CI가 초록불로 가득 찬데 사흘 뒤 버그가 터졌다면, 문제는 테스트가 없는 게 아니다. 테스트가 아무것도 검증하지 않고 있었던 것이다. dev.to에 올라온 한 분석 글이 이 함정을 정확하게 해부한다. AI에게 "이 함수 테스트 짜줘"라고 던지면, LLM은 CI를 통과시키는 데 최적화된 테스트를 돌려준다. 커버리지 숫자는 올라가고, 어시스턴트는 만족스럽게 작업을 완료 처리한다. 그런데 그 테스트 안에 실제로 동작을 검증하는 assertion이 있는지는 아무도 묻지 않는다.
문제의 핵심: LLM의 보상 신호는 '테스트 통과'지 '버그 검출'이 아니다
100유로 초과 시 10을 깎는 단순 함수를 예로 들어보자. AI가 생성한 테스트는 got < 0을 체크한다. total - 10을 total * 2로 바꿔도, return 42로 바꿔도 이 테스트는 초록불이다. 커버리지 도구는 해당 라인이 '실행됐다'고 기록하고, 리포트는 90%를 찍는다. 90% 커버리지 안에 절반의 허상 테스트가 숨어 있어도 아무도 모른다. LLM 입장에서 보면 합리적이다. 가장 짧은 경로로 초록불을 만들면 작업이 끝나니까. 그 테스트가 실제로 코드의 의도를 검증하는지는 외부에서 강제하지 않으면 AI가 신경 쓸 이유가 없다.
대응: 테스트를 믿기 전에 먼저 깨뜨려라
해법은 TDD가 오래전부터 알고 있었다. 테스트를 신뢰하기 전에 그 테스트가 실패할 줄 아는지 확인하는 것이다. 코드를 의도적으로 망가뜨리고, 테스트가 빨간불로 바뀌면 그 테스트는 살아있다. 초록불 그대로라면 버려야 한다. Discount(150) != 140을 체크하는 테스트는 total + 10으로 변경하는 순간 160 != 140으로 빨간불이 된다. 이게 진짜 테스트다. 통과하는 테스트가 아니라 왜 실패하는지를 아는 테스트.
이걸 손으로 모든 케이스에 반복하는 건 당연히 스케일이 안 된다. 뮤테이션 테스팅이 이 과정을 자동화한다. gremlins 같은 도구는 코드에 수백 개의 작은 변이(>를 >=로, +를 -로)를 적용하고 각각의 변이마다 테스트 스위트를 재실행한다. 변이를 해도 테스트가 살아남으면 그 자리에 구멍이 있는 것이다. 커버리지가 '이 라인이 실행됐다'를 말해준다면, 뮤테이션 스코어는 '이 라인이 실제로 검증됐다'를 말해준다. 이 두 숫자는 전혀 다른 것을 측정하고, 중요한 건 두 번째다.
팀 단위 설계: AI 생성 테스트를 게이트로 막아라
개인 개발자 수준의 경계 설정을 넘어, 이걸 팀 워크플로우에 어떻게 내재화할 것인가가 진짜 문제다. 에이전트가 코드와 테스트를 함께 생성할 때, 에이전트 스스로 완료를 선언하게 두면 안 된다. AI가 작성한 테스트는 CI 파이프라인에 진입하기 전에 객관적인 게이트를 통과해야 한다. 빌드 → 린트 → 테스트 스위트 → 크리티컬 함수에 대한 뮤테이션 체크, 이 순서가 에이전트의 PR 머지 조건이 되어야 한다. LLM이 '이 테스트 괜찮음'에 대한 투표권을 갖게 두면 안 된다. 뮤테이션이 판정하고 에이전트는 결과를 관찰할 뿐이다.
두 번째 함정: 에이전트는 왜 같은 실수를 세션마다 반복하는가
테스트 품질 문제를 구조적으로 풀었다고 해도, 또 다른 구멍이 남는다. 에이전트는 세션이 새로 시작될 때마다 프로젝트를 처음 보는 사람처럼 행동한다. 어제 인증 플로우를 왜 그렇게 설계했는지, 특정 파일에 왜 손을 대면 안 되는지, 팀이 내린 아키텍처 결정의 맥락이 모두 사라진다. CLAUDE.md는 행동 지침에 적합하지만 프로젝트 전체 지식을 담기엔 너무 단순하다. 팀 위키는 사람이 읽는 용도로 최적화됐고, 에이전트가 매 세션 효율적으로 소비하기엔 구조가 맞지 않는다.
OKF: 에이전트와 팀이 함께 읽는 지식 포맷
이 문제를 정면으로 겨냥한 접근이 Open Knowledge Format(OKF)이다. Google Cloud Data Cloud 팀이 2026년 6월 발표한 오픈 포맷으로, 핵심은 단순하다. .okf/ 디렉토리 안에 YAML 프론트매터를 가진 마크다운 파일들로 프로젝트 지식을 표현한다. 서비스 설명, 아키텍처 결정, 런북, '이 로직 건드리지 마, 이유는 여기'까지 모두 코드 옆에 버전 관리된 파일로 산다. cat 으로 읽을 수 있고, git diff로 리뷰할 수 있고, PR로 관리된다.
okf-skills는 이 포맷을 Claude Code에서 쓸 수 있게 해주는 툴체인이다. /okf:okf로 번들을 생성·유지하고, /okf:validate로 스펙 적합성을 체크하고, /okf:visualize로 개념 간 의존 관계를 그래프로 시각화한다. 에이전트가 매 세션 프로젝트를 재발견하는 대신, .okf/ 번들을 컨텍스트로 로드해서 팀이 쌓아온 지식 위에서 작업을 시작할 수 있다.
두 문제가 가리키는 하나의 결론
뮤테이션 테스팅과 OKF는 다른 문제를 풀지만, 같은 구조적 교훈을 공유한다. AI가 생성한 산출물은 인간의 기준으로 검증되거나, 기계적으로 검증 가능한 포맷으로 설계되어야 한다는 것이다. 허상 테스트가 무서운 이유는 없는 것보다 나쁘기 때문이다. 없으면 보인다. 허상은 안심시킨다. 에이전트 지식 소실도 마찬가지다. 매번 재설명하는 건 비효율이지만, 잘못된 맥락으로 작업하는 건 리스크다.
내일 팀에서 당장 적용할 수 있는 것
이론보다 실행이다. 당장 가능한 첫 단계는 두 가지다. 첫째, AI가 작성한 테스트에 뮤테이션 체크를 CI 게이트로 추가한다. gremlins(Go) 또는 언어에 맞는 뮤테이션 도구를 파이프라인에 심고, 크리티컬 함수의 뮤테이션 스코어를 PR 머지 조건으로 설정한다. 둘째, .okf/ 디렉토리를 프로젝트에 추가하고 팀의 핵심 아키텍처 결정과 런북부터 채워 넣기 시작한다. 에이전트가 매 세션 다시 발견하는 지식을 코드 옆에 고정하는 것이다.
초록불은 증거가 아니다. 테스트는 실패할 줄 알아야 살아있는 것이다. 그리고 에이전트는 팀의 지식을 기억할 수 있는 구조 위에서만 팀 자산이 된다.