서비스를 직접 운영하기 위해서는 내 서비스에서 고객 로그인과 관리자 로그인이 어떻게 구분되는지 반드시 이해해야 합니다.
핵심은 “
누가로그인했는가”를 확인하는 인증(Authentication) 과 “무엇을할 수 있는가”를 판단하는 인가(Authorization) 를 분리해서 생각하는 것입니다.
| 구분 | 학습 내용 |
|---|---|
| 인증 (민증) | 사용자가 누구인지 확인하는 과정 |
| 인가 (허가) | 로그인한 사용자가 특정 화면이나 기능에 접근할 수 있는지 판단하는 과정 |
| 세션 | 로그인 상태를 서버가 기억하는 방식 |
| 관리자 세션 | 관리자 화면과 관리 기능에 접근할 수 있는 세션 |
| 고객 세션 | 일반 사용자가 서비스 기능을 이용할 때 쓰는 세션 |
| 관리자 보호 | 관리자 화면 존재 자체를 숨기고, 서버 동작마다 권한을 다시 확인하는 구조 |
웹 서비스에서 로그인은 단순히 “비밀번호가 맞는지”만 보는 기능이 아닙니다. 로그인 이후에는 서비스가 계속 다음 질문을 판단해야 합니다.
“이 사용자는 누구인가?” “이 사용자는 지금 이 기능을 사용할 수 있는가?” “이 사용자가 관리자 기능을 호출해도 되는가?”
예를 들어 온라인 강의 서비스를 생각해 보겠습니다.
| 사용자 | 가능한 행동 |
|---|---|
| 비로그인 방문자 | 강의 소개 보기, 로그인 요청 |
| 일반 고객 / 수강생 | 내 강의 보기, 결제 내역 보기, 과제 제출 |
| 관리자 | 강의 등록, 수강생 관리, 결제 상태 확인, 공지 발송 |
여기서 중요한 점은 관리자도 결국 로그인한 사용자 중 하나라는 것입니다. 다만 관리자에게는 더 높은 권한이 부여되어 있습니다.
출입증) 은 “로그인 상태를 기억하는 표식”이다사용자가 로그인에 성공하면 서버는 보통 세션(session) 을 발급합니다. 세션은 사용자가 매번 본인 확인을 반복하지 않도록 서버가 로그인 상태를 기억하는 방식입니다.
단순화하면 다음과 같은 흐름입니다.
%%{init: {
"theme": "base",
"themeVariables": {
"primaryColor": "#EAF2FF",
"primaryTextColor": "#1F2937",
"primaryBorderColor": "#7AA2F7",
"lineColor": "#64748B",
"secondaryColor": "#F8FAFC",
"tertiaryColor": "#FDF2F8",
"fontFamily": "Pretendard, Inter, Arial"
}
}}%%
flowchart LR
A["사용자가 로그인 요청<br/>예: 이메일 매직링크 클릭"] --> B["서버가 사용자 확인<br/>등록된 이메일인지 확인"]
B --> C["세션 생성<br/>로그인 상태를 나타내는 기록"]
C --> D["브라우저에 세션 쿠키 저장<br/>다음 요청부터 함께 전송"]
D --> E["서비스 이용<br/>내 강의, 내 정보, 관리 화면 등 접근 시도"]
classDef user fill:#EAF2FF,stroke:#3B82F6,stroke-width:1.5px,color:#1F2937;
classDef server fill:#ECFDF5,stroke:#10B981,stroke-width:1.5px,color:#064E3B;
classDef browser fill:#FFF7ED,stroke:#F97316,stroke-width:1.5px,color:#7C2D12;
classDef service fill:#FDF2F8,stroke:#DB2777,stroke-width:1.5px,color:#831843;
class A user;
class B,C server;
class D browser;
class E service;
세션 테이블에는 최소한 다음 정보가 들어갈 수 있습니다.
| 필드 | 의미 |
|---|---|
sessionId |
세션을 구분하는 고유값 |
email |
로그인한 사용자 이메일 |
role |
user 또는 admin 같은 역할 |
createdAt |
세션 생성 시각 |
expiresAt |
세션 만료 시각 |
사용자는 모르는 서비스 내부적으로 판단하는 용도의 정보!
이때 role 값만으로 관리자를 판단하면 위험합니다.
데이터가 잘못 들어가거나 오래된 관리자 세션이 남아 있으면, 원치 않는 관리자 접근이 가능해질 수 있습니다.
신원 판정은 반드시 이중으로 확인한다 → 역할 정보와 식별 정보 모두 확인!