AI한테 "또 안 돼"만 반복하던 날들 — 에러를 디버깅 요청문으로 바꾸는 도구

화면 다음에 막히는 곳

지난번에 바이브 코딩 UI 필수 용어 75를 정리해서 올렸다. "예쁘게 해줘" 대신 Bento Grid, Toast, Skeleton Loading 같은 이름으로 말하면 AI가 원하는 화면을 훨씬 빨리 만든다는 이야기였다.

그런데 화면을 잘 시키게 되니 다음 벽이 바로 나왔다. 에러다. 화면이 하얗게 뜨거나 콘솔에 빨간 글씨가 가득하면, 용어를 열심히 고르던 손이 다시 "안 돼요, 고쳐줘"로 돌아간다.

그러면 AI는 에러 메시지 한 줄만 보고 짐작으로 고친다. 운이 좋으면 한 번에 끝나고, 아니면 비슷한 수정을 몇 번이고 되풀이한다. "아직도 안 돼", "또 안 돼"를 주고받다 보면 코드는 처음보다 더 꼬여 있다.

"안 돼요"로는 안 되는 이유

AI가 헤매는 건 실력보다 정보 문제인 경우가 많다. 사람한테 버그를 넘길 때라면 당연히 같이 줄 것들이 AI에게는 빠져 있다.

• 무엇을 하던 중이었는지 — 어느 페이지에서 무엇을 눌렀는지
• 기대한 동작과 실제 동작 — "목록이 떠야 하는데 하얀 화면"처럼 둘을 나눠서
• 에러 전체와 위치 — 첫 줄만이 아니라 파일명:줄번호가 찍힌 부분까지
• 직전에 바꾼 것 — 에러는 대개 마지막 수정에서 시작된다

반대로 넘기면 안 되는 것도 있다. 로그를 통째로 붙이다 보면 API 키, 토큰, 이메일이 같이 딸려 간다.

그래서 만든 것: 에러 디버깅 프롬프트 변환기

에러 디버깅 프롬프트 변환기 — mifplus.com/tools/debug-prompt

UI 용어 75처럼 설치 없이 브라우저에서 바로 열린다. 쓰는 순서는 세 단계다. 에러 메시지를 붙여 넣고, 상황을 체크하고, 완성된 요청문을 복사해서 AI에게 보낸다.

신경 쓴 게 하나 있다. 붙여 넣은 로그는 브라우저 밖으로 나가지 않는다. 서버로 보내지도, AI를 부르지도 않고 판별은 전부 페이지 안에서 규칙으로 한다. 에러 로그에는 생각보다 민감한 값이 많이 섞여 있어서, 붙여 넣는 데 망설임이 없어야 한다고 봤다.

붙여 넣으면 진단부터 해 준다

로그를 붙여 넣으면 오른쪽에 진단 카드가 뜬다. 예시 버튼 중 Supabase RLS를 누르면, 글 저장이 막혔을 때의 로그로 이렇게 진단한다.

• 무슨 에러인지 쉬운 말로 — new row violates row-level security policy를 "Supabase 보안 규칙(RLS)이 저장을 막았어요"로 바꿔 준다. 비유도 하나 붙였다. 아파트 우편함처럼, 내 칸이 아니면 넣을 수 없는 상황.
• 흔한 원인 3가지와 먼저 직접 해 볼 것 — AI에게 묻기 전에 내가 1분 안에 확인할 수 있는 것.
• 로그에서 찾은 것 — 에러 문구는 형광펜, 문제 위치(src/lib/posts.ts:14:9)는 파란 밑줄, 상태 코드는 빨간 테두리로 칠한다. node_modules 안쪽은 건너뛰고, 내 코드에서 처음 나오는 파일을 문제 위치로 잡는다.
• 민감정보 자동 가리기 — Supabase 주소, anon 키, 이메일이 [가림]으로 바뀌었다. 기본으로 켜져 있다.

판별이 틀릴 수도 있다. 그럴 땐 "다른 유형으로 바꾸기"에서 직접 고르면 되고, 로그에 에러가 여러 개 섞여 있으면 "함께 발견됨"으로 같이 보여 준다.

상황 몇 개만 체크하면 요청문이 된다

왼쪽 아래 상황 체크 칸이 앞에서 말한 "빠져 있던 정보"다. 무엇을 하던 중이었는지, 원래 어떻게 돼야 하는지, 실제로 어떻게 되는지까지가 필수다. 재현 방법, 직전에 바꾼 것, 이미 시도한 것은 적을수록 좋다. 빈칸은 요청문에서 빠진다.

위 예시를 채우면 이런 요청문이 나온다. (에러 메시지 부분은 줄였다)

## 상황
글쓰기 페이지에서 새 글을 저장하는 중에 에러가 났어요. (환경: 내 컴퓨터(로컬))

## 기대한 동작 / 실제 동작
- 기대: 글이 저장되고 목록으로 이동해야 해요
- 실제: 반응 없음: 저장 버튼을 눌러도 그대로예요

## 에러 메시지
(가림 처리된 로그 전체)

## 문제 위치(추정)
- src/lib/posts.ts:14:9
- src/app/write/page.tsx:41:13

## 직전에 바꾼 것
posts 테이블에 RLS를 켰어요

## 부탁
1. 원인을 먼저 한두 문장으로 설명해 주세요.
2. RLS를 끄지 말고, 로그인한 사용자가 자기 user_id로만 쓸 수 있는 정책을 SQL로 만들어 주세요.
3. src/lib/posts.ts을(를) 중심으로, 고칠 파일과 바꿀 부분만 수정해 주세요. 관련 없는 코드는 건드리지 마세요.
4. 고친 뒤 제가 확인할 방법을 알려 주세요.

부탁의 2번이 에러마다 달라진다. RLS 에러에 "RLS를 끄지 말고"를 넣은 건, 그 말이 없으면 AI가 정책을 꺼 버리는 가장 쉬운 '해결'을 내놓을 수 있어서다. 타입 에러에는 "any로 덮지 말고", 패키지 충돌에는 "--force 없이"를 넣은 것도 같은 이유다.

3번은 UI 용어 75에서 "로딩·빈 화면·에러 상태도 함께"를 기본으로 붙였던 것과 같은 자리다. 고칠 범위를 정해 주지 않으면 관련 없는 파일까지 손대는 일이 생겨서, 아예 기본으로 들어가게 했다.

요청문 아래에는 점검 목록이 있어서 무엇이 빠졌는지 바로 보이고, 길이는 자세히/짧게 중에 고를 수 있다.

같은 수정이 반복될 때: 루프 탈출 모드

제일 답답한 건 AI가 같은 자리를 맴돌 때다. 그래서 스위치를 하나 따로 뒀다. 루프 탈출 모드를 켜면 부탁 부분이 이렇게 바뀐다.

## 부탁 (같은 문제가 반복되고 있어요)
1. 위의 '이미 시도한 것'은 다시 제안하지 말아 주세요.
2. 코드를 고치기 전에 가능한 원인 3가지를 먼저 제시해 주세요.
3. 각 원인을 확인할 console.log 위치나 확인 방법을 알려 주세요. 결과를 알려 드리면 그때 고쳐 주세요.

핵심은 고치기 전에 확인부터 하게 만드는 것이다. 이 모드에서는 "이미 시도한 것" 칸도 필수가 된다. 같은 제안이 또 돌아오지 않게 막는 칸이라서다.

에러 사전 30, 그리고 에러가 없을 때

아래쪽에는 바이브 코딩하면서 자주 보는 에러 30개를 사전으로 묶었다.

카드를 열면 쉬운 설명, 비유, 흔한 원인, AI에게 할 말이 나온다. 이 에러로 진단해 보기를 누르면 위쪽 진단이 그 에러로 채워진다. 카드마다 주소도 있어서 CORS 카드처럼 바로 열 수 있다. 찾을 때는 / 키로 검색한다.

빨간 글씨가 아예 없는 경우도 있다. 하얀 화면, 버튼을 눌러도 반응 없음, 새로고침하면 데이터가 사라짐, 배포하면 스타일이 깨짐 같은 것들이다. 이런 증상 8개는 따로 모아서 어디를 봐야 단서가 나오는지와 요청문을 같이 붙였다.

맨 아래 실전 사전에는 에러 찾는 곳(콘솔, 네트워크 탭, 터미널, 배포 로그), HTTP 상태 코드 8개, 스택 트레이스 읽는 법, 루프 탈출 요청 3종을 정리해 뒀다.

정리하며

UI 용어 75가 "무엇을 만들지"를 정확히 말하는 도구였다면, 이번 건 "무엇이 잘못됐는지"를 정확히 말하는 도구다. 둘 다 결국 같은 이야기다. AI한테 필요한 건 긴 하소연이 아니라 정리된 정보다.

에러가 나서 "또 안 돼"를 치기 직전이라면, 그 전에 한 번 붙여 넣어 보면 좋겠다. 다음에는 저장·로그인·배포에서 막히는 백엔드 용어를 같은 방식으로 정리해 볼 생각이다.

에러 디버깅 프롬프트 변환기: https://mifplus.com/tools/debug-prompt
바이브 코딩 UI 필수 용어 75: https://mifplus.com/tools/vibe-ui
지난 글: 영상 보다가 "어, 나랑 비슷한데?" — 내가 쓰는 바이브 코딩 UI 용어 75개 정리