초과근무 규칙을 갖춘 근무시간 기록 앱 — 주간 제출 및 승인

이 근무표 앱이 해결해야 하는 문제

초과근무 규칙이 있는 근무표 앱의 핵심은 단순히 근무시간을 기록하는 것이 아닙니다. 혼선을 막고 임금 실수를 줄이며 모든 사람에게 예측 가능한 프로세스를 제공하는 것입니다.

근무표가 스프레드시트나 채팅 메시지에 흩어져 있으면 작은 문제들이 빠르게 쌓입니다. 사람마다 템플릿이 다르고, 휴식시간을 기록하지 않거나 나중에 아무도 모르게 항목을 편집하기도 합니다. 관리자는 주간이 합리적인지 확인하기보다 누락된 시간을 쫓는 데 시간을 쓰게 됩니다. 급여일이 되면 불완전한 정보를 이어붙이며 직원 기억과 맞기를 바라는 상황이 됩니다.

초과근무는 분쟁이 시작되는 지점입니다. 규칙이 일관되지 않거나 사람들이 따르기 어렵게 쓰여 있으면 동일한 일정으로 일한 두 사람이 다르게 지급될 수 있습니다. 모두 선의로 행동하더라도 불분명한 규칙은 재작업을 낳습니다: 재계산, 소급 편집, 어색한 대화 등입니다.

승인은 돈이 움직이기 전의 안전장치입니다. 관리자 승인은 주간이 완전한지, 작업 또는 프로젝트 코드(사용할 경우)가 타당한지, 초과근무가 정당한지 확인합니다. 또한 명확한 ‘이것이 최종’이라는 순간을 만들어 급여 팀이 진행 중 초안의 숫자를 가져오지 않도록 합니다.

주간 제출은 간단한 습관이 되어야 합니다: 모두가 정의된 근무주(예: 월~일) 안에서 근무하고, 명확한 마감(예: 월요일 오전 10시)에 제출하며, 마감 전 알림을 받습니다. 제출 후에는 편집을 차단하거나 재승인이 필요하도록 하고 상태는 분명히 보여야 합니다(예: Draft, Submitted, Approved, Rejected).

핵심 요구사항과 범위

이런 앱은 모두가 기본 사항에 초기에 동의할 때만 작동합니다: 언제 제출하는지, 누가 무엇을 변경할 수 있는지, 무엇이 초과근무로 간주되는지. 경계를 초기에 정하지 않으면 앱은 주간 논쟁의 장이 됩니다.

제출 리듬부터 시작하세요. 대부분 팀에는 주간 제출이 단순합니다: 주중에 시간을 입력하고 한 번 제출합니다. 핵심 경계는 제출 후 편집을 허용할지 여부입니다. 흔한 규칙은 Submit 버튼을 누를 때까지 항목은 편집 가능하다는 것입니다.

초과근무 규칙은 모호하면 안 됩니다. 일별 한도(예: 하루 8시간 초과), 주별 한도(예: 주 40시간 초과) 또는 둘 중 어느 것으로 초과근무를 판단할지 결정하세요. 둘 다 적용된다면 겹칠 때 어느 규칙을 우선할지 명시해 중복 계산이 되지 않게 하세요.

관리자 승인은 빠르게 사용할 수 있는 짧은 루프를 유지해야 합니다: 승인(시간이 최종이 됨), 변경 요청(직원이 수정 후 재제출), 또는 거절(직원이 수정 후 재제출).

승인되면 기간을 잠그세요. 잠금은 막판 편집을 막아 급여 일관성을 유지합니다. 수정이 필요하면 "사유와 함께 잠금 해제" 액션을 사용해 누가 왜 잠금을 해제했는지 기록하세요.

급여 내보내기는 승인된 시간만 포함해야 합니다. 이것을 엄격한 경계로 삼으세요: 승인되지 않은 항목은 미완성으로 보이더라도 내보내기에서 제외합니다.

(과도하게 복잡하게 하지 않고) 저장할 데이터

목표는 모든 것을 추적하는 것이 아니라 계산, 정책 적용, 누가 무엇을 승인했는지 증명할 만큼만 캡처하는 것입니다.

먼저 역할을 정의하세요. 대부분 팀에는 세 가지 역할이 필요합니다: 시간을 입력하는 직원, 승인하는 관리자, 그리고 내보내기와 설정을 담당하는 급여(또는 관리자). 권한을 단순하게 유지해 사람들이 불필요하게 막히지 않게 하세요.

저장할 최소 레코드

사람, 주간 근무표, 개별 시간 항목의 세 계층으로 생각하세요.

각 사람에 대해 기본 정보(이름, 사번이나 이메일, 역할, 관리자, 팀 또는 원가 센터)를 저장하세요. 각 근무표에 대해서는 소유자, 주 시작일, 그 주에 사용된 타임존, 상태(Draft, Submitted, Approved, Rejected)를 저장하세요. 각 시간 항목에는 날짜, 시작 시간, 종료 시간, 휴식 분, 프로젝트 또는 작업, 짧은 메모를 캡처하세요.

또한 주 시작 요일(월 또는 일)과 규칙에 사용할 타임존 같은 캘린더 설정을 저장하세요. 급여가 필요하면 위치나 부서 같은 선택적 컨텍스트를 추가하세요.

저장해 두면 좋은 승인 및 감사 필드

승인은 분쟁이 발생하는 곳이므로 지루하지만 명확한 감사 기록을 작게 유지하세요:

• Submitted at, submitted by
• Approved at, approved by
• Rejected at, rejected by, rejection reason
• Last edited at, last edited by
• Locked 플래그(승인 후 편집 방지)

예: 베를린의 직원이 일요일 밤에 제출하면, 그 주에 사용된 타임존을 저장하면 뉴욕의 관리자가 볼 때 제출 시간이 월요일로 보이는 고전적 문제를 피할 수 있습니다.

이 필드들만 캡처해도 초과근무 규칙을 실행하고 승인 라우팅을 하며 급여에 깔끔한 합계를 내보낼 수 있습니다. 앱을 복잡한 HR 시스템으로 만들 필요는 없습니다.

먼저 평이한 문장으로 초과근무 규칙 정의하기

정책을 누구나 읽을 수 있는 간단한 문장으로 작성하세요. 명확히 설명할 수 없으면 앱이 급여에서 놀라움을 만들어냅니다.

시작은 트리거를 선택하는 것부터: 하루 8시간 초과 시 초과근무, 주 40시간 초과 시 초과근무, 또는 둘 다. 둘 다 사용하면 순서를 정하세요. 일반적인 선택은 먼저 일일 초과근무를 계산하고, 남은 정상 시간에 대해 주간 초과근무를 적용하는 것입니다.

어떤 시간이 근무시간으로 계산되는지도 명확히 하세요. 무급 휴식은 모든 것을 바꿀 수 있으니 명확히 밝히세요: “점심은 무급이며 근무시간에 포함되지 않습니다.” 반올림 규칙이 있다면 그것도 적으세요. 예: “출퇴근 시간을 분 단위로 반올림할 경우 5분 단위로 반올림한다.” 작은 반올림 선택이 한 달이면 누적됩니다.

특수일도 다루세요. 주말, 휴일, 이동시간은 다른 지급 규칙이 있는 경우가 많습니다. 추가 지급을 하지 않더라도 “토요일 근무는 주간 총합이 40시간을 초과하지 않는 한 평일과 동일하게 처리한다”처럼 명확한 문구가 필요합니다.

복사해 쓸 수 있는 정책 문장 예시:

• “초과근무는 하루 8시간 초과 근무한 시간입니다.”
• “주간 초과근무는 하루 초과근무로 이미 계산된 시간을 제외한, 정상 시간 40시간 초과분에만 적용됩니다.”
• “무급 휴식은 제외하며, 유급 휴식은 포함합니다.”
• “휴일 근무는 1.5배로 지급하며 주간 초과근무에 포함하지 않습니다.”
• “현장 간 이동시간은 포함되며, 통근은 포함하지 않습니다.”

이 문장들에 동의하면 로직을 구현하는 일은 논쟁이 아니라 번역 작업이 됩니다.

단계별: 주간 제출 워크플로우

주간 흐름은 모두가 무엇이 “이번 주”에 해당하는지, 언제 제출해야 하는지 알 때 가장 잘 작동합니다. 하나의 주 시작 요일을 선택하고(보통 월요일) 명확한 마감 시간을 정하세요(예: 직원 로컬 타임존 기준 월요일 오전 10시). 지각 제출은 허용하되 가시적으로 표시하세요.

1) 주 기간과 마감일 설정

주를 고정된 날짜 범위로 정의하고 근무표에 저장하세요. 누군가가 주중에 앱을 열거나 여행 중일 때 혼란을 피할 수 있습니다. 처음부터 상태 필드를 포함하세요(Draft, Submitted, Approved, Rejected).

2) 직원 근무표 화면 구성(항목 추가/수정)

항목 편집을 단순하게 유지하세요: 날짜, 시작 시간, 종료 시간(또는 총 시간), 휴식 시간, 프로젝트나 비용 코드(필요시), 짧은 메모. 직원이 전날 항목을 복사해 편집할 수 있도록 하세요. 이 한 가지 단축 기능이 주당 작업량을 크게 줄여줍니다.

3) 자동 합계 표시(정상 vs 초과근무)

항목이 추가될 때 주 합계를 상단에 표시하세요: 총 근무시간, 정상 시간, 초과근무 시간. 주가 완성되기 전까지는 분할이 추정일 수 있지만 실시간으로 업데이트되어 직원이 초기 단계에서 실수를 잡을 수 있어야 합니다.

필수 필드가 누락되면 합계가 “잘못된” 것처럼 보이지 않도록 명확한 경고를 표시하세요.

4) 제출 및 주 잠금

제출 버튼은 세 가지 일을 해야 합니다: 항목 검증(음수 시간 없음, 중복 없음, 필수 메모 확인), 상태를 Submitted로 변경, 편집 잠금. 변경이 필요하면 보통 관리자가 반려하거나 거절해 트리거하는 "Draft로 반환"을 통해 수정하게 하세요.

5) 관리자에게 알림 및 대기 큐 표시

제출되면 관리자는 간단한 큐를 봐야 합니다: 직원 이름, 주 범위, 총 시간, 표시된 문제(예: 누락된 메모)와 빠른 검토 화면. 제출 상태로 이동할 때 자동 알림을 여기서 보내기 좋습니다.

단계별: 관리자 승인 흐름

관리자는 한 화면에서 바로 무엇이 처리되어야 하는지 볼 수 있어야 합니다. 제출된 주의 짧은 큐를 보여주세요: 직원 이름, 주 범위, 총 시간, 초과근무 시간(있다면), 메모 유무 빠른 표시. 이 요약은 관리자가 모든 날짜를 눌러보지 않고도 문제를 발견하게 합니다.

주를 열면 결정은 일관되게 유지하세요:

• 승인: 주를 잠그고 급여 내보내기 준비 완료로 표시합니다.
• 반려(보내기): 직원에게 반려 사유와 함께 돌려보냅니다(필수 코멘트).
• 거절: 정책 문제(근무 누락, 잘못된 프로젝트, 중복 의심 등)인 경우 사용합니다.
• 위임: 관리자가 부재 중일 때 대체 승인자에게 라우팅합니다.

코멘트는 중요합니다. 반려나 거절 시 짧은 사유를 요구하고 레코드에 저장해 직원이 무엇을 고쳐야 하는지 정확히 알게 하세요.

각 결정 이후에 무엇을 변경할 수 있는지 명확히 하세요. 반려나 거절 후에는 직원이 항목과 메모를 수정하고 재제출할 수 있어야 합니다. 승인 후에는 기본적으로 편집을 차단하세요. 변경을 허용하려면 "주 다시 열기" 액션을 사용해 새 승인 사이클을 시작하게 하고 필요한 경우 두 번째 승인을 요구하세요.

부재를 대비해 백업 승인자를 팀별(또는 직원별)로 지정하고, 휴가 기간에는 HR이나 관리자 역할이 승인을 재할당할 수 있게 하세요.

누가 제출했는지, 누가 승인(또는 위임)했는지, 타임스탬프와 간단한 변경 로그(어떤 필드가 언제 바뀌었는지)를 감사 로그로 남기세요.

초과근무 계산 로직과 예외 처리

초과근무는 첫 혼란스러운 주가 나타나기 전까지는 단순하게 들립니다. 수학의 단일 출처를 정하고 직원이 보는 것, 관리자가 승인하는 것, 급여 내보내기가 일치해야 합니다.

어떤 값으로 계산할지 결정하세요: 일별 합계, 주별 합계, 또는 둘 다. 많은 정책은 하루 첫 8시간을 정상 시간으로 보고 그 초과분을 초과근무로 계산합니다. 다른 정책은 일일 한도를 무시하고 오직 주 40시간 초과만 보는 경우도 있습니다. 둘 다 사용한다면 중복 계산을 피하려면 순서를 정의하세요. 실무적인 접근은: 일별 초과근무를 먼저 계산하고 남은 정상 시간에 대해 주간 초과근무를 계산하는 것입니다.

미리 처리해야 할 예외 상황

다음 상황들이 합계를 망치거나 분쟁을 일으키기 쉽습니다:

• 분할 교대: 하루에 두 개 이상의 항목이 있으면 일일 합계로 합산하세요.
• 밤샘 근무: 시작과 종료를 단순 시간만이 아니라 전체 날짜-시간으로 저장하세요.
• 종료 시간 누락: 제출을 차단하거나 항목을 불완전으로 표시해 시간이 부풀려지지 않도록 하세요.
• 중복 및 음수: 겹치거나 시작 시간이 종료 시간보다 늦은 항목을 방지하세요.
• 반올림 규칙: 항목별로 반올림할지(예: 5분 단위) 아니면 일일 합계만 반올림할지 결정하세요.

사람들은 명확한 분해를 보면 스스로 고치는 속도가 빠릅니다. 각 요일의 정상 시간, 초과근무 시간, 무급 휴식을 보여주고 주간 요약을 제시하세요. 이상해 보이는 항목이 있으면 해당 항목을 강조해 보여주세요(예: “14:00–16:00와 중복됨”).

계산은 어디에서나 일관되게 유지하세요. 직원 화면, 관리자 보기, 보고서, 급여 내보내기 모두 동일한 초과근무 로직을 재사용하세요.

급여용 승인된 시간 내보내기

급여팀은 일반적으로 앱이 추적하는 모든 것을 원하지 않습니다. 예측 가능한 파일과 정확한 열 이름이 필요하고 정해진 일정에 맞춰 제공되길 원합니다. 이 부분을 초기에 결정하세요.

먼저 내보내기 형식에 합의하세요. 대부분 CSV가 일반적이지만 실제 핵심은 필드 목록과 열 이름입니다. 급여팀이 열 이름을 EmployeeID라고 지정하라고 하면 정확히 그렇게 맞추세요.

실무적 내보내기 파일은 보통 사번(이름이 아닌), 주 종료일(또는 주 시작·종료), 정상 시간과 초과근무 시간을 분리한 열, 원가 센터나 프로젝트 코드(노무 배분이 필요한 경우), 승인 타임스탬프와 승인자 ID를 포함합니다.

완전 승인된 주만 내보내세요. 승인을 게이트로 삼으세요: 승인되지 않으면 내보내지 않습니다.

수정은 팀들이 흔히 막히는 부분입니다. 내보낸 레코드를 제자리에서 편집하는 대신, 급여가 가져갈 수 있는 델타로 조정 항목을 만들어 처리하는 것이 깔끔합니다. 예: 42주차에 초과근무 5.0시간으로 내보냈는데 실제로 4.0시간이어야 하면 -1.0시간 조정 항목을 원래 주와 직원에 연결해 생성합니다.

내보내기를 배치로 저장해 급여가 안전하게 재실행할 수 있게 하세요. 각 배치에 내보내기 ID, 생성 일시, 사용된 필터(예: “Approved weeks ending 2026-01-18”)를 포함하세요. 급여가 같은 배치를 두 번 가져오면 내보내기 ID로 중복을 감지할 수 있습니다.

피해야 할 일반적인 실수와 함정

이 앱들이 실패하는 이유는 대개 단순합니다: ‘최종’ 상태가 불분명하거나, 시간 경계가 불명확하거나, 내보내기가 급여가 기대하는 것과 일치하지 않는 경우입니다.

첫 번째 함정은 주가 승인된 후에 사람들에게 편집을 허용하는 것입니다. 유연해 보이지만 숫자에 대한 신뢰를 깨뜨립니다. Approved는 잠금 상태로 취급하세요. 정말 변경이 필요하면 수정 요청을 요구하고 무엇이 왜 바뀌었는지 감사 기록을 남기세요.

초과근무 규칙을 기간 중에 변경하는 것도 흔한 분쟁 원인입니다. 규칙이 수요일에 변경되면 각 주에 어떤 버전을 사용했는지 문서화하세요. 그렇지 않으면 동일한 시간이더라도 서로 다른 초과근무 결과가 나옵니다. 간단히 “Policy v2 effective Jan 15” 같은 메모를 주에 붙여 두는 것만으로도 논쟁을 막을 수 있습니다.

타임존 결정은 합계를 조용히 망칠 수 있습니다. 하나의 규칙을 정하고 지키세요: 직원 로컬 타임존을 사용할지, 회사 급여 타임존을 사용할지. 아무것도 하지 않으면 심야 근무가 잘못된 날짜로 넘어가 일별 합계와 초과근무를 바꿀 수 있습니다.

코멘트 없는 승인은 시간을 낭비시킵니다. 관리자가 주를 거절하거나 반려할 때 짧은 이유를 요구해 직원이 무엇을 고쳐야 하는지 알게 하세요.

강제할 가치가 있는 몇 가지 규칙:

• 제출된 주는 관리자가 반려할 때까지 잠그세요.
• 승인된 주는 추적되는 수정 절차를 통해서만 열리게 하세요.
• 초과근무 정책은 버전 관리하고 시행일을 저장하세요.
• 하나의 타임존 규칙을 정하고 근무표에 표시하세요.
• 승인된 주만 내보내세요(Submitted나 부분 승인 상태는 제외).

롤아웃 전 빠른 체크리스트

누군가 시간 기록을 시작하기 전에 프로세스가 공정하고 예측 가능하게 느껴지도록 설정을 합의하세요.

캘린더 규칙을 고정하세요: 주 시작 요일(월요일 vs 일요일)과 제출 마감(예: “전 주는 월요일 오전 10시까지 제출”). 이를 문서화하고 UI에 반복적으로 표시해 사람들이 추측하지 않게 하세요.

초과근무 정책을 평이한 문장으로 작성한 후 실제 예시로 테스트하세요. 정상적인 한 주만 테스트하지 말고 늦은 교대, 식사 휴식 누락, 분할 교대 등 3–5가지 시나리오로 실험하세요.

롤아웃 체크는 실무적이어야 합니다:

• 주 시작 요일과 제출 마감이 설정되고 공지되었는가.
• 초과근무 규칙이 작성되어 3–5개 예시로 테스트되었는가.
• 관리자가 승인 전에 합계와 직원 메모를 볼 수 있는가.
• 급여 내보내기가 승인된 데이터만 포함하며 재현 가능한가.

잠금 정책에 특별히 주의하세요. 제출은 편집을 중지시켜야 하고, 승인된 주는 추적되는 수정 흐름을 제외하고는 사실상 변경할 수 없어야 합니다. 그렇지 않으면 급여는 움직이는 목표가 됩니다.

급여 내보내기는 지루하게 만드세요. 같은 기간에 대해 같은 숫자를 내보내야 하며 승인된 시간만 포함해야 합니다. 지난달 내보내기를 다시 실행했을 때 결과가 달라지면 롤아웃을 잠시 중단하고 먼저 고치세요.

현실적인 예시 시나리오

한 물류창고 팀은 월요일~일요일 주간에 40시간 초과 시 초과근무를 지급하고, 승인된 시간만 급여에 반영합니다. 각 직원은 주 1회 제출하고 관리자는 월요일 정오까지 승인해야 합니다.

Jordan은 이른 교대에서 일합니다. 금요일까지 Jordan은 38시간을 기록했습니다. 토요일에 급송 작업 때문에 늦게까지 남아 6시간을 추가로 기록했습니다. 일요일 밤 Jordan은 주를 검토하고 토요일 항목에 짧은 메모를 추가한 뒤 총 44시간으로 제출합니다.

월요일 아침 관리자 검토 시 앱은 간단한 분할을 보여줍니다: 정상 40시간, 초과근무 4시간. 관리자는 토요일 항목이 교대 종료 후에 생성된 것을 보고 상세를 요청합니다. Jordan은 시작 시간이 30분 어긋났음을 깨닫고 수정해야 합니다.

이미 제출된 근무표이므로 수정은 재제출 흐름으로 갑니다: 관리자가 "토요일 시작시간 수정 후 재제출"이라는 사유로 근무표를 거절합니다. Jordan은 토요일 항목을 수정하고 재제출하며 초과근무는 3.5시간으로 재계산됩니다.

관리자가 승인하면 급여는 그 주에 대해 깔끔한 내보내기를 받습니다: 사번과 이름, 주 시작/종료일, 승인된 정상 및 초과근무 시간, 선택적 원가센터나 위치(예: Warehouse A), 승인 타임스탬프와 승인자 이름.

출시 후 팀은 몇 가지 단순한 수치를 추적합니다: 지각 제출(일요일 이후 제출), 반려율(관리자가 근무표를 얼마나 자주 반려하는지), 제출에서 승인이 완료되기까지 평균 시간. 이 수치들이 올라가면 보통 규칙이 불분명하거나 알림이 부족함을 의미합니다.

다음 단계와 간단한 롤아웃 계획

첫 버전을 회사 전체 전환이 아닌 통제된 테스트로 취급하세요. 규칙과 초과근무가 보통 섞여 있는 한 팀을 선택하고 한 가지 명확한 초과근무 정책으로 시작하세요. 이렇게 하면 피드백이 집중되고 워크플로우가 끝에서 끝까지 작동하는지 증명할 수 있습니다.

파일럿을 2–4주 사이클로 운영하세요. 실제 제출을 몇 번 받아보면 사람들이 주저하는 지점, 관리자가 막히는 지점, 급여 내보내기가 재무가 기대하는 것과 일치하는지 확인할 수 있습니다.

실무적인 롤아웃 계획:

• 한 팀과 하나의 초과근무 정책으로 파일럿 시작(첫 주에는 특수 사례 생략).
• 가장 흔한 다섯 가지 질문을 수집하고 문제를 일으킨 화면이나 라벨을 수정.
• 소유권을 고정: 누가 초과근무 규칙, 지급 코드, 승인 설정을 업데이트하는지 명확히 함.
• 급여 내보내기 일정을 합의(예: 승인 마감 후 월요일 9:00).
• 수작업 내보내기가 두 급여 기간 연속으로 정확할 때만 하나의 통합을 추가.

작은 UI 텍스트 변경이 많은 지원 티켓을 줄입니다. 제출 흐름을 짧게 유지하고 사람들이 실제로 헤매는 곳에만 도움말 텍스트를 추가하세요.

정책 업데이트의 소유자를 초기에 결정하세요. HR은 초과근무 정의를, 급여는 내보내기 형식을, 관리자들은 승인 권한을 소유할 수 있습니다. 이러한 권한을 명확히 해두면 선의의 관리자가 급여 기간 중간에 설정을 바꾸는 일을 막을 수 있습니다.

코딩 없이 이걸 빌드하고 싶다면 AppMaster (appmaster.io)은 프로토타이핑과 시제품 배포에 한 가지 옵션입니다. 시각적 데이터 모델, 제출 및 승인용 드래그 앤 드롭 워크플로우, 웹/모바일 UI 빌더로 시작하고 파일럿으로 초과근무 로직과 급여 내보내기가 프로세스와 일치하는지 확인한 뒤 확장하세요.