DeepSeek Harness에서 max-tokens 잘림이 발생했다고 바로 세션을 삭제하거나 반복 재시도하면 안 됩니다. 단일 응답의 표시 문제인지, 지속 상태 손상인지, 상위 모델 오류인지 분리한 뒤 원본 로그와 작업 공간을 보존하고 rc.7을 복제 환경에서 검증해야 합니다.
DeepSeek Harness에서 max-tokens 잘림이 발생했다고 바로 세션을 삭제하거나 반복 재시도하면 안 됩니다. 단일 응답의 표시 문제인지, 지속 상태 손상인지, 상위 모델 오류인지 분리한 뒤 원본 로그와 작업 공간을 보존하고 rc.7을 복제 환경에서 검증해야 합니다.
마지막 응답만 중간에서 끝났다면 먼저 짧은 무부하 요청으로 다음 턴을 확인하고, 같은 지점에서 계속 실패하면 원본 세션을 지우지 말고 복사본에서 복구를 검증해야 합니다. v0.1.0-rc.7은 max-tokens 잘림으로 세션이 이어지지 않는 문제를 수정했지만, 과거에 이미 손상된 모든 세션의 자동 복구까지 보장한다는 뜻은 아닙니다. (github.com)
이 글은 장기 대화나 코드 분석 중 출력이 멈춘 DeepSeek Harness 사용자, v0.1.0-rc.7을 원격 환경에 적용하려는 운영 담당자, 기존 세션을 살릴지 새로 만들지 판단해야 하는 Agent 개발자를 위한 글입니다.
먼저 확인할 기준: 화면에 답변 일부가 보인다는 사실만으로 세션이 정상이라고 판단하지 않습니다. 다음 요청이 기록되고 실행되는지까지 확인해야 합니다.
마지막 확인일은 2026년 8월 19일이며, 버전 정보와 복구 판단 기준은 2026년 8월 18일 기준 공식 릴리스와 구현 문서를 다시 확인했습니다.
max-tokens 잘림은 한 번의 모델 출력이 제한에 도달한 현상입니다. 반면 문맥이 너무 긴 문제는 요청에 포함되는 이전 기록 자체가 커져 입력 조립이나 제공자 제한에 걸리는 상황입니다. 둘은 화면에서 비슷하게 보일 수 있지만, 복구 방법은 다릅니다.
DeepSeek API의 다중 대화 방식은 서버가 대화 상태를 대신 보관하는 구조가 아니라 클라이언트가 이전 기록을 다시 보내는 방식입니다. 따라서 Harness의 세션 기록이 불완전하거나 재생되지 않으면 다음 요청도 실패할 수 있습니다. 공식 다중 대화 안내에도 같은 구조가 설명되어 있습니다. (api-docs.deepseek.com)
| 관찰되는 증상 | 우선 의심할 문제 | 즉시 할 일 | 중단 조건 |
|---|---|---|---|
| 답변만 중간에서 끝나고 입력은 가능함 | 단일 출력 잘림 | 짧은 무부하 요청 전송 | 짧은 요청도 실패하면 반복 전송 중지 |
| 같은 과거 위치에서 계속 실패함 | 역사 재생 또는 지속 상태 손상 | 로그 복사 후 실패 위치 비교 | 동일 위치에서 2회 이상 재현되면 격리 |
| 새 세션은 되지만 옛 세션만 열리지 않음 | 옛 상태 형식 또는 기록 손상 | 옛 세션 복사본을 새 환경에서 열기 | 원본 디렉터리 삭제 금지 |
| 모델을 바꿔도 같은 요청에서 실패함 | Harness 상태 또는 입력 조립 문제 | 모델보다 SessionEvent 흐름 확인 | 제공자 변경만 반복하지 않기 |
공식 구조 문서상 SessionEvent는 다시 불러올 수 있어야 하는 지속 사실이며, 세션 로그에서 모델에 보이는 기록이 재구성됩니다. 그러므로 화면에 남은 문장보다 assistant 기록, 도구 결과, 턴 종료 여부를 먼저 확인해야 합니다. 공식 구조 문서를 기준으로 보면 세션 로그는 문맥과 재생의 원천입니다. (github.com)
입력창이 정상이고 모델 선택이 유지되며 새 메시지가 전송된다면, 세션 전체가 손상된 것은 아닐 수 있습니다. 이때는 긴 작업을 바로 이어서 보내지 말고 부작용이 없는 짧은 요청을 사용합니다.
예를 들어 현재 작업을 수정하지 않는 확인 문장을 보냅니다.
현재 세션의 마지막 기록만 요약하고 파일이나 도구는 변경하지 마세요.
확인할 신호는 네 가지입니다.
assistant 응답 또는 명확한 오류 기록이 남는지 확인합니다.짧은 요청이 성공하면 원래 작업을 그대로 재전송하지 말고, 마지막으로 완료가 확인된 단계부터 이어갑니다. 반대로 짧은 요청까지 같은 방식으로 멈추면 단순한 화면 잘림으로 보지 않습니다.
계속 보내기를 누르면 호출 비용뿐 아니라 실패한 요청이 세션 기록에 중복될 수 있습니다. 특히 실패가 항상 같은 역사 위치, 같은 모델, 같은 도구 결과 직후에 발생한다면 상위 모델보다 재생 경로와 상태 복구를 먼저 의심해야 합니다.
다음 표처럼 실패의 위치를 고정해 비교합니다.
| 비교 항목 | 기록할 내용 | 판단에 주는 의미 |
|---|---|---|
| 역사 위치 | 마지막 정상 SessionEvent와 첫 실패 이벤트 |
특정 기록 재생 실패인지 확인 |
| 모델 조건 | 모델 이름, 추론 설정, 제공자 경로 | 모델 한정 오류인지 분리 |
| 도구 경계 | 마지막 도구 호출과 결과 수신 여부 | 도구 결과 뒤 상태가 끊겼는지 확인 |
| 버전 조건 | 업그레이드 전후 버전과 실행 방식 | rc.7 수정 효과를 격리 검증 |
공식 릴리스 기록은 max-tokens 잘림 뒤 세션 보존 수정과 대용량 역사 페이지 처리 수정을 명시합니다. 그러나 릴리스 설명에는 모든 기존 손상 상태를 자동으로 마이그레이션한다는 약속이 없습니다. 따라서 “rc.7로 올리면 무조건 살아난다”는 결론은 허용되지 않습니다. (github.com)
운영 중지 조건: 동일한 역사 위치에서 실패가 재현되거나, 도구 결과와 파일 상태가 일치하지 않으면 더 이상 원본 세션으로 실행하지 않습니다. 로그와 작업 공간을 먼저 복사합니다.
페이지 자체는 열리지만 옛 세션을 실행할 수 없다면 새 세션을 만들어 같은 환경에서 무부하 요청을 실행합니다. 새 세션이 정상이고 옛 세션만 실패한다면 네트워크나 모델 선택보다 지속 상태 또는 역사 호환성의 가능성이 커집니다.
이때 원본 세션 디렉터리를 삭제하지 않습니다. 복사본을 만들어 다음 순서로 시험합니다.
DeepSeek Harness는 개발자 미리보기 상태이며 호환성이 깨지는 변경이 있을 수 있다고 공식 저장소가 안내합니다. 따라서 기존 세션의 복구 시험은 운영 원본이 아니라 복제본에서 진행해야 합니다. 공식 사용자 안내도 실행 방식과 개발자 미리보기 상태를 확인하는 기준으로 사용할 수 있습니다. (github.com)
버전 업그레이드 전후에 아래 항목을 남기면 공식 수정이 실제 환경에서 효과가 있었는지 판단하기 쉽습니다.
| 검증 단계 | 성공으로 볼 수 있는 상태 | 실패로 볼 수 있는 상태 |
|---|---|---|
| 역사 열기 | 옛 기록이 중간 누락 없이 읽힘 | 특정 지점에서 화면 또는 재생이 멈춤 |
| 다음 입력 | 새 요청이 정상적으로 시작됨 | 입력이 사라지거나 같은 오류가 반복됨 |
| 도구 없는 응답 | 새 assistant 기록이 남음 |
응답 없이 턴만 닫히거나 재시도됨 |
| 작업 공간 확인 | 파일, 프로세스, 승인 상태가 기록과 일치함 | 모델 설명과 실제 상태가 다름 |
rc.7에서 옛 세션이 열리고 다음 요청도 실행되더라도, 마지막 작업의 결과를 자동으로 신뢰하지 않습니다. 마지막 파일 수정, 도구 출력, 승인 결정, 실행 중인 프로세스를 각각 확인해야 합니다. 기록은 이어지지만 작업 공간이 이미 달라졌다면 모델은 과거 상태를 전제로 잘못된 변경을 이어갈 수 있습니다.
다음 체크리스트를 모두 통과할 때만 옛 세션을 계속 사용합니다.
SessionEvent 기록을 읽을 수 있습니다.하나라도 통과하지 못하면 원본 로그를 보존하고 새 세션을 만듭니다. 새 세션에는 모델이 기억한다고 가정한 요약을 넣지 말고, 사람이 확인한 정보만 주입합니다.
목표:
확인된 완료 단계:
확인되지 않은 단계:
현재 저장소 상태:
마지막 파일 변경:
도구 결과와 승인 상태:
절대로 반복하지 않을 작업:
다음에 수행할 무부하 검증:
옛 세션을 삭제할 필요는 없습니다. 삭제하면 장애 원인, 복구 시도 전 상태, 공식 지원 요청에 필요한 재현 자료가 사라질 수 있습니다. 보관 공간이 문제라면 삭제 대신 읽기 전용 보관본을 만들고 접근 권한을 제한합니다.
장기 Agent 작업을 원격 맥에서 실행하면 화면 연결이 끊겨도 작업 공간과 로그를 분리해 보존하기 쉽습니다. 다만 원격 환경은 자동으로 복구를 보장하지 않습니다. 세션 로그, 작업 디렉터리, 인증 정보, 실행 프로세스의 보관 위치를 운영자가 직접 정해야 합니다.
단기 검증이나 rc.7 회귀 시험이라면 원격 맥 대여 환경처럼 별도 작업 공간을 마련하는 편이 현재 개발 맥을 오염시키지 않습니다. 지역 지연이 중요하면 한국 원격 맥 환경을 비교하고, 여러 지역에서 재현해야 한다면 작업 조건을 고정한 뒤 같은 로그 수집 방식을 적용합니다.
현재 환경을 그대로 쓰는 방식은 빠르지만, 원본 세션과 시험 세션이 섞이고 업그레이드 전후 비교가 어려워집니다. 공용 서버는 비용과 접근성이 좋을 수 있지만 권한, 백업 주기, 프로세스 종료 정책을 직접 관리해야 합니다. VNCMac의 맥 환경을 임시 검증에 사용하는 방식은 장비를 새로 구입하지 않고 격리된 실행 공간을 확보할 수 있지만, 물리 인터페이스가 필요하거나 장기간 고정 부하를 계속 실행하는 경우에는 자체 장비가 더 적합할 수 있습니다.
복구 결론은 간단합니다. 원본 세션과 작업 공간을 먼저 보존하고, 복사본에서 rc.7을 검증합니다. 역사 읽기, 다음 턴 실행, 작업 공간 일치, 증거 보존을 모두 확인하지 못하면 옛 세션을 억지로 살리지 말고 검증된 요약으로 새 세션을 시작하는 편이 안전합니다. 이후 장기 실행을 계속할 예정이라면 원격 맥의 백업과 복구 승인 절차까지 함께 설계해야 합니다.