FIELD GUIDE · 2026 · 동료형
Claude Code 완전 가이드
터미널에서 폴더에 직접 손대는 동료형 AI, 제대로 길들이기
by ai.dingco × ai.crew · v1.1 / 2026.06
이 책은 무엇인가
Claude Code는 당신의 컴퓨터 폴더에 직접 접근해 코드를 읽고, 고치고, 명령을 실행하는 터미널 AI입니다. 브라우저 채팅창에 코드를 복사해 붙여넣고 답을 다시 옮겨 적는 방식이 아닙니다. 파일을 열고, 변경을 적용하고, 테스트를 돌리는 일을 자기 손으로 합니다. 그래서 '채팅 AI'라기보다 옆자리에 앉은 동료에 가깝습니다.
동료에게 일을 맡기듯 쓰면 됩니다. 다만 이 동료는 우리 팀의 규칙을 모르는 신입입니다. 빌드는 어떻게 하는지, 무엇을 건드리면 안 되는지, 커밋 메시지는 어떤 형식인지를 알려줘야 제대로 일합니다. 게다가 슬래시 명령어만 100개가 넘습니다. 전부 외우려 들면 시작도 하기 전에 지칩니다. 이 책은 명령어 암기 대신, 동료를 길들이는 네 가지 축으로 정리했습니다. 기억하게 만들고, 권한을 통제하고, 일을 위임하고, 한 세션을 끝까지 운영하는 것입니다.
이 책은 '시작하기'에서 설치·로그인·첫 세션과 요금제부터 떼고 출발합니다. 그다음 동료를 길들이는 네 가지 축이 계단식으로 이어집니다. 1장에서 '기억하는 AI'를 만들어 매번 같은 설명을 반복하지 않게 하고, 2장에서 그 위에 '안전하게 일을 맡기는 법'을 얹어 통제권을 손에 쥡니다. 3장에서는 '여러 일을 동시에 위임하고 외부 도구까지 확장하는 법'으로 올라가고, 4장에서 '한 번의 작업 세션을 컨텍스트·비용까지 챙겨 운영하는 법'으로 마무리합니다. 마지막 '막힐 때'에서는 자주 부딪히는 문제와 빠져나오는 길을 모았습니다. 앞 장이 뒷 장의 전제이므로 순서대로 읽는 편이 빠릅니다.
책 끝에는 슬래시 명령어·단축키·설정 파일을 한눈에 보는 치트시트, 자주 쓰는 워크플로, 용어집이 있습니다. 본문을 한 번 읽은 뒤에는 치트시트만 펼쳐두고 일해도 됩니다. 모든 명령어와 단축키는 공식 문서(code.claude.com/docs)를 근거로 했습니다.
이 가이드가 맞는 사람
- Claude Code를 깔았지만 /help만 누르다 끄는 실무자
- 복사·붙여넣기 AI에서 벗어나 코드베이스 전체를 맡기고 싶은 개발자
- 팀에 도입하기 전 안전 장치와 규칙을 먼저 세우려는 리드
- 토큰 비용과 컨텍스트를 통제하며 긴 작업을 끌고 가야 하는 1인 개발자
가장 쉬운 시작: 클로드 데스크톱 앱의 'Code' 탭, 또는 브라우저에서 아래 주소로 바로. 명령어 설치(curl·npm)는 개발자용 고급 방법이라 본문 뒤에서 다룹니다.
claude.ai/code 열기 ↗화면 미리보기


바로 쓰는 예시
설명은 뒤로 미루고, 지금 복사해서 바로 써볼 수 있는 것부터.
누구나 · 문서 정리
긴 회사 자료를 표 한 장으로
@보고서.pdf 이 자료를 정리해줘.
1) 결론 3줄
2) 핵심 숫자만 표로
3) 윗선 보고용 한 문장
추측하지 말고 자료에 있는 것만. 애매하면 [확인 필요]로 표시해줘.길들이기 · CLAUDE.md
이 한 장이면 매번 설명이 끝납니다
# 프로젝트 지침 (CLAUDE.md)
- 패키지매니저: pnpm (npm·yarn 금지)
- 빌드: pnpm build / 테스트: pnpm test:unit
- 커밋: Conventional Commits, 본문은 한국어
- 금지: src/legacy/* 는 리팩터링하지 말 것CHAPTER 00
시작하기
깔고, 로그인하고, 첫 명령을 내리기까지 — 그리고 어떤 플랜이 나에게 맞는지.
설치 없이, 클로드 데스크톱의 'Code' 탭으로 시작
개초보에게 가장 쉬운 길은 터미널이 아닙니다. 명령어를 칠 필요 없이 클로드 데스크톱 앱(또는 브라우저)으로 시작하세요. 데스크톱 앱을 깔았다면 앱을 열고 'Code' 탭을 누르면 되고, 설치가 부담되면 브라우저에서 claude.ai/code 로 바로 들어가도 똑같습니다. 둘 다 한 줄도 입력할 필요가 없습니다.
Code 화면이 열리면 ① 작업할 폴더(레포)를 '레포 선택'으로 고르고 ② 아래 입력창('작업을 설명하거나 질문하세요')에 "이 폴더가 뭐 하는 건지 설명해줘"처럼 한국어로 시키면 됩니다. 터미널·명령어 없이, 채팅하듯 일을 맡기는 게 전부입니다.
로그인은 Claude 구독(Pro·Max 등)으로 합니다. 처음 들어가면 구글 등으로 로그인만 하면 끝이고, 한 번 하면 다시 묻지 않습니다. 요금·플랜 선택 기준은 이 장 마지막 절에서 다룹니다.
(고급) 터미널에 익숙한 개발자라면 명령어로도 깔 수 있습니다 — 예: 'curl -fsSL https://claude.ai/install.sh | bash' 또는 'npm install -g @anthropic-ai/claude-code'. 하지만 처음이라면 위 앱·웹 방식이 훨씬 쉽고 자동 업데이트도 됩니다. 클릭만으로 따라 하는 그림 설치법은 '왕초보 시작하기'에 있습니다.
첫 세션, 무엇을 어떻게 시키나
폴더에서 claude 를 켜면 빈 프롬프트가 뜹니다. 여기서부터는 명령어 암기가 아니라 '말'로 시작합니다. "이 프로젝트 구조를 설명해줘" 같은 평범한 한국어 요청이면 충분합니다. Claude는 폴더의 파일을 알아서 읽어 답합니다. 코드를 복사해 붙여넣을 필요가 없다는 것이 채팅 AI와의 첫 번째 차이입니다.
특정 파일을 짚어주고 싶으면 @ 를 씁니다. '@src/app.ts 이 파일의 버그를 찾아줘'처럼 @ 뒤에 경로를 붙이면 그 파일을 콕 집어 참조합니다. 반대로 셸 명령을 직접 돌리고 싶으면 줄 맨 앞에 ! 를 붙입니다. '!npm test'는 Claude를 거치지 않고 바로 실행돼 그 결과가 대화에 들어옵니다.
일을 시키면 Claude는 곧장 고치지 않고 '무엇을 어떻게 바꿀지' 변경안(diff)을 먼저 보여줍니다. 마음에 들면 Enter로 적용하고, 아니면 거절한 뒤 방향을 다시 말합니다. 이 '요청 → 변경안 → 확인'의 한 박자가 Claude Code의 기본 리듬입니다. 익숙해지면 Shift+Tab으로 자동 적용 모드까지 올려 속도를 냅니다(2장).
첫 세션에서 굳이 외울 건 셋뿐입니다. 막히면 /help, 대화가 길어지면 /clear, 프로젝트를 처음 열었으면 /init. 나머지는 필요할 때 이 책의 치트시트를 펼치면 됩니다. 중요한 건 명령어 개수가 아니라 '말로 시키고 변경안을 확인하는' 리듬을 몸에 붙이는 것입니다.
어떤 플랜을 고를까
Claude Code 자체는 무료로 깔지만, 모델을 쓰려면 둘 중 하나가 필요합니다. Claude 구독이거나, Console API 크레딧입니다. 두 방식은 과금 구조가 달라, 쓰는 패턴에 맞춰 고르면 같은 돈으로 더 오래 일할 수 있습니다.
구독은 사용량 한도가 다른 계단으로 나뉩니다. 가볍게 쓰면 Pro(월 20달러 수준), 하루 종일 코딩에 쓰면 Max(한도 5배·20배, 월 100·200달러 수준)가 한도에 덜 부딪힙니다. 주의할 점은 팀 플랜입니다. 등급에 따라 Claude Code가 포함되지 않을 수 있어(표준형 제외, 프리미엄형 포함), 회사 도입 전에는 반드시 확인해야 합니다.
API(Console) 방식은 구독 한도 대신 토큰당 과금입니다. 모델별로 입력·출력 단가가 다르고(가벼운 Haiku가 가장 싸고 Opus가 가장 비쌉니다), 쓴 만큼만 냅니다. 사용량이 들쭉날쭉하거나 여러 명이 정산해야 하는 팀에 맞습니다.
고르는 기준은 단순합니다. '매일·예측 가능하게' 쓰면 구독이 마음 편하고, '가끔·몰아서·정산이 필요'하면 API가 합리적입니다. 어느 쪽이든 4장의 비용 다이얼(/model·/usage·/compact)을 함께 쓰면 지출이 조용히 새는 걸 막습니다. 한도를 자주 만나면 그때 상위 플랜으로 올리면 됩니다.
CHAPTER 01
기억하는 AI
Claude Code가 어제 알려준 규칙을 오늘도 기억하게 만드는 법 — CLAUDE.md, 계층 메모리, /init, 그리고 스스로 쌓는 자동 메모리.
CLAUDE.md, 프로젝트의 장기 기억
Claude Code의 세션은 기본적으로 휘발성입니다. 창을 닫으면 방금 알려준 빌드 명령도, '이 폴더는 건드리지 말라'는 당부도 사라집니다. 다음 날 다시 열면 또 처음부터 설명해야 합니다. 이건 모델의 한계가 아니라 대화라는 형식의 한계입니다. 사람도 메모를 남기지 않으면 어제 회의 내용을 잊습니다.
이 문제를 해결하는 것이 CLAUDE.md입니다. 프로젝트 루트에 두는 지침 파일로, 빌드·테스트 명령, 코딩 규칙, 디렉터리 구조, 금지사항을 적어두면 매 세션이 시작될 때 자동으로 컨텍스트에 들어옵니다. 사람이 새 팀원에게 건네는 온보딩 문서와 정확히 같은 역할입니다. 다른 점은, 이 문서를 읽는 동료가 매번 처음 오는 신입이라는 것뿐입니다.
구체적인 예를 들어보겠습니다. 어떤 프로젝트에서 테스트를 'npm test'가 아니라 'pnpm test:unit'으로 돌려야 하는데, 이걸 적어두지 않으면 Claude는 매번 일반적인 'npm test'를 시도하다 실패합니다. CLAUDE.md에 '테스트: pnpm test:unit' 한 줄을 적는 순간, 그 실패가 영구히 사라집니다. 빌드 명령, 환경 변수 위치, 자주 쓰는 디렉터리 별칭도 마찬가지입니다.
처음부터 길게 쓸 필요는 없습니다. 오히려 길고 추상적인 지침은 잘 지켜지지 않습니다. 'Claude가 자꾸 틀리는 것'을 한 줄씩 적어 나가는 게 가장 좋은 운영법입니다. 같은 실수를 두 번 보면, 세 번째를 막을 규칙을 CLAUDE.md에 적습니다. 문서가 쌓일수록 동료는 점점 우리 팀에 맞는 사람이 됩니다.
팀 공유와 개인 설정을 나누기
규칙에는 모두가 따라야 할 것과 나만의 취향인 것이 섞여 있습니다. '커밋 메시지는 Conventional Commits 형식으로'는 팀 전체의 약속이지만, '나는 설명을 한국어로 받고 싶다'는 개인의 취향입니다. 이 둘을 한 파일에 두면, 내 취향을 커밋하는 순간 동료들에게 강요하는 꼴이 됩니다.
Claude Code는 메모리 파일을 계층으로 나눠 이 문제를 풉니다. 팀이 공유할 규칙은 프로젝트 루트의 CLAUDE.md에 둡니다. 이 파일은 git에 커밋되어 모두에게 같은 지침을 줍니다. 반면 개인 설정은 CLAUDE.local.md에 둡니다. 이 파일은 .gitignore에 넣어 커밋되지 않게 합니다. 동료의 작업 방식을 강제하지 않으면서 내 환경만 길들이는 방법입니다.
더 넓은 범위도 있습니다. 어떤 프로젝트에서든 항상 적용하고 싶은 규칙은 홈 디렉터리의 ~/.claude/CLAUDE.md 에 둡니다. '항상 한국어로 답하라' 같은 개인 전역 규칙이 여기 어울립니다. 세 층위는 좁은 쪽이 넓은 쪽을 보강하는 방식으로 합쳐집니다. 즉 프로젝트 지침이 전역 지침 위에 얹히고, 개인 파일이 그 위에 한 겹 더 얹힙니다.
실무에서 가장 흔한 실수는 이 분리를 무시하고 전부 루트 CLAUDE.md에 넣는 것입니다. 그러면 PR 리뷰 때 '왜 한국어 주석 규칙이 들어왔냐'는 지적이 따라옵니다. 처음 한 번만 층위를 정해두면, 이후로는 '이건 팀 약속인가 내 취향인가'만 판단해 파일을 고르면 됩니다.
/init로 토대를 깔기
맨손으로 CLAUDE.md를 쓰는 것보다 빠른 방법이 있습니다. 프로젝트 폴더에서 /init 을 치면 Claude가 코드베이스를 훑어 빌드 명령·구조·관행을 추론한 CLAUDE.md 초안을 만들어 줍니다. package.json의 스크립트, 폴더 구조, 기존 설정 파일을 읽어 '이 프로젝트는 이렇게 돌아가는 것 같다'를 정리해 주는 것입니다.
다만 초안을 완성본으로 착각하면 안 됩니다. /init이 만든 문서는 추론의 결과이지 사실의 보증이 아닙니다. 효율적인 사용법은 초안에서 사실과 다른 부분을 덜어내고, 코드만 봐서는 알 수 없는 우리 팀의 금지사항과 암묵적 규칙을 더하는 것입니다. '이 레거시 모듈은 리팩터링하지 말 것' 같은 맥락은 코드에 적혀 있지 않으니 사람이 넣어야 합니다.
초안을 다듬을 때는 길이의 유혹을 경계하십시오. /init이 만든 문서가 두 페이지라면, 그중 절반은 Claude가 코드만 봐도 알아낼 수 있는 내용일 가능성이 큽니다. 정말 가치 있는 건 '코드에 없는 결정'입니다. 군더더기를 걷어내고 핵심만 남길수록 매 세션의 컨텍스트도 가벼워집니다.
/init은 일회성 작업이 아닙니다. 프로젝트 구조가 크게 바뀌거나 새 빌드 도구를 도입했을 때 다시 돌려 초안을 갱신하고, 거기에 사람의 판단을 다시 얹는 식으로 운영하면 문서가 코드의 현재 상태를 따라갑니다.
자동 메모리로 이어가기
CLAUDE.md가 '내가 적어주는 기억'이라면, 자동 메모리는 'Claude가 스스로 남기는 기억'입니다. Claude Code는 ~/.claude/projects/<프로젝트>/memory/MEMORY.md 같은 위치에 세션을 가로질러 유지되는 메모를 쌓고, 세션 시작 시 그 앞부분을 다시 불러옵니다. 지난 결정과 맥락이 다음 세션으로 이어지는 셈입니다.
두 기억의 성격은 다릅니다. CLAUDE.md는 안정적인 규칙을 담는 곳이고, 자동 메모리는 '지난번에 이 버그를 이렇게 고쳤다' 같은 진행 중인 맥락을 담는 곳입니다. 규칙은 사람이 의도적으로 적고, 맥락은 작업하며 자연히 쌓입니다. 이 둘을 합치면 동료는 우리 팀의 규칙뿐 아니라 코드베이스의 역사까지 아는 사람이 됩니다.
메모리는 /memory 로 직접 열어 편집할 수 있습니다. 자동으로 쌓인 메모 중 더는 유효하지 않은 결정이나 잘못 기록된 내용이 보이면 손으로 정리하십시오. 메모리도 결국 컨텍스트를 차지하므로, 오래된 정보가 쌓이기만 하면 오히려 방해가 됩니다.
정리하면 운영 흐름은 이렇습니다. /init으로 토대를 깔고, 팀 규칙은 CLAUDE.md에, 개인 취향은 CLAUDE.local.md에 나누고, 일하면서 발견한 규칙과 맥락은 /memory로 다듬어 나갑니다. 이 습관 하나가 '매번 처음부터 설명하는 AI'와 '우리 프로젝트를 아는 동료'를 가릅니다. 이제 기억하는 동료가 생겼으니, 다음 장에서는 그에게 일을 어디까지 맡길지를 정합니다.
CHAPTER 02
권한과 계획
기억하는 동료에게 일을 맡기되, 통제권은 내가 쥐는 법 — 권한 모드 순환, Plan Mode, 권한 설정, 그리고 되돌리기.
Shift+Tab으로 권한 모드를 순환하기
동료에게 일을 맡길 때 가장 중요한 질문은 '어디까지 스스로 하게 둘 것인가'입니다. 매번 확인받게 하면 느리고, 전부 맡기면 위험합니다. 신입에게 오타 수정까지 일일이 보고하게 하면 둘 다 지치고, 데이터베이스 삭제까지 맘대로 하게 두면 사고가 납니다. Claude Code는 이 균형을 권한 모드로 조절합니다.
단축키 Shift+Tab을 누르면 권한 모드가 default → acceptEdits → plan 순으로 순환합니다. default는 변경마다 사용자에게 확인을 받는 기본 모드입니다. 한 번 누를 때마다 다음 모드로 넘어가고, 끝까지 가면 다시 처음으로 돌아옵니다. 현재 어느 모드인지는 화면 하단에 표시됩니다.
각 모드의 쓰임은 분명합니다. default는 모든 변경에 멈춰 확인을 받으니 낯선 작업이나 위험한 구간에 적합합니다. acceptEdits는 파일 편집을 자동으로 적용해 흐름이 끊기지 않게 하는 모드로, 신뢰가 쌓인 반복 작업에 적합합니다. plan은 아무것도 바꾸지 않고 계획만 세우는 읽기 전용 모드입니다.
핵심은 작업의 위험도에 따라 모드 사이를 옮겨 다니는 것입니다. 익숙한 잔손질은 acceptEdits로 빠르게, 결과를 가늠하기 어려운 큰 변경은 plan으로 먼저 확인한 뒤 default로 신중하게. 흔한 실수는 한 모드에 눌러앉는 것입니다. 편하다고 종일 acceptEdits로 두면, 어느 순간 보지 못한 변경이 쌓여 있고 그제야 모드를 잊었다는 걸 깨닫습니다.
Plan Mode, 손대기 전에 지도를 받는다
큰 변경에서 가장 비싼 실수는 '엉뚱한 방향으로 빠르게 가는 것'입니다. 열 개 파일을 고친 뒤에야 접근이 틀렸음을 깨달으면, 되돌리는 비용이 만드는 비용보다 큽니다. Plan Mode는 이걸 막습니다. 이 모드에서 Claude는 코드를 읽고 분석할 수는 있지만 파일을 고치거나 명령을 실행하지는 않습니다. 대신 '무엇을, 어떤 순서로 바꿀지'에 대한 계획을 제시합니다.
흐름은 단순합니다. Plan Mode로 들어가 작업을 설명하면, Claude가 변경 계획을 내놓습니다. 그 계획을 검토하고, 빠진 것이나 위험한 것을 짚어 수정을 요청합니다. 계획이 마음에 들면 그때 비로소 편집 모드로 전환해 실행합니다. 방향을 확정한 뒤에 손을 대므로, 절반쯤 진행된 잘못된 변경을 되돌리는 비용이 사라집니다.
Plan Mode가 특히 빛나는 순간은 '내가 시스템을 완전히 이해하지 못한 채 변경을 시작할 때'입니다. 계획서를 읽으면 Claude가 어떤 파일을 건드릴 작정인지, 내가 미처 생각 못 한 의존 관계가 무엇인지 한눈에 보입니다. 계획에 등장한 낯선 파일 이름 하나가 '아, 거기까지 영향이 가는구나'를 알려주는 경우가 많습니다.
Plan Mode는 코드베이스가 클수록, 그리고 변경이 여러 파일에 걸칠수록 가치가 커집니다. 반대로 오타 하나 고치는 일에까지 계획을 요구하면 답답할 뿐입니다. '일단 시작하고 보자'는 유혹이 클 때일수록 지도를 먼저 받는 습관을 들이십시오.
권한을 규칙으로 굳히기
모드 순환이 '지금 이 순간의 신뢰 다이얼'이라면, 권한 설정은 '늘 적용되는 규칙'입니다. 매번 손으로 모드를 바꾸는 대신, 무엇을 항상 허용하고 무엇을 항상 막을지 미리 정해둘 수 있습니다. 이걸 관리하는 명령이 /permissions 입니다.
설정은 파일로 저장됩니다. 팀이 공유할 권한 규칙은 .claude/settings.json 에 두어 git으로 함께 관리하고, 나만의 권한 설정은 .claude/settings.local.json 에 둡니다. 메모리 파일과 같은 분리 원칙입니다. 팀 공통의 안전 규칙은 모두가 같은 걸 쓰고, 개인이 편의로 푸는 권한은 개인 파일에 두는 식입니다.
실용적인 패턴은 두 방향입니다. 위험한 명령은 아예 차단 목록에 넣어 실수로도 실행되지 않게 하고, 반복되는 안전한 작업은 자동 승인 목록에 넣어 매번 확인을 묻지 않게 합니다. 예를 들어 테스트 실행이나 포맷 명령처럼 결과가 뻔한 작업은 자동 승인으로 두면 흐름이 매끄러워집니다.
권한 설정을 너무 느슨하게 푸는 것이 가장 흔한 함정입니다. '귀찮으니 전부 허용'으로 두면 권한 모드라는 안전 장치 자체가 무의미해집니다. 자동 승인은 '결과를 되돌릴 수 있고, 매번 확인할 가치가 없는' 작업에만 한정하는 것이 원칙입니다.
되돌리기와 마지막 방어선
아무리 신중해도 잘못된 변경은 생깁니다. 중요한 것은 빠르게 되돌릴 수 있느냐입니다. Esc를 두 번 누르면 체크포인트 메뉴가 열려 이전 상태로 되감을 수 있고, /rewind 로도 직전 체크포인트로 돌아갈 수 있습니다. 작업이 산으로 갈 때 처음부터 다시 시작하는 대신 한 단계만 물리는 길입니다.
체크포인트는 '대화와 작업 상태'를 되감는 장치입니다. 그래서 Claude가 만든 변경의 흐름을 무를 때 강력합니다. 하지만 만능은 아닙니다. 체크포인트는 Claude의 작업 단위를 기준으로 동작하므로, 그 바깥에서 일어난 일은 책임지지 않습니다.
그래서 되돌릴 수 없는 작업은 따로 다뤄야 합니다. 파일을 영구 삭제하거나 git history를 강제로 덮어쓰는 일은 체크포인트로도 살릴 수 없습니다. 이런 명령 앞에서는 모드를 default로 낮추고, Claude의 실행 직전 확인을 반드시 눈으로 읽으십시오. 자동 승인 목록에 이런 위험 명령을 넣는 일만 피해도 큰 사고의 대부분을 막습니다.
정리하면 2장의 도구는 한 줄로 꿰입니다. 위험도에 따라 모드를 옮기고(Shift+Tab), 큰 변경은 지도를 먼저 받고(Plan Mode), 늘 적용할 규칙은 권한 설정으로 굳히고(/permissions), 그래도 어긋나면 되감는다(Esc Esc·/rewind). 통제권을 손에 쥐었으니, 다음 장에서는 한 명의 동료를 넘어 여러 일을 동시에 맡기는 단계로 갑니다.
CHAPTER 03
위임과 확장
한 명의 동료를 넘어, 여러 일을 동시에 맡기고 외부 도구까지 손에 쥐는 법 — 서브에이전트, Hooks, MCP, 그리고 Skills·Plugins.
서브에이전트, 일을 나눠 맡기기
혼자 모든 일을 순서대로 하면 느립니다. 테스트를 다 돌린 다음에야 문서를 손대고, 그게 끝나야 리팩터링을 시작하는 식이면 작업이 직렬로 줄을 섭니다. Claude Code는 서브에이전트로 이 줄을 끊습니다. 서브에이전트는 독립된 컨텍스트와 권한을 가진 보조 에이전트로, 본체와 별도의 작업 공간에서 움직입니다.
서브에이전트는 포그라운드로 결과를 기다리며 쓸 수도, 백그라운드로 던져놓고 다른 일을 이어갈 수도 있습니다. 한쪽이 긴 테스트를 백그라운드로 돌리는 동안 본체는 다음 기능을 설계하는 식의 병렬 작업이 가능합니다. 위임은 최대 5단계까지 중첩될 수 있어, 큰 작업을 잘게 쪼개 분담시키는 구조를 만들 수 있습니다. /agents 로 사용할 에이전트를 정의하고 관리합니다.
핵심은 '컨텍스트 분리'입니다. 각 서브에이전트는 자기 일에 필요한 맥락만 들고 가므로, 본체의 대화창이 잡다한 중간 산출물로 가득 차지 않습니다. 본체는 큰 그림을, 서브에이전트는 세부 실행을 맡는 분업이 자연스럽게 만들어집니다. 컨텍스트가 분리되면 긴 검색 결과나 로그가 본체 대화를 오염시키지 않아, 본체는 오래 또렷하게 일합니다.
주의할 점은 '나눌 가치가 있는 일만 나누는' 것입니다. 작은 단발 작업까지 서브에이전트로 던지면 오히려 조율 비용이 더 듭니다. 독립적으로 돌릴 수 있고, 결과만 받아 쓰면 되는 덩어리진 일에 위임이 어울립니다.
Hooks, 규칙을 부탁이 아니라 구조로
동료에게 매번 '커밋 전에 포맷을 돌려라'라고 말하는 건 지칩니다. 말로 하는 부탁은 잊히기 마련이고, 잊힌 한 번이 사고가 됩니다. Hooks는 이런 규칙을 자동화합니다. PreToolUse·PostToolUse 같은 라이프사이클 시점에 훅을 걸어, 특정 도구가 실행되기 직전이나 직후에 정해진 동작을 강제할 수 있습니다.
가장 흔한 쓰임은 편집 후 검증입니다. 파일 편집 직후 자동으로 린트를 돌리게 만들면, Claude가 만든 변경이 스타일 규칙을 어겼을 때 즉시 잡힙니다. 사람이 '포맷 돌렸어?'라고 물을 필요가 없어집니다. PreToolUse 훅으로는 특정 명령이 실행되기 전에 조건을 검사해 위험한 동작을 막을 수도 있습니다.
설정은 .claude/hooks.yaml 이나 settings에 둡니다. 어느 시점에, 어떤 조건에서, 무슨 동작을 할지를 선언적으로 적어두면 그 규칙이 매 세션 자동으로 적용됩니다. 사람의 기억력에 기대지 않고 구조로 굳히는 것이 Hooks의 본질입니다.
Hooks를 처음 쓸 때 흔한 함정은 너무 무거운 동작을 거는 것입니다. 모든 편집 후에 전체 빌드를 돌리게 하면 흐름이 매번 멈춥니다. 빠르고 부작용 없는 검증(린트·포맷 검사)부터 걸고, 무거운 검증은 커밋 직전 같은 드문 시점에만 거는 것이 좋습니다.
MCP, 손이 닿지 않던 도구를 잇는다
Claude Code는 기본적으로 파일과 셸을 다룹니다. 하지만 실무는 그 밖에도 데이터베이스, 이슈 트래커, 사내 API 같은 도구로 가득합니다. MCP(Model Context Protocol)는 이 간극을 메웁니다. Claude를 외부 도구·DB·API에 연결하는 개방 표준으로, MCP 서버를 붙이면 Claude가 그 도구를 자기 손으로 다룰 수 있게 됩니다.
구체적으로는 이런 일이 가능해집니다. MCP 서버를 통해 Claude가 데이터베이스를 직접 조회해 스키마를 확인하거나, 이슈 트래커에서 티켓 내용을 읽어와 그에 맞는 코드를 짜거나, 사내 API를 호출해 결과를 받아오는 일까지 합니다. 사람이 정보를 복사해 붙여넣던 단계가 사라지는 것입니다. /mcp 로 연결과 상태를 관리합니다.
Hooks가 '하지 말 것·반드시 할 것'을 강제하는 가드레일이라면, MCP는 '할 수 있는 일'의 범위를 넓히는 확장 포트입니다. 둘을 함께 쓰면 안전한 자동화와 넓은 도구 접근을 동시에 얻습니다. 다만 확장 포트는 그만큼 위험의 입구이기도 합니다.
MCP 서버는 Claude에게 실제 권한을 넘깁니다. DB를 조회한다는 건 그 DB에 접근할 자격을 넘긴다는 뜻입니다. 그래서 연결 전에 '이 서버가 무엇에 접근하고, 무엇을 할 수 있는지'를 반드시 확인해야 합니다. 출처가 불분명한 서버를 함부로 붙이는 일은, 신원을 모르는 사람에게 회사 출입증을 주는 것과 같습니다.
Skills와 Plugins, 워크플로를 재사용하기
자주 반복하는 작업 절차는 매번 설명할 게 아니라 묶어두는 게 낫습니다. Skills는 재사용 가능한 워크플로를 슬래시 명령어로 만들어 둔 것입니다. '대본을 검수하고 점수를 매겨라' 같은 다단계 절차를 하나의 /명령어로 호출할 수 있습니다. 한 번 잘 만들어 두면, 그 절차를 다시 풀어 설명할 필요가 없어집니다. /skills 로 사용 가능한 스킬을 봅니다.
Plugins는 더 큰 단위의 포장입니다. 스킬·서브에이전트·훅·MCP 설정을 한데 묶어 하나의 패키지로 배포할 수 있습니다. 흩어져 있던 규칙과 도구를 하나로 봉투에 담는 것입니다. 팀이 합의한 작업 방식 전체를 플러그인으로 만들어 공유하면, 새 멤버도 설치 한 번으로 같은 도구·규칙·워크플로를 갖게 됩니다.
이 둘의 관계는 분명합니다. 혼자 반복할 절차는 스킬로 만들고, 팀과 나눌 작업 방식 전체는 플러그인으로 포장합니다. 스킬이 한 가지 일을 잘하는 도구라면, 플러그인은 그 도구들과 규칙을 담은 공구함입니다.
이 장의 네 가지는 결국 하나의 방향을 가리킵니다. 일을 나누고(서브에이전트), 규칙을 굳히고(Hooks), 도구를 잇고(MCP), 그 전부를 재사용 가능하게 포장하는 것(Skills·Plugins). 동료 한 명을 잘 쓰는 단계에서, 잘 짜인 팀을 운영하는 단계로 넘어가는 길입니다. 다음 장에서는 이 모든 걸 한 번의 세션 안에서 컨텍스트와 비용까지 챙기며 끌고 가는 법을 다룹니다.
CHAPTER 04
세션을 운영하기
한 번의 작업을 끝까지 끌고 가는 운영의 기술 — 컨텍스트 관리, Plan→실행 루프, 체크포인트, 그리고 모델·비용 다이얼.
컨텍스트는 한정된 작업대다
Claude Code와의 한 세션은 무한한 메모리가 아닙니다. 대화가 길어질수록 컨텍스트라는 작업대 위에 정보가 쌓이고, 작업대가 꽉 차면 오래된 정보가 밀려나거나 응답이 느려지고 비싸집니다. 긴 작업을 끌고 가려면 이 작업대를 의식적으로 관리해야 합니다.
먼저 상태를 봐야 합니다. /context 로 현재 컨텍스트 사용량을 확인할 수 있습니다. 작업대가 얼마나 찼는지 모르면 언제 정리해야 할지도 알 수 없습니다. 사용량이 높아지면 응답이 둔해지는 게 느껴지는데, 그 전에 수치로 확인하는 습관을 들이는 편이 좋습니다.
정리에는 두 가지 길이 있습니다. 대화 흐름을 이어가야 하면 /compact 로 지금까지의 대화를 요약해 여유를 확보합니다. 핵심 맥락은 남기고 군더더기만 압축하는 방식입니다. 주제가 완전히 바뀌었다면 /clear 로 작업대를 통째로 비우고 새로 시작합니다. 이전 작업과 무관한 새 일을 시작하는데 옛 대화를 끌고 가면 컨텍스트만 낭비됩니다.
가장 흔한 실수는 정리 없이 한 세션을 무한정 늘리는 것입니다. 하루치 작업을 한 대화에 다 담으면, 후반부에는 초반 맥락이 흐려지고 비용만 불어납니다. '주제가 바뀌면 /clear, 길어지면 /compact'를 기본 반사로 두면 세션이 끝까지 또렷합니다. 이어갈 결정은 비우기 전에 /memory 로 메모리에 남겨 다음 세션에 전달하십시오.
Plan에서 실행으로, 그리고 다시 Plan으로
앞 장들의 도구는 따로 노는 게 아니라 하나의 루프로 엮입니다. 실전에서 큰 작업은 보통 이렇게 흐릅니다. plan 모드로 계획을 받고 → 검토해 다듬고 → acceptEdits로 빠르게 실행하고 → 결과를 확인하고 → 어긋나면 되감거나 다시 계획으로 돌아갑니다. 한 번에 끝내려 하지 않고, 작은 루프를 여러 번 도는 것이 핵심입니다.
이 루프가 중요한 이유는 '한 번의 거대한 위임'이 가장 위험하기 때문입니다. 큰 작업을 통째로 맡기고 끝에서 한 번에 확인하면, 중간에 어긋난 지점을 찾기 어렵고 되돌릴 양도 큽니다. 작은 단위로 계획-실행-확인을 반복하면, 매 루프의 결과를 눈으로 확인하며 방향을 바로잡을 수 있습니다.
확인 단계에서 /diff 가 핵심입니다. Claude가 무엇을 바꿨는지 변경 내역을 직접 읽어, 의도와 맞는지 검증합니다. 코드 리뷰가 필요하면 /review 나 /code-review 로 한 겹 더 검토를 받을 수 있습니다. 확인 없이 다음 단계로 넘어가는 순간, 루프의 안전 장치가 풀립니다.
한 가지 더. 루프의 한 바퀴가 끝날 때마다 컨텍스트 상태를 의식하십시오. 여러 바퀴를 돌다 보면 어느새 작업대가 꽉 찹니다. 큰 단계 사이사이에 /compact 로 정리하면, 긴 작업도 흐름을 잃지 않고 끝까지 굴러갑니다.
모델과 사고 강도, 비용의 다이얼
모든 작업에 가장 강한 모델과 가장 깊은 사고가 필요한 건 아닙니다. 오타 수정에 깊은 추론을 돌리는 건 시간과 비용의 낭비고, 복잡한 설계에 빠른 모델만 쓰는 건 품질의 손해입니다. Claude Code는 이 균형을 조절할 다이얼을 제공합니다.
/model 로 사용할 모델을 고르고, /effort 로 사고 강도(노력 수준)를 조절합니다. 빠른 응답이 필요하면 /fast 로 가벼운 모드를 쓸 수 있습니다. 단축키로도 빠르게 전환할 수 있어서, Alt+P로 모델을 고르고 Alt+T로 확장 사고를 토글하며 작업 성격에 맞게 즉석에서 조정할 수 있습니다.
실용적인 운영법은 '작업의 무게에 다이얼을 맞추는' 것입니다. 단순 반복이나 형식 정리는 빠른 모드로 비용을 아끼고, 아키텍처 결정이나 까다로운 버그 추적처럼 한 번의 실수가 비싼 작업은 사고 강도를 올려 신중하게 굴립니다. 한 다이얼에 고정하지 말고 작업마다 의식적으로 맞추는 것이 절약과 품질을 모두 잡는 길입니다.
비용 자체도 들여다봐야 합니다. /usage 로 사용량을 확인해, 어떤 작업이 비용을 많이 쓰는지 감을 잡으십시오. 컨텍스트를 방치한 채 강한 모델로 긴 세션을 끌면 비용은 조용히 불어납니다. 컨텍스트 관리(/compact·/clear)와 모델 다이얼(/model·/effort)을 함께 쓰는 것이 비용을 통제하는 두 손잡이입니다.
CHAPTER 05
막힐 때
첫날의 설치 오류부터 한참 쓴 뒤의 '왜 이렇게 됐지'까지 — 자주 막히는 지점과 빠져나오는 길.
설치·로그인이 안 풀릴 때
가장 흔한 첫 벽은 'command not found: claude'입니다. 십중팔구 설치는 됐지만 셸이 실행 파일 위치(PATH)를 모르는 경우입니다. 터미널을 완전히 닫았다 새로 열면 대개 풀리고, 그래도 안 되면 설치 안내가 알려준 경로를 PATH에 추가하면 됩니다. 네이티브 설치 방식을 쓰면 이 문제가 덜합니다.
로그인이 빙빙 도는 경우도 있습니다. 브라우저 인증 창이 떴는데 세션으로 돌아오지 못하면, 인증을 한 번 더 시도하거나 회사 네트워크·프록시·VPN이 막고 있지 않은지 봅니다. /login 으로 다시 시작할 수 있습니다.
설정을 바꿨는데 안 먹는 것 같을 때는 /doctor 가 먼저입니다. settings.json의 형식 오류, 적용되지 않은 훅, MCP 연결 실패 같은 걸 한 번에 짚어 줍니다. 셸에서 claude 가 아예 안 뜨면 'claude doctor'로 바깥에서 진단합니다.
검색이 파일을 못 찾는다면 ripgrep이 없는 환경일 수 있습니다. ripgrep을 설치하면 코드 검색이 정상화됩니다. 정리하면, 첫날 문제는 거의 다 네 가지 안에 있습니다 — PATH, 로그인, 설정 형식, 검색 도구. /doctor가 이 넷을 대신 짚어 줍니다.
Claude가 엉뚱하게 굴 때
방향이 틀린 변경을 만들었다면, 당황해서 처음부터 다시 시작할 필요 없습니다. Esc를 두 번 누르거나 /rewind 로 직전 체크포인트로 되감으면 됩니다(2장). 그리고 다음 큰 작업은 plan 모드로 계획을 먼저 받아, 손대기 전에 방향을 확정하십시오. 되돌리기는 사고 수습이고, plan은 사고 예방입니다.
같은 실수를 자꾸 반복한다면 그건 모델 탓이 아니라 적어두지 않은 규칙 탓입니다(1장). 'npm test가 아니라 pnpm test:unit' 같은 걸 CLAUDE.md에 한 줄 적는 순간 그 실수는 사라집니다. 세 번 말로 반복했다면 그건 CLAUDE.md에 들어갈 신호입니다.
분명히 적어둔 규칙까지 무시한다면 컨텍스트가 꽉 찼을 가능성이 큽니다. 대화가 길어지면 초반의 지침이 작업대 밑으로 밀려납니다. /context 로 사용량을 확인하고, /compact 로 요약하거나 /clear 로 비운 뒤 다시 시키면 규칙이 살아납니다(4장).
엉뚱한 파일을 건드리는 것도 흔합니다. @ 로 작업 범위를 좁혀 주고, 큰 변경은 plan으로 '어떤 파일을 건드릴 작정인지' 먼저 확인하세요. 계획서에 낯선 파일 이름이 보이면, 그게 바로 막아야 할 사고입니다.
느리거나 비싸질 때
세션이 느려지고 응답이 둔해지는 건 거의 컨텍스트 과포화 신호입니다. /context 로 작업대가 얼마나 찼는지 확인하고, 흐름을 이어가야 하면 /compact 로 요약해 여유를 만들고, 주제가 바뀌었으면 /clear 로 비우고 새로 시작하세요(4장). 느려졌다고 더 강한 모델로 올리는 건 대개 정반대 처방입니다.
비용이 조용히 새는 것 같으면 /usage 로 사용량을 들여다봅니다. 컨텍스트를 방치한 채 강한 모델로 긴 세션을 끌면 지출이 빠르게 붑니다. 작업의 무게에 모델을 맞추는 것이 기본입니다 — 가벼운 정리는 /fast 나 가벼운 모델로, 까다로운 설계만 사고 강도를 올려서(/model·/effort).
긴 검색 결과나 빌드 로그가 대화를 가득 채워 느려지는 경우도 많습니다. 이런 덩어리 작업은 서브에이전트로 분리하면 본체 대화가 깨끗하게 유지됩니다(3장). 본체는 큰 그림만 들고, 잡다한 중간 산출물은 보조에게 맡기는 구조입니다.
정리하면 느림·비용 문제의 두 손잡이는 컨텍스트 관리(/context·/compact·/clear)와 모델 다이얼(/model·/effort·/fast)입니다. 이 둘을 습관으로 두면, 같은 플랜으로도 훨씬 오래 일할 수 있습니다.
복구하고, 신고하기
세션을 실수로 닫았거나 터미널이 죽어도 작업이 사라지진 않습니다. 같은 폴더에서 'claude --continue'로 가장 최근 세션을 잇거나, 'claude --resume'(또는 세션 안에서 /resume)으로 지난 세션 목록에서 골라 재개할 수 있습니다. 어제 하던 작업을 오늘 그대로 이어가는 길입니다.
도구 자체의 버그로 보이면 /feedback 으로 Claude Code 안에서 바로 신고할 수 있고, 재현 방법이 분명하면 공식 GitHub 이슈에 올리면 됩니다. 내 설정 문제인지 도구 문제인지 헷갈릴 때는 역시 /doctor 로 먼저 가른 뒤 신고하는 편이 빠릅니다.
복구가 잦다면 습관을 한 번 점검해 볼 때입니다. 큰 작업을 plan→실행→확인의 작은 루프로 쪼개고(4장), 중간중간 /diff로 확인하면, 애초에 크게 되돌릴 일이 줄어듭니다. 사고는 늘 '확인하지 않은 한 번'에서 납니다.
마지막으로 한 가지. 이 장의 문제 절반은 1·2장을 건너뛴 결과입니다. 기억(CLAUDE.md)과 권한(모드·Plan)을 먼저 갖춰두면, 막힐 일 자체가 크게 줄어듭니다. 막힐 때 펴보는 장이지만, 진짜 처방은 앞 장에 있는 셈입니다.
치트시트 · 빠른 참조
슬래시 명령어
세션·컨텍스트
/clear대화를 비우고 새로 시작/compact대화를 요약해 컨텍스트 여유 확보/context현재 컨텍스트 사용량 보기/rewind이전 체크포인트로 되돌리기/resume이전 세션 이어서 재개
프로젝트·메모리
/init코드베이스 분석해 CLAUDE.md 초안 생성/memoryCLAUDE.md·메모리 파일 편집/agents서브에이전트 정의·관리/hooks라이프사이클 훅 설정/mcpMCP 서버 연결·상태 관리/skills사용 가능한 스킬 보기·관리
모델·성능
/model사용할 모델 선택/effort사고 강도(노력 수준) 조절/fast빠른 응답 모드/config설정 보기·변경
코드·검토
/diff변경 내역(diff) 확인/reviewPR·변경 검토/code-review작업 중 diff 코드 리뷰/security-review보안 관점 검토
권한·진단
/permissions허용·차단 권한 설정/login로그인·재인증(계정 전환)/feedback버그·피드백 신고/usage사용량·비용 확인/status현재 상태 확인/doctor설치·환경 점검/help명령어 도움말
워크플로
/plan변경 없이 계획만 세우기(Plan Mode)/deep-research다중 소스 심층 리서치/workflows워크플로 실행·관리
키보드 단축키
모드
- Shift+Tab권한 모드 순환(default → acceptEdits → plan)
- Esc Esc체크포인트 메뉴(이전 상태로 되돌리기)
입력
- Enter메시지 전송
- Ctrl+J줄바꿈(전송 없이)
- @파일·디렉터리 참조
- !셸 명령 직접 실행
- Esc현재 작업 취소
세션
- Ctrl+C실행 취소
- Ctrl+D세션 종료
- Ctrl+R입력 기록 검색
- Ctrl+O대사(출력) 토글
모델·사고
- Alt+P모델 선택
- Alt+T확장 사고 토글
- Alt+O빠른 모드 토글
설정 파일
| 파일 | 위치 | 용도 |
|---|---|---|
CLAUDE.md | 프로젝트 루트 | 팀 공유 지침(빌드·규칙·금지사항). 매 세션 자동 로드 |
CLAUDE.local.md | 프로젝트 루트(.gitignore) | 커밋되지 않는 개인 설정 |
~/.claude/CLAUDE.md | 홈 디렉터리 | 모든 프로젝트에 적용되는 전역 지침 |
MEMORY.md | ~/.claude/projects/<프로젝트>/memory/ | 세션을 가로질러 유지되는 자동 메모리 |
.claude/settings.json | 프로젝트 | 권한·설정(팀 공유, git 커밋) |
.claude/settings.local.json | 프로젝트 | 권한·설정(개인, 비커밋) |
.claude/hooks.yaml | 프로젝트 | 라이프사이클 훅 정의(PreToolUse·PostToolUse 등) |
~/.claude/keybindings.json | 홈 디렉터리 | 단축키 커스터마이즈 |
실전 워크플로
설치부터 첫 세션까지
- 네이티브 설치(curl ... install.sh) 또는 npm 전역 설치 후 작업 폴더로 이동
- claude 실행 → 브라우저 로그인(OAuth). 막히면 claude doctor 로 점검
- "이 프로젝트 설명해줘"로 첫 대화, @로 파일 짚고 !로 셸 실행 익히기
- /init 으로 CLAUDE.md 초안을 깔아 다음 세션부터 기억하게 만들기
막혔을 때 빠져나오기
- 설치·실행 문제면 claude doctor → PATH·로그인·설정 순서로 점검
- 엉뚱한 변경이면 Esc Esc·/rewind로 되감고, 다음엔 plan으로 먼저
- 느리거나 비싸지면 /context 확인 → /compact·/clear, 모델은 /model·/fast로 조정
- 세션이 꼬이면 claude --continue 로 복구, 도구 버그면 /feedback 으로 신고
안전하게 큰 변경 하기
- Shift+Tab으로 plan 모드 진입 또는 /plan 으로 계획만 먼저 받기
- 제시된 계획을 검토하고 빠진 것·위험한 것을 짚어 수정 요청
- 계획이 확정되면 acceptEdits 모드로 전환해 실행
- /diff 로 변경을 확인한 뒤 커밋. 어긋나면 Esc Esc로 되돌리기
컨텍스트가 꽉 찼을 때
- /context 로 현재 컨텍스트 사용량 확인
- 대화 흐름을 이어가야 하면 /compact 로 요약해 여유 확보
- 주제가 완전히 바뀌면 /clear 로 비우고 새로 시작
- 이어갈 결정·맥락은 비우기 전에 /memory 로 메모리에 남겨 다음 세션에 전달
새 프로젝트에 Claude 길들이기
- 프로젝트 폴더에서 claude 실행 후 /init 으로 CLAUDE.md 초안 생성
- 초안에서 사실과 다른 부분을 덜고 '빌드 명령'과 '하지 말 것'을 직접 추가
- 개인 취향은 CLAUDE.local.md, 팀 권한 규칙은 .claude/settings.json 으로 분리
- 반복 검증은 /hooks 로, 외부 도구 접근은 /mcp 로 연결해 작업 환경 완성
핵심 용어
- CLAUDE.md
- 프로젝트 루트에 두는 지침 파일. 빌드 명령·규칙·금지사항을 적으면 매 세션 자동으로 컨텍스트에 로드된다.
- 계층 메모리
- 지침 파일을 범위별로 나눈 구조. 팀 공유는 CLAUDE.md, 개인은 CLAUDE.local.md, 전역은 ~/.claude/CLAUDE.md에 두고 좁은 쪽이 넓은 쪽을 보강한다.
- 자동 메모리
- Claude가 세션을 가로질러 스스로 유지하는 메모(MEMORY.md). 세션 시작 시 앞부분이 다시 로드된다.
- 권한 모드
- Claude가 변경을 얼마나 자율적으로 적용할지 정하는 단계. Shift+Tab으로 default·acceptEdits·plan을 순환한다.
- Plan Mode
- 파일을 바꾸지 않고 읽기 전용으로 변경 계획만 세우는 모드. 큰 변경 전 방향을 확정할 때 쓴다.
- 체크포인트
- Claude의 작업 단위를 기준으로 저장되는 복귀 지점. Esc Esc 또는 /rewind로 이전 상태로 되감을 수 있다.
- 서브에이전트
- 독립된 컨텍스트와 권한을 가진 보조 에이전트. 포그라운드·백그라운드로 병렬 작업하며 최대 5단계까지 중첩된다.
- Hooks
- PreToolUse·PostToolUse 등 라이프사이클 시점에 거는 자동 동작. 규칙을 부탁이 아니라 구조로 강제한다.
- MCP
- Model Context Protocol. Claude를 외부 도구·DB·API에 연결하는 개방 표준.
- Skills / Plugins
- Skills는 재사용 가능한 워크플로를 슬래시 명령어로 만든 것. Plugins는 스킬·서브에이전트·훅·MCP를 묶어 배포하는 패키지다.
- /doctor
- 설치·설정·MCP 연결·컨텍스트 상태를 한 번에 점검하는 진단 명령. 셸에서는 claude doctor 로도 실행한다.
- 헤드리스 모드
- claude -p "질문" 처럼 대화 세션 없이 한 번 묻고 끝내는 실행 방식. 스크립트·자동화에 쓴다.
- OAuth 로그인
- claude 첫 실행 시 브라우저로 인증하는 방식. 구독(Pro·Max) 또는 Console API 크레딧으로 붙으며, /login 으로 다시 인증한다.
출처 · 공식 문서
- Setup — https://code.claude.com/docs/en/setup
- Quickstart — https://code.claude.com/docs/en/quickstart
- Troubleshooting — https://code.claude.com/docs/en/troubleshooting
- Pricing — https://claude.com/pricing
- Commands — https://code.claude.com/docs/en/commands
- Memory — https://code.claude.com/docs/en/memory
- Keybindings — https://code.claude.com/docs/en/keybindings
- Sub-agents — https://code.claude.com/docs/en/sub-agents
- MCP — https://code.claude.com/docs/en/mcp
다음 권도 있습니다
Codex CLI(엔지니어형)·Gemini CLI(확장형) 가이드북도 같은 시리즈로 나옵니다. 세 도구를 같은 구조로 비교하며 내 워크플로에 맞는 도구를 고르세요.
ai.dingco × ai.crew
다음 단계
혼자 막히지 말고, 같이 하세요
따라 하다 막히는 부분은 ai.crew 카톡방에서 물어보고, 끝냈으면 결과를 공유해 주세요. 비개발자 직장인끼리 세팅을 돕는 방입니다. 새 가이드·실전 프롬프트는 뉴스레터로도 보내드려요.
Newsletter
매주 금요일 아침, 한 통
이번 주 직장인이 진짜 써먹을 AI 한 가지. 광고 없이, 현직자가 검증한 것만.
언제든 구독 해지 가능 · 스팸 없음