AI 에이전트와 함께하는 스펙 주도 개발 풀코스

URL: https://www.youtube.com/watch?v=FJo7p9SPS9c 날짜: 2026-09-26 채널: Tech Bridge 원문 제목: [한영자막] AI 에이전트와 함께하는 스펙 주도 개발 풀코스 강의 재생 시간: 1시간 1분 33초

---

메타데이터

• 주제: 스펙 주도 개발(Spec-Driven Development, SDD), 에이전틱 코딩(Agentic Coding), 인간 개입형 검증(Human-in-the-Loop), 에이전트 스킬(Agent Skills), 에이전트 표준
• 강의 파트너: JetBrains
• 강사: 폴 에버렛(Paul Everett), JetBrains Developer Advocate
• 진행·소개: 앤드루(Andrew)
• 실습 프로젝트: Agent Clinic — AI 에이전트가 인간과의 협업에서 생기는 문제를 치료받는다는 설정의 풀스택 웹 애플리케이션
• 사용 도구: WebStorm, Claude Code, TypeScript, Next.js, React, SQLite, Git, Pico CSS, Context7
• 핵심 파일: mission.md, techstack.md, roadmap.md, feature plan, requirements, validation 문서
• 핵심 용어: Constitution, feature loop, replanning, brownfield, greenfield, MCP(Model Context Protocol), ACP(Agent Client Protocol), Spec Kit, OpenSpec

---

📌 핵심 질문 / 스펙 주도 개발의 핵심 논점

==AI 에이전트의 빠른 코드 생성력을 유지하면서 제품 의도, 기술적 제약, 장기적인 유지보수성을 어떻게 보존할 것인가?==

• 프로젝트 수준의 Constitution이 미션·기술 스택·로드맵을 불변에 가까운 기준으로 고정한다.
• 각 기능을 별도 브랜치에서 계획(Plan)·구현(Implement)·검증(Validate)하는 작은 루프로 처리한다.
• 사람은 에이전트가 모르는 맥락과 우선순위를 제공하고, 에이전트가 만든 결과를 높은 수준에서 검토한다.
• 스펙은 세션과 에이전트를 넘어 프로젝트의 기억으로 남아 컨텍스트 붕괴(Context Decay)와 의도 이탈을 줄인다.
• 스킬과 표준을 사용하면 특정 IDE나 특정 에이전트에 묶이지 않는 반복 가능한 개발 프로세스를 만들 수 있다.

스펙 주도 개발은 “코드를 어떻게 작성할까”보다 “무엇을 왜 만들며 성공을 어떻게 판정할까”를 먼저 결정하는 개발 방식이다. 사람은 수석 아키텍트이자 감독자로서 청사진과 판단 기준을 제공하고, 에이전트는 계획된 작업을 빠르게 수행하는 고성능 페어 프로그래머가 된다. 좋은 스펙은 에이전트에게 모든 저수준 구현을 지시하는 문서가 아니라, 에이전트가 알 수 없는 목표·대상 사용자·제약·품질 기준을 전달하는 영구 기술 산출물이다.

1. 스펙 주도 개발이 필요한 이유

1.1. 작은 스펙 변경이 큰 코드 변경을 통제한다

1. 하류 증폭(Downstream Amplification)

   1. “SQLite와 Prisma ORM을 사용하라”는 한 문장이 수백 줄의 데이터 모델·설정·쿼리·서버 코드를 결정할 수 있다.
   2. 같은 문장을 MongoDB 사용으로 바꾸면 전체 구현 방향이 함께 바뀐다.
   3. 수백 줄의 코드를 직접 수정하는 것보다 핵심 결정을 담은 한두 문장을 수정하는 편이 훨씬 효율적이다.

2. 스펙 작성의 레버리지

   1. 에이전트가 20~30분 동안 수행할 작업은 전통적인 개발자의 여러 시간에 해당할 수 있다.
   2. 에이전트가 실행되기 전에 3~4분 동안 명확한 지침을 작성하면 큰 작업의 방향을 저렴하게 통제할 수 있다.
   3. 빠른 코딩보다 먼저 생각하고 결정하는 시간이 전체 개발 비용과 재작업 비용을 줄인다.

1.2. 컨텍스트 붕괴와 세션 간 기억 손실을 막는다

1. 에이전트의 무상태성(Statelessness)

   1. 에이전트는 세션을 새로 시작할 때 이전 대화의 핵심 결정을 자동으로 보존하지 않는다.
   2. 한 세션의 대화가 길어지면 컨텍스트 윈도우가 가득 차고, 에이전트는 작업 기억이 포화된 상태에서 더 많은 실수를 낸다.
   3. 스펙은 세션과 에이전트가 달라져도 프로젝트의 비협상 조건(Non-negotiables)을 다시 불러올 수 있는 외부 기억이 된다.

2. 고품질 초기 컨텍스트

   1. 에이전트가 부팅되는 시점에 가장 중요한 맥락을 제공해야 이후 추론과 코드 생성이 안정된다.
   2. 프로젝트의 목표와 기술 결정은 Constitution에 남기고, 기능별 세부 사항은 feature spec에 남긴다.
   3. 대화 기록에 의존하지 않고 버전 관리되는 문서에 의존하면 장기 프로젝트의 방향이 덜 흔들린다.

1.3. 의도 충실도(Intent Fidelity)를 높인다

1. 성공 조건의 선행 정의

   1. 문제 정의, 성공 기준, 제약 조건, 사용자 흐름을 코드 생성 전에 정리한다.
   2. 에이전트는 명확한 입력을 바탕으로 더 완전한 계획을 세우고 누락된 세부 사항을 질문할 수 있다.
   3. 스펙이 구체적일수록 에이전트가 빈칸을 임의의 가정으로 채울 가능성이 낮아진다.

2. 결정권의 위치

   1. 기술 아키텍처와 제품 요구를 에이전트의 우연한 선택에 맡기면 빠르지만 유지보수성이 낮고 이상한 제품이 나올 수 있다.
   2. 복잡한 제품에서 명확한 스펙이 없으면 여러 개발자의 에이전트가 서로 다른 방향으로 빠르게 코드를 만들게 된다.
   3. 결과적으로 기능은 많아 보여도 서로 모순되는 설계와 후속 작업의 두통이 쌓인다.

1.4. Vibe Coding과 Engineering의 차이

1. Vibe Coding의 흐름과 한계

   1. “버튼을 만들어 줘”처럼 높은 수준의 프롬프트를 던지고 에이전트가 만든 결과를 확인한다.
   2. 큰 버튼이 나왔지만 크기·배치·동작이 중요한 요구와 어긋나면 실수를 지적하고 다시 생성한다.
   3. 이런 대화가 반복되면 저장되지 않는 긴 대화 기록이 생기며, 작은 버튼에는 쓸 수 있어도 지속적인 대형 프로젝트에는 확장되지 않는다.
   4. 빠른 프롬프트는 일회용 코드와 누적되는 기술 부채(Technical Debt)를 만들 수 있다.

2. SDD의 계약 모델

   1. 스펙은 무엇(What)과 왜(Why)를 구현 방법(How)과 분리하는 영구 기술 산출물이다.
   2. 스펙은 사람과 사람 사이의 계약인 동시에 사람과 에이전트 사이의 계약이다.
   3. 사람의 핵심 업무는 의도를 명확한 스펙으로 변환하는 능력을 기르는 일로 이동한다.
   4. 컴파일러가 사람이 읽을 수 있는 소스 코드를 기계 코드로 변환하듯, SDD는 사람이 읽을 수 있는 스펙을 에이전트가 구현할 소스 코드로 변환한다.

1.5. 챗봇과 코딩 에이전트의 구분

1. 챗봇

   1. 챗봇은 코드에 관해 대화할 수 있지만 프로젝트의 실제 코드베이스나 설치된 도구에 접근하지 못한다.
   2. 챗봇은 프롬프트에 응답할 뿐 프로젝트를 조사하고 명령을 실행해 결과를 완성하는 주체가 아니다.

2. 에이전트

   1. 에이전트는 프롬프트를 받아 계획을 세우고, 추론을 이어 가며 도구를 사용해 결과를 만든다.
   2. 에이전트는 코드베이스와 개발 도구에 접근하므로 프로젝트의 실제 상태를 반영할 수 있다.
   3. 에이전트는 기술 지식과 실행 속도를 제공하는 고성능 페어 프로그래머다.
   4. 사람은 수석 아키텍트로서 청사진을 제공하며, “에이전트는 근육이고 스펙은 두뇌”라는 역할 분담을 지킨다.

2. SDD의 전체 구조와 적절한 상세 수준

2.1. Constitution: 프로젝트 수준의 헌법

1. Constitution의 역할

   1. 프로젝트 미션, 기술 스택, 로드맵처럼 모든 기능에 영향을 주는 높은 수준의 결정을 담는다.
   2. 사람과 에이전트 사이의 합의뿐 아니라 여러 사람 사이의 합의도 기록한다.
   3. 일부 개발자는 최상위 agents.md에 비슷한 규칙을 넣지만, Constitution은 에이전트에 종속되지 않고 더 구조화된 형태로 남는다.

2. 세 가지 기둥

   1. Mission: 프로젝트가 존재하는 이유, 비전, 대상 사용자, 범위와 청중을 정의한다.
   2. Tech Stack: 개발·배포 기술, 회사의 관행, 기술적 제약과 트레이드오프를 합의한다.
   3. Roadmap: 여러 단계를 순서대로 배치하고 각 단계가 독립적인 feature spec 프로세스로 구현되도록 한다.

3. 살아 있는 문서

   1. Constitution과 roadmap은 한 번 쓰고 버리는 요구사항이 아니라 기능이 완성될 때마다 재검토하는 생활 문서다.
   2. 제품이나 기술에 큰 변화가 생기면 replanning 브랜치에서 Constitution의 버전을 갱신한다.
   3. 어떤 Constitution 버전이 어떤 코드 변경을 만들었는지 추적할 수 있도록 스펙도 Git 버전 관리의 일부로 취급한다.

2.2. 적절한 상세 수준

1. 에이전트가 결정할 수 있는 것과 사람이 제공할 것

   1. 사람은 목표, 미션, 대상 사용자, 범위, 제약, 장기 방향처럼 에이전트가 알 수 없는 맥락을 충분히 제공한다.
   2. 에이전트가 합리적으로 결정할 수 있는 저수준 구현, 변수명, 세부 파일 분할까지 사람이 미리 지정하면 과도한 조종(Oversteering)이 된다.
   3. 중요한 기술 요구와 제약은 적되, 사소한 구현 세부 사항은 에이전트의 판단에 맡긴다.

2. 건축가 비유

   1. 건축가는 건물의 상세 도면을 그리고 시공자가 작업할 수 있도록 설계 의도와 인수 기준을 제공한다.
   2. 건축가는 시공자의 모든 작업 방법을 지시하지 않고, 작업을 감독하고 결과를 검토하며 필요하면 수정을 요청한다.
   3. SDD에서도 사람은 도면과 감독을 맡고 에이전트는 정해진 계약을 구현한다.

2.3. 반복 가능한 Feature Loop

1. Plan

   1. 로드맵의 다음 기능을 별도 브랜치에서 선택한다.
   2. 에이전트와 대화하며 기능 범위, 요구사항, 작업 순서, 성공 검증 방법을 확정한다.
   3. 에이전트의 질문과 제안을 검토하고 마음에 들지 않는 아키텍처나 잠재적 충돌을 즉시 수정한다.

2. Implement

   1. 계획과 요구사항이 확정되면 새로운 컨텍스트에서 작업을 시작한다.
   2. /clear로 이전 대화의 기억을 비워 스펙에 기록된 의도에 집중한다.
   3. 전체 task group을 한 번에 구현하거나, 보안·데이터베이스처럼 실수가 누적되기 쉬운 영역은 task group별로 나눠 작은 커밋을 만든다.

3. Validate

   1. 에이전트가 만든 코드가 스펙을 만족하는지, 실제 애플리케이션이 실행되는지, 테스트가 통과하는지 확인한다.
   2. 세부 CSS 클래스나 변수명보다 기능의 동작과 스펙과의 일치 여부를 우선 검토한다.
   3. 테스트를 읽고 디버거로 실행해 코드 흐름을 이해하는 일도 인수 검증의 일부로 삼는다.

4. Replan

   1. 기능 사이에 Constitution, roadmap, 테스트 정책, 프로세스를 재검토한다.
   2. 작게 바꿀 수 있는 제품 요구는 replanning 중에 반영하고, 큰 작업은 새로운 roadmap feature phase로 예약한다.
   3. “천천히 가야 빨리 갈 수 있다”는 원칙으로 다음 기능에 진입하기 전에 방향과 작업 공간을 정리한다.

3. 실습 환경과 Agent Clinic 프로젝트

3.1. 도구 선택과 Git 기반 작업 공간

1. 도구 독립성

   1. SDD는 특정 IDE나 특정 코딩 에이전트에 종속되지 않는다.
   2. VS Code와 Codex CLI, Zed와 로컬 모델, WebStorm과 Claude Code 모두 같은 원칙을 적용할 수 있다.
   3. 웹 애플리케이션 실습은 WebStorm IDE와 Claude Code를 사용한다.

2. 초기 설정

   1. Git 저장소를 포함한 TypeScript 프로젝트 Agent Clinic을 만든다.
   2. 코드와 스펙의 버전을 함께 관리해 어떤 결정이 어떤 변경으로 이어졌는지 추적한다.
   3. IDE의 채팅 패널이 있어도 에이전트와 상호작용하는 방법은 다양하므로, 자신이 익숙한 환경을 선택할 수 있다.
   4. Claude Code가 명령을 실행할 때마다 확인을 요청하며, unsafe mode를 선택하면 확인이 줄어드는 대신 보안 위험을 사용자가 책임진다.
   5. 에이전트가 무엇을 실행하려는지 주의 깊게 확인하고 코드의 최종 책임은 사람에게 있음을 명시한다.

3.2. Agent Clinic의 제품 설정

1. 제품 콘셉트

   1. Agent Clinic은 유명한 학습용 프로젝트 Pet Clinic을 패러디해 AI 에이전트가 인간 때문에 생긴 문제를 치료받는 병원이다.
   2. 에이전트가 겪는 환각(Hallucination), 컨텍스트 부패(Context Rot), 기억 문제, 동료 서브에이전트 조정 문제를 질병으로 모델링한다.
   3. 예약(Appointment), 질환(Ailment), 치료(Treatment)를 관리하는 풀스택 웹 애플리케이션을 만든다.

2. 기술 구성

   1. 백엔드는 Next.js를 사용하고 프론트엔드는 React로 구성한다.
   2. 프로토타입의 데이터베이스는 SQLite를 사용하며, 이후 기능 스펙에서 필요한 ORM과 마이그레이션 정책을 구체화한다.
   3. 컨텍스트 주입(Context Infusion) 같은 치료 이름을 제품의 유머러스한 도메인 모델로 사용한다.

3.3. Constitution을 에이전트와 함께 작성하기

1. 초기 인터뷰

   1. 저장소에 제품 설명과 이해관계자 의견을 readme.md로 제공한다.
   2. Claude Code의 ask user question 도구를 사용하도록 요청하면 인터페이스에서 선택형 질문을 편하게 받을 수 있다.
   3. 에이전트에게 Mission, Tech Stack, Roadmap을 함께 작성하고 roadmap을 작은 단계로 나누도록 지시한다.
   4. Mission의 문체는 Agent Clinic의 설정에 맞게 playful로 선택한다.
   5. 백엔드 개발팀이 TypeScript에 익숙하다는 조직 맥락을 기술 스택 요구사항에 추가한다.
   6. Roadmap은 가장 세분화된 선택지를 골라 사람이 각 단계를 검토하기 쉽도록 한다.

2. 초기 산출물 검토

   1. 에이전트는 specs 디렉터리에 mission.md, techstack.md, roadmap.md 세 파일을 만든다.
   2. Mission에 대상 사용자가 빠졌다면 에이전트가 회사의 사업 맥락을 알 수 없었기 때문이라고 판단하고 대화로 보완한다.
   3. 문서를 직접 편집하기보다 에이전트에게 수정하도록 요청해 관련 문서가 함께 갱신되게 한다.
   4. 빠른 프로토타입이라 처음에 명시하지 않았던 SQLite도 에이전트의 추천을 검토한 뒤 Tech Stack에 확정한다.
   5. 최종 검토가 끝나면 Constitution을 커밋해 프로젝트의 살아 있는 기준으로 만든다.

3. 에이전트의 질문이 주는 가치

   1. 에이전트는 사람이 고려하지 못한 아키텍처 패턴, 이미 문제를 해결하는 외부 패키지, 속도와 데이터 충실도 사이의 트레이드오프를 질문할 수 있다.
   2. 질문에 대한 답은 에이전트에게 결정권을 넘기는 것이 아니라 사람이 더 나은 결정을 내릴 수 있도록 선택지를 넓히는 과정이다.
   3. Greenfield뿐 아니라 기존 코드베이스에서도 Mission·Tech Stack·Roadmap이라는 세 기둥을 정리할 수 있다.

4. 첫 기능: Hello Hono의 계획·구현·검증

4.1. 계획 브랜치와 Feature Spec

1. 새 컨텍스트에서 시작하기

   1. Agent Clinic의 phase one 로드맵 기능을 Hello Hono로 정한다.
   2. Constitution을 공식 출처로 삼아 새 에이전트 세션을 시작하고, 현재 기능을 별도 브랜치에서 작업한다고 알린다.
   3. 프롬프트에는 기능 스펙, 작업 계획, 요구사항 수집, 검증용 scorecard를 함께 만들라는 내용을 넣는다.

2. 초기 결정

   1. phase one의 범위는 로드맵에 적힌 대로 유지한다.
   2. Hono 버전을 특정해 환경 차이를 줄이고 strict TypeScript를 강제한다.
   3. 첫 기능의 확인 방법은 수동 curl로 선택한다.
   4. 에이전트의 질문과 제안이 마음에 들지 않으면 수락하지 않고 충돌이나 우려를 명확하게 설명한다.

3. 세 문서 검토

   1. Plan은 구현 접근법, 작업 순서, 작업 그룹을 기록한다.
   2. Requirements는 홈페이지 모양과 중요한 기술 요구·제약을 기록하며 변수명 같은 저수준 세부 사항은 넣지 않는다.
   3. Validation은 기능이 제대로 구현됐는지 에이전트가 판정할 수 있는 방법을 기록한다.
   4. 처음에는 단순한 placeholder homepage였지만, 보기 좋은 홈페이지를 요구하도록 스펙을 수정하자 계획·요구사항·검증 문서가 함께 갱신된다.

4.2. 구현과 인간 개입형 검토

1. 구현 시작

   1. feature spec을 커밋한 뒤 /clear로 에이전트 컨텍스트를 비운다.
   2. 모든 task group을 구현하도록 요청하거나 작은 단계와 작은 커밋이 필요한 영역은 그룹별로 실행한다.
   3. 에이전트가 콘솔에 표시하는 변경 내용을 관찰해 진행 상황을 파악하고, 커밋 창과 변경 목록에서 조기 검토를 시작한다.

2. 첫 실행 확인

   1. package.json의 스크립트로 애플리케이션을 실행한다.
   2. 브라우저에 기능의 결과가 표시되며, 코드가 단순해도 화면에 픽셀이 나타나는 순간은 구현이 실제로 연결됐다는 신호다.
   3. 에이전트가 자체 validation을 수행했더라도 사람의 검증은 아직 끝나지 않는다.

3. 계획에서 비롯된 구현 오류 수정

   1. home.tsx가 지나치게 최소화되어 헤더·메인·푸터라는 명확한 landmark를 가진 layout component가 필요하다는 점을 발견한다.
   2. 세 영역은 하위 컴포넌트로 나누고 별도의 CSS 파일을 만들도록 요구한다.
   3. 코드의 실수가 계획에 요구사항을 넣지 않았던 데서 흐른 것이라면 에이전트에게 계획과 구현을 함께 수정하게 한다.
   4. 계획을 고치지 않고 코드만 고치면 다음 세션이나 다음 기능에서 같은 오류가 반복될 수 있다.

4. 드리프트 방지

   1. 세 하위 컴포넌트를 한 파일에 둔 결과가 프로젝트 관례와 맞지 않으면 IDE의 move 도구로 별도 파일로 분리할 수 있다.
   2. 그러나 사람이 코드만 이동하면 다른 스펙·README·문서의 경로와 언급이 낡을 수 있다.
   3. 에이전트에게 모든 참조를 수정하고 문서와 구현을 동기화하도록 요청하면 나중에 발생할 재작업을 줄일 수 있다.

4.3. 검증, 병합, 버전 관리

1. 검증 기준

   1. 검토는 CSS 클래스나 구현 스타일을 일일이 지적하기보다 기능이 동작하고 스펙의 의도와 맞는지에 집중한다.
   2. 에이전트가 테스트 패키지를 설치하지 않았다면 기능이 잘못된 것이 아니라 공통 개발 환경에 대한 결정이 아직 Constitution에 없었던 것이다.
   3. 테스트 프레임워크처럼 모든 기능에 필요한 정책은 다음 replanning에서 Constitution과 기존 기능에 반영한다.

2. 커밋과 병합

   1. 계획·요구사항·검증 문서가 구현과 함께 정리되면 기능을 완료 상태로 표시한다.
   2. Roadmap의 작은 체크 표시 변경은 기능 브랜치에 함께 커밋해도 무방하다.
   3. Constitution의 큰 변경은 어떤 코드가 어떤 기준에서 생성됐는지 명확히 하기 위해 별도 브랜치가 더 적합할 수 있다.
   4. 검토와 수정이 끝난 feature branch를 main에 병합한다.

3. Human-in-the-Loop와 인지 부채

   1. 에이전트가 생성한 결과를 사람이 확인하고 다시 요청하는 과정이 Human-in-the-Loop다.
   2. 인지 부채(Cognitive Debt)는 코드가 무엇을 하고 어떻게 진화했는지 추적하는 정신적 부담이다.
   3. 에이전트가 매우 빠르게 코드를 만들수록 사람이 감당할 변경량을 작고 검토 가능한 수준으로 유지해야 인지 부채가 쌓이지 않는다.

5. Replanning과 개발 프로세스의 개선

5.1. 테스트 정책과 Constitution 업데이트

1. 검증을 공통 정책으로 승격

   1. 첫 기능을 끝낸 뒤 곧바로 다음 기능으로 달려가지 않고 replanning 브랜치를 만든다.
   2. Constitution은 어떤 코드와 스펙을 만들어 냈는지 추적할 수 있는 살아 있는 문서이므로 별도 브랜치에서 버전을 갱신한다.
   3. 테스트 프레임워크를 추가하는 정책을 package.json에 반영하고 향후 기능의 기본 검증으로 삼는다.
   4. 스크립트만 추가되고 실제 의존성은 빠질 수 있으므로 변경 결과를 확인한다.

2. 기존 산출물 동기화

   1. Constitution의 테스트 정책이 기존 기능 스펙과 구현에도 영향을 주도록 관련 문서를 함께 업데이트한다.
   2. 테스트 설정과 별개로 첫 기능에 실제 테스트를 작성하도록 추가 요청한다.
   3. IDE에서 테스트를 실행하고 디버거로 코드 실행을 따라가면 테스트가 있다는 사실을 넘어 코드 흐름까지 이해할 수 있다.

5.2. 제품 요구 변화와 로드맵 재검토

1. 반응형 디자인 요구

   1. 제품 관리자가 사용자 40%가 모바일에서 접속한다고 알려 주면 반응형 디자인을 우선순위로 올린다.
   2. 제품 스펙, feature spec, 구현 코드를 함께 수정해 결정이 코드에만 남지 않게 한다.
   3. 초기 단계의 작은 변경은 replanning에서 직접 처리할 수 있다.
   4. 작업량이 크면 로드맵의 독립적인 feature phase로 예약해야 replanning이 과도하게 비대해지지 않는다.

2. 작은 커밋의 효과

   1. 사람은 변경을 한 번에 많이 검토할 때 인지 부하가 커지므로 작게 작업하고 자주 커밋한다.
   2. 모든 제품 결정은 코드가 아니라 스펙에도 남겨 팀 커뮤니케이션과 다음 에이전트의 맥락을 보존한다.
   3. 다음 기능으로 넘어가기 전에 로드맵의 순서가 여전히 타당한지 확인한다.
   4. 여러 기능이 서로 밀접하게 묶여 있으면 기능 2·3·4·5를 하나의 단계로 합치는 식으로 로드맵을 현실에 맞춰 조정한다.

5.3. Change Log Skill과 반복 업무 자동화

1. 조직 차원의 재계획

   1. Replanning은 현재 기능이나 프로젝트 전체를 고치는 데 그치지 않고 조직 전체의 SDD 프로세스를 개선하는 기회가 된다.
   2. 비기술 이해관계자가 진행 상황을 확인해야 한다면 merge마다 change log를 업데이트하는 반복 작업이 필요하다.
   3. 프로젝트나 조직 맥락에 맞는 반복 가능 워크플로에는 Agent Skill이 적합하다.

2. 스킬의 범위 결정

   1. Change Log Skill이 특정 프로젝트 전용인지 모든 프로젝트에 적용할 표준인지 결정한다.
   2. 에이전트가 제공하는 skill creator를 사용해 스킬의 지침과 사용법을 함께 만든다.
   3. 해당 스킬을 사용해 프로젝트 change log를 생성한 뒤 사람이 직접 열어 이해관계자에게 적절한지 검토한다.
   4. 전역 skills 영역에 만들면 모든 프로젝트에서 사용할 수 있고, 프로젝트 디렉터리에 만들면 해당 프로젝트의 문맥만 공유한다.

3. Validation Skill

   1. 검증 단계에는 README 갱신, lint, formatting, test 실행 등 반복적인 품질 검사를 포함할 수 있다.
   2. 이 작업들을 하나의 validation skill로 패키징하면 매 기능마다 수동으로 같은 프롬프트를 반복할 필요가 없다.
   3. 반복 가능한 프로세스를 스킬로 고정할수록 자동화와 일관성이 함께 올라간다.

6. AI Fatigue를 줄이는 두 번째 기능과 심층 검증

6.1. 기능 사이의 깨끗한 경계

1. 다음 기능 전 상태 확인

   1. 미완료 작업이 남아 있지 않은지 확인한다.
   2. 직전 feature branch가 main에 병합됐는지 확인한다.
   3. 다음 roadmap item이 아직도 올바른지 확인한다.
   4. 에이전트 컨텍스트를 지워 이전 대화의 기억이 아니라 스펙이 의도를 결정하게 한다.
   5. 제한된 컨텍스트 예산을 새 작업에 사용하도록 깨끗한 출발점을 만든다.

2. AI Fatigue

   1. 에이전트는 많은 코드를 매우 빠르게 생성하므로 사람이 검토해야 할 변경량도 폭증한다.
   2. 기능 사이에 브랜치·컨텍스트·로드맵을 정리하면 한 번에 처리할 변경량이 작아져 혼란과 피로가 줄어든다.
   3. 반복 입력을 줄이는 custom workflow는 이후 스킬로 자동화할 수 있다.

6.2. Agents and Ailments의 계획

1. 인터뷰 결정

   1. 이전 replanning에서 여러 기능을 한 phase로 합치기로 결정했으므로 에이전트가 다시 물어도 하나의 phase로 유지한다.
   2. 데이터베이스 마이그레이션은 plain SQL을 사용한다.
   3. 제시된 검증 선택지 중 1·2·3을 모두 선택한다.
   4. 에이전트가 만든 계획을 읽은 뒤 CSS 프레임워크는 Pico CSS로 명시한다.

2. 스펙의 진화

   1. Pico CSS 결정을 Requirements에 넣고 관련 파일이 모두 업데이트되는지 에이전트에게 확인시킨다.
   2. Feature spec의 Plan, Requirements, Validation 세 파일을 차례로 검토한다.
   3. 문서가 확정되면 feature spec을 커밋하고, 이번에는 에이전트가 커밋 메시지를 작성하도록 할 수 있다.
   4. 새로 발견한 세부 결정이 최초 스펙에 없었다고 해서 구현이 실패한 것은 아니다.
   5. 사람과 에이전트는 작업 중 드러난 결정을 스펙에 추가하면서 미래 결과를 개선한다.

6.3. 구현 규모와 심층 리뷰

1. 컨텍스트와 변경량 관리

   1. 계획 단계와 구현 단계를 나누면 사람과 에이전트의 컨텍스트가 한꺼번에 넘치지 않는다.
   2. 기능이 크면 전체 계획을 한 번에 구현하지 말고 일부 task group부터 구현한다.
   3. 에이전트가 진행 상황을 보여 줘도 사람이 충분히 생각하고 깊이 있는 리뷰를 해야 한다.

2. 리뷰의 초점

   1. 에이전트의 강점을 살리고 AI Fatigue를 줄이려면 변수명 같은 사소한 스타일보다 높은 수준의 요구사항에 집중한다.
   2. 코드가 사람의 이름으로 커밋해도 되는 품질인지 판단한다.
   3. Props의 타입 정보가 인라인으로 작성돼 있다면 standalone TypeScript type으로 추출하도록 에이전트에게 일관되게 요청한다.
   4. 최초 스펙에 없던 결정도 리뷰 중에 발견하면 이후 스펙과 코드에 반영한다.

3. 테스트와 실행 탐색

   1. Validation 계획을 읽고 애플리케이션을 실행해 실제 동작을 확인한다.
   2. 테스트를 읽고 디버거로 실행해 코드 흐름을 탐색한다.
   3. 테스트는 기능이 작동한다는 증거인 동시에 사람이 변경 내용을 이해해 인지 부채를 줄이는 도구다.
   4. 에이전트에게 여러 서브에이전트를 생성해 전체 프로젝트와 새 기능을 심층 리뷰하도록 요청할 수 있다.
   5. 서브에이전트는 중요한 문제와 권고 사항을 찾아내며, 주 에이전트의 컨텍스트를 오염시키지 않고 더 넓은 검토 공간을 제공한다.
   6. 두 번째 검토에서 발견한 이슈를 에이전트가 수정하고 테스트를 다시 실행하면 기능을 병합할 준비가 된다.

4. Change Log와 마무리

   1. 기능 브랜치에서 Change Log Skill을 실행해 이해관계자에게 변경 내용을 남긴다.
   2. 로그 커밋을 추가한 뒤 feature branch를 병합한다.
   3. 다음 roadmap item을 다시 확인한 뒤 깨끗한 경계를 유지하고 휴식할 수 있는 상태로 만든다.

7. Constitution으로 MVP를 만드는 실험

7.1. 큰 구현을 허용하는 조건

1. MVP 요청

   1. 두 기능을 스펙 워크플로로 구현한 뒤 관리자가 MVP를 요청한다.
   2. 이번에는 기존 feature spec을 참고해 남은 roadmap을 구현하도록 표준 프롬프트를 확장한다.
   3. 큰 작업을 허용하려면 Constitution과 기존 feature spec의 품질을 신뢰하고 결과를 충분히 리뷰·검증할 수 있어야 한다.

2. MVP를 극한 테스트로 사용하기

   1. 남은 로드맵을 한 번에 구현하는 위험을 Constitution과 완성된 스펙의 극한 테스트로 간주한다.
   2. 결과가 원하는 제품과 다르면 에이전트 탓으로 끝내지 않고, 잘못된 결과를 만든 맥락과 결정의 원인을 replanning에서 제거한다.
   3. 에이전트의 질문과 추천을 검토하면서 빈칸을 채운다.

7.2. MVP 스펙·구현·평가

1. 스펙 저장 전 검토

   1. 인터뷰를 마친 뒤 MVP 스펙을 디스크에 저장한다.
   2. Plan, Requirements, Validation을 짧게라도 모두 검토해 에이전트가 빈칸을 메우며 만든 잘못된 가정을 찾는다.
   3. 작은 단계와 잦은 커밋 원칙은 대규모 구현을 앞두고도 유지한다.

2. 결과 확인

   1. 에이전트가 많은 코드를 구현한 뒤 스크립트로 애플리케이션을 실행한다.
   2. 각 화면 섹션이 데이터베이스에서 조회한 sample data를 사용해 더 풍부하게 표시된다.
   3. MVP 단계에서는 일반적인 전체 코드 검증을 생략할 수 있지만, 에이전트에게 스펙 자체를 평가하게 해 계획의 구멍을 찾는다.
   4. 에이전트의 평가는 이해관계자에게 MVP 검토 자료로 공유할 수 있다.
   5. 결과에 따라 브랜치를 병합하거나 보관한다.

3. MVP의 의미

   1. Constitution과 두 기능의 스펙만으로도 사람의 안내가 더해지면 유용한 데모를 만들 수 있다.
   2. 모든 프로젝트가 MVP를 만드는 것은 아니므로 대규모 일괄 구현은 보편 규칙이 아니라 신뢰도와 검증 역량에 따른 선택이다.

8. Brownfield 프로젝트에 SDD 도입하기

8.1. 기존 코드에서 Constitution 역설계

1. 레거시 환경 만들기

   1. Agent Clinic MVP를 specs 폴더 없이 main 브랜치에서 새 Claude Code 세션으로 열어 기존 코드베이스처럼 만든다.
   2. readme.md에는 프로젝트 배경을, to-do.md에는 미완료 작업을 기록한다.
   3. 실제 레거시 프로젝트라면 이슈 트래커, 스프레드시트, 워드 문서에 제품 계획이 흩어져 있을 수 있다.

2. 기존 산출물 탐색

   1. Greenfield와 거의 같은 Constitution 프롬프트를 사용하되 roadmap 항목을 기존 파일과 산출물에서 찾으라고 지시한다.
   2. 에이전트는 코드·파일 구조·커밋·문서를 탐색하며 이미 존재하는 설계 결정을 역설계한다.
   3. 새 Constitution은 과거에 만들어진 코드와 앞으로 에이전트가 만들 코드를 같은 방향으로 정렬한다.
   4. 성능 개선이나 높은 요청량의 기능처럼 추가로 알고 있는 맥락을 프롬프트에 더하면 역설계 결과가 풍부해진다.

8.2. 레거시 프로젝트의 Feature Loop

1. Constitution 산출물

   1. Mission에는 대상 사용자, 프로젝트 아이디어, 추가 배경을 기록한다.
   2. Tech Stack에는 프로젝트 파일 구조, 프레임워크 버전, 에이전트가 확인한 질문과 답을 정리한다.
   3. Roadmap은 to-do.md의 작업을 단계별 phase로 대응시킨다.
   4. 생성된 Constitution 파일을 커밋해 레거시 프로젝트를 SDD 기반 위에 올린다.

2. 이후 작업

   1. Roadmap의 다음 항목인 phase one feedback form을 선택해 별도 브랜치에서 Plan·Requirements·Validation을 만든다.
   2. 스펙을 검토하고 커밋한 뒤 에이전트에게 구현을 요청한다.
   3. 사람이 기능 동작과 코드 품질을 검증하고, feature branch를 커밋해 main에 병합한다.
   4. SDD를 새로 도입한 직후에는 튜닝할 규칙과 문서가 많이 발견되므로 replanning 시간을 충분히 둔다.
   5. 수동으로 전체 프로젝트를 다시 쓰지 않아도 단계별로 문서화된 개발 흐름과 통제권을 확보할 수 있다.
   6. 스펙은 레거시 프로젝트의 기억이 되어 시간이 지나도 과거의 의도가 사라지지 않게 한다.

9. 스킬·CLI·MCP·플러그인으로 SDD 자동화하기

9.1. Feature Spec Skill 만들기

1. 반복 프롬프트의 자동화

   1. 기능 스펙을 시작할 때마다 “이 일을 하고, 저 일을 하고, 세 파일을 작성하라”는 같은 프롬프트를 반복할 필요가 있다.
   2. 에이전트의 skill creator와 대화해 이 과정을 하나의 스킬로 포장한다.
   3. 커뮤니티가 제공하는 스킬을 설치해 사용할 수도 있지만, 조직의 규칙과 프로젝트의 파일 위치에 맞춘 자체 스킬이 더 적합할 수 있다.

2. 스킬의 위치와 호출

   1. 스킬은 프로젝트 전용 디렉터리나 전역 디렉터리에 저장할 수 있다.
   2. 프롬프트에서 스킬 이름을 먼저 언급한 뒤 해야 할 일을 적으면 의도한 스킬의 사용을 명확히 유도할 수 있다.
   3. 하나의 스킬이 다른 스킬을 호출하도록 구성할 수도 있다.
   4. 에이전트는 스킬 설명을 읽고 필요할 때 선택하는 progressive disclosure를 사용하지만, 컨텍스트가 커질수록 판단이 항상 정확하지는 않다.
   5. 사용할 스킬을 알고 있다면 파일 태깅처럼 이름을 직접 지정하는 편이 에이전트의 추론 토큰과 불확실성을 줄인다.
   6. /clear 같은 slash command가 스킬로 대체되는 흐름도 나타나고 있다.

9.2. MCP에서 CLI와 스킬 조합으로 이동하기

1. 외부 지식 접근

   1. 에이전트가 패키지의 최신 문서나 외부 지식이 필요할 때 전통적으로 MCP(Model Context Protocol) 서버를 사용했다.
   2. Context7은 설치된 패키지의 최신 문서를 에이전트 컨텍스트에 공급하는 대표적인 선택지다.
   3. 최신 React 버전처럼 현재의 기술 스택 정보를 확보하면 오래된 지식에 기반한 구현을 줄일 수 있다.

2. CLI + Skill 패턴

   1. Context7도 MCP 서버 대신 CLI(Command Line Interface)와 스킬을 결합해 같은 목적을 달성하는 방식을 제안한다.
   2. Claude Code에 Context7 패키지를 설치할 때 MCP 서버와 CLI+Skills 중 후자를 선택한다.
   3. 계정을 만들고 로그인한 뒤 예시 프롬프트에서 Context7을 호출하면 에이전트가 기술 스택 정보를 조회한다.
   4. CLI 도구는 실제 행동을 수행하면서 설치와 컨텍스트 사용량을 줄일 수 있어 MCP 서버보다 단순할 때가 있다.
   5. MCP가 사라진다는 뜻이 아니라, 반복 가능한 작업과 외부 도구 접근을 스킬과 CLI로 구현하려는 흐름이 강해지고 있다는 뜻이다.

9.3. 플러그인과 보안

1. 공유와 배포

   1. 스킬과 워크플로를 여러 기기·팀원·외부 사용자와 공유하려면 에이전트의 확장 패키지가 필요하다.
   2. Claude Code의 플러그인은 설치·업데이트 가능한 에이전트 확장 모음이며 SDD 생산성을 높일 수 있는 무료 플러그인이 늘고 있다.

2. 신뢰 경계

   1. 플러그인은 아직 에이전트 간 공통 표준이 아니다.
   2. 앱이나 의존성과 마찬가지로 코드를 실행할 수 있으므로 설치·업데이트 전에 제공자를 신뢰할 수 있는지 확인한다.

9.4. Spec Kit과 OpenSpec

1. GitHub Spec Kit

   1. GitHub의 Spec Kit은 에이전트와 함께 사용하는 SDD 워크플로를 공식화하려는 시도다.
   2. 프로젝트에 설치하면 constitution, plan, tasks, implement 같은 slash command를 제공한다.
   3. 브랜치 관리, 검증 스크립트, 의견이 반영된 스펙 문서 형식을 함께 제공한다.

2. OpenSpec

   1. Fission AI의 OpenSpec은 propose, explore, apply, archive 흐름을 사용한다.
   2. propose와 explore는 계획 단계, apply는 구현 단계, archive는 replanning 단계에 대응한다.
   3. 빠른 기능을 위한 표준 패턴을 제공해 팀이 SDD를 처음 도입할 때 참고점이 된다.
   4. 두 도구를 그대로 따르기보다 오픈소스 워크플로를 실험하고 자신의 팀과 프로젝트에 맞게 개선한다.

9.5. 연구 아이디어를 백로그로 보존하기

1. 작업 브랜치를 방해하지 않는 연구

   1. 기능을 구현하는 중 데이터베이스 선택 같은 새로운 아이디어가 생기면 현재 작업을 멈추지 않고 별도의 대화로 조사한다.
   2. 아직 결정하지 않은 아이디어를 roadmap에 곧바로 넣으면 제품 계획이 오염될 수 있다.
   3. 조사 중 생각이 바뀌더라도 좋은 질문과 추천을 잃지 않도록 에이전트에게 잘 알려진 위치에 보고서를 저장하게 한다.

2. 연구 보고서의 활용

   1. 보고서는 대화와 조사 결과를 남기는 기록이 된다.
   2. 나중에 에이전트에게 해당 파일을 연결해 roadmap의 정식 작업으로 예약하도록 요청할 수 있다.
   3. 연구가 반복되면 조사 과정 자체를 스킬로 자동화할 수 있다.
   4. 결정 전 탐색과 결정 후 스펙을 분리하면 아이디어를 보존하면서 제품 로드맵의 안정성을 유지할 수 있다.

10. 에이전트·IDE 독립성과 표준

10.1. 표준이 필요한 이유

1. 변화가 빠른 에이전트 시장

   1. 모델과 에이전트의 성능은 빠르게 바뀌므로 특정 도구 하나에 전체 개발 프로세스를 묶으면 교체 비용이 커진다.
   2. SDD는 구현 도구보다 높은 수준에서 작동해 에이전트와 IDE가 바뀌어도 미션·로드맵·feature spec을 유지할 수 있다.
   3. 에이전트 선택은 빠르게 변하는 벤치마크 순위보다 자신에게 중요한 품질·비용·통합·보안 기준으로 판단한다.

2. 상호운용 표준

   1. MCP는 외부 도구와 에이전트를 연결한다.
   2. **agents.md**는 에이전트에 프로젝트 규칙을 전달한다.
   3. Agent Skills는 반복 가능한 워크플로와 추가 맥락을 캡슐화한다.
   4. **ACP(Agent Client Protocol)**는 에이전트와 클라이언트를 연결한다.

10.2. Codex와 OpenCode로 워크플로 이동하기

1. Codex에서 같은 스킬 실행

   1. WebStorm·Claude Code에서 만든 Feature Spec Skill을 Codex로 옮기면 Codex의 다른 저장 경로에서도 같은 workflow가 동작한다.
   2. 한 프로젝트에서 에이전트를 오가며 작업해도 SDD의 Constitution과 feature loop를 유지할 수 있다.
   3. Codex는 데스크톱 앱·에디터·터미널에서 실행할 수 있는 에이전트 사례다.

2. ACP와 IDE 연결

   1. 에이전트와 클라이언트가 ACP를 지원하면 서로 다른 편집기와 에이전트를 플러그 앤 플레이 방식으로 연결할 수 있다.
   2. ACP는 편집기의 LSP(Language Server Protocol)와 유사한 방식으로 설계됐으며 next-edit suggestion과 plan mode 같은 기능도 다룬다.
   3. ACP Registry는 에이전트의 검색·설치·연결 수명 주기를 자동화한다.
   4. JetBrains IDE의 AI Chat 창에서 ACP Registry의 호환 에이전트를 확인할 수 있다.
   5. OpenCode를 설치하면 필요한 경우 에이전트 자체 설치와 IDE 통합을 함께 자동화해 같은 편집기에서 여러 에이전트를 사용할 수 있다.
   6. 로컬에 직접 만든 custom agent를 설치해 ACP를 확장할 수도 있다.

3. 도구 독립성의 결론

   1. 같은 스펙과 스킬이 Claude Code에서 Codex로 이동해도 작동하면 SDD workflow가 특정 에이전트에 묶이지 않았다는 증거가 된다.
   2. 표준이 늘어날수록 에이전트 교체와 IDE 교체의 유연성이 커진다.
   3. 무엇을 쓰는지보다 무엇을 왜 만들고 어떤 기준으로 검증하는지를 문서화한 스펙이 오래 남는다.

주요 발언 모음

“에이전트는 근육이고 스펙은 두뇌다.”

“스펙은 무엇과 왜를 구현 방법과 분리하는 사람과 에이전트 사이의 계약이다.”

“에이전트가 20~30분 동안 일할 때, 먼저 3~4분 동안 명확한 지침을 쓰는 편이 낫다.”

“사람은 건축가처럼 설계하고 감독하며, 시공자의 모든 작업 방법까지 지시하지 않는다.”

“작은 단계로 가야 검토가 가능하고, 천천히 가야 빨리 갈 수 있다.”

“오늘 작성한 스펙은 내일 프로젝트의 기억이 된다.”

“가장 좋은 코드는 좋은 스펙에서 시작한다.”

핵심 데이터 & 사실

• 재생 시간: 1시간 1분 33초 분량의 풀코스 강의다.
• 기능 변경의 증폭: “SQLite + Prisma ORM” 같은 한 문장이 수백 줄의 코드 방향을 결정할 수 있다.
• 에이전트 작업 시간: 에이전트가 20~30분 동안 수행하는 작업은 전통적 개발자의 여러 시간에 해당할 수 있다.
• 모바일 사용자 비율: 제품 관리자가 사용자 40%가 모바일에 있다는 사실을 알려 반응형 디자인을 로드맵과 스펙에 반영한다.
• 프로젝트 수명: Constitution은 Greenfield의 초기 설계뿐 아니라 수년간 운영된 Brownfield 코드베이스에도 역설계 방식으로 적용된다.
• 대표 문서: mission.md, techstack.md, roadmap.md가 프로젝트 수준 기준을 구성한다.
• 기능 문서: Plan, Requirements, Validation 세 문서가 기능의 계획·요구·검증 계약을 이룬다.
• 핵심 테스트: 테스트는 실행 결과를 확인하는 도구이면서 사람이 코드 흐름을 이해해 인지 부채를 줄이는 탐색 도구다.

결론 및 시사점

1. 의도부터 고정한다: 에이전트의 코드 생성 속도보다 프로젝트의 미션·사용자·성공 조건·제약을 먼저 문서화한다.
2. Constitution을 버전 관리한다: Mission·Tech Stack·Roadmap을 코드와 함께 커밋해 프로젝트의 장기 기억으로 유지한다.
3. 기능을 작은 루프로 나눈다: 별도 브랜치에서 Plan→Implement→Validate를 반복하고 기능 사이에 Replan한다.
4. 사람의 역할을 재정의한다: 사람은 저수준 코드를 직접 타이핑하는 비중을 줄이고 아키텍처·맥락·검증·인수 판단에 집중한다.
5. 검토 가능한 크기를 유지한다: AI Fatigue와 Cognitive Debt를 줄이려면 작은 task group, 작은 변경, 잦은 커밋이 필요하다.
6. 문서와 코드를 함께 수정한다: 코드만 고치면 스펙·README·로드맵이 드리프트하므로 에이전트에게 모든 관련 산출물의 동기화를 요청한다.
7. 검증을 능동적으로 수행한다: 테스트 실행, 디버거 탐색, 브라우저 확인, 서브에이전트 심층 리뷰로 에이전트의 결과를 독립적으로 확인한다.
8. 발견한 결정을 스펙에 기록한다: 최초 요구사항에 없던 세부 결정도 작업 중 스펙에 반영하면 다음 결과의 품질이 높아진다.
9. Greenfield와 Brownfield를 구분하지 않는다: 기존 코드·문서·커밋을 탐색해 Constitution을 역설계하면 레거시에도 SDD를 도입할 수 있다.
10. 반복 가능한 작업은 스킬로 만든다: Change Log, Validation, Feature Spec, Research 같은 반복 프로세스를 프로젝트 또는 전역 스킬로 패키징한다.
11. 외부 지식 접근을 단순화한다: MCP 서버뿐 아니라 CLI와 스킬 조합을 활용해 최신 문서 조회와 실제 행동을 효율적으로 연결한다.
12. 도구 교체를 전제로 한다: MCP, agents.md, Skills, ACP 같은 표준을 활용해 Claude Code·Codex·OpenCode와 여러 IDE 사이에서 workflow를 이동시킨다.
13. 에이전트를 신뢰하되 책임을 넘기지 않는다: 에이전트의 제안은 선택지를 넓히는 재료이고, 최종 아키텍처·보안·품질·병합 결정은 사람의 책임이다.
14. 스펙은 장기 경쟁력이다: 모델과 도구가 바뀌어도 잘 작성된 스펙은 프로젝트의 방향과 팀의 합의를 보존한다.

핵심 요약 (20줄)

1. 스펙 주도 개발은 AI 에이전트에게 무엇과 왜를 먼저 전달해 빠른 코드 생성과 장기적인 엔지니어링 통제를 결합한다.

2. 한 문장의 기술 결정은 수백 줄의 코드에 증폭되므로 코드보다 스펙을 고치는 편이 큰 변경을 효율적으로 통제한다.

3. Constitution은 프로젝트의 미션·기술 스택·로드맵을 기록해 사람과 에이전트의 공통 기준을 만든다.

4. 스펙은 세션과 에이전트를 넘어 비협상 조건을 보존해 컨텍스트 붕괴와 의도 이탈을 줄인다.

5. 사람은 수석 아키텍트로서 목표·사용자·제약을 제공하고 에이전트는 구현과 도구 실행을 담당한다.

6. Vibe Coding의 짧은 프롬프트와 반복 수정은 작은 작업에는 맞지만 대형 프로젝트에서 일회용 코드와 기술 부채를 키울 수 있다.

7. 기능은 별도 브랜치에서 계획·구현·검증하는 Feature Loop로 처리해 변경량과 검토 범위를 작게 유지한다.

8. Plan·Requirements·Validation 문서는 기능의 접근법·필수 조건·성공 판정 방법을 일관되게 연결한다.

9. 에이전트가 만든 코드의 오류가 계획의 누락에서 비롯되면 계획과 구현을 함께 수정해야 같은 문제가 반복되지 않는다.

10. 테스트와 디버거는 기능 동작을 확인하는 수단이면서 사람이 코드 흐름을 이해해 인지 부채를 줄이는 도구다.

11. 기능 사이의 Replanning은 Constitution·로드맵·테스트 정책·개발 프로세스를 현실에 맞게 갱신한다.

12. 모바일 사용자 40%라는 제품 정보처럼 새로운 결정은 제품 스펙·기능 스펙·코드에 동시에 반영한다.

13. Agent Clinic은 Next.js·React·TypeScript·SQLite로 AI 에이전트의 환각과 컨텍스트 문제를 치료하는 실습용 애플리케이션이다.

14. 두 기능을 구현한 뒤 남은 로드맵을 한 번에 구현하는 MVP 실험은 Constitution과 스펙의 품질을 시험하는 극한 테스트가 된다.

15. 기존 코드베이스도 코드·README·할 일 목록·커밋을 탐색해 Constitution을 역설계하면 SDD 기반으로 전환할 수 있다.

16. Change Log와 Validation 같은 반복 업무는 Agent Skill로 패키징해 프로젝트와 조직 전반의 프로세스를 자동화할 수 있다.

17. 사용할 스킬은 이름을 직접 지정해야 에이전트의 progressive disclosure 판단 오류와 불필요한 추론을 줄일 수 있다.

18. MCP 서버와 CLI·스킬 조합은 최신 패키지 문서를 에이전트에 공급하며 외부 지식 접근과 실제 행동을 연결한다.

19. Spec Kit·OpenSpec·MCP·agents.md·Skills·ACP는 특정 IDE와 에이전트에 종속되지 않는 개발 워크플로를 지원한다.

20. 좋은 스펙을 버전 관리하고 계속 개선하면 에이전트가 빠르게 바뀌어도 프로젝트의 기억과 사람의 통제권을 유지할 수 있다.