ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 이미지 읽는 AI에 영수증을 맡기기 전, 무엇을 대조해야 할까
    AI Agent 2026. 9. 23. 09:04
    728x90
    반응형

    빈 영수증 모양 종이 위의 돋보기와 연필, 무늬 없는 금속 원판
    추출한 내용을 원문과 세밀하게 대조하는 AI 생성 개념 이미지입니다.

    영수증 추출 AI는 총액만 보지 말고 품목·수량·단가·합계를 원문과 각각 대조한 뒤 사용할 범위를 정하세요.

    영수증 사진을 넣자 AI가 깔끔한 JSON을 반환합니다. 총액도 맞습니다. 이 정도면 가계부나 정산 자료에 바로 넣어도 될 것 같지만, 총액은 맞아도 품목 수량이나 단가가 틀릴 수 있습니다.

    이미지를 입력받는 기능과 영수증의 모든 값을 정확하게 옮기는 능력은 다릅니다. 이 글은 2026년 9월 13일 Ollama와 문서 추출 도구의 공식 문서를 바탕으로 검수 절차를 설계합니다. 실제 영수증이나 개인정보를 업로드하지 않았으며, 아래 숫자와 추출 기록은 모두 가상 예시입니다.

    이미지 입력 지원은 정확도 검증의 출발점입니다

    Ollama의 비전 기능은 이미지와 텍스트를 함께 넣어 이미지에 대한 설명이나 질문 응답을 받을 수 있게 합니다. REST API와 SDK의 이미지 전달 방식도 구분돼 있습니다. 하지만 이미지 입력을 지원한다는 안내 자체가 한국어 영수증의 필드별 정확도를 보장하지는 않습니다. Ollama 비전 기능

    영수증 전용 추출 도구도 총액 하나만 다루지 않습니다. 예를 들어 Document Intelligence는 거래 날짜, 상점 정보, 세금과 총액, 품목별 수량·단가·금액 같은 구조를 구분합니다. 사용할 도구의 모델 버전과 실제 지원 필드는 따로 확인해야 합니다. 영수증 추출 필드

    이 구분은 도구를 고르는 것보다 먼저 필요합니다. 총액만 모으는 가계부인지, 품목별 지출을 나누는 기록인지, 사람이 원문을 확인할 정산 초안인지에 따라 틀리면 안 되는 필드가 달라집니다.

    “영수증을 잘 읽는다”라는 한 문장 대신 사용할 목적과 확인할 항목을 적어 두면 검수도 구체적으로 할 수 있습니다. 총액만 필요하더라도 통화·날짜·중복 영수증 여부를 놓치면 기록 전체가 틀어질 수 있습니다.

    먼저 원문을 읽을 수 있는 사진인지 확인합니다

    사진에는 영수증의 위아래와 필요한 품목 줄이 모두 들어 있어야 합니다. 합계 부분만 선명하고 중간 품목이 잘렸다면 AI가 그 부분을 복원해 줄 것이라고 기대하지 않습니다.

    빛 반사, 접힌 자리, 흐린 인쇄 때문에 숫자를 사람이 읽기 어렵다면 모델 결과도 원문 대조가 어렵습니다. 이런 경우에는 확대해서 확인하거나 다시 촬영할 수 있는지 봅니다. 문서 추출 공식 안내도 문서마다 선명한 사진이나 고품질 스캔을 제공하도록 권합니다. 입력 이미지 품질

    품목 영역을 잘라서 추가로 보여 줄 때도 전체 영수증과 연결을 유지합니다. 잘린 부분만 보면 품목 금액과 할인, 이전 줄의 수량을 잘못 연결할 수 있기 때문입니다. 원본 사진과 검토용 부분 이미지를 다른 자료로 관리하는 편이 좋습니다.

    개인 이름, 전화번호, 회원번호, 카드 관련 정보가 있다면 외부 서비스에 보내기 전에 필요한 범위인지 검토합니다. 가림 처리를 했다면 필요한 숫자까지 가려지지 않았는지도 확인합니다. 글자 생성형 보정으로 읽히지 않는 숫자를 새로 만들어 넣는 것은 원문 개선이 아니라 증거 변경이 될 수 있습니다.

    가상의 영수증으로 대조 순서를 만들어 봅니다

    설명용 영수증에 다음 내용이 있다고 하겠습니다. 모든 금액은 원 단위이고, 품목 금액에 세금이 포함돼 있으며 별도로 더할 세금은 없다는 가정입니다. 실제 매장의 세금 처리 방식을 설명하는 예시는 아닙니다.

    사과     수량 2     단가 1,500     금액 3,000
    우유     수량 1     단가 2,400     금액 2,400
    할인                                -400
    결제 합계                           5,000
    

    첫째, 원문에서 품목 줄을 나눕니다. 사과와 우유가 각각 하나의 품목인지, 할인은 별도 조정 항목인지 구분합니다. 줄이 겹쳐 보인다고 할인 금액을 우유 단가에 합치지 않습니다.

    둘째, 수량과 단가를 곱해 품목 금액을 대조합니다. 사과는 2×1500=3000, 우유는 1×2400=2400입니다. 이 계산은 가상의 입력에 대한 산술 확인이지 OCR 성공률을 측정한 결과가 아닙니다.

    셋째, 품목 합계 5400에서 할인 400을 빼면 결제 합계 5000과 맞는지 확인합니다. 중요한 것은 숫자를 맞추는 것이 아니라 원문에서 할인이라고 읽은 항목을 올바른 방향으로 적용했는지입니다.

    이 순서를 거꾸로 하면 위험합니다. 총액이 5000이라는 이유로 읽히지 않는 단가를 역산해 채우면 원문 추출과 추론이 섞입니다. 계산으로 가능한 값이라고 해서 영수증에 실제로 적힌 값이라는 증거가 되지는 않습니다.

    합계가 맞아도 수량과 단가가 틀릴 수 있습니다

    AI가 사과를 “수량 1, 단가 3000, 금액 3000”으로 읽었다고 가정해 보겠습니다. 품목 금액과 최종 결제 합계는 여전히 맞습니다. 하지만 사과의 수량과 단가는 원문과 다릅니다.

    총액 일치만 검사하면 이 오류를 통과시킵니다. 품목별 구매 수량이나 단가를 분석하려는 기록에서는 중요한 오류입니다. 산술 검사는 일관성을 확인하는 장치이지 모든 필드의 정확성을 대신하지 않습니다.

    반대로 수량과 단가가 맞는데 품목 금액이 다른 경우도 있습니다. 묶음 할인이나 중량 단가, 단위 환산이 있는지 원문을 먼저 확인해야 합니다. 모든 영수증이 단순한 정수 수량×개당 가격 구조라고 가정하지 않습니다.

    할인 전 금액, 실제 결제액, 받은 현금, 거스름돈도 같은 종류의 합계가 아닙니다. 가장 큰 숫자나 마지막 숫자를 무조건 결제 총액으로 선택하면 안 됩니다. 필드 이름과 그 주변 문맥을 함께 읽어야 합니다.

    원문 문자열과 사용할 숫자를 따로 보관합니다

    검토 과정에서는 AI가 읽은 문자열과 프로그램에서 계산할 정규화 값을 분리하는 편이 좋습니다. 원문에는 “1,500원”이라고 보이지만 계산에는 정수 1500을 쓸 수 있습니다. 이 변환이 어디서 일어났는지 남겨야 나중에 오류를 찾기 쉽습니다.

    다음은 흐린 숫자가 있다고 가정한 검토 기록의 모양입니다. 특정 도구가 실제로 반환한 JSON이 아니라 직접 설계한 예시입니다.

    {
      "field": "unit_price",
      "raw_text": "1?00",
      "value": null,
      "review_status": "needs_review",
      "evidence": "첫 번째 품목의 단가 영역"
    }
    

    value가 null인 것은 0원이라는 뜻이 아니라 확인되지 않았다는 뜻입니다. 원문이 흐리거나 보이지 않을 때 0을 넣으면 무료 품목처럼 잘못 집계될 수 있습니다. 확인 상태와 숫자 값은 별개 필드로 두는 것이 좋습니다.

    품목마다 원문 줄이나 이미지 위치를 연결해 두면 사람이 무엇을 대조해야 할지 알 수 있습니다. 실제 도구가 좌표를 제공하지 않는다면 있는 것처럼 좌표를 만들어 내지 않고 사람이 찾을 수 있는 설명을 남깁니다.

    수정한 값도 원래 추출값을 지우고 덮어쓰기보다 원문 대조 후 정정한 기록을 구분합니다. 나중에 모델 오류인지 후처리 오류인지 분석할 때 원래 응답이 필요하기 때문입니다.

    JSON 스키마는 모양을 맞추지만 원문까지 증명하지 않습니다

    Ollama의 구조화 출력은 JSON 스키마에 맞춘 응답을 요청하고 프로그램에서 검증할 수 있게 합니다. 품목 배열, 숫자나 null, 검토 상태처럼 필요한 구조를 정의하는 데 도움이 됩니다. Ollama 구조화 출력

    하지만 수량 필드가 정수라는 조건을 만족한다고 그 정수가 원문과 같은 것은 아닙니다. 앞의 사과 수량 1도 정수 형식 검사를 통과할 수 있습니다. 스키마 검증과 원문 대조를 하나로 합치지 않습니다.

    요청 문장에는 읽히지 않는 값을 추측하지 말고 null로 남길 것, 품목 줄과 할인·세금·결제액을 구분할 것, 원문 문자열과 정규화 값을 함께 줄 것을 명시할 수 있습니다. 그래도 지시를 썼다는 이유만으로 모델이 모든 경우에 지켰다고 가정하지 않습니다.

    실제로 받은 응답을 파싱하고 필수 필드와 값의 범위를 검사한 뒤 원문과 대조합니다. 모델이 설명문으로 “정확하게 추출했습니다”라고 덧붙여도 그것은 독립된 검수 결과가 아닙니다.

    신뢰도 점수도 검토 우선순위를 정하는 자료입니다

    일부 문서 추출 도구는 단어나 필드의 confidence를 제공합니다. Document Intelligence는 이 값을 추정 확률로 설명하고, 정확성이 중요한 작업에 사람 검토를 포함할 수 있다고 안내합니다. 모든 필드에 같은 종류의 점수가 제공되는 것은 아닙니다. 정확도와 confidence 해석

    이런 도구의 문서화된 필드 점수와 일반 대화 모델이 스스로 적은 “확신도 99%”는 같은 지표가 아닙니다. 무엇을 측정한 값인지, 내가 다루는 영수증 종류에서도 그 점수와 실제 오류가 맞는지 확인해야 합니다.

    검토 우선순위는 점수뿐 아니라 영향도 함께 봅니다. 흐린 상점 설명과 흐린 결제 총액은 잘못됐을 때의 영향이 다를 수 있습니다. 금액·통화·날짜·수량 등 사용 목적에 중요한 필드는 별도로 확인 기준을 정합니다.

    본인의 자료로 자동 수용 기준을 정하려면 사람이 정답을 확인한 평가 묶음이 필요합니다. 깨끗한 한 장에서 잘 됐다는 사실로 접힘·흐림·할인·다른 매장 형식까지 같은 정확도라고 일반화하지 않습니다.

    사용할 범위와 보류할 범위를 마지막에 나눕니다

    가계부의 초안을 만드는 용도라면 AI 추출 뒤 사람이 총액·날짜·중복 여부를 확인하는 흐름을 선택할 수 있습니다. 품목 분석이 목적이라면 수량과 단가, 할인 배분까지 확인해야 하므로 검수 범위가 더 넓어집니다.

    읽히지 않는 부분이 남았다면 재촬영, 원본 확인, 수동 입력으로 넘깁니다. 원문을 확보할 수 없다면 확인되지 않은 값을 표시한 초안으로 남기고 확정 기록과 구분합니다. 이 글은 세무상 증빙 효력이나 정산 규정의 법적 판단을 다루지 않습니다.

    최종 기록에는 어떤 원본을 어떤 모델·설정으로 추출했는지, 어떤 필드를 대조했고 누가 수정·확정했는지 남기는 편이 좋습니다. 자동 추출과 확정 기록의 경계가 분명해야 나중에 금액이 맞지 않을 때 원인을 추적할 수 있습니다.

    영수증 AI의 도움은 사람이 모든 값을 처음부터 타이핑하지 않아도 된다는 데 있을 수 있습니다. 그 도움을 실제로 쓰려면 읽은 값, 계산으로 확인한 값, 아직 모르는 값을 나눠야 합니다. 총액이 맞는지에서 한 걸음 더 나아가 필요한 필드를 원문과 대조했을 때 비로소 사용할 범위를 정할 수 있습니다.

    728x90
    반응형
Designed by Tistory.