오픈코드 2.0, 상주 서비스와 코드 모드 도입…기존 플러그인·서버 API는 호환 변경

여러 화면이 하나의 실행 상태를 공유

오픈코드는 이전부터 클라이언트와 서버를 분리한 구조를 사용했지만, 제작자는 이를 주로 고급 사용자가 활용했다고 설명했다. 2.0에서는 한 개의 백그라운드 서비스가 기기에서 기본 실행되고, 터미널 화면과 웹·데스크톱 앱이 같은 서비스에 접속한다. 어떤 화면을 열었는지와 별개로 세션·도구·작업 상태를 다룰 수 있도록 바꾼 것이다.

프로그램에서 제어할 수 있는 클라이언트 패키지도 새로 제공한다. 제작자는 자바스크립트와 이펙트(Effect)용 클라이언트가 로컬 서비스를 찾아 연결하고, 명령줄에서도 API를 호출할 수 있다고 설명했다. 사람이 매번 화면을 열어 지시하는 방식과 일정에 맞춰 프로그램이 작업을 시작하는 방식 사이의 경계를 낮추는 변화다. 실제 예약 운영에는 별도의 실행 환경과 권한 설계가 필요하다.

도구 목록을 넘어서 코드로 연결하는 방식

코드 모드는 도구를 함수처럼 호출하고 결과를 가공해 다음 도구에 넘기는 구조다. 공식 발표는 모델 컨텍스트 프로토콜(MCP) 서버와 오픈API(OpenAPI) 엔드포인트를 자바스크립트 함수로 바꿔 조합하는 방식을 소개한다. 여러 왕복 호출을 줄일 수 있다는 것이 제작자의 설명이지만, 모든 업무에서 비용이나 시간이 일정 비율로 줄어든다는 측정 결과는 제시하지 않았다.

이 구조는 도구를 많이 연결할 때 목록을 모두 앞에 펼치는 방식과 다른 접근이다. 필요한 기능을 찾아 호출하고 결과를 코드에서 처리할 수 있다. 다만 도구를 조합할 수 있다는 사실은 그 도구가 가진 외부 변경 권한까지 자동으로 승인한다는 뜻이 아니다. 코드 실행과 연결 서비스의 권한을 구분해야 한다는 문제는 그대로 남는다.

백그라운드 작업에는 다른 모델을 사용하는 하위 에이전트와 셸 명령 실행이 포함된다. 제작자는 오래 걸리는 작업을 뒤로 보내고 사용자가 계속 지시할 수 있다고 설명했다. 여러 작업이 동시에 돌아가면 기다리는 시간을 줄일 여지가 있지만, 공유 파일과 실행 자원, 결과 확인을 어떻게 조정할지도 중요해진다. 기능 제공 사실과 안정적인 병렬 운영의 완성은 별개다.

전환 문서에서 확인되는 세 가지 경계

공식 마이그레이션 문서는 의도적으로 호환성이 바뀐 범위를 플러그인 API, 서버 API·클라이언트 계약, 터미널 클라이언트 설정으로 나눈다. 기존 플러그인을 V2용으로 옮겨야 하고, 서버 API를 호출하는 외부 통합도 수정 대상이 될 수 있다. 터미널 설정은 여러 tui.json 계열 파일에서 하나의 전역 cli.json으로 이동하며 자동 전환된다고 설명한다.

반대로 기존 설정을 모두 새로 써야 한다고 해석해서도 안 된다. 문서는 지원되는 V1 설정과 에이전트·명령·스킬 파일 등은 계속 작동하도록 설계했다고 밝힌다. 새 형식으로의 전면 변환은 선택 사항이다. 새 버전이 기존과 같은 설정 위치를 사용한다는 점 때문에, 이미 V2 전용 형태로 바꾼 파일을 다시 V1에 연결하지 않도록 안내하고 있다.

설치 방식에도 변화가 있다. V1과 V2는 기본적으로 같은 opencode 명령을 사용하며 나란히 설치되는 구조가 아니라고 공식 문서는 설명한다. 패키지 관리자로 설치한 기존 버전과 새 설치 방식을 혼용할 때는 이 차이가 중요하다. 이번 변화는 작은 편의 기능의 추가보다 도구를 서비스와 확장 가능한 실행 환경으로 재구성한 업데이트이며, 도입 판단에서는 새 기능과 전환 비용을 함께 볼 필요가 있다.