5초 결론: 같은 모델을 써도 매번 컨텍스트에 무엇을 넣는지, 모델을 몇 번 부르는지, 도구 결과를 얼마나 들고 가는지, 어디서 압축하는지에 따라 사용량은 크게 달라질 수 있다. 모델이 엔진이라면 Codex나 OpenCode 같은 하네스는 변속기, 연료 분사 장치, 내비게이션, 정비사를 한데 묶은 것이다. 엔진이 같다고 연비까지 같으란 법은 없다.
1. "똑같은 5시간 한도인데 두 배로 달린다" — 먼저, 이건 벤치마크가 아니라 체험담이다
SNS에서 한 개발자가 "Codex에서 OpenCode로 바꾸고 같은 GPT-5.6 Sol을 ChatGPT 인증으로 썼더니, 같은 5시간 한도와 주간 한도 안에서도 두 배 넘게 작업이 진행되는 느낌이다"라는 글을 올렸다.
댓글에는 다른 하네스인 pi를 추천하는 사람, 컨텍스트 상한 설정이 다른 게 아니냐고 의심하는 사람, 라우터나 텔레메트리(사용 기록 수집)로 실제 소비량을 직접 보고 싶다는 사람도 있었다.
여기서 가장 중요한 건 "OpenCode를 쓰면 공식적으로 두 배를 쓸 수 있다"고 증명한 사람은 아무도 없다는 점이다. 눈여겨볼 만한 관찰이긴 하지만, 조건을 통제한 비교 실험은 아니다.
한편 OpenAI는 Codex 사용량이 정해진 메시지 수가 아니라 모델, 작업이 실행되는 위치, 복잡도, 컨텍스트, 추론, 속도, 도구 등에 따라 달라진다고 설명한다. 요금제에 따라 5시간 한도와 주간 한도가 모두 있기도 하다.
그러니 "하네스를 바꿨더니 연비가 달라졌다"는 현상 자체는 구조상 꽤 자연스러운 일이다.
2. 하네스란 무엇인가 — AI 본체 바깥에 있는 '나머지 전부'
모델만 보면 이야기는 단순하다.
Sol = 두뇌.
하지만 실제 코딩 에이전트는 그 두뇌 둘레에 엄청난 설비를 갖추고 있다.
- 시스템 지침(system instruction)을 어떻게 짜는가
- 어떤 파일을 읽는가
- 지난 대화를 몇 토큰이나 남기는가
- 셸이나 GitHub 같은 도구를 몇 개나 보여 주는가
- 도구 출력(tool output)을 다음 턴까지 어디까지 가져가는가
- 실패하면 몇 번 재시도하는가
- 계획, 구현, 리뷰를 몇 바퀴 돌리는가
- 컨텍스트가 넘치기 전에 압축하는가
- 하위 에이전트(subagent)로 나눌 것인가
- 언제 "끝났다"고 판정하는가
이 일체를 넓은 의미에서 하네스라고 부른다.
OpenAI도 Codex를 설명하면서 'harness'라는 말을 쓴다. 모델과 각 클라이언트·도구·대화 상태를 이어 주는 App Server를 소개하는 글에서다.
그래서
모델이 같다 = 시스템 전체가 같다
는 성립하지 않는다.
같은 V8 엔진을 얹어도 2톤짜리 SUV와 가벼운 차체의 연비가 같을 수 없는 것과 마찬가지다.
3. AI의 연비를 망치는 범인은 대개 '매 턴 들고 가는 짐'
에이전트의 사용량은 단순히 "답장을 몇 글자 썼는가"로 정해지지 않는다.
긴 세션에서는 추론할 때마다 이런 것들이 함께 실린다.
- 긴 대화 기록
- 커다란 시스템 프롬프트
- AGENTS.md와 각종 규칙
- MCP의 도구 스키마(tool schema)
- GitHub에서 읽어 온 대량의 파일
- 셸의 긴 로그
- 테스트 결과
- 과거의 실패 기록
- 다음 재시도에 쓸 정보
한 번이면 가볍다.
문제는 이걸 10번, 20번, 30번 다시 보내고 다시 해석한다는 데 있다.
"로그를 100KB 읽었다"보다 100KB급 문맥을 안은 채 모델을 여러 번 부르는 쪽이 더 크게 먹히기도 한다.
게다가 하네스 A가 한 작업을 15턴에 끝내는데 하네스 B가 계획 → 확인 → 탐색 → 재탐색 → 리뷰 → 재리뷰로 30턴을 쓴다면, 같은 모델이라도 차이가 나는 건 당연하다.
연비는 엔진 성능만으로 정해지지 않고,
짐 × 왕복 횟수 × 재시도 횟수
때문에 무너진다.
4. OpenCode가 흥미로운 이유 — ChatGPT 인증, MCP, 압축(compaction)이 한 상자 안에 있다
OpenCode 공식 문서에 따르면 OpenAI에 연결할 때 ChatGPT Plus/Pro를 고르고 브라우저에서 인증할 수 있다. API 키를 직접 입력하는 방식과는 별도로 마련된 경로다.
또 OpenCode는 MCP 클라이언트로서 로컬 MCP와 원격 MCP를 모두 추가할 수 있다.
즉,
OpenCode → GitHub MCP → 데이터베이스 MCP → 자체 API → 그 밖의 외부 도구
같은 구성이 가능하다.
OpenCode에는 자동 압축(compaction)도 있어서, 긴 세션의 오래된 활성 컨텍스트를 체크포인트로 바꿔 놓는다. 현행 문서에서는 자동 압축이 기본으로 켜져 있고, 생성된 요약과 최근 약 15,000 token을 남기는 구성 예가 나와 있다.
이건 "오래된 대화를 지운다"기보다는
창고에는 기록을 남겨 두고, 다음 출격에는 필요한 짐만 싣는다
는 설계에 가깝다.
다만 만능은 아니다. OpenCode 스스로도 MCP 서버를 늘리면 도구 스키마 등이 컨텍스트를 차지하고, 특히 GitHub MCP처럼 큰 MCP는 컨텍스트를 압박하기 쉽다고 경고한다.
MCP를 20개 연결해 놓고 "이제 최강이다!" 하는 건, 용사의 장비창에 창고 전체를 장착하는 꼴이다.
5. ChatGPT에서 MCP로 전부 움직이는 것도 발상은 거의 같다
ChatGPT를 한가운데 두고 MCP나 외부 커넥터를 통해 GitHub, 서버, 클라우드, 스토리지 등을 조작하는 구성도 본질은 '모델 + 하네스 + 도구'다.
배선도로 그리면 단순하다.
ChatGPT → MCP / 커넥터 → GitHub·서버·클라우드·스토리지
ChatGPT가 판단하고, MCP가 손발이 되고, 각 서비스가 현실 쪽의 상태를 가진다.
OpenCode도 마찬가지다.
OpenCode → MCP / 셸 / API → 저장소·서버·클라우드
차이는 대화 상태를 어디에 두고, 도구 루프(tool loop)를 어디서 돌리고, 컨텍스트를 어디서 압축하느냐에 있다.
그래서 "ChatGPT에서 MCP로 전부 움직이는 것과 같은 건가?"라는 물음에는 거의 YES라고 답할 수 있다.
같은 건축 사상에 사령실 제품명만 다른 셈이다.
6. 그렇다면 ChatGPT에서 OpenCode로 일을 넘길 수 있을까
OpenCode는 공식적으로 'MCP를 쓰는 쪽'을 지원한다. 한편 내가 인용한 공식 문서에는 OpenCode 자체를 범용 MCP 서버로 내놓는 모드보다 HTTP/OpenAPI 서버와 SDK, 또는 ACP 진입점이 명시되어 있다.
opencode serve를 쓰면 OpenCode를 헤드리스(화면 없는) HTTP 서버로 띄워 OpenAPI를 통해 세션과 에이전트를 프로그램으로 제어할 수 있다. JS/TS SDK도 있다.
그러니 ChatGPT 쪽에서 OpenCode로 일을 던지고 싶다면 깔끔한 구성은 이렇게 된다.
ChatGPT → 얇은 MCP 브리지 → OpenCode Server → Sol → MCP / 셸 / API → GitHub·클라우드 등
MCP 브리지가 내놓는 도구는 극단적으로 적어도 된다.
- opencode_run_task
- opencode_get_status
- opencode_get_result
정도면 충분하다.
ChatGPT 쪽에 GitHub의 수십 개 도구 스키마나 거대한 로그를 매번 들여오지 않고, 긴 실제 작업은 OpenCode 안에서 끝낸 뒤 마지막 결과만 돌려준다.
이쯤 되어야 비로소 '연비 개선'이 설계가 된다.
7. 사용량을 정말 줄이려면 AI 자체보다 'AI에게 되돌아가는 횟수'를 줄여라
가장 흔한 실수는 더 싼 모델로 바꾸면 다 해결된다고 믿는 것이다.
물론 모델 선택도 효과가 있다.
하지만 장시간 자동 작업에서는 그보다도 다음과 같은 역할 분리가 잘 듣는다.
- 결정론적인 처리는 스크립트로 빼낸다
- 상태(state)와 영수증(receipt)은 기계 쪽이 갖는다
- 필요한 도구만 활성화한다
- 긴 로그는 요약·추출한 다음 모델에 넘긴다
- 같은 파일을 여러 번 다시 읽지 않는다
- 실패 이유와 다음 행동(next action)을 상태로 저장한다
- 애매한 판단만 고성능 모델에게 돌려보낸다
- 최종 운영 환경 확인(production readback)만 사람 쪽으로 돌려보낸다
이상적인 모습은 이렇다.
AI = 애매함을 처리하는 담당
스크립트 / 워크플로 = 확정된 절차를 돌리는 담당
GitHub / DB / 상태 = 기억하는 담당
AI에게 "다음에 뭘 하더라?"를 매번 생각하게 하면 그때마다 창고 재고 조사가 시작된다.
기계에게 nextAction을 적어 두게 하면 AI는 필요할 때만 부르면 된다.
8. 다만 "OpenCode라면 같은 한도에서 무조건 이득"이라고는 아직 말할 수 없다
OpenAI 공식 자료로 확인되는 것은, Codex와 Work가 공유 사용 한도를 쓰고, 요금제에 따라 5시간 한도와 주간 한도가 있으며, 사용량이 컨텍스트나 도구 등에 따라 달라진다는 점이다.
OpenCode 공식 자료로 확인되는 것은 ChatGPT Plus/Pro 인증을 쓸 수 있다는 점이다.
하지만 OpenCode를 거친 ChatGPT OAuth 사용이 OpenAI 쪽에서 Codex와 완전히 같은 계량식, 같은 내부 계수로 소비되는지, 또 OpenCode라면 늘 몇 배 이득인지를 담은 비교표는 양쪽 공식 자료 어디에도 없다.
그러므로
"두 배로 달렸다"는 흥미로운 실측 보고.
"반드시 두 배로 달린다"는 미확인.
이 둘은 섞지 않는 편이 좋다.
제대로 비교하려면 같은 저장소, 같은 모델, 같은 작업, 같은 종료 조건에서 다음을 재야 한다.
- 모델 호출 총 횟수
- input/output token
- 압축 횟수
- 도구 호출 횟수
- 실제 경과 시간(wall-clock time)
- 완료한 변경 수
- 재시도 횟수
- 최종 테스트 결과
"몇 시간 쓸 수 있었나"가 아니라 성공한 작업 하나당 무엇을 소비했나를 봐야 한다.
그것이 진짜 연비다.
9. 결론 — AI 시대, 모델 고르기 다음으로 중요한 것은 '배선'
예전에는 "어느 모델이 가장 똑똑한가"가 핵심이었다.
에이전트 시대에는 그것만으로 부족하다.
같은 모델이라도
- 컨텍스트를 채우는 방식
- 도구의 수
- 상태 관리
- 압축
- 재시도
- 종료 판정
- 외부 워크플로와의 역할 분담
에 따라 해내는 일의 양이 달라진다.
모델은 엔진.
하네스는 연료 분사, 변속기, 내비게이션, 피트 크루, 트렁크 용량까지 한꺼번에 묶은 시스템이다.
그러니 "같은 Sol인데 왜 이렇게 다르지?"는 오히려 자연스러운 의문이다.
그리고 MCP로 여러 서비스를 잇기 시작한 순간, 내가 하는 일은 'AI를 쓴다'에서
AI 주변에 일터를 설계한다
로 바뀌어 있다.
마지막으로 가장 뼈아픈 이야기를 하자면, 최강의 MCP는 "뭐든 AI에게 물어보는 것"이 아니다.
AI에게 물어보지 않아도 되는 공정을 늘리는 것이다.
- OpenAI, Unlocking the Codex harness: how we built the App Server https://openai.com/index/unlocking-the-codex-harness/
- OpenAI Help Center, ChatGPT 요금제로 Codex 사용하기 https://help.openai.com/ja-jp/articles/11369540
- OpenAI Help Center, Work와 Codex에서 GPT-6 Astra 사용량 관리하기 https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex
- OpenCode Docs, Providers https://opencode.ai/docs/providers
- OpenCode Docs, MCP servers https://opencode.ai/v2/docs/mcp-servers
- OpenCode Docs, Compaction https://opencode.ai/v2/docs/compaction
- OpenCode Docs, Server / SDK https://dev.opencode.ai/docs/server/ https://dev.opencode.ai/docs/ja/sdk/
- OpenCode Docs, ACP https://opencode.ai/v2/docs/cli/acp/
