Leo's Devlog▌

저장소마다 Claude 세션을 하나씩 두고 개발하는데, 이 글을 쓰려고 구성을 점검하다 디자인을 지휘에서 분리하고 개발 워커는 Sonnet 5로 바꿨다. 각 역할에 그 모델을 둔 이유와, 그렇게 두고 치르는 값.

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

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

프로덕션 API가 30분 죽었고 CORS 에러로 신고가 들어왔다. 원인은 Fargate Spot 회수였는데, Spot이 무엇을 보장하고 무엇을 보장하지 않는지를 문서와 실제 설정을 대조해 찾았다. 2분 경고를 실제로 쓰려면 무엇이 설정돼 있어야 하는지도 같이 봤다.

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

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

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

exhaustive-deps는 effect가 쓰는 모든 값을 deps에 넣으라 한다. 대개 맞지만, deps에 든 값이 렌더마다 새로 만들어지고 그 effect가 리렌더를 일으키면 effect가 멈추지 않는다.

구독 결제에서 중복을 막아야 하는 곳이 세 군데였다. 결제 원장은 UNIQUE로, 주기 이력은 락으로, 즉시 결제는 결제 ID 프리픽스로 막았다. 그런데 그 장치들이 결제만 나가고 DB 쓰기가 실패한 상태를 재시도로 메울 길까지 같이 막았다.