로그인 응답의 리프레시 토큰을 프런트가 쿠키에 넣고 갱신 요청 body에 실어 보내던 구조를, 서버가 쿠키를 심고 프런트는 credentials만 붙이는 구조로 바꿨습니다. 열흘 동안 쿠키 이름이 두 번 바뀌고, 만료 시간이 사라졌다가 돌아오고, "프론트가 지울 수 있나요?"라는 TODO가 세 곳에 붙었다가 하루 뒤 지워졌어요. 토큰 보관 주체가 옮겨 간 기록입니다.
액세스 토큰의 payload를 atob로 풀어 exp를 비교하는 함수가 2024년 9월부터 있었습니다. 2025년 1월에 그 함수를 지우고, 2월에는 화면마다 쿠키를 직접 읽던 로그인 유도를 useAuth 훅 하나로 모았어요. 그날 커밋은 모달을 띄우지 못하는 코드를 남겼고 사흘 뒤에 고쳤습니다. 401 처리를 한곳으로 모으는 이야기의 첫 장면입니다.
로컬에서 잘 되던 STOMP 채팅이 배포하니까 연결이 안 됐습니다. 원인 후보가 서버 상태부터 인증서까지 열 개쯤 되는 상황에서, 하루 8번의 배포 끝에 mixed content — https 페이지에서 ws:// 차단 — 하나로 좁혔습니다. 후보를 어떤 순서로 제거했는지와, 다음에 같은 일을 겪으면 뭘 먼저 볼지를 정리했습니다.
첫 메시지는 잘 가는데 두 번째부터 화면이 안 갱신되고, 새로고침하면 다 보이는 이상한 증상이었습니다. 저장은 되는데 렌더만 안 되는 것 — React key로 쓰던 messageId가 서버 응답에 없어서 프런트가 난수로 채우고 있었어요. 원인을 좁힌 과정과, 당시 정리에서 스스로 놓쳤던 것까지 다시 봤습니다.
wss 연결 실패를 디버깅하던 중 백엔드 로그에 "Invalid character found in method name [0x16, 0x03, 0x01…]"이 찍혔습니다. 악성 트래픽인가 싶었던 이 바이트들은 사실 TLS 핸드셰이크의 첫 패킷이었어요. HTTP만 받는 포트에 wss를 쏘면 왜 이런 로그가 남는지, 프로토콜 불일치를 로그만 보고 판별하는 법을 정리했습니다.
채팅의 STOMP 연결과 구독 객체를 useState에 담고 있었습니다. effect의 정리 함수가 그 state를 읽어 unsubscribe하게 짜 놨는데, 정리 함수는 effect가 만들어질 때의 값을 잡고 있어서 늘 null이었어요. 다음 날 새벽 클라이언트를 useRef로 옮기고 클라이언트·구독 state 셋을 지웠습니다. 파일이 212줄에서 111줄이 됐는데, 그중 54줄은 리팩토링 커밋이 화면 JSX를 통째로 주석 하나로 바꿔 버린 탓이었습니다.
사이드 프로젝트에서 axios를 fetch로 바꿨다가 28시간 뒤 되돌리고, 30분 뒤 다시 fetch로 갔습니다. 그 사이 커밋 메시지는 "프록시 시도 중", "프록시 실험 일단 종료", "credentials 처리 방법 실험 시도"였어요. 되돌아보니 HTTP 클라이언트를 바꾼 게 아니라 Netlify 리다이렉트와 Next 리라이트 사이를 헤맨 이틀이었습니다. 왜 흔들렸는지를 커밋 순서대로 적습니다.
여행지 목록과 검색 API의 메서드를 하루에 세 번 바꿨습니다. 오후 6시에 둘 다 GET, 7시에 page를 쿼리로, 8시 반에 목록만 POST, 밤 11시 반에 검색은 GET으로 확정. 그런데 POST로 바꾸면서 좌표를 params라는 키로 한 번 감싸서 보냈고, 그걸 다음 날 점심에야 풀었어요. 엿새 뒤 검색도 POST가 됐습니다.
송신부와 수신부의 연결을 확인 하는 연결형 서비스
로그인하면 액세스 토큰, 리프레시 토큰, userId를 전부 7일짜리 쿠키에 넣었습니다. 넣는 함수 이름은 setEncryptedCookie였는데 안에서 하는 일은 js-cookie의 set 한 줄이었고, 같이 깔아 둔 crypto-js는 한 번도 import되지 않았어요. 액세스 토큰이 5분으로 줄어든 건 한 달 뒤였고, 그 이름을 버린 건 여덟 달 뒤였습니다.
HTML의 <a> 태그를 사용하여 페이지 이동을 할 수 있습니다. 이 방법은 간단하며 가장 많이 사용됩니다.
웹 소켓(WebSocket)은 클라이언트와 서버 간의 양방향 통신을 가능하게 하는 프로토콜입니다. HTTP와 달리, 웹 소켓은 단일 연결을 통해 지속적인 데이터 전송을 허용하여 실시간 애플리케이션에 적합합니다. 특히, 채팅 애플리케이션과 비디오 스트리밍 및 판독 시스템에서 유용하게 사…
로그아웃 API를 설계하며 PATCH(상태 전환)와 DELETE(세션 삭제)를 비교했던 글입니다. 실제 프로젝트에서는 PATCH를 채택했는데, 지금 다시 보면 이 비교에는 빠진 선택지(실무 사실상 표준인 POST)와 더 중요한 질문("무엇의 상태인가")이 있었어요. 그리고 예시 코드의 결함이 실제 코드에도 그대로 들어갔다는 것까지 확인했습니다.
마이페이지 회원 정보가 화면에 안 찍혀서 새벽에 커밋 둘을 올렸습니다. 첫 커밋은 API 함수가 벗기던 껍데기를 화면 쪽으로 넘겨 data.data.data를 읽게 했고, 36분 뒤 두 번째 커밋이 그걸 되돌리고 팀원이 만들어 둔 타입 붙은 훅으로 갈아탔어요. 나흘 뒤에는 상태 코드마다 써 두던 에러 문구를 지우고 서버가 주는 message 하나로 통일했습니다.
직짱건강의 로그아웃은 2월 말에 처음 짰고 3월 14일 새벽에야 "고치기 성공"이라는 커밋이 올라갔습니다. 그 사이 토큰은 localStorage에서 암호화된 쿠키로 옮겨 갔고, 저는 쿠키를 지운 다음에 로그아웃 요청을 보내고 있었어요. 마지막 커밋은 복호화·Bearer 접두어·절대 URL 셋을 한꺼번에 바꿔서, 그중 무엇이 고친 건지는 지금도 모릅니다.
백엔드에 붙이자마자 CORS 오류가 났고, 저는 next.config.js에 Access-Control-Allow-* 헤더를 붙이는 설정으로 두 번 시도했습니다. 그런데 axios는 백엔드 IP를 직접 부르고 있어서 Next 서버를 거치지도 않았어요. 이틀 뒤 주소가 환경 변수로 바뀌면서 문제는 사라졌고, 그 헤더 설정은 지금도 저장소에 남아 있습니다.
같은 웹 화면이 브라우저에서도 열리고 앱 안의 웹뷰에서도 열렸습니다. 브라우저면 gtag로 보내면 되는데, 웹뷰에서 gtag를 부르면 앱 이벤트와 갈라져 퍼널이 끊겼어요. 이벤트 함수 하나가 Android 인터페이스, iOS 메시지 핸들러, gtag 순서로 갈라 보내게 했고, 구매·환불처럼 서버가 확정하는 이벤트는 서버가 따로 보냈습니다.
공항 보안 검색 판독 화면은 단화면과 양화면이 브라우저 창 두 개였습니다. 한쪽에서 토글을 누르면 다른 창도 따라와야 해서, 설정값을 localStorage에 적고 소켓으로 문자열을 되쏘고 storage 이벤트로 새로고침하는 구조였어요. 스냅샷 코드에서 그 세 층을 다시 읽고, 같은 문제를 2년 뒤 어떻게 다르게 풀었는지 이어 적습니다.