바이브코딩 에러 고치기, AI에 다 못 맡기는 이유

Part 7에서 배운 대로 소개 페이지에 외부 기능을 붙이다 보면, 어느 순간 빨간 에러 글씨를 만나요. 영어로 길게요. (정확히 어디에 뜨는지는 잠시 뒤에 나와요.)

처음엔 가슴이 철렁해요. “내가 뭘 망쳤나” 싶죠. 아니에요. 에러는 고장이 아니라 쪽지예요. 프로그램이 “나 여기서 막혔어요”라고 남긴 메모거든요.

진짜 중요한 건 따로 있어요. AI가 코드를 통째로 짜주는 시대에도, 에러를 읽고 AI가 자신 있게 틀리는 걸 알아채는 감만큼은 외주가 안 돼요. 코드는 맡겨도 이 감각은 직접 쌓아야 하죠. 실무에서 주니어 면접을 보면서도 느껴요. 에러를 안 내는 사람이 아니라, 에러 앞에서 안 얼어붙고 AI 답을 의심할 줄 아는 사람이 결국 더 빨리 늘어요. 그래서 이 편은 복붙으로 고치는 법과 그 감을 쌓는 법을 같이 다뤄요.

이 편에서 얻는 것:

• 에러를 겁내지 않고 읽는 마음가짐
• 복붙만으로 에러를 푸는 3단계
• AI가 자신 있게 틀리는 ‘환각’을 가려내는 법

에러 = 막힌 자리에 붙은 쪽지

에러 메시지를 무서워하는 이유는 하나예요. 영어고, 길고, 처음 보는 단어라서요.

그런데 에러는 사실 친절한 쪽지예요. 프로그램이 일하다 막히면, 그냥 멈추지 않고 “몇 번째 줄에서, 무엇 때문에 막혔다”를 적어 남겨요. 그 쪽지를 읽을 사람이 고치라고요.

그러니 빨간 글씨가 떠도 당장 다 이해할 필요 없어요. 우리가 할 일은 그 쪽지를 읽을 사람에게 넘기는 것이고, 지금 그 사람은 AI예요. 에러는 막혔다는 신호일 뿐, 고치는 길까지 적힌 쪽지거든요.

이렇게 에러를 읽고 고쳐 나가는 일을 디버깅이라고 해요. 제목에 있는 그 단어죠. 거창해 보여도, 결국 쪽지를 읽고 푸는 게 전부예요.

그 빨간 글씨는 ‘콘솔’에 떠요

한 가지 짚을 게 있어요. 정적 웹페이지에서 코드가 막히면, 빨간 글씨가 화면에 대문짝만하게 뜨진 않아요. 대신 브라우저가 몰래 적어두는 메모장, 콘솔(Console)에 떠요. 크롬·엣지 기준으로 여는 법은 이래요.

• 페이지에서 F12를 누르거나, 마우스 오른쪽 → 검사(Inspect).
• 맥은 F12가 볼륨키와 겹쳐 안 먹을 수 있어요. 그땐 ⌥+⌘+I로 열고, 오른쪽 클릭은 두 손가락 탭이나 Ctrl+클릭으로 해요.
• 위쪽 탭에서 Console을 골라요.
• 빨간 줄이 있으면 그게 쪽지예요. 그 줄 위에서 마우스 오른쪽 → Copy, 또는 드래그해서 Ctrl+C(맥은 Cmd+C)로 통째로 복사해요.
• 사파리는 한 번만 설정하면 돼요. 설정 → 고급에서 ‘웹 개발자용 기능 보기’를 켠 다음, 상단 ‘개발’ 메뉴 → ‘자바스크립트 콘솔 표시’(⌥+⌘+C)를 누르면 열려요.

“화면은 멀쩡한데 버튼이 안 먹네?” 싶을 때, 대개 여기에 빨간 줄이 하나 남아 있어요.

에러 푸는 3단계

복잡하게 갈 것 없어요. 막혔을 때 이 순서로만 움직이면 돼요.

3단계에서 쓸 프롬프트 (복붙용)

[무엇을 하려다] 이런 에러가 났어.

(여기에 에러 메시지 전체를 붙여넣기)

이게 무슨 뜻이고 어디를 어떻게 고쳐야 하는지,
초보자도 따라 할 수 있게 알려줘.

여기서 한 가지만 더요. AI가 “이렇게 고치면 돼요” 하고 코드를 주면, 그대로 붙이기 전에 무엇을 왜 바꾸는지 한 줄 설명을 같이 달라고 해보세요. 그래야 다음에 비슷한 게 나도 덜 막혀요. 지난 편들에서 익힌 ‘쪼개서 시키기’가 여기서도 그대로 통해요.

실제로 이렇게 풀려요

말로만 보면 감이 안 오죠. 흔한 예가 하나 있어요. Part 6에서 Supabase를 붙이다 콘솔에 이런 빨간 줄을 만났다고 해봐요.

Uncaught ReferenceError: supabase is not defined
    at index.html:24

3단계대로, “무엇을 하려다”를 한 줄 붙여 그대로 넘겨요.

Supabase 목록을 붙이는 중에 이 에러가 났어.
Uncaught ReferenceError: supabase is not defined (at index.html:24)
무슨 뜻이고 어디를 어떻게 고쳐야 하는지 초보자도 따라 할 수 있게 알려줘.

그러면 AI가 대개 이렇게 짚어줘요. “supabase를 쓰는 코드보다 위에, 라이브러리를 불러오는 <script src="...supabase-js..."> 줄이 빠졌거나 순서가 아래예요. 그 줄을 위로 올리세요.” 시키는 대로 한 줄 옮기고 저장한 뒤 새로고침하면, 빨간 줄이 사라지고 목록이 떠요.

포인트는 에러 내용을 내가 이해하는 게 아니에요. 어디서 났는지(줄 번호)를 통째로 넘기고, 화면이 되는지로 확인하는 거예요.

AI도 자신 있게 틀려요, 이게 ‘환각’이에요

에러보다 더 헷갈리는 게 있어요. 에러도 안 떴는데 결과가 이상한 경우예요.

AI는 가끔 자신 있게 틀려요. 없는 기능을 있는 것처럼 지어내거나, 그럴듯한데 실제론 안 되는 코드를 척척 내놓기도 해요. 실제로 없는 함수나 라이브러리 이름을 진짜처럼 지어내 끼워 넣는 식이죠. 이걸 흔히 환각이라고 불러요. 말투가 워낙 확신에 차 있어서, 처음엔 곧이곧대로 믿기 쉬워요.

가려내는 법은 의외로 단순해요. 코드를 읽어서 맞는지 따지는 게 아니에요. 그건 우리가 할 수 있는 일이 아니거든요. 기준은 딱 하나, 내 화면이에요.

• 화면으로 확인해요. “된다”는 AI 말이 아니라, 내 화면에서 실제로 내가 원한 대로 움직이는지가 기준이에요. 버튼을 눌러 보고 원하는 게 나오면 맞는 거고, 안 나오면 틀린 거예요. 코드가 맞는지는 안 봐도 돼요.
• 한 번에 하나씩만 시켜요. 열 줄을 한꺼번에 받으면 뭔가 이상해도 어디서 어긋났는지 못 찾아요. 조금 시키고 화면에서 확인하고, 또 조금 시키고. 이렇게 가면 문제가 생겨도 방금 바꾼 자리라 금방 잡혀요.
• 이상하면 화면을 그대로 되물어요. “이 코드 맞아?”라고 물어서 AI가 또 “맞아요” 하면, 우리는 그 말을 판단할 길이 없어요. 대신 눈에 보이는 걸 말해요. “버튼을 눌러도 목록에 안 생겨. 이게 되게 고쳐줘.” 코드가 아니라 화면을 근거로 되던지는 거예요.

그리고 안전망을 하나 둬요. 큰 걸 바꾸기 전에 돌아갈 자리를 만들어 두는 거예요.

• 쓰는 도구에 ‘되돌리기’나 체크포인트가 있으면 그게 제일 편해요.
• 없거나 불안하면 지금 잘 되는 파일을 통째로 복사해 따로 둬요. 크게 손봤다가 망가져도 복사본으로 돌아오면 그만이에요.
• 개발자들은 잘 되던 지점을 찍어두고 되돌리는 걸 *git(버전 관리)*이라는 도구로 해요. 지금은 파일 복사로 충분하고, git은 나중에 필요해질 때 배우면 돼요.

돌아갈 자리가 있는 것만으로 마음이 한결 가벼워져요.

AI가 도와주는 거지, 다 해주는 건 아니에요

바이브코딩은 만능이 아니에요. AI는 거드는 쪽이지, 모든 걸 한 번에 확실하게 해결해 주는 도구는 아니에요. 에러도 대개는 풀어주지만, 가끔은 앞에서 본 환각처럼 자신 있게 엉뚱한 길로 끌고 가요.

친구들을 보면 여기서 갈려요. 에러가 잘 안 풀리면 자꾸 “그냥 되게 해줘”로 넘어가요. 그러면 화면은 당장 도는데, 원인은 안 풀린 채 덮여요. 그게 나중에 더 큰 에러로 돌아오고요.

그래서 같은 도구를 써도 결과가 달라져요. 차이는 타이핑 속도가 아니라 감이에요. 이 에러가 뭔지, 지금 방향이 맞는지 겪어본 사람은 어렴풋이 알아요. 그래서 AI가 헛다리를 짚으면 “어, 이건 아닌데” 하고 멈추죠. 그 감이 아직 없으면 AI를 따라 더 깊이 들어갔다 길을 잃기도 쉽고요.

겁줄 얘긴 아니에요. 좋은 소식은 그 감이 타고나는 게 아니라 쌓이는 거란 점이에요. 에러를 직접 만나고 한 번씩 고쳐본 횟수가 그대로 감이 되거든요. 그러니 막혔다고 AI에 통째로 떠넘기지만 말고, “왜 이게 났을까”를 가끔 같이 들여다보세요. 그 한 번이 다음 막힘을 줄여줘요.

자주 만나는 에러, 크게 이런 것들

처음엔 다 똑같이 무서워 보여도, 자주 나오는 건 몇 가지로 추려져요. 외울 필요는 없어요. “아, 이 부류구나” 정도만요.

어떤 부류든 대응은 같아요. 에러를 통째로 복사해 AI에게 맥락과 함께 넘기는 것. 부류를 외우는 것보다, 이 흐름이 손에 붙는 것이 훨씬 중요해요.

막히면

자주 묻는 질문

레스덕의 정리

솔직히 저도 현직에서 하루의 꽤 많은 시간을 에러랑 씨름하며 보내요. 코드를 잘 짜는 사람은 에러를 안 만드는 사람이 아니라, 에러를 빨리 읽고 푸는 사람에 가까워요.

Claude Code로 1년 넘게 일하면서 제 디버깅 습관도 바뀌었어요. 예전엔 혼자 한참 들여다봤다면, 지금은 에러를 통째로 던지고 같이 좁혀가요. 그래도 변하지 않은 게 하나 있어요. 당황하지 않는 것이에요.

에러는 실패가 아니라 과정이에요. 빨간 글씨를 만나도 “아, 쪽지 왔네” 하고 넘기는 마음. 디버깅은 거기서 갈려요.

에러는 넘겼으니 미뤄둔 숙제 차례예요. Part 9에서 키가 안 새게, 비용이 안 터지게 지키는 보안을 다뤄요.