docs(TechLog): 글감 56개를 기록으로 쓴다

주제 13개 · Case 28 · Concept 5 · Reference 15 · Question 4 · Decision 4. 계약의 노드마다 종류가 요구하는 칸을 채우고, 본문이 있는 두 종류에는 SSOT 가 이미 그려 둔 도식 셋(value-boundaries · decision-path-404 · topic-variant-model)을 tech-log-studio/ 로 옮겨 붙였다. 새로 그린 그림은 없다. 검사 셋 전부 통과한다. check_body.mjs 56 편 중 본문이 있는 33 편 PASS check_prose.mjs 56 편 error 0 check_evidence.mjs --repo 포함 문제 없음 verify-tech-log-tree.py 프로젝트 5 · error 0 · warn 0 인용한 코드블록은 전부 SSOT 에서 찾아 대조했다. check_evidence.mjs 가 본문의 각 줄과 source 앵커와 계약 제목을 다시 확인한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 15:29:33 +09:00
parent 6955611439
commit f6c825e858
62 changed files with 6381 additions and 186 deletions
@@ -0,0 +1,83 @@
+---
+kind: CASE
+slug: a-build-argument-left-out
+title: 배포 인자를 빠뜨려 배포본이 존재하지 않는 주소를 불렀다
+topic: only-visible-after-deploying
+topicName: 배포해 봐야 드러난 것
+project: TechLog
+status: 게시 전
+lastVerifiedOn: 2026-09-04
+sourceRevision: tech-log@2026-09-02
+source:
+  - final/document.md#§12.2
+---
+
+# 배포 인자를 빠뜨려 배포본이 존재하지 않는 주소를 불렀다
+
+프론트 이미지를 빌드하면서 API 주소 인자를 넘기지 않았다. 배포본이 존재하지 않는 주소를 불렀다. Dockerfile 이 그 경고를 문자 그대로 적어 두고 있었다.
+
+## 관계
+
+- **레지스트리 없이 tar 를 import 하는 배포 경로**
+  왜 이 인자가 이미지에 굳는지가 그 개념에 있다.
+- **배포 전에 사람이 돌려야 하는 것과 그 함정**
+  이 사건 뒤에 목록으로 굳혔다.
+- **컨테이너는 healthy 였고 SPA 가 부팅에 필요한 파일 하나만 403 이었다**
+  같은 배포에서 드러난 다른 사건이다.
+
+## 문제
+
+배포본이 API 를 부르는데 존재하지 않는 주소로 나갔다. 화면은 데이터를 받지 못했다.
+
+빌드는 성공했고 이미지도 정상적으로 올라왔다.
+
+## 결론
+
+프론트 이미지 빌드에 `RUNTIME_API_BASE_URL` 을 넘기지 않으면 기본값이 이미지에 굳는다. 그 기본값이 존재하지 않는 주소다.
+
+Dockerfile 이 그 경고를 문자 그대로 적어 두고 있는데도 빠뜨렸다.
+
+`kubectl rollout undo` 로 되돌리고 다시 빌드했다.
+
+## 검증 환경
+
+프론트 이미지 : APP_PROFILE · VITE_ROUTER_BASE_PATH · RUNTIME_API_BASE_URL · VITE_BUILD_ID · VITE_COMMIT_SHA · RELEASE_ID · CI_RUNNER_IMAGE · SOURCE_DATE_EPOCH
+런타임 : k3s
+확인 방식 : 배포본의 네트워크 요청에서 실제로 나가는 주소 확인
+
+## 재현 조건
+
+1. 프론트 이미지를 API 주소 인자 없이 빌드한다
+2. 배포하고 사이트를 연다
+3. 개발자도구 네트워크에서 API 요청이 어느 호스트로 나가는지 본다
+
+## 본문
+
+<!-- body:start -->
+
+## 빌드 인자는 이미지에 굳는다
+
+이 프론트는 API 주소를 빌드 인자로 받는다. 런타임 환경 변수가 아니므로 배포한 뒤에는 바꿀 수 없고, 잘못 넣으면 다시 빌드해서 다시 올려야 한다.
+
+인자를 넘기지 않으면 기본값이 들어간다. 그 기본값은 존재하지 않는 주소다.
+
+## 요구하는 인자 전부
+
+```text
+APP_PROFILE=production
+VITE_ROUTER_BASE_PATH=/
+RUNTIME_API_BASE_URL=https://hyeonworks.com/     ← 빠뜨리면 api.example.com
+VITE_BUILD_ID / VITE_COMMIT_SHA / RELEASE_ID
+CI_RUNNER_IMAGE=node@sha256:…                    ← 반드시 @sha256 다이제스트
+SOURCE_DATE_EPOCH
+```
+
+## 되돌리고 다시 빌드했다
+
+`kubectl rollout undo` 로 이전 리비전으로 되돌린 뒤 인자를 넣어 다시 빌드하고 다시 올렸다.
+
+## 확인하지 못한 것
+
+빌드가 이 인자를 요구하도록 막지 않았다. 빠뜨리면 여전히 빌드는 성공하고 배포본만 틀린다. 지금 남은 것은 인자 목록을 적어 둔 것뿐이다.
+
+<!-- body:end -->
@@ -0,0 +1,81 @@
+---
+kind: CASE
+slug: a-healthy-container-that-served-one-403
+title: 컨테이너는 healthy 였고 SPA 가 부팅에 필요한 파일 하나만 403 이었다
+topic: only-visible-after-deploying
+topicName: 배포해 봐야 드러난 것
+project: TechLog
+status: 게시 전
+lastVerifiedOn: 2026-09-04
+sourceRevision: tech-log@2026-09-02
+source:
+  - final/document.md#§12.4
+  - final/document.md#§12.5
+---
+
+# 컨테이너는 healthy 였고 SPA 가 부팅에 필요한 파일 하나만 403 이었다
+
+컨테이너는 healthy 로 올라왔는데 SPA 가 부팅되지 않았다. nginx 가 설정 파일 하나를 읽지 못해 그 파일만 403 을 돌려줬다. 빌드가 그 파일을 0600 으로 쓰고 있었다.
+
+## 관계
+
+- **레지스트리 없이 tar 를 import 하는 배포 경로**
+  이미지 안의 상태가 왜 배포에서만 드러나는지가 그 개념에 있다.
+- **nginx 가 모르는 라우트는 새로고침에서 404 다**
+  같은 웹 서버가 서빙 목록 때문에 낸 다른 사건이다.
+- **배포 인자를 빠뜨려 배포본이 존재하지 않는 주소를 불렀다**
+  같은 배포에서 드러난 다른 사건이다.
+
+## 문제
+
+파드가 healthy 로 올라왔다. 사이트를 열면 화면이 그려지지 않았다.
+
+컨테이너는 살아 있고 nginx 도 응답한다. SPA 가 부팅에 필요한 설정 파일 하나만 403 이었다.
+
+## 결론
+
+빌드가 그 설정 파일을 0600 으로 쓴다. nginx 를 돌리는 사용자가 그 파일을 읽지 못한다.
+
+healthy 판정은 헬스 엔드포인트를 본다. 그 엔드포인트는 이 파일을 읽지 않으므로 통과한다.
+
+이미지가 권한을 정규화하도록 고쳤다.
+
+같은 배포에서 favicon 도 404 였다. `index.html` 이 `public/favicon.svg` 를 참조한 적이 없다. 파일은 이미지에 들어 있었고 nginx 도 서빙했지만 브라우저는 `/favicon.ico` 를 물었고 404 를 받아 기본 아이콘으로 떨어졌다.
+
+## 검증 환경
+
+tech-log-frontend : 83409be
+런타임 : nginx 컨테이너
+확인 방식 : 배포본에서 그 파일 경로를 직접 요청해 상태 코드 확인
+
+## 재현 조건
+
+1. 빌드가 쓰는 설정 파일의 권한을 0600 으로 둔다
+2. 이미지를 배포한다 — 파드가 healthy 로 올라온다
+3. 그 파일 경로를 브라우저나 curl 로 요청한다 — 403 이 온다
+
+## 본문
+
+<!-- body:start -->
+
+## healthy 가 무엇을 확인했나
+
+헬스 판정은 헬스 엔드포인트가 응답하는지를 본다. nginx 프로세스가 살아 있고 그 경로를 돌려주면 통과한다.
+
+SPA 가 부팅에 필요한 설정 파일은 그 판정에 들어 있지 않다. 그래서 컨테이너는 정상이고 사이트만 안 된다.
+
+## 빌드가 쓴 권한
+
+빌드가 그 파일을 0600 으로 쓴다. 파일을 만든 사용자만 읽을 수 있고, nginx 를 돌리는 사용자는 다른 사용자다.
+
+이미지가 권한을 정규화하도록 고쳤다.
+
+## 브라우저가 묻는 주소
+
+같은 배포에서 favicon 도 404 였다. 이유가 달랐다 — `index.html` 이 `public/favicon.svg` 를 참조한 적이 없다. 파일은 이미지에 들어 있었고 nginx 도 서빙했지만, 브라우저는 참조가 없으면 `/favicon.ico` 를 묻는다. 그 이름의 파일이 없어 404 를 받고 기본 아이콘으로 떨어졌다.
+
+## 확인하지 못한 것
+
+이미지 안의 다른 파일 권한을 전수로 확인하지 않았다. 고친 것은 빌드가 쓰는 한 곳이다.
+
+<!-- body:end -->