실무에서 써본 AI 에이전트 & RAG 아키텍처: 삽질 줄이는 핵심 설계 팁

“사용자 질문에 맞춰 회사 DB를 조회하고, 결과를 바탕으로 이메일까지 대신 발송해 주는 AI를 만들 수 있을까?”

LLM(대형 언어 모델)이 대중화되면서 개발자들의 관심은 단순한 챗봇 구현에서 한 걸음 더 나아가, 도구를 쥐여주고 스스로 판단해 일을 끝마치게 만드는 **‘AI 에이전트(Autonomous Agent)‘**로 빠르게 옮겨갔습니다.

하지만 막상 프로덕션 환경에 에이전트를 도입해 보면, 모델이 엉뚱한 거짓말(Hallucination)을 하거나, 토큰 요금이 천정부지로 치솟고, 툴 호출(Tool Calling) 과정에서 런타임 에러가 쏟아지는 현실적인 벽에 부딪히게 됩니다.

이번 글에서는 LLM 기반 애플리케이션과 RAG, 멀티 에이전트 시스템을 구축하면서 몸으로 부딪히며 깨달은 핵심 아키텍처 패턴과 실무 팁들을 정리해 보았습니다.

1. LLM의 기본 성질: 확률적 다음 토큰 예측

에이전트를 제대로 다루려면 모델의 본질을 잊지 말아야 합니다. LLM은 논리적으로 ‘생각’하는 뇌가 아니라, **“지금까지 주어진 텍스트 뒤에 올 확률이 가장 높은 다음 단어(토큰)를 통계적으로 찍어내는 기계”**입니다.

Temperature (온도): 다음 토큰의 확률 분포를 얼마나 흩뿌릴지 결정합니다.
- 0.0 ~ 0.2: 거의 항상 1등 확률 토큰만 고릅니다. 코드 작성, JSON 규격 출력, SQL 쿼리 생성처럼 정답이 명확해야 하는 에이전트 작업에서는 무조건 0으로 두는 것이 진리입니다.
- 0.7 ~ 1.0: 창의적인 글쓰기나 아이디어 브레인스토밍에 적합합니다.
Top-P (Nucleus Sampling): 상위 누적 확률 P(보통 0.9) 안에 드는 단어들만 후보군으로 남기고 나머지를 버립니다.

복잡한 시스템 프롬프트와 문서가 들어가면 첫 글자가 찍히기까지 수 초씩 걸리는(TTFT: Time to First Token) 병목이 생깁니다.

스트리밍(Streaming) 필수 적용: 전체 답변 생성이 끝날 때까지 기다리지 말고, 토큰이 생성되는 즉시 클라이언트로 SSE(Server-Sent Events)를 통해 밀어 넣어주세요. 사용자의 체감 대기 시간이 드라마틱하게 줄어듭니다.
프롬프트 캐싱(Prompt Caching) 활용: Anthropic Claude나 OpenAI 최신 모델들은 변하지 않는 앞부분 텍스트(공통 가이드라인, 방대한 API 스펙 등)를 서버에 캐싱해 둡니다. 동일한 컨텍스트를 재사용하면 비용이 최대 90% 저렴해지고 응답 속도도 2~4배 빨라집니다.
보안과 비용 잡는 로컬 추론 (Ollama): 사내 민감 데이터나 단순 분류 태스크는 외부 API 대신 사내 서버에 Ollama로 Llama 3나 Mistral을 띄워 처리하는 하이브리드 구성이 매우 훌륭한 선택지입니다.

모델에게 우리 서비스의 DB 조회 함수나 날씨 API 명세를 JSON 스키마로 전달하면, 모델은 직접 실행하는 대신 **“이 함수를 이런 인자값으로 실행해 줘”**라는 구조화된 JSON 메시지를 개발자에게 반환합니다.

// LLM이 반환하는 도구 호출 메시지 예시
{
  "name": "query_user_account",
  "arguments": {
    "account_id": "acc_9281",
    "include_history": true
  }
}

개발자 서버는 이 JSON을 파싱해서 실제 DB를 조회하고, 그 결과를 다시 모델의 다음 입력으로 찔러 넣어줍니다. 이 왕복 사이클이 바로 에이전트가 외부 세계와 상호작용하는 원리입니다.

외부 지식을 모델에 학습시키고 싶을 때 많이들 고민하는 선택지입니다.

구분	RAG (Retrieval-Augmented Generation)	Fine-Tuning (미세 조정)
작동 방식	관련 문서를 DB에서 검색해 프롬프트에 동적으로 붙여줌	모델 가중치 자체를 학습 데이터로 업데이트함
최적 시나리오	실시간 뉴스, 자주 바뀌는 사내 규정, 고객 데이터	특화된 말투/어조 통일, 엄격한 코드 스타일 강제
비용 & 난이도	빠르고 저렴함, 출처 추적(Citation) 가능	데이터셋 준비가 어렵고 비용이 큼

결론부터 말씀드리면, 95%의 비즈니스 유즈케이스에서는 RAG가 정답입니다. 파인튜닝을 한다고 모델이 최신 지식을 정확하게 외우는 것이 아닙니다. 문서를 검색해서 모델의 눈앞에 쥐여주는 RAG가 할루시네이션 방지와 최신성 유지에 압도적으로 유리합니다.

에이전트가 그럴싸하게 지어내는 거짓말을 막기 위한 안전장치들입니다.

접지(Grounding) 프롬프트: “제공된 문서에 없는 내용은 절대로 지어내지 말고 모른다고 답해”라는 규칙을 시스템 프롬프트에 박아두세요.
자가 검증(Double-Check) 루프: 생성된 답변을 원본 문서와 비교해서 “제공된 레퍼런스에 사실이 아닌 내용이 포함되어 있는가?”를 별도의 빠른 모델(예: Haiku, GPT-4o-mini)로 1차 필터링하는 검증 노드를 둡니다.

하나의 프롬프트로 기획, 코드 작성, 테스트, 배포를 다 시키면 중간에 100% 삼천포로 빠집니다.

graph LR
    A[사용자 요청] --> B[기획 에이전트]
    B --> C[개발 에이전트]
    C --> D[코드 리뷰 노드]
    D -- 반려 --> C
    D -- 승인 --> E[배포 완료]

역할 분담: 기획 전담, 코딩 전담, 검증 전담으로 에이전트를 잘게 쪼개세요.
상태 머신 (LangGraph): 각 에이전트가 공유하는 상태(State) 객체를 정의하고, 노드(Node)와 조건부 분기(Edge)로 흐름을 제어합니다.
Human-in-the-loop (인간 개입): 돈이 나가거나 파일이 영구 삭제되는 치명적인 액션 직전에는 반드시 사람의 ‘승인(Approve)’ 버튼을 누르게 일시 정지(Suspend)시키는 안전장치를 걸어두어야 시스템이 폭주하지 않습니다.

검색 유입이 많은 핵심 글부터 이어서 보세요.