[AI 주식 알람] 시장조사 없이 시작한 기능 목록은 왜 산으로 가는가: Pain 지표로 PRD 자르기

AI 주식 알람 앱을 혼자 만들면서 가장 먼저 한 일은 화면을 그리는 게 아니라 "이 앱이 없어도 되는 이유"를 스스로 반박하는 일이었다. 개인 프로젝트라 검증할 사용자 풀도 크지 않고, 그렇다고 감으로 기능을 쌓으면 결국 "차트 예쁘게 그려주는 앱"에서 못 벗어난다는 걸 알고 있었다. 그래서 기능 리스트를 만들기 전에 페르소나, Pain, KPI를 먼저 표로 못박고, 그 표에 안 걸리는 아이디어는 아예 시작을 안 하기로 했다.

이번 편은 PRD를 쓰기 전 단계 — 시장조사를 어떻게 구조화했고, 그게 실제로 어떤 기능을 쳐냈는지에 대한 기록이다.

1. 페르소나부터: "누구의 아침"을 대체할 것인가

리서치 문서를 정리하면서 페르소나를 세 개로 좁혔다.

페르소나	특징	핵심 Pain	핵심 Needs
바쁜 직장인 서학개미	한국 거주, 미국장 실시간 대응 불가, 예약주문 위주	정보 과잉, 장중 대응 불가	아침에 1~3개 후보, 바로 주문 가능한 숫자
준경험 투자자	뉴스/유튜브는 보지만 차트 해석은 약함	차트 복잡성, 확신 부족	방향·가격·기간을 한 장으로 이해
불신형 유료 독자	리딩방/유튜버 경험은 있으나 맹신은 원치 않음	검증 부재, 책임 공백	확률·성과 이력·한 줄 이유

 

세 페르소나를 관통하는 공통점은 "차트를 더 잘 읽고 싶다"가 아니라 "차트를 안 읽어도 되고 싶다"는 것이었다. 이 지점에서 이미 방향이 정해졌다 — 지표를 더 얹는 앱이 아니라, 지표를 걷어내는 앱을 만들어야 한다는 것.

페르소나별 여정과 Pain. needs 연결

2. Pain을 감이 아니라 숫자로 정의하기

여기서 제일 시간을 많이 쓴 부분이다. "정보가 너무 많아서 힘들다" 같은 말은 기능 우선순위를 정하는 데 아무 쓸모가 없다. 그래서 Pain마다 실패 KPI와 측정 이벤트를 같이 정의했다.

Pain ID	Pain	실패 KPI (가설)	측정 이벤트
P1	정보 과잉으로 탐색 피로	추천 카드 CTR < 35% 또는 첫 추천 도달 > 90초	rec_card_impression, rec_card_click
P2	차트/지표 해석이 어려움	상세 진입률 < 40%	rec_detail_view
P3	실행 가능한 가격·시점 부재	가격 제안 포함 카드 < 95%	카드 스키마 검증
P4	리스크 선택 구조 없음	Confidence Score 조작률 < 30%	confidence_view, confidence_change
P5	AI 결과가 블랙박스처럼 느껴짐	이유 설명 열람률 < 45%	reason_expand, performance_card_view
P6	장중 대응이 어려움	푸시 오픈율 < 20%	push_sent, push_open
P7	반복 사용 루틴이 약함	D7 리텐션 < 22%	session_start

 

이렇게 표로 만들어 놓으니 좋은 점은, 나중에 "이 기능 넣을까?" 하는 순간마다 "이게 어느 Pain ID를 줄이는지" 되물을 수 있다는 것이다. 대답을 못 하면 그 기능은 보류다.

3. 북극성 KPI 하나로 줄이기

보조 지표를 여러 개 두면 결국 다 잘하는 척하다가 아무것도 못 잡는다. 그래서 KPI도 하나만 북극성으로 정했다.

NS-01 Actionable Decision Rate (ADR) = 24시간 내 actionable_event 발생 사용자 수 / rec_card_view 사용자 수

 

여기서 actionable_event는 저장, 알림설정, 브로커 이동, 가격 복사, 실행 의향 제출 중 하나 이상이 발생한 것을 뜻한다. 기준선 18%, 목표 35%로 잡아뒀다. 나머지 CTR, First Decision Time, Confidence Engagement Rate 같은 지표는 전부 이 하나를 설명하는 보조 지표로만 쓴다.

4. ADR 5개 — 직관에 반하는 결정을 문서로 박아두기

가장 논쟁적이었던 결정은 이거다: 차트와 보조지표를 메인 화면에서 뺀다. 주식 앱에서 차트를 뺀다는 게 말이 되나 싶었는데, 페르소나 리서치로 돌아가 보면 답이 나온다 — 이 사용자들은 차트를 잘 읽고 싶은 게 아니라 차트 없이 판단하고 싶은 사람들이다.

이런 직관에 반하는 결정들은 나중에 "그냥 넣을까?"로 흔들리기 쉬워서, ADR(Architecture Decision Record) 5개로 못박아 뒀다.

ADR	결정
ADR-001	핵심 출력은 정보가 아니라 행동 카드 (Decision Layer)
ADR-002	Confidence는 선택 가능한 UX — 수동적인 배지로 두지 않는다
ADR-003	예측 범위는 3~5 영업일 — 틱 단위 시그널 없음
ADR-004	차트/지표는 메인 화면에서 배제 — 결과 중심 UI
ADR-005	성과 공개형 Trust Layer — 실패 포함 이력 공개

 

실제로 개발 중에 "가격 차트 넣을까?"라는 생각이 들었고, ADR-004를 다시 읽고 "차트는 상세 페이지에서 접었다 펼치는 보조 요소로만" 타협했다.  문서가 없었으면 매번 새로 논쟁했을 부분이다.

개발을 하면서 추가된 요소들도 꽤 있었다. 초기개발시 페르소나를 세가지로 잡고 진행했을 때는 필요없다 생각이 들었지만, 실제 주식어플을 매일 보는 나의 경험으로는 있으면 좋을 것같아 추가하였다.

5. 기능 게이트: 신규 아이디어를 걸러내는 5문항

리서치 단계에서 만든 것 중 실제로 가장 자주 꺼내 쓴 건 이 5문항이다. 새 기능 아이디어가 생길 때마다 이 체크리스트를 통과하는지 본다.

1. 이 기능이 Decision Layer를 강화하는가?
2. 사용자의 리스크 선택권을 강화하는가?
3. 3~5일 실행 맥락과 맞는가?
4. 복잡도를 낮추는가, 높이는가?
5. 신뢰를 데이터로 증명하는 구조에 기여하는가?

이 중 2개 이상에 명확히 반하면 보류. 예를 들어 "커뮤니티 기능(전략 공유, 토론)"은 1번은 걸리지만 4번(복잡도)과 5번(신뢰 증명)에 반해서 Out-of-Scope로 뺐다.

6. 정리

시장조사 단계에서 만든 산출물은 결국 페르소나 3개, Pain 표 1개, KPI 1개(+보조 8개), ADR 5개, 게이트 5문항 — 문서량으로는 많지 않다. 그런데 이후 개발 전 과정에서 "이거 넣을까 말까"를 결정하는 기준은 전부 이 표에서 나왔다. 다음 편에서는 이 PRD를 AI 에이전트가 그대로 파싱해서 요구사항으로 쓸 수 있게 SRS로 바꾸는 과정을 정리한다.