오픽 앱성장코호트결정

가입이 27% 줄었는데 매출은 최고였던 주

주말 가입이 급감해서 사고인 줄 알고 들어갔다. 시장 수요의 계절 하강이었고, 코호트를 재 보니 리텐션으로 버틸 사업이 아니었다.

2026년 9월 21일8

주말 가입이 눈에 띄게 줄었다. 제품이나 검색 유입에 문제가 생겼다고 생각하고 진단에 들어갔는데, 결론은 둘 다 아니었다. 시장 자체가 내려가는 시기였고, 그 김에 코호트를 실측하다가 이 사업의 전제 하나가 바뀌었다.

내가 운영하는 앱은 오픽 모의고사 앱이다. 가입하면 무료 크레딧을 주고, AI 채점을 받으려면 크레딧을 산다. 이 글은 "가입이 왜 줄었나"에서 시작해서 "이 앱은 무엇으로 먹고사는가"로 끝난다. 일어난 순서대로 쓴다.

첫 조회에서 전면 장애가 보였다

가장 먼저 DB 에서 일별 가입을 뽑았다. 그런데 결과가 생각보다 훨씬 나빴다. 줄어든 수준을 넘어서, 특정 날짜부터 거의 끊긴 것처럼 나왔다. 가입 경로가 죽었나 싶었고, 잠깐은 진짜 사고라고 믿었다.

사고가 아니었다. 조회가 틀린 것이었다.

이 앱의 ORM 은 DateTime 을 timezone 없는 UTC 로 저장한다. 그 컬럼에 AT TIME ZONE 'Asia/Seoul' 을 붙이면 Postgres 는 값을 이미 서울 시간으로 해석하고 UTC 로 되돌린다. 올바른 값과는 반대 방향이라 둘의 차이가 18시간이다. 그러면 최근 열여덟 시간의 가입이 전날로 밀려 들어가고, 오늘 칸은 비어 보인다. 며칠을 붙여 보면 가입이 끊긴 것처럼 읽힌다.

-- 틀림: 값이 timestamp(without tz)라 서울 시간으로 간주된 뒤 UTC 로 변환된다
created_at AT TIME ZONE 'Asia/Seoul'
 
-- 맞음: UTC 값에 9시간을 더하는 것뿐이다
created_at + interval '9 hours'

부끄러운 건 이 함정을 내가 이미 알고 있었다는 점이다. 같은 앱의 비용 집계 쿼리를 만들 때 똑같이 걸렸고, 그때 메모에 적어뒀다. 적어둔 메모는 읽어야 효력이 있더라. 조회를 고치고 나서야 진짜 숫자가 나왔다.

진짜 숫자는 −27% 였다

기간가입 (월~토)
9월 7일 ~ 12일114
9월 14일 ~ 19일83

27% 감소. 전면 장애는 아니지만 무시할 폭도 아니다. 이 정도면 보통 두 가지를 의심한다. 검색 순위가 떨어졌거나, 어딘가 화면이 깨졌거나.

그래서 서치 콘솔을 열었다. 일별 클릭이 9월 8일에서 10일 사이에는 69~73 이었는데, 13일에서 17일 사이에는 35~50 이었다. 가입과 같은 모양으로 내려가 있었다. 순위가 빠진 건 아니었다. 페이지별 순위는 그대로였고 노출이 줄어 있었다.

노출이 줄었다는 건 검색하는 사람이 줄었다는 뜻일 수 있다. 그래서 세 번째로 Google Trends 에서 오픽 을 봤다. 9월 6일에서 10일이 100 이었고 그 뒤 45 근처까지 내려와 있었다.

−27%
가입. 9/07 주 114명에서 9/14 주 83명
69~73 → 35~50
서치 콘솔 일별 클릭. 순위는 그대로, 노출이 줄었다
100 → 45
Google Trends '오픽'. 9/6~9/10 이 피크였다

세 계열이 같은 모양이면 시장이다. 자사 지표 하나만 보면 우리한테 무슨 일이 생긴 것처럼 보이는데, 검색량 자체가 그 모양으로 움직이고 있었다. 앱을 고쳐서 될 일이 아니었다.

5년 치를 보니 칼날이었다

Trends 를 5년으로 늘려 봤다. 오픽 검색량은 뾰족한 칼날 두 개 모양이었다. 매년 3~4월과 9월 초에 솟았다가 2~4주 만에 기저선으로 떨어진다. 2026년 9월의 피크는 9월 6일에서 10일이었고, 내가 "가입이 줄었다"고 느낀 주말은 정확히 그 칼날의 뒷면이었다.

드라이버는 채용 시즌인 것 같다. 오픽은 상시 시험이라 "지난주가 시험 주간이었나" 같은 질문이 성립하지 않는다. 지원서 마감이 사람들을 검색창으로 보내는 듯하다. 이건 해석일 뿐이라 확신은 없다.

그러면 9월에 들어온 사람을 붙들어 두자

여기까지 오면 자연스러운 다음 생각이 있다. 피크 때 들어온 사람들을 다음 피크인 3~4월까지 붙들어 두면, 다음 피크를 재방문으로 시작할 수 있지 않을까. 진단을 시작한 날 내가 잡은 방향이 이것이었다. 리텐션을 올려서 계절성을 평탄하게 만들자는 얘기다.

그래서 코호트를 실측했다. 가입한 주를 기준으로, 다음 주에 AI 채점을 한 번이라도 쓴 사람이 몇 명인지.

가입 주별 코호트 크기와 다음 주 AI 사용자 수 (8/17 주 ~ 9/14 주)
062.512515
그 주 가입자86다음 주에 AI 를 쓴 사람0

가입 곡선은 피크를 향해 올라가는데 활성 곡선은 바닥에 붙어 있다. 비율로 보면 11%, 7%, 10%, 2%, 0% 다. 피크 주인 9월 7일 코호트는 124명이 들어와서 다음 주에 3명이 썼다. 9월 1일에서 12일 사이의 피크 코호트 202명 중에 최근 7일 안에 활성인 사람은 6명, 3% 다.

이 숫자를 보고 그 방향을 접었다. 3% 를 6개월 뒤까지 끌고 갈 방법을 고민하기 전에, 애초에 붙들 사람이 없었다. 시험을 보면 목적이 끝나고, 사람들은 그래서 떠난다. 이건 고칠 결함이 아니라 이 카테고리의 속성이었고, MAU 나 리텐션을 KPI 로 두면 계속 헛다리를 짚었을 것이다.

리텐션 사업이 아니었다. 그러면 뭐였을까.

결제는 3일 안에 끝난다

가입 이후 첫 결제까지 며칠이 걸리는지 뽑았다.

가입 후 첫 결제까지 걸린 일수 · 25
당일1040.0%
1~3일728.0%
4~7일312.0%
8일 이상520.0%

가입 당일과 1~3일이 전체의 68% 다. 8일 넘게 걸린 결제는 5건뿐이다.

3일 안에 68% 다. 그리고 이 시차가 처음 질문에 대한 답을 완성한다.

가입이 27% 줄어든 9월 14일 주에 매출은 오히려 최고였다. 웹 결제 기준으로 78,200원, 10건. 그 전주는 74,700원, 13건. 피크 주에 들어온 코호트가 며칠 시차를 두고 결제한 것이고, 그 시차가 3일 안팎이라 다음 주 매출로 잡힌 것이다. 가입이 줄어드는 주에 매출이 오르는 게 이 사업의 정상 모양이더라.

그러니 식은 하나로 줄어든다. 매출은 피크 기간의 신규 가입에 3일 내 결제 전환을 곱한 것이다. 피크 밖의 활성 사용자 수는 이 식에 들어가지 않는다.

국면이 넷이면 할 일도 넷이다

이렇게 정리하고 나니 연중 할 일이 시기별로 갈렸다.

국면할 일하지 말 것
상승 (피크 2~4주 전)배포 동결 준비, 결제 경로를 실제로 눌러 보는 검증큰 변경
피크 (3~4월, 9월 초)전환에만 집중. 결제와 로그인 장애 감시기능 배포
하강 (피크 후 2~4주)사후 분석, 안정성 정리원인 찾겠다고 제품 흔들기
기저 (비수기)SEO 와 스토어 자산 구축. 효과까지 4~8주라 여기서 만든다리텐션 개선 프로젝트

이 중에 제일 비싼 항목이 상승기의 결제 검증이다. 이번 9월 피크 직전에 안드로이드 인앱결제가 열흘간 조용히 죽어 있었고, 그 얘기는 따로 썼다. 그때는 "검증을 안 했다"는 반성으로 끝났는데, 이제 보면 그 열흘이 1년에 두 번뿐인 매출 창의 문턱이었다. 같은 사고라도 시기에 따라 값이 다르고, 이 사업에서는 피크 직전이 제일 비싸다.

비수기의 할 일도 바뀐다. 검색 자산은 만들고 나서 효과가 나오기까지 4~8주가 걸린다. 피크 때 만들면 늦고, 하강기에 만들면 조급해진다. 10월에서 12월에 만든 것이 3월에 열매를 맺는 구조라, 지금부터의 석 달이 다음 피크를 정한다고 보고 있다.

아직 검증되지 않았다

여기까지가 9월 20일에 세운 원칙이다. 솔직히 말하면 이 원칙은 한 번도 시험되지 않았다. 다음 피크가 3~4월이라 결과는 반년 뒤에야 나온다. 그때 가서 "비수기에 쌓은 자산이 피크 신규를 늘렸다"는 게 확인되면 이 글은 맞은 글이 되고, 아니면 계절성을 핑계로 반년을 흘려보낸 글이 된다.

계절 곡선도 아직 남의 것이다. 지금은 Google Trends 를 기준으로 삼고 있는데, 우리 자체 가입 곡선으로 연 2회 스파이크를 확인한 적은 아직 없다. 월 1회 세 계열을 같이 기록해 두기로 했고, 두 번째 피크가 지나면 Trends 없이도 국면을 읽을 수 있을 것 같다.

그리고 시간대 함정은 이번이 두 번째다. 메모에 있었는데 또 밟았으니 다음에 또 밟지 않으리라는 보장이 없다. 이번에는 맞는 조회를 읽기 전용 스크립트로 남겨 두긴 했는데, 새 쿼리를 손으로 쓰는 날이 문제다.

다음 확인은 10월 첫째 월요일이다. 그때까지는 숫자가 내려가도 손대지 않기로 했다.