계기판이 거짓말을 했다

새벽에 텔레그램 알림 하나를 봤다. 컨텍스트 사용량 96%. 너무 높았다. 체감상 그 정도까지 쓴 세션이 아니었다. 직접 확인해보니 실제는 17%였다. 계기판은 17을 보여줘야 했는데 96을 보여주고 있었다. 어디서 나온 숫자인지 찾는 데 오래 걸리지 않았다. 화면 어딘가에 진짜 96%가 있었다. 다만 그건 컨텍스트가 아니라 주간 사용량이었다.

처음엔 단순한 표시 오류라고 생각했다. 숫자 하나 잘못 긁은 것. 그런데 막상 들여다보니 작은 오류가 아니었다.

계기판은 사람이 행동을 결정하는 장치다. 96%라고 뜨면 나는 세션을 정리하거나, 다음 작업을 줄이거나, 지금 하던 일을 멈추는 판단을 한다. 17%라고 뜨면 계속 가도 된다. 숫자 하나가 작업 흐름을 바꾼다.

그 숫자가 틀렸다면, 문제는 예쁘게 표시했느냐가 아니다. 시스템이 나를 잘못된 방향으로 움직이게 만든 것이다.

숫자는 있었지만 의미가 틀렸다

문제의 코드는 아주 단순했다. 화면에서 퍼센트처럼 생긴 것을 찾는다. 그중 마지막 것을 가져온다. 그리고 그걸 컨텍스트 사용량이라고 표시한다.

처음엔 그럴듯해 보인다. 화면 아래쪽에 상태줄이 있고, 거기에 숫자가 있으니까. 마지막 퍼센트가 가장 최신 정보일 거라고 가정한 것이다.

하지만 화면에는 퍼센트가 하나만 있지 않았다. 컨텍스트 사용량도 있고, 주간 사용량도 있고, 5시간 제한 같은 다른 퍼센트도 있었다. 그중 마지막에 나온 숫자가 우연히 주간 사용량 96%였다. 코드는 그 숫자의 뜻을 몰랐다. 그냥 마지막이라는 이유로 가져왔다.

이게 위험한 이유는 숫자가 완전히 엉뚱한 쓰레기값이 아니었다는 점이다. 96%라는 숫자는 실제로 화면에 있었다. 그래서 더 그럴듯했다. 없는 숫자를 지어낸 게 아니라, 다른 의미의 숫자를 가져와서 이름표만 바꿔 붙인 것이다.

이런 오류는 사람을 더 쉽게 속인다. 숫자 자체는 실재하니까. “어디서 나온 거야?” 하고 찾으면 나온다. 다만 그 숫자가 그 항목의 숫자가 아닐 뿐이다.

데이터에서 가장 무서운 거짓말은 완전한 허구가 아니다. 진짜 숫자를 잘못된 칸에 넣는 것이다.

앵커 없는 관측은 추측이다

이번 수정의 핵심은 “퍼센트를 찾는다”가 아니었다. “컨텍스트 토큰 줄에서 퍼센트를 찾는다”였다.

컨텍스트 사용량은 특정 문장 안에 있다. 169.3k/1m tokens (17%) 같은 줄이다. 이 줄은 토큰 사용량을 말한다. 그러니 여기서 괄호 안 숫자를 뽑으면 컨텍스트 퍼센트가 된다.

반대로 주간 96% 같은 줄은 다른 의미다. 같은 퍼센트 기호를 쓰지만 같은 데이터가 아니다. 사람은 문맥을 보고 구분한다. 코드는 문맥을 알려줘야 구분한다. 그냥 %만 찾으라고 하면 코드는 성실하게 아무 퍼센트나 가져온다.

그래서 관측에는 앵커가 필요하다. 숫자 자체가 아니라, 그 숫자가 붙어 있는 문맥. 어느 줄에서 온 값인지, 어떤 라벨 뒤에 붙은 값인지, 어떤 구조 안에 들어 있는 값인지. 그 앵커가 없으면 관측이 아니라 추측이다.

이번 사고의 원인은 모델이 똑똑하지 않아서가 아니었다. 정규식이 멍청해서도 아니었다. 정규식에게 “무엇을 봐야 하는지”를 제대로 말하지 않은 것이다. “퍼센트”가 아니라 “토큰 줄의 퍼센트”라고 말했어야 했다.

한 단어 차이처럼 보이지만 결과는 완전히 다르다.

고쳤더니 이번엔 물음표가 떴다

첫 수정은 토큰 줄에 앵커를 박는 것이었다. 컨텍스트 토큰 줄을 찾고, 거기서 퍼센트를 뽑는다. 주간 사용량이나 다른 퍼센트는 무시한다. 이제 96%를 17%로 착각하는 일은 막혔다.

그런데 다음 문제가 나왔다. 어떤 화면에서는 토큰 줄이 보이지 않았다. Claude Code TUI가 대체화면으로 돌아가면서, tmux가 캡처할 수 있는 25줄 안에 토큰 줄이 없었던 것이다. 이전 방식이라면 그 상황에서도 화면 어딘가의 마지막 퍼센트를 긁어서 값을 만들었을 것이다.

새 방식은 그렇게 하지 않았다. 못 읽으면 ?%라고 표시했다.

처음엔 이것도 고장처럼 보였다. 숫자가 안 나오니까. 사용자 입장에서는 17이든 22든 뭔가 보여주는 쪽이 더 좋아 보인다. ?%는 미완성처럼 보인다.

하지만 실제로는 이게 더 정직했다. 모르는 값을 모른다고 표시한 것이다. 틀린 숫자를 자신 있게 보여주는 것보다 낫다. 96%라고 잘못 말하는 계기판보다, ?%라고 비워두는 계기판이 더 안전하다.

이 차이가 중요하다. 계기판의 임무는 항상 숫자를 채우는 게 아니다. 모를 때 모른다고 말하는 것도 계기판의 임무다.

빈칸도 정보다

자동화 시스템을 만들다 보면 빈칸을 싫어하게 된다. 화면에 빈칸이 있으면 뭔가 빠진 것 같고, 보고서에 unknown이 있으면 완성도가 낮아 보인다. 그래서 어떻게든 값을 채우려 한다.

그 마음이 사고를 만든다.

값을 못 읽었으면 못 읽었다고 표시해야 한다. 데이터가 없으면 빈칸이어야 한다. 확신할 근거가 없으면 숫자를 만들지 말아야 한다. 이건 소극적인 태도가 아니다. 관측 시스템의 기본이다.

틀린 값은 빈칸보다 나쁘다. 빈칸은 사람을 멈추게 한다. “왜 비었지?” 하고 확인하게 만든다. 틀린 값은 사람을 움직이게 한다. “96%구나” 하고 잘못된 판단을 하게 만든다.

그래서 빈칸은 실패가 아니라 안전장치일 때가 있다. 특히 그 숫자가 이후 판단에 쓰이는 값이라면 더 그렇다. 컨텍스트 사용량은 세션 정리, 작업 분할, 보고 타이밍에 영향을 준다. 그런 값은 모르면 모른다고 해야 한다.

모르는 걸 채우는 것보다, 모른다고 말하는 쪽이 더 전문적일 때가 있다.

두 번째 수정은 더 재미없었다

?%가 나온 뒤에 한 번 더 고쳤다. 이번에는 항상 화면 아래쪽에 보이는 statusline의 Context 22% used 같은 줄을 1차 앵커로 삼고, 그게 없을 때 기존 토큰 줄을 fallback으로 보는 구조였다.

말로 쓰면 길지만, 핵심은 단순하다.

컨텍스트 숫자가 어디에 안정적으로 뜨는지 다시 확인했다. 그 줄에 앵커를 박았다. 다른 퍼센트는 여전히 무시했다. 못 읽으면 아무거나 대신 넣지 않았다.

이런 수정은 화려하지 않다. 새 기능도 아니고, 성능 개선도 아니다. 그냥 숫자를 제자리에서 읽게 만드는 일이다. 그런데 운영에서는 이런 일이 중요하다. 계기판이 맞아야 사람이 맞게 움직인다.

좋은 자동화는 일을 대신하는 것만이 아니다. 지금 상태를 정확히 보여주는 것도 자동화의 일이다. 상태를 잘못 보여주면, 자동화가 일을 덜어주는 게 아니라 판단을 흐린다.

배운 것

퍼센트 기호가 같다고 같은 값이 아니다. 컨텍스트 17%와 주간 사용량 96%는 완전히 다른 숫자다. 관측은 숫자를 찾는 일이 아니라, 숫자가 붙은 문맥을 찾는 일이다.

계기판은 항상 뭔가를 보여줘야 한다는 압박을 받는다. 하지만 모르는 값을 틀리게 채우는 것보다, 모른다고 비워두는 게 낫다. ?%는 고장이 아니라 정직한 상태일 수 있다.

그리고 자동화에서 앵커는 사소한 구현 디테일이 아니다. 어디를 보고 있는지 정하지 않으면, 시스템은 가장 그럴듯한 다른 숫자를 가져와 자신 있게 말한다. 그때부터 계기판은 도구가 아니라 함정이 된다.

틀린 값을 자신 있게 말하는 계기판보다, 모른다고 비워두는 계기판이 낫다.

— 강대종 / @ssamssae