월요일 저녁, STARRY의 간판은 켜졌는데 문 앞의 작은 상태등은 아직 노란색이었다. 히토리가 “불이 켜졌으니 영업 중 아닌가요?”라고 묻자 니지카는 네 장의 점검표를 꺼냈다. 첫 장에는 process의 PID, 둘째에는 8080 LISTEN, 셋째에는 health UP, 마지막에는 SIGTERM 뒤 process와 port가 사라진 시간이 적혀 있었다. 실행 중이라는 사실과 손님을 받을 준비가 됐다는 사실은 서로 대신할 수 없었다.

료는 점검표 끝에 굵은 글씨로 덧붙였다. “kill -9는 퇴장 요청이 아니라 강제 퇴장. D3의 Stop-Process -Force도 정리 증거일 뿐 D1의 graceful SIGTERM 증거가 아니야.” 히토리는 같은 마지막 상태라도 과정의 의미가 다르다는 것을 처음 알았다. 파일이 40 byte보다 크고 placeholder가 없다는 validator 도장도 실제 PID와 종료 시간을 읽어 주지는 못했다.

---

화요일에는 공연용 장비를 싣는 작업장이 둘로 나뉘었다. 넓은 builder 작업장에는 Java 21 JDK와 Gradle이 있었고, 작은 runtime 매장에는 완성된 /app/app.jar와 Java 21 JRE만 들어갔다. 키타는 제한 출입증 10001을 목에 걸었다. EXPOSE 8080 표찰은 문 위치를 알려 줄 뿐 실제 문을 열거나 health를 보장하지 않았다.

상자를 닫기 전에 니지카는 .git, .gradle, build, evidence, env, log를 build context에서 제외했다. 그러나 료는 “ignore는 금고가 아니야. 이미 새어 나온 secret은 revoke·rotate가 먼저야”라고 잘랐다. image runner는 absolute learner path를 확인한 뒤에만 build하고, 성공 뒤 user·금지 경로·builder tool·hash를 검사해 temporary 영수증을 atomic replace했다.

---

수요일, 무대 뒤 창고에는 PostgreSQL 상자 하나만 놓였다. Compose 명부의 service는 exact db 하나였고 application은 container 안이 아니라 host JVM 배우로 무대에 올랐다. D3 runner가 db readiness를 기다리고 host bootRun을 시작해 PID·port·health·API를 관찰한 뒤, 마지막에는 process와 container와 volume이 모두 남지 않았는지 확인했다.

그때 히토리는 두 표에서 서로 다른 port를 발견했다. PDF와 Docker 표찰은 8080을 말했지만 packaged runner의 기본값은 28021이었다. 니지카는 어느 쪽도 지우지 않고 실제 invocation의 -Port와 manifest에 기록된 actual port를 최종 연결고리로 삼았다. 짧은 p701 command에 mandatory ProjectRoot가 빠진 것도 같은 방식으로 완전한 script 계약과 대조했다.

목요일에는 배경막 뒤에 설정표를 걸었다. URL과 username은 환경 변수로 들어왔고 password는 trusted terminal에서만 공급됐다. profile은 손님이 고르는 메뉴가 아니라 배포 시스템이 local·test·prod 설정 묶음을 선택하는 장치였다. 문서 모양이 안전해 보여도 actuator, startup log, shell history까지 보지 않으면 secret 비노출 Green은 아니었다.

---

금요일, 료가 DB 스위치를 잠시 내렸다. JVM은 살아 있어 liveness는 UP을 유지했지만 새 주문을 받을 준비가 없어서 readiness는 DOWN이 됐다. DB가 돌아온 뒤 readiness가 다시 UP이 되어야 traffic을 열었다. DB를 liveness에 넣으면 dependency 장애가 process 재시작 loop로 번질 수 있었다.

대기 시간에는 두 장의 비정본 SQL 연습표를 풀었다. Q33은 account별 직전 amount를 LAG로 붙여 첫 행 NULL과 21행 oracle을 확인했다. Q34는 customer별 최신순 ROW_NUMBER를 매겨 3+3+1+1, 총 8행을 남겼다. 둘 다 workbook 제공 정답이 아니라 table·status·tie-breaker 가정을 공개한 학습 예시였다.

---

토요일, 네 사람은 새 공연을 시작하지 않았다. D3가 남긴 host-app-manifest.json을 열어 teardown=1, container_absent=true, volume_absent=true를 읽었을 뿐이었다. 같은 hash의 영수증을 다시 읽었다고 새 lifecycle을 실행한 것은 아니다. D6의 역할은 producer를 가로채는 것이 아니라 증거 연결을 확인하고 새 stdout·resource-limit ownership claim을 만들지 않는 것이었다.

히토리는 마지막 표지에 적었다. “W21 D1–D6 RUNTIME NOT_RUN. source가 기대하는 Green marker와 우리가 실제로 실행한 Green은 다르다.” 그리고 p715의 D7, p719의 주간 통합, p720의 W22 표지는 다음 장으로 넘겼다. 켜진 간판, 열린 port, 준비된 dependency, 정리된 resource를 서로 다른 증거로 읽을 때에만 STARRY의 문이 안전하게 열렸다.