클로드 코드, 똑똑한 채팅창으로만 쓰고 계신가요? 슬래시 명령어 완전 정리

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

클로드 코드는 똑똑한 채팅창을 넘어 프로젝트에 직접 작업하는 도구이며, 슬래시 명령어를 상황에 맞게 골라 계획·권한·기억·검증을 관리하는 것이 핵심이다.

📌 핵심 요점

1. 작업 위치와 입력 방식을 먼저 구분한다. 클로드 코드는 허용된 환경에서 파일을 읽고 수정하며 명령을 실행한다. 자연어는 작업 요청, /는 명령 메뉴, @는 파일 지정, !는 지원되는 화면에서 셸 입력에 사용한다. 설치 확인과 로그인, 작업 폴더 준비는 각각 확인해야 한다.
2. 현재 환경과 작업 난도에 맞춰 설정한다. /help와 /status로 사용 가능한 기능과 상태를 확인하고, /model과 /effort로 모델과 추론 노력을 구분해 선택한다. /usage의 사용량·한도 표시를 읽되, 구독 로그인과 개발자 API 과금을 같은 것으로 가정하지 않는다.
3. 지속할 규칙과 대화 기록을 따로 관리한다. CLAUDE.md에는 프로젝트 목적·구조·원칙·테스트 방법을 남긴다. /compact는 대화를 요약하고, /clear는 새 대화, /resume은 세션 재개에 사용한다. 압축에서 빠지면 안 되는 재현 절차와 파일 이름은 문서에 남긴다.
4. 확장 기능은 해결하는 문제가 다르다. 스킬은 반복 절차, MCP는 외부 도구·데이터 연결, 훅은 특정 사건에 따른 자동 실행을 담당한다. 서브 에이전트는 역할을 나눠 별도 맥락에서 작업하고, 플러그인은 이런 확장을 묶어 관리한다. 기능을 추가해도 필요한 도구·인증·권한과 검증 기준은 별도로 갖춰야 한다.
5. 계획과 실제 동작 확인으로 완료를 판단한다. /plan으로 구현 범위를 검토하고 /permissions로 허용 규칙을 관리한다. /goal에는 관찰 가능한 완료 조건을 준다. /diff와 코드 검토, 테스트 실행, 브라우저 조작은 서로 다른 증거이며, 타이머라면 중복 클릭·일시 정지·초기화·0초 경계까지 확인한다.

🧩 배경과 문제 정의

• 클로드 코드를 자연어로 질문하고 코드를 받는 채팅창처럼만 사용하면, 프로젝트 파일 수정과 명령 실행, 작업 재개와 자동화 기능을 충분히 활용하기 어렵다.
• 클로드 코드는 허용된 권한과 실행 환경 안에서 프로젝트에 직접 작업하므로, 작업 폴더와 변경 대상, 실행 명령을 사용자가 이해해야 한다.
• 긴 대화에서 지침을 유지하고 반복 작업을 줄이려면 프로젝트 규칙, 대화 기록, 스킬, 외부 도구 연결의 역할을 구분해야 한다.
• 작업 완료 메시지나 코드 검토만으로 실제 동작을 보장할 수 없다. 완료 조건을 구체적으로 정하고, 실제로 확인한 증거에 따라 결과를 판단해야 한다.

🕒 시간순 섹션별 상세정리

1. 클로드 코드는 프로젝트 안에서 직접 작업한다

• 일반 클로드에서 받은 코드는 사람이 파일에 붙여 넣고 실행해야 하는 경우가 많지만, 클로드 코드는 작업 폴더의 파일을 읽고 수정하며 필요한 명령을 실행한다. 다만 사용자가 허용한 범위와 실행 환경 안에서 움직인다 [01:12]
• 타이머 화면을 만든 뒤 동작 오류를 설명하면 기존 코드를 살펴보고 수정할 수 있어, 사람이 코드를 반복해서 복사하는 과정이 줄어든다 [01:51]

2. 설치 확인과 작업 폴더·과금 경로 구분이 먼저다

• 설치 명령은 공식 문서의 주소를 확인한 뒤 사용한다. 버전 출력은 설치 여부를 확인하는 단계이며, 로그인과 작업 폴더 준비까지 끝났다는 뜻은 아니다 [02:59]
• 폴더 생성, 폴더 이동, 현재 위치 확인, 파일 목록 확인을 익혀야 한다. 작업 위치를 알아야 클로드가 엉뚱한 파일을 수정하는 일을 피하기 쉽다 [03:24]

3. 자연어·슬래시·파일 지정·셸 입력을 구분한다

• 자연어는 작업을 요청하는 방식이고, /는 클로드 코드의 명령어 메뉴를 여는 방식이다. 슬래시 명령은 보통 메시지 맨 앞에서 실행하며 이름을 입력하면 목록이 좁혀진다 [04:32]
• @로 파일 이름을 지정하면 “아까 만든 파일”처럼 설명하는 대신 대상 파일을 직접 가리킬 수 있어, 파일이 많은 프로젝트에서 유용하다 [05:07]

4. 권한 승인과 실행 중단은 변경 복구와 다르다

• 파일 수정이나 명령 실행 승인을 요청받으면 변경 대상과 실행 내용을 읽어야 한다. Shift+Tab으로 권한 모드를 바꿀 수 있지만, 지원 모드와 이름은 버전에 따라 달라질 수 있다 [05:45]
• 계획만 세우는 단계와 실제 파일을 바꿀 수 있는 단계를 구분해야 한다. Esc로 진행을 멈춰도 이미 수정한 파일이 자동으로 원상 복구되지는 않는다 [06:17]

5. 도움말과 상태 정보로 현재 환경을 확인한다

• 응답이 느리다고 바로 모델부터 바꾸기보다 사용량 한도, 연결 문제, 작업 복잡도를 먼저 구분해야 한다. 원인에 따라 필요한 조치가 달라진다 [07:23]
• /help에서 현재 제공되는 기능을 확인한다. 영상에 나온 명령도 버전이나 계정에 따라 보이지 않을 수 있으므로 실제 메뉴를 기준으로 판단한다 [08:00]

6. 모델 선택·추론 노력·사용량은 별도로 판단한다

• /model로 모델을 선택하며, 빠른 응답이 필요한 작업과 복잡한 설계 작업에 적합한 선택은 달라질 수 있다 [08:49]
• /effort는 같은 모델에서 추론에 들이는 노력을 조절한다. 단순한 색상 변경과 간헐적인 타이머 오류 조사에 필요한 노력은 다르며, 설정을 높인다고 정확성이 무조건 보장되지는 않는다 [09:06]

7. 권한 규칙과 대화 보조 기능에도 사용 범위가 있다

• /permissions는 읽기·수정·실행에 적용할 허용 규칙을 관리한다. 반복해서 허용해도 되는 작업과 매번 확인할 작업을 나누는 편이 낫다 [09:52]
• /copy는 직전 답변이나 코드 블록을 복사할 때 유용하다. 붙여 넣은 결과를 확인하면 실제로 무엇이 복사됐는지 알 수 있다 [10:10]

8. CLAUDE.md에는 지속할 규칙을 남긴다

• 새 세션이 이전 대화를 자동으로 전부 읽는 것은 아니므로, 오래 유지할 규칙은 대화 밖에 남겨야 한다. /init은 프로젝트 지침 파일을 시작하는 데 도움을 주며, 목적·파일 구조·원칙·테스트 방법을 적을 수 있다 [11:15]
• 예시 지침은 index.html 한 파일로 구현하고 외부 라이브러리와 서버를 쓰지 않으며, 수정 후 실행 방법과 실제 확인 항목을 설명하도록 정한다. /memory는 메모리 파일과 자동 메모리 기능을 살펴보거나 관리하는 데 사용한다 [12:02]

9. 대화 압축·새 대화·세션 재개·되돌리기를 구분한다

• /context는 현재 대화와 자료가 차지하는 공간을 확인하는 데 사용하고, /compact는 대화를 요약해 작업을 이어갈 공간을 정리한다. 모든 정보가 빠짐없이 보존되지는 않으므로 세부 재현 절차와 중요한 파일 이름은 문서에 남기는 편이 낫다 [13:39]
• /clear는 새 대화를 시작하고, /resume은 과거 세션을 다시 불러온다. /rename으로 세션에 알아볼 이름을 붙이면 이전 작업을 찾기 쉽다 [14:24]

10. 스킬은 반복 절차를 재사용하지만 도구를 대신하지 않는다

• 스킬은 자주 쓰는 작업 방식과 지식을 파일에 담는 기능이다. /skills로 사용 가능한 스킬을 확인하고, 타이머 검사 스킬에는 기존 파일 읽기, 시작·일시 정지·초기화 검사, 미확인 결과를 통과로 표현하지 않기 등을 적는다 [16:21]
• 필요한 경우 /reload-skills로 목록을 갱신한다. 스킬은 새로운 능력을 부여하기보다 반복 점검에서 빠뜨리지 않을 순서와 기준을 남긴다 [17:21]

11. MCP는 외부 도구와 데이터에 접근하는 연결 통로다

• MCP는 외부 도구와 데이터를 연결하는 표준화된 통로이며, /mcp에서 서버 상태와 인증·연결을 관리할 수 있다. 서버를 등록해도 별도 인증이나 도구 권한이 필요할 수 있다 [18:25]
• 스킬은 일하는 순서를 정하고 MCP는 사용할 외부 도구를 연결한다. 연결만으로 작업 절차가 정해지지는 않으며, 서버가 많아질수록 관리할 인증과 권한도 늘어난다 [19:11]

12. 훅은 조건이 분명한 반복 작업을 자동 실행한다

• 훅은 정해진 사건이 발생할 때 등록한 동작을 실행한다. /hooks로 설정을 확인하고, 특정 도구 실행 후 로컬 검사 스크립트를 돌리도록 구성할 수 있다 [20:20]
• 스킬이 작업 지침을 전달한다면 훅은 지정된 시점에 실행을 연결한다. 판단이 자주 바뀌는 일보다 실행 조건이 명확한 반복 작업에 적합하며, 긴 검사를 매번 실행하면 오히려 속도가 떨어질 수 있다 [21:03]

13. 서브 에이전트는 역할을 나누고 플러그인은 확장을 묶는다

• 서브 에이전트는 정해진 역할과 작업 범위를 별도 맥락에서 수행하고 결과를 돌려준다. /agents의 동작은 버전에 따라 달라질 수 있어 실제 화면을 기준으로 확인해야 한다 [22:08]
• 검토 담당에게 시작 버튼 중복 클릭, 일시 정지 후 재시작, 0초 도달 같은 경계 조건을 맡길 수 있다. 다만 에이전트 수가 늘어도 정답이 보장되지는 않으므로 확인 기준은 사람이 정해야 한다 [22:54]

14. 계획과 목표에는 관찰 가능한 완료 조건이 필요하다

• “멋진 타이머”처럼 모호한 요구는 디자인과 안정성 중 무엇을 우선할지 불분명하다. /plan으로 파일 구성과 구현 순서를 검토한 뒤 수정하면 불필요한 재작업을 줄일 수 있다 [24:42]
• /goal은 완료 조건을 주고 그 방향으로 작업을 이어가게 하지만 검증을 대신하지 않는다. 타이머의 조건은 시작 시 한 번만 감소하고, 일시 정지 시 멈추며, 초기화 시 원래 시간으로 돌아오고, 0 아래로 내려가지 않는 것으로 구체화한다 [25:30]

15. 코드 검토·실행 검사·브라우저 확인·승인은 다른 증거다

• /diff는 변경 파일과 코드 차이를 확인하고, /review 또는 /code-review는 코드 변경을 검토한다. 코드 검토만으로 실제 버튼 조작에서 드러나는 문제까지 확인했다고 볼 수는 없다 [25:58]
• /verify는 지원 환경에서 앱 실행과 동작 관찰을 돕는 내장 스킬이다. 실제 브라우저 실행 도구가 준비되어 있는지에 따라 확인 범위가 달라진다 [26:18]

16. 작은 타이머도 계획 승인 후 실제 동작을 확인한다

• 실습은 25분 집중과 5분 휴식, 시작·일시 정지·초기화 버튼으로 범위를 좁힌다. 계획에서 불필요한 라이브러리나 서버가 추가되지 않았는지, 요구한 버튼이 포함됐는지 확인한 뒤 파일을 생성한다 [27:31]
• 파일 생성 권한은 대상을 확인하고 승인한다. 브라우저에서는 시작 후 숫자가 줄고, 일시 정지 후 멈추며, 초기화 후 25분으로 돌아오는 기본 동작을 확인한다 [28:03]

17. 기능 추가 뒤에는 변경 내용과 기존 동작을 다시 확인한다

• /diff로 무엇이 바뀌었는지 확인한다. 화면이 정상으로 보이는 것과 코드 변경 범위를 이해하는 것은 별개이므로, 관련 없는 부분까지 수정됐는지도 살펴야 한다 [29:10]
• 집중과 휴식을 직접 전환하는 버튼을 추가하고, 25분에서 5분으로 바뀌었다가 다시 집중으로 돌아오는지 확인한다. 새 기능 때문에 기존 동작이 망가지지 않았는지 기존 버튼도 다시 검사한다 [29:25]

18. 명령어 암기보다 상황에 맞는 도구 선택이 중요하다

• 브라우저에서 동작과 경계 조건을 확인하고 수정 사항을 검토한 뒤 기능을 하나 더 추가했다. 클로드 코드는 앱 개발의 여러 단계에 관여했다. [30:11]
• /help를 출발점으로 모델과 권한 선택, 프로젝트 기억, 대화 관리를 설정하고, 스킬·MCP·훅·서브 에이전트·플러그인까지 활용 범위를 넓혔다. [30:39]

19. 작업 완료 메시지보다 계획·검토와 실제 동작 확인이 중요하다

• AI가 일을 빨리 끝내도 좋은 결과가 보장되지는 않는다. 계획과 검토를 건너뛰면 완료 메시지만 남을 수 있으므로, 각 메뉴의 기능이 실제로 작동하는지 확인해야 한다. [31:14]
• 클로드 코드는 앞으로도 새로운 명령어와 달라진 메뉴가 등장할 수 있다. 변화가 생길 때마다 /help를 다시 열어 사용 가능한 기능을 확인하면 된다. [31:24]

🧾 결론

• 명령어 전체를 암기하기보다 사용량 확인, 이전 작업 재개, 변경 검토처럼 필요한 상황과 명령을 연결해 기억하는 편이 유용하다.
• 오래 유지할 기준은 프로젝트 지침에, 반복 점검 순서는 스킬에 남기고, 실제 실행에 필요한 연결과 도구는 별도로 준비한다.
• 완료 메시지나 코드 검토만으로 동작을 확정하지 않는다. 무엇을 실행해 확인했는지와 아직 확인하지 못한 부분을 구분해야 한다.
• 실행 중단과 변경 복구는 다르다. Esc가 기존 수정을 되돌리지는 않으며, /rewind도 컴퓨터 전체를 복구하는 백업은 아니다.

📈 투자·시사 포인트

• 생산성 개선의 출발점은 답변을 복사하는 과정을 줄이고, 프로젝트 수정부터 동작 확인까지 이어지는 작업 흐름을 만드는 데 있다.
• 비용을 판단할 때는 모델 선택·추론 노력·사용량 한도를 따로 보고, 구독과 API의 과금 경로를 구분해야 한다.
• 자동화에는 운영 부담도 따른다. MCP 연결이 늘면 인증과 권한 관리가 늘고, 긴 검사를 훅으로 매번 실행하면 작업 속도가 떨어질 수 있다.
• 작은 작업에는 한 에이전트로도 충분할 수 있다. 확장 기능의 수보다 필요한 절차와 확인 기준을 갖췄는지가 중요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 명령어 제공 여부와 권한 모드의 이름·동작은 버전이나 계정, 실행 환경에 따라 달라질 수 있다. 영상의 목록보다 현재 /help와 실제 메뉴를 기준으로 확인해야 한다.
• /verify나 브라우저 검증 지침이 있어도 실제 브라우저 제어 도구가 준비되지 않았다면 해당 검증을 수행할 수 없다. 자료만으로 독자의 환경에서 가능한 확인 범위를 확정할 수는 없다.
• /compact가 모든 세부 정보를 보존하거나 /rewind가 외부 작업까지 복구한다고 가정할 수 없다. 중요한 기록과 복구 대상은 따로 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 작업 폴더와 파일 목록을 확인하고, 로그인 방식과 과금 경로를 구분한다.
• /help, /status, /usage에서 제공 기능·연결 상태·사용량 한도를 확인한다.
• CLAUDE.md에 프로젝트 목적, 수정 범위, 구현 제약, 실행·테스트 방법을 기록한다.
• 구현 전에 계획을 검토하고, 파일 수정이나 명령 실행을 승인할 때 실행 위치와 대상을 읽는다.

❓ 열린 질문

• 현재 사용하는 버전과 계정에서는 소개된 명령 가운데 무엇이 제공되며, 실제 동작 범위는 어디까지인가?
• 프로젝트에서 반복 허용할 작업과 매번 승인할 작업을 어떤 기준으로 나눌 것인가?
• 작업 완료를 인정하려면 코드 검토, 테스트 실행, 브라우저 조작에서 각각 어떤 증거가 필요한가?