등록됐다고 연동된 게 아니다

연동 기능을 손보게 되어 이것이 얼마나 쓰이는지부터 봐야 했다.

SELECT COUNT(*) FROM providers WHERE integration_type = 'oauth';

Open Table of contents

상황 — 등록만 보면 열 곳

integration_type 이 oauth 인 것이 10개가 넘게 나왔다.

꽤 쓰는 것으로 보였지만 등록됐다는 것이 지금 연동이 돌고 있다는 뜻인지는 별개다. 등록과 연동을 같다고 가정하면 실제로 손댈 곳을 잘못 잡게 된다.

oauth 토큰은 다른 DB 에 있었다.

-- 인증 DB
SELECT provider, expires_at FROM tokens WHERE ...;

3개

활성 토큰이 3개였다.

봐야 할 DB 가 하나 더 있었다.

-- 미들웨어 DB
SELECT * FROM providers;

3개

미들웨어 등록도 같은 3개였다.

providers 에서 7개가 남아 그것들을 봤다.

SELECT id, name, account_id FROM providers WHERE ...;

account_id = '카페24'

account_id 가 계정 식별자가 아니라 채널명 그대로였다.

실제 연동 없이 이름만 넣어 둔 구버전 수동 등록이었던 것이다. 등록은 쌓이고 정리는 안 되니 한 번 붙였다 안 쓰는 것이 그대로 남는다.

세 DB 의 숫자를 나란히 놓았다.

[DB 1]  등록 여부      10개 이상
[DB 2]  활성 토큰       3개
[DB 3]  미들웨어 등록    3개

한 곳만 보면 틀린다.

DB 1만 → "10곳이 쓴다"
세 곳 다 → "실제로는 3곳"

세 DB 를 합쳐야 한 건의 실제 상태가 나왔다.

이 채널에 붙을 수 있는 연동 방식이 셋이었다.

SELECT COUNT(*) FROM shop_configs;

shop_configs 는 903개로 많아 보였다.

SELECT COUNT(*) FROM shop_configs
 WHERE last_collected_at > DATE_SUB(NOW(), INTERVAL 3 MONTH);

last_collected_at 로 최근 활동을 거르니 14개만 남았다.

903 중 1.5퍼센트만 살아 있었으니 설정이 남아 있는 것과 지금 돌고 있는 것은 다른 것이었다.

세 번째 방식은 방향이 반대였다.

[방식 3]  그 채널 → 오픈마켓 방향 상품 송출
[우리]    우리 → 그 채널 방향

이름만 보고 세 번째 연동 방식으로 셀 뻔했는데 우리와 무관했다.

조사 중에 0건인 표도 하나 만났다.

SELECT COUNT(*) FROM channel_products;

상품을 API 로 직접 조회하고 channel_products 에 저장하지 않으므로 설계상 0이었다.

0을 만나면 왜 0인지부터 봐야 하고 그것을 안 보면 이상으로 읽어 없는 문제를 만든다.

이 조사로 결론이 뒤집혔다.

[전]  10곳 이상이 쓰는 기능. 조심해서 손대야 함
[후]  실제 활성은 3곳. 게다가 전부 같은 계열

손댈 곳이 훨씬 줄었고 3곳이면 하나씩 개별 확인이 가능하다.

등록 수는 상한일 뿐 실제가 아니었는데 동작 여부를 보려면 토큰이 살아 있는지와 최근 활동이 있는지와 연동 계층에 등록됐는지를 각각 봐야 했다. 그 셋이 전부 서로 다른 곳에 흩어져 있었다.