에이전트에게 기억보다 먼저 필요한 것은 장부다

제일 먼저 든 생각

에이전트 자동화에서 자주 생기는 불안은 “모델이 답을 몰라서”가 아니다. 오히려 필요한 정보를 한 번은 봤는데, 몇 턴 뒤에는 다른 정보처럼 다루거나, 정책상 하면 안 되는 실행을 그럴듯한 도구 호출로 밀어붙이는 순간이 더 위험하다.

LedgerAgent 논문은 이 문제를 아주 실무적인 언어로 다룬다. 고객서비스 에이전트가 예약을 취소하고, 환불을 처리하고, 계정을 수정하는 장면에서는 대화 기록 전체를 다시 읽는 능력보다 현재 업무 상태를 별도 장부(ledger)에 정확히 적어두는 구조가 중요하다는 것이다.

LedgerAgent는 모델을 더 똑똑하게 만들기보다, 실행 직전의 상태와 정책 경계를 명시적으로 분리한다.

프롬프트 안에 묻힌 상태는 실행 순간에 흔들린다

일반적인 도구 호출 에이전트는 사용자 말, 도구 반환값, 이전 액션, 정책 문서를 모두 프롬프트에 넣는다. 그러면 매 턴마다 모델은 긴 대화 기록에서 어떤 사실이 지금 필요한지 다시 찾아야 한다. 이 방식은 간단하지만, 상태 관리가 암묵적이다.

논문이 지적하는 실패는 두 가지다. 하나는 필요한 사실을 검색했는데도 나중에 오래됐거나 빠진 정보로 판단하는 경우다. 다른 하나는 도구 호출 문법은 맞지만 현재 상태와 도메인 정책을 기준으로 보면 하면 안 되는 실행을 하는 경우다.

“도구 호출은 문법적으로 유효할 수 있지만, 현재 업무 상태에 따라 달라지는 도메인 정책을 여전히 위반할 수 있다.”

“A syntactically valid tool call may still violate a domain policy that depends on the current task state.”

업무 자동화로 옮기면 이 문장은 곧바로 와 닿는다. 휴가 승인, 비용 환급, 고객 데이터 수정, 교육 이수 처리 같은 작업은 “도구를 부를 수 있는가”보다 “지금 이 조건에서 불러도 되는가”가 먼저다.

LedgerAgent가 바꾸는 경계

LedgerAgent는 추론 시점(inference-time)에 두 가지를 추가한다. 첫째, 성공한 도구 반환값에서 필요한 필드를 뽑아 스키마 기반 장부에 저장한다. 둘째, 환경을 바꾸는 도구 호출 전에 정책 게이트(policy gate)를 둬 현재 장부 상태와 정책 조건을 대조한다. 위반이면 호출을 막고, 어떤 상태와 규칙이 충돌했는지 피드백한다.

중요한 점은 추가 학습이나 추가 LLM 호출이 핵심이 아니라는 것이다. 비교 조건에서도 같은 정책, 같은 도구, 같은 대화 기록, 같은 모델 호출 수를 두고 장부 표현과 실행 전 게이트를 더했다. 즉 “모델이 잘 기억하길 바라는 설계”에서 “기억해야 할 상태를 별도 구조로 관리하는 설계”로 옮긴 셈이다.

논문은 항공, 리테일, 통신, 텔레헬스 고객서비스 도메인에서 여섯 모델을 평가했다. Kimi-K2.5, GLM-5, MiniMax M2.5에서 Ledger 방식은 평균 pass^1과 pass^4를 높였고, GPT-4.1과 GPT-5.2의 항공·리테일 비교에서도 pass^1이 각각 12.2점, 15.5점 개선됐다. 특히 여러 번 실행해도 일관되게 성공하는지를 보는 pass^4에서 개선이 의미 있게 나타난다.

Deciflow식 자동화에 필요한 질문

이 논문을 업무 자동화 설계에 붙이면, “프롬프트를 더 길게 쓰자”보다 먼저 나오는 질문이 있다.

• 이 자동화가 다루는 업무 상태는 무엇인가.
• 상태는 대화 기록이 아니라 어떤 필드 장부로 남아야 하는가.
• 실행 전 반드시 확인해야 하는 정책 조건은 무엇인가.
• 상태를 바꾸는 도구 호출과 조회용 도구 호출을 구분했는가.
• 게이트가 막았을 때 사용자에게 어떤 설명을 돌려줄 것인가.

이 질문은 RAG나 메모리 설계와도 맞닿는다. 검색된 문서가 많아지는 것만으로는 안전한 실행이 되지 않는다. 실행 자동화에서는 “근거를 찾았다” 다음에 “현재 상태로 확정했다”, “정책상 실행 가능하다”라는 별도 단계가 필요하다.

조심해서 읽을 점

물론 이 연구의 결과를 모든 업무 에이전트에 일반화할 수는 없다. 실험은 고객서비스형 벤치마크와 정해진 도구·정책 조건 안에서 이뤄졌다. 실제 조직에서는 정책이 더 모호하고, 예외 처리가 문서 밖에 있으며, 사람이 개입해야 하는 경계도 더 복잡하다.

그래도 방향은 분명하다. 에이전트 실패를 “모델 성능 부족”으로만 보지 말고, 상태와 정책을 어디에 저장하고 언제 검사할지 설계해야 한다.

다음 작은 실험

업무 자동화 하나를 고른 뒤, 프롬프트를 고치기 전에 장부부터 그려보면 좋겠다. 예를 들어 “교육 이수 확인 후 수료 처리”라면 장부에는 직원 ID, 과정 ID, 출석률, 평가 통과 여부, 예외 승인 여부, 처리 일시가 들어갈 수 있다. 그리고 수료 처리 도구를 호출하기 전에 정책 게이트가 이 필드를 확인한다.

오늘 남길 질문은 이것이다.

이 에이전트가 실행 직전에 반드시 다시 확인해야 할 장부 필드는 무엇인가?

그 필드가 없다면, 에이전트는 기억력이 부족한 것이 아니라 운영 구조가 비어 있는 것이다.

원문 정보

• 제목: LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents
• 저자: Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2606.20529v1
• PDF: https://arxiv.org/pdf/2606.20529

원문 논문: LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents