AI 에이전트 복잡성 래칫: 왜 90% 테스트 커버리지가 필수인가
이 글은 AI 코딩 에이전트와 함께 소프트웨어를 개발해온 개발자가, 90% 테스트 커버리지가 어떻게 소프트웨어 품질을 "앞으로만 전진"시키는 래칫(ratchet) 메커니즘을 만들어내는지 설명하는 글입니다. 과거 50년간 인간의 의지력으로는 도달하기 어려웠던 높은 테스트 커버리지를 AI 에이전트가 사실상 무료로 달성하게 해주며, 이것이 소프트웨어 개발의 근본적인 판도를 바꾸고 있다고 주장합니다.
1. AI와 함께 진짜 소프트웨어를 만들다
저자는 지난 1년간 AI로 단순히 프롬프트를 던지는 수준이 아니라, 실제 소프트웨어를 구축해왔다고 밝힙니다. 두 개의 오픈소스 프로젝트를 운영하고 있는데, 하나는 AI 코딩 에이전트를 더 뛰어나게 만들어주는 도구이고, 다른 하나는 읽고 쓰는 모든 것을 검색 가능한 지식 베이스로 변환해주는 시스템입니다. 두 프로젝트를 합치면 약 97만 줄의 코드와 665개의 테스트 파일이 있으며, 거의 전부가 Claude Code와 Codex에 의해 작성되었습니다. 보통 15개의 동시 세션을 돌리며 작업한다고 합니다.
"지난 주에 약 29,000줄의 새 코드를 출시했다. 각 릴리스는 이전보다 더 잘 테스트되어 있었다."
이건 원래 불가능하다고 여겨지던 것입니다. 속도와 품질은 트레이드오프 관계라는 게 상식이었죠. 빠르게 출시하면 버그가 생기고, 꼼꼼히 만들면 느려진다. 둘 중 하나를 골라야 했습니다.
"더 이상 고를 필요가 없다. 그 열쇠는 90% 테스트 커버리지이며, AI 에이전트가 그것에 도달하는 비용을 사실상 무료로 만들어줬다."
50년간 그 수준의 검증은 인간의 의지력으로 유지하기엔 너무 비쌌지만, 이제 에이전트가 코드와 함께 테스트를 작성합니다. 그 결과물을 저자는 복잡성 래칫(complexity ratchet)이라 부릅니다. 오직 나아질 수만 있고, 절대 퇴보하지 않는 시스템입니다.
2. 50년간의 소프트웨어 공학: 실수를 막아라
50년간 소프트웨어 공학은 하나의 아이디어를 중심으로 돌아갔습니다: 오류를 예방하라, 왜냐하면 오류는 치명적이니까.
첫 번째 시도에서 코드를 제대로 만들어야 했습니다. 엣지 케이스 하나를 놓치면 프로덕션에서 크래시가 나고, 잘못된 데이터베이스 마이그레이션을 배포하면 고객 데이터를 잃고, 미묘한 동작을 하는 함수를 작성한 뒤 그걸 이해하는 유일한 사람이 퇴사하면 아무도 그 코드가 왜 동작하는지 모릅니다. 시스템 전체가 인간이 꼼꼼할 것이라는 전제에 의존했지만, 인간은 꼼꼼하지 않습니다. 🫠
그래서 코드 리뷰, 스테이징 환경, QA 팀, 릴리스 트레인 같은 정교한 프로세스를 만들었습니다. 어느 정도 효과가 있었지만 느렸고, 소프트웨어 시스템의 복잡도에는 하드 씰링(hard ceiling)이 존재했습니다. 바로 한 팀이 동시에 머릿속에 담을 수 있는 것들의 수입니다.
3. AI 모델의 등장과 오류 모델의 변화
저자가 "모델이 도착했다"고 말하는 의미는, AI 코딩 에이전트들(Claude, GPT, Codex 등)이 이제 코드를 읽고, 맥락을 이해하고, 오류를 진단하고, 수정을 작성할 수 있다는 것입니다. 완벽하지는 않지만, 소프트웨어의 오류 모델이 바뀔 만큼 충분히 잘합니다.
구체적인 예시들이 등장합니다:
- 마이그레이션이 깨지면? 에이전트가 에러 메시지를 읽고, 45개 버전에 걸친 데이터베이스 스키마 이력을 이해하고, 수정을 작성하고, 테스트를 작성합니다.
- 파일 싱크가 백만 개의 심볼릭 링크에서 멈추면? 에이전트가 파서 타임아웃을 진단하고, 30초로 제한하고, 테스트와 함께 수정을 배포합니다.
- 추출 파이프라인에 귀속(attribution) 버그가 있으면? 크로스 모델 평가가 잡아내고, 프롬프트가 반복 개선되고, 데이터베이스 계층에서 강제 적용됩니다.
"대부분의 코드 수준 오류 — 논리 버그, 파싱 실패, 깨진 엣지 케이스 — 에이전트가 다음 턴에 진단하고 수정할 수 있다. 이것은 진정으로 새로운 것이다."
여전히 치명적인 오류는 상태를 파괴하는 것들입니다: 프로덕션 데이터에 대한 잘못된 마이그레이션, 탐지 전에 악용되는 보안 취약점, 되돌릴 수 없는 프라이버시 유출. 하지만 래칫이 이런 것도 돕고(좋은 테스트가 대부분 프로덕션 전에 잡아내니까), 핵심은 코드베이스 내 오류의 대다수가 수정 가능한 종류라는 것입니다.
"이것은 소프트웨어가 만들어지는 방식의 상전이(phase change)다. 하지만 래칫이 있어야만 작동한다."
4. 래칫이란 무엇인가
래칫(ratchet)은 한 방향으로만 움직임을 허용하는 메커니즘입니다. 소켓 렌치가 볼트를 앞으로만 돌리고 뒤로 돌아가지 못하게 하는 것처럼요. 🔧
에이전트가 코드를 작성하는 소프트웨어에서, AI 에이전트와의 매 코딩 세션은 코드베이스에 세 가지를 추가합니다:
- 테스트 — "올바름"이 무엇인지를 인코딩하는 자동화된 검사. 누군가 코드를 변경할 때마다 실행되고, 변경이 무언가를 깨뜨리면 시끄럽게 실패합니다.
- 문서화 — 왜 그런 결정이 내려졌는지 기록. 코드가 무엇을 하는지뿐 아니라, 그 뒤의 추론과 트레이드오프까지.
- 평가 결과 — 품질 임계값을 수립하는 구조화된 평가. 점수가 있어서 다음 버전이 더 나은지 나쁜지 알 수 있습니다.
다음에 에이전트가 코드베이스에서 작업할 때, 이 세 가지를 모두 컨텍스트 윈도우(AI가 보고 추론할 수 있는 텍스트)에 로드합니다. 테스트 스위트 아래로 퇴보할 수 없고, 문서를 무시할 수 없고, 평가 기준선 아래로 품질을 내보낼 수 없습니다.
"품질 바닥이 매 턴마다 올라간다. 앞으로만 가는 움직임. 그것이 래칫이다."
5. 구체적 사례: 인식론적 추출과 홀더 혼동 문제
저자가 만든 지식 시스템은 AI 에이전트에게 장기 기억을 제공합니다. 메모, 회의, 대화, 리서치를 저장하고 인덱싱하고 검색할 수 있는 제2의 뇌 같은 것입니다.
핵심 기능 중 하나가 인식론적 추출(epistemological extraction)인데, 수천 페이지를 읽고 누가 무엇을 믿는지, 어떤 확신도로, 시간에 따라 추출합니다. 예를 들면 "개리는 비트코인이 30만 달러에 도달할 거라 생각한다(확신도: 0.45)" 같은 식입니다.
첫 추출에서 100,720개의 주장이 뽑혔고, 크로스 모델 평가(GPT-5.5와 Claude가 독립적으로 채점)로 품질을 매겼더니 전체 점수는 10점 만점에 6.8점이었습니다.
가장 큰 문제는 저자가 홀더 혼동(holder confusion)이라 부르는 것이었습니다. "AI가 2027년까지 소프트웨어 엔지니어의 80%를 대체할 것이다"라는 주장이 있을 때, 누가 그 믿음의 주체인가? 작성자인가? 인용된 사람인가? 팟캐스트 트랜스크립트에서 추론한 시스템의 분석 엔진인가? 버전 1은 이 구분을 35%나 틀렸습니다. 사람들이 무엇을 믿는지 추적하는 시스템에서 누가 믿는지를 모르면 큰 문제죠.
그래서 평가 결과가 문서화되고, 6가지 구체적 실패 모드가 식별되었으며, 버전 2 프롬프트가 6가지 모두를 다뤘습니다. 가중치 반올림(확신도 점수)은 데이터베이스 계층에서 강제 적용되어, 0.74 같은 거짓 정밀도 대신 0.75라는 정직한 답이 나오게 했습니다. 17개의 테스트가 계약을 잠갔습니다.
"이제 미래의 어떤 버전도 그 17개 테스트를 통과하지 않고는 출시할 수 없다. 아무도 가중치 반올림이 왜 중요한지, 홀더 혼동이 뭔지 기억할 필요가 없다. 테스트가 기억한다."
"품질 바닥이 영구적으로 올라갔다. 래칫의 한 턴이다."
6. 바이브코딩의 함정: 래칫 없는 코딩
"바이브코딩(Vibe coding)"은 안드레이 카파시(Andrej Karpathy)의 용어로, 원하는 것을 자연어로 설명하고 모델이 코드를 생성하게 하는 방식입니다. 강력하지만, 저자가 YC 지원서와 오픈소스 저장소를 통해 본 바로는, 테스트를 건너뛴 바이브코딩 프로젝트 대부분이 중간 정도의 복잡도에 도달하면 무너지기 시작합니다 — 수천 줄, 서로 상호작용하는 몇 가지 기능 정도에서요.
"그들은 래칫을 건너뛰었다. 테스트도 없고, 문서도 없고, 평가도 없다. 에이전트가 복잡성을 추가하지만 아무것도 퇴보를 막지 못한다."
새 기능을 추가할 때마다 기존 기능이 깨질 가능성이 있고, 테스트 없이는 사용자가 신고할 때까지 알 수 없습니다. 버전 0.5쯤 되면 코드베이스는 모든 변경이 예상치 못한 무언가를 깨뜨리는 유령의 집 🏚️이 됩니다. 그러면 개발자는 "AI 코딩은 안 된다"는 블로그 글을 씁니다.
"AI 코딩은 잘 작동한다. 그들이 래칫을 안 만든 것뿐이다."
테스트를 작성하는 사람이 원래 좋은 아키텍처를 만드는 사람이라는 반론이 있을 수 있지만, 래칫 메커니즘의 핵심은 다음 턴에 무슨 일이 일어나는가에 있습니다. 새 기여자가 PR을 열거나, 모델 버전이 바뀌거나, 새벽 2시에 판단력이 흐려진 상태에서 코딩할 때, 테스트가 누가 작성했든 상관없이 퇴보를 잡아냅니다.
"래칫은 인간이 최상의 상태가 아닐 때도 작동한다. 그것이 핵심이다."
7. 테스트의 또 다른 역할: 제도적 기억
전통적인 소프트웨어 회사에서 제도적 기억(institutional memory)은 인간에게 있습니다. 캐싱 레이어가 왜 존재하는지 아는 시니어 엔지니어, 데이터베이스를 거의 파괴할 뻔한 마이그레이션을 기억하는 아키텍트, 빌링 시스템의 이상한 엣지 케이스를 설명할 수 있는 테크 리드.
인간은 떠납니다. 은퇴하고, 스카우트당하고, 번아웃됩니다. 떠나면 지식도 함께 사라집니다.
"모든 소프트웨어 회사에는 중요한 파일을 열었더니 '// 이것 절대 바꾸지 마시오 — Dave한테 물어볼 것'이라는 주석이 있고, Dave는 3년 전에 퇴사한 경험이 있다."
에이전트의 컨텍스트 윈도우는 퇴사하지 않고, 스카우트당하지 않고, 잊지 않습니다. 테스트 스위트가 "가중치 반올림은 0.05 단위를 사용해야 한다"를 인코딩하고, 문서가 "크로스 모달 평가에서 거짓 정밀도가 확신도 점수에 대한 신뢰를 떨어뜨린다는 것을 보여줬기 때문"이라고 설명하면, 그 지식은 영구적입니다. 어떤 에이전트든, 어떤 모델이든, 언제든 그 컨텍스트를 로드하고 제약을 이해할 수 있습니다.
"테스트는 직원 이직에서 살아남는 제도적 기억이다. 1인 프로젝트에서는 더욱 중요하다 — 당신이 가진 유일한 제도적 기억이니까."
8. 래칫의 확장: 코드를 넘어 모든 관찰 가능한 것으로
래칫은 전통적인 코드에만 적용되는 게 아닙니다. 컴퓨터가 관찰할 수 있는 모든 것에 작동합니다.
현대 시스템의 레이어를 생각해보면:
- OS: 프로세스 트리, 파일 시스템 상태, 네트워크 소켓, 크론 스케줄
- 터미널: 모든 키 입력, 출력의 모든 줄, 대화형 프롬프트
- 브라우저: 렌더링된 페이지, 버튼 상태, 네비게이션 이벤트
- API: 파싱하고 검증할 수 있는 구조화된 응답
- AI 에이전트: 관찰 가능한 행동 — 무엇을 말하는지, 어떤 도구를 호출하는지, 어떤 순서로 하는지, 삭제 전에 물어보는지
"만약 관찰할 수 있으면(harness), 볼 수 있다. 볼 수 있으면, 단언(assert)할 수 있다. 단언할 수 있으면, 래칫할 수 있다."
구체적 사례: AI 에이전트의 대화 행동 테스트
저자의 코딩 에이전트 프레임워크에는 대화형 플랜 리뷰 기능이 있습니다. 아키텍처를 검토해달라고 요청하면 섹션별로 질문하고, 엣지 케이스를 탐색하고, 가정에 도전합니다. 마치 실제로 코드를 읽는 엔지니어링 매니저 같은 거죠.
문제는 Claude Code가 때때로 대화 부분을 통째로 건너뛰었다는 것입니다. 플랜 파일을 읽고, 모든 발견사항을 한 번에 쏟아내고, 사용자에게 질문 하나도 없이 종료해버렸습니다. 리뷰의 핵심은 주고받는 대화인데, 그걸 건너뛰면 목적 자체가 무너집니다.
전통적인 테스트 프레임워크로는 "AI가 대화를 했는가"를 테스트할 수 없습니다. 그래서 저자는 Bun의 TTY 기능을 사용해서 실제로 Claude Code를 가상 터미널 안에 생성하고, 특정 시나리오를 주입하고, 리뷰 스킬을 트리거하고, 터미널 출력을 실시간으로 관찰하는 테스트를 만들었습니다. 에이전트가 끝나기 전에 대화형 질문을 던지는지 관찰하고, 질문 없이 종료하면 테스트가 실패합니다.
"이것은 코드를 테스트하는 게 아니다. AI 에이전트가 행동 계약을 따르는지 테스트하는 것이다. TTY 수준에서. 말 그대로 일하는 것을 지켜보면서."
래칫 대응은 세 겹이었습니다:
- STOP 게이트 — "다음 섹션으로 넘어가기 전에 반드시 사용자에게 물어야 한다"는 명시적 규칙과, 모델이 건너뛰기를 합리화하지 못하게 하는 반합리화 조항
- 반지름길 조항 — "플랜 파일은 대화형 리뷰의 출력물이지, 대체물이 아니다"라는 한 문장으로 모델이 계속 악용하던 정확한 허점을 막음
- 게이트 티어 바닥 테스트 — 제어된 시나리오에서 Claude Code를 생성하고 대화형 질문을 하나 이상 하지 않으면 실패하는 TTY 하네스 테스트
또 다른 사례로, OpenClaw 플러그인 테스트는 코드가 컴파일되는지만 확인하는 게 아니라, 소스에서 플러그인을 빌드하고, 격리된 프로필에서 실제 OpenClaw 인스턴스를 생성하고, CLI로 플러그인을 설치하고, 런타임 로드를 확인하고, 설정 슬롯을 지정하고, 설정을 검증하고, 진단 제로를 확인하는 완전한 엔드투엔드 왕복 테스트입니다. 359줄의 테스트 코드를, 인간이라면 설정이 너무 번거로워서 거의 작성하지 않았을 테스트를, Claude가 약 5분 만에 작성했습니다. ⚡
"원칙은 일반화된다. OS 수준에서 테스트할 수 있고, 브라우저 수준에서, API 수준에서, 행동 수준에서 테스트할 수 있다. 전체 스택이 테스트 가능하다. 래칫은 그 모든 것에 적용된다."
9. 90% 커버리지의 과학적 근거
그렇다면 90% 테스트 커버리지가 실제로 무엇을 사주는 걸까요?
Capers Jones는 10,000개 이상의 소프트웨어 프로젝트를 연구하고 결함 제거 효율(DRE, Defect Removal Efficiency) — 사용자에게 도달하기 전에 잡힌 버그의 비율 — 을 측정했습니다. 그의 데이터는 비선형 곡선을 보여줍니다:
- 70% 미만 커버리지: DRE 약 65-75%
- 85-95% 커버리지: DRE 92-97%로 점프
관계는 선형이 아닙니다. 약 85%에서 무릎(knee) 지점이 있고, 그 이후 결함 유출이 급격히 떨어집니다.
항공전자(avionics) 산업은 수십 년 전에 이걸 깨달았습니다. FAA의 비행 안전 필수 소프트웨어 표준인 DO-178C는 레벨 A 시스템(버그가 곧 비행기 추락인 시스템)에 MC/DC(수정 조건/결정 커버리지)를 요구합니다. 분기 커버리지만으로는 결함의 10-20%를 놓치지만, MC/DC는 99% 이상의 DRE를 달성합니다.
"그들이 이걸 의무화한 건 관료들이 서류작업을 좋아해서가 아니다. 데이터가 특정 커버리지 임계값 아래에서는 치명적 결함이 사람을 죽이지 않는 것과 양립할 수 없는 비율로 유출된다는 것을 보여줬기 때문이다."
신뢰성 공학의 식스 시그마 비유도 깔끔합니다:
- 3시그마: 백만 개당 약 67,000개 결함 (꽤 나쁨)
- 4시그마: 약 6,200개 (10배 나음)
- 5시그마: 233개 (또 27배 나음)
4에서 5 시그마로의 점프는 점진적 개선이 아니라 상전이(phase change)입니다. 테스트 커버리지도 같은 곡선을 따릅니다.
"70%에서 90% 커버리지로 가는 것은 30% 더 나아지는 게 아니다. 유출이 한 자릿수(order of magnitude) 줄어드는 것이다."
10. AI가 바꾼 것: 노력의 벽이 사라지다
저자는 연구가 보여주는 것에 대해 정직합니다. Microsoft의 Windows Vista 연구에서 커버리지가 출시 후 결함 감소와 상관관계가 있지만, 90% 이상에 도달하는 노력은 급격히 증가한다는 것을 발견했습니다. 마지막 20%의 커버리지는 처음 70%보다 불균형적으로 더 많은 작업이 필요합니다. 이것이 대부분의 팀이 70-80%에서 멈추고 "충분히 좋다"고 하는 이유였습니다.
하지만 뭔가가 바뀌었습니다:
"AI 코딩 에이전트는 노력을 경험하지 않는다."
에이전트는 열네 번째 엣지 케이스 테스트를 작성하면서 지루해하지 않습니다. 금요일 오후 5시에 대충 넘기지 않습니다. 복잡한 통합 테스트를 보고 "나중에 하지"라고 생각하지 않습니다. 인간 팀을 70%에서 멈추게 했던 노력 곡선이 에이전트에게는 적용되지 않습니다. 모듈의 모든 엣지 케이스에 대한 테스트를 작성해달라고 요청하면, 새벽 2시에도 기꺼이, 철저하게, 불평 없이 해냅니다. 🤖
"이것이 진짜 열쇠다. AI가 코드를 더 빨리 쓰게 해준다는 게 아니다. 많은 사람들이 그건 이미 알아챘다. AI가 이전에는 유지하기엔 너무 비쌌던 수준으로 검증할 수 있게 해준다는 것이다. 데이터가 마법적이라고 말하는 90% 임계값? 인간의 의지력으로 도달하기엔 너무 비쌌다. 이제는 무료다."
래칫은 허영 지표로서의 줄 커버리지가 아닙니다. 행동 계약을 인코딩하는 테스트에 관한 것입니다. 각 테스트가 특정한 교훈을 잠급니다. 커버리지는 시스템 행동의 얼마나 많은 부분이 계약 하에 있는지를 알려주는 프록시입니다. 90%에서는 거의 모든 행동 변경이 테스트 신호를 트리거합니다.
"90%에 도달하는 것은 영웅적 노력이었다. 이제는 그냥 화요일이다. 그것이 판도 변화다."
11. 커뮤니티와 스케일링
저자는 두 프로젝트를 혼자 시작했지만 더 이상 혼자가 아닙니다. 하나는 37명의 기여자가 있고 v1.30에서 단일 릴리스에 21개의 커뮤니티 PR을 반영했습니다. 다른 하나는 25명의 기여자가 있고 v0.31.1.1에서 하나의 PR에 22개의 커뮤니티 수정을 담았습니다.
"래칫이 이것을 안전하게 만든다. 모든 외부 PR은 기존 테스트 스위트를 통과해야 한다. 새 기여자가 전체 시스템을 이해할 필요 없다. 테스트를 통과시키면 된다."
최근 릴리스들의 이야기가 이를 보여줍니다:
- v0.31.0: 실시간 메모리를 위한 새 facts 테이블, 단기 기억을 장기 지식으로 승격시키는 dream consolidation 단계
- v0.31.1: 사용자의 실제 브레인 대신 빈 로컬 데이터베이스로 조용히 라우팅되던 25개 CLI 명령어 수정
- v0.31.1.1: 하나의 PR에 22개의 커뮤니티 보고 수정
- v0.31.2: 심볼릭 링크가 많은 대형 저장소에서 영원히 멈추던 코드 싱크에 30초 타임아웃 추가
각 릴리스가 이전보다 더 많은 테스트와 함께 배포되었습니다. 에이전트가 코드와 함께 테스트를 작성하기 때문에, 커버리지가 미끄러지지 않습니다. 유지하는 노력이 더 이상 인간의 부담이 아니기 때문입니다.
12. 소프트웨어의 복잡성 천장이 올라가다
"소프트웨어의 복잡성 천장이 훨씬 높아졌다."
과거에는 한 팀이 시스템을 머릿속에 담을 수 있는 능력에 의해 제한되었지만, 이제는 한 사람 + 전체 코드베이스, 스키마 이력, 테스트 스위트, 문서를 컨텍스트에 로드할 수 있는 에이전트에 의해 제한됩니다. 그건 훨씬 더 큰 숫자이고, 컨텍스트 윈도우가 커지고 모델이 코드에 대한 추론에서 더 나아질수록 계속 성장합니다.
"에이전트 + 취향(taste) + 오직 올라가기만 하는 테스트 스위트라는 이 모델을 채택하지 않는 모든 소프트웨어 회사는, 이미 이것을 가진 한 사람보다 더 느리게, 더 낮은 품질로 출시하고 있다."
마치며
50년간 90% 테스트 커버리지는 항공전자와 의료기기에만 허용된 사치였습니다 — 인간의 노력 벽에 시간을 쏟아부을 예산이 있는 팀들만의 것이었죠. AI 에이전트가 그 벽을 허물었습니다. 소프트웨어를 신뢰할 수 있게 만드는 커버리지 임계값은 더 이상 비싸지 않습니다. 그냥 설정 하나입니다.
"문제는 90%를 감당할 수 있느냐가 아니다. 90% 없이 감당할 수 있느냐다."
핵심 메시지는 명확합니다: 테스트가 래칫이고, 90% 커버리지가 매 PR마다, 예외 없이 적용되어야 한다는 것. AI가 코드를 빠르게 작성하는 것보다 중요한 건, AI가 이전에는 유지할 수 없었던 수준의 검증을 무료로 만들어준다는 사실입니다. 래칫을 만드세요. 그러면 시스템은 오직 나아질 수만 있습니다. 🔧✨