바이브 코딩 에러 해결 가이드
API·HTTP 상태코드·CORS만 알아도 덜 막힌다
AI에게 “에러 고쳐줘”라고만 말하면 같은 오류가 반복된다. 에러의 종류를 모르면 AI도 추측으로 코드를 고치기 때문이다. 바이브 코딩에서 가장 먼저 익혀야 할 세 단어는 API, HTTP 상태코드, CORS다. 이 세 개만 알아도 AI에게 주는 맥락이 달라지고, 무한 수정 루프를 줄일 수 있다.
먼저 결론
비개발자가 바이브 코딩을 할 때 필요한 것은 모든 코딩 지식이 아니다. 에러가 났을 때 내 요청이 틀린 것인지, 인증이 빠진 것인지, 주소가 없는 것인지, 서버가 아픈 것인지, 브라우저 보안정책에 막힌 것인지를 구분하는 눈이 먼저다. 이 구분을 AI에게 알려주면 답변 품질이 크게 달라진다.
서버와 대화하는 메뉴판
앱이 어떤 형식으로 요청하면 어떤 데이터를 받을 수 있는지 정한 약속이다.
서버의 숫자 답변
200은 성공, 400번대는 요청 쪽 문제, 500번대는 서버 쪽 문제로 방향을 잡는다.
브라우저의 출입 허가
터미널에서는 되는데 브라우저에서 막히는 대표 원인이다.
1. 왜 AI가 고쳤다는데 에러가 반복될까
영상의 출발점은 단순하다. 빨간 줄이나 콘솔 오류가 나왔을 때 그 오류가 어떤 종류인지 모른 채 AI에게 “고쳐줘”라고 하면, AI는 정확한 위치와 원인을 모른다. 그러면 추측으로 코드를 바꾸고, 엉뚱한 파일을 건드리고, 새로운 에러가 생긴다.
따라서 바이브 코딩의 첫 번째 실력은 코드를 직접 다 외우는 것이 아니다. 에러 메시지를 읽고 AI에게 줄 진단 정보를 뽑는 능력이다. API, HTTP 상태코드, CORS는 그 진단의 가장 기본 단위다.
2. API란 무엇인가: 앱과 서버 사이의 메뉴판
영상은 API를 식당 메뉴판에 비유한다. 손님은 주방 안이 어떻게 돌아가는지 몰라도 메뉴판에 적힌 방식대로 주문하면 음식을 받을 수 있다. 앱도 마찬가지다. 날씨, 지도, 결제, 로그인 같은 기능은 외부 서버가 정한 API라는 메뉴판에 맞춰 요청을 보내고 응답을 받는다.
| 비유 | 웹 개발에서의 의미 | 바이브 코딩에서 확인할 것 |
|---|---|---|
| 손님 | 내 앱 또는 프론트엔드 | 어디서 요청을 보내는가 |
| 메뉴판 | API 문서 또는 API 스펙 | 요청 URL, 메서드, 파라미터, 인증 방식 |
| 주문서 | HTTP 요청 | 형식이 맞는가, JSON 구조가 맞는가 |
| 주방 | 서버 | 서버가 정상 응답을 주는가 |
| 음식 | 응답 데이터 | 내가 기대한 데이터가 맞는가 |
MDN은 API를 복잡한 기능을 더 쉽게 만들도록 제공되는 구성요소라고 설명한다. 즉 API는 내부 구현을 몰라도 정해진 방식으로 기능을 사용할 수 있게 해 주는 통로다.
3. HTTP 상태코드: 서버가 보내는 첫 번째 힌트
HTTP 상태코드는 서버가 요청에 대해 먼저 보내는 숫자 답변이다. 개발자도 에러가 나면 먼저 네트워크 탭이나 터미널에서 이 숫자를 확인한다. 상태코드는 에러의 방향을 정해 준다.
| 코드 | 의미 | 식당 비유 | AI에게 말할 내용 |
|---|---|---|---|
| 200 | 요청 성공 | 주문이 정상 접수되고 음식이 나옴 | 응답은 오는데 화면에 표시가 안 되는 문제인지 확인 |
| 400 | 잘못된 요청 | 주문서 형식이 틀림 | 파라미터, JSON, 필수값 누락, 요청 형식을 확인 |
| 401 | 인증 필요 또는 인증 실패 | 회원 카드가 없음 | 로그인 토큰, API 키, Authorization 헤더 확인 |
| 403 | 권한 없음 | 회원은 맞지만 이 메뉴 주문 권한이 없음 | 권한, 도메인 허용, 요금제, 접근 범위 확인 |
| 404 | 리소스 없음 | 없는 메뉴를 주문함 | URL, 엔드포인트, 라우팅, 파일 경로 확인 |
| 500 | 서버 내부 오류 | 주방에서 사고가 남 | 서버 로그, 백엔드 예외, 외부 서비스 장애 확인 |
핵심: 2xx는 대체로 성공, 4xx는 대체로 요청자 쪽 문제, 5xx는 대체로 서버 쪽 문제다. 상태코드 앞자리만 알아도 AI에게 어떤 방향으로 고치라고 말할 수 있다.
4. 브라우저에서 상태코드 확인하는 법
영상에서는 브라우저 개발자 도구의 네트워크 탭을 보여 준다. 비개발자도 이 정도는 익혀두면 좋다. AI에게 질문할 때 “에러가 났다”가 아니라 “네트워크 탭에서 404가 나온다”라고 말할 수 있기 때문이다.
오류가 나는 페이지를 그대로 둔다.
Chrome 기준 개발자 도구를 연다.
요청 목록과 상태코드를 볼 수 있다.
요청이 다시 찍히게 한다.
Status, Request URL, Response, Console 메시지를 복사한다.
5. CORS란 무엇인가: 브라우저의 출입 허가
CORS는 Cross-Origin Resource Sharing의 약자다. MDN은 CORS를 서버가 어떤 출처(origin)의 브라우저 요청을 허용할지 HTTP 헤더로 알려주는 표준이라고 설명한다. 영상에서는 친구 집에 놀러 가기 전 허락을 받는 상황으로 비유한다.
핵심은 CORS가 서버 오류라기보다 브라우저 보안 정책이라는 점이다. 같은 API를 터미널에서 curl로 호출하면 200이 나오는데, 브라우저에서 호출하면 CORS 에러가 날 수 있다. 터미널에서는 되는데 브라우저에서만 안 되면 CORS를 먼저 의심해야 한다.
| 상황 | 가능한 원인 | AI에게 줄 힌트 |
|---|---|---|
| 터미널 curl은 200, 브라우저는 CORS | API 서버가 내 웹앱 출처를 허용하지 않음 | 브라우저 CORS 에러이며 서버의 Access-Control-Allow-Origin 설정을 확인해 달라고 요청 |
| localhost에서 외부 API 호출 실패 | 개발 서버 출처가 허용되지 않음 | 개발환경 origin을 허용해야 하는지, 프록시 서버가 필요한지 질문 |
| 인증 포함 요청에서 CORS 실패 | credentials, 쿠키, 인증 헤더 허용 설정 문제 | Access-Control-Allow-Credentials와 허용 origin을 함께 점검 요청 |
| OPTIONS 요청 실패 | preflight 요청 처리 미흡 | 서버가 OPTIONS 메서드와 CORS 헤더를 응답하는지 확인 요청 |
6. AI에게 에러를 물어볼 때 붙여야 할 정보
AI에게 정확히 물어보려면 문제 상황을 관찰한 결과를 붙여야 한다. 다음 다섯 가지만 있어도 답변이 훨씬 좋아진다.
반드시 붙일 정보
- 브라우저 콘솔 에러 전문
- Network 탭의 Status 코드
- Request URL
- Request Method: GET, POST 등
- Response 또는 에러 메시지
있으면 좋은 정보
- 프론트엔드 주소
- 백엔드/API 주소
- API 키 사용 여부
- 로그인 토큰 사용 여부
- 터미널 curl 결과
AI에게 바로 붙여넣는 디버깅 프롬프트
7. 상태코드별로 AI에게 시킬 일
| 에러 | AI에게 먼저 시킬 일 | 바로 고치지 말고 확인할 것 |
|---|---|---|
| 400 | 요청 파라미터와 JSON body가 API 문서와 맞는지 비교 | 필수값, 타입, 날짜 형식, Content-Type |
| 401 | 인증 토큰/API 키가 요청 헤더에 제대로 들어가는지 확인 | Authorization 형식, 만료 여부, 환경변수 이름 |
| 403 | 권한·도메인 허용·요금제 제한 가능성 확인 | 관리자 콘솔 설정, 허용 origin, API 권한 범위 |
| 404 | 요청 URL과 라우팅 경로 점검 | 오타, 버전 경로, /api 접두어, 동적 라우트 |
| 500 | 백엔드 로그와 서버 예외 추적 | DB 연결, 외부 API 장애, null 처리, 환경변수 누락 |
| CORS | 브라우저 origin 허용과 preflight 응답 확인 | 서버 CORS 설정, 프록시 필요 여부, credentials 설정 |
8. 터미널에서는 되는데 브라우저에서 안 될 때
이 상황은 바이브 코딩에서 특히 자주 나온다. AI가 터미널에서 curl로 API를 호출해 보고 “정상입니다”라고 말했는데, 사용자가 웹 화면에서 테스트하면 실패하는 경우다. 이때는 AI가 거짓말을 한 것이 아니라 테스트 환경이 다를 수 있다.
주의: curl은 브라우저가 아니다. 브라우저는 CORS, 쿠키, 인증, mixed content, SameSite 같은 보안 정책을 적용한다. 터미널 테스트 성공은 브라우저 화면 성공을 보장하지 않는다.
9. 비개발자용 디버깅 순서
콘솔 메시지를 요약하지 말고 그대로 복사한다.
Network 탭에서 빨간 요청의 Status를 본다.
Request URL이 API 문서와 같은지 본다.
가능하면 curl 결과와 브라우저 결과를 비교한다.
API 형식, 인증, CORS, 서버 문제 중 어디인지 먼저 나누게 한다.
10. 최종 판단: 바이브 코더에게 필요한 건 ‘에러 번역 능력’이다
바이브 코딩의 장점은 빠르게 만들 수 있다는 것이다. 하지만 에러가 나면 빠른 속도가 곧 무한 루프로 바뀐다. 이때 필요한 것은 모든 코드를 이해하는 능력이 아니라, 에러를 AI가 이해할 수 있는 언어로 번역하는 능력이다.
API는 메뉴판, HTTP 상태코드는 서버의 숫자 답변, CORS는 브라우저의 출입 허가다. 이 세 개를 구분하면 “고쳐줘”가 아니라 “401 인증 문제인지 확인해줘”, “브라우저 CORS라서 서버 헤더를 봐줘”라고 말할 수 있다. 그 순간 AI는 훨씬 덜 헤매고, 수정도 더 작고 정확해진다.
참고 자료
이 글은 영상 내용과 공식 문서를 바탕으로 바이브 코딩 입문자가 에러를 분류하고 AI에게 더 정확히 질문할 수 있도록 정리한 실무형 가이드입니다.