Codex 모델의 속도와 비용을 비교하다가 평가 방법을 세 번 바꾼 이유

이 글은 X 에서도 보실 수 있습니다. 보러가기

X에서 어떤 게시물을 보고 *“70점 이상 나오는 것을 사용해야겠군”*이라고 가볍게 생각했다가, Codex에서 fast 모드를 쓰다가 normal 모드로 변경했을 때 역체감되는 시간 차이가 너무 심해서 속도의 중요성을 다시 한번 뼈저리게 느끼게 되었습니다.

(아쉽게도 정확히 어떤 포스트였는지는 기억이 나지 않지만요.)

OpenAI가 공개한 코딩 에이전트 그래프를 보면 Sol은 높은 품질을 내지만 API 비용이 비싸고, Terra와 Luna는 상대적으로 저렴해 보였습니다. Luna는 빠르고 경제적인 모델로 소개되지만, 코딩 품질을 얻기 위해 xhigh나 max까지 추론(Reasoning) 단계를 올리면 과연 여전히 빠르고 저렴할까요?

처음 소개될 때는 모델의 속도가 Luna > Terra > Sol 순으로 번개 아이콘이 각각 4개, 3개, 2개로 표시되었던 것으로 기억하는데, 지금은 모두 번개 4개로 표시되어 있습니다.

모델 설명과 그래프만으로는 실제 성능을 판단하기가 어려웠습니다. 그래서 벤치마크 자체를 LLM에 맡겨 보기로 했습니다. 결과적으로 이 실험은 다음 세 단계로 확장되었습니다.

1. 작은 코딩 문제로 비교: 동일한 작은 코딩 문제로 모델의 기본 속도와 비용을 비교했습니다.
2. 실제 과제 원샷(One-shot) 재실행: 작은 문제가 실제 개발을 대표하지 못한다고 판단해, 개발 중인 Myven의 실제 과제들을 다시 실행했습니다.
3. 첫 리뷰 포함 멀티턴(Multi-turn) 측정: 프로젝트가 커질수록 구현과 리뷰가 반복된다는 점을 반영해 첫 리뷰 수정까지 포함한 멀티턴 비용을 측정했습니다.

처음부터 이 세 단계를 계획했던 것은 아니었습니다. 앞 단계의 부족함을 채우려다 보니 자연스럽게 다음 실험이 만들어졌습니다. 그 과정에서 모델별 성능보다 더 중요한 사실도 발견했습니다.

[!NOTE] 코딩 에이전트의 실제 성능은 단순히 모델 하나가 결정하는 것이 아니라 과제, 추론 단계, 테스트, 평가기, 그리고 리뷰 루프가 함께 상호작용한 결과였습니다.

벤치마크 단계별 성공/실패 기준

실험을 진행하기 위해 각 단계마다 명확한 성공과 실패 기준을 정의했습니다.

사실 두 번째 성공 조건은 꽤나 가혹합니다. 그래서 대부분의 결과가 실패로 돌아갔는데, 자세한 내용은 아래에서 다루겠습니다.

1. 첫 번째 실험: 작은 문제로 속도와 비용을 비교하다

첫 실험의 목적은 단순했습니다. 모델과 추론 단계만 바꾸고 나머지 조건을 고정했을 때 어느 조합이 빠르고 저렴한지 확인하고 싶었습니다.

비교 대상 및 설정

• 비교한 설정:
  • Luna xhigh / max
  • Terra xhigh / max
  • Sol high
• 추가로 비교한 설정:
  • Terra high
  • Sol medium

Codex CLI의 codex exec으로 동일한 benchmark-prompt를 직접 실행했습니다. 가능한 한 모든 조건을 동일하게 맞추기 위해 다음을 적용했습니다.

• service_tier="default"로 일반 모드 사용 (fast 또는 priority processing 미사용)
• 사용자 설정과 MCP 영향을 줄인 임시 세션 사용
• 모델과 reasoning effort만 변경
• 설정별 3회 반복
• JSONL 이벤트로 실행 시간과 토큰 수집
• 응답 형식뿐 아니라 생성된 패치의 실제 동작 검사

과제는 TypeScript 동시성 버그를 분석하고 수정하는 비교적 작은 문제였습니다. 모델이 저장소 전체를 탐색하거나 여러 종류의 테스트를 반복하지 않도록 범위를 제한했습니다. 프롬프트 내용은 다음과 같았습니다.

You are participating in a controlled coding-agent benchmark.

Do not use tools. Analyze the TypeScript implementation below. It is intended to provide a TTL cache with single-flight loading, authoritative invalidation, retry after loader failure, and per-caller cancellation that must not cancel the shared load.

type Entry<V> = {
  value?: V;
  expiresAt: number;
  pending?: Promise<V>;
};

export class AsyncCache<V> {
  private readonly entries = new Map<string, Entry<V>>();

  async get(
    key: string,
    loader: (signal?: AbortSignal) => Promise<V>,
    ttlMs = 1_000,
    signal?: AbortSignal,
  ): Promise<V> {
    const current = this.entries.get(key);
    if (current?.value !== undefined && current.expiresAt > Date.now()) {
      return current.value;
    }
    if (current?.pending) return current.pending;

    const pending = loader(signal).then((value) => {
      this.entries.set(key, { value, expiresAt: Date.now() + ttlMs });
      return value;
    });
    this.entries.set(key, {
      value: current?.value,
      expiresAt: current?.expiresAt ?? 0,
      pending,
    });
    return pending;
  }

  invalidate(key: string): void {
    this.entries.delete(key);
  }
}

Return exactly one valid JSON object, with no Markdown fence and no surrounding prose. Keep it under 700 words. Use this shape:

{
  "findings": [
    {"code": "STALE_RESURRECTION|REJECTION_POISON|SHARED_ABORT", "why": "..."}
  ],
  "patch": "a complete replacement implementation as a JSON string",
  "tests": ["exactly four concise test cases"],
  "tradeoff": "one concise sentence"
}

Include each finding code only if the code proves it. The replacement must preserve single-flight loading while ensuring: invalidate during an in-flight load cannot repopulate stale data; a rejected load can be retried; one caller aborting does not cancel the shared loader or other callers; an aborted caller rejects promptly.

작은 문제 실험 결과: Sol medium과 Terra high가 강세

총 21회 실행 결과 중 핵심 비교는 다음과 같았습니다.

이 결과만 보면 결론은 선명했습니다.

• 속도 최우선: Sol medium
• 비용과 속도의 균형: Terra high
• API 비용 최적화: Luna xhigh
• max 단계는 품질 향상 없이 추론 토큰과 대기시간만 크게 증가했습니다.

특히 Sol medium은 Sol high보다 26.4% 빨랐고 16.8% 저렴했습니다. Terra high도 Terra xhigh보다 28.2% 빠르고 15.9% 저렴했습니다. 적어도 이 문제에서는 추론 단계를 굳이 한 단계 더 높이는 것이 품질 향상으로 이어지지 않았습니다.

Luna 또한 예상과 달랐습니다. 모델 단가는 저렴했지만 xhigh와 max에서 추론 시간이 너무 길어졌습니다. Luna max는 Terra xhigh와 비용이 비슷하면서 속도는 약 3배나 느렸습니다.

이 결과만 놓고 보면 Myven 개발 시에도 Sol medium이나 Terra high를 기본값으로 선택하면 될 것 같았습니다. 하지만 실험을 마치고 나니 한 가지 의문이 생겼습니다.

“이 문제가 실제 개발에 비해 너무 간단한 것이 아닐까?”

2. 작은 벤치마크가 부족하다고 느낀 이유

첫 실험은 모델의 추론 속도와 토큰 효율을 비교하는 데 유용했지만, 실제 개발 환경과는 차이가 컸습니다.

작은 벤치마크에서는 모델이 해야 할 일이 문제를 읽고 패치를 만드는 단일 작업에 가깝습니다. 반면 실제 Myven 개발에서는 다음과 같은 작업들이 복합적으로 일어납니다.

• 여러 디렉터리와 기존 구현 탐색
• GitHub Actions와 셸 스크립트 수정
• AWS와 Terraform 운영 계약 확인
• ADR(Architecture Decision Record)과 런북 업데이트
• 기존 테스트와 새 테스트 실행 및 실패 원인 분석
• 코드 리뷰 반영 후 재수정 및 재검증

작은 벤치마크의 전체 시간은 거의 모델의 추론 시간뿐입니다. 하지만 실제 프로젝트에서는 시간 구성이 완전히 다릅니다.

총시간 = 추론 + 저장소 탐색 + 도구 호출 + 테스트 + 실패 후 재작업

프로젝트 규모가 커질수록 뒤쪽 항목들의 가중치가 훨씬 커집니다. Sol medium과 high 사이의 10초 차이는 전체 테스트 빌드에 5분이 걸리는 프로젝트에서는 무의미할 수 있습니다. 반대로 high가 medium이 놓친 운영 계약을 단 한 번에 찾아낸다면, 개별 호출은 조금 느리더라도 전체 작업 시간은 훨씬 더 단축될 수 있습니다.

그래서 단순 문제를 반복하는 대신, 실제 Myven 개발 세션 기록을 분석해 보기로 했습니다. 과제 난이도가 모델 선택과 섞여 공정한 비교가 어려웠기 때문에, 가장 확실한 방법인 **“과거 과제를 동일한 시작점에서 다시 실행하는 방식”**을 택했습니다.

3. 두 번째 실험: 실제 Myven 과제를 다시 실행하다

실제 세션에서 성격이 다른 세 과제를 선정했습니다.

1. 첫 과제 시작: 스테이징 환경을 정해진 시간에 켜고 끄는 GitHub Actions 워크플로를 처음 구현하는 과제.
2. 플랜에서 구현으로 전환: 이미 합의된 계획을 바탕으로 스테이징 환경을 다시 켰을 때 기존 PR 배포 이미지를 복원하고, 관련 런타임 계약을 유지하는 과제.
3. 리뷰 후 구현: AWS IAM 시뮬레이션 응답을 잘못 해석하는 코드 리뷰 지적을 수정하고 테스트를 보강하는 과제.

각 과제의 실제 시작 커밋으로 독립 저장소를 만들고, 아래의 6개 설정에 동일한 과제를 맡겼습니다.

• Terra medium / high / xhigh
• Sol medium / high / xhigh

총 18회의 실행이었습니다. 원본 Myven 워크트리를 건드리지 않도록 모든 실행은 git archive로 만든 격리 복제본에서 수행했으며, 네트워크, AWS, GitHub 접근과 commit·push도 금지했습니다.

성공 기준은 “그럴듯한 코드”가 아니었다

이번에는 평가 기준도 실제 배포에 가깝게 잡았습니다. 다음 조건을 모두 만족해야 PASS로 처리했습니다.

1. Codex CLI가 제한시간 안에 정상 종료될 것
2. 실제 코드 변경이 존재할 것
3. git diff --check를 통과할 것
4. 허용된 파일 범위만 준수할 것
5. 문법 검사와 정적 검사를 통과할 것
6. 요구 기능을 검증하는 테스트를 통과할 것
7. 모델에게 공개하지 않은 (히든) 회귀 테스트를 통과할 것

이 방식은 SWE-bench의 평가 구조와 유사합니다. OpenAI의 SWE-bench Verified처럼, 새 기능을 구현하는 것뿐만 아니라 기존 동작을 깨뜨리지 않았는지 검사하는 회귀 테스트 통과 여부가 핵심이었습니다.

결과는 2/18 이었다

실제 프로젝트 과제에서는 작은 벤치마크와 완전히 다른 결과가 나왔습니다.

18회 중 엄격한 기준을 통과한 것은 단 두 건뿐이었습니다.

• Terra high로 실행한 첫 과제
• Sol xhigh로 실행한 첫 과제

하지만 이 결과를 “구현을 전혀 못 했다”로 해석해서는 안 됩니다.

• 플랜 → 구현 과제: 6개 설정 모두 기존 배포 이미지를 보존하는 핵심 기능을 상당 부분 구현했습니다. 문제는 Lambda 조회 오류를 진짜 초기 상태로 오인해 ECR 이미지로 fallback하면서 기존 plan-on 실패 계약을 깨뜨렸다는 점이었습니다.
• 리뷰 후 구현 과제: 모든 설정이 IAM 시뮬레이션의 리소스별 결과를 읽도록 방향을 수정했지만, 선택적 최상위 필드나 비정상 타입 같은 세세한 경계 조건을 놓쳤습니다.

즉, 한 번의 독립 실행(원샷)만으로 운영 가능한 완벽한 상태에 도달한 비율이 2/18이었습니다.

[!TIP] 평가기 자체의 버그 교정 실험 중 평가기의 문제도 발견했습니다. 일부 구현은 동작이 맞았으나 평가기가 정답 커밋의 step ID나 YAML 표기까지 문자 그대로 동일하게 요구했습니다. (예: on과 "on" 중 하나만 허용) 이에 따라 평가기를 교정(시작 커밋은 실패, 실제 정답 커밋은 통과, 의미가 같은 구현은 통과)하여 신뢰성을 높였습니다. 에이전트를 평가하려면 먼저 평가기를 철저히 검증해야 합니다.

4. 왜 멀티턴 벤치마크가 필요했나

실제 과제 결과가 2/18로 나오자 자연스럽게 의문이 생겼습니다. 실제 개발은 원샷으로 끝나는 경우가 거의 없습니다.

프로젝트가 커질수록 구현 → 테스트 → 리뷰 → 수정 → 재검증의 루프를 반복합니다. 이 과정이 반복될수록 토큰 사용량과 전체 대기시간이 누적되므로, 원샷 결과만으로는 실제 개발 비용을 온전히 설명하기 어렵습니다.

다만 멀티턴을 무제한으로 허용하면 추론 단계가 높은 모델(특히 xhigh)이 첫 리뷰에서 지적하지 않은 경로까지 탐색하고 관련 문제를 추가 발굴하면서 대기시간이 무한정 늘어나는 문제가 있었습니다.

따라서 멀티턴 실험에는 다음과 같은 명확한 제한을 두었습니다.

1. 첫 평가에서 발견된 차단 문제 하나만 피드백으로 전달
2. 다른 파일이나 범위로 확장하지 않고 그 문제만 수정하도록 제한
3. 서브에이전트 사용 금지
4. 수정 후 전체 평가를 단 한 번만 실행 (두 번째 리뷰 기회 없음)

이미 원샷으로 통과한 두 건은 “추가 구현 시간 0”으로 계산했습니다. 이 실험이 측정한 것은 무제한 자율 수정 능력이 아닌, **“첫 요구사항을 구현하고 첫 리뷰의 지적 사항을 고치는 데 필요한 현실적인 총시간과 비용”**입니다.

5. 첫 리뷰까지 허용하자 2/18이 6/18로 늘었다

멀티턴을 적용한 결과는 다음과 같습니다.

• 원샷 성공: 2/18 첫 리뷰 후 성공: 6/18
• 첫 리뷰를 통한 회복률: 25% (4/16)
• 리뷰 수정 평균 추가 시간: 1,664.9초 (약 27.7분)
• 리뷰 수정 평균 추가 비용: $6.49
• 첫 요구 + 리뷰 합산 총시간: 약 2.18시간
• 전체 추정 비용: $29.99

첫 리뷰 한 번이 성공 건수를 3배로 늘려주었습니다. 하지만 리뷰를 준다고 해서 모든 실패 과제가 쉽게 해결되지는 않았습니다.

6. 모델보다 과제의 실패 형태가 더 중요했다

멀티턴 결과를 과제별로 세분화해 보니, 실패의 성격에 따라 극명한 차이를 보였습니다.

1) 명확한 누락 (5/6 성공)

• 내용: 수동 실행 입력을 on/off 선택형으로 제한하거나, 스케줄 실행을 기본 브랜치로 제한하는 등 비교적 위치와 해결 방법이 명확한 과제였습니다.
• 결과: 리뷰 후 최종 5/6 통과.
• 특징: 이 문제는 약 36~53초 이내에 대부분 해결되었습니다. Terra medium, Terra xhigh, Sol high 등이 리뷰 한 번으로 가볍게 성공했습니다. 명확한 누락 유형에는 반드시 높은 추론 단계(xhigh)가 필요하지 않았습니다.

2) 복잡한 fallback 상태 머신 (0/6 성공)

• 내용: 특정 예외 응답(access-denied, throttled 등)에서 실패 처리하고, ECR fallback을 방지하며, 특정 상황에서만 fallback해야 하는 복잡한 조건 분기 과제였습니다.
• 결과: 첫 리뷰 후에도 0/6 전원 실패.
• 특징: 리뷰 턴에만 설정별로 123~261초가 추가로 소모되었습니다. Sol xhigh가 가장 오랜 시간 작업했음에도 통과하지 못했습니다. 이는 단순히 높은 추론 단계가 아닌, 재현 테스트의 부재가 원인이었습니다. 이 경우 상세한 리뷰 텍스트보다 각 AWS 응답을 재현하는 fixture와 실패 테스트를 모델이 직접 실행할 수 있도록 환경을 제공해 주어야 합니다.

3) 좁은 파싱 경계 (Terra xhigh만 성공)

• 내용: 비문자형 데이터를 안전하게 예외 처리하고 최상위 집계 필드의 선택적 속성을 정확히 파싱해야 하는 과제였습니다.
• 결과: Terra xhigh만 유일하게 통과 (77.8초 소요).
• 특징: 다른 모델들은 최상위 집계 필드가 누락될 수 있다는 리뷰를 받았음에도 이를 완벽하게 코드에 녹여내지 못했습니다. xhigh의 정밀한 추론 능력이 빛을 발한 순간이었습니다.

7. 세 단계에서 모델 순위는 계속 바뀌었다

이번 실험에서 가장 흥미로웠던 점은 평가 범위를 넓힐 때마다 유리한 모델이 계속해서 달라졌다는 사실입니다.

graph TD
    A[1단계: 작은 문제] -->|결과| B(Sol medium / Terra high 우세)
    C[2단계: Myven 실제 과제 원샷] -->|결과| D(Terra high / Sol xhigh만 통과)
    E[3단계: 첫 리뷰 포함 멀티턴] -->|결과| F(Terra xhigh 2/3 최종 최다 성공)

1. 작은 문제: Sol medium이 가장 빨랐고, Terra high가 비용-속도 밸런스가 좋았으며, max는 대기시간만 늘렸습니다.
2. 실제 Myven 원샷 과제: Terra high와 Sol xhigh만 성공하고 나머지는 전멸했습니다. 단순 문제에서의 속도 순위가 실제 성공률로 이어지지 않았습니다.
3. 첫 리뷰 포함 멀티턴: Terra xhigh가 2/3로 가장 뛰어난 복구력을 보여주었습니다. Sol xhigh는 가장 비싸고 오래 걸렸으나 추가 복구는 없었습니다.

결국 **“어떤 모델이 가장 좋은가?”**라는 질문에는 단 하나의 정답이 없었습니다. 대신 다음과 같은 질문이 더 유효합니다.

“지금 해결해야 하는 문제가 단순 누락인가, 복잡한 상태 분기인가, 아니면 모델이 눈으로 직접 확인할 수 없는 회귀 조건인가?”

8. Myven에서의 에이전트 모델 운용 원칙

실험 결과를 바탕으로, 현재는 다음과 같은 현실적인 운용 가이드라인을 세워 실천하고 있습니다.

1. 첫 구현은 Terra medium 또는 high로 시작
   • 변경 범위가 작고 명확하다면 Terra medium으로 충분합니다.
   • 여러 파일이나 운영 계약을 다뤄야 한다면 Terra high가 안전한 기본값입니다. 처음부터 무거운 xhigh를 쓸 필요는 없습니다.
2. 단순한 리뷰 피드백은 같은 설정으로 유지
   • 단순 guard 조건 추가, 타입 수정 등은 기존 설정에서도 짧은 시간에 성공적으로 고쳐냅니다. 이럴 때는 모델을 승격하기보다 리뷰 피드백을 구체적이고 좁게 작성해 주는 것이 효율적입니다.
3. 복잡한 파싱이나 상태 분기가 필요할 때만 Terra xhigh로 승격
   • 어려운 경계 조건을 다뤄야 할 때 xhigh가 강점을 보였습니다. 단, 시간 비용이 크기 때문에 첫 리뷰 시 복잡도가 올라갔음이 감지되었을 때 승격시키는 것이 좋습니다.
4. 첫 리뷰 수정 실패 시, 추론 단계를 더 높이지 말 것
   • 실패한 모델에게 계속 “다시 해봐”라고 종용해 봤자 토큰과 시간만 낭비됩니다.
   • 이때 필요한 것은 더 높은 추론 강도가 아니라 **구체적인 피드백(실패 재현 테스트, 입력 fixture, 기대 상태 전이 로그, 실행 가능한 검증 명령 등)**입니다. 문제를 더 작게 쪼개어 전달하는 것이 핵심입니다.
5. Sol 모델의 가격 프리미엄은 과대평가됨
   • Sol은 단순 문제에서는 빨랐지만, 실제 과제 및 멀티턴을 포함했을 때 Sol xhigh는 $8.45로 가장 비싸면서도 성공률은 1/3에 그쳐 비용 대비 효용이 매우 낮았습니다. (단, 이는 Myven AWS 자동화 과제 3건에 한정된 결과입니다.)

9. 벤치마크를 LLM에 위임하며 배운 점

처음에는 LLM에게 벤치마크를 설계하고 수행하도록 맡기면 명확한 해답을 얻을 수 있으리라 기대했습니다. 첫 번째 실험은 속도와 효율 관점에서 명확한 랭킹을 보여주었습니다.

하지만 실제 복잡한 개발에 적용하려 하자 저장소 탐색과 회귀 테스트가 누락되었다는 점을 깨달았고, 실제 과제에 대입하자 원샷 성공률이 곤두박질쳤습니다. 또한 개발은 원샷이 아니라 끊임없는 ’리뷰-수정’의 피드백 루프라는 사실을 다시 상기하며 멀티턴 벤치마크로 확장하게 되었습니다.

결국 벤치마크의 발전 과정은 다음과 같았습니다.

작은 문제의 추론 속도 → 실제 프로젝트의 원샷 완성도 → 첫 리뷰 포함 개발 총비용

이 세 가지 관점을 종합적으로 이해해야만 실제 개발 프로세스에 최적화된 에이전트 모델을 운용할 수 있습니다.

10. 이번 실험의 한계

본 실험에는 명확한 통계적 한계가 존재합니다.

• 표본의 한계: 토큰 비용 절약 및 자원의 한계로 인해 설정 및 과제 조합당 단 1회씩만 실행했습니다. 통계적 신뢰성을 확보하려면 최소 5회 이상 반복 실행하여 확률적 변동을 걸러내야 하지만, 이를 수행하지 못한 점이 가장 큰 한계입니다.
• 도메인의 한계: 선정된 3개의 실제 과제가 모두 Myven의 AWS 인프라 및 운영 자동화 영역에 치우쳐 있어 프론트엔드, 비즈니스 API, 리팩터링 작업에서는 결과가 다를 수 있습니다.
• 멀티턴 깊이의 제한: 실제 개발과 달리 피드백을 단 1턴만 제공했습니다.
• 비용 산정: Codex CLI가 기록한 토큰 기준 추정치이므로 실제 과금 방식과 오차가 있을 수 있습니다.

결론: 모델보다 중요한 것은 피드백 루프

에이전트 코딩 성능은 단지 모델 카드의 벤치마크 점수 하나로 결정되지 않습니다. 실제 성능은 모델, 추론 예산, 저장소 구조, 테스트 코드, 평가기, 그리고 촘촘한 리뷰 루프가 만들어내는 종합적인 생태계의 결과물입니다.

그러나 현재로서는 평가를 완벽하게 자동화하거나 LLM에 전적으로 위임하기가 매우 어렵고, 강력한 루프 하네스(Loop Harness)를 지속해서 구축하는 것조차 까다로운 것이 현실입니다. 이른바 “완전 딸깍”의 영역으로 가는 길은 여전히 저 너머에 있습니다.

원하는 제약과 피드백을 모델이 쉽게 이해하고 직접 테스트해 볼 수 있도록 환경을 잘 만들어 주는 것이 가장 중요합니다.