ERP 연동 개발 2026 — 이카운트·더존·SAP API 5단계 비용표

ERP 연동 개발은 새 시스템을 만드는 일이 아니다. 이미 회사가 쓰고 있는 회계·재무 시스템에 데이터를 넣거나 빼는 통로를 뚫는 일이다. 만드는 대상이 남의 시스템이라는 점 하나 때문에, 견적도 기간도 일반 개발과 전혀 다르게 움직인다. 업체 세 곳에서 400만 원, 1,800만 원, 4,000만 원짜리 견적이 나란히 오는 이유가 여기에 있다. 세 업체가 서로 다른 통로를 상상하고 있는 것이다.

이 글은 발주처가 착수 전에 반드시 판단해야 하는 것만 다룬다. 요구사항 정의서나 화면설계서를 쓰는 법은 요구사항 정의서 작성법에서 이미 다뤘으니 반복하지 않는다. 여기서는 ERP에 API가 있느냐 없느냐, 그리고 없을 때 무엇을 대가로 치르느냐에 집중한다.

ERP 연동 개발이 실제로 붙이는 것은 무엇인가

발주처는 보통 "ERP랑 연동해 주세요"라고 말한다. 이 문장은 견적이 불가능하다. 연동의 단위는 시스템이 아니라 인터페이스이기 때문이다.

인터페이스 1건 = 「하나의 데이터 종류」 × 「하나의 방향」이다. 거래처 마스터를 ERP에서 새 시스템으로 내려받는 것이 1건, 새 시스템에서 만든 주문을 ERP 전표로 밀어넣는 것이 또 1건이다. 같은 거래처 데이터라도 양방향이면 2건이고, 양방향은 단순히 2배가 아니라 충돌 처리 로직이 얹히므로 3배에 가깝다.

실제 프로젝트에서 자주 나오는 인터페이스 목록은 이 정도다.

• 거래처(고객·공급처) 마스터 — 대부분 ERP → 신규 시스템 단방향
• 품목·단가 마스터 — ERP → 신규 시스템
• 주문·수주 — 신규 시스템 → ERP
• 매출 전표·세금계산서 — 신규 시스템 → ERP, 또는 팝빌·바로빌 경유
• 재고 수불 — 방향을 반드시 하나로 못 박아야 하는 지점
• 입출금·수금 대사 — 은행 데이터가 끼면 난이도가 한 단계 올라간다

⚠️ "전체 연동"이라는 말로 견적을 받으면 100% 분쟁이 난다. 계약서에 인터페이스를 번호 매겨 나열하고, 추가 1건당 단가를 미리 적어라. 이 한 줄이 없어서 오픈 직전에 "재고도 당연히 포함인 줄 알았다"로 2주가 날아가는 프로젝트를 매년 본다.

우리 ERP에 표준 API가 있는지부터 확인한다

국내에서 마주치는 ERP는 인터페이스 성숙도가 극과 극이다. 같은 "ERP 연동"이라도 아래 표에서 어느 칸에 있느냐가 비용의 80%를 결정한다.

확인 방법은 간단하다. ERP 벤더 담당자에게 이메일로 세 가지를 물어라. ① 외부 시스템 연동용 API 문서를 받을 수 있는가 ② API 사용에 별도 라이선스·모듈 구매가 필요한가 ③ 우리가 쓰는 버전에서 그 API가 지원되는가. 세 번째가 핵심이다. 문서는 최신 버전 기준으로 쓰여 있고, 회사가 쓰는 건 4년 전 버전인 경우가 흔하다.

⚠️ 영업 담당자의 "연동 됩니다"는 근거가 아니다. 문서 PDF와 샘플 응답(JSON/XML)을 받아라. 받지 못하면 그 ERP는 「API 없음」으로 간주하고 견적을 짜는 편이 안전하다. 착수 후에 없다는 걸 알면 아키텍처를 통째로 다시 잡아야 한다.

표준 API가 있을 때 — 5단계와 실제 소요

API가 있으면 연동은 예측 가능한 작업이 된다. 순서는 아래 5단계로 고정된다.

1단계 — 계정·권한 발급(3~7일). API 키, 테스트 존, IP 허용 목록을 받는다. 발주처가 벤더에 요청해야 하는 구간이라 개발사가 손을 못 댄다. 여기가 막히면 전체 일정이 그대로 밀린다.

2단계 — 필드 매핑(1~2주). ERP의 거래처 코드가 신규 시스템의 무엇에 대응하는지 1:1로 적는다. 이 문서가 프로젝트에서 가장 오래 살아남는 산출물이다. 형식은 테이블 정의서·ERD 작성법의 인터페이스 정의서 양식을 그대로 쓰면 된다.

3단계 — 단건 왕복 검증(3~5일). 실제로 1건을 넣고, 조회하고, 취소해 본다. 이 단계에서 문서에 없던 필수 필드가 반드시 하나 이상 튀어나온다.

4단계 — 오류·재처리 설계(1~2주). 실패한 건을 어디에 쌓고 누가 어떻게 다시 보내는지 정한다. 뒤에서 따로 다룬다.

5단계 — 대량·마감 테스트(1주). 월말 마감 시점의 부하와 마감 후 전표 반려를 재현한다.

⚠️ 호출 한도를 계산하지 않고 설계하면 오픈 첫 달에 멈춘다. 이카운트처럼 일일 호출 한도가 있는 API에서 "주문 1건당 5회 호출" 구조를 짜면, 일 300건 회사에서 1,500회가 나간다. 건당 호출 수를 설계 문서에 숫자로 적게 하라.

표준 API가 없을 때 — 4가지 우회로

API가 없다고 연동이 불가능한 건 아니다. 다만 넷 중 하나를 고르고 각각의 대가를 받아들여야 한다.

① 파일 배치(CSV·엑셀·고정길이). ERP가 제공하는 전표 업로드 양식에 맞춰 파일을 만들어 FTP나 공유 폴더에 떨군다. 국내 중견기업 연동의 절반 이상이 실제로는 이 방식이다. 싸고 안정적이지만 실시간이 아니고, 업로드 실패를 사람이 눈으로 확인해야 하는 경우가 많다.

② 중계 DB(스테이징 테이블). ERP 벤더가 "여기에 넣으면 우리가 가져간다"는 전용 테이블을 열어 준다. 파일보다 빠르고 이력 추적이 쉽다. 벤더가 협조적일 때 최선의 선택이다.

③ ERP DB 직접 접근. 뒤에서 절을 따로 할애한다. 가장 흔하고 가장 위험하다.

④ 화면 자동화(RPA). 사람이 ERP 화면에 입력하는 동작을 그대로 흉내 낸다. 착수는 빠르지만 ERP가 화면을 한 번 개편하면 전부 깨진다. 임시 우회로로만 쓴다.

⚠️ RPA를 정식 연동으로 계약하지 마라. 초기 견적이 300만 원대라 매력적으로 보이지만, ERP 정기 업데이트마다 수정비가 나가 2년이면 API 연동보다 비싸진다. RPA는 "6개월 뒤 정식 연동으로 교체한다"는 종료 조건을 계약서에 넣고 쓰는 도구다.

ERP DB에 직접 붙는 것이 위험한 이유

가장 많이 벌어지는 선택이고, 가장 많이 사고가 나는 선택이다. 위험은 다섯 가지다.

스키마가 계약 대상이 아니다. 벤더는 화면과 기능을 보장할 뿐 테이블 구조를 보장하지 않는다. 정기 패치에서 컬럼 하나가 바뀌면 연동은 통보 없이 조용히 깨진다. 더 나쁜 건 에러가 아니라 잘못된 값이 들어가는 방식으로 깨지는 경우다.

유지보수 계약이 깨진다. 다수의 ERP 유지보수 계약서에는 "제3자가 DB를 직접 변경한 경우 지원 대상에서 제외"라는 조항이 있다. 사고가 났을 때 벤더가 손을 떼면 발주처가 전부 뒤집어쓴다.

애플리케이션 검증을 통째로 건너뛴다. 전표는 차변·대변이 맞아야 하고, 재고는 수불 이력과 잔량이 일치해야 하며, 마감된 기간에는 쓰기가 막혀야 한다. 이 규칙들은 대부분 DB가 아니라 ERP 프로그램 안에 있다. INSERT로 우회하면 회계상 성립하지 않는 데이터가 쌓인다.

성능이 남의 마감을 잡아먹는다. 월말에 대량 SELECT를 돌리면 ERP 트랜잭션이 락에 걸린다. 경리팀이 "ERP가 느려졌다"고 하면 원인 지목이 우리 쪽으로 온다.

감사 추적이 사라진다. 회계감사에서 "이 전표는 누가 입력했나"를 물었을 때 답할 수 없다.

그래도 직접 접근이 유일한 답인 경우가 있다. 자체 구축 ERP라 벤더가 없거나, 조회만 필요한 경우다. 이때는 최소한 이 세 가지를 지켜라. 읽기 전용 계정을 쓰고(쓰기 권한을 아예 부여하지 않는다), 복제본(리플리카)을 조회하고, 뷰(View)를 사이에 둔다. 뷰를 두면 원본 테이블이 바뀌어도 뷰만 고쳐서 흡수할 수 있다.

⚠️ 쓰기를 DB로 하는 순간 되돌릴 수 없다. 잘못 들어간 전표 3,000건을 회계 마감 후에 발견하면, 정정 분개를 사람이 손으로 치는 것 말고 방법이 없다. 읽기는 타협하되 쓰기는 반드시 ERP가 제공하는 정식 통로로 하라.

연동 방향과 데이터 주인을 먼저 못 박는다

기술 선택보다 앞서는 결정이 이것이다. 데이터마다 주인(원본을 보유하는 시스템)을 하나만 정한다. 주인이 둘이면 반드시 충돌한다.

가장 흔한 실수는 재고를 양방향으로 잡는 것이다. 창고 시스템과 ERP가 서로 재고를 밀어 주면, 어느 쪽 숫자가 맞는지 아무도 답할 수 없는 상태가 3개월 안에 온다. 재고는 "ERP가 주인이고 창고 시스템은 수불 이벤트만 올린다" 또는 그 반대로 반드시 하나를 정한다.

⚠️ "일단 양방향으로 열어 두고 나중에 정리하자"는 절대 정리되지 않는다. 양방향 동기화는 개발비가 1.5배가 아니라 필드별 소유권·최종수정시각 비교·충돌 큐까지 붙어 2.5배가 된다. 착수 회의에서 위 표를 채우지 못하면 착수하지 마라.

유형별 비용·기간

아래는 인터페이스 3건(마스터 수신 1 + 전표 송신 1 + 상태 회신 1) 기준의 국내 시세다. 인터페이스가 1건 늘 때마다 250만~600만 원을 더한다.

SAP ECC 구간이 비싼 이유는 개발사가 못 하는 일이 섞여 있어서다. 커스텀 RFC를 새로 만들어야 하면 ABAP 개발자와 이관 절차가 필요한데, 이건 대개 SAP 파트너사 별도 계약이며 1,000만 원 안팎이 추가된다. 이 금액을 개발사 견적에 포함시키라고 요구하면 견적이 부풀거나, 나중에 "우리 범위 아니다"로 돌아온다. 처음부터 두 계약으로 분리하는 편이 총액이 싸다.

⚠️ 운영비 0원 견적은 견적이 아니다. 연동은 만들고 끝나는 물건이 아니라 ERP가 살아 있는 동안 계속 돌아가는 설비다. 인증 만료, 스키마 변경, 마감 실패 재처리가 매달 생긴다. 유지보수를 개발비의 연 10~15%로 잡고 계약에 명시하라.

착수 전 발주처가 확정해야 할 항목

아래 항목이 비어 있으면 개발사는 추정으로 견적을 낸다. 추정 견적은 반드시 변경 청구로 돌아온다.

실시간이냐 배치냐는 특히 발주처가 직접 판단해야 한다. 기준은 하나다. 그 데이터를 몇 분 늦게 봐도 업무가 굴러가는가. 전표는 대부분 하루 한 번이면 충분하고, 재고는 실시간이 필요한 경우가 많다. 전부 실시간으로 요구하면 개발비가 1.5~2배가 된다.

전체 시스템 관점의 배치는 시스템 구성도 작성법에서 다룬 방식으로 한 장에 그려 두면, 업체 비교가 훨씬 쉬워진다.

⚠️ 테스트 환경 없이 시작하면 반드시 운영 데이터를 건드린다. ERP 테스트 계정 발급은 벤더에 따라 유상이고 2~3주가 걸린다. 착수 전에 요청해 두지 않으면, 개발사는 "일단 운영에서 조심해서 하겠다"고 말하게 된다. 그 말이 나오는 순간이 사고 직전이다.

흔한 실패 5가지

① 중복 전표. 네트워크가 끊겨 응답을 못 받았을 뿐인데 재전송해서 같은 전표가 두 번 들어간다. ERP는 대부분 중복을 막아 주지 않는다. 신규 시스템이 「우리 주문번호 ↔ ERP 전표번호」 매핑 테이블을 직접 들고, 보내기 전에 이미 보낸 건인지 확인해야 한다. 이 로직이 없는 견적은 다시 받아라.

② 마감 후 전표 반려. 회계 마감이 끝난 기간으로 전표를 밀면 ERP가 거부한다. 이때 실패 건을 버리면 매출이 사라진다. 실패 큐에 쌓고, 다음 기간으로 날짜를 바꿔 재전송할지 사람이 결정하는 화면이 필요하다.

③ 코드 체계 불일치. ERP 거래처 코드는 8자리인데 신규 시스템은 UUID를 쓴다. 매핑 테이블을 안 만들고 이름으로 매칭하면 "(주)한성물산"과 "주식회사 한성물산"이 다른 회사가 된다. 개업 초기 500건은 넘어가지만 5,000건이 되면 수습이 불가능하다.

④ 인코딩·특수문자. 국내 ERP 상당수가 EUC-KR 기반이다. 이모지나 일부 한자가 들어간 거래처명이 물음표로 깨져 들어가고, 그 상태로 세금계산서가 발행된다.

⑤ 소수점·단위 불일치. 부가세 계산 자리올림 규칙이 두 시스템에서 다르면 건당 1원씩 어긋나고, 월말 대사에서 수백 건의 불일치로 나타난다. 금액 필드는 반드시 정수(원 단위)로 주고받고, 반올림 주체를 한쪽으로 정하라.

⚠️ 위 다섯 가지는 전부 「테스트에서는 안 나오고 운영에서만 나오는」 종류다. 검수 조건에 "운영 데이터 1개월치를 테스트 환경에 복제해 전량 재처리했을 때 불일치 0건"을 넣어라. 이 한 줄이 오픈 후 3개월치 야근을 막는다.

AI-Native 팀이 ERP 연동을 다루는 방식

ERP 연동에서 시간을 가장 많이 잡아먹는 건 코딩이 아니라 해독이다. 문서 없는 자체 ERP의 테이블 300개를 읽고 어느 게 전표 헤더인지 찾는 작업, 벤더가 준 200쪽짜리 인터페이스 명세에서 우리가 쓸 12개 필드를 추리는 작업이 초기 2~4주를 잡아먹는다.

나무숲(TreeSoop)은 팀원 전원이 Claude Code Max를 기본 개발 환경으로 쓴다. 이 구간에서 실제로 달라지는 건 세 가지다. 첫째, 스키마 덤프와 명세 PDF를 통째로 읽혀 후보 테이블·필드를 좁히는 데 걸리는 시간이 며칠에서 반나절로 줄어든다. 둘째, 필드 매핑표에서 양쪽 코드를 생성하므로 매핑표와 코드가 어긋나지 않는다 — 사람이 손으로 옮겨 적을 때 가장 자주 나던 오류가 이 지점이었다. 셋째, 중복 방지·재처리·마감 예외 같은 「운영에서만 터지는」 케이스를 착수 시점에 테스트로 먼저 고정해 둔다.

다만 분명히 해 둘 것이 있다. AI가 줄여 주는 건 해독과 반복 작업이지 검증이 아니다. 실제 ERP에 1건을 넣고 회계 담당자가 화면에서 확인하는 절차는 그대로 남는다. 이 구간을 건너뛰겠다는 업체는 ERP 연동을 해 본 적이 없는 업체다. 접근 방식은 AI-Native 개발 방식에 정리해 두었다.

사내 시스템 전체를 새로 만들면서 ERP에 붙이는 경우라면, 범위를 어디까지 잡을지가 먼저다. 신규 시스템이 스스로 들고 갈 데이터와 ERP에 넘길 데이터를 초기에 갈라 두면, 연동 인터페이스 개수 자체가 절반으로 줄어드는 경우가 많다. 연동 건수는 견적의 단위이므로, 범위 축소가 곧 비용 축소다.

⚠️ 연동만 따로 발주하면 책임 경계가 생긴다. 신규 시스템 개발사와 연동 개발사가 다르면, 데이터가 안 맞을 때 서로를 가리킨다. 가능하면 한 계약으로 묶고, 어려우면 "불일치 발생 시 1차 원인 규명 책임은 누구"를 계약서에 적어라.

자주 묻는 질문

Q. 우리 ERP에 API가 있는지 비개발자가 확인할 방법이 있나?

벤더 담당자에게 「외부 연동용 API 규격서」를 문서로 요청하면 된다. 30분 안에 PDF가 오면 있는 것이고, "협의가 필요하다"는 답이 오면 유상 개발이거나 없는 것이다. 이카운트는 관리자 화면에서 API 인증키 발급 메뉴 존재 여부로 바로 확인된다.

Q. ERP 벤더에 직접 연동 개발을 맡기는 게 낫지 않나?

ERP 쪽 작업만 놓고 보면 안전하다. 벤더는 자기 스키마를 알고 유지보수 책임도 진다. 다만 신규 시스템 쪽 요구는 잘 반영되지 않고, 단가가 일반 개발사보다 1.5~2배 높으며, 일정이 벤더 릴리스 주기에 묶인다. 현실적인 조합은 ERP 쪽 인터페이스는 벤더, 신규 시스템 쪽과 중계 로직은 개발사로 나누고 규격서를 접점으로 삼는 것이다.

Q. 전부 실시간으로 하면 안 되나?

되지만 비싸고 취약해진다. 실시간은 ERP가 잠깐 멈춰도 우리 쪽이 같이 멈추지 않도록 큐와 재시도를 붙여야 하고, 그 설계가 개발비의 30~50%다. 하루 1회 배치로 충분한 데이터를 실시간으로 요구하고 있지 않은지 항목별로 다시 보라.

Q. 1~2년 안에 ERP를 교체할 계획인데 지금 연동해도 되나?

연동 로직을 신규 시스템 안에 직접 박지 말고 어댑터 한 겹을 두라고 요구하면 된다. ERP가 바뀔 때 어댑터만 다시 만들면 되므로 재개발 범위가 30~40% 수준으로 줄어든다. 추가 비용은 보통 10~15%다. 교체 계획이 있다면 반드시 요구하라.

Q. 연동 견적서에서 반드시 확인할 항목은?

① 인터페이스 건수 ② 연동 방식(API/파일/DB/RPA) ③ 실시간 여부 ④ 재처리 설계 포함 여부 ⑤ ERP 벤더 작업 포함 여부, 이 다섯 개다. 싼 견적은 대개 ④와 ⑤가 빠져 있다. 업체별 비교를 배점표로 만드는 방법은 제안서 평가 기준에 따로 정리했다.

정리

ERP 연동 개발의 결과를 가르는 지점은 세 가지다.

첫째, 데이터의 주인을 문서로 확정했는가. 데이터별로 원본을 가진 시스템을 하나만 정하고, 반대 방향 수정은 막아라. 이 표를 못 채운 채 착수한 프로젝트는 예외 없이 재고나 거래처 숫자가 어긋난 채로 오픈한다.

둘째, 인터페이스를 개수로 세고 견적을 받았는가. "ERP 연동 일식"은 견적이 아니라 분쟁 예약이다. 인터페이스를 번호로 나열하고 추가 1건당 단가를 계약서에 넣어라.

셋째, 실패한 건이 어디로 가는지 설계에 있는가. 중복 전표, 마감 후 반려, 코드 불일치는 운영에서 반드시 발생한다. 실패 큐와 재처리 화면, 그리고 그것을 볼 담당자까지 정해져 있어야 연동이 설비로 돌아간다. 여기가 비어 있는 견적은 금액과 무관하게 탈락시켜라.