성숙도 모델

VDLC 도입 정도를 4단계로 나누어 팀이 지금 어디에 있고 다음에 무엇을 해야 하는지 가늠하는 기준이다.

성숙도는 도구 사용 여부가 아니라 절차와 자산의 정착 정도로 판정한다. 코딩 에이전트를 매일 쓰더라도 팀 공용 규칙과 검증 체계가 없다면 여전히 낮은 레벨이고, 반대로 도구 사용 빈도가 낮아도 의도 문서와 계획 승인 관문이 자리 잡았다면 그 팀은 이미 다음 레벨에 들어선 것이다.

4레벨 표

레벨	이름	특징	판별 신호
1	탐색(Exploring)	개인이 바이브코딩 실험 중, 프로세스 없음	프롬프트 세션마다 휘발, 검증은 "돌아가면 OK"
2	실천(Practicing)	개인/소수가 VDLC 사이클을 돌림	의도 문서 작성 시작, 컨텍스트 파일 존재, 계획 승인 관문 사용
3	자산화(Compounding)	팀 단위 컨텍스트 자산 축적·재사용	팀 공용 규칙/스킬/템플릿, 리스크 기반 검증, 환류 의례 정착
4	표준화(Systematizing)	조직 표준 정착, 지표로 관리	리드타임·재작업률 측정, 온보딩에 자산 재사용

레벨별 상세

L1 — 탐색(Exploring)

특징: 개인이 코딩 에이전트로 실험하고 있지만 팀 차원의 프로세스는 없다. 프롬프트와 그 결과는 각자의 채팅창 안에 머문다.

판별 신호: 세션이 끝나면 그 세션에서 합의한 내용도 함께 사라진다. 결과물을 믿을 수 있는지 판단하는 기준은 "일단 실행해서 돌아가면 OK" 수준이다. 같은 질문을 세션마다 다시 설명한다.

다음 레벨로 가는 열쇠: 결과물이 아니라 시작점을 남긴다 — 코드를 작성하기 전에 목적과 성공 기준을 문서 한 장으로 써보는 것.

L2 — 실천(Practicing)

특징: 개인 또는 소수가 여섯 단계 사이클을 의식적으로 돌린다. 의도 문서를 쓰고, 에이전트의 계획을 검토한 뒤에 구현을 진행한다.

판별 신호: 의도 문서 작성이 시작됐고, 프로젝트 규칙 파일(CLAUDE.md 등)이 존재한다. 계획 승인 관문을 쓰지만, 이 절차는 아직 개인의 습관이지 팀의 규칙은 아니다.

다음 레벨로 가는 열쇠: 개인의 규칙 파일과 습관을 팀 공용 자산으로 옮긴다 — 나 혼자만 참조하던 CLAUDE.md와 체크리스트를 팀 전체가 같이 쓰고 갱신하는 것으로 전환하는 것.

L3 — 자산화(Compounding)

특징: 팀 단위로 컨텍스트 자산이 축적되고 재사용된다. 검증 강도는 리스크에 따라 달라지고, 사이클이 끝날 때마다 배운 것을 자산에 반영하는 환류 의례가 정착돼 있다.

판별 신호: 팀 공용 규칙·스킬·템플릿이 존재하고 여러 사람이 같은 것을 참조한다. 리스크 등급에 따라 검증 강도를 구분하는 기준이 있다. 정기적인 환류(회고, 체크리스트 갱신)가 팀 일정에 들어 있다.

다음 레벨로 가는 열쇠: 정성적으로 "좋아지고 있다"는 감각을 정량 지표로 바꾼다 — 리드타임, 재작업률 같은 측정 지표를 실제로 재기 시작하는 것.

L4 — 표준화(Systematizing)

특징: VDLC가 특정 팀의 실천이 아니라 조직의 기본값이다. 지표로 효과를 관리하고, 신규 프로젝트와 온보딩이 기존 자산 재사용을 전제로 시작한다.

판별 신호: 사이클 리드타임·재작업률 같은 지표를 정기적으로 측정하고 의사결정에 쓴다. 온보딩 과정에서 신규 합류자가 조직 표준 컨텍스트 자산을 재사용한다.

표준을 유지하는 열쇠: 지표가 나빠지는 신호를 방치하지 않는다 — 표준화는 도달한 상태가 아니라 측정 지표로 계속 점검하며 유지하는 상태다.

셀프 진단 체크리스트

다섯 가지 원칙별로 3문항씩, 총 15문항이다. 각 원칙 안에서 문항은 난이도 순으로 배치했다 — 1번(Q1)은 L2(실천) 수준에서, 2번(Q2)은 L3(자산화) 수준에서, 3번(Q3)은 L4(표준화) 수준에서 자연스럽게 "예"가 되는 문항이다. 뒤의 레벨 판정은 이 Q1/Q2/Q3 계열별로 따로 집계하므로, 답할 때 각 문항이 몇 번(Q1/Q2/Q3)인지 함께 표시해두면 채점이 쉽다. 모두 관찰 가능한 사실을 묻으므로 예/아니오로만 답한다.

원칙 1 — 의도가 소스다

• [ ] Q1. 기능 작업을 시작하기 전에 목적과 성공 기준을 문서 한 장으로라도 남긴다.
• [ ] Q2. 팀이 공유하는 의도 문서 형식(6-pager, PR-FAQ 등)이 있고 대부분의 작업에 실제로 쓰인다.
• [ ] Q3. 의도 문서에 적은 성공 기준을 사후에 검토해, 다음 의도 문서의 품질 기준으로 반영한다.

원칙 2 — 인간은 판단하고, AI는 실행한다

• [ ] Q1. 에이전트가 제안한 구현 계획을 코드 작성 전에 사람이 검토·승인한 적이 있다.
• [ ] Q2. 계획 승인 관문이 개인 습관이 아니라 팀의 문서화된 절차로 정착돼 있다.
• [ ] Q3. 무엇을 만들지·언제 배포할지에 대한 판단 권한과 실행 위임 범위가 조직 차원에서 명문화돼 있고 온보딩에서 다룬다.

원칙 3 — 속도는 검증이 결정한다

• [ ] Q1. 에이전트 산출물을 자동화된 테스트나 정적 분석 없이 병합하는 경우가 거의 없다.
• [ ] Q2. 리스크 수준에 따라 검증 강도(자동 검증만 vs 인간 리뷰 필수)를 구분하는 기준이 팀에 있다.
• [ ] Q3. 검증 통과율(1회 통과 비율) 같은 지표를 정기적으로 측정하고 검증 체계 개선에 사용한다.

원칙 4 — 컨텍스트는 자산이다

• [ ] Q1. 프로젝트 규칙 파일(CLAUDE.md 등)이 존재하고 실제로 참조된다.
• [ ] Q2. 팀 공용 컨텍스트 자산(스킬, 위키, 컨벤션)이 있고 여러 사람이 재사용한다.
• [ ] Q3. 컨텍스트 자산의 증가·재사용 현황을 추적하고, 신규 프로젝트가 기존 자산 재사용을 기본으로 시작한다.

원칙 5 — 작게 돌리고, 자주 환류한다

• [ ] Q1. 의도-구현-검증 한 사이클이 스프린트 단위가 아니라 하루~며칠 단위로 돈다.
• [ ] Q2. 사이클이 끝날 때마다 배운 것을 규칙·체크리스트·위키로 옮기는 환류 의례가 팀 일정에 있다.
• [ ] Q3. 환류의 결과가 조직 지표(리드타임, 재작업률 등) 개선으로 이어지는지 추적한다.

레벨 판정 규칙 (계층형 매핑)

15문항의 "예" 개수를 단순 합산하지 않는다. 대신 Q1/Q2/Q3 계열(각 5문항, 원칙마다 하나씩)을 따로 집계해, 위 단계부터 순서대로 조건을 확인한다.

확인 순서	조건	조건 충족 시 레벨
1	Q3 계열(3번 문항 5개) 중 "예" 3개 이상	L4 표준화(Systematizing)
2	(1 미충족 시) Q2 계열(2번 문항 5개) 중 "예" 3개 이상	L3 자산화(Compounding)
3	(1·2 미충족 시) Q1 계열(1번 문항 5개) 중 "예" 3개 이상	L2 실천(Practicing)
4	위 세 조건 모두 미충족	L1 탐색(Exploring)

위에서부터 순서대로 확인해 처음 만족하는 조건의 레벨을 최종 레벨로 삼는다(상위 조건을 만족하면 하위 조건은 확인하지 않는다). 임계값을 5문항 중 3개로 잡은 것은 스펙의 레벨별 판별 신호가 각각 3개 안팎의 항목(예: L2 = 의도 문서·컨텍스트 파일·계획 승인 관문 3가지)으로 구성돼 있기 때문이다 — 계열마다 그 신호에 대응하는 문항이 하나씩(5원칙 × 1문항 = 5문항) 있으므로, 그중 과반(3개 이상)이 "예"면 해당 레벨의 신호가 실제로 발현되고 있다고 본다.

단순 합산 방식은 Q1/Q2/Q3가 서로 다른 성숙도 신호를 대표한다는 점을 무시해 경계에서 오판을 낳는다. 예를 들어 스펙의 L2 판별 신호 3가지에 정확히 해당하는 문항만 "예"인 팀은 총합이 3이라 합산식으로는 L1로 잘못 판정되지만, 계열형 규칙에서는 Q1 계열 3개 이상을 충족해 정확히 L2로 판정된다. 마찬가지로 L2 신호를 모두 충족(Q1 계열 5개)한 데다 L3 판별 신호 3가지까지 갖춘 팀은 합산식으로는 총합 8로 L2에 머물지만, 계열형 규칙에서는 Q2 계열 3개 이상을 충족해 정확히 L3로 판정된다.

체크리스트는 자기 평가용이며 팀 전체가 각자 답한 뒤 결과를 맞춰보는 방식을 권한다. 답이 크게 갈리는 문항이 있다면, 그 자체가 팀 안에 공유되지 않은 절차가 있다는 신호다. 진단 결과에 맞는 다음 단계는 도입 로드맵에서 확인한다.