AI 프로덕트 만들기

한 번도 써 본 적 없는 프로덕트의 명세를 짜는 데 이틀을 보냈다. 대신 무엇을 했어야 했는지 적는다.

2026-03-20

영어 원문에서 옮김

나는 AI 기반 투자 리서치 도구를 만들어 왔다. 여러 섹터에 걸친 공급망 분석, 자동 논제 관리, 적대적 스트레스 테스트까지 없는 게 없다. 지난 이틀 동안 내 AI 코딩 어시스턴트와 나는 이런 것들을 만들어 냈다.

• 명세 문서 11종 (Prisma 스키마, API 계약, 전파 알고리즘으로 1,400줄이 넘는다)
• 인터랙티브 UI 목업 5종
• 병렬 레포 구축을 위한 자율 빌드 프롬프트 2종
• 버그 38개를 잡아낸 외부 리뷰 3회
• 리서치 시스템 재작성 4회

그런데도 나는 이 프로덕트를 단 한 번도 써 보지 않았다.

불평하려고 쓰는 글은 아니다. 명세는 정말로 좋다. 아키텍처는 적대적 리뷰를 견뎌 냈다. 코드는 지금 이 순간 두 개의 터미널에서 빌드되고 있다. 그러나 리서치 파이프라인을 세 번째로 재작성하던 즈음 나는 깨달았다. 나는 어둠 속에서 설계해 왔다. 모든 ‘발견’은, 데이터베이스 경로 버그든 Google News 품질 문제든 가짜 시드 데이터 문제든 잠든 노트북에서는 cron이 돌지 않는 문제든, 실제로 써 봤다면 첫 10분 안에 찾아냈을 것들이었다.

이 글은 내가 처음부터 따랐더라면 좋았을 프레임워크다.

잘못된 패턴

내가 한 일은 이랬다.

막연한 아이디어
  → 전부 설계한다
    → 전부 명세한다
      → 명세를 리뷰한다
        → 명세를 고친다
          → 전부 빌드한다
            → 상상대로 돌아가지 않음을 발견한다
              → 재작성한다

아이디어에서 첫 실사용까지 걸린 시간은 몇 주. 빌드 전에 배운 것은 거의 없음.

명세는 내가 상상한 것을 담았다. 내가 필요로 한 것은 담지 못했다. 이 둘은 서로 다른 것이고, 프로덕트를 써 보지 않고서는 둘을 가려낼 수 없다.

실제로 통하는 패턴

막연한 아이디어
  → 핵심 루프를 한자리에서 빌드한다 (2~4시간)
    → 사흘 동안 내가 직접 써 본다
      → 실제로 써 보니 빠진 것을 적는다
        → 빠진 조각을 빌드한다
          → 일주일 써 본다
            → 이제 진짜 프로덕트가 무엇인지 안다
              → 그것을 명세하고 빌드한다

아이디어에서 첫 실사용까지 걸린 시간은 하루 오후. 아키텍처를 확정하기 전에 배운 것은 중요한 전부.

0단계 세 가지 질문 (30분)

막연한 아이디어가 있다. 설계하지 마라. 명세하지 마라. 코드 에디터를 열지 마라. 세 가지 질문에 답하라.

Q1. 원자적 행동은 무엇인가. 이 프로덕트로 매일 하게 될 단 하나의 일이다. 거창한 비전이 아니다. 가장 작고 쓸모 있는 상호작용이다.

내 도구의 경우 “내 투자 논제에 관한 아침 브리핑을 읽고 손볼 게 있는지 정한다”이다.

Q2. 그 행동을 가능하게 하는 데이터는 무엇인가. 최소한의 데이터다. 완전한 데이터 모델이 아니다.

“근거가 딸린 논제 5~10개, 그리고 거기 맞물린 오늘의 관련 뉴스.”

Q3. 한 세션에서 ‘끝’은 어떤 모습인가. 앱을 닫을 때 무엇을 해냈는가.

“오늘 내 논제 중 무엇이 강해지고 약해졌는지 알고, 손을 댔거나 대지 않기로 정한다.”

이 질문들에 또렷이 답하지 못한다면 아이디어가 아직 무르익지 않은 것이다. 계속 생각하라. 빌드하지 마라.

1단계 한자리 프로토타입 (2~4시간)

내일 아침 실제로 쓸 수 있는 것을 빌드하라. 데모가 아니다. 목업이 아니다. 진짜처럼 느껴질 만큼 충분히 진짜인 데이터로 원자적 행동을 해내는 도구다.

규칙은 이렇다.

• 단일 파일이거나 단일 페이지. 아키텍처는 없다.
• 하드코딩한 데이터로 충분하다. 직접 쓴 실제 예시 3~5개가 담긴 JSON 파일이면 된다.
• 데이터베이스 없음. API 없음. 인증 없음.
• UI는 못생겨도 된다. 상호작용만은 진짜여야 한다.
• 내일 그것을 열어서 그 일을 처음부터 끝까지 해낼 수 있어야 한다.

내 도구의 경우 이랬어야 했다. 직접 쓴 투자 논제 5개, 그날 아침 찾은 진짜 뉴스 헤드라인 3개, 그리고 각각을 “강화 / 약화 / 무관”으로 표시하는 버튼이 달린 단일 HTML 페이지. 결정은 localStorage에 저장한다. 총 빌드 시간은 2시간.

내가 실제로 한 일은 이랬다. 테이블 15개짜리 데이터베이스 스키마, 에이전트 4개짜리 파이프라인, 그리고 감쇠 계수가 달린 전파 엔진을 설계했다. 프로덕트를 단 한 번도 써 보기 전에.

2단계 사흘 테스트 (사흘, 하루 15분)

사흘 동안 매일 프로토타입을 써라. 정말로 써라. “들여다보며 쓰는 상상을 하는” 것이 아니다. 일어나서, 열고, 그 일을 하라.

세션마다 정확히 세 가지를 적어라.

1. 내가 실제로 한 일 (하려던 일이 아니다)
2. 빠져 있어서 다른 도구로 손이 가게 만든 것
3. 내가 끝내 건드리지 않은 것

사흘이면 관찰 아홉 개가 모인다. 어떤 명세 문서보다 값지다. 이것들이 드러내는 것은 이렇다.

• 진짜 워크플로 (상상한 것이 아니라)
• 진짜 데이터 요건 (이론상 완전한 모델이 아니라)
• 필수처럼 보였지만 그렇지 않은 기능

사흘 동안 프로토타입을 써 봤다면 내가 배웠을 것은 이렇다.

• 아침 흐름은 30분이 아니라 5분 걸린다. 5분에 맞춰 설계하라.
• 나는 하루에 논제 2~3개만 신경 쓴다. 22개를 띄우는 건 소음이다.
• 적대적 도전 기능은 커피를 마시기 전엔 거슬린다. 저녁으로 옮겨라.
• 데이터 품질은 데이터 자동화보다 한없이 더 중요하다. SEC 공시에서 나온 진짜 발견 하나가 긁어모은 헤드라인 12개를 이긴다.
• 거래 행동은 신호에서 한 번 클릭으로 닿아야 하고, 별도 페이지에 파묻혀서는 안 된다.

명세를 한 줄 쓰기도 전에 나는 기능의 절반을 쳐냈을 것이다.

3단계 아키텍처 결정 (2~4시간, 문서 하나)

이제 프로덕트가 무엇인지 안다. 상상한 것이 아니라 겪은 것이다. 이론상의 워크플로가 아니라 진짜 워크플로를 중심으로 아키텍처를 설계하라.

문서 하나를 써라. 그 문서가 다루는 것은 이렇다.

1. 일일 루프. 정확히 무슨 일이 어떤 순서로 몇 분 안에 벌어지는가
2. 데이터 모델. 일일 루프에 필요한 테이블만
3. 빌드 순서. 가장 많이 쓰는 것을 바탕으로 무엇을 먼저 빌드할지

빌드 순서 규칙은 표시보다 데이터가 먼저라는 것이다. 나는 화면들이 표시할 데이터를 만들어 내는 리서치 시스템을 빌드하기도 전에 아름다운 UI 화면 5개를 빌드했다. 몇 주 동안 앱은 지어낸 숫자를 멋지게 시각화해 보여 주었다. 진짜 숫자를 만들어 내는 시스템, 곧 SEC 공시를 가져오고 실제 10-K 공시에 대고 간선 파라미터를 검증하는 그 시스템은 맨 마지막에 왔고 재작성을 4회 거쳤다. “진짜 데이터”가 실제로 무슨 뜻인지를 내가 자꾸 새로 발견했기 때문이다.

데이터가 틀리면 UI는 의미가 없다. 데이터 파이프라인을 먼저 빌드하라.

명세가 아니라 아키텍처를 리뷰하라. 리뷰어 한 명이 내 데이터 모델과 일일 루프에 20분을 쓰는 편이, 세 명이 수백 쪽 명세를 읽는 것보다 더 많이 잡아낸다. 나는 독립적인 리뷰 셋이 똑같은 근본 결함으로 수렴하는 것을 겪었다. 나는 결정론적으로 계산된 답을 AI가 서술만 하게 했어야 하는데, 복잡한 시스템 문제의 답을 AI에게 계산하라고 시키고 있었다. 20분의 리뷰가, 몇 주의 내부 반복으로는 결코 찾지 못했을 것을 찾아냈다.

4단계 AI와 함께 빌드 (Claude Code로 12주, 없으면 46주)

여기서 AI 코딩 도구가 셈을 바꾼다. 1인 개발자에게 몇 달 걸리던 일이 이제 며칠 걸린다. 그러나 속도 배수는 1~3단계의 규율을 덜 중요하게가 아니라 더 중요하게 만든다.

이유는 이렇다. 잘못된 것을 석 달이 아니라 사흘 만에 빌드할 수 있다면, 그것이 잘못됐음을 더 빨리 알아야 한다. 프로토타입 우선 방식은 느리고 신중하자는 것이 아니다. 내 빌드 속도에 맞출 만큼 빠르게 배우자는 것이다.

Claude Code와 함께라면 빌드 순서는 이렇다.

핵심 원칙은 4일째부터 매일 아침 그것을 쓰는 것이다. 빌드하면서 동시에 쓴다. 아침마다 그날 오후 무엇을 빌드할지가 드러난다. 15일째면 프로덕트는 상상이 아니라 열흘 넘는 실사용으로 다듬어져 있다.

Claude Code가 없다면 이것을 4~6주로 늘리되, 원칙은 같다. 핵심 루프가 돌아가는 순간부터, 나머지가 다 빠져 있어도 그것을 써라.

통하는 빌드 프롬프트 패턴은 이렇다.

AI에게 200줄 명세를 주고 “전부 빌드해”라고 말하지 마라. 단계마다 검증이 딸린 분명한 단계를 줘라.

1단계: 데이터 모델을 만든다. 검증: 이 쿼리 5개가 올바른 데이터를 돌려준다.
2단계: API를 만든다. 검증: 이 curl 명령 3개가 기대한 JSON을 돌려준다.
3단계: UI를 만든다. 검증: 이 시각 테스트들이 통과한다.

각 단계에는 AI가 스스로 확인할 수 있는 완료의 정의가 있다. AI는 통과한 단계마다 커밋하고 이어 간다. 무언가 깨질 때 폭발 반경은 빌드 전체가 아니라 한 단계다.

5단계 첫 진짜 일주일 (일주일, 그다음은 계속)

매일 써라. 테스트가 아니라 사용이다. 세션마다 적어라.

• 들인 시간
• 한 행동
• 데이터 품질 (내가 본 것을 믿었나)
• 하고 싶었지만 할 수 없었던 것

일주일이면 안다. 매일 쓰는 것 (남기고 다듬는다), 한 번 쓴 것 (남기되 다듬지 않는다), 끝내 건드리지 않은 것 (쳐낸다), 그리고 빠진 것 (다음 스프린트)을.

메타 규칙

이것들을 적어 두는 까닭은 내가 하나도 빠짐없이 어기고 대가를 치렀기 때문이다.

1. 명세하기 전에 프로토타입을 만들어라. 2시간짜리 프로토타입이 이틀짜리 명세보다 더 많이 가르친다. 명세는 내가 상상하는 것을 담는다. 프로토타입은 내가 필요로 하는 것을 드러낸다.

2. 표시보다 데이터가 먼저다. 데이터가 틀리면 UI는 의미가 없다. 그것을 표시하는 인터페이스보다, 믿을 만한 데이터를 만들어 내는 파이프라인을 먼저 빌드하라.

3. 유지보수보다 부트스트랩이 먼저다. 유지할 양질의 데이터를 갖기도 전에 데이터 품질을 유지하는 시스템을 빌드하지 마라. 처음 데이터를 손으로든 자동 딥 리서치로든 제대로 갖춘 다음, 매일의 손질을 자동화하라.

4. 매일 쓰기까지 가는 가장 짧은 길을 택하라. 프로덕트를 쓰지 않는 하루하루는 어둠 속에서 설계하는 하루다.

5. 상상이 아니라 경험에서 기능을 쳐내라. 무엇이 불필요한지는 생각만으로는 알 수 없다. 일주일 동안 프로덕트를 쓰면서 끝내 건드리지 않은 것을 알아채야 안다.

6. 문서가 아니라 아키텍처를 리뷰하라. 치명적 결함은 UI 명세가 아니라 데이터 모델과 일일 루프에 산다.

7. 내가 틀린 곳을 드러내라. 이는 프로덕트에도 과정에도 해당한다. 내 빌드에서 가장 값진 순간은 리뷰어 셋이 저마다 똑같은 아키텍처 결함을 짚어냈을 때였다. 나는 며칠째 틀린 설계를 붙들고 반복하고 있었다. 바깥의 눈은 그것을 몇 분 만에 찾아냈다. 준비되기 전에 리뷰를 구하라.

타임라인

0일째 (저녁):     Q1/Q2/Q3에 답한다. 막히면 하룻밤 묵힌다.
1일째 (오후):     한자리 프로토타입을 빌드한다. 한 페이지. 진짜에 가까운 데이터.
2~4일째 (아침):   매일 쓴다. 하루 15분. 관찰 세 개를 적는다.
5일째 (오후):     한 쪽짜리 아키텍처 문서. 데이터 모델 + 루프 + 순서.
5일째 (저녁):     리뷰어 한 명, 20분. "무엇이 깨질까?"
6~8일째:          데이터 파이프라인을 빌드한다. 진짜 데이터. 검증한다.
9~12일째:         일일 루프 UI를 빌드한다. 빌드하면서 매일 아침 쓴다.
13~15일째:        쓰는 것을 다듬는다. 안 쓰는 것을 쳐낸다.

보름이다. 빌드 단계에 Claude Code 같은 AI 도구를 쓴다고 가정한다. 그것들이 없다면 615일째를 세 배로 늘려라. 04단계 타임라인은 바뀌지 않는다. 그쪽은 코딩이 아니라 생각하고 쓰는 일이기 때문이다.

매 단계마다 내가 무엇을 빌드하는지 아는 까닭은, 그동안 줄곧 그것을 써 왔기 때문이다. 놀랄 일도 없고, 재작성도 없고, 끝내 건드리지 않을 기능에 관한 명세 문서도 없다.

다음번에는 다르게 할 것

내 도구는 지금 이 순간 빌드되고 있다. 아마 돌아갈 것이다. 명세는 적대적 리뷰를 견뎌 냈고, 아키텍처는 탄탄하며, 이 글을 쓰는 지금 코드는 두 개의 병렬 터미널에서 실행되고 있다. 그러나 나는 하루 오후면 프로토타입을 만들 수 있었을 프로덕트의 명세를 쓰는 데 이틀을 보냈고, 세 번의 리뷰보다 세 번의 아침 사용에서 더 많이 배웠다.

다음 프로젝트에서 나는 단일 HTML 파일 하나와 커피 한 잔으로 시작한다.