AI 에이전트에 관한 대부분의 튜토리얼은 에이전트가 시간이 지남에 따라 더 많은 도구, 더 넓은 범위, 더 적은 인간의 개입을 통해 더 자율적으로 변해야 한다고 가정합니다. 이는 규제 대상인 전문 서비스 업무를 위한 잘못된 아키텍처(Architecture)이며, 만약 회계나 법률 고객을 위해 구축하고 있다면 코드를 한 줄이라도 쓰기 전에 그 이유를 이해할 가치가 있습니다.

모든 것을 결정짓는 제약 조건

회계 및 법률 워크플로(Workflow)에는 업무를 준비하는 것과 전문적인 판단을 내리는 것 사이에 명확한 경계가 존재합니다. 은행 명세서에서 숫자를 1차적으로 추출하는 것은 준비입니다. 세무 목적으로 거래를 어떻게 분류할지 결정하는 것은 판단입니다. 템플릿을 사용하여 고객에게 보낼 편지를 초안 작성하는 에이전트는 준비입니다. 그 편지에 어떤 법률적 조언을 담을지 결정하는 에이전트는 준비가 아닙니다. 그리고 그런 에이전트를 구축하는 것은 제품이 아니라 부채(Liability)가 됩니다.

이는 가설적인 우려가 아닙니다. 2026년 법률 산업 데이터는 이 격차를 명확하게 보여줍니다. 8am 2026 Legal Industry Report에 따르면, 현재 개별 변호사의 69%가 업무에 생성형 AI (Generative AI)를 사용하고 있지만, 로펌 전체 차원의 법률 특화 AI 도입률은 34%에 불과하며, 로펌의 54%는 책임감 있는 AI 사용을 위한 교육이나 거버넌스 (Governance) 계획이 전혀 없다고 보고했습니다. 기술이 가드레일 (Guardrails)보다 앞서 나가고 있으며, 이 아키텍처가 메우고자 하는 격차가 바로 이것입니다.

따라서 제가 사용하는 아키텍처는 "인간의 승인"을 준수성을 위한 형식적인 절차로 나중에 덧붙이는 것이 아니라, 파이프라인 (Pipeline) 내의 일급 시민 (First-class) 단계로 취급합니다. 구체적으로는 다음과 같은 4개의 계층으로 구성됩니다.

1. 인제스션 계층 (Ingestion layer)

문서는 로펌이 이미 수령하고 있는 모든 곳—이메일, 업로드, QuickBooks, Xero, Clio, iManage와의 통합—으로부터 들어오며, 분류된 후 구조화된 데이터로 정규화 (Normalized)됩니다.

2. 추출 / 초안 작성 계층 (Extraction / drafting layer)

에이전트가 실제 작업을 수행합니다: 항목 추출, 거래 매칭, 편지 초안 작성, 인간의 검토가 필요한 계약서 내 조항 플래그 표시 등입니다.

3. 승인 게이트 (Approval gate)

2단계에서 생성된 그 어떤 것도 명시적인 인간의 행동(human action) 없이는 다음 단계로 넘어가지 않습니다. 이는 무시할 수 있는 UI상의 제안이 아니라, 워크플로우(workflow)가 반드시 거쳐야만 하는 상태입니다.

4. 로깅 레이어 (Logging layer)

에이전트가 수행한 모든 행동, 접촉한 모든 데이터 조각, 그리고 모든 승인 결정은 나중에 발생한 일을 재구성할 수 있을 만큼 충분히 상세하게 기록됩니다. 이는 대부분의 사람들이 과소평가하여 구축하는 레이어이지만, 무언가 잘못되었을 때 가장 중요한 레이어입니다.

로깅 레이어가 생각보다 어려운 이유

"에이전트가 송장 #4521을 처리함"이라고 기록하고 끝내고 싶은 유혹이 생길 수 있습니다. 하지만 이는 기업이 실제로 책임질 수 있는 감사 추적(audit trail)으로는 충분하지 않습니다. 어떤 데이터가 입력되었는지, 어떤 변환(transformation)이 적용되었는지, 어떤 출력이 생성되었는지, 누가 언제 검토했는지, 그리고 승인하기 전에 무엇을(만약 있다면) 변경했는지에 대한 정보가 필요합니다. 제대로 구축된다면, 이는 에이전트가 대체하는 수동 프로세스보다 더 감사 가능(auditable)합니다. 늦게까지 일하는 서두르는 직원은 자신의 논리적 근거를 기록으로 남기지 않지만, 잘 설계된 에이전트는 그 모든 것을 남깁니다.

체크박스가 아닌 설계 제약 조건으로서의 기밀성 (Confidentiality)

데이터 거주성(Data residency)과 액세스 범위 지정(access scoping)은 워크플로우를 작성한 후에 사후 적용하는 것이 아니라, 작성하기 전에 결정되어야 합니다. 구체적으로는 다음과 같습니다: 데이터는 고객이 이미 제어하고 있는 시스템 내에 머물러야 하며, 액세스 권한은 광범위하게 부여되는 대신 워크플로우별로 범위가 지정되어야 합니다. 또한, 무언가를 구축하기 전에 다루게 될 특정 문서 유형에 맞춰 권한/보유(privilege/retention) 규칙이 매핑되어야 합니다. 만약 기밀성 리스크를 생성하지 않고서는 워크플로우를 자동화할 수 없다면, 정직한 답변은 그것을 구축하지 않는 것입니다.

실제로 작동하는 배포 패턴

한꺼번에 다섯 개의 워크플로우를 구축하지 마세요. 기업 내에서 가장 반복적이고 판단력이 가장 적게 필요한 단 하나의 작업을 선택하여, 승인 게이트(approval gate)와 로깅(logging)을 내장한 상태로 엔드 투 엔드(end-to-end)로 구축한 뒤, 실제 파일을 사용하여 기존의 수동 프로세스와 병행하여 실행하십시오. 이 분야에서의 신뢰는 데모가 아니라, 몇 주 동안 실제 사례에서 시스템이 올바르게 작동함으로써 얻어집니다. 그것이 증명되면, 다음 워크플로우로 범위를 넓히십시오.

회계 측면에서 이 패턴은 빠르게 확산되고 있습니다. 2026년 기준으로 회계 및 CPA(공인회계사) 기업의 73%가 어떤 형태로든 자동화 (Automation)를 구현했으며, 재무 리더의 79%는 AI가 결국 일상적인 회계 업무의 절반 이상을 자동화할 것으로 기대하고 있습니다. 여기서 실질적인 가치를 얻고 있는 기업들은 무언가 잘못된 후에 승인 게이트 (Approval gate)를 덧붙인 기업들이 아니라, 첫날부터 승인 게이트를 설계 단계부터 구축한 기업들입니다.

만약 여러분이 SaaS (Software as a Service) 또는 소비자용 앱 (Consumer-app) 배경을 가지고 있다면, 자율성 (Autonomy)을 극대화하고 클릭을 최소화하려는 본능이 이곳에서는 오히려 독이 될 것입니다. 규제 산업인 전문 서비스 (Professional services)에서의 가치 제안 (Value proposition)은 "에이전트가 더 많은 일을 한다"가 아닙니다. 그것은 "에이전트가 반복적인 90%의 업무를 정확하게 수행하고, 중요한 나머지 10%를 모든 단계에 대한 증빙 (Receipt)과 함께 인간에게 전달한다"입니다. 이를 위해 구축한다면, 기술적인 작업은 다른 통합 (Integration) 프로젝트와 진정으로 크게 다르지 않습니다. 규율 (Discipline) 자체가 곧 제품입니다.

승인 게이트 (Approval-gate) 패턴이 실제 업무에서 어떻게 적용되는지 확인하고 싶다면, ritiktechs.com/ai-automation-accountants-law-firms에서 이러한 종류의 자동화 작업에 대해 더 자세히 다루고 있습니다.