각 단계마다 노이즈 통제 장치가 다르다: 마스킹·RBAC(추출/검색), 위치 재배치(재정렬), 가드레일(주입).
3. 설계자의 통찰 (Architect's Insight)
컨텍스트 엔지니어링의 승부는 정보의 양(Volume)이 아니라 순도와 밀도(Purity & Density)에서 갈린다.
통제(RBAC)와 측정(RAGAS)만이 에이전트가 다루는 지식의 무결성(Integrity)을 증명한다.
평가문항
문항 1 / 5
Lost in the Middle 현상으로 프롬프트 중앙에 배치된 핵심 정보를 모델이 자꾸 놓칠 때, 파인튜닝 없이 구조적으로 이를 우회하는 배치 전략은?
① 모든 참고 문서를 알파벳·가나다순으로 나란히 배치한다
② 재정렬로 뽑아낸 핵심 정보(Top 1·2, 치명적 제약 조건)를 프롬프트의 최상단과 최하단에 나누어 배치하는 샌드위치 구조를 쓴다
③ 컨텍스트 윈도우 크기를 최대한 확장해 정보량 자체를 늘린다
④ 더 큰 파라미터의 모델로 교체해 문제를 해결한다
정답 확인
정답 ② — Lost in the Middle은 트랜스포머 셀프 어텐션의 구조적 편향(Primacy·Recency는 강하고 중간은 약한 U자형 곡선)에서 비롯되므로 파인튜닝으로 해결되지 않습니다. 핵심 제약 조건을 최상단·최하단에 나눠 배치하는 샌드위치 전략만으로 비용 없이 정확도를 크게 끌어올릴 수 있습니다.
평가문항
문항 2 / 5
금융사 여신 규정 에이전트처럼 고규제 산업에서 컨텍스트 파이프라인의 추출·검색 단계에 반드시 내재화해야 하는 컴플라이언스 요소는?
① 응답을 더 빠르게 생성하기 위한 시맨틱 캐싱
② 대화의 어조를 더 친근하게 다듬는 프롬프트 튜닝
③ 검색 범위를 넓히기 위해 청크 크기를 최대한 키우는 것
④ PII(개인식별정보) 사전 마스킹과 직급·권한 기반 RBAC 필터링으로 기밀 규정 접근을 원천 차단하는 것
정답 확인
정답 ④ — Extraction 단계의 Sanitization & Masking과 Retrieval 단계의 메타데이터 필터링+RBAC는 열람 권한이 없는 사용자가 기밀 규정에 접근하는 것을 원천 차단하는 컴플라이언스 장치입니다. 캐싱이나 어조, 청크 크기는 컴플라이언스와 무관한 별개의 설계 요소입니다.
평가문항
문항 3 / 5
청크 A의 꼬리 부분을 청크 B의 머리에 복제해 겹치게 만드는 '의미적 중첩(Overlapping)'을 도입하는 이유는?
① 청크 경계에서 단서 조항 등 문맥이 잘려나가는 경계선 누수(Boundary Leakage)를 방지하기 위해
② 벡터DB에 저장되는 총 데이터량을 줄이기 위해
③ 검색 속도를 물리적으로 두 배 빠르게 만들기 위해
④ Re-Ranking 단계를 아예 생략할 수 있게 하기 위해
정답 확인
정답 ① — 슬라이딩 윈도우 방식으로 청크 경계를 10~15%가량 겹치게(기와지붕 원리) 설계하면, 조항이 청크 경계에서 끊겨 의미가 단절되는 문제를 방지할 수 있습니다. 저장량 절약이나 속도 향상, Re-Ranking 생략과는 관련이 없습니다.
평가문항
문항 4 / 5
사용자 질문의 상당수가 표현만 다를 뿐 의미상 반복되는 패턴일 때, 벡터 유사도로 '동일 의미' 질의를 판별해 과거 정답을 즉시 재사용함으로써 API 비용과 응답 지연을 동시에 방어하는 기법은?
① Re-Ranking으로 후보 문서를 매번 새로 채점한다
② Chunking 크기를 늘려 한 번에 더 많은 문서를 검색한다
③ 시맨틱 캐싱(Semantic Caching) — 과거에 답한 것과 의미가 같으면 캐시된 답을 즉시 반환한다
④ CDC(Change Data Capture)로 원본 데이터베이스 변경을 실시간 동기화한다
정답 확인
정답 ③ — 시맨틱 캐싱은 새 질문을 벡터 공간에서 과거 질문과 비교해 의미가 같으면 전체 파이프라인을 다시 돌리지 않고 즉시 답을 반환합니다. 다만 유사도 임계값을 너무 높이면 적중률이 떨어지고, 너무 낮추면 서로 다른 질문에 같은 답을 주는 오작동(False Positive)이 생길 수 있어 튜닝이 중요합니다.
평가문항
문항 5 / 5
RAGAS 프레임워크에서 '모델의 답변이 주어진 컨텍스트 안의 근거에서만 도출되었는가'를 측정하는 지표는?
① Context Recall
② Faithfulness(사실 부합성)
③ Answer Relevance
④ Context Precision
정답 확인
정답 ② — Faithfulness는 답변이 컨텍스트 내 근거에만 기반했는지(환각 여부)를 측정합니다. Context Precision은 핵심 시그널이 상단에 배치됐는지, Context Recall은 필요한 배경지식이 모두 검색됐는지, Answer Relevance는 질문에 정면으로 답했는지를 각각 측정하는 별개 지표입니다.
다음으로
다음 강의 예고: 3강 「지식의 이식: Enterprise RAG와 Few-shot 패턴」 — 오늘 배운 검색·재정렬 파이프라인을 한 단계 더 발전시켜, 외부 지식을 단순히 '참조'하는 수준을 넘어 기업 고유의 논리와 판단 체계를 모델의 추론 과정에 맥락적으로 내재화하는 Enterprise RAG와 Few-shot 패턴을 다룹니다.
03
지식의 이식: Enterprise RAG와 Few-shot 패턴
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 3강
인트로
제3강. 지식의 이식: Enterprise RAG와 Few-shot 패턴
"외부 데이터를 '참조'하는 수준을 넘어, 모델 추론에 기업 고유 논리·체계를 '맥락적으로 내재화'하는 고도화 공정."
구성: 인트로 → 사전학습
사전학습 (생각해보기!)
주제: 왜 우리 회사의 RAG 챗봇은 늘 어딘가 어색하게 느껴질까요?
검색 증강 생성(RAG)을 도입했지만, 답변은 여전히 뭔가 겉도는 느낌
이질감의 3대 병목: ① 용어 파편화(Terminology Mismatch) ② 맥락 유실(Contextual Hallucination) ③ 포맷 붕괴(Formatting Collapse)
원인은 '검색'만으로는 '기업의 사고방식'까지 전달할 수 없다는 것
학습내용 및 목표
학습내용
Grounding(근거 추론): 외부 지식에 답변의 근거를 고정하는 아키텍처
Few-shot(사고 이식): 정답이 아닌 '추론 과정'을 샘플로 전달하는 In-Context Learning
도메인 사전 구축: 사내 전문 용어와 지식 그래프로 맥락 보강
출력 무결성: 포맷 붕괴를 막는 검증·자가치유 파이프라인
학습목표
정확도: 컨텍스트 밖 추측을 차단해 오답률을 Zero化한다.
신뢰성: 근거 없이는 답하지 않는 방어적 추론 구조를 설계한다.
효율성: 파인튜닝 없이 Few-shot만으로 전문가 수준의 답변 품질을 확보한다.
본학습
왜 검색만으로는 부족한가 (RAG 한계)
지식의 파편화: 청크가 전체 로직·인과관계 상실
맥락의 유실: 텍스트는 있으나 배경(의도) 없음
내부 지식 편향(Parametric Bias): 모델이 주입 데이터보다 사전학습을 더 신뢰
본학습
Grounding의 정의: 지식의 '닻'
구분
내부 지식(Parametric)
외부 근거(Non-Parametric)
비유
모델의 '상식'
아키텍트가 쥐여준 '참고서'
성격
방대하나 낡고 불확실(환각 근원)
최신·정확한 사내 실무 데이터
Grounding
철저히 억제(Suppress)
모든 답변의 유일한 근거(Anchor)
본학습
아키텍처: Grounding Layer 삽입
계층 1: 시스템 페르소나
계층 2: Grounding Layer(<context> 태그로 청크 격리 — 지식의 성벽)
2. In-Context Learning: 사고의 이식 (Transplanting Reasoning)
[Input-Thought-Output] Few-shot으로 정답이 아닌 '사고의 공식'을 전달함
Dynamic Few-shot과 Negative Few-shot으로 실시간 최적화와 안티 패턴 차단을 동시에 확보함
3. Enterprise Domain: 조직 지능의 동기화 (Organizational Intelligence Sync)
사내 전문 용어 사전과 지식 그래프로 도메인 맥락을 보강함
실시간 게이트웨이(Pre/Post-Processing)와 자가 치유 리트라이로 용어·포맷의 무결성을 강제함
평가문항
문항 1 / 5
Enterprise RAG 설계에서 Grounding의 핵심 목적으로 가장 적절한 것은?
① 파인튜닝을 통해 도메인 지식을 모델 내부에 영구적으로 학습시키는 것
② 모델의 파라미터 수를 늘려 사전학습 지식의 범위를 확장하는 것
③ 모델의 내부 지식(Parametric Knowledge)을 억제하고, 답변의 근거를 외부 주입 컨텍스트에 고정시키는 것
④ 컨텍스트 윈도우 크기를 최대한 늘려 더 많은 문서를 통째로 주입하는 것
정답 확인
정답 ③ — Grounding은 모델이 방대하지만 낡고 불확실한 내부 지식(상식)에 의존하지 않도록 억제하고, 아키텍트가 주입한 최신·정확한 외부 근거만을 답변의 유일한 닻(Anchor)으로 삼게 만드는 설계입니다. 파라미터 확장이나 파인튜닝은 별개의 접근입니다.
평가문항
문항 2 / 5
Grounding Layer를 사용자 지시·다른 데이터와 물리적으로 분리해 프롬프트 인젝션을 차단하는 대표적 기법은?
① #, ---, XML 태그 등 구분자로 데이터 영역과 지시 영역을 분리하는 격벽 처리(Delimiter Isolation)
② 모델을 재학습(Fine-tuning)시켜 지시와 데이터를 구분하는 판단력을 내재화하는 것
③ 검색되는 문서의 개수를 최소 1개로 제한해 오염 가능성을 줄이는 것
④ 시스템 페르소나 문구를 프롬프트 맨 앞에서 반복 강조하는 것
정답 확인
정답 ① — <context> 같은 태그나 #, --- 구분자로 '이것은 데이터다'와 '이것은 지시다'를 물리적으로 갈라놓는 격벽 처리가 핵심입니다. 이 격벽이 없으면 검색된 문서 안에 숨은 악성 지시문을 모델이 실제 명령으로 착각하는 프롬프트 인젝션에 노출됩니다.
평가문항
문항 3 / 5
다음 중 Few-shot(In-Context Learning)이 파인튜닝 대비 ROI 측면에서 유리한 이유로 볼 수 '없는' 것은?
① 실시간으로 샘플만 교체하면 즉시 업데이트가 반영된다
② 3~5개의 Golden Sample만으로도 충분히 효과를 낼 수 있다
③ 프롬프트 설계와 소량 샘플만으로 초기 비용을 낮출 수 있다
④ 모델 파라미터 자체를 영구적으로 수정해 내부 지식을 갱신한다
정답 확인
정답 ④ — 모델 파라미터를 영구적으로 수정하는 것은 Few-shot이 아니라 파인튜닝의 특징이며, 그 과정에서 Catastrophic Forgetting 같은 성능 퇴행 위험까지 감수해야 합니다. Few-shot은 모델 내부를 건드리지 않고 프롬프트 레이어에서 가볍고 직관적으로 통제한다는 점이 ROI 강점입니다.
평가문항
문항 4 / 5
벡터 검색(Vector Search)에 지식 그래프(Knowledge Graph)를 결합했을 때 얻는 핵심 이점은?
① 임베딩 연산 속도를 획기적으로 높여 응답 지연을 줄인다
② 청크 하나만으로는 놓치기 쉬운 엔티티 간 상위·하위·구성 관계를 추적해 구조적 맥락을 보완한다
③ 파인튜닝 없이도 모델의 파라미터 자체를 갱신할 수 있다
④ 프롬프트에 주입되는 토큰 수를 자동으로 압축해 비용을 낮춘다
정답 확인
정답 ② — 지식 그래프는 [계정계]-[대출]-[여신]처럼 엔티티 간 관계를 담고 있어, 벡터 검색으로 찾은 조각의 부모·형제 노드까지 함께 추적함으로써 청크 단위로는 잘려나갔던 구조적·관계적 맥락을 보충해 줍니다.
평가문항
문항 5 / 5
에이전트의 출력이 JSON Schema 등 정해진 포맷을 위반했을 때, 자가 치유(Self-healing Retry) 파이프라인이 따르는 올바른 순서는?
① 모델을 파인튜닝하여 해당 포맷 오류를 영구적으로 교정한다
② 사용자에게 즉시 에러 메시지만 노출하고 요청을 즉시 종료한다
③ Validation으로 위반을 검사 → 구체적인 Error Feedback 생성 → 에러를 컨텍스트에 추가해 재요청 → 최대 횟수 초과 시 Fallback 응답으로 Graceful Degradation
④ 에러가 발생한 즉시 재요청부터 반복하고, 검증과 피드백 생성은 생략한다
정답 확인
정답 ③ — Validation(검사) → Error Feedback(구체적 피드백) → Self-healing Retry(컨텍스트에 에러를 추가해 재요청) → 3회 초과 시 Fallback으로 Graceful Degradation, 이 순서를 지켜야 실수가 시스템 장애로 번지지 않습니다.
다음으로
다음 강의 예고: 4강 「사고의 척추: CoT(생각의 사슬)와 단계적 추론 설계」 — 오늘 배운 Grounding과 Few-shot이 근거와 사고 패턴을 '주입'하는 기술이었다면, 다음 시간에는 그 근거 위에서 모델이 결과를 묻기 전에 스스로 과정을 한 단계씩 설계하도록 만드는 Chain-of-Thought 추론 구조를 다룹니다.
04
사고의 척추: CoT(생각의 사슬)와 단계적 추론 설계
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 4강
인트로
제4강. 사고의 척추: CoT(생각의 사슬)와 단계적 추론 설계
"결과를 묻기 전에, 과정을 설계하라."
구성: 인트로 → 사전학습
사전학습 (생각해보기!)
주제: 세상에서 가장 똑똑하다는 모델이, 왜 단순한 계산 앞에서 무너질까요?
우리는 지금 또 다른 '지능의 역설'과 마주하고 있습니다.
원인 1: Next-Token Bias — 모델은 다음 단어를 확률적으로 예측할 뿐, 문제 전체를 통찰하고 답을 내는 것이 아닙니다.
원인 2: 작업 기억 부족 — 복잡한 다단계 계산을 한 번에 처리할 '메모장'이 없으면 중간 값을 놓칩니다.
원인 3: 에러의 복리 증식 — 초반의 작은 오차가 뒤로 갈수록 눈덩이처럼 불어납니다.
학습내용 및 목표
학습내용
CoT(Chain of Thought)의 메커니즘: Zero-shot CoT와 Few-shot CoT
논리적 원자화: 복잡한 질문을 검증 가능한 단위로 쪼개는 설계
단계별 검증과 에러 전파 방지: 서킷 브레이커, XML 구획화
지능 확장 기법: PAL, Least-to-Most Prompting, Self-Consistency, ReAct로의 진화
실전 도메인 케이스: 대출 금리 산출, ISMS-P 보안 감사 로직
학습목표
CoT가 추론 품질을 끌어올리는 메커니즘을 설명할 수 있다.
복잡한 문제를 원자적 단계로 분해하고, 각 단계에 검증 지점을 설계할 수 있다.
PAL·Least-to-Most·Self-Consistency 등 상황별 확장 기법을 구분해 적용할 수 있다.
본학습
CoT의 정의: 블랙박스에서 화이트박스로
Standard(Black Box): [질문] → [답변]
CoT(White Box): [질문] → [중간 추론 1, 2, 3...] → [답변]
CoT의 3대 가치: 추적 가능성(디버깅), 연산 정밀도, 지능의 해설
본학습
Zero-shot CoT: 한 줄의 마법 문장
"단계별로 차근차근 생각해보자(Let's think step by step)" — 이 한 줄로 논리 연산 능력이 비약적으로 상승합니다.
작동 원리
토큰 할당 최적화: 답을 서둘러 내뱉지 않고 추론에 토큰을 먼저 씁니다.
작업 기억 공간 확보: 중간 값을 텍스트로 남겨 '메모장' 역할을 하게 만듭니다.
확률적 오류 억제: 성급한 결론으로 直行하는 경향을 억제합니다.
본학습
Few-shot CoT: 정답이 아니라 '사고의 알고리즘'을 가르치다
기존 Few-shot(IO)
Few-shot CoT(Reasoning)
[질문] → [정답]
[질문] → [추론 과정] → [정답]
형식만 배움, 정답이 맞는 이유는 '운'
'사고의 알고리즘'을 그대로 복사
Few-shot CoT의 3대 전략: 논리 표준화, 도메인 지식 투영, 예외 처리 학습
본학습
논리적 분해(Divide & Conquer): 원자적 추론 설계
원자적 분해의 3원칙: 독립성, 가시성, 검증 가능성
모놀리식 질문 → 마이크로 추론으로 쪼개기
1. 서류는 유효한가?
2. DSR(총부채원리금상환비율)이 40% 미만인가?
3. 가산 금리는 얼마인가?
4. 종합 판정은 무엇인가?
본학습
[Case] 복잡한 대출 금리 산출: CoT의 실전 적용
단계
수행 과업
처리 내용
1
기준 금리 확인
COFIX·가산 금리 식별
2
신용 스프레드
신용 등급별 기본 가산 금리 매핑
3
우대 금리 검토
급여이체·자동이체 등 할인율 개별 계산
4
최종 합산·검증
상/하한선 규정 준수 확인
본학습
단계별 검증(Intermediate Validation): 중간에서 걸러내기
3대 검증 축
Grounding Check: 데이터 정합성 — 실제 데이터와 맞아떨어지는가?
Constraint Check: 비즈니스 룰 — 규정과 정책을 위반하지 않는가?
Consistency Check: 논리 일관성 — 앞 단계와 모순되지 않는가?
3계명: 명시적 자기질문, 부정적 조건(중단 조건) 명시, 결과물 형식 고정
본학습
XML 태그로 사고 구획화하기
`
<thought> 정합성 검토, 비즈니스 로직 나열, 모순 체크 </thought>
<reasoning_log> 1단계: 기준 금리 3.5% / 2단계: +1.2% ... </reasoning_log>
<final_answer> 최종 산출 결과 및 사용자 응답 </final_answer>
`
본학습
에러 전파 방지: 서킷 브레이커 설계
왜 작은 에러가 거대한 환각으로 자라는가: 연쇄적 왜곡 + 확증 편향
3전술
논리 게이트: 검증되지 않으면 다음 단계 진행을 금지
임계치 검증: "금리가 20%를 초과하면 즉시 중단"
근거 재정합: 매 단계마다 원본 데이터와 다시 대조
본학습
PAL(Program-Aided Language Models): 계산은 기계에게
논리는 LLM, 계산은 결정적(deterministic) 엔진(Python)이 맡는다
모델이 직접 암산하지 않는다 → 파이썬 코드를 생성한다 → 외부 인터프리터가 실행해 100% 확정된 결과를 얻는다
본학습
Least-to-Most Prompting: 작은 문제부터 차곡차곡
하위 문제 분해 → 순차 해결 → 지식 축적
이전 단계의 정답이 다음 단계를 풀기 위한 힌트가 됩니다.
본학습
셀프 일관성(Self-Consistency): 여러 개의 사고를 투표에 부치다
다중 샘플링(여러 CoT 경로를 병렬로 생성) → 다수결 합의(Majority Vote)
3대 이점: 확률적 오류 필터링, 추론 신뢰도 측정, 고난도 과업 최적화
본학습
[실전] ISMS-P 보안 감사 로직: CoT로 감사를 설계하다
단계
과업
초점
1
기준 식별
ISMS-P 2.1.1 등 필수 통제 항목 추출
2
증적 매핑
방침서·로그에서 관련 구절 특정
3
Gap 분석
기준과 증적의 불일치(결함) 도출
4
종합 판정
결함의 경중 판단 + 개선 권고
본학습
추론 경로 모니터링과 로깅: 사고를 감사 자산으로
Front-end: 사용자에게는 정제된 <final_answer>만 전달
Back-end: 전체 사고 과정을 수집해 사후 분석 자산으로 보존
모니터링 3지표: 단계 일관성, 단계별 토큰·비용, 논리 임계치 도달율
본학습
사고의 유연성 vs 절차의 엄격성
유연성: <thought>, <reasoning> 내부는 비정형 문제 대응을 위해 자유롭게 열어둡니다.
CoT(Zero/Few-shot): 블랙박스를 화이트박스로 전환해 작업 기억을 확보하고 추론 정밀도를 끌어올림
논리적 분해: 모놀리식 질문을 원자적·독립적 단계로 쪼개 검증 가능한 구조로 설계
2. 구조적 통제와 안전 장치 (Structural Control)
XML 구획화·단계별 검증: 사고를 유연한 구간과 엄격한 구간으로 분리하고, 각 단계마다 정합성·비즈니스 룰·일관성을 검증
서킷 브레이커: 작은 오류가 연쇄적으로 왜곡되어 거대한 환각으로 자라기 전에 논리 게이트로 차단
3. 지능 확장 (Intelligence Extension)
PAL(코드 실행)로 확정적 산술 정밀도를 확보하고, Least-to-Most·Self-Consistency로 복잡한 과업의 신뢰도를 높이며, ReAct로 사고를 외부 도구·실시간 데이터와 결합해 개방형 에이전트로 확장함
평가문항
문항 1 / 5
CoT를 통해 모델의 추론 과정을 블랙박스에서 화이트박스로 전환했을 때 얻는 가장 핵심적인 이점은 무엇인가?
① 응답을 생성하는 속도가 빨라진다
② 추론 과정이 노출되어 논리 결함을 추적하고 디버깅할 수 있다
③ 모델의 파라미터 수가 자동으로 증가한다
④ API 호출에 드는 비용이 절감된다
정답 확인
정답 ② — CoT는 질문과 답변 사이에 중간 추론 과정을 드러내는 설계입니다. 이를 통해 결과가 틀렸을 때 어느 단계에서 논리가 어긋났는지 추적할 수 있고, 이는 연산 정밀도와 지능의 해설 가능성으로도 이어집니다. 속도·파라미터 수·비용과는 직접 관련이 없습니다.
평가문항
문항 2 / 5
<thought>, <reasoning_log>, <final_answer> 같은 XML 태그로 모델의 사고 과정을 구획화하는 것에 대한 설명 중 옳지 않은 것은?
① 프론트엔드에는 정제된 <final_answer>만 노출하고, 백엔드에는 전체 사고 로그를 보존해 사후 분석 자산으로 쓸 수 있다
② 태그별로 구역을 분리해두면 오류가 발생했을 때 사후 분석과 디버깅이 쉬워진다
③ 이 구획화 자체가 할루시네이션(환각)을 100% 차단하는 완벽한 안전장치다
④ <thought> 내부는 비정형 문제에 대응하도록 비교적 자유롭게, <final_answer>는 엄격한 출력 포맷을 지키도록 설계할 수 있다
정답 확인
정답 ③ — XML 구획화는 사고 과정을 가시화하고 검증·감사를 용이하게 하는 완화(mitigation) 장치이지, 할루시네이션을 완전히 차단하는 만능 장치가 아닙니다. 에러 전파를 막으려면 별도의 서킷 브레이커·임계치 검증 같은 안전 장치를 함께 설계해야 합니다.
평가문항
문항 3 / 5
다단계 추론에서 초반의 작은 오류가 뒤 단계로 갈수록 연쇄적으로 왜곡되어 거대한 환각으로 자라는 것을 막기 위한 전략으로 가장 적절한 것은?
① 이전 단계의 검증에 실패하면 다음 단계로 진행하지 못하도록 막는 서킷 브레이커(논리 게이트) 로직을 둔다
② 모든 중간 검증 단계를 생략하고 최종 답변만 최대한 빠르게 생성한다
③ 사용자에게 결과를 먼저 보여준 뒤 나중에 검증한다
④ 여러 모델의 답변 중 하나를 무작위로 골라 채택한다
정답 확인
정답 ① — 서킷 브레이커는 검증되지 않은 단계에서 다음 단계로의 진행을 차단하는 논리 게이트입니다. 여기에 임계치 검증("금리 20% 초과 시 중단")과 근거 재정합(원본 데이터와의 재대조)을 결합해 에러의 연쇄적 확산과 확증 편향을 억제합니다.
평가문항
문항 4 / 5
대출 금리 합산과 같이 한 치의 오차도 허용되지 않는 확정적 산술 연산 정밀도가 필요할 때, 가장 적합한 기법은?
① Zero-shot CoT
② PAL(Program-Aided Language Models)
③ Self-Consistency
④ Least-to-Most Prompting
정답 확인
정답 ② — PAL은 논리적 판단은 LLM이 맡고, 실제 계산은 파이썬 같은 결정적 엔진에게 위임하는 기법입니다. 모델이 코드를 생성하면 외부 인터프리터가 이를 실행해 100% 확정된 결과를 반환하므로, 확률적 언어모델의 암산 오류를 원천적으로 배제할 수 있습니다.
평가문항
문항 5 / 5
ReAct 패턴이 순수한 CoT와 차별화되는 가장 결정적인 특징은 무엇인가?
① 사고 과정을 전혀 노출하지 않고 답만 내놓는다
② 동일 질문에 대해 여러 추론 경로를 병렬 생성한 뒤 다수결로 답을 정한다
③ 추론(Thought)과 외부 도구 호출(Action)을 결합해 실시간 데이터·환경과 상호작용하며 답을 완성해 나간다
④ 복잡한 문제를 여러 하위 문제로 순차 분해해 이전 정답을 다음 단계의 힌트로 축적한다
정답 확인
정답 ③ — ReAct는 Thought → Action → Observation을 반복하는 루프로, CoT의 사고 과정을 닫힌 텍스트 안에 가두지 않고 외부 API·실시간 데이터와 연동시켜 개방형 에이전트로 확장한 패턴입니다. ②는 Self-Consistency, ④는 Least-to-Most Prompting에 해당하는 설명입니다.
다음으로
다음 강의 예고: 5강 「[실습 1] 지식형 에이전트: LangChain 기반 지식 베이스 연결」 — 오늘 다진 사고의 척추(CoT)와 서킷 브레이커 설계를 바탕으로, 실제 LangChain 환경에서 지식 베이스를 연결해 에이전트가 근거 있는 답변을 생성하도록 직접 실습해 봅니다.
05
[실습 1] 지식형 에이전트: LangChain 기반 지식 베이스 연결
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 5강
인트로
제5강. [실습 1] 지식형 에이전트: LangChain 기반 지식 베이스 연결
"모델의 상상이 아닌, 팩트에 기반한 답변 설계하기."
구성: 인트로 → 사전학습
사전학습 (생각해보기!)
주제: 우리 회사의 AI가 자신감 넘치는 말투로 '틀린 답'을 내놓는다면 어떻게 될까요?
LLM은 학습 시점까지의 지식을 파라미터 안에 '압축'해 저장한 존재입니다.
학습 이후에 생긴 사내 정책, 최신 제품 스펙, 어제 올라온 공지사항 — 모델은 이런 것들을 전혀 알지 못합니다.
그럼에도 모델은 모른다고 솔직히 말하는 대신, 그럴듯한 문장으로 '추측'을 만들어 답합니다.
문제는 이 추측과 사실을 사용자가 구분할 방법이 없다는 것입니다 — 모두 똑같이 자신감 있는 말투이기 때문입니다.
학습내용 및 목표
학습내용
Parametric Knowledge와 Non-parametric Knowledge의 차이, 그리고 할루시네이션의 근본 원인
지식형 에이전트(RAG)의 5대 컴포넌트: Ingestion → Hybrid Vector Store → Intent Retriever → Citation Generator → Harness Dashboard
Module A/B/C: 메타데이터 인입, 의도 기반 리트리버, 근거 인용 엔진의 상세 설계
[실습] LangChain 기반 지식 베이스 연결 워크플로우 4단계 직접 수행
학습목표
지식형 에이전트가 필요한 이유를 Parametric vs Non-parametric 관점에서 설명할 수 있다.
RAG 파이프라인을 구성하는 5개 컴포넌트의 역할을 구분해 설명할 수 있다.
Hybrid Search, Multi-Query Retriever, Citation Generator의 목적을 이해하고 실습으로 확인할 수 있다.
본학습
왜 지식형 에이전트인가(Parametric vs Non-parametric)
Parametric Knowledge(모델 내부 지식): 학습 시점에 파라미터 안에 압축된 지식 — 최신성 없음, 사내 데이터 반영 불가
Non-parametric Knowledge(외부 문서 지식): 필요할 때마다 외부 데이터베이스에서 실시간으로 불러오는 근거(Grounding) — 최신 정보와 사내 데이터를 즉시 반영 가능
할루시네이션 극복: 외부 데이터(Grounding)로 답변의 신뢰성 확보
추론 과정의 투명성(Traceability): 답변의 근거가 된 문서를 역추적 가능
"수사관 같은 AI": 모든 답변에 '증거'를 제출하도록 설계
비교
본학습
시스템 아키텍처
지식형 에이전트는 문서 인입부터 근거 시각화까지 다섯 개의 컴포넌트가 파이프라인처럼 연결된 하나의 시스템입니다.
컴포넌트
역할
핵심 기술
Ingestion Engine
문서 로딩·메타데이터 보존형 청킹
PyPDFLoader, RecursiveCharacterTextSplitter
Hybrid Vector Store
벡터+키워드 검색 결합
FAISS/Chroma, OpenAI Embeddings
Intent Retriever
질문 재해석·쿼리 확장
Multi-Query Retriever, HyDE
Citation Generator
근거 매핑·원문 링크
LCEL, Metadata Mapping
Harness Dashboard
추론 로그·유사도 시각화
Streamlit, LangSmith
본학습
모듈 A/B/C 상세
Module A. 고도화된 컨텍스트 인입(Ingestion)
소스 파일명·페이지 번호·생성일자를 모든 청크(chunk)에 태깅
문서가 잘게 쪼개진 이후에도 메타데이터가 답변 생성 단계까지 끝까지 유지되도록 보존
Module B. 의도 기반 리트리버(Intent Retriever)
Multi-Query Retriever: 모호한 질문 하나를 3~5개의 유사 질문으로 확장해 검색 누락(Recall 저하)을 방지
Hybrid Search: 의미 기반 검색(벡터)과 정확 일치 검색(키워드)을 결합해 재현율과 정밀도를 동시에 확보
Module C. 근거 인용 엔진(Citation Generator)
답변 문장 끝에 [1][2] 형태의 각주를 자동 생성
"모든 주장은 컨텍스트 근거 + 문서 ID를 명시해야 한다"는 규칙을 프롬프트 레벨에서 강제
Step 1. PDF 업로드 후, Ingestion 단계에서 생성된 메타데이터 청킹 로그를 직접 확인한다.
Step 2. 질문을 입력하고, Intent Retriever가 질문을 어떻게 확장했는지 그 궤적을 분석한다.
Step 3. 생성된 답변의 인용구(각주)를 확인하고, 실제 원문 스니펫과 대조해 근거가 정확한지 검증한다.
Step 4. 인용이 부족하거나 근거가 빈약하면, 프롬프트 가드레일을 수정해 근거 인용 규칙을 다시 강제한다.
정리하기
1. 목적의 전환(Grounding)
Parametric(모델 내부 지식) 의존에서 Non-parametric(외부 문서 근거) 활용으로 이동
할루시네이션 극복과 추론 과정의 투명성(Traceability) 확보가 핵심 목표
2. 핵심 아키텍처(5대 컴포넌트)
Ingestion → Hybrid Vector Store → Intent Retriever → Citation Generator → Harness Dashboard로 이어지는 파이프라인
Multi-Query·Hybrid Search로 검색 정확도를, LCEL 기반 인용 엔진으로 근거의 신뢰도를 확보
3. 설계자의 통찰(Architect's Insight)
지식형 에이전트의 신뢰는 모델의 크기가 아니라, 정교한 데이터 인입과 근거 인용 엔진의 설계에서 나온다.
지식형 에이전트는 결국 출처를 추적하고 근거를 제시하는 '검증기(Verifier)'다.
평가문항
문항 1 / 5
지식형 에이전트(RAG 기반)를 도입하는 근본적인 목적은 무엇인가?
① 사용자 인터페이스를 더 화려하게 꾸미기 위해
② 응답 속도를 단축하기 위해
③ 모델이 학습하지 못한 최신·사내 정보를 외부 데이터로 근거(Grounding)하여 할루시네이션을 줄이기 위해
④ 모델의 파라미터 수를 늘려 더 똑똑하게 만들기 위해
정답 확인
정답 ③ — Parametric(모델 내부 지식)은 학습 시점에 멈춰 있어 최신 정보나 사내 데이터를 반영하지 못합니다. 지식형 에이전트는 외부 문서를 근거로 삼아(Grounding) 답변의 신뢰성을 높이고 할루시네이션을 줄이는 것이 목적입니다.
평가문항
문항 2 / 5
시스템 아키텍처의 'Hybrid Vector Store'가 결합하는 두 가지 검색 방식은?
① 벡터(의미) 검색과 키워드(정확 일치) 검색
② 이미지 검색과 음성 검색
③ 캐시 검색과 실시간 검색
④ 국내 검색과 해외 검색
정답 확인
정답 ① — 의미상 유사한 문서를 찾는 벡터 검색만으로는 고유명사나 코드명 같은 정확 일치가 필요한 검색에 취약합니다. 이를 보완하기 위해 키워드 기반 검색을 결합한 Hybrid Search 구조를 사용합니다.
평가문항
문항 3 / 5
Module B의 Multi-Query Retriever가 모호한 질문 하나를 3~5개로 확장하는 목적은?
① 답변 글자 수를 늘리기 위해
② 서버 부하를 늘려 과금을 최적화하기 위해
③ 동일한 질문을 반복 학습시키기 위해
④ 사용자의 질문 의도를 다각도로 재해석해 검색 누락(Recall 저하)을 줄이기 위해
정답 확인
정답 ④ — 사용자의 표현 하나만으로는 관련 문서를 놓칠 수 있습니다. Multi-Query Retriever는 질문을 여러 각도로 재구성(쿼리 확장)하여 검색 적중률을 높이며, HyDE도 유사한 목적의 보완 기법입니다.
평가문항
문항 4 / 5
Module C '근거 인용 엔진(Citation Generator)'이 강제하는 규칙은?
① 답변을 반드시 3문장 이내로 요약해야 한다
② 모든 주장에는 컨텍스트 근거와 문서 ID(각주)를 명시해야 한다
③ 답변에 이모지를 포함해야 한다
④ 검색 결과 중 가장 최신 문서만 사용해야 한다
정답 확인
정답 ② — '수사관 같은 AI'처럼 모든 답변이 근거 문서와 위치를 제시하도록, LCEL로 메타데이터와 답변을 실시간 매핑해 추론 과정의 투명성(Traceability)을 확보하는 것이 이 모듈의 역할입니다.
평가문항
문항 5 / 5
[실습] 워크플로우에서 생성된 답변에 인용(출처 각주)이 부족하거나 누락된 경우, Step 4에서 취해야 할 조치는?
① 모델을 더 큰 모델로 즉시 교체한다
② 벡터 스토어를 통째로 삭제하고 재구축한다
③ 프롬프트 가드레일을 수정해 근거 인용을 강제하도록 지시를 보강한다
④ 사용자에게 질문을 다시 하라고 안내한다
정답 확인
정답 ③ — 근거 없는 주장을 허용하지 않도록, 인용을 강제하는 규칙(가드레일)을 프롬프트 레벨에서 보강하는 것이 지식형 에이전트를 튜닝하는 핵심 대응입니다.
다음으로
다음 강의 예고: 6강 「[실습 2] 판단형 에이전트: LangGraph 기반 루프와 조건부 로직」 — 오늘 만든 지식형 에이전트가 근거를 못 찾거나 답변이 부실할 때, 스스로 자신의 결과물을 비판하고 다시 일을 시키는 '자기 교정 루프'를 LangGraph로 직접 구축합니다.
06
[실습 2] 판단형 에이전트: LangGraph 기반 루프와 조건부 로직
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 6강
인트로
제6강. [실습 2] 판단형 에이전트: LangGraph 기반 루프와 조건부 로직
"스스로의 결과물을 비판하고 경로를 수정하는 '판단형 에이전트' 구축."
구성: 인트로 → 사전학습
닫힌 루프
사전학습 (생각해보기!)
주제: 완벽해 보이는 AI의 답변, 그대로 믿고 내보내도 될까요?
필요성: 확률적 오류 보정, 비즈니스 가이드라인 검열, 최적 해답 탐색
가치: 신뢰성(환각 필터), 비용 효율성, 사용자 경험 개선
학습내용 및 목표
학습내용
반성적 지능(Self-Correction)이 필요한 이유와 그 가치
LangGraph 상태 그래프의 노드(Node)와 엣지(Edge) 구조
상태 스키마(State Schema)를 통한 판단 루프의 단기 기억 설계
Self-Grader: 구조화된 출력으로 할루시네이션·관련성을 판정하는 논리 게이트
조건부 엣지(Conditional Edge)와 Human-in-the-loop 안전장치
학습목표
LangGraph의 노드-엣지 구조로 판단형 에이전트의 흐름을 설계할 수 있다.
Self-Grader를 통한 이진 판정으로 답변 품질을 통제하는 원리를 이해한다.
조건부 분기와 최대 재시도 제한으로 안전하게 종료되는 판단 루프를 설계할 수 있다.
본학습
반성적 지능: 왜 자기 교정(Self-Correction)인가
필요성: 확률적 오류 보정, 비즈니스 가이드라인 검열, 최적 해답 탐색
가치: 신뢰성(환각 필터), 비용 효율성, 사용자 경험 개선
본학습
시스템 아키텍처: LangGraph 노드와 판단 루프
구분
명칭
역할
Node
Retrieve
지식 베이스 검색
Node
Generate
답변 후보 생성
Node
Grade_Answer
할루시네이션·관련성 이진 판정(Yes/No)
Node
Rewrite_Query
'No' 시 쿼리 재구성
Edge
Conditional Edge
결과에 따라 END 또는 Rewrite 결정
닫힌 루프
본학습
Module A: 상태 스키마 — 판단 루프의 단기 기억
`python
class AgentState(TypedDict):
question: str # 사용자 원본 질문
generation: str # 현재 답변
documents: List[str] # 검색된 문서(근거)
retry_count: int # 루프 횟수(Safety Rail)
`
닫힌 루프
본학습
Module B: 논리 게이트 — Self-Grader
구조화된 출력(Pydantic): {"score":"yes/no"} 강제
이중 검증: Hallucination Check(컨텍스트 실재?) + Relevance Check(질문 의도 해결?)
본학습
Module C: 조건부 경로 제어와 Human-in-the-loop
결정적 분기: Self-Grader 점수에 따라 행선지 강제 지정
실패 전략: Retry(Rewrite_Query) / Escalation(max_retries 초과 시 사람에게)
Human-in-the-loop: 금융 제안·보안 수정 등 민감 답변 직전 '인간 승인' 노드
실습
검증 시나리오: 정상 응답부터 안전 종료까지
시나리오
질문
기동 궤적
정상 응답
명확한 사실 질의
Generate→Grade(Yes)→출력
자기 교정
모호한 질문
Grade(No)→Rewrite→Re-Retrieve→END
안전 종료
지식 베이스 외 질문
3회 실패→Human-in-the-loop(중단)
정리하기
1. 반성적 지능의 도입 (Reflective Intelligence)
Self-Correction: 결과물을 스스로 비판하고 필요하면 재시도하는 반성적 루프
가치: 확률적 오류 보정, 비즈니스 가이드라인 검열, 신뢰성·비용 효율성 확보
2. 핵심 아키텍처 (LangGraph 구성)
State Schema: retry_count 등 안전장치를 품은 판단 루프의 단기 기억
Self-Grader: Pydantic 구조화 출력으로 Hallucination·Relevance를 이진 판정
Conditional Edge: 판정 결과에 따라 Rewrite 또는 END로 향하는 결정적 분기
3. 설계자의 통찰 (Architect's Insight)
판단형 에이전트의 신뢰는 '무한한 반복'이 아니라 '최대 재시도 제한 + Human-in-the-loop'라는 멈춤의 설계에서 나옵니다.
평가문항
문항 1 / 5
LangGraph 기반 판단형 에이전트에서 Grade_Answer 노드의 판정 결과를 자유 서술형 문장이 아니라 {"score":"yes/no"}처럼 구조화된 출력으로 강제하는 이유는?
① 모델의 응답 속도를 높이기 위해
② 사용자에게 더 친절한 문장을 보여주기 위해
③ 코드가 판정 결과를 근거로 다음 경로(END/Rewrite)를 결정적으로 분기시킬 수 있게 하기 위해
④ 검색 문서의 개수를 줄이기 위해
정답 확인
정답 ③ — 애매한 서술형 텍스트로는 조건부 엣지가 다음 노드를 코드로 결정할 수 없습니다. Pydantic 등으로 출력을 yes/no로 강제해야 Conditional Edge가 안정적으로 분기할 수 있습니다.
평가문항
문항 2 / 5
AgentState에 정의된 retry_count 필드의 아키텍처적 역할로 가장 적절한 것은?
① 검색된 문서의 개수를 세는 용도
② Rewrite_Query와 Retrieve 사이를 무한히 맴도는 것을 막는 안전장치(Safety Rail)
③ 사용자의 질문 의도를 분류하는 라벨
④ 답변 생성에 사용된 토큰 수를 기록하는 로그
정답 확인
정답 ② — Grade_Answer가 계속 'No'를 반환할 경우 루프가 무한히 반복될 수 있습니다. retry_count는 루프 횟수를 누적해 max_retries 초과 시 Escalation(사람에게 넘김)으로 전환하게 만드는 안전장치입니다.
평가문항
문항 3 / 5
판단형 에이전트에서 Self-Grader의 '이중 검증'이 Hallucination Check와 Relevance Check로 나뉘어 있는 이유는?
① 검색 속도와 생성 속도를 각각 측정하기 위해
② 답변이 근거 문서에 실재하는지(사실성)와 사용자 질문 의도를 실제로 해결했는지(적합성)는 서로 다른 실패 지점이기 때문
③ 두 번 채점하면 모델 비용이 절반으로 줄기 때문
④ 사용자 만족도를 설문 형태로 수집하기 위해
정답 확인
정답 ② — 답변이 문서에 근거하더라도(사실성 확보) 질문의 의도를 비껴갈 수 있고, 반대로 의도에 맞더라도 근거 없는 내용을 지어낼 수 있습니다. 두 검증은 서로 다른 실패 유형을 잡아내므로 함께 필요합니다.
평가문항
문항 4 / 5
다음 중 LangGraph의 Conditional Edge가 일반적인(고정된) Edge와 다른 점은?
① Conditional Edge는 항상 END로만 연결된다
② Conditional Edge는 그래프 실행 전 컴파일 시점에 목적지가 확정된다
③ Conditional Edge는 실행 중 특정 노드(예: Grade_Answer)의 판정 결과에 따라 다음 노드를 그때그때 다르게 결정한다
④ Conditional Edge는 사용자의 승인 없이는 동작하지 않는다
정답 확인
정답 ③ — 고정 Edge는 항상 정해진 다음 노드로 흐르지만, Conditional Edge는 상태(State)에 담긴 판정 값을 읽어 실행 시점에 END로 갈지 Rewrite_Query로 갈지를 동적으로 결정합니다.
평가문항
문항 5 / 5
금융 상품 제안이나 보안 설정 변경처럼 되돌리기 어려운 민감한 답변 앞에 Human-in-the-loop 노드를 배치하는 가장 큰 이유는?
① 모델의 추론 속도를 인위적으로 늦추기 위해
② Self-Grader가 'Yes' 판정을 내렸더라도, 결과가 민감하고 가역성이 낮은 경우에는 최종 실행 전 사람의 승인을 거치게 하기 위해
③ 검색 문서의 저작권 문제를 회피하기 위해
④ retry_count를 초기화하기 위해
정답 확인
정답 ② — 판정 결과가 통과(Yes)라도 되돌리기 어려운 고위험 행동이라면, 아키텍트는 END로 바로 보내지 않고 인간 승인이라는 정지점을 두어 시스템의 신뢰를 담보해야 합니다.
다음으로
다음 강의 예고: 7강 「[실습 3] 업무형 에이전트: Tool-calling과 API 에코시스템」 — 5강의 지식과 6강의 판단 루프를 결합해, 에이전트가 실제 외부 API를 호출하며 현실의 업무를 완수하는 Tool-calling 에코시스템을 설계합니다.
인터페이스로서의 자연어: 모델은 함수의 '설명'과 '파라미터'만 봄(실제 코드는 보지 못함)
3포인트
① 권한·위험도 명시: 이 도구가 읽기 전용인지, 쓰기·삭제까지 가능한지
② Pydantic 파라미터 강제: 타입·필수 여부·예시 값
③ 의도(Intent) 매핑 최적화: 사용자의 다양한 표현이 정확히 이 도구로 연결되도록 설명 최적화
본학습
Module B&C: 병렬 도구 호출과 Human-in-the-loop
병렬 도구 호출: 한 추론 턴에서 여러 도구를 동시에 호출 → 지연 시간이 합(Sum)에서 최댓값(Max)으로 단축, 결과의 상태 통합 필요
Human-in-the-loop: Read-only 도구는 자동 실행 / Write·Delete 도구(메일 발송, DB 삭제, 결제)는 승인 필수
실습
멀티태스킹 비서 시연: 병렬 호출부터 승인 대기까지
Step 1. 단일 도구 호출: "일정 확인해줘" → 인자 추출 로그 확인
Step 2. 병렬 실행: "일정도 확인하고 뉴스도 요약해줘" → 병렬 실행과 결과 합성, 지연 단축 체감
Step 3. 안전 가드레일: "메일 발송해줘" → 민감 액션 감지, 승인 대기 UI(Interrupt) 노출
Step 4. 최종 보고: 승인 이후 실행 결과 종합 보고
정리하기
1. 지능의 3대 기둥 완성 (Three Pillars)
지식(5강, Grounding): RAG & Citation — 근거를 갖춘 '기초 체력'
판단(6강, Reflection): Self-Correction — 스스로 오류를 거르는 '가드레일'
행동(7강, Action): Tool-calling — 실제 세계를 조작하는 '손과 발'
2. 세 기둥의 시너지 (Synergy)
Grounding + Reflection → 신뢰도: 근거 있는 답을 스스로 검증
Reflection + Action → 안정성: 실행 전 오류를 걸러 안전한 행동만 남김
Action + Grounding → 업무 완결성: 근거에 기반한 실제 결과물을 완성
3. 설계자의 통찰 (Architect's Insight)
업무형 에이전트의 완성도는 도구의 개수가 아니라, Description·병렬 처리·Human-in-the-loop이 얼마나 정교하게 맞물리는가에서 결정됨
평가문항
문항 1 / 5
업무형 에이전트에서 모델이 특정 함수(Tool)를 실제로 호출하기 위해 참고하는 것은 무엇인가?
① 함수의 실제 소스 코드 전체
② 함수 이름과 자연어 설명(Description), 파라미터 스펙
③ 함수가 저장된 서버의 IP 주소
④ 개발자가 작성한 별도의 테스트 케이스
정답 확인
정답 ② — 모델은 함수의 내부 구현을 보지 않고, Tool Registry에 등록된 자연어 설명과 파라미터 스펙만을 근거로 어떤 도구를 어떤 인자로 호출할지 판단합니다. 그래서 Description 엔지니어링이 도구 선택 정확도를 좌우합니다.
평가문항
문항 2 / 5
사용자가 "오늘 일정도 확인하고 뉴스도 요약해줘"처럼 서로 무관한 두 요청을 동시에 했을 때, 순차 호출 대신 병렬 도구 호출을 적용하면 얻는 이점은?
① 전체 응답 지연 시간이 각 호출 시간의 합(Sum)에서 최댓값(Max) 수준으로 줄어든다
② 두 도구의 결과가 자동으로 더 정확해진다
③ 모델이 사용하는 파라미터의 개수가 줄어든다
④ Harness Filter의 승인 절차를 생략할 수 있게 된다
정답 확인
정답 ① — 순차 호출은 지연 시간이 각 호출 시간의 합이 되지만, 한 추론 턴 안에서 여러 도구를 동시에 호출하면 전체 지연 시간은 가장 느린 호출 하나(Max) 수준으로 단축됩니다. 다만 여러 결과를 하나의 상태로 통합하는 처리는 별도로 설계해야 합니다.
평가문항
문항 3 / 5
Harness Filter가 도구 실행 전 반드시 사용자 승인을 요구해야 하는 액션은 다음 중 무엇인가?
① 사용자의 캘린더 일정을 조회하는 Read-only 도구
② 오늘의 날씨 정보를 검색하는 도구
③ 사내 문서 중 공개된 매뉴얼을 검색하는 도구
④ 사용자 대신 이메일을 실제로 발송하는 Write 도구
정답 확인
정답 ④ — Read-only 도구는 자동 실행해도 무방하지만, 메일 발송·DB 삭제·결제처럼 Write·Delete 권한을 수반하는 도구는 되돌리기 어려운 결과를 낳을 수 있으므로 Human-in-the-loop 승인을 반드시 거쳐야 합니다.
평가문항
문항 4 / 5
Tool-calling 아키텍처에서, Planner Node가 결정한 도구와 인자를 바탕으로 실제 외부 API를 호출하고 그 결과를 수집하는 컴포넌트는?
① Tool Registry
② Harness Filter
③ Action Executor
④ Synthesizer
정답 확인
정답 ③ — Tool Registry는 도구 명세를 관리하고, Planner Node는 어떤 도구·인자를 쓸지 결정하며, Action Executor가 실제 호출과 결과 수집을 담당합니다. Harness Filter는 민감 액션 승인, Synthesizer는 최종 결과 종합을 맡습니다.
평가문항
문항 5 / 5
대화형(Conversational) 에이전트와 오늘 배운 업무형(Task-oriented) 에이전트의 구조적 차이를 가장 정확히 설명한 것은?
① 업무형 에이전트는 지식과 판단에 더해 Tool-calling으로 외부 시스템을 직접 조작해 실제 결과(Outcome)를 만들어낸다
② 업무형 에이전트는 더 많은 파라미터를 가진 모델을 사용한다
③ 업무형 에이전트는 사용자에게 항상 더 짧은 답변을 준다
④ 업무형 에이전트는 Description 엔지니어링 없이도 모든 도구를 자동으로 이해한다
정답 확인
정답 ① — 실행형 지능(Actionable Intelligence)은 지식(5강, RAG&Citation)과 판단(6강, Self-Correction)에 Tool-calling이라는 행동을 결합해, 텍스트 응답을 넘어 실제 외부 시스템 조작과 업무 완수라는 결과를 만들어냅니다. 모델 크기나 응답 길이, Description 생략 여부와는 무관합니다.
다음으로
다음 강의 예고: 8강 「평가 하네스: 에이전트 지능의 정량적 측정」 — 오늘 완성한 실행형 지능이 실제로 잘 동작하는지, "좋은 것 같다"는 주관을 버리고 골든 데이터셋과 RAGAS 지표로 성능을 데이터로 증명하는 평가 하네스를 설계합니다.
08
평가 하네스: 에이전트 지능의 정량적 측정
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 8강
인트로
제8강. 평가 하네스: 에이전트 지능의 정량적 측정
"좋은 것 같다"는 주관을 버리고 데이터로 신뢰를 증명하라.
구성: 인트로 → 사전학습
사전학습 (생각해보기!)
주제: 여러분의 에이전트가 "잘 작동한다"는 것을, 무엇으로 증명하시겠습니까?
골든 데이터셋(Golden Dataset): 질문(Question) + 정답(Ground Truth) + 근거(Context)의 삼위일체
구축 방식: 사람이 직접 만드는 수동 구축 vs LLM으로 대량 생성하는 합성 데이터 생성
"좋은 것 같다"는 감상으로는 배포를 승인할 수도, 회귀를 잡아낼 수도 없습니다.
학습내용 및 목표
학습내용
평가 하네스(Evaluation Harness)의 개념과 필요성
RAGAS 프레임워크의 3대 지표: 충실도, 답변 관련성, 정답 수렴도
성적표(Scorecard) 스키마와 평가 자동화 파이프라인
CI/CD 품질 게이트와 규제·준거성 평가
학습목표
주관적인 Vibes-based Eval의 한계를 설명할 수 있다.
RAGAS의 3대 지표로 에이전트의 문제 지점을 정확히 진단할 수 있다.
평가 결과를 CI/CD 파이프라인의 배포 가부(Go/No-Go) 결정에 연결할 수 있다.
본학습
하네스(Harness)의 개념: 에이전트를 시험대에 세우다
사전적 의미: 마구, 안전벨트 / 공학적 의미: 안정적인 기동을 위한 테스트 프레임워크
하네스의 3대 역할: 실행 엔진, 환경 제어, 결과 모니터링
에이전트를 '시험대(Proving Ground)'에 끼워 넣어 품질을 검증하는 장치
본학습
왜 LLM 평가는 어려운가: Vibes-based Eval의 함정
전통적 소프트웨어 테스트: 결정론적(Deterministic) Pass/Fail 판정
LLM의 출력: 확률적(Probabilistic)이며 의미적 유사성으로만 판단 가능
Vibes-based Eval의 3대 함정: 샘플 편향, 주관성, 확장의 한계
블랙박스 문제: 결과가 나빠도 리트리버 문제인지 추론 문제인지 알 수 없음
본학습
평가의 두 기둥: Reference-based vs. Reference-free
Reference-based
Reference-free
골든 데이터셋과 비교(정답 수렴도, 시맨틱 유사도)
질문-문서-답변의 일관성 분석(Faithfulness, Answer Relevancy)
신뢰도 높음, 구축 비용 높음
정답지 없이도 대규모·실시간 모니터링에 유리
개발/검증 단계에 적합
운영/모니터링 단계에 적합
Reference-b…
골든 데이터셋과 비교
신뢰도 높음, 구축 비용 높음
개발/검증 단계에 적합
VS
Reference-f…
질문-문서-답변의 일관성 분석
정답지 없이도 대규모·실시간 모니터링에 유리
운영/모니터링 단계에 적합
본학습
RAGAS 프레임워크: LLM을 심판으로 세우다
RAG 시스템 평가를 위한 오픈소스 프레임워크
LLM을 '비판자(Critic)'로 활용해 정량적 지표를 자동 산출
BLEU/ROUGE 같은 단어 겹침 기반 지표의 한계를 극복 — 질문-컨텍스트-답변의 삼각 관계를 분석
3대 평가 축: Generation(생성) / Retrieval(검색) / End-to-End(전 과정)
본학습
지표 1. 충실도(Faithfulness): 근거 없는 확신을 걸러내다
정의: 답변이 검색된 컨텍스트에만 근거하고 있는가(할루시네이션 방지)
측정 방식: 클레임(주장) 추출 → 컨텍스트와 대조 → (근거가 확인된 주장 수) / (전체 주장 수)
6강 Self-Correction과 연결: 충실도가 임계치 이하로 떨어지면 재작성(Rewrite)을 트리거
본학습
지표 2. 답변 관련성(Answer Relevancy): 질문의 과녁을 맞히다
정의: 답변이 질문에 대해 적절하고 직접적인 해답을 제공하는가
측정 방식: 역질문 생성(답변 → 가상의 질문 유추) → 실제 질문과의 코사인 유사도 계산
Scorecard: Traceability·Granularity·Actionability를 갖춘 성적표 스키마와 Tiered Eval 파이프라인
CI/CD 품질 게이트: 임계치 미달 시 배포를 자동 차단하는 문지기, 그리고 규제·준거성 평가
3. 설계자의 통찰 (Architect's Insight)
에이전트에 대한 신뢰는 "좋은 것 같다"는 느낌이 아니라, 재현 가능한 데이터로 증명된 점수에서 나옵니다.
평가문항
문항 1 / 5
평가 하네스(Evaluation Harness)의 핵심적인 역할로 가장 적절한 것은?
① 사용자에게 더 자연스러운 답변을 생성하도록 프롬프트를 자동 튜닝한다
② 에이전트를 안정적인 시험대에 세워 입력을 주입하고 실행 환경을 통제하며 결과를 모니터링한다
③ 모델의 파라미터 수를 늘려 추론 성능을 높인다
④ 사용자의 질문을 자동으로 요약해 토큰 비용을 절감한다
정답 확인
정답 ② — 하네스는 사전적으로 마구·안전벨트를 뜻하며, 공학적으로는 실행 엔진·환경 제어·결과 모니터링이라는 세 가지 역할을 통해 에이전트를 '시험대(Proving Ground)'에 올려 품질을 검증하는 테스트 프레임워크입니다.
평가문항
문항 2 / 5
RAGAS의 세 가지 지표 중, 답변이 할루시네이션 없이 검색된 컨텍스트에만 근거하고 있는지를 판별하는 지표는?
① 답변 관련성(Answer Relevancy)
② 정답 수렴도(Answer Correctness)
③ 컨텍스트 재현율(Context Recall)
④ 충실도(Faithfulness)
정답 확인
정답 ④ — Faithfulness는 답변에서 클레임(주장)을 추출해 컨텍스트와 대조하고, 근거가 확인된 주장 수를 전체 주장 수로 나눠 산출하며, 6강의 Self-Correction과 연결되어 임계치 이하일 때 재작성을 트리거합니다.
평가문항
문항 3 / 5
"좋은 것 같다"는 식의 Vibes-based Eval을 지양해야 하는 근본적인 이유는?
① 평가자의 주관에 좌우되고 대규모로 확장하기 어렵기 때문이다
② 결정론적 Pass/Fail 판정만 가능해 세밀한 진단이 불가능하기 때문이다
③ 사람이 직접 골든 데이터셋을 만들어야 하기 때문이다
④ LLM 평가 비용이 지나치게 저렴해 신뢰할 수 없기 때문이다
정답 확인
정답 ① — LLM 출력은 결정론이 아닌 확률적·의미적 유사성의 문제이며, 샘플 편향·주관성·확장의 한계라는 3대 함정 때문에 리트리버 문제인지 추론 문제인지조차 구분하지 못하는 블랙박스 평가로 남습니다.
평가문항
문항 4 / 5
RAGAS의 답변 관련성(Answer Relevancy)을 측정할 때 사용하는 '역질문 생성' 방식의 원리는?
① 정답(Ground Truth)과 답변의 사실적 유사도를 가중 합산한다
② 컨텍스트에서 클레임을 추출해 근거 여부를 판별한다
③ 답변으로부터 가상의 질문을 역으로 유추한 뒤, 실제 질문과의 코사인 유사도를 계산한다
④ 답변과 컨텍스트의 단어 겹침(BLEU/ROUGE)을 계산한다
정답 확인
정답 ③ — 답변만 보고 "이 답변이 나오려면 어떤 질문이었을까"를 역으로 생성한 뒤 원래 질문과 임베딩 유사도를 비교함으로써, 장황한 답변을 억제하고 검색 품질까지 간접적으로 피드백합니다.
평가문항
문항 5 / 5
CI/CD 품질 게이트를 통한 평가 자동화가 주는 이점이 '아닌' 것은?
① 임계치 미달 시 배포를 자동으로 차단해 성능 회귀를 방지한다
② Critic 모델 호출 비용이 전혀 들지 않아 평가가 완전히 무료가 된다
③ "감(feel)"이 아닌 데이터 기반의 객관적인 배포 의사결정을 가능하게 한다
④ Push마다 골든 데이터셋으로 자동 평가해 회귀 발생 여부를 즉시 확인할 수 있다
정답 확인
정답 ② — LLM-as-a-Judge 방식의 Critic 모델 호출과 컴퓨팅 리소스에는 실제 비용이 발생하며, 이 때문에 샘플링 비율·Critic 모델 체급·평가 빈도를 조율하는 Tiered Eval(Level 1 경량 CI, Level 2 고성능 Release) 전략이 필요합니다.
다음으로
다음 강의 예고: 9강 「가드레일 & 모니터링: 운영 안정성 확보 전략」 — 오늘 배운 배포 전(Offline) 평가 하네스에 이어, 실제 운영 환경(Online)에서 에이전트를 관측하고 지키는 방법을 다룹니다. LangSmith를 통한 관측성, 입출력 다층 방어막, 캐싱·폴백을 통한 운영 안정성 확보 전략을 살펴봅니다.
09
가드레일 & 모니터링: 운영 안정성 확보 전략
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 9강
인트로
제9강. 가드레일 & 모니터링: 운영 안정성 확보 전략
"실험실의 에이전트는 천재지만, 야생의 에이전트는 시한폭탄일 수 있습니다."
구성: 인트로 → 사전학습
사전학습 (생각해보기!)
주제: 완벽한 평가를 통과한 에이전트가, 왜 배포 첫날부터 사고를 칠 수 있을까요?
평가(Evaluation): 배포 '전'에 이뤄지는 Offline 검증 — 골든 데이터셋, 충돌 테스트(정해진 문제지로 보는 모의고사)
Thought-Action-Observation 로그는 디지털 포렌식이자 문제 재현의 근거가 됨
2. 계층적 방어 체계 (Layered Defense)
Input Rail(보안) → Process Rail(통제) → Output Rail(품질)의 3단계가 프롬프트 인젝션, PII 유출, 무한 루프 등 야생의 리스크를 각각 책임짐
도구 호출은 최소 권한과 Human-in-the-loop으로, 콘텐츠는 모더레이션 모델과 자가 교정 루프로 통제함
3. 지속 가능한 운영 (Sustainable Operations)
캐싱·폴백·드리프트 감지·리얼타임 알럿으로 장애를 예방하고 우아하게 대응함
피드백 루프와 거버넌스를 통해 현장의 실패를 다음 버전의 자산으로, 그리고 법적·윤리적 신뢰로 되먹임함
평가문항
문항 1 / 5
LangSmith에서 에이전트의 Thought-Action-Observation 과정을 처음부터 끝까지 기록하여, 문제 발생 시 재현과 근본 원인 분석을 가능하게 하는 기능은?
① 시맨틱 캐싱(Semantic Caching)
② 서킷 브레이커(Circuit Breaker)
③ 풀 트레이싱(Full Tracing)
④ 알럿 등급화(Alert Grading)
정답 확인
정답 ③ — Full Trace는 에이전트의 사고 과정 전체를 기록해 디지털 포렌식처럼 근본 원인 분석과 재현을 가능하게 합니다. 캐싱은 비용·속도 최적화, 서킷 브레이커는 장애 전이 차단, 알럿 등급화는 알림 우선순위를 위한 기법으로 트레이싱과는 목적이 다릅니다.
평가문항
문항 2 / 5
사용자가 "이전 지시는 모두 무시해"와 같은 문구로 시스템 프롬프트를 무력화하거나 탈옥(Jailbreak)을 시도하는 보안 위협을 가리키는 용어는?
① 프롬프트 인젝션(Prompt Injection)
② 데이터 드리프트(Data Drift)
③ 시맨틱 캐싱(Semantic Caching)
④ 서킷 브레이커(Circuit Breaker)
정답 확인
정답 ① — 프롬프트 인젝션은 무력화, 탈옥, 데이터 탈취 등의 형태로 시스템을 공격하는 위협이며, 구분자를 통한 구조적 구분·입력 분류기·최소 권한 원칙으로 방어합니다. 나머지 보기는 성능 변질이나 운영 안정성과 관련된 별개의 개념입니다.
평가문항
문항 3 / 5
에이전트가 최종 답변을 사용자에게 전달하기 직전, 사실적 근거와 개인정보(PII) 노출 여부를 마지막으로 점검하는 가드레일 계층은?
① Input Rail
② Process Rail
③ Tool Access Control
④ Output Rail
정답 확인
정답 ④ — Output Rail(3단계)은 최종 응답의 품질과 PII 노출 여부를 검문하고, 문제가 있으면 안전한 답변으로 대체(폴백)합니다. Input Rail은 입력 단계의 보안, Process Rail과 Tool Access Control은 도구 호출 과정의 통제를 담당합니다.
평가문항
문항 4 / 5
주력 LLM API에 장애가 발생했을 때, 보조 모델 → 규칙 기반 로직 → 정적 안내 메시지 순으로 단계적으로 전환하며 서비스를 지속시키는 전략은?
① 시맨틱 캐싱(Semantic Caching)
② 폴백 전략(Fallback, Graceful Degradation)
③ 리얼타임 알럿(Real-time Alert)
④ 드리프트 모니터링(Drift Monitoring)
정답 확인
정답 ② — 폴백 전략은 장애 시 완전히 서비스를 멈추는 대신, 모델 폴백(보조 모델) → 로직 폴백(규칙·검색) → 정적 폴백(안내 메시지) 순으로 단계적으로 성능을 낮추며 서비스를 지속시킵니다. 서킷 브레이커·재시도 로직과 함께 운영 안정성을 뒷받침합니다.
평가문항
문항 5 / 5
배포 이후 시간이 지나면서 모델 제공사의 업데이트나 사용자 질문 패턴의 변화 등으로 인해 에이전트의 성능·응답 경향이 서서히 달라지는 현상을 가리키는 용어는?
① 알럿 피로도(Alert Fatigue)
② 프롬프트 인젝션(Prompt Injection)
③ 드리프트(Drift)
④ 최소 권한 원칙(Least Privilege)
정답 확인
정답 ③ — 드리프트는 모델 드리프트, 데이터 드리프트, 컨셉 드리프트로 구분되며, 답변 길이·토큰 분포 변화, 거부율 증가, RAGAS 점수 추이 하락 등의 신호로 감지합니다. 알럿 피로도는 알림 설계의 부작용이고, 나머지는 보안·권한 관련 개념입니다.
다음으로
다음 강의 예고: 10강 「엔터프라이즈 최적화: 비용, 속도, 그리고 미래」 — 오늘 확보한 운영 안정성을 바탕으로, 개인용과 기업용 에이전트의 요구 수준이 어떻게 달라지는지, 그리고 비용과 속도를 함께 최적화하는 전략을 다루며 이번 10강 시리즈의 마지막 여정을 마무리합니다.
10
엔터프라이즈 최적화: 비용, 속도, 그리고 미래
컨텍스트 엔지니어링으로 배우는 AI 에이전트 · 10강
인트로
제10강. 엔터프라이즈 최적화: 비용, 속도, 그리고 미래
"실험실의 성공은 시작일 뿐입니다. 기업의 성공은 효율과 지표로 증명됩니다."
구성: 인트로 → 사전학습
사전학습 (생각해보기!)
주제: 10만 명이 동시에 몰려드는 순간, 여러분의 에이전트는 살아남을 수 있습니까?
사전 점검 질문
사용자 10만 명이 하루 한 번씩 호출한다면, 이 비용을 우리 회사가 감당할 수 있는가?
응답이 5초 이상 지연된다면, 사용자는 몇 명이나 이탈할 것인가?
주력 모델이나 API에 장애가 발생한다면, 우리 시스템은 어떤 대안을 갖고 있는가?
PoC(개인용·시범)와 프로덕션(엔터프라이즈)은 전혀 다른 게임의 규칙 위에서 움직입니다.
학습내용 및 목표
학습내용
비용 최적화: 토큰 경제학, 모델 티어링, 지능형 캐싱
속도 최적화: TTFT 단축, 스트리밍, 병렬·비동기 워크플로우, RAG 파이프라인 튜닝
확장성과 운영: 멀티 에이전트 오케스트레이션, 엔터프라이즈 인프라·보안·거버넌스
미래 전망: AI 도입 로드맵과 ROI, 자율적 기업으로의 전환
학습목표
토큰 경제학과 모델 티어링으로 운영 비용을 절감하는 전략을 설명할 수 있다.
TTFT·스트리밍·병렬 처리 등 체감 속도를 높이는 기법을 적용할 수 있다.
오케스트레이션과 안무형 패턴을 구분해 목적에 맞는 멀티 에이전트 시스템을 설계할 수 있다.
엔터프라이즈 도입 로드맵과 ROI 관점에서 에이전트 프로젝트를 설명할 수 있다.
본학습
개인용 에이전트 vs 엔터프라이즈 에이전트
구분
개인용/PoC
엔터프라이즈/프로덕션
목표
기능 구현·가능성 검증
비즈니스 가치·운영 효율화
비용
무시 가능
수익성(ROI) 핵심 변수
속도
나오기만 하면 됨
초단위 경쟁
신뢰도
가끔 틀려도 재시도
엄격한 SLA 준수
인프라
로컬·단순 API
확장성·고가용성
개인용/PoC
기능 구현·가능성 검증
무시 가능
나오기만 하면 됨
가끔 틀려도 재시도
VS
엔터프라이즈/프로덕션
비즈니스 가치·운영 효율화
수익성
초단위 경쟁
엄격한 SLA 준수
본학습
비용 최적화 (1): 프롬프트 엔지니어링과 토큰 경제학
토큰 경제학: 입력 비용보다 출력 비용이 더 비쌈, 누적의 법칙(요청 1건당 100토큰만 줄여도 월 단위로는 수천 달러의 절감)
프롬프트 압축: 중복된 형용사·부사 제거, 명확한 지시어 사용, 압축 프레임워크 적용
구조화된 출력(JSON Mode): 자연어 서술을 생략하고, 출력 토큰을 최소화하며, 후속 시스템이 바로 활용 가능
본학습
비용 최적화 (2): 모델 티어링
계층
역할
모델 예시
비용
Tier 1 (High-End)
복잡 논증·코드·전략 기획
GPT-4o, Claude 3.5 Sonnet
매우 높음
Tier 2 (Mid)
일반 상담·요약·의도 파악
GPT-4o mini, Gemini 1.5 Flash
낮음
Tier 3 (SLM/Local)
단순 분류·마스킹·포맷
Llama 3(8B), Phi-3
매우 낮음
라우터: 작은 모델이 난이도를 먼저 평가한 뒤 분기("안녕?" → Tier 3, "요약해줘" → Tier 2, "전략을 분석해줘" → Tier 1)
계층화만으로 운영 비용 80% 절감이 가능합니다.
본학습
비용 최적화 (3): 지능형 캐싱과 데이터 재사용
시맨틱 캐싱 고도화: 벡터 유사도로 유사 질문을 즉시 반환(비용 0, 응답 속도 10ms 이하)
컨텍스트 관리: 대화 요약(Conversation Summary), 토큰 절단(Truncation)
RAG 재사용: 검색 결과 조각(chunk)을 캐싱해 동일 검색을 반복하지 않음
TTL(Time To Live) 차등 설정: 실시간 주가는 1분, 회사 규정 같은 정적 정보는 1개월 등
본학습
속도 최적화 (1): 스트리밍과 체감 UX
TTFT(Time To First Token): 요청 후 첫 글자가 출력되기까지 걸리는 시간, 이탈률에 결정적, 권장 기준은 2초 이내
스트리밍(SSE, Server-Sent Events): 토큰이 생성되는 즉시 전송 → 체감 대기 시간 단축
인지적 지연 관리: 상태 시각화, 스켈레톤 UI·프로그레스 바, 중간 결과 노출
본학습
속도 최적화 (2): 병렬·비동기 워크플로우
순차(Sum) vs 병렬(Max): 서로 의존성이 없는 작업은 동시에 실행해 전체 소요 시간을 단축
멀티 도구 호출: 예를 들어 "날씨와 주가를 함께 알려줘" 같은 요청은 두 API를 동시에 호출하고 결과만 취합
비동기 워크플로우: Async/Await 구조로, 로그 기록이나 데이터 분석·감사처럼 사용자 응답에 영향 없는 작업은 백그라운드로 분리 처리
본학습
속도 최적화 (3): RAG 파이프라인 튜닝
지연 발생 원인: 임베딩 계산 오버헤드, 검색(벡터 조회) 병목, 컨텍스트 과부하
Small-to-Big Retrieval: 검색은 작은 단위(문장·문단)로 정밀하게 하되, 실제 전달은 그 문맥을 포함하는 더 큰 부모 청크(Chunk)로 함
인덱싱 최적화: 메타데이터 필터링으로 검색 범위 축소, 하이브리드 검색(키워드+벡터), HNSW 인덱스로 밀리초(ms) 단위 검색
본학습
확장성 (1): 멀티 에이전트의 필연성
단일(Monolith) 구조의 한계: 컨텍스트 과부하로 인해 정작 중요한 정보가 중간에 묻히는 'Lost in the Middle' 현상, 서로 다른 역할이 뒤섞이며 생기는 지식의 희석, 손댈수록 꼬여가는 유지보수 지옥
멀티 에이전트의 장점: 관심사 분리를 통한 전문성 확보, 독립적인 튜닝과 디버깅, 업무 성격에 맞는 최적 모델 배치
한계: 전체 성능이 매니저 에이전트의 역량에 종속됨, 위임 단계가 늘어날수록 지연도 함께 늘어남
본학습
확장성 (3): 안무형(Choreography) 패턴
구분
오케스트레이션(매니저형)
안무형(선형/순환형)
의사결정
매니저가 동적으로 결정
미리 정의된 워크플로우를 따름
유연성
복잡하고 가변적인 작업에 유리
정형적이고 반복적인 작업에 유리
복잡도
매니저 프롬프트 설계가 어려움
개별 설계는 쉽지만 전체 흐름 관리가 중요
비용/속도
매니저 호출 비용이 추가로 발생
중간 판단 비용이 적어 효율적
순차형: A가 조사 → B가 작성 → C가 검수하는 일렬 흐름
순환형: 검수 결과가 불만족스러우면 다시 작성 단계로 되돌아가는 루프(LangGraph의 상태 머신 방식)
본학습
엔터프라이즈 인프라: 클라우드 vs 온프레미스 vs 서버리스
구분
클라우드 SaaS
온프레미스/프라이빗
서버리스
특징
Azure OpenAI, AWS Bedrock 등
자체 GPU + 오픈소스 LLM
Lambda, Cloud Functions
장점
빠른 배포·최신 모델 활용
데이터 보안·고정비 구조
사용량만큼만 지불·관리 부담 제로
단점
데이터 유출 우려·비용 변동성
초기 구축 비용·전담 운영 인력 필요
Cold Start 지연·실행 시간 제한
추천
PoC·범용 에이전트
핵심 금융/의료 업무·대량 호출
간헐적 배치 작업·트리거형 업무
클라우드 SaaS
Azure OpenAI, AWS Bedro…
빠른 배포·최신 모델 활용
데이터 유출 우려·비용 변동성
PoC·범용 에이전트
VS
온프레미스/프라이빗
자체 GPU + 오픈소스 LLM
데이터 보안·고정비 구조
초기 구축 비용·전담 운영 인력 필요
핵심 금융/의료 업무·대량 호출
본학습
엔터프라이즈 보안과 거버넌스
에이전트 전용 IAM: 최소 권한 원칙과 샌드박스 환경으로 에이전트가 접근할 수 있는 범위를 엄격히 제한
감사 로그(Immutable Log): 변경이 불가능한 기록을 남겨, 문제가 생겼을 때 소명 가능성을 확보
중앙 집중 거버넌스: 정책 엔진으로 규칙을 일괄 적용하고, 데이터 주권이 필요한 경우 Opt-out(제외) 옵션을 제공
본학습
배포 전 최종 체크리스트
경제성: 캐싱 임계값 설정, 모델 티어링 분기 로직 점검, 토큰 사용량 모니터링 체계 구축
성능/UX: TTFT 2초 이내 확보, 스트리밍 적용, 병렬 처리 구조 점검
보안/거버넌스: 최소 권한(IAM) 적용, PII 마스킹, 프롬프트 인젝션 방어
신뢰성/운영: 폴백(Fallback) 전략, 풀 트레이싱, 감사 로그(Immutable) 확보
본학습
AI 도입 로드맵: 12개월의 여정
Step 1 (0~3개월) 도입·PoC: 사내 지식 검색(RAG)과 같은 Quick Win 유스케이스 선정, 클라우드 LLM으로 시범 운영, 가드레일 프로토타입 구축, KPI 설정 → MVP와 비즈니스 사례 보고서 산출
Step 2 (4~8개월) 확산·표준화: 에이전트 허브 구축(SDK·텔레메트리·커넥터 표준화로 개발 속도 50% 이상 향상), AI CoE(Center of Excellence) 거버넌스 수립, 백오피스·프론트오피스로 확대, AgentOps 체계 도입 → 통합 플랫폼과 5개 이상의 운영 에이전트 확보
Step 3 (9~12개월 이후) 에이전틱 에코시스템: 에이전트 간 자율 협업, AI-First 프로세스 재설계, 자가 최적화 루프, 지능형 의사결정 지원 → 자율 경영 에코시스템과 신규 수익 모델 창출
본학습
ROI 분석: 숫자와 그림자 비용
Hard ROI: 인건비 대체 효과, 인프라·토큰 비용 최적화(캐싱·티어링), 오류로 인한 손실 비용 감소
Soft ROI: 24시간 연중무휴 확장성, 고객 경험(CX)과 직원 경험(EX) 향상, 의사결정 속도의 가속화
그림자 비용(Shadow Cost): 에이전트를 도입하지 않았을 때 발생하는 기회비용과 경쟁력 약화
본학습
미래: 자율적 기업(Autonomous Enterprise)
조직의 변화: 정적인 계층 구조에서 유연한 네트워크, 즉 '액체형 조직'으로. 에이전트는 도구가 아니라 함께 일하는 동료로
업무의 전환: Human-on-the-loop — 사람은 직접 실행하는 자리에서, 예외 상황을 관리하고 전체를 설계하는 자리로 이동
아키텍트의 새로운 사명: 메타-오케스트레이터 — 개별 에이전트가 아니라 지능 전체의 거버넌스와 의사결정의 무결성을 책임지는 존재로
에이전트의 가치는 모델의 성능이 아니라, '비용·속도·신뢰 사이의 균형을 설계하는 아키텍처와 거버넌스'에서 완성됨
평가문항
문항 1 / 6
작은 모델이 요청의 난이도를 먼저 평가한 뒤, 단순한 인사말은 소형 모델(Tier 3)로, 복잡한 전략 분석은 대형 모델(Tier 1)로 자동 분기시켜 운영 비용을 낮추는 전략은?
① 구조화된 출력(JSON Mode)
② 모델 티어링(Model Tiering)
③ Small-to-Big Retrieval
④ 인지적 지연 관리
정답 확인
정답 ② — 난이도에 따라 Tier 1(고성능)·Tier 2(중간)·Tier 3(경량) 모델로 트래픽을 분기하는 계층화 전략이며, 이 계층화만으로 운영 비용을 최대 80%까지 절감한 사례가 보고됩니다.
평가문항
문항 2 / 6
사용자의 요청 후 화면에 첫 글자가 출력되기까지 걸리는 시간을 가리키며, 프로덕션 환경에서 이탈률에 결정적인 영향을 주는 지표는? 권장되는 기준은 몇 초 이내인가?
① Round Trip Time, 10초 이내
② Token Throughput, 1초 이내
③ TTFT(Time To First Token), 2초 이내
④ Latency Budget, 5초 이내
정답 확인
정답 ③ — TTFT는 요청 후 첫 토큰이 출력되기까지의 시간으로, 사용자 이탈에 직결되는 핵심 지표입니다. 업계 권장 기준은 2초 이내이며, 이를 단축하기 위해 스트리밍(SSE)이 활용됩니다.
평가문항
문항 3 / 6
이전 질문과 의미적으로 유사한 질문이 들어오면 벡터 유사도로 즉시 결과를 반환해, 비용을 사실상 0으로, 응답 속도를 10ms 이하로 낮추는 기법은?
① 시맨틱 캐싱(Semantic Caching)
② 프롬프트 압축
③ 하이브리드 검색
④ TTL(Time To Live) 차등 설정
정답 확인
정답 ① — 시맨틱 캐싱은 문자열이 완전히 같지 않아도 의미가 유사한 질문을 벡터 유사도로 감지해 즉시 캐시된 답을 반환하는 기법으로, 비용과 지연을 동시에 낮춥니다.
평가문항
문항 4 / 6
매니저 에이전트 없이, 미리 정의된 워크플로우(순차형·순환형)에 따라 에이전트들이 각자의 역할을 수행하며 협업하는 오케스트레이션 방식은?
① 중앙 집중형 오케스트레이션
② Human-in-the-loop 구조
③ Full-Autonomous 구조
④ 안무형(Choreography) 패턴
정답 확인
정답 ④ — 안무형 패턴은 매니저의 동적 판단 대신 미리 정의된 흐름을 따르므로, 매니저 호출 비용이 없고 중간 판단 비용이 적어 정형적·반복적 업무에 효율적입니다.
평가문항
문항 5 / 6
에이전트를 '도입하지 않았을 때' 발생하는 기회비용과 경쟁력 약화를 가리키는, ROI 분석의 세 번째 축은?
① Hard ROI
② 그림자 비용(Shadow Cost)
③ Soft ROI
④ 총소유비용(TCO)
정답 확인
정답 ② — Hard ROI는 인건비 대체나 인프라 최적화처럼 숫자로 증명되는 가치, Soft ROI는 24/7 확장성·CX/EX 향상 같은 정성적 가치입니다. 그림자 비용은 도입 지연이 만드는 보이지 않는 기회비용을 뜻합니다.
평가문항
문항 6 / 6
AI 도입 로드맵의 마지막 단계(9~12개월 이후, Step 3)에서 목표로 하는 조직의 모습으로 가장 알맞은 것은?
① 소수의 담당자가 챗봇 한두 개를 시범 운영하는 PoC 단계
② 에이전트 허브와 SDK 표준화를 처음 도입하는 확산 단계
③ 에이전트 간 자율 협업과 자가 최적화 루프로 움직이는 에이전틱 에코시스템
④ 모든 업무를 사람이 직접 검토·승인하는 완전 수동 체계
정답 확인
정답 ③ — Step 3는 에이전트 간 자율 협업, AI-First 프로세스 재설계, 자가 최적화 루프, 지능형 의사결정 지원을 통해 자율 경영 에코시스템과 신규 수익 모델을 지향하는 단계입니다.
마치며
과정을 마치며 자, 이제 정말 마지막입니다. 10강에 걸쳐 우리는 챗봇을 넘어선 자율적 에이전트의 정의부터, 그 지능을 지탱하는 컨텍스트와 메모리, 신뢰를 지키는 안전장치, 그리고 오늘 다룬 비용과 속도와 확장성까지, 하나의 완결된 아키텍처로 쌓아 올렸습니다. 여러분은 이제 단순히 AI에게 말을 거는 사용자가 아닙니다. Sense-Think-Act 루프를 설계하고, 메모리를 계층화하고, 모델 티어링으로 비용을 다스리며, 오케스트레이션으로 여러 에이전트를 하나의 조직처럼 지휘하는 '에이전트 아키텍트'입니다. 기술은 계속 바뀔 것입니다. 오늘 배운 최적의 모델도, 오늘의 캐싱 기법도 1년 뒤에는 낡은 이야기가 되어 있을지 모릅니다. 하지만 결과(Outcome)를 설계하는 관점, 비용과 속도와 신뢰 사이에서 균형을 잡아내는 아키텍트의 안목만큼은 변하지 않습니다. 그것이 이 열 번의 시간을 통해 여러분 안에 남기고 싶었던 단 하나의 자산입니다. 이제 여러분의 조직 안에서, 여러분이 설계한 첫 번째 자율적 에이전트가 실제로 결과를 만들어내는 그 순간을 직접 확인해 보시기 바랍니다. 여기까지 함께해 주셔서 감사합니다.