발주서 → ERP 전표 데모는 어떻게 만들었나: AI가 읽고 사람이 확인하는 구조

루코 웍스의 발주서 → ERP 전표 데모에서 AI는 발주서를 읽어 정해진 칸에만 답을 채우고, 확신이 낮은 줄은 노란색 "확인 필요"로 표시해 담당자에게 넘깁니다. 단가와 금액은 AI가 계산하지 않고 페이지가 단가표로 계산하며, 담당자가 승인한 전표만 ERP로 보낼 데이터가 됩니다. 이 글은 그 구조를 만든 방식과 이유를 정리한 기술 노트입니다.

데모는 어떤 상황을 보여 주나요?

가상의 식자재 도매상 "루코 푸드"가 하루 동안 받은 발주서를 처리하는 화면입니다. 거래처는 3곳, 품목은 9개로 일부러 작게 잡았습니다. 왼쪽에 받은 원본, 오른쪽에 판매 전표 초안이 나란히 뜹니다.

이 세 건은 미리 만든 처리 결과를 보여 줍니다. 처음 들어온 방문자에게 매번 AI를 호출하면 비용이 들고 결과도 매번 조금씩 달라지기 때문입니다. 흐름을 이해하는 데는 고정된 예시가 낫습니다. 직접 써 보고 싶은 방문자는 "내 발주서 붙여 넣기"에 메일이나 엑셀 표를 붙여 넣으면 됩니다. 이때만 AI가 실시간으로 읽습니다.

붙여 넣은 발주서를 AI가 읽는 방식

브라우저는 붙여 넣은 글을 루코 웍스 사이트의 서버 함수로 보내고, 서버 함수가 Anthropic의 Claude Haiku 모델을 호출합니다. AI 서비스의 키는 서버에만 있고 방문자 브라우저에는 내려가지 않습니다.

여기서 중요한 장치는 AI가 자유롭게 문장으로 답하지 못하게 한 것입니다. 서버 함수는 "발주서 1건을 판매 전표 초안으로 기록한다"는 도구 하나를 정해 두고, AI가 반드시 그 도구의 입력 형식으로만 답하도록 지정합니다. 형식은 다음과 같습니다.

거래처와 품목코드 칸은 마스터에 있는 값만 고를 수 있게 막아 두었습니다. AI가 그럴듯한 가짜 코드를 지어낼 길을 형식 단계에서 닫은 것입니다. 지시문에도 "원문에 없는 품목이나 수량을 지어내지 않는다", "맞는 품목이 없으면 코드를 비우고 확신도를 낮음으로 둔다"는 규칙을 넣었습니다. 발주서가 아닌 글을 넣으면 품목 줄을 비우고 "발주서가 아닌 입력입니다"라고 답하게 했습니다.

AI 응답이 길어져 중간에 잘리면 품목 몇 줄이 빠진 채 돌아올 수 있습니다. 서버 함수는 필요한 칸이 모두 있는지 확인하고, 하나라도 빠졌으면 결과를 내보내지 않고 "다시 시도해 주세요"라고 답합니다. 일부만 맞는 전표가 정상처럼 보이는 것을 막으려는 처리입니다.

TIPAI로 문서를 읽는 자동화를 검토할 때는 "AI가 고를 수 있는 값이 미리 정해져 있나요?"라고 물어보세요. 품목코드나 거래처처럼 정답 목록이 있는 칸은 목록 밖의 값을 못 쓰게 막을 수 있습니다.

확신이 낮은 줄은 화면에서 어떻게 다루나요?

AI가 확신도를 낮음으로 준 줄, 그리고 품목코드를 비운 줄은 노란색 "확인 필요"로 표시되고 근거 문장이 함께 보입니다. 예를 들어 "손글씨 '2O'를 20으로 읽었습니다. 이 거래처의 무 평소 주문량은 15~25개입니다" 같은 식입니다. 담당자는 이 줄에서 품목을 목록에서 다시 고르거나, 수량을 고치거나, "이번 전표에서 빼기"를 고를 수 있습니다.

확신이 높은 줄은 그대로 둡니다. 모든 줄을 다시 보게 만들면 자동화한 의미가 없기 때문입니다. 대신 노란 줄이 남아 있으면 승인 버튼이 "이대로 맞아요"로 바뀌어, 담당자가 AI 판단을 본 뒤에 넘어갔다는 기록이 남습니다. 발주서에서 거래처를 찾지 못했다면 거래처를 먼저 고르기 전에는 승인 버튼이 눌리지 않습니다.

단가와 금액은 AI 결과와 따로 계산합니다. 페이지는 거래처별 단가표에서 품목 단가를 찾아 수량을 곱하고, 공급가액에 부가세 10%를 더해 합계를 냅니다. 같은 품목도 거래처마다 단가가 다르기 때문에 이 계산은 표에서 찾는 편이 정확합니다.

담당자가 고친 결과가 쌓이는 방식

전표를 승인하면 담당자가 확인한 노란 줄이 "다음부터 자동으로 맞춥니다: '한빛마트 강서점 양파 큰망' → 양파 15kg(망)" 같은 형태로 화면에 쌓입니다. 거래처 이름과 품명을 함께 저장하는 이유는 같은 "큰망"이라도 거래처마다 가리키는 규격이 다를 수 있어서입니다. 취급하지 않아 뺀 품목은 "취급 안 함"으로 남습니다.

데모에서는 이 매칭표가 화면을 보는 동안에만 유지됩니다. 실제 구축에서는 고객사 품목 마스터와 거래처별 단가표를 받아 시작하고, 담당자가 고친 품명을 계속 쌓아 다음 발주서부터 자동으로 맞춥니다. 처음 몇 주는 고치는 줄이 많고 점점 줄어드는 흐름입니다. 매칭표를 만드는 단계는 발주서 ERP 판매 전표 글에 표로 정리해 두었습니다.

승인한 전표가 나가는 형태

데모는 두 가지 출력을 보여 줍니다.

• ERP 오픈 API 판매 입력 형태: "ERP로 보내는 데이터 보기"를 열면 일자, 거래처코드, 창고, 품목코드, 수량, 단가, 공급가액, 부가세, 적요가 담긴 데이터를 볼 수 있습니다. 실제 필드와 필수 여부는 고객사 ERP 설정에 맞춰 조정합니다.
• ERP 엑셀 일괄 업로드 양식: 승인한 전표를 모아 판매 입력 화면의 엑셀 일괄 업로드에 쓰는 파일로 내려받습니다. 열 구성은 고객사의 판매 입력 화면 설정에 맞춰 바꿉니다.

API를 쓰면 승인한 전표가 바로 들어가고, 엑셀 올리기를 쓰면 담당자가 매일 파일을 받아 직접 올립니다. 어느 쪽을 먼저 쓸지는 ERP 오픈 API와 사람 승인 글에서 기준을 다뤘습니다. 데모는 실제 ERP에 접속하지 않으며, 승인 버튼은 보낼 데이터를 만들어 보여 주기만 합니다.

입력한 발주서는 어디에 남나요?

붙여 넣은 발주서는 처리에만 쓰고 저장하지 않습니다. 서버 함수는 오류가 나도 원문을 기록에 남기지 않고, 방문자에게는 "AI 처리 중 문제가 생겼습니다" 같은 일반 안내만 돌려줍니다. AI 서비스가 돌려준 내부 오류 내용은 화면에 그대로 노출하지 않습니다. 데모는 공개 페이지라 한 번에 넣을 수 있는 글자 수와 하루 사용 횟수를 정해 두었습니다.

TIP데모나 시험 단계에서 실제 발주서를 써 보고 싶다면 거래처 이름, 담당자 이름, 전화번호를 지운 사본을 쓰세요. 품명과 수량 표기만 남아 있어도 AI가 얼마나 맞추는지 충분히 볼 수 있습니다.

실제 구축에서는 무엇이 달라지나요?

실제 구축에서는 고객사가 발급한 ERP API 인증키로 판매 전표를 넣거나, API를 쓰지 않고 매일 엑셀 올리기 파일로 받아 직접 올리는 방식 중에서 고릅니다. 품목 마스터와 거래처별 단가표가 출발점입니다. 더존, 경영박사 같은 ERP든 사내 엑셀 장부든 시스템이 받는 엑셀 양식이 있으면 거기에 맞춰 만들고, 그것도 없으면 화면 자동 입력을 검토합니다.

AI는 초안을 만들고, 장부에 들어가는 결정은 담당자의 승인 버튼에서 일어납니다.