Claude Code에게 한 달 치 사업 장부 관리를 맡겨보았다: 200건의 거래 내역을 대조하고 11건을 잘못 분류하다

저는 몇 개의 소규모 사업체를 운영하고 있습니다. 이는 한 달에 한 번씩 은행 내역서와 회계 플랫폼을 앞에 두고, 쌓여 있는 거래 내역들을 세무서에서 받아들일 수 있는 형태로 변환하는 작업을 해야 한다는 의미입니다. 이는 자영업의 특성 중 아무도 경고해주지 않는 부분입니다. 코딩은 즐겁지만, 장부 정리는 즐겁지 않습니다.

그래서 이번 달에는 Claude Code에게 장부 정리를 맡기고 지켜보았습니다.

결론부터 말씀드리자면, Claude Code는 200건의 거래 내역을 대조(reconcile)했고 11건을 잘못 분류했습니다. 이는 94.5%의 성공률인데, 잘못 분류된 11건이 깔끔한 신고와 세무서로부터의 통지서 사이의 차이를 만든다는 점을 기억하기 전까지는 훌륭하게 들립니다. 이것은 이 에이전트(agent)가 빛을 발한 부분, 저에게 조용히 거짓말을 한 부분, 그리고 이제 제가 에이전트에게 실행을 맡기는 일과 제가 직접 서명하는 일 사이에 긋고 있는 정확한 경계선에 대한 이야기입니다.

One month of business books run by a coding agent, then audited by hand: 200 transactions reconciled, 11 miscategorized. 94.5% right is great for a draft, a disaster for a tax filing.

설정: 질문을 멈추고, 구축을 시작하라

저의 첫 번째 본능은 당연한 것이었습니다. CSV 파일을 채팅창에 붙여넣고 "이것들을 분류해줘"라고 말하는 것이었죠. 저는 약 10줄 정도 그렇게 해본 뒤 멈췄습니다. 왜냐하면 그것은 잘못된 방식의 작업이었기 때문입니다.

일회성 분류는 한 번 요청하고 나면 영원히 옆에서 지켜봐야(babysit) 하는 작업입니다. 제가 실제로 원했던 것은 다음 달에 다른 CSV 파일을 가지고 다시 실행할 수 있고, 매번 조금씩 더 신뢰할 수 있는 프로세스였습니다. 그래서 저는 Claude Code에게 장부 정리를 해달라고 한 것이 아니라, 장부 정리 파이프라인(pipeline)을 구축하라고 명령했습니다.

이 차이는 생각보다 훨씬 중요합니다. 에이전트에게 "일을 수행하는 도구를 만들어달라"고 요청하면, 읽을 수 있는 스크립트, 수정할 수 있는 규칙 세트, 그리고 나중에 지목할 수 있는 감사 추적(audit trail)을 얻게 됩니다. 반면 에이전트에게 "일을 해달라"고 요청하면, 답변 하나와 어깨를 으쓱하는 태도만을 얻게 됩니다. 하나는 자산(asset)이지만, 다른 하나는 이제 로봇과 함께 나누어 해야 하는 잡무(chore)일 뿐입니다.

그것이 작성한 파이프라인은 화려하지는 않았지만 정확히 맞았습니다:

1. MCP (Model Context Protocol) 연결을 통해 내 회계 플랫폼에서 한 달 치 거래 내역을 가져옵니다.
2. 금액과 날짜를 기준으로 각 은행 거래 항목을 영수증 또는 송장 (invoice)과 대조합니다.
3. 모든 항목에 대해 한 줄의 이유와 함께 카테고리를 제안합니다.
4. 확실하지 않은 것은 조용히 추측하는 대신 플래그 (flag)를 표시합니다.

4단계가 저를 살렸습니다. 이에 대해서는 잠시 후에 더 자세히 설명하겠습니다.

에이전트가 제값을 한 부분

대조 (reconciliation) 작업 자체는 진정으로 훌륭했습니다. 200개의 은행 거래 항목을 영수증과 대조하는 작업은 인간이 지루하다는 이유로 정확히 못 하는 종류의 지루한 패턴 매칭 (pattern-matching)입니다. 사람은 40번째 줄쯤 되면 정신이 멍해지며 기계적으로 승인하기 시작합니다. 하지만 에이전트는 정신이 흐려지지 않습니다.

에이전트가 실수할 것이라고 예상했던 사례들도 정확하게 처리했습니다. 약간 다른 날짜에 갱신된 구독 서비스, 음수 항목으로 나타난 환불, 은행 명세서상의 이름이 송장의 이름과 전혀 닮지 않은 공급업체 등이 그러했습니다. 한 달의 대부분 동안, "AWS 스타일의 비용은 인프라로, 커피 영수증은 회의비로"와 같은 처리가 제가 손을 대지 않고도 이루어졌습니다.

이것은 더 이상 특수한 경험이 아닙니다. 2026년 1월 Deloitte의 연구에 따르면, 재무 조직의 63%가 운영의 어딘가에 AI를 완전히 배포했으며, 계속해서 승리하는 패턴은 바로 지루한 방식입니다. 모델이 대량으로 분류하게 하고, 사람이 그 결과물을 검토하는 것입니다. 기계가 읽고, 사람이 서명합니다. 저 또한 독립적으로 동일한 분업 방식에 도달했으며, 저는 이를 제가 독창적이지 못하다는 증거가 아니라 타당성을 입증받은 것으로 해석하기로 했습니다.

Where I let the agent run versus where I keep my hands on the wheel: the agent pulls rows over MCP, matches receipts, drafts categories, and flags ambiguity; I review flagged rows, spot-check confident ones, fix tax-relevant categories, and own what gets filed.

에이전트가 틀린 11가지 항목

여기 불편한 부분이 있습니다. 11개의 실수는 무작위적인 노이즈가 아니었습니다. 그것들은 세 군데에 집중되어 있었으며, 이 세 곳 모두 에이전트가 자신이 무엇을 모르는지 알 방법이 없는 지점들이었습니다.

에이전트가 파악할 수 없었던 의도 (5개 행). 업무용으로 사용한다면 내가 구매한 노트북은 사업 비용(business expense)이지만, 그렇지 않다면 개인적인 구매입니다. 영수증은 어느 쪽이든 동일해 보입니다. 에이전트는 통계적으로 가능성이 높은 선택을 하기 위해 모든 기기를 사업 자산(business asset)으로 분류했으며, 그중 두 건은 틀렸습니다. CSV 파일에 담긴 그 어떤 문맥(context)도 에이전트에게 다른 사실을 알려줄 수는 없었을 것입니다. 그 정보는 제 머릿속에만 들어있기 때문입니다.

에이전트에게 없었던 규칙 (4개 행). 세금 카테고리는 보편적인 논리가 아니라 지역 법률에 따릅니다. 고객과의 식사와 혼자 하는 식사는 에이전트에게 제공되지 않은 규칙에 따라 공제(deductible)되는 정도가 다릅니다. 에이전트는 합리적이고 확신에 찬, 그러나 틀린 추측을 내놓았습니다. 위험한 부분은 바로 그 '확신'입니다. 확신 없이 조심스럽게 내놓은 틀린 답은 잡아내기 쉽습니다. 하지만 깔끔하게 전달된 틀린 답은 그대로 통과되어 버립니다.

사람이 필요했던 예외 사례 (2개 행). 서로 관련 없는 두 가지 항목을 포함하는 단일 결제 건이 카테고리별로 나뉘어 있었습니다. 에이전트는 하나를 선택했습니다. 사람이라면 질문을 했을 것입니다.

이 목록에 없는 것이 무엇인지 주목하십시오. 바로 산술(arithmetic)입니다. 에이전트는 단 한 번도 계산을 틀리지 않았고, 행을 누락하지 않았으며, 중복 계산을 하지도 않았습니다. 실패한 부분은 모두 수학이 아닌 판단(judgment)의 문제였습니다. 이것이 핵심입니다. 에이전트는 지치지 않는 사무원(clerk)이지 회계사(accountant)가 아닙니다. 제가 에이전트를 회계사처럼 대했던 순간이 바로 저에게 금전적 손실을 입혔을 순간이었습니다.

내가 이제 긋는 선

이번 달을 겪으며 저는 하나의 규칙을 갖게 되었습니다. 그것은 "에이전트를 믿어라" 혹은 "에이전트를 믿지 마라"가 아닙니다. 그보다 훨씬 더 좁은 기준입니다.

에이전트는 데이터 추출, 영수증 매칭, 카테고리 초안 작성, 의심스러운 항목 표시와 같이 '물량이 많고 판단이 적게 필요한(high-volume and low-judgment)' 모든 일을 수행합니다. 저는 개인적으로 '물량이 적고 위험 부담이 큰(low-volume and high-stakes)' 모든 일, 즉 표시된 모든 행, 확신이 있는 항목들에 대한 무작위 점검(spot-check), 그리고 세금 결과에 영향을 미치는 모든 카테고리에 대해 최종 승인을 합니다.

이 플래깅 (flagging) 메커니즘이 이 작업을 감당 가능하게 만듭니다. 에이전트(agent)에게 불확실성을 숨기기보다 스스로 드러내라고 지시했기 때문에, 저의 검토 작업은 "200개 행을 다시 확인하기"가 아니었습니다. 대신 "확신하지 못하는 18개 항목을 확인하고, 나머지는 샘플링하기"가 되었습니다. 11개의 오류 중 7개는 이미 에이전트가 스스로 플래깅한 더미에 들어 있었습니다. 나머지 4개는 샘플링 과정에서 제가 찾아냈습니다. 이것이 도움을 주는 에이전트와, 단지 당신이 볼 수 없는 곳으로 업무를 옮겨버리는 에이전트 사이의 차이입니다.

인터넷에는 말하지 않을 사람들이 가득하기에, 저는 한 가지를 크게 강조하고 싶습니다. 스크린샷을 찍어 올리기 좋은 버전의 포스트라면 "AI가 내 세금 계산을 오후 한나절 만에 끝냈다"가 될 것입니다. 하지만 그 버전은 생략을 통한 거짓말입니다. 정직한 버전은 "AI가 내 세금 계산의 94.5%를 수행했고, 나는 세무 조사(audit)를 받을 수도 있는 나머지 5.5%를 처리했다"입니다. 두 번째 버전은 바이럴(viral)되기는 덜하겠지만, 훨씬 더 유용합니다.

여러분이 따라 하길 권하는 것들

여러분의 장부에도 이를 적용해보고 싶다면, 결과에 기여한 세 가지 요소가 있습니다:

• 정답을 요구하지 말고 파이프라인 (pipeline)을 구축하세요. 신뢰해야만 하는 채팅 답변보다는, 읽고 수정할 수 있는 스크립트 (script)가 훨씬 낫습니다. 다음 달에는 다시 설명할 필요 없이, 그냥 다시 실행하기만 하면 됩니다.
• 불확실성을 일급 출력값 (first-class output)으로 만드세요. 자신의 의구심을 플래깅하는 에이전트는 200개 행의 감사를 18개 행의 감사로 바꿔줍니다. 조용히 추측하지 말라고 지시한 것이 제가 준 가장 유용한 단일 지침이었습니다.
• 판단은 항상 당신의 영역에 두세요. 양적인 작업은 기계에게, 이해관계가 걸린 작업은 인간에게 맡기십시오. 의도, 현지 법률, 그리고 진정한 예외 사례(edge cases)는 프롬프트 (prompt)만으로 해결할 수 있는 데이터 문제가 아닙니다.

저는 어떤 프로세스에서든 병목 현상 (bottleneck)이 발생하는 지점은 모두가 최적화하려는 부분인 경우가 드물다는 것을 배우는 데 수년을 보냈습니다. 장부 정리에서 모두는 데이터 입력 (data entry)을 자동화하고 싶어 합니다. 하지만 데이터 입력은 결코 어려운 부분이 아니었습니다. 진짜 어려운 부분은, 비즈니스가 실제로 무엇을 했는지 아는 인간과, 그 부분을 정직하게 가리킬 수 있는 에이전트가 필요한 바로 그 11개의 행입니다.

저는 Claude Code Mastery에서 이러한 인간과 에이전트 간의 분업에 대해 더 자세히 다루고 있으며, 해당 도서의 한 장 전체를 할애하여 까다로운 부분을 통째로 넘기지 않으면서 코딩 에이전트 (coding agents)를 재무 및 비즈니스 업무에 사용하는 방법을 설명합니다.

다음 달에 에이전트가 다시 장부를 관리할 예정입니다. 저는 여전히 플래그(flagged)가 지정된 모든 행을 검토할 것입니다. 계속해서 흥미롭게 지켜보도록 하죠.