AI 에이전트의 복잡성 래칫: 90% 테스트 커버리지가 필수인 이유

지난 1년 동안 저는 AI와 함께 코딩을 해왔습니다. 단순히 프롬프트를 입력하는 것이 아니라 실제 소프트웨어를 구축하는 것이었죠. 두 개의 오픈소스 프로젝트를 진행했습니다: AI 코딩 에이전트를 더욱 향상시키는 GStack과, 읽고 쓰는 모든 것을 AI가 사용할 수 있는 검색 가능한 지식 베이스로 바꿔주는 GBrain입니다. 이 두 프로젝트를 합쳐 약 970,000줄의 코드와 665개의 테스트 파일이 있습니다. 거의 모두 제 지시에 따라 Claude Code와 Codex가 작성했습니다 (대부분의 시간 동안 15개의 동시 Conductor 세션을 사용했습니다).

지난주 저는 72시간 만에 14개의 풀 리퀘스트를 병합했습니다. 거의 29,000줄의 새로운 코드였죠. 각 릴리스는 이전보다 더 철저하게 테스트되었습니다.

그것은 불가능하다고 여겨졌습니다. 속도와 품질은 상충 관계에 있다고 여겨졌죠. 빠르게 출시하면, 무언가를 망가뜨립니다. 천천히 움직이면, 제대로 출시합니다. 둘 중 하나를 선택해야 합니다.

더 이상 선택할 필요가 없습니다. 그 비결은 90%의 테스트 커버리지이며, AI 에이전트가 그곳에 도달하는 것을 무료로 만들었습니다. 50년 동안, 그 수준의 검증은 유지하기에 너무 많은 인간의 의지력을 필요로 했습니다. 이제 에이전트가 코드와 함께 테스트를 작성합니다. 그 결과는 제가 '복잡성 래칫(complexity ratchet)'이라고 부르는 것입니다: 시스템이 더 나아질 수만 있고, 절대 나빠지지 않도록 하는 장치입니다.

(이 글은 AI와 함께 구축하는 방법에 대한 시리즈 중 일곱 번째입니다: 1 2 3 4 5 6

소프트웨어는 한때 취약했습니다

50년 동안, 소프트웨어 공학의 모든 분야는 하나의 아이디어를 중심으로 조직되었습니다: 오류를 방지하라, 왜냐하면 오류는 치명적이기 때문입니다.

처음부터 코드를 올바르게 작성해야 했습니다. 하나의 예외 케이스를 놓치면 프로덕션에서 충돌이 발생합니다. 잘못된 데이터베이스 마이그레이션을 배포하면 고객 데이터를 잃습니다. 미묘한 작업을 수행하는 함수를 작성했는데, 그것을 이해하는 유일한 사람이 퇴사하면 아무도 그것이 왜 작동하는지 모릅니다. 전체 시스템은 인간이 조심스럽게 행동하는 것에 의존했지만, 인간은 조심스럽지 않습니다. 그래서 우리는 정교한 프로세스(코드 리뷰, 스테이징 환경, QA 팀, 릴리스 트레인)를 구축했으며, 이 모든 것은 사용자에게 도달하기 전에 실수를 잡아내기 위해 설계되었습니다.

어느 정도는 효과가 있었습니다. 하지만 느렸습니다. 그리고 그것은 모든 소프트웨어 시스템의 복잡성에 단단한 한계가 있음을 의미했습니다: 한 팀이 동시에 머릿속에 담을 수 있는 것들의 수입니다.

이제 소프트웨어는 유연해졌습니다

제 말은 엉성해졌다는 뜻이 아닙니다. 이전에는 불가능했던 방식으로 회복력이 생겼다는 뜻입니다.

제가 "모델이 여기 있다"고 말할 때, AI 코딩 에이전트(Claude, GPT, Codex 및 그 주변에서 성장하는 생태계)가 이제 코드를 읽고, 맥락을 이해하고, 오류를 진단하고, 수정 사항을 작성할 수 있다는 것을 의미합니다. 완벽하지는 않습니다. 하지만 소프트웨어의 오류 모델이 변경될 만큼 충분히 잘 작동합니다.

마이그레이션이 중단되나요? 에이전트가 오류 메시지를 읽고, 45개 버전에 걸친 데이터베이스 스키마 기록을 이해하고, 수정 사항을 작성하고, 테스트를 작성합니다. 파일 동기화가 수백만 개의 심볼릭 링크에서 멈추나요? 에이전트가 파서 시간 초과를 진단하고, 30초로 제한하고, 테스트와 함께 수정 사항을 배포합니다. 추출 파이프라인에 속성 버그가 있나요? 교차 모델 평가가 이를 발견하고, 프롬프트가 반복되며, 데이터베이스 계층에 적용이 추가됩니다.

대부분의 코드 수준 오류(로직 버그, 구문 분석 실패, 깨진 예외 케이스)에 대해 에이전트는 이제 다음 턴에 이를 진단하고 수정할 수 있습니다. 이것은 진정으로 새로운 것입니다. 치명적으로 남아 있는 오류는 상태를 파괴하는 오류입니다: 프로덕션 데이터에 대한 잘못된 마이그레이션, 탐지 전에 악용된 보안 허점, 되돌릴 수 없는 개인 정보 유출. 래칫은 여기서도 도움이 되지만(좋은 테스트는 프로덕션 전에 이러한 대부분을 잡아냅니다), 진정한 변화는 코드베이스에 있는 오류의 대부분이 수정 가능한 유형이라는 것입니다.

이것은 소프트웨어가 구축되는 방식의 단계적 변화입니다. 하지만 래칫이 있을 때만 작동합니다.

에이전트 복잡성 래칫

래칫은 한 방향으로만 움직임을 허용하는 메커니즘입니다. 소켓 렌치는 볼트를 앞으로 돌리고 뒤로 돌아가는 것을 방지합니다. 이것이 비유입니다.

에이전트가 코딩한 소프트웨어에서 AI 에이전트와의 모든 코딩 세션은 코드베이스에 세 가지를 추가합니다:

테스트 - "올바른" 것이 무엇인지 정의하는 코드로, 누군가 코드를 변경할 때마다 실행되고 변경 사항이 무언가를 망가뜨리면 큰 소리로 실패하는 자동화된 검사입니다.
문서 - 결정이 내려진 이유를 기록하는 것으로, 코드가 무엇을 하는지뿐만 아니라 그 이면의 추론과 트레이드오프를 설명합니다.
평가 결과 - 품질 임계값을 설정하는 것으로, 출력 품질에 대한 구조화된 평가와 점수를 포함하여 다음 버전이 더 나은지 나쁜지 알 수 있게 합니다.

다음에 에이전트가 코드베이스에서 작업할 때, 이 세 가지를 모두 컨텍스트 창(AI가 보고 추론할 수 있는 텍스트)에 로드합니다. 테스트 스위트 아래로 회귀할 수 없습니다. 테스트가 실패할 것이기 때문입니다. 문서를 무시할 수 없습니다. 컨텍스트에 바로 있기 때문입니다. 평가 기준선 아래로 품질을 낮춰 배포할 수 없습니다. 점수가 기록되어 있기 때문입니다.

모든 턴마다 품질 기준선이 올라갑니다. 순방향 이동만 가능합니다. 그것이 래칫입니다.

실제로 이것이 어떻게 보이는지

구체적으로 설명하겠습니다. GBrain은 제가 구축하고 있는 지식 시스템입니다. AI 에이전트에게 장기 기억을 제공하기 위해 개인의 노트, 회의, 대화 및 연구를 저장, 색인화 및 검색합니다. AI 어시스턴트가 실제로 읽을 수 있는 두 번째 두뇌라고 생각하시면 됩니다.

그 기능 중 하나는 인식론적 추출입니다: 수천 페이지를 읽고 누가 무엇을, 어느 정도의 확신을 가지고, 시간이 지남에 따라 믿는지 추출합니다. "Garry는 비트코인이 30만 달러에 도달할 것이라고 생각합니다 (확신도: 0.45)." "Jared는 이 스타트업이 강력한 유지율을 가지고 있다고 생각합니다 (확신도: 0.80)." 이런 식으로 28,000페이지에 걸쳐 있습니다.

첫 번째 추출 실행은 100,720개의 주장을 가져왔습니다. 저는 교차 모델 평가를 사용하여 품질을 평가했습니다. GPT-5.5와 Claude가 모두 독립적으로 출력을 평가하도록 했습니다. 전체 점수: 10점 만점에 6.8점.

가장 큰 문제는? 제가 '보유자 혼동(holder confusion)'이라고 부르는 것입니다. "AI가 2027년까지 소프트웨어 엔지니어의 80%를 대체할 것이다"라는 주장을 생각해보세요. 누가 그 믿음을 가지고 있습니까? 그것을 쓴 사람입니까? 인용하는 사람입니까? 아니면 팟캐스트 대본에서 추론한 시스템의 분석 엔진입니까? 버전 1은 이 구분을 35%의 경우에 잘못했습니다. 이것은 중요합니다. 사람들이 무엇을 믿는지 추적하는 시스템을 구축한다면, 누가 그것을 믿는지 알아야 하기 때문입니다.

그래서 평가 결과가 문서화되었습니다. 6가지 특정 실패 모드가 식별되었습니다. 버전 2 프롬프트는 6가지 모두를 해결했습니다. 가중치 반올림(확신도 점수)은 데이터베이스 계층에서 적용되었습니다. 0.75가 정직한 답변일 때 0.74와 같은 거짓 정밀도는 더 이상 없습니다. 17개의 테스트가 계약을 확정했습니다.

이제 미래의 추출 버전은 이 17개의 테스트를 통과하지 않고는 배포될 수 없습니다. 아무도 가중치 반올림이 중요한 이유나 보유자 혼동이 무엇인지 기억할 필요가 없습니다. 테스트가 기억합니다.

품질 기준선이 영구적으로 상승했습니다. 그것이 래칫의 한 번의 턴입니다.

대부분의 바이브코딩 프로젝트가 실패하는 이유

"바이브코딩(Vibecoding)"은 Andrej Karpathy가 AI로 코딩하는 것을 설명하기 위해 만든 용어로, 자연어로 원하는 것을 설명하고 모델이 코드를 생성하도록 하는 것입니다. 강력하며 제가 구축하는 방식이기도 합니다. 하지만 YC 지원서와 오픈소스 저장소에서 본 바에 따르면, 테스트를 건너뛰는 대부분의 바이브코딩 프로젝트는 중간 정도의 복잡성(수천 줄, 몇 가지 상호 작용하는 기능)에 도달하면 무너지기 시작합니다.

그들은 래칫을 건너뜁니다. 테스트도, 문서도, 평가도 없습니다. 에이전트는 복잡성을 추가하지만 회귀를 방지하는 것은 없습니다. 모든 새로운 기능은 이전 기능을 손상시킬 가능성이 있으며, 테스트가 없으면 사용자가 보고할 때까지 알 수 없습니다. 버전 0.5가 되면 코드베이스는 모든 변경 사항이 예상치 못한 것을 망가뜨리는 유령의 집이 됩니다. 그런 다음 개발자는 AI 코딩이 작동하지 않는다는 블로그 게시물을 작성합니다.

AI 코딩은 잘 작동합니다. 그들이 래칫을 구축하지 않았을 뿐입니다.

테스트를 작성하는 사람이 처음부터 좋은 아키텍처를 작성하는 사람이기도 하다고 주장할 수 있습니다. 공정합니다. 하지만 래칫 메커니즘은 사람에 관한 것이 아닙니다. 다음 턴에 무슨 일이 일어나는지에 관한 것입니다. 새로운 기여자가 PR을 열거나, 모델 버전이 변경되거나, 새벽 2시에 코딩하고 판단력이 흐려졌을 때, 테스트는 누가 작성했는지에 관계없이 회귀를 잡아냅니다. 래칫은 인간이 최상의 상태가 아닐 때도 작동합니다. 그것이 핵심입니다.

테스트 없이는 개선은 잡음이 많은 과정입니다. 에이전트는 상황을 개선하려고 시도하지만, 회귀 신호가 없으면 좋은 변경과 나쁜 변경 모두 동일하게 보이지 않습니다. 조밀한 테스트 스위트를 사용하면 테스트된 표면에 래칫이 생깁니다: 인코딩한 동작에 대해서만 품질이 올라갈 수 있습니다. 그것은 시스템의 대부분이지 전부는 아닙니다. 하지만 빠른 속도로 순방향 이동을 유지하기에 충분합니다.

제도적 기억으로서의 테스트

전통적인 소프트웨어 회사에서 제도적 기억은 인간에게 있습니다. 그 캐싱 계층이 왜 존재하는지 아는 시니어 엔지니어. 데이터베이스를 거의 파괴할 뻔한 마이그레이션을 기억하는 아키텍트. 청구 시스템의 이상한 예외 케이스를 설명할 수 있는 기술 리드.

인간은 떠납니다. 은퇴하고, 스카우트되고, 번아웃됩니다. 그들이 떠날 때 지식도 함께 사라집니다. 모든 소프트웨어 회사는 중요한 파일을 열고 // 이걸 변경하지 마세요 -- Dave에게 물어보세요 라는 주석을 발견한 경험이 있으며, Dave는 3년 전에 퇴사했습니다.

에이전트의 컨텍스트 창은 그만두지 않습니다. 스카우트되지 않습니다. 잊지 않습니다. 테스트 스위트가 "가중치 반올림은 0.05 증분을 사용해야 함"을 인코딩하고 문서가 "교차 모델 평가에서 거짓 정밀도가 신뢰도 점수에 대한 신뢰를 떨어뜨리기 때문"이라고 설명하면, 그 지식은 내구성이 있습니다. 모든 에이전트, 모든 모델, 모든 시간이 그 컨텍스트를 로드하고 제약 조건을 이해할 수 있습니다.

테스트는 직원 이직에도 살아남는 제도적 기억입니다. 1인 프로젝트의 경우 훨씬 더 중요합니다. 그것이 당신이 가진 유일한 제도적 기억이기 때문입니다.

활용 가능한 모든 것은 테스트 가능합니다

래칫은 전통적인 코드에만 작동하지 않습니다. 컴퓨터가 관찰할 수 있는 모든 것에 작동합니다.

현대 시스템의 계층을 생각해보세요. OS는 프로세스 트리, 파일 시스템 상태, 네트워크 소켓, cron 스케줄을 제공합니다. 터미널은 모든 키 입력, 모든 출력 라인, 모든 대화형 프롬프트를 제공합니다. 브라우저는 렌더링된 페이지, 버튼 상태, 탐색 이벤트를 제공합니다. API는 구문 분석하고 검증할 수 있는 구조화된 응답을 제공합니다. 그리고 AI 에이전트는 관찰 가능한 행동(무엇을 말하는지, 어떤 도구를 호출하는지, 어떤 순서로 작업을 수행하는지, 행동하기 전에 묻는지 여부)을 제공합니다.

이 모든 것은 활용 가능합니다. 그리고 활용할 수 있다면 관찰할 수 있습니다. 관찰할 수 있다면 단언(assert)할 수 있습니다. 단언할 수 있다면 래칫할 수 있습니다.

이것은 전통적인 단위 테스트보다 훨씬 더 넓은 표면적입니다. 예를 들어 보여드리겠습니다.

GStack은 제 오픈소스 코딩 에이전트 프레임워크입니다. GitHub 별 93,000개, 701,000줄의 코드, 46개의 스킬을 보유하고 있습니다. 핵심 기능 중 하나는 대화형 계획 검토입니다. 아키텍처 검토를 요청하면 계획을 섹션별로 살펴보고, 질문하고, 예외 케이스를 탐색하고, 가정에 도전합니다. 마치 실제로 코드를 읽는 엔지니어링 매니저가 있는 것과 같습니다.

문제는: Claude Code가 때때로 전체 대화형 부분을 건너뛰곤 했습니다. 계획 파일을 읽고, 모든 결과를 한 번에 덤프하고, 사용자에게 질문 하나 없이 종료했습니다. 검토의 핵심은 왕복 대화입니다. 그것을 건너뛰는 것은 목적을 무효화합니다.

이것을 어떻게 테스트합니까? "AI가 대화를 했는지"를 단위 테스트할 수 없습니다. 어떤 전통적인 테스트 프레임워크도 이것을 다루지 않습니다.

그래서 저는 Bun의 TTY 기능을 사용하여 테스트 하네스(PR #1354)를 구축했습니다. 이 하네스는 말 그대로 Claude Code를 의사 터미널 내에서 생성하고, 특정 저장소 시나리오를 제공하고, 검토 스킬을 트리거하고, 터미널 출력을 실시간으로 관찰합니다. 테스트는 에이전트가 완료되기 전에 대화형 질문을 실행하는지 관찰합니다. 결과를 덤프하고 아무것도 묻지 않고 종료하면 테스트가 실패합니다.

그것은 코드를 테스트하는 것이 아닙니다. AI 에이전트가 행동 계약을 따르는지 테스트하는 것입니다. TTY 수준에서 말 그대로 작동하는 것을 지켜보면서 말이죠.

래칫 응답은 세 가지 계층이었습니다:

스킬 지침의 STOP 게이트 - "다음 섹션으로 진행하기 전에 사용자에게 물어봐야 합니다"라는 명시적 규칙과, 모델이 건너뛰기로 자신을 설득할 수 없도록 특정 실패 모드를 명명하는 반합리화 조항이 포함됩니다.
반-지름길 조항 - "계획 파일은 대화형 검토의 출력이지, 그 대체물이 아닙니다." 모델이 계속 악용하던 정확한 허점을 막는 한 문장입니다.
게이트 계층 바닥 테스트 - 통제된 시나리오에서 Claude Code를 생성하고 에이전트가 적어도 하나의 대화형 질문을 하지 않으면 실패하는 TTY 하네스 테스트입니다.

이제 Anthropic이 새로운 모델 버전을 출시하거나 제가 스킬 프롬프트를 변경할 때, 테스트 스위트는 대화형 계약의 모든 회귀를 잡아냅니다. 에이전트는 조용히 질문을 중단할 수 없습니다. 테스트가 터미널을 지켜보고 확인합니다.

또는 새로운 OpenClaw 플러그인을 출시한 PR #880을 생각해보세요. 테스트는 코드가 컴파일되는지 확인하는 것 이상을 수행합니다. 소스에서 플러그인을 빌드하고, 격리된 프로필에서 실제 OpenClaw 인스턴스를 생성하고, CLI를 통해 플러그인을 설치하고, plugins inspect를 실행하여 런타임이 로드되었는지 확인하고, 구성 슬롯을 설정하고, 구성을 검증하고, plugins doctor를 실행하여 진단 결과가 0인지 확인합니다. 두 개의 별도 프로그램에 걸친 완전한 종단 간 왕복 테스트입니다. 359줄의 테스트 코드입니다. 인간이 거의 수동으로 작성하지 않을 종류의 테스트입니다. 설정이 너무 지루하기 때문입니다. Claude가 약 5분 만에 작성했습니다. 이것이 노력의 벽이 실시간으로 사라지는 모습입니다.

원칙은 일반화됩니다. OS 수준에서 테스트할 수 있습니다: 마이그레이션이 올바른 테이블을 생성했는지, cron 작업이 실행되었는지, 프로세스가 아직 살아 있는지. 브라우저 수준에서: 페이지가 렌더링되었는지, 에이전트가 양식을 올바르게 채웠는지. API 수준에서: 모델이 올바른 스키마로 유효한 JSON을 반환했는지. 행동 수준에서: 에이전트가 프로토콜을 따랐는지, 삭제하기 전에 물었는지, 중지하라고 했을 때 중지했는지.

전체 스택은 테스트 가능합니다. 래칫은 이 모든 것에 적용됩니다. 대부분의 사람들은 아직 이것을 깨닫지 못했습니다. 그들은 여전히 테스트 커버리지를 "내 함수가 올바른 숫자를 반환했는가"로 생각하고 있기 때문입니다. 실제 테스트 표면은 컴퓨터가 볼 수 있는 모든 것입니다.

90%라는 숫자

그렇다면 90%의 테스트 커버리지는 실제로 무엇을 제공할까요?

Capers Jones는 10,000개 이상의 소프트웨어 프로젝트를 연구하고 결함 제거 효율성(DRE)을 측정했습니다. 이는 사용자에게 도달하기 전에 잡힌 버그의 비율입니다. Applied Software Measurement의 데이터는 비선형 곡선을 보여줍니다: 70% 미만의 커버리지에서 DRE는 약 65-75%입니다. 85-95% 커버리지에서 DRE는 92-97%로 급등합니다. 관계는 선형이 아닙니다. 약 85%에서 곡선에 무릎(knee)이 있어 결함 누출이 급격히 감소합니다.

항공 전자 공학 업계는 수십 년 전에 이것을 알아냈습니다. DO-178C는 비행 중요 소프트웨어에 대한 FAA 표준으로, 레벨 A 시스템(버그가 비행기 추락을 의미하는 시스템)에 대해 수정된 조건/결정 커버리지(MC/DC)를 요구합니다. 분기 커버리지만으로는 10-20%의 결함을 놓칩니다. 라인 커버리지보다 더 엄격한 MC/DC는 >99%의 DRE를 달성합니다. 관료들이 서류 작업을 좋아하기 때문에 이것을 의무화하는 것이 아닙니다. 데이터가 특정 커버리지 임계값 이하에서는 사람을 죽이지 않는 것과 양립할 수 없는 비율로 중요한 결함이 누출된다는 것을 보여주었기 때문에 의무화하는 것입니다.

신뢰성 엔지니어링의 병렬 처리는 깔끔합니다. 공장은 Six Sigma라는 시스템을 사용하여 품질을 측정합니다. 아이디어는: 백만 단위당 발생하는 결함 수를 계산한 다음 "시그마 수준"으로 표현하는 것입니다. 시그마가 높을수록 결함이 적습니다. 3-시그마 프로세스는 백만 개당 약 67,000개의 결함을 생성합니다(꽤 나쁨). 4-시그마 프로세스는 약 6,200개를 생성합니다(10배 더 좋음). 5-시그마 프로세스는 233개를 생성합니다(또 다른 27배 더 좋음). 4에서 5 시그마로의 도약은 점진적인 개선이 아닙니다. 그것은 단계적 변화입니다.

테스트 커버리지는 동일한 곡선을 따릅니다. 70%에서 90% 커버리지로 가는 것은 30% 더 나은 것이 아닙니다. 그것은 누출이 10배 더 적은 것입니다. 70%에서 빠져나가는 결함은 테스트되지 않은 30%의 코드에 숨어 있습니다. 90%에서는 숨는 장소가 10%로 줄어들고 대부분의 위험한 경로가 잠겨 있습니다.

이제, 연구가 또한 무엇을 보여주는지에 대해 솔직해야 합니다. Mockus, Nagappan, and Dinh-Trong은 Windows Vista를 연구했으며, 커버리지가 사후 릴리스 결함 감소와 상관관계가 있지만 90%+에 도달하기 위한 노력이 급격히 증가한다는 것을 발견했습니다. 마지막 20%의 커버리지는 처음 70%보다 불균형적으로 더 많은 작업이 필요합니다. 이것은 수십 년 동안 사실이었습니다. 이것이 대부분의 팀이 70-80%에서 멈추고 충분히 좋다고 말하는 이유입니다.

하지만 무언가가 바뀌었습니다: AI 코딩 에이전트는 노력을 경험하지 않습니다.

그들은 열네 번째 예외 케이스 테스트를 작성하는 것에 지루해하지 않습니다. 금요일 오후 5시에 모서리를 자르지 않습니다. 까다로운 통합 테스트를 보고 "나중에 다시 오겠다"고 생각하지 않습니다. 인간 팀을 70%에서 멈추게 했던 노력 곡선은 에이전트에게 적용되지 않습니다. Claude에게 모듈의 모든 예외 케이스에 대한 테스트를 작성하도록 요청할 수 있으며, 그것은 새벽 2시에도 불평 없이 쾌활하고 철저하게 수행할 것입니다. 인간 팀에게 90% 커버리지를 비현실적으로 만들었던 잔혹한 마지막 20%는 정확히 AI 에이전트가 가장 잘하는 종류의 작업입니다.

이것이 진정한 해방입니다. AI가 코드를 더 빠르게 작성할 수 있게 해준다는 것이 아닙니다. 많은 사람들이 이미 그것을 알아차렸습니다. AI가 이전에는 유지하기에 너무 비쌌던 수준에서 검증할 수 있게 해준다는 것입니다. 데이터가 마법적이라고 말하는 90% 임계값은? 그것을 달성하는 데는 너무 많은 인간의 의지력이 들곤 했습니다. 이제는 공짜입니다.

그것이 핵심적인 차이점입니다. 래칫은 허영심 지표로서의 라인 커버리지에 관한 것이 아닙니다. 그것은 행동 계약을 인코딩하는 테스트(보유자 혼동 테스트, 가중치 반올림 테스트, 대화형 검토 게이트)에 관한 것입니다. 각 테스트는 특정 교훈을 잠급니다. 커버리지는 시스템의 동작 중 얼마나 많은 부분이 계약 아래에 있는지 알려주는 대리자입니다. 90%에서 거의 모든 동작 변경이 테스트 신호를 트리거합니다. 에이전트는 통과하거나(안전하게 배포 가능) 테스트를 중단합니다(즉시 발견됨).

나머지 10%는 통합 지점, 인프라 배관 및 진정으로 테스트하기 어려운 예외 케이스입니다. 괜찮습니다. 90%는 혼돈을 래칫으로 바꾸는 것입니다.

90%에 도달하는 것은 한때 영웅적인 노력이었습니다. 이제는 화요일입니다. 그것이 게임의 변화입니다.

개념 증명

저는 두 프로젝트를 모두 혼자 시작했습니다. 더 이상 혼자가 아닙니다.

GStack에는 이제 37명의 기여자가 있습니다. v1.30은 단일 릴리스에 21개의 커뮤니티 PR을 통합했습니다. GBrain에는 25명의 기여자가 있습니다. v0.31.1.1은 하나의 PR에 22개의 커뮤니티 수정 사항(인증 흐름, 스키마 부트스트래핑, 동기화, 개인 정보 보호)을 포함했습니다.

래칫이 이것을 안전하게 만듭니다. 모든 외부 PR은 기존 테스트 스위트를 통과해야 합니다. 새로운 기여자는 전체 시스템을 이해할 필요가 없습니다. 테스트를 통과하기만 하면 됩니다.

지난주 GBrain 릴리스가 이야기를 들려줍니다:

v0.31.0: 실시간 메모리를 위한 새로운 사실 테이블과 단기 기억을 장기 지식으로 승격시키는 꿈 통합 단계
v0.31.1: 사용자의 실제 두뇌 대신 빈 로컬 데이터베이스로 자동 라우팅되던 25개의 CLI 명령어 수정
v0.31.1.1: 하나의 PR에 22개의 커뮤니티 보고 수정 사항
v0.31.2: 30초 시간 초과를 추가하여 대규모 저장소에서 심볼릭 링크로 인해 영원히 중단되던 코드 동기화 수정

각 릴리스는 이전보다 더 많은 테스트와 함께 출시되었습니다. 에이전트가 코드와 함께 테스트를 작성합니다. 커버리지는 떨어지지 않습니다. 그것을 유지하는 노력이 더 이상 인간의 부담이 아니기 때문입니다.

새로운 복잡성 한계

소프트웨어의 복잡성 한계가 훨씬 더 높아졌습니다.

한때는 한 팀이 시스템을 머릿속에 담을 수 있는 능력에 의해 제한되었습니다. 이제는 전체 코드베이스, 스키마 기록, 테스트 스위트 및 문서를 컨텍스트에 로드할 수 있는 에이전트를 가진 한 사람에 의해 제한됩니다.

그것은 훨씬 더 큰 숫자입니다. 그리고 컨텍스트 창이 커지고 모델이 코드 추론 능력이 향상됨에 따라 계속 성장하고 있습니다.

이 모델(에이전트 + 취향 + 위로만 향하는 테스트 스위트)을 채택하지 않는 모든 소프트웨어 회사는 이미 그것을 가진 한 사람보다 느리고 품질이 낮은 제품을 출시하고 있습니다.

도구는 여기에 있습니다. 코드는 공개되어 있습니다. 테스트는 래칫입니다. 90% 커버리지, 모든 PR, 예외 없음.

50년 동안, 90% 커버리지는 항공 전자 공학 및 의료 기기(노력의 벽에 인간의 시간을 쏟을 예산이 있는 팀)를 위해 예약된 사치였습니다. AI 에이전트가 그 벽을 허물었습니다. 소프트웨어를 안정적으로 만드는 커버리지 임계값은 더 이상 비싸지 않습니다. 그것은 단지 설정일 뿐입니다. 질문은 90%를 감당할 수 있느냐가 아닙니다. 감당하지 않을 여유가 있느냐입니다.

래칫, 스킬 및 전체 지식 시스템은 GitHub에서 오픈 소스이며 무료입니다. 가서 구축하세요.

제 MIT 라이선스 오픈 소스 프로젝트: