AI가 버그를 못 찾은 게 아니라, 내가 질문을 잘못한 거였다 — AI 코딩 시대의 프롬프트 디버깅

TECH ESSAY · AI 코딩

AI가 버그를 못 찾은 게 아니라,
내가 질문을 잘못한 거였다

AI 코딩 시대의 프롬프트 디버깅 — 의존성 누락 버그와 질문 설계의 관계

📋 목차

1. 01잘 돌던 코드가 갑자기 멈췄다
2. 02AI는 왜 이걸 못 찾았을까
3. 03질문을 다르게 했다면 어땠을까
4. 04AI 코딩도 결국 질문 실력이다
5. 05바이브코딩에도 짬이 쌓인다
6. 06개발자는 여전히 코드를 읽어야 한다

요즘 업무 코딩에서 AI 도구를 꽤 자주 사용하고 있다. Antigravity에서 Claude Sonnet과 Gemini 3.1 Pro를 번갈아 쓰면서 오류를 수정하고, 기존 코드를 다듬는 식이다. 확실히 개발 속도는 빨라졌다. 그런데 오늘은 조금 묘한 경험을 했다. AI와 함께 코딩하고 있었는데, 결국 문제를 해결한 건 예전 방식의 디버깅이었다. 그리고 나중에 생각해보니, AI가 못 찾은 문제라기보다 내가 AI에게 질문을 잘못 던졌던 것일 수도 있겠다는 생각이 들었다.

01

잘 돌던 코드가 갑자기 멈췄다

문제가 생긴 건 파일 업로드 관련 기능이었다. 웹 화면에서 드래그앤드롭으로 파일을 업로드하면 AJAX로 서버에 파일 정보를 넘기고, 서버에서는 전달받은 파일명을 카테고리별로 넘버링해서 정리하는 로직이 있었다. 원래는 잘 동작하던 기능이었다. 그런데 어느 순간부터 화면에 명확한 에러도 없이 기능이 중간 어딘가에서 멈춘 것처럼 보였다.

처음에는 당연히 AI에게 물어봤다. "이 프로그램이 동작하지 않는데 에러 의심 지점을 찾아줘." AI는 여러 가능성을 제시했다. AJAX 요청 문제, 파라미터 누락, 파일 처리 로직 오류, 응답값 처리 방식 문제. 그럴듯했다. 그래서 제안한 의심 지점을 하나씩 수정해봤지만 결과는 같았다.

🔍 원인 발견

DB 조회 코드는 추가됐는데, DB 연결을 위한 공통 라이브러리 include가 빠져 있었다. 원래 이 파일은 DB를 쓰지 않았기 때문에 공통 라이브러리를 불러오지 않았다. 요구사항이 바뀌면서 DB 조회 코드가 들어갔지만, 전제 조건이 갱신되지 않은 것이다.

몇 번을 수정해도 해결되지 않자 결국 예전 방식으로 돌아갔다. 한 줄씩 디버깅하며 어디까지 실행되고, 어디서 멈추는지 확인했다. 그러다 딱 눈에 걸리는 지점이 보였다. 찾고 나면 너무 당연한 문제였지만, 찾기 전까지는 계속 엉뚱한 곳을 의심하게 만드는 종류의 버그였다.

02

AI는 왜 이걸 못 찾았을까

처음에는 이런 생각이 들었다. "바이브코딩이 아무리 코드베이스를 읽고 수정한다고 해도, 이런 건 못 찾는구나." 반대로 나는 한 줄씩 실행 흐름을 따라가다가 문제를 찾아냈다. 오래간만에 예전 방식으로 분석해서 오류를 찾으니 기분이 묘했다.

그런데 조금 더 생각해보니, 이게 꼭 AI의 한계만은 아닐 수도 있겠다는 생각이 들었다. 이번 문제의 본질은 단순한 에러가 아니었다. 문제는 이 프로그램이 정상 동작하기 위해 필요한 의존성이 빠진 것이었다.

📌 의존성 누락의 구조

• → DB 조회 코드가 추가되면 → DB 연결이 필요하다
• → DB 연결을 하려면 → 공통 라이브러리 include가 필요하다
• → 이 파일은 원래 DB를 쓰지 않던 파일 → 공통 라이브러리 없음
• ⇒ 기능 변경으로 실행 전제가 바뀌었지만, 파일 구조는 업데이트되지 않음

나는 AI에게 "에러를 찾아달라"고 했다. 그러면 AI는 자연스럽게 코드 안에서 에러가 날 만한 부분, 즉 AJAX 요청 문제나 SQL 문법 오류 같은 것을 우선적으로 보게 된다. 하지만 이번 문제는 코드 한 줄의 오류가 아니라 기능 변경으로 인해 바뀐 실행 전제에 있었다. AI가 못 찾은 게 아니라, 내가 AI에게 엉뚱한 렌즈를 쥐여준 셈이었다.

03

질문을 다르게 했다면 어땠을까

만약 처음부터 AI에게 이렇게 물었다면 어땠을까. 아래가 내가 던진 질문과 던졌어야 할 질문의 차이다.

❌ 내가 던진 질문

이 프로그램이 동작하지 않는데 에러 의심 지점을 찾아줘.

✅ 던졌어야 할 질문

이 AJAX 스크립트가 정상 동작하기 위해 필요한
의존성이나 초기화 코드가 빠진 것이 없는지 확인해줘.

특히 최근에 DB 조회 로직이 추가되었는데,
그에 따라 필요한 include, DB connection,
공통 라이브러리 호출이 누락되지 않았는지 봐줘.

핵심은 관점의 차이다. 첫 번째 질문은 AI에게 "에러"를 찾게 한다. 두 번째 질문은 AI에게 "실행 전제 조건의 변화"를 검토하게 한다. 같은 코드를 보더라도 어떤 렌즈로 보느냐에 따라 AI의 답변은 완전히 달라진다.

04

AI 코딩도 결국 질문 실력이다

같은 문제라도 질문 방식에 따라 AI의 답변은 달라진다. 프롬프트 작성 능력도 이제 개발자의 역량 중 하나가 되어가고 있다. 아래 세 가지 질문을 비교해보자.

🎯 프롬프트 품질 비교

LEVEL 1 · 입문

"이거 왜 안 돼?"

LEVEL 2 · 중급

"이 코드에서 에러 의심 지점을 찾아줘."

LEVEL 3 · 고급

"최근 기능 변경으로 새로 추가된 로직이 기존 파일 구조와 충돌하는 부분이 있는지 봐줘. 특히 문법 오류 말고 구조적 전제 조건이 깨진 부분을 중심으로."

질문이 구체적일수록 AI가 보는 시야도 달라진다. 단순히 코드 한 줄의 오류를 찾는 것이 아니라, 실행 흐름·의존성·초기화 코드·기존 구조와 새 요구사항의 충돌까지 보게 만들 수 있다. 이 일을 겪고 나니 프롬프트 작성 능력도 개발 능력의 일부라는 생각이 든다.

05

바이브코딩에도 짬이 쌓인다

개발도 결국 짬에서 나오는 부분이 있다. 비슷한 장애를 몇 번 겪어보면, 로그를 보기 전부터 먼저 의심하는 지점이 생긴다. "이건 DB 연결이나 공통 include 쪽 냄새가 나는데?" 이런 감은 책으로만 배우기 어렵다. 직접 겪어보고, 삽질해보고, 고쳐보면서 몸에 쌓이는 부분이 있다.

📈 프롬프트 숙련도의 변화

초기

"고쳐줘."

중기

"원인 후보를 우선순위별로 정리해줘."

숙련

"이 파일이 독립 실행되는지, 아니면 공통 초기화 파일을 전제로 하는지 확인해줘. 최근 변경사항 기준으로 기존 실행 흐름과 달라진 의존성을 추적해줘."

결국 프롬프트도 경험이 쌓일수록 좋아진다. 개발자가 장애를 겪으면서 디버깅 감각을 키우듯이, 바이브코딩을 계속하다 보면 AI에게 일을 시키는 감각도 같이 쌓이는 것 같다.

06

개발자는 여전히 코드를 읽어야 한다

그렇다고 해서 오늘의 결론이 "프롬프트만 잘 쓰면 된다"는 것은 아니다. 이번에도 마지막에 문제를 찾은 건 한 줄씩 실행 흐름을 따라가던 과정이었다. AI가 코드를 잘 써준다고 해서 개발자가 코드를 읽지 않아도 되는 것은 아니다. 오히려 AI가 만들어낸 코드, AI가 수정한 코드일수록 개발자가 실행 흐름을 더 잘 읽어야 한다.

🧠 개발자가 여전히 봐야 할 것들

• →이 코드가 왜 여기에 있는지
• →이 파일은 원래 어떤 역할을 하던 파일인지
• →이번 수정으로 어떤 의존성이 새로 생겼는지
• →기존 구조와 새 요구사항 사이에서 빠진 연결고리는 없는지

AI는 코드 안에서 의심스러운 부분을 잘 찾는다. 하지만 개발자는 코드 밖의 맥락까지 봐야 한다. AI 코딩 시대의 개발자는 두 가지를 모두 갖춰야 하는 것 같다. 코드를 읽고 실행 흐름을 따라가는 능력, 그리고 AI에게 문제를 정확히 설명하고 적절한 관점으로 보게 만드는 능력.

💡 오늘의 인사이트

AI가 답을 못 찾았을 때, 그게 항상 AI의 한계라고만 볼 수는 없다.

• ·내가 질문을 너무 좁게 했을 수도 있다
• ·AI에게 필요한 관점을 충분히 주지 못했을 수도 있다
• ·문제를 "에러"로만 보게 만들고, "의존성"이나 "실행 전제"의 문제로 보게 하지 못했을 수도 있다

코딩 실력도 짬에서 나오듯이, 프롬프트 작성 능력도 계속 써보면서 쌓이는 감각이다.

C

CoLife

20년 차 현직 개발자 · Code & Life 운영

실무에서 직접 부딪히며 얻은 경험을 솔직하게 씁니다. AI 코딩 도구를 매일 쓰면서 느끼는 것들을 기록하는 중입니다.

이런 경험 있으신가요? 💬

AI가 버그를 못 찾았던 경험, 혹은 프롬프트 한 줄 바꿨더니 확 달라진 경험 있으시면
댓글로 공유해 주세요. 저도 계속 배우는 중입니다.

👇 댓글로 경험 나누기