AI 코딩 에이전트가 만든 변경 사항을 검토할 때 가장 위험한 순간은 테스트가 모두 녹색으로 바뀐 때다. 에이전트가 구현 코드와 테스트 코드를 함께 만들었다면, 요구사항을 잘못 해석한 구현과 그 오해를 승인하는 테스트가 한 묶음으로 통과할 수 있다.
따라서 팀이 먼저 결정할 문제는 “이 에이전트의 테스트 통과율이 충분한가”가 아니다. 에이전트가 해석한 요구사항과 별개로, 어떤 검증이 배포 승인을 막거나 통과시킬 것인가를 정해야 한다. 비용, 토큰 사용량, 작업 완료 속도는 그 다음의 비교 항목이다.
작은 TypeScript 도구를 대상으로 한 공개 실험에서도 이런 문제가 드러났다. 한 구현은 자체 테스트 수십 개와 별도 검증, 타입 검사를 통과했지만, 요구사항상 허용되지 않아야 할 eventId: null 입력을 받아들였다. 자체 테스트도 그 동작을 정상으로 판정했다. 요구사항을 다시 대조해 해당 경계값을 외부 검증에 넣은 뒤에야 실패가 나타났고, 수정 요청과 재검증이 이어졌다.
이 사례가 특정 도구의 일반 성능을 증명하지는 않는다. 다만 AI 코딩 에이전트를 팀에 넣을 때 어떤 실패가 생길 수 있는지, 그리고 왜 별도 검증 게이트가 필요한지는 분명히 보여준다.
실패는 코드가 아니라 검증 기준의 공유에서 시작된다
AI 에이전트가 요구사항을 잘못 읽는 일 자체는 낯선 문제가 아니다. 사람이 구현해도 선택적 필드, null과 빈 문자열의 차이, 권한이 없는 사용자의 처리, 오류 응답의 형식처럼 경계 조건을 놓칠 수 있다.
에이전트 환경에서는 이 문제가 더 빨리 숨겨질 수 있다. 구현을 작성한 주체가 테스트 시나리오도 만들고, 테스트 실패를 수정하며, 완료 보고까지 하기 때문이다. 에이전트가 “테스트를 통과했다”고 말할 때 그 테스트는 대개 자신이 채택한 해석을 확인한다. 요구사항 원문에 없는 행동까지 검증해 주지는 않는다.
실패 메커니즘은 다음처럼 이어진다.
- 요구사항에 모호하거나 압축된 조건이 있다.
- 에이전트가 한 가지 해석을 선택해 구현한다.
- 에이전트가 같은 해석을 바탕으로 테스트를 작성한다.
- 코드와 테스트가 모두 일관되게 통과한다.
- 팀은 테스트 개수와 통과 여부를 품질 신호로 읽는다.
- 운영 조건이나 독립 검증에서 처음으로 요구사항 차이가 드러난다.
문제는 테스트가 적어서만 생기지 않는다. 테스트가 많아도 같은 가정에서 나왔다면, 같은 빈틈을 반복해서 확인할 수 있다. 그래서 자체 테스트는 회귀 방지와 구현 확인에는 유용하지만, 배포 적합성을 혼자 결정하는 근거가 되어서는 안 된다.
조기 신호는 “통과한 테스트”보다 요구사항의 빈칸에 있다
팀은 에이전트가 만든 결과물을 받기 전에, 검증에서 빠지기 쉬운 조건을 먼저 표시해 둘 수 있다. 특히 아래 항목은 독립 검증 대상으로 분리할 만하다.
-
값의 존재 여부와 값의 유효성이 다른 입력
예를 들어 필드가 누락된 경우,null인 경우, 빈 문자열인 경우, 형식은 맞지만 의미상 허용되지 않는 값은 서로 다른 규칙을 가질 수 있다. -
성공 경로만 있는 요구사항
“등록한다”, “조회한다”, “연동한다”는 설명만 있고 중복 요청, 권한 없음, 외부 시스템 오류, 부분 실패의 처리 기준이 없다면 구현과 테스트가 임의의 결론을 낼 가능성이 높다. -
정책 문장으로 표현된 조건
“존재한다면”, “권한이 있는 경우에만”, “변경되지 않아야 한다” 같은 표현은 코드로 옮길 때 분기 조건이 된다. 자연어 요구사항에 남겨두면 각 구현자가 다르게 읽을 수 있다. -
결과가 아니라 실행 권한이 문제인 작업
에이전트가 패키지를 설치하고, 셸 명령을 실행하고, 네트워크에 접근하고, CI 설정을 변경할 수 있다면 산출물 검증과 실행 권한 검증은 분리해야 한다.
마지막 항목은 코드 품질과 다른 종류의 위험이다. OWASP는 에이전트형 코딩 도구가 파일 수정, 명령 실행, 패키지 설치, 네트워크 접근, 브랜치 푸시까지 수행할 수 있다고 설명한다. 저장소의 이슈, README, 의존성 변경 기록, 외부 웹 페이지, 도구 응답도 에이전트가 읽으면 행동에 영향을 주는 입력이 될 수 있다. 따라서 “코드가 맞는가”와 “그 코드가 만들어지는 과정에서 어떤 권한이 사용됐는가”를 같은 승인으로 처리하면 책임 범위가 흐려진다.
검증 게이트는 에이전트 작업 흐름 밖에 둬야 한다
독립 검증은 사람이 모든 코드를 수동으로 읽는다는 뜻이 아니다. 에이전트가 작성하거나 수정할 수 있는 검증 묶음과 분리된 기준을 두는 일이다. 팀 규모와 제품 위험도에 따라 깊이는 달라질 수 있지만, 다음 네 층을 구분하면 승인 기준을 정리하기 쉽다.
1. 요구사항 판정표
개발 시작 전에 담당자가 기능 조건을 판정 가능한 문장으로 적는다. “사용자 이벤트 ID를 검증한다”보다 “이벤트 ID가 제공되면 비어 있지 않은 문자열이어야 하며, null은 허용하지 않는다”처럼 입력과 기대 결과를 적는 방식이다.
이 문서는 긴 명세서일 필요가 없다. 중요한 것은 각 조건이 구현자의 설명이 아니라 제품 또는 업무 책임자의 승인으로 확정됐다는 점이다. 에이전트에는 이 문서를 작업 맥락으로 제공하되, 에이전트가 문서 자체를 수정해 승인 기준을 바꾸지 못하게 관리하는 편이 낫다.
2. 독립 인수 검증
인수 검증은 “구현이 내부적으로 잘 작동하는가”보다 “승인된 요구사항을 충족하는가”를 확인한다. 에이전트가 작성한 단위 테스트와 별도로 관리하고, 최소한 핵심 입력 경계와 금지된 동작을 담는다.
이 검증은 다른 모델에게 다시 작성하게 하는 것만으로 독립성을 얻지 못한다. 모델이 달라도 같은 모호한 요구사항을 참고하면 같은 해석을 반복할 수 있다. 제품 책임자, QA 책임자, 보안 담당자 또는 해당 업무 규칙을 아는 개발자가 판정표를 기준으로 검증 항목을 승인해야 한다.
중요한 변경이라면 에이전트에 정답을 미리 알려주지 않은 테스트를 별도 CI 단계에서 실행하는 방법도 검토할 수 있다. 다만 테스트 내용을 완전히 숨기는 것이 목적은 아니다. 요구사항과 승인 기준의 소유자가 구현 주체와 분리돼 있는지가 핵심이다.
3. 실행 환경 검증
타입 검사, 빌드, 정적 분석, 의존성 확인, 실제 명령 실행은 서로 다른 오류를 찾는다. 공개 실험에서도 타입 검사와 별도 검증을 함께 적용했으며, 자체 테스트가 놓친 입력 조건은 별도 검증을 추가한 뒤 발견됐다.
여기서 팀은 “무엇을 실행했는가”도 남겨야 한다. 에이전트가 새 패키지를 추가했는지, 설정 파일을 바꿨는지, CI 워크플로를 수정했는지, 네트워크 접근이 필요한 명령을 실행했는지를 변경 목록에서 확인할 수 있어야 한다. 테스트 결과가 정상이어도 실행 경로가 승인 범위를 넘었다면 별도 검토 대상으로 돌리는 편이 안전하다.
4. 배포 승인
배포 승인은 에이전트의 완료 메시지나 PR의 테스트 배지에 맡기지 않는다. 승인자는 최소한 다음 질문에 답할 수 있어야 한다.
- 요구사항 판정표의 핵심 조건은 모두 검증됐는가?
- 에이전트 자체 테스트와 독립 인수 검증을 구분해 실행했는가?
- 실패했던 조건이 있다면 수정 후 같은 조건을 다시 검증했는가?
- 변경된 의존성, 권한, CI 설정, 배포 설정이 있는가?
- 이 변경을 승인할 사람은 기능 결과와 실행 범위를 함께 확인했는가?
이 절차는 결재 단계를 늘리자는 제안이 아니다. 자동으로 통과시킬 수 있는 변경과 사람이 멈춰 세워야 하는 변경을 구분하려는 장치다.
승인 절차는 변경 위험에 따라 다르게 설계한다
모든 에이전트 작업에 같은 수준의 검증을 붙이면 팀은 곧 우회 경로를 찾게 된다. 반대로 모든 작업을 “작은 변경”으로 간주하면 독립 게이트는 이름만 남는다. 그래서 변경의 종류별로 승인 경로를 나누는 편이 현실적이다.
예를 들어 문구 수정이나 격리된 내부 도구의 반복 코드처럼 권한, 데이터, 외부 연동에 영향이 제한된 변경은 자동 검증과 코드 소유자 검토로 처리할 수 있다. 반면 인증, 권한, 결제, 개인정보, 고객 데이터 접근, CI/CD 설정, 외부 패키지 추가처럼 실패 영향이 큰 변경은 요구사항 판정표와 독립 인수 검증, 권한 검토를 함께 요구하는 식이다.
판정 기준은 “AI가 만들었는가”가 아니라 “이 변경이 무엇을 건드리는가”여야 한다. 사람이 작성한 코드에도 같은 기준을 적용할 수 있어야 절차가 유지된다.
도입 전에 팀이 합의할 질문
AI 코딩 에이전트의 요금제, 모델, 실행 속도를 비교하기 전에 다음 질문부터 정리해 두는 편이 좋다.
-
에이전트가 만든 테스트와 분리해 관리할 검증은 무엇인가?
핵심 업무 규칙, 권한 조건, 금지된 입력, 장애 시 동작을 먼저 정한다. -
요구사항 해석이 바뀌었을 때 누가 승인하는가?
에이전트가 코드와 테스트를 고쳐 통과시켜도, 업무 규칙을 바꿀 권한까지 가진 것은 아니다. -
어떤 변경은 자동 병합할 수 없게 막을 것인가?
의존성 추가, 권한 설정, CI/CD 변경, 외부 서비스 연결처럼 별도 승인이 필요한 범주를 정한다. -
실패를 발견했을 때 무엇을 다시 검증할 것인가?
오류 한 건을 고친 뒤 전체 요구사항 판정표와 독립 검증을 다시 실행할지, 수정 범위만 볼지 기준을 남긴다. -
에이전트가 접근할 수 있는 파일, 비밀 정보, 네트워크, 도구는 어디까지인가?
산출물 검토 이전에 실행 경계를 정해야 한다. 넓은 권한과 자동 승인을 함께 주면, 코드 오류 외의 문제가 더 큰 범위로 번질 수 있다.
AI 코딩 에이전트 도입의 첫 실험은 생산성 측정으로 시작하기 쉽다. 그러나 팀이 먼저 시험해야 할 것은 에이전트가 얼마나 많은 코드를 만드는지가 아니다. 요구사항을 잘못 해석한 코드와 테스트가 함께 통과했을 때, 누가 어느 단계에서 멈추게 할 수 있는지다. 그 답을 CI 설정, 승인 권한, 독립 검증 묶음으로 남겨둔 팀만이 속도를 높여도 승인 기준을 잃지 않는다.
