여러 개의 AI 코딩 에이전트(AI Coding Agent)를 역할 분담시켜 사용하고 있습니다. 판단·설계를 담당하는 역할, 구현만을 묵묵히 수행하는 역할, 그리고 또 하나, 읽기 전용(Read-only)으로 의견만 제시하는 '상담역'입니다. 이 상담역은 처음에는 '구현 전에 잠시 물어보는 보험' 정도의 위치였습니다. 실제로 운용해 보니, 이 한 번의 수고가 생각했던 것 이상으로 효과를 발휘하는 장면을 몇 번이나 마주하게 되었기에 그 기록을 남깁니다.

전제: 3가지 역할로 나눈 이유

AI 에이전트에게 구현을 맡기고 있으면, '지금의 방침이 정말 괜찮은가'를 에이전트 한 명의 내부에서만 검증하는 것은 불안하다는 느낌을 받는 순간이 있습니다. 판단한 본인이 자신의 판단을 의심하는 것은 구조적으로 어렵기 때문입니다.

그래서 판단·설계를 담당하는 에이전트와는 별개로, read-only(파일을 수정하지 않음) 상태로 의견만 돌려주는 상담역을 마련했습니다. 상담역에는 구현 능력을 부여하지 않고, '이 방침의 허점은 어디인가'를 묻는 전용 창구로 사용합니다. 구현은 다른 에이전트에게 맡기고, 판단역이 설계하고, 상담역이 반증하며, 구현역이 손을 움직이는 3단계 구성입니다.

사례 1: 증상만을 옮긴 알림을 만들 뻔한 경우

무인으로 작동하는 자동화 루프가, 건드려서는 안 되는 관리 파일 영역에 자기 수정(Self-correction)을 시도하려다 반복적으로 차단되는 문제가 며칠 사이에 여러 건 발생했습니다.

처음에 세운 가설은 '차단되었다는 사실 자체에 대한 알림이 도착하지 않았을 뿐이다'라는 것이었습니다. 이 가설 그대로 순순히 구현한다면, '차단이 발생하면 확실히 알림을 보내는 메커니즘'을 만들어 넣는 단계였을 것입니다.

그전에 상담역에게 물어보았더니, 돌아온 답변은 예상과 다른 지적이었습니다. 문제의 본질은 알림의 유무가 아니라, '애초에 무인 루프가 관리 파일 영역에 도달하여 자기 수정을 시도하는 것 자체가 스코프(Scope)를 벗어나 있다'는 설계 원칙이 결여되어 있다는 점이었습니다.

만약 상담하지 않고 첫 번째 가설 그대로 구현했다면, 증상(알아차리지 못한 채 종료됨)을 운송 수단(알림의 유무)만 바꾸어 재현하는 메커니즘을 만들 뻔했습니다. 표면상으로는 '고쳐진' 것처럼 보이지만, 근본 원인은 그대로 남게 됩니다. 실제로 채택한 것은 '구현이 관리 파일 영역에 대한 변경을 필요로 한다고 판명된 시점에서 즉시 착수하지 않고 멈춘다'라는 사전 분류 규칙이었으며, 구현에 들어가기 전 설계 단계에서 낭비를 제거할 수 있었습니다.

사례 2: 응급처치가 아닌 영구적 설계를 선택한 경우

다른 상황에서는 구현역 에이전트가 git 조작을 수행하려다 실행 환경의 안전 제약에 가로막혀 실패했습니다.

여기서 안일한 대처는 '제약을 완화하여 통과시키는 것'입니다. 작동하지 않는 것을 작동하게 만드는 것만 목적이라면 이것이 가장 빠릅니다.

하지만 이러한 임시방편적인 완화는 구현역에게 부여하는 권한을 넓히는 방향의 변경이기도 합니다. 구현역이 외부 유래 텍스트(로그나 문서의 내용)를 읽으며 작업하는 이상, 권한을 넓힐수록 악의적인 입력에 유도되어 의도하지 않은 조작을 수행하게 될 리스크도 함께 커집니다. 여기서도 상담역에게 일단 검토하게 한 결과, 'git 조작은 판단역이 직접 수행하고, 구현역은 자신의 작업 영역 내에서의 commit까지만 수행한다'는 역할 분담이 제약을 완화하지 않고도 문제를 해결할 수 있다는 것을 알게 되었습니다. 응급처치로 끝내지 않고, 영구적인 설계로서 검수한 뒤 채택하고 있습니다.

드러난 구조: 상담 비용은 구현 비용보다 먼저 지불하는 보험

두 사례에 공통적인 것은 상담역과의 왕복 비용이 구현 비용에 비해 명확하게 작다는 점입니다. 상담은 몇 분에서 몇십 분이면 끝나지만, 잘못된 전제인 채로 구현까지 진행해 버리면, 작동하는 결과물이 만들어진 후에야 비로소 재작업(Backtracking)이 발각되어 다시 시작하는 비용이 통째로 추가됩니다.

게다가 구현역 에이전트 자체가 점점 더 빠르고 저렴하게 업무를 수행할 수 있게 될수록, 이 구조는 더욱 강화됩니다. 구현이 빨라진다는 것이 '잘못된 구현을 다시 하는 비용'과 '잘못된 구현을 한 번 만들어 버리는 비용'이 모두 낮아진다는 의미는 아닙니다. 빨라진 구현역에게 잘못된 지시를 내리면, 그만큼 더 빠르게 잘못된 결과물이 만들어질 뿐입니다. 그렇다면 구현에 들어가기 전 한 번 멈춰서 물어보는 판단의 상대적 가치는, 구현이 빠르고 저렴해질수록 오히려 올라가게 됩니다.

배움

• 판단을 내린 본인이 자신의 판단을 의심하는 것은 구조적으로 어렵습니다. Read-only (읽기 전용) 상태로 반증(refutation)만을 반환하는 역할을 분리하면, 이러한 사각지대를 메울 수 있습니다.
• "증상에 대한 대처"와 "원인에 대한 대처"는 겉보기에 비슷할 수 있습니다. 상담(consultation) 단계를 거치면, 구현(implementation)에 들어가기 전에 이러한 착오를 알아차릴 수 있는 상황이 생깁니다.
• 응급 처치(제약을 완화함)와 영구적 설계(역할 분담을 재검토함)는 둘 다 "작동하게 만든다"는 점에서는 같아 보이지만, 권한이 확장되는 방식이 다릅니다. 상담 역할은 이러한 보이지 않는 차이를 드러내는 데 적합합니다.
• 구현이 빠르고 저렴해질수록, "한 번 멈춰서 묻는 것"의 상대적 가치는 낮아지는 것이 아니라 오히려 올라갑니다. 구현 비용이 낮아진다고 해서, 잘못된 방향으로 구현하는 비용이 0이 되는 것은 아니기 때문입니다.

Discussion