패턴만 외워 빠르게 합격 — ADsP 학습 앱을 2주 만에 혼자 만들고 배포한 기록

Hobin·2026년 6월 17일

ADsP(데이터분석 준전문가) 수험생을 위한 CBT 학습 앱을 혼자서 2주 만에 기획·개발·배포했다.
1차 MVP에서는 코어 기능인 '패턴 학습'에 집중하기 위해 고도화 기획(버리기 모드 등)을 과감히 2차로 미뤘고, DB 없이 정적 JSON과 localStorage만으로 구현해 비용 0원과 트래픽 안정성을 확보했다.
방문자는 약 200명으로 크지 않지만, 학습 도구의 핵심 지표인 '재방문 세션'에서 약 80%를 달성했다. 이 글은 결과 자랑이 아니라, 제약(2주·비용 0·1인·첫 프로젝트) 속에서 내린 기획적 스펙 아웃과 기술적 의사결정을 정리한 기록이다.
🔗 https://adsp-app.vercel.app/


1. 왜 만들었나

CBT 자격증의 본질은 단순하다. 100점이나 60점이나 똑같은 합격이다. 일정 수준만 넘으면 되고, 그 이상의 깊이는 합격이라는 목적엔 비용일 뿐이다.

그런데 기존 학습 앱·인강은 방대한 지식과 장황한 해설로 무거웠다. 시장 1위 앱조차 책 구매가 전제였고, "합격선만 빠르게 넘게 해주는" 가벼운 도구의 공백이 보였다.

그래서 방향을 명확히 잡았다. 수험생을 학자로 만들지 않고, 패턴만 외워서 빠르게 합격하게 한다.

개인적으로 이건 첫 완주 프로젝트였다. 처음부터 무겁게 가지 않고, 빠르게 1차 MVP를 만들어 실제 유저 반응으로 코어 가치를 검증하는 형태를 원했다. 제약은 처음부터 분명히 잡았다.

  • 기간: 2주 (2026.05.18 ~ 05.31)
  • 비용: 0원 — 비상업 검증 프로젝트
  • 인력: 1인 — 기획·개발·디자인·배포 전부
  • 상황: 첫 프로젝트

이 제약이 이후 모든 기획안과 기술 스택을 덜어내는 강력한 기준이 됐다.


2. 무엇을 만들었나 (1차 MVP)

ADsP 합격 패턴 - 예상문제집은 ADsP 수험생을 타겟으로 한 CBT 학습 플랫폼이다. (Web + TWA 안드로이드 앱)

1차 MVP의 핵심 루프는 철저히 '기본기'와 '차별점 검증'에 집중했다.

문제 풀이 → 오답 노트(약점 보완) → 핵심 차별점 '패턴 매칭 학습'
  • 데이터 범위: 약 243문항, 29개 패턴 공식
  • 핵심 차별점: "보기에 ~키워드가 나오면 정답/오답" 형태의 패턴 공식화

장황한 해설 대신 통계 수식조차 '숫자 대입 공식'으로 패턴화하여, 유저가 최소한의 인지 에너지만 쓰고 직관적으로 정답을 고를 수 있도록 설계했다.


3. 기술 및 기획 의사결정

이 프로젝트에서 가장 고민한 부분이자 이 글의 핵심이다.

기술 스택: Next.js 14(App Router) + TypeScript + Tailwind CSS, Vercel 배포.

3-1. DB를 쓰지 않은 이유

가장 큰 결단은 DB와 백엔드를 아예 두지 않은 것이다.

  1. 빠른 검증 목표: 로그인·계정 관리는 1차 코어 루프 검증에 필수 요소가 아니었다. 학습 진도와 오답 노트는 유저 기기의 localStorage만으로 충분히 작동했다.
  2. 비용 0원 달성: DB 서버를 띄우면 유지 비용이 발생하지만, 정적 웹 호스팅은 사실상 무료다.
  3. 렌더링 속도: 매 요청마다 DB를 왕복하는 대신, 빌드 시점에 만든 정적 JSON 데이터를 클라이언트가 바로 읽는다. 연산도 브라우저에서 즉시 처리된다.

트레이드오프: 멀티 디바이스 동기화가 안 된다. 이를 보완하기 위해 진도 데이터를 JSON 형태로 클립보드에 백업/복원하는 우회 장치를 마련했다.

3-2. 스펙 아웃(Scope Out)의 결단: '버리기 모드'를 미룬 이유

기초 기획안에는 출제 빈도가 낮거나 패턴화가 불가능한 문제를 유저가 솎아내는 '버리기 시스템'이 포함되어 있었다.

하지만 2주라는 런칭 데드라인과 1인 개발이라는 리소스 한계 앞에서는 선택과 집중이 필요했다. 코어 기능인 '패턴 매칭 학습'이 완벽하게 동작하는지 확인하는 것이 최우선이었으므로, 매력적인 기능이라도 과감하게 2차 MVP 백로그로 밀어냈다. 모든 걸 다 담으려다 런칭을 못 하는 것보다, 핵심 기능 하나로 뾰족하게 시장을 찌르는 것이 스타트업의 MVP 방법론이라 판단했다.

3-3. AI 문항 생성·검증 파이프라인

퀴즈 앱의 본질적 리스크는 UI가 아니라 "문항의 정확성"이다. AI의 환각(Hallucination) 하나가 학습 도구의 신뢰를 박살 낸다. 그래서 생성에만 의존하지 않고, 검증 파이프라인을 시스템화했다.

  • 1차(AI 교차검증): Claude가 생성한 문항을 Gemini가 정합성 및 사실 관계 교차 점검.
  • 2차(운영자 샘플 검수): 양쪽 모델이 동일한 편향으로 틀렸을 맹점을 대비해 직접 샘플링 검수.
  • 스키마 규율: 모든 JSON 데이터가 엄격한 필드 스펙을 지키도록 강제하여 무음 에러(Silent Error) 방지.

4. 런칭과 지표 측정 (서버리스 환경의 트래킹)

DB와 백엔드 서버가 없는 환경이므로, 유저 행동을 추적하기 위해 프론트엔드 레벨에서 즉각 연동이 가능한 서드파티 애널리틱스를 도입했다.

  • 기본 트래픽 및 세션 추적: Vercel Analytics 연동
  • 유저 행동 및 UX 분석: Microsoft Clarity 연동

커뮤니티를 통해 초기 유입을 확보한 결과는 다음과 같다.

  • 방문자: 약 200명
  • 재방문 세션: 약 80%
  • 이탈률: 30%대

학습 도구라는 특성상 절대적인 트래픽 규모보다 유저가 이 앱을 다시 켜는가(재방문율)가 훨씬 중요하다. 트래픽이 작은 건 유료 마케팅의 부재와 시험 시즌 외 기간이라는 맥락이 컸지만, 그 안에서 재방문 세션이 80%가 나왔다는 것은(초기 표본 기준) '패턴 공식 학습'이라는 핵심 가치가 시장에 확실히 통했다는 PMF(Product-Market Fit) 신호였다.


5. 유저 피드백과 QA 부채

5-1. 정성 피드백과 로그 분석

"제가 공부할 때 있었으면 좋았겠어요", "출퇴근 때 유용하게 쓰고 있어요"

정량 지표와 더불어, 짧은 시간에 치고 빠지는 '단기 학습 앱'의 목적이 유저의 출퇴근 맥락과 정확히 맞아떨어졌음을 확인했다.

Clarity 로그를 분석하다 흥미로운 점을 발견했다. 유저들이 문제를 푸는 도중 보기 영역 바깥의 '빈 공간'을 무의미하게 클릭하는 데드 클릭(Dead Click)이 다수 포착된 것이다. 이를 집중 상태의 인지적 보조 니즈로 해석하고, 완주율을 높이기 위한 저자극 마이크로 인터랙션을 다음 백로그로 편입했다.

5-2. 빠른 런칭이 남긴 QA 부채

유저들은 내가 놓친 버그를 정확히 짚어줬다.

  1. "정답이 한쪽으로 쏠린다": 초기 데이터의 정답 위치 분포가 편향된 구조적 맹점이 있었다. 스크립트를 짜서 정답을 1~4번으로 균등 재배치했는데, 이 과정에서 해설 텍스트 속 "①번 보기" 같은 참조 기호가 옛 위치를 가리키는 2차 버그가 터졌다. 스크립트로 맵핑을 일괄 보정하며 구조화된 데이터 변환의 위험성을 배웠다.
  2. "오답 노트에 마지막 문제만 뜬다": 로컬 스토리지 배열 갱신 로직의 에러로 전체 오답이 아닌 최신 1개만 노출되던 버그였다. 즉각 수정 배포했다.

이 버그들은 런칭 전 QA에서 잡았어야 할 기본기였다. "빠른 검증"이라는 이점과 "QA 부채"를 맞바꾼 뼈아픈 경험이었다.


6. 삽질과 배움

첫 프로젝트라 모르는 게 많았지만, 기술적 막힘보다 "끝을 모르는" 데서 오는 내적 딜레이가 더 무서웠다. 하면 되는 일인데 처음이라 어디가 끝인지 감이 안 와서 섀도우 복싱을 하듯 멈칫거렸다.

하지만 이 프로젝트를 기획 → 개발 → 배포 → 피드백 루프까지 한 바퀴 온전히 돌려내고 나니, 무엇이 중요하고 무엇을 버려야 할지 기준이 섰다. 결국 가장 큰 배움은 특정 프레임워크 기술이 아니라 "완주해 낸 경험" 그 자체였다.


7. 회고 및 다음 스텝 (2차 MVP)

잘한 것

  • 리소스 한계를 인정하고 버리기 모드를 스펙 아웃하여 코어 검증(패턴 학습)에만 집중해 데드라인(2주)을 맞춘 것.
  • 서버 유지비 0원으로 유의미한 PMF 데이터를 뽑아낸 것.

프로젝트 간 학습

  • 이 앱은 '다시 켜야만 효과가 있는' 진통제형 도구다. 재방문 세션 ~80%가 그 증거다.
  • 직전에 만든 게임형 프로젝트(GRANDSLAM)는 반대로 '한 번 해보고 끝나는' 비타민형이라 초기 스파이크 후 유입이 빠르게 빠졌다.
  • 두 프로젝트를 나란히 놓고 보니, 제품의 잔존 동기 유무가 트래픽 효율을 가른다는 걸 데이터로 체득했다. 트래픽 절댓값보다 "왜 다시 오는가"가 먼저다.

아쉬운 것

  • 배포를 서두르다 발생한 크리티컬한 QA 부채(정답 쏠림, 오답노트 렌더링 에러).

Next Step (2차 MVP 고도화)
재방문 가설이 1차로 검증된 지금, 정적 앱을 온전한 프로덕트로 스케일업하기 위한 2차 MVP를 설계·기획 중이다. (아직 착수 전 단계이며, 아래는 확정된 백로그다.)

  1. 버리기 모드(시간 최적화) 구현: 1차에서 스펙 아웃했던 앱의 최종 목표치. 빈도가 낮거나 패턴화가 불가능한 문항을 숨겨 학습 시간을 수치적으로 단축해 주는 기능을 추가한다.
  2. DB 연동 및 데이터 영속성 확보: 브라우저 캐시 삭제 시 진도가 날아가는 한계를 극복하기 위해 Supabase 기반 클라우드 DB와 Auth를 연동한다. (기존 localStorage 데이터를 클라우드로 손실 없이 이관하는 마이그레이션 파이프라인 설계가 핵심).
  3. 포트폴리오 수평 확장: 현재의 JSON 데이터 구조를 모듈화하여, 데이터만 교체하면 SQLD, 정보처리기사 등 타 자격증을 동일 엔진으로 커버할 수 있는 멀티 플랫폼으로 확장할 예정이다.

0개의 댓글