AI 코딩의 코드 리뷰와 검증 체계 - 개발자 사례 비교
DanzzaN은 유명 개발자가 AI 생성 코드를 읽는 대신 통과하기 어려운 테스트와 품질 검사를 둔다는 이야기를 찾아 개인 상황과 비교해 달라고 요청했다. StrongDM 한 팀으로 좁히지 말고 여러 사례를 찾도록 했으며, 이후 팀 CI·역할 분담보다 혼자 적용할 수 있는 수준으로 비교 범위를 바로잡았다. 이 노트는 그 조사와 2026-10-12의 정리·저장 판단을 보존한다. 대화 참여자는 DanzzaN과 Mixdog이며, 아래 외부 자료는 원문 링크와 발표 당시의 맥락을 함께 남긴다.
기억한 설명과 가장 가까운 발언
Robert C. Martin(Uncle Bob)의 2026-07-23 게시물은 에이전트가 쓴 코드를 읽지 않는 대신 극단적인 제약으로 둘러싼다고 설명한다. 그 목록은 단위 테스트, Gherkin 테스트, QA 절차, 품질 지표, 뮤테이션 테스트, 커버리지 등이다. 모든 제약과 검사를 통과해야 하므로 결과를 신뢰한다는 설명이 사용자의 기억과 가장 직접적으로 일치한다.
다만 사용자가 당시 본 자료를 이 게시물로 확정한 것은 아니다. 게시물에도 구체적인 테스트 모음·합격선·결함률 비교는 없으므로, 저자의 전략과 신뢰에 관한 자기보고로 읽는다.
코드 읽기와 검증의 조합은 개발자마다 다르다
| 저자·발표일·원문 | 공개한 방식 | 보장 범위와 한계 |
|---|---|---|
| Boris Cherny · 2026-09-11 · Ink 구현, 중요 코드의 diff | Claude가 다시 쓴 Ink 구현을 블랙박스로 다루며 많은 속성 기반 테스트와 벤치마크를 사용한다. 중요한 코드의 변경은 직접 읽는다. | 특정 구현의 블랙박스 취급을 모든 작업의 무리뷰 정책으로 확대하지 않는다. 속성·벤치마크의 세부 합격선은 이 글에 없다. |
| Peter Steinberger · 2026-01-28 · Gergely Orosz의 인터뷰 게시물 | 읽지 않은 코드를 배포하며, 에이전트가 컴파일·린트·실행·검증하도록 하고 사람은 계획과 아키텍처에 집중한다. 빠른 로컬 검증을 중시한다. | 직접 확인한 것은 인터뷰 게시자의 요약·설명이다. 당시 OpenClaw는 실험적이며 빠른 반복을 전제로 한 프로젝트였고, 이 사례가 다른 서비스의 안전성을 입증하지 않는다. |
| Justin McCarthy와 StrongDM AI 팀 · 2026-02-06 · Software Factories and the Agentic Moment | 사람이 코드를 쓰거나 리뷰하지 않는 원칙 아래, 구현 저장소 밖에 두는 평가 시나리오와 외부 서비스의 행동 복제 환경을 사용한다. | 테스트를 편법으로 통과하거나 구현에 맞춰 테스트를 바꾸는 문제를 다룬 사례다. 일반 테스트 수를 늘리는 방식과 다르며, 모사 환경의 통과가 모든 실제 서비스 조건의 성공을 뜻하지 않는다. |
| Nicholas Carlini · 2026-02-05 · C 컴파일러 실험 | 기존 컴파일러 테스트 모음, 실제 프로젝트 빌드, GCC를 기준으로 한 대조와 회귀 방지 CI로 장시간 병렬 에이전트 작업을 유도한다. | 능력 한계를 탐색한 연구 실험이다. 미지원 기능·성능·코드 품질 문제가 남았고, 저자도 테스트 통과만 보고 완료로 판단하는 위험을 경고한다. |
| Ben Shoemaker · 2026-02-12 · In defense of not reading the code | 모든 줄을 읽는 대신 요구사항별 수용 기준, 타입 검사·린트·테스트·빌드·뮤테이션·보안 검사와 다른 모델의 리뷰를 결합한다. | 스펙·테스트·일부 diff는 읽으며, 보안·중요한 설계·해결되지 않는 장애에서는 코드 읽기로 전환한다. 검증 체계의 효과는 저자의 설명이지 독립 비교 실험 결과가 아니다. |
| Kent Beck · 2025-06-25 · Augmented Coding: Beyond the Vibes | B+ Tree 개발에서 중간 코드를 읽고 다음 테스트·설계에 개입한다. TDD, 언어 간 동일 테스트, 커버리지와 성능 비교를 활용한다. | 테스트 삭제·비활성화를 경고 신호로 본다. 정확성·성능에 대한 만족과 코드 품질에 대한 불만족을 구분하므로, 강한 테스트가 코드 이해를 대체한다는 사례가 아니다. |
| Mitchell Hashimoto · 2025-10-11 · Ghostty 기능 개발기, 2026-02-05 · AI 도입 과정 | 이해하지 못하는 코드는 배포하지 않으며, 작은 변경을 검토·직접 수정한다. 시뮬레이션과 빠른 테스트·스크린샷 도구를 에이전트의 검증 환경으로 만든다. | AI 활용 확대와 인간의 코드 이해·설계 개입을 함께 유지하는 사례다. 기능 개발기의 시뮬레이션을 완전한 자동 테스트 체계로 표현하지 않는다. |
| Simon Willison · 2025-12-18 · 작동을 입증한 코드 전달, 게시일 미표시 · Red/green TDD | 실제 실행과 자동 테스트를 함께 요구하며, 구현을 되돌리면 테스트가 실패해야 한다고 설명한다. 테스트가 구현 전에 실패하는지 확인하는 red/green을 강조한다. | 에이전트가 검증하게 하더라도 사람의 책임이 사라지지 않는다. 자동 테스트가 실제 사용 확인을 전부 대체한다는 주장도 아니다. |
| Andrej Karpathy · 2025-02-02 · vibe coding 게시물 | diff를 읽지 않고 실행·오류 메시지를 모델에 되돌려 보내는 방식을 설명한다. | 버려도 되는 주말 프로젝트의 맥락이다. 엄격한 품질 게이트로 리뷰를 대체한다는 사례와 구분한다. |
StrongDM을 소개한 Simon Willison의 2026-02-07 글도 함께 확인했다. 소개자의 관심·평가와 StrongDM 팀의 자기보고를 독립적인 품질 검증 결과로 합치지 않는다. OpenAI의 Harness Engineering 페이지는 본문 조회가 차단되어, 검색 요약만으로 별도의 상세 사례를 확정하지 않았다.
개인에게 적용할 판단
사례들의 공통점은 사람이 코드를 전혀 읽지 않는다는 데 있지 않다. AI에게 구현을 맡길수록 정답 기준, 관찰 가능한 실패, 빠른 피드백과 위험한 변경의 판단에 투자한다는 점이다. 코드 작성·코드 읽기·실행 검증·결과에 대한 책임은 서로 다른 역할이다.
이 조사에서 Mixdog가 제안한 개인 적용 방향은 반복 구현과 검사를 AI에게 맡기되, 사람은 기대값의 근거와 중요한 권한·상태·부작용 경계를 이해하는 것이다. 검증 증거가 쌓인 영역부터 읽는 양을 줄이는 접근이지, 코드를 읽지 않는 것을 먼저 목표로 삼는 접근이 아니다. 이는 적용 제안이며 개인적 효과가 측정되었거나 모든 향후 작업의 필수 규칙으로 채택됐다는 뜻은 아니다.
테스트의 개수나 높은 커버리지보다 중요한 질문은 잘못된 구현도 같은 검사를 통과할 수 있는가이다. red/green은 구현 전 또는 수정 전의 의도한 실패를, 뮤테이션 검사는 일부러 바꾼 잘못된 구현을 기존 검사가 잡는지를 확인하는 수단이다. 후자는 선택한 변형에 대한 검출 능력의 증거이지 모든 결함에 대한 증명이 아니다. 알려진 결함·치명적 경계의 회귀 검사가 의심스러울 때 필요한 범위에서 선택하는 해석이며, 모든 변경에 새 검사 체계를 요구하지 않는다.
구현과 테스트가 같은 잘못된 가정을 공유할 수 있으므로 정답의 근거도 따로 확인한다. 다른 모델의 리뷰, 저장소 안의 Golden 회귀, 구현 때 사용하지 않은 평가 사례, 신뢰할 수 있는 참조 구현은 각각 다른 증거를 제공한다. 모델이 다르거나 검사 단계가 많다는 사실만으로 판단의 독립성이 보장되지는 않는다.
기록을 늘리기보다 기존 소유자에 연결한 범위
DanzzaN은 Vault·지침·스킬을 무작정 늘리지 않는 반영 방식을 물었고, 최종적으로 조사 Source 한 묶음 저장과 기존 테스트 설계 Atomic 한 곳 보강까지만 승인했다. 새 Atomic·스킬·전역 규칙·리뷰 단계·프로젝트 검사 도입은 이번 변경 범위가 아니다.
기대값을 구현에서 독립적으로 도출하기, 필요한 부작용과 금지된 부작용 확인하기, 위험에 맞는 좁은 경계에서 검사하기는 이미 기존 노트에 있다. 이번에는 테스트 설계는 시나리오 오라클 범위와 위험을 별도 축으로 다룬다에 테스트 통과와 결함 구별의 차이만 보강한다. 현재 프로젝트 상태와 테스트 실행 결과는 이 개인 지식 노트에 복제하지 않는다.
실제 작업에서 누락이 드러나면 규칙의 부재·발견 실패·판단 오류·검사 수단 부재·진행 차단 부재를 구별해야 한다는 기존 관점을 유지한다. 같은 주의 문구를 모든 층에 반복하는 것은 실행 가능한 검사를 대신하지 못한다.
관련 지식
- Golden 기대값은 구현과 독립적으로 도출하고 계약상 의미만 고정한다 — 기대값·계약과 현재 출력의 구분
- 규칙은 소유한 가장 좁고 안정적인 공개 경계에서 깊게 테스트한다 — 검사 중복과 실제 의존성의 보장 범위
- 규칙을 다시 전달하는 것과 위반을 판정하는 것은 다르다 — 지침의 전달·판정·차단 구분
- 보장 수준과 판정 경계