Open Interpreter: 저비용 모델을 코딩 에이전트로 만드는 하네스 전략

Open Interpreter · 저비용 코딩 에이전트 · 하네스 에뮬레이션

Open Interpreter가 2026년 7월 13일 새 버전의 Open Interpreter를 공개했다. 겉으로는 “저비용 모델에 최적화된 가벼운 코딩 에이전트”라는 문장으로 요약되지만, 실무적으로 더 중요한 포인트는 따로 있다. 이 프로젝트는 단순히 모델을 싸게 호출하는 CLI가 아니라, 각 모델이 가장 잘 작동하도록 훈련된 도구 표면과 시스템 프롬프트, 컨텍스트 압축 리듬을 에뮬레이션하는 실행 계층을 만들고 있다.

이 글은 Open Interpreter의 공식 발표, GitHub README, Harness 문서, Providers 문서, 그리고 Agent Client Protocol 문서를 기준으로 작성했다. 기준 시점은 2026-07-16이다.

검색 의도부터 보면: “AI 코딩 비용” 문제는 이제 모델 가격만의 문제가 아니다

한국 개발자와 기술 운영자가 앞으로 검색할 키워드는 “저렴한 LLM” 하나로 끝나지 않는다. 실제 질문은 더 구체적이다.

• Claude Code나 Codex 비용이 커질 때 어떤 작업을 저비용 모델로 넘길 수 있나?
• Kimi, Qwen, DeepSeek 같은 모델을 그냥 OpenAI 호환 API로 붙이면 충분한가?
• 모델별 코딩 에이전트 성능 차이는 모델 자체 때문인가, 아니면 하네스 때문인가?
• 사내 에이전트를 IDE, CI, 로컬 터미널에서 같은 방식으로 쓰려면 어떤 프로토콜이 필요한가?

Open Interpreter가 흥미로운 이유는 이 질문에 “모델 라우터를 만들자”가 아니라 **“모델이 훈련된 에이전트 차량을 최대한 비슷하게 제공하자”**고 답하기 때문이다. 이 차이가 작아 보이지만, 에이전트 제품을 운영해 본 팀에게는 꽤 큰 차이다.

핵심 주장: 모델 라우팅보다 하네스 에뮬레이션이 더 중요해질 수 있다

Open Interpreter 공식 발표는 “AI has an economics problem”이라는 문장으로 시작한다. 기업들이 frontier 모델 예산을 조절하고, 더 싼 토큰을 찾고, 오픈/저비용 모델을 더 많이 쓰려는 흐름이 커지고 있다는 문제의식이다. 발표문은 DeepSeek 계열 모델이 Claude Opus 4.7 대비 80% 이상의 지능 지표를 보이면서 비용은 크게 낮다는 식의 가격-지능 프런티어를 언급한다.

하지만 저비용 모델이 싸다는 사실만으로는 코딩 에이전트가 되지 않는다. 많은 코딩 에이전트 제품은 특정 frontier 모델을 전제로 만들어졌다. Claude Code는 Claude의 도구 표면과 메시지 형식에 맞춰져 있고, Codex는 GPT와 OpenAI Responses 계열 경험에 맞춰져 있다. 모델만 바꿔 끼우면 도구 호출 방식, 컨텍스트 관리, 권한 요청, 파일 편집 리듬이 어긋날 수 있다.

Open Interpreter의 답은 하네스 에뮬레이션이다. 공식 Harness 문서는 하네스 모드가 “model-facing prompt, tool schema, message conversion, response handling”을 바꾸되, 실제 런타임은 Open Interpreter의 네이티브 런타임을 유지한다고 설명한다. 즉 외부 CLI를 그냥 shell out 하는 게 아니라, 모델 앞에 보이는 세계를 바꾸는 방식이다.

문서에 적힌 하네스 ID만 봐도 방향이 보인다.

이건 “어떤 모델이 제일 싸냐”보다 한 단계 실무적인 문제다. 같은 모델도 어떤 tool schema와 instruction contract를 받느냐에 따라 행동 품질이 달라질 수 있기 때문이다.

왜 이것이 비용 절감보다 더 큰 이야기인가

많은 팀이 AI 코딩 비용을 줄이려 할 때 먼저 생각하는 방식은 모델 라우팅이다. 쉬운 작업은 싼 모델, 어려운 작업은 비싼 모델에 보낸다는 접근이다. 이 자체는 필요하다. 하지만 코딩 에이전트에서는 라우팅만으로 부족하다.

예를 들어 파일 읽기, 검색, 편집, 셸 실행, TODO 관리, 컨텍스트 압축, 서브태스크 위임은 모두 모델이 반복적으로 학습하거나 튜닝된 행동 패턴과 연결된다. 어떤 모델은 read_file path, offset 같은 도구 표면에 익숙할 수 있고, 어떤 모델은 grep_search pattern, include 같은 스키마에서 더 안정적으로 움직일 수 있다. 시스템 프롬프트의 길이, 컨텍스트 압축 지시, 에러 처리 방식도 다르다.

Open Interpreter는 이 차이를 모델 뒤의 API 호환성 문제가 아니라 모델 앞의 작업 환경 문제로 본다. 공식 발표가 “competitive inference market”에서 하네스 에뮬레이션이 모델 라우팅보다 강한 기반이라고 말하는 이유도 여기에 있다.

실무적으로는 다음과 같은 의미가 있다.

1. 싼 모델을 더 안전하게 실험할 수 있다.
   단순 Chat Completions 래퍼가 아니라 모델별 하네스를 제공하면, 저비용 모델의 실패 원인이 “모델 한계”인지 “도구 표면 mismatch”인지 더 잘 분리할 수 있다.

2. 팀이 이미 가진 에이전트 운영 습관을 보존할 수 있다.
   Open Interpreter는 Codex CLI 위에 구축됐고, README는 terminal interface, skills, plugins 설정을 유지할 수 있다고 설명한다. Codex를 쓰던 팀에게는 전환 비용을 낮추는 신호다.

3. 저비용 모델은 보조가 아니라 작업자 풀로 들어올 수 있다.
   발표문은 엔터프라이즈가 기존 intelligence provider를 쓰면서도 에이전트가 low-cost models에 작업을 delegate할 수 있다고 말한다. 즉 “싼 모델로 초안 작성” 수준이 아니라, 코딩 에이전트 내부의 위임 대상이 될 수 있다는 뜻이다.

구조를 보면: Codex 기반이지만 목표는 오픈 모델용 애플리케이션 계층이다

GitHub README는 Open Interpreter를 “OpenAI Codex의 포크이며, 저비용 모델에서 최고의 성능을 내는 agent harness를 에뮬레이션하는 데 초점을 둔다”고 설명한다. 저장소 구조도 이 설명과 맞다. codex-rs, codex-cli, AGENTS.md, .codex, Bazel 설정, 보안 문서, 설치 스크립트가 함께 있다. 단순한 프롬프트 모음이 아니라 런타임과 배포 패키지를 같이 다루는 프로젝트다.

README 기준 주요 기능은 다음처럼 정리된다.

• macOS, Linux, Windows 네이티브 샌드박싱 안에서 명령 실행
• /model로 provider와 model 전환
• /harness로 Rust-native model harness 확인·전환
• 내장 QA skill을 통한 웹/네이티브 앱 테스트
• interpreter acp로 Agent Client Protocol 에이전트 실행
• ~/.openinterpreter 아래 로컬 config와 session state 유지
• exec, MCP, skills, hooks, permissions, AGENTS.md 지원

여기서 눈에 띄는 것은 제품의 레이어다. Open Interpreter는 모델 API 클라이언트, 터미널 에이전트, 샌드박스, 스킬/훅/권한, IDE 프로토콜을 한 덩어리로 묶는다. 그래서 “오픈 모델용 코딩 에이전트”라고 부르기보다, 오픈 모델이 실제 개발 환경에 들어가기 위한 애플리케이션 계층이라고 보는 편이 더 정확하다.

Provider 문서가 보여주는 운영 포인트: API 호환성은 세 종류로 갈라진다

Open Interpreter의 Providers 문서도 중요하다. 문서는 provider와 model을 분리하고, provider가 요청이 어디로 가는지, 자격 증명을 어떻게 붙이는지, 어떤 wire API를 쓰는지 결정한다고 설명한다.

핵심은 wire_api다.

이 구분은 사소한 구현 디테일이 아니다. 하네스 호환성 문서에 따르면 responses는 native 모드 중심이고, messages는 claude-code류 하네스와 맞으며, chat은 Kimi/Qwen/DeepSeek/SWE-agent/minimal 같은 하네스와 연결된다. 즉 “OpenAI 호환 API면 다 된다”가 아니라, 모델·provider·wire API·하네스가 맞물려야 한다.

한국 팀이 사내에서 여러 LLM provider를 붙일 때도 이 구분은 그대로 중요하다. 모델 선택 UI만 만드는 것보다 provider 인증, wire API, 하네스 기본값, 도구 스키마, 권한 정책을 함께 설계해야 한다.

샌드박싱과 로컬 상태: 저비용 에이전트일수록 더 필요하다

공식 발표에서 또 하나 중요한 축은 네이티브 샌드박싱이다. Open Interpreter는 Codex의 경량 샌드박싱을 이어받아 Windows, macOS, Linux에서 작업 디렉터리 중심으로 네트워크와 파일 접근을 제한할 수 있다고 설명한다.

이 부분은 저비용 모델 전략과 연결된다. frontier 모델 하나만 조심스럽게 쓰는 구조에서는 사람이 매번 권한을 확인하는 방식도 어느 정도 버틴다. 하지만 여러 저비용 모델에 작업을 위임하고, 장시간 자율 작업을 시키려면 매번 사람이 감시하는 방식은 비현실적이다. 오히려 모델 단가가 낮아질수록 실행 횟수와 자동화 범위가 늘어나고, 그만큼 샌드박스와 권한 정책이 중요해진다.

README에 나온 ~/.openinterpreter 로컬 상태, hooks, permissions, MCP, skills, AGENTS.md도 같은 맥락이다. 에이전트가 진짜 개발 환경에서 쓰이려면 “모델에게 질문을 보내고 답을 받는 구조”를 넘어, 다음을 관리해야 한다.

• 어떤 디렉터리와 네트워크에 접근할 수 있는가
• 어떤 스킬과 훅이 실행되는가
• 어떤 provider credential이 쓰이는가
• 세션 상태와 설정은 어디에 남는가
• IDE나 CI가 같은 에이전트를 어떻게 호출하는가

ACP 지원은 왜 중요한가: 에이전트와 IDE의 결합을 느슨하게 만든다

Open Interpreter는 interpreter acp를 통해 Agent Client Protocol 에이전트로 동작할 수 있다고 설명한다. ACP 문서는 이 프로토콜이 코드 에디터/IDE와 코딩 에이전트 사이의 통신을 표준화하며, 로컬 에이전트는 JSON-RPC over stdio로, 원격 에이전트는 HTTP/WebSocket으로 연결될 수 있다고 설명한다.

이건 개발자 경험에서 꽤 중요하다. 지금까지 많은 코딩 에이전트는 특정 IDE나 특정 터미널 제품에 묶였다. IDE는 에이전트별 통합을 따로 만들어야 했고, 에이전트는 IDE별 API를 구현해야 했다. ACP의 목표는 LSP가 언어 서버 생태계에서 했던 것처럼, 에디터와 에이전트를 느슨하게 분리하는 것이다.

Open Interpreter가 ACP를 지원한다는 것은, 저비용 모델 하네스 전략이 터미널 안에만 갇히지 않을 수 있다는 뜻이다. Zed, JetBrains, VS Code, Obsidian 같은 클라이언트가 같은 에이전트 프로토콜로 로컬 또는 원격 에이전트를 붙이는 구조가 가능해진다.

실무 해석: 한국 개발팀은 어디에 써볼 만한가

Open Interpreter를 당장 모든 코딩 작업의 기본 에이전트로 바꾸자는 이야기는 아니다. 오히려 현실적인 도입 지점은 더 좁다.

1) 반복적인 레포 탐색과 초안 작업

큰 구조를 이해하고, 파일을 읽고, 간단한 수정 후보를 만들고, 테스트 명령을 제안하는 작업은 저비용 모델 실험에 적합하다. 하네스 에뮬레이션이 제대로 작동하면 “싼 모델이라 도구를 못 쓴다”는 문제를 줄일 수 있다.

2) CI/자동화의 1차 triage

실패 로그 요약, flaky test 후보 분류, 단순 dependency 업데이트, 린트 수정 같은 작업은 frontier 모델을 매번 쓰기 아깝다. Open Interpreter가 Codex app-server SDK나 CI 워크플로를 대체/보완할 수 있다고 말하는 지점도 여기와 맞닿아 있다.

3) 모델별 하네스 A/B 테스트

팀이 이미 Kimi, Qwen, DeepSeek, Claude, OpenAI 계열을 섞어 쓰고 있다면 모델만 비교하지 말고 하네스까지 같이 비교해야 한다. 같은 작업을 native, kimi-cli, qwen-code, deepseek-tui, claude-code 표면으로 나눠 돌려보면 모델 성능보다 실행 표면의 영향이 보일 수 있다.

4) 내부 에이전트 표준화 실험

MCP, skills, hooks, permissions, ACP가 모두 등장한다는 점은 Open Interpreter를 단순 CLI가 아니라 내부 에이전트 런타임 후보로 보게 만든다. 특히 여러 IDE와 로컬/CI 환경을 동시에 지원하려는 팀에게는 “어떤 에이전트 프로토콜을 표준으로 삼을 것인가”가 중요해진다.

도입 전 체크리스트

실험한다면 다음 순서가 좋다.

1. 비용이 큰 작업군부터 찾는다.
   전체 코딩을 대체하려 하지 말고, 로그 요약·레포 탐색·테스트 실패 triage처럼 비용 대비 반복성이 큰 작업부터 고른다.

2. 모델만이 아니라 하네스도 기록한다.
   결과를 비교할 때 “DeepSeek가 좋다/나쁘다”로 쓰지 말고 provider, wire API, harness, context size, permission 정책을 같이 남긴다.

3. 샌드박스 경계를 먼저 정한다.
   저비용 모델을 많이 호출할수록 실행 횟수는 늘어난다. 파일 쓰기, 네트워크, 비밀키 접근, destructive command 정책을 먼저 정의해야 한다.

4. ACP/MCP/skills를 한꺼번에 열지 않는다.
   프로토콜과 도구 표면이 많아질수록 편하지만, 공급망과 권한 표면도 넓어진다. 처음에는 로컬 레포 탐색과 읽기 중심 작업부터 시작하는 편이 낫다.

5. frontier 모델과 역할을 나눈다.
   저비용 모델은 반복 작업과 초안, frontier 모델은 최종 설계 판단과 위험한 변경 검토로 나누는 식의 escalation 정책이 현실적이다.

결론: Open Interpreter는 “싼 Codex”보다 “하네스 운영 계층”에 가깝다

Open Interpreter를 단순히 “Codex를 포크해서 저비용 모델을 붙인 도구”로 보면 핵심을 놓친다. 중요한 변화는 저비용 모델을 하나의 generic chat wrapper에 밀어 넣지 않고, 각 모델이 잘 작동하는 하네스와 wire API, 도구 표면을 맞춰주려는 접근이다.

앞으로 코딩 에이전트 경쟁은 모델 성능만으로 결정되지 않을 가능성이 크다. 어떤 팀은 더 비싼 frontier 모델을 쓰더라도 하네스와 샌드박스가 약해서 운영 비용이 커질 수 있고, 어떤 팀은 저비용 모델을 잘 맞는 하네스와 권한 경계 안에 넣어 충분한 생산성을 얻을 수 있다.

한 줄로 정리하면 이렇다. Open Interpreter의 메시지는 “모델을 싸게 바꾸자”가 아니라, “저비용 모델이 일할 수 있는 에이전트 차량을 제대로 만들자”에 가깝다.

참고한 주요 sources

• Open Interpreter, Open Interpreter - The application layer for open models, 2026-07-13.
• Open Interpreter GitHub, openinterpreter/openinterpreter README, 2026-07-16 확인.
• Open Interpreter Docs, Harness, 2026-07-16 확인.
• Open Interpreter Docs, Providers, 2026-07-16 확인.
• Agent Client Protocol, Introduction, 2026-07-16 확인.