에이전트 개선 루프의 시작은 트레이스(Trace)입니다
요약
에이전트 시스템을 체계적으로 개선하기 위해서는 실행 과정의 기록인 트레이스(Trace)를 확보하고 이를 평가 및 피드백으로 풍부하게 만드는 과정이 필수적입니다. 트레이스는 에이전트가 실제로 수행한 동작을 보여주는 핵심 데이터이며, 이를 통해 실패 패턴을 식별하고 타겟팅된 변경을 수행하는 반복적인 개선 루프를 구축할 수 있습니다.
핵심 포인트
- 에이전트 개선의 핵심은 트레이스(Trace)를 통해 실행 과정을 포착하고 이를 데이터로 활용하는 것입니다.
- 트레이스는 LLM 호출, 도구 사용, 검색 단계 및 결정 순서 등 에이전트의 실제 동작을 기록하는 역할을 합니다.
- 단순한 트레이스를 평가(Evals)와 인간의 피드백으로 풍부하게 만들어 개선의 근거로 삼아야 합니다.
- LangSmith와 같은 도구는 트레이스 수집부터 CI/CD 게이트를 통한 검증까지 개선 루프의 전 과정을 지원합니다.
핵심 요약 (Key Takeaways)
- 에이전트(Agent)는 모델을 중심으로 여러 계층을 업데이트할 수 있는 시스템입니다: 모델 가중치(Model weights), 오케스트레이션 코드(Orchestration code), 그리고 컨텍스트(Context; 프롬프트, 지침, 기술)가 이에 해당합니다. 무엇을 변경해야 할지 알기 위해서는 트레이스(Traces)로부터 얻은 증거가 필요합니다.
- 트레이스는 스테이징(Staging), 테스트 실행(Test runs), 벤치마크(Benchmarks), 로컬 개발(Local development), 그리고 특히 프로덕션(Production) 등 어디에서나 발생할 수 있습니다. 개선 루프(Improvement loop)는 출처와 관계없이 동일하게 작동합니다.
- 이 루프를 위해서는 트레이스를 평가(Evals) 및 인간의 피드백(Human feedback)으로 풍부하게 만들고, 실패 패턴을 식별하며, 타겟팅된 변경을 수행하고, 배포 전 검증하는 과정이 필요합니다. 각 사이클은 더 나은 데이터와 더 신뢰할 수 있는 반복(Iteration)을 생성합니다.
- LangSmith는 첫 번째 트레이스부터 회귀(Regressions)가 배포되는 것을 방지하는 CI/CD 게이트에 이르기까지 이 루프의 모든 단계를 연결합니다.
에이전트 개선 루프는 원칙적으로 간단합니다: 트레이스를 확보하고, 이를 풍부하게 만들고, 이를 통해 개선하고, 반복하는 것입니다. 이 가이드는 이를 실제로 어떻게 수행하는지 안내합니다.
에이전트를 체계적으로 개선하려면 피드백 루프(Feedback loop)가 필요합니다. 에이전트 동작의 트레이스를 수집하고, 이를 평가 및 인간의 피드백으로 풍부하게 만들며, 무엇이 왜 실패하는지 식별하고, 타겟팅된 변경을 수행한 뒤, 배포하기 전에 해당 변경이 효과가 있었는지 검증합니다. 그런 다음 더 높은 기준점(Baseline)에서 이 과정을 반복합니다.
이 루프는 트레이스에 의해 구동됩니다. 이러한 트레이스는 스테이징 환경, 벤치마크 실행, 로컬 개발, 특히 프로덕션 등 다양한 곳에서 올 수 있습니다. 중요한 것은 이러한 트레이스를 수집하고, 풍부하게 만들며, 그 데이터를 사용하여 시스템을 개선하는 것입니다.
이 가이드는 해당 피드백 루프의 각 단계를 살펴봅니다.
트레이스는 원재료입니다
Harrison은 직설적으로 말했습니다: "소프트웨어에서는 코드가 앱을 문서화하지만, AI에서는 트레이스가 그 역할을 합니다."
전통적인 애플리케이션에서는 코드가 시스템이 무엇을 하는지에 대한 권위 있는 기록입니다. 코드를 읽고, 추론하고, 테스트하고, 원칙적으로 모든 동작을 이해할 수 있습니다.
에이전트 시스템(Agentic system)에서 코드는 에이전트가 무엇을 하도록 허용되었는지를 알려줍니다. 트레이스(Trace)는 이 실행(Run)에서, 이 입력(Input)을 가지고, 이러한 조건 하에서 에이전트가 실제로 무엇을 했는지를 알려줍니다.
트레이스는 에이전트 실행의 전체 과정을 포착합니다: 모든 LLM 호출(LLM call), 모든 도구 호출(Tool invocation), 모든 검색 단계(Retrieval step), 모든 중간 출력(Intermediate output), 그리고 이들을 연결하는 결정의 순서(Sequence of decisions)를 포함합니다. 이는 이 실행에서, 이 입력과 이러한 조건 하에 에이전트가 실제로 수행한 작업에 대한 기록입니다.
가공되지 않은 트레이스(Raw trace)는 무엇이 일어났는지를 알려줍니다. 평가자(Evaluator)에 의해 점수가 매겨지고 검토자(Reviewer)에 의해 주석이 달린 풍부한 트레이스(Enriched trace)는 그것에 대해 무엇을 해야 하는지를 알려줍니다. 이 루프의 나머지 과정은 그러한 풍부화 계층(Enrichment layer)을 구축하고, 이를 사용하여 타겟팅되고 검증된 개선을 수행하는 것에 관한 것입니다.
에이전트 개선 루프 (The agent improvement loop)
트레이스를 확보하고 나면, 에이전트를 개선하는 과정은 구체적이고 반복 가능해집니다. 루프는 다음과 같습니다:
1. 구축 및 개선 (Build and improve): 알고 있는 것부터 시작하십시오. 즉, 에이전트, 작업(Task), 그리고 무엇을 개선할 수 있을지에 대한 가설(Hypothesis)입니다. 개발자는 낮은 점수를 받은 트레이스를 검토하고, 실패 패턴(Failure patterns)을 필터링하며, 좋지 않은 결과를 초래한 궤적(Trajectory)을 조사합니다. 무엇을 고칠지 추측하는 대신, 관찰된 동작으로부터 역추적합니다. 실제 트레이스에서 나타나는 실패 모드(Failure modes)는 코드 및 프롬프트(Prompt) 변경을 위한 입력값이 됩니다.
2. 관찰 및 디버깅 (Observe and debug, 프로덕션 이전 단계): 개발자는 업데이트된 에이전트를 스테이징 환경(Staging environment)에서 실행합니다. 트레이스는 공식적인 평가(Formal evaluation)를 거치기 전에 수정 사항이 의도한 대로 작동하는지 여부를 드러냅니다.
3. 오프라인 평가 (Offline evals): 풍부한 트레이스는 재현 가능한 테스트 케이스(Test cases)로 변환됩니다. 반복되는 실패 모드는 평가자(Evaluator)가 됩니다. 문제를 드러냈던 실제 입력 세트는 데이터셋(Dataset)이 됩니다. 배포하기 전에 개발자는 업데이트된 에이전트에 대해 오프라인 평가 스위트(Offline eval suite)를 실행하여 구체적인 전후 비교(Before-and-after comparison)를 생성합니다. 수정 사항이 효과가 있다면 점수가 향상됩니다. 만약 회귀(Regression)를 유발한다면, 사용자에게 도달하기 전에 해당 문제가 드러납니다. 평가를 통과한 항목들은 영구적인 테스트 스위트(Test suite)에 추가됩니다.
4. 배포 (Deploy): 수정 사항이 배포되면 새로운 트레이스 (Trace)가 쌓이기 시작합니다. 다음 사이클은 더 높은 시작점에서 시작됩니다.
5. 관찰 (Observe, 프로덕션 환경에서): 프로덕션 환경의 모든 에이전트 실행은 입력값, 출력값, 궤적 (Trajectory), 도구 호출 (Tool calls), 토큰 사용량, 지연 시간 (Latency)을 포함하는 트레이스를 생성합니다. 이는 다음 사이클을 위한 원재료이자, 에이전트가 실제로 무엇을 수행했는지에 대한 진실의 원천 (Source of truth)입니다.
6. 온라인 평가 (Online evals) 및 인사이트 (Insights): 원시 트레이스는 추가적인 신호를 포함할 때 더욱 유용해집니다. 자동화된 평가기 (Automated evaluators)가 출력을 지속적으로 점수화합니다. 인사이트 (Insights) 보고서는 대량의 트레이스 전반에 걸쳐 사용 패턴, 실패 모드 (Failure modes), 엣지 케이스 (Edge cases)를 드러냅니다.
7. 주석 (Annotations): 인간 검토자가 선택된 트레이스에 등급, 수정 사항 및 코멘트를 주석으로 답니다. 각 풍부화 계층 (Enrichment layer)은 원시 행동 기록에 문맥을 추가하며, 다음 빌드 사이클로 피드백되는 레이블링된 데이터 (Labeled data)를 구축합니다.
각 사이클이 더 나은 데이터를 생성하기 때문에 이 루프는 복리로 성장합니다. 더 많은 트레이스는 더 많은 실패 모드의 사례를 의미합니다. 더 많은 사례는 더 정밀한 평가를 의미합니다. 더 정밀한 평가는 더 신뢰할 수 있는 반복 (Iteration)을 의미합니다.
LangSmith가 트레이스로부터 데이터를 자동으로 생성하는 방법
에이전트 개선을 주도하는 데이터에는 자동 생성 데이터와 인간 생성 데이터라는 두 가지 범주가 있습니다. LangSmith는 이 두 가지를 모두 생성할 수 있도록 돕습니다. 데이터를 자동으로 생성하려면 온라인 평가기 (Online evaluators)와 인사이트 에이전트 (Insights Agent)를 사용할 수 있습니다.
온라인 평가기 (Online evaluators)
온라인 평가기는 프로덕션 트레이스에서 자동으로 실행되며, 구성 가능한 품질 기준에 따라 출력을 점수화합니다. 모든 트레이스, 샘플링된 하위 집합, 또는 특정 기준에 따라 필터링된 하위 집합에서 실행되도록 구성할 수 있습니다.
채점 방법은 무엇을 평가하느냐에 따라 달라집니다.
결정론적인 정답 (Ground truth)이 없는 정성적 차원, 즉 유용성 (Helpfulness), 어조 (Tone), 관련성 (Relevance), 정책 준수 (Policy adherence), 사실적 타당성 (Factual plausibility)을 평가할 때는 LLM-as-a-judge를 사용하십시오. 평가기는 LLM을 호출하여 최종 응답뿐만 아니라 전체 궤적 (Trajectory)을 평가합니다. 즉, 에이전트가 올바른 도구를, 올바른 순서로, 올바른 파라미터와 함께 사용했는지를 확인합니다.
명확한 정답이 존재하는 동작의 경우, 코드 기반 검사 (code-based checks)를 사용하십시오. 스키마 검증 (Schema validation), 정확한 일치 조건 (exact-match conditions), 형식 준수 (format conformity), 비즈니스 규칙 준수 (business rule compliance), 그리고 도구의 정확성 (tool correctness)은 모두 결정론적 (deterministically)으로 평가할 수 있으며, 이를 수행하는 것이 LLM 판사 (LLM judge)를 통해 라우팅하는 것보다 더 빠르고 저렴합니다.
반복적인 인사이트 및 보고서
LangSmith의 Insights Agent는 프로덕션 트레이스 (production traces)에 대해 자동화된 클러스터링 (clustering)을 실행하여 사용 패턴, 실패 모드 (failure modes), 그리고 에지 케이스 (edge cases)를 드러냅니다. 이는 모니터링 (monitoring)과는 다릅니다. 이미 정의된 메트릭 (metrics)을 추적하는 것이 아니라, 찾으려 했던 줄도 몰랐던 패턴을 발견하는 것입니다.
고객 대상 에이전트를 관리하는 팀은 다음과 같이 질문할 수 있습니다: "사용자들이 실제로 이 에이전트로 무엇을 하려고 하는가?" Insights Agent는 수천 개의 트레이스를 분석하고, 의도 (intent)별로 그룹화하며, 아무도 예상하지 못했던 카테고리를 포함하여 상위 카테고리들을 제시할 수 있습니다. 부정적인 피드백이나 낮은 점수를 받은 트레이스에 동일한 분석을 적용하면, 에이전트가 지속적으로 부족한 부분이 어디인지, 그리고 그 이유가 무엇인지 밝혀낼 수 있습니다.
자동화가 멈추는 지점: 인간의 판단은 여전히 중요합니다
자동화된 평가기 (automated evaluators)와 인사이트는 확장성이 뛰어나지만, 인간의 판단을 대체하지는 못합니다.
일부 에이전트 동작은 도메인 전문 지식 (domain expertise)을 가진 사람만이 평가할 수 있습니다. 그럴듯하게 들리지만 부정확한 판례를 인용하는 법률 조사 에이전트는 LLM 판사 (LLM judge)를 속일 수 있습니다. 기술적으로는 정확하지만 임상적으로는 부적절한 안내를 제공하는 의료 정보 에이전트는 자동화된 검사에서는 정상적으로 보일 수 있습니다. 전문 분야에서의 미묘한 실패는 "정확함"이 실제로 무엇을 의미하는지 이해하는 검토자 (reviewers)를 필요로 합니다.
그 지점에서 어노테이션 큐 (annotation queues)가 등장합니다.
팀은 필터를 사용하여 선택된 프로덕션 트레이스를 어노테이션 큐로 라우팅할 수 있습니다: 자동화된 점수가 낮은 트레이스, 특정 기능 영역의 트레이스, 최종 사용자로부터 '싫어요(thumbs-down)' 피드백을 받은 트레이스 등이 해당됩니다. 검토자는 전체 컨텍스트 (context)를 확인하고 평점, 수정, 코멘트, 그리고 편집된 출력물을 남길 수 있습니다.
팀들이 실무에서 어노테이션 큐를 사용하는 네 가지 주요 방식은 다음과 같습니다:
온라인 평가자 (online evaluators) 정렬: 리뷰어는 LLM-as-a-judge (판단자로서의 LLM)를 교정하기 위해 트레이스 (Trace)에 라벨을 붙입니다. 리뷰어와 자동 평가자가 의견이 일치하지 않을 때, 라벨링된 예시들은 평가자의 점수가 인간의 판단을 반영할 때까지 채점기를 미세 조정 (tune)하는 데 도움이 됩니다.
오프라인 데이터셋 (offline datasets)을 위한 정답 (ground truth) 생성: 리뷰어는 트레이스에 대한 올바른 최종 출력물에 라벨을 붙입니다. 이는 오프라인 평가 (offline eval) 스위트의 기대 답변이 되어, 향후 버전이 실제 운영 입력값에 대해 정확한지 테스트할 수 있게 해줍니다.
개방형 출력물 (open-ended outputs) 점수 매기기: 단일 정답이 없는 경우, 리뷰어는 좋은 응답을 정의하는 기준에 라벨을 붙입니다. 이러한 구조화된 피드백은 정확히 일치하는지 확인하는 체크 (exact-match checks)를 하기에는 너무 미묘한 차원이 있는 평가 항목들에 대한 평가자의 기초가 됩니다.
자연어 어노테이션 (Natural language annotations): 리뷰어는 트레이스에 자유 형식의 코멘트와 수정 사항을 첨부합니다. 이는 Insights Agent 분석으로 흘러 들어가, 점수만으로는 나타나지 않는 패턴을 드러냅니다.
첫 번째 사용 사례와 나머지 사례를 구분할 가치가 있습니다. 온라인 평가자를 정렬하기 위한 어노테이션은 실시간 모니터링을 개선합니다. 즉, 지속적이고 자동화된 채점의 정확도를 높이는 것입니다. 나머지 세 가지는 주로 오프라인 데이터셋을 구축하는 것으로, 수정 사항을 배포하기 전에 테스트할 수 있게 해주는 정답 (ground truth) 및 품질 라벨을 생성하는 작업입니다.
실무에서는 두 가지 리뷰어 프로필이 흔히 나타납니다.
일반 리뷰어 (General reviewers): 계약직, 어노테이터 (annotators), 고객 성공 (customer success) 팀은 표면적인 품질 신호를 평가할 수 있습니다. 이들은 응답이 도움이 되었는지, 가시적인 정보와 비교했을 때 정확한지, 그리고 어조가 적절했는지를 판단합니다.
도메인 전문가 (Domain experts): 제품 관리자 (PM), SME (Subject Matter Experts), 그리고 에이전트가 서비스하는 분야의 전문가들은 자동화가 완전히 놓칠 수 있는 실패 사례를 포함하여, 에이전트가 문맥상 올바르게 행동했는지 판단할 수 있습니다.
종종, 현 시점에서는 여전히 인간 참여형 (human-in-the-loop) 방식이 필요합니다.
풍부해진 트레이스로 할 수 있는 것: 구축 및 개선
풍부해진 트레이스는 에이전트가 지속적으로 실패하는 지점을 이해하기 위한 원재료가 됩니다.
여러 트레이스(Trace)에 걸쳐 나타나는 패턴은 개별 사례보다 훨씬 더 실행 가능한(actionable) 정보를 제공합니다. 여러분은 에이전트가 특정 유형의 질의를 지속적으로 오해하거나, 특정 맥락에서 항상 잘못된 도구(Tool)를 선택한다는 사실을 발견하기 시작할 것입니다.
패턴 수준의 이해는 개별 실행 건을 수시로 점검하는 방식으로는 얻기 어렵습니다. 이는 실제 운영 환경의 동작으로부터 일관된 레이블(Label)이 달린 대규모 데이터가 필요합니다.
해결책은 트레이스가 무엇을 드러내느냐에 따라 달라집니다. 만약 에이전트가 특정 범주의 질의에 대해 잘못된 도구를 선택하고 있다면, 이는 도구 설명(Tool description)을 업데이트하거나 라우팅 로직(Routing logic)을 추가해야 함을 의미할 수 있습니다. 만약 다단계 작업(Multi-step task) 도중에 추론(Reasoning)이 어긋난다면, 더 제약적인 시스템 프롬프트(System prompt)를 사용하거나 작업을 더 작고 집중된 단계로 나누어야 합니다. 에이전트가 출력값은 사실적으로 정확하지만 사용자의 실제 의도를 놓치고 있다면, 이는 대개 프롬프트 수준의 문제이며 지침(Instruction)에서 무엇이 "좋은" 것인지 명확히 정의할 필요가 있습니다. 그리고 때로는 트레이스가 구조적인 문제를 드러내기도 합니다. 에이전트에게 완전히 다른 도구가 필요하거나, 특정 결정 지점에서 인간 참여형(Human-in-the-loop) 체크포인트가 필요한 경우입니다.
이러한 각각의 변경 사항은 가설적인 실패 모드(Failure modes)가 아니라, 관찰된 구체적인 동작을 바탕으로 결정됩니다. 개발자는 어떤 트레이스가 실패했는지, 어떻게 실패했는지, 그리고 주석이 달린 피드백(Annotated feedback)이 그 이유에 대해 무엇이라고 말하는지를 정확히 볼 수 있기 때문에 프롬프트를 다시 작성하는 것입니다.
그 후 오프라인 평가(Offline evaluations)를 통해 이러한 프롬프트 및 코드 변경 사항을 측정 가능한 수치로 만듭니다.
운영 환경의 실패를 오프라인 평가로 전환하기
무엇을 수정해야 할지 파악했다면, 그 수정 사항이 실제로 작동하는지 테스트할 방법이 필요합니다. 여기서 오프라인 평가가 등장합니다.
해당 평가를 위한 데이터셋은 실제 트레이스, 실제 질의, 실제 실패 사례와 같은 운영 환경(Production)에서 가져와야 합니다.
해당 평가가 실제로 무엇을 측정하는지는 주석 작업(Annotation work)이 무엇을 만들어냈느냐에 따라 달라집니다. 여기에는 두 가지 뚜렷한 접근 방식이 있습니다:
정답 정확도 (Ground truth correctness): 리뷰어가 트레이스(Trace)에 대해 올바른 최종 출력값을 라벨링(Labeling)한 경우, 정확도를 직접 테스트할 수 있습니다. 개선된 에이전트를 데이터셋에 실행하여 에이전트의 출력값을 라벨링된 정답(Ground truth)과 비교하십시오. 수정 사항이 효과가 있다면 점수가 향상됩니다. 만약 수정 사항이 회귀(Regression)를 일으킨다면, 평가(Eval) 단계에서 사용자가 이를 접하기 전에 잡아낼 수 있습니다. 기준 기반 점수 산정 (Criteria-based scoring): 모든 출력에 단 하나의 정답이 있는 것은 아닙니다. 개방형 작업(Open-ended tasks)의 경우, 리뷰어는 응답 자체보다는 좋은 응답을 정의하는 기준(Criteria)을 라벨링합니다. 오프라인 평가(Offline evals)는 이러한 기준을 사용하여 업데이트된 버전의 출력값에 점수를 매기며, 이를 통해 정확한 일치 없이도 관련성(Relevance), 완전성(Completeness), 또는 어조(Tone)와 같은 차원에서의 개선 사항을 측정할 수 있습니다.
평가(Eval)로 인코딩된 모든 실패 모드(Failure mode)는 테스트 스위트(Test suite)에 영구적으로 유지되어야 합니다. 이는 에이전트가 무엇을 처리하도록 학습했는지에 대한 지속적인 기록을 생성하며, 향후의 변경 사항이 이미 해결된 문제를 다시 발생시키지 않도록 보장하는 관문(Gate) 역할을 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 LangChain Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기