DeepSeek Harness의 4가지 모드: 스탠더드, 코드, 미니멀, 크리에이터 설명

DeepSeek Harness에는 네 가지 런타임 모드가 있습니다. Standard, Code, Minimal, Creator. 이 모드들은 네 가지 성능 단계가 아니며, 다른 모드를 선택한다고 해서 기반이 되는 DeepSeek 모델 자체가 본질적으로 더 똑똑해지거나 약해지는 것도 아닙니다. 대신 각 모드는 모델을 둘러싼 환경을 변경합니다. 즉, 모델이 사용할 수 있는 도구, 도구를 조정하는 방식, 하네스가 제공하는 지원의 정도, 그리고 에이전트가 작업을 수행하는지, 평가받는지, 아니면 하네스 자체를 수정하는지를 바꿉니다.

차이를 기억하는 가장 간단한 방법은 다음과 같습니다. Standard는 작업을 수행하기 위한 모드이고, Code는 작업을 조정하기 위한 모드이며, Minimal은 모델을 측정하기 위한 모드이고, Creator는 하네스를 변경하기 위한 모드입니다. 이 구분이 중요한 이유는 에이전트 성능이 모델 가중치만으로 결정되지 않기 때문입니다. 도구 인터페이스, 실행 루프, 메모리, 권한, 계획 시스템 및 기타 하네스 구성 요소가 모두 에이전트가 수행할 수 있는 작업에 영향을 줍니다.

DeepSeek를 다른 지속형 에이전트 환경과 비교하고 있다면, DeepSeek 에이전트를 위한 Hermes 플러그인 가이드에서도 다른 관점에서 같은 원칙을 보여 줍니다. 에이전트 계층을 변경하면 기본 모델을 교체하지 않고도 비전, 메모리, 비공개 데이터 접근 등의 기능을 추가할 수 있습니다.

DeepSeek Harness에는 왜 네 가지 모드가 필요한가요?

DeepSeek Harness는 에이전트가 단순히 명령줄이 연결된 언어 모델이 아니라는 생각을 바탕으로 구축되었습니다. 하네스는 모델과 환경 사이에 위치해 모델이 볼 수 있는 것, 사용할 수 있는 도구, 작업 실행 방식, 세션 기록 방식, 여러 단계에 걸쳐 발생하는 일을 결정합니다. DeepSeek는 이러한 관계를 모델과 하네스가 결합되어 에이전트를 구성한다고 요약합니다.

이러한 아키텍처 덕분에 DeepSeek Harness의 네 가지 런타임 모드는 동일한 기반 모델을 사용하면서도 매우 다르게 작동할 수 있습니다. Standard는 일상적인 에이전트 환경 전체를 제공합니다. Code는 이러한 기능을 유지하면서 모델이 도구를 조정하는 방식을 변경합니다. Minimal은 하네스의 지원을 대부분 의도적으로 제거합니다. Creator는 런타임 자체를 점검하고 재구성할 수 있는 기능을 추가합니다.

따라서 이러한 모드를 기본부터 고급까지 이어지는 단계로 해석해서는 안 됩니다. Minimal이 Standard보다 낮은 단계인 것도 아니며, Creator가 단순히 더 강력한 Standard Mode인 것도 아닙니다. 각 프리셋은 서로 다른 질문에 최적화되어 있습니다. 에이전트는 어떻게 작동해야 하는가? 도구를 어떻게 조정해야 하는가? 결과 중 어느 정도가 모델 자체에서 비롯되는가? 또는 에이전트 환경을 어떻게 다시 구축해야 하는가?

1. 표준 모드 — 기본 전체 DeepSeek 에이전트 환경

표준 모드는 DeepSeek에 작업을 맡기고 완료하게 하는 것이 목표일 때 자연스러운 시작점입니다. 파일 편집, 셸 액세스, 파일 및 웹 검색, 스킬, 계획, 목표, 서브에이전트, 워크플로를 포함한 완전한 코딩 에이전트 환경을 제공합니다. 다음 단계를 매번 수동으로 결정할 필요 없이 모델이 환경을 살펴보고, 작업을 수행하고, 결과를 확인한 뒤 계속 진행할 수 있습니다.

이렇게 하면 익숙한 에이전트 루프가 만들어집니다. 저장소를 살펴보고, 관련 파일을 검색하고, 코드를 읽고, 수정하고, 명령을 실행하고, 오류를 확인한 뒤 결과를 개선하는 과정입니다. 이 목록에서 중요한 역량은 특정 도구 하나가 아닙니다. 새로운 정보가 나타날 때 환경을 계속 탐색하며 작업을 진행하는 능력입니다. DeepSeek의 플러그인 아키텍처는 에이전트를 하나의 고정된 애플리케이션으로 취급하지 않고 이러한 기능을 조합할 수 있도록 합니다. 릴리스 관련 보도에서는 이를 플러그인 조합형 에이전트 런타임이라고 설명했습니다.

대부분의 사용자에게는 표준 모드가 올바른 기본값입니다. DeepSeek로 버그를 조사하거나, 저장소를 이해하거나, 기능을 구현하거나, 여러 파일을 살펴보거나, 일반적인 다단계 코딩 작업을 조율하려는 경우라면 도구가 문제를 일으킨다는 사실을 확인하기 전부터 일부러 도구를 제거할 이유가 거의 없습니다.

세션의 목적이 생산성보다 평가에 있을 때는 표준 모드가 덜 적합합니다. 검색, 계획, 스킬, 서브에이전트 및 기타 하네스 구성 요소가 모델의 약점을 보완해 모델이 성공한다면, 최종 결과는 에이전트 시스템이 얼마나 잘 작동했는지를 보여 줍니다. 외부 지원을 최소화했을 때 기본 모델이 얼마나 잘 수행하는지는 명확하게 알려 주지 못합니다.

2. 코드 모드 — DeepSeek가 도구 오케스트레이션을 프로그램으로 전환하도록 하기

Code Mode는 네 가지 모드 중 가장 오해하기 쉽습니다. Code Mode는 “코딩 작업만을 위한 Standard Mode”를 의미하지 않습니다. DeepSeek의 현재 정의에 따르면 Code Mode는 Standard Mode의 모든 기능을 유지합니다. 달라지는 점은 도구가 모델에 노출되는 방식입니다. DeepSeek는 Code Mode SDK를 사용해 여러 작업을 모델이 생성한 TypeScript 프로그램 안에서 결합할 수 있습니다.

일반적인 에이전트 루프에서는 복잡한 작업에 모델과 개별 도구 간의 반복적인 교환이 필요할 수 있습니다. 에이전트는 검색하고, 결과를 받은 뒤, 무엇을 읽을지 결정하고, 이를 읽고, 그 결과를 처리한 다음, 다른 도구를 호출하며 작업을 계속합니다. Code Mode SDK는 이러한 제어 흐름의 일부를 실행 가능한 코드로 옮겨, 모델이 여러 번의 독립적인 도구 호출 대신 루프, 필터링, 분기, 그리고 서로 의존하는 여러 도구 작업을 하나의 프로그램으로 표현할 수 있게 합니다.

수백 개의 파일을 검색하고, 경로로 일치 항목을 필터링한 다음, 일부만 읽고, 값을 추출한 뒤, 각 결과에 동일한 검사를 실행해야 하는 작업을 생각해 보세요. Standard Mode도 이 워크플로를 수행할 수 있지만, 오케스트레이션의 상당 부분이 반복되는 에이전트 실행 단계에 분산됩니다. 오케스트레이션 자체가 작은 프로그램과 비슷해지기 시작할 때 Code Mode가 매력적입니다.

파일 검색
→ 일치하는 경로 필터링
→ 결과 반복 처리
→ 선택한 파일 읽기
→ 반환된 데이터 처리
→ 후속 작업 실행

중요한 단어는 “코딩”이 아니라 복잡성입니다. 단순한 편집 작업이 Code Mode에서 TypeScript 코드를 생성한다고 해서 자동으로 더 나아지는 것은 아닙니다. 몇 가지 도구만 관여한다면 Standard Mode가 오히려 이해하기 쉬울 수 있습니다. 반복 작업, 구조화된 변환, 조건부 로직 또는 도구 결과 처리가 여러 번의 모델 호출을 필요로 할 때 Code Mode가 더 흥미로워집니다.

3. Minimal Mode — Harness를 제거하고 모델을 더 자세히 살펴보기

Minimal Mode는 느린 PC나 소형 홈 서버를 위한 경량 옵션이 아닙니다. 의도적으로 제약된 에이전트 환경입니다. DeepSeek는 현재 이를 영구적인 bash와 str_replace_editorStandard Mode에서 사용할 수 있는 더 폭넓은 검색, 스킬, 하위 에이전트, 워크플로 기능을 제거합니다.

해당 제한이 있는 이유는 평가 때문입니다. DeepSeek 자체도 V4-Flash로 보고된 공개 Code Agent 벤치마크에서 DeepSeek Harness Minimal Mode를 사용했습니다. 이러한 사용 방식은 의도를 훨씬 분명하게 보여 줍니다. Minimal은 연구자가 작고 통제된 도구 집합으로 모델이 무엇을 수행할 수 있는지 더 좁은 관점에서 살펴보려 할 때, 주변 에이전트 기능을 줄이도록 설계되었습니다.

이러한 구분이 중요한 이유는 최신 에이전트 벤치마크가 모델 이상의 것을 측정할 수 있기 때문입니다. 강력한 플래너, 더 나은 컨텍스트 구성, 저장소 검색, 특화된 스킬, 재시도 정책 또는 하위 에이전트 위임은 모두 작업의 성공 여부를 바꿀 수 있습니다. 하네스 평가 연구 역시 성능을 자동으로 모델 가중치에만 귀속하기보다 모델-하네스 구성 수준에서 역량을 해석해야 한다고 주장합니다.

이로 인해 Minimal Mode는 Standard와 매우 다른 최적화 목표를 갖게 됩니다. Standard는 “이 에이전트가 유용한 작업을 완료할 가능성을 가장 높이는 환경은 무엇인가?”라고 묻습니다. Minimal은 “이 환경의 상당 부분을 제거하고 모델에 더 작은 실행 표면만 남기면 어떤 일이 일어나는가?”라고 묻습니다.

일상적인 작업에서는 유용한 기능을 의도적으로 버리는 것이 오히려 비생산적일 수 있습니다. 목표가 저장소를 최대한 빠르고 안정적으로 수정하는 것이라면 Minimal Mode는 대개 잘못된 문제를 해결하려는 셈입니다. 재현성, 비교, 디버깅 또는 원시 모델 동작의 이해가 최대한의 작업 완료보다 중요할 때 Minimal Mode의 가치가 드러납니다.

4. Creator Mode — DeepSeek Harness를 사용해 Harness를 변경하기

Creator Mode는 작업 대상 자체를 바꿉니다. Standard Mode는 주로 에이전트 환경을 사용하는 반면, Creator Mode는 그러한 환경을 만들고 실험하도록 설계되었습니다. Standard Mode의 기능을 포함하면서 런타임 검사, 메모리 내 플러그인 실험, 사용자 지정 프리셋 작성 안내를 추가합니다.

이는 DSH의 기반 아키텍처에서 직접 이어지는 특징입니다. DeepSeek는 모델, 도구, 스킬, 세션, 샌드박스, 스토리지, 루프, 스케줄링, 심지어 UI까지 선택하거나 교체하거나 재구성할 수 있는 플러그인으로 설명합니다. Cordis 커널은 플러그인의 마운트, 마운트 해제 및 종속성 관리를 담당하므로, DSH를 확장할 때 권한이 집중된 모놀리식 에이전트 코어를 반드시 수정할 필요는 없습니다. 이러한 폭넓은 설계 때문에 프로젝트의 “모든 것이 플러그인”이라는 주장은 단순히 네 가지 프리셋이 존재한다는 사실보다 더 중요합니다.

홈 서버를 관리하는 데 특화된 에이전트가 필요하다고 가정해 보겠습니다. 이 에이전트의 유용한 환경에는 셸 액세스, 제한된 파일 시스템 권한, Docker 작업, 인프라 문서, 모니터링 도구, 그리고 몇 가지 특화된 스킬이 포함될 수 있습니다. 이러한 조합은 일반적인 코딩 에이전트와 동일하지 않습니다. Creator Mode는 이러한 기능을 실험하고 재사용 가능한 에이전트 프리셋으로 조합하는 데 중점을 두고 설계되었습니다.

현재 런타임 검사
→ 플러그인 추가 또는 테스트
→ 서비스 및 종속성 확인
→ 구성을 조정
→ 특화 프리셋 저장
→ 해당 환경을 다시 실행합니다

따라서 Creator Mode는 Standard Mode보다 더 전문화되어 있지만, 일상적인 사용에 자동으로 더 적합한 것은 아닙니다. DeepSeek가 단순히 파일 세 개를 수정하고 테스트 모음을 실행하기를 원한다면 런타임 검사와 프리셋 작성은 큰 가치를 더하지 않습니다. Creator는 질문이 “에이전트가 이 작업을 수행할 수 있는가?”에서 “이 유형의 에이전트에는 어떤 기능이 있어야 하는가?”로 바뀔 때 유용해집니다.

Standard vs Code vs Minimal vs Creator: 실제로 무엇이 달라질까요?

가장 큰 실수는 네 가지 모드를 Minimal → Standard → Code → Creator와 같은 단계적 순서로 배열하는 것입니다. 이렇게 하면 각 단계가 단순히 더 많은 기능을 추가하는 것처럼 보입니다. 실제 관계는 다차원적입니다. Standard는 일반적인 실행을 강조하고, Code는 오케스트레이션 방식을 바꾸며, Minimal은 지원 기능을 의도적으로 줄이고, Creator는 하네스 자체를 구성할 대상으로 제공합니다.

기능 개수만 비교하기보다 동일한 질문을 기준으로 모드를 평가하면 차이가 더 명확해집니다. Standard와 Code는 모두 폭넓은 에이전트 환경을 유지하지만, Code는 여러 단계의 도구 작업을 표현하는 방식을 바꿉니다. Minimal은 의도적으로 반대 방향으로 나아가 도구 범위를 축소합니다. Creator는 단순히 또 하나의 일상적인 생산성 도구를 추가하는 대신, 런타임 구성을 위한 기능을 더하는 방식으로 Standard에서 출발합니다.

동일한 DeepSeek 모델을 사용한 두 테스트라도 하네스 구성이 다르면 결과가 달라질 수 있는 이유도 여기에 있습니다. DSH에 대한 초기 분석에서는 모델 이름만 비교하기보다 모델과 하네스 구성을 기록하는 것이 중요하다는 점이 이미 강조되었습니다. 도구 액세스, 권한, 컨텍스트 구성, 에이전트 루프 및 기타 런타임 선택이 모델이 작업을 수행하는 경로를 모두 바꿀 수 있습니다.

실제로 어떤 DeepSeek Harness 모드를 사용해야 할까요?

대부분의 일반적인 작업에서는 먼저 Standard Mode를 사용하세요. 이 모드는 DSH가 조율하도록 설계된 폭넓은 기능을 제공하므로, 더 전문화된 런타임이 정말 필요한지 직접 확인할 수 있습니다. 더 가벼워 보인다는 이유만으로 Minimal에서 시작하면 에이전트를 유용하게 만드는 바로 그 기능이 제거될 수 있습니다.

도구 워크플로 자체가 복잡해졌다면 코드 모드로 전환하세요. 작업에 소프트웨어 개발이 포함된다는 사실보다, 반복적인 검색, 여러 파일에 대한 루프, 도구 결과 필터링, 구조화된 변환 및 조건부 작업이 코드 모드를 사용해야 할 더 강력한 이유입니다.

질문의 초점이 최대 생산성이 아니라 모델 자체에 있다면 미니멀 모드를 사용하세요. 통제된 비교, 벤치마크 재현, 프롬프트 실험, 그리고 성공이 모델에 달린 것인지 아니면 더 풍부한 하네스에 달린 것인지 확인하려는 상황에 더 적합합니다.

에이전트 환경 자체를 변경하려면 크리에이터 모드를 사용하세요. 기본 에이전트를 단순히 운영하는 대신 DeepSeek Harness를 새로운 에이전트를 구축하기 위한 인프라로 다루는 개발자를 위해, 플러그인 실험과 특화된 프리셋에 적합하게 설계되었습니다.

더 큰 목표가 DSH 자체를 수정하는 것이 아니라 비공개 데이터를 중심으로 재사용 가능한 에이전트 기능을 구축하는 것이라면, 로컬 지식 베이스를 위한 AI 에이전트 스킬 가이드에서 셀프 호스팅 시스템에 반복 가능한 검색, 구문 분석, 근거 수집 및 지식 워크플로를 스킬로 패키징하는 방법을 설명합니다.

계획 모드는 DeepSeek Harness의 다섯 번째 런타임 모드가 아닙니다

용어를 혼동하게 만드는 또 다른 DSH 기능이 있습니다. 바로 계획 모드입니다. 표준, 코드, 미니멀, 크리에이터 모드와 나란히 속하는 것처럼 들리지만, DeepSeek의 현재 아키텍처에서는 다르게 취급됩니다. 위의 네 가지 모드는 런타임 프리셋 또는 구성입니다. 계획 모드는 모델에 제공되는 지침을 변경하는 에이전트별 선택적 계획 상태입니다.

DeepSeek의 서브시스템 문서에는 계획 모드는 부드러운 지침이라고 명시되어 있습니다. 활성화되면 계획과 관련된 프롬프트 섹션이 모델 요청에 포함됩니다. 샌드박스 모드와 승인 정책은 서로 독립적으로 제한을 적용하며, 에이전트 루프 자체는 계획 모드에 의존하지 않습니다.

이렇게 하면 두 개념은 서로 다른 역할을 맡게 됩니다. Standard, Code, Minimal, Creator는 런타임 구성에 관한 질문, 즉 어떤 기능이 존재하고 에이전트가 어떻게 작동하는지에 답합니다. Plan Mode는 행동에 관한 질문, 즉 실행을 진행하기 전에 에이전트가 계획 중심의 협업 상태를 유지해야 하는지에 답합니다.

Standard / Code / Minimal / Creator
= 런타임 구성

Plan Mode
= 계획 및 안내 상태

따라서 DeepSeek Harness에 모드가 네 개냐 다섯 개냐는 질문을 받는다면, 유용한 답변은 다음과 같습니다. DSH는 현재 네 가지 주요 런타임 모드를 제공하며, Plan Mode는 다섯 번째 동급 런타임 프리셋이 아니라 별도의 선택적 계획 메커니즘입니다.

네 가지 모드가 DeepSeek Harness에서 실제로 구축되고 있는 것을 보여 주다

DSH의 가장 흥미로운 점은 사용자에게 선택할 버튼 네 개를 제공한다는 사실이 아닙니다. 각 모드는 에이전트 엔지니어링의 서로 다른 네 가지 계층을 보여 줍니다. Standard는 실행에 중점을 둡니다. Code는 오케스트레이션에 중점을 둡니다. Minimal은 평가에 중점을 둡니다. Creator는 구성에 중점을 둡니다. 이 모드들은 함께 DeepSeek가 하니스를 모델 주변의 보이지 않는 접착제가 아니라 에이전트 동작의 능동적인 일부로 보고 있음을 보여 줍니다.

이는 에이전트 시스템의 개선이 반드시 더 큰 모델을 학습시키는 데서만 비롯될 필요는 없기 때문에 중요합니다. 도구 제시 방식, 컨텍스트 관리, 실행 정책, 재시도 동작, 스킬, 메모리 또는 런타임 구성을 변경하면 동일한 모델이 수행할 수 있는 작업이 달라질 수 있습니다. 전체 런타임을 다시 구축하기보다 이러한 기능을 확장하는 데 관심이 있다면, DeepSeek 및 Hermes 플러그인 스택은 주변 에이전트 시스템이 완전히 새로운 기능을 추가할 수 있음을 보여 주는 또 다른 사례입니다.

이는 네 가지 프리셋을 모든 상황에 적용할 수 있는 정답이 아니라 시작 구성으로 봐야 한다는 의미이기도 합니다. 벤치마킹 환경에서는 지원 기능이 적은 편이 좋습니다. 프로덕션 에이전트에는 더 많은 도구와 더 엄격한 권한이 필요할 수 있습니다. 복잡한 도구 워크플로에는 프로그래밍 방식의 오케스트레이션이 도움이 될 수 있습니다. 특화된 홈 서버 에이전트에는 결국 자체 프리셋이 적합할 수도 있습니다.

DeepSeek Harness는 아직 개발자 프리뷰 단계이며, DeepSeek는 핵심 플러그인과 API가 계속 발전할 것이라고 밝혔습니다. 따라서 정확한 프리셋과 인터페이스는 변경될 수 있습니다. 하지만 이러한 아키텍처상의 구분은 이미 유용합니다. 에이전트의 동작이 달라졌을 때 모델만 살펴보지 마세요. 해당 모델이 어떻게 행동할 수 있는지를 결정하는 하니스를 살펴보세요.