기업용 AI Agent는 어떻게 설계해야 할까

LLM이 대중화되면서 많은 조직이 사내 챗봇 혹은 AI Agent를 만들고자 한다. 하지만 막상 프로젝트를 시작해 보면, 단순히 GPT API를 호출하는 것만으로는 기업 환경에서 요구되는 신뢰성과 안정성을 만족시키기 어렵다는 걸 곧 깨닫게 된다.

이 글에서는 특정 회사나 도메인에 국한되지 않고, 기업용 AI Agent를 실제 운영 가능한 수준으로 설계하기 위해 고려해야 할 아키텍처와 개발 전략을 정리해본다.

왜 LLM 단독 구조로는 부족할까?

LLM은 매우 강력하지만, 기업 환경에서는 몇 가지 치명적인 한계가 있다.

• 사내 문서나 내부 데이터를 모른다.
• 근거 없는 답변, 즉 hallucination이 발생할 수 있다.
• 응답 품질을 제어하기 어렵다.
• 호출 비용과 응답 시간이 무시할 수 없다.

그래서 대부분의 기업용 AI Agent는 RAG, 즉 Retrieval-Augmented Generation 구조를 기반으로 설계된다.

RAG의 핵심은 검색이 아니라 설계다

RAG는 단순히 문서를 검색해서 LLM에 넣는 개념이 아니다. 실제로는 데이터 처리부터 검색 전략까지 꽤 많은 설계 포인트가 있다.

1. Corpus 구성: AI가 참고할 지식의 범위

RAG의 출발점은 corpus, 즉 AI Agent가 참고할 전체 문서 집합이다. 일반적으로 매뉴얼, 기술 문서, 보고서, 정책 문서가 여기에 포함된다.

이 corpus의 품질이 곧 AI Agent의 품질이다. 정리되지 않은 문서를 그대로 넣는다면, 결과 역시 정리되지 않는다.

2. Chunking: 문서를 그대로 쓰지 않는 이유

문서는 그대로 검색하지 않는다. 의미 단위로 쪼개는 chunking 과정을 거친다.

• chunk가 너무 크면 검색 정확도가 떨어진다.
• chunk가 너무 작으면 문맥이 끊긴다.

그래서 실제로는 chunk size와 overlap을 여러 번 실험하며 조정한다. 이 단계는 자동화 대상이라기보다 튜닝 대상에 가깝다.

3. Embedding과 Vector DB

Chunk로 나뉜 문서는 embedding 모델을 통해 벡터로 변환되고, 이 벡터들은 FAISS나 Pinecone 같은 vector database에 저장된다.

여기서 중요한 점은 embedding 모델을 바꾸면 전체 corpus를 다시 embedding 해야 한다는 것이다. 그래서 embedding 모델 선택은 초기에 신중해야 한다.

모든 질문에 RAG를 쓰지 않는다

많은 초기 프로젝트가 하는 실수가 있다. 모든 질문을 RAG로 처리하는 것이다. 이렇게 하면 응답이 느려지고, 비용이 늘어나고, 오히려 품질이 떨어질 수 있다.

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

질문 경로 분리 예시

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

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

이 분기만 잘해도 latency와 비용이 눈에 띄게 줄어든다.

Prompt는 UI가 아니라 로직이다

기업용 AI Agent에서 prompt는 단순한 문장이 아니다. LLM을 제어하는 백엔드 로직에 가깝다.

보통 system prompt에서는 다음을 명확히 한다.

• 역할 정의
• 출력 형식 제한
• 근거 없는 추측 금지
• 문서 기반 답변 강제, 즉 grounding

또한 temperature와 top-p를 낮게 설정해 창의성보다 일관성과 안정성을 우선한다. 기업용 AI는 답변이 매번 새롭기보다, 같은 조건에서 예측 가능한 방식으로 동작하는 것이 더 중요하다.

AI Agent는 답변기가 아니다

AI Agent는 단순히 텍스트를 생성하는 존재가 아니다. 문제 해결을 위해 여러 단계를 수행하는 구조다.

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

1. 사용자 의도 분석
2. 정보 필요성 판단
3. RAG 또는 Tool 호출
4. 결과 종합 및 응답 생성

LangChain이나 Semantic Kernel은 이러한 흐름을 orchestration하기 위한 도구일 뿐, 핵심은 설계 자체다. 도구를 먼저 고르는 것보다 어떤 판단 흐름이 필요한지 정의하는 일이 먼저다.

운영 환경에서 가장 중요한 것: 속도와 비용

개발 단계에서는 잘 느껴지지 않지만, 운영 단계에서는 latency와 cost가 모든 의사결정을 지배한다.

이를 위해 몇 가지 전략을 사용한다.

1. 불필요한 RAG 제거

질문 경로를 분리해 근거 문서가 필요하지 않은 요청은 RAG 파이프라인을 거치지 않도록 한다.

2. Top-k 및 context 길이 제한

검색 결과를 많이 넣는다고 품질이 항상 좋아지지는 않는다. 필요한 문서만 LLM에 전달해야 응답 품질과 비용을 동시에 관리할 수 있다.

3. 모델 분리 전략

간단한 요청에 고급 모델을 사용하는 것은 운영 비용을 빠르게 증가시킨다. 분류, 요약, 최종 답변 생성처럼 작업 성격에 따라 모델을 분리하는 전략이 필요하다.

캐싱은 선택이 아니라 필수다

RAG 구조에서 비용과 지연이 큰 구간은 명확하다. embedding 생성과 vector DB 검색이다.

그래서 캐싱도 보통 2단계로 설계한다.

1. Embedding 캐싱

동일 질문이 들어오면 동일 embedding을 재사용해 embedding API 호출 횟수를 줄인다.

2. 검색 결과 캐싱

동일 embedding 또는 유사한 질의에 대해 검색 결과를 재사용하면 vector DB 부하와 latency를 줄일 수 있다.

여기에 corpus 변경 시점을 관리하기 위한 index versioning을 적용하면 운영 안정성도 확보할 수 있다.

정리하며

기업용 AI Agent 구축은 다음 요소들이 함께 맞물릴 때 실제 업무에 쓸 수 있는 수준으로 올라간다.

• RAG 구조
• 질문 경로 분리
• Prompt 제어
• 캐싱과 최적화
• 운영 관점의 의사결정

이 글이 도움이 될 분들

• 기업용 AI/LLM 프로젝트를 준비하는 개발자
• AI Agent 아키텍처를 고민하는 팀 리드
• 챗봇을 넘어 업무 시스템으로 확장하고 싶은 조직