0. FDE와 첫 미팅의 여섯 단어

Forward Deployed Engineer(FDE)는 AI 제품을 한 고객의 실제 시스템 안에서 동작하게 만드는 엔지니어이며, 첫 미팅에서 가장 먼저 오가는 말은 LLM, RAG, MCP, 에이전트, 파인튜닝, 양자화 여섯 단어입니다. 이 장은 FDE가 어떤 일을 맡는지, 그 일이 어떤 순서로 진행되는지, 여섯 단어가 각각 어떤 문제의 해법인지를 한 번에 보여줍니다.

학습 동기: 이 장을 읽으면 FDE의 역할과 참여 단계를 설명할 수 있고, 고객이 "RAG입니까, 파인튜닝입니까?"라고 물을 때 여섯 단어를 구분해 첫 대답을 할 수 있습니다.
선행 가정: 없음. 프로그래밍 경험(API 호출, 서버와 클라이언트의 구분)이 있으면 읽기 쉽고, AI 지식은 전제하지 않습니다.

0.1 FDE는 누구인가

원문: Who is a Forward Deployed Engineer?

이 책은 FDE가 되려는 사람이 첫 고객 미팅에서 설명하고 결정할 수 있을 때까지의 지식을 순서대로 쌓습니다. 그 지식의 범위를 정하려면 먼저 FDE가 무엇을 하는 사람인지 정해야 합니다.

0.1.1 AI 엔지니어와의 차이: 제품을 만드는 사람 vs 한 고객에게 제품을 동작시키는 사람

**Forward Deployed Engineer(FDE)**는 고객과 직접 일하면서 AI 제품을 데모 단계에서 실제 운영 시스템으로 옮기는 소프트웨어 엔지니어입니다. 일하는 곳은 고객의 시스템, 데이터, 업무 흐름 안이며, 이 점이 제품 팀의 엔지니어와 갈리는 지점입니다.

원문의 구분은 한 문장입니다. AI 엔지니어는 대체로 제품을 만들고, FDE는 그 제품을 특정 고객 한 곳에서 동작하게 만든 뒤 배운 것을 제품 팀에 되돌려줍니다.

예를 들어 제품이 "문서 검색 답변 기능"이라고 하겠습니다. 제품 팀은 일반적인 문서를 가정하고 기능을 만듭니다. 고객 현장의 문서는 스캔한 PDF와 표가 섞여 있고, 부서마다 열람 권한이 다르며, 같은 용어를 부서마다 다른 뜻으로 씁니다. 이 차이를 하나씩 확인하고 맞추는 일이 FDE의 몫입니다.

• 데모와 운영의 간격: 데모는 준비된 질문 몇 개에 답하면 통과하지만, 운영은 예상하지 못한 질문, 오래된 문서, 권한 문제를 모두 견뎌야 합니다.
• 환류: 현장에서 반복해서 부딪힌 문제는 한 고객의 사정이 아니라 제품의 빈틈일 수 있으므로, 제품 팀에 전달하는 일까지가 역할에 들어갑니다.
• 실패 양상: 데모에서 멈추면 제품 엔지니어와 구별되지 않고, 고객 요구를 그대로 구현만 하면 제품 팀에 돌아가는 배움이 없습니다.

미팅에서 이 구분은 질문의 방향으로 드러납니다. 제품 이야기를 길게 하기 전에 "지금 문제가 어느 업무 흐름의 어느 지점에서 생깁니까?"를 먼저 묻는 것이 FDE의 기본 동작입니다.

0.1.2 엔지니어·문제 발굴자·신뢰 구축자

원문은 FDE를 세 가지로 풀어 말합니다. 세 역할 중 하나라도 비면 프로젝트는 서로 다른 방식으로 실패합니다.

• 엔지니어(An engineer): 운영용 코드를 작성하고, RAG 파이프라인과 에이전트를 만들고, API를 연동하고, 실제로 배포합니다.
• 문제 발굴자(A problem finder): 고객과 같은 자리에 앉아 실제 업무 문제를 이해하고, 막연한 요청을 명확한 완료 기준(definition of done)으로 바꿉니다.
• 신뢰 구축자(A trust builder): 평가와 수치로 시스템이 동작함을 증명하고, 안전과 보안을 지키며, 엔지니어와 경영진 양쪽에 트레이드오프를 설명합니다.

문제 발굴자의 일을 가상의 예로 보겠습니다. 고객이 "상담 업무를 AI로 줄이고 싶다"고 말합니다. 이 문장만으로는 만들 것이 정해지지 않으므로 질문을 이어갑니다.

두 번째 열의 숫자는 이 책이 만든 가상의 값이며, 실제 값은 고객과 함께 정하는 것이 요점입니다. 완료 기준이 없으면 끝나는 시점도, 성공했다고 말할 근거도 없습니다.

• 엔지니어만 있고 문제 발굴이 없을 때: 잘 만든 시스템이 고객이 원한 문제를 풀지 못합니다.
• 문제 발굴만 있고 엔지니어링이 없을 때: 정의는 정확하지만 동작하는 시스템이 나오지 않습니다.
• 신뢰 구축이 없을 때: 동작은 하지만 고객이 숫자로 확인하지 못해 도입이 멈춥니다. 수치로 보이는 일은 평가(8.1 참조)가, 안전과 보안은 가드레일(9.1 참조)이 받칩니다.

고객 현장에서는 세 역할을 하루 안에 오갑니다. 오전에는 업무 담당자에게 문제를 묻고, 오후에는 코드를 고치고, 저녁에는 경영진에게 수치를 설명하는 일이 한 사람의 일정에 함께 들어갑니다.

0.1.3 깊이보다 폭: 고객 앞에서 빠르게 판단하기 위한 지식 범위

원문은 FDE에게 깊이보다 폭이 더 필요하다고 말합니다. 고객 앞에서 빠르게 올바른 결정을 내리려면 LLM, RAG, 에이전트, 평가, 추론, 보안, 시스템 설계를 각각 판단에 쓸 수 있을 만큼 알아야 하기 때문입니다.

여기서 폭의 기준은 "구현할 수 있는가"가 아니라 "고객 질문에 근거를 들어 답하고 선택지를 가를 수 있는가"입니다. 이 책의 장 구성이 그 범위 그대로입니다.

폭이 필요한 이유는 고객 질문이 한 영역에 머물지 않기 때문입니다. "우리 서버에서 돌릴 수 있습니까?"라는 한 문장에는 모델 크기(0.4.6 참조), 메모리, 지연, 보안 요구가 함께 들어 있습니다.

• 폭이 좁을 때의 실패: 한 영역만 깊이 아는 엔지니어는 그 영역의 해법을 모든 문제에 적용합니다. 파인튜닝만 아는 사람은 모든 문제를 파인튜닝으로 풀려 합니다.
• 폭이 지나치게 얕을 때의 실패: 용어만 아는 상태에서는 선택지를 비교하지 못하고, 고객의 질문을 그대로 팀에 전달하는 데 그칩니다.
• 판단 기준: 각 영역마다 "왜 이 선택인가"를 한두 문장과 숫자 하나로 말할 수 있으면 폭이 충분합니다. 숫자 예로 70억 파라미터 모델의 가중치가 32비트에서 28GB라는 계산을 암산하는 정도입니다(0.4.6 참조).

이 장의 여섯 단어는 폭의 입구입니다. 각 단어가 어떤 문제의 해법인지만 구분해도 첫 미팅의 대화는 길을 잃지 않습니다.

0.2 FDE 참여 생애주기

원문: The FDE Engagement Lifecycle

원문은 거의 모든 FDE 참여가 같은 경로를 따른다고 말하며, 이 책의 장 순서도 그 경로에 맞춰져 있습니다. 어느 장이 어느 단계의 일에 쓰이는지 알면 지금 읽는 내용이 현장의 어느 순간에 필요한지 가늠할 수 있습니다.

일곱 단계와 장의 대응

한 번의 참여는 문제를 이해하는 단계에서 시작해 실제 사용 사례를 완성하는 단계로 끝납니다. 책의 장 번호는 원문 저장소의 Step 번호와 같습니다(Step N은 이 책의 N장).

flowchart LR
    A["발견<br/>0장"] --> B["도구 파악<br/>1~3장"]
    B --> C["프로토타입<br/>4~7장"]
    C --> D["가치 증명<br/>8장"]
    D --> E["견고화<br/>9~11장"]
    E --> F["배포<br/>12장"]
    F --> G["실전 사례<br/>13장"]

그림 0.2 — 한 번의 참여는 발견에서 시작해 실전 사례로 끝나는 일곱 단계이며, 책의 장 순서가 이 단계를 따릅니다.

14장은 일곱 단계에 들어가지 않습니다. FDE 면접 준비라는 별도의 목적을 가진 장이며, 참여 경로의 일부가 아니라 이 직무에 지원하는 단계에서 쓰입니다.

단계별로 고객이 묻는 것과 막히는 곳

각 단계는 고객에게서 나오는 질문이 다르고, 막히는 지점도 다릅니다. 아래는 원문의 단계 정의에서 끌어낸 판단 질문입니다.

• 발견: "성공은 어떤 모습입니까?"를 합의합니다. 완료 기준이 없으면 이후 모든 단계가 서로 다른 목표를 향합니다(0.1.2 참조).
• 도구 파악: "AI로 이것이 됩니까?"에 답합니다. 못 하는 일을 된다고 말하면 이후 단계 전체가 무너지므로, 가능과 불가능의 경계와 이유를 설명할 수 있어야 합니다.
• 프로토타입: 며칠 안에 고객 데이터 위에서 동작하는 것을 보여줍니다. 가장 흔한 산출물은 고객 문서에 답하는 RAG 시스템입니다(5장 참조).
• 가치 증명: 데모의 인상이 아니라 평가 숫자로 말합니다. 숫자가 없으면 경영진의 도입 결정이 멈춥니다(8.1 참조).
• 견고화: 데모를 통과한 시스템을 안전, 보안, 지연, 비용의 현실에 맞춥니다. 프롬프트 인젝션이나 느린 응답은 이 단계에서 드러납니다(9.2, 10.1 참조).
• 배포: 모델을 클라우드에 둘지 고객 서버나 기기에 둘지 결정합니다(12.6 참조).
• 실전 사례: 모든 단계를 통과한 하나의 시스템을 봅니다. 이 책에서는 실시간 음성 AI 에이전트가 그 예입니다(13.1 참조).

예를 들어 같은 "고객 문서 답변" 프로젝트가 단계마다 다른 질문을 만납니다. 발견에서는 "어떤 질문에 답해야 합니까?", 프로토타입에서는 "문서를 어떻게 잘라 검색합니까?", 가치 증명에서는 "정답률을 무엇으로 셉니까?", 견고화에서는 "문서 안의 악성 지시문을 어떻게 막습니까?", 배포에서는 "고객 서버에서 돌릴 수 있습니까?"가 나옵니다.

순서가 뒤집힐 때의 실패

순서는 고정된 규칙이 아니라 의존 관계입니다. 앞 단계를 건너뛰면 뒤 단계에서 비용이 되어 돌아옵니다.

이 책의 장 순서를 그대로 따라 읽는 이유도 같습니다. 도구 파악 단계의 지식(1~3장)이 없으면 프로토타입 단계의 선택(4~7장)을 설명하기 어렵고, 그 선택을 설명하지 못하면 가치 증명(8장)에서 무엇을 측정할지 정하지 못합니다.

현장에서는 지금 어느 단계에 있는지를 스스로 묻는 습관이 판단을 돕습니다. 고객이 단계를 건너뛰어 "벌써 배포 이야기를 해도 되겠습니까?"라고 물으면, 가치 증명의 숫자가 있는지부터 되묻는 것이 안전한 대응입니다.

0.3 이 로드맵을 쓰는 법

원문: How to Use This Roadmap

이 책은 한 번 읽고 덮는 책이 아니라 같은 내용을 여러 번 돌려 읽는 책입니다. 원문 로드맵의 사용법 다섯 줄이 이 책의 읽기 규칙이 되었으며, 아래에서 그 규칙을 반복학습 절차로 풀어 씁니다.

읽는 순서와 책의 구조

원문이 정한 규칙은 네 가지입니다.

• 단계는 주어진 순서대로 따라갑니다. 각 단계는 앞 단계 위에 쌓입니다.
• 한 단계 안에서도 글을 주어진 순서대로 읽습니다. 글 하나가 개념 하나를 쉬운 말과 예시로 설명합니다.
• 같은 주제의 영상이 있으면 해당 글 바로 아래에 나열됩니다. 글을 읽고 영상을 보거나, 그 반대 순서로 보면 됩니다.
• 모든 글은 초보자를 위해 쓰여 있고, 전문 용어와 사전 지식을 전제하지 않습니다.

이 책에서는 그 규칙이 다음 형태로 구현되어 있습니다.

각 절 머리의 원문: 링크는 그 절이 재서술한 글이고, 영상: 줄이 있으면 같은 주제의 영상입니다. 글을 먼저 읽고 영상으로 확인하거나, 영상으로 윤곽을 잡고 글로 세부를 확인하는 두 방식 모두 원문이 허용합니다.

장 끝 질문 목록: 통과 기준

원문은 각 단계가 끝날 때마다 스스로에게 묻도록 합니다. "내일 고객이 이것을 물어도 설명하고 결정할 수 있는가?" 대답이 그렇다면 다음으로 넘어갑니다.

이 질문은 두 조건으로 나눌 때 사용하기 쉽습니다.

• 설명할 수 있는가: 개념을 개발자가 아닌 고객 담당자에게 두세 문장으로 말할 수 있습니다. 용어를 정의 없이 쓰지 않고 예시 하나를 곁들입니다.
• 결정할 수 있는가: 선택지를 둘 이상 늘어놓고, 기준(비용, 지연, 정확도, 데이터 위치)과 근거 숫자로 하나를 고를 수 있습니다.

예를 들어 "사내 문서에 답하는 챗봇을 만들고 싶은데 RAG와 파인튜닝 중 무엇입니까?"에 통과한 상태는 이렇습니다. 문서가 자주 바뀌는지 묻고, 바뀐다면 재학습 없이 최신 문서를 읽혀야 하므로 RAG 쪽이라고 근거를 들어 답합니다(0.4.2, 0.4.5 참조). 용어를 외운 것과 이 답을 말할 수 있는 것은 다른 상태이며, 통과 기준은 후자입니다.

각 장의 마지막 절은 이 기준을 질문 목록으로 만든 것입니다. 질문마다 괄호로 돌아갈 절을 표시했으므로, 막히면 표시된 절로 되돌아가 다시 읽고 질문에 소리 내어 답해 봅니다.

반복학습 절차

한 번에 외우려 하지 말고 읽는 목적이 다른 세 번을 돌립니다. 각 회독의 통과 신호가 다음 회독으로 넘어가는 조건입니다.

회독 사이에는 모르는 부분을 지우는 대신 막힌 질문 번호를 기록해 두는 편이 좋습니다. 반복 때마다 같은 질문에서 막히면 그 질문이 가리키는 절이 약점이므로, 그 절만 다시 읽습니다.

• 순서를 건너뛸 때의 실패: 2장 없이 10장을 읽으면 KV 캐시(10.3 참조)나 Prefill(10.2 참조)이 어느 계산의 결과인지 보이지 않습니다. 각 장의 선행 가정 박스가 필요한 앞 절을 표시합니다.
• 글만 읽고 숫자를 직접 계산하지 않을 때의 실패: 이 책의 예제는 대부분 암산으로 검증할 수 있습니다. 모델 크기나 메모리처럼 숫자가 나오는 곳은 직접 곱해 보아야 판단의 근거가 됩니다.

이 책이 독자에게 요구하는 것과 요구하지 않는 것

원문은 사전 지식 없이 따라올 수 있다고 약속하고, 이 책도 같은 전제를 둡니다. 다만 책이 독자에게 요구하는 것은 있습니다.

• 요구하는 것: 순서대로 읽기, 장 끝 질문에 소리 내어 답하기, 숫자가 나오면 직접 계산하기.
• 요구하지 않는 것: 수학 전공 지식, 모델을 처음부터 구현한 경험, 특정 프레임워크에 대한 숙련.

이 책의 통과 기준은 읽은 분량이 아니라 질문에 답할 수 있는가입니다. 책을 한 번 더 읽는 것보다 질문 한 개에 다시 답해 보는 쪽이 기준에 더 직접적으로 닿습니다.

0.4 첫 미팅의 여섯 단어

원문: Step 0: Must Know
영상: AI Engineering Explained: LLM, RAG, MCP, Agent, Fine-Tuning, Quantization

AI 엔지니어링 대화에는 LLM, RAG, MCP, 에이전트, 파인튜닝, 양자화 여섯 단어가 반복해서 나옵니다. 이 영상은 약 3시간 분량의 라이브 강의이며, 여섯 단어를 "AI 튜터" 하나를 만들어 가는 과정에서 각각 앞 단어의 한계를 푸는 해법으로 소개합니다. 아래 설명은 그 흐름을 재서술한 것이고, 영상 방송 시점 기준의 수치와 제품 상황이 섞여 있습니다.

모델을 만드는 일과 모델을 쓰는 일

영상은 먼저 머신러닝과 AI 엔지니어링을 구분합니다. 이 구분이 이후 여섯 단어를 읽는 좌표입니다.

• 머신러닝(모델을 만든다): 머신러닝 엔지니어가 알고리즘과 수학으로 모델 코드를 쓰고 데이터를 먹여 학습시킵니다. 연구와 수학이 중심입니다.
• AI 엔지니어링(모델을 쓴다): 안드로이드, 백엔드, 데브옵스 개발자 누구나 할 수 있는 일로, 이미 만들어진 모델을 실제 제품에서 동작하게 만듭니다. 파인튜닝, 양자화, MCP, RAG, 벡터 DB, 시스템 설계가 여기에 속합니다.

FDE의 일은 두 번째에 해당합니다. 고객 앞에서 모델을 새로 만들자는 이야기는 거의 나오지 않으며, 이미 있는 모델을 그 고객의 문제에 맞게 쓰는 방법이 대화의 주제입니다.

같은 AI 튜터로 보는 변화: 링크에서 설명으로

영상의 예제는 AI 튜터입니다. 사용자가 "L1, L2 손실 함수"를 입력하면 설명이 나오는 화면이며, 안드로이드, iOS, 웹 어디에든 만들 수 있습니다. 구조는 일반적인 앱과 같습니다. 화면(클라이언트)이 서버를 호출하고, 서버가 응답을 받아 화면에 보여줍니다.

LLM 이전의 방식과 이후의 방식은 서버가 받는 결과가 다릅니다.

이 변화를 구현하려면 첫 번째 단어인 LLM이 필요합니다.

여섯 단어의 지도

영상의 순서는 한 단어의 한계가 다음 단어를 불러오는 구조입니다. 책의 순서(에이전트가 파인튜닝보다 앞)는 원문 로드맵의 나열을 따르며, 아래 표는 단어별 한 줄 정의와 심화 위치를 모았습니다.

첫 미팅에서 나오는 세 질문

원문은 여섯 단어가 FDE의 첫 고객 미팅에서 나온다고 말하고, 대표 질문 셋을 듭니다. 질문마다 어느 단어가 열쇠인지 먼저 정해 두면 대화가 빨리 정리됩니다.

각 질문의 답은 아래 여섯 소절에서 구체화됩니다.

0.4.1 LLM

**LLM(Large Language Model)**은 영어나 한국어 같은 자연어를 이해하고 다음 글을 예측해 생성하는 언어 모델 가운데, 거대한 데이터로 학습했고 거대한 수의 숫자(파라미터)를 가진 것입니다. 언어 모델은 LLM 이전에도 있었습니다. 영상은 "large"가 붙는 이유로 두 가지를 듭니다. 인터넷 전반 수준의 거대한 데이터로 학습한다는 점, 그리고 학습 결과로 나오는 숫자(가중치) 개수가 거대하다는 점입니다.

폴더 두 개: model.py와 parameters.bin

영상은 LLM의 정체를 폴더 하나로 단순화합니다. 모델 코드(model.py, 수백 줄 수준의 아키텍처 코드)와 학습 결과의 숫자를 담은 파일(parameters.bin)이 전부입니다. 이 숫자 파일을 가중치 또는 파라미터라고 부릅니다. 오픈소스 모델이 공개된다는 것은 이 두 가지가 공개된다는 뜻이고, 영상은 이 가운데 숫자 파일을 "금(gold)"이라고 표현합니다. 코드는 대체로 알려져 있으나, 같은 숫자를 직접 얻으려면 막대한 GPU 투자가 필요하기 때문입니다(1억 달러 수준이라는 영상 속 언급은 방송 시점 기준의 대략적 수치입니다).

숫자가 무엇인지는 부동산 중개인의 예로 이해할 수 있습니다. 과거 거래의 침실 수, 면적, 발코니 수와 가격을 모아 놓으면 가격 = w1 × 침실 + w2 × 면적 + w3 × 발코니 형태의 식을 만들 수 있고, 학습은 w1, w2, w3의 값을 찾는 과정입니다. 값을 찾으면 파일에 저장해 두고, 새 매물이 오면 파일에서 값을 읽어 식에 대입합니다. 아래는 이 책이 만든 가상의 숫자 예입니다.

LLM은 이와 같은 구조에서 w의 개수가 세 개가 아니라 수백만에서 수천억 개일 뿐입니다(가중치와 학습의 원리는 1.1 참조).

모델 크기는 곱셈 한 번이다

파일 크기는 파라미터 수 × 파라미터당 바이트로 계산합니다. 32비트(FP32)는 4바이트이므로 1,000억 개 파라미터는 100,000,000,000 × 4바이트 = 400GB입니다. 16비트로 낮추면 2바이트라서 200GB이고, 8비트면 1바이트라서 100GB입니다. 정밀도를 낮추면 크기가 줄어드는 대신 정확도가 일부 희생되며, 이 거래가 양자화의 출발점입니다(0.4.6 참조).

닫힌 방 안의 아이: 오프라인으로 동작하는 LLM

영상이 가장 강조하는 대목은 LLM이 인터넷 없이 동작한다는 사실입니다. 폴더 두 개를 노트북에 내려받고 인터넷을 끊어도 python model.py로 질문에 답합니다. 영상은 이를 "닫힌 방에 갇힌 아이"로 비유합니다. 언어를 배웠기에 말은 할 수 있지만, 방 밖으로 전화를 걸거나 웹을 열 수는 없습니다. 영상은 "LLM이 네트워크 호출을 한다"는 흔한 오해를 명확히 틀린 것으로 규정합니다.

내부 처리 순서도 짧게 보여줍니다. 입력 문장을 토큰(번호)으로 바꾸고, 각 번호를 숫자 목록인 임베딩으로 바꾸어 모델에 넣고, 나온 숫자를 반대 순서로 되돌려 글로 만듭니다(2.4, 2.6 참조). 기계는 글자가 아니라 숫자만 다루므로 앞뒤에 변환이 붙습니다.

학습 시점의 벽: 2020년에 학습한 모델에게 비트코인 가격을 물으면

모델이 2020년 데이터로 학습되었다면 현재 비트코인 가격을 알지 못합니다. 이때 모델의 반응은 두 가지입니다. 질문이 실시간 정보를 요구한다는 것을 알아채지 못하는 모델은 학습 시점 근처의 가격(영상의 예에서는 5만 달러대)을 현재 값처럼 말하고, 영리한 모델은 "실시간 정보라 제가 알 수 없습니다. 도구를 쓰셔야 합니다"라고 말합니다. 영상은 후자도 "모른다고 말할 수 있을 뿐, 직접 가져오지는 못한다"는 점을 강조합니다.

그러면 모델을 다시 학습시키면 되지 않느냐는 생각이 나오지만, 영상은 이를 틀린 방향으로 규정합니다. 재학습은 GPU를 쓰는 막대한 작업이라 실시간으로 반복할 수 없고, 다시 학습해도 가격은 계속 변하므로 곧 같은 문제가 생깁니다.

• 판단: 변하는 정보의 문제는 모델을 고치는 방식이 아니라 외부에서 가져오는 방식으로 풉니다(0.4.2 참조).
• LLM의 역할: 언어를 이해하고 답을 정리하는 두뇌로 쓰고, 정보 수집은 바깥에 맡깁니다.

고객 현장에서는 이 구분이 질문 두 개로 나타납니다. "이 모델이 언제까지의 데이터로 학습되었습니까?", "고객이 묻는 정보는 그 시점 이후에 바뀌었습니까?" 전자는 모델을 고르는 질문이고, 후자는 RAG가 필요한지 정하는 질문입니다(심화는 2.2 참조).

0.4.2 RAG

**RAG(Retrieval-Augmented Generation, 검색 증강 생성)**는 외부 소스에서 필요한 정보를 가져와(Retrieval) 모델의 컨텍스트에 덧붙이고(Augmented) 그것을 근거로 답을 생성하게(Generation) 하는 방식입니다. 소스는 문서, PDF, 데이터베이스, 웹 API 어느 것이든 됩니다. 영상은 이름을 쪼개 설명합니다. Retrieval은 외부에서 관련 정보를 가져오는 일이고, Augmented는 가져온 정보를 모델 입력에 더하는 일이며, Generation은 모델이 근거 있는 문장으로 답을 만드는 일입니다.

비트코인 예: 서버가 가져오고, LLM이 문장을 만든다

흐름은 네 단계입니다. 사용자가 현재 비트코인 가격을 묻고, 서버가 가격 API를 호출해 6만 5천 달러 같은 숫자를 받고, 서버가 LLM에게 "사용자 질문은 이것이고 API 결과는 이것이니 사용자에게 줄 답을 만들라"고 요청하고, LLM이 "현재 비트코인 가격은 65K달러입니다(실시간 데이터 기준)" 같은 문장을 돌려줍니다(숫자는 영상 방송 시점의 값입니다).

flowchart LR
    U["사용자 질문"] --> S["서버"]
    S -->|"1. 가져오기"| A["가격 API 등 외부 소스"]
    A -->|"2. 숫자 반환"| S
    S -->|"3. 질문 + 가져온 정보"| L["LLM"]
    L -->|"4. 근거 있는 답 생성"| S
    S --> U

그림 0.4.2 — RAG에서 LLM은 직접 가져오지 않고, 서버가 가져온 정보를 받아 문장으로 만듭니다.

여기서 외부 API 호출처럼 모델 바깥의 기능을 부르는 것을 영상은 **도구(tool)**라고 부릅니다(6.2 참조). LLM이 스스로 못 하는 일을 코드가 대신하는 셈이며, 모델의 지식과 가져온 데이터를 결합해 한 번에 답을 만드는 것이 RAG입니다.

긴 문서는 통째로 넣지 않는다: 조각, 임베딩, 벡터 DB

영상의 다음 예는 100~300쪽짜리 PDF 교재에서 "반사"를 설명하는 질문입니다. 전체를 모델에 넣으면 두 가지 문제가 생깁니다. 응답이 느려지고, 문서가 컨텍스트 윈도우보다 길면 들어가지 않습니다. 영상은 컨텍스트 윈도우의 한계가 계속 커지고 있다고 전제하면서, 관련 없는 내용을 같이 넣는 것은 여전히 비효율이라고 지적합니다(2.16 참조).

해법은 필요한 조각만 골라 넣는 것입니다.

1. PDF를 여러 개의 조각(chunk)으로 자릅니다. 영상의 예는 10쪽을 100개의 조각으로 자르는 경우입니다.
2. 임베딩 모델로 각 조각을 숫자 목록으로 바꿔 텍스트와 함께 벡터 DB(5.1 참조)에 저장합니다. 벡터 DB는 숫자 목록 간의 거리를 빠르게 찾도록 최적화된 저장소입니다.
3. 질문도 같은 방식으로 숫자로 바꾸고, 가까운 조각을 요청합니다. 영상의 예에서는 질문과 가까운 조각이 2번과 3번이며, 나머지는 멀리 있습니다.
4. 가까운 조각 2개만 모델에 넣습니다.

100개 중 2개만 넣으므로 입력의 98%를 줄이고(2 ÷ 100 = 2%), 응답이 빨라지며 컨텍스트 윈도우 문제도 피합니다. 조각 수, 몇 개를 가져올지(top-k)는 설정값이며 영상은 2개, 3개, 5개를 모두 예로 듭니다(5.1, 5.6 참조).

고객이 RAG를 묻는 순간과 판단

• 고객 질문의 신호: "최신 정보를 반영해야 합니다", "우리 사내 문서로 답해야 합니다", "근거를 보여주어야 합니다."
• RAG가 맞는 경우: 정보가 자주 바뀌거나 비공개이고, 매번 모델을 다시 학습할 수 없을 때입니다.
• RAG만으로 부족한 경우: 문서에서 찾아야 하는 정보가 없는 질문, 또는 말투·형식 같은 답변 방식 자체를 바꾸려는 요구입니다(0.4.5 참조).
• 실패 양상: 조각이 질문과 어긋나게 잘리거나 엉뚱한 조각이 선택되면, 모델이 잘못된 근거로 자신 있게 답합니다. 그래서 가져오는 단계의 품질을 별도로 측정해야 합니다(8.1 참조).

0.4.3 MCP

**MCP(Model Context Protocol)**는 AI 애플리케이션을 외부 시스템에 연결하기 위한 개방형 표준 프로토콜입니다. 영상의 비유는 단순합니다. 웹에서 서로 다른 기계가 소통하는 표준이 HTTP이듯, AI 맥락에서의 표준이 MCP입니다. 서버를 만드는 사람이 정해진 방식으로 기능을 노출해 두면 어떤 AI 애플리케이션이든 같은 방식으로 붙을 수 있습니다.

문제: 서버가 두뇌가 되어 버린다

영상은 RAG를 구현해 가는 과정에서 생기는 문제를 직접 보여줍니다. 서버가 비트코인 질문은 가격 API로, 검색 결과 기반 질문은 검색 API로, 동영상 기반 질문은 동영상 API로 보내야 한다고 하겠습니다. 서버에는 if 가격 질문이면 ... else if 검색 질문이면 ... else if 영상 질문이면 ... 같은 분기가 요청 유형마다 늘어납니다. 사용자의 의도를 판별하는 지능이 서버 코드에 쌓이는 셈이며, 영상은 이것이 피해야 할 방향이라고 말합니다.

해법은 판단을 LLM에게 넘기고 서버는 단순하게 만드는 것입니다. 이를 가능하게 하는 약속이 MCP입니다.

MCP 서버가 노출하는 메타데이터: 이름, 설명, 입력 스키마

MCP 서버는 자기가 제공하는 도구의 정보를 메타데이터로 공개합니다. 영상의 예(fetch crypto price)를 옮기면 세 가지입니다.

서버 내부에서 어느 API를 어떻게 부르는지는 서버를 만든 사람의 일이고, 사용하는 쪽은 메타데이터를 읽고 정해진 요청을 보내 결과를 받으면 됩니다. 같은 방식으로 검색 결과를 가져오는 서버, 동영상 정보를 가져오는 서버(입력은 검색어와 최대 결과 수)도 있습니다.

호출 흐름: 서버는 중개만 하고, 선택은 LLM이 한다

서버는 시작할 때 연결된 MCP 서버들의 메타데이터를 모두 읽어 보관합니다. 영상의 예에서 도구가 하나씩인 서버 3개이면 메타데이터 객체가 3개입니다. 사용자가 질문하면 흐름은 다음과 같습니다.

sequenceDiagram
    participant U as 사용자
    participant S as 서버(중개)
    participant L as LLM
    participant M as MCP 서버
    U->>S: 질문
    S->>L: 질문 + 모든 도구 메타데이터
    L-->>S: 이 도구를 이 인자로 호출하라
    S->>M: 도구 호출
    M-->>S: 도구 결과
    S->>L: 질문 + 도구 결과
    L-->>S: 최종 답
    S-->>U: 답

그림 0.4.3 — LLM은 도구를 직접 호출하지 않고 "이 도구를 이 인자로 부르라"고 권고하며, 호출은 서버가 합니다.

LLM은 질문을 읽고, 도구들의 설명을 읽고, 관련 있는 도구를 고르고, 입력 스키마에 맞는 인자(검색어, 결과 수 5 같은 숫자)를 만들어 돌려줍니다. 서버는 그 권고대로 MCP 서버를 호출하고, 결과를 다시 LLM에게 보내 최종 답을 받습니다. 한 번의 호출로 끝나지 않을 때는 서버가 이 왕복을 반복하는 루프를 돌립니다. 영상은 이것이 LLM이 두뇌가 되는 방식이라고 말합니다.

PDF를 읽는 MCP 서버를 하나 더 붙이면 메타데이터가 4개가 되고, 서버 코드는 바뀌지 않으며 LLM이 늘어난 선택지 안에서 알아서 고릅니다. 이 서버 내부에서 벡터 DB를 써서 관련 조각 2개만 돌려주도록 만들면 앞 소절의 RAG 최적화가 MCP 서버 뒤에 숨습니다.

설명이 곧 라우팅이다

이 구조에서 도구 선택의 근거는 LLM이 읽는 설명 문장뿐입니다. 설명이 모호하거나 다른 도구의 설명과 겹치면 모델이 잘못된 도구를 고르거나 필요한 도구를 지나칩니다.

• 고객 현장의 점검 질문: 도구 설명이 사람이 아닌 모델이 읽기에 충분히 구체적인가, 도구끼리 설명이 겹치지 않는가, 입력 스키마가 인자의 형식을 정확히 제약하는가.
• 실패 양상: 서버에 분기 코드를 쓰지 않았으니 도구 선택이 틀려도 코드에서 잘못된 줄을 찾을 수 없고, 설명을 고쳐야 합니다.
• MCP와 일반 HTTP API의 차이: 영상은 MCP 서버가 일반 HTTP 서버와 비슷하되 메타데이터를 노출한다는 약속이 추가된 것이라고 설명합니다. 공식 명세는 MCP 메시지를 JSON-RPC로 인코딩하며, 표준 전송 방식으로 stdio와 Streamable HTTP 두 가지를 정의합니다.

외부 시스템이 많은 고객일수록 MCP는 가치가 커지지만, 도구 수가 늘면 모델이 읽어야 할 메타데이터도 입력에 늘어납니다(구조와 함수 호출은 6.2, 6.9 참조).

0.4.4 Agent

**에이전트(AI Agent)**는 도구를 사용하고, 판단을 내리고, 여러 행동을 취해 복잡한 일을 사용자 대신 끝내는 시스템입니다. 영상의 정의는 코드 수준에서 구체적입니다. 도구를 쓰고, 두뇌(LLM)로 결정을 내리고, 여러 단계를 거쳐 복잡한 작업을 끝내는 코드는 무엇이든 AI 에이전트라고 부를 수 있다는 것입니다. 언어도 라이브러리도 무관합니다.

정의는 '대신 해주는 코드'다

영상의 비유는 여행사 직원입니다. 항공권을 직접 예약하는 대신 "델리에서 싱가포르로 가는 비행기를 잡아 달라"고 맡기면, 그 사람이 대신 일하는 에이전트입니다. AI 에이전트도 같은 위치입니다. 영상이 든 코드의 예는 매일 아침 내 분야의 채용 공고를 검색하고, 공고 설명을 읽고, 내 이력서를 공고에 맞게 고치고, 이력서를 올려 지원하는 10~100줄 정도의 코드입니다. 이 코드가 도구를 부르고(검색, 업로드), LLM이 판단하고(어느 공고에 어떻게 맞출지), 여러 행동을 이어가므로 에이전트입니다.

앞 소절의 AI 튜터 서버도 같은 기준으로 에이전트입니다. 서버는 MCP 도구를 쓰고, LLM에게 어떤 도구를 쓸지 판단받고, 질문 전달, 도구 호출, 결과 정리라는 여러 행동을 거쳐 복잡한 질문을 끝냅니다.

flowchart LR
    Q["사용자 요청"] --> D{"LLM이 판단"}
    D -->|"도구 필요"| T["도구 호출"]
    T --> R["결과를 컨텍스트에 추가"]
    R --> D
    D -->|"충분함"| F["최종 답"]

그림 0.4.4 — 에이전트는 판단과 도구 호출을 반복하다가, 충분하다고 판단되면 답으로 끝납니다.

라이브러리와 개념: 먼저 개념, 나중에 프레임워크

에이전트 코드는 직접 쓰면 100~200줄이 되는 보일러플레이트를 LangChain(7.4 참조) 같은 라이브러리가 10~20줄 수준으로 줄여준다고 영상은 대략적으로 언급합니다. 이 줄 수는 외부 출처로는 확인하지 못했습니다. 다만 영상은 라이브러리보다 개념 이해가 먼저라고 거듭 말합니다. 쉬운 말로 설명하지 못하면 이해한 것이 아니라는 입장입니다.

고객이 "에이전트"라고 말할 때의 판단

고객이 말하는 에이전트는 영상의 정의에 비추어 세 질문으로 점검합니다.

• 도구가 있는가: 호출해야 할 외부 시스템(검색, 사내 DB, 결재 시스템)이 있는지.
• 판단이 필요한가: 순서가 늘 같으면 고정된 파이프라인으로 충분하고, 상황에 따라 다음 행동이 달라질 때만 LLM의 판단이 필요합니다.
• 여러 행동이 필요한가: 한 번의 답변이면 에이전트가 아니라 일반 질의응답입니다.

세 질문에 모두 "예"일 때 에이전트가 맞고, 아니면 더 단순한 구조가 더 싸고 안정적입니다. 영상 후반부의 조언도 같은 방향입니다. LLM은 작은 용도에는 과한 수단일 수 있으므로 어디에 쓸지보다 어디에 쓰지 않을지를 아는 것이 더 중요합니다. 사용자를 대신해 행동하는 만큼 권한과 안전 문제도 같이 따라옵니다(6.1, 6.3, 9.1 참조).

0.4.5 Fine-tuning

**파인튜닝(Fine-tuning)**은 이미 학습된 기반 모델(foundation model)을 특정 분야나 과제의 데이터로 추가 학습하는 과정입니다. 영상의 사례는 AI 튜터의 설명 방식입니다. 일반 모델이 "에폭(epoch)을 설명하라"는 질문에 일반적인 설명을 주는데, 특정 교육 기관의 설명 스타일로 답하게 하고 싶다고 하겠습니다. 인터넷 전체를 읽은 모델은 한 곳의 방식에 맞춰져 있지 않으므로, 그 기관의 글 200편 정도를 추가 학습시킵니다.

처음부터 학습하지 않는 이유

기반 모델은 이미 문법, 문장 구성, 일반 지식을 갖고 있습니다. 이를 처음부터 다시 만들려면 영상 속 1억 달러 규모의 투자가 필요하지만, 추가 학습은 더 빠르고 싸고 현실적입니다. 영상은 학습 코드도 몇 줄만 고치면 되고, 기존 parameters.bin을 메모리에 읽어 새 데이터로 학습한 뒤 updated parameters.bin으로 저장한다고 설명합니다.

핵심은 파라미터의 개수가 그대로라는 점입니다. 1,000억 개의 숫자가 이곳저곳에서 조금씩 바뀔 뿐입니다. 예를 들어 12.0이던 값이 13.25가 되는 식이며, 모델 파일의 크기는 같습니다. 추론할 때는 서버, MCP, 클라이언트는 그대로 두고 가중치 파일만 바꿔 끼웁니다.

언제 파인튜닝이고 언제 아닌가

영상의 질문 답변에서 나온 기준을 모으면 다음과 같습니다.

요약하면 RAG는 모델에게 모르는 정보를 보여주는 방식이고, 파인튜닝은 모델이 답하는 방식 자체를 바꾸는 방식입니다. 첫 미팅의 "RAG 아니면 파인튜닝?"에는 이 구분이 출발점입니다. 둘은 대체 관계가 아니라 함께 쓸 수도 있습니다. 파인튜닝의 절차와 한계는 11.1 참조로 이어집니다.

메모리가 결정하는 파인튜닝 방식: 전체 vs LoRA

파인튜닝은 학습이므로 메모리를 많이 씁니다. 영상은 학습이 추론보다 대략 4~6배 메모리를 쓴다고 말합니다(경사값, 옵티마이저 상태 등이 추가로 필요하기 때문). 전체 파인튜닝(full fine-tuning)도 같은 메모리를 요구합니다. 70억 파라미터 모델을 32비트로 두면 추론에 7 × 10⁹ × 4바이트 = 28GB가 들고, 전체 파인튜닝은 4배면 112GB, 6배면 168GB입니다. 64GB 노트북은 추론만 되고 전체 파인튜닝은 안 됩니다.

대안이 **PEFT(Parameter-Efficient Fine-Tuning, 파라미터 효율적 파인튜닝)**이며, 영상이 소개하는 첫 기법이 **LoRA(Low-Rank Adaptation)**입니다. 기반 모델은 얼려 두고(바꾸지 않고), 별도로 추가한 소수의 숫자만 학습합니다(11.2 참조). 영상은 추가 메모리가 추론의 약 1.1배 수준이라고 설명합니다. 이 배율은 외부 출처로는 확인하지 못했습니다.

LoRA는 전체 파인튜닝보다 정확도가 낮을 수 있고, 이 배율은 영상이 든 대략적 규칙이므로 실제 값은 모델과 설정마다 다릅니다. 고객이 "우리 GPU로 파인튜닝할 수 있습니까?"라고 물으면 파라미터 수, 정밀도, 전체냐 LoRA냐부터 확인합니다(11.2 참조).

0.4.6 Quantization

**양자화(Quantization)**는 모델을 이루는 숫자의 정밀도를 낮춰 모델 크기를 줄이는 기법이며, 작은 기계에서 모델을 돌리려는 목적에 씁니다. 영상의 절차는 단순합니다. 숫자를 하나 읽고, 정밀도가 낮은 형식(예: 32비트에서 16비트)으로 바꿔서, 같은 파일이나 새 파일에 쓰는 일을 반복합니다. 메모리가 모자라면 덩어리로 나눠 읽을 수 있습니다.

정밀도와 크기

같은 1,000억 파라미터 모델도 정밀도에 따라 크기가 달라집니다(파일 크기 = 파라미터 수 × 바이트).

정밀도가 낮아지면 메모리가 줄고, 영상 설명으로는 속도도 빨라집니다. 대가는 정확도의 일부입니다. 영상은 어느 정밀도가 맞는지는 실험으로 정하라고 말합니다. 가진 기계, 사용자에게 줄 품질, 운영 비용이 함께 결정 요인입니다. 모델 배포 사이트에서 모델 이름에 q4_K_M처럼 q로 시작하는 표시가 붙은 항목이 양자화된 버전이라는 설명도 나옵니다. 파라미터 수가 같은 채팅용 모델도 양자화 여부에 따라 파일 크기가 달라집니다(10.8 참조).

추론은 몇 배, 학습은 몇 배

영상은 이 계산을 "내 노트북에서 이 모델이 돌아가는가"에 바로 적용합니다. 추론(prediction)은 가중치만 올리면 되고, 학습과 전체 파인튜닝은 4~6배가 필요합니다.

8비트로 양자화한 뒤 추론은 16GB 노트북에서 돌릴 수 있지만, 전체 파인튜닝은 여전히 안 됩니다. 이 표의 숫자는 가중치 기준 계산이므로, 실제 실행에는 추가 메모리가 더 필요합니다.

양자화 + LoRA: 작은 기계에서 파인튜닝

그래서 영상은 둘을 합치는 방법을 보여줍니다. 먼저 모델을 8비트로 양자화해 28GB를 7GB로 줄이고, 그 위에 LoRA를 적용합니다. 이 조합을 양자화 LoRA(QLoRA)라고 부릅니다. 다만 영상의 8비트는 계산을 쉽게 하려는 예이고, 이 이름을 붙인 원 논문(Dettmers 등, 2023)의 QLoRA는 기반 모델을 4비트(NF4)로 양자화합니다. 영상의 계산으로는 추론의 약 1.1배이므로 7 × 1.1 = 7.7GB, 곧 약 8GB가 되어 16GB 노트북에서도 파인튜닝이 가능합니다.

flowchart LR
    A["70억, 32비트<br/>28GB"] -->|"양자화(8비트)"| B["7GB"]
    B -->|"LoRA 추가"| C["약 8GB<br/>(7 × 1.1)"]
    C --> D["16GB 노트북에서 파인튜닝"]

그림 0.4.6b — 양자화로 모델을 줄인 뒤 LoRA를 얹으면 작은 기계에서 파인튜닝이 됩니다.

대가는 정확도입니다. 이미 정밀도를 낮춘 모델을 추가로 조정하는 것이므로, 영상은 기계의 한계, 사용자에게 줄 정확도, 사용 사례 사이의 균형을 잡으라고 말합니다.

"우리 서버에서 돌릴 수 있나?"의 계산

세 번째 첫 미팅 질문은 이 소절의 계산으로 시작합니다. 순서는 네 단계입니다.

1. 모델의 파라미터 수를 확인합니다. 70억이든 700억이든 숫자 하나입니다.
2. 정밀도를 정합니다. 32비트는 4바이트, 16비트는 2바이트, 8비트는 1바이트입니다.
3. 곱해서 가중치 크기를 구합니다. 70억 × 2바이트 = 14GB 같은 식입니다.
4. 용도를 정합니다. 추론이면 이 크기에 여유를 더하고, 파인튜닝이면 전체는 4~6배, LoRA는 약 1.1배를 곱합니다.

이 계산으로 가능, 불가능, 양자화하면 가능을 빠르게 가릅니다. 정확한 판정에는 실제 실행에 필요한 추가 메모리, 응답 속도, 동시 사용자 수가 더 필요합니다(10장, 12.6 참조).

0.5 고객이 내일 묻는다면

각 질문에 소리 내어 답해보고, 막히면 표시된 절로 돌아가십시오. 로드맵이 제시한 통과 기준은 "내일 고객이 물어도 설명하고 결정할 수 있는가"입니다.

1. "저희는 AI 엔지니어 한 분이 이미 있는데, FDE는 무엇이 다릅니까?" 제품을 만드는 일과 이 고객에게 동작시키는 일을 어떻게 구분합니까? (0.1.1)
2. "상담 업무를 AI로 줄이고 싶습니다." 막연한 요청을 무엇으로 좁힙니까? 완료 기준을 어떻게 만듭니까? (0.1.2)
3. "지금 데모는 잘 되는데, 바로 배포해도 됩니까?" 지금이 생애주기의 어느 단계이고, 건너뛴 단계는 무엇입니까? (0.2)
4. "그 책을 몇 번 읽으면 FDE 미팅에 나갈 수 있습니까?" 통과 기준을 어떻게 판정합니까? (0.3)
5. "ChatGPT는 인터넷에서 답을 가져오는 거죠?" LLM이 실제로 무엇이고 무엇을 하지 못합니까? (0.4.1)
6. "RAG 아니면 파인튜닝?" 무엇을 되묻고 어떤 기준으로 가릅니까? (0.4.2, 0.4.5)
7. "도구가 열 개인데 서버에 분기 코드를 다 써야 합니까?" MCP는 무엇을 바꿉니까? 도구 설명은 왜 중요합니까? (0.4.3)
8. "에이전트가 할 수 있나?" 도구, 판단, 여러 행동이라는 세 조건으로 어떻게 점검합니까? (0.4.4)
9. "우리 서버에서 돌릴 수 있나?" 70억 파라미터 모델의 가중치 크기를 정밀도별로 암산해 보십시오. 파인튜닝은 어떻게 달라집니까? (0.4.5, 0.4.6)
10. "100쪽짜리 PDF를 그냥 통째로 넣으면 안 됩니까?" 어떤 두 가지 문제가 생기고 무엇으로 줄입니까? (0.4.2)