HR 솔루션 근태관리, 잘못 설정하고 다시 고친 과정

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

월말이 되자 인사팀 메신저에 같은 질문이 쏟아졌습니다. “분명 출근했는데 왜 지각으로 표시되나요?”, “반차를 썼더니 근무시간이 부족하다고 나옵니다.” 새로 도입한 HR 솔루션은 정상 작동하고 있었지만, 정작 근태관리 기준을 잘못 입력한 탓에 직원들의 기록은 계속 어긋났습니다.

이 사례의 핵심은 기능 부족이 아니었습니다. 기존 규칙을 검토하지 않고 시스템부터 열어 버린 순서가 문제였습니다. 근태 오류가 생긴 뒤 설정을 하나씩 되돌린 과정을 살펴보면, 기업이 HR 솔루션을 도입할 때 무엇부터 하지 말아야 하는지가 선명해집니다.

첫 설정에서 모든 근무자를 하나의 규칙으로 묶었습니다

본사 기준을 전 직원에게 그대로 적용한 실수

A기업은 HR 솔루션을 빠르게 개통하려고 본사 사무직의 출퇴근 기준을 기본값으로 지정했습니다. 오전 출근과 오후 퇴근 시간이 일정한 직원에게는 문제가 없었지만, 시차출퇴근자·현장직·외근직·교대근무자에게 같은 규칙을 적용하면서 오류가 시작됐습니다. 현장 직원이 업무 장소에 제시간에 도착했어도 본사 출입 기록이 없다는 이유로 지각처럼 보였고, 야간근무자의 퇴근은 다음 날 기록으로 분리됐습니다.

담당자는 처음에 직원들의 입력 실수라고 판단해 수동 수정을 요청했습니다. 그러나 수정 건수가 늘어날수록 승인자와 인사팀의 업무만 증가했습니다. 예외가 많은 것이 아니라 서로 다른 근무 집단을 억지로 한 정책에 넣은 것이 진짜 원인이었습니다. 조직과 사람을 적절히 배치하고 운영하는 인사관리의 개념은 인사관리 용어 설명에서도 확인할 수 있습니다.

설정을 고칠 때는 직원이 아니라 근무 유형부터 나눴습니다

A기업은 부서명만 보고 정책을 나누던 방식을 중단했습니다. 같은 영업부 안에도 사무실 상주자와 외근 중심 직원이 있었기 때문입니다. 이후 실제 일하는 방식을 기준으로 근무 유형을 분류하고, 유형마다 출퇴근 인정 방식과 승인 흐름을 다시 연결했습니다. 인사팀이 임의로 이름을 붙이지 않고 현업 관리자와 직원에게 실제 하루 일과를 확인한 것도 중요한 변화였습니다.

• 고정근무형: 정해진 출퇴근 시각과 휴게 기준을 사용하는 집단
• 유연근무형: 출근 가능 시간대와 필수 협업 시간을 별도로 관리하는 집단
• 현장·외근형: 사무실 출입 기록보다 업무 장소와 승인 기록이 중요한 집단
• 교대근무형: 날짜를 넘기는 근무와 교대조별 일정 처리가 필요한 집단

처음부터 전사 공통 규칙을 만들려고 하지 마세요. 실제 근무 유형 세 가지 정도를 먼저 골라 시험하면 예외처럼 보이던 문제가 정책 차이인지 입력 오류인지 구분하기 쉬워집니다.

자동화를 서두르다 승인 없는 기록까지 확정했습니다

자동 계산을 자동 판단으로 오해한 순간

근무 유형을 나눈 뒤 A기업은 처리 속도를 높이겠다며 자동 승인 범위를 크게 설정했습니다. 시스템이 출퇴근 시각을 계산하면 결과도 정확할 것이라고 믿은 것입니다. 하지만 외근 후 복귀하지 않은 직원, 교육 장소에서 바로 퇴근한 직원, 긴급 장애 대응으로 밤늦게 일한 직원의 맥락은 단순한 시각 데이터에 담기지 않았습니다.

특히 위험한 부분은 원본 기록과 확정 기록을 구분하지 않은 것이었습니다. 모바일 체크 시각, 출입 데이터, 직원의 사유 입력이 한 화면에 섞였고 관리자는 어떤 값이 자동 수집됐으며 누가 수정했는지 알아보기 어려웠습니다. HR 솔루션은 계산을 빠르게 해주지만, 기록이 적절한지 판단하는 책임까지 대신하지는 않습니다. 자동화 범위를 넓히기 전에 데이터의 출처와 확정 권한부터 설계해야 합니다.

수집·검토·확정을 분리해 오류를 되돌렸습니다

개선 과정에서는 근태기록을 세 층으로 구분했습니다. 첫 번째는 기기나 앱이 수집한 원본, 두 번째는 직원이 사유를 보완한 신청 기록, 세 번째는 관리자가 확인한 확정 기록입니다. 수정 이력에는 변경 전후 값과 처리자, 처리 시각, 사유가 남도록 했습니다. 이 구조를 적용하자 직원은 자신의 기록이 왜 바뀌었는지 확인할 수 있었고, 인사팀도 월말마다 메신저 대화를 뒤질 필요가 줄었습니다.

1. 수집: 출입 장치, 모바일, PC 등 데이터가 들어오는 경로를 표시합니다.
2. 보완: 누락이나 예외가 있을 때 직원이 사유와 증빙을 제출하게 합니다.
3. 검토: 팀 관리자가 실제 일정과 업무 상황을 확인합니다.
4. 확정: 마감 이후에는 일반 사용자가 값을 임의로 바꾸지 못하게 합니다.
5. 재처리: 마감 후 수정은 별도 신청으로 받아 변경 흔적을 보존합니다.

이때 모든 건을 사람이 확인하면 자동화의 장점이 사라집니다. 정상 범위 안의 기록은 자동 통과시키고, 누락·중복·근무일 불일치처럼 정해진 조건에 해당하는 건만 검토함으로 보내는 방식이 현실적입니다. 여러분의 시스템은 ‘정상 기록을 빨리 처리하는 기능’과 ‘이상 기록을 눈에 띄게 만드는 기능’ 중 어디에 더 치우쳐 있나요?

인사팀만 시험한 뒤 전사에 공개해 문의가 폭증했습니다

기능 테스트는 통과했지만 실제 업무는 통과하지 못했습니다

A기업 인사팀은 출근 등록, 휴가 신청, 승인, 월 마감 기능을 직접 시험한 뒤 전사 오픈을 결정했습니다. 테스트 계정에서는 모든 기능이 정상적으로 움직였습니다. 그러나 실제 공개 첫날에는 팀장 겸직자의 승인함이 나뉘고, 신규 입사자의 근무 일정이 비어 있으며, 휴직 복귀자의 권한이 갱신되지 않는 문제가 동시에 발생했습니다.

인사팀이 확인한 것은 버튼의 작동 여부였고 직원들이 겪는 것은 업무 흐름 전체의 연결 문제였습니다. 채용된 구성원이 조직과 직책에 배치되고 승인자로 연결되는 과정까지 살피지 않으면 근태 기능만 정상이어도 운영은 실패할 수 있습니다. 채용의 기본 개념과 조직 유입의 의미는 채용 관련 지식백과를 함께 참고하면 이해하기 쉽습니다.

대표 사용자로 작은 실패를 먼저 만들었습니다

재설정 후에는 전사 공개 전에 대표 사용자 집단을 운영했습니다. 오래 근무한 사무직만 고르지 않고 신입사원, 현장 직원, 유연근무자, 팀장, 겸직자처럼 서로 다른 조건의 사용자를 포함했습니다. 이들에게 단순히 “써보고 의견을 주세요”라고 요청하는 대신 실제로 자주 일어나는 상황을 과제로 제시했습니다.

• 출근 기록이 누락된 날에 보완 신청을 제출하고 승인 결과를 확인합니다.
• 오전 반차와 외근이 같은 날 겹쳤을 때 표시되는 근무시간을 확인합니다.
• 승인자가 자리를 비운 상황에서 대결 또는 위임 흐름이 작동하는지 봅니다.
• 입사·부서 이동·휴직 복귀 후 일정과 권한이 자동으로 연결되는지 시험합니다.
• 월 마감 뒤 잘못된 기록을 발견했을 때 재요청 경로가 보이는지 확인합니다.

테스트 결과는 ‘불편하다’라는 감상보다 완료 시간, 클릭 횟수, 문의 발생 지점, 오류 재현 조건으로 기록했습니다. 예를 들어 직원이 근태 수정 메뉴를 찾는 데 4분이 걸렸다면 교육 부족으로만 치부하지 않고 메뉴명과 화면 위치를 함께 검토했습니다. 사용 설명을 길게 써야만 이해되는 기능은 설정이나 화면 구조가 복잡하다는 신호일 수 있습니다.

시범 운영의 목표는 오류가 없는 척하는 것이 아닙니다. 전사 공개 전에 값싼 실패를 충분히 발견하고, 문의가 발생했을 때 누가 어떤 기준으로 답할지도 연습하는 데 있습니다.

모든 예외를 없애야 한다는 생각도 운영을 망칩니다

규칙을 지나치게 단순화하면 현장의 사정이 사라집니다

실패 사례를 접하면 “예외를 없애고 규칙을 하나로 통일하면 되지 않나요?”라는 반대 의견이 나옵니다. 공통 기준이 많을수록 교육과 관리가 쉬워지는 것은 사실입니다. 하지만 고객 방문이 잦은 영업 조직과 생산 일정에 맞춰 교대하는 현장 조직을 동일하게 다루면 단순함의 비용을 직원이 떠안게 됩니다. 매번 수정 신청을 해야 하는 시스템은 표면적으로만 표준화됐을 뿐 실제로는 수작업을 양산합니다.

반대로 현장의 모든 요구를 별도 규칙으로 만들면 HR 솔루션이 지나치게 복잡해집니다. 직원 한 명의 특수 상황을 새로운 정책으로 추가하다 보면 비슷한 이름의 근무제가 늘고, 담당자가 바뀌었을 때 설정 의도를 설명하기 어려워집니다. 따라서 예외를 없애는 것과 예외를 통제하는 것은 다르다는 관점이 필요합니다. 인사관리의 범위와 역할에 관한 또 다른 설명은 인사관리 개념 자료에서도 살펴볼 수 있습니다.

반복되는 예외만 정책으로 승격했습니다

A기업은 모든 요청을 즉시 시스템 설정으로 만들지 않았습니다. 먼저 임시 승인 절차로 처리하면서 발생 빈도와 영향 범위를 기록했습니다. 같은 유형이 여러 부서에서 반복되고, 기존 규칙으로 처리할 때 오류나 불필요한 업무가 계속 생기는 경우에만 정식 정책 후보로 올렸습니다. 반면 일회성 행사나 개인의 단기 일정은 별도 사유와 승인 기록으로 남겼습니다.

1. 빈도를 확인합니다. 한 번 발생한 특수 상황인지 매월 반복되는 근무 형태인지 구분합니다.
2. 대상 범위를 봅니다. 개인 한 명의 요청인지 직군 전체의 실제 업무 방식인지 확인합니다.
3. 기존 정책으로 처리한 비용을 계산합니다. 수정 횟수, 승인 시간, 문의량을 함께 기록합니다.
4. 새 규칙의 설명 가능성을 검토합니다. 직원이 한두 문장으로 이해하기 어렵다면 더 단순한 대안을 찾습니다.
5. 종료 조건을 둡니다. 프로젝트성 근무 규칙은 종료일과 재검토일을 설정합니다.

이 방식의 장점은 표준화와 유연성 중 하나를 무조건 선택하지 않아도 된다는 점입니다. 공통 원칙은 단순하게 유지하되 반복되는 현실만 설정에 반영하면 됩니다. 좋은 인사관리 솔루션은 예외가 전혀 없는 시스템이 아니라, 예외가 생긴 이유와 승인 과정, 변경 결과를 나중에도 설명할 수 있는 시스템입니다.

다만 기록과 승인을 강조하면 직원 감시가 심해진다는 우려도 타당합니다. 그래서 필요한 데이터만 수집하고 열람 권한과 보관 목적을 분명히 알리는 운영 원칙이 함께 있어야 합니다. HR 솔루션의 성공 기준을 ‘얼마나 많이 자동으로 기록했는가’가 아니라 직원과 관리자가 같은 기준을 신뢰할 수 있는가로 바꾸면, 통제와 편의 사이에서 더 현실적인 답을 찾을 수 있습니다.