월말이 가까워지면 재무팀은 같은 질문을 반복합니다. 매출 데이터와 고객 정보를 결합해 보고서를 만들고, 이상 거래를 찾고, 미수금 현황을 정리하는 작업을 AI에게 맡겨도 되는가. CTO와 개발 리드는 여기에 한 질문을 더해야 합니다. 그 결과를 누가, 어떤 근거로, 어느 단계에서 확정할 것인가입니다.
재무 데이터 AI 자동화에서 자연어 기반 워크플로 빌더는 진입점을 낮춥니다. 사용자가 원하는 변환을 설명하면 파일을 불러오고, 결합하고, 조건을 적용하고, 집계하고, 내보내는 흐름을 만들 수 있습니다. QuickBooks Online 같은 회계 시스템 연결, CSV 파일 처리, 단계별 데이터 변환을 시각화하는 제품도 이 방향을 보여 줍니다.
그러나 워크플로가 보인다고 통제가 설계된 것은 아닙니다. 재무 업무에서는 “AI가 흐름을 만들 수 있는가”보다 “원본 데이터가 어디로 가고, 중간 결과를 누가 바꾸며, 어떤 산출물이 장부나 의사결정에 반영되는가”가 더 중요합니다. 로컬 우선 AI는 이 질문에 답하는 하나의 배치 방식이지, 승인과 검증을 대신하는 기능은 아닙니다.
자동화 대상은 업무 이름이 아니라 오류의 영향으로 나눈다
“AR 에이징을 자동화한다”는 표현만으로는 설계 결정을 내리기 어렵습니다. 같은 AR 에이징 업무에도 데이터 추출, 고객명 정리, 미수 잔액 계산, 연체 사유 분류, 회계 담당자의 조정, 경영진 보고용 해석이 섞여 있기 때문입니다.
먼저 각 단계를 다음 세 부류로 나누는 편이 좋습니다.
| 구분 | 맡기기 적합한 작업 | 남겨야 할 통제 |
|---|---|---|
| 계산·변환 | 파일 형식 통일, 열 이름 매핑, 조인, 필터, 합계, 기간별 집계 | 입력 스키마 검증, 재실행 가능성, 변환 이력 |
| 탐색·보조 판단 | 이상값 후보 찾기, 누락 가능성 표시, 보고서 초안, 설명 문구 생성 | 사람이 근거를 확인하고 채택 여부 결정 |
| 확정·반영 | 분개 확정, 지급 승인, 계정과목 변경, 외부 보고 수치 확정 | 역할별 권한, 승인 기록, 변경 불가 로그 또는 동등한 추적 수단 |
첫 부류는 로컬 우선 처리의 효과가 비교적 뚜렷한 영역입니다. 반복적인 표 계산과 데이터 결합은 정해진 입력과 규칙을 전제로 재현할 수 있습니다. 재무 데이터가 외부 모델이나 제3자 분석 환경으로 나가는 범위를 줄여야 한다면, 처리 위치도 검토할 이유가 생깁니다.
반면 두 번째와 세 번째 부류를 한 화면에서 연속 실행할 수 있다고 해서 같은 수준으로 자동화하면 안 됩니다. 예를 들어 AI가 “중복 거래로 보이는 항목”을 표시하는 일과, 그 거래를 장부에서 제거하는 일은 위험도가 다릅니다. 전자는 검토 목록을 줄일 수 있지만, 후자는 거래 사실과 회계 처리에 직접 영향을 줍니다.
로컬 우선이라는 말은 데이터 경로로 확인해야 한다
재무팀이 “로컬 우선”을 요구할 때는 대개 민감한 원장 데이터, 거래처 정보, 급여 또는 지급 정보가 외부로 전송되는 범위를 줄이고 싶다는 뜻입니다. 다만 제품이 로컬 우선을 표방하더라도, 실제 데이터 경로는 기능마다 달라질 수 있습니다.
검토 단계에서 CTO와 보안 책임자는 “데이터가 로컬에 남는가”라는 한 문장으로 판단하지 말고, 아래 흐름을 분리해 확인해야 합니다.
- 원본 데이터 수집: 회계 시스템 API, 파일 업로드, 데이터베이스 연결 중 무엇을 쓰는가. 인증 토큰과 원본 파일은 어디에 저장되는가.
- 변환 실행: 조인, 필터, 집계 같은 계산은 사용자 기기, 사내 서버, 제품 사업자의 서버 중 어디에서 실행되는가.
- AI 요청: 자연어 지시와 함께 어떤 데이터 샘플, 스키마, 결과 미리보기가 모델에 전달되는가. 모델 제공자와 보존 정책은 무엇인가.
- 결과 보관과 공유: 생성된 워크플로, 중간 테이블, 대시보드, 다운로드 파일을 누가 열람할 수 있는가.
- 지원·장애 대응: 제품 지원 과정에서 운영자가 고객 데이터를 조회할 수 있는 경로가 있는가.
이 질문은 특정 배치 방식을 우위에 놓기 위한 것이 아닙니다. 로컬 실행이 적합한 경우는 원장 전체나 고객별 상세 거래처럼 외부 이동을 최소화하려는 데이터입니다. 반대로 시장 가격, 거시 경제 지표, 공개 공시 자료처럼 외부 데이터 수집과 갱신 자체가 업무의 일부인 분석은 별도 연결과 출처 관리가 더 중요할 수 있습니다.
또한 로컬 처리만으로 권한 문제가 사라지지는 않습니다. 개인 PC에서 실행되는 도구라도 재무 담당자가 볼 수 없는 법인, 계정, 기간의 데이터를 불러올 수 있다면 접근 통제는 실패한 것입니다. 데이터 위치와 사용자 권한을 각각 설계해야 합니다.
자연어는 제작 인터페이스로 쓰고, 규칙은 실행 기준으로 고정한다
자연어는 재무 담당자가 개발 요청서 없이 분석 흐름을 만들게 하는 데 유용합니다. “고객별 미수금을 합산하고 일정 금액 이상만 표시해 달라”는 요청에서 데이터 변환 초안을 빠르게 만들 수 있습니다. 하지만 자연어 지시는 같은 의도를 다른 조건으로 해석할 여지가 있습니다. “이번 달”, “미수”, “고액”, “정상 거래”처럼 재무 실무에서 자주 쓰는 말은 회사의 정의와 계정 체계에 따라 달라집니다.
그래서 운영 환경으로 승격할 워크플로는 자연어 설명이 아니라 검토된 실행 규칙을 기준으로 관리해야 합니다.
- 금액, 기간, 통화, 법인, 계정과목의 정의를 명시합니다.
- 입력 테이블과 필수 열, 허용하는 빈값과 형식 오류를 정합니다.
- 조인 기준과 중복 처리 방식을 기록합니다.
- 계산식과 필터 조건을 사람이 읽을 수 있는 형태로 확인합니다.
- 같은 입력에서 같은 결과가 나오는지 재실행해 봅니다.
- 결과가 달라졌을 때 원본 데이터, 규칙, 모델 제안 중 무엇이 바뀌었는지 구분할 수 있게 남깁니다.
시각적 캔버스와 단계별 미리보기는 이 검토에 도움이 될 수 있습니다. 다만 화면에서 노드가 연결돼 있다는 사실은 계산의 정확성을 보장하지 않습니다. 특히 회계 시스템에서 가져온 데이터는 취소 거래, 수정 분개, 다중 통화, 마감 후 조정처럼 표면적인 합계만으로 확인하기 어려운 상태를 포함할 수 있습니다. 워크플로를 처음 만들 때부터 예외 데이터를 시험 입력으로 준비하는 편이 안전합니다.
승인 경계는 결과 화면이 아니라 되돌릴 수 없는 행동 앞에 둔다
사람 검토를 넣는다고 해서 모든 결과를 사람이 다시 계산할 필요는 없습니다. 검토자는 AI가 한 작업을 처음부터 복제하는 사람이 아니라, 회사가 정한 기준에서 벗어난 결과를 판단하는 사람이어야 합니다.
승인 경계를 정할 때는 다음 질문이 유용합니다.
- 이 결과가 외부 보고, 세무 신고, 지급, 신용 판단에 직접 쓰이는가.
- 잘못 반영했을 때 데이터만 수정하면 되는가, 거래 상대방이나 의사결정에 이미 영향을 주는가.
- 규칙으로 설명할 수 있는 오류인가, 계약 조건이나 사업 맥락을 알아야 하는 판단인가.
- 승인자가 원본 거래와 변환 과정을 다시 볼 수 있는가.
- 승인 전후의 값, 이유, 승인자를 기록할 수 있는가.
예를 들어 일별 매출을 집계해 내부 대시보드에 표시하는 단계는 입력 검증과 이상치 알림으로 운영할 수 있습니다. 반면 그 집계값을 이사회 자료나 자금 계획의 확정 수치로 옮기는 순간에는 담당자 확인과 승인 기록을 붙이는 편이 낫습니다. 자동화의 범위를 줄이는 일이 아니라, 자동화가 신뢰를 잃지 않도록 결과의 용도를 나누는 일입니다.
권한도 역할별로 분리해야 합니다. 워크플로를 만들 수 있는 사람, 원본 연결을 승인하는 사람, 실행 결과를 검토하는 사람, 회계 시스템에 반영하는 사람을 같은 계정에 몰아두면 편리해 보이지만 오류와 오용을 발견하기 어려워집니다. 소규모 조직이라 역할을 완전히 분리하기 어렵다면, 최소한 고위험 변경과 반영 작업에는 별도 승인이나 사후 검토 절차를 둬야 합니다.
제품 검증은 데모의 자연어 능력보다 실패 장면에서 한다
탐색 단계에서는 제품에 실제 민감 데이터를 바로 연결하기보다, 구조가 비슷하지만 비식별화하거나 통제 가능한 데이터로 시험하는 편이 좋습니다. 이때 “보고서를 만들어 주는가”보다 다음 장면에서 어떻게 행동하는지 확인해야 합니다.
- 열 이름이 바뀌거나 필수 열이 빠졌을 때 실행을 멈추는가.
- 조인으로 행 수가 예상보다 늘어났을 때 경고하는가.
- 회계 시스템 연결 권한이 바뀌거나 토큰이 만료됐을 때 누가 알 수 있는가.
- 사용자가 자연어로 기존 규칙과 충돌하는 요청을 했을 때 어떤 규칙을 우선하는가.
- 결과를 다운로드하거나 공유할 때 접근 범위가 유지되는가.
- 이전 실행 결과와 비교해 차이가 큰 경우 원인 추적이 가능한가.
- 생성된 워크플로를 사람이 수정하고 승인된 버전으로 고정할 수 있는가.
초기 파일럿은 하나의 반복 업무에서 시작하는 편이 좋습니다. 예를 들어 정해진 CSV 구조를 받아 집계표와 검토 목록을 만드는 작업처럼, 입력과 기대 결과를 비교하기 쉬운 업무가 적합합니다. 여기서 데이터 경로, 재현성, 권한, 승인 기록을 확인한 뒤 회계 시스템 연결이나 더 넓은 자동화로 확대할 수 있습니다.
재무 데이터 AI의 성패는 얼마나 자연스럽게 요청을 이해하느냐만으로 갈리지 않습니다. 조직이 각 결과를 초안, 검토 대상, 확정 수치 중 무엇으로 취급할지 먼저 합의할 때, 로컬 우선 처리도 규칙 기반 자동화도 제 역할을 할 수 있습니다. 다음 회의에서는 도입 후보 제품의 기능 목록보다, 현재 가장 자주 반복하는 재무 업무 하나를 펼쳐 놓고 데이터 이동 경로와 승인 지점을 먼저 표시해 보십시오.
