3장. 설치와 첫 5분

클로드 코드는 설치 자체보다, 어떤 방식으로 시작하느냐가 더 중요하다. 같은 도구를 써도 어떤 사람은 첫날부터 "이거 된다"를 느끼고, 어떤 사람은 권한 팝업과 어색한 환경 설정에 지쳐서 다시 익숙한 수동 작업으로 돌아간다. 솔로 빌더에게 이 차이는 꽤 크다. 첫 5분의 선택이 이후 수백 시간의 마찰을 줄이기 때문이다.

이 장의 목표는 단순하다. 복잡한 설치 가이드를 다 외우는 것이 아니라, 내 운영체제, 내 예산, 내 작업 습관에 맞는 가장 빠른 시작점을 찾는 것이다. 이미 충분히 바쁜 1인 개발자에게 필요한 것은 "모든 옵션의 완벽한 암기"가 아니라 "오늘 당장 덜 막히는 선택"이다.

2.1 npm, Homebrew, WinGet, 네이티브 설치 비교

요즘 기준으로 가장 먼저 기억할 한 줄은 이것이다. 기본값은 네이티브 설치다. 최근 가이드는 macOS·Linux·Windows에서 네이티브 설치를 권장하고, Homebrew·WinGet·npm은 환경에 따라 고르는 대안으로 본다.¹

설치 방식은 결국 "누가 업데이트를 관리하느냐"의 문제다. 내가 직접 챙길 것인가, 운영체제나 패키지 매니저에 맡길 것인가, 아니면 가능한 한 설치 마찰을 줄일 것인가를 고르는 셈이다.

솔로 빌더 관점에서 더 직설적으로 말하면 이렇다.

macOS나 Linux를 쓰고 있고 특별한 이유가 없다면 네이티브 설치로 시작하는 편이 가장 덜 피곤하다. 이미 패키지 관리를 Homebrew로 통일해 둔 사람은 brew가 편할 수 있다. Windows 사용자는 WinGet이나 네이티브 설치가 자연스럽고, Node 도구 체인과 CLI 실험을 자주 하는 사람만 npm을 의식적으로 고르면 된다.¹

Windows에서 한 가지 더 생각할 점은 어디에서 개발하느냐다. .NET, PowerShell, Windows 네이티브 도구를 주로 다루면 Windows 네이티브 설치가 편하다. 반대로 Docker, Python 백엔드, Node 서버처럼 배포 환경이 리눅스에 가까우면 WSL 쪽이 마음이 편할 때가 많다. 로컬에서부터 배포 환경과 비슷한 감각을 가져갈 수 있기 때문이다.¹

처음 시작하는 독자에게 내가 권하는 선택은 대체로 아래 셋 중 하나다.

• macOS/Linux라면: 네이티브 설치

• Windows 일반 개발이라면: 네이티브 설치 또는 WinGet

• Windows에서 리눅스 서버 감각이 중요하다면: WSL + 네이티브 설치

중요한 건 "가장 고급스러운 방식"이 아니라 "내가 오늘 안 막히는 방식"이다. 설치 성공이 목적이 아니라, 곧바로 첫 작업을 시키는 것이 목적이기 때문이다.

2.2 Pro/Max/Team/API 요금제 선택 가이드

설치만큼 처음 사람을 헷갈리게 하는 것이 요금제다. 여기서도 원칙은 간단하다. 대부분의 솔로 빌더는 Pro로 시작하고, 사용량 때문에 실제로 자주 막힐 때만 Max를 고민하면 된다. 공식 가격 기준으로 Pro는 월 20달러, 연간 결제 기준 월 17달러 수준이고, Max는 100달러부터 시작한다. Free 플랜은 Claude를 체험하는 용도이지, 터미널 기반 Claude Code의 기본 출발점은 아니다.²

Team은 이름만 보면 혼자 쓰는 사람과 무관해 보이지만, 사실 작은 팀으로 커질 가능성이 있는 솔로 빌더에게는 나중 선택지로 의미가 있다. 결제와 관리가 팀 단위로 정리되기 때문이다. 다만 처음부터 팀 플랜을 고민할 필요는 거의 없다. 혼자 만들고 혼자 운영하는 단계에서는 Pro 혹은 Max가 훨씬 단순하다.²

API는 결이 다르다. 구독형이 아니라 사용량 기반 과금이고, 자동화나 배치 작업, CI, 자체 도구 연동에서 특히 빛난다. 공식 가격표 기준으로 Opus 4.7은 입력 1M 토큰당 5달러, 출력 25달러, Sonnet 4.6은 3달러와 15달러, Haiku 4.5는 1달러와 5달러다.²

그래서 선택 기준은 이렇게 정리하면 쉽다.

Pro는 가장 현실적인 기본값이다. 개인 프로젝트, 사이드 프로젝트, 주말 창업, 틈틈이 개발하는 직장인에게 맞다. "매일 쓰긴 하지만 하루 종일 붙어 있진 않다"면 거의 이 구간이다.

Max는 Claude Code를 사실상 주 개발 파트너로 붙여 놓고 오래 달리는 사람에게 맞다. 긴 리팩터링, 다중 파일 수정, 잦은 반복 작업에서 제한이 생산성을 자꾸 끊는다면 그때 올라가면 된다. 처음부터 비싼 헬멧을 쓰고 자전거를 사는 식으로 시작할 필요는 없다.

Team은 혼자 시작했지만 사람을 붙이기 시작할 때 의미가 생긴다. 공동 창업자, 프리랜서 협업자, 파트타이머가 생기면 결제와 정책을 따로 관리하는 비용이 생각보다 커지기 때문이다.²

API는 사람보다 프로세스에 연결할 때 고른다. 예를 들어 이런 경우다.

• GitHub Actions에서 코드 점검을 자동화하고 싶다

• 새벽 배치 작업으로 문서 요약이나 코드 생성 파이프라인을 돌리고 싶다

• 내 제품 안에 Claude 기반 기능을 넣고 싶다

• 구독보다 사용량 측정이 더 중요하다

한 문장으로 줄이면 이렇다. 내가 직접 붙어서 쓰는 시간은 구독형, 시스템이 대신 돌리는 시간은 API다.

2.3 첫 명령부터 첫 커밋까지

설치가 끝났다면 이제 가장 중요한 순간이 온다. 여기서 많은 초보 사용자가 실수한다. 처음부터 거대한 기능을 맡긴다. 로그인, 결제, 배포, 테스트, 디자인까지 한 번에 시키고는 결과가 어설프면 실망한다. 그건 클로드 코드의 문제가 아니라 첫 공을 너무 무겁게 던진 것이다.

첫 5분에는 작고 눈에 보이는 작업이 좋다. 버튼 문구 바꾸기, 에러 메시지 정리, README 한 문단 고치기, 테스트 하나 추가하기 같은 일이다. 결과가 바로 보이고, 승인 흐름도 배우고, 내 프로젝트를 Claude가 어떻게 읽는지 감을 잡을 수 있다.

가장 무난한 첫 루프는 이렇다.

1. 프로젝트 루트 폴더를 연다.

2. claude를 실행하거나, VS Code 확장을 설치했다면 패널을 연다.³⁴

3. 로그인하고 작업 디렉터리를 신뢰한다.

4. 첫 프롬프트는 설명형으로 준다. 예를 들면 "이 프로젝트 구조를 5줄로 요약하고, 실행 명령과 테스트 명령을 알려줘."

5. 두 번째 프롬프트는 작은 수정으로 준다. 예를 들면 "헤더의 CTA 버튼 문구를 '무료로 시작하기'로 바꾸고, 관련 테스트가 있으면 함께 고쳐줘. 바꾸기 전에 계획을 먼저 보여줘."

6. 제안된 변경을 diff로 확인하고 수락한다.

7. 마지막으로 "변경 내용을 한 줄로 요약하고 적절한 커밋 메시지로 커밋해줘"라고 요청한다.

여기서 핵심은 두 가지다.

첫째, 첫 프롬프트는 구현 요청보다 탐색 요청이 낫다. Claude가 프로젝트를 얼마나 잘 읽는지, 실행 명령을 얼마나 정확히 짚는지 보면 이후 신뢰 수준을 조절하기 쉽다.

둘째, 첫 수정은 작을수록 좋다. 성공 경험이 빨리 생긴다. "오, 진짜 파일을 찾고 바꾸네"라는 감각이 들어야 다음 단계로 넘어간다. 첫날에는 감탄이 중요하다. 감탄이 쌓이면 습관이 된다.

만약 VS Code 확장을 쓰고 있다면 이 첫 5분이 더 부드럽다. 계획을 검토한 뒤 승인할 수 있고, @ 멘션으로 파일을 지정하기 쉽고, 대화 기록과 다중 세션 관리도 편하다. 선택한 코드 줄을 바로 참조하거나, 필요하면 여러 대화를 병렬로 열어 다른 작업을 나눠볼 수도 있다.³

한편 너무 빨리 자동 승인 모드로 달려가지는 마라. 처음 며칠은 "조금 답답해도 검토하는 습관"이 이긴다. 솔로 빌더는 속도만 빠른 사람이 아니라, 혼자서도 사고를 통제하는 사람이어야 하기 때문이다.

2.4 VS Code, JetBrains, 터미널, 모바일 - 어디서 일할 것인가

작업 환경을 고를 때 가장 흔한 오해는 "가장 강력한 환경 하나만 있으면 된다"는 생각이다. 실제로는 그렇지 않다. 좋은 솔로 빌더는 주 작업석 하나와 보조 좌석 하나를 가진다.

터미널은 Claude Code의 본진이다. 기존 에디터를 바꾸지 않아도 되고, git, 테스트, 스크립트, 로그, 서버 작업과 잘 붙는다. 백엔드 개발자, 인프라 지향 개발자, Vim이나 Zed 같은 개인 취향이 강한 사람에게 특히 잘 맞는다. 가장 유연하지만, 처음엔 조금 투박하게 느껴질 수 있다.⁵

VS Code는 가장 무난한 기본 좌석이다. 공식 확장은 그래픽 인터페이스를 제공하고, 계획을 문서처럼 검토하고, 파일을 @ 멘션으로 붙이고, 여러 대화를 탭으로 나눠 운영할 수 있게 해준다. 쉽게 말해 "터미널의 성능을 IDE의 편안함으로 감싼 자리"다. 처음 시작하는 솔로 빌더라면 VS Code가 가장 추천할 만한 출발점이다.³⁴

JetBrains는 IntelliJ, PyCharm, WebStorm 같은 IDE에 깊게 묶여 사는 사람에게 좋다. 이쪽의 장점은 익숙한 정적 분석, IDE diff 뷰어, 선택 영역 공유, 진단 오류 공유다. 이미 JetBrains 손에 익은 사람에게 VS Code로 갈아타라고 하는 건 좋은 조언이 아니다. 익숙한 작업대에서 Claude를 붙이는 편이 훨씬 현실적이다.⁵

모바일은 주 작업석이 아니라 보조 좌석으로 보는 편이 좋다. 이동 중에 아이디어를 적고, 원격 세션을 이어서 보고, 저녁에 침대에서 "내일 할 일 정리" 정도를 던지는 데는 훌륭하다. 하지만 본격적인 구현, diff 검토, 테스트 반복은 결국 데스크톱 환경이 편하다. 모바일은 코드를 생산하는 자리라기보다, 작업을 이어 붙이는 자리에 가깝다. VS Code는 Claude.ai 구독 기반 원격 세션을 이어받는 흐름도 지원한다.³

그래서 환경 선택은 이렇게 하면 된다.

• 가장 처음이라면: VS Code + Pro

• 이미 IntelliJ/PyCharm이 몸에 밴 사람이라면: JetBrains 플러그인 + Pro

• 터미널이 제일 편한 사람이라면: CLI + 원하는 에디터

• 외부 이동이 잦다면: 데스크톱을 주 작업석으로 두고 모바일은 지시·검토용으로 사용

결국 중요한 것은 화려한 도구 조합이 아니다. 내가 매일 앉을 수 있는 자리를 만드는 것이다. 매번 실행 방식이 바뀌고, 어떤 날은 터미널, 어떤 날은 브라우저, 어떤 날은 낯선 에디터를 헤매면 집중력이 새어 나간다. 혼자 만드는 사람에게 집중력은 돈보다 귀하다.

이 장의 결론

클로드 코드를 시작할 때 가장 좋은 전략은 욕심을 줄이는 것이다. 설치 방식은 가장 덜 막히는 것을 고르고, 요금제는 Pro에서 시작하고, 첫 과업은 작게 잡고, 작업 환경은 이미 익숙한 자리에 붙인다. 이 네 가지만 지켜도 첫 주의 경험이 완전히 달라진다.

나는 대부분의 솔로 빌더에게 이렇게 권한다.

• 설치는 네이티브를 기본값으로 생각하라.

• 요금제는 Pro에서 시작하고, 실제 병목이 생길 때만 Max를 고민하라.

• 첫 작업은 작고 눈에 보이는 수정으로 시작하라.

• 작업 환경은 VS Code를 기본값으로, JetBrains나 터미널은 이미 손에 익은 사람에게 맞춰 선택하라.

설정이 끝났다면 이제 해야 할 일은 하나뿐이다. 작은 작업 하나를 던져 보고, 변경사항을 직접 승인해 보는 것. 그 순간부터 클로드 코드는 더 이상 "신기한 AI 도구"가 아니라, 당신의 제품을 함께 만드는 작업 파트너가 된다.

참고

¹설치 방식 비교와 최신 권장 흐름 정리

²Claude 요금제와 API 가격 공식 페이지

³VS Code에서 Claude Code 사용하기

⁴Claude Code 빠른 시작

⁵JetBrains IDEs - Claude Code Docs

⁶Claude Code for VS Code 마켓플레이스