ERP 통합 구조 프로젝트 킥오프마다 듣게 되는 문장이 있습니다. "UAT에서는 완벽하게 동작했는데요…"
당연히 그랬을 겁니다. UAT는 깔끔하게 정제된 샘플 데이터 위에서, 두 시스템 모두 멈춰 있는 상태에서, 개발자 한 명이 키보드 앞에 앉아, 시계도 멈춘 환경에서 돌아갑니다. 반면 프로덕션은 당신의 조직이 내려 온 모든 비즈니스 의사결정이 켜켜이 쌓인 난장판 위에서 돌아갑니다 — 중복된 고객, 도중에 바뀌는 스키마, 같은 마스터를 동시에 편집하는 두 사람, 월말 마감 러시, 새벽 2시의 네트워크 끊김.
흥미로운 질문은 당신의 ERP 통합이 이 현실에 부딪힐 것이냐가 아닙니다. 반드시 부딪힙니다. 흥미로운 것은 부딪혔을 때 어떻게 실패할 것이냐입니다. 실패하는 방식은 정말로 다섯 가지뿐이며, 각각이 밖에서 보면 다르게 보이기 때문입니다.
저희는 지난 10년 동안 아시아 태평양 지역의 제조, 이커머스, 물류, 에너지 고객을 대상으로 ERP 통합을 구축하고 수리하고 교체해 왔습니다. 그 경험을 통해 통합이라는 것을 "다섯 가지 공통 실패 모드를 가진 하나의 문제"로 보게 되었습니다. 본 글이 그 현장 가이드입니다.
접합부 문제란
모든 ERP 통합은 접합부(seam) 입니다. 스키마가 다르고, 책임자가 다르고, 릴리스 주기가 다르며, 종종 벤더마저도 다른 두 시스템이 함께 봉제되는 지점입니다. 대부분의 경우 접합부 양쪽의 시스템 자체는 멀쩡합니다. 접합부가 바로 장애가 깃드는 곳입니다.
flowchart TD
A["상류 시스템<br/>이커머스, CRM, MES, WMS"] --> B["접합부<br/>장애의 80%가 발생하는 지점"]
B --> C["ERP<br/>SAP, Oracle, 더존, ERPNext"]
B -.->|"모드 1"| D1["스키마 드리프트"]
B -.->|"모드 2"| D2["대사 없음"]
B -.->|"모드 3"| D3["동기 결합"]
B -.->|"모드 4"| D4["주관자 부재"]
B -.->|"모드 5"| D5["가관측성 없음"]아래 다섯 모드는 모두 접합부에서 발생합니다. 어느 모드가 당신을 괴롭히고 있는지 진단할 수 있으면, 해결의 방향은 보통 명확합니다 — 쉽지는 않더라도.
모드 1: 스키마 드리프트
무엇이 잘못되는가: 통합은 MOU 서명 시점의 ERP 스키마에 맞추어 구축됩니다. 6개월 후, ERP 팀이 새로운 필수 필드를 추가하거나, 명확성을 위해 컬럼명을 변경하거나, 컬럼 타입을 문자열에서 enum으로 바꿉니다. 변경이 "사소해" 보이기 때문에 통합은 계속 동작합니다 — 그러다 월말 결산에서 조용한 데이터 손상이 떠오릅니다.
증상: 대사 리포트에 "작은" 차이가 시간이 지나며 점점 커집니다. 특정 레코드 유형이 간헐적으로 실패합니다. 벤더 지원은 "그 필드는 원래 필수였습니다"라고 답합니다.
왜 발생하는가: 스키마가 계약이 아니라 문서로 취급되기 때문입니다. 개발자가 PDF를 읽고, 코딩하고, 출시합니다. 배포된 스키마가 코드가 가정하는 스키마와 여전히 일치하는지 아무도 검증하지 않습니다.
해결: 스키마를 코드로 취급하고, git으로 버전 관리하며, 매 트랜잭션마다 접합부에서 검증하세요. 드리프트는 크게 거부합니다. Pydantic, JSON Schema, Protobuf — 도구 선택보다 규율이 중요합니다. 접합부가 곧 계약이며, 강제되지 않는 계약은 그저 느낌일 뿐입니다.
모드 2: 대사 없음, 신뢰 원천 없음
무엇이 잘못되는가: 두 시스템이 동일한 데이터에 대해 서로 "내가 진본이다"라고 생각합니다. 통합은 시스템 A에서 B로 데이터를 씁니다. 그런데 누군가 가끔 B의 UI에서 직접 수정합니다. 몇 주 만에 두 쪽이 어긋나기 시작합니다. 발견은 감사 시점 — 감사인이 두 보고서를 나란히 놓고 고객 수가 왜 312명 차이나는지 묻는 순간 — 에 이루어집니다.
증상: "고객 X의 주소가 CRM과 ERP에서 다르다." 유령 재고. 마진이 멀쩡해 보이다가 어느 날 갑자기 그렇지 않게 됩니다. 재무팀과 영업팀이 누구 숫자가 맞는지 다툽니다.
왜 발생하는가: 어느 시스템이 어느 도메인을 소유하는지 아무도 결정하지 않았기 때문입니다. 또는 결정했어도 강제하지 않았기 때문 — 양쪽이 일치한다는 것을 매일 밤 증명하는 작업이 없습니다.
해결: 데이터 도메인별로 신뢰 원천을 하나로 지정하세요 — 고객, 품목, 가격, BOM, 임직원. 일일 대사 작업을 구축해 시스템 간 드리프트를 탐지합니다. 임계값을 넘는 괴리에 알람을 띄웁니다. 어떤 도메인이 진정으로 양방향 업데이트를 요구한다면, 충돌 해결 규칙과 last-writer-wins 의미론으로 명시적으로 설계합니다. 실제로는 신뢰 원천이 둘인데 하나라고 스스로를 속이지 마세요.
모드 3: 동기 결합
무엇이 잘못되는가: 상류 시스템(이커머스 결제, MES 작업 지시, CRM 거래 확정, POS 결제)의 모든 트랜잭션이 ERP로의 동기 왕복을 요구합니다. ERP가 느릴 때 — 그리고 ERP는 늘 느립니다 — 상류 시스템도 느려집니다. ERP가 월간 유지보수로 다운될 때 상류 시스템도 다운됩니다. 백오피스 시스템이어야 할 ERP가 매출의 크리티컬 패스 의존성이 되어 버립니다.
증상: ERP 배치 작업 중 이커머스 결제가 실패합니다. ERP 패치 적용 중 생산이 멈춥니다. SLA를 매달 30분씩 시계처럼 정확하게 초과합니다.
왜 발생하는가: 가장 단순한 구현이기 때문입니다. ERP에 POST, 응답 대기, 사용자에게 반환. UAT는 밀리초 응답 시간을 보여 줍니다. 프로덕션은 진실을 보여 줍니다.
해결: 영속 큐를 사용한 비동기 메시징 — NATS JetStream, RabbitMQ, Kafka. Outbox 패턴을 구현하세요: 상류 시스템은 로컬에 쓰고, 커밋하고, 반환합니다. 디스패처가 outbox를 읽어 자기 속도로 ERP에 푸시합니다. 상류 시스템은 결코 ERP를 기다리며 블록되지 않습니다. ERP가 따라잡습니다. 코드가 더 많고 인프라가 더 많지만, 상류 시스템이 자체 SLA를 가진 통합에서는 선택이 아닙니다.
모드 4: 통합이 파워포인트일 뿐, 시스템이 아님
무엇이 잘못되는가: 벤더가 아키텍처 다이어그램을 제안합니다. MOU 서명. 커넥터 구축. 컷오버. 벤더 청구서 발행. 벤더 퇴장. 6개월 후 새벽 2시에 무언가가 깨지고, 세 팀이 서로를 탓하는 동안 사업은 시간당 손실을 보고 있습니다. 아무도 런타임을 소유하지 않습니다.
증상: 네 당사자가 얽혀 사건이 길어집니다. 벤더는 "그건 ERP 문제입니다"라고 합니다. ERP 팀은 "그건 통합 문제입니다"라고 합니다. 통합 벤더는 주말에 연락이 닿지 않습니다. 해결 시간이 시간이 아닌 일 단위로 측정됩니다.
왜 발생하는가: 킥오프가 통합을 "구축하는 것"에 집중했지 "운영하는 것"에 집중하지 않았습니다. SOW에 "오픈 일자"는 있었지만 "운영 모드" 정의는 없었습니다.
해결: 첫 사건 후가 아니라 킥오프 전에 소유권을 결정하세요. 문서화합니다. 공동 런북. 공동 가관측성 대시보드. 벤더가 오픈 후에도 루프에 남는다면 공동 온콜 로테이션. 벤더가 운영 모드를 받지 않겠다고 하면, 첫날부터 사내 인수를 계획합니다. 새벽 2시의 질문에 먼저 답하도록 설계하세요: 누가 호출되고, 무엇을 들여다봅니까?
모드 5: 접합부를 가로지르는 가관측성 없음
무엇이 잘못되는가: 트랜잭션이 실패할 때 — ERP에 도달하지 못한 영업 주문, 두 번 계상된 청구서, 사라진 재고 이동 — 디버깅은 네 시스템에 로그인하고, 타임스탬프를 복사하고, 손으로 삼각측량을 해야 합니다. 단순한 사건의 진단에 사흘이 걸립니다. 그 무렵 고객은 이미 주문을 취소했고, 재무팀은 시스템에 대한 신뢰를 잃었습니다.
증상: 평균 진단 시간이 깁니다. "로그에서 판단하기 어렵습니다." 근본 원인을 찾지 못해 같은 사건이 반복됩니다. 통합은 누구도 신뢰하지 않는 블랙박스가 됩니다.
왜 발생하는가: 각 시스템이 자기 포맷, 자기 시계로 로그를 남기고, 공유 상관 ID가 없기 때문입니다. 접합부가 바로 컨텍스트가 사라지는 지점입니다.
해결: 통합 경계를 가로질러 trace ID를 전파하세요. 모든 트랜잭션은 상류 시스템에서 안정적인 상관 ID를 얻고, 통합을 통과해, ERP의 감사 로그에 도달합니다. 구조화된 로그(JSON), 중앙 집계(OpenSearch, Datadog, Grafana Loki — 이미 사용하는 것 무엇이든), 그리고 트랜잭션의 시작부터 확정까지의 전 생애주기를 모든 관련 시스템을 가로질러 한 화면에서 보여 주는 대시보드. 보이지 않는 것은 고칠 수 없고 — 추적할 수 없는 것은 신뢰할 수 없습니다.
패턴 뒤의 패턴
이 다섯 모드 중 어떤 것도 ERP 자체에 관한 것이 아니라는 점에 주목하세요. ERP — SAP, Oracle, 더존, ERPNext, Microsoft Dynamics, 어느 것이든 — 가 진짜 문제인 경우는 드뭅니다. 문제는 접합부에 있습니다. 그런데도 대부분의 ERP 통합 프로젝트는 기획 공수의 90%를 "어느 ERP를 쓸까"에, 10%를 "접합부를 어떻게 운영할까"에 씁니다.
이것은 저희가 여러 영역을 가로질러 반복적으로 배운 교훈입니다. AI 시스템에서 모델은 저렴한 부분이며 — 엔터프라이즈 데이터와의 통합이 진짜 시스템입니다. SOC 플랫폼에서 SIEM은 저렴한 부분이며 — ID, 자산, 티켓팅 시스템으로의 접합부가 진짜 시스템입니다. 이커머스에서 스토어프론트는 저렴한 부분이며 — 재고, 결제, 풀필먼트로의 접합부가 진짜 시스템입니다.
새 기술, 같은 물리. 소프트웨어의 가치는 접합부에 깃듭니다.
만약 저희 문제라면
망가진 접합부에서 건강한 통합 자산까지의 현실적인 90일 경로:
| 주차 | 초점 |
|---|---|
| 1~2주 | 접합부 감사. 모든 통합을 인벤토리. 각각이 다섯 모드 중 어느 것에 빠져 있는지 식별. 사업 영향도로 우선순위화. |
| 3~6주 | 가장 나쁜 접합부부터 수리. 스키마-애즈-코드, 대사 작업, 필요 시 비동기 패턴. 패턴 실증 사례로 활용. |
| 7~10주 | 패턴을 나머지에 전개. 모든 접합부에 가관측성과 trace 전파를 표준화. 공동 운영 소유권 문서화. |
| 11~12주 | 운영 상태 진입. 런북. 온콜. 재무에 지속 보고되는 대사 리포트. 드리프트 알람을 팀 채널에 연동. |
화려하지 않습니다. 그러나 작동합니다.
Simplico가 들어갈 자리
지난 10년 동안 저희는 ERP를 정말로 대화해야 하는 시스템들과 통합해 왔습니다 — 이커머스 플랫폼, 공장 현장의 MES, 물류 야드의 WMS, CRM, 빌링 시스템, 뱅킹 API, 관세 포털. ERPNext, Odoo, SAP, Oracle, 커스텀 빌드. 제조, 에너지, 항만, 유통.
당신의 ERP 통합이 이 다섯 가지 방식 중 하나로 실패하고 있다면 — 또는 곧 시작할 프로젝트에서 이 모두를 피하고 싶다면 — 기꺼이 살펴봐 드리겠습니다.
저희 통합 아키텍트와의 90분 통화. 현재 접합부 상태를 인벤토리하고, 어떤 실패 모드가 당신을 갉아먹고 있는지 솔직하게 짚어 드리며, 1페이지 분량의 시정 계획을 남깁니다. 슬라이드웨어는 없습니다.
Simplico는 방콕에 본사를 둔 엔지니어링 스튜디오로, AI/RAG, 사이버 보안, ERP 통합, 이커머스, 모바일 개발을 전문으로 합니다. 한국, 일본, 중국, 태국 및 영어권 시장의 엔터프라이즈 팀과 협업합니다.