DongHyeonkaandClaude Opus 5
0650d91def
rewriting-technical-prose-naturally 를 서브에이전트 셋으로 나눠 56편에 적용했다. ai-tells.md 의 첫 절대로 다른 표현으로 바꾸는 대신 문장을 통째로 지웠다. 설명한 것의 중요성을 다시 평가하는 꼬리 19 이미 설명한 것을 추상어로 되풀이 19 독자에게 읽는 법을 지시하거나 오해를 가정 9 자료가 뒷받침하지 않는 덧붙인 이득 4 문서군 전체의 문형 편중도 풀었다 — 함께 27→7(한 묶음), 그대로 22→12(두 묶음), 하게 된다 1→0. 한 편에서 세 번 반복되던 「같은 병이 ~에서도 났다」와 두 기록에 같은 문장으로 있던 세 쌍을 갈랐다. 계약 제목 「여덟 자리」가 본문의 「여덟 곳」과 어긋나 있었다. 제목이 spatial-metaphor 규칙에도 걸리므로 계약과 기록을 함께 「여덟 곳」으로 맞췄다. 검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS · check_evidence --repo 문제 없음 · verify-tech-log-tree error 0 warn 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
82 lines
3.3 KiB
Markdown
82 lines
3.3 KiB
Markdown
---
|
|
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 -->
|