ERP 구매 대 자체 개발, 숫자로 비교한 결론

사는 쪽도 만드는 쪽도 아니었습니다. 회계와 세무 원장처럼 계산 로직이 이미 오래 검증된 영역은 통째로 기성품에 맡기고, 그 위에 얹히는 원가와 정산 가시성 레이어만 직접 만드는 쪽으로 갈렸습니다. 처음부터 나온 결론은 아닙니다. 실제 거래 데이터를 열어본 뒤 한 번 뒤집힌 결과입니다.

저는 개발자가 아닙니다. 여러 법인의 재무를 보는 실무자입니다. 외식업 소규모 법인의 매장 한 곳에 관리 시스템을 넣는 검토를 했습니다. 업체를 끼는 안과 직접 만드는 안 사이에서 며칠 동안 판단을 몇 번씩 바꿔가며 정리한 기록을 남깁니다.

처음 잡은 판단 기준은 자체 개발 쪽에 불리했습니다

검토를 시작하며 세운 기준은 세 가지였습니다. 하나같이 자체 개발을 밀어냈습니다. 순서대로 적습니다.

첫째, ERP의 본체는 코드가 아니라 로직의 검증입니다. 부가세 신고, 원천세, 재고평가 같은 계산은 기성 패키지에서 수년간 수많은 사업장을 거치며 검증된 부분이고, 직접 만들었다가 그 계산이 한 군데라도 틀리면 신고 오류든 가산세든 책임이 전부 내부로 돌아옵니다. 화면을 잘 만드는 것과 세무 계산이 맞는 것은 다른 문제입니다. 완전히 다릅니다.

둘째, 유지보수 주체가 사실상 한 사람이 됩니다. 만든 사람이 자리를 비우면 아무도 손댈 수 없는 시스템이 남습니다. 법인 입장에서는 기능 부족보다 큰 리스크입니다. 훨씬 큽니다. 외부 업체를 끼자는 의견의 근거도 대개 여기에 있습니다.

셋째, 외식업에서 핵심으로 꼽히는 발주와 재고, 로스 관리는 이미 그 업종만 파고든 특화 솔루션이 여러 개 잘 나와 있습니다. 없는 것을 만드는 게 아니라 있는 것을 다시 만드는 상황입니다. 그러면 만들 이유가 약해집니다.

비용을 계산해보니 아끼는 그림이 성립하지 않았습니다

자체 개발을 검토한 최초 동기는 비용 절감이었습니다. 여기서 계산이 먼저 무너졌습니다.

발주와 재고를 다루는 SaaS는 매장 측 이용이 아예 무료이거나, 유료라 해도 월 십만 원대 초반에서 끝나는 경우가 대부분입니다. 유통사 쪽에 과금하는 구조라 발주를 넣는 매장은 사실상 돈을 내지 않습니다. 반면 SI 업체를 끼고 구축하는 ERP는 자릿수가 다릅니다. 그렇다면 “구축비를 아끼려고 직접 만든다”는 명분은 힘을 잃습니다. 애초에 아낄 구축비가 없는 대안이 존재하기 때문입니다.

여기서 남는 진짜 비용은 사람의 시간이었습니다. 발주와 재고 기능은 만들기는 쉽습니다. 운영이 어렵습니다. 매일 입출고를 넣고, 실제 재고와 하나씩 대조하고, 품목 마스터를 계속 손보는 일은 결국 다른 일도 하고 있는 매장 직원의 손을 거칩니다. 직원이 불평 없이 쓰는 수준의 모바일 화면, 거래처 연동, 단가 자동 반영까지 기성 SaaS 수준으로 끌어올리려면 못해도 몇 달이고, 그 뒤로도 유지보수가 끝없이 붙습니다. 저처럼 다른 본업이 있는 사람에게는 이 시간이 가장 비싼 항목이었습니다.

그래서 1차 결론이 나왔습니다. “직접 만들지 않는다, 다만 SI 업체도 끼지 않고 저가 SaaS로 구축비 0원에서 검증한다”였습니다.

데이터를 열어보고 결론이 뒤집혔습니다

여기서 멈추지 않았습니다. 은행 거래내역과 매입 세금계산서를 실제로 붙여서 봤습니다. 최근 1년 은행 거래가 600건대, 매입 세금계산서는 50건대였습니다. 많지 않습니다. 개업한 지 두 달 남짓 된 매장이라 표본이 짧다는 점은 감안했습니다.

확인된 것은 세 가지입니다.

• 식자재 매입이 사실상 단일 벤더에 몰려 있었습니다. 실제로 반복 거래가 일어나는 핵심 거래처는 두세 곳뿐이었고, 나머지 건들은 임대료나 마케팅비, 기물 구입 같은 비식자재였습니다.
• 금액이 큰 매입 건 상당수가 통장 출금과 매칭되지 않았습니다. 아직 미지급으로 남았거나 다른 계좌에서 빠져나간 건들이 구분 없이 섞여 있었습니다.
• 은행 거래의 75퍼센트가 거래처 미지정이었습니다. 건수로는 465건입니다. 라벨 없이 그냥 쌓여 있었습니다.

이 세 가지가 앞의 판단을 바꿨습니다. 전부요.

발주 시스템의 가치가 예상보다 낮았습니다

수발주 SaaS의 핵심 가치는 여러 거래처의 발주를 한 화면에서 취합하는 데 있습니다. 그런데 거래처가 두세 곳입니다. 그중 한 곳은 자체 수주 시스템을 이미 갖고 있었습니다. 취합할 대상 자체가 없는 셈입니다. 도입해서 얻는 이득이 도입 자체의 번거로움보다 크지 않았습니다.

순서가 틀렸던 겁니다. “무엇을 살까”를 고민하기 전에, 그 도구가 해결하는 문제가 우리에게 실제로 있는지를 데이터로 먼저 확인했어야 했습니다. 거꾸로 밟았다가 되돌아온 셈입니다.

비어 있던 자리는 발주가 아니라 원가와 정산 가시성이었습니다

세금계산서에는 월 합계만 있고 품목과 수량이 없습니다. 로스를 잡으려면 거래명세서를 품목 단위로 받아 쌓는 일이 선행되어야 하는데, 그게 안 되어 있었습니다. 세금계산서와 출금 대사도 어긋난 채였습니다. 그대로 남아 있었습니다. 시스템 이전에 지금 당장의 수작업 리스크였습니다.

이 영역은 기성품이 채워주지 않습니다. 회사의 은행 거래 데이터와 POS 매출, 그리고 품목 단위 거래명세서를 한자리에 붙여야 비로소 나오는 숫자이기 때문입니다. 그래서 자체 개발의 자리가 여기로 좁혀졌습니다. 업체 ERP도 아니고 발주 SaaS도 아닙니다. 이미 있는 데이터를 붙여서 보는 모니터링 레이어입니다.

만들기로 한 다음에 정한 것들입니다

형태는 웹 하나로 통일했습니다

데스크톱 실행파일, 네이티브 앱, 웹. 셋 중에 웹으로 갔습니다. 실행파일은 매장 PC마다 설치와 업데이트가 필요한 데다 폰에서는 아예 쓸 수 없어서, 이 검토의 출발점이었던 “어디서나 조회”라는 요구와 정면으로 부딪힙니다. 탈락입니다. 네이티브 앱은 iOS와 안드로이드 두 벌을 따로 유지해야 하니 비용이 그대로 두 배가 되고, 거기에 스토어 심사라는 변수까지 붙습니다. 푸시 알림이 필요하면 메신저 봇으로 대체하면 됩니다. 폰 홈 화면에 추가하면 앱처럼 뜨는 형태로 만들 경우, 앱을 따로 만들 이유가 거의 사라집니다.

서버는 VPS 한 대에 웹앱, DB, 야간 배치(배치 같은 단어는 따로 모아 정리해두었습니다), 알림 봇을 올리는 구성으로 잡았습니다. 이 정도 규모면 월 1~2만 원대 사양으로 충분합니다. 다만 회사 재무 데이터가 올라갑니다. HTTPS와 로그인만으로 공개 인터넷에 두는 건 피했습니다. 사설망 뒤에 두거나, 최소한 2단계 인증이나 IP 제한을 붙이는 쪽으로 정리했습니다.

권한은 3단계로 시작해서 화면 단위로 쪼갰습니다

처음에는 조회자, 발주 담당자, 관리자 3단계로 잡았습니다. 그런데 시안을 놓고 보니 발주 담당자가 회사 전체 입출금을 볼 이유가 없다는 점이 걸렸습니다. 임대료나 마케팅비까지 매장 담당자에게 보일 이유가 없었습니다.

그래서 레벨 3단계는 유지하되 화면 단위 권한을 따로 뒀습니다. 발주 담당자에게 열리는 “정산” 화면은 회사 전체 입출금이 아니라 본인이 낸 발주 건의 입고 여부와 매칭 상태만 보이도록 범위를 잘랐고, 계정과 품목 마스터처럼 건드리면 곤란한 화면은 관리자 전용으로 뒀습니다. 권한 설계는 레벨을 몇 개로 나눌지보다, 각 화면을 누가 보면 곤란한지에서 출발하는 편이 실수가 적었습니다.

직접 만들어보면서 드러난 한계입니다

화면 시안을 네 벌 만들어 붙여보는 과정에서, 문서로만 검토했을 때는 보이지 않던 것들이 나왔습니다.

용어가 현장과 어긋났습니다

재고 입력 화면에 “실사”라는 단어를 썼습니다. 유통과 외식 현장 용어라 그대로 쓴 것인데, 검토 자리에서 바로 질문이 나왔습니다. “그게 뭐냐, 재고조사인가 실사용인가.” 만든 사람이 아는 단어와 쓰는 사람이 아는 단어가 다르면 그 화면은 온보딩에서 막힙니다. 거기서 끝입니다. 결국 “매일 실사”를 “매일 재고조사”로, “마감 실사”를 “마감 재고조사”로 전부 교체했고, 문서와 화면을 통틀어 잔존 표기가 0건이 될 때까지 훑었습니다.

부족 판단 기준이 상수였습니다

처음 만든 화면에서 재고 부족 여부는 품목마다 손으로 넣어둔 적정재고와 현재재고를 비교하는 방식이었습니다. 그럴듯합니다. 그런데 그 적정재고 값을 누가 무슨 근거로 정하느냐가 비어 있었습니다.

일평균 소비량은 별도 입력 없이 계산할 수 있습니다. 그날 소비량은 전일 재고에 당일 입고를 더하고 당일 재고를 빼면 나옵니다. 입고량은 발주와 입고 확인에서, 재고 수량은 마감 재고조사에서 이미 들어오기 때문입니다. 그래서 기준을 단계로 나눴습니다. 개시 직후에는 손으로 넣은 고정값을 쓰다가, 재고조사 데이터가 2~4주 정도 쌓이면 최근 7일 이동평균 소비량에 리드타임과 안전재고를 얹은 값으로 자동 전환되게 했습니다. 4주 이상 누적되면 요일별 소비 패턴까지 반영합니다.

진짜 문제는 계산식이 아니었습니다. 이 계산의 정확도는 전적으로 매일 마감 재고조사가 빠지지 않는 데 달려 있습니다. 병목은 시스템이 아닙니다. 현장의 입력 습관입니다. 화면을 폰 한 손 입력으로 최대한 가볍게 만든 이유가 그것이고, 실운영에서는 미입력 시 다음날 알림 같은 강제 장치가 필요하다고 봤습니다. 어떤 도구를 사도 이 문제는 그대로 남습니다.

모바일에서 깨졌습니다

데스크톱 브라우저로 볼 때는 멀쩡했습니다. 390px 폭에서는 내용 폭이 515px로 넘쳐 겹치고 잘렸습니다. 범인은 둘이었습니다. 좌우 2단 드릴다운 구조, 그리고 컬럼이 여섯 개인 이력 표. 별도 모바일 페이지를 따로 만드는 대신 미디어쿼리로만 분기해서 좌우 2단을 세로 스택으로 내렸고, 컬럼이 많아 감당이 안 되는 표는 가로 스크롤 래퍼로 감싸거나 아예 카드형으로 재배치했습니다. 그런 다음 전체 탭과 상태를 하나씩 열어 재보면서, 가로 스크롤 폭이 화면 폭과 정확히 같아지는지를 눈이 아니라 숫자로 확인했습니다.

“모바일에서도 됩니다”라는 말은 열어보기 전까지 확인되지 않은 상태였습니다. 실제 폭을 숫자로 재기 전까지 저는 문제가 있는 줄도 몰랐습니다.

검증이 막히는 지점도 있었습니다

화면을 만든 뒤 브라우저로 열어 자동 캡처를 걸어두려 했는데, 브라우저가 띄우는 원격 디버깅 허용 팝업에 막혀 한동안 시각 검증 자체를 하지 못했습니다. 그 구간에서는 문법 검사와 태그 균형 확인 같은 정적 검토로 버텼고, 눈으로 보는 확인은 직접 파일을 열어서 했습니다. 자동화가 막히는 지점을 미리 알아두는 것도 결국 일정의 일부였습니다. 그것도 꽤 큰 일부였습니다.

정리하면서 남긴 판단 기준입니다

다음에 쓰려고 남긴 기준입니다.

• 사는 것과 만드는 것을 전체 단위로 고르지 않습니다. 원장과 세무처럼 틀리면 안 되는 계산은 검증된 기성품에 그대로 두고, 여러 데이터를 합쳐 봐야만 나오는 보고와 자동화 레이어만 직접 만듭니다.
• 도구를 고르기 전에, 그 도구가 푸는 문제가 우리 데이터 안에 실제로 존재하는지부터 확인합니다. 거래처가 두세 곳뿐인데 발주 취합 도구를 사는 건 문제가 없는 자리에 돈을 쓰는 일입니다.
• 절감액을 계산할 때 제 시간을 0원으로 넣지 않습니다. 만드는 시간보다 만든 뒤 유지하는 시간이 깁니다.
• 유지보수를 한 사람만 할 수 있는 구조가 되는지 봅니다. 이 조건 때문에 만들 범위를 좁히는 편이 좋습니다.
• 시스템으로 풀리지 않는 문제를 시스템에 맡기지 않습니다. 매일 현장에서 기록이 쌓이지 않으면 아무리 비싼 도구를 사다 붙여도 로스는 끝내 잡히지 않습니다.

정리하면 이 검토에서 얻은 것은 도구 선택지가 아니었습니다. 범위 감각이었습니다. 무엇을 만들지보다 무엇을 만들지 않을지를 먼저 확정하고 나니, 손에 남는 부분은 생각보다 크지 않았고 그 정도라면 직접 붙여볼 만했습니다.