여기서 먼저 구분해야 할 것이 있습니다. 검증과 마감은 같은 작업이 아닙니다. 마감은 컷오프 시점과 회사의 정책에 따라 결과가 달라질 수 있지만, 검증은 시점이 달라져도 일관된 기준으로 이뤄져야 합니다. 두 가지를 섞어버리면 눈앞에 나타난 차이가 데이터 자체의 문제인지, 마감 기준에 따라 생긴 차이인지 구분하기 어려워집니다.

포트원 고객사 한 곳을 예로 들어보겠습니다. 이 팀이 한 달에 대사해야 하는 건수는 수백만 건, 그중 한 마켓플레이스 채널에서만 수십만 건에 달했습니다. ERP·주문·정산 데이터를 한곳에 모으고, 차지백·부분 환불·환율 차이를 유형별로 나눠 검증한 뒤, CS팀의 답변을 기다려 2차·3차 대사까지 마치고 나면 어느새 열흘 가까이 지나 있었습니다.

이 팀의 올해 2월 마감을 자동화된 콘솔에서 처음부터 다시 돌려봤습니다. 사람이 엑셀로 마감한 결과와 기계가 정해진 룰셋에 따라 계산한 결과를 나란히 놓고 비교했습니다. 차이가 나타난 곳은 이월 처리였습니다. 이월하면 안 되는 건이 다음 달로 넘어와 있었고, 반대로 이월해야 할 건이 그대로 남아 있기도 했습니다.

금액 자체가 큰 것은 아니었습니다. 문제는 이런 몇 건을 확인하는 데 담당자의 시간이 건당 1~2시간씩 들어간다는 점이었습니다. 자동화의 가치는 단순히 오류를 찾아내는 데서 끝나지 않습니다. 오류 하나를 확인하기 위해 사람이 들여야 했던 시간을 애초에 발생하지 않게 만드는 것. 그 지점에서 자동화의 더 큰 가치를 찾을 수 있습니다.

그래서 마지막에 남는 질문은 하나입니다. AI가 답을 만들어낼 수 있느냐가 아니라, 그 답을 최종 승인할 수 있는 사람이 누구냐는 것입니다.

검증과 마감을 왜 다른 모드로 분리해야 할까요?

마감은 '시점'의 영향을 크게 받는 작업이기 때문입니다.

마감은 일반적으로 월초에 전월 데이터를 기준으로 진행합니다. 그런데 바로 이 '월초'라는 시점이 결과를 바꿀 수 있습니다. 데이터를 확인하는 순간에는 주문의 상태값이 정해져 있더라도, 그 상태가 다음 달까지 그대로 유지된다는 보장은 없기 때문입니다.

예를 들어 8월 주문이 지금은 아무 문제 없어 보여도 며칠 뒤 부분 환불이 발생할 수 있습니다. 아직 배송이 완료되지 않은 주문이 다음 달에는 배송 완료 상태로 바뀔 수도 있습니다.

물론 시점이 달라져도 결과가 변하지 않도록 설계할 수 있는 로직도 있습니다. 나중에 배송이 완료됐더라도 배송 완료 시점을 기준으로 필터를 적용하면 전월 마감에는 영향을 주지 않도록 만들 수 있습니다. 다만 모든 데이터를 이런 방식으로 처리할 수 있는 것은 아닙니다.

기초·기말 잔액을 추적하는 회사라면 차이는 더 뚜렷해집니다. 특정 기준 시점의 잔액을 고정한 뒤 그 범위 안에서 마감을 진행하고, 이후 발생한 변동은 컷오프(cutoff) 이후의 데이터로 구분하는 방식으로 운영하기 때문입니다.

결국 언제 컷오프를 설정하고 전표를 마감하느냐가 하나의 기준이 됩니다. 그리고 그 기준에 따라 우리가 보는 데이터의 모습도 달라집니다. 그래서 검증과 마감의 역할을 나눠야 합니다.

Validation Mode(검증 모드) 는 상태나 시점의 변화에 영향을 받지 않는 구조를 지향합니다. 해당 월의 데이터는 해당 월의 데이터끼리만 짝지어 보여주고, 시간이 지나 상태값이 바뀌더라도 사람이 수동으로 검수할 때 적용하는 기준에 따라 데이터를 투명하게 확인할 수 있도록 하는 데 초점을 둡니다.

반면 Closing Mode(마감 모드) 는 실제 마감에 적용하는 비즈니스 로직, 즉 업무 절차와 회사 내부 정책을 함께 반영합니다. 사람이 직접 마감했을 때와 동일한 결과를 만들어내려면 실제 업무에서 적용하는 기준을 그대로 따라야 하기 때문입니다.

두 모드를 하나로 합치면 어떻게 될까요? 시점에 따라 달라지는 마감 로직이 검증 결과에도 함께 들어가게 됩니다. 그러면 지금 보이는 차이가 데이터 자체의 문제인지, 마감 시점이나 회사 정책 때문에 생긴 것인지 구분하기 어려워집니다.

검증은 시점과 무관하게, 마감은 시점과 정책을 그대로 반영하게. 두 모드를 분리해야 각각의 결과를 신뢰할 수 있습니다.

자동화 이전에는 무엇이 병목이었을까요?

앞서 소개한 팀의 한 달 마감에는 열흘 가까운 시간이 걸렸습니다. 가장 먼저 부딪히는 문제는 데이터의 양이었습니다. 한 달에 대사해야 하는 건수가 수백만 건에 달했고, 그중 한 마켓플레이스 채널에서만 수십만 건이 발생했습니다.

하지만 데이터가 많다는 것만으로 그만큼의 시간이 걸린 것은 아닙니다. ERP·주문·정산 데이터를 마감에 사용할 수 있는 형태로 한곳에 모으는 과정부터 시간이 필요했습니다. 특히 전사 ERP 자체가 대량의 데이터를 빠르게 처리하기 어려운 구조였기 때문에, 데이터를 적재하는 데만 서른 시간 가까이 걸렸습니다.

데이터를 모으고 나면 그때부터 본격적인 검증이 시작됩니다. 차이가 발생할 가능성이 있는 건을 차지백(chargeback), 부분 환불, 전체 환불, 환율 차이 등 유형별로 나눠 확인하고, 필요한 경우 유관 부서에 다시 확인을 요청합니다.

특히 CS팀의 확인이 필요한 클레임 건에서는 한 번의 검증으로 끝나지 않습니다. CS팀의 답변을 반영해 ERP 데이터를 수정하고, 수정된 데이터를 기준으로 2차 대사와 3차 대사를 다시 진행해야 합니다. 데이터를 준비하는 데 한 번, 차이를 확인하는 데 또 한 번, 수정한 뒤 다시 검증하는 데 또 한 번의 시간이 필요한 구조였습니다.

그렇다고 열흘이라는 기간이 이 팀만의 예외적인 상황은 아닙니다. Ledge가 2025년 재무 실무자 100명을 대상으로 조사한 결과, 월 마감에 5영업일을 초과하는 조직이 절반이었고 7영업일을 넘는 곳도 27%였습니다(Ledge, 2025). 여러 채널과 통화를 동시에 관리해야 하는 조직이라면 마감에 더 많은 시간이 필요한 구조입니다.

콘솔을 도입하면서 가장 먼저 바뀐 것도 이 앞단의 반복 작업이었습니다. ERP 데이터를 미리 별도 DB에 저장해두고 필요할 때 바로 불러올 수 있도록 하자, 서른 시간 가까이 걸리던 데이터 적재 작업이 두 시간 남짓으로 줄었습니다. 차이가 발생한 건도 여러 엑셀 파일을 오가며 찾을 필요 없이 한 화면에서 확인하고, 건별 이력까지 바로 따라갈 수 있게 됐습니다.

즉, 자동화가 처음 줄여준 것은 사람의 판단이 아니었습니다. 판단하기 위해 데이터를 모으고, 대조하고, 다시 확인하는 데 필요했던 시간이었습니다.

구간별로 나눠 보면 변화가 더 분명하게 보입니다.

마감 구간	자동화 이전	콘솔 도입 이후
ERP·주문·정산 데이터 적재	서른 시간 가까이	두 시간 남짓
월 대사 건수	수백만 건 (한 채널에서만 수십만 건)	동일
차이 건 확인 방식	엑셀 파일 여러 개를 XLOOKUP·SUMIF로 대조	한 화면에서 건별 이력 추적
이월 오류 1건 확인 부담	건당 1~2시간까지 소요 가능	재실행 시 자동 검출
월 마감 총 소요	열흘 안팎	반복 구간만 단축, 판단 구간은 잔존

표에서 하나의 패턴을 확인할 수 있습니다. 줄어든 것은 사람의 판단이 아닙니다. 판단에 도달하기까지 기다려야 했던 시간입니다.

기계가 다시 돌린 마감에서는 무엇이 드러났을까요?

차이가 나타난 곳은 전월에서 이월된 건이었습니다.

마감은 전월에 '이렇게 처리했다'는 기록을 바탕으로, 다음 달에 이월된 데이터를 이어받아 진행합니다. 그런데 정리된 로직을 적용해 올해 2월 마감을 처음부터 다시 실행해 보니, 이월하면 안 되는 건이 넘어와 있거나 반대로 이월돼야 할 건이 그대로 남아 있는 사례가 확인됐습니다.

여기서 한 가지 짚고 넘어갈 부분이 있습니다. 이 팀은 전체 발생 건수에 비해 오류가 극히 적은 편입니다. 이미 상당히 높은 정확도를 유지할 수 있는 업무 프로세스를 갖추고 있었죠.

그런데도 마감 로직 전체를 자동으로 다시 실행해 보니 차이가 드러났습니다. 사람이 건건이 확인할 때는 지나칠 수 있는 작은 차이도, 기계는 정해진 룰셋을 예외 없이 적용하기 때문입니다.

여기서 말하는 '기계'는 AI가 아닙니다. 사람이 미리 확정해 둔 자동화 로직입니다.

사람은 왜 그 차이를 놓쳤을까요?

기존 마감 방식이 여러 엑셀 파일을 오가며 눈으로 대조하는 작업에 의존하기 때문입니다.

XLOOKUP, VLOOKUP, SUMIF, SUBTOTAL 등을 조합해 파일마다 데이터를 맞춰보고, 필요한 값을 복사해 붙여넣는 과정이 반복됩니다. 이런 작업에서 작은 실수가 생기는 것은 이상한 일이 아닙니다. 물론 오류를 줄이기 위해 검증 수식을 여러 겹으로 구성하기도 합니다. 하지만 사람이 직접 데이터를 옮기고 확인하는 과정이 남아 있는 한, 누락 가능성까지 완전히 없애기는 어렵습니다.

이런 차이가 실제 재무제표를 크게 왜곡하는 경우는 드뭅니다. 오히려 재무 담당자가 마감 과정에서 겪는 혼선과 확인 부담이 더 현실적인 문제에 가깝습니다.

"이건 이월되면 안 되는 건데, 왜 넘어와 있지?"

금액이 크지 않은 건이라도 하나를 확인하는 데 1~2시간이 걸릴 수 있습니다. 한 건을 확인하는 동안 다른 마감 업무는 뒤로 밀리고, 담당자의 집중력도 그만큼 분산됩니다.

그래서 자동화의 가치는 단순히 오류를 찾아내는 것에 있지 않습니다. 오류 하나를 찾아내는 데 사람이 써야 했던 시간을, 애초에 발생하지 않게 만드는 것. 결국 자동화가 줄이는 것은 오류뿐 아니라 그 오류를 확인하고 처리하는 데 들어가는 사람의 시간과 집중력입니다.

AI는 지금 무엇을 제안할 수 있을까요?

AI가 지금 가장 잘할 수 있는 일 중 하나는 답을 확정하는 것이 아니라, 확인이 필요한 지점을 좁혀주는 것입니다.

예를 들어 이런 식입니다.

"이건 이런 예외 때문에 발생한 것 같으니, 이 데이터를 확인해 보면 명확해질 것 같습니다."

실제로 재무 조직의 AI 활용 사례를 보면 오류·이상 탐지는 34%로 상위권에 해당합니다(Gartner, 2025). AI가 정답을 대신 확정하기보다는, 사람이 어디를 들여다봐야 하는지 먼저 찾아주는 역할에 가깝습니다.

이 영역을 조금이라도 경험해 보셨다면 공감하실 텐데요. 예외 처리는 끝이 보이지 않는 싸움처럼 느껴질 때가 많습니다. 재무 업무는 사람이 수행하고, 그 업무에 예외를 만들어내는 비즈니스 상황 역시 사람이 만들어내기 때문입니다.

그렇다고 패턴이 무한하다고 생각하지는 않습니다. 앞으로 AI가 지금보다 훨씬 더 많은 패턴을 인식하게 될 가능성은 충분합니다. 다만 현재는 하나의 통일된 룰만으로 모든 케이스를 분류하기 어려운 단계입니다. 여전히 규칙만으로는 설명하기 어려운 건이 남습니다.

고객이 강하게 환불을 요구해 별도의 지출결의를 올리고 지급한 건, 소비자원에 접수된 클레임을 별도로 처리한 건처럼요. 데이터가 단 하나만 달라져도 우리는 곧바로 '예외 케이스'라고 판단합니다. 그리고 그 한 건을 처리하는 데도 적지 않은 시간이 들어갑니다.

조금 더 구체적인 사례를 보겠습니다.

전액 환불처럼 룰이 명확한 건은 간단한 엑셀 수식만으로도 처리할 수 있습니다. 문제는 정산서에 나타나지 않는 거래입니다.

예를 들어 고객이 별도로 클레임을 제기해 CS팀을 통해 환불을 받았다고 해보겠습니다. 재무팀이 직접 확인할 수 없는 외부 데이터에 해당 내용이 있고, 예치금 결제 방식으로 일정 금액을 환불한 데다 피해 보상금 명목으로 상품 가액의 10%까지 추가 지급했다면 어떨까요?

이런 건은 원인을 찾기 전에 필요한 데이터부터 모아야 합니다. 엑셀 함수로 처리한다고 생각하면 어디에서부터 확인해야 할지 막막해지는 이유입니다.

반면 필요한 데이터가 준비돼 있다면 AI는 여러 정보를 한꺼번에 살펴볼 수 있습니다. 그리고 이렇게 제안할 수 있습니다.

"혹시 이 차이가 이런 CS 특이 건 때문에 발생한 것 아닐까요?"

사람이 한 건씩 데이터를 따라가며 원인을 추적하던 역할을 일부 대신하는 셈입니다.

이런 제안의 범위가 넓어질수록 지금까지 '예외'라고 불렀던 케이스도 조금씩 줄어들 수 있습니다. 예외를 없애는 것이 아니라, 예외로 남는 영역을 점점 좁혀가는 것. 지금 AI가 재무 업무에서 할 수 있는 일은 여기에 가깝습니다.

AI가 할 수 없는 일은 무엇일까요?

"그래, 그거 맞아"라고 최종적으로 확정하는 일입니다.

영어로는 accountability라고 하죠. 어떤 액션을 누가 수행했는지, 어떤 근거를 가지고 수행했는지, 그리고 그 결과에 누가 책임을 지는지 — AI는 이 질문에 답할 수 없습니다.

이것은 누군가의 잘못을 찾아내는 문제와는 다릅니다. 어떤 처리가 잘못됐을 때 조직은 업무 절차 전체를 다시 따라가며 과정을 검수합니다. 교육이 필요하다면 교육을 강화하고, 업무 방식에 문제가 있었다면 방식을 바꿉니다. 협업 과정에서 부족한 부분이 있었다면 협업 체계도 보완해야 합니다.

조직 차원에서 질문을 던지고 답을 찾아갈 수 있어야 합니다. 그런데 "이거 왜 이렇게 처리했어요?"라는 질문에 "AI가 그렇게 얘기했어요"라는 답이 돌아온다면, 그다음 질문을 이어갈 수 없습니다.

결국 이 문제는 신뢰성으로 이어집니다. 감사인이 납득할 수 있는가. 감사인이 AI를 사용한다면, AI가 감사한 결과를 외부에서도 신뢰할 수 있는가.

신뢰성에 대한 질문을 계속 따라가다 보면 마지막에 남는 물음은 하나입니다. 이것을 누가 책임지는가.

그래서 사람이 맡아야 할 역할은 AI가 제안한 결과를 검토하고, 검수한 다음 최종 승인을 내리는 일입니다. 그 승인은 예전에도 사람이 하고 있었습니다. 달라지는 것은 승인에 이르기까지 거쳐야 했던 수많은 반복 작업이 줄어든다는 점입니다.

최종 승인은 여전히 사람의 몫입니다

앞으로 업무의 경계는 사람이 직접 처리하는 영역에서 검수하고 검토하는 영역으로 계속 이동할 것입니다. 다만 AI 모델이 좋아진다고 해서 이런 변화가 자연스럽게 만들어지는 것은 아닙니다.

두 가지가 함께 갖춰져야 합니다. 첫째는 AI에게 건넬 수 있는 검증된 데이터 원천의 범위가 얼마나 넓어지는가입니다. 둘째는 회사마다 다른 비즈니스 맥락을 AI가 어떻게 이해하도록 만들 것인가입니다.

두 번째 문제는 데이터를 가져다주는 것만으로 해결되지 않습니다. 회사 내부 정책과 그 회사만의 특이점, 업무 프로세스, 담당자들이 일하는 방식, 회사가 보유한 데이터, 운영 중인 커머스의 데이터까지 연결해야 합니다. 그리고 이 모든 요소를 하나의 스트림라인된 방식으로 각 회사에 맞게 구현할 수 있는 전문성도 필요합니다. 그래야 AI가 점점 더 맥락에 맞는 제안을 내놓을 수 있습니다.

포트원은 마켓플레이스 정산 데이터를 검증 단계별로 나눠 확인하고, 검증 모드와 마감 모드를 분리해 운영하면서 재무팀이 최종 승인을 내리기 전에 거쳐야 하는 반복 작업을 줄이는 구조를 만들고 있습니다. AI 에이전트가 재무 데이터 위에서 왜 자주 흔들리는지 궁금하다면, 온톨로지 런타임을 다룬 아티클도 함께 읽어보세요.

자주 묻는 질문 (FAQ)

Q1. 검증 모드와 마감 모드를 하나로 합쳐서 운영하면 안 되나요?

권하지 않습니다. 마감은 컷오프 시점과 회사 정책에 따라 결과가 달라질 수 있는 작업입니다. 이 로직이 검증 결과에까지 섞이면 지금 나타난 차이가 데이터 자체의 문제인지, 마감 기준 때문에 생긴 차이인지 구분하기 어려워집니다. 검증은 시점에 독립적으로, 마감은 시점과 정책을 반영해 운영하는 편이 각각의 결과에 신뢰를 부여하기 좋습니다.

Q2. 주문은 이번 달, 정산은 다음 달인 건은 어떻게 관리하나요?

먼저 기준을 정해야 합니다. 해당 주문과 관련된 모든 정산 건을 포함하는 데이터셋을 만들 것인지, 아니면 해당 월에 실제 발생한 정산 건만 포함할 것인지 정의해야 합니다. 이후 조인된 데이터가 정한 기준에 맞게 들어왔는지 확인합니다. 정산 데이터에서 누락된 주문이 없는지도 반대 방향으로 함께 검증해야 합니다.

Q3. 마감 자동화로 실제 얼마나 시간이 줄어드나요?

작업 구간에 따라 달라집니다. 앞서 언급한 브랜드의 경우 ERP·주문·정산 데이터를 한곳에 모으는 적재 작업이 서른 시간 가까이 걸리던 것에서 두 시간 남짓으로 줄었습니다. 다만 유관 부서의 확인이 필요한 클레임 건처럼 사람의 판단이 필요한 구간은 그대로 남습니다. 자동화 효과는 전체 마감 기간을 일률적으로 줄이는 것보다 반복 작업이 집중된 구간에서 더 뚜렷하게 나타나는 편입니다.

Q4. AI가 처리한 결과를 감사인이 인정하나요?

결과물 자체보다 그 결과에 도달한 절차와 책임 소재를 설명할 수 있는지가 핵심입니다. 어떤 룰셋으로 계산했는지, 예외 건은 누가 어떤 근거로 확정했는지를 추적할 수 있어야 합니다. "AI가 그렇게 판단했다"는 설명만으로는 다음 질문으로 이어가기 어렵습니다. 따라서 사람의 검토와 최종 확정 기록을 함께 남겨두는 편이 안전합니다. 구체적인 증빙 요건은 담당 감사인과 확인하시기 바랍니다.