2025년 1월 DeepSeek-R1이 공개됐을 때 시장의 반응은 ‘딥시크 쇼크’라는 말로 요약됐습니다. 앞서 V3가 중국 AI 연구소도 높은 수준의 모델을 효율적으로 구축할 수 있음을 보여줬다면, R1은 고도화된 추론 능력 역시 소수 프론티어 기업만의 영역이 아니라는 점을 확인시켰습니다.
이번에는 경쟁의 무대가 모델 바깥으로 이동하고 있습니다.
딥시크가 공개한 딥시크 하네스(DeepSeek Harness)는 모델을 실제로 일하는 에이전트로 전환하는 데 필요한 실행 계층을 다룹니다. 도구, 메모리, 실행 루프, 샌드박스, 저장소, 스케줄링, 사용자 인터페이스를 하나의 구조 안에서 조합할 수 있게 만든 것입니다. 딥시크가 내건 원칙은 단순합니다: “Everything is a Plugin (모든 것은 플러그인이다)”
딥시크가 완전히 새로운 종류의 에이전트를 발명한 것은 아닙니다. 주목할 부분은 이미 존재하던 에이전트의 구성 요소들을 어떻게 나누고, 어떤 방식으로 다시 결합할 수 있게 만들었는가에 있습니다.
하네스란 무엇인가
하네스 엔지니어링(Harness Engineering)은 에이전트가 일하는 환경 자체를 설계하는 일입니다. Harness의 원래 의미는 말을 제어하는 마구(馬具)입니다. 목적은 말을 느리게 만드는 것이 아니라, 힘과 속도를 유지한 채 원하는 방향으로 움직이게 하는 데 있습니다. AI에서도 마찬가지로, 모델의 능력을 최대한 활용하되 잘못된 행동이나 예측하기 어려운 실행이 발생하지 않도록 주변 환경과 규칙을 설계하는 것을 뜻합니다. 하시코프 공동창업자 미첼 하시모토가 이 표현으로 강조한 것도 같은 접근입니다. 에이전트가 실수하면 프롬프트로 다시 지시하는 데 그치지 않고, 실수가 재발하기 어렵도록 규칙과 검증 도구, 실행 환경 자체를 수정합니다.
다만 DeepSeek Harness는 이보다 구체적입니다. 하시모토의 하네스가 엔지니어링 관행에 가깝다면, DeepSeek Harness는 모델을 감싸 실제 업무를 수행하게 만드는 실행 계층(Runtime Layer) 자체입니다.
왜 이런 계층이 필요할까요. LLM의 API는 텍스트를 입력받아 텍스트를 출력할 뿐입니다. 모델이 “config 파일을 확인하겠습니다”라고 답해도 스스로 파일을 여는 것은 아닙니다. 그 판단을 해석해 도구를 실행하고, 결과를 다시 모델의 컨텍스트에 넣어 다음 행동을 판단하게 하는 루프가 필요합니다. 이 루프를 담당하는 것이 하네스입니다.
원리는 단순하지만 실제 서비스 수준으로 만들려면 훨씬 많은 요소가 필요합니다. 길어진 컨텍스트를 정리하고, 위험한 명령을 차단하고, 코드는 격리된 샌드박스에서 실행해야 합니다. 작업 실패 시 재시도할지 다른 방법을 택할지, 무엇보다 언제 작업을 종료할지 판단해야 합니다. 에이전트가 작업이 끝났다고 잘못 판단해 멈출 수도, 종료 조건을 인식하지 못한 채 같은 행동을 반복할 수도 있기 때문입니다.
그래서 에이전트를 이해하는 가장 단순한 공식은 이렇습니다:
“모델 + 하네스 = 에이전트”
Claude Code, OpenAI Codex, Cursor 역시 각자의 모델과 함께 이를 둘러싼 실행 환경을 갖고 있습니다. 어떤 코딩 에이전트가 “일을 잘한다”고 평가받을 때, 그 차이의 상당 부분은 모델 성능이 아니라 하네스에서 발생합니다.
딥시크 하네스는 무엇이 다른가
차이는 실행 루프를 구성하는 요소들을 얼마나 세분화하고 개방했는가에 있습니다.
Claude Code 같은 통합형 제품에서는 실행 정책, 도구 사용 방식, 작업 종료 로직 상당 부분이 제공자가 설계한 구조 안에 고정돼 있습니다. 사용자가 조정할 수 있는 것은 주로 프롬프트나 일부 외부 도구입니다. DeepSeek Harness는 모델 어댑터부터 도구, 메모리, 샌드박스, 저장소, 스케줄러, 사용자 인터페이스, 나아가 실행 루프 자체까지 교체 가능한 부품으로 취급합니다. 완성된 하나의 애플리케이션이라기보다, 필요한 부품을 조립해 자신의 에이전트 환경을 구축하는 플랫폼에 가깝습니다.
모델도 고정돼 있지 않습니다. 딥시크 모델이 기본이지만 모델 제공자가 어댑터로 구현돼 OpenAI, Anthropic, Google, Kimi는 물론 로컬 모델도 연결할 수 있습니다. 자체 모델을 개발하는 기업이 만든 플랫폼인데 모델 계층의 종속성은 오히려 줄인 셈입니다. 더 흥미로운 점은 Claude Code나 Codex 같은 외부 코딩 에이전트조차 서브에이전트로 호출할 수 있게 설계했다는 것입니다.
즉 딥시크는 다른 에이전트 제품과 같은 층에서 경쟁하기보다, 여러 모델과 에이전트를 하나의 구성 요소로 다루는 상위 실행 계층을 지향합니다.
딥시크 하네스가 겨냥하는 것
딥시크는 하네스를 무상 배포한 날, 모델 API 가격을 올렸습니다. 하네스가 단순한 제품 출시가 아니라 하나의 ‘전략 선언’으로 읽히는 이유입니다.
딥시크 하네스는 ‘생성형 AI로 소프트웨어를 만드는 비용이 빠르게 낮아진다면 에이전트는 어떤 구조를 가져야 하는가’라는 질문에서 출발합니다. 현재 대부분의 AI 어시스턴트는 사전에 정의된 도구를 사용하는 애플리케이션입니다. 딥시크는 한 단계 더 나아가, 필요한 기능이 없으면 에이전트가 새 플러그인을 만들어 시스템에 연결하고, 필요한 기간 동안 사용한 뒤 제거하는 구조를 지향합니다. 모든 기능을 사전에 개발해 둘 필요가 없어지는 것입니다.
문제는 소프트웨어 생성 비용이 낮아져도 시스템 전체의 비용까지 낮아지지는 않는다는 점입니다. 생성된 도구는 명령어를 등록하고 공유 상태를 변경하며 다른 서비스와 의존관계를 만듭니다. 플러그인이 쌓일수록 시스템은 복잡해지고, 어떤 기능을 제거했을 때 예상하지 못한 다른 기능이 함께 멈출 수 있습니다. 생성 비용은 떨어지지만 생명주기와 의존성을 관리하는 비용은 오히려 늘어날 수 있습니다.
딥시크 하네스가 기반으로 삼은 Cordis 프레임워크는 이 문제에 두 가지 원칙으로 대응합니다. 첫째, 효과는 되돌릴 수 있어야 합니다. 플러그인이 추가한 기능과 변경한 상태는 제거 시 역순으로 복구됩니다. 둘째, 의존성은 동적으로 반응해야 합니다. A에 의존하는 B는 A가 제거되면 스스로 비활성화되고, A가 돌아오면 다시 동작합니다. 함께 공개된 논문은 구성 요소가 여러 차례 추가·제거되더라도 최종 구성이 같다면 시스템이 동일하게 동작해야 한다는 원칙을 형식화한 것입니다.
Cordis가 AI가 아닌 크로스플랫폼 챗봇 프레임워크(Koishi)에서 발전했다는 점도 흥미롭습니다. 기능이 계속 생기고 사라지는 동안에도 전체가 멈추지 않아야 하는 문제를, 챗봇 생태계는 이미 오래 경험해 왔습니다.
기술 구조보다 중요한 질문은 딥시크가 왜 이를 공개했느냐입니다. 하네스는 오픈소스로 열고 모델 API 가격은 올린 비대칭적 선택에는 두 가지 해석이 가능합니다.
첫째는 ‘보완재 무료화(Commoditize Your Complement)’ 전략입니다. 핵심 제품의 시장을 키우기 위해 주변 제품을 범용화하는 전통적 플랫폼 전략으로, 구글이 Android로 모바일 운영체제의 진입장벽을 낮춘 사례가 대표적입니다. 이 관점에서 딥시크의 선택은 명확합니다. 실행 계층에서 경쟁사가 높은 마진을 확보하기 어렵게 만들면서, 그 위에서 자사 모델이 사용될 수 있는 전체 시장을 키우는 것입니다.
둘째는 수직 통합과 수평 플랫폼의 경쟁입니다. OpenAI와 Anthropic은 자사 모델과 긴밀하게 통합된 에이전트 애플리케이션으로 확장하며 성능과 사용자 경험을 최적화합니다. 딥시크는 특정 모델에 종속되지 않는 모듈형 하네스를 열어, 여러 모델과 도구가 공존하는 공통 인프라 계층을 지향합니다. 수직 통합은 최적화에, 수평 플랫폼은 유연성과 생태계 확장성에 강점이 있어 어느 쪽이 우월하다고 단정하기는 어렵습니다. 딥시크의 선택은 후자입니다.
모델 다음의 해자도 평준화될 수 있을까
DeepSeek-R1 이후 AI 산업에는 자연스럽게 다음 질문이 이어졌습니다.
모델 자체가 빠르게 범용화된다면, 다음 경쟁 우위는 어디에서 만들어지는가.
유력한 후보가 하네스였습니다. 이유는 두 가지입니다. 첫째, 같은 모델이라도 어떤 도구와 연결되고, 컨텍스트를 어떻게 관리하며, 오류를 어떻게 복구하고 작업을 언제 종료하는지에 따라 실제 에이전트 성능이 크게 달라집니다. 둘째, 하네스는 사용자의 작업 환경과 설정, 도구 체계가 쌓이는 영역이어서 전환 비용이 발생합니다. 모델 API는 교체할 수 있어도, 수많은 도구와 워크플로우가 얽힌 실행 환경을 다른 시스템으로 옮기기는 어렵습니다. 모델 이후의 해자가 하네스에서 만들어질 것이라는 전망에는 충분한 논리가 있었습니다.
그런데 딥시크가 바로 그 계층을 MIT 라이선스로 공개했습니다. R1이 모델 계층의 진입장벽을 낮췄다면, DeepSeek Harness는 한 단계 위인 에이전트 실행 계층에서 같은 시도를 하고 있는 것입니다. 경쟁사들이 다음 해자로 쌓아 올리려던 계층을, 딥시크는 해자가 형성되기 전에 범용재로 만들어 버리는 쪽을 택했습니다.
여기에 기업 관점에서 눈여겨볼 특징이 하나 더 있습니다. DeepSeek Harness는 시스템 프롬프트부터 추론 과정, 도구 호출과 실행 결과, 서브에이전트 할당, 토큰 사용량까지 실행 과정의 주요 정보를 세션 로그에 기록합니다. 작업을 이전 시점에서 재개하거나 특정 지점에서 분기하고, 과거 실행을 검색·재생할 수 있습니다. 에이전트가 무엇을 보고 어떤 판단을 거쳐 행동했는지 추적하려는 구조입니다. 에이전트가 기업 시스템 안에서 더 많은 권한을 갖게 될수록 이런 실행 기록의 중요성은 커집니다. 성능이 높은 에이전트만으로는 충분하지 않고, 문제가 발생했을 때 실행 과정을 되짚을 수 있어야 하기 때문입니다.
물론 DeepSeek Harness를 완성된 표준으로 보기는 이릅니다. 현재 버전은 초기 단계로 호환성을 깨는 변경 가능성이 명시돼 있고, ‘되돌리기’도 시스템 내부 상태에만 유효할 뿐 이미 발송된 이메일이나 실행된 결제 같은 외부 세계의 행동까지 되돌리지는 못합니다. 기존 선두권 코딩 에이전트보다 실제 업무 성능이 우수하다는 것도 아직 입증되지 않았습니다. 지금 주목할 것은 벤치마크 성능보다 아키텍처와 전략적 방향성입니다.
현재 시장의 관심은 주로 “어떤 코딩 에이전트가 승자가 될 것인가”에 집중돼 있습니다. 하지만 DeepSeek Harness는 다른 질문을 던집니다. 에이전트를 구성하는 요소 가운데 어느 부분까지 하나의 독점 제품 안에 들어 있어야 하는가. 이번 경쟁의 대상은 제품 하나가 아니라, 모델과 도구, 메모리, 실행 환경, 다른 에이전트까지 어떤 방식으로 연결할 것인지에 대한 공통 규격을 누가 먼저 만드는가에 가깝습니다.
만약 특정 하네스 구조가 충분한 개발자와 플러그인 생태계를 확보해 사실상의 표준이 된다면, 경쟁의 중심은 다시 한 단계 위로 이동합니다. 그때 중요한 질문은 어떤 모델을 쓰는가가 아니라, 그 공통 실행 기반 위에서 어떤 업무 시스템을 구축하고, 어떤 데이터를 연결하며, 기업의 실제 프로세스를 어떻게 재설계할 것인가가 될 가능성이 높습니다.
첫 번째 딥시크 쇼크가 모델이라는 경쟁 우위의 지속 가능성에 질문을 던졌다면, 이번에는 시장이 다음 해자로 주목하던 에이전트 실행 계층에 같은 질문이 던져지고 있습니다. DeepSeek Harness가 실제 표준이 될지는 아직 알 수 없습니다. 다만 한 가지는 분명합니다. 에이전트 경쟁은 이미 ‘어떤 모델이 더 똑똑한가’만으로는 설명하기 어려운 단계로 넘어갔습니다.
Writer: Turing Post – Ksenia Se & Ben Eum
Edit: Metanet
