AI 시대의 새로운 패러다임

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 시대의 새로운 개발 패러다임인 Spec-Driven Development는 사람이 목적과 제약을 스펙으로 명확히 하고, AI가 이를 바탕으로 구현·검증하도록 개발의 중심을 옮기는 방식이다.

📌 핵심 요점

1. SDD는 무엇을 만들지 합의하는 출발점이다. 기대 동작이 명확한 작업에 적합한 TDD 앞단에서 자연어로 요구사항을 구체화하고, 이를 코드 생성과 검증의 기준으로 삼는다. 실습에서도 기존 TDD 구성을 하네스에 통합한다.
2. 좋은 스펙은 구현과 판단의 기준을 함께 담는다. 입력·출력과 관측 가능한 동작, 목적과 측정 가능한 성공 기준, 제약, 제외 범위, 엣지 케이스를 명시한다. 짧은 초안을 반복 검토하며 사용자 여정·오류 대응·인터페이스와 실행 가능한 검증 명령까지 보완한다.
3. 문서와 단계별 인수인계가 자율 실행을 뒷받침한다. PRD는 요구를, 아키텍처 문서는 구조를, ADR은 결정 이유를 보존한다. 큰 스펙은 계층화하고, 독립 세션마다 필요한 맥락과 작업을 제공하며 상태 기록과 완료 요약으로 다음 단계를 연결한다.
4. 하네스는 실행을 맡고 사람은 판단과 개선을 맡는다. 실행기는 단계별 구현·검증, 브랜치 분리, 가드레일 전달, 자가 교정, 커밋과 상태 추적을 처리한다. 사람은 설계와 계획 승인, 결과 리뷰, 안전장치 점검을 수행하고 회고를 규칙과 문서 수정으로 연결한다.
5. 실습 결과와 운영 비용을 함께 봐야 한다. 유튜브 썸네일 생성기를 로컬에서 실행하고 이미지 결과를 확인했다. 발표자는 약 30분 만에 앱을 만들었다고 평가하지만, 좋은 스펙도 무결점을 보장하지 않으며 장시간 실행·긴 컨텍스트·서브 에이전트의 토큰 비용은 별도 관리 대상이다.

🧩 배경과 문제 정의

• TDD는 버그 수정이나 작은 함수처럼 기대 동작이 명확한 작업에 잘 맞지만, 새로운 서비스나 프로젝트처럼 무엇을 만들지부터 정해야 하는 상황에서는 테스트를 먼저 작성하기 어렵다.
• Spec-Driven Development(SDD)는 자연어 스펙을 먼저 작성하고, 이를 기준으로 코드 생성과 검증을 진행하는 개발 방식이다. 모호한 요구로 인한 반복 수정을 줄이려면 목적·동작·제약·성공 기준을 구체화해야 한다.
• AI 중심 개발에서는 개발자의 역할이 코드 작성에서 설계와 판단, 결과 검토로 이동한다. AI가 알 수 없는 도메인 맥락과 의사결정 이유를 문서화하고, 실패를 다음 작업의 개선으로 연결하는 실행 환경이 중요해진다.
• 실습은 유튜브 썸네일 생성 서비스를 대상으로 짧은 요구사항을 구체적인 스펙으로 발전시키고, 하네스 프레임워크를 통해 작업을 실행하는 구조를 다룬다.

🕒 시간순 섹션별 상세정리

1. TDD의 앞단에서 무엇을 만들지 합의하는 SDD

• 테스트 없이 구현부터 작성하지 못하게 하는 TDD 가드는 기대 동작이 명확한 버그 수정이나 작은 함수에 적합하다. 새로운 도메인 모듈·SaaS·앱을 설계할 때는 무엇을 만들지 먼저 합의해야 한다 [01:53]
• SDD는 자연어 스펙을 먼저 쓰고 그 스펙으로 코드 생성과 검증을 주도한다. 좋은 스펙의 기준뿐 아니라 에이전트가 스펙을 자율적으로 실행하게 만드는 하네스도 중요하다 [02:43]

2. 코드 작성자에서 설계와 판단을 맡는 리뷰어로의 전환

• 코드보다 스펙을 먼저 작성해야 한다. 명확한 스펙은 AI의 구현 기준이 되지만, 모호한 프롬프트와 스펙은 끝없는 수정 사이클로 이어질 수 있다 [03:29]
• 개발자는 아키텍처·엣지 케이스·도메인 맥락을 판단하는 역할을 맡는다. 코딩을 AI에 위임하면서 사람이 상대적으로 더 어려운 판단에 집중하는 방향으로 역할이 이동한다 [04:08]

3. 지식 외부화와 설계 집중, 실패를 축적하는 학습 루프

• 컨벤션·워크플로우·패턴과 설계 지식은 규칙 파일이나 스킬, 문서로 외부화해야 한다. 머릿속에만 있는 지식은 AI가 작업에 활용할 수 없다 [04:33]
• AI 중심 개발에서는 스펙 설계와 출력 검토가 주요 병목이 된다. 개발자의 시간과 주의력을 작업 앞단의 설계에 더 많이 배분해야 한다 [05:18]

4. 설계부터 회고까지 이어지는 다섯 단계의 개발 루프

• 설계 단계는 사람이 주도하고 AI가 보조한다. 기술 결정·도메인 맥락·조직 제약을 PRD, 아키텍처 문서, ADR로 남겨 AI가 읽고 작업할 근거를 만든다 [07:14]
• 계획 단계에서는 AI가 설계를 작은 작업으로 나누고 사람이 검토·승인한다. 구현 단계에서는 AI가 승인된 계획의 각 작업을 실행하며 통과할 때까지 반복한다 [07:48]

5. 좋은 스펙을 구성하는 다섯 가지 기준

• 입력·출력과 관측 가능한 동작을 정의해 무엇을 만드는지 명확히 해야 한다. 만드는 이유와 측정 가능한 성공 기준도 필요하다 [09:23]
• 응답 시간이나 프레임워크 관례 같은 제약과 이번 작업에서 제외할 범위를 명시해야 한다. MVP 밖의 기능을 제한하면 AI의 과도한 작업 확장을 막고 토큰도 아낄 수 있다 [09:56]

6. 짧은 초안을 반복 검토하고 인터페이스를 명확히 정의하기

• 처음부터 완벽한 스펙을 작성할 필요는 없다. 열 줄 정도의 초안을 AI가 확장하게 하고 사람이 비판적으로 검토하는 과정을 세네 번 반복하는 방식으로 구체화할 수 있다 [10:48]
• 수용 기준·엣지 케이스·제약·범위·인터페이스 시그니처를 점검하고, 빠진 항목은 보완해야 한다. 응답 지연 100ms 이하나 캐시 히트율 70% 이상은 측정 가능한 수용 기준의 예시다 [11:18]

7. 큰 프로젝트의 스펙을 계층으로 나누는 방법

• 모든 요구를 하나의 문서에 넣기보다 마스터 스펙 아래에 컴포넌트별 스펙을 둔다. 각 컴포넌트 스펙은 단일 AI 세션의 컨텍스트에 들어갈 크기로 나누는 것이 좋다 [12:56]
• 큰 스펙의 내용이 컨텍스트 압축 과정에서 묻히는 문제를 줄이려면 문서를 잘게 나누고 참조 관계를 연결해야 한다. MVP 이후 컴포넌트나 기능을 추가할 때도 해당 스펙을 점진적으로 붙이는 방식을 권장한다 [13:32]

8. 기존 TDD 환경에 하네스 프레임워크 통합하기

• 하네스 프레임워크 저장소의 구조를 현재 프로젝트로 복사하도록 Claude에 요청한다. 기존에 설정한 TDD 관련 구성도 사용할 수 있도록 병합한다 [14:41]
• 스펙을 작성한 뒤 AI가 나머지 작업을 반복 실행하는 과정은 오래 걸릴 수 있으며, 한 시간을 넘기는 경우도 있다고 한다. 실습에서는 실행을 먼저 시작한 뒤 프로젝트 구조를 확인하는 방식을 택한다 [15:11]

9. PRD·아키텍처·ADR로 요구와 결정 이유 보존하기

• docs의 PRD에는 목표, 해결할 문제, 사용자, 핵심 기능, MVP 제외 사항과 디자인을 담는다. 아키텍처 문서에는 디렉터리 구조·패턴·데이터 흐름·상태 관리 등을 정리하며, 제공된 뼈대를 반드시 그대로 따를 필요는 없다 [16:22]
• ADR은 무엇을 선택했는지뿐 아니라 왜 선택했고 무엇을 포기했는지 기록한다. 결정 이유가 코드에 남아 있지 않으면 후속 에이전트가 기존 의도를 모른 채 구조를 바꿀 수 있으므로, 판단의 맥락까지 전달해야 한다 [17:58]

10. 썸네일 생성 서비스의 입력·출력과 목적 정의하기

• 실습 서비스는 배경·문구·사진 등에 대한 사용자의 요청을 받아, 자막에서 ‘GPT 이미지 2’로 지칭하는 이미지 API로 유튜브 썸네일을 생성하는 구상이다 [19:39]
• 프롬프트는 필수 입력이고 사용자 이미지는 선택 입력이며, 출력은 이미지다. 입력과 출력의 필수 여부를 구분해 초기 요구사항을 명확히 한다 [19:58]

11. 짧은 요구에서 시작해 저장소 맥락과 실행 장치 연결하기

• 초기 요구는 몇 줄의 짧은 프롬프트로 시작하고, 핵심 기능과 MVP 제외 사항은 대화를 통해 보강한다. AI는 탐색용 서브 에이전트로 현재 저장소를 먼저 살펴본다 [21:18]
• 기존 설정에는 TDD 가드, 빌드·테스트 실행 훅, 위험한 명령어를 차단하는 훅이 포함되어 있다. 이 설정들은 에이전트의 작업 과정에 검증과 제한을 제공한다 [21:57]

12. MVP 기능 선택과 외부 API 사용 조건 확인하기

• MVP 후보에는 16:9 썸네일 프리셋, 복수 후보 동시 생성, 세션 내 생성 결과 갤러리가 포함된다. 썸네일에 넣을 문구는 프롬프트와 별도 필드로 받기로 한다 [22:55]
• AI가 이미지 모델 정보를 찾는 과정에서 혼선이 생긴 뒤 해당 API를 확인한다. OpenAI API 키와 호출 비용이 필요하며, 실습에서는 비용을 지불하고 사용하는 방향을 선택한다 [23:39]

13. 빈약한 계획을 사용자 여정과 오류 대응 중심으로 보강하기

• 초기 계획에는 PRD에 채울 항목과 결정 사항이 있지만 구체성이 부족하다. 기존의 다섯 가지 체크리스트를 기준으로 계획을 다시 검토하도록 요청한다 [26:05]
• 사용자 진입부터 실행까지의 흐름과 오류 발생 시 대응을 자세히 설계하도록 요구한다. 제품 사용자의 만족을 위해 UI·UX와 사용자 여정을 더 중점적으로 다룬다 [26:45]

14. 슬래시 커맨드로 탐색·논의·작업 분할 자동화하기

• 하네스의 슬래시 커맨드는 정해진 워크플로우를 실행한다. 먼저 하위 문서를 읽고 의도를 파악하며, 구체화하거나 기술적으로 결정할 사항이 있으면 사용자에게 돌아와 논의한다 [28:10]
• 스펙이 충분히 정리되어 있으면 논의 단계를 건너뛸 가능성이 높다. 이후 Claude가 작업을 단계와 작은 태스크로 나누며, 각 작업의 범위를 최소화한다 [28:39]

15. 개선된 스펙에 사용자 흐름·에러 처리·화면 설계 구체화하기

• 수정된 계획에는 사용자 페르소나와 진입 맥락, 누가 언제 무엇을 하며 어떤 결과를 원하는지가 더 자세히 포함된다 [29:22]
• 사용자 여정은 폼 작성, 입력 검증, 검증 실패 시 복귀, 썸네일 생성과 성공·실패 분기로 구체화된다. 오류 처리 매트릭스에는 오류별 대응 방식과 추가 규칙이 압축된다 [29:49]

16. MVP에 맞춰 설계를 줄이고 실행 기준을 구체화한다

• 아키텍처를 다시 점검하되 과도한 엔지니어링을 피하고, MVP에 필요한 최소한의 변화로 최대한의 결과를 만드는 데 집중한다. [30:12]
• 함수·클래스의 인터페이스를 명시하고 구현은 AI에 맡긴다. 수용 기준에는 실행 가능한 명령어를 포함하며, 주의 사항과 네이밍도 구체적으로 지정한다. [30:36]

17. 상태 기록과 완료 요약으로 세션 간 작업을 연결한다

• 완료 여부와 오류를 기록해야 독립된 세션에서도 다음 작업을 판단할 수 있다. 이전 세션의 기억에 의존하면 컨텍스트 압축 과정에서 진행 정보가 사라질 수 있다. [31:30]
• 단계 완료 요약에는 산출물과 다음 단계에 필요한 정보를 담는다. 실행기가 이 요약을 다음 프롬프트의 컨텍스트로 누적 전달하면서 엔지니어 간 인수인계처럼 작업을 연결한다. [32:10]

18. 스펙으로 구현과 검증을 진행하는 가벼운 하네스를 만든다

• 실행 시 각 단계의 프롬프트가 Claude에 전달되고, 해당 스펙에 따라 구현과 검증이 진행된다. 이 구조가 간단한 형태의 스펙 기반 개발이다. [32:38]
• 하네스는 복잡할수록 좋은 것이 아니라 원하는 결과를 만드는 데 필요한 만큼 작고 단순한 편이 좋다. 스킬을 30~40개씩 만드는 방식도 과도한 설계가 될 수 있다. [33:21]

19. claude -p로 대화 없이 작업을 실행한다

• claude -p는 프롬프트를 전달하면 작업을 수행하고 결과를 반환하는 방식이다. 지속적인 사용자 개입이 없는 실행을 전제로 하며, 매일 밤 코드 검사를 돌리는 자동화 등이 사용 예다. [34:26]
• 코드베이스 분석 시연에서는 대화형 화면을 열지 않고 터미널에서 요청을 전달한다. 작업 중에는 별도 설명이 보이지 않다가 분석 결과가 반환된다. [35:22]

20. 단계별 세션 분리로 메인 컨텍스트 누적을 줄인다

• 긴 메인 세션에 구현을 계속 쌓으면 품질이 급격히 떨어진다는 것이 세션 분리의 근거다. 컨텍스트 사용량이 30~40%를 넘으면 활용하기 어렵다는 강한 판단이 제시되지만, 이를 뒷받침하는 측정 결과는 이 구간에 없다. [36:08]
• 뒤쪽 단계일수록 앞선 작업의 컨텍스트가 누적되므로, 각 단계를 바깥 세션에서 실행하고 필요한 정보와 프롬프트를 모두 제공하는 구조를 사용한다. [37:08]

21. 헤드리스 실행의 과금 문제와 Codex 전환을 검토한다

• 시연에서는 claude -p가 구독 사용에서 API 과금으로 바뀌었다는 설명을 전제로 비용 확인을 요청한다. Codex는 아직 같은 상황이 아니라는 판단 아래 향후 프로젝트에서는 대응하는 기능을 사용할 계획이며, 정책이 언제 바뀔지는 알 수 없다고 덧붙인다. [40:45]
• 별도 크레딧이 필요하다는 응답을 확인한 뒤 실행 방식 변경도 요청하지만, 이미 작업이 시작된 상태여서 이번 시연은 비용을 부담하고 기존 실행을 계속하기로 한다. [41:53]

22. 요구사항·아키텍처·ADR를 다섯 단계의 실행 계획으로 연결한다

• 요구사항 문서에는 목표, 핵심 기능, MVP 제약, 디자인, 사용자 여정, 오류 처리가 담긴다. 아키텍처에는 디렉터리와 다섯 레이어, 데이터 흐름과 상태 관리가 들어가며, ADR에는 기술과 구조를 선택한 이유가 기록된다. [42:58]
• 세 문서를 바탕으로 MVP 작업을 0번부터 시작하는 다섯 단계로 나누고, 메인 인덱스에서 전체 진행 상태를 관리한다. 각 단계에는 별도의 실행 프롬프트가 있다. [43:33]

23. API 키가 대화와 터미널 기록에 남지 않도록 한다

• API 키를 Claude나 Codex의 대화·터미널 입력에 직접 붙여 넣으면 세션 히스토리에 남을 수 있다. 해당 기록이 탈취될 경우 키도 유출될 수 있다는 이유로 직접 입력을 피하도록 강조한다. [44:33]
• 키를 별도로 입력한 뒤 AI에는 설정이 제대로 됐는지 확인하도록 요청한다. [45:15]

24. 원격 개입과 절전 방지로 장시간 실행을 이어간다

• Claude Code 세션을 휴대전화와 연동하면 자리를 비운 동안에도 도움이나 권한 요청에 대응할 수 있다. 프로젝트 설정 단계에서는 아키텍처 규칙, 개발 절차, 명령어를 담은 CLAUDE.md도 생성된다. [45:25]
• 도메인 작업 이후 OpenAI 서비스, API, UI 순서로 구현이 이어지며 브랜치 생성과 커밋도 자동으로 진행된다. 결과는 PR이나 코드 리뷰로 검토할 수 있다. [46:10]

25. 단계 완료와 무결점 제품은 구분해야 한다

• 인덱스에는 0~2단계가 완료로 기록되고 3단계가 실행 중이다. 라우트 구성과 테스트, 수용 기준 실행이 이어지면서 구현이 마무리된다. [47:16]
• 좋은 스펙은 오류와 버그의 확률을 낮추지만 완벽한 서비스를 보장하지 않는다. 실제 서비스를 실행해 문제가 발견되면 별도로 수정해야 한다. [47:51]

26. 설계에서 자동 구현으로 이어진 뒤 사람이 안전장치를 검토한다

• 앞선 설계가 충분히 구체적이어야 뒤의 작업이 자동으로 진행된다. 계획에는 범위 최소화와 단계별 자기완결성 같은 지침이 반영되고, 이에 따라 페이즈와 단계가 생성된다. [48:48]
• 실행기는 헤드리스 세션으로 구현을 진행하면서 브랜치 분리, 가드레일 전달, 컨텍스트 전달, 자가 교정, 커밋, 상태 추적을 처리한다. [49:29]

27. 회고 결과를 문서와 실행 환경에 반영한다

• 세션이 끝난 뒤 AI가 회고를 작성하는 것만으로는 충분하지 않다. 회고 내용을 토대로 CLAUDE.md와 관련 문서를 고쳐 같은 실수를 줄이는 시스템 개선으로 연결해야 한다. [50:30]
• 다음 실행이 이전보다 덜 틀리도록 환경을 축적해서 개선하는 능력이 AI 시대 엔지니어의 중요한 역량으로 드러난다. [50:47]

28. 사용량 보고서로 긴 세션과 서브 에이전트 비용을 점검한다

• 사용량 화면에는 패스트 모드 실행 후 8%를 사용한 것으로 표시된다. 패스트 모드가 아니었다면 사용량이 조금 적었을 것이라는 추정도 덧붙는다. [51:22]
• 보고서의 48%는 150K 이상의 긴 세션과, 44%는 서브 에이전트 사용이 많은 세션과 연결해 읽힌다. 긴 세션과 서브 에이전트 활용이 토큰 비용을 늘릴 수 있다는 점이 최적화 대상으로 꼽힌다. [51:39]

29. 썸네일 생성과 전체 빌드로 구현 결과를 확인한다

• 사진을 선택하고 후보 수를 두 개로 설정해 썸네일 생성을 시도한다. 개발자 도구의 네트워크 탭을 늦게 열어 이미 발생한 API 호출은 확인하지 못했지만, 생성된 썸네일에는 만족감을 나타낸다. [56:01]
• 마지막 단계에는 전체 동작 테스트와 빌드가 포함된다. 이후 UI를 포함한 4단계까지 완료 상태가 확인되며, 계획대로 생성된 구조에 대해 전체 빌드와 테스트를 다시 실행하는 최종 검증이 계속된다. [56:47]

30. 구체적인 스펙이 자율 실행의 기반이 된다

• 이번 구현의 핵심은 스펙을 준비한 뒤 AI가 이를 바탕으로 자율 실행했다는 점이다. 마무리에서는 잘 작성한 스펙을 기반으로 약 30분 만에 앱을 만들었다고 평가한다. [59:45]

31. 큰 스펙을 분할하고 계층화하는 개발 방식

• 작업 규모가 너무 크면 스펙을 더 작은 단위로 나누고 계층화할 수 있다. [1:00:11]
• 스펙 기반 개발을 직접 시도할 때 발표자가 만들어 둔 프레임워크도 활용할 수 있다. [1:00:20]

32. 에이전트 장기 실행에 따른 토큰 비용과 팀 단위 관리

• 에이전트를 자율적으로 오래 실행하도록 헤드리스 모드로 구동할 수 있지만, 토큰 사용량이 누적될 수 있다. 이와 관련해 코덱스 사용을 권장한다. [1:00:38]
• 다음에 다룰 과제는 토큰 효율과 비용을 측정하고, 낭비가 발생하는 지점을 찾아 팀 단위로 통제하는 방법이다. [1:00:49]

🧾 결론

• SDD의 핵심은 AI가 실행할 수 있을 만큼 요구와 검증 기준을 구체화하는 데 있다. 개발자의 주요 역할도 설계·도메인 판단·출력 검토로 이동한다.
• 스펙, 작은 작업 단위, 실행 하네스, 검증, 회고가 연결되어야 반복 실행의 개선을 기대할 수 있다. 회고는 실제 문서와 규칙 변경으로 이어져야 한다.
• 하네스와 문서는 MVP에 필요한 수준으로 유지한다. 과도한 기능이나 복잡한 실행 장치보다 명확한 범위와 자기완결적인 단계가 중요하다.
• 단계 완료 표시는 제품의 무결점 판정이 아니다. 실제 사용자 흐름을 실행하고 발견된 문제를 수정하는 검토가 남는다.

📈 투자·시사 포인트

• 개발 조직은 코드 생성 속도뿐 아니라 스펙 설계와 결과 리뷰에 필요한 시간도 함께 평가할 필요가 있다. 자료에서는 이 두 작업이 AI 중심 개발의 주요 병목으로 제시된다.
• 에이전트 도입의 경제성을 판단하려면 구현 시간과 함께 토큰 사용량, API 호출 비용, 재작업 비용을 측정해야 한다. 단일 시연의 제작 시간만으로 팀 전체의 생산성 효과를 일반화하기 어렵다.
• 도메인 지식과 의사결정 이유를 문서로 보존하는 역량이 중요해진다. 후속 에이전트가 기존 의도를 이해하도록 만드는 기록이 반복 작업의 기반이 된다.
• 실행 도구 선택에는 헤드리스 실행의 과금 조건과 팀 공유 한도도 영향을 준다. 영상 속 정책 설명을 고정된 조건으로 받아들이기보다 실제 도입 시점에 확인해야 한다.

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

• claude -p의 구독·API 과금과 Codex의 비용 조건은 시연 당시 설명이다. 계정이나 실행 방식별 적용 조건과 현재 정책은 이 자료만으로 확정할 수 없다.
• 컨텍스트 사용량이 30~40%를 넘으면 활용하기 어렵다는 주장은 제시되지만, 이를 일반적인 임계값으로 뒷받침하는 측정 결과는 없다. Fast 모드의 추론 동작에 관한 설명도 추가 확인이 필요하다.
• 자막의 ‘GPT 이미지 2’라는 명칭과 실제 API 모델 식별자의 대응은 확인이 필요하다. 자료에는 모델 정보를 찾는 과정에서 혼선이 있었다고 명시되어 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 작은 MVP 하나를 정하고 입력·출력, 목적, 성공 기준, 제약, 제외 범위와 예외 처리를 짧은 스펙으로 작성한다.
• AI가 확장한 초안을 사람이 반복 검토하고 사용자 여정, 오류 대응, 인터페이스, 실행 가능한 수용 기준을 보완한다.
• PRD·아키텍처·ADR에 요구와 결정 이유를 남기고, 각 실행 단계에 먼저 읽을 파일·작업·검증 명령·금지 사항을 포함한다.
• 단계별 완료 여부와 오류, 산출물, 다음 단계에 필요한 정보를 기록하고 실제 서비스 실행 및 전체 빌드·테스트 결과를 확인한다.

❓ 열린 질문

• 스펙 작성과 리뷰 시간을 포함했을 때, 어떤 규모와 유형의 작업에서 SDD의 생산성 효과가 가장 크게 나타나는가?
• 세션을 나누면서 필요한 맥락을 충분히 전달하려면 스펙과 완료 요약을 어느 크기와 수준으로 유지해야 하는가?
• 팀 단위로 토큰 비용과 재작업을 측정할 때, 자율 실행의 효율을 판단할 공통 지표는 무엇으로 정할 것인가?