복붙해서 바로 쓰는 클로드 코드 레시피 북

이 장은 접어두고 계속 펼쳐보는 페이지입니다

Claude Code를 잘 쓰는 비결은 멋진 말을 하는 데 있지 않습니다.
목표, 범위, 파일명, 완료 기준을 또렷하게 말하는 데 있습니다.

이 장은 설명보다 바로 쓰는 문장에 집중합니다.
마음에 드는 프롬프트를 복사한 뒤, 대괄호 안만 바꿔서 붙여 넣으세요.

[대괄호 안의 내용]만 내 프로젝트에 맞게 바꾸세요.

그리고 한 가지 습관만 기억하면 됩니다.

Claude에게 일을 맡기기 전에, 먼저 작업 범위를 말하게 하세요.

이 한 문장만으로도 엉뚱한 파일을 고치거나, 너무 많은 코드를 바꾸는 일을 줄일 수 있습니다.

레시피 01. 새 프로젝트를 시작할 때

빈 폴더를 열고 Claude Code에 들어왔다면, 첫 부탁은 길게 말하는 편이 좋습니다.
처음에 방향을 잘 잡아주면 뒤에서 덜 헤맵니다.

아래 프롬프트는 새 프로젝트 시작용 기본 카드입니다.

현재 폴더에서 새 프로젝트를 시작하려고 해.

목표:
[무엇을 만들지 적기. 예: 자기소개용 미니 포트폴리오 웹페이지]

기술 범위:
[사용할 기술 적기. 예: HTML, CSS, JavaScript만 사용. 프레임워크는 사용하지 않음]

원하는 파일 구조:
- index.html
- style.css
- script.js
- README.md

완료 기준:
1. 브라우저에서 index.html을 열었을 때 화면이 깨지지 않을 것
2. 모바일 화면에서도 읽기 좋을 것
3. 버튼이나 링크가 있다면 실제로 동작할 것
4. 각 파일의 역할이 분명할 것

먼저 파일을 만들지 말고, 작업 계획과 만들 파일 목록을 보여줘.
내가 승인하면 그때 작업을 시작해줘.

여기서 중요한 부분은 완료 기준입니다.
Claude에게 "잘 만들어줘"라고 하면 기준이 흐립니다. 대신 "브라우저에서 깨지지 않을 것", "모바일에서도 읽기 좋을 것"처럼 확인 가능한 문장으로 말하세요.

더 짧게 쓰고 싶을 때

현재 폴더에 [프로젝트 이름]을 만들고 싶어.
HTML, CSS, JavaScript만 사용해서 만들어줘.
먼저 필요한 파일 구조와 작업 계획을 보여주고, 내가 승인하면 파일을 생성해줘.
완료 기준은 브라우저에서 바로 열어 확인 가능하고, 모바일에서도 보기 좋은 상태야.

이미 파일이 있는 폴더에서 시작할 때

기존 파일이 있는 폴더에서는 바로 "만들어줘"라고 하지 마세요.
먼저 폴더를 읽고 상황을 파악하게 해야 합니다.

현재 폴더의 파일 구조를 먼저 확인해줘.
기존 파일을 함부로 수정하지 말고, 어떤 파일이 있는지 요약해줘.
그다음 [만들고 싶은 기능]을 추가하려면 어떤 파일을 수정해야 하는지 계획만 알려줘.

이 문장은 안전벨트입니다.
특히 작업 폴더 안에 예전 파일이 섞여 있을 때 꼭 먼저 붙여 넣으세요.

레시피 02. 디자인을 바꿀 때

디자인 요청은 "예쁘게"보다 "어떤 느낌으로"가 훨씬 잘 먹힙니다.
색감, 여백, 분위기, 모바일 대응을 같이 말하면 결과가 안정됩니다.

현재 페이지의 디자인을 수정하고 싶어.

원하는 분위기:
[예: 깔끔한 포트폴리오, 따뜻한 카페 메뉴판, 미니멀한 앱 소개 페이지]

색감:
[예: 흰 배경 + 짙은 남색 텍스트 + 연한 회색 카드]

여백:
전체적으로 답답하지 않게 섹션 사이 간격을 넉넉하게 잡아줘.

모바일 대응:
화면이 좁아지면 카드와 버튼이 세로로 자연스럽게 쌓이게 해줘.

수정 범위:
가능하면 style.css만 수정해줘.
HTML 수정이 필요하면 먼저 이유를 설명해줘.

마지막 두 줄이 핵심입니다.
가능하면 style.css만 수정해줘.
이렇게 말하면 Claude가 구조까지 뒤흔드는 일을 줄일 수 있습니다.

색감이 막막할 때 쓰는 문장

디자인 색감을 직접 정하기 어려워.
초보자가 보기 좋은 차분한 색 조합으로 추천해서 적용해줘.
단, 배경색, 글자색, 버튼색, 카드색을 각각 어떤 의도로 골랐는지 짧게 설명해줘.

모바일 화면이 이상할 때

모바일 화면에서 레이아웃이 답답해 보여.
style.css를 중심으로 수정해줘.

확인할 점:
1. 글자가 너무 작지 않은지
2. 버튼을 손가락으로 누르기 쉬운지
3. 카드나 섹션이 화면 밖으로 넘치지 않는지
4. 위아래 여백이 자연스러운지

수정 전 어떤 CSS를 바꿀지 먼저 알려줘.

디자인은 한 번에 완성하려고 하지 마세요.
먼저 큰 분위기를 잡고, 그다음 버튼, 여백, 색감을 조금씩 다듬는 편이 좋습니다.

레시피 03. 기능을 하나 추가할 때

기능을 추가할 때는 작게 말하세요.
"웹사이트를 더 좋게 만들어줘"보다 "버튼을 누르면 다크모드가 켜지게 해줘"가 훨씬 안전합니다.

현재 페이지에 기능을 하나 추가하고 싶어.

추가할 기능:
[예: 다크모드 버튼]

동작 방식:
[예: 버튼을 누르면 배경은 어둡게, 글자는 밝게 바뀌고 버튼 문구도 변경됨]

수정할 파일:
- index.html
- style.css
- script.js

원하는 기준:
1. 기존 디자인은 최대한 유지할 것
2. JavaScript 코드는 초보자가 이해하기 쉽게 짧게 작성할 것
3. 각 코드에 필요한 경우 간단한 주석을 달 것
4. 수정 후 어떤 파일이 어떻게 바뀌었는지 요약할 것

먼저 작업 계획을 보여줘.

기능 추가 요청에는 항상 동작 방식을 넣으세요.
버튼을 누른다, 글자가 바뀐다, 목록이 추가된다, 입력값이 비워진다.
눈에 보이는 움직임을 문장으로 적으면 됩니다.

버튼 기능을 추가할 때

[버튼 이름] 버튼을 추가해줘.
버튼을 클릭하면 [원하는 동작]이 일어나게 해줘.
기존 HTML 구조를 크게 바꾸지 말고, 필요한 부분만 수정해줘.
script.js에 초보자가 이해하기 쉬운 방식으로 작성해줘.

입력창 기능을 추가할 때

페이지에 입력창과 버튼을 추가하고 싶어.
사용자가 [입력할 내용]을 입력하고 버튼을 누르면, 그 내용이 화면에 [어떻게 표시될지] 보여줘.
새로고침하면 데이터가 사라져도 괜찮아.
HTML, CSS, JavaScript만 사용해줘.

"새로고침하면 데이터가 사라져도 괜찮아"라는 문장은 의외로 중요합니다.
초보 프로젝트에서 데이터 저장까지 한 번에 넣으면 코드가 갑자기 복잡해질 수 있습니다.

레시피 04. 에러가 났을 때

에러가 나면 당황해서 이렇게 말하기 쉽습니다.

안 돼. 고쳐줘.

하지만 Claude는 무엇이 안 되는지 모릅니다.
에러 해결에는 세 가지가 필요합니다.

• 오류 메시지

• 내가 한 행동

• 기대한 결과

아래 프롬프트를 그대로 쓰세요.

아래 에러를 해결해줘.
먼저 원인을 짧게 설명하고, 어떤 파일을 수정할지 알려줘.
그다음 최소한의 수정으로 고쳐줘.

오류 메시지:
[터미널 또는 브라우저 콘솔에 나온 에러를 그대로 붙여넣기]

내가 한 행동:
1. [예: index.html을 브라우저에서 열었음]
2. [예: 다크모드 버튼을 클릭했음]
3. [예: 아무 반응이 없었음]

기대한 동작:
[예: 버튼을 누르면 화면이 어두운 테마로 바뀌어야 함]

주의할 점:
기존 디자인과 구조는 최대한 유지해줘.
수정 후 내가 다시 확인할 방법도 알려줘.

에러 메시지는 지저분해 보여도 괜찮습니다.
오히려 그대로 붙여 넣는 편이 좋습니다.
중간을 예쁘게 고치려고 하다가 중요한 단서가 빠질 수 있습니다.

브라우저 콘솔 에러용

브라우저 개발자 도구 콘솔에 아래 에러가 나왔어.
이 에러가 왜 생겼는지 초보자도 이해할 수 있게 설명해줘.
그리고 필요한 파일만 최소 수정해서 고쳐줘.

콘솔 에러:
[콘솔 에러 붙여넣기]

에러가 난 상황:
[예: 버튼을 클릭했을 때 / 페이지를 처음 열었을 때 / 입력창에 글을 쓰고 제출했을 때]

터미널 에러용

터미널에서 아래 에러가 나왔어.
명령어를 실행한 상황과 에러 메시지를 함께 보낼게.

실행한 명령어:
[예: npm run dev]

오류 메시지:
[터미널에 나온 내용을 그대로 붙여넣기]

원하는 것:
1. 에러 원인을 짧게 설명해줘
2. 내가 지금 입력해야 할 명령어나 수정할 파일을 알려줘
3. 위험한 삭제나 큰 변경이 필요하면 먼저 물어봐줘

에러 해결의 목표는 "한 번에 멋지게 고치기"가 아닙니다.
지금 막힌 지점을 통과하기입니다.

레시피 05. 승인하기 전에 안전 검토하기

Claude Code를 쓰다 보면 파일 수정 전에 승인할지 묻는 순간이 옵니다.
이때 바로 y를 누르기 전에, 아래 문장을 한 번 더 던져보세요.

아직 파일을 수정하지 마.
먼저 이번 작업의 안전 검토를 해줘.

확인할 것:
1. 수정할 파일 목록
2. 각 파일에서 바꿀 내용 요약
3. 삭제되거나 크게 바뀌는 코드가 있는지
4. 예상되는 위험 요소
5. 문제가 생겼을 때 되돌리는 방법

검토 결과를 보고 내가 승인하면 그때 수정해줘.

이 프롬프트는 초보자에게 특히 강력합니다.
무엇을 바꾸는지 알고 승인하면, 터미널이 덜 무섭습니다.

변경 범위를 줄이고 싶을 때

방금 제안한 수정 범위가 너무 커 보여.
이번에는 [파일명]만 수정하는 방식으로 다시 계획해줘.
기능을 완벽하게 바꾸기보다, 현재 문제를 해결하는 최소 수정안을 원해.

되돌리기 방법을 먼저 알고 싶을 때

수정하기 전에 되돌리기 방법을 먼저 알려줘.
이번 작업으로 바뀔 파일을 기준으로, 문제가 생겼을 때 내가 어떤 순서로 원래 상태에 가깝게 되돌릴 수 있는지 설명해줘.
그전에는 파일을 수정하지 마.

위험한 명령어인지 물어볼 때

이 명령어나 작업이 안전한지 먼저 설명해줘.
특히 파일 삭제, 폴더 삭제, 패키지 설치, 설정 변경이 포함되어 있는지 확인해줘.
초보자가 승인해도 되는 작업인지 짧게 판단해줘.

delete, remove, rm, overwrite 같은 말이 보이면 잠깐 멈추세요.
모르면 거절해도 됩니다. Claude에게 다시 물어보면 됩니다.

레시피 06. 파일이 많아졌을 때 길을 잡기

프로젝트가 커지면 Claude도 맥락이 필요합니다.
이때는 "전체를 알아서 봐줘"보다 "어디를 중심으로 볼지"를 알려주는 편이 좋습니다.

현재 프로젝트에서 [작업하려는 기능]을 수정하고 싶어.
먼저 관련 있어 보이는 파일만 찾아서 알려줘.

조건:
1. 바로 수정하지 말 것
2. 관련 파일 후보와 이유를 먼저 설명할 것
3. 수정이 꼭 필요한 파일과 참고만 하면 되는 파일을 나눠서 말할 것
4. 내가 승인하면 그때 작업할 것

특정 파일만 보고 작업하게 하기

이번 작업에서는 아래 파일만 보고 수정해줘.

수정 허용 파일:
- [파일명 1]
- [파일명 2]

수정 금지 파일:
- [파일명 3]
- [파일명 4]

목표:
[원하는 작업]

수정 금지 파일은 읽고 참고할 수는 있지만, 변경하지 마.

이 문장은 프로젝트가 커질수록 빛을 발합니다.
Claude에게도 작업실의 출입문을 정해주는 셈입니다.

레시피 07. 결과물을 점검할 때

작업이 끝났다고 바로 끝난 것은 아닙니다.
브라우저에서 보고, 버튼을 눌러보고, 모바일 크기로 줄여봐야 합니다.

Claude에게도 점검표를 만들게 하세요.

방금 작업한 내용을 기준으로 확인 체크리스트를 만들어줘.

체크리스트에는 아래 내용을 포함해줘.
1. 브라우저에서 확인할 것
2. 버튼이나 링크를 눌러볼 것
3. 모바일 화면에서 확인할 것
4. 깨진 디자인이 없는지 볼 것
5. 문제가 생기면 어떤 파일을 먼저 봐야 하는지

초보자가 따라할 수 있게 순서대로 적어줘.

셀프 리뷰를 시킬 때

현재 코드에서 초보자가 놓치기 쉬운 문제를 찾아줘.
단, 바로 수정하지 말고 리뷰만 해줘.

봐야 할 것:
1. 사용하지 않는 코드가 있는지
2. 파일명이 잘 연결되어 있는지
3. 버튼이나 링크가 실제로 동작하는지
4. 모바일에서 불편한 부분이 있는지
5. 더 단순하게 만들 수 있는 부분이 있는지

중요도 순서대로 알려줘.

리뷰만 요청하는 습관은 좋습니다.
수정과 검토를 나누면, 내가 프로젝트의 주도권을 놓치지 않습니다.

레시피 08. README와 사용 방법 정리하기

프로젝트가 어느 정도 완성되면 README를 만드세요.
README는 사람에게 보여주는 설명서이자, 미래의 나를 위한 메모입니다.

현재 프로젝트를 기준으로 README.md를 작성해줘.

포함할 내용:
1. 프로젝트 이름
2. 한 줄 소개
3. 주요 기능
4. 사용 기술
5. 파일 구조
6. 실행 방법
7. 내가 직접 수정하면 좋은 부분
8. 앞으로 개선할 아이디어

문장은 초보자도 이해하기 쉽게 짧고 명확하게 써줘.
과장된 표현은 빼고, 실제 프로젝트 내용만 기준으로 작성해줘.

사용 방법만 따로 정리할 때

이 프로젝트를 처음 보는 사람이 실행할 수 있도록 사용 방법을 정리해줘.
필요한 명령어, 열어야 할 파일, 확인해야 할 화면을 순서대로 적어줘.
초보자가 막힐 만한 지점도 함께 알려줘.

남은 개선점을 뽑을 때

현재 프로젝트에서 다음에 개선하면 좋을 점을 알려줘.
단, 너무 어려운 기능 말고 초보자가 하나씩 도전할 수 있는 순서로 추천해줘.

형식:
- 쉬움: 바로 해볼 수 있는 개선
- 보통: 조금 찾아보며 할 수 있는 개선
- 어려움: 나중에 도전할 개선

마무리 정리는 단순한 청소가 아닙니다.
다음 작업을 쉽게 시작하게 만드는 표시입니다.

레시피 09. 배포하거나 공유하기 전에

누군가에게 링크를 보내기 전에는 마지막 점검이 필요합니다.

이 프로젝트를 다른 사람에게 공유하기 전에 점검하고 싶어.

확인할 것:
1. 깨진 링크가 있는지
2. 이미지 파일 경로가 맞는지
3. 모바일에서 보기 좋은지
4. 불필요한 테스트 문구가 남아 있는지
5. README에 실행 방법이 충분히 적혀 있는지

바로 수정하지 말고, 먼저 점검 결과와 수정이 필요한 항목을 알려줘.

포트폴리오 문구를 다듬을 때

포트폴리오에 들어갈 문구를 다듬어줘.

현재 문구:
[현재 문구 붙여넣기]

원하는 느낌:
[예: 담백하고 자신감 있게 / 친근하지만 가볍지 않게 / 짧고 선명하게]

조건:
1. 과장하지 말 것
2. 문장을 너무 길게 만들지 말 것
3. 방문자가 바로 이해할 수 있게 쓸 것
4. 수정안 3가지를 제안할 것

기술보다 문구가 더 어려울 때도 있습니다.
그럴 때 Claude를 글 편집자로 쓰면 좋습니다.

레시피 10. 한 번에 너무 커졌을 때 작게 쪼개기

Claude가 갑자기 많은 파일을 고치려고 한다면, 작업을 쪼개세요.

이번 작업이 너무 커진 것 같아.
목표를 작은 단계로 나눠줘.

조건:
1. 각 단계는 10분 안에 확인할 수 있을 정도로 작게 나눌 것
2. 1단계가 끝나면 브라우저에서 무엇을 확인해야 하는지 알려줄 것
3. 한 단계마다 수정할 파일을 최소화할 것
4. 지금은 1단계만 진행할 것

이 문장은 프로젝트가 산으로 가는 것을 막아줍니다.
큰 결과물도 결국 작은 승인들의 합입니다.

바로 쓰는 10초 카드

아래 문장들은 더 짧은 버전입니다.
급할 때 하나씩 꺼내 쓰세요.

마지막으로 기억할 한 줄

Claude Code는 대신 만들어주는 도구이지만, 방향을 정하는 사람은 나입니다.

처음에는 복사해서 쓰면 됩니다.
조금 익숙해지면 단어를 바꾸고, 범위를 줄이고, 완료 기준을 더 선명하게 쓰면 됩니다.

좋은 프롬프트는 길고 화려한 문장이 아닙니다.

무엇을 만들지,
어떤 파일을 바꿀지,
언제 끝난 것으로 볼지,
수정 전에 무엇을 확인할지.

이 네 가지만 말할 수 있으면 충분합니다.

이제 검은 화면은 더 이상 낯선 방이 아닙니다.
필요할 때 열고, 한 문장 붙여 넣고, 작은 결과를 하나씩 쌓아가면 됩니다.