계정을 바꿨는데 이전 한도가 보였다: PokeTokenBar 캐시 수정
AI 코딩 도구의 한도 조회를 메뉴바 앱에 연결한 뒤, 계정 전환에도 이전 계정의 캐시가 선택되는 반례를 수정했습니다. 캐시의 유효기간과 자격 증명 출처를 따로 확인해 공개 버전에 반영했습니다.
코딩 도구의 계정을 바꿨는데 메뉴바에는 이전 계정의 사용 한도가 남을 수 있었습니다. 요청 오류는 없고 숫자도 정상처럼 보여 알아차리기 어려운 문제였습니다.
PokeTokenBar는 AI 코딩 도구의 사용량을 보여주는 macOS 메뉴바 앱입니다. 저는 Antigravity의 한도 조회를 기존 갱신·화면 흐름에 연결했고, 이어서 토큰 캐시의 계정 전환 반례를 수정했습니다. Swift 구현에는 AI의 도움을 받았으며, 유지보수자 리뷰에 따라 조건과 테스트를 바꿨습니다.
핵심 질문은 아직 유효한 캐시라도 지금 읽으려는 자격 증명에서 나온 값인가였습니다. 만료 시간만 확인하면 계정이 바뀌어도 이전 한도를 재사용할 수 있었습니다.
기능을 연결한 뒤 캐시 반례가 드러났다
로컬 사용 기록만으로 계정의 남은 한도와 초기화 시각을 알 수 없어 새 도구의 API 응답을 앱의 공통 갱신 상태와 메뉴 화면에 연결했습니다. 자동 갱신에서는 기존 인증 정책을 유지하면서 파일의 토큰을 사용할 수 있게 했습니다. 수동 갱신의 인증 경로까지 없앤 것은 아닙니다.
유효기간만으로는 캐시를 고를 수 없었다
외부 도구의 토큰 파일은 형식이 여러 가지이고, 같은 파일 경로라도 계정을 바꾸면 내용이 달라집니다. 파일을 메모리 캐시보다 먼저 확인하는 순서를 유지했습니다.
문제는 파일을 읽은 뒤 어느 토큰을 쓸지였습니다. 유효한 캐시를 무조건 반환하면 파일에 반영된 계정 전환을 놓칩니다. 반대로 파일에 만료된 access token이 남아 있어도 같은 계정에서 갱신한 캐시는 살려야 했습니다.
처음에는 만료된 파일보다 유효한 캐시를 우선했습니다. 같은 계정에서는 맞는 동작이지만 유효기간과 출처는 다른 조건이라는 점을 놓쳤습니다.
리뷰에서 계정 전환의 반례가 나왔다
유지보수자가 이 선택의 반례를 제시했습니다.
A 계정으로 조회해 유효한 캐시를 만든다
→ 파일을 만료 임박한 B 계정의 토큰으로 바꾼다
→ 다시 조회한다
→ 유효한 A의 캐시가 반환된다
캐시가 오래돼서가 아니라 출처가 다른 캐시를 유효하다는 이유로 고른 문제였습니다.
갱신된 캐시를 유지할 때 현재 파일의 인증 정보에서 나온 값인지 확인하도록 바꿨습니다. access token이 같거나 비어 있지 않은 refresh token이 같을 때만 같은 출처로 취급했습니다. 갱신 과정에서 access token은 달라질 수 있기 때문입니다.
의미를 줄여 쓰면 다음과 같습니다. 실제 코드의 토큰 값 대신 조건만 남겼습니다.
if cacheIsValid && fileTokenIsExpired && sameCredentialSource {
return cachedToken
}
return try await resolveTokenFromFile()
이는 토큰 값에 근거한 출처 비교이지 계정 ID 검증이 아닙니다. 확인 범위는 유지보수자가 제시한 이전 계정 캐시 재사용 반례입니다.
두 방향의 실패를 같은 테스트 경계에 두기
파일 형식 테스트만으로는 이 문제를 잡을 수 없었습니다. 같은 경로의 파일을 다시 읽는 사이에 계정이 바뀌는 순서가 필요했습니다.
테스트에서는 A의 캐시를 만든 뒤 파일을 B의 토큰으로 바꿔 A 캐시가 반환되지 않는지 확인했습니다. 반대 방향으로는 mock HTTP 응답으로 같은 출처의 토큰을 갱신한 뒤 그 캐시가 후속 조회에도 유지되는지 검사했습니다.
출처가 바뀌면 이전 캐시를 버리고, 같은 출처에서 갱신하면 새 캐시를 살리는 것이 두 테스트의 공통 계약입니다.
리뷰 중에는 자동 갱신에서 인증창을 피하는 것과 모든 경로에서 사용자 개입이 사라지는 것도 구별했습니다.
공개 버전으로 전달하고 남은 기준
한도 기능 #210과 캐시 보완 #274는 병합돼 각각 공개 버전 v2.5.2와 v2.5.4에 포함됐습니다. 확인 가능한 결과는 공개 버전 반영과 두 방향의 회귀 테스트입니다. 실제 사용자의 계정 전환 오류 발생률은 측정하지 않았습니다.
유지보수자의 반례를 받아 조건과 테스트를 바꾼 것이 이 기여의 핵심입니다. 이 판단은 Swift 메뉴바 앱에서 나왔지만, 화면에 표시하는 외부 데이터가 현재 사용자의 것인지 확인한다는 프론트엔드의 캐시 문제와도 같습니다. 캐시는 아직 쓸 수 있는지만으로 재사용할 수 없습니다.