“어제까지 되던 도구가 오늘은 왜 안 되죠?”
이 질문을 검색창에 넣고 싶어지는 순간이 옵니다. 버튼을 눌렀는데 아무 반응이 없고, 계산 결과는 이상하며, 파일을 정리해 달라고 했더니 예상하지 못한 이름이 생깁니다. 클로드가 긴 설명을 내놓아도 지금 무엇을 해야 하는지는 더 흐려질 수 있어요.
막힘은 도구를 만들어 쓰는 과정의 일부입니다. 진짜 문제는 오류가 생겼다는 사실이 아니라 화면 도구와 파일 작업을 같은 속도로 다루는 데 있어요.
작은 화면 도구는 대체로 되돌리기 쉽습니다. 입력값을 다시 넣거나 이전 상태로 돌아가면 돼요. 반면 파일 작업은 한 번의 재시도가 같은 파일을 다시 옮기거나, 이름을 덮어쓰거나, 이미 바뀐 상태 위에 또 변경을 쌓을 수 있습니다.
그래서 복구 경로를 둘로 나눕니다.
| 상황 | 복구 순서 |
|---|---|
| 화면 도구 | 한 번 재시도 → 보이는 증상 전달 → 직전 상태로 되돌리기 |
| 파일 작업 | 즉시 멈춤 → 증상 전달 → 변경 범위 확인 → 사본에서 복구 → 다시 검증 |
두 경로를 외울 필요는 없어요. 질문 하나만 기억하면 됩니다.
지금 다시 눌러도 원본과 기록이 더 바뀌지 않는가.
그렇다면 화면 도구 경로를 쓸 수 있습니다. 확신이 없다면 파일 작업 경로로 갑니다.
화면 도구에서는 증상을 작게 만든다
6장 가계부에서 본 두 증상을 다시 꺼내 볼게요. 합계가 숫자로 더해지지 않고 긴 문자열처럼 이어졌고, 같은 예시를 두 번 불러오자 16행이 32행이 됐습니다. 화면은 열렸고 표도 보였어요. 겉모양만 보면 완성처럼 보였지만 합계와 행 수는 틀렸습니다.
이때 “다시 잘 만들어 줘”라고만 보내면 클로드는 무엇이 잘못됐는지 추측해야 합니다. 화면 색을 바꾸거나 표 구조를 다시 만들 수도 있어요. 필요한 건 도구 전체의 재설계가 아니라 두 증상의 수정이었습니다.
증상 전달은 길지 않아도 됩니다.
“현재 수입과 지출 합계가 숫자로 더해지지 않고 금액이 이어 붙은 문자열처럼 표시됩니다. 예시 데이터는 16행이어야 하는데 같은 불러오기를 두 번 누르면 32행으로 중복됩니다. 디자인과 항목 구조는 바꾸지 말고, 금액을 숫자로 계산하고 예시 데이터가 한 번만 들어가도록 수정해 주세요. 수정 뒤 수입 3,385,000원, 지출 1,620,700원, 잔액 1,764,300원, 16행인지 확인해 주세요.”
이 요청문에는 네 가지가 들어 있습니다.
- 지금 보이는 증상.
- 기대하는 결과.
- 바꾸지 말아야 할 범위.
- 수정 뒤 확인할 숫자.
에러 코드가 없어도 괜찮아요. 비개발자가 전달해야 하는 것은 원인의 이름이 아니라 화면에서 확인한 차이입니다. “합계가 이상하다”보다 “수입 3,385,000원이 나와야 하는데 숫자가 이어 붙는다”가 고칠 재료가 됩니다.
수정 뒤에는 같은 행동을 반복합니다. 예시를 한 번 넣고 행 수를 봅니다. 다시 눌러도 행 수가 늘지 않는지 확인해요. 금액 하나를 바꿔 합계가 다시 계산되는지도 봅니다.
그 과정에서 다른 영역이 바뀌면 직전 상태로 돌아갑니다. 화면 도구는 대화 안에서 이전 버전을 다시 요청하거나, 보관해 둔 파일을 다시 열어 복구할 수 있어요.
막히는 순간 — 수정할수록 화면이 더 달라져요
증상. 합계 오류만 고치려 했는데 색상, 항목 이름, 버튼 위치까지 달라졌습니다.
원인. 수정 범위를 좁히지 않아 전체 구조를 다시 만든 것입니다.
복구. 직전 정상판으로 되돌리고 바꿀 증상과 유지할 영역을 함께 적어 다시 요청합니다.
“직전 버전으로 돌아가 주세요. 이번 수정 범위는 금액 계산과 예시 중복 방지뿐입니다. 항목 이름, 화면 구성, 색상, 내보내기 기능은 바꾸지 마세요. 수정 뒤 합계 세 개와 행 수만 보고해 주세요.”
화면 도구에서 한 번의 재시도는 허용할 수 있습니다. 같은 입력을 다시 넣어 일시적인 반응 문제인지 보는 정도예요. 같은 오류가 이어지면 더 누르지 말고 증상을 붙여넣습니다. 반복 클릭은 원인을 찾는 행동이 아니라 상태를 더 복잡하게 만드는 행동이 될 수 있어요.
파일 작업에서는 재시도보다 멈춤이 먼저다
앞 절에서 한 번의 재시도를 허용한 것은 화면 도구였기 때문입니다. 파일 작업에서는 그 한 번이 다릅니다. 실행을 다시 누르면 한 파일이 다른 파일을 덮어쓰거나, 임의의 번호가 붙어 어느 파일이 최신인지 더 알기 어려워질 수 있어요. 이미 옮겨진 파일 위에 같은 이동이 한 번 더 쌓이기도 합니다.
그래서 파일 작업의 첫 행동은 재시도가 아니라 멈춤입니다.
멈춘 다음 볼 것은 화면이 멎었다는 사실이 아니에요. 어떤 파일이 어느 위치로 가려 했는지, 같은 목적지가 생겼는지, 이미 움직인 파일이 있는지입니다.
“실행을 멈춰 주세요. 아직 파일을 이동하거나 덮어쓰지 마세요. 지금까지 옮겨진 파일과 남은 파일을 나누어 보여 주고, 같은 목적지 이름이 생긴 항목이 있으면 따로 표시해 주세요. 원본 폴더는 변경하지 말고 변경 대상은 작업용 사본으로 제한해 주세요.”
계획을 고친 뒤에도 곧바로 전체에서 실행하지 않습니다. 파일 두세 개만 들어 있는 샘플 사본에서 새 규칙을 먼저 시험해요. 다음 장에서 실제로 이 순서를 밟습니다. 이름을 단순하게 만들려던 규칙이 서로 다른 두 파일을 같은 이름으로 보내 버리는 장면을, 열 개 전체가 아니라 샘플 두 개에서 미리 만나게 될 거예요.
파일 작업의 성공 판정에는 숫자가 필요합니다. 정리 전, 정리 후, 원본, 복원본의 개수가 모두 같아야 해요. 숫자가 하나라도 다르면 정리 성공이라고 쓰지 않습니다.
셀 때는 무엇을 셌는지도 함께 적습니다. “파일 수가 같다”는 문장만으로는 부족해요. 최상위만 센 결과인지, 하위 폴더까지 포함한 결과인지에 따라 같은 폴더가 전혀 다른 숫자로 보입니다.
멈춤은 소극적인 행동이 아닙니다. 현재 상태를 보존하는 기술이에요. 파일 작업에서는 실패 원인을 알기 전에 상태가 더 바뀌는 일을 막는 것이 우선입니다.
오류 메시지를 모두 이해할 필요는 없다
긴 오류 문장이 나오면 전체를 공부하려고 하기 쉽습니다. 그럴 필요는 없어요. 복구에 필요한 부분은 네 조각입니다.
보이는 증상. 버튼을 눌러도 반응이 없는지, 합계가 틀리는지, 파일 이름이 겹치는지 적습니다.
기대 결과. 몇 행, 얼마, 몇 파일이어야 하는지 씁니다.
직전에 한 행동. 어떤 파일을 넣었고 무엇을 눌렀으며 어떤 수정 요청을 보냈는지 남깁니다.
보호할 범위. 원본 폴더, 기존 데이터, 정상인 화면처럼 건드리면 안 되는 곳을 지정합니다.
오류 문구가 있다면 그대로 붙이면 됩니다. 해석해서 다시 쓰다가 중요한 단어를 빼지 마세요. 화면 캡처를 쓸 때는 고객 이름, 이메일, 계정 정보 같은 민감한 부분을 가리고 전달합니다.
“왜 안 되나요?”는 대화를 시작하는 질문일 수 있습니다. 복구를 끝내는 질문은 아닙니다. 숫자와 범위를 붙여야 행동으로 바뀝니다.
“안 돼요”를 재현 가능한 문장으로 바꾼다
같은 오류도 표현에 따라 복구 속도가 달라집니다. “저장이 안 돼요”라고만 쓰면 저장 버튼이 반응하지 않는지, 저장했다고 표시되지만 다시 열면 사라지는지, 내보낸 파일이 비어 있는지 알 수 없어요.
보이는 순서대로 적으면 됩니다.
“항목을 한 줄 추가한 뒤 화면에는 17행이 보입니다. 페이지를 닫았다가 같은 위치에서 다시 열면 16행으로 돌아갑니다. CSV로 내보낸 파일에도 새 항목이 없습니다. 새 항목이 화면에만 임시로 보이는지 확인하고, 기존 16행과 합계 계산은 바꾸지 않은 채 저장 또는 내보내기 경로를 수정해 주세요.”
여기에는 원인 추정이 없습니다. 관찰한 행동만 있어요. 클로드가 “저장 방식의 문제”라고 설명하더라도 복구 뒤에는 같은 순서로 다시 시험합니다. 한 줄 추가, 닫기, 다시 열기, 내보내기, 행 수 확인입니다.
파일 작업도 마찬가지예요. “파일이 없어졌어요”보다 다음 문장이 낫습니다.
“작업 전 사본에는 파일이 24개 있었고, 지금 세어 보니 21개입니다. 하위 폴더를 포함한 전체 목록과 이동 내역을 보여 주세요. 원본 폴더는 24개 그대로인지 별도로 보고하고, 현재 상태에서 추가 이동이나 삭제는 하지 마세요.”
좋은 증상 문장은 전문 용어가 많은 문장이 아닙니다. 다른 사람이 같은 입력과 행동으로 차이를 확인할 수 있는 문장이에요.
되돌리기는 마지막 수단이 아니라 기본 단계다
도구를 만들 때는 수정판만 남기기 쉽습니다. 괜찮아 보이는 버전에 덮어쓰고, 문제가 생기면 대화 기록을 뒤져요. 복구가 어려운 이유는 오류가 복잡해서가 아니라 정상 상태가 어디였는지 남아 있지 않기 때문입니다.
보관 이름은 거창할 필요가 없습니다.
가계부_합계수정전.html파일정리_작업전사본회의보고서_원문기준_v1.md
정상판을 하나 남기고 수정합니다. 파일 작업이라면 작업 전 사본과 변경 목록을 함께 둡니다. 화면 도구라면 재생성 요청문과 기대값을 남겨요.
되돌린 뒤에는 같은 검증을 다시 합니다. 이전 화면이 보인다는 이유로 끝내지 않습니다. 행 수, 합계, 파일 수, 누락을 확인해야 정상 상태로 돌아온 것이 맞는지 알 수 있어요.
두 트랙을 고르는 짧은 판단표
| 질문 | 그렇다면 |
|---|---|
| 다시 실행해도 원본과 기록이 바뀌지 않는가 | 화면 도구 경로를 검토한다 |
| 파일 이동·이름 변경·삭제가 포함되는가 | 즉시 멈추고 파일 작업 경로로 간다 |
| 직전 정상판이 남아 있는가 | 그 상태를 기준으로 수정 범위를 좁힌다 |
| 기대값을 숫자로 말할 수 있는가 | 요청문에 숫자를 넣는다 |
| 무엇이 바뀌었는지 모르는가 | 추가 실행 전 변경 목록을 요청한다 |
도구가 아티팩트인지 코워크인지 클로드 코드인지보다 중요한 판단입니다. 같은 공간에서도 화면만 바꾸는 일과 로컬 파일을 다루는 일은 복구 위험이 다를 수 있어요.
애매하면 파일 작업 경로를 고른다
화면 안에서 시작한 도구라도 내려받은 CSV를 덮어쓰거나 로컬 폴더의 파일을 바꾸는 순간 위험이 달라집니다. “아티팩트에서 시작했으니 화면 도구 경로”처럼 서비스 이름으로 고르지 마세요. 지금 실행이 무엇을 바꾸는지로 판단합니다.
예를 들어 가계부 화면의 합계 표시만 고치는 일은 되돌리기 쉬운 편입니다. 같은 가계부가 내보낸 월별 CSV 12개를 합치고 기존 파일 이름을 바꾸는 일이라면 파일 작업 경로가 맞아요. 실행을 멈추고 대상 파일 목록, 새 파일 위치, 원본 보존 여부를 확인해야 합니다.
판단이 서지 않으면 더 보수적인 경로를 택합니다. 한 번 더 누르는 데 드는 몇 초보다 원본 상태를 되찾는 시간이 훨씬 클 수 있어요. 사본을 만들고 변경 범위를 확인한 뒤 실행하면 느려 보이지만, 복구까지 포함한 전체 시간은 오히려 짧아집니다.
복구 기록 한 장을 남긴다
막힘을 해결한 뒤 대화를 닫아버리면 다음 오류에서 다시 처음부터 설명해야 합니다. 아래 다섯 줄을 텍스트 파일에 남겨 두세요.
- 증상은 무엇이었는가.
- 기대값은 무엇이었는가.
- 원인은 확인됐는가, 추정인가.
- 어떤 요청으로 복구했는가.
- 재검증에서 무엇을 확인했는가.
이 기록은 개발 문서가 아닙니다. 다음번의 자신에게 남기는 복구 메모예요. 같은 도구를 고칠 때 재생성 요청문보다 더 빠르게 상황을 설명해 줍니다.
지금 쓰고 있는 도구 하나를 골라 복구메모.md를 만들어 보세요. 실제 오류가 없다면 “합계가 맞지 않을 때”나 “파일 수가 달라질 때”를 가정해 기대값과 보호할 범위만 적어도 됩니다.
막힘을 없애는 사람은 없습니다. 대신 막혔을 때 상태를 더 망치지 않고, 증상을 전달하고, 직전 정상판으로 돌아가는 사람이 있어요.
그 능력이 있으면 도구를 다시 만들지 않고 계속 고쳐 쓸 수 있습니다.
