AI가 버그를 계속 못 고친다면? 로그를 찍어보세요

바이브코딩을 하다 보면 AI에게 오류 메시지를 보여줘도 문제가 해결되지 않을 때가 있습니다.

저장 버튼을 누르면 아무 반응이 없어.
이런 오류도 같이 나타나. 고쳐줘.

AI가 코드를 수정합니다. 다시 버튼을 눌러봅니다. 여전히 작동하지 않아요.

AI에게 다시 알려주면 다른 코드를 수정하지만 이번에도 해결되지 않습니다. 몇 번 반복하다 보면 이런 생각이 들어요.

AI도 이 버그는 못 고치는 것 아닐까?

물론 AI가 잘못된 판단을 할 때도 있습니다. 하지만 실제로는 AI에게 문제가 아니라 결과만 보여준 경우가 많아요.

화면에 나타난 증상과 오류 메시지만으로 원인을 알 수 없다면 프로그램이 실행되는 과정을 더 자세히 확인해야 합니다.

이럴 때 AI에게 이렇게 요청해보세요.

원인을 추측해서 바로 수정하지 말고,
문제가 발생하는 과정을 확인할 수 있도록 로그를 추가해줘.

오류 메시지를 보여줬는데도 왜 못 고칠까요?

회원가입 버튼을 눌러도 가입되지 않는 문제가 생겼다고 해볼게요.

화면에는 다음 문구만 나타납니다.

회원가입에 실패했습니다.

이 문구만으로는 어느 단계에서 문제가 생겼는지 알기 어렵습니다.

버튼 클릭이 제대로 인식되지 않았을 수 있음
→ 입력한 이메일을 서버로 보내지 못했을 수 있음
→ 서버가 요청을 거절했을 수 있음
→ 회원 정보 저장에 실패했을 수 있음
→ 가입은 됐지만 다음 화면으로 이동하지 못했을 수 있음

겉으로 보이는 결과는 모두 “회원가입이 안 된다”로 같지만 원인은 서로 다릅니다.

AI도 코드를 읽고 가능한 원인을 추측할 수는 있어요. 하지만 실제로 버튼을 눌렀을 때 어떤 값이 전달됐고 프로그램이 어느 단계까지 실행됐는지는 코드를 읽는 것만으로 확인하기 어렵습니다.

정보가 부족하면 AI는 가능성이 높은 곳부터 추측해서 수정합니다. 첫 번째 추측이 틀리면 다른 부분을 다시 바꾸게 돼요.

로그는 프로그램이 남기는 실행 기록이에요

로그는 앱에서 어떤 일이 일어났는지 보여주는 기록입니다.

회원가입 과정에 로그를 추가하면 다음과 같은 내용을 확인할 수 있어요.

회원가입 버튼 클릭됨
→ 이메일 입력값 확인됨
→ 서버에 회원가입 요청을 보냄
→ 서버가 요청을 받음
→ 데이터베이스 저장 실패
→ 사용자에게 실패 안내를 보여줌

이 기록이 있으면 문제의 범위가 달라집니다.

처음에는 “회원가입 과정 어딘가에 문제가 있다”고만 알았습니다. 로그를 확인한 뒤에는 “서버까지 요청은 잘 전달됐고 데이터베이스에 저장하는 단계에서 실패했다”고 좁힐 수 있어요.

로그는 AI가 정답을 바로 알려주는 마법의 문장이 아닙니다. 대신 AI가 추측해야 할 범위를 줄여주는 단서예요.

서비스를 운영하면서 계속 남기는 로그가 왜 필요한지는 로그가 무엇이고 어디에 쓰이는지 설명한 글에서 더 자세히 확인할 수 있습니다. 이번 글에서는 개발 중인 버그를 찾기 위해 잠시 추가하는 로그를 중심으로 설명할게요.

로그는 어디에서 확인하나요?

웹사이트를 만들 때 로그는 주로 두 곳에 나타납니다.

브라우저 개발자 도구
→ 사용자가 보는 화면에서 생긴 일

개발 서버를 실행한 터미널
→ 서버에서 처리한 일

같은 웹사이트 안에서 일어난 일이라도 화면과 서버는 서로 다른 곳에서 실행될 수 있어요. 그래서 한쪽의 기록만 보고는 원인을 찾지 못할 때가 있습니다.

두 장소가 낯설어도 괜찮습니다. 로그의 내용을 직접 해석할 필요는 없어요. 어디에서 찾아 복사해야 하는지만 알면 AI에게 분석을 맡길 수 있습니다.

브라우저 로그는 개발자 도구의 Console에서 확인해요

브라우저 개발자 도구는 지금 보고 있는 웹페이지에서 무슨 일이 일어나는지 확인하는 도구입니다.

Chrome이나 Edge에서는 웹페이지의 빈 곳을 마우스 오른쪽 버튼으로 누른 뒤 검사를 선택하면 열 수 있어요.

단축키를 사용해도 됩니다.

Mac
→ Command + Option + I

Windows
→ Ctrl + Shift + I

개발자 도구가 열리면 위쪽에 있는 Console 탭을 선택하세요. 브라우저 화면에서 실행된 로그와 오류 메시지가 이곳에 나타납니다.

이제 문제가 발생했던 행동을 다시 해봅니다.

개발자 도구의 Console을 열어둠
→ 문제가 있던 버튼을 다시 누름
→ 새로 나타난 로그를 확인함
→ 해당 내용을 복사함

빨간색 메시지만 복사하지 말고 바로 전에 나타난 로그도 함께 복사하는 편이 좋아요. 오류가 발생하기 전까지 어떤 단계가 실행됐는지 확인하는 데 필요할 수 있습니다.

로그가 너무 많아 어떤 내용을 복사해야 할지 모르겠다면 AI에게 먼저 이렇게 요청할 수 있어요.

브라우저 Console에서 쉽게 찾을 수 있도록
추가하는 로그 앞에 [회원가입 디버깅]이라고 표시해줘.

그러면 다음처럼 관련된 로그를 구분하기 쉬워집니다.

[회원가입 디버깅] 버튼 클릭
[회원가입 디버깅] 입력값 확인
[회원가입 디버깅] 서버 요청 시작
[회원가입 디버깅] 요청 실패

개발자 도구에 나타나는 빨간색과 노란색 메시지가 무엇인지 모르겠다면 Warning과 Error를 구분하는 방법을 먼저 읽어보세요.

서버 로그는 개발 서버를 실행한 터미널에서 확인해요

터미널은 글자로 컴퓨터에 명령을 내리고 결과를 확인하는 창입니다.

바이브코딩을 하면서 다음과 비슷한 명령어로 웹사이트를 실행한 적이 있을 거예요.

npm run dev

이 명령어를 실행한 터미널이 개발 서버를 실행하고 있는 창입니다. 서버에서 회원가입 요청을 처리하거나 데이터베이스에 값을 저장할 때 남긴 로그도 보통 이 창에 나타나요.

터미널을 닫지 않은 상태에서 브라우저로 돌아가 문제가 발생한 행동을 다시 해보세요.

터미널에서 개발 서버가 실행 중임
→ 브라우저에서 회원가입 버튼을 다시 누름
→ 터미널에 새로운 로그가 나타남
→ 새로 나타난 부분을 복사함

터미널에는 웹사이트를 실행한 순간부터 여러 메시지가 쌓여 있을 수 있습니다. 모든 내용을 복사할 필요는 없어요. 문제가 발생한 행동을 하기 직전과 직후에 새로 나타난 내용을 복사하면 됩니다.

터미널 자체가 낯설다면 터미널이 무엇이고 어떻게 여는지 설명한 글을 참고하세요.

배포한 사이트의 서버 로그는 내 터미널에 나타나지 않아요

내 컴퓨터에서 실행한 사이트와 인터넷에 배포한 사이트는 서버 로그를 확인하는 위치가 다릅니다.

내 컴퓨터에서 npm run dev로 실행한 사이트
→ 개발 서버를 실행한 터미널에서 확인

Vercel에 배포한 실제 사이트
→ Vercel의 Logs에서 확인

배포한 사이트에서 문제가 발생했는데 내 컴퓨터의 터미널만 보고 있으면 아무 로그도 나타나지 않을 수 있어요. 요청이 내 컴퓨터가 아니라 Vercel의 서버에서 처리됐기 때문입니다.

어디에서 로그를 봐야 할지 모르겠다면 AI에게 물어보세요.

지금 문제는 Vercel에 배포한 사이트에서 발생하고 있어.

추가한 로그가 브라우저 Console에 나타나는지,
Vercel Logs에 나타나는지 구분해서 알려줘.
각 로그를 어디에서 확인하는지도 설명해줘.

AI가 브라우저 로그와 서버 로그의 위치를 나누어 알려줄 수 있습니다.

AI에게 로그를 추가해달라고 요청해보세요

버그가 발생했다고 무조건 많은 로그를 추가할 필요는 없습니다.

AI에게 현재 증상과 기대한 결과를 설명하고 원인을 구분하는 데 필요한 곳에만 로그를 추가하게 하세요.

문의 제출 버튼을 눌렀지만
화면에 완료 안내가 나타나지 않고
데이터베이스에도 문의가 저장되지 않아.

원래는 문의가 저장된 뒤
화면에 제출 완료 안내가 나타나야 해.

아직 원인을 추측해서 수정하지 말고,
어느 단계에서 문제가 생기는지 확인할 수 있도록
필요한 위치에 디버깅 로그를 추가해줘.

브라우저 Console에서 확인할 로그와
서버 터미널에서 확인할 로그를 구분해줘.

로그를 확인하는 방법과
문제를 다시 재현하는 순서도 알려줘.

비밀번호, 인증 토큰, API 키와 개인정보는
로그에 출력하지 마.

여기서 중요한 요청은 세 가지입니다.

바로 수정하지 말고 먼저 관찰하기
→ 잘못된 추측으로 코드를 계속 바꾸는 일을 줄임

로그가 나타나는 위치 알려주기
→ 브라우저와 서버 중 어디를 봐야 하는지 알 수 있음

민감한 정보는 출력하지 않기
→ 문제 해결에 필요하지 않은 정보가 노출되는 것을 막음

로그를 복사해서 다시 AI에게 보여주세요

AI가 로그를 추가했다고 작업이 끝난 것은 아닙니다.

로그는 실제로 문제가 발생했을 때 어떤 일이 일어나는지 확인하기 위한 장치예요. 같은 행동을 다시 해서 버그를 재현해야 합니다.

AI가 로그를 추가함
→ 사이트를 다시 실행하거나 새로고침함
→ 문제가 발생한 행동을 똑같이 반복함
→ 브라우저와 터미널의 로그를 복사함
→ AI에게 다시 전달함

로그를 전달할 때는 어느 장소에서 복사했는지 표시해주세요.

저장 버튼을 다시 눌러봤어.

원래는 저장 후 목록 화면으로 이동해야 하는데
현재는 같은 화면에 그대로 머물러 있어.

브라우저 Console 로그는 아래와 같아.

[브라우저 로그 붙여넣기]

개발 서버를 실행한 터미널 로그는 아래와 같아.

[서버 로그 붙여넣기]

이 기록을 바탕으로 문제가 생긴 단계를 찾아줘.
추측과 로그로 확인된 사실을 구분해서 설명하고,
원인이 확인되면 필요한 부분만 수정해줘.

이제 AI는 화면에 나타난 결과만 보고 추측하지 않아도 됩니다. 브라우저에서는 요청을 보냈지만 서버에는 도착하지 않았는지, 서버가 요청을 받았지만 데이터베이스 저장에 실패했는지 실제 기록을 따라가며 확인할 수 있어요.

로그에 민감한 정보를 남기지 마세요

문제를 자세히 확인하려고 모든 값을 출력하면 안 됩니다.

다음 정보는 브라우저나 서버 로그에 그대로 남기지 마세요.

• 비밀번호
• API 키와 비밀 키
• 로그인 인증 토큰
• 카드번호와 결제 정보
• 주민등록번호
• 문제 해결에 필요하지 않은 이메일, 전화번호와 주소

AI에게 로그를 추가해달라고 할 때 민감한 값을 가리도록 함께 요청하세요.

입력값이 전달됐는지는 확인하되
실제 비밀번호와 인증 토큰은 출력하지 마.

이메일처럼 확인이 필요한 개인정보는
전체 값을 출력하지 말고 일부를 가려줘.

로그를 AI에게 붙여넣기 전에도 민감한 값이 포함됐는지 한번 확인하는 것이 좋습니다. 발견했다면 해당 부분을 지우거나 ***로 바꾼 뒤 전달하세요.

문제를 고친 뒤에는 임시 로그를 정리하세요

버그를 찾기 위해 추가한 상세 로그를 계속 남겨둘 필요는 없습니다.

특히 버튼을 누를 때마다 많은 내용이 출력되는 로그는 중요한 오류를 찾기 어렵게 만들고 운영 중에는 불필요한 정보를 쌓을 수 있어요.

문제가 해결되면 AI에게 다음 작업까지 요청하세요.

같은 행동을 다시 테스트해서 문제가 해결됐는지 확인해줘.

원인을 찾기 위해 임시로 추가한 디버깅 로그는 제거하고,
운영 중에도 필요한 성공·실패 기록만 남겨줘.

민감한 정보가 로그에 포함되지 않는지도 다시 확인해줘.

모든 로그를 지우라는 뜻은 아닙니다.

원인을 찾기 위해 잠시 추가한 상세 로그
→ 문제 해결 후 정리

운영 중 오류를 발견하기 위해 필요한 로그
→ 민감한 정보를 제외하고 유지

어떤 로그를 남길지 모르겠다면 AI에게 각 로그의 목적을 설명하게 한 뒤 결정할 수 있어요.

AI가 못 고치는 것처럼 보이면 단서를 더 주세요

AI에게 오류 메시지를 보여주는 것은 좋은 시작입니다.

하지만 오류 메시지만으로 원인을 알 수 없는 문제도 있어요. 이때 같은 설명을 반복하거나 AI가 여러 곳을 계속 수정하게 하면 코드만 복잡해질 수 있습니다.

문제가 생긴 행동 설명
→ 기대한 결과와 실제 결과 설명
→ AI에게 디버깅 로그 추가 요청
→ 같은 문제 다시 재현
→ 브라우저와 서버 로그 복사
→ AI에게 로그 전달
→ 확인된 원인만 수정
→ 같은 행동으로 다시 검증
→ 임시 로그 정리

AI가 버그를 잘 고치려면 더 긴 프롬프트보다 실제로 무슨 일이 일어났는지 보여주는 정보가 필요할 때가 많습니다.

몇 번을 수정해도 같은 문제가 반복된다면 이렇게 요청해보세요.

이제 추측해서 수정하지 말고,
원인을 확인할 수 있도록 로그를 추가해줘.

AI가 프로그램 안에서 일어난 일을 볼 수 있게 해주면 막연했던 버그가 확인할 수 있는 문제로 바뀝니다.

에러 메시지, 브라우저 Console과 증상을 AI에게 전달하는 기본 흐름부터 연습하려면 바이브코딩 가이드 10장을 먼저 따라 해보세요.

수업에서 강사가 오류의 답부터 말하지 않고 로그와 실행 흐름을 먼저 묻는 이유도 같습니다. 뚝딱 강사가 수강생 질문에 바로 답하지 않는 이유에서 정답보다 문제를 좁히는 힘을 기르는 방식을 설명했습니다.

로그를 어디서 봐야 할지부터 모르거나 같은 에러가 반복된다면 혼자 프롬프트를 바꾸는 것보다 현재 화면을 함께 보는 편이 빠를 때가 있습니다. 뚝딱이 바이브코딩 강의를 오프라인으로 진행하는 이유도 수강생의 실제 프로젝트와 로그를 그 자리에서 함께 확인하기 위해서입니다.