연동 방향을 먼저 확인한다

외부 서비스에서 데이터를 가져오는 방법을 찾다가 이름과 용도가 맞아 보이는 제품을 발견했다. 구현 검토를 시작하고 문서를 읽는데 예제가 전부 내보내는 쪽이었다.

Open Table of contents

이름이 가린 흐름의 방향

공식 소개 문장을 찾아 읽으니 판매자가 자사 쇼핑몰의 상품을 여러 오픈마켓으로 송출하는 서비스였다. 우리에게 필요한 것은 그쪽 쇼핑몰의 상품을 가져오는 반대 방향이었다.

이름이 맞으면 방향도 맞을 것이라고 전제한 것이 검토를 시작한 근거였다. 이것이 우리가 원하는 방향인가를 구현 검토보다 앞에 두는 것이 이 건의 교훈이다.

방향을 확인한 그 자리에서 검토를 접었다. 계속 갔으면 인증 방식을 조사하고 시험 환경을 신청하고 예제를 돌려 본 뒤에야 같은 결론에 닿았을 것이다.

공식 문서의 한 문장이 방향을 알려 주는데 예제만 보면 그 문장을 지나치기 쉽다. 예제는 그 서비스가 무엇을 하는지가 아니라 어떻게 부르는지를 보여 주기 때문이다.

우리 시스템이 그 서비스와 이미 연동하고 있어서 그것이 무엇인지 확인해 봤다. 이름이 비슷한 다른 API였고 그쪽 쇼핑몰의 일반 인터페이스였다.

찾던 답이 이미 붙어 있던 셈이라 새로 찾을 필요가 없었다. 새 연동을 찾기 전에 현재 무엇으로 붙어 있는지를 먼저 보는 것이 순서였다.

이 조사를 하면서 관련 기능의 사용 현황도 같이 봤는데 설정된 건수가 구백을 넘었다. 많이 쓰는 것처럼 보였지만 최근 석 달의 수집 이력에서 다른 값이 나왔다.

같은 기간에 실제로 돈 대상은 열 몇 개뿐이었다. 설정만 남아 있고 실제로는 안 쓰는 상태이므로 초기에 만든 기능의 수명이 다한 것으로 봤다.

이후로 기능의 사용 현황을 볼 때 설정 수를 세지 않고 최근 이력을 센다. 설정 건수는 과거에 만들어진 것을 뜻하고 로그와 작업 기록과 갱신 시각은 지금 쓰이는 것을 뜻한다.

둘의 차이가 크면 그 기능은 재검토 대상이 된다. 정리 여부는 내가 정할 것이 아니므로 설정 수와 활성 수와 누적 데이터를 나란히 적고 판단을 요청했다.