일정산이 끝난 체결은 손대지 않는다는 규칙이 있는데 오체결 한 건을 정정하는 작업이 들어왔다. 그 체결이 정산에 편입됐는지부터 판정해야 했다.
Table of contents
Open Table of contents
배경 — 어디를 봐야 하는지 모르는 세 테이블
정산 관련 테이블이 settlement_master·settlement_history·settlement_batches 셋이었고 이름만으로는 어디를 봐야 할지 알 수 없었다. 스키마를 하나씩 열어 어떤 키를 갖고 있는지 봤다.
settlement_master 는 일 단위라 trade_id 가 아예 없었고 settlement_history 쪽에는 market 컬럼이 있었다. settlement_batches 에만 trade_id 가 들어 있었다.
연결 고리가 된 회차 테이블
체결에서 정산으로 가는 경로가 회차를 거치는 구조였다. trades 에서 settlement_batches 로 가고 거기서 settlement_master 로 가면 status 와 closed_at 과 paid_at 이 나온다.
경로가 확정되니 판정도 단순해졌다. settlement_batches 에서 그 trade_id 의 행을 COUNT(*) 로 세면 된다.
판단 기준 — 0건이면 조인이 필요 없다
두 가지 방법이 있었다. 세 테이블을 전부 조인해 상태를 한 번에 보는 조회를 두는 것과, settlement_batches 만 세고 행이 있을 때만 settlement_master 로 넘어가는 것이다. 뒤쪽을 골랐다. 이유는 정정 요청 대부분이 당일 체결이라 0건이 압도적이어서다. 대신 행이 있는 건은 조회를 두 번 하는 것을 감수했다.
세어 봐서 0건이면 어떤 회차에도 안 들어갔다는 뜻이고 마감이 아니므로 조작이 안전하다. 행이 있을 때만 마스터로 넘어가면 되므로 대부분의 판정이 한 줄에서 끝난다. 전에는 같은 판정을 할 때마다 세 테이블 스키마를 다시 훑었다.
확정과 추정을 나눠 적기
settlement_history 는 값을 보니 KRW 마켓만 들어 있었고 이번 건은 BTC 마켓이라 무관했다. 다만 한 건의 조회로 그 테이블이 KRW 전용이라고 단정할 수는 없었다.
아직 다른 마켓 데이터가 안 들어왔을 수도 있고 다른 조건으로 들어갈 수도 있다. 그래서 연결 경로는 확정으로 적고 마켓 전용은 재확인이 필요한 추정으로 적어 나눴다.
추정을 사실처럼 적으면 다음 사람이 그것을 전제로 다른 마켓 조사에서 이 테이블을 건너뛴다. 재확인 표시 하나가 그 굳어짐을 막는다.
게이트를 싸게 만드는 값
이 조사의 목적은 정산 완료 체결을 조작하지 않는다는 규칙을 실제로 지키는 것이었다. 판정이 비싸면 바쁠 때 건너뛰게 되고 규칙은 문서에만 남는다.
세 테이블을 훑던 것이 COUNT(*) 한 줄이 되니 건너뛸 이유가 사라졌다. 게이트를 싸게 만드는 것이 게이트를 지키게 만드는 방법이었다.
정리
- 여러 테이블 중 어디가 연결 고리인지 스키마를 훑어 찾는다
trade_id를 가진 테이블이 그 경로의 입구다- 0건이면 미편입이라 조인 없이 판정이 끝난다
- 규명해 두면 같은 탐색을 반복하지 않는다
- 한 케이스의 관측으로 전용이라고 단정하지 않는다
- 같은 조사에서도 확정과 추정의 신뢰도를 나눠 적는다
- 재확인 표시가 추정이 사실로 굳는 것을 막는다
- 게이트를 싸게 만들면 실제로 지키게 된다