[한영자막] AI 에이전트와 함께하는 스펙 주도 개발 풀코스 강의

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 에이전트와 함께하는 스펙 주도 개발은 요구사항을 프로젝트의 기억으로 남기고, 계획·구현·검증·재계획을 반복해 사람이 개발의 주도권을 유지하는 방법이다.

📌 핵심 요점

1. 대화의 의도를 지속되는 명세로 바꾼다. 짧은 요청과 반복 수정은 시제품에 유용하지만, 장기 프로젝트에서는 맥락 손실과 기술 부채를 낳을 수 있다. 명세에 문제·대상 사용자·성공 기준·제약을 기록하면 세션이 바뀌어도 핵심 결정을 이어갈 수 있다.
2. 프로젝트 헌장과 기능 명세를 구분한다. 헌장은 미션·기술 스택·로드맵을 담고, 기능 명세는 계획·요구사항·검증 기준을 구체화한다. 구현 전에 명세를 검토하고 커밋하며, 기능별 브랜치에서 변경을 관리한다.
3. 검증 결과를 코드와 스펙에 함께 반영한다. Agent Clinic 실습에서는 레이아웃 누락, 테스트 의존성과 실제 테스트의 부재, 반응형 요구를 발견하며 문서와 구현을 보완한다. 에이전트의 자체 검증 이후에도 사람이 실행 결과와 변경 내용을 확인해야 한다.
4. 변경량과 인지 부채를 관리한다. 기능 사이에 재계획 시간을 두고, 사람이 이해하고 검토할 수 있는 단위로 작업한다. 남은 로드맵 전체를 MVP로 구현하는 실험은 스펙을 신뢰하고 결과를 검증할 여력이 있을 때 선택한다. 기존 프로젝트도 코드·README·TODO에서 헌장과 로드맵을 복원해 같은 순환을 적용할 수 있다.
5. 반복 절차를 자동화하되 도구 교체 가능성을 확보한다. 기능 명세 작성, 변경 이력, 검증 절차를 스킬로 만들고 필요할 때 이름을 명시해 호출한다. GitHub Spec Kit·OpenSpec 같은 워크플로와 MCP·ACP 등의 연결 방식을 활용하며, 실습에서는 스킬 이식과 편집기 통합으로 에이전트를 바꿔도 개발 절차를 이어간다.

🧩 배경과 문제 정의

• AI 코딩 에이전트에 짧은 요구만 전달하고 결과를 반복 수정하는 방식은 빠른 시제품 제작에는 유용하지만, 복잡한 장기 프로젝트에서는 기술 부채와 구현 방향의 충돌을 낳을 수 있다.
• 에이전트는 제품의 목적, 조직의 기술 선택, 대상 사용자 같은 고유 맥락을 알지 못한다. 대화가 길어지거나 세션이 바뀌어도 유지할 요구사항과 제약을 명세로 남겨야 한다.
• 스펙 주도 개발은 프로젝트 공통 원칙과 기능별 명세를 바탕으로 계획·구현·검증을 반복한다. 사람은 주요 의사결정과 결과 검토를 맡고, 에이전트는 명세에 따라 구현한다.
• 실습은 패러디 웹 애플리케이션인 Agent Clinic을 대상으로 환경 설정, 프로젝트 원칙 수립, 첫 기능 구현과 검증, 재계획의 시작까지 다룬다.

🕒 시간순 섹션별 상세정리

1. 명세로 구현을 제어하고 핵심 결정을 보존한다

• 스펙 주도 개발에서는 만들 대상을 Markdown 파일이나 상세한 프롬프트로 정의한다. 사람의 작업 중심은 직접 코드를 작성하는 일에서 에이전트가 모르는 맥락을 기록하는 일로 옮겨간다 [00:09]
• “SQLite와 Prisma ORM을 사용한다” 같은 한 문장이 수백 줄의 코드에 영향을 줄 수 있다. 명세는 작은 수정으로 큰 구현 변경을 제어하고, 세션 사이의 맥락 손실을 줄이며, 문제·성공 기준·제약을 통해 의도에 맞는 결과를 유도한다 [00:40]

2. 프로젝트 공통 원칙과 기능별 반복 작업을 분리한다

• 프로젝트 헌장(constitution)은 공통으로 지켜야 할 기준을 정의한다. 각 기능은 별도 브랜치에서 계획·구현·검증을 거쳐 작업 맥락을 정리하고 다음 기능으로 넘어간다 [02:29]
• 신규 프로젝트에서는 에이전트와 대화하며 헌장을 만들고, 기존 프로젝트에서는 코드베이스를 바탕으로 생성한다. 두 경우 모두 작은 단위로 버전을 관리하며 기능 개발을 반복할 수 있다 [02:52]

3. 반복 대화에 의존하는 바이브 코딩의 한계

• 버튼을 만들어 달라는 요청 뒤 결과를 보고 계속 수정하는 방식은 작은 작업에는 통하지만, 긴 대화 기록에 의존하므로 지속적인 대규모 프로젝트로 확장하기 어렵다 [04:32]
• 높은 수준의 짧은 요청은 빠르지만 일회성 코드와 기술 부채로 이어질 수 있다. 유지·관리되는 명세는 대화에 흩어진 의도를 지속적으로 활용할 기술 산출물로 남긴다 [05:03]

4. 변경 효율·맥락 유지·의도 일치가 핵심 효과다

• 앱의 외형과 분위기를 설명한 몇 문장이 수백 줄의 CSS로 이어질 수 있다. 명세 수준에서 변경을 제어하면 매우 빠르게 코드를 생성하는 에이전트를 관리하는 인지 부담을 줄일 수 있다 [05:55]
• 대화가 길어져 컨텍스트 창이 차면 에이전트의 실수가 늘어날 수 있다. 명세는 세션과 에이전트가 바뀌어도 남아 코드베이스와 기능 구현에 필요한 핵심 맥락을 유지한다 [06:21]

5. 에이전트에는 도구를, 사람에게는 설계 판단을 맡긴다

• 컴파일러가 소스 코드를 기계어로 바꾸듯, 스펙 주도 개발에서는 명세와 프롬프트가 에이전트의 소스 코드 생성을 이끈다. 자연어 명세는 이해관계자가 내용을 이해하기에도 유리하다 [07:30]
• 이 워크플로의 에이전트는 코드베이스와 개발 도구에 접근하고 계획과 추론을 통해 작업한다. 사람은 설계도를 제공하는 아키텍트, 에이전트는 기술 지식과 구현 속도를 제공하는 페어 프로그래머 역할을 맡는다 [08:10]

6. 헌장과 계획·구현·검증·재계획의 구조

• 헌장은 미션, 기술 스택, 로드맵으로 프로젝트 수준의 결정을 구조화한다. 최상위 AGENTS.md를 활용하는 방식도 있지만, 프로젝트 헌장은 특정 에이전트에 종속되지 않으며 사람과 에이전트, 사람과 사람 사이의 합의를 담는다 [09:52]
• 미션은 비전·대상·범위를, 기술 스택은 개발·배포 기술과 제약을 정한다. 로드맵은 기능 명세 절차로 구현할 단계들의 순서를 담는 지속적으로 갱신되는 문서다 [10:26]

7. 실습 환경과 Git으로 코드·명세를 함께 관리한다

• 스펙 주도 개발은 특정 IDE나 에이전트에 묶이지 않는다. VS Code와 Codex CLI, Zed와 로컬 모델 같은 조합도 가능하며, 실습에서는 웹 앱 개발을 위해 WebStorm과 Claude Code를 사용한다 [13:07]
• Agent Clinic은 TypeScript 프로젝트로 시작하고 Git 저장소를 만들어 코드와 명세의 버전을 추적한다 [13:43]

8. Agent Clinic의 목적과 기술 선택을 헌장으로 구체화한다

• 프로젝트의 핵심 아이디어, 조직의 기술 스택, 예정 기능은 향후 개발과 이해관계자의 이해를 이끄는 공통 요구사항이다. 기술 선택은 조직의 기존 환경과 절충안을 고려해 기록하고, 에이전트와의 대화로 대안과 놓친 질문을 검토한다 [14:59]
• Agent Clinic은 Pet Clinic을 패러디한 앱으로, AI 에이전트의 환각·맥락 부패·기억 문제·하위 에이전트 협업 부담을 진료 대상으로 설정한다 [16:20]

9. 질문과 검토를 거쳐 헌장 문서를 완성한다

• 프로젝트 설명과 저장소의 readme.md에 담긴 이해관계자 의견을 제공하고, 미션·기술 스택·로드맵을 함께 작성하도록 요청한다. 사람이 작은 변경을 검토할 수 있도록 로드맵도 작은 단계로 나눈다 [17:15]
• 초기 질문에서는 미션의 장난스러운 어조, 팀이 익숙한 백엔드 TypeScript 사용, 로드맵의 세분화 수준을 결정한다. 작성 결과는 specs 디렉터리의 mission.md, techstack.md, roadmap.md에 저장된다 [18:02]

10. 첫 기능은 새 맥락과 별도 브랜치에서 계획한다

• 로드맵의 첫 기능은 ‘Hello Hono’다. 구현 전에 접근 방식, 작업 순서, 성공 검증 방법을 명확히 하는 기능 명세가 필요하다 [20:12]
• 새 에이전트 맥락에서 헌장을 공식 정보원으로 사용하고 별도 기능 브랜치에서 작업한다. 기능 명세에는 작업 계획, 요구사항, 검증용 평가 기준을 포함한다 [20:41]

11. 기능 명세의 계획·요구사항·검증 기준을 함께 수정한다

• 초기 계획을 검토하면서 보기 좋은 임시 홈페이지를 첫 기능에 추가한다. 수정은 에이전트를 통해 진행해 요구사항과 검증 문서도 함께 맞춘다 [21:41]
• 요구사항에는 중요한 기술적 필요와 제약을 적되 변수 이름 같은 사소한 구현 세부사항까지 지정하지 않는다. 검증 기준은 에이전트가 결과의 정확성을 확인할 수 있어야 한다 [22:13]

12. 명세를 바탕으로 구현하고 실행 결과를 확인한다

• /clear로 대화 맥락을 비운 뒤 명세의 전체 작업 그룹을 구현하도록 요청한다. 보안이나 데이터베이스처럼 작은 오류가 뒤에서 누적될 수 있는 영역은 작업 그룹별로 구현하고 커밋하는 방법도 유용하다 [23:37]
• 구현 중 콘솔의 변경 내용과 이후 커밋 창의 차이를 확인하면 검토를 일찍 시작할 수 있다. 개발자는 명확한 계약을 제공하고 결과를 감독하는 역할을 맡는다 [24:05]

13. 검증에서 발견한 누락은 명세와 구현을 함께 고친다

• 병합 전에는 변경 사항이 실제로 동작하고 명세에 부합하는지 검토한다. 개별 CSS 클래스 같은 세부 구현보다 기능 수준의 문제에 집중한다 [25:14]
• 최소한으로 구현된 홈페이지에는 헤더·메인·푸터 하위 컴포넌트로 구성한 레이아웃과 CSS 파일이 필요했다. 이는 계획에서 요구하지 않은 사항이므로 명세와 구현을 함께 수정한다 [25:47]

14. 직접 수정한 코드도 문서와 동기화하고 병합한다

• 수정 결과에는 기능 계획의 다섯 번째 작업 그룹, 레이아웃 컴포넌트, CSS 파일이 추가된다. 같은 파일에 들어간 세 하위 컴포넌트는 관례에 맞게 IDE 이동 도구로 별도 파일로 분리한다 [27:09]
• IDE로 직접 수정하면 명세와 README 등 다른 산출물이 코드와 어긋날 수 있으므로 에이전트에 관련 언급의 갱신을 요청한다. 이 시점에는 테스트 패키지가 설치되지 않았으며, 모든 기능에 필요한 문제로 다음 단계에서 다룬다 [27:53]

15. 테스트 정책의 누락을 프로젝트 재계획으로 보완한다

• 첫 기능을 구현하고 검증한 뒤에는 다음 기능으로 바로 넘어가기보다 프로젝트 전체를 재검토한다. 검증에 테스트가 유용하지만, 기존 헌장에는 개발자가 원하는 테스트 방식이 충분히 전달되지 않았다 [29:14]
• 테스트 관련 기술 스택을 보완하기 위해 재계획 브랜치를 만든다. 헌장을 별도 브랜치에서 갱신하면 어떤 헌장 버전이 어떤 코드를 만들어 냈는지 추적하기에 유리하다 [29:37]

16. 테스트 정책을 기존 스펙과 실제 검증에 반영하기

• 에이전트는 package.json에 스크립트만 추가하고 의존성은 추가하지 않았다. 테스트 프레임워크 도입 정책이 향후 코드에만 적용되지 않도록 기존 기능 스펙과 구현도 수정해야 한다 [30:05]
• 테스트 환경을 설정하는 것과 테스트를 작성하는 것은 별개다. 두 차례 프롬프트 이후에도 테스트 자체는 없어서 추가 작성을 요청한다 [30:30]

17. 반응형 요구 반영과 로드맵 재조정

• 사용자 중 40%가 모바일을 사용한다는 제품 담당자의 요구에 따라 반응형 디자인을 강화한다. 제품 스펙, 기능 스펙, 코드를 함께 수정하며, 초기 개발의 작은 변경은 재계획 중 바로 구현하되 큰 작업은 별도 기능 단계로 로드맵에 배치한다 [31:17]
• 스펙에도 결정 사항을 기록하고 코드와 동기화해야 팀이 같은 맥락을 공유할 수 있다. 수정된 문서와 코드의 차이를 검토하고 작은 단위로 자주 커밋하면 검토 부담을 줄일 수 있다 [31:57]

18. 변경 이력과 검증 절차를 스킬로 자동화하기

• 재계획은 개별 기능뿐 아니라 프로젝트와 조직의 개발 절차를 개선하는 기회다. 비기술 이해관계자에게 진행 상황을 전달하는 변경 이력 갱신처럼 반복 가능하고 프로젝트 맥락이 필요한 작업은 스킬로 만들기 적합하다 [33:09]
• 스킬의 적용 범위는 프로젝트 전용인지 전체 프로젝트 공통인지 판단해야 한다. README 갱신, 린트, 포맷팅, 테스트 실행과 품질 확인도 하나의 검증 스킬로 묶어 수작업을 줄일 수 있다 [34:15]

19. 기능 경계를 정리하고 다음 기능의 의도를 명세하기

• 대량의 코드 변경은 사람의 검증을 지치게 한다. 기능을 시작하기 전에 미완료 작업, 이전 브랜치 병합 여부, 다음 로드맵 항목을 확인하고 에이전트 문맥을 초기화하면 스펙에 의도를 남기면서 다음 작업에 문맥 예산을 집중할 수 있다 [36:01]
• 다음 기능에서는 앞서 합의한 여러 기능의 일괄 처리를 유지하고 마이그레이션에 일반 SQL을 선택한다. 에이전트의 질문과 명세 초안을 통해 구체적인 구현 선택을 확인한다 [37:08]

20. 상위 요구사항 중심의 검토와 스펙 보완

• 구현 진행을 지켜본 것만으로 충분히 검토했다고 볼 수는 없다. 변경 내용을 깊이 살피되 변수명 같은 세부 사항에 과도하게 집중하기보다 상위 요구사항과 자신의 이름으로 커밋할 수 있는 품질을 기준으로 판단한다 [38:54]
• 인라인으로 작성된 props 타입을 독립된 TypeScript 타입으로 분리하도록 코드 전반의 수정을 요청한다. 처음 스펙에 이 기준이 없었다는 사실은 실패가 아니라, 새로 발견한 세부 결정을 스펙에 반영해 이후 결과를 개선할 기회다 [39:29]

21. 실행 검증과 이해 확인, 서브에이전트의 재검토

• 기능 스펙의 검증 계획을 확인하고 애플리케이션을 실행해 동작을 검증한다. 동시에 인지 부채를 막기 위해 변경을 이해했는지도 확인하며, 테스트를 읽고 디버거로 실행하는 방법을 활용한다 [40:11]
• 여러 서브에이전트가 기능 변경을 포함한 프로젝트 전체를 깊이 검토하도록 한다. 별도 문맥에서 검토하면 주 에이전트의 문맥 창을 보존하면서 문제와 개선안을 찾을 수 있고, 이 사례에서는 후속 수정과 테스트로 계속된다 [40:50]

22. 남은 로드맵을 MVP로 구현해 스펙의 빈틈 확인하기

• 두 기능을 구현한 뒤 남은 로드맵 전체를 MVP로 구현하는 실험을 진행한다. 이런 대규모 작업은 헌법 문서와 스펙의 품질을 신뢰하고, 결과를 검토·검증할 여력이 있을 때만 선택해야 한다. 의도와 다른 결과가 나오면 에이전트를 잘못 이끈 원인을 재계획으로 바로잡아야 한다 [42:46]
• 질의응답으로 MVP 스펙을 작성한 뒤 계획·요구사항·검증 문서를 확인한다. 에이전트가 빈칸을 채우며 잘못 가정한 부분을 찾아내고, 구현 전에 스펙을 커밋한다 [43:50]

23. 기존 코드와 문서에서 SDD 기반 복원하기

• 기존 Agent Clinic MVP에서 스펙 폴더를 제외하고 다른 프로젝트 디렉터리의 새 세션으로 시작해 레거시 프로젝트 상황을 구성한다. README에는 배경 정보가, TODO 문서에는 남은 작업이 있으며, 실제 프로젝트에서는 이슈 추적기나 스프레드시트 등도 근거가 될 수 있다 [45:51]
• 에이전트가 기존 코드와 문서에서 헌법 문서와 로드맵을 역으로 도출하도록 한다. 이 기반은 앞으로 생성할 코드가 기존 구현과 맞도록 돕고, 성능 개선이나 요청이 많은 기능처럼 추가 목표가 있다면 함께 제공할 수 있다 [46:38]

24. 레거시 프로젝트에도 같은 기능 개발 순환 적용하기

• SDD 기반을 마련한 뒤에는 새 프로젝트와 같은 절차를 적용한다. 첫 단계인 피드백 폼을 에이전트와 계획하고, 기능 브랜치와 계획·요구사항·검증 스펙을 만들어 검토 후 커밋한다 [48:13]
• 대화로 필요한 수정을 반영한 뒤 구현하고, 코드 품질과 기능 동작을 검증해 커밋과 메인 브랜치 병합을 완료한다 [48:59]

25. 반복 프롬프트를 스킬로 만들고 명시적으로 호출하기

• 기능 스펙을 시작할 때마다 반복하는 지시와 세 문서 작성 절차는 스킬로 자동화할 수 있다. 스킬 생성 도구와 질의응답으로 요구를 정리하되, 생성 과정에서도 에이전트가 원하는 선택을 하는지 확인한다 [50:11]
• 스킬은 프로젝트별 또는 전역으로 둘 수 있고, 프롬프트에서 직접 언급하거나 다른 스킬에서 호출할 수도 있다. 에이전트가 설명을 보고 자동 선택하는 판단은 특히 문맥이 커질수록 완벽하지 않으므로, 사용할 스킬이 정해져 있다면 이름을 명시한다 [51:07]

26. 외부 자료 접근을 MCP 또는 CLI와 스킬로 구성하기

• API, 비공개 지식 기반, 데이터베이스 같은 외부 자원 접근에는 MCP가 활용된다. Context7은 패키지의 최신 문서를 에이전트 문맥에 제공하는 사례다 [52:13]
• CLI를 호출하는 스킬도 같은 목적을 수행할 수 있다. Context7 설치에서는 MCP 서버와 CLI·스킬 조합 중 후자를 선택하고, 계정 설정 후 예시 프롬프트로 기술 스택 정보를 찾는 기능을 확인한다 [52:49]

27. 플러그인과 기존 SDD 프레임워크 활용하기

• 작업 절차를 여러 기기와 팀에 공유할 때 플러그인으로 확장 기능을 묶어 설치·갱신할 수 있다. 다만 플러그인은 아직 에이전트 간 공통 표준이 아니며 코드를 실행할 수 있으므로 설치와 업데이트 시 신뢰 여부를 확인해야 한다 [54:04]
• GitHub Spec Kit은 헌법·계획·작업·구현 명령으로 SDD 절차를 정형화한다. OpenSpec의 제안·탐색·적용·보관 절차도 각각 계획·구현·재계획 단계와 연결되며, 작은 기능을 위한 패턴도 제공한다 [54:43]

28. 확정되지 않은 아이디어를 연구 백로그로 보존하기

• 기능 개발 중 데이터베이스 선택 같은 아이디어를 조사하더라도, 아직 채택하지 않았다면 바로 로드맵에 넣을 필요는 없다. 기존 브랜치 작업을 유지하면서 에이전트와 가능성을 탐색할 수 있다 [55:40]
• 대화에서 얻은 질문과 권고, 판단 결과는 정해진 위치의 연구 보고서로 남긴다. 나중에 해당 파일을 링크해 로드맵에 반영할 수 있고, 연구가 반복되면 그 과정도 스킬로 자동화할 수 있다 [55:59]

29. 공통 표준과 스킬 이식으로 에이전트 교체하기

• SDD는 작업의 초점을 구현 방법에서 무엇을 왜 만들지로 옮긴다. 에이전트와 모델이 빠르게 바뀌므로 작업 절차를 하나의 도구에만 종속시키지 않는 것이 목표다 [56:54]
• MCP는 외부 도구 연결, AGENTS.md는 규칙, 에이전트 스킬은 추가 맥락이 필요한 반복 절차, ACP는 에이전트와 클라이언트 연결을 담당하는 표준으로 구분된다 [57:14]

30. ACP로 편집기와 에이전트를 연결하고 선택 폭 넓히기

• 에이전트와 편집기가 모두 ACP를 지원하면 서로 연결할 수 있다. ACP 레지스트리는 클라이언트 안에서 에이전트를 찾고 설치하고 연결하는 과정을 자동화한다 [58:03]
• JetBrains IDE에서는 호환 에이전트 목록에서 OpenCode를 선택해 설치와 IDE 통합을 진행한다. 통합 후에는 같은 편집기 안에서 다른 에이전트와 함께 SDD 작업에 사용할 수 있다 [58:35]

31. 에이전트와 IDE에 종속되지 않는 스펙과 워크플로

• 도구에 관한 최신 정보를 확인하고, 자신에게 중요한 기준을 바탕으로 선택해야 한다 [1:00:07]
• 스펙은 특정 에이전트나 IDE에 묶이지 않는 상위 수준에서 작동하며, 개발 워크플로와 도구도 에이전트에 독립적으로 구성됐다. 더 많은 표준이 등장하면 이러한 유연성이 커질 것으로 예상된다 [1:00:24]

32. 스펙을 프로젝트의 기억으로 남기고 개발 주도권 유지하기

• 스펙 주도 개발은 에이전트가 의도대로 움직이길 기대하는 바이브 코딩보다 실제 요구에 가까운 결과를 지향한다. 이를 위해 개발 원칙을 작성하고, 대화로 기능을 계획하며, 사람이 검증에 참여하고, 스킬과 표준으로 워크플로를 자동화한다 [1:00:57]
• 오늘 작성한 스펙은 내일 프로젝트의 기억이 된다. 스펙을 명확하게 유지하고 개발 과정을 지속적으로 개선해야 하며, 좋은 코드는 좋은 스펙에서 출발한다 [1:01:10]

🧾 결론

• 스펙의 가치는 문서의 분량보다 무엇을 왜 만드는지, 어떤 제약과 기준으로 검증할지를 명확히 하는 데 있다.
• 구현 중 새로 발견한 요구와 판단은 스펙에도 반영해야 한다. 코드와 어긋난 문서는 프로젝트의 기억 역할을 유지하기 어렵다.
• 사람은 설계 판단, 결과 수용, 변경 이해를 맡는다. 코드 생성이 빨라질수록 검토 가능한 작업 크기와 재계획이 중요해진다.
• 스펙 주도 개발은 신규 프로젝트뿐 아니라 기존 코드와 문서에서 출발하는 프로젝트에도 적용할 수 있는 반복 절차다.

📈 투자·시사 포인트

• 개발 생산성을 평가할 때 생성 속도와 함께 검토 부담, 수정 비용, 맥락 유지 여부를 살펴볼 필요가 있다. 강의는 빠른 생성이 인지 부채를 늘릴 수 있음을 강조한다.
• 팀이 축적할 자산으로 명세, 검증 기준, 반복 작업 스킬이 부각된다. 도구가 바뀌어도 이 자산을 활용할 수 있는지가 운영상 중요한 판단 기준이 된다.
• 에이전트·편집기 간 연결과 스킬 이식 사례는 특정 도구에 대한 의존을 줄일 가능성을 보여준다. 다만 실제 호환성과 표준 지원 범위는 도구별로 확인해야 한다.
• 자료에는 기업 실적, 시장 규모, 투자 수익률을 판단할 근거가 없다. 투자 관점에서는 개발 도구의 업무 적용성과 전환 비용을 검토하는 참고 사례로 읽는 편이 적절하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 스펙 주도 개발의 생산성·품질 개선은 실습과 설명을 통해 제시되며, 비교 실험이나 정량 성과는 제공되지 않는다. 모든 작업에서 동일한 효과를 기대할 근거는 부족하다.
• 앞부분에는 테스트 정책의 적용 결과가 확인되지 않는다는 설명이 있으나, 뒤 구간에서는 의존성 누락 보완, 테스트 작성 요청, 실행·디버깅과 커밋까지 이어진다. 다만 구체적인 프레임워크와 정책 전문은 제공되지 않는다.
• 초기 기술 설명에는 Next.js·React가 등장하지만 첫 기능은 ‘Hello Hono’로 제시된다. 최종 기술 구성과 변경 경위는 이 요약만으로 확정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 프로젝트의 미션·대상 사용자·범위·기술 제약·로드맵을 헌장으로 정리하고, 기존 프로젝트라면 코드와 문서의 실제 상태를 대조한다.
• 다음 기능을 구현하기 전에 계획·요구사항·검증 기준을 작성하고 검토한 명세를 커밋한다.
• 기능 브랜치에서 검토 가능한 크기로 구현하고, 실행 결과와 테스트를 사람이 직접 확인한다.
• 누락된 요구나 직접 수정한 코드가 있으면 관련 스펙·README·로드맵을 함께 갱신한다.

❓ 열린 질문

• 우리 프로젝트에서 공통 헌장에 고정할 결정과 기능별로 에이전트에 맡길 구현 판단의 경계는 어디인가?
• 사람이 충분히 이해하고 검증할 수 있는 기능 크기는 어느 정도이며, 대규모 MVP 구현을 선택할 조건은 무엇인가?
• 명세 버전과 코드 변경의 대응 관계를 어떤 브랜치·커밋 규칙으로 추적할 것인가?