[Claude 활용 24회 — AI에게 일을 위임하는 법] 3/24화: Claude Code 설치 가이드 2026 — 30분 만에 첫 성공까지
지난주 후배 한 명이 메신저로 Claude Code 설치 방법을 물었다.
“Claude Code 깔아봤는데, 뭘 해야 할지 모르겠어요. 그냥 채팅창 아닌가요?”
솔직히 나도 처음엔 그랬다. 작년 말, Claude Code 설치를 마치고 터미널을 열었을 때 한 일이라곤 우리 팀의 10만 줄짜리 레거시 코드베이스를 통째로 던진 것이었다. “이 프로젝트를 분석하고 개선점을 알려줘.” 그럴듯해 보이는 지시였다. 결과? AI가 7분 넘게 코드를 훑더니, 맥락을 절반쯤 잃은 채 전혀 엉뚱한 패키지 구조 리팩터링을 제안했다. 빌드조차 안 되는 코드를 자신 있게 내놓았다.
그때 내 판단은 단순했다. ‘아직 쓸 물건이 아니구나.’ 서랍에 넣었다.
석 달 뒤 동료가 같은 도구로 테스트 코드를 뚝딱 만들어내는 걸 보고 다시 꺼냈다. 그제야 깨달았다. 도구가 문제가 아니었다. 내가 첫 30분을 완전히 잘못 시작한 것이었다. 첫 과제가 너무 컸고, 프로젝트 맥락을 AI에게 제대로 알려주지 않았으며, 심지어 권한 설정까지 건드려서 자동으로 파일을 수정하게 풀어놨다. 세 가지 실수를 한꺼번에 저질렀다.
이 글은 그 삽질을 거름 삼아 쓴다. Claude Code 설치부터 첫 번째 의미 있는 결과를 얻기까지, 개발자와 비개발자 두 갈래 경로를 30분 안에 완주하는 가이드다. Anthropic 공식 문서에 설치법은 나와 있지만, “설치 다음에 뭘 하느냐”에 대한 이야기는 빠져 있다. 그 빈칸을 채우려 한다.
1화에서 2026년 7월 Claude 생태계에 판이 바뀐 네 가지 이유를 이야기했고, 2화에서 Cowork가 클라우드로 간 의미를 짚었다. 오늘은 직접 손을 움직인다. 읽기만 하는 회차는 여기서 끝이다.
새 도구의 30분 법칙 — 왜 첫 경험이 모든 걸 결정하는가
개발 도구든 생산성 앱이든, 새로운 소프트웨어의 운명은 첫 30분에 결정된다. 소프트웨어 온보딩 연구들이 공통적으로 가리키는 숫자가 있다. 첫 세션에서 의미 있는 결과를 얻지 못한 사용자의 60~70%는 다시 돌아오지 않는다. 업계에서 “Time to First Value”라고 부르는 지표다. 첫 번째 가치까지의 시간.
나는 이 함정에 정확히 빠졌다. 세 시간을 써서 얻은 건 빌드가 안 되는 리팩터링 제안뿐이었다. 그 세 시간 동안 “이 도구는 아직 쓸 게 못 된다”는 결론을 내렸고, 석 달이나 버려졌다. 석 달이다. 그 시간에 동료는 이미 매일 쓰고 있었다.
Claude Code의 첫 경험이 특히 중요한 이유가 있다. 이건 채팅창이 아니다. 터미널 안에서 돌아가는 에이전트다. 내 파일 시스템을 읽고, 코드를 수정하고, 명령을 실행한다. 일반 챗봇처럼 “안녕, 뭐든 물어봐”로 시작하면 방향을 잃는다. 프로젝트 폴더 안에서, 구체적인 한 가지 과제를 던져야 한다.
그리고 이 도구는 두 갈래 길을 제공한다.
- 개발자 경로: 터미널 CLI — 코드 프로젝트에 직접 투입. 파일을 읽고, 수정하고, 테스트를 돌리고, Git 커밋까지 한다.
- 비개발자 경로: Claude 데스크톱 앱 — 폴더를 연결하면 문서, 데이터, 이미지 등 파일 기반 작업을 수행한다. 2화에서 다룬 Cowork 웹 버전도 여기에 해당한다.
어느 쪽이든 원칙은 같다. 작은 과제 하나를 확실히 성공시키는 것. 10만 줄 레거시가 아니라, README 파일 하나. 100페이지 보고서가 아니라, 회의록 정리 하나. 첫 과제에서 “이게 되네?”라는 감각을 잡으면, 그다음부터는 자연스럽게 확장된다.

위 다이어그램이 오늘 걸어갈 두 갈래 길이다. 먼저 개발자 경로부터 가보자.
개발자 경로 — Claude Code 설치부터 첫 명령까지 5단계
개발자 경로는 터미널에서 시작하고 터미널에서 끝난다. IDE를 열 필요 없다. Claude Code는 VS Code 확장이 아니다. 독립적인 CLI 도구이고, 내 프로젝트 폴더 안에서 파일 시스템 전체를 맥락으로 사용한다. 이게 일반 AI 챗봇과 결정적으로 다른 지점이다.
1단계 — 사전 준비: Node.js 18 이상 확인 (0~3분)
Claude Code는 npm 패키지로 배포된다. Node.js가 필요하다. 터미널을 열고 버전을 확인한다.
node -v
v18.0.0 이상이 출력되면 통과. 아무것도 안 나오거나 버전이 낮으면 Node.js 공식 사이트에서 LTS(Long Term Support) 버전을 받는다. 2026년 8월 기준 LTS는 v22.x 계열이다.
Windows라면 설치 파일을 다운로드해서 실행하면 된다. 기본 옵션 그대로 Next-Next-Finish. macOS라면 brew install node도 좋다. 핵심은 Node.js 18 이상이라는 것뿐이다.
설치 후 터미널을 새로 열고(이전 터미널은 PATH가 반영 안 되어 있을 수 있다) 다시 확인한다.
node -v
# v22.x.x 같은 출력이 나오면 성공
npm -v
# 10.x.x 같은 출력이 나오면 성공
npm은 Node.js에 자동으로 딸려온다. 별도 설치할 필요 없다.
자주 막히는 지점: 회사 프록시 환경이라면 npm config set proxy와 npm config set https-proxy를 먼저 설정해야 한다. 규제가 강한 환경에서 일하는 분이라면, 이 단계에서 사내 프록시 주소를 확인하고 넣어두자. 집에서 개인 노트북으로 한다면 이 문제는 건너뛰면 된다.
2단계 — 설치 한 줄 (3~5분)
npm이 확인됐으면 설치는 정말 한 줄이다.
npm install -g @anthropic-ai/claude-code
-g는 글로벌 설치를 뜻한다. 시스템 어디서든 claude 명령을 쓸 수 있게 된다. 설치에 1~2분 정도 걸린다. 네트워크 상태에 따라 다르다.
설치가 끝나면 확인한다.
claude --version
버전 번호가 출력되면 설치 완료. 여기서 막히는 경우가 두 가지 있다.
권한 오류 (EACCES): macOS/Linux에서 글로벌 설치 시 권한이 없다는 에러가 나올 수 있다. sudo npm install -g를 쓰는 것보다 npm의 디렉터리 권한 설정을 바꾸는 편이 낫다. 또는 nvm(Node Version Manager)을 쓰면 이 문제가 아예 발생하지 않는다.
‘claude’를 찾을 수 없음: Windows에서 claude 명령이 인식되지 않으면 터미널을 새로 열어본다. 그래도 안 되면 npm 글로벌 설치 경로가 PATH에 있는지 확인한다.
# Windows PowerShell
npm config get prefix
# 출력된 경로 아래 node_modules/.bin 이 PATH에 있어야 한다
# macOS/Linux
which claude
# 경로가 출력되면 정상
대부분의 경우 터미널을 새로 여는 것으로 해결된다. 설치 과정에서 PATH가 갱신되는데, 기존 터미널에는 반영이 안 되기 때문이다.
Windows에서 대안 설치 방법: winget install Anthropic.ClaudeCode로도 설치할 수 있다. winget이 PATH를 자동 등록해주기 때문에 npm보다 편할 수 있다. scoop install claude-code도 가능하다. 어떤 방법이든 결과는 같다 — 터미널에서 claude를 칠 수 있으면 된다.
3단계 — 첫 실행과 인증 (5~10분)
설치가 끝났다. 이제 아무 디렉터리에서나 실행해보자.
claude
첫 실행이면 브라우저가 자동으로 열린다. Anthropic 계정으로 로그인하라는 화면이 뜬다. 계정이 없으면 여기서 만들면 된다.
구독 요금제에 대해: Claude Code를 사용하려면 유료 구독이 필요하다. 2026년 8월 기준으로 선택지는 두 가지다.
- Pro 요금제: 월 $20. Claude Code 사용 가능하지만 일일 사용량 제한이 있다. 가볍게 시도해보기에 적합하다.
- MAX 요금제: 월 $100 또는 $200. 사용량 제한이 대폭 완화되거나 사실상 무제한. 업무에 본격 투입할 때 필요하다.
오늘 목표는 ‘첫 성공 경험’이다. Pro로 시작해도 충분하다. 하루에 몇 번 정도 써보는 건 Pro 한도를 넘지 않는다. 나중에 매일 수십 건씩 돌리기 시작하면 그때 MAX를 고려하면 된다.
인증이 완료되면 터미널에 대화형 프롬프트가 뜬다. 커서가 깜빡이며 입력을 기다리는 상태. 여기까지 왔으면 설치는 끝났다.
╭─────────────────────────────────────────╮
│ Claude Code │
│ │
│ /help for available commands │
│ │
│ cwd: /Users/you │
╰─────────────────────────────────────────╯
>
위와 비슷한 화면이 보인다면 성공이다. 정확한 모양은 버전에 따라 다르지만, 핵심은 > 프롬프트가 떠서 입력을 받는 상태라는 것이다.
하지만 여기서 바로 “내 프로젝트 분석해줘”를 타이핑하면 안 된다. 아직 어떤 프로젝트 폴더에도 들어가지 않았기 때문이다. Claude Code는 현재 디렉터리(cwd)를 기준으로 파일을 읽는다. 홈 디렉터리에서 시작하면 아무 맥락도 없다.
일단 Ctrl+C나 /exit으로 나온다. 다음 단계로 가자.
4단계 — 프로젝트 폴더에서 /init (10~15분)
이 단계가 핵심이다. 내가 첫날 놓친 것이 바로 이것이다.
먼저, 작업할 프로젝트 폴더로 이동한다. 기존 프로젝트가 있다면 그 폴더로 가면 된다. 아직 프로젝트가 없다면, 연습용으로 하나 만들자.
# 기존 프로젝트가 있다면
cd ~/projects/my-existing-project
# 없다면 연습용 폴더 생성
mkdir ~/claude-practice
cd ~/claude-practice
git init
Git 저장소를 권장하는 이유: Claude Code는 Git이 초기화된 폴더에서 가장 잘 동작한다. 파일 변경 이력을 추적할 수 있고, AI가 수정한 내용을 git diff로 한눈에 볼 수 있기 때문이다. 필수는 아니지만, 강력히 권장한다.
프로젝트 폴더에서 Claude Code를 실행한다.
claude
이제 /init을 입력한다.
/init
/init은 현재 프로젝트를 Claude Code에 소개하는 명령이다. 실행하면 프로젝트 루트에 CLAUDE.md라는 파일이 생긴다. 이 파일은 AI가 프로젝트를 이해하기 위한 지침서다. 프로젝트의 구조, 빌드 방법, 테스트 방법, 코딩 컨벤션 같은 정보가 들어간다.
처음 /init을 실행하면 Claude가 프로젝트 파일들을 훑어보고 CLAUDE.md 초안을 자동으로 작성한다. 이게 핵심이다. AI에게 “넌 지금 어떤 프로젝트에서 일하고 있어”를 알려주는 것.
내가 첫날 이걸 건너뛰고 바로 10만 줄을 던졌다. AI는 프로젝트가 뭘 하는 건지, 빌드는 어떻게 하는 건지, 테스트는 어떻게 돌리는 건지 아무것도 모르는 상태에서 코드를 분석해야 했다. 당연히 엉뚱한 결과가 나왔다.
CLAUDE.md가 생겼으면 한번 열어본다. 자동 생성된 내용이 맞는지 확인하고, 틀린 부분이 있으면 직접 수정해도 좋다. 이 파일은 5화에서 깊이 있게 다룰 예정이니, 지금은 “이런 게 있구나” 정도만 알아두면 된다.
# CLAUDE.md 예시 (자동 생성된 모습)
# My Project
## Build
npm install && npm run build
## Test
npm test
## Conventions
- TypeScript strict mode
- ESLint + Prettier
- Feature branch workflow
자동 생성 내용이 빈약하더라도 걱정할 필요 없다. 지금은 첫 성공 경험이 목표다. CLAUDE.md는 쓰면서 점진적으로 다듬어가면 된다.
5단계 — 알아야 할 슬래시 명령 5개 (15~20분)
Claude Code 안에서 슬래시(/)로 시작하는 명령들이 있다. 이건 AI에게 하는 지시가 아니라 도구 자체를 제어하는 명령이다. 채팅과 관리 명령을 구분하는 문법이라고 생각하면 된다.
첫날 알아야 할 건 딱 다섯 개다.
1. /init — 프로젝트 초기화
방금 썼다. CLAUDE.md를 생성하고 프로젝트 맥락을 설정한다. 프로젝트당 한 번만 하면 된다. 이미 CLAUDE.md가 있는 프로젝트에서는 다시 할 필요 없다.
2. /context — 컨텍스트 사용량 확인
/context
현재 대화에서 컨텍스트 윈도우를 얼마나 사용하고 있는지 보여준다. AI 모델은 한 번에 처리할 수 있는 텍스트 양에 한계가 있다. 이걸 ‘컨텍스트 윈도우’라고 부른다. 파일을 많이 읽거나 대화가 길어지면 이 공간이 차는데, 가득 차면 오래된 대화 내용부터 잘려나간다.
처음엔 이 숫자가 뭔지 감이 안 올 텐데, 일단 “80%를 넘으면 대화를 새로 시작하는 게 낫다” 정도만 기억하자. 7화에서 컨텍스트 관리를 본격적으로 다룬다.
3. /effort — 응답 깊이 조절
/effort high
세 단계가 있다: low, medium, high. 이건 AI가 얼마나 깊이 생각하고 답할지를 조절하는 스위치다.
low: 간단한 질문, 빠른 답변. “이 함수 뭐 하는 거야?”medium: 기본값. 대부분의 작업에 적합.high: 복잡한 설계, 대규모 리팩터링, 까다로운 버그. 시간은 더 걸리지만 품질이 올라간다.
첫날은 medium(기본값)으로 두자. 나중에 작업 성격에 따라 전환하는 감각이 생긴다.
4. /color — 터미널 색상 테마
/color
가독성에 의외로 큰 영향을 준다. 터미널 배경이 어두운 사람은 dark 계열로, 밝은 사람은 light 계열로 맞추면 된다. 사소한 것 같지만, 코드 diff를 볼 때 색상이 안 맞으면 눈이 아프다. 첫 설정 때 한 번 해두면 된다.
5. /help — 전체 명령 목록
/help
모든 슬래시 명령의 목록과 간단한 설명을 보여준다. 뭐가 있는지 한번 훑어보면 “이런 것도 되는구나”라는 게 보인다. 나머지는 필요할 때 찾으면 된다.

이 다섯 개면 첫날은 충분하다. 나머지 명령은 쓰다 보면 자연스럽게 필요해진다. /compact(대화 압축), /review(코드 리뷰 요청), /clear(대화 초기화) 같은 건 7화와 8화에서 제대로 다룬다.
Claude Code 설치 트러블슈팅 — 자주 막히는 곳 3가지
온보딩 과정에서 사람들이 자주 막히는 지점을 모았다. 내가 직접 겪거나 주변에서 들은 것들이다.
문제 1: “npm install이 한참 걸린 뒤 실패해요”
회사 네트워크에서 npm 레지스트리 접근이 차단되었을 가능성이 높다. 규제가 강한 환경에서 흔하다. 해결 방법은 두 가지다.
- 사내 프록시 설정:
npm config set proxy http://프록시주소:포트 - 개인 네트워크(테더링 등)로 전환해서 설치. 설치 후에는 사내 네트워크에서도 실행 가능하다.
문제 2: “claude 명령이 인식 안 돼요”
95%는 터미널을 새로 열면 해결된다. 나머지 5%는 npm 글로벌 경로가 시스템 PATH에 빠져 있는 경우다.
# npm 글로벌 경로 확인
npm config get prefix
# 출력 예: /usr/local (macOS/Linux) 또는 C:\Users\you\AppData\Roaming\npm (Windows)
# 이 경로가 시스템 PATH에 있어야 한다
Windows라면 winget install Anthropic.ClaudeCode로 재설치하는 편이 빠를 수 있다. winget은 PATH를 자동 처리한다.
문제 3: “인증 화면이 안 떠요” 또는 “브라우저가 안 열려요”
SSH 원격 접속 환경에서 흔하다. 브라우저가 없는 서버에서 claude를 실행하면 URL이 텍스트로 출력된다. 그 URL을 로컬 브라우저에 복사해서 열면 된다. 인증은 로컬 브라우저에서 하고, 토큰이 서버 쪽에 전달되는 구조다.
WSL(Windows Subsystem for Linux)에서도 비슷한 문제가 생길 수 있다. WSL 안에서 Windows 쪽 브라우저를 못 여는 경우인데, 역시 출력된 URL을 수동으로 Windows 브라우저에 붙여넣으면 해결된다.
비개발자 경로 — Claude 데스크톱 앱으로 30분 온보딩
여기서부터는 코드를 쓰지 않는 분들을 위한 경로다. 기획자, 마케터, PM, 디자이너, 콘텐츠 제작자 — 터미널이 무엇인지 몰라도 상관없다. Claude를 ‘파일 작업이 가능한 AI 동료’로 쓰는 방법이다.
설치: 앱 하나 깔면 끝
Claude 데스크톱 앱은 Windows와 macOS에서 사용할 수 있다. claude.ai 사이트에 접속해서 데스크톱 앱 다운로드 링크를 찾거나, 직접 검색해서 설치한다. 일반 프로그램 설치와 동일하다 — 다운로드, 실행, 다음-다음-완료.
설치 후 Anthropic 계정으로 로그인하면 대화 화면이 열린다. 여기까지는 웹에서 쓰는 Claude와 같아 보인다. 하지만 결정적인 차이가 하나 있다.
데스크톱 앱은 내 컴퓨터의 파일을 읽을 수 있다.
웹 브라우저의 Claude는 채팅만 된다. 파일을 올려서 분석시킬 수는 있지만, 내 하드디스크에 있는 폴더를 탐색하거나 파일을 직접 생성·수정하지는 못한다. 데스크톱 앱은 이게 된다. 이 차이가 “채팅 도구”와 “일을 위임받는 에이전트”의 경계선이다.
폴더 연결 — AI에게 작업 공간을 알려주는 법
데스크톱 앱을 설치했다면, 다음 단계는 작업 폴더를 연결하는 것이다. 이건 “이 폴더 안의 파일들을 읽고 작업해도 좋다”고 AI에게 허가하는 행위다.
방법은 간단하다. 대화 화면에서 프로젝트를 만들 때 로컬 폴더를 지정하거나, 설정 메뉴에서 작업 디렉터리를 추가하면 된다.
폴더 선택 팁:
- 처음엔 범위가 좁은 폴더를 고른다. “내 문서” 전체가 아니라, 특정 프로젝트 폴더 하나.
- 민감한 파일(개인정보, 계약서 원본, 급여 명세 등)이 없는 폴더로 시작한다.
- AI가 파일을 수정할 때 확인을 요청하도록 기본 설정을 유지한다. 절대 자동 승인으로 바꾸지 않는다.
2화에서 짚었듯, Cowork 웹 버전(클라우드 실행)은 내 로컬 파일에 자동 접근하지 못한다. 클라우드에서 돌리려면 파일을 업로드하거나, 연동 서비스(Google Drive 등)를 커넥터로 연결해야 한다. 로컬 파일 작업은 데스크톱 앱이 훨씬 직관적이다.
첫 대화 — 무엇을 물어볼 것인가
폴더가 연결되면 이제 대화할 수 있다. 하지만 “아무거나 물어보세요”라는 빈 화면 앞에서 멈추는 사람이 많다. 뭘 시키지?
비개발자의 첫 대화는 폴더 탐색으로 시작하는 걸 권한다.
이 폴더에 어떤 파일들이 있는지 목록을 만들고,
각 파일이 어떤 내용인지 한 줄로 요약해줘.
이 한 마디로 AI가 폴더를 훑고 정리해준다. 결과를 보면 “아, 내 파일을 정말로 읽는구나”라는 감각이 생긴다. 이게 첫 번째 확인 지점이다.
그다음, 구체적인 작업을 하나 시킨다. 이건 바로 다음 섹션에서 다룬다.
첫 과제 추천 2종 — 이것부터 시켜보세요
도구를 설치했고, 프로젝트를 연결했다. 이제 첫 번째 “진짜 일”을 시킬 차례다. 여기서 과제 선택이 정말 중요하다. 너무 크면 실패하고, 너무 작으면 감흥이 없다. 내가 여러 번 시행착오를 거쳐 찾은 ‘골디락스 과제’ 두 가지를 소개한다.
개발자용 첫 과제 — README 다시 쓰기
프로젝트 폴더에서 Claude Code를 열고, 이렇게 말한다.
이 프로젝트의 README.md를 다시 써줘.
처음 합류한 신입 개발자가 이 문서만 보고
로컬에서 프로젝트를 클론하고, 의존성을 설치하고,
개발 서버를 띄우고, 테스트를 돌릴 수 있어야 해.
현재 README에 빠진 내용이 있으면 프로젝트 파일을 보고 채워줘.
이 과제가 첫날에 완벽한 이유가 다섯 가지 있다.
- 범위가 명확하다. 결과물은 README.md 파일 하나다.
- 맥락이 적당히 필요하다. AI가 package.json, Makefile, Dockerfile 같은 파일을 읽어서 빌드·실행 방법을 파악해야 한다. 이 과정에서 AI의 파일 탐색 능력을 자연스럽게 관찰할 수 있다.
- 검증이 쉽다. AI가 쓴 README대로 따라하면 되는지 직접 해보면 된다.
- 위험이 없다. README는 실행되는 코드가 아니다. 잘못 써도 시스템이 안 깨진다.
- 즉시 가치가 있다. 팀 동료들이 바로 쓸 수 있는 산출물이다.
Claude Code가 README를 생성하면, diff를 확인하라고 물을 것이다. 여기서 반드시 한 줄씩 읽는다. 첫날은 AI의 판단을 맹신하지 않는 습관을 들이는 날이다.
# Claude Code가 수정을 마치면 diff를 보여준다
# 터미널에서 직접 확인할 수도 있다
git diff README.md
README 내용이 정확한지 확인하고, 맞으면 커밋한다. 첫 번째 성공 경험 완료.
이 과제를 변형해서 쓸 수도 있다. 프로젝트에 README가 아예 없다면 “이 프로젝트의 README.md를 처음부터 작성해줘”로 바꾸면 된다. 이미 README가 충실하다면, “이 프로젝트에 CONTRIBUTING.md를 작성해줘. 새로운 기여자가 PR을 올리기까지의 과정을 설명해야 해”로 변형할 수 있다.
비개발자용 첫 과제 — 회의록에서 액션 아이템 추출
폴더에 회의 녹취록이나 메모를 텍스트 파일로 넣고, 이렇게 말한다.
이 폴더의 회의록 파일들을 읽고 다음을 정리해줘:
1. 각 회의에서 확정된 결정 사항 (언제, 누가, 무엇을)
2. 참석자별 액션 아이템과 기한
3. 아직 미결인 논의 사항
4. 다음 회의 일정과 안건
결과를 하나의 마크다운 파일로 만들어서 이 폴더에 저장해줘.
파일 이름은 meeting-summary.md로.
이 과제가 좋은 이유도 비슷하다.
- 입력이 명확하다. 폴더에 있는 파일이 입력이다.
- 출력이 명확하다. 마크다운 파일 하나가 결과물이다.
- 검증이 직관적이다. 내가 회의에 참석했으니 결과가 맞는지 바로 판단할 수 있다.
- 실용적이다. 이걸 팀에 공유하면 바로 쓸 수 있다.
결과물을 열어보고, 빠진 내용이 있으면 “3번 회의에서 김 대리가 다음 주까지 데이터 분석하기로 한 건 빠졌어. 추가해줘”처럼 자연어로 수정을 요청하면 된다. 이 ‘수정 요청 → 반영 확인’ 사이클을 한 번 경험하는 것이 첫날의 진짜 목표다.
이 순간, 당신은 채팅이 아니라 위임을 한 것이다. AI가 코드를 짜주는 시대가 아니라, AI에게 일을 위임하는 시대다. 위임할 줄 아는 사람이 하나의 회사가 된다. 오늘 그 첫걸음을 뗐다.

첫날의 함정 3가지 — 반드시 피하세요
설치를 마치고 첫 과제를 성공했다면, 축하한다. 하지만 첫날에 가장 많이 하는 실수 세 가지를 반드시 짚고 넘어가야 한다. 나도 세 가지를 전부 했고, 그래서 석 달을 버렸다.
함정 1: –dangerously-skip-permissions 절대 쓰지 마세요
Claude Code는 기본적으로 파일을 수정하거나 명령을 실행하기 전에 사용자에게 확인을 요청한다. “이 파일을 수정해도 될까요?” “이 명령을 실행해도 될까요?” 하나하나 물어본다.
이게 귀찮다. 20년차 개발자인 나도 귀찮았다. 그래서 검색했다. --dangerously-skip-permissions라는 플래그가 있었다. 이름부터가 경고인데, “나는 뭘 하는지 아니까”라고 생각했다.
결과: AI가 설정 파일을 예상치 못한 방식으로 수정했다. 구체적으로는, 프로젝트 루트의 환경 설정 파일을 “개선”한답시고 값을 바꿔놨다. 개발 환경이라 큰 사고는 아니었지만, 되돌리는 데 한 시간이 걸렸다. 실 서비스 환경이었다면? 생각만 해도 아찔하다.
이 플래그가 하는 일을 정확히 말하면: Claude Code가 모든 파일 수정과 명령 실행을 승인 없이 자동으로 수행하게 한다. 파일 삭제도 된다. 외부 네트워크 요청도 된다. 시스템 명령 실행도 된다.
첫날은 AI의 행동 패턴을 관찰하는 날이다. 뭘 하려고 하는지, 어떤 파일을 읽는지, 어떤 명령을 실행하려 하는지 — 하나하나 확인하면서 감을 잡아야 한다. 그 과정에서 “아, 이건 승인해도 되겠다” “이건 위험하다” 구분하는 눈이 생긴다.
최소 일주일은 기본 권한 모드로 쓰라. 6화에서 권한 모드를 제대로 다루는데, 거기서도 이 플래그는 권장하지 않는다. 대신 안전한 자동화를 위한 다른 방법들(훅, 샌드박싱)을 소개할 것이다.
함정 2: 첫 과제를 너무 크게 잡기
나의 첫 과제는 “10만 줄 프로젝트 전체 분석 및 개선점 도출”이었다. 결과는 참담했다.
왜 안 될까? AI 모델은 컨텍스트 윈도우라는 제한된 공간 안에서 일한다. 이건 AI의 ‘작업 기억’이라고 생각하면 된다. 파일을 많이 읽으면 이 공간이 차고, 가득 차면 앞서 읽은 내용을 잊기 시작한다. 10만 줄을 한 번에 이해하라는 건 사람에게도 무리인데, AI에게도 마찬가지다.
첫 과제의 적정 규모:
- 파일 수: 1~5개
- 변경 범위: 한 가지 명확한 목표
- 완료 시간: 5~10분
- 검증 방법: 눈으로 보거나 한 번 실행해보면 확인 가능
README 작성, 테스트 하나 추가, 함수 하나 리팩터링, 에러 메시지 개선 — 이런 수준이 적당하다. 작게 성공하고, 점진적으로 키우는 거다.
대규모 코드베이스를 다루는 방법은 17화에서 전략적으로 다룬다. 지금은 작게 시작하는 습관을 먼저 들이자.
함정 3: 결과물을 검증 없이 반영하기
AI가 만든 코드가 “동작하는 것처럼 보이는” 경우가 있다. 문법도 맞고, 로직도 그럴듯하고, 심지어 주석까지 깔끔하다. 하지만 실제로 돌려보면 엣지 케이스에서 실패하거나, 존재하지 않는 API를 호출하거나, 성능이 심각하게 나쁜 코드일 수 있다.
개발자라면 이렇게 검증한다:
git diff로 변경 내용을 한 줄씩 읽는다.- 테스트가 있다면 돌려본다 (
npm test,pytest등). - 빌드가 되는지 확인한다.
- 확신이 없는 부분은 AI에게 “이 코드에서 발생할 수 있는 문제점을 알려줘”라고 되물어본다.
비개발자라면:
- 생성된 문서의 사실 관계를 직접 확인한다. 날짜, 이름, 숫자가 맞는지.
- “이 내용에서 틀린 부분이 있을 수 있어?”라고 AI에게 자기 검증을 요청한다.
- 중요한 산출물은 반드시 사람이 최종 검토한다.
이 습관은 4화에서 다룰 ‘좋은 지시의 4요소’ 중 하나인 검증 방법과 직결된다. 지시를 내릴 때부터 “이 결과를 어떻게 확인할 것인가”를 포함하면, AI도 자기가 만든 결과의 검증 기준을 의식한다.
첫날의 규칙: AI가 만든 건 전부 ‘초안’이라고 생각하라. 초안을 검토하고 승인하는 건 사람의 몫이다. 이 원칙은 24회 시리즈 내내 바뀌지 않는다.
30분 타임라인 — 한눈에 보는 설치 완주 경로
여기까지 읽고 “많아 보인다”고 느낄 수 있다. 실제로 해보면 빠르다. 시간대별로 정리한다.
개발자 경로 30분:
- 0~3분:
node -v확인. 없으면 설치. - 3~5분:
npm install -g @anthropic-ai/claude-code - 5~10분:
claude첫 실행, 브라우저 인증 - 10~15분: 프로젝트 폴더로 이동,
/init실행 - 15~25분: 첫 과제 실행 (README 작성)
- 25~30분: 결과 검토,
git diff, 커밋
비개발자 경로 30분:
- 0~5분: 데스크톱 앱 다운로드, 설치
- 5~10분: 계정 로그인, 초기 설정
- 10~15분: 작업 폴더 연결
- 15~25분: 첫 과제 실행 (회의록 정리)
- 25~30분: 결과 확인, 수정 요청 한 번
두 경로 모두 30분 안에 첫 번째 ‘쓸 만한 결과물’을 손에 쥘 수 있다. 이게 핵심이다. 세 시간 동안 삽질한 게 아니라, 30분 만에 “이거 쓸 만하네”라는 감각을 잡는 것.
설치 이후가 진짜 시작 — 첫 주를 위한 안내
첫 30분을 무사히 넘겼다면, 다음 일주일 동안 해볼 만한 것들을 가볍게 정리한다.
개발자라면:
- 매일 한 가지 작은 과제를 Claude Code로 해본다. 테스트 추가, 에러 메시지 개선, 문서 보완, 간단한 버그 수정.
- AI가 수정한 내용을 매번
git diff로 확인하는 습관을 들인다. - 승인 프롬프트가 뜰 때 “이걸 왜 하려는 거지?”를 한 번씩 생각해본다. AI의 행동 패턴이 보이기 시작한다.
- CLAUDE.md를 조금씩 보강한다. “테스트는 이렇게 돌려라”, “이 폴더는 건드리지 마라” 같은 지시를 추가한다. 5화에서 이걸 체계적으로 다룬다.
비개발자라면:
- 다양한 파일 형식을 시도해본다. 텍스트, CSV, 마크다운, PDF 등.
- “정리해줘”보다 구체적인 지시를 연습한다. “이 CSV에서 매출 상위 10개를 뽑아서 표로 만들어줘” 식으로.
- 결과물에 대해 “이거 말고 이렇게 바꿔줘”라고 수정을 요청하는 대화를 이어본다. 한 번의 지시로 완벽한 결과가 나오는 일은 드물다. 대화를 통한 반복 수정이 핵심 워크플로다.
일주일 뒤, 당신은 이 도구가 일상에 쓸모 있는지 아닌지를 판단할 수 있게 된다. 그 판단이 “쓸모 있다”라면, 4화부터가 진짜 깊이 있는 영역이다.
자주 묻는 질문 — 첫날에 궁금한 것들
Q: Claude Code와 Claude 데스크톱 앱은 같은 건가요?
아니다. Claude Code는 터미널 CLI 도구다. 개발자가 코드 프로젝트 안에서 쓴다. Claude 데스크톱 앱은 GUI 애플리케이션이다. 비개발자를 포함한 모든 사용자가 파일 기반 작업에 쓴다. 둘 다 Claude AI를 사용하지만, 인터페이스와 쓰임새가 다르다.
Q: 무료로 쓸 수 있나요?
Claude Code는 Pro($20/월) 이상의 유료 구독이 필요하다. 무료 체험이 있을 수 있으나 기능과 사용량이 제한된다. “30분 첫 경험”을 위한 목적이라면 Pro 월 구독으로 시작해서, 쓸모를 확인한 뒤 결정하는 게 현명하다.
Q: 회사 코드에 써도 되나요?
이건 회사마다 정책이 다르다. AI 도구에 사내 코드를 입력하는 것에 대한 보안 정책을 먼저 확인해야 한다. 감사 이력이 남아야 하는 조직이라면 특히 주의가 필요하다. 확실하지 않으면 개인 프로젝트나 오픈소스로 먼저 연습하고, 회사 정책이 정리된 뒤에 사내 코드에 적용하라.
Q: Windows에서도 잘 되나요?
된다. Claude Code는 Windows, macOS, Linux를 모두 지원한다. Windows에서는 PowerShell이나 Windows Terminal에서 쓰는 것을 추천한다. cmd.exe에서도 동작하지만, 경험이 좋지 않을 수 있다. WSL에서도 사용 가능하다.
Q: 인터넷이 끊기면 어떻게 되나요?
Claude Code는 Anthropic 서버와 통신해야 한다. 인터넷이 끊기면 동작하지 않는다. 로컬에서 AI 모델을 돌리는 게 아니라, 클라우드의 AI에게 내 코드 맥락을 보내고 응답을 받는 구조다. 비행기 모드에서는 쓸 수 없다.
Q: 한국어로 대화해도 되나요?
된다. 한국어로 지시하고 한국어로 답변을 받을 수 있다. 다만 프로그래밍 관련 작업(코드 생성, 커밋 메시지 등)은 영어가 더 자연스러운 경우가 많다. 나는 “지시는 한국어, 코드와 커밋 메시지는 영어”를 기본으로 쓴다.
이번 회차의 수익화 지점
오늘 만든 건 없어 보인다. 그냥 설치했을 뿐이니까. 하지만 이 ‘설치부터 첫 성공까지’의 경험 자체가 상품이 될 수 있다.
팀에 새 도구를 도입할 때 가장 비싼 비용은 도구 라이선스가 아니라 온보딩 시간이다. 10명이 각자 세 시간씩 삽질하면 30인시가 날아간다. 그걸 30분으로 줄이는 온보딩 가이드가 있다면?
오늘 이 글에서 정리한 두 갈래 경로(개발자 CLI / 비개발자 데스크톱)를 회사·팀의 환경에 맞게 커스텀하면, 그게 바로 “AI 도구 도입 워크숍”의 첫 번째 모듈이다. 사내 프록시 설정, 팀의 보안 정책 반영, 첫 과제를 팀의 실제 업무로 교체 — 이런 맞춤 작업을 해서 내부 교육 자료로 만들 수 있다. 사내 교육이 아니더라도, 프리랜서나 소규모 팀 대상으로 “AI 코딩 도구 온보딩 세팅”을 유료 서비스로 제안할 수 있는 형태다.
핵심은 설치가 아니다. “첫 30분에 반드시 성공하게 만드는 경로 설계”가 가치다. 그리고 그 경로는 팀마다, 환경마다, 업종마다 다르다. 그 차이를 메울 줄 아는 사람이 도입 컨설턴트다.
다음 회 예고
도구를 설치했다. 첫 과제도 성공했다. 그런데 같은 Claude Code를 쓰는데, 어떤 사람은 10분 만에 원하는 결과를 얻고 어떤 사람은 한 시간을 헤맨다. 차이는 도구가 아니라 지시의 품질이다.
4화에서는 ‘좋은 지시 vs 나쁜 지시’를 다룬다. 맥락, 제약, 완료 조건, 검증 방법 — 이 네 가지를 갖춘 지시가 왜 결과를 바꾸는지, 나쁜 지시를 좋은 지시로 바꾸는 Before/After 다섯 쌍을 직접 보여준다. “알아서 잘 해줘”가 얼마나 비싼 말인지, 숫자로 체감하게 될 것이다.
관련 회차: 5화: CLAUDE.md — AI에게 프로젝트를 가르치는 법 | 6화: 권한과 보안 — 훅으로 통제하는 법
◀ 이전 2화 (다음 차수는 아직 게시되지 않았습니다)
참고 자료
- Anthropic 공식 문서 — Claude Code Overview — Claude Code의 설치 요구사항과 시작 방법을 안내하는 공식 가이드
[…] 시리즈: Claude 활용 24회 — AI에게 일을 위임하는 법 (총 24화 중 4화)◀ 이전 3화 (다음 차수는 아직 게시되지 […]