> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/7-1.-ai.md). # 7-1. AI의 구성요소와 아키텍처 기본 AI Engineering 기본기: Model부터 Harness Engineering까지 ### 1. 개요 AI는 백엔드와 마찬가지로 끊임없이 트렌드를 살펴보고 파악해야 한다. 다만 백엔드와 차이점은 그 변화 속도가 매우 빠르다는 것이다. 백엔드의 기술 변화가 비교적 긴 주기로 이루어진다면, AI는 1년 사이에도 모델과 활용 방식, 시스템 구성 방법이 크게 변화할 수 있다. 링크드인이나 미디움, 벨로그 등을 살펴보면 얼마 전까지 획기적이었던 기술이나 방법론이 얼마 지나지 않아 새로운 모델이나 더 나은 방법으로 대체되는 모습을 쉽게 볼 수 있다. > AI의 기본기라는 것은 존재하지 않는 것인가? > > AI가 더 좋은 것, 새로운 것으로 대체될 때마다 그것을 배우고 도입해야 하는가? > > 러닝커브와 도입비용은 어떻게 감당해야 하는가? 이 물음에 대한 답을 찾아나가면서 한 가지 알게 된 사실은 **AI의 본질이 특정 모델 자체에만 있는 것은 아니라는 점**이었다. AI 모델은 입력에 대해 결과를 생성하는 핵심 엔진이다. 그러나 실제 시스템에서 어떤 모델을 선택하고, 어떤 정보를 제공하며, 어떤 도구를 연결하고, 결과를 어떻게 검증하고, 실패하면 어떻게 재시도할지는 엔지니어가 설계해야 한다. 즉, > **모델은 AI 시스템을 구성하는 핵심 컴포넌트이고, 엔지니어링은 그 모델을 목적에 맞게 활용하기 위한 시스템을 설계하는 영역이다.** 여기서 백엔드 엔지니어링의 기본기가 중요하듯 AI Engineering의 기본기도 중요하다는 결론에 도달하게 된다. AI의 본질을 특정 제품이나 모델에 한정하지 않는다면, AI의 기본기는 단순히 새로운 모델의 사용법을 암기하는 것이 아니라 **AI가 결과를 생성하는 과정과 그 결과를 원하는 수준으로 끌어올리기 위한 시스템 설계 방법**이라 볼 수 있다. AI 모델이 계속해서 바뀌더라도 백엔드 엔지니어링의 기본기와 설계 원칙이 사라지지 않는 것처럼, AI 역시 모델의 변화와 별개로 지속적으로 활용할 수 있는 기본적인 설계 원리가 존재한다. 빠른 속도로 변화하고 도입되는 AI를 더 깊게 분석하고 최적화하기 위해, 여기서는 특정 제품보다는 실무에서 반복적으로 등장하는 AI Engineering의 기반 개념을 중심으로 살펴본다. *** ## 2. AI + Backend 먼저 큰 흐름부터 살펴보면 다음과 같다. AI를 실무에 적용하기 위해서는 **Model을 다양한 방법(Ways)과 시스템 컴포넌트를 통해 Application에 연결**해야 한다. ``` AI Model ↓ AI 활용 방법 ↓ AI System ↓ Application ``` 조금 더 구체적으로 분리하면 다음과 같이 볼 수 있다. ``` AI 실무 활용 │ ┌───────────────────┼────────────────────┐ │ │ │ AI 모델/기술 AI 활용 방법 AI 시스템 요소 │ │ │ Transformer Prompting RAG LLM Context Engineering Agent Embedding Few-shot Tool Use Multimodal CoT Workflow Fine-tuning Structured Output MCP RLHF/RLAIF Prompt Chaining Memory │ │ │ └───────────────────┴────────────────────┘ │ Harness Engineering │ ┌────────────┴────────────┐ │ │ Evaluation Production │ │ Evals / Tests Observability Benchmark Guardrails Tracing Cost / Latency Red Team Security ``` 실무적으로 AI를 Application에 적용할 때 중요한 것은 단순히 좋은 모델 하나를 선택하는 것이 아니다. 다음과 같은 질문을 함께 고려해야 한다. ``` 어떤 Model을 사용할 것인가? ↓ 어떤 Context를 제공할 것인가? ↓ 어떤 Tool을 연결할 것인가? ↓ 어떤 Workflow로 실행할 것인가? ↓ 결과를 어떻게 검증할 것인가? ↓ 실패하면 어떻게 Retry할 것인가? ↓ 성능과 비용을 어떻게 측정할 것인가? ``` 이러한 전체적인 설계 및 실행 환경을 여기서는 **Harness Engineering**이라는 관점에서 이해한다. 다만 Harness Engineering은 하나의 엄밀하게 고정된 표준 계층이라기보다는, **AI 모델이나 Agent가 실제 업무를 수행하도록 주변의 Context, Tools, State, Evaluation, Guardrails, Execution 환경 등을 설계하는 엔지니어링 관점**으로 이해하는 것이 적절하다. 따라서 다음과 같은 관계로 이해하면 쉽다. ``` Prompt Engineering ⊂ Context Engineering ⊂ AI System / Harness Engineering ``` 이는 엄밀한 표준 수학적 포함관계라기보다는 학습을 위한 개념적 관계이다. 즉, 프롬프트를 잘 작성하는 것부터 시작하여 어떤 정보를 어떻게 제공할지 설계하고, Tool·Memory·RAG·Agent·Evaluation·Guardrail 등을 포함한 실행 환경 전체를 설계하는 방향으로 확장된다. *** ## 3. Transformer & LLM ### Transformer 쉽게 말하면 Transformer는 GPT와 같은 현대적인 LLM을 구성하는 대표적인 **신경망 아키텍처 계열**이다. Transformer는 2017년 *Attention Is All You Need* 논문에서 제안되었으며, 기존의 RNN이나 CNN 기반 sequence transduction 구조 대신 Attention을 핵심으로 사용하는 구조를 제안했다. 즉, ``` Transformer ↓ LLM의 대표적인 아키텍처 ↓ GPT / Claude / Gemini / Llama 등 ``` 와 같이 이해할 수 있다. 다만 **모든 LLM이 동일한 Transformer 구조를 그대로 사용하는 것은 아니며**, 각 모델은 Transformer 계열 구조를 기반으로 다양한 변형과 최적화를 적용할 수 있다. Transformer 기반 LLM은 텍스트를 Token 단위로 처리하고, 각 Token 간의 관계를 계산하면서 다음 Token을 생성하는 방식으로 동작한다. 개념적으로 단순화하면 다음과 같다. ``` Text ↓ Tokenization ↓ Token ↓ Embedding ↓ Transformer ├─ Attention ├─ Feed Forward Network ├─ Layer Normalization └─ ... ↓ Next Token Probability ↓ Generated Text ``` 여기서 중요한 것은 **Embedding이라는 단어가 두 가지 맥락에서 사용될 수 있다는 점**이다. * LLM 내부에서는 Token을 신경망이 처리할 수 있는 벡터 표현으로 변환하는 과정이 존재한다. * RAG에서는 별도의 Embedding Model을 이용하여 문서와 Query를 벡터로 변환하고 검색에 사용한다. 둘은 목적과 사용 위치가 다르므로 구분해야 한다. *** ### Attention Transformer의 핵심 메커니즘 중 하나가 Attention이다. 간단하게 표현하면 다음과 같다. ``` Q = Query K = Key V = Value Attention(Q, K, V) ``` Attention은 입력 Token들 사이의 관계를 계산하고, 현재 Token을 처리할 때 어떤 Token의 정보에 더 많은 가중치를 둘지 계산하는 메커니즘이다. 예를 들어, ``` 철수가 영희에게 사과를 주었다. 그녀는 그것을 먹었다. ``` 라는 문장이 있다면 인간은 문맥을 통해 다음과 같이 이해할 수 있다. ``` 그녀 → 영희 그것 → 사과 ``` Transformer의 Attention은 이러한 문맥상의 관계를 학습하고 계산할 수 있도록 하는 핵심 메커니즘 중 하나다. 다만 이것을 단순히 > A가 B이고 B가 C이므로 A가 C라고 추론한다. 라고 설명하면 Transformer의 실제 동작을 지나치게 단순화하게 된다. 실제로는 학습된 파라미터를 이용하여 Token 간의 관계와 표현을 계산하고, 그 결과를 바탕으로 다음 Token의 확률 분포를 생성한다. *** ### Feed Forward Network Transformer에서는 Attention만 사용하는 것이 아니라 Feed Forward Network(FFN) 등의 구성요소도 함께 사용한다. 개념적으로 단순화하면 다음과 같이 볼 수 있다. ``` Attention ↓ Token 간 정보 교환 및 관계 계산 ↓ FFN ↓ 각 Token 표현의 비선형 변환 및 특징 추출 ``` 따라서 > Attention = Token 간 관계를 반영하는 메커니즘\ > FFN = 각 위치의 표현을 변환하고 특징을 추출하는 메커니즘 정도로 이해하면 된다. *** ## LLM LLM은 **Large Language Model**의 약자로, 대규모 텍스트 데이터를 기반으로 학습하여 자연어를 입력받고 텍스트를 생성할 수 있는 대규모 언어 모델을 의미한다. 개념적으로 다음과 같이 연결된다. ``` Transformer 계열 Architecture ↓ Large-scale Training ↓ LLM ↓ GPT / Claude / Gemini / Llama ... ``` LLM은 주어진 Context와 이전 Token을 기반으로 다음 Token의 확률 분포를 계산하고 이를 반복하여 출력을 생성한다. ``` 입력 Context ↓ Tokenization ↓ Transformer ↓ 다음 Token 확률 ↓ Token 선택 ↓ 다음 입력에 추가 ↓ 반복 ↓ Generated Text ``` 예를 들어, ``` 입력: Spring에서 @Transactional은 ``` 이라고 입력하면 모델은 학습된 파라미터와 현재 Context를 기반으로 다음에 올 가능성이 높은 Token들을 계산한다. ``` [트랜잭션을] [관리하는] [기능을] ... ``` 이러한 과정을 반복하면서 최종적인 문장을 생성한다. 따라서 GPT와 같은 LLM을 단순히 "정답을 저장해놓고 찾아주는 데이터베이스"로 이해해서는 안 된다. LLM은 학습된 파라미터와 입력 Context를 기반으로 출력을 **생성**하는 모델이며, 생성 결과가 항상 사실이라는 보장은 없다. *** ## 3-1. GPT-6 / GPT Astra GPT-6 Astra와 같은 명칭은 **LLM 계열의 특정 제품/모델을 지칭하는 이름**으로 이해하는 것이 적절하다. 2026년 현재 OpenAI는 GPT-6 Astra를 실제 모델로 공개하고 있으며, 소프트웨어 엔지니어링, 브라우징, 컴퓨터 사용, 연구 및 전문 업무 등의 용도로 설명하고 있다. 중요한 것은 다음 관계를 이해하는 것이다. ``` Transformer ↓ LLM ↓ GPT 계열 모델 ↓ 특정 모델 버전 ``` 즉, 엔지니어가 특정 제품명만 기억하는 것보다, ``` Architecture ↓ Model ↓ Capability ↓ System Integration ↓ Evaluation ``` 의 구조를 이해하는 것이 더 중요하다. 모델 제품명은 지속적으로 변경될 수 있지만, * Context를 어떻게 제공할 것인가? * Tool을 어떻게 연결할 것인가? * 결과를 어떻게 검증할 것인가? * 비용과 Latency를 어떻게 관리할 것인가? * 실패하면 어떻게 Retry할 것인가? 와 같은 엔지니어링 문제는 특정 모델의 이름과 관계없이 반복해서 등장한다. *** ## 4. Embedding & Vector DB & RAG RAG를 이해하기 위해서는 먼저 **Embedding과 Vector Search**를 이해해야 한다. *** ### Embedding Embedding은 텍스트나 이미지 등의 데이터를 **고정된 차원의 수치 벡터로 표현하는 과정**이다. RAG에서는 별도의 Embedding Model을 사용하여 문서와 사용자 Query를 벡터로 변환한 뒤 서로의 의미적 유사도를 비교하는 데 활용한다. 예를 들어, ``` "Spring Transaction" ↓ Embedding Model ↓ [0.12, -0.83, 0.41, ...] ``` 와 같이 변환할 수 있다. Embedding은 단순히 문자열을 숫자로 바꾸는 것이 아니다. 학습된 Embedding Model은 데이터의 의미적 특징을 벡터 공간에 표현하도록 학습되어 있기 때문에 의미가 유사한 데이터가 일정한 조건에서 가까운 벡터 위치를 갖도록 만들 수 있다. 예를 들어, ``` "Spring의 트랜잭션 처리" ↓ [0.21, 0.71, ...] "@Transactional 동작 원리" ↓ [0.23, 0.69, ...] ``` 와 같이 서로 비슷한 의미를 가진 문장이 유사한 벡터 공간에 표현될 수 있다. 다만 중요한 것은 **Embedding이 의미를 완벽하게 이해하거나 추론하는 과정은 아니라는 것**이다. Embedding은 검색과 비교를 위한 벡터 표현을 생성하는 것이며, 실제 최종 답변 생성은 LLM이 담당한다. *** ## Vector DB Embedding된 벡터를 저장하고 검색할 수 있는 저장소가 Vector Database 또는 Vector Search 기능을 제공하는 데이터베이스이다. 전체적인 구조는 다음과 같다. ``` Document ↓ Embedding Model ↓ Vector ↓ Vector DB ``` 사용자가 질문하면, ``` User Query ↓ Embedding Model ↓ Query Vector ↓ Vector Search ↓ 관련 문서 ``` 와 같은 흐름으로 검색한다. 여기서 PostgreSQL 역시 `pgvector`와 같은 확장을 통해 Vector Search를 수행할 수 있기 때문에 Vector DB 역할을 수행할 수 있다. 즉, > PostgreSQL 자체가 본질적으로 Vector DB인 것이 아니라, PostgreSQL에 Vector 기능을 추가하여 Vector Search 저장소로 사용할 수 있다. *** ## RAG RAG는 **Retrieval-Augmented Generation**의 약자이다. RAG는 LLM 자체의 파라미터에 존재하는 지식만 사용하는 것이 아니라, 외부 데이터에서 필요한 정보를 \*\*검색(Retrieval)\*\*하고 그 결과를 Context로 제공하여 답변을 생성하도록 하는 시스템 구성 방식이다. 따라서 RAG는 특정 AI 모델 자체가 아니다. ``` RAG = Retrieval + Context + Generation ``` 예를 들어, ``` 사용자: 우리 회사 휴가 규정 알려줘 ↓ Query ↓ Embedding ↓ Vector Search ↓ 회사 규정 문서 ↓ Context ↓ LLM ↓ 답변 ``` 이때 핵심은 회사 규정 문서를 LLM에게 Context로 제공하는 것이다. ``` 외부 지식 ↓ Retrieval ↓ Context ↓ LLM ↓ Answer ``` 이를 통해 LLM이 외부 문서의 정보를 참고하여 답변하도록 구성할 수 있다. 다만 RAG 역시 **환각(Hallucination)을 완전히 제거하는 기술은 아니다.** 검색 결과가 잘못되었거나, 관련 문서가 검색되지 않았거나, Context가 부족하거나, 모델이 Context를 잘못 해석하면 잘못된 답변이 생성될 수 있다. 따라서 RAG의 핵심은 단순히 Vector DB를 붙이는 것이 아니라, > **필요한 근거를 얼마나 정확하게 검색하고, 적절한 Context로 구성하여 LLM에 전달하는가** 에 있다. *** ## LLM Model과 Embedding Model의 차이 매우 중요한 부분이다. ``` Embedding Model ↓ 검색을 위한 벡터 표현 생성 LLM ↓ Context를 기반으로 최종 답변 생성 ``` 즉, 둘은 서로 다른 책임을 가진 모델이다. ``` Document ↓ Embedding Model ↓ Vector DB ↓ Vector Search ↓ Relevant Documents ↓ Context ↓ LLM ↓ Answer ``` 따라서 > "GPT를 선택했으니 Embedding도 GPT가 담당한다." 라고 생각하면 안 된다. RAG를 구축할 때는 일반적으로 **LLM과 Embedding Model을 별도로 선택**한다. *** ## 5-1. Vector Search Vector Search는 RAG와 동일한 개념이 아니다. ``` Vector Search = Vector 표현을 기반으로 유사한 데이터를 검색하는 방법 ``` RAG는 그 Vector Search 등을 이용하여 검색한 정보를 LLM의 Context로 제공하고 답변을 생성하는 전체적인 시스템 구성이다. 따라서 관계는 다음과 같다. ``` Embedding ↓ Vector ↓ Vector Search ↓ Retrieved Context ↓ RAG ↓ LLM ↓ Answer ``` 보다 전체적인 RAG Pipeline은 다음과 같이 구성할 수 있다. ``` Document Ingestion ↓ Parsing ↓ Chunking ↓ Embedding ↓ Indexing ↓ Retrieval ↓ Reranking ↓ Context Construction ↓ LLM ↓ Generation ``` 여기서 중요한 점은 **질문을 Token 단위로 처리하여 최종 문장을 생성하는 것은 LLM의 책임**이라는 것이다. RAG는 LLM이 답변할 때 사용할 외부 근거를 검색하고 Context를 구성하는 역할을 담당한다. *** ## 5-2. Chunking & Hybrid Search & Reranking ### Chunking 문서를 그대로 하나의 Context로 제공한다고 해서 항상 검색 품질이 높아지는 것은 아니다. 오히려 너무 긴 문서를 하나의 검색 단위로 취급하면 원하는 정보를 정확하게 검색하기 어려워질 수 있다. 따라서 문서를 적절한 단위로 분리한다. ``` 100페이지 문서 ↓ Chunk 1 Chunk 2 Chunk 3 ... Chunk N ``` 단순히 일정한 Token 수로 자르는 것보다 문서의 구조와 의미를 고려하는 것이 중요할 수 있다. 예를 들어, ``` Heading ├─ Section │ ├─ Paragraph │ └─ Paragraph └─ Section ``` 과 같이 문서 구조를 보존하면서 Chunk를 구성할 수 있다. 이러한 접근을 대표적으로 다음과 같이 부를 수 있다. * Semantic Chunking * Structure-aware Chunking 즉, > 문서를 어떻게 나누는가가 Retrieval 품질에 영향을 줄 수 있다. *** ### Hybrid Search Vector Search만 사용하는 것이 항상 최적은 아니다. 특히 다음과 같은 정보는 Keyword Search가 유리할 수 있다. ``` @Transactional NullPointerException ERR-500 ORD-1234 Java21 ``` 따라서 Vector Search와 Keyword Search를 결합할 수 있다. ``` Vector Search + Keyword Search ↓ Hybrid Search ``` Vector Search는 의미적 유사성을 찾는 데 강점을 가질 수 있고, Keyword Search는 정확한 단어·식별자·키워드 검색에 강점을 가질 수 있다. 따라서 두 방식을 함께 사용하여 Retrieval 품질을 높일 수 있다. *** ### Reranking Retrieval 결과가 너무 많다면 1차 검색 결과를 다시 정밀하게 평가할 수 있다. 예를 들어, ``` Retriever ↓ 20 documents ↓ Reranker ↓ Top 5 ↓ LLM ``` 과 같이 구성할 수 있다. 개념적으로, ``` Embedding / Retrieval = 빠른 1차 후보 검색 Reranker = 후보 문서에 대한 정밀한 관련성 평가 ``` 라고 이해하면 된다. 따라서 Reranking은 검색 결과의 관련성을 다시 평가하여 최종적으로 LLM에 제공할 Context 후보를 줄이는 데 활용할 수 있다. *** ## 5-3. Embedding → LLM 과정에서 고려할 요소 AI 시스템을 구축할 때는 단순히 "어떤 LLM이 가장 좋은가?"만 고민해서는 안 된다. 예를 들어 Embedding Model과 LLM만 고려하더라도 다음과 같은 구조가 된다. ``` 사용자 질문 │ ▼ ┌────────────────┐ │ Embedding Model│ └───────┬────────┘ │ ▼ Vector DB │ ▼ Vector Search │ ▼ 관련 문서 │ ▼ ┌───────────────┐ │ LLM │ └───────┬───────┘ │ ▼ 답변 ``` 이때 다음과 같은 질문이 필요하다. #### 1. Embedding Model ``` 어떤 모델로 문서를 벡터화할 것인가? ``` 그리고 이것은 다시 다음 질문으로 연결된다. ``` 어떤 데이터를 근거로 제공할 것인가? 문서를 어떻게 Chunking할 것인가? 어떤 형태로 구조화할 것인가? ``` #### 2. Vector DB / Search ``` 어떤 Vector Store를 사용할 것인가? 어떤 Search 방식을 사용할 것인가? Vector Search와 Keyword Search를 결합할 것인가? ``` #### 3. LLM ``` 어떤 LLM으로 최종 답변을 생성할 것인가? ``` #### 4. 모델의 추론/생성 설정 ``` 얼마나 많은 Context를 제공할 것인가? 출력 길이를 어느 정도로 제한할 것인가? 추론 수준 또는 reasoning effort를 어떻게 설정할 것인가? Latency와 Cost를 어느 정도 허용할 것인가? ``` 즉, AI 시스템에서 "모델 선택"은 하나의 선택이 아니다. ``` Embedding Model 선택 + Search 전략 선택 + Reranker 선택 + LLM 선택 + Context 구성 + Generation 설정 ``` 이 모든 요소가 함께 결과 품질에 영향을 미친다. *** ### Top-k Vector Search에서 `Top-k`는 검색 결과 중 상위 몇 개의 후보를 반환할지를 의미한다. 예를 들어, ``` Top-k = 3 ``` 이면 상위 3개의 후보 문서를 반환하고, ``` Top-k = 10 ``` 이면 상위 10개의 후보 문서를 반환한다. 다만 > Top-k가 높을수록 무조건 좋다. 라고 할 수 없다. 검색 결과가 너무 많아지면 관련성이 낮은 문서가 Context에 포함되어 Noise가 증가할 수 있다. 따라서 일반적인 구조는 다음과 같이 구성할 수 있다. ``` Vector Search ↓ Top-k 후보 ↓ Reranking ↓ 관련성이 높은 문서 ↓ Context ↓ LLM ``` 즉, **Recall을 확보하기 위한 후보 검색과 Precision을 높이기 위한 재정렬을 분리**할 수 있다. *** ## 5-4. RAG + LLM Harness 앞서 살펴본 컴포넌트를 조합하면 다음과 같은 AI 시스템을 구성할 수 있다. ``` ┌───────────────┐ │ AI System │ └───────┬───────┘ │ ┌──────────┴──────────┐ │ │ Model RAG │ │ ┌────┴────┐ ┌────┴────┐ │ │ │ │ LLM Embedding Retrieval Generation │ │ │ │ │ │ Vector Search LLM │ │ Attention Vector ``` 질문과 답변을 생성하는 LLM과 외부 문서를 검색하기 위한 Embedding Model을 분리할 수 있다. 전체 흐름은 다음과 같다. ``` User Query ↓ Embedding Model ↓ Vector Search ↓ Relevant Documents ↓ Context ↓ LLM ↓ Generation ↓ Answer ``` 정리하면, > **RAG와 Vector Search는 "모델 선택"이 아니라 LLM에 외부 지식을 공급하기 위한 시스템 구성 방식이다.** 그리고 RAG를 구성하는 과정에서 ``` Embedding Model + Vector Search + Reranker + LLM ``` 등을 각각 선택하게 된다. 따라서 하네스 엔지니어링은 단순히 모델을 고르는 것이 아니라, > **어떤 모델과 어떤 검색 방법과 어떤 Context를 조합하여 원하는 결과를 얻을 것인가** 를 설계하는 과정이라고 볼 수 있다. *** ## 5-5. Fine-tuning RAG와 Fine-tuning은 목적이 다르다. RAG는 모델의 파라미터를 변경하지 않고 외부 Context를 제공한다. ``` User Query ↓ Retrieval ↓ Context ↓ Base LLM ↓ Answer ``` 반면 Fine-tuning은 특정 데이터셋을 이용하여 모델의 파라미터를 추가로 학습시켜 특정 작업이나 출력 패턴에 적응시키는 방법이다. ``` Base Model ↓ Training Data ↓ Fine-tuned Model ``` 따라서 Fine-tuning을 단순히 > 실무 환경에 맞춰 모델을 재학습하는 것 이라고 표현하기보다는, > **특정 작업, 형식, 행동 패턴 또는 도메인 특성에 모델을 추가 학습시키는 방법** 이라고 이해하는 것이 정확하다. RAG와 비교하면 다음과 같다. | 목적 | RAG | Fine-tuning | | -------- | --------------------- | -------------------------------------- | | 최신 외부 정보 | 적합 | 정보 자체를 최신화하는 용도로는 비효율적 | | 회사 문서 | 적합 | 문서 자체를 지식 저장소로 사용하는 목적에는 일반적으로 RAG가 적합 | | 출력 형식 | Context/Prompt로 제어 가능 | 특정 형식의 학습에 활용 가능 | | 행동 패턴 | 제한적 | 특정 행동 패턴 학습에 활용 가능 | | 지식 업데이트 | 문서 교체/갱신 | 추가 학습 필요 | | 운영 난이도 | 상대적으로 낮음 | 상대적으로 높음 | 따라서 회사 규정처럼 자주 변경되는 정보를 답변하게 하려는 경우에는 모델을 매번 다시 학습시키는 것보다 RAG를 통해 최신 문서를 검색하도록 구성하는 방식이 일반적으로 적합하다. *** ## 5-6. LoRA / PEFT Fine-tuning의 비용을 줄이기 위해 Parameter-Efficient Fine-Tuning(PEFT) 계열 방법을 사용할 수 있다. 그중 대표적인 방법이 LoRA이다. ``` Base Model + LoRA Adapter ↓ Fine-tuned Behavior ``` LoRA는 모델의 모든 파라미터를 직접 업데이트하는 대신 별도의 저랭크 Adapter를 학습하여 적은 수의 파라미터를 조정하는 방식이다. 즉, ``` Full Fine-tuning = 많은 파라미터 업데이트 LoRA / PEFT = 일부 추가 파라미터 또는 Adapter 중심의 학습 ``` 이라는 차이가 있다. 따라서 LoRA는 Fine-tuning 자체와 완전히 별개의 개념이라기보다 **효율적으로 Fine-tuning하기 위한 대표적인 PEFT 방법**으로 이해하는 것이 적절하다. *** ## 5-7. OCR / Document AI RAG의 정확도를 높이기 위해서는 단순히 문서를 Vector DB에 넣는 것보다 **문서를 어떻게 추출하고 구조화하는가**가 중요할 수 있다. 특히 PDF, 스캔 문서, 계약서, 표, 이미지 등이 포함된 문서는 단순 텍스트 추출만으로 문서의 의미 구조를 제대로 보존하기 어려울 수 있다. 예를 들어, ``` 계약서 PDF ↓ OCR ↓ Layout 분석 ↓ Table 추출 ↓ Document Structure ↓ Chunking ↓ Embedding ↓ RAG ``` OCR은 **Optical Character Recognition**의 약자로 이미지 속 문자를 인식하여 기계가 처리할 수 있는 텍스트로 변환하는 기술이다. 다만 OCR 자체가 Document AI 전체를 의미하는 것은 아니다. ``` OCR = 문자 인식 Document AI = 문자 + Layout + Table + Structure + Metadata 등 문서 전체를 이해/추출하기 위한 처리 ``` 따라서 실제 RAG Pipeline에서는 OCR뿐 아니라 Layout 분석, Table 추출, 문서 구조 분석 등을 함께 사용할 수 있다. 결국 작은 전처리 차이가 Retrieval 결과와 최종 답변의 품질에 영향을 줄 수 있기 때문에 문서를 다루는 과정 자체도 중요한 엔지니어링 영역이다. *** ## 5-8. Semantic Search 단순한 문자열 일치보다 **의미적 유사성**을 기준으로 검색하는 것이 Semantic Search이다. 예를 들어 사용자가 ``` "DB 연결이 느리다" ``` 라고 질문했을 때 실제 원인이 ``` "Connection Pool Exhaustion" ``` 일 수 있다. 단순 Keyword Search라면 두 표현의 직접적인 단어 일치가 부족할 수 있다. 하지만 적절한 Embedding Model을 이용하면 의미적으로 관련된 문서를 검색할 수 있다. 따라서 ``` Keyword Search = 문자열 / 키워드 중심 검색 Semantic Search = 의미적 유사성 중심 검색 ``` 으로 구분할 수 있다. 실무에서는 둘을 함께 사용하는 Hybrid Search도 고려할 수 있다. *** ## 5-9. Graph RAG / Knowledge Graph 일반적인 RAG가 문서와 Chunk를 중심으로 정보를 검색한다면, 일부 문제에서는 **Entity와 Entity 간 관계**를 구조화하여 검색하는 것이 더 유리할 수 있다. 예를 들어, ``` Spring └─ Transaction └─ TransactionManager └─ DataSource ``` 와 같이 관계를 Graph로 표현할 수 있다. ``` Node = Entity Edge = Entity 간 관계 ``` 이러한 구조화된 관계 정보를 Retrieval 과정에 활용하는 접근을 Graph RAG 또는 Knowledge Graph 기반 RAG라고 부를 수 있다. 다만 Graph RAG가 일반 RAG보다 항상 정확한 것은 아니다. 도메인과 데이터 구조에 따라 일반 Vector Search, Hybrid Search, Knowledge Graph 등을 선택해야 한다. *** ## 5-10. Agentic RAG 기존의 단순한 RAG는 일반적으로 다음과 같은 흐름을 가진다. ``` Query ↓ Search ↓ Context ↓ LLM ↓ Answer ``` 하지만 복잡한 질문에서는 한 번의 검색 결과만으로 충분하지 않을 수 있다. 이때 Agent의 계획 및 반복 실행 구조를 Retrieval 과정에 적용할 수 있다. ``` Query ↓ Agent ↓ Search ↓ 결과 평가 ↓ 추가 Search ↓ 결과 평가 ↓ Final Context ↓ Final Answer ``` 즉, Agent가 검색 결과를 보고 ``` 현재 정보가 충분한가? ↓ 부족하다. ↓ 다른 검색을 수행한다. ↓ 결과를 다시 평가한다. ``` 와 같은 과정을 반복하도록 구성할 수 있다. 이를 Agentic RAG라고 이해할 수 있다. 중요한 점은 Agentic RAG가 **Embedding Model 자체를 Agent로 변경한다는 의미가 아니라**, Retrieval을 수행하는 전체 제어 흐름에 Agentic한 계획·도구 사용·반복 평가 구조를 적용한다는 점이다. *** ## 5-11. Self / Corrective RAG Corrective RAG는 검색 결과가 충분히 관련성이 있는지 평가하고, 부족하면 다시 검색하도록 구성하는 접근이다. ``` Question ↓ Retrieve ↓ Relevant? ├─ NO → Search Again │ └─ YES ↓ Answer ``` Agentic RAG와 비슷한 반복 구조를 가질 수 있지만, 초점이 다르다. ``` Agentic RAG = 검색 과정 전체의 계획·행동·반복에 초점 Corrective / Self-RAG = 검색 결과의 적절성 평가와 수정에 초점 ``` 따라서 둘은 서로 배타적인 개념이라기보다 함께 조합할 수도 있다. *** ## 6. 프롬프트 엔지니어링 이제 AI를 사용하는 가장 기본적인 입력 방식인 **Prompt**를 살펴보자. 가장 단순한 구조는 다음과 같다. ``` 질문 ↓ LLM ↓ 답변 ``` 그러나 질문을 어떻게 작성하느냐에 따라 결과가 달라질 수 있다. 예를 들어, ``` 너는 Java Backend 전문가다. 다음 규칙을 지켜라. 1. 사실과 추론을 구분한다. 2. 확실하지 않으면 불확실하다고 말한다. 3. 코드 예시는 Java 21 기준으로 작성한다. 질문: ... ``` 와 같이 모델의 역할, 제약조건, 출력 기준 등을 명시할 수 있다. 예를 들어 다음 두 질문은 요구사항이 매우 다르다. ``` 프로젝트를 구축해줘. ``` 와 ``` Web MVC 기반 REST API 서버를 구축하되, 공통 관심사는 Aspect로 처리하고, Clean Architecture 구조를 적용해줘. ``` 두 번째 질문은 모델이 고려해야 할 Context와 Constraint가 훨씬 명확하다. 따라서 Prompt Engineering은 단순히 "질문을 잘 쓰는 방법"이라기보다, > **모델이 원하는 작업과 출력 형식을 수행할 수 있도록 Instruction과 Context를 구성하는 방법** 으로 이해하는 것이 좋다. *** ## 6-1. Zero-shot 예시를 제공하지 않고 바로 작업을 요청하는 방식이다. ``` 다음 문장을 요약해라. ``` 입력에 대한 별도의 예시나 시범 출력 없이 작업 자체를 지시한다. ``` Instruction ↓ LLM ↓ Output ``` *** ## 6-2. Few-shot 몇 개의 입력과 출력 예시를 제공하여 모델이 원하는 패턴을 따라가도록 유도하는 방식이다. ``` 입력: A 출력: X 입력: B 출력: Y 입력: C 출력: ``` 이렇게 예시를 제공하면 모델이 원하는 답변의 형태나 패턴을 파악할 수 있다. 즉, ``` Few-shot = 예시를 Context로 제공하여 원하는 출력 패턴을 유도 ``` 라고 이해할 수 있다. *** ## 6-3. Chain of Thought 복잡한 문제를 여러 단계로 나누어 해결하도록 유도하는 접근을 Chain of Thought라고 부른다. 개념적으로는 다음과 같이 표현할 수 있다. ``` 문제 ↓ 분해 ↓ 중간 단계 ↓ 결론 ``` 다만 실무에서는 모델의 내부 추론 과정을 장문의 텍스트로 모두 출력하도록 요구하는 것보다, ``` 문제 분해 ↓ 구조화된 중간 결과 ↓ 검증 ↓ 최종 결과 ``` 와 같이 **검증 가능한 중간 산출물**을 요구하는 방식이 더 유용한 경우가 많다. 특히 중요한 것은 내부 추론 과정 전체를 그대로 노출하는 것과, 엔지니어링 관점에서 검증 가능한 중간 결과를 제공하는 것은 서로 다른 문제라는 점이다. 따라서 실무에서는 단순히 > "생각을 아주 길게 해서 답해라." 라고 하는 것보다, ``` 1. 요구사항 추출 2. 제약조건 확인 3. 해결안 생성 4. 결과 검증 5. 최종 답변 ``` 과 같이 검증 가능한 구조를 설계하는 것이 더 중요할 수 있다. *** ## 6-4. Structured Output Structured Output은 LLM의 결과를 특정 Schema에 맞추도록 제어하는 방법이다. 단순히 ``` JSON으로 응답해줘. ``` 라고 하는 것보다, ``` { "category": "BUG", "severity": "HIGH", "reason": "...", "recommendation": "..." } ``` 와 같이 명확한 Schema를 지정하는 것이 좋다. 이를 Application에 연결하면 다음과 같은 구조를 만들 수 있다. ``` LLM ↓ Structured Output ↓ JSON ↓ Jackson ↓ Java DTO ↓ Business Logic ``` 즉, LLM의 출력을 사람이 읽는 텍스트로만 사용하는 것이 아니라 **Application이 처리할 수 있는 구조화된 데이터**로 사용할 수 있다. 이렇게 하면 LLM을 일종의 API 컴포넌트처럼 Application에 연결할 수 있다. *** ## 6-5. Function Calling / Tool Calling LLM에게 단순히 질문하는 것이 아니라 Application이 제공하는 Tool을 호출할 수 있도록 구성할 수도 있다. 예를 들어, ``` LLM ├── search() ├── getWeather() ├── queryDatabase() ├── sendEmail() └── createTicket() ``` 사용자가 ``` 내 주문 상태 알려줘. ``` 라고 요청하면 LLM은 직접 데이터베이스를 아는 것이 아니라, Application이 제공한 Tool을 선택하여 호출할 수 있다. ``` User ↓ LLM ↓ Tool Call ↓ queryDatabase() ↓ Tool Result ↓ LLM ↓ Answer ``` 여기서 중요한 것은 Tool의 실제 실행 권한이 Application에 있다는 것이다. 따라서 Function Calling은 > **LLM이 외부 시스템의 기능을 호출하기 위한 인터페이스를 선택하고 인자를 생성하도록 하는 방법** 으로 이해할 수 있다. Function Calling은 Agent 시스템에서 중요한 구성요소가 될 수 있지만, > Function Calling 자체 = Agent 는 아니다. *** ## 7. Agent & Workflow ### Agent Agent는 단순히 AI Model을 의미하지 않는다. Agent는 일반적으로 **목표를 달성하기 위해 Model을 이용하여 계획을 세우고, Tool을 사용하고, 결과를 관찰하고, 다음 행동을 결정하는 실행 시스템**을 의미한다. 개념적으로 다음과 같이 표현할 수 있다. ``` Goal ↓ LLM ↓ Plan ↓ Tool ↓ Observation ↓ LLM ↓ Next Action ↓ Tool ↓ ... ↓ Final Answer ``` 예를 들어, > "이번 달 매출이 지난달보다 10% 이상 떨어졌는지 확인하고 원인을 분석해줘." 라는 요청을 받았다고 하자. 단순 LLM이라면 학습된 지식과 제공된 Context만으로 답변을 생성한다. Agent라면 다음과 같은 행동을 수행하도록 구성할 수 있다. ``` 사용자 질문 ↓ 목표 분석 ↓ 지난달 매출 조회 ↓ 이번달 매출 조회 ↓ 매출 비교 ↓ 관련 DB / 문서 검색 ↓ 원인 분석 ↓ 결과 검증 ↓ 최종 답변 ``` 즉, ``` Model = 추론/생성의 핵심 엔진 Agent = Model + State + Tool + Control Loop + Goal ``` 이라고 이해할 수 있다. 따라서 **Agent의 핵심 두뇌는 Model이지만 Agent와 Model은 동일하지 않다.** Agent는 Model을 이용하여 실제 작업을 수행하기 위한 상위 실행 구조다. *** ### Model-driven Control Agent의 중요한 특징 중 하나는 다음 행동을 개발자가 모두 고정하지 않고 **Model의 판단에 따라 다음 행동을 결정할 수 있다는 점**이다. ``` User ↓ Agent ↓ LLM ↓ "DB를 조회해야 한다." ↓ Tool Call ↓ Observation ↓ LLM ↓ "추가 검색이 필요하다." ↓ Tool Call ↓ ... ``` 이처럼 다음 행동 선택의 일부를 Model에 위임할 수 있다. 이를 Model-driven Control 관점에서 이해할 수 있다. *** ## Workflow Workflow는 Agent와 반대로 **개발자가 전체 실행 흐름을 명시적으로 정의하는 방식**이다. 예를 들어, ``` Step 1: 문서 분류 ↓ Step 2: 정보 추출 ↓ Step 3: DB 검증 ↓ Step 4: 결과 생성 ``` 와 같이 개발자가 실행 순서를 고정한다. ``` Workflow = Deterministic Control ``` 즉, ``` Agent = 다음 행동의 일부를 Model에게 결정시킴 Workflow = 개발자가 실행 흐름을 정의 ``` 로 구분할 수 있다. 실무에서는 둘 중 하나만 사용하는 것이 아니라 다음과 같이 섞어서 사용할 수 있다. ``` Workflow ├─ Step 1 ├─ Step 2 │ └─ Agent │ ├─ Tool A │ ├─ Tool B │ └─ 판단 └─ Step 3 ``` 즉, **결정성이 필요한 부분은 Workflow로 고정하고, 탐색이나 계획이 필요한 부분은 Agent에 위임**하는 방식이다. *** ## 8. Prompt Chaining 하나의 거대한 Prompt에 모든 작업을 넣는 대신 여러 Prompt를 단계적으로 연결하는 방법이다. ``` Prompt A ↓ 결과 ↓ Prompt B ↓ 결과 ↓ Prompt C ``` 복잡한 작업을 여러 작업으로 분리할 수 있다. 예를 들어, ``` 문서 ↓ 요약 ↓ 핵심 요구사항 추출 ↓ 테스트 케이스 생성 ↓ 코드 생성 ``` 와 같이 구성할 수 있다. 단순히 ``` 이 명세를 참고해서 API 로직을 생성해줘. ``` 라고 하는 것보다, ``` 1. 명세 요약 2. 핵심 요구사항 추출 3. 예외조건 추출 4. 테스트 케이스 생성 5. API Logic 생성 ``` 과 같이 단계를 분리하면 각 단계의 결과를 검증하고 다음 단계에 전달할 수 있다. 즉, > Prompt Chaining은 복잡한 작업을 여러 개의 명시적인 AI 처리 단계로 분해하는 방법이다. *** ## 9. Context Engineering & Context Window & Compression ### Context Engineering Prompt Engineering이 > "어떤 Instruction을 입력할 것인가?" 에 초점을 둔다면, Context Engineering은 더 넓은 관점에서 > **"어떤 정보를 어떤 구조와 순서로 모델에게 제공할 것인가?"** 를 고민한다. 예를 들어 API 로직을 설계한다고 하자. 단순히 ``` Java로 API를 만들어줘. ``` 라고 하는 것이 아니라, ``` System Instructions + User Request + Relevant Documents + Conversation History + Tool Results + Memory + Current State ``` 와 같은 다양한 정보를 Context로 구성할 수 있다. 예를 들어, ``` 현재 시스템 상태 의존성 DB Schema 기존 코드 API 요구사항 테스트 결과 에러 로그 ``` 등을 구조화하여 제공할 수 있다. 즉, ``` Context Engineering = 모델이 판단에 사용할 정보를 선택하고, 구조화하고, 우선순위를 정하고, 필요한 만큼 제공하는 엔지니어링 ``` 으로 이해할 수 있다. *** ## Context Window LLM은 한 번에 무한한 Context를 처리할 수 있는 것이 아니다. 따라서 모델이 처리할 수 있는 Context Window의 범위를 고려해야 한다. 개념적으로 다음과 같다. ``` ┌─────────────────────────────┐ │ System Instructions │ │ │ │ User Request │ │ │ │ RAG Documents │ │ │ │ Tool Results │ │ │ │ Conversation History │ │ │ │ Memory │ └─────────────────────────────┘ ``` Context가 너무 많다고 항상 결과가 좋아지는 것은 아니다. 특히 관련 없는 문서가 많이 포함되면 Noise가 증가하여 오히려 결과 품질이 떨어질 수 있다. 따라서 ``` Context의 양 ↓ 무조건 많게 ``` 가 아니라, ``` Relevant Context ↓ 필요한 정보만 ↓ 적절한 구조 ↓ LLM ``` 이 중요하다. *** ## Context Compression Context가 너무 많다면 다음과 같은 방법으로 줄일 수 있다. ``` 많은 문서 ↓ Relevant Documents 선택 ↓ 요약 ↓ 필요한 정보만 추출 ↓ LLM ``` 또는 ``` Conversation History ↓ Summary ↓ Compressed Context ↓ LLM ``` 와 같이 Context를 압축할 수 있다. 즉, > Context Compression은 모델의 Context 부담을 줄이면서 중요한 정보는 유지하기 위한 방법이다. *** ## 10. Memory Agent가 이전 상태를 유지할 필요가 있다면 Memory를 사용할 수 있다. 예를 들어, ``` 사용자 ↓ Agent ↓ 이전 대화 상태 ↓ 현재 질문 ↓ 답변 ``` 과 같이 이전 정보를 활용할 수 있다. Memory는 하나의 고정된 구현이 아니라 다양한 형태로 구성할 수 있다. ``` Short-term Memory Long-term Memory External State ``` 예를 들어, ``` Short-term Memory = 현재 작업/대화의 상태 Long-term Memory = 장기간 유지할 사용자/업무 정보 External State = DB / File / Cache / Vector Store 등의 외부 저장소 ``` 중요한 점은 Memory 역시 Context의 하나로 활용될 수 있다는 것이다. ``` Memory ↓ Context ↓ LLM / Agent ``` 따라서 Memory의 무분별한 축적은 오히려 Context Noise를 증가시킬 수 있으므로 무엇을 기억하고 언제 제공할 것인지가 중요하다. *** ## 11. MCP MCP는 **Model Context Protocol**의 약자이다. MCP는 AI Application이 외부 시스템의 **Tools, Resources, Prompts** 등을 표준화된 프로토콜을 통해 연결할 수 있도록 하는 개방형 표준이다. 쉽게 말하면, > **AI Application과 외부 시스템 사이의 표준화된 연결 규약** 이라고 이해할 수 있다. 개념적으로 다음과 같다. ``` MCP │ ┌────────┼────────┐ ↓ ↓ ↓ GitHub DB Slack │ │ │ └────────┼────────┘ ↓ AI ``` 예를 들어 MCP Server가 다음과 같은 Tool을 제공할 수 있다. ``` get_order() search_issue() create_ticket() query_database() ``` AI Application은 MCP Client를 통해 이러한 기능을 사용할 수 있다. MCP의 중요한 점은 단순히 "API 하나를 호출하는 라이브러리"가 아니라 **AI Application과 외부 Context/Tool을 연결하기 위한 공통 프로토콜**이라는 것이다. 현재 MCP는 Tools뿐 아니라 Resources와 Prompts 등을 포함하는 구조를 제공한다. *** ## 12. Harness Engineering 지금까지 AI 활용 방법을 살펴보면 반복적으로 등장하는 문제가 하나 있다. > **AI가 항상 원하는 결과를 생성한다고 보장할 수 있는가?** 답은 아니다. 따라서 실무에서는 단순히 Model의 성능만 보는 것이 아니라, ``` Context Tools Memory Workflow Evaluation Guardrails Observability Retry State Security ``` 등을 함께 설계해야 한다. 이러한 관점에서 Harness Engineering을 이해할 수 있다. Harness Engineering은 모델이 실제 Application 환경에서 작업을 수행하도록 **주변 실행 환경과 제어·검증 체계를 설계하는 엔지니어링 관점**이다. 예를 들어 코딩 Agent를 생각해보자. 기존의 단순한 사용 방식은 다음과 같을 수 있다. ``` User ↓ LLM ↓ Code ``` 하지만 실제 개발 환경에서는 다음과 같은 도구와 검증 체계가 필요하다. ``` ┌─ Repository ├─ Build ├─ Test ├─ Linter ├─ Git User → Agent ───────┼─ Browser ├─ Database ├─ Documentation ├─ Memory ├─ Context ├─ Guardrails └─ Evaluation ↓ Result ↓ Verification ↓ Retry ``` 이처럼 Agent에게 단순히 답변을 요구하는 것이 아니라 **실제 작업을 수행하고 결과를 검증할 수 있는 환경을 제공**하는 것이다. *** ## 12-1. Harness Engineering의 중요한 점 예를 들어 Coding Agent라면 다음과 같은 실행 환경을 구성할 수 있다. ``` 코드 생성 ↓ 컴파일 ↓ 테스트 ↓ 실패 ↓ 에러 분석 ↓ 수정 ↓ 테스트 ↓ 통과 ↓ 정적 분석 ↓ Diff 검토 ↓ 완료 ``` 이 구조에서 중요한 것은 Agent가 단순히 코드를 생성하는 것이 아니라, ``` 생성 ↓ 실행 ↓ 관찰 ↓ 검증 ↓ 수정 ↓ 재실행 ``` 이라는 폐쇄적인 Feedback Loop를 갖는 것이다. 따라서 Harness Engineering의 핵심은 단순히 > "더 똑똑한 모델을 사용한다." 가 아니라, > **모델이 실제 환경에서 행동하고, 결과를 관찰하고, 실패를 감지하고, 수정하고, 다시 검증할 수 있도록 실행 환경을 설계한다.** 는 데 있다. 결국 백엔드 엔지니어링에서 중요하게 생각하는 ``` 실행 상태 검증 재시도 예외처리 관측성 보안 ``` 등의 개념이 AI 시스템에서도 중요해진다. *** ## 13. Evals AI에게 질문하고 답변을 검증하는 과정은 사람이 직접 수행할 수도 있지만, 실제 서비스에서는 반복 가능한 평가 체계를 구축하는 것이 중요하다. 예를 들어, ``` 100개의 질문 ↓ AI 답변 ↓ Expected Answer / Expected Criteria ↓ Evaluation ``` 과 같이 구성할 수 있다. 여기서 평가 기준은 단순히 "정답인가?"만 존재하지 않는다. ``` 정확성 관련성 형식 준수 Tool 사용 성공률 Latency Cost Safety ``` 등 다양한 지표를 사용할 수 있다. 따라서 Evals는 > **AI 시스템이 원하는 수준의 결과를 지속적으로 생성하는지 측정하고 비교하기 위한 평가 체계** 라고 이해할 수 있다. *** ## 13-1. LLM as a Judge 평가를 다른 LLM에게 맡기는 방법도 있다. ``` Question ↓ Candidate Answer ↓ Judge LLM ↓ Score / Evaluation ``` 이 방법을 LLM-as-a-Judge라고 부른다. 그러나 Judge 역시 LLM이므로 * 편향 * 일관성 문제 * 평가 기준의 모호성 * 모델 간 평가 차이 등이 발생할 수 있다. 따라서 중요한 시스템에서는 ``` Deterministic Evaluator + Reference Answer + LLM Judge + Human Review ``` 등을 적절히 조합하는 것이 좋다. *** ## 13-2. Guardrails AI가 수행할 수 있는 행동과 출력에 제약을 두는 것이 Guardrails이다. 예를 들어, ``` 개인정보 필터 SQL Injection 방지 허용된 Tool만 사용 JSON Schema 검증 금지된 행동 차단 권한 검사 ``` 등을 적용할 수 있다. 이를 구조화하면, ``` User Input ↓ Input Guardrail ↓ LLM / Agent ↓ Tool ↓ Output Guardrail ↓ Response ``` 와 같이 구성할 수 있다. 중요한 점은 Guardrail이 단순한 Prompt 문장 하나가 아니라는 것이다. 보안이나 권한과 관련된 부분은 가능한 한 Application Layer에서 명시적으로 검증해야 한다. 예를 들어, ``` "DB를 조회해도 된다." ``` 라고 Prompt에 작성하는 것과 ``` Application ↓ Authorization Check ↓ Allowed Tool ↓ Database ``` 로 권한을 실제로 통제하는 것은 전혀 다른 문제다. 따라서 Guardrail은 Prompt 기반 제약뿐 아니라 **Schema Validation, Authorization, Tool 제한, Input/Output Filtering 등의 Application-level 제어**까지 포함하여 이해하는 것이 좋다. *** ## 14. AI Gateway 실무에서 여러 AI 모델을 사용한다면 Application과 Model 사이에 Gateway 계층을 둘 수 있다. ``` Application ↓ AI Gateway ├── GPT ├── Claude ├── Gemini └── Local LLM ``` AI Gateway는 다음과 같은 공통 기능을 제공할 수 있다. ``` Model Routing Rate Limit Retry Caching Logging Cost Tracking Fallback ``` 즉, Application이 각 모델의 API를 직접 호출하는 대신, ``` Application ↓ AI Gateway ↓ Model ``` 형태로 추상화할 수 있다. 이는 일반적인 API Gateway와 유사하게 공통 정책을 중앙화하는 방식으로 이해할 수 있다. *** ## 14-1. Model Routing 질문의 특성에 따라 다른 모델을 선택할 수도 있다. ``` 간단한 분류 ↓ 작은 모델 복잡한 추론 ↓ Reasoning Model 이미지 분석 ↓ Multimodal Model 코드 생성 ↓ Coding Model ``` 모델마다 * 품질 * Latency * Context Window * 비용 * Tool 사용 능력 * Multimodal 지원 여부 등이 다를 수 있기 때문에 모든 요청에 동일한 모델을 사용하는 것이 항상 최적은 아니다. 따라서 Model Routing을 통해 요청의 특성에 맞는 모델을 선택할 수 있다. ``` Request ↓ Classifier / Router ↓ ┌────────────┬──────────────┬──────────────┐ ↓ ↓ ↓ Small LLM Reasoning Multimodal Model Model ``` *** ## 15. RLHF / RLAIF & Distillation AI 시스템을 구축하는 방법뿐만 아니라 **모델 자체의 성능이나 행동 특성을 학습을 통해 변경하는 방법**도 존재한다. *** ### RLHF / RLAIF RLHF는 **Reinforcement Learning from Human Feedback**이다. 사람의 선호도나 피드백을 활용하여 모델의 행동을 조정하는 방식이다. RLAIF는 Human Feedback 대신 AI가 생성한 평가나 피드백을 활용하는 접근이다. 개념적으로 다음과 같이 볼 수 있다. ``` Pretraining ↓ Instruction Tuning ↓ Preference Optimization / RL ↓ Aligned Model ``` 이러한 과정은 모델 자체의 행동과 성능을 조정하는 **Model Training / Alignment 영역**에 가깝다. 따라서 일반적인 Application 개발자가 매 요청마다 직접 수행하는 Harness 구성과는 다른 레이어의 개념이다. *** ### Distillation 큰 모델의 출력이나 행동을 이용하여 작은 모델을 학습시키는 방법을 Knowledge Distillation이라고 한다. ``` Large Model ↓ Teacher ↓ Generated Examples ↓ Small Model ↓ Student ``` 예를 들어, ``` 큰 모델 = 높은 품질의 결과 생성 작은 모델 = 큰 모델의 결과를 학습 ↓ 실제 서비스 = 작은 모델 사용 ``` 과 같이 비용과 Latency를 줄이는 방향으로 활용할 수 있다. 즉, Distillation은 단순히 "큰 모델을 작게 만든다"는 의미가 아니라 **Teacher Model의 지식 또는 행동을 Student Model이 학습하도록 하는 방법**이다. *** ## 16. Quantization LLM은 내부적으로 많은 수치 파라미터를 사용한다. Quantization은 이러한 수치 표현의 정밀도를 낮추어 모델의 메모리 사용량이나 연산 비용을 줄이는 방법이다. 개념적으로, ``` FP32 ↓ FP16 / BF16 ↓ INT8 ↓ INT4 ``` 와 같이 더 낮은 정밀도의 표현을 사용할 수 있다. 장점은 다음과 같다. ``` 메모리 사용량 감소 추론 비용 감소 하드웨어 요구사항 감소 ``` 반면 지나친 Quantization은 모델 품질이나 정확도에 영향을 줄 수 있다. 따라서 ``` Memory / Cost ↕ Model Quality ``` 사이의 Trade-off를 고려해야 한다. *** ## 17. 멀티모달 AI가 텍스트만 처리하는 것이 아니라 여러 종류의 입력과 출력을 다루는 것을 Multimodal이라고 한다. 예를 들어, ``` Text Image Audio Video Code ``` 등을 처리할 수 있다. 개념적으로, ``` Multimodal Model / | \ Text Image Audio \ Video ``` 와 같이 여러 Modality를 하나의 시스템에서 처리할 수 있다. 또는 각 입력 유형에 따라 서로 다른 Model을 조합할 수도 있다. ``` Image ↓ Vision Model ↓ Structured Result ↓ LLM ↓ Answer ``` 따라서 Multimodal은 특정 하나의 모델 이름이라기보다 **여러 Modality를 처리할 수 있는 AI 시스템/모델의 특성**으로 이해하는 것이 적절하다. *** ## 18. Computer Use & Browser Agent Agent가 단순히 Application에서 제공하는 API나 함수만 호출하는 것이 아니라 **컴퓨터의 UI 또는 브라우저를 직접 조작하도록 구성**할 수도 있다. 이를 Computer Use라고 부를 수 있다. 예를 들어, ``` "채용 사이트에서 조건에 맞는 공고를 찾아 정리해줘." ``` 라는 요청이 있다고 하자. Agent가 Browser를 이용하여 ``` Browser ↓ Search ↓ Page ↓ Extract ↓ Filter ↓ Summarize ``` 와 같은 과정을 수행할 수 있다. 여기서 Browser Agent는 이러한 브라우저 상호작용을 수행하도록 구성된 Agent 시스템을 의미한다. 기존 API 기반 Tool Calling이 ``` LLM ↓ API ↓ Structured Result ``` 라면 Browser Agent는 ``` Agent ↓ Browser ↓ Web Page ↓ UI Interaction ↓ Observation ↓ Next Action ``` 과 같은 구조를 가질 수 있다. 따라서 Computer Use는 Agent가 실제 컴퓨터 환경에서 행동할 수 있도록 하는 능력 또는 Tool 계층이고, Browser Agent는 그 능력을 Browser 작업에 활용하는 Agent 시스템으로 이해하면 된다. *** ## 19. MCP + Agent + RAG 앞서 살펴본 MCP, Agent, RAG, Memory를 조합하면 보다 실제적인 AI Harness를 구축할 수 있다. ``` AI Agent │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ RAG MCP Memory ↓ ↓ ↓ 사내 문서 GitHub / DB 이전 상태 │ │ │ └──────────────┼──────────────┘ ↓ LLM ↓ Action ↓ Observation ↓ Evaluation ↓ Retry ``` 각 컴포넌트의 책임을 분리하면 다음과 같다. ``` LLM = 추론 및 생성 RAG = 외부 문서 기반 Context 제공 MCP = 외부 Tool / Resource / Prompt 연결 Memory = 이전 상태 저장 및 활용 Agent = 목표를 달성하기 위한 계획과 행동 제어 Harness = 이 전체 실행 환경과 검증 체계 ``` 즉, > **Agent가 중심이 되어 Model을 사용하고, RAG·MCP·Memory 등을 통해 필요한 Context와 Tool을 확보하며, Harness가 실행·검증·보안·관측·재시도 등의 환경을 제공한다.** 이러한 구조를 통해 단순한 질문-답변 시스템에서 실제 업무를 수행하는 AI Application으로 확장할 수 있다. *** ## 20. 정리 지금까지 살펴본 AI 기술을 하나의 계층 구조로 이해하면 다음과 같이 정리할 수 있다. > **주의:** 아래 7단계는 OSI 7 Layer처럼 실제 표준으로 정의된 계층이 아니다. AI Engineering의 개념을 학습하기 위해 기능별로 묶은 **개념적 분류**이다. | Layer | 핵심 기술 | 역할 | | ----- | ------------------------------------------ | ------------- | | 1 | Transformer / LLM | AI 모델 | | 2 | Prompt / Structured Output | 모델 입력 및 출력 제어 | | 3 | Embedding / Vector DB / Search | 의미 기반 검색 | | 4 | RAG / Knowledge Graph | 외부 지식 연결 | | 5 | Tool Calling / MCP | 외부 시스템 연결 | | 6 | Agent / Workflow / Memory | 작업 수행 및 상태 관리 | | 7 | Harness / Eval / Guardrail / Observability | 안정적인 실행·평가·운영 | 이를 다시 하나의 흐름으로 표현하면 다음과 같다. ``` ┌──────────────────────────────────┐ │ HARNESS │ │ │ │ Context / Tools / Tests / Evals │ │ Guardrails / Memory / Git │ │ Browser / Observability │ │ Retry / State / Security │ │ │ │ ┌────────────────────┐ │ │ │ AGENT │ │ │ │ │ │ │ │ LLM │ │ │ │ ↓ │ │ │ │ Action │ │ │ │ ↓ │ │ │ │ Observation │ │ │ │ ↓ │ │ │ │ Action ... │ │ │ └────────────────────┘ │ │ │ └──────────────────────────────────┘ ``` Harness는 이러한 관점에서 **AI Application 안에서 Model이나 Agent가 실제 작업을 수행할 수 있도록 Context, Tool, State, Evaluation, Guardrail, Observability 등을 제공하는 실행 환경**으로 이해할 수 있다. *** ## 21. 결론 AI도 결국 또 다른 의미의 Application으로 볼 수 있다. Application에서 ``` 책임 분리 상태 관리 입력 검증 권한 관리 실행 예외 처리 재시도 모니터링 테스트 ``` 가 중요하듯이 AI Application에서도 동일한 엔지니어링 문제가 발생한다. 특히 AI 시스템은 ``` Model ↓ Context ↓ Tool ↓ Action ↓ Observation ↓ Evaluation ↓ Retry ``` 와 같은 반복적인 실행 구조를 가질 수 있기 때문에 일반적인 소프트웨어 엔지니어링 원칙이 더욱 중요해진다. 결국 AI Engineering에서 중요한 것은 특정 모델의 이름을 외우는 것만이 아니다. ``` 어떤 Model을 사용할 것인가? ↓ 어떤 Context를 제공할 것인가? ↓ 어떤 Tool을 연결할 것인가? ↓ 어떤 Workflow / Agent를 사용할 것인가? ↓ 결과를 어떻게 검증할 것인가? ↓ 실패하면 어떻게 재시도할 것인가? ↓ 비용과 Latency를 어떻게 관리할 것인가? ↓ 전체 시스템을 어떻게 관측하고 보호할 것인가? ``` 이러한 질문에 답할 수 있는 능력이 AI Engineering의 중요한 기본기라고 볼 수 있다. 따라서 AI의 변화가 빠르더라도 특정 제품이나 모델에 종속되지 않고, ``` Architecture Model Context Retrieval Tool Agent Workflow Evaluation Guardrail Observability ``` 각각의 책임과 관계를 이해한다면 새로운 모델이나 새로운 AI 기술이 등장했을 때도 그 기술이 **어떤 계층에 해당하고, 기존 시스템의 어느 부분을 대체하거나 보완하는지** 판단할 수 있다. 결국 백엔드 엔지니어가 특정 Framework의 API만 외우는 것이 아니라 ``` HTTP TCP Thread Transaction Database Cache Message Consistency Architecture ``` 와 같은 기본 원리를 이해하는 것과 마찬가지로, AI Engineering 역시 ``` Transformer LLM Embedding Retrieval RAG Prompt Context Tool Agent Workflow Memory Evaluation Guardrail Harness ``` 각각의 역할과 연결 관계를 이해하는 것이 중요하다. **AI의 기술은 빠르게 변하지만, 문제를 분해하고 책임을 분리하고 실행을 검증하며 실패를 제어하는 엔지니어링의 기본 원리는 쉽게 사라지지 않는다.** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://leehyokyun.gitbook.io/openbook/7-1.-ai.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.