에이전트가 셋이면 대답도 셋이어야 할까 — 다중 에이전트 팀의 말하기 규칙

KoalStudio에서는 여러 에이전트가 같은 작업면을 봐요. 한쪽에서는 AsterDuck의 릴리스 기록을 확인하고, 다른 쪽에서는 Called Up의 재실행 조건을 검토하고, 또 다른 쪽에서는 Project Whisper의 QA 근거를 정리해요. 서비스마다 정본과 검증법은 다르지만 요청과 결과가 오가는 곳은 겹칠 수 있어요.

여기서 곤란한 건 에이전트가 일을 못 하는 순간보다 모두가 할 수 있는 순간이에요. 요청 하나를 본 에이전트들이 저마다 답하면, 내용이 비슷해도 사람은 어느 답이 최종본인지 다시 판단해야 해요. 한 답에는 최신 문서가 반영됐고 다른 답에는 오래된 맥락이 섞일 수도 있어요. “확인했어요”, “저도 동의해요” 같은 말이 연달아 붙으면 실제 결과와 블로커는 위로 밀려나요.

이번 시리즈를 준비하면서 우리는 이 문제를 모델 성능으로 풀지 않기로 했어요. 누가 더 잘 답하는지 경쟁시키는 대신, 한 요청에서 누가 답을 회수하고 누가 차이만 검토하며 누가 지켜볼지를 먼저 정했어요. 담당자(owner), 검토자(reviewer), 관찰자(observer)는 KoalStudio의 오래된 고정 직책이 아니에요. 이 시리즈의 공동 작업을 위해 제안했고, 실제 운영에 채택한 임시 역할이에요. 다음 요청에서는 같은 에이전트가 다른 자리에 설 수 있어요.

한 요청에는 답변 책임자가 한 명 있어요

요청자는 먼저 담당 에이전트를 정해요. 담당자는 요청을 해석하고 필요한 자료를 모은 뒤, 검토 의견까지 받아 하나의 결과로 돌려줘요. 다른 에이전트에게 사실 확인이나 위험 검토를 맡길 수 있지만 최종 답변을 다시 묶는 책임은 넘기지 않아요.

이 구분은 서비스 작업이 한곳에서 움직일 때 특히 유용해요. 예를 들어 Called Up의 재현 조건을 정리하는 요청에 AsterDuck 릴리스 경험과 Project Whisper QA 맥락을 아는 에이전트가 함께 참여할 수 있어요. 그렇다고 세 에이전트가 각자 완성본을 올릴 필요는 없어요. 담당자는 필요한 관점만 요청하고, 받은 차이를 원래 답에 반영해요. 덕분에 세 서비스의 일이 같은 작업면에서 이어져도 답변끼리 부딪히지 않아요.

검토자는 두 번째 완성본을 쓰는 사람이 아니에요. 담당자의 결과에서 빠진 사실, 정본과의 충돌, 외부 공개 위험, 다음 단계를 막는 문제를 찾아요. 문제가 없다면 같은 내용을 바꿔 말하지 않아요. 승인 기록이 필요한 단계라면 정해진 표시를 남기고, 그렇지 않으면 리액션이나 침묵으로 충분해요.

관찰자는 맥락을 따라가되 기본적으로 답하지 않아요. 다만 담당자가 놓친 치명적 위험이 있거나, 관찰자만 가진 새 정보가 결론을 바꾸거나, 직접 인계를 요청받았다면 끼어들어요. 이때도 전체 답을 새로 쓰지 않고 달라지는 부분만 알려줘요. 침묵은 참여하지 않았다는 뜻이 아니라 현재 답변 책임을 침범하지 않았다는 뜻에 가까워요.

답변, 검토, 침묵을 고르는 표

역할 설명을 길게 외우는 대신 실제 메시지를 볼 때는 아래 표를 사용해요. 이 글의 중심 산출물도 이 판단표예요.

상황	담당 에이전트	검토자	관찰자
새 요청이 직접 배정됨	요청을 인수하고 결과를 답해요	요청받기 전에는 기다려요	기다려요
시작 조건이 부족함	필요한 조건을 한 번에 물어요	담당자가 요청한 항목만 확인해요	기다려요
초안이나 작업 결과가 올라옴	검토 범위와 종료 조건을 알려요	오류·충돌·위험만 답해요	새 사실이 없으면 기다려요
검토 결과에 문제가 없음	결과를 최종본으로 회수해요	리액션 또는 정해진 승인 표시를 남겨요	기다려요
새 사실이 결론을 바꿈	답에 반영하고 변경점을 밝혀요	달라지는 부분과 근거만 전해요	본인만 아는 사실일 때만 알려줘요
블로커가 생김	질문과 선택지를 정리해요	요청받은 선택지의 위험을 봐요	담당 요청이 없으면 기다려요
단순 확인·감사 메시지	다음 행동이 달라질 때만 답해요	보통 답하지 않아요	답하지 않아요
게시·삭제·배포 같은 외부 행동 직전	요청자에게 승인 근거를 올려요	필요한 검토 게이트만 수행해요	답하지 않아요

표를 실제로 쓰려면 요청을 올릴 때 네 가지를 함께 적어두는 편이 좋아요. 무엇을 끝낼지, 담당자가 누구인지, 어떤 검토가 필요한지, 어디까지 가면 닫을지를 적어요. Called Up의 재실행 근거를 확인하는 일이라면 담당자는 결과를 모으고, 검토자는 입력과 결과가 정본에 맞는지만 봐요. 외부 게시가 범위에 없다면 검토가 끝난 뒤 초안을 게시하는 행동까지 이어가지 않아요. 요청의 종료 지점이 보여야 에이전트도 다음 일을 추측해 덧붙이지 않아요.

상태 보고는 예외적으로 필요할 때가 있어요. 오래 걸리는 작업에서 요청자가 기다려야 하는지, 다른 일을 먼저 진행해도 되는지 달라진다면 짧은 중간 보고가 다음 행동을 바꿔요. 반대로 몇 분마다 같은 진행률을 쓰거나, 검토자가 담당자의 상태 보고를 다시 확인해 주는 건 도움이 되지 않아요. 우리는 상태 메시지에도 예상 종료 시점, 새 블로커, 요청자에게 필요한 결정 중 하나가 있을 때만 턴을 쓰기로 했어요.

이 구분 덕분에 한 작업면에 서로 다른 속도의 일이 놓여도 대화가 덜 꼬여요. AsterDuck 릴리스 확인이 외부 상태를 기다리는 동안 Called Up의 문서 검토를 이어갈 수 있고, Project Whisper의 QA에서 새 위험이 나오면 그 차이만 바로 전달할 수 있어요. 모든 참여자가 모든 진행 상황에 답하지 않아도, 멈춘 일과 움직이는 일을 구분할 수 있어요.

판단 기준은 말의 양이 아니라 다음 행동이 달라지는지예요. 결과, 새 정보, 이견, 블로커 가운데 하나가 생겼다면 텍스트로 남겨요. 아무것도 달라지지 않는다면 리액션이나 침묵이 더 정확해요.

이 표는 에이전트를 무조건 조용하게 만들려는 규칙도 아니에요. 검토자가 실제 오류를 발견했는데 담당자만 말할 수 있다는 이유로 묻어두면 실패한 계약이에요. 반대로 모두가 안전을 이유로 전체 답변을 복제해도 실패예요. 발언권보다 중요한 건 발언의 범위예요. 담당자는 결과 전체를, 검토자와 관찰자는 결론을 바꾸는 차이를 맡아요.

이름이 보이는 것과 요청을 받는 것은 달라요

여러 에이전트가 같은 메시지를 읽을 때는 자연어 속 등장 인물과 요청의 수신자를 구분해야 해요. “검토자가 작성한 기록을 담당 에이전트가 정리해 주세요”에서 검토자는 작업의 소재이고, 담당 에이전트가 수신자예요. 반면 “검토자, 이 기록의 날짜를 확인해 주세요”라면 검토자가 새 요청을 받은 거예요.

그래서 이름이나 역할명이 문장에 들어갔다는 사실만으로 응답을 시작하지 않아요. 직접 지목과 요청 동사가 함께 있거나, 담당자가 검토 범위를 넘겼거나, 기존 결론을 바꾸는 정보를 가진 경우에만 턴을 열어요. 역할이 불분명하고 중복 답변 가능성이 크다면 각자 해석해 답하기보다 요청자가 담당자를 먼저 정해요.

메신저의 멘션 기능만으로는 이 문제를 다 해결하기 어려워요. 멘션은 알림이고, 역할은 책임 범위예요. 전체 알림이 필요해 모두를 불렀더라도 담당자가 정해져 있다면 나머지는 자동으로 공동 답변자가 되지 않아요. 시스템 프롬프트나 라우팅 규칙에도 “문장에 등장함”과 “업무를 배정받음”을 별도 조건으로 두는 편이 안전해요.

여러 관점은 살리고, 공개되는 답은 하나로 모아요

담당자 한 명만 생각하게 만들면 다중 에이전트를 쓰는 이유가 줄어요. 그래서 담당자는 검토의 종류와 종료 조건을 먼저 좁혀요. “모두 의견 주세요”보다 “현재 정본과 다른 사실, 공개하면 안 되는 정보만 확인해 주세요”가 낫고, Project Whisper QA라면 “테스트 통과 여부를 되풀이하지 말고 플레이 진행을 막는 위험만 봐 주세요”처럼 범위를 닫을 수 있어요.

검토가 끝나면 담당자가 차이를 반영해 한 번만 답해요. 요청자는 그 답을 보고 방향, 공개 범위, 외부 실행 여부를 결정해요. 게시·삭제·배포처럼 되돌리기 어렵거나 외부 상태를 바꾸는 행동은 이 말하기 계약만으로 통과시키지 않아요. 단일 답변은 책임 소재를 분명하게 만들지만, 사람의 승인까지 대신하지는 않아요.

이 운영 모델을 시리즈에 적용한 뒤에는 작업면을 읽는 법도 단순해졌어요. 답변 하나가 보이면 담당자의 결과이고, 그 아래 붙은 말은 결과를 바꾸는 차이여야 해요. 같은 결론을 여러 번 비교하느라 AsterDuck, Called Up, Project Whisper의 다음 작업이 밀리지 않아요. 어느 서비스가 더 중요한지를 정하는 규칙이 아니라, 서로 다른 서비스의 일이 같은 대화 안에서 계속 움직이게 하는 통신 규칙인 셈이에요.

병렬 작업의 충돌을 줄이는 방법은 회의 없이 병렬로 일하는 구조에서, 결과를 한곳에 남기는 방법은 결과를 남기는 협업 구조에서 더 자세히 다뤄요. 이번 계약이 맡는 범위는 그보다 좁아요. 한 요청의 답변 책임자를 정하고, 검토는 차이만 남기며, 나머지는 다음 턴이 필요할 때까지 기다리는 것. 그 정도가 여러 에이전트가 한 작업면을 함께 쓰기 위한 출발점이었어요.