“급여를 위한 AI 에이전트”에 관한 대부분의 글은 시스템을 실제로 구축하거나 설정하는 사람들이 아니라 HR 구매자를 대상으로 합니다. 이 글은 다릅니다 — 저는 단일 회사의 내부 HR 스택뿐만 아니라 여러 고객 계정에 걸쳐 실행되도록 설계된 급여 검증 에이전트를 구축하거나 평가할 때 실제로 견고하게 작동하는 아키텍처를 살펴보고자 합니다.

저는 특히 여러 고객의 급여를 동시에 처리하는 소규모 회계 법인의 맥락에서 이를 연구하고 테스트해 왔으며, 이는 대부분의 벤더 문서가 가정하는 엔터프라이즈 단일 테넌트 (single-tenant) 사례보다 훨씬 더 까다로운 오케스트레이션 (orchestration) 문제라는 것이 밝혀졌습니다.

핵심 아키텍처 결정: 오케스트레이션과 계산의 분리

이 분야에서 가장 중요한 설계 결정이자, 벤더 마케팅에서 가장 제대로 설명되지 않는 부분은 바로 이것입니다: 급여세 원천징수 계산은 절대로 언어 모델 (Language Model)을 통해 직접 실행되어서는 안 됩니다. 이는 결정론적 (deterministic)인 문제이며 — 적용 가능한 연방, 주 및 지역 규칙이 주어졌을 때 직원 1인당 급여 기간당 정확히 하나의 정답이 존재합니다 — LLM은 확률적 (probabilistic)인 출력을 생성합니다. 이는 튜닝을 통해 프롬프트로 해결할 수 있는 문제가 아니라, 근본적인 불일치입니다.

제대로 작동하는 아키텍처는 대략 다음과 같습니다:

에이전트 계층 (Agent Layer) (오케스트레이션, 검증, 플래깅)
        │
        ▼
...

에이전트 계층 (Agent Layer)은 LLM (Large Language Model) 기반의 추론이 실제로 가치를 더하는 곳입니다. 즉, 여러 소스에서 데이터를 가져오고, 기준점(baseline)과 비교하여 무엇이 이상 징후(anomalous)인지 결정하며, 무엇을 사람이 검토해야 할지 아니면 자동으로 통과시킬지를 결정하는 단계입니다. 세금 엔진 계층 (Tax engine layer)은 목적에 맞게 구축된 규칙 기반 시스템 (rules-based system)이어야 합니다. Symmetry의 세금 엔진과 같은 상용 인프라는 여기서 무엇이 "정확한" 것인지에 대한 합리적인 참조점이 될 수 있으며, 연방세, 50개 주 전체, 그리고 수천 개의 지역 관할 구역을 5ms 미만의 응답 시간으로 처리합니다. 만약 급여 에이전트를 평가하거나 구축하고 있는데 아키텍처에서 이러한 분리가 명시적으로 드러나지 않는다면, 이는 사소한 구현 세부 사항이 아니라 심각한 결함으로 취급해야 합니다.

멀티테넌시(Multi-tenant) 복잡성: 대부분의 가이드가 생략하는 부분

이 주제에 대해 발표된 거의 모든 내용은 단일 테넌트 (single-tenant) 배포, 즉 한 회사가 자사 직원을 위해 급여를 자동화하는 상황을 가정합니다. 하지만 수십 명 이상의 서로 관련 없는 고객사의 급여를 처리하는 소규모 회계 법인은 멀티테넌트 SaaS 문제에 더 가까운 환경에서 운영되며, 그 설계상의 영향은 결코 가볍지 않습니다.

각 고객사에게는 다음 사항이 필요합니다:

• 격리된 데이터 액세스 범위 지정 (Client A를 위해 잘못 설정된 검증 규칙이 Client B의 데이터에 접근할 수 없어야 함)
• 고객사별 맞춤형 기준 모델 (안정적인 인원수를 유지하는 전문 서비스 고객사에 맞춰 조정된 이상 징후 임계값은, 매주 초과 근무가 변동되는 건설업 고객사에게는 실제 문제를 놓치거나 지속적인 노이즈를 생성할 수 있음)
• 교차 오염 없이 고객사별로 내보낼 수 있는 독립적인 감사 추적 (audit trails)

기성 플랫폼을 구매하는 대신 직접 구축하고 있다면, 첫날부터 각 고객사를 고유한 경계 컨텍스트 (bounded context)로 취급하십시오. 모놀리식 단일 모델 시스템을 구축한 후에 적절한 테넌트 격리 (tenant isolation) 기능을 사후에 적용하는 것은 처음부터 이를 고려하여 설계하는 것보다 훨씬 더 많은 비용이 듭니다.

데이터 소스 매핑 및 액세스 범위 지정

어떠한 검증 로직이 실행되기 전에, 고객사별로 모든 소스 시스템에 대한 깨끗한 맵 (map)이 필요합니다:

client_config = {
    "client_id": "c_0042",
    "time_tracking_system": {"provider": "toggl", "access": "read_only"},
...

액세스 범위 지정 (access scoping)은 처음 생각하는 것보다 훨씬 더 중요합니다. 에이전트가 수정이 아닌 검증만 수행하는 모든 작업에는 읽기 전용 (read-only) 액세스가 적절합니다. 쓰기 권한 (write access)이 진정으로 필요한 경우에는 특정 필드, 즉 "플래그 (flag)" 또는 "예외 (exception)" 필드로 범위를 제한해야 하며, 근본적인 급여 기록 (pay record) 자체에는 절대 접근해서는 안 됩니다. 급여 기록에 대해 광범위한 쓰기 권한을 가진 에이전트는 기술적인 측면뿐만 아니라, 결과물에 대해 승인하는 기업의 입장에서 전문적 책임 (professional-responsibility) 관점에서도 피해야 할 리스크 요인 (liability surface)입니다.

실전 투입 전 기준점 (Baseline) 설정

에이전트는 특정 고객의 "정상 (normal)" 상태가 무엇인지 먼저 알지 못하면 이상 징후 (anomaly)를 탐지할 방법이 없습니다. 여기서의 실질적인 구현 방법은 간단합니다. 수동 로깅 (passive logging) 모드에서 인간 검토자에게 플래그를 표시하는 능동적 검증 (active validation) 모드로 전환하기 전에, 최소 3~6회의 이전 급여 주기 (pay cycles)를 수집해야 합니다 (급여 구조의 변동성이 큰 고객의 경우 더 많은 데이터가 필요합니다).

이 단계를 건너뛰는 것은 제가 여러 구현 사례에서 목격한 가장 흔한 실패 유형입니다. 기준점 (baseline) 없이 능동 모드로 전환된 에이전트는 단순한 기본 임계값 (default threshold)에 대해 엄청난 양의 거짓 양성 (false positives)을 생성합니다. 이로 인해 검토자들은 몇 주 안에 알림 피로 (alert fatigue)를 느끼게 되고, 시스템의 플래그는 검토되는 대신 반사적으로 무시되기 시작합니다. 이는 실질적인 내용 없이 커버리지만 있는 것처럼 보이게 만들기 때문에, 검증 시스템을 아예 가동하지 않는 것보다 더 나쁜 상황이라고 할 수 있습니다.

실전 검증 로직 (Validation logic)

마케팅 용어를 제외하고, 사전 실행 검증 로직 (pre-run validation logic)이 실제로 어떻게 구성되는지 간략화한 버전은 다음과 같습니다:

def validate_payroll_batch(client_id, batch, baseline):
    flags = []
    for employee in batch.employees:
...

관할 구역 변경 (jurisdiction-change) 플래그는 특별한 주의가 필요합니다. 왜냐하면 급여 준수 (payroll-compliance)에 대한 직접적인 맥락 없이 이 시스템을 구축하는 팀들이 가장 놓치기 쉬운 부분이기 때문입니다. 새로운 주(state)에서 단 한 명의 원격 근무자를 채용하는 것만으로도 즉시 새로운 원천징수 관할 구역, 잠재적인 상호주의 협정 (reciprocity agreement), 그리고 해당 지역의 세금 규칙 세트가 도입됩니다. 고객의 기존 단일 주 운영을 위해 구축된 범용 검증 규칙 세트(general-purpose validation ruleset)는 매 주기마다 주 변경 사항을 명시적으로 확인하지 않는 한 이를 포착하지 못할 것입니다.

Human-in-the-loop 레이어는 아키텍처 측면에서도, 법적 측면에서도 선택 사항이 아닙니다

모든 플래그는 지정된 검토자 (reviewer)에게 전달되어야 하며, 플래그 자체뿐만 아니라 그 해결 과정 (resolution) 또한 로그로 기록되어야 합니다. 이는 단순히 권장되는 관행이 아닙니다. 이는 실제 감사 추적 (audit trail)을 생성하는 핵심 구성 요소이며, 고객이 급여 결과에 대해 이의를 제기하거나 규제 기관이 오류를 어떻게 발견했는지(또는 놓쳤는지)를 물을 때 매우 중요하게 작용합니다. 이를 마지막에 덧붙이는 부수적인 UI 화면이 아니라, 시스템의 일급 시민 (first-class part)으로 구축하십시오. 최소한의 스키마 (schema)는 다음과 같습니다:

flag_resolution = {
    "flag_id": "...",
    "reviewed_by": "...",
...

피드백 루프 (Feedback loop): 장기적인 정확도를 결정하는 요소

실행 후에는 실행된 급여를 총계정원장 (general ledger)과 대조하고, 세금 예치금이 원천징수 금액과 일치하는지 확인하십시오. 그런 다음 모든 수정 사항을 고객의 베이스라인 모델 (baseline model)에 다시 반영하십시오. 이러한 지속적인 재보정 (recalibration) 과정을 생략하는 시스템은 고객의 상황(신규 채용, 세율 변경, 계절적 인력 변동 등)이 변화함에 따라 정확도가 정체되거나 시간이 지남에 따라 조용히 저하됩니다. 반면 기초가 되는 베이스라인은 첫날 설정된 상태 그대로 고정되어 있기 때문입니다.

Build vs. Buy: 엔지니어링 공수 관점에서의 분석

기존 플랫폼을 도입할 것인지 아니면 자체적으로 구축할 것인지 결정해야 한다면, 솔직한 계산법은 고객 수(client volume)에 크게 좌우됩니다. 단순하고 대부분 단일 주(single-state) 급여 구조를 가진 고객이 약 10명 미만인 경우, AI 검증 기능이 내장된 풀 서비스 플랫폼(Gusto, QuickBooks Payroll)을 사용하는 것이 맞춤형 인프라를 구축하는 것보다 엔지니어링 시간당 더 높은 가치를 제공합니다. 벤더(vendor)가 이 전체 시스템에서 가장 위험도가 높고 유지보수 부담이 큰 구성 요소인 세금 엔진(tax engine)을 소유하고 관리하기 때문입니다.

그 이상의 규모, 특히 여러 주(multi-state)가 얽힌 복잡성이 발생하는 경우에는 기존 급여 처리기(payroll processor)의 API 위에 구축된 독립적인 검증 레이어(validation layer)가 엔지니어링 투자를 정당화하기 시작합니다. 고객별 규칙 설정 가능성(rule configurability)이 단순히 있으면 좋은 기능(nice-to-have)을 넘어 진정으로 가치 있는 요소가 되기 때문입니다. 검증(validation), 조정(reconciliation), 통신(communication)을 위한 별도의 특화된 에이전트들을 갖춘 완전 맞춤형 멀티 에이전트 시스템(multi-agent system)은 유의미한 규모, 즉 수십 개의 고객 계정 이상이 되어 한계 엔지니어링 비용(marginal engineering cost)이 충분한 거래량에 걸쳐 상쇄되어 타당성을 가질 때에만 진정으로 정당화됩니다.

이 분야를 구축하려는 모든 분들을 위한 마무리 생각

여기서 흥미로운 엔지니어링 문제는 LLM 추론 레이어(reasoning layer)가 아닙니다. 그 부분은 현 시점에서 비교적 이미 잘 알려진 영역입니다. 진짜 문제는 지루한 인프라 작업입니다. 적절한 멀티 테넌트 격리(multi-tenant isolation), 깔끔한 액세스 범위 지정(access scoping), 실제 감사 추적 스키마(audit trail schema), 그리고 한 번 설정하고 잊어버리는 것이 아니라 시간이 지나면서 실제로 유지 관리되는 베이스라인/피드백 루프(baseline/feedback loop)를 구축하는 것입니다. 이것들을 제대로 구현해야 그 위의 AI 레이어가 진정으로 유용해집니다. 이를 건너뛴다면 데모에서는 인상적으로 보이지만, 실제 운영 환경에서는 알람 피로(alert fatigue)를 유발하거나 더 심하게는 컴플라이언스 공백(compliance gap)을 만들어내는 결과물을 만들게 될 것입니다.

저는 claritywithai.org에서 금융 및 회계 사용 사례를 위한 실무적인 AI 에이전트 아키텍처(architecture) 및 구현에 대해 더 많은 글을 작성하고 있습니다. 현재의 도구 옵션들에 대한 비교를 포함하여, 이 특정 배포 프레임워크(deployment framework)에 대한 더 자세한 분석은 여기에서 확인하실 수 있습니다: AI Agents for Payroll Processing in Small Firms.

비슷한 것을 구축하고 계신 분이 있다면 댓글을 통해 아키텍처 트레이드오프(architecture tradeoffs)에 대해 기꺼이 논의하겠습니다.