brunch

매거진 넥스트 모바일 이야기

라이킷 10 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Mobiinside Feb 20. 2020

오픈서베이 개발팀은 어떤 과제를 해결하고 있을까?

시스템 구조 이해 및 회원 시스템 개편기 1편

김경만 개발자

저는 오픈서베이의 김경만 개발자입니다. 오픈서베이는 모바일 리서치 기업으로, 스마트폰을 활용해 소비자 데이터를 수집하고 분석하는 일을 합니다. 흔치 않은 비즈니스 모델이다보니 개발 시스템도 흥미롭고 독특한 면이 꽤 있습니다. 이에 제가 진행한 회원 시스템 개편 프로젝트 후기를 통해 오픈서베이 개발 시스템 구조 및 개발 업무 환경에 대해 소개해드리고자 합니다.

S#.1 오픈서베이 시스템 이해하기

소비자조사 업종은 조사를 시작해서 결과를 받아보기까지의 과정 안에 수많은 이해관계자가 얽혀있습니다. 이에 전통적인 소비자조사 프로세스를 수행하려면, 그만큼 많은 인력이 필요하고, 자연스럽게 비용이 오릅니다. 과거에 설문조사가 대기업의 전유물이었던 이유는 여기에 있습니다.

오픈서베이는 이렇게 복잡한 소비자조사 프로세스를 간소화하고, 기술의 힘을 통해 시스템화하는 방법을 고민했던 사람들이 만들어낸 제품입니다. 제가 오픈서베이에 입사한 이유 중 하나는 이러한 고민의 흔적이 남아 있는 제품과 개발 문화에 대한 동경이라고 해도 과언이 아닙니다.

오픈서베이와 기존 리서치 회사의 프로세스는 이렇게나 다릅니다

S#.2 흥미로웠던 오픈서베이 시스템 3가지

B2C 서비스만 경험해본 제게 오픈서베이의 설문 시스템은 흥미로운 점이 정말 많았습니다. 본격 개발기에 앞서 앞으로 언급할 오픈서베이의 다양한 기술 및 시스템에 대한 배경지식 소개 차 제가 흥미로웠던 점을 몇 가지 소개해 드릴까 합니다.

① 설문 알림이 시작될 때 급격히 치솟는 트래픽

오픈서베이의 설문참여 앱 오베이는 유저의 사용 패턴이 다른 앱들과 좀 다릅니다. 보통 모바일 앱은 유저가 접속하고 싶을 때, 아이콘을 눌러 앱을 실행합니다. 그런데 오베이는 유저가 평상시에 앱 아이콘을 눌러 들어오는 빈도보다 설문 푸시를 받은 유저가 푸시 알림을 타고 들어오는 빈도가 훨씬 높습니다. 그래서 ‘유저(User)’ 대신 설문에 참여한다는 의미의 ‘패널(Panel)’이라는 용어로 부르고 있습니다.

이 말은 즉, 오베이의 일간 트래픽은 그날 패널에게 얼마나 많은 설문을 보냈는지에 따라서 결정된다는 겁니다. 유저가 앱을 켜는 원인이 특수하다는 거죠. 이러한 특수성은 개발자가 그날그날 트래픽을 예측해서 서버를 운영하기 힘들게 만듭니다. 설문 푸시 하나에 트래픽이 널뛰기하는 경우가 많기 때문입니다. *MAU 대비 DAU가 50%를 거뜬히 초과하는 경우도 종종 있을 정도죠.

* MAU는 Monthly Active User(월간 활성 사용자), DAU는 Daily Active User(일간 활성 사용자)의 줄임말입니다.

이에 오픈서베이는 *APM툴인 WhaTap과 중앙로그관리시스템인 graylog, 그리고 자체 설문 및 푸시 발송량 트래픽 모니터링 툴인 미어캣 등을 통해 최대한 자동화된 모니터링과 병목구간 측정 및 개선을 통해 제한된 리소스하에서도 비교적 원활한 환경을 운영하고 있습니다.

*APM은 Application Performance Monitoring의 약자입니다.

오픈서베이가 트래픽 모니터링을 위해 활용하는 상용 APM ‘와탭(WhaTap)’ (내부 정보 보안을 위해 상세 수치는 블러 처리했습니다)

② 프로필 기반으로 설문조사 기회를 만드는 타겟팅 시스템

타겟팅 시스템(Targeting System)은 원하는 패널에게만 설문 푸시를 보낼 수 있는 시스템을 말합니다. 의외로 설문조사는 아무나 응답해도 되는 경우가 극히 드뭅니다. 이를테면 ‘서울 거주 1인 가구 30대 여성’과 같이 응답 대상자를 정해놓고 설문조사를 하는 경우가 대다수입니다. 이때 오픈서베이는 패널이 등록한 프로필을 기반으로 원하는 대상자에게만 타겟팅된 설문을 보낼 수 있습니다.

저는 이러한 타겟팅 시스템이야말로 오픈서베이 비즈니스의 핵심 기술이라고 생각합니다. 이 기술이 패널의 응답 경험에 긍정적인 영향을 주기 때문인데요. 오픈서베이가 아닌 다른 리서치 회사의 설문에 참여해보면 알겠지만, 다른 곳의 설문은 앞단에 응답 대상자 여부를 판단하기 위한 사전 문항이 붙어있습니다. 많게는 십수 개까지요.

만약 패널이 설문에 필요한 대상자가 아닐 경우, 문항에 열심히 응답하다가 갑작스럽게 설문이 종료되고 리워드도 적거나 없는 경우도 많습니다. 그런 경험이 쌓이면 응답 자체를 무성의하게 하거나 대상자에 선정되기 위해 사실과 다른 응답을 할 수도 있죠. 오픈서베이의 타겟팅 시스템은 패널의 응답 경험을 높이고, 설문의 신뢰성을 높이는 데 큰 역할을 합니다.

기획 단계부터 원하는 응답자를 타겟팅할 수 있는 오픈서베이

③ 다양한 정형·비정형 데이터를 자동으로 시각화하는 시스템

결과 페이지를 살펴보면 알겠지만, 오픈서베이는 매우 훌륭한 데이터 자동 시각화 시스템을 갖추고 있습니다. 제가 이 시스템을 높이 사는 이유는 설문조사 결과 데이터는 시각화하기 까다로운 면이 있기 때문입니다. 비교적 단순한 객관식 응답 데이터도 있지만, 순위형, 복수응답 혹은 주관식 문항을 통해 수집한 다양한 정형·비정형 데이터도 있거든요.

그래서 오픈서베이는 설문조사 경험이 없거나 적은 분들도 데이터를 좀 더 쉽고 편리하게 분석할 수 있도록, 다양한 유형의 데이터를 자동으로 시각화하는 훌륭한 시스템을 개발 및 구축하고 있습니다. 고객과 직접 소통하는 사업그룹 분들에게 들어보니, 고객들이 가장 만족스럽게 이용 중인 시스템 중 하나라고 하더군요.

이외에도 흥미로운 시스템은 많습니다. 특히, 응답에 따라 문항이 달라지는 로직, 직관적인 설문 에디터 시스템, 인구수에 비례해서 패널 수를 조정하는 운영 방침, 그리고 트렌드만을 쫓는 게 아니라 특정 집단의 사용성을 고려한 UI·UX 설계도 흥미롭게 느껴졌습니다.

다양한 정형·비정형 데이터를 자동으로 시각화하는 결과 분석 시스템

S#.3 오픈서베이 세대별 시스템 구조 이해하기

솔직하고 싶은 맘에 이야기를 보태자면, 적응하기 어려운 점도 확실히 있었습니다. 일단 앱이 좀 오래됐습니다. (디자인은 제 전문 분야가 아니라 논외) 모바일 앱 초창기 때 쓰이던 코드가 그대로 남아있는 경우가 더러 있었습니다. 모든 앱이 늘 최신 코드를 적용할 필요는 없지만, 현재는 쓰이지 않는 코드로 인해 유지 관리 및 새로운 기술 적용의 어려움이 있었습니다.

또한, 초기 오베이는 하나의 거대한 모놀리식 시스템(Monolithic System)으로 구성돼 있었습니다. 설문 생성, 모집단 설정, 대상자 선정, 데이터 수집, 분석, 결과 생성 등 리서치의 수많은 단계를 하나의 시스템이 지탱하고 있던 것이죠. (저희는 이때를 오픈서베이 1세대라고 부릅니다) 이때는 세부 기능의 정책을 하나 바꾸려면 전체 시스템을 대상으로 배포를 진행해야 했습니다. 개발 업무를 하는 분이라면 이러한 시스템 구조의 잠재적인 위험에 대해 아실 겁니다.

놀랍게도 설문 생성, 모집단 설정, 대상자 선정, 데이터 수집, 분석, 결과 생성 등 리서치의 수많은 단계를 하나의 모놀리식 시스템이 지탱하고 있었습니다.

그래서 전부터 개발팀은 레거시 시스템에서 각 기능을 분리하는 크고 작은 프로젝트를 꾸준히 진행해왔다고 합니다. (이때가 오픈서베이 2세대입니다) 그치만 처음부터 완전히 새로운 시스템을 구축하는 방식이 아니다 보니, 같은 데이터가 복수의 시스템 DB에 중복되어 저장되거나 작은 단위로 쪼개진 프로젝트 개수가 너무 많아져서 서버 및 인력 리소스가 과하게 많이 필요한 상황이 지속됐습니다.

2세대를 표현하자면 모놀리식 시스템 + 마이크로 시스템 사이의 무언가.. 이 당시 한 명의 개발자가 담당하는 시스템이 N개가량이었고, 시스템별로 admin, daemon, api, DB가 다 따로 있어서 운영관리가 매우 힘들었습니다.

그러다가 2017년부터 개발총괄을 맡은 폴(이건노 CTO)이 칼을 빼들었습니다. 그간 필요성에 대해선 모두 공감하고 있었지만 여러 현실적인 이유로 미루고만 있던 ‘서비스 통폐합 프로젝트’를 시작한 겁니다. 산발적으로 쪼개진 여러 프로젝트 중 합칠 수 있는 건 합치고 없앨 수 있는 건 없애면서 관리해야 할 서비스 가짓수를 줄여서 유지관리 및 개선의 효율성을 높이는 것인데요. 이 글의 주제이기도 한 ‘오베이 회원 시스템 개편’도 이 맥락에 있습니다.

S#.4 내가 회원 시스템 개편 프로젝트를 맡게 된 이유

발단은 2018년 초입니다. 입사한 지도 좀 돼서 회사 생활에 적응했다 싶었을 때, 폴(이건노 CTO)로부터 프로젝트 제안이 왔습니다. 위 문단의 서비스 통폐합 프로젝트 중 오베이 회원 시스템 개편 업무를 맡아보면 어떻겠냐면서요.

참고로 회원 시스템이란 오베이 패널들이 사용하는 앱의 전반적인 시스템을 말합니다. 그럼 오베이 앱 시스템 전체를 개편해야 하는 게 아닐까 싶지만, 당시만 해도 ‘로그인 시스템 이전하기’ 정도의 그리 규모가 크지 않은 프로젝트로 예상했습니다(아래 이미지 참고). 회사생활에 어느 정도 적응을 마친 후, 출처 모를 용감함에 사로잡힌 제게는 딱 좋은 먹잇감이었죠. 여기까지가 제가 미끼를 덥석 물어버린 배경입니다.

프로젝트를 맡을 당시에 예상했던 프로젝트 범위

아직 제가 어떤 미끼를 물었는지도 잘 몰랐을 때입니다. 데이터를 살펴보면서 구체적인 마이그레이션 및 데이터 축적 방법을 고민해봤죠. 검토해보니 데이터가 여기저기 쌓이는 문제는 확실히 있었지만, 시스템 단에서 조금 정리를 해주고 회원 계정 정보가 축적되는 방식을 변경하면, 코드베이스를 꽤나 컴팩트하게 줄일 수 있을 것 같았습니다. 그럼 DB 정리도 무리 없이 진행될 것 같았고요.

그런데, 계속 검토를 해보니 시스템 구조가 생각보다 훨씬 더 복잡했습니다. 회원 시스템과 다른 시스템이 서로 매우 깊게 관여돼 있었고, 현재의 회원 시스템 데이터를 직접 참조하는 시스템도 있었습니다. 그렇게 프로젝트 범위는 회원 및 샵 운영 시스템을 새로 개발하는 수준까지 넓어지게 됐습니다(아래 이미지 참고).