Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
글로벌 HR 플랫폼은 단순한 데이터 통합을 넘어선 복잡성을 가집니다. 국가별 법적 실체(EOR)와 고용 기록의 분리된 특성 때문에, 단일 대시보드 구현이 어렵습니다. 특히 급여 규정 준수는 코드가 아닌 구성 가능한 규칙 엔진으로 관리되어야 하는 것이 핵심 과제입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기저는 '전 세계 팀을 하나의 플랫폼에서 관리하세요'라는 내용의 HR-tech 제품 카피를 많이 작성해 왔습니다. 이 문제를 실제로 다뤄본 경험을 바탕으로, 이것이 단순한 체크박스 기능이 아니라 진정으로 까다로운 시스템 문제인 이유를 설명하고자 합니다.
요약하자면, 분산된 팀은 단일 데이터셋이 아닙니다. 최소한 두 가지가 필요합니다. 하나는 국가별로 다른 법적 실체(legal entity)의 규칙을 충족해야 하는 고용 기록(employment record)이며, 다른 하나는 직원이 어디에 있든 관계없이 팀 관리자에게 일관성 있게 보여야 하는 HR 기록입니다. 이 두 가지 요소는 사용자에게는 통합되기를 원하지만, 규정 준수(compliance)를 위해서는 분리되어야 합니다. 바로 이 긴장감 때문에 대부분의 '통합 워크포스 플랫폼'은 너무 일반적이어서 실제 법적 변동성(statutory variation)을 처리하기 어렵거나(thin), 아니면 기술적으로 SSO(Single Sign-On)로 붙인 두 개의 제품으로 분리되는(siloed) 문제가 발생합니다.
회사가 Employer of Record(EOR)를 통해 채용할 경우, 해당 인력의 법적 고용주는 제품을 사용하는 회사가 아니라 그 국가에 있는 EOR 법인(또는 EOR가 모든 곳에 인프라를 소유하지 않는 경우 파트너 법인)입니다. 이는 대시보드 상의 단일 '직원'이라 하더라도, 실제 고용 관계, 계약서를 발행하는 주체, 급여를 처리하는 주체, 법정 기여금을 납부하는 주체가 국가별로 다를 수 있으며, 심지어 같은 국가 내에서도 코리도어(corridor)별로 다를 수 있다는 것을 의미합니다.
따라서 데이터 모델은 단순히 employee 테이블에 salary와 manager_id만 가질 수 없습니다. 이 모델에는 해당 인력의 고용주가 누구인지를 추적하는 고용 관계 계층(employment-relationship layer)이 필요하며, 어떤 법정 규칙 세트가 적용되는지(예: 인도 PF/ESI/TDS/퇴직금 스택은 브라질의 13번째 월급 및 FGTS 요구 사항과는 전혀 다릅니다), 그리고 근본적인 법인이나 파트너가 변경될 경우 이 관계에 어떤 일이 발생하는지를 추적해야 합니다.
모든 국가의 급여 규정 준수(payroll compliance)는 사실상 자체적인 규칙 엔진(rule engine)입니다. 인도만 해도 다음과 같은 복잡성을 가지고 있습니다. 기본 임금의 12%에 해당하는 퇴직 기금(Provident Fund)은 일부 고용주가 적용하고 다른 고용주는 적용하지 않는 임금 상한선 관례를 따르며, 고액 급여 기준을 초과하면 적용이 중단되는 ESI(Employees' State Insurance), 주별 전문세(Professional Tax), 퇴직금 적립 규칙(gratuity accrual rules), 그리고 주 정부의 사업장 설립법(Shops and Establishments Acts) 등이 겹쳐 있습니다. 게다가 현재 네 가지 통합 노동법전(Labour Codes)이 주(state) 단위로 단계적으로 도입되고 있습니다. 여기에 지원하는 모든 통로를 곱하면, 제품 출시 주기와는 전혀 상관없이 국가별, 심지어 경우에 따라 주별로 버전 관리가 되어야 하는 규칙 엔진을 얻게 됩니다.
순진한 접근 방식은 국가별 급여 로직을 하드코딩(hardcode)하는 것입니다. 이것은 처음 세 개국까지는 작동하지만, 열 번째 나라가 되면 유지보수가 불가능해집니다. 왜냐하면 주 및 국가 수준의 규제 변경 사항이 스크립트 보드에 스스로 알리지 않기 때문입니다. 장기적으로 운영되는 시스템들은 법정 규칙(statutory rules)을 코드가 아닌 구성 가능한 데이터(configurable data)로 취급합니다. 따라서 컴플라이언스 업데이트는 배포(deploy)가 아니라, 법률을 이해하는 사람이 검토하는 데이터 변경 사항이 됩니다.
만약 누군가가 EOR(Employer of Record)을 통해 귀하의 팀에 합류했고, 이후 귀사가 자체 인도 법인을 설립하여 그 사람을 EOR에서 전환한다면, 이것은 고용 관계가 변경된 동일한 직원 기록인가요, 아니면 신규 채용자인가요? 이 부분을 잘못 처리하면, 전환 과정에서 과거 성과/퇴사/출근 데이터를 잃게 되거나(직원에게나 보고서 작성에 모두 좋지 않음), 두 개의 법적으로 분리된 고용 관계를 하나로 혼동하게 됩니다(감사 추적 기록(audit trails)에 좋지 않음). 올바른 답은 그 사람의 신원과 역사는 법적 고용주가 변경되어도 지속되지만, 그 아래의 '고용 관계 레이어'만 깨끗하게 변경되어야 한다는 것입니다. 이는 글로 쓰면 당연해 들리지만, 특히 처음부터 이를 염두에 두고 설계하지 않았다면, 소급적으로 구축하기에는 정말 까다로운 문제입니다.
진정으로 유용한 애플리케이션은 "AI가 HR 정책을 작성해 주는 것"이 아니라, 올바르게 모델링된 데이터 계층(data layer) 위에 자연어 인터페이스를 사용하는 것입니다. 이를 통해 HR 관리자는 대시보드를 뒤지는 대신 채팅 인터페이스(인도 노동력의 많은 경우 기본 메시징 레이어인 WhatsApp을 사용합니다)를 통해 "이번 분기에 PF 상한액 검토에 참여할 사람이 누구인지"와 같은 질문을 하거나 급여 실행 상태를 확인할 수 있습니다. 이것이 작동하는 유일한 이유는 근본적인 데이터 모델이 이미 신원(identity), 고용 관계(employment relationship), 법정 규칙 세트(statutory rule set)를 분리하고 있기 때문입니다. 이 세 가지 요소가 얽혀 있다면, AI 계층은 그저 스프레드시트 앞에 있는 채팅봇에 불과합니다.
만약 글로벌 채용(EOR, Employer of Record)과 HR 운영(HRMS, Human Resources Management System)을 통합한다고 주장하는 플랫폼을 평가하고 있다면, 물어봐야 할 질문은 "제가 있는 국가를 지원하나요?"가 아니라, "고용 관계를 개인 기록과는 어떻게 별도로 모델링하며, 그 관계가 변경되면 제 데이터는 어떻게 되나요?"입니다. 이 질문에 명확하게 답할 수 있는 공급업체들은 실제로 가장 어려운 부분을 구축한 것입니다. 이 질문에 대해 망설이는 공급업체들은 아마도 공유 로그인으로 두 가지 제품을 단순히 붙여놓았을 가능성이 높습니다.
Asanify는 직접 운영하는 코리도어(India 핵심, 다른 지역은 파트너를 통해 확장된 커버리지)에 대해 EOR과 HRMS 모두 동일한 기반 플랫폼에서 실행합니다. EOR 측에 대한 더 자세한 내용은 [asanify.com/global-employer-of-record]이며, HRMS 측은 [asanify.com/global-hrms]입니다.