6장: 베팅 테이블의 재구성
원작에서 피치를 다 쓰고 나면 그 문서는 백로그(backlog)로 가지 않습니다. 사이클이 시작되기 전에 베팅 테이블(betting table)이 열리고, 그 자리에 올라오는 것은 지난 사이클 동안 나온 피치와 누군가 일부러 되살려 다시 들고 온 피치뿐입니다. 여기서 다음 사이클에 무엇을 걸지 정하는 결정이 베팅(bet)이고, 걸지 않기로 한 피치는 따로 추적하지 않고 놓아줍니다 (7장: 백로그 대신 베팅, 8장: 베팅 테이블).
이 회의가 6주에 한 번이 아니라 매주 열린다면, 테이블 위의 결정은 어떻게 달라질까요.
백로그 무용론은 더 강해진다
원작이 백로그를 거부한 이유는 두 가지였습니다. 손댈 시간이 나지 않을 항목이 쌓일수록 실제로는 뒤처지지 않았는데도 늘 뒤처진 기분이 든다는 것, 그리고 묵은 아이디어를 검토하고 다듬는 데 쓰는 시간이 지금 시의적절한 일을 밀고 나가지 못하게 막는다는 것입니다.
구현이 싸지면 이 논거는 약해지는 것이 아니라 강해집니다. 싸진 것은 만드는 비용만이 아닙니다. 아이디어를 적어 내는 비용도 함께 싸져서, 에이전트에게 물으면 그럴듯한 후보 기능 목록이 몇 초 만에 돌아옵니다. 그런데 그 목록을 읽고 분류하고 아직 유효한지 판단하는 일은 여전히 사람의 주의력에서 나옵니다. 2장에서 두 번째 병목으로 꼽았던 자원이 여기에 청구됩니다. 목록의 생산 속도만 몇십 배가 되고 소화 속도는 그대로라면, 백로그는 예전보다 훨씬 빨리 부풀고 훨씬 빨리 썩습니다.
그래서 원작의 대안이 그대로 유효합니다. 중요한 아이디어는 돌아옵니다. 정말 중요한 것이라면 누군가 맥락과 함께 다시 들고 나오고, 잊혔다면 애초에 그만한 것이 아니었습니다.
베팅은 옵션 매수가 된다
원작의 베팅은 비싼 결정이었습니다. 한 팀을 6주 동안 한 프로젝트에 묶는다는 뜻이었고, 그 6주는 다른 무엇에도 쓸 수 없었습니다. 되돌릴 수 없으니 신중해야 했고, 신중하려면 잘 셰이핑된 후보가 몇 개만 올라와야 했습니다.
구현이 싸지면 이 계산이 바뀝니다. 베팅은 헌신이 아니라 옵션 매수에 가까워집니다. VDLC는 이 변화를 병렬 베팅으로 정의합니다. 불확실성이 높은 피치에는 같은 피치에 서로 다른 접근 2~3개를 나란히 걸고, 사이클 안에서 승자를 고릅니다 (VDLC 주간 사이클).
여기에 조건이 하나 붙습니다. 승자 선정 기준은 Day 0 베팅 시점에 측정 가능한 형태로 문서에 적어 둡니다. 응답 지연 p95, 코드 재생성 성공률, 특정 엣지 케이스 통과 여부처럼 나중에 누가 봐도 같은 답이 나오는 기준이어야 합니다. 사후 취향 판정은 금지입니다. 결과를 다 본 뒤에 기준을 고르면 병렬 베팅은 비교가 아니라 합리화가 되기 때문입니다.
병렬로 걸 수 있는 개수의 상한을 정하는 통화는 컴퓨트가 아닙니다. 컴퓨트로만 따지면 열 개도 돌릴 수 있습니다. 상한은 인간 주의력에서 나옵니다. 문서에 적어 둔 기준으로 사람이 실제로 비교하고 판정할 수 있는 개수가 천장이고, 기본값은 2~3개입니다. 컴퓨트는 그 안에서 피치의 애피타이트 총액을 넘지 않는 선에서 자유롭게 나눠 씁니다.
베팅 테이블의 성격도 함께 달라집니다. 원작에서 이 회의는 드물게 열리는 대신 무게가 실린 자리였지만, 주 단위 사이클에서는 매주 월요일 아침의 가벼운 의식이 됩니다. 한 번의 결정에 걸린 것이 6주가 아니라 나흘이기 때문입니다.
솔로 빌더의 베팅
혼자 만드는 사람에게는 베팅 테이블이 없습니다. 그러나 베팅은 있습니다. 설득할 이해관계자가 없을 뿐, 무엇에 이번 주를 걸지는 여전히 정해야 합니다.
오히려 솔로 쪽이 더 위험합니다. 조직에는 팀 수라는 물리적 상한이 있어 동시에 굴릴 수 있는 프로젝트가 저절로 제한되지만, 병렬 에이전트를 쓰는 개인에게는 그런 상한이 없습니다. 솔로 빌더의 희소 자원은 자기 주의력 하나뿐인데, 그 자원만 상한 없이 초과 인출되는 구조입니다.
그러니 동시에 거는 베팅의 수를 스스로 정해 두는 것이 솔로 버전의 베팅 테이블입니다. 하나를 새로 열려면 하나를 닫거나 놓아주는 규칙을 자신에게 부과하는 것입니다. 남이 대신 물어봐 주지 않으므로 애피타이트 선언은 조직에서보다 더 절실합니다. 사이클 길이 쪽에서는 5장에서 본 하향 변형, 곧 2일 빌드에 1일 쿨다운이 솔로와 소규모 팀을 위한 기본값으로 이미 정의되어 있습니다.
서킷 브레이커 → 컨텍스트 브레이커
원작에는 프로젝트가 늘어지는 것을 막는 장치가 하나 있습니다. 서킷 브레이커(circuit breaker)입니다. 한 사이클 안에 출시하지 못한 프로젝트는 자동으로 연장되지 않고 기본적으로 중단되며, 다시 하려면 다음 베팅 테이블에서 새로 이겨야 합니다 (8장: 베팅 테이블의 서킷 브레이커 절).
원작도 같은 진단을 이미 내렸습니다. 6주 안에 끝나지 않았다면 셰이핑을 잘못한 것이므로, 서킷 브레이커는 다음 셰이핑 트랙에서 다시 짜도록 밀어붙입니다. 다만 그 사이 기본 동작은 여전히 중단이었습니다.
VDLC가 뒤집는 것은 이 진단이 아니라 기본 동작과 발동 시점입니다. 중단 대신 셰이핑 트랙으로의 즉시 반송을 기본값으로 삼습니다. 다시 만드는 비용은 이미 싸고, 비싼 것은 불명확한 의도를 붙들고 같은 자리를 맴도는 사람의 시간이기 때문입니다.
발동은 사이클 끝을 기다리지 않습니다. 다음 세 조건 중 하나라도 충족되면 그 자리에서 발동합니다.
- Day 1이 끝난 시점에 배포 가능한 수직 슬라이스가 하나도 없다.
- 컴퓨트 예산을 소진했는데 필수 항목(must-have)으로 잡은 스코프가 오르막에 남아 있다.
- 에이전트가 같은 스코프에서 상호 모순되는 접근을 3회 이상 반복한다.
두 번째 조건은 둘 중 하나가 아니라 둘의 결합입니다. 예산을 다 쓴 것만으로는 발동하지 않고, 예산이 넉넉한데 오르막이 남아 있는 것도 정상입니다. 쓸 수 있는 것을 다 쓰고도 필수 항목이 여전히 오르막에 있다는 조합이 신호입니다.
발동했을 때 내놓아야 하는 산출물은 실패 보고서가 아니라 복귀 메모입니다. 어떤 의도가 불명확했는지, 어떤 래빗 홀(rabbit hole)이 피치에 신고되지 않은 채 남아 있었는지를 적습니다. 이 메모가 셰이핑 트랙의 입력이 되어 다음 피치를 고칩니다. 브레이커가 벌이 아니라 학습 장치가 되는 지점입니다.
브레이커에 걸리지 않고 사이클 끝까지 살아남은 베팅은 무엇으로 청산될까요. 원작이라면 출시가 답이었습니다. 그러나 사람이 한 줄도 읽지 않은 코드가 배포되는 시대에, 완료의 기준은 한 항목을 더 요구합니다.