카카오 이모티콘의 데이터는 어떻게 흐를까?
[코드스테이츠 PMB 10기] 플로우차트 Flow Chart
기획자 여러분,
데이터가 두려우신가요?
(전 두렵습니다...)
1. 데이터를 아는 기획자
오늘은 PM이 알아야 할 데이터베이스(DB) 지식을 학습했다. 특히 관계형 데이터베이스를 중심으로 SQL, 스키마, E-R 다이어그램 등의 개념을 배웠다. 학습 후, 이와 관련된 여러 가지 읽기 자료들을 살펴보며 데이터와 기획자의 상관 관계에 대해 깨달은 바를 적어보자면 다음과 같다.
데이터, 어디까지 알아야 되나요?
데이터 PM은 데이터 기반 인사이트를 바탕으로 제품 및 기능을 설계하고, 통계 분석을 위한 시각화 도구로 데이터를 시각화하고, 가설 테스트 및 모델링을 통해 변수 간의 고유한 관계를 식별합니다.
- <A step-by-step guide to becoming a Data Product Manager> 中
좋은 PM은 현재 필요한 데이터를 빠르게 찾고 정리할 수 있는 사람이다. 왜냐하면 데이터 분석이야말로 우리 서비스의 품질을 빠르게 평가하고, 성과를 측정하고, 개선하는 가장 좋은 방법이기 때문이다. 한마디로 의사결정 과정에서 참고할 자료가 되어준다.
그렇다고 해서 기획자가 DB에 대한 모든 것을 알아야 하는 것은 아니다. 직접 DB 서버를 설계하거나 DB 프로그래밍을 하는 경우는 사실상 없다. 그러나 기본적인 이해는 갖춰야 한다. 이때의 포인트는 DB의 효율화이다. 기획자는 데이터 수집범위를 정의하고, 수집한 데이터의 운용 정책을 수립하여 안정적인 서비스를 구축할 수 있어야 한다는 것이다.
"개발자님. 데이터 주세요!"
라는 말이 통하지 않는 이유
또한, 팀 구성원 입장에서도 DB에 대한 지식이 어느 정도 있는 사람과 대화하기를 선호한다. 모르는 부분을 물어보면 한두 번은 자세히 설명해주더라도, 이런 상황이 반복되면 '이 사람은 이해할 마음이 없구나'라며 대화를 포기하게 된다.
<서비스 기획자라면 꼭 알아야 하는 "이것">(참고)에 소개된 사례를 인용하자면, 개발자에게 데이터 추출을 요청할 때 그냥 "A 기능에 대한 데이터를 뽑아주세요"라고 말하는 것과 정확한 테이블과 컬럼명을 요청하는 것은 다르다. 의사소통에 어폐가 생겨 원하는 데이터가 누락된 경우, 업무가 지연되는 불상사가 발생한다.
그러므로 기획자는 개발팀의 사정과 상황에 무관심해서는 안 된다. 서비스의 어떤 데이터들을 서버에서 불러오는지, 어떤 데이터들이 클라이언트에 있는지 구분하는 작업이 요구된다. 만약 기획자의 참여 없이 DB 설계가 진행된다면 기획자의 의도는 쏙 빠진 서비스가 나올 수밖에 없고, 기획자의 역할과 전문성은 매우 축소될 수밖에 없다.
주니어의 경우 모든 데이터를 완벽하게 정리하는 데 한계가 있을 수는 있다. 그러나 데이터 분석 절차에 대해 이해가 없다면 원하는 결과를 도출해 낼 수 없다는 점을 인지할 필요가 있다. 결론적으로 이 시대의 PM이라면 문제 상황에 따라 어떤 데이터(지표)를 적절히 꺼내 읽어야 할지를 파악할 정도의 데이터 역량은 갖추고자 노력해야 한다.
2. 카카오 이모티콘의 플로우 차트
전문성 있는 PM을 꿈꾸는 나 역시 이번 포스팅을 통해 데이터 역량을 조금이나마 기르고자 했다. 포스팅의 주제는 우리 일상에서 떼려야 뗄 수 없지만, 뚜껑을 열어보면 어마어마한(?) 개발 지식이 적용된 서비스인 카카오 이모티콘으로 삼았다.
카카오 이모티콘이라는 서비스의 전체 플로우 중, 카카오 이모티콘 샵에서 이모티콘을 구입하여 채팅방에서 처음으로 사용하기까지의 플로우차트(Flow Chart)를 (매우 간단히!) 그려보자면 다음과 같다. 그런데 나는 사용자가 직접 만나는 부분보다는 보이지 않는 곳에서 데이터가 어떻게 흐르는지 알아보고 싶었다.
카카오 이모티콘의 데이터 흐름을 이해하는 과정에 <비전공자를 위한 이해할 수 있는 IT 지식>을 읽어두었던 것이 매우 많은 도움이 되었다. 예전부터 이 책을 꼭 한 번 읽어보고 싶다고 생각했기 때문에, 부트캠프에서 수강생들끼리 북클럽을 꾸릴 수 있다는 말을 듣자마자 사람들을 모아서 위와 같은 페이지를 만들고, 함께 독서를 했었다.
<비전공자를 위한 이해할 수 있는 IT 지식>에서 말하길, Web과 App에서의 데이터는 조금 다르게 흐른다고 한다. 그 중 카카오톡 App을 기준으로 후자를 카카오 이모티콘에 대입하여 설명하자면, 사람들이 이모티콘 스토어에서 이모티콘을 다운로드하면, 그렇게 다운로드한 이모티콘은 필요한 경우 데이터베이스가 있는 서버에 요청(이모티콘 더블탭)을 보내고, 응답을 받아 처리(이모티콘 전송)한다는 것이다.
개발자와 함께
카카오 이모티콘의
데이터 흐름을 추측해봤다
그런데 분석하다 보니까 "이러면 서버에 무리가 가지 않나?"라는 의문이 들었다. <비전공자를 위한 이해할 수 있는 IT 지식>에서는 최대한 네트워크에 부담이 가지 않도록 데이터를 클라이언트와 서버에 적절하게 배분해야 한다고 나와 있다. 서버는 24시간, 365일 안정적으로 돌아가는 게 중요하기 때문이다.
카카오 이모티콘의 서버에는 셀 수 없이 많은 이모티콘이 등록되어 있을 것이다. 그러나 카카오 이모티콘은 클라이언트에 데이터를 나누어 운영하지 않는 것으로 보인다. "그런데 어떻게 서버에 저장된 이모티콘이 0.00001초*만에 전송될 수 있는 거지?"라는 질문이 생겼다.
* 카카오 이모티콘이 실제로 0.00001초만에 전송되는지 계산해본 적은 없지만, '눈 깜짝할 새 전송된다'는 의미를 전달하고자 사용한 표현입니다.
그래서 어김없이
개발자 A씨에게 물어보기로 했다
보통 서버에서는 그런 고용량 데이터를 직접 가지고 있지 않는다고 한다. 이때의 고용량 데이터란 이미지 이상의 데이터를 의미하는데, 카카오 이모티콘은 무려 '움직이는 이미지'이다. 따라서 개발자 A씨는 사용자가 보낸 채팅 요청을 처리하는 카카오톡 채팅의 서버와 이모티콘 데이터를 관리하는 카카오 이모티콘의 서버가 따로 있을 거라고 예상했다. 서버마다 맡은 역할이 따로 있다는 뜻이다.
"그러면 이모티콘을 카카오톡 채팅 쪽 서버에 저장하면 서버가 느려져?"라고 물었더니, 개발자 A씨는 "아니. 서버가 터져..."라고 답했다. 단지 고용량 데이터 때문에 서버가 느려지고 터지는 것뿐만 아니라, 메시지를 전송하기 위한 통신 프로토콜과 파일을 전송하기 위한 통신 프로토콜이 또 다르기 때문에 서버가 각자 운영되고 있을 거라고 추측했다. (이때, 위 이미지에서는 서버 B는 클라우드 스토리지이다.)
대부분의 서비스들이 클라이언트 → 서버 → DB → 서버 → 클라이언트라는 큰 틀 자체는 유사하지만, 데이터를 요청하는 방식 , 응답을 받아 처리하는 방식을 어떻게 설계하느냐에 따라 서비스 간의 격차가 생기는 듯하다.
카카오가 직접 밝힌
카카오 이모티콘의 서비스 구조는?
이러한 추측이 과연 옳았을지 궁금해서 카카오 기술 블로그(참고)를 찾아봤다. 카카오 이모티콘의 데이터와 관련된 포스팅이 하나 있기에 읽어보았는데, 사실 개발자들을 위한 포스팅이다 보니 절반 이상이 외계어로 보여서(...) 이해가 가는 부분만 열심히 눈에 담았다. 내가 읽은 포스팅은 <이모티콘 서비스는 왜 MSA를 선택했나?>이다. 이 포스팅에서 내가 얻은 인사이트를 요약하자면 다음과 같다.
카카오라는 서비스가 발전함에 따라 이모티콘 서비스 역시 거대해졌다. 따라서 이와 관련되어 해결해야 할 기술 부채가 쌓여갔고, 이를 해결하기 위해 개발팀에서는 MicroService Architecture(MSA)라는 아키텍처를 도입했다.
MSA란 기존 아키텍처의 단점을 보완하고자 나온 여러 아키텍처 중 하나로, 프로젝트의 규모가 커질수록 복잡도가 심각하게 증가한다는 기존의 Monolithic Architecture를 대체하기 위해 쓰인다. 사용자 입장에서는 카톡이라는게 하나의 서비스 같아 보이지만, 사실은 카카오 선물하기, 카카오 이모티콘, 카카오 뷰 등 작은 서비스 여러 개가 모여서 하나의 시스템을 제공하고 있다는 뜻.
최근들어 MSA에 대한 이야기가 자주 언급되고 있는데, 그 이유는 MSA가 클라우드 환경과 찰떡궁합이기 때문이라고 한다. MSA는 서비스 단위로 기능을 분리해서 구축할 수 있기에 사용하지 않는 기능 또는 사용량이 적은 기능을 축소해서 효율화시킬 수 있다고.
기획자를 꿈꾸는 나에게
'개발'이란?
나에게 코딩을 성공적으로 전도(?)한 개발자 A씨에게 무한한 감사를.사실 카카오 기술 블로그에서 MSA라는 처음 맞닥뜨렸을 때, 머릿속이 새하얘지고 심장이 빨리 뛰기 시작했다(ㅋㅋ). 그만큼 문과생과 예대생의 경계에 아슬아슬하게 걸쳐 있는 나에게 개발에 관한 지식이란 몹시도 두려운 영역인 거다.
그래도 일단 뛰어들어 보기 전까진 모른다고, 재작년 여름 쯤 생활코딩에서 html과 CSS를 익히고, 관련 도서를 찾아 읽고, 개발자 A씨와 많은 대화를 나누었다. 그래서 적어도 개발이 겁나지는 않는다. (다만 못 할 뿐이지...)
나름대로 맨 땅에 해딩하며 노력한 끝에 "아무것도 모르겠어!"의 단계에서 벗어나 "내가 뭘 모르는지는 알겠어!"의 단계까지는 도달할 수 있었다. 위 사진의 의식하는 할 수 없음(ㅋㅋ) 정도의 단계란 뜻이다. 앞으로 이러한 도전 정신을 바탕으로 개발자와 싸우지 않는(?) PM으로 성장하고 싶다.
참고자료
