화면에는 실행 중이라고 나오지만 새 요청이나 결과가 보이지 않습니다.
가장 빠른 해결법은 재시도 예약과 다음 요청 시작 기록을 먼저 확인하고, 증거가 없거나 대기 시간이 통제되지 않으면 작업을 중지해 현장을 보존하는 것입니다.
이 글은 다음 사용자를 위한 점검 절차입니다.
- 로컬 사용자: 작업이 계속 기다리는 이유를 모르는 경우
- 원격 에이전트 운영자: 무인 백그라운드 작업의 중지와 복구 기준이 필요한 경우
- 플랫폼 엔지니어: 재시도 로그, 제한 시간, 상위 API 상태를 함께 진단해야 하는 경우
첫 번째 확인: 로딩 화면이 아니라 진행 증거를 찾습니다
실패 사례를 하나 가정해 보겠습니다. 웹 화면에는 “실행 중”이 계속 표시되지만 새 요청 기록은 없고, 세션 이벤트도 추가되지 않습니다. 이때 로딩 애니메이션만 보고 기다리면 원인 파악이 늦어집니다.
먼저 다음 항목을 같은 시각 기준으로 확인합니다.
- 세션에 새 이벤트가 기록됐는지
- 모델 요청 시작과 종료 기록이 있는지
- 토큰 사용량이나 스트림 데이터가 증가하는지
- 도구 승인 대기 상태인지
- 셸, 훅, 외부 도구 프로세스가 살아 있는지
- 원격 컴퓨터의 작업 폴더와 실행 프로세스가 유지되는지
공식 딥시크 API는 비스트리밍 요청에서도 응답 전 빈 줄을 보낼 수 있고, 스트리밍 요청에서는 연결 유지용 주석을 보낼 수 있습니다. 따라서 연결이 열려 있다는 사실만으로 모델이 계속 추론하고 있다고 단정하면 안 됩니다. 반대로 원격 연결이 잠시 끊겼다고 해서 프로세스가 반드시 종료됐다고 볼 수도 없습니다. 공식 연결 유지와 제한 시간 안내를 함께 확인해야 합니다. (api-docs.deepseek.com)
관찰 신호와 판단
| 관찰 신호 | 우선 의심할 위치 | 다음 확인 |
|---|---|---|
| 새 요청 시작 기록이 없음 | 재시도 대기, 프로세스 중단 | 예약 기록과 프로세스 상태 확인 |
| 요청은 시작되지만 같은 오류 반복 | 모델 경로, 인증, 기본 주소 | 현재 제공자 설정과 최소 요청 확인 |
| 모델 응답 뒤 도구 이벤트가 없음 | 승인, 훅, 셸, 외부 도구 | 도구별 실행 로그와 반환 상태 확인 |
| 연결은 끊겼지만 프로세스가 살아 있음 | 네트워크 또는 세션 단절 | 현장 보존 후 재접속 가능성 확인 |
재시도 기록이 보이지 않는다면 도구나 승인 단계에서 멈췄을 수 있습니다. 이 경우 모델 재시도 문제로 분류하지 말고 도구 실행 경로로 이동합니다.
두 번째 확인: 예약된 재시도와 시작된 재시도를 짝으로 봅니다
재시도 흐름에서는 “다시 시도할 예정”이라는 기록과 “다음 요청을 실제로 시작했다”는 기록을 분리해 봐야 합니다. 예약만 있고 시작 기록이 없다면 다음 단계가 취소됐거나 실행 프로세스가 중단됐을 가능성이 있습니다.
현재 사용 중인 하니스의 저장 이벤트와 실행 로그에서 다음 순서를 찾습니다.
- 최초 요청 실패
- 재시도 예약 기록
- 대기 또는 취소 상태
- 다음 요청 시작
- 다음 응답 종료 또는 다음 실패
이 다섯 단계가 모두 이어지지 않으면 무한 대기를 정상적인 엘엘엠 재시도로 해석하지 않는 편이 안전합니다. 공식 문서와 현재 패키지의 저장 형식이 다를 수 있으므로 이벤트 이름은 고정해서 외우지 말고, 설치된 버전의 기록 정의와 최신 릴리스를 대조해야 합니다. 하니스의 저장 이벤트 규칙도 확인 대상에 포함할 수 있습니다. (github.com)
다음 조건이면 현장을 먼저 저장합니다.
- 재시도 예약 뒤 다음 요청 시작 기록이 없음
- 오류가 발생한 뒤 프로세스의 표준 출력과 오류 출력이 끊김
- 작업 폴더가 사라졌거나 다른 경로로 바뀜
- 원격 접속은 끊겼지만 프로세스 상태를 확인하지 못함
- 대기 시간이 운영자가 정한 범위를 넘어섬
저장할 항목은 하니스 버전, 세션 식별자, 마지막 이벤트, 오류 전문, 모델 이름, 제공자 설정, 기본 주소, 작업 폴더, 프로세스 상태입니다. 화면을 새로 고치는 행동은 이 자료를 대신하지 못합니다.
세 번째 확인: 같은 모델 오류가 반복되면 재시도 횟수를 늘리지 않습니다
같은 오류가 매번 같은 위치에서 반환되면 일시적인 장애보다 설정 오류일 가능성이 높습니다. 특히 다음 항목을 순서대로 확인합니다.
- 모델 이름이 현재 제공되는 목록에 있는지
- 인증 키가 올바른 환경 변수에 들어 있는지
- 기본 주소가 공식 주소와 일치하는지
- 현재 제공자 설정이 선택한 연결 방식과 맞는지
- 일반 주소와 실험용 주소를 혼용하지 않았는지
- 사고 과정 응답과 도구 호출에 필요한 대화 기록을 보존하는지
공식 모델 목록은 현재 사용 가능한 모델 식별자를 API로 확인하도록 안내합니다. 이름을 직접 추정하지 말고 /models 응답과 설정 파일을 비교해야 합니다. 공식 모델 목록 응답을 기준으로 점검하십시오. (api-docs.deepseek.com)
딥시크 API의 기본 주소와 모델 설정은 공식 첫 호출 예제에 제시된 값과 대조할 수 있습니다. 구형 모델 이름은 공식 변경 기록에서 사용 중단 일정이 안내된 적이 있으므로, 오래된 설정을 그대로 재시도하는 방식은 피해야 합니다. 공식 첫 호출 예제와 공식 변경 기록을 함께 확인하십시오. (api-docs.deepseek.com)
수정 후에는 긴 대화나 도구를 넣지 않습니다. 짧은 텍스트 한 줄로 모델 연결을 시험합니다.
- 새 세션을 만듭니다.
- 최소 메시지를 보냅니다.
- 스트리밍을 끄고 응답 본문과 종료 상태를 확인합니다.
- 성공하면 도구를 하나만 추가합니다.
- 다시 성공한 뒤 원래 작업을 복구합니다.
오류가 인증, 모델 이름, 기본 주소처럼 결정적인 문제라면 자동 재시도는 비용과 대기만 늘립니다.
네 번째 확인: 모델 응답과 에이전트 완료를 분리합니다
모델이 응답을 반환했다고 해서 전체 작업이 끝난 것은 아닙니다. 에이전트는 모델 호출 뒤 승인, 훅, 셸, 파일 처리, 외부 도구 호출을 이어 갈 수 있습니다.
| 모델 단계 | 도구 단계 | 해석 |
|---|---|---|
| 응답 없음 | 실행 기록 없음 | 모델 경로, 네트워크, 인증부터 확인 |
| 응답 성공 | 승인 대기 | 재시도가 아니라 권한 흐름 점검 |
| 응답 성공 | 셸이 종료되지 않음 | 명령어, 작업 폴더, 외부 프로세스 점검 |
| 도구 종료 | 결과 반환 없음 | 결과 전달과 세션 저장 단계 점검 |
도구 문제를 모델 재시도로 분류하면 같은 요청을 불필요하게 다시 보낼 수 있습니다. 모든 권한을 한꺼번에 열어 시험하는 것도 좋지 않습니다. 승인 범위와 명령을 최소화하고, 가장 작은 도구 호출이 결과를 반환하는지 확인해야 합니다.
복구 기준은 간단합니다. 최소 도구 호출이 정상 종료되고, 반환 결과가 세션에 기록되며, 다음 에이전트 단계가 시작되어야 합니다. 셸이 계속 살아 있거나 승인 이벤트가 누락되면 본 작업을 다시 시작하지 말고 해당 도구 단계에서 멈춥니다.
자주 헷갈리는 재시도 판단
메타데이터의 질문들은 실제 운영 중 자주 발생하는 판단 지점을 기준으로 정리했습니다. 모델 오류인지 백그라운드 작업 문제인지 먼저 가르는 것이 핵심입니다.
다섯 번째 확인: 원격 환경의 정체성이 유지되는지 검사합니다
원격 맥에서 반복 실패가 발생하면 네트워크만 보지 말고 실행 환경도 확인해야 합니다. 다음 변화는 이전 작업을 그대로 이어 가기 어렵게 만듭니다.
- 시스템이 잠자기나 재시작을 거침
- 작업 폴더가 임시 경로에서 다른 경로로 변경됨
- 실행 사용자가 달라짐
- 환경 변수가 사라짐
- 셸 프로세스와 하위 프로세스가 분리됨
- 네트워크 출구나 보안 정책이 바뀜
환경이 동일하고 프로세스가 살아 있다면 현장을 보존한 뒤 연결 복구를 시도할 수 있습니다. 환경의 정체성이 바뀌었다면 새 검증 작업을 만드는 편이 안전합니다. 이전 세션을 강제로 이어 가면 파일 상태와 대화 상태가 서로 어긋날 수 있습니다.
원격 장시간 작업을 운영한다면 딥시크 하니스 백그라운드 작업 검수와 같은 인수 절차를 별도로 마련해야 합니다. 작업이 끝났다는 표시보다 파일 변경, 종료 상태, 결과 저장 여부를 확인해야 합니다. 원격 맥 환경 자체가 의심되면 맥 미니 원격 환경 주문 안내에서 새 검증 환경을 분리하는 방법도 검토할 수 있습니다.
중지·복구·이관을 결정하는 체크리스트
- [ ] 마지막 모델 요청의 시작과 종료 기록을 분리해 확인했습니다.
- [ ] 재시도 예약 기록 뒤 실제 다음 요청 시작 기록을 찾았습니다.
- [ ] 같은 오류가 설정 변경 없이 반복되는지 확인했습니다.
- [ ] 모델 이름과 기본 주소를 현재 공식 문서와 대조했습니다.
- [ ] 인증 키가 현재 실행 프로세스에 전달됐는지 확인했습니다.
- [ ] 승인, 훅, 셸, 외부 도구 중 하나가 대기 중인지 확인했습니다.
- [ ] 원격 프로세스와 작업 폴더가 그대로 유지되는지 확인했습니다.
- [ ] 중지 전 로그, 세션, 오류 전문, 환경 정보를 저장했습니다.
- [ ] 최소 텍스트 요청이 성공한 뒤 최소 도구 호출도 성공했습니다.
- [ ] 환경이 바뀌었다면 이전 작업을 억지로 재개하지 않았습니다.
판단은 세 갈래로 나눕니다.
계속 기다림은 새 요청 시작이나 도구 진행 같은 증거가 있고, 오류가 일시적이며, 대기 상한을 정한 경우에만 선택합니다.
취소 후 재실행은 진행 증거가 끊겼지만 환경과 작업 폴더를 보존했고, 최소 요청으로 연결을 다시 검증한 경우에 적합합니다.
환경 이관은 인증과 모델 설정이 맞는데도 원격 프로세스가 사라졌거나, 작업 폴더와 실행 주체가 바뀌었거나, 같은 환경 문제를 반복 재현하는 경우에 선택합니다.
현재 로컬 장비나 기존 원격 환경에서만 문제가 반복된다면, 원인은 모델 자체가 아니라 절전, 세션 단절, 권한 전달, 작업 폴더 변경일 수 있습니다. 이런 환경은 장시간 백그라운드 작업에서 복구 지점이 약하고, 장애 현장을 보존하기도 어렵습니다. 반면 MACCOME의 맥 환경을 임시 검증용으로 사용하면 새 세션과 작업 폴더를 분리해 모델 연결, 도구 실행, 원격 복구를 단계별로 확인할 수 있습니다. 장기 고정 부하나 물리 장치 접근이 필요하다면 직접 장비를 운영하는 편이 낫지만, 반복 재시도 원인을 분리해야 하는 테스트와 단기 작업이라면 환경을 바꾸는 것이 무작정 재시도하는 것보다 빠른 선택이 될 수 있습니다.