마케팅 분석처럼 일정 수준의 오차를 허용할 수 있는 영역에서는 이런 특성이 크게 문제가 되지 않습니다. 숫자에 5% 정도 오차가 있더라도 어떤 제품이 잘 팔렸는지, 매출이 어느 방향으로 움직이는지를 파악하는 데에는 큰 지장이 없으니까요.

하지만 결산은 다릅니다. “대략 99%는 맞으니 이렇게 봐주세요”라고 넘어갈 수 있는 업무가 아니기 때문입니다. 중요한 것은 숫자 자체가 아니라 그 숫자가 어디에서 왔고, 왜 그렇게 계산됐는지를 설명할 수 있느냐에 있습니다.

이런 한계는 실제 성능에서도 확인됩니다. 재무 문서 기반 질의응답 성능을 측정한 FinanceBench에서는 GPT-4 Turbo에 검색 시스템을 결합한 구성조차 전체 문항의 81%에서 정답에 도달하지 못했습니다(Patronus AI, 2023). 아무리 모델의 성능이 좋아져도, 재무 데이터를 그대로 맡기기에는 여전히 불확실성이 남아 있는 셈입니다.

그래서 AI를 올리기 전에 먼저 해야 할 일은 모델을 고르는 것이 아니라 데이터를 검증하는 것입니다. 그리고 검증에도 순서가 있습니다.

데이터 완전성 → 수식 → 상태값과 필터 → 조인과 기간 귀속.

크게 네 단계입니다. 앞단의 검증이 빠지면 뒷단의 검증도 기준을 잃습니다. 데이터가 빠져 있다면 수식이 맞는지 확인할 대상부터 달라지고, 상태값과 필터가 잘못됐다면 그 위에서 아무리 정확하게 조인해도 올바른 결과라고 보기 어렵습니다.

결국 중요한 것은 AI가 얼마나 정확하게 답하느냐에 앞서, AI가 답을 만들어낼 수 있는 데이터 자체가 검증되어 있느냐입니다.

재무 데이터에 AI를 붙일 때 가장 큰 제약은 무엇일까요?

가장 큰 제약은 확률에 기반해 답을 생성하는 구조만으로는 숫자의 완결성을 보장하기 어렵다는 점입니다.

주문 데이터와 정산 데이터를 ChatGPT 같은 LLM에 넣고 “알아서 매칭해 줘”라고 요청하는 것 자체는 어렵지 않습니다. 다만 그 결과를 그대로 신뢰하기에는 한계가 있습니다. AI는 정해진 로직을 예외 없이 실행하는 대신, 주어진 정보를 바탕으로 가장 가능성 높은 답을 만들어내기 때문이죠. 이 과정에서 할루시네이션(AI 환각)이 발생하면 실제 데이터와 다른 숫자가 결과로 나올 수도 있습니다.

FinanceBench는 SEC 공시와 실적 보고서에서 추출한 1만 건 규모의 질문·답변 쌍을 활용해 이러한 한계를 측정했습니다. 검색 시스템을 결합한 구성에서는 전체 문항의 81%에서 오답이 발생했고, 긴 컨텍스트를 사용한 구성에서도 21%가 실패했습니다(Patronus AI, 2023). 성능이 크게 개선된 구성에서도 다섯 문항 중 하나는 놓친 셈입니다.

물론 최근 모델은 상황에 맞는 코드를 직접 작성하고 실행한 뒤, 그 결과까지 확인하는 수준으로 발전했습니다. 그렇다고 재무 업무의 제약까지 사라진 것은 아닙니다. 정산과 마감에 필요한 모든 맥락이 데이터로 주어지는 것은 아니기 때문입니다.

실제 업무에는 회사마다 반복해서 나타나는 고유한 패턴이 있습니다. 대표적인 것이 예외 처리죠. 담당자는 그동안 쌓아온 업무 경험과 배경지식을 바탕으로 예외 상황을 판단합니다.

“이 데이터가 안 맞으면 저쪽을 확인해서 맞추면 된다.”
“이건 원래 안 맞을 수밖에 없는 데이터라 다른 방식으로 검증한다.”

담당자에게는 자연스러운 판단이지만, 그 배경에 있는 맥락까지 AI에게 전달하기는 쉽지 않습니다. 무엇을 알고 있는지조차 명확하게 정리되어 있지 않은 암묵지인 경우가 많아서입니다.

물론 이런 맥락을 AI에게 전달하는 방법은 있습니다. 하지만 필요한 정보를 하나도 빠뜨리지 않고 구조화하는 것부터 만만치 않습니다. 설령 모든 정보를 전달하더라도 AI가 확률에 기반해 답을 생성한다는 본질까지 달라지는 것은 아니고요.

그래서 재무 자동화에서 중요한 것은 AI에게 얼마나 많은 일을 시키느냐가 아닙니다. 오히려 AI가 확률적으로 답을 만들어내도 되는 영역과, 정해진 로직에 따라 반드시 검증해야 하는 영역을 어디에서 나눌 것인지가 핵심입니다.

결국 재무 자동화의 출발점은 AI의 역할을 최대한 넓히는 데 있지 않습니다. AI가 판단해도 되는 일과 반드시 로직으로 검증해야 하는 일을 구분하는 것, 그 경계를 설계하는 데서 시작합니다.

같은 5% 오차가 마케팅 분석에서는 괜찮고 결산에서는 안 되는 이유는 무엇일까요?

오답으로 인해 발생하는 비용이 서로 다르기 때문입니다.

예를 들어 최근 매출 추이를 AI에게 보여주고 패턴을 분석해 달라고 하거나, 어떤 제품이 가장 많이 팔렸는지, 어떤 항목에서 가장 큰 비용이 발생했는지를 물어보는 상황을 생각해 보겠습니다. 이런 분석에서는 원 단위까지 정확한 숫자만을 바탕으로 해야 의미 있는 답을 얻을 수 있는 것은 아닙니다.

정확도가 95% 수준이더라도 큰 흐름이 달라지지 않는다면 분석과 해석에는 큰 문제가 없습니다. 일부 잘못된 답이 나오더라도 그로 인한 비용은 판단이 조금 늦어지거나 한 번 더 확인하는 정도에 그칠 수 있습니다.

하지만 결산에는 같은 기준을 적용하기 어렵습니다. 모든 전표와 주문을 회계 기준에 따라 설명할 수 있어야 하고, 설명하기 어려운 데이터가 있다면 관련 증빙을 갖춰 별도로 소명해야 합니다.

오차가 일정 수준을 넘어가면 감사 과정에서 추가적인 검토와 소명이 필요한 상황도 생길 수 있습니다. 이때 중요한 개념이 중요성(materiality)입니다. 국제감사기준 ISA 320은 중요성 금액을 특정 수치로 정해두기보다 전문가적 판단에 맡기고 있습니다. 다만 실무에서는 세전이익의 5%, 매출의 0.5~1% 등이 관행적인 참고 기준으로 활용되기도 합니다.

그런데 AI에게 이런 업무를 맡기면 또 다른 문제가 생깁니다. AI가 만들어내는 것은 가장 그럴듯한 답이지, 반드시 소명할 수 있는 답은 아니기 때문입니다.

그럴듯한 답과 실제 데이터를 근거로 설명하고 소명할 수 있는 답은 전혀 다릅니다.

결국 여기서 중요한 질문은 "AI가 답을 낼 수 있는가?"가 아닙니다. "AI가 만든 결과에 어떻게 신뢰를 부여할 것인가?"입니다.

정산 데이터를 신뢰하려면 무엇부터 검증해야 할까요?

네 가지를 순서대로 확인해야 합니다.

단계	검증 질문	확인하지 않으면
1단계. 데이터 완전성	마켓플레이스가 제공한 요약 금액과 로데이터 합계가 일치하는가	데이터 자체가 잘못된 상태에서 모든 계산이 진행됩니다
2단계. 수식(기준)	어떤 기준으로 볼지 정하고, 그 기준에 해당하는 컬럼을 빠짐없이 담았는가	보려던 것과 다른 숫자를 보게 됩니다
3단계. 상태값·필터	마켓플레이스의 상태값 유형이 내가 확인하려는 범위를 모두 포함하는가	'완료'에 환불이 섞이거나, 유효한 정산금이 빠질 수 있습니다
4단계. 조인·기간 귀속	올바른 키로 조인됐고, 기간 귀속 기준이 명확한가	주문과 정산이 어긋나고, 누락을 발견하기 어려워집니다

이 네 단계에는 하나의 공통점이 있습니다. “데이터를 어떻게 분석할까?”보다 먼저 “지금 보고 있는 데이터 자체를 믿을 수 있는가?”를 확인한다는 것입니다.

순서를 지키는 이유도 여기에 있습니다. 데이터 완전성이 확보되지 않았다면 수식이 맞는지 검증하기 전에 이미 대상 데이터부터 잘못될 수 있습니다. 수식과 상태값의 기준이 정리되지 않은 상태에서는 조인 결과가 맞는지 판단할 기준을 세우기도 어렵고요.

더 엄밀하게 들여다보면 검증 단계를 더 세분화할 수도 있습니다. 하지만 이 네 가지를 순서대로 통과하고 나면 비로소 같은 데이터를 놓고, 같은 기준으로 이야기할 수 있는 상태가 만들어집니다.

그때부터 데이터 분석이 의미를 갖습니다. 무엇을 분석할지 결정하고, 원하는 방식으로 데이터를 가공하고, 그 결과를 신뢰할 수 있는 것 역시 그 전에 데이터가 검증되어 있기 때문입니다.

1단계와 2단계에서는 무엇을 확인할까요?

핵심은 두 가지입니다. 데이터가 올바르게 들어와 있는지, 그리고 그 데이터를 올바른 기준으로 계산하고 있는지를 확인하는 것입니다.

① 데이터가 제대로 들어왔는가

마켓플레이스는 정산서마다 총 매출액과 같은 요약 숫자를 함께 제공합니다. 이번 달 정산 금액이 1억 원으로 표시돼 있다면, 로데이터에 바로 필터를 적용하기보다 해당 컬럼을 먼저 합산해 실제로 1억 원이 재현되는지부터 확인해야 합니다.

정산서 한 건만 놓고 보면 형식적인 절차처럼 느껴질 수 있습니다. 하지만 실제 마감에서는 한 달, 분기, 연 단위처럼 사람이 의미 있다고 보는 기간을 기준으로 데이터를 나눠 확인합니다. 여기서 문제가 생깁니다. 정산서가 발행되는 주기와 회계상 확인하려는 기간이 항상 일치하지 않기 때문입니다. 한 달에 정산서가 여러 건 발행될 수도 있고, 하나의 정산서가 두 개 이상의 월에 걸쳐 있을 수도 있습니다.

따라서 한 달 단위로 데이터를 확인한다면 단순히 해당 월의 데이터를 필터링하는 것만으로는 부족합니다. 각 구간이 서로 겹치거나 빠진 부분은 없는지, 해당 기간에 속하는 정산서를 모두 합쳤을 때 정산서의 요약 숫자와 정확히 일치하는지까지 확인해야 합니다.

결국 데이터 완전성 검증의 핵심은 하나입니다. 보고 싶은 기간의 데이터를 빠짐없이, 중복 없이 가져왔는지 먼저 확인하는 것입니다.

② 어떤 기준으로 계산하고 있는가

기간에 맞는 데이터를 준비했다면, 다음은 어떤 기준으로 숫자를 계산할 것인지를 정하는 단계입니다.

예를 들어 매출 금액을 상품 가액 그대로 볼지, 프로모션 금액을 차감한 금액으로 볼지부터 명확해야 합니다. 특히 프로모션은 마켓플레이스마다 정의와 처리 방식이 달라 주의가 필요합니다. 마켓플레이스가 부담하는 금액과 최종적으로 브랜드가 부담하는 금액이 각각 존재하기 때문이죠.

기준을 정했다면 그에 해당하는 데이터가 실제로 모두 포함되어 있는지도 확인해야 합니다. 같은 ‘마켓플레이스 부담 프로모션’이라도 실제 데이터에서는 여러 컬럼으로 나뉘어 제공되는 경우가 있기 때문입니다.

여기서 한 단계만 건너뛰어도 문제가 생깁니다. 수식을 만드는 일 자체는 정확하게 수행할 수 있지만, 정작 확인하려던 것과 다른 숫자를 정확하게 계산할 수도 있습니다.

결국 수식 검증에서 중요한 것은 계산식이 맞는지만 확인하는 것이 아닙니다. 무엇을 계산해야 하는지 그 기준부터 맞춰야, 계산 결과 역시 의미를 갖습니다.

3단계와 4단계에서는 무엇을 확인할까요?

앞의 두 단계에서 데이터와 계산 기준을 정했다면, 이제는 그 기준이 실제 데이터에 제대로 적용되고 있는지를 확인할 차례입니다. 필터가 의도한 범위를 빠짐없이 포함하는지, 서로 다른 데이터셋을 연결할 때 키와 기간이 어긋나지 않는지를 살펴봅니다.

③ 상태값과 필터가 내 의도를 제대로 반영하는가

필터는 실무에서 가장 익숙하게 사용하는 도구이면서, 동시에 의도와 가장 쉽게 어긋나는 도구이기도 합니다. 익숙한 만큼 별다른 의심 없이 적용하기 쉽지만, 필터의 기준이 되는 상태값 자체를 잘못 이해하면 결과 전체가 달라질 수 있습니다.

그래서 필터를 적용하기 전에 먼저 마켓플레이스가 어떤 상태값을 제공하는지, 각각의 상태가 실제로 무엇을 의미하는지부터 살펴봐야 합니다. 내가 확인하려는 범위를 해당 상태값들이 빠짐없이 포함하고 있는지도 함께 확인할 필요가 있고요.

예를 들어 어떤 마켓플레이스에서는 주문 상태가 ‘완료’로 표시돼 있어도 환불이나 반품 건이 함께 포함될 수 있습니다. 반대로 ‘반품’ 상태라고 해서 해당 주문과 관련된 정산금이 모두 사라지는 것도 아닙니다. 일부 금액은 여전히 유효한 정산금으로 남아 있을 수 있어서입니다.

결국 중요한 것은 ‘완료’, ‘반품’ 같은 상태값의 이름이 아니라 그 안에 어떤 데이터가 포함되는지입니다. 마켓플레이스마다 상태값을 정의하고 처리하는 방식이 다른 만큼, 이름만 보고 필터를 걸기보다 각 상태의 실제 의미와 포함 범위를 확인한 뒤 필터를 구성하는 것이 핵심입니다.

④ 조인과 기간 귀속이 올바른가

여러 데이터셋을 하나로 연결해 비교할 때 필요한 검증입니다. 가장 흔한 사례가 주문 데이터와 정산 데이터를 하나로 연결하는 조인이죠.

여기서 확인할 것은 두 가지입니다. 올바른 키값으로 연결했는지, 그리고 내가 보려는 기준에 맞게 기간을 귀속했는지입니다.

예를 들어 월 단위로 데이터를 나눠 보겠습니다. 주문은 이번 달에 발생했지만 실제 정산은 다음 달에 이뤄질 수 있습니다. 취소나 부분 환불이 발생하면 관련 금액이 이후 정산에 반영되는 경우도 있기 때문입니다.

따라서 조인에 앞서 어떤 데이터를 만들 것인지부터 정의해야 합니다. ‘해당 주문과 관련된 모든 정산 건을 포함한 데이터’인지, 아니면 ‘해당 월에 실제로 발생한 정산 건만 포함한 데이터’인지에 따라 같은 주문과 정산 데이터를 연결하고도 결과는 달라집니다.

반대 방향의 검증도 필요합니다. 정산 데이터를 기준으로 봤을 때 빠진 건은 없는지, 예상하지 못한 기간의 데이터가 연결된 것은 아닌지를 확인하는 과정입니다. 예를 들어 이전 연도에 발생한 주문이 연결됐다면 단순한 데이터 오류가 아니라 그 데이터를 어떤 기준으로 처리할 것인지 회사의 정책까지 확인해야 하는 경우가 있습니다.

이 단계가 번거로운 이유도 여기에 있습니다. 단순히 두 데이터를 연결하는 것으로 끝나는 것이 아니라, 무엇을 기준으로 연결했고 그 결과를 어느 기간에 귀속할 것인지까지 설명할 수 있어야 하기 때문입니다.

결국 데이터에 대한 신뢰는 이런 불편한 지점을 하나씩 확인하는 과정에서 만들어집니다. 조인과 기간 귀속 검증이 필요한 이유도 바로 여기에 있습니다.

검증을 통과한 뒤에 남는 질문

네 단계를 모두 통과했다면, 이제야 “이 데이터로 무엇을 볼 것인가”를 고민할 수 있습니다. 그런데 여기서 한 가지 구분이 필요합니다. 검증과 마감을 같은 로직으로 처리해도 될까요?

두 작업은 목적부터 다릅니다. 마감은 언제 컷오프를 잡느냐에 따라 결과가 달라질 수 있지만, 검증은 시점이 달라지더라도 같은 기준에서 동일한 결과를 확인할 수 있어야 합니다.

포트원은 마켓플레이스 정산 데이터를 이 네 단계에 따라 검증하는 구조를 만들고 있습니다. 검증을 건너뛴 채 분석부터 시작하는 대신, 검증을 통과해 신뢰할 수 있는 데이터를 먼저 만들고 그 위에서 분석이 시작되도록 하는 것이 목적입니다.

그렇다면 검증된 데이터를 실제 마감에 적용했을 때는 무엇이 달라질까요?

2편에서는 검증과 마감을 왜 서로 다른 모드로 분리해야 하는지, 그리고 사람이 열흘 동안 엑셀로 진행했던 마감을 기계가 동일한 룰셋으로 다시 실행했을 때 무엇이 드러났는지를 다룹니다.

자주 묻는 질문 (FAQ)

Q1. 주문 데이터와 정산 데이터를 ChatGPT에 넣고 매칭해 달라고 해도 되나요?

탐색 목적으로는 유용하게 활용할 수 있습니다. 다만 그 결과를 마감의 근거로 사용하는 것은 신중해야 합니다. LLM은 확정된 로직을 그대로 실행하기보다 주어진 정보를 바탕으로 가장 가능성 높은 답을 생성하는 구조이기 때문입니다. 따라서 실제로는 매칭되지 않아야 할 건이 그럴듯한 상대 건과 연결될 가능성도 남아 있습니다. FinanceBench에서 검색 시스템을 결합한 GPT-4 Turbo 구성이 81% 실패한 것도 같은 맥락에서 볼 수 있습니다(Patronus AI, 2023).

Q2. 요즘 AI는 코드를 직접 작성하고 실행하는데, 그래도 제약이 남나요?

코드를 실행할 수 있다는 것과 업무의 맥락을 이해한다는 것은 별개의 문제입니다. AI가 코드를 작성하고 실행 결과까지 확인하더라도, 회사마다 다른 예외 처리 기준과 내부 정책을 모두 알고 있는 것은 아닙니다. 담당자가 "이건 원래 안 맞는 데이터라 다른 방식으로 본다"고 판단하는 지점을 빠짐없이 전달하는 것도 현실적으로 쉽지 않습니다.

Q3. 정산 데이터를 검증할 때 가장 먼저 확인해야 하는 것은 무엇인가요?

마켓플레이스가 제공하는 요약 금액이 로데이터 합계로 재현되는지부터 확인합니다. 정산서에 이번 달 정산 금액이 1억 원으로 표시돼 있다면, 필터를 적용하기 전에 해당 컬럼을 합산해 같은 숫자가 나오는지 먼저 확인합니다. 여기서부터 숫자가 맞지 않는다면, 그 데이터를 기반으로 진행한 계산과 분석 역시 신뢰하기 어렵습니다.

Q4. 주문 상태가 '완료'인 건만 걸러도 정산 대상 매출을 볼 수 있지 않나요?

마켓플레이스마다 다릅니다. 어떤 곳에서는 '완료' 상태에 환불이나 반품 건이 포함될 수 있고, 반대로 '반품' 상태인데도 여전히 유효한 정산금이 포함되는 경우도 있습니다. 마켓플레이스마다 상태값을 정의하고 처리하는 방식이 다른 만큼, 상태값의 의미와 채널별 정책을 먼저 확인한 뒤 필터를 구성하는 것이 안전합니다.

출처

Patronus AI, FinanceBench: A New Benchmark for Financial Question Answering, 2023
ISA 320, Materiality in Planning and Performing an Audit — 중요성 관련 관행적 기준선 참고

PortOne Close 도입문의 →