한 주간의 소셜섹터 이슈, 이거 하나만 보세요.

정리는 슬로워크가 할게요.


오렌지레터는 슬로워크에서 매주 월요일 오전 발행하는 뉴스레터예요.
지난 한 주간 당신이 혹시 놓쳤을지 모르는 소셜섹터의 동향, 펀딩, 채용 소식은 물론이고, 다가오는 주에 있을 각종 행사와 모임 소식도 함께 전해드려요.


아침마다 소식 확인하느라 여러 사이트를 들락날락 하다 보면 어느새 시간이 금방 지나가잖아요. 오렌지레터와 함께라면 이제 그런 수고는 하지 않아도 돼요. 슬로워크가 꼼꼼히 챙겨드릴게요.


오렌지레터의 오렌지 색은 따뜻하고 진취적인 느낌을 나타내요. 선한 사람들이 모여 느리지만 조금씩 세상을 더 좋은 곳으로 바꿔나가기 위해 열심인 슬로워크를 상징하는 고마운 색이죠. 우리는 오렌지레터와 함께 세상이 조금 더 오렌지빛으로 물들기를 기대해요.


오렌지레터에 알리고 싶은 소식이나 제안해주고 싶은 내용이 있다면 ‘제보하기'를 통해 알려주세요. 주변 소식에 귀를 쫑긋 기울이고 함께할 일은 없을까 늘 고민하면서 우리 그렇게 같이 걸어요. 혹시 또 모르죠, 정말 멋진 파트너를 만나게 될지도!


그럼, 매주 월요일에 만나요.
슬로워크 드림.

Posted by slowalk

안녕하세요. 스티비팀 서버 개발자 이학진 입니다. 저희는 최근 서비스에서 사용 중이던 MySQL DB를 RDS로 이관하는 작업을 진행하였습니다. 무엇 때문에 이관을 결정하게 되었는지와 어떻게 이관을 진행하였는지에 대해 글을 써보도록 하겠습니다.


배경

stibee.com은 작년 11월에 정식 오픈한 새내기 이메일마케팅 서비스 입니다. 사실 오픈 초기부터 얼마전까지만 해도 AWS EC2의 m4.large 인스턴스 하나로 운영되던 서비스였습니다.(사실 웹+API 서버 1대, 메일발송 서버 1대) 그리고 이 싱글 인스턴스에 무려 6개의 서버, MySQL 1개, Kafka™ 1개, Redis 1개가 돌고 있었습니다. 그럼에도 불구하고 CPU 사용률은 20%를 넘지 않았습니다.

 

하지만 최근 사용자도 점점 늘어났고, 네이버에서 메일 수신정책을 변경하면서 메일발송 서버에 대한 요청이 급증했습니다.

 

스티비에서 네이버로 대량메일을 발송했을 때 해당 메일의 본문 링크를 자동검사하는 것을 발견했는데요, 따라서 네이버로부터 비정상적으로 많은 요청이 들어오고 있었습니다. (어떤 기준으로 이런 검사를 하는 것인지 정확한 정책은 아직 모릅니다. 담당자분 이 글을 보신다면 연락주세요. 친하게 지냈으면 합니다 )

 

이내 곧 이메일을 마구 쏘아대던 스티비 서버는 네이버의 분노를 감당하지 못했습니다. (사실 네이버의 요청은 무난하게 처리하였으나, 요청 후 발생되는 이벤트 후처리에 DB를 과하게 사용하여…) 결국 CPU가 비명을 질렀습니다. 

 

일단 네이버의 IP를 달고오는 패킷을 drop함으로써 문제를 해결하였지만, 이로 인해 이제 "우리도 때가 왔다!'라는 판단을 하게 되었습니다.

 

그리하여 앞으로 대박날 스티비를 대비하여 스케일아웃이 가능하도록 각각의 서비스를 분리하는 작업을 진행하게 되었습니다. (사실 지금도 조금씩 떼어내고 있습니다. )


준비

앞서 RDS로 이관한다고 말씀드렸는데요. RDS는 AWS에서 제공하는 관계형 데이터베이스 서비스(링크)입니다. RDS로 이용 가능한 DB는 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server 등이 있습니다.

 

이 중 저희는 아마존에서 MySQL과 호환되며 최대 5배까지 성능을 낼 수 있다는 Aurora DB를 사용하기로 결정하였습니다. (결정권자=1인=저)

 

AWS의 모든 서비스가 그러하듯이 RDS를 생성하는 방법은 매우 간단합니다. RDS 콘솔로 진입하신 뒤, 메인 대쉬보드의 “Launch a DB Instance” 를 클릭면 됩니다.



그러면 아래와 같이 사용 가능한 DB 목록들이 나타나는데 이중 기본값인 Aurora DB를 선택하고 “Select” 버튼을 누르시면 됩니다.


 


그리고 회사의 자금사정(?)에 따라 인스턴스 타입을 결정하시면 됩니다.


인스턴스 타입의 선택은 서비스의 특성에 따라 다르므로, 다양한 성능 테스트를 해보시기 바랍니다. 저희는 당시 EC2 인스턴스에서 DB가 같이 돌고 있었던 지라, EC2와 비슷한 사양이되 그 중 제일 저렴한 사양인 r3.large를 골랐습니다.


사양 선택에 있어 너무 고심할 필요는 없습니다. AWS에서는 클릭 한번으로 언제든 사양을 변경할 수 있으니까요~


사양을 변경하기 위해서는 인스턴스의 재부팅이 필요하므로 실서비스에 물리기 전에 결정하시길 권장합니다.



여기서 한 가지 주의할 점, Aurora DB는 기본적으로 클러스터로 구성됩니다. 클러스터란 쉽게 말해 여러 Aurora DB들을 하나로 묶어서 마치 하나의 DB처럼 사용 가능하게 해주는 역할을 합니다. (이로 인한 부하 분산, Fail-Over, 고가용성 등의 장점이 있습니다.)


앞서 저희는 하나의 인스턴스를 런칭 시키고자 하였으나, 설정페이지의 “Multi-AZ Deployment”의 기본설정을 보시면 “Create Replica In Difference Zone”으로 되어 있습니다. 이는 동일한 인스턴스를 다른 AZ에 추가적으로 둠으로써 고가용성을 보장하고 부하분산을 통해 성능향상을 해주겠다는 아마존 형님의 배려이십니다. (하지만 돈은 두배? ^^) 그래서 스티비는 “No”... (나중에 추가 할 수 있습니다.)


그 다음엔 DB Instance를 식별할 수 있게 이름을 부여하고 Root 역할을 할 Master Username과 패스워드를 설정해 줍니다. 그리고 “Next Step”


자! 이제 마지막 설정 페이지 입니다. 모든 옵션에 대해서 언급하고 넘어가기에는 설명이 너무 길어지니, 이것 정도는 알아야 한다는 옵션에 대해서만 간략히 설명하도록 하겠습니다.

  • VPC Security Group(s): DB Instance의 인/아웃바운드 트래픽 규칙을 정할 수 있습니다. 여기에서는 이미 생성된 Security Group을 사용할지, 아니면 새로 생성할 지를 정할 수 있으며, 선택된 Security Group의 세부 설정은 EC2 콘솔 페이지의 Security Group에서 할 수 있습니다.
  • Auto Minor Version Upgrade: Aurora DB의 마이너 패치가 나왔을 때, 자동으로 업그레이드를 할지 여부입니다. Yes로 하면 두세 달에 한번 업그레이드가 된다고 합니다. 주의하실 점은 업그레이드 시점에 DB는 사용 불가…(꺅!)
  • Maintenance Window: 자동으로 마이너 업그레이드를 한다면, 사용자의 이용이 가장 적은 시간대로 패치 시간을 적용할 수 있습니다.


모든 설정을 마치고 “Launch DB Instance”를 클릭하면 잠시 후 Aurora DB가 뙇!!하고 모습을 드러내시니, 이로써 이관에 대한 기본적인 준비를 마쳤습니다.

런칭된 오호라(?) DB

 

이관

AWS는 이관 방법에 대해 많은 정보를 문서로 제공합니다.

MySQL DB 인스턴스에서 데이터 가져오기 및 내보내기(링크)


운영 중인 DB를 중단하지 않고 RDS로 이관하는 방법도 있지만 이는 이관 후 데이터의 정합성을 검증해야하고 운영 DB의 부하발생 등의 이유로 해당 방법은 사용하지 않았습니다. 비록 점검 공지를 띄우고 이관 종료까지 서비스를 사용할 수 없지만 엔지니어에게 부담없는 방법을 택했습니다.

먼저 대략적인 이관 시간을 파악하고 스티비 활성 사용자가 가장 적은 시간대를 선택하여 이관을 진행하였습니다.


이관 절차는 아래와 같았습니다.

1. 자정(0시)을 기점으로 점검 페이지 교체

2. DB를 사용하는 모든 서비스 종료

3. MySQLdump를 이용한 DB백업

4. 백업된 DB 파일을 EC2로 복사

5. EC2에서 MySQL 명령어로 RDS 접속

6. source 명령어를 통한 백업파일 import

7. 명령어 실행 종료 후, 서비스 구동 및 점검 페이지 교체


이관을 진행함에 있어 EC2를 사용하는 이유는 다운타임을 최소화 하기 위해서 입니다. EC2와 RDS를 같은 VPC 내에 위치 시킴으로써 네트워크 속도가 가장 빠르기 때문입니다. (혹여나 그렇지 않을 경우 RDS가 속해 있는 VPC에 EC2를 생성해 주시기 바랍니다.)


아래는 3번부터 사용된 명령어 입니다.

DB 덤프 뜨기

$ mysqldump -u db_user -p --databases db_name --single-transaction --compress --order-by-primary > backup.sql


#필요에 따라서 압축

$ tar -zcvf backup.tar.gz backup.sql 


#EC2로 덤프 파일 복사

$ scp -r -i <key pair>.pem backup.sql.gz ec2-user@<EC2 DNS>:/<target_directory>/backup.sql.gz

#덤프 파일 복사는 편하신 방법으로 진행하시면 됩니다.

#MySQL 서버가 EC2에서 돌고 있었다면 생략


#EC2에서 RDS mysql 접속

$ mysql -h <host_name> -P 3306 -u <db_master_user> -p

#host_name은 RDS 콘솔 페이지에서 확인 할 수 있는 Cluster Endpoint 입니다.


#DB 및 User 생성

$ create database db_user;

$ grant all privileges on db_user.* to 'db_user'@'localhost' identified by 'db_password' with grant option;

$ grant all privileges on db_user.* to 'db_user'@'%' identified by 'db_password' with grant option;

$ flush privileges;


#이관 시작

$ source path/backup.sql



여기까지가 제가 진행한 이관절차의 끝 입니다. 그런데 과연 이렇게 간단하게 끝났을까요? 물론 아닙니다. 문제점 한두 개 정도는 나와줘야 제맛 아니겠습니까? (사실 악 악 하면서 심장이 쫄깃해졌습니다.)

 

문제 발생 및 해결

사실 지금까지 기술한 내용들은 AWS의 기술 문서에 매우 자세히 나와있어서 RDS를 사용하고자 하신 분들은 굳이 이 글을 읽지 않으셔도 무방하셨을 거 같습니다. 하지만 저 문서들을 보고 진행했음에도 불구하고 문제가 발생하더군요. 저희 서비스만의 문제였는지 모르겠지만 발생된 문제와 해결법을 공유해 보도록 하겠습니다.


1) Timezone

토종 한국 서비스라 Timezone이 한국 표준시였습니다. 그런데 기본 옵션으로 RDS 인스턴스를 생성하시면 국제 표준시로 설정이 되어 시간값이 다르게 나왔습니다.

DB Cluster Parameter Group의 time_zone 값을 Asia/Seoul로 변경한다.
기본 옵션값은 변경되지 않으므로 새로 생성한 뒤 변경하고, 인스턴스에 적용한다.


2) Import 중 ‘MySQL server has gone away’ 에러

MySQL의 옵션중 클라이언트가 한번에 전송 할 수 있는 패킷량의 제한이 있습니다. 이관 테이블 중 Long Text 타입의 컬럼이 있었고 해당 컬럼의 데이터를 옮기지 못해 발생된 에러 입니다. (이와 같은 이유로 아마존 기술 문서에 기술된 dump와 동시에 import하는 방식을 사용했을 때도 최대 1GB 밖에 전송할 수 없었습니다.)

DB Parameter Group의 max_allowed_packet의 값을 늘린다.
기본 옵션값은 변경되지 않으므로 새로 생성한 뒤 변경하고, 인스턴스에 적용한다.


3) 이모지 적용 안됨 

스티비는 메일 제목과 본문에 이모지 사용을 적극 권장하고 있습니다. 하지만 이관 후 작성된 메일의 이모지가 깨지는 현상이 발생 되었습니다. 이미 아시는 분들은 딱하고 감이 오시겠지만 네, CharacterSet 문제입니다. 그리고 이모지는 utf8mb4에서 지원됩니다.

DB Cluster Parameter Group의 character 옵션들을 바꾼다.
character_set_client = utf8mb4
character_set_connection = utf8mb4
character_set_database = utf8mb4
character_set_filesystem = utf8mb4
character_set_results = utf8mb4
character_set_server = utf8mb4
collation_connection = utf8mb4_unicode_ci


여기까지 스티비의 이관기를 마칩니다. 감사합니다.



Posted by slowalk


세상에 온전하게 혼자 만든 물건은 매우 드뭅니다. (풀스택이라는 개념도 있지만) 웹서비스 역시 여러 사람의 협업으로 만듭니다. 슬로워크에서 운영하는 이메일마케팅 서비스 스티비도 예외는 아닙니다. 살짝 말씀드리면 스티비는 기획/PM 1명, 디자이너 1명, 개발자 2명이 만들고 있습니다. 큰 조직은 아니지만 소통의 틈은 늘 존재하기 마련입니다. 


그중 하나가 UI 용어입니다. 동상이몽이라는 말처럼 각자 웹서비스 개발을 해왔지만, 모두가 같은 상황과 맥락에서 학습한 것이 아니고, 머릿속에 그리는 이미지가 달라 사용하는 용어가 서로 다를 수 있습니다. 그리고 같은 용어를 사용하면서도 그 의미와 구현된 결과물이 다를 수 있습니다. 


“‘드롭다운'이 들어가야 해요"라고 요청받고 나온 결과물은 ‘버튼을 클릭하면 아래로 펼쳐지는 메뉴'일 수 있습니다. 하지만 요청한 사람이 실제로 원했던 것은 <select>일 수 있다는 것이죠. 이런 소통의 틈을 채우기 위해 우리는 장문의 기획서를 쓰고 시간과 공을 들여 프로토타이핑을 합니다. 시간과 인력 자원이 허락된다면 아주 좋은 과정입니다. 하지만 자원이 적은 스타트업 팀에게는 부담스러울 수 있습니다. 모든 것이 비용이죠. 그저 “‘드롭다운'은 아래로 펼쳐지는 메뉴이고, 옵션 선택을 위해서는 셀렉트(<select>)를 쓰자"고 미리 약속하면 많은 부분이 해결됩니다. 그래서 UI 용어 통일은 중요합니다.



이런 것이 헷갈리고, 이렇게 씁니다. 


몇 가지 사례를 살펴보겠습니다. 서비스를 2년 가까이 만들어 오면서 헷갈렸던 용어와 서로 약속을 통해 바로 잡은 것들, 그리고 아직도 헷갈리는 것들이 섞여 있습니다. 그리고 다른 팀에서 사용하는 의미와 또는 웹표준과 다를 수 있습니다. 그저 “스티비는 이렇게 쓰는구나"하고 봐주시면 되겠습니다.



1. 버튼(button)


사용자의 클릭을 끌어내는 버튼. 마우스와 키보드를 가지고 할 수 있는 많은 액션이 있지만 무언가를 클릭하는 것만큼 직관적이고 친숙한 UX는 없을 것입니다. 그 중심에 버튼이 있습니다. 어떤 때는 이동을, 어떤 때는 실행이나 취소를 위해 버튼을 클릭합니다. 


버튼의 개념과 역할은 아주 명확한 것처럼 보이지만 프론트엔드 개발자 입장에서는 때로 ‘링크'와 혼동될 때가 있습니다. 어떤 것은 <a>로 만들어진 링크로 만들어야 하고, 어떤 것은 <button>으로, 또 어떤 때는 <input type=”submit”>처럼 하기도 합니다. 하지만 표현되는 결과물은 마우스를 올리면 색이 변하는 ‘버튼'이죠. 보통 <a>는 페이지의 이동을 나타내고, <button>은 실행이나 취소, <input type=”submit”>은 양식의 전송을 말합니다. 


스티비에서는 ‘버튼', ‘링크', ‘링크 버튼'을 혼용해서 사용합니다. 결과물은 버튼이지만 개발자의 재량에 따라 어떤 방식으로 구현할지 정합니다. 위 용어들에 대한 추가 질문은 따로 하지 않습니다. 그리고 SPA 방식으로 개발된 탓에 실제로 구분이 명확히 되지 않는 경우가 있습니다. 


* 이렇게 씁니다.

→ “개발자가 알아서 한다"



2. 팝업(popup)과 모달(modal) 


다음으로 헷갈리는 것이 팝업과 모달입니다. 과거 ‘팝업’은 작은 새로운 윈도우를 띄우는 기능을 말했습니다. 최근 팝업 차단이나 모던 브라우저들의 다중탭 기능 덕분에 많이 사용하지 않는 기능이 되었습니다만 아직도 많이 사용되는 용어입니다. 그리고 모달은 비교적 최근에 등장한 개념으로 화면 위에 레이어를 덮어 마치 새로운 창이 나타나는 것처럼 보여주는 방식입니다. 


“이 부분은 모달로 해주시고요.", “다음 페이지는 역시 같은 팝업에서 이동하는 것으로...”. 이처럼 초기에는 위 용어를 혼재하여 사용했습니다. 새로운 윈도우를 띄우는 상황은 없거나 매우 희박하므로 소통에 큰 문제는 없었습니다. 다만 모달은 ‘기존(부모) 페이지와 맥락을 달리하는...”이라는 함의를 가지고 있습니다. 이런 경우는 되도록 ‘모달'이라는 용어로 통일하려고 합니다. 


* 이렇게 씁니다. 

→ 팝업/모달은 중에 하나를 선택하지는 않지만 열리는 상황과 맥락에 따라 용어를 구분하면 좋다. 구현은 하나의 통일된 템플릿으로 진행한다. 

 


3. 얼럿(alert)



‘얼럿’은 사용자가 무언가 잘못된 길로 갔을 때, “띵"하고 뜨는 그 경고창입니다. 과거에는 브라우저에 내장된 기본 기능을 많이 사용했지만, 디자인과 사용성을 위해 최근에는 디자인이 입혀진 레이어로 구현된 유사 얼럿이나 하단에 위치한 토스트얼럿UI 등 다양한 변형이 사용되고 있습니다. “사용자가 취소하려고 하면 이런 메시지로 경고를 해주세요"라는 요청을 받는다면 개발자는 이것을 단순히 alert()으로 처리할지 상단에 뜨는 예쁜 레이어로 띄웠다가 일정 시간이 지나면 없앨지, 하단에 커다랗게 보여줄지 고민이 됩니다. 앞서 살펴본 모달 형식의 경고도 있으니 혼란은 커집니다. 


대부분 서비스가 그렇겠지만 스티비는 미리 설계된 얼럿 디자인을 사용합니다. 보통의 경우 당연히 이 UI를 사용하고, 추가 액션이 필요하거나 화면의 가운데 모달 형식으로 보여줘야 할 경우라면 디자인 작업물에 명시합니다. 화면에 붉은 글씨로 보여주는 경우도 있어 이 부분은 대부분 디자인 결과물로 소통합니다.


* 이렇게 씁니다.

→ 디자이너가 각 상황과 맥락을 파악하며 적당한 경고 방식을 선택, 디자인 작업물에 배치하여 개발팀에 전달합니다. (디자인 결과물은 제플린으로 전달합니다)



4. 드롭다운(dropdown)과 셀렉트(select)



결과부터 말씀드리면 ‘드롭다운'과 ‘셀렉트'는 다른 UI입니다. 하지만 비슷한 역할을 하는 경우가 있어 혼용하여 사용되는 것 같습니다. ‘드롭다운'은 하위 메뉴가 숨겨져 있다가 사용자의 마우스 오버나 클릭에 숨겨진 메뉴를 보여주는 UI입니다. 셀렉트는 <select>태그로 구현되며 사용자에게 내재된 옵션값 중 하나(또는 여러 개)를 받기 위한 양식 UI입니다. 


예쁜 디자인을 위해 레이어로 구현된 드롭다운처럼 구현한 셀렉트도 있고, 셀렉트인데 옵션의 선택에서 그치는 것이 아니라 선택과 동시에 페이지가 이동된다든지 하는 액션을 가진 경우가 있어 혼란이 생긴 것으로 생각됩니다. 


* 이렇게 씁니다.

→  초기 기획 단계에서 이 둘은 명확히 구분합니다. 사용자에게 어떤 값의 입력(선택)을 요구하기 위해서는 셀렉트를 사용합니다. 이때 디자인은 변형될 수 있지만, 선택이라는 핵심 기능은 그대로 둡니다.

버튼 뒤에 숨겨진 메뉴를 표현하기 위해서는 드롭다운을 사용합니다. 하위 메뉴에서 어떤 액션이 있어야 한다면 드롭다운으로 합니다. 구현은 기획에 맞추어 진행합니다.



5. 인풋(input)


‘인풋’, ‘입력창', ‘필드' 등 여러 이름으로 불리웁니다. 사용자에게 텍스트 형식으로 어떤 내용을 입력받기 위한 UI로 보통은 그냥 사각형이고, 여기에 테두리(border)나 옅은 배경(background)를 주어 사용합니다. 


딱히 헷갈릴 일이 없긴합니다. 하지만 뭔가 용어 통일을 한다면? 아마도 ‘텍스트 입력'이나 ‘텍스트 인풋'이 적당하지 않을까 합니다. 결과물은 입력을 위한 상자이지만 구현은 보통 <input>태그로 합니다. 하지만 단순히 인풋이라고만은 할 수 없는 것이 <input type=”checkbox”>나 <input type=”radio”>, <input type=”submit”> 같은 예외가 있기 때문입니다. “인풋으로 해주세요", “인풋 중에 뭐요?”같은 상황이 생길 수 있습니다. 그렇다고 ‘텍스트 입력'이라고 한다면 <textarea>와 혼동할 수 있습니다. 구현 과정을 생각하여 되도록 명확한 용어가 사용되는 편이 좋습니다.


* 이렇게 씁니다. 

→ 무엇을 입력할지 디테일한 전달 필요. 용어 통일은 조금 더 논의해 본다.



마치며 

쓰임에 따라, 상황에 따라 다를 수 있는 UI 관련 용어들. 각자 편한 대로 쓰면 되지 왜 꼭 통일해야 할까요? 오히려 하나의 단어로 통일하는 순간 그 단어만 제한되는 것은 아닐까요? 개발 조직마다 다르겠지만, 스타트업이나 스타트업처럼 작고 빨라야 하는 조직에서의 팀원 사이의 이런 작은 ‘싱크'들은 매우 중요합니다. 드롭다운을 열심히 그렸는데, 실제로 필요한 건 셀렉트였다면? 이렇게 소통이 어긋났을 때 발생하는 시간과 자원의 낭비가 줄어듭니다. 세세한 UI까지 디자이너가 그리는 시간을 줄일 수 있습니다. 미리 약속된 UI(일종의 스타일 가이드)가 있다면 개발자는 상세 디자인 없이도 기존 것을 재사용하면 되기 때문입니다. UI 용어의 싱크만 잘해도 많은 시간을 절약할 수 있습니다. 그 시간에 더 많은 아이디어를 실험하고 구현해볼 수 있습니다. 



Posted by slowalk

이메일마케팅의 진정한 재앙, 스팸신고.

수신거부를 제대로 유도하면 스팸신고를 막을 수 있다.



스티비를 운영하다 보면 이런 질문을 가끔 받습니다.

“이메일에 수신거부 링크를 꼭 삽입해야 하나요?”

“수신거부 링크를 아주 작게, 잘 안 보이게 해도 될까요?”


수신거부 링크가 거슬리는 것, 이해합니다. ‘수신거부 링크가 잘 보이고 누르기 편할수록 수신거부하는 구독자가 늘어나지 않을까?’하는 고민이 생길 수밖에 없습니다.


일반 상식과는 약간 다른 접근법을 제안해 드립니다. 수신거부보다 스팸신고가 더 큰 재앙이기 때문입니다. 스팸신고를 막기 위해 수신거부를 적절히 이용할 필요가 있습니다.  왜 스팸신고가 재앙인지, 스팸신고를 막기 위해 수신거부를 어떻게 활용할지 알아보겠습니다.


1. 스팸신고가 왜 재앙인가?

수신거부는 이메일 수신을 중단하고 싶은 의사가 있는 구독자 1명에게만 영향을 미칩니다. 구독자 A가 수신거부를 했다고 해서 다른 구독자들에게 미치는 영향은 전혀 없습니다.


그러나 스팸신고는 다릅니다. 만약 Gmail을 사용하는 구독자 A가 스팸신고를 한다면, Gmail을 사용하는 모든 구독자들에게 영향을 미칠 수 있습니다. Gmail과 같은 메일박스 프로바이더(Mailbox Provider; 이메일 주소를 생성하여 이메일을 보내고 받고 보관하게 해 주는 서비스)는 스팸신고가 많이 들어온 이메일 발신자를 학습해서 스팸 필터링에 활용합니다. 즉 Gmail을 사용하는 구독자가 특정 이메일의 스팸신고를 많이 한다면, 스팸신고를 하지 않은 다른 Gmail 사용자에게도 이메일이 도달하지 않고 스팸편지함에 빠질 수 있는 것입니다. 이렇듯 한명 한명의 스팸신고가 누적되면 발신자의 평판이 낮아져서 원래 이메일을 잘 받아보고 있던 구독자에게도 도달하지 못할 수 있습니다.


Gmail이 스팸을 인식하는 방법



2. 점점 쉬워지는 수신거부

스팸신고라는 재앙을 피하기 위해 다양한 해결책이 등장하고 있습니다. Gmail과 iOS10 기본 메일앱 등에서는 일부 이메일에서 ‘수신거부’ 또는 ‘구독 취소' 기능을 이메일 상단에서 쉽게 사용할 수 있도록 제공합니다. 스팸신고보다 수신거부를 유도하기 위해서입니다. (자세한 내용 보기: 9 Things You Need to Know About Email in iOS 10)


Gmail에서 ‘수신거부' 기능을 제공한다


iOS10의 기본 메일앱에서 ‘구독 취소' 기능을 제공한다


3. 수신거부 문구도 색다르게

아무리 스팸신고라는 대재앙을 피했다 하더라도, 설레는 마음으로 이메일을 보냈는데 수신거부가 되돌아오면 마음이 아픕니다. 이럴 때 “수신을 원치 않으면 수신거부를 클릭하세요”처럼 딱딱하고 건조한 문구로는 아쉬운 마음을 전할 수 없습니다. 아쉬운 마음을 담은 부드럽고 진지한 수신거부 문구를 소개합니다.


“이메일을 그만 받고 싶으면, 수신거부 하세요. 서로 감정 상하지 않기로 해요.” NextDraft

“떠나는 게 아쉽긴 하지만, 언제든 바로 수신거부 할 수 있어요.” Hitne’s SaaS Weekly

“만약 도움이 되지 않는다 생각하시면 구독해지를 해주세요.” 오픈서베이



수신거부를 확인하는 랜딩페이지에서는 더 많은 메시지를 전달할 수 있습니다. 동영상을 활용하는 것도 좋은 방법입니다.


“가까웠던 우리 사이가 벌써 그리워요.” HubSpot (클릭하면 동영상을 확인할 수 있습니다.)



스팸신고를 막기 위해 수신거부가 왜 중요한지 알아봤습니다. 중요한 내용만 요약하면 아래와 같습니다.


수신거부가 편해야 더이상 관심없는 구독자를 떨궈내고 핵심 구독자에게 집중할 수 있다.

수신거부 링크를 못 찾은 구독자가 귀찮은 마음에 스팸신고를 눌러버리면 그것이야말로 진정한 재앙이다.

한명 한명의 스팸신고가 누적되면 발신자의 평판이 낮아져서 핵심 구독자의 메일함에서도 스팸처리되는 재앙이 생길 수 있다.


더 읽어보기: Why an Unsubscribe is Better Than Being Marked as Spam ― Litmus

참고: 수신거부 문구의 재발견 ― 스티비 블로그




작성: 조성도
Posted by slowalk

11월 10일, 스티비(Stibee)는 베타 테스트를 종료하고 정식버전을 출시했습니다. 새로운 스티비 디자인은 기존 디자인과 어떻게 다를까요?




기존에는 빈 페이지, 발송 완료 등 이미지가 필요한 부분에 이모지와 노란 꿀벌 로고를 활용했는데요, 스티비 정식버전에서는 기존의 노란색에서 벗어나 컬러와 이미지를 변경했습니다. 이를 가장 잘 볼 수 있는 페이지가 바로 empty-state, 즉 사용자가 가입한 이후 아직 서비스에서 요구하는 정보를 입력하지 않은 ‘빈 페이지’입니다. 이 페이지는 사용자가 가입한 후에 어떤 행동을 해야하는지를 안내하는 것이 주 목적입니다. 안내에 따라 사용자가 정보를 등록하면 더 이상 만날 수 없지만, 짧게 접하는 시간과 반대로 사용자의 이어지는 행동을 어떻게 유도할지 많이 고민해야 하는 페이지입니다.


empty-state에 사용하는 일러스트는 정보가 없음을 나타내는 이미지로, 서로 비슷한 맥락으로 페이지를 설명합니다. 하지만 요구하는 정보가 각각 달라 가장 직관적으로 사용자 행동을 유도하기 위해 많은 것을 덜어냈습니다.

그럼, 최종으로 선택된 시안과 탈락된 시안은 어떤 차이가 있을까요? (귀여움 주의)


스티비에 가입하면 가장 먼저 할 일은 ‘주소록 등록하기’입니다. 최종 확정된 왼쪽 시안은 사람의 실루엣과 인덱스로 주소록의 형태를 좀 더 명확하게 보여줍니다.  




주소록을 업로드 했다면 그 다음은 ‘이메일 작성하기’입니다. 최종 선택된 시안은 이메일 콘텐츠 일러스트를 활용한 시안입니다. 오른쪽에 있는 시안은 ‘벌통이 비어있으니 이메일로 벌통을 채워주길 바라’는 뜻으로 만든 일러스트입니다. 벌통 시안은 이렇게 설명하지 않으면 어떤 뜻을 가진 이미지인지 알 수 없는 것이 가장 큰 단점이라, 최종 시안으로 선택될 수 없었습니다.  



다음은 주소록 세부 항목 중, 수신거부한 수신자 목록 페이지의 empty-state 일러스트입니다. 사람, 리스트 이미지를 활용해 봤지만 수신거부한 수신자 목록 페이지 외에도 다양한 목록이 비어있을 때 활용하기 좋아 왼쪽 일러스트를 최종 시안으로 선택했습니다.




주소록에서 사용자를 검색할때 정보가 없는 경우에도 ‘정보 없음’을 일러스트로 보여줍니다. 최종 선택된 시안은 직관적인 이미지로 ‘폴더’와 ‘돋보기’를 사용했습니다. 반면 탈락된 오른쪽 시안은 아무것도 없는 벌집을 돌아다니는 벌 이미지로 이미지를 만들었습니다.



지금 소개한 이미지는 지금 스티비 곳곳에 숨어 있습니다. 완전히 새로워진 스티비. 지금 바로 스티비를 나타내는 다양한 일러스트를 만나보세요!








작성: 조은지


Posted by slowalk

[2016 TEDC Boston]

스티비 조성도 총괄과 임호열 기획자가 이메일마케팅 컨퍼런스의 왕중왕, TEDC에 다녀왔습니다. 그곳에서 얻어오는 이메일마케팅 노하우와 실질적인 팁이 궁금하신 분들은 콘텐츠 하단의 프로젝트에 참여해주세요.

(이 글은 콘텐츠 크라우드펀딩 플랫폼 PUBLY에도 발행되었습니다.)



94.2억 달러

스티비 자체 조사 결과 2010년부터 2016년 7월까지의 전세계 이메일마케팅 업계 M&A 규모는 약 94.2억 달러이다. 원화로는 10조 원이 넘는다. 인수금액이 공개된 것만 이렇다. 구글의 Sparrow 인수(2012년)나 드롭박스의 Mailbox 인수(2013년), MS의 Accompli 인수(2014년) 등 이메일앱 M&A를 제외하고 마케팅 서비스만 조사한 결과이다. 이메일마케팅 업계 M&A는 IBM, Salesforce.com 등 B2B IT 서비스 업체들이 주도하고 있지만 Deutsche Post(2013년에 Optivo 인수)와 같은 의외의 플레이어도 있다.


왜 이렇게 이메일마케팅 업계의 M&A가 활발할까? 이메일은 가장 보편적인 마케팅 채널이고, 스마트폰이 보급되면서 더 각광받고 있다. 잠깐, 이메일이 각광받고 있다니 뭔가 이상한가? 그런 생각이 드는 게 맞다. 한국에서는 별로 각광받고 있지 않기 때문이다.



70.3%

스티비가 2015년에 마케터들을 대상으로 조사한 '이메일마케팅 현황 및 인식 보고서'에 따르면 응답자의 70.3%가 현재 이메일 뉴스레터를 발행하고 있거나 발행할 계획을 갖고 있다고 답했다. 그렇지만 페이스북, 인스타그램, 유튜브 등 다른 디지털마케팅 채널에 비해 이메일에 대한 논의는 찾아보기 어렵다. 마케터들이 이메일은 이미 잘 알고 있어서일까? 나는 그렇게 생각하지 않는다.

수많은 마케팅 이메일을 보내고, 또 받고 있지만 이메일마케팅에 대해서 한국어로 알 수 있는 팁과 트렌드는 제한적이었다. 그동안 이메일마케팅의 최신 트렌드에 대해 전문적으로 다루는 매체를 찾아볼 수 없었기 때문이다.

그래서 이메일마케팅 서비스 스티비를 출시하기 전, 우리는 이메일마케팅에 대한 정보를 알려주는 뉴스레터 발송부터 시작했다. 잠재고객을 확보하는 좋은 방법이라고 생각했다. 덕분에 별다른 마케팅 활동 없이도 뉴스레터 발송 1년 만에 구독자를 2,000명 넘게 확보할 수 있었다.

뉴스레터를 발행하기 시작하니 많은 사람들이 우리에게 이메일마케팅에 대해 질문해오기 시작했다. 이메일마케팅은 늘 해오던 것이고, 딱히 그만둘 이유가 있는 것도 아니지만 늘 궁금증은 간직해오고 있던 것이었다.

"이게 효과가 있는 것인가?"

"내가 잘 하고 있는 건가?"

"어떻게 하면 더 효과를 높일 수 있는가?"

이런 질문들이 몰려들었다.

나뿐만 아니라 스티비의 다른 팀원까지에게도 강의 요청이 많이 왔다. 지금껏 패스트캠퍼스, 어벤저스쿨, 사회복지웹기획자모임, 서울시 청년허브, 수원시평생학습관 등에서 강의했는데 예상 외의 호응에 우리도 놀랐다. 이메일마케팅에 대해 궁금한 게 많은데 어디 물어볼 데가 없는 것이었다. 논의할 데도 없고 고민을 나눌 데도 없었다. 스티비는 마케터들의 그런 욕구를 충족시켜 주고 싶었다.



이메일은 죽지 않았다. 다만,

이메일마케팅에 대한 리서치를 하다 보면 많이 접하는 문구가 있다.

"Email is not dead."

물론 이메일마케터들의 주장이다. 심지어 저 문구를 타이틀로 내건 사이트도 있다. 이메일마케팅에 대한 긍정적인 팩트를 모아 놓은 곳이다.


그러던 중 이번에는 약간 다른 제목의 글을 발견했다.

"Email isn't dead, but your strategy might be."

Action Rocket이라는 이메일마케팅 에이전시와 Taxi for Email이라는 이메일콘텐츠 관리 서비스의 창립자 Elliot Ross가 쓴 글이다. '이메일은 죽지 않았다. 다만 당신의 전략은 죽었을지도 모른다'는 제목이 현재 이메일마케팅의 상황을 여실히 보여주고 있다.

'살아있는 이메일', 즉 마케팅 목표를 달성하는 이메일을 보내려면 어떻게 해야 할까? 기획, 콘텐츠, 디자인, 개발 어느 하나 신경쓰지 않으면 안 된다. 이번에 열리는 TEDC(The Email Design Conference)는 그 모든 것을 다루는 컨퍼런스이다. 다른 디지털마케팅 컨퍼런스처럼 마케터들만 모이는 곳이 아니라 콘텐츠 에디터, 개발자, 디자이너가 함께 모인다.



'이메일계의 WWDC', TEDC

WWDC(Worldwide Developers Conference)는 애플에서 매년 6월에 개최하는 개발자 컨퍼런스이다. WWDC에 MacOS/iOS 생태계와 관련된 모든 사람들이 모이듯이 TEDC에는 이메일마케팅과 관련된 모든 사람들이 모인다. 그래서 작년에 스티비 개발을 시작하면서 "내년에는 꼭 TEDC에 가야지"하고 다짐했었다.

보스턴 행사에 앞선 런던 컨퍼런스(7.26-27)가 열리는 동안 트위터에서 #LitmusLive 해시태그를 지켜봤는데, 그 중에서 유용한 것 몇 가지를 골라봤다.


이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒCatalin Bridinel

이메일 발송 48시간 이후에는 오픈&클릭률이 0.1%로 뚝 떨어진다. 오픈하지 않은 사람들에게 같은 내용을 제목만 다르게 해서 재발송해라.

이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒJustine Jordan


오픈하지 않은 사람들에게 같은 내용을 다른 제목으로 재발송하니, 컨버전이 35% 증가했다.

이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒLauren Smith



같은 내용의 이메일을 재발송해도, 평판이 나빠지진 않는다. 두 메일을 모두 열어보는 구독자는 전체의 0.09% 뿐이다.

이미지를 누르면 해당 트윗 창으로 가실 수 있습니다. - PUBLY ⓒLauren Smith



트윗 몇 개만 봐도 매우 유용해 보이는 컨퍼런스인 TEDC. 그곳에 가기 위해 우리는 Stibee 전용 명함을 만들었다.


ⓒStibee

귀여운 컨셉으로 디자인된 이 명함은 TEDC에 오는 이메일마케팅 전문가들과 친분쌓기용으로 만들어졌다. 이런 교류를 통해 그들이 한국 시장에 진출할 때 스티비가 도움을 줄 수 있으리라 기대한다.

또한 아래 예고된 탐나는 선물도 TEDC 보스턴이 기다려지는 이유 중 하나다.



이미지를 누르면 해당 인스타그램 창으로 가실 수 있습니다. - PUBLY ⓒagainstsoph

[2016 TEDC Boston]

스티비 조성도 총괄자와 임호열 기획자가 이메일마케팅 컨퍼런스의 왕중왕, TEDC에 다녀왔습니다. 그곳에서 얻어오는 이메일마케팅 노하우와 실질적인 팁이 궁금하신 분들은 프로젝트에 참여해주세요.




Posted by slowalk

이메일마케팅은 적은 비용으로 높은 효과를 얻을 수 있습니다. 비용이 낮은만큼 접근하기도 쉽지만, 관련된 법과 규정을 숙지하지 않으면 피해를 볼 수 있습니다.

정보통신망법에서는 영리목적의 광고성 정보를 전송하는 이메일이 지켜야하는 의무사항을 규정하고 있습니다. 제목에는 “(광고)”를 붙여야 한다는 등이 그 예입니다. 놓치기 쉬운 내용이 있으니 꼼꼼히 살펴볼 필요가 있습니다.

수신자의 명시적인 동의를 받아야 합니다

서비스에 가입하거나 앱을 설치하는 것만으로는 수신동의를 했다고 볼 수 없기 때문에 가입 또는 설치 과정에서 광고성 정보에 대한 수신동의를 별도로 받아야 합니다.

단 직접적인 거래 관계를 통해 연락처를 수집한 경우에는 수신동의를 받지 않아도 됩니다. 어떤 제품이나 서비스를 거래하기 위해 만난 고객에게 명함을 받았다면 수신동의 없이 그 제품이나 서비스에 대한 광고성 정보를 전송할 수 있습니다.

제목이 시작되는 부분에 “(광고)”를 표시해야 합니다

수신자의 필터링을 회파하기 위한 목적으로 빈칸, 부호 문자 등을 사용하거나 표시하는 방법을 조작하면 안됩니다. 예를 들어 (광/고), (광 고), (광.고), (“광고”), [광고]와 같이 변칙 표기하거나 특수문자를 사용하지 않아야 합니다. “(광고)지만”, (광고)인듯 광고 아닌” 등처럼 “(광고)” 뒤에 다른 말을 이어붙이는 것은 가능합니다. 스티비도 제목에 항상 “(광고)”를 붙이고 있습니다.

본문에 전송자의 명칭, 이메일 주소, 전화번호 및 주소를 표시해야 합니다

수신자가 내용을 정확히 확인할 수 있도록 해야하며 글자 크기나 색상을 조정하여 내용을 확인할 수 없게 하면 안됩니다. 이 정보는 국문과 영문으로 제공해야 합니다. 일반적으로 이런 정보는 이메일 본문의 하단에 추가합니다.

수신거부에 대한 안내문을 본문에 명시하고 즉시 수신거부를 할 수 있는 기술적 조치를 해야 합니다

수신자가 수신거부를 할 수 있다는 사실을 본문에 명시하고 로그인이나 다른 정보 입력없이 수신거부를 할 수 있는 간편한 방법을 제공해야 합니다. 이 역시 글자 크기나 색상을 조정하여 내용을 확인할 수 없게 하면 안 되고, 국문과 영문으로 제공해야 합니다.

KISA 불법스팸대응센터의 광고전송가이드에서 위의 4가지 준수사항에 대한 구체적인 방법과 예시를 확인할 수 있습니다. 정보통신방법에 대한 자세한 내용은 불법 스팸 방지를 위한 정보통신망법 안내서에서 확인할 수 있습니다.


작성자: 스티비 기획 임호열




당신의 이메일마케팅을 변화시키는 이야기, 스티비 뉴스레터를 구독하세요.




Posted by slowalk


지난번 <좋은 이메일 뉴스레터 디자인 파헤치기>에서는 제일 먼저 이메일 뉴스레터의 머리, <헤더>부분을 살펴봤습니다(바로가기). 이번에 살펴볼 이메일 뉴스레터 디자인은 <콘텐츠>에 관한 이야기 입니다. 


콘텐츠는 가장 많은 이야기를 담고 있는 뉴스레터의 핵심부분으로 <헤더>나 <푸터>보다 자유롭게 디자인을 바꿀 수 있습니다. 글로만 내용을 전하기도 하고, 사진이나 그래픽을 활용해 다음 뉴스레터가 기다려지는 소식을 전하기도 하는데요. 오늘은 읽자마자 휴지통으로 사라지지 않도록 콘텐츠를 돋보일 수 있게 다양한 방법으로 디자인한 이메일 뉴스레터를 살펴보도록 하겠습니다.



1. 움직이는 gif로 시선끌기


 

전체 뉴스레터 보기


움직이는 gif로 밋밋한 이메일에 생동감을 주는 건 어떨까요? 간단한 도형 안에 직원들의 모습을 gif로 만들어 활기찬 모습이 돋보이도록 만든 뉴스레터입니다.


전체 뉴스레터 보기


전체 뉴스레터 보기


gif를 활용한 뉴스레터는 브랜드의 이미지 뿐만 아니라 제품의 활용 모습을 보여주기 위해 활용하기도 합니다.  



클릭율을 높이는 이미지 활용 tip

전체 뉴스레터 보기


간혹 이미지 안에 플레이 버튼을 넣어 동영상이 재생될 것 같은 이미지를 사용한 뉴스레터를 받아보곤 하는데요. 대부분은 사용자를 원하는 페이지로 유인하고자 하는 함정(?)으로 활용한다는 사실, 알고 계셨나요? 이렇게 실행 버튼을 넣어 만든 사진은 일반 사진보다 클릭해보는 사용자의 습성을 활용해 클릭을 유도하는 방법으로 사용하기도 합니다.



2. 사용자를 이끄는 버튼 활용하기

전체 뉴스레터 보기


간결한 메세지와 색의 대비로 눈길을 끄는 뉴스레터 입니다. 화면 가운데 자리한 큰 버튼이 눈에 띄는데요. 이 버튼을 CTA(Call to Action)버튼 이라고 부릅니다. 위의 뉴스레터처럼 CTA 버튼을 강조한 뉴스레터는 새로 서비스를 론칭했거나 행사를 기획했을 때 활용하기 좋은 뉴스레터 디자인입니다. 이렇게 강렬한 CTA 버튼을 활용하려면 보색 대비가 큰 컬러 조합을 활용하는 것을 추천합니다.



전체 뉴스레터 보기


보색 대비가 아니더라도 어두운 바탕에 CI나 BI 컬러를 배치해 브랜드를 돋보이게 하는 방법도 멋집니다.




3. 텍스트로 충분! 뉴스 큐레이션

대부분의 뉴스레터는 위에서 보여드린 형식보다 다양한 소식을 한번에 전하는 뉴스레터가 많습니다. 이럴 땐 정리하는 방법에 따라 뉴스레터의 이미지가 달라지는데요. 이때 추천하는 방법은 1단 레이아웃을 활용한 뉴스레터입니다. 


전체 뉴스레터 보기


뉴스를 전달하는 사진이 없어도 글자 크기와 컬러를 나누어 자칫 밋밋할 수 있는 뉴스레터를 생동감 있게 만들었습니다. 이때 1단 레이아웃으로 디자인하면 모바일에서 이메일 뉴스레터를 보더라도 글자가 깨지거나 레이아웃이 흐트러짐 없이 뉴스레터를 받아 볼 수 있어 더욱 추천하는 방법입니다. (모바일에서 The UX Journal 링크를 클릭해 PC화면에서 보는 뉴스레터와 비교해보세요!)



오늘은 큰 디자인 요소 없이 주목도를 높인 뉴스레터 콘텐츠를 소개했습니다. 메인 이미지를 어떻게 만들어 활용하는지, 주목도 높은 CTA 버튼을 어떻게 사용하는지에 따라 사용자의 집중도나 클릭율이 높아질 수 있는데요. 단순히 일주일 혹은 한 달 동안 쌓아놓은 이야기를 전달하는 뉴스레터가 아닌, 그때그때 일어나는 이슈에 따라 다양한 포맷과 형식으로 뉴스레터를 전하는 것은 어떨까요? 



출처 Really Good Emails

by 사슴발자국








Posted by slowalk