Day 21. Agent Client + Agent Bench — 수동에서 선언적으로

Day 14에서 Orchestrator-Workers와 Evaluator-Optimizer를 짤 때, guard advisor 4종을 어떻게 붙였는지 떠올려 볼게요. 코드 변경 없이 15분 이론으로 갑니다.

Day 14의 수동 코드 — 무엇이 반복되었나

Day 14의 AgentChatClientConfig에는 ChatClient @Bean 메서드가 5개 나열되어 있었어요. 마스터 1개, 워커 3개(ARIA/REX/LUNA), 생성자+평가자 2개.

그리고 guard를 붙일 때는 이렇게 했어요.

// Day 14 — AgentChatClientConfig.guardAdvisors() 정적 팩토리
public static List<Advisor> guardAdvisors(int maxIterations,
                                          Duration timeout,
                                          long maxTotalTokens,
                                          int maxToolInvocations) {
    return List.of(
            new MaxIterationsAdvisor(maxIterations),
            new DurationTimeoutAdvisor(timeout),
            new UsageBudgetAdvisor(maxTotalTokens),
            new ToolInvocationCounterAdvisor(maxToolInvocations)
    );
}

호출하는 쪽에서는 매번 이렇게 조립했어요.

List<Advisor> guards = AgentChatClientConfig.guardAdvisors(5, Duration.ofSeconds(30), 8000L, 10);
String reply = chatClient.prompt()
        .user(userMessage)
        .advisors(guards.toArray(Advisor[]::new))
        .call()
        .content();

Day 19에서 한 단계 올라왔지만 — 여전히 "전역 1벌"

Day 19의 HarnessProperties + HarnessAdvisorChainConfig로 한도를 YAML에 외부화했어요. 하드코딩된 숫자가 application.yml로 빠진 건 진전이지만, 프로파일이 전역 1벌이었어요.

마스터 LLM은 반복 5회면 충분한데, Evaluator-Optimizer 루프는 10회가 필요해요. 전역 한도 하나로는 이 차이를 표현할 수 없죠.

Spring AI에 공식 AgentClient가 있을까?

잠깐 짚고 갈 게 있어요. "Spring AI에 AgentClient 같은 게 이미 있지 않나?" 라는 질문이 나올 수 있어요.

2026년 5월 기준, Spring AI 1.1.x 공식 코어에는 AgentClient 클래스가 없어요. Spring AI의 철학은 ChatClient + @Tool + Advisor라는 프리미티브를 제공하고, 도메인에 맞는 조합은 개발자가 직접 설계하도록 열어두는 거예요.

커뮤니티 프로젝트(spring-ai-community/spring-ai-agents)에 AgentClient라는 이름의 라이브러리가 있긴 한데, 이건 Claude Code나 Gemini CLI 같은 외부 CLI 에이전트를 Spring 앱에서 호출하는 래퍼예요. 우리가 만들려는 "ChatClient 기반 에이전트의 선언적 구성"과는 다른 축이에요.

오늘의 방향 — 세 단계로 올라간다

Step 2에서 에이전트 프로파일을 정의하고, Step 3에서 AgentClient facade를 만들어요.

Day 19 HarnessProperties가 "전역 1벌"이었다면, AgentProfile은 "에이전트 1대"의 독립 설정이에요. YAML 한 장에 에이전트 N대를 선언적으로 정의합니다.

에이전트 프로파일이 담아야 하는 것

에이전트 한 대를 선언적으로 정의하려면 무엇이 필요할까요?

1. 이름 — 어떤 에이전트인지 식별
2. system 프롬프트 — 이 에이전트의 역할 정의
3. guard 한도 4종 — maxIterations, timeout, tokenBudget, toolCallLimit
4. 허용 도구 목록 — 이 에이전트가 쓸 수 있는 도구 이름

이걸 하나의 불변 객체에 모아요.

AgentProfile record

// kr.spartaclub.aifriends.agentclient.AgentProfile

public record AgentProfile(
        String name,
        String systemPrompt,
        int maxIterations,
        Duration timeout,
        long maxTotalTokens,
        int maxToolInvocations,
        Set<String> allowedTools
) {

    public static Builder builder(String name) {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("AgentProfile name 은 비어 있을 수 없습니다.");
        }
        return new Builder(name);
    }
    // Builder 내부에서 기본값: maxIterations=10, timeout=30s, tokens=8000, tools=20
}

빌더 패턴으로 필요한 것만 지정하고 나머지는 기본값을 쓸 수 있어요.

AgentProfile profile = AgentProfile.builder("aria-worker")
        .systemPrompt("너는 캐릭터 ARIA야...")
        .maxIterations(3)
        .timeout(Duration.ofSeconds(10))
        .maxToolInvocations(5)
        .allowedTools(Set.of("getCurrentWeather", "getAffinity"))
        .build();

YAML로 에이전트 N대 선언하기

Java 코드에서 직접 빌더를 호출하는 건 여전히 코드예요. 진짜 선언적이려면 YAML로 적을 수 있어야 해요.

AgentClientProperties가 Spring Boot의 @ConfigurationProperties로 YAML을 바인딩해요.

# application.yml — 에이전트 프로파일 선언
ai-friends:
  agent-client:
    profiles:
      orchestrator-master:
        system-prompt: |
          너는 ai-friends 그룹 대화방의 오케스트레이터야.
          사용자 발화를 받아 캐릭터들에게 분배하는 역할만 해.
        max-iterations: 5
        timeout: 15s
        max-total-tokens: 4000
        max-tool-invocations: 0
      worker-aria:
        system-prompt: |
          너는 캐릭터 ARIA. 차분하고 친절한 카운슬러.
        max-iterations: 3
        timeout: 10s
        max-total-tokens: 2000
        max-tool-invocations: 5
        allowed-tools:
          - getCurrentWeather
          - getAffinity

Day 19 HarnessProperties와 비교

Step 3에서 이 프로파일을 기반으로 AgentClient를 조립해 볼게요.

프로파일이 정의됐으니, 이걸 기반으로 ChatClient + guard advisor를 한 덩어리로 감싸는 facade를 만들어요. agentClient.run(message) 한 줄이면 guard 4종이 자동 적용됩니다.

Before/After — Day 14 vs Day 21

Before (Day 14) — 매번 수동 조립

// 1. ChatClient는 @Bean으로 미리 빌드
@Bean
public ChatClient ariaWorkerChatClient(ChatClient.Builder builder, ...) {
    return builder.defaultSystem("너는 ARIA...").defaultTools(...).build();
}

// 2. 호출할 때마다 guard를 수동으로 조립
List<Advisor> guards = AgentChatClientConfig.guardAdvisors(3, Duration.ofSeconds(10), 2000L, 5);
String reply = ariaWorkerChatClient.prompt()
        .user(userMessage)
        .advisors(guards.toArray(Advisor[]::new))
        .call()
        .content();

After (Day 21) — 선언 한 줄

// YAML 프로파일로 이미 guard 한도가 설정된 AgentClient
String reply = ariaAgent.run(userMessage);

AgentClient 클래스 본체

// kr.spartaclub.aifriends.agentclient.AgentClient

public class AgentClient {

    private final ChatClient chatClient;
    private final AgentProfile profile;

    public AgentClient(ChatClient chatClient, AgentProfile profile) {
        this.chatClient = chatClient;
        this.profile = profile;
    }

    public String run(String userMessage) {
        return chatClient.prompt()
                .user(userMessage)
                .advisors(freshGuards())
                .call()
                .content();
    }

    public <T> T run(String userMessage, Class<T> responseType) {
        return chatClient.prompt()
                .user(userMessage)
                .advisors(freshGuards())
                .call()
                .entity(responseType);
    }

    Advisor[] freshGuards() {
        return new Advisor[]{
                new MaxIterationsAdvisor(profile.maxIterations()),
                new DurationTimeoutAdvisor(profile.timeout()),
                new UsageBudgetAdvisor(profile.maxTotalTokens()),
                new ToolInvocationCounterAdvisor(profile.maxToolInvocations())
        };
    }
}

핵심은 freshGuards()예요. Day 14에서 배운 것처럼 guard advisor들은 AtomicInteger/AtomicLong 상태를 내부에 들고 있어요. 호출마다 새 인스턴스를 만들어야 사이클 간 카운터가 오염되지 않아요. run()이 불릴 때마다 freshGuards()가 프로파일 한도로 새 advisor 4종을 생성해요.

AgentClientFactory — 도구까지 해석해서 조립

AgentClient를 만들려면 ChatClient가 필요하고, ChatClient에는 system 프롬프트와 도구가 등록되어야 해요. AgentClientFactory가 이 조립을 담당해요.

// kr.spartaclub.aifriends.agentclient.AgentClientFactory

public class AgentClientFactory {

    private final Map<String, Object> toolRegistry;

    public AgentClient create(ChatClient.Builder builder, AgentProfile profile) {
        ChatClient.Builder clientBuilder = builder
                .defaultSystem(profile.systemPrompt());

        Object[] tools = resolveTools(profile);
        if (tools.length > 0) {
            clientBuilder.defaultTools(tools);
        }

        ChatClient chatClient = clientBuilder.build();
        return new AgentClient(chatClient, profile);
    }

    Object[] resolveTools(AgentProfile profile) {
        if (profile.allowedTools().isEmpty()) {
            return new Object[0];
        }
        return profile.allowedTools().stream()
                .map(name -> {
                    Object tool = toolRegistry.get(name);
                    if (tool == null) {
                        throw new IllegalArgumentException(
                                "도구 레지스트리에 '%s' 가 없습니다. 등록된 도구: %s"
                                        .formatted(name, toolRegistry.keySet()));
                    }
                    return tool;
                })
                .toArray();
    }
}

toolRegistry는 도구 이름 → 도구 빈의 매핑이에요. @Bean으로 한 번 등록해두면 YAML의 allowed-tools에 이름만 적어서 원하는 도구를 에이전트에 끼울 수 있어요.

에이전트 40줄 → 3줄

Day 14에서 ARIA 워커를 정의하려면: @Bean 메서드 20줄 + guardAdvisors() 호출 + @Qualifier 주입 = 40줄 가까운 Java 코드가 필요했어요.

Day 21에서는: YAML 프로파일 8줄 + agentClient.run() 1줄 = 코드 3줄, 설정 8줄. Java 코드의 반복이 사라져요.

Day 14의 GameOrchestrationService + OrchestratorMasterService + CharacterWorkerService를 AgentClient 기반으로 재구현해요. Before/After를 코드 레벨에서 비교합니다.

Before/After 비교표

DeclarativeGameOrchestrationService 핵심 코드

// kr.spartaclub.aifriends.agentclient.service.DeclarativeGameOrchestrationService
// (전체 코드: lecture-source-code/ai-friends/.../DeclarativeGameOrchestrationService.java)

public class DeclarativeGameOrchestrationService {

    private final AgentClient masterAgent;
    private final Map<String, AgentClient> workerAgents;

    public GroupDialogueResponse orchestrate(String userUtterance,
                                             List<String> activeCharacterIds) {
        // 마스터 에이전트가 분배 — guard 자동 적용
        DialogueDistribution distribution = masterAgent.run(
                formatDistributePrompt(userUtterance, activeCharacterIds),
                DialogueDistribution.class);

        // 워커 에이전트들이 병렬 응답 — 각자 guard 자동 적용
        List<CompletableFuture<WorkerResponse>> futures = sanitized.stream()
                .map(assignment -> CompletableFuture.supplyAsync(() -> {
                    AgentClient worker = resolveWorkerAgent(assignment.characterId());
                    String responseText = worker.run(assignment.responseIntent());
                    return new WorkerResponse(
                            assignment.characterId(), responseText, assignment.priority());
                }))
                .toList();

        CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
        // ... priority 정렬 후 GroupDialogueResponse 반환
    }
}

워커 해석 규칙

Day 14에서는 characterId "ARIA" → 빈 이름 "ariaWorkerChatClient"로 매핑했어요.

Day 21에서는 characterId "ARIA" → 프로파일 키 "worker-aria"로 매핑해요.

AgentClient resolveWorkerAgent(String characterId) {
    String key = "worker-" + characterId.toLowerCase(Locale.ROOT);
    AgentClient agent = workerAgents.get(key);
    if (agent == null) {
        throw new IllegalArgumentException(
                "등록되지 않은 캐릭터입니다: characterId=%s (조회 키=%s, 등록된 키=%s)"
                        .formatted(characterId, key, workerAgents.keySet()));
    }
    return agent;
}

매핑 규칙이 단순해졌어요. YAML 프로파일 키가 곧 에이전트 식별자예요. 새 캐릭터를 추가하려면 Java 코드 변경 없이 YAML에 worker-{이름} 프로파일만 추가하면 돼요.

AgentClientAutoConfig — YAML에서 에이전트 맵 자동 생성

// kr.spartaclub.aifriends.agentclient.config.AgentClientAutoConfig

@Configuration
@EnableConfigurationProperties(AgentClientProperties.class)
public class AgentClientAutoConfig {

    @Bean
    public Map<String, AgentClient> agentClients(ChatClient.Builder builder) {
        // YAML 프로파일 N개 → AgentClient N개의 맵
        return buildAgentMap(name -> builder);
    }
}

Day 14에서 @Bean 메서드 5개를 나열했던 코드가, 이제 @Bean 메서드 1개로 줄었어요. YAML의 프로파일 수만큼 자동으로 AgentClient가 만들어져요.

Day 14의 CharacterOptimizationService를 AgentClient 기반으로 재구현해요. 가장 큰 변화 — maxIterations가 메서드 파라미터에서 YAML 설정으로 이동합니다.

Before/After — maxIterations의 위치 변화

Before (Day 14) — 호출마다 값이 흔들릴 수 있음

// maxIterations가 메서드 파라미터
public OptimizationResult optimize(String characterId,
                                    String initialContextPrompt,
                                    String characterPersona,
                                    int maxIterations) {  // ← 호출 측이 매번 결정
    // ...
}

After (Day 21) — 프로파일에서 고정

// maxIterations가 generator 프로파일의 YAML 설정
public OptimizationResult optimize(String characterId,
                                    String initialContextPrompt,
                                    String characterPersona) {  // ← 파라미터 사라짐
    int limit = generatorAgent.profile().maxIterations();  // ← YAML에서 읽기
    // ...
}

DeclarativeCharacterOptimizationService 핵심 코드

// kr.spartaclub.aifriends.agentclient.service.DeclarativeCharacterOptimizationService
// (전체 코드: lecture-source-code/ai-friends/.../DeclarativeCharacterOptimizationService.java)

public class DeclarativeCharacterOptimizationService {

    private final AgentClient generatorAgent;
    private final AgentClient evaluatorAgent;

    public OptimizationResult optimize(String characterId,
                                        String initialContextPrompt,
                                        String characterPersona) {
        int limit = generatorAgent.profile().maxIterations();
        String contextPrompt = initialContextPrompt;
        CharacterDraft draft = null;
        EvaluationFeedback feedback = null;
        int attempts = 0;

        while (attempts < limit) {
            attempts++;
            draft = generatorAgent.run(
                    "캐릭터 ID: %s\n%s".formatted(characterId, contextPrompt),
                    CharacterDraft.class);
            feedback = evaluatorAgent.run(
                    "캐릭터 페르소나: %s\nnarration: %s"
                            .formatted(characterPersona, draft.narration()),
                    EvaluationFeedback.class);

            if (feedback.verdict() == EvaluationVerdict.PASSED) {
                return new OptimizationResult(draft, feedback, attempts, true);
            }
            contextPrompt = buildContextPrompt(initialContextPrompt, feedback.suggestion());
        }
        return new OptimizationResult(draft, feedback, attempts, false);
    }
}

루프 구조 자체는 Day 14와 거의 동일해요. 바뀐 건 두 가지뿐이에요.

1. maxIterations가 메서드 파라미터 → generatorAgent.profile().maxIterations()
2. chatClient.prompt().user().call().entity() → generatorAgent.run(message, Class)

guard advisor는 run() 안에서 매 호출마다 자동 적용되니까, 루프 바깥에서 guard를 조립하는 코드가 완전히 사라졌어요.

YAML로 루프 한도 조정

ai-friends:
  agent-client:
    profiles:
      character-generator:
        system-prompt: "너는 캐릭터 narration 생성 엔진이야..."
        max-iterations: 5    # dev에서는 5, prod에서는 3으로 줄여 비용 절감
        timeout: 20s
        max-total-tokens: 6000
      character-evaluator:
        system-prompt: "너는 캐릭터 narration 품질 평가자야..."
        max-iterations: 10
        timeout: 10s
        max-total-tokens: 3000

dev 프로파일에서는 max-iterations: 5로 넉넉하게, prod에서는 3으로 빡빡하게. Java 코드 변경 없이 YAML 한 줄이에요.

AgentClient로 에이전트를 선언적으로 실행할 수 있게 됐어요. 이제 "이 에이전트가 제대로 동작하는지"를 배포 전에 자동으로 검증하는 프레임워크를 만들어요.

왜 에이전트에 회귀 테스트가 필요한가

일반 소프트웨어는 같은 입력에 항상 같은 출력이 나와요. 에이전트는 다릅니다. LLM이 개입하니까 같은 입력에도 매번 다른 출력이 나올 수 있어요.

그래서 에이전트의 회귀 테스트는 "출력이 정확히 이것인가"가 아니라 "출력이 이 조건을 만족하는가"를 검증해요.

• "ARIA가 차분한 톤으로 답했는가?" (설정 일관성)
• "호감도 음수인데 호의적으로 답하지 않았는가?" (규칙 정합성)

Day 19에서 만든 Evaluator 인터페이스가 바로 이 "조건 만족 여부"를 판정하는 도구예요. AgentBench는 이 Evaluator를 시나리오 묶음으로 조직화한 프레임워크예요.

3가지 부품

1. AgentScenario — 시나리오 1건

// kr.spartaclub.aifriends.agentclient.bench.AgentScenario

public record AgentScenario(
        String name,              // "ARIA 캐릭터 설정 일관성"
        String userMessage,       // "오늘 기분 어때?"
        List<Document> supportingData,  // 평가 기준 데이터
        Evaluator evaluator       // Spring AI Evaluator
) { }

2. AgentBenchRunner — 시나리오를 돌리고 결과를 집계

// kr.spartaclub.aifriends.agentclient.bench.AgentBenchRunner (발췌)

public AgentBenchResult run(AgentClient agent, List<AgentScenario> scenarios) {
    List<String> responses = scenarios.stream()
            .map(scenario -> agent.run(scenario.userMessage()))
            .toList();
    return runWithResponses(agent.profile().name(), scenarios, responses);
}

run()은 실제 AgentClient를 호출해서 응답을 받고, runWithResponses()는 미리 준비된 응답으로 평가만 수행해요. 후자는 LLM 호출 없이도 평가 로직을 검증할 수 있어서, 일반 단위 테스트에서도 쓸 수 있어요.

3. AgentBenchResult — 집계 결과

// kr.spartaclub.aifriends.agentclient.bench.AgentBenchResult

public record AgentBenchResult(
        String agentName,
        int totalScenarios,
        int passed,
        int failed,
        List<ScenarioResult> details
) {
    public double passRate() {
        return totalScenarios > 0 ? (double) passed / totalScenarios : 0.0;
    }
}

passRate()가 0.0~1.0 사이의 통과율을 돌려줘요. 다음 시간(Day 22)에서 이 값을 Micrometer Gauge로 수집하면, 대시보드에서 "에이전트 품질 추이"를 시계열로 볼 수 있어요.

프레임워크를 만들었으니, ai-friends에 실제로 쓸 시나리오를 작성해요. 캐릭터 설정 일관성 + 호감도 규칙 정합성, 두 종류입니다.

시나리오 팩토리 구조

AiFriendsScenarioFactory가 Day 19의 두 Evaluator를 재활용해서 시나리오 세트를 생산해요.

// kr.spartaclub.aifriends.agentclient.bench.AiFriendsScenarioFactory (발췌)

public static List<AgentScenario> characterConsistencyScenarios(Evaluator consistencyEvaluator) {
    return List.of(
            new AgentScenario(
                    "ARIA 캐릭터 설정 일관성",
                    "오늘 하늘이 예쁘다, 기분이 어때?",
                    "ARIA: 차분하고 친절한 카운슬러. 천천히 또박또박 반말.",
                    consistencyEvaluator),
            new AgentScenario(
                    "REX 캐릭터 설정 일관성",
                    "지난번에 게임 클리어했어!",
                    "REX: 활기차고 게임을 사랑하는 텐션. 반말 + 감탄사.",
                    consistencyEvaluator),
            new AgentScenario(
                    "LUNA 캐릭터 설정 일관성",
                    "밤하늘 별이 많다",
                    "LUNA: 신비롭고 시적인 톤. 짧은 비유. 반말.",
                    consistencyEvaluator)
    );
}

시나리오 1: 캐릭터 설정 일관성 (LLM 기반)

ARIA/REX/LUNA 각 캐릭터에 대해 "이 캐릭터다운 응답을 했는가?"를 Day 19의 CharacterConsistencyEvaluator가 채점해요.

시나리오 2: 호감도 규칙 정합성 (규칙 기반)

호감도 음수/양수 상태에서 응답 톤의 키워드를 AffectionCoherenceEvaluator가 검증해요.

public static List<AgentScenario> affectionRuleScenarios() {
    AffectionCoherenceEvaluator evaluator = new AffectionCoherenceEvaluator();
    return List.of(
            new AgentScenario(
                    "호감도 음수 — 적대적 반응 기대",
                    "칭찬할게, 너 정말 대단해!",
                    List.of(new Document("호감도 음수 상태",
                            Map.of("affectionScore", -20))),
                    evaluator),
            new AgentScenario(
                    "호감도 양수 — 호의적 반응 기대",
                    "오늘 뭐 하고 놀까?",
                    List.of(new Document("호감도 양수 상태",
                            Map.of("affectionScore", 85))),
                    evaluator)
    );
}

호감도 데이터는 Document의 metadata에 affectionScore 키로 전달해요. AffectionCoherenceEvaluator가 metadata에서 점수를 꺼내 규칙을 판정하는 구조예요.

CI/CD 파이프라인에서의 위치

git push → CI 빌드 → 단위 검증 → ./gradlew bench → 배포
                                         ↑
                          규칙 기반: 매 PR마다
                          LLM 기반: 릴리스 검증에서만

⚠️ LLM 기반 시나리오는 호출 비용이 들고 비결정적이에요. 매 PR마다 돌리면 비용이 쌓이고, 가끔 flaky 결과가 나올 수 있어요. 규칙 기반은 매 PR에, LLM 기반은 릴리스 직전에 돌리는 이중 구조가 현실적이에요.

오늘 만든 AgentClient + AgentBench에는 각각 트레이드오프가 있어요. 면접에서 "에이전트를 어떻게 관리하셨나요?"라는 질문에 이 5가지를 언급할 수 있으면 설계 깊이가 드러납니다.

트레이드오프 5종

1. 선언적 설정 vs 코드 직접 구성

YAML로 에이전트를 정의하면 추가/변경이 쉽지만, 복잡한 조건부 로직은 표현하기 어려워요. "월요일에는 maxIterations를 늘리고 금요일에는 줄인다" 같은 동적 규칙은 YAML 한 장으로 안 돼요. 그때는 코드에서 프로파일을 프로그래밍 방식으로 조합하는 혼합 전략이 필요해요.

2. 프로파일 granularity — 에이전트별 vs 시나리오별

현재는 "에이전트 1대 = 프로파일 1개"예요. 같은 에이전트라도 "일상 대화"와 "복잡한 분석" 시나리오에서 다른 한도가 필요하다면? 프로파일을 시나리오별로 쪼개면 유연해지지만, YAML이 복잡해지고 관리 비용이 올라가요. 현재 에이전트별 granularity는 대부분의 케이스에 충분해요.

3. 벤치 시나리오 커버리지 vs 유지보수 비용

시나리오를 100개 작성하면 커버리지는 높아지지만, 캐릭터 페르소나가 바뀔 때마다 100개를 다 고쳐야 해요. 핵심 경로 5~10개로 시작하고, 실제 사고가 나면 그 케이스를 추가하는 "사고 주도" 전략이 유지보수 비용 대비 효과가 가장 좋아요.

4. LLM 평가의 비결정성

CharacterConsistencyEvaluator는 LLM이 "CONSISTENT"라고 답하면 pass예요. 같은 응답을 평가해도 10번 중 9번은 CONSISTENT, 1번은 INCONSISTENT가 나올 수 있어요. 이걸 줄이려면 temperature를 0에 가깝게, 평가 프롬프트를 정밀하게, 또는 3회 호출해서 다수결을 쓰는 방법이 있어요. 각각 비용과 지연이 올라가는 트레이드오프가 있어요.

5. 인메모리 벤치 vs CI 파이프라인 통합

현재 AgentBenchRunner는 인메모리에서 결과를 돌려줘요. CI에 통합하려면 결과를 JSON/JUnit XML로 내보내서 CI 도구가 pass/fail을 판단할 수 있게 해야 해요. Gradle task로 ./gradlew bench를 등록하고, exit code 0/1로 CI 판정을 거는 패턴이 일반적이에요.

Day 22로 이어지는 다리

오늘 AgentClient로 에이전트를 실행하고, AgentBench로 평가까지 했어요. 남은 건 운영에서 눈(Observability)을 다는 것이에요.

다음 시간은 Observability 실전이에요. Day 19에서 만든 UsageTrackingAdvisor의 인메모리 AtomicLong 추적을 Micrometer 영속 메트릭으로 올려요. 토큰 사용량 분포, 응답 지연 히스토그램, 비용 알림까지 — Prometheus + Grafana 대시보드에서 확인하는 모습을 만들어요.

AgentBench의 passRate()도 Micrometer Gauge로 수집하면, "에이전트 품질이 시간에 따라 어떻게 변하는지"를 대시보드에서 추적할 수 있어요.

그리고 프롬프트/응답 감사 로그와 PII 마스킹 필터도 hands-on으로 구현해요. 누가 언제 무엇을 물었고 LLM이 뭐라 답했는지 기록하되, 개인정보는 마스킹해서 저장하는 구조예요.

오늘 Day 21에서 한 일을 정리해 볼게요.

Day 14에서 손으로 짰던 에이전트가, Day 19에서 YAML 외부화를 거쳐, Day 21에서 에이전트별 선언적 구성으로 자라났어요. 그리고 AgentBench로 "이 에이전트가 제대로 동작하는지"를 배포 전에 자동 검증하는 장치까지 갖추었어요.

Spring AI 공식 코어에 AgentClient가 없었지만, ChatClient + BaseAdvisor 프리미티브가 충분히 잘 깔려 있었기 때문에 그 위에 도메인 맞춤 추상화를 올리는 건 어렵지 않았어요. 프레임워크 사용자에서 프레임워크 설계자로 — 오늘 그 한 칸을 경험했어요.