GPT-5.5 low vs medium vs high vs xhigh: 오픈소스 저장소의 실제 작업 26개에서 본 추론 곡선

• GPT-5.5 Codex를 GraphQL-go-tools의 실제 작업 26개에 low, medium, high, xhigh 설정으로 실행하자, 테스트 통과보다 사람 패치와의 의미적 동등성·코드 리뷰 통과율에서 추론 노력 차이가 더 크게 드러남
• 테스트 통과는 low 21/26, medium 21/26, high 25/26, xhigh 24/26이었지만, 의미적 동등성은 4/26 → 11/26 → 18/26 → 23/26으로 증가했고 코드 리뷰 통과도 3/26 → 5/26 → 10/26 → 18/26으로 상승함
• high는 medium 대비 테스트 통과, 동등성, 리뷰 통과를 모두 개선하면서 평균 비용이 $3.13에서 $4.49로 1.43배 증가해, 이 데이터셋에서 가장 실용적인 기본 설정처럼 보임
• xhigh는 high보다 동등성과 리뷰 품질을 크게 높였지만 평균 비용이 $9.77, 평균 실행 시간이 753.3초로 늘었고, 더 많은 테스트·fixture·expected-output 변경까지 만들어 풋프린트 위험도 증가함
• 추론 노력의 효과는 작업별로 단조롭지 않아 high가 xhigh를 이기거나 높은 설정이 그럴듯하지만 잘못된 구현을 만들기도 했으며, 팀은 전역 벤치마크 대신 자체 하네스와 자체 작업에서 측정해야 함

실험 목적과 평가 방식

• GPT-5.5 Codex를 같은 오픈소스 저장소 작업 26개에 대해 low, medium, high, xhigh 추론 노력 설정으로 각각 실행해, 테스트 통과뿐 아니라 사람이 병합한 PR과의 의미적 동등성 및 리뷰 가능성을 비교함
• 대상 저장소는 Go 기반 GraphQL-go-tools이며, 각 작업은 실제 병합된 PR 또는 커밋에서 파생됨
• 각 작업은 고정된 저장소 스냅샷, 변경 요청 프롬프트, Docker 컨테이너 안에서 패치를 생성하는 한 번의 시도로 구성됨
• Stet은 생성된 패치를 적용하고 격리된 컨테이너에서 작업별 테스트를 실행해 통과 여부를 확인함
• 테스트 이후에는 다음 기준으로 추가 평가함
  • 동등성: 후보 패치가 원래 사람이 만든 패치와 같은 동작 변경을 달성했는지
  • 코드 리뷰 통과: 정확성, 버그 유입 위험, 유지보수성, 엣지 케이스를 고려했을 때 리뷰어가 받아들일 만한지
  • 풋프린트 위험: 사람이 만든 패치와 비교해 에이전트가 추가로 얼마나 많은 코드를 건드렸는지
  • 제작/규율 루브릭: 명확성, 단순성, 일관성, 의도성, 견고성, 지시 준수, 범위 규율, diff 최소성을 평가함
• 모든 모델은 작업당 한 번, 단일 시드로 실행됨
• LLM 판정 모델은 GPT-5.4였고, 판정자는 패치와 작업만 보며 어떤 모델·추론 설정이 만든 패치인지는 보지 않음
• 대표 예시는 수동으로도 확인했지만, 이 작업 세트에 대한 별도 인간 보정은 없어 단일 절대 점수보다 증감 방향을 더 신뢰해야 함
• 실행 세부 사항
  • 모델: GPT-5.5
  • 하네스(harness): Codex 0.128.0
  • 데이터셋: 실제 GraphQL-go-tools 작업 26개
  • 주요 지표: 테스트 통과, 의미적 동등성, 코드 리뷰 통과, 풋프린트 위험, 제작/규율 커스텀 평가, 비용과 실행 시간
• 대화형 차트와 작업별 상세 분석은 https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve에 있음
• AGENTS.md를 개선하는 자동 연구 루프에도 같은 평가를 사용함
  • 에이전트가 저장소용 AGENTS.md 개선안을 만들고, Stet으로 과거 작업을 실행한 뒤, 어디서 좋아지거나 나빠졌는지 찾아 반복함

전체 지표와 해석

• 전체 지표는 추론 노력이 높아질수록 테스트 통과보다 의미적 동등성과 리뷰 통과율에서 더 큰 차이를 보임
• 핵심 결과
  • 테스트 통과: low 21/26, medium 21/26, high 25/26, xhigh 24/26
  • 사람 패치와 동등: low 4/26, medium 11/26, high 18/26, xhigh 23/26
  • 코드 리뷰 통과: low 3/26, medium 5/26, high 10/26, xhigh 18/26
  • 제작/규율 평균: low 2.311, medium 2.604, high 2.736, xhigh 3.071
  • 평균 작업 비용: low $2.65, medium $3.13, high $4.49, xhigh $9.77
  • 평균 에이전트 실행 시간: low 286.9초, medium 411.0초, high 579.0초, xhigh 753.3초
• low와 medium은 테스트 통과가 21/26으로 같지만, 동등성은 4/26에서 11/26으로 오르고, 리뷰 통과는 3/26에서 5/26으로 오름
• high는 medium 대비 테스트 통과가 +15.4%p, 동등성이 +26.9%p, 리뷰 통과가 +19.2%p 증가해 실용적인 개선 폭이 가장 뚜렷함
• xhigh는 high 대비 테스트 통과가 -3.8%p 낮지만, 동등성은 +19.2%p, 리뷰 통과는 +30.8%p 증가함
• 추론 노력은 단순히 테스트 통과율만 바꾸는 것이 아니라, Codex가 만드는 패치의 종류를 바꾸는 것으로 나타남
• 공개 벤치마크는 많은 경우 이진적인 작업 성공 여부를 답하지만, 실제 소프트웨어 엔지니어링에서는 패치를 병합하고 이후 유지보수할 수 있는지도 중요함
• Terminal-Bench는 주로 난해한 코딩 문제 중심이고, SWE-bench verified는 모델이 답을 이미 포함했을 가능성이 있으며, SWE-bench Pro는 유용하지만 일반적인 성격이 강함
• 이 실험의 관심사는 “에이전트가 내 코드베이스에서 사람이 병합한 것과 같은 종류의 변경을 했는가”와 “이 패치를 이후 소유하고 싶을 정도인가”에 있음

low에서 medium: 휴리스틱에서 도메인 모델링으로 이동

• low와 medium은 테스트 통과가 둘 다 21/26으로 같아, 테스트만 보면 동률처럼 보임
• 하지만 medium은 의미적 동등성이 4/26에서 11/26으로 오르고, 제작/규율 평균도 2.311에서 2.604로 상승함
• 이 구간에서는 테스트만 측정하면 추론 노력 차이 대부분을 놓치게 됨
• low는 통과하는 패치에서도 휴리스틱이나 부분 구현에 머무르는 경우가 있었고, medium은 저장소와 도메인 의미를 더 잘 모델링하는 방향으로 바뀜
• PR #1297 예시
  • GraphQL Federation에서 nullable external @requires 의존성을 검증하는 작업임
  • nullable required 필드가 오류와 함께 null로 돌아오면, 그 오염된 엔티티를 의존 downstream fetch에 넘기면 안 됨
  • 작업의 본질은 단순 검증 분기 추가가 아니라, 미묘한 federation 데이터 의존성 규칙을 모델링하는 데 있음
  • low는 테스트를 통과했지만, required-field/error 매칭을 휴리스틱으로 처리하고 구조화된 nullable @requires 메타데이터를 놓쳐 동등하지 않고 리뷰도 통과하지 못함
  • medium은 오염된 객체를 추적하고 downstream fetch 입력을 필터링해 동등성과 리뷰를 통과했으며, 제작/규율 품질이 1.350에서 3.225로 오름
  • high와 xhigh도 같은 품질대에 머물렀기 때문에, 이 작업은 주로 low에서 medium으로 넘어갈 때의 개선을 보여줌

high: 실용적인 기본값에 가까운 지점

• high는 medium보다 테스트 통과, 의미적 동등성, 리뷰 통과를 모두 개선하면서 비용 증가가 크지만 과도하지 않은 수준에 머묾
• high와 medium 비교
  • 테스트 통과: 21/26에서 25/26으로 증가
  • 동등성: 11/26에서 18/26으로 증가
  • 코드 리뷰 통과: 5/26에서 10/26으로 증가
  • 평균 풋프린트 위험: 0.268에서 0.314로 증가
  • 제작/규율 평균: 2.604에서 2.736으로 증가
  • 평균 작업 비용: $3.13에서 $4.49로 증가, 1.43배
  • 평균 실행 시간: 411.0초에서 579.0초로 증가
• high는 추가 토큰이 실제 이득으로 전환되는 지점처럼 보이며, 통합 세부 사항을 맞히는 비율이 더 높아짐
• PR #1209 예시
  • gRPC datasource가 응답 JSON에서 GraphQL alias를 존중하고, 참조된 protobuf message type을 사전에 검증하며, union/interface mutation 경로의 매핑 커버리지를 업데이트해야 하는 작업임
  • low와 medium은 모두 테스트를 통과했지만 동등하지 않고 리뷰도 실패함
  • medium은 alias 직렬화와 누락 message 검증을 상당 부분 처리했지만, createUser mutation 매핑 업데이트를 놓치고 JSONPath에 response-key 의미를 과도하게 실음
  • high는 명시적인 response-key/alias 처리를 도입하고, planning과 JSON marshaling 전반에 alias를 전달해 첫 엄격 통과가 됨
  • high의 커스텀 품질은 3.625로 올랐고, 단순히 코드를 더 추가한 것이 아니라 통합 의무를 정확히 맞춤
  • xhigh도 통과했지만 작업 수준 해석을 개선하지는 않았고, 재생성된 요약 기준 에이전트 실행 시간이 high 314.0s보다 긴 790.7s였음
• PR #1155 예시
  • repeated scalar field 지원, null/invalid message panic 회피, gRPC status code 전파, datasource 비활성화, dynamic client 지원을 포함하는 gRPC datasource hardening 작업임
  • low와 medium은 테스트는 통과했지만 동등하지 않음
  • medium은 견고성을 개선했지만 invalid repeated field를 empty array로 직렬화하고, aliased-root planning 동작을 놓쳤으며, dynamic-client 생명주기 위험이 남음
  • high는 더 안전한 nil/invalid 처리, status-code 전파, disabled-datasource 동작, dynamic client-provider 커버리지로 동등성과 리뷰를 통과함
  • 이 작업에서는 xhigh가 테스트는 통과했지만 disabled datasource 의미와 invalid-list 동작을 잘못 처리해 동등하지 않고 리뷰도 실패하는 역전이 발생함

xhigh: 기본값보다는 품질 모드에 가까움

• xhigh는 high보다 의미적·리뷰 품질을 높였지만, 단순히 설정을 올리면 모든 것이 좋아지는 형태는 아님
• xhigh와 high 비교
  • 테스트 통과: 25/26에서 24/26으로 감소
  • 동등성: 18/26에서 23/26으로 증가
  • 코드 리뷰 통과: 10/26에서 18/26으로 증가
  • 평균 풋프린트 위험: 0.314에서 0.365로 증가
  • 제작/규율 평균: 2.736에서 3.071로 증가
  • 평균 작업 비용: $4.49에서 $9.77로 증가, 2.18배
  • 평균 실행 시간: 579.0초에서 753.3초로 증가
• xhigh는 더 많은 기반을 커버하고, 인간 의도에 더 잘 맞고, 더 완전한 변경을 만드는 경향이 있지만 훨씬 많은 토큰을 사용함
• 리뷰 루브릭은 xhigh 평균 3.365, 중앙값 3.500으로, high의 평균 2.817, 중앙값 2.750보다 높음
• 중앙값도 평균보다 높아, xhigh의 개선이 한두 개의 뛰어난 패치만으로 평균을 끌어올린 결과로 보이지 않음
• xhigh는 의미적으로 더 완전하지만, 사람이 만든 패치에 비해 더 많은 코드를 건드려 풋프린트 위험도 증가함
• xhigh가 26개 작업에서 추가한 줄은 총 13,144줄이며, 구현 코드 5,918줄과 테스트·fixture·expected-output 7,226줄로 나뉨
• high와 비교해 xhigh가 추가한 줄은 2,631줄 더 많고, 그중 2,436줄은 테스트·fixture·expected-output 파일에 있음
• 풋프린트 증가는 거대한 production code를 작성했기 때문만은 아니며, xhigh가 검증과 fixture 커버리지를 더 많이 만든 영향도 큼
• 하지만 테스트와 fixture, expected-output 변경도 리뷰하고 유지보수해야 하는 실제 표면적임
• PR #1076 예시
  • subscription 처리를 재구성해 공유 mutex race condition을 피하는 작업임
  • 요구사항에는 subscription별 직렬화된 write, subscription별 heartbeat 제어, race detector 커버리지, WebSocket close semantics 수정이 포함됨
  • medium은 테스트를 통과했지만 동등하지 않고 리뷰도 실패함
  • high는 동등성과 지시 준수를 달성했지만, 새 worker queue가 전역 subscription event loop를 막을 수 있고, shutdown이 stuck worker 뒤에서 멈출 수 있으며, hung update가 무제한이고, client-level unsubscribe가 여전히 internal subscription을 건너뛰어 리뷰에 실패함
  • xhigh가 첫 엄격 통과였고 커스텀 품질을 3.475로 올림
  • 이 작업은 concurrency-heavy 작업에서 xhigh가 리뷰 위험 정리를 사는 품질 모드로 작동한 가장 좋은 예시임
• PR #1308 예시
  • GraphQL @oneOf input object를 구현하는 작업임
  • built-in directive 추가, introspection 노출, operation literal과 runtime variable 검증, undefined-variable source location 개선이 필요함
  • medium과 high는 테스트를 통과했지만, runtime variable, nullable variable, provided-null payload, introspection shape 관련 중요한 @oneOf 의미를 놓쳐 동등하지 않고 리뷰도 실패함
  • xhigh가 첫 엄격 통과였고 견고성 3.7, 지시 준수 4.0, 커스텀 품질 3.525를 기록함
  • 차이는 표면적인 polish가 아니라 여러 시스템 부분에 걸친 엣지 케이스 커버리지에 있음
• PR #1240 예시
  • GraphQL AST field-selection merging과 inline-fragment selection merging을 하나의 normalization walk로 통합하는 작업임
  • low와 high는 엄격 통과였음
  • xhigh는 의미 평가 기준으로는 동등했지만, prioritized subpass를 유지하고 AbstractFieldNormalizer 순서를 바꾸며 오래된 field-merge registration을 남겨 리뷰에 실패함
  • 더 높은 추론 설정도 더 정교하고 그럴듯한 리팩터링을 만들면서, 테스트와 리뷰어가 중시하는 정확한 실행 동작을 놓칠 수 있음

제작·규율, 비용, 한계와 결론

• 제작·규율 커스텀 평가도 리뷰 루브릭과 비슷하게 추론 노력이 커질수록 전반적으로 상승함
• all-custom 점수는 xhigh 평균 3.071, 중앙값 3.087로, high의 평균 2.736, 중앙값 2.688보다 높음
• 제작과 규율 모두 중앙값도 높아, xhigh가 일부 특출난 예시만 만든 것이 아니라 전반적인 패치 품질을 높인 것으로 해석 가능함
• 평균/중앙값 지표
  • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
  • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
  • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
• 세부 해석
  • low는 견고성과 지시 준수가 약함
  • medium은 테스트 통과 총량을 개선하지 않고도 이 부분을 의미 있게 개선함
  • high는 실질적인 정확성과 견고성을 개선함
  • xhigh는 범위와 diff 규율을 포함해 거의 모든 차원을 개선함
• 비용과 시간
  • low: 평균 비용 $2.65, 중앙값 $1.91, 평균 실행 시간 286.9s, 중앙값 294.6s
  • medium: 평균 비용 $3.13, 중앙값 $2.87, 평균 실행 시간 411.0s, 중앙값 371.8s
  • high: 평균 비용 $4.49, 중앙값 $3.99, 평균 실행 시간 579.0s, 중앙값 572.9s
  • xhigh: 평균 비용 $9.77, 중앙값 $6.39, 평균 실행 시간 753.3s, 중앙값 732.7s
• 비용은 low와 특히 xhigh에서 치우침이 있으며, xhigh 평균 비용은 몇몇 비싼 작업의 영향을 받음
• xhigh는 중앙값 기준으로도 high보다 비싸고 느림
• high는 medium 대비 작업당 약 1.43배 비용이 들고, xhigh는 high 대비 약 2.18배 비용이 듦
• 한계
  • 작업당 단일 시드만 사용함
  • 26개의 실제 GraphQL-go-tools 작업만 포함함
  • LLM 판정자는 GPT-5.4였고, 패치·작업은 보지만 label은 보지 않음
  • 이 작업 세트에 대한 grader calibration은 없음
  • 통계적으로 유의한 보편 결과나 다른 저장소로 그대로 옮겨갈 결과로 볼 수 없음
• 관련 비교
  • Voratiq의 실제 작업 leaderboard도 다른 방법론이지만 비슷한 방향을 보임
  • Voratiq에서 GPT-5.5 xhigh는 1994, GPT-5.5 high는 1807로 +187점, +10.3% 상승함
  • 비용은 $4.23 대 $2.52로 +67.9%, 시간은 11.9m 대 7.8m로 +52.6%임
  • Stet 실험에서는 high → xhigh가 동등성 +19.2%p, 상대 +27.8%, 코드 리뷰 통과 +30.8%p, 상대 +80.0%로 더 크게 나타났고, 제작/규율 aggregate는 +12.2%로 유사함
  • Voratiq는 ongoing work에 대한 preference/selection 스타일 리더보드이고, 이 실험은 하나의 26개 작업 저장소 slice이므로 직접 비교할 수는 없음
• 실용 결론
  • xhigh는 모호하거나, 여러 영역에 걸치거나, 동시성 중심이거나, 리뷰 위험이 큰 작업에 적합함
  • high는 이 데이터셋에서 기본 daily driver로 가장 실용적인 설정처럼 보임
  • medium 이하 설정은 비용이 더 중요하고 작업이 일상적이거나 잘 정의된 경우에 적합함
  • 추론 노력의 효과는 작업별로 매끄럽거나 단조롭지 않으며, high가 xhigh를 이기거나 높은 설정이 그럴듯하지만 잘못된 구현을 만드는 역전도 있음
  • 팀은 전역 벤치마크 기본값을 복사하기보다, 자체 하네스와 자체 작업에서 측정해야 함
• 공개 사항
  • Stet.sh를 만들고 있으며, 이 로컬 평가 도구로 실험을 실행함
  • 제품 버전에서는 코딩 에이전트가 AGENTS.md 개선 같은 후보 변경을 만들고, Stet으로 과거 저장소 작업에 대해 평가함
  • 코딩 에이전트를 많이 쓰는 팀이 high vs xhigh, Codex vs Claude Code, AGENTS.md 업데이트, 위임해도 안전한 작업 판단 같은 구체적 결정을 앞두고 있다면 저장소별 시험을 함께 실행할 팀을 찾고 있음
  • Stet은 LLM 구독을 사용해 완전히 로컬에서 실행되며, 대기자 명단은 https://www.stet.sh/private에 있음