AI의 발전을 이야기할 때, 우리는 보통 '모델이 무엇을 할 수 있느냐'에서 시작하게 됩니다. 그런데, 성능 좋은 모델을 에이전트로 쓰려고 하면 또 다른 질문들이 생기기 마련입니다 - 이 모델을 누가 운영할 수 있는지, 비용은 얼마나 드는지, 그리고 여러 도구와는 어떻게 연결하는지 같은 질문들이죠.

딥시크는 그동안 최상위권 추론 모델로 주목받아 왔는데요, 최근에는 모델만이 아니라 그 모델을 운영하는 데 필요한 것들까지 공개하고 있습니다. 딥시크는, 올해 8월에 에이전트 하네스를 공개했고, 9월과 10월에는 DeepSeek-V4.1-Flash와 그 가중치, 그리고 추론 엔진을 차례로 내놓았는데, 여기에 칩과 칩 사이에서 데이터가 어떻게 오가는지까지 다루는 라이브러리를 더해 한데 모아 놓고 보면 모델을 둘러싼 시스템이 어떻게 짜여 있는지를 상당 부분 직접 들여다볼 수 있습니다.

하지만, 시스템이 어떻게 짜여 있는지 들여다보는 일과 그 시스템을 실제로 운영하는 일은 전혀 다른 문제입니다. 딥시크가 공개한 것들만 가지고 에이전트를 만든다면, 그 중 어느 부분까지를 바로 가져다 쓸 수 있을까요? 그리고 어떤 부분이 여전히 딥시크가 직접 운영하는 서비스나 외부에 공개하지 않은 인프라에 기대고 있을까요?

이번 글에서는, 모델에서 출발해서 에이전트, 그리고 그 주변의 인프라까지, 딥시크가 공개한 요소들을 하나씩 따라가 보려고 합니다. 딥시크가 우리 손에 쥐여 준 것이 과연 어떤 것인지, 그리고 그 요소들로 어떤 일을 해 볼 수 있게 됐는지를 함께 살펴보죠.

그리고, 딥시크 생태계 전체를 한 장으로 정리한 인포그래픽을 한국어판 PDF로 준비했습니다. 글을 읽기 전에 전체 그림을 먼저 잡아 두시거나, 이후에 참고하면서 활용하시는 데 도움이 될 거라고 생각합니다. 아래 버튼을 눌러 내려받아 보세요.

(PDF가 보이지 않으면 여기를 눌러 받아 보세요)

오늘 에피소드에서는 아래와 같은 내용을 다룹니다:

딥시크가 오픈소스로 공개한 것들만 가지고 코딩 에이전트를 처음부터 끝까지 만들어 본다고 생각해 보면, 그 출발점은 당연히 ‘모델’입니다.

그리고, 딥시크의 모델 그 자체는 정말 대단합니다. 딥시크는 2026년 9월 10일에 멀티모달 추론과 코딩, 에이전트 워크플로우까지 지원하는 최신 모델 DeepSeek-V4.1-Flash를 내놓았죠. 딥시크에 따르면, 포스트트레이닝을 거치기 전 단계의 베이스 모델은 여러 종류의 벤치마크에서 V4-Pro-Base와 비슷한 성능을 보였습니다. 10월 17일에는 V4.1-Flash-1017 업데이트가 나왔고, 지금은 업데이트된 가중치를 MIT 라이선스로 누구나 받아 쓸 수 있습니다.

에이전트에게 이 ‘모델’이라는게 왜 중요한가 하는 건, 숫자 하나를 보면 알 수 있습니다. 이 모델의 글로벌 KV 캐시(KV Cache) - 앞서 처리한 컨텍스트를 다시 쓸 수 있게 저장해 두는 정보 - 는 토큰당 890바이트로, V4 Flash의 4분의 1 수준입니다. 캐시가 작으면, 한 세션 안에서 긴 컨텍스트를 계속 유지하기가 그만큼 수월해질 수 있습니다. 단, 이 숫자는 글로벌 KV 상태만 잰 수치이지, 실행 중인 모델 전체가 쓰는 메모리를 잰 게 아니라는 점은 말씀드려 둡니다.

구조를 보면, V4.1 Flash는 멀티모달 MoE 모델입니다. MoE(Mixture-of-Experts)는 여러 '전문가' 하위 네트워크 가운데 토큰마다 일부만 골라 쓰는 구조를 말하죠. 딥시크는, 5,520억 개의 백본 파라미터에 Engram 파라미터 1,960억 개를 페어링했는데, Engram은 학습하는 동안 익힌 지식을 필요할 때마다 찾아 쓰는 ‘희소 메모리 뱅크’입니다. 모델은 Engram 덕분에 활성 KV 캐시를 부풀리지 않고도 바깥에 따로 둔 지식 가중치를 필요할 때만 꺼내 쓸 수 있죠. 이 Engram은 사용자의 프롬프트나 대화 기록과는 별개입니다.

흥미롭게도, 이 모델은 입력을 다루는 방식이 독특합니다. 딥시크는, 40개 레이어를 20개 레이어의 인과적 인코더와 20개 레이어의 디코더로 나누고, 디코더의 글로벌 KV 상태는 인코더의 마지막 상태에서 투영해서 가져오도록 했습니다. 그래서, 프롬프트 토큰 대부분은 디코더의 연산을 전부 거치지 않고 지나갈 수 있습니다. 모델은, 입력 전체를 한꺼번에 처리하는 프리필(Prefill) 단계에서는 토큰당 80억 개, 답을 한 토큰씩 만들어 가는 디코딩 단계에서는 160억 개의 파라미터를 활성화합니다. 다만, 로컬 슬라이딩 윈도우 어텐션(Sliding-window Attention)에는 여전히 추가 연산이 필요합니다.

V4.1 Flash는 '제한된 재생(Bounded Replay)'이라는 방법도 씁니다. 최근의 짧은 구간만 다시 계산해서 슬라이딩 윈도우 상태를 근사적으로 복원하는 방법인데, 계산을 조금 더 하는 대신에 계속 저장해 둬야 하는 상태를 줄이는 쪽을 택한 것으로 볼 수 있죠. 하지만, 근사와 희소 선택에서 생기는 오차가 딥시크가 평가하지 않은 상황에서는 문제를 일으킬 수 있다는 점은 기억해 두시는 게 좋겠습니다.

또, 딥시크는 Compressed Sparse Attention 2로 중복을 한 번 더 덜어 냈습니다. 어떤 레이어는 글로벌 KV 상태를 만들고 그중 관련 있는 항목을 고르고, 다른 레이어는 그 상태를, 또는 상태와 선택 결과를 함께 재사용하는 방식입니다. 여기에 저정밀도 FP4 캐싱까지 더해서, 앞서 말한 수준까지 글로벌 KV 사용량을 줄였습니다.

에이전트 관점에서 보면, 이런 설계는 모두 컨텍스트가 길어질수록 비용이 눈덩이처럼 불어나는 문제를 줄이려는 선택이라고 볼 수 있는데, 이런 설계가 실제로 효과를 내는지는 모델을 둘러싼 서빙 스택, 즉 인프라를 어떻게 짜느냐에 달려 있습니다.

모델을 손에 넣었다면, 다음으로 고민할 건 그 모델을 어떻게 효율적으로 운영하느냐겠죠. 딥시크가 내놓은 답은 ‘DeepInfer’입니다. 딥시크는 지난 10월 20일에 공개한 DeepInfer를 자사의 프로덕션 서비스를 실제로 움직이는 추론 프레임워크라고 소개하는데, 지금 공개된 버전은 ‘오프라인 추론’ - 사용자 요청을 실시간으로 받아 응답하는 게 아니라, 미리 준비해 둔 입력을 한꺼번에 처리하는 방식 - 만 지원합니다.

그럼, DeepInfer 안에는 무엇이 들어 있는지 살펴보죠.

DeepInfer에는 개발자가 가져다 쓸 만한 요소가 꽤 많습니다. 우선, DSpark라는 ‘투기적 디코딩(Speculative Decoding)’ 기능이 있습니다. 작은 드래프트 모델이 다음에 올 토큰 여러 개를 먼저 제안하면, 신뢰도 추정값을 보고 그 중에 몇 개를 검증할지 정하는 방식인데, 속도가 얼마나 빨라지는지는 드래프트 모델이 제안한 토큰이 얼마나 채택되느냐에 어느 정도 달려 있죠. 그리고, ‘비동기 스케줄링’으로 CPU가 다음 배치를 준비하는 동안에도 GPU 같은 가속기를 쉬지 않게 해서, 연산 단계 사이에 생기는 빈틈을 줄입니다. 지원하는 하드웨어는 NVIDIA SM100 GPU와 화웨이 Ascend 950 NPU입니다.

하지만, 여러 사용자가 동시에 쓰기 시작하면 현실적인 문제들이 드러납니다. 각 요청을 어느 서버로 보내야 할지, 이미 처리한 컨텍스트를 다시 쓸 수 있을지 같은 문제들이죠. 딥시크는, 공개 버전에서 여러 서버가 함께 쓰는 공유 KV 캐시 저장소, 비전 인코딩·프리필·디코드를 나눠 처리하는 서빙 구조, 그리고 로드 밸런싱을 개발자의 몫으로 남겨 두었습니다. 엔진은 자기의 내부 KV 상태만 관리하기 때문에, 서비스 전체에서 KV 상태를 공유하고 재사용하려면 그만큼의 인프라를 따로 갖춰야 합니다.

딥시크가 염두에 둔 규모가 어느 정도인지는 배포 가이드를 보면 감이 옵니다. 딥시크가 효율적인 서빙을 위해 권장하는 가장 작은 구성이 프리필용 GPU 64개에 디코딩용 GPU 64개인데요, 가이드에는 프리필 인스턴스 하나와 디코드 인스턴스 하나만으로도 배포할 수는 있다고 나와 있습니다.

결국, DeepInfer로 엔진을 들여다보고 우리 환경에 맞게 손볼 수는 있지만, 코딩 에이전트를 사용자에게 서비스하려면 그 주변에 서빙 시스템을 추가로 따로 세워야 한다는 이야기입니다.

그리고, 여기서 질문이 하나 더 생깁니다. 모델을 운영하기 시작하면, 에이전트는 여러 도구와 어떻게 함께 일하게 될까요?

어쩌면 많은 분들께 가장 흥미로운 부분, ‘하네스(Harness)’입니다. 하네스는 에이전트의 구성 요소를 한데 엮어 주고, 개발자가 그 위에 기능을 더 붙일 수 있게 해 주는 장치인데요, 하는 일은 모델을 둘러싼 루프를 관리하는 겁니다. 컨텍스트를 조립해서 모델에 응답을 요청하고, 허용된 도구를 실행하고, 그 결과를 기록한 다음, 한 단계 더 나아갈지를 정하는 루프죠.

딥시크가 8월 13일에 공개한 DeepSeek Harness(dsh)는, 이 루프를 Cordis 기반의 ‘플러그인 아키텍처’ 위에 올려 두었습니다. 모델 어댑터, 도구 레지스트리, 세션 로그, 그리고 에이전트 루프 자체까지 모든 게 플러그인이죠. 그래서, 개발자는 모든 구성 요소가 기대고 있는 중앙 루프를 직접 고치지 않고도, 설정만 바꿔서 구성 요소를 블록처럼 갈아 끼울 수 있습니다. 딥시크 하네스에 대한 튜링포스트의 이전 글도 한 번 참고해 보시구요:

실행 환경이 좋은 예입니다. 이 아키텍처에서는 파일시스템 기능과 서브프로세스 기능이 실행 환경 하나를 함께 쓰기 때문에, 이 기능들의 제공자(Provider)만 바꾸면 도구를 하나하나 다시 짜지 않고도 관련 도구들을 한꺼번에 원격 샌드박스로 옮길 수 있습니다. 작업 기록도 또 다른 예죠. 모델이 보는 컨텍스트를 세션 로그가 공급하기 때문에, 중단된 세션을 이어 가는 일도, 무슨 일이 있었는지 되짚어 보는 일도 같은 기록 내용을 바탕으로 할 수가 있습니다.

우리가 만들려는 코딩 에이전트로 보면, 이런 설계 구조 덕분에 이것저것 실험을 해 볼 수 있습니다. 다른 구성 요소는 그대로 둔 채, 컨텍스트를 다루는 정책이나 코드를 실행하는 백엔드, 모델 어댑터만 바꿔 볼 수 있으니까요. 구성 요소를 갈아 끼울 수 있다는 건 개발자가 통제할 수 있는 범위가 그만큼 넓어진다는 뜻이지만, 동시에 어떤 구성 요소에 실제 코드 저장소와 자격 증명, 네트워크 접근을 허락할지도 개발자가 직접 정하고 책임져야 한다는 뜻이기도 하죠.

그리고, 안전과 관련해서 꼭 말씀드려 둘 게 있습니다. DeepSeek Harness는 실험적인 개발자 프리뷰이고, 보안 감사를 거치지 않았습니다. 딥시크도 이 하네스를 안전하다거나 프로덕션에 쓸 수 있다고 여기면 안 된다고 분명히 밝혔습니다. 플러그인과 모델이 생성한 명령은 자기에게 열려 있는 자원이라면 어디든 영향을 미칠 수 있고, 샌드박싱과 승인 프롬프트로 위험을 줄일 수는 있어도 완전한 격리를 보장하지는 못합니다.

하네스가 에이전트에 루프를 적용할 수 있게 해 준다고 해도, 에이전트는 그 밖에도 모델과 올바른 형식으로 정보를 주고받고, 모델이 돌려준 응답 - 추론 내용, 도구 호출, 구조화된 응답 - 을 제대로 해석할 수 있어야 합니다.

모델이 실제로 받는 건, '여기부터 사용자의 말', '여기부터 도구의 결과'처럼 경계를 특수 토큰으로 표시한 하나의 긴 텍스트이고, 이 형식은 모델마다 다릅니다. 모델이 내놓는 출력도 하나의 텍스트라서, 그 안에서 어디까지가 추론이고 어디가 도구 호출인지를 다시 잘라 내야 하죠. 그런데, 애플리케이션은 OpenAI나 앤쓰로픽의 표준 API 형식으로 말하기 때문에, 이 둘 사이에서 요청을 모델의 형식으로 바꿔 넣고 출력을 구조화된 데이터로 다시 나눠 주는 '통역' 계층이 필요합니다. 이 계층이 바로 ‘프로토콜 라이브러리’이고, 스택에서 잘 눈에 띄지 않지만 여기서 짚고 넘어갈 만하죠.

‘deepseek-recipe’는, 딥시크 모델과 주고받는 이 과정을 도와주는 라이브러리입니다. Rust 라이브러리와 Python 바인딩을 제공하는데, Messages, Chat Completions, Responses 같은 여러 API 형식에 맞춰 요청을 만들고, 프롬프트를 렌더링하고, 모델의 출력을 파싱해 줍니다. 다만, 추론을 실행하고, HTTP로 연결하고, 도구를 실제로 실행하는 일은 여전히 애플리케이션이 맡아야 합니다.

0.2.0 업데이트에서는 JSON 스키마를 지원하기 시작했습니다. 지원하는 스키마인지 검증해서 프롬프트에 넣고, 출력 제약 조건을 백엔드로 넘겨 주는데요, 그 제약을 ‘제약 디코딩(Constrained Decoding)’ - 모델이 정해진 형식에서 벗어난 토큰을 아예 고르지 못하게 하는 방식 - 으로 실제로 강제하느냐는 어떻게 통합하느냐에 달려 있습니다. 이 업데이트로 공개 API도 바뀌었기 때문에, 기존에 통합해 둔 코드는 손봐야 할 수도 있다는 점은 말씀드려 둡니다.

몇몇 세부 사항은 여전히 따로 설정해야 하는데, 예를 들어서, 모델이 추론에 쓴 토큰 수를 알고 싶다면 스트리밍 프로세서에 토크나이저를 붙여 줘야 하죠.

백엔드를 바꾼 뒤에 에이전트가 이전과 다르게 움직인다면, 이 계층부터 확인해 보시는 게 좋겠습니다. 모델이 바뀌어서 그럴 수도 있지만, 요청과 응답을 다루는 방식이 바뀌어서 그럴 수도 있으니까요.

에이전트에게는 실제로 일할 공간이 필요합니다. 코드를 실행하고, 파일을 고치고, 해결책이 맞는지 시험해 보려면, 단계와 단계 사이에 작업 상태를 유지하면서도 다른 작업과는 격리된 환경이 있어야 하죠. 그런데, 에이전트 수십만 개를 한꺼번에 학습시키고 평가한다면 어떨까요? 딥시크는 이런 격리된 실행 환경, 즉 ‘샌드박스’를 동시에 38만 개 넘게 돌린다고 밝혔습니다.

DeepSeek Elastic Compute(DSec)는, 에이전트가 코드를 실행하고 파일을 바꾸고 그 결과를 확인할 수 있는 공간을 제공합니다. Python 인터페이스 하나로 여러 종류의 환경을 골라 쓸 수 있는데, 상태를 남기지 않고 함수만 실행하는 가벼운 실행기부터 컨테이너, 가볍게 띄우는 가상 머신인 마이크로VM, 그리고 완전한 가상 머신까지 있습니다. 짧은 스크립트 하나를 돌리는 일과 안드로이드 안에서 일하는 에이전트에 필요한 환경은 다를 수밖에 없으니, 호출하는 쪽이 필요한 환경을 고르게 한 거죠.

그 인터페이스 뒤에서, 딥시크는 일을 두 계층으로 나눴습니다:

클러스터 계층은 네 가지 구성 요소로 이뤄져 있습니다. IAM은 요청한 쪽의 신원과 권한, 자원 할당량을 확인합니다. 워처(Watcher)는 각 머신의 상태와 부하를 지켜보고, 배치 엔진(Placement Engine)은 그 정보를 바탕으로 알맞은 머신을 고르죠. API 서버는 요청을 그 머신으로 보내는데, 신뢰할 수 있는 학습 시스템과 네트워크에서 격리된 샌드박스 클러스터 사이를 잇는 통로는 이 API 서버 하나뿐입니다.

각 머신에서는, edge가 샌드박스를 띄우는 일부터 네트워크 규칙, 정리, 스냅샷까지 샌드박스의 용량과 생애주기를 관리합니다. 컨테이너와 VM 샌드박스 안에서는 aether가 작업을 chronus로 넘기고, chronus가 셸 세션과 파일 접근, HTTP 요청, 스트리밍 출력을 제공하죠. 가벼운 FnCall 작업은 미리 만들어 둔 컨테이너를 거치는 더 짧은 경로로 처리합니다.

DSec은, 3FS를 써서 컨테이너와 마이크로VM의 이미지 데이터를 필요한 부분만 그때그때 불러오기 때문에, 샌드박스를 띄우기 전에 이미지 전체를 내려받을 필요가 없습니다. 에이전트의 작업 공간도 단계와 단계 사이에 그대로 유지하고요. 그리고, DeepSeek-V4.1부터는 에이전트 루프와 그 워커를 GPU 학습 작업과 따로 돌리기 때문에, 학습이 중간에 멈추더라도 에이전트의 작업을 처음부터 다시 할 필요가 없습니다.

다만, 제가 살펴본 공개 자료는 DSec의 아키텍처를 설명할 뿐이고, 가져다 배포할 수 있는 플랫폼으로 내놓은 건 아니라는 점은 말씀드려 둡니다. 다른 샌드박스 시스템을 써도 되고, 딥시크의 학습 인프라를 재현하는 일은 에이전트 하네스를 돌리는 일과는 전혀 다른 별개의 프로젝트입니다.

요즘 에이전트라면 거의 다 일하는 도중에 문서를 찾아보거나 웹페이지를 읽어야 할 일이 생기는데요, 딥시크는 여기에도 나름의 답을 내놓았습니다:

둘 다 딥시크가 운영하는 읽기 전용 JSON API라서, 애플리케이션은 딥시크 API 키만 있으면 바로 호출할 수 있습니다. 검색 엔진과 페이지 수집 서비스를 직접 만들 필요가 없어지는 셈이죠. 하지만, 검색 엔진 자체는 여전히 딥시크의 인프라에서 돌아갑니다. API를 쓸 수 있다고 해서 검색 인덱스나 순위를 매기는 방식, 직접 설치해서 운영할 수 있는 검색 서비스를 손에 넣는 건 아니니까요. 에이전트에 이 도구들을 붙이는 건 얼마든지 가능하지만, 그만큼 사용료와 호출 한도(Rate Limit), 서비스가 멈췄을 때의 영향까지 함께 따져 봐야 합니다.

문서에 나온 가격은 API마다 성공한 요청 1,000건당 0.75달러이고, 실패한 요청과 검색 결과가 비어 있는 경우에는 과금하지 않습니다. 딥시크는, DeepSeek Harness나 Claude Code, Codex에서 딥시크 API를 통해서 서버 쪽 Search와 Fetch를 호출하면 무료로 제공해 왔는데, 2026년 11월 1일 0시(베이징 시간, 한국 시간 오전 1시)부터 요청당 과금을 시작했습니다.

지금까지 모델과 에이전트 루프, 그리고 에이전트가 일하는 공간을 살펴봤는데요, 이제 한 계층 더 내려가서 실제로 계산을 하고 칩과 칩 사이로 데이터를 옮기는 라이브러리들을 들여다보죠. 딥시크가 이 계층을 공개하기 시작한 건 2025년 2월 24일, 딥시크의 ‘오픈소스 위크(Open-Source Week)’ 때부터입니다.

이번에 새로 나온 릴리스들은 그때 시작한 작업들을 기반으로 추가, 개선된 것들입니다:

이 라이브러리들이 어디에 쓰이는지는 직접 따라가 볼 수 있습니다. DeepInfer는 FlashMLA, DeepGEMM, DeepEP를 서브모듈로 담고 있고, Ascend용 DeepGEMM과 DeepEP도 함께 들어 있습니다. 이 라이브러리들을 함께 놓고 보면, 모델을 운영하는 데 들어가는 작업이 훨씬 더 많이 드러나죠.

화웨이 칩 지원도 이 작업의 일부입니다. DeepGEMM-Ascend는 Ascend에서 같은 API로 쓸 수 있는 구현을 제공하고, FlashMLA와 TileKernels에도 Ascend용 커널이 들어 있습니다.

다만, 지원하는 하드웨어는 라이브러리와 연산마다 다르기 때문에 어느 버전을 쓰느냐도 중요합니다. 예를 들어, 딥시크는 2026년 9월 30일에 FlashMLA를 업데이트하면서 Ascend 커널을 추가한 대신에, 해당 버전에서는 NVIDIA의 Hopper(H100 세대)와 그 이전 GPU 지원을 뺐고 FP8/FP4 KV 캐시 형식도 바꿨습니다. 기존에 배포해 둔 환경이라면, README에 링크된 이전 버전을 쓰면 됩니다.

그리고, 분산 파일시스템인 3FS가 있습니다. 문서에 따르면, 3FS는 학습 데이터와 체크포인트, 그리고 추론에 쓰는 KV 캐시까지 다룹니다. 같은 저장소를 바탕으로 학습과 서빙을 모두 받칠 수 있으니, 인프라 팀 입장에서는 재사용할 수 있는 요소가 하나 더 생긴 셈이죠. 하지만, 3FS도 서빙 시스템과 연결하는 일은 따로 해야 하고, 아쉽게도 이 파일시스템이 있다고 해서 DeepInfer에 빠져 있는 공유 캐시 서비스가 저절로 생기지는 않는다는 점은 말씀드려 두겠습니다.

지금까지 각 요소가 무슨 일을 하는지 살펴봤으니, 이제 이 요소들을 한데 맞춰 보면서 처음의 질문으로 돌아가 보죠. 딥시크가 공개한 것들만 가지고, 실제로 돌아가는 에이전트 시스템의 어느 부분까지를 만들 수 있을까요?

딥시크는 모델 가중치, 추론 엔진, 프로토콜 라이브러리, 하네스, 그리고 연산과 통신, 저장을 위한 도구까지, 에이전트를 만드는 데 필요한 요소들을 상당히 많이 공개했습니다. 그렇다고 해도, 우리가 직접 해야 할 일이 얼마나 남는지는 결국 무엇을 만들려고 하느냐에 따라 달라지죠.

먼저, 사용자에게 서비스하려면 모델을 실행하는 것만으로는 부족합니다. DeepInfer의 공개 버전은 오프라인 추론만 지원하고, README에도 서비스 수준의 KV 캐시 관리, 비전 인코딩·프리필·디코드를 나눠 처리하는 서빙, 그리고 프리필 서버와 디코드 서버 사이의 로드 밸런싱은 빠져 있습니다. 실제로 서비스를 운영하려면, 요청을 어느 서버로 보낼지, 이미 처리한 컨텍스트를 어떻게 재사용할지를 팀이 직접 정해야 하죠. 3FS가 저장소 역할을 할 수는 있지만, 그 저장소를 서빙 시스템과 연결하는 일은 여전히 개발자의 몫입니다.

공개된 요소들을 서로 이어 붙이는 일도 남아 있습니다. 예를 들어, deepseek-recipe는 요청의 형식을 맞추고 도구 호출을 포함한 모델의 출력을 파싱해 주지만, 추론을 실행하고 HTTP로 주고받고 그 도구를 실제로 실행하는 일은 애플리케이션이 해야 합니다.

에이전트를 운영하려면 에이전트가 어디까지 손댈 수 있는지, 그 경계도 정해야 합니다. Harness에는 권한 제어와 샌드박싱 도구가 들어 있지만, 딥시크가 안전 고지에서 밝혔듯이 보안 감사를 거치지 않았고 프로덕션에 쓸 준비도 되어 있지 않습니다. 그래서, 실제 코드 저장소나 자격 증명, 네트워크에 연결하기 전에, 팀은 에이전트가 무엇에 접근할 수 있는지를 직접 정하고 시험해 봐야 하죠. 작은 규모로 배포한다면, 이미 나와 있는 샌드박스 시스템으로도 충분할 수 있습니다.

에이전트를 대규모로 학습시키고 평가하려고 한다면, 계층이 하나 더 필요합니다. 하네스가 에이전트 루프를 제공하기는 하지만, 대규모 실험에는 서로 격리된 환경과 긴 작업 동안 상태를 보존하는 방법, 그리고 다 쓴 자원을 회수하는 시스템이 필요하니까요. 딥시크는 DSec으로 이런 환경을 대규모로 어떻게 관리하는지 설명했지만, 제가 살펴본 공개 자료에는 가져다 배포할 수 있는 릴리스가 없습니다.

마지막으로, 어떤 기능은 여전히 딥시크의 서비스로 남아 있습니다. 딥시크의 Search와 Fetch를 에이전트의 도구로 쓸 수는 있지만, 모든 요청이 딥시크를 거치기 때문에, 딥시크에 기대지 않고 독립적으로 운영하려는 팀이라면 다른 대안을 찾아야 합니다.

딥시크가 공개한 것들을 가지고, 우리가 만들려고 하는 (코딩) 에이전트를 어디까지 만들 수 있을까요? 적어도, 모델이 내놓는 답만 보는 데서 그치지 않고 그보다 훨씬 아래까지 내려가서 시스템이 어떻게 돌아가는지를 직접 들여다볼 수 있게 됐다는 것, 그것만으로도 꽤 큰 의미가 있다고 생각합니다.

딥시크 덕분에, 인프라를 만드는 사람들이 손댈 수 있는 범위는 그만큼 넓어졌습니다. 이제 에이전트 개발이나 인프라팀이 모든 계층을 처음부터 새로 만들지 않고도 DeepInfer 주변에 캐시 서비스를 붙이거나, Harness의 구성 요소 하나를 갈아 끼우거나, 커널 하나를 개선해 볼 수 있죠. 아키텍처와 런타임, 그리고 그 둘을 받치는 라이브러리까지 한데 놓고 공부할 수 있고, 한 계층을 바꿨을 때 다른 계층에 어떤 영향이 가는지도 직접 따라가 볼 수 있습니다.

그렇게 보면, 앞으로 에이전트 생태계를 둘러싼 경쟁의 모습도 달라질 수 있지 않을까 싶습니다. 더 나은 에이전트 시스템을 만들려고 모든 팀이 더 나은 모델을 직접 학습시킬 필요는 없어지는 거죠. 이미 있는 모델을 쓸모 있게 만드는 인프라를 개선하고, 딥시크가 내놓은 요소들을 이리저리 맞춰 보면서 우리에게 가장 잘 맞는 조합을 찾는 쪽으로도 얼마든지 경쟁할 수 있으니까요.

읽어주셔서 감사합니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!