#mysql

연차 적립 배치가 '오늘이 정확히 발생일'일 때만 부여해서, 한 번 못 돌면 그 발생분이 영구히 사라졌다. 조건을 '발생일 ≤ 오늘 && 미부여'로 바꿨더니 릴리스 당일에 연차가 과다 지급됐다는 문의가 왔다. 멱등 키가 자동 부여만 보고 있었기 때문이다.

mysql2 풀 설정을 한 줄도 안 준 채로 운영해 왔다. 기본값이 무엇을 뜻하는지, 포화되면 어떤 증상이 나는지, prod이 지금 어디쯤에 있는지를 재봤다. 그리고 재고 나서야 이 지표로는 답할 수 없는 질문이 하나 남는다는 걸 알았다.

날짜 컬럼을 다루는 값이 두 좌표계로 나뉜다. 시간축의 한 점인 instant와, 달력 위의 칸인 civil 날짜다. 둘을 한 루프에서 섞으면 하루가 밀리고, 값을 채우는 시계가 두 개면 같은 행 안에서 아홉 시간이 어긋난다.

정적 가드레일 두 개를 만들었고 둘 다 처음엔 '위반 0건'을 보고했다. 둘 다 거짓이었다. 탐지 기준이 위험 경로보다 좁으면 0건이 나와도 안 잡힌 것뿐인데, 그 보고를 보고 나는 안심했다.

상태를 바꾼 트랜잭션이 커밋된 뒤 메일이 fire-and-forget로 날아가 조용히 실패한다. 브로커 없이 테이블 하나로 묶고 워커를 돌렸더니, 이번엔 그 워커가 두 번 도는 문제와 안전장치가 조용히 멈추는 문제가 따라왔다.

AI가 짠 코드에서 만난 N+1 사례들. 쿼리 하나가 무거운 경우는 무엇을 얼마나 가져오느냐에 따라 JOIN·집계·배치로 나뉘고, 배치를 제대로 하는 함수도 호출부가 루프에서 부르면 그 이득이 통째로 사라진다.

연차 차감은 pessimistic 락을 걸고도 뚫렸고, 인보이스 채번은 락을 선언하지 않고도 안 겹쳤다. 두 처방이 나뉜 건 한 번에 하나씩 처리해야 하는 단위가 달랐기 때문이고, 어느 쪽이든 mock으로는 검증되지 않는다.