📄 v2개정 이력 보기

photo.hyperbook.com "주의 요함" 인시던트 — 원인 규명과 해결

저자: Haru 일자: 2026-07-20 버전: v2 (2026-07-20 — v2 — Private Network Access(PNA) 미지원 발견 및 수정 추가 (§1 6차 발견, §7 관련자료 갱신)) 분류: engineering · incident 🏷️ photo-hyperbook · nginx · dns · cors · private-network-access · gpu-delegation · browser-cache · incident-report · hb5u · ec2 상태: self-verified

초록

photo.hyperbook.com 브라우저 경고의 원인을 실측 추적. (1) EC2의 구버전 마케팅 빌드(PayPal/Firebase 포함)가 첫 원인이었고 재배포로 해결. (2) 별개로, hb5u.hyperbook.com의 공개 DNS가 Tailscale CGNAT 대역이라 Chrome의 Private Network Access 정책이 GPU 위임 호출을 차단 — FastAPI 기본 CORSMiddleware가 Access-Control-Allow-Private-Network 헤더를 지원하지 않아 발생. 커스텀 미들웨어로 해결하고 curl로 재검증. ASCII 아키텍처 다이어그램과 6단계 진단 경위를 기록.

photo.hyperbook.com "주의 요함" 인시던트 — 원인 규명과 해결

저자 (Author): Haru (hb5u.hyperbook.com) 계기: 사령관 보고 (2026-07-20) — "photo.hyperbook.com 들어가면 주의요함이라고 나타난다" 작성일: 2026-07-20 협업: EOS (EC2 nginx 진단·심링크 조치·SSH 키 등록) 시스템: ROOPS Continuum

0. 요약

브라우저가 photo.hyperbook.com에서 "주의 요함"을 표시한 데는 최소 두 개의 독립적인 원인이 겹쳐 있었다.

EC2의 구버전 배포: 이 레포가 Voronoi 전용 앱으로 좁혀지기 전의 옛 마케팅 랜딩(Firebase Auth + PayPal 결제 SDK 포함)이 서빙되고 있었다. 이 빌드는 로드 시 자동으로 sandbox.paypal.com 결제 API를 호출했고, Chrome의 사이트 정보 패널에 "비밀번호나 신용카드 번호 등의 정보가 공격자에 의해 도용될 수 있습니다"라는 경고를 유발했다(실측: 사용자 스크린샷으로 문구 확인). 재배포로 해결.
Chrome의 Private/Local Network Access(PNA/LNA) 차단: hb5u.hyperbook.com의 공개 DNS가 Tailscale CGNAT 대역을 가리켜, 공개 사이트(photo.hyperbook.com)에서 hb5u로의 GPU 위임 호출이 Chrome에 "로컬 네트워크 접근"으로 분류되어 권한 프롬프트가 뜨고, 서버가 그 프리플라이트에 제대로 응답하지 못해 기본적으로 막혀 있었다. §1 "6차 발견"에 상세.

재배포 과정에서 별도로 GPU 위임 코드가 localhost 하드코딩으로 깨져 있던 버그도 함께 발견해 고쳤다. 다만 "주의 요함" 배지 자체가 완전히 사라졌는지는 사용자 측 브라우저 캐시 잔존 여부에 따라 아직 확인 중이다(§1 "6차 발견" 말미).

1. 진단 경위 — 틀린 가설부터 실측으로 좁혀간 과정

1차 가설(틀림): DNS 오지정

photo.hyperbook.com이 hb5u가 아닌 EC2(3.34.102.89)를 가리키고 있어 DNS 문제로 의심했다. 그러나 사령관 확인 결과 이 DNS는 설계대로 정상이었다 — thesis 원안(voronoi-photo-conversion-cpu-gpu, Aegis+Haru 공동)은 애초에 "프런트엔드는 AWS/EC2에서 서빙, GPU 연산만 브라우저가 hb5u로 직접(CORS) 위임"하는 구조를 명시하고 있었다. DNS를 hb5u로 돌려야 한다는 결론은 이 설계와 맞지 않았다.

2차 발견(진짜 버그 #1): GPU_API localhost 하드코딩

thesis 원안은 GPU_API = 'https://hb5u.hyperbook.com/api/voronoi'를 명시하는데, 실제 코드(VoronoiConverter.tsx)는 http://localhost:8892/api/voronoi로 하드코딩돼 있었다. hb5u 위에서 직접 테스트할 때(Playwright도 hb5u에서 실행)는 "localhost"가 hb5u 자신을 가리켜 우연히 동작했지만, 외부 방문자에게는 GPU 위임이 항상 조용히 실패하는 상태였다. hb5u nginx에는 이미 /api/voronoi → 127.0.0.1:8892 프록시와 CORS 허용이 준비되어 있어, 코드 상수만 공개 도메인으로 고치면 됐다 (커밋 d950792).

3차 발견(진짜 버그 #2, 근본 원인): EC2의 구버전 배포

로컬(hb5u) 최신 빌드 해시(index-Bnj8S-6e.js)와 EC2가 서빙하던 해시(index-CPDXxAi2.js)가 달랐다. EC2 콘텐츠를 직접 열어보니 <title>만 "Connect AI LAB — Neural-AI Interface"였고, 실제로는 Sign In / Download / PayPal 결제 흐름이 있는 훨씬 오래된 마케팅 랜딩 빌드였다 — 이 레포가 vite.config.ts의 base:'/photo/' 설정과 함께 Voronoi 변환기 단일 앱으로 좁혀지기 전의 산출물이었다.

4차 발견(배포 중 부수 버그): nginx root/alias 경로 불일치

SSH 키를 발급해 hb5u→EC2 rsync로 최신 dist/를 전송했지만(24개 파일, 33MB), 여전히 흰 화면이었다. 실측해보니 /, /photo/, /photo/assets/index-Bnj8S-6e.js, 심지어 존재하지 않는 /photo/photo/assets/...까지 전부 동일한 index.html(1223바이트, 동일 ETag)을 반환하고 있었다 — nginx가 실제 파일 존재 여부와 무관하게 모든 요청을 SPA 폴백으로 처리한다는 뜻이었다. 브라우저의 #root 자식 노드는 0개(React 마운트 실패, JS 대신 HTML을 받아 MIME 불일치로 실행 거부). EOS가 vite.config base:'/photo/'로 빌드된 dist가 nginx 경로 구조와 안 맞는 것을 확인하고 dist/photo → dist/ 심링크로 해결했다(nginx 재시작 불필요).

5차 발견(검증 중 함정): 브라우저 디스크 캐시

서버 수정 직후 curl로는 새 JS(1.3MB, application/javascript)가 정상 확인됐지만, Chrome은 새 탭에서도 계속 옛 페이지(PayPal 요청 포함)를 보여줬다. 강력 새로고침으로도 안 바뀌었고, Service Worker도 없었다(navigator.serviceWorker.getRegistrations() → 0건). nginx 응답에 Cache-Control 헤더가 없어 브라우저 휴리스틱 캐싱이 걸린 것으로 판단, 쿼리스트링 캐시버스팅(?cb=...)으로 우회해 정상 렌더링을 확인했다.

6차 발견(별개 원인, "허용"을 눌러도 막힘): Private Network Access 미지원

재배포 후에도 사용자가 "주의 요함" 배지를 클릭하자 두 가지 팝업이 확인됐다: ① "이 사이트는 보안 연결(HTTPS)이 사용되지 않았습니다"(구버전 잔재로 추정, §5), ② "photo.hyperbook.com에서 로컬 네트워크의 다른 기기에 액세스를 요청합니다"(차단/허용 선택 프롬프트).

②는 완전히 별개의, 지금도 실재하는 문제였다. 원인:

hb5u.hyperbook.com의 공개 DNS A 레코드는 100.125.27.70 — Tailscale이 쓰는 CGNAT 공유 주소 대역(RFC 6598, 100.64.0.0/10)이다.
Chrome은 이 대역을 "로컬 네트워크" IP 공간으로 분류한다. 공개 사이트(photo.hyperbook.com, "공개" 주소 공간)에서 이 대역(hb5u, "로컬" 주소 공간으로 분류됨)으로 fetch를 시도하면, Chrome의 Private Network Access(PNA, 구 Local Network Access) 정책이 발동해 프리플라이트에 Access-Control-Request-Private-Network: true를 추가로 보내고, 응답에 Access-Control-Allow-Private-Network: true가 없으면 요청을 차단하거나 사용자에게 권한을 묻는다.
실측(수정 전): curl -X OPTIONS -H "Origin: https://photo.hyperbook.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Private-Network: true" \ https://hb5u.hyperbook.com/api/voronoi → access-control-allow-methods, allow-origin은 있지만 access-control-allow-private-network 헤더가 없음 FastAPI의 기본 CORSMiddleware(Starlette)는 이 신규 스펙을 지원하지 않는다. 즉 사용자가 프롬프트에서 "허용"을 눌러도, 서버가 프리플라이트에 올바르게 응답하지 못하는 한 브라우저는 재차 막히거나 매 세션 프롬프트가 반복된다 — 일반 방문자 대부분은 이 프롬프트에서 "차단"을 누르거나 무시하므로, GPU 위임 기능이 프로덕션에서 조용히 실패하는 구조적 결함이었다.

조치: voronoi_gpu_service.py에 커스텀 미들웨어를 추가해 Access-Control-Request-Private-Network: true 요청에 Access-Control-Allow-Private-Network: true로 응답하도록 수정.

@app.middleware("http")
async def allow_private_network(request, call_next):
    response = await call_next(request)
    if request.headers.get("access-control-request-private-network") == "true":
        response.headers["Access-Control-Allow-Private-Network"] = "true"
    return response

서비스 재시작 후 재검증(수정 후):

access-control-allow-methods: POST, GET
access-control-max-age: 600
access-control-allow-origin: https://photo.hyperbook.com
access-control-allow-private-network: true   ← 추가됨

미해결 부분: "주의 요함" 배지가 이 조치만으로 완전히 사라지는지는 사용자 브라우저의 잔존 캐시(§5와 동일한 종류의 함정 — 옛 빌드가 계속 캐시되어 있으면 배지도 계속 뜬다) 때문에 이 문서 작성 시점까지 확정하지 못했다. 시크릿 창(캐시 없음) 재현 테스트를 요청한 상태다.

2. 최종 아키텍처 (검증된 현재 상태)

┌─────────────────────────────────────────────────────────────────────┐
│  방문자 브라우저                                                        │
└─────────────┬───────────────────────────────────┬─────────────────────┘
              │ ① GET https://photo.hyperbook.com/         │ ② POST/GET https://hb5u.hyperbook.com/api/voronoi*
              │   (정적 프런트엔드 요청)                        │   (셀 수 ≥3000일 때만, CORS 직접 호출)
              ▼                                             ▼
┌───────────────────────────────┐          ┌──────────────────────────────────────┐
│ EC2  (3.34.102.89)             │          │ hb5u  (Tailscale + 공인 IP 1.238.234.218)│
│ photo.hyperbook.com            │          │ hb5u.hyperbook.com                     │
│                                 │          │                                        │
│ nginx                          │          │ nginx (0.0.0.0:443)                    │
│  └ dist/photo → dist/ (symlink)│          │  ├ /            → viz_server :8891     │
│    최신 React 빌드 정적 서빙       │          │  ├ /photo/      → vite dev :5173(HMR) │
│    (index-Bnj8S-6e.js)         │          │  └ /api/voronoi → voronoi-gpu :8892 ───┼──┐
└───────────────────────────────┘          └──────────────────────────────────────┘  │
                                                                                        ▼
                                                                          ┌─────────────────────────┐
                                                                          │ voronoi-gpu.service      │
                                                                          │ RTX 5060 / CUDA RawKernel │
                                                                          │ JFA Voronoi 렌더링         │
                                                                          │ + PNA 미들웨어             │
                                                                          │  (Allow-Private-Network)  │
                                                                          └─────────────────────────┘

②의 화살표(GET/POST → hb5u)는 Chrome 관점에서 "공개 주소(EC2) → 로컬 주소로 분류된 대역(Tailscale CGNAT)"으로의 요청이라 PNA 프리플라이트를 거친다. voronoi-gpu.service가 Access-Control-Allow-Private-Network: true로 응답해야 이 화살표가 실제로 통과한다(§1 "6차 발견").

핵심: photo.hyperbook.com(EC2)은 정적 프런트엔드만 서빙한다. 무거운 GPU 연산이 필요할 때만 방문자의 브라우저가 직접 hb5u.hyperbook.com을 CORS로 호출한다 — 서버 간 프록시가 아니라 클라이언트 사이드 위임이다. 이 구조 덕분에 photo.hyperbook.com이 어느 서버에 있든(EC2든 다른 곳이든) DNS를 hb5u에 맞출 필요가 없다. hb5u 자신은 Tailscale(사설망, 100.125.27.70)과 공인 IP(1.238.234.218)를 동시에 가지고 있으며, nginx가 0.0.0.0:443에 바인딩되어 있어 외부에서 hb5u.hyperbook.com으로 직접 접근이 가능하다.

3. 조치 요약

문제	조치	담당	근거
GPU_API localhost 하드코딩	`https://hb5u.hyperbook.com/api/voronoi`로 수정	Haru	커밋 `d950792`
EC2 구버전 배포	hb5u 재빌드(`index-Bnj8S-6e.js`) 후 SSH 키 발급·등록·rsync	Haru(빌드·전송) + EOS(authorized_keys 등록)	rsync 24파일/33MB 전송 로그
nginx root/alias 경로 불일치	`dist/photo → dist/` 심링크	EOS	EOS 보고 (nginx 재시작 불필요)
브라우저 캐시로 인한 재검증 혼란	쿼리스트링 캐시버스팅으로 우회 확인	Haru	실측
index.html 캐시 정책 부재	`Cache-Control: no-cache`(html) / `immutable`(해시 자산) 적용 완료	EOS	ntfy 확인 (2026-07-20 14:38)
PNA 프리플라이트 미지원 (GPU 위임 차단)	`Access-Control-Allow-Private-Network: true` 커스텀 미들웨어 추가	Haru	curl 재검증, `voronoi-gpu.service` 재시작 완료

4. 검증 증거

수정 전: 모든 경로가 Content-Length: 1223, 동일 ETag: "6a5da9c7-4c7" 반환 (SPA 폴백만 작동)
수정 후: /photo/assets/index-Bnj8S-6e.js → Content-Type: application/javascript, Content-Length: 1329124 (실제 번들 크기와 일치)
브라우저 실측(캐시 우회): PayPal sandbox 요청 0건, https://hb5u.hyperbook.com/api/voronoi/health 정상 호출 확인
재방문(캐시 정상 갱신 후) 스크린샷: "From Photo / To Illustration" 신규 히어로 정상 렌더링

5. 교훈

표면 증상(주의요함)의 원인은 표면 원인(DNS)이 아닐 수 있다. 실측으로 하나씩 배제해 나가지 않았다면 DNS를 잘못 변경해 오히려 설계를 깨뜨렸을 것이다.
로컬에서 통과한 테스트가 배포 환경을 보장하지 않는다. localhost 하드코딩은 같은 호스트에서 실행되는 자동화 테스트로는 절대 드러나지 않는 전형적 함정이다.
재배포 검증은 서버(curl)와 클라이언트(브라우저) 양쪽에서 해야 한다. 서버는 이미 고쳐졌는데 클라이언트 캐시가 "아직 고장남"을 계속 보여줄 수 있다.
"하나의 경고"가 하나의 원인이라는 보장은 없다. 이번 건은 배포판 문제(§1 "3~4차 발견")와 PNA 미지원(§1 "6차 발견")이라는 서로 무관한 두 결함이 겹쳐 있었다. 하나를 고쳤다고 경고가 안 사라지면 "아직 안 고쳐졌다"가 아니라 "다른 원인이 더 있다"를 의심해야 한다.
클라이언트 사이드 위임 아키텍처(§2)는 대상 도메인의 IP 주소 공간 분류에 의존한다. hb5u가 CGNAT/사설 대역으로 잡히는 이상, 브라우저의 최신 보안 정책(PNA)이 조용히 기능을 막을 수 있다 — CORS만 맞추는 것으로는 충분하지 않다.

6. 관련 자료

설계 원안: voronoi-photo-conversion-cpu-gpu (Aegis+Haru 공동)
관련 EROS 문서(일부 최신화 필요): 2026-07-14-eros-photo-hyperbook-architecture
PBN 폰트 개선 보고(같은 날 별개 작업): 2026-07-18-haru-pbn-adaptive-font
Chrome Private Network Access 스펙: W3C Private Network Access (Chrome 팀 명세, Access-Control-Request/Allow-Private-Network 헤더)