2021년에 나는 시카고 외곽의 한 3PL 창고를 둘러봤다. 그 사장은 완전히 잘못된 것을 자랑스러워하고 있었다. "연동은 전부 우리가 직접 개발했어요." 그가 말했다. "미들웨어 라이선스 비용을 엄청나게 아꼈죠." 엔지니어 두 명, 그중 한 명은 운영을 겸하는 파트타임이었다. 6개월 후 그는 패닉 상태로 전화해 왔다. 전자상거래 플랫폼이 API 필드를 바꿨고, 파트타임은 그만뒀고, 새로 온 직원은 옛날 코드를 읽을 수 없었고, 주문이 이틀 동안 멈춰 있었다. 그 일로 주요 고객 하나를 잃었다. 그 이틀의 손실은 수년간의 미들웨어 구독료보다 컸다.

모든 창고는 결국 이 결정을 마주하게 된다. 주문은 마켓플레이스에서 들어와야 하고, 운송장은 운송사에서 돌아와야 하고, 3PL 고객은 재고 가시성을 원하고, 대형 리테일 고객은 EDI를 요구한다 — 구매 발주 850, 출하 통지 856, 알파벳 수프 풀코스다. 문제는 연동하느냐가 절대 아니다. 누가 일을 하고, 진짜 비용이 얼마냐는 것이다.

직접 개발에서 가장 싼 부분은 '만드는' 것이다

대부분의 창고는 이 결정을 잘못 계산한다. 개발 비용만 견적에 넣기 때문이다. 엔지니어 두 명, 두 달, API가 연결되고, 모두가 "아낀" 라이선스 비용을 축하한다. 그 계산은 허구다.

자체 개발 연동의 진짜 비용 구조는 대략 개발 30%, 유지보수 70% — 그리고 유지보수는 절대 끝나지 않는다. 플랫폼은 API를 개정한다. 운송사는 인증서를 교체한다. EDI 스펙은 조금씩 바뀐다. 새벽 3시에 알람이 울려도 대응할 자격 있는 사람은 없다. 외부 변화 하나하나가 계획에 없던 개발 스프린트가 된다. 일회성 엔지니어링 프로젝트를 샀다고 생각하지만, 실제로 산 것은 자기 이름이 붙은 장기 부채다.

더 날카로운 리스크는 사람이다. 자체 개발 연동 스택의 단일 장애점은 서버가 아니라 코드를 쓴 사람이다. 그리고 그 사람은 언젠가 반드시 떠난다. 떠나면 문서 없는 블랙박스와, 상류에서 무언가 바뀌는 날 멈춰 버리는 비즈니스가 남는다.

미들웨어가 실제로 파는 것

미들웨어도 자선 사업이 아니다. 모두가 들어본 iPaaS 제품들 — MuleSoft, Boomi, Celigo, Workato — 은 세 번 요금을 물리고, 계약하기 전에 그 세 가지 숫자를 모두 문서로 받아둬야 한다. 첫째는 구독료로, 연결 수나 데이터량에 따라 등급이 매겨진다. 요금은 수시로 바뀌니 벤더의 최신 공개 요금으로 확인하고, 구두 견적을 믿지 마라. 둘째는 구축이다 — 벤더 컨설턴트는 일 단위로 청구하는데, 중간 복잡도의 연동은 견적의 두 배가 걸리는 게 보통이다. 셋째, 그리고 가장 간과되는 것은 종속이다. 비즈니스 로직이 그들의 비주얼 플로우 빌더 안에 들어가면, 갈아타는 데 엄청난 비용이 든다.

그러니 무엇을 사는지 똑똑히 알자. 미들웨어는 싸지 않다 — 리스크를 외주하는 것이다. 플랫폼이 API를 바꾸면 벤더가 커넥터를 맞춰준다. 새벽 2시에 무언가 깨지면 에스컬레이션할 지원팀이 있다. 새벽 3시의 전화가 자기 것이 아니게 되기 위해 돈을 내는 것이다.

계약 전에 한 가지 함정을 더 짚어두자. 프로세스 매핑을 벤더 컨설턴트에게 외주하지 마라. 당신 회사의 워크플로 — 주문이 어디서 들어오고, 예외는 누가 처리하고, 재고의 진실의 원천은 어느 시스템인지 — 은 어떤 설정을 시작하기 전에 사내에서 정리되어야 한다. 프로세스 설계를 통째로 컨설턴트에게 넘기고, 현장의 실제 운영과 맞지 않는 설정으로 라이브를 올리고, 재작업을 두 번이나 돈 내고 한 창고를 나는 봤다. 컨설턴트는 도구를 안다. 비즈니스를 아는 건 당신뿐이다.

창고 시스템 통합 데이터 흐름

내가 세운 세 가지 선

수년에 걸쳐 내가 정착한 세 가지 경험칙이다. 하나라도 해당되면 직접 연동을 개발해서는 안 된다.

선 하나: 연동 포인트가 다섯을 넘는다. 마켓플레이스, ERP, 운송사, EDI, 고객 포털 — 엔드포인트가 하나 추가될 때마다 유지보수 복잡도는 선형이 아니라 기하급수적으로 늘어난다. 사람이 머릿속에 담을 수 있는 한도는 대략 다섯이다. 그 이상은 플랫폼 도구가 필요하다.

선 둘: 풀타임 연동 엔지니어가 두 명 없다. '풀타임'과 '연동 엔지니어'라는 단어에 주목해라 — "거들 수 있는 개발자"가 아니다. 파트타임으로 유지보수하는 자체 개발 연동은 결국 실패한다. 변수라면 언제가 될 뿐이다.

선 셋: 비즈니스가 아직 빠르게 바뀌고 있다. 올해는 Shopify, 내년은 TikTok Shop, 그 다음 해는 대기업 고객의 EDI. 연동 대상 자체가 불안정하면 커스텀 코드의 재작업 비용이 당신을 익사시킬 것이다. 미들웨어 커넥터 라이브러리는 바로 이걸 위해 존재한다 — 기성 커넥터를 활성화하는 것은 처음부터 새로 쓰는 것보다 한 자릿수 싸다.

역도 성립한다. 세 가지가 모두 참일 때만 직접 개발해라: 엔드포인트 수가 무기한 두세 개에 머물고, 비즈니스 로직이 미들웨어로 표현할 수 없는 방식으로 진짜로 커스텀하고 — 특이한 청구 규칙이 전형적인 사례다 — 그리고 어디 가지 않는 안정적인 연동 엔지니어가 있는 경우.

그래도 개발하겠다면, 양보할 수 없는 두 가지

개발할 정당한 이유가 있는 창고도 있다. 좋다. 하지만 내게는 두 가지 요구사항이 있고, 둘 다 없이는 시작하지 않겠다.

첫째, 문서와 인수인계 런북이 코드와 함께 나온다. 작성자가 떠나기 전에, 다른 누군가가 그 연동을 읽고, 수정하고, 독립적으로 배포할 수 있어야 한다. 한 사람만 이해하는 시스템은 자산이 아니라 시한폭탄이다.

둘째, 모든 외부 호출에는 서킷 브레이커와 재시도를 달고, 모든 주문 페이로드는 재실행 가능해야 한다. 플랫폼 API는 끊임없이 삐걱거린다. 재시도가 없으면 타임아웃 한 번이 주문 한 건의 손실이고, 성수기의 주문 손실은 마켓플레이스 페널티와 화난 최종 고객으로 번질 수 있다. 재실행 가능성이 없으면 — 언젠가는 반드시 — 무언가 실패했을 때 복구 경로가 없다. 이건 최소선이지 천장이 아니다.

내일 당장 할 수 있는 한 가지: 종이 한 장에 보유한 시스템 연동 포인트를 전부 적어 세어보라. 다섯을 넘으면? 이번 주에 미들웨어 벤더 세 곳과 데모를 잡아라. 다섯 미만인데 한 명의 파트타임이 유지보수하고 있으면? 그래도 데모를 잡아라. 주문이 멈추는 날을 기다렸다가 이 계산을 한 번도 해본 적 없었다는 걸 깨닫지 마라.

영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.