같은 고객사를 수도권팀과 영남팀이 함께 담당한다면, 함께 쓰는 고객 기본정보는 한곳에서 찾아볼 수 있어야 합니다. 그렇다고 내부 협상 기준이나 공개 범위가 정해진 상담 내용까지 모두에게 보여줘야 할까요? 반대로 민감 정보를 보호하려고 고객정보를 통째로 잠그면, 같은 회사인지 확인하기 위해 다른 팀에 연락하는 일이 생깁니다.
인원이 많은 조직에서 필요한 것은 ‘공유 또는 비공개’ 중 하나를 고르는 일이 아닙니다. 함께 써야 할 정보는 공유하고, 특정 사람만 알아야 하는 정보와 바뀌면 안 되는 값은 따로 보호하는 일입니다.
CRM(고객 관계 관리 시스템) 권한 관리는 누가 어느 범위의 데이터를 보고 수정할 수 있는지 정하는 일입니다. 조직별 접근 범위, 읽기·쓰기, 필드별 제한, 생성 이후 변경 가능 여부를 나누면 고객정보 공유와 민감 정보 보호를 함께 설계할 수 있습니다. 거래 전체를 일괄 비공개로 두는 대신, 업무에 필요한 데이터 범위와 그 안의 민감 정보에 대한 권한을 나눠 정하는 방식입니다.
CRM 권한은 네 가지 질문으로 나눠야 합니다
‘팀별 권한을 설정할 수 있나요?’만으로는 우리 조직의 요구를 충분히 설명하기 어렵습니다. 다음 네 가지를 나눠 적어보세요.
어느 데이터까지 접근하나요? 전사, 소속 본부, 소속 팀, 본인 담당 거래 중 필요한 범위를 정합니다.
그 데이터에서 무엇을 할 수 있나요? 읽기와 쓰기를 구분합니다. 전사 거래를 조회하는 것과 전사 거래를 수정하는 것은 다릅니다.
어떤 항목까지 허용하나요? 필드, 즉 개별 입력 항목의 권한을 정합니다. 거래 진행 상태와 내부 협상 기준을 같은 수준으로 공개할 필요는 없습니다.
언제 입력하거나 수정할 수 있나요? 최초 생성 때 값을 넣을 수 있는지, 저장한 뒤에도 바꿀 수 있는지 구분합니다.
예를 들어 ‘고객 기본정보는 전사 읽기, 거래는 담당 범위 읽기·쓰기, 내부 협상 기준은 지정 책임자만 열람·수정’이라고 쓰면 요구가 구체적입니다. 여기에 ‘최초 접수 채널은 생성할 때만 입력’이라는 시점 조건도 붙일 수 있습니다.
조직도는 접근 범위를 정하는 기준입니다. 그 범위 안에서 모든 작업과 모든 필드가 자동으로 허용된다는 뜻은 아닙니다. 여기서 ‘전사’는 데이터 범위를 가리키며, 삭제나 권한 설정 같은 관리자 작업까지 허용한다는 의미도 아닙니다.
고객정보 공유와 민감 정보 제한을 본부·팀별로 설계하는 사례
국내사업본부에 수도권팀과 영남팀이 있고, 해외사업본부에 해외영업팀이 있다면 권한을 어떻게 나눠야 할까요? 같은 고객사 A에 수도권 거래와 영남 거래가 각각 연결돼 있을 때, 함께 볼 고객정보와 필요한 사람에게만 허용할 민감 정보를 구분해야 합니다. 이때 거래에 접근할 수 있는 조직 범위와 거래 안의 민감 필드 권한은 별도로 정합니다.
먼저 역할별 접근 범위와 허용 작업을 정합니다. 아래처럼 거래 단위의 접근 범위를 정하더라도, 그 안의 민감 정보를 어디까지 공개할지는 별도 기준이 필요합니다. 공용 고객 기본정보는 회사명·대표 연락처 등 함께 쓰기로 정한 항목에 한정합니다. 고객정보에 포함돼 있다는 이유만으로 개인 연락처나 민감 정보까지 전사에 공개하는 것은 아닙니다.
영업 담당자: 공용 고객 기본정보는 읽고, 본인 담당 거래는 읽고 수정합니다. 담당하지 않은 거래는 같은 팀 소속이라는 이유만으로 공개하지 않으며, 다른 팀 거래에도 접근하지 않습니다.
팀장: 소속 팀 거래를 읽고 수정합니다. 다른 팀 거래에는 접근하지 않습니다.
국내사업본부장: 수도권팀과 영남팀 거래를 읽습니다. 이 사례에서는 수정 권한을 주지 않고, 해외본부 거래도 공개하지 않습니다.
전사 조회 역할: 각 본부의 일반 거래정보를 읽되 수정하지 않습니다. 별도로 제한된 민감 필드까지 공개하는 것은 아닙니다.
직급명만으로 접근 범위와 수정 권한을 일괄 부여하지 말고, 각 역할이 맡은 업무에 따라 따로 정하세요.
공용 고객정보의 공유 범위와 조직별 거래 접근·작업 권한을 정하고, 민감 필드의 허용 대상은 별도로 구분합니다.
이 정책에서 수도권 담당자는 고객사 A의 공용 기본정보를 확인한 뒤 자신이 맡은 거래의 진행 상태를 바꿀 수 있습니다. 하지만 고객사 A에 연결돼 있다는 이유만으로 영남팀의 거래 조건이나 상담 기록까지 열려서는 안 됩니다. 고객을 함께 관리하는 것과 연결된 모든 기록을 함께 보는 것은 다른 요구입니다.
본부장도 마찬가지입니다. 국내 거래를 넓게 조회할 필요가 있어도 직접 수정할 필요는 없을 수 있습니다. 직함 하나에 권한을 묶기보다, 업무에 필요한 범위와 행동을 각각 적어야 이런 차이를 반영할 수 있습니다.
민감 정보는 거래 접근 권한과 별도로 제한하세요
거래를 조회하거나 수정할 수 있는 담당자라도 그 안의 민감 정보를 모두 볼 수 있어야 하는 것은 아닙니다. 진행 상태는 갱신해야 하지만, 내부 협상 기준은 지정된 책임자만 열람·수정하도록 제한할 수 있습니다. 민감 정보의 열람 제한과 필드의 수정 제한은 각각 정해야 합니다.
앞선 사례에 ‘내부 협상 기준’이라는 민감 필드를 추가해보겠습니다. 일반 담당자는 거래 자체에 접근해 진행 상태를 수정할 수 있지만, 이 필드는 열람하거나 수정할 수 없도록 정책을 정합니다. 지정된 협상 책임자는 자신에게 허용된 거래 범위 안에서만 해당 필드를 열람·수정합니다. 필드 권한을 받았다고 거래 접근 범위까지 전사로 넓어지는 정책은 아닙니다.
거래를 볼 수 있어도 민감 정보까지 자동으로 공개하지 않습니다. 지정된 사람에게만 민감 필드의 열람·수정을 허용하며, 거래 접근 범위는 별도로 유지합니다.
항목별 요구도 구별해야 합니다.
읽기만 허용: 값은 확인할 수 있지만 해당 사용자는 수정할 수 없습니다.
열람·수정 모두 제한: 해당 사용자는 내용을 알아서는 안 되고, 변경해서도 안 됩니다.
일반 수정 허용: 업무 진행에 따라 값을 갱신할 수 있습니다.
화면에서 항목을 숨기는 설정만 보고 열람 제한까지 검증됐다고 판단하지는 마세요. 조직에서 실제로 쓰는 조회 경로에서도 그 값에 접근할 수 없는지 확인해야 합니다.
읽기 전용과 ‘생성 이후 변경 금지’는 다릅니다
‘이 필드는 수정 불가’라는 요구에는 서로 다른 상황이 들어 있습니다. 하나는 해당 사용자가 값을 읽기만 하는 경우이고, 다른 하나는 처음에는 입력하되 저장한 뒤에는 바꾸지 못하게 하는 경우입니다.
예를 들어 ‘최초 접수 채널’을 처음 문의가 들어온 경로로 보존하려 한다고 가정해보겠습니다. 이후 연락 경로가 달라져도 최초 값은 그대로 남겨야 합니다.
이때 필요한 동작은 다음 순서입니다.
생성 권한을 가진 담당자가 새 거래를 만듭니다.
‘최초 접수 채널’에 ‘파트너 소개’를 입력하고 저장합니다.
같은 담당자가 저장된 거래를 다시 열어 ‘직접 문의’로 바꾸려고 합니다.
최초 접수 채널의 업데이트는 차단돼야 합니다.
변경이 허용된 다른 일반 필드, 예를 들어 진행 상태는 계속 수정할 수 있어야 합니다.
생성 후 변경 금지는 최초 입력을 허용하면서 저장 후 해당 필드의 재수정을 막는 요구입니다. 변경이 허용된 일반 필드의 수정은 계속 가능해야 합니다.
생성할 때부터 입력이 막히면 ‘최초 입력 허용’ 요구를 충족하지 못합니다. 반대로 저장 후 같은 사용자가 값을 바꿀 수 있으면 ‘생성 이후 변경 금지’ 요구를 충족하지 못합니다. 거래 전체를 잠가 일반 업무 갱신까지 막는 것도 이 사례의 목적과 다릅니다.
여기서 변경 금지는 정책을 적용받는 사용자와 확인한 변경 경로를 기준으로 판단해야 합니다. 관리자나 외부 연동, 대량 변경을 포함해 어떤 경로로도 절대 바뀌지 않는다는 시스템 전체의 보장과는 구분해야 합니다.
처음 잘못 입력한 값의 정정이 필요하다면, 누가 판단하고 어떤 절차로 처리할지도 미리 합의하세요. 합의한 절차가 실제 설정·운영 방식으로 가능한지는 별도로 확인해야 합니다.
역할별로 허용과 차단을 함께 검증하세요
정책을 적었다면 역할별로 확인할 고객정보·거래·필드를 준비하세요. 검증에 필요한 항목만 사용하고 민감 정보는 제외하세요. 관리자 계정 하나로 화면을 둘러보기보다 역할별 계정으로 같은 데이터를 다르게 확인하는 편이 정책과 결과를 비교하기 좋습니다. 테스트 계정과 환경의 제공 조건은 공급사와 협의해야 합니다.
앞서 정한 정책을 기준으로 허용돼야 할 행동과 차단돼야 할 행동을 모두 확인합니다.
고객 기본정보 공유
계정·행동: 수도권 담당자가 공용 고객사 A의 기본정보를 조회합니다.
기대 결과: 조회가 허용됩니다.
담당 거래 갱신
계정·행동: 같은 담당자가 본인 거래의 진행 상태를 수정합니다.
기대 결과: 수정이 허용됩니다.
다른 팀 거래 제한
계정·행동: 같은 담당자가 고객사 A에 연결된 영남팀 거래를 조회합니다.
기대 결과: 같은 고객에 연결돼 있어도 거래 조회는 차단됩니다.
팀장 범위 확인
계정·행동: 수도권팀장이 소속 팀원의 거래를 조회하고 수정합니다.
기대 결과: 두 행동 모두 허용됩니다.
본부 조회와 수정 분리
계정·행동: 국내사업본부장이 영남팀 거래를 조회한 뒤 수정하려고 합니다.
기대 결과: 조회는 허용되지만 수정은 차단됩니다.
다른 본부 접근 제한
계정·행동: 국내사업본부장이 해외본부 거래를 조회합니다.
기대 결과: 조회가 차단됩니다.
전사 조회 역할 확인
계정·행동: 전사 조회 계정으로 각 본부의 일반 거래정보를 조회하고 수정하려고 합니다.
기대 결과: 조회는 허용되지만 수정은 차단됩니다.
민감 필드 차단
계정·행동: 일반 담당자가 접근 가능한 거래의 ‘내부 협상 기준’을 조회하고 수정하려고 합니다.
기대 결과: 이 필드의 열람·수정은 모두 차단됩니다.
민감 필드 허용
계정·행동: 지정 협상 책임자가 허용 범위 거래의 ‘내부 협상 기준’을 조회하고 수정합니다.
기대 결과: 두 행동 모두 허용됩니다.
최초 입력과 재수정 분리
계정·행동: 생성 권한을 가진 담당자가 ‘최초 접수 채널’을 입력해 저장하고, 저장 후 다른 값으로 바꾸려고 합니다. 일반 필드도 별도로 수정합니다.
기대 결과: 최초 입력은 허용되고 채널 재수정은 차단됩니다. 일반 필드 수정은 정상적으로 허용됩니다.
기록에는 ‘정상’이라는 한마디 대신 아래 항목을 남겨보세요.
테스트 계정과 소속
대상 데이터·필드와 시도한 행동
정책상 기대 결과
실제 결과: 직접 확인한 뒤 작성
증빙과 확인일
불일치 내용과 조치 담당자
실제 결과와 합격 여부를 미리 채우면 안 됩니다. 예를 들어 민감 필드가 화면에서 보이지 않는다는 것만 확인했다면, 수정 시도나 다른 조회 경로까지 검증했다고 기록하지 않습니다.
예외와 다른 접근 경로는 별도로 확인하세요
공동 담당 거래, 겸직, 조직 이동이 있다면 추가 정책이나 예외가 필요한지 확인해야 합니다. 누가 어느 범위에 접근해야 하는지, 여러 규칙이 겹치면 무엇을 우선할지부터 정해야 합니다. 검색·미리보기·내보내기도 실제로 이용한다면 확인 대상에 포함하세요.
외부 연동용 API(프로그램끼리 데이터를 주고받는 인터페이스), 대량 가져오기, 자동화로 값을 변경한다면 해당 경로에서도 생성 후 변경 금지의 적용 범위를 별도로 확인해야 합니다. 이는 조직별 추가 검증 항목이며, 여기서 모든 경로의 지원 방식이나 차단 결과를 보장하는 것은 아닙니다.
조직이 바뀐 뒤에는 기존 역할의 테스트도 다시 실행하는 것이 좋습니다. 조직 변화에 따른 운영 기준은 영업 조직 개편에 따른 CRM 재설계에서도 살펴볼 수 있습니다.
트래킷에서 검토할 권한 설계
트래킷은 조직도와 본부·팀에 따른 데이터 접근 범위, 읽기·쓰기 권한, 민감 필드의 열람·수정 제한, 생성 이후 업데이트를 막는 필드 통제를 지원합니다.
따라서 검토할 때도 ‘권한 기능이 있나요?’에서 끝내기보다 우리 조직의 업무 문장으로 요구를 전달하는 편이 좋습니다. ‘고객 기본정보는 공유하되 민감 정보는 필요한 사람에게만 허용한다’, ‘거래 접근 범위는 소속 본부·팀과 담당 업무에 맞춰 정한다’, ‘담당자는 진행 상태를 바꾸지만 내부 협상 기준은 볼 수 없다’, ‘최초 접수 채널은 생성 후 바꾸지 못한다’처럼 정리하는 방식입니다.
우리 조직에 적용할 역할 조합과 예외, 변경 경로를 정리하면 필요한 권한 설정을 구체적으로 검토할 수 있습니다.
자주 묻는 질문
고객정보를 공유하면서 민감 정보만 제한할 수 있나요?
함께 쓰는 고객 기본정보와 민감 정보의 열람·수정 권한을 나눠 설계할 수 있습니다. 고객정보를 공유한다고 내부 협상 기준까지 모두에게 공개할 필요는 없습니다. 본부·팀별 거래 접근 범위도 별도로 정하고, 거래를 볼 수 있는 사람에게 민감 필드까지 자동으로 허용하지 않는지 확인하세요.
본부장이라면 모든 필드를 수정할 수 있나요?
조직상 접근 범위와 읽기·쓰기, 필드별 권한은 별개입니다. 본부 거래를 읽을 수 있어도 수정은 제한할 수 있고, 민감 필드는 별도로 제한하는 정책을 세울 수 있습니다.
읽기 전용과 생성 후 변경 금지는 무엇이 다른가요?
읽기 전용은 해당 사용자가 값을 수정할 수 없다는 뜻입니다. 생성 후 변경 금지는 최초 입력은 허용하되 저장한 뒤 업데이트를 막는 요구입니다. 생성과 저장 후 변경을 각각 확인해야 합니다.
화면에서 필드를 숨기면 권한 검증이 끝난 건가요?
아닙니다. 화면 표시만이 아니라 실제 사용하는 검색·미리보기·내보내기 등에서도 열람 제한이 유지되는지 확인해야 합니다. 확인하지 않은 경로까지 차단된 것으로 기록해서는 안 됩니다.
공유할 고객정보와 제한할 민감 정보를 먼저 정하세요
고객정보를 한곳에 모으는 것과 모든 정보를 모든 사람에게 여는 것은 다릅니다. 함께 일하는 데 필요한 고객정보는 공유하고, 민감 정보는 필요한 사람에게만 허용하는 것이 핵심입니다. 본부·팀별 거래 접근 범위, 민감 필드의 열람·수정 권한, 생성 후 보존해야 할 값의 변경 가능 여부를 각각 정하세요.
먼저 우리 조직에서 공유할 고객정보, 필요한 사람에게만 허용할 민감 정보, 생성 후 바뀌면 안 되는 필드를 적어보세요. 그리고 역할별로 허용할 행동과 차단할 행동을 한 쌍씩 만드세요. 그 목록이 있으면 기능 설명을 듣는 데서 그치지 않고 실제 업무 기준으로 권한을 확인할 수 있습니다.
트래킷을 검토하신다면 이 목록과 우리 조직의 업무 흐름을 기준으로 고객정보 공유와 민감 정보 제한이 함께 적용되는지 확인해보세요.