(4) 설정 하나가 프로세스를 죽인다 — 실전 크래시 3건의 해부

이번 편은 실제 크래시 3건의 정리 — 전부 논리 버그가 아니라 설정/라이프사이클 문제였다. ① Postgres 커넥션 소진 — error 53300. DB 접근 팩토리가 Pool을 호출마다 돌려주고 아무도 안 끊는 설계에서, 워커가 RSS 아이템마다 호출하는 순간 커넥션 한도가 붕괴했다 — sorry, too many clients already. 고쳐주는 게 싱글턴 memoize + 워커 종료 시 풀 end(). 배움: "팩토리 함수가 리소스를 뱉는다"는 설계는 호출자가 반드시 되돌림 책임을 지지 않으면 그대로 누수가 된다. ② WS 프레임 리플레이 없음. 두 브라우저 테스트에서 A가 말해서 broadcast를 한 뒤 B가 웨이터를 붙이면 그 발言을 영영 지나친다 — 소켓은 새로 들어오는 프레임만 내보낸다. 이 때문에 히스토리(REST hydration)와 실시간 프레임의 양 경로가 따로 있어야 하고, 테스트는 발송 전에 모든 웨이터를 붙여야 한다. 무작위 실패처럼 보이는 것의 대부분이 타이밍이다. ③ next rewrites는 WebSocket upgrade를 프록시하지 않는다. 채팅 화면(:3011)과 ws 연결(:3010 직접)이 따로 간다. 쿠키는 포트 무시 매칭이라 통과했지만, 배포 TLS 뒤에서 쿠키 도메인 규칙이 달라질 수 있으므로 체크포인트는 문서에 별도 남긴다.