DongHyeonkaandClaude Opus 5
2109f726fe
기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만 있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문 종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다. SSOT 결함 둘을 고쳤다. - kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이 「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽 `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다. - virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데 원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다. 기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은 둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더 든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다). 계약을 셋 고쳤다. - kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/** 28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는 것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온 것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 커밋도 28개가 어긋났다). - virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고 재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다. - kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고 넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다. style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져 (실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고, engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고 있었다(Question 기록에서 11.94 → 3.86). verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.8 KiB
kind, slug, title, topic, topicName, project, status, decisionStatus, sourceRevision, source, evidence
| kind | slug | title | topic | topicName | project | status | decisionStatus | sourceRevision | source | evidence | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| PROJECT_DECISION | split-the-two-stores-and-design-each | 세션과 토큰의 저장소를 나눠 각각 설계한다 | where-application-state-lives | 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기 | keycloak-session-store | 게시 전 | ADOPTED | cdac9b8178391311d8eca1ebc6cac15bb62d79af |
|
|
세션과 토큰의 저장소를 나눠 각각 설계한다
로그인 세션은 Redis 에, OAuth 토큰은 PostgreSQL 에 따로 두기로 했다. 한 저장소로 묶는 쪽을 먼저 시도했다가 세션만 옮겨지는 것을 보고 나눴다. 나눈 뒤에도 덮어쓰기와 로그아웃 정리는 풀리지 않았고 원인은 저장소가 아니라 기본키였다.
근거
- 세션과 인가된 클라이언트는 조회 키가 다르다 세션은 세션 id 로 찾고 토큰은 principal 이름으로 찾는다는 것이 나누기로 한 전제다.
- 세션만 Redis 로 옮기자 토큰이 따라오지 않았다 한 저장소로 묶는 대안을 실제로 적용해 보고 반쪽만 옮겨지는 것을 확인했다.
- 기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다 나눠 옮긴 뒤에 무엇이 풀리고 무엇이 풀리지 않는지를 그 실험이 잰다.
결정문
Application Session 은 Redis 에 두고 OAuth2AuthorizedClient 는 JdbcOAuth2AuthorizedClientService 로 PostgreSQL 에 둔다. 두 저장소를 한 덩어리로 다루지 않고 각각 고른다.
인스턴스가 둘 이상이고 요청이 어느 쪽으로 갈지 모르는 구성에만 해당한다. 단일 인스턴스에서는 이 질문이 생기지 않는다.
판단 이유
아무것도 설정하지 않은 Spring Boot 애플리케이션에서 자동구성이 무엇을 고르는지 먼저 봤다. 토큰 쪽은 AuthenticatedPrincipalOAuth2AuthorizedClientRepository 가 잡혔고, 이 구현은 principal 이름으로 찾으므로 조회 키에 세션 id 가 없다. 세션 쪽은 세션 id 로 찾는다. 이름이 비슷한 두 개가 서로 다른 키로 굴러간다.
한 저장소로 묶는 쪽을 먼저 시도했다. SPRING_SESSION_STORE_TYPE=redis 로 Application Session 을 Redis 로 옮기고 빈 구성을 전후로 비교했더니 authorizedClientService, authorizedClientRepository, authorizedClientManager 셋 다 옮기기 전과 같았다. 세션 저장소를 바꿔도 OAuth2AuthorizedClient 는 따라오지 않는다.
그래서 토큰은 JdbcOAuth2AuthorizedClientService 로 PostgreSQL 에 따로 옮겼다. 이 문서가 Q3 에 낸 답도 같다 — "둘은 조회 키가 다르므로 각각 결정해야 한다. 세션을 Redis 로 옮겨도 토큰은 따라오지 않는다".
토큰 쪽 후보는 셋이었다. JdbcOAuth2AuthorizedClientService, Redis 로 직접 구현하는 것, 그리고 세션 안에 넣는 HttpSessionOAuth2AuthorizedClientRepository. 앞의 둘은 같은 인터페이스라 컨트롤러를 안 고쳐도 되지만, 둘 다 principal 이름으로 찾으므로 같은 사용자의 두 세션이 같은 행을 쓰는 것을 막지 못한다. 셋째는 Repository 쪽으로 바꿔야 하지만 세션 단위로 저장되므로 같은 사용자의 다른 브라우저가 서로를 덮어쓰지 않고, 그 대신 세션이 커진다. 셋째를 안 고른 것은 Q3 가 Redis 와 JDBC 중 무엇이냐를 물었기 때문이다. 그 대가가 아래 영향 절의 셋째와 넷째다.
영향
나눈 뒤 네 가지를 물었고 둘은 풀렸다.
다른 인스턴스로 요청해도 되는가 : 된다 재시작 후 로그인 유지 : 된다
이 두 항목은 B-2 의 검증 표에 적힌 판정을 옮긴 것이다. 증거 원문 다섯 개(배포 로그, 스키마, 평문 토큰, 덮어쓰기 시험, 로그아웃 정리) 어디에도 교차 인스턴스 요청이나 재시작 뒤 로그인을 확인한 출력이 없다. 표의 판정까지가 이 결정이 댈 수 있는 근거다.
나머지 둘은 저장소를 나눠도 풀리지 않았다.
같은 사용자의 다른 브라우저가 덮어쓰는가 : 덮어쓴다 로그아웃하면 두 저장소가 다 정리되는가 : 한쪽만
셋째와 넷째의 뿌리는 저장소 선택이 아니라 기본키 한 줄이다. JdbcOAuth2AuthorizedClientService 의 기본 스키마는 기본키를 이렇게 만든다.
PRIMARY KEY (client_registration_id, principal_name)
세션 id 가 이 키에 없어서 같은 사용자의 두 세션이 같은 행을 쓴다. 다른 브라우저로 다시 로그인하면 행이 늘지 않고 값만 바뀐다. 로그아웃한 뒤에는 Redis 세션이 0 키로 정리되고 PostgreSQL 토큰은 1 행으로 살아 있다. 그 행의 refresh token 은 평문이고, bytea 값을 디코드해 JWT 임을 확인했다.
저장소를 Redis 로 골랐든 PostgreSQL 로 골랐든 이 키가 같으면 결과도 같다. 이 결정은 두 문제를 안고 간다.
아직 하지 않은 것도 적어 둔다. 이 실험대는 원인을 기본키로 지목한 데서 멈췄고 스키마를 고쳐 본 적이 없다. 키를 바꾸면 덮어쓰기와 로그아웃 정리가 풀리는지, 평문 토큰을 어떻게 처리할지는 재 보지 않았다.