Apsity가 내 12개 앱에서 반복해서 잡아낸 3가지 패턴
Apsity를 두 달 쓰면서 반복해서 잡아낸 3가지 패턴을 정리했다. 특정 국가 다운로드 급증, 업데이트 직후 conversion 하락, 리뷰 평점 급락. 각 패턴마다 어떻게 잡고 무엇을 했는지 솔직하게 기록했다.
On this page (6)
2026년 4월 · 귀찮은개발자 EP.16
Apsity가 내 12개 앱에서 반복해서 잡아낸 3가지 패턴
Apsity를 만든 지 두 달이 지났다. EP.02에서 대시보드를 만들었고, EP.03에서 AI 그로스 에이전트를 올렸다. 지금은 그 위에서 그냥 쓰고 있다.
처음엔 "기능이 많으면 좋은 거다"라고 생각했다. 그런데 두 달을 쓰니까 기능 개수는 별로 중요하지 않다는 걸 알게 됐다. 중요한 건 뭘 잡아내느냐였다.
이 글은 Apsity가 실제로 내 앱 12개에서 반복해서 잡아낸 패턴 3가지를 정리한 거다. 일회성 사건이 아니라 두 달 동안 여러 번 겪은 것들이다. 각 패턴마다 증상, 원인, 내가 한 조치를 솔직하게 적었다.
빠르게 보기
① 특정 국가 다운로드가 갑자기 급증한다 → 원인은 대부분 외부 언급(Reddit/YouTube/TikTok)이다. ② 업데이트 직후 conversion rate만 혼자 떨어진다 → 원인은 내가 바꾼 스크린샷이나 설명이다. ③ 리뷰 평점이 일주일 만에 0.3점 떨어진다 → Claude 클러스터링으로 공통 불만 하나를 찾아 바로 hotfix한다.
패턴 1 — 특정 국가에서 다운로드가 갑자기 급증할 때
Apsity의 Countries 메뉴는 국가별 다운로드를 7일 이동평균으로 추적한다. 현재 일자 값이 이동평균 대비 2배를 넘으면 알림이 뜬다. 공식 자체는 단순하다. 근데 단순한 게 잘 먹힌다.
한 번은 A 앱 Countries에서 "브라질 전주 대비 +312%"라는 알림이 떴다. 처음엔 버그인 줄 알았다. 왜냐하면 브라질은 그 앱에서 평소 주간 다운로드 상위 10위권에도 없던 나라였다.
먼저 App Store Connect 원본 숫자로 교차 확인했다. 진짜였다. 그제야 "이유"를 찾기 시작했다. Reddit 검색, YouTube 검색, TikTok 검색. 보통 이런 건 일주일 안에 답이 나온다. 그때는 포르투갈어로 된 TikTok 영상 하나가 원인이었다.
조치한 것: 브라질어(포르투갈어) 키워드 필드를 추가했다. App Store Connect에 국가별 메타데이터를 따로 넣을 수 있는데, 그동안 영어만 쓰고 있었다. 그리고 해당 영상 링크를 저장해뒀다. 나중에 비슷한 트래픽이 올 때 패턴을 확인하려고.
이런 일이 월 1~2회 반복해서 일어난다. 빈도가 낮아 보이지만 모르고 지나가면 "이유 없이 시작된 trend"가 조용히 꺼진다. 반대로 바로 반응하면 원래 없던 나라를 주력 시장으로 키울 수 있다. 브라질은 그 후로 그 앱 상위 5위 국가에 들어왔다.
패턴 2 — 업데이트 직후 conversion rate가 혼자 떨어질 때
이게 제일 자주 당한다. 그리고 제일 늦게 알아차리는 것도 이거다. 이유는 간단하다. 내가 rank만 보고 있었기 때문이다.
새 빌드를 배포하고 하루 지나면 App Store Connect에 숫자가 찍힌다. Impressions(노출)는 그대로, Installs(설치)는 뚝. Rank는 변동 없음. 만약 내가 rank만 보는 습관이었다면 이걸 못 잡았다.
Apsity의 Overview 첫 화면은 rank, impressions, conversion rate 3개를 한 줄에 나란히 놓는다. 일부러 그렇게 만들었다. 처음 만들었을 땐 4개, 5개씩 넣고 싶었는데 결국 3개로 줄였다. 나란히 놓고 봐야 어느 지표 하나만 혼자 움직이는 걸 즉시 알 수 있기 때문이다.
실제로 B 앱에서 이런 일이 있었다. 업데이트 다음 날 Overview를 보니 rank 그대로, impressions 그대로, conversion만 -18%. 바로 원인 추정에 들어갔다. 알고리즘은 아닌 것 같았다. 보통 알고리즘 변화는 impressions도 같이 흔든다. conversion만 혼자 움직이는 건 거의 항상 내 탓이다.
확인해보니 업데이트 때 첫 번째 스크린샷을 교체했다. "더 잘 만들었다"고 생각했던 새 스크린샷이었다. 원복했다. 48시간 안에 conversion이 원래 수치로 돌아왔다.
교훈: rank는 결과다. 원인을 보려면 impressions와 conversion이 필요하다. 두 개 중 하나만 있어도 절반만 보는 거다. 그래서 Apsity 첫 화면을 3지표 동시 뷰로 고정했다.
이 패턴 덕분에 한 가지 습관이 생겼다. 업데이트 배포 후 48시간 동안은 Overview를 아침저녁으로 열어본다. 평소엔 아침에 한 번만 본다.
패턴 3 — 리뷰 평점이 일주일 만에 0.3점 떨어질 때
리뷰는 제일 직접적인 신호다. 동시에 제일 읽기 귀찮은 신호이기도 하다. C 앱은 평소 평균 4.6을 유지하던 앱인데, 어느 월요일 아침에 확인해보니 4.3이었다. 일주일 만에 0.3점이 빠졌다.
0.3점은 많다. 7일 동안 들어온 신규 리뷰가 1점이나 2점 쪽으로 쏠렸다는 뜻이다. 평소엔 5점 리뷰가 다수라 평균이 유지되는데, 갑자기 쏠렸다는 건 공통 이슈가 있다는 거다.
직접 읽기엔 너무 많다. 최근 7일치만 해도 80개 정도 됐다. 그래서 Apsity Reviews 메뉴에서 바로 Claude한테 클러스터링을 시켰다. 프롬프트는 대충 이런 거다.
다음은 최근 7일간 C 앱에 달린 1~2점 리뷰 80개다.
각 리뷰를 불만 카테고리로 묶고, 가장 많이 나온 top 3 카테고리를 뽑아라.
출력은 JSON으로. 각 카테고리마다 대표 인용 1개 포함.
결과는 3분 안에 나왔다. top 1 카테고리는 "최근 업데이트 후 앱이 특정 화면에서 멈춘다"였다. 인용 2개만 읽어봐도 같은 화면이 지목되고 있었다. 버그 위치가 거의 확정된 거다.
그대로 해당 화면을 열어서 재현해봤다. 5분 만에 재현됐다. 특정 기종(iPhone 12 mini)에서만 나는 레이아웃 오류였다. hotfix를 그날 저녁에 올렸고, 다음 주 월요일엔 4.3이 4.5로 돌아와 있었다.
요점: 80개 리뷰를 사람이 읽는 건 미친 짓이다. Claude에게 맡기면 3분이다. 정확도도 높다. "감정 점수"보다는 "카테고리 분류 + 대표 인용"이 훨씬 쓸만하다. 결정에 쓸 수 있는 형태이기 때문이다.
3가지 패턴이 공통적으로 말해주는 것
세 패턴을 겪고 나서 알게 된 게 있다. rank는 결과다. 순위가 떨어지고 나서야 움직이면 이미 늦는다. 원인을 보려면 다른 지표가 필요하다. Countries, Impressions, Conversion, Reviews 같은 것들이다.
그리고 한 가지 더. 알림이 오는 구조가 중요하다. 내가 매일 9개 메뉴를 일일이 훑는 대신, "이상한 일이 생길 때만" 알려주는 구조가 필요하다. 사람은 매일 같은 대시보드를 보다 보면 무뎌진다. 알림은 그걸 방지해준다.
그래서 내가 Apsity에서 제일 자주 여는 건 결국 세 곳이다. Overview(3지표), Countries(급증 알림), Reviews(클러스터링). 나머지 6개 메뉴는 필요할 때만 열어본다. 9개를 다 매일 본다는 건 환상이었다.
FAQ
Q1. 앱 개수가 적어도 이런 패턴을 잡을 수 있나?
가능하다. 오히려 앱이 1~2개면 손으로 매일 확인하는 게 더 빠를 수 있다. 4개를 넘어가면 수동으로는 못 따라간다. 내가 대시보드를 만든 시점도 앱이 5개를 넘었을 때였다.
Q2. 무료 도구로도 이 패턴을 잡을 수 있나?
App Store Connect + 구글 스프레드시트 조합이면 어느 정도 가능하다. 다만 매일 보는 건 결국 지친다. "알림이 올 때만 본다"는 구조가 더 오래 간다. 그게 내가 Apsity를 만든 이유다.
Q3. 국가 다운로드 급증 임계값은 어떻게 정했나?
7일 이동평균 대비 현재 일자 값이 2배를 넘으면 알림을 띄운다. 단순한 공식이지만 실제로 잘 잡힌다. 처음엔 3배로 했는데 놓치는 게 많아서 낮췄다. 2배 이하로 내리면 오탐이 너무 많아서 이 수치에서 멈췄다.
Q4. 리뷰 클러스터링은 Claude 말고 다른 모델도 되나?
된다. GPT-4o나 Gemini로도 비슷한 품질이 나온다. 다만 일관된 JSON 포맷을 뽑는 안정성은 Claude Sonnet 쪽이 제일 좋다. 내가 다른 데서도 같은 이유로 Claude를 고른다.
마무리
Apsity를 만든 건 시작이었다. 두 달을 써보니 알게 된 건, 대시보드 기능 개수보다 뭘 잡아내느냐가 훨씬 중요하다는 거다. 그리고 "뭘 잡아낼지"는 설계할 때가 아니라 쓰면서 알게 된다.
위의 3가지 패턴은 다 설계 당시엔 생각도 못한 것들이다. 두 달 동안 반복해서 겪고 나서 "이거 항상 일어나는 일이네"라고 깨달은 거다. 지금 대시보드는 이 3가지를 잘 잡아내도록 조금씩 바뀌어왔다.
다음 EP에서는 이 중 한 가지(리뷰 클러스터링)를 구현한 과정을 더 파볼 생각이다. 80개 리뷰를 3분에 처리하는 프롬프트가 어떻게 생겼는지, 정확도는 어떻게 검증하는지 같은 것들이다.
이 글이 도움이 됐다면 Apsity에서 직접 확인해볼 수 있다. 14일 무료 체험이 있다.