OpenCode 2.0: 상시 서버와 코드 모드로 다시 짠 코딩 에이전트

AI 요약

OpenCode 2.0은 사용자가 매일 실행하며 겪은 경험을 바탕으로 시스템을 크게 손봤다고 설명합니다. 주요 변경점은 클라이언트와 서버의 통합, API 재작성, 코드 모드, 백그라운드 작업, 플러그인 안정화, SDK 제공입니다. CLI를 업그레이드하려면 최신 1.x 버전을 설치한 뒤 opencode upgrade --major를 실행합니다. 1.0 플러그인은 호환되지 않으며 서버 API도 완전히 달라집니다.

단일 로컬 서버와 새 API

2.0에서는 로컬 서비스가 백그라운드 프로세스 하나로 실행됩니다. TUI, 웹 인터페이스, 데스크톱 앱이 모두 같은 서버에 연결합니다. @opencode/client를 사용하는 스크립트는 로컬 서비스를 자동으로 찾아 연결하고, opencode api 명령으로도 서버 기능을 호출합니다. 서버를 다른 호스트에 공개해 /pair 또는 opencode pair로 다른 애플리케이션과 연결하는 방식도 지원합니다. 작성자는 새 네이티브 앱도 이 흐름을 활용할 예정이라고 밝혔습니다.

기존 API는 사용 사례가 늘면서 일관성이 떨어졌다고 설명하고, 이를 처음부터 다시 만들었다고 합니다. OpenCode 자체도 API를 호출합니다. 예를 들어 새 작업을 시작할 때 현재 세션을 Git worktree로 옮기는 작업을 처리합니다. 새 클라이언트 패키지는 일반 JavaScript와 Effect용 인터페이스를 제공합니다.

코드 모드와 백그라운드 작업

@opencode/codemode는 MCP 서버나 OpenAPI 엔드포인트를 에이전트가 스크립트에서 호출할 수 있는 함수로 바꿉니다. OpenCode는 이 스크립트를 자체 JavaScript 인터프리터에서 실행합니다. 도구 하나를 호출한 뒤 결과를 변환해 다른 도구를 부르는 작업을 하나의 스크립트로 묶을 수 있어, 도구를 하나씩 호출할 때보다 왕복 횟수를 줄입니다. 2.0에서는 MCP 서버가 기본으로 코드 모드를 사용합니다. 작성자는 MCP 서버를 많이 추가해도 컨텍스트가 크게 늘지 않고, 에이전트가 도구를 찾아 조합한다고 설명합니다.

주 에이전트는 하위 에이전트에 작업을 맡기고 자신은 대화를 이어갈 수 있습니다. 백그라운드 하위 에이전트를 자동으로 실행할 수 있고, 사용자가 직접 다른 모델을 지정해 시작할 수도 있습니다. 셸 명령도 비동기로 실행하며, 작업이 끝나면 알림을 받습니다. 포그라운드 작업이 오래 걸릴 때 단축키로 백그라운드로 옮기는 기능도 있습니다.

플러그인, SDK와 업그레이드 조건

팀은 2.0의 기능 대부분을 내부 플러그인으로 구현해 플러그인 API를 계속 사용하도록 했으며, 현재 플러그인이 80개 이상이라고 합니다. 실험 단계였던 TUI 플러그인은 안정 버전으로 승격했습니다. 플러그인을 세션 도중 다시 불러오는 기능도 지원해 에이전트가 플러그인을 작성하고 곧바로 사용할 수 있습니다.

@opencode/sdk를 이용하면 CLI와 같은 코드를 라이브러리로 쓸 수 있습니다. SDK를 축소해 서버나 Durable Objects 같은 환경에 맞춘 OpenCode를 만들고, 표준 OpenCode 서버 프로토콜을 지원하는 클라이언트에서 연결할 수 있습니다. Effect 기반 API도 선택할 수 있습니다. 업그레이드에는 호환성 변경이 따릅니다. 1.0 플러그인은 작동하지 않고 서버 API도 달라지므로 클라이언트와 서버를 함께 올려야 한다는 사용 경험이 공유됐습니다.

Hacker News 반응

• @oblongsquare69 — 이 프로그램을 좋아합니다. 2.0은 크게 개선됐습니다.
• @nater5000 — 게시글만 보면 좋은 개선이 많이 들어간 것 같습니다. OpenCode를 조금 써봤는데 제 작업에는 충분했습니다. 그래도 주력으로 쓰기에는 Codex나 Claude Code보다 부족했습니다. 이번 버전이 그 차이를 메웠는지 다시 써보겠습니다.
  • @dsauerbrun — 궁금해서 묻습니다. Codex나 Claude Code가 OpenCode보다 나은 작업은 어떤 것인가요?
• @361994752 — 백그라운드 작업과 하위 에이전트 기능, 하위 에이전트 실행 때 모델을 지정하는 기능이 지금까지 가장 마음에 듭니다. 작은 기능이지만 매일 개발할 때 편의성이 크게 달라집니다.
• @kingds — 전반적으로 분명히 좋아진 것 같습니다. 다만 업그레이드 뒤 문제가 생겼습니다. 이제 모든 도구 호출이 백그라운드 프로세스를 거치면서 TUI 프로세스를 감싸던 샌드박스가 조용히 무력화됐습니다. 차단돼야 할 웹 요청 등이 성공하는 걸 하루 이틀 뒤에야 알아챘습니다.
  • @verdverm — 초기 v2에서 보안 퇴행이 적어도 세 가지 있다고 봅니다. 설정 로딩 문제가 있었고, 플러그인 핫 리로드로 에이전트가 플러그인을 바꾼 뒤 즉시 적용할 수 있으며, 샌드박스 문제도 있습니다. 이미 이만큼 발견됐는데 다른 문제가 얼마나 더 있을지 궁금합니다.
  • @Cannabat — 네 번째도 있습니다. 플러그인이 추가한 도구는 권한 설정을 따르지 않습니다. 항상 허가를 묻게 설정해도 자동 승인됩니다.
  • @LeBit — 제 생각에도 퇴행입니다. 샌드박스에서 쓰려면 --standalone을 지정해야 합니다. 도구가 샌드박스 안에서 실행되도록 설계해야 합니다.
• @LaurensBER — 흥미로워서 써보겠습니다. 클라이언트와 서버 구조, 플러그인 시스템이 강력해 보입니다. 다만 최근에는 OMP와 Tern 터미널 조합을 쓰는데 매우 매끄럽습니다. 회사 장비인 Windows에서 쓸 만한 터미널을 찾기 어려웠지만 이 조합이 가장 낫습니다.
  • @flashblaze — 저도 써봤는데 RAM 사용량이 꽤 높았습니다. 결국 Ghostty로 돌아갔습니다.
• @solarkraft — 좋습니다. V1의 불편한 점이 많이 사라졌습니다. 스킬과 플러그인이 자동으로 다시 불러와지고 작업을 백그라운드로 보낼 수 있습니다. 설정 편집용 내장 스킬도 생겼고 프런트엔드도 손봤습니다. Effect를 중심으로 실행 구조를 다시 설계했다고 합니다. 이번 업데이트로 OpenCode가 기능 면에서 현재 수준에 맞춰졌습니다.
  • @tacomagick — 사용 중인 모델이 작업을 자동으로 백그라운드로 보낼 수도 있습니다. 수동으로만 되는 건 아닙니다.
  • @solarkraft — 맞습니다. 제가 말한 건 작업이 오래 걸릴 때 제가 직접 백그라운드로 옮겨야 한다는 점입니다. 모델이 항상 그 시간을 예측하지는 못합니다. 모델이 멈춰 버리는 문제도 아직 해결되지 않았고, 기본 설정에서는 권한 요청에 시간 제한도 없습니다.
• @nater5000 — 업데이트는 전반적으로 좋은 개선처럼 보입니다. 저는 아직 OpenCode를 많이 써보지 않았지만, 제 작업에서는 괜찮았습니다. Codex나 Claude Code를 대신할 만큼 주력 도구가 되지는 못했는데 새 버전은 다시 살펴보겠습니다.
• @nfriedly — OpenChamber 2.0을 통해 OpenCode 2.0을 쓰고 있는데 만족스럽습니다. 서버와 클라이언트를 모두 업그레이드해야 하는 첫 고비를 넘기고 나니 계속 잘 작동했습니다.
  • @threecheese — 키보드에 익숙해지면 손의 일부처럼 쓸 수 있습니다. 터미널 여러 개를 빠르게 오갈 수 있고 마우스로 손을 옮기면 하던 일이 끊깁니다. 물론 포인터가 좋은 이유도 있습니다. 대부분 취향 차이라고 봅니다.
• @verdverm — 저는 OpenCode에서 Pi로 옮겼습니다. V2의 UX 방향이 마음에 들지 않고 보안 관련 접근도 신뢰하기 어렵습니다. 설정 로딩 문제를 팀과 함께 살펴보며 이슈와 PR 두 건을 처리했습니다.
• @esafak — OpenCode를 매일 쓰지만 GUI를 MCP와 플러그인만 추가하는 방식으로 확장하고 싶지는 않습니다. PR 병합 버튼이나 CI 상태 표시 같은 UI를 직접 붙이고 싶습니다. 버튼과 라벨 같은 UI 구성 요소를 제공하고 사용자 함수와 연결하면 좋겠습니다. 코드 모드가 이를 지원할 수 있을까요?
• @solarkraft — 작업을 백그라운드로 보내는 기능은 좋지만, 모델이 멈추는 유형의 불편은 여전히 있습니다. 애플리케이션을 실행할 때 모델이 절반쯤 멈추는 일이 저만 겪는 줄 알았습니다.
• @rfgplk — 코드 대부분을 LLM이 만들었다면 왜 C++이나 Rust가 아니라 TypeScript를 썼는지 명확한 답을 듣고 싶습니다.
  • @verdverm — 컴파일 언어는 서드파티 플러그인을 만들기 어렵게 합니다.
• @sksduck — OpenMemoryLeak이라고 부를 정도로 메모리를 많이 씁니다.
  • @nijave — 1.x에서는 파일 감시자가 과도하게 늘어나는 문제를 발견했습니다. 하위 디렉터리가 많은 최상위 폴더에서 실행하면 수백만 개의 감시자가 생길 수 있습니다. 2.x에서 해결됐는지는 모르겠습니다.
• @amelius — Vim을 쓰지만 AI 도구의 웹 인터페이스가 TUI보다 좋습니다. 이상할 수도 있겠지만요.
• @hi_hi — 표준 Codex나 Claude 대신 어떤 코딩 에이전트를 써야 할지 판단하는 벤치마크가 있나요?
  • @ahmadyan — 몇 가지 벤치마크가 있지만 쉽게 점수를 높이는 방식으로 대응할 수 있습니다. 같은 모델도 하네스에 따라 행동이 달라집니다.

원문: Anomaly / 번역·요약: Trawling