메뉴/기능 권한 설계를 초기에 안 한 것 (RBAC)

처음엔 “로그인만 되면 다 보여 주자”였습니다. 누가 무엇을 볼 수 있고 무엇을 할 수 있는지를 뒤로 미뤘습니다. 1인이 만들고 1인이 테스트하니, 권한이 없어도 당장은 불편하지 않았으니까요. 하지만 ERP는 본질적으로 권한 시스템입니다. 권한은 화면 위에 덧칠하는 게 아니라 바닥에 까는 것이라는 걸, 덧칠을 시작하고 나서야 알았습니다.

뒤늦게 바닥에 깐 권한 축. 역할(슈퍼관리자·관리자·직원…)별로 어떤 메뉴에 접근할 수 있는지를 매트릭스로 정의하고, 사람에게는 역할만 배정합니다. 처음부터 이 축이 있었다면 화면마다 가드를 손으로 소급해 붙일 일이 없었습니다.

용어부터 — RBAC와 가로지르는 관심사

용어: RBAC(역할 기반 접근 제어)

Role-Based Access Control. 사람마다 권한을 일일이 주지 않고, “역할”(예: 인사 담당자, 일반 직원, 시스템 관리자)에 권한을 묶은 뒤 사람에게 역할을 부여하는 방식입니다. 권한 관리의 표준 패턴입니다.

용어: 가드(guard)

어떤 기능이나 화면에 들어가기 전, “이 사람이 이걸 할 자격이 있나”를 검사하는 문지기 코드입니다. 통과하지 못하면 차단합니다.

용어: 가로지르는 관심사(cross-cutting concern)

한 화면의 기능이 아니라 모든 화면을 관통하는 축입니다. 권한, 로깅, 감사 같은 것들이 여기 속합니다. 한 곳에 모여 있지 않고 시스템 전체에 흩어져 있어, 나중에 추가하면 빠짐없이 붙이기가 매우 어렵습니다.

권한 없이 먼저 굴러간 화면들

초기에는 권한 모델이 없었습니다. 인증만 통과하면 메뉴가 다 보이고 기능도 다 눌렸습니다. 1인이 만들고 1인이 테스트하니, 권한이 없어도 당장은 아무 불편이 없었습니다. 그래서 “역할은 나중에”가 됐습니다.

하지만 ERP는 본질적으로 권한 시스템입니다. 인사 담당자가 보는 화면과 일반 직원이 보는 화면이 다르고, 결재 승인은 아무나 누르면 안 되고, 어떤 관리 화면은 시스템 관리자만 들어가야 합니다. 기능이 쌓일수록 “이건 누가 볼 수 있어야 하지?”라는 질문이 화면마다 따라붙었고, 매번 그 자리에서 즉흥적으로 답했습니다. 즉흥적으로 답한 권한 규칙은 화면마다 모양이 달랐고, 어딘가는 아예 빠졌습니다.

함정 — 권한은 한 화면의 기능이 아니라 모든 화면을 관통하는 축이다

권한을 나중에 끼워 넣으면, 이미 만들어 둔 메뉴·버튼·기능 하나하나에 “이 역할이면 통과”를 손으로 다시 붙여야 합니다. 100개 화면이면 100번 붙여야 하고, 빠뜨린 한 곳이 곧 권한 구멍이 됩니다. 처음에 축으로 깔지 않으면, 나중엔 누더기로 깁게 됩니다. 그리고 누더기에는 항상 꿰매지 않은 틈이 남습니다.

그림으로 보기 — 덧칠 vs 바닥

왼쪽(덧칠): 화면을 다 만든 뒤 가드를 하나하나 손으로 붙이면, 빠뜨린 칸이 그대로 권한 구멍이 됩니다. 오른쪽(바닥): 권한을 바닥 축으로 먼저 깔면 화면은 그 위에서 "내가 어떤 역할에게 보이는가"를 알고 태어나므로 빠짐이 생기지 않습니다.

뒤늦은 RBAC 토대 공사

결국 역할 기반 접근 제어(RBAC)의 토대를 단계적으로 깔았습니다. 한 번에 끝나는 일이 아니라 여러 단계의 공사였습니다.

1. 역할 정의 — 시스템이 인정하는 역할들을 정합니다(일반 직원·인사 담당·시스템 관리 등).
2. 기능 가드 — 각 기능 진입 앞에 “이 역할이면 통과” 문지기를 붙입니다. 이미 만들어 둔 화면들에는 이걸 소급해서 붙여야 했습니다.
3. 사용자·역할 관리 — 누구에게 어떤 역할을 줄지 운영 화면에서 다룹니다(2026-06-10에 역할 배정 저장 기능 구현).
4. 역할 기반 메뉴 — 메뉴를 역할에 따라 묶어 내려 주도록 구조를 다시 짭니다. 메뉴 가시성도 권한에서 흘러나오게 합니다.
5. 스코프 가드 — “볼 수 있다”와 “승인할 수 있다”를 구분하고, 부서장은 자기 부서와 하위 부서까지만 보도록 범위를 좁힙니다.

역할(예)	볼 수 있는 것	할 수 있는 것
일반 직원	본인 관련 화면	본인 신청·조회
부서장	자기 부서 + 하위 부서	조회 위주 (승인은 권한에 따라)
인사 담당	인사·근태 관리 화면	승인·정정 등 실행
시스템 관리	어드민 구획 전체	코드·사용자·역할 운영

표에서 보듯, 같은 화면이라도 역할마다 “보이는 범위”와 “누를 수 있는 버튼”이 다릅니다. 이 매트릭스를 처음에 한 장 그려 두면, 새 화면은 그 칸을 채우기만 하면 됩니다. 안 그려 두면, 화면마다 즉흥적으로 칸을 채우다 빈칸(=구멍)을 남깁니다.

현실적 타협 — 옛 방식과 새 방식을 동시에 인정하기

설계에는 무중단 이관을 위한 절충이 들어갔습니다. 정적으로(코드/시드 기반) 박힌 역할과, 운영 중 추가하는 동적(DB 기반) 역할을 둘 다 인정하는 방식입니다. 둘 중 하나만 맞아도 통과시킵니다. 이건 “처음부터 DB 역할로 깔끔하게 갔다면” 필요 없었을 호환 장치입니다 — 이미 발급된 토큰과 시드를 깨지 않으려고, 옛 방식과 새 방식이 한동안 공존하게 둔 것입니다. 나중에 끼워 넣은 권한은 이렇게 호환 장치라는 추가 비용까지 데려옵니다.

”볼 수 있다”와 “할 수 있다”는 다르다

권한을 뒤늦게 다루다 보면 흔히 빠지는 함정이 하나 더 있습니다. 조회 권한과 실행 권한을 같은 것으로 취급하는 것입니다. 부서장이 부서원의 정정 요청 목록을 보는 것과, 그 요청을 승인하는 것은 전혀 다른 권한입니다. 목록에 떴다고 승인 버튼까지 눌리면, 그 자체가 권한 구멍입니다.

이걸 처음 설계에 넣어 두면 “이 역할은 조회만, 저 역할은 승인까지”가 화면마다 자연스럽게 갈립니다. 나중에 끼워 넣으면, 이미 “목록=실행”으로 묶어 둔 곳들을 하나하나 떼어내며 “여긴 조회만”을 다시 붙여야 합니다. 그래서 권한은 가능한 한 가장 잘게, 처음부터 구분해 두는 게 쌉니다.

권한을 나중에 끼워 넣으면	처음부터 축으로 깔면
기존 화면마다 가드를 손으로 소급 부착	새 화면이 권한 메타데이터를 달고 태어남
빠뜨린 한 곳 = 권한 구멍	메뉴·가드가 같은 출처에서 자동 생성 → 빠짐 없음
옛/새 역할 호환 장치라는 추가 비용	처음부터 한 방식이라 호환 장치 불요
”조회=실행” 혼동을 사후에 분리	조회·실행 권한이 처음부터 구분

처음부터 했다면

권한 모델을 첫 설계에 넣었다면, 새 화면은 처음부터 “어떤 역할이 보는가”를 메타데이터로 달고 태어났을 것입니다. 메뉴 가시성도, 기능 가드도, 그 메타데이터에서 자동으로 흘러나왔을 것입니다. 소급해서 가드를 붙이는 공사도, 옛/새 역할을 동시에 인정하는 호환 장치도, 조회와 실행을 사후에 분리하는 작업도 줄였을 것입니다.

가로지르는 관심사는 처음에 가로질러 깔아야 합니다. 나중에 세로로 쌓아 올린 화면들 사이에 권한을 가로로 끼워 넣으려 하면, 끼우는 자리마다 틈이 생깁니다.

교훈

권한(RBAC)은 기능이 아니라 아키텍처의 축입니다. 첫 화면을 그리기 전에 역할·메뉴·기능 권한의 뼈대를 깔아 — 화면은 그 뼈대 위에서 “내가 누구에게 보이는가”를 알고 태어나야 합니다. “볼 수 있다”와 “할 수 있다”를 처음부터 분리하고, 권한은 가능한 한 잘게 나눠 두세요. 나중에 끼워 넣은 권한은 항상 어딘가에 구멍과 호환 장치를 남깁니다. 가로지르는 관심사는 처음에 가로질러 깔아야 합니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 이어지는 이야기는 〈로그인 통합과 ERP/포탈 권한 분리〉에 있습니다.