또 새 기능이다​

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: 악성 MCP 서버를 통한 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 대비 13%p 향상됐습니다. 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": "enabled",
        "budget_tokens": 8192,
        "effort": "xhigh"
    },
    messages=[{"role": "user", "content": "..."}]
)

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

이 대목은 중요합니다. 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.4부터 이 문제의 우회 방법은 있었습니다.

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 파라미터로 클럭 소스를 제어할 수 있습니다.

-- 현재 설정 확인
SHOW timing_clock_source;

-- 변경 (postgresql.conf 또는 SET)
SET timing_clock_source = 'rdtsc';      -- 빠름, 약간 낮은 정밀도
SET timing_clock_source = 'rdtscp';     -- 높은 정밀도
SET timing_clock_source = 'system';     -- 기존 clock_gettime()

x86-64 CPU에서 해당 명령어를 지원하면 자동으로 RDTSC를 사용합니다. 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

PostgreSQL 19 개요​

PostgreSQL 19는 2026년 9월 출시 예정이에요. 기능 동결(Feature Freeze)은 4월 8일에 완료되었고, 5월에 첫 번째 베타가 나올 예정이에요.

PostgreSQL 18이 비동기 I/O, UUIDv7, 가상 생성 컬럼 같은 굵직한 기능을 가져왔다면, PostgreSQL 19는 기존 기능의 실질적 개선과 성능 최적화에 집중하는 릴리즈입니다. 화려하진 않지만 실무에서 체감할 수 있는 변화가 많습니다.

이 글은 2026년 4월 기준으로 작성되었으며, 정식 출시 전까지 일부 내용이 변경될 수 있습니다.

쿼리 플래너 & 실행​

GROUP BY ALL​

SELECT department, role, COUNT(*)
FROM employees
GROUP BY ALL;

GROUP BY ALL을 쓰면 집계 함수가 아닌 SELECT 표현식을 자동으로 GROUP BY에 포함합니다. 컬럼 5개를 일일이 나열할 필요가 없어졌습니다.

Eager Aggregation​

대용량 테이블을 조인하기 전에 먼저 집계하는 최적화입니다. enable_eager_aggregate 파라미터로 제어합니다.

-- 플래너가 자동으로 orders를 먼저 집계한 후 customers와 조인
SELECT c.name, SUM(o.amount)
FROM customers c JOIN orders o ON c.id = o.customer_id
GROUP BY c.name;

조인 대상 행 수가 줄어들기 때문에 대용량 분석 쿼리에서 성능이 크게 개선될 수 있습니다.

COUNT() 자동 최적화​

COUNT(1), COUNT(not_null_col)을 자동으로 COUNT(*)로 변환합니다. 습관적으로 COUNT(1)을 쓰던 사람들에게는 반가운 변화입니다.

병렬 TID Range Scan​

TID Range Scan이 병렬 실행을 지원합니다. 대규모 테이블에서 특정 범위의 물리적 행을 빠르게 스캔할 수 있습니다.

Incremental Sort 확장​

Append/MergeAppend 노드 내에서도 Incremental Sort가 가능해졌습니다. 파티션 테이블의 정렬 성능이 개선됩니다.

EXPLAIN ANALYZE 타이밍 오버헤드 감소​

x86-64 CPU에서 RDTSC 명령어를 활용해 시간 측정 오버헤드를 약 38% 줄였습니다. 이 주제는 별도 포스트에서 상세히 다룹니다.

윈도우 함수 개선​

IGNORE NULLS / RESPECT NULLS​

lag, lead, first_value, last_value, nth_value에서 NULL 처리 방식을 지정할 수 있습니다.

SELECT
  ts,
  value,
  last_value(value) IGNORE NULLS OVER (ORDER BY ts) AS last_non_null
FROM sensor_data;

시계열 데이터에서 NULL 값을 건너뛰고 마지막 유효 값을 가져오는 패턴이 훨씬 간결해졌습니다. 이전에는 서브쿼리나 래터럴 조인이 필요했습니다.

파티셔닝​

MERGE / SPLIT PARTITIONS​

-- 파티션 병합
ALTER TABLE bookings MERGE PARTITIONS (p_2024_q1, p_2024_q2) INTO p_2024_h1;

-- 파티션 분할
ALTER TABLE bookings SPLIT PARTITION p_2024 INTO
  (PARTITION p_2024_h1 FOR VALUES FROM ('2024-01-01') TO ('2024-07-01'),
   PARTITION p_2024_h2 FOR VALUES FROM ('2024-07-01') TO ('2025-01-01'));

파티션을 병합하거나 분할하는 DDL이 추가되었습니다. 기존에는 새 파티션을 만들고 데이터를 이동한 뒤 기존 파티션을 삭제해야 했습니다.

COPY TO with Partitioned Tables​

파티션 테이블에서 직접 COPY TO가 가능해졌습니다. 이전에는 각 파티션을 개별적으로 복사해야 했습니다.

논리 복제 (Logical Replication)​

WAL 레벨 동적 조정​

서버 재시작 없이 WAL 레벨을 변경할 수 있습니다. effective_wal_level 읽기 전용 파라미터로 현재 상태를 확인합니다.

이전에는 wal_level = logical 설정 변경 후 반드시 재시작이 필요했습니다. 운영 중인 시스템에서 논리 복제를 활성화할 때 다운타임을 줄일 수 있습니다.

시퀀스 복제​

논리 복제에서 시퀀스 값을 동기화할 수 있습니다.

ALTER SUBSCRIPTION my_sub REFRESH SEQUENCES;

WAIT FOR LSN​

레플리카가 특정 LSN까지 동기화될 때까지 대기하는 메커니즘입니다. 읽기 일관성이 필요한 경우에 유용합니다.

동기화 모니터링​

pg_replication_slots에 slotsync_skip_reason 컬럼이 추가되어 슬롯 동기화 지연 원인을 파악할 수 있습니다.

성능 최적화​

jsonb_agg 성능 향상​

jsonb_agg 함수의 성능이 50% 이상 개선되었습니다. JSON 집계가 많은 API 백엔드에는 반가운 변화입니다.

LISTEN/NOTIFY 최적화​

채널별 해시 테이블 기반으로 처리 방식이 변경되어, 많은 채널을 사용하는 환경에서 성능이 개선됩니다.

ICU 문자 변환 최적화​

UTF-8 데이터베이스에서 ICU 문자 변환 함수의 성능이 향상되었습니다.

Buffer Cache 알고리즘 변경​

Free buffer list를 Clock-sweep 알고리즘으로 교체했습니다.

Temporary Table 트렁케이션 고속화​

임시 테이블 truncation 처리가 빨라졌습니다.

모니터링 & 관찰성​

pg_stat_statements 확장​

• Generic/Custom 플랜별 호출 횟수 추적
• FETCH 명령어 정규화
• IN 절 파라미터 리스트 정규화

VACUUM / ANALYZE 진행 상황​

• mode, started_by 컬럼 추가로 수동/자동 실행 구분 가능
• VACUUM VERBOSE에서 메모리 사용량 표시
• vacuumdb --dry-run 옵션 추가
• log_autoanalyze_min_duration 신규 파라미터로 ANALYZE 로깅 분리

pg_buffercache 확장​

pg_buffercache_os_pages로 OS 페이지 분포를 확인할 수 있습니다.

WAL 모니터링​

wal_fpi_bytes로 Full Page Image 바이트를 추적합니다.

멀티트랜잭션 통계​

pg_get_multixact_stats() 함수로 멀티트랜잭션 사용 현황을 확인할 수 있습니다.

SQL & 함수​

random() 날짜/시간 생성​

SELECT random('2024-01-01'::date, '2024-12-31'::date);

지정 범위 내 랜덤 날짜/시간을 생성할 수 있습니다. 테스트 데이터 생성이 간편해졌습니다.

base64url 인코딩​

encode/decode 함수에서 URL-safe한 base64url 포맷을 지원합니다.

error_on_null()​

NULL 값 검증 함수가 추가되었습니다. NULL이 들어오면 에러를 발생시킵니다.

SRF(Set-Returning Function) 인라인​

Set-returning 함수의 인라인 최적화가 지원됩니다.

관리 & 도구​

regdatabase 타입​

데이터베이스 이름과 OID를 상호 변환하는 새 객체 식별자 타입입니다.

CHECKPOINT 개선​

FLUSH_UNLOGGED, MODE 파라미터가 추가되었습니다.

pg_upgrade 대용량 객체 최적화​

대용량 객체(Large Object) 마이그레이션이 빨라졌습니다.

psql 개선​

• %S 프롬프트 옵션으로 검색 경로 표시
• boolean 값 표시 커스터마이징 (\pset display_true)

pgbench​

--continue-on-error 옵션으로 에러 발생 시에도 벤치마크를 계속 진행할 수 있습니다.

그래프 쿼리 (SQL/PGQ)​

PostgreSQL 19는 SQL:2023 Part 16(SQL/PGQ) 을 코어에 들였습니다. 관계형 테이블 위에 프로퍼티 그래프 뷰를 얹고, GRAPH_TABLE과 MATCH 구문으로 그래프 패턴 매칭을 표준 SQL 안에서 풉니다. 별도 그래프 DB나 확장 없이 PostgreSQL만으로 일부 그래프 워크로드를 받아낼 수 있게 되었습니다.

첫 구현은 고정 깊이 패턴까지입니다. 가변 길이 경로는 다음 릴리스의 1차 후보입니다. 이 주제는 분량이 커서 별도 포스트에서 상세히 다룹니다.

호환성 주의​

standard_conforming_strings 비활성화 불가​

이제 standard_conforming_strings를 off로 설정할 수 없습니다. 비표준 문자열 리터럴(\' 등)은 에러를 발생시킵니다. escape_string_warning 파라미터도 제거되었습니다.

기존에 E'...' 없이 역슬래시 이스케이프를 쓰던 레거시 코드가 있다면 확인이 필요합니다.

log_lock_waits 기본값 변경​

log_lock_waits가 기본적으로 활성화됩니다. 잠금 대기 로그가 자동으로 남습니다.

마무리​

PostgreSQL 19는 눈에 띄는 신기능보다는 기존 기능의 완성도를 높이는 릴리즈입니다.

제가 개인적으로 주목하는 기능은 매일 쓰게 될 편의 기능인 GROUP BY ALL, 분석 쿼리 성능에 직접 영향을 주는 Eager Aggregation, 운영 중 논리 복제 활성화를 편하게 해주는 WAL 레벨 동적 조정이에요. IGNORE NULLS는 시계열 처리를 깔끔하게 해주고, 표준 그래프 쿼리를 코어에 들인 SQL/PGQ도 눈에 들어와요. EXPLAIN ANALYZE RDTSC는 다음 글에서, SQL/PGQ는 후속편에서 상세히 다룹니다.

2026년 9월 정식 출시가 기대되고, 5월 베타부터 미리 테스트해볼 수 있어요.

참고 자료​

• PostgreSQL 19: What's Coming — VersionLog
• PostgreSQL 19: CommitFest 2025-07 — Postgres Professional
• PostgreSQL 19: CommitFest 2025-09 — Postgres Professional
• PostgreSQL 19: CommitFest 2025-11 — Postgres Professional
• PostgreSQL 19: CommitFest 2026-01 — Postgres Professional
• PostgreSQL Roadmap

또 나왔다​

Anthropic이 자꾸 뭔가를 내놓네요.

Claude Code 데스크톱 앱이 나왔나 싶더니, 이번엔 Routines라는 기능이 2026년 4월 14일에 리서치 프리뷰로 공개됐습니다. Claude Code에서 프롬프트를 한 번 짜두면, 정해진 시간에 혹은 특정 이벤트가 발생할 때 알아서 실행되는 자동화 기능입니다.

쉽게 말하면 "AI cron job"입니다.

주의: 이 글에서 다루는 내용은 전부 리서치 프리뷰 기준입니다. API, 실행 한도, 동작 방식 모두 정식 출시 전에 바뀔 수 있습니다. "오 좋은데?" 하고 프로덕션에 넣었다가 다음 달에 스펙이 바뀌면 본인 책임입니다.

Routines가 뭔데​

루틴은 Claude에게 시킬 작업을 담은 프롬프트, 작업 대상 코드베이스인 GitHub 저장소, Slack, Linear, Google Drive 같은 외부 서비스를 잇는 MCP 커넥터를 하나로 묶습니다.

이걸 한 번 설정하면 Anthropic 클라우드 VM에서 실행됩니다. 제 노트북이 꺼져 있어도 돌아갑니다. 퇴근하고 자는 동안에도 돌아갑니다.

어떻게 실행되나​

트리거는 세 종류입니다.

하나의 루틴에 여러 트리거를 동시에 걸 수 있습니다. 예를 들면:

• 매일 밤 11시 + PR 열릴 때 + Sentry 알림 API 호출 → 같은 루틴이 세 가지 상황에서 모두 실행

활용 예시​

• 매일 밤 이슈 트래커를 읽어서 라벨 붙이고 Slack에 요약 보고
• PR 열릴 때 팀 코드 리뷰 체크리스트 자동 적용
• 에러 알림 임계값 초과 시 수정 PR 초안 자동 생성
• 배포 후 스모크 테스트 자동 실행
• 주간 스캔으로 API 변경 사항을 반영한 문서 업데이트 PR 생성

꽤 그럴듯합니다. 그럴듯한데, 아직 베타입니다. 잊지 말아야 합니다.

요금은​

• 루틴 실행은 기존 구독 사용량에 포함됩니다
• "Extra Usage" 활성화 시 한도 초과분은 추가 과금으로 계속 실행됩니다
• Free 플랜은 사용할 수 없습니다

하루 5회가 많아 보이지 않을 수 있지만, 잘 설계된 루틴 하나가 수동 작업 30분을 대체한다면 충분할 수도 있습니다.

ChatGPT Tasks랑 뭐가 다른데​

이런 류의 기능하면 ChatGPT Tasks가 먼저 떠오를 수 있습니다. 근데 성격이 꽤 다릅니다.

ChatGPT Tasks는 "내일 아침에 이거 확인해"라고 알려주는 알람 앱입니다. Claude Routines는 "내일 아침에 이거 확인하고 PR까지 만들어놓을게"라고 하는 자동화 에이전트입니다.

방향 자체가 다릅니다.

좋은 점​

알림만 보내는 데 그치지 않고 코드 수정, PR 생성, Slack 메시지까지 실제로 수행하는 진짜 자동화입니다. 스케줄, API, GitHub 이벤트를 하나의 루틴에 동시에 설정하는 다중 트리거도 지원합니다. 클라우드 실행이라 로컬 머신에 의존하지 않습니다. 퇴근해도 돌아갑니다. MCP 커넥터에는 Slack, Linear, Google Drive 등 외부 서비스 연동 기능이 내장되어 있습니다.

우려되는 점​

여기서부터가 진짜 중요합니다.

리서치 프리뷰라는 것​

정식 출시가 아닙니다. API 스펙, 실행 한도, 트리거 동작 방식 전부 바뀔 수 있습니다. Anthropic도 공식 문서에서 이 점을 명시하고 있습니다. 프로덕션 워크플로우에 넣기에는 이릅니다.

개인 계정에 묶인다​

루틴은 개인 claude.ai 계정에 귀속됩니다. 팀원과 공유할 수 없고, 루틴이 만든 커밋/PR은 해당 개인 이름으로 찍힙니다. 팀 단위 운영이 어렵습니다.

보안 이슈​

자율 실행 중 문서에 숨겨진 악성 지시를 따를 수 있는 프롬프트 인젝션 위험이 있습니다. Anthropic 자체 보고로 공격 성공률은 ~1%입니다. CVE 2건도 보고됐습니다. RCE 취약점(CVE-2025-59536)과 API 키 유출(CVE-2026-21852)입니다. 데이터 학습의 경우 Pro/Max 플랜은 AI 학습을 위한 데이터 사용이 기본 ON이고, Enterprise만 OFF입니다.

벤더 락인​

루틴 설정이 Anthropic 클라우드에 저장됩니다. git에 백업되지 않습니다. 나중에 다른 도구로 갈아타고 싶어도 이식할 방법이 없습니다.

사내에서 쓸 수 있을까​

솔직히 말하면, 지금 당장 프로덕션에 넣기는 이르다고 봐요.

가능한 부분​

• Team/Enterprise 플랜에서 사용 가능
• SOC 2 Type 2, ISO 27001 인증 있음
• Enterprise는 클라우드 세션 감사 로그 지원
• 네트워크 프록시로 개인 계정 차단 가능 (Enterprise)

아직 안 되는 부분​

현실적 접근법​

먼저 Team 플랜으로 파일럿을 진행합니다. 비규제, 비프로덕션 환경에서 테스트하는 방식입니다.

MCP 커넥터는 제한해야 합니다. 읽기 전용이면서 관리자가 승인한 것만 허용합니다.

정식 출시를 기다리는 방법도 있습니다. GA 후 Enterprise 세일즈와 감사 로그/권한 제어를 확인합니다.

규제 데이터는 금지합니다. PII, 금융, 의료 데이터에는 절대 사용하지 않습니다.

마무리​

Anthropic이 정말 쉬지 않고 무언가를 내놓고 있습니다. Subagents가 나왔나 싶더니 Agent Teams가 나오고, 이제는 Routines까지 나왔습니다. 따라가는 것만으로도 바쁩니다.

Routines의 컨셉 자체는 매력적입니다. "AI가 밤새 일한다"는 말이 과장이 아닌 시대가 정말 오고 있습니다. 하지만 지금은 리서치 프리뷰입니다. 흥미롭게 지켜보되, 프로덕션에 넣는 것은 아직 참아야 합니다.

한 가지 확실한 건, AI 도구의 변화 속도가 이전과는 차원이 다르다는 거예요. 정신 차리고 따라가야 해요. 아니면 어느 날 제 자리에서 루틴이 일하고 있을지도 모르겠어요.

이 글의 내용은 2026년 4월 16일 기준 리서치 프리뷰 상태를 바탕으로 작성되었습니다. 정식 출시 후 기능, 요금, 제한 사항이 달라질 수 있습니다.

참고 자료​

• Automate work with routines — Claude Code Docs
• Introducing routines in Claude Code — Anthropic Blog
• Security — Claude Code Docs
• Claude Code routines promise mildly clever cron jobs — The Register
• Claude Code Routines: Automate Dev Workflows — DEV Community

Claude Code 단축키 도움말 화면​

Claude Code에서 ?를 누르면 볼 수 있는 단축키 요약 화면이에요.

이 화면에 나오는 것들을 하나씩 풀어서 정리해보겠습니다.

단축키를 왜 알아야 하나​

Claude Code를 터미널에서 쓰다 보면, 마우스 없이 모든 걸 해결해야 하는 순간이 옵니다. 긴 프롬프트를 수정하고, 실행을 취소하고, 모델을 바꾸고, 히스토리를 뒤지는 일이 전부 키보드로 가능합니다.

문제는 단축키가 꽤 많다는 점입니다. 전부 외울 필요는 없습니다. 이 글에서는 매일 쓰게 되는 것만 추렸습니다.

이 시리즈는 3편으로 구성됩니다.

• 1편: 필수 단축키 (이 글)
• 2편: Vim 모드
• 3편: 커스터마이징 & 세부 컨텍스트

macOS 터미널 설정부터​

시작하기 전에 하나 짚고 가겠습니다. macOS에서 Option(Alt) 키 조합이 안 먹히는 경우가 많습니다. 터미널 설정을 먼저 바꿔야 합니다.

이걸 안 하면 Option+P, Option+T 같은 단축키가 특수문자만 입력됩니다. 꼭 먼저 설정해야 합니다.

일반 제어​

가장 자주 쓰는 기본 조작입니다.

히스토리 검색 모드 (Ctrl+R 이후)​

히스토리 검색에 진입하면 쓸 수 있는 키가 따로 있습니다.

텍스트 편집​

프롬프트가 길어질수록 이 단축키들이 빛을 발합니다.

Ctrl+K로 지우고 Ctrl+Y로 붙여넣는 조합은 터미널의 킬 링(kill ring)과 같은 원리입니다. 익숙해지면 마우스 드래그보다 빠릅니다.

멀티라인 입력​

Claude Code에서 한 줄짜리 프롬프트만 쓰지는 않습니다. 여러 줄 입력하는 방법을 알아두어야 합니다.

VS Code, Alacritty, Zed, Warp 터미널에서 Shift+Enter를 쓰려면 /terminal-setup을 실행해서 바인딩을 설치해야 합니다.

또 하나 유용한 단축키가 있습니다.

프롬프트가 정말 길어지면 터미널에서 편집하는 게 고역입니다. 이 단축키를 누르면 기본 에디터(보통 vim이나 nano)가 열리고, 거기서 편하게 작성할 수 있습니다. 저장하고 나오면 바로 입력됩니다.

모드와 모델 전환​

Claude Code를 쓰다가 모델을 바꾸거나 모드를 전환하고 싶을 때는 명령어를 칠 필요가 없습니다.

Windows/Linux에서는 Option 대신 Alt를 사용합니다.

Shift+Tab은 특히 자주 씁니다. 코드 수정이 맘에 안 들면 plan 모드로 바꿔서 계획을 먼저 세우게 하고, 빠르게 진행하고 싶으면 auto로 전환하는 식입니다.

입력 프리픽스​

프롬프트 첫 글자에 따라 동작이 달라집니다.

!은 Claude에게 시키지 않고 직접 셸 명령을 실행할 때 씁니다. git status 같은 단순 확인을 AI한테 시키면 아깝습니다.

프롬프트 제안​

Claude Code가 회색 텍스트로 다음 입력을 제안할 때가 있습니다.

이미지 붙여넣기​

스크린샷이나 이미지를 Claude에게 보여줘야 할 때도 있습니다.

붙여넣으면 [Image #N] 형태로 입력창에 표시됩니다.

확인/권한 다이얼로그​

Claude가 파일을 수정하거나 명령을 실행하려 할 때 나오는 확인 창에서 쓸 수 있는 키입니다.

한눈에 보기​

마지막으로 매일 쓰는 것만 골라서 한 장에 정리했습니다.

[일반]
Ctrl+C .......... 취소
Ctrl+D .......... 종료
Ctrl+L .......... 입력 지우기
Ctrl+R .......... 히스토리 검색
Esc × 2 ........ 되감기

[편집]
Ctrl+K .......... 줄 끝까지 삭제
Ctrl+U .......... 줄 시작까지 삭제
Ctrl+Y .......... 붙여넣기 (킬 링)
Alt+B / Alt+F ... 단어 단위 이동
Ctrl+J .......... 줄바꿈

[전환]
Shift+Tab ....... 권한 모드 순환
Option+P ........ 모델 전환
Option+T ........ 사고 모드 토글
Option+O ........ Fast 모드 토글

[입력]
/ ............... 명령 메뉴
! ............... 셸 실행
@ ............... 파일 자동완성

다음 편 예고​

2편에서는 Claude Code의 Vim 모드를 다뤄요. /config에서 활성화하면 Normal/Insert 모드 전환, h/j/k/l 내비게이션, 텍스트 오브젝트까지 전부 쓸 수 있어요. Vim 사용자라면 기대해도 좋아요.

이 글은 2026년 4월 기준 Claude Code v2.1.x 기준으로 작성되었습니다. 버전에 따라 단축키가 다를 수 있습니다. ?를 눌러 현재 환경의 단축키를 확인할 수 있습니다.

참고 자료​

• Interactive mode — Claude Code Docs
• Customize keyboard shortcuts — Claude Code Docs

여기까지 왔다면​

1편에서 필수 단축키를, 2편에서 Vim 모드를 다뤘어요. 3편에서는 키 바인딩 커스터마이징과 특정 화면에서만 쓰는 세부 컨텍스트 단축키를 정리해요.

이 시리즈는 3편으로 구성됩니다.

• 1편: 필수 단축키
• 2편: Vim 모드
• 3편: 커스터마이징 & 세부 컨텍스트 (이 글)

키 바인딩 커스터마이징​

설정 파일 열기​

Claude Code 안에서 /keybindings를 입력하면 ~/.claude/keybindings.json 파일이 열립니다. 없으면 자동 생성됩니다. 변경 사항은 재시작 없이 즉시 적용됩니다.

설정 형식​

[
  {
    "key": "ctrl+enter",
    "command": "chat:submit",
    "when": "Chat"
  },
  {
    "key": "ctrl+shift+k",
    "command": "chat:clearInput",
    "when": "Global"
  }
]

• key: 키 조합 (ctrl, alt, shift, meta + 키)
• command: namespace:action 형식의 액션 이름
• when: 적용 컨텍스트

바인딩 해제​

특정 단축키를 비활성화하려면 command를 null로 설정합니다.

[
  {
    "key": "ctrl+s",
    "command": null,
    "when": "Chat"
  }
]

사용 가능한 컨텍스트​

바인딩 불가 키​

다음 키는 터미널 수준에서 예약되어 있어 변경할 수 없습니다.

설정 검증​

/doctor

키 바인딩 설정에 문제가 있으면 /doctor에서 확인할 수 있습니다.

트랜스크립트 뷰어​

Ctrl+O로 트랜스크립트 뷰어를 열면, Claude가 어떤 도구를 실행했는지 상세하게 볼 수 있습니다. MCP 호출 내용도 여기서 확인 가능합니다.

풀스크린 모드에서 Ctrl+O를 반복하면 normal → transcript → focus view 순서로 전환됩니다.

디프 뷰어​

Claude가 파일을 수정했을 때 나오는 디프 화면에서 쓸 수 있는 키입니다.

되감기 / 요약 (메시지 선택)​

Esc × 2로 진입하는 메시지 선택 화면의 단축키입니다.

Vim 스타일의 J/K 이동도 지원하는 점이 눈에 띕니다.

스크롤 / 풀스크린 모드​

풀스크린 렌더링이 활성화된 상태에서 사용 가능합니다.

이미지 첨부 내비게이션​

이미지를 여러 장 붙여넣은 후 관리할 때 씁니다.

하단 바 (Footer)​

PR 상태, 태스크 등이 표시되는 하단 바에서 쓸 수 있는 키입니다.

설정 화면​

/config로 진입하는 설정 화면의 단축키입니다.

모델 선택​

Option+P로 모델 선택 화면에 진입하면 다음 단축키를 쓸 수 있습니다.

플러그인 관리자​

터미널 멀티플렉서 충돌​

tmux나 screen을 쓰고 있다면 일부 단축키가 충돌할 수 있습니다.

tmux 사용자는 Ctrl+B를 백그라운드 전환에 쓸 때 항상 두 번 눌러야 한다는 것만 기억하면 됩니다.

한눈에 보기: 커스터마이징 요약​

[키 바인딩]
/keybindings .... 설정 파일 열기
/doctor ......... 설정 검증
재시작 불필요 .... 변경 즉시 적용

[트랜스크립트 뷰어] (Ctrl+O)
/ ............... 검색
n / N ........... 다음/이전 결과
Ctrl+E .......... 전체 펼치기
q ............... 닫기

[디프 뷰어]
← / → .......... 디프 소스 전환
↑ / ↓ .......... 파일 전환
Esc ............. 닫기

[되감기] (Esc × 2)
J / K ........... 위/아래 이동
Enter ........... 선택

[주의: 멀티플렉서]
Ctrl+B .......... tmux와 충돌 (두 번 누르기)
Ctrl+A .......... screen과 충돌 (두 번 누르기)

시리즈를 마치며​

3편에 걸쳐 Claude Code의 단축키를 정리했습니다. 솔직히 전부 외울 필요는 없습니다. 1편의 필수 단축키만 익혀도 충분하고, 나머지는 필요할 때 이 글을 찾아보면 됩니다.

한 가지 팁을 남기자면, Claude Code 안에서 ?를 누르면 현재 환경에서 쓸 수 있는 단축키가 바로 나옵니다. 이 글보다 그게 더 빠를 수 있습니다.

이 글은 2026년 4월 기준 Claude Code v2.1.x 기준으로 작성했어요. /keybindings 커스터마이징은 v2.1.18 이상이 필요해요.

참고 자료​

• Interactive mode — Claude Code Docs
• Customize keyboard shortcuts — Claude Code Docs

Claude Code에 Vim이 있다고?​

있어요. /config에서 에디터 모드를 Vim으로 바꾸면 돼요. 그 순간부터 Claude Code의 입력창이 Vim처럼 동작해요.

Normal 모드와 Insert 모드가 분리되고, h/j/k/l로 이동하고, dd로 줄을 지우고, ciw로 단어를 바꿀 수 있습니다. Vim 사용자라면 손에 익은 그대로입니다.

이 시리즈는 3편으로 구성됩니다.

• 1편: 필수 단축키
• 2편: Vim 모드 (이 글)
• 3편: 커스터마이징 & 세부 컨텍스트

활성화 방법​

Claude Code 실행 후 /config를 입력하고, Editor mode를 Vim으로 변경합니다. 별도 설치나 플러그인은 필요 없습니다.

참고로 Vim 모드와 일반 키 바인딩은 독립적으로 동작합니다. Vim 모드를 켜도 Ctrl+C, Ctrl+R 같은 일반 단축키는 그대로 쓸 수 있습니다.

모드 전환​

Vim의 핵심은 모드입니다. Claude Code에서도 동일하게 적용됩니다.

Insert → Normal​

Normal → Insert​

Vim을 써본 적이 있다면 완전히 같은 동작입니다. 처음이라면 i로 입력하고 Esc로 나온다는 것만 기억하면 됩니다.

내비게이션 (Normal 모드)​

기본 이동​

화살표 키도 동작하지만, Vim을 쓰는 이유는 홈 로우에서 손을 떼지 않는 데 있지 않습니까.

단어 단위 이동​

줄 단위 이동​

전체 이동​

문자 점프​

예를 들어 f=을 누르면 커서가 다음 = 문자로 점프합니다. ;을 누르면 그다음 =으로 계속 이동합니다. 긴 프롬프트에서 특정 위치를 빠르게 찾을 때 유용합니다.

히스토리 탐색​

커서가 더 이상 이동할 수 없는 경계에 도달하면 명령어 히스토리를 탐색합니다.

편집 (Normal 모드)​

삭제​

변경 (삭제 후 Insert 모드 진입)​

d는 삭제만 하고 Normal 모드에 남습니다. c는 삭제 후 바로 Insert 모드로 전환됩니다. 뭔가를 지우고 바로 다시 타이핑하려면 c 계열이 키 입력을 한 번 줄여줍니다.

복사 & 붙여넣기​

기타 편집​

.은 꽤 강력합니다. cw로 단어를 바꾼 뒤 .을 누르면 같은 동작을 반복하므로, 여러 곳에서 같은 수정을 할 때 시간을 아낄 수 있습니다.

텍스트 오브젝트​

Vim의 진짜 힘은 텍스트 오브젝트에 있습니다. d, c, y 같은 오퍼레이터와 조합해 사용합니다.

단어​

괄호 / 따옴표​

실전 조합 예시​

예를 들어 프롬프트에 "이전 파일을 수정해줘"라고 적었는데 따옴표 안의 내용만 바꾸고 싶다면, 따옴표 안에 커서를 두고 ci"를 누르면 됩니다. 따옴표 안의 텍스트가 지워지면서 바로 새 내용을 입력할 수 있습니다.

Normal 모드에서 도움말​

Vim 모드에서 Normal 모드일 때 ?를 누르면 현재 환경에서 사용 가능한 단축키 목록을 볼 수 있습니다.

한눈에 보기​

[모드 전환]
Esc ............. Normal 모드
i / a ........... Insert 모드 (앞/뒤)
I / A ........... Insert 모드 (줄 시작/끝)
o / O ........... 새 줄 열기 (아래/위)

[이동]
h/j/k/l ........ 좌/하/상/우
w / e / b ...... 단어 (시작/끝/이전)
0 / $ / ^ ...... 줄 (맨앞/맨뒤/첫글자)
gg / G ......... 전체 (처음/끝)
f{c} / t{c} .... 문자 점프

[편집]
x .............. 문자 삭제
dd / D ......... 줄 삭제 / 줄끝까지
cc / C ......... 줄 변경 / 줄끝까지
yy / p / P ..... 복사 / 붙여넣기
. .............. 마지막 편집 반복

[텍스트 오브젝트]
ciw ............ 단어 변경
di" ............ 따옴표 안 삭제
ci( ............ 괄호 안 변경
ya{ ............ 중괄호 포함 복사

다음 편 예고​

3편에서는 커스터마이징과 세부 컨텍스트 단축키를 다뤄요. keybindings.json으로 키를 재설정하는 방법, Transcript Viewer, Diff Viewer, 스크롤 모드 등 특정 상황에서만 쓰는 단축키를 정리할게요.

이 글은 2026년 4월 기준 Claude Code v2.1.x 기준으로 작성되었습니다. Vim 모드는 /config → Editor mode에서 활성화할 수 있습니다.

참고 자료​

• Interactive mode — Claude Code Docs
• Customize keyboard shortcuts — Claude Code Docs

이 글은 Vim 단축키 시리즈의 두 번째 글이에요.

1. Vi/Vim 단축키 종합 가이드: 기본부터 실전까지
2. Neovim 단축키 가이드: Vim을 넘어서는 기능들 ← 현재 글

Vi와 뭐가 다른가​

1편에서 다룬 단축키는 Vi/Vim 어디서든 동작하는 보편적인 키입니다. 이 글에서는 Neovim에서만 쓸 수 있는 기능들을 다룹니다.

Neovim이 Vim 위에 추가하는 것:

Neovim에는 플러그인 없이 코드 분석, 정의 이동, 자동완성을 지원하는 내장 LSP가 있습니다. 내장 터미널에서는 에디터 안에서 셸을 실행합니다. Lua 설정으로 Vimscript 대신 Lua를 사용해 설정과 플러그인을 구성하며, 플러그인 생태계에는 Telescope, Treesitter, LSP 기반 플러그인 등이 있습니다.

아래 단축키 중 <leader> 키가 나오면, 대부분의 Neovim 설정에서 Space로 매핑되어 있습니다.

내장 LSP 단축키​

LSP(Language Server Protocol)를 설정하면 IDE 수준의 코드 내비게이션이 가능해집니다.

코드 내비게이션​

gd로 이동한 후 Ctrl-o를 누르면 이전 위치로 돌아옵니다.

코드 액션​

진단 (Diagnostics)​

자동완성​

시그니처 도움말​

함수 호출 시 인자를 입력하는 중에 Ctrl-k를 누르면 파라미터 정보가 표시됩니다.

내장 터미널​

Neovim 안에서 셸을 실행합니다.

기본 사용​

터미널 모드 키​

터미널에서 Normal 모드로 돌아오면 출력 내용을 Vim 명령으로 검색하거나 복사할 수 있게 됩니다.

분할 터미널 워크플로우​

+------------------+------------------+
| Code (Neovim)    | Terminal (shell) |
|                  |                  |
+------------------+------------------+

코드를 편집하면서 옆 터미널에서 빌드/테스트를 실행합니다. Ctrl-w l로 터미널로 이동하고, Ctrl-w h로 코드로 복귀합니다.

플로팅 터미널: 많은 설정에서 Ctrl-; 또는 <leader>t로 플로팅 터미널을 토글합니다. 화면을 많이 가리지 않으면서 빠르게 명령을 실행하는 데 유용합니다.

마우스 활용​

Neovim에서 mouse=a 설정을 켜면 마우스를 활용할 수 있게 됩니다.

기본 동작​

마우스 + 키보드 하이브리드​

마우스로 선택한 후 키보드로 조작:

1. 마우스 드래그로 영역 선택  (Visual 모드 진입)
2. d, c, y 등 키보드 명령 실행

예: 마우스로 코드 블록을 드래그 선택 → > (들여쓰기), y (복사), d (삭제)

언제 마우스를 쓰는가​

키보드가 더 빠른 경우는 다음과 같습니다.

• 같은 줄 내 이동 (f, w, 0, $)
• 구조적 선택 (ci", vi{, vap)
• 반복 작업 (., 매크로)

마우스는 화면에 보이는 임의의 위치로 먼 거리 점프를 하거나, 여기저기 클릭하며 코드 리뷰를 하거나, 단어나 괄호 경계와 무관하게 비구조적 선택을 할 때 더 빠릅니다.

키보드 순수주의에 집착할 필요는 없습니다. 상황에 따라 둘 다 사용하면 됩니다.

필수 플러그인 단축키​

Neovim 생태계의 핵심 플러그인들과 주요 단축키를 정리합니다.

Telescope​

퍼지 파인더로 파일과 텍스트, 버퍼, 도움말 태그를 검색합니다.

Telescope 창 안에서:

Neo-tree​

파일 트리를 제공하는 탐색기입니다.

Neo-tree 안에서:

Comment.nvim​

언어에 맞는 주석을 간편하게 적용합니다.

Vim의 Ctrl-v → I → // 방식보다 훨씬 간편합니다. 언어별 주석 형식도 자동 감지합니다.

nvim-surround​

텍스트를 원하는 문자로 감싸거나 기존 감싸기를 변경하고 삭제합니다.

Surround 문법:

ys + iw + "   →  단어를 "로 감싸기
ys + ap + {   →  문단을 {로 감싸기
cs + " + '    →  "를 '로 변경
ds + (        →  (를 삭제

이것도 동사(ys/cs/ds) + 명사(motion/text object) + 감싸기 문자의 문법입니다.

Flash / Hop​

현재 화면 안에서 원하는 위치로 빠르게 이동합니다.

화면에 보이는 위치로 2-3번의 키 입력만으로 이동합니다. f/t는 같은 줄로 제한되지만, Flash는 화면 전체에서 동작합니다.

Gitsigns​

Git 변경 사항을 표시하고 hunk 단위 작업을 지원합니다.

Which-key​

사용할 수 있는 키를 팝업으로 안내합니다.

단축키가 기억나지 않을 때 <leader>만 누르고 기다리면 됩니다. 어떤 키가 어떤 기능인지 팝업으로 보여줍니다.

Leader 키와 커스텀 매핑 전략​

Space를 Leader로 쓰는 이유​

vim.g.mapleader = " "

• 양손 어디서든 누르기 쉬운 위치
• 기본적으로 Normal 모드에서 Space는 l과 같은 동작(쓸모 없음)
• Neovim 커뮤니티의 사실상 표준

네이밍 규칙​

잘 만들어진 설정에서는 Leader 뒤의 키가 일관된 체계를 따릅니다.

자주 쓰는 커스텀 매핑​

-- 저장
vim.keymap.set("n", "<leader>w", ":w<CR>")

-- 창 이동 (Ctrl-h/j/k/l)
vim.keymap.set("n", "<C-h>", "<C-w>h")
vim.keymap.set("n", "<C-j>", "<C-w>j")
vim.keymap.set("n", "<C-k>", "<C-w>k")
vim.keymap.set("n", "<C-l>", "<C-w>l")

-- Visual 모드에서 들여쓰기 후 선택 유지
vim.keymap.set("v", "<", "<gv")
vim.keymap.set("v", ">", ">gv")

-- 줄 이동
vim.keymap.set("v", "J", ":m '>+1<CR>gv=gv")
vim.keymap.set("v", "K", ":m '<-2<CR>gv=gv")

-- 검색 하이라이트 제거
vim.keymap.set("n", "<leader>h", ":nohlsearch<CR>")

-- 시스템 클립보드 복사
vim.keymap.set({"n", "v"}, "<leader>y", '"+y')

마지막 <gv / >gv 매핑은 특히 유용합니다. 기본 Vim에서는 >로 들여쓰기하면 Visual 선택이 해제되지만, 이 매핑을 쓰면 선택이 유지되어 연속으로 > >를 누를 수 있습니다.

클립보드 연동​

기본 사용​

"+y     → 시스템 클립보드에 복사
"+p     → 시스템 클립보드에서 붙여넣기

매번 "+를 치기 귀찮다면 설정에서:

vim.opt.clipboard = "unnamedplus"

이렇게 하면 y/p가 바로 시스템 클립보드를 사용합니다.

SSH 원격에서 클립보드​

SSH로 접속한 서버의 Neovim에서 복사한 텍스트를 로컬 클립보드로 보내려면 OSC 52를 지원하는 터미널이 필요합니다.

지원 터미널: iTerm2, WezTerm, Alacritty, kitty, Windows Terminal

Neovim 0.10+에서는 OSC 52가 기본 지원됩니다. 별도 설정 없이 "+y로 SSH 환경에서도 로컬 클립보드에 복사합니다.

Neovim 전용 편의 기능​

명령/검색 히스토리 윈도우​

일반 : 프롬프트와 달리, Vim 명령(검색, 편집, 이동)으로 이전 명령을 수정해 실행합니다. 긴 치환 명령을 재사용할 때 유용합니다.

q:를 실수로 눌렀다면 :q로 닫습니다.

inccommand​

치환 결과를 실시간으로 미리 보여주는 기능입니다.

vim.opt.inccommand = "split"

:s/old/new/g를 입력하는 동안 실시간으로 변경 결과를 미리 보여줍니다. 정규식이 맞는지 실행 전에 확인할 수 있습니다.

"split"으로 설정하면 화면 하단에 변경될 줄 목록이 표시됩니다. "nosplit"이면 본문에서 직접 하이라이트합니다.

:lua 직접 실행​

:lua print(vim.fn.expand("%"))     " 현재 파일 경로
:lua print(vim.opt.tabstop:get())  " 탭 크기
:lua vim.lsp.buf.format()          " LSP 포맷팅

설정을 바꾸거나 디버깅할 때 Lua 코드를 즉시 실행할 수 있다는 점도 유용합니다.

내장 diff 모드​

nvim -d file1.txt file2.txt

또는 이미 열린 상태에서:

:diffthis                " 현재 윈도우를 diff에 포함
:diffoff                 " diff 모드 해제
]c / [c                  " 다음/이전 변경으로 이동
do                       " diff obtain — 반대쪽 변경 가져오기
dp                       " diff put — 이쪽 변경 보내기

단축키 디버깅​

단축키가 안 먹히거나 예상과 다르게 동작할 때:

매핑 확인​

:map <leader>f           " <leader>f에 뭐가 매핑되어 있는지
:nmap                    " Normal 모드 매핑 전체 목록
:imap                    " Insert 모드 매핑 전체
:vmap                    " Visual 모드 매핑 전체
:verbose map <leader>f   " 어떤 파일에서 매핑했는지까지 표시

:verbose가 특히 중요합니다. 키 충돌이 생겼을 때 어떤 플러그인이 해당 키를 가져갔는지 바로 확인합니다.

Which-key 활용​

Which-key 플러그인이 설치되어 있다면 <leader>를 누르고 기다리면 모든 매핑이 시각화됩니다. 키 충돌이 있으면 같은 접두사에 두 개 이상의 매핑이 보입니다.

키가 안 먹힐 때 체크리스트​

1. :verbose map <key>로 다른 플러그인이 덮어쓰지 않았는지 확인
2. 올바른 모드인지 확인 (nmap vs imap vs vmap)
3. Leader 키가 제대로 설정되었는지: :echo mapleader
4. 플러그인이 로드되었는지: :Lazy check (lazy.nvim 사용 시)

마치며​

Neovim은 Vim의 편집 철학 위에 현대적인 기능을 더해요. LSP는 IDE 수준의 코드 내비게이션을 제공하고, 내장 터미널은 에디터 밖을 나가지 않는 워크플로우를 만들며, 플러그인은 기능을 폭넓게 확장해요.

다음 순서로 익히기를 권합니다.

1. 1편의 Vim 기본을 먼저 익힙니다
2. LSP 단축키(gd, K, gr)를 자주 쓰면서 습관을 만듭니다
3. Telescope(<leader>ff/fg)를 파일 탐색의 기본으로 삼습니다
4. Comment(gcc), Surround(ys/cs/ds)를 익힙니다
5. 나머지는 필요할 때 하나씩 추가합니다

한 번에 다 외우려 하지 말고, 매일 하나씩 새로운 키를 시도해보세요.

참고 자료​

• Neovim 공식 문서
• Vim Cheat Sheet
• Vim Adventures — 키 학습 게임
• Neovim 시리즈 — 입문, 중급, 고급, 내 설정