C# 개발자를 위한 AI Agent와 RAG 입문
Model → Agent → Embedding → Vector Search → RAG

작성 기준일 · 2026-09-17

C# 개발자를 위한 AI Agent와 RAG 입문
Model → Agent → Embedding → Vector Search → RAG

LLM을 호출하는 수준에서 벗어나, C#/.NET 애플리케이션에 AI Agent와 RAG를 어떻게 연결하는지 하나의 흐름으로 이해해 봅니다.

핵심 요약

AI 애플리케이션을 처음 접하면 LLM API를 호출하는 것만으로 Agent를 만들었다고 생각하기 쉽습니다. 하지만 실제 애플리케이션에서는 모델, Agent, 세션 상태, 도구 호출, Embedding, Vector Search, RAG가 서로 다른 역할을 합니다.

특히 기업용 시스템에서는 "LLM이 알고 있는 일반적인 지식"과 "우리 회사가 가진 실제 데이터"를 분리해서 생각해야 합니다. RAG는 이 둘을 연결하는 대표적인 방법입니다.

1. 먼저 이해해야 할 전체 구조

제공된 강의의 핵심 흐름을 현재 .NET 생태계에 맞춰 정리하면 다음과 같습니다.

Model
학습된 모델

LLM
언어 모델

Agent
목표 + 추론 + 실행

Embedding
텍스트 → 벡터

Vector Search
의미 기반 검색

RAG
검색 결과를 Context로 결합

현재 Microsoft Agent Framework 문서 역시 Agent를 단순한 LLM 호출 객체가 아니라 Agent abstraction + model connection + instructions + tools + middleware + context providers + session state가 결합된 실행 단위로 설명합니다.

2. Model과 LLM은 같은 것인가?

강의에서 가장 먼저 설명하는 개념은 Model입니다.

Model = 데이터로 학습된 모델
Inference = 이미 만들어진 모델에 입력을 전달하고 결과를 얻는 과정
Training = 데이터를 이용해 모델을 학습시키는 과정

예를 들어 나이와 보험료 데이터를 이용해 보험료를 예측하는 모델을 만든다면 이것은 특정 문제를 해결하기 위한 머신러닝 모델입니다.

반면 LLM은 대규모 텍스트 데이터 등을 기반으로 언어를 처리하도록 학습된 모델 계열입니다. 따라서 "모델을 직접 학습시키는 것"과 "이미 제공되는 LLM을 애플리케이션에서 사용하는 것"은 구분해야 합니다.

중요한 구분

OpenAI, Anthropic, Google과 같은 회사는 AI 모델과 관련 서비스를 제공합니다. ChatGPT와 같은 제품/서비스와 그 안에서 선택되는 모델은 동일한 개념이 아닙니다. 실제 개발에서는 제공자(provider) → API/client → model → application의 계층을 분리해서 이해하는 것이 좋습니다.

3. AI Agent는 단순한 Chat API 호출과 무엇이 다른가?

강의에서는 여행 에이전트를 예로 들어 Agent를 설명합니다.

Goal
무엇을 달성해야 하는가?

Reasoning
주어진 상황을 어떻게 판단할 것인가?

Act
판단 결과를 어떤 행동으로 연결할 것인가?

이를 개발 관점에서 단순화하면 다음과 같습니다.

사용자 입력 → Agent Instructions → Model 추론 → Tool/Context 활용 → 결과

다만 "Agent = Goal + Reasoning + Action"은 이해를 위한 단순화입니다. 현재 Microsoft Agent Framework에서는 Agent 실행 과정에 세션, Context Provider, Middleware, Tool 등이 함께 참여할 수 있습니다.

4. C#으로 Agent를 시작할 때 Console Application을 사용하는 이유

강의에서는 처음부터 MVC나 복잡한 Web Application을 만들지 않고 Console Application으로 Agent를 학습합니다.

이 접근은 학습 단계에서는 상당히 합리적입니다. ASP.NET Core MVC를 동시에 사용하면 Controller, DI, Routing, Authentication, Middleware 등의 개념이 AI 학습과 섞이기 때문입니다.

TIP · 학습 순서

처음에는 Console → Agent → Tool → Session → RAG 순으로 개념을 익히고, 이후 ASP.NET Core Web API/MVC로 옮기는 방법이 좋습니다.

5. Microsoft.Extensions.AI가 중요한 이유

강의에서는 여러 AI 관련 라이브러리와 추상화를 설명하지만, 2026년 현재 .NET 개발자가 특히 주목할 부분은 Microsoft.Extensions.AI입니다.

Microsoft 문서에 따르면 Microsoft.Extensions.AI는 AI 서비스와 애플리케이션 사이의 공통 추상화를 제공하며, 핵심 인터페이스로 IChatClient와 IEmbeddingGenerator를 제공합니다.

애플리케이션 코드
↓
IChatClient
↓
OpenAI / Azure OpenAI / Anthropic 등 Provider

이 구조의 장점은 애플리케이션 코드가 특정 공급자의 SDK에 지나치게 강하게 결합되는 것을 줄일 수 있다는 것입니다.

Microsoft 문서에서는 IChatClient가 채팅 기능을 제공하는 AI 서비스와 상호작용하기 위한 추상화이며, 여러 Provider가 이 인터페이스를 구현할 수 있다고 설명합니다.

6. Agent와 LLM을 분리해서 생각하자

예를 들어 다음과 같은 Agent를 생각해 보겠습니다.

C# Mock Interview Agent

Goal: 사용자의 경력 수준에 맞춰 면접 질문을 생성한다.

Instruction: 세 개의 질문을 생성한다.

Model: LLM을 사용해 질문을 생성한다.

Input: "나는 1년차 C# 개발자입니다."

여기에서 LLM은 Agent 그 자체가 아닙니다.

LLM은 Agent가 사용하는 추론 능력의 핵심 구성요소이고, Agent는 그 위에 목표, 지시사항, 상태, 도구, Context 등을 결합한 실행 구조라고 이해하는 것이 정확합니다.

현재 Microsoft Agent Framework의 개념 문서도 이러한 구성을 명시적으로 설명합니다.

7. 첫 번째 Agent의 한계 — "일반적인 LLM 답변"만 한다

여기서 RAG가 등장합니다.

예를 들어 사용자가 다음과 같이 입력했다고 가정합니다.

"나는 1년차 C# 개발자입니다."

일반적인 LLM은 자체적으로 학습된 지식과 현재 프롬프트를 바탕으로 답변을 생성합니다.

하지만 회사에서 실제로 원하는 규칙이 다음과 같다면 문제가 생깁니다.

1년차 개발자 → OOP + SQL 중심
시니어 개발자 → Architecture + Design Pattern
Azure 개발자 → Azure App Service + Functions + APIM

이 정보가 회사 내부 DB나 문서에 있다면 LLM이 그 내용을 자동으로 알고 있다고 가정해서는 안 됩니다.

핵심 문제

LLM의 일반적인 지식과 애플리케이션이 실제로 사용하는 최신·사내 데이터는 별개의 데이터 영역입니다.

8. RAG란 무엇인가?

RAG는 일반적으로 Retrieval-Augmented Generation을 의미합니다.

Retrieve
관련 정보를 검색

Augment
검색 결과를 Context로 추가

Generate
Context를 참고해 답변 생성

즉 단순히 다음과 같이 질문하는 것이 아니라

사용자 질문 → LLM

다음과 같은 구조를 만듭니다.

사용자 질문
↓
관련 데이터 검색
↓
검색된 Context + 사용자 질문
↓
LLM
↓
최종 답변

9. 왜 일반 SQL 검색만으로는 부족한가?

RAG에서 중요한 부분은 Retrieve입니다.

사용자가 "1년차 주니어 C# 개발자"라고 입력했을 때 DB에 다음 데이터가 있다고 생각해 보겠습니다.

표현	의미	질문 영역
1년차 C# 개발자	Junior	OOP, SQL
Junior Developer	Junior	OOP, SQL
초급 개발자	Junior	OOP, SQL

LIKE 검색이나 단순 문자열 일치만으로는 이런 표현의 의미적 유사성을 충분히 처리하기 어렵습니다.

여기에서 Embedding + Vector Search가 등장합니다.

10. Embedding — 텍스트를 숫자 공간으로 변환하기

Embedding은 텍스트와 같은 입력을 숫자 벡터로 표현하는 방법입니다.

개념적으로는 다음과 같습니다.

"1년차 C# 개발자"
↓
Embedding Model
↓
[0.12, -0.04, 0.83, ...]

중요한 점은 숫자 하나가 특정 단어 하나를 의미한다고 단순하게 해석하면 안 된다는 것입니다. 벡터는 모델이 학습한 표현 공간에서 입력의 의미적 특성을 수치화한 결과로 이해하는 것이 좋습니다.

강의에서는 OpenAI의 text-embedding-3-small을 예제로 사용하며 1,536차원 벡터를 설명합니다. 다만 실제 사용하는 Embedding 모델과 설정에 따라 차원 수는 달라질 수 있으므로 "모든 Embedding은 1,536차원"이라고 일반화하면 안 됩니다.

11. Vector란 무엇인가?

Vector를 처음 접하는 개발자라면 복잡한 수학부터 공부할 필요는 없습니다.

RAG에서 우선 이해해야 할 것은 다음 세 가지입니다.

텍스트를 Embedding으로 변환한다.
변환된 숫자 배열을 저장한다.
새로운 질문도 같은 방식으로 변환한 뒤 기존 벡터와 유사도를 계산한다.

예시

"1년차 C# 개발자"

↓ Embedding

Vector A

"Junior .NET Developer"

↓ Embedding

Vector B

Vector A ↔ Vector B의 유사도 계산

12. Cosine Similarity와 Euclidean Distance

강의에서는 벡터 간 관계를 설명하기 위해 Euclidean Distance와 Cosine Similarity를 소개합니다.

방법	핵심 관점	RAG에서의 이해
Euclidean Distance	두 점 사이의 거리	벡터 공간에서의 거리 기반 비교
Cosine Similarity	벡터 방향의 유사성	텍스트 의미의 유사성 비교에 자주 활용

실제 시스템에서는 데이터와 Embedding 모델, Vector DB, 검색 알고리즘 및 인덱스 구성에 따라 적절한 유사도/거리 함수를 선택해야 합니다.

13. Vector Database가 필요한 이유

RAG 시스템은 단순히 벡터를 계산하는 것에서 끝나지 않습니다.

수많은 문서의 Embedding을 저장하고 사용자의 질문과 비교하여 관련성이 높은 데이터를 빠르게 검색해야 합니다.

전형적인 구조

문서 → Chunking → Embedding → Vector Storage → Similarity Search → Top-K Context → LLM

Vector Database 또는 Vector Search 기능을 제공하는 데이터베이스는 이 검색 단계를 담당합니다.

14. SQL Server에서도 Vector를 사용할 수 있을까?

2026년 기준으로 이 부분은 강의 원본보다 반드시 업데이트해서 봐야 합니다.

Microsoft 공식 문서에 따르면 SQL Server 2025(17.x)에는 VECTOR 데이터 형식이 제공됩니다. Vector는 기본적으로 float32를 사용하며 각 요소는 4바이트의 단정밀도 부동소수점 값으로 저장됩니다. 최대 차원 수는 1,998입니다.

따라서 "SQL Server에서는 Vector를 사용할 수 없다"는 식으로 이해해서는 안 됩니다.

현재 기준 핵심

SQL Server 2025에서는 VECTOR 데이터 형식을 사용할 수 있습니다.

따라서 기존 SQL Server 기반 시스템에서도 AI/RAG 아키텍처를 설계할 수 있는 선택지가 넓어졌습니다.

Microsoft 공식 문서는 SQL Server 2025에서 VECTOR 타입과 벡터 거리 계산 기능을 제공한다고 명시합니다.

15. 강의의 6,152라는 숫자는 주의해서 봐야 한다

원본 강의에서는 1,536차원 Embedding과 SQL Server 저장 크기 6,152바이트를 연결해서 설명합니다.

여기에서는 개념을 정확하게 분리해야 합니다.

확인 포인트

1,536은 Embedding vector의 차원 수입니다.

반면 저장 공간은 데이터 타입, 헤더, 전송 형식, 저장 구조 등에 의해 달라질 수 있습니다.

따라서 "벡터의 차원 = 저장 바이트 수"라고 생각하면 안 됩니다.

특히 현재 SQL Server 2025의 VECTOR 타입은 각 float32 요소를 4바이트로 저장하는 구조를 공식 문서에서 명시하고 있습니다. 따라서 1,536차원의 float32 vector라면 원소 데이터 자체만 단순 계산했을 때 1,536 × 4 = 6,144바이트입니다. 여기에 실제 저장·표현 구조를 별도로 고려해야 합니다.

이 때문에 강의에 등장하는 특정 바이트 수를 다른 데이터베이스나 다른 Vector 타입에도 그대로 적용해서는 안 됩니다.

16. RAG의 실제 데이터 흐름

이제 지금까지의 내용을 하나로 연결해 보겠습니다.

① 사용자 질문

"나는 1년차 C# 개발자입니다."

② Query Embedding

질문을 Vector로 변환

③ Vector Search

저장된 문서/데이터와 유사도 비교

④ Context Retrieval

"1년차 개발자는 OOP와 SQL을 중심으로 평가"

⑤ Augmentation

사용자 질문 + 검색된 Context

⑥ LLM

Context를 기반으로 답변 생성

⑦ Agent

필요하다면 Tool과 Session 등을 이용해 다음 행동 수행

17. "Agent + RAG"가 되면 무엇이 달라지는가?

단순 LLM 호출은 다음과 같습니다.

Prompt → LLM → Answer

RAG를 추가하면 다음과 같습니다.

Prompt → Retrieval → Context → LLM → Answer

Agent까지 추가하면 더 확장됩니다.

User
↓
Agent
↓
Query / Reasoning
↓
RAG / Tools / APIs / Database
↓
LLM
↓
Action / Response

현재 Microsoft Agent Framework의 공식 시작 가이드도 Agent → Tools → Multi-turn Sessions → Memory & Persistence → Workflows → Hosting이라는 단계적 학습 흐름을 제시하고 있습니다.

18. Session은 RAG와 다른 개념이다

여기서 한 가지 중요한 구분이 필요합니다.

RAG는 외부 지식(Context)을 검색하는 문제이고, Session은 대화 상태를 유지하는 문제입니다.

구성	해결하는 문제	예시
RAG	외부 지식 검색	회사 규정, 매뉴얼, 프로젝트 문서
Session	대화 상태 유지	이전 대화, 세션별 상태
Tool	외부 시스템 실행	DB 조회, API 호출, 파일 처리

현재 Microsoft Agent Framework의 AgentSession은 Agent 실행 사이에서 대화 상태를 유지하기 위한 컨테이너이며, 세션을 생성하고 여러 RunAsync 호출에 재사용하거나 직렬화 후 복원할 수 있습니다.

19. C# 개발자가 이 구조를 이해해야 하는 이유

기존 .NET 개발자는 이미 AI 애플리케이션을 만들기 위한 상당히 좋은 기반을 가지고 있습니다.

ASP.NET Core
Dependency Injection
Configuration
Middleware
Background Service
HttpClient
SQL Server
Redis
Authentication / Authorization
Observability

AI 애플리케이션은 기존 웹 애플리케이션을 완전히 버리고 새로운 방식으로 개발하는 것이 아니라, 이러한 기존 애플리케이션 아키텍처 위에 Model + Agent + Context + Tool + Session을 추가하는 방향으로 발전할 수 있습니다.

특히 Microsoft.Extensions.AI는 .NET 애플리케이션에서 여러 AI 서비스와 통합하기 위한 공통 추상화를 제공하므로 기존 DI 중심의 .NET 개발 방식과도 잘 맞습니다.

20. 실무에서는 어떻게 발전시키는가?

처음부터 "멀티 에이전트 + MCP + RAG + Vector DB + Workflow"를 한 번에 만드는 것은 추천하지 않습니다.

STEP 1 LLM 호출을 이해한다.

STEP 2 Agent와 Instructions를 이해한다.

STEP 3 Tool Calling을 추가한다.

STEP 4 Session으로 Multi-turn 대화를 구현한다.

STEP 5 Embedding을 이해한다.

STEP 6 Vector Search를 구현한다.

STEP 7 RAG를 구현한다.

STEP 8 Workflow와 여러 Agent를 연결한다.

STEP 9 ASP.NET Core에 Host한다.

STEP 10 Logging, Evaluation, Security, Cost Control을 추가한다.

21. 실제 기업 시스템으로 가져갈 때 추가해야 하는 것

강의의 Console 기반 Demo와 실제 Enterprise AI 시스템 사이에는 상당한 차이가 있습니다.

Demo	Enterprise
환경변수 API Key	Secret 관리 / Managed Identity 등
Console	ASP.NET Core API / Web Application
단일 사용자	사용자/테넌트별 권한 및 데이터 격리
단순 Prompt	Prompt 관리 및 버전 관리
단순 Vector Search	Hybrid Search / Metadata Filter / Reranking 검토
즉시 응답	Timeout / Retry / Rate Limit / Cancellation
LLM 결과 그대로 사용	Validation / Guardrails / Evaluation

특히 Microsoft의 IChatClient 문서도 Prompt Injection, 입력 데이터 크기, 모델 호출 횟수 등의 위험을 애플리케이션이 고려해야 한다고 명시합니다.

WARNING · RAG를 사용한다고 답변이 자동으로 정확해지는 것은 아니다

RAG의 핵심은 "관련 정보를 찾아 LLM에게 제공한다"는 것입니다. 검색 결과가 잘못되거나, 문서가 오래되었거나, Chunking이 잘못되었거나, 검색 Top-K가 적절하지 않으면 최종 답변도 영향을 받을 수 있습니다.

따라서 실제 서비스에서는 Retrieval 품질과 Generation 품질을 별도로 평가해야 합니다.

22. 이 강의 내용을 2026년 관점에서 다시 정리하면

1단계 · Model
AI 모델이 무엇인지 이해한다.

2단계 · LLM
언어 모델을 애플리케이션에서 사용하는 방법을 이해한다.

3단계 · Agent
Instructions, Model, Tools 등을 결합한 실행 단위를 이해한다.

4단계 · Session
Multi-turn 대화와 상태를 관리한다.

5단계 · Embedding
텍스트를 의미 기반 벡터 표현으로 변환한다.

6단계 · Vector Search
질문과 의미적으로 가까운 데이터를 검색한다.

7단계 · RAG
검색 결과를 Context로 만들어 LLM에 제공한다.

8단계 · Tool Calling
Agent가 외부 시스템과 상호작용할 수 있도록 한다.

9단계 · Workflow
복잡한 작업을 여러 단계와 Agent로 구성한다.

10단계 · Production
보안, 권한, 관측성, 평가, 비용, 장애 대응을 추가한다.

23. 최종 체크리스트

☐ Model과 LLM의 차이를 이해했다.
☐ Agent와 단순 Chat API 호출의 차이를 이해했다.
☐ Goal / Instructions / Model / Tool의 관계를 이해했다.
☐ Session과 RAG의 차이를 이해했다.
☐ Embedding이 텍스트를 벡터 표현으로 변환한다는 것을 이해했다.
☐ Cosine Similarity의 역할을 이해했다.
☐ Vector Search의 목적을 이해했다.
☐ Retrieve → Augment → Generate 흐름을 이해했다.
☐ SQL Server 2025의 VECTOR 지원을 확인했다.
☐ Demo와 Enterprise 환경의 차이를 이해했다.

24. FAQ

C# 개발자는 Python을 반드시 배워야 하나요?

C#/.NET만으로도 AI 애플리케이션과 Agent를 개발할 수 있습니다. 현재 Microsoft Agent Framework는 C#을 공식적으로 지원하며, Microsoft.Extensions.AI 역시 .NET 애플리케이션을 위한 AI 추상화를 제공합니다. 다만 AI 생태계의 자료와 라이브러리는 Python 비중도 높기 때문에 AI 엔지니어링을 깊게 확장한다면 Python을 읽고 수정할 수 있는 수준까지 익혀두는 것이 실무적으로 도움이 될 수 있습니다.

RAG를 사용하면 LLM을 다시 학습시켜야 하나요?

일반적인 RAG에서는 검색된 외부 데이터를 Prompt의 Context로 제공하므로 해당 데이터를 LLM 자체에 다시 학습시키는 것과는 다릅니다.

SQL Server를 계속 사용해도 되나요?

SQL Server 2025에서는 VECTOR 데이터 형식과 벡터 관련 기능을 사용할 수 있습니다. 기존 시스템과 데이터 통합이 중요한 경우 SQL Server 기반 설계를 검토할 수 있습니다. 다만 대규모 벡터 검색에서는 별도의 Vector Database나 검색 시스템을 함께 비교해야 합니다.

Agent를 만들면 자동으로 자율적인 AI가 되나요?

아닙니다. Agent의 자율성은 사용 가능한 Tool, 실행 루프, 상태 관리, 승인 정책, Workflow 및 애플리케이션이 허용한 권한 등에 의해 결정됩니다. 실제 서비스에서는 Agent가 수행할 수 있는 행동의 범위를 명확히 제한해야 합니다.

마무리

이번 내용에서 가장 중요한 것은 특정 SDK의 API를 외우는 것이 아닙니다.

Model → LLM → Agent → Session → Embedding → Vector Search → RAG → Tool → Workflow

이 연결 관계를 이해하는 것이 핵심입니다.

특히 기존 C#/.NET 개발자라면 AI를 완전히 새로운 분야로 보기보다 기존 애플리케이션 아키텍처에 새로운 실행 계층이 추가되는 것으로 바라보는 편이 이해하기 쉽습니다.

그리고 RAG에서 가장 중요한 사고방식은 다음 한 문장으로 정리할 수 있습니다.

LLM에게 모든 것을 기억시키는 것이 아니라,
필요한 순간 필요한 Context를 검색해서 제공한다.

출처 및 참고 자료

참고: 본문은 제공된 영상 스크립트의 내용을 기반으로 구성하되, 2026-09-17 현재 확인 가능한 Microsoft 공식 문서를 기준으로 변경된 .NET Agent Framework 및 SQL Server Vector 관련 내용을 보완했습니다. 영상에 등장하는 특정 NuGet 버전, API 형태, 제품 기능은 현재 버전과 다를 수 있으므로 실제 개발 전 공식 문서를 다시 확인해야 합니다.

LUCKY BLOG

Pinned Post

“일본어를 잘하는 법”이 아니라 “일본 여행에서 실제로 말할 수 있는 일본어”