AI 에이전트 복잡성 래칫(Complexity Ratchet): 왜 90%의 테스트 커버리지가 필요한가

AI 코딩 시대의 복잡성 래칫(Complexity Ratchet) - Garry Tan의 에세이 요약

게리 탄(Garry Tan, Y Combinator CEO)이 X에 공유한 장문의 에세이로, 지난 1년간 AI 에이전트(Claude Code, Codex 등)와 함께 두 개의 오픈소스 프로젝트를 만든 경험을 정리한 글입니다. 약 97만 줄의 코드와 665개의 테스트 파일 대부분을 AI가 작성했고, 동시에 15개의 에이전트 세션을 운영했다고 합니다. 그는 이 과정을 통해 "속도와 품질은 양자택일"이라는 소프트웨어 공학의 오랜 명제가 깨졌다고 주장하며, 그 핵심 메커니즘으로 '복잡성 래칫(Complexity Ratchet)'이라는 개념을 제시합니다.

핵심 개념 정리

래칫(Ratchet)이란 한 방향으로만 움직이는 톱니바퀴 장치를 뜻하는 비유로, 코드베이스 품질이 후퇴 없이 전진만 하도록 만드는 구조를 의미합니다.
세 가지 축적물 에이전트와의 코딩 세션마다 테스트(무엇이 옳은가), 문서(왜 그렇게 결정했는가), 평가 결과(품질 기준선) 세 가지가 코드베이스에 쌓입니다.
컨텍스트 윈도우(Context Window)의 활용 다음 세션에서 AI 에이전트가 이 세 가지를 모두 읽고 작업하므로, 테스트를 깨거나 문서를 무시하거나 평가 점수를 떨어뜨릴 수 없게 됩니다.

기존 방식과의 차별점

에러 모델의 변화 과거 50년간 소프트웨어 공학은 "에러는 치명적이니 예방하라"는 전제로 코드 리뷰, QA, 스테이징 등 복잡한 프로세스를 만들었으나, 이제는 대부분의 에러를 에이전트가 다음 턴에 진단하고 수정 가능합니다.
복잡성 한계의 확장 시스템 복잡도의 상한선이 '한 팀이 머리에 담을 수 있는 양'에서 '한 사람과 전체 코드베이스를 컨텍스트에 로드한 에이전트들'로 넓어졌습니다.
제도적 기억의 영속성 사람은 퇴사·번아웃으로 떠나지만 테스트와 문서로 남은 지식은 어떤 모델, 어떤 시점에서도 다시 불러올 수 있습니다.

90% 테스트 커버리지의 의미

비선형적 품질 곡선 Capers Jones의 1만여 프로젝트 연구에 따르면 커버리지 70% 이하에서는 결함 제거율이 6575%에 그치지만, 8595%에서는 92~97%로 급등하는 '무릎 지점'이 존재합니다.
항공 산업의 선례 항공 소프트웨어 표준 DO-178C는 Level A(치명적) 시스템에 MC/DC 커버리지를 강제하며, 이는 99% 이상의 결함 제거율을 달성하기 위함입니다.
AI가 깬 비용 장벽 마지막 20% 커버리지를 채우는 작업은 인간에게 지루하고 비용이 컸지만, 에이전트는 피로를 느끼지 않으므로 새벽에도 엣지 케이스(Edge Case) 테스트를 끝없이 작성합니다.

저자가 제시한 실제 사례

GBrain의 추출 정확도 개선 10만 건 이상의 신념 추출에서 '누가 그 주장을 했는가'를 35% 오인하던 문제를 17개의 테스트로 고정시켜, 어떤 후속 버전도 그 이하로 떨어질 수 없도록 했습니다.
Superpowers의 TTY 테스트 AI 에이전트가 대화형 리뷰를 건너뛰는 행동을 Bun의 의사 터미널 기능으로 직접 감시·차단하여, "AI가 대화를 했는가"라는 비전통적 요구사항도 테스트화했습니다.

장점과 한계

장점 외부 기여자가 시스템 전체를 이해하지 않아도 테스트만 통과시키면 안전하게 PR을 머지(Merge)할 수 있어 협업의 진입 장벽이 낮아집니다.
한계 상태를 파괴하는 종류의 에러(잘못된 DB 마이그레이션, 보안 침해, 프라이버시 유출)는 여전히 치명적이며, 약 10%의 통합 지점과 인프라는 본질적으로 테스트가 어렵습니다.
반론에 대한 답변 "테스트를 잘 짜는 사람이 원래 아키텍처도 잘 짠다"는 지적에 대해, 래칫의 핵심은 사람이 아니라 다음 턴의 안전망이라는 점을 강조합니다.

이 글에서 저자가 전하려는 핵심은 AI 코딩의 진짜 가치가 '빨리 짜는 것'이 아니라 '지금까지 너무 비싸서 포기했던 수준의 검증'을 무료로 만들었다는 점입니다. 50년간 항공·의료 분야의 전유물이었던 90% 테스트 커버리지 (Test Coverage)가 이제는 한 사람의 일상이 될 수 있고, 그 결과 한 명의 개발자가 만들 수 있는 소프트웨어의 복잡도 (Complexity) 천장이 극적으로 높아졌다는 관찰입니다. 다만 글 자체가 자신의 오픈소스 프로젝트 (Superpowers, GBrain) 홍보를 겸하고 있고, 통계 인용 일부(예: GPT-5.5)에 검증이 필요한 부분도 있어 비판적 독해가 필요한 텍스트이기도 합니다.