이카운트 api를 알아보는 분들은 대개 주문은 늘었는데 재고와 매출 자료를 옮기는 일이 더 버거워진 시점에 검색하게 됩니다. 엑셀 파일을 받아 올리고, 품목을 맞추고, 다시 전표를 넣는 과정에서 한 번이라도 수량이 어긋나면 그날 업무가 꼬이기 시작합니다.
처음에는 “연동만 하면 다 편해지겠지”라고 생각하기 쉽습니다. 그런데 실제로는 어떤 자료를 누가 기준으로 관리할지부터 정하지 않으면, 자동화가 오히려 같은 자료를 두 번 만드는 원인이 되기도 합니다.
이 글에서는 기능 이름만 늘어놓지 않고, 이카운트 api를 어디에 쓰면 효과가 있는지와 어디서 멈춰야 하는지를 업무 흐름으로 풀어보겠습니다. 끝까지 읽으면 우리 회사에 개발 연동이 필요한지, 기본 기능과 엑셀만으로도 충분한지 판단할 수 있게 됩니다.
이카운트 api가 필요한 순간은 따로 있습니다
이카운트는 1999년에 서비스를 시작한 웹 기반 전사적 자원 관리 프로그램입니다. 인터넷으로 접속하는 방식이라 사무실 컴퓨터에 별도 프로그램을 설치하지 않아도 재고, 구매, 영업, 생산, 회계, 급여 업무를 한곳에서 처리하도록 설계돼 있습니다.
여기서 말하는 에이피아이(API)는 서로 다른 프로그램이 정해진 규칙으로 자료를 주고받게 하는 통로입니다. 쉽게 말하면 쇼핑몰이나 매장 판매 프로그램에서 생긴 주문 정보를 사람이 다시 입력하지 않고 이카운트의 주문서나 판매전표로 전달하는 연결 장치입니다.
이카운트의 공식 안내 기준으로 오픈 에이피아이(Open API)는 고객사가 쓰는 다른 시스템과 이카운트를 연동하기 위한 개발 정보를 제공하는 서비스입니다. 자체 쇼핑몰, 회사 웹사이트, 키오스크, 자체 앱처럼 회사마다 운영 방식이 다른 도구를 묶을 때 쓰는 기능입니다.
가장 흔한 출발점은 주문 수집입니다. 자사몰에서 결제가 완료되면 주문번호, 주문자, 배송지, 품목, 수량, 금액을 이카운트 주문서에 만들고, 출고가 끝난 뒤에는 판매 자료까지 이어지도록 설계하는 방식입니다.
두 번째는 재고 공개입니다. 온라인 상품 페이지에 표시되는 재고와 실제 창고 재고가 다르면 품절 취소와 고객 응대가 함께 늘어납니다.
이카운트에 등록한 품목과 재고 현황을 외부 판매 화면으로 보내는 흐름이 필요한 이유가 여기에 있습니다. 세 번째는 현장 매출입니다.
오프라인 매장이나 무인 판매기에서 거래가 발생할 때마다 판매 자료를 모아 이카운트에 등록하면, 매장과 온라인 채널의 매출을 같은 기준으로 볼 수 있습니다. 다만 모든 회사가 곧바로 개발 연동을 해야 하는 것은 아닙니다.
스마트스토어, 쿠팡, 카페24처럼 이카운트 쇼핑몰 관리 기능에서 지원하는 채널을 쓰고 있다면, 먼저 제공 기능의 범위를 확인하는 편이 비용과 시간을 아끼는 길입니다. 직접 개발은 표준 연결로 해결되지 않는 업무에서 빛을 봅니다. 예를 들면 사내 주문 프로그램, 독자적인 회원 등급 정책, 거래처별 공급가 계산, 현장 기기 자료 수집처럼 회사만의 규칙이 강할 때입니다.
연동 기능과 스펙, 어디까지 가능한가
이카운트 오픈 에이피아이는 영업, 구매, 생산, 재고, 회계, 근태, 쇼핑몰, 게시판처럼 여러 업무 메뉴의 입력과 조회를 지원합니다. 단순히 주문만 넣는 기능이 아니라 품목과 거래처 정보를 먼저 정리하고, 그 위에서 전표와 재고 자료를 움직일 수 있다는 점이 핵심입니다.
공식 안내에 나온 입력 항목으로는 거래처 등록, 품목 등록, 견적서, 주문서, 판매, 발주서, 구매, 작업지시서, 생산불출, 생산입고, 매출과 매입 자료, 출퇴근, 쇼핑몰 주문서, 게시글 등이 있습니다. 회사가 어느 메뉴를 실제로 쓰는지에 따라 필요한 연동 범위도 완전히 달라집니다.
조회 쪽에서는 품목, 재고 현황, 창고별 재고 현황 같은 자료를 활용할 수 있습니다. 품목 목록만 외부에 보내는 것과 창고별 가용 재고까지 보내는 것은 운영 난도가 다르므로, 판매 화면에 무엇을 보여줄지 먼저 정해야 합니다.
처리 속도는 “몇 초 안에 끝난다”는 식으로 미리 단정하기 어렵습니다. 외부 쇼핑몰의 주문량, 네트워크 상태, 한 번에 보내는 건수, 품목 검증 과정, 재시도 설계에 따라 결과가 달라지기 때문입니다.
그래서 실무에서는 실시간이라는 말보다 처리 주기를 먼저 합의합니다. 주문이 들어오는 즉시 전송할지, 몇 분 단위로 묶어 보낼지, 야간에 한 번 정산할지에 따라 서버 부담과 오류 대응 방식이 달라집니다.
용량도 숫자 하나로 판단하면 안 됩니다. 이카운트는 기본 ERP 서비스의 사용자 수와 용량을 무제한으로 안내하고 있지만, 연동 프로그램은 주문 건수와 호출 방식에 맞게 별도의 운영 여력을 갖춰야 합니다.
호환성의 핵심은 운영체제가 아니라 자료 구조입니다. 외부 시스템의 상품 코드, 옵션 코드, 거래처 코드, 창고 코드가 이카운트의 품목과 거래처 정보에 정확히 이어져야 정상적인 주문 등록과 재고 차감이 가능합니다.
여기서 가장 많이 생기는 실수는 상품명으로 품목을 맞추는 방식입니다. 상품명은 행사나 계절에 따라 쉽게 바뀌지만 품목 코드는 기준값으로 유지할 수 있으므로, 연동 키는 사람이 읽는 이름보다 변경되지 않는 코드로 설계하는 편이 안전합니다.
가격과 이용 방법, 개발비는 따로 봐야 합니다
이카운트 ERP 기본 사용료와 최초 가입비는 시점에 따라 달라질 수 있습니다. 연간 선납 가격과 선택 부가 서비스 조건도 변동될 수 있으니, 정확한 금액은 신청 전 이카운트 공식 가격 페이지에서 직접 확인하는 것이 좋습니다.
사용자 수는 무제한으로 안내돼 있습니다. 주문 담당자, 출고 담당자, 경리 담당자, 관리자처럼 여러 사람이 같은 흐름을 확인해야 하는 회사라면 인원당 비용이 붙는 방식과 비교할 때 장점이 분명합니다.
이카운트는 오픈 에이피아이 사용 자체에 추가 비용이 발생하지 않는다고 공식 안내합니다. 다만 이 말이 개발 프로젝트 전체가 무료라는 뜻은 아닙니다.
연동 설계, 외부 프로그램 제작, 서버 운영, 오류 알림, 보안 점검, 기능 변경 대응에는 개발 인력이나 외주 비용이 들어갑니다. 특히 자사몰이 이미 복잡한 할인 규칙과 묶음 상품 구조를 갖고 있다면, ERP 연결보다 외부 주문 데이터를 정리하는 작업이 더 오래 걸리기도 합니다.
가입은 이카운트 홈페이지에서 진행할 수 있고, 가입 후 로그인한 상태에서 에이피아이 세부 매뉴얼과 테스트 기능을 확인하는 구조입니다. 바로 개발 계약부터 하기보다, 실제 회사 코드로 시험 데이터를 넣어 보는 단계가 먼저입니다.
이용 순서는 단순합니다. 먼저 ERP 안에 품목, 거래처, 창고, 단가, 세금 처리 기준을 정리하고, 다음으로 외부 시스템에서 어떤 자료를 보낼지 정한 뒤, 테스트 환경에서 한 건씩 검증합니다.
그 다음에 정상 주문, 옵션 주문, 품절 주문, 취소 주문, 부분 출고, 반품처럼 예외 상황을 차례로 확인합니다. 이 단계를 빼면 첫 주에는 멀쩡해 보이다가 할인 행사나 교환 요청이 몰린 날 문제가 드러나는 경우가 많습니다.
개발을 외부에 맡길 때는 “이카운트 연동 경험이 있는가”만 묻지 말고, 오류가 났을 때 누가 어디에서 확인하는지까지 계약 전에 확인해야 합니다. 주문을 받은 쇼핑몰, 중간 연동 서버, 이카운트 중 어느 지점에서 멈췄는지 찾는 체계가 없으면 책임만 오가게 됩니다.
실제 사용 환경에서 먼저 시험할 항목
실제 사용을 가정한 테스트는 주문 한 건을 넣는 데서 끝나면 안 됩니다. 예를 들어 의류 쇼핑몰이라면 색상과 사이즈 옵션이 있는 상품, 사은품이 붙는 주문, 묶음 배송 주문을 각각 넣어 품목 코드와 수량이 기대대로 처리되는지 봐야 합니다.
첫 번째 확인 항목은 중복 등록입니다. 외부 시스템이 응답을 늦게 받았다고 같은 주문을 다시 보내면, 이카운트에는 주문이 두 번 생성될 수 있습니다.
이를 막으려면 외부 주문번호를 기준으로 이미 처리한 자료인지 확인하는 장치가 필요합니다. 재전송 자체를 막기보다, 같은 주문이 들어와도 중복 전표를 만들지 않도록 설계하는 편이 장애 상황에 강합니다.
두 번째는 품목 불일치입니다. 쇼핑몰에는 새 옵션이 등록됐는데 이카운트에 품목이 없으면 주문 등록은 실패하거나 엉뚱한 품목으로 잡힐 수 있습니다.
신상품 등록 책임이 어느 부서에 있는지, 등록 후 어느 시점부터 판매를 열지 정해 두어야 합니다. 세 번째는 재고 차감 시점입니다.
결제 완료와 출고 완료 가운데 어느 시점에 재고를 줄일지에 따라 가용 재고가 달라집니다. 예약 판매가 많은 회사는 결제 완료 단계에서 재고를 잡아야 할 수 있고, 현장 재고 중심 회사는 출고 확정 단계가 더 맞을 수 있습니다.
네 번째는 취소와 반품입니다. 주문 취소가 들어왔을 때 주문서만 취소할지, 이미 차감된 재고를 복구할지, 카드 결제와 정산 자료를 어떤 순서로 처리할지는 처음부터 흐름도로 정리해야 합니다.
다섯 번째는 마감 시간입니다. 영업팀이 당일 매출을 확정하는 시간과 창고가 출고를 마감하는 시간이 다르면, 같은 날짜인데도 주문 수량과 판매 수량이 달라 보일 수 있습니다.
제가 여러 업무 자동화를 살펴보며 느낀 점은, 기술 오류보다 기준 없는 업무 흐름이 더 오래 문제를 만든다는 것입니다. 연결은 개발자가 만들지만, 어떤 수치를 회사의 공식 숫자로 볼지는 현업이 정해야 하거든요.
이카운트 api 후기, 장점은 업무의 연결에 있습니다
첫 번째 장점은 이중 입력을 줄일 수 있다는 점입니다. 쇼핑몰 주문을 내려받아 다시 ERP에 올리는 일을 반복하는 환경이라면, 입력 시간만 줄어드는 것이 아니라 복사 과정에서 생기는 수량과 금액 오류도 함께 줄일 수 있습니다.
특히 주문 건수가 적을 때는 수작업이 편해 보입니다. 하지만 채널이 늘고 옵션이 복잡해지면 한 건의 실수가 재고, 출고, 매출, 고객 응대까지 이어지기 때문에 단순 작업량 이상으로 부담이 커집니다.
두 번째 장점은 재고를 한 기준으로 볼 수 있다는 점입니다. 창고 재고와 판매 화면 재고가 서로 다른 파일에서 관리되면 담당자가 늘 확인 전화를 해야 하지만, 연동 구조가 잡히면 재고 확인 업무를 훨씬 짧게 만들 수 있습니다.
세 번째 장점은 보고서의 시차를 줄이는 데 있습니다. 주문 자료가 일정한 규칙으로 들어오면 관리자는 오늘 들어온 주문, 출고 대기 수량, 품목별 판매 흐름을 ERP 기준으로 확인할 수 있습니다.
네 번째 장점은 회사 고유의 도구를 포기하지 않아도 된다는 점입니다. 이미 쓰고 있는 자체 주문 화면이나 현장 판매 화면을 모두 바꾸기보다, 필요한 자료만 ERP에 보내는 방식으로 통합 범위를 조절할 수 있습니다.
다섯 번째 장점은 에이피아이 추가 사용료가 없다는 부분입니다. 다만 앞서 말씀드린 것처럼 실제 판단에서는 월 사용료보다 개발과 유지보수에 들어갈 비용, 그리고 담당자가 관리할 수 있는 범위를 함께 계산해야 합니다.
이카운트 ERP 자체는 웹 기반 서비스이므로 사무실, 물류센터, 외근 장소에서 같은 자료를 확인하기에 편합니다. 사용자 수에 따른 추가 비용이 없다는 정책도 여러 부서가 함께 조회해야 하는 환경에서는 실무적인 이점이 됩니다.
단점과 아쉬운 점, 자동화의 범위를 좁혀야 합니다
가장 큰 아쉬움은 연동 자체가 업무 설계를 대신해 주지는 않는다는 점입니다. 품목 코드가 제각각이고 창고 구분이 흐릿한 상태라면, 에이피아이를 붙여도 잘못된 자료가 더 빨리 쌓일 뿐입니다.
두 번째는 예외 상황의 유지 비용입니다. 쇼핑몰 정책이 바뀌거나 새 배송 방식이 생기고, 묶음 상품이나 할인 규칙이 변경되면 기존 연동도 손봐야 할 수 있습니다.
세 번째는 오류를 알아차리는 시간이 중요하다는 점입니다. 주문 전송이 실패했는데 담당자가 다음 날에야 알면, 고객은 결제했는데 창고에는 출고 지시가 없는 상황이 생길 수 있습니다.
그래서 실패 주문 목록, 재처리 버튼, 담당자 알림을 초기 설계에 넣는 편이 좋습니다. 성공한 자료보다 실패한 자료를 누가 언제 어떻게 처리할지 정해 둔 시스템이 운영하기 편합니다.
네 번째는 개발 언어와 외부 판매 시스템에 따라 구현 난도가 달라진다는 점입니다. 이카운트 쪽 기능이 제공돼도, 상대 시스템이 주문 정보를 안정적으로 내보내지 못하면 연동 전체가 불안정해질 수 있습니다.
다섯 번째는 “실시간”에 대한 기대치입니다. 모든 자료가 즉시 완벽히 바뀐다고 기대하기보다, 어느 자료를 어느 주기로 반영할지 정하고 그 약속을 현업과 공유하는 편이 분쟁을 줄입니다.
경쟁 제품 비교, 무엇을 기준으로 골라야 하나
이카운트 api를 검토할 때 경쟁 제품과의 비교는 기능 개수보다 운영 방식에서 시작해야 합니다. 이미 쇼핑몰 통합 관리 서비스를 중심으로 일하는지, 제조와 재고 그리고 회계까지 하나의 ERP에서 관리할지가 더 중요한 기준입니다.
| 비교 기준 | 이카운트 중심 방식 | 쇼핑몰 통합 관리 중심 방식 |
|---|---|---|
| 주요 목적 | 영업, 재고, 생산, 회계 자료의 통합 관리 | 여러 판매 채널의 주문 수집과 출고 처리 |
| 연동 판단 | 자체 시스템이나 특수 업무를 ERP에 연결할 때 적합 | 지원 쇼핑몰 채널을 빠르게 묶을 때 편리 |
| 강점 | 재고와 전표, 보고서를 한 업무 기준으로 볼 수 있음 | 판매 채널 운영 화면에 익숙한 경우 빠른 시작이 가능함 |
| 주의점 | 품목과 거래처, 창고 기준을 먼저 정리해야 함 | ERP 반영 범위와 재고 기준을 별도로 확인해야 함 |
자체 쇼핑몰을 운영하면서 재고와 회계까지 이카운트로 관리하는 회사라면, 이카운트 중심 설계가 자연스럽습니다. 주문 자료를 단순히 모으는 데서 끝나지 않고, 판매와 재고 그리고 매출 자료까지 이어서 보려는 목적이 있기 때문입니다.
반대로 판매 채널이 많고 표준 쇼핑몰 연동만 필요하다면, 먼저 이카운트 쇼핑몰 관리 기능과 기존 통합 관리 서비스가 제공하는 연결 범위를 비교해야 합니다. 이미 가능한 연결을 다시 개발하면 비용과 유지할 지점만 늘어날 수 있습니다.
대형 구축형 ERP와 비교하면 이카운트는 표준 기능을 빠르게 쓰기 좋은 편입니다. 그러나 회사만의 복잡한 승인 절차, 독자적인 생산 계산, 특수한 물류 규칙을 전부 시스템에 그대로 담으려면 별도의 설계와 개발 범위를 충분히 잡아야 합니다.
비교할 때는 데모 화면만 보지 말고 우리 회사의 실제 주문 파일을 기준으로 질문해야 합니다. 품목 옵션, 취소, 반품, 부분 배송, 거래처별 단가, 창고 이동이 어떤 화면과 어떤 자료로 처리되는지 확인하면 선택이 훨씬 쉬워집니다.
도입 전 체크리스트와 추천 대상
이카운트 api를 추천하는 대상은 주문 자료를 수작업으로 옮기는 일이 반복되는 회사입니다. 특히 자체 쇼핑몰이나 사내 주문 시스템이 있고, 이 자료를 재고와 판매 전표까지 이어서 관리하려는 곳이라면 검토할 가치가 있습니다.
제조업이라면 작업지시와 생산 입출고 자료의 연결을 살펴볼 수 있습니다. 유통업이라면 주문, 출고, 창고별 재고, 거래처 단가가 핵심이고, 매장 중심 사업이라면 현장 판매 자료를 어느 시점에 모을지가 우선입니다.
반대로 품목 수가 적고 주문 건수도 많지 않으며, 정형화된 온라인 채널만 사용하는 경우에는 기본 쇼핑몰 관리 기능과 엑셀 업로드부터 써보는 편이 현실적입니다. 자동화는 불편한 지점을 정확히 찾은 뒤 시작해야 효과가 분명합니다.
도입 전에 꼭 적어둘 것은 다섯 가지입니다. 기준 품목 코드, 주문 상태의 의미, 재고 차감 시점, 오류 발생 시 담당자, 변경 요청을 승인하는 사람입니다.
이 다섯 가지가 문서로 정리되면 개발자와 현업 담당자가 같은 언어로 이야기할 수 있습니다. 반대로 이 기준 없이 “주문이 자동으로 들어오게 해 달라”고만 요청하면, 각자 다른 화면을 떠올려 수정이 반복될 가능성이 큽니다.
가격은 ERP 기본 사용료와 개발 비용을 분리해서 판단해야 합니다. 이카운트의 기본 ERP 사용료는 공식 기준 월 4만 원이며, 오픈 에이피아이 자체 추가 사용료는 없지만 실제 개발과 운영에 필요한 비용은 회사 상황에 따라 달라집니다.
그래서 구매 가이드는 의외로 단순합니다. 먼저 이카운트에 시험용 자료를 넣어 보고, 표준 기능으로 해결되는 범위를 확인한 다음, 남는 불편만 개발 목록으로 좁히면 됩니다.
자주 묻는 질문
Q. 이카운트 api는 별도 비용이 드나요?
A. 이카운트 공식 안내 기준으로 오픈 에이피아이 사용에 대한 추가 비용은 없습니다. 다만 외부 시스템 연결을 만드는 개발비와 이후 유지보수 비용은 별도로 발생할 수 있습니다.
Q. 스마트스토어와 쿠팡도 직접 개발해야 하나요?
A. 이카운트는 스마트스토어, 쿠팡, 카페24 같은 온라인 쇼핑몰은 쇼핑몰 관리 기능으로 연동할 수 있다고 안내합니다. 실제 지원 범위와 필요한 설정은 판매 채널, 사용하는 기능, 계약 상태에 따라 먼저 확인하는 편이 좋습니다.
Q. 이카운트 api로 재고를 쇼핑몰에 바로 보여줄 수 있나요?
A. 품목과 재고 현황, 창고별 재고 현황을 조회하는 기능을 활용해 외부 화면으로 보내는 구조를 만들 수 있습니다. 다만 판매 가능 재고의 계산 기준과 반영 주기는 회사의 운영 방식에 맞게 정해야 합니다.
Q. 개발 경험이 없는 회사도 사용할 수 있나요?
A. ERP 설정과 기본 쇼핑몰 관리 기능은 현업 담당자가 익혀 사용할 수 있습니다. 자체 시스템과의 개발 연동은 매뉴얼 확인, 테스트, 오류 대응이 필요하므로 사내 개발자나 연동 경험이 있는 업체와 역할을 나누는 편이 안정적입니다.
Q. 주문이 중복 등록되는 문제는 어떻게 막나요?
A. 외부 주문번호를 기준으로 이미 처리된 주문인지 확인하는 절차를 연동에 넣어야 합니다. 통신 오류로 재전송이 발생해도 같은 주문이 두 번 전표로 생성되지 않도록 설계하는 것이 핵심입니다.
이카운트 api는 화려한 기능 하나를 추가하는 도구라기보다, 흩어진 업무 자료의 기준을 맞추는 방법에 가깝습니다. 우리 회사가 어떤 숫자를 믿고 어떤 순서로 일을 처리할지부터 정리한다면, 그때부터 연동은 확실히 힘을 발휘합니다.
함께 보면 좋은 글
이어서 읽어보세요