2026년 딥시크 하네스 이미지 첨부 검수법

2026년 8월 17일 공개된 v0.1.0-rc.7 릴리스에는 MCP와 ACP의 영속 이미지 첨부, PTC Mode의 중첩 이미지 전달이 새 기능으로 기록되어 있습니다. 다만 이 기능은 모든 모델이 이미지를 이해한다는 뜻이 아닙니다. 공식 저장소도 현재 개발자 미리보기 단계이며 호환성이 깨지는 변경이 있을 수 있다고 안내합니다. 공식 릴리스 기록에서 기능 추가와 버전별 변경 사항을 먼저 확인해야 합니다.

먼저 아래 세 가지를 분리합니다.

1. 화면이 파일을 선택했는가
2. 요청 본문에 첨부 참조가 들어갔는가
3. 선택된 모델 또는 상위 제공자가 실제로 이미지 입력을 처리했는가

세 단계 중 하나라도 증거가 없으면 결과는 통과가 아니라 제한입니다. 특히 사용자 지정 제공자의 설정에 이미지 입력을 켜도, 상위 엔드포인트가 텍스트만 받으면 모델 응답은 이미지 내용을 읽을 수 없습니다. 모델 이름에 vision이 들어가는지로 판단하지 않습니다.

현재 공식 API 문서와 모델 입력 정보를 확인할 때도 모델별 입력 능력 선언을 먼저 기록해야 합니다. DeepSeek의 공식 대화 완성 API 문서는 요청 메시지의 입력 형식과 응답 구조를 설명하지만, 특정 모델이 이미지 입력을 처리한다는 사실까지 자동으로 보장하지 않습니다. 현재 공식 문서상 DeepSeek 자체 대화 완성 경로는 텍스트 입력 중심으로 설명되므로, 이미지 작업에는 별도 이미지 지원 제공자나 이미지 처리가 가능한 비전 모델이 필요한지 먼저 확인합니다.

딥시크 하네스가 이미지 전송을 거부하는 상황은 어떻게 찾습니까?

화면에서 첨부 버튼이 사라졌는지, 모델 설정에서 이미지 입력이 거짓으로 선언되었는지, 요청 직전 검증에서 차단되었는지를 순서대로 봅니다. 기록할 증거는 설정 화면, 모델 능력 선언, 전송 직전 로그, 상위 응답의 오류 내용입니다. 업로드 아이콘만 남아 있고 요청 로그에 첨부가 없다면 모델 문제가 아니라 사용자 인터페이스 또는 연결 계층 문제일 수 있습니다.

이미지 첨부 검수의 첫 관문은 파일이 아니라 모델입니다. 다음 항목을 같은 검수 기록에 남깁니다.

• 선택한 모델 이름과 제공자 이름
• 이미지 입력 지원 여부를 나타내는 설정 값
• 실제 요청 형식과 첨부 필드
• 상위 엔드포인트의 성공 또는 거부 응답
• 이미지 내용을 특정하는 질문에 대한 답변

테스트 이미지는 단순한 풍경보다 식별 정보가 있는 자료가 좋습니다. 예를 들어 서로 다른 색의 도형 3개, 짧은 표, 고유한 단어 1개를 넣습니다. 실제 고객 화면이나 비밀 키는 사용하지 않습니다. 모델에 왼쪽 도형의 색과 표의 두 번째 행 내용을 말하라고 요청합니다. 답변이 이미지를 볼 수 없다는 내용이거나 일반적인 문장만 반복하면 이미지 입력 성공으로 기록하지 않습니다.

비전 모델을 연결했더라도 첨부가 모델 본문이 아니라 도구 입력으로만 전달될 수 있습니다. 이 경우 모델이 원본을 직접 읽은 것인지, MCP 도구가 이미지를 분석해 텍스트로 바꾼 것인지 구분해야 합니다. 두 결과는 운영 책임과 장애 지점이 다릅니다.

MCP와 ACP는 연결 방식이 다르므로 하나가 성공했다고 다른 하나까지 통과 처리하지 않습니다. MCP는 외부 도구 호출과 자료 전달 경계를 확인하고, ACP는 편집기나 외부 호스트가 세션을 열고 프롬프트를 전달하는 경계를 확인합니다.

MCP 공식 사양은 서버와 클라이언트 사이의 기능 협상, 자원 전달, 도구 결과를 별도 요소로 정의합니다. 따라서 이미지가 어느 계층에서 첨부되었는지 로그에 남겨야 합니다. MCP 기본 사양은 자원과 도구의 책임 범위를 구분하고, MCP 샘플링 사양은 이미지 입력이 별도 이미지 내용으로 전달될 수 있음을 설명합니다.

공식 릴리스는 두 경로에 영속 이미지 첨부를 추가했다고 명시하지만, 실제 사용 중인 제공자와 호스트의 능력 협상은 별도로 확인해야 합니다. 배포 버전에서 같은 결과가 나오는지 반드시 시험합니다.

두 번째 단계: 식별 가능한 이미지로 전송 확인

1. 테스트 이미지에 고유한 표식 2개를 넣습니다.
2. 같은 요청에 이미지 순서와 질문 순서를 명시합니다.
3. MCP 경로에서 도구 입력 기록을 저장합니다.
4. ACP 경로에서 초기화 응답과 프롬프트 전달 기록을 저장합니다.
5. 모델의 답변이 첫 번째 이미지와 두 번째 이미지를 올바르게 구분하는지 확인합니다.
6. 화면 미리 보기와 실제 수신 결과를 대조합니다.

이미지 2장을 붙였는데 모델이 한 장의 특징만 답하면 순서 보존 실패일 수 있습니다. 파일 이름만 전달되고 실제 바이너리 또는 읽을 수 있는 자산이 전달되지 않은 경우도 있습니다. 경로 문자열이 보인다는 이유로 전송 성공으로 판단하지 않습니다.

MCP와 ACP의 이미지 첨부는 새로 고침 뒤에도 남습니까?

영속성은 세 층으로 나누어 확인합니다.

• 화면 캐시: 현재 창에서만 미리 보기가 남는 상태
• 세션 기록: 대화에는 첨부 항목이 보이지만 실제 파일을 다시 읽을 수 없는 상태
• 첨부 자산: 세션을 다시 열어도 모델이나 도구가 실제 이미지에 접근할 수 있는 상태

새로 고침, 클라이언트 재연결, 프로세스 재시작을 각각 실행합니다. 각 단계 뒤에 같은 이미지의 고유 표식을 다시 질문합니다. 세션 기록에 파일 이름이 남아 있어도 자산이 삭제되었으면 통과가 아닙니다.

MCP의 전송 방식도 확인 대상입니다. MCP 전송 사양은 표준 입출력과 스트리밍 방식의 메시지 경계를 설명합니다. 이미지 참조가 어느 전송 구간에서 사라졌는지 찾으려면 요청 생성 시점, 전송 직전, 서버 수신 시점의 기록을 나누어 저장해야 합니다.

이미지 첨부는 대화 텍스트보다 저장 책임이 복잡합니다. 세션 파일, 첨부 파일, 접근 권한, 작업 디렉터리, 원격 연결이 서로 다른 위치에 있을 수 있습니다.

다음 체크리스트를 한 항목씩 실행합니다.

• [ ] 첨부 직후 세션 식별자와 첨부 식별자를 기록합니다.
• [ ] 화면을 새로 고친 뒤 같은 첨부가 다시 선택되는지 확인합니다.
• [ ] 클라이언트를 종료하고 다시 연결합니다.
• [ ] 하네스 프로세스를 재시작합니다.
• [ ] 기존 세션을 복구하고 이미지의 고유 표식을 질문합니다.
• [ ] 세션 기록과 실제 첨부 자산의 위치를 각각 확인합니다.
• [ ] 읽기 권한이 없는 계정으로 같은 세션을 열어 봅니다.
• [ ] 첨부를 삭제한 뒤 모델이 이전 이미지를 계속 읽는지 확인합니다.

복구 후 같은 요청이 반복 전송되면 중복 비용뿐 아니라 작업 반복과 무한 실패가 발생할 수 있습니다. 특히 상위 모델이 이미지를 거부했는데 복구 로직이 이전 요청 전체를 다시 재생하면, 실패가 세션 복구 문제인지 모델 입력 문제인지 구분하기 어려워집니다.

안전한 회복 동작은 세 가지입니다. 첨부 없는 새 요청으로 전환하고, 이미지 입력을 지원하는 모델로 바꾸거나, 이미지의 핵심 내용을 사람이 검증한 텍스트 증거로 바꾸는 것입니다. 원인 확인 전 자동 재시도를 무제한으로 두지 않습니다.

PTC Mode의 주 작업과 자식 작업에 서로 다른 이미지를 요구하는 테스트를 만듭니다. 주 작업에는 화면 전체를, 자식 작업에는 오른쪽 아래의 작은 표식만 확인하도록 지시합니다. 두 이미지의 표식을 다르게 해야 합니다.

검수 증거는 세 묶음으로 수집합니다.

1. 주 작업이 어떤 첨부를 보유했는지 보여 주는 작업 궤적
2. 자식 작업이 실제로 받은 이미지와 답변
3. 실패 시 어느 계층에서 첨부가 끊겼는지 보여 주는 오류 기록

자식 작업이 주 작업의 설명만 받고 원본 이미지를 받지 못했다면, 텍스트 문맥 전달은 성공했지만 이미지 중첩 전달은 실패한 것입니다. 반대로 자식 작업이 이미지를 받았지만 다른 파일을 받았다면 순서 또는 참조 연결 문제입니다.

공식 rc.7 기록은 PTC Mode의 중첩 이미지 전달을 지원한다고 밝힙니다. 그러나 지원 표시는 배포 버전의 기능 존재를 뜻할 뿐, 현재 사용자 지정 제공자와 외부 호스트까지 자동으로 보장하지는 않습니다. 따라서 주 작업과 자식 작업의 수신 결과를 모두 남겨야 합니다. 검수 기록에는 사용한 버전과 제공자 조합도 함께 적습니다.

PTC Mode의 중첩 작업이 원본 이미지를 받았는지 어떻게 확인합니까?

자식 작업에 원본 파일 이름을 묻지 않습니다. 파일 이름은 전달되었지만 내용이 비어 있을 수 있습니다. 대신 원본에만 있는 표식, 특정 위치의 색, 표 안의 단어처럼 내용 기반 질문을 사용합니다. 답변이 맞아야 하고, 작업 궤적에도 자식 작업의 첨부 참조가 있어야 합니다.

원격 실행 환경은 자동으로 영속 저장소가 되지 않습니다. 접속이 끊겨도 프로세스가 남는지, 세션 파일이 보존되는지, 첨부 자산의 권한이 유지되는지는 별도 설정입니다. 운영팀은 이미지 파일, 세션 기록, 작업 로그, 인계 문서를 서로 다른 항목으로 관리해야 합니다.

원격 맥에서 확인할 항목은 다음과 같습니다.

• 첨부 자산의 실제 저장 위치
• 하네스 프로세스가 해당 위치를 읽을 권한
• 다른 운영 계정이 세션을 복구할 때의 접근 범위
• 원격 접속 종료 뒤에도 파일이 남는지
• 새 담당자가 같은 세션과 이미지를 재현할 수 있는지
• 고객 자료와 테스트 자료가 같은 디렉터리에 섞이지 않는지

이 과정에서 민감한 화면을 캡처하지 않습니다. 빈 테스트 화면, 가짜 표식, 폐기 가능한 계정만 사용합니다. 세션 인계 문서에는 비밀 키나 고객 저장소 경로를 넣지 않습니다.

원격 맥을 임시 검수 환경으로 사용할 때는 맥 미니 렌탈 구성 확인과 원격 맥 주문 절차를 먼저 확인하고, 실제 보존 기간과 접근 권한은 배포 전에 별도로 합의합니다.

아래 표는 이미지 첨부를 운영에 투입할지 판단하는 기준입니다.

운영 결정은 다음처럼 단순화합니다.

이번 주에는 빈 테스트 이미지 하나로 MCP와 ACP를 각각 실행하고, 새로 고침·재연결·프로세스 재시작·PTC Mode 중첩 작업까지 한 번에 기록하는 것이 좋습니다. 이미지가 화면에 보인다는 이유만으로 배포 승인하지 않습니다. 모델 선언과 상위 응답이 맞지 않으면 먼저 모델을 바꾸고, 저장과 복구가 불안정하면 세션 설계를 바꿉니다.

현재 로컬 또는 기존 서버 방식은 이미지 파일이 어느 디렉터리에 남는지, 누가 읽을 수 있는지, 세션 복구 때 어떤 요청이 재생되는지 팀마다 달라지는 문제가 있습니다. 여기에 원격 접속 종료, 권한 변경, 임시 저장소 정리까지 겹치면 재현성이 쉽게 무너집니다. 단기간에 독립된 검수 환경이 필요하거나 팀 인계를 반복해야 한다면 MESHLAUNCH의 원격 맥 환경에서 먼저 한 차례 검수하는 편이 운영 판단에 유리합니다. 다만 장기간 고정 부하나 물리 장치 연결이 필요한 업무라면 직접 보유한 맥이 더 적합할 수 있습니다.