Claude Code 초보자는 무엇부터 만들어야 하나요?
새 서비스를 통째로 만들기보다 기존 프로젝트의 문구 변경, 입력 검증, 작은 버그 수정처럼 결과를 확인하기 쉬운 작업이 좋습니다. 구조 탐색, 계획, 구현, 테스트를 한 차례 모두 경험하는 것이 목표입니다.
강의와 예제 복사에서 출발해 질문·검증·변형으로 넘어가는 실전 중심 Claude Code 입문법
Claude Code를 처음 켠 사람은 곧 질문 앞에서 멈춘다. 무엇을 시켜야 할지 모르는데 프롬프트부터 잘 써야 한다는 압박까지 생긴다. 초보자가 먼저 익혀야 할 것은 명령어 목록일까. 아니면 원하는 결과가 나올 때까지 파고드는 과정일까.
기초 강의와 다른 사람의 작업 영상은 Claude Code가 다룰 수 있는 범위를 빠르게 보여준다. 파일을 읽고 수정하고 명령을 실행해 테스트까지 돌리는 과정을 모르면 가능한 작업을 떠올리기도 어렵다. 처음에는 설치부터 프로젝트 열기, 변경 요청, 결과 확인까지 한 번 따라 해보는 편이 낫다.
다만 강의를 모두 본 뒤 시작하겠다는 생각은 쉽게 수동적인 시청으로 이어진다. 화면과 같은 결과가 나왔다고 해서 자신의 문제를 해결할 수 있게 된 것도 아니다. 강의는 기능 사전이 아니라 작업 지도로 삼아야 한다. 한 단원을 봤다면 곧바로 작은 결과물을 만들어야 한다.
첫 과제로는 기존 프로젝트의 문구 변경이나 간단한 입력 검증처럼 결과를 눈으로 확인할 수 있는 일이 적합하다. Anthropic의 빠른 시작 문서도 코드 프로젝트에서 Claude Code를 실행한 뒤 코드베이스를 파악하고 작은 변경을 수행하는 순서로 안내한다. 거대한 앱을 처음부터 생성하는 것보다 변경 전후를 비교하기 쉽다.
질문을 정교하게 만들지 못해도 작업은 시작할 수 있다. 알고 있는 것과 원하는 결과, 막힌 지점을 평문으로 적고 Claude Code가 추가 질문을 하게 만들면 된다. 예를 들어 “로그인 버튼을 눌러도 반응이 없다. 어느 파일을 봐야 할지 모르겠다. 먼저 구조를 조사하고 내게 세 가지 질문을 해달라”고 요청할 수 있다.
Anthropic의 공식 워크플로는 새 코드베이스에서 전체 구조를 먼저 묻고 주요 데이터 모델이나 인증 흐름으로 범위를 좁히도록 권한다. 베스트 프랙티스 문서에는 큰 기능을 시작하기 전에 Claude가 사용자를 인터뷰하고 명세를 작성하게 하는 방식도 담겼다. 초보자에게 필요한 프롬프트 기술은 멋진 역할극보다 대화를 통해 불확실성을 줄이는 능력에 가깝다.
Claude Code의 /config에서는 Explanatory와 Learning 출력 스타일을 선택할 수 있다. Explanatory는 구현 선택과 코드 패턴을 설명한다. Learning은 일부 코드를 TODO(human)으로 남겨 사용자가 직접 채우게 한다. 완성품만 받고 싶은 유혹을 줄이고 대화를 학습 과정으로 바꿀 수 있는 공식 기능이다.

다른 사람의 방식을 따라 하는 일은 좋은 출발점이다. 문제는 동일한 입력과 출력에서 끝낼 때 생긴다. 예제를 복사했다면 입력 조건이나 저장 방식, 화면 동작 중 하나를 바꿔 다시 구현해야 한다.
작은 할 일 목록을 만든다면 다음 순서로 진행할 수 있다. 먼저 Claude Code에 관련 파일과 데이터 흐름만 설명하게 한다. Plan Mode에서 수정할 파일과 테스트 방법을 정한 뒤 항목 추가 기능을 구현하고 테스트를 실행시킨다. 이후 사용자가 완료 상태 저장이나 빈 문자열 차단 중 하나를 직접 추가한다.
마지막에는 코드를 보지 않고 “데이터가 저장되는 순서와 실패할 수 있는 지점을 내가 설명해 보겠다. 틀린 부분만 지적해 달라”고 요청한다. 생성된 코드를 다른 입력에 맞게 바꾸고 다시 설명해야 따라 하기가 자신의 지식으로 넘어간다.
2026년 1월 Anthropic이 발표한 무작위 대조 연구는 이 차이를 수치로 보여줬다. 낯선 Python 라이브러리를 익힌 개발자 52명을 조사했더니 AI 지원 그룹은 직후 이해도 평가에서 직접 코딩한 그룹보다 17% 낮은 점수를 받았다. 작업 속도는 조금 빨랐지만 통계적으로 유의한 차이는 아니었다.
AI를 사용한 사람 모두가 낮은 점수를 받은 것은 아니다. 후속 질문을 던져 생성 코드에 대한 설명을 요구하거나 개념을 확인한 참가자는 더 높은 숙련도를 보였다. 코드 생산보다 이해를 목적으로 대화를 이어간 방식이 달랐다.
초보 프로그래머 21명을 관찰한 ICER 2024 연구에서도 20명이 과제를 완성했다. 하지만 어려움을 겪던 일부 참가자는 잘못된 제안을 걸러내지 못했고 실제 이해보다 자신의 수행을 높게 평가했다. 실행되는 결과물은 학습의 증거가 아니다. 검증을 시작할 재료다.
써본 사람들 사이에서도 짧은 시간에 시제품을 완성하는 즐거움과 간단한 수정조차 도구에 의존하게 된다는 불안이 함께 나온다. 설명을 자세히 요구하면 속도가 느려지고 토큰 사용이 늘어난다는 불만도 있다. 학습 세션과 납품 세션을 구분해야 하는 이유다.
Anthropic은 Claude Code에 테스트, 빌드, 스크린샷처럼 통과 여부를 확인할 수단을 주라고 권한다. 검증 기준이 없으면 도구는 그럴듯해 보이는 순간 작업을 멈춘다. 초보자도 “구현해 줘” 대신 “실패하는 테스트를 먼저 만들고, 수정한 뒤 전체 테스트 결과를 보여 달라”고 요청할 수 있다.
여기서 테스트는 오류만 찾아내지 않는다. 어떤 입력을 정상으로 보고 무엇을 예외로 처리하는지 알려주는 실행 가능한 설명서가 된다. 개인 개발자나 작은 팀은 별도 교육 환경을 만들기 어렵다. 실제 저장소의 테스트와 빌드 명령을 학습 장치로 함께 쓰는 편이 효율적이다.
한 작업을 마치면 Claude에게 변경 파일, 핵심 개념, 실패했던 접근, 다음에 재사용할 명령을 짧게 기록하게 할 수 있다. 다음 날 그 기록 없이 같은 기능을 설명하거나 일부를 다시 만들어 보면 이해가 남았는지 확인할 수 있다. UNESCO도 생성형 AI 교육에서 인간의 판단과 비판적 검토를 중심에 두라고 권고한다.
CLAUDE.md, Skills, Hooks, MCP와 Subagents는 강력하지만 입문 순서를 대신하지 않는다. CLAUDE.md에는 빌드 명령과 코딩 규칙을 저장할 수 있다. Hooks는 파일 수정 뒤 lint 실행처럼 반드시 반복할 동작을 강제하고, Skills는 여러 번 수행한 절차를 재사용 가능한 워크플로로 만든다.
처음부터 이 구성을 모두 설치하면 무엇이 모델의 기본 능력이고 무엇이 설정의 효과인지 구분하기 어렵다. 같은 지시를 여러 세션에서 되풀이했다면 CLAUDE.md로 옮긴다. 빠뜨리면 사고가 나는 검증은 Hook으로 만들고, 별도 조사가 주 대화를 계속 흐릴 때 Subagent를 붙이는 순서가 자연스럽다.
Claude Code 활용력은 기능 수보다 탐색의 밀도에서 갈린다. 서툰 문장이라도 문제를 꺼내고 설명을 되묻고 예제를 변형한 뒤 테스트로 반박해 본 경험이 쌓여야 한다. 고급 하네스는 그 경험을 압축하는 장치이지 경험을 건너뛰는 지름길은 아니다.
새 서비스를 통째로 만들기보다 기존 프로젝트의 문구 변경, 입력 검증, 작은 버그 수정처럼 결과를 확인하기 쉬운 작업이 좋습니다. 구조 탐색, 계획, 구현, 테스트를 한 차례 모두 경험하는 것이 목표입니다.
현재 증상과 원하는 결과, 모르는 부분을 그대로 적고 필요한 정보를 되묻게 하세요. 먼저 관련 파일을 찾고 작업을 시작하기 전에 세 가지 확인 질문을 해달라고 요청할 수 있습니다.
같은 프로젝트 규칙을 반복해서 설명하게 될 때 CLAUDE.md를 추가하면 됩니다. MCP나 Subagents는 기본적인 탐색·수정·검증 흐름을 익힌 뒤 외부 도구 연결이나 조사 분리가 실제로 필요할 때 도입하는 편이 낫습니다.