물류 시스템 직접 만들기 vs 사기

개발자가 한 명이라도 있는 회사에서는 이 논의가 반드시 나옵니다. "이거 우리가 만들면 되지 않나요?"

기능 목록만 놓고 보면 만들 수 있어 보입니다. 주문 목록 불러오고, 바코드 읽고, 대조하고, 저장하고. 실제로 프로토타입은 며칠이면 나옵니다.

문제는 프로토타입 이후입니다.

초기 개발비는 총비용의 일부입니다

직접 만들 때 계산에서 자주 빠지는 항목들입니다.

• 엣지 케이스 처리 — 부분 출고, 합포장, 사은품, 취소·변경 반영, 재고 부족
• 인식 정확도 튜닝 — 조도·각도·곡면·손상 조건에서의 실패 대응
• 디바이스 파편화 — 안드로이드 기종별 카메라 동작 차이
• 오프라인 대응 — 창고 와이파이 음영 구간에서의 큐잉과 재전송
• 장애 대응 — 새벽에 출고가 멈췄을 때 누가 받는가
• 담당자 이탈 — 만든 사람이 퇴사하면 아무도 못 고칩니다

마지막 항목이 실무에서 가장 자주 문제가 됩니다. 사내 도구는 문서가 부족한 경우가 많아, 원 개발자가 나가면 사실상 손댈 수 없는 상태가 됩니다.

소프트웨어의 비용은 만드는 데 드는 것이 아니라 계속 살아 있게 하는 데 듭니다.

그래도 만드는 것이 나은 경우

전부 사라는 뜻은 아닙니다. 다음 조건이면 직접 개발이 합리적입니다.

• 우리만의 방식이 경쟁력인 영역 — 남들과 같으면 안 되는 부분
• 시장에 제품이 없는 영역 — 우리 업무가 정말 특수한 경우
• 연동만 하면 되는 얇은 영역 — 기존 시스템 사이를 잇는 스크립트 수준
• 유지 인력이 구조적으로 확보된 경우 — 한 명이 아니라 팀

반대로 다음은 사는 쪽이 대체로 낫습니다.

• 업계 공통 문제 — 우리만 겪는 문제가 아닌 것
• 정확도가 계속 개선되어야 하는 영역 — 인식·판정 로직
• 디바이스·OS 변화를 계속 따라가야 하는 영역
• 24시간 안정성이 필요한 영역

판단을 위한 질문 네 개

1. 이 기능이 우리 사업의 차별점인가, 아니면 없으면 곤란한 기반인가?

기반이라면 사는 쪽이 대체로 낫습니다.

1. 3년간 누가 유지보수하는가?

이름을 댈 수 없으면 만들지 않는 편이 안전합니다.

1. 개발 인력을 여기 쓰면 무엇을 못 하게 되는가?

기회비용이 실제 비용입니다.

1. 실패했을 때 되돌릴 수 있는가?

외부 도구는 해지하면 끝이지만, 사내 도구는 이미 업무가 그 위에 얹혀 있습니다.

중간 지대가 있습니다

이분법으로 볼 필요는 없습니다. 실제로는 이런 조합이 많습니다.

연동과 리포트는 자체, 엔진과 앱은 외부가 현실적인 분업인 경우가 많습니다.

먼저 검증하고 나서 결정하기

직접 만들지 살지를 처음부터 정할 필요는 없습니다. 이 방식이 우리 현장에서 통하는지를 먼저 확인하는 것이 순서상 앞입니다.

외부 도구로 4주 PoC를 돌려보면 두 가지를 동시에 알게 됩니다.

• 검수 방식 자체가 우리 현장에 맞는가
• 실제로 필요한 기능 범위가 어디까지인가

두 번째가 중요합니다. 직접 개발을 하더라도, 무엇을 만들어야 하는지 알고 시작하는 것과 모르고 시작하는 것의 차이가 큽니다.

자주 묻는 질문

오픈소스 바코드 라이브러리를 쓰면 되지 않나요?

인식 라이브러리 자체는 쉽게 구할 수 있습니다. 비용이 드는 부분은 라이브러리가 아니라 그 위의 업무 로직과 현장 조건 대응입니다.

외부 도구에 종속되는 것이 걱정입니다.

데이터 반출 가능 여부와 계약 해지 조건을 먼저 확인하시면 위험이 크게 줄어듭니다. 장기 약정 없이 시작할 수 있는지도 함께 보세요.

사내 개발 프로토타입이 이미 있습니다.

그렇다면 비교 기준이 명확해집니다. 그 프로토타입이 실제 현장 조건에서 며칠 연속 돌아가는지 확인해 보시면 남은 작업량이 보입니다.