내부 정책 수락을 추적하는 웹앱 만들기

정책 수락 추적이 해결하는 문제

정책 수락 추적은 특정 사람이 특정 정책의 특정 버전을 언제 수락했는지를 기록하는 과정입니다. "직원 정책 확인"처럼 생각하되, 나중에 증명하기 쉽고 검색 가능하며 일관되게 보관되는 방식으로 저장합니다.

누가 사용하고 왜 필요한가

다양한 팀이 각기 다른 이유로 필요로 합니다:

• HR: 핸드북 업데이트, 직장 내 행동규범, 원격근무, 복리후생 및 휴가 규정
• IT/보안: 허용 사용 정책, 비밀번호/2FA 기준, 장치 관리, 데이터 처리
• 법무/컴플라이언스: 규제 관련 정책, 이해상충, 내부고발 절차
• 매니저: 변경 후 팀이 필수 확인을 완료했는지 확인

이메일과 PDF 서명이 실패하는 이유

이메일 스레드와 "회신으로 확인" 워크플로우는 단순해 보이지만, 명확한 증거가 필요할 때 문제가 됩니다.

일반적 실패 모드는 다음과 같습니다:

• 증거 분실 또는 분산: 회신이 개인 받은편지함, 공유 메일박스, 오래된 티켓에 남아 있음
• 버전 관리 부재: 누군가 어떤 문구를 수락했는지 증명 불가
• 약한 보고 기능: "최신 업데이트를 누가 수락하지 않았나?"에 답하려면 수작업 필요
• 감사 어려움: 내부 검토나 외부 감사용 신뢰 가능한 기록을 추출하는 데 며칠이 걸릴 수 있음

추적 앱의 목표

웹 앱은 감사 준비가 된 수락 기록을 생성해야 합니다: 위조 방지 가능성은 낮추고 명확히 답할 수 있어야 합니다:

• 누가 수락했는가
• 어떤 정책을 수락했는가
• 어떤 버전을 수락했는가
• 언제 (가능하면 어떤 시스템/세션에서) 수락했는가

내부 정책의 경우 정식 전자서명 도구가 과하다고 판단되면 실무적인 전자서명 대안으로 작동합니다.

기대치 설정: 작게 시작하세요

MVP는 필수 항목(정책, 버전, 사용자, 타임스탬프)과 기본 상기 기능을 캡처하는 것으로 시작하세요. 이것이 안정화되면 자동화(SSO, 접근 제어, 에스컬레이션)와 더 강력한 보고 및 내보내기를 추가합니다.

요구사항과 이해관계자 정의

화면 설계나 기술 스택을 선택하기 전에 시스템 대상과 조직 내에서 "수락"이 법적·운영상 무엇을 의미하는지 합의하세요. HR, 보안, 법무가 나중에 간극을 발견해 재작업이 발생하는 일을 방지합니다.

이해관계자 및 목표 식별

대부분의 정책 수락 추적 도구는 네 가지 핵심 대상에게 서비스를 제공합니다:

• 직원: 어떤 기기에서든 정책에 빠르게 접근해 확인을 완료할 수 있어야 함
• 정책 소유자(HR, 보안, 법무, 재무): 업데이트를 게시하고 대상자를 지정하며 완료율을 확인
• 관리자(IT, People Ops): 사용자, 그룹, 통합, 예외(퇴사자, 계약직, 이름 변경)를 관리
• 감사자/매니저: 누구가 무엇을 언제 어떤 버전으로 수락했는지 편집 없이 증거 확인

각 그룹의 성공 기준을 캡처하세요. 예를 들어 보안팀은 "입사 후 7일 내 수락"을, HR은 "특정 지역에 적용"을 원할 수 있습니다.

무엇을 '수락'으로 볼 것인지 정의

요구되는 증거 수준을 명확히 하세요:

• 체크박스 + 제출(일반 기준): "읽었고 동의합니다"와 타임스탬프
• 이름 타이핑: 실수 클릭 주장의 가능성을 줄임
• OTP/재인증 단계: 정식 전자서명 없이도 고위험 정책에 유용
• 전자서명 대안: 법무팀이 더 강력한 부인방지(non-repudiation)를 요구하면 최소 통제(신원 확인, 변조 감지 로그)를 문서화

정책 텍스트가 제공되었지만 열람하지 않은 경우 수락을 유효로 할지, 사용자가 열람/스크롤해야 하는지 규칙을 명시하세요.

정책 유형과 범위 목록화

관리할 정책을 먼저 정하세요: 행동강령, 정보보안, 원격근무, NDA 부속합의, 지역/규제 관련 확인 등. 정책이 국가·엔티티·역할·근로 형태(직원 vs 계약직)별로 다른지도 기록하세요.

지원해야 할 컴플라이언스 요구사항

최소한 다음을 확인하세요:

• 감사 추적과 수락 이벤트의 불변성
• 보존 기간(기간 만료 후 처리 방식)
• 내보내기(CSV/PDF)와 내보내기 권한자
• 내부 검토용과 외부 감사용으로 필요한 증거

이미 온보딩 체크리스트나 HRIS 워크플로우가 있다면 지금 메모해 통합을 설계하세요.

수락 워크플로우 매핑

명확한 워크플로우는 확인을 일관되고 감사 친화적으로 만듭니다. 가장 단순한 경로로 시작하고 규제/리스크/교육 필요에 따라 선택적 단계를 추가하세요.

가장 단순한 엔드-투-엔드 흐름

1. 정책 게시: 관리자가 정책을 "활성"으로 표시하고 발효일을 설정

2. 직원 통지: 시스템이 정책 링크와 함께 이메일/Slack/Teams 메시지를 발송

3. 직원 수락: 직원이 로그인해 정책을 읽고 "동의"를 클릭. 타임스탬프와 정책 버전 기록

4. 보고: 컴플라이언스 또는 HR이 완료율을 보고 CSV로 내보냄

이 흐름만으로도 많은 조직에 충분합니다 — 특히 누가 어떤 버전을 언제 수락했는지를 신뢰성 있게 증명할 수 있다면요.

고려할 선택적 단계

퀴즈 또는 이해도 체크

정책이 안전, 재무, 규제 행위에 영향을 주는 경우 짧은 퀴즈를 사용하세요. 퀴즈 점수(합격/불합격)를 저장하고, 합격하지 않으면 수락을 허용할지 여부를 결정하세요.

업데이트 시 재수락

정책 변경 시 모든 수정이 재수락을 필요로 하진 않습니다. 실무적 접근은 게시자가 새 버전에 대해 "수락 필요"를 선택했을 때만 재수락을 트리거하는 것입니다.

매니저 후속조치

매니저 가시성이 필요하면 매니저가 연체자를 보고 알림을 보낼 수 있는 경량 뷰를 추가하세요.

수락 기간 및 에스컬레이션

표준 수락 창(예: 통지 후 14일)과 다음 같은 에스컬레이션 규칙을 정의하세요:

• 7일 후 상기(미수락 시)
• 12일 후 두 번째 상기
• 14일째 매니저/HR에 에스컬레이션

예외는 명확히: 휴직, 계약직, 역할 기반 제외 등.

수락이 접근을 차단해야 하나요?

고위험 정책의 경우 특정 도구 사용 전에 확인을 요구할 수 있습니다(예: 경비 처리 시스템, 고객 데이터 플랫폼). 이 경우 워크플로우에 문서화하세요: "기한 초과 시 접근 제한" vs "접근 허용하되 에스컬레이션". 위험 감소와 업무 방해 최소화 사이에서 균형을 선택하세요.

정책 콘텐츠, 버전 관리 및 변경 통제

감사나 내부 검토에서 수락 기록이 통용되려면 각 수락이 정확한 불변 정책 버전을 가리켜야 합니다. "행동강령을 수락했다"는 모호하지만, "행동강령 v3.2(발효 2025-01-01)를 수락했다"는 검증 가능합니다.

게시된 각 정책 버전을 불변으로 취급하세요

게시 후 오탈자, 형식 수정, 설명 보강 등으로 편집되는 일이 잦습니다. 앱이 "항상 최신 텍스트만 저장"하면 과거 수락 기록 아래에서 문서가 조용히 변경될 수 있습니다.

대신 매번 게시할 때 새 버전을 만들고 해당 버전을 읽기 전용으로 보관하세요:

• 불변 스냅샷(일반적으로 생성된 PDF)을 저장하거나
• 수락 시 표시된 렌더링된 HTML을 정확히 저장하고 잠금

이렇게 하면 사용자가 본 "내용"을 나중에 재현할 수 있습니다.

각 버전에 캡처할 메타데이터

정책 콘텐츠와 정책 정체성은 분리하세요. 안정된 정책 ID(예: HR-COC-001)가 모든 버전을 묶어줍니다.

게시된 각 버전에 대해 저장할 항목:

• 버전 번호(v1.0, v1.1 등)
• 발효일
• 소유자(담당 팀/사람)
• 변경 요약(무슨 변경인지 평문으로)

이 메타데이터는 직원에게 무엇이 바뀌었는지 보여주어 재수락 이유에 대한 신뢰를 쌓습니다.

재수락 규칙 정의(중대 vs 경미)

모든 편집이 재수락을 유발할 필요는 없습니다. 단순 규칙을 만드세요:

• 중대 변경(의미·의무·벌칙·안전 조치): 재수락 필요
• 경미 변경(형식, 오타, 끊긴 링크): 재수락 불필요

버전별로 "재수락 필요" 플래그를 구현하고 수락 화면에 간단한 이유를 표시하세요.

데이터 모델: 저장해야 할 항목

명확한 데이터 모델은 정책 수락 추적을 신뢰 가능하고 검색 가능하며 감사 친화적으로 만듭니다. 목표는 단순합니다: 언제든지 "누가 무엇을 언제까지 수락해야 했고 어떤 증거가 있는가?"를 답할 수 있어야 합니다.

핵심 테이블/오브젝트

최소한 다음 오브젝트를 계획하세요(이름은 기술 스택에 따라 달라질 수 있음):

• Users: 직원 ID, 이메일, 이름, 상태(활성/종료), 부서·위치·매니저 같은 선택적 속성
• Policies: 장기간 유지되는 컨테이너(예: Code of Conduct). 제목, 소유자, 카테고리, 상태(초안/게시/은퇴)
• PolicyVersions: 게시된 각 수정본. 버전 번호, 게시일, 발효일, 콘텐츠 참조(HTML/마크다운 또는 파일 스토리지 포인터)
• Assignments: 누가 어떤 PolicyVersion을 수락해야 하는지(부서/위치/그룹/특정 사용자), 기한 및 규칙 포함
• Acceptances: 사용자 + policyVersion + assignment에 연결된 수락 이벤트
• Reminders(선택): 예약된 알림, 마지막 전송 시간, 에스컬레이션 수준

상태 및 타겟팅

상태는 사용자별·버전별로 모델링하세요:

• pending(할당되었지만 미수락)
• accepted(해당 버전 수락)
• expired(새로운 필수 버전 때문에 이전 수락이 무효화)
• exempt(명시적 면제, 사유 포함)

대상 지정 지원을 위해 부서/위치를 User 레코드에 저장하거나 조인 테이블(Departments, Locations, UserDepartments)을 사용하세요.

증거 필드(당신의 "증거")

Acceptances에 캡처할 것:

• 수락 타임스탬프(서버 시간)
• policyVersionId(정확히 어떤 텍스트를 수락했는지)
• 선택적으로 IP 주소와 사용자 에이전트(개인정보 정책이 허용할 경우)
• 수락 방법(웹, 모바일, 키오스크)
• 추가 무결성 검사가 필요하면 "동의" 문구/버전 해시

인증, 역할 및 접근 제어

정책 수락 앱의 신뢰성은 아이덴티티와 권한에 달려 있습니다. 모든 "동의"는 정확한 사람과 연결되어야 하고, 누가 무엇을 변경할 수 있는지 명확해야 합니다.

로그인 옵션

중견·대기업에서는 Single Sign-On을 사용해 신원이 HR/IT의 진실 소스와 일치하도록 하세요:

• SSO (OIDC 또는 SAML): 중앙화된 접근, 비밀번호 감소, 오프보딩 간소화
• 이메일 + 비밀번호: IdP가 없는 소규모 조직에서 허용되지만 가능하면 MFA 추가

둘 다 지원하면, 가능할 때 SSO를 우선 사용하고 계약직이나 파일럿 팀을 위해 비밀번호 로그인을 예비로 두세요.

역할과 권한

역할은 실제 책임에 맞게 단순하게 유지하세요:

• 직원: 할당된 정책 조회, 수락, 개인 기록 조회
• 정책 소유자: 초안 생성·편집, 업데이트 제안, 완료 모니터링
• 관리자: 사용자 관리, 소유자 지정, 통합 설정, 게시 제어
• 감사자(읽기 전용): 기록 검색 및 내보내기 가능, 수정 불가

실수를 방지하는 접근 규칙

인증/인가 레이어에 몇 가지 강력한 규칙을 두세요:

• 게시 권한은 관리자만(또는 게시 취소/은퇴)
• 소유자는 초안 작성 및 승인 요청 가능, 게시 후 히스토리 수정 불가
• 감사자는 내보내기 가능하지만 내보내기 행위는 로그에 남기고 범위를 제한

오프보딩과 기록 보존

사용자가 퇴사하면 수락 기록을 삭제하지 마세요. 대신:

• 계정을 비활성화(또는 IdP 비활성화에 의존)
• 사용자 ID + 당시 표시 이름/이메일과 함께 수락 기록 보존
• 역사의 증거를 유지하면서 전 직원 프로파일 접근은 관리자/감사자만 허용

앱에 포함되어야 할 UX 화면

좋은 UX는 "정책 포털이 있다"에서 "사람들이 제때 확인을 완료한다"로 바꿉니다. 화면 수를 작게 유지하고 다음 단계가 명확하게 보이게 하며, 나중에 무슨 일이 있었는지 증명하기 쉽게 만드세요.

직원용 화면

1) My Policies (대시보드)

가장 많이 사용되는 홈 화면입니다. 할당된 정책에 대해 다음을 보여주세요:

• 기한 및 긴급도(예: "5일 남음")
• 상태(미시작 / 열람됨 / 수락됨)
• 명확한 기본 액션("검토 & 수락")

대형 조직을 위해 "연체"와 "완료" 필터 및 검색을 추가하세요.

2) Read & Accept

읽기 경험은 방해 요소를 제거하세요. 정책 제목, 버전, 발효일, 끝부분의 명확한 확인 섹션을 포함하세요.

PDF를 표시하면 모바일에서 읽기 쉬운 뷰어, 확대/축소, "PDF 다운로드" 대체 링크를 제공하세요. 접근성을 위해 HTML 버전도 제공 고려.

3) Acceptance History

직원은 자신이 무엇을 언제 수락했는지 볼 수 있어야 합니다. 정책명, 버전, 수락 일시, 수락된 버전 링크를 포함하세요. 이는 "내가 완료했는지 확인해 달라"는 지원 요청을 줄여줍니다.

관리자/소유자 화면

1) 정책 편집기

관리자는 정책 레코드 생성, 콘텐츠 업로드, 향후 재수락 사이클을 위한 짧은 변경 요약 작성 필요

2) 게시 & 대상 지정

초안과 게시를 분리하세요. 게시 화면은 잘못된 버전을 실수로 보낼 수 없게 하고, 누가 할당되는지(부서, 위치, 역할, 전체 직원)를 명확히 보여줘야 합니다.

매니저 화면(선택 사항)

간단한 "팀 완료" 페이지가 충분한 경우가 많습니다: 완료율, 연체자 목록, 한 번의 클릭으로 후속 알림 전송.

접근성 기본

UI 레이블은 명확하고 평이한 언어 사용, 키보드 네비게이션 지원, 스크린 리더를 위한 적절한 제목과 버튼 레이블, 높은 대비 유지. 직원이 노트북 없이도 확인을 완료할 수 있도록 모바일 우선 레이아웃 설계.

감사 추적 및 수락 증거

감사 추적은 신뢰할 수 있어야만 유용합니다. 감사자나 내부 조사관은 변조 불가능한 스토리를 원합니다: 어떤 정책 버전이 제시되었고, 누가 받았고, 어떤 행동이 언제 일어났는지.

신뢰 가능한 감사 추적의 요소

강력한 추적은 네 가지 특성을 가집니다:

• 불변 이벤트: 일단 기록되면 편집/삭제 불가. 수정이 필요하면 수정 이유를 설명하는 새 이벤트 추가
• 신뢰 가능한 타임스탬프: 모든 이벤트에 서버측 타임스탬프(및 시간대) 기록
• 행위자 신원: 누가 행동했는지(직원, 매니저, 관리자, 시스템), 사용자 ID 및 인증 방식 등 저장
• 컨텍스트: 정책 ID + 정확한 버전과 사용자를 타겟팅한 할당 범위(팀, 위치, 역할)

기록해야 할 이벤트

최소한 다음을 캡처하세요:

• 정책 게시(버전 번호 및 발효일 포함)
• 할당 생성/변경(누가 할당되었는지, 어떤 규칙 또는 관리자 액션으로 되었는지)
• 상기 발송(채널, 수신자, 템플릿/버전)
• 수락 제출(사용자, 타임스탬프, 정책 버전, 웹/모바일 여부)

추가로 "정책 보관", "사용자 비활성화", "기한 변경" 같은 이벤트도 기록하되 핵심 이벤트는 일관되고 검색 가능하게 유지하세요.

감사 가능 기록을 보호하는 안전장치

신뢰를 저해하는 기능을 피하세요:

• 수락 기록 삭제 금지: UI나 DB에서 삭제 불가. 무효화가 필요하면 voided로 표시하고 이유와 실행자 로그 기록
• 관리자 메모를 통한 수정: 관리자 메모/이벤트(예: "잘못된 계정 보고; 수락 재귀속화")를 추가해 원본 수락을 편집하지 않음
• 증거 필드: (정당한 경우) IP 주소, 사용자 에이전트, 제출 해시 등은 전자서명 없이도 증거를 강화

읽음 확인 vs 수락 증거

페이지 열람, 스크롤, 머문 시간 같은 "읽음" 신호는 교육·UX에 유용하지만 동의를 증명하지는 않습니다. 수락은 명시적 행동(체크박스+제출, 이름 입력, "동의" 버튼)으로 특정 정책 버전에 연결되므로 강력합니다. 읽음 확인은 보조 메타데이터로 다루세요.

알림, 상기 및 에스컬레이션

알림은 "정책을 게시했다"에서 "직원들이 수락했음을 증명할 수 있다"로 만드는 차이입니다. 메시징을 워크플로우의 일부로 설계하세요.

사람들이 실제로 쓰는 채널 선택

대부분 조직은 한 가지보다 여러 채널을 사용합니다:

• 이메일: 공식적이고 검색 가능
• Slack/Teams: 빠른 행동 유도 및 응답률 증가
• 인앱 알림: 포털에 이미 접속한 사용자(특히 관리자·매니저) 대상

관리자는 캠페인별로 채널을 활성화/비활성화해 저위험 업데이트가 전사 스팸이 되지 않도록 하세요.

상기 규칙 설계(중단 시점 포함)

좋은 주기는 예측 가능하고 제한적입니다. 예시: 초기 통지, 3일 후 상기, 기한까지 주간 상기.

중단 조건을 명확히 하세요:

• 수락, 면제, 비활성화 또는 캠페인 종료 시 즉시 중단
• 사용자가 범위에서 벗어나면 중단

연체자에 대해선 단계별 에스컬레이션(직원 → 매니저 → 컴플라이언스) 추가. 에스컬레이션은 기한 기준(예: 7일 연체)으로 시행하고 항상 기한을 포함.

행동을 유도하는 템플릿 사용

템플릿에 자동 포함 항목:

• 정책명
• 버전/발효일
• 기한(해당 시)
• 수락 화면으로 바로 가는 단일 액션 링크(예: /policies/123/accept)

카피는 짧고 구체적이며 채널 간 일관되게 유지하세요.

현지화 잊지 마세요

다국어 인력이 있다면 템플릿 번역을 저장하고 사용자의 선호 언어로 발송하세요. 최소한 제목과 CTA를 현지화하고 번역이 없으면 기본 언어로 대체하세요.

보고, 대시보드 및 내보내기

보고는 정책 수락 추적이 실제로 유용해지는 지점입니다. 목표는 차트로 사람을 압도하는 것이 아니라 반복되는 질문에 빠르게 답하는 것: "끝났나?", "누가 늦었나?", "이 버전을 증명할 수 있나?"

중요한 지표

우선 다음 지표부터 시작하세요:

• 각 정책 버전의 완료율(수락/할당)
• 연체 사용자(수 및 목록), 가능하면 매니저나 팀별 그룹화
• 시간에 따른 수락 추이(일별/주별)
• 선택 사항: 수락까지 걸린 시간(할당부터 수락까지의 중앙값)

이 지표를 단일 대시보드에 표시해 HR/컴플라이언스가 한눈에 상태를 파악하게 하세요.

필터와 드릴다운

모든 숫자를 클릭 가능하게 해 사용자와 기록을 드릴다운할 수 있게 하세요. 일반 필터:

• 부서/팀
• 위치/사이트
• 정책 및 정책 버전
• 날짜 범위(할당일, 기한, 수락일)
• 상태(수락, 대기, 연체, 면제)

계약직 등 여러 근로형태를 지원하면 할당·보고에 필요할 때만 worker type 필터 추가.

내보내기와 "감사 패킷"

내보내기는 내부 감사 요청에 빠르게 대응하는 방법입니다:

• CSV 내보내기: 스프레드시트 분석용(안정된 ID, 타임스탬프, 정책 버전 포함)
• PDF 내보내기: 사람이 읽기 쉬운 요약
• 정책 버전별 감사 패킷 뷰: 정책 제목+버전, 게시/발효일, 할당된 사람, 수락자(타임스탬프 포함), 남은 대기자/연체자 등 핵심을 번들로 제공

감사 패킷은 원클릭으로 PDF 저장 가능하게 설계하세요. 별도 감사 추적 페이지가 있으면 패킷에서 링크(예: "전체 이벤트 이력 보기")를 연결.

과다 수집 피하기

보고는 추가 개인정보를 수집하게 해서는 안 됩니다. 수락 증빙과 후속 조치 관리에 필요한 항목만 수집하세요:

• 민감한 속성 대신 부서/위치 선호
• 필요한 것 이상 개인 정보 노출 금지(이름, 업무용 이메일/ID 정도만)
• 자유 텍스트 필드는 필수이고 통제된 경우에만 내보내기에 포함

간단한 보고 레이어는 보안이 쉽고 대부분의 컴플라이언스 요구에 충분합니다.

보안, 프라이버시 및 데이터 보존

정책 수락 앱은 감사 및 HR 분쟁 시 진실의 원천이 될 수 있으니 기록 시스템처럼 취급하세요. 보안 및 보존 결정을 명확히 문서화하고 설명하기 쉽게 만드세요.

보안 기본(비타협 항목)

모든 곳에서 HTTPS 사용(내부 환경 포함) 및 HSTS 적용. 세션 강화: secure, httpOnly 쿠키, 관리자용 짧은 유휴 타임아웃, CSRF 보호, 안전한 비밀번호 재설정 플로우(Single Sign-On이 주 방법이라도 필요). 오프보딩 시 모든 디바이스에서 로그아웃.

최소 권한 원칙 적용. 대부분 직원은 정책 조회·수락만 필요합니다. 게시, 버전 변경, 내보내기는 소수 역할에만 허용하고 주기적으로 검토하세요.

프라이버시: 정당화할 수 있는 것만 수집

정당한 이유 없이 정교한 디바이스 지문, 지속적 위치, 과도한 IP 히스토리 등은 수집하지 마세요. 많은 조직에서 사용자 ID, 타임스탬프, 정책 버전 및 최소 메타데이터만으로 충분합니다.

IP 주소나 사용자 에이전트를 기록할 경우에는 투명하게 공개하세요: 무엇을 수집하고 왜 수집하며 얼마나 오래 보관하는지 내부 공지와 개인정보 문서에 일치시키세요.

데이터 보존(그리고 증명 가능하게 만들기)

레코드 유형별 보존 기간을 정의하세요: 정책 문서, 수락 이벤트, 관리자 액션, 내보내기 등. 법적/HR 요구사항에 맞게 수락 기록을 보관한 뒤 일관되게 삭제 또는 익명화하세요.

관리자용으로 보존 설정을 문서화된 장소(예: /security)에도 게시해 "얼마나 오래 보관하나요?"라는 질문에 코드 뒤져보지 않고 답할 수 있게 하세요.

백업 및 재해 복구

데이터베이스와 업로드된 정책 파일을 백업하고 복원 테스트를 정기적으로 수행하세요. 복구 후 무결성을 증명할 수 있도록 레코드의 고유 ID와 생성 시각을 보관하고 누가 데이터를 덮어쓰거나 삭제할 수 있는지 제한하세요.

빌드 계획: MVP 범위, 기술 선택, 테스트

컴플라이언스 가치를 증명하는 MVP로 시작

첫 릴리스는 한 가지 질문에 답할 수 있어야 합니다: "누가 어떤 정책 버전을 언제 수락했는지 증명할 수 있나?" 나머지는 선택적입니다.

MVP 범위(소규모 팀 기준 4–6주):

• 관리자가 정책 생성, 버전 게시, 대상자 선택(전체 직원 또는 특정 그룹)
• 직원이 할당된 정책을 보고 "확인" 클릭(타임스탬프 기록)
• 시스템이 버전화된 수락 기록을 저장하고 감사용 간단한 CSV 내보내기 제공
• 기본 상기(예: 3일·7일 후 이메일) 및 완료 대시보드

더 빠르게 진행하려면 채팅 기반 명세로 코드를 생성하는 워크플로우도 고려(예: Koder.ai 예시)는 가능하지만, 자체 코드로 전환할 준비와 소유권을 확보하세요.

단순하고 실용적인 스택

채용이 쉽고 배포가 간단한 스택을 선택하세요:

• 서버: Node.js(NestJS 또는 Express) 또는 Python(Django)
• DB: PostgreSQL
• UI: React(Next.js) 또는 서버 렌더링 Django UI로 복잡도 감소
• 백그라운드 작업: BullMQ(Node) 또는 Celery(Python) — 상기·에스컬레이션용
• 인증: 가능한 경우 OIDC 기반 SSO

단계별로 구축(정체 방지)

Phase 1 (MVP): 수락, 버전 관리, 내보내기, 기본 상기

Phase 2: HRIS 디렉터리 동기(Workday/BambooHR 등), 매니저 뷰, 에스컬레이션

Phase 3: 풍부한 보고, API 통합, 정책 저작 개선

통합 아이디어: 사용자 속성을 HRIS에서 야간 동기화; 기한 경과 시 Jira/ServiceNow 티켓 생성; /pricing에서 요금제·제한 노출; 관련 설명 글 /blog/policy-versioning-best-practices 추가.

테스트 체크리스트(절대 건너뛰지 마세요)

• 역할 권한: 관리자 vs 매니저 vs 직원; 최소 권한 강제
• 버전 재수락: 새 버전 게시 후 사용자가 다시 수락해야 하는지, 이전 수락은 불변인지 확인
• 상기: 올바른 수신자·타이밍·중단 조건, 수락 후 상기 중지
• 내보내기 정확성: CSV가 올바른 버전·타임스탬프·사용자 식별자를 반영하고 대시보드 합계와 일치하는지
• 엣지 케이스: HRIS 동기에서 종료된 사용자 처리, 사용자의 부서 변경, 정책 대상 변경 중간에 발생한 상황