[한영자막] 스펙 짜는 데 시간 쓰지 마세요, 프로토타입이 답입니다

한 줄 핵심

AI로 코드를 만들 때는 완전한 스펙을 먼저 쓰기보다, 질문의 해상도를 높이기 위해 빠른 프로토타입을 먼저 돌려보는 편이 더 정확하고 저렴하게 원하는 결과에 도달한다.

시간별 요약

1. 0:00
   AI에게 코드를 시킬 때 세세한 스펙을 먼저 완성하려는 습관보다, 필요한 부분은 직접 코드로 확인하며 프로토타입을 만드는 방식이 더 효과적이다. Agile 시대부터 있던 프로토타이핑과 spike의 가치를 다시 살려야 한다.
2. 1:02
   프로토타입은 질문에 답하기 위한 버려도 되는 코드이며, 코드 생산 비용이 크게 내려간 지금은 가장 싸고 강력한 검증 수단이 됐다. 어떤 질문은 낮은 충실도의 대화로 충분하지만, 동작 방식이나 화면 형태처럼 감으로는 답하기 어려운 문제는 높은 충실도의 시각적·실행 가능한 산출물이 필요하다.
3. 3:01
   Wayfinder에서는 작업을 여러 계획 세션으로 나누고, 기본은 grilling으로 범위를 잡되 핵심이 '어떻게 보여야 하는가' 또는 '어떻게 동작해야 하는가'일 때 prototype 티켓을 사용한다. 즉, 논의로 끝낼지 프로토타입을 만들지 판단하는 기준이 명확해져야 한다.
4. 4:01
   TLDraw 기반 다이어그램 앱의 검색 UI를 예로 들면, A·B·C 같은 여러 프로토타입을 실제 화면에서 비교하면서 레이아웃, 필터 방식, 검색 결과 표시를 구체적으로 다듬을 수 있다. 이런 반복 과정은 단순한 문서보다 훨씬 많은 설계 결정을 코드에 축적한다.
5. 8:01
   프로토타입이 완성되면 다음 단계는 이를 기준으로 구현 코드에 옮기고, 기존 프로토타입 코드는 정리하는 일이다. 이 방식은 프런트엔드뿐 아니라 상태 모델이나 복잡한 로직처럼 종이에선 판단하기 어려운 백엔드 문제에도 유효하다.

실무 인사이트

• 스펙을 길게 쓰기 전에 1~2개의 핵심 질문을 정하고, 그 질문이 시각·행동으로 확인돼야 한다면 바로 프로토타입으로 넘어가라.
• 프로토타입은 최종 결과물이 아니라 의사결정 장치이므로, 버리기 쉬운 브랜치나 별도 산출물에 두고 빠르게 피드백을 반복하는 편이 효율적이다.
• UI뿐 아니라 상태 전이, 로직 분기, 예외 케이스처럼 말로 설명하기 어려운 부분도 작은 인터랙티브 프로토타입으로 검증하면 구현 실패를 크게 줄일 수 있다.