DeepSeek super agent 문제는 마지막으로 작동한 경계부터 찾아야 한다

DeepSeek super agent가 응답하지 않거나 같은 작업을 반복하고, 예상하지 못한 작업자를 실행하거나 쓸모 있는 결과를 내지 못할 때는 시스템을 통째로 다시 설치하기보다 마지막으로 정상 작동한 단계와 처음 실패한 단계를 찾아야 한다. 이 안내서는 이벤트 수신, 작업 승인, 작업자 실행, 응답 전달을 구분해 문제를 좁히는 진단 방법을 제시한다.

프로토타입은 외부 이벤트 소스, 라우터, 작업 기록, 작업자 세션, 로컬 작업 공간, 외부 응답 전달로 구성된다. 이벤트가 도착한 것과 작업이 승인된 것, 작업자가 완료된 것, 응답이 전달된 것은 각각 별개의 상태다. 진단 기록에서도 이를 구분해야 한다.

이 자료는 모든 릴리스에서 확인된 버그 목록이 아니다. 설치 환경을 직접 실행해 확인한 내용도 아니다. 정확한 설정 이름과 경로, 명령어, 지원 동작은 고정한 버전의 업스트림 저장소에서 확인해야 한다. 소스와 튜토리얼의 설명이 다르면, 작동 중인 인프라를 바꾸기 전에 소스를 살펴본다.

시작 단계에서는 가장 먼저 나온 의미 있는 오류를 확인한다. 긴 스택 추적에는 첫 번째 누락 의존성이나 잘못된 설정에서 파생된 오류가 뒤섞일 수 있다. 실행 명령, 작업 디렉터리, 런타임 버전, 소스 리비전, 최초 오류 메시지를 기록한다. 환경 전체를 공개 이슈에 붙여 넣으면 관련 없는 자격 증명이 노출될 수 있으므로 피한다.

현재 구현이 요구하는 런타임과 의존성을 확인한다. 문서에 적힌 Node 버전과 SQLite 지원 여부를 살펴보고, 설치 때 사용한 런타임과 애플리케이션을 실행하는 런타임이 같은지도 점검한다. 서비스 관리자와 대화형 터미널은 실행 파일 경로나 환경 변수가 다를 수 있다. 전용 OS 사용자가 설정을 읽고 지정된 상태 디렉터리에 쓸 수 있는지도 확인한다. 권한 문제는 전체 프로세스의 권한을 높이는 대신 필요한 디렉터리에서 해결한다.

GitHub 활동이 감지되지 않는다면 프로세스 자체가 아니라 연동 계정이 잘못됐을 수 있다. 연동에 실제로 사용되는 계정과 해당 계정의 저장소 접근 권한, 인증 방식을 확인한다. 프로토타입은 GitHub App이 아니라 전용 사용자 계정을 문서화하므로, 다른 제품에서 작동하는 자격 증명이 이 흐름에도 적합하다고 단정할 수 없다.

저장소를 읽을 수 있는 것과 관련 알림이나 이벤트가 연동에 도착하는 것은 다르다. 업스트림에 설명된 이벤트 전달 방식과 원본 대화를 확인하고, 로그에서 알아볼 수 있는 통제된 테스트 신호 하나를 사용한다. 비슷한 댓글을 여러 개 보내면 문제가 해결된 뒤 여러 작업이 생길 수 있어 진단이 어려워진다. 잘못된 저장소의 활동을 감지한다면 설정의 소유자와 저장소 이름, 실행 프로세스가 사용하는 환경을 확인한다. 설정 파일을 수정해도 프로세스가 자동으로 다시 읽는다고 가정하지 않는다.

이벤트가 수신됐는데 작업이 시작되지 않았다면 해당 이벤트의 승인 여부를 먼저 확인한다. 발신자, 저장소 범위, 대화 맥락, 정책에 따라 이벤트가 거부될 수 있다. 작업자가 나타나지 않았다는 이유만으로 실행 실패라고 결론 내리지 말고, 이벤트와 작업 승인 결정을 연결하는 기록을 찾는다. 사람에게는 흥미로운 일반 대화라도 에이전트에 대한 직접 명령은 아닐 수 있다. 반대로 권한이 있는 사람의 명확한 요청은 추론 모드와 별도의 경로로 처리될 수 있다.

대화에 표시된 이름과 설정에서 사용하는 계정 식별자가 다를 수 있으므로 승인된 신원 매핑을 확인한다. 에이전트 자신의 계정과 요청한 사람의 계정도 구분한다. 권한을 바꿔야 한다면 필요한 범위만 수정하고 통제된 테스트를 반복한다. 작업이 시작되는지 확인하려고 모든 참여자에게 광범위한 접근을 부여해서는 안 된다.

공개된 설계에서 off, observe, auto는 추론된 작업의 승인을 설명한다. 모든 명시적 요청을 일괄 차단하는 모드는 아니다. 따라서 권한이 있는 사람이 off나 observe 상태에서 직접 작업을 요청했을 때 작업자가 실행됐다는 사실만으로 모드가 고장 났다고 볼 수 없다. 추론된 기회와 직접 요청을 따로 시험하고, 이벤트가 처리된 시점의 설정값과 승인 경로를 기록한다.

모든 실행 경로를 멈추려면 적절한 프로세스 및 접근 제어를 사용해야 한다. 추론 모드를 긴급 정지 장치로 의존하지 않는다. 새 작업의 승인을 막는 것과 이미 실행 중인 작업자를 멈추는 것도 다를 수 있다. 운영을 재개하기 전에 활성 상태를 확인해 기존 작업을 새 요청으로 오인하지 않도록 한다.

작업자가 멈춘 것처럼 보이면 마지막으로 확인된 동작을 살핀다. 모델 응답, 도구, 하위 프로세스, 파일 시스템 작업 또는 다른 의존성을 기다리는 중인지, 진행 중인지, 실패했는지 확인한다. 새 텍스트가 없다는 이유만으로 애플리케이션 전체를 종료하고 다시 시작해야 한다고 판단할 수는 없다. 모델 접근 문제와 저장소 접근 문제도 따로 조사한다. 엔드포인트, 자격 증명, 할당량, 오류 응답을 비밀 정보 노출 없이 확인한다. 제공자 오류가 반드시 라우팅 오류인 것은 아니며, 저장소 의존성이 없어 명령이 실패했다면 이벤트 연동이 아니라 작업자 작업 공간을 살펴본다.

작업을 재시도하기 전에는 파일 변경이나 외부 작업이 이미 발생했는지 확인한다. 원래 지시를 반복하면 부수 효과도 되풀이될 수 있다. 상황을 파악할 때까지 작업 기록과 작업 공간을 보존한 뒤 기존 작업을 이어갈지, 범위를 제한한 새 작업을 만들지, 일회성 평가 환경을 기준 상태로 복원할지 결정한다.

완료된 작업도 승인 기준을 충족하지 못할 수 있다. 결과물을 원래 요청, 저장소 맥락, 작업자에게 전달된 제약과 비교한다. 요청이 모호했는지, 예상한 체크아웃에서 작업했는지, 의도한 범위 밖의 파일을 수정했는지 구분한다. 요약에서 검사를 통과했다고 했다면 실제로 어떤 검사를 실행했고 무엇을 확인했는지 살펴본다. 일시적 오류 뒤의 좁은 재시도는 전체 검증과 같지 않다. 텍스트 수정에는 명확한 변경 내역만으로 충분할 수 있지만, 동작을 바꿨다면 그 동작에 맞는 검증이 필요하다.

다음 요청에는 범용 지침을 길게 덧붙이기보다 결과물과 승인 기준을 명확히 적는다. 지정 파일, 원하는 동작, 검토 조건을 포함하면 결과를 평가하기 쉽다. 실패 사례도 평가 기록에 남긴다. 성공적인 데모만으로는 드러나지 않는 운영 요구사항을 보여줄 수 있기 때문이다.

응답이 없을 때는 요청이 무시됐다고 단정하기 전에 작업 상태와 결과물을 확인한다. 작업은 끝났지만 외부 응답 전달만 실패했을 수 있다. 목적지 대화, 계정 권한, 채널별 전달 오류를 차례로 점검한다. 중복 작업은 별도로 조사해야 한다. 원본 이벤트와 작업 식별자를 비교해 여러 요청이 제출됐는지, 하나의 이벤트가 여러 번 처리됐는지, 관련 대화가 새 작업으로 해석됐는지 구분한다. 로그나 상태를 성급히 지우면 이 차이를 판별할 증거가 사라질 수 있다.

선택 사항인 Feishu 연동에는 별도의 신원 확인과 전달 경계가 있다. GitHub에서 응답이 왔다고 해서 Feishu 자격 증명, 이벤트 처리, 대화 권한도 정상이라고 볼 수 없다. 각 채널에서 최소한의 요청으로 시험하고 응답이 어디에 나타나는지 기록한다.

패널, 작업 기록, 파일 시스템의 상태가 서로 맞지 않아 보이면 변경하기 전에 각 관찰 내용을 기록한다. 활성 프로세스와 사용 중인 디렉터리를 확인한다. 작업 디렉터리나 설정이 다른 프로세스 두 개가 실행되면 특정 기록이 손상되지 않았더라도 상태가 혼란스러워질 수 있다. 데이터베이스 삭제를 첫 번째 해결책으로 삼지 않는다. 초기화는 요청과 작업의 연결을 지우면서 외부 변경은 남길 수 있다. 관련 상태를 보호된 위치에 백업하고, 구현에 기록된 복구 절차와 보존할 항목을 검토한다.

업그레이드할 때는 이전 리비전과 현재 리비전을 비교하고 영속성 관련 변경을 확인한다. 이전 코드로 되돌려도 새 데이터의 의미까지 원래대로 복구된다고 보장할 수 없다. 업그레이드 전에 복구 계획을 세운다. 지원되는 마이그레이션 경로가 문서화되지 않았다면 그 불확실성도 프로토타입 평가에 반영한다.

공개 이슈에는 기대 동작과 실제 동작, 최소 재현 절차, 소스 리비전, 관련 환경 정보를 적는다. 마지막으로 성공한 단계와 처음 실패한 단계를 밝히면 유지보수자가 이벤트 수신, 정책, 실행, 상태, 전달 중 어디부터 살필지 판단하는 데 도움이 된다. 자격 증명, 비공개 저장소 내용, 개인 정보, 관련 없는 로그는 공개 전에 가린다. 민감한 이름을 바꿀 때는 행위자 사이의 관계를 알아볼 수 있도록 일관되게 바꾸고, 재현 여부와 재시작 또는 설정 변경의 영향을 함께 적는다.

관찰한 사실과 가정도 구분한다. “작업자 로그에 이 오류가 있다”는 말은 “모델이 고장 났다”는 판단보다 근거가 분명하다. observe 모드에서 직접 요청이 실행됐다는 기록은 예상된 동작일 수도 있다. 생명주기는 아키텍처 안내서에서, 통제된 평가 절차를 다시 구성하는 방법은 설정 안내서에서 확인할 수 있다.