클로드 코드 기본 사용법 — 이제 직접 일을 맡겨 보자

이제 진짜 일을 맡겨 볼 차례

3편까지 따라왔다면 설치도 설정도 끝났습니다. 남은 건 실제로 일을 맡기는 것뿐입니다.

그런데 막상 맡기려고 하면 어디까지 부탁해도 되는지, 어떻게 말해야 알아듣는지 감이 잘 안 잡힙니다. 한 번에 크게 부탁했다가 엉뚱한 곳까지 바뀌어서 되돌린 경험이 몇 번 쌓이면 손이 굳기도 하죠.

사실 요령은 몇 가지뿐입니다. 이 글에서는 일을 어떻게 나눠 맡기고, 결과를 어떻게 확인하고, 방향이 틀어졌을 때 어떻게 되돌리는지를 순서대로 봅니다.

파일을 가리키는 법이나 모드를 바꾸는 조작은 VS Code에서 클로드 코드 쓰기에 정리해 뒀으니 필요하면 같이 보세요.

한 번에 하나씩, 작게 부탁하기

2편에서 만든 할 일 목록 페이지로 예를 들어 보겠습니다. 이렇게 부탁하면 어떻게 될까요.

할 일 목록 페이지 좀 더 좋게 만들어 줘.

클로드는 “좋게”를 나름대로 해석합니다. 디자인을 바꾸고, 기능을 몇 개 덧붙이고, 코드 구조도 정리할 수 있습니다. 결과가 마음에 들 수도 있지만, 무엇이 얼마나 바뀌었는지 확인하기 어렵고 마음에 안 드는 부분만 골라서 되돌리기도 어렵습니다.

같은 일을 이렇게 부탁해 보세요.

할 일 목록에서 완료한 항목은 목록 맨 아래로 내려가게 해 줘.
다른 기능이나 디자인은 건드리지 마.

바뀌는 곳이 하나라서 결과를 보자마자 맞는지 알 수 있습니다. 틀렸다면 그 부분만 다시 말하면 됩니다.

부탁할 때는 무엇을 바꿀지, 건드리지 말아야 할 곳은 어디인지를 함께 적어 주세요. 이미 비슷한 것이 있다면 그걸 가리키는 것도 좋습니다. “지금 있는 추가 버튼과 같은 모양으로 삭제 버튼을 만들어 줘”라고 하면 새로 디자인을 고민하지 않고 기존 모양을 따라 만듭니다.

여러 파일을 고치는 일은 계획부터 보기

고칠 곳이 여러 파일에 걸쳐 있거나, 어떻게 만들어야 할지 나도 확실하지 않을 때는 바로 고치게 하지 말고 계획부터 받아 보는 게 좋습니다. 클로드가 엉뚱한 방향으로 한참 고친 뒤에 되돌리는 것보다, 계획 단계에서 방향을 잡는 쪽이 훨씬 수월합니다.

순서는 이렇습니다.

  1. 권한 모드를 Plan으로 바꿉니다. 터미널에서는 입력창 아래 모드 이름이 Plan이 될 때까지 Shift+Tab을 누르고, VS Code 확장에서는 입력창 아래 모드 이름을 클릭해 고릅니다.
  2. “무엇을 어떻게 바꿀지 계획만 보여 줘”라고 부탁합니다. Plan 모드에서는 클로드가 파일을 읽기만 하고 고치지 않습니다.
  3. 계획을 읽고 빠진 것이나 원하지 않는 부분을 말합니다. “3번 단계는 빼 줘”처럼 짧게 말해도 됩니다.
  4. 계획이 괜찮으면 승인합니다. 그때부터 클로드가 계획대로 고치기 시작합니다.

반대로 오타 하나 고치기, 글자 색 하나 바꾸기처럼 한 문장으로 설명되는 일에는 계획이 필요 없습니다. 공식 문서도 바뀔 내용을 한 문장으로 말할 수 있으면 계획을 건너뛰라고 합니다. 괜히 계획부터 받으면 오히려 번거롭습니다.

“됐어?” 대신 확인할 방법을 같이 주기

클로드는 일이 끝난 것처럼 보이면 멈춥니다. 확인할 방법이 따로 없으면 “끝난 것 같다”는 느낌이 기준이 됩니다. 그래서 “다 됐습니다”라고 했는데 막상 열어 보면 안 되어 있는 일이 생깁니다.

부탁할 때 무엇으로 확인하면 되는지까지 적어 주면 이런 일이 크게 줄어듭니다.

빈칸일 때 추가 버튼을 누르면 목록에 아무것도 추가되지 않게 해 줘.
고친 다음, 빈칸일 때와 글자를 넣었을 때 각각 어떻게 되는지 확인하고 결과를 알려 줘.

이렇게 하면 클로드가 고친 뒤 스스로 확인하고, 안 되면 다시 고칩니다. “확인했습니다”라는 말만 듣지 말고 무엇으로 확인했는지 보여 달라고 하는 것도 좋습니다. 결과를 직접 보는 편이 한 번 더 확인하는 수고를 줄여 줍니다.

다만 클로드가 확인할 수 없는 것도 있습니다. 실제 휴대폰에서 화면이 어떻게 보이는지, 색이 눈에 편한지 같은 건 사람이 봐야 합니다. 이런 부분은 “이건 직접 확인하지 못했다고 말해 줘”라고 미리 부탁해 두면, 확인한 것과 못 한 것을 구분해서 알려 줍니다.

저도 기능 하나를 만들어 달라고 부탁하고 “완료했습니다”라는 답을 받은 적이 있습니다. 그런데 화면에 보이는 부분만 만들어져 있었고, 직접 값을 넣어 시험해 보니 결과가 엉망이었습니다.

그래서 기능을 만들어 달라고 할 때마다 “만든 다음 직접 시험해 보고 결과를 알려 줘”를 함께 적었습니다. 그런데 이 말을 매번 반복하게 되더군요. 결국 3편에서 만든 CLAUDE.md 메모에 적어 뒀습니다. 지금은 따로 말하지 않아도 만들고 나서 확인까지 해 줍니다.

처음 알아두면 좋은 명령어

입력창에 /를 치면 쓸 수 있는 명령어 목록이 나옵니다. 처음에는 아래 몇 개만 알아도 충분합니다.

명령어 하는 일
/help 도움말과 쓸 수 있는 명령어 보기
/clear 대화를 비우고 새로 시작하기
/compact 지금까지 대화를 요약해서 정리하고, 같은 대화를 이어가기
/context 대화 공간이 얼마나 찼는지 보기
/model 사용할 모델 바꾸기
/btw 대화에 남기지 않고 잠깐 궁금한 것 물어보기

/clear와 /compact는 헷갈리기 쉬우니 조금 더 설명하겠습니다.

클로드가 한 대화에서 기억하며 볼 수 있는 분량에는 한계가 있습니다. 주고받은 말뿐 아니라 클로드가 읽은 파일, 실행한 명령의 결과까지 전부 이 공간을 차지합니다. 공간이 가득 차 갈수록 앞에서 한 말을 잊거나 실수가 늘어납니다.

/compact는 지금까지의 대화를 요약해서 공간을 비웁니다. 같은 일을 계속하고 있는데 대화가 길어졌을 때 씁니다. 공간이 차면 클로드 코드가 알아서 요약하기도 합니다.

/clear는 대화를 아예 새로 시작합니다. 하던 일과 관계없는 새 일을 맡길 때 씁니다. 비운 대화는 /resume으로 다시 열 수 있으니 부담 갖지 않아도 됩니다.

방향이 틀어졌을 때

클로드가 일하는 도중에 엉뚱한 방향으로 가는 게 보이면 끝날 때까지 기다리지 말고 바로 멈추세요. 터미널에서는 Esc를 누르면 멈춥니다. 멈춰도 그때까지의 대화는 남아 있어서 “그게 아니라 이렇게 해 줘”라고 이어서 말하면 됩니다.

이미 고친 결과가 마음에 안 들면 “방금 바꾼 거 되돌려 줘”라고 말해도 되고, 되돌리기 메뉴로 원하는 시점까지 돌아가도 됩니다. 터미널에서는 입력창이 빈 상태에서 Esc를 두 번 누르거나 /rewind를 입력하면 메뉴가 열리고, VS Code 확장에서는 돌아가고 싶은 메시지에 마우스를 올리면 나타나는 되돌리기 버튼을 누르면 됩니다.

다만 이 메뉴로도 안 되는 경우가 있습니다. 클로드가 명령을 실행해서 파일을 지우거나 옮긴 경우는 되돌려지지 않습니다. 이럴 때 쓰라고 3편에서 git으로 저장 지점을 남겨 뒀습니다. “아까 저장한 상태로 되돌려 줘”라고 하면 그 시점으로 돌아갑니다. 큰 일을 맡기기 전에 “지금 상태 저장해 줘”라고 한마디 해 두는 습관이 여기서 값을 합니다.

같은 문제를 두 번 넘게 고쳐 달라고 했는데도 계속 틀린다면, 거기서 더 고쳐 달라고 하기보다 새로 시작하는 게 낫습니다. 대화 안에 실패한 시도가 잔뜩 쌓여서 클로드가 오히려 헷갈리기 때문입니다. /clear로 대화를 비우고, 지금까지 해 보면서 알게 된 점을 담아 처음부터 더 구체적으로 부탁하세요. 공식 문서도 긴 대화에서 계속 고치는 것보다 깨끗한 대화에서 더 나은 부탁을 하는 쪽이 거의 항상 결과가 좋다고 말합니다.

저도 기능 하나를 고치느라 한 시간을 보낸 적이 있습니다. 고쳐 달라고 할수록 다른 곳이 어긋나서 결국 포기하고, git으로 저장해 둔 이전 상태로 되돌렸습니다. 그다음 기능을 처음부터 다시 설계하고, 한 번에 부탁하던 것을 작은 단계로 쪼개 하나씩 맡겼습니다. 한 시간을 붙잡고 있던 일이 그렇게 하니 금방 끝났습니다.

다음은 스킬과 플러그인

1편에서 클로드 코드가 무엇인지 보고, 2편에서 설치해 첫 요청을 보내고, 3편에서 매번 하던 말을 메모에 적어 뒀습니다. 이번 편에서는 일을 나눠 맡기고 결과를 확인받는 방법까지 봤습니다. 여기까지가 혼자 쓰는 데 필요한 기본입니다. 처음부터 전부 지키려고 애쓰지 않아도 됩니다. 결과가 마음에 안 들 때마다 이 글을 떠올려 부탁하는 방식을 하나씩 바꿔 보세요.

그런데 쓰다 보면 매번 같은 부탁을 반복하게 됩니다. “만들고 나서 확인까지 해 줘”, “고치기 전에 계획부터 보여 줘” 같은 말이 그렇습니다. 짧은 것은 3편처럼 메모에 적어 두면 되지만, 여러 단계로 이뤄진 작업은 메모 한 줄로는 감당이 안 됩니다.

5편에서는 그런 반복을 묶어 두는 스킬과 플러그인을 다룹니다. 둘이 어떻게 다른지, 어디서 찾아 설치하는지, 제가 실제로 써 본 것은 무엇이고 왜 설치했는지까지 정리했습니다.