지난 편에서 큰 요청을 작은 작업으로 나누는 법을 정리했다면, 이번에는 그다음에 꼭 부딪히는 문제를 다뤄볼 차례입니다. 작업은 잘 나눴는데도 AI가 자꾸 엉뚱한 파일을 고치거나, 이미 있는 기능을 다시 만들거나, 정작 지금 막힌 부분이 아닌 다른 설명을 길게 내놓는 경우가 있습니다.

이럴 때 많은 사람은 “모델이 별로인가?”부터 떠올립니다. 하지만 실제로는 현재 상태를 충분히 넘기지 않았기 때문인 경우가 많습니다. “안 돼요”, “에러 나요”, “버튼이 안 먹어요” 같은 말만으로는 AI가 판단해야 할 가지가 너무 많습니다. 겉으로는 같은 증상처럼 보여도, 원인은 완전히 다를 수 있기 때문입니다.

이번 편에서는 그 빈칸을 어떻게 줄일지 정리해보겠습니다. 핵심은 복잡한 말을 길게 늘어놓는 게 아닙니다. 지금 어디까지 만들었는지, 어느 파일이 관련 있는지, 에러가 정확히 무엇인지, 화면에서 어떤 순서로 문제가 보이는지를 AI가 따라갈 수 있게 넘기는 것입니다. 이 흐름이 잡히면 답변의 초점이 훨씬 또렷해집니다.

이번 글에서 먼저 잡아둘 핵심
내가 보는 증상 AI에게 꼭 줘야 할 정보 빠졌을 때 생기기 쉬운 일
버튼을 눌러도 반응이 없다 관련 파일, 이벤트 연결 코드, 콘솔 에러 유무, 최근에 바꾼 부분 원인과 상관없는 설명이 길어지거나, 전체 구조를 다시 짜는 답이 나오기 쉽다
콘솔에 에러가 뜬다 에러 원문, 파일명과 줄 번호, 언제 뜨는지, 직전에 수정한 내용 AI가 넓게 추정만 하다가, 실제 원인보다 멀어진 답을 내놓을 수 있다
화면은 보이는데 동작이 이상하다 재현 순서, 현재 필터·검색·수정 상태, 기대한 결과와 실제 결과 겉모습만 보고 답하다가, 상태가 꼬인 지점을 놓치기 쉽다

이번 글의 핵심 한 줄
AI가 자꾸 빗나가게 답하는 이유는 질문을 못해서가 아니라, 지금 내 코드와 화면이 어떤 상태인지 충분히 전달되지 않았기 때문인 경우가 많습니다.

왜 현재 상태 전달이 중요한가

코딩에서 겉으로 같은 문제처럼 보여도, 실제 원인은 완전히 다를 때가 많습니다. 예를 들어 삭제 버튼이 안 눌린다고 해봅시다. 버튼 선택자가 잘못됐을 수도 있고, 이벤트가 연결되지 않았을 수도 있고, 화면을 다시 그리는 과정에서 버튼이 새로 만들어지면서 연결이 끊겼을 수도 있습니다. 혹은 아예 비활성 상태가 걸려 있는 것일 수도 있습니다.

초보자 입장에서는 이게 다 비슷하게 보입니다. 그냥 “삭제 버튼이 안 돼요”처럼 느껴집니다. 그런데 AI는 그 안에서 가능한 원인을 여러 갈래로 떠올립니다. 이때 현재 상태가 비어 있으면 답변도 넓어집니다. 그러면 원인과 상관없는 설명이 길어지고, 읽는 사람은 더 헷갈리게 됩니다.

  • 어디까지 구현됐는지 모르면 이미 있는 기능을 또 설명하기 쉽습니다.
  • 어느 파일이 관련 있는지 모르면 전체 프로젝트를 다시 짜는 답이 나오기 쉽습니다.
  • 에러가 있는지 없는지 모르면 추정이 지나치게 넓어집니다.
  • 어떤 순서로 문제가 보이는지 모르면 화면 상태 문제를 놓치기 쉽습니다.

결국 AI에게 현재 상태를 잘 넘긴다는 것은, AI가 똑똑해지게 만드는 마법이 아닙니다. 지금 이 문제를 어느 범위에서 봐야 하는지 좁혀주는 일에 가깝습니다. 그리고 초보자에게는 이 차이가 생각보다 큽니다. 질문을 조금만 정리해도, 답변이 읽을 만한 크기로 내려오기 시작하기 때문입니다.

오해하기 쉬운 지점
코드를 많이 붙인다고 해서 항상 좋은 것은 아닙니다. 중요한 건 많이 주는 것이 아니라, 문제와 연결된 순서대로 주는 것입니다.

이번 편에서는 어디까지 다룰 것인가

이번 편에서는 “막혔을 때 AI에게 현재 상태를 어떻게 넘길 것인가”에 집중하겠습니다. 범위를 넓히면 오히려 핵심이 흐려지기 쉬워서, 이번에도 다룰 것과 다루지 않을 것을 먼저 잘라두는 편이 좋습니다.

이번 글에서 다룰 것은 아래 네 가지입니다.

  • 관련 코드와 파일을 어떻게 골라서 보여줄지
  • 에러 메시지를 어떤 방식으로 전달하면 좋은지
  • 화면 문제를 어떻게 재현 순서로 설명할지
  • 이걸 한 번에 정리해서 요청하는 기본 템플릿

반대로 이번 글에서는 아래 내용은 깊게 들어가지 않겠습니다.

  • 서버 로그를 보는 방법
  • 배포 환경에서만 생기는 문제
  • 복잡한 라이브러리 버전 충돌
  • 네트워크 탭이나 고급 디버깅 도구 사용법

지금 단계에서 중요한 것은 도구를 더 많이 배우는 일이 아닙니다. AI가 내 문제를 덜 오해하게 만드는 최소한의 전달 구조를 익히는 쪽이 먼저입니다. 그 감각이 잡히면, 나중에 더 복잡한 문제를 다룰 때도 훨씬 덜 흔들립니다.

코드 맥락: 어느 파일의 무엇이 문제인지 먼저 좁히기

코드 문제를 AI에게 물을 때 가장 먼저 해야 할 일은, 지금 어디까지 만들어졌는지와 어느 부분이 이번 질문의 범위인지를 분리해서 보여주는 것입니다. 많은 초보자가 바로 코드부터 붙여넣는데, 사실 그 전에 짧게라도 현재 작업 범위를 말해주는 편이 훨씬 도움이 됩니다.

1. 어디까지 구현됐는지 먼저 알려주기

예를 들어 할 일 앱이라면 “추가, 삭제, 완료 체크, 필터까지는 정상 동작한다. 오늘은 검색 기능을 붙이는 중이다” 정도만 적어도 좋습니다. 이 한 줄이 있으면 AI는 이미 완성된 기능을 또 설명할 가능성이 줄어듭니다.

2. 관련 파일과 함수부터 좁히기

모든 파일을 한꺼번에 붙이기보다, 이번 문제와 직접 연결된 파일을 먼저 적어두는 편이 좋습니다. index.html, style.css, script.js처럼 파일 이름을 밝히고, 그 안에서 어떤 함수나 어떤 요소가 관련 있는지 같이 적어주면 훨씬 선명해집니다.

3. 최근에 바꾼 부분을 같이 적기

문제는 대개 방금 손댄 곳 주변에서 생기는 경우가 많습니다. 물론 항상 그런 것은 아니지만, 초보자 기준으로는 이 정보가 꽤 중요합니다. “오늘 searchInput과 clearSearchButton을 추가했다” 같은 문장은 생각보다 많은 힌트를 줍니다.

4. 기대한 결과와 실제 결과를 분리해서 쓰기

“검색이 안 돼요”보다 “입력값에 맞는 항목만 보여야 하는데 전체 목록이 그대로 보인다”가 훨씬 좋습니다. AI는 기대한 결과와 실제 결과의 차이를 봐야, 어떤 흐름이 빠졌는지 더 잘 좁혀갈 수 있습니다.

핵심 포인트
코드를 적게 주라는 뜻이 아닙니다. 관련 없는 코드까지 한꺼번에 섞지 말고, 문제와 연결된 파일과 흐름부터 먼저 보여주라는 뜻입니다.

예를 들어 검색 기능을 붙이는 중이라면, 아래 정도로 정리해서 넘기는 편이 좋습니다.

[현재 작업]

HTML, CSS, JavaScript로 할 일 앱을 만드는 중

추가, 완료, 삭제, 필터까지는 정상 동작

오늘 검색 입력창과 검색 지우기 버튼을 추가함

[현재 문제]

검색어를 입력해도 목록이 줄어들지 않음

콘솔 에러는 없음

[관련 파일]

index.html: #searchInput, #clearSearchButton 추가

script.js: elements 객체, bindSearchEvents, handleSearchInput, getFilteredTodos

[관련 코드]
function handleSearchInput() {
currentSearchQuery = normalizeText(elements.searchInput.value);
renderTodos();
}

function bindSearchEvents() {
elements.searchInput.addEventListener("input", handleSearchInput);
}

[기대한 결과]

입력 중인 검색어에 맞는 항목만 바로 보여야 함

[실제 결과]

어떤 검색어를 입력해도 전체 목록이 그대로 보임

[원하는 답변]

가장 가능성 큰 원인 3개

확인 순서

필요한 수정 코드만 제안

이 정도만 정리해도 AI는 “검색 기능 전반을 처음부터 설명할까?”가 아니라, “이 흐름에서 무엇이 빠졌을까?” 쪽으로 답을 좁히기 시작합니다. 바로 그 차이가 중요합니다.

에러 메시지: 요약하지 말고 그대로 전달하기

콘솔 에러가 뜨는 경우에는 더 분명합니다. 이럴 때는 에러를 해석해서 줄이는 것보다, 원문을 그대로 전달하는 편이 낫습니다. 초보자가 자주 하는 실수는 “null 관련 에러가 떠요”, “undefined 어쩌구가 나와요”처럼 자기식으로 요약하는 것입니다. 그런데 이 요약 과정에서 중요한 정보가 많이 빠집니다.

에러 메시지에는 생각보다 많은 힌트가 들어 있습니다. 어떤 값이 비어 있는지, 어느 파일 몇 번째 줄인지, 어느 함수에서 터졌는지 같은 정보가 들어 있기 때문입니다. 그래서 가능한 한 복사해서 그대로 붙이는 습관이 좋습니다.

에러를 전달할 때 같이 붙이면 좋은 정보
항목 예시 왜 중요한가
에러 원문 Uncaught TypeError: Cannot read properties of null... 어떤 종류의 문제인지 가장 먼저 좁혀준다
파일명과 줄 번호 script.js:214 어디를 먼저 봐야 하는지 바로 정할 수 있다
발생 시점 페이지 로드 직후, 버튼 클릭 직후, 저장 버튼 누른 뒤 문제가 초기 로드인지, 특정 동작 이후인지 구분할 수 있다
직전에 바꾼 것 검색 영역 추가, 함수 이름 변경, 버튼 클래스 수정 원인이 생긴 지점을 더 빠르게 좁힐 수 있다
에러 유무 자체 콘솔 에러 없음 문제가 문법이나 런타임 오류보다 로직 쪽일 가능성을 높여준다

예를 들어 아래처럼 주면 훨씬 좋습니다.

[에러 메시지]

Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
at bindSearchEvents (script.js:214:24)

[발생 시점]

페이지 새로고침 직후 바로 발생

검색 영역을 추가한 뒤부터 시작됨

[직전에 바꾼 것]

index.html에 search-section 추가

script.js에 bindSearchEvents 함수 추가

[관련 질문]

가장 가능성 큰 원인이 무엇인지

먼저 확인할 HTML selector와 JS 연결 순서를 알려줘

여기서 중요한 건 “이 에러가 뭔지 알려줘”보다도, 어느 지점을 먼저 확인해야 할지를 물어보는 것입니다. 초보자에게는 이 질문 방식이 특히 유용합니다. 한 번에 해결책을 통째로 받기보다, 원인을 좁혀가는 순서를 배우기 때문입니다.

화면 맥락: 무엇을 눌렀고 무엇이 달라졌는지 설명하기

문제가 늘 콘솔 에러로 나타나는 것은 아닙니다. 오히려 실제로는 에러 없이 화면만 이상하게 보이거나, 특정 상태에서만 동작이 꼬이는 경우가 꽤 많습니다. 이런 경우에는 코드보다 재현 순서가 더 중요할 때도 있습니다. 재현 순서란, 같은 문제가 다시 일어나게 만드는 단계별 순서를 말합니다.

화면 문제를 설명할 때는 아래 다섯 가지 정도를 챙기면 좋습니다.

  • 문제가 시작되기 전 상태가 무엇이었는지
  • 어떤 버튼이나 입력을 어떤 순서로 했는지
  • 지금 필터, 검색, 수정 모드 같은 상태가 걸려 있는지
  • 실제로 화면에서 무엇이 보였는지
  • 원래 기대한 결과가 무엇이었는지

예를 들어 “삭제 후 화면이 이상해요”만으로는 부족합니다. 전체 보기인지 완료 보기인지, 검색 중이었는지, 수정 중이었는지에 따라 완전히 다른 문제가 될 수 있기 때문입니다. 상태가 여러 개 겹치는 앱일수록 이 설명이 더 중요해집니다.

할 일 앱 예시로 바꿔 쓰면 이런 식이 더 좋습니다.

[현재 상태]

완료 보기 필터가 선택된 상태

검색창에 "회의"를 입력한 상태

검색 결과로 1개 항목만 보이는 상태

[재현 순서]

완료 보기 버튼을 누른다

검색창에 "회의"를 입력한다

보이는 항목의 삭제 버튼을 누른다

[실제 결과]

목록은 비었는데 summary 문구는 그대로 "검색 결과 1개"로 남아 있음

빈 상태 메시지도 바로 바뀌지 않음

[기대한 결과]

목록이 비면 summary 문구가 0개로 바뀌고

"검색어에 맞는 할 일이 없습니다" 같은 안내가 보여야 함

이 설명은 단순히 “삭제 후 summary가 이상해요”보다 훨씬 낫습니다. AI가 봐야 할 상태가 이미 들어 있기 때문입니다. 이 경우에는 단순 삭제 기능 문제가 아니라, 필터 상태와 검색 상태를 함께 반영한 뒤 요약 문구를 다시 그리는 흐름을 의심하게 됩니다.

핵심 포인트
화면 문제는 화면만의 문제가 아닐 때가 많습니다. 그 화면이 만들어지기 전 상태와 버튼 순서를 같이 줘야 실제 원인에 더 가까워집니다.

스크린샷도 분명 도움이 됩니다. 특히 정렬이 깨졌거나, 버튼 위치가 이상하거나, 비활성 상태가 눈에 잘 안 들어오는 문제에서는 꽤 유용합니다. 다만 스크린샷만 던지고 끝내기보다는, 무엇을 눌렀고 무엇이 기대와 달랐는지를 텍스트로 같이 적는 편이 안전합니다. 화면 한 장만으로는 이전 상태나 클릭 순서가 빠지기 쉽기 때문입니다.

AI에게는 이렇게 정리해서 요청하면 된다

이제 앞에서 본 내용을 한 번에 묶어보겠습니다. 결국 핵심은 화려한 문장을 만드는 게 아니라, 현재 작업, 현재 문제, 관련 코드, 에러, 재현 순서, 기대한 결과를 빠뜨리지 않고 정리하는 것입니다. 아래 템플릿 정도만 있어도 막혔을 때 꽤 든든합니다.

[현재 작업]

지금 무엇을 만들고 있는지

어디까지는 정상 동작하는지

오늘 새로 붙인 기능이 무엇인지

[현재 문제]

지금 어떤 문제가 보이는지 한두 문장으로 정리

[관련 파일]

어떤 파일이 직접 관련 있는지

관련 함수나 요소 이름이 무엇인지

[관련 코드]

문제와 연결된 코드만 먼저 첨부

연결 문제가 의심되면 HTML, CSS, JS를 같이 첨부

[에러 메시지]

있으면 원문 그대로

없으면 "콘솔 에러 없음"이라고 명시

[재현 순서]

어떤 상태에서 시작하는지

무엇을 누르거나 입력하는지

어디서 문제가 보이는지

[기대한 결과]

원래는 어떻게 동작해야 하는지

[원하는 답변 방식]

가장 가능성 큰 원인 몇 개

확인 순서

수정이 필요한 코드만 제안

전체 리팩터링은 하지 말 것

실제로 할 일 앱 검색 기능을 예로 들면, 이렇게 요청할 수 있습니다.

지금 HTML, CSS, JavaScript로 할 일 앱을 만드는 중이야.

추가, 삭제, 완료 체크, 필터까지는 정상 동작하고,
오늘은 검색 기능을 붙이는 단계야.

문제는 완료 보기 상태에서 검색 후 항목을 삭제하면
목록은 비는데 summary 문구가 바로 갱신되지 않는다는 점이야.
콘솔 에러는 없어.

관련 파일은 script.js이고,
renderTodos, updateSummary, getFilteredTodos 흐름이 연결돼 있어.

재현 순서

완료 보기 선택

검색창에 특정 단어 입력

검색 결과로 보이는 항목 삭제

기대한 결과

목록이 비면 summary도 0개로 바뀌고

빈 상태 메시지가 같이 보여야 해

원하는 답변

가장 의심되는 함수 흐름을 먼저 짚어줘

왜 그런지 설명해줘

수정할 코드 위치만 제안해줘

전체 코드를 처음부터 다시 쓰지는 말아줘

이 정도만 정리해도 AI는 답변을 훨씬 좁혀서 하게 됩니다. 특히 마지막의 “전체 코드를 다시 쓰지 말아줘” 같은 문장은 입문자에게 꽤 중요합니다. 초보자는 큰 구조를 통째로 갈아엎는 답보다, 지금 코드에서 무엇을 확인하고 어디를 바꾸면 되는지 배우는 쪽이 더 도움이 되기 때문입니다.

반대로 자주 하는 실수도 같이 기억해두면 좋습니다.

  • “안 돼요”만 적는다
    문제 범위가 너무 넓어서 AI가 추정을 많이 하게 됩니다.
  • 에러를 내 말로만 요약한다
    파일명, 줄 번호, 함수 이름 같은 중요한 단서가 빠질 수 있습니다.
  • 코드를 무작정 전부 붙인다
    관련 없는 코드까지 섞이면 초점이 흐려집니다.
  • 재현 순서를 안 적는다
    특정 상태에서만 생기는 문제를 놓치기 쉽습니다.
  • 기대한 결과를 안 적는다
    AI는 “무엇이 잘못됐는가”만이 아니라 “원래 무엇이 되어야 하는가”도 알아야 합니다.

짧은 체크리스트
현재 작업, 현재 문제, 관련 파일, 에러 원문, 재현 순서, 기대한 결과. 이 여섯 가지만 챙겨도 질문의 품질은 꽤 달라집니다.

마무리

지금까지 연재 흐름을 묶어보면 이렇습니다. 먼저 AI에게 어떤 역할로 답하게 할지 정했고, 그다음 좋은 요청의 기본 구조를 잡았고, 큰 작업을 작은 단계로 나누는 법까지 왔습니다. 이번 편은 거기서 한 걸음 더 나아가, 지금 내 코드와 화면이 어떤 상태인지 AI가 따라갈 수 있게 넘기는 법을 다뤘습니다.

입문자에게 이 부분이 중요한 이유는 분명합니다. AI의 답이 늘 맞는가보다, 내가 지금 무엇을 물어보고 있는지 분명한가가 먼저이기 때문입니다. 현재 상태를 잘 넘기기 시작하면 답변이 덜 퍼지고, 수정 요청도 훨씬 쉬워집니다. 그렇게 해야 AI가 준 답을 그냥 복붙하는 단계를 조금씩 넘어설 수 있습니다.

다음 편에서는 여기서 자연스럽게 이어서, AI가 준 코드를 어떻게 검토하고 다시 요청하면 좋은지를 다루면 흐름이 좋습니다. 돌아간다고 끝이 아니라, 무엇이 빠졌고 무엇을 다시 물어봐야 하는지 보는 감각도 결국 같이 붙어야 하기 때문입니다.

'바이브코딩 > 기초' 카테고리의 다른 글

[기초-5] 막혔을 때 이렇게 물어보세요: 초보자를 위한 AI 디버깅 요청의 기본  (0) 2026.04.14
[기초-4] 돌아간다고 끝은 아니다: AI 코드 검토와 다시 요청하는 법  (0) 2026.04.07
[기초-2] 한 번에 다 시키지 마세요: 바이브 코딩에서 큰 요청을 잘게 나누는 법  (0) 2026.03.24
[기초-1] 좋은 요청의 기본 구조: 목표·맥락·제약·출력 형식 쉽게 잡는 법  (0) 2026.03.17
[기초-0] “너는 시니어 개발자야”만으론 부족하다: 바이브 코딩을 위한 AI 페르소나 프롬프트 기초  (1) 2026.03.10