방문 케어 서비스 프랜차이즈의 급여·정산은 겉으로는 "관리사가 방문한 건수에 단가를 곱하면 되는" 단순한 일처럼 보이지만, 실제 실무는 POS 매출내역·카드 승인내역·현금영수증이 양식이 제각각인 엑셀로 흩어져 있고, 서비스명 표기는 파일마다 흔들리며, 관리사마다 단가가 다릅니다. 이 프로젝트는 그 지저분한 원본 데이터를 그대로 받아 파싱·매핑·계산·대사까지 하나의 파이프라인으로 묶은 급여 정산 자동화 사례입니다.
급여 정산 자동화가 풀어야 했던 문제
도입 전 이 프랜차이즈는 매달 정산 때마다 여러 개의 엑셀을 손으로 맞추고 있었습니다. POS에서 뽑은 매출내역, 카드사에서 받은 승인내역, 홈택스 현금영수증 내역이 서로 다른 열 이름과 날짜 형식을 쓰고, 한 셀에 여러 서비스가 콤마로 묶여 있거나 관리사 이름이 금액과 함께 여러 줄로 들어오기도 했습니다.
문제는 손이 많이 간다는 것만이 아니었습니다. 수작업 대사는 틀리기 쉽고, 틀리면 관리사 급여가 어긋난다는 점이 핵심이었습니다. 서비스명 표기가 조금만 흔들려도 집계에서 빠지고, 단가를 한 번 잘못 설정하면 그 오류가 매달 명세서에 그대로 실렸습니다. 그래서 이 사례의 목표는 화면을 예쁘게 만드는 것이 아니라, 사람이 엑셀을 눈으로 맞추던 일을 규칙으로 바꿔 같은 입력이면 언제나 같은 결과가 나오게 만드는 것이었습니다.
제각각인 엑셀을 파싱·매핑·대사하는 접근
핵심 결정은 **"실무 엑셀을 바꾸지 않는다"**였습니다. 클라이언트가 이미 쓰는 POS·카드사·홈택스 양식을 그대로 두고, 시스템이 그 흔들림을 흡수하도록 설계했습니다. 기술적으로는 브라우저에서 엑셀을 파싱(SheetJS)하고, 헤더를 표준 필드로 자동 매핑한 뒤, 서비스명은 별칭·부분매칭으로 표준 서비스에 연결하고, 관리사별 단가로 급여를 집계하며, 매출과 카드·현금 영수증을 동일자·정확금액으로 대사하는 순서로 흐릅니다.
파일마다 다른 열 이름은 2패스 자동 매핑으로 흡수합니다. 먼저 "거래일시▼", "승인일시", "발행일자", "공급가액" 같은 표기를 표준 필드에 정확히 일치시키고, 남은 열은 부분 문자열 포함으로 한 번 더 맞춥니다. 한 필드에 두 열이 겹치지 않도록, 이미 매핑된 표준 필드는 두 번째 패스에서 건너뜁니다.
정확 일치를 먼저 확정하고 남은 열만 부분매칭해 오매핑을 막습니다
날짜는 엑셀 시리얼 값·"25-07-01 09:22"·"2026-02-13 16:00:03"이 뒤섞여 들어와도 YYYY-MM-DD로 정규화하고, 금액은 "143,000원"·"-"·마이너스 표기를 일관 숫자로 바꿉니다. "관리사A (70,000)\n관리사A-2 (0)"처럼 한 셀에 여러 이름이 금액과 함께 들어오면 **실제 수행 관리사(금액이 가장 큰 이름)**만 뽑고, "관리 추가, 스페셜 케어 120분"처럼 콤마로 묶인 한 행은 두 서비스로 분리해 집계합니다.
관리사별 단가 급여 계산과 3.3% 원천징수
파싱된 매출은 관리사×서비스별로 건수를 합산한 뒤, 관리사마다 다른 단가를 곱해 소계를 냅니다. 단가는 practitioner_prices[관리사][프로그램종류]에서 오는데, 같은 서비스라도 관리사에 따라 단가가 다르기 때문에 SaaS 급여 계산기로는 담기 어려운 규칙입니다. 프로그램 종류가 지정되지 않았거나 단가가 없으면 0원으로 집계되지 않도록 업로드 전에 경고로 노출해, 단가 누락이 명세서까지 흘러가는 것을 막습니다.
집계된 서비스 총액에 가감 조정(추가 수당·공제)을 반영하고, 여기에 프리랜서 원천징수 3.3%(소득세 3% + 지방소득세 0.3%)를 자동 공제해 실수령액을 계산합니다. 관리사 카드에는 서비스 총액 → 원천징수 → 실수령액이 그대로 표시되고, 같은 계산이 명세서 PDF로 이어집니다.
카드·현금 결제 대사
대사는 매출내역과 카드 승인내역·현금영수증을 동일자·정확금액으로 맞추는 단계입니다. 매출 한 건의 카드금액·현금금액을 보고 카드전용·현금전용·복합결제를 구분한 뒤, 같은 날 같은 금액의 영수증을 짝짓습니다. 복합결제는 카드 부분과 현금 부분을 각각 맞춰 한 건의 매칭으로 묶고, 하나의 영수증은 한 번만 쓰이도록 사용 표시를 관리합니다. 결과는 매칭 완료 / 미매칭 판매 / 미매칭 영수증 세 갈래로 나뉘고, 환불 매출·취소 영수증은 자동 매칭에서 분리해 사람이 확인하도록 남깁니다.
결과: 단가 로직 하나를 고치자 138건이 자동 정정됐다
가장 상징적인 결과는 단가 오류의 사후 정정이었습니다. 특정 프로그램에 시스템이 임의로 일정 금액을 더하던 로직이 있었는데, 이를 제거하자 설정 단가 그대로 계산되도록 바뀌었습니다. 문제는 이미 저장된 과거 정산이었는데, 재계산 기능이 확정 전 정산의 저장된 건수를 현재 단가로 다시 계산해 2026년 4월 정산 138건을 사람이 손대지 않고 자동 정정했습니다. 이는 매달 반복되는 절감치가 아니라 로직 수정에 따른 일회성 배치 정정이지만, "로직을 고치면 데이터까지 따라 정정된다"는 이 시스템의 설계 철학을 그대로 보여줍니다.
도입 후, 여러 개의 흔들리는 엑셀을 수기로 맞추던 급여·정산이 엑셀을 그대로 올리면 파싱·매핑·계산·대사가 규칙대로 흐르는 하나의 시스템으로 통합됐습니다. 구독형 급여 SaaS로는 담기 어려운 이 프랜차이즈만의 규칙(제각각 양식, 흔들리는 서비스명, 관리사별 단가, 복합결제 대사)을 맞춤 개발로 모델링했기에 가능한 결과였습니다. 자매 사례로는 고객사마다 다른 스키마를 다룬 행사·캐스팅 맞춤형 CRM 구축 사례와, 운영 풀사이클을 자동화한 고시원 운영 자동화 시스템 구축 사례가 있습니다.
이 시스템을 이루는 각 설계는 아래 글에서 더 자세히 다룹니다. 엑셀 인입은 양식이 제각각인 엑셀을 자동으로 읽는 법과 표기가 흔들리는 서비스명을 자동으로 통일하는 설계에서, 대사는 정산 대사란 무엇인가에서 다룹니다. 급여 계산은 사람마다 단가가 다른 급여를 자동 계산하는 법, 사후 정정은 정산 자동화의 ROI와 로직을 고친 뒤 과거 정산을 정정하는 설계에서 이어집니다. 도입을 검토 중이라면 급여·정산 시스템 도입 전 준비 체크리스트와 급여 정산 SaaS vs 맞춤 시스템이 판단에 도움이 됩니다.
지출(매입)측 법인카드를 대조하는 법인카드 지출 대조(매입측)와 달리, 이 사례는 매출(수입)측을 카드·현금 영수증과 맞추는 매출 대사라는 점에서 방향이 반대입니다. 자동화의 효과를 숫자로 잡는 방법은 업무 자동화 도입 ROI는 어떻게 계산하나, 엑셀을 버리지 않고 시스템으로 넘기는 방법은 엑셀을 버리지 않고 시스템으로에서 함께 볼 수 있습니다.
자주 묻는 질문
제각각인 실무 엑셀로 급여·정산을 자동화하려면 어떻게 하나요?
실무 엑셀을 바꾸지 않고, 시스템이 양식의 흔들림을 흡수하도록 설계합니다. 이 사례는 헤더(열 이름)를 표준 필드에 자동 매핑하고, 날짜·금액을 정규화하며, 흔들리는 서비스명을 별칭·부분매칭으로 표준 서비스에 연결한 뒤 관리사별 단가로 집계합니다. 사용자는 파일을 그대로 올리기만 하면 됩니다.
매출과 카드·현금 결제를 어떻게 맞추나요?
매출 한 건의 카드금액·현금금액을 보고 카드전용·현금전용·복합결제를 구분한 뒤, 같은 날 같은 금액의 영수증과 짝지어 대사합니다. 결과는 매칭 완료·미매칭 판매·미매칭 영수증으로 나뉘고, 환불·취소 건은 자동 매칭에서 분리해 사람이 확인하도록 남깁니다.
사람마다 단가가 다른 급여를 자동으로 계산할 수 있나요?
네. 관리사마다 프로그램 종류별 단가를 표로 관리하고, 집계할 때 관리사×서비스 건수에 그 단가를 곱합니다. 서비스 총액에서 3.3% 원천징수(소득세 3% + 지방소득세 0.3%)를 자동 공제해 실수령액까지 계산합니다.
단가를 잘못 설정했다가 고치면 과거 정산도 바로잡을 수 있나요?
확정 전 정산이라면 가능합니다. 재계산 기능이 저장된 건수를 현재 단가로 다시 계산해 정정합니다. 이 사례에서는 단가 로직을 고친 뒤 과거 정산 138건이 사람 손 없이 자동 정정됐습니다. 다만 이는 매달 반복되는 절감치가 아니라 일회성 배치 정정입니다.
급여 SaaS를 쓰지 않고 맞춤으로 개발한 이유는 무엇인가요?
제각각인 원본 양식, 흔들리는 서비스명, 관리사별로 다른 단가, 복합결제 대사처럼 이 프랜차이즈에 특화된 규칙이 많았기 때문입니다. 범용 SaaS는 이런 지저분한 입력과 업종 특화 규칙을 그대로 담기 어려워, 데이터 파이프라인을 코드로 정확히 모델링하는 맞춤 개발을 선택했습니다.