내 손에 맞게 길들이기

슬래시 커맨드 — 자주 쓰는 부탁을 단축어로

매번 “이 코드 리뷰해줘, 보안 문제랑 성능 문제 위주로 봐줘”라고 길게 타이핑하고 있다면, 그 부탁을 /리뷰 한 단어로 줄일 수 있다.

전화기의 단축 다이얼과 같다. 자주 거는 번호를 버튼 하나에 저장해 두는 것뿐이다.

슬래시 커맨드는 자주 쓰는 지시문을 미리 파일로 저장해 두고, 채팅창에 /이름만 쳐서 불러내는 기능이다. 클로드 코드에는 /clear, /help처럼 기본으로 들어 있는 커맨드도 있지만, 진짜 가치는 내가 직접 만드는 커맨드에 있다.

만드는 법은 허무할 만큼 간단하다. 약속된 폴더에 마크다운 파일 하나를 두면, 그 파일 이름이 곧 명령어가 된다.

파일 하나가 명령어 하나

프로젝트 폴더 안에 .claude/commands/ 폴더를 만들고, 거기에 리뷰.md 파일을 두면 끝이다. 그 안에 적은 내용이 바로 그 커맨드가 실행할 지시문이 된다.

# 파일 내용 (이게 곧 명령어의 지시문이 된다)
아래 코드를 리뷰해줘.
- 보안 취약점을 최우선으로 본다
- 그다음 성능, 마지막으로 가독성
- 발견한 문제는 심각도(상/중/하)로 표시

# 이제 채팅창에서는 이렇게만 치면 된다
❯ /리뷰

파일 안에 $ARGUMENTS라고 적어 두면, 커맨드 뒤에 붙인 말이 그 자리에 끼워진다. /리뷰 결제모듈이라고 치면 ‘결제모듈’이 지시문 안으로 들어가는 식이다.

내가 자주 쓰는 지시를 슬래시 커맨드로 만들어줘.
- 커맨드 이름: /리뷰
- 하는 일: 코드를 보안 → 성능 → 가독성 순으로 점검하고
  발견한 문제를 심각도(상/중/하)로 정리
- .claude/commands/ 폴더에 마크다운 파일로 저장해줘
- 커맨드 뒤에 붙인 대상($ARGUMENTS)을 리뷰 범위로 쓰게 해줘

훅이란 무엇인가

슬래시 커맨드가 ‘내가 부를 때 도는’ 기능이라면, 훅은 ‘부르지 않아도 알아서 끼어드는’ 기능이다.

사무실 출입문에 달린 자동 센서를 떠올리면 된다. 누가 들어오고 나갈 때마다, 시키지 않아도 불이 켜지고 기록이 남는다.

훅(hook)은 에이전트가 작업하는 흐름의 정해진 길목에 미리 걸어 두는 자동 동작이다. 에이전트가 도구를 쓰기 직전, 다 쓴 직후, 답을 마쳤을 때처럼 정해진 순간이 오면 내가 등록해 둔 명령이 자동으로 실행된다.

핵심은 ‘언제’다. 훅은 아무 때나 끼어들지 않는다. 작업의 생명주기에는 몇 개의 정해진 길목이 있고, 훅은 그 길목 중 어디에 설 것인지를 골라 거는 것이다.

훅이 설 수 있는 대표적인 길목

• 도구 실행 직전. 에이전트가 파일을 고치거나 명령을 돌리기 직전. 위험한 작업을 미리 막거나, “정말 할 거냐”고 한 번 거를 수 있는 자리다.
• 도구 실행 직후. 파일을 고친 바로 다음. 자동으로 포맷을 맞추거나, 테스트를 돌리거나, 바뀐 내용을 기록하기 좋은 자리다.
• 답변을 마쳤을 때. 에이전트가 한 차례 일을 끝냈을 때. 완료 알림을 보내거나 결과를 요약해 남기는 자리다.

왜 굳이 자동화할까. 사람은 잊어버리기 때문이다. “코드 고치면 꼭 포맷 맞춰라”를 매번 손으로 챙기는 대신, 한 번 훅으로 걸어 두면 다시는 잊을 일이 없다.

훅(hook)

작업 흐름의 정해진 길목에 걸어 두는 자동 동작. 그 순간이 오면 시키지 않아도 실행된다.

생명주기(lifecycle)

에이전트가 한 작업을 처리하는 동안 거치는 정해진 단계들. 훅은 이 단계 사이에 끼어든다.

이벤트(event)

‘도구 실행 직전’처럼 훅이 반응하는 특정 순간. 어떤 이벤트에 걸지를 내가 고른다.

훅 실습 — 작업 후 자동 알림

긴 작업을 시켜 놓고 다른 일을 하다 보면, 에이전트가 언제 끝났는지 모르고 한참 뒤에야 화면을 들여다보게 된다. 끝나는 순간 소리 한 번 울리게 만들어 보자.

가장 짧고, 가장 자주 쓰게 되는 첫 훅이다.

훅은 settings.json이라는 설정 파일에 등록한다. “어떤 이벤트에, 어떤 명령을 실행할지”를 적어 두는 곳이다. 직접 손으로 써도 되지만, 형식이 낯설면 에이전트에게 만들어 달라고 시키는 편이 빠르고 안전하다.

설정 파일에 등록하는 모습

아래는 ‘에이전트가 답변을 마쳤을 때(Stop) 알림음을 한 번 울려라’를 등록한 모습이다. 형식을 외울 필요는 없다. 어떤 모양인지 눈에 익히는 것으로 충분하다.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command",
            "command": "afplay /System/Library/Sounds/Glass.aiff" }
        ]
      }
    ]
  }
}

작업이 끝났을 때 알림이 울리게 훅을 걸어줘.
- 에이전트가 답변을 마치는 순간(Stop)에 실행
- 내 운영체제에 맞는 소리 재생 명령을 골라줘
- .claude/settings.json에 등록하고, 어떤 줄을 추가했는지 설명해줘
- 끄고 싶을 때 어떻게 지우는지도 알려줘

권한과 settings

1모듈에서 본 ‘위험도 사다리’ — 읽기는 자유, 쓰기는 승인, 삭제는 신중 — 그 사다리를 실제 규칙으로 굳히는 곳이 바로 권한 설정이다.

법인카드와 같다. 한도와 사용처를 미리 정해 두면, 매번 결재를 올리지 않아도 안심하고 맡길 수 있다.

에이전트는 강력한 만큼 위험하다. 시키면 망설임 없이 파일을 지우고 명령을 실행한다. 그래서 “무엇은 마음대로 해도 되고, 무엇은 나에게 물어봐야 하며, 무엇은 절대 안 되는지”를 미리 정해 두는 장치가 권한이다.

권한은 네 계층으로 나뉜다

권한은 단순히 ‘된다/안 된다’의 이분법이 아니다. 네 단계로 나뉘고, 이 네 계층을 이해하면 나머지는 응용일 뿐이다.

• 허용(allow). 묻지 않고 그냥 실행한다. 읽기나 파일 목록 보기처럼 되돌릴 필요가 없는 안전한 작업을 여기에 둔다.
• 확인(ask). 실행 전에 매번 “해도 될까요?”를 묻는다. 파일 쓰기·이동처럼 되돌릴 수는 있지만 결과가 남는 작업에 어울린다. 기본값에 가까운 단계다.
• 거부(deny). 아예 막는다. 묻지도 않고 실행하지도 않는다. 시스템 폴더 삭제나 비밀키가 든 파일 접근처럼 절대 일어나면 안 되는 작업을 여기에 둔다.
• 관리형(managed). 조직(회사)이 위에서 정해 두는 정책. 개인이 풀거나 바꿀 수 없다. 회사가 일괄로 “이건 모두 금지”를 강제하는 자리다.

이 규칙들이 사는 곳 — settings.json

훅도, 권한도 모두 settings.json이라는 같은 파일에 적힌다. 이 파일은 위치에 따라 적용 범위와 우선순위가 다르다.

{
  "permissions": {
    "allow": [ "Read", "Glob", "Grep" ],
    "ask":   [ "Write", "Edit" ],
    "deny":  [ "Bash(rm -rf:*)", "Read(./.env)" ]
  }
}

자동 승인 설정

같은 안전한 작업에 매번 “네, 해도 됩니다”를 누르고 있다면, 그 작업은 한 번 정해 두고 자동으로 통과시킬 수 있다.

다만 자동 승인은 편리함과 위험을 맞바꾸는 일이다. 무엇을 자동으로 넘길지 고르는 안목이 핵심이다.

앞 레슨에서 본 ‘허용(allow)’이 바로 자동 승인이다. 자주 반복되면서 되돌릴 일이 없는 작업을 허용 목록에 올려 두면, 에이전트가 그 작업을 할 때 더는 묻지 않는다. 흐름이 끊기지 않으니 작업이 한결 매끄러워진다.

자동 승인해도 좋은 것, 절대 안 되는 것

• 자동 승인 후보 — 읽기 계열. 파일 읽기, 폴더 목록 보기, 검색. 세상을 바꾸지 않으니 막을 이유가 없다.
• 자동 승인 후보 — 가벼운 반복 작업. 테스트 실행, 코드 포맷처럼 자주 돌고 결과가 안전한 명령.
• 자동 승인 금지 — 되돌리기 어려운 것. 삭제, 덮어쓰기, 외부로 무언가를 보내는 명령(배포·전송)은 매번 사람이 확인해야 한다.

판단이 서지 않을 때 쓰는 안전한 기준이 하나 있다. “이 작업이 멋대로 실행돼도 나는 1분 안에 되돌릴 수 있는가?” 그렇다면 자동 승인 후보, 아니라면 확인을 남겨 둔다.

{
  "permissions": {
    // 묻지 않고 통과 — 안전한 반복 작업만
    "allow": [
      "Read", "Glob", "Grep",
      "Bash(npm test:*)",
      "Bash(npm run format:*)"
    ],
    // 되돌리기 어려운 건 반드시 확인에 남긴다
    "ask": [ "Bash(git push:*)", "Bash(rm:*)" ]
  }
}

내 .claude/settings.json의 권한 설정을 점검해줘.
- 자동 승인(allow)에 들어 있는 항목 중
  되돌리기 어려운 작업(삭제/덮어쓰기/배포/전송)이 섞여 있으면 짚어줘
- 그런 항목은 확인(ask)이나 거부(deny)로 옮기는 안을 제시해줘
- 읽기 계열은 allow로, 위험 작업은 ask/deny로 정리한 깔끔한 버전을 보여줘
- 바꾸기 전에 무엇을 어떻게 바꿀지 먼저 설명하고, 내가 "진행"하면 적용해줘

상태표시줄과 환경 종합

자동차 계기판이 속도와 연료를 늘 보여 주듯, 상태표시줄은 지금 어떤 모델로, 어느 폴더에서, 무엇을 쓰며 일하고 있는지를 한 줄로 보여 준다.

이 모듈에서 손본 조각들을 한자리에 모아 보는 마지막 레슨이다.

상태표시줄(status line)은 화면 아래에 늘 떠 있는 한 줄짜리 정보판이다. 현재 모델, 작업 폴더, 깃 브랜치 같은 걸 보여 주게 설정할 수 있다. 이것 역시 settings.json에 한 줄을 더해 켠다.

왜 필요할까. 엉뚱한 폴더에서 작업하거나, 비싼 모델을 모르고 계속 쓰는 실수를 화면을 흘끗 보는 것만으로 막아 주기 때문이다.

# 늘 화면 아래에 떠 있는 한 줄
claude-opus  ~/projects/shop  main  ✎ 3개 변경

이 모듈을 한 장으로

지금까지 손본 것을 정리하면 이렇다. 모두 같은 settings.json과 .claude/ 폴더 안에서 일어난 일이다.

1. 슬래시 커맨드반복하는 부탁을 .claude/commands/의 마크다운 파일로 묶어 /이름으로 호출한다.
2. 훅작업의 정해진 길목(실행 전·후, 완료 시)에 자동 동작을 걸어, 빠뜨리면 안 되는 일을 시스템에 맡긴다.
3. 권한허용·확인·거부·관리형 네 계층으로 무엇을 맡기고 무엇을 막을지 규칙으로 굳힌다.
4. 자동 승인‘1분 안에 되돌릴 수 있는’ 안전한 작업만 허용으로 올려 흐름을 매끄럽게 만든다.
5. 상태표시줄모델·폴더·브랜치를 한 줄로 띄워, 실수를 흘끗 보는 것만으로 막는다.