Claude Code 명령어, 헷갈리는 /cost·/plan·STEP-BY-STEP 한 번에 정리
이미지: AI 생성 대표 이미지
Claude Code 명령어를 보다 보면 /cost, /plan, /clear 옆에 /STEP-BY-STEP, /TLDR, /ELI5까지 한꺼번에 등장합니다. 처음에는 전부 입력하면 작동하는 숨은 기능처럼 보이죠. 그런데 여기에는 실제 Claude Code 명령과, 자주 쓰는 프롬프트를 짧게 부르는 이름이 섞여 있습니다. 둘 다 쓸모 있지만, 쓰는 방법은 다릅니다.
딱 이것만 먼저 기억하면 편합니다. 현재 Claude Code 공식 문서에서 /cost는 /usage의 별칭이고, /plan은 계획 모드로 들어가는 명령입니다. /clear는 새 대화를 시작하고, /resume은 예전 세션을 다시 여는 역할을 합니다. 반대로 /STEP-BY-STEP, /TLDR, /ELI5, /100ideas, /invert는 공식 내장 명령표에 없습니다. 이런 표현은 일반 프롬프트로 써도 되고, 마음에 들면 내 커스텀 명령으로 저장하면 됩니다.
이 차이만 알아도 인터넷에서 본 단어를 무작정 외울 필요가 없습니다. Claude Code는 물론 Codex에서도 다시 쓸 수 있는 나만의 작업 문장을 만들 수 있습니다.
먼저 구분할 것: 내장 명령·사용자 정의 명령·프롬프트 패턴
| 구분 | 무엇인가 | 예시 | 확인 방법 |
|---|---|---|---|
| 실제 내장 명령 | 제품이 구현한 세션·모델·권한 제어 기능 | Claude Code의 /cost, /compact, /clear, /plan |
제품 내 /, /help, 명령 자동완성, 공식 문서 |
| 사용자 정의 명령·스킬 | 사용자가 저장한 지시문 묶음 | /security-check, /100ideas, /invert |
프로젝트의 스킬·명령 폴더와 팀 설정 |
| 프롬프트 패턴 | 그냥 자연어로 전달하는 사고·검증 방식 | 문제를 4단계로 검토한 뒤 결론만 제시해 |
어느 대화창에서도 그대로 입력 |
Claude Code에서는 내장 명령, 기본 제공 스킬, 내가 만든 스킬, 예전 방식의 커스텀 명령 파일이 같은 슬래시 명령 목록에 함께 보일 수 있습니다. 그래서 누군가의 /verify가 내 화면에도 똑같이 있을 거라고 단정하면 곤란합니다. 가장 쉬운 확인법은 입력창에서 /를 눌러 내 세션의 목록을 보는 것입니다. Claude Code 공식 문서
실제로 바로 써볼 Claude Code 명령 12개
아래는 현재 공식 명령표에서 확인되는 항목입니다. 다만 버전, 플랜, OS, 연결한 플러그인에 따라 보이는 메뉴는 조금씩 다를 수 있어요. 마지막 확인은 Claude Code 입력창에서 /를 눌러 보면 됩니다.
| 상황 | 명령 | 정확한 역할 |
|---|---|---|
| 이번 작업의 사용량 확인 | /cost 또는 /usage |
현재 세션 사용량을 확인한다. /cost는 /usage의 별칭이다. |
| 대화가 길어짐 | /context |
컨텍스트를 무엇이 차지하는지 확인한다. |
| 같은 맥락을 유지하면서 압축 | /compact |
앞선 대화를 요약해 컨텍스트 공간을 확보한다. |
| 완전히 다른 업무 시작 | /clear |
비어 있는 새 대화를 시작한다. 기존 대화는 /resume으로 다시 열 수 있다. |
| 예전 작업 이어 하기 | /resume [세션] |
세션 ID·이름으로 이전 대화를 재개하거나 선택기를 연다. |
| 다른 해결 경로 실험 | /branch |
현재 대화에서 대체 경로를 분기한다. |
| 잘못된 진행 되돌리기 | /rewind |
이전 지점으로 대화와 코드를 되돌리거나 일부 대화를 요약한다. |
| 세션 이름 정리 | /rename [이름] |
현재 세션 이름을 바꿔 나중에 찾기 쉽게 한다. |
| 대화 보관 | /export [파일명] |
현재 대화를 일반 텍스트로 내보낸다. |
| 프로젝트 규칙 초안 만들기 | /init |
저장소를 읽고 시작용 CLAUDE.md를 만든다. |
| 큰 변경 전 설계 | /plan [설명] |
플랜 모드로 진입해 수정 전 계획부터 세운다. |
| 도구 실행 규칙 설정 | /permissions |
허용·확인·차단 권한 규칙을 관리한다. |
처음에는 세 가지만 써도 충분합니다. 큰 기능을 손댈 때는 /plan으로 출발하고, 대화가 길어지면 /context로 무엇이 자리를 많이 차지하는지 본 뒤 /compact를 쓰세요. 다른 일로 넘어갈 때는 대화를 억지로 이어 가지 말고 /clear를 쓰고, 나중에 필요하면 /resume으로 돌아오면 됩니다. 여기서 헷갈리기 쉬운 점은 /clear와 /compact입니다. /clear는 새 빈 대화, /compact는 지금까지 맥락을 요약해서 계속 이어 가는 기능입니다. Claude Code Commands
/STEP-BY-STEP, /TLDR, /ELI5는 명령이 아니라 좋은 작업 지시의 별칭이다
링크에서 본 단축어도 충분히 좋은 습관입니다. 다만 현재 공식 Claude Code 명령표에는 이 이름들이 보이지 않습니다. 내 환경에서 명령으로 인식되는지는 설치한 스킬과 플러그인 설정에 달려 있어요. 아무 설정이 없다면 슬래시만 빼고 문장으로 적으면 됩니다. 결과는 여전히 쓸 만합니다.
| 짧은 이름 | 바로 붙여 넣을 문장 | 쓸 때 |
|---|---|---|
STEP-BY-STEP |
문제를 원인 확인, 실행 순서, 성공 판정, 다음 단계로 나눠 정리해줘. 최종 답변에는 결론과 근거만 써줘. |
모호한 목표를 실행 계획으로 바꿀 때 |
TLDR |
핵심 결론 3개, 결정에 필요한 숫자·날짜, 당장 할 일만 8줄 이내로 요약해줘. |
긴 회의록·문서의 판단 포인트를 추릴 때 |
ELI5 |
전문용어를 처음 나오면 한 번만 풀어 쓰고, 비유 하나와 실제 예시 하나로 설명해줘. |
낯선 개념을 쉽게 이해할 때 |
100ideas |
범주별로 발산하고, 중복 제거와 평가를 거쳐 상위 항목만 남겨줘. |
콘텐츠·기능 아이디어를 넓힐 때 |
invert |
이 계획을 실패시키는 조건, 조기 경보, 예방책, 복구 순서를 찾아줘. |
출시·투자·코드 변경 전에 구멍을 찾을 때 |
/100ideas와 /invert도 같은 방식으로 생각하면 됩니다. 자주 쓰는 팀 템플릿이라면 커스텀 명령으로 저장하고, 한두 번 쓸 일이라면 슬래시를 빼고 아래 문장을 그대로 붙여 넣으면 됩니다.
실무에서 강한 프롬프트는 멋진 호출어가 아니라 입력, 제약, 완료 기준, 검증 방법이 빠지지 않은 작업 명세다.
think step by step: 생각을 공개하라는 말보다 작업 단계를 고정하자
복잡한 비교나 디버깅, 일정 설계는 한 줄 답보다 검토 순서를 알려 줄 때 훨씬 잘 풀립니다. 그렇다고 “생각을 전부 보여줘”라고 길게 요청할 필요는 없어요. 무엇을 어떤 순서로 살피고, 최종 답변에는 무엇만 남길지를 적어 주면 됩니다.
Anthropic도 단계적 추론을 프롬프트 기법으로 안내하지만, 확장 사고 기능이 있는 모델에서는 그 기능이 일반적으로 더 적합할 수 있다고 설명한다. 핵심은 마법 문구가 아니라 작업 난도에 맞는 검토 구조다. Anthropic 프롬프트 엔지니어링 가이드
바로 쓰는 템플릿
[목표]
Windows 검색창이 검은 화면으로 열리는 문제의 가능한 원인을 우선순위로 정리한다.
[작업 순서]
1. 증상만으로 확정할 수 없는 원인과 확인 가능한 원인을 나눈다.
2. 데이터 손실 위험이 낮은 조치부터 배열한다.
3. 각 조치에 실행 방법, 성공 판정, 다음 단계 조건을 붙인다.
4. 최종 답변에는 결론, 실행 순서, 주의점만 쓴다.
[완료 기준]
관리자 권한 필요 여부와 재부팅 필요 여부가 각 단계에 명시돼 있어야 한다.
이렇게 적어두면 답변이 길게 흩어지는 대신, 바로 실행할 수 있는 절차로 정리됩니다. 코딩 에이전트라면 마지막 줄만 수정 뒤 관련 테스트를 실행하고, 실패 시 원인과 남은 위험을 보고한다로 바꿔도 좋습니다.
/100ideas: 100개를 많이 뽑는 기능이 아니라 발산 후 선별하는 방법
아이디어를 100개 달라고 하면 비슷한 제목만 길게 돌아오는 경우가 꽤 있습니다. 그래서 숫자 자체보다 범주를 나누고, 겹치는 항목을 빼고, 고르는 기준을 정하는 일이 더 중요합니다. /100ideas를 내 명령으로 저장하고 싶다면 아래처럼 만들어 보세요.
[주제]
직장인 대상 AI 활용 블로그 시리즈 기획
1. 입문, 업무 자동화, 글쓰기, 개발, 검증의 5개 범주를 만든다.
2. 범주마다 서로 겹치지 않는 아이디어 12개씩, 총 60개를 만든다.
3. 제목이 비슷한 항목은 통합하고, 너무 넓은 항목은 버린다.
4. 검색 의도, 바로 실행 가능성, 후속 글 확장성으로 각 항목을 5점 만점 평가한다.
5. 상위 10개만 제목·독자·핵심 질문·첫 문단 훅까지 완성한다.
[제약]
확인 불가능한 기능명이나 과장된 생산성 수치는 쓰지 않는다.
60개라는 숫자도 고정은 아닙니다. 범주가 3개면 30개로 줄이고, 팀 브레인스토밍이라면 80개로 늘리면 됩니다. 핵심은 ‘많이 만들기’와 ‘좋은 것 고르기’를 한 번에 섞지 않는 거예요. Claude 공식 가이드도 성공 기준과 평가 방식을 먼저 세운 뒤 프롬프트를 다듬는 방식을 권합니다. Claude Platform 프롬프트 엔지니어링 개요
/invert: 성공법을 묻기 전에 실패 조건을 먼저 찾는 프롬프트
invert는 실제 범용 명령어라기보다 반대로 생각하기(inversion)에 붙인 이름이라고 보면 편합니다. “이걸 성공시키려면 뭘 해야 하지?”만 묻는 대신, “이 계획을 망치려면 어떤 조건이 필요하지?”를 먼저 찾아보는 방식이에요. 출시나 콘텐츠 기획, 코드 변경 전에는 이런 질문이 의외로 빈틈을 잘 잡아냅니다.
[계획]
매주 월요일에 AI가 작성한 기업 분석 글을 GitHub Pages에 발행한다.
이 계획을 실패시키는 조건을 15개 찾는다.
각 조건에 대해 다음을 표로 정리한다.
- 실패가 발생하는 구체적 상황
- 조기 경보 신호
- 예방 조치
- 발생했을 때의 복구 순서
마지막에는 영향도와 발생 가능성이 모두 높은 항목 3개만 골라
이번 주 실행 체크리스트로 다시 작성한다.
이 프롬프트의 좋은 점은 막연한 “리스크 알려줘”를 바로 쓸 수 있는 점검표로 바꿔준다는 데 있습니다. GitHub Pages 글이라면 미래 날짜 게시물, 잘못된 카테고리 URL, 로컬 이미지만 가리키는 경로, 빌드는 성공했는데 실제 배포 페이지는 안 보는 일처럼 구체적인 실패 조건이 나옵니다.
Claude와 Codex에 공통으로 잘 먹히는 다섯 가지 문장
1. 결과물을 먼저 고정한다
좋은 결과는 A, B, C를 모두 충족한 상태다.
완료 전 각 조건을 확인하고, 충족하지 못한 항목은 추측으로 채우지 말고 남은 이슈로 표시해줘.
AI에게 “잘해줘”라고만 하면 기준을 각자 다르게 해석할 수 있습니다. 그래서 원하는 결과와 통과 기준을 먼저 적어 주는 편이 편합니다. OpenAI 최신 모델 가이드도 기대 결과와 성공 기준을 먼저 명시하라고 권합니다. 세부 절차를 너무 꽉 묶기보다, 결과와 검증 기준을 주고 경로 선택은 맡기는 편이 최근 추론 모델과 잘 맞을 때가 많습니다. OpenAI 모델 가이드
2. 근거의 범위를 제한한다
공식 문서, 공공기관 자료, 기업 공시만 근거로 사용해줘.
각 핵심 주장 뒤에 원문 링크와 기준일을 붙이고, 확인되지 않은 내용은 제외해줘.
이 한 문장만 넣어도 AI가 그럴듯한 보조 자료를 섞는 일을 꽤 줄일 수 있습니다. 가격, 이벤트, 정책, 주가처럼 자주 바뀌는 정보라면 기준일과 출처 유형까지 같이 정해 주세요.
3. ‘검토자’를 한 번 더 둔다
초안을 만든 뒤 독립적인 검토자 역할로 전환해줘.
사실 오류, 누락된 전제, 독자가 오해할 표현을 찾아 수정안을 제시하고,
수정된 최종본만 출력해줘.
답을 두 번 길게 쓰라는 뜻은 아닙니다. 한 번 만든 결과를 다른 기준으로 한 번 더 살피게 하는 장치라고 생각하면 됩니다. 숫자, 날짜, 코드 변경 범위처럼 틀리면 곤란한 항목에서 특히 든든합니다.
4. 작업의 자율 범위를 정한다
읽기, 조사, 초안 작성, 테스트는 스스로 진행해줘.
외부 서비스 게시, 결제, 삭제처럼 되돌리기 어려운 작업은 실행 직전에만 확인을 요청해줘.
에이전트가 사소한 일에도 매번 멈춰서 묻는다면 이 문장이 도움이 됩니다. 조사와 초안, 테스트까지는 알아서 진행하고, 발행이나 결제처럼 되돌리기 어려운 순간에만 멈추게 하는 방식입니다. OpenAI도 장기 작업에서 의도를 추론해 끝까지 수행하도록 하되, 되돌리기 어려운 작업은 따로 다루는 지시문을 예시로 제공합니다. OpenAI 모델 가이드
5. 반복되는 규칙은 대화에 매번 붙이지 않는다
매번 같은 말을 붙여 넣고 있다면 파일로 옮길 때입니다. Claude Code는 CLAUDE.md와 스킬에, Codex는 프로젝트 지침 파일과 스킬에 반복 규칙을 적어두는 편이 낫습니다. 긴 대화는 압축되면서 초반 지시가 흐려질 수 있기 때문이에요. Claude Code 문서는 지속 규칙을 초기 프롬프트 대신 CLAUDE.md에 두면 매 요청에 다시 넣어 준다고 설명합니다. Claude Code 에이전트 루프 문서
내 /invert, /100ideas를 실제 Claude Code 명령으로 만드는 법
여기부터가 조금 재밌는 부분입니다. .claude/commands/에 파일 하나를 만들면 내 슬래시 명령이 생깁니다. 예를 들어 .claude/commands/blog-invert.md를 만들면 Claude Code에서 /blog-invert로 부를 수 있어요. 현재 공식 문서도 이 방식을 계속 지원합니다.
다만 명령이 많아지면 폴더 하나에 SKILL.md를 두는 스킬 방식이 더 편합니다. 한 개를 가볍게 만들 때는 commands, 프로젝트 규칙이나 참고 파일까지 함께 묶을 때는 skills를 고르면 됩니다. Claude Code 스킬 공식 문서
| 쓰는 범위 | 만들 위치 | 추천 상황 |
|---|---|---|
| 프로젝트 명령 | .claude/commands/blog-invert.md |
바로 /blog-invert 하나를 만들고 싶을 때 |
| 개인 공용 명령 | ~/.claude/commands/blog-invert.md |
모든 프로젝트에서 같은 짧은 명령을 쓸 때 |
| 프로젝트 스킬 | .claude/skills/blog-invert/SKILL.md |
팀 규칙·참고 파일까지 폴더에 함께 둘 때 |
| 개인 공용 스킬 | ~/.claude/skills/blog-invert/SKILL.md |
개인 작업 방식 전체를 재사용할 때 |
Windows에서 ~는 보통 C:\Users\사용자이름을 뜻합니다. 예를 들어 개인 공용 명령은 C:\Users\HG\.claude\commands\blog-invert.md에 두면 됩니다.
1. 가장 빠른 방법: .claude/commands에 Markdown 파일 하나 만들기
파일 하나만 만들면 됩니다.
.claude/
└── commands/
└── blog-invert.md
파일명 blog-invert.md가 곧 호출 이름 /blog-invert가 됩니다. 본문에는 매번 반복하던 작업 지시를 넣어 주세요.
---
description: 콘텐츠·출시·개발 계획의 실패 조건과 대응책을 점검한다.
---
사용자가 `/blog-invert` 뒤에 적은 내용을 점검 대상 계획으로 본다.
1. 계획을 실패시키는 구체적인 조건을 최대 12개 찾는다.
2. 각 조건마다 조기 경보 신호, 예방 조치, 실패 뒤 복구 순서를 정리한다.
3. 영향도와 발생 가능성을 각각 1~5점으로 평가한다.
4. 두 점수의 합이 높은 항목 3개만 이번 주 체크리스트로 다시 쓴다.
확인할 근거가 없으면 사실처럼 단정하지 말고, 확인이 필요한 가정으로 표시한다.
개인 공용으로 쓰고 싶다면 같은 파일을 ~/.claude/commands/blog-invert.md에 두면 됩니다. 이게 가장 빠른 입문 방법입니다. 공식 문서도 .claude/commands/deploy.md가 /deploy를 만든다고 안내합니다.
2. 이름부터 내장 명령과 겹치지 않게 정한다
여기서 한 가지만 조심하면 됩니다. /clear, /plan, /verify, /code-review처럼 이미 쓰이는 이름은 피하세요. 커스텀 명령 파일이 번들 스킬과 같은 이름을 쓰면 기존 기능을 가릴 수 있습니다. blog-invert, idea-lab, source-check처럼 용도가 바로 보이는 이름이 안전합니다.
3. 기능을 묶어 관리하려면 SKILL.md로 확장한다
명령이 길어지거나 참고 파일·실행 도구까지 같이 챙기고 싶다면 그때 스킬로 옮기면 됩니다. 아래는 콘텐츠 기획 실패 요인을 점검하는 /blog-invert 스킬 예시예요. 폴더 이름과 front matter의 name을 같게 맞추면 나중에 정리하기 편합니다.
.claude/
└── skills/
└── blog-invert/
└── SKILL.md
SKILL.md에는 다음 내용을 넣는다.
---
name: blog-invert
description: 콘텐츠·출시·개발 계획의 실패 조건과 대응책을 점검한다.
---
사용자가 `/blog-invert` 뒤에 적은 내용을 점검 대상 계획으로 본다.
1. 계획을 실패시키는 구체적인 조건을 최대 12개 찾는다.
2. 각 조건마다 조기 경보 신호, 예방 조치, 실패 뒤 복구 순서를 정리한다.
3. 영향도와 발생 가능성을 각각 1~5점으로 평가한다.
4. 두 점수의 합이 높은 항목 3개만 이번 주 체크리스트로 다시 쓴다.
확인할 근거가 없으면 사실처럼 단정하지 말고, 확인이 필요한 가정으로 표시한다.
description은 그냥 메모가 아닙니다. Claude가 일반 요청을 받았을 때 이 스킬을 꺼내 쓸지 판단하는 단서예요. 그래서 ‘무엇을, 언제 하는 스킬인지’를 구체적으로 적어두는 편이 좋습니다. 공식 문서도 SKILL.md의 YAML front matter와 Markdown 본문, 그리고 description의 역할을 설명합니다. Claude Code 스킬 공식 문서
4. Claude Code에서 불러오고 실행한다
파일을 저장했다면 Claude Code를 다시 시작하거나, 이미 켜 둔 세션에서는 /reload-skills로 다시 읽으면 됩니다. /skills에서 목록에 보이는지 한 번 보고, 아래처럼 실행해 보세요.
/blog-invert 다음 달부터 매주 월요일 기업 분석 글을 자동 발행한다.
스킬은 이렇게 직접 부를 수 있고, description이 잘 맞으면 Claude가 일반 요청에서도 알아서 활용할 수 있습니다. 목록에 안 보인다면 현재 작업 경로가 .claude/skills/가 있는 저장소 안인지, 개인 스킬은 ~/.claude/skills/ 아래에 넣었는지만 먼저 확인해 보세요.
5. 같은 방식으로 /idea-lab도 만든다
무조건 100개를 뽑는 것보다, 넓게 만들고 잘 고르는 흐름을 같이 넣는 편이 훨씬 쓸모 있습니다. 그래서 이름도 /100ideas보다 /idea-lab처럼 붙여 봤습니다.
---
name: idea-lab
description: 주제를 범주별로 발산하고 중복을 제거한 뒤 실행 우선순위를 정한다.
---
사용자가 `/idea-lab` 뒤에 적은 내용을 주제로 삼는다.
1. 서로 다른 5개 범주를 만든다.
2. 범주별로 겹치지 않는 아이디어 10개씩을 만든다.
3. 검색 의도, 실행 난도, 후속 확장성을 각각 1~5점으로 평가한다.
4. 상위 10개만 제목, 타깃 독자, 핵심 질문, 첫 문단 훅까지 구체화한다.
5. 유사한 아이디어와 근거 없는 기능명은 제거한다.
이 파일을 .claude/skills/idea-lab/SKILL.md 또는 ~/.claude/skills/idea-lab/SKILL.md에 저장하면 /idea-lab AI 에이전트 블로그 시리즈처럼 부를 수 있습니다. 일단 가볍게 시작하고 싶다면 같은 본문을 .claude/commands/idea-lab.md에 넣어도 됩니다.
Codex에서는 무엇을 저장할까
여기까지의 파일 경로와 슬래시 호출은 Claude Code 기준입니다. Codex는 설치한 스킬과 실행 환경에 따라 부르는 방법이 달라서, /blog-invert가 모든 화면에서 똑같이 동작한다고 보기는 어렵습니다. Codex에서는 반복 규칙을 프로젝트 지침 파일과 스킬에 적어두고, 필요하면 위 SKILL.md의 작업 지시를 일반 프롬프트로 붙여 넣는 방법이 가장 무난합니다. OpenAI도 에이전트가 읽는 AGENTS.md와 스킬 파일의 지시가 행동에 영향을 준다고 안내합니다. OpenAI 모델 가이드
나만의 /100ideas, /invert를 만들기 전에 쓸 기본 골격
아래 다섯 줄은 채팅, Claude Code, Codex 어디에나 붙여 쓸 수 있습니다. 먼저 채팅에 써 보고 마음에 들면, 그때 개인 명령이나 스킬 본문으로 옮기면 됩니다.
[목표] 무엇을 최종 산출물로 만들지 한 문장으로 쓴다.
[입력과 근거] 사용할 자료와 출처 범위를 정한다.
[제약] 금지할 것, 톤, 길이, 예산, 기술 조건을 적는다.
[작업 방식] 발산·비교·반증·검증 중 필요한 순서를 지정한다.
[완료 기준] 통과 조건과 실패 시 보고할 항목을 정한다.
예를 들어 블로그 글에는 출처는 공식 사이트만, 코드 작업에는 테스트 통과와 변경 파일 목록, 여행 계획에는 예산·이동 시간·예약 필요 여부를 완료 기준에 넣어 보세요. 같은 “잘 써줘”라도 이 다섯 칸을 채우면 결과가 훨씬 또렷해집니다.
명령어를 찾는 시간보다 결과를 검증하는 시간이 중요하다
결국 진짜 쓸모 있는 기능은 특정 단어 하나가 아닙니다. AI가 무엇을 해야 하는지 알아듣게 하고, 결과를 한 번 더 확인하게 만드는 작업 설계가 핵심이에요. /100ideas와 /invert가 내 도구에서 보이지 않아도 괜찮습니다. 템플릿을 자연어로 먼저 써 보고, 자주 쓰게 되면 그때 스킬이나 프로젝트 명령으로 저장하면 됩니다.
마지막으로 실제 내장 명령은 버전, 플랜, 설치한 스킬, 연결한 MCP 서버에 따라 달라질 수 있습니다. 블로그나 영상에서 본 슬래시 명령을 바로 믿기보다, 내 환경에서 / 또는 /help를 먼저 눌러 보세요. 이 작은 습관만 있어도 “왜 나는 안 되지?” 하는 시간을 꽤 아낄 수 있습니다.
Leave a comment