웹에서 급여명세서 사이트를 만드는데 어떤 방식이 좋을까요?

Question

회사에서 기존에는 문자나/카톡으로 급여명세서를 개별작성해서 하나하나 보내줬는데 이걸 통일화시켜서 웹에서 접속해서 급여명세서 페이지에서 만들고 싶어하는데 엑셀을 읽어서 그대로 출력되게 만들고 싶어합니다 근데 문제가 파견직들이 많다보니 급여지급내역 양식이 전부 다 다릅니다 통일이 안되어 있으니까 처음에 만든방식은 엑셀 열방식대로 구분쪽에 지급/공제 쪽을 나누고 총지급액-공제액 = 실수령액 이런식으로 만들었는데 엑셀양식이 통일이 아니라 그래서 열을 인식해서 만들면 인식 못하고 헤더 제목을 중식비/식대비/야근수당/만근수당 이렇게 전부 다른곳들이 많아서 이거 하나하나 적용하기에도 문제가 있어보이고 지금은 지급액/총지급액/실수령액등 총지급액 엑셀 수식으로 A~C열까지가 플러스면 지급쪽이고 마이너스면 공제쪽으로 빼서 그것만 읽어들이는 방식으로 만들긴했는데 이것도 수식이 달라지거나 수식이 안들어가 있는거는 읽어들이지를 못하니 애매모호 하는데 혹시 다른방법이 있을까요 궁금합니다

캐티 · Answer

사이트로 만들면 db나 엑셀 출력 같은것을 만들어야 하므로 결국에는 시스템으로 가는데 돈이 많이 들거여요.간단하게 가려면 브라우저 확장프로그램으로 제작하고, 한 100명 이내라면 사람마다 읽어야 하는 형식을 만들어서 지정하면 되겠쩌. 1000명이고 만 명 이런 규모라면 양식을 몇 가지로 줄여야 하는 거여요.

꿈은없고요놀고싶습니다 · Answer

어떻게 프로세스가 이루어 지는거에오?? 기존에는 회사의 급여담당 직원이 엑셀을 직접 읽고 정리해서 직원 개개인 별로 카톡을 보내줬었는데, 그게 너무 공수가 많이 드니까 웹 사이트에 엑셀 문서를 업로드 하면 그 엑셀 문서를 시스템이 읽어서 급여양식 출력을 해준다는 건가요???저라면 우선 각기 다른 엑셀 양식을 모두 정리해서 시스템이 개별 파싱하는 방식으로 만들 것 같습니다. 만약 새로운 엑셀 양식이 생긴다면 그 엑셀 양식을 시스템에 다시 등록해 줄겁니다. 그게 너무 비효율 적이다. 말이안된다. 라고 생각하면 그냥 AI에게 시키는 방법도 있습니다. 서버에 Hermes 같은 AI 에이전트 하네스를 설치해서 GPT 5.6 Luna 같은 모델을 연동시킵니다. 엑셀을 시스템에 업로드 하면 에이전트가 엑셀을 읽고 분석해서 답변을 json 형태로 정리하여 리턴해주고 그걸 받아 처리하면 됩니다. 물론 그 답변을 어떻게 검증할지는 개발자가 정해야 겠죠.

chytonpide · Answer

결론부터 말씀드리면, 열 위치·헤더 이름·수식 중 하나로 "완전 자동 인식"을 하려는 방향 자체가 막다른 길입니다. 파견업체마다 양식은 다르지만, 같은 업체는 매달 거의 같은 양식을 보냅니다. 그래서 실무에서 검증된 방식은 처음 한 번만 사람이 매핑을 확정하고, 그 매핑을 저장해서 다음 달부터 재사용하는 구조입니다. 은행 거래내역 가져오기나 회계 프로그램의 엑셀 import 마법사가 전부 이렇게 동작합니다. 지금 만드신 자동 인식 로직은 버리는 게 아니라, 그 매핑 화면의 "기본값 추천" 역할로 내려오면 됩니다. 추천 구조 1. 정규 모델을 먼저 정하고, 명세서 페이지는 엑셀을 모르게 만들기 명세서 화면이 엑셀 열을 직접 보지 않도록 중간 모델을 둡니다. 항목명은 원본 그대로 보존하니 "중식비"는 중식비로, "식대비"는 식대비로 출력됩니다. Payslip { employeeName, period, sourceCompany, earnings: [{ label: "기본급", amount }, { label: "중식비", amount }, ...], deductions: [{ label: "소득세", amount }, { label: "국민연금", amount }, ...], gross, totalDeduction, net } 2. 양식 지문(fingerprint)으로 저장된 매핑 조회 헤더 행을 정규화(공백·괄호·줄바꿈 제거)해서 순서대로 이어 붙인 문자열의 해시를 지문으로 씁니다. 업로드 시 지문이 저장소에 있으면 매핑을 바로 적용하고 검증 단계로 넘어갑니다. 헤더 행 자체도 1행이 아닐 수 있으니, "성명/사원명/이름" 같은 키 열이 처음 나타나는 행을 헤더로 잡으면 됩니다. 3. 새 양식일 때만 자동 추천 (신호 여러 개를 합산) - 병합 셀 그룹 헤더: 국내 급여대장은 1행에 "지급항목"/"공제항목"이 병합 셀로 있고 2행에 세부 항목이 오는 경우가 많습니다. 병합 범위만 읽어도 분류가 그대로 나옵니다. 이게 있으면 다른 신호보다 우선합니다. - 접미사·키워드 사전: 항목명을 전부 등록할 필요 없이 패턴으로 잡습니다. ~수당, ~비, ~급, 식대, 상여, 장려 → 지급. ~세, ~보험, ~연금, ~공제, 가불, 환수, 장기요양 → 공제. 총지급, 지급합계, 공제합계, 실수령, 차인지급, 차감지급 → 합계 열(분류 대상에서 제외). - 수식 파싱: 지금 하신 방식 그대로 신호 하나로 유지합니다. - 값으로 역추론: 아래에서 따로 설명합니다. 수식이 없는 파일의 답입니다. 4. 숫자 검증 분류 결과가 어디서 나왔든, 모든 직원 행에서 지급합 = 총지급액, 공제합 = 공제합계, 총지급액 - 공제합계 = 실수령액이 성립하는지 확인합니다. 하나라도 어긋나면 자동 적용을 막고 확정 화면으로 보냅니다. 급여라서 이 단계는 반드시 필요합니다. 5. 관리자 확정 화면 새 양식이거나 검증에 실패했을 때만 뜹니다. 열 목록을 보여주고 각 열을 지급/공제/합계/무시 중 하나로 클릭 지정하게 합니다. 자동 추천값이 기본 선택되어 있어서 대부분은 확인 버튼만 누르면 됩니다. 저장하면 지문과 함께 매핑이 남고 다음 달부터 자동입니다. 수식이 없는 파일: 값만으로 지급/공제를 역추론하기 지금 가장 애매하다고 하신 부분입니다. 수식이 없어도 총지급액과 실수령액 값이 있으면 어느 열이 지급인지 계산으로 찾을 수 있습니다. - 합계 열을 제외한 숫자 열이 N개라고 하면, 그중 어떤 부분집합의 합이 총지급액과 같은지 찾습니다. 열이 20개여도 조합은 약 백만 개라 순회 가능합니다. - 핵심은 여러 직원 행이 같은 분류를 동시에 만족해야 한다는 제약입니다. 한 행만 보면 우연히 맞는 조합이 여럿 나오지만, 직원 다섯 명 정도만 있어도 답이 거의 하나로 좁혀집니다. - 나머지 열의 합이 공제합계와 같고, 차이가 실수령액과 같으면 확정입니다. 답이 여러 개면 사전 신호로 가르거나 확정 화면으로 넘깁니다. ★ Insight ───────────────────────────────────── - 이 문제는 "헤더 텍스트 해석"이 아니라 "합계 값과 일치하는 열 분할 찾기"로 바꾸면 훨씬 결정적이 됩니다. 텍스트는 업체마다 다르지만 산수는 업체마다 같기 때문입니다. - 행이 늘수록 제약이 강해지는 구조라, 데이터가 많은 파일일수록 오히려 자동 분류가 정확해집니다. 헤더 사전 방식과 정반대입니다. - 한 열이 어떤 행에서는 양수, 다른 행에서는 음수인 경우(정산·환수 열)는 부분집합 탐색에서 부호 그대로 더해야 합니다. 절댓값을 쓰면 답이 사라집니다. ───────────────────────────────────────────────── LLM으로 헤더 분류하는 방법 사전 대신 헤더 목록만 LLM에 보내서 지급/공제/합계/무시로 분류받는 방법도 있습니다. 헤더 이름 변형에는 사전보다 훨씬 강하고, 파일당 헤더 이십여 개라 비용은 미미합니다. 다만 급여이므로 단독으로 쓰지 말고, 위 구조에서 "자동 추천" 자리에 넣어 숫자 검증과 관리자 확정을 그대로 거치게 하는 것을 권합니다. 어차피 지문으로 캐시되니 업체당 한 번만 호출됩니다. 정리 지금 방식의 한계는 "수식이 있어야만 동작"하는 데 있고, 그 답은 수식 대신 값 역추론 + 검증입니다. 그리고 완전 자동을 포기하고 한 번 확정한 매핑을 저장하는 구조로 가면, 인식 실패가 나도 시스템이 멈추지 않고 관리자가 클릭 몇 번으로 처리하게 됩니다. 실제 파견업체 엑셀 샘플을 몇 개 주시면, 지문·사전·값 역추론 파서를 프로토타입으로 만들어서 어느 정도 자동 처리되는지 바로 확인해 드릴 수 있습니다.AI는 라고 하네요.

정규분포 · Answer

개발자는 항상 기술적으로만 바라보고 법적인 배경은 별로 신경쓰지 않는게 공통된 패턴인 것 같네요.근로기준법 제 48조 ② 사용자는 임금명세서를 서면(「전자문서 및 전자거래 기본법」 제2조제1호에 따른 전자문서를 포함한다)으로 교부하여야 한다.급여명세서는 일단 서면 전달이나 전자 발송해야 법적 효력이 생김. 그냥 알아서 들어와서 빼가라는 식으로 만들면 꼬투리 잡혀요.

정규분포 · Answer

회사가 굳이 ERP 쪽 업체가 아니면, 이런데 시간 쏟기 보다는 ERP 도입하시는 것을 추천함. 이건 솔직히 관리쪽 경영 실력이 없어서 중견기업마저도 빠지는 fallacy로 보임.

먼지9729 · Answer

저라면 일단 각 업체들마다 양식이 있을건데 그 엑셀 파일들을 웹에 보여줄수 있을정도로 변환하는 작업을 먼저 할 것 같습니다.각 회사별로 양식이 다르다면 각 회사별로 기능을 다르게 만들어서 데이터 정리 기능을 먼저 만드시는게 어떨까요?

웹에서 급여명세서 사이트를 만드는데 어떤 방식이 좋을까요?

6개의 답변

Q&A 목록