본문으로 건너뛰기
CoderRed Blog

Article

GPT-6 Astra, 순정 Codex와 OMP 중 어디서 더 잘할까

저는 요즘 순정 Codex와 오마이파이(OMP)를 병행해서 씁니다. OMP에서는 파일 탐색, LSP, 디버거, 브라우저, 서브에이전트까지 같은 세션에서 쓸 수 있어요. OMP를 처음 소개했던 글에서도 터미널 안에 개발 도구가 한꺼번에 들어온 점이 마음에 든다고 썼습니다.

그런데 GPT-6 Astra가 나온 뒤에는 조금 다른 생각이 들었습니다. AGENTS.md나 SKILL.md에 쌓아둔 지시를 정리하라는 이야기가 나오고, 모델이 좋아질수록 예전의 세세한 규칙이 오히려 방해가 될 수 있다는 설명도 눈에 들어왔어요.

“모델은 더 똑똑해졌는데, 주변 도구와 지시는 계속 늘려도 되는 걸까?”

OMP는 기능이 많아서 좋지만 그만큼 복잡하게 느껴지기도 해요. 아스트라가 토큰을 많이 먹는 건 이미 체감하고 있습니다. 그래서 궁금했습니다. 같은 아스트라를 쓸 때 OMP가 순정 Codex보다 일을 더 잘해주느냐.

두 도구에 같은 작업을 돌려 벤치마크를 하지는 않았습니다. 둘을 병행하면서 생긴 궁금증을 풀려고 자료와 사용자 후기를 찾아봤어요. 승자는 고르지 못했습니다. 그래도 확인된 사실과 기능 설명만으로는 알 수 없는 부분을 나눠볼 수는 있었습니다.

ARC-AGI-3 게임의 조작을 탐색하며 다음 행동을 메모하는 아스트라
아스트라가 게임을 탐색하며 남기는 메모
ARC Prize가 공개한 s5i5 시연의 한 장면입니다. 게임 화면 옆에 아스트라의 행동 메모가 표시됩니다. (이미지: ARC Prize 공식 GIF에서 발췌)

지시는 줄이라는데 하네스는 중요하다고 합니다

하네스는 모델을 둘러싼 실행 환경입니다. 코딩 에이전트에서는 도구 호출과 파일 편집, 명령 실행을 맡고 대화 상태와 컨텍스트 압축도 관리하죠. 이 글에서는 Codex를 실행 도구, Astra를 그 안에서 쓰는 모델로 구분합니다.

OpenAI의 아스트라 가이드는 기존 스킬과 AGENTS.md의 행동 지시를 점검하라고 권합니다. 지시를 더 충실히 따르는 모델에서는 서로 충돌하는 규칙이 작업을 중간에 멈추게 할 수 있다는 설명도 있어요.

예전 모델이 반복해서 실수하던 부분을 막으려고 규칙을 하나씩 붙여왔는데, 새 모델에서도 그 규칙이 모두 필요한지는 다시 볼 만합니다. “끝날 때까지 계속해라"와 “이 단계에서는 반드시 확인을 받아라"가 함께 쌓여 있으면 어떤 행동이 나올지도 고민이고요.

도구나 실행 환경의 역할까지 없어지는지는 별개의 문제였어요. The New Stack의 아스트라 하네스 분석 기사가 눈에 들어온 이유도 여기에 있습니다. 같은 모델을 같은 추론 강도로 실행해도 하네스에 따라 점수와 비용이 크게 달라졌다는 내용이었어요.

같은 아스트라도 기억을 이어주는 방식에 따라 달랐어요

기사의 원자료는 9월 3일 ARC Prize가 공개한 GPT-6 Astra의 ARC-AGI-3 평가입니다. 낯선 게임 환경을 탐색하고 규칙을 알아낸 뒤 목표를 달성하는 평가로, 일반적인 코드 수정 벤치마크와는 작업 종류가 다릅니다.

비교한 하네스는 두 가지였습니다.

  • Standard: 모델이 직접 남긴 메모를 다음 단계로 가져갑니다.
  • Provider Adapter: 요청 사이에 암호화된 내부 추론 상태를 보존하고, 긴 대화는 제공사의 compaction으로 관리합니다.

같은 추론 강도끼리 보면 차이가 더 잘 보입니다.

추론 강도StandardProvider Adapter
medium38.6%98.4%
high54.8%99.9%
max62.7%98.6%

high에서는 54.8%에서 99.9%로, 점수 비율로 약 1.82배입니다. 기사에 나온 대표 수치인 62.7%와 99.9%는 각 하네스의 최고 기록이며, 각각 max와 high 설정에서 나왔습니다.

ARC Prize가 공개한 GPT-6 Astra의 Standard 및 Provider Adapter 하네스 평가 결과
같은 아스트라에서도 하네스에 따라 달라진 평가 결과
ARC Prize의 ARC-AGI-3 결과입니다. OMP와 Codex의 제품 비교가 아니라, Standard와 Provider Adapter 실행 조건의 비교입니다. (이미지: ARC Prize)

비용과 시간도 줄었습니다. Public·Semi-Private에서 두 하네스가 모두 해결한 167개 게임·추론 강도 조합을 비교하면, 기록된 실행 시간을 합산했을 때 Provider Adapter가 약 3.66배 빨랐습니다. 총 토큰도 49% 적게 썼고요.

저는 이 결과가 흥미로웠어요. 같은 모델이라도 이미 해낸 추론을 다음 요청에서 활용할 수 있도록 연결하는 일이 성능을 바꿨으니까요.

여기서 말하는 기억은 작업 중에 쌓은 추론 상태를 다음 요청으로 이어주는 기능입니다. AGENTS.md에 프로젝트 설명을 더 많이 쓰는 것과는 다르죠. 행동 지시는 덜어내되, 추론 상태를 이어주는 실행 기능은 더 잘 갖출 수 있습니다.

PRO-LONG 하네스에서 maze_solver.py를 활용해 미로를 푸는 아스트라
외부 도구를 활용하는 아스트라
별도 실험인 PRO-LONG에서는 아스트라가 직접 만든 maze_solver.py로 미로를 풀었습니다. 위의 Standard·Provider Adapter 점수와는 실행 조건이 다릅니다. (이미지: ARC Prize 공식 GIF에서 발췌)

다만 이 표의 Standard를 OMP, Provider Adapter를 Codex에 대입할 수는 없습니다. 두 제품을 비교한 실험은 따로 필요합니다.

현재 OMP는 그 연결을 하고 있었습니다

제 환경에 설치된 OMP는 18.1.15였고, 기본 모델은 openai-codex/gpt-6-astra:xhigh였습니다. 실제 적용 설정을 조회한 뒤 같은 릴리스의 소스를 따라가 봤습니다.

확인한 부분OMP 18.1.15의 구현·설정
모델 연결Codex Responses 경로 사용
추론 상태 요청reasoning.encrypted_content 요청
응답 보관원래 reasoning 항목과 제공사 네이티브 출력 저장
다음 요청동일 모델·제공사·API에서 네이티브 항목 재전달
긴 대화 압축OpenAI 네이티브 압축 우선, 결과를 저장해 문맥 재구성에 사용

압축 방식은 remote, snapcompact 순서로 설정돼 있습니다. 먼저 네이티브 V2 압축을 시도합니다. 지원되지 않거나 실패하면 V1 /responses/compact 경로를 시도하고, 네이티브 방식이 실패한 뒤에는 다음 방법인 snapcompact로 넘어갈 수 있습니다.

snapcompact는 대화 내용을 이미지로 보관합니다. 암호화된 추론 상태를 담는 OpenAI 네이티브 압축과는 보존 방식이 다릅니다. 또 OMP가 네이티브 추론을 재전달하려면 모델 ID까지 일치해야 합니다. 같은 대화에서 모델을 바꾸면 연속성을 유지하는 조건도 달라지는 셈이죠.

OMP는 아스트라의 응답 텍스트뿐 아니라 추론 상태도 보관하고 있었습니다. 매번 생각을 버리는 구조가 아니라, 앞서 살펴본 핵심 기능이 구현돼 있었어요. 다만 제가 확인한 것은 버전·설정과 코드까지입니다. 서버 측 동작이나 압축 전후의 작업 품질은 따로 측정하지 않았습니다.

그런데 여기까지 알아봐도 제 질문은 그대로 남았습니다.

지원한다는 설명과 더 잘한다는 경험은 다르니까요.

아스트라를 다른 하네스에서 써본 사람들은 어땠을까요?

그래서 아스트라 출시 이후의 후기를 찾아봤습니다. 이전 GPT 모델 비교는 제외했고, 실제 댓글에서 어떤 모델을 썼는지 확인했습니다. 비슷한 제목으로 검색된 Codex·OpenCode 시간 비교도 있었지만, 본문에서는 Sol을 사용했기에 이 글의 비교 근거에서 뺐습니다.

OMP·Pi·Codex 모두 토큰을 많이 먹었다는 후기

9월 7일 r/PiCodingAgent의 u/Sup3rMo 댓글에는 아스트라를 세 하네스에서 써봤다는 말이 나옵니다.

“I tried astra with different harness setups: omp, pi, codex”

이 사용자는 OMP, Pi, Codex 어디서든 토큰 소모가 크다며 모델 자체의 특성으로 봤습니다. OMP를 직접 써본 이야기라 반가웠어요. 다만 주로 토큰 소모에 관한 체감이었고, 코드 품질이나 완료 시간을 나란히 비교한 수치는 없었습니다.

저도 아스트라의 사용량은 체감하고 있습니다. 하지만 어디서든 많이 쓴다는 것만으로는, OMP에서 쓴 토큰이 더 좋은 결과로 돌아오는지 알 수 없었습니다.

순정 Codex에서 더 잘한다고 느끼는 사람

r/OpenaiCodex의 u/command-shift는 아스트라가 Codex 자체 하네스 밖에서는 그만큼 잘하지 못하는 것 같다고 했습니다. 본인은 순정 환경에서 아스트라 인스턴스 4~5개를 실행하고 추론 강도를 조절해 쓴다고 설명했어요.

같은 댓글에서 떠올린 벤치마크의 위치를 기억하지 못한다고 했고, 직접 비교 수치도 제시하지 않았습니다. 순정 환경을 선호하는 사용자 의견으로 참고했습니다.

같은 대화에서 u/Alternative-Taro5701은 반대 선택을 했습니다. Codex의 플러그인·도구 문제를 겪고 Pi로 옮겨, 아스트라를 상위 조정자로 두고 여러 모델에 작업을 배분하는 구성을 만드는 중이라고 했어요. 도구의 제약 때문에 하네스를 바꾼 사례로, 이전 후 성능이 좋아졌다는 결과를 제시한 후기는 아니었습니다.

Claude Code에 아스트라를 연결해 쓰는 사람

9월 8일의 아스트라를 Claude Code 안에서 쓰는 구성에 관한 글도 있었습니다. 작성자 u/TheDeadlyPretzel은 왜 그냥 Codex를 쓰지 않느냐는 질문에 Claude Code의 하네스와 생태계를 더 높게 평가한다고 답했어요.

작성자는 직접 만든 게이트웨이와 플러그인을 소개하고 있었습니다. 작성자의 설명에서 강조한 것은 작업 흐름을 원하는 대로 구성할 수 있다는 점이었어요. 훅으로 동작을 제어하고 작업마다 모델을 배정하면서도 기존 개발 환경을 유지할 수 있다는 이유였습니다.

같은 글의 u/brhkim 댓글은 다른 경험을 전합니다. 비슷한 구성을 사용하지만 Claude Code 업데이트가 프록시를 자주 깨뜨려 유지보수가 힘들었고, 아스트라 지원을 위한 Codex 업데이트 뒤에는 웹 검색도 깨졌다고 했어요. 원글 작성자는 자신은 그런 문제를 겪지 않았다고 답했습니다.

기능이 풍부한 환경을 고르는 이유와, 그 환경을 유지하는 부담이 한 글 안에 같이 있었습니다.

토큰을 쓰는 만큼 일이 줄어들면 좋겠어요

후기는 엇갈렸습니다. 순정 Codex를 선호하는 사람도 있고, 다른 하네스의 제어 기능을 쓰려고 아스트라를 그쪽에 연결한 사람도 있었어요. 이번 조사에서는 OMP의 아스트라 성능이 더 낫다는 구체적인 비교 후기를 찾지 못했습니다.

제 입장에서는 기능 목록보다 이런 차이가 더 궁금합니다.

  • 같은 요청을 했을 때 끝까지 마치는가.
  • 불필요한 변경을 덜 만드는가.
  • 제가 방향을 다시 설명해야 하는 횟수가 줄어드는가.
  • 결과물을 검토하고 고치는 시간이 줄어드는가.

어려운 문제를 풀고 필요한 검증을 하느라 토큰을 쓰는 건 납득할 수 있습니다. 반면 지시를 해석하거나 복잡한 절차를 수행하느라 오래 걸렸는데, 정작 요청한 일은 덜 끝나 있다면 아쉽죠.

OMP의 여러 도구는 분명 쓸모가 있습니다. 정확한 코드 탐색이나 디버깅이 필요한 작업이라면 추가 기능 자체가 OMP를 고를 이유가 되죠. 다만 그 편의성이 같은 아스트라의 결과물까지 꾸준히 좋게 만드는지는 아직 답하지 못했습니다.

정리하면

아스트라가 나와도 하네스의 역할은 여전하다고 생각합니다. ARC Prize가 공개한 결과를 보면, 추론 상태와 문맥을 어떻게 관리하느냐에 따라 성능과 비용이 크게 달라졌으니까요. 현재 OMP도 여기에 필요한 주요 기능을 지원하고 있었고요.

하지만 그 사실만으로 OMP가 순정 Codex보다 낫다는 결론을 낼 수는 없었습니다. 실제 사용자 의견도 갈리고, 같은 아스트라를 고정한 OMP·Codex 비교 자료는 이번 조사에서 확보하지 못했습니다.

저는 두 도구를 계속 병행해서 쓰고 있습니다. 이번에 어느 하나만 남기기로 결정한 것은 없어요. 대신 도구를 보는 기준은 달라졌습니다. 기능이 많다는 점에는 이미 만족했으니, 이제는 그 기능 덕분에 제가 다시 설명하고 기다리고 결과물을 고치는 시간이 얼마나 줄어드는지 궁금합니다.

토큰을 많이 쓰더라도 제 일이 그만큼 줄어들면 좋겠습니다. 아스트라에서 OMP가 순정 Codex보다 그 값을 더 하는지는 아직 모르겠습니다.

참고 자료

댓글