Chapter 11

개선 루프

11.1 피드백 파이프라인
11.2 실험
11.3 지속 학습

모니터링으로 문제를 발견하는 건 시작일 뿐이야. 진짜 중요한 건 그 데이터로 실제로 어떻게 개선하느냐지. 저자가 강조하는 건 이게 일회성이 아니라 루프여야 한다는 점이야 — 발견 → 분석 → 수정 → 검증이 계속 돌아야 하거든.

에이전트가 프로덕션에 나가면 온갖 문제가 생겨. 환각, 도구 호출 실패, 느린 응답, 사용자 불만. 이걸 체계적으로 수집하고 개선으로 연결하는 파이프라인이 필요하지.

사람이 매번 로그 뒤져서 문제 찾을 수는 없으니까, 자동화해야 해. 저자가 제시하는 자동 탐지 방식은 이래:

이상 탐지(Anomaly Detection) — 평소 패턴에서 벗어나는 걸 잡는 거야. 응답 시간이 갑자기 2배로 뛰었다든가, 특정 도구 호출 실패율이 급증했다든가. 통계적 기준선을 세워놓고 이탈하면 알림
LLM-as-Judge 자동 평가 — 에이전트 응답을 다른 LLM이 자동으로 채점하는 거지. 10장에서 다뤘던 평가 방식을 실시간 모니터링에 붙이는 것
사용자 신호 수집 — 명시적 피드백(좋아요/싫어요, 별점)도 있고, 암묵적 신호(재시도 횟수, 세션 이탈률, 응답 수정 빈도)도 있어

문제를 찾았으면 왜 생겼는지 파악해야 해 — 이게 근본 원인 분석(Root Cause Analysis)이야. 같은 증상이라도 원인이 다를 수 있거든.

예를 들어 "에이전트가 틀린 답을 줬다"는 증상 하나에도 원인은 여러 가지야:

프롬프트가 모호해서 모델이 잘못 해석
검색한 문서가 오래된 정보
도구가 에러를 반환했는데 에이전트가 무시하고 진행
모델 자체의 환각

저자는 이걸 체계적으로 분류하기 위해 **실패 택소노미(Failure Taxonomy)**를 만들라고 해. 프롬프트 문제, 도구 문제, 지식 문제, 모델 문제 — 카테고리를 나눠놓으면 어디를 고쳐야 하는지 빨리 판단할 수 있지.

자동화가 다 잡아주면 좋겠지만, 현실은 그렇지 않잖아. 자동 평가가 놓치는 미묘한 품질 문제들이 있고, 특히 기술적으로 맞지만 맥락적으로 부적절한 응답은 사람만 잡을 수 있어.

저자가 제시하는 인간 리뷰 구조는 이래:

계층적 피드백 — 간단한 이진 피드백(좋다/나쁘다)부터 시작해서, 문제가 있으면 더 상세한 피드백(어디가 왜 잘못됐는지)을 받는 구조야. 모든 응답에 상세 리뷰를 달 수는 없으니까 단계를 나누는 거지
전문가 리뷰 큐 — 자동 평가에서 낮은 점수를 받거나, 사용자가 부정 피드백을 준 케이스를 큐에 넣어서 도메인 전문가가 리뷰해
골든 데이터셋 확장 — 리뷰 과정에서 발견된 좋은 예시와 나쁜 예시를 평가 데이터셋에 추가하는 거야. 이러면 자동 평가의 정확도도 점점 올라가지

핵심은 인간 리뷰가 일회성 검수가 아니라 시스템 개선의 입력이 되어야 한다는 거야. 리뷰 결과가 프롬프트 수정이나 도구 개선으로 이어지지 않으면 시간 낭비잖아.

피드백에서 문제 원인을 찾았으면, 실제로 고쳐야 해. 에이전트에서 고칠 수 있는 건 크게 두 가지 — 프롬프트와 도구야.

프롬프트 정제:

실패 케이스를 분석해서 프롬프트의 어느 부분이 모호한지 찾고
few-shot 예시를 추가하거나 수정하고
가드레일(출력 형식 제약, 금지 행동 명시)을 강화하지
저자는 프롬프트를 직접 사용자에게 노출하기보다, 맥락적 가이드(contextual guidance) 메커니즘을 통해 도메인 지식을 주입하라고 해. 프롬프트 엔지니어링을 모르는 사람도 개선에 참여할 수 있게

도구 정제:

도구 설명(description)이 불분명해서 에이전트가 잘못된 도구를 선택하는 경우 → 설명 수정
도구의 입출력 스키마가 에이전트에게 혼란을 주는 경우 → 스키마 단순화
특정 도구가 에러를 자주 뱉는 경우 → 재시도 로직이나 폴백 추가
필요한 도구가 아예 없는 경우 → 새 도구 개발

피드백은 쏟아지는데 엔지니어링 리소스는 한정적이잖아. 뭘 먼저 고칠지 정해야 해.

저자의 우선순위 프레임워크:

영향도(Impact) — 이 문제가 얼마나 많은 사용자에게 영향을 주는가
심각도(Severity) — 단순 불편인가, 완전히 잘못된 결과인가
수정 용이성(Effort) — 프롬프트 한 줄 고치면 되는 건지, 아키텍처를 뜯어야 하는 건지
빈도(Frequency) — 얼마나 자주 발생하는가

이걸 종합해서 높은 영향도 + 낮은 수정 비용인 것부터 치우는 거야. 프롬프트 수정으로 해결되는 고빈도 이슈가 가장 먼저 처리해야 할 후보지.

프롬프트를 고쳤어, 도구를 바꿨어 — 근데 이게 정말 나아진 건지 어떻게 알아? 감으로? 안 돼. 체계적인 실험이 필요해.

가장 안전한 실험 방법은 **섀도 배포(Shadow Deployment)**야. 새 버전 에이전트를 그림자처럼 뒤에서 돌리는 거지.

작동 방식:

사용자 요청이 들어오면 기존 에이전트(v1)가 실제로 응답
동시에 새 에이전트(v2)도 같은 요청을 처리하지만, 결과는 사용자에게 안 보여줌
v1과 v2의 응답을 오프라인에서 비교 분석

장점이 명확해 — 사용자 경험에 전혀 영향 없이 실제 트래픽으로 테스트할 수 있거든. 합성 데이터나 테스트 시나리오로는 못 잡는 엣지 케이스를 실제 데이터로 확인할 수 있는 거야.

다만 한계도 있어:

비용이 2배 (두 에이전트를 동시에 돌리니까)
부작용(side effect)이 있는 도구는 섀도에서 실행하면 안 돼. 이메일 보내기, 주문 넣기 같은 건 mock으로 대체해야 하지
**확률적 분산(probabilistic variance)**을 실제 데이터로 검증할 수 있다는 게 핵심 가치야

전통적인 실험 방법인 A/B 테스트도 있어. 사용자를 두 그룹으로 나눠서 각각 다른 버전을 보여주고 결과를 비교하는 거지.

에이전트 A/B 테스트가 웹사이트 A/B 테스트랑 다른 점이 있어:

비결정성 — 같은 프롬프트에도 다른 응답이 나올 수 있어서, 충분한 샘플이 필요해. 버튼 색깔 바꾸는 것보다 훨씬 많은 데이터가 필요하지
다차원 메트릭 — 정확도, 지연시간, 비용, 사용자 만족도를 동시에 봐야 해. 정확도는 올랐는데 비용이 3배면 성공인가?
장기 효과 — 에이전트 변경의 효과가 바로 안 나타날 수 있어. 사용자가 새 버전에 적응하는 데 시간이 걸리거든

저자가 강조하는 건 **통계적 유의성(Statistical Significance)**을 꼭 확인하라는 거야. 에이전트의 비결정성 때문에 노이즈가 크니까, 직감적으로 "좋아 보인다"로 판단하면 안 돼. p-value 계산하고, 신뢰 구간 확인하고, 충분한 샘플 사이즈 확보해야 하지.

A/B 테스트의 약점이 있어 — 실험 기간 동안 절반의 트래픽이 열등한 버전에 가고 있다는 거야. 이걸 **탐색-착취 트레이드오프(Exploration-Exploitation Tradeoff)**라고 하는데, **베이지안 밴딧(Bayesian Bandit)**이 이걸 해결해.

작동 원리:

처음에는 트래픽을 50:50으로 나눔
데이터가 쌓이면서 더 나은 버전이 보이기 시작하면, 그쪽으로 트래픽을 점점 더 보냄
최종적으로는 거의 모든 트래픽이 승자에게 감

A/B 테스트 대비 장점:

기회 비용 최소화 — 열등한 버전에 트래픽을 오래 보내지 않아
자동 수렴 — 명시적으로 "실험 종료"를 선언할 필요 없이 자연스럽게 좋은 버전으로 수렴하지
다변량 테스트에 강함 — 프롬프트 A vs B vs C vs D를 동시에 테스트할 때, A/B 테스트는 트래픽 분산이 심해지지만 밴딧은 빨리 하위 후보를 쳐내거든

저자는 **맥락적 밴딧(Contextual Bandit)**도 언급하는데, 이건 사용자 특성(쿼리 유형, 언어, 도메인)에 따라 다른 버전이 최적일 수 있다는 걸 반영한 고급 버전이야. 예를 들어 프롬프트 A가 코딩 질문에는 좋고 프롬프트 B가 분석 질문에는 좋을 수 있잖아.

실험 중에도 이건 너무 나쁘다 싶으면 즉시 중단할 수 있어야 해. 저자가 말하는 게이팅(Gating) 전략:

품질 게이트 — 핵심 메트릭(정확도, 안전성)이 임계값 아래로 떨어지면 자동 롤백
점진적 롤아웃 — 1% → 5% → 25% → 100%로 단계적으로 트래픽을 늘려. 각 단계에서 메트릭 확인
킬 스위치 — 심각한 문제 발견 시 즉시 이전 버전으로 되돌리는 메커니즘

이건 에이전트만의 얘기가 아니라 소프트웨어 배포 일반론이기도 한데, 에이전트에서는 비결정성 때문에 게이트 기준을 어떻게 잡느냐가 더 까다로워. "정확도 95% 이하면 롤백"이라고 했는데, 어떤 시간대에는 93%이고 어떤 시간대에는 97%이면? 이동 평균이나 통계적 검정을 써야 하는 이유지.

배포한 에이전트가 영원히 그 수준에 머물면 안 되잖아. 세상은 변하고, 사용자 요구도 변하고, 데이터도 변해. 에이전트가 이 변화에 적응하는 방법을 저자는 크게 두 가지로 나눠.

먼저 인컨텍스트 학습(In-Context Learning) — 모델 가중치를 건드리지 않고, 컨텍스트 윈도 안에서 학습하는 방식이야. 현재 LLM 에이전트의 주요 학습 메커니즘이지.

왜 이게 중요하냐면 — 프로덕션에 나간 LLM의 가중치는 보통 고정(frozen)되어 있거든. 매번 파인튜닝할 수도 없고, 해도 위험해. 그래서 가중치 업데이트 없이 에이전트가 경험에서 배우게 하는 게 핵심 과제야.

구체적인 방법들:

경험 메모리(Experience Memory) — 과거 성공/실패 사례를 저장해두고, 비슷한 상황이 오면 꺼내서 컨텍스트에 넣어. few-shot의 동적 버전이라고 보면 돼
전략 라이브러리(Strategy Library) — 에이전트가 여러 상호작용에서 추출한 추상적 원칙을 저장하는 거야. "이런 유형의 질문에는 이렇게 접근하면 효과적이더라"라는 메타 지식
RAG(Retrieval-Augmented Generation) 업데이트 — 지식 베이스를 주기적으로 갱신해서 최신 정보를 반영해. 모델은 못 바꿔도 검색 대상은 바꿀 수 있으니까

최근 연구에서는 이걸 **토큰 공간에서의 학습(Learning in Token Space)**이라고 부르기도 해. 가중치가 아니라 컨텍스트(토큰)를 업데이트하는 게 LLM 에이전트의 자연스러운 학습 방식이라는 관점이지. Letta 같은 프레임워크가 이 접근을 취하고 있어.

인컨텍스트 학습의 한계도 명확해:

컨텍스트 윈도 크기 제한. 경험이 아무리 많아도 한 번에 다 못 넣지
어떤 경험을 꺼내올지 결정하는 검색 품질에 의존하고
근본적인 능력 부족(reasoning이 약한 것)은 컨텍스트로 못 고쳐

인컨텍스트 학습으로 안 되는 수준의 개선이 필요하면, 결국 모델을 건드려야 해. 이게 **오프라인 재학습(Offline Retraining)**이야.

파인튜닝(Fine-Tuning):

프로덕션에서 수집한 데이터로 모델을 특정 도메인에 맞게 조정
LoRA 같은 효율적 방법으로 전체 모델을 재학습하지 않고 어댑터만 학습
문제는 학습 신호를 어디서 가져오느냐야. 사용자 피드백? 자동 평가? 전문가 라벨링? 각각 장단점이 있지

경험 증류(Experience Distillation):

에이전트가 프로덕션에서 쌓은 궤적(trajectory)을 분석해서, 성공 패턴을 추상적 원칙으로 정리하는 거야
이 원칙을 다시 학습에 활용하거나 프롬프트에 반영
EvolveR 같은 프레임워크가 이 접근을 취해 — 온라인 상호작용 → 오프라인 증류 → 강화학습으로 전략 내재화

RLHF / 강화학습 기반 개선:

인간 피드백이나 자동 보상 신호로 에이전트의 의사결정을 강화학습으로 개선하는 건데
가장 강력하지만 가장 비용이 높은 방법이야

오프라인 재학습에서 저자가 특히 경고하는 위험들이 있어:

카타스트로픽 포겟팅(Catastrophic Forgetting) — 새로운 데이터로 학습하면서 기존에 잘하던 걸 까먹는 현상이야. A 도메인 데이터로 파인튜닝했더니 B 도메인 성능이 떨어지는 거지
분포 이동(Distribution Shift) — 학습 데이터와 프로덕션 데이터의 분포가 달라지는 문제. 계속 모니터링해야 해
과적합(Overfitting) — 수집한 데이터의 특정 패턴에만 맞춰지는 거

그래서 저자의 결론은 — 인컨텍스트 학습을 우선 시도하고, 그걸로 안 될 때만 오프라인 재학습을 고려하라야. 인컨텍스트 학습은 롤백이 쉽고 위험이 낮거든. 오프라인 재학습은 강력하지만 실패하면 되돌리기 어렵지.

정리

11장 읽고 기억할 거 세 가지:

피드백은 수집만 하면 의미 없어. 탐지 → 분석 → 수정 → 검증의 루프가 돌아야 해. 실패 택소노미를 만들고, 우선순위를 정하고, 실제로 고쳐야 하지
감으로 배포하지 마. 섀도 배포로 안전하게 검증하고, A/B 테스트로 통계적으로 확인하고, 베이지안 밴딧으로 효율적으로 실험해. 게이팅으로 안전장치도 걸어두고
모델 재학습은 최후의 수단이야. 인컨텍스트 학습(경험 메모리, 전략 라이브러리, RAG 업데이트)으로 해결되는 게 대부분이고, 오프라인 재학습은 카타스트로픽 포겟팅 같은 위험이 따르거든