여러분들도 2025년 1월 딥시크가 DeepSeek-R1을 내놓았을 때를 기억하실 겁니다. 추론과 수학, 코딩 벤치마크에서 오픈AI의 o1을 바짝 따라붙은 것도 놀라웠지만, 진짜는 그 다음이었죠. 딥시크는 모델 가중치를 MIT 라이선스로 풀어버렸고, 강화학습 과정을 상당 부분 설명한 논문까지 함께 내놨습니다.

한국도 그때 꽤 시끄러웠던 걸로 기억합니다. 신문 1면에 '스푸트니크 쇼크'라는 표현이 오르내렸고, 앱스토어 1위를 찍은 지 얼마 안 돼 보안 문제로 다운로드가 막히기도 했죠. 여의도에는 딥시크 관련주식 리스트가 돌아다녔고요. 저희 튜링포스트 코리아도 한 번 정리해 드렸었습니다:

다만, 돌이켜 보면 작년 초의 그 소동은 "중국이 그걸 이렇게 싸게 만들었대" 언저리를 맴돌다 끝났던 것 같습니다. 정작 중요한 건 가격이 아니라 문턱이었는데 말이죠 - 지금 생각해 봐도, 이런 대단한 걸 만들 수 있는 쪽이 갑자기 많아졌다는 것, 그게 핵심이었습니다.

중국 연구소도 뛰어난 모델을 효율적으로 뽑아낼 수 있다는 건 이미 V3가 보여준 바 있었습니다. R1은 거기서 한 걸음 더 나아가서, 고도의 추론 능력조차 소수 프론티어 랩의 전유물이 아니라는 걸 증명해 버렸던 것이구요. 물론 프론티어 랩들은 컴퓨팅 파워와 유통망, 인재, 독점 데이터라는 우위를 여전히 갖고 있었지만, 그래도 모델 하나만 놓고 보면, 그때부터 모델의 성능이 장기적으로 기댈 만한 해자(Moat)라는 느낌은 사라지기 시작했어요.

그리고 지금, 딥시크 하네스(DeepSeek Harness)가 그보다 한 층 위에서 똑같은 일을 벌이고 있습니다.

이야기를 진행하기 전에 이 단어부터 한 번 간단히 정리하고 가죠. ‘하네스’라는 단어, AI 판에서 요즘 부쩍 많이 들리는 단어기는 하지만, 막상 뭘 가리키는지는 또 아주 클리어하지는 않을 수도 있잖아요?

우리가 AI를 부려온 방식을 되짚어 보면, 순서가 이랬습니다.

처음엔 프롬프트 엔지니어링, 말을 잘 거는 기술이었죠. 그런데 프로젝트를 통째로 맡기려니 배경을 모르는 상대에게 지시하는 셈이라 금새 한계가 왔습니다.

그래서 컨텍스트 엔지니어링, 무엇을 보여줄지를 설계하기 시작했고요.

그 다음이 MCP와 스킬이었습니다. 쓸 수 있는 도구를 붙여주고, 할 수 있는 일의 범위를 정해준 거죠. 여기서 또 문제가 생겼습니다. 도구가 늘어날수록 AI가 어느 상황에 무슨 도구를 집어들어야 할지 헷갈려 하기 시작한 겁니다.

결국 남은 질문은 이거였어요. 무엇을 보여줄까가 아니라, 무엇을 막고 무엇을 재고 무엇을 고칠까. 그게 하네스 엔지니어링, 에이전트가 일하는 환경 자체를 설계하는 일이라고 할 수 있을 것 같습니다.

(주의해야 할 건, 위에서 순서대로 말씀드린 개념들은 뒤의 것이 앞의 것을 대체하는 아니라 포함하는 관계에 있다고 보는게 맞다는 겁니다. 컨텍스트 엔지니어링이 하네스에 밀려난 게 아니라, 하네스 안에 들어가 있는 것이라는 의미죠)

harness의 원래 뜻은 말에 씌우는 마구(馬具)입니다. 비유가 꽤 정확한데, 마구의 목적은 말을 느리게 만드는 게 아니라 속도는 살리면서 방향을 잡는 데 있죠. LLM도 마찬가지로, 여기서의 harness도 LLM의 능력은 최대로 뽑아 쓰되 엉뚱한 쪽으로 뛰어들지 않게 하는 거예요. 게다가 달리는 말 열 마리를 한꺼번에 몰기 시작하면 이야기가 훨씬 심각해질 거라는 건 말할 필요도 없을 겁니다.

하시모토가 강조하려고 한 건 이런 실질적인 프랙티스였습니다 - 에이전트가 실수를 하면, 그 실수가 구조적으로 다시는 불가능해지도록 환경을 고친다는 거요. 프롬프트로 야단치는 게 아니라 규칙 파일에 한 줄을 남기고, 검증 도구를 하나 만들어 붙이는 방식이죠. 그렇게 쌓인 것이 ‘하네스’입니다.

자, 그런데 이 글에서 말하는 하네스 - 딥시크의 하네스 - 는 그보다 조금 좁은 영역의 의미예요. 하시모토가 말한 ‘하네스’가 엔지니어링으로서의 프랙티스를 말했다면, 딥시크 하네스는 ‘물건’이예요 - 모델을 감싸서 일하게 만드는 ‘실행 층’ 그 자체요.

왜 그런 층이 필요할까 생각해 보면, 결국은 ‘모델 API가 생각보다 훨씬 단순한 물건’이기 때문입니다. 모델에 텍스트를 넣으면 텍스트가 나오죠? 사실 그게 전부예요. 그래서 모델이 "config 파일을 읽어보겠습니다"라고 답한다고 해도 그건 그냥 글자입니다 - 파일은 안 열려요. 누군가 그 글자를 읽고 "아, 파일을 열라는 거구나" 하고 해석해서 실제로 파일을 열고, 내용을 다시 모델에 넣어주고, 또 물어보는 작업을 해야 합니다.

그리고 바로 그 '누군가'가 하네스입니다. 모델에게 묻고, 시키는 걸 실행하고, 결과를 모델의 입에 물려주고, 다시 질문을 하는 ‘Loop(루프; 순환 구조)’를 돌리는 레이어죠.

이 단순한 루프를 실전에서 쓸 만하게 만들려면 사실 붙여야 할 게 산더미입니다. 컨텍스트가 차면 접어야 하고, 위험한 명령은 걸러야 하고, 코드는 격리된 곳에서 돌려야 하고, 틀렸을 때 다시 시도할지 판단해야 하죠. 무엇보다 언제 멈출지를 알아야 하는데, 이게 의외로 아주 어렵습니다. 다 됐다고 착각하고 끝내거나, 끝난 줄 모르고 무한 루프를 돌 수도 있으니까요.

그래서, 업계의 실질적인 공식은 이렇습니다: 모델 + 하네스 = 에이전트. 클로드 코드도 코덱스도 커서도 각자의 하네스를 갖고 있습니다. 우리가 "클로드 코드가 일 잘한다"고 말할 때, 그 절반은 사실 모델이 아니라 하네스 이야기였던 겁니다.

어느 투자은행에서 실시한 ‘워크플로우 벤치마크’를 보면 이걸 잘 알 수 있는데, 같은 모델을 하네스 셋에 각각 얹었더니, 결과물의 품질 차이는 미미했지만 그 과정에서 쓴 비용은 두 배 넘게 벌어졌어요. 한쪽은 거대한 스크립트를 뽑아놓고 디버깅 루프에 갇혔고, 다른 쪽은 이미 상장폐지된 종목을 계속 조회하면서 50분 동안 도구를 130번 넘게 호출했다고 합니다. 모델은 똑같았고, 이런 차이를 만들어낸 건 루프였습니다.

딥시크 하네스에 대한 깃허브 반응은 대단합니다.

출시 당일 2만 7,500개였던 스타가 이틀 만에 9만 5,000개를 넘겼고, 지금은 13만 개를 넘어섭니다. (다만 매체마다 집계 시점이 달라서 숫자가 제각각이고, '깃허브 역사상 최고 속도'라는 표현에 검증된 근거는 없다는 지적도 나오기는 합니다)

그런데, 더 눈여겨볼 숫자는 따로 있습니다. 깃허브에 dsh-plugin 토픽으로 모인 리포지토리가 벌써 300개를 넘었어요. 스타는 북마크지만 플러그인은 누군가 실제로 손을 움직인 결과라서, 더 큰 의미가 있다고 봅니다.

딥시크가 새로운 종류의 물건을 발명한 건 아니예요 - 앞서서 이야기한 그 루프, 똑같은 거예요. 다만, 딥시크가 한 일은 그 루프를 부품 단위로 쪼개고, 부품마다 밖에서 갈아 끼울 수 있게 표준의 계약을 열어둔 것이라고 할 수 있습니다.

클로드 코드에서라면, 모델도, 실행 정책도, 종료 판단도 앤트로픽이 정한 대로 못 박혀 있습니다. 그래서 우리 사용자가 손댈 수 있는 건 프롬프트와 도구 몇 개 정도인 거죠.

반면, 딥시크 하네스에서는 그 모든 게 전부 ‘플러그인 슬롯’입니다. 모델 어댑터, 도구, 메모리, 샌드박스, 저장소, 스케줄러, UI는 물론이고 에이전트 루프 자체까지 통째로 교체할 수 있어요. 딥시크 하네스 리포지토리를 열어보면 워크스페이스 멤버가 230개를 넘습니다. 파일시스템부터 PTY, language server, 자격증명, 텔레메트리까지 죄다 개별 패키지로 쪼개져 있죠. 다시 말해서, 완성된 컴퓨터라기보다 거대한 브레드보드에 가깝습니다.

모델의 자리도 비어 있습니다. 딥시크가 기본값이긴 하지만 모델 제공자(Model Provider) 자체가 어댑터 플러그인이라서, 오픈AI와 앤트로픽, 구글, Kimi 등 수십 종의 다른 모델을 꽂을 수 있고 OpenAI 호환 엔드포인트면 로컬 모델도 됩니다. 자기 모델을 만들어서 파는 회사가 만든 물건치고는 묘하게 담백하죠.

개인적으로 가장 인상적이었던 대목은 따로 있습니다. 클로드 코드와 코덱스를 서브에이전트로 불러 씁니다. 경쟁 제품이 아니라, 그것들을 부품으로 취급하는 위층에 자기 자리를 잡은 겁니다.

국내 반응은 어땠을까 확인해 보니, R1 때만큼 대중적으로 번지지는 않았습니다. AI타임스와 ZDNet 코리아, 디지털투데이 같은 전문 매체들이 발 빠르게 다뤘고, 대체로 "클로드 코드와 코덱스가 장악한 에이전트 실행 환경에 대한 오픈소스 진영의 대안"이라는 틀로 정리가 된 느낌입니다.

다만 개발자 프리뷰 단계인 데다가 완성형 제품의 대체재라기보다 직접 조립하려는 개발자를 위한 기반에 가깝다는 유보적 태도였다고 느꼈고, 오히려 같은 날 나온 V4-Pro가 '기대 이하'라는 평가로 헤드라인을 가져가기도 했습니다. 눈에 띄었던 건, 같은 날 모델 API 값은 올리면서 하네스는 무상 배포한 비대칭을 짚은 분석이었습니다. 제품 출시가 아니라 전략의 선언이라는 거였는데, 저도 그 지점이 핵심이라고 봅니다.

딥시크가 딥시크 하네스를 통해서 내건 슬로건은, "모든 것은 플러그인이다(Everything is a Plugin)"이라는 겁니다. 언뜻 들으면 소프트웨어 판에서 흔한 이야기 같지만, 단순한 추상화라 할지라도 스택의 적절한 층에 가서 붙는 순간 판이 달라지는 경우가 있습니다.

유닉스는 "모든 것은 파일이다"라는 원칙 하나로 프린터든 네트워크 연결이든 전부 파일 다루듯 만들어진 운영체제죠. 스몰토크는 "모든 것은 객체다"를 내세워 메시지를 주고받는 객체 중심으로 환경 전체를 짰고요. 웹은 흔히 모래시계 모델이라 부르는 구조를 통해서 문서와 그걸 서비스하는 기계를 깔끔하게 떼어놨습니다. 위로는 온갖 애플리케이션이, 아래로는 온갖 네트워크가 붙지만 가운데 허리는 IP 하나로 잘록하게 모이는 구조예요.

재미있는 건 세 가지 경우 모두 부품 자체는 이미 다 있었다는 점입니다. 진짜 혁신은 그 부품들에 공통 인터페이스 하나를 씌워서, 그전까지 따로 놀던 조각들을 맞물려 돌아가게 만든 데서 나왔어요.

제록스 PARC에서 개인용 컴퓨터의 개념을 만든 앨런 케이는, 스몰토크를 두고 ‘컴퓨팅 비용이 급격히 떨어지던 흐름에 대한 응답이었다’라고 설명한 적이 있습니다. PARC에서 개인용 컴퓨터가 싸지면서 ‘과연 소프트웨어가 어떤 모습일 수 있는가’라는 전제 자체가 바뀌었고, 아키텍처는 그 뒤를 따라갔다는 이야기입니다.

하네스도 비슷한 자리에서 출발합니다. 이번에 값이 떨어진 건 소프트웨어를 만들어내는 비용이고요. 질문은 이런 것이겠죠:

지금 대부분의 AI 어시스턴트는, 여전히 정해진 도구 묶음에 연결된 고정된 애플리케이션입니다. 그런데 하네스는 크리에이터 모드에서 한 발 더 나갑니다. 필요한 기능이 없으면 에이전트가 임시 플러그인을 직접 짜고, 올려도 되겠냐고 허락을 구한 다음, 쓸 만큼 쓰고 다시 떼어냅니다.

어떤 기능은 미리 만들어둘 필요가 없어지는 겁니다. 필요해지는 순간에 만들면 되니까요.

생성형 AI 기반의 코드 생성 기술 때문에 소프트웨어를 추가하는 비용은 낮아졌지만, 이미 추가된 걸 관리하는 비용은 계속 불어납니다.

생성된 도구는 명령어를 등록하고, 공유 상태를 건드리고, 다른 서비스와 의존성을 만들어냅니다. 이미 사라진 리소스를 여전히 기다리는 구성 요소를 남겨두기도 하고요. 그러니까 확장 기능을 끝없이 써대면서 정작 뒷정리를 안 하는 에이전트는, 똑똑해질수록 오히려 못 믿을 물건이 되어 갑니다. 좀 얄궂죠?

딥시크 하네스는 코르디스(Cordis)라는 프레임워크 위에 얹혀 있습니다. 모든 플러그인이 컨텍스트 객체 하나를 반드시 거쳐서 등록하게 만든 구조라, 어느 플러그인이 무엇을 등록했는지 완전한 장부가 남습니다. 여기서 두 가지 원칙이 나오는데요:

함께 나온 논문 「시공간 조합 가능성을 위한 프로그래밍 패러다임」은 이걸 형식화해 보려는 시도입니다. 몇 가지 가정 아래에서, 계속 붙였다 뗐다 하며 굴러온 시스템이 처음부터 그 구성으로 새로 만든 시스템과 관측 상 똑같은 상태에 도달할 수 있다는 걸 보여주죠. 공간(무엇이 붙어 있나)과 시간(언제 붙었다 떨어졌나)에 상관없이 같은 결과가 나온다는 뜻입니다.

IBM 연구소에서 일했던 관계형 데이터베이스의 창시자, 에드거 코드가 생각나네요. 에드거 코드가 이야기한 관계형 모델 역시 ‘데이터를 저장 방식에서 떼어내자’는, 그때까진 엔지니어들의 취향 정도였던 이야기를 형식적 추상화로 끌어올렸습니다. 나중에 SQL이 원래 구상을 좀 희석하긴 했지만, 추상화 자체는 살아남아서 산업 전체의 판을 다시 짜놨죠.

코르디스가 에이전트 런타임에서 그런 역할을 할지는 판단하기 이릅니다만, 질문만큼은 제대로 던지고 있다고 봅니다. 에이전트가 자기 기능을 스스로 만들어낼 참이라면, 그걸 붙이고, 돌아가는 것들과 맞물리게 하고, 망가뜨리지 않으면서 다시 걷어낼 방법이 필요하니까요.

흥미로운 건 코르디스가 애초에 에이전트에서 나온 물건이 아니라는 점입니다. 코이시(Koishi)라는 크로스 플랫폼 챗봇 프레임워크에서 자라났고, 만든 사람인 시그마(Shigma)는 지금 딥시크에 있어요. 4년간 커뮤니티 플러그인이 수천 개씩 쌓이는 동안 코이시는 다이나믹 소프트웨어의 실무적 문제와 정면으로 부딪혔습니다. 기능이 나타났다 사라지고, 플러그인끼리 서로 의존하고, 그 와중에도 시스템은 멈추면 안 됐으니까요.

이 아키텍처가 하필 채팅에서 나왔다는 것도 생각해 보면 납득이 갑니다. 중국에서 메신저는 오래전부터 커뮤니케이션 위에 결제와 커머스, 공공 서비스, 엔터테인먼트, 업무까지 다 얹어져 온 물건이에요. 위챗 하나만 해도 이용자가 14억 명 수준이고, 코이시는 QQ와 텔레그램, 디스코드를 지원합니다. 끊이지 않는 이벤트, 계속 유지되는 상태, 외부 서비스, 제각기 개발된 도구들. 챗봇은 오늘날 에이전트가 겪는 문제를 진작에 겪고 있었던 거였죠.

자, 여기서부터가 제가 진짜 하고 싶은 이야기입니다.

첫 번째 딥시크 모먼트 이후, ‘뭐가 진짜 해자냐’라는 논의는 AI 스택의 위쪽으로 슬금슬금 올라갔습니다. 모델이 점점 싸지고 격차도 좁혀진다면, 값어치 있는 건 모델을 둘러싼 하네스 아니겠느냐는 거였죠.

이 짐작에는 물론 근거가 있었습니다. 앞서 본 것처럼 같은 모델이라도 어떤 하네스에 얹느냐에 따라 성능도 비용도 갈립니다. 게다가 하네스는 사용자를 묶어두는 층이기도 하죠. 도구 설정을 다 맞춰놓고 손에 익어버리면, 그게 커맨드라인 한 줄짜리 인터페이스라고 해도 갈아타기가 성가셔지니까요. 모델은 갈아탈 수 있어도 하네스는 잘 못 갈아탑니다. 그래서 다들 여기가 다음 해자라고 봤던 겁니다.

그런데 딥시크가 바로 그 층을 MIT 라이선스로 풀어버렸습니다.

어떻게 이해해야 할까요? 해외 분석가들의 시각이 갈리는데, 큰 줄기는 둘입니다.

첫째, 보완재 무료화(commoditizing your complement) 전략. 소프트웨어 업계의 오래된 수법이죠. 내 제품이 팔리려면 옆에 있어야 하는 물건을 공짜로 뿌려서, 그쪽에서 아무도 돈을 못 벌게 만드는 겁니다. 구글이 안드로이드로 했던 일이 딱 그거고요. 실제로 딥시크는 하네스를 무상 공개한 바로 그날 V4 API 가격을 올렸습니다. 모델은 비싸게 팔고 모델을 감싸는 규격은 공짜로 뿌리는 이 비대칭이, 우연일 리는 없어 보입니다.

둘째, 수평 확장 대 수직 통합의 구도. 오픈AI와 앤트로픽은 자사 모델에 깊이 묶인 하네스를 만들어 애플리케이션 층에서 우위를 굳히는 아래로의 통합을 씁니다. 반면 딥시크는 모델 중립적이고 극단적으로 모듈화된 기반을 오픈소스로 풀어서, 차세대 AI 애플리케이션의 인프라 자체가 되겠다는 쪽이죠. 하네스 비공개 베타에 뽑힌 프로젝트들이 MCP 플러그인과 런타임, 오케스트레이션, 멀티에이전트 스케줄링에 몰려 있었다는 관찰도 있습니다. 응용 제품이 아니라 인프라를 노린 선정이었던 겁니다.

여기에 눈여겨본 대목이 하나 더 있습니다. 어떤 개발자는 이걸 두고 R1 때와 똑같은 일이 한 층 위에서 벌어진 거라고 표현하더군요. R1이 모델의 사고 과정을 공개된 산물로 만들었다면, 하네스는 에이전트의 실행 과정을 그렇게 만든다는 겁니다. 실제로 하네스는 모델이 본 모든 것을 추가 전용(append-only) 세션 로그에 기록합니다. 시스템 프롬프트, 추론 과정, 도구 호출과 결과, 서브에이전트 배정, 컨텍스트 주입, 토큰 비용까지 전부요. 그래서 실행을 다시 돌리지 않고도 재개하고, 분기하고, 검색하고, 그대로 재생할 수 있습니다. 숨을 곳이 없는 셈입니다.

이게 우연이 아닌 이유가 있습니다. 딥시크가 하네스 팀을 이끌 사람으로 영입한 게 제인 스트리트 출신 엔지니어예요. 퀀트 트레이딩은 무슨 일이 왜 일어났는지 나중에 전부 되짚을 수 있어야 하는 걸 세상에서 가장 까다롭게 요구하는 동네입니다. 급하게 붙인 곁가지가 아니라 몇 달 전부터 준비한 베팅이라는 이야기죠.

Pi 에이전트를 만드는 Earendil의 공동창업자 아르민 로나허(Armin Ronacher)의 반응도 인상적이었습니다. 하네스가 완벽하다고 보지는 않지만, 오랜만에 자기들의 선택을 다시 들여다보고 싶어질 만큼 자극받은 물건이었다고 하더군요. 오픈소스의 그런 점이 좋다는 말과 함께요.

정리하면 이렇습니다. 하네스가 열리면 에이전트 층 자체가 평준화됩니다. 모델 성능이 평준화됐을 때 벌어진 일을, 이번엔 한 층 위에서 다시 보게 될 수도 있다는 거죠. 딥시크는 모델 경쟁에서 내려온 게 아니라, 에이전트 시대의 표준 자리를 먼저 차지하러 간 것에 가깝습니다.

그렇지만, 하네스는 아직 v0.1이고, 리포지토리에도 호환성을 깨는 변경이 있을 거라고 대문짝만하게 적혀 있어요. 에이전트 프레임워크에서 이건 아주 무거운 경고입니다. 호환성이 깨진다는 건 그 위에 올려둔 모든 사람의 에이전트가 같이 깨진다는 뜻이고, 그에 따르는 비용은 고스란히 초기 사용자에게 전가됩니다. 취미로 하는 사람이라면 감당할 만하고 공개적으로 반복 개선할 여력이 있는 연구소라면 더욱 그렇겠지만, 프로덕션에 바로 꽂을 물건은 아닙니다.

내세우는 보장 내용에도 한계가 분명합니다. 코르디스가 되돌리는 건 프로세스 안의 상태뿐이에요. 플러그인을 떼어낸다고 이미 나가버린 이메일이 돌아오지는 않습니다. 되돌리기가 작동하려면 플러그인 작성자가 자기 효과를 성실하게 적어뒀어야 하고요. 그리고 딥시크에서 하네스가 선두권 코딩 에이전트보다 낫다는 걸 보여준 적도 아직 없습니다.

그럼에도 불구하고, 제가 성능 결과보다도 더 흥미를 느끼는 딥시크의 첫 대형 발표가 모델이라는 해자를 흔들었다면, 이번에는 모두가 다음 해자로 눈독 들이기 시작한 그 층을 열어젖혔다는 것이죠.

써 보시고 싶은 분들은, 아주 쉽게 해 보실 수 있습니다. Node.js만 있으면 명령어 한 줄로 로컬에 웹 화면이 뜹니다.

많은 분들이 ‘어떤 코딩 에이전트가 이길지’ 지켜보고 있죠. 그런데 딥시크는 저에게 조금 다른 질문을 던지게 만들고 있습니다. 애초에 코딩 에이전트 중에 꼭 독점 제품이어야만 하는 부분이 얼마나 될까요?

한 가지만 말씀드리고 싶어요: R1 발표 이후에 우리 모두 그 모델을 값싸게 만들었다는 데 놀랐지만,. 진짜 핵심은 ‘만들 수 있는 곳들이 많아졌다, 즉 그 문턱이 낮아졌다’는 것이었어요. 이번에도 같은 실수를 할 수 있습니다 - 하네스를 '공짜 클로드 코드'로만 읽으면 딱 그 모습일 겁니다.

지금 벌어지고 있는 건 ‘제품 경쟁’이 아닙니다. 에이전트를 제작하는 규격을 누가 먼저 정하느냐의 싸움이에요. 그리고 그 규격이 정해지고 나면, 그 위에서 무엇을 만들지가 다음 큰 판이 될 겁니다.