프롬프트를 잘 쓰는 단계까지 왔다면, 이제 중요한 것은 “AI가 코드를 바꾸게 하는 순서”입니다. 실제 프로젝트에서는 곧바로 “이 기능 수정해줘”라고 맡기는 것보다, 먼저 코드 위치를 찾고, 작업 계획을 확인한 뒤, 변경 내용을 검토하고, 테스트를 거쳐 저장하는 흐름이 훨씬 안전합니다.

Claude Code는 터미널에서 프로젝트 코드를 읽고 수정할 수 있는 도구입니다. 웹사이트의 작은 기능을 고칠 때도 이 기본 루프를 지키면, 비개발자도 변경 범위를 통제하면서 작업할 수 있습니다.

1. 코드 분석: 어디를 고쳐야 하는지 파악

웹사이트 기능 수정의 첫 단계는 “수정”이 아니라 “파악”입니다. 버튼 문구 하나를 바꾸는 작업처럼 단순해 보여도 실제 코드는 여러 파일에 나뉘어 있을 수 있습니다. 화면 파일, 상태 관리 파일, API 호출 파일, 스타일 파일이 따로 존재하는 경우가 많습니다.

먼저 프로젝트 폴더로 이동한 뒤 현재 상태를 확인합니다.

cd your-project-folder
git status

작업 중인 변경 사항이 이미 있다면, 새 수정과 섞이지 않도록 먼저 확인해야 합니다. `git status`에서 수정된 파일이 많이 보이면 바로 진행하지 말고, 어떤 변경인지 확인하는 편이 안전합니다.

Claude Code를 실행합니다.

claude

처음부터 수정을 요청하지 말고, 분석만 요청합니다. 예를 들어 “문의하기 버튼을 누르면 이동하는 페이지를 바꾸고 싶다”는 상황이라면 다음처럼 입력할 수 있습니다.

문의하기 버튼을 클릭했을 때 이동하는 경로를 수정하려고 합니다.
아직 코드를 수정하지 말고, 관련된 파일과 현재 동작 흐름만 찾아서 설명해 주세요.
파일 경로, 주요 컴포넌트, 클릭 이벤트 또는 링크 처리 위치를 구분해서 알려 주세요.

여기서 핵심은 “아직 수정하지 말고”입니다. AI 코딩 도구는 요청을 받으면 바로 고치려는 경향이 있으므로, 분석 단계와 수정 단계를 분리해야 합니다.

Claude Code가 관련 파일을 찾아 설명하면, 다음 내용을 확인합니다.

- 실제 화면을 담당하는 파일인지

- 링크나 버튼 클릭 이벤트가 어디에서 처리되는지

- 라우팅 경로가 하드코딩되어 있는지

- 공통 컴포넌트를 여러 페이지에서 함께 쓰는지

- 수정하면 다른 화면에도 영향을 주는지

공통 버튼 컴포넌트를 수정하면 여러 페이지가 동시에 바뀔 수 있습니다. 이 지점을 놓치면 “한 화면만 고치려던 작업”이 전체 사이트 변경으로 번질 수 있습니다.

2. 작업 계획 세우기

코드 위치를 찾았다고 바로 수정하지 않습니다. 다음 단계는 작업 계획입니다. Claude Code에게 “어떤 파일을 어떤 방식으로 바꿀지” 먼저 제안하게 해야 합니다.

방금 찾은 내용을 기준으로 수정 계획을 세워 주세요.
목표는 문의하기 버튼 클릭 시 /contact 페이지로 이동하도록 바꾸는 것입니다.

다음 형식으로 답변해 주세요.
1. 수정할 파일
2. 수정할 코드의 역할
3. 예상 변경 내용
4. 영향을 받을 수 있는 화면
5. 테스트해야 할 항목

아직 파일은 수정하지 마세요.

이 계획을 보면 작업 범위가 보입니다. 예를 들어 `Header.tsx`만 바꾸면 되는지, `routes.ts` 또는 `navigation.ts` 같은 설정 파일도 함께 수정해야 하는지 알 수 있습니다.

계획이 너무 넓으면 다시 좁혀야 합니다.

변경 범위를 최소화해 주세요.
스타일 변경, 리팩터링, 파일 구조 변경은 하지 말고
문의하기 버튼의 이동 경로 수정에 필요한 최소 변경만 제안해 주세요.

바이브 코딩에서 자주 생기는 문제는 “작은 요청이 큰 리팩터링으로 바뀌는 것”입니다. Claude Code가 더 나은 구조를 제안하더라도, 지금 목표가 기능 수정이라면 범위를 유지하는 쪽이 좋습니다.

3. 수정 요청과 변경안(diff) 확인

계획이 납득되면 그때 수정을 요청합니다. 요청 문장은 구체적이어야 합니다.

위 계획대로 최소 범위만 수정해 주세요.
문의하기 버튼 클릭 시 /contact 페이지로 이동하도록 변경해 주세요.
불필요한 리팩터링, 스타일 변경, 파일명 변경은 하지 마세요.
수정 후 변경된 파일 목록과 변경 이유를 설명해 주세요.

Claude Code가 파일을 수정한 뒤에는 반드시 직접 diff를 확인합니다. 터미널에서 다음 명령어를 사용합니다.

git diff

특정 파일만 보고 싶을 때는 파일 경로를 붙입니다.

git diff path/to/file

diff를 볼 때는 세 가지를 확인합니다.

첫째, 요청한 기능과 관련 없는 변경이 섞였는지 봅니다. 버튼 이동 경로만 바꾸기로 했는데 스타일, 포맷팅, 파일 구조가 함께 바뀌었다면 되돌리거나 다시 요청하는 것이 좋습니다.

둘째, 문자열 하나만 바뀐 것처럼 보여도 실제 경로가 프로젝트 라우팅 규칙과 맞는지 확인합니다. 예를 들어 Next.js 프로젝트라면 `/contact`에 해당하는 페이지가 실제로 존재해야 합니다.

셋째, 공통 컴포넌트 수정인지 확인합니다. 공통 헤더의 링크를 바꾸는 작업이라면 모든 페이지에 반영될 수 있습니다. 의도한 변경이면 괜찮지만, 특정 페이지에서만 달라져야 하는 요구사항이라면 접근 방식이 달라져야 합니다.

원하지 않는 변경이 있다면 Claude Code에 바로 되돌리게 요청할 수 있습니다.

방금 변경 중에서 스타일 관련 수정은 되돌려 주세요.
기능 변경에 필요한 이동 경로 수정만 남겨 주세요.
수정 후 다시 변경 파일 목록을 알려 주세요.

또는 Git으로 전체 변경을 되돌릴 수도 있습니다. 다만 이 명령은 작업 내용이 사라질 수 있으므로 주의해서 사용해야 합니다.

git checkout -- path/to/file

최근 Git에서는 아래 명령도 사용됩니다.

git restore path/to/file

4. 테스트로 동작 검증

코드가 바뀌었다면 실제로 실행해서 확인해야 합니다. 프로젝트마다 실행 명령은 다를 수 있습니다. `package.json`에 정의된 스크립트를 먼저 확인합니다.

cat package.json

일반적인 프론트엔드 프로젝트에서는 다음과 같은 명령이 자주 사용됩니다.

npm install
npm run dev

이미 의존성이 설치되어 있다면 `npm install`은 매번 실행하지 않아도 됩니다. 개발 서버를 실행한 뒤 브라우저에서 해당 화면을 열고, 수정한 버튼을 직접 클릭합니다.

테스트할 항목은 단순히 “클릭이 된다”에서 끝나면 안 됩니다.

- 버튼이 보이는 페이지가 정상적으로 열리는지

- 버튼 클릭 시 `/contact`로 이동하는지

- 새로고침해도 해당 페이지가 정상 표시되는지

- 모바일 화면이나 다른 주요 페이지에서 문제가 없는지

- 콘솔에 오류가 뜨지 않는지

자동 테스트가 있는 프로젝트라면 테스트 명령도 실행합니다.

npm test

또는 프로젝트에 따라 다음 명령이 있을 수 있습니다.

npm run test
npm run lint
npm run build

어떤 명령을 써야 할지 모르겠다면 Claude Code에 물어볼 수 있습니다.

이 프로젝트에서 기능 수정 후 확인해야 할 테스트 명령을 package.json 기준으로 찾아 주세요.
명령어가 실제로 정의되어 있는 경우만 알려 주세요.

중요한 점은 “실제로 정의된 명령만 실행”하는 것입니다. `npm run lint`가 없는 프로젝트에서 실행하면 오류가 납니다. 오류 자체가 코드 문제는 아닐 수 있으므로, 먼저 스크립트 존재 여부를 확인해야 합니다.

5. 커밋 요청으로 안전하게 저장

테스트까지 통과했다면 변경 내용을 저장할 차례입니다. 커밋은 작업 단위의 저장점입니다. 커밋을 잘게 남기면 나중에 문제가 생겼을 때 되돌리기 쉽습니다.

먼저 변경 상태를 확인합니다.

git status

변경 내용을 다시 확인합니다.

git diff

Claude Code에게 커밋 메시지를 제안하게 할 수 있습니다.

현재 변경 내용을 기준으로 적절한 Git 커밋 메시지를 제안해 주세요.
한 줄 요약 형식으로, 무엇을 왜 바꿨는지 드러나게 작성해 주세요.

예를 들어 다음과 같은 메시지가 나올 수 있습니다.

Update contact button link to navigate to contact page

커밋할 파일을 추가합니다.

git add path/to/file

여러 파일을 한 번에 추가할 수도 있지만, 처음에는 파일을 명시하는 방식이 안전합니다.

git status

이후 커밋합니다.

git commit -m "Update contact button link to navigate to contact page"

Claude Code에게 커밋까지 요청할 수도 있지만, 초반에는 `git diff`, `git status`, `git commit`을 직접 확인하면서 진행하는 편을 권장합니다. 커밋은 저장점이기 때문에 사람이 마지막으로 확인하는 습관을 들이는 것이 좋습니다.

작업 루프는 다음 순서로 반복하면 됩니다.

분석 요청
→ 작업 계획 확인
→ 최소 범위 수정 요청
→ git diff 확인
→ 실행 및 테스트
→ git status 확인
→ 커밋

Claude Code를 잘 쓰는 핵심은 더 많은 일을 한 번에 시키는 것이 아니라, 한 단계씩 통제하는 것입니다. 코드 분석과 수정 요청을 분리하고, diff와 테스트를 거친 뒤 커밋하는 루프만 익혀도 실제 웹사이트 기능 수정의 안정성이 크게 올라갑니다.