Claude Code의 상태 표시줄에 무엇을 보여줄까: 워크스타일에 맞춰 터미널에서 떠나지 않게 하는 방법

이 글의 요점: Claude Code의 상태 표시줄(화면 하단의 커스텀 정보 바)은 ~/.claude/settings.json에 statusLine을 한 블록 추가하는 것만으로 활성화할 수 있으며, stdin으로 전달되는 JSON을 가공하여 원하는 문자열을 출력할 수 있다. 나는 표준적인 모델명・컨텍스트 사용률 외에도 GTD의 할 일 개수(GitHub Issue를 5분 캐시로 집계)・재생 중인 음악・선언된 작업 태스크 세 가지를 추가하여 항상 4줄로 표시하고 있다 (2026-06-28 시점・실기 스크립트 118행). 본 기사에서는 공식 설정 방법, 일반적인 표시 항목 카탈로그, 나의 구성과 선택 이유, 그리고 '추가해도 방해가 되지 않는' 줄 단위 소멸 설계에 대해 다룬다.

상태 표시줄은 Claude Code 화면 최하단(내장 푸터 바로 위)에 표시되는 커스텀 정보 바이다. 공식 문서 설명에 따르면, Claude Code가 실행하는 쉘 스크립트에 JSON의 세션 정보를 stdin으로 전달하고, 스크립트가 표준 출력에 작성한 문자열을 그대로 그리는 메커니즘이다.

즉, '쉘에서 echo 할 수 있는 정보라면 무엇이든 출력할 수 있다'. 모델명이나 컨텍스트 사용률과 같은 Claude Code 내부 상태뿐만 아니라, Git의 브랜치, 외부 API로 가져온 날씨, 다른 프로세스의 상태까지, 스크립트가 얻을 수 있는 정보는 모두 후보가 된다. 여기가 상태 표시줄이 흥미로운 지점이며, 본 기사의 주제이기도 하다.

설정은 ~/.claude/settings.json에 statusLine 필드를 추가하는 것만으로 충분하다. type을 `

B. 중급 (여러 사례에서 발견됨)

• 5시간 / 7일간의 Rate Limit (속도 제한) 사용률 + 리셋까지 남은 시간
• 세션 경과 시간
• Git의 Staged (스테이지됨) / Unstaged (스테이지되지 않음) / Untracked (추적되지 않음) 파일 수 (S:0 U:1 A:0와 같은 표기)
• 세션 중 추가 / 삭제된 행 수 (+42 -7 형식)
• 오늘의 누적 비용 + Burn Rate (소모율) (🔥 $0.12/hr)
• 입력 / 출력 토큰 수, Cache Hit Rate (캐시 적중률)

비용과 Rate Limit의 시각화는 ccusage (비용 및 Burn Rate 특화 도구)와 같은 라이브러리를 사용하여 구현하는 사례가 많다.

C. 화려하고 독특한 사례

• Reasoning (추론) 강도 인디케이터
• Anthropic Platform의 가동 상태 (status.claude.com 모니터링)
• Vim 모드의 자체 렌더링
• 실행 중인 Sub-agent (하위 에이전트) 이름
• GitHub / GitLab의 PR (Pull Request) 제목과 상태, 미머지(Unmerged) PR 수
• 날씨 · 대기질 (AQI) · 일출/일몰 시각 (외부 API)
• 다른 시간대의 현재 시각, 특정 날짜까지의 카운트다운
• 읽지 않은 메일 수, 다음 캘린더 일정과 남은 시간
• 브랜치 이름을 클릭 가능한 링크로 만들어 터미널에서 GitHub을 직접 열기

C 계층까지 오면 이미 'Claude Code의 상태 표시'라는 틀을 넘어 자신만의 대시보드가 된다. 날씨나 캘린더까지 표시할지는 취향의 문제지만, '셸(Shell)에서 가져올 수 있는 정보라면 무엇이든 놓을 수 있다'는 설계 사상을 잘 보여주는 사례군이다.

여기서부터가 본론이다. 나의 상태 표시줄(Status Line)은 A 계층의 기본 항목에 더해, 자신의 워크스타일에 직결되는 3가지 정보를 추가했다. 실제 기기에서 실행되는 스크립트(118행)가 실제로 출력하는 4줄은 다음과 같다.

Claude Sonnet 4.6 Ctx:[███░░░░░░░] 34% 5h:[██░░░░░░░░] 22% 7d:[█░░░░░░░░░] 8% 00:07
📥 0 🎯 6 ⏳ 6 🌈 89 🔁 6 📁 19 📎 7
🎯 #1544 Vol.5 Zenn 공개
...

위에서부터 순서대로 역할을 설명한다.

• 1행: 모델명 + Context (컨텍스트) / 5시간 / 7일간의 각 바(Bar) + 일본 시간 (HH:MM). 바는 사용률에 따라 색상이 변한다 (후술).
• 2행: GTD의 태스크 건수. 📥 inbox / 🎯 next / ⏳ waiting / 🌈 someday / 🔁 routine / 📁 project / 📎 reference
• 3행: 현재 선언하고 있는 작업 태스크의 ID와 제목
• 4행: Music 앱에서 재생 중인 곡명과 아티스트

A 계층과의 차이점은 2~4행이 모두 'Claude Code의 외부에 있는 나의 상황'이라는 점이다. 태스크 관리 도구의 내용, 음악 플레이어의 상태, 자신이 선언한 작업 대상——이것들을 터미널 하단에 집약했다. 그 이유를 하나씩 적는다.

나는 태스크를 GitHub Issue로 GTD (Getting Things Done) 관리하고 있다. 2행은 그 건수를 gh issue list로 라벨별로 집계하여 출력한다. 목적은 단순하다. Claude Code로 작업하는 동안에도 '지금 Inbox에 몇 건이 쌓여 있는지'가 시야 구석에 남아 있게 하는 것이다. 태스크 상황을 확인하기 위해 굳이 다른 창으로 전환할 필요가 없다.

GTD 메커니즘 자체에 대해서는 'Claude Code GTD 스킬에 Pro 기능을 구현한 이야기'에 자세히 적어 두었다.

다만, 여기에는 한 가지 구현상의 요령이 필요하다. gh issue list는 네트워크를 통해 GitHub API를 호출하기 때문에 매번 실행하면 수백 밀리초가 소요된다. 상태 표시줄은 세션 중에 수없이 재렌더링되므로, 그때마다 API를 호출하면 체감 속도가 무거워진다. 그래서 나는 집계 결과를 5분간 캐시(Cache)한다. 캐시 메커니즘은 다음과 같다.

GTD_CACHE="$HOME/.claude/gtd-counts-cache"
GTD_CACHE_TS="$HOME/.claude/gtd-counts-ts"
GTD_CACHE_TTL=300 # 5분
...

타임스탬프를 별도 파일에 기록해 두고, 마지막 획득으로부터 300초 이내라면 캐시를 그대로 사용한다. 오래되었다면 gh issue list

명령어를 다시 실행하여 캐시를 업데이트한다. 작업 건수는 초 단위의 신선도를 필요로 하지 않으므로, 5분 정도 늦어져도 실질적인 해는 없다. "정확성"보다 "그리기가 멈추지 않는 것"을 우선시한 판단이다.

외부 명령어(External Command)나 API를 호출하는 항목을 상태 표시줄(Status Line)에 추가한다면, 이 캐시 개념을 응용할 수 있다. 날씨든 캘린더든, 업데이트 빈도의 허용 범위를 결정하고 TTL (Time To Live, 생존 기간)을 설정하면, 무거운 취득 프로세스를 매번 그릴 때마다 실행하지 않도록 분리할 수 있다.

3행은 현재 자신이 선언하고 있는 작업 태스크(Task)다. 나는 /current-task #1544 Vol.5 Zenn 공개와 같이 작업 대상을 선언하는 스킬(Skill)을 사용하고 있으며, 그 내용을 ~/.claude-state/current-task라는 파일 하나에 써 내려가고 있다. 상태 표시줄 측은 그것을 읽기만 하면 된다.

CURRENT_TASK_FILE="$HOME/.claude-state/current-task"
if [ -f "$CURRENT_TASK_FILE" ]; then
current_task=$(cat "$CURRENT_TASK_FILE" 2>/dev/null)
...

보충:

/current-task는 내가 개인적으로 구성한 스킬이며, Claude Code의 표준 기능은 아니다. 재현하고 싶다면 작업 대상을 파일 하나(예: ~/.claude-state/current-task)에 써 내려가는 방식이라면 무엇이든 좋다. echo "#1544 Vol.5 Zenn 공개" > ~/.claude-state/current-task와 같이 수동으로 업데이트하는 것만으로도 동일한 표시가 된다.

이것을 추가한 뒤로 작업의 탈선이 줄었다. 지금 해야 할 일이 화면 하단에 고정되어 표시되어 있으면, 다른 신경 쓰이는 Issue를 건드리려 할 때 "아니, 지금은 #1544다"라며 다시 끌어올려진다. 태스크 선언을 "자신과의 약속"으로서 가시화하는 효과가 있다.

4행은 Music 앱에서 재생 중인 곡이다. pgrep으로 Music 프로세스의 존재를 확인하고, 실행 중이라면 AppleScript (osascript)로 재생 상태와 곡명·아티스트를 질의한다.

if pgrep -xq "Music"; then
music_info=$(osascript -e '
tell application "Music"
...

이것은 실용이라기보다 기록을 위한 표시다. 작업 중에 듣고 있는 곡이 보이면, 나중에 "그 기사는 어떤 음악을 들으며 썼는가"를 떠올릴 수 있다. 실익은 적지만, 터미널에 자신의 작업 감각이 남아 있는 점이 마음에 든다.

참고로, 이 블록은 macOS의 Music 앱과 AppleScript에 의존한다. 다른 OS나 다른 플레이어에서 재생 중인 곡을 표시하고 싶다면, playerctl (Linux의 MPRIS 경유) 등 환경에 맞는 취득 수단으로 교체해야 한다. AppleScript로 Music 앱을 조작하는 메커니즘에 대해서는 「Claude Code에서 Mac의 Music.app을 AppleScript로 조작하는 /dj 스킬을 직접 만들었다」에서도 다루고 있다.

지금까지 "추가했다, 추가했다"라고 써왔지만, 표시 항목을 늘리면 당연히 라인은 세로로 길어진다. 나의 경우, current-task와 Now Playing을 추가한 결과 상한선이 4행이 되었다.

그럼에도 "많다"라고 느껴지지는 않았다. 이유는 4행이 항상 4행인 것은 아니기 때문이다. 나의 스크립트는 각 행을 "내용이 있을 때만 출력한다"는 설계로 되어 있다. 출력 부분을 추출하면 다음과 같다.

# 1행目 (모델 + 바 + 시각)은 항상 출력
printf "%s Ctx:%s 5h:%s 7d:%s %s" "$model" "$ctx_bar" "$rate_bar" "$rate_7d_bar" "$jst_time"
# 2행目 이후는 내용이 있을 때만 줄바꿈하여 추가
...

태스크를 선언하지 않았다면 3행은 나오지 않는다. 음악을 멈추면 4행은 사라진다. 즉, 아무것도 선언하지 않고 음악도 멈춰 있을 때는 2행으로 돌아간다. 정보는 "항상 4행을 점유하는" 것이 아니라, "상황에 따라 나타나거나 사라지는" 것이다.

이 발상의 전환이 항목을 늘릴 때의 핵심이라고 생각한다. "정보를 채워 넣는다"라고 생각하면 행수가 고정적으로 늘어나 화면을 압박한다. 하지만 "상황에 따라 나온다 / 사라진다"라고 생각하면, 관련 없는 정보는 자동으로 물러나기 때문에 늘려도 평소의 모습이 무거워지지 않는다.

이를 응용하면, 예를 들어 "Git 브랜치 이름은 메인 브랜치일 때만 경고 색상으로 표시하고, 작업 브랜치에서는 표시하지 않는다", "컨텍스트 (Context) 사용률이 80%를 넘었을 때만 빨간색 띠로 크게 표시한다"와 같은 조건부 표시 라인을 구성할 수 있다. 항상 모든 것을 보여주는 것이 아니라, "지금 이 정보가 필요한 상황인가"를 스크립트 측에서 판정하여 나누어 보여주는 것이다. 이것이 항목을 늘려도 방해가 되지 않는 상태 표시줄 (Status Line)을 만드는 방법이다.

같은 방식으로, 첫 번째 줄의 각 바 (Bar)는 사용률에 따라 색상을 변경하고 있다. 내 스크립트의 임계값 (Threshold)은 60% 미만이 초록색, 60~79%가 노란색, 80% 이상이 빨간색이다.

if [ "$pct_int" -le 59 ]; then
color="\033[32m" # 초록
elif [ "$pct_int" -le 79 ]; then
...

색상은 ANSI 이스케이프 코드 (ANSI escape code)로 지정한다 (\033[32m이 초록, \033[33m이 노란색, \033[31m이 빨간색, \033[0m으로 리셋). 컨텍스트가 빨간색으로 변하기 시작하면 '슬슬 구분을 짓거나 컴팩션 (Compaction)을 의식해야겠다'는 식으로, 숫자를 읽지 않아도 색상만으로 상황을 파악할 수 있다. 임계값은 취향에 따라 정하면 되며, 공식 문서의 예시는 "70% 미만이 초록, 70~89%가 노란색, 90% 이상이 빨간색"을 채택하고 있다. 자신의 작업 리듬에 맞춰 조정하면 된다.

내 구성을 그대로 만들고 싶다면, 아래 프롬프트를 Claude Code에 전달하면 스크립트 전체를 출력해 준다. {리포지토리 이름} 부분만 수정하면 된다.

다음 요구사항으로 Claude Code의 statusLine용 bash 스크립트를 작성해 주세요.
설정 방법:
~/.claude/settings.json의 statusLine.command에서 호출한다고 가정.
...

자신의 사용 방식에 맞춰 요구사항을 바꾸면 커스텀 구성의 스크립트를 만들어 준다. "GTD는 사용하지 않으므로 두 번째 줄은 필요 없음", "비용을 표시하고 싶음", "Spotify를 사용 중 (Linux)" 등의 조건을 추가해 보길 권한다.

상태 표시줄은 ~/.claude/settings.json에 statusLine 블록을 하나 추가하는 것만으로 시작할 수 있다. stdin으로 전달되는 JSON을 가공하여 표준 출력 (Standard Output)에 쓰면, Claude Code 내부 상태뿐만 아니라 Git, 외부 API, 다른 앱의 상태 등 셸 (Shell)에서 가져올 수 있는 정보라면 무엇이든 배치할 수 있다.

나는 그곳에 GTD의 태스크 개수 (5분 캐시), 선언 중인 작업 태스크, 재생 중인 음악 등 나의 워크스타일에 직결되는 정보를 추가했다. 결과적으로 태스크 상황을 확인하기 위해서도, 지금 해야 할 일을 기억하기 위해서도 터미널을 떠날 필요가 없게 되었다.

그리고 항목을 늘릴 때의 핵심은, 행마다 "내용이 있을 때만 표시한다"는 설계로 만드는 것이다. 상황에 따라 나타났다 사라지는 라인은 항목을 늘려도 평소의 모습이 무거워지지 않는다. 우선은 기본 모델명과 컨텍스트 바부터 시작해서, 자신이 "터미널에 있으면서 보고 싶은 정보"를 하나씩 추가해 나가는 것을 추천한다.

• 공식 문서 "Customize your status line": https://code.claude.com/docs/en/statusline

• ccusage (비용·번 레이트 특화): https://ccusage.com/guide/statusline

• ccstatusline (다기능 라이브러리): https://github.com/sirmalloc/ccstatusline

• Zenn Book Vol.4 「코드를 쓰지 못하는 내가 Claude Code에 「메커니즘」을 전달하기까지」 — CLAUDE.md, 서브 에이전트 (Sub-agent), 스킬 (Skill), Playbook 등 Claude Code의 설정 레이어를 체계적으로 다룬 책

• Claude Code GTD 스킬에 Pro 기능을 구현한 이야기 — 본 기사의 GTD 카운트 표시의 전제가 되는 스킬에 대한 해설

• Claude Code에서 Mac의 Music.app을 AppleScript로 조작하는 /dj 스킬을 직접 만든 이야기 — Now Playing 표시에서 사용 중인 AppleScript 연동의 상세 내용

이 기사는 はてなブログ (Hatena Blog)로부터의 크로스 포스트입니다.