7장: 검증·완료의 기준

원작이 정한 완료의 정의는 한 문장입니다. 완료란 배포되었다는 뜻입니다. 사이클이 끝날 때 팀은 자기 작업을 배포하고, 작은 프로젝트 여럿을 맡은 팀이라면 사이클 안에서 준비되는 대로 내보냅니다 (10장: 책임 넘기기). 다음 사람의 대기열로 넘기는 것은 완료가 아니라는 선언이었습니다.

이 정의는 사람이 코드를 직접 쓰고 직접 돌려 보았다는 전제 위에서만 충분했습니다. 생성이 끝났고 테스트도 초록불인데 그 코드를 아무도 읽지 않았다면, 우리는 이것을 완료라고 부를 수 있을까요.

힐 차트 → 위임 가능성 지도

원작에는 진행 상황을 보여 주는 도구가 하나 있습니다. 힐 차트(hill chart)입니다. 모든 작업에는 두 국면이 있습니다. 어떤 접근을 취할지 알아내는 오르막(uphill), 그리고 관련된 일이 전부 눈에 들어와 실행만 남은 내리막(downhill)입니다. 각 스코프가 언덕의 어디쯤 있는지 점으로 찍어 두면 진척을 묻지 않고도 상황이 보입니다 (13장: 진행 상황 보여주기).

VDLC는 같은 차트의 용도를 바꿉니다. 진행 보고 도구였던 것이 인간과 에이전트 사이의 업무 분배 도구가 됩니다. 오르막에 있는 스코프는 미지가 남아 있다는 뜻이고, 미지가 남아 있다면 사람의 판단이 필요하므로 에이전트에게 완전히 위임하지 않습니다. 내리막에 있는 스코프는 의도가 확정되었다는 뜻이고, 확정되었다면 실행은 통째로 위임할 수 있습니다 (VDLC 주간 사이클).

그래서 점을 내리막으로 옮기는 행위의 무게도 달라집니다. 원작에서 그것은 "이제 어떻게 할지 알겠다"는 보고였지만, VDLC에서 그것은 "이 스코프의 의도가 컨텍스트 문서에 완결적으로 기술되었다"는 선언입니다. 머릿속에서만 풀린 것은 내리막이 아닙니다. 적히지 않은 이해는 에이전트에게 전달되지 않으므로, 여기서 판정 기준은 담당자의 확신이 아니라 문서입니다.

QA는 가장자리에서 검증 게이트로

원작에서 QA는 가장자리를 맡는 역할이었습니다. 메인 플로우가 동작하는지는 만든 사람이 이미 확인했으니 QA는 예외 상황을 찾는 데 집중하고, 거기서 나온 이슈는 기본적으로 선택 항목(nice-to-have)으로 들어온 뒤 심각한 것만 필수 항목(must-have)으로 올라갑니다.

이 분업 전체가 전제 하나에 얹혀 있습니다. 사람 구현자가 메인 플로우를 이미 손으로 통과해 보았다는 전제입니다. 에이전트가 생성한 코드에는 그 전제가 없어서, 아무도 한 번도 밟아 보지 않은 메인 플로우가 존재할 수 있습니다. 그래서 VDLC에서 검증은 남는 시간에 하는 보조 활동이 아니라 명시적 단계로 승격되고, 5장에서 본 Day 4 하루 전체가 여기에 배정됩니다. 이날은 신규 코딩이 금지되며 검증 중 발견된 결함의 수정만 허용됩니다.

게이트에서 확인하는 항목은 다섯입니다.

• 피치가 적어 둔 문제가 실제로 해소되었는가 (베이스라인(baseline) 대비 비교)
• 제외 항목 위반이 없는가
• 메인 플로우를 사람이 직접 검증했는가
• 엣지 케이스 자동 테스트가 통과하는가
• Done = Deployed, 곧 실제 환경에 배포되었는가

2장에서 첫 번째 병목으로 꼽았던 것이 프로세스 수준에서 흡수되는 자리가 여기입니다. AI 도입도가 높은 팀에서 PR 리뷰 시간이 91% 늘었다는 수치는, 검증을 일정에 자리 없는 활동으로 두었을 때 그 부담이 어디로 밀려나는지를 보여 줍니다. 하루를 배정한다는 것은 그 초과분을 저녁 시간이 아니라 사이클 안에서 치르게 만든다는 뜻입니다.

스코프 해머링 → 컨텍스트 해머링

고정된 기간 안에 끝내려면 남은 일을 깎아야 합니다. 원작은 이 일을 "잘라낸다"보다 센 말로 부릅니다. 스코프 해머링(scope hammering)입니다. 이것이 정말 필수 항목인지 거듭 되묻고, 아니라고 판단된 것에 물결표를 붙여 선택 항목으로 내려보내는 일입니다 (14장: 언제 멈출지 결정하기).

되묻는 행위는 그대로 남지만 깎는 대상이 바뀝니다. 코드를 지워 봐야 같은 의도 문서가 남아 있는 한 다음 생성에서 그것이 다시 돌아오기 때문입니다. 그래서 VDLC의 해머링은 코드가 아니라 컨텍스트 문서를 두들깁니다. 유스케이스 하나를 잘라내기로 했다면 구현을 삭제하는 것이 아니라 의도 문서에서 그 항목을 내리고 다시 생성합니다. 컨텍스트 해머링이라는 이름이 붙은 이유입니다.

완료의 정의에도 조건이 하나 붙습니다. Done = Deployed에 재생성 가능(regenerable)이 더해집니다. 컨텍스트 문서만으로 같은 것을 다시 만들어 낼 수 있어야 진짜 완료라는 것입니다. 5장에서 본 쿨다운의 재생성 검증이 이 조건을 매주 실측합니다. 배포는 되었는데 재생성이 실패한다면, 그 사이클은 완료된 것이 아니라 컨텍스트 부채를 남긴 것입니다.

언제 멈출까

그래도 시간보다 할 일이 많다는 사실은 변하지 않습니다. 원작이 내놓은 답은 비교의 방향을 바꾸는 것이었습니다. 이상적인 완성형을 올려다보며 비교하지 말고, 베이스라인 — 이 기능이 없는 오늘 고객이 쓰고 있는 답답한 우회 방법 — 과 견주어 내려다보라는 것입니다. 지금 만든 것이 그것보다 나으면 출시할 수 있습니다.

이 기준은 구현이 얼마나 싼지와 아무 상관이 없습니다. 고객이 지금보다 나아지는가만 묻기 때문입니다. 그래서 원작의 답 가운데 이 대목은 손댈 것이 없고, 바뀐 것은 유혹의 크기뿐입니다. 예전에는 더 만들자는 제안에 몇 주라는 가격표가 붙어 있어서 자연히 걸러졌지만, 이제는 한 시간이면 되니 굳이 멈출 이유를 찾기 어렵습니다. 2장에서 인용한 Jason Fried의 문장이 여기서 다시 필요해집니다. 속도도, 커밋 수도, 투입한 인원 수도 제품을 본질적으로 더 낫게 만들지는 않는다는 말입니다. 더 만들 수 있다는 것은 더 만들어야 할 이유가 아닙니다.

맺음말

구현 비용은 실제로 무너졌지만 모든 자리에서 균일하게 무너지지는 않았고, 그 자리에 검증과 주의력과 복잡도라는 새 희소 자원이 들어섰습니다(1부). 애피타이트와 셰이핑은 그래서 폐기되기는커녕 더 무거워졌고, 다만 애피타이트는 시간 하나가 아니라 인간 주의력과 컴퓨트라는 두 통화로, 셰이핑은 문서가 아니라 프로토타입 라운드를 내장한 활동으로 내용물을 바꿨습니다(2부). 사이클과 베팅과 완료 판정은 4일 빌드에 1일 쿨다운이라는 주간 심박으로 재조립되었고, 그 안에서 서킷 브레이커는 반송 장치로, 힐 차트는 위임 지도로, QA는 게이트로 자리를 옮겼습니다(3부).

여기까지가 경계선을 긋는 일이었습니다. 다음 걸음은 이 선 위에 세워진 운영 규칙을 실제 한 주에 얹어 보는 것이고, 규칙의 전체 정의는 VDLC 주간 사이클 문서에 있습니다. 월요일 아침에 베팅하고 목요일에 게이트를 세우고 금요일에 재생성을 시켜 보는 것으로 충분한 시작입니다.

원작의 결론은 방법론을 통째로 도입하지 않더라도 언어와 개념 몇 개는 가져다 쓸 수 있기를 바란다는 말로 끝납니다. 이 가이드도 같은 자리에서 끝냅니다. 한 가지만 덧붙이면, 바이브 코딩이라는 이름을 붙였다가 1년 만에 내려놓은 Karpathy와 Shape Up의 사이클이 끝났다고 먼저 말한 DHH가 정반대 방향에서 출발해 같은 결론에 닿았다는 사실입니다. 만드는 일은 넘겨줄 수 있지만 품질의 기준은 사람이 붙들고 있어야 한다는 것. Shape Up이 처음부터 하던 이야기이기도 합니다.