에이전트 관찰 가능성(observability)은 학습을 강화하는 피드백이 필요하다

대부분의 팀들은 에이전트 관찰 가능성을 디버깅 도구로 생각하기 시작합니다. 무언가 잘못되었기 때문에 트레이스(trace)를 열어 단계를 검사하고, 에이전트가 어디서 잘못된 결정을 내렸는지 알아냅니다.

그것은 유용하지만 너무 좁은 관점입니다.

에이전트 관찰 가능성의 더 깊은 역할은 학습을 강화하는 것입니다. 하지만 트레이스만으로는 그 순환 고리(loop)를 만들 수 없습니다. 에이전트의 행동이 유용한지, 받아들여졌는지, 거부되었는지, 비효율적인지, 위험한지 또는 잘못되었는지를 알려주는 피드백 신호도 필요합니다.

단순히 모델 훈련에서의 학습만을 의미하는 것이 아니라, 전체 에이전트 시스템 전반에 걸친 학습을 의미합니다. 즉, 모델이 무엇을 해야 하는지, 하네스(harness)가 어떻게 안내해야 하는지, 어떤 컨텍스트가 필요한지, 어떤 실패 모드가 반복되는지, 그리고 어떤 행동이 사용자에게 실제로 효과적인지를 아는 것입니다.

트레이스는 단순히 무슨 일이 일어났는지에 대한 기록일 뿐이며, 피드백은 마지막의 단순한 평가 점수가 아닙니다. 이 둘이 결합되어 시스템을 개선하기 위한 원재료가 됩니다.

학습은 여러 수준에서 발생한다

에이전트 시스템이 시간이 지남에 따라 '학습'하고 개선할 수 있는 몇 가지 방법들이 있습니다. 저희는 이 내용을 여기서 다루었습니다:

모델 수준에서 학습이 일어날 수 있습니다. 모델이 요청을 지속적으로 잘못 분류하거나, 잘못된 도구를 선택하거나, 정책을 따르지 못하는 사례를 발견할 수 있습니다. 이러한 트레이스는 SFT(Supervised Fine-Tuning) 또는 RL(Reinforcement Learning)을 통해 모델 가중치 자체를 업데이트하는 데 사용될 수 있습니다.

하네스 수준에서 학습이 일어날 수 있습니다. 하네스는 모델 주변의 모든 것을 의미합니다: 프롬프트, 도구 스키마, 권한 확인, 제어 흐름, 메모리 업데이트 로직, 라우팅, 재시도(retries), 그리고 가드레일(guardrails)입니다. 트레이스를 통해 에이전트가 올바른 모델 역량을 가지고 있었지만 잘못된 골조(scaffolding)를 사용했음을 보여줄 수 있습니다. 어쩌면 도구 설명이 모호했을 수도 있고, 에이전트가 읽기 전 쓰기(read-before-write) 제약 조건을 필요로 했을 수도 있으며, 시스템 프롬프트가 잘못된 트레이드오프를 만들었을 수도 있습니다.

학습은 컨텍스트 레벨에서도 일어날 수 있습니다. 에이전트는 주어진 정보(검색된 문서, 메모리, 사용자 선호도, 도구 결과, 이전 대화 턴, 환경 상태)에 극도로 민감합니다. 트레이스(trace)를 통해 모델이 잘못되거나 누락된 컨텍스트가 주어졌음에도 합리적인 결정을 내렸다는 것을 보여줄 수 있습니다. 이 경우, 학습 루프는 어떤 컨텍스트를 검색하고, 저장하고, 압축하거나 폐기해야 하는지를 개선해야 합니다. 이는 일반적으로 메모리(memory)라고 불립니다.

중요한 점은 이러한 모든 학습 루프가 트레이스에 의해 구동된다는 것입니다. 에이전트가 무엇을 보았고, 무엇을 했으며, 다음에 무슨 일이 일어났는지 모른다면, 무엇을 개선해야 하는지 신뢰성 있게 알 수 없습니다.

이것이 바로 에이전트 관찰 가능성(agent observability)이 에이전트 평가를 구동하는 이유입니다. 트레이스에서 에이전트의 행동이 가시화됩니다.

학습은 자동화되거나 수동으로 진행될 수 있다

어떤 학습은 수동으로 진행됩니다. 개발자가 트레이스를 보고 에이전트가 잘못된 도구를 호출했다는 것을 알아차리고, 프롬프트나 도구 스키마를 업데이트합니다. 제품 관리자(PM)가 실패한 대화 세트를 검토하고 제품에 새로운 워크플로우가 필요하다는 것을 깨닫습니다. 주석 작업자는 팀이 더 나은 평가 데이터셋을 구축할 수 있도록 트레이스에 레이블을 지정합니다.

이것 역시 학습입니다. 단지 인간이 루프 안에 있는 것뿐입니다.

다른 학습은 자동화됩니다. 시스템은 운영(production) 트레이스를 샘플링하고, 온라인 평가를 실행하며, 알려진 실패 패턴을 감지하고, 데이터셋에 예시를 추가하거나, 무언가 잘못된 것처럼 보일 때 검토 대기열을 트리거할 수 있습니다. 학습 루프가 자동화되기 위해 에이전트가 스스로 개선될 필요는 없습니다. 이 자동화 과정은 단순히 어떤 트레이스가 주의를 받을 자격이 있는지 식별하고 이를 구조화된 피드백으로 변환하는 것일 수 있습니다.

어느 쪽이든, 그 과정은 트레이스에 의해 구동됩니다.

트래픽 볼륨이 낮은 단일 에이전트의 경우, 수동 검토만으로 충분할 수 있습니다. 하지만 많은 에이전트나 높은 볼륨의 운영 트래픽의 경우, 이는 인프라 문제(infrastructure problem)가 됩니다. 트레이스를 캡처하고, 필터링하고, 점수를 매기고, 라우팅하며, 중요한 것을 보존해야 합니다.

트레이스는 필요하지만 충분하지 않다

트레이스는 무엇이 일어났는지 알려줄 뿐입니다. 그것 자체가 무엇이 좋았는지는 말해주지 않습니다.

그 구분이 중요합니다. 에이전트는 40단계 만에 작업을 완료할 수 있지만, 사실 같은 작업은 6단계가 걸렸어야 했을 수도 있습니다. 자신감 있는 최종 답변을 생성할 수 있지만, 사용자가 거부했을 수도 있습니다. 오류를 발생시키지 않을 수는 있지만, 여전히 사용자의 의도(intent)에는 실패할 수 있습니다. 올바른 도구(tool)를 호출할 수는 있지만, 인자(argument)가 미묘하게 잘못되었을 수도 있습니다.

트레이스로부터 학습하려면, 그 트레이스에 첨부된 피드백이 필요합니다.

피드백은 관찰 가능성(observability)을 수동적인 기록에서 훈련 신호(training signal), 디버깅 신호(debugging signal), 제품 신호(product signal), 또는 평가 신호(evaluation signal)로 전환시키는 것입니다. 피드백이 없으면, 여러분은 거대한 궤적(trajectories) 더미를 갖게 됩니다. 하지만 피드백이 있다면, 다음과 같은 유용한 질문을 시작할 수 있습니다:

• 어떤 트레이스가 성공을 나타냅니까?

• 어떤 트레이스가 실패를 나타냅니까?

• 어떤 실패가 모델(model), 하네스(harness), 또는 컨텍스트(context) 때문에 발생했습니까?

• 어떤 실패는 평가(evals)로 전환할 가치가 있습니까?

• 어떤 행동이 시간이 지남에 따라 개선되고 있습니까?

이것이 핵심 요구 사항입니다: 에이전트 관찰 가능성 데이터와 함께 피드백을 저장해야 합니다.

피드백은 여러 곳에서 올 수 있다

피드백이 반드시 사람이 모든 트레이스를 수동으로 채점한다는 것을 의미할 필요는 없습니다. 실제로는 유용한 피드백이 몇 가지 형태로 존재합니다.

가장 명확한 것은 직접적인 사용자 피드백입니다: 엄지손가락 위로, 엄지손가락 아래로, 별점 평가, 또는 서면 수정 사항. 이 신호는 이해하기 쉽지만, 보통 희소합니다. 대부분의 사용자는 명시적인 피드백을 남기지 않습니다.

다음은 간접적인 사용자 피드백입니다. 코딩 에이전트의 경우, 이는 수락된 코드 줄(lines of code), 되돌려진 diff, 수정 후 통과한 테스트, 또는 사용자가 생성된 변경 사항을 유지했는지 여부가 될 수 있습니다. 지원 에이전트의 경우, 사용자가 티켓을 다시 열었는지 여부일 수 있습니다. 연구 에이전트의 경우, 사용자가 답변을 복사했는지 아니면 같은 질문을 다시 했는지가 될 수 있습니다. 이러한 신호는 명시적 평점보다 노이즈가 많지만, 종종 훨씬 더 풍부합니다.

LLM을 심사위원(judge)으로 활용하여 피드백을 생성할 수도 있습니다. 심사위원은 답변이 도움이 되었는지, 에이전트가 정책을 따랐는지, 또는 궤적(trajectory)이 의심스러운지 점수를 매길 수 있습니다. 이는 대규모로 실행할 수 있다는 점에서 유용하며, 특히 프로덕션 트레이스에 대한 온라인 평가자로서 그렇습니다. 완벽하지는 않으며 보정(calibrate)되어야 하지만, 사람이 검토하기에는 너무 느린 경우에도 팀이 구조화된 피드백을 생성하는 방법을 제공합니다.

마지막으로, 피드백은 결정론적(deterministic)일 수 있습니다. 규칙(rules)과 정규 표현식(regexes)은 저평가되어 있습니다. 실패 패턴을 알고 있다면 이를 인코딩하세요. 에이전트가 승인 없이 파괴적인 명령을 호출해서는 안 된다면, 이를 확인하세요. 응답에 인용(citation)이 포함되어야 한다면, 이를 검증하세요. 코딩 에이전트가 사용자의 좌절 징후를 보이면, 이를 감지하세요.

Claude Code의 유출 사례가 이를 구체화했습니다. 여러 보고서에 따르면 Claude Code는 userPromptKeywords.ts에서 정규 표현식을 사용하여 사용자 프롬프트에서 좌절 단어와 구문을 탐지했습니다. PCWorld는 이 정규식이 “wtf,” “horrible,” “awful,” 및 “this sucks”와 같은 용어를 찾았다고 보도했습니다. Slashdot의 요약은 동일한 패턴을 포함하며, Blake Crosley의 분석은 이를 LLM 추론(inference)보다는 정규식 기반 좌절 감지라고 설명합니다.

엔지니어링 관점에서 볼 때, 이 패턴은 교훈적입니다. 모든 피드백 신호가 모델 호출을 필요로 하는 것은 아닙니다. 저렴한 규칙이 유용한 신호를 포착한다면, 그 저렴한 규칙을 사용하세요. 그리고 해당 신호가 어떻게 저장되고 사용되는지에 대해 명확하게 하세요.

관측 가능성 플랫폼에 필요한 것들

관측 가능성(observability)이 학습을 구동하려면, 플랫폼은 세 가지가 필요합니다.

첫째, 트레이스를 저장해야 합니다. 이것이 기본 계층입니다. 에이전트가 수행한 모든 것의 전체 궤적(trajectory)이 필요합니다: 모델 호출, 도구 호출, 입력, 출력, 메타데이터, 타이밍, 오류 및 중간 상태를 포함합니다. 이상적으로는 사용하는 스택에 관계없이 트레이스를 수집할 수 있어야 하며, 단지 하나의 프레임워크에서만 국한되어서는 안 됩니다. LangSmith는 30개 이상의 다양한 프레임워크에서 추적을 지원하며, OpenTelemetry 추적을 통해 OpenTelemetry와 호환되는 애플리케이션의 트레이스도 수집할 수 있습니다.

둘째, 피드백을 저장해야 합니다. 피드백은 트레이스와 분리된 별도의 스프레드시트나 분석 시스템에 존재해서는 안 됩니다. 이는 평가하는 실행(run), 트레이스(trace) 또는 스레드(thread)에 직접 첨부되어야 합니다. 이렇게 하면 피드백별로 필터링하고, 좋았던 궤적과 나빴던 궤적을 비교하며, 실제 실패로부터 데이터셋을 구축하고, 중요한 행동이 개선되는지 추적할 수 있습니다. LangSmith는 피드백을 포착하고 이를 트레이스에 연결하는 기능을 지원합니다.

셋째, 피드백을 생성해야 합니다. 일부 피드백은 사용자로부터 오겠지만, 많은 유용한 피드백은 시스템 자체에서 생성되어야 합니다. 여기에는 규칙(rules), 평가기(evaluators), 샘플링(sampling), 주석 큐(annotation queues), 경고(alerts), 그리고 과거 트레이스에 대한 백필(backfills)이 포함됩니다. LangSmith는 프로덕션 트레이스로 실행되는 LLM-as-judge 평가기를 포함하여 자동화 규칙과 온라인 평가를 지원합니다.

에이전트 팀에게 필요한 제품 형태는 다음과 같습니다: 트레이스를 저장하고, 피드백을 저장하며, 피드백을 생성하는 것입니다.

학습 루프는 트레이스와 피드백에 달려 있습니다

관찰 가능성(observability)의 목적은 단순히 트레이스를 보는 것이 아닙니다. 그 목적은 그것으로부터 배우는 것입니다.

트레이스는 무슨 일이 일어났는지 알려줍니다. 피드백은 그것이 무엇을 의미했는지 알려줍니다. 이 둘이 결합되어 모델, 하네스(harness), 그리고 컨텍스트를 개선할 수 있게 합니다. 이는 수동 디버깅과 자동화된 평가를 지원합니다. 프로덕션 동작을 데이터셋, 규칙, 경고, 그리고 회귀 테스트로 변환시킵니다.

피드백이 없는 에이전트 관찰 가능성은 불완전합니다. 행동을 검사할 수는 있지만, 그것으로부터 체계적으로 배울 수는 없습니다.

에이전트 관찰 가능성을 최대한 활용하려면, 트레이스와 함께 피드백을 저장해야 합니다. 이것이야말로 에이전트 트레이스를 로그에서 학습 시스템으로 변화시키는 것입니다.