로드맵

순서

1. ClaudeAdapter를 먼저 정확히 옮긴다. ✅ 완료.
2. 두 번째 어댑터를 붙이며 공통 계약을 뽑아낸다.
3. 그 뒤에 AbstractAdapter를 확정한다.

ActiveRecord도 MySQL 하나로 시작했습니다.

왜 이 순서인가

프로바이더별 차이 — codex의 threadId, 그리고 나머지가 다르게 쓰는 것으로 드러날 무엇이든 — 는 두 번째 어댑터를 붙일 때 비로소 드러납니다. Claude 하나만 보고 설계한 공통 계약은 추상화의 탈을 쓴 추측입니다.

그래서 하위 클래스가 하나뿐인 동안 AbstractAdapter는 의도적으로 작게 유지됩니다.

abstract class AbstractAdapter {
  abstract get command(): string;
  abstract buildArgv(options: SpawnOptions): string[];
  abstract spawn(options: SpawnOptions): ChildProcess;
  abstract parseLine(line: string): AbstractEvent | null;
  abstract reportedMode(event: AbstractEvent): PermissionMode | null;
}

하나의 구현에서 그려낸 계약은 추측입니다. 둘을 견뎌낸 모양이라야 확정할 값어치가 있습니다.

이 순서가 피하려는 실패

최대 경쟁 플러그인인 jetbrains-cc-gui(★5,315)는 ai-bridge/channels/ 아래에 6개 어댑터를 붙였습니다 — claude, codex, grok, kimi, opencode, pi. 그리고 그것들 사이에 공통 계약이 없습니다.

• Claude의 send: sessionId + disableThinking + agentPrompt
• Codex의 send: threadId + baseUrl + apiKey + serviceTier

같은 send인데 파라미터가 다르고, 명령 목록도 맞지 않습니다 — Claude는 7종, Codex는 3종. 호출자는 페이로드를 만들기 전에 자신이 누구와 이야기하는지 알아야 합니다. 그것은 통합이 아니라 한 장롱 안의 분리 수납입니다.

원인은 구조에 있습니다. export async function handleClaudeCommand(command, args, stdinData) — 함수를 모듈에 흩뿌리고, 거대한 switch로 분기하며, 상태를 인자로 계속 전달하는 방식입니다. 이것이 설계 원칙이 겨냥하는 구체적인 반대 사례이며, 함수 모듈 방식이 추상화 실패로 이어진다는 실물 증거입니다.

“지원됨”이 뜻하게 될 것

프로바이더는 spawn된다고 완성된 것이 아닙니다. 기준은 첫 소비자가 세웁니다. Swttch에서 CLI를 구동하는 모든 호출부가 대체 가능해야 합니다. Claude에 관한 한 그 목록은 완결되어 검증되었고, 상당 부분은 CI의 실제 Windows 위에서 검증되었습니다.

그래서 두 번째 어댑터가 흥미로운 것입니다. 같은 인터페이스를 통해 같은 기준에 도달해야 하며, 그러지 못하는 자리 하나하나가 계약이 틀렸던 자리입니다.

계획으로 존재하는 프로바이더

이 다섯은 숨기지 않고 사이드바에 나열되어 있습니다. 로드맵이 요점이지, 사과할 누락이 아니기 때문입니다.

프로바이더	상태
Claude	출시됨. 실제 CLI를 상대로 검증됨
Codex	계획 — 계약을 강제할 바로 그것
Grok	계획
Kimi	계획
OpenCode	계획
pi	계획

ACP는 경쟁자가 아니라 어댑터

Zed의 ACP는 2025년 12월부터 JetBrains IDE에 내장되었고 25개 이상의 에이전트를 지원합니다. 그러나 ACP는 “사람이 에디터 앞에 앉아 승인한다”를 전제하며, 프로세스 실행 문제 — 실행 파일 탐색, Windows, WSL — 를 표준화하지 않습니다. 채택자들이 그것을 미해결 상태로 짊어지고 있습니다: Zed #56176(WSL에서 ACP 서버 실행 실패), Kiro 문서는 “절대경로를 박아라”가 공식 해법이고, JetBrains AI Assistant는 WSL을 아예 지원하지 않습니다.

따라서 ACP는 경쟁 대상이 아닙니다. headless-cli가 보여주었듯, 어댑터 중 하나로 흡수할 수 있습니다.

1.0에 이르는 것

1.0은 플러그인이 CLI를 구동하는 모든 호출부가 대체 가능해질 때입니다. 왜 ActiveCLI인가의 대조표가 그 체크리스트이며, 기능 개수가 아니라 그것이 “완료”의 정의입니다.

새로 설계할 프로토콜은 없었습니다. 이미 동작하던 것을 원칙에 따라 클래스에 배치하는 일이었고, 그 과정을 실제 CLI를 상대로 수행하면서 스크립트 목(mock)이 가리고 있던 결함 셋을 잡았습니다. 새 세션을 --resume으로 시작하던 것, 권한 응답 봉투를 한 겹 덜 감싸던 것, 그리고 stderr을 버려 진단이 불가능하던 것입니다.