소개: 에이전틱 AI의 시대

2026년을 살고 있는 개발자라면, 무언가 바뀌고 있다는 걸 알아차렸을 겁니다. 지금 구축 중이거나 구축 요청 받은 애플리케이션은 불과 2년 전에 작업했던 것과 근본적으로 다릅니다. 앱은 더 이상 단순히 요청에 응답하는 데 그치지 않습니다. 생각하고, 계획하며, 행동합니다.

에이전틱 AI 시대가 도래했습니다.

에이전틱 AI 시스템은 이제 있으면 좋은 것이 아니라, 현대 애플리케이션의 필수 요소로 빠르게 자리 잡아가고 있습니다. 챗봇은 문서를 탐색하고, API를 호출하며, 데이터베이스를 쿼리하고, 다음에 수행할 작업을 결정할 수 있습니다. 추전 엔진은 고정된 알고리즘을 실행하지 않습니다. 여러 AI 에이전트들이 협업하여 사용자의 의도를 파악하고, 컨텍스트를 검색하며, 실시간으로 맞춤화된 제안을 생성합니다.

여기서 중요한 점은, 이러한 시스템을 구축하고 계속 실행되도록 유지하는 책임은 사람에게 있다는 것입니다.

문제는, 기존의 소프트웨어 엔지니어링 방식은 에이전틱 시스템에 매끄럽게 적용되지 않는다는 것입니다. 유닛 테스트만 하고 모든 작업이 끝났다고 할 수 없습니다. 시스템은 본질적으로 비결정론적이기 때문에 모든 예외 상황을 예측할 수 없습니다. 동일한 입력이 다른 출력을 생성할 수 있고, 에이전트가 환각을 일으킬 수 있으며, 도구 호출이 실패할 수도 있습니다. 에이전트 하나의 실수가 전체 시스템에 연쇄적으로 파급될 수 있습니다. 그리고 사용자가 불만을 제기하거나 더 심각하게는 AI의 불필요한 API 호출로 인해 5천만 원이라는 큰 비용이 발생한 이유를 CEO가 묻기 전까지는 이러한 사실을 알 수 없습니다.

실제로 일어날 수 있는 문제입니다. 최근 업계 연구에 따르면, 영향력이 큰 운영 중단으로 인해 현재 평균 시간당 200만 달러의 비용이 야기됩니다. 이는 시스템이 다운되는 1분마다 33,000달러 이상의 비용이 발생한다는 의미입니다. 에이전틱 시스템에 장애가 발생하면 시간과의 싸움이 시작되는데, 적절한 옵저버빌리티가 없다면 상황을 파악할 수 없습니다.

결정론적 시스템에서 확률론적 시스템으로의 전환

개발자들은 결정론적 시스템에 익숙합니다. 코드를 작성하면 매번 같은 방식으로 실행되고, 함수는 동일한 입력에 대해 동일한 출력을 반환합니다. 디버깅은 논리적입니다: 스택 추적을 따라가서 버그를 찾고, 수정하고, 배포하면 모든 것이 완료됩니다.

에이전틱 AI 시스템은 이러한 멘탈 모델을 완전히 무너뜨립니다. 시스템은 확률적으로 작동합니다. LLM은 추론 과정의 미묘한 차이에 따라 각기 다른 도구를 호출할 수 있습니다. 검색 시스템은 의미적 유사도 점수에 따라 다른 문서를 제공할 수 있습니다. 다중 에이전트 워크플로우는 에이전트가 지시 사항을 해석하는 방식에 따라 완전히 다른 실행 경로를 택할 수 있습니다. 하지만 이는 버그가 아니라, 에이전틱 시스템을 강력하고 유연하게 만드는 역량입니다. 하지만 이로 인해 적절한 옵저버빌리티 인프라 없이는 시스템을 이해하고, 디버깅하며, 유지 관리하기가 매우 어려워집니다

간단한 예를 들어보겠습니다. 주문 정보 조회와 배송 업데이트를 제공해야 하는 고객 지원 에이전트가 있다고 가정해 보겠습니다. 보통은 완벽하게 작동하지만, 때때로 주문이 분명히 존재함에도 사용자에게 주문이 존재하지 않는다고 안내합니다. 그냥 타임아웃되는 경우도 있습니다.

기존 로깅에서는 다음과 같은 내용이 표시됩니다.

[INFO] 사용자 쿼리 수신: "내 주문 #12345는 어디에 있나요?"
[INFO] LLM 호출이 2.3초 만에 완료됨
[ERROR] 데이터베이스 쿼리 실패

 

좋습니다. 하지만  데이터베이스 쿼리가 실패했는가? LLM은 어떤 결정을 내렸는가? 어떤 도구를 호출하려고 했는가? 프롬프트는 올바르게 구성되었는가? 환각 현상으로 다른 주문 번호를 생성했는가? 시스템 내의 다른 에이전트가 개입했는가? 전혀 알 수가 없습니다.

이러한 시스템을 구축하는 방법관찰하는 방법을 모두 이해하는 것이 중요한 이유도 바로 이 때문입니다. 나중에 옵저버빌리티를 추가할 수는 없습니다. 처음부터 아키텍처의 일부가 되어야 합니다.

옵저버빌리티 부족에 따르는 비용

구체적인 수치로 살펴보겠습니다. 적절한 옵저버빌리티 없이 에이전틱 시스템에 장애가 발생할 경우:

  • 평균해결시간(MTTR) 급증: 엔지니어는 본질적으로 확정할 수 없는 문제를 재현하는 데 수 시간 또는 수일을 소비합니다.
  • 토큰 비용 통제 불능: 에이전트 하나만 잘못 구성되어도 모르는 사이에 API 호출에 수백만 원이 낭비될 수 있습니다
  • 조용히 저하되는 품질: 에이전트 내부에서 일어나는 사항을 파악할 수 없기 때문에 환각이나 연쇄적인 오류를 놓치게 됩니다.
  • 보안 취약점 미탐지: 운영 환경에서 프롬프트 주입이나 개인식별정보 유출이 발생하지만 너무 늦게 이를 발견합니다.

앞서 언급했던 시간당 200만 달러라는 수치에는, 다운타임 외에도 저하된 사용자 경험으로 인한 수익 손실, 통제 불능 에이전트로 인해 낭비되는 컴퓨트 및 API 비용, 적절한 도구 없이 디버깅에 소요되는 엔지니어링 시간, 평판 훼손 등이 포함됩니다. 비용은 빠르게 증가하며, 에이전트가 실제로 무엇을 하고 있는지 파악하지 못하면 사후 대처에만 급급하게 됩니다.

 

학습 내용

이 가이드는 기존의 결정론적 소프트웨어에서 에이전틱 AI의 확률론적 세상으로 이동하려는 개발자를 위해 전략적 청사진을 제공합니다. 기술 환경이 빠르게 변화하고 있지만, 아키텍처를 둘러싼 핵심 과제는 변함이 없습니다. 추론 가능한 시스템을 어떻게 구축할 것인가, 그리고 이러한 시스템이 아무런 경고 없이 무너지지 않도록 어떻게 보장할 것인가? 하는 문제입니다.

다음 사항을 자세히 살펴봅니다.

  • 에이전틱으로의 전환: 스스로 생각하고 계획하는 시스템에서는 더 이상 "유닛 테스트"가 통하지 않는 이유를 알아봅니다.
  • 에이전트의 구조 분석: LLM, 도구, 검색, 메모리, 오케스트레이션 등 5가지 핵심 요소를 분석하고, 이들이 어떻게 상호 작용하여 "채팅"을 "실행"으로 전환하는지 살펴봅니다.
  • 가시성 부재 비용 정량화: 옵저버빌리티 전략 없이 에이전트를 배포할 때 발생하는 재무 및 운영 리스크를 살펴봅니다.

"확률적 간극" 식별: 기술적 실패(500 오류)와 논리적 오류(LLM의 도구 호출 환각) 간의 차이점을 파악하는 방법을 알아봅니다.

에이전틱 시스템 입문서

에이전틱 시스템을 구축하고 모니터링하는 방법에 대해 본격적으로 살펴보기 전에, 실제로 다루고자 하는 내용에 대해 모두가 동일하게 이해하고 있는지 짚고 넘어가겠습니다. "AI 에이전트", "에이전틱 워크플로우" 또는 "자율 시스템" 같은 용어를 자주 접하고, 이러한 개념들이 ChatGPT에 대한 일반적인 API 호출과 어떻게 다른지 궁금하시다면 이 섹션이 도움이 될 것입니다. 이미 기본 사항에 익숙하시다면 다음으로 건너뛰셔도 됩니다.

LLM 애플리케이션의 스펙트럼

LLM 애플리케이션은 단순한 텍스트 생성부터 자율 에이전트에 이르기까지 광범위하게 활용되며, 산업 전반에서 데이터를 처리, 분석 및 생성하는 방식을 혁신하고 있습니다. 제한적인 단일 작업 애플리케이션에서 복잡한 다단계 에이전틱 워크플로우로 그 범위가 확대되고 있습니다.

  • 콘텐츠 생성
    가장 단순한 수준에서 LLM은 콘텐츠를 생성하는 데 사용됩니다. 여기에는 블로그, 이메일, 스크립트 같은 텍스트 작성, 코드 생성 또는 기존 코드 디버깅 지원이 포함됩니다. 각 요청은 독립적이며, 시스템은 컨텍스트를 유지하거나 출력을 생성하는 것 이상의 조치를 취하지 않습니다.
  • 요약 및 분석
    다음 단계에서는 LLM을 사용해 기존 콘텐츠를 분석합니다. 여기에는 긴 문서 요약, 핵심 내용 추출, 텍스트 분류 또는 감정 분석 수행이 포함됩니다. 모델은 정보를 처리하지만 외부 시스템과 상호 작용하거나 의사 결정을 내리지는 않습니다.
  • 대화형 시스템
    대화형 시스템은 상호작용과 컨텍스트를 추가합니다. 이 시스템은 대화 기록을 유지하며 여러 차례에 걸쳐 응답을 제공합니다. 상호작용하는 것처럼 느껴지지만, 여전히 주로 텍스트를 생성할 뿐 자율적으로 작동하지는 않습니다.
  • 검색 증강 시스템
    검색 증강 시스템은 LLM을 외부 데이터 소스에 연결합니다. 모델의 학습 데이터에만 의존하는 것이 아니라, 런타임에 관련 문서나 레코드를 검색하여 컨텍스트로 사용합니다. 이를 통해 정확도를 높이고 시스템이 특정 도메인 질문에 답할 수 있게 되지만, 모델이 워크플로우를 소유하지는 않습니다.
  • 에이전틱 시스템
    에이전틱 시스템은 최종 단계에 해당합니다. 이러한 시스템은 목표 지향적이며 자율적으로 작동합니다. LLM은 다음에 수행할 작업을 결정하고, API나 데이터베이스와 같은 도구를 호출하며, 상태를 업데이트하고, 작업이 완료되거나 중단될 때까지 계속 실행됩니다. 

이 가이드는 에이전틱 시스템에 중점을 둡니다. 아키텍처, 신뢰성 및 옵저버빌리티와 관련하여 개발자가 가장 많은 문제에 직면하는 영역이기 때문입니다.

에이전틱 시스템이란?

레스토랑 어시스턴트를 예시로 들어 에이전틱 시스템을 살펴보겠습니다.

기존 대화형 시스템:

사용자: "오늘 저녁 7시에 4명이 식사할 수 있는 좋은 이탈리안 레스토랑을 찾아줘."
LLM: "근처에서 4명이 이용할 수 있는 이탈리안 레스토랑을 찾아보시는 것을 추천합니다."
상호작용이 종료됩니다.

 

에이전틱 시스템:

사용자: "오늘 저녁 7시에 4명이 식사할 수 있는 좋은 이탈리안 레스토랑을 찾아줘."
에이전트: 요리 종류, 평점, 인원수 및 시간에 맞는 레스토랑 옵션이 필요하다고 판단합니다.
에이전트: 레스토랑 검색 도구를 호출합니다
에이전트: 평점, 영업시간, 예약 지원 정보가 포함된 이탈리안 레스토랑 목록을 수신합니다.
에이전트: 평점을 기준으로 필터링하고 저녁 7시 이용 가능 여부를 확인합니다.
에이전트: "벨라스 이탈리안 비스트로(별점 4.5점)를 찾았습니다. 오후 7시에 4인용 테이블이 있습니다. 예약해 드릴까요?"
사용자: "예"
에이전트: 예약 도구을 호출하여 예약을 합니다.
에이전트: "완료했습니다! 예약 번호는 BR-2847입니다."
에이전트가 자율적으로 목표를 달성합니다.

 

주요 차이점은 무엇일까요? 기존의 LLM 기반 대화형 시스템에서는 시스템이 조언을 제공할 뿐 추가적인 조치는 취하지 않습니다. 반면 에이전틱 시스템은 루프 형태로 실행됩니다. 필요한 것을 결정하고, 조치를 취하며, 결과를 확인하고, 작업이 완료될 때까지 계속 진행합니다. LLM은 워크플로우 내에서 도구를 사용하여 실제 시스템과 상호 작용하고, 정보를 검색하며, 일어난 일에 대한 메모리를 유지할 수 있는 의사 결정자가 됩니다. 이것이 시스템을 “에이전틱”하게 만들어 주는 특징입니다.

에이전틱 시스템은 겉보기에는 마술을 부린 것처럼 느껴질 수 있지만, 내부를 보면 몇 가지 핵심 아키텍처 구성 요소가 연동되어 상위 수준 목표를 구체적인 작업으로 변환합니다. 각 구성 요소는 특정 역할을 수행하며, 안정성, 비용 또는 옵저버빌리티를 분석하려면 이러한 역할들을 이해할 필요가 있습니다.

핵심 아키텍처 구성 요소

에이전틱 시스템 구축과 관련된 핵심 아키텍처 구성 요소를 이해할 수 있도록, Anthropic이 설명한 증강 LLM 빌딩 블록에서 영감을 얻은 레스토랑 에이전트의 아키텍처를 살펴보겠습니다. 

레스토랑 에이전트 다이어그램

 

이 다이어그램은 레스토랑 에이전트의 개괄적인 구조를 보여줍니다. LLM은 의사 결정의 핵심으로서 중심에 자리하며, 오케스트레이션은 이를 둘러싼 실행 루프를 관리합니다. 이 루프를 통해 LLM은 목표를 달성하는 데 사용하는 세 가지 기능인 도구, 검색, 메모리에 액세스할 수 있습니다. 

각 구성 요소를 자세히 살펴보겠습니다.

LLM(언어 및 추론 계층)

모든 에이전틱 시스템의 중심에는 대규모 언어 모델(LLM)이 있습니다. 이는 시스템의 의사 결정 핵심으로, 사용자의 의도를 해석하고, 문제에 대해 추론하며, 필요한 조치를 결정하고, 나머지 워크플로우를 구동하는 결과물을 생성합니다. 예를 들어, 레스토랑 에이전트에게 사용자가 "오늘 밤 4명이 식사할 이탈리아 레스토랑을 찾아줘"라고 요청을 하면, LLM은 제약 조건을 분석하여 레스토랑 검색, 요리 종류별 필터링, 예약 가능 여부 확인, 옵션 제시 등의 다음 단계를 결정합니다.

대부분의 운영 시스템은 OpenAI(GPT-5.2, GPT-4), Anthropic 또는 Azure OpenAI에서 제공하는 호스팅 LLM API에 의존합니다. 데이터 통제나 배포 관련 제약으로 인해, 일부 조직은 Llama 또는 Mistral 같은 오픈소스 모델을 사용하기도 합니다. 

그러나 개발자 관점에서는 LLM이 할 수 없는 것을 이해하는 것이 중요합니다. LLM은 비즈니스 로직을 실행하거나, 정확성을 강제하거나, 일관된 동작을 보장하지 않습니다. 출력은 확률적이며, 동일한 입력이라도 다른 결정으로 이어질 수 있습니다. LLM은 또한 실제 시스템에 직접 접근할 수 없습니다. 주변 아키텍처 없이는 데이터를 가져오거나, 상태를 저장하거나, 조치를 취할 수 없습니다. 이러한 이유로, LLM은 시스템 자체가 아닌 추론 엔진으로 간주해야 합니다.

 

도구 

도구는 에이전틱 시스템이 현실 세계와 상호 작용하는 수단입니다. LLM이 무엇을 할지 결정한다면, 도구는 이러한 결정을 실제로 실행하는 역할을 합니다. 예를 들어 레스토랑 에이전트의 경우, 레스토랑 데이터를 가져오기 위한 API 호출, 메뉴를 검색하기 위한 데이터베이스 쿼리, 예약 시스템에 대한 내부 서비스 호출, 결제 작업 또는 기타 실행 가능한 코드 등이 도구가 될 수 있습니다. 이 계층이 없다면 에이전트는 추론할 수는 있지만 행동할 수는 없습니다.

실제 환경에서 도구는 명확한 이름, 설명 및 입력 스키마를 갖춘 잘 정의된 함수로 LLM에 노출됩니다. 오케스트레이션 계층은 이러한 도구를 모델에 제공하며, 모델은 달성하려는 목표를 기반으로 사용할 도구를 선택합니다. 선택이 완료되면 도구 실행 계층이 기본 코드를 실행하고 그 결과를 에이전트의 컨텍스트로 다시 반환합니다. 결과물은 워크플로우를 종료하거나 추가적인 추론 단계를 위한 입력이 될 수 있습니다.

GPT-4나 Claude 같은 최신 LLM은 네이티브 함수 호출을 지원하므로 이러한 상호작용이 직관적입니다. 중요한 차이점은 모델이 아니라 도구가 작업을 수행한다는 것입니다. 이러한 역할 분담은 실행을 예측 가능하게 유지하며, 실제 시스템이 프로그래밍 가능한 통제 하에 유지되도록 합니다.

 

검색

시스템이 비정형 데이터에서 추가적인 컨텍스트를 필요로 할 때 검색이 사용됩니다. 여기에는 보통 리뷰나 기술 정보 같은 자유 형식 텍스트가 포함됩니다. 예를 들어, 레스토랑 에이전트는 이를 활용하여 "로맨틱한 분위기"나 "단체 모임에 적합" 같은 특성을 기준으로 레스토랑 리뷰를 검색하고, 설명을 바탕으로 메뉴를 찾으며, 특정 레스토랑이 다른 레스토랑보다 선호되는 이유를 설명하거나, 관련된 과거 대화를 불러올 수 있습니다. 검색 기능은 에이전트가 말뭉치를 탐색하고, 관련 스니펫을 가져와 추론이나 설명을 위한 문맥으로 포함할 수 있도록 합니다. 검색 증강 생성(RAG)이라 불리는 이러한 패턴은 실제 데이터에 근거하여 응답을 제공합니다. 검색된 콘텐츠는 의사결정을 지원하지만, 모든 요청에 필수적인 것은 아니며 데이터베이스나 API 같은 신뢰할 수 있는 데이터 소스를 대체해서는 안 됩니다.

 

메모리

메모리를 통해 에이전트는 단계 및 상호작용 전반에서 연속성을 유지합니다. 사용자 선호도, 이전 결정, 중간 결과 같은 관련 컨텍스트를 캡처하기 때문에 시스템이 모델을 호출할 때마다 처음부터 다시 시작하지 않아도 됩니다.

메모리는 일반적으로 LLM 외부에 존재하며 필요할 때 프롬프트에 주입됩니다. 단기 메모리에는 보통 호출 간에 보존되어야 하는 최근 대화 기록이나 최근 추론 단계가 포함됩니다. 장기 메모리는 세션 간에 유지되어야 하는 사용자 환경 설정, 과거 상호작용 또는 도메인 지식을 저장할 수 있습니다. 이러한 메모리는 정확한 회상이 필요한지, 아니면 의미론적 회상이 필요한지에 따라 데이터베이스, 키/값 저장소 또는 벡터 데이터베이스에 저장됩니다. 오케스트레이션 계층은 컨텍스트 크기, 비용, 유용성 간에 균형을 맞추어 어떤 메모리가 관련이 있고 얼마나 포함할지를 결정합니다.

실제 환경에서 에이전틱 시스템은 세심한 메모리 관리가 필요합니다. 에이전트가 대화 도중 중요한 문맥을 잊어버려 혼란스러운 응답을 제공하거나 너무 많은 기록이 누적되어 실행 속도가 느려지고 비용이 많이 발생할 수도 있기 때문입니다. 따라서 안정적인 에이전틱 시스템을 구축할 때 메모리를 효과적으로 관리하는 것은 까다로운 일입니다.

 

오케스트레이션 계층 

오케스트레이션 계층은 LLM을 에이전트로 만들어 줍니다. 에이전틱 시스템을 위한 운영 시스템이라고 생각하면 됩니다. LLM과 시스템의 나머지 부분 사이에 위치하여 의사 결정이 이루어지고, 실행되며, 서로 연결되는 방식을 제어합니다. 오케스트레이션 계층은 프롬프트를 구성하고, 컨텍스트를 주입하며, 모델에 도구를 제공하고, 실행 순서를 제어하는 역할을 담당합니다. LLM이 추론하는 동안, 오케스트레이션은 제어 흐름을 관리합니다.

대부분의 에이전틱 시스템은 LangChainLlamaIndexAutoGen 등과 같은 오케스트레이션 프레임워크를 사용합니다. 이러한 프레임워크는 에이전트, 도구, 메모리 및 워크플로우에 대한 추상화를 제공하고, 상용구 코드를 줄여 개발 속도를 높입니다.

운영의 관점에서 볼 때, 많은 실질적인 문제가 여기에서 비롯됩니다. 이 계층은 의도가 실행으로 전환되는 곳입니다. 컨텍스트, 순서 또는 도구 가용성의 작은 변화가 다른 실행 경로로 이어질 수 있습니다. 또한, 잘못 구성된 프롬프트, 컨텍스트 누락 또는 잘못 정의된 도구 스키마로 인해, 모델이 유효해 보이는 응답을 반환하지만 잘못된 의사 결정을 내릴 수 있습니다. 실패는 기술적이라기보다는 논리적인 문제라 기존 오류 처리를 우회하는 경우가 많기 때문에 감지하기 어렵습니다. 그래서 이 계층에서는 옵저버빌리티가 반드시 필요합니다.

이러한 요소들은 에이전틱 시스템의 토대를 형성합니다. LLM은 추론을 제공하고, 오케스트레이션은 흐름을 제어하며, 도구는 작업을 실행하고, 검색은 필요할 때 컨텍스트를 추가하며, 메모리는 단계 전반에 걸쳐 진행 상황을 유지합니다. 모든 에이전틱 시스템은 규모나 도메인에 관계없이 이 구성 요소들의 조합으로 구축됩니다.

5가지 아키텍처 핵심 요소를 완벽히 숙지하면, AI를 아무것도 볼 수 없는 '블랙박스'로 간주하지 않고 관리 및 관찰 가능한 시스템으로 다룰 수 있습니다. 이제 강력할 뿐만 아니라 예측 가능한 에이전틱 워크플로우를 설계하는 데 필요한 멘탈 모델을 갖추었습니다.