역할과 권한: 비즈니스 사례로 보는 명확한 규칙

진짜 문제: 보이면 안 되는 데이터를 누군가 보는 상황

업무상 ‘데이터 유출’은 지루하게 보이는 경우가 많습니다. 지원 담당자가 고객 프로필을 열었는데 전체 결제 내역을 본다거나, 고객이 로그인했을 때 “불만이면 20% 제안” 같은 내부 메모나 인보이스의 실제 원가와 마진을 발견하는 식입니다. 비밀번호가 도난당한 게 아닙니다. 단지 앱이 잘못된 것을 보여준 것뿐입니다.

대부분의 유출은 실수로 발생합니다. 권한이 뒤늦게 추가되거나, 새 화면이 급히 배포되거나, 테스트용으로 '충분히 좋았던' 옛 역할을 복사하면서 문제가 생깁니다. 그러다 테이블에 필드를 하나 추가하는 작은 변경이 조용히 모두에게 보여지게 됩니다.

그래서 역할과 권한은 앱의 마지막 확인 항목이 아니라 핵심 설계 요소여야 합니다. 대부분의 소규모 기업은 결과적으로 같은 네 가지 역할 유형으로 정리됩니다: 소유자, 관리자, 직원, 고객.

목표는 간단합니다: 각 사람은 자신의 업무를 수행하는 데 필요한 것만 보고, 그 외에는 일절 보지 못하게 하는 것. 이 범위는 화면뿐 아니라 백그라운드의 데이터까지 포함합니다.

노코드 플랫폼 같은 곳에서 빠르게 개발하는 경우에는 이 점이 더 중요합니다. 속도가 빠르면 개인 메모, 가격 규칙, 다른 고객의 기록을 실수로 노출하기 쉬우므로 초기 설계 단계에서 접근을 고민하세요. 특히 AppMaster 같은 플랫폼을 쓰면 더더욱 그렇습니다.

역할, 권한, 범위: 간단한 정의

역할과 권한은 앱 내에서 누가 무엇을 할 수 있는지를 결정하는 규칙입니다.

• 역할(role) 은 소유자(Owner), 관리자(Manager), 직원(Staff), 고객(Client) 같은 직무 라벨입니다.
• 권한(permissions) 은 해당 역할이 허용된 특정 작업들입니다.

접근 수준(access level) 은 그 규칙들이 실제로 만들어내는 결과입니다. 같은 '직원' 역할이라도 환불을 승인할 수 있는 사람과 없는 사람이 있을 수 있습니다.

실수를 막는 신뢰할 만한 방법은 최소 권한에서 시작해 그 사람이 일상 업무를 하는 데 꼭 필요한 권한만 추가하는 것입니다. 누군가가 인보이스를 전혀 수정하지 않는다면 “혹시 몰라”라는 이유로 편집 권한을 주지 마세요. 권한을 나중에 추가하는 것이 데이터 유출을 되돌리는 것보다 쉽습니다.

대부분 권한은 조회(view), 생성(create), 수정(edit), 삭제(delete) 그리고 내보내기(export)나 승인(approve) 같은 고위험 작업 몇 가지로 귀결됩니다.

범위(scope) 는 다른 질문에 답합니다: “어떤 레코드에 대해 그 작업을 할 수 있는가?” 어떤 사람은 인보이스를 조회할 수 있지만 자신의 것만 볼 수 있고 전체를 보지는 못할 수 있습니다.

일반적인 범위 패턴은:

• 자신의 레코드(본인이 생성했거나 할당된 항목)
• 팀 혹은 로케이션(지점, 부서, 프로젝트)
• 전체 회사(비즈니스 전반의 모든 레코드)

예를 들어 영업 담당자는 자신의 견적을 생성하고 조회할 수 있지만 전체 고객 목록을 내보내지는 못합니다. 영업 관리자는 팀 전체의 견적을 보고 할인을 승인할 수 있습니다. 소유자는 모든 것을 보고 회계용 보고서를 내보낼 수 있습니다.

소유자, 관리자, 직원, 고객이 일반적으로 필요로 하는 것

대부분의 앱은 같은 네 그룹으로 나뉩니다. 세부는 달라질 수 있지만 패턴은 동일합니다. 명확한 역할과 권한으로 시작하면 나중에 “왜 저 사람이 저걸 보지?” 같은 당황스러운 상황을 피할 수 있습니다.

소유자는 보통 사업 전반에 대한 전체 가시성이 필요합니다. 여기에는 청구, 보안 설정(비밀번호 규칙, MFA 등), 누가 언제 무엇을 변경했는지 확인할 수 있는 감사 기록(audit history)이 포함됩니다.

관리자는 전체 관리자 권한 없이 팀을 운영할 수 있어야 합니다. 보통 부서 내 모든 것을 볼 수 있고(감시), 할인·환불·휴가·콘텐츠 변경 같은 작업을 승인할 수 있으며 보고서를 읽을 수 있습니다. 직원 초대나 비밀번호 재설정 같은 제한적 관리자 작업이 필요할 수는 있으나 청구나 전사적 보안 제어에는 접근하지 않아야 합니다.

직원은 일상 작업을 빠르게 처리할 수 있어야 하며 위험은 최소화돼야 합니다. 안전한 기본값은 “내게 할당된 것만” 입니다. 지원 담당자는 자신에게 할당된 티켓만 보고, 디스패처는 오늘의 경로만 보며, 영업 담당자는 자신에게 할당된 리드만 봅니다. 내보내기와 대량 다운로드는 기본적으로 꺼져 있어야 하며 실제 필요가 있을 때만 켜야 합니다.

고객은 여러 사람이 하나의 계정을 공유하더라도 본인 소유의 데이터만 봐야 합니다. 제한된 작업(요청 생성, 인보이스 결제, 프로필 업데이트)은 허용하되 내부 메모, 직원 코멘트, 내부 상태는 숨깁니다.

많은 비즈니스에서 잘 작동하는 기본값:

• 소유자: 청구, 보안, 감사 로그를 포함한 모든 권한
• 관리자: 팀 데이터, 승인, 보고, 제한된 사용자 관리
• 직원: 할당된 레코드만, 대량 내보내기 불가, 관리자 설정 불가
• 고객: 자신 소유 레코드만, 내부 메모 불가, 제한된 작업만

화면이 아닌 데이터 유형별로 접근을 나누기

많은 팀이 화면 단위로 권한을 정합니다: “직원은 주문 페이지를 열 수 있고, 고객은 못한다.” 이것도 도움이 되지만 진짜 위험은 놓치기 쉽습니다. 동일한 데이터는 검색, 댓글, 알림, 내보내기, 첨부파일 등 여러 곳에 나타납니다.

먼저 메뉴가 아니라 데이터 영역을 나열하세요. 영향이 큰 영역은 보통 고객 연락처, 주문 및 배송 상태, 인보이스 및 결제 상태, 급여와 인사 메모, 내부 메모나 분석입니다.

그다음 각 역할이 각 데이터 유형에 대해 무엇을 할 수 있는지 결정하세요: 조회, 생성, 수정, 삭제, 승인, 공유 등. 여기서 필드 수준 규칙이 중요합니다. 동일한 객체가 공개 뷰와 내부 뷰를 모두 필요로 하는 경우가 많습니다.

예시: 주문(Order)은 고객 이름, 배송지, 가격, 내부 마진, 그리고 “이 고객은 불만이 많으니 할인 제공” 같은 내부 메모를 포함할 수 있습니다. 고객은 주소와 상태는 보지만 마진이나 내부 메모는 절대 보지 못해야 합니다. 관리자는 모든 필드를 보며 할인 승인 권한까지 가질 수 있습니다. 직원은 배달·생산에 필요한 필드만 보고 재무 정보는 보지 못해야 합니다.

첨부파일과 파일은 추가 주의가 필요합니다. 계약서, 신분증, 영수증, 스크린샷은 폼 필드보다 더 민감할 수 있습니다. 누가 업로드, 다운로드, 미리보기를 할 수 있는지 별도 권한으로 설정하세요. 또한 첨부파일이 부모 레코드(예: 인보이스)의 접근 권한을 상속할지 별도 규칙을 가질지 결정하세요.

마지막으로 내보내기와 대량 작업은 단순히 리스트를 볼 수 있다고 포함되는 기능이 아니어야 합니다. CSV/PDF로 내보내기, 첨부파일 대량 다운로드, 상태 대량 변경(승인, 취소, 환불), 대량 메시지(이메일/SMS/텔레그램), 레코드 재할당 같은 관리자 작업은 명시적으로 권한을 부여하세요.

비즈니스 예시 1: 영업 및 청구 앱

작은 서비스 비즈니스를 상상해 보세요: 소유자는 프로젝트를 판매하고, 관리자는 작업을 감독하며, 직원은 일을 수행하고, 고객은 견적을 승인하고 인보이스를 결제합니다. 실수를 피하는 가장 빠른 방법은 누구도 로그인하기 전에 역할과 권한에 동의하는 것입니다.

먼저 금전 관련 정보를 정하세요. 가격 정보는 마진보다 더 많은 사람에게 보일 수 있습니다. 흔한 규칙은: 직원은 청구할 금액은 볼 수 있지만 그 가격이 왜 정해졌는지는 보지 못하게 하는 것 입니다. 기술자는 인보이스 항목을 설명하기 위해 라인 아이템을 볼 수 있지만 내부 마진, 공급가, 특별 할인 내역은 보지 못합니다.

고객 데이터도 위험 지점입니다. 여러 사람이 연락처를 보아야 하지만 편집은 소수만 할 수 있게 하지 않으면 청구 이메일이 개인 이메일로 덮어씌워져 회계로 인보이스가 전달되지 않는 같은 사고가 발생합니다.

많은 팀에 잘 맞는 간단한 설정:

• 소유자: 마진과 할인 이력 포함 모든 것을 보고 결제 상태 변경 가능
• 관리자: 견적·인보이스 생성, 할인 승인, 고객 연락처 편집 가능
• 직원: 할당된 고객 정보와 인보이스 라인 항목 조회 가능, 가격 규칙이나 마진은 볼 수 없음
• 고객: 자신의 견적과 인보이스만 보고 결제하거나 변경을 요청할 수 있음

고위험 작업은 잠그세요. 인보이스를 '결제됨'으로 표시하거나 환불을 발행하거나 결제 수단을 변경하는 작업은 소유자(또는 신뢰받는 재무 역할)로 제한하는 것이 좋습니다.

비즈니스 예시 2: 내부 메모가 있는 지원 데스크

지원 데스크는 단순해 보입니다: 고객이 메시지를 보내고 팀이 답변하며 티켓을 닫습니다. 문제가 되는 건 같은 티켓 뷰를 모두에게 재사용할 때입니다. 잘못된 설정 하나로 고객이 내부 메모, 태그, 심지어 직원 성과 지표를 보게 될 수 있습니다.

소규모 이커머스의 공유 지원 인박스를 떠올려 보세요. 티켓에는 고객 메시지, 주문 정보, 배송 상태, 그리고 “사기 가능성 있음, 신분증 확인” 또는 “VIP, 우선 처리” 같은 내부 메모가 포함될 수 있습니다. 내부 맥락은 팀에 도움이 되지만 고객에게는 절대 보여주면 안 됩니다.

민감한 정보를 안전하게 분리하는 깔끔한 방식:

• 고객: 자신의 메시지, 공개 상태 업데이트, 최종 해결 결과만 봄. 내부 태그나 직원 전용 메모는 없음.
• 직원 에이전트: 고객 메시지와 문제 해결에 필요한 고객 데이터(예: 주문 이력)만 봄. 내부 메모와 태그 추가 가능.
• 관리자: 직원이 보는 모든 것 + 재할당 제어와 SLA 우회 권한.
• 소유자/관리자(최고권한): 사업 전체의 모든 티켓과 고수준 보고서 조회 가능.

고객 개인정보(PII)는 또 다른 함정입니다. 지원은 종종 전화번호나 주소가 필요하지만 모든 티켓에 항상 보여줄 필요는 없습니다. 좋은 규칙은: 워크플로가 필요할 때만 민감 필드를 보여주는 것입니다. 예를 들어 에이전트가 ‘배송 문제’를 선택하면 주소를 보여주고, 티켓이 닫히면 다시 숨기는 방식입니다.

내부 지표는 고객 경험과 분리하세요. ‘첫 응답 시간’, ‘에이전트 점수’, ‘법무로 에스컬레이션됨’ 같은 항목은 직원 및 관리자 뷰에만 있어야 합니다.

비즈니스 예시 3: 운영 및 배송 추적

창고와 현장 팀이 하루 종일 배송을 운영한다고 상상해 보세요. 누군가는 경로를 계획하고, 누군가는 피킹(picking)을 하고, 운전자가 정차를 완료합니다. 앱이 잘못된 정보를 잘못된 사람에게 보여주면 당황스러운 수준을 넘어 고객 주소, 가격, 내부 메모가 노출될 수 있습니다.

각 그룹이 매일 필요로 하는 정보를 분리하는 것부터 시작하세요.

직원(피커와 운전사) 은 보통 매우 집중된 작업 뷰가 필요합니다. 운전사는 앱을 열면 자신에게 할당된 오늘의 작업만 보게 하고, 정차 순서, 정차 연락처, 배송 지침만 보게 하세요. 전체 고객 목록을 훑어보거나 다른 운전사의 작업을 볼 수 없어야 합니다. 교대 근무를 대신하는 상황이면 관리자가 작업을 재할당하도록 하고 광범위한 접근 권한을 주지 마세요.

관리자는 더 넓은 운영 상황을 볼 수 있어야 합니다. 모든 팀의 스케줄, 재고 수량, 현재 문제(지연 배송, 실패한 낙하, 손상된 품목, 서명 누락)를 확인하고 문제를 해결할 도구(정차 재할당, 경로 분할, 재고 조정 승인)를 가져야 합니다.

고객은 가장 작은 뷰만 필요합니다: 자신의 배송 상태만 봅니다. ETA 추적, 배송 증빙, '배송 중' 또는 '지연됨' 같은 업데이트를 받을 수 있지만 다른 고객이나 하루 전체 경로 지도, 내부 예외 메모는 절대 볼 수 없어야 합니다.

여기서 역할과 권한을 강제하는 간단한 방법은 할당과 고객 계정별로 데이터를 범위 처리하는 것입니다. 예를 들어 Delivery Job 레코드는 (1) 할당된 직원, (2) 관리자, (3) 해당 주문에 연결된 고객만 읽을 수 있게 설정하세요.

단계별: 역할과 권한을 설계하는 방법

먼저 사용자 그룹의 이름을 평이한 언어로 정하세요. “소유자, 관리자, 직원, 고객”은 좋은 출발점이지만 실제 비즈니스 흐름과 맞아야 합니다. 각 그룹에 대해 한 문장으로 성공 기준을 적어보세요. 예: “관리자는 급여는 보지 않으면서 업무 배정과 팀 성과를 확인할 수 있다.”

다음으로 액션을 데이터 영역에 매핑하세요. 처음부터 화면을 생각하지 마세요. 어떤 데이터가 있고 사람들이 그 데이터로 무엇을 할 수 있는지를 먼저 적으세요. 종이 한 장짜리 그리드로 충분합니다:

• 역할과 데이터 영역(고객, 주문, 인보이스, 티켓, 보고서)을 나열하세요.
• 각 역할별로 필요한 작업(조회, 생성, 수정, 승인, 내보내기)을 적으세요.
• 각 작업의 범위(자신, 팀, 전체)를 결정하세요.
• ‘팀’을 명확히 정의하세요(지점, 지역, 프로젝트, 직속 부하 등).
• 절대 금지 항목(예: 고객은 내부 메모 절대 불가)을 표시하세요.

그다음 실제 작업으로 초안 테스트를 진행하세요. ‘주문 생성’, ‘티켓 해결’, ‘보고서 다운로드’ 같은 일반 플로우를 따라가 보세요. 어떤 작업을 하려다 광범위한 접근을 줘야 한다면 보통 누락된 권한(예: ‘총액 보기’는 허용하되 ‘내보내기’는 금지) 이 있는 것입니다.

금전이나 민감 변경이 생길 때는 승인 단계를 추가하세요. 직원은 인보이스 초안을 작성할 수 있지만 발송이나 최종 승인 권한은 관리자에게 두세요. 직원이 배송지 주소는 수정할 수 있지만 은행 정보 변경은 소유자 승인으로 제한하세요.

실수로 데이터 유출을 초래하는 흔한 실수들

대부분의 데이터 유출은 해킹이 아닙니다. 앱이 누군가에게 직무상 필요 이상의 권한을 조용히 부여할 때 발생합니다. 역할과 권한은 한 번 설정해 놓고 절대 재검토하지 않으면 실패합니다.

자주 반복되는 패턴:

• 설정 편의를 위해 ‘관리자(Admin)’를 기본 역할로 두는 것
• 제한 없이 광범위한 내보내기 허용(고객, 연락처, 정산, 인보이스 등)
• 교대 팀에서 하나의 로그인 계정을 공유해 누가 무엇을 봤는지 추적 불가
• 주요 화면은 보안했지만 모바일 뷰, PDF, 이메일 알림, 첨부파일, 자동완성 폼 같은 측면을 잊음
• 퇴사자 접근 해제 실패: 전 직원이 앱, 이메일, 저장된 세션에 계속 접근 가능

측면 루트(side doors)가 가장 교묘합니다. 계약 화면 접근을 막았더라도 PDF를 이메일로 전송하면 직원이 그 PDF를 가지게 됩니다. 또는 모바일 레이아웃이 데스크톱에서 숨긴 필드를 표시할 수 있습니다.

실무적 해결책은 내보내기와 다운로드를 별도 권한으로 취급하는 것입니다. 역할이 목록을 봐야 한다면 전체 내보내기 대신 필터된 뷰를 제공하세요.

실제 사용자 초대 전 빠른 점검 목록

실제 사용자를 초대하기 전에 누군가 잘못 클릭하거나 화면을 공유하거나 파일을 다운로드할 가능성을 가정하세요. 몇 가지 점검으로 나중에 고생하는 일을 막을 수 있습니다.

기본값부터 정하세요. 새 사용자가 생성되면 자동으로 가장 낮은 권한에 배치되고 금전, 내보내기, 관리자 설정에 접근하지 못하게 하세요. 더 많은 권한이 필요하면 의도적으로 수동 변경하게 하세요.

다음으로 고객 경험을 낯선 사람처럼 테스트하세요. 고객은 URL을 바꾸거나 검색, 필터를 조작해도 다른 고객의 레코드를 절대 찾을 수 없어야 합니다. 빠른 테스트로는 고객 A로 로그인해 고객 B를 이름, 인보이스 번호, 티켓 ID로 찾을 수 없는지 확인하는 것입니다.

대부분의 유출을 잡아내는 다섯 가지 빠른 체크:

• 민감 필드는 기본적으로 숨기기(급여, 원가/마진, 개인 ID, 내부 메모)
• 내보내기와 대량 작업 잠그기
• 실수 시 비용이 큰 작업에는 승인 추가(환불, 지급, 역할 변경 등)
• 범위가 모든 곳에서 강제되는지 확인(화면, 검색 결과, API 응답)
• 변경 이력을 감사할 수 있게 하기: 누가 언제 무엇을 변경했는지(역할 변경, 결제 조작 포함)

‘사고 테스트’를 해보세요. 동료에게 직원 계정으로 실제 업무를 완료하게 한 뒤 동일한 작업을 고객 계정으로 시도해 보세요. 고객이 내부 가격을 보거나 전체 고객 목록을 내려받거나 환불을 트리거할 수 있다면 권한이 너무 넓습니다.

현실적인 시나리오: 직원과 고객이 같은 앱을 쓰는 경우

자주 들어오는 요청은 이렇습니다: 고객은 상태를 확인할 수 있는 포털을 원하지만, 직원도 같은 시스템으로 업무를 운영합니다. 역할과 권한이 명확하지 않으면 포털이 내부 메모, 다른 고객의 주문, 직원 전용 가격을 노출할 수 있습니다.

맞춤 인쇄소를 예로 들어보죠. 하나의 주문이 견적→생산→배송→인보이스로 이어지고 모두 같은 앱에서 처리됩니다.

이 워크플로에서 각 역할이 봐야 할 것:

• 소유자: 이익, 직원 성과, 모든 고객 계정 등 모든 정보
• 관리자: 팀의 모든 주문, 내부 메모, 할인·환불 승인 권한
• 직원: 자신에게 할당된 주문, 다음으로 완료할 작업, 작업에 필요한 연락처
• 고객: 자신의 주문, 고수준 상태(승인, 제작중, 발송됨), 배송 증빙, 결제해야 할 인보이스

두 가지 엣지 케이스가 모델을 흔들기 쉽습니다.

첫째, 관리자가 일시적으로 다른 팀을 대신할 때입니다. 이때 관리자 권한을 소유자로 바꾸지 마세요. 대신 7일 같은 기간 제한 범위를 부여해 해당 팀 주문에 접근하게 하고 기간 종료 시 자동으로 권한을 회수하세요.

둘째, VIP 고객이 "더 많은 가시성"을 요청할 때입니다. 더 많은 데이터 자체를 주지 말고 더 많은 문맥을 제공하세요. 예를 들어 확장된 타임라인이나 전용 메시지 스레드를 보여주되 "연체 중"이나 "재인쇄 사유(우리 실수)" 같은 내부 메모는 직원 전용으로 유지하세요.

역할과 책임은 변합니다. 접근 권한은 한 번 설정해 끝내는 것이 아니라 정기적으로 검토해야 합니다. 누군가 역할이 바뀌면 필요 이상의 권한을 누적시키지 말고, 먼저 더 이상 필요 없는 권한을 제거한 뒤 새 업무에 필요한 최소 권한을 추가하세요.

다음 단계: 명확한 접근 정책을 정하고 적용하기

작게 시작하세요. 가장 중요한 워크플로 한 가지(예: "인보이스 생성 및 결제" 또는 "지원 티켓 기록 및 답변")를 골라 먼저 역할과 권한을 정의하고 확장해 나가세요.

규칙을 한 표에 정리하고 살아있는 문서로 취급하세요: 역할, 할 수 있는 것, 할 수 없는 것, 그리고 범위 제한(예: "자신의 레코드만", "자신의 지점만")을 적습니다. 누군가 "직원이 고객 전화번호를 볼 수 있나?"라고 묻는다면 표가 즉시 답을 줄 수 있어야 합니다.

실무적 롤아웃 절차:

• 첫 워크플로(소유자, 관리자, 직원, 고객)에 대한 표 초안 작성
• 각 규칙을 필드 포함 구체적 데이터와 작업(조회, 수정, 내보내기, 삭제)에 매핑
• 각 역할별 데모 계정을 만들어 실제 작업을 끝까지 테스트
• 작은 그룹으로 런칭하고 예기치 않은 일이 없으면 범위를 확장
• 분기별로 접근 권한을 검토하고 조직 변경(새 관리자, 새 팀, 새 벤더) 후 즉시 재검토

AppMaster (appmaster.io)에서 개발한다면 데이터 모델과 비즈니스 로직과 함께 역할을 계획하면 웹 앱, 모바일 앱, API 엔드포인트 전반에 동일한 규칙을 일관되게 적용하기 쉽습니다.

오늘 바로 첫 접근 표를 작성해 한 워크플로에 적용해 보세요. 그 한 걸음으로 대부분의 우발적 데이터 유출을 예방할 수 있습니다.