에이전트는 왜 한 턴 만에 멈추나

같은 조건인데 실행 길이가 갈린다

자율 실행 에이전트를 업무에 붙이면 편차가 먼저 눈에 띕니다. 어떤 세션은 지시 하나로 파일을 뒤지고 고치고 검증까지 하고 돌아오는데, 어떤 세션은 답 한 줄 하고 다음 지시를 기다립니다. 모델도 같고 도구 권한도 같습니다. 같은 방식으로 테스트 스위트의 에러 1,300건을 되짚은 기록은 1,300개의 에러는 버그가 아니었다에 있습니다.

이럴 때 가장 먼저 드는 의심은 지시가 부실해서라는 것입니다. 저희도 그렇게 봤습니다. 다만 이건 감으로 답할 문제가 아니라 세어 볼 수 있는 문제였습니다.

무엇을 쟀나

지표는 run length 로 잡았습니다. 사람이 한 번 말한 뒤 다음에 말하기까지 에이전트가 실행한 도구 호출 수입니다. 길수록 좋은 실행이라는 뜻은 아닙니다 — 232번을 쓰고 헤맸을 수도 있습니다. 이 지표가 재는 것은 품질이 아니라 중간에 멈출 이유가 남아 있었는가입니다.

지시문 쪽은 다섯 축으로 판정했습니다. 각 축은 에이전트가 멈추는 이유 하나씩에 대응합니다.

관찰은 맞았다

세션의 첫 지시만 놓고 보면 격차가 큽니다. 축이 하나도 없는 지시는 도구 호출 중앙값이 1.0이고, 하나라도 있으면 19.0입니다.

그런데 진단은 왜 틀렸나

“지시가 부실해서 단발로 끝난다”가 맞으려면 대화 중간에도 같은 격차가 나와야 합니다. 나오지 않았습니다. 판정을 통과한 발화의 중앙값이 4.0, 부족한 발화가 3.0으로 거의 붙습니다.

자율 실행이 가장 길었던 상위 20턴을 열어 보면 이유가 보입니다. 그중 절반이 11~21자짜리였습니다.

“승인할테니 나머지 이어서 해” — 15자, 도구 192회 “다음 큐 이어서 진행해” — 12자, 도구 103회

대화 중간에는 할 일 목록이 이미 대화 안에 있습니다. 그래서 지시문이 결정 변수가 아닙니다. 에이전트가 손을 놓아 사람이 재촉해야 했던 경우도 드물었습니다 — 도구를 하나도 안 쓰고 끝난 턴 522건 중 직후에 재촉이 붙은 것은 15건, 2.9%였고 그 522건은 대부분 애초에 질문이었습니다.

그러니까 손실은 대화 전체에 퍼져 있지 않고 세션 첫 턴 하나에 몰려 있습니다. 거기서만 맥락이 비어 있어서 지시문이 유일한 공급원이 되기 때문입니다.

임계도 틀렸다

설계할 때는 “세 축은 있어야 자율 실행이 붙는다”고 가정했습니다. 전수 재판정에서 반증됐습니다. 점프는 세 축이 아니라 0축과 1축 사이에 있고, 3축 이상은 표본이 사실상 없었습니다(2건).

즉 “이어서”, “다음 것 진행해” 같은 포인터 하나면 충분합니다. 11자짜리가 190번을 내는 이유가 이것입니다.

그래서 사람을 훈련하지 않기로 했다

자연스러운 처방은 “지시를 길게 쓰도록 훈련하자”입니다. 두 번 검토하고 두 번 기각했습니다.

• 첫 지시의 88%가 축 0/5입니다. 사람의 타이핑 습관을 바꿔서 닫을 크기가 아닙니다.
• 같은 구조를 이미 한 번 겪었습니다. 한국어 번역체를 통제하려고 생성 지시에 “자연스럽게 써라”를 넣었을 때는 효과가 없었고, 생성 후 별도 다듬기 단계를 붙였을 때만 43%에서 25%로 떨어졌습니다.
• 이전에 만들어 둔 지시문 코칭 기능이 있었는데, 전체 기록을 뒤져 보니 발동한 적이 3회뿐이었습니다. 모델의 자율 판단에 맡긴 장치는 실질적으로 꺼져 있었습니다.

그래서 이번에는 모델 판단이 아니라 훅으로 배선했습니다. 세션 첫 작업 지시에서만, 세션당 한 번만 발동합니다. 그리고 사람에게 되묻지 않습니다 — 짧은 지시는 결함이 아니라 그 시점에 맥락이 비어 있다는 사실의 반영이고, 빈 곳을 채우는 것은 에이전트의 일이기 때문입니다.

배선 다음 날 오탐이 났다

“조금 더 쉽게 설명해줘”를 훅이 작업 지시로 읽고 발동했습니다. 설명 요청을 걸러내는 패턴이 문장 첫머리에만 걸려 있어서, 앞에 수식어가 붙으면 빠져나갔습니다.

짧은 메타 발화를 위치와 무관하게 잡는 규칙을 추가했습니다. 다만 “정리해줘”는 작업 동사 목록에서 일부러 뺐습니다 — “다시 정리해줘”(설명)와 “파일 정리해줘”(작업)를 어휘로 가를 방법이 없어서 놓치는 쪽을 택했습니다. 장치가 한 번 잘못 뜨면 그 다음부터 무시당하고, 그게 바로 앞의 코칭 기능이 3회에서 죽은 경로입니다.

부작용은 따로 왔다

“목록 맨 위부터 집어라”는 세션이 하나일 때 장점이고 여럿일 때 충돌 장치입니다. 병렬로 띄운 세션들이 같은 문서를 보고 같은 작업을 동시에 시작했습니다.

막혀 있던 것은 문서 쪽뿐이었습니다. 같은 파일을 동시에 쓰는 것은 막았는데 같은 일을 동시에 하는 것은 아무도 보고 있지 않았습니다. 점유 기록을 만들어 붙였는데 그것만으로도 구멍이 남았습니다 — 아무도 점유를 선언하지 않으면 통째로 무력화됩니다. 기록이 재는 것은 “누가 잡았나”인데 필요한 것은 “같은 목록에 몇 세션이 붙어 있나”였습니다.

그래서 세션 등록 계층을 하나 더 뒀습니다. 점유가 0건이어도 동료 세션이 있으면 “0건은 아무도 일 안 한다가 아니라 아무도 안 잡았다는 뜻”이라고 띄웁니다. 단독 세션에서는 아무것도 띄우지 않습니다.

안 잡기로 한 것

장치를 신뢰하려면 사각지대를 알아야 합니다. 어디까지 자동으로 두고 어디부터 사람이 잡을지는 상담에서 업무 흐름을 놓고 정합니다.

• 긴 실행이 좋은 실행인지는 재지 않습니다. run length 는 대리 지표입니다.
• 대화 중간의 지시는 발동하지 않습니다. 효과가 없고(4.0 대 3.0), 효과 없는 발동은 잔소리가 되어 장치를 죽입니다.
• “적절히”, “잘” 같은 어휘 수준의 모호함은 정상 사용과 기계로 가를 수 없어 버렸습니다.

정리

관찰은 맞고 진단은 틀릴 수 있습니다. 여기서는 “잘 짜인 첫 지시로 시작하면 오래 간다”는 관찰이 사실이었지만, “사람이 지시를 못 줘서 짧게 끝난다”는 진단은 대화 중간에서 성립하지 않았습니다. 그 차이가 처방을 사람 훈련에서 장치 배선으로 옮겼습니다.

설계가 측정 때문에 두 번 바뀌었습니다. 임계를 세 축에서 한 축으로 내린 것, 그리고 발동 지점을 대화 전체에서 세션 첫 턴으로 좁힌 것. 둘 다 직관이 먼저 있었고 숫자가 뒤집었습니다. 업무자동화를 도입할 때 저희가 계약서보다 먼저 맞추려는 것이 이 부분입니다 — 무엇을 재고 무엇을 안 재는지.