ARTICLE 03 · INTEGRATION · 2026-09-13

새 앱을 ERP, 회계 시스템, 기존 데이터와 연동하기: 바이브 코딩이 가장 덜 도움이 되는 작업

새 화면은 며칠이면 만들 수 있습니다. 진짜 위험은 회사의 돈과 재고를 다루는 시스템과 맞닿는 지점에 있습니다. 두 번 들어온 주문, 월말에 맞지 않는 합계, 앱에는 있다고 나오는데 창고에는 없는 재고 같은 것들입니다. 이 글은 시스템을 연동하기 전에 답해야 할 네 가지 질문과, 매일 숫자를 대조할 수 있게 설계하는 방법을 설명합니다.

새 앱을 ERP, 회계 시스템, 기존 데이터와 연동하기: 바이브 코딩이 가장 덜 도움이 되는 작업
핵심 요약
  • 회계 시스템, 재고 시스템과 연결되지 않은 새 앱을 쓰면 직원이 같은 데이터를 두 곳에 입력해야 하고, 양쪽 숫자가 조금씩 어긋나기 시작합니다.
  • 연동하기 전에 데이터마다 어느 시스템을 기준으로 삼을지, 전송이 실패하면 어떻게 할지 먼저 합의해야 합니다.
  • 연동 모듈을 만들기 전에 두 시스템의 숫자를 대조하는 보고서부터 완성하십시오. 결산일까지 기다리지 않고 하루 안에 문제를 알 수 있습니다.

문제는 대부분 시스템 사이의 이음매에서 생깁니다

영업 사원이 새 앱으로 주문을 받고, 회계팀이 같은 주문서를 회계 프로그램에 다시 입력하는 모습은 흔합니다. 그러면 회사에는 서로 같아야 하는데 같게 만드는 장치는 없는 숫자가 두 벌 생깁니다. 누군가 다시 입력할 때마다 두 숫자가 조금 더 벌어질 여지가 생깁니다.

증상은 대개 천천히 드러납니다. 바쁜 날 주문서 한 장이 빠집니다. 누군가 ERP에서만 가격을 고치는 바람에 앱에는 아직 지난달 가격이 남아 있습니다. 앱이 보여 주는 재고는 실제 창고보다 반나절 늦습니다. 월말이 되면 회계팀은 차이가 어느 문서에서 나왔는지 찾느라 며칠을 씁니다.

두 시스템의 합계는 같아야 하고, 맞지 않는 항목은 원인을 찾아야 할 대상입니다.
두 시스템의 합계는 같아야 하고, 맞지 않는 항목은 원인을 찾아야 할 대상입니다.

이 부분은 바이브 코딩이 별로 도움이 되지 않는 일입니다. API 문서가 잘 갖춰져 있으면 AI는 API를 호출하는 코드를 아주 빨리 씁니다. 그런데 시스템 연동에 필요한 지식은 대부분 문서로 적힌 적이 없습니다. 영업팀과 창고는 서로 다른 상품 코드 체계를 씁니다. 고객 한 곳에 코드가 세 개 붙어 있는데, 예전에 세 지점에서 계산서를 발행했기 때문입니다. 회계팀은 10년 동안 비고란에 고객의 구매 주문 번호를 적어 왔습니다. 이런 내용은 일하는 사람의 머릿속과 오래된 데이터 안에 있어서, 누군가 직접 앉아 묻고 데이터를 열어 봐야 합니다.

연동 모듈을 만들기 전에 답해야 할 네 가지 질문

시스템 연동은 두 부서가 장부 한 권을 같이 쓰게 하는 일과 비슷합니다. 시작하기 전에 누가 쓰고, 누가 읽기만 하고, 언제 쓰고, 잘못 쓰면 누가 고칠지 정해야 합니다. 이 네 가지 질문에는 현업 부서가 답해야 하며, 기술팀이 대신 답할 수 없습니다.

데이터마다 어느 시스템을 기준으로 삼을까

데이터 종류마다 기준이 되는 시스템을 하나만 두어야 합니다. 그 시스템에 있는 값을 기준 원본 데이터(Source of Truth)라고 합니다. 예를 들어 판매 가격은 ERP, 재고 수량은 창고 시스템, 고객 연락처는 앱을 기준으로 삼습니다. 다른 시스템은 읽어 가서 쓸 수는 있어도 고쳐서는 안 됩니다. 두 곳에서 고칠 수 있게 두면 어느 숫자가 맞는지 아무도 답하지 못합니다.

언제, 어느 방향으로 보낼까

어떤 데이터는 거의 즉시 도착해야 합니다. 잘 팔리는 상품의 재고가 그렇습니다. 장부에 반영하는 매출처럼 밤에 한 번 몰아서 보내도 되는 데이터도 있습니다. 자주 보낼수록 시스템은 복잡해지고 비용도 올라가므로, 전송 주기는 데이터가 늦었을 때 생기는 손해를 기준으로 정해야 합니다.

전송이 실패하면 어떻게 될까

전송 도중에 네트워크가 끊기는 일은 흔합니다. 그래서 보내는 쪽 시스템은 다시 보낼 수 있어야 하고, 다시 보내더라도 문서가 두 번 만들어지면 안 됩니다. 이런 성질을 멱등성(Idempotency)이라고 합니다. 여러 번 보내도 실패한 항목은 사람이 볼 수 있는 곳에 모여 있어야 하고, 처리할 담당자의 이름이 정해져 있어야 합니다.

누가 언제 숫자를 대조할까

오늘 제대로 돌아가는 연동 모듈도 누군가 새로운 할인 유형을 추가한 날에는 틀릴 수 있습니다. 그래서 두 시스템의 숫자를 매일 맞춰 보는 대사(Reconciliation)는 시스템의 일부이고, 운영을 시작한 첫날부터 있어야 합니다.

연동 방식적합한 경우주의할 점
대상 시스템의 API 호출시스템에 API가 있고 공급업체가 사용을 지원합니다.하루 호출 횟수에 한도가 있고, API 모듈에 라이선스 비용이 붙습니다.
정해진 주기의 파일 가져오기·내보내기기존 시스템에 API는 없지만 파일을 가져올 수 있습니다.데이터가 전송 주기만큼 늦고, 가져오기에 실패한 파일을 처리할 방법이 있어야 합니다.
기존 시스템의 데이터베이스 직접 읽기다른 방법이 없고 시스템 공급업체가 동의합니다.직접 쓰기는 데이터를 망가뜨릴 위험이 있고 서비스 이용 조건을 어길 수도 있으므로, 읽기로만 제한해야 합니다.
프로그램이 사람 대신 화면을 클릭하게 하기모든 연결 경로가 막혀 있고 처리량이 적습니다.기존 시스템의 화면이 바뀌면 작동을 멈춥니다.
개발팀 참고 · 기술 세부 사항

문서마다 Idempotency Key를 사용하고, Outbox와 Message Queue를 거쳐 전송합니다. Backoff 방식의 Retry와, 사람이 처리할 수 있는 화면을 갖춘 Dead-letter Queue를 둡니다. 상품 코드와 고객 코드의 매핑 테이블은 중간 계층에 보관합니다. 입력 데이터의 Schema를 검증하고, 큐의 지연 시간과 오류율을 모니터링하며, 공급업체 API에 대한 Contract Test로 변경 사항을 Production에 닿기 전에 잡아냅니다.

시멘트가 두 번 배송된 건자재 유통업체

한 건자재 유통업체가 거래처 매장이 직접 주문할 수 있는 앱을 만들었습니다. 앱은 API로 주문을 ERP에 보냈습니다. 비가 많이 오던 날, 창고의 인터넷이 끊겼다 이어지기를 반복했습니다. 앱은 주문을 보낸 뒤 응답을 기다리다 시간이 초과되자, 설정된 대로 주문을 다시 보냈습니다. ERP는 같은 주문을 두 번 받아 출고 지시서를 두 장 발행했고, 시멘트 트럭이 같은 매장에 두 번 찾아갔습니다. 회사는 매장 주인이 전화로 두 번째 배송을 거절하고 나서야 이 사실을 알았습니다.

네트워크가 끊긴 사이 다시 전송된 주문 한 건이 시멘트 배송 두 번이 되었습니다.
네트워크가 끊긴 사이 다시 전송된 주문 한 건이 시멘트 배송 두 번이 되었습니다.

팀은 두 군데를 고쳤습니다. 먼저 앱이 주문을 다시 보낼 때마다 처음의 참조 코드를 붙이고, 받는 쪽은 문서를 만들기 전에 이 코드를 확인하게 했습니다. 다음으로 매일 아침 대사 보고서를 돌려 전날의 주문 건수와 금액을 앱과 ERP 사이에서 비교하게 했습니다. 이 보고서는 바로 다음 주에 다른 종류의 문제를 잡아냈습니다. 앱에서는 취소되었는데 ERP에는 여전히 남아 있는 주문이었고, 그런 일이 있는 줄은 아무도 몰랐습니다.

연동하기 전에 숫자부터 대조하기

  1. 시스템 사이를 오갈 문서 한 종류를 고릅니다. 판매 주문서를 예로 들 수 있습니다.
  2. 양쪽이 매일 일치해야 할 숫자를 정합니다. 문서 건수, 총금액, 상품 코드별 수량 등입니다.
  3. 두 시스템의 숫자를 끌어와 나란히 놓는 보고서를 만들고, 지난달 수기 입력 데이터로 시험해 봅니다.
  4. 보고서가 잡아낸 차이를 하나씩 읽습니다. 차이 하나하나가 연동 모듈이 처리해야 할 규칙입니다.
  5. 연동 모듈을 가동하면 보고서를 매일 아침 돌리고, 그날 안에 차이를 해소할 담당자의 이름을 정합니다.

남겨 둘 근거는 하루 차이 건수와 항목마다 해소하는 데 걸린 시간입니다. 두 시스템이 같은 단어를 다르게 정의하면 이 방법은 막힙니다. 한쪽 매출은 세금을 포함하고 다른 쪽은 포함하지 않는 경우가 그렇습니다. 그럴 때는 회계팀이 정의부터 확정해야 합니다.

기존 데이터 이관은 대개 가장 과소평가됩니다

새 시스템이 기존 시스템의 고객 데이터, 상품, 미결제 잔액을 가지고 시작해야 한다면, 데이터를 옮기는 일은 누구의 예상보다 오래 걸립니다. 오래된 데이터에는 중복 항목과 빈칸이 있고, 입력하던 사람이 바뀔 때마다 형식도 달라졌기 때문입니다.

안전한 작업 순서는 네 단계입니다. 첫 단계는 데이터 정제로, 중복 항목을 합치고 꼭 필요한 칸을 채웁니다. 두 번째 단계에서는 기존 시스템의 어느 칸이 새 시스템의 어느 칸으로 가는지 대응표를 작성합니다. 이것을 데이터 매핑(Data Mapping)이라고 합니다. 세 번째 단계에서는 시험 이관을 하고 데이터 책임자에게 샘플을 확인하게 합니다. 마지막 단계에서는 새 시스템으로 운영 전환(컷오버)하기 전에 두 시스템을 일정 기간 병행 운영하고, 전환일에 문제가 생길 때를 대비해 되돌리는 계획을 세워 둡니다.

기존 데이터는 정제하고, 중복을 합치고, 제자리를 찾아 정리한 뒤에 새 시스템에 넣어야 합니다.
기존 데이터는 정제하고, 중복을 합치고, 제자리를 찾아 정리한 뒤에 새 시스템에 넣어야 합니다.

다음 중 하나라도 해당하면 아직 연동에 투자하지 마십시오

  • 문서량이 적어서 일주일에 한 번 수기로 입력하는 편이 연동 모듈을 만들고 유지하는 비용보다 쌉니다.
  • 대상 시스템을 1년 안에 교체할 예정입니다.
  • 두 시스템의 값이 엇갈릴 때 판단을 내릴 데이터 책임자가 아직 없습니다.
  • 기존 시스템 공급업체가 연동을 허용하지 않거나 지원하지 않습니다.

성과는 회계팀과 운영팀이 체감할 수 있는 숫자로 재십시오. 사라진 이중 입력 시간, 하루 차이 건수, 차이를 해소하는 데 걸린 시간, 월말 결산에 걸리는 일수입니다. 병행 운영을 2주 꽉 채웠는데도 차이가 줄지 않으면 운영 전환일을 미루고, 아직 처리하지 못한 규칙이 무엇인지 다시 살펴보십시오.

DNA MAKER · SYSTEM INTEGRATION

새 앱과 기존 시스템이 같은 숫자를 보고하도록 만듭니다

계정과목표와 분개 규칙은 회계팀의 것이고, 상품 코드와 재고를 세는 방식은 창고팀의 것입니다. ERP 공급업체는 자기 시스템의 한계를 압니다. DNA Maker는 이 세 그룹과 함께 문서 한 장을 처음부터 끝까지 따라가 본 뒤, 시스템 사이의 연결 지점을 지도로 정리합니다. 어느 칸이 어느 칸으로 가는지, 데이터 종류마다 어느 시스템이 기준인지, 한 번에 얼마나 보내는지, 전송이 실패하면 누가 무엇을 해야 하는지가 이 지도에 담깁니다.

저희는 이 지도를 바탕으로 큐, 문서를 중복 생성하지 않는 재전송, 코드 매핑 테이블, 일일 대사 보고서를 갖춘 연동 계층을 만들고, 회계팀이 걸려 있는 항목을 볼 수 있는 대시보드도 함께 제공합니다. 작업은 문서 한 종류에서 시작해, 차이가 계속 0으로 유지될 때까지 수기 입력과 병행 운영합니다. 그다음에 새 시스템으로 운영 전환하고 다음 문서 종류로 넓혀 갑니다. 팀이 가장 자주 이중으로 입력하는 문서가 있다면, 두 시스템에 있는 그 문서의 샘플 10건을 가지고 저희와 이야기해 보십시오.

소프트웨어 엔지니어링 용어집

연동 계획을 세울 때 개발팀, 기존 시스템 공급업체와 이야기하면서 쓰는 용어입니다. 오른쪽 열의 질문을 보면 단계마다 누가 책임지는지 드러납니다.

용어의미쉬운 예시개발팀에 물어봐야 할 질문
Reconciliation두 시스템의 숫자가 일치하는지 비교하고, 맞지 않는 항목의 원인을 찾는 작업매일 아침 보고서가 전날 주문 건수와 금액을 앱과 ERP 사이에서 비교합니다.차이는 누가 해소하고, 몇 시간 안에 해소해야 합니까?
Data Migration정제와 이관 후 검증까지 포함해, 기존 시스템의 데이터를 새 시스템으로 옮기는 작업중복된 고객을 합친 뒤 고객 8,000곳의 명단을 새 시스템으로 옮깁니다.이관 후 데이터가 빠짐없이 옮겨졌고 미결제 잔액이 기존 시스템과 일치하는지 어떻게 확인합니까?
Data Mapping한 시스템의 어느 데이터 칸이 다른 시스템의 어느 칸에 해당하는지 정리한 표영업팀의 상품 코드를 창고의 상품 코드와 하나씩 짝지어 둡니다.이 표의 책임자는 누구이고, 신상품이 생기면 누가 추가합니까?
Middleware한 시스템에서 데이터를 받아 형식을 바꾼 뒤 다른 시스템으로 넘겨주는 중간 소프트웨어미들웨어가 앱에서 주문을 받아 상품 코드를 변환한 뒤 ERP로 보냅니다.미들웨어가 멈추면 처리 대기 중인 항목은 어디로 가고, 누가 알림을 받습니까?
Message Queue받는 쪽 시스템이 잠시 멈춰도 데이터를 잃지 않도록, 전송할 항목을 줄 세워 보관하는 두 시스템 사이의 대기 공간ERP가 점검으로 한 시간 멈춘 동안 주문이 큐에서 기다리다가, 시스템이 돌아오자 차례로 들어갑니다.큐가 얼마나 길어지면 업무에 지장이 생기고, 그 사실을 무엇으로 알 수 있습니까?
Parallel Run기존 시스템을 끄기 전에 결과를 비교하려고, 일정 기간 기존 시스템과 새 시스템을 함께 쓰는 방식연동 모듈이 돌아가는 동안 회계팀이 2주 더 수기 입력을 계속하고, 매일 합계를 비교합니다.병행 운영을 끝내도 된다는 기준은 무엇이고, 누가 결정합니까?
Cutover기존 시스템에서 새 시스템으로 실제로 갈아타는 시점토요일 밤 두 시간 동안 주문 접수를 멈추고 미결제 잔액을 옮긴 뒤, 일요일 아침에 새 시스템을 엽니다.전환하는 밤에 문제가 생기면 몇 시까지 되돌릴 수 있고, 누가 지시합니까?
내일 해 볼 일: 영업팀과 회계팀에 각자의 시스템에서 어제 판매 주문서가 몇 건인지 세어 보게 하고, 두 숫자를 비교하십시오. 맞지 않으면 빠진 주문서 한 건을 골라 원인을 찾을 때까지 추적하십시오. 그 원인이 연동 모듈이 처리해야 할 첫 번째 규칙입니다.