정산 추적 위해 원본 페이로드 저장 방식으로 전환

이번 v1.0.2 는 릴리즈 노트 한 줄로 요약하면 "잡다한 세 건" 인데, 각각 왜 건드리게 됐는지를 적어두지 않으면 몇 달 뒤에 본인도 맥락을 잃는다. 그래서 짧게 남긴다.

payload 원본 저장 — 정규화냐 추적이냐 둘 다냐

이커머스 측 외부 알림을 수신해서 내부 큐로 넘기는 흐름이 있다. 처음 설계할 때 선택지는 단순했다: 외부 포맷을 내부 DTO 로 변환해서 저장하면 스키마가 깔끔하고 코드도 예측 가능하다. 그래서 그렇게 했고, 한동안 별 문제 없었다.

문제는 정산 검증에서 터졌다. 파트너 측에서 이의를 제기하면 "우리 시스템에 들어온 원문" 을 봐야 하는데, DTO 만 남아 있으면 역추적이 안 된다. 매핑 로직을 통과하면서 어떤 필드가 잘렸는지, 어떤 값이 변환됐는지 알 방법이 없다. 더 귀찮은 건 외부 포맷이 조용히 바뀔 때다. 파트너가 스펙을 고지하지 않고 필드를 추가하거나 타입을 바꾸면, 매핑 코드는 모르고 지나가고 나중에 숫자가 안 맞는 걸 보고서야 안다.

그래서 raw payload 를 별도 컬럼으로 그냥 박아두는 방식으로 바꿨다.

ALTER TABLE notification_events
  ADD COLUMN raw_payload JSONB;

정규화 컬럼은 그대로 두고, 원본도 같이 저장한다. 쿼리/집계는 정규화 컬럼으로, 디버깅·분쟁 추적은 raw 로. 스토리지를 두 배 쓰는 대신 추적 가능성을 확보하는 트레이드오프인데, 정산 도메인에서는 이게 맞다. 돈 관련 이슈는 "왜 그 값이 들어왔는가" 를 반드시 소명할 수 있어야 한다.

이중화가 나쁜 설계처럼 보이는 상황이 있고, 이중화가 정답인 상황이 있다. 이번이 후자였다.

보관 기간 정책은 아직 정하지 않았다. 무기한 쌓으면 결국 스토리지 문제가 된다. JSONB 컬럼 인덱스 전략이나 파티셔닝은 볼륨이 실제로 찼을 때 다시 보는 걸로.

보안 검사 한시 비활성화 — debug 와 release 의 분리선

셋업 단계 무결성 검사 일부를 껐다. 영구 결정이 아니고 QA 단말 풀이 좁아서 생긴 임시 조치다. 일부 기기에서 false positive 가 터지는데, 그 기기들이 QA 에 쓰는 단말이라 매번 수동 우회가 번거로웠다.

buildTypes {
    debug {
        // 무결성 검사 우회 (QA 단말 false positive 회피)
        // TODO: QA 풀 교체 후 제거
    }
    release {
        // 운영은 그대로 유지
    }
}

이게 위험한 이유는 하나다. release 까지 같이 끄면 끝이다. 흥분 상태에서 PR 리뷰하다 보면 release 블록도 같이 넣어버리는 실수가 생각보다 쉽게 난다. 그래서 PR 설명에 맥락을 빨갛게 박아뒀다. 리뷰어에게 "이건 debug 전용" 이라는 게 눈에 바로 들어와야 한다.

한시 우회는 TODO 를 명시적으로 달아두지 않으면 "한시" 가 반년이 된다. 이번엔 QA 풀 교체 시점을 트리거로 잡아뒀는데, 추적이 안 되면 흐지부지될 가능성이 있다. 이슈 트래커에도 링크 걸어두는 게 더 안전했을 것 같다.

배포 설정 — 트랜지티브 의존성이 조용히 경고 뱉을 때

빌드 스크립트 의존성 버전 락을 정리했다. 직접 선언한 라이브러리가 아니라 그 라이브러리가 끌고 오는 간접 의존성이 마이너 업데이트되면서 기동 시 경고 로그를 뱉기 시작했다. 기능에 당장 영향은 없지만 경고 로그가 쌓이면 진짜 문제가 묻힌다.

정리한 방향은 세 가지다.

• 직접 의존성은 버전을 명시해서 예상 범위를 고정
• 간접 의존성은 BOM이나 플랫폼 선언으로 일괄 관리, 버전 충돌 위임
• 중복 선언 제거 — 같은 라이브러리가 두 군데 선언돼 있으면 어느 버전이 실제로 올라오는지 추론이 필요해진다

트랜지티브 의존성 문제의 특성이 있는데, 증상이 바로 안 나타난다. 빌드는 되고, 테스트도 통과하고, 배포 후 로그에서 슬쩍 경고 하나가 뜬다. 그걸 무시하면 다음 업데이트 때 더 큰 충돌이 날 수 있다. 경고를 경고로 남겨두면 안 된다는 거, 이번에 다시 확인했다.

회고

성격 다른 변경 세 건을 한 릴리즈에 묶었더니 PR 리뷰가 흐려졌다. raw payload 추가가 정산 맥락을 알아야 이해가 되는데, 같은 PR 에 gradle 수정이랑 보안 우회가 섞여 있으면 리뷰어가 맥락 전환을 세 번 해야 한다. 커밋은 같이 가더라도 PR 은 목적 단위로 쪼개는 게 맞다.

특히 한시 우회 같은 항목은 단독 PR 로 분리해서 제목부터 "임시, QA 전용" 이 드러나야 한다. 묶어놓으면 중요도가 다른 변경들 사이에서 묻힌다. 이번 PR 설명에 빨간 글씨를 박아놓은 건 그 방어책이었는데, 근본적으로는 PR 분리가 더 깔끔한 해결책이다.

다음 릴리즈에서는 변경 목적이 두 개 이상이면 브랜치부터 나눠서 가는 걸로.