새 결제 수단 Pg\B 연동이 실제로 돌고 있는지 확인해야 했다. feature/pay-b 에 코드가 들어 있는 커밋이 있었지만 그것만으로 배포됐다고 넘어가지 않기로 했다.
Table of contents
Open Table of contents
검증 — 코드 축의 확인
main 의 PaymentGateway::resolve() 분기를 보니 기존 수단만 있고 신규 수단이 없었다. 실제 발급을 호출하는 코드도 기존 Pg\A 만 부르고 있었다.
git log main..feature/pay-b 로 세니 기능 브랜치가 여섯 커밋 앞서 있고 아직 병합되지 않았다. 기본 브랜치에 그 코드가 없다는 것이 첫 축에서 확정됐다.
원인 — 이미지 빌드 시각
코드가 없어도 확실히 하려고 docker inspect 로 이미지의 Created 를 봤다. 그 시각이 문제의 커밋 날짜보다 앞서 있었다.
빌드가 커밋보다 앞선다는 것은 그 커밋이 들어간 이미지가 아예 없다는 뜻이다. 이미지 빌드 시각과 커밋 시각을 대조하는 것만으로도 배포 여부의 절반이 갈린다.
주의 — 0건에 붙인 대조군
마지막으로 PG 관리자 화면에서 당일 실적을 조회하니 0건이었다. 여기서 멈추면 실매출이 없는 것인지 조회 자체가 이상한 것인지를 구분할 수 없다.
범위를 한 달로 넓혀 조회하니 Pg\A 건이 몇 건 나왔으므로 전산은 정상이고 당일만 실적이 없는 것이었다. 0건 결과에는 반드시 대조군 조회를 붙여 전산 이상과 실적 없음을 갈라야 한다.
배경 — 세 축이 낸 같은 답
main 에 코드가 없고 이미지 Created 가 그 커밋 이전이며 실매출이 없다는 셋이 모두 같은 방향을 가리켰다. 하나만 봤으면 확신이 안 섰을 것이다.
각 축이 막는 것도 다른데 코드는 만들었는지를 보고 이미지는 빌드했는지를 보며 외부 실적은 실제로 도는지를 본다. 앞의 둘이 참이어도 셋째가 거짓일 수 있고 셋째만 봐도 안 돌아서인지 안 써서인지를 모른다.
조치 — 갈린 과제와 함께 나온 제약
이 판정의 결과로 앞으로 할 일이 둘로 갈렸다. 신규 연동은 아직 배포가 안 됐으니 배포해야 하는 일이고 지금 도는 것은 여전히 기존 경로이므로 그 정산이 어디로 가는지가 별도 과제였다.
이미 신규로 넘어갔다고 생각했으면 뒤쪽을 아예 안 봤을 것이다. 확인 순서는 두 가지 방법이 있었는데 PG 실적부터 보는 것과 코드와 이미지부터 보는 것이다. 뒤쪽을 골랐다. 이유는 실적 0건은 안 돌아서인지 안 써서인지를 못 가르지만 코드와 이미지는 우리 손 안에 있어 바로 확정돼서다. 대신 PG 조회가 마지막으로 밀려 결론이 반나절 늦어지는 것을 감수했다. 같은 조사에서 간편결제 수단이 정기결제를 지원하는지도 제공사에 물어 인증결제만 되고 billing_key 정기결제는 불가하다는 회신으로 확정했는데 문서에는 명확히 없는 내용이었다. 관련 자료에 평문 client_secret 이 섞여 있는 것도 발견했지만 차단을 해제하지 않고 필요한 정보만 따로 옮겨 적었다.
정리
- 커밋이 있다고 배포된 것이 아니다
- 코드와 이미지 빌드 시각과 외부 실적 세 축을 교차한다
- 이미지 빌드 시각이 커밋보다 앞서면 그 코드가 안 들어간 것이다
- 0건에는 대조군을 붙여 조회 이상과 실적 없음을 가른다
- 세 축이 같은 답을 내야 확신이 선다
- 이 판정으로 과제 자체가 갈릴 수 있다
- 문서에 없는 제약은 물어봐야 안다
- 자격증명이 섞인 자료는 차단을 해제하지 않는다