DeepSeek Harness, 모든 agent 기능을 plugin으로 쪼갠 이유

DeepSeek Harness는 완성된 coding agent보다 agent를 조립하는 기반에 가깝다. model, tool, skill, session, sandbox, storage, loop, scheduling, UI를 모두 plugin으로 다루고, Cordis kernel이 이들의 mounting과 dependency를 관리한다. 설정만 바꿔 각 기능을 선택하거나 교체하고, Harness 본체를 수정하지 않은 채 확장하는 구상이다. 개발자 미리보기 소식이 Hacker News에서 710점과 290개가 넘는 댓글을 모은 배경에는 “Everything is a plugin”이라는 선명한 설계 선택이 있다.

재현성을 위한 기록 방식도 눈에 띈다. model이 본 모든 내용을 append-only session log에 남긴다. system prompt, reasoning, tool call과 결과, subagent scheduling, context injection이 같은 event stream에 쌓인다. Trajectory 화면에서는 기록의 출처를 구분해 살펴볼 수 있고, resume, fork, search, replay도 이 stream을 기준으로 동작한다. agent가 왜 특정 행동을 했는지 추적하기 어려운 현실에서, 실행 이력을 제품의 중심 자료 구조로 둔 셈이다.

실행 환경은 네 가지 mode로 나뉜다. Standard mode는 file editing, shell, 검색, planning, goal, subagent, workflow를 포함한 전체 coding agent다. Code mode는 model이 만든 코드로 여러 차례의 tool call을 조율한다. Minimal mode는 persistent bash와 str_replace_editor라는 두 도구만 남겨 model 자체를 비교하기 쉽게 만든다. Creator mode는 현재 runtime을 들여다보고 Cordis plugin을 memory에서 시험한 뒤 새로운 preset을 구성하도록 설계됐다. 같은 kernel 위에서 제품용 환경과 benchmark용 환경을 분리할 수 있다는 의미다.

도입 전에는 작은 preset 하나로 경계를 시험하는 편이 안전하다. 예를 들어 읽기 전용 repository와 제한된 shell만 연결하고, 같은 task를 resume와 fork에서 반복해 event stream이 동일한 판단 근거를 제공하는지 확인할 수 있다. plugin을 바꿨을 때 log 형식과 session 복원이 유지되는지도 중요하다. 관찰 화면이 자세하더라도 권한 정책과 실패 복구가 plugin마다 달라지면 운영자는 다시 여러 층의 상태를 맞춰야 한다.

이 구조의 장점은 조합 가능성이지만, 검증할 부분도 바로 그 경계에 있다. plugin 간 권한, version 호환성, event log에 남는 민감한 정보, replay가 외부 시스템에 미치는 영향을 운영자가 정의해야 한다. 개발자 미리보기 단계라 core plugin과 API가 계속 바뀔 수 있다는 안내도 있다. 현재 코드는 MIT license로 공개됐고, 웹 실행은 npx @deepseek-ai/dsh web, 직접 확인은 GitHub repository 복제로 시작할 수 있다. 흥미로운 질문은 기능 수가 아니라, 이 plugin 구조가 복잡한 agent 실행을 실제로 더 이해하기 쉽고 재현 가능하게 만드느냐다.