DeepSeek Harness가 추가한 Claude Code Mods 호환성 레이어: 포팅이 아닌 부분집합 테스트

DeepSeek은 10월 3일 오픈 소스 에이전트 하네스(dsh)의 v0.2.1-alpha.1 버전을 배포했으며, 릴리스 노트 중 한 줄이 다른 내용보다 더 많은 주목을 받을 만합니다: 실험적인 Claude Code Mods 호환성 레이어입니다. 이것은 포팅이 아닙니다. 'Mods 지원'도 아닙니다. 이 호환성 레이어의 명시된 목적은 Claude Code Mods API가 dsh 플러그인들의 대략적인 부분집합임을 검증하는 것입니다. 이러한 틀은 에이전트 설정 형식(agent config formats)이 어디로 향하고 있는지에 대해 많은 것을 알려주므로, 저는 릴리스를 면밀히 읽고 실제로 배포된 내용의 수치를 계산해 보았습니다.

정확히 무엇이 배포되었나

이 릴리스는 GitHub에서 10월 3일 06:42 UTC에 이루어졌으며, npm 패키지 @deepseek-ai/dsh는 약 두 시간 전에 게시되었습니다. dist-tags가 그 성숙도를 보여줍니다: latest는 9월 29일의 0.2.0-rc.2를 가리키고 있는 반면, Mods 레이어는 alpha 태그에만 존재합니다. 이것은 일상적인 작업에 설치하는 빌드가 아닙니다.

# 10월 3일 기준으로 Mods 호환성 레이어는 alpha 전용임
npm view @deepseek-ai/dsh dist-tags
# alpha: 0.2.1-alpha.1, latest: 0.2.0-rc.2
...

주변의 나머지 내용은 플러그인 시스템 자체에 관한 것입니다: 플러그인 관리 페이지에 있는

부분집합 테스트(subset test)는 한 방향으로 진행됩니다. DeepSeek은 다음과 같은 질문을 던지고 있습니다: Mod가 수행하는 모든 것이 dsh 플러그린(dsh plugin)으로 표현될 수 있는가? 만약 그렇다면, dsh의 플러그인 표면(plugin surface)이 Mods를 포괄하며, Mod를 플러그인에 매핑하는 것은 재설계(redesign) 문제가 아니라 번역(translation) 문제가 됩니다. 그렇지 않다면, 그 격차(gaps)는 Mods API 중 Anthropic 고유의 부분이 무엇인지 정확히 알려줍니다. 어느 답변이든 유용하며, 둘 다 오늘 당신의 Mod가 작동할 것이라는 보장은 아닙니다.

이를 OpenAI가 동일한 문제를 처리했던 방식과 비교해 보세요. Codex 플러그인이 출시되었을 때, 설정 표면(config surface)은 저장소(repo) 밖으로 이동하여 새로운 형식으로 들어갔고, MCP Extensions가 ChatGPT의 사이드바에 등장했을 때는 한 공급업체(vendor)의 플러그인 스키마에 종속된 모든 것에 대한 이식성 청구서(portability bill)가 돌아왔습니다. 저는 이 두 가지 모두에 대해 글을 썼습니다(Codex plugins, MCP Extensions). DeepSeek은 세 번째 경로를 시도하고 있습니다: 자체적으로 처음부터 작성하기 전에 기존 공급업체의 API 형태를 호환성 목표(compatibility target)로 채택하는 것입니다.

'부분집합'이 핵심 단어인 이유

Claude Code Mods는 인-프로세스 후크(in-process hooks)입니다. 이들은 에이전트가 수행하는 동작을 셸 명령어 구성이나 파일 접근과 같은 지점에서 가로채고 재구성하며, 에이전트 루프와 동일한 프로세스 내에서 실행됩니다. 우리는 Mods가 2.1.287 버전으로 출시되었을 때 그 메커니즘에 대해 다루었으며(details here), 나중에 7줄짜리 Mod가 거부 규칙(deny rule)을 무효화하는 것을 지켜보기도 했습니다(that audit).

인프로세스 훅(In-process hooks)은 플러그인 시스템에게 높은 기준입니다. 만약 dsh 플러그인이 이를 표현할 수 있다면, dsh 플러그인은 단순한 도구와 명령을 넘어 정책 그 자체가 됩니다. 이것이 '부분집합(subset)' 질문을 사소하지 않게 만들고, 제가

세 개의 공급업체가 이제 에이전트 확장 형식(agent extension formats)을 배포하고 있으며, 그중 오직 하나만이 다른 것과 부분집합 테스트를 거치고 있습니다. 여러분의 규칙 파일, 즉 마크다운(markdown)으로 된 파일들이 여전히 이식 가능한 레이어입니다: 제가 사용했던 모든 하네스(harness)는 지침 파일(instruction files)을 읽으며, 그중 어느 것도 다른 플러그인 스키마에 신경 쓰지 않습니다. 이것이 지루하지만 확실한 베팅입니다. 정책은 평문 파일에 유지하고, 훅(hooks)은 얇게 유지하며, 모든 것의 버전을 고정하는 것이 중요합니다. 이는 우리가 AgentConfig Studio($29)에서 패키징하고 Verify First에서 가르치는 것과 같은 규율입니다. 만약 부분집합 테스트가 표준이 된다면, 여러분의 플러그인 목록은 교집합(intersection)으로 줄어들고, 지침 파일들이 나머지 부분을 담당하게 됩니다.

다음으로 주목해야 할 신호는 호환성 레이어(compat layer)가 0.2.1 안정 버전까지 살아남는지, 아니면 조용히 '깔끔하게 번역된 부분'으로 축소되는지 여부입니다. 어느 쪽이든, 이 저장소(repo)의 릴리스 노트는 이제 코덱스(Codex)와 Claude Code 변경 로그 옆에 제가 매주 읽는 목록에 추가되었습니다.