Issue BJ: [Preview] 성능 U7 — 프록시가 자산 하나마다 세션 행을 UPDATE, 전 자산 no-store

[Danto7632]

프리뷰 게이트웨이·세션 계층의 효율 문제. #332(컨테이너 실행 격리)는 런타임 계층이라 파일이 겹치지 않는다(PreviewRuntimeLauncher·PreviewWorkspaceService·createAndStartContainer).

확정 사실

#	위치	문제
7-1	PreviewSessionService.java:243-252, 336-340	프록시가 resolveGateway → touch → repository.save() 를 요청마다 한다. 트랜잭션 밖이라 save 가 merge 로 동작해 자산(JS/CSS/이미지) 하나당 SELECT + merge-SELECT + UPDATE 3왕복 + 쓰기 락. 페이지 1회 로드에 자산이 N개면 N×3
7-2	PreviewGatewayService.java:119-125	전 자산에 Cache-Control: no-store, ETag/Last-Modified 미전달 → 해시가 박힌 불변 자산(/assets/index-xxxx.js)까지 매 새로고침마다 재전송
7-3	PreviewGatewayService.java:101-115, 261, 332 · PreviewGatewayController.java:76-81	업스트림 응답을 ofByteArray 로 전량 메모리 버퍼링(HTML 은 String 변환으로 한 번 더 복사). 요청 본문은 readAllBytes 로 무제한 — 인증 없는 경로라 대용량 POST 로 OOM 을 유도할 수 있다
7-4	PreviewGatewayService.java:284-308	base 흡수 재요청(최대 2단계)이 자산마다 최대 3회 컨테이너 왕복
7-5	DockerContainerService.java:129, 951-960	컨테이너 생성마다 pullImageCmd(로컬 존재 미확인, 최대 3분 대기). 코딩 에이전트 쪽은 inspectImageCmd 로 올바르게 처리하고 있다(CodingAgentContainerRunner.java:180)
7-6	DockerContainerService.java:166-181, 659-673	컨테이너 로그 드라이버 상한 없음 — dev 서버 stdout 이 TTL 동안 무제한 적재

할 일

• 7-1: 문서 탐색(Sec-Fetch-Dest navigation)에만 touch 하거나 last_accessed_at 이 60초 이내면 skip. 갱신은 @Modifying 단일 UPDATE
• 7-2: 해시 자산은 private, max-age=3600, immutable, 그 외는 업스트림 ETag/Last-Modified 전달 + If-None-Match 패스스루
• 7-3: 비-HTML 은 ofInputStream + StreamingResponseBody(SSE 경로에 이미 있는 패턴), 요청 본문 상한 10MB 초과 시 413
• 7-4: 세션당 흡수 단수를 기억해 다음 자산부터 바로 적용
• 7-5: inspectImageCmd 선확인 후 없을 때만 pull
• 7-6: withLogConfig(json-file, max-size=10m, max-file=2)

보류(#332 구역): npm 캐시 볼륨 재사용, binding-approval-hold 6시간 동안 컨테이너를 stop 후 재기동으로 바꾸기 — #332 후속으로 제안한다.

검증

프리뷰 페이지 1회 로드 시 preview_sessions UPDATE 횟수 전/후 · 대용량 자산 스트리밍 확인 · 10MB 초과 POST 가 413

계획 원문: .agent-team/00-plan/perf-cost-plan.md U7

[Danto7632]

PR #355 로 해소. base 가 develop 이라 수동으로 닫는다.

실측(실제 MySQL performance_schema, 요청 20건 = 문서1+자산19): 세션 UPDATE 20회 → 0회(스로틀 안) / 1회(스로틀 지난 첫 요청). 가드 테스트는 구코드로 되돌리면 실패한다.

이슈의 '3왕복' 은 실제로 2왕복이었다 — resolveGateway 가 이미 @Transactional 이라 save 가 관리 엔티티 merge(추가 SELECT 없음)였다. 쓰기 락 문제는 그대로 유효했다.

Sec-Fetch-Dest 대신 시간 스로틀을 골랐다: ① 문서 탐색만 갱신하면 XHR/SSE 로만 쓰이는 프리뷰가 사용 중에 만료된다 ② 그 헤더는 인가 판정이 쓰는 신호라 세션 갱신 정책과 얽지 않았다. 인가 경로는 한 줄도 안 건드렸다.

7-2 캐시는 public 을 어떤 분기에도 두지 않아 토큰 회전이 무력화되지 않는다. 해시 판별은 '16진수 8자 + a~f 글자 1자 이상' 으로 좁혀 photo-20260911.jpg 같은 오인을 막았다.