스티비(Stibee)

스티비는 “깔끔한 뉴스레터를 쉽고 빠르게 만들고 싶을 때” 사용할 수 있는 이메일 마케팅 서비스를 제공하고 있습니다.

슬로워크라는 소셜 섹터에서 다양한 활동을 하는 솔루션 그룹에서 2019년 분리하여 자회사로 출발한 스티비는 현재 20,000개가 넘는 팀이 사용하고 있을 뿐 아니라, 분리하던 시점부터 손익분기점을 계속해서 넘겨오며 사업 모델의 수익성을 증명하고 있습니다.

이제까지 누적된 10억 건에 가까운 이메일 발송 내역과 2천만 명이 넘는 이메일 구독자를 바탕으로1 앞으로 이메일 마케팅에 그치지 않고 종합적인 콘텐츠/마케팅 솔루션을 제공하는 업체로 거듭날 것으로 보입니다.

과제

스티비 임호열 대표는 하루개발을 신청하는 이메일에서 이미 구체적인 과제를 제시해주었습니다.

  • 스티비 에디터에서 사용되는 동영상 미리보기 상자 개선
  • 스팸 차단 리스크를 줄일 수 있는 발송서버 구조 만들기
  • 다수의 주소록에 존재하는 유니크한 구독자 수를 계산하는 방법
  • 개발팀 팀빌딩에 관한 이야기

이메일은 초기에 일반 문자열만을 보낼 수 있었지만, 이후 다양한 정보를 표시하기 위해 HTML 이메일이 요구되었고, 다양한 이메일 클라이언트에서 이를 지원하면서 보편적으로 사용할 수 있게 되었습니다. 이 과정에서 표준 없이 부분적인 HTML 요소를 서로 다르게 도입하여 같은 내용이 다르게 표시되는 문제가 있습니다. 이를 해결하기 위한 이메일 표준화 프로젝트 등의 시도가 있었지만, 여전히 다양한 클라이언트에서 동일한 모습으로 표현되는 완성도 있는 이메일을 작성하기 위해서는 섬세한 기술이 요구됩니다.

이에 스티비는 자체 이메일 에디터를 구현하고 꾸준히 개선할 필요가 있어, 초창기부터 많은 노력을 기울여 왔습니다. 첫 번째 과제는 이메일 에디터에서 영상의 링크를 첨부하는 경우 자동으로 썸네일을 생성해 메일에 넣고 영상으로 링크를 걸어주는 기능을 개선하는 것이었습니다.

해결 과정

기존 썸네일 생성 코드는 AWS 람다에 파이썬 2 코드로 작성되어 있었습니다. 처음 코드가 작성된 때에 비해 유튜브 영상의 대중적인 비율이 달라졌는데(4:3에서 16:9로) 여전히 과거 비율의 썸네일을 받아와 돌려주기 때문에 위아래에 레터박스가 있는 상태로 결과물이 나오는 문제가 있었습니다. 이에 높은 해상도를 가진, 적절한 비율의 썸네일 주소를 받아오는 동시에, 필요한 경우 레터박스를 잘라내는 크랍 코드를 추가해야 했습니다.

레터박스가 포함된 유튜브 썸네일

파이썬 코드를 수정해도 된다고 전달받았지만, 이미 지원이 종료된 파이썬 2 코드를 갱신하는 것보다, 회사의 선택 방향에 맞춰 고랭으로 재작성하는 게 좋겠다는 생각에 자주 사용해보지 않았던 고랭을 다시 익혀 과제를 해결하였습니다.

람다로 전달받는 주소는 영상 ID가 아닌, 사용자에게 입력받은 영상 주소 그대로이므로 이를 해석해 영상 ID를 알아내야 합니다. 현재는 유튜브 주소만을 처리하고 있지만, 앞으로는 다양한 영상 제공자를 처리해야 할 필요도 있습니다. (참고: Summernote의 영상 URL 처리부)

var re = regexp.MustCompile(
    `.*(?:youtu.be\/|v\/|u\/\w\/|embed\/|watch\?v=)([^#\&\?]*).*`
)
match := re.FindStringSubmatch(url)

유튜브의 경우 다양한 해상도와 비율의 썸네일을 제공해주지만, 영상에 따라 썸네일의 존재 여부가 다릅니다. 그래서 가장 높은 수준의 옵션부터 차례대로 요청하여 HTTP 응답을 확인하고, 정상적인 응답을 받는 경우에 다음 과정을 처리하도록 했습니다.

qualityList := []string {
    "maxresdefault",
    "hqdefault",
    "mqdefault",
    "sddefault",
    "default",
}

썸네일을 얻어온 후에는, 아이콘 이미지를 지정된 위치와 비율로 합성합니다. 이 과정에서 아이콘 이미지를 외부(S3 등)에서 가져오면 낭비라고 생각해, 만든 이미지를 base64 인코딩하여 소스 코드 패키지에 문자열 형태로 포함했습니다. 추후 확장을 위해 이미지를 인코딩하는 소스코드까지 함께 작성하여 제공했습니다. 고랭에는 JPEG Encode가 내장되어 있어 최종 결과물을 JPEG로 출력하도록 했습니다. 하지만 더 작은 크기에 나은 화질을 예상할 수 있는 WEBP의 경우 디코더만 제공되고, 인코더는 외부 모듈을 사용해야 합니다. chai2010/webp를 사용해서 인코딩이 정상적으로 이뤄짐은 확인했지만, AWS 람다 패키지로 빌드하는 과정에서 실패하여 제외하였습니다.

레터박스가 제거되고 아이콘이 합성된 결과물

추가 작업

스팸 차단 리스크를 줄일 수 있는 발송서버 구조 만들기

이메일 서비스 제공자별로 스팸 메일을 인식하고 차단하는 방식은 모두 다르고 악용을 막기 위해 완전히 공개되어 있지 않아, 다양한 경로를 통해 입수한 여러 방법을 모두 적용하고, 계속해서 달라지는 처리 방침에 대응해야 하는 어려움이 있습니다. 이와 같은 종류의 문제가 그렇듯 정답이 없고, 지속적인 관찰과 데이터 분석이 요구됩니다. 대중적으로 알려진 SPF 레코드 등을 등록하는 수준으로 다수의 이메일을 성공적으로 발송하기가 어렵습니다.

다수의 주소록에 존재하는 유니크한 구독자 수를 계산하는 방법

스티비는 RDBMS를 주 데이터베이스로 사용하고 있으며, 하나의 테이블에 모든 구독 정보를 보관하지 않고 자체적인 기준으로 나눠 상당히 많은 테이블에 나눠 보관하고 있습니다. 데이터 분석을 위해 이 많은 테이블로부터 중복 주소를 제거하고 고유한 이메일 주소가 몇 개나 존재하는지 쉽게 확인할 수 있는 방법에 대한 문의를 받았습니다. 저는 이런 경우 중복 쓰기를 사용하면 좋겠다는 의견을 냈습니다. 성능과 그 외 발생할 수 있는 잠재적인 문제를 고려하면 테이블을 하나로 합쳐서는 안 되고, 대신 별도의 테이블에 해시화된 이메일 주소를 UNIQUE 제약 조건이 걸린 필드에 추가하게 되면 큰 부담 없이 항상 총 숫자를 알 수 있겠습니다.

개발팀 팀빌딩에 관한 이야기

소규모 업체의 팀빌딩은 언제나 어려운 이야기입니다. 작은 조직일수록 제공할 수 있는 내용이 특별하거나 탁월하기 어려워, 해당 조직이 풀고자 하는 문제의 도메인이 남다르거나, 남들은 잘 다루지 않지만 사회에서 중요하게 다뤄야 하는 문제를 해결하려는 개성이 있어야 그나마 구직자들에게 회사의 존재라도 알릴 수 있습니다.

비록 단시간이지만 살펴보고 경험해본 스티비에서 다음과 같은 특징을 발견하여, 이를 강조하여 구인하면 좋겠다는 의견을 냈습니다.

  1. 고랭을 백엔드로 사용하는 것.
  2. 트래픽이 메일 발송 여부에 따라 발생하므로, 예측 가능한 트래픽을 효율적으로 처리하는 환경.
  3. 성장하고 있는 서비스와 사업 분야.
  4. 쌓여 있는 사용자 정보와 이용 데이터가 엄청나게 많지만, 제대로 분석해서 서비스 개선에 활용한 적이 없다는 점.

더 알아보기

영상


  1. 스티비 이메일 리포트와 하루개발 촬영분 참고 ↩︎