엔트로픽 SDLC 플레이북으로 바이브 코딩 버그를 잡아보자!

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

앤트로픽 SDLC 플레이북을 확장해 구현 전에 합격 기준을 정하고 독립 QC로 검증하면, 자체 테스트가 놓친 바이브 코딩 버그를 찾아 수정·재검증으로 연결할 수 있다.

📌 핵심 요점

1. 테스트 통과는 요구 사항 충족과 다르다. 행사 참가자가 취소해도 대기자가 승격되지 않는 사례처럼, 중요한 동작을 검사하지 않았다면 테스트가 모두 통과해도 기능은 미완성이다.
2. 앤트로픽 플레이북의 핵심은 개발 단계 사이의 연결이다. 사용자 의도부터 설계·구현·검증·운영까지 앞 단계의 결정과 근거를 다음 작업자가 이어받도록 한다.
3. 발표자는 원문의 흐름에 테스트 스펙 문서, 독립 QC, 버그 티켓을 통한 재검증 절차를 구체적으로 더했다. 구현 계획과 합격 기준은 같은 요구 사항 명세를 기준으로 각각 작성한다.
4. 요구 사항 추적성 검사는 구현 작업과 테스트의 연결 누락을 찾는다. 연결이 존재한다는 사실만으로 기능이 검증되지는 않으므로, 고정된 코드 버전에서 실제 동작을 확인해야 한다.
5. 결함은 재현 절차와 기대·실제 결과를 담은 티켓으로 전달하고, 합격 기준을 유지한 채 수정·회귀 검증한다. 이후 사람의 리뷰와 배포 승인, 운영 피드백까지 개발 흐름에 연결한다.

🧩 배경과 문제 정의

영상은 정원 30명의 행사 신청 앱에서 시작한다. 참가자가 취소하면 첫 번째 대기자가 자동 승격돼야 하지만, 자체 테스트를 모두 통과한 앱에서도 확정 인원만 29명으로 줄고 대기자는 그대로 남는다. 발표자는 이를 테스트 실행 여부보다 무엇을 확인해야 완성으로 인정할지 먼저 정하지 않은 문제로 설명한다.

발표자가 소개하는 앤트로픽의 AI 네이티브 SDLC 플레이북은 기획·설계·구현·테스트·배포·운영 사이의 결정을 문서로 연결하는 접근이다. 발표자는 이 흐름에 구현 전 테스트 스펙 작성, 독립 QC, 결함 티켓과 재검증을 더한 실험을 제시한다. 목표는 사용자의 요청이 실제 검증 결과까지 이어지게 해 반복 설명과 수정 요청을 줄이는 것이다.

🕒 시간순 섹션별 상세정리

1. 테스트가 통과했는데 자동 승격은 실패한다

• 정원 30명과 대기자 1명이 있는 상태에서 참가자가 취소해도 대기자는 승격되지 않는다. 확정 인원은 29명으로 줄지만 자체 테스트는 통과한 상태다. [00:29]
• 발표자는 중요한 요구가 시험 문제에서 빠져 있다면 전부 맞혀도 완성이라고 할 수 없다고 보여준다. 먼저 합의해야 할 것은 기능의 완료 기준이다. [01:19]

2. SDLC 전체를 연결하는 플레이북과 확장 설계

• 발표자는 2026년 8월 공개됐다고 소개한 앤트로픽 플레이북을 통해 코드 생성 속도에 비해 기능 결정·설계 검토·테스트 확인·배포 승인이 매끄럽게 이어지지 않는 문제를 짚어 본다. [02:04]
• 사용자 의도, 설계와 구현 계획, 코드, 테스트·리뷰 결과, 운영 문제를 문서로 연결한다. 목적은 앞 단계의 결정을 다음 작업자가 정확히 이어받는 것이다. [02:30]
• 원문에도 검증 에이전트와 개발 피드백 흐름이 있으며, 발표자는 여기에 테스트 스펙 문서와 독립 QC, 버그 티켓을 통한 재검증 절차를 구체적으로 더했다고 구분한다. [03:08]

3. 행사 규칙을 사용자 의도 문서로 확정한다

• 실험 앱의 규칙은 정원 30명, 초과 신청자의 신청 순서별 대기, 참가자 취소 시 첫 대기자의 자동 승격이다. 마지막 규칙이 빠지면 화면이 정상이어도 요구 사항을 충족하지 못한다. [03:38]
• 인텐트 문서를 작성할 때 AI는 바로 구현하지 않고 정원과 취소 정책 등을 질문한다. 해결할 문제, 기대 결과, 영향받는 사람, 제약과 미결정 사항을 기록한다. [04:31]
• 중복 신청처럼 미정인 정책은 그대로 남기고, 요청하지 않은 로그인이나 이메일 발송을 추가하지 않는다. 사용자가 확인한 의도가 이후 작업의 기준이 된다. [04:55]

4. 요구 사항에 식별자와 판정 가능한 조건을 붙인다

• 스펙 문서에서는 자연어 요청을 구체적인 요구 사항으로 바꾼다. 30번째와 31번째 신청자의 처리, 동시 신청의 순서처럼 경계와 처리 규칙을 명확히 필요가 있다. [05:21]
• 정원 초과 금지, 초과 신청자의 대기 등록, 취소 시 첫 대기자 승격에 요구 사항 번호를 붙여 구현 여부를 개별적으로 확인한다. [05:49]
• 미정 정책에 임의의 테스트 조건을 만들지 않는다. 구현 전에 반드시 결정해야 하는 항목은 해결될 때까지 다음 단계 진행을 막는다. [06:01]

5. 구현 전에 계획과 합격 기준을 각각 설계한다

• 플래너는 변경 파일과 개발 순서를 계획 문서에 적고, QC 아키텍트는 합격 조건을 테스트 스펙에 정한다. 두 역할 모두 같은 요구 사항 명세를 기준으로 삼는다. [06:37]
• QC가 구현 작업 목록만 보면 플래너의 누락을 그대로 반복할 수 있다. 자동 승격 테스트는 30명과 대기자 1명 상태에서 취소 후 첫 대기자가 참가자로 바뀌고 확정 인원이 다시 30명이 되는지 확인하도록 미리 정한다. [07:01]
• 코드가 기준을 충족하지 못해도 정답을 코드에 맞춰 바꾸면 안 된다. QC의 독립성을 위해 작업 공간과 파일 수정 권한을 분리해야 한다. [07:21]

6. 추적성 검사로 구현과 테스트의 연결 누락을 찾는다

• 코드 작성 전에 각 요구 사항에 구현 작업과 합격 여부를 판단할 테스트가 모두 연결됐는지 확인한다. 실험에서는 자동 승격 요구와 테스트 사이의 연결을 일부러 제거한다. [07:51]
• 추적성 검사기가 빠진 연결을 찾고, 연결을 복구한 뒤 다시 검사한다. 다른 테스트가 모두 통과해도 핵심 요구를 놓칠 수 있는 경로를 사전에 드러내는 절차다. [08:13]
• 연결 확인은 실제 기능 검증과 다르다. 추적성 검사는 누락을 먼저 찾으며, 구현 이후 실제 동작을 별도로 확인해야 한다. [08:23]

7. 자체 테스트와 독립 QC의 결과가 갈린다

• 빌더는 승인 문서를 기준으로 구현하고 자체 테스트를 실행한다. 데모에서는 자동 승격 결함을 잡는 자체 테스트를 넣지 않아 통과 결과가 나온다. [08:58]
• 별도 QC가 미리 정한 조건으로 검증하자 취소 후 참가자 29명과 대기자 1명이 남아 기대 결과와 어긋난다. 코드 스타일보다 사용자 규칙의 실제 동작을 확인하는 과정이다. [09:53]
• QC의 실행 테스트와 접근 권한, 검증 대상 커밋을 정한다. 결함 티켓에는 충족하지 못한 요구와 테스트, 기대·실제 결과, 재현 절차와 실행 환경을 기록한다. [10:28]

8. 결함 티켓으로 수정과 회귀 검증을 반복한다

• 기존 소프트웨어 조직의 결함 등록·수정 방식을 AI 에이전트 사이에도 이어 붙인다. 빌더는 티켓의 절차로 문제를 재현하고 코드를 수정한다. [10:53]
• 실패한 테스트를 삭제하거나 기대값을 잘못된 결과에 맞춰 바꾸지 못하게 한다. 수정 코드를 새 커밋으로 남기고 QC가 같은 테스트와 정원·대기 순서 관련 회귀 테스트를 실행한다. [11:27]
• 검증 실패 시 수정과 재검증을 반복하되, 이번 실험에서는 세 번 수정해도 같은 문제가 남으면 중단하고 담당자에게 원인 분석과 검증 증거를 남기도록 한다. [11:45]

9. 리뷰·배포 승인과 운영 피드백을 연결한다

• 구현과 QC 검증이 끝났다고 가정한 뒤 사람은 PR 리뷰에서 승인 계획에 포함된 변경인지, 필수 테스트 결과가 있는지, 남은 위험을 받아들일 수 있는지 확인한다. [12:08]
• 배포는 별도로 판단하며 CI, 저장소 권한, 책임자 승인이 함께 필요하다. 이번 실험은 실제 서비스 자동 배포까지 진행하지 않는다. [12:40]
• 운영 이상 신호의 로그와 변경 내용을 분석해 인시던트 문서에 기록하고, 필요한 수정을 다음 인텐트 문서와 테스트에 반영한다. 이 장면은 가상 데이터로 보여준다. [13:33]

10. 완성 기준의 합의와 하네스 실험으로 계속된다

• 발표자는 의도 기록, 요구 사항 구체화, 구현 전 계획·합격 기준 수립, QC 검증과 결함 수정·재검증을 되짚어 본다. 핵심은 사용자 요청이 구현 작업과 검증 결과까지 이어지는지다. [14:15]
• 최초 요구 해석이 틀리면 반복 테스트도 중요한 문제를 놓칠 수 있어 사용자 확인과 QC의 질문, 운영 피드백이 필요하다. 구현 전에 무엇이 완성인지 합의하는 것이 출발점이다. [14:49]
• 스킬 공개는 반응을 보고 결정하겠다고 말하며, 추적성 검사기·결함 기록·실제 테스트 결과 확인 장치의 필요성을 강조한다. 다음에는 클로드 코드 하네스로 누락과 잘못된 완료 판정의 자동 탐지를 실험하고, 시청자 사례를 참고하겠다고 마무리한다. [16:04]

🧾 결론

• 완성의 기준은 코드 작성 후의 완료 보고가 아니라, 구현 전에 합의한 사용자 요구와 검증 조건이어야 한다.
• 문서의 가치는 개수보다 연결에 있다. 사용자 요청이 요구 사항, 구현 작업, 테스트, 결함 기록으로 이어져야 누락과 반복 설명을 줄일 수 있다.
• 독립 QC는 역할 이름만으로 성립하지 않는다. 작업 공간과 수정 권한을 분리하고, 빌더가 합격 기준을 임의로 바꾸지 못하도록 해야 한다.
• 처음 요구를 잘못 이해하면 검증을 반복해도 중요한 문제를 놓칠 수 있다. 사용자 확인과 QC의 질문, 운영 단계의 피드백이 계속 필요하다.

📈 투자·시사 포인트

• AI 개발 도구의 실무 가치를 판단할 때 코드 생성 속도와 함께 요구 사항 누락, 검증 근거, 수정·재검증의 연결을 살펴볼 필요가 있다.
• 에이전트 활용에는 역할별 프롬프트 외에도 추적성 검사기, 결함 기록 장치, 실제 테스트 결과를 확인하는 자동 검사 체계가 필요하다는 시사점을 준다.
• 서비스 배포를 통제하려면 작업 절차를 안내하는 스킬과 함께 CI, 저장소 권한, 책임자의 승인이 작동해야 한다.
• 영상에는 비용 절감률이나 생산성 개선 수치가 제시되지 않는다. 특정 기업이나 도구의 투자 수익성을 판단하는 근거로 확대하기보다 개발 품질 관리의 평가 항목으로 활용하는 편이 적절하다.

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

• 앤트로픽 원문과 발표자의 확장 설계는 구분해야 한다. 테스트 스펙 문서, 독립 QC, 버그 티켓을 통한 재검증의 구체적인 구성은 발표자가 더한 부분으로 설명된다.
• 결함을 남긴 데모와 가상 운영 데이터를 사용하는 실험이다. 실제 서비스 자동 배포, 운영 장애 대응 효과, 비용·시간 절감까지 검증한 사례로 볼 수는 없다.
• 중복 신청 정책은 미정으로 남겨 둔다. 동시 신청의 처리 순서도 명확히 결정할 대상으로 제시되지만, 영상에서 구체적인 정책이나 구현 방식이 확정되지는 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 구현 전에 사용자 의도, 기대 결과, 제약, 미결정 사항을 기록하고 사용자에게 확인받는다.
• 요구 사항에 식별자를 붙이고 정원 경계, 대기 순서, 취소 후 자동 승격처럼 관찰 가능한 합격 조건으로 구체화한다.
• 같은 요구 사항 명세를 기준으로 구현 계획과 테스트 스펙을 각각 작성하고, 모든 필수 요구 사항에 구현 작업과 테스트가 연결됐는지 검사한다.
• QC의 작업 공간과 권한을 정하고 검증 대상 커밋을 고정한다. 빌더가 합격 기준을 임의로 수정할 수 없도록 한다.

❓ 열린 질문

• 사용자와 AI가 처음부터 요구 사항을 함께 오해했을 때, QC의 질문과 사용자 확인으로 그 오류를 어떻게 드러낼 수 있을까?
• 요구 사항과 테스트가 형식적으로 연결돼 있어도 핵심 동작을 충분히 검사하지 못하는 문제를 어디까지 자동으로 찾아낼 수 있을까?
• 발표자가 예고한 클로드 코드 하네스에서 합격 기준의 수정 권한, 검증 버전 고정, 테스트 실행 증거를 어떻게 통제할 것인가?