2026년 딥시크 하네스 추론 강도 선택법

공식 문서상 사고 모드는 기본으로 켜지고 기본 강도는 high이며, low는 실제 낮은 강도로 매핑됩니다. 따라서 이번 주에는 모든 작업을 높은 강도로 고정하지 말고, 검증하기 쉬운 작업은 낮은 강도로 시작하고 복합 수정과 고위험 판단만 높은 강도로 올리는 이중 운영을 적용하는 편이 합리적입니다. (사고 모드 공식 문서)

이 글은 간단한 작업을 과도하게 깊게 처리하고 싶지 않은 개발자, 저장소별 에이전트 정책을 정해야 하는 팀, 원격 맥에서 장시간 백그라운드 작업을 운영하며 자원 낭비를 줄이려는 담당자를 위한 글입니다.

마지막 업데이트: 2026년 8월 18일. 최신 사고 모드 문서, 도구 호출 문서, 모델 요금 문서를 기준으로 확인했습니다.

낮은 추론 강도와 높은 추론 강도를 고를 때 “어느 쪽이 무조건 빠른가”를 먼저 묻는 방식은 위험합니다. 공식 문서는 low, high, max를 지원하지만, 높은 강도가 항상 더 정확하다는 작업별 보장은 제시하지 않습니다. 실제 선택 기준은 다음 세 가지입니다.

• 검증 가능성: 결과를 사람이 짧은 시간 안에 확인할 수 있는가
• 영향 범위: 한 파일에 머무는가, 여러 모듈의 동작을 바꾸는가
• 실패 비용: 잘못된 결과가 단순 재실행으로 끝나는가, 배포 장애나 데이터 손상으로 이어지는가

DeepSeek 모델의 사고 모드에서는 도구 호출을 사용할 수 있습니다. 다만 도구 호출이 포함된 다음 요청에는 앞선 응답의 reasoning_content를 전달해야 하며, 누락하면 오류가 발생할 수 있습니다. 추론 강도 전환은 도구 권한을 자동으로 바꾸는 기능이 아니지만, 모델의 호출 순서와 추가 검증 행동에는 영향을 줄 수 있습니다. 도구 인자의 형식과 함수 호출 결과 검증은 채팅 완성 공식 API 문서에서도 확인해야 합니다. (도구 호출 공식 문서)

이 표는 비용표가 아닙니다. 공식 요금은 입력과 출력 토큰을 기준으로 청구되므로, 낮은 강도가 반드시 전체 비용을 줄인다고 단정할 수 없습니다. 재실행과 사람의 수정 시간이 늘면 낮은 강도의 실제 운영 비용이 더 커질 수도 있습니다. 현재 모델 문서에는 플래시와 프로가 각각 다른 토큰 단가와 동시성 한도를 갖는 것으로 표시되어 있으므로, 팀은 강도뿐 아니라 모델 선택과 재시도 횟수도 함께 기록해야 합니다. (모델과 요금 공식 문서)

주의: 공식 문서의 강도 매핑은 모델 버전과 요청 방식에 따라 달라질 수 있습니다. 설정 파일에 값을 저장한 뒤 실제 요청 본문에 어떤 값이 전달되는지 확인하지 않으면, 화면에서 낮은 단계를 골라도 서버에는 다른 값이 전송될 수 있습니다.

코드 검색, 주요 패키지 목록 작성, 설정 파일 위치 확인, 변경 이력 요약은 입력과 출력의 경계가 비교적 분명합니다. 결과도 파일 경로, 함수 이름, 커밋 목록처럼 사람이 바로 대조할 수 있습니다. 이런 경우에는 low reasoning effort를 먼저 적용합니다.

다만 “검색은 항상 낮은 강도”라고 고정하면 안 됩니다. 저장소가 여러 언어로 구성되었거나, 문서와 실제 코드가 서로 다르거나, 호출 관계를 추적해야 한다면 작업은 단순 요약에서 구조 분석으로 바뀝니다. 다음 조건 중 하나라도 맞으면 높은 강도로 올립니다.

• 검색 결과가 서로 충돌합니다.
• 모델이 확인하지 않은 파일을 근거로 결론을 냅니다.
• 호출 관계와 설정값의 연결을 설명해야 합니다.
• 요약이 다음 수정 작업의 설계 문서로 사용됩니다.

저장소 선택과 권한 설정은 하네스의 작업 결과만큼 중요합니다. 공식 사용 안내도 작업 공간을 먼저 선택해야 세션 작성기가 활성화된다고 설명합니다. 원격 맥에서 실행한다면 작업 디렉터리, 승인 정책, 로그 보관 위치를 별도로 확인해야 합니다. (딥시크 하네스 빠른 시작 안내)

단일 파일에서 변수 이름을 바꾸거나 정해진 형식에 맞춰 반복 수정하는 작업은 낮은 강도로 시작할 수 있습니다. 이때 완료 조건은 “차이 파일이 예상 범위 안에 있고 관련 테스트가 통과하는가”로 정합니다.

반대로 공개 함수의 동작 변경, 자료 구조 변경, 인증 흐름 수정, 여러 패키지의 인터페이스 변경은 높은 강도가 적합합니다. 모델이 파일을 많이 읽었다는 이유만으로 높은 강도를 선택하는 것이 아니라, 한 파일의 변경이 다른 모듈에 미치는 영향을 추적해야 하기 때문입니다.

운영 기록에는 다음 항목을 남깁니다.

• 시작 강도와 실제 요청에 전달된 강도
• 변경된 파일 목록과 예상 밖의 파일
• 실행한 도구와 호출 순서
• 테스트 명령과 실패 내용
• 사람이 직접 되돌리거나 다시 작성한 부분

high reasoning effort를 적용했더라도 테스트가 없으면 결과 위험은 줄어들지 않습니다. 높은 강도는 검증을 대신하는 장치가 아니라, 복합적인 가설을 세우고 도구 결과를 연결할 기회를 늘리는 설정으로 다뤄야 합니다.

로그가 한 종류이고 재현 절차가 명확한 장애는 낮은 강도로 원인 후보를 정리할 수 있습니다. 그러나 로그 시간이 어긋나거나, 간헐적으로만 발생하거나, 네트워크와 권한과 자료 저장소가 함께 관여한다면 높은 강도를 유지합니다.

이런 작업에서는 모델이 첫 번째 원인을 찾았다는 이유로 종료하지 않도록 합니다. 최소한 다음 순서를 요구합니다.

1. 관찰된 사실과 추정을 분리합니다.
2. 서로 다른 원인 가설을 나열합니다.
3. 각 가설을 확인할 명령과 필요한 로그를 지정합니다.
4. 가장 값싼 검증부터 실행합니다.
5. 수정 뒤 재현 절차와 회귀 테스트를 다시 실행합니다.

코드 검토도 같은 원칙을 따릅니다. 형식, 반복 코드, 명백한 이름 오류는 낮은 강도로 처리할 수 있습니다. 보안 설정, 권한 상승, 자료 이전, 배포 환경 변수는 코드 양이 적어도 높은 강도와 사람 승인을 적용해야 합니다.

사람이 지켜보지 않는 반복 작업은 처음부터 높은 강도로 고정하기보다, 재실행 가능한 단계부터 낮은 강도로 시작하는 편이 운영 기록을 만들기 쉽습니다. 예를 들어 저장소 목록 수집, 변경 파일 추출, 테스트 결과 분류처럼 실패해도 원상 복구가 쉬운 단계가 먼저입니다.

다음 조건이면 해당 작업만 높은 강도로 전환합니다.

• 필수 파일이 누락되었습니다.
• 결과 형식이 규칙을 지키지 못했습니다.
• 테스트가 실패했지만 원인이 불명확합니다.
• 도구 호출이 중간에 멈췄습니다.
• 같은 작업을 다시 실행해도 결과가 달라집니다.

재시도, 강도 전환, 작업 중단은 모두 같은 실행 기록에 남겨야 합니다. 강도를 바꾸면 도구 호출이 반드시 달라진다고 볼 수는 없지만, 실제 호출 경로와 도구 결과를 저장해야 전환의 효과를 판단할 수 있습니다.

운영 팁: 중단 기준을 “오래 걸리면 중단”처럼 쓰지 말고, 결과 누락, 같은 명령 반복, 허용 범위를 벗어난 파일 수정처럼 관찰 가능한 조건으로 정의합니다.

팀마다 저장소와 테스트 체계가 다르므로 외부 벤치마크의 정확도나 처리 시간 수치를 그대로 가져오면 안 됩니다. 같은 모델, 같은 저장소, 같은 작업 설명, 같은 원격 맥 환경에서 낮은 단계와 높은 단계를 번갈아 실행해야 합니다.

기준 작업은 세 묶음으로 구성합니다.

• 단순 작업: 파일 검색, 요약, 이름 변경, 반복 형식 수정
• 복합 작업: 여러 모듈 수정, 테스트 실패 원인 추적, 인터페이스 변경
• 고위험 작업: 권한, 보안 설정, 자료 이전, 배포 구성 검토

각 작업에서 완료 여부만 보지 말고 다음 항목을 기록합니다.

• 올바른 파일을 찾았는가
• 도구 호출이 불필요하게 반복되지 않았는가
• 테스트가 통과했는가
• 사람이 수정한 줄과 파일은 얼마나 되는가
• 실패 뒤 재시도와 중단이 추적 가능한가

그 결과를 바탕으로 팀 정책을 다음처럼 고정할 수 있습니다.

• 단순 작업의 검증 통과율이 안정적이면 낮은 강도를 기본값으로 둡니다.
• 복합 작업에서 누락과 재작업이 반복되면 높은 강도로 승격합니다.
• 고위험 작업은 강도와 관계없이 사람 승인을 필수로 둡니다.
• 실패한 낮은 강도 작업은 같은 조건으로 무한 재시도하지 않고 높은 강도 또는 사람에게 넘깁니다.

비용을 세밀하게 관리하려면 [딥시크 하네스 토큰 운영 기준]을 함께 정리하고, 장시간 작업은 [원격 맥 용량 계획]에 맞춰 실행 공간을 분리하는 편이 좋습니다. 실제 시험을 원한다면 한국 원격 맥 환경에서 짧은 기준 작업부터 실행해 로그와 테스트 결과를 확보할 수 있습니다.

노트북에서 장시간 에이전트를 실행하면 화면을 닫거나 절전 상태로 전환할 때 작업이 끊길 수 있고, 여러 저장소를 동시에 돌릴 때 개발 환경과 백그라운드 환경이 충돌할 수 있습니다. 로컬 장비는 물리 장치 접근에는 유리하지만, 장시간 작업의 격리, 권한 분리, 실행 기록 보관에는 별도 운영이 필요합니다.

반면 원격 맥은 테스트용 작업 공간을 분리하고, 낮은 강도 작업과 높은 강도 작업을 같은 조건에서 반복하기 쉽습니다. 다만 장기적으로 계속 실행하는 고정 부하나 특정 물리 장치가 필요한 작업이라면 직접 보유한 맥이 더 적합할 수 있습니다. 임시 검증, 팀 기준 작업, 백그라운드 시범 운영이 목적이라면 JEXCLOUD의 원격 맥 환경 주문 페이지에서 격리된 시험 공간을 마련하는 방식이 현실적입니다. 장시간 작업 전에는 미국 동부 원격 맥 환경처럼 필요한 위치와 접속 조건을 먼저 확인하는 것이 좋습니다.

이번 주에는 작은 저장소 하나를 정해 낮은 강도와 높은 강도로 같은 검색, 수정, 장애 분석 작업을 각각 실행해 보시기 바랍니다. 로컬 환경이 장시간 점유된다면, 그다음에는 원격 맥에서 같은 기준 작업을 반복해 도구 호출과 재작업 기록까지 비교하는 순서가 안전합니다.