ERP·CRM 구축: 맞춤 개발과 SaaS 중 무엇을 고를까

성장하는 회사는 대부분 엑셀, 이메일, 단톡방만으로는 더 이상 업무를 붙잡아 둘 수 없는 시점을 맞습니다. 그다음에는 더 어려운 질문이 기다립니다. 이미 만들어진 SaaS를 구독할 것인가, 아니면 회사의 일하는 방식에 맞춰 소프트웨어를 만들 것인가? 이 가이드는 ERP, CRM, 업무 흐름(워크플로) 시스템이 각각 무엇을 하는지, 선택지를 어떻게 솔직하게 저울질하는지, 그리고 어떤 길을 고르든 어떻게 도입하는지를 설명합니다.

핵심 요약

대부분의 중소기업에 가장 안전한 길은 병행입니다. 회계와 인보이스처럼 표준적인 업무는 꾸준히 관리되는 소프트웨어나 SaaS를 쓰고, 회사를 차별화하는 프로세스만 직접 만드십시오. 결정은 여섯 가지 기준(프로세스의 고유성, 연동, 사용자와 권한, 데이터 소유권, 장기 비용, 종속 위험)으로 내리고, 프로세스 정리, MVP, 단계별 적용 순서로 도입하며, 어떤 길을 고르든 데이터와 코드가 회사 소유로 남도록 하십시오.

엑셀과 단톡방으로 버티기 어려워졌다는 신호

엑셀과 메신저는 여러 사람이 손으로 계속 맞춰 줘야 사업이 돌아가는 순간부터 무너지기 시작합니다. 전형적인 신호는 다음과 같습니다.

같은 데이터를 여러 곳에 입력합니다. 주문이 엑셀에 들어가고, 다시 인보이스 도구에, 다시 창고에 보내는 메시지에 들어가면서 버전이 서로 어긋납니다.
아무도 재고 숫자를 믿지 않습니다. 재고보다 많이 팔거나, 갑자기 품절되거나, 재고 조사 때마다 차이가 납니다.
결재가 채팅방에서 이루어집니다. 누가 할인을 승인했는지 알려면 몇 주 치 메시지를 거슬러 올라가야 합니다.
고객 이력이 사람과 함께 떠납니다. 영업 담당자가 퇴사하면 연락처와 대화 내용이 그 사람의 휴대폰과 함께 사라집니다.
보고서 하나를 만드는 데 며칠이 걸리고, 핵심 엑셀 파일을 이해하는 사람은 단 한 명뿐입니다.
모두가 원가까지 포함해 모든 것을 보고 고칠 수 있고, 누가 무엇을 바꿨는지 기록도 없습니다.

이 중 한두 가지라면 잘 고른 도구 하나나 간단한 자동화로 충분할 수 있으며, 그 방법은 업무 자동화 툴 비교에서 다룹니다. 여러 가지가 한꺼번에 보인다면 제대로 된 시스템을 갖출 때입니다.

ERP, CRM, 업무 흐름 시스템은 각각 무엇을 하나

ERP는 운영과 돈을, CRM은 고객과 영업을, 업무 흐름 시스템은 사내 결재와 협업을 관리합니다. 여러 영역을 함께 다루는 제품도 많지만 핵심 역할은 다릅니다.

ERP(전사적 자원 관리)는 운영과 돈을 다룹니다. 구매, 재고, 판매 주문, 인보이스, 그리고 흔히 회계, 생산, 다중 창고까지 포함합니다.
CRM(고객 관계 관리)은 고객과 영업을 다룹니다. 연락처, 리드, 영업 파이프라인, 견적, 후속 관리, 모든 대화의 이력입니다.
업무 흐름(워크플로) 시스템은 사내 프로세스를 다룹니다. 구매, 경비, 휴가 결재와 공유 문서, 업무 관리이며, 한국에서는 흔히 그룹웨어나 전자결재 시스템이라고 부릅니다. Microsoft 365나 Google Workspace 같은 제품군이 이미 일부를 담당하기도 합니다.

가장 중요한 것은 이 시스템들이 데이터를 공유하는 것입니다. 고객 정보도, 상품 목록도, 가격표도 하나여야 합니다.

세 가지 길: 기성 제품, 맞춤 개발, 병행

길은 세 가지입니다. 기성 소프트웨어나 SaaS를 구독하거나, 시스템을 맞춤 개발하거나, 둘을 병행하는 것입니다.

기성 소프트웨어와 SaaS. ERP라면 Odoo나 NetSuite, CRM이라면 HubSpot이나 Salesforce처럼 이미 있는 제품을 구독하고 설정해서 씁니다. 검증되어 있고 빨리 시작할 수 있으며, 업데이트와 보안은 공급사가 맡고, 보통 사용자 수나 모듈 단위로 비용을 냅니다. 대신 회사가 제품에 맞춰야 하고, 제품 로드맵은 공급사의 것입니다.

맞춤 개발. 개발팀이 회사의 프로세스에 맞춰 소프트웨어를 만듭니다. 업무에 정확히 맞고, 사용자당 라이선스 비용이 없으며, 진짜 경쟁력이 될 수 있습니다. 대신 초기 투자가 크고, 실제로 쓰기까지 시간이 더 걸리며, 유지보수, 보안, 호스팅을 계속 책임져야 합니다.

병행. 표준적인 부분은 표준 소프트웨어를 쓰고, 차별화되는 부분만 직접 만듭니다. 회계, 인보이스, 급여는 나라마다 세무와 전자 인보이스 규정이 다르고 자주 바뀌므로 꾸준히 관리되는 제품에 맡기는 편이 대개 낫습니다. 예를 들어 EU는 2025년에 채택한 디지털 시대의 부가가치세(ViDA) 패키지(영문)로 2030년 7월 1일부터 국경 간 B2B 거래에 전자 인보이스 기반의 디지털 보고를 도입합니다. 이런 회계 중심부 주위에 온라인 쇼핑몰 연동, 도매 고객용 주문 포털, 창고 직원용 모바일 앱 등을 만들 수 있습니다(모바일 앱은 앱 개발 과정: 기획부터 출시까지 참고). Odoo 커뮤니티 버전(LGPLv3 라이선스)이나 ERPNext 같은 오픈소스 ERP는 그 중간입니다. 직접 호스팅하고 수정할 수 있지만, 수정한 내용은 업그레이드할 때마다 함께 이어 가야 합니다.

많은 중소기업에는 병행이 합리적인 기본값입니다.

결정을 가르는 여섯 가지 기준

맞춤 개발과 SaaS 사이의 결정을 가르는 기준은 여섯 가지입니다. 프로세스가 얼마나 고유한가, 연동, 사용자와 권한, 데이터 소유권, 장기 비용 요인, 공급사 종속입니다.

프로세스가 얼마나 고유한가? 고객별 가격 체계나 독특한 생산 흐름처럼 그것이 회사의 경쟁 방식이라면, 범용 소프트웨어에 억지로 끼워 맞추는 데 대가가 따릅니다. 장부 정리처럼 표준적인 업무라면 새로 만들지 마십시오.
연동. 데이터를 주고받아야 할 시스템을 모두 적으십시오. 온라인 쇼핑몰, 오픈마켓, 결제, 택배사, 회계, 은행, 홈페이지 문의 양식 등입니다(쇼핑몰 플랫폼을 고르는 중이라면 쇼피파이 vs 우커머스 vs 맞춤 개발 비교 참고). 기성 커넥터가 있는지, 문서화된 API와 감당할 만한 호출 한도가 있는지 확인하십시오. 예를 들어 HubSpot의 API 사용 가이드라인(영문)은 비공개 배포 앱의 하루 호출 한도를 구독 등급별로 정해 두고 있습니다. 계정당 Free와 Starter는 25만 회, Professional은 62만 5천 회, Enterprise는 100만 회입니다. 진짜 복잡함은 연동에 숨어 있는 경우가 많습니다. 깔끔한 API가 있으면 나중에 AI 어시스턴트를 연결하기도 훨씬 쉬워집니다. 예를 들어 AI 애플리케이션을 외부 시스템에 연결하는 오픈소스 표준인 MCP(Model Context Protocol)(영문)를 쓸 수 있습니다(AI 솔루션 참고).
사용자와 권한. 사용자당 요금제는 창고 직원, 배송 기사, 외부 파트너처럼 가끔 쓰는 사용자가 많을수록 비싸집니다. 영업 담당자는 자기 고객만 보고 일부 역할에는 원가를 숨기는 식의 세밀한 권한을 일찍 확인하십시오. 일부 SaaS는 이를 상위 요금제에서만 제공합니다.
데이터 소유권. 데이터는 어디에 저장되며, 이력과 첨부 파일까지 포함한 전체 데이터를 쓸 수 있는 형식으로 내보낼 수 있습니까? 해지하면 어떻게 됩니까? EU에 있는 사람의 개인정보를 처리한다면 GDPR이 적용됩니다. 회사를 대신해 그 데이터를 처리하는 업체는 수탁자(processor)이며, 유럽 개인정보보호이사회(EDPB)의 중소기업용 가이드(영문)는 컨트롤러와 수탁자의 관계가 “계약으로 규율되어야 한다”고 밝힙니다. 보통 데이터 처리 계약(DPA)이라고 부릅니다.
장기 비용 요인. 시스템을 쓸 것으로 예상되는 전체 기간의 총비용을 비교하십시오. SaaS 비용은 사용자 수, 추가 모듈, (API 접근 같은 기능을 위한) 상위 요금제, 갱신 시 가격 변경에 따라 늘어납니다. 맞춤 개발 비용은 초기 구축(범위, 역할, 업무 규칙, 연동에 따라 달라짐), 호스팅, 보안 업데이트, 새 기능에서 나옵니다. 둘 다 데이터 이전, 교육, 사내 인력의 시간이 듭니다.
공급사 종속. SaaS에서는 폐쇄적인 데이터 형식, 가격 인상, 기능 단종이 위험입니다. 맞춤 개발에서는 다른 누구도 코드를 이해하지 못해 한 개발사에 묶이는 것이 위험입니다. 두 위험의 처방은 같습니다. 실제로 시험해 본 전체 데이터 내보내기, 문서화, 널리 쓰이는 기술, 그리고 계약 종료까지 다루는 계약서입니다.

맞춤 시스템의 범위 정하기: 프로세스, MVP, 단계별 적용

맞춤 시스템의 범위는 네 단계로 정합니다. 현재 프로세스를 정리하고, 단순화하고, MVP를 정의한 뒤, 단계별로 적용합니다. 가장 값비싼 실수는 엉뚱한 것을 만드는 것이며, 이 순서가 그것을 막아 줍니다.

현재 프로세스를 정리하십시오. 주문 하나, 구매 하나, 고객 문의 하나를 처음부터 끝까지 따라가 보십시오. 관리자만이 아니라 실제로 일하는 사람들과 이야기하고, 실제 주문서, 인보이스, 엑셀 파일을 모으십시오. 요구사항은 예외 상황과 임시방편 속에 숨어 있습니다.
디지털화하기 전에 단순화하십시오. 엉망인 프로세스를 자동화하면 엉망이 더 빨리 돌아갈 뿐입니다.
MVP를 정의하십시오. 최소 기능 제품(MVP)은 실제 업무 흐름 하나를 처음부터 끝까지 대체하는 가장 작은 버전입니다. 예를 들어 창고 한 곳의 주문, 재고 반영, 납품서 발행입니다. 역할, 권한, 주요 화면, 연동, 사람들이 실제로 보는 몇 가지 보고서를 적어 두십시오.
단계별로 적용하십시오. 시범 팀이나 시범 지점에서 시작해 발견된 문제를 고친 뒤 넓혀 가십시오. 이후 단계마다 구매, CRM, 전자결재 같은 모듈을 하나씩 더합니다.

견적도 단계별로 요청하십시오. 범위, 연동, 업무 규칙이 비용과 기간을 좌우하므로, 명확한 프로세스 정리가 견적을 믿을 수 있게 만듭니다.

데이터 이전과 직원들의 적응

순조로운 데이터 이전이란 무엇을 옮길지 정하고, 정리하고, 시험 삼아 가져와 본 뒤, 정해진 날짜에 전환하는 것입니다. 정착 여부는 핵심 사용자의 참여, 역할별 교육, 그리고 새 시스템을 유일한 기준으로 삼는 데 달려 있습니다.

데이터 이전: 무엇을 옮길지 정하십시오. 기준 정보(고객, 상품, 가격), 진행 중인 항목(주문, 잔액, 현재 재고), 그리고 이력을 얼마나 옮길지입니다. 오래된 기록은 읽기 전용 보관소에 남겨 둘 수 있습니다. 중복과 제각각인 상품 코드를 정리하고, 시험 가져오기를 돌리고, 창고별 재고 같은 합계를 예전 기록과 대조하십시오. 그런 다음 전환일을 정하고 예전 도구를 동결하십시오.

정착:

처음부터 팀마다 핵심 사용자 한 명씩을 참여시키십시오.
역할별로, 팀이 쓰는 언어로 된 짧은 안내서와 함께 교육하십시오.
새 시스템을 유일한 기준으로 삼으십시오. 채팅으로 들어온 주문도 따로 처리하지 말고 시스템에 입력해야 합니다.
창고와 현장 직원이 휴대폰으로 일할 수 있게 하십시오.
첫 몇 주 동안 작은 불편을 빨리 고치십시오. 사람들이 시스템을 믿을지는 거기서 결정됩니다.

개발 파트너 고르기와 피해야 할 함정

개발 파트너는 작업 범위를 어떻게 정하는지, 어떤 기술을 쓰는지, 코드와 계정을 누가 소유하는지, 어떤 문서와 테스트를 제공하는지, 출시 후에는 어떻게 되는지를 확인해 고르십시오. 물어볼 만한 질문은 다음과 같습니다.

기능 견적을 내기 전에 우리 프로세스를 정리해 줍니까? 작업을 어떤 단계로 나눕니까?
어떤 기술을 씁니까? 다른 팀이 이어받을 수 있습니까?
소스 코드는 첫날부터 우리 계정의 저장소에 있고, 클라우드, 도메인, 제3자 서비스 계정도 우리 명의입니까?
아키텍처, 데이터 모델, API 문서, 배포 안내서, 사용자 매뉴얼 중 어떤 문서를 받습니까?
테스트와 백업은 어떻게 하고, 실제로 복구를 시험해 본 적이 있습니까?
출시 후에는 어떻게 됩니까? 오류 수정, 보안 업데이트, 새 기능, 그리고 계약이 끝날 때의 인수인계는 어떻게 처리합니까?

흔한 함정은 다음과 같습니다.

엑셀의 혼란을 항목 하나하나까지 소프트웨어에 그대로 옮기는 것.
시범 운영 없이 모든 모듈을 한꺼번에 여는 것.
SaaS를 너무 많이 커스터마이징해서 공급사가 업데이트할 때마다 무언가가 고장 나는 것.
자사 데이터로 시험해 보지 않고 매끄러운 데모만 보고 결정하는 것.
결정 권한을 가진 사내 책임자가 없는 것.
유지보수 예산도, 종료 계획도 없는 것.

자주 묻는 질문

맞춤 개발은 항상 SaaS보다 비싼가요?

보통 초기 투자가 더 큽니다. 몇 년에 걸친 비교는 사용자 수, 시스템을 쓸 기간, 각 선택지에 필요한 커스터마이징과 연동의 양에 따라 달라집니다. 첫해만이 아니라 시스템 사용 기간 전체의 총비용을 비교하십시오.

SaaS로 시작했다가 나중에 맞춤 시스템으로 옮길 수 있나요?

네, 오히려 합리적인 경우가 많습니다. SaaS를 써 보면 회사에 정말 필요한 것이 무엇인지 알게 되기 때문입니다. 전체 데이터 내보내기와 문서화된 API가 있는 제품을 고르면, 나중에 옮기는 일이 구조 작업이 아니라 계획된 이전이 됩니다.

맞춤 시스템의 소스 코드는 누가 소유해야 하나요?

가능하면 회사가 소유해야 하며, 최소한 전체 접근 권한과 사용·수정 권리를 가져야 합니다. 이를 계약서에 넣고, 코드를 회사 계정의 저장소에 두고, 다른 팀이 이어받을 수 있을 만큼 충분한 문서를 요청하십시오.

ERP나 CRM 도입, 또는 지금 쓰는 도구들 사이의 연결을 고민하고 계시다면 앱·소프트웨어 개발 서비스, 프로세스 정리와 시스템 선정을 위한 전략 컨설팅을 살펴보시거나 문의하기로 연락해 주십시오. UsualMatrix는 전 세계 고객과 중국어, 스페인어, 영어로 일합니다.

참고: 이 글은 일반 정보이며 법률 자문이 아닙니다. 개인정보 보호와 세무 규정은 국가와 사업에 따라 다르므로, 구체적인 내용은 자격을 갖춘 전문가에게 확인하십시오.