이 글은 중원랩스(중원컨설팅)가 맡아 진행한 이카운트 연동 프로젝트 가운데 두 곳, 온라인 쇼핑몰 A사와 유통업 C사의 기록을 바탕으로 2026년 11월 기준으로 재구성한 글입니다. 고객사와 담당자, 사용한 프로그램의 이름은 밝히지 않고 일반 명칭으로 바꿨습니다. 품목과 수량, 창고 구성은 설명을 위한 예시입니다.
자동화 상담에서는 "이카운트 API로 붙이면 되지 않나요?"라는 질문이 가장 먼저 나옵니다. 공식 API가 열려 있는 업무라면 API가 첫 후보인 것도 맞습니다. 그런데 실제 현장의 주문 자료는 엑셀로만 내려받을 수 있거나, 사람이 중간에 손을 대야 하는 단계를 품고 있는 경우가 많습니다.
그래서 같은 판매전표 자동등록이라도 회사마다 고르는 방식이 달라집니다. 어느 방식을 고르든 품목코드 대응, 실패 건을 누가 받는지, 어디까지를 정상으로 볼지가 정해지지 않으면 자동화는 오래가지 못합니다. 문제는 도구가 아니라 업무의 경계입니다.
핵심 요약
이카운트 API는 이카운트에 자료를 등록하는 자동화의 첫 후보지만, 원천 자료가 엑셀 가공을 꼭 거쳐야 하거나 해당 업무가 공식 API로 열려 있지 않다면 엑셀 업로드나 화면 기반 자동화가 더 맞을 수 있습니다. 방식을 고르기 전에 코드 대응, 실패 처리, 정상 범위부터 정해야 합니다.
- 판단 순서: 공식 API로 열린 업무는 API를 먼저 검토합니다. 중간에 엑셀 가공이 빠질 수 없는 흐름은 엑셀 업로드로 끝맺고, API가 없는 업무는 화면 기반 자동화(RPA)를 봅니다.
- A사(온라인 쇼핑몰): 여러 쇼핑몰 주문을 판매전표로 자동등록했습니다. 공식 API 저장도 검토했지만, 최종 등록은 엑셀로 변환한 결과를 판매입력 [웹자료올리기]로 올리는 방식을 택했습니다.
- C사(유통업): 거래처가 온라인으로 넣은 주문을 화면 기반 프로그램이 짧은 간격으로 판매입력에 넘깁니다. 몇 시간에 한 번 정도 생기는 간헐 실패는 정상 범위로 봅니다.
- 공통 교훈: 두 회사 모두 실패 건수를 0으로 만드는 일보다, 알림 없이 멈추거나 성공처럼 지나가는 실패를 드러내는 일에 더 공을 들였습니다.
이카운트 API란: 공식 연동 통로와 사용 조건
이카운트 API는 이카운트가 외부 프로그램에 공개한 공식 연동 통로(오픈API)입니다. 외부 시스템은 이 통로로 이카운트 자료를 조회하거나, 판매입력과 쇼핑몰 주문 같은 입력 API로 전표를 등록합니다. 호출 흐름은 Zone 조회에서 시작해 로그인을 거친 뒤 업무 API를 부르는 순서이고, 로그인에는 관리자가 발급한 인증키를 씁니다. 인증키에는 만료일이 있어 기한이 지나면 세션이 발급되지 않으므로, 만료일 관리도 운영 업무에 포함해야 합니다.
호출량에도 한도가 있습니다. 이카운트 공식 안내(2026년 11월 4일 확인)에 따르면 호출 한 번에 300건, 하루에 5,000건이 상한이며 이 상한은 늘릴 방법이 없습니다. 그래서 주문을 한 건씩 보내기보다 여러 건을 묶어 등록하고, 바뀐 자료만 조회하고, 오류가 나도 곧바로 다시 호출하지 않도록 설계합니다. API 매뉴얼은 이카운트 로그인 후 Self-Customizing > 정보관리 > API인증키발급 메뉴에서 확인할 수 있고, 실제 키를 쓰기 전에 테스트 키로 먼저 검증합니다.
1. 두 회사의 출발점: 같은 판매전표, 서로 다른 주문 경로
두 회사가 이카운트에 남기려던 결과물은 모두 판매입력, 곧 판매전표였습니다. 차이는 주문이 들어오는 길에 있었습니다. A사 주문은 여러 쇼핑몰에서 주문 수집 도구로 모인 뒤 엑셀 파일로 나왔고, C사 주문은 거래처가 온라인으로 직접 넣었습니다. 이 출발점의 차이가 두 회사의 연결 방식을 갈랐습니다.
| 비교 항목 | 쇼핑몰 A사 | 유통 C사 |
|---|---|---|
| 주문이 생기는 곳 | 입점한 여러 쇼핑몰, 수집 도구에 모임 | 거래처의 온라인 주문 |
| 등록 결과 | 판매입력, 저장 즉시 재고 차감 | 판매입력 |
| 공식 이카운트 API 사용 | 검토했으나 쓰지 않음 | 쓰지 않음 |
| 실제 등록 방식 | 엑셀로 변환해 [웹자료올리기], 매크로 예비 경로 | 화면 기반 프로그램이 몇 분 간격으로 실행 |
| 진행 상태 | 2026년 9월 말 기록으로 운영 단계 | 운영 중이며 재고표 등 다른 자동화는 추진 단계 |
표 1. 두 회사 판매입력 자동화의 출발점 (설명용 정리)
그림 1. A사와 C사의 판매입력 자동등록 경로 — 중원랩스 설명용 도식, 단계 구성은 단순화한 예시입니다.
2. A사의 판단: 쇼핑몰 주문 자동등록을 이카운트 API 대신 [웹자료올리기]로 끝맺었습니다
A사는 쇼핑몰 여러 곳에 입점해 판매하는 온라인 쇼핑몰 회사입니다. 주문은 수집 도구로 한데 모였지만 매출과 재고 관리는 이카운트 몫이어서, 담당자가 그 주문을 판매전표로 한 번 더 입력해야 했습니다. 이 일이 월말에 몰리면 월중 재고는 실제보다 많아 보이고, 같은 주문을 두 번 확인하게 됩니다. 상담에서 정한 목표는 온라인 매출 자동 집계, 판매 즉시 재고 차감, 손으로 옮겨 적는 입력 없애기였습니다.
이 글에서는 주문 한 건을 예로 들어 따라가겠습니다(예시). 고객이 텀블러 1개와 접시 2종 세트 1개를 주문하고 배송비를 냈습니다. 텀블러는 1번 창고, 세트 구성품은 2번 창고에서 출고됩니다.
연결 방식보다 먼저 맞춘 네 가지 기준
공식 API로 보내든 엑셀로 올리든, 이카운트가 저장하려면 품목코드, 창고, 수량, 단가가 이카운트 기준에 맞아야 합니다. A사 주문 자료는 네 곳에서 이 기준과 어긋났습니다. 예시 주문에서는 텀블러 줄과 세트 줄이 서로 다른 창고로 가고, 배송비는 별도 줄이 됩니다.
| 어긋난 곳 | 현장에서 보인 현상 | 점검 항목 | 정한 규칙 |
|---|---|---|---|
| 품목코드 | 수집 도구의 상품·옵션 코드로는 이카운트 품목을 찾지 못함 | 매칭표에 매칭 키가 비어 있는 줄 | 매칭되지 않은 줄은 업로드에서 보류, 묶음 옵션은 구분 기호로 나눠 품목별 처리 |
| 창고 | 한 주문이 전표 여러 장으로 나뉘거나 기본 창고로 빠짐 | 품목별 담당 창고, 창고 코드 형식 | 같은 창고끼리 묶어 전표 생성, 공란과 형식 불일치를 나눠 점검 |
| 단가 | 원천 자료에 단가 칸이 없음 | 단가를 무엇으로 계산할지 | 주문금액을 수량으로 나눠 계산, 단가는 소수점 아래를 남기고 공급가액과 부가세만 반올림 |
| 배송비 | 배송비 누락 또는 중복 | 배송 방법별 처리 규칙 | 무형 품목으로 등록해 상품 줄 아래 별도 줄로, 창고는 바로 앞 줄을 따름 |
표 2. A사 주문 자료가 이카운트 기준과 어긋난 네 지점 (설명용 정리)
이 중 가장 놓치기 쉬운 곳은 매칭 키 공란입니다. 매칭표에 키를 비운 채 등록해도 아무 경고가 없고, 실패는 자동화가 그 줄을 처리하는 순간에야 드러납니다. 그래서 A사 안내 문구도 권장 표현을 버리고 "이 코드가 없는 행은 자동 처리되지 않습니다"로 바꿨습니다. 예시 주문의 세트 옵션에 키가 비어 있다면, 세트가 담긴 전표는 저장되지 않습니다.
판매입력과 주문서, 세트 처리에서 고른 길
먼저 주문서(수주)로 받아 두었다가 판매로 전환하는 안이 나왔습니다. 그러나 주문서 단계에서는 재고가 줄지 않아, 판매 가능한 재고를 실시간으로 확인하려던 A사 목적과 어긋났습니다. 그래서 저장 즉시 재고가 차감되는 판매입력을 결과물로 정했습니다.
세트는 생산입고로 조립해 관리하는 방안이 있었지만, 기존 데이터의 재고와 원가까지 흔들릴 수 있어 채택하지 않았습니다. 대신 세트에 담긴 구성 품목을 낱개로 차감합니다. 그 대가로 세트별 원가는 정밀하게 볼 수 없지만, A사에게는 매출과 재고 숫자가 맞는 것이 우선이었습니다. 기존 영업 담당자가 쓰는 판매입력 화면은 그대로 두고, 자동등록에만 쓰는 판매입력 화면을 따로 만들었습니다.
공식 API 저장을 검토하고도 [웹자료올리기]로 끝맺은 이유
중원랩스는 이카운트에 자료를 등록하는 작업이라면 공식 API를 기본값으로 둡니다. 주고받는 자료의 구조가 정해져 있고, 화면 개편이 있어도 연동이 흔들릴 일이 적기 때문입니다. 그 기준대로라면 A사의 등록도 공식 API가 먼저였습니다. 하지만 A사 흐름에는 주문 수집 도구에서 내려받은 엑셀을 매칭하고 변환하는 단계가 빠질 수 없었습니다. 엑셀 가공이 필수인 흐름에서 마지막 단계만 API로 바꾸면 한 흐름 안에 두 방식이 섞이고, 문제가 생겼을 때 어디부터 볼지 흐려집니다. 담당자가 같은 엑셀로 직접 올리는 예비 경로를 남기기도 어려워집니다.
| 비교 항목 | 공식 이카운트 API로 저장 | 엑셀로 바꿔 [웹자료올리기] |
|---|---|---|
| 어울리는 흐름 | 원천 자료를 시스템이 직접 넘겨주고 손볼 단계가 적음 | 엑셀 매칭·변환이 반드시 필요함 |
| 운영 준비 | 인증키 만료일, 호출 상한, 오류 응답을 다룰 설계 | 변환 양식과 업로드 양식, 브라우저 환경 |
| 자동화가 멈췄을 때 | 개발 지식이 있어야 대신 처리 가능 | 담당자가 같은 엑셀로 직접 업로드 가능 |
| 이카운트 화면 변경 | 영향이 적음 | 영향이 있어 유지보수로 대응 |
| A사 결정 | 검토만 함 | 최종 선택 |
표 3. 공식 이카운트 API 저장과 [웹자료올리기]의 차이 (설명용 정리)
두 방식 가운데 하나가 늘 옳다고 보기는 어렵고, 원천 자료가 어디에서 어떤 모양으로 나오는지가 답을 정합니다. A사에서는 엑셀이 흐름의 중심이었기 때문에 엑셀 업로드로 끝맺는 쪽이 관리하기 쉬웠습니다. 원천 자료가 처음부터 시스템 사이에서 오간다면 같은 판단에서도 공식 API가 앞섭니다.
A사 자동등록이 돌아가는 순서
- 매칭표 갱신 (담당자, 사무실 PC): 신규 상품을 등록할 때마다 대응하는 이카운트 품목코드를 매칭표에 적고, 매칭 키 칸은 반드시 채웁니다.
- 주문 엑셀 받기 (담당자, 사무실 PC): 주문 수집 도구에서 이카운트 업로드용 주문 파일을 내려받습니다.
- 변환 (확장 프로그램, 같은 PC): 매칭표에서 품목과 창고를 찾아 붙이고, 창고가 다르면 전표를 가르고, 단가 계산과 배송비 줄 추가를 처리합니다.
- 업로드 (확장 프로그램, 같은 PC): 변환된 자료를 판매입력 [웹자료올리기] 창에 자동으로 넣습니다.
- 저장 확인 (담당자, 같은 PC): 시험 운영 동안에는 담당자가 결과를 눈으로 확인하고 저장을 누르며, 검증을 통과한 다음부터 저장도 자동으로 돌립니다.
- 실패 줄 재처리 (담당자, 같은 PC): 저장 뒤 이카운트가 알려 준 실패 줄과 사유를 엑셀로 남기는 방식으로 정했고, 원인을 고쳐 다시 올리는 일은 사람이 맡습니다.
확장 프로그램은 PC의 파일 권한이나 내려받기 폴더 설정이 달라지면 멈출 때가 있습니다. 이를 대비해 A사는 엑셀 매크로로 같은 결과를 만드는 경로도 남겨 두었습니다. 주문 파일을 주문 시트에 붙여 변환하고, 만들어진 판매입력 시트를 [웹자료올리기]에 옮겨 붙이는 방식이어서 PC 환경을 거의 타지 않습니다. A사 자동등록은 2026년 9월 말 기록으로 보면 운영 단계이고, 실패 줄을 모으는 방식과 매칭 키 공란을 찾는 점검은 방향만 정해 둔 상태입니다.
소량 테스트에서 자동 저장까지 넘어간 기준
A사는 예시 같은 주문 한 건을 먼저 흘려 보며 매칭, 창고 분리, 단가 계산, 배송비 줄이 기대대로 나오는지 맞춰 봤습니다. 다음으로 처리량을 300줄 안쪽으로 묶어 결과만 띄우고, 저장 버튼은 담당자 손에 남겼습니다. 이때 '매칭 없음'이 한 건도 없어야 자동 저장을 켰습니다. 최종 시험은 A사가 먼저 제안한 방식대로 주말 주문이 쌓인 월요일에 하고, 그 주를 지켜봤습니다. 평소 적은 주문으로는 보이지 않던 예외가 주문이 몰리는 날 드러나기 때문입니다.
3. C사의 판단: 화면 기반 프로그램으로 판매입력을 반복하고 정상 범위를 정했습니다
C사는 거래처가 온라인으로 넣는 주문을 받는 유통 회사입니다. C사의 주문 자동화는 공식 이카운트 API가 아니라 이카운트 화면을 다루는 프로그램이 몇 분 간격으로 주문을 확인해 판매입력으로 넘기는 구조이고, 현재 운영 중입니다. 이카운트 화면이 바뀌면 화면 기반 자동화가 영향을 받을 수 있다는 점은 C사와 미리 확인했고, 유지보수로 대응하기로 했습니다. 재고표나 입고 예정표 같은 다른 자동화는 아직 진행 중입니다.
C사는 정상 범위를 먼저 정했습니다
몇 분마다 도는 자동화라면 통신 상태 때문에 이따금 한 번씩 실패하는 것이 자연스럽습니다. C사는 이런 실패가 몇 시간에 한 번꼴이면 정상으로 보고, 빈도가 뚜렷하게 늘 때에만 원인을 찾습니다. 실패가 0이어야 정상인 자동화는 아니라는 뜻입니다. 오히려 C사가 이상 신호로 보는 것은 실행 이력이 정해진 주기보다 오래 비어 있는 상태입니다. 운영 중 오류는 기존 소통 채널에 남기면 담당자가 확인합니다.
사람이 손댄 자리에는 표시를 남깁니다
- 자동 실행 일시 중지: 송장처럼 사람이 직접 입력할 때는 자동 실행을 잠시 끕니다. 다시 켜지 않으면 자동화는 오류 없이 멈춰 있으므로, 수정이나 점검 뒤에는 자동 실행 설정이 꺼진 채 남지 않았는지 확인합니다.
- 배송비 추가 여부: 배송비를 사람이 손으로 입력했다면 그 주문의 '배송비 추가 여부'를 반드시 채웁니다. 이 칸이 비어 있으면 자동화가 배송비 줄을 다시 만들어 두 번 계상됩니다.
- 안전재고 설정: 판매입력의 안전재고를 '저장 안 됨'으로 설정하면 재고가 부족할 때 자동화가 그 자리에서 막힙니다. 설정을 메시지 안내로 바꾸고 재고가 모자란 건은 저장 없이 넘어가는 방향을 검토하고 있으며, 건너뛴 건을 사람이 알아챌 방법도 함께 정하는 중입니다.
4. 두 사례로 본 판단 순서: 공식 이카운트 API가 기본, 예외는 두 갈래
두 사례를 겹쳐 보면 판단의 뼈대는 단순합니다. 등록 업무가 공식 이카운트 API로 열려 있으면 API를 먼저 봅니다. 흐름 한가운데 엑셀 손질이 빠질 수 없다면 A사처럼 엑셀 업로드로 마무리하고, 해당 업무를 API로 다룰 수 없다면 화면 기반 자동화를 검토합니다. 화면 기반을 고를 때는 "이 동작을 사람이 화면에서 그대로 할 수 있는가"를 먼저 물어봅니다.
그림 2. 이카운트 자동화 방식을 고르는 판단 흐름 — 중원랩스 설명용 도식, 판단 순서를 단순화해 보여 줍니다.
표준 기능, API, RPA, 엑셀 업로드를 업무 성격별로 나누는 일반 기준과 개발 착수 전 점검 항목은 이카운트 API·RPA 자동화 기준을 정리한 글에서 따로 다룹니다. 이 글은 그 기준이 실제 프로젝트에서 어떻게 적용됐는지에 초점을 둡니다.
5. 운영 규칙: 실패를 없애기보다 실패가 보이게 만들었습니다
자동등록이 돌기 시작하면 관심사가 "제대로 들어가는가"에서 "어긋났을 때 누가 알아채는가"로 옮겨 갑니다. A사와 C사는 서로 다른 종류의 실패를 경계했지만, 결론은 같았습니다. 실패 건수 자체보다 실패가 드러나지 않는 상태가 더 위험하다는 것입니다.
A사에서는 한때 오류가 화면에 뜨지도 않고 재확인도 거치지 않은 채 지나간 적이 있습니다. 결과가 성공한 것처럼 보였으니 담당자로서는 알아챌 수 없었습니다. 그 뒤로 실패 표시, 잠시 기다린 뒤 결과 재확인, 실패 줄 기록을 A사 자동화의 기본으로 삼았습니다. 실패 줄을 모으는 방식도 사전 검증 대신 사후 취합으로 정했는데, 저장 시점에 이카운트가 스스로 유효성을 따져 어떤 줄이 왜 실패했는지 돌려주기 때문입니다.
| 비교 항목 | 쇼핑몰 A사 | 유통 C사 |
|---|---|---|
| 주문 출처 | 여러 쇼핑몰, 주문 수집 도구에 모음 | 거래처 온라인 주문 |
| 최종 등록 방식 | 엑셀 변환 후 판매입력 [웹자료올리기], 매크로 경로 병행 | 화면 기반 프로그램이 판매입력에 반복 등록 |
| 공식 API를 쓰지 않은 지점 | 중간 엑셀 가공이 필수라 엑셀 업로드로 끝맺음 | 화면 기반으로 구성, 화면 변경은 유지보수로 대응 |
| 특히 조심한 실패 | 오류가 났는데도 화면상 성공으로 보임 | 수동 작업 중 꺼 둔 자동 실행을 깜빡 잊고 방치 |
| 정상과 이상의 경계 | 저장 후 남긴 실패 줄 기록으로 판단 | 가끔 나는 실패는 정상, 실행 기록이 오래 끊기면 이상 |
표 4. 두 회사가 실패를 다루는 방식 (설명용 정리)
마치며: 우리 회사 이카운트 연동, 방식보다 먼저 답할 질문
- 등록하려는 업무가 공식 이카운트 API로 열려 있습니까, 화면이나 엑셀로만 처리됩니까?
- 주문 자료가 시스템에서 곧바로 넘어옵니까, 엑셀로 받아 손질해야 합니까?
- 쇼핑몰 상품마다 대응하는 이카운트 품목코드가 정리돼 있고, 매칭 키가 빠진 줄을 골라낼 수 있습니까?
- 창고가 섞인 주문과 배송비 줄을 어떻게 나눌지 규칙이 있습니까?
- 자동화가 멈추거나 실패하면 그 사실을 누가 어떤 화면으로 확인합니까?
- 사람이 손댄 주문을 자동화가 알아볼 표시가 있습니까?
자주 묻는 질문
Q. 이카운트 API란 무엇인가요?
A. 이카운트가 외부 프로그램에 공개한 공식 연동 통로(오픈API)입니다. Zone 조회 뒤 로그인하고 업무 API를 부르는 흐름이며, 관리자가 발급한 인증키로 로그인하고 인증키 만료일을 관리해야 합니다.
Q. 이카운트 API 호출 한도는 얼마인가요?
A. 이카운트 공식 안내 기준(2026년 11월 4일 확인)으로 1회 300건, 1일 5,000건이며 늘릴 수 없습니다. 그래서 주문을 묶어서 등록하고, 오류가 나면 시간을 두고 다시 보내도록 짭니다.
Q. 쇼핑몰 주문 자동등록은 꼭 이카운트 API로 해야 하나요?
A. 그렇지 않습니다. 공식 API가 첫 후보이지만, 온라인 쇼핑몰 A사처럼 중간에 엑셀 변환이 꼭 필요하면 판매입력 [웹자료올리기]로 끝맺는 편이 유지보수와 예비 경로 면에서 나을 수 있습니다.
Q. 공식 API가 아닌 방식으로 등록하면 무엇을 대비해야 하나요?
A. 엑셀 업로드나 화면 기반 프로그램은 이카운트 화면 개편의 영향을 피하기 어려우므로 유지보수 계획을 함께 세워 둡니다. A사처럼 담당자가 손으로 같은 결과를 만들 수 있는 예비 경로를 남겨 두면 자동화가 멈춰도 업무는 이어집니다.
Q. 반복 실행하는 자동화에서 가끔 오류가 나면 고장인가요?
A. 꼭 그렇지는 않습니다. 몇 분 간격으로 도는 C사 자동화는 몇 시간에 한 번꼴의 간헐 실패를 정상으로 보고, 실행 기록이 정해진 주기보다 오래 비는 상태를 더 경계합니다.
Q. 사람이 직접 입력할 때 자동화와 겹치지 않게 하려면 어떻게 하나요?
A. C사는 송장처럼 사람이 입력하는 동안 자동 실행을 잠시 끄고, 작업 뒤 다시 켜졌는지 확인합니다. 배송비를 손으로 넣은 주문에는 '배송비 추가 여부'를 채워 자동화가 배송비를 다시 붙이지 않게 합니다.
관련 글
- 이카운트 API·RPA 자동화, 개발 전에 확인할 7가지
- 이카운트 판매입력, 품목명만 온 주문을 AI 초안으로
- 더존 iCUBE·엑셀에서 이카운트로 데이터 이관하는 체크리스트
- 이카운트 컨설팅 문의 전 준비할 6가지 자료
우리 회사 이카운트 연동 방식도 함께 점검해 보세요
판매전표 자동등록을 검토하고 있다면 최근에 받은 주문 파일 하나와 이카운트 품목·창고 목록, 현재 판매전표 입력 절차를 준비해 주세요. 주문이 어디에서 어떤 모양으로 들어오는지부터 함께 보고, 공식 이카운트 API로 갈지 엑셀 업로드나 화면 기반 자동화로 끝맺을지 판단해 드립니다.