Part.8 · 운영·문제 해결·지원

설치·첫 사용 문제 해결: 사례 선택

처음 막혔을 때: 마지막 성공 단계부터 찾기

같은 증상이라도 실패한 단계가 다르면 조치가 달라집니다. 먼저 아래 표에서 마지막으로 직접 확인한 단계를 고릅니다. 한 번 실패한 전체 설치를 처음부터 반복하거나 기존 결과를 삭제할 필요는 없습니다.

지원 요청을 실제로 작성하는 예

다음은 작성 양식입니다. 대괄호를 실제 관찰로 바꾸고, 모르는 값은 미확인이라고 적습니다. 제품이 반환하지 않은 오류 코드·성공 시각을 만들지 않습니다.

목적: [예: SDK Custom 합성 후보 처음 생성]
OS/CPU와 도구 버전: [실제 조회값]
선택 경로: [기존 툴체인 run / 선택 세트 run-offline / GUI 등]
마지막 성공: [예: analyze까지 실제 확인]
실패 단계/시각: [실제 단계, 현지 시간과 시간대]
관찰: [원문 status/reason 또는 OS 오류; 비밀값 제거]
입력/패키지 참조: [버전과 SHA-256; 고객 내용 제외]
기존 결과: [있음/없음, 새 시도와 구분]
다음 확인 요청: [예: 승인된 네이티브 전제 조건 확인]

원본 전체 로그·고객 응답·키·토큰·프로필 원문을 일괄 전송하지 않습니다. 공유 전 민감 정보를 제거한 최소 메시지·식별자만 조직의 지원 경로로 보냅니다. 문제가 해결된 뒤에는 처음 실패했던 단계와 그 영향을 받은 결과를 다시 확인하고 다음 단계로 돌아갑니다.

먼저 현재 단계를 정하십시오

문제를 “설치가 안 된다” 한 문장으로 묶지 마십시오. 가장 마지막으로 확인된 상태를 먼저 적으면 잘못된 재설치나 권한 변경을 줄일 수 있습니다.

실제 상황을 적는 짧은 예

“릴리스 [ID]의 새 VM을 배포했습니다. VM은 실행 중이고 제품은 아직 준비되지 않았습니다. 관리자 등록과 Work는 시작하지 않았습니다. 처음 보인 메시지는 [원문]이며 시각은 [시간대 포함]입니다.” 이 경우에는 A부터 확인합니다. 클라이언트 연결 오류가 동시에 보이더라도 제품 준비가 증명되기 전에는 C의 인증 설정을 바꾸지 않습니다.

반대로 제품 준비와 네트워크 도달성은 확인됐는데 로그인만 거부되면 C에서 인증을 봅니다. 바인딩 화면만 있고 Work 영수증이 없다면 I로 갑니다. 이 순서가 원인을 확정해 주지는 않지만, 아직 증명되지 않은 다음 단계를 성공으로 표시하지 않게 합니다.

즉시 멈춰야 하는 경우

서명·파일 지문 불일치, 예상 밖 호스트 신원, 다른 고객·설치 ID, 권한 확대 의심, 이전 사용자 데이터, 상태 무결성 경고가 있으면 다음 조치를 직접 실행하지 말고 해당 사례의 지원 자료만 최소한으로 모읍니다. 암호, 토큰, 개인키, passkey 응답, 고객 데이터, 전체 로그는 일반 지원 요청에 넣지 않습니다.

증상에서 다음 절차를 선택하기

온라인 환경은 승인된 네트워크·제공자 경로를 사용하는 구성이고, 폐쇄형 온프렘은 필요한 설치 자산·모델·문서 등을 사전에 반입하는 구성입니다. 어느 쪽도 이 안내서가 제품의 기본값으로 고정하지 않습니다. SDK의 선택 Rust 의존성 세트는 SDK 어댑터 빌드의 Rust 범위를 준비하며 어플라이언스 이미지·모델 가중치·제공자 자격 증명·모든 OS 개발 도구를 대신하지 않습니다.

지원 인계 양식의 예: 릴리스·구성요소·OS, 시각과 시각대, 마지막 확인 단계, 최초 거부 원문, 수행한 변경, 현재 결과, 다음 담당자. 미확인·거부·대기·실패·완료를 같은 상태로 합치지 않습니다. 비밀값과 고객 내용은 첨부하지 않습니다.

상세 예시 30개에서 가장 가까운 상황 찾기

하나의 큰 문제 유형 안에서도 증상과 조치가 다릅니다. 아래 링크의 세부 예시 ID를 찾아 상황·관찰·조치·복귀 조건을 순서대로 읽으십시오. 예시는 교육용이며 실제 장애 이력은 별도 근거가 있어야 합니다.

SDK·Builder·GAPE·Integration Helper·소스 Document의 개별 오류는 각 설치 후 도구 안내에 추가한 상세 예시도 함께 확인하십시오. 한 도구의 준비 성공을 다른 도구나 실제 Work의 성공으로 복사하지 않습니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 A: VM은 실행 중인데 제품 서비스가 준비되지 않음

왜 이 사례가 중요한가

클라우드 콘솔에는 VM이 실행 중으로 보여도 어플라이언스는 아직 초기화 중일 수 있습니다. 클라이언트를 연결하거나 Work를 시작하기 전에 설정 화면에서 제품 준비 상태를 확인하십시오.

예시 상황

새 어플라이언스를 만들었고 클라우드 콘솔은 실행 중입니다. 그러나 PackrGUI 연결은 거부되고 제품 상태는 초기화 중 또는 서비스 준비 안 됨입니다. 이때 클라우드 상태와 제품 상태를 별도로 기록합니다.

확인 순서

1. 받은 이미지의 릴리스 ID와 인스턴스가 새 배포인지 확인합니다. 이전 시험 VM이나 다른 릴리스 이미지라면 여기서 멈춥니다.
2. 릴리스 문서에 적힌 첫 부팅 완료 기준과 정상 대기 시간을 확인합니다. 문서에 없는 임의 시간을 성공 기준으로 만들지 않습니다.
3. 클라우드의 VM 실행 상태와 제품의 서비스 준비 상태를 각각 확인합니다. 프로세스가 실행되더라도 제품 준비 상태가 없으면 다음 단계로 가지 않습니다.
4. 릴리스가 제공한 읽기 전용 진단에서 첫 부팅 단계, 필수 구성요소, 서비스 거부 사유를 확인합니다. 제품 명령이나 로그 위치는 릴리스 문서의 정확한 값만 사용합니다.
5. 같은 시각의 네트워크 오류가 있더라도, 서비스 준비가 증명되기 전에는 네트워크를 원인으로 단정하지 않습니다.

이번 릴리스가 packrctl과 정식 로컬 운영 경로를 제공한다면 아래 읽기 전용 명령으로 VM 전원과 제품 준비를 구분해 확인할 수 있습니다. 반환된 준비 상태와 사유를 읽으십시오. health의 0이 아닌 종료 상태는 UNKNOWN이나 NOT_READY일 수 있으며 무작정 VM을 재시작하라는 뜻이 아닙니다.

packrctl status --json
packrctl health --json

결과별 다음 조치

현장 판단 예시: 전원만 켜진 첫 부팅

운영자가 10:00에 새 VM을 만들고 10:02에 콘솔의 실행 중을 확인했지만, 제품 상태가 계속 초기화 중이라고 가정합니다. 이 기록으로 말할 수 있는 것은 VM 전원 상태뿐입니다. 서비스 준비, 관리자 등록 가능, 클라이언트 접속 가능은 각각 아직 확인되지 않았습니다. 이미지 ID와 첫 부팅 시각을 적고 릴리스가 지정한 대기·상태 확인을 한 번 수행합니다. 준비 거부가 지속되면 고객이 게스트 패키지나 초기화 파일을 직접 고치지 않고 지원팀으로 넘깁니다.

지원 요청 예시

“릴리스 ID [값], 인스턴스 생성 시각 [시간대 포함], VM 상태 [실행 중], 제품 상태 [화면에 보인 그대로], 첫 부팅 단계 [값], 최초 오류 [원문]입니다. 고객 Work는 시작하지 않았습니다.”

고객 데이터나 전체 시스템 로그 대신, 릴리스가 지정한 최소 상태 출력만 전달합니다.

완료·중지 기준

완료: 제품이 이 설치 신원에 대해 서비스 준비를 표시합니다. 중지: 초기화 누락, 상태 무결성 경고, 릴리스 불일치, 반복되는 준비 실패가 있으면 복구 파일 삭제·재설치·서비스 강제 시작을 하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 A-1: VM은 실행 중인데 첫 부팅은 진행 중

상황: 설치 담당자는 새 VM의 전원 상태를 확인한 직후 GUI를 엽니다. GUI는 연결 시간 초과를 보이고 제품의 첫 부팅 화면은 아직 초기화 중입니다. 계정이 틀렸다고 판단하기 전에 제품 준비 상태를 따로 확인해야 하는 상황입니다.

관찰을 이렇게 나눠 읽습니다.

• VM: 실행 중. 이 관찰은 전원 상태만 확인합니다.
• 제품: 초기화 진행 중. 준비 완료 시각은 아직 없습니다.
• GUI: 시간 초과. 제품이 준비되기 전이므로 인증 실패 원인으로 확정할 수 없습니다.

확인·조치 순서:

1. 같은 인스턴스의 이미지·생성 기록을 확인하고, 릴리스가 정한 첫 부팅 완료 표시와 정상 대기 기준을 찾습니다.
2. 정상 초기화가 계속 진행되는지 제품 상태에서 확인합니다. 준비 상태가 없는데 계정 재등록·클라이언트 재설치로 넘어가지 않습니다.
3. 준비 완료가 관찰된 뒤 그 설치 신원을 기록하고 원래 GUI 연결을 다시 확인합니다.

다음 단계로 돌아갈 조건: 동일한 새 설치가 준비 상태를 보이고 신원이 맞으면 관리자 설정으로 진행합니다. GUI 접속은 별도로 확인합니다.

해결되지 않았을 때: 공식 대기 기준을 넘기거나 진행 상태가 멈추면 첫 오류와 마지막 갱신 시각을 보존하여 이미지·배포 담당자에게 인계합니다.

상세 예시 A-2: 프로세스는 있지만 필수 초기화가 실패함

상황: 관리 화면에서 서비스 프로세스는 실행 중인데 제품 건강도는 준비되지 않음으로 표시됩니다. 첫 오류에는 필수 초기화 구성요소 또는 설정을 사용할 수 없다는 설명이 있습니다. 프로세스를 강제로 다시 시작하면 될 것처럼 보이지만 이미지와 제품 준비를 먼저 대조합니다.

관찰을 이렇게 나눠 읽습니다.

• 프로세스 시작: 확인됨. 초기화 성공은 별개입니다.
• 건강도: 준비 안 됨. 정확한 사유와 조회 시각을 기록합니다.
• 파일 목록: 전달된 이미지와 실제 이미지가 같은지 아직 대조가 필요합니다.

확인·조치 순서:

1. 전달 목록의 이미지·릴리스와 현재 인스턴스의 출처를 대조합니다. 다른 버전의 설명서와 오류를 비교하지 않습니다.
2. 제공된 읽기 전용 status·health 결과에서 최초 초기화 거부와 그 이후 상태를 구분합니다.
3. 누락 자산이 확인되면 공급자의 해당 이미지 수정·교체 절차로 인계합니다. 고객 VM에서 임의 패키지를 추가하지 않습니다.

다음 단계로 돌아갈 조건: 지원 절차 적용 뒤 현재 이미지·설치 신원과 제품 준비 결과를 다시 대조합니다. 서비스 프로세스만 다시 뜬 상태는 종료 기준이 아닙니다.

해결되지 않았을 때: 초기화 원인이 확인되지 않았거나 이미지가 다른 경우 후속 등록·Work를 보류하고 최소 오류·이미지 신원을 인계합니다.

상세 예시 A-3: 어제의 준비 화면은 정상인데 오늘 연결은 실패함

상황: 사용자는 이전에 저장한 준비 완료 화면을 근거로 서버는 정상이라고 생각합니다. 그 뒤 유지보수나 재부팅이 있었고 오늘의 제품 상태는 아직 읽지 않았습니다. 과거 성공과 현재 관찰을 나누어 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 이전 화면: 변경 이전 시각입니다. 현재 상태의 증거로 사용하지 않습니다.
• 변경 기록: 재부팅·업데이트 시각 중 알려진 항목만 적습니다.
• 현재 상태: 확인 전입니다. 아직 네트워크 장애라고 확정하지 않습니다.

확인·조치 순서:

1. 현재 대상이 이전과 같은 인스턴스인지 확인합니다. 교체됐다면 사례 B·J의 신원 확인도 적용합니다.
2. 변경 이후의 제품 status·health와 최초 오류를 읽습니다. 준비가 확인되면 그 뒤 도달성·인증을 사례 C로 나눕니다.
3. 수정 전후 상태와 변경한 항목을 한 기록에 묶고 영향을 받은 단계만 재확인합니다.

다음 단계로 돌아갈 조건: 현재 준비·신원·클라이언트 인증이 각각 확인되면 그 범위만 복구 완료로 기록합니다.

해결되지 않았을 때: 현재 상태를 조회할 수 없으면 과거 화면으로 빈칸을 채우지 말고 미확인 단계와 관리 경로 장애를 인계합니다.

이 사례의 지원 기록을 실제로 채우기

이미지·인스턴스 출처, 생성 시각, 현재 status·health, 초기화 단계, 첫 거부와 마지막 갱신 시각.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: A-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 B: 접속하려는 서버의 호스트 신원이 달라짐

왜 이 사례가 중요한가

인스턴스를 교체하거나 설정을 바꾸면 호스트 키가 달라질 수 있습니다. 경고는 목적지의 신원이 아직 확인되지 않았다는 뜻이므로 검사를 끄고 재접속하지 마십시오.

예시 상황

어제 접속한 주소로 다시 연결했는데 SSH 또는 앱이 서버 신원이 변경됨을 알립니다. 사용자는 같은 VM이라고 생각하지만 실제로는 새 인스턴스, 재생성된 키, 잘못된 주소, 또는 확인되지 않은 다른 호스트일 수 있습니다.

확인 순서

1. 연결을 중단하고 경고의 발생 시각, 접속 주소, 표시된 신원 정보를 기록합니다. 비밀키나 자격 증명은 기록에 넣지 않습니다.
2. 릴리스가 허용한 관리 콘솔에서 대상 인스턴스의 이름·설치 ID·생성 또는 재시작 이력을 확인합니다. 주소만 같다는 이유로 동일 호스트라 판단하지 않습니다.
3. 제품 또는 클라우드의 독립적인 인증 경로가 제공하는 현재 호스트 신원을 대조합니다. 접속 경고가 난 바로 그 채널에서 받은 값만으로 그 채널을 신뢰하지 않습니다.
4. 두 값이 일치하고 릴리스가 신뢰 갱신 절차를 명시한 경우에만 그 절차를 사용합니다. 신뢰 갱신 권한이 없다면 관리자·지원팀에 넘깁니다.
5. 연결 후에도 고객·설치 신원이 예상한 값인지 확인합니다. 호스트 키 확인은 제품 권한 확인을 대신하지 않습니다.

결과별 다음 조치

현장 판단 예시: 같은 주소에서 공개키 경고

주소는 그대로인데 접속 도구가 다른 호스트키를 표시했다고 가정합니다. 새 인스턴스가 같은 주소를 재사용했을 수도 있고, 원래 인스턴스에서 키가 다시 생성됐을 수도 있습니다. 경고 메시지만으로 어느 쪽인지 확정할 수 없습니다. 접속을 멈춘 상태에서 관리 콘솔의 인스턴스·디스크 신원과 릴리스가 제공하는 독립 인증 경로의 현재 키를 대조합니다. 둘 중 하나라도 확인되지 않으면 저장된 신뢰 항목을 지우거나 교체하지 않습니다.

지원 요청 예시

“릴리스 ID [값], 예상 설치 ID [값], 접속 대상 [공식 별칭], 경고 시각 [시간대 포함], 경고 유형 [원문], 인스턴스 교체 여부 [확인 결과]입니다. 경고 뒤 연결은 진행하지 않았습니다.”

완료·중지 기준

완료: 현재 호스트 신원, 설치 신원, 공식 접속 대상이 독립 증거와 일치합니다. 중지: 신원 차이가 해소되지 않으면 호스트 검사 해제, 경고 무시, 저장된 키 임의 삭제·교체를 하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 B-1: VM 교체 후 같은 주소에서 호스트 키 경고

상황: 운영자가 VM을 교체했고 클라이언트는 어제와 같은 주소로 접속합니다. 경고에는 서버 키가 달라졌다고 표시됩니다. 주소 재사용은 가능한 설명이지만 접속 채널의 현재 신원이 검증된 것은 아닙니다.

관찰을 이렇게 나눠 읽습니다.

• 주소: 이전과 같음. 인스턴스 동일성을 뜻하지 않습니다.
• 관리 콘솔: 인스턴스 교체 기록을 별도로 확인합니다.
• 호스트 지문: 경고 채널의 값과 독립 경로의 값을 구분합니다.

확인·조치 순서:

1. 연결을 중단한 채 승인된 콘솔에서 현재 인스턴스·디스크·이미지 신원을 확인합니다.
2. 릴리스의 독립 인증 경로에서 현재 공개키 지문을 얻어 경고의 값과 대조합니다.
3. 정확히 일치하고 신뢰 갱신 권한이 있는 담당자가 제공된 갱신 절차를 적용한 뒤 제품 설치 신원을 확인합니다.

다음 단계로 돌아갈 조건: 현재 호스트와 제품 설치 신원이 모두 예상 값과 일치해야 접속 단계로 돌아갑니다.

해결되지 않았을 때: 독립 지문이 없거나 불일치하면 신뢰 기록 삭제·검사 해제 없이 보류하고 신원 담당자에게 인계합니다.

상세 예시 B-2: 잘못 저장된 접속 대상과 올바른 서버를 구별하기

상황: 북마크나 클라이언트 프로필의 별칭은 맞아 보이는데 연결된 제품은 예상 설치가 아닙니다. 서버 키가 유효하더라도 원래 작업 대상이 잘못 선택됐을 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 프로필 별칭: 사람이 붙인 이름입니다. 실제 대상 신원과 별도로 기록합니다.
• 호스트 신원: 유효해도 다른 승인 서버일 수 있습니다.
• 고객·설치 표시: 예상 값과 다르면 현재 세션을 작업에 사용하지 않습니다.

확인·조치 순서:

1. 릴리스가 지정한 실제 엔드포인트와 저장 프로필의 주소·포트를 대조합니다.
2. 현재 제품의 고객·설치 신원을 독립 설치 기록과 대조합니다. 다른 고객 내용을 열어 확인하지 않습니다.
3. 승인된 클라이언트 설정 화면에서 올바른 프로필을 선택하고 새 세션의 신원·범위를 다시 확인합니다.

다음 단계로 돌아갈 조건: 올바른 대상에 인증됐다는 현재 기록을 확인하면 원래 절차를 계속합니다.

해결되지 않았을 때: 공식 엔드포인트와 설치 신원이 연결되지 않으면 접근을 중단하고 주소·신원 담당자가 확인합니다.

상세 예시 B-3: 같은 인스턴스라고 하는데 키가 다시 바뀜

상황: 정당한 키 갱신을 한 번 확인했는데 이후 같은 인스턴스에서 다시 경고가 납니다. 재부팅이나 설정 변경이 있었다는 설명만으로 반복 갱신을 승인하지 않습니다.

관찰을 이렇게 나눠 읽습니다.

• 키 변경: 두 관찰 사이에 다시 발생했습니다. 변경 이력을 구분합니다.
• 인스턴스: 같다는 설명과 실제 콘솔 ID를 대조합니다.
• 현재 키: 이전 검증값과 다르면 다시 미확인 상태입니다.

확인·조치 순서:

1. 첫 키 갱신의 근거와 이후 경고 시각·대상을 보존합니다.
2. 승인된 변경 기록과 독립 경로의 현재 신원을 담당자가 대조합니다.
3. 원인이 확인되고 현재 값이 검증되기 전에는 접속을 반복하지 않습니다.

다음 단계로 돌아갈 조건: 담당자가 현재 호스트·설치와 변경 이력을 확인한 뒤 지정한 접속 경로만 재확인합니다.

해결되지 않았을 때: 원인 미확인의 반복 키 변경은 사용자 설정 정리로 처리하지 않고 신원 문제로 인계합니다.

이 사례의 지원 기록을 실제로 채우기

예상 대상 별칭, 경고 시각, 인스턴스 교체 여부, 독립 호스트 지문 확인 여부, 제품 설치 신원 일치 여부.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: B-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 C: 네트워크 장애와 인증 거부를 구별하기

왜 이 사례가 중요한가

시간 초과와 로그인 거부는 확인할 지점이 다릅니다. 시간 초과는 네트워크나 서비스 준비 상태를, 서버에 도달한 뒤의 거부는 인증이나 접근 범위를 먼저 확인하십시오.

예시 상황

PackrGUI가 연결을 못 합니다. 한 번은 연결 시간 초과, 다음에는 로그인 거부가 보입니다. 앞의 오류는 도달성 또는 준비 상태이고, 뒤의 오류는 인증 또는 신원 범위일 수 있습니다. 두 메시지를 별개로 기록합니다.

확인 순서

1. 현재 어플라이언스의 릴리스 ID와 설치 ID가 맞는지 확인합니다.
2. VM 실행과 제품 서비스 준비를 구분합니다. 제품이 준비되지 않았다면 사례 A부터 해결합니다.
3. 릴리스의 공식 주소·네트워크 경로와 고객 방화벽 정책을 확인합니다. 다른 포트나 공개 인터넷 경로를 임의로 열지 않습니다.
4. 도달성이 확인된 뒤에만 현재 계정, 릴리스가 지정한 로그인 방식, 계정의 고객·설치 범위를 확인합니다.
5. 인증이 성공해도 제품 화면에서 고객·설치 신원과 허용 기능을 확인합니다. 로그인 성공은 런타임 바인딩 또는 Work 권한이 아닙니다.

메시지에 따른 분기

재검증과 지원 자료

문제가 해결되면 서비스 준비 → 도달성 → 인증 → 제품 설치 신원을 다시 순서대로 확인합니다. 지원 요청에는 첫 오류와 이후 오류를 각각 원문·시각으로 적고, 접속 대상은 공개 가능한 공식 별칭으로만 적습니다. 암호, 토큰, 개인키를 보내지 않습니다.

완료·중지 기준

완료: 인증된 클라이언트가 예상 고객·설치 신원을 보여 줍니다. 중지: 신원 불일치나 인증 경로 미확인은 다른 계정·키를 빌리거나 호스트 검사를 끄는 방식으로 넘기지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 C-1: 접속 시간 초과와 서비스 미준비를 분리하기

상황: 같은 사용자 계정으로 어제는 접속됐지만 오늘은 응답이 없습니다. 로그인 화면조차 나오지 않았습니다. 이때 암호 오류를 가정하기보다 서버 준비와 승인된 경로를 순서대로 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 클라이언트: 시간 초과이며 인증 응답은 받지 못했습니다.
• 서버 준비: 현재 결과를 확인해야 합니다.
• 주소·포트: 릴리스의 값과 비교 전에는 올바르다고 가정하지 않습니다.

확인·조치 순서:

1. 사례 A에서 현재 서비스 준비를 확인합니다. 미준비면 먼저 그 단계를 해결합니다.
2. 저장된 엔드포인트와 조직이 승인한 DNS·방화벽·접속 경로가 같은지 담당자가 확인합니다. 임의 포트를 열지 않습니다.
3. 도달성이 회복된 뒤 인증 결과와 고객·설치 신원을 별도로 확인합니다.

다음 단계로 돌아갈 조건: 같은 승인 경로로 응답·인증·신원이 확인돼야 연결 복구로 기록합니다.

해결되지 않았을 때: 어느 경로에서 멈추는지 확인할 수 없으면 마지막 도달 지점과 시간 초과를 네트워크 담당자에게 인계합니다.

상세 예시 C-2: 서버는 응답하지만 세션이 만료됨

상황: GUI에서 서버 신원은 확인되지만 로그인 거부가 나오고 헤드리스 조회도 현재 계정에서는 거부됩니다. 네트워크가 응답했다는 사실과 세션이 유효하다는 사실을 분리합니다.

관찰을 이렇게 나눠 읽습니다.

• 서버 응답: 있음. 단순 도달성 문제와 구별합니다.
• 세션: 만료 또는 미인증이라는 실제 표시를 원문대로 기록합니다.
• 다른 경로: GUI와 헤드리스의 계정·세션이 같다고 가정하지 않습니다.

확인·조치 순서:

1. 현재 릴리스의 로그인 방식과 계정·유효기간을 확인합니다.
2. 허용된 현재 계정으로 정식 재인증하고 반환된 고객·설치 범위를 확인합니다.
3. GUI와 헤드리스에서 필요한 각 경로를 따로 조회합니다. 사용자 토큰을 서비스에 복사하지 않습니다.

다음 단계로 돌아갈 조건: 사용할 경로의 현재 세션이 인증됐고 올바른 설치를 보여 주면 그 경로의 연결 단계가 끝납니다.

해결되지 않았을 때: 재인증해도 권한 거부가 지속되면 계정 담당자에게 정확한 범위·사유를 인계합니다. 암호·토큰은 보내지 않습니다.

상세 예시 C-3: GUI는 되는데 자동화 서비스만 접속 실패

상황: 워크스테이션 GUI는 정상인데 서버의 정기 작업은 접속 거부를 받습니다. GUI 화면을 성공 증거로 복사하지 않고 서비스의 실행 위치와 신원으로 조회합니다.

관찰을 이렇게 나눠 읽습니다.

• GUI: 현재 사용자 세션의 성공입니다.
• 자동화: 별도 계정·네트워크·허용 범위를 사용할 수 있습니다.
• 실패: 시간 초과인지 인증 거부인지 원문으로 나눕니다.

확인·조치 순서:

1. 해당 릴리스가 헤드리스 경로와 서비스 인증 절차를 제공하는지 확인합니다.
2. 서비스의 공식 접속 주소, 실행 계정, 세션 상태와 고객·설치 범위를 각각 기록합니다.
3. 담당자가 실패한 경로를 조정한 뒤 동일 서비스 신원으로 읽기 전용 상태를 재확인합니다.

다음 단계로 돌아갈 조건: GUI 성공과 별도로 헤드리스의 인증·신원·허용 기능을 확인한 경우에만 해당 자동화 경로가 준비됐다고 기록합니다.

해결되지 않았을 때: 서비스 인증이 제공되지 않거나 범위 승인이 없으면 사용자 자격 증명 복사로 대체하지 말고 미제공·미승인으로 인계합니다.

이 사례의 지원 기록을 실제로 채우기

사용 경로, 현재 서버 준비, 시간 초과·신원·인증 중 실패 단계, 세션 상태, 고객·설치 범위.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: C-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 D: 관리자 등록이 비대화형 입력을 거부함

실제 관찰과 의미

관리자 등록에는 실제 대화형 확인이 필요할 수 있습니다. 스크립트나 파이프로 보낸 값은 거부될 수 있으므로, 관리자 기능을 사용하기 전에 제품의 성공 기록을 확인하십시오.

예시 상황

설치 담당자가 자동화 스크립트에서 관리자 등록을 실행했습니다. 출력에는 사용자 확인이 필요하다는 거부가 있고, 뒤이어 바인딩 위자드는 관리자 범위를 찾지 못합니다. 여기서 임의로 “등록된 것으로 간주”하면 후속 오류를 만듭니다.

확인 순서

1. 릴리스가 요구하는 등록 방식이 로컬 설정 UI인지, 실제 대화형 터미널인지 확인합니다.
2. 시도한 방식이 파이프·예약 작업·비대화형 원격 세션이었는지 확인합니다. 비밀 입력이나 확인 단어 자체는 지원 자료에 넣지 않습니다.
3. 제품의 현재 관리자 등록 상태를 읽기 전용으로 확인합니다. 성공 기록이 없다면 후속 바인딩을 시작하지 않습니다.
4. 승인된 실제 관리자가 릴리스 절차에 따라 대화형 화면에서 고객·설치·런타임 범위를 검토하고 직접 확인합니다.
5. 등록 결과의 역할, 허용 범위, 유효기간과 설치 신원을 다시 읽습니다. OS 로그인 성공과 제품 관리자 등록을 구별합니다.

예시 분기

지원 요청 예시

“릴리스 [값], 관리자 등록 단계 [값], 입력 방식 [대화형/비대화형], 제품 거부 메시지 [원문], 등록 상태 [없음/있음/확인 불가]입니다. 비밀 입력은 첨부하지 않았습니다.”

완료·중지 기준

완료: 실제 관리자의 제품 역할과 이 설치의 허용 범위가 기록되어 읽힙니다. 중지: 확인 절차를 자동 입력으로 흉내 내거나 OS 관리자 권한을 제품 권한으로 대체하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 D-1: 원격 파이프에서 관리자 확인이 거부됨

상황: 설치 스크립트에 관리자 등록 명령을 넣었더니 실제 터미널 또는 사용자 확인이 필요하다는 거부가 나옵니다. 등록 결함으로 단정하기 전에 제공된 절차의 대화형 요구를 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 입력 경로: 파이프·비대화형 작업입니다.
• 제품 결과: 사용자 확인 요구가 충족되지 않았습니다.
• 등록 상태: 완료된 역할·범위 기록은 아직 없습니다.

확인·조치 순서:

1. 등록 문서에서 허용하는 로컬 위자드 또는 대화형 터미널 경로를 찾습니다.
2. 실제 관리자가 해당 설치·고객·런타임 범위와 유효기간을 직접 확인합니다.
3. 등록 직후 읽기 전용 상태로 역할과 범위가 기록됐는지 확인합니다.

다음 단계로 돌아갈 조건: 사용자 확인과 제품의 등록 결과가 모두 있어야 관리자 설정 완료로 기록합니다.

해결되지 않았을 때: 대화형 경로를 사용할 수 없다면 자동 입력·확인 토큰 조작 없이 해당 조건을 담당자에게 인계합니다.

상세 예시 D-2: OS 관리자로 로그인했지만 제품 관리자 역할이 없음

상황: 운영체제 관리 권한으로 로그인한 사용자가 제품 관리 화면에서도 관리자일 것으로 기대합니다. 제품은 현재 설치의 관리자 역할이 없다고 표시합니다.

관찰을 이렇게 나눠 읽습니다.

• OS 로그인: 성공했습니다.
• 제품 역할: 해당 설치에서 미등록 또는 미확인입니다.
• 설치 범위: 다른 설치의 등록 상태를 재사용할 수 없습니다.

확인·조치 순서:

1. 현재 설치 신원을 제품에서 확인하고 기존 등록 기록이 어느 설치를 대상으로 했는지 대조합니다.
2. 제공된 제품 관리자 등록 절차를 현재 설치에서 수행할 담당자를 확인합니다.
3. OS 권한 상승 대신 제품 역할·범위·유효기간이 기록됐는지 확인합니다.

다음 단계로 돌아갈 조건: 현재 설치에 대한 제품 관리자 결과가 확인된 뒤 그 범위 안의 관찰을 수행합니다.

해결되지 않았을 때: 관리자 지정 권한이 없으면 등록을 시도해 넓히지 않고 권한 담당자에게 인계합니다.

상세 예시 D-3: 등록은 끝났지만 고객·런타임 범위가 다름

상황: 등록 완료 화면을 본 뒤 런타임 연결을 시도했지만 범위 거부가 나옵니다. 실제 기록에는 의도와 다른 고객·설치 또는 제한된 런타임 범위가 들어 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 등록 완료: 역할 존재에 대한 결과입니다.
• 허용 범위: 현재 요청을 포함하는지는 별도입니다.
• 거부 결과: 정확한 대상과 사유를 보존합니다.

확인·조치 순서:

1. 현재 설치·고객·런타임 참조와 관리자 기록의 값을 나란히 대조합니다.
2. 어느 항목이 잘못됐는지 확인한 뒤 권한 있는 담당자가 정식 범위 변경을 판단합니다.
3. 변경된 범위를 읽어 확인한 뒤 영향을 받은 관찰·검증부터 다시 진행합니다.

다음 단계로 돌아갈 조건: 현재 요청이 기록된 허용 범위 안에 있고 제품이 재검증한 결과가 있어야 진행합니다.

해결되지 않았을 때: 원래 승인 범위를 확인할 수 없으면 기존 기록을 직접 편집하지 않고 보류합니다.

이 사례의 지원 기록을 실제로 채우기

등록 경로·대화형 여부, 현재 설치 신원, 실제 관리자 확인 여부, 제품 역할·범위·유효기간.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: D-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 E: 관리자 등록 뒤 저장소 접근이 거부됨

실제 관찰과 의미

관리자 등록이 완료돼도 제품이 정책을 읽을 때 접근 거부가 나올 수 있습니다. 등록 성공과 후속 접근 성공을 따로 확인하고 표시된 거부 사유에 따라 조치하십시오.

예시 상황

관리자 등록은 성공으로 보였습니다. 그러나 런타임을 관찰하려는 순간 Permission denied 또는 저장소 접근 오류가 뜹니다. 관리자 권한을 여러 번 다시 등록하기보다 첫 오류를 보존합니다.

확인 순서

1. 제품이 보여 준 최초 오류의 시각·단계·거부 코드를 기록합니다. 재시도로 최초 오류를 덮어쓰지 않습니다.
2. 릴리스와 설치 ID가 등록 당시와 같은지 확인합니다. 다른 설치의 정책을 읽는 상황이라면 즉시 멈춥니다.
3. 제품 서비스 준비 상태와 관리자 등록 상태를 릴리스의 읽기 전용 화면에서 각각 확인합니다.
4. 저장소 접근 오류인지, 관리자 역할이 없는 것인지, 허용 범위 밖인지 메시지를 구분합니다. 세 경우의 조치는 다릅니다.
5. 해당 릴리스의 알려진 수정·지원 지침을 확인합니다. 고객이 직접 파일 소유권이나 잠금 파일을 수정하는 단계는 아닙니다.

결과별 조치

지원 자료

릴리스·설치 ID, 최초 거부 메시지, 관리자 등록 성공 여부, 서비스 준비 상태, 발생 시각을 보내십시오. 잠금 파일, 내부 데이터베이스, 관리자 정책 원본, 비밀키, 전체 로그는 첨부하지 않습니다.

완료·중지 기준

완료: 제품이 해당 관리자 상태를 읽고 허용 범위 안의 관찰을 정상 처리합니다. 중지: 재등록 반복, 파일 권한 확대, 잠금 파일 삭제, 서비스 계정 변경을 하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 E-1: 등록 성공 뒤 첫 상태 조회에서 접근 거부

상황: 관리자 등록은 완료됐지만 이후 정책·상태를 읽는 단계에서 Permission denied가 표시됩니다. 같은 등록을 반복하기 전에 최초 등록 결과와 후속 접근 오류를 따로 보존합니다.

관찰을 이렇게 나눠 읽습니다.

• 등록 결과: 존재합니다.
• 후속 조회: 접근 거부로 종료됐습니다.
• 근거: 저장소 오류인지 역할 범위인지 아직 제품 사유로 분류해야 합니다.

확인·조치 순서:

1. 두 결과의 릴리스·설치 신원이 같은지 대조합니다.
2. 제품이 준 정확한 오류 단계·사유를 보관하고 서비스 준비도 읽기 전용으로 확인합니다.
3. 정식 지원 절차에서 해당 버전의 수정 여부를 확인합니다. 파일 소유권·잠금 파일을 직접 바꾸지 않습니다.

다음 단계로 돌아갈 조건: 지원 절차 적용 후 같은 설치에서 관리자 상태를 읽고 허용 관찰이 성공하는지 확인합니다.

해결되지 않았을 때: 내부 저장소 접근이 계속 거부되면 최초 오류와 버전을 인계하고 데이터베이스 원본은 일반 티켓에 첨부하지 않습니다.

상세 예시 E-2: 조회는 되지만 범위 밖 작업만 거부됨

상황: 관리자 상태는 정상적으로 읽히지만 특정 런타임 또는 기능 요청만 거부됩니다. 모든 접근 거부를 파일 권한 문제로 묶으면 실제 범위 거부를 놓칠 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 관리자 조회: 정상입니다.
• 특정 요청: 현재 허용 범위 밖이라고 표시됩니다.
• 다른 작업: 성공하더라도 해당 요청의 권한을 증명하지 않습니다.

확인·조치 순서:

1. 요청의 설치·고객·기능·런타임과 관리자 허용 범위를 대조합니다.
2. 필요한 범위 변경인지 잘못 선택한 대상인지 담당자가 구별합니다.
3. 대상 또는 승인이 정식으로 바로잡힌 뒤 같은 제한된 요청을 재확인합니다.

다음 단계로 돌아갈 조건: 허용된 범위의 요청이 성공하면 그 기능까지만 복구 완료로 기록합니다.

해결되지 않았을 때: 범위 승인이 없으면 파일 권한 확대나 서비스 계정 교체로 해결하지 않습니다.

상세 예시 E-3: 업데이트 이후 처음 나타난 저장소 접근 오류

상황: 기존 환경을 업데이트한 뒤 관리자 상태 조회가 실패합니다. 예전 정상 결과는 있지만 업데이트 이후 접근 성공은 아직 없습니다. 수정된 버전·현재 신원·실패 단계를 묶어 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 이전 버전: 조회 성공 기록이 있습니다.
• 현재 버전: 첫 조회부터 접근 오류가 있습니다.
• 설치 신원: 변경 여부를 별도로 확인해야 합니다.

확인·조치 순서:

1. 업데이트 전후 정확한 버전과 승인된 변경 기록을 확인합니다.
2. 현재 설치·서비스·관리자 상태를 제품의 허용된 읽기 전용 진단으로 확인합니다.
3. 해당 버전의 복구·롤백 안내를 담당자가 적용하도록 인계합니다. 임의 하위 버전 파일을 섞지 않습니다.

다음 단계로 돌아갈 조건: 복구한 버전·현재 설치·정상 조회가 함께 확인돼야 해당 접근 문제가 해결됐다고 기록합니다.

해결되지 않았을 때: 복구 절차가 없거나 상태 무결성 경고가 있으면 작업을 보류하고 최소 오류·변경 내역을 인계합니다.

이 사례의 지원 기록을 실제로 채우기

등록 완료 기록, 최초 접근 거부 단계·시각, 서비스 상태, 현재 역할·범위, 변경 전후 버전.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: E-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 F: 로컬 런타임은 보이지만 바인딩되지 않음

실제 관찰과 의미

로컬 모델을 찾는 단계와 현재 설치에 바인딩하는 단계는 별개입니다. 모델 별칭이나 런타임 주소를 바꾼 뒤에는 새 바인딩 결과를 확인하고 Work에 사용하십시오.

예시 상황

관리자는 로컬 모델이 설치된 것을 확인했습니다. PackrGUI에는 런타임이 감지됨으로 보이지만 바인딩됨은 아닙니다. 전날 모델 별칭 또는 런타임 주소를 바꿨다면 과거 상태와 현재 관찰을 구별해야 합니다.

확인 순서

1. 릴리스가 지원하는 런타임 종류와 모델인지 확인합니다. 모델 파일 존재만으로 지원 여부를 결정하지 않습니다.
2. 제품 화면에서 감지 시각, 검증 상태, 바인딩 상태를 따로 읽습니다. 이전 부팅의 상태가 아닌지 확인합니다.
3. 현재 고객·설치 ID와 관리자 승인 범위가 런타임 위치·모델을 포함하는지 확인합니다.
4. 제품이 모호성이나 범위 밖을 표시하면 그 이유를 그대로 기록합니다. 여러 모델 중 어느 것을 선택할지 고객이 추측해 저장소에 기록하지 않습니다.
5. 릴리스 위자드가 제공하는 재관찰 또는 범위 승인 절차를 사용합니다. 이후 새 바인딩의 모델 참조와 설치 ID를 읽습니다.
6. 바인딩이 완료되어도 실제 Work 호출 여부는 사례 I에서 별도로 확인합니다.

분기 예시

현장 판단 예시: 별칭 변경 뒤 과거 바인딩 표시

11:00에 런타임 별칭이 바뀌었는데 제품에는 10:30의 바인딩됨 기록이 남아 있다고 가정합니다. 10:30 기록은 변경 전 상태입니다. 11:00 이후 새 감지, Core 검증, 바인딩의 각 시각과 모델 참조가 이어져야 변경 후 자동 재바인딩을 확인할 수 있습니다. 새 감지만 있고 바인딩이 없다면 사례의 분기표로 원인을 좁힙니다.

이 표의 시각은 가상 예시입니다. 제품이 실제로 반환한 상태·거부 코드를 기록하고, 내부 저장소를 직접 편집하지 마십시오.

지원 요청 예시

“릴리스 [값], 설치 ID [값], 런타임 종류 [공개 가능한 이름], 기대 모델 [이름], 변경 시각 [값], 감지/검증/바인딩 상태 [각각], 거부 메시지 [원문]입니다. Work는 실행하지 않았습니다.”

완료·중지 기준

완료: 현재 관찰과 승인 범위에 연결된 새 바인딩이 제품에 표시됩니다. 중지: 데이터베이스를 직접 고치거나 거부된 이전 바인딩을 복사하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 F-1: 모델 파일은 있지만 런타임 관찰이 없음

상황: 운영자는 모델 파일을 준비했으므로 바인딩도 완료될 것으로 기대합니다. 제품에는 현재 런타임 관찰이 없거나 감지 단계만 표시됩니다. 파일 준비·프로세스·제품 관찰을 각각 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• 모델 파일: 존재만 확인됐습니다.
• 런타임 프로세스: 지원 버전과 실제 실행 상태를 확인해야 합니다.
• 제품 관찰: 최신 관찰·검증·바인딩이 아직 없습니다.

확인·조치 순서:

1. 릴리스가 지원하는 런타임·모델·주소와 실제 준비한 조합을 대조합니다.
2. 제품의 감지·설정 위자드에서 현재 관찰과 사유를 확인합니다.
3. 지원 범위 안에서 준비가 끝난 뒤 제품이 새 관찰을 검증했는지 확인합니다.

다음 단계로 돌아갈 조건: 현재 설치의 런타임·모델 참조가 검증·바인딩됐을 때만 바인딩 완료로 기록합니다.

해결되지 않았을 때: 지원 대상이나 관찰 경로를 확인할 수 없으면 바인딩 상태 파일을 직접 만들지 않고 담당자에게 인계합니다.

상세 예시 F-2: 별칭만 바꿨는데 이전 바인딩이 계속 보임

상황: 모델 별칭을 바꾼 뒤 화면에는 여전히 이전 바인딩이 보입니다. 화면 캐시인지, 새 관찰이 아직 없는지, 새 대상이 거부됐는지를 먼저 구분해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 변경 기록: 별칭 또는 주소의 전후 값을 구분합니다.
• 표시된 바인딩: 변경 전 관찰일 수 있습니다.
• 새 관찰: 시각·대상·거부 사유를 별도로 확인합니다.

확인·조치 순서:

1. 이전 바인딩 참조와 새로 요청한 런타임·모델 참조를 보존합니다.
2. 제품이 제공한 새 관찰·검증 절차를 사용하고 그 시각이 변경 이후인지 대조합니다.
3. 새 대상이 범위 밖이면 승인 담당자가 판단할 때까지 이전 결과를 새 대상으로 복사하지 않습니다.

다음 단계로 돌아갈 조건: 새 관찰에 묶인 대상과 바인딩이 일치해야 새 환경 적용으로 기록합니다.

해결되지 않았을 때: 새 관찰이 없거나 사유가 미확인이면 이전 바인딩을 근거로 새 Work를 시작하지 않습니다.

상세 예시 F-3: 여러 모델이 감지돼 대상 선택이 모호함

상황: 한 환경에 둘 이상의 모델이 있고 제품이 런타임은 감지했지만 자동 바인딩을 적용하지 않습니다. 사용 가능한 첫 모델을 임의로 골라 성공 처리할 수 없는 상황입니다.

관찰을 이렇게 나눠 읽습니다.

• 감지: 여러 후보가 보입니다.
• 관리자 범위: 어느 모델·런타임을 허용했는지 확인이 필요합니다.
• 제품 결과: 모호함 또는 범위 거부 사유를 그대로 보존합니다.

확인·조치 순서:

1. 원래 계획한 대상과 공급자가 지원하는 모델 조합을 먼저 특정합니다.
2. 관리자가 현재 설치의 허용 범위를 제품 절차에서 확인합니다.
3. 정확한 대상이 정해진 뒤 새 관찰·검증 결과를 읽습니다.

다음 단계로 돌아갈 조건: 의도한 단일 대상과 검증된 바인딩이 기록된 뒤 해당 범위의 사용을 계속합니다.

해결되지 않았을 때: 대상 선택 권한이나 지원 조합이 없으면 임의 기본값을 만들어 바인딩하지 않습니다.

이 사례의 지원 기록을 실제로 채우기

현재 런타임·모델 참조, 변경 전후 값, 관찰 시각, 검증 결과·거부 사유, 관리자 허용 범위.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: F-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 G: 로컬 모델이 시작되지 않거나 외부 확인이 시간 초과됨

실제 관찰과 의미

로컬 모델 시작 실패는 모델 부재, 자원 부족, 네트워크 확인 실패 등 원인이 다를 수 있습니다. 네트워크 정책을 바꾸기 전에 정확한 메시지와 제공된 오프라인 설정 절차를 확인하십시오.

예시 상황

고객은 오프라인 환경에서 로컬 모델을 쓰려 합니다. 런타임이 모델 다운로드를 기다리거나 메타데이터 확인이 시간 초과됩니다. 또는 모델 시작이 실패하지만 화면만으로 메모리 부족인지 모델 부재인지 구분되지 않습니다.

확인 순서

1. 릴리스의 지원 모델·아키텍처·메모리·디스크 요구사항을 확인하고 그 목록에 맞춰 VM 크기를 정합니다.
2. 모델이 이미 로컬에 준비됐는지 제품 또는 릴리스가 지정한 방법으로 확인합니다. 다운로드 화면은 로컬 설치 완료가 아닙니다.
3. 고객의 오프라인 정책과 릴리스가 요구하는 로컬 전용 설정을 확인합니다. 외부 접근이 금지된 환경에서 임의로 인터넷 출구를 열지 않습니다.
4. 실패가 모델 프로세스 시작인지, 런타임 발견인지, 바인딩 검증인지 분리합니다. 문제 단계가 다르면 조치도 다릅니다.
5. 제품이 기록한 호출·실패 상태를 확인합니다. 시간 초과된 공급사 메타데이터 요청을 성공한 AI 추론으로 기록하지 않습니다.
6. 자원을 변경할 경우 고객이 승인한 환경 변경 절차 뒤 런타임을 다시 관찰·검증·바인딩합니다.

결과별 조치

지원 요청 예시

“릴리스 [값], OS/아키텍처 [값], 모델 [값], 로컬 모델 준비 여부 [값], 실패 단계 [시작/발견/검증/Work], 최초 오류 [원문], 외부 통신 정책 [허용/차단]입니다. 프롬프트와 고객 데이터는 첨부하지 않았습니다.”

완료·중지 기준

완료: 지원되는 로컬 모델이 준비되고 현재 런타임이 검증·바인딩됩니다. 실제 추론과 Work는 별도 확인이 필요합니다. 중지: 요구 사양 미확인, 비승인 인터넷 연결, 외부 추론이 없었다는 근거 없는 주장.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 G-1: 모델 로딩 중 종료되지만 메모리 부족은 아직 미확인

상황: 모델을 시작하면 곧 종료됩니다. 사용자는 무조건 메모리를 늘리려 하지만 실제 오류는 아직 확인하지 않았습니다. 자원·아키텍처·모델 준비 상태를 함께 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 프로세스: 시작 후 종료됩니다.
• 실패 사유: 실제 오류 없이는 자원 부족으로 확정하지 않습니다.
• 지원 조건: 모델·아키텍처·메모리·디스크 요구사항이 비교 대상입니다.

확인·조치 순서:

1. 정확한 모델 버전·아키텍처와 릴리스 요구사항을 대조합니다.
2. 허용된 상태 조회에서 사용 가능한 자원과 최초 종료 사유를 확인합니다.
3. 실제로 부족한 자원이 확인되면 환경 담당자가 승인된 변경 후 런타임을 다시 관찰합니다.

다음 단계로 돌아갈 조건: 모델이 지원 조건에서 시작되고 현재 관찰·검증·바인딩까지 확인되면 준비 완료로 기록합니다.

해결되지 않았을 때: 정확한 실패 사유가 없으면 크기 변경·모델 교체를 반복하지 않고 종료 관찰과 지원 조건을 인계합니다.

상세 예시 G-2: 폐쇄망에 모델 파일을 반입하지 않아 다운로드 대기

상황: 폐쇄형 온프렘에 클라이언트와 SDK 의존성 세트는 반입했지만 모델은 없습니다. 런타임은 모델 다운로드를 기다립니다. Rust 의존성이 준비됐다는 사실은 모델 가중치가 준비됐다는 뜻이 아닙니다.

관찰을 이렇게 나눠 읽습니다.

• SDK 의존성: Rust 컴파일 자산에 대한 준비입니다.
• 모델: 로컬에 준비됐는지 별도 확인합니다.
• 외부 경로: 차단 정책을 임의로 열어 해결하지 않습니다.

확인·조치 순서:

1. 실제 사용할 모델·버전과 라이선스·지문·저장 요구를 제공 목록에서 확인합니다.
2. 조직이 승인한 오프라인 모델 반입 경로로 준비하도록 담당자에게 인계합니다.
3. 파일 확인 뒤 모델 시작, 현재 관찰과 바인딩을 순서대로 확인합니다.

다음 단계로 돌아갈 조건: 필요한 모델이 검증된 로컬 자산으로 준비되고 런타임 바인딩이 확인돼야 해당 준비가 끝납니다.

해결되지 않았을 때: 반입 경로나 권리가 미확인이면 임의 저장소에서 모델을 가져오지 않고 공급·라이선스 담당자에게 인계합니다.

상세 예시 G-3: 온라인 메타데이터 확인 실패와 로컬 사용을 구별하기

상황: 로컬 모델은 준비돼 있지만 외부 메타데이터 조회가 시간 초과됩니다. 이 한 결과를 전체 로컬 추론 실패 또는 외부 통신이 전혀 없었다는 증거로 사용할 수 없습니다.

관찰을 이렇게 나눠 읽습니다.

• 외부 조회: 시도 후 시간 초과입니다.
• 로컬 추론: 별도 호출 결과가 있어야 확인됩니다.
• 제품 Work: 별도 Work ID·영수증을 확인해야 합니다.

확인·조치 순서:

1. 고객 네트워크 정책과 릴리스가 제공한 로컬 전용 설정이 실제로 적용됐는지 확인합니다.
2. 외부 조회의 실패, 로컬 모델 시작, 바인딩과 Work의 관찰을 각각 기록합니다.
3. 허용된 진단으로 재확인하되 정책 변경이나 외부 모델 대체는 별도 담당자의 절차를 따릅니다.

다음 단계로 돌아갈 조건: 확인한 로컬 단계의 결과만 성공으로 기록하고 외부 조회 실패는 별도로 남깁니다.

해결되지 않았을 때: 통신 범위나 모델 선택을 확인할 수 없으면 무외부 통신·로컬 Work 완료를 주장하지 않고 인계합니다.

이 사례의 지원 기록을 실제로 채우기

OS·아키텍처, 모델·런타임 버전, 요구·현재 자원, 로컬 모델 준비, 최초 종료·외부 조회 상태.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: G-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 H: Builder에 Pack 후보가 있지만 실행할 수 없음

실제 경계

Pack Builder는 Pack을 준비하고 검증하도록 돕습니다. 후보 생성, 파일 저장, 화면의 준비 상태, passkey 등록은 각각 별도 상태입니다. 어느 하나도 고객의 Pack 승인·사용 권한·실행 권한을 자동으로 만들지 않습니다.

예시 상황

운영자가 Builder에서 Pack 후보를 만들었습니다. 미리보기와 구조 검사는 통과했지만 PackrGUI의 실행 목록에 나타나지 않거나 Work 요청이 거부됩니다. “Builder에서 만들었으니 실행할 수 있다”는 결론은 성립하지 않습니다.

확인 순서

1. 이 릴리스에 Builder가 실제 제공되는지, 설치 파일의 서명·버전이 맞는지 확인합니다.
2. 후보의 검증 상태와 결함 목록을 확인합니다. 구조 검증 통과가 실행 승인과 다른지 봅니다.
3. Pack의 정확한 버전·계약·요청 능력·대상 환경을 확인합니다.
4. 고객 설치의 Pack 승인 여부와 사용 권한을 제품 상태에서 각각 확인합니다. 다른 고객 또는 설치의 승인을 재사용하지 않습니다.
5. 실행 전 사전 조건과 필요한 별도 사용자 승인 또는 passkey 절차가 있는지 확인합니다. 브라우저가 열리거나 앱으로 돌아오는 것만으로 승인이 완료된 것은 아닙니다.
6. 제품 거부 사유가 남으면 후보를 수정하거나 승인 절차를 진행하되, 거부된 Work를 다른 경로로 실행하지 않습니다.

상태별 조치

지원 요청 예시

“릴리스 [값], Builder 버전 [값], 후보 ID/버전 [공개 가능한 값], 검증 상태 [값], 승인 상태 [값], 고객 권한 상태 [값], 최초 Work 거부 [원문]입니다.” Pack 소스, 내부 계약 원문, passkey 응답은 첨부하지 않습니다.

완료·중지 기준

완료: 정확한 Pack이 이 고객 설치에 대해 검증·승인·권한 부여됐고 사전 조건을 충족합니다. 중지: 후보를 승인 Pack으로 바꿔 표시하거나 거부된 실행을 우회하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 H-1: 후보 구조 검사는 통과했지만 승인은 대기

상황: Builder가 후보 검증 PASS를 표시해 사용자가 실행 목록에서 찾습니다. 하지만 정확한 후보 리비전에 대한 승인 기록은 아직 없습니다. 준비와 사용 승인 사이의 단계가 남아 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 후보 검증: 지정 검사 범위의 성공입니다.
• 승인: 대기 상태입니다.
• 실행: Work 시작·영수증은 없습니다.

확인·조치 순서:

1. 현재 후보 ID·리비전·지문과 검증 결과가 같은 대상을 가리키는지 확인합니다.
2. 릴리스의 승인 담당자에게 변경 목적·후보 지문·검증 결과를 인계합니다.
3. 승인 후에도 현재 고객·설치 사용 권한과 사전 조건을 별도로 확인합니다.

다음 단계로 돌아갈 조건: 정확한 후보에 대한 승인·권한·사전 조건이 확인되면 실행 준비 단계로만 이동합니다.

해결되지 않았을 때: 승인이 없으면 후보를 Pack 폴더로 복사하거나 다른 계정으로 실행하지 않습니다.

상세 예시 H-2: 승인은 있지만 다른 설치의 사용 권한

상황: 한 설치에서 승인한 Pack을 다른 설치에서도 사용할 수 있을 것으로 기대합니다. 제품은 현재 설치의 사용 권한을 거부합니다. 승인 기록의 존재와 적용 범위를 나누어 확인합니다.

관찰을 이렇게 나눠 읽습니다.

• Pack 승인: 정확한 버전·대상 범위를 확인합니다.
• 현재 설치: 승인·사용 권한의 설치와 다를 수 있습니다.
• 거부: 현재 요청의 권한 결과입니다.

확인·조치 순서:

1. 현재 고객·설치·Pack 버전과 사용 권한 기록의 참조를 대조합니다.
2. 필요한 권한을 담당자가 정식 절차로 판단합니다. 다른 설치의 파일을 복사하지 않습니다.
3. 권한이 확인된 뒤 같은 대상의 사전 조건·계획을 다시 확인합니다.

다음 단계로 돌아갈 조건: 현재 설치를 대상으로 한 권한과 계획이 확인돼야 해당 Pack의 실행 절차를 진행합니다.

해결되지 않았을 때: 권한 담당자의 확인이 없으면 승인 파일의 이름·설치 ID를 바꿔 재사용하지 않습니다.

상세 예시 H-3: 승인 뒤 후보를 수정해 지문이 달라짐

상황: 검토자가 승인한 뒤 입력 선언이나 후보 파일을 수정했습니다. 이전 승인 화면은 남아 있지만 새 후보의 지문은 달라졌습니다. 새 바이트가 승인됐는지 다시 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 기존 승인: 이전 후보 지문에 대한 기록입니다.
• 현재 후보: 수정된 리비전·지문입니다.
• 현재 검증: 새 후보에 대한 결과가 필요합니다.

확인·조치 순서:

1. 수정 전후 후보 지문과 변경 목적을 보존합니다.
2. 새 후보의 검증과 승인 적용 범위를 정식 절차에서 확인합니다.
3. 현재 후보·승인·사용 권한·실행 계획의 참조를 나란히 대조합니다.

다음 단계로 돌아갈 조건: 현재 바이트를 대상으로 한 결과가 확인돼야 새 후보로 진행합니다.

해결되지 않았을 때: 이전 승인을 새 후보에 복사하거나 매니페스트 지문만 바꿔 일치시키지 않습니다.

이 사례의 지원 기록을 실제로 채우기

후보 ID·리비전·지문, 검증 대상, 승인 목적·범위, 현재 사용 권한, 사전 조건과 실제 Work 유무.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: H-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 I: 바인딩은 성공했지만 Work 영수증이 없음

실제 관찰과 의미

로컬 런타임이 바인딩돼 있어도 Work가 제출되지 않았을 수 있습니다. 런타임 준비와 Work 완료는 각각 다른 기록으로 확인합니다.

예시 상황

PackrGUI에 런타임 바인딩됨이 보입니다. 운영자는 첫 작업이 완료됐다고 생각하지만 Work 목록에는 결과가 없고 영수증도 없습니다. 또는 작업은 제출됐으나 상태가 대기/중단/롤백입니다.

확인 순서

1. 같은 고객·설치·릴리스 신원에서 Work가 실제 제출됐는지 확인합니다.
2. 요청한 Pack이나 작업의 승인·사용 권한·사전 조건이 충족됐는지 확인합니다.
3. 제품의 Work 기록에서 승인, 실행 시작, 모델 호출, 결과 검증, 최종 상태를 각각 확인합니다. 일부 단계가 없으면 그 지점이 현재 상한입니다.
4. 로컬 모델을 사용했다면 그 Work에 묶인 호출이 있는지 확인합니다. 모델이 일반적으로 응답 가능하다는 사실을 이 Work의 호출로 사용하지 않습니다.
5. 최종 상태가 성공인 경우에만 그 Work ID와 동일한 결과·영수증 위치를 확인합니다. 실패·중단·롤백은 성공 영수증이 아닙니다.
6. 영수증이 없으면 릴리스의 기록 조회 절차를 따르고 최초 누락 지점을 지원팀에 전달합니다. 수동 영수증 파일을 만들지 않습니다.

설치 목록에 packrctl이 있고 해당 설치에 인증됐다면, 상태가 불확실한 Work를 다시 실행하지 말고 조회하십시오. 자리표시자는 반환된 Work ID로 바꿉니다.

packrctl work list --limit 10 --json
packrctl work show "PASTE_RETURNED_WORK_ID" --json

허용된 계정의 목록이 비어 있어도 다른 계정이 Work를 제출한 적 없다고 증명되지는 않습니다. 보고서 파일이나 모델 응답은 제품의 타입이 정해진 Work·영수증 기록을 대신하지 못합니다.

어디서 멈췄는지 판단

예시: 런타임은 바인딩됐지만 Work 준비는 미확인

로컬 모델 별칭을 바꾼 뒤 어플라이언스에는 새 BOUND가 보이지만 Work 준비 상태는 UNKNOWN이라고 가정합니다. 설치·릴리스, 바인딩 시각, 권한과 런타임의 별도 상태, 제품이 표시한 정확한 사유, Work ID 유무를 기록하십시오. 준비가 계속 UNKNOWN이면 제출 전에 멈추고 그 값을 지원 경로로 전달합니다. 명령 반복, 상태 파일 수정, 바인딩 기록을 영수증으로 취급하는 방식은 Work 완료를 입증하지 못합니다.

현장 판단 예시: 모델 응답과 Work 결과 혼동

운영자가 모델 시험 질문에 응답을 받고 GUI에서 바인딩됨을 본 뒤 첫 Work 완료라고 보고하려 한다고 가정합니다. 이때 Work ID가 없다면 제출도 확인되지 않았습니다. ID가 있더라도 승인·실행 시작·모델 호출·결과 검증·종료와 영수증을 각각 확인해야 합니다. 아래 표는 자신의 설치에서 수행한 Work에 사용하십시오.

첫 누락 관문을 기록해 지원팀에 전달하십시오. 다른 Work의 영수증이나 수동 파일 생성으로 빈칸을 채우지 마십시오.

지원 요청 예시

“릴리스 [값], 설치 ID [값], Work ID [있으면], Pack/작업명 [공개 가능한 값], 마지막 확인 상태 [값], 최초 거부/누락 [원문], 모델 호출 확인 [예/아니요/확인 불가], 영수증 상태 [없음/있음]입니다.” 프롬프트·결과 원문은 보내지 않습니다.

완료·중지 기준

완료: 승인된 같은 Work의 성공 최종 상태, 검증된 결과와 영수증이 일치합니다. 중지: 바인딩 화면, 추정 호출, 다른 Work의 영수증으로 빈 기록을 채우지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 I-1: 모델 시험 응답은 있으나 Work ID가 없음

상황: 운영자는 모델 시험 응답과 바인딩됨 화면을 보고 첫 Work가 끝났다고 생각합니다. 제품 Work 목록에는 해당 요청이 없습니다. 모델 시험과 제품 실행을 구별할 필요가 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 모델 응답: 일반 시험 결과입니다.
• 바인딩: 현재 런타임 준비에 대한 결과입니다.
• Work: 제출된 실제 ID가 아직 확인되지 않습니다.

확인·조치 순서:

1. 허용된 현재 계정으로 제품 Work 목록을 읽고 해당 요청의 실제 제출 여부를 확인합니다.
2. ID가 없으면 제출 미확인으로 기록합니다. 다른 계정의 이력까지 없다고 일반화하지 않습니다.
3. 승인된 첫 Work가 필요하면 원래의 계획·승인 절차에서 시작하고 반환된 ID를 보관합니다.

다음 단계로 돌아갈 조건: 실제 Work의 승인·실행·검증·최종 상태·영수증을 확인하기 전에는 첫 Work 완료로 표시하지 않습니다.

해결되지 않았을 때: 제출 권한이나 지원 Pack이 없으면 모델 응답으로 영수증을 만들지 말고 준비 상태를 인계합니다.

상세 예시 I-2: 제출한 Work의 결과가 늦게 보임

상황: Work 제출 후 실제 ID를 받았지만 클라이언트 연결이 끊어졌습니다. 사용자는 같은 요청을 다시 실행하려 합니다. 먼저 반환된 ID로 현재 상태를 조회해야 중복 실행을 피할 수 있습니다.

관찰을 이렇게 나눠 읽습니다.

• 제출: 실제 반환 ID가 있습니다.
• 클라이언트: 연결이 끊겼다는 사실만 확인됐습니다.
• 실행 결과: 연결 오류만으로 실패·성공을 확정할 수 없습니다.

확인·조치 순서:

1. 동일 고객·설치·Work ID를 제품의 조회 경로로 읽습니다.
2. 대기·실행 중·실패·롤백·성공 등 실제 반환 상태와 갱신 시각을 보존합니다.
3. 성공 종료라면 같은 Work의 결과 검증과 영수증을 대조합니다. 미종료라면 제공된 대기·지원 절차를 따릅니다.

다음 단계로 돌아갈 조건: 동일 Work의 종료와 결과·영수증이 확인된 뒤 그 결과로만 처리합니다.

해결되지 않았을 때: 조회가 불가능하거나 상태가 미확인이면 다시 제출하지 않고 ID·최초 연결 오류·마지막 상태를 인계합니다.

상세 예시 I-3: 보고서는 있지만 영수증의 설치·Work가 다름

상황: 공유 폴더에서 결과 파일과 영수증을 찾았지만 여러 실행 결과가 함께 있습니다. 파일 이름이 비슷하다는 이유로 현재 Work의 완료 증거로 사용할 수 없습니다.

관찰을 이렇게 나눠 읽습니다.

• 결과 파일: 존재하지만 소속 실행은 아직 미확인입니다.
• 영수증: 고객·설치·Work 참조를 확인해야 합니다.
• 제품 기록: 현재 Work의 최종 상태와 결과 지문이 비교 기준입니다.

확인·조치 순서:

1. 반환된 Work ID의 제품 기록을 먼저 읽고 현재 결과 지문을 확인합니다.
2. 영수증의 실행·설치 참조와 제공된 검증 절차의 결과를 대조합니다.
3. 불일치 파일은 원본 상태로 보존하고 다른 실행 결과와 분리하여 담당자에게 인계합니다.

다음 단계로 돌아갈 조건: 같은 실행의 기록·결과·검증된 영수증이 일치한 경우에만 완료를 기록합니다.

해결되지 않았을 때: 영수증의 ID나 해시를 직접 고쳐 맞추지 않고 현재 Work의 미확인 상태를 유지합니다.

이 사례의 지원 기록을 실제로 채우기

반환된 Work ID, 현재 고객·설치, 마지막 상태·갱신 시각, 결과 지문, 영수증 참조·검증 결과.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: I-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기

사례 J: 새 VM에서 이전 사용자·설치의 흔적이 보임

실제 관찰과 의미

새로 배포한 VM에는 고유한 설치 신원과 호스트 신원이 있어야 합니다. 첫 설정에서 기존 조직명·관리자·접근 키가 보인다면 사용 전에 원인을 확인해야 합니다.

예시 상황

공식 이미지로 새 고객 VM을 만들었는데 설정 화면에 이전 조직 이름이나 이미 등록된 관리자처럼 보이는 항목이 있습니다. 또는 예상하지 못한 사용자 홈·접근 키·이미 사용된 설치 ID가 보입니다. 이 상태를 “초기 샘플”로 추정하고 계속 작업하지 않습니다.

확인 순서

1. Work를 시작하지 않고 외부 연결과 추가 사용자 등록을 멈춥니다.
2. 받은 이미지의 공식 릴리스 ID와 배포 방법, 새 인스턴스의 생성 시각을 기록합니다.
3. 제품이 표시하는 고객·설치 신원과 예상 값을 비교합니다. 다른 고객 데이터 내용은 열거나 복사하지 않습니다.
4. 클라우드 관리 화면에서 이 인스턴스가 의도한 공식 이미지에서 만들어졌는지만 확인합니다. 내부 디스크 파일을 탐색해 원인을 분석하지 않습니다.
5. 릴리스 지원 또는 배포 담당자에게 최초 발견 화면의 최소 정보, 이미지 ID, 설치 ID, 시각을 전달합니다. 담당자의 격리·교체 결정을 기다립니다.

결과별 조치

현장 판단 예시: 새 설치에 이전 계정 흔적

새 VM에서 의도하지 않은 사용자 홈이나 이전 설치 ID가 보이면, 그것이 비어 있는지 또는 고객 정보가 실제로 들어 있는지 직접 탐색하지 않습니다. 발견 자체가 새 이미지의 신원·접근 상태를 재검토해야 할 신호입니다. Work와 추가 사용자 등록을 중단하고 배포 이미지 ID, 새 인스턴스 ID, 발견 시각, 제품이 표시한 설치 신원만 최소한으로 기록합니다.

지원 요청 예시

“릴리스 [값], 공식 이미지 ID [값], 새 인스턴스 생성 시각 [시간대 포함], 예상 설치 ID [값], 실제 표시된 신원 종류 [고객/사용자/설치], 최초 발견 화면의 최소 설명 [값]입니다. Work나 추가 등록은 하지 않았습니다.”

다른 고객의 이름·파일 내용·키·전체 디스크 이미지는 일반 지원 티켓에 첨부하지 않습니다.

완료·중지 기준

완료: 공식 담당자가 이미지와 새 설치 신원을 독립적으로 검증하고 사용 재개를 명시합니다. 중지: 고객이 이전 파일을 삭제하거나 키를 바꿔 이미지를 정상으로 표시하지 않습니다.

비슷해 보이는 증상 세 가지를 분리하기

수정 뒤 원래 절차로 돌아가는 방법

처음 거부된 단계와 수정한 항목을 기록하고 그 단계의 현재 결과를 확인합니다. 이전에 검증한 단계는 변경의 영향을 받았을 때 다시 확인합니다. 다음 단계는 필요한 현재 증거가 있을 때만 진행합니다. 지원 요청에는 정확한 버전·시각대 포함 시각·실패 단계·사유·마지막 확인 상태·수정 내용과 재확인 결과를 넣습니다. 예시 표는 실제 원인 확정이나 실행 이력이 아닙니다.

상세 사례를 읽는 방법

아래 세 사례는 실제 현장에서 마주칠 수 있는 조건을 단계별로 설명한 교육용 현장 시나리오입니다. 예시 상태는 제품의 실제 오류 코드나 고객 장애 이력으로 취급하지 않습니다. 원인은 자신의 설치에서 관찰한 값으로 구별하십시오. 실제 실행 근거가 함께 제공된 기록은 그 기록의 범위에서만 인용합니다.

각 예시에는 상황, 관찰, 구별을 위한 확인·조치, 재개 조건과 해결되지 않았을 때의 인계를 담았습니다. 하나의 현상에 여러 원인이 가능하므로 첫 거부 뒤에 다음 단계를 무조건 수행하지 않습니다.

상세 예시 J-1: 새 VM의 첫 설정에 이전 조직이 표시됨

상황: 새 설치라고 전달받았지만 첫 설정 화면에 예상하지 않은 조직이나 관리자 표시가 있습니다. 예시 데이터일 것이라고 가정해 고객 정보를 입력하기 전에 출처를 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• VM 생성: 새 인스턴스라는 기록이 있습니다.
• 제품 표시: 예상 조직·설치와 다릅니다.
• 내용: 이전 데이터나 자격 증명을 직접 열어 조사하지 않습니다.

확인·조치 순서:

1. Work·추가 등록·고객 데이터 입력을 중단합니다.
2. 서명 이미지·인스턴스 출처·생성 시각과 제품이 표시한 신원 종류만 최소한으로 기록합니다.
3. 이미지·배포 담당자에게 인계하고 승인된 격리·교체 결정을 따릅니다.

다음 단계로 돌아갈 조건: 담당자가 이미지와 새 설치 신원을 독립 검증하고 사용 재개를 명시해야 설정으로 돌아갑니다.

해결되지 않았을 때: 이전 표시를 지우거나 사용자 디렉터리를 삭제해 새 설치처럼 만들지 않습니다.

상세 예시 J-2: 서로 다른 VM의 설치 신원이 동일함

상황: 팀이 두 VM을 만들었는데 제품 설치 ID가 같습니다. 주소와 인스턴스 이름은 서로 다릅니다. 복제·출처 문제인지 아직 확정되지 않았더라도 두 독립 설치가 맞는지 확인해야 합니다.

관찰을 이렇게 나눠 읽습니다.

• 인스턴스: 두 개의 생성 기록이 있습니다.
• 설치 ID: 동일한 값이 표시됩니다.
• 호스트 신원: 제품 설치 신원과 별도로 확인할 항목입니다.

확인·조치 순서:

1. 두 인스턴스의 작업과 추가 등록을 보류하고 각 출처·생성 기록을 분리합니다.
2. 공식 이미지에서의 새 배포인지 기존 디스크·VM 복제인지 관리 기록으로 확인합니다.
3. 설치 신원 생성·이미지 출처 검증은 담당자에게 인계하고 ID·키를 수동 변경하지 않습니다.

다음 단계로 돌아갈 조건: 각 새 설치의 고유 신원과 승인된 사용 재개를 확인한 뒤에만 독립 환경으로 사용합니다.

해결되지 않았을 때: 두 환경을 번갈아 사용하며 문제를 숨기거나 기존 승인·권한 파일을 나눠 복사하지 않습니다.

상세 예시 J-3: 교체 VM에서도 이전 상태가 반복됨

상황: 문제가 있던 VM 대신 새 인스턴스를 만들었는데 같은 이전 상태가 보입니다. 같은 이미지를 여러 번 생성하는 것만으로 원인이 해결되지는 않습니다.

관찰을 이렇게 나눠 읽습니다.

• 첫 VM과 교체 VM: 별도의 인스턴스 기록을 보존합니다.
• 이미지: 정확한 세대와 출처를 각각 대조합니다.
• 반복 현상: 원인 확정 없이 관찰 사실로 기록합니다.

확인·조치 순서:

1. 반복 생성과 고객 데이터 투입을 멈추고 두 VM의 이미지·생성 기록·신원 표시를 최소한으로 보관합니다.
2. 공급 담당자가 원본 이미지와 설치 절차를 검증하고 정확한 교체 대상을 지정하도록 인계합니다.
3. 교체 뒤에는 새 이미지 출처·설치 신원·서비스 준비를 다시 확인합니다.

다음 단계로 돌아갈 조건: 문제를 가진 입력과 구별되는 검증된 교체 출처, 고유 신원과 재개 결정이 있어야 종료합니다.

해결되지 않았을 때: 기존 Golden·원본 이미지를 사용자 임의로 수정하거나 재봉인하지 않고 원본 증거를 보존합니다.

이 사례의 지원 기록을 실제로 채우기

공식 이미지·인스턴스 출처, 생성 시각, 표시된 신원 종류, 기대 신원 일치 여부, 중단·인계 상태.

원문 상태와 해석을 분리하고, 시각에는 시간대를 포함합니다. 아래는 기록 양식이며 제품 API 요청이나 실제 실행 영수증이 아닙니다.

case: J-[1/2/3]
release / component / OS: [actual values]
observed_at: [actual time and timezone]
last_confirmed_stage: [actual observation]
first_refusal: [minimal original message, no secrets]
changed_item: [actual change or none]
recheck_result: [observed / refused / not run]
next_owner: [authorized role]

지원팀에 전체 로그·고객 데이터·키·토큰·passkey 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

설치·첫 사용 매뉴얼로 돌아가기