추론 단계를 높이면 코딩 에이전트는 더 좋아질까

추론 단계를 높이면 코딩 에이전트는 더 좋아질까

Terra와 Sol의 medium, high, xhigh 설정을 일반 모드에서 60개 세션으로 비교했다. 시간, 토큰, 추정 비용과 함께 엄격한 검증기 기준의 기능·회귀·수정 범위, fresh-context 첫 리뷰 보완 결과를 측정했다.

코딩 에이전트를 고를 때 흔히 떠올리는 가설이 있다. 추론 단계를 높이면 느리고 비싸지는 대신 결과가 더 좋아질 것이라는 가설이다. 더 강한 모델을 쓰면 복잡한 저장소에서 관련 경로를 더 잘 찾고, 첫 구현이 부족하더라도 리뷰를 통해 완성도가 올라갈 것이라는 기대도 있다.

이번 실험의 결과는 그보다 복잡했다.

균형 표본에서 가장 빨랐던 설정은 terra medium이었다. Terra와 Sol 모두 medium은 xhigh보다 같은 과제·반복 9쌍 모두 빠르고 토큰도 적었다. 이 효율 차이는 견고했다. 반면 품질 순위는 확정할 수 없었다. 과제가 세 개뿐이었고, 엄격한 수정 범위 규칙이 공개 과제에서 허용한 관련 테스트 파일까지 범위 초과로 판정했기 때문이다.

즉, 이번 결과가 강하게 보여준 것은 xhigh의 시간·토큰 비용이다. 높은 추론이 품질을 개선하지 않는지, 또는 불필요한 경로를 더 수정하는지는 보정된 scope 규칙과 더 다양한 과제로 다시 측정해야 한다.

실험에서 확인하고 싶었던 것

이번 벤치마크는 다음 질문에 답하도록 설계했다.

1. 추론 단계를 medium에서 high, xhigh로 높이면 모든 성공 기준을 충족한 과제 완결 결과가 늘어나는가?
2. 상대적으로 빠른 Terra 계열이 실제 저장소 작업에서도 속도와 비용의 이점을 유지하는가?
3. Sol 계열의 추가 시간과 비용이 품질 향상으로 이어지는가?
4. 첫 구현이 실패했을 때, fresh-context 에이전트가 결정적 검증기의 첫 번째 문제만 보완하면 결과가 회복되는가?
5. 높은 추론 단계가 더 많은 경로를 탐색하면서 불필요한 수정까지 만드는가?

실험 전 예상은 다음과 같았다.

• medium은 빠르고 저렴하지만 복잡한 과제에서 누락이 많을 것이다.
• high는 속도와 품질 사이의 균형점이 될 것이다.
• xhigh는 가장 느리고 비싸지만 어려운 과제에서 가장 높은 과제 완결성을 보일 것이다.
• Sol은 Terra보다 느리고 비싸지만 복잡한 통합 과제에서 더 안정적일 것이다.
• fresh-context의 제한된 보완 호출은 일부 미완결 결과를 과제 완결로 바꿀 것이다.

결과적으로 속도와 자원 사용에 대한 예상은 비교적 분명하게 확인됐다. 높은 추론의 품질 향상 효과는 엄격 기준에서 관측되지 않았지만, 결과가 scope 정의에 민감해 효과가 없다고 단정할 수도 없었다. fresh-context 첫 리뷰 보완에서도 엄격 완결 전환은 관측되지 않았다.

공개를 위해 일반화한 세 가지 과제

세 과제는 실제 제품 개발에서 반복적으로 등장하는 유지보수 패턴을 바탕으로 만들었다. 다만 이 글에서는 제품명, 저장소 구조, 파일과 함수 이름, API 주소, 커밋과 실행 식별자, 숨은 검증기의 구현 세부사항을 제거하거나 일반화했다.

이 과제들은 운영 서비스의 현재 결함이나 보안 취약점을 의미하지 않는다. 격리된 저장소 스냅샷과 벤치마크 계약을 이용해 모델의 구현 행동을 측정하기 위한 문제다.

과제 A: 외부 이벤트 식별자 정규화

외부 플랫폼의 이벤트 payload가 이전의 평면 형식과 새로운 중첩 형식을 모두 사용할 수 있는 상황을 가정했다. 구현은 다음 조건을 만족해야 했다.

• 기존 형식과 새로운 형식을 모두 지원한다.
• 두 값이 함께 존재할 때 정해진 우선순위를 지킨다.
• null, 빈 값, 잘못된 자료형에서도 예외를 일으키지 않는다.
• 정규화한 식별자를 저장과 후속 라우팅에서 일관되게 사용한다.
• 특정 대상 선택과 기본 fallback을 정확히 처리한다.
• 관련 없는 payload 필드를 변경하지 않는다.

작은 코드 변경처럼 보이지만, 입력 경계와 저장 경로, 후속 분기, 회귀 테스트를 함께 이해해야 하는 과제다.

과제 B: 비동기 상세 화면의 새로고침 안정성

비동기로 상세 정보를 불러오는 화면에서 최초 로딩, 같은 항목의 새로고침, 오류, 빠른 항목 전환이 겹쳐도 안정적인 UI 상태를 유지해야 했다.

• 최초 요청 중에는 명확하고 접근 가능한 로딩 상태를 보여준다.
• 같은 항목을 새로고침하는 동안 기존 정보를 유지한다.
• 새로고침이 실패해도 기존 정보와 오류 상태를 함께 표현한다.
• 최신 요청의 성공 결과만 화면에 반영한다.
• 늦게 도착한 오래된 응답이 최신 화면을 덮어쓰지 못하게 한다.
• 다른 항목을 선택하면 이전 항목의 정보를 적절히 제거한다.
• 비정상 응답에서도 상태가 깨지지 않는다.

코드 자체보다 기존 상태 모델과 요청 경쟁 조건을 정확히 파악하는 것이 중요한 과제다.

과제 C: 브라우저 읽음 상태 반영

브라우저에서 알림 또는 공지의 읽음 상태를 서버에 안전하게 반영하는 작은 클라이언트를 구현하도록 했다.

• 요청 전에 동일 출처 자격 증명으로 보안 토큰을 얻는다.
• 보안 헤더와 JSON 요청을 정확히 구성한다.
• HTTP 오류, 잘못된 토큰, 네트워크 예외에서는 실패 상태를 유지한다.
• 서버 요청이 성공한 뒤에만 화면의 미확인 표시를 제거한다.
• 브라우저 DOM이 없는 서버 렌더링 환경에서도 안전하게 동작한다.
• 중복 요청을 방지한다.
• 테스트를 위해 주입된 주소와 기능을 임의로 바꾸지 않는다.

이 과제는 코드 양은 작지만 기존 모듈 경계, 브라우저 환경, 보안 요청 순서, UI 반영 시점을 동시에 맞춰야 했다.

과제 완결을 어떻게 판정했나

단순히 모델 프로세스가 정상 종료됐거나 모델이 “완료했다”고 응답한 것은 과제 완결로 보지 않았다. 최종 완결은 다음 다섯 축을 모두 만족한 상태로 정의했다. 이 글의 과제 완결성은 실제 배포나 출시 승인이 아니라, 벤치마크의 엄격한 성공 기준을 한 세션에서 동시에 만족한 비율을 뜻한다.

1. 기능: 사전에 고정한 행동 계약을 만족한다.
2. 회귀: 관련 없는 기존 동작을 깨뜨리지 않는다.
3. 엄격 수정 범위: 검증기에 잠긴 scope allowlist 안에서 수정한다. 이 allowlist는 공개 과제의 합리적 수정 범위와 완전히 일치하지 않아 별도 민감도 분석이 필요하다.
4. 프로세스: 실행과 결과 수집이 정상적으로 끝난다.
5. 검증 무결성: 결정적 검증기가 격리된 환경에서 동일 결과를 재현하며, 후보 코드와 검증 코드가 서로 오염되지 않는다.

이 구분은 결과를 해석할 때 중요하다. 다만 사후 감사에서 scope 구성타당성 문제가 확인됐다. 공개 과제는 관련 구현과 독립 테스트를 허용했지만, 숨은 allowlist는 일부 관련 테스트 파일을 범위 초과로 처리했다. 따라서 이 글의 엄격 미완결 비율은 “코드를 전혀 작성하지 못한 비율”이 아니라 “잠긴 모든 성공 기준을 동시에 만족하지 못한 비율”이며, 그중 scope 실패를 곧바로 불필요한 수정으로 해석해서는 안 된다.

지표와 점수 기준

단일 pass/fail만으로는 기능을 거의 완성한 결과와 요구 자체를 찾지 못한 결과가 모두 같은 실패로 보인다. 이를 피하기 위해 결과를 품질, 완결성, 실행 신뢰성, 효율로 분해했다.

품질과 완결성 지표

각 점수는 해당 조건을 통과한 세션의 비율을 0점에서 100점으로 환산했다. assertion 수가 많은 과제가 점수를 과도하게 지배하지 않도록, 한 세션은 각 축에서 최대 1건으로 계산했다. 이 방식은 과제별 가중치를 맞추지만 all-or-nothing cliff가 있다. 예를 들어 과제 B는 세션 단위 기능 통과가 0/18이었지만 개별 기능 계약은 67/108, 즉 62.0%를 충족했다. 따라서 세션 축 점수와 계약별 coverage를 함께 봐야 한다.

과제 완결성은 기능·회귀·범위 점수의 평균이 아니다. 세 조건이 서로 다른 실행에서 각각 통과해도 완결로 계산하지 않는다. 반드시 같은 세션에서 모든 성공 기준을 동시에 만족해야 한다.

실행 신뢰성 지표

프로세스 정상 종료와 검증 무결성도 각각 0점에서 100점으로 기록했다. 이번 실험에서는 모든 설정이 두 축 모두 100점이었다. 이는 모델 성능의 차이가 아니라, 60개 결과가 도구 오류나 검증기 오염 없이 수집됐다는 근거이므로 모델 순위 점수에는 포함하지 않았다.

효율 지표

효율 점수는 설정별 표본 수가 동일한 초기 균형 표본 n=9에서만 계산했다. 각 축의 최상위 설정을 100점으로 두고 나머지를 상대 점수로 환산했다.

속도 점수 = 가장 빠른 프로토콜 wall-clock 중앙값 / 해당 설정의 중앙값 × 100
토큰 효율 = 가장 적은 9개 세션 총 토큰 / 해당 설정의 총 토큰 × 100
비용 효율 = 가장 낮은 9개 세션 API 환산 비용 / 해당 설정의 API 환산 비용 × 100

시간은 긴 실행 하나의 영향을 줄이기 위해 중앙값을 사용했다. 토큰과 비용은 실제로 누적되는 자원이므로 동일한 9개 세션의 총량을 사용했다.

보조 종합점수

아래 점수는 당시 운영 선택을 위해 계산한 탐색적 예시다. 품질 순위의 근거로 사용하지 않는다.

보조 종합점수 = 기능 25% + 회귀 15% + 범위 15% + 과제 완결성 15%
               + 속도 10% + 토큰 효율 10% + 비용 효율 10%

이 점수는 결과를 확인한 뒤 정한 효용함수이며 모델의 통계적 성능 점수가 아니다. 기능·회귀·범위와 그 교집합인 완결성을 함께 넣어 품질을 일부 중복 계산하고, 토큰과 토큰 단가에서 계산되는 비용도 동시에 반영한다. 가중치에 따라 순위가 바뀌므로 본문 결론에서는 제외하고, 원축과 민감도 분석을 우선한다.

테스트 계획

비교 대상은 다음 여섯 설정이었다.

• Terra: medium, high, xhigh
• Sol: medium, high, xhigh

실행 조건은 모두 동일하게 고정했다.

• Codex CLI의 격리된 exec 실행 사용
• 첫 구현과 보완을 각각 독립적인 --ephemeral 호출로 실행
• 일반 서비스 티어 사용, fast mode 비활성화
• 동시성 1
• 모델 내부 멀티에이전트 비활성화
• 동일한 저장소 스냅샷에서 매 세션을 새로 생성
• 원본 작업 트리와 후보 작업 공간 분리
• 사용자 개인 설정을 배제한 일회성 실행
• 사전에 고정한 기능 및 회귀 계약 사용
• 네트워크 시간이나 임의 대기에 의존하지 않는 결정적 검증기 사용

1단계: 균형 비교

세 과제와 여섯 설정의 모든 조합을 독립적으로 세 번씩 실행했다.

3개 과제 × 6개 설정 × 3회 = 54개 논리 세션

설정마다 정확히 9개 표본을 갖기 때문에 모델과 추론 단계의 속도, 토큰, 비용을 비교할 때는 이 균형 표본을 사용했다.

2단계: 불확실한 셀의 반복 수를 5회로 확장

초기 결과가 섞여 있거나 실패 유형이 반복마다 달랐던 세 개의 과제-설정 조합만 4회차와 5회차를 추가했다.

선택된 3개 셀 × 추가 2회 = 6개 세션
최종 합계 = 60개 논리 세션

확장된 셀은 다음과 같다.

• 과제 A / sol high
• 과제 A / terra xhigh
• 과제 C / terra xhigh

실제 코딩 에이전트 작업은 첫 응답에서 끝나는 경우가 드물다. 사람은 검증 결과를 보고 다음 보완을 요청하고, 자동화된 하네스도 테스트와 리뷰 결과를 바탕으로 루프를 제어해 과제를 끝내려 한다. 따라서 첫 실행의 평균적인 품질뿐 아니라 같은 조건을 반복했을 때 얼마나 안정적으로 완결되는지도 실무적인 품질 판단에 포함해야 한다.

다만 이 실험의 5회 확장은 하나의 세션을 5턴까지 이어간 것이 아니다. 같은 과제·설정 조합을 격리된 독립 세션으로 최대 다섯 번 반복해 비결정성과 재현성을 확인한 것이다. 구현→검증→보완 루프 자체는 뒤의 C1 프로토콜에서 별도로 측정했다. 즉 5회 확장은 자동 완결 루프를 운영할 때 필요한 반복 재현성과 완결 안정성 근거를 보강하지만, 5턴 안에 과제가 수렴하는지를 직접 보여주지는 않는다.

5회 확장은 전체 설정의 표본 수를 불균형하게 만든다. 따라서 설정 전체의 공정한 속도·비용 비교에는 첫 54개 균형 표본을 사용하고, 품질 분석에서는 선택된 동일 과제 셀의 변동성과 반복 완결성을 판단하는 근거로 포함했다.

C1: fresh-context 멀티턴 제한

각 논리 세션은 다음 순서로 진행했다.

1. 모델이 첫 구현을 수행한다.
2. 결정적 검증기가 기능, 회귀, 범위를 평가한다.
3. 첫 구현이 실패하고 공개 가능한 제품 결함이 있으면 가장 우선순위가 높은 첫 finding 하나만 모델에 전달한다.
4. 모델은 그 finding만 보완한다.
5. 전체 검증을 다시 실행하고 세션을 종료한다.

첫 구현과 보완은 각각 격리된 codex exec --ephemeral 호출로 실행했다. 보완 호출은 첫 구현의 저장소 상태를 그대로 인계받지만 이전 대화나 탐색 과정은 인계받지 않고, 결정적 첫 finding 하나만 받는다. 이는 실수가 아니라 장기 컨텍스트 오염과 누적 컨텍스트에 따른 품질 저하를 통제하고, 모든 설정에 동일한 보완 정보만 제공하기 위한 설계다.

따라서 여기서 멀티턴은 같은 대화 스레드를 이어가는 의미가 아니라 작업 수행 → 외부 검증 리뷰 → 발견 사항 보완이라는 워크플로 단계를 뜻한다. 측정값도 “동일 대화의 복구율”이 아니라 수정된 코드 상태를 인계받은 fresh-context 에이전트의 단일-finding 보완 후 엄격 완결 전환율로 해석한다. 장기 컨텍스트 품질을 측정한 것이 아니라 그 영향을 제거한 실험이다.

첫 구현에서 통과하면 보완 호출은 없었다. 범위 초과만 남은 경우에도 별도 보완을 주지 않았다. 모델이 더 많은 문제를 찾아 끝없이 수정하는 것을 방지하고, 첫 구현과 fresh-context 단일-finding 보완까지의 운영 비용을 비교하기 위한 제한이었다.

그 결과 60개 논리 세션에서 실제 Codex 호출은 80회였다.

토큰과 비용 계산 방법

가격은 실험 시작 시점에 고정한 2026년 7월 13일 공식 가격표를 사용했다.

각 Codex 호출을 독립적으로 계산했으며, 한 호출의 입력이 272,000토큰을 초과하면 입력 단가는 2배, 출력 단가는 1.5배를 적용했다. 80회 호출 중 77회가 이 긴 컨텍스트 기준을 넘었다.

토큰 지표는 다음처럼 해석해야 한다.

• input tokens에는 캐시된 입력이 포함된다.
• cached input tokens는 입력 토큰의 부분집합이다.
• output tokens에는 추론 출력 토큰이 포함된다.
• reasoning tokens는 출력 토큰의 부분집합이므로 총 토큰에 다시 더하지 않았다.
• 총 토큰은 input + output으로 계산했다.

비용은 고정 가격표와 CLI가 보고한 토큰 사용량으로 계산한 API 정가 환산 추정치다. Codex 구독 요금이나 쿼터의 실제 청구액이 아니라, CLI가 보고한 토큰에 동일 모델의 공개 API 단가를 적용한 값이다. 실제 청구서와 대조한 금액도 아니다. 또한 Codex CLI가 cache-write 토큰을 별도로 노출하지 않아, 관측되지 않은 cache-write 추가 비용이 있다면 이 추정치에는 포함되지 않는다.

결과 1: 설정 간 공정 비교

먼저 설정마다 n=9인 초기 균형 표본을 보자.

이 표의 시간은 모델 호출뿐 아니라 결정적 검증과 리뷰 승인 대기를 포함한 프로토콜 wall-clock이다. 순수 모델 호출시간 중앙값은 terra medium 231초, terra high 268초, sol medium 335초, sol high 412초, terra xhigh 563초, sol xhigh 789초였다. 순수 모델시간에서도 Terra와 Sol의 medium은 각각 xhigh보다 9/9쌍 모두 빨랐다.

위 그래프는 검증기와 승인 대기를 제외한 순수 모델 실행시간 중앙값이다. 초기 균형 표본 n=9/설정만 사용했으며 낮을수록 좋다. terra medium이 231초로 가장 짧았고, sol xhigh는 789초로 약 3.4배 길었다.

엄격 기준에서는 추론 단계를 높일수록 시간과 토큰은 증가했지만 완결은 증가하지 않았다. 다만 이 완결률은 scope allowlist에 민감하므로 품질 효과를 확정하는 근거로 사용할 수 없다.

• terra medium, terra high, sol medium은 모두 3/9를 통과했다.
• terra medium은 이 셋 중 가장 빠르고 추정 비용도 가장 낮았다.
• terra xhigh는 terra medium보다 중앙값이 약 2.7배 길었지만 통과는 오히려 한 건 적었다.
• sol xhigh는 가장 많은 토큰과 비용을 사용했고 엄격 완결은 없었다.

관련 테스트 파일만 합리적인 수정 범위로 인정하면 결과가 크게 달라진다.

회색 막대는 사전에 고정한 allowlist를 그대로 적용한 엄격 완결률이고, 초록 막대는 구현과 직접 관련된 테스트 파일까지 허용한 민감도 분석이다. 초록 막대를 재실행에서 관측한 별도의 성공률이나 공식 통과율로 읽으면 안 된다. 같은 산출물을 어떤 scope 규칙으로 판정하느냐에 따라 완결률이 얼마나 바뀌는지 보여주는 보조 지표다.

이 민감도 분석은 엄격 완결 순위가 모델 행동뿐 아니라 평가 범위 정의에 크게 좌우됐음을 보여준다. 따라서 terra medium은 이 표본의 속도·비용 기본값 후보로는 지지되지만 품질까지 가장 좋은 설정이라고 결론 내릴 수 없다. 또한 54개 세션은 3개 고정 과제를 세 번 반복한 것이므로 독립 과제 다양성은 세 개뿐이다.

설정별 다축 점수

같은 균형 표본을 기능, 회귀, 범위, 완결성, 효율로 나누면 결과의 의미가 달라진다.

sol xhigh는 과제를 전혀 수행하지 못한 설정이 아니었다. 기능은 66.7점, 회귀는 100점이었다. 엄격 allowlist의 범위 점수가 33.3점이어서 완결성은 0점이 됐지만, 관련 테스트를 허용한 민감도 분석에서는 6/9로 바뀐다. sol high도 회귀 안전성은 높았으며 보정 기준에서는 6/9였다.

terra medium은 효율 세 축에서 가장 좋은 관측값을 보였다. 그러나 다축 점수에도 문제가 있는 scope 축과 그 교집합인 완결성이 포함되므로, 이를 품질·효율 종합 우승으로 읽지 않는다.

과제별 다축 점수

설정보다 과제 유형의 영향이 컸다는 사실은 과제별 점수에서 더 선명하다.

과제 B와 C는 세션 단위 완결표에서 모두 0점이지만 원인은 달랐다. 과제 B는 모든 세션이 전체 기능 계약을 동시에 충족하지 못했지만 개별 기능 계약은 67/108(62.0%) 통과했다. 과제 C는 거의 모든 세션이 기능과 회귀 검증을 통과했고, 엄격 scope 실패 20/20은 모두 관련 테스트 파일 하나가 allowlist 밖이었던 사례였다. 이 결과는 세션 축 점수뿐 아니라 계약별 coverage와 scope 민감도를 함께 보고해야 한다는 근거다.

결과 2: 5회 확장에서 나타난 품질 변동성

선택된 세 셀의 5회 확장 결과는 다음과 같다.

엄격 기준에서 과제 A의 sol high와 terra xhigh는 모두 4/5였다. 두 설정 모두 기능과 회귀 검증은 5/5 통과했고, 관련 통합 테스트 파일이 allowlist 밖이어서 각각 한 번씩 scope 실패가 됐다. 관련 테스트를 허용하면 둘 다 5/5다.

같은 과제와 같은 성공 횟수 안에서는 terra xhigh가 더 유리했다.

• 중앙값은 약 95초 짧았다.
• 사용 토큰은 약 28% 적었다.
• 5회 누적 추정 비용은 절반보다 조금 낮았다.
• 관측된 IQR도 훨씬 작았다.

다만 표본이 다섯 개뿐이다. 4/5 과제 완결성의 Jeffreys 95% 구간은 약 [0.371, 0.977]로 매우 넓다. 따라서 이 결과는 해당 과제에서의 관측이지, 두 모델의 일반적인 우열을 확정하는 근거가 아니다.

5회 확장 결과를 다축 점수로 다시 보면 다음과 같다.

과제 A의 두 설정은 품질 프로파일이 동일하다. 이때는 terra xhigh가 더 짧은 시간과 적은 토큰·비용을 사용했다는 효율 차이가 실제 선택 기준이 된다.

과제 C의 terra xhigh는 엄격 완결성 0점, 기능 60점, 회귀 100점이었다. 엄격 실패 서명은 scope 세 번과 기능 미충족 두 번으로 나뉘었지만, scope 세 건은 모두 관련 테스트 파일 때문이었다. 이를 허용한 민감도 기준에서는 3/5로 바뀐다. randomness가 기능 계약 충족에는 영향을 줬지만, 엄격 완결 0/5만으로 범위 통제 능력을 판단할 수는 없다.

5회 확장까지 품질 판단에 포함하면 과제 A에서는 sol high와 terra xhigh가 같은 기능·회귀·보정 완결 품질을 보였고, 과제 C에서는 terra xhigh의 기능 충족이 반복에 따라 흔들렸다. 따라서 이번 과제군에서 높은 추론의 일관된 품질 우위는 확인되지 않았다. 이 결론은 선택된 세 셀의 반복 신뢰성에 관한 것이며, 모든 설정을 5회씩 비교한 일반 품질 순위는 아니다.

결과 3: 전체 토큰과 비용

5회 확장을 포함한 실험 전체의 사용량은 다음과 같다.

입력 토큰의 약 93.35%가 캐시 읽기로 기록됐다. 캐시가 없었다면 대형 저장소의 반복적인 컨텍스트 로딩 비용은 훨씬 커졌을 것이다. 반대로 캐시 비율이 높았는데도 총 추정 비용이 약 195달러에 이른 것은 세 가지 이유가 겹쳤기 때문이다.

1. 대부분의 호출이 긴 컨텍스트 구간을 넘었다.
2. 높은 추론 단계에서 입력과 출력 토큰이 함께 증가했다.
3. 첫 구현 이후 리뷰 보완이 필요한 세션은 추가 호출을 사용했다.

초기 균형 표본 54개만 보면 총 120.03M 토큰과 약 $179.12가 사용됐다. 추가 6개 세션은 약 11.74M 토큰과 $15.84를 더했다.

전체 평균은 세션당 약 $3.25였다. 엄격 완결 17건으로 나눈 단순 환산 비용은 약 $11.47이지만, scope 민감도에 따라 분모가 바뀌므로 모델 구매 의사결정에 사용할 생산성 지표로 보지 않는다.

5회 확장까지 포함해도 높은 추론의 품질 우위는 확인되지 않았다

초기 균형 표본뿐 아니라 5회 확장까지 포함하면 이번 과제군에서 높은 추론이 더 높은 품질을 냈다는 증거는 없다. 과제 A에서 sol high와 terra xhigh는 기능·회귀 5/5, 관련 테스트 허용 완결 5/5로 같았다. 과제 C의 terra xhigh는 기능과 관련 테스트 허용 완결이 3/5로 반복에 따라 흔들렸다. 낮은 추론 설정보다 xhigh가 더 안정적이거나 완성도가 높다는 관측은 나오지 않았다.

다만 5회 확장은 초기 결과가 불확실했던 세 셀만 선택했으며, 나머지 설정은 3회에 머물렀다. 결과를 확인한 뒤 확장 대상을 고른 불균형 표본이므로 전체 설정의 누적 완결률을 직접 비교하거나 “높은 추론은 일반적으로 품질 효과가 없다”고 확정할 수는 없다.

엄격 기준에서는 기능 정답과 과제 완결성도 분리됐다. 이 차이의 상당 부분은 모델 행동이 아니라 scope 규칙에서 발생했다.

과제 A의 sol xhigh는 기능 검증을 3/3 통과했지만 엄격 scope는 0/3이었다. 과제 C의 scope 실패 20/20도 모두 관련 테스트 파일 하나 때문이었다. 관련 테스트를 허용하면 sol xhigh의 초기 완결은 0/9에서 6/9로 바뀐다. 따라서 이를 “높은 추론이 불필요한 경로를 더 수정했다”는 증거로 사용할 수 없다.

일반적으로 높은 추론 단계가 더 많은 경로를 탐색하면서 패치를 확대할 가능성은 있다. 하지만 이번 데이터는 그 가설을 검증하지 못했다. 이를 확인하려면 공개 프롬프트와 일치하는 scope 규칙 아래에서 다음을 별도로 측정해야 한다.

• 변경 파일 수와 diff 크기
• 요구와 직접 관련 없는 파일의 수정 여부
• 새 테스트와 기존 테스트 보강의 구분
• 기능 계약 coverage와 실제 회귀
• 블라인드 사람 리뷰의 최소 패치 판정

따라서 이번 실험 내부의 결론은 5회 확장까지 포함해도 높은 추론의 품질 우위가 관측되지 않았다는 것이다. 일반적인 품질 효과의 유무와 범위 통제 효과는 모든 설정을 같은 횟수로 반복하고 scope를 보정한 실험에서 다시 확인해야 한다.

Fresh-context에서 첫 리뷰 한 건만 보완하면 효과가 있었나

이번 프로토콜에서는 첫 구현의 파일 상태를 보존한 뒤, 별도의 ephemeral 호출에 결정적 검증기의 첫 finding 하나만 전달했다. 총 20개 세션이 이 fresh-context 보완을 사용했지만, 엄격 기준에서 완결로 전환된 세션은 0건이었다. 이 값은 fresh-context 단일-finding 보완의 엄격 완결 전환율 0/20을 뜻한다.

이 결과는 같은 대화 스레드에서 리뷰를 받은 모델의 복구 능력을 측정하지 않는다. --ephemeral로 장기 컨텍스트 영향을 의도적으로 제거했기 때문이다. 또한 20건 중 18건은 같은 과제 B의 동일한 첫 finding, 2건은 과제 C의 동일한 finding이어서 다양한 리뷰 문제 20건도 아니다. 따라서 “모델은 리뷰를 반영하지 못한다”거나 “멀티턴 리뷰가 일반적으로 효과 없다”고 일반화할 수 없다.

다만 실무적인 교훈은 있다.

• 리뷰 finding은 독립적인지, 선후 관계가 있는지 구분해야 한다.
• 첫 finding만 수정하게 할 때는 전체 회귀 검증을 반드시 다시 실행해야 한다.
• 복잡한 상태 관리나 기존 모듈 경계 탐색 문제는 fresh-context 단일 보완보다 계획 단계의 품질이 더 중요할 수 있다.
• 보완 횟수를 늘리기 전에 검증기가 실제 제품 결함과 범위 문제를 정확히 분리하는지 확인해야 한다.

분석 방법과 해석 원칙

속도는 평균보다 중앙값을 우선했고, 반복 간 변동은 IQR로 확인했다. 작은 성공 표본의 불확실성을 숨기지 않기 위해 5회 셀에는 Jeffreys 95% 구간을 사용했다.

또한 다음 원칙을 지켰다.

• 설정 간 비교는 표본 수가 같은 초기 n=9 결과를 사용한다.
• 5회 확장 결과는 선택된 동일 과제 셀 안에서 품질 변동성과 반복 완결성을 판단하는 데 사용한다.
• 기능, 회귀, 범위, 프로세스 실패를 하나의 “모델 실패”로 뭉개지 않는다.
• 토큰과 비용은 호출별로 계산한 뒤 합산한다.
• 추론 토큰을 출력 토큰과 중복 합산하지 않는다.
• 전체 과제 완결성을 모델의 보편적인 코딩 능력 점수로 해석하지 않는다.
• 엄격 scope 기준과 관련 테스트 허용 기준의 민감도 차이를 함께 제시한다.

특히 5회 확장 이후에는 sol high와 terra xhigh의 전체 표본 수가 다른 설정보다 많다. 이 상태의 누적 비용이나 성공 건수를 그대로 설정 순위로 사용하면 선택 편향이 생긴다.

실무에서 어떻게 사용할 것인가

이번 데이터로 직접 지지되는 운영 전략은 시간·토큰을 중시할 때 처음부터 xhigh를 선택하지 않는 것이다. 품질까지 포함한 기본값은 보정된 scope 실험 전에는 확정할 수 없다.

가성비 그래프는 초기 균형 표본의 설정별 API 정가 환산 추정비용을 관련 테스트 허용 기준의 완결 건수로 나눈 값이다. terra medium은 보정 완결 1건당 약 $2.05, sol xhigh는 약 $10.20이었다. 낮을수록 비용 효율이 좋지만, 분모가 엄격 완결이 아니라 scope 민감도 보정 완결이며 실제 Codex 구독 청구액도 아니므로 절대적인 가격표가 아니라 설정 간 의사결정용 지표로만 사용한다.

작고 경계가 명확한 유지보수

terra medium은 이 fixture suite의 속도·비용 기본값 후보로 둘 만하다. 프로토콜 wall-clock과 순수 모델시간에서 가장 빨랐고 토큰과 비용도 가장 적었다. 다만 엄격 완결성과 보조 종합점수는 scope 정의에 민감하므로 품질 우위의 근거로 사용하지 않는다.

탐색이 필요하지만 수정 범위가 명확한 과제

terra high를 사용할 수 있지만 medium보다 품질이 높거나 더 안전하다는 근거는 아직 없다. medium 대비 추가 시간과 토큰이 필요한지 과제 특성으로 판단해야 한다.

저장소 전반의 경로 탐색이 필요한 과제

xhigh는 medium보다 일관되게 느리고 토큰을 더 사용했다. 사용할 때 범위 제한을 두는 것은 일반적인 운영 안전장치로 유용하지만, 이번 실험이 xhigh의 범위 초과 성향을 입증한 것은 아니다.

• 먼저 조사와 계획만 수행한다.
• 수정할 파일과 책임 범위를 확정한다.
• 발견한 부수 문제는 구현하지 말고 별도 목록으로 남긴다.
• 변경 후 기능뿐 아니라 범위 검증을 실행한다.

높은 추론을 기본값으로 쓰기보다, medium 또는 high에서 계획을 세운 뒤 정말 필요한 과제에만 높은 추론을 적용하는 편이 시간과 비용을 통제하기 쉽다.

검증된 운영 원칙과 다음 실험 가설

이번 결과를 실제 프로젝트의 운영 방식으로 옮길 때는 확인된 결론과 아직 검증하지 않은 가설을 구분해야 한다.

따라서 현재 가장 합리적인 운영 가설은 첫 구현을 medium으로 시작해 비용을 통제하고, 검증 결과에 따라 보완 설정을 선택적으로 승격하는 방식이다. 특히 terra medium → sol high는 속도와 회귀 안전성을 결합할 후보지만, 이를 권장 기본값으로 만들려면 같은 첫 구현 결과를 terra medium과 sol high가 각각 보완하는 교차 설정 실험이 필요하다.

한계

이 실험에는 분명한 한계가 있다.

• 세 개의 고정 과제만 사용했다.
• 과제별 난이도와 통합 범위가 같지 않았다.
• 선택된 세 셀만 5회로 확장했고 나머지는 3회였다.
• 모델 출력에는 비결정성이 있으므로 같은 설정도 다른 경로를 선택할 수 있다.
• 비용은 고정 가격표 기반 추정치이며 실제 청구액이 아니다.
• 캐시 쓰기 비용은 CLI 관측 범위 밖이다.
• C1은 첫 구현의 파일 상태만 인계하는 fresh-context 보완이며, 동일 대화의 장기 컨텍스트 효과는 측정하지 않았다.
• C1 보완 20건 중 18건이 같은 과제와 같은 첫 finding에 집중됐다.
• 공개 과제와 숨은 scope allowlist가 일부 관련 테스트 파일에서 충돌했다.
• 세션 단위 기능 점수는 계약의 부분 충족을 숨길 수 있다.
• 세 과제가 전체 제품 개발의 계획, 설계, 마이그레이션, 운영 대응을 모두 대표하지 않는다.

따라서 이 결과는 특정 fixture suite에서의 행동 비교다. 모델의 절대 점수나 모든 코딩 작업에 적용되는 순위표로 읽어서는 안 된다.

가격 출처

• GPT-5.6 Terra 모델 문서
• GPT-5.6 Sol 모델 문서
• GPT-5.6 소개

가격과 계산 규칙은 실험 시작 시 고정한 2026년 7월 13일 스냅샷을 사용했다.

요약

• 일반 모드에서 Terra와 Sol의 medium, high, xhigh를 비교했다.
• 3개 과제와 6개 설정의 균형 표본을 독립 세션으로 세 번 반복한 뒤, 선택된 세 셀을 독립 세션 5회로 확장해 60개 논리 세션과 80회 Codex 호출을 수집했다.
• 기능, 회귀, 엄격 범위, 엄격 완결성, 속도, 토큰, 비용을 분리했으며 계약별 coverage와 scope 민감도도 추가로 검토했다.
• terra medium은 프로토콜 wall-clock과 순수 모델시간에서 가장 빨랐고 추정 비용도 가장 낮았다.
• Terra와 Sol 모두 medium은 xhigh보다 같은 과제·반복 9/9쌍 모두 빠르고 토큰도 적었다.
• 엄격 완결은 설정별 0~3/9였지만 관련 테스트를 허용하면 대부분 6/9로 바뀌어, 품질 순위는 scope 정의에 민감했다.
• 과제 B는 세션 기능 통과 0/18이지만 개별 기능 계약은 67/108(62.0%) 충족했다.
• 보조 종합점수는 상관된 축을 중복 반영하는 사후 효용함수이므로 모델 품질 순위로 사용하지 않는다.
• 과제 A에서 sol high와 terra xhigh는 모두 4/5였지만, terra xhigh가 더 빠르고 토큰과 추정 비용도 적었다.
• 5회 확장까지 포함해도 이번 과제군에서 높은 추론의 일관된 품질 우위는 확인되지 않았다. 다만 선택된 세 셀만 확장했으므로 일반적인 품질 효과가 없다고 확정할 수는 없다.
• 전체 사용량은 131.78M 토큰, 추정 비용 약 $194.96, 프로토콜 wall-clock 합계 약 8시간 23분이었다.
• C1은 파일 상태를 인계하는 fresh-context 2단계 보완이다. 이 제한 프로토콜의 엄격 완결 전환은 0/20이었지만 same-thread 대화 복구율을 뜻하지 않는다.
• 실무에서는 시간·토큰을 중시하면 medium부터 시작할 근거가 있다. 일반 품질 기본값은 scope를 보정한 더 다양한 과제로 다시 측정해야 한다.
• terra medium → sol high처럼 첫 구현과 보완 설정을 다르게 사용하는 승격 전략은 유망한 후속 가설이지만 이번 실험에서는 측정하지 않았다.

맺으며

이 벤치마크는 최종이 아니고 마지막 가설과 멀티턴으로 작업 완료율까지 체크해야 마무리 될 것이다. 그럼에도 불구하고 이 글을 적는 이유는 에이전트 사용은 평가가 필수이고 방법을 계속 보완해 나가는 작업이 필요하다는 것을 강조하기 위함이다.