5.3. 사례 2 — XLWORK 풋팅

감사에서 숫자 하나가 안 맞으면 그 하나 때문에 밤이 길어집니다. 합계는 틀려서는 안 되는 자리인데, 표가 수십 장이면 그 값을 사람이 손으로 전부 다시 짚어 볼 수는 없습니다.

앞 사례에서는 문서가 '어떻게 보일지', 곧 서식을 코드로 닫았습니다 — 판단이 거의 끼어들지 않는, 셋 중 가장 닫기 쉬운 표면이었습니다.

이번 사례는 판단이 반드시 한 줌 남는 표면입니다. 합계가 맞는지 검증하는 일, 감사에서 풋팅(Footing, 합계 검증)이라 부르는 그 일입니다.

제가 만들어 쓰는 도구를 하나 꺼내겠습니다. 감사보고서에 붙는 재무제표 파일(DSD)을 읽어, 합계 검증과 대사 검증 수식을 심은 엑셀 워크북을 자동으로 만들어 주는 도구입니다.

핵심은 그다음입니다. 결정론이 걸러낸 불일치만 AI가 다시 판정합니다.

서식을 닫는 것과, 판단을 한 줌 남기는 것이 이 한 도구 안에서 만납니다.

1. 풋팅이 왜 코드로 닫는 일인가 — 합계는 판단이 아니라 사실이다

풋팅은 감사의 가장 기초적인 절차입니다. 표의 세로합·가로합을 다시 계산해, 표시된 합계와 맞는지 보는 일입니다.

대사(Cross-check)는 그 짝입니다. 같은 숫자가 재무제표와 주석 여러 곳에 나올 때, 그 값들이 서로 어긋나지 않는지 맞춰 보는 일입니다.

이 두 가지에는 판단이 없습니다. 재무상태표의 자산 합계는 어제 계산해도 오늘 계산해도 같은 값이어야 합니다.

매번 똑같은 답이 나와야 하는 일 — 이것이 코드로 닫을 자리의 정의입니다.

그런데 이 자리를 흔들리는 도구에 맡기면 곤란합니다. 제가 쓰던 상용 풋팅·대사 도구(CCK Solution의 AI Footing+Cross-ref(Pro))에서 몇 가지 결함을 만났기 때문입니다.

주석 번호 참조 '4,5,6,32'가 45632라는 한 숫자로 뭉개지고, 빈 셀을 참조하다 #VALUE!가 뜨는 식이었습니다. 매번 맞아야 하는 자리에서 이런 흔들림은 그대로 검토 부담으로 돌아옵니다.

그래서 그 몇 가지 결함을 잡으려고 검증 부분을 직접 다시 만들었습니다. 도구 전체가 더 낫다는 이야기가 아니라, 걸린 결함들을 하나씩 닫았다는 이야기입니다.

2. 그래서 검산할 수 있는 건 빠짐없이 깐다 — 다중 후보 풋팅·대사·자체감사

결정론 층의 원칙은 하나입니다. 검산이 가능한 관계라면 겁내지 말고 빠짐없이 수식으로 깝니다.

빠뜨리지 않는 것이 먼저입니다. 틀린 곳을 하나라도 놓치는 것보다, 멀쩡한 곳까지 일단 다 짚어 두는 편이 안전하기 때문입니다.

다중 후보로 합을 찾는다

합계 검증부터 보겠습니다. 표의 어떤 셀이 어느 범위의 합인지, 파일만 봐서는 딱 잘라 알기 어렵습니다.

그래서 대상 셀마다 그럴듯한 합 후보를 여러 개 만듭니다. 위쪽 몇 행의 합, 소계들의 합, 특정 열의 세로합처럼 가능한 조합을 파이썬으로 전부 계산합니다.

그중 표시된 값과 정확히 일치하는 후보를, 엑셀 수식으로 확정해 워크북에 심습니다. 사람이 '이건 이 합이겠지' 하고 눈으로 찍던 자리를, 계산으로 확정하는 것입니다.

검산 가능한 관계는 전부

합계 하나로 끝나지 않습니다. 단계별 손익, 현금흐름표, 자본변동표, 주석 표의 합계행과 합계열, 비율 산식까지 — 검산이 되는 관계는 빠짐없이 수식으로 깝니다.

단위를 맞춰 대사한다

대사는 단위부터 정리합니다. 재무제표는 백만원, 주석은 천원이나 원으로 적히는 경우가 흔하기 때문입니다.

원·천원·백만원을 환산해 자릿수를 맞춘 뒤, 재무제표 금액과 주석 금액을 대조합니다.

워크북이 스스로를 감사한다

마지막이 자체감사(selfaudit)입니다. 만들어 낸 워크북의 모든 수식을, 엑셀과 별개인 독립 파서 — 워크북의 수식을 프로그램이 처음부터 다시 읽어 계산하는 장치 — 로 한 번 더 계산합니다.

그 결과를 애초의 파이썬 검산값과 대조합니다. 수식이 말하는 값과 파이썬이 검산한 값이 어긋날 수 없게 한 벌로 묶어 두고(단일 진실 구조), 통과·불일치·오류를 하나의 신호로 되돌려 줍니다(종료코드).

검증 워크북의 구조 — 표시값과 검산값이 어긋난 행만 빨갛게 걸린다 (도식)

3. 그런데 빨간불이 다 진짜 오류인가 — 노이즈를 골라내는 자리만 AI

여기서 문제가 하나 생깁니다. 빠짐없이 다 짚으면, 진짜 오류가 아닌 것까지 함께 빨간불이 켜집니다.

절사 차이, 비율의 반올림, 근사값으로 맞아떨어지는 대사차 같은 것들입니다. 틀린 게 아니라 원래 그런 값인데, 기계적으로는 '안 맞음'으로 걸립니다.

이 노이즈를 사람이 한 항목씩 헤집으면, 자동화한 검증이 다시 수작업으로 돌아갑니다.

그래서 판단을 사람이 아니라 AI에 넘깁니다. 결정론이 이미 빨간불로 깔아 둔 항목만, LLM이 항목별로 다시 봅니다.

결정론이 겁내지 않고 빨간불을 빠짐없이 다 깔면, 그 노이즈를 골라내는 비용은 사람이 아니라 LLM이 집니다.

빠짐없이 잡는 몫은 결정론(재현율)이, 그중 진짜만 골라내는 몫은 AI(정밀도)가 나눠 집니다. 사람에게는 AI가 '수정필요'로 추린 것만 올라옵니다.

다만 AI에 판단을 넘기는 순간, 안전장치가 필요합니다. 확률모델은 본래 흔들리는 물건이라, 검증이라는 자리에서 함부로 풀어 두면 안 되기 때문입니다.

이 도구에는 그 안전장치가 코드에 박혀 있습니다.

안전장치	무엇을 막나
초록불 불가침	결정론이 통과시킨 항목은 LLM이 뒤집지 못한다
검산 게이트	AI가 '수정필요'라 해도 제안값이 결정론 재검산값과 맞을 때만 확정, 아니면 '확인필요'로 강등
대사는 확인필요	대사 불일치는 어느 쪽이 맞는지 방향을 확정할 수 없어 늘 '확인필요'로만
입력 불신	DSD 셀 텍스트 속 문구는 데이터로만 취급, 그 안의 지시는 명령으로 따르지 않는다

풀어 말하면, AI는 결정론이 켜 둔 초록불을 절대 못 끄고, 빨간불을 '수정필요'로 올리려 해도 그 근거가 재검산과 맞아야만 통과합니다.

그리고 AI 백엔드가 없으면 AI 검토는 통째로 건너뜁니다. 그래도 결정론 워크북은 그대로 정상적으로 만들어집니다.

AI는 골격을 세우는 층이 아니라, 결정론이 세운 골격 위에 얹히는 부가 층입니다.

4. 이것이 황금비율의 실제 얼굴이다 — 그리고 AI가 규칙을 고친 순간

앞 챕터들에서 결정론 90% + AI 10%라는 비율을 말했습니다. 이 도구가 그 비율을 숫자로 계산해 내는 것은 아닙니다.

다만 구조가 정확히 그 모습입니다. 검산 가능한 거의 전부가 결정론 몫이고, AI가 맡는 것은 '진짜 오류인가'라는 좁은 판단 한 자리뿐입니다.

결정론이 빨간불을 빠짐없이 다 깔고(재현율), AI는 그중 진짜 오류만 골라낸다(정밀도)

여기에 제가 좋아하는 실제 장면이 하나 있습니다. AI가 오히려 결정론 규칙을 고쳐 준 순간입니다.

첫 실행에서 LLM이 짚어낸 것이 하나 있었습니다. 이자율 열의 세로합을 도구가 오탐으로 걸었다는 것이었습니다.

요율은 세로로 더할 값이 아닌데, 다중 후보 방식이 기계적으로 합 후보를 만들어 빨간불을 켜 둔 것이었습니다.

저는 그 지적을 받아, 요율 열은 세로합 검증에서 제외한다는 규칙을 결정론 쪽에 바로 넣었습니다. AI가 결정론을 대체한 게 아니라, 결정론을 더 정교하게 다듬어 준 셈입니다.

반복은 결정론으로, 판단은 AI에게 — 그리고 그 판단이 다시 결정론을 손봅니다.

다음 사례는 검증 쪽으로 한 걸음 더 들어갑니다. 여기서는 이미 만들어진 재무제표를 검증했다면, 다음에는 AI가 '직접 쓴' 초안 자체를 사람이 조서 검토하듯 자동으로 검증하는 이야기입니다.

감사조서 하네스(Harness)로 넘어가겠습니다.