Part 2 of 3 — MCP 에이전트 구축 및 테스트

모든 AI 에이전트는 결정들의 집합체이며, 이 중 대부분은 비공식적으로 한 번 내려지고 다시는 검토되지 않습니다. 어떤 모델을 사용할지, 시스템 프롬프트가 무엇일지, 어떤 도구에 접근할 수 있게 할지, 포기하기 전에 몇 단계까지 진행하게 할지 등이 그렇습니다. 아무도 이것들을 설정 파일로 작성하지 않습니다. 그저 코드상에서 발생하고, 그러다 보니 사람들은 그것들이 애초에 선택지였다는 사실을 잊어버립니다.

Part 1에서는 이러한 결정들이 형태를 갖는다고 주장했습니다: 에이전트 정의(agent definition) (클래스 — 루프, 시스템 컨텍스트, 기능 경계, 모델, 제한)와 에이전트 인스턴스(agent instance) (실행 중인 발생 — 목표, 컨텍스트 창, 자격 증명, 소모 예산). 이 구분이 바로 튜닝에 필요한 것이며, 왜냐하면 사람들이

이 부분은 사람들이 흔히 건너뛰는 지점입니다. 에이전트는 추상적으로 "좋은" 것이 아닙니다. 에이전트는 당신이 직접 정의한 기준에 따라 좋거나 나쁜 것이며, 그 기준들 하나하나가 에이전트 인스턴스(agent instances)가 실행된 후 측정된 값입니다:

• 수용 가능한 답변에 도달하는가? 정확성(Correctness)은 이진법적(binary)이지 않습니다. 때로는 "올바른 사실을 포함하고 있는가"의 문제일 수도 있고, 때로는 이를 판단하기 위한 루브릭(rubric)과 두 번째 모델이 필요할 수도 있습니다. 여기서 주목해야 할 점은 이것이 바로 테스트 가능한 형태가 된 작업 계약(task contract)이라는 사실입니다. 정의(definition)는 에이전트가 무엇을 반환해야 하는지를 말해주고, 결과 기준(outcome criterion)은 인스턴스가 실제로 그렇게 수행했는지를 확인합니다.
• 얼마나 오래 걸리는가? 모델의 "생각(thinking)"뿐만 아니라, 모든 도구 호출(tool call)을 포함한 실제 경과 시간(Wall-clock time)을 의미합니다.
• 얼마나 많은 토큰을 소모하는가? 단순히 마지막 메시지뿐만 아니라, 모든 왕복(round trip) 과정에서 합산된 입력(input)과 출력(output) 토큰입니다. 이는 인스턴스가 소모한 예산(consumed budget)을 다시 읽어낸 값입니다.
• 어떤 도구를 사용하며, 얼마나 자주 사용하는가? 과소평가되는 부분입니다. 어떤 도구는 호출 비용이 저렴하지만, 다른 도구들은 호출 제한이 있는 API, 느린 외부 서비스, 호출당 실제 달러 비용이 발생하는 도구처럼 비용이 많이 들 수 있습니다. 비록 둘 다 "통과"하더라도, 비싼 도구를 한 번 사용하여 정답을 얻는 에이전트보다 다섯 번의 저렴한 호출을 통해 정답에 도달하는 에이전트가 더 나은 에이전트입니다.

목록보다 순서가 더 중요합니다

여기서 거꾸로 하기 쉬운 부분이 있습니다. 튜닝 가능한 매개변수들을 탐색(sweeping)하기
전에 결과 매개변수(outcome parameters)를 먼저 정의해야 합니다. 정답이 어떤 모습이어야 하는지, 어느 정도의 지연 시간(latency)이 수용 가능한지, 기꺼이 지불할 토큰 예산은 얼마인지, 그리고 어떤 도구를 아껴서 사용해야 하는지를 결정하십시오. 이를 기준(criterion), 루브릭(rubric), 예산(budget)으로 기록해 두어야 합니다. 그러고 나서야 더 타이트한 시스템 컨텍스트(system context), 더 저렴한 모델, 혹은 다른 루프 전략(loop strategy)을 시도하기 시작하십시오.

그 단계를 건너뛰면 "튜닝 (tuning)"은 단순히 느낌(vibes)에 의존하는 작업이 됩니다. 프롬프트를 살짝 수정해보고, 시도한 세 가지 예시에서 답변이 조금 더 나아 보여서 그대로 배포하지만, 그것이 실제로 더 나아진 것인지 아니면 그냥 달라진 것뿐인지 알 수 없게 됩니다. 올바른 순서로 진행한다면 모든 변경 사항은 테스트 가능한 가설이 됩니다. 즉, 특정 정의 필드(definition field)를 변경했을 때, 내가 건드리지 않은 지표는 유지하면서 내가 중요하다고 말한 지표들이 내가 원하는 방향으로 움직이는지를 확인할 수 있게 됩니다.

이것이 중요한 이유: 에이전트 정의는 코드가 아니라 데이터입니다

이러한 프레임워크가 실무에서 효과를 발휘하는 이유는, 시스템 컨텍스트(system context), 모델(model), 능력 범위(capability boundary), 그리고 루프 설정(loop settings)이 코드에 박혀 있는 것이 아니라 설정 (configuration) 데이터가 되면 — 제 호스트의 경우 agents.json처럼 말이죠 — 두 에이전트를 비교하는 일이 코드 재작성(rewrite)이 아닌 차이점 비교(diff)가 되기 때문입니다. 정확히 하나의 필드만 다른 두 정의에 동일한 테스트 질문 세트를 던지고, 각 정의에 대해 일련의 인스턴스(instances)를 배치로 실행하면, 측정된 결과의 모든 차이는 바로 그 하나의 필드 때문이라고 결론 내릴 수 있습니다.

이것이 게임의 전부입니다. 클래스(class)를 튜닝하고, 인스턴스(instances)를 측정하십시오. 그리고 이것은 다음에 이어질 내용, 즉 이러한 비교를 수동이 아닌 체계적으로 수행하기 위해 정확히 필요한 설정입니다.

이 시리즈의 1부 링크: https://dev.to/langensjonathan/mcp-agents-explained-what-actually-makes-an-llm-an-agent-12a0