Oh! Heepie Day! 🐢

모델·에이전트 벤치마크

4 min read

개발 철학과 작업 습관(설계·코드스타일·테스트/디버깅)을 기준으로, 개별 모델과 에이전트 오케스트레이션을 공정하게 비교·기록하여 상황별 라우팅 근거를 확보하기 위한 것이다.

AS-IS: 벤치마크 없이 사용할 때

  • 공신력 있는 기준이 없어 “사람들이 좋다고 하는 모델”을 그대로 사용
  • “에이전트가 꼭 필요해?” → 한 모델로 전부 처리하려는 경향
  • agent/skill, 토큰/비용 구조를 모른 채 사용 → 품질/시간/비용이 뒤섞여 판단
sequenceDiagram
  autonumber
  participant Dev as Developer
  participant Single as Single Model
  Dev->>Single: 임의 프롬프트로 요청(기준 없음)
  Single-->>Dev: 결과(품질/시간/비용 미기록)
  Note over Dev,Single: 주관/체감으로 판단 → 재현·설득 어려움

TO-BE: 벤치마크 후 사용할 때

  • “평가 축(1~8) + 시간/비용”을 공통 기준으로 확보
  • 작업 단계별 라우팅 예: 계획(A 모델) / 개발·테스트(B 모델) / 검색·참조(C 모델)
  • 실행 로그(벽시계 시간, iteration 수, 토큰/비용)와 산출물 근거(설계안/테스트/커맨드)를 함께 기록 → 재현·설득 가능
sequenceDiagram
  autonumber
  participant Dev as Developer
  participant Plan as 계획용 모델(A)
  participant Exec as 실행용 모델(B)
  participant Search as 검색용 모델(C)
  participant Log as Usage/Cost Logger

  Dev->>Plan: 설계/명세 수립(경계, UseCase 분해, 테스트 전략)
  Plan-->>Dev: 계획 산출물(근거 포함)
  Dev->>Exec: 구현/테스트/리팩터 수행
  Exec-->>Dev: 코드/테스트 결과
  Dev->>Search: 레퍼런스/예시 검색·정리
  par 기록
    Exec->>Log: 시간/iterations/토큰/비용 기록
  and 검증
    Exec->>Exec: 빌드/테스트/린트 커맨드 실행
  end

왜 “평가 축(1~8) + 시간/비용”을 모두 보나

  • 아키텍처/설계: MVVM 경계·DI·의존성 방향이 어긋나면 유지보수 비용 급증
  • 코드스타일/컨벤션: 영어 KDoc, 네이밍, 패키징 일관이 가독성과 PR 속도 좌우
  • 테스트: JUnit5 + Mockito + coroutines-test(runTest + StandardTestDispatcher) 준수가 회귀 방지·flaky 회피의 기반
  • 디버깅: 재현→원인→검증 루프가 명확해야 수정 신뢰도 확보
  • 리팩터 안정성: 최소 변경/영향 범위 통제가 안 되면 숨어있는 결함 유입
  • 요구사항 명세화: 모호함을 질문/AC로 해소하지 않으면 번복·재작업 발생
  • 생산성: 벽시계 시간·iteration 수로 실제 속도·탐색 비용을 계량화
  • 도구 활용: 빌드/린트/테스트 커맨드의 적절한 사용은 품질 가속 장치
  • 비용: 토큰→모델사 단가 매핑으로 금액 추정·ROI 판단 가능

참고 문서(‘기준 축’ 앵커)

메모

  • 참고 문서의 Arean에서 모델 간 비교
  • SWE-bench에서 평가값 참고

Graph View