Architecture

기업용 AI Agent 아키텍처 개요

왜 단순 챗봇으로는 부족한가, 그리고 어떻게 설계해야 하는가

Architecture Overview Control first
Input
사용자 입력질문, 요청, 업무 맥락을 받습니다.
Route
의도 분석 / 분기RAG, 일반 생성, Tool 호출 경로를 선택합니다.
Generate
LLM 생성근거와 제어 규칙을 포함해 답변을 생성합니다.
Control
응답 제어 / 출력형식, 근거, 비용, 속도를 운영 기준으로 관리합니다.
이 글의 핵심
  • 기업용 AI Agent는 개인용 챗봇처럼 대화만 잘하는 시스템이 아니라 업무 맥락과 근거를 통제하는 시스템이다.
  • 기본 구조는 의도 분석, RAG 또는 일반 생성 경로, LLM 생성, 응답 제어로 나뉜다.
  • 좋은 아키텍처는 왜 답변이 나왔는지, 언제 비용이 늘어나는지 설명할 수 있어야 한다.

“AI Agent를 도입해보자”라는 이야기는 이제 낯설지 않다. 하지만 실제 프로젝트를 진행해보면, 많은 조직이 챗봇 수준을 넘지 못한 채 멈추는 경우를 자주 보게 된다.

문제는 모델이 아니라 아키텍처다. 이 글에서는 기업 환경에서 실제로 동작 가능한 AI Agent 아키텍처의 기본 구조와 설계 원칙을 정리해본다.

기업용 AI Agent는 개인용 챗봇과 무엇이 다른가

개인용 챗봇은 대화를 잘하는 것이 목적이다. 반면 기업용 AI Agent는 목적이 훨씬 명확하다.

  • 사내 데이터 기반의 정확한 답변
  • 업무 맥락을 이해한 결과
  • 예측 가능한 응답 품질
  • 운영 가능한 비용과 속도

이 차이 때문에, 기업용 AI Agent는 LLM 단독 구조로는 거의 항상 한계에 부딪힌다.

기업용 AI Agent의 기본 아키텍처 개요

기업용 AI Agent는 보통 다음과 같은 레이어로 구성된다.

  1. 사용자 입력
  2. 질문 의도 분석 / 분기
  3. RAG 또는 일반 생성 경로
  4. LLM 생성
  5. 응답 제어 및 출력

핵심은 LLM을 어디에, 언제, 어떻게 쓰느냐를 의도적으로 설계한다는 점이다.

RAG는 선택이 아니라 기본 전제다

기업 환경에서 LLM이 단독으로 답변을 생성하면 다음 문제가 발생한다.

  • 사내 문서를 모른다.
  • 근거 없는 답변, 즉 hallucination이 발생한다.
  • 답변 품질을 통제하기 어렵다.

그래서 대부분의 기업용 AI Agent는 RAG, 즉 Retrieval-Augmented Generation 구조를 기본 전제로 삼는다.

RAG의 기본 흐름

  1. 사내 문서를 corpus로 구성
  2. 문서를 chunk 단위로 분할
  3. embedding을 생성해 vector DB에 저장
  4. 사용자 질문을 embedding으로 변환
  5. 유사 문서를 검색, 즉 top-k retrieval 수행
  6. 검색된 문서를 LLM 입력에 포함
LLM이 추측하지 않고, 근거를 보고 답하게 만드는 것이 RAG 구조의 핵심 목적이다.

모든 질문에 RAG를 쓰면 안 되는 이유

초기 프로젝트에서 흔히 하는 실수가 있다. 모든 질문을 무조건 RAG로 처리하는 것이다. 이 방식은 금방 한계에 도달한다.

  • 응답 속도가 느려진다.
  • 비용이 급격히 증가한다.
  • 단순한 질문에도 과한 검색이 붙는다.

그래서 실제 운영 환경에서는 질문 유형에 따라 처리 경로를 분리한다.

질문 경로 분리 예시

문서 근거가 필요한 질문은 RAG 경로로 보낸다. 예를 들어 “사내 규정 기준 알려줘”, “이전 프로젝트 문서 내용 설명해줘” 같은 질문이다.

생성 중심 질문은 일반 생성 경로가 더 적합하다. “이 문단 요약해줘”, “보고서 형식으로 다시 써줘” 같은 요청이 여기에 해당한다.

이 분기 구조만으로도 latency와 비용이 크게 개선된다.

Prompt는 UI가 아니라 제어 로직이다

기업용 AI Agent에서 prompt는 단순한 문장이 아니다. LLM의 행동을 제어하는 로직 계층에 가깝다.

보통 system prompt에는 다음 요소가 포함된다.

  • 역할, 즉 Role 명시
  • JSON 같은 출력 형식 제한
  • 근거 없는 추측 금지
  • 제공된 문서 기반 답변 강제, 즉 grounding

이러한 prompt 설계 없이는, 같은 모델이라도 응답 품질은 크게 흔들린다.

AI Agent는 답변기가 아니다

기업용 AI Agent는 단순히 질문에 답하는 존재가 아니다. 문제를 해결하기 위해 여러 단계를 수행하는 구조를 가진다.

일반적인 Agent 흐름은 다음과 같다.

  1. 사용자 의도 분석
  2. 정보 필요성 판단
  3. 문서 검색 또는 외부 Tool 호출
  4. 결과 종합
  5. 최종 응답 생성

LangChain이나 Semantic Kernel 같은 프레임워크는 이 흐름을 구현하기 위한 도구일 뿐, 핵심은 어떤 단계가 필요한지를 설계하는 것이다.

운영 환경에서 반드시 고려해야 할 두 가지

개발 단계에서는 잘 보이지 않지만, 운영 단계에서는 모든 의사결정이 응답 속도와 비용으로 수렴한다.

이를 위해 다음과 같은 전략이 필요하다.

  • 질문 경로 분리로 불필요한 RAG 제거
  • top-k 및 context 길이 제한
  • 요청 난이도에 따른 모델 분리
  • embedding 및 검색 결과 캐싱

특히 캐싱은 선택이 아니라 필수 설계 요소에 가깝다.

기업용 AI Agent 아키텍처의 핵심은 통제 가능성

정리해보면, 기업용 AI Agent 아키텍처의 핵심은 기술 그 자체가 아니라 다음 질문에 대한 답이다.

  • 이 답변은 왜 이렇게 나왔는가?
  • 언제 비용이 늘어나는가?
  • 잘못된 답변을 어떻게 막는가?
  • 운영 환경에서 예측 가능한가?

이 질문에 답할 수 있는 구조를 만들 때, 비로소 AI Agent는 실제 업무에 사용할 수 있는 시스템이 된다.

마치며

기업용 AI Agent는 LLM을 잘 쓰는 문제라기보다 LLM을 통제하는 구조를 설계하는 문제에 가깝다.

아키텍처, 데이터, 프롬프트, 운영 전략이 함께 설계될 때 AI Agent는 단순한 데모를 넘어 조직의 실제 생산성을 높이는 도구가 된다.