내가 몰랐던 것.

토스 v2 webhook 이 signature 헤더 검증이 아니라 raw_response 안 secret 매칭이라는 것. 단순 SDK 박았다고 끝이 아니라는 것.

사용자가 결제 완료 후 리포트 페이지로 redirect 됐는데 unlock 상태가 안 됨. DB 의 payment row 는 정상 PAID 인데 access_until 이 미반영. webhook 자체는 도착했는데 secret 매칭 실패로 skip 됐다.

결제 사고는 단일 축으로 진단하면 못 잡는다. DB row 상태 + UX flow (사용자 시점) + webhook secret 매칭 — 3축 동시에 봐야 진짜 root cause 발견.

OOM 이 단일 원인이 아니라 5-6 원인 누적이라는 것. 매번 다른 곳에서 메모리 새고 있었다.

MySQL 가 새벽에 죽는 사고가 6 번째. 매번 다른 패턴 — staging 의 long query / dashboard 의 누적 connection / 스왑 미설정 / journald 무한 로그 / mysql 자체 튜닝 부재. 한 가지만 fix 하면 다른 곳에서 다시 죽음.

OOM 같은 운영 사고는 한 패턴 fix 가 아니라 sweep — 모든 가능 원인을 동시에 정리. 잘못된 신호 (예: '메모리 부족이니 RAM 더 사자') 에 휘둘리면 6 개월 낭비.

cafe24 호스팅이 해외 IP 자동 차단한다는 것. CI / CD 의 GitHub Actions 가 해외 IP 라 DB 접속 실패하면 'DB IP 가 바뀐 듯' 으로 오진하기 쉽다.

GitHub Actions 가 cafe24 의 MySQL 에 접속 못 함. 처음 추측 = 'DB 가 IP 바뀐 듯' → IP 재발급 시도 → 여전히 실패. 진짜 원인은 cafe24 의 ' 해외접속 차단' 정책. 한국 IP whitelist 또는 우회 VPN 필요.

원격 인프라 사고 = 첫 추측이 맞을 확률 30%. 잘못된 진단 (DB IP 추정) 으로 시간 낭비하지 말고, hostinginfra provider 의 정책 / 방화벽 / 차단 룰 먼저 확인.

sshd config 의 한 줄 잘못 박으면 VPS 가 영구히 접근 불가가 된다는 것. console / KVM 접근 없으면 복구 불가.

VPS 보안 강화 시도 중 sshd_config 의 PasswordAuthentication / Port / AllowUsers 라인 동시 수정. systemctl restart sshd 후 즉시 disconnect. 새 연결 시도 → permission denied. console 접근도 없어서 영구 lock out.

SSH / sshd 설정 변경은 '한 번 잘못 박으면 끝' 의 카테고리. 단순 보안 설정이 아니라 '연결 자체' 의 root layer. console / out-of-band 접근 없는 상황에서는 절대 X.

codemod (자동 코드 변환 스크립트) 가 import 라인까지 자동 제거하면 모든 페이지가 ReferenceError 로 죽을 수 있다는 것. silent fail 에서 자동화의 위험.

i18n sweep 자동 codemod 가 한국어 → 한국어 단일화 작업 중, 무관한 import 라인까지 같이 제거. 새로 가입한 사용자가 signup 페이지에서 흰화면 + console ReferenceError. 30 분 동안 사고 인지 못함.

자동화 스크립트 (codemod / 일괄 sed / find-replace) 가 import / 의존성 라인 건드리면 silent fail 위험. 사용자가 알리기 전까지 사고 인지 불가.