AI 코딩 에이전트를 팀에 붙였을 때 가장 먼저 나타나는 문제는 품질 저하가 아니라 속도 비대칭이다. 에이전트는 사람보다 빠르게 코드를 생성하지만, 검증 구조가 그 속도를 따라가지 못하면 결함도 똑같이 빠르게 쌓인다. CTO나 개발 리드가 에이전트 도입 초기에 맞닥뜨리는 진짜 문제는 "어떤 모델을 쓸까"가 아니라 "이 코드가 배포되기 전에 누가, 어느 단계에서, 무엇을 확인하는가"다.
이 글은 그 질문에 답하기 위한 권한 구조와 게이트 설계를 요구사항 단계에서 어떻게 정의할지 다룬다.
왜 모델 선택보다 구조 설계가 먼저인가
에이전트가 만들어낸 코드 결함의 상당 부분은 모델의 능력 문제가 아니다. 에이전트에게 어떤 범위의 작업을 맡겼는지, 그리고 그 결과물을 어떤 순서로 누가 검토하는지가 정해지지 않은 채 운영된 결과다.
예를 들어 시스템 경계를 바꾸는 작업과 단일 함수를 수정하는 작업을 동일한 방식으로 에이전트에게 넘기면, 에이전트는 두 작업의 영향 범위 차이를 스스로 구분하지 않는다. 검증도 마찬가지다. 보안 취약점을 찾는 검토를 버그 수정보다 먼저 실행하면, 이미 구조적으로 잘못된 코드에 공격 시나리오를 적용하는 셈이 된다. 순서가 틀리면 검증 결과도 신뢰하기 어렵다.
구조 설계가 먼저여야 하는 이유는 여기에 있다. 에이전트가 생성하는 코드의 범위와 그 코드를 검증하는 순서를 명시하지 않으면, 속도는 빨라지고 통제는 느슨해진다.
작업 범위를 세 단계로 분리하는 이유
에이전트에게 작업을 넘기기 전에 그 작업이 어느 수준의 변경인지를 먼저 정해야 한다. 범위가 다르면 에이전트의 역할도 달라지고, 검토 권한도 달라진다.
시스템 수준 변경은 서비스 경계, 공유 인터페이스, 배포 구조처럼 전체 아키텍처에 영향을 미치는 작업이다. 이 범위의 작업을 에이전트에게 맡길 때는 아키텍처 소유자가 작업 범위를 명시적으로 정의하고, 결과물의 구조적 적합성을 검토할 책임을 가져야 한다.
서브시스템 수준 변경은 기능 슬라이스, 서비스 모듈, 통합 인터페이스처럼 시스템 설계를 바꾸진 않지만 여러 파일과 컴포넌트에 걸치는 작업이다. 이 범위는 기능 단위 책임자가 작업 범위를 제한하고, 모듈 간 의존성 변화를 확인해야 한다.
로컬 수준 변경은 몇 개 파일, 함수, 단위 테스트처럼 영향이 명확히 한정된 작업이다. 범위가 좁고 소유권이 분명하기 때문에 에이전트가 가장 독립적으로 작업할 수 있는 영역이다.
이 분리가 중요한 이유는 에이전트가 작업을 완료했을 때 결과를 검토할 사람이 달라지기 때문이다. 로컬 변경을 시스템 수준 검토자가 일일이 확인하면 병목이 생기고, 시스템 수준 변경을 로컬 검토 수준으로 통과시키면 아키텍처 결함이 배포된다.
검증 게이트를 순서대로 통과해야 하는 이유
검증 단계를 설계할 때 흔히 저지르는 실수는 게이트를 나열하되 순서를 강제하지 않는 것이다. "구조 검토, 버그 검토, 보안 검토를 모두 거친다"는 요구사항은 있지만, 어느 것이 먼저인지가 정해지지 않으면 검토자마다 다른 순서로 진행한다.
게이트는 반드시 순서대로 통과해야 한다. 그 이유는 각 게이트가 이전 게이트의 결과를 전제하기 때문이다.
첫 번째 게이트는 구조 검증이다. 코드의 경계가 올바른지, 추상화가 적절한지, 파일 소유권이 맞는지를 확인한다. 이 게이트는 버그를 직접 수정하지 않는다. 코드가 잘못된 위치에 있거나 잘못된 범위의 에이전트가 작성했다면, 수정 지시를 해당 범위의 작업자에게 돌려보내는 것이 이 게이트의 역할이다.
두 번째 게이트는 버그와 운영 이슈 검증이다. 구조가 올바르다는 것이 확인된 후에 실행한다. 이 시점에서 발견된 문제가 아키텍처적 원인에서 비롯된 것이라면, 직접 수정하지 않고 첫 번째 게이트로 올려보내야 한다. 구조 문제를 로컬 패치로 덮으면 나중에 더 큰 비용이 발생한다.
세 번째 게이트는 적대적 검증이다. 엣지 케이스, 경쟁 조건, 잘못된 입력, 보안 취약점, 롤백 경로를 공격하듯 검토한다. 여기서 구조적 문제가 발견되면 게이트를 다시 처음부터 통과해야 한다. 구조 문제를 세 번째 게이트에서 처리하려 하면, 검증 비용이 쌓이고 결함은 남는다.
이 순서가 깨지는 가장 흔한 상황은 일정 압박이다. 구조 검증을 건너뛰고 버그 검증부터 시작하거나, 보안 검토를 마지막에 형식적으로 진행할 때 에이전트가 만든 결함이 배포 환경까지 넘어간다.
누가 게이트를 통과시킬지를 요구사항으로 정해야 한다
게이트 순서를 정했다면, 다음 질문은 각 게이트를 누가 통과시키는가다. 이것이 요구사항 단계에서 가장 명확히 정해져야 하는 부분이다.
몇 가지 기준을 제안한다.
첫째, 게이트 통과 권한은 작업 범위에 따라 달라져야 한다. 로컬 수준 변경의 구조 검증은 해당 기능을 담당하는 개발자가 할 수 있지만, 시스템 수준 변경의 구조 검증은 아키텍처 소유권을 가진 사람이 확인해야 한다. 에이전트가 생성한 코드라는 이유로 검토 권한을 낮추면 안 된다.
둘째, 각 게이트의 통과 기준을 사전에 문서화해야 한다. "괜찮아 보이면"은 기준이 아니다. 구조 검증에서는 어떤 경계 위반이 재작업 사유인지, 버그 검증에서는 어떤 이슈가 아키텍처 문제로 분류되는지를 미리 정해야 검토자가 일관된 판단을 내릴 수 있다.
셋째, 게이트를 되돌릴 권한도 명시해야 한다. 세 번째 게이트에서 구조 문제가 발견됐을 때 누가 재시작을 결정하는가? 이 권한이 불명확하면 팀은 로컬 패치로 문제를 덮는 쪽을 선택하게 된다. 그 선택이 기술 부채가 된다.
요구사항 단계에서 이 구조를 정의하는 방법
프로젝트 요구사항 단계에서 AI 코딩 에이전트의 권한 구조와 게이트 순서를 정의할 때, 아래 네 가지를 산출물로 만들어야 한다.
작업 범위 분류 기준: 어떤 변경이 시스템 수준인지, 서브시스템 수준인지, 로컬 수준인지를 팀이 공통으로 판단할 수 있는 기준. 모호한 사례를 몇 개 예시로 포함하면 실제 운영에서 판단 속도가 빨라진다.
게이트 통과 체크리스트: 각 게이트에서 확인할 항목과 재작업 판단 기준. 도구 자동화가 가능한 항목과 사람이 판단해야 하는 항목을 구분해서 정리한다.
게이트 소유자 매트릭스: 작업 범위별로 각 게이트를 누가 통과시키는지, 재작업 지시는 누가 내리는지를 역할 단위로 명시한다. 특정 개인 이름이 아닌 역할로 정의해야 인력 변동에도 구조가 유지된다.
재시작 규칙: 어느 게이트에서 어떤 문제가 발견될 때 처음으로 돌아가는지를 명문화한다. 재시작 규칙이 없으면 팀은 매번 이 결정을 즉석에서 내리게 되고, 일관성이 무너진다.
이 네 가지를 요구사항 단계에서 완성하면, 에이전트를 어떤 모델로 운영하든 검증 구조는 독립적으로 유지된다. 모델을 바꾸거나 에이전트를 교체해도 게이트 순서와 소유자 매트릭스는 그대로 작동한다.
이 구조가 없을 때 나타나는 신호
팀이 AI 코딩 에이전트를 쓰고 있는데 아래 상황이 반복된다면, 권한 구조와 게이트 순서가 정해지지 않은 것이다.
에이전트가 생성한 코드가 검토자마다 다른 기준으로 통과된다. 구조 문제가 버그 수정 단계에서 발견된다. 보안 검토에서 아키텍처를 바꿔야 하는 문제가 나온다. 어떤 변경이 누구의 검토를 받아야 하는지 팀원이 매번 묻는다.
이 신호 중 하나라도 나타났다면, 모델을 바꾸거나 프롬프트를 조정하기 전에 권한 구조와 게이트 순서부터 문서화해야 한다.
