월요일, STARRY 제어실 벽에는 다섯 개의 계기판이 걸렸다. 니지카는 요청 속도와 오류와 지연을 한데 섞지 않고 http request, 완료 이체, 재시도, 대사 불일치, 오래 멈춘 idempotency 작업으로 나눴다. 히토리가 requestId와 accountId를 tag에 적으려 하자 료가 지웠다. “한 번만 나타나는 이름은 로그의 실마리이지, 수천 개 time series를 만드는 계기판 이름이 아니야.”

catalog validator는 최소 다섯 행과 다섯 required 이름, type·LOW 표찰과 충분한 meaning을 살폈지만 실제 meter가 살아 있는지는 말하지 않았다. learner-owned CSV의 actual hash가 있어야 D1 evidence가 닫혔고, 이 preview에는 그 실행이 없었다.

---

화요일, 키타는 이체 한 건을 연주처럼 감쌌다. 성공하면 completed counter가 올랐고 RuntimeException이면 business_rejected를 올린 뒤 예외를 다시 던졌다. 곡이 끝나든 끊기든 Timer.Sample은 finally에서 멈췄다. 두 개의 SimpleMeterRegistry test는 그 좁은 행동을 설명했지만, 아직 Gradle이 실제로 연주한 기록은 아니었다.

히토리는 tests=2라는 악보 숫자 옆에 testsExecuted=0을 함께 적었다. unit test가 맞아도 production transfer, exporter, dashboard, p95가 자동으로 Green이 되는 것은 아니었다.

---

수요일, 모든 요청에는 빨간 실 하나가 달렸다. 손님이 유효한 X-Request-Id를 가져오면 그대로 응답에 돌려주고, 없거나 모양이 틀리면 UUID 같은 새 실을 묶었다. 응답이 끝난 뒤에는 finally에서 MDC 실을 풀어 다음 손님의 기록과 엉키지 않게 했다. canonical gate는 정확히 두 test와 incident-runbook hash만 한 영수증에 묶었다.

대기 시간에는 Q37 표를 펼쳤다. transaction 하나에 leg 둘, audit 셋을 동시에 붙이자 여섯 줄이 됐다. child를 transaction별로 먼저 모아 한 줄씩 만든 뒤 join하니 금액 SUM이 중복되지 않았다. 원문은 문제만 주었기에 2×3=6은 비정본 반례라는 꼬리표를 달았다.

---

목요일, 지하 rehearsal DB에서 두 transaction이 같은 probe 한 행을 향해 UPDATE했다. holder가 value를 1로 올리고 잠시 머무는 동안 waiter는 Lock에서 기다렸다. blocker가 보인 뒤 holder가 commit하자 wait는 0으로 사라지고 최종값은 2가 됐다. Compose가 만든 schema와 volume은 마지막에 깨끗이 치웠다.

료는 p766의 짧은 ACCESS EXCLUSIVE·SELECT 메모에 선을 긋고 packaged canonical script를 펼쳤다. 구현과 Green marker는 분명히 UPDATE/UPDATE·ROW_UPDATE였다. 오래된 요약보다 실행 권한을 가진 정본을 우선하고, 그 충돌 자체도 숨기지 않았다.

---

금요일, 세 경보가 벽에 걸렸다. 5xx rate, transfer p95, reconciliation mismatch였다. 각 표에는 window와 threshold뿐 아니라 severity, owner, 첫 query, runbook, 멈추는 조건이 적혔다. 그러나 alerts.md의 크기와 hash를 확인한 도장은 실제로 경보가 울리고 notification이 도착했다는 증거가 아니었다.

Q38에서는 두 기간의 SUCCESS 고객 집합을 DISTINCT한 뒤 INTERSECT했다. seed를 읽으면 expected customer_id=1 김민수였지만 query를 실행한 결과가 아니므로 비정본·미실행 표찰을 남겼다.

---

토요일, 네 사람은 incident runbook을 계단처럼 정리했다. symptom에서 impact, check, mitigate, recovery verification, follow-up으로 내려갔다. DB timeout이면 readiness→pool→network→DB wait 순서로 좁혔고, 대사 불일치면 계좌를 격리해 source를 확인한 뒤 승인된 correction만 허용했다. 숫자를 빨리 맞추려고 balance를 자동 UPDATE하는 문은 잠가 두었다.

마지막 칠판에는 learner, local, manual, external 네 칸이 있었다. D3 requestId gate와 D4 db-wait runner는 packaged local owner였지만 preview가 실행하지 않았다. D5·D6의 문서 의미는 사람이 봐야 했고 dashboard·notification은 공식 URL과 시간이 없으므로 NOT_RUN_EXTERNAL이었다.

히토리는 마지막에 적었다. “W23 D1–D6 RUNTIME NOT_RUN. 보이는 marker보다 누가 실행했고 무엇까지 닫았는지가 먼저다.” p780 하단의 D7과 p783 하단 이후 주간 통합은 다음 장에 남겼다.