도입 사례 — 소규모 팀 신규 서비스

이 사례는 로보코 자체 개발 경험을 익명화해 재구성한 것이다. 서비스명·구체 수치는 실제와 다르며, 흐름과 판단 지점만 사실에 기반한다.

상황

대상은 신규 서비스를 처음부터 만드는 소규모 팀이었다. 레거시 코드도, 지켜야 할 기존 규칙도 없는 그린필드였다. 팀은 이미 코딩 에이전트를 일상적으로 쓰고 있었지만, 그 자체가 VDLC를 따른다는 뜻은 아니었다. 초기 몇 주는 프로토타입을 빠르게 뽑아보는 데 집중했고, 의도 문서 없이 채팅창에서 바로 기능을 요청하는 방식이 대부분이었다.

VDLC 풀사이클 적용

첫 균열

프로토타입 단계에서는 문제가 드러나지 않았다. 리스크가 낮고 되돌리기 쉬운 화면 단위 작업이었기 때문이다. 그러나 핵심 기능 하나가 여러 화면과 데이터 모델에 걸치기 시작하면서 균열이 생겼다. 세션마다 다른 맥락에서 같은 질문에 다르게 답하는 일이 반복됐고, 어제 합의한 것 같았던 정책이 오늘 세션에서는 다시 논쟁거리가 됐다. 매니페스토가 짚은 "컨텍스트 없는 프롬프트" 안티패턴이었다. 구현은 계속 빨랐지만, 팀은 스스로 무엇을 만들고 있는지 점점 설명하기 어려워졌다.

풀사이클로 전환

이 시점에 팀은 기능 단위마다 1단계 — 의도 정의부터 다시 시작하기로 했다. 큰 문서가 아니라 짧은 PR-FAQ 한 장으로 "이 기능이 성공하면 무엇이 달라지는가"만 못 박고, 2단계 — 컨텍스트 설계에서 그때까지 반복해서 설명하던 도메인 규칙을 CLAUDE.md에 옮겼다. 3단계 — 공동 구현에서는 계획을 먼저 승인받은 뒤 구현에 들어가는 관문을 세웠고, 4단계 — 검증에서는 기능의 되돌림 가능 여부에 따라 검증 강도를 나눴다. 사이클 하나는 길어야 며칠, 짧으면 하루 안에 끝났다.

복리 효과

몇 차례 사이클을 돌고 나자 변화가 보이기 시작했다. 새 기능을 시작할 때 반복 설명해야 하는 것이 눈에 띄게 줄었다. CLAUDE.md와 도메인 위키가 쌓이면서, 에이전트에게 매번 처음부터 맥락을 넣어주지 않아도 이전 사이클의 결정을 그대로 참조할 수 있었기 때문이다. 6단계 — 환류에서 반복 지시를 규칙으로, 검증에서 잡힌 실수 패턴을 체크리스트로 옮기는 습관이 자리 잡자, 뒤로 갈수록 같은 크기의 기능을 더 짧은 사이클로 끝낼 수 있었다. 매니페스토의 원칙 4(컨텍스트는 자산이다)가 말한 복리 구조를 소규모 팀 안에서 직접 확인한 셈이다.

이 과정이 매끄럽기만 했던 것은 아니다. 짧은 사이클을 강조하다 보니 한동안 검증 단계를 생략하는 유혹이 있었다. "어차피 그린필드니까 나중에 고치면 된다"는 판단이 두어 번 회귀 버그로 돌아온 뒤에야, 리스크가 낮은 영역이라도 자동 테스트만큼은 사이클마다 반드시 통과시키는 규칙으로 못 박았다.

교훈

이 팀은 성숙도 모델의 L2 실천(Practicing) 단계에서 시작해, 그린필드 특유의 빠른 반복 덕분에 비교적 짧은 기간에 L3 자산화(Compounding) 단계로 이동했다. 신규 서비스라고 해서 의도 정의와 검증을 생략해도 되는 것은 아니라는 점이 핵심 교훈이다. 오히려 규칙이 없는 그린필드일수록 첫 몇 사이클에서 무엇을 컨텍스트 자산으로 남길지 의식적으로 결정해야, 이후 사이클이 복리로 빨라지는 구조가 일찍 자리 잡는다.