저는 이번 릴리스를 두 가지를 제공하는 것으로 봅니다. 바로 즉시 사용 가능한 코딩 에이전트와 그 기반이 되는 메타 하네스 프레임워크이며, 이는 Pi가 OpenClaw와 맺는 관계와 매우 유사합니다.
이 점은 이 프로젝트를 둘러싼 일부 논란도 설명해 줄 수 있습니다. 사람들이 항상 같은 것을 논의하는 것은 아닙니다. 많은 비판자들은 전자를 평가하고 있는 반면, 저는 후자의 설계에 더 관심이 있습니다.
DeepSeek Harness는 코딩 에이전트 자체를 플러그 가능하게 만듭니다. 기업과 개발자는 개별 구성 요소를 교체하고 자신의 요구에 맞는 하네스를 조립할 수 있습니다. 또한 런타임 자기 확장과 반복적 개선을 위한 생성 모드를 제공합니다.
높은 수준에서 보면 모델은 다음과 같습니다:
- 커널은 런타임과 확장 메커니즘을 제공합니다.
- 플러그인은 교체 가능하고 조합 가능한 원자적 기능을 제공합니다.
- 기업은 커뮤니티에서 플러그인을 선택하거나 자체적으로 구축한 다음, 커널과 플러그인을 자사 요구에 맞춘 내부 하네스로 패키징합니다.
이것이 왜 중요한지 이해하려면 먼저 우리가 하네스라고 부르는 것이 무엇인지 명확히 해야 합니다.
하네스란 무엇인가?
며칠 전 InfoQ의 누군가가 저에게 이런 질문을 했습니다:
컨텍스트 관리와 작업 계획부터 MCP 도구 호출과 멀티 에이전트 오케스트레이션에 이르기까지, 하네스 기능은 점점 더 비슷해지고 있습니다. 의미 있는 혁신의 여지가 남아 있는 곳은 어디입니까?
하네스에 대한 보편적으로 받아들여지는 정의는 아직 없습니다.
제 견해는 모델이 에이전트의 기초적인 추론 및 인지 능력을 제공한다는 것입니다. 하네스는 그러한 능력이 어떻게 조직되고, 호출되며, 실제 작업에 적용되는지를 결정합니다. 모델과 하네스가 함께 에이전트의 실질적인 능력과 성능을 정의합니다.
저는 하네스를 두 계층으로 나눕니다.
좁은 의미의 하네스는 코딩 에이전트가 작업을 완료하도록 돕는 런타임 프레임워크입니다. 여기에는 컨텍스트 관리, 메모리, 도구 호출, 계획, 테스트, 검증, 멀티 에이전트 오케스트레이션이 포함됩니다. 이는 에이전트가 작업을 안정적으로 완료할 수 있는지를 결정합니다.
넓은 의미의 하네스는 에이전트가 실제 비즈니스 환경 내에서 검증, 피드백, 교정을 받을 수 있게 하는 폐쇄 루프 시스템입니다. 이는 에이전트를 조직의 시스템과 프로세스에 연결하여 시간이 지나도 올바른 일을 계속 수행하도록 돕습니다.
하네스 문제의 전반부는 에이전트가 작업을 어떻게 완료하는가에 관한 것입니다. 이 영역의 기능들은 실제로 수렴하고 있습니다.
그러나 비슷한 기능 목록이 동일한 결과를 만들어 내지는 않습니다. 속도, 정확성, 안정성, 비용, 장애 복구의 차이는 종종 표면 아래에 숨어 있습니다.
후반부는 에이전트가 실제 엔지니어링 및 비즈니스 시스템에 진입하고, 피드백을 받으며, 목표를 향해 계속 작업하는 방식에 관한 것입니다.
차별화가 점점 더 나올 곳이 바로 여기입니다. 시나리오별 검증, 피드백 귀인, 폐쇄 루프 실행입니다.
개발 플랫폼, 프로덕션 로그, 트레이싱 시스템, 내부 자동화 플랫폼, 독점 지식, 조직 규칙은 모두 연결되어야 합니다. 에이전트는 실제 피드백을 보고, 결과가 올바른지 판단하고, 실패의 원인을 찾아내고, 계속 교정해 나가야 합니다.
이 계층은 특정 환경에 크게 의존합니다. 범용 코딩 에이전트는 이를 직접 해결할 수 없습니다.
같은 코딩 에이전트가 한 팀에서는 거의 마법처럼 느껴지고 다른 팀에서는 완전히 쓸모없을 수 있습니다. 그 차이는 종종 팀이 그 주위에 구축한 하네스에 있습니다.
이것이 많은 프로젝트가 플러그인을 패키징하는 이유입니다. 핵심적으로 이러한 플러그인은 이전에 흩어져 있던 스킬, MCP 통합, 문서, 커넥터를 설치 가능하고, 조합 가능하며, 배포 가능한 단위로 가져옵니다.
이 관점에서 보면 DeepSeek Harness의 방향이 훨씬 더 명확해집니다.
DeepSeek Harness를 다시 살펴보기
DeepSeek Harness의 핵심 메시지는 “모든 것은 플러그인이다”입니다.
더 중요한 것은 코딩 에이전트 자체를 플러그 가능하게 만든다는 점입니다. 모델, 도구, 스킬, 세션, 샌드박스, 스토리지, 루프, 스케줄링, UI는 모두 교체하고 재조합할 수 있는 플러그인으로 조립됩니다.
이는 기업이 커뮤니티 플러그인을 사용하거나, 자체 시나리오별 플러그인을 개발하거나, DeepSeek Harness에 포함된 기본 하네스 구성 요소를 교체할 수 있음을 의미합니다.
원칙적으로 이는 2차 개발의 유연성을 높이는 동시에 전체 프로젝트를 포크할 필요성을 줄여, 업스트림 개발을 계속 따라가기 쉽게 만듭니다.
이 설계는 제가 몇 년 전 Egg로 했던 일을 떠올리게 합니다.
Egg는 런타임 커널, 플러그인 시스템, 그리고 상위 수준 프레임워크를 구축하기 위한 확장 메커니즘을 제공했습니다.
같은 모델을 사용하여 DeepSeek Harness를 이해할 수 있습니다:
- 커널은 런타임과 확장 메커니즘을 제공합니다.
- 플러그인은 교체 가능하고 조합 가능한 원자적 기능을 제공합니다.
- 기업은 커널과 커뮤니티 또는 내부 개발 플러그인을 결합하여 자체 하네스를 구축합니다.
아이디어는 안정적인 커널을 유지하고 생태계가 나머지를 탐구하도록 하는 것입니다.
이 방향이 성공한다면, 우리는 하나 이상의 oh-my-dsh을 갖게 될지도 모릅니다. 서로 다른 시나리오를 위해 구축된 수많은 변형을 보게 될 수도 있습니다.
기존 코딩 에이전트에 어떤 영향을 미칠 수 있는가
커뮤니티의 일부 사람들은 MiniMax, Kimi, ZCode 같은 팀들이 분명히 웃고 있을 것이라고 농담했습니다.
저는 그렇게 확신하지 않습니다.
DeepSeek Harness는 기존 코딩 에이전트에 즉각적인 제품 압력을 만들지 않을 수 있습니다. 그러나 생태계 수준의 영향은 훨씬 더 커질 수 있습니다.
량원펑의 AGI 비전과 DeepSeek의 오픈소스 모델은 이미 두 개의 강력한 결집점을 제공합니다. 이제 DeepSeek Harness가 흥미로운 아키텍처적 제안을 더합니다.
이 아키텍처가 실제 세계의 검증을 견뎌낸다면, 전 세계의 오픈소스 개발자들을 끌어들일 수 있습니다. 그렇게 된다면 기존 코딩 에이전트 팀들이 반드시 마지막에 웃는 것은 아닐 수 있습니다.
역사적으로 OpenClaw 아래에서 중요한 역할을 했던 Pi는 여전히 널리 논의되고 있습니다. OpenCode도 충성도 높은 개발자 커뮤니티를 계속 끌어들이고 있습니다. 그러나 이 프로젝트들은 자체 파운데이션 모델이 없는 하네스를 가지고 있습니다.
DeepSeek는 LLM과 하네스를 모두 갖추고 있습니다. 그 조합은 상당한 생태계 잠재력을 만들어 냅니다.
커뮤니티는 최근 같은 모델이 서로 다른 하네스 아래에서 어떻게 매우 다르게 수행될 수 있는지 논의해 왔습니다.
만약 DeepSeek Harness가 결국 모델을 비교하기 위한 공유 인프라의 일부가 된다면 어떨까요?
만약 그것이 오픈소스 커뮤니티에서 선호되는 하네스 기반이 되고, 개발자들이 점차 그 주위에 풍부한 플러그인 생태계를 구축한다면, DSH는 사실상의 표준으로 발전할 수 있습니다. 그러면 다른 코딩 에이전트들은 그 인터페이스와 관례에 대한 호환성 쪽으로 이동할지도 모릅니다.
이러한 가능성들은 여전히 추측에 불과합니다. 그것들은 입증된 생태계 결과가 아니라 오늘날 보이는 아이디어와 아키텍처에 기반합니다.
개념은 설득력 있고 잠재력은 실재합니다. 다음에 무슨 일이 일어날지는 개발자들이 현미경으로 코드를 검토한 후에도 이 아키텍처가 커뮤니티의 지지를 얻을 수 있는지에 달려 있습니다.