에이전트 훈련 방법: 프로덕션 팀들이 사용하는 7가지 패턴

프로덕션 환경에서 에이전트를 훈련하는 과정은 일곱 가지 패턴으로 이루어집니다. 모든 트레이스를 측정하고, 실제 트래픽으로부터 평가(evals)를 구축하며, 해당 트레이스들을 데이터셋으로 라벨링하고, 프롬프트 엔지니어링에는 한계가 있다는 것을 받아들이고, LoRA 파인튜닝을 실행한 다음, 평가 세트를 고정하고 훈련을 반복하는 것입니다. 노력의 대부분은 에이전트 자체가 아니라 인프라에 들어갑니다.

원문 출판: overmindlab.ai.

프로덕션에서 에이전트를 구축, 배포 및 개선하며 얻은 교훈.

만약 프로덕션 환경에서 LLM 기반의 에이전트를 운영하고 있다면, 아래 제시된 일곱 가지 패턴들이 반복적으로 나타납니다.

에이전트 훈련을 위한 7가지 패턴이란 무엇인가요?

| # | 패턴 | 수행할 작업 | 전술적 조언 |
| :--- | :--- | :--- |
| 1 | 모든 에이전트 트레이스 측정 (Instrument every agent trace) | 모든 에이전트 실행을 OpenTelemetry와 호환되는 트레이싱 도구로 라우팅합니다. | 트레이스는 최소 30일 동안 보관하세요. 사용자 ID, 사용 사례 및 에이전트 버전으로 태그를 지정하세요 |
| ... |
Overmind는 AI 팀을 위한 모델 훈련 플랫폼입니다. 프로덕션 트레이스를 소유하는 특화된 모델로 자동 훈련, 벤치마킹 및 서비스합니다. 아래 패턴들은 직접 구축하든 그렇지 않든 동일한 루프입니다.

에이전트 트레이스를 어떻게 측정(instrument)하나요?

에이전트 실행 하나하나가 하나의 트레이스(trace)를 생성합니다. 이 트레이스는 입력, 도구 호출(tool calls), 검색된 컨텍스트(retrieved context), 중간 추론 과정(intermediate reasoning), 최종 출력을 포함하는 전체 시퀀스를 의미합니다. 이러한 기록이 없다면, 흩어져 있는 로그 파일에서 에이전트의 행동을 재구성해야 하는데, 이는 매우 고통스러운 작업입니다.

OpenTelemetry는 이 분야의 기본 표준이 되었습니다. OpenTelemetry의 GenAI 시맨틱 컨벤션은 모델 이름, 토큰 사용량, 도구 호출 등을 포함하여 실행의 각 단계가 기록하는 공유된 형식을 설정합니다. 따라서 LangChain 에이전트의 트레이스는 원시 API 호출(raw API call)에서 나온 트레이스와 동일한 형태를 띱니다. Langfuse, Arize Phoenix, Datadog LLM Observability, LangSmith를 포함하여 대부분의 관측 가능성 플랫폼(observability platforms)들이 이 형식을 기본적으로 지원합니다.

실용적인 조언: OpenTelemetry와 호환되는 추적(tracing) 도구 하나를 선택하세요. 모든 에이전트 실행을 이 도구를 통해 라우팅하세요. 최소 30일 동안 추적 기록을 보관하세요. 나중에 추적 코드를 수정하기 위해 돌아갈 필요 없이, 사용자 ID, 사용 사례, 에이전트 버전을 태그로 지정하세요.

실제 프로덕션 트래픽으로 평가(evals)를 구축하는 방법은 무엇인가요?

에이전트를 배포하기 전에 몇 가지 평가를 통해 실행해 보세요. 평가는 에이전트가 작업을 수행했는지 점수를 매기는 확인 과정입니다. 하지만 실제 트래픽이 도착하면 엣지 케이스(edge cases)도 함께 옵니다.

프로덕션 추적 기록은 실제 평가 소스가 될 수 있습니다. 주간 단위로 샘플 추적 기록을 가져와 실패 사례를 새로운 테스트 케이스로 만드세요. 오래된 평가 세트는 진실의 원천이라기보다는, 이전 수정 사항이 여전히 유효한지 확인하는 회귀(regression) 검사로 사용될 수 있습니다. Langfuse, Braintrust, Arize, 그리고 LangSmith는 모두 이 워크플로우를 직접 지원하며, 샘플링된 프로덕션 데이터를 구조화된 평가 세트로 변환합니다.

실용적인 조언: 프로덕션에 투입된 지 2주가 될 때쯤에는, 주된 평가 세트가 출시 전에 작성한 합성(synthetic) 데이터가 아닌 실제 추적 기록으로 구축되어야 합니다.

추적 기록을 레이블이 지정된 데이터셋으로 변환하는 방법은 무엇인가요?

추적 기록은 발생한 일만 기록합니다. 이를 훈련하거나 평가하기 전에, 해당 실행이 얼마나 좋았는지 알아야 합니다. 그 판단이 바로 레이블(label)이며, 레이블이 사실상 데이터셋을 구성하는 요소입니다. 더 많은 비레이블 추적 기록이 그것을 더 좋게 만들지는 못하므로, 더 많이 수집하기 전에 가지고 있는 것을 레이블 지정하세요.

에이전트의 코드베이스부터 시작하세요. 이미 에이전트가 무엇을 하도록 의도되었는지 명시하고 있으므로, 이를 통과 또는 실패 기준 목록으로 만드세요. 추적 기록을 이 체크리스트와 비교하여 점수를 매기고, 실패한 각각의 항목에 메모를 작성하세요. 하멜 후사인(Hamel Husain)은 이것을 오류 분석(error analysis)이라고 부릅니다. 이러한 메모들을 실패 분류 체계(failure taxonomy), 즉 시간이 지남에 따라 계산하고 추적할 수 있는 실패 유형의 고정된 목록으로 그룹화하세요.

트레이스(trace)마다 레이블과 실패 유형이 부여되면, 데이터셋이 생깁니다. 이것이 바로 파인튜닝(fine-tune)에 사용되는 것이며, 이후의 모든 변경 사항을 평가하는 기준이 됩니다. 전체 파이프라인은 트레이스를 훈련 데이터셋으로 변환하는 방법에서 확인해 보세요.

실용적 조언: 코드에서 5개에서 20개의 통과/실패 기준을 먼저 작성한 다음, 레이블링을 하면서 이를 다듬으세요. 첫 달 동안은 매주 몇 시간을 할애하여 직접 레이블링하는 데 사용하세요. 첫 번째 작업은 외부에 맡기지 마세요. 무엇이 '좋은' 상태인지에 대한 당신의 판단력은 트레이스를 스스로 분석해 봐야만 비로소 드러납니다.

언제 프롬프트 엔지니어링을 멈춰야 할까요?

프롬프트 엔지니어링에는 한계가 있습니다. 프롬프트 반복 작업은 저렴하고 빠르기 때문에, 평가 점수를 계속 개선하는 동안에는 최대한 활용하세요. 결국 새로운 지침 하나하나가 어제의 버그를 수정하는 동시에 조용히 새로운 버그를 도입합니다. 시스템 프롬프트는 부풀어 오르고(bloats), 레이턴시(latency)는 높아지며, 모델은 아예 일부 내용을 무시하기 시작합니다.

이 시점에서는 더 많은 미세 조정(tweaking)을 할지 아니면 완전히 다른 레버리지(lever)를 선택할지 결정해야 합니다. 대부분의 팀은 프롬프트 수정이 자유롭게 느껴지기 때문에 필요 이상으로 한 달 더 계속 미세 조정을 합니다. 하지만 그렇지 않습니다. 엔지니어링 시간은 전체 파이프라인에서 가장 비용이 많이 드는 항목입니다. 트레이드오프(trade-off)에 대한 자세한 내용은 프롬프트 엔지니어링 대 파인튜닝에서 확인해 보세요.

실용적 조언: 프롬프트 변경 전후의 평가 점수를 추적하세요. 먼저 변경되지 않은 프롬프트를 두 번 실행하여, 점수가 자체적으로 얼마나 흔들리는지 확인하세요. 그보다 작은 변화는 무시하세요.

파인튜닝을 위해 연구팀이 필요할까요?

오픈 웨이트 모델을 파인튜닝(Fine-tuning)한다는 것은 연구팀과 막대한 GPU 예산을 필요로 하는 것을 의미했습니다. LoRA는 기본 모델(base model)을 동결하고 대신 작은 저랭크 어댑터 행렬(low-rank adapter matrices) 세트를 훈련합니다. 이 어댑터들은 전체 매개변수(parameters)의 1% 미만인 경우가 많습니다. 이것이 바로 QLoRA의 4비트 양자화(quantisation)를 사용하여 단일 고메모리 GPU에서 70B 모델을 파인튜닝할 수 있는 이유입니다. 양자화는 가중치(weights)를 더 낮은 정밀도로 저장하므로, 모델이 차지하는 메모리가 줄어듭니다.

레이블링된 트래젝토리(labelled trajectories), 즉 이미 점수를 매긴 기록된 에이전트 실행을 사용하여 오픈 웨이트 기반 모델을 선택하고 LoRA 과정을 수행하세요. 그런 다음 Fireworks, Together 또는 Modal에서 그 결과를 제공합니다. Unsloth, OpenPipe, Predibase가 파이프라인의 대부분을 처리해 줍니다. 방법론 선택은 별개의 질문이며, 파인튜닝의 다양한 유형에서 다루고 있습니다.

전술적 조언: 레이블링된 트래젝토리가 1,000개 이상이고 작업이 좁은(narrow task) 경우, LoRA 파인튜닝을 수행하세요. 동일한 평가 세트(eval set)에서 프롬프트 엔지니어링 기반 모델과 비교해 보세요.

왜 훈련하기 전에 평가 세트를 동결해야 할까요?

파인튜닝의 점수를 매기는 데 사용되는 평가 세트는 기본 모델에 점수를 매길 때 사용했던 것과 동일해야 하며, 훈련이 시작되기 전에 잠겨 있어야 합니다. 기준(criteria)을 변경하고 훈련을 같은 주에 진행하면 어떤 것이 수치를 변화시켰는지 알 수 없습니다.

모델은 에이전트 하네스(agent harness) 내부에서 테스트되어야 하며, 단독으로 테스트되어서는 안 됩니다. 고립된 상태에서 더 높은 점수를 받은 모델이라도, 에이전트는 도구 호출 형식(tool call formats), 출력 구조(output structure), 지침 준수(instruction following)에 의존하기 때문에 벤치마크 점수가 포착하지 못하는 문제가 발생할 수 있습니다.

전술적 조언: 모든 모델 변경은 매번 동일하게 동결된 평가 세트를 대상으로 진행되어야 합니다. 모델은 온갖 이유로 성능이 저하될 수 있으며, 고정된 스코어보드가 유일한 확인 방법입니다.

자기 개선 루프

첫 번째 전체 순환(capture, label, train, deploy, measure)을 거치는 데는 몇 주가 걸립니다. 다섯 번째 순환에 이르면 대부분의 마찰이 사라지고 루프가 몇 시간 만에 돌아갑니다.

이러한 복리 효과가 핵심입니다. 한 분기에 이 루프를 다섯 번 실행하는 팀은 최첨단 API 비용의 일부만으로 비즈니스 요구 사항과 일치하는 에이전트를 갖게 됩니다. 단지 한 번 실행하고 끝냈다고 생각하는 팀은 6개월 전과 비슷한 수준에 머물러 있습니다.

이것이 본질적으로 Overmind의 제품 가설입니다. 이는 사용자의 저장소(repository)와 추적 기록(traces)을 연결한 다음, 최적화기(optimiser)를 통해 변경 사항을 제안합니다. 이 변경 사항들을 레이블링된 데이터에 대해 테스트하고 실제로 점수를 올리는 것만 표면화합니다. 증거에서 배포된 개선으로 이어지는 루프가 자체적인 6주짜리 프로젝트가 되는 대신 짧게 유지됩니다.

실질적 조언: 주기(cadence)를 정해서 달력에 기록하세요. 매주가 공격적이지만 가능하며, 월별이 최소 기준입니다. 그보다 느리면 진정한 루프를 돌리는 것이 아니라 간헐적인 정리 작업만 하는 것입니다.

인프라가 에이전트보다 더 많은 작업을 요구한다

이 7가지 단계 중 어느 하나라도 그 자체로 실제 업무입니다. 이들이 연결되면 여러 개의 업무가 됩니다. 대부분의 팀은 주변 인프라 구축에 들어가는 시간이 에이전트를 만드는 시간보다 더 많이 든다는 것을 발견합니다.

여기에 위 게시물에서 언급된 모든 도구들을 기능별로 그룹화했습니다.

프로토타입 단계를 넘어 루프를 처음부터 구축하지 않고도 실행하고 싶다면, 살펴보는 가치가 있습니다.

FAQ

에이전트를 미세 조정하는 데 필요한 레이블링된 예제는 얼마나 되나요?

1,000개 이상의 레이블링된 트래젝토리와 좁은 태스크가 있다면, LoRA 미세 조정(fine-tune)을 실행할 가치가 있습니다. 그보다 적다면, 계속해서 레이블링하고 프롬프트를 반복적으로 개선하세요.

GPU 클러스터 없이 70B 모델을 미세 조정할 수 있나요?

네. LoRA는 전체 파라미터의 1% 미만인 작은 어댑터 행렬 세트만을 학습하며, QLoRA의 4비트 양자화(quantisation)는 고정된 기본 모델을 더욱 축소합니다. 따라서 70B 모델의 미세 조정은 단일 고메모리 GPU에서 가능합니다.

미세 조정된 모델을 독립적으로 테스트해야 하나요, 아니면 에이전트 내부에서 테스트해야 하나요?

에이전트 하네스(agent harness) 내부에서 해야 합니다. 격리 상태에서 점수가 더 높은 모델이라도, 에이전트는 벤치마크 점수가 포착하지 못하는 도구 호출 형식(tool call formats), 출력 구조(output structure), 그리고 지침 준수(instruction following)에 의존하기 때문에 에이전트를 오히려 악화시킬 수 있습니다.

얼마나 자주 학습 루프를 실행해야 하나요?

매주가 공격적이지만 가능하고, 매월이 최소한의 빈도입니다. 그보다 느리면 주기적인 정리 작업(cleanup)을 하는 것이지 루프를 돌리는 것이 아니므로, 복리 효과(compounding)가 발생하지 않습니다.

Overmind는 AI 팀을 위한 모델 학습 플랫폼입니다. 프로덕션 트레이스(production traces)를 여러분이 소유하는 특화된 모델로 변환해 줍니다. 시작하기.