#nestjs

상태를 바꾼 트랜잭션은 커밋됐는데 거기 딸린 메일은 fire-and-forget로 날아가 조용히 실패한다. Kafka·SQS 없이 MySQL 테이블 하나로 외부 발송을 트랜잭션에 묶고, 재시도·멱등·DB 장애의 역설까지.

운영에서 무서운 건 빨간 에러가 아니라 아무 데도 안 남는 실패다. 조용히 죽는 배치, 진짜 에러를 묻는 401 스팸. 로그 게이팅·분산추적·에러 트래킹을 환경변수로 켜고 끄게 붙였다.

50~100페이지 공고 PDF를 LLM에 던져 등록 폼을 자동으로 채웠다. 핵심은 추출이 아니라, 모델이 뱉은 JSON을 검증 없이 DB에 넣지 않는 설계였다. responseSchema 강제·타입 화이트리스트·confidence 등급.

N+1이 보이면 반사적으로 JOIN을 붙인다. 하지만 JOIN이 맞는 건 다대일일 때뿐, 일대다에 붙이면 N+1을 행 증식으로 바꿀 뿐이다. 관계의 모양에 따라 배치 IN과 GROUP BY로 갈린다.

요청 하나가 수십 줄 로그를 남기는데 서로 연결고리가 없으면 동시 요청에 뒤섞여 추적 불가다. 외부 라이브러리 없이 Node 내장 AsyncLocalStorage로 Correlation ID를 깔고, 로거 64곳을 무수정으로 묶었다.

증권사 API에 종속된 일임계약을, 증권사마다 다른 상태와 규격과 업무 중단을 견디게 설계해야 했다. 증권사별 상태기계, DB 락 대신 Redis 동시성, 큐 기반 중단 대응으로 갈랐다.

874줄 NotificationsService를 facade + 서브서비스로 나눴다. 분리 자체보다 어려운 건 경계를 어디에 그을지, 그리고 나눈 뒤 그 경계를 어떻게 지킬지였다.

인증을 전수 점검하다 같은 구멍이 반복해서 나왔다. 상태 검사는 로그인에만 있고 토큰은 그 검사보다 오래 산다. 정지된 계정이 refresh로 새 토큰을 받고, 검증 토큰은 평문으로 DB에 누웠다.

Linear·Jira 대신 SWING 안에 이슈 트래커를 직접 만든 결정. 컨텍스트·워크플로우·MTTR을 우리 것으로 두고 확장 가능하게 설계했더니, 팀장이 제품으로 키워보자고 제안했다.