diff --git a/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md b/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md
index 683766a..de76092 100644
--- a/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md	
+++ b/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md	
@@ -42,6 +42,54 @@ Baron SSO 로그인 페이지에는 사용자가 선택할 수 있는 로그인
 
 따라서 L7, Nginx, Oathkeeper는 사용자를 인증하는 주체라기보다 "요청을 올바른 내부 서비스로 안전하게 전달하는 앞단 계층"에 가깝다. 실제 로그인 요청 접수와 OIDC 판단은 Hydra가 하고, 비밀번호 검증과 세션 발급은 Backend와 Kratos가 처리한다.
 
+### 3.1 Hydra가 먼저 나오는 이유
+
+처음 흐름을 보면 Hydra가 Kratos보다 먼저 등장하기 때문에 혼동될 수 있다. 직관적으로는 "사용자 인증은 Kratos가 담당하니 Kratos가 먼저 나와야 하는 것 아닌가?"라고 생각할 수 있다.
+
+그러나 Baron SSO의 RP 로그인 흐름에서는 사용자가 처음부터 Baron SSO 로그인 페이지에 직접 온 것이 아니다. 사용자는 먼저 RP 업무시스템에 접속하려고 한다. RP는 자기 세션이 없으면 Baron SSO의 OIDC endpoint로 브라우저를 보낸다.
+
+이 시점에 Baron SSO가 먼저 판단해야 하는 것은 사용자의 비밀번호가 맞는지가 아니다. 먼저 확인해야 하는 것은 "어느 RP 시스템이 어떤 OIDC 로그인 요청을 보냈는가"이다.
+
+역할을 나누면 다음과 같다.
+
+| 질문 | 담당 |
+| --- | --- |
+| 어느 RP가 로그인을 요청했는가? | Hydra |
+| 이 RP의 `client_id`가 정상인가? | Hydra |
+| `redirect_uri`가 등록된 주소인가? | Hydra |
+| 요청한 `scope`, `state`, `nonce`, `code_challenge`가 정상인가? | Hydra |
+| 사용자가 실제 누구인가? | Kratos |
+| 비밀번호, 코드, 세션이 유효한가? | Kratos |
+| 인증된 사용자를 RP 로그인 요청에 연결하는가? | Baron Backend -> Hydra |
+
+따라서 Hydra가 먼저 하는 일은 "사용자 인증"이 아니라 "RP 로그인 요청 접수"이다. 이때 생성되는 `login_challenge`도 사용자 식별자가 아니라 RP 로그인 요청 식별자다.
+
+쉽게 표현하면 다음과 같다.
+
+```text
+Hydra = RP 로그인 신청 접수처
+Kratos = 사용자 본인확인 창구
+Baron Backend = 두 시스템을 연결해서 완료 처리하는 중계자
+```
+
+전체 흐름은 다음처럼 이해하면 된다.
+
+```text
+1. RP 로그인 요청 접수
+   담당: Hydra
+
+2. 사용자 본인 인증
+   담당: Kratos
+
+3. 인증된 사용자를 RP 로그인 요청에 연결
+   담당: Baron Backend -> Hydra
+
+4. RP로 최종 복귀
+   담당: Hydra
+```
+
+즉 `login_challenge`는 "이 사용자가 누구인가"를 나타내는 값이 아니다. "이 RP 로그인 요청 건이 무엇인가"를 나타내는 임시 접수번호다. 사용자가 로그인 화면에서 비밀번호, 로그인 링크, QR 코드 중 하나로 인증을 마치면 Backend가 이 접수번호를 들고 Hydra에 `AcceptLoginRequest`를 호출하여 "이 접수 건은 이 사용자로 로그인 완료"라고 알려준다.
+
 ```mermaid
 flowchart LR
     User[사용자 브라우저]