원인 찾기(디버깅)
AI에게 고쳐 달라 해도 계속 헛돌 때 쓰는 법이에요. 증상이 아니라 원인을 좁혀요
쉽게 말하면
가게 전체 불이 나갔을 때 두꺼비집 앞에서 하는 일이에요. 차단기 앞에 서서 "불이 안 켜져요"라고 백 번 말해도 불은 안 켜져요. 사장님이 실제로 하는 건 스위치를 하나씩 내렸다 올리면서 어느 회선이 범인인지 좁히는 거예요. 냉장고 회선을 내렸더니 불이 들어오면, 그때부터 고칠 곳은 가게 전체가 아니라 냉장고 한 대예요. 원인 찾기가 정확히 이 일이에요. 고치는 건 그다음이고, 값이 나가는 건 범위를 반으로 줄이는 이 과정이에요.
AI에게 "안 돼요"만 던지면 AI도 두꺼비집 앞에 선 사람과 같아요. 짚이는 데를 골라 고치고, 고친 자리가 또 다른 곳을 건드려요.
그래서 순서가 정해져 있어요. 재현 절차 쓰기로 "반드시 나는 순서"를 먼저 확보하고, 그다음에 이 문서의 방법으로 범위를 좁혀요. 재현이 안 되는 증상은 아직 고칠 수 있는 상태가 아니에요.
답은 바로 와요. 대신 짚이는 데를 아무 데나 고쳐서 멀쩡하던 목록 화면이 같이 바뀌어요. 세 번 반복하면 원래 상태가 무엇이었는지도 몰라요.
적는 데 3분이 더 들어요. 대신 고칠 곳이 한 곳으로 정해져서, 멀쩡한 화면은 안 건드리고 한 번에 끝나는 일이 많아요.
AI가 헛도는 이유
AI는 사장님 화면을 못 봐요. 사장님이 적어 준 문장만 보고 원인을 짐작해요.
그래서 같은 부탁도 붙는 정보에 따라 완전히 다른 답이 나와요. 왼쪽은 실제로 많이 쓰는 말이고, 오른쪽은 그 말을 들은 AI가 하게 되는 일이에요.
| 내가 보낸 말 | AI가 실제로 하는 일 | 그래서 생기는 일 |
|---|---|---|
| "안 돼요. 고쳐 주세요" | 무엇이 안 되는지 모르니 가장 흔한 원인 하나를 골라 그 부분을 다시 써요 | 멀쩡하던 곳이 같이 바뀌어요. 두세 번 반복하면 처음 모습으로 못 돌아가요 |
| "저장이 안 돼요" | 버튼부터 자료가 들어가는 곳까지 전부를 의심 대상으로 잡아요 | 한 번에 여러 곳을 건드려서, 어느 수정이 효과가 있었는지 못 가려요 |
| "빨간 글씨가 떠요" | 글씨 내용을 모르니 흔한 오류 문구를 상상해서 대응해요 | 원인과 상관없는 수정이 들어와요. 에러 읽는 법대로 원문을 그대로 붙이면 이 칸이 사라져요 |
| "어제는 됐는데 오늘 안 돼요" | 그 사이에 무엇이 바뀌었는지 모르니 만든 것 전체를 훑어요 | 답이 길어지고 추측이 늘어요. 바뀐 것 하나를 알려 주면 범위가 그 한 줄로 줄어요 |
| "손님 화면에서만 안 된대요" | 사장님 화면을 기준으로 고쳐요 | 사장님 화면에서는 계속 멀쩡해서 고쳐졌다고 믿게 돼요 |
"고쳐 주세요"보다 "여기까지는 정상이에요"
AI에게 줄 수 있는 가장 값나가는 정보는 안 되는 것이 아니라 되는 것이에요. 되는 것을 적으면 그만큼이 의심 목록에서 통째로 빠져요. 한 줄이 절반을 잘라 내는 경우도 흔해요.
범위를 반으로 줄이는 다섯 걸음
다섯 걸음 중 코드를 읽어야 하는 건 하나도 없어요. 전부 사장님이 화면 앞에서 할 수 있는 일이에요.
- 1되는 것부터 적어요. "목록은 보여요. 상세 화면도 열려요. 저장 버튼을 누를 때만 멈춰요." 이 한 줄을 적는 순간 의심 범위가 이미 크게 줄어요.
- 2바로 앞에 바꾼 것을 떠올려요. 어제까지 됐다면 원인은 대개 그 사이에 바꾼 것 안에 있어요. 바꾼 것이 여럿이면 하나씩 되돌려 봐요.
- 3절반을 잠깐 비워 봐요. 한 화면이 이상하면 그 화면의 절반을 잠깐 빼고 열어 보세요. 증상이 사라지면 범인은 뺀 절반 안에, 그대로면 남은 절반 안에 있어요.
- 4짐작 대신 증거를 뽑아요. 화면에 실제로 뜬 문구, 눌렀을 때 아무 반응이 없는지 아니면 잠깐 도는지를 적어요. 개발자 도구를 열 수 있으면 빨간 줄을 그대로 복사해요.
- 5좁힌 범위를 통째로 넘겨요. "저장 버튼만 반응이 없고 화면에 이런 문구가 떠요. 목록과 상세는 정상이에요. 어제 바꾼 건 저장 화면 문구뿐이에요." 여기까지 오면 AI든 개발자든 한 번에 맞혀요.
한 번에 한 가지만 바꿔요
두 곳을 같이 고치고 증상이 사라지면 어느 쪽이 원인이었는지 영영 몰라요. 그러면 같은 일이 다음 달에 또 나요. 고칠 때도 되돌릴 때도 한 번에 하나예요. 그래야 이전 버전으로 돌리기도 깔끔해요.
세 칸으로 나눠서 보기
어디가 원인인지 감이 안 잡히면 네 칸으로 갈라 놓고 하나씩 지워요. 대부분의 증상은 이 넷 중 하나에 들어가요.
| 의심할 칸 | 여기가 원인일 때의 신호 | 사장님이 직접 확인하는 법 |
|---|---|---|
| 화면 | 눌러도 아무 반응이 없어요. 새로고침하면 입력이 사라져요 | 다른 브라우저나 다른 폰으로 같은 순서를 밟아 봐요. 거기서 되면 화면 쪽이에요 |
| 저장 | 저장됐다는 표시는 뜨는데 새로고침하면 없어요 | 관리자 목록에 그 줄이 실제로 생겼는지 봐요. 없으면 저장까지 못 간 거예요 |
| 바깥 창구 | 결제·문자·메일처럼 남의 서비스를 부르는 기능만 실패해요 | 그 회사의 장애 안내를 먼저 봐요. 저쪽이 멈춘 날이면 내 쪽에는 고칠 게 없어요 |
| 설정값 | 아무것도 안 고쳤는데 어제까지 되던 기능 하나만 오늘 안 돼요 | 키나 주소를 최근에 바꿨는지 확인해요. 환경 변수가 비면 그 기능만 조용히 죽어요 |
확인해 보세요
예약 저장이 안 된다는 문의를 받았어요. 목록과 상세 화면은 잘 열려요. 지금 가장 먼저 할 일은?
헷갈리기 쉬운 것
이 주제에서 시간을 가장 많이 잡아먹는 건 어려운 원인이 아니라 두 가지를 섞어 보는 것이에요. 네 쌍만 갈라 두면 돼요.
| 섞이기 쉬운 두 가지 | 무엇이 다른가 | 어느 쪽인지 가르는 질문 |
|---|---|---|
| 재현과 원인 찾기 | 재현은 반드시 나게 만드는 순서를 확보하는 일이고, 원인 찾기는 그 순서 안에서 범위를 좁히는 일이에요 | "열 번 하면 열 번 나나요" |
| 고장과 아직 없는 기능 | 고장은 만든 대로 안 움직이는 것이고, 없는 기능은 애초에 만든 적이 없는 것이에요 | "전에는 이게 됐었나요" |
| 진짜 고장과 예전 화면 | 고친 것이 반영되기 전 화면이 그대로 남아 있는 경우가 있어요 | "새 창이나 다른 기기에서도 똑같나요" |
| 만드는 화면과 손님 화면 | 만드는 중인 화면과 손님이 보는 화면은 설정값도 들어 있는 자료도 달라요 | "손님이 쓰는 주소로 들어가서도 똑같나요" |
세 번째 줄이 사람을 가장 자주 헛돌게 해요. 분명히 고쳤는데 그대로면 원인을 더 파기 전에 캐시부터 의심해요. 새 창에서 정상으로 보이면 고친 건 이미 맞은 거예요.
- Q. 코드를 못 읽는데 원인 찾기를 할 수 있나요?
- 할 수 있어요. 위 다섯 걸음은 전부 화면 앞에서 하는 일이에요. 되는 것과 안 되는 것을 가르고, 바뀐 것을 떠올리고, 화면에 뜬 문구를 그대로 옮기는 것이에요. 코드를 읽는 건 그 뒤 사람의 몫이에요.
- Q. AI에게 몇 번까지 다시 시켜 보면 되나요?
- 같은 부탁으로 두 번 실패하면 멈추는 게 좋아요. 세 번째부터는 새 정보 없이 추측만 반복돼서, 고쳐지기보다 범위가 넓어져요. 멈추고 되는 것부터 다시 적어 보세요.
- Q. 빨간 글씨는 안 뜨는데 그냥 안 돼요. 이럴 땐 어떻게 하나요?
- 조용한 실패도 정보예요. 눌렀을 때 잠깐이라도 도는지, 아니면 아무 일도 안 일어나는지 갈라 보세요. 아무 일도 없으면 버튼과 화면 쪽이고, 잠깐 돌다 멈추면 저장이나 바깥 창구 쪽일 때가 많아요.
- Q. 가끔만 안 되는 건 어떻게 좁히나요?
- 가끔이라는 말을 조건으로 바꾸는 게 먼저예요. 특정 시간대인지, 특정 기기인지, 특정 손님의 자료에서만인지 세 가지를 적어 보세요. 조건이 하나라도 잡히면 그때부터 재현 절차를 쓸 수 있어요.
- Q. 고쳐 달라고 하면 왜 멀쩡한 곳까지 바뀌나요?
- 범위를 안 줬기 때문이에요. 어디까지가 정상인지 알려 주지 않으면 전부가 수정 대상이 돼요. "목록과 상세는 정상이니 건드리지 말아 주세요"라는 한 줄이 이걸 막아요.
- Q. 끝까지 혼자 못 찾겠으면요?
- 좁힌 데까지만 정리해서 넘겨도 값이 있어요. 되는 것, 안 되는 것, 어제 바꾼 것 세 줄이면 외주 맡기기에서 받는 견적의 근거가 되고, 확인에 드는 시간도 줄어요.
실제로 겪는 장면
장면 1 · 외주 개발자가 말했다
“제 컴퓨터에선 잘 됩니다.”
이 말은 발뺌이 아니라 정보예요. 두 환경 중 한쪽에서만 난다는 뜻이니까요. 여기서 물을 건 하나예요. "손님이 쓰는 주소에서도 확인해 보셨나요." 만드는 컴퓨터와 실제 서비스는 설정값도 자료도 달라서, 이 한 문장으로 원인 후보가 절반으로 줄어요.
장면 2 · 같은 부탁을 세 번째 보낸 뒤
“이번엔 저장은 되는데 목록이 안 떠요.”
이건 진전이 아니라 범위가 넓어졌다는 신호예요. 원인을 모른 채 고치면 고칠 때마다 새 증상이 붙어요. 여기서 할 일은 네 번째 부탁이 아니라 되돌리기예요. 마지막으로 멀쩡했던 판으로 돌아간 다음, 다섯 걸음을 처음부터 밟아요.
고친 뒤에는 원래 순서를 다시 밟아요
증상이 사라졌다고 끝난 게 아니에요. 재현 순서를 그대로 다시 밟아 확인하고, 그 옆의 기능 한두 개도 눌러 봐요. 한 곳을 고치면 다른 곳이 같이 움직이는 일이 흔해요. 손으로 확인할 목록이 있으면 이 확인이 5분이면 끝나요.
하나 더
AI에게 같은 부탁을 두 번 보냈는데 둘 다 실패했고, 이번엔 다른 화면까지 이상해졌어요. 지금 할 일은?
직접 해보기
두 줄로 적어서 보내 보세요
첫 줄은 되는 것, 둘째 줄은 안 되는 것과 어제 바꾼 것이에요. 지금 만들고 있는 것이 있으면 스튜디오 채팅에 이 두 줄을 그대로 적어 보세요. "고쳐 주세요" 한 줄만 보냈을 때와 답이 얼마나 달라지는지 바로 보여요.
스튜디오에서 두 줄로 보내기더 깊이 (안 읽어도 괜찮아요)
왜 절반씩 지우는 방법이 가장 빠른가 · 후보가 백 개일 때 하나씩 확인하면 최악에 백 번이지만, 절반씩 잘라 내면 일곱 번이면 끝나요. 코드를 몰라도 이 방법은 그대로 써요. 화면 요소를 절반 가리기, 기능을 절반 끄기, 어제 바꾼 것 중 절반만 되돌리기가 전부 같은 원리예요. 중요한 건 자를 때마다 증상이 나는지 안 나는지 한 번씩 확인하는 거예요. 확인 없이 두 번 자르면 얻은 정보가 사라져요.
증상은 원인에서 멀리 떨어져 나타나요 · 목록이 비어 보인다고 목록 쪽이 범인인 경우는 오히려 드물어요. 저장이 실패해 자료가 안 들어갔거나, 화면이 부르는 주소가 바뀌었거나, 바깥 창구가 답을 안 줬을 수 있어요. 그래서 "증상이 보이는 곳"과 "원인이 있는 곳"을 처음부터 다른 칸에 적어 두면 헛수고가 줄어요. 비유의 한계도 여기예요. 두꺼비집은 회선이 눈에 보이게 나뉘어 있지만, 만든 것 안에서는 그 경계를 사장님이 직접 그어야 해요.
찾은 원인은 세 줄로 남겨요 · 고치고 바로 닫지 말고 세 줄만 적어요. 무엇이 안 됐는지, 원인이 무엇이었는지, 무엇을 바꿔서 해결됐는지. 같은 증상은 몇 달 뒤에 또 와요. 그때 이 세 줄이 몇 시간을 아껴 줘요. 어디에 남길지 자리를 정해 두는 것까지가 원인 찾기의 마지막 걸음이에요.
이것만 기억하세요
- ·고치기 전에 좁혀요. 범위를 안 준 부탁은 멀쩡한 곳까지 흔들어요
- ·되는 것부터 적어요. 그 한 줄이 의심 범위를 통째로 잘라 내요
- ·한 번에 한 가지만 바꿔요. 두 곳을 같이 고치면 원인을 영영 몰라요
- ·같은 부탁으로 두 번 실패하면 멈추고, 마지막으로 멀쩡했던 판으로 돌아가요
- ·찾은 원인은 세 줄로 남겨요. 같은 증상은 몇 달 뒤에 또 와요