맞춤형 ERP와 커스터마이징한 기성 ERP 중 어느 쪽이 맞습니까?

부다페스트의 소프트웨어 개발 회사인 Mesterséges Intelligencia Központ Kft.는 프로세스를 표준에 맞출 수 있다면 기성 ERP가 좋고, 업무 방식이 다르거나 커스터마이징이 이미 업그레이드를 위협할 정도라면 맞춤형 ERP가 좋다고 봅니다.

핵심: 길은 세 가지입니다. 기성 ERP를 그대로 쓰는 것, 기성 ERP를 설정하고 공급사의 확장 지점을 통해 보완하는 것, 그리고 맞춤형 ERP입니다. 기성 시스템의 코어에 깊이 손대야 할수록, 고유한 부분을 별도의 모듈로 분리하거나 자체 시스템을 구축하는 편이 더 낫습니다. 어떤 길을 택하든, 사전에 데이터를 정제하고 단계적으로 전환하는 것이 한 번에 크게 바꾸는 것보다 위험이 작습니다.

ERP란 무엇입니까?

ERP(enterprise resource planning, 전사적 자원 관리 시스템)는 회사의 핵심 프로세스를 하나의 시스템으로 묶습니다. Microsoft의 정의에 따르면 ERP는 재무, 공급망, 생산, 인사, 구매, 프로젝트 관리 같은 핵심 프로세스를 조직이 통합할 수 있도록 돕는 업무 관리 소프트웨어입니다(Microsoft: What is ERP?).

실무에서 ERP의 가치는 같은 데이터가 한 번만 만들어진다는 데 있습니다. 들어온 주문이 창고 출고가 되고, 출고가 청구서가 되며, 청구서가 회계 전표와 미수금이 됩니다. 이 단계들이 별도의 프로그램과 스프레드시트에 흩어져 있으면 데이터는 손으로 옮겨지고, 오류도 함께 옮겨집니다. 고객과 영업 관리는 관련된 분야이지만 별도의 결정입니다. 이에 관해서는 맞춤형 CRM 개발은 언제 가치가 있습니까? 글에서 다룹니다.

ERP를 도입하는 세 가지 길

“맞춤형 또는 기성”이라는 질문은 사실 세 가지 선택지 사이의 선택입니다. 경계가 뚜렷하지는 않지만, 비용, 업그레이드, 종속성 면에서 차이는 큽니다.

기성 ERP를 그대로 사용

회사가 기성 제품을 도입하고, 자체 프로세스를 제품의 표준 작동 방식에 맞춥니다. 프로세스가 일반적이고 회사가 익숙한 업무 방식을 바꿀 준비가 되어 있다면 잘 작동합니다. 장점은 더 빠른 시작과 공급사가 제공하는 업그레이드이고, 단점은 제품이 다루지 못하는 부분이 스프레드시트나 수작업으로 계속 남는다는 것입니다.

설정하고 확장한 기성 ERP

대부분의 도입 사례는 이 단계 어딘가에 있습니다. 업그레이드 용이성 측면에서 의미가 크게 다르므로, 다음 세 가지를 구분하는 것이 좋습니다.

구성(설정): 공급사가 미리 제공하는 옵션을 프로그래밍 없이 사용하는 것입니다. 워크플로, 승인 단계, 필드, 문서 양식, 권한이 여기에 해당합니다.
확장(extension): 공급사가 지원하고 문서화한 확장 지점과 인터페이스를 통해, 제품 자체의 코드를 수정하지 않고 새 기능을 추가하는 것입니다.
수정(코어 커스터마이징): 공급사 자체의 코드나 객체를 다시 작성하거나, 복사한 뒤 다시 작성하는 것입니다. 가장 큰 자유를 주지만, 공급사들의 자체 문서에 따르면 업그레이드할 때 위험도 가장 큽니다(아래 참고).

맞춤형 ERP

시스템은 회사 자체의 프로세스와 데이터 모델을 바탕으로 만들어지며, 실제로 필요한 것만 개발됩니다. 업그레이드해야 할 공급사의 코어가 없고, 추가 개발은 고객이 결정합니다. 그 대신 개발, 운영, 유지보수를 자체 팀이나 계약한 개발사를 통해 조직해야 합니다. 맞춤 소프트웨어와 기성 소프트웨어의 일반적인 비교는 맞춤 소프트웨어와 기성 솔루션(SaaS) 중 어느 쪽이 맞습니까? 글에서 다룹니다.

커스터마이징이 많으면 왜 업그레이드가 어려워집니까?

기성 ERP의 공급사는 정기적으로 수정 패치와 새 버전을 내놓습니다. 회사가 공급사의 코드를 수정했다면, 업그레이드할 때마다 그 수정이 여전히 작동하는지 확인해야 하고, 다시 작성해야 하는 경우도 많습니다. 대형 공급사들의 자체 문서도 같은 결론에 이릅니다.

SAP: “클린 코어(clean core)” 접근 방식에 따르면 확장은 명확하게 정의되고 업그레이드에도 안정적인 인터페이스를 통해 SAP 애플리케이션과 엄격히 분리해 두어야 합니다. 공급사는 자사 객체를 직접 수정하거나 복사하는 방식을 더 문제가 많다고 보는데, 패치나 업그레이드가 있을 때마다 철저한 재테스트가 필요할 수 있기 때문입니다(SAP Learning: Introducing the Clean Core Approach).
Microsoft Dynamics 365: Finance, Supply Chain, Commerce 제품에서 공급사는 확장 기반 모델을 채택한 이유로, 클라우드와 잦은 업데이트에는 덜 침습적인 커스터마이징이 필요하며 그래야 업데이트가 맞춤형 솔루션에 영향을 줄 가능성이 줄어든다는 점을 듭니다. 이 제품들에서는 확장이 유일한 커스터마이징 방법이며, 애플리케이션 코드를 덮어쓰는 방식(overlayering)은 지원되지 않습니다(Microsoft Learn: Extensibility home page).
Odoo: 문서에 따르면 맞춤형 모듈이 포함된 데이터베이스는 맞춤형 모듈이 대상 버전에 맞게 준비되기 전까지 업그레이드할 수 없으며, 호환성은 맞춤형 모듈의 유지보수 담당자가 책임집니다(Odoo: Upgrade).

SAP와 Microsoft에서 얻는 교훈은 같습니다. 코어는 손대지 않은 채로 두고, 회사에 고유한 부분은 분리 가능한 확장이나 별도의 모듈에 두어 문서화된 인터페이스로 기성 시스템과 소통하게 해야 합니다. Odoo에서는 맞춤형 모듈의 유지보수가 시스템을 언제 업그레이드할 수 있는지를 결정합니다. 필요한 고유 기능이 너무 많아 이를 더 이상 깔끔하게 해결할 수 없다면, 이는 맞춤형 ERP나 맞춤형 모듈을 택해야 한다는 강한 신호입니다.

헝가리의 특수 사항: NAV Online Számla, 청구서 발행, 은행, 온라인 쇼핑몰

헝가리 회사의 ERP는 헝가리 현지 시스템과도 함께 작동해야 합니다. 가장 중요한 것은 헝가리 국세청(NAV)의 온라인 청구서 데이터 보고 시스템인 NAV Online Számla입니다. NAV의 안내에 따르면 2021년 1월 4일부터 헝가리 부가가치세법의 청구서 발행 규정이 적용되는 모든 청구서, 수정 청구서, 취소 청구서에 관한 데이터를 보고해야 합니다(NAV: Online Számla).

시스템 간 연결(시스템 간 인터페이스)의 지원 버전은 3.0입니다(2026년 10월 17일 확인). 인터페이스 명세에 따르면 청구서 발행 프로그램은 프로세스 안에서 별도의 사람의 개입 없이 자동으로 데이터를 보고해야 합니다. NAV는 제출된 데이터를 비동기 방식으로 처리하며, 프로그램이 처리 성공을 확인하고 해당 청구서의 접수 확인 메시지를 받기 전까지는 데이터 보고가 완료된 것으로 보지 않습니다(NAV Online Számla: 문서). NAV는 명세를 수시로 개정하며 2026년 8월에도 개정판을 공개했으므로, 연동은 계속 유지보수해야 합니다.

헝가리에서 ERP가 일반적으로 갖춰야 하고 저희가 연동하는 기능은 다음과 같습니다.

NAV Online Számla: 시스템 간 인터페이스를 통한 청구서 데이터 제출, 처리 결과 조회, 오류 처리.
청구서 발행 서비스: 청구서 발행을 외부 청구서 발행 서비스에서 계속하는 경우, 해당 서비스의 인터페이스를 통한 연결.
은행: 은행 거래 내역서와 거래 데이터 불러오기, 입금 내역과 청구서 대조.
온라인 쇼핑몰: 온라인 쇼핑몰과 ERP 간의 주문, 재고, 가격 동기화.
택배사 및 기타 시스템: 택배 발송, 기존 CRM, 이메일, 캘린더.

기성 ERP를 선택할 때는 제품에 헝가리 현지화 버전이 있는지, 명세가 바뀌면 누가 NAV 연동을 유지보수하는지, 헝가리 은행 및 청구서 발행 서비스와는 어떻게 연결되는지 물어보는 것이 좋습니다. 맞춤형 ERP에서는 이런 연동이 개발의 일부입니다. 시스템 연동에 관해서는 프로세스 자동화 페이지에서 더 자세히 다룹니다.

의사결정 표

기준	기성 ERP 그대로	확장한 기성 ERP	맞춤형 ERP
프로세스와의 적합성	회사가 표준 프로세스에 맞춤	표준 대부분이 맞고, 몇몇 부분만 고유함	업무 방식이 표준과 크게 다름
시작	설정만으로 충분하다면 대체로 빠름	확장 기능 개발 때문에 더 오래 걸림	개발 기간이 필요하며, 단계적으로 가동할 수 있음
업그레이드	공급사가 제공하며 위험이 적음	업그레이드할 때마다 확장 기능을 확인해야 함	고객이 일정을 정하고 개발사가 수행함
고유한 프로세스	설정으로만 가능	확장 지점이나 별도 모듈로 구현	어떤 비즈니스 로직이든 가능
연동	공급사와 그 파트너의 커넥터로	커넥터와 맞춤형 연동으로	인터페이스나 데이터에 접근할 수 있는 것이라면 무엇이든
비용 구조	공급사 조건에 따른 라이선스 또는 구독료	라이선스에 더해 확장 기능의 개발과 유지보수	개발, 운영, 추가 개발
종속성	공급사와 제품의 앞날에 종속	공급사와 확장 기능을 개발하는 파트너에 종속	소스 코드를 보유하므로 다른 개발사와도 이어 갈 수 있음
누구에게 맞습니까?	업무 방식이 일반적이고 빠른 시작이 필요한 회사	표준이 좋은 기반이지만 몇몇 부분이 다른 회사	업무 방식이나 연동이 고유한 회사

혼합형 방식도 흔합니다. 재무와 회계에는 기성 ERP를 그대로 쓰고, 맞춤형 생산 일정 계획이나 가격 책정 같은 회사 고유의 프로세스는 인터페이스로 기성 시스템과 소통하는 별도의 맞춤형 모듈에서 실행합니다.

기존 시스템에서의 전환

ERP 프로젝트가 백지 상태에서 시작되는 경우는 드뭅니다. 여러 해의 데이터가 담긴 오래된 프로그램, 기성 시스템, 또는 스프레드시트 묶음이 이미 있습니다. 전환 단계는 다음과 같습니다.

현황 분석: 어떤 데이터, 프로세스, 연결이 있는지, 그리고 지금 시스템 밖의 스프레드시트에서 처리되는 것은 무엇인지 파악합니다.
데이터 현황 파악과 정제: 데이터를 옮기기 전에 중복된 고객, 불완전한 품목 마스터, 오래된 항목을 정리합니다.
데이터 매핑: 기존의 각 필드가 새 시스템의 어디로 가는지, 그리고 이미 마감된 기존 항목은 어떻게 처리할지 정합니다.
시험 이전: 기존 데이터를 테스트 환경으로 옮기고, 핵심 사용자가 실제 사례로 이를 확인합니다.
단계적 운영 개시: 일상 업무가 멈추지 않도록 모듈별 또는 사업장별로, 경우에 따라 기존 시스템과 새 시스템을 짧은 기간 병행 운영하면서 전환합니다.
사후 관리: 실제 운영 개시 후 오류 수정, 추가 교육, 운영을 진행합니다.

모든 것을 한 번에 교체할 필요는 없습니다. 새 모듈을 먼저 기존 시스템 옆에 두고, 기존 부분을 대체할 수 있을 때까지 두 시스템이 인터페이스를 통해 데이터를 주고받게 하는 것이 현실적인 방법인 경우가 많습니다.

위험 요소와 그 대응

너무 큰 첫 단계: 모든 것을 한꺼번에 가동하면 오류 하나가 회사 전체를 멈춰 세웁니다. 범위가 명확한 모듈 하나로 시작하는 것이 좋습니다.
정리되지 않은 데이터: 잘못된 데이터는 새 시스템에서도 잘못된 채로 남습니다. 데이터 정제는 나중에 하는 일이 아니라 프로젝트의 일부입니다.
숨겨진 프로세스: 중요한 단계 중 상당수가 스프레드시트나 특정 직원의 머릿속에만 있습니다. 현황 분석에서 이런 부분까지 드러내야 합니다.
핵심 사용자의 부재: 일상 업무를 하는 사람들이 설계와 테스트에 참여하지 않으면, 시스템 옆에서 스프레드시트가 계속 쓰입니다.
연동 오류: 동기화가 멈춘 것을 모르고 지나치지 않도록 NAV, 은행, 온라인 쇼핑몰 연결에는 로그 기록과 오류 알림이 필요합니다.
일방적인 종속: 전체 소스 코드와 문서를 인도하면 나중에 다른 개발사와도 시스템을 이어 갈 수 있습니다.

ERP에서 인공지능은 어디에 도움이 됩니까?

대규모 언어 모델(OpenAI의 ChatGPT, Anthropic의 Claude, Google의 Gemini)은 지금까지 사람이 읽거나 옮겨 적거나 글을 쓰던 곳에서 유용합니다.

문서: 들어오는 청구서, 납품서, 주문서의 데이터를 읽어 내어, 검토할 수 있도록 준비된 상태로 기록합니다.
이메일: 수신된 주문 이메일을 처리하고 답장 초안을 준비합니다.
데이터에 대한 질문: 일상적인 말로 시스템에 질문할 수 있습니다. 예를 들어 어떤 고객이 기한이 지난 청구서를 아직 결제하지 않았는지 물을 수 있습니다.
이상 항목 표시: 예를 들어 고객의 이전 주문과 크게 다른 주문처럼 특이한 항목을 검토 대상으로 표시합니다.

실수가 금전적 손실로 이어지는 곳에서는 AI가 제안하고 사람이 승인합니다. 모델 연결과 데이터 보호에 관해서는 AI 통합 페이지에서 설명합니다.

저희의 경험

현재도 하나의 대규모 ERP 및 CRM 시스템을 개발하고 있으며, 고객과 제품의 이름은 공개하지 않습니다. ERP에서 어려운 부분은 화면인 경우가 드뭅니다. 직원들이 시스템을 실제로 사용할지, 아니면 그 옆에서 계속 스프레드시트를 관리할지는 데이터 모델, 권한, 연동, 기존 데이터의 이관이 결정합니다.

자주 묻는 질문

맞춤형 ERP 개발은 언제 가치가 있습니까?

회사의 업무 방식이 기성 ERP가 전제하는 방식과 크게 다르고 그 차이를 유지하고 싶을 때, 많은 시스템을 연결해야 하는데 기성 커넥터가 없을 때, 또는 필요한 커스터마이징이 공급사의 코어를 수정해야 할 정도일 때 가치가 있습니다. 기성 ERP가 설정만으로 프로세스의 대부분을 충족한다면 대개 그쪽이 더 빠른 길이며, 첫 상담에서 그렇다고 말씀드립니다.

기성 ERP는 얼마나 커스터마이징할 수 있습니까?

여러 방식으로 가능하지만, 어떤 방식인지가 중요합니다. 설정(구성)과 공급사가 지원하는 확장 지점은 업그레이드에 거의 영향을 주지 않습니다. 반면 공급사의 코드를 수정하면 업그레이드할 때마다 새로운 작업이 생길 수 있습니다. 대형 공급사인 SAP와 Microsoft의 문서는 코어를 손대지 않고 확장을 분리해 두도록 권장하며, Odoo의 문서에 따르면 맞춤형 모듈의 유지보수가 업그레이드의 전제 조건입니다.

커스터마이징이 많으면 어떤 위험이 있습니까?

무엇보다 업그레이드가 비싸지고 위험해집니다. 새 버전이 나올 때마다 수정 사항을 확인하고 다시 작성해야 하는 경우가 많으며, 일부 공급사에서는 맞춤형 부분이 새 버전에 맞게 준비되기 전까지 업그레이드 자체를 할 수 없습니다. 또한 회사가 확장 기능을 개발하는 파트너에게도 종속됩니다. 커스터마이징의 규모가 이를 정당화한다면, 맞춤형 모듈이나 맞춤형 ERP의 비용과 비교해 보는 것이 좋습니다.

기존 시스템에서의 전환은 어떻게 진행됩니까?

현황 분석, 데이터 정제, 데이터 매핑으로 시작하고, 이어서 테스트 환경에서 시험 이전을 한 뒤, 모듈별로 또는 기존 시스템과 새 시스템을 짧은 기간 병행 운영하면서 단계적으로 운영을 개시합니다. 실제 운영 개시 후에는 오류 수정과 운영이 이어집니다. 기존 시스템은 인터페이스로 연결된 채 한동안 새 시스템과 함께 운영될 수도 있습니다.

NAV Online Számla도 연동합니까?

네. NAV 인터페이스 명세가 요구하는 대로 NAV의 시스템 간 인터페이스를 통해 청구서 데이터를 제출하고, 처리 결과를 조회하며, 오류를 처리합니다. 같은 방식으로 외부 청구서 발행 서비스, 은행, 온라인 쇼핑몰도 연결합니다.

저희는 어떻게 도와드립니까?

Mesterséges Intelligencia Központ Kft.는 맞춤형 ERP, CRM 및 업무 관리 시스템을 개발하고, 기성 시스템을 위한 맞춤형 모듈과 연동을 만들며, 이들을 인공지능으로 연결합니다. 첫 상담은 무료이며, 기성 ERP로 충분하다면 그렇다고 말씀드립니다. 개발의 기능 규모를 COSMIC 기능점수(ISO/IEC 19761)로 측정하고, 이를 바탕으로 견적과 일정을 작성합니다. 그 방법은 비용 산정 페이지에서 설명합니다. 요청하시면 비밀유지계약(NDA)을 체결하며, 인도 후에는 운영과 유지보수도 맡습니다. 소스 코드와 이용 권리는 계약으로 정합니다.

자세한 내용은 업무용 소프트웨어 페이지에서 보실 수 있습니다. 귀사의 시스템에 관해 이야기를 나누고 싶으시면 연락처 페이지에 안내된 연락처로 메시지를 보내 주시기 바랍니다.