BYOK 현실 점검: 지금 Open Design에서 깨지는 5가지

우리는 Open Design이 처음부터 BYOK라고 사람들에게 말해 왔습니다. 그건 지금도 사실입니다. BYOK 디자인 워크플로에 대한 시드 글은 동작하는 경로를 안내합니다 — daemon을 OpenAI 호환 엔드포인트로 가리키고, 키를 붙여 넣으면 끝입니다. 대다수 설정에서는 이것이 이야기의 전부이며, 앞으로도 전부로 남습니다.

하지만 “BYOK”는 단일 기능이 아닙니다. 그것은 채팅 작성기, finalize 엔드포인트, 모델 선택기, CLI 실행 경로, 그리고 분석 레이어까지 뻗어 있는 하나의 계약입니다. 그 각각은 계약이 깨질 수 있는 지점이며 — 지금 그 중 여럿이 우리 공개 트래커에 미해결 이슈로 올라와 있고, 지난 48시간 동안 사용자들이 보고한 것들입니다.

우리는 시드 글을 쓰고 거기서 멈출 수도 있었습니다. 그 대신 여기 정직한 점검이 있습니다: 이번 주에 들어온 스레드들, 무엇이 깨지는지, 왜 깨지는지, 오늘 무엇을 해야 하는지, 그리고 어느 PR(또는 로드맵 슬롯)이 그것을 고치고 있는지. 이 중 어느 것도 숨겨져 있지 않습니다. 모두 등록되고, 라벨이 붙고, 아래에 링크되어 있습니다 — 그리고 우리는 여러분이 금요일에 발표 도중에 이것들을 발견하기보다 우리에게서 읽기를 바랍니다.

약속 대 버그 목록

프레이밍이 중요합니다. 쉽게 오독하면 “BYOK는 어설프게 만들어졌다”가 되기 때문입니다. 그렇지 않습니다. 아래 다섯 개 중 어느 것도 “BYOK가 동작하지 않는다”는 버그가 아닙니다. 모두가 우리가 소유한 어댑터 — OpenAI 호환 레이어, 모델 선택기, finalize 경로 — 와 우리가 소유하지 않은 것 사이의 경계에 자리합니다: 상류 공급자의 CLI, 그들의 패키징 선택, 또는 호스트 플랫폼의 프로세스 모델입니다.

그 경계는 어떤 오픈소스 CLI 오케스트레이터에서든 현실이 사는 곳입니다. 우리는 추론을 실행하지 않고, 공급자마다 포크한 CLI를 제공하지 않으며, 모든 것을 모서리를 매끄럽게 다듬는(그리고 조용히 여러분의 토큰에 세금을 매기는) 프록시로 감싸지 않습니다. 그 자세의 대가는, 공급자의 CLI가 형태를 바꾸거나 Windows가 macOS에는 없는 제한을 강제할 때 이음새가 드러난다는 것입니다. 이번 주에는 그 이음새 다섯 개가 한꺼번에 드러났습니다.

들어온 순서대로 다섯 개 모두 여기 있습니다.

Gemini가 “Finish Design”으로 가는 길에서 길을 잃다

Issue #1619 — bug, open

증상

Gemini용으로 BYOK가 구성되어 있습니다. 설정의 연결 테스트가 성공합니다. 모델 선택기가 Gemini 모델을 반환합니다. 일반 채팅도 동작합니다 — 자신의 Gemini 키로 문제없이 온전한 대화를 나눌 수 있습니다. 하지만 사용자가 Finish Design을 누르는 순간, daemon이 마치 갑자기 어느 공급자와 대화하고 있었는지 잊은 듯이 Anthropic 형태의 오류를 던집니다.

왜 일어나는가

스레드의 메인테이너 답변이 이를 확인해 줍니다: 일반 API 모드 채팅은 선택된 Gemini BYOK 공급자를 끝까지 존중하지만, Finish Design은 아직 Anthropic 호환 finalize 경로 너머로 일반화되지 않았습니다. 다른 모든 것은 각 상류의 방언을 말할 줄 아는 공급자 인식 프록시를 통해 라우팅됩니다. Finish Design은 여전히 이전 릴리스에서 남겨진 하드코딩된 Anthropic finalize 엔드포인트를 거칩니다 — 그래서 Anthropic이 아닌 형태로 도착하는 Gemini 응답이 파서를 걸려 넘어뜨립니다.

우회 방법

Gemini를 Anthropic 호환 공급자 슬롯 아래에서 OpenRouter를 통해 라우팅하세요. 그러면 Finish Design 경로는 OpenRouter의 심에서 돌아오는 Anthropic 형태의 응답을 보게 되고 올바르게 finalize합니다. 추가 홉이 생기고 Gemini를 직접 호출하는 대신 OpenRouter의 라우팅 비용을 지불하게 되지만, 오늘 안정적이며 이미 동작하는 채팅 경로를 건드리지 않고 깨진 그 한 경로만 커버합니다.

누가 고치고 있는가

Finish Design 일반화는 현재 BYOK 로드맵에 P1으로 올라 있습니다. 아직 PR은 없습니다 — 이것이 daemon 팀이 다음에 착수할 일이며, 다섯 개 중에서 경계 불일치가 아니라 우리가 온전히 소유한 코드의 결함인 유일한 항목입니다.

Gemini 3 Flash가 Windows에서 프롬프트가 도달하기 전에 죽다

Issue #1611 — bug, open

증상

Gemini 3 Flash Preview가 Windows에서 Open Design 내부에서 약 1.5초 후 stdin: write EOF와 함께 실패합니다 — 프롬프트가 모델에 도달하기도 전에 말이죠. Gemini 3 Pro는 정확히 같은 설치에서 잘 동작합니다. 그리고 직접 실행한 Gemini CLI(gemini --model gemini-3-flash-preview ...)는 GEMINI_CLI_TRUST_WORKSPACE=true가 설정되어 있으면 성공합니다. 따라서 키 문제도, 계정 문제도, 단독으로 본 CLI의 문제도 아닙니다.

왜 일어나는가

진단에는 두 번의 시도가 필요했는데, 이런 문제들이 어떻게 풀리는지를 보여주는 좋은 사례라 보여드릴 가치가 있습니다. 보고자의 스크린샷을 처음 읽었을 때는 상류의 429 RESOURCE_EXHAUSTED 할당량 오류처럼 보였습니다. OD_GEMINI_3_FLASH_OK를 stdout에 기록하는 깨끗한 PowerShell 재현 후 그림이 바뀌었습니다: 모델은 도달 가능하고, CLI는 건강하며, 실패는 특정하게 Open Design → Gemini CLI 실행 경로에 있고, Windows의 Flash 변종에 특정적입니다. Pro는 같은 실행 경로를 거치는데도 살아남고, Flash는 그렇지 못합니다.

우회 방법

모델 선택기에서 Gemini 3 Pro Preview를 선택하세요. 같은 실행 경로를 거치며 동작합니다. 별개로 — 그리고 이 부분이 버그 자체보다 더 많은 시간을 잡아먹었는데 — ~/.gemini/hooks/를 확인하세요. 느린 gsd-check-update.js 훅(Hook execution error: Hook timed out after 60000ms)이 이 사용자의 경우 매 실행마다 대략 104초의 오버헤드를 더하고 있었고, 이는 Flash 실패와는 완전히 무관했습니다. 어쨌든 Gemini 훅을 정리하세요. 멈춰버린 업데이트 확인 훅은 어떤 에이전트든 고장 난 것처럼 느끼게 만듭니다.

누가 고치고 있는가

Flash 특정적이고 OD 측 문제로 표시되었습니다. daemon의 stdin 쓰기 경로에 대한 조사가 진행 중입니다 — write EOF는 daemon이 프롬프트 쓰기를 마치기 전에 자식 프로세스의 stdin이 닫혔다는 뜻이므로, 수정은 그 특정 변종이 어떻게 spawn되는지에 있습니다.

DeepSeek TUI는 Windows에서 30 KB 프롬프트 한도가 있다

Issue #1610 — bug, open

증상

Windows 패키지 빌드의 DeepSeek 래퍼 v0.8.33에서, 길게 작성된 프롬프트가 우리의 사전 점검 가드에 81397 > 30000 bytes로 실패합니다. 사용자는 아무 잘못도 하지 않았습니다 — 단지 30 KB를 넘길 만큼 풍부한(시스템 컨텍스트, 디자인 시스템, 참조 자료) 프롬프트를 작성했을 뿐입니다.

왜 일어나는가

그 가드는 의도적이며, 더 나쁜 오류로부터 여러분을 보호하고 있습니다. DeepSeek TUI 어댑터는 현재 프롬프트를 위치 기반 명령줄 인자로 — argv에 묶여 — 보내는데, Windows는 전체 명령줄을 macOS와 Linux보다 훨씬 낮은 수준에서 제한합니다. 사전 점검이 없으면 같은 프롬프트는 나중에, spawn의 더 깊은 곳에서, 훨씬 덜 유용한 ENAMETOOLONG 오류와 함께, 원인이 프롬프트 크기라는 어떤 단서도 없이 실패합니다. 그래서 우리는 일찍 실패하고 그 숫자를 명시합니다. 이 이슈가 드러낸 불일치는 문서에 있습니다: 상위 수준 안내는 Windows 긴 프롬프트 폴백이 광범위하게 적용된다고 암시하지만, DeepSeek TUI 경로에는 아직 그것이 없습니다 — 그 전송 방식은 여전히 argv이지 stdin이나 프롬프트 파일이 아닙니다.

우회 방법

DeepSeek TUI 어댑터로 Windows를 쓰고 있다면, 작성한 프롬프트를 30 KB 미만으로 유지하거나, stdin 기반 어댑터로 전환하세요 — Claude Code, Codex, OpenCode는 모두 프롬프트를 stdin으로 받으며 비교할 만한 한도가 없습니다. macOS와 Linux에서는 이 이슈가 전혀 물지 않습니다. 거기서는 argv 제한이 충분히 높아 실제 프롬프트가 거기에 도달하지 않습니다.

누가 고치고 있는가

올바른 수정은 DeepSeek TUI 어댑터를 위한 stdin 또는 프롬프트 파일 전송 방식으로, argv 한도를 완전히 제거하고 stdin 어댑터들과 보조를 맞추게 합니다. 어댑터 팀의 큐에서 추적되고 있습니다.

OpenCode 로컬 CLI 테스트가 모델이 워밍업되기 전에 타임아웃되다

Issue #1603 — bug, priority:p0, open

증상

Settings → BYOK → OpenCode에서, 연결 테스트가 어김없이 45초에 타임아웃됩니다. 이상한 점: 사용자가 먼저 OpenCode Desktop의 터미널을 열고 거기에 로컬 LLM을 붙이면, 같은 Open Design 테스트가 다음 시도에서 성공합니다.

왜 일어나는가

그 “먼저 Desktop 터미널을 연다”는 디테일이 단서의 전부입니다. Open Design은 실행 중인 OpenCode Desktop 세션에 붙지 않습니다. 설정 스모크 테스트를 위해 daemon은 자신만의 새로운 OpenCode CLI 하위 프로세스를 spawn하고 ok 응답을 기다립니다. 차가운 로컬 모델 — 아직 메모리에 로드되지 않은 모델 — 의 경우, 그 첫 응답은 45초 예산보다 오래 걸릴 수 있는데, 모델이 무언가에 답하기 전에 디스크에서 읽혀 워밍업되고 있기 때문입니다. Desktop 터미널을 열고 프롬프트 하나에 답하게 하면 OS 캐시에서 모델이 워밍업되어, daemon의 새 하위 프로세스가 곧바로 그 이점을 누릴 수 있게 됩니다. 그래서 이것은 사실 OpenCode 버그가 아닙니다. 로컬 모델에 대해 잘못된 콜드 스타트 타이밍 가정입니다.

우회 방법

Open Design에서 OpenCode를 테스트하기 전에, OpenCode Desktop을 열고 로컬 LLM을 붙인 다음, 프롬프트 하나에 답하게 하세요. 그런 다음 OD 연결 테스트를 실행하세요 — 모델이 따뜻해져 있어 응답이 예산 안에 도착합니다. v0.7.0부터는 연결 테스트 예산도 구성 가능하므로, 로컬 모델이 정말로 느리게 로드된다면 손으로 워밍업하는 대신 그 창을 늘릴 수 있습니다.

누가 고치고 있는가

daemon 측 수정은 로컬 모델 어댑터에 특정한 더 길거나 구성 가능한 워밍업 창으로, 차가운 로컬 모델이 호스팅된 API와 같은 시계로 평가받지 않게 합니다. p0으로 추적되고 있습니다 — 다섯 개 중 최고 우선순위인데, 로컬 모델 사용자가 바로 BYOK가 봉사하려는 대상이기 때문입니다.

패키지된 웹 앱이 평문 HTTP로는 로드를 거부하다

Issue #1620 — bug, open

증상

약간 다른 버그, 같은 계열입니다. 보고자는 LAN IP에서 평문 HTTP로 패키지된 웹 앱을 실행하고 있는데, 페이지가 로드 시 예외를 던집니다 — 사용 가능한 상태에 결코 도달하지 못합니다.

왜 일어나는가

PR #1428 이후, 분석 공급자와 PDF 내보내기 nonce가 crypto.randomUUID()를 직접 호출하기 시작했고, 보안 crypto API를 사용할 수 없을 때 우아하게 폴백하는, PR #900에서 도입된 계층형 헬퍼를 우회했습니다. Chromium은 보안 컨텍스트가 아닌 곳에서는 crypto.randomUUID를 노출하지 않습니다 — 그리고 평문 HTTP의 맨 LAN IP는 Chromium의 정의상 보안 컨텍스트가 아닙니다. 그래서 직접 호출이 로드 시점에 예외를 던지고, 페이지가 그와 함께 다운됩니다. 엄밀히 BYOK 버그는 아니지만, 정확히 같은 대상을 뭅니다: 자신의 인프라를 운영하는 사람들, 종종 에어갭 환경에서, 종종 평문 HTTP로 — 내부 도구에 인증서를 세우는 것이 그 마찰만큼의 가치가 없기 때문입니다.

우회 방법

웹 앱을 HTTPS로 또는 localhost로 제공하세요. 둘 다 Chromium의 보안 컨텍스트 요구를 만족하며 — localhost는 인증서 없이도 보안으로 취급됩니다 — 페이지가 정상적으로 로드됩니다. 빠른 내부 설정에는 localhost가 비용 제로의 경로이고, LAN 접근에는 HTTPS 위의 자체 서명 인증서가 더 오래가는 경로입니다.

누가 고치고 있는가

PR #1621은 남은 호출 지점들을 PR #900의 계층형 UUID 헬퍼를 다시 거치도록 라우팅하여, 보안 컨텍스트 폴백이 이미 연결되어 있던 곳에서만이 아니라 다시 모든 곳에 적용되게 합니다. 열려 있고 리뷰 중입니다.

이것이 Open Design의 BYOK에 대해 실제로 말해주는 것

이 목록을 품질 판결이 아니라 계약 지도로 읽으세요. 이 다섯 개 중 넷은 어댑터 경계에 자리합니다 — Gemini의 CLI 실행 경로, DeepSeek의 argv에 묶인 CLI 전송, OpenCode의 콜드 스타트 실행 모델, 호스트 플랫폼의 보안 컨텍스트 규칙. 다섯 번째인 Finish Design 건은 우리 자신의 finalize 엔드포인트에 있는데, 한 릴리스 전에 Anthropic 형태의 응답을 하드코딩했고 아직 일반화하지 않았습니다. 그건 우리 책임입니다. 나머지 넷은 여러분이 만들지 않은 도구를 존중하는 대가로 치르는 세금입니다.

그리고 그것이 구조적 핵심입니다. 리브랜딩된 프록시가 아닌 모든 BYOK 시스템은 결국 여기에 다다릅니다. 여러분은 추론을 소유하거나 — 그러면 BYOK를 잃습니다, 이제 토큰을 사서 마진을 붙이는 쪽이 여러분이니까 — 아니면 상류 도구를 존중하고 그 모서리들을 물려받습니다: 그들의 CLI, 그들의 패키징 별난 점들, 각자 다르게 다루는 플랫폼 제한들. 우리는 두 번째 자세를 의도적으로 골랐고, 다시 고를 것입니다. 그 비용은 이번 주 같은 주들입니다 — daemon과 어댑터 팀이 이틀 동안 다섯 개 표면에 걸쳐 작업을 등록한 그런 주 말이죠.

이 거래는 여전히 옳습니다. macOS의 Claude Code, Codex, Cursor, Gemini Pro, 그리고 Linux의 DeepSeek에서 동작하는 설정 — 우리 실제 사용자의 대략 90%를 커버하는 매트릭스 — 은 오늘 깔끔하게 돌아가며, 프록시 세금도 없고 여러분의 토큰에 붙는 마진도 없습니다. 위의 다섯 스레드는 2026년 5월 중순 그 매트릭스의 나머지 10%가 어떻게 생겼는지를 보여줍니다: 이름이 붙고, 등록되고, 각각 수정이 진행 중입니다. 정직한 이음새가, 청구서가 어디로 가는지 숨기는 매끄러운 표면보다 낫습니다.

오늘 무엇을 쓸까 (매트릭스)

이것은 위 섹션의 실용 버전입니다 — 같은 다섯 이음새를, 지금 당장 손대도 안전한 것에 매핑한 것입니다. ✓는 그 경로가 있는 그대로 동작한다는 뜻이고, ✗는 그것을 막고 있는 이슈로 링크되며, 우회 방법은 해당 섹션에 있습니다.

공급자	macOS	Linux	Windows	Finish Design 경로
Claude Code (Sonnet / Opus)	✓	✓	✓	네이티브
Codex	✓	✓	✓	네이티브
Cursor (BYOK)	✓	✓	✓	네이티브
Gemini 3 Pro Preview	✓	✓	✓	OpenRouter 심 (#1619)
Gemini 3 Flash Preview	✓	✓	✗ (#1611)	OpenRouter 심 (#1619)
DeepSeek (API)	✓	✓	✓	OpenRouter 심
DeepSeek TUI (긴 프롬프트)	✓	✓	✗ (#1610)	OpenRouter 심
OpenCode (로컬 모델)	✓	✓	✓ (먼저 워밍업, #1603)	해당 없음

이 표를 읽는 두 가지 방식. 여러분의 스택이 전부 ✓인 블록에 있다면 — Claude Code, Codex, Cursor, 또는 Gemini Pro — 여러분은 깔끔한 경로에 있고 위의 어떤 것도 여러분의 하루를 바꾸지 않습니다. ✗ 행 중 하나에 있다면, 해당 섹션에 링크된 수정이 도착할 때까지 오늘 돌아가게 해줄 우회 방법이 있습니다. 어느 쪽이든, 행이 ✗에서 ✓로 뒤집힐 때 알림을 받고 싶다면 트래커의 BYOK 라벨을 구독하세요.

다음에 할 일

Open Design의 skills 라이브러리는 이 모든 것 밑에 깔린 동작 레이어입니다 — 연결이 건강해지면 BYOK 어댑터가 먹여 넣는 파일 기반 계약들입니다. 위의 이음새들은 여러분의 키에서 모델로, 다시 돌아오는 바이트를 옮기는 것에 관한 것이고, skills는 모델이 그것들로 실제로 무엇을 하는지입니다. 스킬이 모델에서 무엇을 소비하고 무엇을 신경 쓰지 않는지 — 이것이 또한 왜 이 어댑터 모서리들이 출력을 바꾸지 않고 여러분이 그것에 도달하는지 여부만 바꾸는지의 이유이기도 한데 — 보고 싶다면, 그 디렉터리가 시작하기에 알맞은 곳입니다.

skills 라이브러리 둘러보기.

관련 읽을거리

• BYOK 디자인 워크플로: 자신의 키로 Claude, Codex, 또는 Qwen 실행하기 — 원래의 BYOK 설명 글이자, 위 다섯 이음새가 그 가장자리에 자리한 동작 경로
• 우리가 Open Design을 제품이 아니라 스킬 레이어로 만든 이유 — 왜 우리가 상류 도구를 프록시로 감싸는 대신 존중하는지, 이것이 바로 이 경계들이 존재하는 이유
• 31개 스킬, 72개 시스템 — 라이브러리가 동작하는 방식 — 연결이 건강해지면 BYOK가 실제로 무엇에 먹여 넣는지