Part.1 · 설치와 첫 연결

문서 탐색: 설치·첫 사용 · 설치 후 도구 · 사용 용례 · 문제 해결 사례

처음 설치한다면: 목적에 맞는 시작점

모든 도구를 순서대로 설치할 필요는 없습니다. 다음 표에서 오늘 하려는 일을 하나 고르고 해당 안내부터 시작하십시오. 이 페이지를 여는 데에는 브라우저만 필요합니다. SDK 합성 예제를 실행하는 데에는 어플라이언스 계정·고객 활성화·실제 API 접속이 필요하지 않습니다.

각 도구의 상세 절은 설치 후 도구 목록에 있습니다. 도구가 필요한 단계에서만 설치합니다. 실제 연결·등록·Work가 필요한 시점에는 해당 릴리스의 승인된 경로가 따로 필요합니다.

설치 전 10분: 내 컴퓨터와 받은 파일 확인

1. 설치 대상을 구분합니다. VM 이미지는 서버용이고 PackrGUI·Builder는 사용자 PC용입니다. SDK는 연동 작업 PC에서 휴대형으로 쓸 수 있습니다. Document는 JSON 자료이며 별도 앱 설치 파일이 아닙니다.
2. OS와 CPU를 확인합니다. 아래는 읽기 전용 조회입니다. arm64/aarch64와 x86_64/AMD64는 서로 다른 패키지입니다. 현재 SDK의 기록된 조합은 macOS ARM64, Debian 13 AMD64, Windows AMD64입니다. 다른 Linux 배포판이나 Windows ARM을 같은 조합으로 간주하지 않습니다.
3. 받은 목록에서 본체·선택 의존성·예제·버전·지문·서명 유무·네이티브 전제 조건을 확인합니다. SDK의 Rust 세트는 선택 구성이며 온라인 환경의 기본값을 바꾸지 않습니다.
4. 빈 작업 위치를 정합니다. 설치 파일 원본, 해제한 프로그램, 수정할 입력, 실행별 결과를 분리합니다. 회사 정책상 허용된 개인 폴더를 사용하고 기존 폴더를 덮어쓰지 않습니다.
5. 필수 연결 정보가 필요한 경로라면 관리자로부터 전달받습니다. 주소만으로는 충분하지 않습니다. 계정·기기 등록 방식, 기대하는 조직·설치 신원, TLS 서버명과 지원 연락 경로까지 확인합니다.

# macOS 터미널에서만
sw_vers
uname -m
# Linux 터미널에서만
cat /etc/os-release
uname -m

# Windows PowerShell
$PSVersionTable.PSVersion
(Get-CimInstance Win32_OperatingSystem).Caption
(Get-CimInstance Win32_ComputerSystem).SystemType

파일 종류를 보고 올바른 절차 선택하기

이 문서의 범용 .pkg/.exe/.deb 파일명은 해시 명령 설명용입니다. 실제 SDK 파일을 그 이름으로 찾지 마십시오. 현재 로컬 운영자판에서는 현재 SDK 패키지 표가 본체·의존성의 실제 파일 링크와 지문을 제공합니다. 다른 구성요소는 별도의 해당 릴리스 제공 목록을 확인합니다. 존재하지 않는 포털·다운로드 링크·서명 상태를 추측하지 않습니다.

명령을 처음 복사할 때

• macOS의 터미널·Linux 셸에는 bash 예시를, Windows PowerShell에는 powershell 예시를 사용합니다. $나 PS C:\> 같은 프롬프트는 명령이 아니며 복사하지 않습니다.
• /absolute/path/..., C:\absolute\path\..., 대괄호 입력란은 내가 받은 실제 값으로 먼저 바꿀 자리입니다. 따옴표는 유지합니다. 경로에 공백이 있으면 특히 필요합니다. Unix의 ./bin/...과 Windows의 .\bin\...을 바꾸어 쓰지 않습니다.
• install_root, $installRoot 같은 변수는 해당 준비 절을 실행한 같은 셸에서만 존재합니다. 터미널을 새로 열면 아래의 재개 절차로 다시 지정합니다. 폴더명·대소문자·파일 확장자 .json.txt를 확인합니다.
• 한 블록 안에서도 한 단계씩 실행하고 결과를 읽습니다. 문서의 예상 결과는 실제 성공 로그가 아닙니다. 오류가 나오면 이어 붙인 나머지 명령을 실행하지 않습니다.
• 예제 원본을 보존하고 사본을 UTF-8로 저장합니다. Windows PowerShell 5.1의 기본 > 또는 Out-File은 UTF-16일 수 있습니다. JSON 입력은 UTF-8 편집기를 사용하고 저장 인코딩을 확인합니다.

빈 폴더를 어디에 만들지 이해하기

VibePackr-SDK-install-01/
  sdk/             압축 해제한 본체; bin, docs, examples
  dependencies/    선택 의존성 세트; 원본 검증 입력 유지
  inputs-02/       수정할 전체 input.json 사본
  runs/
    custom-01/     첫 성공 후 생기는 결과
    mcp-01/        별도 MCP 결과
    custom-api-candidate-02/  수정 입력의 새 결과

위는 폴더 관계 설명입니다. 실제 생성 명령은 SDK 절에 있습니다. runs 부모는 준비하되 custom-01 같은 최종 후보 폴더는 SDK가 만들게 둡니다. GAPE도 새 출력 경로를 사용합니다. Helper의 로그 보관 폴더와 Builder의 제품 관리 후보는 별개입니다.

어디까지 끝났는지 기록하고 다음에 이어 하기

설치·연결·후보 생성·실제 Work를 한 번에 “완료”라고 적지 않습니다. 각 연습이 끝날 때 날짜, 도구 버전·경로, 입력 지문, 실제 명령 또는 화면 작업, 결과 위치, 마지막 성공 단계와 남은 담당자를 적습니다. 문제 해결에는 이 기록이 출발점입니다.

다시 시작할 때 받은 패키지와 보관된 결과를 지우지 마십시오. SDK의 경로 재개 예시는 SDK 절에 있고, 다른 도구도 입력·출력의 절대 경로를 다시 선택합니다. 애매한 실행 결과가 남으면 먼저 기존 Work/요청 ID를 조회하고, 중복 실행을 새 시도로 해결하지 않습니다. 막힌 단계는 문제 해결 색인의 시작 분류표로 이동합니다.

이 문서를 사용하는 방법

이 문서는 고객의 담당자가 파일 수령부터 첫 Work 결과 확인까지 직접 진행하도록 돕습니다. 제품이 표시하는 상태와 해당 릴리스의 서명된 매니페스트가 최종 기준입니다. 예시와 일반 운영체제 명령이 제품의 거부 결정이나 릴리스 문서를 대신하지 않습니다.

• 담당자: 어플라이언스 설치 관리자, PackrGUI 사용자, 선택적으로 Builder 운영자. 설치·권한 부여·Pack 승인 담당자가 다를 수 있습니다.
• 준비물: 해당 릴리스의 전달 목록과 서명 검증 안내, 지원 환경 표, 고객 조직의 설치 권한, 네트워크·인증 정보, 릴리스별 지원 연락 경로. 암호·비밀키를 지원 요청에 첨부하지 마십시오.
• 완료 기준: 같은 릴리스와 설치 신원에 대해 파일 검증, 서비스 준비, 관리자 범위, 인증된 연결, 검증된 런타임 바인딩, 승인된 실제 Work, 결과와 영수증을 각각 확인합니다. 한 단계의 성공이 다음 단계의 성공을 뜻하지 않습니다.
• 중지 기준: 파일 지문·서명 불일치, 예상하지 못한 호스트 신원, 다른 고객·설치 신원, 권한 거부, 상태 무결성 경고가 나오면 다음 단계로 넘어가지 마십시오. 원본 메시지와 시각을 기록하고 릴리스별 지원 경로를 이용하십시오.

1. 전달 파일과 대상 환경 확인

1. 공식 포털이 게시된 릴리스라면 setup.vibepackr.com에서 시작합니다. 오프라인 설치라면 전달받은 Start_Setup.html을 엽니다. 포털과 오프라인 안내의 릴리스 식별자와 구성요소 목록이 같은지 확인합니다. 포털이 열리지 않는 상황은 제품 VM 장애와 구별하십시오.
2. 전달 목록에서 어플라이언스 이미지, 해당 운영체제용 PackrGUI, 선택 구성요소인 Enterprise Pack Builder와 Additional Packs의 실제 제공 여부를 확인합니다. 소개 페이지에 표시된 구성요소라도 릴리스 목록에 없으면 설치하지 않습니다.
3. 릴리스 매니페스트의 버전·플랫폼·SHA-256과 받은 파일을 대조하고, 동봉된 공식 절차로 서명을 검증합니다. 지문은 손상 여부를 확인하지만 서명 검증을 대신하지 않습니다. 일반 파일 지문 확인 예시는 macOS의 shasum -a 256 파일명, Linux의 sha256sum 파일명, Windows PowerShell의 Get-FileHash -Algorithm SHA256 파일명입니다. 파일명이 공백을 포함하면 각 셸의 인용 규칙을 따릅니다.
4. 릴리스별 호환성 표에서 대상 클라우드 또는 가상화 환경, CPU 아키텍처, 메모리·디스크, 네트워크, 인증 경로와 지원 런타임을 확인합니다. 로컬 7B 모델을 사용할 계획이라면 모델 실행에 필요한 자원을 별도로 확인하십시오. 최소 사양은 전달된 호환성 표를 따르십시오.
5. 기록할 값: 릴리스 ID, 설치 파일 이름과 지문, 이미지 식별자, 대상 플랫폼, 파일 검증 결과. 불일치 파일을 이름만 바꾸거나 다른 플랫폼 패키지로 대체하지 마십시오.

다음 단계로 진행할 조건: 전달 목록에 있는 정확한 파일의 서명과 지문이 맞고 대상 환경이 지원 목록 안에 있습니다.

받은 설치 파일을 확인하는 실제 명령 예시

이번 릴리스의 서명된 목록에 있는 파일명과 SHA-256을 사용하십시오. 아래 명령은 운영체제의 읽기 전용 파일 확인 예시입니다. 예시 파일명을 받은 파일명으로 바꾸고, 별도로 릴리스의 서명 확인 절차도 완료하십시오. 이전 안내서의 지문을 재사용하지 마십시오.

# macOS 터미널
shasum -a 256 "VibePackr-installer-for-this-platform.pkg"
# Linux 셸
sha256sum "VibePackr-installer-for-this-platform.deb"

# Windows PowerShell
Get-FileHash -Algorithm SHA256 "VibePackr-installer-for-this-platform.exe"

판정 예시: 매니페스트에는 A1..., 로컬 명령 결과에는 B2...가 표시됩니다. 설치 전에 멈추고 정확한 파일명과 두 지문을 남겨 전달 담당자에게 올바른 서명 파일을 요청하십시오. 파일명을 바꿔도 지문은 바뀌지 않습니다.

2. 고객 환경에 새 어플라이언스 배포

1. 전달된 릴리스가 지정한 서명 어플라이언스 이미지로 새 인스턴스를 배포합니다. 다른 버전의 이미지나 기존 VM을 복사해 설치 파일로 사용하지 마십시오.
2. 인스턴스 생성 후 첫 부팅이 끝날 때까지 기다립니다. 클라우드 콘솔의 실행 중은 VM 전원이 켜졌다는 뜻입니다. 제품의 서비스 준비는 제품 상태 화면 또는 릴리스별 진단으로 별도 확인합니다. 초기화 중에는 접속을 반복하기보다 공식 대기·상태 절차를 따르십시오.
3. 제품이 새로 생성한 설치 신원, 고객 조직, 서비스 엔드포인트와 연결 방법을 기록합니다. 두 독립 인스턴스가 같은 설치 신원이나 호스트 신원을 보이면 복제 상태를 의심하고 사용을 멈춥니다.
4. 관리자 또는 클라이언트의 최초 접속에서 표시되는 호스트 신원을 공식 릴리스의 검증 경로와 대조합니다. 예전 VM의 키를 새 VM에 재사용하거나 신원 경고를 무시하지 마십시오.

다음 단계로 진행할 조건: 첫 부팅이 완료되고 제품 서비스가 준비 상태이며, 이 인스턴스의 고유 설치 신원과 인증된 접근 경로가 확인됩니다.

3. 최초 관리자 등록과 허용 범위

1. 고객 환경 내부의 Customer Setup UI 또는 릴리스가 지정한 관리자 절차를 엽니다. 로컬 운영체제 로그인만으로 제품의 Appliance Administrator 권한이 생기지는 않습니다.
2. 실제 관리자가 고객·설치·지원 런타임 범위를 확인하고 제품이 요구하는 방식으로 초기 등록을 완료합니다. 자동 바인딩은 이 승인 범위 안에서 동작합니다. 어떤 환경 변화도 무조건 승인하는 기능이 아닙니다.
3. 관찰과 런타임 바인딩에 필요한 최소 권한, 적용 대상과 유효기간을 제품 화면에서 확인합니다. 계정 이름이 맞아도 고객·설치 신원이 다르면 계속 진행하지 않습니다.
4. 릴리스가 대화형 터미널 입력을 요구하는 경우, 복사한 명령을 비대화형 원격 스크립트나 파이프로 보내지 마십시오. 제품이 지정한 로컬 위자드 또는 대화형 세션에서 관리자가 직접 확인합니다.
5. 등록 후 관리자 상태를 읽기 전용으로 다시 확인합니다. 저장소 접근 오류나 Permission denied가 나오면 임의로 소유권·권한·잠금 파일을 고치지 말고 정확한 오류를 지원 경로로 전달합니다.

다음 단계로 진행할 조건: 제품이 현재 설치 신원에 대해 관리자 역할·허용 범위·유효기간을 확인합니다.

4. 로컬 런타임 감지와 자동 바인딩

1. 릴리스가 지원하는 로컬 런타임과 모델을 고객 환경에 준비합니다. 예를 들어 제공된 호환성 표에 Ollama와 Qwen 모델이 포함돼 있다면 해당 버전과 자원 요구사항을 확인합니다. 이 예시를 모든 설치의 기본 모델로 간주하지 마십시오.
2. Packr 또는 PackrGUI의 감지·설정 위자드에서 감지됨 → 검증됨 → 바인딩됨을 구별합니다. Core가 관찰한 설치·고객·런타임 신원과 관리자 범위를 검증한 뒤에만 바인딩을 적용합니다. 단순히 모델 파일이 있거나 런타임 프로세스가 실행된 것만으로 바인딩되지는 않습니다.
3. 현재 바인딩의 런타임 종류, 모델 참조, 설치 신원, 상태와 제품이 기록한 시각을 확인합니다. 바인딩 성공은 모델 추론 또는 Work 성공의 증거가 아닙니다.
4. 런타임을 교체·재시작하거나 모델 별칭이 바뀌었다면 새 관찰을 기다리고 제품이 다시 검증한 바인딩을 확인합니다. 이전 바인딩 화면만 보고 새 런타임을 사용하지 마십시오.
5. 허용 범위를 벗어난 변경이나 여러 모델 중 대상을 특정할 수 없는 상태는 위자드의 거부 사유에 따라 관리자가 해결합니다. 제품 상태 저장소를 직접 편집하거나 기존 바인딩을 강제로 재사용하지 마십시오.
6. 오프라인 운영이 필요하면 모델이 이미 로컬에 있고 릴리스가 지정한 로컬 전용 네트워크 설정이 적용되는지 확인합니다. 네트워크 정책과 제품의 실제 통신 기록을 확인하지 않고 외부 통신이 없었다고 판단하지 마십시오.

다음 단계로 진행할 조건: 제품이 현재 설치에 대해 지원 런타임과 모델의 바인딩을 검증된 상태로 표시합니다.

5. PackrGUI, 헤드리스 클라이언트와 Builder 연결

1. 릴리스 매니페스트가 지정한 해당 운영체제용 PackrGUI를 설치합니다. macOS, Windows, Linux 패키지는 서로 대체할 수 없습니다. 운영체제의 보안 경고가 뜨면 서명 상태와 전달된 설치 안내를 확인하고 보안 검사를 우회하지 마십시오.
2. 릴리스가 지정한 주소·네트워크·인증 경로로 고객 어플라이언스에 연결합니다. 제품 화면에서 서버가 응답하는지, 인증이 되었는지, 고객·설치 신원이 같은지 각각 확인합니다. 화면이 열리는 것만으로 인증된 연결은 아닙니다.
3. GUI 없이 운영한다면 릴리스가 지정한 헤드리스 CLI 또는 서비스 경로를 별도로 검사합니다. GUI 연결 성공으로 헤드리스 준비나 Work 권한을 대신 증명할 수 없습니다.
4. Enterprise Pack Builder가 실제 릴리스 구성요소일 때만 별도 설치·권한 절차를 따릅니다. Builder는 Pack 후보의 준비·검증을 지원합니다. 후보 생성이 Pack 승인·사용 권한·실행을 뜻하지 않습니다.
5. 릴리스에서 Safari 웹 passkey 확인을 요구하면 정식 HTTPS 주소와 등록된 관리자 절차를 사용합니다. passkey 등록과 매 작업 승인은 별개입니다. 브라우저 창이 열리거나 앱으로 돌아왔다는 사실만으로 Core 승인을 완료한 것으로 판단하지 마십시오. 등록이 거부되면 다른 계정의 자격 증명을 빌리지 않습니다.

연결 이후의 작업은 설치 후 도구 안내서를 따르십시오. Builder, GAPE, Integration Helper, SDK Engine, Contract & Document의 설치 위치와 사용 순서를 확인할 수 있습니다. 전체 관계를 보여주는 Non-SI 아키텍처 그림도 포함돼 있습니다.

다음 단계로 진행할 조건: 사용할 각 클라이언트 경로의 인증·설치 신원·허용 기능을 제품에서 확인합니다.

6. 첫 Work 실행과 영수증 확인

1. 릴리스가 지정한 지원 Pack 또는 시험 Work를 선택합니다. Pack의 계약·범위·사전 조건·승인·사용 권한을 실행 전에 확인합니다. Builder가 만든 후보를 승인된 Pack처럼 실행하지 않습니다.
2. 제품이 표시하는 실행 계획과 대상 환경을 확인하고, 고객이 승인한 경로로 한 건을 실행합니다. 실제 Work는 설치, 연결, 런타임 바인딩과 별도 단계입니다.
3. 로컬 모델을 사용했다면 해당 Work 기록에서 모델 호출이 실제로 일어났는지 확인합니다. 런타임이 바인딩됨으로 보이거나 모델이 응답 가능해도 Work 호출이 없을 수 있습니다.
4. 최종 상태, 결과 검증, Work 기록과 영수증을 같은 설치·릴리스 신원으로 대조합니다. 실패, 중단, 롤백, 검증 대기 상태는 성공으로 기록하지 않습니다.
5. 첫 사용 완료를 선언하기 전에 담당자가 아래 확인표를 채웁니다. 확인 안 됨은 실패와 구별해 적되 완료로 표시하지 않습니다.

실제 운영 용례

설치를 마친 뒤 어떤 기능을 어떤 순서로 확인할지는 사용 용례 색인에서 시작하십시오. 새 설치, 런타임 변경과 자동 재바인딩, PackrGUI·헤드리스 분리, Builder 후보, 첫 Work를 각각 담당자·선행 조건·증거·실패 분기까지 풀어 설명합니다. 사례 A~J는 증상이 발생했을 때 찾아보는 문제 해결 문서입니다.

7. 문제 해결 사례

다음은 설치와 사용 중 나타날 수 있는 상황별 안내입니다. 제품의 실제 오류 문구는 버전과 플랫폼에 따라 다를 수 있습니다. 각 사례의 안전한 조치까지만 직접 수행하고, 신원·권한·상태 무결성 오류는 지원 경로로 넘기십시오. 각 제목의 링크에서 상황 예시, 순서별 확인, 결과별 분기, 지원 요청 예시와 완료·중지 기준을 자세히 확인하십시오. 증상에 맞는 사례를 고르기 어렵다면 문제 해결 색인부터 보십시오.

사례 A — VM은 켜졌는데 제품은 준비되지 않음

• 증상: 클라우드 콘솔에는 VM이 실행 중이나 제품 상태는 초기화 중이거나 서비스 준비가 아닙니다.
• 먼저 확인: 첫 부팅 완료 표시와 제품 상태를 확인합니다. 필요한 초기화 구성요소가 없다는 오류가 표시되면 이미지 ID와 메시지를 기록합니다.
• 조치: 릴리스가 허용한 대기와 읽기 전용 진단을 한 번 수행합니다. 요구 구성요소가 빠졌거나 준비 상태가 계속 나오지 않으면 이미지 ID와 상태를 지원팀에 전달합니다. 고객 VM에서 임의 패키지를 설치하거나 서비스 상태 파일을 지우지 마십시오.

사례 B — SSH 또는 앱이 예전과 다른 호스트를 표시함

• 증상: 호스트 키 변경 경고, 인증된 서버 신원 불일치, 예상하지 못한 설치 신원.
• 먼저 확인: 접속하려는 인스턴스와 이전 인스턴스가 다른지, 주소·조직·설치 ID가 맞는지 확인합니다. 호스트 키가 바뀌었다면 이전 신뢰 기록을 자동으로 재사용하지 않습니다.
• 조치: 접속을 멈추고 릴리스의 공식 독립 검증 경로로 현재 호스트 신원을 확인합니다. 검증 전에 경고를 무시하거나 호스트 검사 옵션을 끄거나 저장된 키를 임의 교체하지 마십시오.

사례 C — 접속 거부가 네트워크 문제인지 인증 문제인지 불분명함

• 증상: 부팅 직후 연결 시간 초과, 로그인 실패, 또는 클라이언트는 열리지만 제품은 미인증 상태.
• 먼저 확인: VM/서비스 준비 → 공식 주소와 네트워크 경로 → 현재 계정 및 인증 방법 → 제품의 고객·설치 신원 순서로 확인합니다. 접속 시간 초과와 로그인 거부는 조치가 다릅니다.
• 조치: 릴리스가 지정한 재확인 절차를 따릅니다. 다른 사람의 키나 계정으로 우회하지 말고, 실패 단계·시각·정확한 메시지를 기록합니다.

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

• 증상: 명령을 원격 스크립트나 파이프로 보냈을 때 실제 터미널 또는 사용자 확인이 필요하다는 거부가 나옵니다.
• 먼저 확인: 릴리스가 대화형 로컬 위자드 또는 터미널을 요구하는지 확인합니다.
• 조치: 지정된 대화형 절차에서 실제 관리자가 직접 확인합니다. 확인 단계를 자동 입력으로 흉내 내지 마십시오. 등록 후 제품의 역할·범위가 기록됐는지 다시 읽습니다.

사례 E — 관리자 등록 후 접근 오류

• 증상: 관리자는 등록됐지만 이후 관찰·바인딩이 Permission denied 또는 저장소 접근 오류로 멈춥니다.
• 먼저 확인: 제품이 표시한 거부 코드와 발생 단계, 서비스 준비 및 설치 신원을 읽기 전용으로 확인합니다. 저장소 접근 문제인지 역할·범위 거부인지 구분합니다.
• 조치: 제품 상태 파일이나 OS 권한을 임의로 바꾸지 않습니다. 해당 릴리스의 수정 여부를 확인하고 지원팀에 정확한 오류·버전을 전달합니다.

사례 F — 런타임은 보이는데 바인딩되지 않음

• 증상: 로컬 모델이 설치되고 런타임이 실행 중인데 제품은 감지됨 또는 거부됨만 표시합니다.
• 먼저 확인: 지원 모델·런타임, 설치 신원, 관리자 승인 범위, Core의 검증 상태와 거부 사유를 봅니다. 모델 별칭·런타임 주소를 바꿨다면 새 관찰 이후 상태인지 확인합니다.
• 조치: 범위 안의 환경이라면 릴리스 위자드가 지정한 재관찰 절차를 따릅니다. 범위 밖 또는 모델 선택이 모호하면 관리자에게 명시적 조치를 요청합니다. 데이터베이스를 수정해 BOUND로 표시하지 마십시오.

사례 G — 로컬 모델을 사용하려는데 메모리 또는 네트워크가 부족함

• 증상: 로컬 모델이 시작되지 않거나, 오프라인 환경에서 모델 다운로드·메타데이터 확인이 시간 초과됩니다.
• 먼저 확인: 릴리스의 모델별 메모리 요구사항, 이미 설치된 로컬 모델, 고객의 외부 통신 정책을 확인합니다. 바인딩 상태와 Work 실행 상태를 각각 확인하십시오.
• 조치: 지원 사양에 맞는 자원을 준비하고, 오프라인 운영이면 릴리스가 제공하는 로컬 모델 준비 경로를 사용합니다. 실패한 외부 요청을 추론 성공이나 무외부 통신으로 보고하지 않습니다.

사례 H — Pack 후보는 있는데 실행할 수 없음

• 증상: Builder에서 후보가 보이지만 Work 목록에 승인된 Pack으로 나오지 않거나 실행이 거부됩니다.
• 먼저 확인: 후보의 검증 상태, 승인 여부, 고객 권한, 계약 범위, 사전 조건을 각각 확인합니다.
• 조치: 제품의 승인 절차를 따릅니다. Builder 화면의 준비됨을 실행 허가로 해석하지 마십시오.

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

• 증상: 런타임 상태는 바인딩됨이지만 결과나 영수증을 찾을 수 없습니다.
• 먼저 확인: Work가 실제로 제출·승인·실행됐는지, 최종 상태가 성공·실패·중단·롤백 중 무엇인지 확인합니다. 바인딩 화면만으로 영수증이 생성되지는 않습니다.
• 조치: 릴리스가 지정한 첫 Work 절차와 기록 위치를 따릅니다. 과거 바인딩 기록을 Work 영수증으로 대신하지 마십시오.

사례 J — 이미지 또는 복제 VM에 이전 사용자의 흔적이 보임

• 증상: 새 고객 VM에서 예상하지 못한 사용자 홈, 접근 키, 기존 설치 신원이나 설정이 보입니다.
• 먼저 확인: 설치에 사용한 이미지 식별자와 새 인스턴스 여부만 확인합니다. 예상하지 못한 이전 사용자 흔적이 보이면 사용을 멈춥니다.
• 조치: 해당 VM에서 작업을 시작하지 말고 배포 담당자와 지원팀에 알립니다. 기존 사용자의 파일을 고객이 직접 지워서 이미지를 승인 상태로 만들지 마십시오.

8. 변경·복구·지원 요청

1. 런타임, 모델, 네트워크, 고객·설치 범위를 바꾸면 기존 바인딩을 전제로 작업하지 말고 새 관찰 → Core 검증 → 새 바인딩 → 필요한 Work 재확인 순서로 확인합니다. 범위 밖 변경은 관리자 승인 절차를 거칩니다.
2. 실패가 반복되면 같은 명령을 무한 재시도하지 마십시오. 최초 오류, 해당 릴리스의 지원 절차, 변경 직전 상태를 기록합니다. 복구는 릴리스가 제공한 경로에서만 수행하고, 제품 내부 상태·키·영수증을 직접 수정하지 않습니다.
3. 지원 요청에는 릴리스와 구성요소 버전, 운영체제, 단계, 화면의 상태·거부 코드, 발생 시각과 시간대, 재현 순서, 수행한 안전한 조치, 영향 범위를 포함합니다. 고객 데이터·원문 프롬프트·비밀번호·비밀키·passkey 응답·전체 로그는 보내지 말고 지원팀이 지정한 최소 공개 경로를 따릅니다.
4. 긴급 중지: 서명·호스트 신원 불일치, 다른 고객/설치 ID, 권한 확대 의심, 이전 사용자 흔적, 상태 무결성 경고가 있으면 설치나 Work를 멈추고 지원팀에 첫 증거를 전달합니다.

설치 기록과 지원 자료

설치 담당자는 릴리스 ID, 이미지 ID, 실제로 설치한 플랫폼별 파일명과 지문, 지원 환경 확인 결과, 최초 관리자 범위, 인증된 연결 상태와 현재 런타임 바인딩을 기록하십시오. Work를 실행했다면 같은 설치·Work ID에 연결된 최종 상태, 결과 검증과 영수증 위치도 남깁니다.

macOS·Windows·Linux 클라이언트와 헤드리스 경로는 각각 별도로 확인하십시오. 한 플랫폼에서 연결됐더라도 다른 플랫폼의 설치·인증·권한을 확인해야 합니다. 화면과 명령이 이 안내서의 예시와 다르면 전달된 릴리스별 지침을 따르고, 제품의 실제 메시지와 수행한 단계를 지원 요청에 적으십시오. 고객 데이터와 비밀값은 제외합니다.

온라인·폐쇄망 환경과 구성요소별 작업 지도

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

운영 변경 뒤 확인할 것

클라이언트 업데이트는 해당 클라이언트의 연결·인증·설치 신원을, 런타임 변경은 새 관찰·검증·바인딩을, Pack 변경은 정확한 버전·신뢰·현재 사용 권한·사전 조건을 다시 확인합니다. 변경 전 기록과 복구 대상은 보존합니다. 문제가 생기면 처음 달라진 관찰을 기록하고 그 구성요소의 절차로 돌아갑니다.

추가 Pack은 제공된 릴리스·고객·설치 범위에 맞는 파일과 등록 절차를 사용합니다. 임의 폴더 복사나 후보 파일명 변경으로 등록·승인을 대신하지 않습니다. 처음 적용할 때도 승인된 계획과 후조건 검증·영수증을 확인합니다. 제거·되돌림은 해당 Pack이 선언한 복구 절차와 현재 권한을 따릅니다.

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

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

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

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

목적: [예: 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의 성공으로 복사하지 않습니다.

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

상황별 시작점

읽는 방법

각 용례는 상황 → 선행 조건 → 실제 진행 순서 → 실패 분기 → 완료 증거로 구성했습니다. 여러 증상이 동시에 보이면 마지막으로 확인된 상태부터 선택하십시오. 오류 해결은 사례 색인에서 증상별로 찾을 수 있습니다. 지원 요청에는 오류 원문과 릴리스·설치 신원처럼 최소 정보만 넣고 고객 데이터·비밀값은 제외하십시오.

담당자와 산출물로 용례를 선택하기

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

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

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

처음 사용하는 도구: 첫 결과까지의 체크리스트

아래 각 도구 안내서의 첫 실습부터 읽으십시오. 명령줄 도구는 받은 실행 파일의 절대 경로를 지정하므로 전역 PATH 등록이 필수는 아닙니다. GUI 앱은 제공된 설치 방법으로 열고 릴리스별 화면 이름을 사용합니다. 없는 메뉴나 다운로드 주소를 추측하지 않습니다.

SDK의 선택 Rust 세트는 다른 앱의 설치 프로그램이 아닙니다. 모든 도구에 Rust 설치를 요구하지 않습니다. 기존 구성의 연결을 확인하는 사람은 새 VM 생성·초기 관리자 등록을 반복하지 않습니다.

전체 구성이 연결되는 방식

이 그림은 고객이 환경과 운영을 소유하고, 연동 도구가 이해·준비·선언을 도우며, 제품이 실행을 통제하는 관계를 보여줍니다. 이미지를 별도 탭으로 열면 확대할 수 있습니다. 실제로 설치할 수 있는 도구와 지원 버전은 전달받은 구성요소 목록에서 확인하십시오.

필요한 도구 확인

필요한 도구를 아래 표에서 고르십시오. 로컬 SDK·문서 준비만 할 때는 어플라이언스 설치가 선행 조건이 아닙니다. 각 구성요소의 제공 여부, 플랫폼, 버전과 설치 파일은 함께 전달된 목록을 기준으로 확인합니다. 목록에 없는 도구는 다른 릴리스의 파일로 대체하지 마십시오.

다음 작업 선택

설치 세트에 필요한 구성

Non-SI 설치 세트에서는 고객이 Start_Setup.html에서 이 안내서까지 온라인 환경과 오프라인 환경 모두에서 이동하고, 어플라이언스·고객 워크스테이션 플랫폼·Builder·GAPE·Integration Helper·SDK 인터페이스 또는 Engine·Contract & Document 템플릿의 정확한 설치 구성요소를 확인할 수 있어야 합니다. 하나의 버전 세트 안에 플랫폼별 설치 파일을 분리해 제공할 수 있지만, 각 항목의 지문·호환성·선행 조건·설치 담당자를 표시해야 합니다. 해당 릴리스에서 제공되지 않는 항목은 그 사실과 대체 절차를 분명히 안내합니다. 문서 링크나 과거 구현만으로 설치 가능한 제품을 대신하지 않습니다.

SDK Engine은 고객의 연동 작업대에 별도로 설치합니다. 해당 운영체제용 설치 파일, 지원 어플라이언스 버전과 설치·제거 방법은 SDK Engine 안내서와 전달 목록에서 확인하십시오.

받은 파일이 목록과 다르거나 서명 검증이 실패하면 설치를 멈추고 공급자의 지원 경로에 문의하십시오. 플랫폼별 목록에 있는 검증된 파일만 설치합니다.

권장 순서

1. 어플라이언스에 연결하는 작업이라면 설치·첫 사용을 인증된 클라이언트 연결과 검증된 런타임 바인딩까지 진행하십시오. 로컬 SDK 합성 예제·Document 준비는 해당 도구의 첫 실습에서 바로 시작합니다. 도구를 열기 전에 정확한 릴리스 구성요소 목록을 확인합니다.
2. 특정 리비전의 아키텍처 확인이 필요하면 GAPE 관찰 결과와 한계를 검토합니다. 도표를 승인으로 해석하지 않습니다.
3. Document로 작업을 설명하고 공급자가 게시한 정확한 Contract·어댑터 참조를 확보합니다. Integration Helper로 지원되는 입력 범위의 후보를 검사·준비합니다.
4. 해당 릴리스가 이 대상의 SDK 인터페이스나 Engine을 제공하면 게시 리비전을 확인하고 지정된 검증·패키징 절차를 따릅니다. 릴리스 목록에 없다면 이 경로에서 멈춥니다. 인포그래픽이나 이전 SDK 산출물만 보고 현재 제공 기능으로 간주하지 않습니다.
5. 기존 지원 Pack으로 해결할 수 없으면 Builder에서 후보를 준비합니다. 후보 검증·승인·사용 권한·Work 실행을 별도 단계로 기록합니다.
6. 실제 작업은 첫 Work 안내서에 따라 진행하고 최종 영수증을 확인합니다. 준비 산출물은 영수증을 대신하지 않습니다.

공통 지원 요청 기록

릴리스·구성요소 버전, 고객·설치 신원, 입력 리비전 또는 후보 ID, 표시된 상태·사유, 마지막으로 증명된 단계와 다음 조치를 기록하십시오. 개인키·자격 증명·고객 내용·원문 프롬프트·내부 엔지니어링 내보내기는 제외합니다. 신원·서명·권한·상태 무결성이 다르면 중지합니다.

온라인·폐쇄망 환경과 구성요소별 작업 지도

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

운영 변경 뒤 확인할 것

클라이언트 업데이트는 해당 클라이언트의 연결·인증·설치 신원을, 런타임 변경은 새 관찰·검증·바인딩을, Pack 변경은 정확한 버전·신뢰·현재 사용 권한·사전 조건을 다시 확인합니다. 변경 전 기록과 복구 대상은 보존합니다. 문제가 생기면 처음 달라진 관찰을 기록하고 그 구성요소의 절차로 돌아갑니다.

추가 Pack은 제공된 릴리스·고객·설치 범위에 맞는 파일과 등록 절차를 사용합니다. 임의 폴더 복사나 후보 파일명 변경으로 등록·승인을 대신하지 않습니다. 처음 적용할 때도 승인된 계획과 후조건 검증·영수증을 확인합니다. 제거·되돌림은 해당 Pack이 선언한 복구 절차와 현재 권한을 따릅니다.

설치·첫 사용 안내서로 돌아가기

왜 이 사례가 중요한가

클라우드 콘솔에는 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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

왜 이 사례가 중요한가

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

예시 상황

어제 접속한 주소로 다시 연결했는데 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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

왜 이 사례가 중요한가

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

예시 상황

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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 관찰과 의미

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

예시 상황

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

확인 순서

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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 관찰과 의미

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

예시 상황

관리자 등록은 성공으로 보였습니다. 그러나 런타임을 관찰하려는 순간 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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 관찰과 의미

로컬 모델을 찾는 단계와 현재 설치에 바인딩하는 단계는 별개입니다. 모델 별칭이나 런타임 주소를 바꾼 뒤에는 새 바인딩 결과를 확인하고 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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 관찰과 의미

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

예시 상황

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

확인 순서

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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 경계

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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 관찰과 의미

로컬 런타임이 바인딩돼 있어도 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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

실제 관찰과 의미

새로 배포한 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 응답을 붙이지 않습니다. 문의 뒤에도 원본 결과를 보존하고, 조치가 권한·신원·배포 범위를 바꾸면 해당 담당자의 정식 절차로 이어갑니다.

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

운영 목적과 선행 조건

전달받은 어플라이언스 이미지를 새 VM으로 배포하고 제품이 만든 설치 신원에 로컬 Appliance Administrator를 등록합니다. 배포 전에 구성요소 목록, 서명 검증 절차, 지원 환경 표와 조직의 배포 승인을 준비하십시오.

예시 대화

설치 담당자가 “VM 상태가 실행 중입니다. 이제 GUI를 연결해도 되나요?”라고 묻습니다. 관리자는 “제품의 첫 부팅과 서비스 준비가 별도로 확인되어야 합니다. 설치 신원도 새로 생성됐는지 확인하겠습니다”라고 답합니다. 이 구분이 첫 번째 관문입니다.

실행 순서와 남길 기록

1. 서명 또는 지문이 다르면 설치를 시작하지 않습니다. 파일명 변경으로 불일치를 가리지 않습니다.
2. VM 전원이 켜져도 서비스 준비 상태가 나오지 않으면 첫 부팅 사례를 따릅니다.
3. 접속 시 호스트 신원 경고가 나오면 호스트 신원 사례로 이동합니다. 확인 전 신뢰를 갱신하지 않습니다.
4. 관리자 확인을 비대화형 스크립트로 대체하지 않습니다. 등록 거부는 대화형 등록 사례에서 분류합니다.
5. 등록 직후 읽기 전용 상태로 역할·범위·유효기간을 확인합니다. OS 로그인과 제품 관리자 권한은 별개입니다.

성공과 실패의 경계

이 용례의 성공은 정확한 서명 파일, 새 설치 신원, 준비된 서비스, 실제 관리자의 기록된 범위까지입니다. 런타임 바인딩과 Work 영수증은 다음 용례에서 확인해야 합니다. 다른 고객 신원, 이전 사용자 흔적, 상태 무결성 경고가 있으면 사용을 중단하고 이미지 잔여 사례를 따릅니다.

상세 시나리오: VM 전원 상태와 제품 준비 상태가 다른 경우

예를 들어 배포 담당자가 09:00에 VM을 생성했고 클라우드 화면에 09:02부터 실행 중이 보이지만, 제품 위자드에는 아직 준비 완료가 보이지 않는다고 가정합니다. 이때 기록에는 VM 생성 시각, 이미지 ID, 제품 상태를 마지막으로 확인한 시각을 분리해 적습니다. 서비스가 준비되지 않은 동안 관리자 등록이나 GUI 인증을 시도해 나온 오류는 첫 부팅 실패의 근거가 아닐 수 있습니다. 릴리스의 대기·상태 절차를 한 번 수행하고, 준비가 계속 확인되지 않으면 사례 A로 넘깁니다.

관리자 등록은 배포 담당자와 권한 소유자가 서로 다른 조직에서도 성립해야 합니다. 배포 담당자는 설치 ID와 이미지 출처를 넘기고, 권한 소유자는 고객·설치·런타임 허용 범위를 실제 제품 화면에서 검토합니다. 이후 읽기 전용 결과에 범위와 유효기간이 표시될 때만 이 단계를 닫습니다.

인계 기록 예시

위 대괄호 값은 예시 입력란이며 실제 릴리스 값을 만들어내지 않습니다. 다른 고객 또는 이전 설치의 값이 보이면 다음 단계로 넘기지 마십시오.

운영 중 사용할 구체적인 진행 예

운영 인계는 VM 생성자와 제품 관리자 사이에서 이루어질 수 있습니다. 온라인 설치는 승인된 포털·전달 경로에서 파일을 준비하고, 폐쇄망 설치는 동일 세대의 이미지·클라이언트·필요 모델·지문·문서를 반입 전에 준비합니다. 두 환경 모두 실제 신원과 관리자 범위 확인은 설치된 제품에서 수행합니다.

이 용례를 마칠 때 대조할 기록

인계 전 같은 설치 ID에 묶인 서비스 준비·관리자 역할·범위·만료와 다음 클라이언트 담당자를 기록합니다. 관리자 등록이 미완료이면 그 상태로 인계하며 런타임·Work를 완료 처리하지 않습니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

운영 목적과 선행 조건

고객이 이미 승인한 설치·런타임 범위 안에서 로컬 모델의 별칭 또는 런타임 관찰값이 바뀌었을 때, Core가 새 관찰을 검증해 바인딩을 갱신하는 흐름입니다. 현재 설치 신원, 관리자 범위, 지원 모델과 변경 전 바인딩 상태를 먼저 확보합니다.

예시 상황

운영자가 로컬 모델의 별칭을 바꿉니다. 모델 서버는 실행 중이지만 PackrGUI는 과거 바인딩 시각을 보여 줍니다. 이 시점의 “모델이 응답한다”는 사실만으로 새 모델의 바인딩을 완료했다고 말할 수 없습니다.

변경 전·후 확인표

순서대로 진행

1. 변경 내용과 시각을 기록합니다. 기존 바인딩을 삭제하거나 내부 상태 저장소를 직접 고치지 않습니다.
2. 릴리스 위자드가 제공하는 감지·재관찰 경로에서 새 런타임이 발견되는지 확인합니다.
3. 현재 관리자가 승인한 고객·설치·런타임 범위 안인지 확인합니다. 범위 밖이면 자동 적용을 기대하지 않고 관리자 결정을 받습니다.
4. 제품의 감지 → 검증 → 바인딩 상태와 거부 사유를 순서대로 읽습니다. 여러 후보 모델 중 대상이 모호하면 임의 선택하지 않습니다.
5. 새 바인딩의 모델 참조, 설치 ID, 기록 시각이 변경 이후인지 확인합니다. 이때만 바인딩 갱신을 기록합니다.
6. 실제 Work와 영수증은 별도로 실행·검증합니다. 영수증 부재 사례를 참고하십시오.

실패 분기와 지원 자료

감지되지 않으면 런타임 실행·공식 연결 경로를 확인합니다. 검증이 거부되면 바인딩 사례에 따라 범위·신원·모호성을 분리합니다. 지원 요청에는 변경 전후 상태·시각·설치 ID·제품 거부 문구만 전달하고 내부 저장소나 고객 프롬프트는 보내지 않습니다.

완료 기준

현재 변경에 대한 새 관찰과 Core의 새 바인딩이 같은 설치 신원으로 기록돼야 합니다. 이것은 Work 결과 또는 macOS·Windows 자동 바인딩 검증을 뜻하지 않습니다.

상세 시나리오: 모델 별칭만 바뀐 경우

예를 들어 10:00에 로컬 런타임의 별칭을 모델-A에서 모델-B로 바꿨다고 가정합니다. 09:40의 바인딩됨 기록은 변경 전의 증거입니다. 운영자는 10:00의 변경 기록과 이후 새 감지 시각을 나란히 놓고, Core가 같은 설치 ID와 승인 범위로 새 모델 참조를 검증했는지 봅니다. 별칭만 변경돼도 여러 후보가 동시에 보이면 임의로 하나를 선택하지 않습니다.

새 바인딩이 나오지 않는다면 단계별로 분류합니다. 런타임 자체가 발견되지 않으면 서비스 준비와 공식 연결 경로를 확인합니다. 발견은 됐으나 범위 밖이면 승인 소유자에게 넘깁니다. 검증은 됐으나 모델 대상이 모호하면 정확한 모델 선택을 요구합니다. 이전 바인딩 화면의 시각만 갱신돼 보인다면 새 바인딩으로 선언하지 않습니다.

변경 기록 예시

시각과 모델명은 절차 설명용 가상 값입니다. 실제 Work는 해당 바인딩 이후의 별도 기록으로 확인하십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 유지보수 창에서 모델 별칭과 런타임 주소 중 하나만 바꿉니다. 변경 전 지원 버전, 바인딩 참조와 마지막 상태를 보관하고 변경 후 새 관찰이 어느 값에 연결됐는지 대조합니다. 온라인 확인 성공이나 로컬 프로세스 재시작만으로 새 바인딩이 적용된 것으로 판단하지 않습니다.

이 용례를 마칠 때 대조할 기록

변경 전후 런타임·모델 참조, 관찰 시각, 검증 사유, 적용된 바인딩과 이후 별도로 수행한 승인 Work를 구분합니다. 되돌림도 제품이 다시 관찰·검증한 결과를 확인합니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

첫 연결 실습: 일반 사용자와 VM 관리자를 먼저 구분

목표: 이미 준비된 회사 VM에 내 클라이언트로 연결하고 같은 고객·설치 신원을 확인합니다. 이 실습은 Work를 자동 실행하지 않습니다. 회사에 VM이 아직 없다면 배포 담당자는 설치 안내 1–4절부터 진행하고, 일반 사용자는 설치 신원·준비 상태·접속 자료를 인계받습니다.

1. 관리자로부터 받아야 할 자료

호환 클라이언트의 실제 파일·지문·서명 상태, 고객·설치·릴리스 참조, 접속 endpoint와 TLS 서버명, 내 계정·기기 등록 방식, 허용 역할, 등록 만료/갱신 문의 경로를 받습니다. 릴리스가 기기별 프로필을 제공하면 조직의 안전한 전달 경로로 받습니다. 설명 페이지에 비밀키를 붙여넣거나 공통 설치 ZIP에 넣지 않습니다. 자동 등록 포털은 이 릴리스가 실제 제공할 때만 사용합니다.

2. OS별 설치와 실행 위치 확인

앱이 열리지 않으면 연결 실패가 아니라 앱 기동 단계로 기록합니다. OS의 정확한 경고, 앱 경로·버전·CPU와 동봉 파일을 확인하십시오. 운영체제 보안 설정 해제나 관리자 실행을 일반 해결책으로 사용하지 않습니다.

3. 연결·등록·신원 확인

1. 앱을 열고 해당 릴리스의 연결/프로필 선택 절차를 사용합니다. 새 서버를 추측하지 말고 관리자가 전달한 endpoint·TLS 서버명·프로필을 대조합니다.
2. 릴리스가 제공하는 사용자·기기 등록을 완료합니다. 단순 OS 로그인, 브라우저 복귀, 프로필 파일 선택만으로 등록 완료를 판단하지 않습니다. 만료 또는 미등록이면 관리자에게 그 상태를 전달합니다.
3. 제품이 표시한 고객·설치·릴리스와 관리자의 기대값을 대조합니다. 인증 상태와 서버 준비 상태를 따로 기록합니다. 다른 조직·설치가 보이면 접속을 중단합니다.
4. 처음에는 상태 조회만 확인합니다. 허용된 Work가 보이지 않으면 현재 역할·사용 권한을 관리자와 확인합니다. 일반 사용자에게 VM 관리자 로그인을 요구하지 않습니다.
5. 헤드리스도 사용할 사람만 해당 릴리스의 CLI·서비스 프로필로 별도 인증 상태를 조회합니다. GUI의 자격 증명을 임의 복사하거나 GUI 성공으로 헤드리스를 완료 처리하지 않습니다.

기대 결과: 실행한 클라이언트의 버전·경로, 같은 고객/설치 참조, 실제 인증 상태를 기록할 수 있습니다. 일반 사용자 등록이나 운영 연결이 해당 후보에서 아직 검증되지 않았다면 그 단계는 미확인으로 남습니다. 성공 화면을 가정해 채우지 않습니다.

막히면: 앱 기동 오류 → 패키지·OS 준비, 시간 초과/인증 거부 → 사례 C, 신원 변경 → 사례 B, 관리자 등록 문제 → 사례 D/E로 이동합니다. 실제 첫 Work는 별도의 첫 Work 용례를 따릅니다.

운영 목적

고객의 워크스테이션에서 GUI로 어플라이언스에 접속하고, 운영 자동화가 필요할 경우 릴리스가 제공한 별도의 헤드리스 경로를 확인합니다. 두 경로는 같은 고객 어플라이언스를 사용하더라도 설치 파일, 인증, 세션, 허용 기능과 결과 증거가 다를 수 있습니다.

예시 상황

운영자는 Mac의 PackrGUI에서 상태 화면을 볼 수 있습니다. 팀은 “그러면 Linux 서버의 헤드리스 작업도 준비됐다”고 말합니다. 이 결론은 검증되지 않았습니다. 각 클라이언트에서 직접 인증·설치 신원·기능을 확인해야 합니다.

경로별 확인표

실제 진행 순서

1. 각 플랫폼별 정확한 설치 파일을 릴리스 매니페스트와 대조합니다. Mac 패키지의 성공으로 Windows 패키지를 승인하지 않습니다.
2. GUI에서 서비스 응답, 인증 완료, 고객·설치 ID, 현재 허용 기능을 각각 확인합니다. 창이 열린 상태는 인증 완료가 아닙니다.
3. 헤드리스가 릴리스에 포함됐다면 별도의 공식 절차로 인증·연결·허용 범위를 확인합니다. GUI 자격 증명을 임의로 복사하지 않습니다.
4. 두 경로에서 같은 설치를 보는지 대조하되, 서로의 세션이나 권한을 자동으로 같다고 처리하지 않습니다.
5. 실제 Work를 수행할 때는 사용한 바로 그 경로의 최종 상태와 영수증을 확인합니다. 경로가 다르면 따로 기록합니다.

이번 릴리스가 packrctl을 제공할 때의 읽기 전용 확인

설치 담당자로부터 승인된 로컬 접근 경로를 받은 뒤, 설치 목록에 packrctl이 있는 경우 아래 명령으로 상태와 건강도를 읽으십시오. 권한 있는 어플라이언스 또는 관리 클라이언트에서만 실행합니다. 이 명령으로 GUI 세션을 인증하거나 Work를 승인할 수는 없습니다.

packrctl status --json > headless-status.json
packrctl health --json > headless-health.json

셸 종료 상태뿐 아니라 JSON의 준비 상태와 사유를 읽으십시오. UNKNOWN은 READY가 아닙니다. 정확한 전달 목록에 packrctl이 없으면 개발용 바이너리를 가져오지 말고 헤드리스 경로를 미제공으로 기록합니다.

실패 분기

한 경로만 실패하면 성공한 경로의 설정을 복제하기 전에 연결·인증 사례로 실패 지점을 분류합니다. 호스트 신원 경고는 신원 사례에서 즉시 중지합니다.

완료 기준

각 경로의 설치 파일·연결·인증·설치 ID·사용할 기능을 직접 확인한 뒤에만 해당 경로를 검증됨으로 기록하십시오.

제공된 구성요소 확인

플랫폼마다 전달 목록의 설치 파일 이름·서명·지원 버전·연결 방식을 확인하십시오. 설치 후에는 서버 신원, 인증 세션, 일치하는 고객·설치 ID를 기록합니다. 해당 플랫폼의 설치 파일이나 헤드리스 클라이언트가 목록에 없다면 다른 패키지를 사용하기 전에 공급자가 제공하는 지원 경로를 확인하십시오.

상세 시나리오: GUI만 연결되는 상황

Mac의 PackrGUI가 같은 설치 ID를 보여 주지만 서버 자동화 작업은 접속하지 못한다고 가정합니다. GUI의 인증 계정, 토큰 유효기간, 네트워크 경로는 자동화 서비스의 것과 다를 수 있습니다. GUI 화면을 캡처해 헤드리스 인증 성공으로 제출하지 마십시오. 헤드리스가 해당 릴리스의 제공 목록에 있는지부터 확인하고, 있다면 그 경로의 계정·주소·거부 사유를 별도로 기록합니다.

반대로 헤드리스 상태 조회가 성공해도 GUI 화면이 열리고 현재 세션에 같은 권한이 있는지 알 수 없습니다. 두 경로의 마지막 확인 단계가 다르면 가장 뒤처진 경로를 정확히 표시합니다. 예를 들어 GUI는 인증·신원 일치, 헤드리스는 네트워크 도달만 확인으로 적습니다.

플랫폼별 검증 기록 양식

실증 전에는 미확인으로 적습니다. 한 칸의 성공을 다른 운영체제나 경로에 복사하지 마십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 데스크톱 GUI는 정상인데 예약 자동화가 거부됩니다. GUI 사용자 세션과 자동화 서비스의 실행 위치·사용 계정·네트워크 경로·설치 범위가 각각 같은지 확인합니다. GUI의 토큰이나 키를 자동화에 복사하지 말고 해당 릴리스가 제공하는 서비스 인증 절차를 사용합니다.

이 용례를 마칠 때 대조할 기록

GUI와 헤드리스의 설치 파일·버전·인증 결과·설치 ID·허용 기능·상태 조회 결과를 한 표의 별도 행으로 남깁니다. 어느 한 경로가 미제공이면 그대로 기록하고 실제 Work 영수증은 실행한 경로에 연결합니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

운영 목적

고객이 필요한 기능을 Pack 후보로 준비·검증하고, 정식 권한 담당자가 승인·사용 권한을 별도로 확인할 수 있도록 인계합니다. 기존 Pack으로 해결 가능한지 먼저 확인하며, 새로운 후보를 만들었다는 이유만으로 실행 경로를 열지 않습니다.

예시 대화

Builder 사용자가 “검증 통과 표시가 떴으니 지금 실행하겠습니다”라고 말합니다. 관리자는 “그것은 후보 검증 결과입니다. 고객 설치의 Pack 승인, 사용 권한, 계약 범위, 사전 조건을 각각 확인해야 합니다”라고 답합니다.

상태와 소유자

순서대로 진행

1. 릴리스가 Builder를 제공하는지, Builder 설치 파일의 버전·서명을 확인합니다.
2. 지원 범위 안의 요구사항을 정의하고 후보의 계약·데이터 범위·사전 조건을 작성합니다. 범위 밖 기능을 지원되는 것처럼 표시하지 않습니다.
3. Builder의 검증 결과와 결함 목록을 확인하고 후보를 수정합니다. 검증 결과의 정확한 범위만 기록합니다.
4. 승인 담당자에게 후보 ID·버전·요청 능력·검증 결과를 제출합니다. 소스 전체나 고객 데이터는 필요한 승인 경로 외로 보내지 않습니다.
5. 승인과 사용 권한이 이 고객 설치에 각각 적용됐는지 제품 상태로 확인합니다. passkey 등록이 요구된다면 릴리스가 지정한 관리자 감독 경로를 사용하며, 브라우저 왕복만으로 승인 완료를 주장하지 않습니다.
6. 실제 Work는 별도 계획·승인·사전 조건을 확인한 뒤 실행하고 영수증으로 검증합니다.

거부되었을 때

Builder 후보 사례의 검증·승인·권한·사전 조건 분기로 이동합니다. 후보를 직접 배포 디렉터리에 복사하거나 거부된 명령을 다른 계정으로 실행하지 않습니다.

완료 기준

이 용례의 준비 완료는 후보 검증과 정식 승인·사용 권한 상태가 각각 확인됨입니다. 이것은 Work 성공을 뜻하지 않습니다.

상세 시나리오: 후보는 검증됐지만 실행이 거부됨

Builder에서 후보의 구조 검증이 통과했는데 실행 버튼 또는 Work 제출이 거부됐다고 가정합니다. 이것은 곧바로 제품 고장을 의미하지 않습니다. 후보의 구조·계약 검증, 승인 주체의 판단, 설치별 사용 권한, 실행 시점의 사전 조건은 서로 다른 관문입니다. 어느 관문에서 멈췄는지 제품의 원문 상태로 분류합니다.

예를 들어 후보 검증 PASS와 승인 대기 상태가 함께 표시되면 후보 준비 완료, 실행 권한 없음으로 기록합니다. 승인된 Pack이어도 현재 고객·설치 범위나 사전 조건이 맞지 않으면 이 실행은 진행하지 않습니다. 거부 상태를 바꾸려고 후보 파일이나 정책 저장소를 직접 수정하지 마십시오.

승인 인계 양식

대괄호는 실제 제품 기록을 채우기 위한 자리입니다. 검증 PASS를 승인 상태 칸에 복사하지 마십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 기존 점검 Pack의 입력을 새 대상에 맞게 변경합니다. 기존 Pack의 지원 범위를 먼저 확인하고, 필요한 후보만 새 리비전으로 생성합니다. 승인 검토를 받은 뒤 후보를 다시 수정했다면 이전 승인과 새 후보를 같은 것으로 취급하지 않습니다.

이 용례를 마칠 때 대조할 기록

후보 생성·검증, 승인, 설치별 사용 권한, 사전 조건과 Work 영수증을 각각 별도 상태로 적습니다. 인계에는 실행하지 않은 단계와 다음 권한 담당자도 포함합니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

운영 목적과 시작 조건

고객이 지원되는 Pack 또는 릴리스가 지정한 시험 작업 한 건을 제품의 통제된 경로로 실행하고, 같은 설치·Work ID의 최종 결과와 영수증을 확인합니다. 서비스 준비, 인증된 연결, 관리자 범위, 현재 런타임 바인딩이 먼저 확인돼야 합니다.

예시 상황

운영자가 “Qwen이 바인딩됐으므로 첫 Work가 끝났습니다”라고 보고합니다. 검토자는 “Work ID, 실행 승인, 모델 호출, 결과 검증, 영수증이 같은 작업에 연결됐습니까?”라고 확인합니다. 아직 Work를 제출하지 않았다면 보고할 수 있는 상태는 런타임 준비까지입니다.

단계별 확인표

실제 진행 순서

1. 승인된 대상 한 건을 고르고 실행 계획·대상 환경을 확인합니다. Builder 후보를 승인 Pack으로 취급하지 않습니다.
2. 고객이 허용한 사용자 승인 경로를 완료합니다. passkey 등록·브라우저 복귀·실제 Work 승인은 서로 다른 단계입니다.
3. Work 제출 후 제품이 기록한 ID를 확보하고, 그 ID의 승인·시작·실행 상태를 순서대로 읽습니다.
4. 로컬 AI 모델을 사용한 경우, 일반적인 모델 응답이 아니라 그 Work에 연결된 호출을 확인합니다.
5. 결과 검증, 실패·롤백 여부, 최종 영수증을 같은 릴리스·설치·Work ID에 결합합니다. 실패·중단·롤백은 성공으로 바꾸어 쓰지 않습니다.
6. 영수증이 없으면 영수증 부재 사례의 마지막 확인 상태부터 조사합니다. 기록을 수동으로 생성하지 않습니다.

승인된 설치에서만 사용하는 조건부 CLI 예시

전달받은 릴리스가 packrctl과 CREATE_AUDIT_ARTIFACT 작업을 제공한다면, 이 Work 한 건의 승인과 어플라이언스의 권한·사전 조건을 확인한 뒤에만 아래 예시를 사용하십시오. 키는 승인받은 미사용 값으로 바꿉니다. 이 작업은 로컬 감사 산출물을 만들며 첨부 고객 문서를 감사하거나 Qwen 모델을 호출하지 않습니다.

packrctl work run CREATE_AUDIT_ARTIFACT "create audit artifact" \
  "REPLACE_WITH_ONE_UNUSED_APPROVED_KEY" --json > work-run.json
# 반환된 result.work.work_id를 복사합니다. Work ID를 만들지 마십시오.
packrctl work show "PASTE_RETURNED_WORK_ID" --json > work-show.json

반환 기록에서 타입 결과·최종 상태·검증·영수증 참조·사람의 최종 인수 상태를 따로 확인하십시오. 종료 코드나 JSON 파일 생성만으로 성공 영수증이 되지 않습니다. 결과가 불확실하면 work run을 다시 내지 말고 원래 요청을 제품이 지원하는 경로로 대조하십시오.

지원 요청과 완료 기준

지원 요청에는 릴리스·설치·Work ID, 사용 Pack/작업의 공개 가능한 이름, 마지막 확인 단계, 최초 오류, 영수증 상태만 적습니다. 프롬프트·고객 데이터·원시 결과는 일반 티켓에 넣지 않습니다. 완료: 승인된 같은 Work의 성공 최종 상태, 검증된 결과, 영수증이 함께 확인됩니다.

상세 시나리오: 모델은 응답하지만 Work 영수증이 없는 경우

운영자가 로컬 모델의 응답을 확인하고 “첫 Work 성공”이라고 보고하려 한다고 가정합니다. 먼저 Work ID가 있는지 확인합니다. ID가 없다면 제품에 Work가 접수됐다는 증거부터 없습니다. ID가 있어도 승인, 시작, 모델 호출, 결과 검증, 최종 상태가 각각 기록됐는지 읽습니다. 모델의 일반 응답은 특정 Work에 묶인 호출을 대신하지 않습니다.

예를 들어 로컬 모델 별칭을 바꾼 뒤 GUI에는 새 BOUND가 보이지만 Work 준비는 UNKNOWN일 수 있습니다. 현재 설치가 보여 주는 권한·런타임·Work 준비 상태와 정확한 사유 코드를 기록하십시오. 필요한 준비 상태가 확인될 때까지 Work를 제출하지 말고, UNKNOWN이 계속되면 그 값을 릴리스 지원 경로로 전달하십시오. 아래 표에는 자신의 첫 Work 기록을 채웁니다.

한 건의 Work 증거표

실패·중단·롤백 결과를 영수증 파일의 존재만으로 성공 처리하지 않습니다. 문제를 전달할 때는 처음 빠진 관문을 보고하고 원문 프롬프트와 결과물은 일반 지원 요청에 포함하지 마십시오.

운영 중 사용할 구체적인 진행 예

예를 들어 승인된 읽기 작업 한 건을 계획합니다. 실행 직전 동일 설치·Pack·입력·현재 권한과 계획을 확인하고 반환된 실제 Work ID를 보관합니다. 연결 문제로 결과가 늦게 보이더라도 같은 ID의 조회 경로를 사용하며, 결과를 얻기 위해 새 Work를 중복 실행하지 않습니다.

이 용례를 마칠 때 대조할 기록

최종 상태, 후조건 검증, 결과 지문, Work 기록과 영수증이 모두 같은 실행을 가리키는지 확인합니다. 실패·롤백·대기·미확인은 각각 기록하고 모델의 독립 응답을 제품 영수증으로 대체하지 않습니다.

계획한 절차, 실제 수행한 동작, 확인된 결과와 남은 단계를 구분해 기록하십시오. 위 상황은 이해를 위한 예시이며 이 문서 갱신에서 고객 환경의 실행이 이루어진 것은 아닙니다.

사용 용례 색인으로 돌아가기

첫 후보 실습: 입력부터 인계까지

목표: 해당 릴리스가 제공한 읽기 전용 연습 Pack/후보를 새 리비전으로 준비하고 검증 결과를 읽습니다. 기존 운영 Pack을 수정하거나 서비스 변경 Work를 처음 연습으로 사용하지 않습니다. 제공된 연습 입력이 없으면 아래 목표 작성까지만 진행하고 지원 담당자에게 호환 예제를 요청합니다.

1. 해당 OS용 앱을 설치 안내대로 열고, 연결된 고객·설치·릴리스 및 Builder 역할을 확인합니다. 앱 창만 열리고 연결이 없으면 그 지점에서 멈춥니다.
2. 릴리스가 제공한 연습 후보 또는 지원 Pack을 제품의 제공된 선택/불러오기 절차로 엽니다. 화면 이름은 버전 안내를 따릅니다. 후보 ID·원본 리비전·원본 입력을 기록합니다.
3. 다음은 사람이 작성할 목표 메모입니다. JSON/API 입력 칸에 그대로 붙이지 않습니다. 목적: 합성 점검 결과 한 건 / 입력: 제공된 합성 자료 / 출력: 검토용 결과 / 변경: 고객 서비스 변경 없음 / 실패: 선언된 복구 상태 확인을 적고, 제품이 지원하는 입력 필드에 제공 템플릿의 형식으로 입력합니다.
4. 새 후보를 저장하고 제품이 반환한 실제 ID·리비전을 기록합니다. 검증 기능을 실행해 그 리비전의 결과·사유·누락 필드를 확인합니다. 저장과 검증은 별도 확인입니다.
5. 거부되면 정확히 표시된 선언만 수정하고 새 리비전을 검증합니다. 통과했다면 후보 참조, 검증 결과, 목적과 미완료 승인·사용 권한을 인계합니다. 파일이 생성됐다는 이유로 Work를 실행하지 않습니다.

예상 산출물: 제품이 반환한 후보 참조와 검증 기록입니다. SDK의 adapter.rs나 GAPE snapshot이 생성될 것으로 기대하지 않습니다. 후보를 제품이 관리한다면 임의 파일 경로를 찾아 복사하는 대신 릴리스의 내보내기 절차를 사용합니다.

다음 연습: 승인된 후보의 실제 사용은 승인·현재 사용 권한·사전 조건이 갖춰졌을 때 첫 Work 용례로 진행합니다. 검증은 통과했지만 승인이 대기라면 이번 실습은 후보 준비/인계 완료, Work 미실행으로 남깁니다. 아래 BLD 사례와 사례 H에서 상태별로 이어갑니다.

Builder를 열기 전

1. 어플라이언스 릴리스와 해당 운영체제의 Builder 패키지가 호환되고 서명·제공 목록에 포함됐는지 확인하십시오. Mac 패키지로 Windows·Linux 설치 가능성을 주장하지 않습니다.
2. 어플라이언스 준비 상태, 인증된 Builder 역할, 고객·설치 신원, 후보에 필요하다면 검증된 런타임 바인딩을 확인합니다. 로컬 소켓 연결 거부나 열린 Builder 창은 인증된 서버 연결이 아닙니다.
3. 확장하려는 기존 Pack 또는 기능을 찾습니다. 승인된 기존 Pack으로 해결되면 그 지원 경로를 사용합니다.

준비와 검증

1. 원하는 결과, 대상 환경, 허용 입력, 데이터 경계, 사전 조건과 롤백 처리를 적습니다. 예: “이 설치에 감사 산출물 한 건을 만들고, 선언된 소스만 읽고, 영수증을 남기며, 고객 서비스를 변경하지 않는다.”
2. 해당 릴리스가 제공한 Contract와 기능만 선택합니다. 입력 문서의 JSON 문법이 맞는다는 이유로 기능 식별자를 만들어내지 않습니다.
3. Builder에서 후보를 만든 뒤 제품의 후보 검증을 실행합니다. 후보 ID·리비전·검증 상태·정확한 사유·검사 규칙을 기록합니다. 선언 결함은 후보에서 수정하고 다시 검증하며 Core 정책 파일은 직접 바꾸지 않습니다.
4. 검증된 후보를 릴리스의 승인 경로로 제출합니다. 정식 Pack 승인과 고객 설치별 사용 권한을 따로 확인합니다. 릴리스의 등록·서버 검증 경로가 있을 때에만 passkey로 특정 승인의 사용자를 확인할 수 있습니다. Safari 열기와 앱 복귀만으로는 등록·승인이 증명되지 않습니다.
5. Work 전에 계획·대상·현재 권한·사전 조건을 확인합니다. 관문이 통과한 경우에만 통제된 제품 경로로 실행하고 최종 결과를 영수증과 대조합니다.

예시: 후보 검증은 통과했지만 Work가 거부됨

아래는 작성 예시이며 Builder API 입력이나 실제 영수증이 아닙니다. 설치된 릴리스의 실제 값을 넣고 검증과 거부를 분리해 기록하십시오.

릴리스: [서명 릴리스 ID]
설치: [고객이 허용한 참조]
후보: [Builder 후보 ID와 리비전]
검증: PASS (구조만)
승인: PENDING
사용 권한: NOT_CHECKED
Work: NOT_STARTED
다음 담당자: Pack 승인 담당자

후보가 감사 산출물을 선언하고 구조 검증에서 PASS를 받았는데 Work 제출은 “승인 대기”를 반환합니다. 이 상태는 후보 검증 완료 / 실행 권한 없음으로 기록합니다. 다음 조치는 승인 담당자의 몫입니다. 반복 제출, 다른 계정 사용, Pack 디렉터리로 후보 복사는 상태를 바꾸지 못합니다. 승인 후 사용 권한이 없다면 권한 담당자가 정확한 고객·설치 범위를 확인해야 합니다.

예시: 브라우저가 돌아왔지만 승인 기록이 없음

passkey 페이지가 열렸다 Builder로 돌아왔지만 Core에 동일 세션·계획·후보의 검증된 승인이 없습니다. Work는 거부 또는 대기 상태로 유지합니다. 표시된 correlation ID와 릴리스의 자격 증명 등록 상태를 확인하고, passkey 응답 원문을 지원 요청에 넣지 않습니다.

완료 증거

후보 준비는 검증된 후보와 인계 기록까지입니다. 승인된 Pack 사용에는 별도 승인·사용 권한·현재 사전 조건·실제 Work·검증 결과·일치하는 영수증이 필요합니다. 후보 거부 사례와 첫 Work 안내를 참고하십시오.

단계별 실제 사용 용례

예를 들어 주간 점검 산출물을 만드는 기존 Pack을 팀의 입력 형식에 맞게 준비한다고 가정합니다. 먼저 기존 승인 Pack의 지원 입력으로 해결되는지 확인합니다. 새 후보가 필요하면 원래 Pack 참조, 변경한 입력 선언, 후보 리비전과 검증 결과를 함께 남깁니다. 승인 담당자는 정확히 그 후보 지문을 검토하고, 운영 담당자는 현재 설치의 사용 권한과 사전 조건을 별도로 확인합니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 원본 Pack 참조, 후보 ID·리비전·지문, 변경 목적, 지원 플랫폼, 검증 결과, 승인 상태, 사용 권한 상태, 사전 조건, 롤백 처리와 다음 담당자. 실제 Work가 없으면 후보 준비 완료까지만 기록합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 BLD-1: 브라우저 확인 후 앱에 돌아왔지만 승인 기록 없음

상황: 사용자는 passkey 페이지에서 앱으로 돌아왔으므로 후보가 승인됐다고 생각합니다. 제품에는 같은 후보·계획·세션의 검증된 승인 기록이 보이지 않습니다.

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

• 브라우저 복귀: 화면 이동만 확인합니다.
• 자격 증명 등록: 개별 작업 승인은 별도입니다.
• 후보·계획: 승인 대상과 현재 값이 같아야 합니다.

확인·조치 순서:

1. 반환된 상관관계 참조와 현재 후보·계획을 제품 상태에서 대조합니다.
2. 해당 릴리스의 등록·서버 승인 확인 경로가 제공되는지 확인합니다.
3. 권한 담당자가 현재 상태를 확인하기 전에는 Work를 시작하지 않습니다.

다음 단계로 돌아갈 조건: 제품이 정확한 대상의 승인을 확인한 뒤 사용 권한·사전 조건을 별도로 대조합니다.

해결되지 않았을 때: passkey 응답 원문·다른 계정의 자격 증명으로 빈 승인 기록을 채우지 않습니다.

상세 예시 BLD-2: 실행 실패 후 일부 산출물과 롤백 상태가 남음

상황: 후보 또는 승인 Pack 작업이 실패했는데 출력 파일 일부가 보입니다. 파일 존재만으로 성공으로 보거나, 파일만 지우고 재실행하기 전에 제품의 실패·롤백 상태를 확인합니다.

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

• 파일 존재: 일부 동작의 흔적일 수 있습니다.
• Work 상태: 실패·롤백·후조건 검증을 별도로 확인합니다.
• 승인: 실패 뒤 새 실행에 그대로 적용되는지 추정하지 않습니다.

확인·조치 순서:

1. 해당 Work·계획·후보 신원과 마지막 검증 결과를 보존합니다.
2. Pack이 선언한 지원 복구 절차와 롤백 결과를 담당자가 확인합니다.
3. 현재 상태가 확인된 뒤 새 계획·권한·사전 조건을 정식 경로에서 평가합니다.

다음 단계로 돌아갈 조건: 검증된 복구 상태와 이후 승인된 실행의 결과를 구분해 기록합니다.

해결되지 않았을 때: 원본 결과 삭제·수동 성공 표시·다른 경로 실행으로 실패 상태를 숨기지 않습니다.

설치 후 도구 목록

첫 관찰 실습: 입력 준비, 실행, 결과 열기

먼저 받은 파일을 확인합니다. 승인된 snapshot과 뷰어만 받은 사람은 제공된 HTML 뷰어를 브라우저에서 열어 snapshot ID·소스 리비전·공개 등급을 읽고 노드 하나를 선택합니다. 소스나 매니페스트를 새로 만들 필요가 없습니다. 실행 파일과 승인 manifest를 받은 담당자는 아래 로컬 관찰을 진행할 수 있습니다. 일반 소스 Document나 SDK input.json을 GAPE 매니페스트로 사용하지 않습니다.

실행할 파일과 새 출력 경로 지정

gape_exe/$gapeExe는 제공된 실행 파일, manifest/$gapeManifest는 실제 승인 매니페스트의 절대 경로로 바꿉니다. 그 매니페스트가 지정한 소스 위치와 리비전도 존재해야 합니다. 새 출력의 부모 폴더만 준비하고 gape-observation-01은 만들지 않습니다. 경로를 추측해 소스 범위를 넓히지 않습니다.

gape_exe="/absolute/path/packr-gape"
gape_manifest="/absolute/path/approved-manifest.json"
gape_output="$HOME/gape-observation-01"
test -f "$gape_exe" && test -f "$gape_manifest" || exit 1
test ! -e "$gape_output" || exit 1
"$gape_exe" snapshot "$gape_manifest" "$gape_output" || exit 1
"$gape_exe" validate-snapshot "$gape_output/gape-architecture-snapshot.json" || exit 1
ls -la "$gape_output"

$gapeExe = 'C:\absolute\path\packr-gape.exe'
$gapeManifest = 'C:\absolute\path\approved-manifest.json'
$gapeOutput = Join-Path $env:USERPROFILE 'gape-observation-01'
if (!(Test-Path -LiteralPath $gapeExe -PathType Leaf) -or !(Test-Path -LiteralPath $gapeManifest -PathType Leaf)) { throw 'Executable or approved manifest missing' }
if (Test-Path -LiteralPath $gapeOutput) { throw 'Choose a fresh output path' }
& $gapeExe snapshot $gapeManifest $gapeOutput
if ($LASTEXITCODE -ne 0) { throw 'Snapshot failed' }
& $gapeExe validate-snapshot (Join-Path $gapeOutput 'gape-architecture-snapshot.json')
if ($LASTEXITCODE -ne 0) { throw 'Snapshot validation failed' }
Get-ChildItem -LiteralPath $gapeOutput

무엇을 읽나: snapshot 명령의 JSON에는 snapshot ID와 노드·관계·finding 수, execution_authority: NONE이 표시됩니다. finding 수가 0일 것이라고 가정하지 않습니다. 검사 결과와 실제 생성 파일을 보존하고, 동봉된 뷰어가 있으면 그 파일을 엽니다. 뷰어가 없다면 snapshot JSON을 편집기에서 읽습니다. HTML 파일 이름을 임의로 추측하지 않습니다.

짧은 과제: 노드 하나의 이름·소스 리비전·연결된 관계·관찰 한계를 기록합니다. 이전 snapshot과 비교하려면 두 원본을 보존하고 제공된 compare before.json after.json 명령의 지원 여부를 릴리스에서 확인합니다. 관찰 밖의 동작은 추정하지 않습니다. 내부 엔지니어링 snapshot은 외부 공유하지 않고 승인된 PUBLIC_SAFE 투영을 사용합니다.

막히면: 실행 파일 없음은 설치 준비, 소스 경로/리비전 없음은 승인 입력 준비, snapshot 검사 실패는 관찰 검사 단계로 기록합니다. 아래 GAPE-1/2로 이동하며 임의 manifest 작성으로 관찰 범위를 확대하지 않습니다.

사용할 때

연동 담당자가 제안한 작업이 어느 구성요소와 인터페이스에 의존하는지 파악할 때 사용합니다. 해당 릴리스가 GAPE 도구와 승인된 입력 매니페스트를 제공하는지 확인하십시오. 일반 소스 폴더·스크린샷·아키텍처 인포그래픽은 매니페스트가 아닙니다.

관찰 준비

1. 승인된 소스 버전, 관찰할 폴더, 제외 대상, 예상 규칙과 공유 범위를 기록합니다. GAPE 결과는 선택한 저장 버전에 대한 관찰입니다. 저장하지 않은 변경이나 실제 실행 중의 동작은 결과에 포함되지 않을 수 있습니다.
2. 구성요소 목록에 packr-gape와 승인된 매니페스트가 있다면 새 출력 폴더에서 packr-gape snapshot manifest.json new-output-folder를 실행합니다. 둘 중 하나가 없다면 지원되는 관찰 절차를 문의하십시오.
3. 해당 명령이 제공된 경우 packr-gape validate-snapshot gape-architecture-snapshot.json으로 생성 결과를 확인합니다. 이는 snapshot의 구조·출처 검사이지 실제 런타임 동작 검증이 아닙니다.
4. 승인된 오프라인 뷰어에서 노드·관계 하나를 선택하고 소스 리비전과 관찰 한계를 적습니다. 별도 Contract 또는 소유자 규칙과 대조하십시오. UNRESOLVED·STALE은 그대로 이슈로 남기며 뷰어를 고쳐 일치처럼 표시하지 않습니다.
5. 허용된 곳에는 PUBLIC_SAFE 투영만 공유합니다. 엔지니어링 입력·내부 경로·소스 위치·상세 판정은 승인된 엔지니어링 환경에 보관합니다.

실제 릴리스가 GAPE를 제공할 때의 명령 예시

아래 명령은 설치 목록에 packr-gape와 조회 권한이 있는 소스용 승인 매니페스트가 모두 있을 때만 사용하십시오. 출력 폴더는 새로 만들어야 합니다. validate-snapshot은 snapshot 검사이며 실행 중인 어플라이언스 검사가 아닙니다.

packr-gape snapshot approved-manifest.json new-observation-folder
packr-gape validate-snapshot new-observation-folder/gape-architecture-snapshot.json

실제 릴리스가 생성한 파일명이 다르면 그 이름을 사용합니다. 매니페스트 지문·소스 리비전·snapshot ID·검사 결과와 execution_authority: NONE을 기록하십시오. 실행 파일이나 승인 매니페스트가 없으면 이 경로를 중지하고 이번 릴리스에서 미제공으로 기록합니다.

예시: 도표에 어댑터 연결이 보임

운영자가 GAPE snapshot에서 PackrGUI와 연동 어댑터 사이의 관계를 봅니다. 이 관계는 STATIC_SOURCE입니다. 실제 고객 런타임은 다른 기능 구성으로 동작할 수 있고 동적 호출은 저장된 소스 관찰 범위 밖일 수 있습니다. snapshot에 표시된 정확한 소스 버전을 기록하고 담당자에게 제공된 Contract와 연결 증거를 확인하십시오. 배포 기록에 “연결됨”이나 “승인됨”이라고 쓰지 않습니다.

예시: 관찰과 예상 규칙이 다름

snapshot에 인터페이스 연관은 있지만 예상 소유자 규칙이 없거나 다른 리비전의 규칙입니다. GAPE는 UNRESOLVED 또는 STALE을 표시합니다. 매니페스트 신원·snapshot 지문·판정·정확한 리비전을 보존하십시오. 담당자가 Contract와 소스를 별도로 대조해야 하며 그림을 새로 그리는 일은 복구가 아닙니다.

완료 증거

매니페스트, snapshot 검증 결과, 선택한 투영, 리비전, 공개 등급, 관찰 한계와 미해결 판정이 기록되면 관찰이 끝납니다. 연동 등록과 Work는 별도 절차입니다. Integration Helper 또는 Contract & Document 안내로 이어가십시오.

단계별 실제 사용 용례

예를 들어 새 연동 요청 전에 담당자가 데이터가 어느 구성요소를 거치는지 검토합니다. 승인된 매니페스트의 저장 리비전을 고정하고 노드 하나와 그 관계를 추적합니다. 관찰 출처와 확인되지 않은 동적 경로를 함께 적고, 다른 리비전의 문서와 비교할 때는 두 리비전을 모두 표시합니다. 운영 장애 원인을 이 그림만으로 확정하지 않습니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 소스 리비전, 매니페스트 지문, snapshot 지문, 관찰 범위, 공개 등급, 선택한 노드·관계, 미해결 항목과 다음 확인 담당자. snapshot 검증 결과와 실제 런타임 증거는 별도로 기록합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 GAPE-1: 코드는 변경됐지만 예전 snapshot을 검토함

상황: 담당자가 현재 설계와 다르다고 보고한 그림은 이전 저장 리비전의 snapshot입니다. 현재 소스, 승인 매니페스트와 관찰 결과의 리비전을 먼저 구별합니다.

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

• 그림: 특정 snapshot ID·소스 리비전을 가집니다.
• 현재 소스: 저장되지 않은 변경은 관찰에 포함되지 않을 수 있습니다.
• 검증: snapshot 구조 검사는 런타임 검증이 아닙니다.

확인·조치 순서:

1. 매니페스트 지문·snapshot 생성 시점·정확한 저장 리비전을 대조합니다.
2. 새 관찰이 필요하면 승인된 입력과 제공된 명령으로 새 출력 폴더를 사용합니다.
3. 이전·새 결과를 함께 보존하고 변경된 관계와 관찰 한계를 표시합니다.

다음 단계로 돌아갈 조건: 현재 검토 대상 리비전과 검증된 snapshot이 맞으면 그 범위의 관찰 검토를 계속합니다.

해결되지 않았을 때: 매니페스트나 리비전이 미확인이면 그림을 고쳐 일치시키지 않고 해당 관찰을 미확인으로 남깁니다.

상세 예시 GAPE-2: 필터 또는 관찰 범위 때문에 노드가 보이지 않음

상황: 검색에서 구성요소가 나오지 않아 기능이 없다고 생각합니다. 하지만 선택한 필터·매니페스트 제외 규칙·지원 언어에 따라 표시와 관찰 범위가 달라질 수 있습니다.

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

• 검색 결과 없음: 화면의 선택 범위에 대한 결과입니다.
• 매니페스트: 관찰 폴더·제외 규칙을 정합니다.
• 구현 부재: 이 화면만으로 확정할 수 없습니다.

확인·조치 순서:

1. 검색어·필터를 확인하고 원래 관찰의 범위·리비전·제외 목록을 읽습니다.
2. 다른 범위가 필요하면 승인된 입력을 가진 담당자에게 요청합니다. 내부 자료를 공개 뷰에 추가하지 않습니다.
3. 관찰 밖·표시 필터·실제 미확인을 구별해 기록하고 필요한 소스 근거를 담당자에게 인계합니다.

다음 단계로 돌아갈 조건: 해당 리비전과 범위의 관계를 확인한 경우에만 그 관찰을 인용합니다.

해결되지 않았을 때: 소스 근거가 없으면 미구현·기능 없음으로 단정하지 않습니다.

설치 후 도구 목록

첫 준비 실습: 전체 요청 한 건을 단계별로 읽기

준비물: 버전이 맞는 Helper 실행 파일, 완전한 request.json, 공급자가 게시한 대상 참조. SDK와 Helper는 별도 실행 파일입니다. SDK의 발췌 JSON만 저장해 이 요청을 대신하지 않습니다. SDK 전체 예제를 재사용하려면 그 Helper 릴리스에서도 동일한 대상·envelope를 지원하는지 먼저 확인합니다.

1. 제공된 요청 원본을 보존하고 작업용 사본을 만듭니다. request_id, correlation_id, draft 전체와 그 안의 definition/source/mapping/fixture를 확인합니다. 실제 API 토큰은 넣지 않습니다.
2. 아래 실행 파일·요청 경로를 실제 절대 경로로 바꿉니다. helper-first-01은 새 로그 폴더입니다. 첫 명령만 실행하고 결과를 읽습니다.
3. stdout의 status, reason, lifecycle_stage, next_required_actions, 후보 지문을 확인합니다. next_action이라는 단일 필드가 있다고 가정하지 않습니다. 이 CLI는 타입 거부 결과를 출력하면서 종료 코드 0일 수 있으므로 `$LASTEXITCODE`/종료 코드만으로 다음 단계에 가지 않습니다.
4. 발견이 통과한 경우에만 기존 절의 normalize → validate → prepare → status를 각각 같은 요청 사본으로 실행합니다. 이전 명령의 JSON 결과를 다음 명령의 입력으로 바꾸지 않습니다. 각 명령은 전체 요청을 받습니다.
5. DENIED, 구현 필요, 권한 필요 또는 모르는 상태면 해당 결과를 보존하고 다음 조치를 읽습니다. 첫 연습에 r2-submit은 필요하지 않습니다. 요청을 수정할 때는 새 사본·새 로그 폴더를 사용합니다.

helper_exe="/absolute/path/packr-integration-helper"
helper_request="/absolute/path/request.json"
helper_logs="$HOME/helper-first-01"
test -f "$helper_exe" && test -f "$helper_request" || exit 1
test ! -e "$helper_logs" || exit 1
mkdir "$helper_logs" || exit 1
"$helper_exe" r2-discover "$helper_request" > "$helper_logs/01-discover.json" 2> "$helper_logs/01-discover.stderr.txt"
helper_exit=$?
cat "$helper_logs/01-discover.json"
cat "$helper_logs/01-discover.stderr.txt"
# helper_exit와 JSON의 status/reason을 별도로 기록합니다.

$helperExe = 'C:\absolute\path\packr-integration-helper.exe'
$helperRequest = 'C:\absolute\path\request.json'
$helperLogs = Join-Path $env:USERPROFILE 'helper-first-01'
if (Test-Path -LiteralPath $helperLogs) { throw 'Choose a fresh log folder' }
New-Item -ItemType Directory -Path $helperLogs -ErrorAction Stop | Out-Null
& $helperExe r2-discover $helperRequest 2> (Join-Path $helperLogs '01-discover.stderr.txt') | Out-File -LiteralPath (Join-Path $helperLogs '01-discover.json') -Encoding utf8
$helperExit = $LASTEXITCODE
Get-Content -LiteralPath (Join-Path $helperLogs '01-discover.json') -Raw -Encoding UTF8
Get-Content -LiteralPath (Join-Path $helperLogs '01-discover.stderr.txt')

위 파일은 로그이며 그 자체를 새 요청으로 제출하지 않습니다. 후속 결과도 02-normalize, 03-validate, 04-prepare, 05-status처럼 구분해 저장합니다. 예상 연습 결과는 단계 판정과 후보 준비 기록이며 실제 API 연결·등록·Work가 아닙니다. 게시된 대상이 없다면 TARGET_NOT_PROVIDED는 담당자의 진행 기록으로 쓰고, 제품이 실제 출력한 reason과 구분하십시오. 아래 IH-1/2에서 거부와 인계 예를 확인합니다.

입력과 담당자

후보 준비

1. 지원되는 소스 형식으로 읽기 전용 작업부터 설명합니다. 예: status.read의 입력 service 문자열과 출력 service·healthy. 실제 토큰이나 고객 응답은 문서에 붙여넣지 않습니다.
2. 공급자가 게시한 대상 Contract·어댑터 리비전을 확보합니다. 없으면 TARGET_NOT_PROVIDED로 기록하십시오. 비슷해 보이는 표시 이름은 유효한 대상 매칭이 아닙니다.
3. 해당 릴리스가 제공한 완전한 요청 파일을 사용합니다. 포함된 Helper가 r2-discover, r2-normalize, r2-validate, r2-prepare, r2-status를 제공한다면 request.json으로 이 순서대로 진행합니다. 매 단계의 상태·사유·다음 조치를 보존하십시오.
4. 실제 결과가 거부한 필드 또는 매핑만 고칩니다. 제한된 예시 형식은 기본 자료형과 명시적 매핑을 지원합니다. 지원되지 않는 변환이나 매핑되지 않은 필수 필드는 계속 거부됩니다. REQUIRES_IMPLEMENTATION scaffold에는 실제 어댑터 구현이 추가로 필요합니다.
5. 릴리스의 승인된 제출 경로에서만 r2-submit을 사용합니다. 신뢰된 등록 전송 경로가 없는 CLI는 REQUIRES_AUTHORITY를 반환합니다. 정식 등록에는 정확한 후보·목적에 묶인 별도의 유효한 승인이 필요합니다. 등록되어도 Work 바인딩·승인이 자동으로 생기지 않습니다.

재현 가능한 로컬 준비 예시

전달 목록에 Helper 실행 파일과 버전에 맞는 완전한 request.json이 있다면 아래 단계를 하나씩 실행합니다. 각 JSON에서 status·reason·단계·다음 조치를 읽고 진행하십시오. 셸 종료 코드만으로 통과를 판단하지 않습니다. 요청에는 위의 status.read 설명 대신 릴리스가 제공한 지원 대상 참조가 필요합니다.

packr-integration-helper r2-discover request.json > 01-discover.json
packr-integration-helper r2-normalize request.json > 02-normalize.json
packr-integration-helper r2-validate request.json > 03-validate.json
packr-integration-helper r2-prepare request.json > 04-prepare.json
packr-integration-helper r2-status request.json > 05-status.json

판정 예시: 발견 결과가 status=PASSED, reason=NONE, lifecycle_stage=DISCOVERED라도 정규화가 DENIED / CONTRACT_INCOMPATIBLE을 반환할 수 있습니다. 두 결과를 모두 보존하고 prepare 전에 멈춰 게시된 올바른 대상을 확보하십시오. 앞 단계가 거부됐는데 다섯 명령을 무조건 연속 실행하지 마십시오.

예시: 소스는 통과, 대상은 거부

합성 status.read 문서에 대해 r2-discover가 status=PASSED, reason=NONE, lifecycle_stage=DISCOVERED를 반환합니다. 게시된 대상이 묶이지 않아 r2-normalize는 DENIED / CONTRACT_INCOMPATIBLE을 반환합니다. 소스 문서 구조는 받아들여졌지만 연동은 준비되지 않았습니다. 공급자 또는 연동 담당자에게 정확한 대상 참조를 요청하십시오. Contract ID를 임의로 만들거나 표시 이름만 맞춰 통과시키지 않습니다.

예시: 후보 제출 후 등록되지 않음

검증된 후보의 제출 결과가 REQUIRES_AUTHORITY입니다. 후보 지문과 요청한 승인 목적을 기록합니다. 권한 담당자가 정확한 후보를 native 등록 경로에서 평가해야 합니다. CLI 반복 실행이나 옵션 추가로 준비 상태를 등록으로 바꿀 수 없습니다.

완료 증거

입력·대상 리비전, 요청 신원, 단계별 타입 결과, 후보 지문, 미해결 문제와 다음 담당자가 기록되면 준비 단계가 끝납니다. 실제 제공자 연결·등록·바인딩·승인된 Work·영수증에는 각각 별도 증거가 필요합니다. 소스 선언은 Contract & Document를 참고하십시오.

단계별 실제 사용 용례

예를 들어 서비스 상태를 읽는 소스 Document와 공급자가 게시한 대상 참조를 연결합니다. 첫 시도는 합성 데이터로 준비하고 단계마다 상태·사유·다음 조치를 읽습니다. 정규화가 거부되면 그 뒤 prepare·submit으로 넘기지 않습니다. 입력을 고쳤다면 요청 리비전과 지문을 새로 기록하여 이전 거부와 새 결과를 구별합니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 전체 요청 지문, 소스·대상 리비전, 요청·상관관계 ID, 각 단계의 타입 결과, 후보 지문, scaffold의 구현 필요 여부, 제출·등록 상태와 다음 담당자. 실제 API 연결 시험은 준비 결과와 구분합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 IH-1: 발견은 통과했지만 대상 정규화가 거부됨

상황: 합성 소스 Document의 read_quality는 발견됐지만 전체 요청은 다른 Contract·어댑터 리비전을 가리킵니다. 발견 PASS 뒤 prepare까지 무조건 실행하면 첫 거부를 놓칩니다.

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

• 발견: status=PASSED, reason=NONE, lifecycle_stage=DISCOVERED는 소스 발견 결과입니다.
• 정규화: DENIED / CONTRACT_INCOMPATIBLE은 대상 호환 거부입니다.
• 후보 준비: 아직 완료되지 않았습니다.

확인·조치 순서:

1. 정규화의 상태·사유·다음 조치를 보존하고 후속 prepare·submit을 멈춥니다.
2. 공급자가 게시한 정확한 대상과 전체 요청의 참조를 대조합니다. 이름만 비슷한 대상을 고르지 않습니다.
3. 지원되는 참조를 확보한 뒤 수정 요청의 리비전·지문을 보관하고 영향을 받은 단계부터 검사합니다.

다음 단계로 돌아갈 조건: 해당 요청이 정규화·의미 검증을 통과한 뒤에만 후보 준비 결과를 확인합니다.

해결되지 않았을 때: 게시된 대상이 없으면 ID·스키마 지문을 만들어 맞추지 않고 대상 미제공으로 인계합니다.

상세 예시 IH-2: prepare 산출물은 있지만 제출이 권한을 요구함

상황: 후보 준비 결과가 만들어졌지만 CLI 제출은 REQUIRES_AUTHORITY를 반환합니다. 로컬 후보 파일을 서버 등록 위치에 복사하면 해결되는 문제가 아닙니다.

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

• prepare: 후보 준비 결과입니다.
• submit: 신뢰된 등록 경로·정확한 승인 목적을 요구합니다.
• Work: 등록·바인딩·실행은 별도입니다.

확인·조치 순서:

1. 후보 지문과 제출 결과·요청·상관관계 ID를 보존합니다.
2. 해당 릴리스가 실제 등록 전송 경로와 담당자를 제공하는지 확인합니다.
3. 정확한 후보·목적·고객·설치 범위에 대한 승인된 등록 절차로 인계합니다.

다음 단계로 돌아갈 조건: 등록 담당자의 실제 결과를 확인한 경우에만 등록으로 기록하고 Work는 따로 확인합니다.

해결되지 않았을 때: CLI 반복 제출이나 자격 증명 복사로 준비 상태를 등록 상태로 바꾸지 않습니다.

설치 후 도구 목록

첫 문서 실습: 파일 저장부터 Helper 인계까지

목표: 아래의 완전한 소스 Document를 quality-document.json으로 저장하고 문법을 확인합니다. 이 파일은 소스 선언만 담습니다. SDK/Helper의 전체 요청이나 GAPE 매니페스트가 아닙니다.

1. 조직이 허용한 새 작업 폴더를 만들고 텍스트 편집기를 엽니다. 아래 JSON 블록의 {부터 마지막 }까지만 복사합니다. 코드 울타리와 json 표시는 파일에 넣지 않습니다.
2. 파일 이름을 quality-document.json, 인코딩을 UTF-8로 저장합니다. Word/서식 문서 형식이 아닌 일반 텍스트를 사용하고 .json.txt가 붙지 않았는지 확인합니다. 저장한 파일을 다시 열어 operations.read_quality가 있는지 읽습니다.
3. macOS/Linux에 Python 3가 이미 준비돼 있다면 아래 명령을 사용합니다. Windows는 PowerShell의 내장 JSON 파서를 사용할 수 있으므로 이 실습 때문에 Python 설치가 필수는 아닙니다.
4. 문법 통과 후 properties의 resource/component/score와 각 required 목록을 대조합니다. 이 검토와 JSON 파싱은 제품의 의미 검증을 대신하지 않습니다.
5. 원본 사본을 보존한 뒤 공급자가 제공한 전체 요청의 draft.source에 문서 객체를 넣습니다. 파일 경로 문자열이나 JSON을 이중 인코딩한 문자열을 넣지 않습니다. 대상 참조·매핑·fixture는 제공된 요청에서 별도로 확인하고 Helper 첫 준비 실습으로 이동합니다.

document_path="/absolute/path/quality-document.json"
python3 -m json.tool "$document_path"

$documentPath = 'C:\absolute\path\quality-document.json'
Get-Content -LiteralPath $documentPath -Raw -Encoding UTF8 -ErrorAction Stop | ConvertFrom-Json -ErrorAction Stop | Format-List
Get-FileHash -LiteralPath $documentPath -Algorithm SHA256

기대 결과: JSON 파서는 객체를 표시하고 파싱 오류를 내지 않습니다. 문법 오류라면 줄/열과 쉼표·따옴표·중괄호를 확인합니다. 이 파서는 중복 키나 제품 미지원 스키마 전체를 판정하지 않습니다. 문법 확인 완료 / Helper 의미 검증 미실행으로 기록하고, 실제 Helper 결과가 나왔을 때 별도 추가합니다.

작은 수정 연습: 새 사본에서 입력 이름을 바꾸려면 properties, required, 요청의 명시적 매핑과 지원 대상 영향을 함께 검토합니다. 처음에는 제공된 원본으로 한 번 확인한 뒤 바꾸십시오. DOC-1/2 사례는 이름 불일치와 전체 요청 누락을 다룹니다.

수정 중인 산출물 구분

범위가 정해진 소스 Document 작성

1. 짧은 목표와 데이터 경계를 적습니다. 예: read_quality는 리소스 이름을 받아 구성요소 이름과 품질 점수를 문자열로 반환합니다. 리소스를 변경하지 않습니다.
2. 지원되는 CUSTOM_API 형식에서 document_kind는 CUSTOM_API, protocol_revision은 지원되는 값으로 하고 operations 아래에 read_quality를 둡니다. input_schema는 필수 resource 문자열을 가진 object, output_schema는 필수 component와 score 문자열을 가진 object로 선언합니다. 문장 속 필드 이름은 설명이며 완전한 JSON 파일이 아니므로 구두점과 중첩은 아래의 완전한 예시를 사용하십시오.
3. 속성 이름과 required 목록을 일치시킵니다. 제한된 예시는 지원되는 기본 자료형만 받습니다. 중첩 object·배열·추가 JSON Schema 키워드·중복 키·주석이 묵시적으로 허용되지는 않습니다. 자격 증명이나 실제 운영 응답을 schema의 기본값·설명에 넣지 않습니다.
4. 로컬 사본에서 앞의 OS별 파서 명령으로 JSON 문법을 확인합니다. 문법 PASS는 JSON 파싱만 증명합니다. 수정할 때 원본과 지문을 보존합니다.
5. 공급자가 게시한 정확한 기능·Contract·어댑터·작업·리비전 식별자를 확보합니다. 이 참조는 독립 소스 Document가 아니라 릴리스가 정한 요청 envelope에 넣습니다. 이후 Integration Helper 준비 절차를 따릅니다.

완전한 소스 Document 예시

아래 CUSTOM_API 예시는 읽기 전용 read_quality 작업을 선언합니다. 실제 API를 호출하거나 제품 Contract를 만들지 않습니다. JSON을 quality-document.json으로 저장하고 해당 릴리스가 제공한 완전한 요청의 draft.source에 넣은 뒤 호환되는 지원 대상 참조를 지정하십시오.

{
  "document_kind": "CUSTOM_API",
  "protocol_revision": "1",
  "operations": {
    "read_quality": {
      "input_schema": {
        "type": "object",
        "properties": {"resource": {"type": "string"}},
        "required": ["resource"]
      },
      "output_schema": {
        "type": "object",
        "properties": {
          "component": {"type": "string"},
          "score": {"type": "string"}
        },
        "required": ["component", "score"]
      }
    }
  }
}

python3 -m json.tool quality-document.json > /dev/null
sha256sum quality-document.json

첫 명령은 JSON 문법만 확인합니다. macOS는 shasum -a 256 quality-document.json, Windows PowerShell은 Get-FileHash -Algorithm SHA256 quality-document.json을 사용하십시오. 완전한 envelope·대상·매핑의 적합성은 Helper의 타입 판정으로 별도 확인해야 합니다.

예시: JSON은 유효하지만 대상 리비전이 다름

소스 Document가 파싱되고 발견 단계에서 read_quality가 받아들여졌지만 요청은 다른 릴리스의 어댑터 리비전을 참조합니다. 정규화 단계는 대상을 거부합니다. 릴리스 매니페스트와 공급자 참조를 대조하고, 승인된 호환 값이 실제로 있을 때만 새 요청의 대상 리비전을 바로잡습니다. 소스 작업 이름만 바꿔 우연히 맞추면 불일치를 숨기게 됩니다.

예시: 필드 이름만 바꾸고 required를 그대로 둠

편집자가 입력 속성 resource를 resource_name으로 바꾸고 required: ["resource"]는 그대로 둡니다. JSON 문법은 유효하지만 선언 의미가 일치하지 않습니다. 속성을 되돌리거나 required 목록을 고친 뒤 같은 로컬 파서와 Helper 검증을 다시 수행하십시오. 문법 검사 통과를 Contract 검증으로 해석하지 않습니다.

완료 증거

소스 Document의 리비전·지문, 게시된 대상 참조, 요청 신원, 타입이 정해진 Helper 결과와 남은 승인 담당자를 보관합니다. 실제 인증·등록·런타임 증거 전에는 “연결됨”, Work와 영수증 전에는 “실행됨”이라고 표시하지 않습니다.

단계별 실제 사용 용례

예를 들어 읽기 전용 품질 조회에 출력 필드 하나를 추가하려고 합니다. 사람용 목표, 소스 스키마, 대상 참조와 전체 요청 envelope를 각각 구분합니다. 출력 속성과 required 목록, 실제 합성 응답, 명시적 매핑을 함께 검토하고 지원되지 않는 스키마 확장은 그대로 별도 구현 요구로 남깁니다. 제품이 발행한 Contract를 고객 문서로 대체하지 않습니다.

증상별 확인과 복귀 확인

다음 담당자에게 넘길 최소 기록

인계 항목: 소스 Document 리비전·지문, 요청 envelope 리비전, 게시된 Contract·어댑터 참조, 매핑 규칙, 합성 입력·예상 출력, 문법·의미 검증 결과와 변경 이유. 실제 값이 없는 템플릿과 실행 가능한 전체 요청을 구분합니다.

도구별 문제 해결 사례 읽기

다음은 지원되는 입력·명령·권한 경계를 바탕으로 구성한 교육용 사례입니다. 제품의 실제 상태·사유와 함께 읽고, 자신의 실행 기록 없이 예시의 결과를 성공 이력으로 사용하지 않습니다. 온라인과 오프라인 환경 모두에 적용되는 확인 항목과 선택 의존성 경로에만 해당하는 항목을 구별합니다.

상세 예시 DOC-1: 속성 이름만 바꾸고 required는 그대로 둠

상황: 입력 속성 resource를 resource_name으로 바꿨지만 required에는 resource가 남아 있습니다. JSON 문법 검사는 통과해도 선언의 의미는 일치하지 않습니다.

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

• 문법: JSON 파싱은 가능합니다.
• 선언: properties와 required가 다른 이름을 가리킵니다.
• 대상·매핑: 소스 변경의 영향을 따로 확인해야 합니다.

확인·조치 순서:

1. 전체 소스 Document와 원본 리비전·지문을 보존합니다.
2. 실제 의도한 입력 이름을 정하고 속성·required·명시적 매핑을 지원 범위 안에서 맞춥니다.
3. 로컬 JSON 문법과 Helper 의미 검증을 각각 수행하고 결과를 구분합니다.

다음 단계로 돌아갈 조건: 문법과 의미 검증이 모두 확인된 새 요청을 후속 준비에 사용합니다.

해결되지 않았을 때: 지원되지 않는 스키마 확장은 임의로 허용하지 않고 추가 구현 요구로 남깁니다.

상세 예시 DOC-2: 소스 Document 발췌를 전체 요청으로 실행함

상황: 사용자는 안내서의 짧은 CUSTOM_API 예시만 저장해 Helper 또는 SDK 입력으로 보냅니다. 소스 설명은 맞지만 요청·대상·매핑·합성 응답을 포함한 전체 envelope는 아닙니다.

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

• 소스 Document: draft.source에 들어갈 자료입니다.
• 전체 요청: request_id·correlation_id·draft와 지원 참조가 필요합니다.
• 발췌: 필드를 설명하는 예시이며 바로 실행 가능한 전체 입력이 아닙니다.

확인·조치 순서:

1. 제공된 버전에 맞는 전체 요청 템플릿을 확보하고 원본을 보존합니다.
2. 소스·대상·매핑·합성 응답을 각각의 정해진 위치에 채웁니다. 비밀값·실제 고객 응답은 넣지 않습니다.
3. 문법 확인 뒤 제품의 analyze 또는 Helper 단계 판정으로 의미를 확인합니다.

다음 단계로 돌아갈 조건: 완전한 요청과 게시된 대상이 지원 범위 안에서 검증됐을 때 후보 준비로 진행합니다.

해결되지 않았을 때: 필수 대상 참조가 없으면 설명용 값을 실제 식별자로 추측해 사용하지 않습니다.

설치 후 도구 목록