정책 확인 앱, 직원을 위한 구조 만들기

정책 확인 기록이 어려워지는 이유

직원이 12명인 회사에서는 정책 이메일만으로도 충분할 수 있습니다. HR 담당자가 PDF를 첨부하고 모두에게 회신을 요청한 뒤, 답변을 이메일함에 저장하면 됩니다. 하지만 정책이 바뀌거나 팀이 커지면 이런 방식은 한계에 부딪힙니다. 관리자가 특정 직원이 특정 문서를 수락했다는 증거를 찾아야 할 때도 마찬가지입니다.

공유 폴더에는 다른 문제가 있습니다. 보통 최신 파일만 표시하고 누가 파일을 열었는지는 거의 보여 주지 않습니다. 접근 기록만으로는 누군가 정책을 읽었는지, 필요한 조치를 이해했는지, 정책을 따르겠다고 확인했는지 증명할 수 없습니다.

정책 확인 앱은 세 가지 사실을 분리해 관리합니다. 정책 내용, 정책 버전, 각 직원의 응답입니다. HR이 재택근무 규정, 비용 한도, 보안 요건을 수정하면 회사는 이전 버전을 보관하고 새 버전을 게시할 수 있습니다. 또한 각 직원이 어떤 버전을 확인했는지도 보여 줄 수 있습니다.

기록은 다음과 같은 실무적인 질문에 답할 수 있어야 합니다.

• 어떤 직원에게 정책이 언제 전달되었는가?
• 각 직원은 어떤 버전을 확인했는가?
• 응답을 제출한 시점은 언제인가?
• 기한을 놓친 사람은 누구인가?
• 정책이 업데이트되어 새 확인이 필요한가?

읽기와 확인은 서로 다른 행동입니다. 수신 확인은 누군가 이메일을 보았다는 사실만 알려 줄 뿐, «이 정책을 읽고 이해했습니다»와 같은 진술을 남기지는 않습니다. 공식적인 확인 기록에는 직원의 신원, 정확한 정책 버전, 시간, 응답이 포함되어야 합니다.

이런 구조가 없으면 HR은 이메일 대화, 스프레드시트 행, «행동강령 최종본», «행동강령 최종본 2»처럼 이름 붙은 파일을 비교하느라 몇 시간을 보낼 수 있습니다. 6개월 전 기록을 증명해 달라는 요청을 받기 전까지는 기록이 완전해 보일 수도 있습니다.

잘 설계된 앱은 각 정책에 안정적인 기록을 부여하고 직원에게 명확한 작업 하나를 제공합니다. 관리자는 회사 전체에 반복해서 알림을 보내는 대신 아직 응답하지 않은 사람에게만 후속 조치를 할 수 있습니다.

워크플로를 만들기 전에 역할 설정하기

누군가 문서를 업로드하기 전에 권한부터 설정하세요. 그렇지 않으면 관리자가 검토가 끝나지 않은 정책을 게시하거나, 업무상 필요가 없는 사람이 직원 응답을 볼 수 있습니다.

대부분의 팀에는 다섯 가지 역할이 필요합니다. 소규모 회사에서는 한 사람이 여러 역할을 맡을 수 있지만, 권한은 분리된 상태로 유지해야 합니다.

• 정책 소유자는 정책을 작성하고 업데이트하며 관련 질문에 답합니다.
• 검토자는 초안의 정확성, 법률 문구, 이해하기 쉬운 표현을 확인합니다.
• 게시자는 승인된 버전을 지정된 직원에게 공개합니다.
• 직원은 할당된 정책을 읽고 확인을 제출합니다.
• 관리자는 접근 권한, 그룹, 기록, 내보내기를 관리합니다.

초안 편집은 정책 소유자와 검토자로 제한하세요. 검토자는 초안에 의견을 남기거나 승인할 수 있지만, 그것이 업무에 포함되지 않는 한 직접 게시해서는 안 됩니다. 게시자는 필요한 승인이 기록된 후에만 버전을 공개해야 합니다. 이렇게 역할을 나누면 서둘러 작성한 초안이 공식 정책으로 게시되는 일을 막을 수 있습니다.

직원 응답에는 정책 자체보다 더 엄격한 접근 제한이 필요합니다. 관리자는 팀의 완료 현황을 봐야 할 수 있습니다. HR 또는 컴플라이언스 담당자는 이름, 날짜, 의견, 내보내기 파일이 필요할 수 있습니다. 대부분의 직원은 자신의 응답만 볼 수 있어야 합니다.

예를 들어 재택근무 정책 소유자가 재택근무 장비 지원 한도를 업데이트한다고 가정해 보겠습니다. HR이 문구를 검토하고, 피플 오퍼레이션 관리자가 버전 3을 게시한 뒤, 직원들이 읽었다고 확인합니다. 이후 감사가 필요해지면 관리자가 완료 기록을 내보낼 수 있습니다.

AppMaster에서는 사용자 역할, 직원 그룹, 정책 편집, 게시, 응답 보고를 위한 별도 화면으로 이런 권한을 구성할 수 있습니다. 각 사람에게 필요한 최소 권한부터 시작하고, 실제 업무상 필요할 때만 접근 권한을 넓히세요.

명확한 정책 및 버전 기록 만들기

모든 정책에는 신뢰할 수 있는 기록 하나가 필요합니다. «핸드북_최종_v3» 같은 파일 이름은 피하세요. 특정 날짜에 어떤 문서가 적용되었는지 직원, 관리자, 감사 담당자가 확인하려 할 때 혼란을 만듭니다.

정책 기록에는 이해하기 쉬운 제목, 카테고리, 소유자, 시행일, 첨부 문서를 포함하세요. 카테고리는 직장 내 행동, 보안, 복리후생, 재택근무 등으로 나눌 수 있습니다. 소유자는 질문에 답하고 변경 사항을 승인할 수 있는 특정 담당자나 팀이어야 합니다.

게시된 정책마다 1.0, 1.1, 2.0처럼 명확한 버전 번호를 부여하세요. 간단한 규칙이 효과적입니다. 문구를 조금 수정할 때는 다음 마이너 버전을 사용하고, 직원의 의무나 규칙이 바뀔 때는 새로운 메이저 버전을 부여합니다. 복잡한 번호 체계보다 일관성이 중요합니다.

초안과 게시된 정책 분리하기

직원에게는 승인된 정책만 보여야 합니다. 초안은 별도의 상태로 관리하세요. 정책 소유자는 그곳에서 문서를 수정하고 날짜를 확인하며 피드백을 요청할 수 있습니다. 초안이 게시된 버전을 그 자리에서 대체해서는 안 됩니다.

소유자가 업데이트를 게시하면 새 버전 기록을 만들고 이전 버전을 보존하세요. 이전 버전은 폐기 상태로 바꿀 수 있지만, 이력에는 계속 남아 있어야 합니다. 그래야 회사가 직원이 확인을 제출할 당시 어떤 내용을 읽었는지 정확히 보여 줄 수 있습니다.

새 버전마다 짧은 변경 사항을 추가하세요. 예를 들면 다음과 같습니다. «버전 2.0에서는 재택근무 승인 절차가 변경되었습니다. 직원은 거주 주 외 지역에서 근무하기 전에 승인을 요청해야 합니다.» 이 내용은 직원이 새 확인 요청을 받은 이유를 이해하는 데 도움이 되고, 관리자가 누가 이를 완료해야 하는지 판단하는 데도 유용합니다.

각 확인 기록은 정책 제목만이 아니라 하나의 정책 버전을 가리켜야 합니다. 정책이 여러 차례 변경되어도 이력이 분명하게 유지됩니다.

간단한 승인 및 게시 흐름 사용하기

정책 소유자는 제목, 이해하기 쉬운 내용, 버전 번호, 예정 시행일을 포함한 초안을 만듭니다. 검토 중에는 초안을 수정할 수 있습니다.

그다음 초안을 승인해야 하는 사람에게 보냅니다. HR, 부서 책임자, 법률 자문, 운영 관리자가 검토자가 될 수 있습니다. 절차는 단순하게 유지하세요. 각 검토자는 승인, 거부, 의견을 남긴 뒤 초안을 되돌려보낼 수 있어야 합니다. 반려되면 소유자가 초안을 수정해 다시 제출합니다.

확정된 버전 게시하기

승인이 끝나면 정책을 지정된 직원 그룹에 게시합니다. 시행일은 신중하게 정하세요. 직원이 새 출장 정책을 읽을 시간을 확보한 뒤 예정된 출장에 적용해야 할 수도 있고, 긴급한 보안 업데이트는 당일 바로 시행해야 할 수도 있습니다.

게시가 완료되면 공개된 사본을 잠그세요. 직원은 읽을 수 있지만 누구도 본문, 할당 그룹, 버전 번호를 수정해서는 안 됩니다. 문구가 바뀌면 새 초안을 만들고 새 버전을 게시하세요. 그러면 모든 직원의 확인 기록이 해당 직원이 실제로 본 정확한 내용을 가리키게 됩니다.

게시된 기록에는 정책 제목과 버전, 정책 소유자, 승인자, 게시일과 시행일, 할당된 직원 그룹, 확정된 정책 본문 또는 첨부 문서가 포함되어야 합니다.

정책을 삭제하지 않고 폐기하기

새 버전이 이전 버전을 대체하면 이전 정책을 폐기 상태로 표시하세요. 현재 할당 화면에서는 제거하되 문서, 승인 내역, 시행일, 완료된 확인 기록은 보존해야 합니다.

HR이 재택근무 정책 2.0을 버전 2.1로 바꾼다면, 2.1이 할당된 직원은 새 내용을 확인해야 합니다. 동시에 팀은 버전 2.0을 열어 누가 언제 수락했는지 확인할 수 있어야 합니다. 이전 기록을 삭제하면 나중에 컴플라이언스를 확인하기가 불필요하게 어려워집니다.

직원이 쉽게 확인하도록 만들기

직원에게는 일반적인 정책 제목이 아니라 자신이 확인해야 하는 정확한 문서가 보여야 합니다. 화면 상단에 정책 이름, 버전 번호, 시행일, 응답 기한을 배치하세요.

행동은 간단하게 유지하세요. 문서를 읽은 뒤 직원은 «이 정책을 읽고 이해했음을 확인합니다»와 같은 문장을 선택할 수 있습니다. 확인의 목적이 아닌데도 직원이 모든 세부 내용에 동의한다고 표현하는 문구는 사용하지 마세요.

앱은 회사가 이미 보유한 정보를 활용해야 합니다. 직원 계정에서 이름을 가져오고 날짜, 시간, 정책 버전, 상태를 저장할 수 있습니다. «확인 완료», «대기 중», «기한 초과»처럼 이해하기 쉬운 상태는 관리자에게 유용한 정책 확인 현황을 보여 줍니다.

제출 전 확인 화면을 두면 실수를 줄일 수 있습니다. 다음과 같은 정보를 표시할 수 있습니다.

• 재택근무 정책, 버전 3.0
• 시행일: 2025년 6월 1일
• 응답 기한: 2025년 6월 15일
• 상태: 오전 10시 42분 확인 완료

설명이 필요할 때는 의견이나 질문을 남길 수 있는 선택 항목을 추가하세요. 직원이 «다음 달 고객 방문에도 출장 규정이 적용되나요?»라고 물을 수 있습니다. 질문은 정책 소유자에게 보내되, 회사가 먼저 답변을 받아야 한다고 정한 경우가 아니라면 확인 제출을 막지는 마세요.

민감한 정책에는 확인 버튼을 활성화하기 전에 직원이 문서를 열도록 하는 방식을 사용할 수 있습니다. 제출할 때 확인 문구를 다시 표시하면 됩니다. 이렇게 하면 짧은 작업을 불편한 양식으로 만들지 않으면서도 합리적인 열람 기록을 남길 수 있습니다.

AppMaster에서는 정책 기록, 직원 계정 데이터, 확인 양식, 각 응답을 올바른 정책 버전에 연결해 저장하는 비즈니스 규칙으로 이 흐름을 만들 수 있습니다.

올바른 직원에게 정책 보내기

직원은 자신의 업무에 적용되는 정책만 받아야 합니다. 모든 문서를 모든 사람에게 보내면 불필요한 알림이 늘고 응답률이 떨어지며 기록을 검토하기도 어려워집니다.

할당에는 직원 디렉터리를 사용하세요. 각 직원 기록에는 부서, 근무지, 직무, 관리자, 입사일, 재직 상태와 같은 실용적인 정보가 포함되어야 합니다. 그러면 HR이나 운영 담당자가 매번 새 목록을 만들지 않고 대상자를 선택할 수 있습니다.

개정된 창고 안전 정책은 창고 직원과 감독자에게 보낼 수 있습니다. 영업 커미션 정책은 영업팀에만 보낼 수 있습니다. 각 요청에는 정책 이름, 버전 번호, 기한, 직원이 해야 할 행동을 명시해야 합니다.

그룹을 사용하고 예외도 허용하기

사람들이 이미 익숙하게 이해하는 그룹을 기준으로 할당 규칙을 만드세요. 초기 워크플로에서는 부서와 근무지만으로도 충분한 경우가 많습니다. 관리자, 운전자, 고객 데이터를 다루는 직원처럼 특정 업무에만 적용되는 정책에는 직무를 추가하세요.

직원을 이름으로 지정하는 할당도 허용하세요. 임시 업무를 맡았거나 여러 팀에서 일하는 사람, 문제 발생 후 정책을 다시 검토해야 하는 사람에게 유용합니다. 관리자는 게시 전에 대상자를 추가하거나 제거할 수 있어야 하며, 앱은 그 결정을 기록해야 합니다.

할당 설정에는 부서, 근무지, 직무, 지정 직원 필터, 수신자 미리 보기, 휴직자나 더 이상 재직하지 않는 직원을 제외하는 옵션, 각 정책 버전의 최종 대상자 기록이 포함되어야 합니다.

전달과 확인을 따로 추적하기

직원 정책 확인 기록에는 서명 완료 상태만으로 부족합니다. 앱이 요청을 생성한 시점, 직원에게 알림을 보낸 시점, 직원이 정책을 열거나 확인하거나 거부한 시점을 기록하세요. 이메일 전달에 실패하면 그 사실을 남기고 관리자가 요청을 다시 보낼 수 있게 하세요.

신규 입사자는 별도로 처리해야 합니다. 입사일부터 필수 정책을 할당하거나 온보딩 그룹을 통해 할당하세요. 직원이 고객 지원팀에서 재무팀으로 이동하면 디렉터리 변경을 계기로 새 직무에 필요한 정책을 검토할 수 있습니다. 앱은 재무 정책을 할당하면서 이전 확인 기록은 보존할 수 있습니다.

AppMaster에서는 디렉터리, 정책, 할당 기록을 서로 연결된 데이터 모델로 구성할 수 있습니다. 시각적 비즈니스 프로세스를 사용하면 HR이 버전을 게시하거나 직원의 팀을 변경할 때 할당을 자동으로 생성할 수 있습니다.

모든 사람에게 스팸을 보내지 않고 미응답자에게 알림 보내기

알림은 기록을 완성하는 데 도움이 되지만 너무 많은 메시지는 무시되기 쉽습니다. 정책을 게시할 때 첫 알림 날짜를 설정하세요. 일반적으로 기한 며칠 전에 한 번, 직원이 아직 응답하지 않았다면 기한 당일 한 번 보내는 일정이 적절합니다.

알림을 보내기 전에 각 사람의 상태를 확인하세요. 현재 버전을 수락한 직원에게는 후속 알림을 보내지 않아야 하며, 확인을 제출하는 즉시 예약된 알림도 모두 중단되어야 합니다.

정책 이름, 버전, 기한을 포함한 직접적인 메시지를 사용하세요. 아직 해야 할 일이 남은 사람이 소수라면 전체 공지를 보내지 마세요. 월요일에 재택근무 정책을 완료한 직원이 아직 시작하지도 않은 동료와 같은 금요일 알림을 받아서는 안 됩니다.

적절한 단계별 에스컬레이션 설정하기

기한이 지나면 미완료 항목을 직원에게 다시 보내고 후속 조치를 담당하는 사람에게 알립니다. 많은 회사에서는 직원의 관리자나 HR 담당자가 이 역할을 맡습니다. 이들에게 정책, 기한, 현재 상태를 간단히 보여 주세요.

다음과 같은 짧은 일정이 효과적일 수 있습니다.

• 기한 5일에서 7일 전에 첫 알림을 보냅니다.
• 기한 당일 최종 알림을 한 번 보냅니다.
• 기한이 지나면 관리자 또는 HR 담당자에게 알립니다.
• 계속 기한이 지난 상태일 때만 추가 후속 알림을 보냅니다.

모든 정책에 같은 일정을 적용하지 마세요. 필수 안전 규정은 간단한 핸드북 업데이트보다 빠른 에스컬레이션이 필요할 수 있습니다. 알림 시점과 에스컬레이션 담당자는 정책 기록마다 설정하세요.

AppMaster에서는 시각적 비즈니스 프로세스로 확인 상태에 따라 수신자를 필터링하고, 메시지를 예약하며, 직원이 응답하면 작업 상태를 업데이트할 수 있습니다.

감사 이력을 읽기 쉽게 유지하기

감사 화면은 수십 개의 직원 기록을 열지 않아도 네 가지 질문에 답할 수 있어야 합니다. 누가 정책을 받았는가, 누가 확인했는가, 누가 아직 조치해야 하는가, 누가 기한을 놓쳤는가입니다. 각 정책 버전 상단에 할당, 확인 완료, 대기 중, 기한 초과 인원을 표시하세요.

집계는 최초 할당 목록을 기준으로 하세요. 80명이 버전 3.0을 받았다면 그중 5명이 나중에 다른 팀으로 이동했더라도 할당 인원은 80명으로 표시해야 합니다. 그래야 게시 당시의 정확한 기록이 보존됩니다.

기록을 쉽게 찾을 수 있게 만들기

필터를 사용하면 이력이 복잡한 표로 변하는 것을 막을 수 있습니다. 관리자가 직원 정책 확인 기록을 정책 이름과 버전, 팀 또는 부서, 확인 상태, 할당일 또는 확인일, 개별 직원별로 필터링할 수 있게 하세요.

각 직원 기록에는 명확한 타임라인이 있어야 합니다. 앱이 정책을 할당한 시점, 추적하는 경우 직원이 문서를 연 시점, 직원이 확인한 시점, 수락한 정확한 버전을 보여 주세요. 할당 당시 직원의 직무나 팀, 확인한 문구도 저장하세요.

개정판을 게시할 때 이전 확인 기록을 덮어쓰지 마세요. 버전 2.0은 새로운 할당과 기한을 만듭니다. 버전 1.0은 원래 본문, 수신자, 확인 기록과 함께 이력에 남아 있어야 합니다. 직원이 두 버전을 모두 수락하는 것은 정상입니다.

맥락을 포함해 기록 내보내기

내부 검토를 위해 이름만 나열한 목록 대신 날짜가 포함된 보고서를 내보내세요. 정책 제목, 버전, 게시일, 기한, 직원 정보, 상태, 확인 시간, 보고서 생성일을 포함해야 합니다.

AppMaster로 만든 앱에서는 정책 기록, 할당, 알림, 확인 내역을 연결된 데이터 테이블에 저장할 수 있습니다. 관리자는 직원 한 명의 이력을 검토하거나 스프레드시트를 손으로 합치지 않고도 특정 정책 버전의 전체 기록을 내보낼 수 있습니다.

예시: 재택근무 정책 업데이트하기

HR이 재택근무 장비의 비용 정산 규정을 변경한다고 가정해 보겠습니다. 기존 재택근무 정책에는 이미 146건의 확인 기록이 있으므로 내용을 직접 수정하면 이력이 모호해집니다. 자체 시행일, 승인 상태, 게시일을 가진 버전 2를 새로 만드세요.

변경 내용을 이해하기 쉬운 말로 설명하세요. 예를 들어 일정 금액을 초과하는 장비를 구매하기 전에 관리자의 승인을 받아야 하고, 30일 이내에 영수증을 제출해야 한다는 내용일 수 있습니다. 전체 정책은 그대로 제공하되, 직원이 긴 문서 두 개를 직접 비교하지 않도록 짧은 요약을 추가하세요.

새 규정의 영향을 받는 사람에게만 버전 2를 할당하세요. 완전 재택 및 하이브리드 근무자, 이들의 관리자, 비용 청구를 검토하는 재무팀 직원이 대상이 될 수 있습니다. 전일제 사무실 근무자에게는 불필요한 작업을 부여하지 않아도 됩니다.

버전 1은 원래 수신자와 확인 기록을 그대로 유지합니다. 버전 2는 새로운 확인 주기를 시작합니다. 버전 1을 수락한 직원도 비용 조건이 변경되었으므로 버전 2를 다시 확인해야 합니다.

새 규정이 시행되기 7일 전처럼 기한을 설정하세요. HR이 정책을 게시할 때 최초 알림을 보내고, 이후에는 확인을 완료하지 않은 직원에게만 알림을 보내세요. 관리자는 자신의 팀만 볼 수 있어야 하며, HR은 버전 2를 필터링해 누가 확인했는지, 정책을 열지 않았는지, 기한을 놓쳤는지 검토할 수 있어야 합니다.

기록을 약하게 만드는 실수

게시된 정책 뒤에 있는 파일을 교체하지 마세요. 비용 한도나 담당자처럼 작은 변경이라도 새 버전을 만드세요. 버전 1.2를 수락한 사람이 자동으로 버전 1.3까지 수락한 것은 아닙니다.

이메일을 열었다는 사실은 전달 정보로는 유용하지만 확인 기록은 아닙니다. 사람들은 실수로 메시지를 열거나 정책을 읽지 않고 미리 보기만 할 수 있습니다. «확인합니다»와 같은 명확한 행동을 요청하고 응답 시간과 정책 버전을 함께 저장하세요.

모든 알림을 보내기 전에 현재 상태를 확인하세요. 직원이 확인을 완료하면 알림 대상 그룹에서 즉시 제거해야 합니다. 불필요한 메시지는 직원을 불편하게 만들고 프로세스가 제대로 관리되지 않는다는 인상을 줍니다.

접근 권한도 중요합니다. 소수의 정책 팀에만 정책 내용을 만들고 편집할 권한을 주세요. 관리자는 자신의 팀에 대한 완료 현황이 필요할 수 있지만, 게시된 문서나 직원의 응답을 수정할 수 있어서는 안 됩니다.

퇴사한 직원도 과거 보고서에는 포함되어야 합니다. 퇴사했다고 확인 기록을 삭제하지 마세요. 재직 상태를 종료로 표시하고, 필요하면 개인정보 접근을 제한하며, 해당 직원이 회사에서 근무했던 기간의 확인 기록은 보존하세요.

작은 워크플로부터 시작하기

이미 직원이 확인해야 하는 정책 하나로 시작하세요. 업데이트된 재택근무 규정이나 허용 가능한 사용 정책이 좋은 예입니다. 처음에는 직원 20명으로 구성된 한 부서처럼 소규모 그룹을 초대해 보세요. 제한적으로 출시하면 앱이 회사 전체의 공식 기록이 되기 전에 부족한 부분을 찾을 수 있습니다.

팀이 보존해야 하는 정보를 기록하세요. 정책 제목, 버전, 게시일, 시행일, 직원 할당, 기한, 응답일, 확인 상태가 여기에 포함됩니다. 초안, 승인됨, 발송됨, 확인 완료, 기한 초과, 보관됨처럼 이해하기 쉬운 상태를 사용하세요.

프로세스의 양쪽을 모두 테스트하세요. 할당된 직원은 게시된 버전을 읽고 확인을 제출할 수 있어야 합니다. 앱은 할당일, 응답일, 정책 버전을 함께 기록해야 합니다. 알림은 아직 응답하지 않은 테스트 직원에게만 전달되어야 하며, 버전 2를 게시해도 버전 1의 모든 응답이 보존되어야 합니다.

AppMaster를 사용하면 정책, 버전, 직원, 할당, 확인 기록을 분리한 노코드 내부 앱을 만들 수 있습니다. 정책을 할당하고 응답을 기록하며 아직 회신하지 않은 직원에게만 알림을 보내는 비즈니스 프로세스를 구성하세요. 그런 다음 각 그룹이 수행하는 업무에 맞춰 간단한 직원용 및 관리자용 화면을 만드세요.

첫 번째 정책 주기가 끝나면 관리자에게 실제로 사용한 보고서와 상태 화면이 무엇인지 물어보세요. 부서별 기한 초과 인원, 감사용 내보내기, 휴직에서 복귀한 직원에게 알림을 다시 보내는 기능이 필요할 수 있습니다. 실제 사용으로 필요성이 확인될 때 해당 기능을 추가하세요.

작은 첫 워크플로는 앱의 구조를 명확하게 만들어 줍니다. 게시된 버전 하나, 정해진 대상자, 기록된 확인 내역, 읽기 쉬운 이력입니다. 이 기록이 안정적으로 작동한 뒤 범위를 넓히세요.