1. 검토 다음은 갈림길

검토 메모가 손에 있으면 이제 고칠 차례입니다. 그런데 고치는 방법이 하나가 아닙니다. 3장 3절의 프로세스 그림에서 '간단한 수정인가?'라는 갈림길이 있었습니다. 이 절은 그 갈림길에서 어느 쪽으로 갈지, 그리고 각 길에서 어떻게 말할지를 다룹니다.

2. 이어서 고치기

문구, 색, 위치, 크기처럼 눈에 보이는 것은 하던 대화에서 이어서 요청합니다. 요령은 세 가지입니다.

2.1 한 번에 여러 개, 번호로

검토 메모의 '고칠 것'을 번호 붙여 한 번에 보냅니다. 하나씩 보내면 매번 Claude가 폴더를 다시 살펴보느라 시간과 사용량을 씁니다.

검토했어. 아래를 고쳐줘. 나머지는 그대로 둬.

1. 주문하기 버튼을 눌러도 아무 일도 안 일어나. 눌렀을 때 입력 내용이 구글 시트로 가야 해.
2. 폰 폭에서 가격표가 옆으로 잘려. 폰에서는 세로로 쌓이게 해줘.
3. 농장 전화번호를 064-123-4567로 바꿔줘.
4. '프리미엄 감귤 체험' 문구와 그 부분은 통째로 빼줘.

2.2 위치를 지목

"저거 좀 바꿔줘"는 통하지 않습니다. 6장에서 이야기한 것처럼 화면의 어디를 말하는지 Claude가 알 수 있어야 합니다. 문구가 있으면 문구를 그대로 인용하고, 없으면 "맨 위 사진 아래 첫 번째 제목"처럼 위치를 말합니다. 파일이 여러 개면 @파일명으로 지목합니다. 캡처를 찍어 첨부하고 동그라미를 쳐도 됩니다. 입력창의 + 버튼으로 이미지를 붙일 수 있습니다.

2.3 '나머지는 그대로'

수정을 요청하면 Claude가 시키지 않은 곳까지 손보는 경우가 있습니다. 색을 바꿔 달라고 했는데 배치가 바뀌어 있는 식입니다. "나머지는 그대로 둬"를 습관처럼 붙이세요. 검토 메모의 '괜찮은 것'을 여기에 씁니다. "사진 배치와 색은 그대로 두고"라고 말하면 됩니다.

3. 동작이 이상할 때는 상황을 그대로

버튼이 안 눌리고, 보냈는데 저장이 안 되고, 화면이 하얗게 뜨는 것처럼 동작의 문제는 원인을 여러분이 모릅니다. 원인을 추측하지 말고 상황을 그대로 말합니다.

주문하기 버튼을 누르면 '접수되었습니다'라고 뜨는데, 구글 시트에는 아무것도 안 들어가. 시트 주소는 https://docs.google.com/spreadsheets/d/xxxx 야. 브라우저는 크롬이고, 폰이 아니라 노트북에서 해봤어.

무엇을 했고, 무엇을 기대했고, 실제로 무엇이 일어났는지. 이 세 가지가 있으면 Claude가 원인을 찾습니다. 화면에 빨간 글씨나 경고창이 떴다면 그 문구를 그대로 복사해서 붙입니다. 8장에서 배운 개발자 도구의 콘솔(Console) 탭에 빨간 글씨가 있다면 그것도 복사해서 붙입니다. 이것이 7장에서 이야기한 '에러 메시지 대처'입니다.

여러 번 지시해도 해결이 안 된다면 단계별로 확인하게 시킵니다.

안 고쳐지네. 어디서 막히는지 단계별로 확인해줘. 버튼을 눌렀을 때, 입력 내용을 모았을 때, 시트로 보낼 때, 각 단계마다 화면에 무엇이 일어나는지 표시하는 임시 문구를 넣어서 내가 직접 확인할 수 있게 해줘.

4. 고쳐도 제자리일 때는 되돌리기

같은 것을 세 번 고쳐 달라고 했는데 제자리라면, 그 대화는 이미 꼬인 것입니다. 고친 것 위에 고친 것이 쌓여 Claude도 무엇이 원래 상태인지 모릅니다. 이때 두 가지 도구가 있습니다.

4.1 /rewind

3장 7절에서 배운 /rewind로 고치기 전 상태로 돌아갑니다. 되돌릴 지점 목록에서 '첫 결과물이 나온 직후'를 고르고, 코드만 되돌릴지 대화까지 되돌릴지 선택합니다. 대화까지 되돌리면 Claude는 그 사이의 실패를 기억하지 못합니다. 코드만 되돌리면 기억은 남습니다. 같은 실수를 반복할 것 같으면 대화까지, 실패에서 배운 것을 살리고 싶으면 코드만 되돌립니다.

되돌린 다음에는 요청을 다르게 합니다. 같은 말을 다시 하면 같은 결과가 나옵니다. 위 3절처럼 상황을 더 자세히 말하거나, 아래 5절처럼 브리프를 다시 씁니다.

4.2 처음부터 다시 만들기

앞선 책은 '리팩토링도 시간이 얼마 걸리지 않게 되는 시대, 처음부터 개발하는 시대가 열릴 수 있다'고 썼습니다. 그 시대가 왔습니다. 랜딩 페이지 하나는 몇 분이면 다시 나옵니다. 세 번 고쳐서 안 되는 것을 네 번째 고치는 것보다, 배운 것을 브리프에 반영해 새로 만드는 것이 빠릅니다.

5. 방향이 다르면 새 대화에서 브리프 다시 쓰기

검토했더니 구조가 통째로 다르거나, 고칠 것이 열 개가 넘거나, 만들어 보니 내가 원한 것이 이게 아니었다는 것을 알게 되었다면 새로 시작합니다. /clear로 대화를 비우고 브리프를 다시 씁니다. 이때 폴더 안의 기존 파일을 지울지 물어보세요. 대개는 "폴더의 기존 파일은 old 폴더로 옮기고 새로 만들어줘"가 안전합니다.

다시 쓰는 브리프에는 배운 것이 들어갑니다. 첫 브리프와 두 번째 브리프의 차이를 보세요.

(첫 브리프의 화면 구성 일부)
- 그 아래 감귤 종류와 가격 3종류

(두 번째 브리프의 같은 자리)
- 그 아래 감귤 종류와 가격 3종류. 종류마다 사진 하나, 이름, 무게, 가격 순서로. 폰에서는 세로로 쌓이게. 가격은 폴더의 가격.xlsx에 있는 숫자만 쓰고 '프리미엄', '체험' 같은 문구는 넣지 마

한 줄이 세 줄이 되었습니다. 만들어 보고 검토했기 때문에 쓸 수 있는 세 줄입니다. 만들기 전에는 이 세 줄을 쓸 수 없었습니다. 이것이 이 책이 명세서를 앞에 두지 않는 이유입니다. 검토를 한 번 거친 브리프는 어떤 명세서 템플릿보다 정확합니다.

6. 직접 고치기

문구 하나, 숫자 하나는 메모장으로 여는 것이 빠릅니다. 3장 6절에서 해봤습니다. 8장을 읽었다면 어느 파일의 어디를 고쳐야 하는지 감이 잡힐 것입니다. 다만 두 가지는 지키세요.

1. 고치기 전에 파일을 복사해 둡니다. 이름 뒤에 _backup을 붙이면 됩니다.
2. 고친 뒤 Claude에게 알려줍니다. "index.html의 전화번호를 내가 직접 바꿨어." 그래야 다음 작업 때 Claude가 덮어쓰지 않습니다.

7. 반복되는 실수는 하네스로

같은 종류의 문제가 두 프로젝트에서 연달아 걸리면, 그것은 그 프로젝트의 문제가 아니라 여러분의 작업 환경의 문제입니다. 4장에서 이야기한 하네스에 올릴 때입니다.

검토는 이번 결과물을 고치고, 하네스는 다음 결과물을 처음부터 낫게 만듭니다. 이 둘이 돌아가기 시작하면 프로젝트를 거듭할수록 첫 결과물의 품질이 올라갑니다. 부트캠프에서 세 번째 프로젝트부터 "이제 거의 한 번에 나와요"라는 말이 나오는 이유입니다.