무엇이 문제였나 — 평점 4.0점이 막고 있던 것
두물머리투자자문에서 2020년 2월부터 2022년 5월까지 2년 4개월 동안 로보어드바이저 앱 '불릴레오'와 증권사 자문 서비스 '불리오'의 운영·기획·그로스를 함께 맡았습니다. 두 서비스에서 관리한 자문계약 고객은 4,300명을 넘는 규모였습니다.
이 시기에 처음 마주한 숫자가 Google Play 평점 4.0점이었습니다. 앱스토어에서는 평점 한 단위 차이가 신규 설치 전환율을 크게 가릅니다. 4.0점은 눈에 띄게 나쁜 값은 아니었지만, 계좌 개설까지 이어지는 다음 단계 전환을 끌어올리기에는 부족한 값이었습니다.
투자자문업은 앱을 설치했다고 끝나는 서비스가 아닙니다. 설치 다음에는 계좌 개설, 그다음에는 실제 투자 계약까지 여러 단계를 거칩니다. 평점 4.0점은 이 앞단, 그러니까 설치 후보가 앱을 지울지 계속 볼지를 가르는 첫 단계에서부터 이탈을 만들고 있었습니다. 뒤 단계인 계좌 개설 전환을 아무리 손봐도 앞단에서 절반이 빠져나가면 전체 숫자는 오르지 않습니다.
평점이 문제였던 진짜 이유는 별점 숫자 자체가 아니라, 그 뒤에 어떤 고객이 무슨 이유로 낮은 점수를 남겼는지 회사가 체계적으로 파악하지 못했다는 데 있었습니다. 4,300명이 넘는 고객의 불만과 요청이 개별 상담 채널에 흩어져 있었고, 그 데이터를 모아서 보는 장치가 없었습니다.
두물머리는 로보어드바이저 앱 '불릴레오'만이 아니라 증권사 플랫폼에 자문 서비스를 얹은 '불리오'도 함께 운영했습니다. 두 서비스 모두 신규 고객이 앱을 설치한 뒤 실제 자문계약, 나아가 계좌 개설까지 이어져야 매출로 연결되는 구조였습니다. 앱스토어 평점은 이 흐름의 맨 앞에서 후보군의 크기 자체를 정하는 지표였고, 여기서 새는 규모가 뒤 단계 어떤 개선보다 컸습니다.
투자자문업은 광고 문구 하나, 후기 답변 하나에도 근거가 있어야 하는 업종입니다. 그래서 평점이 낮다고 해서 이벤트나 리뷰 유도 같은 손쉬운 방법으로 숫자만 끌어올릴 수도 없었습니다. 실제로 서비스를 개선해서 평점이 따라 오르게 만드는 방법 외에는 선택지가 좁았고, 그래서 평점 뒤에 있는 원인을 정확히 아는 일이 더 중요했습니다.
처음 잰 숫자 — Google Play 콘솔의 4.0점
측정 방법은 단순했습니다. Google Play 콘솔이 보여주는 평균 평점을 기준값으로 삼았고, 계좌 개설 전환은 앱 설치 이후 계좌 개설을 시도한 사용자 비율로 잡았습니다. 두 지표 모두 새로 만든 계측이 아니라 이미 있던 지표를 정기적으로 확인하는 방식이었습니다.
출발점 숫자는 두 개였습니다. Google Play 평점 4.0점, 그리고 그 시점의 계좌 개설 시도율입니다. 계좌 개설 시도율의 절대값은 지금 남은 기록에 없지만, 조치 이후 이 값이 2.44배로 늘었다는 배수는 남아 있습니다. 절대값 없이 배수만 남은 지표는 이 글에서 이 하나이고, 평점은 전후 절대값을 그대로 씁니다.
숫자 하나만 보고 조치를 시작하지는 않았습니다. 4.0점이라는 값은 결과였고, 그 결과를 만든 원인은 따로 찾아야 했습니다. 이 순서, 그러니까 결과 숫자를 먼저 확인하고 원인은 그다음에 찾는 순서가 이 글 전체를 관통합니다.
평점과 계좌 개설 시도율, 두 지표를 같은 기간 동안 나란히 두고 본 이유도 있습니다. 평점만 보면 앱이 좋아졌는지만 알 수 있고, 실제 매출로 이어지는 다음 단계까지 좋아졌는지는 알 수 없습니다. 반대로 계좌 개설 시도율만 보면 그 변화가 평점 때문인지 다른 이유 때문인지 구분이 안 됩니다. 두 지표를 같이 놓고 봐야 원인과 결과의 연결이 보였습니다.
세운 가설 — 앱 평점이 낮은 이유는 무엇이었을까
VoC(고객의 소리) 시스템을 들여오기 전까지 고객 불만은 개별 상담 채널로 들어왔습니다. 상담원이 문의를 받아 그 자리에서 답하고 종료하는 방식이었고, 같은 유형의 불만이 몇 명에게서 반복되는지는 따로 집계하지 않았습니다.
이런 구조에서 세운 가설은 소박했습니다. 눈에 띄는 불만 몇 가지를 고치면 평점이 따라 오를 거라는 가설이었습니다. 응대 품질을 개별적으로 높이면 평점도 함께 오른다고 봤습니다.
이 가설이 자연스러웠던 이유가 있습니다. 상담원 한 명이 하루에 접하는 문의는 많아야 몇십 건입니다. 그 몇십 건 안에서 반복되는 것처럼 보이는 불만이 있으면, 그것이 전체 4,300명을 대표하는 신호라고 믿기 쉽습니다. 표본이 작을수록 개인의 경험이 곧 전체처럼 느껴집니다.
당시 팀에 없던 것은 복잡한 도구가 아니라 단순한 습관, 즉 들어온 문의를 한 곳에 모아 세는 습관이었습니다. 상담 채널마다 문의가 접수되고 종료됐지만, 그 종료된 문의를 나중에 다시 꺼내 유형별로 세어 보는 절차는 없었습니다. 그래서 가설은 항상 최근에 응대한 몇 건, 혹은 목소리가 컸던 몇 건에서 출발했습니다.
이 가설 자체가 완전히 틀렸다고 말하려는 것은 아닙니다. 응대 품질을 높이는 일은 그 자체로 필요했고, 실제로 나쁘지 않은 방향이었습니다. 문제는 그 가설 하나만으로 4.0점에서 4.7점까지 가기에는 부족했다는 데 있었습니다. 개별 응대는 이미 상담 채널에 온 소수를 다독일 뿐, 앱을 조용히 지운 다수의 이유는 건드리지 못했습니다.
가설이 틀린 지점 — 왜 1:1 응대만으로는 부족했나
이 가설은 규모 앞에서 무너졌습니다. 고객이 4,300명을 넘는 상태에서는 상담원 개인의 기억과 감으로 어떤 불만이 소수의 예외이고 어떤 불만이 다수가 겪는 패턴인지 구분할 수 없었습니다. 한 사람이 크게 화를 낸 문의와 백 명이 조용히 겪는 불편이 상담 채널에서는 똑같이 티켓 한 건으로 보였습니다.
응대를 아무리 친절하게 해도 평점은 잘 움직이지 않았습니다. 원인은 응대 태도가 아니라 무엇을 먼저 고쳐야 하는지 정할 데이터가 없다는 데 있었습니다. 데이터 없이 세운 가설은 매번 개인의 인상에 의존했고, 그 인상은 상담원마다 달랐습니다.
더 근본적인 문제도 있었습니다. 낮은 평점을 남긴 고객 상당수는 상담 채널에 문의를 남기지 않고 그냥 앱을 지웠습니다. 상담 채널로 들어오는 목소리는 전체 불만 중 일부였고, 나머지는 평점 숫자로만 조용히 남았습니다. 1:1 응대를 아무리 잘해도 애초에 상담 채널에 오지 않는 다수의 이유는 볼 수 없었습니다.
그래서 가설이 틀렸다는 사실을 알아챈 지점도 응대 품질이 아니라 숫자였습니다. 상담원 평가나 응대 만족도 같은 지표는 계속 나쁘지 않았는데도 평점 4.0점은 몇 달째 그대로였습니다. 원인을 바꿔야 결과가 바뀐다는 사실이, 원인을 그대로 둔 채 결과만 바뀌기를 기다린 그 몇 달 동안 분명해졌습니다.
진짜 원인 — 목소리를 모으지 않으면 원인도 안 보인다
진짜 원인은 앱의 특정 버그가 아니라 고객 목소리를 모으는 장치 자체가 없었다는 데 있었습니다. 문의가 산발적으로 들어오고 산발적으로 끝나는 구조에서는 표본이 아무리 커도 규칙이 보이지 않습니다. 4,300명이 남긴 신호는 이미 회사 안에 있었지만, 그 신호를 모아서 세는 사람이 없었습니다.
지금 저희가 코드로 쓰는 소프트웨어 품질·평가 규칙에도 같은 순서가 적혀 있습니다. 실패 사례를 20개에서 50개까지 수동으로 훑어 공통 카테고리를 정의한 다음에야 자동 평가 기준을 만든다는 순서입니다. 평가 기준부터 먼저 만들면 측정하기 쉬운 값만 재고 진짜 문제는 놓친다는 이유에서입니다. 2020년의 VoC 도입과 지금의 이 순서는 같은 원인에서 나온 같은 답이었습니다.
표본 크기를 다루는 방식도 닮았습니다. 지금 규칙은 실패 사례를 10개에서 15개까지 모으는 것으로 시작해 30개에서 50개까지 넓혀 가라고 정합니다. 처음부터 완벽한 표본을 채우려 하지 말고, 적은 수라도 먼저 모아서 방향을 잡으라는 뜻입니다. VoC도 처음부터 4,300명 전체를 정교하게 분류하지 못했습니다. 반복되는 유형 몇 가지를 먼저 잡고, 분류 기준을 넓혀 가는 순서로 진행했습니다.
일단 evaluator부터 짜고 데이터는 나중에 라는 접근은 측정 가능한 것만 측정하고, 진짜 문제는 놓칩니다.
이 규칙은 품질 판단을 내리는 사람도 한 명으로 못 박습니다. 여러 사람의 평가를 평균 내는 방식은 오히려 노이즈가 되고, 도메인을 아는 한 사람의 판단이 정답에 가깝다는 근거에서입니다. 2020년의 VoC 체계에서도 최종적으로 어떤 불만을 먼저 고칠지 우선순위를 정하는 사람은 그로스 담당자 한 명으로 좁혀져 있었습니다. 여러 부서가 각자 판단해서 흩어지는 방식이 아니었습니다.
확인 절차를 다루는 경계도 있습니다. '다시 확인해봐'라는 요청만으로는 답이 나아지지 않고, 오히려 정답을 오답으로 뒤집는 경우가 더 많다는 근거입니다. 실제 테스트 결과나 로그 같은 외부 신호와 함께일 때만 재확인이 의미가 있다고 못 박습니다. VoC도 마찬가지였습니다. '한 번 더 신경 써서 응대하자'는 다짐만으로는 평점이 오르지 않았고, Zendesk에 쌓인 실제 문의 건수라는 외부 신호가 있어야 어디를 먼저 고칠지 알 수 있었습니다.
조치 — Zendesk 기반 VoC로 4,300명의 목소리를 모으다
조치는 Zendesk 기반 VoC 시스템을 팀 안에 들여오는 것이었습니다. 상담 채널로 들어오는 문의를 유형별로 분류해 쌓고, 어떤 불만이 몇 건씩 반복되는지 집계할 수 있게 만들었습니다. 4,300명이 넘는 고객이 보내는 신호를 한곳에서 볼 수 있게 된 것이 이 조치의 핵심이었습니다.
- 문의를 유형별로 분류해 반복 빈도를 집계
- 빈도가 높은 유형부터 우선순위를 정해 개선
- 개선 이후 같은 유형의 재문의가 줄었는지 다시 확인
이 세 단계는 한 번 돌리고 끝나는 절차가 아니라 계속 반복하는 순환이었습니다. 분류하고, 우선순위를 정하고, 고치고, 다시 확인하는 흐름을 반복할수록 어떤 유형의 불만이 진짜로 평점에 영향을 주는지 감이 아니라 숫자로 알 수 있었습니다.
이 무렵에는 지금처럼 AI가 문의를 자동으로 분류해 주는 도구가 널리 쓰이지 않았습니다. 문의를 유형별로 나누고 건수를 세는 일은 사람이 직접 태그를 붙이는 방식으로 진행했습니다. 손이 많이 가는 과정이었지만, 사람이 직접 분류하더라도 모아서 세는 장치가 있다는 사실 자체가 그전과 다른 점이었습니다.
지금 코드 품질 규칙에는 문제를 묶어서 처리하는 방식도 정해져 있습니다. 같은 유형의 문제는 한 번에 3건에서 5건씩 묶어 처리하고, 한 번의 변경 범위가 500줄을 넘기지 않게 제한합니다. VoC로 모은 불만도 비슷하게, 같은 유형끼리 묶어 한 번의 개선 작업으로 처리하는 편이 하나씩 따로 대응하는 것보다 효율적이었습니다.
무엇부터 고칠지 정하는 기준도 지금 규칙에 그대로 남아 있습니다. 점수를 4점 넘게 깎는 항목은 다른 항목보다 먼저 처리한다는 기준입니다. VoC에서도 우선순위는 비슷하게 정했습니다. 계좌 개설처럼 매출과 바로 연결되는 단계에서 나온 불만을 가장 먼저 봤고, 그다음으로 반복 빈도가 큰 불만을 순서대로 봤습니다.
같은 기간에 Goal Based Investment 엔진의 스팟형 상품을 출시하는 이벤트도 함께 진행했습니다. 이 이벤트는 이틀 동안 AUM 50억원을 추가로 모집했습니다. VoC로 정리한 고객 반응이 상품 설계와 커뮤니케이션에 반영된 결과였지만, 평점 개선 조치가 이 이벤트의 유일한 원인이라고 단정하지는 않습니다. 같은 그로스 조직이 같은 시기에 이룬 별도의 성과로 남겨 둡니다.
재측정 결과 — 평점 4.7점, 계좌 개설 시도 2.44배
VoC 도입 이후 같은 방식으로 다시 쟀습니다. Google Play 평점은 4.0점에서 4.7점으로 올랐고, 계좌 개설 시도율은 도입 전 대비 2.44배로 늘었습니다. 재측정에 쓴 도구는 처음과 같습니다. Google Play 콘솔의 평균 평점, 그리고 앱 설치 이후 계좌 개설 시도 비율입니다.
평점 0.7점 차이는 작아 보일 수 있지만, 앱스토어에서 이 구간은 순위 노출과 신규 설치 전환에 함께 영향을 주는 구간입니다. 평점이 오르면서 설치 후보가 앱을 지우지 않고 다음 단계로 넘어가는 비율도 함께 늘었고, 그 결과가 계좌 개설 시도율 2.44배로 이어졌습니다.
2년 4개월의 재직 기간 동안 이 지표를 한 번 재고 끝내는 숫자가 아니라 계속 다시 재는 지표로 다뤘습니다. 한 번의 개선으로 4.7점에 도달한 뒤에도 VoC로 들어오는 문의 분류는 계속 돌렸고, 새로운 유형의 불만이 늘어나면 다시 우선순위를 매겼습니다.
측정 주기도 정해 두었습니다. 한 번 조치하고 몇 달 뒤에야 결과를 보는 방식이 아니라, VoC로 들어오는 문의 건수와 평점을 계속 나란히 놓고 봤습니다. 특정 유형의 불만이 줄어드는 시점과 평점이 오르는 시점이 겹치는지를 확인하는 방식으로, 조치 하나하나의 효과를 가늠했습니다.
지금 규칙은 사람이 직접 나서야 하는 비율의 상한도 10% 이하로 정해 둡니다. 나머지는 자동 판정이나 이미 정해진 절차로 처리하고, 사람의 판단은 정말 필요한 자리에만 남겨 둔다는 뜻입니다. VoC도 결이 비슷했습니다. 반복되는 유형의 불만은 정해 둔 개선 절차대로 처리하고, 그로스 담당자의 직접 판단은 이전에 없던 새로운 유형이 나타났을 때만 필요했습니다.
남는 한계 — 그때의 가설 목록은 기록으로 남아 있지 않다
이 글에는 밝히지 못한 부분이 있습니다. 당시 VoC로 모은 구체적인 불만 유형과 건수, 먼저 검증한 가설과 기각한 가설의 세부 기록은 지금 남아 있지 않습니다. 이 글은 2020년부터 2022년 사이의 경험을 지금 시점에서 다시 정리한 기록이며, 당시 실시간으로 쓴 분석 문서가 아닙니다.
또 하나의 한계는 인과관계입니다. 평점이 4.0점에서 4.7점으로 오른 구간에는 VoC 시스템 도입 외에도 앱 업데이트, 디자인 변경 같은 다른 변화가 함께 있었을 가능성이 있습니다. VoC 하나가 평점 상승의 전체 원인이라고 단정할 근거는 없습니다. 목소리를 체계적으로 모으는 장치가 없던 상태에서 있는 상태로 바뀐 것이 가장 큰 변화였다는 정도만 자신 있게 말할 수 있습니다.
지금은 이 판단을 사람의 기억에만 기대지 않습니다. 코드 품질 점수는 도입 초기 기준선에서 시작해 3단계, 기준선+5점에서 80점을 거쳐 85점까지 목표를 올리고, 점수가 기준선 아래로 떨어지면 다음 단계 진행을 막습니다. 규칙 문서에는 이 흐름의 예시로 품질 점수 75.5점이 78.2점으로, 세부 항목 하나가 64점에서 71점으로 오른 한 주가 적혀 있고, 그 한 주에 처리한 항목은 5건의 변경과 18건의 문제였습니다.
품질 판단의 최종 결정권자는 한 사람으로 고정하고, AI 판정은 전문가 동의율이 64%에서 68%에 그친다는 근거로 단독 판단에서 제외합니다. 2020년의 VoC 루프가 사람 손으로 하던 일을, 지금은 이런 규칙과 자동 검사가 나눠서 합니다.
지금 규칙에는 공개 벤치마크를 경계하는 조항도 있습니다. 널리 쓰이던 한 검증 세트가 실제로는 문제의 59.4%에 결함이 있었다는 사실이 드러나 폐기된 사례가 근거입니다. 그래서 개선 판단에는 우리 서비스 고유의 사례로 만든 기준만 씁니다. VoC 역시 업계 평균이나 다른 앱의 리뷰가 아니라, 우리 고객 4,300명이 남긴 목소리만을 근거로 삼았다는 점에서 같은 원칙이었습니다.
이 이야기를 지금 다시 꺼낸 이유도 여기에 있습니다. 4.0점에서 4.7점으로 오른 결과 자체보다, 결과를 만든 순서, 즉 결과부터 재고 원인은 나중에 찾는다는 순서가 그때는 사람이 기억으로 지키던 습관이었고 지금은 문서에 못 박힌 규칙이라는 점이 이 글에서 남기고 싶은 부분입니다. 사람이 바뀌고 회사가 바뀌어도 이 순서 자체는 그대로 유효했습니다.
새 프로젝트에 이 순서를 처음 들여올 때도 지금 규칙은 단계를 정해 둡니다. baseline 점수를 먼저 재고, 그 baseline보다 5점 높은 값을 첫 목표로 잡은 다음, 몇 개월에 걸쳐 80점과 85점으로 목표를 올립니다. 처음부터 85점을 요구하지 않는다는 점이 중요합니다. 2020년의 VoC도 첫 달부터 4.7점을 목표로 잡지 않았고, 지금 위치에서 갈 수 있는 다음 한 걸음만 정했습니다.
측정 없이 인상만으로 판단하다 놓친 경험은 이 자리에도 있습니다. 테스트 도구가 만든 유령 에러를 좇은 기록도 '측정 장치 자체를 의심하지 않으면 원인을 못 찾는다'는 같은 문제를 다룹니다. 평점이나 전환율처럼 이미 있는 지표를 다시 들여다보고 싶다면 상담에서 이야기할 수 있습니다.