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는 네 가지 모드 중 가장 오해하기 쉽습니다. 이는 “코딩 작업만을 위한 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은 연구자가 작고 통제된 도구 집합으로 모델이 무엇을 수행할 수 있는지 더 좁은 관점에서 확인하려 할 때, 주변 에이전트 기능을 줄이도록 설계되었습니다.

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

따라서 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는 harness 자체를 구성할 대상으로 노출합니다.

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

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

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

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

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

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

에이전트 환경 자체를 변경하려면 Creator 모드를 사용하세요. 플러그인 실험, 특화된 프리셋, 그리고 DeepSeek Harness를 단순히 기본 에이전트로 사용하는 것이 아니라 새로운 에이전트를 구축하기 위한 인프라로 다루는 개발자를 위한 모드입니다.

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

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

용어를 혼동하게 만드는 또 다른 DSH 기능이 있습니다. 바로 플랜 모드입니다. Standard, Code, Minimal, Creator와 나란히 속하는 것처럼 들리지만, 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가 계속 발전할 것이라고 밝혔습니다. 따라서 정확한 프리셋과 인터페이스는 변경될 수 있습니다. 하지만 아키텍처상의 구분은 이미 유용합니다. 에이전트의 동작이 달라질 때는 모델만 살펴보지 마세요. 해당 모델이 어떻게 행동할 수 있는지를 결정하는 하니스도 살펴봐야 합니다.