Claude Code 시작하기 — 설치부터 첫 프로젝트까지

2026년 2월 기준 Claude Code의 주 사용자는 한 달 사이 두 배로 뛰었고, 평균 개발자가 이 도구에 쓰는 시간은 주 20시간이다. IDE 플러그인이 아니라 까만 터미널 창에서. 왜 다들 굳이 터미널로 돌아갔을까. 설치 명령 한 줄부터 첫 커밋까지, 실제 흐름만 따라가 보자.

터미널 한 줄: claude 만 치면 200k 컨텍스트의 에이전트가 깨어난다.

설치는 1분, 진짜 시작은 그다음

설치 자체는 허무할 만큼 짧다. Node.js 18 이상이 깔려 있다면 npm 한 줄이면 끝이다.

# npm 방식 — Node.js 18+ 필요
npm install -g @anthropic-ai/claude-code

# 또는 네이티브 인스톨러 — Node·npm 의존성 0
curl -fsSL https://claude.ai/install.sh | bash

여기서 갈림길이 하나 있다. 2026년 1월 v2.1.15부터 Anthropic은 네이티브 인스톨러를 기본으로 밀고, npm 방식은 deprecated 처리했다. 그렇다고 npm이 죽은 건 아니다 — 여전히 완전히 지원되고, 버전을 고정해 쓰고 싶을 때(CI 파이프라인 같은)는 오히려 npm이 낫다. 네이티브 쪽은 의존성이 없고 백그라운드에서 알아서 업데이트되며 Anthropic이 우선 테스트하는 경로다. 둘 중 뭘 골라도 다음 단계는 같다.

설치가 끝나면 작업할 폴더로 들어가 claude 만 친다.

cd my-project
claude

처음 실행하면 브라우저가 열리고 Anthropic 계정 로그인을 요구한다. 인증을 마치면 그때부터 터미널 안에 에이전트가 앉아 있다. 파일을 읽고, 명령을 돌리고, 코드를 고치는 그 에이전트가. 설치 옵션과 인증 절차의 세부는 Claude Code 공식 설치 문서에 정리돼 있다.

IDE를 버리고 터미널로 — 그 200k가 하는 일

대부분의 AI 코딩 도구는 IDE 확장으로 출발했다. Copilot도, Cursor도. 그런데 Anthropic은 의도적으로 터미널을 골랐다. 이유는 단순하다 — 파일 접근에 대한 완전한 통제와 최대한의 유연성. 에디터 안에 갇히지 않으니 어떤 프로젝트 구조든, 어떤 셸 도구든 그대로 붙는다.

이 선택이 빛을 발하는 지점이 컨텍스트다. Claude Code의 작업 창은 200k 토큰. 숫자만 보면 막연하니 실제로 어디에 쓰이는지 쪼개 보자.

차이는 여기서 난다. IDE 자동완성은 커서 주변 몇십 줄을 본다. Claude Code는 프로젝트 디렉터리를 통째로 훑고, 연관된 파일 열 개를 동시에 머리에 올린 채 "이 함수를 바꾸면 어디가 깨지는지"를 추론한다. 좁은 창으로 보던 코드를 넓은 창으로 보는 것 — 그게 200k의 실체다.

믿기 어렵다면 수치 하나. Anthropic 집계에서 코드 출력 20개 중 19개가 첫 시도에 동작한다(95%). 팀 단위로는 도입 후 개발 속도가 2~10배 빨라졌다는 보고가 나왔다. 이게 8개월 만에 Claude Code가 Copilot과 Cursor를 추월하고 개발자 46%에게 "가장 사랑받는" 도구로 뽑힌 배경이다.

첫 프로젝트의 실제 흐름 — 탐색·계획·코딩·커밋

여기가 핵심이다. Claude Code를 "그냥 코드 짜줘"라고 던지면 잘 안 풀린다. Anthropic이 권장하고 Claude Code 제작자 본인이 매일 쓰는 흐름은 4단계다. 한 단계씩 보자.

1탐색(Explore). 첫 세션이면 /init 부터. 이 명령이 저장소를 훑어 CLAUDE.md를 만들어 준다 — 프로젝트의 상시 브리핑 문서다. 컬러 팔레트, 코딩 컨벤션, 빌드 방식 같은 "에이전트가 항상 알아야 할 것"을 여기 적어두면 매 세션 시작 때 자동으로 로드된다. 매번 프로젝트를 처음부터 설명하느라 토큰을 태우는 대신, 진짜 작업에 토큰을 쓰게 되는 셈이다.

이 CLAUDE.md 아이디어가 워낙 잘 먹혀서, 경쟁 도구들이 곧바로 GEMINI.md·.cursorrules 같은 자기 버전을 내놨다. 따라 만든다는 건, 통한다는 뜻이다.

2계획(Plan). 곧장 코딩시키지 말 것. 플랜 모드로 전환하면 에이전트가 파일을 읽고 질문에 답하되 아무것도 고치지 않는다. 탐색과 실행을 분리하는 장치다. 게다가 플랜 모드는 thinking 토큰을 쓰는데, 이건 탐색용 파일 읽기가 잡아먹는 컨텍스트 비용보다 싸다. 즉 계획을 먼저 세우는 게 토큰 관리 측면에서도 이득이다.

3코딩(Code). 계획이 마음에 들면 플랜 모드를 빠져나와 실제 구현을 맡긴다. 핵심은 한 번에 한 변경. 큰 작업을 통째로 던지지 말고 단위로 쪼개, 매 변경을 계획과 대조하며 검토한다.

4커밋(Commit). 만족스러우면 그대로 "커밋해줘. 메시지는 설명적으로" 라고 하면 된다. 필요하면 PR 생성까지 이어서.

긴 세션을 매끄럽게 굴리는 두 명령도 알아두자.

# 대화가 길어져 컨텍스트가 꽉 찰 때
/compact

# 완전히 다른 작업으로 넘어갈 때 — 컨텍스트 비우기
/clear

작업이 바뀌었는데 /clear 없이 계속 가면, 앞선 작업의 잔재가 150k 가용 창을 야금야금 갉아먹는다. 새 작업 = /clear, 이 습관 하나가 체감 품질을 바꾼다.

MCP 연결 맛보기 — 에이전트에 손발 달기

여기까지가 "코드를 읽고 쓰는 Claude Code"라면, MCP는 그 바깥 세계로 손을 뻗는 통로다. MCP(Model Context Protocol)로 GitHub·DB·파일시스템 같은 외부 도구를 에이전트에 물리면, 단순한 코드 생성기가 아니라 실제로 일을 끝까지 처리하는 일꾼이 된다.

추가는 claude mcp add 한 줄이다. GitHub를 붙여 이슈·PR을 직접 만지게 하는 예:

claude mcp add --transport http github \
  https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

로컬 파일시스템을 특정 폴더만 열어주는 예는 이렇게:

claude mcp add filesystem -- \
  npx -y @modelcontextprotocol/server-filesystem ~/Documents

전송 방식만 헷갈리지 않으면 된다. 표로 정리하면:

팀과 공유하고 싶다면 --scope project 를 붙인다. 그러면 프로젝트 루트에 .mcp.json 이 생기고, 이걸 git에 커밋하면 저장소를 클론한 모두가 같은 MCP 구성을 그대로 받는다. 설정이 곧 코드가 되는 지점이다.

그래서, 무엇부터 할까

설치는 1분, 흐름은 네 단어다 — 탐색·계획·코딩·커밋. 처음 며칠은 /init 로 만든 CLAUDE.md를 다듬고, 한 번에 한 변경만 시키는 감각을 들이는 데 쓰면 충분하다. MCP는 그게 손에 익은 뒤에 하나씩 붙여도 늦지 않는다.

흥미로운 건 규모에 따라 풍경이 갈린다는 점이다. 직원 1만 명 넘는 대기업에선 여전히 Copilot이 56%로 1위지만, 소규모 기업에선 Claude Code 채택률이 75%에 이른다. 작은 팀일수록, 터미널 안에서 끝까지 일을 마치는 에이전트의 무게가 더 크게 느껴진다는 뜻일 거다.

지금 당신이 쓰는 스택에서, 자동완성 대신 200k 컨텍스트를 통째로 읽는 동료를 옆에 앉혔을 때 어떤 작업의 순서가 바뀔까. 답은 첫 claude 한 줄을 친 다음에 더 빨리 온다.