[한영자막] 프롬프트 작성은 그만두세요. 이제 명세(Spec)를 작성할 때입니다.

한 줄 핵심

프롬프트 중심 AI 코딩은 빠른 출발에는 유용하지만, 큰 프로젝트에서는 명세를 중심으로 콘스티튜션·스펙·플랜·태스크로 분해해 관리해야 재현성과 품질을 확보할 수 있다.

시간별 요약

1. 0:00
   프롬프트 중심 개발의 한계 prompt-first 방식은 빠르게 결과를 내지만, 대규모 프로젝트나 기업 환경에서는 프롬프트가 비공개적이고 일시적이며 리뷰하기 어려워 핵심 요구를 놓치기 쉽다. 따라서 주된 산출물을 프롬프트가 아니라 명세로 바꾸는 전환이 필요하다.
2. 2:00
   명세 기반 개발의 구조 명세 기반 개발은 콘스티튜션, 스펙, 플랜, 태스크로 역할을 분리한다. 콘스티튜션은 보안·테스트·팀 규칙 같은 불변 원칙을 담고, 스펙은 무엇을 만들지 정의하며, 플랜은 기술 선택과 배포 방식을 정하고, 태스크는 구현 가능한 단위로 쪼갠다.
3. 4:00
   GitHub와 SpecIt로 시작하기 SpecIt을 GitHub Copilot과 연동하면 저장소 안에 명세와 스크립트가 함께 남아 Git history의 일부가 된다. 이 과정은 마법이 아니라 markdown과 scripting으로 구성되어 있어 구조를 이해하면 팀이 쉽게 도입하고 재사용할 수 있다.
4. 8:01
   콘스티튜션과 스펙 작성 실습 실습에서는 Microsoft Build 세션 플래너용 MCP 서버를 예로 들어 grounded only, time aware, agent safe, HTTP safe, testable by design, privacy by default 같은 불변 원칙을 먼저 정의한다. 이어서 검색, 단건 조회, 현재 진행 세션 조회 같은 기능 요구를 스펙으로 적고, 구현 방식은 아직 적지 않은 채 무엇을 만들지에만 집중한다.
5. 14:01
   플랜, 태스크, 구현과 검증 플랜 단계에서는 TypeScript, Node.js, HTTP transport, 배포와 설정 같은 기술 결정을 적고, 태스크 단계에서는 이를 구현 순서대로 쪼갠다. 이후 implement 단계에서 코드와 테스트가 생성되며, MCP Inspector로 실제 동작을 확인해 명세가 실행 가능한 코드로 이어지는 흐름을 증명한다.
6. 20:00
   실무 적용을 위한 제안 처음부터 전체 워크플로를 바꾸기보다 실제 기능 하나를 골라 먼저 무엇과 왜를 스펙으로 쓰고, 팀의 비협상 규칙을 콘스티튜션에 넣고, 생성된 산출물을 반드시 리뷰한 뒤 적용하는 방식이 가장 현실적이다. 이렇게 하면 다음 기능부터는 명세가 재사용 자산이 되어 AI 개발의 품질과 일관성이 높아진다.

실무 인사이트

• AI 코딩의 품질은 프롬프트 길이보다 요구사항을 얼마나 명세로 고정하느냐에 크게 좌우되므로, 기능 개발 전 스펙 문서를 먼저 작성하는 습관이 효과적이다.
• 보안·테스트·배포 같은 팀 규칙을 콘스티튜션으로 분리하면 프로젝트별 판단이 흔들리지 않고, 여러 기능과 팀에 걸쳐 일관된 기준을 유지할 수 있다.
• SpecIt처럼 명세를 저장소에 남기는 방식은 AI 결과물을 일회성 대화가 아니라 리뷰 가능한 개발 산출물로 바꿔 주어 협업과 재현성에 유리하다.