🛡 역할 기반 권한 시스템(RBAC), 우리는 이렇게 구성합니다

안녕하세요 makeviibe 입니다.

서비스가 성장하면서 가장 먼저 고민하게 되는 보안 중 하나는

“누가 어떤 기능을 쓸 수 있어야 하는가?”입니다.

 

예를 들어,

“운영자만 유저 목록을 조회할 수 있게 해주세요”

“일반 유저는 본인 정보만 수정 가능해야 해요”

“어드민만 설정을 바꿀 수 있어야 합니다”

 

이런 요구사항이 반복될 때마다 코드를 if문으로 처리한다면

점점 유지보수가 어려워지고, 실수로 권한 없는 유저가 접근하게 되는 상황도 생길 수 있습니다.

 

그래서 makeviibe 팀은 모든 프로젝트에서

역할 기반 권한 시스템(RBAC: Role-Based Access Control) 을 표준으로 설계하고,

Spring Security를 통해 API 단위에서부터 명확한 권한 체계를 적용합니다.

---

✅ 역할 기반 권한 시스템이란?

RBAC은 “사용자의 역할(role)에 따라 접근 권한을 나누는 시스템”입니다.

이 구조의 핵심은 다음과 같습니다:

• 사용자마다 고정된 역할이 1개 이상 주어진다
• 각 역할은 권한의 묶음이다 (기능 단위 권한이 아님)
• 역할은 코드와 문서 모두에서 명확히 관리된다

---

✅ makeviibe 팀의 RBAC 설계 방식

---

1. API 경로 자체에 역할을 드러낸다

우리는 API 경로를 역할 기반으로 구성합니다:

✅ 이렇게 하면:

• 프론트엔드도 어떤 API가 어떤 역할 전용인지 바로 파악할 수 있고
• 개발자가 실수로 잘못된 API를 연결할 확률이 줄어듭니다
• Swagger, Postman 등에서 문서화할 때도 구조가 명확해집니다

---

2. Spring Security에서 역할별 접근을 사전 필터링

Spring Security를 사용해 컨트롤러 진입 전 단계에서 권한 체크를 수행합니다.

이 설정 하나로, /api-admin/** 경로는 관리자만,

/api-user/**는 일반 유저도 접근할 수 있도록 분리됩니다.

---

3. 역할 정보는 JWT 토큰에 포함

makeviibe 팀은 JWT 기반 인증을 사용하며,

토큰 payload에 사용자 ID와 함께 role도 명시합니다.

→ 이 값을 Spring Security에서 추출해 인증 객체에 넣고,

→ 위의 hasRole('ADMIN') 설정에 따라 접근 허용 여부를 판단합니다.

---

4. 컨트롤러에서도 명시적으로 역할 제한

보안은 코드에 “의도”가 드러나는 게 중요합니다.

그래서 @PreAuthorize 혹은 @Secured 등을 사용해

컨트롤러 함수마다 역할 조건을 명확히 선언합니다.

→ 개발자, 코드리뷰어 모두 “이건 관리자만 가능하구나”를 한눈에 파악할 수 있습니다.

---

5. 역할 정의는 Enum + 정책 문서로 함께 관리

코드에는 Enum을 사용하고,

기능별 접근 정책은 Notion 등 협업 툴에서 다음과 같이 정리합니다:

→ 프론트엔드와 기획팀, QA가 참고할 수 있도록 구조화해 둡니다.

---

🎯 왜 이런 구조가 좋은가?

---

✍ 마무리하며

makeviibe 팀은 역할 기반 권한 구조를 기능 개발 초기 단계부터 설계합니다.

우리는 다음을 지향합니다:

• ✅ 권한 조건이 숨겨지지 않고 코드에 명시되도록
• ✅ API 구조로 의도가 드러나도록
• ✅ 인증/인가 흐름이 재사용 가능하고 테스트 가능한 구조로

​

보안은 신뢰의 기본이고, 신뢰는 설계에서 시작됩니다.

그 시작점이 바로 “역할 기반 권한 구조”라고 생각합니다.