이번 주 DEV를 살펴보니, 제 피드에 올라오는 게시물의 절반이 에이전트(agents)에 관한 것이었습니다. 오케스트레이션 프레임워크 (orchestration frameworks), A2A 프로토콜 (A2A protocols), 서브 에이전트 지표 (sub-agent metrics), 로컬 AI 장비 (local AI rigs) 등이 그것입니다. 제가 직접 이러한 아이디어들을 시도할 때마다 반복해서 마주치는 패턴은 매번 동일합니다. 에이전트 설계가 두 번째 단계에서 이미 틀렸다는 것을 깨닫기 위해 유료 API 할당량(또는 주말 GPU 시간)을 다 써버린다는 점입니다.

그래서 저는 순서를 뒤집었습니다. 이제 저는 평가 하네스 (evaluation harness)를 먼저 작성하고, 무료로 호스팅된 환경에서 무료 모델 액세스를 통해 이를 실행한 다음, 하네스가 설계가 비용을 지불할 가치가 있다고 알려준 후에만 돈을 씁니다. 이 포스트는 여러분이 복사해서 실행할 수 있는 실행 가능한 하네스를 포함한 해당 워크플로 (workflow)에 관한 것입니다.

문제점: 에이전트 프로토타입은 비용이 많이 들게 실패한다

단일 에이전트 (single-agent) 스크립트는 반복 작업(iterate) 비용이 저렴합니다. 하지만 플래너 (planner), 워커 (worker), 그리고 크리틱 (critic)을 추가하는 순간, 모든 설계 실험은 세 역할 모두에 걸친 토큰 비용과 루프를 실행할 장소를 필요로 합니다. 만약 제가 보통 그러하듯, 플래너의 프롬프트 (prompt)가 실제 병목 현상(bottleneck)이라는 것을 발견하게 된다면, 여러분은 무료 티어 (free tier)가 알려줄 수 있었던 사실을 배우기 위해 비용을 지불한 셈이 됩니다.

해결책은 혼동하기 쉬운 두 가지 질문을 분리하는 것입니다:

1. 설계가 타당한가? (작업 분해 (task decomposition), 라우팅 (routing), 종료 조건 (termination conditions))
2. 프로덕션 (production)에 사용하기에 충분히 빠르고/저렴하고/똑똑한가? (지연 시간 (latency), 작업당 비용 (cost per task), 프런티어 모델 (frontier-model) 품질)

질문 1은 구조적입니다. 더 성능이 낮은 무료 모델로도 답할 수 있습니다. 질문 2는 진정으로 여러분의 프로덕션 스택 (production stack)을 필요로 하며, 질문 1을 통과할 때까지 미뤄두어야 합니다.

결과물: 인프라 구축 전에 실행되는 평가 하네스

제가 사용하는 하네스는 다음과 같습니다. 이것은 의도적으로 모델 불가지론적 (model-agnostic)입니다. 문장 품질보다는 파이프라인 (pipeline)의 구조 (올바른 서브 태스크 (sub-tasks)가 생성되었는가? 루프가 종료되었는가? 크리틱이 잘못된 출력을 거부했는가?)를 점수화하므로, 작은 무료 모델에서도 의미를 유지합니다.

# eval_harness.py — 멀티 에이전트 파이프라인을 위한 구조적 평가
# 모든 OpenAI 호환 엔드포인트(무료 티어 또는 유료)에서 실행됩니다.
# 라벨: 모의 클라이언트(mock client)를 대상으로 로컬에서 테스트됨; 실제 클라이언트로 교체하세요.
...

주의 깊게 살펴볼 두 가지 사항이 있습니다:

• ambiguous_goal (모호한 목표) 케이스는 실제 설계 버그를 가장 많이 잡아내는 사례입니다. 많은 플래너 (planner) 프롬프트들은 명확한 질문을 던지는 대신 "대시보드를 더 개선해줘"라는 요청에 대해 스스로 하위 작업 (sub-tasks)을 만들어버리곤 합니다. 이러한 실패를 무료 모델에서 찾아내는 데는 비용이 전혀 들지 않습니다.
• wall_seconds는 기록되지만 의도적으로 점수화 (scored)하지는 않습니다. 무료 공유 환경에서의 지연 시간 (latency)은 실제 운영 환경의 지연 시간에 대해 아무런 정보도 주지 않기 때문입니다. 이를 점수화하는 것은 잘못된 것을 측정하는 일이 될 것입니다.

무료 샌드박스 (sandbox)의 역할

이 루프를 실행하려면 두 가지가 필요합니다: 모델 추론 (model inference), 그리고 테스트 프레임워크 (harness)를 실행할 장소입니다. 저는 두 가지 모두에 MonkeyCode를 사용합니다. MonkeyCode의 무료 모델 액세스는 추론 측면을 충족하며, 무료 서버 옵션 덕분에 테스트 프레임워크를 제 노트북이 아닌 다른 곳에서 실행할 수 있습니다. 이는 팀원이 동일한 설정에 대해 동일한 평가 (eval)를 다시 실행해야 할 때 매우 중요합니다.

공지: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.

제가 주장하지 않는 부분에 대해 명확히 말씀드리고 싶습니다: 저는 어떤 모델을 사용할 수 있는지, 할당량 (quotas)은 얼마인지, 또는 무료 옵션이 얼마나 오래 유지될지 확인하지 않았습니다. 따라서 이 모든 사항은 변경될 수 있음을 유의하시고, 이를 기반으로 무언가를 구축하기 전에 현재 약관을 확인하십시오. 아래의 워크플로 (workflow)는 이러한 세부 사항에 의존하지 않으며, 그것이 핵심입니다. 만약 무료 옵션이 사라지더라도, client를 다른 엔드포인트 (endpoint)로 지정하기만 하면 테스트 프레임워크는 여전히 작동합니다.

결정 테이블: 유료 인프라로 전환해야 하는 시점

가장 많은 비용을 절약해 주는 행은 두 번째 행입니다: 유료 모델에 맞춰 프로토타입을 다시 작성하고 요행을 바라는 대신, 단 한 번의 유료 호출을 통해 동일한 테스트 프레임워크를 다시 실행하는 것입니다.

솔직한 한계점

• 구조적 검사(Structural checks)는 품질 검사(quality checks)가 아닙니다. 계획(plan)에 모든 적절한 키워드가 포함되어 있더라도 여전히 나쁜 계획일 수 있습니다. 하네스(harness)는 망가진 설계를 걸러낼 뿐, 좋은 설계를 인증하지는 않습니다.
• 무료 공유 환경은 노이즈가 많습니다. 그곳에서 시간(time)을 측정하지 마세요. 그곳에서 모델 A와 모델 B의 지연 시간(latency)을 비교하지 마세요. 또한 CI를 위한 가용성(availability)을 가정하지 마세요.
• 무료 티어(Free tiers)는 종료됩니다. 야간 작업(nightly job)에 연결하는 모든 것은 이식 가능(portable)해야 합니다. 클라이언트를 인터페이스 뒤에 두세요 (위의 하네스가 정확히 이 이유로 OpenAI 호환 형태를 가정하는 것입니다).

이 접근 방식을 사용해서는 안 되는 대상

• 만약 당신의 작업이 안전에 치명적이거나(safety-critical) 개인 사용자 데이터를 다룬다면, 어떤 무료 호스팅 환경으로도 보내지 마세요. 대신 오픈 모델(open model)을 사용하여 로컬에서 평가하세요.
• 만약 프로덕션 지연 시간(production latency)이나 작업당 비용을 벤치마킹(benchmarking)하고 있다면, 무료 티어는 양방향 모두에서 잘못된 수치를 제공할 것입니다. 적은 샘플을 사용하여 유료 인프라(paid infra)로 넘어가세요.
• 만약 에이전트의 핵심 리스크가 분해(decomposition)가 아닌 도구 통합(tool integration) (인증, 부작용, 속도 제한)이라면, 구조적 하네스(structural harness)는 실제 리스크를 테스트하지 못합니다. 대신 도구 호출 모의 하네스(tool-call mock harness)를 구축하세요.

마치며

가장 저렴한 토큰은 망가진 설계를 발견하느라 소비하지 않는 토큰입니다. 구조적 평가(structural evaluation)를 먼저 작성하고, 무료인 어딘가에서 실행한 다음, 당신의 낙관론이 아니라 하네스가 아이디어가 실제 예산을 받을 자격이 있는지 결정하게 하세요. 이번 주에 이 루프(loop)를 시도해보고 싶다면, 위의 스크립트와 어떤 무료 모델 엔드포인트(model endpoint)만 있으면 진정으로 충분합니다. MonkeyCode의 무료 티어가 마침 제가 사용 중인 조합이지만, 하네스는 특정 제공업체보다 더 오래 지속됩니다.