개발의 판단과 맥락을 기록하는 곳
API, 서버, 데이터 흐름과 운영에서 드러나는 변화를 정리합니다.
현재 8개의 발행 글이 이 주제에 속해 있습니다.
DB 폴링만으로 버티던 서비스가 커넥션 풀 고갈과 작업 지연 누적이라는 벽에 부딪히는 순간이 온다. 이 글은 그 신호를 감지하는 구체적인 기준과 함께, Redis/BullMQ 등 메시지 큐 도입 시 실제로 발생하는 consumer 확장·재시도·데드레터 관리 같은 운영 부담을 생략 없이 다룬다. 큐 도입은 해결책이자 새 책임이며, '정말 필요한가'를 판단하는 실용적인 기준을 제시한다.
Supabase에서 RLS를 활성화하면 클라이언트 요청과 SQL 에디터 직접 조회의 결과가 달라지는 이유를 권한 체계부터 추적한다. anon 키와 service_role 키의 차이, auth.uid()가 기대한 사용자 ID를 반환하지 않는 조건, 그리고 정책이 충돌할 때 PostgreSQL이 선택하는 동작 방식을 실제 사례 중심으로 분석한다. 마지막으로 RLS 정책을 로컬과 프로덕션에서 안전하게 테스트하는 절차를 정리했다.
Supabase에서 RLS를 활성화한 순간 쿼리는 에러 없이 빈 배열을 반환하기 시작한다. service_role 키와 anon 키를 혼동할 때 벌어지는 일, SQL 에디터 테스트가 주는 환상, auth.uid()가 null을 뱉는 이유 등 실제 운영에서 마주치는 RLS 실수 패턴을 진단 쿼리와 함께 파헤친다.
DB 폴링 기반 작업 처리로 버틸 수 있는 한계와 Redis·메시지 큐 도입을 결정해야 하는 실전 신호, 그리고 큐를 도입할 때 따라오는 운영 부담을 사례 중심으로 정리한다. DB 테이블 하나로 작업 큐를 대신한 지 1년이 지났다. 처음엔 "언젠가 Redis나 RabbitMQ를 도입해야지"라고 생각했지만, 그 언젠가는 오지 않았다.
Next.js API Route를 Vercel Functions 크론 잡으로 운영할 때 외부 API 호출로 인한 타임아웃을 피하려면, 동시에 여러 건을 처리하려는 욕심을 버려야 한다. 최대 1건 처리, 멱등키 기반 재시도, 중복 실행 방지, 로그 기반 관측 전략을 소개한다.
가비지 컬렉션은 현대 프로그래밍 언어가 거의 예외 없이 채택한 자동 메모리 관리 기술이지만, 그 내부는 대부분의 개발자에게 블랙박스다. 2판으로 돌아온 이 핸드북은 지난 60년간 축적된 GC 연구의 정수를 집대성한다. 단순한 mark-sweep에서 병렬·동시·실시간 컬렉터까지, GC가 어떻게 진화해왔고 오늘날 어떤 선택지를 제공하는지 한 권으로 조망한다.
핑 모니터링 시스템의 데이터 구조체를 12KiB에서 4KiB로 줄이는 비트 단위 최적화 과정을 통해, 메모리 제약이 없는 상황에서도 개발자가 조기 최적화에 빠지는 이유와 그 과정 속의 기술적 쾌감을 탐구하는 에세이입니다.
Stablecoin 모니터링은 단순 가격 조회가 아니라, 신뢰 가능한 price aggregation, 경보 임계치, 그리고 사후 감사 가능한 on-chain logging까지 함께 설계해야 한다. Chainlink 기반 depeg monitoring API가 왜 인프라 문제로 이어지는지 짚는다.