coSTAR: Databricks에서 AI 에이전트를 문제없이 빠르게 배포하는 방법

코딩 도우미가 테스트 스위트 없이 코드베이스를 리팩터링하도록 두는 사람은 없을 것입니다. 테스트 없이는 도우미는 눈먼 상태로 작동합니다. 하나의 함수를 수정하고 다른 세 개를 조용히 망가뜨릴 수도 있습니다. 테스트는 루프를 닫는 역할을 합니다. 테스트를 실행하고, 실패를 관찰하고, 코드를 수정하고, 다시 실행합니다. 테스트가 없으면 확신도 없습니다.

Databricks에서는 Databricks 플랫폼의 새로운 기능(예: Genie Code의 데이터 엔지니어링, 추적 분석 및 머신러닝 기능)부터 OSS 프로젝트(예: MLflow 도우미) 및 내부 엔지니어링 워크플로(예: 온콜 지원 또는 자동 코드 검토자)에 이르기까지 광범위한 기능을 포괄하는 에이전트를 지속적으로 개발하고 배포합니다. 이러한 에이전트는 장기 실행 작업을 수행하고, 수천 줄의 코드를 생성하며, 다른 것들 중에서도 새로운 데이터 및 AI 자산을 만들 수 있습니다. 초기에는 몇 가지 기본적인 검사가 있었지만, 확신을 가지고 반복할 수 있게 해주는 포괄적인 자동화된 테스트 스위트가 부족했습니다. 이 게시물에서는 MLflow와 이를 중심으로 구축한 모범 사례인 coSTAR(결합된 시나리오, 추적, 평가, 개선) 방법론을 사용하여 이 격차를 어떻게 해소했는지 설명합니다. coSTAR는 두 개의 결합된 루프를 실행합니다. 하나는 심사위원을 인간 전문가의 판단과 일치시켜 신뢰할 수 있도록 하고, 다른 하나는 신뢰할 수 있는 심사위원을 사용하여 에이전트가 모든 테스트 시나리오를 통과할 때까지 자동으로 개선합니다.

그림: coSTAR 프레임워크는 두 개의 미러링된 STAR 루프(Scenario → Trace → Assess → Refine)를 실행합니다. 에이전트 루프(파란색)는 심사위원을 사용하여 추적을 자동 채점하고 심사위원과 일치하도록 에이전트를 개선합니다. 심사위원 루프(주황색)는 인간 전문가를 사용하여 추적을 채점하고 그들의 평가와 일치하도록 심사위원을 개선합니다. 두 루프 모두 동일한 시나리오와 추적을 공유합니다.

문제: 테스트 없는 코딩

초기 개발 루프는 다음과 같았습니다. 에이전트를 실행하고, 수동으로 출력을 검토하고, 결함을 발견하고, 코딩 도우미에게 수정하도록 지시합니다. 반복합니다.

이것이 테스트 없이 코드를 작성하고 모든 변경 사항을 수동으로 QA하는 것과 비슷하게 들린다면, 그것은 정확히 그것이었습니다. 그리고 예상했던 대로 실패했습니다. 명백한 반응은 "테스트를 작성하라"는 것입니다. 그러나 에이전트 테스트는 결정론적 함수를 테스트하는 것과 구조적으로 다르며, 여러 가지 문제가 동시에 복합됩니다.

• 비결정성. 동일한 구현, 동일한 입력이 다른 실행에서 다른 출력을 생성할 수 있습니다. 테스트는 정확한 출력을 주장하는 대신 출력의 속성을 평가해야 합니다.
• 느린 피드백 루프. 단일 에이전트 실행은 수십 분이 걸릴 수 있습니다. 1초 미만의 테스트 스위트가 허용하는 방식으로는 반복할 수 없습니다. 모든 평가 주기는 비용이 많이 듭니다.
• 연쇄 오류. 3단계에서의 잘못된 결정은 7단계에서의 실패를 유발합니다. 증상이 나타날 때쯤이면 근본 원인은 에이전트 실행의 몇 단계 뒤에 묻혀 있습니다.
• 주관적인 품질. 많은 테스트 차원(이 기능 엔지니어링 코드가 좋은가? 이 데이터 정리 접근 방식이 적절한가?)에 대해서는 정답이 없습니다. 이러한 차원을 판단하는 것은 도메인 전문 지식에 달려 있습니다.

이러한 제약 조건은 이후의 모든 설계 결정에 영향을 미쳤습니다. 또한 이 문제를 흥미롭게 만드는 이유이기도 합니다. 우리는 단순히 테스트 실행기를 구축하는 것이 아니라, "정확한" 것이 판단의 문제인 확률적이고 장기 실행되며 다단계 프로세스를 위한 자동화된 최적화 방법론을 구축하고 있습니다.

접근 방식을 안내하는 비유

잘 보면 에이전트 개발은 모든 엔지니어가 이미 알고 있는 개발 루프에 깔끔하게 매핑됩니다.

이 비유는 단순히 설명적인 것이 아닙니다. coSTAR라고 부르는 시스템의 실제 아키텍처입니다. coupled 루프 두 개가 Scenario 정의를 테스트 픽스처로 사용하고, Trace 캡처를 테스트 하네스로 사용하며, 심사위원으로 Assess하고, Refine를 빨강-초록 루프로 사용합니다. 각 부분을 살펴보겠습니다.

S - 시나리오 정의

전통적인 테스트에서 테스트 픽스처는 사전 조건을 설정합니다. 데이터베이스를 생성하고, 데이터를 채우고, 환경을 구성합니다. 이에 상응하는 것은 시나리오 정의입니다. 초기 상태, 사용자 프롬프트 및 예상 결과에 대한 구조화된 설명입니다.

다음은 지저분한 데이터셋에 대해 데이터 분석가 에이전트를 테스트하기 위한 단순화된 시나리오입니다.

각 시나리오는 테스트 픽스처와 마찬가지로 설정, 입력 및 성공 기준을 한 곳에 묶습니다. 다양한 에이전트에 걸쳐 이러한 시나리오 모음을 유지 관리하며, 일반적인 경우, 엣지 케이스 및 알려진 과거 실패를 다룹니다. 새로운 실패 모드를 발견함에 따라 모음은 시간이 지남에 따라 성장합니다. 프로덕션에서 발견하는 모든 버그는 프로덕션 버그가 회귀 테스트가 되어야 하는 것과 마찬가지로 새로운 시나리오가 됩니다.

이 구조를 왜 사용해야 할까요? 에이전트 실행은 비용이 많이 들기 때문입니다. 단일 시나리오는 실행하는 데 몇 분이 걸립니다. 무엇을 테스트할지 신중해야 하며, 시나리오 정의는 이식 가능해야 합니다. 즉, 동일한 시나리오를 다른 에이전트 구현 또는 동일한 에이전트의 다른 버전에 대해 실행할 수 있습니다.

T - 추적 캡처

테스트 스위트를 실행하기 위해 각 시나리오의 프롬프트를 테스트 중인 에이전트(AUT)에 보내는 하네스를 사용합니다. 각 실행은 MLflow 추적으로 캡처됩니다. 모든 도구 호출, 모든 중간 출력 및 에이전트가 생성하는 모든 아티팩트에 대한 구조화된 로그입니다. 비행 기록기라고 생각하면 됩니다. 에이전트가 수행한 모든 것을 순서대로 캡처하므로 나중에 실행의 모든 부분을 검사할 수 있습니다.

핵심 아키텍처 결정: 실행과 채점을 분리합니다. 테스트 하네스는 추적을 생성하고, 심사위원(다음 소개할 내용)은 이를 채점합니다. 이들은 별도의 단계입니다. 추적을 영구 저장함으로써 시나리오를 다시 실행하지 않고도 심사위원에 대해 반복할 수 있습니다. 임계값을 조정하시겠습니까? 기록된 추적을 몇 초 만에 다시 채점합니다. 새 심사위원을 추가하시겠습니까? 수집한 모든 추적에 대해 실행합니다. 심사위원이 잘못되었다고 의심되십니까? 녹음과 비교하여 평가하고 오프라인으로 디버그합니다. 비용이 많이 드는 단일 에이전트 실행은 나중에 심사위원을 일치시키는 데 사용할 골든 세트의 후보를 포함하여 여러 번 재사용되는 데이터를 생성합니다.

A - 심사위원으로 평가

심사위원은 추적을 기반으로 작동하며 실행의 속성에 대해 추론합니다. 에이전트가 유효한 코드를 생성했습니까? 출력이 품질 임계값을 충족했습니까? 에이전트가 올바른 프로세스를 따랐습니까? 앞서 언급했듯이 이 평가는 전통적인 단위 테스트와 다릅니다. 에이전트 출력은 비결정적이고 풍부하므로 정확한 출력을 주장하는 것은 본질적으로 쓸모가 없습니다.

이러한 심사위원을 구현하는 표준 접근 방식은 "LLM-as-a-Judge"입니다. 전체 추적을 모델에 공급하고 점수와 중요하게는 해당 점수에 대한 근거를 요청합니다. 그러나 이것은 전체 프로그램 상태를 단언문에 덤프하는 테스트를 작성하는 것과 같습니다. 비용이 많이 들고, 취약하며, 디버깅하기 어렵습니다. 에이전트의 경우 단일 추적은 수천 줄이 될 수 있습니다. 이를 심사위원의 컨텍스트 창에 넣으면 판단 품질이 저하됩니다.

대신, MLflow의 에이전트형 심사위원을 사용합니다. 즉, 추적을 선택적으로 탐색하는 도구가 장착된 에이전트 자체인 심사위원입니다. 잘 작성된 테스트가 특정 함수를 호출하고 특정 반환 값을 확인하는 것처럼, 에이전트형 심사위원은 추적에서 특정 도구를 호출하고 특정 속성을 확인합니다.

다음은 에이전트 전반에 걸쳐 사용한 몇 가지 예제 심사위원입니다.

스킬 호출 심사위원은 추적을 탐색하고 시나리오의 대상인 스킬을 에이전트가 호출했는지 확인합니다(그렇지 않으면 스킬의 목적이 AUT에 명확하지 않음).

모범 사례 심사위원은 Databricks 공식 문서에 따라 출력이 모범 사례를 따르는지 여부를 탐색합니다.

Outcome Judge inspects the trace for output assets and asserts certain properties. Going back to the Data Analyst example, identify the part of the trace where engineering code was authored and evaluate whether the code is appropriate for the task at hand:

This judge is interesting because it tackles the subjective quality problem head-on: what counts as good feature engineering depends on domain expertise. An LLM judge can't get this right out of the box. It's tempting to try writing out the complete criteria in the judge's prompt: "prefer median imputation over mean for skewed distributions, always scale features before distance-based models, ..." But encoding a domain expert's full judgment into a prompt is laborious and brittle. It's much easier for humans to look at an example and say "this is good" or "this is bad" than to write out the complete spec. This is exactly why alignment works, as we'll cover shortly.

In general, our test suite for a single agent includes judges across several categories:

Deterministic checks, things we can verify mechanically, no LLM needed:

• Syntax/linting on generated code
• Output schema validation (do expected tables exist? are column types correct?)
• Tool sequence linting (did the agent read the error logs before trying to fix the issue, or did it skip straight to editing code?)

LLM-based checks, judgment calls that require understanding context:

• Code diff guidelines (did the agent change unrelated lines? did it introduce deprecated APIs?)
• Best practice adherence (is the generated code following the conventions for this domain?)

Operational metrics, signals that don't pass/fail individually but track health over time:

• Token usage (high token counts often signal the agent is struggling, retrying, backtracking, or going in circles)
• Tool call counts and failure ratios (a spike in failed tool calls indicates something is wrong)
• Latency (wall-clock time for the agent to complete the task)

The operational metrics deserve a note. They don't gate a release the way pass/fail judges do, but they're critical for cost management and early warning. If token usage doubles after a change, something went wrong even if all judges still pass; the agent is probably doing more work than it should. We track these over time and alert on anomalies.

Growing the test suite over time

Test suites don't get authored in one sitting. They evolve over time. They start with the simplest checks that give a signal: does the output exist? Does it parse? Then structural checks follow: does the output have the right schema, the right columns, the right types? Only later come end-to-end data validation judges: does the output actually produce correct results when you run it?

This mirrors how test suites mature in traditional software. Exhaustive integration tests don't come on day one. It starts with smoke tests, then unit tests as failure modes emerge, building toward end-to-end coverage over time. The key is that the infrastructure supports adding new judges cheaply, so the test suite grows alongside the agent.

Testing the Tests: Judge Alignment

Here's a problem every engineer knows: a flaky or wrong test suite that greenlights bad code ships bugs with confidence. Similarly, judges who approve poor outcomes give a false sense of security. This is where the second loop of the coSTAR framework comes in: the same scenarios and traces that drive agent refinement also drive judge refinement, with human expert scores as the ground truth. This matters because, unlike traditional testing where test correctness can be verified by inspection, LLM judges are stochastic and can drift in how they interpret natural-language criteria. So we need a way to verify them and keep them aligned with human experts.

To do this alignment, we first curate a Golden Set of typically dozens of examples of agent outputs that our engineers have manually assessed. This is the ground truth the judges must agree with. Then we leverage MLflow's alignment capabilities (powered by techniques like GEPA and MemAlign) to automatically refine the judge against the Golden Set. Notice this is structurally the same STAR loop we use to refine the AUT itself, but the assess step is performed by human experts and the refine step applies to the judge.

R - Refine

With judges that the judge loop has aligned against human expert judgment, we can now trust the agent loop. A coding assistant treats the agent as its codebase and the judges as its test suite. It reads failures, diagnoses root causes, patches the agent, and re-runs everything. The engineer is still the reviewer and final arbiter of the proposed changes to the agent, but this automated iteration saves considerable human effort in analyzing and improving the agent.

Here's what one iteration looked like for the Data Analyst agent:

Red. We ran the initial version of the agent against our scenario suite. The best-practices judge flagged a discrepancy: our agent was generating code for logical views that was different from our official recommendations/documentation. While this discrepancy would not affect correctness, it had implications on the maintenance and deployment of the generated code. This is an example of an insidious regression that would be hard to catch by manual investigation.

Green. The coding assistant analyzed the judge feedback and identified the gap: the agent was using a skill that was not prescriptive about the type of views that should be created (temporary vs permanent). After adding the relevant guidance to the skill, the tests passed successfully and the change was verified to not introduce other regression (based on other test scenarios).

Regression Tests for Infrastructure, Not Just the Agent

So far we've described judges as tests for the agent, catching regressions when the agent implementation changes. But in practice, the agent itself isn't the only thing that changes. The agent depends on external tools and infrastructure, and those change too.

Our agents call MCP tools, standardized interfaces for data access, code execution, environment setup, and more. These tools have their own development teams and release cycles. When a tool changes its implementation (say, a code execution tool starts returning stderr in a different format, or a data access tool changes how it handles null values) the agent hasn't changed at all, but the agent's behavior can break.

Because we run our judges on every nightly build, they act as regression tests against the full stack, not just the agent’s current implementation. When a tool team ships a change that causes an agent to start failing its judges then we catch the error immediately, before it reaches customers. More importantly, the judge's failure tells us what broke (the specific quality dimension that regressed), which makes it far easier to triage whether the root cause is in the agent or in a tool the agent depends on.

This is the same value that integration tests provide in traditional software: they guard the contract between the code and its dependencies. The only difference is that here, the "code" is an agent and the "dependencies" are MCP tools.

From Eval to Production Monitoring

There's one more extension of the testing analogy that turned out to be surprisingly valuable: running the same judges on production traffic.

In traditional software, testing doesn't stop at CI. Production gets monitored too: error rates, latency percentiles, business metrics on live traffic. The same test logic that validates code in dev often reappears as health checks and alerts in prod.

We do the same thing. The judges we built for eval are designed to score any agent conversation, not just eval scenarios. So we run them (or a sampled subset) on real production conversations. This gives us:

• Early warning on drift. If judge's pass rate drops on production conversations, something changed. Maybe a model upgrade degraded quality, maybe user prompts shifted in a way the agent handles poorly. We see it in the judge scores before we see it in user complaints.
• Real-world signal for the test suite. Production conversations that judges flag as failures become candidates for new eval scenarios. This is how the test suite grows organically: real failures feed back into eval, closing the loop between production and development.
• Cost monitoring at the agent level. We track token usage and tool call counts on production conversations. A quality-neutral change that triples cost is still a regression.

핵심 인사이트는 동일한 평가 인프라(평가자, 메트릭, 기록된 추적)가 이중으로 활용된다는 것입니다. 평가를 위해 한 번 구축하면 프로덕션 모니터링은 부수적인 효과로 따라옵니다.

현재 상황

저희는 Databricks 플랫폼에서 출시한 여러 에이전트(예: Genie의 데이터 엔지니어링, 머신러닝 및 추적 분석 기능), 개발자 생산성을 위한 내부 에이전트, 그리고 기타 고객 대면 에이전트(예: AI Dev Kit 또는 OSS MLflow Assistant) 전반에 걸쳐 이 방법론을 채택했습니다. 전반적으로 실질적인 이점을 확인했습니다:

• 수동 평가에 비해 자동화된 테스트 스위트는 변경 사항 검증 시간을 2주에서 몇 시간으로 단축했습니다. 이에 따라 저희 팀은 더 빠른 속도로 개선 사항을 출시할 수 있었습니다.
• 여러 테스트 스위트가 에이전트당 수백 개의 테스트 시나리오로 확장되어 회귀를 탐지하는 데 대한 신뢰도를 높였습니다.
• 통합 테스트는 종속 인프라의 변경 사항을 감지하여 프로덕션에서 회귀를 방지할 수 있었습니다. 이러한 변경 사항의 예로는 기본 모델의 TODO 관리 동작, 지연 시간에 영향을 미치는 변경 사항 또는 모델 변경 사항이 있습니다.

MLflow는 GenAI 테스트 플랫폼으로서 엔지니어들이 방법론을 표준화하고, 테스트 개발을 가속화하며, 팀 간에 모범 사례를 공유하는 데 중요한 역할을 했습니다.

아직 작동하지 않는 것들

테스트 비유도 여기서 유용합니다. 저희의 한계는 익숙한 테스트 문제에 해당합니다:

시나리오 생성은 수동입니다(테스트 케이스 작성은 비용이 많이 듭니다). 저희는 평가, 정렬 및 최적화를 자동화했지만, 시나리오 자체를 생성하는 것은 여전히 사람의 작업입니다. 각 시나리오는 현실적인 초기 상태, 의미 있는 프롬프트 및 올바른 기대치를 만드는 것을 필요로 합니다. 이것이 테스트 스위트 크기를 제한하는 병목 현상이며, 좁은 테스트 스위트는 다음 문제로 직접 이어집니다. 시나리오 자동 생성(프로덕션 트래픽 패턴 또는 에이전트 사양에서 다양하고 현실적인 테스트 케이스 합성)은 저희에게 활발한 연구 분야입니다.

코딩 도우미가 과적합될 수 있습니다(테스트 스위트가 너무 좁음). 테스트 스위트가 충분한 사례를 다루지 못하면 코딩 도우미는 특정 입력에는 완벽하지만 새로운 입력에는 실패하는 에이전트 구현을 설계하게 됩니다. 이는 프로덕션에서 오류가 발생하는 단위 테스트를 통과하는 코드를 작성하는 것과 같은 에이전트의 경우입니다. 저희는 프로덕션 실패를 평가에 다시 피드하고 시간이 지남에 따라 커버리지를 확장하여 이를 완화하지만, 시나리오 생성이 자동화될 때까지 테스트 스위트 확장은 원하는 만큼 빠르지 않습니다.

평가자 정렬은 비용이 많이 듭니다(테스트 보정에는 인력이 필요함). 골든 세트를 구축하려면 도메인 전문가가 출력을 수동으로 채점해야 하는데, 이는 저희가 제거하려는 정확한 병목 현상입니다. 그리고 이것은 일회성 비용이 아닙니다. 에이전트가 발전함에 따라 평가자는 재보정이 필요합니다. 저희는 평가자의 불확실성을 측정하고, 평가자가 불분명한 특정 예제를 식별하여 인간의 레이블이 실제로 모호성을 해결할 수 있도록 하여 이를 더 스마트하게 만드는 방법을 조사하고 있습니다. 목표는 평가자 정렬을 위한 능동 학습입니다. 무작위 샘플을 채점하도록 전문가에게 요청하는 대신, 평가자가 불확실한 예제만 표시하고 도메인 전문가의 입력이 기준을 가장 많이 명확하게 하는 예제를 표시합니다.

다단계 실패는 귀인하기 어렵습니다(근본 원인 분석). 에이전트가 10단계 파이프라인의 7단계에서 실패하면 근본 원인이 7단계에 있었을까요, 아니면 3단계에 있었을까요? 저희 평가자는 증상을 감지하지만 코딩 도우미는 때때로 잘못된 함수를 변경하여 테스트 실패를 수정하는 것처럼 잘못된 단계를 패치합니다. 더 나은 인과 관계 추적은 활발한 연구 분야입니다.

새로운 실패 모드가 통과됩니다(커버리지 격차). coSTAR는 평가자가 다루는 차원 내에서 최적화됩니다. 새로운 유형의 실패가 발생하여 어떤 평가자도 확인하지 않으면, 어떤 테스트도 실행하지 않는 코드의 버그처럼 보이지 않습니다. coSTAR는 테스트 스위트 *내에서* 개선되지만, 테스트 스위트를 자체적으로 확장할 수는 없습니다. 사람은 여전히 새로운 실패 모드를 인지하고 평가자를 추가해야 합니다.

주요 내용

1. 에이전트 개발에는 테스트 문제가 있습니다. 자동화된 평가 없이는 테스트 없이 코딩하는 것이며, 예상되는 회귀를 겪게 될 것입니다.
2. 평가자에게 추적이 아닌 도구를 제공하십시오. 대상 도구를 호출하는 에이전트식 평가자는 집중된 단위 테스트와 같습니다. 전체 추적을 평가자에게 덤프하는 것은 어설션에 프로그램 상태를 덤프하는 것과 같습니다. 확장성이 없습니다.
3. 테스트를 테스트하십시오. LLM 평가자는 확률적입니다. 인간이 채점한 골든 세트에 대해 이를 정렬하는 것은 테스트 스위트를 사양에 대해 검증하는 것과 같습니다.
4. 루프를 닫으십시오. 진정한 승리는 전체 coSTAR 루프입니다. 신뢰할 수 있는 시나리오, 기록된 추적, 정렬된 평가자, 그리고 테스트를 통과할 때까지 에이전트를 개선하는 코딩 도우미입니다. 자동화된 개선 없이는 평가가 절반에 불과합니다.
5. 한 번 구축하고 어디서나 모니터링하십시오. 평가에서 검증하는 것과 동일한 평가자가 프로덕션을 모니터링할 수 있습니다. 하나의 투자, 두 개의 수익.
6. 커플링이 중요합니다. 에이전트를 개선하는 것은 이를 구동하는 평가자의 신뢰성만큼만 신뢰할 수 있습니다. 평가자에 대한 신뢰를 얻는 루프와 그 신뢰를 사용하여 에이전트를 개선하는 루프라는 coSTAR의 두 가지 커플링된 루프는 자동화된 개선을 단순히 빠른 것이 아니라 의미 있게 만드는 것입니다.

저희는 MLflow의 일부로 coSTAR를 구축하고 있습니다. 유사한 문제를 해결하고 있다면 저희에게 알려주시면 감사하겠습니다.

• coSTAR 방법론을 사용하여 출시한 기능을 보려면 Genie Code를 사용해 보세요.
• 반복적인 에이전트 개선을 위해 LLM 평가자를 정의하고 사용하는 방법을 시작하려면 MLflow의 튜토리얼을 따르세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)