3부 중 3부 — MCP 에이전트 구축 및 테스트

성능 테스트(performance testing)를 해본 적이 있다면 JMeter의 사고방식을 알고 있을 것입니다. "내 시스템이 충분히 빠른가?"라는 질문은 추측이 아닌 측정을 통해 답해야 하는 문제입니다. 테스트 계획(test plan)을 정의하고, 시스템에 부하를 가하고, 수치를 읽어내면, 이제 어떤 변경 사항이 상황을 개선했는지 혹은 악화시켰는지 알 수 있습니다. 단순히 "더 빨라진 것 같다"는 느낌이 아니라 말이죠.

MCP 에이전트에는 이에 상응하는 도구가 없으며, 매우 절실히 필요합니다. 최근까지 저의 사례를 포함하여 제가 본 대부분의 에이전트 개발 방식은 다음과 같습니다. 시스템 프롬프트(system prompt)를 수정하고, 수동으로 몇 번 실행해 본 뒤, 답변이 더 나아 보이는지 눈으로 확인하고, 배포합니다. 그것은 측정이 아닙니다. 그것은 단지 단계만 더 추가된 '느낌(vibes)'일 뿐입니다.

이를 해결하기 위해 내가 만든 것

이 시리즈의 이전 파트에서 소개한 MCP 호스트인 MAVERIK은, JMeter가 엔드포인트(endpoints)를 다루는 방식처럼 에이전트 정의를 다루는 내장 테스트 프레임워크(testing framework)를 갖추며 성장했습니다. 즉, 한 번 정의하고, 체계적으로 실행하며, 인상이 아닌 확실한 수치로 비교하는 방식입니다.

매핑은 거의 일대일로 이루어집니다:

판정 기준(judge criteria)에 대해 언급할 만한 세부 사항이 있습니다. 판정자(judge)는 두 번째 모델이므로 자체적으로 토큰(tokens)을 소모합니다. MAVERIK은 판정자의 비용을 별도로 추적하므로, 테스트 중인 에이전트가 소비하는 예산을 결코 오염시키지 않습니다. 그렇게 하지 않으면, 루브릭(rubric) 점수가 매겨지는 모든 스위트가 에이전트를 실제보다 더 비싼 것처럼 조용히 보이게 만듭니다.

에이전트 정의(agent definitions) 세트를 대상으로 스위트(suite)를 지정하면, MAVERIK은 모든 에이전트에게 모든 질문을 던집니다. 각 케이스마다 새로운 에이전트 인스턴스를 실행하며, Part 2에서 '결과 파라미터(outcome parameters)'라고 불렀던 항목들을 기록합니다. 즉, 인스턴스의 통과 여부, 소요 시간(LLM 및 도구 실행 시간을 모두 포함한 전체 턴 시간), 모든 왕복 과정(round trip) 동안 소모된 입력 및 출력 토큰 수, 그리고 수행된 도구 호출(tool calls) 횟수를 기록합니다. 이때 어떤 도구를 호출했는지도 구체적으로 기록하는데, 이는 일부 도구가 다른 도구보다 호출 비용이 훨씬 더 비싸기 때문입니다.

두 가지 파라미터 분할의 실행

이 지점이 바로 Part 2에서 제시한 프레임워크가 실제로 가치를 발휘하는 부분입니다. 당신은 정의(definition)를 튜닝하고, 인스턴스(instances)를 측정합니다. 실행에 앞서, 무엇이 정답으로 간주되는지, 평가자(judge)가 어떤 루브릭(rubric)을 적용해야 하는지 등 결과 파라미터를 기준으로 작성합니다. 이것이 바로 실행 가능한 작업 계약(task contract)이 됩니다. 그런 다음, 튜닝 가능한 파라미터들을 한 번에 하나씩 훑으며 조정합니다. 예를 들어, 서로 다른 시스템 컨텍스트(system context), 더 저렴한 모델, 순차적 방식 대신 병렬 도구 호출(parallel-tool-calling) 전략, 또는 축소된 MCP 서버 세트 등을 시도할 수 있습니다. MAVERIK은 사전에 정의한 단위로, 해당 변경 사항이 실제로 도움이 되었는지 아니면 단순히 비용을 다른 곳으로 전가했을 뿐인지를 알려줍니다.

이것이 진정한 보상입니다. 단순히 "에이전트가 질문에 답했는가"를 고립시켜 보는 것이 아니라, "v2 시스템 컨텍스트가 토큰을 3분의 1만 사용하면서도 동일하게 잘 답하는가" 또는 "저렴한 모델이 이 유형의 질문에 실제로 충분히 좋은가, 아니면 쉬운 케이스에서만 그렇게 보이는 것인가"를 확인하는 것입니다.

이 내용이 추상적으로 들린다면, 제가 지난주에 실제 사례를 게시했습니다. MCP 서버 세트만 다른 두 가지 에이전트 정의, 하나의 질문, 그리고 답변 품질과는 무관한 28%의 비용 차이를 다루었습니다. 전체 실험은 설정(config) 복제와 단일 질문 스위트로 이루어졌습니다. 그 포스트가 바로 수동으로 한 번 실행해 본 이 루프(loop) 그 자체입니다. 이 섹션은 루프 자체에 관한 것입니다.

의도적으로 정석대로 구축함

이 모든 것이 가능한 이유는 Part 1에서의 설계 선택 때문입니다. 도구 호출 루프(tool-calling loop)가 SDK의 자동 호출 모드(auto-invocation mode)가 아닌, 수동으로 구동되도록 설계되었습니다. 모든 도구 호출(tool call)은 가시적이며, 모든 왕복(round trip)은 계산 가능하고, 모든 토큰(token)은 추적이 가능합니다. 그리고 결정적으로, 에이전트와 대화형으로 채팅을 하든 전체 벤치마크 스위트(benchmark suite)를 통해 실행하든 정확히 동일한 루프 코드가 실행됩니다. 테스트 결과는 실제 동작을 예측할 수 있을 때에만 의미가 있으며, 이는 테스트 경로와 프로덕션(production) 경로가 시뮬레이션이 아닌 동일한 코드일 때만 가능합니다.

구축해야 할 것들이 더 남아 있습니다. 어떤 도구를 호출하는 것이 비용이 많이 드는지 고려하는 비용 예측(cost prediction), 그리고 각 정의를 수동으로 작성하는 대신 범위(range)로부터 정의 매트릭스를 생성하는 파라미터 스윕(parameter sweeps) 등이 그것입니다. 하지만 핵심 루프는 이미 작동합니다. "좋음"이 무엇을 의미하는지 정의하고, 실제 에이전트 정의에 대해 실행한 뒤, 직관 대신 숫자가 논쟁하게 만드십시오.

그 다음 단계는 CI/CD 본능을 가진 사람이라면 누구나 당연하게 생각할 단계입니다. 만약 스위트(suite)가 변경 사항이 도움이 되었는지 알려줄 수 있다면, 변경 사항이 _무언가를 망가뜨렸는지_도 알려줄 수 있습니다. 이는 이 도구가 누군가 확인하는 것을 기억할 때만 실행되는 것이 아니라, 모든 커밋(commit)마다 파이프라인(pipeline)에서 실행되어야 함을 의미합니다. 그것이 다음 글의 주제입니다.

만약 여러분이 MCP를 기반으로 구축하고 있으며, 단지 느낌(vibes)에 의존해 프롬프트 변경 사항을 배포한 적이 있다면, 현재 그것이 실제로 도움이 되었는지 어떻게 결정하고 계신지 듣고 싶습니다. 이 프로젝트는 오픈 소스입니다 — https://github.com/langens-jonathan/maverik.