AI 프로덕트 만들기

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

2026-03-20

영어 원문에서 옮김 · 기계 초벌 번역, 검수 전

나는 AI 기반 투자 리서치 도구를 만들고 있다. 다중 섹터 공급망 분석, 자동화된 논제 관리, 적대적 스트레스 테스트, 있을 건 다 있다. 지난 이틀 동안 나와 내 AI 코딩 어시스턴트는 다음을 만들어 냈다.

• 명세 문서 11개(1,400줄이 넘는 Prisma 스키마, API 계약, 전파 알고리즘)
• 상호작용 UI 목업 5개
• 병렬 저장소 구축을 위한 자율 빌드 프롬프트 2개
• 버그 38개를 잡아낸 외부 리뷰 3라운드
• 리서치 시스템 재작성 4회

그리고 나는 아직 이 프로덕트를 한 번도 써 보지 않았다.

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

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

실수의 패턴

내가 한 일은 이렇다.

Vague idea
  → Design everything
    → Spec everything
      → Review the specs
        → Fix the specs
          → Build everything
            → Discover it doesn't work as imagined
              → Rewrite

아이디어에서 첫 실제 사용까지의 시간: 몇 주. 짓기 전에 배운 양: 거의 없음.

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

실제로 통하는 패턴

Vague idea
  → Build the core loop in one sitting (2-4 hours)
    → Use it yourself for 3 days
      → Write down what's missing from actual use
        → Build the missing pieces
          → Use it for a week
            → Now you know what the real product is
              → Spec and build that

아이디어에서 첫 실제 사용까지의 시간: 오후 한나절. 아키텍처를 확정하기 전에 배운 양: 중요한 것 전부.

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

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

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

내 도구의 경우: “내 투자 논제들에 대한 아침 브리핑을 읽고 무언가 조치가 필요한지 결정한다.”

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

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

Q3: 한 세션의 ‘완료’는 어떤 모습인가? 앱을 닫을 때 무엇을 해냈는가?

“오늘 내 논제 중 어느 것이 강해지고 약해졌는지 알고, 행동했거나 행동하지 않기로 결정했다.”

이 질문들에 분명히 답할 수 없다면 아이디어는 준비되지 않은 것이다. 계속 생각하라. 짓지 마라.

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

내일 아침 실제로 쓸 수 있는 것을 지어라. 데모가 아니다. 목업이 아니다. 진짜처럼 느껴질 만큼 진짜에 가까운 데이터로 원자적 행동을 수행하는 도구다.

규칙:

• 파일 하나 또는 페이지 하나. 아키텍처는 없다.
• 하드코딩된 데이터도 괜찮다. 직접 쓴 실제 예시 3-5개가 든 JSON 파일.
• 데이터베이스 없음. API 없음. 인증 없음.
• UI는 못생겨도 된다. 상호작용은 진짜여야 한다.
• 내일 열어서 처음부터 끝까지 그 일을 할 수 있어야 한다.

내 도구라면 이랬어야 했다. 손으로 쓴 투자 논제 5개, 그날 아침 찾은 실제 뉴스 헤드라인 3개, 각각을 “강화 / 약화 / 무관”으로 표시하는 버튼이 있는 HTML 페이지 하나. 결정은 localStorage에 저장. 총 빌드 시간: 2시간.

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

2단계: 3일 테스트(3일, 하루 15분)

프로토타입을 3일 동안 매일 써라. 실제로 써라. “보면서 쓰는 상상을 하는 것”이 아니다. 일어나서, 열고, 그 일을 하라.

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

1. 실제로 한 일(하려고 계획한 일이 아니라)
2. 무엇이 빠져 있어서 다른 도구로 손이 갔는가
3. 한 번도 건드리지 않은 것

3일 뒤 관찰 9개가 생긴다. 어떤 명세 문서보다 값지다. 이것들이 드러내는 것은,

• 진짜 워크플로(상상한 워크플로 대비)
• 진짜 데이터 요구 사항(이론적으로 완전한 모델 대비)
• 필수처럼 보였지만 아닌 기능들

프로토타입을 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로 1-2주, 없이는 4-6주)

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

이유는 이렇다. 잘못된 것을 3개월이 아니라 3일 만에 지을 수 있다면, 그것이 잘못된 것임을 더 빨리 알아야 한다. 프로토타입 먼저 접근은 느리고 신중하자는 것이 아니다. 빌드 속도에 맞출 만큼 빠르게 배우자는 것이다.

Claude Code로 짓는 빌드 순서는 이렇다.

일차 무엇을 왜 이 순서인가 1-3 데이터 파이프라인. 실제 출처에서 온 실제 데이터. 품질을 검증한다. 데이터가 나쁘면 다른 무엇도 중요하지 않다. 4-6 핵심 일일 루프 UI. 매일 아침 하는 그 일. 4일차부터는 프로덕트를 쓰고 있어야 한다. 7-9 보조 기능. 매일의 사용이 필요하다고 드러낸 것만. 일주일 동안 아쉽지 않았던 것은 전부 죽여라. 10-12 자동화. 예약 작업, 배경 리서치, 유지보수. 손으로 해 오던 것을 자동화한다. 13-15 다듬기와 테스트. 실제로 쓰는 것만. 잘라 낼 기능은 다듬지 마라.

핵심 원칙: 4일차부터 매일 아침 써라. 짓는 동시에 쓴다. 매일 아침이 그날 오후에 무엇을 지을지 드러낸다. 15일차가 되면 프로덕트는 상상이 아니라 10일 넘는 실제 사용으로 빚어져 있다.

Claude Code 없이라면 4-6주로 늘리되 원칙은 같다. 나머지가 다 빠져 있어도 핵심 루프가 돌아가는 즉시 써라.

통하는 빌드 프롬프트 패턴:

AI에게 200줄짜리 명세를 주고 “전부 지어라”라고 하지 마라. 단계마다 검증이 붙은 분명한 단계들을 줘라.

Step 1: Create the data model. Verify: these 5 queries return correct data.
Step 2: Create the API. Verify: these 3 curl commands return expected JSON.
Step 3: Create the UI. Verify: these visual tests pass.

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

5단계: 첫 실제 일주일(1주, 이후 계속)

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

• 쓴 시간
• 취한 행동
• 데이터 품질(본 것을 신뢰했는가?)
• 하고 싶었지만 할 수 없었던 것

일주일 뒤에 알게 된다. 매일 쓰는 것(유지, 다듬기), 한 번 쓴 것(유지, 다듬지 않기), 한 번도 건드리지 않은 것(제거), 빠진 것(다음 스프린트).

메타 규칙

이것들을 적어 두는 까닭은 내가 전부 어기고 대가를 치렀기 때문이다.

1. 명세보다 프로토타입 먼저. 2시간짜리 프로토타입이 2일짜리 명세보다 많이 가르친다. 명세는 상상한 것을 담는다. 프로토타입은 필요한 것을 드러낸다.

2. 데이터가 화면보다 먼저. 데이터가 틀리면 UI는 중요하지 않다. 표시하는 인터페이스보다 신뢰할 수 있는 데이터를 만드는 파이프라인을 먼저 지어라.

3. 유지보수보다 부트스트랩 먼저. 유지할 품질 데이터가 생기기 전에 데이터 품질을 유지하는 시스템을 짓지 마라. 손으로든 자동화된 심층 리서치로든 초기 데이터를 먼저 바로잡고, 그다음 매일의 관리를 자동화하라.

4. 매일 사용까지의 절대적 최단 경로를 택하라. 프로덕트를 쓰지 않는 하루하루가 어둠 속에서 설계하는 하루다.

5. 기능은 상상이 아니라 경험으로 죽여라. 생각만으로는 무엇이 불필요한지 알 수 없다. 프로덕트를 일주일 쓰고 한 번도 건드리지 않은 것을 알아차림으로써 안다.

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

7. 어디서 틀렸는지 보여 줘라. 프로덕트와 과정 모두에 적용된다. 내 빌드에서 가장 값진 순간은 리뷰어 셋이 독립적으로 같은 아키텍처 결함을 짚었을 때였다. 나는 며칠 동안 잘못된 설계를 반복하고 있었다. 바깥의 눈은 몇 분 만에 찾았다. 준비되기 전에 리뷰를 구하라.

타임라인

Day 0 (evening):     Answer Q1/Q2/Q3. If stuck, sleep on it.
Day 1 (afternoon):   Build one-sitting prototype. One page. Real-ish data.
Day 2-4 (morning):   Use it daily. 15 min/day. Write 3 observations.
Day 5 (afternoon):   One-page architecture doc. Data model + loop + order.
Day 5 (evening):     One reviewer, 20 minutes. "What will break?"
Day 6-8:             Build the data pipeline. Real data. Validate.
Day 9-12:            Build the daily loop UI. Use it each morning as you build.
Day 13-15:           Polish what you use. Cut what you don't.

15일. 빌드 단계에 Claude Code나 비슷한 AI 도구를 쓴다고 가정한다. 없다면 6-15일차를 세 배로 늘려라. 0-4단계의 타임라인은 바뀌지 않는다. 그것은 코딩이 아니라 생각하고 쓰는 일이다.

모든 단계에서 무엇을 짓고 있는지 안다. 내내 써 왔기 때문이다. 놀랄 일이 없다. 재작성이 없다. 결코 건드리지 않을 기능에 대한 명세 문서가 없다.

다음번에 다르게 할 것

내 도구는 지금 빌드되고 있다. 아마 작동할 것이다. 명세는 적대적 리뷰를 견뎠고, 아키텍처는 건전하며, 이 글을 쓰는 동안 코드는 병렬 터미널 두 개에서 실행되고 있다. 그러나 나는 오후 한나절에 프로토타입할 수 있었던 프로덕트의 명세를 쓰는 데 이틀을 보냈고, 리뷰 세 라운드보다 세 번의 아침 사용에서 더 많이 배웠다.

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