업무 자동화 용어집
연동
- 오픈 APIOpen API
회사 밖 프로그램이 정해진 규칙으로 데이터를 넣고 꺼낼 수 있게 공개한 연결 통로.
ERP 제조사, 쿠팡, 카페24처럼 업무 시스템을 운영하는 회사가 외부 프로그램에 열어 둔 기능 목록입니다. 사람이 화면에서 엑셀을 내려받고 올리던 일을 프로그램이 대신 호출하게 만들 수 있습니다. 자동화할 때는 어떤 기능이 열려 있는지(저장만 되는지, 수정·삭제도 되는지), 누가 키를 발급하는지, 사용료가 있는지를 먼저 확인합니다. 국내 클라우드 ERP 중에는 오픈 API 사용에 추가 비용이 없다고 안내하며 판매·주문서 입력과 재고 조회 등을 제공하는 곳도 있습니다.
- 인증키API 인증키, Access Key, Secret Key
오픈 API를 호출하는 프로그램이 누구인지 확인하는 데 쓰는 문자열 열쇠.
인증키를 가진 프로그램은 그 회사 계정 권한으로 데이터를 읽고 쓸 수 있으므로 비밀번호처럼 관리해야 합니다. ERP 중에는 로그인 후 화면에서 API 인증키를 발급하되 회사의 최고 관리자 계정(마스터 ID)으로만 발급할 수 있는 곳이 있습니다. 쿠팡은 Wing에서 Access Key와 Secret Key를 발급합니다. 외주로 연동할 때는 키를 회사가 직접 발급해 전달하고, 계약이 끝나면 다시 발급해 이전 키를 끊을 수 있는지 확인합니다.
- OAuthOAuth 2.0
키를 건네주지 않고 계정 주인이 앱에 필요한 권한만 승인해 주는 인증 방식.
카페24가 이 방식을 씁니다. 개발자센터에 앱을 등록하고 쇼핑몰 운영자가 권한을 승인하면 앱이 접근 토큰을 받아 API를 호출합니다. 카페24 기준 접근 토큰은 2시간, 갱신 토큰은 2주 동안 유효하므로 토큰을 주기적으로 갱신하는 처리가 프로그램에 들어가야 합니다. 주문 조회는 mall.read_order, 주문 변경은 mall.write_order처럼 권한 범위를 나눠 요청합니다.
- 쿠팡 Wing APIWing Open API, 쿠팡 API
쿠팡 판매자센터(Wing)에서 키를 발급해 주문 조회, 송장 전송 등을 연동하는 API.
Wing에서 Access Key와 Secret Key를 발급하고, API를 호출할 서버의 IP를 허용 목록에 등록해야 합니다. 등록된 IP에서만 호출이 되므로 외주 개발사는 주소가 바뀌지 않는 고정 IP 서버를 준비합니다. 송장업로드는 상품준비중 상태의 주문에만 가능해서 주문 확인 단계를 먼저 처리하는 흐름이 필요합니다. 키 만료와 재발급 일정을 운영 항목에 넣어 두지 않으면 어느 날 주문 수집이 멈출 수 있습니다.
쇼핑몰·물류
- 주문 수집주문 자동 수집
여러 판매 채널에 들어온 주문을 한곳으로 모으는 작업.
스마트스토어, 쿠팡, 카페24 판매자센터에서 주문 엑셀을 내려받거나 API로 새 주문을 가져오는 단계입니다. 판매처마다 열 이름, 제목 줄 위치, 번호 형식이 달라서 공통 열 표에 맞춰 합치는 처리가 함께 들어갑니다. API로 수집하면 고객 이름, 연락처, 주소가 수집 서버를 거치므로 개인정보 처리 위탁 여부도 함께 정리해야 합니다.
- 택배 일괄 접수일괄 접수, 파일접수
여러 건의 배송을 택배사 양식 파일 하나로 한꺼번에 접수하는 방식.
받는 분 이름, 전화번호, 주소, 품목명 등을 택배사 양식에 채워 올리면 택배사가 송장번호를 붙여 돌려줍니다. CJ대한통운 기업고객 파일접수처럼 회사마다 열 순서(레이아웃)를 따로 정해 쓰는 경우가 있어, 실제로 쓰는 양식 파일에 맞춰 열을 연결해야 합니다. 접수할 때 판매처 주문번호를 고객주문번호 칸에 넣어 두면 나중에 송장을 주문에 되돌리기 쉬워집니다.
- 송장번호운송장번호
택배사가 소포 하나마다 붙이는 배송 추적용 번호.
택배 접수 후 택배사 결과 파일에 담겨 돌아오며, 각 쇼핑몰에 다시 등록해야 고객이 배송을 조회할 수 있습니다. 한 상자에 여러 주문 줄이 들어가면 같은 송장번호를 여러 줄에 넣어야 하고, 한 주문을 두 상자로 나누면 송장이 두 개 나옵니다. 다른 주문에 잘못 붙으면 오배송 문의로 이어지므로 주문번호로 매칭하고 안 맞는 줄은 따로 확인합니다.
- 송장 일괄 등록일괄발송
택배사에서 받은 송장번호를 판매처별 양식에 채워 여러 주문에 한 번에 올리는 작업.
택배사 결과 파일의 주문번호로 원래 주문을 찾아 판매처마다 정해진 업로드 양식을 만드는 과정입니다. 스마트스토어는 발주발송관리의 엑셀 일괄발송, 쿠팡은 Wing 배송관리 파일, 카페24는 관리자 배송 정보 일괄 등록을 씁니다. 쿠팡 API로 송장을 보낼 때는 주문이 상품준비중 상태여야 합니다. 매칭이 안 된 줄은 억지로 맞추지 말고 확인 필요 목록으로 빼면 실수가 줄어듭니다.
- 고객주문번호
택배 접수 파일에 보내는 쪽이 넣는 주문 식별 번호 칸.
택배사 결과 파일에 송장번호와 함께 그대로 돌아오기 때문에 송장을 원래 주문에 되돌리는 열쇠가 됩니다. 비워 두면 이름과 전화번호로 짐작해야 해서 동명이인이나 같은 고객의 주문 두 건에서 틀리기 쉽습니다. 판매처마다 번호 체계가 다르므로 판매처 이름과 주문번호를 함께 넣어 두면 헷갈리지 않습니다.
- 합포장묶음배송, 합배송
같은 고객의 여러 주문 상품을 한 상자에 담아 송장 하나로 보내는 것.
같은 판매처 안에서는 스마트스토어의 배송비 묶음번호, 쿠팡의 묶음배송번호처럼 판매처가 정한 번호로 묶습니다. 판매처가 다른 주문은 받는 분 이름, 연락처, 주소가 모두 같을 때만 합포장 후보로 확인 목록에 올리고, 실제로 묶을지는 담당자가 정하는 편이 안전합니다. 묶은 뒤에는 상품주문번호마다 같은 송장번호를 넣어야 하는 판매처가 있어 송장 복사 규칙을 미리 정해 둡니다.
- 엑셀 숫자 정밀도숫자 정밀도, 지수 표기
엑셀이 숫자를 15자리까지만 정확하게 저장하는 제한.
쿠팡 묶음배송번호처럼 18자리 안팎인 번호가 숫자 칸에 들어가면 뒷자리가 0으로 바뀌거나 1.23E+18 같은 지수 표기로 보입니다. 0으로 시작하는 우편번호와 하이픈 없는 휴대전화 번호도 숫자로 읽히면 맨 앞 0이 사라집니다. 번호, 우편번호, 연락처 열은 처음 읽을 때부터 텍스트로 다뤄야 송장 매칭이 깨지지 않습니다.
ERP·회계
- 엑셀 일괄 업로드엑셀 업로드
ERP 입력 화면에서 양식에 맞춘 엑셀 자료를 붙여넣어 여러 건을 한꺼번에 올리는 기능.
판매 입력 화면 같은 곳에서 양식을 받아 작성하고 붙여넣거나 올리는 방식이며, 메뉴 이름은 ERP마다 다릅니다. 올릴 때 오류가 있는 줄과 사유를 보여 주는 제품도 있습니다. 인증키 없이 쓸 수 있고 담당자가 오류를 보고 저장하는 과정이 그대로 확인 단계가 됩니다. 입력 화면 항목을 회사마다 바꿀 수 있는 ERP라면 양식도 회사마다 다르므로, 고객사 ERP에서 직접 내려받은 양식에 맞추는 것이 가장 확실합니다.
- 판매 입력판매입력, 판매 전표
ERP에서 거래처에 판 내역(거래처, 품목, 수량, 단가)을 전표로 기록하는 메뉴.
저장된 판매 전표는 재고와 매출 집계에 반영되므로 잘못 들어가면 확인할 곳이 늘어납니다. 엑셀 일괄 업로드로 올리거나 오픈 API로 저장할 수 있으며, 판매 입력 API에 수정·삭제 기능이 없는 ERP라면 잘못 들어간 전표는 사람이 화면에서 고쳐야 합니다. 그래서 자동화할 때는 전표 초안을 만들고 사람이 승인한 뒤 보내는 순서를 둡니다.
- 품목코드
ERP에 등록된 상품 하나하나를 구분하는 회사 내부 코드.
거래처는 같은 물건을 각자 다른 이름으로 부르지만 ERP 전표에는 우리 회사 품목코드가 들어가야 합니다. 발주서 자동 입력에서 가장 시간이 드는 부분이 거래처 품목명을 품목코드로 바꾸는 일이고, 이를 위해 매칭표를 씁니다. 보내기 전 검사에서는 품목코드가 품목 마스터에 있는지, 매칭표와 일치하는지를 확인합니다.
- 거래처코드
ERP에 등록된 거래처를 구분하는 코드.
판매 전표에는 어느 거래처에 판 것인지 거래처코드로 기록합니다. 발주서에 적힌 상호가 ERP에 등록된 이름과 조금만 달라도 다른 거래처로 잘못 들어갈 수 있습니다. 자동 입력에서는 거래처코드가 거래처 목록에 없으면 승인을 막고 담당자에게 선택을 요청하는 방식으로 다룹니다.
- 매칭표매핑표, 대응표
서로 다른 이름이나 열을 우리 회사 기준 하나로 연결해 둔 표.
발주서 입력에서는 거래처별 품목명을 우리 품목코드에 연결하고, 주문 합치기에서는 판매처별 열 이름을 공통 열에 연결합니다. 처음에는 시스템이 후보를 보여 주고 담당자가 고르며, 고른 결과가 표에 쌓여 같은 이름은 다음부터 자동으로 맞춰집니다. 같은 1박스라도 거래처마다 낱개 수가 다를 수 있어 거래처별로 따로 둡니다.
AI·문서
- OCR
이미지나 스캔 문서 속 글자를 읽어 텍스트로 바꾸는 기술.
팩스나 PDF 발주서를 ERP 전표 초안으로 바꿀 때 첫 단계로 씁니다. 인쇄된 표는 대부분 맞게 읽지만 손글씨 수량, 흐린 팩스, 도장이 겹친 칸은 틀리기 쉽고, 틀려도 그럴듯한 숫자를 내놓습니다. 그래서 결과를 그대로 ERP에 넣지 않고, 글자 읽기와 품목 매칭을 나눈 뒤 확신이 낮은 칸만 사람이 확인하게 만듭니다.
- 확신도
OCR이나 AI가 결과를 얼마나 자신 있게 냈는지 나타내는 값.
OCR 결과에는 글자나 칸마다 이런 값이 함께 나오는 경우가 많습니다. 기준보다 낮은 칸을 표시해 사람이 그 칸만 원본과 대조하게 하면 전체를 다시 치지 않아도 됩니다. 다만 확신도가 높아도 틀릴 수 있어서 손글씨 칸 항상 표시, 단가 × 수량과 금액 검산 같은 규칙을 함께 씁니다.
- 답변 초안AI 초안
AI가 고객 문의를 읽고 근거 자료를 참고해 먼저 써 두는 답변 문안.
쇼핑몰 CS에서는 문의를 배송, 교환·반품, 사이즈, 기타로 나누고 주문 상태, 배송 조회 결과, 쇼핑몰 규정 문서를 근거로 초안을 만듭니다. 규정 문서에 없는 내용은 확인 후 안내한다고 쓰도록 지시해 두면 규정을 지어내는 일을 줄일 수 있습니다. 담당자는 초안과 근거를 한 화면에서 보고 고친 뒤 보내며, 고친 내용은 규정 문서와 지시문을 다듬는 데 씁니다.
도입·운영
- 사람 승인 단계승인 단계, 승인 화면
자동으로 만든 결과를 외부 시스템이나 고객에게 보내기 전 담당자가 확인하고 승인하는 단계.
ERP 전표, 고객 답변처럼 한 번 나가면 되돌리기 어려운 결과에 둡니다. 승인 화면은 문제 있는 건을 위로 올리고, 원본과 초안을 나란히 보여 주고, 누가 언제 승인했는지 기록을 남기는 것이 기본입니다. 몇 주 동안 거의 고칠 일이 없던 유형만 골라 자동 발송으로 바꾸는 식으로 범위를 넓힙니다.
- 병행 운영
기존 방식과 자동화 결과를 일정 기간 나란히 돌려 비교하는 도입 단계.
보통 1~2주 동안 사람이 하던 결과와 자동화 결과를 같이 만들어 차이를 확인합니다. 이 기간에 샘플 파일에 없던 예외가 드러나고, 처리 못 한 줄이 어디로 모이는지도 점검할 수 있습니다. 병행 운영 없이 바로 바꾸면 첫 오류가 난 날 신뢰를 잃고 손작업으로 돌아가는 경우가 많아, 견적서에 이 기간이 들어 있는지 확인합니다.
개인정보·계약
- 개인정보 처리 위탁처리 위탁, 위탁 계약, 수탁자
회사(위탁자)가 고객 개인정보를 다루는 업무를 다른 업체(수탁자)에게 맡기는 것.
개인정보 보호법 제26조에 따라 위탁은 문서로 해야 하고, 목적 외 처리 금지, 기술적·관리적 보호조치 등 법령이 정한 내용을 계약서에 넣어야 합니다. 위탁자는 수탁자를 교육하고 처리 현황을 점검하는 등 감독할 책임도 집니다. 자동화 업체가 주문 파일을 받거나 자기 서버에서 API로 주문을 가져오거나 운영 중에 주문 내역을 볼 수 있다면 위탁으로 보고 계약해 두는 편이 안전합니다.
- 개인정보 처리방침처리방침
회사가 개인정보를 어떻게 수집·이용·위탁·보관하는지 정보주체에게 공개하는 문서.
업무를 위탁하면 위탁 업무의 내용과 수탁자를 정보주체가 언제든 쉽게 확인할 수 있게 공개해야 하며, 쇼핑몰은 보통 처리방침 안 위탁 표에 한 줄을 추가합니다. 택배사, 결제대행사가 이미 올라가 있는 표에 같은 형식으로 붙이면 됩니다. 국외 이전이 있으면 그 근거와 법이 정한 사항도 처리방침에 담아야 합니다.
- 국외 이전
개인정보를 해외로 제공하거나 해외 업체에 처리 위탁·보관하는 것.
개인정보 보호법 제28조의8은 국외 이전을 원칙적으로 막고, 별도 동의나 계약 이행에 필요한 처리 위탁·보관으로서 법정 사항을 처리방침에 공개한 경우 등에만 허용합니다. 해외 클라우드나 해외 AI 서비스로 주문 정보나 고객 문의를 보내는 자동화라면 여기에 해당하는지 검토해야 합니다. 계약 전에 데이터가 어느 나라 서버를 거치는지 업체에 물어보는 것이 출발점입니다.