외부 쇼핑몰에서 상품 데이터를 가져오는 방법을 찾다가 이름과 용도가 맞아 보이는 제품을 발견했다. 구현 검토를 시작하고 문서를 읽는데 예제가 전부 POST /products 로 내보내는 쪽이었다.
Table of contents
Open Table of contents
원인 — 이름이 가린 흐름의 방향
공식 소개 문장을 찾아 읽으니 판매자가 자사 쇼핑몰의 상품을 여러 오픈마켓으로 송출하는 서비스였다. 우리에게 필요한 것은 그쪽 쇼핑몰의 상품을 가져오는 반대 방향이었다.
이름이 맞으면 방향도 맞을 것이라고 전제한 것이 검토를 시작한 근거였다. 이것이 우리가 원하는 방향인가를 구현 검토보다 앞에 두는 것이 이 건의 교훈이다.
조치 — 며칠을 아낀 지점
두 가지 방법이 있었는데 이미 시작한 검토를 마저 하는 것과 방향을 확인한 그 자리에서 접는 것이다. 뒤쪽을 골랐다. 이유는 계속 갔으면 OAuth 인증 방식을 조사하고 시험 환경을 신청하고 예제를 돌려 본 뒤에야 같은 결론에 닿았을 것이라서다. 대신 그 서비스의 다른 기능에 쓸 만한 것이 있는지는 확인하지 못한 것을 감수했다.
공식 문서의 한 문장이 방향을 알려 주는데 예제만 보면 그 문장을 지나치기 쉽다. 예제는 그 서비스가 무엇을 하는지가 아니라 어떻게 부르는지를 보여 주기 때문이다.
검증 — 이미 쓰고 있던 경로
우리 시스템이 그 서비스와 이미 연동하고 있어서 grep -rn 으로 그것이 무엇인지 확인해 봤다. 이름이 비슷한 다른 API 였고 그쪽 쇼핑몰의 GET /products 일반 인터페이스였다.
찾던 답이 이미 ShopImportClient 로 붙어 있던 셈이라 새로 찾을 필요가 없었다. 새 연동을 찾기 전에 현재 무엇으로 붙어 있는지를 먼저 보는 것이 순서였다.
주의 — 설정 수와 최근 이력의 격차
이 조사를 하면서 관련 기능의 사용 현황도 같이 봤는데 import_settings 가 구백을 넘었다. 많이 쓰는 것처럼 보였지만 최근 석 달의 import_logs 에서 다른 값이 나왔다.
같은 기간에 실제로 돈 seller_id 는 열 몇 개뿐이었다. import_settings 만 남아 있고 실제로는 안 쓰는 상태이므로 초기에 만든 기능의 수명이 다한 것으로 봤다.
배경 — 판정 기준을 바꾼 뒤
이후로 기능의 사용 현황을 볼 때 설정 수를 세지 않고 최근 이력을 센다. 설정 건수는 과거에 만들어진 것을 뜻하고 로그와 channel_jobs 와 updated_at 은 지금 쓰이는 것을 뜻한다.
둘의 차이가 크면 그 기능은 재검토 대상이 된다. 정리 여부는 내가 정할 것이 아니므로 설정 수와 활성 수와 누적 데이터를 USAGE.md 에 나란히 적고 판단을 요청했다.
정리
- 이름이 맞아 보여도 흐름의 방향이 반대일 수 있다
- 방향 확인을 구현 검토보다 앞에 둔다
- 공식 문서의 한 문장이 방향을 알려 주고 예제는 안 알려 준다
- 새 연동을 찾기 전에 현재 무엇으로 붙어 있는지 본다
- 이름이 비슷한 별개 제품이 같은 회사에 있을 수 있다
- 사용 현황은 설정 건수가 아니라 최근 이력으로 센다
- 둘의 차이가 크면 재검토 대상이다
- 정리 여부는 숫자를 나란히 보이고 판단을 요청한다