제4장 — AI 에이전트와 도구 호출

LLM Primer V: 실전 LLM 애플리케이션 구축을 챕터별로 따라가는 워크스루의 네 번째 글입니다. 에이전트를 도구를 상대로 루프 도는 언어 모델로 다루고, 그 스키마·메모리 층·다중 에이전트 배선은 루프를 실전에 맡기기 전에 엔지니어링되어야 한다고 말하는 장입니다.

이 장이 존재하는 이유

텍스트만 넣고 텍스트만 뽑는 상태 없는 모델은 하나의 계산기입니다. 프로덕션 작업은 그것을 여러 단계에 걸쳐 목표를 좇는 행위자로 바꾸는 것을 요구합니다. 이 도구를 부르고, 다음에는 저 도구를 부르고, 결과 중 어느 것을 사용자에게 요약할지 결정하고, 과제가 끝난 지점에서 멈추는 일. 이 움직임은 다이어그램에서는 간단해 보이고, 현실에서는 간단하지 않습니다. 에이전트는 방황하고, 루프에 빠지고, 잘못된 도구를 부르고, 도구가 받을 수 없는 인자를 지어내고, 이미 가져온 것을 잊고, 자기 권한 바깥에서 행동합니다. 제4장은 그 루프를 읽히게 하고 경계 안에 두는 엔지니어링에 관한 것입니다 — 스키마, 메모리 규율, 그리고 그럴싸해 보이는 데모를 프로덕션 행위자로 바꿔 주는 다중 에이전트 구조.

4.1 조합으로서의 에이전트 아키텍처, 선택이 아니라

기본 루프는 ReAct입니다. 상황에 대해 추론하고, 도구를 호출해 행동하고, 결과를 관찰하고, 목표가 달성되거나 단계 예산이 소진될 때까지 반복합니다. 프로덕션 시스템은 그 위에 세 가지 증강을, 셋 중 하나를 고르는 게 아니라 모두 얹습니다. 네이티브 함수 호출 — 공급자가 디코딩 시점에 JSON Schema를 기준으로 도구 인자를 제약합니다 — 은 I/O 계약을 굳혀, 루프가 더 이상 잘못된 형식의 호출에서 복구할 필요가 없게 합니다. Plan-and-Execute 스타일의 명시적 계획은 장기 지평의 과제에서 계획을 앞쪽에 배치하고, 세상이 바뀔 때만 계획자를 다시 돌립니다. 워크플로 오케스트레이션은 과제의 알려진 전이를 그래프로 인코딩하고, 단계 안의 결정만 모델에 맡깁니다. 이는 대부분의 엔터프라이즈 배포가 수렴하는 모양인데, 알 수 있는 것과 판단이 필요한 것을 분리해 주기 때문입니다. 리플렉션 루프, 비용 티어드 함대에 걸친 다중 모델 라우팅, 그리고 전문 하위 에이전트가 이 옆에 추가 증강으로 자리합니다.

4.2 도구 호출 메커닉스 — 스키마가 계약

모든 도구에는 스키마가 있고, 그 스키마는 루프가 모델에 강제하는 계약입니다. 속성 수준의 설명은 사람이 아니라 모델을 위한 문서입니다. 도메인이 허용하는 곳에서는 enum으로 인자 공간을 닫습니다. 아이템포턴시 키는 루프가 부수 효과를 두 번 일으키지 않고 도구 호출을 재시도하게 해 줍니다. 구조화된 재시도 가능 오류는 모델이 짐작하는 대신 깔끔하게 복구할 수 있게 해 줍니다. 도구는 최소한이어야 합니다 — 도구 하나에 한 가지 뚜렷한 일 — 왜냐하면 열 개의 선택 플래그를 지닌 뚱뚱한 도구는 모델이 틀리는 도구이기 때문입니다. ask_user 도구는 카탈로그에 명시적으로 있어야 합니다. 에이전트가 인자를 지어내는 대신, 모호함을 정당하게 끌어올릴 수 있는 길을 마련해 주기 위해서입니다. 도구가 서로 독립적이라고 선언한 경우에만 동시성이 안전합니다. 루프는 선언된 독립 도구를 병렬 가능한 것으로, 나머지 모두를 엄격히 순차적인 것으로 다룹니다. 「에이전트가 잘못된 일을 했다」로 귀결된 모든 실전 프로덕션 사고는, 인자의 의미를 스키마가 말해 주지 않은 도구로 되짚어집니다.

4.3 세 층의 메모리: 단기, 장기, 시맨틱

에이전트에게 메모리가 필요한 이유는, 과제가 한 턴에 딱 맞아떨어지는 경우가 드물기 때문입니다. 단기 메모리는 최근 대화를 슬라이딩 윈도로 두르고, 그 슬라이딩 안에서도 살아남는 고정 메시지 — 시스템 프롬프트, 현재 목표, 진행 중인 계획 — 를 유지하며, 창 바깥으로 떨어져 나간 실행 이력을 주기적으로 요약합니다. 장기 메모리는 관측할 때마다가 아니라 확인 시점에 기록된 정제된 사실의 벡터 저장소이며, 시작 시점만이 아니라 루프 여러 지점에서 검색됩니다. 시맨틱 메모리는 유사도가 아니라 구조적 결합이 필요한 질의를 위한 트리플의 지식 그래프입니다 — 「누가 누구에게 보고하는가」, 「어떤 제품이 어느 범주에 속하는가」와 같이 벡터 저장소가 납작하게 만들어 버리는 관계들. 이 셋은 서로 다르게 사용되기 때문에 서로 다르게 저장되고, 규율은 모든 것을 하나의 임베딩 인덱스로 뭉개지 않고 쓰기와 읽기를 알맞은 층으로 라우팅하는 것입니다.

제4장이 준비하는 것

에이전트도 RAG도 확률적 트레이스를 만들어 냅니다. 사용자가 불만을 제기하고, 로그에는 세 도구와 여덟 번의 모델 호출에 걸친 백 개의 스팬이 남아 있으며, 팀은 그 실패가 검색 회귀인지, 프롬프트 표류인지, 도구 스키마 문제인지, 아니면 부러진 하류 시스템을 상대로 에이전트가 올바르게 선택한 것인지 판단해야 합니다. 그 질문은, 트레이스를 측정 가능한 통과/실패 신호로 바꾸는 규율 없이는 답할 수 없습니다. 제5장은 그 규율입니다 — LLM-as-judge, RAG 트라이어드, 에이전트를 위한 궤적 테스트, 그리고 프로덕션 트레이스가 다음 배포를 게이팅하는 평가 세트로 흘러 들어가는 지속 루프.

다음 → 제5장: LLM 애플리케이션 평가하기. 확률적 트레이스를 팀이 그에 맞춰 출시할 수 있는 통과/실패 신호로 바꾸는 평가 규율.