Kent Beck — 오래된 공학을 새 도구 앞에서 다시 시험한다
원문은 Kent Beck을 Extreme Programming의 창시자, TDD의 발명자, 애자일 선언의 공동 서명자로 소개한다. 1999년의 《Extreme Programming Explained》가 소프트웨어 개발 프로세스에 큰 영향을 주었다는 배경도 함께 제시한다.
프로세스를 발명한 사람이 Agent와 직접 부딪힌다
AI 코딩이 확산된 뒤 Beck은 관찰자에 머물지 않았다. Claude Code로 B+ 트리 라이브러리인 BPlusTree3를 만들었고, Rust와 Python 구현을 통해 생산 환경에 가까운 성능을 목표로 실험했다.
AI 전용 기법이 아니라 기존의 좋은 공학을 가져온다
Beck은 AI를 위해 완전히 새로운 규칙을 발명하기보다 자신이 수십 년 동안 복잡한 소프트웨어를 다루며 검증해 온 규율을 옮겨 쓴다. 원문은 바로 이 점을 Harness Engineering의 중요한 증거로 본다.
CLAUDE.md — 역할보다 더 중요한 것은 원칙이다
원문에서 Beck의 CLAUDE.md는 길고 화려한 Prompt가 아니다. 핵심은 “숙련된 소프트웨어 엔지니어처럼 행동하고, Kent Beck의 TDD와 Tidy First 원칙을 따른다”는 짧은 방향 설정이다.
숙련된 소프트웨어 엔지니어로서 일하되, TDD와 Tidy First의 규율을 작업 과정의 기본값으로 삼는다.
TDD — Red → Green → Refactor가 Agent의 작업 속도를 묶는다
TDD는 손으로 코드를 쓰던 시대에는 좋은 개발 습관이었다. AI가 코드를 쓰는 시대에는 그 습관이 외부 Harness가 된다. 먼저 실패를 만들고, 최소한으로 통과시키고, 그 뒤에 구조를 정리하게 한다.
무엇이 아직 없는지 명확해진다.
Constraint — 작업 순서를 묶는다
Agent가 요구를 받자마자 구현으로 달려가지 못하게 한다. 테스트가 먼저라는 순서가 coding ahead를 억제하는 경계가 된다.
Feedback — 성공과 실패를 외부화한다
“괜찮아 보인다”가 아니라 테스트의 통과·실패로 현재 상태를 판단한다. 자기확신을 실행 가능한 신호로 바꾼다.
Tidy First — 구조 변경과 행동 변경을 같은 commit에 섞지 않는다
Beck의 두 번째 축은 변경의 성격을 분리하는 것이다. 코드의 모양을 바꾸는 일과 프로그램의 행동을 바꾸는 일을 한 덩어리로 묶지 않는다.
구조를 바꾸되 행동은 그대로 둔다
읽고 유지하기 쉬운 형태로 바꾸는 작업이다.
- 코드 재배치
- 이름 개선
- 함수 추출
- 구조 정돈
MIX
프로그램이 하는 일을 바꾼다
사용자에게 보이는 기능과 동작을 변경하는 작업이다.
- 새 기능 추가
- 버그 수정
- 동작 규칙 변경
- 결과 변화
첫 두 번의 실패 — Agent는 코드로 설계 결함을 덮으려 한다
Beck의 BPlusTree3 실험은 처음부터 성공하지 않았다. 원문은 앞선 두 번의 시도가 실패했다고 적는다. 복잡성이 너무 빠르게 누적되어 Agent가 코드베이스 안에서 길을 잃었다.
실패 1 — 복잡성의 누적
기능이 진행될수록 코드와 결정이 겹쳤고, Agent가 어느 부분을 어떻게 바꿔야 하는지 판단하기 어려운 상태가 됐다.
실패 2 — 설계보다 구현이 앞섬
작업을 받자마자 코드를 쓰기 시작하면서 계획과 설계가 코드량에 묻혔다. 구현 속도가 결함을 늦게 드러내는 가림막이 됐다.
Coding Ahead
원문이 강조하는 핵심 교훈은 설계 결정에 더 적극적으로 개입하고 AI의 조기 구현을 막아야 한다는 것이다. Agent는 일을 받으면 바로 구현을 시작하려는 경향이 있다.
Augmented Coding과 Vibe Coding — 어느 것이 옳은가가 아니라 어디에 쓰는가
Beck은 두 방식을 선악으로 나누지 않는다. 둘 다 가치가 있지만 유지보수해야 하는 생산 시스템과 짧게 쓰고 버릴 수 있는 탐색 프로젝트를 같은 방식으로 다뤄서는 안 된다고 구분한다.
| 구분 | Augmented Coding | Vibe Coding |
|---|---|---|
| 무엇을 중시하는가 | 코드 품질, 복잡도, 테스트 커버리지 | 시스템 행동과 최종 결과 |
| 가치관 | 손으로 작성한 코드와 같은 기준 — 깨끗하고 동작하는 코드 | 일단 실행하고 오류를 다시 AI에 넘기는 빠른 반복 |
| 사람의 역할 | 설계 결정을 주도하고 AI가 실행 | 요구를 설명하고 구현을 AI에 크게 위임 |
| 적합한 상황 | 장기 유지보수가 필요한 생산 코드 | 프로토타입, 일회성 스크립트, 탐색 프로젝트 |
생산 시스템 — Augmented Coding
오래 유지해야 하고 많은 사용자를 책임지는 코드라면 설계·테스트·복잡도 관리에 인간이 계속 개입한다.
짧은 탐색 — Vibe Coding
주말 hackathon, 일회성 실험, 빠른 아이디어 검증처럼 지속적인 유지보수 비용이 핵심이 아닌 상황에서는 충분히 유효할 수 있다.
왜 이 사례가 중요한가 — TDD는 이미 Harness였다
원문은 Harness Engineering이 AI 시대에 갑자기 생겨난 완전히 새로운 학문이라는 관점을 거부한다. TDD와 Tidy First가 이미 오래전부터 작업 순서, 피드백, 변경 단위를 통제해 왔기 때문이다.
테스트를 먼저 쓰게 해 구현의 순서를 제약하고, 통과·실패라는 명확한 피드백을 만든다.
구조 변경과 행동 변경을 분리해 각 변화가 추적·검증·rollback 가능하게 만든다.
사람이 스스로 지키던 규율을 이제 Agent에게 외부 조건으로 제공한다.
사람이 TDD로 자신의 구현 순서를 통제하고, Tidy First로 commit의 성격을 관리한다.
같은 규율을 CLAUDE.md와 작업 흐름으로 옮겨 AI의 행동과 변경 단위를 통제한다.
원문이 도달하는 결론은 단순하다. 좋은 공학 규율은 실행자가 사람인지 기계인지 크게 가리지 않는다. 사람도 테스트를 건너뛰고, AI도 테스트를 건너뛴다. 사람도 구조와 행동을 섞고, AI도 섞는다. 그래서 오래된 규율은 사라지는 대신 새로운 실행자를 위한 Harness로 돌아온다.
새 시대는 옛 지혜를 모두 낡게 만들지 않는다.
오히려 무엇이 유행이었고 무엇이 원리였는지를 드러낸다.
TDD는 테스트의 기술이기 전에 서두르지 않는 순서였고,
Tidy First는 정리의 기술이기 전에 변화의 원인을 잃지 않는 규율이었다.
사람이 쓰던 코드를 AI가 쓰기 시작해도
복잡성이 생기는 방식과 실패가 쌓이는 방식은 크게 달라지지 않는다.
그래서 좋은 Harness는 미래에서만 오지 않는다.
오래 검증된 공학을 새로운 실행자에게 건네는 데서도 시작한다.