요건 정의를 작성하고 자는 동안 앱이 만들어졌던 이야기 (CoDD v2.17 마일스톤, 일어나서 감상을 말하면 지속적 개선도 자동)

결론부터 말하겠다

내가 꿈꾸는 이상적인 개발은 이렇다.

1. 요건 정의서(Requirements Definition)를 작성한다 ← 나
2. 하네스(Harness)를 한 번 실행하고 잠든다 → 아침에 일어나면 앱이 완성되어 있다 ← AI

아침에 일어나서 앱을 만져보고, 신경 쓰이는 부분이 있으면 이렇게 말한다.

codd fix "로그인 에러를 알기 쉽게 하고 싶어"

→ 설계서도 소스 코드도 테스트도, 전부 수정되어 돌아온다.

내가 만진 것은 「요건 정의서」와 「만진 후의 감상」 딱 두 번뿐이다.

이것이 내가 3년 전부터 말해온 북극성이다.

"인간은 요건 정의와 시스템을 만진 후의 감상만을 말하게 된다"

CoDD v2.17

드디어 이 북극성에 도달했다. 대단하지 않은가?

CoDD란 무엇인가

CoDD = **Coherence-Driven Development** (정합성 주도 개발)

내가 명명한 방법론이다. 「설계서 ↔ 코드 ↔ 테스트」가 항상 동일한 사실을 말하고 있는 상태를 AI가 자율적으로 유지한다.

전국시대 가신단 계보도에 비유하자면, 누가 누구의 밑에 있고 누가 누구에게 명령하는지가 가계도로 제대로 관리되고 있는 상태와 같다. 코드와 설계서와 테스트 사이에도 이것을 구축하는 것이 CoDD다.

왜 만들었는가. 내가 SIer 시절에 「설계서가 부패하는 것을 지겹도록 보았던」 반동이다. 설계서를 보면 최신 사양을 알 수 있어야 하는데, 아무도 믿지 않는다. 코드를 읽지 않으면 진실을 알 수 없다. 그 절망을 AI로 때려눕히고 싶었다.

하룻밤 하네스 【신규 개발 편】

requirements.md를 한 장 작성했다면, 자기 전에 이것을 실행한다.

#!/usr/bin/env bash
# CoDD 하룻밤 하네스
codd init my-project # 초기화 (최초 1회)
...

아침에 일어나면 설계서도 코드도 테스트도 갖춰져 있다. 진짜로.

codd elicit

을 통해 AI가 요건의 빈틈을 찔러오기 때문에 (예: "로그인은 OAuth인가요? 아니면 패스워드인가요?" 등), 자기 전에 몇 차례 대화를 나눈 뒤 잠드는 것이 현실적이다.

사용 후 하네스 【지속적 개선 편】

신규 개발이 끝난 후, 앱을 만져보며 신경 쓰이는 점을 자연어로 던진다.

codd fix "로그인 에러를 알기 쉽게 하고 싶어"
codd fix "대시보드 로딩을 빠르게 하고 싶어"
codd fix "모바일에서 버튼이 누르기 힘들어"
...

codd fix는 내부적으로 다음과 같이 동작한다.

• 「로그인」, 「에러」와 같은 키워드로부터 관련 설계서를 탐색
• 후보가 여러 개라면 「어느 것을 수정할까요?」라고 질문
• 「알기 쉽게」가 모호하다면 「문구 평이화? 도움말 추가? 재시도 절차 표시?」와 같이 선택지를 제시
• 설계서 → 구현 코드 → 테스트를 순서대로 업데이트
• 마지막으로 「가계도에 모순 없음」을 확인

질문 내용 자체도 AI가 생성한다. 하드코딩은 제로, 간섭은 최소한으로.

--non-interactive

를 붙이면 모호할 때 묻지도 따지지도 않고 중단하므로, CI에서 야간 배치 작업에 포함할 수 있다.

왜 이것이 가능한가 — 가계도 덕분

CoDD는 내부적으로 설계서, 코드, 테스트를 「의존성 맵(Dependency Map)」으로 가지고 있다. 가계도 같은 것이다.

전문 용어로 말하면 DAG (Directed Acyclic Graph, 방향성 비순환 그래프)이다. 전국시대 가신단 계보도와 마찬가지로, 누가 누구의 가신인지 명확하게 결정되어 있다.

구체적으로는 다음과 같은 구조다. 로그인 기능의 가계도:

요건 정의 아래에 설계서, 설계서 아래에 구현, 구현 아래에 테스트. 완전히 상하 관계가 결정되어 있다.

설계서 A를 수정하면, CoDD는 가계도를 따라 아래의 가신들(구현과 테스트)을 전부 함께 수정한다. 예를 들어 인증 설계를 「OAuth 대응으로 변경」이라고 고쳐 쓰면:

빨간색은 변경점, 노란색은 자동으로 따라오는 가신들이다.

누락이 있다면 가계도 검사 (codd dag verify)
가 "여기 가신이 없다"며 할복을 명한다.

「설계서 부패」가 일어나지 않는 이유는, 변경할 때마다 가계도를 따라 전부 함께 수정하기 때문이다. 혼자서 모두를 거느리는 것은 AI의 역할이다. 나(주군)는 판단만 하고 있으면 된다.

v2.17까지 도달한 수치

벤치마크로 실증했다.

SWE-bench Lite (Python OSS 73문항의 실제 버그 수정 벤치마크)에서:

• Codex GPT-5.5 단독: 73 / 73 (100%) ← 단독으로 전승
• Claude Opus 4.7 단독: 66 / 73 (90.4%)
• 두 모델 합산: 73 / 73 (100%)

이전 버전 (v2.11.0)과의 비교:

Backend	v2.11.0	v2.17.1	Δ
Claude	62/73 (84.9%)	66/73 (90.4%)	+4
Codex	69/73 (94.5%)	73/73 (100%)	+4

CoDD를 v2.11.0 → v2.17.1로 진화시켰더니, 벤치마크 (Benchmark)에서 +4문제를 더 풀 수 있게 되었다. 대단하지 않은가?

그런데 v1 계열은 "greenfield조차 제대로 작동하지 않았다"

진화의 드라마를 이야기하기 전에, 출발점의 실태를 솔직하게 적어둔다.

v1.34 이전의 codd implement

(= AI에게 구현 코드를 작성하게 하는 명령)은 이런 상태였다.

• AI가 생성한 코드 끝에 markdown 해설 텍스트가 혼입되어 있음 - 결과적으로 TypeScript 컴파일러가 **674개의 전사 (타입 에러 (Type Error))**를 뱉음
• codd init --language를 지정해도 설계서 내의 지정이 무시되어 다른 언어가 나옴
• codd extract가 Python 프로젝트에서 0개의 소스 파일밖에 분석하지 못함

"아무것도 없는 상태에서의 신규 개발" (greenfield)조차 이 모양이었다. 코드를 생성하게 하면 markdown 혼입으로 674명이 전사하고, 다시 한번 부탁하면 똑같은 일을 반복한다. 완전히 AI 군이 계속 멍청해져 있는 상태다.

그것을 5일 만에 v2.17.1까지 뜯어고쳤다.

v1.34 ─────→ v2.17.1 ─────→ v2.18.x 이후
greenfield greenfield brownfield
곤란 완료 ★지금 여기★ (다음 도전)

brownfield (기존 시스템 개선)의 기초 부품 (codd extract / codd diff)은 갖춰져 있다. 다만 codd fix "현상"을 실제 brownfield 환경에 던지는 실증은 아직이다. 이것이 v2.18.x 이후의 도전이다.

5일 만에 17번의 minor 버전 폭주 진화

시계열을 붙여둔다.

날짜	주요 릴리스	내용
5/7 (목)	v1.35.0	codd elicit + lexicon (업계 표준 사전, 업계별 lint 같은 것)
5/8 (금)	v1.36 → v2.0 → v2.8	하루 만에 12 minor, Lexicon-Driven Completeness milestone
5/9 (토)	v2.9.0	데이터·기능 특성 기반의 lexicon 권장
5/10 (일)	v2.10 → v2.13	cross-industry lexicon / sprint 개념 폐지 / 정합성 gate / opt-out 보호
5/11 (월)	v2.14 → v2.17.1	구조적 결함 8건 수정 / 공유 부품 / 치명적 버그 patch codd fix [PHENOMENON]

5일. "인간이 요건 정의와 감상만 작성한다"라는 북극성(North Star)에 드디어 도달했다.

그런데 나, 5일 동안 CoDD 소스 한 줄도 안 읽었는데 ㅋㅋㅋ

여기까지 읽고 "그래서, 네가 쓴 거잖아?"라고 생각한 사람.

코드는 한 줄도 읽지 않았다. PR diff조차 열어보지 않았다.

내가 5일 동안 한 일:

• 장군 (Claude shogun)과 이자카야 톤으로 대화
• AI 부하에게 "해둬", "이거 고쳐", "대박이지 않아?"라고 시키기
• 벤치마크 표만 보며 "100% 찍고 있잖아"라고 하기

담당:

• 주군 (나): 명명·북극성·"default 실격" 같은 판단
• 군사 (Claude Opus 4.7): 설계서를 작성
• 아시가루 (Codex GPT-5.5): 코드로 구현
• 가로 (Claude Sonnet 4.6): 태스크 분해 + 검수 + merge

5일 만에 17번의 minor 릴리스, 구조적 결함 8건 수정, SWE-bench 100%. 내가 본 것은 git log의 숫자와 벤치마크 표뿐이다.

CoDD의 북극성인 "인간은 요건 정의와 감상만을 말하게 된다"를, CoDD를 만드는 측에서도 실증하고 있었다는 중첩 구조. 대단하지 않은가?

아, 쓰다 보니 깨달았는데, 나 엔지니어 맞나...?

여기까지 쓰다 보니 갑자기 불안해졌다.

5일 동안 17개의 minor 업데이트, 벤치마크 100%, 그런데 코드 한 줄도 읽지 않았다. git log의 숫자만 바라보고 있었을 뿐. 그런데도 "엔지니어입니다"라고 자처해도 되는 걸까.

하지만 생각해보니, 내가 했던 일은 이것이다:

정합성 주도(Coherence-Driven Development)라는 방법론을 명명했다 -
Harness Engineering이라는 업계 계층 (Prompt → Context → Harness)을 정리했다 -
가계도 검사(codd dag verify)라는 메타포를 두었다 -
codd elicit, codd fix [PHENOMENON]의 커맨드 이름과 동작을 결정했다

전부 "개념화"와 "명명"이다.

AI 시대의 엔지니어는, 쓰는 사람에서 명명하는 사람으로 포지션이 이동하고 있다는 느낌이 든다. 쓰는 것은 AI, 판단하는 것은 사람, 개념에 이름을 붙이는 것도 사람.

응, 아마 나는 이런 형태로 살아갈 것이다. 코드를 쓰고 있지는 않지만, 이것이 나의 일이다.

AI 부하와의 랠리 — "타임아웃으로 넘어지는 default는 실격이잖아"

multi-agent-shogun (내가 운용하고 있는 멀티 에이전트 기반, 쇼군이 영주, 가로가 지휘, 군사가 설계, 아시가루가 구현) 위에서, AI 부하와 1대 1로 논의하며 CoDD를 진화시켰다.

그중 하나.

군사 (Claude Opus, 설계 담당)가 SWE-bench의 개선안으로 "AI 타임아웃을 1800초로 통일"이라고 써왔다. 그것에 대해 나는:

"타임아웃으로 넘어지는 일이 빈번하게 발생하는 값은, 애초에 default 값으로서 실격이잖아"

군사가 즉시 메모화했다.

"영주 원칙 = 사용자가 빈번하게 넘어지는 default는 실격. timeout / retry / batch / token 전부, 실체 (P99+마진) 베이스로 결정한다"

3600초로 변경. 이것이 v2.14.0에서 모든 커맨드에 통일되었다.

"default의 철학"이란 업계에서 모호하게 다뤄지지만, 내 관점에서는 **"사용자가 넘어지면 그것은 bug"**다. default는 "동작함"이 보장되어 있지 않으면 안 된다. "빠르지만 실패하는 것"보다 "느리지만 성공하는 것"을 택해라, 그것을 최적화하고 싶은 사용자는 env var로 낮추면 된다.

API 비용

5일 만에 v1.35 → v2.17.1로 진화시킨 실제 비용:

• Claude Max 플랜 (월 $200)
• ChatGPT Pro 플랜 (월 $200)

월 $400. 추가 API 과금 없음. 구독 범위 내.

이것을 종량제(Pay-as-you-go)로 계산하는 것이 무서워서 아직 해보지 않았다.

써보고 싶은 분

pip install codd-dev
codd init my-project
codd elicit
...

Star를 눌러준다면 울면서 기뻐하겠다.

덤 — 업계 계층론으로 말하자면

Layer 1: Prompt Engineering (전술 / 개별 prompt 최적화)
Layer 2: Context Engineering (전략 / 컨텍스트의 품질 설계)
Layer 3: ★Harness Engineering★ (기반 / 정합성을 AI가 자율 유지하는 플로우)
...

CoDD는 Harness Engineering의 OSS 구현이라는 위치에 있다.

Kiro (AWS)나 cc-sdd 같은 다른 Spec-Driven Dev 툴은 Context Engineering 수준에 머물러 있다. CoDD는 context drift (설계서와 코드의 괴리)를 자율 유지하는 Harness 레이어까지 발을 들이고 있다는 것이 나의 정리다.

이 이상의 계층이 발견된다면, 다시 글을 쓰겠다.

"요건 정의와 감상밖에 쓰지 않게 되는 세계"의 입구, 여기에 놓아두겠다.

덤의 덤 — "명명하는 사람"의 모티브, 사실은 책으로 썼다

여기까지 읽고 "코드를 안 쓰는데 명명하는 사람이라니 무슨 소리야?"라고 생각한 사람.

사실 2월에 이 테마로 책을 한 권 썼다.

『AI의 사용법은 가르치지 않는다 — 생성형 AI 시대에 정말로 필요한 사고력』 (Zenn, 500엔)

주장은 한 줄: 언어화는 나, 구조화는 AI.

장 구성만 발췌:

• 「모르겠다」를 분해할 수 있는가 — 멘토링 현장에서
• 언어화해서 AI에게 던져라 — 구조화는 AI의 업무
• 컨텍스트 (Context)가 모든 것을 결정한다 — 거울의 법칙과 격차의 정체
• 사고의 외부화 엔진 — 생성형 AI (Generative AI)의 진짜 사용법

CoDD에서 "인간은 요건 정의와 감상만 쓰게 될 것이다"라고 말하는 것은, 이 책의 주장을 커맨드 (Command)로 구현했을 뿐이다. codd elicit

(AI가 요건의 빈틈을 질문함) = 「언어화해서 AI에게 던져라」의 자동화 버전.

「이름을 짓는 사람」이 되고 싶은 사람을 위한 체계적인 버전은 이쪽이다.