release: 옛 serve 가 살아남아 낡은 빌드를 서빙하던 문제 수정

[dldnsgkr]

develop → main. #170 하나뿐이고 마이그레이션 변경은 없다.

무엇을 고치나

프리뷰를 다시 띄울 때 옛 serve 를 죽이는 pkill 이 실제 프로세스를 한 번도 잡지 못했다. 컨테이너 안 cmdline 에 리터럴 npx serve 가 없고, 대신 그 pkill 을 실행하는 sh -c 자신의 cmdline 에 패턴 문자열이 있어 스스로에게 SIGTERM 을 보냈다.

컨테이너 실측(2026-08-25, node:20-alpine, 운영과 같은 cap-drop/pids/memory):

pkill -f 'npx serve'   → exec 종료코드 143,  살아남은 serve 2개
pkill -f '[s]erve -s'  → exec 종료코드 0,    남은 serve 0개

새 serve 로그:  Accepting connections at http://localhost:46113   ← 랜덤 포트로 밀려남
포트 3000 응답: <h1>OLD-DIST</h1>                                  ← 게이트웨이가 보는 포트

옛 serve 가 포트 3000 을 쥐고 있으면 새 serve 는 EADDRINUSE 로 죽지 않고 조용히 옮겨 붙는다. 게이트웨이는 3000 만 프록시하므로 옛 serve 가 붙들고 있는 옛 디렉터리가 계속 응답한다. 빌드 산출물 경로가 바뀔 때(dist → build) 낡은 화면이 남는다 — 같은 경로면 serve 가 요청마다 디스크를 읽어 최신이 나오므로, 증상은 경로가 달라질 때만 발현된다.

이미 들어가 있던 리스닝 확인이 오히려 이것을 가렸다. 옛 serve 가 3000 에서 응답하니 probe 가 통과해 "준비 완료"가 된다.

함께 고친 것 — 빌드 실패가 조용히 성공으로 넘어가던 문제

DockerContainerService.exec 이 종료 코드를 읽지 않아 프리뷰 빌드의 set -o pipefail 이 무의미했다. 빌드가 깨져도 호출자는 성공으로 알았고, 컨테이너를 재사용하는 프리뷰에서는 이전 빌드의 dist 가 남아 있어 실패한 빌드가 옛 화면으로 성공처럼 보였다.

exec 의 의미는 바꾸지 않았다 — 호출부 48곳 중 상당수가 실패해도 되는 명령이라, 종료 코드를 함께 돌려주는 execWithExitCode 를 따로 두고 빌드에서만 쓴다.

검증

• 마이그레이션 없음
• 테스트 4개 추가. pkill 테스트는 패턴을 정규식으로 컴파일해 실측 cmdline 을 잡는지 + 자기 자신은 안 잡는지를 본다(옛 패턴으로 되돌리면 둘 다 깨진다)
• ./gradlew test 전체 통과, CI 통과, dev 배포 성공(f83e762) 및 기동 확인(200)

Closes #115

🤖 Generated with Claude Code