GitHub가 Microsoft Build 2026에서 공개한 Copilot App의 핵심 기능 중 하나는 '에이전트 머지'다. CI 상태를 감시하고, 리뷰어를 추적하고, 실패한 검사를 처리한 뒤 병합 조건이 충족되면 PR을 자동으로 머지한다. 관리자는 '리뷰 피드백 반영까지만 맡길지, 아니면 병합까지 맡길지'를 저장소별로 설정할 수 있다. 겉으로 보면 생산성 도구다. 하지만 이 기능이 본격적으로 팀에 도입되는 순간, 진짜 질문이 시작된다. 에이전트가 머지한 코드의 품질을 누가 어떤 기준으로 검증하는가?
이 질문이 불편한 이유는 에이전트 생성 코드의 품질 문제가 이미 현장에서 반복되고 있기 때문이다. Anthropic이 자사 파운더 플레이북에서 명명한 개념인 '에이전트 기술 부채(agentic technical debt)'는 이 현상을 정확하게 포착한다. 일반적인 기술 부채는 한 스프린트를 투자하면 갚을 수 있다. 하지만 에이전트 기술 부채는 세션마다 복리로 불어난다. 에이전트는 매 세션마다 저장소를 읽고, 아키텍처를 재해석하고, 자신만의 방식으로 기능을 구현한다. 아무도 이전 세션의 결정을 강제하지 않으면, 세션 3쯤에는 이미 다른 아키텍처가 자라고 있다. 세션 7이 되면 같은 기능의 구현이 두 개가 되고, 어느 쪽이 정본인지 팀 누구도 모른다. 에이전트가 나쁜 게 아니다. 오히려 에이전트가 충분히 강력하기 때문에, 제약이 없으면 선택한 아키텍처에서 이탈하는 속도도 그만큼 빠르다.
여기에 세 번째 신호가 더해진다. Thoughtworks Technology Radar Vol.34(2026년 4월)는 뮤테이션 테스팅을 'Trial' 링에 올리면서 날카로운 경고를 붙였다. "LLM 생성 테스트가 늘어나는 시대에 커버리지 숫자는 이전과 다른 의미를 갖는다." AI가 짠 테스트가 코드를 실행은 하지만 아무것도 검증하지 않을 수 있다는 뜻이다. isAdult(age) { return age >= 18; } 함수에 isAdult(25)와 isAdult(10)만 테스트하면 커버리지는 100%다. 하지만 >=를 >로 바꿔도 두 테스트는 그대로 통과한다. 경계값 age = 18을 한 번도 검증하지 않았기 때문이다. 커버리지가 초록색이라는 건 에이전트가 테스트를 '많이' 만들었다는 뜻일 뿐, 테스트가 로직을 '제대로' 검증한다는 뜻이 아니다.
세 신호를 엮으면 하나의 구조적 문제가 드러난다. 에이전트는 코드를 짜고, 테스트를 생성하고, CI를 통과시키고, 심지어 PR까지 머지할 수 있다. 이 과정에서 인간 리뷰어가 개입하지 않으면, 커버리지 100%에 CI 그린인데도 실제로는 경계값을 검증 못 하는 테스트, 3번째 세션부터 설계 원칙이 어긋나기 시작한 코드, 누가 왜 그 결정을 했는지 아무도 모르는 아키텍처가 쌓인다. 속도는 빨라졌고 지표는 정상인데, 품질의 실질은 무너지고 있다.
그렇다면 팀 차원의 검증 구조는 어떻게 설계해야 하는가. 세 가지 레이어를 동시에 가져가야 한다.
첫째, 에이전트가 읽는 결정 문서를 만들어라. ADR(Architecture Decision Record)을 매 세션 시작 전 에이전트가 읽도록 강제하는 것이 핵심이다. "왜 이 아키텍처를 선택했는가, 어떤 대안을 거부했는가"가 기록된 문서가 있어야 에이전트는 같은 결정을 반복해서 재발명하지 않는다. CLAUDE.md나 코파일럿 저장소별 가이드라인이 이 역할을 할 수 있다. 문서가 없으면 에이전트에게 방향을 주는 게 아니라 매번 재교육을 반복하는 셈이다.
둘째, 에이전트 머지 범위를 단계적으로 확대하라. GitHub Copilot App이 제공하는 자동화 범위 설정—CI 복원만 허용, 리뷰 피드백 반영까지 허용, 병합까지 허용—은 팀의 신뢰 수준에 따라 점진적으로 확장해야 한다. 기본값은 "모든 쓰기 작업 전에 승인 요청"이다. 이게 맞는 시작점이다. 신뢰는 에이전트가 만드는 게 아니라 팀이 검증 데이터를 축적하면서 부여하는 것이다.
셋째, 커버리지 대신 뮤테이션 스코어를 품질 게이트로 추가하라. AI가 생성한 테스트는 커버리지를 쉽게 올리지만 경계값을 빠뜨리는 경향이 있다. Stryker나 Pitest 같은 뮤테이션 테스팅 도구를 CI 파이프라인에 넣어 에이전트 생성 테스트가 실제로 로직 변화를 감지하는지 검증해야 한다. 커버리지 임계값을 올리는 것보다 뮤테이션 스코어 임계값을 설정하는 게 AI 시대의 품질 게이트로 더 실효적이다.
에이전트 도구가 강해질수록 팀의 검증 구조가 더 중요해지는 역설은 앞으로도 계속될 것이다. GitHub Copilot App의 캔버스, 에이전트 머지, 보안 리뷰 스킬은 에이전트가 개발 파이프라인 전체를 관통할 수 있게 해준다. 그 파이프라인이 품질을 지키려면 에이전트 자율성을 늘리는 속도만큼, 팀이 검증 구조를 설계하는 속도를 따라가야 한다. 에이전트를 믿는 것과 에이전트를 검증하는 것은 양립 불가능한 선택이 아니다. 검증 구조가 있어야 신뢰를 줄 수 있고, 신뢰를 준 만큼 자율성을 확장할 수 있다. 그 순서를 바꾸면 빠르게 달리다 아무도 모르게 망가진다.