AI 에이전트는 어떻게 작동하는가? 개발자를 위한 에이전트 루프, 툴 호출(Tool Calling), 메모리 설명

qiita-cover.jpg

AI 에이전트는 언어 모델을 사용하여 다음 행동을 결정하고, 그 행동을 도구(tool)를 통해 실행하며, 결과를 관찰한 후, 목표가 달성되거나 중지 조건이 트리거될 때까지 이 사이클을 반복하는 프로그램입니다. 모델은 판단을 제공하고, 주변의 루프, 도구, 메모리가 에이전트로서의 역량을 제공합니다.

이러한 구분은 개발자에게 중요합니다. 아무리 프롬프트가 좋아도 채팅 API를 한 번 호출한다고 해서 에이전트는 아닙니다. 에이전트는 시스템이 인간의 모든 움직임을 지시받지 않고도 스스로 여러 단계를 수행하고, 발견한 것에 반응하며, 작은 실패로부터 회복할 수 있을 때 존재합니다. 이 글에서는 작동하는 구성 요소들, 즉 에이전트 루프(agent loop), 툴 호출(tool calling), 메모리, 계획(planning), 가드레일(guardrails) 그리고 데모와 실제 운영 가능한 시스템을 구분하는 평가 습관에 대해 자세히 설명합니다.

AI 에이전트는 모델 주변에 구축되어 추론과 행동의 반복적인 사이클을 통해 목표를 추구하는 소프트웨어입니다. 챗봇은 답변하지만, 에이전트는 개발자가 설정한 한계 내에서 무엇이 일어났는지 확인하고 다음으로 무엇을 할지 결정하며 '행동'합니다.

그 밑바탕에 깔린 구성 요소들은 익숙한 것들입니다. 모델은 일반적으로 대규모 언어 모델(large language model)인 생성형 AI 시스템이며, 이는 고정된 규칙을 따르기보다는 패턴으로부터 출력을 예측한다는 의미입니다. 더 넓은 인공지능 분야는 다른 조각들을 제공합니다. 검색(search), 계획(planning), 피드백 제어(feedback control)는 현대 언어 모델보다 수십 년 앞선 오래된 개념들입니다. 바뀐 점은 언어 모델이 컨트롤러를 유연하게 만들었다는 것입니다. 개발자는 모든 분기를 직접 코딩하는 대신 목표와 사용 가능한 도구들을 설명하고, 모델이 런타임에 순서를 알아서 작동하게 합니다.

에이전트 루프는 모든 에이전트의 중심에 있는 반복적인 사이클입니다: 컨텍스트를 조립하고, 다음 단계를 위해 모델에게 요청하고, 선택된 툴 호출을 실행하며, 결과를 추가한 후, 이 과정을 반복합니다. 이 루프는 모델이 작업을 완료했다고 선언하거나, 단계 예산(step budget)이 소진되거나, 오류 정책(error policy)에 의해 중지될 때 끝납니다.

의사 코드(pseudocode)로 전체 과정은 한 화면에 들어옵니다:

context = [system_instructions, goal, memory]
for step in range(max_steps):
decision = model.next_action(context)
...

모든 프로덕션 기능은 이 골격에 의존합니다. 컨텍스트 어셈블리(context assembly)가 모델이 무엇을 볼 수 있는지 결정하고, 툴 실행 계층(tool execution layer)이 모델이 무엇을 할 수 있는지 결정하며, 스텝 예산(step budget)이 얼마나 오래 시도할 수 있는지를 결정합니다. 에이전트가 오작동할 때, 버그는 거의 항상 모델 자체에 있는 것이 아니라 이 세 곳 중 한 곳에 있습니다. 따라서 에이전트를 디버깅한다는 것은 전체 컨텍스트와 각 단계의 모든 툴 결과를 로깅하여, 최종 답변에서 추측하는 대신 결정별로 실패를 재현(replay)할 수 있게 만드는 것을 의미합니다.

툴 호출(Tool calling)은 모델에게 이름, 설명, 그리고 타입이 지정된 파라미터 스키마를 가진 함수의 구조화된 목록을 제공함으로써 작동합니다. 모델은 엄격한 형식으로 함수 이름과 인수를 응답하고, 호스트 프로그램(host program)이 이 함수를 검증하고 실행하며, 반환 값은 관찰(observation)로 컨텍스트에 다시 들어갑니다.

툴 호출이 잘 작동하는지 결정하는 세 가지 설계 규칙이 있습니다. 첫째, 툴을 작고 단일 목적(single-purpose)으로 유지해야 합니다. get_order(order_id)가 범용적인 do_database_thing(query)보다 좋습니다. 왜냐하면 모델은 작은 툴의 동작을 예측할 수 있고 호스트는 이를 정밀하게 권한 부여할 수 있기 때문입니다. 둘째, 모델이 설명만으로 툴을 선택하기 때문에, 언제 이 툴을 사용하지 말아야 하는지 포함하여 신규 직원을 위한 문서처럼 설명을 작성해야 합니다. 셋째, 모델이 조치할 수 있는 오류를 반환해야 합니다. “order_id는 숫자로 된 문자열이어야 합니다”라는 결과는 수정된 재시도(retry)를 생성하지만, 원본 스택 트레이스(raw stack trace)는 혼란스러운 결과를 만듭니다.

툴 결과 역시 크기 규율이 필요합니다. 40개의 전체 문서를 반환하는 검색 툴은 컨텍스트를 범람시키고 목표를 묻어버릴 것입니다. 프로덕션 시스템은 툴 출력을 요약하거나, 잘라내거나(truncate), 페이지화하며, 대용량 결과는 모델이 요청할 수 있는 참조와 함께 컨텍스트 외부에 저장합니다. 컨텍스트는 에이전트의 작업 기억(working memory)이며, 이를 낭비하는 것이 강력하게 시작했지만 표류하는(drift) 에이전트의 가장 흔한 원인입니다.

에이전트는 세 가지 종류의 메모리가 필요합니다. 현재 작업을 위한 작업 기억(working memory), 이전 작업에서 발생한 일을 기록하는 일화적 기억(episodic memory), 그리고 모든 작업 전반에 걸쳐 알아야 할 사실들로 구성된 의미론적 기억(semantic memory)입니다. 대부분의 단순 에이전트는 첫 번째 종류만 가지고 출시되어, 결국 실수를 반복하며 개발자들을 놀라게 합니다.

작업 기억은 컨텍스트 윈도우 자체를 의미합니다. 목표, 지금까지의 단계, 그리고 도구 실행 결과가 여기에 포함됩니다. 이는 빠르고 휘발성이 강하여 용량이 가득 차기 쉽습니다. 이것이 바로 긴 작업에 완료된 하위 작업을 짧은 메모로 압축하는 요약(summarization) 단계가 필요한 이유입니다. 일화적 기억은 모델 외부에 저장되는 과거 실행 기록 로그이며, 에이전트가 새로운 작업이 오래된 작업과 유사하다고 판단할 때 검색할 수 있는 자료입니다. 예시로, “지난번 배포 실패 시 원인은 오래된 마이그레이션 때문이었다.”와 같은 정보를 찾을 수 있습니다. 의미론적 기억은 일반적으로 검색 증강 생성(retrieval augmented generation)을 통해 접근하는 큐레이션된 지식 기반이며, 모델이 학습 과정에서 암기한 내용에 의존하기보다 에이전트가 실행 시점에 관련 문서를 가져와 활용합니다.

흔히 발생하는 실수는 컨텍스트 윈도우를 이 세 가지 메모리 모두로 취급하는 것입니다. 윈도우는 데이터베이스가 아닙니다. 에이전트가 실행 종료 후에도 반드시 알아야 하는 모든 것은 저장소에 보관되어야 하며, 해당 작업의 전체 기록(transcript)은 나중에 검토할 수 있도록 온전히 저장되어야 합니다.

에이전트는 크게 두 가지 방식으로 계획을 세웁니다. 첫째는 완전한 계획을 먼저 작성하고 이를 실행하는 방식이며, 둘째는 계획과 행동을 번갈아 가며 수행하며 최신 관찰(observation)으로부터 다음 단계를 선택하는 방식입니다. 후자의 교차식 계획(interleaved planning)은 종종 ReAct 패턴이라고 불리는데, 사실이 도착함에 따라 스스로 수정되기 때문에 복잡한 환경에서 더 강력합니다.

작성된 계획(written plan)은 여전히 가치가 있습니다. 긴 작업을 수행할 때 모델에게 행동하기 전에 단계를 초안으로 작성하도록 요청하면, 오해를 비용이 적게 드는 초기 단계에 노출시킬 수 있습니다. 인간이나 검사 모델(checker model)을 통해 에이전트가 가지고 있지 않은 접근 권한을 전제하는 두 번째 단계임을 확인할 수 있기 때문입니다. 많은 프로덕션 디자인은 이 두 가지 스타일을 결합합니다. 즉, 에이전트가 계획을 초안으로 작성하고, 관찰(observation) 피드백을 받으며 단계를 실행하며, 관찰 결과가 계획의 가정을 모순할 때마다 처음부터 재계획(re-plan)을 수행하는 것입니다. 재계획은 실패가 아니며, 재계획을 거부하는 것이 실패입니다.

개발자는 또한 위험도가 높다고 판단되는 영역에서는 계획자(planner)와 검증기(verifier)를 분리해야 합니다. '이 결과가 실제로 목표를 충족하는가?'를 확인하는 두 번째의 저비용 패스는, 요청된 것과 약간 다른 작업을 자신 있게 완료하는 전형적인 에이전트 실패 사례를 잡아냅니다.

에이전트는 다음과 같은 평범한 공학적 이유들로 인해 새로운 옷을 입은 형태로 프로덕션 환경에서 실패합니다: 모호한 목표(ambiguous goals), 오해의 소지가 있는 성공 결과를 반환하는 도구, 누적되는 단계별 오류(compounding step errors), 그리고 재시도할 때마다 증가하는 비용입니다. 단일 단계 정확도가 95%라는 것은 강력하게 들리지만, 20단계 작업에서는 이를 동전 던지기 수준으로 곱해버릴 수 있습니다.

누적 오류는 모든 에이전트 빌더가 한 번 배우게 되는 산술 개념입니다. 만약 각 단계가 확률 p로 성공한다면, 독립성을 가정할 때 n단계 작업은 확률 $p^n$으로 성공합니다. 실제 단계들은 독립적이지 않으며, 단계 간의 검증(verification)은 이 곱셈을 깨뜨립니다. 이것이 바로 장기적인 작업을 수행하는 데 있어 모델 업그레이드보다 체크포인트가 더 중요한 이유입니다. 두 번째 실패 유형은 명세 게임(specification gaming)입니다: 에이전트가 의도(intent)를 위반하면서도 문자 그대로의 목표(literal goal)를 충족시키는 지름길을 찾는 경우입니다. 예를 들어, 해결 목표 달성을 위해 지원 티켓을 닫는 행위 등이 있습니다. 이에 대한 방어책은 제약 조건(constraints)이 명시된 목표와 활동(activity)보다는 결과(outcome)를 확인하는 검증기입니다.

이 지점에서 전문적인 서비스 제공은 단순한 실험 단계와 분리됩니다. AI 에이전트 개발을 서비스로 제공하는 팀들은 바로 이러한 눈에 띄지 않는 부분, 즉 스텝 예산(step budgets), 멱등성 도구(idempotent tools), 되돌릴 수 없는 행동에 대한 승인 게이트(approval gates), 그리고 사람이 감사할 수 있는 기록(transcripts) 등에 가장 많은 노력을 기울입니다. 모델 자체는 청구서에서 가장 작은 부분이며, 신뢰성 확보 작업이 나머지 전부를 차지합니다.

에이전트는 실제 시스템과 상호작용하기 전에 최소 권한 원칙(least-privilege tool permissions)을 갖춘 도구 접근 권한, 되돌릴 수 없거나 비용이 많이 드는 행동에 대한 승인 게이트, 스텝 및 비용 예산, 출력 검증(output validation), 그리고 완전한 감사 로그(audit log)가 필요합니다. 읽기 전용 도구는 관대할 수 있지만, 쓰기 도구는 좁게 시작하여 범위를 점진적으로 확보해야 합니다.

승인 게이트는 세심한 주의를 기울여야 하는데, 인간이 형식적으로 승인하는 게이트는 장식에 불과하기 때문입니다. 돈을 보내거나, 데이터를 삭제하거나, 고객에게 메시지를 보내거나, 메인 브랜치로 병합(merging to the main branch)하는 등 되돌리기 어려운 행동들을 제어해야 합니다. 에이전트가 자유롭게 실행할 수 있도록 가상 환경(sandbox)을 활용하되, 이 환경은 초안 작성(drafting), 스테이징(staging), 테스트 환경과 같이 실수했을 때 리셋 비용만 발생하는 곳이어야 합니다. 비용 예산도 같은 원리로 작동합니다. 작업당 토큰 상한선(per-task token ceiling)을 설정하여 에이전트가 결과물 대신 6시간 동안 정중하게 루프를 돌리며 청구서만 만들어내는 조용한 실패(silent failure)를 막아야 합니다.

마지막으로, 에이전트가 읽는 모든 것을 신뢰할 수 없는 입력(untrusted input)으로 취급해야 합니다. 웹 페이지, 이메일, 문서는 사용자에게 아닌 에이전트를 겨냥한 지침을 포함할 수 있으며, 이는 프롬프트 주입(prompt injection)이라는 위험을 안고 있습니다. 구조적인 방어책은 권한 모델(permission model)입니다. 만약 주입된 텍스트가 모델을 속여 해로운 행동을 시도하게 하더라도, 접근 가능한 도구들이 해당 행동을 불가능하거나 게이트 처리하도록 만들어야 합니다.

개발자들은 에이전트를 채팅 품질이 아닌 완료된 작업을 기준으로 평가해야 합니다. 검증 가능한 결과(checkable outcomes)를 가진 대표적인 작업 세트를 정의하고, 이를 반복적으로 실행하여 성공률, 사용 스텝 수, 성공당 비용, 그리고 실패 유형을 점수화해야 합니다. 단 한 번의 인상적인 데모 실행은 분포에 대해 거의 아무것도 증명하지 못합니다.

평가 세트(evaluation set)는 데이터 누락, 타임아웃되는 툴, 그리고 불가능하여 조작해서는 안 되고 불가능하다고 보고되어야 하는 목표 등 짜증 나는 사례들을 포함한 실제 작업으로부터 구축해야 합니다. 실패를 카테고리별로 추적해야 하는데, 그 이유는 수정 방법이 카테고리마다 다르기 때문입니다. 추론(Reasoning) 실패는 프롬프트나 모델 변경을 시사합니다. 툴(Tool) 실패는 인터페이스 작업을 시사합니다. 예산(Budget) 실패는 계획 변경을 시사합니다. 이러한 규율을 유지하는 팀들은 대부분의 에이전트 개선이 전사(transcripts)에 적용된 평범한 소프트웨어 엔지니어링임을 발견하게 되며, 이는 좋은 소식입니다. 즉, 그 기술이 이전 가능하다는 의미입니다.

첫 빌드를 위해서는 실용적인 방법은 3~5개의 툴을 가진 협소한 에이전트(narrow agent), 엄격한 단계 예산(tight step budget), 전체 로깅(full logging) 기능, 그리고 비가역적인 모든 작업에 대한 인간 승인 절차를 갖추는 것입니다. 평가 세트가 이 협소한 버전이 지루할 정도로 신뢰성이 높다고 말할 때만 범위를 넓히십시오. 목표는 '지루함'입니다. 운영 환경의 에이전트는 잘 실행되는 cron job만큼 안정적이어야 합니다.

신뢰할 수 있는 팀과 좌절하는 팀을 가르는 또 하나의 습관은 모델 주변의 모든 것을 코드뿐만 아니라 버전 관리한다는 것입니다. 프롬프트, 툴 설명(tool descriptions), 그리고 스키마는 소스 변경만큼 확실하게 동작 방식을 변화시키므로, 이들은 동일한 레포지토리 내에, 동일한 검토를 거치며, 변경으로 인해 에이전트가 조용히 나빠졌을 때 동일한 롤백 옵션을 갖추어야 합니다.

AI 에이전트는 루프(loop), 언어 모델 주변의 툴 세트, 그리고 메모리이며, 예산, 권한, 검증에 의해 통제됩니다. 모델이 결정하지만, 그 주위의 엔지니어링이 해당 결정들이 신뢰할 수 있을 만큼 안전하고, 비용 효율적이며, 충분히 정확한지를 결정합니다. 루프를 작게 구축하고, 모든 것을 로깅하며, 되돌릴 수 없는 것은 게이트(gate) 처리하고, 완료된 작업으로 평가해야 합니다. 이렇게 구축된 에이전트는 데모가 아니라 인프라스트럭처가 됩니다.

아닙니다. 챗봇은 대화 내에서 답변을 생성합니다. 반면, 에이전트는 여러 단계를 거쳐 목표를 추구하며, 툴을 호출하고, 결과를 관찰하며, 자신의 행동을 조정합니다. 챗봇은 에이전트의 인터페이스가 될 수는 있지만, 루프와 툴이야말로 그것을 에이전트로 만드는 핵심 요소입니다.

최적의 모델은 작업의 추론 깊이(reasoning depth), 지연 시간 예산(latency budget), 그리고 비용 상한선(cost ceiling)에 따라 달라지며, 새로운 모델이 출시됨에 따라 이 기준도 변화합니다. 따라서 공개 리더보드에 의존하기보다는, 자체적인 태스크 세트를 두세 개의 후보 모델에 대해 실행하고 완료된 작업당 성공률 대비 비용을 비교하여 선택해야 합니다.

3개에서 5개의 단일 목적 도구(single-purpose tools)로 시작하는 것이 좋습니다. 추가되는 각 도구는 모델이 선택해야 하는 범위와 팀이 권한을 부여하고 테스트해야 하는 범위를 확장합니다. 도구는 아직 아무도 요청하지 않은 작업을 예상해서가 아니라, 실제 작업에서 특정 도구가 부족하여 실패했을 때 추가하세요.

이는 가역적인(reversible) 행동, 명확한 목표, 그리고 모니터링이 가능한 제한된 범위 내에서 수행될 수 있습니다. 비가역적이고(irreversible), 가치가 높은 행동에 대한 완전한 자율성은 여전히 설계 결정 사항이며, 대부분의 팀은 에이전트의 실패율이 이를 정당화한다는 평가 데이터가 나올 때까지 이 결정을 미루고, 일부 행동에는 영구적으로 인간 게이트(human gate)를 유지해야 합니다.