같은 요청이 두 번 와도 한 번만 — 멱등 키(Idempotency-Key) 구현하기
응답이 사라지면 재시도는 피할 수 없습니다. 그래서 같은 요청이 두 번 와도 한 번만 처리하고, 두 번째에도 처음과 같은 응답을 돌려주는 멱등 키를 MySQL 로 직접 구현했습니다. 다섯 요청이 동시에 와도 확정은 한 번이었던 실험을 함께 정리했습니다.
응답이 사라지면 재시도는 피할 수 없습니다. 그래서 같은 요청이 두 번 와도 한 번만 처리하고, 두 번째에도 처음과 같은 응답을 돌려주는 멱등 키를 MySQL 로 직접 구현했습니다. 다섯 요청이 동시에 와도 확정은 한 번이었던 실험을 함께 정리했습니다.
같은 데이터를 두 번 받아도 한 번만 남기려고 upsert 를 썼는데, 돌아온 숫자는 신규 건수가 아니었습니다. 같은 SQL 이 Node 의 mysql2 에서는 4, Go 드라이버에서는 3 을 돌려준 이유와, 신규 건수를 올바르게 세는 방법을 정리했습니다.
Go 에 약해서 서버를 TypeScript 로 다시 짜며 가장 먼저 다시 배운 것은 빈 값이었습니다. 0, 빈 문자열, null, 키 없음이 각각 다른 뜻이라는 것과, 설정 파일이 없는 환경 변수를 조용히 빈 문자열로 넣는다는 것을 직접 실험으로 확인했습니다.
조건문과 쿼리 빌더에 흩어진 코드를 DBA가 검토하려면 어떤 SQL이 만들어지는지부터 파악해야 했습니다. CodeRabbit에 예상 SQL과 검토 지점을 정리하도록 설정한 배경, 가상 코드 예시, 실제 SQL 대조와 사람의 판단이 필요한 구간을 함께 정리했습니다.
옵시디언 vault를 정리하다 '나는 거의 안 쓴다'는 한마디에 전제가 바뀌었습니다. 주 독자는 AI였습니다. 두 번째 정본이 된 대시보드와 진짜 노트를 가린 빈 폴더 노트, 아무도 보지 않던 스크린샷을 치우고, 규약인 이름과 서로 인용하는 문서는 일부러 남긴 기준을 정리했습니다.
옵시디언 vault 의 고아 노트를 464개로, 깨진 링크를 141회로 셌지만 실제는 271개와 113회였습니다. 재는 도구가 링크 규칙을 몰랐고, 검증은 오류를 잡을 수 없는 방법이었습니다. 미리보기(dry-run)와 다른 방법의 검증, 무손실 대조로 막은 아홉 번의 기록입니다.
AI 에이전트의 장기 메모리로 쓰는 옵시디언 vault에서, 28KB로 줄여 둔 루트 인덱스가 12주 만에 108KB로 다시 불었습니다. 원인은 "지우지 말고 덧붙인다"는 규칙에 크기 상한이 없었던 데 있었습니다. 층별 상한, 상태와 이력의 분리, 쓰기 시점 점검으로 고친 기록입니다.
Search Console에 '제출됨' 안내가 떴지만 목록은 여전히 '가져올 수 없음'이었습니다. 접수와 완료는 다른 대답이었습니다. 검색 성과와 색인 보고서, GA4 주요 이벤트가 0이던 이유를 어떤 기준으로 읽었는지, 무엇을 아직 결론으로 적지 않았는지 정리했습니다.
Next.js 블로그의 사이트맵에 최신 100편만 들어 있었고 에러는 없었습니다. 목록 API를 한 번만 부른 페이지네이션 누락과 여러 경로에서 조용히 빠져 있던 ISR 온디맨드 재검증을 고치고, 주기적 재생성이라는 교란 변수를 피해 저장 직후에 확인한 기록입니다.