서론

여러 AI 코딩 에이전트(CLI/TUI 하네스)를 비교 사용한 결과로 'OpenCode + openchamber' 조합에 도달했다는 취지의 게시물을 SNS에서 접했습니다. 제시된 판단 기준을 제가 요약하자면 다음 세 가지로 정리할 수 있습니다.

성숙하고 안정적인 GUI가 필요함(TUI의 검은 화면, 방대한 단축키 암기는 힘들다)
벤더 종속성이 없어야 함(특정 모델 벤더에 의존하지 않고, 서드파티 모델이 2급 시민 취급을 받지 않아야 한다)
후속 개발 및 커스터마이징이 가능하여 고객에게 그대로 전달할 수 있어야 함(OSS로 라이선스가 친화적이다)

이 세 가지 조건을 기준으로 다른 후보들(커뮤니티 제작 GUI, OAuth 로그인 전제 툴, 서드파티 모델 설정이 번거로운 툴)을 제외하고 최종적으로 OpenCode 본체 + GUI 래퍼인 openchamber(MIT, ★7,600 초과, 2025년 9월 작성)에 결정되었다는 흐름이었습니다.

흥미로운 관점이지만, 별표 수가 많은 것에 비해 2025년 9월 작성이라 아직 신규하기 때문에 실제로 어느 정도 '성숙'했는지 궁금했습니다. 게다가 다른 후보들이 정말로 'GUI가 형편없어서 제외할 만한지'는 실측으로 검증되지 않았습니다. 그래서 실제로 openchamber를 빌드하고 구동하여 세 가지 조건을 실측 기반으로 검증해 보았습니다.

검증 환경

• Mac mini (Apple Silicon, RAM 8GB)
• OpenCode CLI v1.17.10 (공식 CLI, 사전 설치됨)
• bun 1.3.14 (openchamber의 packageManager 지정에 맞춰 도입) - openchamber는 소스에서 clone → bun install → bun run build:web으로 빌드(Web/CLI 버전)

데스크톱 버전(Electron)은 GitHub Releases의 바이너리 배포가 전제되어 빌드가 무겁기 때문에, 이번에는 소스로 가볍게 시도할 수 있는 CLI/Web 버전으로 검증했습니다.

1. 설정 및 구동 ── '성숙한 GUI'인가?

git clone --depth 1 https://github.com/openchamber/openchamber.git
cd openchamber
bun install # 3143 packages, 약 49초
...

package.json의 packageManager 지정 버전과 bun의 실제 버전이 일치했기 때문에 의존성 문제로 막히는 일 없이 한 번에 통과했습니다. TypeScript 제품에서 흔한 '의존성 버전 지옥'은 이번에는 발생하지 않았습니다.

구동 로그를 보면 OpenCode 본체를 자식 프로세스로 자동 구동하고 있는 것을 확인할 수 있습니다.

Starting OpenCode on allocated port 58077...
[OpenCode] Launching managed server {
sourceBinary: "/opt/homebrew/bin/opencode",
...

즉, OpenCode 본체를 개별적으로 구동 및 설정할 필요 없이, openchamber를 구동하는 것만으로 OpenCode 연결까지 완료됩니다. 이 부분은 상상했던 것보다 훨씬 순조로웠습니다.

UI 비밀번호 로그인 역시 POST /auth/session에 비밀번호를 던지는 것만으로 쿠키 발급을 통한 세션 관리가 작동합니다. API 계층, 프로세스 관리, 로그 관리까지 일련의 구조가 갖춰져 있어, 새로운 프로젝트에서 흔히 발생하는 '기반이 부실하다'는 느낌은 없었습니다.

한편 한 가지 걸리는 점이 있었습니다. 로그의 cwd: "/Users/masaka"에서 볼 수 있듯이, openchamber는 기본적으로 홈 디렉토리를 프로젝트 루트로 취급합니다. 이번에는 검증용 디렉터리에 작업을 한정할 필요가 있었기 때문에, 이후 API 요청마다 directory 파라미터를 매번 명시하여 고정했습니다. GUI를 단순히 띄운 것만으로는 '지금 어디를 건드리고 있는지'에 대한 감각이 예상과 어긋날 위험은 있어 보입니다.

참고로, 이번에는 headless 환경이었기 때문에 브라우저 조작(실제 드롭다운 조작이나 단축키, 에러 발생 시 토스트 표시 등)은 검증할 수 없었습니다. 아래 내용은 HTTP API 직접 호출을 통한 기능 검증이며, 시각적인 UI의 완성도 자체는 확인하지 못했다는 점을 솔직하게 말씀드립니다. 백엔드 계층의 구조를 추론해 볼 때, GUI 측면도 상당한 노력이 들어간 것으로 보입니다.

2. 코딩 작업 완료 및 모델 전환 — '벤더 종속성이 없다'고 할 수 있을까

openchamber의 API는 /api/*로 들어오는 요청을 OpenCode 본체의 /*에 그대로 프록시하는 직관적인 구조였으며, 인증 헤더 주입 외에는 거의 투명했다. 즉, OpenCode 공식 SDK의 타입 정의가 그대로 통용된다.

막혔던 부분

처음에는 다음과 같이 모델을 지정하여 메시지를 보냈으나, 지정이 무시되고 기본 모델로 폴백(fallback)되었다.

{"providerID": "openrouter", "modelID": "deepseek/deepseek-v4-flash", "parts": [...]}

@opencode-ai/sdk의 타입 정의를 확인해보니, 정확하게는 model 키 아래에 중첩(nested)되어야 했다.

{"model": {"providerID": "openrouter", "modelID": "deepseek/deepseek-v4-flash"}, "parts": [...]}

이는 OpenCode 본체의 API 사양이며 openchamber 고유의 버그는 아니지만, 모델 지정에 실수를 하면 에러가 나지도 않고 조용히 기본 모델로 실행된다는 점은 실제로 사용해보지 않으면 알 수 없는 동작 방식이었다. GUI 드롭다운 메뉴에서 선택할 때는 발생하지 않는 문제지만, API/SDK를 직접 건드려 2차 개발을 하는 상황에서는 걸리기 쉬운 함정이라고 생각한다.

실측 결과

'기존 코드를 변경하지 않고, 지정한 함수를 추가하여 테스트 호출도 작성하는' 최소한의 코딩 작업을 올바른 모델 지정으로 수정한 후 여러 프로바이더에 던져보았다.

• |
  reasoning_content 필드 미지원으로 400 에러 |

네 건 모두 실제로 파일 내용을 확인하여 성공 여부를 판단했다(모델의 자체 선언 텍스트만으로는 판단하지 않음).

Cerebras의 경우, 직전 어시스턴트 메시지에 포함된 reasoning_content 필드를 Cerebras 측 API가 받아주지 않아 즉시 에러가 발생했다. 이는 OpenCode 본체 쪽 프로바이더 어댑터 계층의 호환성 결함이며, openchamber GUI 설계 자체의 문제는 아니다. 다만 결과적으로 사용자 입장에서는 '특정 프로바이더만 작동하지 않는다'는 불공평한 경험이 되며, '서드파티 모델이 2등 시민'이라는 원래 주장에 부분적인 근거를 제공하는 실측 결과이다. 하지만 원인 발생 지점이 GUI 계층인지 에이전트 본체 계층인지는 분리하여 평가해야 한다고 느꼈다.

/api/config/providers를 호출하면 12개 프로바이더와 600개가 넘는 모델을 목록으로 볼 수 있다. 전환 자체는 메시지 전송 시마다 model을 지정하는 것만으로 충분했고, 세션을 넘나드는 복잡한 재설정은 필요하지 않았다. API를 직접 보는 한 '2등 시민' 느낌이 난다면 그것은 프로바이더별 API 호환성 문제(Cerebras의 예)이지, UI 설계상의 핸디캡 같지는 않다는 것이 실측 기반 평가이다.

3. 2차 개발 용이성 — 'OSS로 커스터마이징할 수 있는가'

라이선스는 MIT이며, 재배포 및 개변에 제한은 없다. 실제로 확장 포인트를 작동시켜 확인해 보았다.

커스텀 테마 (작동 확인 완료)

공식 문서대로 ~/.config/openchamber/themes/*.json에 테마 파일을 놓고 /api/config/reload를 호출하자, 앱 재시작 없이 테마가 인식되었다.

다만 처음에는 필수 필드를 일부 생략한 최소 구성의 JSON을 넣었더니, 서버 로그에 invalid theme JSON이라고만 뜨고 조용히 무시되었다(API 응답이나 사용자에게 에러 내용이 출력되지 않음). 서버 소스를 읽어보니, syntax.highlights.diffAdded 등 약 40개의 컬러 값이 필수적이었다. 'JSON 드롭인으로 재시작 불필요'라는 편리함과, '필수 필드가 많아 실패 시 피드백이 약하다'는 허술함을 모두 실측으로 알게 되었다.

플러그인 메커니즘

openchamber 자체가 OpenCode 공식 플러그인 메커니즘을 사용하여 'openchamber의 세션/스케줄링 작업을 OpenCode 측 에이전트 툴로 공개하는' 자체 확장 플러그인을 자동 생성하고 있었다. 단순한 뷰어(viewer)가 아니라, OpenCode 본체 측 에이전트에서도 openchamber의 상태를 조작할 수 있는 양방향 설계이다.

아키텍처

packages/{web,ui,electron,vscode,mobile,docs}

모노레포(monorepo) 구성이며, 공유 UI 로직은 packages/ui에 집약되어 있다. 개발자(인간 및 AI 에이전트 모두)를 위한 AGENTS.md가 상당히 엄격하게 구조화되어 있으며, 'OpenCode 공식 API를 그대로 사용한다'는 설계 지침도 명시되어 있다. OpenCode 본체 업데이트를 따라가기 쉬운 구조라고 느꼈다.

'2차 개발이 가능하다'는 것은 실측 및 코드 리딩 양면에서 타당하다고 평가할 수 있다. 다만 규모가 큰 TypeScript/React 모노레포이기 때문에, '2차 개발 가능'과 '2차 개발이 쉽다'는 동의어가 아니다. 포크(fork)하여 크게 손을 대려면 Node/React 에코시스템에 대한 숙련도가 필요한 규모이다.

제외된 후보들에 대한 평가

원래 게시물에서는 GUI가 미성숙하다는 이유로 TUI 전용 커뮤니티 제작 하네스 그룹이 제외되었으나, 그중 하나를 과거에 실제로 구동했을 때는 CLI 툴 단독으로는 최소 작업을 한 번에 완수할 수 있었다(OpenRouter를 통한 fizzbuzz 구현).

이번에 알게 된 것은 'GUI 레이어의 유무'가 독립적인 축이라는 점이다. TUI 전용 툴이 제외된 이유는 'GUI가 미성숙'했지만, 그 툴 자체도 프로바이더 비종속적 설계였기 때문에 GUI를 입히면 같은 무대에서 경쟁할 가능성은 있다. 반면 openchamber는 OpenCode 공식 SDK에 강하게 의존하는 설계라 미니멀리즘 지향의 하네스와 궁합이 좋지 않다. **'GUI가 필요하다면, 처음부터 GUI를 전제로 설계된 에코시스템이 더 합당하다'**는 것이 실제로 코드를 읽어본 후의 평가이다. GUI의 완성도 그 자체보다는 'GUI를 전제로 설계되었는지 여부'의 차이로 재해석하는 것이 실측에 더 부합하는 설명이 될 것이다.

요약

Discussion