그린 파인애플님의 블로그
[ERP 구축기 #05] 메뉴 숨김만으로 충분할까? ERP의 RBAC 권한 설계 본문
🚧 ERP에서는 모든 사용자가 같은 기능을 사용할 수 없다
ERP 시스템을 개발하다 보면 사용자에 따라 접근할 수 있는 메뉴와 수행할 수 있는 작업을 다르게 제어해야 한다.
예를 들어 같은 메뉴를 사용하더라도 일반 사용자는 조회만 가능하고, 업무 담당자는 데이터를 등록하거나 수정할 수 있으며, 관리자만 삭제할 수 있도록 권한을 구분해야 할 수 있다.
신규 PQ 시스템에서도 이러한 요구사항이 있었기 때문에 RBAC(Role-Based Access Control, 역할 기반 접근 제어) 방식으로 권한 관리 기능을 설계했다.
관리의 편의성을 위해 기존 사용자 및 메뉴 정보와 연계하여 DB에서 역할과 메뉴 권한을 관리하는 방식으로 구현하기로 했다.
📎 역할 기반 권한 + 사용자별 예외 권한
기본적인 권한은 역할(Role)을 기준으로 관리하도록 했다.
예를 들어 일반 사용자, 업무 담당자, 관리자와 같은 역할에 메뉴별 CRUD 권한을 부여하고 사용자는 해당 역할을 통해 권한을 가지게 된다.
다만 실제 ERP를 운영하다 보면 동일한 역할을 가진 사용자 중 특정 사용자에게만 추가 권한을 부여해야 하는 경우가 있기 때문에 사용자별 예외 권한도 설정할 수 있도록 구성했다.
부서별 권한도 검토했지만 현재 업무 규모에서는 역할 기반 권한만으로 충분하다고 판단하여 제외했고, 필요할 경우 추후 확장할 예정이다.
현재 시스템은 내부 사용자가 중심이고, 이용자가 명확하기 때문에 권한 구조를 복잡하게 만들지 않고, 실제 업무에 필요한 수준으로 단순화하여 설계했다

엑셀 다운로드나 출력 기능까지 별도의 권한으로 세분화할 수도 있지만, 현재 업무에서는 조회 권한으로 함께 제어하는 수준이면 충분하다고 판단했다.
| 의미 | 시스템 동작 |
| 등록 | 신규 데이터 등록 가능 |
| 조회 | 메뉴 접근 및 데이터 조회 가능 |
| 수정 | 기존 데이터 수정 가능 |
| 삭제 | 데이터 삭제 가능 |
설계한 구조는 아래와 같다
로그인에 성공하면 Backend의 권한 API를 호출하여 현재 사용자가 사용할 수 있는 메뉴와 CRUD 권한을 조회한다.
Frontend에서는 조회한 권한 정보를 이용하여 사이드바 메뉴를 노출하고 업무 화면 진입시 권한에 따라 등록·수정·삭제등의 버튼을 활성화/비활성화한다.
하지만 Frontend에서 메뉴나 버튼을 숨기는 것만으로는 실제 보안을 보장할 수 없다.
브라우저의 localStorage 값은 사용자가 직접 변경할 수 있고, 화면을 거치지 않고 API를 직접 호출하는 것도 가능하기 때문이다.
따라서 Frontend의 권한 제어는 사용자 편의를 위한 UX 용도로 사용하고, 실제 데이터 접근 권한은 Backend API에서 다시 검증하도록 구현했다.


권한 제어와 별개로 주요 API 호출에 대해서는 감사로그(Audit Log)를 기록하도록 구성했다.
누가, 언제, 어떤 API를 호출했는지 기록하여 문제가 발생했을 때 사용자 행위를 추적할 수 있도록 했으며, 비정상적인 사용 패턴이나 확인이 필요한 계정은 배치를 통해 별도로 확인할 수 있도록 구성했다.

권한제어를 하는 화면의 구성은 아래와 같이 했고
편의를 위해 행, 특정 모듈의 메뉴는 한번에 전체 체크 가능하도록 구성했다



🔐 앞으로 추가할 보안 기능
현재는 메뉴 및 CRUD 권한을 중심으로 기본적인 접근 제어 기능을 구현했다.
앞으로는 이전 시스템 구축 및 ISMS-P 대응 경험을 활용하여 중복 로그인 제어, 개인정보 암호화, 비밀번호 정책 등 ERP 운영에 필요한 보안 기능을 단계적으로 추가할 예정이다.
📕 기능 구현하면서 느낀 점
처음 권한 기능을 설계할 때는 메뉴를 보여주거나 숨기는 정도로 생각했지만, 실제로 구현하다 보니 화면에서의 권한 제어와 서버에서의 권한 검증은 역할이 다르다는 것을 다시 확인할 수 있었다.
Frontend에서 메뉴나 버튼을 숨기는 것은 사용자가 사용할 수 없는 기능을 보여주지 않기 위한 UX이고, 실제 데이터에 대한 접근을 막는 것은 Backend의 역할이다.
또한 권한을 지나치게 세분화하면 관리가 복잡해질 수 있기 때문에 현재 시스템에 필요한 수준에서 단순하게 시작하고, 실제 운영 과정에서 필요한 권한을 추가하는 방향으로 설계했다.
ERP의 권한 설계에서는 얼마나 많은 권한을 만들 것인가보다, 누가 어떤 데이터와 기능에 접근할 수 있는지를 명확하게 정의하는 것이 더 중요하다고 생각한다.
'개발 > [ERP] 풀스택 AI개발' 카테고리의 다른 글
| [ERP 구축기 #07] 양식이 제각각인 HWPX 문서를 자동 생성해 비용 절감하기 (0) | 2026.09.04 |
|---|---|
| [ERP 구축기 #06] 반복되는 API 호출 줄이기 - Redis와 React Query 캐싱 (0) | 2026.08.28 |
| [ERP 구축기 #04] APM이 없어서 직접 만든 Grafana 모니터링 환경 (0) | 2026.08.26 |
| [ERP 구축기 #03] 현업이 AI로 만든 업무 도구를 ERP 정식 기능으로 발전시키기 (0) | 2026.08.26 |
| [ERP 구축기 #02] "경력사항 입력만 하다 퇴근합니다" - 현업 인터뷰에서 시작된 업무 자동화 (0) | 2026.08.26 |
