OpenClaw에서 AI 에이전트 워크플로우 (AI agent workflows)를 구축해야 하는 첫 번째 실질적인 이유를 찾은 것 같습니다

사람들이 실제로 계속 실행하게 될 AI 에이전트 워크플로우 (AI agent workflows)를 구축하고 싶다면, 영수증-원장부기 (receipt-to-ledger bookkeeping)는 진정으로 말이 되는 첫 번째 유스케이스 (use case) 중 하나입니다.

"에이전트가 회계를 하기 때문"이 아닙니다.

업무의 범위가 명확하기 때문입니다:

영수증 이미지 또는 PDF 입력 (in)
구조화된 JSON 출력 (out)
아카이브 파일 이름 변경
중복 확인 실행
총계정원장 (general ledger)에 반영되기 전 불확실한 사항에 대한 인간의 검토

이것이 바로 실제 워크플로우 (workflow)입니다.

많은 에이전트 데모 (agent demos)들은 다음과 같은 두 가지 지루한 질문을 던지는 순간 무너집니다:

입력값이 정확히 무엇인가?
출력값이 정확히 무엇인가?

"리서치 어시스턴트 (Research assistant)"가 보통 이 지점에서 무너집니다. 무엇을 위한 리서치인가요? 어떤 소스를 사용하는가? 무엇을 완료된 것으로 간주하는가? 누가 확인하는가? 에이전트가 자신 있게 무언가를 지어내어 고객에게 이메일을 보내면 어떻게 되는가?

OpenClaw의 유스케이스 (use cases)를 살펴보던 중, r/openclaw의 한 스레드에서 누군가 다음과 같이 말하는 것을 발견했습니다:

"저는 제 것을 장부 기입원으로 사용합니다. 영수증 사진을 보내면, 세무 보고에 최적화된 방식으로 원장과 이미지 아카이브를 관리하는 방법을 알고 있습니다."

그 말에 저는 멈칫했습니다.

미래지향적으로 들려서가 아닙니다. IMG_4922.jpg와 같은 이름으로 가득 찬 Dropbox 폴더를 실제로 정리해 본 적이 있는 사람처럼 들렸기 때문입니다.

그것은 보통 좋은 신호입니다.

대부분의 에이전트 제안이 실패할 때 이것이 작동하는 이유

최고의 에이전트 워크플로우 (agent workflows)는 마법 같지 않습니다.

그것들은 다음과 같습니다:

반복적이고
짜증 나며
문서 작업이 많고
엄격한 스크립트 (scripts)가 비명을 지를 정도로 무질서하지만
결승선을 여전히 정의할 수 있을 만큼 구조화되어 있는 것

영수증 처리는 이 모든 항목을 충족합니다.

소규모 팀들은 이미 이 작업들에 실제 시간을 낭비하고 있습니다:

Gmail에서 영수증 전달하기
Slack이나 Discord에서 PDF 끌어오기
파일 이름 변경하기
판매처, 날짜, 소계, 세금, 총액 추출하기
비용 카테고리 추측하기
동일한 Uber 영수증이 두 번 제출되었는지 확인하기
모든 것을 Google Drive, Dropbox, QuickBooks, Xero 또는 스프레드시트에 밀어넣기

이것이 바로 에이전트가 수행해야 하는 바로 그런 종류의 업무입니다.

“내 회사를 운영해줘.”가 아닙니다.

“재무 부서를 대체해줘.”도 아닙니다.

그저 반복적인 단순 노동(grunt work)을 검토 단계(review step)와 함께 신뢰할 수 있게 수행하는 것입니다.

이것이 바로 제가 OpenClaw 스레드에서 느꼈던 분위기이기도 합니다. 유익한 댓글들은 회의적이었습니다. 사람들은 기본적으로 이렇게 말하고 있었습니다: 범위를 좁게 유지하고, 강력한 도구(tooling)를 사용하며, 모델은 모호한 부분(fuzzy parts)을 처리하게 하라고 말이죠.

그러한 사고방식은 또 다른 “자율 기업(autonomous business)” 데모보다 훨씬 더 가치 있습니다.

내가 실제로 구축할 워크플로우 (workflow)

현실적으로 느껴지는 버전은 다음과 같습니다.

1) 새 영수증 이미지 또는 PDF가 있는지 편지함/폴더 감시
2) 필드 추출: 판매자(vendor), 날짜, 통화, 소계, 세금, 합계, 결제 수단
3) JSON으로 정규화(Normalize)
...

그게 전부입니다.

가짜 자율성(fake autonomy)은 없습니다. “GPT-5로 장부를 마감하세요”도 없고, “Claude로 회계사를 대체하세요”도 없습니다.

중요한 지점에 인간이 개입하는 깔끔한 파이프라인(pipeline)이 있을 뿐입니다.

프롬프트보다 JSON 계약(contract)이 더 중요하다

만약 제가 이것을 OpenClaw, n8n 또는 Make에서 연결한다면, 단계 사이에 다음과 같은 페이로드(payload)가 이동하기를 원할 것입니다:

{
  "vendor": "Uber",
  "transaction_date": "2026-04-12",
...
}

그 review_required 필드는 세상의 그 어떤 프롬프트 엔지니어링(prompt engineering)보다 더 중요합니다.

요령은 모델이 똑똑하게 느껴지도록 만드는 것이 아닙니다.

요령은 워크플로우를 안전하게 만드는 것입니다.

LLM이 해야 할 일 vs 코드가 해야 할 일

이 분리가 게임의 핵심입니다.

모호한 작업에는 GPT-5, Claude, Qwen 또는 Llama를 사용하세요

하드코딩(hardcode)하기 까다로운 작업에는 모델을 사용하세요:

OCR 텍스트 정제
지저난 영수증에서 필드 추출
가맹점 이름 정규화
카테고리 제안
중복 가능성 포착
신뢰도(confidence)가 너무 낮을 때를 결정
검토자 요약 생성

명확한 경계에는 결정론적 코드(deterministic code)를 사용하세요

예측 가능해야 하는 작업에는 일반 코드, API 및 규칙을 사용하세요:

파일 명명 규칙
아카이브 폴더 경로
중복 해시 체크
승인 라우팅(approval routing)
QuickBooks 또는 Xero로의 원장(ledger) 기록
감사 로그(audit logs)
재시도 동작(retry behavior)
멱등성(idempotency)

이 경계들을 흐릿하게 만들면, 당신은 그저 데모를 만들게 될 뿐입니다.

이들을 분리된 상태로 유지한다면, 재무 팀이 실제로 용인할 수 있는 무언가를 얻게 될 것입니다.

실질적인 아키텍처 (A practical architecture)

제가 실제로 배포해도 괜찮겠다고 느낄 만한 버전은 다음과 같습니다.

구성 요소 (Component)	역할 (Job)
OpenClaw	에이전트 조정 (Agent coordination) 및 도구 호출 (tool calling)
...

n8n/OpenClaw 용어로 표현한 예시 파이프라인 (Example pipeline in n8n/OpenClaw terms)

Gmail 트리거 (Gmail Trigger)
  -> 첨부 파일 다운로드 (Download attachment)
  -> OCR 단계 (OCR step)
...

화려하지는 않습니다.

하지만 그렇기 때문에 저는 이것을 신뢰합니다.

추출 프롬프트 예시 (Example extraction prompt)

저라면 모델 프롬프트(model prompt) 또한 극도로 지루하게 유지할 것입니다.

당신은 구조화된 영수증 데이터를 추출하고 있습니다.
유효한 JSON만 반환하세요.

...

프롬프트는 지루할수록 더 좋습니다.

검토 게이트(review gate)를 위한 TypeScript 예시 (Example TypeScript for the review gate)

이 부분은 사람들이 데모에서는 건너뛰지만, 나중에 후회하게 되는 부분입니다.

type Receipt = {
  vendor: string | null;
  transaction_date: string | null;
...

그 함수는 당신의 모델 벤치마크 스프레드시트보다 더 중요합니다.

스크립트와 OCR API를 사용하는 것이 더 깔끔하지 않을까요? (Wouldn’t a script plus OCR API be cleaner?)

때로는 그렇습니다.

만약 모든 영수증이 동일한 형식으로, 동일한 채널을 통해, 동일한 스키마(schema)로 들어온다면, 스크립트와 OCR API를 사용하는 것이 아마 더 나을 것입니다.

그 방식은 다음과 같은 장점이 있습니다:

테스트하기 더 쉬움
감사(audit)하기 더 쉬움
추론(reasoning)하기 더 쉬움
예상치 못한 상황이 발생할 가능성이 낮음

하지만 소규모 팀은 그런 방식으로 운영되지 않습니다.

영수증은 다음과 같은 경로로 들어옵니다:

Gmail
Apple Mail
Slack
WhatsApp 스크린샷
무작위 판매자의 PDF
형편없는 조명 아래에서 찍은 휴대폰 사진

누군가는 중복된 파일을 업로드합니다.
누군가는 세금 항목을 잘라버립니다.
가맹점 이름의 절반은 카드 명세서의 이름과 일치하지 않습니다.

이것이 바로 에이전트 워크플로우(agent workflow)가 제값을 하기 시작하는 지점입니다.

옵션 (Option)	강점 (Where it wins)
OpenClaw 영수증-회계 장부 에이전트 (OpenClaw receipt-to-ledger agent)	지저분한 입력(messy intake), 다단계 오케스트레이션(multi-step orchestration), 그리고 검토 체크포인트가 있는 워크플로우에 최적
...

흥미로운 점은 에이전트가 스크립트를 대체하는 것이 아니라는 사실입니다.

에이전트는 스크립트 형태의 부분들 위에 자리 잡으며, 그 사이의 지저분한 경계면들을 처리합니다.

그것이 바로 믿을 수 있는 아키텍처입니다.

엄격한 경계: 최종 회계 판단 (The hard boundary: final accounting judgment)

이것은 인간의 영역으로 남겨두어야 합니다.

언제나 말입니다.

저는 바로 이 지점에서 많은 에이전트 대화들이 진지함을 잃는다고 생각합니다.

사람들은 “회계 에이전트 (bookkeeping agent)”라는 말을 들으면, 최종 전기 (posting) 결정을 내리고, 예외 상황을 처리하며, 어쩌 пое 어떻게든 회계사보다 세무 처리를 더 잘 이해하는 봇을 상상합니다.

사양하겠습니다.

이 워크플로우 (workflow)의 가장 강력한 형태는 자율적인 금융 권한 (autonomous finance authority)이 아니라, 금융 인접 자동화 (finance-adjacent automation)입니다.

에이전트가 근거를 준비하게 하십시오.
사람이 계정 과목 분류 (coding)를 승인하게 하십시오.
사람이 예외 사항을 검토하게 하십시오.
무엇이 실제로 총계정원장 (general ledger)에 반영될지 사람이 결정하게 하십시오.

이것은 타협이 아닙니다.

이것이 바로 이 워크플로우가 실행 가능한 이유입니다.

왜 OpenClaw가 적합한가

OpenClaw는 광범위한 “비즈니스와 채팅하기” 설정보다 이 패턴에 더 잘 맞습니다. 왜냐하면 자연스럽게 도구 사용 (tool use)과 워크플로우 설계 (workflow design)를 유도하기 때문입니다.

이것은 매우 중요한 문제입니다.

이것은 챗봇 (chatbot)의 문제가 아닙니다.
이것은 오케스트레이션 (orchestration)의 문제입니다.

다음과 같은 기능을 수행할 수 있는 무언가가 필요합니다:

편지함 및 폴더 모니터링
OCR 또는 추출 (extraction) 서비스 호출
출력값 정규화 (normalize)
중복 체크 실행
QuickBooks 또는 Xero와 같은 시스템에 기록
예외 사항을 인간에게 라우팅
단계 간 상태 (state) 유지

이것은 채팅창의 단일 거대 프롬프트 (single giant prompt)보다 OpenClaw와 n8n/Make를 결합하는 것이 훨씬 더 적합합니다.

아무도 언급하지 않는 비용 함정

이 유스케이스 (use case)가 실질적으로 느껴지는 또 다른 이유가 있습니다.

이것은 수많은 아주 작은 모델 호출 (model calls)을 포함합니다.

하나의 거대한 프롬프트가 아니라, 많은 작은 프롬프트들입니다.

영수증-원장 파이프라인 (receipt-to-ledger pipeline)은 다음과 같은 별도의 호출을 쉽게 트리거할 수 있습니다:

OCR 클리닝 (cleanup)
필드 추출 (field extraction)
공급업체 정규화 (vendor normalization)
카테고리 제안
중복 탐지
신뢰도 점수 산정 (confidence scoring)
검토자용 요약 생성

이러한 패턴은 토큰당 과금 (per-token pricing) 체제 하에서 빠르게 악화됩니다.

팀들은 워크플로우의 품질 대신 청구 비용에 대한 불안감을 중심으로 설계를 시작하게 됩니다.

중복 체크를 추가해야 할까?
GPT-5가 확신하지 못한다면 Claude로 두 번째 패스 (second pass)를 실행해야 할까?
검토자를 위해 예외 사항을 요약해야 할까?

이것들은 워크플로우에 관한 질문들입니다.

이것들이 가격에 대한 패닉으로 변해서는 안 됩니다.

이것이 바로 상시 가동되는 자동화 (always-on automations)를 위해 정액제 컴퓨팅 (flat-rate compute)이 매우 유용한 이유입니다.

만약 여러분이 OpenClaw, n8n, Make, Zapier 또는 자체 워커 스택 (worker stack)에서 에이전트를 실행하고 있다면, 경제성은 프롬프트 (prompts)만큼이나 중요합니다.

여기서 Standard Compute가 흥미로운 이유는 월정액 가격으로 무제한 AI 컴퓨팅을 제공하며, OpenAI API의 드롭인 교체재 (drop-in replacement)로 작동하기 때문입니다. 따라서 토큰 소비 (token spend)를 일일이 감시하지 않고도 GPT-5.4, Claude Opus 4.6, Grok 4.20을 통해 수많은 작은 모델 호출 (model calls)을 실행하고 싶다면, 이 방식은 정확히 이러한 종류의 워크플로우에 대한 실질적인 문제를 해결해 줍니다.

이는 추상적인 이야기가 아닙니다. 영수증 파이프라인 (Receipt pipelines)은 조용히 수많은 LLM 호출을 축적하는 대표적인 사례입니다.

만약 내가 내일 당장 이것을 구축해야 한다면

나는 아주 공격적으로 지루한 방식을 유지할 것입니다.

스택 (Stack)

에이전트 조정 (agent coordination)을 위한 OpenClaw
가시적인 오케스트레이션 (orchestration)을 위한 n8n 또는 Make
추출 정리 및 분류를 위한 GPT-5 또는 Claude
로컬/개인정보 민감 실험을 위한 Qwen 또는 Llama
영수증 상태 및 중복 제거 키 (dedupe keys)를 위한 Postgres 또는 Airtable
원본 파일 아카이브를 위한 Google Drive 또는 Dropbox
최종 장부 목적지를 위한 QuickBooks 또는 Xero
워크플로우가 수많은 작은 모델 호출을 시작할 때 정액제 API 액세스를 위한 Standard Compute

규칙 (Rules)

신뢰도가 낮은 항목은 절대 자동 게시하지 말 것
모델이 누락된 세금 값을 임의로 만들어내게 하지 말 것
항상 원본 파일을 유지할 것
항상 추출된 필드와 신뢰도 (confidence)를 기록할 것
예외 사항에 대해서는 항상 인간의 검토를 요구할 것
항상 장부 기록을 멱등적 (idempotent)으로 만들 것
항상 감사 추적 (audit trail)을 보존할 것

빠른 로컬 프로토타입 아이디어

이를 빠르게 테스트하고 싶다면, 아주 단순한 폴더 감시자 (folder watcher)로 시작할 수 있습니다.

mkdir receipts-inbox receipts-archive
npm init -y
npm install chokidar zod pg

그런 다음 PDF나 이미지를 포착하여 OCR + 추출 경로를 거치게 하고, 정규화된 JSON을 Postgres에 쓰는 감시자를 연결하세요.

import chokidar from "chokidar";

chokidar.watch("./receipts-inbox").on("add", async (filePath) => {
...

워크플로우의 형태를 증명하기 위해 거대한 프레임워크(framework)가 필요하지는 않습니다.

그저 깔끔한 계약(contract)과 엄격한 검토 게이트(review gate)만 있으면 됩니다.

실제 에이전트 유스케이스를 식별하는 나만의 규칙

데모에서는 인상적으로 들리지만, 감사(audit) 단계에서 모호한 유스케이스라면 저는 신뢰하지 않습니다.

영수증-장부 기입(Receipt-to-ledger bookkeeping)은 그 테스트를 통과합니다.

다음 항목들을 명확히 지목할 수 있기 때문입니다:

입력 (input)
출력 (output)
검토 단계 (review step)
실패 모드 (failure modes)
GPT-5가 도움이 되는 부분
Claude가 도움이 되는 부분
일반적인 코드(plain code)가 도움이 되는 부분
사람이 책임을 지는 부분

이것이 바로 이 사례가 제 기억에 남은 이유입니다.

화려해서가 아닙니다.
오히려 화려하지 않기 때문입니다.

실제 비즈니스 운영(business operations) 환경에서도 살아남을 수 있는 AI 에이전트 워크플로우(AI agent workflows)를 구축하고 싶다면, 모두가 지루해서 자랑조차 하지 않는 업무부터 시작하십시오.

영수증 처리가 바로 그중 하나입니다.

그리고 이것은 최초의 유용한 에이전트 워크플로우가 천재적인 모습이 아닐 것이라는 가장 명확한 신호일지도 모릅니다.

그것은 마치 누군가가 마침내 영수증 폴더를 정리하는 모습처럼 보일 것입니다.