긴 작업에서도 흔들리지 않는 에이전트 설계

5.1 핵심 정보 보존 — 컨텍스트 윈도우를 자산으로 다루기

에이전트가 오래 작동할수록 컨텍스트 윈도우(context window, 모델이 한 번에 참고할 수 있는 정보의 총량)는 빠르게 차오릅니다. 누적 요약(progressive summarization, 이전 대화를 계속 압축하는 방식)은 토큰을 아끼지만, 요약을 반복하는 사이 확정된 사실이 뭉개지는 위험이 있습니다. 또한 모델은 긴 문맥의 가운데에 놓인 정보를 놓치기 쉬운데(lost-in-the-middle), 이 때문에 계약 조건이나 식별자 같은 확정 사실은 별도의 고정 블록으로 유지하고 문맥의 눈에 띄는 앞뒤 자리에 배치하는 편이 안전합니다. 도구 실행 결과가 토큰을 과도하게 차지하면 장황한 출력은 필요한 부분만 남기고 정리합니다.

5.2 에스컬레이션과 모호성 해소 — 언제 사람에게 넘길 것인가

상위 이관(escalation, 에이전트가 처리를 멈추고 사람 담당자에게 넘기는 것)의 트리거는 명확한 사건에 걸어야 합니다. 고객이 사람 상담을 직접 요청했을 때, 정책에 없는 상황일 때, 여러 번 시도해도 진전이 없을 때가 대표적입니다. 반대로 고객의 감정이나 모델의 자신감 점수(confidence proxy) 같은 대리 지표를 트리거로 삼는 설계는 위험합니다 — 신뢰하기 어렵고 오작동을 부릅니다. 조회 결과가 여러 건으로 갈리면 곧바로 하나를 고르지 말고, 계약번호나 주문번호 같은 식별자를 먼저 요청해 대상을 좁힙니다.

5.3 멀티에이전트 오류 전파 — 실패를 구조화해 전달하기

여러 에이전트가 협업하는 구조에서는 한 에이전트의 실패가 어떻게 전달되는지가 신뢰성을 좌우합니다. 오류는 구조화된 맥락(structured error context)으로 넘겨야 합니다 — 실패 유형, 시도한 질의, 확보한 부분 결과, 가능한 대안을 함께 담습니다. 특히 '접근 권한 실패'와 '결과가 실제로 비어 있음'은 전혀 다른 사건인데, 이를 뭉뚱그리면 종합 단계에서 잘못된 결론이 납니다. 하위 에이전트의 오류를 조용히 삼켜 버리거나, 반대로 작은 실패에 전체 작업을 중단하는 것은 둘 다 나쁜 패턴입니다.

5.4 대규모 코드베이스 탐색 — 문맥 저하를 관리하는 설계

규모가 큰 코드베이스를 훑을 때는 문맥이 길어지며 판단이 흐려지는 문맥 저하(context degradation)가 생깁니다. 이를 막는 실무 장치가 몇 가지 있습니다. 중간 상태를 별도 메모 파일(scratchpad)에 적어 두면 문맥에서 밀려나도 다시 불러올 수 있고, 하위 작업을 서브에이전트(subagent)에 위임하면 상위 에이전트의 문맥을 가볍게 유지합니다. 진행 상태를 정형화한 기록 파일(manifest)로 남겨 두면 도중에 중단돼도 복구가 가능하며, /compact 같은 압축 명령으로 대화를 정리해 남은 여력을 확보합니다.

5.5 사람 검수와 신뢰도 보정 — 평균 뒤에 숨은 실패 찾기

품질을 사람 손으로 확인할 때, 전체 평균 지표는 특정 구간의 실패를 가릴 수 있습니다. 전체 정확도가 높아 보여도 특정 문서 유형에서만 크게 틀리는 경우가 흔합니다. 그래서 무작위가 아니라 층화 표집(stratified sampling, 유형별로 나눠 표본을 뽑는 방식)으로 검수해야 구간별 약점이 드러납니다. 또 모델이 스스로 매기는 자신감 점수는 라벨이 붙은 검증 자료로 보정(calibration)해야 실제 정확도와 맞고, 항목 단위로 따로 보정하는 편이 정밀합니다. 문서 유형이나 항목의 성격에 따라 검수 경로를 나누면 사람의 손이 필요한 곳에 집중됩니다.

5.6 다중 출처 종합에서의 출처 추적

여러 자료를 하나로 묶어 답을 만들 때, 각 주장이 어느 출처에서 나왔는지의 연결(claim-source mapping)이 종합 과정에서 끊기지 않아야 합니다. 자료끼리 내용이 어긋나면 한쪽을 조용히 버리지 말고, 어느 출처가 무엇을 말하는지 상충을 명시해 함께 보여 줍니다. 발행일이나 수집 시점 같은 시간 정보(temporal data)도 함께 남겨야 오래된 자료와 최신 자료를 구분할 수 있습니다. 마지막으로 어떤 주제가 자료로 뒷받침되지 않는지, 빠진 범위(coverage gap)를 함께 보고하면 읽는 사람이 결론의 한계를 알 수 있습니다.

! 흔한 함정

• 문맥은 길수록 좋다고 여겨 확정 사실을 아무 자리에나 두는 것 — 긴 문맥의 가운데 정보는 모델이 놓치기 쉽습니다(lost-in-the-middle).
• 고객의 감정이나 모델의 자신감 점수를 상위 이관 트리거로 삼는 것 — 신뢰하기 어려운 대리 지표입니다.
• 하위 에이전트의 실패를 조용히 삼켜 버리거나, 반대로 작은 오류에 전체 작업을 멈추는 양극단.
• 전체 평균 지표만 보고 품질을 판정해, 특정 문서 유형이나 항목에서만 나는 실패를 놓치는 것.