네트워크

로컬에서 잘 되던 STOMP 채팅이 배포하니까 연결이 안 됐습니다. 원인 후보가 서버 상태부터 인증서까지 열 개쯤 되는 상황에서, 하루 8번의 배포 끝에 mixed content — https 페이지에서 ws:// 차단 — 하나로 좁혔습니다. 후보를 어떤 순서로 제거했는지와, 다음에 같은 일을 겪으면 뭘 먼저 볼지를 정리했습니다.

첫 메시지는 잘 가는데 두 번째부터 화면이 안 갱신되고, 새로고침하면 다 보이는 이상한 증상이었습니다. 저장은 되는데 렌더만 안 되는 것 — React key로 쓰던 messageId가 서버 응답에 없어서 프런트가 난수로 채우고 있었어요. 원인을 좁힌 과정과, 당시 정리에서 스스로 놓쳤던 것까지 다시 봤습니다.

wss 연결 실패를 디버깅하던 중 백엔드 로그에 "Invalid character found in method name [0x16, 0x03, 0x01…]"이 찍혔습니다. 악성 트래픽인가 싶었던 이 바이트들은 사실 TLS 핸드셰이크의 첫 패킷이었어요. HTTP만 받는 포트에 wss를 쏘면 왜 이런 로그가 남는지, 프로토콜 불일치를 로그만 보고 판별하는 법을 정리했습니다.

로그아웃 API를 설계하며 PATCH(상태 전환)와 DELETE(세션 삭제)를 비교했던 글입니다. 실제 프로젝트에서는 PATCH를 채택했는데, 지금 다시 보면 이 비교에는 빠진 선택지(실무 사실상 표준인 POST)와 더 중요한 질문("무엇의 상태인가")이 있었어요. 그리고 예시 코드의 결함이 실제 코드에도 그대로 들어갔다는 것까지 확인했습니다.