30년 버틴 init, 5년 만에 갈아치워진 표준​

리눅스에서 PID 1로 부팅 직후 가장 먼저 실행되는 프로세스가 init이에요. 이 자리는 SysVinit이 30년 가까이 지켰지만 2010년대 초반부터 갑자기 풍경이 바뀌었어요. 2011년 Fedora 15에서 등장한 systemd가 5년 만에 거의 모든 메이저 배포판의 기본 init을 차지했고, 그 사이에는 Upstart가 잠깐 등장했다 사라졌죠.

이 글은 세 init 시스템을 기능 비교 대신 연표로 다룹니다.

• 어떤 배포판이 언제 SysVinit을 버렸는가
• Upstart는 왜 짧게 살았는가
• systemd 채택을 둘러싼 Debian 투표, Devuan 분기, Ubuntu의 입장 변화는 어떻게 흘러갔는가
• 지금도 systemd를 쓰지 않는 배포판은 어디인가

서버에 SSH로 들어가서 ps -p 1 -o comm=을 한 번 실행했을 때, 출력 한 줄이 어떤 역사 위에 서 있는지 정리해 보겠습니다.

세 세대, 한눈에​

세 시스템의 본질적 차이는 한 줄로 줄일 수 있습니다. SysVinit은 셸 스크립트를 순서대로 돌리고, Upstart는 이벤트가 발생하면 잡(job)을 돌리며, systemd는 의존성 그래프를 따라 유닛(unit)을 병렬로 돌린 뒤로도 계속 지켜봅니다.

1세대: SysVinit (1983~)​

뿌리는 AT&T가 1983년에 낸 Unix System V입니다. 리눅스에는 1990년대 초 Miquel van Smoorenburg(미컬 반 스모렌부르흐)가 포팅한 sysvinit 패키지로 흘러들어왔고, 그 후 약 20년간 거의 모든 리눅스 배포판의 기본 init이 됐습니다.

핵심 구조는 단순합니다.

/etc/inittab          → 어느 런레벨에 어떤 스크립트를 돌릴지 선언
/etc/init.d/*         → 각 서비스의 start/stop/restart 스크립트
/etc/rc{0..6}.d/      → 런레벨별 심볼릭 링크 (S20foo, K80foo …)

런레벨(runlevel)은 시스템의 모드 번호입니다. 관습적으로 7개를 씁니다.

런레벨 진입 시 /etc/rcN.d/의 S로 시작하는 링크를 번호 순으로 실행하고, 빠져나갈 때 K 링크를 실행합니다. 부팅이란 곧 "셸 스크립트를 정해진 순서대로 한 줄씩 돌리는" 일이었습니다.

SysVinit의 한계​

SysVinit이 30년을 살아남은 건 단순함 덕이고, 5년 만에 밀려난 것도 그 단순함 탓입니다.

가장 큰 문제는 직렬 부팅이었습니다. S20foo가 끝나야 S21bar가 시작되니, CPU가 놀고 있어도 두 서비스가 서로 무관해도 순서를 바꿀 수 없었고 이게 부팅이 느린 결정적 이유였습니다. 의존성 표현이 약한 것도 여기 얽힙니다. "DB가 떠 있어야 web이 뜬다" 같은 관계를 번호(S20, S21)로만 나타냈고, LSB 헤더가 의존성 기술을 거들긴 했지만 여전히 선형 정렬이 전제였습니다.

나머지 둘은 프로세스 관리 쪽입니다. 스크립트가 &로 백그라운드에 넘긴 자식을 init이 직접 추적하지 않아 PID 파일이 진실의 원천이 되는데, 이게 어긋나면 service foo status가 거짓말을 하고 자식이 더블 fork로 도망가면 더 곤란해집니다. 서비스가 죽었을 때 되살리는 것도 init 밖의 일이라, respawn을 inittab에 직접 걸거나 monit/supervisord 같은 외부 도구를 끌어와야 했습니다.

이 한계들이 2000년대 후반 "부팅이 빨라야 하는 노트북"과 "의존성 많은 데스크톱 환경"의 시대와 충돌했습니다. 다음 두 세대는 모두 이 중 하나 이상을 풀려고 출발합니다.

2세대: Upstart (2006~)​

Canonical의 Scott James Remnant(스콧 제임스 렘넌트)가 만들었습니다. 첫 출시는 Ubuntu 6.10 "Edgy Eft"(2006-10)입니다. 이때부터 Ubuntu의 기본 init은 SysVinit이 아니라 Upstart였습니다(호환 모드로 SysV 스크립트도 돌렸습니다).

Upstart의 출발점은 "부팅은 단순한 순서가 아니라 일련의 사건들이다"라는 발상입니다. USB가 꽂히고 네트워크가 올라오며 디스크가 마운트되는 등, 이벤트가 발생할 때마다 그에 맞는 잡이 트리거되도록 모델을 짰습니다.

설정은 /etc/init/*.conf에 한 잡씩 둡니다.

description "Hello Web"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5

exec /usr/local/bin/hello-web --port 8080

respawn 한 줄로 자동 재시작이 해결되고, start on filesystem and net-device-up 식으로 이벤트 조합도 가능했습니다. SysVinit에 비하면 진짜 진보였습니다.

채택도 빨랐습니다. Ubuntu 9.10 "Karmic Koala"(2009-10)에서 SysV 호환 레이어 없이 native Upstart 부팅을 기본화했고, RHEL 6(2010-11)이 정식 채택했습니다. Google의 ChromeOS와 일부 Fedora 릴리스도 한때 Upstart를 썼습니다.

Upstart가 짧게 살았던 이유​

그런데 RHEL 6 이후 Upstart의 채택은 거기서 멈춥니다. 2010년대 초반 새로 등장한 systemd로 흐름이 갈아탔고 Ubuntu 본진마저 결국 같은 길을 갔는데, 단순히 "더 좋은 게 나왔다"로는 설명이 부족합니다.

가장 자주 꼽히는 건 Canonical의 CLA 정책입니다. Upstart 코드에 기여하려면 Canonical이 요구하는 Contributor License Agreement에 동의해야 했는데, 받은 코드를 상용으로 재배포할 권리를 회사에 양도하는 형태라 다른 진영이 부담스러워했습니다. 같은 시기 Linux 커널을 비롯한 여러 핵심 프로젝트가 CLA 없이 기여를 받던 흐름과 대조됐습니다.

기술적 한계도 겹쳤습니다. "A 이후 B" 같은 단순 의존이 이벤트 모델로는 어색했던 반면, systemd가 들고 나온 의존성 그래프와 Wants= / Requires= / After= 선언이 더 자연스럽다는 평가가 빠르게 자리 잡았습니다. 자식 프로세스 추적도 Upstart는 SysVinit과 비슷한 한계 안에 머물러, cgroup을 fork-bomb에도 끄떡없는 추적 수단으로 쓴 systemd에 비하면 약했습니다. 여기에 Fedora와 RHEL이 systemd를 적극적으로 밀면서 큰 생태계 플레이어 하나가 Upstart 진영에서 빠져나갔고, RHEL 6의 Upstart는 단명한 뒤 RHEL 7부터 systemd로 갔습니다.

결정타는 Debian과 Ubuntu가 차례로 systemd로 넘어간 시점입니다. 그 부분은 뒤에서 따로 정리합니다.

3세대: systemd (2010~)​

2010년 4월, Red Hat의 Lennart Poettering(레나르트 푀터링)과 Kay Sievers(카이 지버스)가 발표한 글 한 편("Rethinking PID 1")으로 등장합니다. 핵심 아이디어는 세 가지였습니다.

첫째는 의존성 기반 병렬 부팅입니다. 유닛(*.service, *.socket, *.target 등)이 의존성을 명시하고, 의존성이 풀린 것부터 병렬로 출발합니다. 둘째는 소켓 활성화(socket activation)로, 데몬을 미리 띄우는 대신 systemd가 먼저 listen 소켓을 열어두고 첫 연결이 들어올 때 데몬을 깨웁니다. macOS의 launchd에서 영감을 받은 모델입니다. 셋째는 cgroup 기반 프로세스 추적입니다. 서비스가 fork한 자식과 손자까지 cgroup에 묶여 정확히 추적/정리되므로 PID 파일 위조나 더블 fork로 도망갈 수 없습니다.

이 세 가지가 동시에 풀린 게 결정적이었습니다. 이전 세대가 풀지 못한 한계를 한꺼번에 정리했고, 부팅 시간 단축이라는 가시적 효과도 따라왔습니다.

다만 systemd는 init만이 아니라 logind, journald, networkd, resolved, timedated 등 시스템 영역의 여러 컴포넌트를 흡수해 갔고, "Unix 철학과 어긋난다"는 비판도 같은 시기에 나왔습니다. 이 글은 그 논쟁에 한 발 들이지 않고, 채택 흐름만 따라갑니다.

systemd 채택 연표​

발표 시점부터 메이저 배포판들의 채택 시점을 연도순으로 보면 흐름이 분명해집니다.

약 5년(2010 발표~2015) 만에 Fedora, RHEL, Debian, Ubuntu, openSUSE, Arch가 모두 systemd로 정렬됩니다. 이 정도 속도로 init 같은 핵심 컴포넌트가 통일된 적은 리눅스 역사에 거의 없습니다.

Debian의 투표와 Devuan 분기​

Debian은 의사결정에 시간이 오래 걸리는 프로젝트입니다. systemd 채택도 예외가 아니어서 2013년 후반부터 Technical Committee 안에서 격론이 오갔고, 결국 2014년 2월 표결로 Debian 8 "Jessie"의 기본 init은 systemd로 결정됩니다.

표결 자체는 그것대로 정리됐지만, 남아 있던 또 다른 쟁점, 즉 "패키지가 systemd 의존성을 강제로 걸 수 있느냐"가 분기를 불렀습니다. 이 쟁점은 2014년 11월 init system coupling General Resolution으로 넘어갔고, "다른 init 시스템 지원은 권장되지만 의무는 아니다(recommended, but not mandatory)" 같은 선택지가 올라왔지만 결과는 "GR 불필요(General Resolution is not required)"였습니다. 패키지가 systemd 외에 안 돌게 만들어도 막는 규정을 따로 두지 않는다는 의미였습니다.

이 결과에 반발한 일부 Debian 사용자/개발자가 "Veteran Unix Admins" 이름으로 2014년 11월 27일 Devuan 분기를 발표합니다. 약 2년 반의 패키지 감사/수정 끝에 2017년 5월 25일 Devuan 1.0 "Jessie"가 나왔습니다. Debian 8을 베이스로 systemd 훅을 모두 들어내고 SysVinit(또는 OpenRC)을 기본 init으로 하는 버전입니다.

Devuan은 이후로도 Debian을 한 단계씩 따라가며 출시를 이어가고 있습니다. 규모는 작지만 "systemd 없이도 Debian 생태계를 쓰고 싶다"는 수요에 답하는 진영으로 살아남았습니다.

Ubuntu가 자존심을 접은 결정​

Ubuntu에게 init은 단순한 부품이 아니었습니다. Upstart는 Canonical의 자체 프로젝트였고, 거의 10년간 Ubuntu의 기본 init이었습니다. 그런데 Debian이 systemd로 결정한 직후, Mark Shuttleworth(마크 셔틀워스)는 "Ubuntu도 upstream(Debian)과 보조를 맞추겠다"고 발표합니다.

마이그레이션은 비교적 부드러웠습니다. Ubuntu 15.04 "Vivid Vervet"(2015-04-23)에서 기본 init이 systemd로 전환됐고, Ubuntu Touch(모바일)만 예외였습니다. 이후 15.04부터 16.10까지는 부팅 시 GRUB에서 Upstart와 systemd를 고를 수 있는 듀얼 부팅 기간을 유지했는데, 회귀가 생겼을 때 도망갈 길을 일정 기간 열어둔 운영적 선택이었습니다. 16.10 이후 Upstart 옵션이 제거되면서 이때부터 Ubuntu는 완전히 systemd 단독으로 갔습니다.

Canonical 입장에서는 자기 프로젝트를 접고 경쟁 프로젝트를 받아들인 결정이었지만, 그 무렵엔 systemd가 사실상 표준이 된 상태였고 Debian과 다른 init을 유지하는 비용이 더 커졌습니다.

systemd를 안 쓰는 배포판들​

2026년 현재도 systemd가 아닌 init을 기본으로 쓰는 배포판이 남아 있습니다. 컨테이너 베이스 이미지나 임베디드, 보수적 운영을 위한 선택지로 의외로 자주 등장합니다.

여기서 중요한 점이 하나 있습니다. Alpine은 컨테이너 이미지 시장에서 표준급 점유율을 가지고 있습니다. "제 노트북은 Ubuntu고 systemd만 만져봤다"고 해도, 컨테이너에 FROM alpine:... 한 줄을 넣는 순간 OpenRC 기반 시스템과 만납니다. 다만 컨테이너 안에서는 init이 거의 의미를 갖지 않는다는 별도의 이슈가 있는데, 그건 마지막에서 다시 봅니다.

같은 작업, 세 가지 표현​

세 init 시스템의 차이를 가장 빨리 느끼는 방법은 같은 서비스를 세 가지 형식으로 옆에 두고 보는 것입니다. hello-web이라는 가상의 HTTP 서버를 부팅 시 자동 기동하고 죽으면 자동 재시작하도록 등록한다고 해보겠습니다.

SysVinit: /etc/init.d/hello-web​

#!/bin/sh
### BEGIN INIT INFO
# Provides:          hello-web
# Required-Start:    $network $remote_fs
# Required-Stop:     $network $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: hello web server
### END INIT INFO

DAEMON=/usr/local/bin/hello-web
PIDFILE=/var/run/hello-web.pid

case "$1" in
  start)
    start-stop-daemon --start --background \
      --make-pidfile --pidfile $PIDFILE \
      --exec $DAEMON
    ;;
  stop)
    start-stop-daemon --stop --pidfile $PIDFILE
    rm -f $PIDFILE
    ;;
  restart)
    $0 stop; sleep 1; $0 start
    ;;
  status)
    [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE) 2>/dev/null \
      && echo "running" || echo "stopped"
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|status}"; exit 1
    ;;
esac

그 후 update-rc.d hello-web defaults(Debian 계열) 또는 chkconfig hello-web on(RHEL 계열)으로 런레벨 링크를 만들어야 합니다. 자동 재시작은 별도 도구가 필요합니다.

Upstart: /etc/init/hello-web.conf​

description "hello web server"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5

exec /usr/local/bin/hello-web --port 8080

스크립트가 아니라 선언문입니다. start-stop-daemon, PID 파일, status 분기, 런레벨 링크가 전부 사라졌습니다. respawn 한 줄로 자동 재시작도 끝납니다.

systemd: /etc/systemd/system/hello-web.service​

[Unit]
Description=hello web server
After=network.target

[Service]
ExecStart=/usr/local/bin/hello-web --port 8080
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

등록은 systemctl enable --now hello-web 한 줄. 의존성을 After=로 명시하고, 재시작 정책도 Restart=on-failure로 명확합니다. 자식 프로세스 추적은 cgroup이 알아서 해줍니다.

같은 의도가 34줄 스크립트에서 9줄, 11줄 선언으로 줄어듭니다. 줄어든 만큼 init이 책임지는 부분과 사용자가 짜야 하는 부분의 경계가 옮겨갔다는 뜻입니다.

컨테이너 시대의 init: PID 1 문제​

여기까지가 "호스트 OS의 init" 이야기였습니다. 그런데 컨테이너 시대로 들어오면 init의 의미가 한 번 더 뒤집힙니다.

도커 컨테이너 안에서 PID 1은 실제 init 시스템 대신 사용자가 실행한 프로세스입니다. CMD ["node", "server.js"]면 node가 PID 1이 됩니다. 그런데 PID 1에는 두 가지 특별한 책임이 있습니다.

하나는 좀비 자식 프로세스 수확입니다. 자식이 죽으면 부모가 wait()으로 거둬야 좀비가 정리되는데, PID 1이 이걸 안 하면 좀비가 영구히 쌓입니다. 다른 하나는 시그널 처리입니다. 커널은 PID 1에게 기본 시그널 핸들러를 붙여주지 않아서, 명시적으로 처리하지 않으면 SIGTERM이나 SIGINT가 무시됩니다.

대부분의 애플리케이션은 이 두 가지를 신경 쓰고 만들어지지 않았습니다. 그래서 컨테이너 생태계에는 경량 init들이 등장했습니다.

tini는 Docker가 --init 플래그로 채택한 사실상 표준입니다. dumb-init은 Yelp가 만든 대안이고, s6-overlay는 컨테이너 안에서 멀티 프로세스를 다룰 때 씁니다.

Kubernetes는 이 문제를 한 단계 더 위에서 다룹니다. Pod 종료 시 컨테이너 PID 1에 SIGTERM을 보내고 grace period 후 SIGKILL로 가는데, 앱이 SIGTERM을 안 잡으면 매번 강제 종료가 발생합니다. (이 흐름은 SIGINT, SIGTERM, SIGHUP, SIGKILL: 쿠버네티스 시대의 유닉스 시그널에서 깊게 다뤘습니다.)

호스트의 init은 의존성과 부팅 속도를 고민하지만, 컨테이너의 PID 1은 시그널 전파와 좀비 수확이라는 더 원초적인 책임으로 돌아갑니다.

한 줄로​

SysVinit의 30년은 단순함이 호환성을 만든 시대였고, systemd의 5년은 의존성과 cgroup이 표준을 만든 시대였어요. 그 사이의 Upstart는 좋은 아이디어 한 가지로 잠깐 빛났지만 큰 생태계의 흐름을 못 이긴 사례로 남았고, PID 1 자리에 무엇이 앉느냐는 결국 그 시대 운영체제가 무엇을 가장 중요하게 여기는지를 비추는 거울이에요.

→ 다음 편: systemd 유닛이라는 언어: 11종을 한 바퀴. 이 글에서 살짝만 비춘 유닛 11종이 cron, fstab, inetd, autofs, inotify 같은 옛 도구를 어떻게 흡수했는지 한 바퀴 돕니다.

참고​

• Wikipedia의 init 문서
• Wikipedia의 systemd 문서
• Wikipedia의 Upstart (software) 문서
• Wikipedia의 Devuan 문서
• Rethinking PID 1 — Lennart Poettering (2010)
• Fedora Project Wiki의 Features/systemd
• Ubuntu — A Journey from System V to System D — packagecloud
• It's Easy To Switch Between Upstart & Systemd Right Now On Ubuntu 15.04 — Phoronix
• Debian systemd Controversy Results in Fork — InfoQ

터미널에서 긴 프롬프트는 힘들다​

Claude Code를 쓰다 보면 몇 줄 넘는 프롬프트를 치고 싶을 때가 종종 있어요. 들여쓰기가 있거나, 코드를 붙이거나, 한글 IME 상태에서 복잡한 편집이 필요한 순간이에요. 터미널의 한 줄 편집기는 이런 상황에 약해요.

이럴 때는 Claude Code 프롬프트를 외부 에디터로 열어서 씁니다. 방법 자체는 간단한데, 운용하다 보면 사소한 함정이 하나 있어 같이 정리합니다.

$EDITOR와 Ctrl+X Ctrl+E를 쓰는 기본 방법​

Claude Code는 프롬프트 입력 중 Ctrl+X 뒤이어 Ctrl+E를 누르면 $EDITOR 환경변수에 지정된 에디터를 띄웁니다. 내부적으로는 claude-prompt-<uuid>.md 같은 임시 파일을 만들고 그걸 에디터에 넘깁니다. 편집 후 저장하고 닫으면 그 내용이 그대로 프롬프트에 입력됩니다.

가장 단순한 세팅:

# ~/.zshrc
export EDITOR='nvim'

이러면 Ctrl+X Ctrl+E로 nvim이 뜨고, :wq로 닫으면 내용이 Claude Code 프롬프트로 들어옵니다.

참고로 최근 Claude Code 버전은 Ctrl+G도 같은 동작으로 바인딩돼 있습니다. 둘 다 테스트해 보고 손에 맞는 것을 쓰면 됩니다.

전역 EDITOR는 nvim, Claude만 Cursor로​

그런데 EDITOR 환경변수는 git, crontab, less 등 여러 곳에서 참조합니다. 저는 이걸 nvim으로 둔 상태가 편해서 바꾸고 싶지 않아요. Claude Code 프롬프트만 GUI 에디터(Cursor, VSCode)로 띄우고 싶을 때는 함수로 감싸서 EDITOR를 이 프로세스 범위에서만 오버라이드하면 됩니다.

제 ~/.zshrc에 들어 있는 것은 이것입니다.

cc() {
  # VSCode 쓸 때
  # EDITOR="code -w" command claude "$@"

  # Cursor 쓸 때
  EDITOR="/Applications/Cursor.app/Contents/Resources/app/bin/cursor -w" command claude "$@"
}

중요한 점은 두 가지입니다.

• command claude: alias나 동명 함수가 걸려 있어도 실제 claude 바이너리를 실행하도록 우회합니다.
• -w 플래그: Cursor/VSCode는 기본적으로 연 뒤 바로 셸로 제어를 반환합니다. -w(또는 --wait)를 붙여야 에디터 창이 닫힐 때까지 대기합니다. 없으면 Claude Code가 빈 파일을 바로 읽어 갑니다.

이제 터미널에서 cc만 실행하면 Claude Code가 뜨고, 프롬프트 편집 시 Cursor로 열립니다. 다른 툴들은 EDITOR=nvim을 그대로 봅니다.

실제 동작​

1. 프롬프트에서 Ctrl+X Ctrl+E​

2. Cursor에 임시 파일이 열립니다​

파일명은 claude-prompt-<uuid>.md 형식입니다. 마크다운이라 코드 블록이나 리스트도 편하게 씁니다.

3. 저장하고 닫으면 프롬프트로 들어옵니다​

여기서 한 가지 이상한 게 생겼습니다.

![복귀 후 프롬프트에 ^[[O^[I 이상 문자가 끼어든 상태

프롬프트 앞부분의 기존 텍스트와 Cursor에서 쓴 내용 사이에 ^[[O^[[I^[[O^[[I^[[O가 끼어 있습니다. 정체가 무엇일까요?

^[[O, ^[[I의 정체​

이 문자들은 Focus Reporting에서 나옵니다.

터미널에는 포커스 리포팅(Focus Reporting)이라는 기능이 있습니다. ANSI/xterm 스펙의 DEC Private Mode 1004. 이게 켜져 있으면 터미널 창의 포커스가 들어오고 나갈 때 아래 두 이스케이프 시퀀스가 터미널에 주입됩니다.

이걸 왜 쓰느냐면, vim/tmux 같은 TUI 앱이 유휴 상태일 때 렌더링을 멈추거나 커서 스타일을 바꾸기 위해 필요합니다. 터미널이 보내주는 이 이벤트로 현재 창이 활성인지 아닌지를 알 수 있습니다.

문제는 이 지점입니다.

1. Claude Code가 Cursor를 띄웁니다. 이 순간 터미널 포커스가 제 터미널에서 Cursor 윈도우로 이동하고, 터미널이 ^[[O (focus-out)을 내보냅니다.
2. Cursor에서 저장/종료하면 포커스가 다시 터미널로 돌아옵니다. ^[[I (focus-in)이 내보내집니다.
3. 창 전환을 두세 번 하다 보면 여러 번의 in/out이 생깁니다.
4. 이 이스케이프 시퀀스들은 stdin 버퍼에 쌓입니다. Claude Code가 에디터 종료 후 다시 입력 읽기를 시작할 때, 앞서 쌓인 것들을 프롬프트 텍스트로 흡수합니다.

정리하면 Cursor/VSCode 같은 별도 윈도우 GUI 에디터를 띄울 때만 이 현상이 생깁니다. 터미널에서 포커스가 실제로 왔다갔다 하기 때문입니다.

해결 방법​

1순위: nvim / vim / helix / micro​

같은 터미널 세션 안에서 도는 TUI 에디터는 포커스가 창 단위로 움직이지 않습니다. 창은 하나, 안에서 그냥 화면이 바뀔 뿐입니다. focus-in/out 이벤트 자체가 생기지 않습니다.

export EDITOR='nvim'

제 경험상 이게 제일 안정적이에요. nvim이 충분히 좋은 마크다운 편집기이기도 하고요.

2순위: 그래도 Cursor/VSCode를 쓰고 싶다면​

몇 가지 부분 해결책이 있지만 완벽한 건 없습니다.

• 복귀 후 섞인 ^[[ 시퀀스를 backspace로 수동 제거한 뒤 Enter를 누릅니다.
• 터미널 앱 설정에서 focus reporting을 비활성화합니다(Ghostty, iTerm2 등에 옵션이 있습니다). 단 vim/tmux 쪽 기능도 같이 잃습니다.
• Cursor/VSCode를 쓰되 cc 함수 내에서 임시로 focus reporting을 꺼 주는 래퍼를 끼웁니다. 번거로운 방법입니다.

깔끔한 길은 첫 번째예요. 긴 프롬프트 편집에 IDE급 기능이 꼭 필요한 게 아니라면 TUI 에디터 쪽이 나아요.

요약​

• Claude Code 프롬프트는 Ctrl+X Ctrl+E (또는 Ctrl+G)로 $EDITOR를 호출합니다.
• 전역 EDITOR를 건드리지 않고 싶다면 cc() 함수 패턴으로 Claude에 한정해 오버라이드합니다. -w 플래그를 꼭 붙여야 합니다.
• Cursor/VSCode를 쓰면 포커스 리포팅 시퀀스가 프롬프트에 섞이는 부작용이 있습니다.
• 제일 안정적인 조합은 TUI 에디터(nvim 등) + EDITOR=nvim입니다.

참고 링크​

• ClaudeLog — How to Edit Prompts in External Editor
• GitHub anthropics/claude-code #18990 — 외부 에디터 설정 관련 피드백
• Claudefast — Claude Code Keybindings Guide
• xterm Focus Reporting 스펙 — DECSET ?1004h / ?1004l

오래된 주제와 새로운 무대​

유닉스 시그널은 운영체제 수업 첫 단원에서 가볍게 다루고 지나가는 주제예요. 그런데 Docker, Kubernetes, systemd, PM2 같은 프로세스 오케스트레이터들이 일상이 된 지금, 이 네 개의 시그널은 오히려 운영 사고의 주요 원인이 되고 있어요.

• "Docker stop을 했는데 왜 10초 뒤에야 죽나요?"
• "K8s rolling update 중 request가 잘립니다"
• "Ctrl+C가 안 먹히는데 뭐가 잘못됐죠?"
• "nohup으로 돌렸는데 SSH 끊기니까 죽었어요"

전부 시그널 이해와 직결된 질문입니다. 한 번 제대로 정리해두면 두고두고 도움이 됩니다.

네 시그널 개요​

핵심 차이는 마지막 칼럼인 핸들 가능 여부입니다. SIGKILL만 프로세스가 가로챌 수 없습니다. 이것이 왜 중요한지는 뒤에서 자세히 살펴봅니다.

SIGINT​

SIGINT는 우리가 가장 자주 만나는 시그널입니다.

터미널에서 Ctrl+C를 누르면 현재 포그라운드 프로세스 그룹에 SIGINT가 날아갑니다. "사용자 인터럽트"의 약자로 interrupt에서 왔습니다.

프로세스는 이 시그널을 받으면 다음과 같이 동작합니다.

• 기본적으로는 즉시 종료
• 핸들러를 등록하면 정리 후 종료 가능 (열린 파일, DB 트랜잭션 롤백 등)
• 완전히 무시할 수도 있음 (일부 REPL이 이렇게 동작)

Ctrl+C가 안 먹는 경우들​

• 자식 프로세스가 별도 세션으로 분리돼 있을 때 (setsid)
• 프로세스가 I/O 블록 상태(디스크, 네트워크)라 인터럽트 후에도 시스템 콜 복귀가 늦을 때
• 핸들러가 SIGINT를 잡아놓고 일부러 안 끝낼 때
• TUI 앱(vim, tmux 등)이 터미널 raw 모드로 Ctrl+C를 키 입력으로 받아먹을 때

Ctrl+C가 안 먹히면 보통 SIGTERM을 쏴보는 게 다음 수순입니다. kill PID (기본값이 SIGTERM).

SIGTERM​

SIGTERM은 정중한 종료 요청이며, 가장 중요한 시그널이자 현대 운영 환경의 기본 종료 경로입니다.

kill PID를 인자 없이 쓰면 기본이 SIGTERM입니다. docker stop CONTAINER는 컨테이너 PID 1에 SIGTERM을 전송하고, Kubernetes의 Pod 종료가 시작될 때도 각 컨테이너에 SIGTERM을 보냅니다. systemd가 unit을 멈출 때와 PM2, foreman, supervisor 등 프로세스 매니저가 stop할 때도 기본 시그널은 SIGTERM입니다.

SIGTERM은 "그만 종료해 주세요" 라는 의사 표현입니다. 프로세스가 이 시그널을 캐치할 수 있고, 원하는 시간 동안 정리할 수 있습니다.

Graceful shutdown 패턴 (Go 예제)​

프로덕션 서버가 SIGTERM을 받았을 때 해야 할 일은 대체로 다음과 같습니다.

1. 신규 요청 수신을 중단
2. 진행 중인 요청을 완료할 때까지 기다림
3. DB 커넥션, 파일, 임시 자원 정리
4. 종료

Go 1.16+에서 signal.NotifyContext를 쓰면 깔끔합니다.

package main

import (
    "context"
    "log"
    "net/http"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    ctx, stop := signal.NotifyContext(context.Background(),
        syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    srv := &http.Server{Addr: ":8080"}

    go func() {
        if err := srv.ListenAndServe(); err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()

    <-ctx.Done() // SIGINT/SIGTERM 대기

    shutdownCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
    defer cancel()

    if err := srv.Shutdown(shutdownCtx); err != nil {
        log.Printf("shutdown error: %v", err)
    }
    log.Println("bye")
}

25초 타임아웃은 K8s 기본 grace period(30초)보다 살짝 짧게 잡는 것이 관행입니다. grace period 안에 정리를 끝내고 자진 종료하기 위해서입니다.

Node.js 예제​

const server = app.listen(3000)

const shutdown = (signal) => async () => {
  console.log(`${signal} 수신, 정리 중...`)
  server.close(() => process.exit(0))
  // 25초 지나도 종료 안 되면 강제
  setTimeout(() => process.exit(1), 25_000).unref()
}

process.on('SIGTERM', shutdown('SIGTERM'))
process.on('SIGINT',  shutdown('SIGINT'))

Python 예제​

import signal, sys, time

def shutdown(signum, frame):
    print(f"signal {signum} 수신, 정리 중...")
    # cleanup code here
    sys.exit(0)

signal.signal(signal.SIGTERM, shutdown)
signal.signal(signal.SIGINT,  shutdown)

while True:
    time.sleep(1)

SIGKILL​

SIGKILL을 아껴 써야 하는 이유가 있습니다. kill -9 PID는 개발자들의 오랜 습관입니다 — 하지만 프로세스에게 정리할 기회를 주지 않습니다.

• 커널이 프로세스를 즉시 종료
• 프로세스는 시그널을 캐치하거나 무시하거나 핸들러를 등록할 수 없다 (불가능)
• lock 파일이나 임시 파일 같은 애플리케이션 수준 정리가 누락되고, 상대편 DB는 연결 끊김을 늦게 감지할 수 있음
• 쓰기 중이던 데이터가 flush 안 된 상태로 증발

쓸 만한 때​

• SIGTERM을 보냈는데 충분히 기다린 뒤에도 안 죽음 (핸들러 무한 루프 등)
• Docker grace period 초과 → Docker가 자동으로 SIGKILL 전송
• K8s grace period 초과 → kubelet이 SIGKILL
• OOM killer가 메모리 확보 위해 희생자로 선정

즉 순서는 항상 SIGTERM → 대기 → (안 되면) SIGKILL입니다. 처음부터 kill -9로 가는 것은 게으름이거나 데이터 손상 리스크를 감수하는 행위입니다.

SIGHUP​

SIGHUP은 의미가 뒤집힌 시그널입니다. 이름 그대로 "HangUp"에서 왔습니다. 1970년대 전화 연결이 끊기면 모뎀이 보내주던 신호입니다. 지금은 그 용도가 거의 사라졌지만 두 가지로 남아 있습니다.

의미 1: 터미널 세션 종료​

SSH로 원격 서버에 접속해서 명령을 실행하고 접속을 끊으면, 그 자식 프로세스들에 SIGHUP이 갑니다. 기본 동작은 종료입니다.

그래서 이를 피하는 도구들이 생겼습니다. nohup은 SIGHUP 무시 플래그를 설정하고 실행하는 "no hup"이고, disown은 셸의 job 테이블에서 프로세스를 제거해 SIGHUP 전파를 끊습니다. setsid는 새 세션을 만들어 터미널과의 연결 자체를 분리합니다. tmux나 screen은 결이 조금 다른데, 세션을 원격 호스트의 상주 데몬이 잡고 있어 클라이언트 연결이 끊겨도 프로세스가 유지됩니다.

주의: nohup은 SIGHUP만 막습니다. SIGTERM, SIGKILL은 그대로 받습니다. 시스템 재부팅/종료 때도 보호하지 못합니다.

의미 2: 설정 리로드 관용​

현대 데몬들은 SIGHUP을 "설정 다시 읽어라"라는 신호로 재해석해서 씁니다. 공식 표준은 아니지만 사실상 관례입니다. 대표적인 예가 nginx입니다. kill -HUP이나 nginx -s reload를 받으면 마스터가 새 설정으로 워커를 띄우고 기존 워커는 현재 연결이 끝나면 종료합니다. rsyslog/syslog-ng도 같은 방식으로 설정을 리로드하고, haproxy도 리로드용으로 씁니다(최근 버전은 seamless-reload를 따로 둡니다). postgres 역시 pg_reload_conf()나 kill -HUP postmaster로 설정을 다시 읽습니다.

HUP의 원래 의미와는 전혀 상관없는 용도인데, 이제는 이쪽이 더 유명합니다.

쿠버네티스의 Termination 시퀀스​

K8s에서 Pod를 지우면 내부적으로 다음 순서로 돕니다.

1. Pod의 status가 Terminating으로 변경
2. 서비스의 endpoint에서 해당 Pod 제거 (신규 트래픽 차단)
3. preStop hook 실행 (정의돼 있다면)
4. 각 컨테이너의 PID 1에 SIGTERM 전송
5. Termination grace period (기본 30초) 대기
6. 그래도 살아 있으면 SIGKILL

여기서 3번 preStop과 4번 SIGTERM 사이의 순서가 중요합니다. 쿠버네티스는 preStop hook이 끝난 뒤에 컨테이너 PID 1로 SIGTERM을 보내며, preStop에 걸린 시간도 grace period에 포함됩니다. 동시에 진행되는 것은 endpoint 제거와 종료 시퀀스라서, preStop은 주로 "LB에서 빠질 시간을 벌기" 같은 용도로 사용합니다.

grace period 설정​

spec:
  terminationGracePeriodSeconds: 60
  containers:
  - name: app
    # ...
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]  # LB가 endpoint 제거를 반영할 시간

앱 내부의 graceful shutdown 타임아웃은 이 값보다 짧게 잡습니다.

흔한 함정들​

Dockerfile의 shell form ENTRYPOINT​

# 나쁜 예 — /bin/sh가 PID 1이 되어 SIGTERM을 흡수
CMD node server.js

# 좋은 예 — node가 직접 PID 1
CMD ["node", "server.js"]

shell form(문자열)은 sh -c로 감싸져 실행되는데, sh는 기본적으로 시그널을 자식에게 전파하지 않습니다. docker stop이 SIGTERM을 PID 1(sh)에 보내지만 실제 앱은 그것을 받지 못합니다. 결국 10초를 기다렸다가 SIGKILL로 박살납니다.

긴 preStop을 graceful shutdown 대체용으로 쓰지 말 것​

preStop: sleep 60 같은 것으로 "종료 시간을 버는" 것은 꼼수에 가깝습니다. 앱이 실제로 정리하는 것이 아니라 단지 종료를 늦출 뿐입니다. 제대로 된 해법은 앱에 SIGTERM 핸들러를 두는 것입니다.

Python의 KeyboardInterrupt는 SIGINT만​

try/except KeyboardInterrupt는 SIGINT만 잡습니다. SIGTERM은 안 잡힙니다. 컨테이너에서 돌리는 Python이면 반드시 signal.signal(signal.SIGTERM, ...)을 등록해야 합니다.

Node.js에서 동기 블로킹 작업​

이벤트 루프를 오래 점유하는 동기 작업(큰 파일 sync read, 무거운 crypto 연산 등)은 process.on('SIGTERM', ...) 핸들러조차 실행하지 못합니다. Node 프로세스가 시그널을 처리할 기회를 얻지 못하기 때문입니다. graceful shutdown이 의미 있으려면 이벤트 루프를 풀어주는 코드여야 합니다.

nohup 과신​

nohup long_task.sh &로 돌려놓았다고 "이제 안전하다"라고 여기기 쉽지만, SIGHUP만 막습니다. reboot나 SIGTERM 앞에서는 무력합니다. 장기 작업은 systemd 유닛이나 tmux 세션 쪽이 더 안전합니다.

한 줄로​

"SIGTERM을 잡을 줄 아는 코드"와 "SIGTERM을 쏠 줄 아는 운영자"가 만나면 SIGKILL이 필요 없는 날이 많아져요. 컨테이너 오케스트레이션 시대에 이 오래된 주제가 다시 중요해진 이유는 결국 이것이에요.

참고​

• SIGKILL vs SIGTERM: Master Process Termination in Linux and Kubernetes, SUSE
• Kubernetes best practices: terminating with grace, Google Cloud
• Graceful Shutdown in Go: Practical Patterns, VictoriaMetrics
• Kubernetes: containers, and the "lost" SIGTERM signals, ITNEXT
• SIGHUP for Configuration Reload, linuxvox
• How to Use the nohup Command in Linux, DigitalOcean

짜증​

tmux copy-mode에서 로그를 위로 올려 y로 복사하면, 복사 직후 라이브 뷰(맨 밑)로 돌아가 버려요. 연속으로 몇 군데 복사하려고 하면 매번 다시 스크롤해야 해요.

환경: tmux 3.1 이상이 필요합니다. 이 글에 쓰인 copy-pipe-no-clear가 3.1에 추가됐습니다. tmux -V로 확인할 수 있습니다.

고친 뒤​

기본값은 ON입니다. 가끔 "복사 후 맨 밑으로"가 필요하면 토글하거나 그냥 Enter를 쓰면 됩니다.

설정​

~/.tmux.conf의 copy-mode 섹션에 다음 설정을 추가합니다.

setw -g mode-keys vi

# 복사 후 copy-mode 유지 토글 (기본 ON)
set -g @copy-stay "on"

# Prefix + Ctrl-y 로 ON/OFF
bind C-y if-shell -F '#{==:#{@copy-stay},on}' \
  'set -g @copy-stay "off" ; display "copy-stay: OFF (y: 맨 밑으로)"' \
  'set -g @copy-stay "on"  ; display "copy-stay: ON  (y: 스크롤 유지)"'

bind-key -T copy-mode-vi v send-keys -X begin-selection

# y: 스크롤 유지 / 맨 밑으로 분기
bind-key -T copy-mode-vi y if-shell -F '#{==:#{@copy-stay},on}' \
  'send-keys -X copy-pipe-no-clear "pbcopy"' \
  'send-keys -X copy-pipe-and-cancel "pbcopy"'

# Enter는 항상 기존 동작
bind-key -T copy-mode-vi Enter send-keys -X copy-pipe-and-cancel "pbcopy"
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-no-clear "pbcopy"

리눅스면 pbcopy 자리를 xclip -selection clipboard로 바꾸면 됩니다.

적용​

tmux source-file ~/.tmux.conf

또는 bind r source-file ~/.tmux.conf 바인딩이 있다면 tmux 안에서 Prefix + r을 누릅니다.

어떻게 되는 건지​

필수는 아니지만 알아두면 좋은 부분입니다.

• @copy-stay는 tmux의 사용자 옵션입니다. 이름이 @로 시작하면 사용자 저장소로 씁니다.
• if-shell -F '#{==:A,B}'는 A와 B가 같으면 첫 번째 명령, 다르면 두 번째 명령을 실행합니다. -F 덕분에 외부 셸을 안 쓰고 tmux format만으로 분기가 끝납니다.
• copy-pipe-no-clear — 복사하고 copy-mode 유지 (연속 복사용)
• copy-pipe-and-cancel — 복사하고 copy-mode 종료 (라이브 뷰로 복귀)
• set -g로 지정한 옵션은 서버 전역. 세션을 여러 개 띄워도 한 번만 토글하면 전체 반영되고, tmux kill-server 전까지 값이 유지됩니다.

copy-mode 종료 키 동작 차이​

같은 copy-mode를 빠져나가는데도 키마다 동작이 다릅니다.

"y 누르고 안 복사된 줄 알았는데 q로 빠져나갔다" 같은 사고가 가끔 있습니다. 종료 전에 복사가 끝났는지를 한 번 확인하는 습관이 안전합니다.

@사용자 옵션과 if-shell 토글의 일반 패턴​

이 글에서 쓴 토글 구조는 사실 이 한 케이스에 한정된 트릭이 아닙니다. @옵션에 상태를 저장하고 if-shell -F로 분기하는 패턴은 tmux 안에서 재사용 가능한 토글을 만드는 일반 기법입니다.

응용 예시 — 상태바에 시각 표시 ON/OFF 토글을 만들 수 있습니다.

set -g @show-clock "off"

bind C-t if-shell -F '#{==:#{@show-clock},on}' \
  'set -g @show-clock "off" ; set -g status-right ""' \
  'set -g @show-clock "on"  ; set -g status-right "%H:%M"'

@*로 시작하는 옵션은 tmux가 해석하지 않고 그대로 보관만 하므로 이름은 자유입니다. 외부 스크립트 없이 tmux 설정 파일 한 곳에서 상태 + 분기 + 알림을 모두 처리할 수 있다는 점이 이 패턴의 가치입니다.

기본값을 off로 두고 싶다면​

set -g @copy-stay "off"

한 줄만 바꾸면 돼요. 토글 키는 그대로 동작해요.

어느 날 Enter가 느려졌다​

터미널에서 Enter를 눌렀는데 다음 프롬프트가 뜰 때까지 300ms 넘게 비는 느낌이 왔어요. 큰 레포일 때는 그러려니 했지만 작은 디렉토리에서도 똑같이 굼떴고, "디렉토리 크기와 무관하게 느리다" — 이 사실이 첫 번째 단서였어요.

이 글은 그 지연의 정체를 찾아가서, 얕은 수정으로 안 됐고, 결국 프롬프트 테마를 갈아엎고 Starship으로 넘어온 여정의 기록입니다.

첫 시도: status를 빠르게 한다​

처음에는 단순하게 접근했습니다. "Enter 뒤 지연 = git status가 느림"이라고 가정하고, 속도를 높이는 옵션부터 모두 켰습니다.

# ~/.zshrc
DISABLE_UNTRACKED_FILES_DIRTY="true"

# git 전역
git config --global core.fsmonitor true
git config --global core.untrackedCache true
git config --global feature.manyFiles true

fsmonitor는 파일 시스템 이벤트를 상주 데몬이 추적해 git status의 내부 스캔 비용을 사실상 0에 가깝게 만듭니다. 실제로 git status --porcelain 자체의 시간은 크게 짧아졌습니다.

그런데 Enter 지연은 거의 그대로였습니다. git status가 10배 빨라졌는데도 체감이 달라지지 않았으니, 제가 엉뚱한 부분을 최적화했다는 뜻이었습니다.

측정을 다시 할 때 만난 세 가지 함정​

문제를 다시 풀어헤치려면 먼저 제대로 측정해야 했습니다. 여기서 쉽게 빠지는 함정이 세 개 있었습니다.

함정 1. zsh -i -c exit는 per-Enter 지연이 아니다​

흔히 쓰는 "쉘 벤치마크"인 time zsh -i -c exit는 전혀 다른 대상을 측정합니다. 쉘이 시작할 때 한 번만 드는 비용입니다. compinit, plugin 로딩 같은 일회성 작업을 포함합니다. 매번 Enter를 칠 때 드는 비용과는 다른 층이라, 이 값을 아무리 줄여도 프롬프트 재평가 비용은 그대로입니다.

함정 2. precmd를 직접 호출해도 안 된다​

일반적인 zsh 테마는 precmd_functions에 훅을 걸어 매 프롬프트 직전에 준비 작업을 합니다. 그러나 agnoster는 다릅니다.

PROMPT='%{%f%b%k%}$(build_prompt) '

PROMPT 변수 안에 명령 치환 $(build_prompt)를 끼워 둔 구조라, 프롬프트 문자열이 expansion될 때 비로소 git 호출이 일어납니다. 그래서 precmd를 수동으로 실행해 재면 거의 0ms가 찍힙니다. 실제 Enter 경로와 다른 곳에서 측정하는 셈입니다.

함정 3. 반복마다 새 zsh를 띄우면 측정이 오염된다​

# 나쁜 예
for i in {1..10}; do
  time zsh -ic 'print -P "$PROMPT" >/dev/null'
done

이렇게 측정하면 매 반복이 zsh 시작 비용(~200ms)에 묻힙니다. 같은 zsh 프로세스 안에서 루프를 돌려야 순수 프롬프트 렌더 비용만 남습니다.

올바른 one-liner​

결국 큰 레포로 cd 한 상태에서 다음과 같이 측정해야 했습니다.

zsh -ic '
  print -P "$PROMPT" >/dev/null        # 웜업
  { time (for i in {1..10}; do print -P "$PROMPT" >/dev/null; done) } 2>&1
'

print -P "$PROMPT"는 PROMPT 문자열을 강제로 expand시키기 때문에 내부의 $(build_prompt)가 실제로 실행되고, 진짜 비용이 드러납니다.

진짜 범인: agnoster의 7× git spawn​

측정을 제대로 돌리자 범인이 또렷이 보였습니다. ~/.oh-my-zsh/themes/agnoster.zsh-theme의 prompt_git()은 매 프롬프트 렌더마다 git 서브프로세스를 일곱 번 띄웁니다.

1. git config --get oh-my-zsh.hide-status
2. git rev-parse --is-inside-work-tree
3. git rev-parse --git-dir
4. git status --porcelain        (parse_git_dirty)
5. git symbolic-ref HEAD
6. git log --oneline @{upstream}..   (ahead)
7. git log --oneline ..@{upstream}   (behind)

그리고 macOS의 기본 git 바이너리는 Apple wrapper입니다.

/Library/Developer/CommandLineTools/usr/libexec/git-core/git

호출 한 번당 fork → exec → wrapper → core 체인에 고정적으로 40~50ms가 듭니다. 이 오버헤드는 git이 아무리 빨라도 줄어들지 않습니다.

산수가 맞아떨어집니다.

7 × 50ms ≈ 350ms

그래서 .git이 수십 MB든 수백 MB든 바닥값은 비슷하게 나옵니다. 이게 Enter 지연의 정체였습니다.

측정 결과 (10회 평균)​

프롬프트 지연의 95% 이상이 prompt_git의 spawn 오버헤드였습니다. git status 자체는 fsmonitor 덕분에 이미 충분히 빨랐습니다. 제가 status 내부를 최적화하느라 헛돈 까닭은 줄일 수 있는 구간만 보고 줄이려 했기 때문입니다. spawn 횟수는 그대로 7이었으니 체감이 달라지지 않은 게 당연했습니다.

세 가지 선택지​

구조적 한계가 확인되자 길이 명확해졌습니다.

A. agnoster의 git 세그먼트를 끈다​

git config --global oh-my-zsh.hide-status 1

혹은 zshrc 마지막에:

prompt_git() { : }

프롬프트 렌더 비용이 15ms로 떨어집니다. 대신 브랜치/dirty 표시가 사라집니다. 저는 브랜치를 프롬프트에서 보는 편이 좋아서 이 선택지는 제외했습니다.

B. powerlevel10k로 간다​

gitstatusd라는 상주 데몬이 변경을 감시하며 결과를 파이프로 돌려줍니다. git 바이너리를 띄우지 않으므로 spawn은 0회입니다. instant prompt를 사용해 초기 표시도 빠릅니다.

괜찮은 옵션이지만, 설정을 직접 다듬기엔 .p10k.zsh 포맷이 다소 난잡해 보였습니다.

C. Starship으로 간다​

Rust로 작성한 단일 바이너리입니다. zsh 프롬프트 훅에서 starship 바이너리를 한 번 실행하고, git 정보는 그 안에서 Rust로 작성된 git 구현 gitoxide(gix)로 읽습니다. Starship은 1.10.0에서 libgit2 바인딩을 gitoxide로 바꿨고, 1.23.0부터는 git_status 모듈도 gitoxide를 씁니다. 다만 1.25.0의 git_status는 core.fsmonitor가 켜져 있거나 use_git_executable을 설정한 경우 등에는 git status --porcelain=2를 외부 프로세스로 실행합니다. 앞에서 core.fsmonitor를 켠 이 환경에서는 외부 git 실행이 매 렌더 7회에서 git_status의 1회 수준으로 줄어듭니다.

• 설정은 ~/.config/starship.toml 한 파일 (TOML)
• git diff로 리뷰/롤백이 쉬움
• 프리셋 갤러리가 존재해 시작점 제공

풍부한 정보와 속도, 설정 가독성을 모두 고려해 Starship으로 결정했습니다.

Starship 전환 작업​

설치​

brew install starship
# 1.25.0

~/.zshrc 두 군데 수정​

agnoster를 끄고:

- ZSH_THEME="agnoster"
+ # ZSH_THEME="agnoster"   # 비활성, Starship 사용
+ ZSH_THEME=""

파일 끝에 초기화 추가:

# Starship prompt. agnoster 대신. 없으면 graceful skip.
if command -v starship >/dev/null 2>&1; then
  eval "$(starship init zsh)"
fi

바이너리가 없으면 조용히 건너뛰도록 command -v 체크를 넣었습니다. 새 머신 셋업할 때 zshrc를 그대로 복사해도 안전합니다.

프리셋 적용​

starship preset pastel-powerline -o ~/.config/starship.toml

pastel-powerline의 정보 밀도가 가장 괜찮아 선택했습니다. 이대로 써도 되지만 두 가지가 걸렸습니다.

1. 한 줄 프롬프트라 긴 디렉토리/브랜치명이 나오면 명령 입력 공간이 좁아집니다.
2. 다크 터미널에서 일부 세그먼트의 글자가 묻힙니다.

튜닝 1: 두 줄 프롬프트​

format 문자열 끝(마지막 """ 직전)에 줄바꿈과 character 모듈을 추가합니다.

$line_break\
$character

파일 끝에는 [character] 섹션을 추가합니다.

[character]
success_symbol = "[❯](bold #FCA17D)"
error_symbol = "[❯](bold red)"
vimcmd_symbol = "[❮](bold green)"

이제 첫 줄에는 정보(유저/경로/git/언어/시간)를 표시하고, 두 번째 줄에는 ❯ 하나만 둡니다. 명령 입력이 세그먼트에 영향받지 않습니다.

튜닝 2: 다크 터미널 가독성​

기본 pastel-powerline은 각 세그먼트 배경색만 지정하고 글자색은 터미널 기본을 씁니다. 어두운 터미널(제 환경은 거의 검정 배경)에서는 짙은 배경 세그먼트 안의 글자가 잘 보이지 않았습니다.

각 세그먼트에 명시적 글자색과 bold를 지정했습니다.

time 세그먼트의 원래 배경 #33658A는 너무 어두워서 거의 터미널 배경과 합쳐져 보였습니다. 더 밝은 파랑 #4A86C5로 바꾸고, format 문자열 안의 배경/전경 치환자 두 군데도 같이 교체했습니다.

bg:#33658A)  →  bg:#4A86C5)
fg:#33658A)  →  fg:#4A86C5)

Nerd Font 글리프가 많은 파일이라 직접 편집하면 글자가 깨지기 쉽습니다. 수정은 Python 스크립트로 바이트 안전하게 적용했습니다.

결과​

속도 (20회 평균, 같은 zsh 내 print -P "$PROMPT")​

약 6배입니다. 인간 지각 한계(~100ms) 안쪽이라 체감상 즉시 반응합니다. Enter가 걸리던 감각이 완전히 사라졌습니다.

시각​

실제 화면입니다(일부 모자이크).

표시 요소:

• 사용자명 (흰 bold, 보라 배경)
• 디렉토리 (3계층 … 축약)
• git 브랜치 + 상태 (stashed $ / untracked ? / modified ! / renamed / ahead/behind 등)
• 감지된 언어 버전 (위 예시엔 Go v7.3.2, Java v25.0.1)
• 시간 (♥ HH:MM)
• 두 번째 줄: ❯ 입력 커서

이 과정에서 배운 것​

1. 느린 걸 고치려면 먼저 제대로 재야 합니다. 제가 잰 zsh -i -c exit는 Enter 지연이 아니라 쉘 시작 시간이었습니다. 엉뚱한 걸 최적화하느라 며칠 돌아갔습니다.

2. spawn 횟수는 내부 로직 속도와 독립입니다. git이 1ms에 끝나도 7번 띄우면 350ms가 듭니다. 개선 가능한 구간이 보여도, 그 부분이 병목인지부터 확인해야 합니다.

3. 도구의 구조를 모르면 설정도 고치기 어렵습니다. agnoster가 PROMPT 변수 안에 명령 치환을 넣는 구조라는 걸 몰랐다면 precmd 벤치마크만 반복하며 "왜 안 느리지?"라고 했을 겁니다.

4. 근본 전환이 결국 싸게 먹힐 때가 있어요. 보조 옵션을 쌓아도 못 넘는 한계가 있을 때는 테마 자체를 갈아치우는 편이 빨라요. agnoster → Starship은 설정 파일 두 개 수정 + brew install 한 번이었어요.

참고 자료​

• Starship 공식 사이트
• Starship 프리셋 갤러리: pastel-powerline 시작점
• powerlevel10k (대안 선택지)
• macOS git wrapper 관련: xcrun -f git으로 위치 확인 가능

PostgreSQL 파티셔닝의 짧은 역사​

PostgreSQL의 파티셔닝은 10 버전에서 선언적(declarative) 문법이 들어온 이후 꾸준히 성숙해왔어요. 11에서 UPDATE로 파티션 간 row 이동이 가능해졌고, 14에서 DETACH PARTITION CONCURRENTLY가 추가됐어요. 그리고 PostgreSQL 19에서 마침내 파티션 자체를 병합하고 분할하는 DDL이 들어와요.

ALTER TABLE ... SPLIT PARTITION ...
ALTER TABLE ... MERGE PARTITIONS ...

익숙한 문법입니다. Oracle을 써본 사람이라면 20년 넘게 봐온 구문과 거의 판박입니다. 다만 자세히 보면 문법과 제약에서 결정적인 차이들이 있습니다.

이전까지 PostgreSQL에서는 어떻게 했나​

PostgreSQL 18 이하에서 파티션을 병합하려면 이런 절차를 거쳤습니다.

1. 새로운 합쳐진 파티션 테이블을 생성
2. 기존 파티션에서 INSERT SELECT로 데이터 이동
3. 기존 파티션 DETACH
4. 새 파티션 ATTACH
5. 기존 파티션 DROP

한 번에 트랜잭션으로 묶기도 까다롭고, 데이터 이동 중 ACCESS EXCLUSIVE LOCK이 걸려 서비스 가용성에도 영향을 줍니다. 분할도 마찬가지로 귀찮았습니다. Oracle에서는 한 줄이면 끝나는 작업이었습니다.

PostgreSQL 19의 새 문법​

SPLIT과 MERGE를 각각 예제로 살펴보겠습니다.

SPLIT PARTITION​

-- 원본 파티션 테이블
CREATE TABLE sales (
    id bigint generated always as identity,
    region text not null,
    amount numeric
) PARTITION BY LIST (region);

CREATE TABLE sales_all PARTITION OF sales
    FOR VALUES IN ('KR', 'JP', 'CN', 'US', 'UK');

-- 하나의 파티션을 셋으로 분할
ALTER TABLE sales SPLIT PARTITION sales_all INTO (
    PARTITION sales_asia FOR VALUES IN ('KR', 'JP', 'CN'),
    PARTITION sales_us   FOR VALUES IN ('US'),
    PARTITION sales_uk   FOR VALUES IN ('UK')
);

MERGE PARTITIONS​

-- 세 파티션을 하나로 합치기
ALTER TABLE sales MERGE PARTITIONS
    (sales_asia, sales_us, sales_uk)
    INTO sales_all;

문법에서 눈여겨볼 점은 다음과 같습니다.

• 지원 타입: RANGE, LIST (HASH는 지원하지 않음)
• RANGE 파티션은 인접(adjacent) 해야 병합 가능
• LIST는 인접 제약 없음
• 소스 파티션들은 괄호 (...)로 감싼다
• 대상 파티션에 PARTITION 키워드를 붙이지 않는다

Oracle의 문법​

같은 일을 Oracle에서 하면 이렇게 됩니다. Oracle 쪽은 8i 시절부터 존재해온 문법이라 변주가 많습니다.

SPLIT PARTITION​

-- RANGE 파티션 분할 (AT 값 기준)
ALTER TABLE sales SPLIT PARTITION sales_2026 AT (DATE '2026-07-01')
    INTO (
        PARTITION sales_2026_h1 TABLESPACE ts1,
        PARTITION sales_2026_h2 TABLESPACE ts2
    );

-- LIST 파티션 분할 (VALUES 기준)
ALTER TABLE sales SPLIT PARTITION sales_all
    VALUES ('KR', 'JP', 'CN')
    INTO (
        PARTITION sales_asia,
        PARTITION sales_rest
    );

MERGE PARTITIONS​

-- 기본 문법
ALTER TABLE sales MERGE PARTITIONS
    sales_q1_2026, sales_q2_2026, sales_q3_2026, sales_q4_2026
    INTO PARTITION sales_2026;

-- RANGE 전용 TO 단축 문법
ALTER TABLE sales MERGE PARTITIONS
    sales_q1_2026 TO sales_q4_2026
    INTO PARTITION sales_2026;

나란히 비교​

문법 차이​

기능/제약 차이​

실전에서 갈리는 락과 온라인 실행​

문법은 거의 맞춰졌습니다. 하지만 운영에서 진짜 갈리는 것은 락과 온라인 실행 여부입니다.

PostgreSQL 19​

공식 커밋 메시지와 depesz의 벤치(1천만 행 LIST 파티션 기준)에서 확인된 내용은 다음과 같습니다.

• 작업 전체 구간에서 ACCESS EXCLUSIVE LOCK 유지
• 단일 프로세스에서 순차 실행
• 대규모 파티션에서는 실질적 다운타임이 발생할 수 있음

쓸모 있는 평가는 이렇습니다. "편의성은 크게 좋아졌지만, 온라인성은 Oracle을 따라잡지 못했습니다." 한 줄 SQL로 간단히 표현할 수 있게 된 것만으로도 의미가 크지만, 수백 GB 파티션을 무중단으로 합칠 수 있는 수준은 아닙니다.

Oracle​

Oracle Enterprise Edition에서는 ONLINE 키워드로 DML 블로킹 없이 파티션을 쪼개거나 합칠 수 있습니다. SPLIT PARTITION ... ONLINE은 12.2부터, MERGE PARTITIONS ... ONLINE은 18c부터 지원합니다.

ALTER TABLE sales MERGE PARTITIONS
    sales_q1_2026, sales_q2_2026
    INTO PARTITION sales_h1_2026
    ONLINE;

내부적으로는 shadow 구조를 만들고 점진적으로 데이터를 이관하는 방식이라, 배타 락 보유 시간이 거의 없습니다. Enterprise Edition 라이선스가 전제라는 게 큰 단서지만, 대형 운영 환경에서 체감되는 차이는 큽니다.

어디까지 따라왔고, 어디까지 아직인가​

따라잡은 것

• SPLIT/MERGE DDL 자체의 존재: SQL 한 줄로 끝납니다
• 지원 파티션 타입 (RANGE, LIST)
• 인접 조건 정책 (RANGE는 인접 필요, LIST는 무관)
• 다중 분할(한 파티션 → N개)과 다중 병합(N개 → 하나)

아직 못 따라온 것

• 온라인(ONLINE) 실행: 대형 파티션은 실질적 다운타임이 남음
• 병렬 실행: 단일 프로세스로만 처리
• RANGE 범위 병합 단축 문법(p1 TO p4) 없음

PostgreSQL의 역사적 약점 중 하나가 "큰 파티션 테이블의 유지보수가 DDL 한 줄로 안 끝난다"였습니다. PostgreSQL 19는 그 거리를 눈에 띄게 좁혔습니다. 다만 운영에서 가장 아픈 "락을 오래 붙잡는다"는 문제는 남아 있어서, 대형 테이블은 여전히 DETACH CONCURRENTLY + 수동 작업 전략을 병용해야 할 수 있습니다.

Oracle에서 PostgreSQL로 넘어올 때 "제가 쓰던 그 문법, PostgreSQL에도 있어요?"라는 질문의 목록이 하나씩 채워지고 있어요. 이번은 파티션 병합/분할 차례였어요.

참고

• Waiting for PostgreSQL 19 – Implement ALTER TABLE … MERGE/SPLIT PARTITIONS — depesz
• PostgreSQL devel — ALTER TABLE 문서
• Oracle Database VLDB Guide — Merging Multiple Partitions
• Oracle Base — Partition Maintenance Operations in 12c Release 1

또 새 기능이다​

Claude Code를 쓰다 보면 이런 경험이 있을 거예요. 파일 하나를 수정할 때마다 "Allow?" 프롬프트가 뜨고, bash 명령을 실행할 때마다 또 떠요. 장시간 작업할 때는 Y 키를 누르는 게 일이 돼요.

그래서 나온 게 Auto 모드입니다. 2026년 3월 24일, 리서치 프리뷰로 공개됐습니다.

Auto mode lets Claude handle permission prompts automatically — Claude checks each tool call for risky actions and prompt injection before executing.

쉽게 말하면, 권한 승인을 AI가 대신 판단해 주는 모드입니다.

기존 권한 모드 복습​

Auto 모드를 이해하려면 기존 모드부터 알아야 합니다. Shift+Tab으로 전환할 수 있는 모드들입니다.

핵심 차이:

• default/acceptEdits: 사람이 판단
• auto: AI 분류기가 판단
• bypassPermissions: 아무도 판단 안 함 (위험)

어떻게 동작하나​

Auto 모드는 2단계 파이프라인으로 각 도구 호출의 안전 여부를 판단합니다.

1단계: 입력 검사와 프롬프트 인젝션 탐지​

도구 실행 결과가 에이전트의 컨텍스트에 들어가기 전에, 서버 측에서 프롬프트 인젝션 시도를 스캔합니다. 파일이나 웹페이지에 숨겨진 악성 지시를 감지하면 경고를 붙입니다.

2단계: 출력 검사와 트랜스크립트 분류기​

실제 도구 호출 전에 Claude Sonnet 4.6 기반 분류기가 행동의 위험성을 평가합니다.

Stage 1: 빠른 1토큰 Yes/No 필터
  ↓ (위험 가능성 있으면)
Stage 2: Chain-of-thought 추론으로 정밀 판단
  ↓
결과: 승인 또는 차단

• Stage 1에서 대부분의 안전한 작업이 바로 통과
• 의심스러운 것만 Stage 2로 넘어가서 정밀 검토
• 분류기는 사용자 메시지, 도구 호출, CLAUDE.md 내용을 참조
• 도구 실행 결과는 분류기에게 보이지 않음 (인젝션 방지)

뭘 막고 뭘 허용하나​

기본 차단 항목​

• curl | bash 같은 다운로드 후 실행 패턴
• 외부 엔드포인트로 민감 데이터 전송
• 프로덕션 배포 및 마이그레이션
• 클라우드 스토리지 대량 삭제
• IAM/리포 권한 변경
• main에 직접 push 또는 force push
• 세션 이전에 존재하던 파일의 비가역적 삭제

기본 허용 항목​

• 작업 디렉토리 내 로컬 파일 작업
• 매니페스트에 선언된 의존성 설치
• .env 읽기 및 해당 API로의 인증 정보 전송
• 읽기 전용 HTTP 요청
• 시작 브랜치 또는 Claude가 생성한 브랜치에 push

차단 시 동작​

분류기가 차단하면 Claude는 이유를 전달받고 다른 접근법을 시도합니다. 연속 3회 또는 세션 내 20회 차단되면 Auto 모드가 일시 중단되고 사용자에게 직접 물어봅니다.

정확도는​

Anthropic이 공개한 수치:

17%의 미탐(false negative)이 눈에 띕니다. Anthropic도 이걸 숨기지 않고 공개했습니다. "완벽하지 않다"는 걸 솔직하게 인정한 것입니다.

즉, 사용자가 거부했을 위험 행동 100건 중 17건이 통과할 수 있습니다. 그래서 격리된 환경에서의 사용을 계속 권장하는 것입니다.

요금과 제한​

• Pro 플랜: 사용 불가
• Max, Team, Enterprise, API: 사용 가능
• 분류기 호출이 토큰 사용량에 포함되어 약간 더 비쌈
• 읽기와 작업 디렉토리 내 파일 편집은 분류기를 건너뛰므로 추가 비용 없음
• 셸 명령, 네트워크 작업에서 주로 추가 비용 발생
• Claude Code v2.1.83 이상 필요

주의할 점​

컨텍스트 압축 문제​

대화 중에 "main에 push하지 마" 같은 경계를 설정해도, 컨텍스트 압축(compaction)이 해당 메시지를 날려버리면 분류기가 그 경계를 인식하지 못합니다.

해결하려면 대화로 경계를 설정하지 말고, 명시적 deny 규칙을 설정 파일에 넣어야 합니다.

상속된 권한 문제​

Auto 모드의 분류기는 개별 행동을 평가하지, 전체 맥락에서의 의도를 파악하지는 못합니다. IAM 수정이나 curl | bash 같은 패턴은 차단하지만, 개별적으로는 무해해 보이는 여러 행동이 합쳐져서 위험해지는 경우는 놓칠 수 있습니다.

이전 취약점 이력​

Claude Code에는 이미 보고된 CVE가 있습니다.

• CVE-2025-59536: 악성 .claude/settings.json을 통한 원격 코드 실행
• CVE-2026-21852: 악성 저장소의 프로젝트 설정(ANTHROPIC_BASE_URL)을 통한 API 키 유출

Auto 모드가 이런 공격 벡터를 완전히 차단하지는 못합니다.

bypassPermissions 대신 Auto를 써야 하는 이유​

이전에 장시간 작업을 위해 bypassPermissions(또는 --dangerously-skip-permissions)를 쓰던 사람들이 있습니다. Auto 모드는 그 대안입니다.

공식 문서에서도 이렇게 말합니다.

"For background safety checks without prompts, use auto mode instead."

활성화 방법​

# CLI 플래그
claude --permission-mode auto

# 또는 실행 중 Shift+Tab으로 전환

# 기본값으로 설정
# settings.json에서:
# "permissions": { "defaultMode": "auto" }

Team/Enterprise 플랜에서는 관리자가 먼저 활성화해야 사용자가 접근할 수 있습니다.

커뮤니티 반응​

GeekNews(news.hada.io)에서도 Auto 모드 소식이 다뤄졌습니다. 댓글 반응이 인상적입니다.

"하루가 다르게 발전하는군요"

"일상이 바뀔 수 있을 정도의 파급력이 있는 기능이 하루 걸러 하나씩 나와버리네요"

저도 공감해요. Anthropic의 릴리즈 속도는 정말 따라가기 벅찰 정도예요.

마무리​

Auto 모드는 "매번 Y를 누르는 귀찮음"과 "아무 검사 없이 전부 실행하는 위험함" 사이의 중간 지점입니다.

편리합니다. 하지만 17%의 미탐률이 있고, 컨텍스트 압축 문제가 있고, 격리 환경에서 쓰라는 권장 사항이 있습니다. 리서치 프리뷰인 만큼 앞으로 개선될 여지가 있지만, 지금은 편리함과 위험 사이의 트레이드오프를 이해하고 쓰는 것이 중요합니다.

개인 프로젝트에서 장시간 코딩 세션을 돌릴 때라면 충분히 쓸 만해요. 프로덕션 인프라에 접근 가능한 환경이라면 아직은 아니에요.

이 글은 2026년 4월 기준 리서치 프리뷰 상태를 바탕으로 작성했어요. 정식 출시 후 동작, 정확도, 요금이 변경될 수 있어요.

참고 자료​

• Auto mode for Claude Code (Anthropic Blog)
• Claude Code auto mode: a safer way to skip permissions (Anthropic Engineering)
• Choose a permission mode (Claude Code Docs)
• Claude Code Auto Mode 공개 (GeekNews)
• Anthropic hands Claude Code more control (TechCrunch)
• What Auto Mode Means for AI Agent Privilege Management (Apono)

commands가 사라졌다?​

Claude Code를 쓰면서 .claude/commands/ 디렉토리에 커스텀 명령어를 만들어 쓰던 분들이 있을 거예요. /deploy, /review, /commit 같은 것들이에요.

그런데 어느 날 문서를 보니 "Skills"라는 게 나옵니다. commands는 어디로 갔을까요.

결론부터 말하면, commands가 skills로 통합됐습니다. 정확히는 v2.1.3 (2026년 1월)부터입니다.

"Merged slash commands and skills, simplifying the mental model with no change in behavior" — Claude Code v2.1.3 Changelog

타임라인​

공식 deprecation 일정은 아직 없습니다. 하지만 방향은 명확합니다.

commands와 skills의 차이​

기존: commands​

.claude/commands/deploy.md

마크다운 파일 하나. 프롬프트를 적어두면 /deploy로 호출할 수 있었습니다. 단순하고 직관적이었습니다.

현재: skills​

.claude/skills/deploy/
├── SKILL.md           # 주요 지침 (필수)
├── template.md        # Claude가 채울 템플릿
├── examples/
│   └── sample.md      # 예제 출력
└── scripts/
    └── validate.sh    # Claude가 실행할 스크립트

디렉토리 구조입니다. SKILL.md가 진입점이고, 지원 파일을 함께 둘 수 있습니다.

핵심 차이: frontmatter​

Skills의 가장 큰 차이는 YAML frontmatter입니다.

---
name: deploy
description: 프로덕션 배포
disable-model-invocation: true
allowed-tools: Bash(ssh *) Bash(rsync *)
model: claude-opus-4-7
context: fork
---

배포 순서:
1. 테스트 실행
2. 빌드
3. 서버에 전송

frontmatter로 할 수 있는 것들:

commands에서는 이런 제어가 전부 불가능했습니다.

자동 호출이 핵심​

commands는 /명령어로 직접 호출해야만 동작했습니다. skills는 다릅니다.

description에 적절한 키워드를 넣어두면, Claude가 대화 맥락에서 관련이 있다고 판단할 때 자동으로 로드합니다. 예를 들면 다음과 같습니다.

---
name: api-conventions
description: API design patterns for this codebase
---

API 엔드포인트 작성 시:
- RESTful 명명 규칙 사용
- 일관된 에러 포맷 반환
- 요청 유효성 검사 포함

이 skill은 /api-conventions으로 호출할 수도 있고, Claude가 API 코드를 작성할 때 알아서 참조하기도 합니다.

반대로 배포처럼 사람이 타이밍을 통제해야 하는 작업은 disable-model-invocation: true를 설정해서 자동 호출을 막습니다.

마이그레이션은 어떻게​

안 해도 된다​

기존 .claude/commands/ 파일은 그대로 동작합니다. 이름이 같으면 skill이 우선할 뿐입니다.

하고 싶다면​

1. .claude/skills/<이름>/ 디렉토리 생성
2. 기존 .md 파일 내용을 SKILL.md로 이동
3. 필요하면 frontmatter 추가
4. 기존 commands 파일 삭제

예시:

Before — .claude/commands/deploy.md

프로덕션에 배포해줘.
1. 테스트 실행
2. 빌드
3. rsync로 서버에 전송

After — .claude/skills/deploy/SKILL.md

---
name: deploy
description: 프로덕션 빌드 및 배포
disable-model-invocation: true
---

프로덕션에 배포해줘.
1. 테스트 실행
2. 빌드
3. rsync로 서버에 전송

내용은 같고, frontmatter만 추가됐습니다.

번들 Skills​

Claude Code가 기본으로 제공하는 skills도 있습니다.

이것들도 전부 skill입니다. 프롬프트 기반으로 Claude가 도구를 조율해서 실행합니다.

Skills 저장 위치​

skill을 어디에 저장하느냐에 따라 적용 범위가 달라집니다.

제가 자주 쓰는 건 Personal에, 프로젝트 팀원과 공유할 건 Project에 넣으면 돼요.

커뮤니티 반응​

병합이 발표됐을 때 커뮤니티에서 혼란이 있었습니다. GitHub에 "Merged slash commands and skills"가 뭔 말이냐는 이슈가 올라왔고, "no change in behavior"면 왜 changelog에 넣느냐는 비판도 있었습니다.

실제로 사용자 입장에서는 기존 commands가 그대로 동작하기 때문에 체감할 수 있는 변화가 거의 없었습니다. 하지만 앞으로 새로 만들 때는 skills로 만드는 편이 맞습니다. frontmatter의 자동 호출 제어, 도구 제한, subagent 실행 같은 기능은 commands에서는 쓸 수 없습니다.

정리​

기존 commands를 당장 마이그레이션할 필요는 없어요. 하지만 새로 만들 건 skills로, 기존 것도 기능이 필요하면 skills로 전환하는 게 좋아요.

참고 자료​

• Extend Claude with skills (Claude Code Docs)
• Claude Code v2.1.3 Changelog (X)
• Changelog entry confusion (GitHub Issue #17288)
• Track full deprecation of commands (GitHub Issue #37447)
• Slash Commands Are Dead. Long Live Skills. (Medium)
• Claude Code Skills vs Slash Commands 2026 (YingTu)

출시​

2026년 4월 16일, Anthropic이 Claude Opus 4.7을 출시했어요. 모델 ID는 claude-opus-4-7 — 가격은 Opus 4.6과 동일하게 백만 토큰당 입력 $5, 출력 $25예요.

Anthropic의 공식 표현이 인상적입니다.

"가장 어려운 코딩 작업을 감독 없이 맡길 수 있는 수준"

"더 똑똑해졌다"보다 "더 맡길 수 있게 됐다"는 표현을 택했습니다. 모델의 방향성이 달라졌음을 보여줍니다.

벤치마크: 1위 탈환​

GPT-5.4와 Gemini 3.1 Pro에 밀렸던 자리를 되찾았습니다.

코딩​

SWE-bench Pro에서는 Opus 4.6 대비 약 11%p(53.4% → 64.3%) 향상됐습니다. CursorBench에서도 58% → 70%로 12%p 올랐습니다.

지식 노동​

금융 분석, 법률 검토, 문서 작성 등 전문 지식 작업에서도 최고 수준을 기록했습니다.

비전​

54.5%에서 98.5%로 뛰었습니다 — 단순한 "개선"보다 "차원이 다른" 수준에 가깝습니다.

핵심 변화 1: 셀프 검증​

Opus 4.7의 가장 큰 변화는 자기 출력물을 스스로 검증한다는 것입니다.

단순한 chain-of-thought에 그치지 않습니다. 모델은 다음 과정을 거칩니다.

1. 원래 요구사항과 출력물을 대조 확인
2. 계획 단계에서 논리적 결함을 감지
3. 실제로 문제가 해결되는지 검증

Vercel의 평가에 따르면 "시스템 코드 작업 전에 먼저 증명(proof)을 제시하는 새로운 행동 방식"이 관찰됐습니다. Notion은 "암시적 요구사항 테스트를 처음으로 통과"했다고 보고했습니다.

그 결과 도구 오류가 1/3로 감소했고, 다단계 워크플로우 성능은 14% 향상됐습니다.

핵심 변화 2: 3.3배 고해상도 비전​

이전 Claude 모델의 이미지 해상도 한계는 1,568px / 1.15MP였습니다. Opus 4.7은 2,576px / 3.75MP로 3배 이상 늘었습니다.

이 변화가 중요한 이유는 다음과 같습니다.

• 화학 구조식의 작은 글씨 인식
• 기술 다이어그램의 세부 요소 파악
• 특허 문서의 복잡한 도면 해석
• 스크린샷 기반 에이전트의 화면 인식 정확도

XBOW 벤치마크에서 54.5% → 98.5%로 뛴 데에는 이 해상도 향상이 영향을 미쳤습니다. 자율 펜테스팅 워크플로우가 이제 가능해졌다는 평가도 있습니다.

핵심 변화 3: xhigh Effort 레벨​

기존 effort 파라미터에 xhigh 레벨이 추가됐습니다.

low → medium → high → xhigh (신규) → max

• xhigh는 Claude Code의 새 기본값
• high와 max 사이의 지능/비용 트레이드오프
• 코딩과 에이전트 작업에 최적화

# API 사용 예시
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}]
)

effort는 output_config 안에 지정하고, Opus 4.7은 budget_tokens 대신 adaptive thinking을 씁니다(Effort 공식 문서).

주의사항: 프롬프트 재튜닝 필수​

이 대목은 중요합니다. Opus 4.7은 지시를 문자 그대로 해석합니다.

이전 모델들은 모호한 표현을 "알아서" 해석했지만, 4.7은 정확히 지시한 대로만 실행합니다.

기존에 잘 돌아가던 프롬프트가 4.7에서는 다르게 동작할 수 있습니다. 마이그레이션 시 프롬프트 감사가 필수입니다.

주의사항: 토큰 사용량 변화​

• 입력 토큰: 1.0~1.35배 증가
• 높은 effort 레벨에서 더 많은 토큰 소비
• 토크나이저 업데이트로 동일 텍스트가 더 많은 토큰으로 분해될 수 있음

다만 Replit은 "더 낮은 비용으로 동일 품질 달성"이 가능하다고 평가했습니다. 개별 호출의 토큰은 늘어도 재시도와 오류 수정이 줄어 전체 비용은 오히려 감소할 수 있다는 의미입니다.

주의사항: 벤치마크 오염 가능성​

Anthropic 스스로 메모리화 오염(memorization contamination) 가능성을 언급했습니다. 벤치마크 데이터가 학습 데이터에 포함됐을 가능성을 뜻합니다. 따라서 실제 프로덕션 작업으로 직접 검증하는 편이 좋습니다.

함께 나온 기능들​

Opus 4.7 출시와 함께 Claude Code에도 새 기능이 추가됐습니다.

보안​

Project Glasswing에 따라 사이버 보안 능력이 일정 수준으로 제한되어 있습니다. Mythos(연구용 내부 모델)보다 제한적이며, 위험한 사이버 보안 용도는 자동 탐지/차단됩니다.

다만 정당한 보안 전문가를 위한 Cyber Verification Program이 있어서, 인증된 사용자는 보안 연구 목적으로 활용할 수 있습니다.

커뮤니티 반응​

GeekNews에서도 당연히 다뤄졌습니다.

Genspark은 "무한 루프 저항성, 일관성, 우아한 에러 복구"가 개선됐다고 평가했습니다. 개발 현장에서 실제로 체감할 만한 변화라는 의미입니다.

VentureBeat는 "GPT-5.4와 Gemini 3.1 Pro를 간신히 따돌리며 1위를 탈환"이라고 보도했습니다. "간신히"라는 표현이 현재 LLM 경쟁의 치열함을 잘 보여줍니다.

정리​

Opus 4.7의 특징은 "더 똑똑해졌다"보다 "더 맡길 수 있게 됐다"에 가까워요. 셀프 검증, 도구 오류 감소, 긴 작업에서의 일관성 — 모두 "사람이 덜 개입해도 되는" 방향을 가리켜요.

프롬프트 재튜닝만 잘하면, 체감 성능은 벤치마크 수치보다 더 클 수 있어요.

참고 자료​

• Introducing Claude Opus 4.7 (Anthropic)
• What's new in Claude Opus 4.7 (Claude API Docs)
• Claude Opus 4.7 실전 활용 가이드 (brunch/@lukas08)
• Claude Opus 4.7을 소개합니다 (GeekNews)
• Claude Opus 4.7 narrowly retaking lead (VentureBeat)
• Claude Opus 4.7 leads on SWE-bench (The Next Web)
• Claude Opus 4.7 is now available in Amazon Bedrock (AWS)

EXPLAIN ANALYZE의 불편한 진실​

EXPLAIN ANALYZE는 PostgreSQL에서 쿼리 성능을 분석할 때 가장 먼저 쓰는 도구예요. 실제로 쿼리를 실행하면서 각 노드의 실행 시간, 행 수, 루프 횟수를 보여줘요.

그런데 한 가지 문제가 있습니다. EXPLAIN ANALYZE를 붙이는 것 자체가 쿼리를 느리게 만듭니다.

이건 버그가 아니라 구조적인 문제입니다. 공식 문서에서도 이렇게 경고합니다.

"The measurement overhead added by EXPLAIN ANALYZE can be significant, especially on machines with slow gettimeofday() operating-system calls."

왜 느려지나​

EXPLAIN ANALYZE는 실행 계획의 각 노드를 통과할 때마다 시간을 측정합니다. 구체적으로는 InstrStartNode(시작)과 InstrStopNode(종료)에서 시스템 시계를 읽습니다.

핵심은 이 시계를 읽는 함수가 clock_gettime()이라는 것입니다.

쿼리 실행 흐름:

  SeqScan (100만 행)
    ├─ 행 1: clock_gettime() → 처리 → clock_gettime()
    ├─ 행 2: clock_gettime() → 처리 → clock_gettime()
    ├─ 행 3: clock_gettime() → 처리 → clock_gettime()
    │  ...
    └─ 행 1,000,000: clock_gettime() → 처리 → clock_gettime()

  → clock_gettime() 호출 횟수: 200만 번

100만 행을 스캔하면 clock_gettime()이 200만 번 호출됩니다. 중첩된 노드가 있으면 더 늘어납니다. 각 호출이 약 20ns라고 해도, 200만 번이면 40ms의 순수 오버헤드가 발생합니다.

프로파일링을 해보면 InstrStartNode/InstrStopNode의 실행 시간 대부분이 clock_gettime()에서 소비됩니다. 실제 쿼리 로직이 아니라 시간 측정에 시간을 쓰고 있는 것입니다.

clock_gettime()이 뭔데​

clock_gettime()은 Linux에서 고해상도 시간을 가져오는 시스템 콜입니다. 정확하고 안정적이지만, 호출할 때마다 비용이 듭니다.

현대 Linux에서는 VDSO (Virtual Dynamic Shared Object)를 통해 커널 진입 없이 호출할 수 있도록 최적화되어 있습니다. 그래도 호출당 약 18~20ns의 오버헤드가 있습니다. 플랫폼에 따라 20~100ns까지 달라질 수 있습니다.

clock_gettime() 호출 경로:

  사용자 공간 → VDSO → TSC 레지스터 읽기 → 보정 → 반환
                ↑
                커널 진입 없이 실행되지만
                보정 로직 때문에 여전히 비용 발생

매번 이 경로를 거치는 게 문제입니다. 쿼리 노드 처리 시간이 수십 ns 수준이면, 시간 측정 비용이 실제 처리 비용보다 클 수도 있습니다.

TIMING FALSE라는 우회로​

사실 PostgreSQL 9.2부터 이 문제의 우회 방법은 있었습니다.

EXPLAIN (ANALYZE, TIMING FALSE) SELECT * FROM large_table;

TIMING FALSE를 쓰면 시간 측정을 건너뜁니다. 실제 행 수와 루프 횟수만 보여줍니다. 오버헤드가 거의 사라집니다.

하지만 타이밍이 없으면 어느 노드가 병목인지 알 수 없습니다. 그래서 실무에서는 결국 TIMING TRUE(기본값)를 쓰게 됩니다.

pg_test_timing 유틸리티로 현재 시스템의 타이밍 오버헤드를 확인합니다.

$ pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 18.80 ns

PostgreSQL 19의 해결책: RDTSC​

PostgreSQL 19에서는 x86-64 CPU의 RDTSC (Read Time-Stamp Counter) 명령어를 활용합니다.

RDTSC란​

CPU에는 TSC(Time Stamp Counter)라는 카운터가 있습니다. CPU 클럭마다 1씩 증가하는 레지스터입니다. RDTSC 명령어는 이 카운터 값을 직접 읽습니다.

clock_gettime():  사용자 공간 → VDSO → 보정 로직 → 반환
RDTSC:            CPU 레지스터 직접 읽기 → 반환

시스템 콜도, VDSO 경유도, 보정 로직도 없습니다. CPU 명령어 하나로 끝납니다.

성능 비교​

pg_test_timing으로 측정한 결과:

200만 번 호출 기준으로 환산하면:

단일 쿼리에서 14ms라면 크지 않아 보이지만, 중첩 노드가 있거나 행 수가 더 많으면 오버헤드는 행 수와 노드 수에 비례해 커집니다.

RDTSC vs RDTSCP​

두 명령어의 차이를 알아두면 좋습니다.

RDTSC는 CPU의 비순차 실행(out-of-order execution)으로 인해 측정 순서가 살짝 뒤바뀔 수 있습니다. 하지만 EXPLAIN ANALYZE에서는 상대적인 시간 차이만 보면 되므로, 약간의 부정확함은 문제가 되지 않습니다.

PostgreSQL 19는 EXPLAIN ANALYZE에는 빠른 RDTSC를, 높은 정밀도가 필요한 다른 경우에는 RDTSCP를 사용합니다.

timing_clock_source 설정​

새로운 timing_clock_source 파라미터로 클럭 소스를 제어합니다. 허용값은 auto, system, tsc 세 가지이고 기본값은 auto입니다. superuser만 바꿀 수 있습니다.

-- 현재 설정 확인
SHOW timing_clock_source;

-- 변경 (postgresql.conf 또는 SET, superuser 전용)
SET timing_clock_source = 'auto';     -- 기본값. 지원 CPU면 TSC, 아니면 OS 시스템 클럭
SET timing_clock_source = 'tsc';      -- CPU 명령어(x86-64의 RDTSC/RDTSCP)로 측정
SET timing_clock_source = 'system';   -- OS 시스템 클럭 (기존 방식)

tsc를 선택해도 RDTSC와 RDTSCP 중 무엇을 쓸지는 PostgreSQL이 용도에 따라 정합니다. 두 명령어를 따로 고르는 값은 없습니다.

x86-64 CPU에서 해당 명령어를 지원하면 auto가 TSC 클럭 소스를 선택합니다. 오래된 x86-64 CPU나 ARM 등 다른 아키텍처에서는 기존 방식이 유지됩니다. 공식 문서는 쿼리 실행 중 이 값을 바꾸면 구간 시간이 크게 튀거나 음수가 나올 수 있다고 경고합니다.

주의사항​

x86-64 전용​

이번 최적화는 x86-64 아키텍처 전용입니다. ARM 기반 서버(AWS Graviton 등)에서는 적용되지 않습니다. 향후 ARM용 최적화도 추가될 수 있지만, 초기 릴리즈에는 포함되지 않았습니다.

TSC 신뢰성​

모든 x86-64 CPU에서 TSC가 동일하게 동작하지는 않습니다. 오래된 CPU나 가상화 환경에서는 TSC가 불안정할 수 있습니다. PostgreSQL은 TSC 지원 여부를 확인한 후 자동으로 적절한 클럭 소스를 선택합니다.

변화의 체감​

일상적인 EXPLAIN ANALYZE 사용에서 이 변화를 극적으로 체감하기는 어려울 수 있습니다. 하지만 대량 행을 처리하는 복잡한 쿼리에서는 측정 오버헤드 감소가 실행 시간 측정의 정확도를 높여준다는 점이 핵심입니다.

역사: 6년간의 논의​

이 아이디어가 처음 나온 건 2020년입니다. Andres Freund(안드레스 프로인트)가 PostgreSQL Hackers 메일링 리스트에 "Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?" 라는 제목으로 제안했습니다.

6년 동안 논의와 구현이 이어진 끝에 PostgreSQL 19에 드디어 포함되었습니다. 아이디어 자체는 단순하지만, TSC 안정성 검증, 다양한 CPU/VM 환경 호환성, 정밀도 트레이드오프 같은 세부 사항을 해결하는 데 시간이 걸렸습니다.

정리​

EXPLAIN ANALYZE를 프로덕션에서 쓰는 건 여전히 주의가 필요해요. 하지만 PostgreSQL 19부터는 측정 때문에 발생하는 노이즈가 줄어들어, 더 정확한 성능 분석이 가능해져요.

참고 자료​

• Reduced timing overhead for EXPLAIN ANALYZE with RDTSC — pganalyze
• Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? — PostgreSQL Hackers
• EXPLAIN ANALYZE may be lying to you — OnGres
• A Systems Engineer's Guide to Benchmarking with RDTSC
• Time, but Faster — ACM Queue
• PostgreSQL Documentation: EXPLAIN