코딩 에이전트가 짠 코드를 AI가 승인할 수 있나…완성 기준은 ‘생성’이 아니라 별도 검증 단계에 달렸다
코딩 에이전트가 코드를 만들고 다른 AI가 이를 검토하는 흐름은 이미 제품 기능으로 들어오고 있다. 다만 여기서 곧바로 ‘AI가 만든 코드를 AI가 승인해도 된다’는 결론이 나오지는 않는다. 현재 공식 문서들을 종합하면 AI는 생성과 1차 검토, 수정 제안, 재검토까지 맡을 수 있지만, 완성 기준은 여전히 컴파일 성공, 테스트 통과, 보호 브랜치 규칙 충족, 재검토 여부, 운영 전환 뒤 장애 지표처럼 별도 게이트로 나뉘어 관리되는 구조에 가깝다.
이 기준이 중요한 이유는 개발 성공과 배포 가능성이 같은 말이 아니기 때문이다. 코드 생성 모델이 과제를 끝냈다고 판단해도, 저장소 규칙이 요구하는 승인 수나 상태 점검, 보안 검토, 변경 후 재승인 조건을 통과하지 못하면 운영 반영은 멈춘다. ‘코딩 에이전트의 완성 기준은 무엇인가’라는 질문에 대한 현재의 가장 보수적인 답은, 모델의 자기평가가 아니라 저장소와 배포 체계가 요구하는 독립 검증 조건을 모두 충족했는지에 달려 있다는 것이다.
AI 검토는 가능해졌지만 기본값은 아직 ‘의견’에 가깝다
가장 분명한 사례는 GitHub Copilot 코드 리뷰다. GitHub 문서에 따르면 Copilot은 풀리퀘스트를 검토해 문제를 찾고 수정 제안을 남길 수 있으며, 필요하면 후속 수정 작업까지 연결할 수 있다. 다만 기본 동작은 승인이나 변경 요청이 아니라 ‘코멘트’ 리뷰다. 즉 AI 검토 결과는 우선순위를 붙여 사람에게 보여주는 피드백이며, 기본 설정만으로 필수 승인 수를 자동 충족하는 구조는 아니다.
GitHub는 2026년 문서에서 Copilot 승인 기능을 공개 미리보기로 설명하고 있다. 이 기능이 켜진 경우에는 Copilot이 승인 리뷰를 남겨 저장소의 required-approval 규칙을 충족할 수 있다고 적고 있다. 그러나 이 역시 기본값이 아니고, 새 커밋이 올라오면 기존 승인이 취소돼 다시 검토를 요청해야 한다. 결국 AI 검토가 도입됐더라도 승인 권한의 범위와 유효 조건은 저장소 정책이 따로 정한다는 뜻이다.
이 점은 기업 IT 책임자에게 중요한 대목이다. ‘AI 리뷰어가 있다’는 사실만으로 승인 체계를 자동화했다고 보기 어렵기 때문이다. 실제 통제 포인트는 AI가 몇 건의 코멘트를 남겼는지가 아니라, 그 코멘트가 어떤 규칙과 연결되는지, 수정 뒤 재검토가 의무인지, 새 커밋이 올라오면 승인이 무효화되는지, 사람 승인과 어떤 비율로 병행되는지에 있다.
완성 기준은 ‘코드가 생겼다’가 아니라 ‘분리된 게이트를 통과했다’는 것
공식 문서 기준으로 보면 자동 개발의 완성은 하나의 지표로 정의되지 않는다. 첫 단계는 생성 성공이다. 에이전트가 요구한 파일과 변경분을 만들고 빌드 가능한 상태를 냈는지가 여기에 해당한다. 하지만 그다음에는 테스트와 상태 점검이 붙는다. GitHub의 보호 브랜치 규칙은 통과해야 할 상태 검사와 승인 리뷰 수를 별도로 요구할 수 있도록 설계돼 있다.
여기에 재검토 단계가 추가된다. GitHub는 Copilot이 검토한 뒤 변경이 다시 올라오면 자동 재검토를 별도 설정해야 하며, 수동 재검토도 가능하다고 밝히고 있다. 다시 말해 AI가 스스로 수정한 코드라고 해도 그 수정이 새로운 위험을 만들었는지 다시 확인하는 절차가 공식 워크플로에 이미 들어 있다. 개발 자동화의 실제 단위는 ‘한 번 생성하고 끝’이 아니라 생성, 검토, 수정, 재검토의 반복이다.
운영 승인 단계는 더 좁다. GitHub 문서에서도 보안 민감하거나 규제가 강한 코드베이스는 초안 단계의 자동 리뷰와 병합 전 재검토를 함께 쓰라고 권한다. 이는 AI 리뷰가 사람 검토를 없애기보다 앞단의 결함 탐지 비용을 낮추는 역할에 가깝다는 뜻이다. 따라서 현 시점에서 AI가 검수도 맡을 수 있느냐는 질문에는 ‘맡을 수는 있지만, 그 결과를 최종 승인으로 인정할지 여부는 저장소 규칙과 조직 통제에 달려 있다’고 답하는 편이 정확하다.
MCP와 A2A는 연결 규격이지, 품질 보증 규격은 아니다
에이전트 도입 논의에서 자주 함께 언급되는 MCP와 A2A도 같은 맥락에서 봐야 한다. Anthropic은 2025년 12월 9일 Model Context Protocol, 즉 MCP를 리눅스재단 산하 Agentic AI Foundation에 기증한다고 발표했다. 이 발표의 핵심은 특정 기업 제품이 아니라, 에이전트가 외부 도구와 데이터에 접근하는 공통 규격을 중립 거버넌스 아래 두겠다는 데 있다.
MCP의 최근 공식 블로그와 문서를 보면 이 규격은 도구 호출, 상태 없는 요청·응답 구조, 장기 작업을 위한 확장, 인증 강화를 중심으로 발전하고 있다. 이는 에이전트가 더 많은 맥락과 시스템에 연결될 수 있게 한다는 뜻이지, 그 결과가 자동으로 정확해진다는 뜻은 아니다. 오히려 연결 범위가 넓어질수록 어떤 도구를 호출했는지, 인증이 적절했는지, 장기 작업 상태를 어떻게 추적할지 같은 통제 문제가 더 중요해진다.
A2A도 마찬가지다. A2A 공식 규격은 서로 다른 에이전트 시스템 사이의 상호운용을 위한 공개 표준으로 자신을 설명하며, 에이전트는 선언한 기능에 따라 비동기 작업을 주고받을 수 있다. 그러나 규격은 메시지 형식과 기능 선언, 오류 처리, 작업 상태 같은 상호작용 방식을 정의할 뿐, 그 에이전트의 판단이 옳은지까지 보증하지는 않는다. 다시 말해 MCP가 도구 연결 규격이라면 A2A는 에이전트 간 대화 규격에 가깝고, 둘 다 코드 품질의 최종 책임을 대신하지는 않는다.
기업이 봐야 할 지표는 생성 성능보다 유지보수·보안·장애 비용이다
이 때문에 현업의 평가는 모델 데모보다 훨씬 보수적으로 잡혀야 한다. 첫째, 개발 성공 지표와 테스트 통과 지표를 분리해야 한다. 에이전트가 코드를 제출한 비율이 높더라도 테스트 통과율과 재오픈 비율이 낮으면 실제 생산성 개선으로 보기 어렵다. 둘째, 리뷰 통과 뒤 운영 단계에서 결함이 얼마나 되돌아오는지 봐야 한다. 병합 후 장애, 롤백, 긴급 패치가 늘면 앞단의 자동화 효율은 과장됐을 가능성이 크다.
셋째, 유지보수성 지표가 필요하다. AI가 같은 기능을 더 빨리 만들더라도 경로가 복잡해지고 규칙 예외가 늘면 다음 변경 비용이 커질 수 있다. 넷째, 보안 결함과 권한 관리가 핵심이다. MCP 문서가 인증과 권한 부여를 별도 사양으로 다루고, GitHub 문서가 보안 민감 코드베이스에서 재검토와 추가 지침을 권하는 이유도 여기 있다. 더 많은 도구와 저장소 맥락을 에이전트에 연결할수록, 잘못된 권한 위임이나 검토 누락이 단순 버그보다 큰 사고로 이어질 수 있다.
결국 자동 개발에서 AI 검수의 역할은 사람을 완전히 대체하는 최종 판정자가 아니라, 병합 전 결함 발견율을 높이고 반복 작업을 줄이는 중간 심사자로 보는 편이 현재 공식 문서와 가장 잘 맞는다. 완성 기준은 하나의 모델 점수로 정리되지 않는다. 코드 생성 성공, 필수 테스트 통과, 정책상 승인 충족, 변경 후 재검토, 운영 장애 지표 안정화까지 이어지는 다층 게이트를 통과했을 때 비로소 ‘완성’에 가깝다.
자료: Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation(2025-12-09); Model Context Protocol Blog, The 2026-07-28 Specification(2026-07-28); A2A Protocol, Overview – A2A Protocol v1.0.1 specification(2026); GitHub Docs, Using GitHub Copilot code review(2026); GitHub Docs, Managing protected branches(2026); GitHub Docs, Use GitHub Copilot code review across the pull request lifecycle(2026)