전체 경로 검증과 장애 진단

참가자 AWS 배포 트랙, 예상 약 30분입니다. 수동 DNS를 포함한 공개 경로가 준비되어 있어야 합니다. 이 장의 라이브 검증은 Bedrock을 호출하고 새 실행을 만들므로 이용량이 발생합니다.

로컬 코드 검사, AWS 구성 검사, 실제 계획·물리·저장, 브라우저 조작을 구분해 증거를 남깁니다. 다른 배포에서 통과한 과거 결과나 교재의 읽음 표시는 본인 배포의 검증 결과가 아닙니다.

1. 검사 대상 고정

set -euo pipefail
cd "$ROBOT_LAB"
test -f infra/workshop-binding.json
umask 077
mkdir -p .local/evidence
python3 -B scripts/deploy.py status --stack app \
  > .local/evidence/app-status.json
export ROBOT_URL="$(python3 -c 'import json; print(json.load(open(".local/evidence/app-status.json"))["outputs"]["PublicUrl"])')"
printf '검사할 내 배포: %s\n' "$ROBOT_URL"

모든 브라우저·HTTP 검사가 이 URL을 가리켜야 합니다. 루트 운영 사이트나 다른 참가자의 주소를 검증 대상으로 쓰지 않습니다.

2. 로컬 계약과 실제 물리 검사

npm test
npm run build
.venv/bin/python -m unittest discover -s agent/tests -v
.venv/bin/python -m unittest discover -s tests/simulation -v
python3 -B scripts/deploy.py lint

MuJoCo 검사에는 여러 배치와 파랑 우선 쌓기, 그리퍼 힘 0, 마찰 0, 놓은 뒤 밀려난 물체가 포함됩니다. 실패해야 하는 조건이 성공으로 바뀌었다면 테스트 기대값을 느슨하게 바꾸지 않습니다.

3. AWS 구성 검사

python3 -B scripts/deploy.py configure-logs
set -o pipefail
python3 .local/tools/verify-aws.py \
  | tee .local/evidence/aws-verification.jsonl

각 passed와 마지막 verification: passed를 확인합니다. 이 도구는 새 물리 실행이나 모델 호출을 하지 않습니다. 본인의 Runtime 로그 보존, Private Fargate, SG 연결, CloudFront 설정, HTTPS, S3/DynamoDB까지 검사합니다.

tee를 사용할 때는 pipefail을 켜 검사 실패가 파이프의 성공으로 숨겨지지 않게 합니다.

4. 실제 모델 → 물리 → 저장 검증

python3 .local/tools/verify-demo.py --seed 123
python3 -m json.tool .local/evidence/live-verification.json

이 명령은 다음을 수행합니다.

1. 본인 공개 주소에서 새 세션을 만들고 플래너를 두 번 호출합니다.
2. 파랑→빨강→주황 계획 순서를 확인하고 새 배치 123의 쌓기 실행을 생성합니다.
3. 실제 MuJoCo 결과와 모든 물리 검사를 확인합니다.
4. DynamoDB의 완료 상태와 S3 JSON을 직접 조회해 API 결과와 비교합니다.
5. 다른 세션의 결과 접근이 404인지 검사합니다.

보고서의 publicUrl, planner, runId, seed, metrics, checks를 확인합니다. placed: 3, success: true와 검사 전체 통과가 함께 있어야 합니다. 위치 오차는 시드·환경에 따라 달라지므로 과거 문서의 소수점 값을 그대로 기대하지 않습니다.

planRequestSeconds는 같은 새 세션의 첫 요청과 반복 요청 시간입니다. 네트워크와 모델 추론을 포함하며 AgentCore만의 추가 지연 측정이 아닙니다.

5. 실제 브라우저 검사

설치된 Playwright Chromium을 사용합니다. 준비되지 않았다면 다음 설치는 브라우저 바이너리를 다운로드합니다.

npx playwright install chromium
set -o pipefail
BROWSER_BASE_URL="$ROBOT_URL" \
BROWSER_ARTIFACTS="$ROBOT_LAB/.local/evidence/browser" \
npm run test:browser | tee .local/evidence/browser-check.log

검사에는 데스크톱·모바일 렌더링, 재생/탐색, 발표 모드, 실제 파랑 우선 쌓기와 빨간 상자만 옮기는 흐름이 포함됩니다. 마지막 결과의 passed: true, 검사 URL, 캡처 디렉터리를 확인합니다.

BROWSER_SKIP_LIVE=1은 새 물리 실행 일부를 생략합니다. 플래너 호출까지 없는 오프라인 검사로 보아서는 안 되며, 전체 경로 완료 근거로 사용하지 않습니다.

서버가 한 번에 한 물리 실행을 받으므로 수동 시연과 브라우저 검사를 동시에 진행하지 않습니다. 브라우저 검사는 429 경합을 제한적으로 재시도하지만, 혼잡이 계속되면 실패를 기록하고 다시 시간을 잡습니다.

6. 실패 시 재개: 장애를 구간별로 좁히기

“빨간 상자만 오른쪽 트레이로 옮겨줘” 뒤 연결 오류가 보이면, 먼저 응답의 HTTP 상태와 Content-Type을 봅니다. CloudFront의 HTML 오류 페이지를 API JSON으로 읽으려다 생긴 오류일 수 있습니다.

상태 코드나 물리 실패 원인을 보존하고 해결 후 해당 검사부터 다시 수행합니다. API 오류를 숨기기 위해 규칙 모드로 바꾸거나 실패 JSON을 성공으로 편집하지 않습니다. 자세한 절차는 문제 해결에 있습니다.

7. 본인 검증 기록 남기기

참가자 작업 공간의 .local/evidence/에 날짜, 공개 URL, release, 검사 명령·종료 상태, 실행 ID·배치·계획 순서, 물리 검사, 저장소 일치 여부, 생략/실패 항목을 기록합니다. 쿠키·CSRF·Secret·원문 로그는 넣지 않습니다.

완료 체크리스트

• 로컬·AWS 구성·실제 모델/물리/저장·브라우저 근거를 분리했습니다.
• 본인 URL에서 새 배치와 요청 순서로 실제 실행했습니다.
• S3/DynamoDB 일치와 다른 세션의 404를 확인했습니다.
• 데스크톱·모바일 검사와 캡처를 확인했습니다.
• 수행하지 못한 검사는 미검증으로 남겼습니다.

AI CLI 카드: 11. 검증 · 다음: 12. 시나리오 확장

AI CLI 프롬프트 카드

아래 프롬프트를 복사해 실습 EC2에서 선택한 Codex, Kiro CLI, Claude Code의 대화 입력창에 붙여넣습니다. Markdown 카드 다운로드

Robot Atlas 워크숍 11장의 검증을 수행하세요.
ROBOT_REPO/workshop/chapters/11-validation.md를 읽고 ROBOT_LAB의 바인딩과
App PublicUrl을 확인하세요. 루트 운영 서비스나 다른 참가자 주소는 검사하지 마세요.

검증을 나누어 진행:
1. npm test/build, Python Agent 계약, 실제 MuJoCo, 배포 lint.
2. .local/tools/verify-aws.py: AWS 구성·공개 HTTPS. 모델 호출/새 실행은 하지 않는 검사.
3. .local/tools/verify-demo.py --seed 123: 실제 플래너 2회, 파랑→빨강→주황 실행,
   물리 검사, DynamoDB 상태, S3/API 일치, 다른 세션의 404.
4. BROWSER_BASE_URL을 본인 URL로 고정한 실제 데스크톱·모바일 브라우저 검사.
두 Python 검증기는 reference/resources.md의 코드로 본인 app에 준비합니다.

근거:
각 명령의 종료 상태, 날짜, URL, release, run ID, seed, 계획 순서, metrics/checks,
캡처 위치와 미검증 항목을 참가자 .local/evidence에 남기세요.
tee를 쓰면 pipefail로 실패 상태를 보존하세요.
BROWSER_SKIP_LIVE=1은 전체 경로 검증이 아니고 모델 호출도 남을 수 있습니다.

진단 원칙:
연결 오류는 HTTP 상태·Content-Type·구간별 상태로 좁히세요.
정적 정상/API 502는 origin DNS·TLS·Host·ALB target을 확인하세요.
429는 실행 경합을 먼저 확인하고 제한적으로 재시도하세요.
물리 실패는 실패로 남기고 endpoint나 규칙 모드 전환으로 숨기지 마세요.
취소 후 늦은 응답이 성공을 덮어쓰지 않아야 합니다.

로컬 테스트 통과, 과거 운영 검증, 교재 읽음 표시는 본인 클라우드 리허설 증거가 아닙니다.
Secret·쿠키·CSRF·원문 대화는 보고서에서 제외하세요.
수정은 본인 app으로 제한하고, 배포가 필요하면 새 manifest와 본인 변경 세트를 검토하세요.
최종 보고에 실제 통과·실패·생략을 구분하세요.