#사용자가 중간에 딴 질문을 끼워넣으면 Agent는 왜 주작업을 놓치는가

← 전체 목차 · 이전: 멀티턴 대화, 왜 갈수록 느려지고 비싸지는가 · 다음: 멀티 Agent Handoff: 왜 완전한 이력을 전부 넘기면 안 되는가

충전 Agent가 잔액 조회 → 충전 등급 확인까지 진행한 상태에서 사용자가 "겸사겸사 지난달 청구서도 봐줘"라고 끼어들자, Agent는 주작업을 통째로 내려놓고 청구서 조회로 넘어갔다. 청구서를 다 본 뒤엔 잔액 조회 API를 두 번 중복 호출했고, 사용자는 6~7분을 기다리고도 충전 결과를 못 받았다. 사후 점검에서 모델 추론도 정상, 도구 인터페이스도 전부 정상 응답이었다 — 즉 컴포넌트 단위 점검은 전부 파랗지만 사업은 실패한 "전부 정상인데 실패"한 사고다.

#원인은 "기억력"이 아니라 "상태를 공학적으로 위탁하지 않았다"는 것

"컨텍스트를 잊었나 보다"는 현상 진단이지 근본 원인이 아니다. 진짜 질문은: 모델의 기억에 의존하지 않는 상태 진실 소스가 시스템에 있는가다. 모델이 "기억해서" 해결할 수 있는 문제는 애초에 모델에게 기억을 맡기면 안 된다.

#1층 — 작업 분급: 모든 작업이 상태머신을 쓸 자격은 없다

충전 = 검증 → 차감 → 입금   (각 노드에 명확한 표식, 결과 영속화)

여기서 사고 근본 원인이 소거된다: 충전이 상태머신을 탄다면, 사용자가 끼어들어도 주작업은 "검증 완료, 차감 대기" 노드에 그대로 머물러 있지 모델의 한 번 추론으로 증발하지 않는다. 판단 기준은 작업의 복잡도가 아니라 일관성 요구 수준이다 — 잡담에 상태머신을 씌우는 것도, 충전에 안 씌우는 것도 둘 다 사고다.

#2층 — 실행 링크 보완: 중복 방지 → 중단 방지 → 선점 방지

1. 도구 호출 멱등 검증: 모든 도구 요청에 고유 작업 ID를 바인딩. 중복 호출은 캐시된 결과를 즉시 반환 — 잔액 API 중복 호출 사고에 직접 대응.
2. 업무 작업 브레이크포인트 재개: 실행 시간을 모니터링, 타임아웃 시 자동 일시정지 + 현장 상태 보존. 사용자 재시도 시 처음부터가 아니라 끊긴 지점부터 이어감 — 6~7분 공회전 사고에 직접 대응.
3. 명령 우선순위 차단: 모델 추론 이전에 규칙 판정 레이어를 하나 더 둠. 핵심 업무 명령이 보충 명령보다 우선순위가 높고, 부가 명령은 현재 작업의 보충 정보로만 취급되어 주작업 흐름을 끊지 못함 — "겸사겸사 청구서도 봐줘"가 충전을 밀어낸 사고에 직접 대응.

세 번째 항목의 위치가 핵심이다: 규칙 판정은 모델 추론 전에 일어나지, 모델 출력을 사후에 고치는 게 아니다.

#3층 — 아키텍처 최적화: 장시간 실행에서 서서히 쌓이는 오차 압축

• 도구 결과 사전 요약: 도구가 반환한 원시 장문 데이터를 정제 전처리한 뒤 모델에 넣는다 — 컨텍스트 비대는 토큰 비용만이 아니라 정보 누락을 직접 유발한다.
• 장기 기억 조각화 관리: 긴 대화는 최근 3라운드 핵심 교환 + 전역 작업 상태만 유지한다. "최근 N라운드"와 "전역 작업 상태"는 반드시 함께 있어야 한다 — 세부는 잘려도 되지만 작업 상태는 잘리면 안 된다.
• 핵심 시나리오 하드 규칙 방어: 결제·개설 등 고위험 업무에는 규칙 검증을 추가. Agent 출력 지시가 업무 흐름에 안 맞으면 직접 가로채 수정하고, 모델의 자유 발휘에 전적으로 맡기지 않는다.

#핵심 통찰

1. Agent 사고의 전형적 형태는 "전부 파란데 실패한 것"이다 — 모델 추론도 도구 응답도 정상인데 업무는 안 됐다. 컴포넌트 헬스체크만으로는 이런 사고를 못 잡는다. "작업이 종단 상태까지 진행됐는가" 자체를 1급 모니터링 대상으로 삼아야 한다.
2. "컨텍스트를 잊었다"는 현상이지 근본 원인이 아니다 — 책임을 모델의 기억력으로 돌리는 순간 답이 얕아진다. 진짜 질문은 모델 기억에 의존하지 않는 상태 진실 소스가 있는가다. 모델이 "기억해서" 풀 수 있는 문제는 애초에 모델에게 맡기면 안 된다.
3. 모든 작업이 상태머신을 탈 자격은 없다 — 잡담에 상태머신을 씌우면 과설계, 충전에 안 씌우면 사고다. 판단 기준은 작업 복잡도가 아니라 일관성 요구 수준이다.
4. 멱등 키는 "호출"이 아니라 "작업"에 묶여야 한다 — "고유 작업 ID"를 도구 요청에 바인딩한다는 건 멱등 키의 유효 범위가 업무 생명주기라는 뜻이다. 같은 작업 안의 중복 조회는 캐시로 맞고, 호출자가 알아서 중복 제거하는 방식이 아니다.
5. 규칙 레이어는 추론 이전으로 끌어와야 한다 — 명령 우선순위 차단은 "모델 추론 전"에, 하드 규칙 방어는 "모델 출력 이후"에 작동한다. 모델을 앞뒤로 끼워 두 관문 사이에서만 자유롭게 놔둔다는 것은 LLM을 신뢰할 수 없는 컴포넌트로 취급하고 시스템을 설계한다는 뜻이다.
6. 컨텍스트 관리는 "압축 + 앵커"이지 단순 절단이 아니다 — 최근 몇 라운드만 남기고 전역 작업 상태를 함께 안 지니면, 절단 자체가 "초기 지시 망각"을 인위적으로 만들어낸다.
7. 사용자의 끼어들기는 이상 입력이 아니라 상시 조건이다 — "겸사겸사 …"라는 한마디가 사고의 방아쇠였다. 실사용자를 상대하는 모든 Agent는 명령이 중간에 끼어든다는 걸 전제해야 하며, 주작업의 끼어들기 내성은 고급 기능이 아니라 기본 능력이다.
8. 제어 가능성과 지능화는 충돌할 수 있고, 충돌하면 제어 가능성이 우선한다 — "모델의 자유 발휘에 전적으로 맡기지 않는다"는 효과 지표에서는 감점 요인이지만 업무 안정성에서는 필수다.

#엔지니어링 실전 Tips

• 상태 진실 소스를 단일화할 것. 매 라운드 추론 전 현재 상태 노드를 먼저 읽게 하고, 모델이 대화 이력에서 진행 상황을 "회상"하게 두지 말 것. 모델은 다음 스텝만 결정하고 진행 상황은 보관하지 않는다.
• 캐시가 곧 멱등이다. 분산 락 수준의 복잡도까지 갈 필요 없이, 작업 ID + 결과 캐시만으로 반복 호출 사고 대부분을 막을 수 있다.
• 타임아웃엔 실패보다 일시정지가 우선. 자동 일시정지 + 현장 상태 보존이 브레이크포인트 재개의 전제이며, "몇 분을 기다렸다" 류의 체험 문제에 대한 정답이다.
• 주명령과 보조명령을 구분할 것. 규칙 레이어에서 우선순위 태그를 매겨 보조 명령을 "현재 작업의 보충 정보"로 강등시킨다. 모델의 판단에 맡길 문제가 아니라 분류 문제다.
• 장문 데이터는 컨텍스트에 그대로 넣지 말 것. 도구가 반환한 원시 장문은 정제 전처리 후 투입. 컨텍스트 비대는 토큰 비용만이 아니라 정보 누락을 직접 유발한다.
• 절단에는 반드시 앵커를 동반할 것. 최근 N라운드만 남기면서 전역 작업 상태를 함께 안 지니면, 절단 자체가 초기 지시 망각의 원인이 된다.
• 고위험 업무는 전권 위임하지 말 것. 결제·개설 같은 시나리오는 규칙 검증을 두고, 흐름에 안 맞는 지시는 차단·수정한다.
• 보조 명령이 언제 처리되는지도 설계 대상이다. "주작업 완료 후 보충 실행"인지 "그대로 버리고 사용자에게 통보"인지를 미리 정해두지 않으면, 차단 이후 사용자 경험이 애매해진다.