AI 에이전트 엔지니어링 - 비결정적 AI를 제어하는 법

"AI 에이전트" 요즘 정말 핫한 키워드입니다.
LLMOps와 관련 인프라 엔지니어로서, 사실 에이전트라는 개념을 조금은 가볍게 생각했었던 것 같습니다.
하지만 시장의 변화는 생각보다 훨씬 빨랐고, 제가 알던 AI 활용의 범위를 훌쩍 넘어서고 있습니다.

변화에 적응해야할 필요성을 느끼며, 에이전트 엔지니어링의 초석을 제대로 다져보고자 이 책을 탐독하기 시작했습니다.

 

---

 

🤖 AI 에이전트가 뭐야!

데이터를 스스로 분석하고 환경을 해석하며 컨텍스트에 기반한 결정을 내리도록 설계된 지능형 시스템이다.

 

과거에 AI 에이전트라는 개념은 사실상 '챗봇'과 동의어였습니다.
하지만 LLM이 나날이 발전하면서 모델이 수행할 수 있는 영역은 상상 이상으로 넓어졌습니다.

그렇다면 AI에게 더 많은 권한을 주면 어떨까요?
예를 들어, AI에게 '계산기'나 '날씨 검색' 같은 외부 도구(Tool)를 활용할 권한을 주는 것입니다.
그러면 AI는 사용자의 질문에 따라 스스로 적절한 도구를 선택하고 최선의 답을 도출해낼 것입니다.

여기에 참고할 만한 과거 기록과 데이터까지 결합한다면, 설계자가 의도한 목표를 정확히 수행하는 고도화된 에이전트가 완성될 것처럼 보입니다.

그렇다면 이제 AI 에이전트는 만능일까요?
그렇지 않습니다. AI 에이전트는 뛰어난 역량과 가능성을 보여주지만 동시에 해결해야 할 복잡성과 과제가 많습니다.

이 책에서는 과제들을 해결하기 위한 효과적이고 적응력있는 시스템을 소개합니다.

 

 

🏋️‍♂️ AI 모델에 손과 발을 달아주다

우리가 생각하는 대표적인 AI 모델인 Chat GPT와 Gemini를 떠올려봅시다.
내가 궁금한 것이 있을 때마다 우리는 질문을 하고, 그에 따른 답을 얻으면서 서비스를 사용합니다.

하지만 만약 주기적으로 답을 받고 싶다면?
만약 모델이 개인 데이터를 이용하도록 만들고 싶다면?
만약 모델이 외부 정보를 이용하도록 만들고 싶다면?

이러한 고민들이 모여 모델에 다양한 기능을 결합하고 자율성을 부여하는 과정에서, 비로소 'AI 에이전트'라는 개념이 정립된 것으로 보입니다.
그리고 그 기능을 Tool, Memory, 그리고 구성 요소를 연결하고 제어하는 Orchestration으로 부릅니다.

https://kanerika.com/blogs/ai-agent-architecture/

Tool

LLM은 훌륭한 두뇌이지만, 크기가 너무 커서 학습시키는 데 오래 걸리며 많은 자원을 소모합니다.
그래서 LLM은 최신 데이터를 빠르게 반영하지 못 합니다.
이를 해결하기 위해서 내부 데이터나 외부 기능을 호출할 수 있는 권한을 부여하는 것이 도구입니다.

• 로컬 도구: 로컬에서 실행하는 도구로, 보통 특정 작업에 맞춘 사전 정의 규칙과 로직을 따라 만들어집니다.
• API 기반 도구: 외부 서비스와 상호작용하도록 하여 로컬에서 수행하기 어려운 데이터 처리나 액션 실행을 가능하게 만듭니다.
• MCP: 각 데이터 소스나 서비스별로 커스텀 어댑터를 작성하는 통합 방식은 유지보수가 어렵고 확장성이 낮습니다. MCP는 모델에 독립적인 통합 표준을 통해 LLM과 외부 시스템을 연결하는 통일된 방식의 인터페이스 역할을 합니다.

MCP는 https://bcho.tistory.com/1470 블로그에서 쉽게 정리되어 있으니 참고하면 도움될 것입니다.

MCP (Model Context Protocol) 1. 개념 이해

 

Knowledge Base & Memory

대부분 사용자는 AI 에이전트가 지금까지 일어난 일과 그 이상의 추가 정보를 알기를 바랍니다.
이 책에서는 이 추가 정보를 지식과 메모리로 구별해서 표현합니다.

• 지식: 주로 RAG로 표현되며 기술 스펙, 정책 문서 등 도메인 특화 콘텐츠를 의미합니다.
• 메모리: 과거 사용자 대화, 도구 출력 등 에이전트 자신의 히스토리를 의미합니다.

기본적으로 이 정보들은 입력 시 컨텍스트에 포함이 된다. 그런데 모델이 받을 수 있는 최대 토큰 수는 정해져있습니다.

따라서 입력 값과 유사한 정보들을 빠르게 찾아내 그 정보들만 사용하는 기능이 필요합니다!
이를 위해서 RAG와 벡터 스토어를 사용합니다.

• RAG: 사용자가 질문을 던지면, 관련된 문서를 먼저 검색(Retrieval)하고, 그 내용을 질문과 합쳐서(Augmentation) 모델에게 전달하여 답변을 생성(Generation)하게 합니다.
• 벡터 스토어: 텍스트를 AI가 이해할 수 있는 배열(벡터)로 변환하고, 이를 저장하고 관리합니다. 사용자의 질문이 들어오면 이를 벡터로 변환하고 의미적으로 가장 유사한 데이터를 찾아줍니다.

https://medium.com/@bijit211987/designing-high-performing-rag-systems-464260b76815

 

Orchestration

에이전트가 사용할 수 있는 도구, 메모리가 갖추어졌으니, 이를 가지고 실제 과제를 해결하기 위한 오케스트레이션을 수행합니다.
이는 단순히 어떤 도구를 호출할지 결정하는 것을 넘어 각 모델 호출에 적합한 컨텍스트를 구성해 근거 있는 행동을 유도하는 과정을 포함합니다.

오케스트레이션 수행 방식은 에이전트 유형에 따라 추론, 계획, 행동의 접근 방식이 달라집니다.

• 반사형 에이전트
  • 조건이 참이면 도구 실행 (if-then)
  • 입력과 행동을 직접 연결하며 내부 추론 과정을 거치지 않습니다.
• 리액트 에이전트 (ReAct Agent: Reasoning + Acting)
  • 사용자의 질문에 대해 생각(Thought) → 행동(Action) → 관찰(Observation)의 단계를 거칩니다. 도구(Tool)를 사용한 결과(관찰)를 바탕으로 다시 다음 행동을 고민합니다.
  • 탐색적 시나리오(동적 데이터 분석, 다중 소스 통합)에 강하며, 중간에 전략을 조정할 수 있는 유연성이 강점입니다.
• 계획 후 실행 에이전트
  • 복잡한 작업을 수행하기 전, 작업을 뚜렷한 단계로 나누어 실행합니다.
  • 계획이 명시적으로 드러나기 때문에 더버깅과 모니터링에 강점이 있습니다.
• 쿼리 분해 에이전트
  • 복잡한 질문을 반복적으로 하위 질문으로 나누고 각 하위 질문마다 검색이나 다른 도구를 호출한 뒤 최종 답변을 도출합니다.
  • 외부 지식 검색이 필요한 상황에서 특히 효과적입니다.
• 성찰형 에이전트
  • 다음 단계로 진행하기 전 과거 단계를 검토해 실수를 찾아내고 수정합니다.
  • 초기 오류가 연쇄적으로 이어져 큰 실패로 이어질 수 있는 고위험 워크플로우에서 강점이 있습니다.
  • 정확성과 신뢰성이 더 중요한 작업에서 유용합니다.

보시다시피, 에이전트의 종류는 다양하고 결국 이를 구현하기 위한 오케스트레이션 접근 방식이 에이전트의 성공 여부에 큰 영향을 줍니다.

 

 

🤼‍♂️ 하나로는 부족해!

요즘 LinkedIn에서 "멀티 에이전트로 페르소나를 여러 개 만들고, 이를 통해 애플리케이션 개발을 n일만에 했다." 이런 글들이 많이 보입니다.
아무래도 애플리케이션 개발과 같은 고도의 작업에서는 하나의 에이전트로는 부족할 것 같습니다.
그래서 독립적인 여러 개의 에이전트를 정의하여 사용하는 케이스가 많아진 것 같습니다.
(디스코드에서 에이전트들끼리 대화하면서 협력하는 것을 보면 참 신기합니다.)

https://kanerika.com/blogs/ai-agent-architecture/

그러나 아무때나 에이전트를 추가하는 것은 아닙니다.
에이전트를 여러 개 둔다는 것은 그만큼 관리포인트가 늘어난다는 것이고, 에이전트 간 통신 인프라도 생각해야하기 때문에 전체적으로 복잡성이 커지게 됩니다.
이 책에서 제시하는 에이전트 추가 원칙은 아래와 같습니다.

• 작업 분해: 각 에이전트는 워크로드의 특정 측면에 집중하여, 책임이 단순해지고 효율성이 높아지도록 해야합니다.
• 전문화: 에이전트가 자신의 강점에 부합하는 역할을 맡도록 해 시스템의 집합적 역량을 극대화합니다.
• 파시모니: 원하는 기능을 달성하는데 최소한의 에이전트만 추가하도록 권장하는 원칙입니다.
• 조율: 에이전트 시스템이 조화롭게 작동하도록, 정보 공유를 효율적으로 하고 충돌 위험을 줄여야 합니다.
• 견고성: 하나의 에이전트가 실패했을 때도 전체 동작이 수행될 수 있도록 시스템을 구성해야 합니다.

 

 

✨ AI 에이전트가 성공하려면?

AI 에이전트는 기존 애플리케이션에 비해서 제어 가능성과 신뢰성 확보가 어렵습니다.
이는 LLM의 확률론적 특성에서 기인합니다.

• 디버깅의 어려움: 특정 단계에서 왜 잘못된 도구를 선택했는지, 혹은 왜 루프에 빠졌는지 원인을 파악하고 재현하기가 매우 어렵다.
• 신뢰성 보장 불가: 99% 성공하더라도 나머지 1%에서 예상치 못한 외부 API 호출이나 결제 등을 수행할 위험이 존재한다.
• 환각(Hallucination): 존재하지 않는 도구를 사용하려 하거나, 가상의 실행 결과를 바탕으로 다음 단계로 넘어가려 한다.
• 장기 기억 상실: 작업 단계가 길어질수록 초기 목표를 잊거나, 이전에 수행했던 실패 경험을 반복하는 경향이 있다.

또 데이터를 활용하는 에이전트에서는 데이터 드리프트도 신경써야 하고, 모델의 성능이 떨어지면 모델을 최신 버전이나 아에 다른 모델로 교체해야하는 경우도 생길 것입니다.

기존 애플리케이션은 개발자가 의도한 로직과 워크플로우로 동작합니다. 이에 비해 AI 에이전트는 신경쓸 게 너무 많습니다.
아무래도 If-Else를 LLM에게 맡긴 트레이드 오프가 아닐까 싶기도 합니다.

그럼 이를 해결하기 위해서는 어떻게 해야할까요?
결론부터 말하자면 AI 에이전트를 좀 더 구체적이고, 정교하게 만들어야 하며, 무엇보다 에이전트가 정말 일을 잘 하고 있는지 모니터링 체계를 세부적으로 짜는 것이 중요합니다!
(요즘 느끼는 건데 개발도 중요하지만 모니터링도 정말 중요한 것 같습니다.)

 

모니터링 지표

기존 애플리케이션과 다르게 AI 모델을 사용하기 때문에 확인하는 지표에서 차이가 있습니다.
그럼 AI 에이전트에서 중요하게 봐야할 지표는 무엇일까요?

• 워크플로우 관련
  • 작업 성공률: 에이전트가 의도한 워크 플로우를 얼마나 완수했습니까?
  • 도구 재현율: 계획 모듈이 예상한 도구를 모두 호출했습니까?
  • 도구 정밀도: 불필요한 도구 호출을 피했습니까?
  • 파라미터 정확도: 각 도구에 올바른 인자를 제공했습니까?
• 출력 품질
  • 환각율: 제공된 데이터나 도구의 결과와 무관한 거짓 정보를 생성합니까?
  • 토큰 사용량: 토큰을 얼마나 사용했습니까? (급격한 증감은 이슈 신호일 수 있음)
  • 재시도 빈도: 계획이나 도구 사용 시 재시도를 얼마나 했습니까? (불안정성 식별)
• 사용자 피드백
  • 재질의/재표현 비율: 사용자가 첫 시도에 이해되지 않고, 재질문을 했습니까?
  • 작업 포기율: 사용자가 혼란스럽거나 좌절시키는 워크플로우를 경험했습니까?
  • 명시적 평점: 시스템의 유용성이 어떻습니까?

 

---

이 책을 읽고 정리하면서 AI 에이전트에 대한 이해도가 높아진 것 같습니다. 

결국 AI 에이전트 엔지니어링은 단순히 AI 모델을 사용하는 단계를 넘어, 비결정적인 AI를 결정론적인 소프트웨어 시스템으로 감싸 안는 과정이라고 생각합니다.
그리고 그 결과물이 만들어내는 가치는 실로 무궁무진할 것으로 기대가 됩니다.