급여 검증을 위한 AI 에이전트 구축하기
급여 관련 AI 에이전트에 관한 대부분의 기사는 HR 구매자를 대상으로 합니다. 개발자를 대상으로 하지 않습니다.
소규모 회계 법인을 위한 급여 에이전트를 구축한다면 더 어려운 문제에 직면하게 됩니다. 단 하나의 회사를 관리하는 것이 아니라, 여러 고객을 동시에 관리해야 하기 때문입니다. 이는 싱글 테넌트(single-tenant) 문제가 아닌 멀티 테넌트(multi-tenant) 문제입니다.
실제로 작동하는 아키텍처를 구축하는 방법은 다음과 같습니다.
3계층 아키텍처
- 에이전트 레이어(Agent Layer): 추론, 오케스트레이션 및 이상 징후 탐지를 위해 LLM을 사용합니다.
- 결정론적 세금 엔진(Deterministic Tax Engine): 계산에는 규칙 기반 시스템을 사용합니다. 세금 계산에 LLM을 절대 사용하지 마십시오. LLM은 확률적입니다. 세금 계산은 정확해야 합니다.
- 설명 가능성 레이어(Explainability Layer): 모든 수치가 어떻게 도출되었는지 기록하는 시스템을 구축합니다.
멀티 테넌트 시스템을 위한 설계 규칙
많은 고객을 처리할 때는 고객 간 격리가 필수적입니다.
• 데이터 격리(Data Isolation): 고객 A를 위한 규칙이 고객 B에 영향을 주어서는 안 됩니다. • 고객별 베이스라인(Client Baselines): 안정적인 사무실의 이상 징후 임계값은 초과 근무가 많은 건설 현장에는 맞지 않을 수 있습니다. 각 고객은 고유한 베이스라인이 필요합니다. • 감사 추적(Audit Trails): 모든 고객에 대해 독립적인 로그를 내보낼 수 있어야 합니다.
베이스라인 문제
에이전트는 무엇이 정상인지 모르면 이상 징후를 찾을 수 없습니다.
활성 검증을 시작하기 전에 최소 3~6회 분량의 이전 급여 주기를 입력(ingest)해야 합니다. 이 과정을 생략하면 오탐(false positives)이 쏟아져 나오게 됩니다. 이는 알람 피로도를 유발하며, 사용자가 경고를 무시하게 만들어 잘못된 안도감을 갖게 합니다.
탐지 대상
로직은 다음과 같은 특정 항목을 찾아야 합니다:
- 평균 대비 급여율 또는 근무 시간의 이상 징후.
- 근태 관리 시스템과 급여 시스템 간의 데이터 불일치.
- 관할 구역 변경. 직원이 새로운 주로 이주하면 세금 규칙이 즉시 변경됩니다.
- 신규 입사자의 미완료 온보딩 양식.
구축할 것인가, 구매할 것인가
결정은 고객 수에 달려 있습니다.
• 고객 10명 미만: Gusto 또는 QuickBooks와 같은 기존 플랫폼을 사용하십시오. 이들이 위험도가 높은 세금 엔진을 대신 처리해 줍니다. • 고객 10명 초과: 급여 API 위에 검증 레이어를 구축하십시오. • 대규모: 방대한 양을 관리하기 위해 맞춤형 멀티 에이전트 시스템을 구축하십시오.
진짜 엔지니어링 과제는 LLM이 아닙니다. 테넌트 격리, 액세스 범위 지정, 감사 추적과 같은 지루한 작업들입니다. 기초를 제대로 다져 놓으면 AI는 유용해집니다.
Optional learning community: https://t.me/GyaanSetuAi