Skip to content
←

Split View: DeepSeek Harness의 플러그인 커널 구조 — 되감을 수 있는 에이전트는 무엇이 다른가

✨ Learn with Quiz
|

DeepSeek Harness의 플러그인 커널 구조 — 되감을 수 있는 에이전트는 무엇이 다른가

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 DeepSeek Harness developer preview, 아이템 번호는 49285244이고 2026-08-15 기준 718점에 댓글 297개입니다. 링크는 DeepSeek의 Harness 소개 페이지입니다. GeekNews 피드에도 같은 항목이 올라와 있었습니다.

댓글 중 하나는 작성자 본인이 남긴 것으로, 아직 초기 개발자 프리뷰이고 거친 부분과 호환성이 깨지는 변경이 많을 것이라고 밝히고 있습니다. 라이선스는 MIT입니다.

모든 것이 플러그인이라는 문장

소개 페이지의 핵심 주장은 모든 것이 플러그인이라는 것입니다. 그리고 그 목록이 구체적입니다. 모델, 도구, 스킬, 세션, 샌드박스, 스토리지, 루프, 스케줄링, 그리고 UI까지 전부 플러그인이 제공한다고 적혀 있습니다.

이 목록에서 눈에 띄는 것은 뒤쪽입니다. 도구를 플러그인으로 만드는 것은 흔합니다. 그런데 루프와 스케줄링과 UI까지 플러그인이라는 것은 에이전트의 제어 흐름 자체를 교체 가능한 것으로 취급하겠다는 뜻입니다.

이것을 관리하는 층은 Cordis라는 커널이라고 소개되어 있습니다. 플러그인의 장착과 해제, 의존 관계를 담당하고, 플러그인끼리는 Cordis의 서비스와 이벤트로 통신합니다.

댓글에서 이 부분의 배경이 보충됐습니다. Cordis가 이번에 처음 나온 것이 아니고 다른 프로젝트에서 수년간 쓰여 온 플러그인 시스템이며, 핵심은 동작 중인 프로세스를 재시작하지 않고 플러그인을 올리고 내리는 것이라는 설명이었습니다. 그리고 내릴 때 그 플러그인이 만든 상태와 부수 효과를 되돌린다는 점이 특징으로 언급됐습니다.

되돌릴 수 있는 해제가 왜 어려운 문제인가

플러그인을 올리는 것은 쉽습니다. 어려운 것은 내리는 것입니다.

플러그인 하나가 살아 있는 동안 무엇을 하는지 생각해 보면 됩니다. 이벤트 구독을 걸고, 소켓을 열고, 타이머를 등록하고, 다른 플러그인이 참조하는 서비스를 등록합니다. 그냥 참조만 끊으면 이 중 어느 것도 사라지지 않습니다. 타이머는 계속 돌고 구독은 계속 호출됩니다.

그래서 대부분의 플러그인 시스템은 실질적으로 한 방향입니다. 올릴 수는 있고 내리려면 재시작합니다. 그런데 에이전트에서는 재시작이 비쌉니다. 진행 중인 세션과 쌓아 둔 문맥이 날아가기 때문입니다.

Harness가 플러그인에 해제 처리기를 요구한다는 점이 여기서 의미를 갖습니다. 정리를 선택 사항이 아니라 계약으로 만든 것입니다. 이렇게 하면 세션 도중에 도구 하나를 갈아 끼우거나, 문제를 일으키는 플러그인만 내리고 나머지는 그대로 두는 일이 가능해집니다. 우리 시스템에 옮기면 질문은 이렇게 됩니다. 우리 에이전트에서 도구 하나를 바꾸려면 무엇이 죽어야 하는가. 대개는 프로세스 전체입니다.

진짜 특징은 이벤트 로그입니다

소개 페이지에서 가장 실무적인 부분은 추적입니다. 모델이 보는 모든 것을 추가 전용 세션 로그에 남긴다고 적혀 있습니다. 목록은 시스템 프롬프트, 추론, 도구 호출과 그 결과, 서브에이전트 스케줄링, 그리고 모든 문맥 주입입니다.

마지막 항목이 중요합니다. 문맥 주입까지 기록한다는 것은 에이전트 디버깅에서 가장 흔한 미궁을 없애 줍니다.

에이전트가 이상하게 행동할 때 우리가 보는 것은 보통 우리가 쓴 프롬프트입니다. 그런데 모델이 실제로 받은 것은 그 프롬프트에 시스템이 덧붙인 여러 조각이 합쳐진 결과입니다. 이전 요약, 검색 결과, 파일 내용, 도구 설명 같은 것들입니다. 이 조각들이 언제 어떤 순서로 들어갔는지 남지 않으면, 우리는 우리가 쓴 것을 보면서 우리가 보내지 않은 것의 결과를 설명하려 애쓰게 됩니다.

그리고 소개 페이지는 이 로그 위에서 재개, 분기, 검색, 재생이 모두 같은 이벤트 스트림으로 동작한다고 적고 있습니다. 이 문장이 설계의 핵심입니다. 네 가지 기능을 따로 만든 것이 아니라 하나의 자료 구조에서 파생시킨 것입니다. 한 댓글은 이 추적 기능을 이 프로젝트에서 가장 좋은 부분으로 꼽으면서, 상용 서비스에서는 대개 이런 수준의 원본 기록에 접근할 수 없다는 점을 함께 지적했습니다.

네 가지 실행 모드

소개 페이지는 네 가지 모드를 제시합니다.

  • 표준 모드: 파일 편집, 셸, 검색, 계획 수립, 서브에이전트를 포함한 전체 도구 집합입니다.
  • 코드 모드: 여러 단계를 조율하기 위해 모델이 TypeScript 코드를 생성해서 실행합니다.
  • 최소 모드: 배시 셸과 파일 편집기만 남깁니다. 벤치마킹 용도라고 명시되어 있습니다.
  • 크리에이터 모드: 사용자 정의 프리셋을 만들고 런타임을 들여다보며 플러그인을 실험합니다.

최소 모드에 벤치마킹이라는 용도가 명시된 것이 흥미롭습니다. 에이전트 벤치마크에서 점수의 상당 부분이 모델이 아니라 하네스에서 온다는 사실은 널리 알려져 있습니다. 도구를 최소로 고정한 모드를 따로 두면 모델 자체의 기여와 도구의 기여를 분리해서 잴 수 있습니다. 자체 평가를 돌리는 팀이라면 이 발상은 그대로 가져다 쓸 만합니다.

실행 형태는 다음과 같고 Node.js가 필요합니다. 전체 소스는 deepseek-ai/deepseek-harness 저장소에 있습니다.

# 예시: 소개 페이지에 적힌 실행 형태
npx @deepseek-ai/dsh web

댓글에서 나온 반론

가장 날카로운 반론은 플러그인 구조 자체를 향했습니다. 한 댓글은 커뮤니티 플러그인에 기능을 의존하는 제품이 초반 몇 달은 잘 돌아가지만 이후에는 호환되지 않고 방치된 플러그인이 쌓이며 일관성도 관리 주체도 없어진다고 적었습니다.

이 지적은 무시하기 어렵습니다. 실제로 여러 생태계에서 반복된 일이기 때문입니다. 다만 정확히 보면 이 위험은 플러그인 구조 때문이 아니라 플러그인이 확장 지점이면서 동시에 기본 기능일 때 생깁니다. 핵심 기능이 서드파티 플러그인으로만 제공되면 그 플러그인이 방치되는 순간 제품에 구멍이 납니다.

또 다른 댓글은 이것이 대체 무엇이냐고 물으면서 README가 설치 안내 외에는 비어 있다고 지적했습니다. 아키텍처가 좋아도 그것으로 무엇을 만들 수 있는지 보이지 않으면 채택되지 않습니다.

어떻게 적용하나

이 프로젝트를 당장 도입하지 않더라도 가져갈 것이 두 가지 있습니다.

첫째, 모델에게 실제로 전달된 것을 그대로 남기는 일입니다. 대부분의 팀은 프롬프트 템플릿과 최종 응답만 기록합니다. 조립이 끝난 최종 입력과 도구 호출 결과, 그 사이에 시스템이 끼워 넣은 모든 것을 순서대로 남기면 재현할 수 없던 버그의 상당수가 재현 가능해집니다. 저장 비용이 걱정된다면 실패한 세션부터 남기면 됩니다.

둘째, 평가용 최소 구성을 따로 만드는 일입니다. 도구를 최소로 고정한 프로필을 하나 두면 모델을 바꿀 때 성능 변화가 모델에서 온 것인지 도구에서 온 것인지 구분할 수 있습니다.

누구에게는 해당 없는가

에이전트를 직접 만들지 않고 완성된 코딩 도구를 쓰는 팀이라면 이 구조는 참고 사항입니다. 다만 그 경우에도 세션 기록에 접근할 수 있는지는 도구를 고를 때 확인할 만한 기준입니다.

단발성 작업만 처리하는 에이전트도 해당이 적습니다. 세션이 짧고 실패하면 그냥 다시 돌리면 되는 구조에서는 재개와 분기가 필요 없습니다. 이 설계의 가치는 세션이 길고 문맥을 다시 쌓는 비용이 클 때 나옵니다. 프리뷰 단계라는 점도 그대로 받아들여야 합니다. API가 바뀔 수 있다고 저자가 직접 밝혔으므로, 지금 이것 위에 제품을 올리는 것은 그 변경을 따라갈 여력이 있을 때만 합리적입니다.

정리

이 프로젝트에서 오래 남을 아이디어는 모든 것이 플러그인이라는 구호가 아닙니다. 에이전트의 실행을 하나의 추가 전용 스트림으로 표현하면 재개와 분기와 재생이 따로 만들 기능이 아니라 그 표현의 결과가 된다는 점, 그리고 플러그인을 내릴 때의 정리를 계약으로 강제하면 재시작 없이 시스템을 바꿀 수 있다는 점입니다. 둘 다 에이전트에만 해당하는 이야기가 아닙니다.

원문과 관련 글

해제 처리기와 이벤트 로그에 대한 해석, 그리고 적용 방법은 소개 페이지와 댓글에서 확인한 내용을 바탕으로 제가 정리한 것입니다.

The Plugin Kernel Architecture of DeepSeek Harness — What Makes an Agent You Can Rewind

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is DeepSeek Harness developer preview, the item number is 49285244, and as of 2026-08-15 it stood at 718 points with 297 comments. The link points to DeepSeek's Harness page. The same item appeared in the GeekNews feed.

One of the comments is from one of the authors, saying this is only an early developer preview and to expect many rough edges and compatibility-breaking changes. The license is MIT.

The sentence "everything is a plugin"

The central claim on the page is that everything is a plugin, and the list is specific. Models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI are all said to be provided by plugins.

What stands out is the back half of that list. Making tools into plugins is common. But loops, scheduling, and the UI as plugins means treating the agent's own control flow as replaceable.

The layer that manages this is introduced as a kernel called Cordis. It handles mounting, unmounting, and dependencies, and plugins communicate with each other through Cordis services and events.

The comments filled in the background. Cordis did not appear for the first time here; it is a plugin system that has been used in another project for years, and the core of it is loading and unloading plugins without restarting a running process. That it reverts the state and side effects a plugin created when it unloads was named as its distinguishing feature.

Why an undoable unload is a hard problem

Loading a plugin is easy. Unloading is the hard part.

Think about what a plugin does while it is alive. It attaches event subscriptions, opens sockets, registers timers, and registers services other plugins reference. Dropping the reference removes none of that. The timers keep firing and the subscriptions keep getting called.

That is why most plugin systems are effectively one-directional. You can load, and to unload you restart. But in an agent, restarting is expensive, because the session in flight and the context you accumulated go with it.

This is where requiring teardown handlers matters. It makes cleanup a contract rather than an option. With it, you can swap a single tool mid-session, or unload only the plugin that is misbehaving and leave the rest running. Carried to your own system the question becomes: to change one tool in our agent, what has to die? Usually the whole process.

The real feature is the event log

The most practical part of the page is tracing. Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and their results, subagent scheduling, and every context injection.

That last item matters. Recording context injections too removes the most common dead end in agent debugging.

When an agent behaves strangely, what we look at is usually the prompt we wrote. But what the model actually received is that prompt plus several fragments the system appended — earlier summaries, search results, file contents, tool descriptions. If there is no record of when those went in and in what order, we end up staring at what we wrote while trying to explain the consequences of what we did not send.

And the page says resume, fork, search, and replay all operate on that same event stream. That sentence is the heart of the design. The four capabilities were not built separately; they were derived from one data structure. One comment picked this tracing out as the best part of the project, noting that commercial services generally do not let you reach raw records at that level.

Four runtime modes

The page presents four modes.

  • Standard mode: the full toolset, with file editing, shell, search, planning, and subagents.
  • Code mode: the model generates TypeScript to orchestrate multi-step operations.
  • Minimal mode: only a bash shell and a file editor. Explicitly stated to be for benchmarking.
  • Creator mode: building custom presets, inspecting the runtime, and experimenting with plugins.

It is interesting that minimal mode names benchmarking as its purpose. It is now widely understood that a large share of the score in agent benchmarks comes from the harness rather than the model. Keeping a mode with tools pinned to a minimum lets you measure the model's contribution separately from the tooling's. If you run your own evaluations, that idea alone is worth taking.

The launch form is below and Node.js is required. The full source lives in the deepseek-ai/deepseek-harness repository.

# Example: the launch form given on the page
npx @deepseek-ai/dsh web

The objection from the comments

The sharpest objection went at the plugin structure itself. One comment wrote that products that depend on community plugins for their features work fine for the first six months and then accumulate incompatible, abandoned plugins with no consistency and no governance.

That is hard to dismiss, because it has happened repeatedly across ecosystems. Seen precisely, though, the risk comes not from the plugin structure but from plugins being both the extension point and the base functionality. When core features ship only as third-party plugins, the moment one is abandoned there is a hole in the product.

Another comment simply asked what this actually is, noting that the README is bare apart from installation instructions. Good architecture that does not show what you can build with it does not get adopted.

How to apply this

Even if you do not adopt the project, two things are worth taking.

First, record what was actually sent to the model. Most teams log the prompt template and the final response. Log the fully assembled input, the tool call results, and everything the system slipped in between, in order, and a large share of previously irreproducible bugs become reproducible. If storage cost worries you, start with failed sessions.

Second, build a separate minimal configuration for evaluation. Keeping one profile with tools pinned to a minimum lets you tell whether a performance change on a model swap came from the model or from the tooling.

Who this does not apply to

If you use a finished coding tool rather than building agents, this structure is background. Even so, whether you can reach the session record is a reasonable criterion when choosing a tool.

Agents that handle only one-shot tasks are also largely outside this. When sessions are short and a failure just means running it again, resume and fork are not needed. This design earns its value when sessions are long and rebuilding context is expensive. The preview status should be taken at face value too. The author says the API may change, so building a product on this now is only sensible if you have the capacity to follow those changes.

Summary

The idea that lasts here is not the slogan that everything is a plugin. It is that representing an agent's execution as a single append-only stream turns resume, fork, and replay from features you build into consequences of that representation, and that making teardown a contract lets you change a running system without restarting it. Neither is specific to agents.

Sources and related reading

The reading of teardown handlers and the event log, and the application advice, are my own, built on what I read on the page and in the comments.