바이브코딩 하다 보면, 분명 시킨 대로 했는데 AI가 “어 그거 못 찾겠는데요?” 할 때가 있어요. 저는 오늘 이거 때문에 30분을 날렸는데, 알고 보니 범인이 완전 엉뚱한 데 있었습니다. 같은 함정에 빠지지 마시라고 공유해요.
무슨 일이 있었냐면
스크립트 파일 한 곳을 고치려고 AI에게 “이 부분을 이렇게 바꿔줘”라고 했어요. 평소처럼 잘 될 줄 알았죠. 그런데 빨간 글씨로 이게 떴습니다:
String to replace not found in file.
해석하면 “바꾸라고 한 그 코드를, 파일에서 못 찾겠어요” 라는 뜻이에요. 저는 황당했죠. 분명히 그 코드가 거기 있는데? 눈으로도 보이는데 왜 못 찾는다는 거야…
초보의 함정: “안 되면 똑같은 걸 다시 시킨다”
솔직히 처음엔 그냥 다시 시켰어요. “아니 거기 있다니까? 다시 해봐.” 그런데 똑같은 빨간 글씨. 두 번째도 안 됨.
여기서 하나 배웠어요. 안 될 때 같은 명령을 또 치는 건, 틀린 풀이를 그대로 다시 쓰는 거랑 같더라고요. 답이 바뀔 리가 없죠. “왜 안 되지?”로 질문 자체를 바꿔야 했어요.
범인은 ‘내가 서 있는 위치’였다
차근차근 따져봤어요. “파일에 코드가 있는데 못 찾는다 → 그럼 혹시, AI가 보고 있는 파일이 내가 생각하는 그 파일이 아닌 거 아냐?“
확인해보니 정답이었어요. 저는 Git에서 브랜치(branch) 를 여러 개 오가며 작업하고 있었는데, 엉뚱한 사본에서 파일을 고치려 했던 겁니다. 제가 고치려던 코드는 다른 브랜치에만 있었고요.
브랜치를 바꾸면 파일이 실제로 바뀝니다
이게 제가 몰랐던 핵심이에요. 초보 때 제일 헷갈리는 부분이라 짚고 갈게요.
브랜치(branch): 같은 프로젝트의 ‘작업 사본’. 원본을 건드리지 않고 따로 실험할 수 있게 갈라놓은 갈래입니다.
애초에 왜 이런 걸 쓰냐면, 잘 돌아가는 코드를 망치지 않고 새 걸 시도하기 위해서예요. 새 기능을 만들다 보면 중간에 앱이 안 켜지는 상태를 거치잖아요. 그걸 원본에서 하면 그동안 아무것도 못 씁니다. 그래서 갈래를 하나 따서 거기서 마음껏 부수고, 다 되면 원본에 합치는 거죠. 시험지에 바로 쓰지 않고 연습장에서 풀어보는 것과 같습니다. 문제는 연습장이 여러 장이 되면 내가 지금 어느 장을 보고 있는지 헷갈린다는 거고요.
저는 브랜치를 “작업 목록을 나눠놓은 폴더” 쯤으로 생각했어요. 그래서 브랜치를 바꿔도 파일은 그대로 있고 이름표만 바뀌는 줄 알았죠. 아니었습니다. 브랜치를 옮기면 Git이 폴더 안의 파일 내용을 그 브랜치 상태로 실제로 갈아끼웁니다. 같은 이름, 같은 경로의 파일인데 열어보면 내용이 다른 거예요.
그래서 “분명 그 코드를 봤는데”가 착각이 아니었습니다. 진짜로 봤어요. 다른 브랜치에 있을 때 봤던 거죠. 그 뒤에 브랜치를 옮겼고, 그 순간 파일 내용이 조용히 바뀐 겁니다. 아무 알림도 없이요. 제 머릿속 기억은 30분 전 화면에 멈춰 있는데 디스크의 파일은 이미 딴 게 돼 있었던 셈입니다.
AI도 억울할 게 없었어요. AI는 지금 이 순간 디스크에 있는 파일을 읽습니다. 제 기억이나 30분 전 화면은 볼 수 없죠. 그러니 “못 찾겠다”는 게 정확한 보고였습니다. AI는 정직했고, 틀린 건 저였어요.
돌이켜보면 이 에러가 뜬 게 다행이었습니다. 만약 AI가 “비슷한 코드를 찾아서 알아서 고쳐드렸어요”라고 했다면, 엉뚱한 브랜치에 잘못된 수정이 들어간 걸 한참 뒤에나 발견했을 테니까요. 못 찾겠으면 아무것도 안 하고 멈추는 게, 어설프게 짐작해서 손대는 것보다 훨씬 안전합니다.
해결: 작업 전에 “나 지금 어디?”
해결은 허무할 만큼 간단했어요. 작업 전에 내가 어느 브랜치에 있는지부터 확인하는 것. 초보 때 이 git 명령 몇 개만 알아도 이런 삽질이 확 줍니다:
git branch --show-current # 지금 내가 있는 브랜치 이름 (← 오늘의 범인 잡은 한 줄)
git branch # 내 브랜치 목록 전체 보기 (현재 위치엔 * 표시)
git switch 브랜치이름 # 그 브랜치로 이동 (예전 방식: git checkout 브랜치이름)
git switch -c 새브랜치 # 새 브랜치 만들면서 바로 이동
저는 --show-current로 위치를 확인하고, git switch로 맞는 브랜치로 옮긴 다음 고치니 바로 됐습니다. 30분 헤맨 게 민망할 정도로요. (참고로 switch는 비교적 최근에 생긴 명령이고, checkout은 옛날부터 쓰던 명령이에요. 둘 다 이동은 되니, 검색하다 둘 다 보여도 당황 마세요.)
네 줄이지만 실제로 자주 쓰는 건 맨 윗줄 하나입니다. 나머지는 “어디로 갈지” 정할 때 쓰는 거고, --show-current는 뭔가 이상할 때마다 반사적으로 치는 용도예요. 3초 걸리는데 30분을 아껴줍니다.
오늘 배운 것
- 빨간 에러는 거짓말을 안 해요. “못 찾겠다”면 진짜 그 자리에 없는 겁니다. 의심할 건 에러가 아니라 내 가정이에요.
- 안 되면 반복 말고 질문을 바꾸기. “왜 안 되지?”로 한 발 물러서면 보입니다.
- 뭔가 하기 전에 “나 지금 어디 있지?” 한 번 확인하기. 브랜치든 폴더든, 위치 착각이 의외로 범인일 때가 많아요.
세 줄을 관통하는 건 하나예요. 제가 틀린 게 아니라 제 ‘가정’이 틀렸다는 것. 코드가 거기 있다는 것도, AI가 헛소리한다는 것도 다 검증 안 된 가정이었죠. 그리고 가정은 원래 눈에 안 보입니다. 너무 당연해서 의심할 생각조차 안 드니까요. 30분을 날린 것도 코드를 잘못 짜서가 아니라 “확인할 필요도 없다고 믿은 것” 때문이었어요.
그래서 저는 이제 뭔가 이상하면 코드를 들여다보기 전에 위치부터 봅니다. 30분짜리 수업료로 산 습관치고는 싸게 건진 편이죠. 막히면 git branch --show-current 한 번, 잊지 마세요. 😉