11.8 C
New York
토요일, 12월 20, 2025

Buy now

[광고] 쿠팡 추천 링크

안녕하세요? 올해까지 삼성전자 25년 직장 생황릃 마치고 퇴직하려 합니다. 퇴직 후 아르바이트로 쿠팡 파트너스 활동을 하려고 합니다. 쿠팡 파트너스는 쿠팡 추천 링크를...

카누 캡슐 커피머신 솔직 리뷰: ‘네스프레소 호환’ 가성비 끝판왕 (ft. 쿠팡 최저가 할인)

'공유 커피' 카누가 만든 카누 캡슐 커피머신 : 캡슐 커피머신 바리스타 브리즈/어반! 네스프레소 오리지널 캡슐 호환으로 활용도는 높이고, 카누만의 황금 레시피로 커피 맛은 깊어졌습니다....
Home Blog Page 337

[워드프레스 최적화] gzip 압축으로 워드프레스 로딩 속도를 개선 방법

인터넷 웹라우저 통신에서 http는 많은 부분을 차지하는데요. 이런 웹 브라우저 통신에서 속도 개선하기 위해서 gzip 압축, 브라우져 캐싱, js & css 압축 그리고 CDN(contents delivery network)과 같은 방법들이 적용되고 있습니다.

이러한 위의 웹 사이트를 최적화 방법 중 gzip 압축을 적용해 사이트 속도를 높이고 트래픽도 감소시키는 방법에 대해서 알아 봅니다.

아래 내용은 저자와의 협의하에 웹서버 최적화 -NGINX에서 gzip 압축으로 트래픽과 로딩 속도를 개선해 보자를 그대로 인용하였습니다.

1. gizip이란 무엇일까요?

위키백과 에서 gzip 설명 내용을 토대로 다시 정리해 보면

  • gzip은 GNU zip의 준말로 유닉스시스템에서 사용하는 압축 프로그램으로 시작되었다.
  • 1992년 10월 31일 Jean-loup Gailly와 마크 애들러가 만들어 처음 배포하였다.
  • 압축 구현 방법은 LZ77과 허프만 코딩을 조합한 DEFLATE알고리즘에 기반한다고 알려져 있다.

즉 gzip은 웹서버에서 사용하는 압축 프로그램으로 여기서 압축한 방식을 대부분의 웹 브라우저에서 지원하는 범용성때문에 웹서버 최적화 시 많이 사용하는 소프트웨어입니다.
리눅스계열등을 설치 시 기본으로 배포하는 프로그램으로 이를 사용하기 위해 프로그램을 설치할 필요가 없습니다.

2. gzip설정 옵션

gzip의 옵션에는 아래와 같은 것들이 있습니다.

  • gzip [on/orr] : gzip의 설정을 on/off하는 명령
  • gzip_disable [regex] : 해당 명령어 다음에 오는 문장이 요청 헤더에 User-Agent와 일치 시 압축하지 않음
  • gzip_vary [on/off] : gzip, gzip_static, or gunzip 설정이 on일 시 응답 헤더에 “Vary: Accept-Encoding”를 넣을지 말지에 대한 명령
  • gzip_proxied : 요청과 응답에 따라서 프록시된 요청을 압축할지 말지에 대한 설정으로 “any”로 설정하면 모든 응답에 대해 gzipping 압축을 수행
  • gzip_comp_level [level] : 응답에 대한 압축의 정도를 의미하며 level의 값은 1부터 9까지 가능
  • gzip_buffers [num] [size] : num은 버퍼의 갯수, size는 버퍼의 크기를 의미
  • gzip_http_version [versino] : minimum HTTP 통신 버전
  • gzip_types [types in array] : “text/html”외 추가로 gizip항 타입 정의

3. nginx에서 gzip설정

nginx에서 gzip을 설정하는 방법은 /etc/nginx 경로에 있는 nginx.conf 파일을 수정해서 설정합니다.

gzip을 적용 시 주의할 점이라고면 욕심에 모든 파일 압축을 요구하는데 이는 오히려 서버의 부하를 가중시켜 속도를 떨어뜨린다고 합니다.

  • gzip_min_length 1024;와 같이 압축해야 할 최소 크기를 지정, 어느 정도 큰 파일만 압축하라고 가이드 함
  • 이미지 파일은 압축이 안되기 때문에 압축 타입에서 빼라고 함
  • 단 이미지 파일이지만 SVG 파일은 코드 형태로 되어 있으므로 적용 가능

3.1. SVG 파일 압축 가능한지 확인

SVG 파일을 gzip 압축이 가능하게 하려면
먼저 NGINX에 이를 가능케 되어 있는지 mime types을 확인해야 합니다.

  • /etc/nginx/mime.types 파일을 열어 image/svg+xml svg svgz;가 있는지 확인하고 없으면 추가
  • 최근 NGINX에는 포함되어 있음

3.2. gzip 설정

아래와 같이 gzip 옵션을 적용합니다.

# enable gzip compression

gzip on;
gzip_disable "MSIE [1-6].(?!.*SV1)";  # IE 6이하에는 적용시키지 않음
gzip_vary on;
gzip_min_length  1024;
gzip_buffers     16 8k; 
gzip_proxied any;
gzip_comp_level 6; # 압축 레벨 1~9 사이 선택 
gzip_http_version 1.1;
gzip_types       text/html application/x-javascript text/css application/javascript text/javascript text/plain application/json application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/xml font/eot font/opentype font/otf image/svg+xml ;

#end gzip configuration

저장하고 nginx가 제대로 작동하는 지 테스트 한 후 문제가 없다면 nginx를 재 가동시킵니다.

nginx -t
service nginx reload

10$ 제휴 프로모션으로 Vultr 가입하기

[워드프레스 최적화] gzip 압축으로 워드프레스 로딩 속도를 개선 방법 1

[워드프레스 최적화] FastCGI 적용 워드프레스 반응 속도 및 서버 로드 줄이기

오늘은 워드프레스 속도를 빠르게 하는 방법 중 상당히 효과가 좋다고 알려진 FastCGI 적용 방법에 대해서 알아보도록 하겠습니다. 이는 웹서버로 NGINX를 사용하는 경우 유용합니다.

웹서버로 아파치를 많이 사용하고 점유율도 높지만 얼마 전부터는 단순하면서 성능이 좋은 NGINX를 웹서버로 사용하는 경우도 늘었습니다. 특히 동접자가 많은 경우 NGINX가 메모리 관리 등에서 효율성이 있다고 알려져 그런 흐름이 가속화 되기도 했습니다.

그렇지만 아파치에서도 NGINX만의 장점들을 쉽게 구현하는 방법들이 등장해 아파치를 사용에도 별 문제가 없어져 차별화가 많이 희석되기도 했습니다.

1. FastCGI cache란?

일반적으로 사용자가 브라우저를 통해서 특정 페이지를 보겠다고 요청하면 NGINX는 PHP와 MySQL이라는 데이타베이스에게 명령을 내려 사용자가 요청한 페이지를 구성하게 하는데요. FastCGI는 NGINX와 PHP 사이에서 기존에 불러왔던 페이지를 저장해 놓고 있다가 사용자 요청이 오면 PHP나 MySQL의 도움없이 바로 사용자에게 보여주어 굉장히 빨리 처리해 속도를 높이고 시스템의 부하를 줄이는 역활을 합니다. 이를 업계에선 Full page caching이라고 부르고 있네요.

아래는 FastCGI가 작동하는 다이어그램인데요. NGINX, PHP-FPM, MySQ 사이의 관계를 잘 보여주고 있습니다.

FastCGI 작동 방식 다이어그램 ashleys-server-architecture

FastCGI cache는 서버 부하를 줄여주고, 사이트 속도를 빠르게 해주는데요. cache된 페이지 중심이긴 하지만 속도가 빨라지고 TTFB(Time To First Byte, 서버에 요청해 첫 데이타를 받기까지 걸리는 시간)가 절반 이하로 줄어듭니다.

2. FastCGI 적용 방법

그러면 이런 FastCGI cache를 적용하려면 어떻게 해야 할까요?

아래와 같이 순서대로 적용해 보시지요. FastCGI cache는 서버를 설치(NGINX, PHP, MariaDB 등) 시 자동으로 설치되므로 설되어 있는 기준으로 세팅을 어떻게 하는냐를 말씀드리겠습니다.

2.1. Nginx의 설정파일 nginx.conf 설정하기

먼저 Nginx의 설정파일인 nginx.conf에서 FastCGI cache 관련 내용을 설정합니다.

여기는 Nginx의 설정 파일 중 http 구간에 적용하는 코드가 되겠습니다.

FastCGI cache path 위치 지정

FastCGI cache path 위치는 아무 곳이라도 상관이 없습니다. 심지어 별도로 위치를 지정하지 않아도 NGINX가메모리 여유가 있으면 자동으로 Cache를 램에 올려 사용하고 모자라면 스압을 사용한다고 합니다.

그렇지만 필요에 따라서 FastCGI Cache 파일을 지우는 등 Cache 관리를 하려면 일정 폴더를 지정해 주어야 합니다. FastCGI Cache를 관리해주는 플러그인들은 대부분 Cache 폴더를 지정토록 하고 있습니다.

물론 폴더와 상관없이 FastCGI cache를 관리하는 방법이 있기는 한데 불안정하고 설치 버젼에 따라서 작동하지 않은 경우도 많기 때문에 cache 폴더 지정해 관리하는 것이 좋습니다.

그리고 몇가지 옵션을 테스트했지만 명확히 메모리 폴더를 지정하지 않으면, 우선 순위에서 밀리기 때문에 램에서 작동하지 않는 경우도 많아지는 것 같습니다.

그렇기 때문에 램에서 작동토록 하려면 Cache 폴더를 지정해 주어 확실하게 우선 순위를 설정하는 것이 나은 선택입니다.

또한 메모리가 충분하지 않다면 SSD로 구성된 스토리에 FastCGI cache 폴더를 지정해 운영하는 것도 차선책이 될 수 있습니다. 그렇지만 예전 느려빠진 HDD 스토리지라면 별로 추천하고 싶지는 않습니다. 콘텐츠 내용이 많지만 자주 업데이트 되지 않는 사이트의 경우 Cache 기간을 며칠 정도로 길데 잡아 효율성을 높일 때 유용할 것 같습니다.

제가 아는 사이트는 콘텐츠 양이 많다보니 8시간 정도로 길게 잡으니 cache 용량이 2GB를 넘어 버리드라구요. 이런 경우는 램을 업그레이드 할 수 없다면 SSD 스토리에 Cache 폴더를 설정해 운영하는 것도 아주 나쁘지는 않습니다.

당연히 비즈니스 사이트라면 램을 업그레이드해서 Cache 전체를 램에 올리는게 좋겠죠.

저는 용량은 적지만 빠른 RAM 메모리에 했는데요. 여기서는 두가지 경우를 모두 표현 했습니다.

# 일반 디스크에 6999MB 용량에 cache해 캐시 유효기간을 10분으로 유지하는 WORDPRESS라는 캐시 이름
#fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=WORDPRESS:2048mb inactive=8h; # Disk애 적용 시 

# RAM 메모리 512MB 용량을 할당, 10분동안 유지하는 WORDPRESS라는 캐시 이름
fastcgi_cache_path /dev/shm/fastcgi levels=1:2 keys_zone=WORDPRESS:512m inactive=10m; #RAM에 적용 시
Code language: PHP (php)

여기서 정말 강조하고 싶은 것은 위치 지정 후 정말 제대로 작동하는지를 꼭 확인하라는 것입니다. path 설정해 놓는다고 다 작동하지는 않으며 RAM에 올리는 방식 또는 Disk에 설정 시 스왑등이 제대로 설정되어 있는지에 따라서 제대로 작동하지 않을 수 있습니다.

FastCGI cache 중 발생 상황 대응 지정

그 다음은 FastCGI가 디스크에 파일을 배치하는 방법, FastCGI 서버와의 통신 중에 오류 발생 시 하는 경우 등 오래된 캐시를 사용할 수 있는 경우, 워드프레스 테마 중 종종 부적절한 헤더값을 보내주는 경우 무시하라는 옵션을 표기합니다.

fastcgi_cache_key "$scheme$request_method$host$request_uri$mobile_request";
fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
Code language: PHP (php)

FastCGI cache 조건 설정

fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_valid 404 30s; 
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_keep_conn on;
Code language: PHP (php)
  • 여기서 fastcgi_cache_valid 200 301 302 60m;은 응답코드가 200 301 302인 것을 캐시하고 그 캐시파일의 유효기간을 60분을 잡는 것입니다. 개인 사이트는 변경 내용이 많지 않으니 넉넉하게 시간을 주어도 좋을 것이고, 커뮤니티 사이트는 빨리 내용이 갱신되므로 1m(1분) 또는 30s(30초) 단위로 짧은 시간을 주는게 좋다고 합니다.
  • fastcgi_cache_valid 404 30s;은 응답코드가 404인 것은 30초마다 다시 갱신토록 했습니다.
  • fastcgi_buffers 16 16k; , fastcgi_buffer_size 32k;는 캐시 버터 크기 설정입니다.

FastCGI 캐시를 메모리에서 작동시키기

FastCGI를 일반 디스크에서 실행하는 것보다도 RAM 메모리에서 실행시키면 더욱 빠르겠죠.
RAM 시스템 메모리는 디스크보다 훨씬 빠르니 반응시간도 훨씬 빨라질 것 입니다.

먼저 RAM 디스크를 등록해 줍니다. /etc/fstab 파일을 nano 편집기를 열어 편집할 수 있도록 합니다.

nano -w /etc/fstab
Code language: PHP (php)



fstab에서 아래와 같이 RAM 디스크를 등록해 줍니다.

tmpfs /dev/shm/fastcgi tmpfs defaults,size=128M 0 0
Code language: PHP (php)



다음에는 RAM Disk를 구성할 디렉토리와 소유권등을 정리해 줍니다. RAM Disk로 /dev/shm/fastcgi를 나들겠습니다.

mkdir  /dev/shm/fastcgi
chown www-data:www-data /dev/shm/fastcgi
chmod +x /dev/shm/fastcgi
Code language: PHP (php)

이러면 자동으로 디렉토리를 만들고 그리고 나서 NGINX 시스템을 다시 실행합니다.

service nginx restart
Code language: PHP (php)

이제 새로운 RAM Disk를 마운트합니다.

mount -a
Code language: PHP (php)

참고로 RAM Disk를 없애려면 /etc/fstab에서 Ram 디스크를 지우고, 터미널에서 umount 명령을 사용합니다.

umount /dev/shm/fastcgi
Code language: PHP (php)


Nginx에 캐시폴더 권한을 줍니다

chown www-data:www-data /dev/shm/fastcgi
Code language: PHP (php)

이렇게 별도 폴더를 만들지 않고 우분투 설치 시 자동으로 만들어지는 /dev/shm 폴더를 그대로 사용하는 것도 방법입니다. 별도 폴더를 만들지 않아도 되기 때문에 더욱 간편하긴 한데요. 이 폴더에 다른 프로그램도 사용할 수 있어 fastcgi 폴더를 만드는 것도 나쁘진 않습니다.

2.2. 서버 블락에서 FastCGI cache 설정

지금부터는 서버 블락에서 FastCGI cache 관련 옵션 정리 방법입니다.

캐싱을 하지 말아야 할 경우 설정

캐싱을 하지 말아야 할 경우가 있는데 이 구간을 정의하는 부분입니다.

    set $skip_cache 0;

    # ---------------------------------------------------------------------
    # 캐싱을 하지 말아야 할 경우가 있는데 이를 정의하는 구간 CACHE SKIP RULES - START
    # ---------------------------------------------------------------------

    # Do not cache POST requests - they should always go to PHP
        if ($request_method = POST) {
       set $skip_cache 1;
    }

    # Do not cache URLs with a query string - they should always go to PHP
    if ($query_string != "") {
       set $skip_cache 1;
    }

    # WooCommerce-specific cache skip rules
    if ($request_uri ~* "/store.*|/cart.*|/my-account.*|/checkout.*|/addons.*") {
    set $skip_cache 1;
       set $skip_cache_reason WP_WooCommerce;
    }

    if ($cookie_woocommerce_items_in_cart) { 
       set $skip_cache 1; 
       set $skip_cache_reason WP_WooCommerce;
    }

    if ($request_uri ~* ("/cart.*")) { 
       set $skip_cache 1; 
    }

    # Don't cache URIs containing the following segments (admin panel, sitemaps, feeds, etc.)
    if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $skip_cache 1;
    }

    # Don't use the cache for logged-in users or recent commenters
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
    }

    # ---------------------------------------------------------------------
    # CACHE SKIP RULES - END
    # ---------------------------------------------------------------------
Code language: PHP (php)

FastCGI와 PHP-FPM과 통합

이제 FastCGI cache와 PHP간 통합을 정의합니다.
이 부분도 마찬가지로 server 블락에 아래 내용을 추가 합니다.

    # Add PHP handler
    location ~ \.php$ {

    try_files $uri =404; # comment out this line if php-fpm is hosted on a remote machine
    include /etc/nginx/fastcgi.conf;
    fastcgi_cache WORDPRESS;
    add_header X-Cache $upstream_cache_status;
    fastcgi_pass unix:/run/php/php7.2-fpm.sock;

    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;

    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    if (!-f $document_root$fastcgi_script_name) {
        return 404;
        }
    }
Code language: PHP (php)

3. NGINX 재가동 및 작동 테스트

FastCGI 설정이 완료되면 nginx를 다시 가동시키고 제대로 작동하는지 테스트 해 봅니다.

먼저 문법 상 충돌되거나 오류가 없는지 config test를 진행합니다.

service nginx configtest
Code language: PHP (php)



“the configuration file /etc/nginx/nginx.conf syntax is ok” 라는 문구가 나오면 정상적으로 작동 가능한 것이므로 nginx를 다시 가동시킴니다.

service nginx restart
Code language: PHP (php)



이제 FastCGI가 제대로 작동하는지 확인해 봅니다.

ls -alhR /dev/shm/fastcgi
Code language: PHP (php)



그러면 현재 cache되고 있는 리스트가 주욱 나옵니다. 그러면 정상적으로 작동하는 것이니 기쁜 마음으로 마무리 합니다.

4. 시행 착오

무사히 FastCGI를 설치하고 작동하는 것을 확인하고부터 사이트의 속도가 굉장히 빨라졌습니다. 그리고 욕심을 내어서 몇가지를 조정했습니다.

  • 먼저 cache를 램에 올리고 메모리를 512MB을 할당했습니다.
  • 다음 cache 교체 시간을 1440m으로 상당히 길게 잡았습니다. 내용이 많이 바뀌지 않기 때문에 여유있게 잡아본 것입니다.

이렇게 설정을 바꾼 후 처음 엄청 빠른 속도를 보여 주었던 것이 시간이 지나면서 엄청 느려지기 시작했습니다. 사이트 메인의 TTFB가 처음에는 0.3ms정도였는데 어느 순간 1.3s까지 느려지더군요.

세팅 초기의 webpagetest.org 측정 결과

일정 시간 경과 후 webpagetest.org 측정 결과

왜 이런 문제가 발생했을까 여러가지 설정 테스트를 해보니 cache 유지 시간이 길고, RAM 512MB에 세팅한 cache가 꽉 찬 상태에서는 무엇인가가 제대로 작동하지 않는다는 결론을 얻었습니다.
cache를 비우고 cache 설정 시간을 30m 정도로 줄이니 제대로 작동했으니깐요.

결국 cache 메모리가 적다면 cache 교체 시간을 짧게 설정해야 한다는 결론을 얻었습니다.

하지만 나중에 생각해보면 Fastcgi는 설정한 용량이 차면 순서대로 Cache를 지우도록 되어 있기 때문에 위와 같은 해석은 근거가 없습니다. 어느 분이 스왑으로 변경하기 때문에 그럴 것이라는 의견을 주셨는데 앞에서 설명드린대로 SSD도 상당히 빠르기 때문에 설령 나머지가 스왑으로 전환되어 SSDㅇ서 작동한다고 해도 그 정도로 느려지지는 않습닏.

그후 FastCGI와 구글 모드 페이지 스피드를 같이 운영 시 나타나는 문제라는 것을 알았습니다. 구글 모드 페이지 스피드는 너무 열심히 일을 해서 구글 모드 페이지 스피드 캐시를 끊임없이 업데으이트하면서 CPU자원을 100%이상으로 사용하고 여기에 FastCGI Cache도 만드느라 이중 일을 하면서 속도가 느려지는 현상이었습니다. 이후 구글 모드 페이지 스피드를 제거 후 이런 문제를 만나적은 없습니다.

5. 참고 포스팅

[워드프레스 최적화] 스왑 메모리 설정으로 워드프레스를 안정적으로 운영 하기

Vultr 가상서버호스팅(VPS)에서 워드프레스 운영 중 메모리 스왑 파일을 적용해 속도를 향상시키는 방안에 대해서 알아 보겠습니다.

사이트 운영을 위해 서버를 설치 시 운영체제나 데이타베이스 종류는 최신의 트렌드를 반영하여 선택하기 마련입니다.
예를 들어 운영체제는 대부분 64비트를 선택하죠. 그리고 데이타베이스로 InnoDB가 적용된 MariaDB를 선택하곤 합니다. 이들은 가장 최신이고 가장 성능에서 앞선다고 알려진 것들 입니다.

그런데 여기에 함정이 있네요. 본격적인 사이트 운영을 위해 서버 사양을 빵빵하게 운영한다면 별로 문제가 되지 않겠지만 엔트리급을 선택하는 경우는 조금 다릅니다. 예를 들어 Vultr의 756MB 메모리를 가진 2.5$ 플랜이나 1GB 메모리를 가진 5$ 플랜을 선택하는 경우 잘못하면 메모리 부족에 허덕일 수 있기에 가장 적은 메모리를 사용하는 사양을 선택해야 합니다.
그런 관점에서 최소 메모리 요구 조건은 64비트보다는 32비트 운영체제가 더 낫고, InnoDB가 적용된 MariaDB보다는 MyISAM를 적용한 일반 MySQL이 차라리 낫습니다.

그러나 이미 64비트에 MariaDB를 적용해 사용하고 있는데 다시 설치하고 최적화시키는 것은 무지 귀찮은 일이죠. 선수가 아니라면 또 엄청난 시간을 들여서 구글링을 해야겠지요.

서두가 조금 길었는데요. 이렇게 엔트리 사양에서 메모리 부족이 발생하는 경우가 많은데 이를 해결하는 방법으로 디스크를 이용 스왑 메모리를 만드는 방법에 대해 간략히 살펴 봅니다.

1. 시스템 저장 공간 사용 현황 파악

다행히 요즘은 SSD로만 운영되는 상품이 많기 때문에 SSD 디스크에 스왑 메모리를 만들면 어느 정도 성능이 나오기 때문에 시도할 만합니다.

그러면 어떻게 이 스왑 메모리를 만들어 이용할 수 있을까요?
우선 시스템에 스왑 메모리를 적용할 여유가 있는지 확인합니다.

이때 시스템 내 디스크 및 메모리 사용 현황을 파악하기 위해서 df -h라는 명령을 사용합니다. 이 명령을 내리면 시스템에 구성된 각종 디스크와 RAM 메모리 사용 현황을 보여 줍니다.

# df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            469M     0  469M   0% /dev
tmpfs            99M   11M   89M  11% /run
==/dev/vda1        25G   16G  7.8G  67% /==
tmpfs           495M     0  495M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           495M     0  495M   0% /sys/fs/cgroup
tmpfs            99M     0   99M   0% /run/user/0


이에 따르면 SSD 디스크 공간 25GB중에서 16GB가 남아있다는 것을 알 수 있습니다.

2. 스왑 메모리 파일 만들기

16GB 용량이 남아 있다는 것을 확인했으면 어느 정도 크기의 스왑 파일을 만들 것인지를 결정해야 합니다.

저의 경우 1GB 메모리가 있는데 조금 넉넉한 스왑 메모리를 확보하고 싶어서 4GB를 선택했습니다. 어짜피 놀고있는 SSD 공간이므로..

아래와 같은 명령을 사용해 스왑 파일을 만듭니다. 스왑 메모리 파일을 만들고, 권한을 부여하고 포맷하는 일련의 과정을 바로 이어서 진행 합니다.

fallocate -l 4G /swapfile  # 4GB 스왑 메모리 파일을 만든다.
chmod 600 /swapfile     # 스왑 메모리 파일에 쓰기 권한을 부여한다.
mkswap /swapfile        # 스왑 메모리 파일을 포맷한다.
swapon /swapfile        # 스왑 메모리 파일을 활성화 한다.



위와 같은 작업을 통해서 4GB의 스왑 메모리 파일이 생성되었습니다.
그러면 정말로 스왑 메모리가 만들어졌는지 확인을 해봅니다. 이때 사용하는 명령은 free -m 또는 swapon -s 명령입니다.
free -m 명령은 일반 메모리와 스왑 메모리 상태를 보여줍니다. 스왑 메모리가 없다면 0으로 표기됩니다. 아래에서는 생성된 스왑파일 4095가 보이네요.

@happist:~# free -m
              total        used        free      shared  buff/cache   available
Mem:            988         540          85         117         362         187
Swap:          4095         108        3987



swapon -s 명령을 사용하면 아래와 같은 결과를 보여 줍니다.

@happist:~# swapon -s
Filename                Type        Size    Used    Priority
/swapfile                                  file        4194300    108288    -1


3. 영구 스왑 메모리 파일로 만들기

위와 같이 만들어진 스왐 메모리는 다시 부팅하면 없어져 버립니다. 따라서 시스템이 존재하는 한 계속 사용할 수 있도록 만드는 작업이 필요합니다.
이는 /etc/fstab의 파일에 아래 내용을 추가하는 것입니다.

nano /etc/fstab   # fstab 파일을 편집



fstab 파일 맨 아래 부분에 아래 내용을 추가

/swapfile   none    swap    sw    0   0


4. 스왑 메모리 죽이기

메모리를 충분히 증설했거나 스왑 파일을 활용함에도 별로 성능에 도움이 되지 않은다면 과감히 지워버릴 필요가 있겠죠.
스왑 메모리 파일을 지우는 것은 아래 rm 명령을 사용합니다.

rm /swapfile

10$ 제휴 프로모션으로 Vultr 가입하기

[워드프레스 최적화] 스왑 메모리 설정으로 워드프레스를 안정적으로 운영 하기 2

[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법

오늘은 워드프레스 운영을 위해 Vultr 가상서버호스팅(VPS)에 서버 설치 후 최적화하는 방안에 대해서 살펴보고 있습니다.
서버 최적화는 웹서버 최적화, DB 최적화 그리고 PHP 최적화등으로 나누어질 수 있는데요. 오늘은 이 중 DB 최적화에 대해 살펴 보겠습니다.

여기 워드프레스를 설치한 서버에는 MariaDB가 기본으로 설치되어 있으므로 MariaDB 최적화 방안 중심으로 살펴 보겠습니다.
사실 그동안 DB 부분은 접근할 엄두가 나지 않았고, 최적화가 크게 필요 없다는 생각을 했는데, 자료를 보다보니 여기에서의 최적화가 절대적으로 필요하다고 하고, 여기까지 최적화하지 않으면 두고 두고 후회할 것 같아 없는 시간을 내서 시도해 보았습니다.

1. my.cnf 위치

MariaDB를 설치했기 때문에 InnoDB 최적화에 대한 내용이니 참고하시는게 좋겠습니다.

다 아시는 것처럼 MariaDB를최적화하기 위해서는 my.cnf에서 설정을 변경해 주는데요.
이 파일은 /etc/my.cnf 또는 /etc/mysql/my.cnf에 위치하고 있습니다.

2. 최적 메모리에 대한 생각

MariaDB 최적화를 위해서 자료를 조사하다보니 메모이이야기 많이 나옵니다. 메모리는 많으면 많을수록 좋다는게 일반적인 상식이고, 이 DB와 관련해서도 마찬가지입니다.

DB가 작업하는 공간이 속도가 빠른 메모리에서 모두 진행하는게 속도를 올릴 수 있는 지름길이기 때문이죠.

그러면 도대체 어느 정도 메모리를 가지고 있어야 할까요?

일반적으로 메모리의 크기는 최소 데이타베이스 크기 정도는 확보해야 한다고 합니다. 데이타베이스 크기와 RAM의 크기가 비숫하면 별다른 세팅을 하지 않고도 어느 정도 성능을 낼 수 있다고 합니다. 만약 6GB의 데이타베이스가 있다면 메모리도 최소 6GB가 있어야 하고 이보다도 20%~30%정도 더 메모리가 있다면 최상이라는 것이죠.

그러나 일반적으로 비용의 문제이기 때문에 충분한 메모리를 가지지 못하는 경우가 생기죠. 이렇게 서버에 충분한 메모리가 없는 경우 제대로 된 MySQL/MarianDB가 작동하지 않을 수 있습니다. 그렇기에 최적화가 필요합니다.

3. MariaDB 필수 최적화 항목들

my.cnf에는 많은 설정 변수들이 있는데요. 이러한 설정들을 최적화해서 적은 메모리로 가능하는한 최고의 성능을 낼 수 있는 옵션이 무엇이 있는지 살펴 보겠습니다.

이는 가능하면 디스크 대신 빠른 메모리 영역에서 작업을 처리할 수 있도록 설정을 유도함으로써 CPU 성능과 조화를 이루어 전체 성능을 높일 수 있습니다.

3.1. innodb_buffer_pool_size

이 설정은 데이카베이스가 얼마만큼의 메모리를 가져다 쓸 것이냐를 지정하는 것으로 가장 중요한 설정 중의 하나입니다.

설치 시 기본으로 세팅되어 있는 값은 128k인데요. 많은 문헌에서 시스템 메모리의 65%~75% 권장하고 있습니다.

  • 일반적으로 5~6GB (8GB RAM)
  • 20~25GB (32GB RAM)
  • 100~120GB(128GB RAM)

Vultr에서 사용하는 5$ 플랜은 기껏 1GB 시스템 메모리를 가지고 있으므로 750MB를 할당하였습니다.

innodb_buffer_pool_size= 750M

3.2. innodb_log_file_size

innodb_log_file_size는 데이타베이스 충돌 발생 시 다시 실행하거나 이전으로 되돌릴 때 사용하는 메모리이빈다.

이 사이즈는 기본으로 48M이 할당되어 있는데요. 일반적으로 앞서 설정한 innodb_buffer_pool_size의 25% ~ 50% 정도 할당하는 게 좋다고 합니다. 다만 너무 클 필요는 없다는 지적이 있네요.

innodb_buffer_pool_size= 185MB

3.3. innodb_flush_log_at_trx_commit

이는 데이타베이스가 작동을 어떤 방식으로 기록하느냐를 설정하는 것이죠.

설정값은 1, 2, 0의 세가지가 있는데 기본은 1로 설정되어 있습니다.

1로 설정되면 트랜잭션을 수행할때마다 버퍼가 로그 파일에 기록되고 로그 파일은 다시 디스크로 플러시 됩니다.

2로 설정되면 데이타베이스가 각 트랜잭션을 완료 시 로그 파일에 기록되고 로그 파일은 1초마다 디스크로 플러시 됩니다.

0으로 설정되면 각 트랜젝션 시 아무런 기록을 하지 않고 로그 버퍼는 로그 파일에 기록되어 1초마다 디스크로 플러시 됩니다.

가장 성능이 좋은 것은 0을 선택하는 것이고, 1을 선택하면 가장 높은 신뢰성을 보여 준다고 합니다.

정전 등에 대비가 잘 되어 있다면 성능을 중요시해 0을 선택할 수도 있는데요. 저는 성능 지상주의이므로 0을 선택했습니다.

3.4. query_cache_size

query_cache_size는 SQL 실행 결과를 미리 특정 공간에 저장해 놓고, 다음 번 같은 문장으로 호출 시 빠르게 해당 결과를 보여주는 것인데요.

query_cache_size가 너무 크다면 갑자기 엄청난 쓰기 작업이 발생하면 서버는 바로 쿼리 작업을 하는 대신 cache를 찾아 작동하는데 집중해 오히려 속도가 느려집니다.
query_cache 때문에 발생하는 병목 현상은 자주 나타나는 현상으로 아주 악명이 높다고 알려졌는데요. query_cache_size는 너무 크지 않게 설정하는 게 좋으며 최고 512M이면 충분하다는 의견입니다.

또 어떤 가이드는 차라리 query_cache_size를 0으로 놓는 것을 고려하라고 충고하고 있습니다.

3.5. Disable MySQL DNS Lookups

DNS lookups 호스트 네임과 IP를 매번 확인후 작동하므로 느려질 수 있다고 합니다. 따라서 skip-name-resolve 명령어를 추가해서 이를 방지합니다.

skip-name-resolve

3.6. innodb_io_capacity

SSD와 같은 성능 좋은 Disk를 사용하고 있다면 이를 크게 올려주는 게 성능에 좋다고 합니다.
Vultr는 모두 SSD로 운영되므로 nnodb_io_capacity를 105000 이상으로 설정했습니다.

innodb_io_capacity = 15000

3.7. tmpdir

데이타베이스 서버에서 작동하는 많은 수의 쿼리를 디스크에서 메모리로 MySQL 임시 디렉통리를 변경하면 획기적으로 속도를 개선 가능합니다.

로드가 느린 쿼리가 포함된 일반적으로 최적화되지 않은 워드프레스 데이타베이스인 경우 이 설정은 큰 성능 개선이 가능하다고 하는데요.
이를 위해서 는 tmpdir을 램디스크인 tmpfs 디렉토리로 설정하면 성능을 개선할 수 있습니다.

램디스크인 tmpfs 위치가 어디인지를 확인하려면 df -h 명령어를 사용합니다.
일반적으로 linux의 fstab 파일에는 tmpfs가 /dev/shm가 기본으로 지정되어 있습니다.

# df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            469M     0  469M   0% /dev
tmpfs            99M   11M   89M  11% /run
/dev/vda1        25G   16G  7.8G  67% /
tmpfs           495M     0  495M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           495M     0  495M   0% /sys/fs/cgroup
tmpfs            99M     0   99M   0% /run/user/0

[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법 3

우리는 TMPDIR을 램디스크에 위치시키도록 만들고자 합니다. 이를 위해서는 기존에 만들어진 램디스크인 tmpfs 디렉토리를 활용하는 방법과 새롭게 램디스크를 만드는 방법이 있습니다.

아래 글을 참조해 보시죠.

[워드프레스 최적화] 데이타베이스를 램디스크에서 작동시켜 속도 개선 방법

여기에선 새롭게 램디스크를 만드는 방법에 대해서 간략 살펴보겠습니다.

먼저 /dev/shm 아래에 /dev/shm/mysql 디렉토리를 만듭니다.

mkdir -p /dev/shm/mysql

이 디렉토리의 owner와 group을 mysql로 변경

chown mysql:mysql /dev/shm/mysql

my.cnf에서 tmpdir을 지정

tmpdir=/dev/shm/mysql

MySql id 찾기

이 램디스크가 리부팅해도 계속 존재하려면 fstab에 등록을 해야하죠. 그러기 위해서 먼저 MySql id를 찾습니다.

아래 명령를 사용하면 uid 및 gid 값을 알 수 있습니다.

id mysql
uid=114(mysql) gid=116(mysql) groups=116(mysql)

fstab 파일 편집

편집기를 통해서 fstab 파일을 편집 상태로 만들어 램디스크를 등록합니다.
여기에서 여기서는 위에서 검색했던 uid와 gid 정보를 활용합니다.
nano /etc/fstab
tmpfs /dev/shm/mysql tmpfs rw,gid=116,uid=114,size=768M,nr_inodes=50k,mode=0700 0 0

램디스크 마운트

이렇게 만들어진 램디스크를 마운트 합니다.
그 전에 nginx를 재부팅합니다.

service nginx restart
mount -a

4. 시스템 적용하기

위와 같이 데이타베이스 최적화 옵션을 반영했다면 마지막으로 MySQL 등을 다시 시작합니다. 그러면 위 설정들이 반영되게 됩니다.

service mysql restart
service php7.2-fpm restart
service nginx restart

그러면 제대로 반영되고 있는지 확인해 볼까요?

먼저 MariaDB로 접속합니다. 패스워드를 치고 들어갑니다.

@happist:~# mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g. 이하 생략
~

다음으로는  SHOW VARIABLES LIKE 'tmpdir'; 명령으로 tempdir을 출역토록 합니다.

~~~javascript
MariaDB [(none)]> SHOW VARIABLES LIKE 'tmpdir';
+---------------+----------------+
| Variable_name | Value          |
+---------------+----------------+
| tmpdir        | /dev/shm/mysql |
+---------------+----------------+
1 row in set (0.02 sec)

음 , 정상적으로 tmpdir은 설정한대로 /dev/shm/mysql에 위치하고 있음을 알 수 있습니다.

10$ 제휴 프로모션으로 Vultr 가입하기

[워드프레스 최적화] 워드프레스 성능 개선을 위한 데이타베이스(MariaDB) 최적화 방법 4

5. 관련 포스팅

사이트 운영을 위한 안내 – 웹서버 세팅에서 워드프레스 설치까지(우분투 17.10, NGINX 1.13.6, Marian DB 10.2, PHP7.2)

Vultr 가상서버호스팅(VPS) 서버 성능은 어느 정도일까? 기대 이상의 성능을 보여주다.

2018년 벽두부터 거세게 타오르는 성희롱 방지 캠페인 #TIMESUP

0

2018년 새해 벽두부터 300여명의 헐리우드 여배우들을 비롯한 많은 여성들이 직장에서의 성희롱과 부정행위를 근절하기 위한 운동에 나셨다고 하네요.

그들은 블루 컬러 여성 노동자들을 지원하기 위해 1300만달러 법적 방어 기금을 모금했습니다.

이 운동은 #TIMESUP으로 명명되어 벌써 트위털를 통해서 활발하게 전파되고 있고 여기에는 Shonda Rhimes, Ashley Judd, Eva Longoria, Reese Witherspoon과 같은 할리우드 배우들이 동참하고 있습니다.

#TIMEUP Campaign

이 운동은 특히 블루 컬러에 초점을 맞추고 이들이 종사하는 미국 전역의 직장에서의 성희롱 퇴치, 성평등을 지지하는 캠페인을 지원하고 있습니다. 그동안 성희롱 문제가 주로 영향력이 큰 헐리우드 중심으로 전개된 데에 대한 비판이 있었는데 이에 대한 반작용인지는 모르지만 이번에는 그동안 외면받았던 블루 컬러 여성 노동자를 중심에 두고 시작되고 있습니다.

300여명의 헐리우드 여배우들이 서명한 공개 서한을 담은 편지가 2018년 1월 1일자 뉴욕타임즈와 스페인어신문 라 오피니언 (La Opinion)에 전면광고로 실렸습니다.
아래 그 편지 내용중 일부입니다.

“Harassment too often persists because perpetrators and employers never face any consequences. This is often because survivors, particularly those working in low-wage industries, don’t have the resources to fight back,”

직장에서 가해자나 고용주 모두 아무런 책임을 지지 않았기 때문에 직장에서 성히롱은 너무 자주 발생합니다. 이는 저임금 산업에 종사하는 노동자들이 이러한 성희롱에 반격할 아무런 힘이 없기 때문에 더욱 더 그렇습니다.

▽ 뉴욕타임즈에 실린 #TIMESUP Campaign 호소문

뉴욕타임즈에 실린 #TIMESUP Campaign 호소문

#TIMESUP Campaign02

아래는 이 캠페인 트윗 몇개를 모아 보았습니다.

인스타그램에 대응하는 스냅챗이 ‘Stories Everywhere’를 서두르는 이유

0

스냅챗은 받는 사람이 메세지를 확인하면 바로 사라지는 일명 ‘단명 메시지’로 뜬 미국의 메세지 서비스죠. 10대를 비롯한 사생활이 노출되는 것을 꺼리는 사람들에게 인기를 끌었습니다.

그리고 2013년 10월 스냅챗은 “Snapchat Stories”라는 기능을 추가하면서 한번 더 도약할 수 있는 계기를 만들었습니다. 이 기능은 사진이나 동영상을 스냅샷에 공유하면 24시간 후에는 자동 삭제되는 기능으로 24시간 동안은 누구나 시청할 수 있습니다.

▽ 요즘 핫한 방탄소년단 스냅챗 스토리 동영상

https://youtu.be/jfHWcKOfHLs

그런데 2016년 8월, 페이스북은 인스타그램 스토리 기능을 런칭합니다. 스냅챗의 카피라는 욕을 먹었지만 인스타그램의 특성과 페이스북 인프라에 힘입어 단숨에 스냅챗을 앞지르게 됩니다. 아마 2017년 중반부터는 인스타그램 스토리 사용자가 스냅챗 스토리 사용자를 능가하게 되죠.

▽ 스냅챗 사용자 및 인스타그램 스토리 사용자 증가 추이
Graph by recode

스냅챗 사용자 및 인스타그램 스토리 사용자 증가 추이 snapchat_vs_instagram_stories_2_01

이러한 인스타그램의 추격을 뿌리치고자 스냅챗은 “Stories Everywhere”라는 서비스를 준비하고 있습니다.

아직 개발 단계이긴하지만 이 서비스는 스냅챗에서 만든 비디오를 다른 플랫폼에 올릴 수 있도록하며, 또한 스냅챗 공개 큐레이션 컬렉션인 “Our Stories”에 다름 앱이 접속해서 스토리를 공유할 수 있도록 기획되고 있다고 합니다.

Executive Summary

스냅챗이 ‘Stories Everywhere’ 서비스를 강화하는 이유는 아래와 같이 3가지로 정리할 수 있습니다.

첫째, 스냅챗 이외의 플랫폼에서 스냅챗 컨텐츠를 경험해보고 스냅챗으로 넘어오는 스냅챗 신규 사용자 유입 강화

둘째, 스냅채 외 플랫폼에 컨텐츠를 노출함으로써, 더 많은 노출 확대를 원하는 인플러언서(influencers)를 확대하고 스냅챗 중심으로 컨텐츠 배포

셋째, 스냅챗 컨텐츠가 다양한 플랫폼 및 사이트에 노출됨으로서 광고 수익 기회 확대

1. 스냅챗이 ‘Stories Everywhere’ 서비스를 강화하는 이유

왜 스냅챗이 이런 시도를 강화하는지를 BI Inteeligence에서 분석했는데요. 이 내용을 간략 공유해 보겟습니다.

Snapchat pushes ‘Stories Everywhere’ to lure users

1.1. 스냅챗 신규 사용자 유입 강화

첫째, 스냅챗 앱에 들어있는 풍부한 사용자 제작 컨텐츠를 무료로 풀면서 새로운 사용자를 유치할 수 있습니다. 스냅챗에는 매일 35억 개의 스냅이 만들어지며, 스냅챗은 검색 및 스냅 맵을 위해 하루 수백만개의 스토리 인덱스를 만듭니다. 이는 스냅챗이 광범위한 잠재 고객에게 어필 할 수 있는 중요 컨텐츠를 보유하고 있다는 것을 보여 줍니다. Stories Everywhere를 사용하는 스냅챗 미가입자는 스냅챗에 가입해 자신의 관심사에 맞는 이야기기들을 더 볼 수 있습니다. 이것으로 스냅챗은 치근 가입자가 둔화된 현 상황을 타개 할수 있습니다.

1.2. 노출 확대를 통한 인플러언서(influencers) 확대

둘째, 스냅챗 헤비 사용자의 앱 검색 능력을 강화할 수 있습니다. Stories Everywhere는 스냅챗 사용자의 컨텐츠가 스냅챗 사용자 1억 7천 8백만명외의 사람들에게도 노출 할 수 있는 기회를 제공합니다. 이는 콘텐츠 제작을 촉진할 수 있고, 스냅챗의 영향력을 강화할 수 있습니다. 스냅챗은 주요 인플러언서(influencers)들에게 플랫폼에서 검색이 더 잘 될 수 있도록 그들이 사용하는 앱 리스트를 재조정하도록 설득하고 있습니다. 인플러언서(influencers)을 확대하는 것은 스냅챗에게 커다란 도우움을 줍니다. 인플러언서(influencers)와 같은 인기있는 사용자는 엄청나게 많은 팔로워를 스냅챗 플랫폼으로 가져올 수 있기 때문입니다.

1.3. 광고 수익 기회 확대

셋째, Stories Everywhere는 더 많은 광고 수익 기회를 만들 수 있습니다. 예를 들어 스냅챗 스토리를 배포하는 제3자 웹 사이트에서 광고를 운영할 수 있습니다. 페이스북과 인스타그램은 다른 플랫폼에 스토리 공유를 허용하지 않기 때문에 브랜드들은 여기에 광고를 집행하는 경향이 있습니다. 추가 광고 수익을 얻는 것은 기업 공개 후 매분기마다 기대 수익을 맞추지 못했기 때문에 스냅챗으로서는 매우 중요합니다.

2. 스냅챗 Stories Everywhere 문제점

스냅챗이 Stories Everywhere는 친한 친구끼리 상호 작용할 수있는 플랫폼으로써의 Snapchat의 핵심 정체성을 벗어날 수 있습니다.
2017년 11월 스냅챗이 밝힌 바에 따르면 스냅의 60%가 매우 가까운 친구끼리 주고 받은 스냅이었으며, 이러한 스냅가운데서 자연스럽게 브랜드 광고가 이루어지는 프랫폼이 되었다고 합니다.
Stories Everywhere는 스냅챗의 폐쇄성을 약화시킬 것이며 스냅챗 앱의 친밀성에 익숙한 사용자들을 실망시킬 수 있습니다.

미디어의 미래, 마케터라면 알아야 할 14가지 예측 By BI Intelligence

0

2018년 연초, 격변하고 있는 이 시점에 미디어의 미래에 대해서 잠시 생각해 보는 것도 나쁘지 않은 것 같습니다. 특히 마케터라면 말이죠.

미국의 마케팅 조사 및 컨셜팅 업체인 BI Intelligence는 “14 Things You’ll Want to Know About
the Future of Media”라는 보고서를 공개했습니다. 이 보고서는 BI Intelligence 회원에게 무료로 배포하느 보고서임데요. EXCLUSIVE FREE SLIDE DECK: 14 Things You’ll Want to Know About the Future of Media 이 주소로 접속하면 얻을 수 있습니다. 혹시 몰라서 이 포스티의 마지막에 PDF를 첨부해 놓았습니다. 다만 조회만 가능하게 해 놓았습니다. 제가 저작권자가 아니라서 배포할 수는 없을 것 같습니다.

내용은 매우 평이하게 PT 덱 형식으로 되어 있어서 잠깐이면 전체 내용을 살펴볼 수 있습니다. 그 동안 알려진 내용을 토대로 BI Intelligence의 인사이트를 담았으므로 일독할 만합니다.

여기서는 간단하게 그 내용을 소개하도록 하겠습니다. 좀 더 자세한 내용은(워낙 간단하게 작성된 덱이라 복잡하지는 않습니다.)

다만 아직 공력이 부족해서인지 BI Intelligence에서 주장하는 바가 다 이해되는 것은 아닙니다. 미국 중심이라고 그렇까요?

Executive Summary

미디어의 미래에 대한 BI Intelligence의 인사이트는 아래와 같이 list-up될 수 있습니다.

  1. 이미 미디어 사용은 역대 최고치에 도달하고 있음. 멀티 태스킹으로 매일 31시간 활동하면 이중 12신을 미디어에 사용.

  2. 앞으로는 경쟁력 있는 미디어를 가장 편한 방식으로 소비, 공유, 이야기할 것이다.

  3. 미디어 증가는 개발도상국에서 활발하게 진행할 것이다.

  4. 디지탈 광고는 선진국에서도 성장중이며, 아시아의 성장이 매우 빠르다.

  5. 새로운 TV 네트워크가 동영상을 포함한 비디오 보급을 지배할 것이다.

  6. 기존 인쇄 매체의 비디오 미디어로의 전환만이 답은 아니다.

  7. 미래에 모든 미디어는 곧 비디오 미디어가 되는 것은 아니다.

  8. 스마트 스피커 및 자가 운전 자동차에서 미디어 사용 증가는 과장 되었다.

  9. AR은 도처에서 구현될 것

  10. “social stories.”에서 거대한 성장 예상

  11. 광고 독점은 현실이다.

  12. 광고 유통 플랫폼은 유통 컨텐츠에 책임을 져야.

  13. 이제 혁신적 디지탈 광고가 등장하고 있다.

  14. 아직 최적의 디지탈 미디어 광고 모델은 없다.

1. 최고치에 달한 미디어 사용, In the US, we’re nearing “peak media.”

미국에서 미디어 사용은 역대 최고치에 도달하고 있습니다.
사람들은 멀티태스킹을 통해서 매일 31시간 활동을 합니다. 이 중에서 12시간은 미디어와 테크 디바이스를 사용합니다.

  • 업무 5시간
  • 요리, 청소, 식사 등등 7시간
  • 취침 7시간
  • 미디어 및 테크 사용 12시간

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence003

디지탈 미디어 사용 시간이 6시간으로 가장 길다.

이마케터에 따르면 미디어 사용 시간중 가장 많은 시간(약 6시간)을 디지탈 미디어에 사용합니다.

미디어의 미래, 마케터라면 알아야 할 14가지 예측 By BI Intelligence 5

향후 미디어 사용 시간 증가는 제한적

디지탈 미디어 사용이 이마케터의 조사대로 6시간까지 증가한 것은 데스크탑과 모바일 사용 증가에 따른 것입니다.
그러나 향후 미디어 사용 시간 증가는 제한적일 것입니다. 5년후인 2021년의 매일 매일의 미디어 사용 및 테크 디바이스 사용 시간은 현재에 비해 겨우 18분 증가에 그칠 것입니다. (Over the next 5 years, our daily media and tech consumption will grow by only 18 minutes)

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence006

미디어에서 디지탈 비중은 점점 증가하나 성장율은 둔화

이마케터에 따르면 미디어에서 디지탈 비중은 점점 증가하고 아날로그는 지속 감소할 것입니다.
그러나 디지탈의 성장율도 해를 거듭할 수록 둔화되고 있습니다. (2017년 2% 성장)

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence007

인터넷은 지역적 물리적 경계을 없애고 있음

인터넷은 그동안 기존 미디어 회사들을 보호해왔던 지역적 물리적 장벽을 날려 버리고 있습니다.

이제 모든 회사들은 제한된 사람들의 관심을 끌기 위해서 경쟁하고 있습니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence009

광고주들은 몇개의 빅 파트너와 협력하기를 원하며, 사람들은 역시 몇개의 빅 구독처만을 갖기를 원합니다.

그래서 무슨일이 일어날까요?

미래에는 더 많은 (미디어 회사간) 통합이 일어날 것입니다.

2. 경쟁력 있는 미디어를 가장 편한 방식으로 소비, 공유, 이야기할 것이다.

사람들은 항상 매력적인 이야기와 정보( “미디어”)를 원하며, 가능한 가장 편리한 방법으로 정보를 소비, 공유 및 이야기하고 싶어 합니다.

3. 미디어 증가는 개발도상국에서 활발

앞서 이야기한 미디어가 최고치에 달했다는 평가는 오직 선진국에만 해답하는 이야기입니다. 곧 40억명에 달하는 사람들이 온라인에 합류합니다.

4. 디지탈 광고는 선진국에서도 성장하며, 아시아의 성장이 빠르다.

사실, 아시아-태평양 지역은 조만간 가장 큰 디지털 광고 시장이 될 것입니다.
동쪽을 주시해야 합니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence016

디지털은 글로벌로 확산되고 있습니다. 넷플릭스 가입자의 절반은 이제 미국외 글로벌에서 나오고 있습니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence017

5. 새로운 TV 네트워크가 비디오 보급을 지배할 것

미국에서 기존 유료 TV 가입을 지속적으로 감소할 것입니다. 대부분 예상하는 내용이긴 합니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence019

젊은 층에서 TV 시청이 살아지고 있습니다. 감소하는 게 아닌… 매년 30%~40%씩 감소하고 있으니깐요.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence020

이에 반해서 새로운 TV 네트워크는 빠르게 증가하고 있습니다. 넷플릭스 가입자, 아마존 프라임 멤버쉽, 애플 TV 설치수 그리고 Hulu 가입자가 빠르게 증가하고 있습니다. 특히 2017년에 Hulu의 증가세가 눈부시군요.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence021

새로운 TV 네트워크는 사용하기가 더 편하며 더많은 가격대비 가치를 가지고 있습니다. 그리고 전통 미디어를 발라버리고 있습니다. 예를 들어 애플 TV나 넷플릭스는 AMC같은 전통 케이블 네트웍을 압도하고 있습니다. 또한 유튜브는 광고 매출에서 CBS를 압도하고 있습니다.

  • 디지탈 라디오도 천천히 성장하고 있습니다. 미국에서 2017년 매주 온라인 라디오를 듣는 비율이 53%로 5년전 29%에 비해서 크게 증가했습니다.
    미디어 미래에 대해 알아야 할 14가지 by BI Intelligence026

  • 디자탈 오디오인 Podcast 광고도 급증하고 있습니다.
    미디어 미래에 대해 알아야 할 14가지 by BI Intelligence027

6. 인쇄 미디어의 비디오 미디어로의 전환만이 답은 아니다.

비디오 미디오로 전환이 어려움을 격고있는 인쇄 미디어를 구할 수 있다는 이론은 틀릴지도 모릅니다. The theory that a “pivot to video” will save struggling text publishers is nuts.

7. 미래에 모든 미디어는 곧 비디오가 되는 것은 아니다.

마찬가지로 모든 미디어는 곧 비디오 미디어가 된다는 이론 역시 틀렸습니다. The theory that all media will soon be video is also nuts.

8. 스마트 스피커 및 자가 운전 자동차에서 미디어 사용 증가는 과장 되었다.

스마트 스피커 및 자가 운전 자동차가 미디어 소비를 증가시키겠지만 생각만큼 증가하지는 않을 것입니다.

스마트 스피커 사용자들은 미디어를 더 소비하겠지만 그렇게 많지는 않습니다. 현재 많은 소비는 음악에서 일어나고 있습니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence031

사람들은 1년에 2주에 해당하는 시간을 차안에서 보내지만, 이미 운전자들은 이미 음악을 듣고 있으며, 승객들은 스마트폰으로 미디어를 소비하고 있습니다. 그렇기에 자율운전자동차가 등장해도 미디어 소비가 폭발적으로 증가하지는 않습니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence032

9. AR은 도처에서 구현될 것

AR은 도처에서 구현되고 가상 현실(VR)은 대부분 게임과 교육 훈련에서 활용될 것입니다.

10. “social stories.”에서 거대한 성장 예상

소셜 비디오 시청이 폭발적으로 증가하고 있습니다. 이속에서 “social stories.”가 새로운 종류의 스토리로 확대되고 있습니다.

미디어 미래에 대해 알아야 할 14가지 by BI Intelligence035

11. 광고 독점은 현실이다.

구글과 페이스북에 의한 광고 독점은 새로운 것이 아닌 사실 그 자체입니다.
미디어 미래에 대해 알아야 할 14가지 by BI Intelligence038

거대 광고 배급자는 항상 미디어에서 엄청한 파워를 가지고 있습니다. 그리고 거대 미디어 유통업체는 거대 미디어를 필요로 합니다.
대형 디지털 유통 업체는 이미 콘텐츠 제작자와 실질적인 자본을 공유하고 있으며, 이러한 정도는 매년 강화되고 있습니다.
미디어 미래에 대해 알아야 할 14가지 by BI Intelligence041

12. 광고 유통 플랫폼은 유통 컨텐츠에 책임을 져야.

예전처럼 광고 유통 플랫폼은 유통시키는 컨텐츠에 대해서 책임을 져야 합니다.

13. 이제 혁신적 디지탈 광고가 등장하고 있다.

우리는 마침내 혁신적인 디지털 비디오 광고를 보기 시작했습니다!

  • 스마트폰에서 30초 광고를는 TV에서 한시간짜리 정보를 전달하는 광고 즉 Informercial과 같은 같습니다.

  • 소비자들은 건너 뛸 수 있는(skippable) 짧은 디지털 비디오 광고를 더 잘 수용합니다.

  • 사람들은 관심있는 ‘건너 뛸 수 있는(skippable)’광고만 보면, 어떤 사람들은 이를 끝까지 시청합니다.
    미디어 미래에 대해 알아야 할 14가지 by BI Intelligence045

14. 아직 최적의 디지탈 미디오 광고 모델은 없다.

광고, 구독, 전자상거래 및 하드웨어가 모두 작동하는 최적의 디지탈 미디어 광고 모델은 없습니다.

미디어 미래는 더 한층 좋아질 것입니다. The future of media is getting better all the time.

PDF 보고서

Loader Loading...
EAD Logo Taking too long?

Reload Reload document
| Open Open in new tab

참고 포스팅

2018년 마케터가 주목해야 할 디지탈 트렌드 10가지

미국 미디어 이용 시간 트렌드에서 읽어 보는 시사점

뉴스를 돈내고 보는 시대가 올까? 미국의 미디어 유료 구독 증가에서 얻는 인사이트

[워드프레스 최적화] 구글 페이지스피드 활용, 최고 이미지 포맷 WebP 이용 방법

여기에서는 구글 페이지 스피드를 활용해 가장 효율이 좋은 이미지 포맷이라는 WebP를 활용하는 방법에 대해 알아 봅니다.

여기서 말하는 구글 페이지 스피드는 사이트 성능 평가하는 것이 아닌 구글 프로젝트 하나로 진행되었던 서버 최적화 프로젝트의 이름입니다.

아파치 웹서버에 적용하는 것을 mod_pagespeed라고 부릅니다. 웹서버가 NGINX라면 ngx_pagespeed라고 하죠. 제가 웹서버로 NGINX를 사용하고 있기 때문에 ngx_pagespeed 중심으로 설명드립니다.

그리고 구글 페이지스피드를 설치하지 않고도 WebP를 사용할 수 있는 방법에 대해서는 아래 글을 참조해 보세요.

1. 속도와 트래픽 절약을 위한 이미지 압축에 대한 고민

사이트 운영 시 속도와 트래픽에 대해서 많은 고민을 하게 되는데요.

사이트 속도를 빠르게 한다는 것은 방문자들의 만족도를 높여서 사이트가 활성화되는 기본 요건에 해달되겠죠. 그리고 트래픽이 늘어날수록 서버 처리에 부담을 주니 속도에 영향을 주고 트래픽 비용이 발생합니다.

그래서 이미지를 올릴 시 최대한 압축을 하고 어떤 경우는 보기에 싫을 정도로 압축을 하기도 합니다. 이는 압축이 지나처 컨텐츠의 질을 떨어뜨리는 일이죠.

저는 이미지를 주로 jpg를 사용하고 70%까지 압축을 하고 있습니다. 그러면 대부분의 이미지가 100k이로 줄어들기 때문입니다. 대부분의 아미지 프로그램들은 70%를 하한선으로 잡고 있더군요.

저는 그 하한선까지 압축을 하는 셈이지요. 이 정도 이미지 압축은 일반 사진은 큰 문제가 없는데 글씨가 있는 이미지의 경우는 글자가 많이 흐려집니다.

그래서 적당히 이미지 압축을 해도 충분히 크기를 줄일 수 있는 방법이 있다면 좋겠다는 생각을 했습니다.

그래서 방법을 찾아보니 저의 희망을 어느 정도 채워질 수 있는 방법이 있긴는 하더군요. 바로 webP 이미지 포맷을 이용하는 방법인데요.

이 webP는 기존 jpg에 비해서 30%까지 용량을 줄여 준다고 합니다. 다만 적용되는 브라우저가 제한적이라는 게 약점이죠.

2. webP 이미지 포맷에 대해서

위키는 webP 파일 포맷에 대해 아래와 같이 설명하고 있습니다.

webP(웹피, weppy)는 무손실 및 손실 압축 이미지 파일을 위한 이미지 포맷이다. On2 테크놀러지스의 기술을 구매하여, 그것을 기반으로 구글이 개발하여, 2010년 9월 30일 공개하였다. 영상 포맷인 VP8의 파생으로, 멀티미디어를 담는 포맷인 WebM의 자매 프로젝트이다.
JPEG 파일 포맷은 너무 오래 되어서 구글에서 새롭게 개발 발표한 포맷으로 기존 jpeg보다 30% 더 크기를 줄 수 있다고 한다.

아래는 구글에서 운영하는 webP 설명 사이트에서 jpg 이미지 변환 예를 가저온 것인데요. 43.84KB의 jpg 파일이 29.61KB로 줄었고(32% 사이즈 감소), 86.25KB는 59.18KB(31% 사이즈 감소)로 줄었습니다.
WebP Gallery
참조

▽ webP와 jpg 이미지 변화 비교

webP와 jpg 이미지 변화 비교

이러한 webP 이미지 포맷은 아쉽게도 모든 브라우저에서 지원하는 것은 아닙니다.

2017년 12월 현재 크롬, 오페라, 안드로이드 브라우저, 삼성 인터넷, QQ, 바이두 등이 지원하고 있는데요.

2020년 2월 1일 기준으로 크롬, 엣지, 파이어폭스, 오페라 등등 대부분이 지원하고 IE와 사파리 등 일부만 지원하지 않고 있습니다.

커버리지는 글로벌 전체 브라우저 79% 정도 커버하고 있네요(데스크탑 84%, 모바일 77%)

데스크탑 중심 브라우져보다는 속도를 중요시하는 모바일 브라우저에서 지원이 활발합니다. 모바일을 위해서라도 사용해야겠다는 생각이 듭니다.

애플 사파리는 지원을 검토중이라고 합니다만 가능성이 낮다는 이야기가 있네요. 구글과 경쟁하는 애플이니깐요.

webP를 지원하는 브라우저들 2020년 02월 01알 현재
webP를 지원하는 브라우저들 2020년 02월 01알 현재

3. WebP를 이용하는 방법 – 구글 페이지스피드 사용

그러면 워드프레스에서 어떻게 webP 이미지 포맷을 이용할 수 있을까요?

3.1. 플러그인 사용

워드프레스 플럭인중에서는 webP 이미지 포맷을 지원하는 다양한 플러그인들이 많이 있습니다.
여기서는 간략하게 webP를 지원하는 플러그인을 살펴보겠습니다.

3.1.1. Optimus – WordPress Image Optimizer 플러그인 사용

가장 간단한 방법은 플러그인을 사용하는 방법입니다. 대표적인 플러그인으로 Optimus – WordPress Image Optimizer 를 사용할 수 있습니다. 여기에서 Creation of WebP files에 체크를 하면 이미지가 업로드되면 webP 이미지 포맷으로 변환해 줍니다.

그리고 Optimus – WordPress Image Optimizer 플러그인은WordPress Cache Enabler 에서 Cache 플러그인으로서 webP를 지원하고 있어서 같이 사용하면 좋다고 합니다.

3.1.2. Jetpack에서 Photon 사용

만약 Jetpack을 사용한다면 번들 프로그램중의 Photon service에서 무료로 webP 서비스를 사용할 수 있습니다.
단지 jetpack의 설정 중 Performance & Security에서 Photon을 상요하도록 설정만 하면 됩니다.

3.1.3. ShortPixel + Cache Enabler

ShortPixel Image Optimizer 은 일종의 Freemium 플러그입니다. JPG, PNG, GIF를 압축하는 기능과 JPEG, PNG or GIF 파일을 WebP로 변환해주는 기능을 가지고 있습니다.
다만 월 100장까지는 무료지만 그 이상부터는 5,000 이미지 당 $4,99를 내야합니다.

마찬가지로 이 플러그인도 Cache Enabler와 결합해서 최적으로 사용할 수 있습니다.

3.1.4. EWWW Image Optimizer

EWWW Image Optimizer 도 webP 파일을 지원하는 이미지 압축 플러그인인데요. 스피드 제한이나 파일 사이즈 제한이 없는 플러그인으로 60만명이상이 사용하고 있습니다.

webP를 사용하기위해서는 Conversion Setting에서 jpg/png to webP와 Alternative webP Rewritung에 체크를 해서 사용할 수 있습니다.

3.2. 구글 페이지스피드(ngx_pagespeed) 사용

앞에서 소개한 것처럼 플러그인을 사용할 수 도 있지만 서버단에서 webP 이미지 포맷을 자동으로 만들고 브라우져에 뿌려줄 수 있는 방법이 있습니다.

바로 구글 페이지스피드(ngx_pagespeed) 사용하는 방법이죠. 구글 페이지스피드(ngx_pagespeed)에서는 오래전부터 webP를 지원해왔습니다. 그런데 일부 브라우져에서 일부 파일이 제대로 보여지지 않은 버그가 있었습니다. 저도 이 문제로 사용을 중단했었죠.

그런데 구글 페이지스피드 1.13.35.1-beta 버젼에서 이런 문제를 해결해 배포되었기 때문에 다시 사용하고 있습니다.
여기서는 구글 페이지스피드 1.13.35.1-beta를 어떻게 nginx 서버에 설치하는지를 중심으로 설명드리겟습니다.

우분투 uuid-dev 설치

먼저 uuid-dev를 설치합니다. 갑자기 uuid-dev 설치 이야기가 나오는 것은 이전 페이지스피드 버젼에서는 이게 없이도 설치에 문제가 없었는데요. 구글 페이지스피드 1.13.35.1-beta부터는 설치가 안되더군요.
다른 사람들이 구글에 문의한 내용을 토대로 정리해보면 바로 uuid-dev 설치가 필요하다고 합니다.

uuid-dev 설치는 간단합니다. 아래 명령어만 주면 됩니다.

apt-get install uuid-dev
Code language: PHP (php)

ngx_pagespeed 소스 다운받기

그 다음으로 할일은 ngx_pagespeed 소스를 다운 받습니다.
먼저 최신버젼의 ngx_pagespeed가 무엇인지를 확인합니다.

최신 버젼 확인하기, PageSpeed Release Notes

이에 따르면 201년 12월 30일 현재 1.13.35.1-beta가 최신버젼임을 알 수 있습니다.

그러면 아래와 같은 명령을 순차적으로 입력해 ngx_pagespeed 소스를 받습니다.

NPS_VERSION=1.13.35.1-beta
cd
wget https://github.com/pagespeed/ngx_pagespeed/archive/v${NPS_VERSION}.zip
unzip v${NPS_VERSION}.zip
cd ngx_pagespeed-${NPS_VERSION}/
NPS_RELEASE_NUMBER=${NPS_VERSION/beta/}
NPS_RELEASE_NUMBER=${NPS_VERSION/stable/}
psol_url=https://dl.google.com/dl/page-speed/psol/${NPS_RELEASE_NUMBER}.tar.gz
[ -e scripts/format_binary_url.sh ] && psol_url=$(scripts/format_binary_url.sh PSOL_BINARY_URL)
wget ${psol_url}
tar -xzvf $(basename ${psol_url})  # extracts to psol/
Code language: PHP (php)

Nginx 소스 컴파일 설치

다음으로는 Nginx 최신버젼을 받아 컴파일하는 단계입니다.
여기서도 Nginx 최신버젼이 무엇인지 확인해야 합니다.

최신 버젼 확인하기, nginx Release Notes

2017년 12워 30일 현재, nginx는 1.13.8이 최신 버젼이네요. 아래와 같이 진행합니다.

NGINX_VERSION=1.13.8
cd
wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz
tar -xvzf nginx-${NGINX_VERSION}.tar.gz
cd nginx-${NGINX_VERSION}/
./configure --add-module=$HOME/ngx_pagespeed-${NPS_VERSION} ${PS_NGX_EXTRA_FLAGS}

./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' --add-module=$HOME/ngx_pagespeed-${NPS_VERSION} ${PS_NGX_EXTRA_FLAGS} --with-openssl=../openssl-1.1.0.g  

make
make install
Code language: PHP (php)

webP관련 최적화 세팅

이렇게 ngx_pagespeed 설치가 완료되면 최적화 세팅을 합니다. ngx_pagespeed 최적화 관련해서는 여러 참고 자료들이 있으므로 넘어가기로 하고 webP관련 내용만 추가해 보겠습니다.

webP는 pagespeed가 작동하면 자동으로 사용할 수 있게 됩니다. pagespeed는 대부분의 이미지관련 필수 기능들이 기본 코어에 들어가 있기 때문에 별도 세팅하지 않아도 제대로 작동합니다.
ngx_pagespeed에서 이미지 관련 필터는 아래와 같은 것이 있습니다.

  • rewrite_images ; 기본
  • convert_jpeg_to_progressive ; 기본
  • convert_png_to_jpeg ; 기본
  • convert_jpeg_to_webp ; 기본
  • convert_to_webp_lossless ; 기본
  • inline_images ; 기본
  • recompress_images ; 기본
  • recompress_jpeg ; 기본
  • recompress_png ; 기본
  • recompress_webp ; 기본
  • convert_gif_to_png ; 기본
  • strip_image_color_profile ; 기본
  • strip_image_meta_data ; 기본
  • jpeg_sampling ; 기본
  • resize_images ; 기본
  • resize_rendered_image_dimensions ; 기본
  • extend_cache_images ; 기본
  • convert_to_webp_animated ; 옵션
  • inline_preview_images ; 옵션
  • resize_mobile_images ; 옵션
  • sprite_images ; 옵션

위에서 보는 것처럼 이미지 최적화 관련 필터 대부분은 기본으로 core에 포함되어 있으므로 추가로 옵션으로 추가할 게 거의 없습니다. 저는 convert_to_webp_animated와 resize_mobile_images 정도만 추가해 주었습니다.

다음으로은 이러한 최적화한 옵션 값을 지정해 줍니다.
저는 구글에서 제안하는 값에서 크게 변동 시키지는 않았습니다. 이미지 압축을을 조금 더 높였죠.

    pagespeed CssImageInlineMaxBytes                        0;
    pagespeed CssInlineMaxBytes                          2048;
    pagespeed CssOutlineMinBytes                         3000;
    pagespeed ImageInlineMaxBytes                        3072;
    pagespeed ImageJpegNumProgressiveScans                 -1;
    pagespeed ImageJpegNumProgressiveScansForSmallScreens  -1;
    pagespeed ImageLimitOptimizedPercent                  100;
    pagespeed ImageLimitResizeAreaPercent                 100;
    pagespeed ImageRecompressionQuality                    80;
    pagespeed ImageResolutionLimitBytes              32000000;
    pagespeed JpegRecompressionQuality                     -1;
    pagespeed JpegRecompressionQualityForSmallScreens      70;
    pagespeed WebpRecompressionQuality                     75;
    pagespeed WebpAnimatedRecompressionQuality             70;
    pagespeed WebpRecompressionQualityForSmallScreens      70;
    pagespeed JsInlineMaxBytes                           2048;
    pagespeed JsOutlineMinBytes                          3000;
    pagespeed MaxInlinedPreviewImagesIndex                 -1;
    pagespeed MinImageSizeLowResolutionBytes             3072;
    pagespeed RewriteRandomDropPercentage                   0;
Code language: PHP (php)

아래는 최종으로 ngx_pagespeed 관련 세팅한 값이니 참고하세요.

## enable pagespeed module on this server block
    pagespeed on;              

    ## Cache setting
    pagespeed FileCachePath /var/ngx_pagespeed_cache;
    pagespeed FileCacheSizeKb            1024000000;  # cache를 적용 후 다 차면 비운다
    pagespeed FileCacheInodeLimit        50000000;
    pagespeed CssFlattenMaxBytes       102400;
    pagespeed LRUCacheKbPerProcess 8192;
    pagespeed LRUCacheByteLimit 16384;

    pagespeed DefaultSharedMemoryCacheKB 50000;

    ## Speed up PageSpeed by storing it in the super duper fast memcached
    pagespeed MemcachedThreads 1;
    pagespeed MemcachedServers "localhost:11211";

    ## PageSpeed Cache Purge
    pagespeed EnableCachePurge on;
    pagespeed PurgeMethod PURGE;
    pagespeed DownstreamCacheRewrittenPercentageThreshold 95;

    # needs to exist and be writable by nginx 755로 되어 있음 
    # cache 비우는 방법 Flushing PageSpeed Sever-ide Cache
    # rm -rf /var/ngx_pagespeed_cache/* or touch /var/ngx_pagespeed_cache/cache.flush
    # service nginx restart

    ## Filter settings
    pagespeed EnableFilters responsive_images ;
    pagespeed EnableFilters convert_to_webp_animated ;    
    pagespeed EnableFilters resize_mobile_images ;
    pagespeed EnableFilters lazyload_images;    
    pagespeed EnableFilters move_css_above_scripts;
    pagespeed EnableFilters outline_css ;
    pagespeed EnableFilters outline_javascript ;
    pagespeed EnableFilters defer_javascript;  # 페이지 로딩 완료 시까지 자바 실행 지연    
    pagespeed EnableFilters remove_quotes ;
    pagespeed EnableFilters collapse_whitespace;
    pagespeed EnableFilters insert_dns_prefetch; # DNS resolution time 축소
    pagespeed EnableFilters in_place_optimize_for_browser ;

    # 이미지관련 대부분이 Core에 기본으로 들어가 있음, 사용하지 않으려면 비활성화 해야 함 예를 들어 pagespeed DisableFilters convert_to_webp_animated; 기본 rewrite_images, convert_jpeg_to_progressive, convert_png_to_jpeg, convert_jpeg_to_webp, convert_to_webp_lossless, inline_images, recompress_images, recompress_jpeg, recompress_png, recompress_webp, convert_gif_to_png, strip_image_color_profile, strip_image_meta_data, jpeg_sampling, resize_images, resize_rendered_image_dimensions, 

    pagespeed AnalyticsID UA-64766674-1;
    pagespeed EnableFilters make_google_analytics_async,make_show_ads_async;

    ## Tuning the Filters

    pagespeed CssImageInlineMaxBytes                        0;
    pagespeed CssInlineMaxBytes                          2048;
    pagespeed CssOutlineMinBytes                         3000;
    pagespeed ImageInlineMaxBytes                        3072;
    pagespeed ImageJpegNumProgressiveScans                 -1;
    pagespeed ImageJpegNumProgressiveScansForSmallScreens  -1;
    pagespeed ImageLimitOptimizedPercent                  100;
    pagespeed ImageLimitResizeAreaPercent                 100;
    pagespeed ImageRecompressionQuality                    80;
    pagespeed ImageResolutionLimitBytes              32000000;
    pagespeed JpegRecompressionQuality                     -1;
    pagespeed JpegRecompressionQualityForSmallScreens      70;
    pagespeed WebpRecompressionQuality                     75;
    pagespeed WebpAnimatedRecompressionQuality             70;
    pagespeed WebpRecompressionQualityForSmallScreens      70;
    pagespeed JsInlineMaxBytes                           2048;
    pagespeed JsOutlineMinBytes                          3000;
    pagespeed MaxInlinedPreviewImagesIndex                 -1;
    pagespeed MinImageSizeLowResolutionBytes             3072;
    pagespeed RewriteRandomDropPercentage                   0;
Code language: PHP (php)

참고

이미지 최적화 관련 괜찮은 솔류션들은 대부분 유료로 제공되고 있습니다.

서버를 운영한다면 무료로 어느 정도 성능이 좋은 임지 최적화 시스템을 구축하는 것이 가능합니다. 아래는 그 방법에 대해서 간략 정리한 내용이니 참고하시기 바랍니다.

혹시 서버를 고민하신가요?

안녕하세요?

저는 Vultr를 사용하고 있는데요. 혹 신규로 서버 구축을 고민하신다면 Vultr도 검토해 보시라고 권해드립니다.

저는 2016년부터 Vultr을 사용했는데 큰 불만없이 잘 사용하고 있습니다. 아래 사용기도 한번 보시구요.

한국과 일본 서버 중에서 리노드나 AWS도 좋은 대안이지요. Vultr도 장점이 많은 VPS이고 대안으로 검토해볼만합니다. 성능면에서 괜찮다고 생각합니다.

혹시 Vultr에 관심이 있다면 아래 리퍼럴 링크를 이용해 보세요. 신규 계정을 등록 시 10$을 받을 수 있는 제휴 링크입니다.

[워드프레스 최적화] 구글 페이지스피드 활용, 최고 이미지 포맷 WebP 이용 방법 6

벤처투자 한푼없이 5억불 회사로 키운 이메일 왕국, 메일침프(Mail Chimp) 이야기

6

Executive Summary

메일침프는 2001년 Ben Chesnut과 Dan Kurzius가 창립한 이메팅마케팅 솔류션제공 회사입니다.
현재 대다수 뜨고있는 스타트업기업과 달리 벤처투자를 절대 받지않고 스스로의 힘으로 중견기업에 올라 관심을 받고 있죠.

이 메일침프에서 배울 수 있는 시사점을 아래 4가지로 정리해 봤습니다.

  • 첫째, 작은 회사가 커가는 것을 도와준다는 창업 철학에 따라 이메일마케팅 수용 가능성이 높은 중소 기업을 타겟으로 비지니스르 시작했고, 벤처투자사의 유혹(대기업 중심으로 바꾸어 성장을 촉진시키자.)에도 불구하고 초지일관 중소기업을 타겟으로 비지니스 추진

  • 둘째, 쉽고 재미있게 사용할 수 있는 전문 이메일마케팅 솔류션 브랜드로 포지셔닝

  • 셋째, 일정조건까지는 평생 무료로 서비스 이용하다 유료로 업그레이드하는 Freemium프로그램으로 1년내 5배이상 사용자를 늘리고 판매 및 이익이 크게 개선, 도약할 수 있는 계기를 만듬

  • 넷째, 브랜드 정체성에 맞추어 펀마케팅(Fun Marketing)으로 강력한 구전 효과를 일으키는 바이럴 마케팅에 집중

1. 메일침프 시작

메일침프 경영진 Ben Chestnut2001년, 메일침프를 시작할 당시 공동창업자인 Ben Chesnut과 Dan Kurzius는 웹 디자인 컨설팅 비지니스 회사를 운영하고 있었습니다.
그러다가 고객들에게 메일 을보내는 방법에 대한 문의가 잇다르자 공동창업자 Ben Chesnut는 예전에 시도하다 보류했던 Greeting Card Projest 프로그램을 활용해 메일 t시스템을 구축하고 고객 요청에 따라 메일을 보내기 시작했습니다.
즉 원래는 연하장을 보내기 위해 만들려다 버려둔 프로그램을 다시 개선해 이메일 마케팅 솔류션으로 변화시킨 것이죠.

처음에는 웹 디자인 컨설팅 비지니스를 중심으로 하면서 이메일 마케팅 비지니스는 부가적인 작업으로 여겼습니다.
그러다 웹 디자인 컨설팅 비지니스에 대한 회의가 점점 커지고면서 이 비지니스에 대한 열정을 잃으면서 2007년 웹 디자인 비지니스를 중단하고 이메일 마케팅에 전념하기로 합니다.
이렇게 이메일 마케팅에 전념하기로 한것에 대한 공동 창업자 Chesnut은 뉴욕타임즈 기사 Monkey Business: The Story Behind MailChimp’s Wild Growth에서도 밝혔듯이 소규모 기업들이 커가도록 도와주는 것에 더 열정을 느꼈기 때문이라고 밝혔습니다.

그러나 2007년 당시 이메일 마케팅 상황은 좋지는 않았습니다. 먼저 당시 인터넷업계 사정을 살펴보면 스팸 메일이 유례없이 급증해서 소비자들은 이 스팸 메일 때문에 골머리를 앓고 있었습니다. 당시 한 조사 결과에 따르면 당시 메일의 95%는 스팸 메일이었다고 합니다. 이 조사 결과를 보면 스팸 메일이 어느 정도 극성을 부리고 있었는지 알 수 있습니다.

제가 기억하기는 이러한 스팸 메일은 한국에서도 이메일서비스의 경쟁구도를 완전히 바꾸어놓았습니다.먼저 한국에서도 개인 차원에서의 이메일 무용론이 대두되면서 많은 사람들이 개인 메일을 거의 사용하지는 않게 되었습니다. 그리고 메일 사용은 이런 스팸 메일을 피할 수 있는 메일로 변경하게 되면서 메일 서비스 경쟁 구도가 변하게 됩니다. 그동안 한메일 및 네이버 메일이 주류였다면 GMAIL이 새로운 다크호스로 떠오른 것이죠. 저도 이 당시 사용하던 다음이나 네이버 메일에 온갖 스팸 메일만 잔뜩 쌓여 있어서 메일함을 열어 보기가 겁났던 기억이 납니다. 이러한 스팸 때문에 당시 제대로 스팸을 제대로 걸려준다고 알려진 gmail로 변경해 사용하게 되었죠. 이렇게 GMAIL은 스팸과의 전쟁이라는 환경하에서 새로운 강자로 떠오르게 되죠.

또 이메일마케팅 업계에서 가장 강력한 경쟁 상대였던 Constant Contact이 $107M에 IPO를 성공하는 등 경쟁업체들이 투자를 받아 성장하면서 시장을 지배하고 있었다는 점입니다.

이렇게 스팸 메일로 소비자들이 진절머리를 내고 있던 시절이라 이메일 마케팅에 대한 전망이 썩 좋지는 않았고, 이미 경쟁자들이 시장을 장악하고 있는 열악한 경쟁 환경이지만 공동창업자 Chesnut과 Kurzius는 이메일이 비용 대비 효과가 뛰어나 중소기업들이 성장하는데 도움이 되는 마케팅 채널이 될거라는 점을 간파했기 때문에 사업을 밀어 부칠 수 있었습니다.

2017년 메일침프는 임직원 700명에 연간 매출 5.3억불, 1천 6백만 고객을 가진 거대한 이메일 왕국으로 성장했습니다.

메일침프는 아직 상장하지 않았기 때문에 매출 등 모든것이 거의 공유되지 않고 있습니다. 언론등 오픈된 자료를 토대로 연도별 매출 그래프 구성했습니다. 언론등에서도 추정한 자료들이니 단지 경향만 보기위해 참조하시기 바랍니다. (물론 여기엔 메일침프에서 밝힌 자료도 일부 포함되어 있습니다.)

▽ 메일침프 매출액 추이,
2015년 ~ 2017년은 언론 보도자료 기반,
2010년 ~ 2014년은 인터넷 추정치로 근거 빈약해 수치 표기 하지 않음

메일침프 매출액 추이 Mailchimp revenue

2. 매일침프에서 배우는 시사점

그러면 메일침프에서 배울 수 있는 시사점에는 무엇이 있을까요? 솔직히 혜성같이 나타나 엄청난 성공을 구가한 많은 성공 사례에 비추어보면, 메일침프는 성공 사례라 칭하기에는 약할지도 모르겠습니다.
벌써 17년차의 회사인데 매출은 겨우(?) 5억불을 넘는 정도이니 굉장히 천천히 성장해 온 회사라고 할 수 도 있습니다.

그러나 이 회사는 다른 스타트업이 다 하는 벤처투자를 거절하고 메일침프 혼자의 힘으로 여기까지 왔다는 점에서 다소 느릴지 모르지만 배울 꺼리가 많습니다.

저는 메일침프에서 배울 수 있는 시사점으로 작은 회사가 커가는 것을 돕는다는 경영철학에 맞추어 이메일마케팅 가능성이 높은 중소기업으로target의 설정 및 (벤처투자자들의 유혹에도 불구하고)이를 끝까지 고수해 경쟁력의 원천으로 삼았다는 점, 전문가이면서도 재미있고 편한 이미지로 메일침프 브랜드 빌딩, Freemium 비지니스 전략, 바이럴 마케팅의 4가지로 정리해 보았습니다.

2.1. Target의 적정성 – 창업 철학에 맞춰 경쟁력 있는 중소기업으로 target 설정

스타트업 관점에서 보면 메일침프는 디자인 컨설팅 비지니스를 하다가 이메일마케팅 솔류션 비지니스로 업종을 전환하는 피벗팅을 한 사례이므로 시작부터 업계를 흔들 기술력 또는 마케팅력 등이 거의 없는 상태에서 시작할 수 밖에 없었습니다.

그래서 메일침프는 비지니스 대상을 면밀하게 고심해 선장했는데요. 바로 중소기업을 타겟으로 삼았습니다.

이렇게 중소기업을 타겟으로 잡은 이유는

  • 첫째, 공동창업자인 Ben Chesnut과 Dan Kurzius은 작은 회사가 커가는 것을 지원하는 것에 열정을 느꼈고 이를 창업의 근본으로 삼았기에그들의 사업 타겟은 당연 중소기업이 제격이었기 때문이죠.

  • 둘째, 메일침프는 경쟁사애 비해서 중소기업에 대한 고객 근접성이 뛰어 나다고 판단했습니다. 메일침프 자체가 작은 중소기업이었기에 주요 타겟인 중소기업에 대해서 그들이 무엇을 필요로 하는지를 잘 알수 있고, 이를 기반으로 중소기업에 맞는 눈높이로 다가 갈 수 있고, 중소기업이 원하는 마케팅 서비스를 제공할 수 있고, 그들에 맞추어 가격도 저렴하게 맞출 수 있다는 자신감이 있었기 때문입니다.

  • 셋째, 이미 주식시장 상장하거나 상장을 준비하는 경쟁사들은 규모가 커져서 민첩성이 떨어지며, 그들은 규모의 경제를 노려 대기업이나 중견기업을 중심으로 비지니스를 강화하고 있었습니다. 메일침프로서는 (경쟁력을 충분히 갖추기 전에는) 직접 경쟁을 회피하는 게 나은 전략이기 때문입니다.

  • 셋째, 마케팅 비용 한계가 있는 중소기업은 비용 대비 효과를 매우 중요시하므로 비용 대비 효과가 큰 이에일마케팅에 대한 수요가 중소기업군에서 커질 것으로 보았습니다.

이러한 중소기업 중심의 비지니스는 처음에는 어려웠고 성장도 느렸지만 점차 수요가 늘고 메일침프의 Freemium 전략이 먹히면서 도약할 수 있었습니다.

한편 경쟁 회사들이 상장되면서 메일침프도 VC들의 투자 제의를 많이 받았는데요. 메일침프는 이런 VC들은 현재의 중소기업 중심 비지니스보다는 대기업 중심 비지니스로의 전환을 권하고 대기업 중심이라서 받아드릴 수 없었다고 이야기 합니다.

“중소규모의 회사를 이해하는 투자자를 지금까지 만난 적이 없습니다. 벤처투자자들은 항상 메일침프(MailChimp)가 엄청난 수익을 가져다 줄 대기업 을 위한 서비스를 제공하기를 원했습니다.
모두가 우리에게 ‘지금 금광 위에 앉아 있는 거나 다름없다. 만약 사업 방향을 대기업 대상으로 전환하면, 엄청난 성공을 거둘 수 있다’고 말한다. 하지만 우리 내면의 무언가는 그것이 좋은 방향이 아니라고 항상 말합니다.”고 메일침프 공동창업자이자 CEO인 Ben Chesnut은 이야기합니다. – MailChimp의 “실리콘밸리스럽지 않은” 이야기에서 인용

VC의 투자를 거절하고 중소기업과 긴 호흡으로 비록 조금 느리지만 차근차근 성장해온 것이 메일침프가 걸오 온 길입니다.

▽ 메일침프 초기 웹사이트,
이 디자인은 거의 5년동안 그대로 유지되었다고 한다.

5년동안 유지되었던 메일침프 초기 웹사이트 디자인

2.2. 메일침프 브랜딩 – 쉽고 재미있게 사용할 수 있는 전문 이메일마케팅 솔류션 브랜드

메일침프를 성공으로 이끈 것 중의 하나는 메일침프라는 쉽고 재미있게 사용할 수 있는 전문 이메일마케팅 솔류션 브랜드라는 이미지를 확실하게 세웠다는 점이 아닐까 합니다.

벤처투자 한푼없이 5억불 회사로 키운 이메일 왕국, 메일침프(Mail Chimp) 이야기 7이 메일침프의 Freddie라는 사랑스러운 브랜드 마스코트로 기억하기 쉽고 재미있게 사용할 수 있는 브랜드 이미지를 만들 수 있었고 짧은 시간내에 인지도를 빨리 올릴 수 있게 해 주었습니다.

메일침프라는 브랜드는 원숭이를 주제로 코믹하게 시작하고자 하여 처음에는 침프메일이라는 브랜드를 검토했습니다. 그러나 이미 브랜드 및 도메인이 선점당해 결국 메일침프로 바꾸었습니다.

메일침프는 브랜드 이름 자체의 재미있는 요소를 적극 브랜딩에 활용했습니다.
2014년에 전개한 “Did You Mean MailChimp?” 캠페인은 칸 광고제에서 대상을 수상하는 등 마케팅 효과를 톡톡히 누리며 메일침프 인지도 향상에 큰 기여를 했습니다.
메일침프 로고 Mailchimp logo

또 메일침프 마스코트 Freddie는 가장 기억하기 쉽고 귀여운 마스코트를 가진 브랜드 중의 하나로 만들었습니다. Freddie는 (FullName : Frederick von Chimpenheimer 4)의 약자인데요. 이 마스코트는 여러 마케팅 단계에서 적절하게 사용되면서 메일침프 브랜드 이미지를 쉽고 재미있고 고객에게 진실한 브랜드라는 이미지를 심어 왔습니다.
예를 들어 캠페인 메일링을 보내기 전 로켓 발사 버튼이 나타나 발사할 준비가 되었는지를 묻고 발사 버튼을 누르면 로켓이 쏘아지듯이 메일이 발송되도록 했습니다.
벤처투자 한푼없이 5억불 회사로 키운 이메일 왕국, 메일침프(Mail Chimp) 이야기 8

그리고 캠페인 발송이 끝나면 임무를 완수했다는 메세지와 함께 하이파이브하는 GIF 영상을 보여줍니다. 이런 재미있는 과정을 통해서 메일침프에서의 메일링은 마치 바나나를 먹는것처럼 쉽고 재미 있어 메일링은 억지로 마지못해 하는 잡일이 아니라 고객과 만나는 신나는 경험이라는 의미를 부여했습니다.

메일침프 발송 후 보여주는 하리파이브 Mailchimp hifive

메일침프는 이렇게 고객에게 브랜드 정체성을 전달하는 매우 정교한 가이드라인을 운영하고 있습니다.
예를 들어 MailChimp Contents style Guide를 보면 고객에게 전달하는 경험에 그들의 보이스와 톤을 알려주고 있습니다. 무엇을 해야하고 무엇을 하지 말아야 하는지를요. 예를들어 아래와 같은 것입니다.

  • Fun but not silly, 즐겁게 그렇지만 실없지 않게
  • Confident but not cocky, 자신감 있게 그렇지만 건방져 보이지는 않게
  • Smart but not stodgy, 똑똑하게 그렇지만 거부감이 들지 않게
  • Informal but not sloppy, 너무 형식에 얽매지않지만 너무 너절하지 않기
  • Helpful but not overbearing, 도움이 되지만 결코 억압적으로 보이지는 않게
  • Expert but not bossy, 전문가지만 너무 가르치는 상사처럼 굴지 않기,
  • Weird but not inappropriate, 기묘하지만 부적절하지는 않게 (해석이 잘 안되긴하지만 매일침프가 추구하는 즐겁게 접근이 고객에게는 다소 이상하게 보일 수 도 있다는 것을 의미하지 않을까 추정합니다. )

쉽고 재미있는 브랜드로서 메일침프를 만드는 것은 이러한 마케팅 활동에서 뿐만이 아니라 사내 문화를 펀(Fun)하게 만들면서 브랜드 정체성(아이덴티티)이 회사 경영 전반에걸처 자연스럽게 발현되도록 했습니다.

아래는 메일침프 인스타그램에 올라온 메일침프 사내의 풍경입니다.사내에서 킥보드를 타면서 즐겁게 근무하는 모습을 보여주고 있는데요. 이처럼 체화된 브랜드 정체성이 소비자에 다가가는 여러 경로를 통해서 자연스럽게 스며들어 시너지를 내는 것으로 보입니다.

이러한 브랜드 빌딩을 통해서 메일침프는 이메일 마케팅의 전문 솔류션 브랜드지만 (경쟁사처럼) 건방지고 딱딱한 이미지가 아닌 친구같고 따뜻하게 느끼는 브랜드로 만들었습니다.

2.3. Freemium 전략

2009년 9월 1일 메일침프는 전격적으로 Freemium 프로그램을 도입 합니다. 그 당시까지 무료로 서비스를 제공하겠다는 개념자체가 없었는데 과감하게 일정 조건 동안 무료로 사용하게 한 것이죠.

즉 고객수 500명, 한달 3000개의 이메일 발송서비스를 평생 무료로 제공하겠다는 것이었는데요. 업계에서 처음 시도하는 무료 프로그램으로 상당히 반응이 좋았습니다. 처음 무료로 시험삼아 써보다가 사업이 발전하고 고객수가 늘어나면 유료 플랜으로 전환하리라는 것을 염두에 둔 전략이었죠.
뒤에도 나오겠지만 Freemium으로 사용하다 유료 플랜으로 전환하는 비율은 약 10%를 넘는다고 합니다. 90%에 달하는 무료 사용자들이 경영에 방해가 되었을까요? 이렇게 대대적인 Freemium을 실시해도 그 비용 이상으로 유료로 전환되기 때문에 1인당 고객 유치비용(CAC, Counsumer Acquation Cost)이 오히려 감소했다고 합니다.

이 Freemium 프로그램은 발전을 거듭해(아마 경쟁사들이 따라왔기 때문에) 지금은 2,000명의 고객에 월 12,000개의 메일까지는 무료로 사용할 수 있도록 업그레이드 되었습니다.

▽ 메일침프 CEO Chesnut의 reemium 프로그램 발표 내용

메일침프 Freemium 프로그램 발표

▽ 초기 메일침프 Freemium 프로그램이 포함된 가격 운영 테이블

메일침프 Freemium 프로그램이 포함된 가격 운영 테이블

위와 같은 인원수에 따른 가격 테이블은 2014년부터 좀 더 단순화된 옵션테이블로 바뀌었습니다. 즉 아래와 같이 크게 세가지 가격 플랜으로 변경된 것이죠.

  • 2014/2015 – Entrepreneur / Growing Business / High Volume Sender

  • 2016 – Starting Up / Growing Business / Pro Marketer

  • 2017 – New Business / Growing Business / Pro Marketer

▽ 2017년 메일침프 Freemium 프로그램이 포함된 가격 운영 테이블

2017년 메일침프 Freemium 프로그램이 포함된 가격 운영 테이블 최근

이 Freemium 프로그램의 효과에 대해서 메일침프 공동창업자 Ben Chesnut은 메일침프를 본격적으로 성장시킨 계기가 되었다고 이야기 하고 있습니다.

그는 그 성과에 대해서는 메일침프 블로그에 Going Freemium: One Year Later라는 포스팅을 통해서 자세히 설명하고 있습니다.

이 프로그램을 시작한 2009년 9월부터 1년후인 2010년 9월을 비교해 보면 아래와 같이 정리할 수 있습니다.

  • 메일침프 사용자가 8.5만명에서 45만명으로 5배 증가 (2012년 2월엔 120만으로 증가)

  • 매월 30,000명의 신규 사용자가 증가했으며, 유료 사용자는 매월 4,000명씩 증가

  • 전체 유료 사용자는 1년간 150% 증가했으며 이익은 650% 증가

  • 이익이 증가한 고객 유치비용(CAC, Customer Acquisition Cost)이 8% 감소해 $100이하로 내려갔기 때문

이러한 Freemium 프로그램 적용에 따라 메일침프릐 사용자가 어떻게 증가하고 있는지를 보여주는 그래프입니다.
사용자가 10만명을 넘기엔 8년이 걸렸지만 Freemium 프로그램 적용 후엔 100만 사용자 돌파에 2년이 걸렸고, 200만 사용자 돌파에는 겨우 10개월만 소요되었습니다.

▽ 메일침프 사용자 증가 추이

메일침프 사용자 증가 추세 Mailchimp user growth

2.4. 바이럴 마케팅 캠페인 Fun Marketing

다음으로 살펴볼 것은 메일침프의 마케팅입니다. 메이침프의 마케팅은 펀하고 독특해서 금방 눈에 띄고 쉽게 기억에 남을 수 있는 것들입니다.

앞서 메일침프의 브랜드 정체성중의 하나가 Fun이라고 했는데요. 이런 브랜드 정체성을 제대로 살리면서 메일침프를 잘 알리는 캠페인들이 메일침프의 성장에 기여하는 것으로 보입니다.
최근의 대표적인 2가지 캠페인을 소개해 봅니다.

2014년 “MailKimp” – 가장 뛰어난 podcast 광고중의 하나

Mailchimp를 잘못 발음하는 것을 소재로 삼아 만든 popcast에서 진행한 광고로 메일침프는 미국에서 가장 유명하고 인기있는 popcast인 Serial을 후원하면서 이 광고를 활용했습니다. Mailchimp를 발못 발음하는 여러 사례를 아주 재미있는 음악으로 만들어 아주 인기를 끌었으며 이 팝캐스트의 한 에피소드당 백만명 이상이 청취하는데 조사에 의하면 95%의 청취자들은 이 광고를 메일 서비스하는 mailchimp로 인지했다고 합니다.

  • Speaker #1: Support for Serial comes from MailChimp
  • Speaker #2: From MailChimp
  • Speaker #3: Mail…kimp? Chimp?
  • Speaker #4 (host of the podcast): More than 7 million businesses around the world….
  • Speaker #5: ….use MailChimp…
  • Speaker #6: ….to send emails, newsletters, and deliver high-fives
  • Speaker #4 (host of the podcast): MailChimp! Send better email.
  • Speaker #7: (quietly) Very nice!
  • Speaker #4 (host of the podcast): I use MailChimp
  • Speaker #7: You do!?
  • Speaker #4 (host of the podcast): I love it

이 광고를 아예 리믹스 음악으로 만들었습니다. 댓글들을 보면 알겠지만 반응이 폭발적이군요.

2017년 Did You Mean MailChimp? – 칸느 광고제 수상작

2014년 popcast 광고가 큰 인기를 얻으면서 이를 적극적으로 활용한 광고 캠페인을 전개했습니다.

이 캠폐인은 3.8백만회 검색을 유도했으며, 7억 7천만회 노출 되었으며 3.5백만회나 미디어에 소개되었으며, 2017년 칸느 광고제 사이버부분에서 그랑프리를 받았습니다.

▽ Did You Mean MailChimp? 캠페인을 간략 정리한 동영상

메일침프가 진행한 다양한 주제의 광고 커뮤니케이션, 아티스트와 콜라보에서 패션쇼까지 다양한 기법들이 동원되었습니다.

▽ Did You Mean MailChimp? 캠페인의 다양한 주제 List,
이미지 출처 – sumo.com

메일침프 캠페인 mailchimp did you mean

영상 광고 중 가장 반응이 좋은 것중의 하나였던 Mailshrimp 유튜브 영상

이 또한 옥외 빌보드나 지하철 광고, 인스타그램 포스팅 등 다양한 커뮤니케이션 채널을 통해서 진행 되었습니다.

▽ 제반 커뮤니케이션 채널별 광고 모습,
이미지 출처 – sumo.com

메일침프 캠페인 mailchimp did you mean 02

3. 마치며

메일침프는 17년차에 접어들지만 본격적인 성장은 2010년부터 시작되었고 할 수 있습니다. 그리고 매출등이 유의미한 규모로 성장한 것은 최근의 일입니다.
이러한 최근의 성장에 따라 2016년에는 포브스 선정 Forbes Cloud 100대 기업 중 7위에 랭크되기도 했고 미디어의 집중적인 스포트라이트를 받았습니다.

또한 2017년에 Inc.에서는 올해의 기업으로 메일침프를 선정하고 상당히 자세한 메일침프에 대한 케이스스터디를 실었는데요. 한번 읽어볼만 합니다.

Want Proof That Patience Pays Off? Ask the Founders of This 17-Year-Old $525 Million Email Empire

이외 아래 글들에서 많은 인사이트를 얻었습니다. 같이 읽으면 좋을 것 같네요.

Monkey Business: The Story Behind MailChimp’s Wild Growth

The Newyork Times, MailChimp and the Un-Silicon
Valley Way to Make It as a Start-Up

4. 관련 포스팅

이메일은 죽었을까? 역설적으로 가장 중요한 마케팅 채널이 되고 있는 이메일 마케팅!!

요즘 핫하다는 화장품 브랜드 글로시에(Glossier)의 이메일 마케팅 캠페인 사례

[이메일마케팅] 개인과 스타트업이 사용하기 좋은 이메일마케팅 서비스 – 메일침프(MailChimp)

버즈피드 미래 전략 – 멀티 수익 모델 창출을 위한 9개 전략 매트릭스

0

디지탈 미디어 부분에서 새로운 영역을 개척해 온 버즈피드가 날로 격심해지는 경영 환경 그리고 구글 및 페이스북으로 대표되는 거대 광고 테크 기업의 독점의 심화속에서 위기를 느끼고 있나 봅니다.
이러한 어려움 속에서 버즈피드가 나아갈 전략 방향을 버즈피드 CEO Jonah Peretti(조나 페레티)가 버즈피드 포스팅을 통해 제시하고 있는데요. 9 Boxes, Building out our multi-revenue model
영어 공부겸해서 번역해 보았습니다. 구글의 힘을 빌었고 문맥이 거칠어지는 부분을 중심으로 의역을 했습니다.

버즈피드 CEO Jonah Peretti(조나 페레티)는 회사의 전략 방향을 종종 버즈피드 포스팅으로 올려 공유하곤 했는데요. 이번 포스팅도 버즈피드의 컨텐츠를 풍부하게하고(뭐 CEO가 포스팅하나 올렸다고 컨텐츠가 풍부해 지겠나고 생각할 수도 있지만 잘 나가는 미디어 신생기업의 CEO가 던지는 메세지는 결코 가볍지는 않기에 어느 정도 효과는 있을 것 같습니다.), 버즈피드의 전략을 멸확히 내외에 공표하면서 신뢰를 쌓을 수 있는 전략으로 보입니다.

참고로 2020년 전략을 소개한 포스팅도 참고하세요.

버즈피드 2020년 전략에서 읽어보는 디지탈 미디어 트렌드

Executive Summary

버즈피드 CEO Jonah Peretti(조나 페레티)가 이글에서 밝히고자하는 내용을 나름대로 간략 정리해 봅니다.

  • 페이스북, 구글의 광고 독점이 강해지면서 미디어가 제반 가치를 제대로 평가 받지 못하면서 위기에 빠지고 있다.
  • 버즈피드는 이런 거대 테크 기업과 관계를 정상화하기 위해 싸울 것이며 관계를 정상화하기 위해 최선을 다할 것이다.
  • 이러한 싸움의 최대 무기는 양질의 컨테츠이므로 버즈피드는 양질의 컨텐츠를 만드는데 주력하겠다.
  • 기존의 단선적인 비지니스 모델로 수익을 늘리는 것은 한계가 있다. 따라 버즈피드는 영위하는 여러 부문과 영역을 묶어 상호 시너지를 내면서 수익을 올리는 Multi Revenue Model을 강화하겠다.
  • 버즈피드 내에서 성공적인 role model은 Tasty이다. Tasty 방식을 전 버즈피드 사업군에 적용하고 기존 성공적인 브랜드들을 기반으로 강력한 디지탈 브랜드 포트폴리오를 구축하겠다.
  • 디지탈 브랜드 포트폴리오 구축과 비지니스 매트릭스간 교차점에서 새로운 수익원을 만들 수 있는 미래를 위한 조직을 만들겠다.

버즈피드 CEO Jonah Peretti(조나 페레티)의 기고문 전문

버즈피드 CEO jonah peretti(조나 페레티)버즈피더 여러분, 안녕하세요

버즈피드는 2017년 매출과 독자 증가에서 신기록을 세웠습니다 그러나 쉽지는 않았습니다.

미디어는 위기에 처해 있습니다. 구글과 페이스북이 대부분의 광고 수익을 차지하고 있으며, 이들이 컨텐츠의 가치에 비해 컨텐츠 제작자들에게 지불하는 비용은 너무 적습니다. 이는 고품질 컨텐츠 제작자들을 재정적으로 힘들게 하고, 가짜 뉴스, 선동 및 음모론, 선정주의적 스핀으로 복제한 스토리, 음성적으로 만든 컨텐츠, 알고리즘으로 생성된 컨텐츠 및 불법 복제된 동영상과 같은 값싼 미디어를 선호하는 결과를 낳고 있습니다.

경제적, 정치적 양극화가 한층 깊어지고, 우리 모두 공유하는 현실 인식이 깨어질 때 이러한 현실 경제적인 어려움은 우리 사회에 커다란 위협으로 다가 옵니다. 거대 기술 플랫폼은 우리 자신만의 세계에 갖혀 살도록 강요하는 개인화된 미디어 버블을 만들고 있습니다. 반면 전통적인 미디어 회사들은 풍부한 구독자를 기반으로 기존 엘리트 중심 세계관을 강화하고 있습니다.
우리의 미디어 생태계는 갈수록 파편화되고 있으며, 그 결과로 일반 대중들은 고품질의 저널리즘과 흥미 진진한 엔터테인머트로부터 점점 멀어지고 있습니다. 민주주의와 문화의 미래는 이러한 문제를 해결혀는 언론사와 플랫폼에 달려 있습니다.

가장 큰 독립적인 디지탈 미디어 기업으로서, 우리는 이러한 문제와 결부되어 있습니다. 그것은 우리 사업에 부담을 주지만, 우리가 유리하게 작용할 수 있습니다. 우리 사업이 직면한 문제를 해결하기 위해 우리는 미디어 생태계를 재구성하고 사회에 긍정적이고 지속적인 영향을 미칠 수 있는 기회를 잡았습니다. 오늘 미디어 업계의 발전과 번영을 위한 우리의 계획을 알려드리고자 합니다.

미디어와 테크놀로지 간의 관계 변경, Fixing the Relationship Between Media and Tech

첫째, 우리는 미디어와 거대 테크 플랫폼간의 관계를 개선 할 수 있는 기회를 얻었습니다. 최첨단 테크 플랫폼은 품질이 낮고, 불쾌하고 악의적인 콘텐츠로 어려움을 겪고 있는 동안, 전문 콘텐츠 공급자들은 그들의 컨텐츠에 공정한 댓가를 받기 위해 애쓰고 있습니다. 이와 관련된 문제를해결하는 간단한 방법이 있습니다. : (거대 테크)플랫폼은 가치 있는 컨텐츠에 댓가를 지불해야합니다. 디지털 미디어 생태계를 고치는 것은 모든에게 이득이기 때문에 이러한 변화는 불가피 합니다. (거대 테크) 플랫폼은 더 나은 컨텐츠를 얻고, 미디어 산업은 지속 성장 가능한 다양한 디지탈 비지니스모델을 확보하고 일반 대중은 양질의 뉴스와 엔터테인먼트를 즐기게됩니다.

우리는 이러한 변화를 보기 시작했지만, 공정한 분배를 얻기 위해서는 열심히 싸워야 합니다. 양질의 콘텐츠를 만드는 것은 이 싸움에서 우리의 가장 좋은 무기가 될것입니다. 우리는 강력한 저널리즘을 두 배로 늘릴 것입니다. 명확하고 의미있게 포지셔닝 된 라이프스타일 브랜드; 새로운 형식의 더 많은 전통적인 BuzzFeed 기사들, 우리의 독자들에게 연결되는 리스트 및 퀴즈등이 될 것 입니다. 단기적으로는 생태계는 콘텐츠 비용을 줄이고 경쟁을 강화하는 것을선호하겠지만, 우리는 장기 목표에 집중할 것 입니다. 장기적으로는 최고의 콘텐츠가 이길 것 입니다.

디중 수익 모델로 진화, Evolving to a Multi-Revenue Model

2018년에는 (거대 테크)플랫폼으로부터의 매출이 크게 증가 할 것으로 예상합니다. 지난 4 년 동안 Facebook, Amazon, Netflix 및 Google로부터 받은 수익은 다음과 같습니다.

버즈피드의 페이스북 아마존, 넷플릭스로터 얻는 매출 추이

이것은 고무적인 추세지만 우리는 플랫폼에서 나오는 수익이 폭등할때까지 기다리지 않을 것입니다. 우리는 광고 사업을 보완하기 위해 계속해서 멀티 수익 모델(Multi-Revenue Model)을 구축 할 것입니다.

최근 몇 년 동안 디지털 미디어는 업계의 “진정한 비즈니스 모델”을 위해 다양한 경쟁자들을 추동하는 하이퍼사이클을 견뎌 왔습니다. 어떤 이들은 네이티브 광고를 옹호했고, 어떤 이들은 프로그래밍 방식을 선호했습니다. 일부는 전자상거래와 콘텐츠 통합을 중시했고, 다른 이들은 “동영상으로 전환 (pivot to video)” 또는 전통적인 TV의 (컨텐츠) 개발 모델에 집중했습니다. 일부는 규모의 경제를 추구했고 다른 이들은 틈새 시장이지만 강력한 구독 모델 구축을 옹호했습니다.

현실은 더욱 복잡합니다. 디지털 미디어를 위한 하나의 완벽한 모델은 없습니다. 최고의 미디어 회사는 광고, 구독, 스튜디오 개발, 브랜드 라이센스 및 머천다이징을 결합한 다양한 수익원에서 수익을 창출합니다. 디지털 미디어가 성숙함에 따라 최고의 디지털 미디어 기업은 많은 수익원을 가진 다양한 비즈니스모델을 구축하고, 대기업보다 더 잠재 고객 중심, 더 데이터 중심, 더 효율적이며 글로벌로 디지털 고유한 이점을 활용할 것입니다.

우리는 이미 이전보다 디지털 미디어로부터 수익을 창출 할 수있는 더 많은 방법이 있음을 직접 목격하고 있습니다. 2017년 매출의 약 4분의 1은 직접 판매하는 광고 사업의 밖에서 발생했습니다. 이는 2018년에는 매출액의 약 3분의 1 그리고 2019년에는 매출액의 약 절반까지 성장할 것입니다. 점점 더 많은 소스에서 수익을 창출하는 컨텐츠 및 브랜드를 만들어 가고 있습니다. : 전자상거래, 광고, 플랫폼 수익 및 쇼 개발이 그것입니다. Tasty 는 이에 대한 훌륭한 예 입니다. (Tasty) 비즈니스가 수익을 창출하는 모든 방법을 살펴보십시오.

버즈피드 Tasty 비지니스 모델

강력한 브랜드 포트폴리오 구축, Building a Portfolio of Strong Brands

우리 사업 전반에 걸쳐 이미 성공한 Tasty 비지니스모델을 적용하고, BuzzFeed Media Brand를 만들어 사람들의 실제 삶과 연결되는 강력한 디지털 브랜드 구축을 가속화 할 것입니다.

과거에는 소비자가 브랜드에 충실했습니다. 브랜드는 우리가 추구하는 (사람들의 실제 삶과) 멀리 떨어진 열망이 넘치는 브랜드 이미지를 만들었습니다. 점점 더 (소비자와 브랜드간) 힘의 균형이 바뀌었고 소비자는 더 많은 브랜드에 대한 통제력을 갖게되었습니다. 오늘날 브랜드는 소비자에게 충실해야 합니다. 매일 삶에서소비자에게 감동적인 서비스를 제공할 수 있는 회사만이 가장 강력한 브랜드를 가질수있습니다. 우리는 디지털 및 데이터 기반으로 짧은시간안에 미디어에서 가장 잘 알려진 브랜드를 구축했고, 수십 년 동안 수억 달러 마케팅비를 쏟아 부어 만든 브랜드들과 경쟁하고 있습니다. 90%의 밀레니얼들이 BuzzFeed와 BuzzFeed News를 알고 있습니다. Tasty는 식품 미디어에서 상대적으로 신참이지만 페이스북에서 가장 좋아하는 미디어 브랜드로 다른 어떤 식품 네트워크보다 전 세계적으로 잘 알려져 있습니다.

Tasty의 성공은 특정 소비자 니즈에 대응에 어떻게 대응해야 하는지를 알려 줍니다. 점점 양극화되는 환경에서, 세계는 정치 담론과 관련이 없고 공유할 수 있는 컨텐츠가 필요합니다. 공동 관심사를 중심으로 사람들이 모이고 서비스를 통해서 삶을 향상시킬 수 있는 컨텐츠가 필요합니다. Tasty 는 음식에 대한 공통의 열정을 가진 다양한 사람들에게, 이러한 모든 것들을 실행 시킨 좋은 예 입니니다. 우리는이 Tasty 비지니스 모델을 다른 핵심 분야로 확대하고 가정 내 삶의 문제를 다루는 Nifty를 구축하는 데 더 많은 투자를합니다. 건강과 웰리스를 다루는 Goodful도 만들어졌습니다. 모든 사람들이 자신의 스타일을 표현토록 돕는 미션을 갖고 새로운뷰티및 스타일브랜드를 출시했습니다. Tasty는 시작에 불과했습니다. 여기서 우리가 할 수 있는 일은 훨씬 많아서 브랜드를 현대적으로 구축하고 사람들이 열정을가지고 공유하고,연결하도록 돕습니다

미래를 위한 조직, Organizing for the Future

우리는 브랜드와 여러 수익원을 결합하는 전략을 보다 잘 수행할 수 있는 새로운 조직 구조를 만들고 있습니다. BuzzFeed, BuzzFeed News, Tasty, Nifty, Goodful 및 성장하는 BuzzFeed Media Brand의 라이프스타일 브랜드같은 핵심 컨텐츠 엔진이 핵심 수익원을만들고 성장시킬 것입니다. (그 핵심 수익원은) 광고, 전자상거래, 스튜디오 개발등입니다. 이것은 많은 새로운 기회를 이끌어 낼 것이며 그 중 일부는 아래 다이어그램에 강조되어 있습니다.

버즈피드 9가지 경영 전략 매트릭스

2018년에는 컨텐츠팀과 이러한 비즈니스 기회를 긴밀하게 연계하고, 모든 (비지니스 부문간) 교차로에서 성장을 주도 할 것입니다. BuzzFeed의 임직원들은 자신의 업무가 적어도 하나의 영역에서 어떻게 기여 하는지를 알 수 있어야 하며 Tech, Product, Marketing, Research, Legal, Communications, Finance 및 People과 같은 팀이 협력을 이끌어 낼 것입니다. 함께 작업하면서 규모를 키울 것이며, 잠재 고객과의 연결을 강화하며 각 전략 매트릭스(위에서 설명한 각 부문별 다이어그램)에서 더 많은 수익을 창출해야 합니다.

2017년 내내, 우리는 비지니스 다양화에서 엄청난 진전을 이루었습니다. BuzzFeed Audience Engine을 통해 광고 제안 형태를 벼화시켰고, BuzzCuts와 같은 턴키 광고 제품 및 프로그래밍 방식을 도입했습니다. 우리는 멕시코시티의 코카콜라에서부터 호주 관광청, 브라질의 네슬레 (Nestle)에 이르기까지 글로벌 시장에서 기록적인 계약을 성사시켰습니다. 우리는 Tasty One Top에서 Social Sabotage에 이르는 커머스 비즈니스와 Unsolved 및 Ladylike와 같은 일련의 패스트 판매 상품등을 개발했으며 수익성 높은 라이센스 제휴도 활발히 성장하고 있습니다. 그리고 우리는 AM to DM과 Unfortunatly Ashly와 같은 히트작뿐만이 아니라 Facebook용 Quinta, NBCU용 Kelsey와 같은 외부 파트너를 위한 수많은 프로젝트에 이르기까지 이전보다 더 많은 독창적인 시리즈를 개발하고 있습니다.

지난 1년 동안 매출을 늘리고 잠재 고객을 늘리는 동시에 이러한 모든 작업을 처리했습니다. 확실히, 이러한 노력은 만족스러울 정도의 매출 성장을 가져오지는 못했습니다. 주위의 수많은 방관자들은 이것을 디지털 미디어의 종말의 신호로 해석하고 싶어하지만, 실상 그것은 훨씬 더 단순한 사안입니다. (적절한 (신문 기사의) 헤드라인은 아닙니다). 우리는 성장하고 있습니다. 우리는 본질적으로 하나뿐인 매출 기반에서 비지니스할 수 있는 역량 이상으로 성장했습니다.(We’ve outgrown the ability to build our business on essentially a single, very distinct revenue stream.) 우리는 서로 다른 독자들을 가입시키고 다양한 비지니스를 지원할 수 있는 뉴스와 엔터테인먼트 브랜드 포트폴리오로 발전시켰습니다. 우리는 이러한 변화를 받아드릴 필요가 있으며, 우리의 성공으로 이끄는 실험 지향, 호기심, 재미 그리고 문화적 다양성을 보호하고 강화해야 합니다.

우리는 어려운 미디어 환경에서 사업을 영위하고 있지만 우리는 승리할 수 있습니다. 우리의 전진은 다른 사람들을 위해 초석을 닦는 것입니다. 우리는 비지니스를 다양화하고 브랜드 포트폴리오를 확장하면서 미디어와 테크 기업간의 망가진 관계를 회복시키는데 도움을 줄 것입니다. 우리가 이런 문제를 해결할 때 더 강한 회사가 될 수 있을 뿐만이 아니라, 디지탈 미래로 미디어를 이끌 것이며 사람들을 연결하고 민주주의 문화를 강화할 수 있도록 지원할 것입니다.

내일 모두에게 이러한 전략과 이 전략이 의미하는 바를 설명할 것입니다. 내년 초 각 비지니스 매트릭스별로 9번의 회의를 열어, 성장을 독려하고 미래를 구축하기 위해서 어떻게 협력할 것인지 토론할 것입니다. 가능하면 빨리 여러분과 이 전략에 대해서 토론하도록 하겠습니다.(Can’t wait to see you all to discuss this more.)

여러분의 분석 정신, 창의력, 근면, 유연함에 끊임없이 깊은 인상을 받고 있습니자.여러분들과 함께 미디어의 미래를 건설할 수 있어 영광입니다.

감사합니다.

조나 페레티

참고 사항

인터넷을 찾아보니 이미 이 글을 번역해 공개한 곳이 있네요. 참고로 같이 보면 좋을 듯 합니다.

버즈피드의 미래를 만들어갈 9개의 상자