AI 서브 에이전트(AI Sub-agent)를 사용하면 개발과 리뷰는 얼마나 좋아질까.

이 질문에 대해 작은 실험을 몇 차례 진행했다.

결론부터 말하자면, 만능은 아니었다.

속도가 빨라진다거나, 비용이 저렴해진다거나, 항상 품질이 올라간다거나, 구현까지 안전하게 맡길 수 있다고는 말할 수 없다.

하지만 효과가 나타나기 쉬운 장면은 있었다.

그것은 바로, 고위험(High-risk) 리뷰이다.

특히 AI 에이전트 운용에서 "읽기만 했는데, 실행해도 괜찮아 보이게 만드는" 경계를 확인할 때, 관점을 분리한 리뷰는 도움이 되었다.

시도하고 싶었던 것

이번에 시도하고 싶었던 것은 서브 에이전트가 "편리해 보이는가"가 아니다.

다음과 같은 제한된 질문을 설정했다.

고위험인 '읽기 전용' 태스크에서, 관점을 분리한 복수 에이전트 리뷰가 중요한 간과(Oversight)를 줄이기 위한 확인 범위를 넓힐 수 있는가?

반대로, 처음부터 말하지 않기로 한 것도 결정했다.

• 서브 에이전트는 항상 유효하다
• 서브 에이전트가 더 빠르다
• 서브 에이전트가 더 저렴하다
• 구현 작업에도 안전하게 사용할 수 있다
• 운영 환경, 데이터베이스, 인증, 결제, 보안 관련 사항을 맡겨도 된다
• 리뷰 결과가 그대로 "병합해도 좋다", "닫아도 좋다", "공개해도 좋다"라는 허가가 된다

이 부분을 구분하지 않으면 금방 과도한 주장이 되어버린다.

이번 실험에서는 서브 에이전트를 최종 판단자로 취급하지 않았다.

어디까지나, 간과를 줄이기 위한 리뷰 담당자로서 취급했다.

효과가 있었던 것은 "권한의 오독"

가장 효과가 눈에 띄었던 것은 권한 경계(Permission boundary) 리뷰였다.

AI 에이전트 운용에서는 문서 내에서 다음과 같은 사항을 결정한다.

• 리뷰를 통해 얻은 증거를 어디까지 신뢰할 것인가
• Issue를 닫아도 되는 조건
• PR(Pull Request)을 병합해도 되는 조건
• 라벨이나 "준비 완료" 상태를 변경해도 되는 조건
• 자동화나 공개·배포를 시작해도 되는 조건

이런 문서들은 조금만 애매해도 위험하다.

예를 들어, "리뷰했다"라는 사실이 나중에 "실행해도 좋다"라는 허가로 읽힐 수 있다.

또한, "리스크를 기록했다"라고만 했는데, "리스크가 해결되었다"라고 읽힐 수도 있다.

이런 종류의 오독은 하나의 세션에서 전체를 읽기만 하면 놓치기 쉽다.

그래서 관점을 나누었다.

• 권한 경계를 보는 담당
• 증거의 취급을 보는 담당
• 자동화나 공개·배포의 경계를 보는 담당

이렇게 나누면, 동일한 위험한 허점이 여러 방향에서 보이는 경우가 있었다.

단 하나의 지적이라면 과민한 리뷰일지도 모른다.

하지만 서로 다른 관점에서 유사한 지적이 나온다면, 문서나 대상 측에 잘못 읽기 쉬운 구조가 있을 가능성이 높다.

3가지 관점으로 나누기

이번에 자주 사용한 방식은 3가지 담당 범위로 나누는 방식이었다.

예를 들어 다음과 같이 나눈다.

• 목적, 대상 범위, 인간이 판단해야 할 경계를 본다
• 증거, 검증, 되돌리기(Rollback) 방법, 측정 방법을 본다
• 리스크, 권한 없는 조작, 아직 확언할 수 없는 주장을 본다

이렇게 나누면 문서 전체를 대략 훑어보는 것만으로는 놓치기 쉬운 세부 사항을 포착하기 쉽다.

실제로 다음과 같은 논점이 나왔다.

• "승인된 절차"라는 말이 다른 승인 없이 실행해도 되는 것처럼 보인다
• 읽기 결과가 준비 완료나 쓰기 권한처럼 보인다
• "검증됨"이라고 부르는 조건이 본문과 표, 예시에서 일치하지 않는다
• 예외 처리로 분류했음에도 예외 ID가 필수 사항이 아니다
• 마스킹(Masking) 처리에 대해 누가 무엇을 확인했는지에 대한 근거가 약하다
• "CI를 구현하지 않는다"라고는 적혀 있지만, 기동·재실행·승인을 금지하는 표현이 약하다

모두 화려한 문제는 아니다.

하지만 AI 에이전트 운용에서는 이런 작은 모호함이 나중에 큰 사고로 이어진다.

중요했던 운용 규칙

서브 에이전트를 사용한다면 단순히 인원수만 늘리는 것으로는 부족하다.

이번 실험에서는 다음 규칙이 중요했다.

1. 읽기 전용 리뷰임을 명시한다

서브 에이전트의 출력은 리뷰 재료일 뿐, 최종 판단이 아니다.

"준비 완료", 라벨 변경, Issue 종료, PR 병합, 공개·배포, 기사 공개, 자동화 활성화는 별도의 인간 판단으로 한다.

이 부분을 애매하게 만들면 리뷰 결과가 멋대로 실행 권한으로 승격된다.

2. 역할을 나눈다

"리뷰해줘"라고만 요청하면 관점이 분산된다.

권한 경계, 증거, 보안, API 호환성, 되돌리기 방법, 데이터 형식, 마스킹 처리와 같이 관점을 나눈다.

서브 에이전트를 늘리는 의미는 인원수가 아니라 관점의 분리에 있다.

3. 상위 에이전트(Parent Agent)가 통합한다

서브 에이전트의 지적을 그대로 채택하지 않는다.

상위 에이전트가 중복, 근거 부족, 범위 외, 중대한 간과 등을 분류한다.

단순히 여러 출력을 모으는 것만으로는 리뷰 품질이 올라가지 않는다.

통합하지 않는 서브 에이전트 운용은 단순히 노이즈를 늘릴 뿐이다.

4. 사용하지 않을 판단을 가질 것

작은 수정, 즉시 읽을 수 있는 PR, 변경 범위가 좁은 태스크에서는 사용하지 않는다.

"서브 에이전트를 기동하지 않는다"라는 판단을 내릴 수 없는 운용은 비용 관리에서 실패한다.

초회 출력 체크에서 보인 한계

또 하나 중요했던 것은 초회 출력 체크(First output check)이다.

서브 에이전트 운용에서 두려운 점은, 최종적으로 정리된 출력만을 보고 "잘 되었다"라고 생각하게 되는 것이다.

그래서 나중에 정리된 출력뿐만 아니라, 첫 번째 출력이 데이터 형식이나 참조해도 좋은 정보의 경계를 충족했는지를 살펴보았다.

확인한 내용은 예를 들어 다음과 같다.

• JSON으로서 유효한가
• 필수 항목이 있는가
• 후보와 정답 조건의 대응이 무너지지 않았는가
• 참조해도 좋은 정보의 경계를 침범하지 않았는가
• 금지된 변경을 수행하지 않았는가
• 나중에 수정한 출력만으로 성공이라 간주하고 있지 않은가

이 체크를 도입하면 긍정적인 면뿐만 아니라 깨지기 쉬운 면도 보인다.

실제로 권한 경계(Permission boundary) 리뷰에서는 강력한 후보를 선택할 수 있었던 반면, 초회 출력의 형식이 검증에서 탈락하는 케이스도 있었다.

예를 들어, 필요한 요약이 부족하거나, 판정 결과의 항목명이 예상과 어긋나는 등의 문제이다.

이는 실패이다.

하지만 나쁜 실패는 아니었다.

초회 출력을 남겨두었기 때문에, 역할별 출력 규칙과 검증 도구 사이의 괴리를 볼 수 있었다.

최종 출력만을 보고 있었다면 이 괴리는 숨겨져 있었을 것이다.

"강력한 후보를 선택했다"와 "완전히 충족했다"는 다르다

보안에 가까운 리뷰에서는 또 다른 중요한 사실이 보였다.

강력한 후보를 선택했을지라도, 숨겨진 정답 조건을 완전히 충족했다고는 할 수 없다.

예를 들어, 외부 서비스로부터 전달되는 알림의 서명 확인, 이벤트 저장, 중복 처리 방지, 재시도 처리와 같은 테마에서는 강력한 후보를 선택할 수 있었다.

하지만 서비스 제공처가 정하는 서명 대상, 허용하는 서명 방식이나 버전, 인간이 공개·보안상의 약속을 채택하는 판단의 명시가 부족하여, 일부 조건에서는 일치도가 낮았다.

이는 상당히 중요하다.

"비교하면 이쪽이 더 좋다"와 "운영 환경(Production)으로 진행해도 좋다"는 다르다.

리뷰에서 얻은 증거는 실행 허가가 아니다.

우위성이 있다고 말할 수 있는 조건

이번 실험을 통해, 나라면 다음 조건을 만족할 때만 "서브 에이전트 운용에 우위성이 있다"라고 말하겠다.

첫 번째는, 단일 리뷰로는 희박해지기 쉬운 중요 논점을 포착하는 것.

두 번째는, 포착한 지적이 실제로 유효한 것.

세 번째는, 근거 부족이나 범위 외의 지적을 너무 많이 늘리지 않는 것.

네 번째는, 읽기만 하는 리뷰(Read-only review)라는 경계를 깨뜨리지 않는 것.

다섯 번째는, 가벼운 태스크에서는 사용하지 않는 판단을 할 수 있는 것.

특히 다섯 번째가 중요하다고 생각한다.

만능화되는 순간, 운용 측면에서는 약해진다.

어디에 사용해야 하는가

현재로서 사용 가치가 있다고 생각하는 상황은 다음과 같다.

• AI 에이전트 운용 규칙을 채택하기 전
• 증거 확인 규칙이나 승인 흐름을 설계할 때
• Issue 종료, PR 병합(Merge), 라벨 변경, 준비 완료, 공개·배포의 권한 경계를 정할 때
• API의 약속 사항이나 하위 호환성(Backward compatibility) 리뷰
• 외부 서비스 알림, 토큰, 기밀 데이터, 중복 처리 방지와 같이 보안에 가까운 리뷰
• 구현 전에 놓치면 되돌리기 어려운 논점을 찾아낼 때

반대로, 사용하지 않는 것이 좋은 상황은 다음과 같다.

• 오타 수정
• 작은 문구 수정
• 변경 범위가 1개 파일이며, 인간이 즉시 읽을 수 있는 PR
• 구현 방침과 테스트 방침이 명확한 소규모 태스크
• 속도나 비용이 최우선인 작업

결론

서브 에이전트 운용은 모든 작업을 맡기기 위한 메커니즘이 아니었다.

고위험 리뷰에서 놓치는 부분을 늘리기 위한 메커니즘으로서 사용할 때 가치가 있다.

특히 읽기만 하는 리뷰와 실행 허가의 경계, 증거와 최종 판단의 경계, 자동화와 공개·배포의 경계에서는 관점을 분리한 다중 리뷰가 효과적이었다.

한편, 속도나 비용 측면의 우위는 아직 말할 수 없다.

구현이나 운영 작업으로 안전하게 확장할 수 있다고도 말할 수 없다.

따라서 현재의 채택 방침은 다음과 같다.

무거운 읽기 전용 리뷰에서는 사용한다. 가벼운 태스크나 구현 권한에는 확장하지 않는다.

이 선긋기가 현재로서는 가장 안전하고 실용적이었다.

Discussion