Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Claude Code의 상태 표시줄(Status Line)을 단순한 시각적 요소를 넘어 풍부한 데이터 소스로 활용하는 방법을 제안합니다. 비용, 컨텍스트 사용량, 모델 정보 등 상태 표시줄에 포함된 데이터를 스크립트를 통해 추출하여 세션 관리 및 모니터링에 활용할 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이전에는 Claude Code의 상태 표시줄(status line)이 실질적인 가치는 거의 없는 단순한 장식용 요소라고 생각했습니다. 지금도 그렇게 생각하지만, 예전에도 그렇게 생각했었습니다.
하지만 공식적으로는 표시 목적으로 설계되었음에도 불구하고, 상태 표시줄은 실제로 풍부한 데이터 소스입니다. 이 글을 쓰는 시점을 기준으로, 상태 표시줄에는 약 30개의 서로 다른 필드가 있으며 현재 세션에 대한 데이터(비용, 지속 시간, 컨텍스트 사용량 (context usage)), 현재 git 브랜치 또는 워크트리 (worktree), 현재 모델, 추론 노력 (reasoning effort) 등의 정보를 담고 있습니다.
그리고 상태 표시줄 핸들러 (status line handlers)가 공식적으로는 터미널 하단에 렌더링될 텍스트 및 기타 시각적 피드백을 출력하도록 의도되어 있기는 하지만, 그것만이 허용된 유일한 작업이라고 어디에도 명시되어 있지 않습니다. 상태 표시줄 명령은 여러분이 원하는 어떤 Bash 스크립트든 될 수 있습니다.
그러면 다음과 같은 의문이 생깁니다. 이 데이터가 유용하게 쓰일 다른 용도가 있을까요? Claude Code 대화형 세션 (interactive sessions)에서 스크립트를 작성할 때를 생각해 보면, 일반적인 사용 사례는 보통 (a) 훅 (hooks), 그리고 (b) 플러그인 (plugins) (기술 (skills), 명령 (commands), 에이전트 (agents) 등)을 포함합니다. 훅 (hooks)은 이미 자체적인 특수 입력 데이터 채널을 가지고 있으며, 많은 정보가 중복됩니다. 또한 Claude Code의 환경 변수 (environment variables) 역시 이와 동일한 데이터의 일부를 담고 있습니다.
하지만 전부 다 담고 있지는 않습니다.
예를 들어, 특정 시점에 컨텍스트 창 (context window)을 얼마나 소비했는지 어떻게 알 수 있을까요? 현재 세션에서 돈을 얼마나 썼는지 어떻게 알 수 있을까요? JSONL 세션 로그에는 읽은 토큰 (tokens read), 캐시된 토큰 (tokens cached), 출력 토큰 (output tokens), USD 기준 비용 (cost in USD)에 대한 정보가 포함되어 있지만, 이는 일반적으로 이전 턴 (turn)에 관한 것입니다. JSONL 기록에는 전체 세션에 걸쳐 지출한 금액의 누적 합계가 포함되어 있지 않습니다. 해당 정보를 원한다면 직접 추적해야 합니다. 그리고 이는 매우 빠르게, 상당히 어려워질 수 있습니다.
**컨텍스트 윈도우 (context window)**의 경우도 마찬가지입니다. 네, 훅 (hooks)을 사용하여 들어오고 나가는 모든 토큰을 집계하고, 어떤 토큰이 캐시 (cache)에서 오는지 추적할 수 있으며, Claude에게 수학적 계산을 요청하여 세션 전반에 걸쳐 누적되는 이 정보를 추적할 수 있는 공식을 얻을 수도 있습니다. 또한 압축 경계 (compaction boundaries)를 넘어 이를 추적하기 위한 추가 로직을 작성할 수도 있습니다. 하지만 그 정보를 그냥 직접 조회할 수 있다면 얼마나 좋을까요?
문제는 상태 표시줄 (status line)이 Claude Code의 나머지 배관 (plumbing) 구조로부터 상대적으로 격리되어 있다는 점입니다. 비록 어떤 방식으로든 훅 (hooks)과 연결되어 있는 것처럼 분명히 보이지만, (문서화된) "상태 표시줄 훅 (StatusLine hook)"은 존재하지 않습니다. 그리고 묘하게도, 이들은 플러그인 (plugins)과 통합되지 않습니다. 사람들이 여러 가지 우회 방법을 찾아내긴 했지만, 상태 표시줄을 플러그인의 일부로 배포할 수는 없습니다.
따라서 대신 다음과 같은 방법을 사용할 수 있습니다: 상태 표시줄 사이드카 (status line side-car)를 만드는 것입니다.
상태 표시줄 데이터는 표준 입력 (STDIN)을 통해 흐릅니다. 따라서 여러분이 할 수 있는 일은 STDIN에서 데이터를 캡처하여 tee 명령어를 통해 파일로 리다이렉션(redirection)하는 동시에, 이미 구성해 놓은 시각적 상태 표시줄로 데이터를 전달하는 상태 표시줄 스크립트를 만드는 것입니다.
자, 이제 됐습니다. 이제 여러분은 그 격리된 데이터 소스를 워크플로우의 다른 어디에서나 사용할 수 있는 실시간 기록으로 전환했습니다. 훅 (hooks)이 이를 읽을 수 있고, 심지어 Claude조차도 이를 읽을 수 있습니다!
Claude가 언제든 자신의 컨텍스트 윈도우 (context window)가 몇 퍼센트나 사용되었는지 즉시 확인할 수 있는 방법이 있다면 정말 멋지지 않을까요? 불쌍하게도 그는 말 그대로 전혀 알지 못합니다. 그가 이 정보를 가지고 뭔가 멋진 일을 하는 법을 배우게 될지 궁금하군요.
확인해보고 싶으신가요?
저는 정확히 그 역할을 수행하는 플러그인을 만들었습니다. 이름은 Context-Awareness이며, 핵심 아이디어는 다음과 같습니다. 남은 컨텍스트 창 (Context Window)의 크기에 따라 Claude의 행동을 유도할 영리한 방법을 고민하는 대신, 그 정보를 Claude에게 직접 제공하고 무엇을 할지는 Claude 스스로 결정하게 하는 것입니다.
Claude는 LLM (Large Language Model)에 대해 아주 잘 알고 있습니다. 그들은 컨텍스트 부패 (Context Rot)에 대해서도 알고, 압축 (Compaction)에 대해서도 알고 있습니다. 다만 그들은 현재 자신의 컨텍스트 창 상태가 실제로 어떤지에 대해서는 전혀 알지 못할 뿐입니다. 한 Claude는 이를
"명령어": "tee >(jq -r '.context_window.used_percentage' > ~/.claude/ctx-pct) | my-statusline"