DongHyeonkaandClaude Opus 5
fd221353a3
SSOT 를 저장소에서 확인해 더 보강하고 그것으로 다시 썼다.
§7.2 참조 검사 SQL 을 문자열로 조립하는 실제 코드 — 컴파일러가 표 이름도
컬럼 이름도 보지 않는다는 것이 그 모양에서 드러난다
§11.2 section-heading-rank 가 미디어 쿼리 값을 먼저 걷어내는 이유(테스트 주석)
§16.1 질문 삭제는 참조가 둘뿐이라 같은 문제가 덜하다는 대조
Case 열 편과 Question 셋을 다시 썼다. Question 은 사실·가정·미지수·제약을 갈라
채우고 선택지마다 무엇을 감수하는지 적었다 — 오류 코드를 나누면 계약과 반입한 두
저장소가 함께 움직인다는 것처럼.
SSOT 62,643 → 68,319 자. 검사 넷 전부 통과한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.4 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | ||
|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | a-healthy-container-that-served-one-403 | 컨테이너는 healthy 였고 SPA 가 부팅에 필요한 파일 하나만 403 이었다 | only-visible-after-deploying | 배포해 봐야 드러난 것 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
컨테이너는 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 컨테이너 확인 방식 : 배포본에서 그 파일 경로를 직접 요청해 상태 코드 확인
재현 조건
- 빌드가 쓰는 설정 파일의 권한을 0600 으로 둔다
- 이미지를 배포한다 — 파드가 healthy 로 올라온다
- 그 파일 경로를 브라우저나 curl 로 요청한다 — 403 이 온다
본문
healthy 가 무엇을 확인했나
헬스 판정은 헬스 엔드포인트가 응답하는지를 본다. nginx 프로세스가 살아 있고 그 경로를 돌려주면 통과한다.
SPA 가 부팅에 필요한 설정 파일은 그 판정에 들어 있지 않다. 그래서 파드는 healthy 로 올라오고 사이트만 안 된다. 롤아웃도 정상으로 끝나므로 배포 도구는 아무 신호도 주지 않는다.
빌드가 쓴 권한
빌드가 그 설정 파일을 0600 으로 쓴다. 파일을 만든 사용자만 읽을 수 있고, nginx 를 돌리는 사용자는 다른 사용자다.
증상이 404 가 아니라 403 이라는 것이 원인을 좁혔다. 404 면 파일이 없는 것이고 403 이면 파일은 있는데 읽지 못하는 것이므로, 이미지에 파일이 들어갔는지부터 확인할 필요가 없었다.
이미지가 권한을 정규화하도록 고쳤다. 빌드 단계에서 쓰는 권한을 바꾸는 대신 이미지가 마지막에 정리하게 한 것은, 빌드 도구가 그 권한을 왜 그렇게 쓰는지가 이 저장소 밖의 사정이기 때문이다.
브라우저가 묻는 주소
같은 배포에서 favicon 도 404 였는데 원인이 달랐다. index.html 이 public/favicon.svg 를 참조한 적이 없다.
파일은 이미지에 들어 있었고 nginx 도 서빙했다. 브라우저는 참조가 없으면 /favicon.ico 를 묻고, 그 이름의 파일이 없어 404 를 받고 기본 아이콘으로 떨어졌다.
| 파일이 이미지에 있나 | nginx 가 서빙하나 | 무엇이 문제였나 | |
|---|---|---|---|
| 설정 파일 | o | o | 권한이 0600 이라 읽지 못함 |
| favicon | o | o | 아무도 그 이름을 요청하지 않음 |
둘 다 「파일이 없다」가 아니었다. 그래서 이미지를 열어 파일을 찾는 방식으로는 둘 다 정상으로 보인다 — 무엇이 실제로 요청되고 어떤 응답이 오는지를 봐야 갈린다.
확인하지 못한 것
이미지 안의 다른 파일 권한을 전수로 확인하지 않았다. 고친 것은 빌드가 쓰는 한 곳이다.