실전 트러블슈팅

실무에서 실제로 밟은 지뢰와 해결 과정

1. 1

   Spring Batch 6에서 메타데이터가 안 쌓일 때

   Spring Batch 6은 기본이 인메모리 JobRepository다. dataSourceRef도 spring.batch.jdbc.*도 없어진 상황에서 JDBC 영속을 살리는 방법.

   2026.07.20
2. 2

   재고 차감 동시성, UPDATE 한 줄로 끝내기

   조회-검사-차감은 동시성에서 깨진다. 조건부 UPDATE 한 줄이면 행 락으로 원자성이 보장된다 — 비관/낙관 락과의 비교까지.

   2026.07.22
3. 3

   정산 시스템에서 1원이 사라지는 문제 — Largest Remainder Method

   비율 배분 후 반올림하면 합계가 안 맞는다. 내림 + 잔여를 나머지 큰 순으로 나눠주는 Largest Remainder Method와 불변식 테스트.

   2026.07.26
4. 4

   JPA N+1, 발견부터 처리까지 실전 순서

   쿼리 통계로 발견하고, fetch join·batch size·DTO 프로젝션 중 상황에 맞게 고르고, 쿼리 수 단언 테스트로 재발을 막는 실전 순서.

   2026.07.28
5. 5

   한글 입력에서 Enter가 두 번 눌리는 버그

   한글 조합 중 Enter는 keydown을 두 번 발생시킨다. isComposing 체크 한 줄로 해결하는 한국어 서비스 필수 지식.

   2026.07.30
6. 6

   Next.js ISR 때문에 조회수가 멈춘 것처럼 보였다

   DB엔 쌓이는데 화면은 그대로라면 캐시부터 의심하라. ISR 페이지에서 실시간 데이터만 클라이언트로 분리한 과정.

   2026.08.05
7. 7

   결제 웹훅은 반드시 두 번 온다 — 멱등성 설계

   웹훅은 최소 1회 전달 = 중복 각오. 이벤트 ID 유니크 제약 + 같은 트랜잭션, 상태 기계 조건부 UPDATE, 그리고 중복엔 200 응답.

   2026.08.05
8. 8

   Prisma + Supabase 연결, 삽질 포인트 세 가지

   direct host DNS 실패, 서버리스 60초 타임아웃, pgbouncer 커넥션 제한 — Supabase에 Prisma 붙일 때 세 번 막힌 지점과 해결.

   2026.08.06
9. 9

   PostgreSQL 인덱스가 안 타는 5가지 이유

   인덱스를 만들었는데 EXPLAIN을 보면 Seq Scan이 나온다. 당황하기 전에 아래 다섯 가지를 순서대로 확인하자. 1. 테이블이 작다 수천 행짜리 테이블은 인덱스를 타는 것보다 전체 스캔이 싸다. 플래너가 옳다. 운영 데이터 규모로 테스트하지 않으면 인덱스 검증은 의미가 없다. 2

   2026.08.06
10. 10

    Prisma N+1, include가 만능이 아닌 이유

    ORM을 쓰면 N+1은 피할 수 없는 주제다. Prisma는 기본기가 좋은 편이지만, 그래서 오히려 방심하다 당한다. Prisma의 기본 방어선 include는 내부적으로 관계별 배치 쿼리로 풀린다. posts 1번 + authors 1번 + tags 1번. 루프 안에서 findUniq

    2026.08.08
11. 11

    크론 작업 설계 — 멱등성이 전부다

    크론 작업은 "한 시간에 한 번 실행된다"고 믿고 짜기 쉽다. 현실은 다르다. 겹쳐 돌고, 건너뛰고, 중간에 죽는다. 이 셋을 전제하고 설계하면 크론은 평화롭다. 전제 1 — 두 번 실행된다 재시도, 배포 중 중복 스케줄, 수동 실행… 같은 작업이 두 번 돌 경로는 얼마든지 있다. 대응

    2026.08.09
12. 12

    pgbouncer 앞에서 Prisma가 이상해지는 이유

    서버리스에서 Postgres를 쓰면 커넥션 풀러 pgbouncer 가 사실상 필수다. 그런데 풀러를 끼우는 순간 잘 되던 것들이 조용히 이상해진다. 원리를 알면 전부 설명되는 현상들이다. 왜 풀러가 필요한가 Postgres 커넥션은 비싸다 프로세스 하나씩 . 서버리스는 인스턴스가 수십

    2026.08.09