기업 비즈니스 솔루션 직접 만들고 구독해봤더니

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

견적서 승인 단계 하나를 바꾸는 데 개발팀은 3주가 필요하다고 했고, 구독형 서비스는 그날 바로 설정할 수 있다고 했습니다. 처음에는 빠르고 저렴한 쪽이 당연히 유리해 보였지만, 실제로 두 방식을 함께 운영해보니 승부는 속도보다 업무의 고유성, 누적 비용, 변경 빈도에서 갈렸습니다.

기업 비즈니스 솔루션을 선택할 때 자주 맞붙는 선택지는 두 가지입니다. 우리 업무에 맞춰 직접 만드는 맞춤형 구축과 이미 완성된 기능을 빌려 쓰는 SaaS 구독입니다. 어느 한쪽이 항상 우월한 것은 아니며, 어떤 업무를 맡기느냐에 따라 승자가 달라집니다.

첫 30일 승부는 SaaS, 업무 적합성 승부는 맞춤형 구축

로그인부터 현업 투입까지 걸린 시간

SaaS는 계정을 만들고 사용자를 초대하면 곧바로 시작할 수 있었습니다. 프로젝트 관리, 전자결재, 고객 문의 접수처럼 여러 기업이 비슷한 방식으로 처리하는 업무는 기본 템플릿만 손봐도 충분했습니다. 사용자 20명 규모라면 관리자 교육과 데이터 입력을 포함해도 대체로 수일에서 2주 안에 첫 운영이 가능합니다.

반면 맞춤형 구축은 요구사항을 정의하는 단계부터 시간이 필요했습니다. 현업 인터뷰, 화면 설계, 권한 정책, 데이터 이전, 테스트를 거치면서 간단한 내부 시스템도 2~3개월이 걸릴 수 있습니다. 그러나 기존 ERP의 특수한 품목 코드나 회사만의 다단계 승인 규칙처럼 표준 제품이 받아들이기 어려운 절차에서는 업무를 시스템에 억지로 맞추지 않아도 된다는 장점이 컸습니다.

• SaaS 우세: 표준화된 업무, 빠른 개통, 원격 근무, 소규모 팀의 즉시 협업에 유리합니다.
• 맞춤형 구축 우세: 독자적인 산정 공식, 복잡한 권한, 여러 사내 시스템과의 깊은 연동에 적합합니다.
• SaaS의 약점: 필요한 기능이 상위 요금제에만 있거나 설정 범위를 벗어나면 업무 절차를 바꿔야 합니다.
• 구축의 약점: 요구사항이 자주 바뀌면 개발 일정과 예산이 함께 늘어납니다.

기능 수보다 핵심 흐름을 먼저 비교해야 하는 이유

기능 목록이 100개인 제품도 직원이 매일 쓰는 세 단계가 불편하면 좋은 솔루션이 아닙니다. 반대로 기능이 단순해도 문의 접수부터 담당자 배정, 처리 결과 통보까지 끊김 없이 이어진다면 현업 만족도는 높아집니다. 비즈니스의 기본 개념처럼 기업 활동은 가치를 만들고 전달하는 과정이므로, 솔루션도 기능의 개수보다 가치가 흐르는 경로를 얼마나 잘 지원하는지 봐야 합니다.

실무 팁: 데모 화면을 순서대로 구경하지 말고, 실제 직원이 어제 처리한 업무 한 건을 그대로 재현해보세요. 중간에 엑셀이나 메신저로 빠져나가는 순간이 있다면 그 지점이 비용과 오류가 생기는 곳입니다.

1. 사용 빈도가 가장 높은 업무 세 가지를 고릅니다.
2. 각 업무의 시작 조건과 최종 산출물을 한 문장으로 적습니다.
3. SaaS 체험판과 구축 시안에서 같은 업무를 직접 실행합니다.
4. 클릭 수뿐 아니라 대기, 재입력, 관리자 호출 횟수까지 기록합니다.

월 구독료 대 개발비, 3년 비용표에서 판세가 바뀌었다

처음 보이는 가격과 실제 총비용의 차이

사용자당 월 2만 원인 SaaS를 직원 50명이 쓰면 월 100만 원, 연 1,200만 원입니다. 초기 개발비 5,000만 원인 맞춤형 솔루션과 비교하면 첫해에는 SaaS가 압도적으로 저렴해 보입니다. 하지만 3년 동안 인원이 100명으로 늘고 고급 보안, API 연동, 추가 저장 공간을 구매하면 구독 비용이 예상보다 빠르게 커질 수 있습니다.

맞춤형 구축도 개발비만 계산하면 안 됩니다. 서버 또는 클라우드 사용료, 장애 대응, 보안 패치, 운영 담당자, 기능 개선 비용이 계속 발생합니다. 특히 처음 개발한 업체와 계약이 끝난 뒤 문서가 부족하면 다른 업체가 구조를 파악하는 비용까지 추가됩니다. 구매 가격이 아니라 36개월 총소유비용으로 두 선택지를 비교해야 하는 이유입니다.

손익분기점을 흔드는 네 가지 변수

실제로 비용표를 만들어보니 사용자 수보다 더 큰 변수는 연동 범위였습니다. SaaS 두 개를 연결하는 자동화가 단순하면 월 몇만 원으로 해결되지만, ERP·물류·회계 데이터가 실시간으로 맞아야 하면 별도 개발비가 붙습니다. 맞춤형 구축도 요구사항이 확정되지 않은 상태에서 시작하면 변경 요청이 누적되어 초기 견적의 20~40%가 추가될 수 있습니다.

• 사용자 증가율: 현재 인원보다 12개월·36개월 뒤 예상 계정 수를 계산합니다.
• 연동 난도: API 제공 여부, 호출 한도, 실시간 동기화 필요성을 확인합니다.
• 변경 빈도: 법규나 상품 정책이 자주 바뀌는 업무는 수정 비용을 별도로 잡습니다.
• 종료 비용: 데이터 내보내기 형식, 이전 지원비, 계약 해지 시점도 금액으로 환산합니다.

기업의 투자 판단은 외형적 성장이나 도입 발표만으로 평가하기 어렵습니다. 대규모 투자 이후 수익성과 경영 성과를 다룬 사례에서도 확인할 수 있듯, 솔루션 역시 도입 규모보다 실제 비용 절감과 처리 시간 개선이 남는지를 추적해야 합니다.

가격 협상 전에는 공급사에 사용자 50명, 100명, 200명일 때의 견적을 각각 요청하세요. 할인된 첫해 가격만 보면 2년 차 갱신 때 예산이 흔들릴 수 있습니다.

통제권 대 업데이트 속도, 운영팀이 체감한 진짜 차이

보안과 데이터 소유권에서는 질문이 달라야 한다

맞춤형 구축은 데이터 저장 위치, 접근 권한, 로그 보관 기간을 기업 정책에 맞게 설계할 수 있습니다. 민감한 제조 원가, 연구 자료, 고객 식별 정보를 다루거나 폐쇄망 운영이 필요하다면 이 통제권은 결정적인 장점입니다. 다만 직접 통제한다는 것은 보안 패치와 취약점 대응 책임도 직접 진다는 뜻입니다.

SaaS는 공급사가 인프라와 업데이트를 관리하므로 내부 운영 부담이 적습니다. 그렇다고 보안 검토를 생략해도 된다는 의미는 아닙니다. 데이터 암호화, 관리자 접근 통제, 다중 인증, 백업 주기, 국내외 데이터 저장 위치, 장애 공지 절차를 확인해야 합니다. 계약 종료 후 데이터가 언제 삭제되는지까지 문서로 받아야 편의성과 책임의 경계가 분명해집니다.

• 우리 데이터가 저장되는 국가와 리전을 확인했습니까?
• 관리자 권한 변경과 다운로드 기록을 감사 로그로 남길 수 있습니까?
• 퇴사자 계정이 자동으로 차단되도록 인사 시스템과 연결할 수 있습니까?
• 장애 발생 시 복구 목표 시간과 보상 기준이 계약서에 있습니까?
• 원본 데이터와 첨부 파일을 범용 형식으로 일괄 반출할 수 있습니까?

업데이트를 받는 쪽과 결정하는 쪽의 대결

SaaS를 쓰는 동안 가장 편했던 점은 기능 개선과 보안 업데이트를 별도 프로젝트 없이 받을 수 있다는 것이었습니다. 모바일 화면, 알림 기능, 외부 서비스 연동이 꾸준히 좋아졌고 운영팀은 배포 작업을 하지 않아도 됐습니다. 반면 공급사가 화면이나 정책을 바꾸면 내부 매뉴얼과 교육 자료를 급히 수정해야 했고, 익숙한 기능이 사라져도 되돌리기 어려웠습니다.

맞춤형 솔루션은 업데이트 시기와 범위를 스스로 정할 수 있습니다. 성수기에는 변경을 멈추고 비수기에 충분히 테스트한 뒤 배포하는 식의 운영이 가능합니다. 그러나 담당 개발자가 바뀌거나 오래된 기술이 쌓이면 작은 수정도 위험한 작업이 됩니다. 사업은 지속적인 거래와 운영의 연속이라는 business 용어 설명을 떠올리면, 시스템 역시 한 번 완성하는 제품이 아니라 계속 관리해야 할 운영 자산에 가깝습니다.

1. 변경 요청 창구를 하나로 통합해 현업의 요구가 개발자에게 직접 흩어지지 않게 합니다.
2. 요청마다 매출 영향, 시간 절감, 법적 필요성 중 하나의 근거를 붙입니다.
3. 월 1회 우선순위를 검토하고 SaaS 설정으로 해결할지 개발할지 나눕니다.
4. 배포 후에는 처리 시간, 오류율, 문의 건수를 이전 수치와 비교합니다.

둘 중 하나만 고집할 필요도 없습니다. 전자결재·화상회의처럼 범용 업무는 SaaS로 빠르게 운영하고, 가격 산정·생산 배차처럼 경쟁력이 숨어 있는 핵심 업무만 맞춤 개발하는 혼합형 구조가 현실적인 경우가 많았습니다. 이때 TS컴퍼니 같은 종합 비즈니스 솔루션 파트너에게 기대할 역할은 제품 판매보다 업무 경계를 나누고 연동 책임을 명확히 하는 것입니다.

직원 42명 유통사의 주문 지연을 8주 동안 따라가다

모든 것을 새로 만들려던 첫 주

직원 42명인 생활용품 유통사 A사는 온라인몰 세 곳과 전화 주문을 함께 처리했습니다. 주문 담당자가 데이터를 엑셀로 합친 뒤 창고에 메신저로 보내는 구조였고, 오후 주문이 다음 날 출고 목록에서 빠지는 일이 월 15건가량 발생했습니다. 대표는 처음에 주문·재고·배송을 모두 담은 맞춤형 시스템을 만들고 싶어 했습니다.

인터뷰를 진행하자 문제의 중심은 주문 화면이 아니라 채널마다 다른 상품 코드였습니다. 전체 시스템을 새로 개발하면 약 4개월이 필요했지만, 회사가 원하는 것은 두 달 안에 누락을 줄이는 일이었습니다. 그래서 주문 수집과 담당자 알림은 구독형 서비스로 시작하고, 상품 코드 변환 규칙만 작은 맞춤형 모듈로 개발하는 대결 구도를 세웠습니다.

• 1주 차: 최근 한 달 주문 1,860건의 유입 경로와 누락 지점을 표시했습니다.
• 2주 차: SaaS 체험 계정에서 쇼핑몰 주문을 자동 수집하고 담당자 다섯 명에게 역할을 배정했습니다.
• 3~4주 차: 서로 다른 상품 코드를 대표 코드로 바꾸는 변환 모듈을 연결했습니다.
• 5주 차: 출고 실패와 재고 부족 알림 기준을 정하고 중복 알림을 줄였습니다.
• 6~8주 차: 현업 문의와 오류 기록을 바탕으로 예외 상품 37개의 규칙을 보완했습니다.

구독과 개발이 각각 이긴 구간

SaaS는 속도에서 이겼습니다. 2주 차부터 주문이 한 화면에 모였고, 담당자가 휴가를 가도 다른 직원이 처리 상태를 확인할 수 있었습니다. 맞춤형 모듈은 정확도에서 이겼습니다. 묶음 상품과 낱개 상품의 재고 차감 규칙을 회사 방식대로 구현하자 사람이 코드를 바꿔 입력하는 작업이 사라졌습니다.

8주 뒤 주문 누락은 월 15건에서 2건으로 줄었고, 매일 90분가량 걸리던 주문 취합은 약 20분으로 단축됐습니다. 계정 구독과 연동 도구 비용은 월 약 80만 원, 변환 모듈 개발비는 1,200만 원이 들었습니다. 모든 기능을 맞춤 개발하는 초기 견적보다 시작 비용이 낮았고, 모든 것을 SaaS 설정에 맞출 때 남았을 상품 코드 오류도 피했습니다.

1. 누락 주문 2건의 원인을 매월 운영 회의에서 다시 추적합니다.
2. 신규 판매 채널을 열기 전 API와 상품 코드 규칙부터 시험합니다.
3. 사용하지 않는 계정은 분기마다 회수해 구독료 증가를 막습니다.
4. 변환 모듈의 소스, 규칙 문서, 복구 절차를 사내 저장소에도 보관합니다.
5. 주문량이 현재의 두 배가 되는 시점에 SaaS 요금과 자체 구축 비용을 다시 견적 냅니다.

A사는 8주 차에 어느 한쪽을 승자로 선언하지 않았습니다. 대신 표준 업무는 SaaS, 경쟁력과 오류가 집중된 규칙은 맞춤 개발이라는 경계를 운영 원칙으로 등록했습니다. 다음 달 묶음 상품이 추가되자 담당자는 새 시스템을 찾지 않고 코드 변환 규칙 한 줄을 요청했고, 테스트 주문 세 건이 모두 정상 출고된 뒤 그 상품을 판매 목록에 올렸습니다.