QuotaBeacon

새로고침 버튼이 있는데 갱신을 알기 어려웠습니다

QuotaBeacon을 만들면서 각 AI 서비스의 사용량을 메뉴 막대에 모았습니다. 하지만 숫자를 한곳에 보여주는 것과 사용자가 요청한 새로고침을 제대로 설명하는 것은 다른 작업이었습니다. 8월 28일에 다듬은 부분은 바로 이 버튼의 의미였습니다.

당시에는 세 가지 조건이 겹쳤습니다. 일부 서비스는 성공한 값을 캐시에서 다시 가져왔고, macOS의 ‘동작 줄이기’가 켜져 있으면 회전 표시가 사라졌습니다. 마지막 갱신 시각도 분까지만 표시돼 같은 분 안에서 요청하면 차이를 읽기 어려웠습니다. 버튼을 눌렀다는 사실, 새 요청이 나갔다는 사실, 화면에 새 값이 보인다는 사실을 따로 살펴야 했습니다.

저는 이 문제를 회전 효과 하나로 해결하지 않았습니다. 수집 요청의 성격과 캐시 정책을 먼저 나누고, 그 뒤에 진행 표시를 맞췄습니다. 사용량 모니터는 눈에 보이는 퍼센트가 같더라도 언제 어떤 방식으로 얻은 값인지 알아야 다음 판단에 쓸 수 있기 때문입니다.

자동 수집과 직접 요청을 다른 의도로 전달했습니다

자동으로 주기적인 값을 확인할 때는 불필요한 호출을 줄여야 합니다. 반면 사용자가 직접 새로고침을 눌렀다면 조금 전의 성공 캐시를 그대로 보여주는 것만으로는 그 요청을 설명하기 어렵습니다. 저는 수집 경로에 scheduled와 userInitiated라는 의도를 넣었습니다.

이 구분은 버튼에서 끝나지 않습니다. 화면이 모델에 요청하고, 모델이 수집 조정자를 거쳐 각 서비스에 전달할 때까지 유지하도록 했습니다. 메뉴 막대, 대시보드, 설정의 ‘지금 새로고침’, 우클릭 메뉴도 같은 수동 경로를 쓰게 맞췄습니다. 한 버튼만 바꾸면 다른 화면에서는 여전히 자동 수집의 정책으로 처리될 수 있습니다.

Claude·Gemini·Z.ai에서는 사용자 요청일 때 성공 캐시의 최소 간격을 건너뛰도록 했습니다. 자동 수집은 기존 간격을 유지합니다. 같은 서비스를 조회해도 무엇이 요청을 시작했는지에 따라 캐시 사용이 달라지는 구조입니다. 여기서 새 값이라는 뜻은 퍼센트가 반드시 바뀐다는 뜻이 아니라, 최신 관측을 다시 요청했다는 뜻입니다.

수동 버튼도 서버의 대기 시간은 지켜야 합니다

캐시를 건너뛰는 규칙과 서버가 더 기다리라고 한 규칙을 합치지 않았습니다. Claude가 429와 Retry-After로 재시도 시점을 알려준 경우에는 사용자가 눌러도 그 대기 조건을 유지합니다. 수동 새로고침이 모든 제한을 무시하는 버튼이 되면 짧은 시간에 같은 요청을 반복하게 됩니다.

이 선택에서 성공 캐시는 앱이 이전 결과를 재사용하는 정책이고, 서버 대기는 응답을 받은 뒤 지켜야 할 조건입니다. 둘 다 ‘지금 요청하지 않는다’는 결과를 만들 수 있지만 원인이 다릅니다. 그래서 연결 상태와 실패 유형도 사용량 숫자와 별도로 다뤘습니다.

사용량을 얻지 못한 상황을 잔여량 0으로 바꾸지 않는 것도 같은 판단입니다. 값이 없다는 사실과 한도를 다 썼다는 사실을 구분해야 합니다. 서비스별 한도 창과 관측 시각, 데이터 출처를 함께 두는 이유는 퍼센트 하나가 모든 상태를 대신할 수 없기 때문입니다.

자동 수집 중 들어온 클릭을 버리지 않았습니다

다른 경계는 자동 수집이 이미 진행 중일 때였습니다. 중복 호출을 막기 위해 진행 중인 작업을 기다리는 구조만 두면, 그 사이 들어온 사용자 요청도 자동 수집 결과로 끝날 수 있습니다. 사용자는 새로 읽기를 요청했는데 앱 내부에서는 이전에 시작한 일에 합쳐지는 셈입니다.

저는 진행 중인 자동 수집이 끝난 뒤 사용자 의도의 수집을 이어서 한 번 수행하도록 했습니다. 여러 작업을 동시에 무작정 실행하지 않으면서도 자동 수집과 수동 요청의 차이를 유지하는 방식입니다. 이 조건을 정할 때는 정상 상태에서 버튼을 한 번 누르는 경우보다 요청이 겹치는 순서를 살피는 일이 중요했습니다.

이후 새로고침을 확인할 때는 화면 진입점마다 같은 의도를 보내는지, 성공 캐시 우회 전에 서버의 대기 조건을 확인하는지, 자동 작업 중의 클릭이 후속 요청으로 이어지는지를 따로 점검하도록 남겼습니다. 요청을 받아들이는 것과 실제 조회를 시작하는 사이의 흐름을 확인하는 기준입니다.

움직임을 줄여도 상태는 남겨야 했습니다

‘동작 줄이기’에서는 회전 대신 정적인 모래시계와 ‘데이터 갱신 중’ 문구를 표시하도록 바꿨습니다. 일반 모드에서는 완료될 때까지 회전하되, 빠르게 끝나는 요청도 450ms의 최소 피드백 시간을 두었습니다. 결과가 너무 빨리 오면 사용자가 시작 여부를 읽을 틈이 없기 때문입니다.

완료 시각에는 초를 표시했습니다. 같은 분 안에서 다시 조회해도 관측 시점이 달라졌는지 확인할 수 있습니다. 물론 완료 시각만으로 각 서비스가 모두 성공했다는 뜻은 아닙니다. 전체 수집의 진행 표시를 읽은 뒤 서비스별 상태와 출처를 확인하는 순서가 필요합니다.

이 작업에서 배운 점은 접근성 설정을 켠 상태에서도 동작의 의미가 이어져야 한다는 것입니다. 애니메이션을 없애는 순간 진행 정보까지 사라지면 사용자는 버튼과 결과 사이를 연결하기 어렵습니다. 표현 방식은 바꾸되 시작·진행·완료 정보는 유지하는 쪽으로 정리했습니다.

숫자보다 요청의 의미를 먼저 정리합니다

여러 AI를 함께 쓰는 앱에서 모든 사용량을 한 숫자로 합치는 일은 피했습니다. 서비스마다 한도 창과 리셋 기준이 다르기 때문입니다. QuotaBeacon은 서비스별 정보를 나눠 보여주고, 메뉴 막대에서 필요한 항목으로 들어가 확인하도록 만들었습니다.

같은 관측 앱을 만들 때는 자동 조회와 직접 요청에 같은 정책을 써도 되는지부터 보려고 합니다. 오래된 값과 조회 실패가 구분되는지, 움직임을 줄여도 요청 상태를 알 수 있는지도 확인합니다. 이 조건을 정한 뒤 아이콘이나 퍼센트 표시를 다듬으려 합니다.

QuotaBeacon의 새로고침 개선은 새 숫자를 더하는 작업이 아니었습니다. 값을 다시 얻으려는 의도를 끝까지 전달하고, 기다려야 할 조건을 지키며, 사용자가 그 과정을 읽도록 바꾼 작업입니다. 메뉴 막대처럼 작은 화면일수록 이 구분을 생략하지 않는 것이 제가 남긴 기준입니다.