내 업무 어디까지 AI에 맡겨도 되나, Claude Academy 인사이트 ④

연재 「재무전문가가 꼭 알아야 할 Anthropic 교육자료」 4편 1편 지도 · 2편 설계 · 3편 진단 · 4편 절차(이 글) · 5편 실측

“이건 AI에 맡겨도 되나” 앞에서 멈춰 본 적이 있으실 겁니다. 통째로 맡기자니 서명이 걸리고, 안 맡기자니 쓸 이유가 없습니다.

이 질문은 업무 단위로는 답이 안 나옵니다. 단계로 쪼개야 답이 나옵니다. 부가세 신고를 통째로 맡길지 묻지 말고, 자료 정규화는 맡기고 불공제 확정은 내가 하는 식으로 쪼갭니다.

아래는 그 선을 긋고, 시키고, 확인하고, 기록하는 순서입니다. 순서에 들어가기 전에, 이 글의 뼈대인 강좌의 핵심 개념 둘을 표로 놓고 시작합니다.

먼저 AI와 일하는 세 방식입니다. 지금 내 일이 어느 방식인지에 따라 설계가 달라집니다.

그리고 방식이 무엇이든 필요한 역량은 넷이라는 것이 4D 프레임워크입니다.

1. 업무를 단계로 쪼갭니다

부가세 신고를 예로 들면 이렇게 갈립니다.

부가세 신고를 통째로 맡기는 것이 아닙니다. 불공제 후보 추출은 맡기고 확정은 내가 합니다. 그 한 줄이 답입니다.

월결산도 같은 방식으로 갈립니다.

감사대응은 사람이 맡는 단계가 다릅니다.

세 표에서 사람 칸의 공통점이 보입니다. 기준을 적용해 예외를 결정하는 단계, 그리고 서명이 붙는 단계입니다. 나머지는 넘길 수 있습니다.

일곱 가지 업무를 같은 방식으로 쪼갠 전체 표를 공개해 두었습니다. 자기 업무 하나를 이렇게 쪼개 보시면 대개 한 번에 보입니다. 지금 AI에 맡기고 있는 것 중 넘기면 안 되는 단계가 무엇인지.

2. 지시서를 씁니다

강의가 드는 프롬프팅 여섯 가지 기본 기법입니다.

여기에 세 축을 겹치면 지시서가 완성됩니다. 결과물 설명(Product, 무엇을 만들 것인가), 프로세스 설명(Process, 어떤 순서로 접근할 것인가), 수행 설명(Performance, 간결할지 상세할지, 동의할지 반박할지).

강의가 힘주는 대목은 프로세스 설명입니다. 결과만 말하지 말고, 어떤 순서와 방법으로 할지까지 말하라는 것입니다. 재무에서는 특히 그렇습니다. 같은 금액이 나와도 어떤 경로로 도출했는지가 조서에 남아야 하기 때문입니다.

3. 나온 결과를 확인합니다

원 강의의 분별력은 “결과물·프로세스·수행을 평가하라”까지 가고 멈춥니다. 재무에서 그것은 이름이 이미 있는 작업입니다.

이 여섯 가지는 커리큘럼에서 검증 기능으로 따로 세워 둔 것입니다. AI에 시킬 때 쓰는 지시서 골격은 이렇습니다. 그대로 옮겨 쓰셔도 됩니다.

[대상] ~산출물   [원본] ~   [방법] (위 카탈로그에서 선택해 명시)
[요구] ① 항목별 [통과/차이/보류/판단필요] 판정  ② 차이는 건별 내역·금액  ③ 판정 불가는 사유
[산출] 검증 요약(통과율) + 차이 내역표 + 후속 조치 제안

여기에 실패로 배운 규칙 넷을 붙입니다.

• 만든 세션과 검증 세션을 분리합니다. 아첨 때문입니다. 새 대화에서 원본을 다시 주고 돌리십시오
• 판정은 [통과 / 차이 / 보류 / 판단필요] 넷입니다. “대체로 맞습니다”는 검증이 아닙니다. 넷째를 빼면 회계처리 판단이 필요한 건이 그냥 「차이」로 뭉개집니다
• 합계만 대사하지 않습니다. 상계된 오류가 그대로 통과합니다. 건수와 구성까지 봐야 합니다
• 대사하기 전에 계정 정의를 읽습니다. 금액이 정확히 일치해도 계정이 틀린 경우가 있습니다. 대사로는 잡히지 않습니다

그리고 차이의 원인이 지시서의 결함이면 지시서를 고쳐 다시 돌립니다. 이것이 강의가 말하는 설명–분별력 루프의 재무판입니다. 조서 리뷰처럼 초안·리뷰노트·수정·클리어를 도는 것입니다.

4. 판단은 넘기지 않습니다

공제와 불공제, 계정분류, 충당 설정, 집행 우선순위. 재무 업무의 책임이 여기에 모입니다. 넘길 수 없는 이유는 실무적입니다. 감사에서 판단 근거를 물었을 때 “AI가 그렇게 말했습니다”는 답이 되지 않기 때문입니다.

그래서 AI에 시킬 것은 결정을 잘하게 돕는 것입니다.

[사안] ~
[요구] ① 가능한 판단 대안을 모두 제시  ② 각 대안의 근거(조문·기준)와 리스크
       ③ 전기 유사 판단 검색            ④ 반대 논거 1개 이상
[금지] 단일 결론 단정 금지. 결정은 내가 한다.
[산출] 판단 대안 비교표

[금지] 한 줄이 실제로 결과를 바꿉니다. 이 줄이 없으면 대부분 하나의 결론을 확신 있게 내놓고, 사람은 그것을 검토하지 않고 승인만 하게 됩니다. 네 번째 요구(반대 논거)는 3편에서 본 처방 넷 중 “반박을 유도하는 것”과 같은 장치입니다.

결정한 뒤에는 한 줄을 남깁니다.

사안 / 결정 / 근거(원문 링크) / 기각한 대안과 이유 / 결정자·일자 / 차기 참조 조건

이 로그가 쌓이면 두 가지가 생깁니다. 감사·검토에서 근거를 즉시 댈 수 있고, 다음 분기에 같은 고민을 반복하지 않습니다. 담당자가 바뀔 때 판단이 유실되는 것도 이 로그가 막습니다.

5. 책임을 문서로 남깁니다

강좌에 책임감 선언문(AI diligence statement) 이라는 실습이 있습니다. 작업에서 AI의 역할을 밝히고 최종 결과물의 책임은 내가 진다는 것을 문서로 남기는 것이고, 강의는 다음 다섯 가지를 담으라고 합니다.

1. 사용한 AI 시스템
2. AI가 기여한 방식
3. 적용한 검토 절차
4. 최종 결과물에 대해 본인이 책임을 진다는 진술
5. 맥락별 고려사항

책임감의 하위 3요소가 그대로 대응합니다. 책임 있는 생성(Responsible Creation, 어떤 시스템을 왜 골랐고 어떤 자료를 넣었나) · 책임 있는 투명성(Responsible Transparency, 누구에게 무엇을 밝히나) · 책임 있는 배포(Responsible Deployment, 무엇으로 검증하고 무엇을 보증하나).

재무에서 이것은 이미 쓰는 문서에 한 칸을 더하는 일입니다. 검토보고서, 자문 회신, 조서의 작성 근거란에 “무엇을 AI로 했고, 어떻게 검증했으며, 판단은 누가 했다”를 남기는 것입니다. 강의도 상황마다 공개 기대치가 다르다는 점을 이 양식의 이유로 드는데, 회계는 그 기대치가 가장 높은 쪽입니다.

한 가지 덧붙이면, 이 선언문은 방어 문서만이 아닙니다. 무엇을 검증했는지 적으려면 실제로 검증을 해야 하므로, 쓰는 행위 자체가 절차를 강제합니다.

이 순서에 이름이 붙어 있습니다

지금까지 한 것이 Anthropic AI Fluency의 4D입니다. 쪼갠 것이 위임, 시킨 것이 설명, 확인한 것이 분별력, 기록한 것이 책임감입니다.

하나만 기억하시면 됩니다. 설명과 분별력이 같은 세 축을 씁니다. 결과물·프로세스·수행. 시킬 때 그 셋을 말했으면 볼 때도 그 셋을 봅니다. 프레임워크를 먼저 외울 필요는 없습니다. 순서를 밟고 나면 이름이 따라옵니다.

앤트로픽은 어디까지 하고 있나

1편에서 정정했듯 클로드 아카데미에는 재무 사용 사례가 18건 있습니다. 결산 실무가 그대로 들어 있습니다. 회사 간 분개 대사, 계정 간 거래 조정, 계약서에서 ASC 606 필드 추출, 인원 대사, SOX 통제 문서화, 준비금 검증, 변동 설명.

프롬프트도 구체적입니다. 「분개 대조 및 작성」은 월말 환율로 통화를 맞추고, 금액과 참조번호로 퍼지 매칭하고, 차이를 시점·반올림·진짜 차이로 나누라고 지시합니다. 「인원 대사」는 코스트센터와 사번으로 맞추고 미계획 채용·미충원·급여 없는 명단·FTE 오분류를 나열하라고 합니다.

사용 사례만 있는 것도 아닙니다. Finance 플러그인에 결산주간 스킬이 함께 옵니다. 이름까지 확인한 것이 일곱 개입니다(소개문은 여덟 개라고 하는데 한 개는 화면에서 확인하지 못했습니다).

여기서 제 판정을 한 번 더 고쳐야 합니다. 사용 사례 18건만 보고 “검증이 비어 있다”고 썼는데, 플러그인까지 보면 대사와 표본 선정, 통제 테스트, 조서 작성이 전부 있습니다. 검증이라 부르는 회계 절차는 상당 부분 덮여 있습니다.

여섯 기능에 다시 대보면 이렇습니다.

오른쪽 끝 두 줄이 위에서 한 것입니다. 그리고 V 줄을 한 문장으로 줄이면 이렇게 됩니다.

/sox-testing이 뽑아 준 표본이 맞는 표본인지는 누가 봅니까.

대사도 표본 선정도 통제 테스트도 이제 AI가 합니다. 그러면 그 산출물을 확인하는 절차가 한 겹 더 필요해집니다. 사용 사례가 시키는 대사는 계정과 계정을 맞추는 업무이고, 앞의 3번에서 말한 검증은 그 대사 결과가 맞는지 확인하는 일입니다. 검증을 AI에 맡길수록 이 구분이 더 중요해집니다.

그러니 도구가 늘어날수록 이 글의 순서는 짧아지지 않습니다. 1번(쪼개기)과 3번(확인)과 4번(판단 기록)이 남습니다. 나머지는 도구가 가져갑니다.

다만 여기까지는 커넥터를 붙이기 전 이야기입니다. 법령 MCP처럼 실제로 도구를 붙이고 나면 실패가 다른 곳에서 나기 시작하고, 그건 위 검증 카탈로그로 잡히지 않습니다. 저희가 세법 에이전트를 고치며 겪은 것이 그 이야기입니다.

→ 재무 AI 에이전트에 꼭 넣어야 할 일곱 가지