openinterpreter/openinterpreter 딥다이브
— 전설의 Open Interpreter가 Rust로 다시 태어나다

1프로젝트 한 줄 요약

openinterpreter/openinterpreter는 "저비용 모델로도 잘 도는, 터미널 안에서 사는 코딩 에이전트"다. 당신이 "이 버그 고쳐줘"라고 자연어로 치면, 에이전트가 스스로 셸을 돌리고(shell_command) 파일을 고쳐(apply_patch) 결과를 화면에 실시간으로 흘려준다. 이 "생각→도구 호출→관찰→다시 생각"의 반복(에이전트 루프)이 심장이다. 여기까지는 요즘 흔한 터미널 코딩 에이전트와 같다. 다른 점은 그 껍데기 아래의 정체와, "저비용 모델"이라는 목표다.

가장 먼저 알아야 할 사실: 이 저장소는 OpenAI의 Codex(codex-rs)를 통째로 하드포크한 것이다. 파일을 열어 보면 크레이트 이름이 전부 codex-*이고 디렉토리도 codex-rs/다. README가 이를 정직하게 밝힌다 — "Open Interpreter is a fork of OpenAI's Codex." 원래의 파이썬 Open Interpreter는 어디 갔을까? README 하단에 답이 있다: "원조 파이썬 프로젝트는 커뮤니티가 유지하는 endolith/open-interpreter로 계속 산다." 즉 이 이름을 물려받은 새 프로젝트는 완전히 다른 코드베이스(파이썬→Rust)로 재출발한 셈이다.

2왜 지금 주목받는가

Open Interpreter는 2023년 9월 GitHub 트렌딩 #1에 오르며 이름을 알린, 누적 66k 스타의 유서 깊은 프로젝트다. 그런 프로젝트가 파이썬을 버리고 OpenAI Codex를 포크해 완전히 새 몸으로 돌아왔다는 것 자체가 사건이다. 여기에 "저비용·로컬 모델도 잘 굴린다"는 실용적 매력과, README 상단의 "오늘, Kimi K3가 도착했다(Today: Kimi K3 is here)"는 신모델 대응 홍보가 겹쳐 다시 트렌딩에 올랐다.

주목 포인트 1 — "모델을 그 모델의 하니스로 감싼다"는 통찰

이 프로젝트가 던지는 가장 값진 메시지. 요즘 LLM은 순수한 "텍스트 예측기"가 아니라, 특정 에이전트 하니스 안에서 도구를 부르도록 강화학습(RL)으로 튜닝돼 있다. 그래서 Kimi 모델을 Claude Code식 프롬프트/도구 포맷에 넣으면 실력이 안 나온다 — 분포 밖(out-of-distribution)이기 때문이다. Open Interpreter는 이 문제를 정면으로 공략한다. 모델을 고르면 그 모델이 원래 뛰던 하니스를 자동으로 입혀 준다. "모델이 곧 에이전트"라는 최신 흐름을 제품으로 구현한 드문 사례다.

주목 포인트 2 — 지갑이 얇아도 되는 코딩 에이전트

Claude Code·Codex는 강력하지만 프런티어 모델 비용이 만만찮다. Open Interpreter는 DeepSeek·Kimi·Qwen·GLM 같은 저가 API, 그리고 Ollama·LM Studio로 돌리는 완전 로컬 모델을 기본 지원 대상으로 삼는다. 빌트인 프로바이더 목록(model-provider-info)에 openai·anthropic과 나란히 deepseek·kimi·moonshot·qwen·dashscope·openrouter·zai(GLM)·ollama·lmstudio가 박혀 있다. "좋은 코딩 에이전트를 값싸게, 혹은 내 컴퓨터 안에서"라는 수요를 정조준한다.

주목 포인트 3 — 검증된 엔진을 물려받은 이점

바닥부터 새로 짠 게 아니라 OpenAI가 다듬은 Codex 엔진을 물려받았다는 점은 큰 강점이다. 3-OS 네이티브 샌드박스(Landlock/Seatbelt/Windows), MCP·ACP 프로토콜 클라이언트, apply_patch 편집 엔진, 세션 리플레이, V8 기반 "code mode"까지 — 이 모든 성숙한 기반을 그대로 쓰면서, 자신은 "하니스"라는 차별화 레이어에만 집중한다. 신생 프로젝트가 흔히 겪는 안정성 문제를 건너뛴 영리한 전략이다.

3기술 스택 전체 지도

"코딩 CLI"라 하면 Node 프로젝트를 떠올리지만, Open Interpreter의 실체는 약 98개 크레이트로 이뤄진 Cargo 워크스페이스다(Rust .rs 파일 2,561개, 약 116만 줄). npm 런처(codex-cli)는 얇은 껍데기이고, 심지어 그 package.json은 아직 상류 Codex의 @openai/codex 메타데이터 그대로다. 스택을 이해하려면 "무엇이 화면을 그리고, 무엇이 모델과 말하고, 무엇이 안전을 지키는가"의 세 축으로 봐야 한다.

화면·터미널 (TUI 레이어)

두뇌·통신 (모델·네트워크 레이어)

일·안전 (도구·샌드박스·상태 레이어)

4아키텍처 심화 분석

4-1. 전체 구조도 — 사용자 한 줄에서 파일 수정까지

Open Interpreter를 이해하는 가장 빠른 길은 "당신이 친 한 문장"이 어떤 부품을 거쳐 "파일 수정"으로 끝나는지 따라가는 것이다. 핵심은 턴 루프(turn loop) — 모델에게 한 번 묻고, 도구를 실행하고, 결과를 다시 붙이는 한 사이클을, 작업이 끝날 때까지 반복하는 구조다. 그리고 그 입구에서 하니스가 선택돼, 모델에 맞는 프롬프트·도구·와이어가 결정된다.

턴 루프의 최상위 코드는 이렇게 생겼다(core/src/tasks/regular.rs). "대기 중인 입력이 없을 때까지" 턴을 반복하는 단순·견고한 구조다.

// core/src/tasks/regular.rs — 상위 태스크 루프 (요지)
let mut next_input = input;
loop {
    // run_turn: 모델 1회 호출 + 딸려 오는 도구 호출들을 처리
    let last_agent_message = run_turn(
        Arc::clone(&sess), Arc::clone(&ctx),
        Arc::clone(&turn_extension_data),
        next_input, prewarmed_client_session.take(),
        cancellation_token.child_token(),
    ).await?;

    if !sess.input_queue.has_pending_input(&sess.active_turn).await {
        return Ok(last_agent_message);   // 대기 입력 없으면 턴 종료
    }
    next_input = Vec::new();               // 큐에 쌓인 입력으로 다음 턴
}

run_turn 안에서는 run_sampling_request로 모델에 요청을 보낸 뒤, SSE로 흘러오는 ResponseEvent들을 종류별로 처리한다 — OutputTextDelta(스트리밍 텍스트), OutputItemDone(완성된 도구 호출/메시지), ReasoningSummaryDelta(추론 요약), Completed(턴 종료) 등. 전형적인 "서버 이벤트 스트림 소비" 패턴이다.

4-2. 하니스 에뮬레이션 — 이 프로젝트의 심장

여기가 Open Interpreter를 그냥 "또 하나의 Codex"가 아니게 만드는 지점이다. core/src/harness/ 아래에는 하니스마다 세 가지가 한 세트로 묶여 있다: ① 튜닝된 시스템 프롬프트(.md), ② 도구 스키마(.json), ③ 포맷/파싱 Rust 코드. 예컨대 kimi_code.rs + kimi_code_system_prompt.md + kimi_code_tools.json.

프롬프트는 실제로 대상 하니스를 사칭한다. Kimi 하니스 프롬프트의 첫 줄은 "You are Kimi Code CLI…", Claude Code 하니스는 "You are an interactive agent that helps users with software engineering tasks…"로 시작한다. 저비용 모델이 "내가 원래 뛰던 그 환경이구나" 하고 착각하게 만들어, RL로 학습한 실력을 그대로 발휘하게 하는 것이다. 코드에는 README가 소개하는 것보다 많은 16종 하니스가 정의돼 있다(tools/src/harness.rs): Native · ClaudeCode · ClaudeCodeBare · DeepSeekTui · KimiCode · KimiCli · ZCode · LittleCoder · MiniSweAgent · OpenCode · Pi · QwenCode · SweAgent · Terminus2 · Minimal · Other. 런타임에 /harness 명령으로 갈아 끼운다.

4-3. apply_patch — Codex 시그니처 편집 포맷

파일 수정 도구 apply_patch는 Codex 혈통을 가장 잘 보여준다. "이 문자열을 저 문자열로"(exact match)가 아니라, V4A라는 자유형(freeform) 패치 포맷을 쓴다 — *** Begin Patch로 시작해 *** Update File:로 대상을 지정하고, @@ 컨텍스트 앵커 아래에 +(추가)·-(삭제)· (문맥) 줄을 나열한다. 이 포맷은 Lark 문법(apply_patch.lark)으로 파싱된다.

# apply_patch 도구가 받는 V4A 패치 포맷 예시
*** Begin Patch
*** Update File: src/login.rs
@@ fn verify_token(token: &str)
-    if token.is_empty() {
+    if token.trim().is_empty() {
         return Err(AuthError::Empty);
     }
*** End Patch

컨텍스트 줄(@@ 앵커와 주변 문맥)로 위치를 잡기 때문에, 파일이 조금 바뀌어도 정확한 라인 번호 없이 수정 지점을 찾아낸다. 셸 도구 shell_command의 스키마도 살펴보면 Codex의 설계 철학이 보인다 — workdir를 반드시 넘기게 하고 cd 사용을 지양하도록 설명에 못 박아, 에이전트가 작업 디렉토리를 잃지 않게 한다.

// core/src/tools/handlers/shell_spec.rs (요지)
ToolSpec::Function(ResponsesApiTool {
    name: "shell_command".to_string(),
    description: r#"Runs a shell command and returns its output.
- Always set the `workdir` param ...
- Do not use `cd` unless absolutely necessary."#.to_string(),
    strict: false,
    // command(필수) · workdir · timeout_ms(기본 10000) · login …
})

4-4. 3-OS 네이티브 샌드박스 + Starlark 정책

에이전트가 내 컴퓨터에서 셸을 돌리는 건 무섭다. Codex 엔진은 세 운영체제 각각에 네이티브 샌드박스를 구현해 뒀고, Open Interpreter는 이를 그대로 물려받는다.

가장 배울 만한 부분은 execpolicy다. "어떤 명령을 자동 허용하고 무엇을 막을지"를 Starlark(파이썬 비슷한 설정 언어)로 규칙을 기술하고, 실제 bash 명령은 tree-sitter-bash로 구문 트리를 파싱해 검사한다. 문자열 매칭이 아니라 파서 기반이라, rm -rf /를 교묘히 감싼 명령도 잡아낼 여지가 크다. "자동화 도구에 최소 권한을 어떻게 강제하는가"의 교과서적 사례다.

5디렉토리 · 크레이트 구조 해부

저장소는 거대하지만 규칙적이다. 루트 최상위는 크게 Rust 본체(codex-rs/) · npm 런처(codex-cli/) · TypeScript SDK(sdk/) · 문서(docs/)로 나뉜다. "무엇을 먼저 읽어야 하는가" 관점의 지도는 아래와 같다.

꼭 먼저 볼 크레이트

6학습 포인트

배울 것 1 — 하니스 에뮬레이션이라는 새 패러다임

가장 값진 교훈. 모델마다 그 모델이 훈련된 하니스로 감싸야 성능이 난다는 통찰을, (와이어 × 하니스) 라우팅 매트릭스로 실제 구현한 코드를 볼 수 있다. "프롬프트를 잘 쓰면 아무 모델이나 된다"는 낡은 감각을, "모델·하니스·와이어의 분포를 정합시켜라"로 업데이트하는 실물 교보재다. 저비용/오픈 모델을 제품에 태우려는 사람이라면 반드시 봐야 할 접근.

배울 것 2 — 하나의 바이너리, 두 개의 브랜드

product-info/src/lib.rs의 enum Product { Codex, OpenInterpreter }. 같은 실행 파일이 argv0(interpreter/i) · 환경변수 OPEN_INTERPRETER_BRAND · 패키지 메타데이터로 자기 정체를 결정한다. 심지어 서버 호환성 체크를 통과하려고 백엔드엔 Codex 호환 버전(0.144.5)을 보고하되 제품 버전은 0.0.28로 따로 관리한다. "포크 제품이 상류와 호환성을 유지하면서 독자 정체성을 갖는 법"의 실전 사례.

배울 것 3 — 컨텍스트 기반 편집(apply_patch / V4A)

정확한 라인 번호나 문자열 완전 일치 대신 @@ 컨텍스트 앵커로 수정 지점을 찾는 V4A 포맷, 그리고 그것을 Lark 문법으로 파싱하는 방식. "LLM이 생성한 편집을 어떻게 견고하게 적용하는가"라는, 코딩 에이전트의 핵심 난제를 다루는 법을 배운다.

배울 것 4 — 파서 기반 명령 정책(execpolicy)

위험한 셸 명령을 문자열 블랙리스트가 아니라 tree-sitter-bash 구문 트리 + Starlark 정책으로 판정하는 설계. 정규식 우회에 취약한 문자열 검사의 한계를 파서로 넘어서는 실전 보안 코드다. 자동화·CI 도구를 만들 누구에게나 값진 사고 훈련.

배울 것 5 — 도구를 코드로 부르는 "code mode"(V8 임베드)

Rust 안에 V8 자바스크립트 엔진(v8 149.2.0)을 임베드해, 도구들을 JS 함수처럼 노출하고 모델이 코드를 짜서 도구를 조합 호출하게 하는 실험적 경로(code-mode). "도구 호출을 하나씩 JSON으로"에서 "여러 도구를 코드 한 조각으로 오케스트레이션"으로 넘어가는 최신 아이디어를 소스로 확인할 수 있다.

배울 것 6 — 초대형 Cargo 워크스페이스 운영

98개 크레이트, rust-toolchain.toml로 못 박은 툴체인(1.95.0), Cargo와 Bazel(MODULE.bazel)의 병존, 프로바이더 카탈로그를 scripts/write_provider_catalog.py로 생성해 Rust에 임베드하는 코드젠 패턴. "Rust 모노레포를 재현 가능하고 일관되게 유지하는 법"의 모범 사례다.

7시스템 · 실행 요구사항

대부분의 사용자는 설치 스크립트 한 줄이면 된다. 반면 소스에서 빌드하려면 Rust 툴체인이 필요하다. 아래 표가 두 경로를 가른다.

8직접 해볼 수 있는 실습 과제

먼저 설치. 스크립트 한 줄이면 된다.

# 설치 (macOS/Linux)
curl -fsSL https://www.openinterpreter.com/install | sh

i               # 대화형 TUI 실행 (또는 interpreter)

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크

공식
· GitHub 저장소: github.com/openinterpreter/openinterpreter (Apache-2.0 · OpenAI Codex 하드포크)
· TrendShift 카드: trendshift.io/repositories/8740 (Daily #10 · #AI agent)
· 홈페이지·설치: openinterpreter.com → curl -fsSL https://www.openinterpreter.com/install | sh
· 파이썬 원조(별개 프로젝트): github.com/endolith/open-interpreter

저장소 안에서 꼭 읽을 것
· codex-rs/core/src/harness/ — 하니스 에뮬레이션(이 프로젝트의 심장)
· codex-rs/core/src/tasks/regular.rs · session/turn.rs — 턴 루프
· codex-rs/core/src/tools/handlers/ — 도구 구현(shell·apply_patch·plan)
· codex-rs/product-info/src/lib.rs — 듀얼 브랜드 스위치
· codex-rs/model-provider-info/ — WireApi + 프로바이더 카탈로그
· README.md · NOTICE — 포크 혈통과 저작권 고지

곁들여 학습
· ratatui · crossterm — Rust TUI 프레임워크
· tokio · reqwest · eventsource-stream — 비동기 · SSE 스트리밍
· Linux Landlock · seccomp · bubblewrap / macOS Seatbelt — OS 샌드박스
· OpenAI Responses API · MCP(Model Context Protocol) · ACP(Agent Client Protocol)
· 이미 분석한 다른 터미널 코딩 에이전트 딥다이브와 비교(§인덱스 cat-coding-cli — grok-build 등)