AI가 급여 관리(Payroll)를 보완하는 방법

이전 기사에서 저는 Payroll Engine이 이제 MCP Server를 출시했다는 점을 거의 스치듯 언급했습니다. 이는 AI 클라이언트가 실제 급여 데이터베이스와 통신할 수 있게 해주는 작은 가교 역할을 합니다. 그 한 단락이 게시물의 나머지 내용 전체를 합친 것보다 더 많은 질문을 불러일으켰으며, 대부분의 질문은 동일한 걱정으로 귀결되었습니다.

우리가 정말로 AI를 급여 관리 근처에 두고 싶어 할까?

이는 타당한 질문이며, 답변은 전적으로 AI에게 무엇을 허용하느냐에 달려 있습니다. 따라서 이 글에서는 심도 있는 기술적 설명 대신, 한 걸음 물러나 더 큰 그림을 살펴보고자 합니다. AI가 급여 워크플로(Workflow)에서 실제로 어디에 위치하는지, 무엇을 절대 건드려서는 안 되는지, 그리고 감사인(Auditor) 앞에서도 유효하도록 그 경계선을 어떻게 그어야 하는지에 대해 다룹니다.

AI는 급여를 계산하지 않습니다

이 글에서 가장 중요한 문장부터 시작하겠습니다: AI는 급여를 계산하지 않습니다.

급여 관리는 결정론적(Deterministic)이어야 하며, 재현 가능하고, 감사 가능해야 합니다. 동일한 입력값은 항상 동일한 급여 명세서를 생성해야 하며, 모든 숫자는 규칙으로 추적 가능해야 합니다. 대규모 언어 모델(Large Language Model, LLM)은 설계상 이 중 그 어느 것도 해당하지 않습니다. LLM에게 실제 계산을 맡기는 것은 범주 오류(Category error)입니다.

따라서 Payroll Engine에서 결정론적 엔진은 규정을 해결하고, 급여 실행(Payrun)을 수행하며, 결과를 생성하는 단일 진실 공급원(Single source of truth)으로서 정확히 그 자리에 머물러 있습니다. AI는 이 중 그 어떤 것도 대체하지 않습니다. AI는 엔진의 _주변_에 위치하며 사람들이 엔진과 **상호작용(Interact)**하는 방식을 바꿉니다. 질문을 던지고, 데이터를 입력하고, 이상 징후를 발견하고, 점검을 실행하는 방식 말입니다. 엔진은 계산하고, AI는 인간이 엔진을 운전하도록 돕습니다.

이러한 프레임워크가 나머지 과정을 안전하게 만듭니다. 우리는 모델에게 세법에 대해 맞게 말해달라고 요구하는 것이 아닙니다. 우리는 모델에게 의도를 올바른 API 호출로 번역해 달라고 요청하는 것이며, 그 후 계층화된 규정과 감사 추적(Audit trail)을 갖춘 엔진이 반드시 정확해야 하는 부분을 수행하도록 하는 것입니다.

참여의 스펙트럼

엔진이 수학적 계산을 담당한다는 점을 받아들이고 나면, "급여 관리에서의 AI"는 더 이상 하나의 두려운 존재가 아니라, 점점 더 유능해지고 점점 더 많은 권한을 갖게 되는 보조 도구들의 스펙트럼(Spectrum)이 됩니다. 유용한 네 가지 단계는 다음과 같습니다:

단계	AI가 수행하는 작업	리스크
Ask (질문)	기존 데이터 조회 및 분석	읽기 전용 — 잘못된 답변은 나올 수 있으나, 잘못된 쓰기는 발생하지 않음
...

이 단계들을 하나씩 도입할 수 있습니다. 대부분의 조직은 Ask 단계에서 시작하며, 많은 조직이 이 단계에 만족하며 머무릅니다.

Ask — 자연어로 급여 데이터 조회하기

이것은 진입점이자 가장 안전한 단계입니다. MCP(Model Context Protocol) 기능이 있는 클라이언트(Claude Desktop, Cursor, GitHub Copilot)를 엔진에 연결하고 자연어로 질문하십시오:

CH-Monthly 급여 체계에서 유효한 임금 유형(Wage types)은 무엇인가요?
12월 31일 기준으로 모든 직원이 얼마를 벌었나요? — 당시 우리가 알고 있던 값과 지금 우리가 알고 있는 값을 비교해서 알려주세요.
세율표(Rate table)에서 소득 85,000에 대한 세율은 얼마인가요?

SQL도, 보고서 빌더(Report builder)도, 조인(Join)도 필요 없습니다. 모델이 적절한 도구를 선택하면, 엔진이 쌓여 있는 모든 규제 계층을 가로질러 답을 찾아내고, 결과는 몇 초 만에 돌아옵니다. 세 번째 예시가 가장 훌륭합니다. AI는 단순히 테이블을 읽는 것이 아니라, _엔진_에 조회를 요청합니다. 따라서 그 값은 재무 실행(Payrun) 시 실제로 사용될 값이며, 모든 우선순위 적용(Overrides) 사항이 반영된 결과입니다.

시점(Temporal)에 관한 질문도 중요합니다. 급여 엔진(Payroll Engine)은 두 가지 시간 축을 따라 데이터를 저장하기 때문에, 동일한 어시스턴트가 "당시에는 무엇이라고 믿었나요?"와 "지금은 무엇을 알고 있나요?"라는 두 가지 서로 다른 질문에 답할 수 있습니다. 이는 급여 감사(Payroll audits) 및 소급 수정(Retroactive-correction) 검토에 정확히 필요한 기능입니다.

결정적으로, 이 단계의 모든 것은 **설계 단계부터 읽기 전용(Read-only by design)**입니다. 어시스턴트는 그 어떤 것도 생성, 변경 또는 삭제할 수 없습니다. 혼란을 겪는 모델이 낼 수 있는 최악의 결과는 잘못된 문장일 뿐, 결코 잘못된 급여 명세서(Payslip)가 될 수는 없습니다.

Act — 보조 데이터 입력 및 운영

다음 단계는 어시스턴트가 무언가를 직접 _수행(do)_하게 하는 것입니다. 직원을 온보딩(Onboarding)하거나, 급여 변경 사항을 제출하거나, 해당 기간의 급여 계산(Payrun)을 시작하는 작업 등이 이에 해당합니다. 이는 진정으로 유용한 기능입니다. "영업팀의 Anna Weber 직원을 생성하고 4월부터 급여를 9,200으로 설정해줘"라는 문장은 급여 담당자가 말만 할 수 있다면 정말 좋아할 문장이지만, 이는 읽기(Reading)의 영역을 넘어 쓰기(Writing)의 영역으로 넘어가는 것이며, 이 경계에는 반드시 실질적인 가드레일(Guardrails)이 필요합니다.

• 자유 형식이 아닌 구조화된 방식. 어시스턴트는 UI와 동일한 검증된 채널을 통해 _변경 케이스(Case change)_를 제출합니다. 데이터베이스에 임의의 값을 직접 쓸 수는 없으며, 정의된 케이스를 채우면 엔진이 이를 검증합니다.
• 확정 전 미리보기. 어떤 데이터도 영구 저장(Persisting)하지 않고 단일 직원에 대한 계산 결과를 미리 볼 수 있습니다. 따라서 사람은 결과가 실제 적용되기 전에 그 영향을 확인할 수 있습니다.
• 모든 과정의 감사(Audit). 모든 쓰기 작업은 사람이 수행한 작업과 동일한 감사 추적(Audit trail)에 기록됩니다. 즉, 누가, 언제, 어떤 급여 항목에, 어떤 이유로 수행했는지가 남습니다.

어시스턴트는 시스템을 운영하는 더 빠른 방법이 되지만, 어시스턴트가 취하는 모든 행동은 사람이 동일한 관문(Gates)을 거쳐 동일한 기록을 남기며 수행할 수 있는 것과 동일합니다.

Consolidate — 국가 간 통합 뷰

여러 국가에서 급여를 관리하는 조직의 경우, 반복되는 고충은 그룹 차원의 통합 뷰를 확보하는 것입니다. 즉, 여러 법인과 통화에 걸쳐 국가별로 비교 가능한 총 급여(Gross), 실수령액(Net), 그리고 고용주 부담 비용(Employer cost)을 파악하는 일입니다. 보통 이는 별도의 보고(Reporting) 프로젝트가 되어야 합니다. 하지만 엔진의 통합 모델(Consolidation model) 위에 AI 어시스턴트가 있다면, 이는 다음과 같은 질문의 문제가 됩니다.

_"1분기 동안 우리 Benelux 법인들의 총 소득과 고용주 부담 비용을 비교해줘."

데이터 집계(Aggregation)는 여전히 정규화된 국가 간 스키마(Cross-country schema)를 바탕으로 엔진에 의해 수행되며, AI는 단지 이를 대화형으로 만들어줄 뿐입니다.

Verify — 즉각적인 컴플라이언스(Compliance) 확인

마지막 단계는 어시스턴트를 컴플라이언스(Compliance) 확인 도구로 변모시킵니다. 공식적인 기대값 시나리오 세트를 입력하고, 엔진이 각 시나리오를 실제 급여 실행(Payrun)을 통해 수행하도록 한 뒤, 계산된 결과값을 기대값과 비교하게 합니다. 이는 프롬프트(Prompt)를 통해 구동되는 법적 정확성에 대한 회귀 테스트(Regression testing)이며, 새로운 회계연도의 규칙이 시행될 때 매우 귀중한 역할을 합니다.

민감한 데이터를 위해 구축된 권한 모델

급여(Payroll)는 조직이 보유한 가장 민감한 데이터 중 하나입니다. 급여, 은행 계좌, 세금 식별자, 건강 관련 공제 항목 등이 포함됩니다. 아무리 유용하더라도 이 모든 데이터에 접근할 수 있는 어시스턴트는 리스크(Liability)가 됩니다. 따라서 단 하나의 도구라도 노출되기 전에 두 가지 독립적인 질문에 답해야 합니다. 이 어시스턴트가 볼 수 있는 기록은 무엇인가? 그리고 이 어시스턴트가 사용할 수 있는 기능은 무엇인가? 입니다.

Payroll Engine은 두 가지 직교하는(Orthogonal) 액세스 제어 차원을 통해 이 질문에 답합니다.

차원	제어 항목	적용 시점
격리 수준 (Isolation Level)	어떤 기록이 반환되는가	런타임(Runtime), 쿼리당
권한 (Permissions)	어떤 도구가 존재하는가	시작 시, 1회

이 둘을 분리하는 것이 핵심 기술입니다. 하나는 _데이터(Data)_를 제한하고, 다른 하나는 _기능(Functionality)_을 제한합니다. 이들은 결합되며, 결정적으로 모델이 대화를 통해 이 제한을 우회할 수 없습니다.

격리 수준(Isolation Level) — 데이터 경계. 서버 측에서 강제되는 격리 수준은 모든 개별 쿼리의 범위를 지정합니다.

수준	범위
MultiTenant	모든 테넌트(Tenant)
...

Tenant 범위의 어시스턴트는 다른 테넌트의 기록을 물리적으로 반환할 수 없습니다. 범위는 쿼리 자체에 적용되며

권한 (Permissions) — 역량의 경계. 도구들은 HR, Payroll (급여), Report (보고서), System (시스템)과 같이 도메인별로 그룹화되며, 각 그룹은 배포(deployment) 시마다 독립적으로 부여되거나 거부됩니다. 그룹이 부여되지 않은 도구는 결코 등록되지 않습니다. 즉, "액세스 거부"라고 응답하는 것이 아니라, 모델이 호출할 수 있는 대상 자체가 존재하지 않는 것입니다. 해당 배포 환경에 역량 자체가 존재하지 않기 때문에, 오용하거나 탈옥(jailbreak)할 수 있는 대상도 없습니다.

두 차원 모두 순수하게 설정(configuration)에 의해 결정되므로, 어시스턴트의 도달 범위는 코드에 작성되는 것이 아니라 프로필(profile)로 표현됩니다:

프로필	HR	Payroll	Report	System
HR Manager	Read	—	—	—
...
동일한 엔진, 동일한 어시스턴트라 할지라도, 프로필을 변경하면 사용 가능한 데이터와 역량이 완전히 달라집니다.

세 번째 기둥: 모든 것은 감사(Audit)된다

범위(Scope)와 역량(Capability)이 어시스턴트가 _할 수 있는 것_을 결정한다면, 감사 추적(audit trail)은 어시스턴트가 _한 것_을 기록합니다. 모든 작업, 특히 모든 쓰기(write) 작업은 인간의 작업과 정확히 동일하게 기록됩니다: 누가, 언제, 어떤 급여(payroll) 항목에 대해, 어떤 이유로 수행했는지가 기록됩니다. 컴플라이언스(compliance) 관점에서 볼 때, AI가 제출한 급여 변경은 직원이 직접 입력한 것과 구별할 수 없습니다. 동일한 게이트, 동일한 기록, 동일한 책임 소재를 갖기 때문입니다.

범위, 역량, 감사라는 세 가지 통제 수단의 중요한 속성은 이 중 어느 것도 모델이 올바르게 행동하는 것에 의존하지 않는다는 점입니다. 모델이 완전히 잘못된 행동을 하더라도 이 통제 수단들은 유지됩니다. 급여 데이터가 걸려 있는 상황에서 가치 있는 가드레일(guardrail)은 바로 이런 종류뿐입니다.

실질적인 활용 사례

원칙은 이 정도로 충분하니, 실제 일상적인 사용에서는 어떤 모습인지 살펴보겠습니다. 아래 예시들은 요청자가 누구인지, 그리고 무엇을 수행하려 하는지에 따라 그룹화되었습니다.

시간적 질문에 답하기

이 지점이 바로 어시스턴트가 제값을 하는 부분입니다. 기존의 급여 관리 (Payroll) 도구들이 한계를 드러내는 지점이 바로 여기이기 때문입니다. 급여 엔진 (Payroll Engine)은 모든 값을 두 가지 시간 축 — 즉, 가치 날짜 (Value Date) (이 값이 언제 활성화되는가?)와 평가 날짜 (Evaluation Date) (그 시점에 우리가 알고 있었던 것은 무엇인가?)를 따라 저장합니다. 동일한 직원, 동일한 날짜에 대해서도 어떤 지식 컷오프 (Knowledge Cutoff) 시점을 기준으로 질문하느냐에 따라 서로 다른 답변이 나올 수 있습니다:

이 방식의 묘미는 아무도 파라미터 (Parameters)를 고민할 필요가 없다는 점입니다. 사용자가 말로 질문하면, 어시스턴트가 적절한 가치 날짜 (Value Date)와 평가 날짜 (Evaluation Date)를 대신 선택해 줍니다:

질문 내용	어시스턴트의 해결 방식	결과
"Mario의 현재 급여는 얼마인가요?"	Retro A — 오늘 기준의 값, 오늘 알고 있는 값	5500
...

동일한 6월 날짜에 대해 Retro B (5000)와 Retro D (5500)가 차이 나는 것이 바로 핵심입니다. 6월 이후에 소급 인상 (Retroactive raise)이 입력되었기 때문에, "그때 알고 있었던 것"과 "지금 알고 있는 것"이 정당하게 달라지는 것입니다. 이 두 가지를 대화하듯 물어볼 수 있다는 점은 급여 감사 (Payroll audit)나 소급 지급 (Back-pay) 분쟁 시 정확히 필요한 기능입니다.

예측 (Forecasts)은 이와 정반대되는 개념입니다. 평가 날짜 (Evaluation Date)를 미래로 설정하면 됩니다:

"Budget2026 계획에 따른 Mario의 10월 급여는 얼마가 될까요?"

그러면 엔진은 실제 급여 데이터에 영향을 주지 않고, 격리된 예측 범위 (Forecast scope) 내에서 10월 시점의 값을 직접 계산합니다.

온보딩 (Onboarding) 및 일상적인 변경 사항

급여 담당자에게 어시스턴트는 여러 화면을 오가는 데이터 입력 작업을 한 문장으로 바꿔줍니다:

"Sales 부서에 Anna Weber를 온보딩해 줘. 월급은 9,200이고, 시작일은 4월 1일이야."
"5월 1일부터 Mario의 급여를 9,500으로 인상해 줘."
"회사의 주거래 은행 계좌를 새로운 IBAN으로 업데이트해 줘."

각 요청은 구조화되고 검증된 케이스 변경(case change)이 되며, 확정(commit)되기 전에 미리 보기(preview)를 제공하고 이후에는 감사 추적(audit trail)에 기록됩니다.

그룹 및 관리 질문

여러 국가나 법인에 걸쳐 있는 조직의 경우:

_"1분기 동안 우리 Benelux 법인들의 총수입(gross income)과 총 고용주 비용(total employer cost)을 비교해 줘."
_"지난달 직원 1인당 고용주 비용이 가장 높았던 법인은 어디인가요?"

엔진은 정규화된 스키마(normalized schema)를 바탕으로 국가 간 집계(cross-border aggregation)를 수행하며, 어시스턴트는 이를 보고서 요청 대신 질문의 형태로 처리할 뿐입니다.

연말 및 컴플라이언스(compliance) 점검

_"공표된 과세 연도 시나리오를 독일 급여(German payroll)에 적용하여 실행하고, 예상 값에서 벗어나는 결과가 있으면 표시해 줘."

법적 정확성을 위한 프롬프트 기반의 회귀 테스트(regression check)입니다. 이는 새로운 과세 연도의 규칙이 적용되는 시점에 특히 가치가 높습니다.

지원 및 감사

_"1월에 누가 Mario의 데이터를 변경했으며, 그 이유는 무엇인가요?"
_"지난 급여 지급(payrun) 이후 영업 부서에서 발생한 모든 케이스 변경 사항을 보여줘."

감사 추적(audit trail)이 일급 시민(first-class)으로 취급되기 때문에, "누가, 언제, 무엇을, 어떤 이유로 했는가"는 그저 또 다른 질문일 뿐이며, 로그를 일일이 뒤질 필요가 없습니다.

다음 단계

급여 관리에서의 AI는 계산을 모델에 맡기는 것이 아닙니다. 결정론적(deterministic)이고 감사 가능한 엔진을, 사람들이 질문할 수 있고 — 적절한 권한이 있다면 당신이 정의한 범위 내에서, 그리고 신뢰할 수 있는 감사 추적을 통해 — 실행(act), 통합(consolidate), 검증(verify)할 수 있게 해주는 어시스턴트로 감싸는 것입니다. 엔진은 지루할 정도로 정확하게 유지되고, 인터페이스는 훨씬 더 인간적으로 변합니다.