Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드✨Start Quiz
공유하기
Authors

이 글은 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가 바뀔 수 있다고 저자가 직접 밝혔으므로, 지금 이것 위에 제품을 올리는 것은 그 변경을 따라갈 여력이 있을 때만 합리적입니다.

정리

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

원문과 관련 글

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

Discuss on Twitter • View on GitHub