ETL vs ELT, 당신의 선택은?

여러분, 데이터를 수집하고 처리하여 분석할 수 있는 상태로 만드는 데에도 여러가지 접근 방식이 있다는 것을 알고 계셨나요? 오늘은 데이터 파이프라인에서 취할 수 있는 두가지 주요한 동작 방식인 ELT와 ETL에 대해 이야기해보려고 합니다. 특히, 딜라이트룸이 왜 ELT 방식을 택했는지, 그로 인해 어떤 이점을 기대할 수 있는지 살펴보겠습니다.

ETL(Extract — Transform — Load) 이란 무엇일까요?

데이터 처리의 맥락에서 ETL은 데이터를 추출(Extract), 변환(Transform), 그리고 적재(Load)하는 전통적인 방식을 말해요. 각 단계는 말 그대로, 데이터를 소스에서 가져오는 ‘추출’, 원하는 형태로 가공하는 ‘변환’, 그리고 최종 목적지에 저장하는 ‘적재’로 이루어져 있죠.

그런데 여기서 중요한 포인트는 ‘변환’ 단계입니다. ETL은 데이터를 목적지에 저장하기 전에 먼저 가공합니다. 이는 우리가 필요한 데이터만을 선택적으로 저장하고, 우리의 저장소를 효율적으로 활용하기 위한 과정이에요.

ETL은 다음과 같은 장점이 있습니다:

• 효율적인 저장 공간 사용: 꼭 필요한 데이터만 최종적으로 우리의 목적지 데이터 저장소에 쌓이게 되므로 효율적으로 저장 공간을 사용하게 됩니다.

• 보안과 규정 준수: 변환 과정에서 원본 데이터에 있던 민감한 정보를 제거하거나 GDPR, HIPAA 등 다양한 규정에 맞추기 용이합니다.

• 검증된 기술: 역사가 오래된 만큼 지금까지 많은 관련 지식이 쌓였고 도구나 전문가들도 더 쉽게 찾을 수 있습니다.

하지만 다음과 같은 단점도 가지고 있죠:

• 까다로운 유지보수: 데이터의 종류와 양이 늘어나면서, 변환 과정을 맞춤 설정하고 유지하는 일이 점점 더 복잡 해 집니다.

• 높은 변환 단계 운용 비용: 대량의 데이터를 처리 하려면, 변환 단계에서도 상당한 컴퓨팅 자원이 필요합니다. 이를 위한 별도의 시스템이 필요하고, 그만큼 운영 비용도 올라갑니다.

• 낮은 유연성: 변환 단계에서 이미 데이터의 최종 형식을 정해두기 때문에, 나중에 다른 형태의 데이터가 필요할 때 대응하기 어렵습니다.

ELT(Extract — Load — Transform)는 어떤 방식일까요?

ELT는 ETL과는 다르게, 데이터를 추출한 다음 바로 적재(Load)하고, 그 후에 변환(Transform)하는 방식이에요. 이 방식은 최근에 현대적인 클라우드 데이터 웨어하우스의 발전과 함께 더욱 주목받기 시작했습니다.

ELT의 장점은 다음과 같아요:

• 간단한 시스템 구성: 데이터를 변환하는 작업은 데이터 웨어하우스에서 이루어지기 때문에, 복잡한 네트워킹이나 컴퓨팅 자원 관리에 대한 걱정이 줄어듭니다.

• 높은 유연성: 원본 데이터를 보유하고 있어서, 필요할 때 언제든지 재가공이 가능합니다.

• 적재 외주화: 완전히 정리된 형식의 데이터가 아니더라도 일단 원본 데이터를 그대로 적재를 해두고 변환만 내부적으로 하면 되므로, 적재 과정을 외부에 맡기기 용이합니다. 특히 다양한 소스로부터 데이터를 받아와야 하는 경우 추출, 적재 부분을 직접 구현, 유지보수하는 비용을 아낄 수 있습니다.

반면에 ELT는 다음과 같은 단점도 있습니다:

• 보안과 규정 준수: 아무래도 원본 데이터를 모두 적재해두고 사후에 변환하기 때문에 준수해야할 규정에 맞지 않는 데이터까지 적재하게 될 수도 있습니다.

• 비효율적인 저장 공간 사용: 실제 당장 꼭 필요한 데이터보다 더 많은 데이터를 미리 적재해두고 사용 하므로 아무래도 저장 공간을 더 많이 사용하게 됩니다.

딜라이트룸에서 ELT를 도입한 이유는 무엇일까요?

딜라이트룸은 초기에 ETL 방식을 사용했었습니다. 하지만 시간이 지나면서, 변환 레이어의 복잡성과 운영 비용이 증가하는 것을 체감했어요. 또한, 데이터 양이 많아지면서 변환 과정과 적재 과정에서 발생하는 트래픽 비용, 시간 소요, 네트워크 전송 실패 등 여러 문제가 발생했습니다.

이러한 문제들을 해소하고자 저희는 ELT 방식을 도입해 보았습니다. ELT 방식은 기본적으로 데이터를 먼저 적재하고, 필요에 따라 데이터 웨어하우스 내에서 처리를 합니다. 이로 인해 관리해야 할 요소가 줄어들고, 데이터 모델링에 있어서도 더 많은 자유와 유연성을 가질 수 있게 되었습니다.

개발자의 자원이 매우 소중한 소규모 스타트업의 특성상 EL(추출-적재) 파트를 외주화 할 수 있는 점도 중요한 요인이었습니다. Fivetran과 같은 서비스를 사용하여 직접 개발을 최소화 하며 다양한 데이터 소스로부터 안정적으로 데이터 적재가 가능하였습니다. 혹은 서드파티에 따라서 우리의 데이터 레이크(AWS S3)로 데이터를 푸쉬해주는 기능이 있다면 적극 활용하여 파이프라인을 단순화 시키고 있습니다.

이미 모든 데이터를 받아두었으므로, 변환은 단일 데이터 웨어하우스내에서 수행할 수 있습니다. 이때는 dbt와 같은 도구의 도움을 받아 데이터 모델링 및 변환 수행 과정을 일관적인 코드(SQL + a)로 정의하고 표준적인 방법으로 문서화 및 변화 추적을 할 수 있습니다. 이에 대해서는 별도의 글에서 더 자세히 소개하여 보겠습니다.

요약하면, 저장 공간에 비용을 더 들이는 대신, 개발 비용과 운영 복잡도를 감소시키고 유연성을 얻는 일석삼조의 효과가 있었습니다. 현대의 클라우드 환경에서 저장공간은 매우 저렴한 편이므로 이러한 트레이드오프를 감수할 만 한 가치가 있었다고 볼 수 있습니다.

결론

ELT 방식은 현대 데이터 환경의 복잡성과 비용 문제에 대한 한 가지 해답을 제시하고 있습니다. 데이터 관리의 유연성을 높이고, 비용을 절감하며, 시스템의 복잡성을 줄이는 데 큰 도움이 되죠. 하지만 모든 상황에 맞지는 않을 수 있기 때문에 장단점을 잘 따져 볼 필요가 있습니다. 파이프라인 일부에 대해 점진적으로 시험삼아 적용해보는 것도 방법입니다. 데이터를 중심으로 하는 비즈니스를 운영하신다면, 그리고 아직 ETL 방식을 고수하고 계신다면 ELT의 도입을 시도해 보시는 것을 추천드립니다!

⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다

🙌딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!

• 지금 바로 미디엄 팔로우하고 다음 아티클도 빠르게 만나보세요!

• 딜라이트룸 소식을 가장 빠르게! 딜라이트룸 링크드인 🔗

• 높은 평점으로 난리난 딜라이트룸 잡플래닛 ✅

• 딜라이트룸 일상을 엿볼 수 있는 인스타그램 📸

• 더 다양한 딜라이트룸의 모습을 확인할 수 있는 유투브 💌
  

신규 기능을 유저들에게 알리는 다양한 전략! 💘

지난 글 "전환율 10배 높여주는 치트키"에서
유저가 기능을 인지하는 임팩트가 가장 큰 홈엔트리 전략을 소개했다면

이번에는 기능의 존재는 인지하고 있으나 귀찮아서,
또는 까먹어서 기능을 찾으려 하지 않는 유저들에게
뾰족하게 다가가서 퀄리티 높은 유입을 가져오는 전략을 소개합니다 🙌

어떻게 해야 퍼널별 전환율을 더 높일 수 있을까? 🤔

알라미팀의 Monetization PO 스테판이
수없이 다양한 실험을 통해 직접 부딪혀가며
터득한 퍼널 최적화 전략에 대해 아래 링크에서 살펴보세요!

#퍼널별전환율 #그로스 #growth #전략 #PO #딜라이트룸

크로스 플랫폼 독인가? 약인가? 딜라이트룸 생각은?

작성자 — Jason, Tech Lead @DelightRoom

요즘 어때?

요즘 종종 보는 지인들과 보통의 첫마디가 “요즘 어때?”입니다.

대부분 스타트업에 종사해서, ‘스타트업 한파’를 온몸으로 받아내고 있기 때문에 더욱더 서로의 안위를 많이 물어봅니다.

특히, 경영 악화로 구조조정, 채용 중지, 운영 비용 축소 처럼, 현재 힘든시기를 벗어나려는 노력에 대해서 자주 얘기가 나오곤 합니다.

그중에도 개발 모임(기술 교류 및 자문)에 가면 아무래도 타이트한 리소스에 해내야하는 업무는 많기 때문에, 다양한 생산성 이야기가 나옵니다. 스타트업이 겨울이여도 사용자에게 전달해야하는 가치는 줄지 않기에, 고민이 깊어지기 마련이죠.

그럴때마다 꼭 나오는 이야기가 바로 크로스플랫폼 개발이야기 입니다.

체감상 한국에서도, 2018부터 ReactNative를 주요 개발스택으로 고려하는 움직임들이 있었던것 같습니다.

(이후, 구글에서 출시한 Flutter도 관심이 높아지면서 점점 개발 커뮤니티에서는 크로스플랫폼에 대한 열기가 달아 올랐었습니다.)

크로스플랫폼 어때?

리소스가 부족할때, 가장 쉽게 떠올리는 솔루션으로 크로스플랫폼 개발이 종종 언급됩니다. 궁극적으로는 크로스플랫폼은 생산성 이슈를 해결하는 방법중 하나일텐데요.

아, 크로스플랫폼에 대해 더 들어가기 전에 간단히 소개를 드려보면, 개발 한번으로 iOS와 Android 앱을 모두 만들어내는 것이라고 생각하면 되겠습니다.

(보통, 앱 만들때 ‘iOS 앱개발’과 ‘Android 앱개발’ 이렇게 두번 개발하게 되는데, 이것을 한번의 개발로 줄인다고 생각하시면 되요)

크로스플랫폼에 대한 분명한 기대는 “one source multi use”에 있을것입니다. 그로 인해 궁극적으로 생산성 2배를 기대하며, 제품을 만들어가게 될것입니다.

그런데 사람들이랑 만날때 마다 “진짜 이거 생산성 2배 맞아?”라는 이야기를 자주 하게 됩니다.

왜냐하면 대표적인 크로스플랫폼(ReactNative, Flutter)으로 만든 서비스의 성공사례를 쉽게 듣기 어렵고, 그나마 알려진 회사들은(페북, 인스타, 그랩, 디스코드) 개발자만 이미 100명 넘는 회사인 경우여서, 전체 회사 규모가 100명 이하인 스타트업에서는 또 그것대로 공감하기 어려운 것도 있기 때문이죠.

그렇다면 크로스플랫폼으로 생산성 향상이 가능한지 장단점을 하나씩 뜯어 보면서 알아보려고 합니다.

그전에 한가지 전제가 있는데요. 비즈니스 문제중에는 크로스플랫폼으로 잘 풀수 있는것과 그렇지 않은것이 있다고 생각합니다.

크게 나누어보면 크로스플랫폼으로 ‘구현 가능한 것’과 ‘불가능한것’으로 먼저 나누어 볼수 있구요.

크로스플랫폼으로 구현 가능한것 중에서도 난이도가 ‘높은것’과 ‘낮은것’으로 나누어 볼수있다고 생각했습니다.

위의 전제를 그림으로 도식화해보면 아래와 같습니다.

크로스플랫폼으로 풀수있는 문제 도식화

장점

• 여러 플랫폼에 재사용할수 있는 코드

• 빨라진 개발 속도

• 적은 유지 비용 들어감

• 빠른 마켓 타이밍(iOS, An에 한번에 출시하니까)

단점

• 하드웨어 지원이 필요한 기능에, 추가 개발 리소스가 들어감 (크로스플랫폼에서 바로 지원안되는 경우도 있고, 지원되더라도 구현간 퍼포먼스등의 어려움이 있는 경우가 있음)

• 일반 네이티브 제품보다 퍼포먼스가 느림

• 각 플래폼별로 가이드하는 디자인 원칙을 일관적으로 따를수 없음 (Human Interface Guide, Material Design 을 모두 지키면서 일관성 있는 UX를 만드는게 어려움)

위에서 나열한 장단점은 일반적인 내용이라서, 실제로 의사결정간에 충분한 근거가 되지 않는다고 생각합니다. 그리고 정말 개발속도와 유지비용이 적게 들어가는 것인지 의문이 드는 경우도 있습니다.

먼저 스타트업에서는 크로스플랫폼을 선택하기 전에 정해야 할것은

• 현재 타겟하는 구체적인 사용자는 누구인가? (페르소나)

• 현재 제공하려는 사용자 가치는 무엇인가? (사용자 가치)

• 사용자 가치에 핵심이 되는 기능은 무엇인가? (핵심 기능)

위에 내용을 기반으로 사용자 문제를 정의하고 고객의 만족을 빠르게 줄수 있는 방법으로써, 크로스플랫폼이 가능하다고 충분한 리서치가 되면 의사결정할 수 있다고 생각합니다.

충분히 리서치 할때는 이런 기준들이 있을수 있다고 생각합니다.

• 핵심 기능은 디바이스 서포트가 많이 필요한 것인가?

• 핵심 기능간에 기대되는 최소 퍼포먼스는 어느정도인가?

• 크로스 플랫폼을 개발한다고 했을때, 워크플로우는 충분히 효율적인가?

• 핵심 기능 제공시, UX가 양쪽 플랫폼의 기본 디자인 원칙을 따를수 있는가?

• ….

결국에는 회사가 처한 상황에 맞게 사용하면 된다고 생각하는데요.

검색해보면 알겠지만, 생각보다 크로스플랫폼 사용에 대한 배움? 경험?을 자세하게 공유한 사례가 없긴합니다.

대표적으로는 Airbnb가 ReactNative를 누구보다 열심히 쓰면서, 얻은 교훈과 고민들을 자세하게 나누어 준 내용이 있어서, 그나마 도움이 많이 되었습니다. (내용이 상당히 알차고 꿀잼입니다. 결국 2018년도에 리액트네이티브 접고, 다시 네이티브 선언을 하긴 했지만요)

참고하시면 좋기 때문에 링크를 달아 놓아보아요.

1) AirBnb에서 리액트 네이티브

2) 기술로써 리액트 네이티브

3) 크로스 플랫폼 팀 조직하기

4) 리액트네이티브 접기로 정하다

5) 앞으로 AirBn에서 모바일 개발 방향성

그렇다면 딜라이트룸은 어떻게 크로스플랫폼을 바라보고 있는지 이어서 같이 보려고 하는데요.

그전에 제품 개발 철학에 대한 내용부터 나눠보겠습니다.

확장 가능하지 않은 일을 해라

확장 가능하지 않은 일을 해라

딜라이트룸 제품 개발 철학 기저에는 “확장 가능하지 않은 일을 해라”가 깔려있는데요.

(대표님인 제이께서, YC를 만드신, 폴그레이엄을 엄청 좋아하시고, 그 분의 에세이를 사랑하시는데요. 그중에서도 “확장 가능하지 않은 일을 해라”는 번역까지 해주셨었죠.)

제가 폴그레이엄의 에세이를 읽고 느꼈던 인상적인 부분은,

고객의 행복을 위해서는 자동화, 스케일, 엔지니어링, 심미적 요소의 탁월함 따위가 중요하지 않고, (특히 초기 사용자에게)

고객의 욕구를 만족시키기 위해서 지금 해줄수 있는 것을 빨리 찾아서 해줘야 한다는 것이였습니다. (비록, 비효율적일지라도..)

고객에게 집착하려는 제품 개발문화가 있는 딜라이트룸에서는, “확장 가능하지 않은 일을 하라”는 멤버들에게 여러 울림을 주었습니다.

그래서, 확장 가능하지 않은일은 할때,

• 고객의 문제를 훨씬 자세하고 깊게 파악할수 있고

• 그것을 기반으로 더 큰 고객 만족을 줄수 있고

• 그렇게 했을때, 오히려 더 확장 가능한 방법을 찾을수 있다

는 믿음을 가지고 일하고 있습니다.

그렇다면, “’확장 가능하지 않은 일’은 구체적으로 어떤거지?” 궁금할텐데요.

몇가지 구체적인 사례를 들어보도록 하겠습니다.

✅ Stripe 사례

문제: 사용자가 Stripe 설치후, 사용간 생기는 이슈를 알고 싶음

• 확장 가능한 일: 사용자가 웹사이트가서 알아서 설치하고, 사용성 이슈를 온라인으로 리포팅함

• 확장 가능하지 않은 일: Stripe을 한번 사용해본다고 하면, 바로 “컴퓨터 줘봐”하고 바로 서비스 설치해 주고 사용하는 것도 관찰

✅ Airbnb 사례

문제: Airbnb를 사용하는 고객(방을 빌려주는 사람)의 니즈와 욕구에 대한 의견을 받고 싶음

• 확장 가능한 일: 어느 나라의 고객이던 사용간 니즈를 온라인을 통해서 의견을 받음

• 확장 가능하지 않은 일: 뉴욕 고객의 니즈 및 욕구를 구체적으로 듣기 위해서 뉴욕으로 날아감

✅ 딜라이트룸 사례

문제: 알람이 울릴때, 핸드폰을 꺼서 일어나야함을 놓치는 이슈를 방지하고 싶음

• 확장 가능한 일: 양쪽 플랫폼에서 동일한 방법으로 핸드폰 끄는 방법을 방지함

• 확장 가능하지 않은일:

• Android 사용자: 시스템 기능을 이용해서 전원 끄는 화면을 켰을때, 그 위로 알라미 화면이 자꾸 뜨게 만들어 결국 전원을 못끄게 방해함

• iOS 사용자: iOS는 전원끄기 화면을 켰을때 방해 할수 없으므로, 전원 꺼짐을 알아차려서 폰을 켰을때 노티 폭탄 줍니다. 그때라도 알림 노티를 알려주는 것이죠. 한번 알람을 놓칠수 있지만 다음에 핸드폰을 끄려할때, 노티 폭탄에 대한 부담으로 함부로 끄기 어렵게 만드는것이죠.

(위 기능들은 당시 사용자들에게 상당한 만족감을 주었지만, 현재는 OS가 업데이트되고시스템 권한이 엄격해짐에 따라 해당 기능은 없어졌습니다. 다만 다른 방향으로 사용자 니즈를 풀어드리는 기능을 제공하고 있습니다)

사례들을 보면 “확장 가능한 일”은 상당히 이상적인 솔루션 보이지만, 실제로 문제에 직면했을때 사용자 문제를 바로 해결하기 어려운 경우가 종종 있습니다.

딜라이트룸의 사례에서도 만약 확장 가능성을 고려해서 크로스플랫폼을 사용하고 있었다면, 기존의 솔루션을 만드는 것은 거의 불가능했을것이라고 생각합니다.

아마도 집요하게 해당 이슈를 파고들지 못했을 것이고 “사용자가 핸드폰 끄는것은 어쩔수 없지”라고 생각하고 넘겼을것 입니다.

결국 확장가능하지 않더라도 고객의 문제를 각 플랫폼에서 풀어줄수 있는 방법만 있다면, 집요하게 파고들수 있도록 열어놨기 때문에 빠른 고객 문제 해결을 이뤄낼수 있었다고 생각합니다.

돌아보면, 악마는 디테일에 있었던 것이죠. 안될것 같은 고객의 니즈도 플랫폼별로 살짝 다른 솔루션을 통해 작아보이는 만족감까지 챙겨가면서요.

네이티브로만 풀수있는 문제로 고객 만족의 사례

WTH? 메타, 구글?

또 한가지 하고 싶은 이야기! 제작자들이 열심히 안씁니다.

개인적으로 제품 제작자가 본인 제품 많이 안써보는 것을 태만하다고 보는데요.

애착있는 제품 제작을 위해서는 이것은 필수라고 생각해요.

그런데 제가 느끼기에는 크로스플랫폼 제작자들 사이에서는 이런 사랑? 애착이, 요즘들어 잘 안느껴지긴 합니다.

특히, 요즘 크로스플랫폼의 양대산맥이 Flutter와 ReactNative인데요. 각각 구글, 메타가 제작자입니다.

그나마 메타는 페북과 인스타그램을 통해, ReactNative를 깊게 사용했었는데이런 솔선수범 덕분에 ReactNative를 사람들이 많이 채택했다고 생각해요.

“아, 페북, 인스타에서도 이정도 성능으로 쓸수 있다면 해볼만 하겠다”하고 써보는 것이죠.

다만, 최근에 메타의 큰 베팅이었던 쓰레드는 네이티브로 만들어졌다고 하는데요.

이부분에서 제작자의 사랑이 식은것 아닌가? 이런 생각이 들었습니다.

그보다 더 심각하다고 생각한건 구글입니다.

구글은 Flutter를 서포트 하고 있지만, 정작 구글의 중추가되는 서비스에서 사용하는 것을 본적이 없기 때문입니다.

(iOS 앱들을 까보면, Flutter를 쓰고 있는지 확인할수가 있는데요. 기본적인 Google Workspace 앱이랑, 유투브, 유투브 뮤직 들은 Flutter를 안쓰고 있는 것을 알수가 있었습니다.)

결국, 크로스플랫폼이란 개발 도구도 제작자들이 적극적으로 써보면서 개선을 시켜야하는데, 이런 식이면 믿음이 점점 떨어질수 밖에 없다고 생각이 들었습니다.

결론

정리해보면, 크로스플랫폼이 독이 될지, 약이 될지는 그 자체에 있다고 생각하지 않습니다.

더 중요한것은, ‘고객을 어떻게든 빠르게 만족시킬수 있어야함’을 아는 것이라고 생각합니다.

그런 측면에서, “확장 가능하지 않은 일을 하라”에세이를 꼭 읽어보시는 것을 강력 추천합니다.

그리고나서 현재 풀고 있는 문제들을 자세하게 이해하는 것이 중요하다고 볼수 있겠습니다.

우리가 풀고 있는 문제들은 어떤 도메인에 속하는지, 이미 풀어낸 문제들은 어떤 속성을 가지고 있는지 등등 말이죠. 특히, 개발팀을 이끌고 계신 팀장님들께서 이런 부분을 자세하게 숙지하고 있어야, 그에 맞는 적정기술을 쓸수 있다고 생각합니다.

그렇게 하면, 가끔 경영진에서 얘기하는 “크로스플랫폼을 쓰면, 훨씬 개발 속도 빨라지는것 아냐?”라는 질문에 동공지진 일어나지 않게 되겠죠.

이렇게 자세하게 이해하면, 각 팀이 속한 상황에서, 크로스플랫폼이 독인지, 아니면 약인지 알수있게 되겠죠.

약도 남용, 오용하면 안되는 것처럼 적절하게 써야하는 것이죠.

문제에 따라 다르긴 하겠지만, 개인적으로는 네이티브로 좁은 타겟과 뾰족한 문제로 시작해보는것도 방법이라고 생각합니다.

⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다

🙌딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!

• 지금 바로 미디엄 팔로우하고 다음 아티클도 빠르게 만나보세요!

• 딜라이트룸 소식을 가장 빠르게! 딜라이트룸 링크드인 🔗

• 높은 평점으로 난리난 딜라이트룸 잡플래닛 ✅

• 딜라이트룸 일상을 엿볼 수 있는 인스타그램 📸

딜라이트룸에서 일하는 방식

알라미는 어떤 문화에서 만들어지고 있나요?

작성자 : Jay — CEO @DelightRoom

딜라이트룸에서는 어떻게 목표를 정하고 우선순위를 정할까? 알라미를 만들어가는 문화에 대해 자주 들어오는 질문 Top4 를 간단히 정리해 보았다.

1. 목표를 어떤 식으로 정하나요?

딜라이트룸에서는 OKR 을 이용하여 목표를 관리하고 있으며, 분기별로 Company OKR 이 정해지면, 각 팀에서 Company OKR 을 달성하기 위한 Team OKR 을 설정하는 시간을 가진다.

Company OKR

여기서 중요하게 생각하는 부분은 Company OKR 이 먼저 정해진 후에 Team OKR 로 넘어가는 부분이다. 모든 구성원이 한 방향으로 나아가게 만들기 위해 회사가 중요하게 생각하는 방향성을 먼저 공유하고, 그 방향성에 대해 궁금한 부분이나 의견이 있다면 이야기를 주고받을 수 있는 피드백 기간을 가진다.

Team OKR

Company OKR 이 정해진 후에 각 팀에서는 이를 달성하기 위한 Team OKR 을 설정한다. 이 과정에서 목표치와 세부 방향성은 팀에서 주로 정하고 회사와 싱크한다. 이렇게 설정된 각 팀의 OKR 은 분기별로 있는 전사 워크샵에서 공유된다.

각 팀별 분기 회고 & 다음 분기에 중요하게 생각하는 부분들 공유 시간

딜라이트룸에서는 분기별로 하루를 전사 OKR 리뷰&플래닝 시간으로 사용하는데, 이때 각 부서가 어떤 결과물을 만들어 왔고, 어떤 레슨을 얻었으며, 이를 바탕으로 다음 분기에는 어떤 방향으로 나아갈지를 싱크하는 의미 있는 시간이다.

전사 OKR 리뷰 및 플래닝 시간을 통해 각 팀이 각자의 목표만을 추구하는 것이 아니라 모두 한 방향으로 잘 가고 있는지를 확인하고, 서로의 목표를 한층 더 잘 이해할 수 있다. 더 나아가 각 팀이 서로의 목표를 달성하기 위해 도움을 주는 분위기도 만들어진다.

2. 업무 우선순위를 어떻게 정하나요?

OKR이 잘 설정되었다면, 이제 각 팀에서 OKR 달성을 위해 백로그를 만들고 우선순위에 맞춰서 진행할 차례다. 아무리 목표가 잘 정해져도 우선순위가 불명확한 채로 주먹구구식으로 이뤄지면 성과를 내기 어렵다. 딜라이트룸에서 각 팀이 업무의 우선순위를 정하는 방법은 크게 두 가지 키워드로 표현된다.

ICE 프레임워크

서로 중요도를 이야기 할 때 공통의 언어가 있어야 효과적으로 소통할 수 있다. 우리는 공통으로 업무 우선순위를 정하기 위해 ICE 프레임워크를 사용하고 있다. 이는 주먹구구식으로 우선순위가 정해지지 않도록 방지하고, 제한된 리소스에서 가장 좋은 성과를 낼 수 있도록 만들어 준다.

간단하게 말하면 Impact, Confidence, Ease 세 가지를 고려하여 우선순위를 정하는 것으로 “얼마나 임팩트가 있는 일인지?”, “얼마나 이 일에 확신이 있는지?”, “얼마나 리소스가 적게 드는 일인지?” 세 가지 축으로 점수를 매긴다. (조금 더 상세히 알고 싶다면, 이 글을 참조)

ICE 를 사용해 우선순위를 맞추면서 팀 내 구성원들이 서로 각 백로그들이 왜 중요한지 쉽게 싱크하게 된다.

그 과정에서 자연스럽게 PM/개발자/디자이너가 서로의 관점으로 피드백을 주고받으며 서로가 공감하는 우선순위로 업무가 진행된다.

유연함

목표가 명확하게 싱크 되고 공통의 언어가 정해졌다면 목표를 달성하기 위한 디테일한 프로세스는 각 팀에게 맡긴다. 팀별로 처한 환경이 다르기 때문에 각 팀에서 효과적이라고 생각하는 방식으로 프로세스를 설립하고 개선한다.

2주 단위의 지속적인 플래닝&회고를 통한 점진적 개선

여기서 핵심은 각 팀에 맞는 운영방식을 계속해서 찾아가는 것으로 팀별 스프린트 회고를 통해 각 팀에 최적인 프로세스를 만들어가는 것이다.

이를 위해 모든 팀은 2주 단위 스프린트로 회고를 하며 좋았던 점 아쉬웠던 점을 공유하고 다음 스프린트에서 새롭게 시도하거나 변경하고 싶은 것들을 이야기한다. 이렇게 지속적인 개선을 시도하면서 각 팀에 최적화된 업무 프로세스로 발전시키고 있다.

3. 사용자 중심적인 제품 문화를 가지고 있다던데요?

딜라이트룸에 합류하면 가장 많이 듣게 되는 단어 중 하나가 바로 “사용자”라는 단어일 것이다. 물론 모든 회사가 사용자를 중요하게 생각하겠지만, 우리는 어떻게 하면 사용자 입장에서 생각하고 행동할 수 있을지를 끊임없이 고민하며 여러 시도를 하고 있다.

VOC 미팅

매주 CPO, PM, Dev lead, Design lead, POM(Product Operation Manager) 가 모두 모여 VOC 를 리뷰하는 시간을 가진다. 단순히 정리된 내용을 훑는 정도가 아닌 모든 VOC의 원문을 함께 확인하고 논의한다.

실제로 매주 모두가 함께 리뷰하는 VOC 원문 예시

여기서 중요한 것은 단순히 사용자가 제기하는 문제와 제안을 100% 반영 하는 것을 목표로 두는 것이 아니다 .각 팀에서 해당 사안에 대해 어떻게 생각하는지 의견을 듣고 중요도를 싱크하여 온도 차이를 줄이는 것이다.

실제로 처음 VOC 미팅을 진행하면 하나의 문제에 대해서도 어느 팀은 “빠르게 수정해야 한다”라고 생각하고, 어느 팀은 “다른 이슈가 더 중요하다”와 같이 말하는 온도 차이를 발견할 수 있다. 이렇게 되면 장기적으로 팀 간에 이해도가 떨어지고, 장기적으로는 제품이 삐걱 거리며 사용자를 잘 이해하지 못하는 제품이 나온다.

VOC 미팅을 통해 이런 온도 차이를 줄이게 되면, 서로가 생각하는 우선순위에 대해 잘 이해하게 되면서 “왜 이 문제를 빨리 해결해주지 않는 거야!?”라는 말 보다는 “아.. 이 문제도 중요하지만, 우리는 더 중요한 문제를 해결하고 있지”라는 이야기를 하게 되는 것을 발견할 수 있다.

회의실 이름

딜라이트룸에서는 어떻게 사용자들의 문제를 해결해주고 삶을 바꿔줄지에 대한 고민을 항시 하고 있다. 실제로 우리의 서비스 덕분에 삶이 바뀐 사용자들의 스토리를 자주 확인하게 되는데, 이런 사용자들을 위하는 마음을 항시 간직하기 위해 회의실 이름은 아래와 같이 사용자의 스토리 + 별명으로 이루어져 있다.

딜라이트룸의 모든 회의실엔 스토리와 별명이 붙어있다

리텐션은 왕이다

사용자의 불편함은 곧 리텐션으로도 나타난다. 딜라이트룸에서는 제품을 개선하는 모든 실험에서 리텐션을 분석하고, 통계적으로 유의미하게 떨어지면 실험이 성공했더라도 다시 롤백하는 문화를 가지고 있다. 또한, 리텐션 만으로는 모든 사용자의 마음이 드러나지 않기 때문에, 변화로 인한 사용자 피드백을 항시 확인하고 있다.

4. 얼마나 데이터 친화적인가요?

딜라이트룸에서는 단순히 감에 의존해서 제품을 개선하는 것이 아니라 실제로 우리가 세웠던 가설이 통계적으로 유의미하게 검증되었는지 확인하고, 지표를 통해 얻을 수 있는 인사이트를 뽑아내어 공유하는 문화를 가지고 있다.

A/B 테스팅 + 전사 공유

2주 단위의 매 스프린트마다 수많은 A/B 테스팅이 이루어진다. 가설 검증 뿐만 아니라 다양한 지표 분석을 통해 사용자들이 우리가 추가한 기능이나 변화를 어떻게 받아들이고 사용하는지에 대해 인사이트를 얻는다 (참조: 알라미 A/B 테스팅 일지#1).

이렇게 각 팀에서 얻은 인사이트를 타운홀 발표에서 전사에 공유함으로써, 모든 구성원이 제품과 사용자에 대한 이해도를 높일 수 있게 만든다.

WDAS (Weekly Data Analysis & Seminar)

딜라이트룸에서는 모든 구성원들이 Amplitude 를 통해 모든 데이터를 확인할 수 있다. 평소에 데이터를 보고 분석하다 보면, 진행하던 업무와는 별개로 다양한 궁금증이 생기게 되는데 WDAS 시간을 통해 평소에 궁금했던 데이터를 분석하고 공유한다.

실제로 데이터 분석가가 아니더라도 쉽게 데이터를 보고 발견한 재미있는 현상을 공유하며, 그 과정에서 새로운 인사이트를 얻는 데이터 친화적인 문화를 가지고 있다.

예를 들면, 한/미/일 중 어느 나라가 평균 기상 시간이 빠른지와 같은 간단한 분석부터, 코로나가 한창일 때에 미국에서 락다운으로 인해 도시별로 평균 기상 시간이 얼마나 뒤로 밀렸는지와 같은 분석 등이 진행되었다. 이는 데이터 분석가가 아닌 구성원이 단순 궁금증에서 확인한 데이터였다.

끝으로 정리해보면, 딜라이트룸에서는 명확한 목표 설정을 통해 모두가 한 방향을 보게 만들고, 각 팀이 최적의 우선순위를 달성하는 기반으로 업무를 진행한다. 그러면서도 정량적&정성적 데이터를 기반으로 사용자 중심적으로 생각하는 제품 개발 문화를 가지고 있다.

이런 제품 문화에서 알람의 정의를 단순히 시간을 알려주는 도구가 아니라, 하루의 시작과 끝을 책임지는 웰니스 서비스로 바꿔나가는 것에 관심 있다면…

알람앱을 10년 동안 만들고 있다고요? 앞으로는요?

알라미의 미션과 비전 (+미션 회의론자의 미션 정하는 고군분투기)

이 글에서 정의하는 미션은 “우리는 사용자에게 어떤 가치를 주는가?”
비전은 “우리가 결국 이루고자 하는것이 무엇인가?”

미션과 비전은 과연 필요한 것인가?

고백하자면 창업 초기의 나는 미션과 비전에 대해서 매우 회의적인 사람이었다. 내공이 부족해서인지 아무리 관련 글을 읽고 다른 사람들과 이야기해 봐도 왜 미션과 비전이 필요한지 동의가 잘 안 되었다.

당장 PMF(Product Market Fit)도 맞추기 급급한 스타트업에 미션과 비전이라니? 소위 미션과 비전은 오랜 시간 동안 변하면 안 된다고 하는데, 아무것도 모르는 시작단계에 이를 세우는 것이 맞는 것일까? 과연 이것이 린하게 돌아가는 스타트업에 맞는 것일까? 그렇다면 미션과 비전은 꼭 필요한 것인가? 다른 회사들은 미션과 비전을 왜 정하는 것인가?

창업 초기에 미션과 비전에 대한 나의 시각

이야기를 나눠본 많은 사람이 미션과 비전은 필수적이라고 했지만, 실제로 회사가 이를 어떻게 활용하고 어떤 효과를 얻었는지에 대해서는 잘 와닿지 않았다. “의사 결정을 하는 데 도움이 된다”, “모두가 동기부여 되는 데 도움이 된다” 등의 대답을 들었지만, 이야기할수록 추상적인 이야기로만 들리며 뻔한 교장 선생님 훈화 말씀 같은 느낌으로 전락하는 경우가 대부분으로 느껴졌다.

당시 머리속을 멤돌던 생각이 바로 “과연 우리에겐 미션이 필요한 것일까? 필요하다면 어떤 미션과 비전이 필요할 것인가?”였다.

알라미의 미션 (Mission)

알라미는 미션이나 비전에 대한 정의 없이 시작했다. 처음에는 단순히 더 잘 일어나기 위해 개인적으로 만든 사이드 프로젝트가 점점 커지며 비즈니스가 된 것이지 처음부터 세상의 아침을 바꾸기 위해 시작한 것이 아니었다.

초기의 대부분 시간은 잘 일어나지 못하는 사용자들의 문제를 해결해주고 “이 앱이 내 인생을 바꿨다” 등의 사용자 피드백에 희열을 느끼며 제품을 개선해 갔다. 그러면서 점점 매출이 생기고 사용자들이 많아질수록 더 많은 사람에게 영향력을 끼치는 서비스로 성장했다.

늦잠 때문에 장례식까지 늦던 사용자의 알라미 간증(?) 영상 (링크)

서비스가 어느 정도 커지고 성장세가 주춤하게 되자, 여러 방향 중 우리가 어떤 방향으로 가야 하는지, 어떤 기능들을 개발할지 등에 대한 논의가 불거졌다. 우리가 타겟해야하는 사용자의 범위는 어디까지인지, 어떤 가치를 주는 기능들이 우선되어야 하는지에 대한 생각이 각기 달라지고 있던 것이다.

팀원들은 제품 방향성에 대한 각기 다른 시각을 갖게 되었고, 무엇보다 모두가 한 방향을 보고 나아가는 것에 큰 걸림돌이 되었다. 이러면서 “우리 서비스의 본질은 무엇이고, 결국 어떤 가치를 전달해야하는가?” 라는 질문이 자연스럽게 나오게 되었다.

이게 중요해! 아니야 저게 중요해! (그 당시 우리의 모습..)

생각해보면 알라미는 시작부터 “어떻게 하면 더 확실하게 잠에서 깰까?”에 대한 문제에서 시작했고 그 문제를 잘 풀수록 사용자들은 만족하고 회사는 성장했다. 알람의 본질은 단순히 시간을 알려주는것이 아니라 원하는 시간에 확실히 하루를 시작하게 만드는 것이었던 것이다. 결국, 사람들을 확실히 깨우는 것이 우리 앱이 주는 가치이자 집중해야 하는 방향이었다.

“Wake people up, fully and completely”
(사람들을 완전히 확실하게 깨우자)

위와 같이 미션이 명확해지자 제품의 방향성이 조금 더 뾰족해지고 구성원들 각각이 생각하는 제품의 본질이 자연스럽게 맞춰지기 시작하며 비효율적인 커뮤니케이션이 줄어들기 시작했다. 예를 들어, 다른 많은 알람앱에서 제공했던 스톱워치&타이머 기능은 “확실히 깨운다”라는 방향성과 맞지 않기 때문에 추가 하지 않았던 기능이다.

아이폰, 안드로이드 기본 알람앱에 있는 스톱워치와 타이머 기능 (초창기만 해도 해당 기능들을 넣어야 한다는 이야기가 나오곤 했다)

우리는 이러한 과정을 통해 미션은 우리 제품의 본질을 나타내며 우리가 집중해야 하는 대상인 것이라는 것을 배웠다. 결국, 미션을 정의하는 것은 선택과 집중을 해야만 하는 존재인 스타트업이 집중할 존재를 정의하는 프로세스이자 결과물인 것이고 알라미에게는 바로 Wake people up, fully and completely 인 것이다.

알라미의 비전 (Vision)

미션이 ‘우리는 무엇을 하는 회사인가?’ 라면, 비전은 “우리가 결국 이루고자 하는 것은 무엇인가?” 이다. 알라미가 10년 뒤에는 결국 어떤 모습일지를 나타내는 문장으로, 우리가 어느 지점을 바라보며 가고 있는지를 알려주는 중요한 역할을 한다.

역사적으로 “알람”이라는 것은 일어날 시간에 소리를 내주는 하나의 도구로, 과거에는 닭 울음소리, 자명종, 최근에는 알람앱이 이러한 역할을 하고 있다. 긴 시간 동안 알람의 목적은 단순히 “일어날 시간을 알려주는 것”으로 지금까지 알람의 패러다임은 크게 변하지 않았다.

정해진 시간이 되면 소리를 내주는 도구인 알람시계

실제로 알라미가 나오기 전까지 수 많은 알람 앱들의 목표는 지정된 시간에 소리를내는 것 뿐이었다. 알라미가 이런 패러다임을 깨고, “일어나는것 까지 책임 지는것”으로 알람의 책임 범위를 확장 해왔다. 그렇다면 그 다음으로 알라미가 바꾸고 싶은 패러다임은 무엇일까?

우리는 알람의 역할이 잠에서 깨우는것에서 더 나아가, 성공적인 아침까지 책임져야 한다고 생각했다. 알라미를 사용한다는 것은 확실하게 잠에서 깨어나 성공적으로 아침을 시작한다 라는 의미로 바꾸고 싶었고, 아래와 같은 비전을 세울 수 있었다.

“Make people’s morning successful”
(모두에게 성공적인 아침을 만들어주자)

여기서 성공적인 아침이 뜻하는 바가 무엇일까? 제시간에 잘 자고 원하는 시간에 확실하게 일어나는 것, 개운하게 잠에서 깨는 것, 원하는 아침 루틴으로 하루를 시작하는 것처럼 사람에 따라 다양한 의미가 될 수 있다.

이런 성공적인 아침을 달성하는 과정에서 자연스럽게 알람의 책임 범위가 달라진다. 기존 알람은 일어나는 시간에만 집중되어 있었다면, 알라미는 잠들기 전 저녁 시간부터 잠에서 깬 후의 아침 시간까지를 책임져야 하는 범위로 생각한다.

이렇게 달라지는 책임 범위가 제품적으로나 비즈니스적으로 기존의 알람과 큰 차이를 만든다고 생각한다. 쉽게 말하면 유틸리티 카테고리에서 웰니스 카테고리로 포지셔닝 되는 것이다.

이런 변화와 비슷하게 알라미를 기점으로 10년 뒤 알람앱을 사용할 때에는 확실하게 일어나서 성공적으로 아침을 시작하는 것이 자연스럽게 여겨지는 패러다임이 되기를 바란다.

기존 알람의 정의에서 우리가 재정의 하고자 하는 알람의 정의 (유틸리티 → 웰니스)

이렇게 한 서비스의 개념을 재정의 하는 것이 사람들의 행동과 습관을 자연스럽게 바꿀 수 있으며, 결국 제로 투 원(Zero to One) 을 이룰 수 있다고 생각한다.

우리의 미션과 비전은 세상에 어떤 영향을 끼치는가?

만국 공통 알람짤.. (세상에는 두 종류의 사람이 있다)

알람은 국가를 불문하고 모두에게 필요한, 보편적인 니즈를 가진 서비스이다. 수많은 사람들이 출근, 등교, 자기 계발 등 여러 가지 이유로 지정된 시간에 일어나려고 한다. 하지만 매일 아침 정해진 시간에 일어나기는 쉽지 않고, 원하는 시간에 일어나지 못하면 아침의 컨디션뿐 아니라 하루 전체에 부정적인 영향을 끼치기도 한다. 이러한 부분이 바로 제시간에 아침을 시작하게 만드는 것이 중요한 이유이다.

알라미는 원하는 시간에 확실하게 일어나서 성공적으로 아침을 시작하도록 만들기 위해 노력하고 있다. 사소하게 보일 수 있지만, 아침에 일어나는 방식을 바꾸는 것만으로도 하루가 바뀌고, 이것들이 모여서 일주일, 한 달 그리고 삶 전체가 바뀔 수 있다.

실제로 위와 같이 알라미를 통해 아침이 바뀌고 인생이 바뀐 사례는 리뷰를 통해 쉽게 접할 수 있다

2020년 5월 기준, 전 세계 알람앱 최초로 100만 개 리뷰를 돌파하면서도 4.8점이라는 높은 평점을 유지하고, 수많은 진심 어린 피드백을 보며 우리가 조금씩 세상에 영향을 끼치고 있다고 생각하고 있다 (참고 사례).

우리는 이렇게 매일 전 세계 사람들에게 성공적인 아침을 선사하고, 그들이 조금씩 자신이 원하던 삶을 그려나갈 수 있도록 도움으로써 세상에 크고 작은 영향력을 미치고 있다고 믿는다.

마치며

정리하자면 우리는 사람들을 확실하게 깨우는 가치를 기반으로, 모든 사람에게 성공적인 아침을 선사하길 꿈꾼다. 이렇게 간단해 보이는 미션과 비전을 정하기 위해 정말 많은 시행착오가 있었는데, 돌이켜 생각해보니 미션과 비전이 작동하려면 화려하고 있어 보이게 포장된 문장이 중요한 것이 아니라 구성원들과 함께 진정 이 일을 하는 의미와 목표에 대해 깊게 고민하고 논의를 하는 것이 필요했다.

끝으로 10년 뒤에도 가치가 유지될 것에 베팅하라고 이야기한 아마존의 Jeff Bezos 이야기를 바탕으로 알라미에 대해 생각해 보자.

10년이 지나도 변하지 않는 가치에 배팅하는 아마존의 예시

10년 뒤에도 사람들은 일어나야 할 것이고, 알람은 필요할 것이고, 원하는 시간에 확실히 일어나서 성공적인 아침을 보내고 싶을 것이다.

우리는 알라미를 기점으로 알람의 개념을 ‘하루의 시작을 성공적으로 시작하게 만들어 주는 웰니스 서비스’로 재정의 하고자 하며, 10년 뒤의 사람들은 성공적인 아침을 기대하며 알람을 맞추기를 꿈꾼다.

알라미? 그게 뭐하는 앱인데?

알라미를 2012년 부터 5년간 서비스하며 항상 듣는 질문이 있다.

처음 뵙는 분들의 경우, “알람 앱이요? 그럼 간단하지 않나요?”
오랜만에 뵙는 분들의 경우, “아직도 알람 앱 하고 있어요? 아직도 할 게 있나요?”

항상 여기에 대해 답변을 하면서 ‘정리를 한번 해봐야지…’ 생각만 하다가 이참에 정리를 한 번 해보려고 한다.

일단 알라미를 모르는 분들을 위해 간단하게 소개하자면, 알라미는 사용자를 무조건 깨우는 컨셉의 알람 앱이다. 알람이 울리면 알람을 해제하기 위해 수학 문제를 풀거나 폰을 흔드는 등의 지정된 미션을 수행해야만 한다.

알라미의 또 다른 이름이 Sleep if you can 이다

여러 알람해제 방법 중 강력한 게 바로 사진으로 알람해제로, 알람을 해제하려면 지정된 장소의 사진을 찍어야 한다. 만약 화장실을 찍어두었다면 화장실까지 가야만 알람을 해제할 수 있다 (심지어 집 밖의 장소를 찍어두는 사용자분들도 있다).

알람해제 후 침대에서 다시 잠드는 분들에게 추천!

알라미가 풀려고 하는 문제가 사소하고 지엽적으로 보이지만, 이 문제에 집중한 덕분에 초기에 소수의 사용자가 사랑하는 제품을 만들 수 있었으며 더욱 많은 사람이 좋아하는 앱으로 발전해 나갈 수 있었다. 이러한 경험을 하면서 YC의 샘 알트만이 말한 “소수의 사용자가 사랑하는 것을 많은 사람이 사랑하도록 확장하는 일이, 많은 사람이 좋아하는 것을 많은 사람이 사랑하게 만드는 것보다 훨씬 쉽습니다” 에 대해 격하게 공감하게 되었다. 지금까지 많은 분이 알라미를 좋아해 주셔서 투자 없이도 잘 성장할 수 있었으며 97개국 앱스토어 카테고리 1위, 2500만 다운로드 등 다양한 성과를 내고 있다.

알라미가 지금까지 이룬 작지만 뿌듯한 성과 (2018년 기준)

이제 본론으로 들어가서 알람앱을 왜 그렇게 길게 하고 있는지, 대체 무엇을 하고 있는지에 대해 정리를 해보았다. 여러 가지가 있지만 크게 몇 가지만 꼽아 보았다.

1. 기술적 어려움

“알람이 기술적으로 어려울 게 있나? 그냥 만들면 되는 거 아니야?” 나 또한 처음엔 그렇게 생각했고, 현재 팀원들 역시 처음엔 그렇게 생각했다. 알람 앱에서 가장 중요한 것은 당연하게도 제시간에 울리는 것인데, 이 부분이 생각처럼 쉽지 않다.

안드로이드의 경우 제조사 별로 롬을 커스터마이징 하면서 예상치 못하는 상황이 수도 없이 발생한다. 예를 들면, 삼성 폰의 경우 시스템 앱이(e.g., 스마트매니저) 경우에 따라 알람이 울리지 못하도록 막는 일이 있고, 중국이나 인도의 많은 폰들에서는 앱에 내장된 메모리 정리 앱이 작동되면서 알람이 안 울리는 경우가 부지기수다. 이외에도 여러 이슈가 있으며 이런 이슈들을 해결하기 위해 수많은 제조사의 폰을 직구해서 일일이 테스트를 진행하고 해결방법을 고안해 나가고 있다 (테스트를 하며 세상엔 정말 특이한 폰들이 많다는 것을 알게 되었다).

사무실에 있는 테스트폰 사진 (70여 종의 다양한 제조사 테스트폰이 있다)

안드로이드는 수많은 폰들이 있으니까 그렇다고 치자, 아이폰은 어떨까? 아이폰은 더욱 가관이다. 아이폰에서 무음모드 중 알람을 울리기 위해서는 앱이 백그라운드에서 살아 있어야만 한다. 다시 말해서 무음모드에서 알람을 울리려면 24시간 내내 알람 앱이 실행되고 있어야 한다는 소리다. 이는 아이폰 기본 알람을 제외한 모든 알람 앱에 해당되는 이야기인데, 그 때문에 대부분 알람 앱은 이를 해결하기 위해 여러 가지 꼼수(?)를 쓰며 백그라운드에서 계속 돌아간다 (그렇지 않은 알람 앱들은 무음모드에서 진동만 울리는 것을 확인할 수 있을 것이다). 때문에 배터리 사용량과 백그라운드에서 죽었을 때 대응 등에 대한 다양한 이슈를 처리해야 하며 생각보다 쉽지 않다. 기술적인 이야기가 길어지면 재미없어지므로 나중에 자세히 한 번 정리해보려 한다.

결국, 이러한 기술적 이슈들을 꾸준히 해결하고 있는 알람 앱이 생각만큼 없으며 그 결과 플레이스토어와 앱스토어 모두 상위 알람 앱 중 최고 평점을 기록하고 있다 (아래는 “알람” 검색시 나오는 최상위 3개 알람 앱의 평점 비교).

플레이스토어 (왼쪽부터 Top1~Top3이며, 가장 왼쪽이 알라미)

앱스토어 (왼쪽부터 Top1~Top3이며, 가장 왼쪽이 알라미)

2. 글로벌화

글로벌하게 알라미를 사용하게 만들기 위해 여러 가지 노력을 해오고 있는데, 그 중 한 가지가 바로 로컬라이징이다. 처음에는 번역가를 통한 단순 앱 번역으로 시작했지만, 더욱 자연스러운 번역과 문맥을 사용하기 위해 꾸준히 사용자 참여 번역을 받아오고 있다. 이러한 과정을 효율적으로 하기 위해 내부적으로 Alarmy translation 페이지를 직접 만들어 운영하고 있다. 사용자들이 최대한 편하게 번역에 참여할 수 있도록 꾸준히 개선해오고 있으며, 번역 페이지를 만든 후에 더욱 많은 사용자의 참여를 끌어낼 수 있었다.

사용자 참여 번역 페이지 버전 1.0

사용자 참여 번역 페이지 버전 2.0

덕분에 많은 언어로 로컬라이징을 할 수 있었으며, 그 결과 현재 알라미는 57개 국어를 지원하고 다양한 국가들에 골고루 분포된 85%의 해외 사용자를 가지고 있다.

3. 광고 최적화

알라미의 주 수익원이 광고이기 때문에 광고 최적화에 많은 신경을 쓰고 있다. 광고 효율을 높이기 위해 수십 개의 광고 네트워크를 테스트하고, 효율 분석 후 선별적으로 사용한다. 지금도 효율을 고려해 10~20개의 광고 네트워크를 사용하고 있으며(S2S 방식 포함), 매주 효율에 따라 우선순위를 조절하고 새로운 네트워크를 붙이거나 기존의 네트워크를 제거하는 등의 작업을 하고 있다. 그 외에도 지면 별 refresh rate 조절, frequency cap 조절, 광고 포맷 A/B 테스팅, 광고주의 비딩가격을 고려한 CPM floor 설정 등 다양한 전략을 테스트 해보고 효율을 비교하고 있다. 덕분에 모펍(트워터의 광고 플랫폼) 케이스 스터디에 실리기도 했다.

사용자도 꾸준히 늘어 왔기 때문에 정확한 비교가 되진 않지만, 사용자 성장률에 비해 더욱 가파른 수익 성장률을 보이고 있다 (알라미는 Mopub을 primary SSP로 사용하고 있다)

또한, 위에서 언급했듯이 85%의 사용자가 해외 사용자이기 때문에 한국의 광고영역뿐만 아니라 해외 여러 국가의 광고영역도 최적화 작업을 진행하고 있다. 특히 주요국가의 경우에는 해당 나라의 로컬 광고 네트워크와 컨택하여 테스트를 진행하거나 해당 나라를 대상으로 위에서 언급한 여러 전략을 테스트해보는 작업들을 진행한다. 이 외에도 여러 가지 고려해야 할 상황들이 많고 수익과 직결되는 부분이라 정확도를 필요로 하며, 이를 위해서 필요한 부분은 자동화하고 내부 툴을 만들어서 사용하고 있다.

사용중인 광고 네트워크들의 성과를 한곳에서 비교하기 위해 만든 내부 툴 (민감한 지표들은 삭제)

매주 나라별 원하는 지표를 트래킹하고 있다 (위는 지표 트래킹을 위한 차트 예시)

처음엔 기본 개념만 가지고 광고를 시작하여 지금까지 여러 가지 시행착오를 겪으며 많은 것들을 배웠다. 하지만 아직도 배울 것들과 해볼 것들이 한참 남았다. 정말 에드테크(Ad tech)는 어려운 것 같다.

대한민국 모바일 광고 생태계 지도 (출처: 모비데이즈), 해외까지 합치면 더욱 많아진다.

4. A/B 테스팅

특정 버튼이 초록색인 것이 클릭률이 높을까 빨간색인 것이 클릭률이 높을까? 버튼의 색을 변경해보거나, 문구를 변경해보거나, UI 구성을 변경해보는 등 사실 마음만 먹으면 수많은 A/B 테스팅을 진행할 수 있다. 하지만 테스팅에 들어가는 코스트와 예상되는 결과의 파급력 등을 고려하여 제한적으로 테스팅을 해야 하기 때문에, 생각한 가설들을 아직도 모두 검증해보진 못했다.

그래도 지금까지 내부적으로 여러 A/B 테스팅을 해왔다. 예를 들어, 광고 형태를 비교하여 광고효율(ecpm)을 15% 증가시키거나, 앱 내 문구 변경으로 원하는 지표의 달성률을 50% 올리기도 했다.

종료 배너 영역의 네이티브 광고와(좌) 300x250 배너(우) 예시

조금 더 간단한 예시로 플레이 스토어 앱 등록정보에서
“SLEEP IF U CAN 😈#1 among top alarms”와
“SLEEP IF U CAN 😈 The most constantly used alarm in the world” 중 어떤 문구에 사람들이 더 많이 반응해서 다운로드가 일어날까? A/B 테스팅 전에는 알기 힘들다 (결과는 후자가 최대 7% 높은 다운로드를 기록하였다).

플레이 스토어 등록정보 예시

다행히 플레이스토어에는 간단하게 스토어 등록정보를 A/B 테스팅 해볼 수 있다(애플 분발해라). 2017년 상반기에 진행한 플레이 스토어 A/B 테스팅만 수십 가지이며, 그 결과 아래와 같은 전환율 개선을 이루어 냈으며 덕분에 구글 앱 액설런스 프로그램 앰버서더로 선정이 되기도 했다.

스토어 등록정보 A/B 테스팅 리스트 중 다운로드 전환율이 개선된 사례들

스토어 등록정보 A/B 테스팅은 많은 모바일 앱이 어렵지 않게 지금 바로 실행할 수 있으니 한 번 해보시길 추천한다. A/B 테스팅 관련하여 진행했던 여러 가설과 결과에 대해서는 따로 한번 포스팅을 할 예정이다.
[추가됨: 알라미 A/B 테스팅 일지#1]

5. CS(Customer service, 고객 대응)

서비스가 커지면서 사용자들과 소통하는 것이 귀찮아지고, ‘이런 걸 왜 물어보지?’, ‘요청하는 모든 기능을 앱에 넣어줄 순 없어!’라는 생각이 들면서 CS에 소홀해질 수 있다.

하지만 나는 CS가 엄청나게 중요하다고 생각한다. 돈을 들여 사용자 인터뷰를 하거나 사용자 설문조사를 하는 것도 의미가 있지만, 서비스를 사용하며 나온 피드백은 더욱 큰 의미를 가진다. 때문에 직접 CS를 처리하면 사용자들이 우리 앱을 어떻게 사용하고 있고, 어떤 니즈가 있으며 어떤 것을 싫어하는지 정말 잘 알 수 있다. 그래서 최근까지(5년간) 사용자들에게 답장을 보내거나 댓글을 다는 것까지 모두 대표인 내가 많은 부분 처리해왔다 (알라미에서는 매일 1000여 개의 별점이 쌓이며, 100여 건의 메일이 온다).

이런 CS 작업들은 사용자의 의견을 파악하는 것 뿐만 아니라 실제로 다운로드에도 영향을 끼칠 수 있다. 예를 들어, 스토어 리뷰의 최상단에 1점짜리 리뷰가 있으면 다운로드에 악영향을 끼치게 되는데, 종종 아래와 같은 경우들이 생긴다.

스토어 최상단에 1점짜리 리뷰가 있는 앱 예시

이런 경우 ‘좋아요’를 많이 받아 오랫동안 상위리뷰로 남아있어 골칫거리가 된다. 하지만 알라미에서는 빠른 대응과 소통으로 최상위의 1점짜리 리뷰가 5점짜리 리뷰로 둔갑하는 경우가 종종 있다 (이런 경우 최상위에 ‘좋아요’를 여러개 받은 5점 짜리 리뷰가 생긴다!).

알라미 최상단에 있던 불만 리뷰 예시. 재빠른 대응을 통해 오히려 “Great support” 이라는 긍정적인 리뷰로 바뀜

실제로 플레이 콘솔의 알라미 리뷰 데이터를(한 달 어치) 보면 아래와 같이 리뷰에 답글을 달면 1.4점의 별점이 올라가는 반면 답글을 달지 않은 리뷰는 반대로 0.2점의 별점이 떨어지는 것을 볼 수 있다.

물론 댓글을 단 리뷰들이 대체로 불만 댓글이었기 때문에 차이가 이렇게 극명하게 나타났다. 이러한 경향이 있을 수 있구나 정도로 참고하시길 바란다.

최근엔 CS가 너무 많아져 다른 팀원에게 넘겼지만 아직까지도 매우 중요한 작업으로 생각하고 있으며, 답장을 직접 보내진 못하더라도 모든 메일과 불편함을 표시하는 리뷰는 매일 읽고 있다 (나뿐만 아니라 개발자들도 매일 CS를 꼼꼼히 확인하고 사용자들과 소통하고 있다).

추가로, 위에서 언급하지는 않았지만 중간중간 팀에서 필요한 서비스는 직접 만들어서 사용하는 경우가 많다. 물론 우리의 요구사항들과 딱 들어맞는 솔루션이 있다면 해당 솔루션을 사용하지만 딱 맞는 솔루션이 없는 경우, 장기적으로 팀에 미치는 영향을 고려해 보고 자체적으로 필요한 서비스를 만든다 (뒤 돌아 생각해보면, 이렇게 구축한 자체 서비스가 팀 내부의 생산성을 높여 결과적으로는 좋은 선택인 경우가 많았다).

사실 위에서 언급한 것들은 사용자 눈에는 보이지 않는 일이기 때문에 주위에서 보기에 어떤 일들을 하고 있는지 모를 수 있다고 생각한다. 하지만 내부적으로는 계속해서 여러 작업이 일어나고 있다 (아래 그림이 우리의 상황을 잘 대변하고 있다고 생각한다).

겉으로 보기엔 편안해 보여도 물 밑에서는 열심히 헤엄치고 있다 (사진: 출처링크)

알라미뿐 아니라 모든 앱에도 적용되는 이야기지만, 어떤 앱이든 퀄리티를 높이는 것에는 한계가 없다고 생각한다. 이를 위해 꾸준히 노력해오고 있고 그 결과 다행히 매년 몇 배씩 꾸준히 성장하고 있으며, 앞으로도 할 일이 아주 많이 남았다.