프롬프트를 넘어 명세를 먼저 쓰는 스펙 주도 개발

URL: https://www.youtube.com/watch?v=F_smvU3oqbU
날짜: 2026-08-29
채널: Tech Bridge
원문 제목: [한영자막] 프롬프트 작성은 그만두세요. 이제 명세(Spec)를 작성할 때입니다.
발표자: Luna Diva, Microsoft MVP·클라우드 네이티브 아키텍트
재생 시간: 약 22분

---

📌 핵심 질문 / 프롬프트를 주산출물로 삼는 개발을 어떻게 바꿀 것인가

==AI에게 일회성 프롬프트를 던져 코드를 얻는 방식에서 벗어나, 헌법(Constitution)·명세(Specification)·계획(Plan)·태스크(Task)를 저장소에 남기는 스펙 주도 개발로 전환해야 한다.==

• 프롬프트는 대체로 비공개·일시적이며 검토와 재현이 어렵다.
• 명세는 무엇을 왜 만들지 고정하고, 계획은 어떻게 만들지 기술적으로 구체화한다.
• 헌법과 모든 중간 문서를 팀이 검토하고 합의해야 AI가 원하는 품질의 결과를 만들 수 있다.

대규모 프로젝트와 엔터프라이즈 팀에서 AI 코딩의 품질을 안정화하려면 코드 생성 능력보다 먼저 공유 가능한 설계 산출물을 확보해야 한다. GitHub Spec Kit과 GitHub Copilot을 사용하면 마크다운 기반 지침과 스크립트로 이 흐름을 자동화하면서도, 사람이 각 문서를 승인하고 수정하는 통제권을 유지할 수 있다.

1. 프롬프트 우선 개발에서 명세 우선 개발로

빠른 프롬프트 중심 코딩은 AI 소프트웨어 개발을 시작하게 해준 유용한 출발점이지만, 팀 규모와 프로젝트 복잡도가 커질수록 공통 기준이 약해진다.

1.1. 프롬프트 우선 방식의 장점과 한계

1. 초기 속도와 접근성

   1. 빠른 출발: 짧은 지시를 입력하면 모델이 곧바로 코드를 만들어 개발을 시작할 수 있다.
   2. 초기 생산성: 결과가 빠르고 인상적이어서 AI 기반 개발을 실제 업무에 도입하는 문턱을 낮춘다.

2. 팀 개발의 취약한 기반

   1. 비공개성: 개인이 작성한 프롬프트는 대개 팀의 저장소와 공유되지 않는다.
   2. 일시성: 프롬프트는 한 번의 대화 맥락에 묶여 다음 기능이나 다음 개발자에게 재사용하기 어렵다.
   3. 검토 어려움: 어떤 요구와 가정이 코드 생성에 영향을 줬는지 리뷰어가 추적하기 어렵다.
   4. 결과의 불안정성: 코드는 대체로 빌드되더라도 기능의 핵심 의도와 완전히 어긋나는 결과가 나올 수 있다.

3. 생산된 코드 뒤의 비용

   1. 예측하지 못한 결과: 지시를 쓰고 모델이 코드를 만든 뒤, 개발자는 결과가 의도에 맞는지 확인해야 한다.
   2. 원인 추적 시간: 결과가 틀리면 오후 내내 모델이 왜 그런 코드를 만들었는지 역추적하게 된다.
   3. 핵심 산출물의 전환: 프롬프트를 주산출물로 취급하지 말고, 팀이 읽고 검토할 수 있는 명세를 주산출물로 삼아야 한다.

1.2. 스펙 주도 개발의 정신 모델

1. 헌법에서 시작하는 흐름

   1. 불변의 뿌리: 헌법은 특정 프로젝트보다 크고 때로는 특정 팀보다도 큰 원칙을 담는다.
   2. AI의 준수 기준: 코딩 AI 어시스턴트가 반드시 지켜야 할 보안·품질·기업·팀 규칙을 명시한다.

2. 무엇과 어떻게의 분리

   1. 명세(Specification): 애플리케이션이 무엇을 해야 하는지, 어떤 기능과 기능 요구사항을 가져야 하는지 적는다.
   2. 계획(Plan): 배포 대상, 기술 스택, 프레임워크, 버전 등 어떻게 만들지 결정하는 기술 세부사항을 적는다.

3. 작업 분해와 구현

   1. 태스크(Task): 명세와 계획을 논리적 순서의 관리 가능한 덩어리로 나눈다.
   2. 구현(Implement): AI가 태스크를 실제 코드와 테스트로 변환한다.
   3. 검토(Review): 헌법·명세·계획을 포함해 AI가 생성하는 모든 문서를 사람이 읽고 팀이 동의해야 한다.

2. 네 단계 코어 구조와 검토 원칙

헌법부터 코드까지의 네 단계는 모든 상황을 포괄하는 완성 목록이 아니라, 스펙 주도 개발 프레임워크를 시작하기 위한 핵심 골격이다.

2.1. 헌법(Constitution): 프로젝트보다 오래가는 규칙

1. 헌법의 범위

   1. 설계부터 테스트 가능하게: 테스트 가능성을 구현 후 검증 항목이 아니라 설계 원칙으로 둔다.
   2. 보안 표준: MCP와 공개 엔드포인트를 포함한 보안 요구를 처음부터 지킨다.
   3. 엔터프라이즈 가이드라인: 조직 차원의 규정과 표준을 프로젝트에 적용한다.
   4. 팀별 규칙: 해당 팀이 반드시 지키기로 합의한 개발 규칙을 포함한다.

2. 헌법의 역할

   1. 최소 요구의 고정: AI가 놓쳐서는 안 되는 필수 조건을 반복적인 프롬프트마다 다시 설명하지 않아도 된다.
   2. 범위 확장성: 프로젝트가 바뀌거나 기능이 늘어도 공통 원칙은 계속 재사용된다.
   3. 조직 지식의 축적: 학습한 내용과 엔터프라이즈·다른 팀에서 얻은 규칙을 살아 있는 문서에 계속 반영한다.

2.2. 명세(Specification): 무엇을 만들지 고정

1. 기능 중심의 문서

   1. 기능 목록: 만들고 싶은 기능을 명시한다.
   2. 기능 요구사항: 기능이 충족해야 할 동작과 사용자 관점의 결과를 적는다.
   3. 기술 배제: 구현 방법, 특정 프레임워크, 배포 방식 같은 기술 세부사항은 명세에 넣지 않는다.

2. 팀 합의의 기준

   1. 공통 이해: 명세를 읽은 팀원 모두가 무엇을 만들고 왜 만드는지 같은 방식으로 이해해야 한다.
   2. 변경 추적: 명세가 저장소에 들어가면 요구의 변경도 Git 기록에서 추적할 수 있다.
   3. 반복 가능한 출발점: 새 기능을 만들 때 기존 헌법을 기반으로 새 기능 명세를 추가하고 같은 흐름을 반복한다.

2.3. 계획(Plan): 어떻게 만들지 기술적으로 결정

1. 계획에 들어갈 항목

   1. 배포 대상: 애플리케이션을 어디에 배포할지 정한다.
   2. 스택과 프레임워크: TypeScript, Node.js, MCP 서버 등 사용할 기술 선택을 적는다.
   3. 전송과 설정: HTTP 전송 지원, 애플리케이션 구성 방식, 운영 설정을 구체화한다.
   4. 버전: 사용할 라이브러리와 도구의 버전을 명시한다.

2. 자동으로 채워지는 기술 정보의 주의점

   1. 질문 또는 추론: 지정하지 않은 값은 AI가 사용자에게 물어보거나 자체적으로 채울 수 있다.
   2. 현재 버전과 최신 버전의 차이: 자동으로 선택된 버전이 현재 기준일 수는 있지만 최신 버전이라는 보장은 없다.
   3. 명시적 버전 지정: 최신 프레임워크를 원하면 계획 프롬프트에 정확한 버전을 직접 적어야 한다.

2.4. 태스크(Task)와 구현(Implement): 계획을 실행 가능한 단위로

1. 태스크 분해

   1. 논리적 순서: 사용자 스토리와 기술 구현을 개발 순서에 맞게 배치한다.
   2. 관리 가능한 크기: AI 어시스턴트가 한 번에 이해하고 통합할 수 있는 크기로 나눈다.
   3. 기초 작업 우선: 보일러플레이트, Node 설정, package.json, Dockerfile, 선행 조건을 앞쪽에 둔다.

2. 구현 단계

   1. 코드 변환: 태스크를 소스 코드로 바꾼다.
   2. 테스트 생성: 테스트 가능한 설계 원칙에 맞춰 테스트도 함께 만든다.
   3. 검증 루프: 테스트와 컴파일 검증이 작동하는 코드를 만드는 데 도움을 준다.

3. 중간 단계의 활용

   1. 분석(Analyze): 명세와 계획의 충돌·누락을 구현 전에 확인한다.
   2. 명확화(Clarify): 애매한 요구를 질문으로 드러내고 결정한다.
   3. 선택 가능한 지름길: 태스크를 만든 뒤 바로 구현할 수도 있지만, 분석과 명확화를 먼저 실행하는 편이 안전하다.

3. 데모 대상: Microsoft Build 세션 플래너 MCP 서버

명세 흐름을 보여주기 위해 Microsoft Build 세션 플래너에 AI 에이전트가 접근할 수 있는 MCP(Model Context Protocol) 서버를 만든다.

3.1. 세션 플래너의 문제 정의

1. 행사와 일정의 관계

   1. 풍부한 세션 데이터: Microsoft Build에는 온라인으로 다시 볼 수 있는 세션이 많이 있다.
   2. 일정표 역할: 세션 플래너는 행사 중 무엇을 보고 무엇을 할지 결정하는 개인 일정표와 같다.

2. MCP 서버의 필요성

   1. 기존 CLI: 세션 플래너에는 사용할 수 있는 훌륭한 CLI가 있었다.
   2. 부족한 연결 계층: CLI만으로는 AI 에이전트가 데이터를 활용할 MCP 서버가 없었다.
   3. 데모 목표: 기존 세션 데이터를 근거로 삼아 AI 에이전트가 검색하고 현재 일정을 확인할 수 있는 MCP 서버를 만든다.

3.2. 초기 저장소 상태

1. 비어 있는 브랜치

   1. 최소 프로젝트: 브랜치에는 MCP 서버와 관련된 특별한 구현이 아직 없다.
   2. .github 폴더: GitHub Copilot 지침만 들어 있다.
   3. .vscode 폴더: 개인 VS Code 설정이 들어 있지만 MCP 서버와는 관계가 없다.

2. 데모 편의 파일

   1. demo 폴더: 타이핑 장면을 길게 보여주지 않기 위해 사용할 프롬프트를 미리 준비해 둔 폴더다.
   2. Git ignore와 마크다운: 기본적인 무시 규칙과 마크다운 파일만 더 있다.
   3. 출발점의 의미: 기능 코드 없이 명세 도구를 설치하고 산출물이 늘어나는 과정을 확인할 수 있는 상태다.

4. GitHub Spec Kit 초기화

Spec Kit은 CLI와 저장소에 추가되는 지침·스크립트로 Copilot이 스펙 주도 개발 단계를 따르게 만든다.

4.1. specify init 실행

1. CLI와 통합 선택

   1. Specify CLI: 먼저 Spec Kit의 Specify CLI를 설치한다.
   2. 초기화 명령: 터미널에서 specify init을 실행해 현재 프로젝트에 Spec Kit을 초기화한다.
   3. AI 하네스 지정: 사용하는 AI 도구에 맞춰 통합 유형을 선택한다.
   4. Copilot 통합: GitHub Copilot을 선택하면 해당 통합에 맞는 사용자 지정 지침이 연결된다.

2. 터미널의 확인 절차

   1. 비어 있지 않은 저장소 경고: 이미 파일이 있어 “그렇게 비어 있지는 않은데 계속하시겠습니까?”라는 확인이 나온다.
   2. 스크립트 셸 선택: Bash, PowerShell, Python 중 사용할 방식을 고른다.
   3. Windows 환경: Windows에서 시연하므로 PowerShell을 선택한다.

4.2. 초기화 결과와 구조 이해

1. 자동 설정

   1. 선행 조건 확인: 필요한 구성 요소가 설치되어 있는지 검사한다.
   2. Copilot 연결: GitHub Copilot이 Spec Kit 프레임워크를 사용할 수 있도록 지침을 연결한다.
   3. 인증 안내: 자격 증명과 OAuth 토큰에 대한 유용한 힌트도 제공한다.
   4. 추가 명령: 헌법·명세·계획·태스크·구현 등에 사용할 명령들이 프로젝트에 들어온다.

2. .specify 폴더의 의미

   1. 문서 탐색 권장: 자동화가 어떻게 작동하는지 이해하려면 새로 생성된 .specify 폴더를 직접 살펴봐야 한다.
   2. 마크다운과 스크립트: 핵심은 마크다운 지침과 스크립트이며, 내부에 신비한 실행 로직이 숨겨진 구조가 아니다.
   3. 강력함과 투명성: 기능은 강력하지만 구성 요소를 읽어보면 “마법”을 제거하고 도구의 동작을 이해할 수 있다.
   4. 문서 확인 경로: 모든 명령의 목록은 아니므로 더 많은 명령은 Spec Kit 문서에서 확인한다.

5. 헌법 단계: MCP 서버의 협상 불가능한 원칙

프로젝트 헌법은 모든 팀이 동일하게 사용해야 하는 고정 템플릿이 아니라, 세션 플래너 MCP 서버에 타당한 기준을 선택해 기록한 문서다.

5.1. 여섯 가지 원칙

1. 근거 있는 데이터(grounded)

   1. 원본 데이터 한정: AI가 제공된 Microsoft Build 세션 데이터에만 근거해 답하도록 한다.
   2. 환각 방지: 실제로 존재하지 않는 세션을 AI가 지어내지 못하게 한다.

2. 시간 인식(time-aware)

   1. 세션 일정의 시간성: 소프트웨어에서 시간은 어려운 개념이므로 세션 시작 시각과 현재 시각을 정확히 다뤄야 한다.
   2. 임박한 일정: “곧 시작하는 세션”을 잘못 계산하면 사용자의 일정 결정이 틀리므로 시간 조건을 중요하게 취급한다.

3. 에이전트 안전(agent-safe)

   1. 안전한 도구 설계: MCP 도구가 에이전트의 행동을 안전하게 제한하도록 만든다.
   2. 보안 고려: MCP 환경에서 권한과 보안을 제대로 유지하기 어렵다는 점을 설계 단계부터 반영한다.

4. HTTP 안전성(HTTP-safe)

   1. 공개 엔드포인트 대비: MCP 서버가 HTTP로 공개 엔드포인트에서 호출될 수 있음을 전제로 한다.
   2. 노출 가능한 설계: 외부에 노출해도 안전하도록 HTTP 계층의 안전 요구를 지킨다.

5. 설계부터 테스트 가능(testable by design)

   1. 내장된 검증성: 테스트를 나중에 덧붙이는 대신 설계 자체가 테스트 가능하게 만든다.
   2. 품질 기준: 구현 결과가 컴파일되고 실제로 작동하는지 자동 검증할 수 있게 한다.

6. 기본값으로 개인정보 보호(privacy by default)

   1. 공개 목록이 아니어도 적용: 세션 목록이 공개 데이터인 상황에서도 개인정보 보호 원칙을 기본값으로 둔다.
   2. 미래의 안전장치: 현재 기능에 꼭 필요하지 않은 원칙도 이후 데이터와 기능의 확장을 대비해 헌법에 넣는다.

5.2. /speckit.constitution 실행과 검토

1. 프롬프트 준비

   1. 사전 작성의 시간: 여섯 가지 원칙을 질문 형태로 정리하는 작업은 상당한 시간이 걸린다.
   2. AI의 보조: AI가 질문과 초안 준비를 도울 수 있지만 최종 원칙과 판단은 사람이 정한다.

2. 헌법 생성

   1. 슬래시 명령: Copilot에서 /speckit.constitution 명령을 실행하고 헌법 프롬프트를 붙여 넣는다.
   2. 처리 시간: GenAI가 원칙을 분석하고 지정 폴더의 헌법 문서에 통합하는 데 시간이 걸릴 수 있다.
   3. 시연의 절충: 실제 실행을 기다리는 대신 준비해 둔 브랜치로 이동해 생성 결과를 확인한다.
   4. 실험 권장: 미리 만든 브랜치를 보는 것은 다소 요령을 피우는 것처럼 느껴질 수 있지만, 실제 프로젝트에서 직접 실행해 보는 편이 더 유익하다.

3. 생성된 결과

   1. 헌법 마크다운: .specify/memory/constitution.md에 여섯 원칙이 스펙 주도 개발 노력의 기준으로 통합된다.
   2. 팀의 기준점: 이후 명세와 계획이 헌법의 근거 있는 데이터, 시간 인식, 안전성, HTTP 안전성, 테스트 가능성, 개인정보 보호를 따르게 된다.

6. 명세 단계: 세션 데이터에 대한 기능 요구사항

헌법이 “반드시 지켜야 하는 것”을 정했다면 명세 단계는 애플리케이션이 실제로 “무엇을 해야 하는지”를 기술과 분리해 정의한다.

6.1. AI 에이전트와 MCP 서버의 기능

1. 주요 목표

   1. 데이터 접근: AI 에이전트가 Microsoft Build 세션 데이터에 접근할 수 있는 MCP 서버를 만든다.
   2. 범위 고정: 명세는 서버가 제공할 사용자 기능을 다루고 구현 방법은 다루지 않는다.

2. 데이터 모델링

   1. JSON 원본: 불러올 JSON 데이터에 있는 원본 필드를 데이터 모델의 출발점으로 삼는다.
   2. 근거 보존: 세션 정보가 원본 데이터와 연결되어야 하므로 임의의 세션이나 필드를 만들어내지 않는다.

3. 노출할 MCP 도구

   1. 세션 검색: 조건에 맞는 Microsoft Build 세션을 검색한다.
   2. 세션 조회: 특정 세션의 상세 정보를 가져온다.
   3. 현재 진행 또는 임박 세션 확인: 현재 무엇이 진행 중인지, 다음에 어떤 세션이 시작되는지 시간 기준으로 확인한다.
   4. 기능과 기술의 분리: 검색·상세 조회·현재 세션이라는 사용자 기능만 명세에 넣고 서버 구현 세부사항은 계획 단계로 미룬다.

6.2. /speckit.specify 실행과 사용자 스토리

1. 명세 통합

   1. 슬래시 명령: Copilot에서 /speckit.specify를 실행하고 준비한 기능 명세 프롬프트를 붙여 넣는다.
   2. 헌법 참조: Spec Kit은 헌법의 필수 조건을 확인하면서 기능 요구사항을 통합한다.
   3. 모호성 처리: 불명확한 부분을 명세 안에서 강조하거나 사용자에게 질문한다.

2. 질문 방식

   1. 주관식 질문: 사용자가 자유롭게 답하는 열린 질문으로 요구를 명확히 할 수 있다.
   2. 객관식 질문: 선택지를 제시해 팀이 빠르게 정책을 결정할 수도 있다.
   3. 명세의 품질: 질문과 답변이 문서에 반영되어 요구사항의 빈틈을 줄인다.

3. 생성된 명세 폴더

   1. specs 폴더: 첫 기능 명세가 저장소의 specs 폴더에 생성된다.
   2. 사용자 스토리: 세션 검색, 세션 상세 정보 조회, 현재 진행 중인 세션 확인 등에 대한 사용자 스토리가 만들어진다.
   3. 다음 단계의 입력: 이 문서가 계획 단계에서 기술 결정을 만들기 위한 입력이 된다.

7. 계획·태스크·구현 단계

명세가 완성되면 기술적 선택을 계획으로 분리하고, 계획을 다시 AI가 처리할 수 있는 태스크로 나눈 다음 코드를 만든다.

7.1. /speckit.plan과 기술 설계

1. 계획 프롬프트

   1. 기술 선택: TypeScript와 Node.js를 사용하고 MCP 서버를 구축한다고 지정한다.
   2. HTTP 전송: MCP 서버가 HTTP transport를 지원하도록 요구한다.
   3. 운영 세부사항: 배포 위치, 구성 방법, 애플리케이션 설정을 계획에 넣는다.

2. 계획 생성

   1. 슬래시 명령: /speckit.plan을 실행해 헌법과 기능 요구사항을 함께 입력으로 사용한다.
   2. 기술 구현 세부사항: AI가 기능 명세를 만족하는 기술 구현 방안을 작성한다.
   3. 추가 마크다운: specs 폴더에 계획 단계에서 결정된 기술 세부사항을 담은 마크다운 파일들이 추가된다.

3. 계획의 산출물

   1. 상태 비저장 HTTP 서버: 세션 데이터 MCP 서버를 stateless HTTP server로 구성한다.
   2. 기술 맥락: 기술 담당자와 구현에 필요한 기술 맥락을 문서화한다.
   3. 버전 정보: 사용할 TypeScript 버전과 기타 의존성 버전을 기록한다.

7.2. /speckit.tasks와 관리 가능한 작업

1. 태스크 생성

   1. 입력 결합: 계획의 사용자 스토리와 기술 구현을 함께 가져온다.
   2. 헌법 준수: 태스크 분해도 헌법의 안전성·테스트 가능성 등 필수 원칙을 지킨다.
   3. 실행 단위: AI 어시스턴트가 한 번에 통합할 수 있는 작업 크기로 쪼갠다.

2. 생성된 작업의 순서

   1. 기초 단계: 보일러플레이트를 만들고 Node 설정을 준비한다.
   2. 패키지 요구사항: 애플리케이션에 필요한 의존성을 담은 package.json을 만든다.
   3. 컨테이너 준비: 이후 단계를 위해 Dockerfile을 만든다.
   4. 논리적 사용자 스토리 순서: 선행 조건과 기반 작업부터 시작해 기능 구현으로 넘어가도록 정렬한다.

3. 도구의 본질

   1. 마크다운으로 된 스크립트: 자동화는 특별한 마법이 아니라 마크다운 지침과 스크립트의 조합이다.
   2. 복잡성의 완화: 큰 기능을 작고 접근 가능한 작업으로 바꾸는 능력이 AI 어시스턴트와의 협업을 쉽게 만든다.

7.3. /speckit.implement와 테스트 가능한 코드

1. 구현 전 점검

   1. 중간 명령 권장: 태스크 생성 후 /speckit.analyze와 /speckit.clarify를 실행해 누락과 모호함을 확인하는 편이 좋다.
   2. 즉시 구현 선택: 필요하다면 중간 단계를 건너뛰고 /speckit.implement로 바로 진행할 수도 있다.

2. 코드 생성

   1. 태스크의 코드화: /speckit.implement은 계획과 태스크를 실제 소스 코드로 변환한다.
   2. 테스트 동반: “설계부터 테스트 가능”이라는 헌법 원칙에 따라 테스트도 함께 구성한다.
   3. 작동 검증: 테스트는 코드가 컴파일되고 실제로 동작하는지 확인하는 피드백이 된다.

3. 구현 결과

   1. 많은 파일: 구현 단계가 끝나면 소스 코드와 설정 파일이 저장소에 추가된다.
   2. 실행 가능한 서버: 생성된 코드를 실행해 MCP 서버가 실제로 시작되는지 확인한다.
   3. 시연의 기준: 데모에서 서버가 실행되는 것은 생성 결과가 기능적으로 이어졌다는 첫 번째 확인이다.

8. MCP 서버 검증과 실제 동작

코드 생성으로 끝내지 않고 MCP Inspector를 통해 서버 연결과 도구 목록을 직접 확인한다.

8.1. MCP Inspector 사용

1. 검사 도구 준비

   1. 도구 이름: 시연에는 MCP Inspector가 사용되며, 설명상 “Motor Cortex Protocol Inspector”라는 표현도 등장한다.
   2. Node 모듈: 로컬 컴퓨터에서 실행할 수 있는 Node 프로그램이다.
   3. 자동 설치: 설치되어 있지 않으면 실행 시 다운로드할 수 있고, 시연 환경에는 이미 설치되어 있다.

2. 연결 확인

   1. 서버와 검사기 연결: MCP 서버를 Inspector에 연결한다.
   2. 도구 목록 조회: 서버가 제공하는 도구를 나열한다.
   3. 요구사항 대조: 세션 검색, 세션 상세 조회, 현재 진행 중인 세션 확인 등 명세에 적은 기능이 목록에 나타나는지 확인한다.

8.2. 검색 도구 실행

1. 검색 필드 확인

   1. 풍부한 조건: 검색 도구를 실행하면 검색에 사용할 수 있는 필드들이 Inspector에 표시된다.
   2. 원본 데이터 활용: 필드는 세션 JSON 데이터 모델과 연결되어 있어 근거 있는 검색을 가능하게 한다.

2. 실제 응답

   1. 첫 결과: 검색 결과는 개막 기조연설(opening keynote)부터 시작한다.
   2. 시간 맥락: 시연 당시 개막 기조연설은 이미 한 달 전 행사였지만, 과거 세션도 정상적으로 조회된다는 점을 보여준다.
   3. 기능 검증: Inspector에서 도구가 응답하고 세션 데이터가 반환되면서 작동하는 MCP 서버가 만들어졌음을 확인한다.

9. 작은 기능 하나로 도입하는 실천법

스펙 주도 개발을 다음 날 전체 업무 흐름에 강제로 적용하기보다, 작지만 의미 있는 실제 기능 하나로 시작해야 한다.

9.1. 첫 기능에서 할 세 가지

1. 프롬프트 전에 명세 쓰기

   1. 순서 전환: 코드를 요구하는 프롬프트보다 기능 명세를 먼저 작성한다.
   2. 공유 가능한 기준: 저장소에 남는 명세로 팀이 같은 목표를 바라보게 한다.

2. 무엇과 왜를 먼저 기록하기

   1. What: 만들 기능과 사용자가 얻을 결과를 적는다.
   2. Why: 그 기능이 필요한 이유와 해결하려는 문제를 적는다.
   3. How의 지연: 프레임워크·배포·구현 방법은 계획 단계에서 결정한다.

3. 헌법에 규칙 두세 개부터 넣기

   1. 작은 시작: 처음부터 거대한 규정집을 만들지 않는다.
   2. 범위 조절: 협상 불가능한 팀 규칙을 두세 개, 필요하면 네다섯 개까지 선택한다.
   3. 원칙의 실효성: 실제 기능에 적용하고 결과를 확인하면서 팀에 맞는 규칙을 늘린다.

9.2. 살아 있는 헌법과 반복 학습

1. 시간에 따른 변화

   1. 학습 반영: 팀이 새로 배운 내용을 헌법에 추가한다.
   2. 조직 지식 반영: 엔터프라이즈와 다른 팀에서 얻은 좋은 기준을 가져온다.
   3. 프로젝트를 넘는 범위: 어떤 원칙은 현재 프로젝트나 팀보다 큰 조직 수준의 의미를 가진다.

2. 첫 기능 이후

   1. 검토의 반복: 헌법·명세·계획·태스크·코드 등 AI가 낸 모든 결과를 계속 검토한다.
   2. 실행과 체감: 기능을 직접 구현하고 사용해 스펙 주도 흐름이 실제 팀에 어떻게 맞는지 느낀다.
   3. 다음 기능으로 확장: 첫 기능을 마치면 다음 기능도 Spec Kit으로 구현해 반복 가능성을 확인한다.

주요 발언 모음

“프롬프트를 주요 산출물로 취급하지 말고, 명세를 주요 산출물로 취급하기 시작하세요.”

“프롬프트 우선 개발에서는 지시를 쓰고 모델이 코드를 작성한 뒤 예상하지 못한 결과를 얻습니다.”

“헌법부터 코드까지가 시작점이며, AI가 내놓는 모든 것을 검토해야 합니다.”

“명세는 무엇을 만들지 설명하고, 방법은 계획을 위해 남겨둡니다.”

“그냥 마크다운이고, 그냥 스크립팅입니다.”

“최신 프레임워크 버전을 원한다면 계획 프롬프트에 원하는 버전을 구체적으로 적으세요.”

“내일 전체 작업 흐름을 다시 만들 필요는 없습니다. 작지만 의미 있는 실제 기능 하나를 고르세요.”

“무엇과 왜를 먼저 포착하고, 어떻게인지는 나중에 다루세요.”

핵심 데이터 & 수치

• 영상 길이: 약 22분(메타데이터 기준 22분 07초).
• 핵심 단계 수: 헌법(Constitution) → 명세(Specification) → 계획(Plan) → 태스크(Task)의 네 단계이며 구현(Implement)과 검토가 뒤따른다.
• 헌법 원칙 수: 세션 플래너 MCP 서버에 적용한 원칙은 근거 있는 데이터, 시간 인식, 에이전트 안전, HTTP 안전성, 설계부터 테스트 가능, 기본값으로 개인정보 보호의 여섯 가지다.
• 첫 도입 규모: 협상 불가능한 팀 규칙은 처음에 두세 개부터 시작하고, 필요하면 네다섯 개까지 둘 수 있다.
• 데모 대상: Microsoft Build 세션 데이터를 AI 에이전트에 제공하는 MCP 서버다.
• 계획 기술 예시: TypeScript, Node.js, MCP 서버, HTTP 전송, 배포·구성 설정, Dockerfile이 계획과 태스크의 구체 항목으로 등장한다.
• 검증 결과: MCP Inspector에서 서버 연결, 도구 목록, 세션 검색 필드, 개막 기조연설 검색 결과를 확인했다.

결론 및 시사점

1. 프롬프트는 빠른 프로토타이핑에 유용하지만 대규모 협업의 신뢰 가능한 주산출물이 되기 어렵다.
2. 명세를 저장소와 Git 기록에 남기면 AI 코딩의 요구·결정·변경을 팀이 검토하고 재현할 수 있다.
3. 헌법은 AI와 팀이 지켜야 할 협상 불가능한 원칙을 담고, 명세는 기술과 분리된 기능 요구사항을 담는다.
4. 계획은 배포·스택·프레임워크·버전·구성 같은 구현 방법을 담당하며, 지정하지 않은 버전은 최신이 아닐 수 있으므로 명시적으로 고정해야 한다.
5. 태스크는 큰 기능을 보일러플레이트·의존성·컨테이너·기능 작업으로 나눠 AI가 단계적으로 처리하게 한다.
6. 분석과 명확화를 먼저 실행하면 구현 전에 모호성과 충돌을 줄일 수 있고, 구현 단계는 테스트와 함께 작동하는 코드를 만든다.
7. GitHub Spec Kit은 마크다운과 스크립트로 이 흐름을 제공하므로 .specify 폴더를 직접 읽어 자동화의 동작을 이해하는 것이 좋다.
8. 첫 도입은 이번 주·다음 달·다음 반복 주기에 처리할 작지만 의미 있는 기능 하나로 제한하고, 결과를 검토한 뒤 다음 기능으로 확대해야 한다.

핵심 요약 (20줄)

프롬프트 우선 AI 코딩은 빠른 출발을 가능하게 하지만 대규모 협업의 공통 기반으로는 취약하다. 개인 프롬프트는 비공개이고 일시적이며 검토와 재현이 어려워 팀 지식으로 축적되기 힘들다. AI가 만든 코드는 빌드되더라도 기능의 핵심 의도를 놓칠 수 있어 결과 검토와 원인 추적 비용이 발생한다. 스펙 주도 개발은 프롬프트가 아니라 명세를 저장소의 주요 산출물로 취급한다. 헌법은 프로젝트와 팀을 넘어 재사용할 수 있는 보안·품질·기업·팀 규칙을 담는다. 명세는 기술 구현 방법을 제외하고 애플리케이션이 무엇을 해야 하는지와 기능 요구사항을 정의한다. 계획은 배포 대상·기술 스택·프레임워크·버전·HTTP 전송·구성 같은 구현 방법을 결정한다. 태스크는 사용자 스토리와 기술 구현을 AI가 처리할 수 있는 논리적이고 관리 가능한 단위로 나눈다. 구현 단계는 태스크를 코드로 바꾸면서 테스트를 함께 구성해 컴파일과 동작을 검증한다. 헌법부터 명세·계획·태스크까지 AI가 생성한 모든 문서는 사람이 읽고 팀이 합의해야 한다. Microsoft Build 세션 플래너 MCP 서버는 스펙 주도 흐름을 설명하기 위한 실제 데모 대상이다. 세션 플래너는 Microsoft Build 세션 데이터를 AI 에이전트가 활용하도록 MCP 도구를 제공한다. MCP 서버의 헌법에는 근거 있는 데이터·시간 인식·에이전트 안전·HTTP 안전성이 포함된다. 설계부터 테스트 가능성과 기본값으로 개인정보 보호를 두면 공개 엔드포인트와 미래 확장에 대비할 수 있다. GitHub Spec Kit은 Specify CLI로 Copilot 통합 지침과 스펙 주도 개발용 폴더를 프로젝트에 추가한다. Spec Kit의 핵심 자동화는 마크다운과 스크립트로 구성되어 있어 내부 동작을 직접 확인할 수 있다. 명세 단계는 세션 검색·상세 조회·현재 진행 세션 확인이라는 사용자 스토리를 생성한다. 계획 단계에서 자동 선택되는 라이브러리 버전은 최신이 아닐 수 있으므로 원하는 버전을 직접 지정해야 한다. MCP Inspector는 서버 연결·도구 목록·검색 필드·세션 결과를 확인해 실제 작동을 검증한다. 도입은 전체 업무 흐름을 한 번에 바꾸기보다 작지만 의미 있는 기능 하나에 명세와 헌법을 적용하는 데서 시작해야 한다.