메타데이터
- 채널명: Tech Bridge
- 영상 제목: [한영자막] 스펙 짜는 데 시간 쓰지 마세요, 프로토타입이 답입니다
- URL: https://www.youtube.com/watch?v=MZImoK3lVH8
- 영상 발행일: 2026-07-25
- 영상 길이: 약 10분 25초 (625초)
- 처리일: 2026-07-26
- Video ID: MZImoK3lVH8
Layer 1 — 한 줄 요약
AI 코딩 작업에서 사람들은 "완벽한 스펙(spec)"을 먼저 만들려 하지만, 실제로 필요한 건 프로토타입이다 — AI 시대엔 코드 생산 비용이 극도로 낮아졌기 때문에, 논의를 저충실도(discussion)로 끝내지 말고 고충실도(prototype)로 끌어올려야 좋은 결과가 나온다.
Layer 2 — 핵심 내용 요약
문제 제기: 사람들이 AI와 일할 때 저지르는 실수
화자는 AI로 코드를 만들 때 사람들이 반복적으로 저지르는 실수에 대해 오랫동안 문제 제기를 해왔다고 말한다. 많은 사람들이 "AI를 위한 스펙을 만들어야 한다", "플랜 모드(Plan mode)", "스펙 기반 개발(spec-driven development)"에 집착하며, 매우 상세한 스펙을 미리 짜서 AI의 출력이 그 스펙과 정확히 일치하게 만들려 한다. 그런데 이 과정에서 사람들이 잊는 것이 있다 — 그냥 코드를 짜도 된다는 사실이다. 애자일(Agile) 시절부터 존재해온 프로토타이핑과 스파이크(spike)라는 개념이 있음에도, 애자일이 여전히 대중적이고 영향력이 있는데도 정작 사람들은 더 이상 프로토타이핑을 하지 않는다.
프로토타입 스킬 소개
화자는 자신의 "스킬 저장소(skills repo)"에 프로토타입 스킬을 추가해 이 흐름을 바꾸려 한다고 설명한다.
- 프로토타입 정의: 질문에 답하기 위한, 버리는 것을 전제로 한(throwaway) 코드
- "코드는 싸다(code is cheap)"는 말은 부분적으로만 맞다 — 정확히는 코드를 생산하는 비용이 극도로 낮아진 것. 그래서 프로토타입/스파이크를 만드는 일이 그 어느 때보다 저렴하고 효과적인 도구가 되었다.
핵심 개념: 충실도(Fidelity) — 고충실도 vs 저충실도
무언가를 설계할 때 머릿속에 해결되어야 할 질문들이 있다.
- 저충실도로 충분한 질문: 기본적인 구조(예: "모달이 열리면 취소 버튼과 확인 버튼이 있어야 한다" 같은 단순한 것) → 그냥 대화(discussion)로 해결 가능
- 고충실도가 필요한 질문: 특정 조건에서 데이터를 어떻게 보여줄지, 특정 상황에서 어떻게 동작해야 하는지 등 — 스펙만으로는 정확히 답하기 어렵고, **반쯤 동작하는 코드로 아이디어를 실제 테스트(road test)**해봐야 답이 나오는 질문들. 이런 질문은 오직 프로토타이핑으로만 답할 수 있다.
프로토타입 제작 비용이 그 어느 때보다 낮아졌기 때문에, 화자는 더 많은 논의를 고충실도 수준에서 하고 싶어 한다. 기본적인 것들은 그냥 논의로 끝내지만, "아, 이건 실제로 작동하는 걸 봐야겠다"는 생각이 드는 순간 바로 프로토타입을 요청한다.
Wayfinder 스킬과의 연계
프로토타이핑은 화자의 새 스킬인 Wayfinder의 일부다 (Wayfinder는 별도 영상에서 다룰 예정). Wayfinder는 큰 작업 덩어리를 여러 개의 플래닝 세션으로 쪼개고, 각 세션은 자신만의 티켓(ticket)을 갖는다. 티켓 타입에는:
- Grilling 타입 (기본값): 에이전트와 채팅하며 기본 스코프를 정하는 것 (Grilling 스킬 사용)
- Prototype 타입: 논의의 충실도를 높여야 할 때 — 대충 만든 구체적 산출물을 만들어 반응해보는 것 (UI 로직 코드를 대략 구현), 프로토타입을 에셋으로 연결
언제 프로토타입을 써야 하는가에 대한 명확한 기준: "어떻게 보여야 하는가(how should it look)" 또는 "어떻게 동작해야 하는가(how should it behave)"가 핵심 질문일 때. (Wayfinder를 쓰든 안 쓰든 이 기준은 그대로 적용된다.)
실제 데모 — TLDraw 기반 다이어그램 앱 검색바 만들기
화자는 TLDraw로 만든 자신의 다이어그램 앱에 옛 다이어그램을 검색하는 기능을 추가하는 예시를 시연한다. 데이터 모델(다이어그램 + 시간에 따른 스냅샷)이 복잡해서 어떻게 보이고 동작해야 할지 확신이 없었다.
- Prototype 실행 → 하단에 피커(picker)가 생성되고, 옵션 A/B/C 세 가지 서로 다른 UI/UX 설계안이 만들어짐
- A안: 검색창 위치가 좋았지만(위쪽), 다이어그램 이름으로 그룹핑하는 방식이 마음에 안 듦
- B안: 왼쪽에 필터용 그룹핑이 있어 괜찮았지만, 다른 검색어를 입력하면 필터가 리셋되는 문제
- C안: 필터 없이 전부 한 줄로 나열되는 방식이 마음에 들었지만, 상단 "search diagrams" UI가 별로였고, "current" 항목이 스냅샷과 함께 이상하게 기술적으로 보임
- 약 100,000 토큰이 소요됨 — 이 시점에서 화자는 **컴팩트(compact)**를 선택. 프로토타입과 관련된 모든 설계 결정 정보는 유지하면서 피드백만 추가로 주기 위함 (같은 코드베이스 위치에서 대화를 이어감)
- 피드백 반영: "A의 검색창 + C의 레이아웃이 좋다"고 구술로 피드백 → 이 피드백들이 프로토타입에 반영되어 하나의 풍부한 자산(rich asset)으로 인코딩됨. 프로토타입은 보통 버리는 브랜치(throwaway branch)에 저장
- D안 생성 → A의 검색창 + 요청한 모든 사항이 반영됨. 중복되던 항목이 하나로 정리되고, 클릭 시 실제로 동작하는 것까지 확인
- 화자는 이 프로토타입이 완성되었다고 판단하고, 이후 이를 AFK 에이전트에게 넘겨 전체 통합, 기존 프로토타입 코드 삭제, 원래 스펙과의 정합성 확인을 맡길 것이라고 설명
중요한 디테일: 이 프로토타입은 버리는 라우트(throwaway route)가 아니라 실제 라이브 페이지에 통합되어 만들어짐 — 이렇게 하면 코드가 실제로 어떻게 동작할지에 대해 훨씬 정직한(honest) 표현이 되고 유연성도 커짐.
비용 트레이드오프
충실도가 높을수록 토큰 비용이 늘어난다. 논의만으로 해결하면 저충실도이므로 답이 덜 유용하지만 토큰은 적게 든다. 반대로 고충실도(프로토타입)로 갈수록 비용은 늘지만 답의 질이 훨씬 좋아진다.
UI를 넘어선 적용 — 백엔드/로직 프로토타입
화자는 이것이 UI/프론트엔드 전용이 아니라고 강조한다. 프론트엔드가 프로토타입의 덕을 크게 보는 건 맞지만("어떻게 보여야 하는가"는 논의 단계에서 답하기 어려운 질문이기 때문), 백엔드 작업처럼 복잡한 작업에서도 "이 로직/이 상태 모델이 맞는 느낌인가?" 같은 질문이 계속 나온다. 복잡하거나 실제 환경에서 동작해야 하는 것을 만들 때는 반드시 이런 질문에 부딪히게 되고, 프로토타입을 만드는 것이 가장 좋은 해결책이 된다.
예시로 화자는 "종이 위에서는 추론하기 어려운 케이스들을 상태 머신에 밀어넣는 작은 인터랙티브 터미널 앱을 만들어라"는 지시를 보여준다 — 즉, 순수 로직 프로토타입(UI가 필요 없는 프로토타입). 이 기능에 대해 시청자들로부터 좋은 피드백을 많이 받았다고 언급. 로직 프로토타입 브랜치와 UI 프로토타입 브랜치는 각각 별도의 레퍼런스 문서를 가지고 있어 각 방식에 맞게 정확히 작업하는 법을 안내한다.
결론
화자는 "논의를 더 높은 충실도에서 하라"고 당부한다. 에이전트가 캔버스/디자인 툴을 다루는 능력이 좋아질수록 와이어프레임도 다시 각광받을 것으로 예상한다. 핵심 포인트: 논의/스펙에서 곧바로 프로덕션 코드로 가는 도약은 매우 크다. 반면 이미 동작하는 프로토타입이 있다면, 그것을 프로덕션으로 전환하는 일은 훨씬 간단하다.
Layer 3 — 핵심 인용구
"A prototype is throwaway code that answers a question." (프로토타입은 질문에 답하기 위한, 버리는 것을 전제로 한 코드다.)
"Producing prototypes, producing quick kind of throwaway spikes has never been cheaper and never been a more effective tool." (프로토타입, 즉 빠르게 버리는 스파이크를 만드는 일이 그 어느 때보다 저렴하고 효과적인 도구가 된 적이 없다.)
"How should it look or how should it behave is the key question [for using the prototype skill]." (어떻게 보여야 하는지, 어떻게 동작해야 하는지가 핵심 질문일 때 프로토타입 스킬을 써야 한다.)
"So many times I see people saying, 'Well, the thing didn't build what I wanted. I created this big beautiful spec, and it just did something totally weird.' You probably just weren't having discussions at a high enough fidelity, and you probably should have been prototyping." (사람들이 "완벽한 스펙을 만들었는데도 AI가 완전히 이상한 걸 만들었다"고 말하는 걸 자주 본다. 아마 충분히 높은 충실도로 논의하지 않았고, 프로토타이핑을 했어야 했을 것이다.)
"The leap from discussion and spec to production-ready code is really big. Whereas, if you have a working prototype, turning that into production is pretty simple." (논의와 스펙에서 프로덕션 수준 코드로의 도약은 매우 크다. 반면 동작하는 프로토타입이 있다면, 이를 프로덕션으로 전환하는 것은 꽤 간단하다.)
Layer 4 — 시사점 및 적용 방안
- 스펙 만능주의에 대한 반론: Plan mode·스펙 기반 개발(spec-driven development)에 과도하게 의존하는 워크플로우는 AI 코딩 시대에 재고할 필요가 있다. 스펙이 아무리 상세해도 "보여야 할 모습/동작해야 할 방식"에 대한 질문은 텍스트만으로 해결되지 않는다.
- 충실도(fidelity) 개념을 논의 설계에 도입: 모든 설계 질문에 같은 강도로 접근하지 말고, 단순한 질문은 대화로, "어떻게 보이고 동작해야 하는가" 같은 질문은 실제 동작하는 프로토타입으로 해결하는 이분법적 전략이 효율적이다.
- 프로토타입을 라이브 코드에 직접 통합하는 방식의 이점: throwaway 브랜치라도 실제 라이브 라우트에 연결해 만들면, 실제 프로덕션 환경에서의 동작을 훨씬 정직하게 검증할 수 있고, 나중에 구현자가 실제로 복붙(copy-paste)할 수 있는 자산이 된다.
- 컴팩트(compact) 시점 판단: 프로토타입에 관한 설계 결정 컨텍스트는 보존하되, 세션이 길어지면(예: 10만 토큰) compact로 전환해 같은 코드베이스 맥락에서 대화를 이어가는 것이 실전 팁으로 유용하다.
- UI뿐 아니라 백엔드/상태 로직에도 프로토타입 적용 가능: "종이 위에서 추론하기 어려운 상태 머신 케이스"를 검증하는 순수 로직 프로토타입(터미널 앱 등)이라는 아이디어는, UI가 없는 백엔드 작업에도 프로토타이핑 철학을 확장할 수 있음을 보여준다.
- 팀/개인 워크플로우에 적용해볼 수 있는 실천 규칙: "어떻게 보여야 하나?" 혹은 "어떻게 동작해야 하나?"라는 질문이 나오면 즉시 논의를 멈추고 프로토타입을 만드는 것을 규칙화하면, AI가 완전히 엉뚱한 결과물을 내놓는 상황을 줄일 수 있다.