🔐 로그인은 하나, 권한은 둘
이 프로젝트를 설계하면서 가장 고민이 많았던 부분 중 하나는 바로
“학생과 관리자가 동일한 로그인 페이지를 통해 접근하되, 서로 다른 권한을 갖게 하자”는 요구사항이었습니다.
처음에는 간단하게 생각했습니다.
“그냥 Role만 구분하면 되겠지?”
하지만 구현 단계에서는 여러 갈래의 고민이 이어졌습니다.
- 학생은 OAuth2만 허용하고, 관리자는 로컬 로그인만?
- 관리자도 OAuth2를 쓸 수 있게 하려면 추가 정보 입력을 어떻게 처리하지?
- 로그인 후 역할에 따라 라우팅을 나눌까, 통합할까?
- 로그인 폼을 아예 나눌까, 하나로 통합할까?
결국 제가 내린 결론은 이랬습니다:
👩🎓 학생
- 로그인 방식: 군번(ID) +
군번+생년월일 6자리(초기 비밀번호) - 사전 등록된 DB 정보 기반으로만 로그인 가능
- 최초 로그인 시 비밀번호 즉시 변경 필수
- 자동으로
ROLE_STUDENT부여 - 학생 전용 기능만 접근 가능
👩💼 관리자
✅ 로컬 로그인
- 회원가입 시 이름, 군번, 이메일 등 기본 정보 입력
ROLE_PENDING_ADMIN상태로 DB 저장 (로그인 불가)- 총괄 관리자(
ROLE_TOP_ADMIN)의 승인 후 ROLE_MID_ADMIN권한 부여 → 로그인 가능
✅ OAuth2 로그인 (Google / Kakao)
- OAuth2 로그인 성공 시
ROLE_TEMP으로 임시 등록 - 즉시 추가 정보 입력 페이지로 리디렉션
- 입력 완료 시
ROLE_PENDING_ADMIN으로 상태 전환 - 총괄 관리자 승인 후
ROLE_MID_ADMIN으로 변경 → 로그인 가능
🗝️ 관리자 권한 접근 정책
✅ ROLE_TEMP, ROLE_PENDING_ADMIN
- 로그인 가능
- 하지만
/admin/**경로는 모두 접근 차단 - 단, 예외적으로 아래 경로는 접근 허용:
/admin/profile(추가 정보 입력용 페이지)
🔒 관리 기능은 사용 불가
✅ ROLE_MID_ADMIN, ROLE_TOP_ADMIN
/admin/**경로 포함한 모든 관리자 기능 접근 가능- 권한 설명:
ROLE_MID_ADMIN: 일반 관리자ROLE_TOP_ADMIN: 총괄 관리자 (다른 관리자 승인 가능)
🧑✈️ 총괄 관리자 (ROLE_TOP_ADMIN)
ROLE_TOP_ADMIN은 시스템 초기 등록 시 1명만 존재- 승인 대기 관리자 조회/승인 기능 (
/admin/pending-admins)은 TOP_ADMIN만 접근 가능 - 추후 인수인계를 위한
TOP_ADMIN권한 이관 기능 별도 개발 예정
⚙️ 설계 흐름
로그인 요청
├── 학생 로그인 (로컬)
│ └── DB에 저장된 사전 등록 정보 확인 → ROLE_STUDENT 부여
│
└── 관리자 로그인
├── 로컬 회원가입 → ROLE_TEMP
│ └── ROLE_TOP_ADMIN 승인 → ROLE_MID_ADMIN
│
└── OAuth2 로그인 → ROLE_TEMP
└── 추가 정보 입력 → ROLE_PENDING_ADMIN
└── ROLE_TOP_ADMIN 승인 → ROLE_MID_ADMIN🔁 로그인 폼, 하나로 통합할 것인가?
이 프로젝트에서 고민했던 포인트 중 하나는
"로그인 폼을 기술적으로 통합하면서도, 사용자 경험을 구분할 수 있을까?"였습니다.
처음에는 /login 하나로 통합된 폼만 제공했지만, 학생과 교직원이 혼동하지 않도록 UI 상에서만 탭으로 구분하는 방식으로 개선했습니다.
- 기술적으로는 여전히 하나의 엔드포인트(
/login) - 입력받은
userId(군번)을 기반으로 이메일을 조회 - Spring Security 내부에서 이메일 기반 인증 수행
덕분에 로그인 플로우는 단순하게 유지하면서도, 학생 / 관리자의 구분은 Role 기반으로 유연하게 처리할 수 있었습니다.
✅ 다음 글에서는...
다음 글에서는 가장 핵심 기능인 학생과 관리자가 주고받는 수리 요청 프로세스를 어떻게 시스템으로 구현했는지 소개할 예정입니다.
특히 수리 이력 관리, 상태 변경 흐름, 권한에 따른 요청 처리 방식까지 실제 현장 문제를 어떻게 해결했는지 상세히 풀어보려고합니다!
개발자를 꿈꾸며, 하루하루 쌓아가는 로제의 지식 아카이브입니다.