사내 시스템 통합 가이드: 상품·주문·재고·정산 연결 [2026]
상품·주문·재고·정산 데이터가 여러 시스템과 엑셀에 흩어진 기업을 위해 기준 데이터 선정, API·배치·미들웨어 연동, 오류 처리와 단계적 통합 절차를 정리했습니다. 원본 시스템과 수정 권한을 정하고 연동 실패를 재처리하는 기준도 확인합니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
사내 시스템 통합은 프로그램을 한 화면에 모으는 작업이 아니라 상품·주문· 재고·고객·정산 객체의 소유권과 전달 계약을 정하는 작업입니다. 기준 시스템, 식별자, 상태 버전, 멱등성, 실패 큐와 수동 복구가 먼저 정해져야 연결이 끊겨도 데이터를 되살릴 수 있습니다.
객체와 필드별 소유권을 한 곳에 둔다#
상품명은 PIM, 회계 품목 코드는 ERP, 실물 위치는 WMS처럼 같은 객체의 필드별 책임이 다를 수 있습니다. 생성·수정·비활성화 권한, 내부 ID와 외부 ID 매핑, 다른 시스템이 보유하는 읽기 전용 복제값을 표시하세요. “최신값이 이긴다”는 규칙은 잘못된 변경도 정상값을 덮어쓰게 합니다.
| 데이터 | 소유 시스템 예시 | 다른 시스템 권한 | 충돌 처리 |
|---|---|---|---|
| 상품 기본 | PIM·ERP | 읽기·판매 속성 추가 | 소유자 변경만 승인 |
| 주문 | OMS·자사몰 | 이행 상태 갱신 | 원 주문 버전 대조 |
| 실물 재고 | WMS·ERP | 가용량 계산 | 사건 재생·실사 |
| 고객 동의 | CRM·자사몰 | 목적별 조회 | 철회가 우선 |
| 정산 | 정산 원장·ERP | 보고서 조회 | 조정 사건 생성 |
연동 계약에 성공뿐 아니라 실패 의미를 넣는다#
필드 이름 목록만으로는 운영할 수 없습니다. 요청 ID, 스키마 버전, 필수값, 단위·시간대, 상태 코드, 인증, 제한, 성공 확인, 오류 분류와 재시도 조건을 계약으로 관리하세요. 소비 시스템이 지원하지 않는 새 값이 들어왔을 때 버릴지 보류할지도 정해야 합니다.
| 계약 요소 | 질문 | 증거 | 변경 시 |
|---|---|---|---|
| 식별자 | 같은 사건을 어떻게 아나 | 요청·객체 ID | 매핑 버전 보존 |
| 스키마 | 필수·선택·단위는 무엇인가 | 명세·샘플 | 호환성 검사 |
| 상태 | 허용 전이는 무엇인가 | 전이표 | 미지원 값 보류 |
| 전달 | 성공을 어떻게 확인하나 | 응답·소비 기록 | 재시도 정책 |
| 보안 | 누가 어떤 필드를 보내나 | 권한·비밀 관리 | 키 회전·회수 |
실무 시나리오: 주문 저장 뒤 이벤트 발행이 실패한다#
OMS에는 주문이 저장됐지만 WMS 전송 직전에 프로세스가 중단됐다고 가정하겠습니다. 단순 재시도는 중복 출고를 만들 수 있습니다. 주문 저장과 발행할 사건을 같은 트랜잭션의 outbox에 남기고, 발행자는 미전송 사건을 다시 보내며 WMS는 사건 ID로 중복을 건너뜁니다.
| 실패 | 탐지 | 자동 복구 | 사람의 조치 |
|---|---|---|---|
| 발행 누락 | 미전송 outbox | 다시 발행 | 장기 지연 조사 |
| 중복 전달 | 처리된 사건 ID | 결과 재사용 | 중복 영향 대조 |
| 순서 역전 | 객체 버전·순번 | 대기·재정렬 | 상태 충돌 승인 |
| 스키마 오류 | 검증 실패 큐 | 자동 재시도 금지 | 매핑 수정·재처리 |
| 대상 장애 | 타임아웃·회로 차단 | 간격 재시도 | 수동 업무 전환 |
outbox와 멱등성은 이중 쓰기 실패를 다루는 패턴이다#
AWS Prescriptive Guidance의 Transactional outbox pattern은 데이터베이스 변경과 메시지 발행 중 하나만 성공하는 이중 쓰기 문제, 중복 전달과 순서 고려를 설명합니다. 특정 AWS 서비스를 반드시 써야 한다는 뜻은 아니며, 저장·발행·소비 증거와 멱등 처리가 필요한 이유를 보여 주는 공식 기술 근거입니다.
기존 ERP를 유지하고 업무 모듈만 추가할 때 네 가지 경계를 정합니다#
회계·구매·판매가 이미 운영 중이라면 모든 화면을 새로 만들기보다 부족한 업무를 분리하는 방식을 먼저 비교할 수 있습니다. 예를 들어 별도 모듈에서 요청·검토·승인을 처리하고 확정된 결과만 기존 시스템에 전달하는 구조입니다. 다만 기존 제품이 해당 접근과 연동을 허용하는지, 필요한 데이터와 상태를 실제로 읽거나 전달할 수 있는지는 제품·계약별로 확인해야 합니다. 특정 ERP와의 호환을 확인 전에 약속하지 않습니다.
| 경계 | 계약 전에 정할 내용 | 검수 증거 | 보류 조건 |
|---|---|---|---|
| 기준 원장 | 기준정보·재고·회계의 수정 책임 | 필드별 소유권과 코드 매핑 | 양쪽이 같은 값을 임의 수정 |
| 업무 승인 | 요청·확정·취소와 전달 시점 | 승인 전후 상태·권한 시험 | 미승인 자료가 원장에 반영 |
| 전달 방식 | API·파일의 주기·완료 의미 | 요청·수신·반영 결과 대조 | 수신을 업무 성공으로 간주 |
| 운영 인수 | 실패 감지·재처리·수동 전환 담당 | 중복·누락·복구 시연 | 담당자만 아는 수기 수정 |
파일 연동은 파일이 존재한다는 사실만으로 완료를 판단하지 않습니다. 생성 중인 파일과 완성 파일을 구분하고 파일 ID·기준일·형식 버전·건수와 수신 이력을 남기세요. 행 일부가 실패하면 전체 파일을 다시 보내도 이미 승인된 거래가 중복되지 않아야 합니다. 재처리할 행과 업무 담당자가 수정할 행을 나누고, 원본·변환값·실패 사유를 비교할 수 있어야 합니다. 외부 시스템의 지원 조건에 맞춰 실제 전달 방식을 결정합니다.
대사는 성공 응답 건수뿐 아니라 원장에 반영된 수량·금액·상태까지 확인합니다. 기준 시각이 다른 자료끼리 합계를 비교하면 정상 지연도 오류처럼 보일 수 있으므로 대상 기간과 포함 상태를 고정하세요. 마감 이후 도착한 취소·정정 자료는 과거 값을 조용히 덮지 않고 원거래와 정정·재마감의 관계를 설명할 수 있어야 합니다. 합계를 맞추는 수동 수정에는 승인자와 사유를 남기고 다음 수집에서 다시 깨지지 않는지도 확인합니다.
구축 검수에는 기존 시스템이 중단되거나 자격증명이 만료되는 상황도 넣습니다. 새 모듈을 잠시 멈춰도 기존 업무를 계속할 수 있는지, 복구 뒤 수동 처리분을 중복 없이 반영하는지 확인하세요. 공급사 변경 통지와 계정 관리, 일일 실패 확인, 월마감 대사와 장애 연락의 책임자를 구분해야 합니다. 개발 납품과 지속 운영 지원은 같은 계약이 아닐 수 있으므로 운영 시간·대응 범위·변경 요청의 포함 여부를 별도로 합의합니다.
레거시는 가장 덜 침습적인 방식부터 연결한다#
API가 없으면 공급사 지원과 백업 조건을 확인한 뒤 읽기 전용 DB 뷰, 내보내기 파일, 정기 배치, 제한된 RPA 순으로 평가합니다. 운영 DB를 직접 쓰거나 화면을 무제한 자동화하면 업데이트와 감사에 취약해집니다. 통합 우선순위는 엑셀·시스템 전환 체크리스트, 도구 선택은 사내 시스템과 SaaS 비교에서 이어서 볼 수 있습니다.
재처리와 원장 대조를 운영자가 직접 수행한다#
정상 한 건뿐 아니라 중복, 순서 역전, 부분 실패, 잘못된 매핑, 권한 만료를 시험하세요. 운영자가 실패 큐에서 원문과 오류를 보고 수정·재처리하며, 대상 시스템의 결과 ID와 원장을 대조할 수 있어야 합니다. 재고 사건 설계는 재고 차이 시스템 점검과 함께 검토할 수 있습니다.
핵심 요약
- ✓사내 시스템 통합을 화면 통합이 아니라 객체·필드 소유권과 전달 계약의 문제로 정의한다
- ✓식별자·스키마·상태·성공 확인·오류 분류·보안 변경을 연동 계약에 넣는다
- ✓양방향 덮어쓰기보다 단방향 소유권과 명시적 명령을 기본으로 둔다
- ✓outbox·사건 ID·멱등 처리로 발행 누락과 중복 전달을 복구한다
- ✓레거시는 지원 범위 안의 덜 침습적인 방식부터 연결하고 운영자 재처리까지 인수한다
자주 묻는 질문