전체 글139 JSON.parse 후 큰 ID 끝자리가 바뀌어 404가 난 이유: MAX_SAFE_INTEGER와 id_str·BigInt 해법 표지 이미지. 서버가 보낸 ID 텍스트와 JSON.parse 뒤의 Number 값이 달라지는 흐름을 요약했다.목록 API에서 받은 주문을 눌렀는데 상세 화면이 404를 띄우는 상황을 재현해봤다. 서버 로그를 보니 클라이언트가 요청한 ID 끝자리가 ...475가 아니라 ...400이었다.처음에는 라우터가 경로 파라미터를 잘못 자르는 줄 알았다. 그런데 범인은 서버가 아니라 클라이언트의 JSON.parse였다. 2^53을 넘는 정수 ID를 JSON 숫자로 내려주면, 자바스크립트는 그걸 double로 반올림해서 들고 있다가 그대로 다시 보낸다.이 글은 Node.js와 Chrome에서 직접 돌려본 결과로 큰 ID 끝자리가 왜, 얼마나 바뀌는지, 그리고 문자열 ID(id_str)와 BigInt reviver 중 .. 2026. 10. 21. Cache-Control no-cache와 no-store 차이: 서버엔 304, fetch에선 200으로 보인 이유 표지: no-cache는 "저장하지 마"가 아니라 "쓰기 전에 물어봐"라는 뜻이다.목록 API 응답이 바뀌었는데 화면에는 예전 값이 남아 있다는 얘기를 듣고, 나는 처음에 Cache-Control: no-cache 한 줄이면 끝이라고 생각했다. 이름부터가 "캐시 없음"이니까.그런데 로컬에서 재현해 보니 서버 로그에는 304가 찍히는데, 브라우저의 fetch()는 계속 200을 돌려줬다. 캐시를 안 한다면서 304는 왜 오고, 304가 왔다면서 JS에서는 왜 200일까?이 글은 그 질문 하나를 따라간다. Node로 작은 서버를 띄우고 curl, Chrome의 fetch, Node의 fetch로 max-age, no-cache, no-store를 각각 두 번씩 불러서 서버까지 요청이 갔는지, ETag 재검증.. 2026. 10. 20. GitHub 오픈소스 5선: OpenCode부터 ComfyUI까지, 역할별로 고르기 코드를 고치고 싶은데 학습 로드맵을 열거나, 앱 자동화가 필요한데 새 코딩 에이전트부터 설치하면 출발점부터 어긋나요. 오늘 GitHub Trending에서 고른 오픈소스 5개는 모두 AI와 관련 있지만, 쓰임은 다릅니다.OpenCode와 ComfyUI는 작업을 실행하는 도구, ai-memory와 CLI-Anything은 기존 도구를 이어주는 도구예요. LLM Course는 배우는 순서를 찾을 때 여는 자료입니다.2026년 10월 19일 10:07 KST, GitHub Trending의 Repositories · 모든 언어 · Today 목록에서 골랐어요. 공식 저장소에서 용도와 시작점, 라이선스를 확인한 다섯 후보이며, 전체 인기 순위 1~5위라는 뜻은 아닙니다.2026년 10월 19일 10:07 KST.. 2026. 10. 19. git bisect run으로 버그 커밋 찾기: 빌드 깨진 커밋을 범인으로 찍지 않으려면 exit 125 주문 합계가 1,300원에 30% 할인을 적용하면 910원이 나와야 하는데 909원이 나온다. 2주 전 커밋에서는 멀쩡했다는 건 아는데, 그 사이 커밋이 스무 개쯤 된다. 이럴 때 꺼내는 게 git bisect run이다. 테스트 스크립트 하나만 주면 Git이 이진 탐색으로 범인 커밋을 찾아준다.나는 스크립트를 "통과하면 0, 실패하면 1"로만 짜면 된다고 생각했다. 그런데 중간에 빌드가 잠깐 깨졌던 커밋이 끼어 있으면, bisect가 엉뚱한 커밋을 범인으로 지목한다. 이 글에서는 실습용 저장소에서 그 상황을 그대로 재현하고, exit 125 한 줄로 결과가 어떻게 바뀌는지 확인한다.git bisect run에서 빌드가 깨진 커밋을 skip해야 하는 이유를 확인한 실습의 표지.결론 먼저1. git bis.. 2026. 10. 19. Promise.all이 실패해도 나머지 요청은 끝까지 돈다: AbortController로 끊어도 서버는 계속 처리한 이유 프로필, 결제, 쿠폰 API 세 개를 Promise.all로 묶어 호출했는데 결제가 500을 돌려줬다고 해보자. 코드는 catch로 빠져서 "실패" 화면을 띄운다. 그럼 아직 응답이 안 온 쿠폰 요청은 어떻게 될까?나는 막연히 "같이 멈추겠지"라고 생각하고 있었다. Promise.all이 reject되면 나머지 Promise도 정리되는 줄 알았다. 그래서 로컬에 Node.js 서버를 하나 띄워서 요청이 서버에서 실제로 어디까지 처리되는지 로그로 확인해봤다.Promise.all 실패 후 남은 요청이 서버에서 어떻게 되는지 확인한 실습의 표지.결론 먼저1. Promise.all이 reject돼도 남은 요청은 취소되지 않는다. 서버는 끝까지 처리하고, 클라이언트 쪽 후속 코드도 계속 실행된다.2. 첫 번째 에.. 2026. 10. 18. HTTP 멱등성: 두 번째 DELETE가 404여도 멱등인 이유 같은 문서를 지우는 DELETE에 처음에는 204, 다시 보내니 404가 온 상황을 생각해보자. HTTP 멱등성을 “같은 결과가 나오는 것”으로 외웠다면 여기서 걸린다. 분명 응답이 달라졌으니까.멱등성에서 같아야 하는 것은 동일한 요청의 의도한 서버 효과다. 응답 코드는 달라도 된다.이 글의 204와 404 흐름은 실제 호출 로그가 아니라 RFC 9110을 설명하기 위한 개념 예시다.응답 코드와 삭제 후 상태를 나눠 보는 개념 설명. 실제 서비스의 호출 기록은 아니다.같은 DELETE 두 번 뒤에 남는 것RFC 9110은 같은 요청을 여러 번 보냈을 때, 서버에 미치는 의도한 효과가 한 번 보냈을 때와 같다면 그 요청 메서드를 멱등하다고 정의한다. HTTP에서 safe 메서드와 PUT, DELETE는 멱.. 2026. 10. 17. 이전 1 2 3 4 ··· 24 다음 반응형
