chore: 이전 세션이 남긴 변경을 커밋한다

이번 파이프라인 작업과 무관하게 작업 트리에 남아 있던 것을 그대로 올린다.
사용자가 「전부 커밋」으로 정했고, 이번 작업과 섞이지 않게 커밋만 나눴다.

대부분은 clean-architecture-backend-template 의 그림 정본 재배치다 —
final/assets/diagrams/<이름>/ 에 있던 것이 CLAUDE.md 가 적은 배치인
final/assets/<이름>/ 로 옮겨졌고 .techviz/<이름>/ 이 함께 들어왔다.
삽입 줄의 대부분(3.15M)이 그 .techviz context.json 이다.

그 밖에 ca-tmpl·document-haness 의 정리, .claude/agents/ 열한 개,
writing-practitioner-guides 스킬, .playwright-mcp 세션 산출물,
scripts/check-ssot-facts.py 와 그 시험이 들어 있다.

이 커밋의 내용은 내가 만든 것이 아니라 이전 세션이 남긴 것이고 검증하지 않았다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/keycloak/tech-log-studio/oauth-oidc-auth-boundary/question/question-bff-state-store.md

@@ -20,20 +20,7 @@ source:
 
 # BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가
 
-현재 BFF의 세션과 Authorized Client는 프로세스 메모리에 저장된다. 재시작과 레플리카 이동 뒤에도 로그인 상태를 유지하려면 두 상태를 어디에 저장할지 정해야 한다.
-
-BFF(Backend for Frontend)가 서버에 들고 있는 상태는 둘이다. 하나는 브라우저의 로그인 세션이고,
-다른 하나는 Keycloak에서 받은 액세스 토큰과 리프레시 토큰을 담아 두는 Authorized Client다.
-세션은 `session ID`로 찾지만 Authorized Client는 `client registration 이름`과 `principal name`으로 찾는다.
-
-찾는 열쇠가 이렇게 다르니 두 상태를 반드시 한 저장소에 담아야 하는 것은 아니다.
-각각의 조회 방식과 운영 요구사항에 맞게 저장 구조를 따로 정할 수 있다.
-
-공유 저장소 후보로 Redis를 우선 보고 있지만 아직 고르지 않았다.
-액세스 토큰과 리프레시 토큰을 Redis에 담는다면 토큰을 어떤 방식으로 암호화할지, 세션과 토큰의 만료 시간을 어떻게 맞출지,
-로그아웃할 때 세션과 Authorized Client가 모두 지워지는지를 확인해야 하는데 아직 확인하지 않았다.
-
-토큰 보호와 만료 처리, 로그아웃 뒤 상태 정리까지 검증한 다음에 저장 구조를 정한다.
+현재 BFF(Backend for Frontend)의 세션과 Authorized Client는 프로세스 메모리에 저장된다. 재시작과 레플리카 이동 뒤에도 로그인 상태를 유지하려면 두 상태를 어디에 저장할지 정해야 한다.
 
 ## 관계
 
@@ -48,13 +35,19 @@ BFF(Backend for Frontend)가 서버에 들고 있는 상태는 둘이다. 하나
 
 ## 사실
 
+- BFF가 서버에 들고 있는 상태는 둘이다.
+  하나는 브라우저의 로그인 세션이고, 다른 하나는 Keycloak에서 받은 액세스 토큰과 리프레시 토큰을 담아 두는 Authorized Client다.
+  JavaScript 응답에 OAuth 토큰이 보이지 않았을 때는 토큰을 다루는 일도 같이 사라진 것처럼 보였지만,
+  BFF 코드를 따라가 보니 BFF가 세션에서 Authorized Client를 찾아 액세스 토큰을 붙여 내부 API를 대신 불렀다.
 - 현재 구성에는 Spring Session도, Redis도, JDBC 저장소도, 토큰을 암호화해 담는 저장소도 없다.
 - HttpSession은 서블릿 컨테이너의 메모리 구현을 쓰기 때문에, 그 프로세스가 종료되면 세션 데이터도 같이 사라진다.
 - OAuth2AuthorizedClientService도 Spring Boot 자동구성이 고르는 메모리 구현이다.
-- 세션은 session ID로 조회하고 Authorized Client는 registration 이름과 principal name으로 조회한다.
+- 세션은 session ID로 조회하지만 Authorized Client는 registration 이름과 principal name으로 조회한다.
   두 저장 구조를 공유 저장소로 옮길 때는 각각 따로 설계해야 한다.
 - Authorized Client 매니저에는 authorization-code와 refresh-token provider가 함께 구성돼 있어서,
   저장소를 공유하면 여러 인스턴스가 같은 항목을 동시에 갱신할 수 있다.
+- 여기까지는 한 대에서 실행한 학습 환경에서 코드와 테스트로 확인한 것이다.
+  여러 인스턴스가 세션과 Authorized Client를 공유하는지는 실행해 확인하지 못했다.
 
 ## 가정
 
@@ -78,6 +71,7 @@ BFF(Backend for Frontend)가 서버에 들고 있는 상태는 둘이다. 하나
 - Authorized Client를 찾을 때는 session ID를 쓰지 않아서, 세션만 공유해도 같은 사용자의 여러 세션이 같은 토큰을 본다.
 - 현재 테스트에는 저장소 계약이 없다.
 - 모든 화면 요청이 BFF를 지나기 때문에 저장소가 느려지면 화면도 바로 느려진다.
+  다만 이 학습 환경에서는 처리량을 재지 못해서, 어느 지점부터 느려지는지는 숫자로 말할 수 없다.
 
 ## 선택지
 
@@ -137,4 +131,6 @@ Redis와 관계형 DB를 둘 다 인증 경로에서 쓰게 되므로 모니터
 4. 로그아웃 뒤 두 저장소에 잔여 항목이 없는지 확인한다.
 5. 저장소를 끊은 상태에서 로그인과 API 호출이 어떤 오류를 내는지 본다.
 
+토큰 보호와 만료 처리, 로그아웃 뒤 상태 정리까지 검증한 다음에 저장 구조를 정한다.
+
 암호화 키 교체 절차는 후보를 고른 뒤에 따로 설계한다.