쿠폰 재전송 횟수 추적 컬럼을 발급 이력 테이블에 추가

tb_coupon_issue_history 테이블에 resend_count 컬럼을 추가하는 DDL 작업을 했다.

왜 이 컬럼이 필요했나

쿠폰 발급 이력 테이블에 재전송 횟수를 추적하는 컬럼이 없었다. 사실 처음 설계할 때는 "쿠폰은 한 번 발송하면 끝"이라는 전제가 깔려 있었던 것 같다. 근데 실제 운영에 들어가면 얘기가 달라진다. 발송 실패, 수신 미확인, 사용자 요청 재발송 같은 케이스가 계속 생겨나고, 그걸 추적하지 않으면 "이 쿠폰이 몇 번 나갔는지"를 알 방법이 없다.

운영팀 입장에서는 재전송 횟수가 쌓이면 어뷰징 탐지나 발송 비용 관리 측면에서도 의미 있는 데이터다. 단순히 기능 하나 추가하는 게 아니라, 운영 관측 가능성(observability)을 높이는 작업이라고 볼 수 있음.

DDL 작업, 팀에서 어떻게 관리하나

이번에 변경된 파일은 sql/DDL_TABLES.sql 하나다. 변경 통계가 따로 찍히지 않을 정도로 작은 변경이지만, DDL은 라인 수로 무게를 재면 안 된다.

우리 팀은 DDL 변경을 코드 변경과 동일하게 PR에 포함시키는 규칙을 갖고 있다. 이유는 단순하다. 스키마 변경이 코드 배포랑 타이밍이 어긋나면 장애로 이어지기 때문이다. 특히 컬럼 추가처럼 "무해해 보이는" 변경도 방심하면 안 된다.

이번 resend_count는 발급 이력에 누적 카운트를 쌓는 용도니까 INT 계열에 DEFAULT 0 같은 값을 설정하는 게 자연스럽다. 기존 데이터가 있어도 기본값으로 채워지니까 배포 순서에 크게 민감하지 않은 케이스였음.

-- 일반적인 패턴 예시 (실제 쿼리와 무관)
ALTER TABLE tb_coupon_issue_history
  ADD COLUMN resend_count INT NOT NULL DEFAULT 0 COMMENT '재전송 횟수';

이런 패턴이 안전한 이유는, 기존 레코드에 자동으로 0이 채워지고, 새로 INSERT되는 레코드도 명시적으로 값을 안 넘겨도 오류가 안 나기 때문이다. 운영 중인 테이블에 컬럼 추가할 때는 이 DEFAULT 여부가 핵심 체크포인트다.

DDL을 chore로 분류한 이유

커밋 메시지를 chore(ddl)로 달았다. 기능 구현(feat)이나 버그 수정(fix)이 아니라 인프라/스키마 정비 성격이라 chore가 맞다고 판단했다. 팀 내에서 커밋 타입을 일관되게 쓰는 게 이후 changelog 자동화나 릴리즈 노트 작성할 때 실질적인 차이를 만들어낸다. DDL만 모아서 보고 싶을 때 chore(ddl) 스코프로 필터링하면 바로 나오는 구조.

작은 컨벤션처럼 보여도, 팀 규모가 커질수록 이런 메타 정보가 없으면 "이 스키마 언제 바뀐 거야?" 라는 질문에 git log 뒤져야 하는 상황이 생긴다. 그게 쌓이면 온보딩 비용도 올라가고.

resend_count 하나짜리 컬럼 추가지만, 이걸 계기로 팀 내 DDL 관리 프로세스를 다시 한번 점검하게 됐다. 앞으로 비슷한 이력성 컬럼이 추가될 때 동일한 패턴으로 자연스럽게 따라올 수 있도록 이번 커밋이 레퍼런스가 되면 충분하다.

끝.