관리자 인증과 고객 인증

서비스를 직접 운영하기 위해서는 내 서비스에서 고객 로그인관리자 로그인이 어떻게 구분되는지 반드시 이해해야 합니다.

핵심은 “누가 로그인했는가”를 확인하는 인증(Authentication) 과 “무엇을 할 수 있는가”를 판단하는 인가(Authorization) 를 분리해서 생각하는 것입니다.

구분 학습 내용
증 (민증) 사용자가 누구인지 확인하는 과정
가 (허가) 로그인한 사용자가 특정 화면이나 기능에 접근할 수 있는지 판단하는 과정
세션 로그인 상태를 서버가 기억하는 방식
관리자 세션 관리자 화면과 관리 기능에 접근할 수 있는 세션
고객 세션 일반 사용자가 서비스 기능을 이용할 때 쓰는 세션
관리자 보호 관리자 화면 존재 자체를 숨기고, 서버 동작마다 권한을 다시 확인하는 구조

1단계. 로그인은 “신분 확인”이고, 권한은 “출입 가능 구역 확인”이다

웹 서비스에서 로그인은 단순히 “비밀번호가 맞는지”만 보는 기능이 아닙니다. 로그인 이후에는 서비스가 계속 다음 질문을 판단해야 합니다.

“이 사용자는 누구인가?” “이 사용자는 지금 이 기능을 사용할 수 있는가?” “이 사용자가 관리자 기능을 호출해도 되는가?”

예를 들어 온라인 강의 서비스를 생각해 보겠습니다.

사용자 가능한 행동
비로그인 방문자 강의 소개 보기, 로그인 요청
일반 고객 / 수강생 내 강의 보기, 결제 내역 보기, 과제 제출
관리자 강의 등록, 수강생 관리, 결제 상태 확인, 공지 발송

여기서 중요한 점은 관리자도 결국 로그인한 사용자 중 하나라는 것입니다. 다만 관리자에게는 더 높은 권한이 부여되어 있습니다.


2단계. 세션 (출입증) 은 “로그인 상태를 기억하는 표식”이다

사용자가 로그인에 성공하면 서버는 보통 세션(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 값만으로 관리자를 판단하면 위험합니다. 데이터가 잘못 들어가거나 오래된 관리자 세션이 남아 있으면, 원치 않는 관리자 접근이 가능해질 수 있습니다.


3단계. 관리자 신원 판정은 반드시 이중으로 확인한다 → 역할 정보와 식별 정보 모두 확인!