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>
11 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source, assets, evidence
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | assets | evidence | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | the-winner-of-the-rotation-race-also-loses | 회전 경쟁에서 이긴 요청의 토큰도 쓸 수 없었다 | where-application-state-lives | 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기 | keycloak-session-store | 게시 전 | cdac9b8178391311d8eca1ebc6cac15bb62d79af |
|
|
|
회전 경쟁에서 이긴 요청의 토큰도 쓸 수 없었다
같은 refresh token 으로 동시에 5건을 보내자 이긴 요청의 새 토큰도 쓸 수 없었다. 경쟁이 감지되자 Keycloak 이 client session 을 지웠기 때문이다. 다섯 전부 못 쓰게 되므로 재시도를 「실패한 것만 다시 보낸다」로 설계할 수 없고, 복구하려면 다시 로그인해야 한다.
관계
- 기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다 그 실험은 저장된 토큰이 서로를 덮어쓰는 것을 쟀고, 이 실험은 같은 토큰을 동시에 쓸 때를 쟀다.
- 세션과 토큰의 저장소를 나눠 각각 설계한다 토큰 쪽 설계에 재시도가 왜 따라붙는지를 이 관측이 댄다.
문제
토큰 갱신에 성공하면 Keycloak 은 새 refresh token 을 발급하면서 옛것을 소비된 것으로 표시하므로, 그 토큰이 다시 오면 재사용으로 본다. 이 realm 은 회전을 켜고 재사용 허용을 0 으로 두어 한 번만 쓸 수 있게 해 두었다.
인스턴스가 둘이고 요청이 어느 쪽으로 갈지 모르는 구성에서는 두 replica 가 같은 refresh token 을 거의 같은 시각에 쓸 수 있다. 이때 하나가 이기고 나머지가 400 을 받는다면 진 요청만 다시 보내는 재시도로 복구된다. 실제로 그렇게 갈리는지를 재야 했다.
결론
realm 설정 revokeRefreshToken : true refreshTokenMaxReuse : 0
같은 refresh token 으로 동시에 5건을 보낸 결과 순차 실행으로 재현 : x 이긴 요청이 새 토큰을 받았는가 : o 이긴 요청의 새 토큰을 쓸 수 있었는가 : x 원인 : 경쟁이 감지되자 Keycloak 이 client session 을 지웠다
회전을 느슨하게 둔 두 구성을 같은 절차로 더 걸었을 때 revokeRefreshToken false : 5건 다 200. client session 1 남음 refreshTokenMaxReuse 1 : 성공 2 / 5. 이긴 토큰 재사용 400. client session 0
「하나는 성공하고 나머지가 실패한다」가 아니라 전부 못 쓰게 되는 쪽이었다. 새 토큰 자체가 잘못 발급된 것이 아니라 그 토큰이 매달린 세션이 방금 사라졌기 때문이다.
그래서 이 상황의 복구는 실패한 요청을 다시 보내는 것으로 끝나지 않고 재인증까지 가야 한다.
검증 환경
실험대 : 베어메탈 한 대(test-server, Arch Linux, 12GB, WiFi only) 위의 VM 두 대 kc-lab-1 : k3s server (컨트롤 플레인) · keycloak-1 kc-lab-2 : k3s agent · keycloak-0 · PostgreSQL · Redis 애플리케이션 : BFF(Spring Boot) 두 인스턴스. 노드마다 하나씩 떴다 회전 설정 : revokeRefreshToken true · refreshTokenMaxReuse 0 정책 비교로 더 건 두 구성 : revokeRefreshToken false · refreshTokenMaxReuse 1 동시 요청 수 : 5. 세 구성 모두 같은 수로 걸었다 Keycloak 패치 버전 : 이 측정 기록에 적혀 있지 않다
재현 조건
-
realm 의 회전 설정을 확인한다. revokeRefreshToken 이 true 이고 refreshTokenMaxReuse 가 0 이어야 한다.
-
로그인해서 refresh token 을 하나 확보한다.
-
그 토큰 하나로 토큰 갱신 요청 5건을 동시에 보낸다. 셸에서 각 요청을 백그라운드로 띄우고 wait 으로 모은다. 순차로 돌리면 경합이 생기지 않아 재현되지 않는다.
-
5건의 응답 코드를 각각 기록한다.
-
200 을 받은 요청이 가져온 새 access token 으로 보호된 요청을 한 번 보낸다.
-
그 사용자의 세션에 client session 이 몇 개 남았는지 확인하고, 새로 만든 정상 세션과 견준다. 같은 시점에 revoked_token 행 수도 센다.
-
회전 설정을 바꾸기 전에 세션을 새로 만든다. 앞 구성에서 파괴된 세션으로 재면 무엇을 바꾸든 다섯 다 400 이라 비교가 성립하지 않는다.
-
회전을 끈 구성과 refreshTokenMaxReuse 를 1 로 둔 구성에서 3 번부터 6 번까지를 각각 다시 돌린다.
본문
회전을 켜면 옛 토큰이 소비된 것으로 표시된다
토큰 갱신에 성공하면 Keycloak 은 새 refresh token 을 발급하면서 방금 쓴 토큰을 소비된 것으로 표시한다. 소비된 토큰이 다시 오면 재사용으로 보고 거절하는데, 얼마나 엄격하게 볼지는 realm 설정 두 개가 정한다.
| 설정 | 무엇을 바꾸나 |
|---|---|
| revokeRefreshToken | 회전을 켠다. 옛 토큰을 소비 처리 |
| refreshTokenMaxReuse=0 | 한 번만 쓸 수 있다 (가장 엄격) |
| refreshTokenMaxReuse=1 | 같은 토큰을 두 번까지 허용 — 네트워크 재시도를 견디려는 값 |
동시 5건을 처음 던진 것은 가장 엄격한 쪽인 refreshTokenMaxReuse=0 에서였다. 지금 realm 이 어느 쪽인지는 관리 명령으로 확인한다.
kcadm get realms/<realm> --fields revokeRefreshToken,refreshTokenMaxReuse
순차로 보내면 아무 일도 일어나지 않는다
replica 둘이 같은 refresh token 을 쓰는 상황을 만들려면 요청이 실제로 겹쳐야 한다. 같은 토큰으로 5건을 차례로 보내면 첫 건이 갱신하고 나머지가 소비된 토큰을 들고 오므로 재사용 판정이 순서대로 나올 뿐이다. 그래서 셸에서 요청 5건을 & 로 띄우고 wait 으로 한꺼번에 모아 같은 시각에 도착하게 만들었다.
부하 도구는 쓰지 않았다. 묻는 것이 초당 몇 건까지 견디는가가 아니라 겹치면 무엇이 부서지는가라서, 둘만 겹쳐도 답은 나온다. 5건으로 잡은 것은 뒤에 나오는 오류 문구 두 종류가 한 화면에 같이 보이기 때문이지 다섯이 필요해서가 아니다.
이긴 요청의 토큰도 쓸 수 없었다
동시에 보낸 5건 가운데 하나는 새 토큰을 받았다. 나머지 넷이 받은 400 은 한 가지가 아니었다. 한 건만 Maximum allowed refresh token reuse exceeded 였고 나머지 셋은 Session doesn't have required client 였다 — 뒤의 셋은 회전 판정이 아니라 세션 쪽에서 거절됐다.
이긴 요청의 새 토큰으로 보호된 요청을 보내자 그것도 통하지 않았다. 재사용이 감지된 순간 Keycloak 이 그 토큰만 막은 것이 아니라 세션 쪽을 지웠기 때문이다. 이긴 요청이 받은 토큰은 방금 사라진 client session 에 매달려 있어서 검증을 통과하지 못한다.
이긴 요청이 200 을 받은 것 자체는 어긋난 값이 아니다. 그 요청은 먼저 처리를 시작해 새 토큰 발급까지 갔고, 그 사이에 뒤늦게 도착한 것들이 같은 옛 토큰을 들고 오면서 재사용 탐지를 깨웠다. client session 이 지워진 것은 그 다음이고, 200 응답은 이미 성공이 확정된 상태로 나간다. 두 일의 순서가 전부라서, 응답 코드를 아무리 봐도 그 토큰이 죽었다는 것은 안 보인다.
이 판정은 값 하나만 보고 내리지 않았다. 경합을 겪은 sid 는 user session 행이 남아 있고 client session 만 0 이었는데, 그 0 이 원래 그런 값인지 지워진 결과인지는 값 하나로 구분되지 않는다. 그래서 정상 세션을 하나 새로 만들어 같은 질의를 걸었고, 그쪽은 1 이었다.
토큰을 폐기 목록에 올려 막은 것일 가능성도 함께 지웠다. 같은 시점에 revoked_token 을 세었더니 0 행이었다. 토큰을 지우는 방식이었다면 그 client 의 다른 토큰은 살아 있어야 하는데, 여기서는 그 client 몫이 한꺼번에 죽는다.
그림에서 동시 요청 다섯이 회전 검사로 모이고, 거기서 나가는 화살표는 client session 을 지우는 쪽으로 간다. 이긴 요청의 새 토큰으로 향하는 선은 그 삭제 뒤에 놓인다. 「하나는 성공하고 나머지가 실패한다」가 아니라 다섯 전부 못 쓰게 되는 쪽이었다.
재시도 설계가 여기서 갈린다
실패가 진 요청에만 온다면 재시도는 400 을 받은 쪽만 다시 보내면 끝난다. 200 을 받은 요청까지 쓸 수 없으므로 그 설계로는 복구되지 않고, 이 사용자는 다시 로그인해야 한다.
그러면 회전 설정을 느슨하게 두는 쪽은 어떤지를 같은 절차로 두 번 더 걸었다. 걸기 전에 세션을 새로 만드는 것이 전제인데, 방금 파괴된 세션으로 재면 설정을 무엇으로 두든 다섯 다 400 이라 비교가 성립하지 않는다.
| 회전 설정 | 성공 | 이긴 토큰 재사용 | 남은 client session |
|---|---|---|---|
| revokeRefreshToken true · maxReuse=0 | 1 / 5 | 400 | 0 |
| revokeRefreshToken false | 5 / 5 | 200 | 1 |
| revokeRefreshToken true · maxReuse=1 | 2 / 5 | 400 | 0 |
회전을 끄면 경쟁 자체가 성립하지 않는다. 같은 refresh token 을 계속 쓸 수 있으니 다섯 다 200 이고 세션도 남는다. 대신 토큰이 유출되면 만료까지 계속 쓸 수 있고, 회전이 좁히려던 것이 바로 그 구간이다.
refreshTokenMaxReuse 를 1 로 올린 쪽은 절충이 되지 못했다. 성공이 1에서 2로 늘었을 뿐 남은 client session 은 0 그대로이고 이긴 토큰도 여전히 400 이다. 동시 요청이 N 개면 refreshTokenMaxReuse 가 N-1 이상이어야 한다는 계산이 여기서 따라 나오는데, 그러려면 몇 개까지 동시에 올지를 먼저 알아야 하고 그 답은 이 실험에 없다. N 을 바꿔 가며 재 보지도 않았으므로 이 계산은 두 구성에서 따라 나온 추론이다.
남는 길은 갱신을 직렬화하는 쪽이고, 그 잠금은 프로세스 밖에 있어야 한다 — 프로세스 안의 synchronized 는 replica 를 넘지 못한다. 후보로 PostgreSQL 행 잠금과 Redis 분산 lock 과 갱신 전용 인스턴스를 적어 두었지만 어느 것을 넣었을 때 이 재현이 사라지는지는 재지 않았다. 이 실험이 닫은 것은 무엇이 부서지는가까지다.
확인하지 않은 것
재시도 설계를 붙여서 다시 재지 않았다. 어떤 재시도가 이 상황을 복구하는지는 확인하지 않았다.
동시 요청 수는 5건 한 가지만 걸었다. 2건이나 20건에서 같은 결과가 나오는지는 세 구성 어디에서도 재지 않았다.
BFF 를 거쳐 같은 경쟁이 나는지도 재지 않았다. Keycloak 쪽 동작만 갈라 보려고 토큰 엔드포인트를 직접 쳤기 때문이다.