AI 에이전트 작성과 검토 컨텍스트를 분리하는 아키텍처

검토가 작성자의 전제를 그대로 물려받을 때

웹 ChatGPT를 읽기 전용 MCP로 연결해 설계와 코드 검토를 맡기고, 실제 편집은 로컬 에이전트가 처리하는 구성이 소개되고 있다. 이는 하나의 컨텍스트가 작성과 검토를 모두 맡는 방식에서 벗어나, 두 패스를 각기 다른 권한과 맥락에 두려는 흐름이다.

동일한 맥락에서 결과물을 다시 확인하면 작성 과정에서 세운 가정이 검토의 기준으로 이어지기 쉽다. 결국 잘못된 전제가 의심받지 못한 채 승인된 결과가 배포될 수 있다. 컨텍스트 분리는 역할을 보기 좋게 나누는 문제가 아니라, 오류를 발견하기 위한 전제다.

검토 체계에는 다음 요소가 함께 필요하다.

작성자는 편집과 실행 권한을 갖고, 검토자는 조회 권한만 갖도록 도구 수준에서 분리한다.
검토자에게는 변경 diff, 관련 인터페이스, 적용 기준, 수용 조건을 우선 제공하고 전체 저장소는 요청 시 조회하게 한다.
정확성, 경계 조건, 인터페이스 계약, 오류 처리, 성능, 보안처럼 검토 축을 고정한다.
작성 측은 각 지적을 수용·반박·보류 중 하나로 처리하고 그 사유를 남긴다.
수정 이후 다시 검토해야 하는 조건과 의견 충돌의 판정 규칙을 사전에 정한다.
지적 내용, 처리 결과, 사유, 사용한 모델과 기준 버전을 보존한다.

작성과 검토 사이에 두는 경계

역할 이름만 다르게 부여해서는 권한 분리가 되지 않는다. 작성 역할에 편집과 실행 권한을 부여했다면, 검토 역할에는 조회 계열 도구만 노출해야 한다. 쓰기 도구를 제공한 뒤 사용하지 말라고 지시하는 방식은 통제가 아니다.

검토 입력도 경계의 일부다. 전체 저장소를 그대로 넘기면 변경 자체보다 주변 맥락에 주의가 분산될 수 있다. 변경 diff와 연결된 인터페이스, 기준, 수용 조건을 기본 자료로 구성하고, 필요한 경우에만 저장소 범위를 넓히는 편이 낫다.

검토 기준이 없는 요청은 취향에 가까운 스타일 지적으로 흐르기 쉽다. 무엇을 확인할지 규격으로 정해 두면 검토자는 결과물의 정확성뿐 아니라 경계 조건, 계약 위반, 오류 처리, 성능과 보안까지 같은 기준에서 판단할 수 있다.

⤢✕

지적을 반영하고 다시 검증하는 흐름

검토 지적을 자동으로 반영하면 안 된다. 검토 자체가 틀릴 수 있으며, 반박의 근거도 이후 판단에 활용할 수 있는 기록이다. 작성 측이 수용·반박·보류를 결정하게 하고, 보류에는 사유와 기한을 남겨야 한다. 기한 없는 보류가 쌓이면 검토는 통과 의례가 된다.

재검토 역시 한 번의 확인으로 끝내지 않는다. 수용된 지적이 일정 수 이상이거나 인터페이스가 변경되면 검토를 다시 수행하도록 조건을 둔다. 수정이 다른 결함을 만들어낼 수 있기 때문이다.

작성자와 검토자가 결론을 달리할 때는 판정 주체와 근거의 우선순위가 필요하다. 사안마다 조율하면 결국 목소리가 큰 쪽의 판단으로 끝날 수 있다. 지적, 처리 결과, 사유, 검토에 사용한 모델과 기준 버전을 함께 남기면 다음 사고에서 왜 특정 결정을 내렸는지 추적할 수 있다.

위험도에 맞춰 적용 범위를 정한다

되돌리기 어려운 변경, 인터페이스 변경, 보안 관련 변경부터 분리 검토를 적용할 수 있다. 모든 수정에 두 개의 패스를 강제하면 사소한 변경까지 검토 왕복을 거치며 처리량이 떨어질 수 있다.

검토자용 조회 도구 집합을 먼저 정하고, 쓰기 권한을 제외한 별도 자격을 발급한다. 기존 자격을 재사용하는 방식보다 새 자격을 발급하는 편이 권한 축소를 명확히 한다.

체크리스트는 일반적인 리뷰 가이드를 그대로 옮기기보다 조직에서 실제로 발생했던 결함 유형을 바탕으로 구성한다. 검토를 통과한 뒤에도 발생한 결함을 모으면, 현재 기준이 놓치고 있는 영역을 확인할 수 있다. 검토 적용률, 지적 수용률, 검토 통과 후 결함률, 평균 검토 소요는 운영 지표로 관리할 수 있다.

분리 검토와 자기 점검의 차이

구분	분리 검토 패스	동일 컨텍스트 자기 점검
결함 발견율	높음	낮음
처리 지연	있음	없음
전제 승계	없음	있음
운영 부담	큼	없음
근거 기록	남음	희박
토큰 원가	큼	작음

분리 검토는 작성 단계의 전제를 그대로 이어받지 않으므로 잘못된 가정까지 의심할 수 있다. 지적과 처리 사유가 축적되고, 권한이 나뉘어 검토자가 임의로 수정하는 일을 막는다. 반면 검토 패스가 추가되므로 배포까지 시간이 늘고, 검토 컨텍스트 구성과 자료 전달에도 운영 부담과 추가 호출 원가가 생긴다.

동일 컨텍스트의 자기 점검은 즉시 수행할 수 있고 이미 확보한 맥락을 활용하므로 자료 준비가 필요 없으며 원가도 작다. 그러나 작성 시의 가정이 검증 기준으로 남아 근본적인 오류를 지나칠 수 있고, 자기 승인 결과가 검토를 거친 것처럼 남을 수 있다. 위험 등급이 높은 변경은 분리 검토로 보내고 나머지는 자기 점검 후 표본 검토하는 방식으로 발견율과 처리량을 조절할 수 있다.

읽기 전용 권한은 지적과 수정의 결정을 분리하고 잘못된 자동 수정의 유입을 막으며 사고 시 책임 소재를 분명히 한다. 명백한 오타도 작성 측을 거쳐야 하므로 왕복과 처리 부담이 생기는 것이 단점이다. 형식이나 오타 수준의 변경에만 제한된 수정 권한을 허용하는 경계가 속도와 안전을 함께 고려하는 방식이 될 수 있다.

외부 모델을 검토에 사용하면 학습 데이터와 판단 경향의 차이로 다른 결함을 지적할 수 있고, 한 모델의 체계적 약점을 상쇄하며 벤더 장애에도 검토 경로를 남길 수 있다. 대신 연동과 자격 관리가 늘고 외부로 전달되는 자료의 데이터 경계를 검토해야 하며 지적 형식의 차이도 처리 부담이 된다. 동일 모델의 별도 세션은 연동 없이 데이터 경계를 유지하고 지적 형식을 일관되게 만들지만, 같은 모델의 사각지대를 물려받을 수 있다. 민감도가 낮은 변경에는 외부 모델을 사용하고 민감한 코드에는 동일 모델의 별도 세션을 쓰는 방식이 관점 다양성과 데이터 경계를 함께 다룬다.

품질과 접근 통제로 해석하는 분리 구조

작성과 검토의 분리는 개발 산출물에 대한 독립적 검증 원칙을 구현하는 방식이다. 검토 기준을 명시하는 일은 검토 항목을 표준화하는 활동에 해당한다.

지적 처리 경로와 재검토 조건은 공식 검토 절차에서 후속 조치를 관리하는 장치다. 의견 충돌 조정 규칙은 검토 결과를 판정하는 권한 체계로 볼 수 있다.

읽기 전용 연결은 최소 권한 원칙을 도구 수준에서 적용한 사례이며, 역할별 자격 분리는 직무 분리 통제에 대응한다.

에이전트 개발에서 이어질 흐름

검토 전용 읽기 연결은 에이전트 개발 구성의 표준 패턴으로 자리잡는 방향이다. 검토 기준 체크리스트는 저장소 자산으로 버전 관리되고 결함 이력과 연결되는 흐름이 나타날 수 있다.

지적 처리 사유 기록은 감사 대응 자료로 요구되는 방향이며, 작성과 검토에 서로 다른 벤더 모델을 배치하는 구성은 관점 다양성을 확보하는 수단으로 정착하는 흐름이다.

검토를 분리하는 목적은 검토 단계를 하나 더 만드는 데 있지 않다. 작성자가 만든 전제가 검토자의 전제가 되는 흐름을 끊는 데 있다. 권한 경계, 조회 전용 도구, 검토 입력 범위, 기준 목록, 지적 처리 사유, 재검토 조건이 함께 갖춰져야 하며, 보류 지적의 기한을 관리하지 않으면 검토 체계는 형식만 남는다.