Claude Code에 수정 요청할 때 이렇게 말하면 잘 고쳐준다

Claude Code를 쓰다 보면 한 번쯤 이런 경험을 합니다. "이 부분 좀 고쳐줘"라고 했는데 전혀 엉뚱한 부분을 바꾸거나, 고쳐달라는 건 손도 안 대고 다른 내용을 추가해 오는 경우입니다. 수정 요청이 잘 안 먹힌다고 느낀다면, Claude Code가 부족한 게 아니라 요청 방식에 개선할 여지가 있는 겁니다. 같은 내용을 어떻게 말하느냐에 따라 결과물이 달라지기 때문입니다. 이 글에서는 수정 요청이 왜 실패하는지 살펴보고, 실제로 잘 먹히는 표현 패턴 네 가지를 구체적인 예시와 함께 정리합니다.

 

모호한 수정 요청이 실패하는 이유

수정 요청이 먹히지 않는 가장 흔한 원인은 요청이 너무 추상적이기 때문입니다. "이상한 것 같은데 고쳐줘", "좀 더 자연스럽게 바꿔줘", "이 부분이 맘에 안 드네" — 이런 요청은 사람에게도 답하기 어렵습니다. Claude Code는 맥락(context)을 기반으로 판단하는데, 맥락이 빠지면 추측에 의존할 수밖에 없습니다.

 

더 구체적으로 설명하겠습니다. Claude Code는 기본적으로 대화 흐름 전체를 참고해서 의도를 파악합니다. 그런데 "고쳐줘"라는 말 하나만 있으면 — 어느 파일인지, 어느 줄인지, 무엇이 문제인지, 어떻게 되길 원하는지 — 아무것도 알 수 없습니다. 결국 Claude Code는 가장 그럴싸한 해석을 골라 시도하게 되고, 그 해석이 틀리면 수정이 엉뚱하게 됩니다.

 

모호한 요청이 가져오는 또 다른 문제는 수정 범위입니다. 넓게 해석하면 너무 많이 바꾸고, 좁게 해석하면 정작 원하는 부분은 그대로 남습니다. 제가 보기에는 수정 요청 실패의 80% 이상이 이 '범위 불명확' 문제에서 비롯됩니다. 정확히 어디를, 어떻게, 왜 바꾸길 원하는지를 함께 전달하면 결과물이 눈에 띄게 달라집니다.

 

한 가지 더 있습니다. 코드를 처음 작성할 때와 수정을 요청할 때는 Claude Code가 다른 상태에 있습니다. 처음 작성할 때는 요청이 넓어도 방향 잡기가 비교적 쉽습니다. 하지만 수정 요청에서는 이미 만들어진 결과물 중에서 '어느 부분을 어떤 방향으로 바꿀지'를 특정해야 합니다. 그래서 수정 요청일수록 더 구체적인 정보가 필요합니다.

 

 

수정 요청을 잘 먹히게 하는 4가지 패턴

수정 요청에는 네 가지 핵심 패턴이 있습니다. 모두 갖추면 가장 좋지만, 하나씩이라도 의식적으로 적용하면 성공률이 달라집니다.

 

패턴 1 — 어디가 문제인지 구체적으로 짚기

"3번째 섹션에서 함수가 실행되지 않습니다"처럼 위치와 증상을 함께 알려주는 방식입니다. 파일 이름, 함수 이름, 줄 번호, 섹션 번호 등 위치를 특정할 수 있는 정보라면 무엇이든 포함합니다. Claude Code는 파일 내용을 통째로 읽고 있기 때문에, 위치를 명시하면 탐색 범위가 줄어들어 정확도가 높아집니다.

 

패턴 2 — 원하는 결과를 명시하기

"이렇게 되길 원합니다"라는 목표 상태를 명확히 전달합니다. "출력값이 숫자가 아니라 문자열로 나왔으면 합니다", "버튼을 클릭하면 팝업이 뜨지 않고 바로 다음 페이지로 이동했으면 합니다" — 이처럼 결과를 구체적으로 표현하면 Claude Code가 정확히 어느 방향으로 코드를 수정해야 할지 판단할 수 있습니다.

 

패턴 3 — 오류 메시지나 현재 상태를 그대로 붙여넣기

터미널에 빨간 글씨로 오류가 떴다면, 그 메시지 전체를 복사해서 붙여넣으면 됩니다. TypeError: cannot read properties of undefined처럼 구체적인 오류 메시지는 Claude Code에게 가장 직접적인 단서가 됩니다. 오류 메시지 없이 "오류가 나요"라고만 하면, Claude Code는 모든 가능성을 다 뒤져야 합니다

.

패턴 4 — 한 번에 하나씩 요청하기

"여기도 고치고, 저기도 바꾸고, 이 기능도 추가해줘"처럼 여러 가지를 한꺼번에 요청하면 작업이 뒤섞입니다. 하나의 수정 요청이 다른 수정 요청에 영향을 줄 수 있기 때문입니다. 한 번에 하나씩 처리하고, 결과를 확인한 다음 다음 요청으로 넘어가는 방식이 전체적으로 훨씬 빠릅니다.

 

예를 들어 "로그인 버튼도 고치고, 입력 유효성 검사도 추가하고, 디자인도 좀 바꿔줘"라고 요청하면, Claude Code는 세 가지를 동시에 처리하다가 서로 충돌하는 수정을 만들어 낼 수 있습니다. 로그인 버튼 수정이 입력 유효성 검사 로직에 영향을 줄 수도 있고, 디자인 변경이 버튼 동작을 덮어쓸 수도 있습니다. 하나씩 처리하면 각 단계의 결과를 확인하고 다음 단계로 넘어갈 수 있어서, 중간에 잘못된 방향으로 흘러가는 것을 막을 수 있습니다.

아래 화면처럼 구체적인 오류 메시지와 위치 정보를 함께 붙여넣는 방식이 가장 효과적입니다.

 

 

나쁜 요청 vs 좋은 요청 — 실제 비교

같은 문제를 두 가지 방식으로 요청하면 어떻게 달라지는지 비교해 보겠습니다.

 

예시 1 — 출력 형식 문제

나쁜 요청: "출력이 이상해요. 고쳐주세요."

좋은 요청: "report.py의 print_summary() 함수 결과물이 숫자 대신 None으로 출력됩니다. total_count 변수 값이 제대로 반환되도록 수정해 주세요."

 

예시 2 — 기능 동작 문제

나쁜 요청: "버튼이 안 눌려요."

좋은 요청: "index.html 파일의 submit-btn 버튼을 클릭하면 아무 반응이 없습니다. 콘솔에는 Uncaught ReferenceError: submitForm is not defined 오류가 떠 있습니다. submitForm 함수가 정의되지 않은 원인을 찾아서 수정해 주세요."

 

예시 3 — 스타일/내용 수정

나쁜 요청: "글이 너무 딱딱해요."

좋은 요청: "2번째 단락이 너무 기술 용어 위주로 작성되어 있습니다. 프로그래밍을 전혀 모르는 사람도 읽을 수 있도록 쉬운 말로 바꿔 주세요."

 

세 가지 예시 모두 구조가 같습니다. 위치(어느 파일, 어느 함수, 어느 단락), 현상(무엇이 어떻게 잘못됐는지), 목표(어떻게 되길 원하는지)를 갖추고 있습니다. 이 세 요소만 챙겨도 요청의 질이 크게 높아집니다.

 

처음에는 이렇게 요청하는 게 번거롭게 느껴질 수 있습니다. "그냥 고쳐줘"라고 하면 되는데 왜 이렇게 길게 써야 하냐고 생각할 수도 있습니다. 하지만 현실적으로 따져보면, 모호하게 요청하고 엉뚱한 결과가 나와서 다시 설명하는 시간이 처음부터 구체적으로 쓰는 시간보다 훨씬 길게 걸립니다. 처음 요청 한 번을 제대로 쓰는 게 결국 더 빠릅니다.

아래 화면처럼 나쁜 요청과 좋은 요청을 나란히 비교해 보면 차이가 바로 보입니다.

 

 

 

반복 개선 전략 — 2~3번 주고받으면 달라진다

한 번 요청해서 완벽하게 고쳐지길 기대하는 것은 처음부터 욕심입니다. Claude Code도 처음엔 요청을 최선으로 해석해서 수정하지만, 정확히 원하는 방향이 아닐 수 있습니다. 이때 중요한 건 대화를 이어가는 방식입니다.

 

1차 수정이 돌아오면 결과를 확인하고, 부족한 부분을 다시 구체적으로 피드백합니다. "이 부분은 잘 됐는데, 3번째 줄의 들여쓰기가 여전히 맞지 않습니다"처럼 개선된 점을 인정하면서 남은 문제를 짚어주면 됩니다. 이렇게 2~3회 주고받으면 처음 한 번 완벽하게 요청하려고 고민하는 것보다 오히려 빠르게 원하는 결과에 도달할 수 있습니다.

 

반복 개선 전략에서 하나 더 주의할 점이 있습니다. 1차 수정 후 "아니요, 다시 해주세요"처럼 방향 없는 피드백은 또 다른 모호한 요청입니다. "어떻게 다시"가 빠졌기 때문입니다. 무엇이 기대와 달랐는지, 어떤 방향으로 바꿔야 하는지를 함께 알려줘야 2차 수정이 의미 있어집니다.

 

수정 요청이 반복될수록 Claude Code는 해당 프로젝트의 맥락을 점점 더 잘 이해하게 됩니다. 같은 세션(대화창) 안에서 작업을 이어가면, 앞서 나눈 내용을 참고해서 나중 요청을 더 잘 처리합니다. 세션을 끊지 않고 이어서 작업하는 것만으로도 수정 정확도가 높아지는 이유가 여기에 있습니다.

 

반복 개선이 특히 효과적인 상황이 있습니다. 처음에 원하는 결과를 말로 표현하기 어려울 때입니다. "뭔가 어색한데 어떻게 고쳐야 할지 모르겠다"는 상황에서는 일단 Claude Code에게 여러 버전을 만들어달라고 하는 것도 방법입니다. "이 단락을 세 가지 다른 방식으로 고쳐서 보여줘"라고 요청하면 보기를 비교하면서 원하는 방향을 더 쉽게 잡을 수 있습니다. 방향을 잡은 다음에는 "두 번째 버전의 방향은 맞는데, 첫 문장만 더 짧게 바꿔줘"처럼 구체적으로 좁혀가면 됩니다.

 

아래 화면처럼 1차 수정 피드백 → 2차 수정 확인 → 최종 승인으로 이어지는 흐름이 효율적인 반복 개선의 예시입니다.

 

 

수정 요청을 잘 하는 건 특별한 기술이 아닙니다. 위치, 현상, 목표 — 이 세 가지를 습관처럼 포함하고, 한 번에 하나씩 처리하고, 결과를 보면서 이어가면 됩니다. 처음엔 조금 번거롭게 느껴질 수 있지만, 몇 번 해보면 어느새 자연스럽게 이 방식으로 요청하게 됩니다. Claude Code는 잘 말하는 만큼 잘 고쳐줍니다. 요청하는 방식을 조금만 바꿔도 결과물의 질이 눈에 띄게 달라집니다.