AGENT / 63번째 글

에이전트끼리 일을 넘길 때 무엇을 함께 넘기는가

여럿으로 나눈 에이전트가 기대만큼 못 하는 이유는 대개 넘기는 자리에 있습니다. 대화를 통째로 넘기는 방식이 왜 나쁜지, 봉투에 무엇을 담아야 하는지, 돌려받는 쪽에 무엇이 있어야 하는지 정리합니다.

PALDYN Team2026.08.2211 MIN READ

지난 글에서 에이전트를 나눌 이유가 있는지 묻고, 나누면 문맥이 갈린다는 문제를 언급했다. 이 글은 그 자리를 다룬다. 에이전트 A가 하던 일을 B가 이어받을 때 무엇을 함께 넘기는가.

이것이 별것 아닌 것처럼 보이는데, 여럿으로 나눈 구조가 기대만큼 못 하는 이유의 대부분이 여기 있다. 하나였을 때는 앞에서 알아낸 것이 그냥 문맥에 남아 있었다. 나누는 순간 그 「그냥 남아 있음」이 사라지고, 무엇을 넘길지 누군가 정해야 하는 일이 된다. 정하지 않으면 두 극단 중 하나로 간다 — 전부 넘기거나, 너무 적게 넘기거나.

전부 넘기는 쪽의 문제

가장 쉬운 구현은 지금까지의 대화 기록을 그대로 다음 에이전트에게 붙여 주는 것이다. 코드 한 줄이면 되고 아무것도 안 빠진다.

무엇을 넘길 것인가

문제가 셋이다.

첫째, 값이 그대로 곱해진다. 3만 토큰짜리 대화를 일꾼 셋에게 각각 넘기면 9만 토큰이 입력으로 들어간다. 나눠서 얻으려던 이득이 여기서 상당 부분 사라진다.

둘째, 무엇이 중요한지 표시가 없다. 대화 기록에는 도구가 뱉은 표 전체와 중간에 틀렸다가 고친 흔적과 사용자의 곁가지 질문이 같은 무게로 들어 있다. 받는 쪽은 그 안에서 「내가 할 일」을 스스로 찾아야 하고, 그 찾기가 틀리면 엉뚱한 것을 만들어 온다.

셋째, 앞의 실수가 따라간다. A가 중간에 잘못 판단한 문장이 기록에 남아 있으면 B는 그것을 이미 확인된 사실로 읽는다. 긴 문맥의 현실에서 본 대로 모델은 긴 문맥의 중간을 고르게 보지 않으므로, 뒤에 붙은 정정보다 앞에 있는 오류가 더 강하게 남기도 한다.

반대쪽 극단도 있다. 「이 회사 조사해 줘」 한 줄만 넘기는 것이다. 값은 싸지만 B는 A가 이미 확인한 것을 다시 확인하고, A가 피하기로 한 것을 다시 시도한다.

봉투에 담는 다섯 가지

가운데를 잡는 방법은 넘기는 것의 모양을 정해 두는 것이다. 대화가 아니라 서식이라고 생각하면 된다. 다섯 칸이면 대체로 충분하다.

칸	무엇을 적는가	빠지면
해낼 것	한 문장짜리 일감. 「됐다」의 조건까지	받는 쪽이 목표를 다시 추측한다
이미 알아낸 것	확인된 사실만. 추측은 추측이라 적는다	같은 조사를 다시 한다
하면 안 되는 것	건드리지 말 것, 쓰지 말 도구, 예산 상한	이미 실패한 길로 다시 간다
돌려줄 모양	결과의 형식. 필드 이름까지	자유 서술이 돌아와 관리자가 다시 해석한다
확실하지 않은 것	넘기는 쪽이 자신 없는 자리	받는 쪽이 그것을 사실로 믿는다

넷째 칸이 특히 값을 한다. 일꾼의 출력 형식을 미리 못박아 두면 관리자가 결과를 파싱하려고 다시 모델을 부를 일이 없어진다 — 구조화 출력과 JSON 스키마로 모양 정하기가 그대로 쓰이는 자리다.

다섯째 칸은 자주 빠지는데, 넣어 두면 이상한 결과의 원인을 나중에 찾기가 훨씬 쉽다. 「매출 숫자는 확인했지만 이것이 연결 기준인지 별도 기준인지 모른다」 같은 한 줄이 그것이다.

돌아오는 쪽도 봉투다

핸드오프를 한 방향으로만 설계하면 관리자가 결과를 믿을 근거가 없다.

넘기는 봉투와 돌려받는 봉투

돌려받는 쪽에 있어야 하는 것은 넷이다.

결과 — 넘길 때 정해 둔 모양 그대로
못 한 것과 그 이유 — 다 했으면 「없음」이라고 적힌 채로
확신이 낮은 자리 — 어디를 다시 봐야 하는지
쓴 값 — 호출 수·토큰·걸린 시간

두 번째가 핵심이다. 「못 했다」가 돌아올 자리를 만들어 두지 않으면 일꾼은 못 한 것을 지어내서라도 채워 온다. 「이 다섯 개를 찾아와」라고 시켰는데 셋만 찾았을 때, 돌려줄 서식에 다섯 칸만 있으면 나머지 둘은 그럴듯한 값으로 채워진다. 빈칸을 허용하고 그 옆에 이유를 적게 하면 그 자리가 사라진다.

네 번째는 밖에서 따로 재는 것보다 봉투에 실어 걷는 편이 쉽다. 일꾼이 자기가 쓴 값을 돌려주면 관리자가 남은 예산으로 다음 일감을 정할 수 있고, LLM 비용 추적에서 본 집계와도 같은 축으로 붙는다.

사람 쪽으로 넘기는 핸드오프

에이전트끼리만 넘기는 것이 아니다. 상담 에이전트가 사람 상담원에게 넘기는 경우가 실무에서는 더 흔하고, 여기서는 서식이 더 중요해진다. 사람은 3만 토큰짜리 대화 기록을 읽지 않기 때문이다.

넘길 때 담는 것은 대체로 같지만 표현이 다르다.

왜 넘겼는가 — 「모르는 질문」인지 「권한이 없는 요청」인지 「고객이 사람을 요구」인지
고객이 원하는 것 — 한 문장
이미 시도한 것 — 안내한 내용과 고객의 반응. 같은 안내를 두 번 하는 것이 가장 나쁘다
확인된 정보 — 주문 번호·계정처럼 다시 묻지 않아도 되는 것

이 서식이 없으면 사람 쪽에서 「처음부터 다시 말씀해 주시겠어요」가 나오고, 그 한마디가 에이전트를 도입해 얻은 것을 대부분 상쇄한다. 상담 응대 서비스 만들기에서 다룬 이야기다.

넘기는 자리에서 자주 나는 사고

넘기고 끝낸다. 넘긴 뒤 일꾼이 응답하지 않는 경우를 다루지 않으면 관리자가 영원히 기다린다. 시간 상한과 「응답 없음」 경로를 둔다
되받은 결과를 검사하지 않는다. 정해 둔 모양대로 왔는지 코드로 확인한다. 모델의 출력은 형식을 지키다가도 어느 날 안 지킨다
왕복이 늘어나는 것을 안 센다. A가 B에게 넘기고 B가 다시 A에게 묻는 왕복이 세 번을 넘으면 대개 일감이 잘못 쪼개진 것이다. 횟수에 상한을 두고 넘으면 사람에게 올린다
되돌아온 것을 그대로 다시 넘긴다. 실패한 일감을 손대지 않고 재시도하면 같은 자리에서 다시 막힌다. 다시 넘길 때는 무엇이 달라졌는지 봉투에 적는다
아이디를 안 붙인다. 봉투마다 작업 아이디를 붙여 두면 어느 갈래에서 틀렸는지 한 줄로 따라갈 수 있다. 나중에 붙이려면 전부 고쳐야 한다