내부 도구의 RBAC vs ABAC: 확장 가능한 권한 선택법

내부 도구에서 권한이 복잡해지는 이유

내부 도구는 고객 기록, 환불, 송장, 급여 노트, 거래 금액, 내부 비공개 코멘트 등 비즈니스에서 가장 민감한 부분과 가깝습니다. 모든 사람이 모든 것을 볼 필요는 없고, 편집할 수 있는 사람은 더 적어야 합니다.

권한은 보통 단순하게 시작합니다: “Support는 티켓을 볼 수 있다”, “Finance는 환불을 승인할 수 있다”, “관리자는 팀 성과를 볼 수 있다.” 그러다 조직이 커지고 프로세스가 변하면 도구는 예외들의 조각 모음이 됩니다.

나중에 터지는 패턴은 흔합니다:

• 역할 확산: Support를 추가하고, Support - Senior, Support - EU, Support - EU - Night Shift를 차례로 만들다 보면 누구도 각 역할이 무엇을 포함하는지 기억하지 못하게 됩니다.
• 예외 누적: 몇몇 사람에게는 “딱 한 가지 권한”이 필요하다고 해서 일회성 토글이 쌓입니다.
• 우발적 노출: 화면이 재사용되면서 접근 검사를 다시 하지 않아 누군가 급여 노트, 고객 PII, 매출 보고서를 보게 됩니다.
• 깨진 워크플로: 사용자는 레코드를 볼 수는 있는데 다음 단계를 수행할 수 없거나(또는 그 반대로 컨텍스트를 보지 못한 채 조치를 취할 수 있음) 합니다.
• 고통스러운 감사: “누가 $1,000 이상 환불을 승인할 수 있나?”에 답하려면 수작업 조사가 필요합니다.

RBAC나 ABAC를 일찍 선택하는 목적은 단순히 화면을 잠그는 것이 아닙니다. 새로운 팀, 지역, 정책이 등장했을 때 규칙을 이해하기 쉽게 유지하는 것입니다.

유지되는 권한 모델은 네 가지 특성이 있습니다: 설명하기 쉬우며, 검토하기 쉬우며, 오용하기 어려우며, 변경이 빠릅니다.

RBAC를 쉽게 설명하면 (역할과 그것이 여는 것)

RBAC(역할 기반 접근 제어)는 “직함” 접근법입니다. 사용자는 하나 이상의 역할(Support Agent, Admin 등)을 부여받고, 각 역할에는 그 역할이 볼 수 있고 할 수 있는 고정된 권한 집합이 있습니다. 두 사람이 같은 역할을 가지면 같은 접근을 받습니다.

RBAC는 팀이 일상적으로 대체로 같은 방식으로 운영되고 주요 질문이 기능 수준일 때 잘 동작합니다: “이 화면을 사용할 수 있나?” 또는 “이 작업을 수행할 수 있나?”

지원 콘솔의 예시 역할:

• Support Agent: 티켓 보기, 고객에 답장, 내부 노트 추가
• Support Lead: 에이전트 권한 전부 + 티켓 재할당 및 팀 지표 보기
• Admin: 사용자 관리, 시스템 설정 변경, 권한 규칙 편집

핵심 아이디어는 역할이 특정 개인이 아니라 책임에 매핑된다는 점입니다. 책임이 안정적이면 역할도 안정적이고 모델은 설명하기 쉬운 상태로 유지됩니다.

RBAC가 잘 맞는 경우:

• 조직도가 명확할 때(팀, 리드, 관리자)
• 대부분의 접근 결정이 “이 기능을 사용할 수 있는가?”일 때
• 온보딩이 예측 가능해야 할 때(역할 X를 할당하면 끝)
• 감사가 중요할 때(역할이 무엇을 할 수 있는지 나열하기 쉬움)

현실이 복잡해지면 RBAC만으로는 문제가 생깁니다. 내부 도구는 예외를 모읍니다: 환불을 할 수 있는 지원 에이전트, 한 지역만 봐야 하는 재무 사용자, PII를 볼 수 없는 계약직. 각 예외를 새로운 역할로 해결하면 역할 폭발이 일어납니다.

RBAC만으로 실패하고 있다는 실용적 신호: 매주 “특수 역할”을 추가하기 시작한다면 이미 한계에 와 있습니다.

ABAC를 쉽게 설명하면 (속성 기반 규칙)

ABAC(속성 기반 접근 제어)는 단지 직함으로 결정하지 않고 규칙으로 접근을 판단합니다. “Finance 역할이 무엇을 할 수 있나?” 대신 ABAC는 “이 사람이 누구이고, 이 레코드가 무엇이며, 지금 무슨 일이 일어나고 있는가?”를 묻습니다.

속성은 이미 추적하고 있는 사실들입니다. 규칙 예시:

• “지원 에이전트는 자신의 지역의 티켓을 볼 수 있다.”
• “매니저는 근무시간 내에 $5,000 미만의 비용을 승인할 수 있다.”

대부분의 ABAC 시스템은 몇 가지 속성 범주를 사용합니다:

• 사용자 속성: 부서, 지역, 관리자 여부
• 데이터 속성: 레코드 소유자, 티켓 우선순위, 송장 상태
• 컨텍스트 속성: 시간대, 디바이스 유형, 네트워크 위치
• 행동 속성: 보기 vs 편집 vs 내보내기

구체적 예: 지원 에이전트는 (a) 티켓 우선순위가 치명적이 아니고, (b) 티켓이 본인에게 할당되어 있으며, (c) 고객 지역이 본인의 지역과 일치할 때만 티켓을 편집할 수 있습니다. 이렇게 하면 Support - EU - Noncritical, Support - US - Noncritical 같은 별도 역할을 만들 필요가 없습니다.

단점은 예외가 쌓이면 ABAC도 추론하기 어려워진다는 점입니다. 몇 달 지나면 “누가 인보이스를 내보낼 수 있나?” 같은 기본 질문에 긴 조건 체인을 읽지 않고는 답할 수 없게 됩니다.

좋은 ABAC 습관은 규칙을 적게, 일관성 있게, 평이한 이름으로 유지하는 것입니다.

레코드 수준 접근: 실수가 가장 자주 발생하는 지점

많은 팀이 권한을 “이 화면을 열 수 있나?”로 취급합니다. 이것은 첫 번째 층일 뿐입니다. 레코드 수준 접근은 화면을 열 수 있더라도 어떤 행(row)을 볼 수 있고 변경할 수 있는지를 결정합니다.

지원 담당자와 재무 담당자가 둘 다 Customers 페이지에 접근할 수 있다고 가정해보세요. 화면 수준 접근에서 멈추면 모두에게 모든 것을 보여줄 위험이 있습니다. 레코드 수준 규칙은 그 페이지 안에서 로드되는 데이터를 좁힙니다.

일반적인 레코드 수준 규칙 예시:

• 본인 고객만 (assigned_owner_id = current_user.id)
• 본인 지역만 (customer.region IN current_user.allowed_regions)
• 본인 원가 센터의 송장만 (invoice.cost_center_id IN current_user.cost_centers)
• 본인 팀의 티켓만 (ticket.team_id = current_user.team_id)
• 본인이 생성한 레코드만 (created_by = current_user.id)

레코드 수준 접근은 UI가 아니라 데이터가 조회·수정되는 곳에서 강제돼야 합니다. 실제로는 쿼리 레이어, API 엔드포인트, 비즈니스 로직에서 적용되어야 합니다.

일반적인 실패 모드는 “페이지는 잠겼는데 API는 열려 있음”입니다. 비관리자에게 버튼을 숨겼지만 엔드포인트는 여전히 모든 레코드를 반환합니다. 앱 접근 권한이 있는 사람은 요청을 재사용하거나 필터를 조작해 그 호출을 트리거할 수 있습니다.

모델을 점검하는 간단한 질문들:

• 사용자가 엔드포인트를 직접 호출해도 허용된 레코드만 반환되는가?
• 리스트, 상세, 내보내기, 집계(count) 엔드포인트가 동일한 규칙을 적용하는가?
• 생성, 업데이트, 삭제는 읽기와 별도로 검사되는가?
• 관리자는 규칙을 의도적으로 우회하는가, 아니면 실수로 우회하는가?

화면 권한은 방에 들어갈 수 있는 사람을 결정합니다. 레코드 수준 접근은 들어온 사람이 방 안에서 어떤 서랍을 열 수 있는지를 결정합니다.

실제 예시: 지원, 재무, 매니저

목표는 “완벽한 보안”이 아니라 오늘 사람들이 이해할 수 있고, 나중에 워크플로를 깨지 않고 변경할 수 있는 권한입니다.

지원팀

지원팀은 보통 레코드 수준 규칙이 필요합니다. “모든 티켓”은 거의 사실이 아니기 때문입니다.

간단한 모델: 에이전트는 자신에게 할당되었거나 자신의 큐에 있는 티켓을 열고 업데이트할 수 있습니다. 팀 리드는 티켓을 재할당하고 에스컬레이션에 개입할 수 있습니다. 매니저는 편집 권한 없이 대시보드를 볼 필요가 있는 경우가 많습니다.

일괄 작업과 내보내기는 흔한 변수입니다. 많은 팀이 일괄 종료는 허용하지만 일괄 재할당을 제한하고, 내보내기는 리드와 매니저로 제한하며 로깅을 적용합니다.

재무팀

재무 접근은 주로 승인 단계와 명확한 감사 추적에 관한 것입니다.

일반적인 설정: AP 담당자는 청구서를 생성하고 초안을 저장할 수 있지만 승인이나 지급은 할 수 없습니다. 컨트롤러는 승인 및 지급 해제를 할 수 있습니다. 감사자는 첨부파일을 포함해 읽기 전용이어야 하며, 공급업체 세부 정보를 변경할 수 없어야 합니다.

현실적인 규칙 예: “AP 담당자는 자신이 생성한 초안은 편집할 수 있다; 제출된 이후에는 오직 컨트롤러만 변경할 수 있다.” 이는 레코드 수준 접근(상태 + 소유자)에 해당하며, 역할을 더 만드는 것보다 ABAC에 더 잘 맞는 경우가 많습니다.

매니저

대부분의 매니저는 넓은 가시성이 필요하지만 편집 권한은 제한되어야 합니다.

실용적인 패턴: 매니저는 대부분의 운영 데이터를 볼 수 있지만 편집은 팀 소유 또는 직속 보고서에 연결된 레코드(휴가 요청, 목표, 성과 노트 등)로만 제한합니다. team_id, manager_id, 고용 상태 같은 속성은 부서마다 역할을 만드는 것보다 명확한 경우가 많습니다.

이들 그룹 전반에서 보통 필요한 것:

• 지원: 할당/큐별 가시성, 신중한 내보내기, 통제된 재할당
• 재무: 상태 기반 규칙(초안 vs 제출 vs 승인), 엄격한 승인, 감사 안전(read-only) 접근
• 매니저: 넓은 보기, 제한된 편집(팀 소유 또는 직속 보고서 레코드)

결정 매트릭스: 역할 vs 속성 vs 레코드 수준 규칙

어느 쪽이 “더 낫다”를 논쟁하기보다는 접근 문제의 어떤 부분이 각 모델에 맞는지 물어보세요. 대부분의 팀은 하이브리드로 끝납니다: 넓은 접근은 역할로, 예외는 속성으로, “내 것만”은 레코드 필터로 처리합니다.

권한 로직을 월 비용처럼 다루세요. 추가되는 역할, 규칙, 예외마다 테스트, 설명, 디버그 비용이 듭니다. 오늘 실제 시나리오를 커버하는 최소한만 쓰세요.

실용적인 기본값:

• 넓은 레인은 RBAC로 시작하세요(Support, Finance, Manager).
• 반복되는 조건(지역, 직급, 고객 등)은 ABAC로 추가하세요.
• 사용자가 “자기 것”만 봐야 한다면 레코드 수준 규칙을 추가하세요.

화면을 만들기 전에 권한을 단계별로 설계하기

UI를 다 만든 뒤에 권한을 결정하면 보통 역할이 너무 많아지거나 특수 사례 더미가 생깁니다. 간단한 계획이 끊임없는 재작업을 막습니다.

1) 화면이 아닌 행동으로 시작하세요

각 워크플로에서 사람들이 실제로 하는 일을 적으세요:

• 보기(읽기)
• 생성
• 편집
• 승인
• 내보내기
• 삭제

환불 흐름에서는 Approve가 Edit과 같지 않습니다. 그 단 하나의 구분이 엄격한 규칙을 필요로 하는지 아니면 단순한 역할로 충분한지를 결정하는 경우가 많습니다.

2) 직무에 맞는 역할 정의

사람들이 회의 없이도 알아볼 수 있는 역할을 선택하세요: Support Agent, Support Lead, Finance Analyst, Finance Manager, Auditor, Admin. “Support Agent - Can edit VIP notes” 같은 역할은 빠르게 폭발합니다.

3) 실제 예외를 만드는 속성 목록 작성

ABAC는 그만한 가치가 있을 때만 추가하세요. 전형적인 속성은 지역, 팀, 고객 티어, 소유권, 금액입니다.

예외가 한 달에 한 번 미만이라면 영구 권한 규칙 대신 수동 승인 단계를 고려하세요.

4) 레코드 수준 규칙을 한 문장 정책으로 작성

레코드 수준 접근은 대부분의 내부 도구가 무너지는 지점입니다. 기술적이지 않은 매니저에게도 보여줄 수 있는 규칙을 작성하세요:

“Support Agents는 자신의 지역의 티켓을 볼 수 있다.”

“Finance Analysts는 승인되기 전까지 자신이 생성한 인보이스를 편집할 수 있다.”

“Managers는 $500 초과 환불을 자신 팀에 대해서만 승인할 수 있다.”

한 문장으로 표현할 수 없으면 그 프로세스는 아마 명확히 정리될 필요가 있습니다.

5) 빌드 전에 실제 사람 다섯 명으로 테스트하세요

다음과 같은 실제 시나리오를 걸어보세요:

• VIP 고객을 처리하는 지원 에이전트
• 인보이스를 수정하는 재무 분석가
• 큰 환불을 승인하는 매니저
• 유지보수를 하는 관리자
• 변경은 못하지만 기록을 봐야 하는 감사자

혼란스러운 부분을 여기서 고치세요. 그래야 권한 미로가 생기기 전에 해결됩니다.

흔한 함정(그리고 회피 방법)

대부분의 권한 실패는 RBAC냐 ABAC냐의 선택 때문에가 아닙니다. 작은 예외들이 쌓여서 아무도 누가 무엇을 할 수 있는지, 왜 그런지를 설명할 수 없게 될 때 발생합니다.

역할 폭발은 보통 “Support Lead에게 버튼 하나가 더 필요하다”로 시작해 결국 한 권한으로 다른 점이 있는 25개의 역할로 늘어납니다. 역할은 넓게(직무형) 유지하고 반복되는 엣지 케이스는 소수의 규칙 기반 예외로 처리하세요.

읽기 어려운 속성 로직은 ABAC의 같은 문제입니다. “department == X AND region != Y” 같은 조건이 여기저기 흩어져 있으면 감사는 추측 작업이 됩니다. 명명된 정책(예: “RefundApproval policy”)을 사용해 수식 대신 정책 이름으로 말할 수 있게 하세요.

내보내기, 리포트, 일괄 작업은 누수가 흔한 곳입니다. 팀이 레코드 뷰를 잠그고도 Export CSV나 일괄 업데이트가 동일한 검사를 우회하는 것을 잊습니다. 모든 비화면 경로를 우선순위 높은 동작으로 간주하고 자체 권한 검사를 적용하세요.

주의할 함정들:

• 예외마다 새 역할 만들기
• 읽기 어려운 또는 명명되지 않은 속성 규칙
• 내보내기, 예약 리포트, 일괄 작업이 검사 건너뛰기
• 서로 다른 도구가 동일한 접근 질문에 다르게 답함
• 어떤 곳에서는 적용되지만 다른 곳에서는 적용되지 않는 레코드 수준 규칙

가장 안전한 해결책은 역할, 속성, 레코드 수준 규칙에 대한 단일 진실 소스를 만들고 백엔드 로직에서 일관되게 시행하는 것입니다.

배포 전 빠른 체크리스트

모델을 설명하기 어렵다면 누군가 “난 그 고객을 볼 수 있어야 한다”거나 “왜 저 사람이 이 목록을 내보낼 수 있지?”라고 말할 때 디버그하기 더 어렵습니다.

대부분의 놀라움을 잡아내는 다섯 가지 검사:

• 실제 사용자가 자신의 접근을 한 문장으로 설명할 수 있는가(예: “나는 Support, region = EU, 내 지역 티켓을 볼 수 있지만 내보내기는 못 함”)? 아니라면 규칙이 분산되어 있을 가능성이 큽니다.
• “누가 내보내기 할 수 있나?”와 “누가 승인할 수 있나?”에 대한 명시적 답이 있는가? 내보내기와 승인은 고위험 행동으로 취급하세요.
• 레코드 수준 규칙이 버튼 숨김이 아니라 데이터가 조회되는 모든 곳(API 엔드포인트, 리포트, 백그라운드 작업)에 적용되는가?
• 민감한 행동에 대해 기본값이 안전한가(기본적으로 거부)? 새 역할, 속성, 화면이 강력한 권한을 실수로 상속받지 않게 하세요.
• “누가 이 특정 레코드를 보고 왜 볼 수 있나?”를 역할, 속성, 레코드 소유/상태 같은 단일 진실 소스로 1분 이내에 답할 수 있는가?

예: 재무는 모든 인보이스를 볼 수 있지만 승인자는 승인만 할 수 있고, 매니저만 전체 공급업체 목록을 내보낼 수 있다. Support는 티켓을 볼 수 있지만 내부 노트는 티켓 소유자의 팀만 볼 수 있다.

권한을 변경할 때 모든 것을 망치지 않는 방법

권한은 지루한 이유로 변경됩니다: 새 매니저가 생기거나 재무가 AP와 AR로 분리되거나, 인수가 일어나 팀이 추가되는 식입니다. 변경을 작고 되돌리기 쉬우며 검토하기 쉽게 계획하세요.

한 번에 하나의 큰 “슈퍼 역할”에 접근을 묶지 마세요. 새 접근은 새 역할, 새 속성, 또는 좁은 레코드 규칙으로 추가한 뒤 실제 작업에 대해 테스트하세요.

재설계 없이 접근 추가하기

새 부서가 나타나거나 합병으로 팀이 추가될 때는 핵심 역할을 안정적으로 유지하고 그 위에 레이어를 추가하세요.

• 기본 역할은 적게 유지(Support, Finance, Manager)하고 작은 추가 권한(Refunds, Export, Approvals)을 덧붙이세요.
• 조직 변경에는 역할 대신 속성(team, region, cost center)을 선호해 새 그룹이 생겨도 역할이 필요 없게 하세요.
• 소유권과 할당(ticket.assignee_id, invoice.cost_center)에는 레코드 수준 규칙을 사용하세요.
• 민감한 행동(지급, 탕감)은 승인 단계를 추가하세요.
• 대부분의 곳에서 내보내기는 별도 권한으로 취급하세요.

임시 접근은 영구 역할 변경을 요구해서는 안 됩니다. 휴가 대체나 사고 대응을 위해서는 "48시간 동안 Finance Approver"처럼 종료일과 이유가 있는 시간 제한 부여를 사용하세요.

감사 주기와 조사 준비 로그

간단한 검토 주기를 사용하세요: 고위험 권한(금전, 내보내기)은 매달, 나머지는 분기마다, 그리고 조직 개편이나 합병 후에는 즉시 검토하세요.

누가 무엇을, 어떤 레코드에, 왜 허용되었는지 대답할 수 있도록 충분히 로그를 남기세요:

• 누가 조회, 편집, 승인, 내보내기를 했는가
• 언제 발생했는가(가능하면 출처 포함)
• 어떤 레코드를 건드렸는가(ID, 타입, 편집의 경우 변경 전/후)
• 왜 허용되었는가(역할, 속성, 레코드 규칙, 임시 부여)
• 누가 접근을 부여했는가(그리고 만료일)

유지할 수 있는 모델을 구현하는 다음 단계

작고 지루한 권한 모델로 시작하세요. 그것이 6개월의 변화를 견딥니다.

좋은 기본은 단순한 RBAC입니다: 실제 직무에 맞는 소수의 역할(Support Agent, Support Lead, Finance, Manager, Admin). 이 역할로 어떤 화면이 존재하는지, 어떤 동작을 사용할 수 있는지, 어떤 워크플로를 시작할 수 있는지를 통제하세요.

그다음 반복되는 실제 예외가 계속 보일 때만 ABAC를 추가하세요. ABAC는 금액 한도, 지역 제한, 소유권, 상태처럼 조건이 중요할 때 빛나지만, 신중한 테스트와 명확한 소유 주체가 필요합니다.

규칙을 먼저 평이한 문장으로 작성하세요. 문장으로 말하기 어려운 규칙은 유지보수가 어려울 가능성이 큽니다.

빠르게 파일럿을 해보고 싶다면 AppMaster (appmaster.io) 같은 노코드 플랫폼이 역할, 소유자/팀/상태 같은 데이터 필드, 그리고 백엔드에서 강제되는 워크플로를 초기에 모델링하는 데 도움이 됩니다.