RAG, 에이전트, 프롬프트: AI 프로젝트 시작을 위한 기술 스택

AI 프로젝트, 특히 LLM(거대 언어 모델)을 활용한 서비스를 만들 때 고려해야 할 기술들을 정리한 가이드입니다. 각 기술의 개념을 이해하고, 자신의 프로젝트 규모와 목적에 맞는 최적의 조합을 찾아보세요.

 

---

1. RAG (Retrieval-Augmented Generation)

RAG는 LLM이 알지 못하는 최신 정보나 특정 분야의 전문 지식(예: 우리 학교 학사 규정, 특정 게임 공략집)을 외부 문서에서 찾아와(Retrieval), 그 내용을 바탕으로 답변을 생성(Generation)하는 기술입니다. LLM의 환각(Hallucination)을 줄이고 답변의 신뢰도를 높이는 가장 핵심적인 기술이죠.

1) 플랫폼

RAG 파이프라인(데이터 준비 → 검색 → 생성)을 쉽게 만들도록 도와주는 도구들입니다.

• Makebot LLM Builder: 기업 내부 문서와 LLM을 연결해 빠르게 엔터프라이즈 챗봇을 구축 가능. → 실무 활용도 높음 (예: 고객센터 자동화).
• Botgrade: 모델 답변을 자동 평가해 품질 관리. → 사람이 매번 수작업 검증할 필요를 줄여줌.
• InstructRAG: 명령 기반 검색·응답. → FAQ, 지식베이스 질의응답에 적합.
• ReaRAG: 실시간 검색 + 순환 추론 결합. → 최신 뉴스 요약 같은 실시간성 요구 서비스에 유리.
• Haystack: 오픈소스·대규모 문서 처리에 최적화. → 연구·프로토타입 환경에 적합.
• RAGFlow: 시각적 파이프라인 UI 제공. → 비개발자도 손쉽게 조합 가능.
• txtai: 검색·분류·추천 통합 플랫폼. → 텍스트와 비정형 데이터 동시 활용.
• LlamaIndex: 다양한 데이터 타입 지원, 맞춤 검색에 강점.
• Verba: 캐싱·하이브리드 검색 강점. → 빠른 응답 필요한 챗봇에 적합.

2) 임베딩 모델

'임베딩'은 텍스트(단어, 문장)를 컴퓨터가 이해할 수 있는 숫자들의 배열, 즉 **벡터(Vector)**로 바꾸는 과정입니다. 좋은 임베딩 모델은 '강아지'와 '멍멍이'처럼 의미가 비슷한 단어들을 벡터 공간에서 가까운 위치에 둡니다.

• OpenAI (text-embedding-3): 영어 중심, 저비용·고차원·빠른 추론.
  • large(1536차원): 긴 문서·복잡한 맥락 반영 유리.
  • small(512차원): 속도·비용 효율적, FAQ 검색 적합.
• Cohere (v3.0): 다국어 강점, 의미 밀집 표현 최적화
• Hugging Face (BGE/E5/Instructor/MiniLM/MPNet) : 오픈소스 모델의 성지입니다. 특히 한국어 프로젝트를 할 때는 ko-sroberta-multitask 같은 한국어 특화 모델을 무료로 다운받아 사용할 수 있어 매우 유용합니다.
• Mistral (mistral-embed/Codestral): 1024차원·다국어·코드 임베딩에 특화·빠른 추론.
• VoyageAI (voyage-3/large/lite): 32K 컨텍스트·초저가·한국어 포함 다국어·작은 벡터로 효율적 검색.
• Google Gemini-Embedding: SOTA급·68점대 MTEB 다국어 성능·8192 토큰·범용성.
• Jina Embeddings v3: 570M 파라미터·8192 토큰·최첨단 다국어 임베딩·오픈소스.
• Amazon Titan: 멀티모달(텍스트+이미지)·클라우드 특화.

3) 벡터 차원

임베딩 모델이 문장을 몇 개의 숫자로 표현하는지를 의미합니다. (예: 1536차원 = 1536개의 실수로 이루어진 배열)

• 차원이 높을수록: 데이터의 세부적인 정보와 특징을 더 잘 반영할 수 있습니다. 예를 들어, 긴 문장이나 복잡한 이미지를 잘 표현하려면 더 높은 차원의 임베딩이 필요합니다.
• 차원이 낮을수록: 연산량이 줄어들고, 메모리 사용량이 적어집니다. 하지만 차원을 너무 낮추면 중요한 정보를 놓칠 수 있습니다.
• 결론: 일반적인 문서 검색은 768 ~ 1024차원으로도 충분하며, 사용하는 임베딩 모델이 정해주는 차원을 따르는 것이 일반적입니다.
• 예: 짧은 FAQ 검색 → 512차원, 논문 검색 → 1536차원.

4) 검색 방식

사용자 질문과 가장 관련 있는 문서를 어떻게 찾을지에 대한 방법론입니다.

• BM25 (Sparse Retrieval): 단어 빈도 기반 전통 검색, 빠르고 정확한 키워드 매칭에 강점. → 법률·규정 검색 적합.
• DPR (Dense Retrieval) : 임베딩된 벡터 간의 의미적 유사도(코사인 유사도 등)를 계산합니다. 고전적인 dense 모델, 아직도 baseline으로 쓰임.
• Contriever (Dense Embedding): 최신 self-supervised dense 모델, 의미 기반 검색에 강점.
• Hybrid (Dense + Sparse): BM25와 Dense Embedding 결합, 키워드 정확성과 의미 유사도를 동시에 확보. → FAQ 챗봇, 문서 검색 등에서 가장 널리 사용.

<aside> 💡

[어떤 방식을 선택할까?]

• 법률 조문, 사내 규정 검색: 키워드가 정확히 일치해야 하므로 BM25가 유리합니다.
• "요즘 유행하는 패션 스타일 알려줘": 사용자의 의도를 파악해야 하므로 Dense 검색이 적합합니다.
• 대부분의 Q&A 챗봇: 두 가지 장점을 모두 취하는 Hybrid Search를 사용하는 것이 가장 안정적입니다. </aside>

5) 백터 인덱스 / 근사검색

수백만 개의 문서 벡터 중에서 내 질문 벡터와 가장 가까운 벡터를 어떻게 '효율적으로' 찾을지에 대한 기술입니다.

• Flat (Brute Force): 모든 벡터와 일일이 거리를 계산하는 가장 무식하고 정확한 방법. 데이터가 수천 개 이하라면 쓸 수 있지만, 그 이상이면 속도가 너무 느려져 현실적으로 사용하기 어렵습니다.
• IVF (Inverted File Index): 벡터들을 여러 개의 '방(클러스터)'으로 미리 나눠놓고, 질문 벡터가 들어오면 가장 가까운 방 몇 개만 뒤지는 방식입니다.
• HNSW (Hierarchical Navigable Small World Graph): 벡터들을 '친구의 친구는 친구' 같은 소셜 네트워크 형태의 그래프로 연결해, 가장 빠른 길을 따라가며 근접 이웃을 찾는 방식입니다. 검색 속도가 매우 빨라 현재 가장 널리 쓰이는 인덱스 방식 중 하나입니다.
• PQ (Product Quantization): 벡터를 여러 조각으로 나눠 압축하여 메모리 사용량을 획기적으로 줄이는 기술입니다. 약간의 정확도 손실을 감수하고 메모리 효율을 극대화할 때 사용합니다.

6) 인덱스/벡터 DB

• Chroma, Faiss: 파일 기반으로 동작하여 별도의 서버 설치 없이 가볍게 시작할 수 있습니다. 개인 프로젝트나小규모 테스트에 매우 적합합니다. Faiss는 Facebook(Meta)에서 개발했으며, 성능이 매우 뛰어납니다.
  • Chroma: Python 친화적, 소규모/중규모 RAG 환경에 최적화.
  • Faiss: Facebook 오픈소스, 다양한 인덱스 옵션 지원, 대규모 벡터 검색에 특화.
• Milvus, Qdrant, Weaviate, Pinecone: 대규모 서비스를 위한 서버-클라이언트 구조의 벡터 DB입니다. 실시간 데이터 추가/삭제, 필터링, 확장성 등 운영에 필요한 다양한 기능을 제공합니다.
  • Pinecone: 클라우드 기반 벡터 DB, 자동 스케일링과 관리형 인프라 제공.
  • Milvus: 오픈소스 고성능 벡터 DB, GPU 지원으로 대규모 검색 최적화.
  • Qdrant: 실시간 벡터 검색에 강점, ML 모델과 쉽게 통합 가능.
  • Weaviate: GraphQL 지원, 메타데이터 기반 필터링과 시맨틱 검색 가능.

7) Chunking 전략

긴 문서를 LLM에 한 번에 넣을 수 없기 때문에, 의미 있는 단위로 잘게 쪼개는 과정입니다. RAG 성능에 가장 큰 영향을 미치는 요소 중 하나입니다.

• Fixed-length: 512 토큰(대략 250~300자) 같은 고정된 길이로 무조건 자르는 가장 간단한 방식.
• Sliding window (Overlap): 문장의 중간이 잘리는 것을 방지하기 위해 Chunk를 나눌 때 이전 Chunk의 끝부분 일부(e.g., 50 토큰)를 다음 Chunk의 시작 부분에 포함시키는 방식입니다.
• Semantic chunking: 문단, 문장 등 의미가 완결되는 단위로 자르거나, 임베딩 벡터의 유사도를 기반으로 의미적 경계를 찾아 자르는 고급 방식입니다.
• Hierarchical chunking: 큰 단위 → 작은 단위 순차 검색 (multi-stage retrieval)

8) Re-ranking

초기 검색(Retrieval) 단계에서 찾아온 여러 개의 문서(e.g., 상위 20개)를 LLM에게 넘기기 전에, 질문과 정말로 관련이 높은 문서만 추려내 순서를 다시 매기는 과정입니다. LLM에 들어가는 정보의 질을 높여 최종 답변의 품질을 향상시킵니다.

• Cross-encoder (e.g. msmarco-distilbert, bge-reranker) : 검색된 각 (질문, 문서) 쌍을 모델에 함께 입력하여 관련도를 훨씬 정밀하게 계산하는 방식입니다. 속도는 느리지만 정확도가 높습니다.
• LLM re-ranker (GPT-4, Claude로 후보 문서 다시 평가) : GPT-4 같은 고성능 LLM에게 직접 후보 문서들을 보여주고, "이 질문에 답하는 데 가장 중요한 순서대로 3개만 골라줘"라고 요청하는 방식입니다.
• Statistical Ranking: 단순 스코어 기반

9) 기타 고려사항

• 성능/비용 trade-off: 고성능 임베딩 모델, 큰 벡터 차원, Re-ranking 등은 성능을 높이지만 API 비용과 응답 시간을 증가시킵니다.
• 스케일링: 문서가 1만 개일 때와 100만 개일 때의 검색 속도와 시스템 구조는 완전히 달라야 합니다.
• 검색 파라미터: Top-k(몇 개를 검색할지), 유사도 점수 임계값 등을 조절하며 최적의 값을 찾아야 합니다.
  • k (Top-k 검색 개수): 3, 5, 10, 20
  • Max marginal relevance (MMR): 중복 줄이기
  • Score threshold: 특정 유사도 이상만 채택
  • Hybrid Weighting: Sparse vs Dense 비율 조정

---

2. Agent

에이전트는 단순히 질문에 답하는 것을 넘어, 스스로 사고(Thinking)하고, 계획(Planning)을 세우고, 도구(Tools)를 사용하여 주어진 목표를 달성하는 자율적인 프로그램입니다.

1) 아키텍처 / 프레임워크

• 프레임워크
  • LangChain, LlamaIndex가 에이전트 개발에도 널리 쓰이며, 최근에는 상태(State)와 흐름 제어에 강점이 있는 LangGraph, 여러 에이전트의 협업에 특화된 AutoGen, CrewAI 등이 주목받고 있습니다.
  • LangChain, LangGraph, AutoGen, CrewAI, Semantic Kernel, LlamaIndex
• 실행 모델
  • 단일 에이전트 vs 멀티에이전트

2) 상호작용 (Agent Collaboration)

• 멀티에이전트 상호작용 패턴
  • 협력(Cooperative): 각자 맡은 역할을 수행하고 결과를 합치는 방식.
    • 에이전트 3명이 문서 요약 → 최종 합산 요약 결과를 평가
  • 경쟁(Competitive): 결과 품질을 겨루고 우승 답변 채택
    • 에이전트 2명이 질문에 대해 독립적으로 답변 → 우승 답변 선택
  • 혼합(Hybrid): 경쟁 후 협력적 합의
    • 경쟁 후 합의(Consensus) 단계 추가 → 합의 결과 평가
  • 자기 검증형 (Reflective) : 에이전트가 자신의 결과물을 스스로 평가하고 부족한 점을 수정, 보완하는 방식. (마치 코드 리뷰를 스스로 하는 개발자처럼)
• 의사결정 방식
  • 투표(Voting), 합의(Consensus), 평판(Reputation-based) 알고리즘
  • deadlock / 무한루프 방지 메커니즘
• 대규모 시뮬레이션
  • 수십 명 에이전트가 가상 사회에서 협업·토론하는 시나리오 (e.g. Social Simulation)

3) 도구 / API 연동 (Tool Use)

에이전트의 능력을 확장하는 핵심 기능입니다. LLM이 할 수 없는 일(e.g., 실시간 정보 검색, 계산, 외부 서비스 연동)을 함수(API)로 구현하여 에이전트에게 제공합니다.

• 툴 선택 로직
  • 단일 툴 선택
  • 복수 툴 체이닝 (A → B → C 호출)
    • 예시: '환율 계산 → 해외 결제 금액 추정 → 이메일로 결과 전송' 같이 여러 API를 연결할 필요가 있을 때 체이닝을 사용합니다.
• 실시간 데이터 연동
  • 단순히 내장된 지식이 아닌, 실시간 검색(날씨·금융·주식·뉴스 등)이나 최신 데이터를 API로 가져오는 기능이 요구됩니다.
  • API latency가 높거나 불안정할 때 fallback 전략
    • 예시: "날씨 정보 API가 3초 내 응답하지 않으면 다른 날씨 API 호출", "검색 실패 시 가장 최근 데이터 사용".
  • Streaming 응답 처리 가능 여부
• 잘못된 툴 선택(오작동) 검출률 (Tool reliability metrics)
  • 에이전트가 잘못된 도구를 선택하거나 API 호출 결과가 실패할 수 있으므로, 오작동(실패) 발생률 모니터링 및 평가 지표가 필요합니다.

4) 상태 관리 / 메모리

• 단기 메모리 (Session memory)
  • 대화 중 맥락 유지, 이전 입력 반영 여부
  • 랭그래프에서 상태 관리 전략
• 장기 메모리 (Long-term memory)
  • 이전 대화의 중요한 내용을 Vector DB 등에 요약, 저장해두고 필요할 때 다시 꺼내 쓰는 방식
  • RDB 사용 가능

5) 결과 품질 및 제어

• 추론 Traceability
  • “왜 이 결정을 내렸는가?” 설명 가능성 (나중에 물어 봤을 때라도 추론 추적)
  • 호출 경로(Which tool, Which agent)를 기록/리플레이 가능 여부
  • 또는 결정 내린 히스토리를 어디에다가 데이터화 해놓는 방식
• 오류 유형
  • 할루시네이션 / 무한 루프 / 툴 실패 / Deadlock 발생 빈도
• Guardrails
  • 정책 위반(PII 노출, 금칙어 등) 차단
  • 응답 길이·포맷 강제 여부 (예: JSON schema validation)

6) 멀티모달 에이전트

• 입력/출력 모달리티
  • 텍스트, 음성, 이미지, 비디오, 센서 데이터
• Cross-modal reasoning
  • 이미지 기반 질문 → 텍스트 답변, 오디오 지시 → 코드 실행
• 멀티모달

7) 기타 고려사항

• 오케스트레이션
  • Workflow 관리: Prefect, Airflow, Temporal 같은 외부 오케스트레이터 연동
• 스케일링
  • 에이전트 수 증가 시 비용, Latency, Throughput 변화 측정
• 장애 대응
  • 에이전트 일부 실패 시 점진적 기능 축소(graceful degradation) 가능 여부
• Observability
  • 로그, 메트릭, 이벤트 트레이싱 (Prometheus, OpenTelemetry 연동)

---

3. 프롬프트

LLM에게 원하는 결과물을 얻어내기 위해 내리는 '지시문'입니다. 좋은 프롬프트는 좋은 결과물의 시작이며, '프롬프트 엔지니어링'은 그 자체로 중요한 기술 분야입니다.

1) 프롬프트 엔지니어링 기법

• Prompt chaining: 여러 개의 작은 프롬프트를 연결해 단계별로 처리
• 예: 질문 요약 → 관련 문서 검색 → 최종 답변 생성
• Self-reflection: 모델이 스스로 답변을 검토하고 수정
• 예: "너의 답변을 다시 읽고, 논리적 오류가 있는지 점검하라"
• Few-shot / Zero-shot / Hybrid: 예시 제공 여부에 따른 차이 검증
• Reddit 최신 기법
  • 1. Recursive Self-Improvement Prompting (RSIP) - 반복적 자기 개선 프롬프트
    • LLM이 자신의 출력물을 반복적으로 평가·비판·수정하며 스스로 품질을 높여가는 방식.
    • 예시: 출력 후 최소 3개 결점 스스로 진단 → 해당 사항 개선하여 재출력 → 선정된 평가 기준별로 단계별 개선 반복 후 최종본 제출.
    • 적용 분야: 창작, 기술 문서, 논증 설계 등(평가 기준별로 단계 개선).
  • 2. Context-Aware Decomposition (CAD) - 맥락 기반 복합 문제 분해
    • 복잡한 과제의 핵심 컴포넌트를 분리·분석 후, 각 요소를 맥락과 연결해서 각각 해결하고, 종합적으로 전체 답안을 제시하는 방식.
    • 'Thinking Journal(사고 일지)'로 각 단계별 사고 과정을 기록하여 중간 결과와 통합적 해법 연결.
  • 3. Controlled Hallucination for Ideation (CHI) - ‘통제된 환각’ 활용 창의 이데이션
    • LLM의 hallucination을 완전히 억제하지 않고, 창의적 아이디어 도출에 적극 활용.
    • 'Speculative' 결과물 명확 표시 → 아이디어별 이론적 근거, 실제 구현 필요사항, 최종적으로 실현 가능성까지 비평.
  • 4. Multi-Perspective Simulation (MPS) - 다관점 시뮬레이션
    • 단순 찬반 구도가 아닌 다섯 개 이상의 복잡한 시각/가정/논리 구조를 생성.
    • 각 관점별로 핵심 가치, 강점/약점, 논리 근거 분석 → 서로 간 대화/합의/비판 → 최종 통합적 시각으로 결론 도출.
  • 5. Calibrated Confidence Prompting (CCP) - 신뢰도 등급화 프롬프트
    • LLM이 각 주장이나 정보에 대해 명시적으로 Confidence(신뢰도) 등급을 부여하도록 프롬프트 설계(예: Virtually Certain, Highly Confident, Moderately Confident, Speculative 등).
    • 각 등급별로 증거/불확실성/추가 정보 필요성 명시.
• Mirascope Blog
• Tree-of-Thought (ToT): 의사결정을 트리 형태로 분기해 탐색
• 예: 수학 문제 → 여러 풀이 경로 생성 → 최적 해법 선택
• Graph-of-Thought (GoT): 노드-엣지 형태로 사고 과정을 네트워크화
• 예: 복잡한 프로젝트 계획을 여러 경로/연관성으로 연결해 정리
• Recall-Augmented Generation
  • 외부 지식 DB를 참조하여 기억 기반 답변을 강화함.
• Tool-Calling Prompt / Agentic Loop
  • 프롬프트 안에 API 호출·서드파티 도구 사용 지시를 포함하여, LLM이 실질적 행동(예: 검색, 연산)을 수행하도록 유도.

2) 프롬프트 표준화

• 동일한 prompt, 동일한 seed/temperature, 동일한 토큰 한도
• 재현성 확보: 모델 버전, 토크나이저 버전, DB 버전 기록

3) 프롬프트 옵저버빌리티

• Langfuse, PromptLayer 등은 프롬프트 입력, 결과, 비용, 지연 시간 등을 추적/시각화합니다.
• 비효율적인 프롬프트를 빠르게 탐지·개선할 수 있습니다

4) 기타 고려 사항

• 정책 준수 검증
  • 레드팀 프롬프트(민감정보, jailbreak, 혐오발화) 수행
• Fusion 전략
  • Late Fusion: 검색(검색된 여러 문서)에 대해 각각 LLM이 답변을 생성한 뒤, 각 문서별로 생성된 여러 답변을 다시 합치는 방식입니다.
  • Early Fusion: 검색된 여러 문서의 retrieval 결과를 미리 합친 뒤, 한 번에 LLM에 입력하여 답변을 생성하는 방식입니다.
• Retrieval 결과와 LLM 입력을 어떻게 조합해서 최종 답변을 생성할지 결정
• 평가 자동화
  • HELM, EvalScope: 학계나 기업에서 대규모로 LLM의 종합 성능을 벤치마킹하는 프레임워크입니다.
  • 테스트케이스 자동화
    • 특정 도메인/업무 상황에 맞춘 테스트 세트를 자동 생성해서 모델에 넣고 결과 검증
    • 예: 고객 문의 100개 → 모델 응답 → 정답셋과 비교하여 pass/fail 체크
    • 소프트웨어 테스트에서의 단위테스트 자동화와 비슷한 개념을 LLM 성능 평가에 적용한 것

---