CORS 에러가 뭐야 — 왜 자꾸 요청이 막힐까

CORS 에러는 웹페이지가 다른 출처(다른 주소)의 서버에 요청할 때, 브라우저가 안전을 위해 막아서 생기는 에러입니다.

2026년 7월 기준으로 AI에게 코드를 맡겨 처음 웹을 만들다 보면 거의 첫날 만나는 에러이기도 합니다.

이 글을 읽으면 CORS가 왜 생기는지, 그리고 이걸 왜 대개 프론트가 아니라 서버(백엔드)에서 고치는지 알 수 있습니다.

CORS 에러는 브라우저가 "다른 출처끼리 함부로 통신하지 마"라는 안전 규칙을 지키느라 요청을 막는 것입니다. 서버가 "이 출처는 괜찮아"라는 허가증(헤더)을 내주면 통과됩니다. 그래서 해결도 보통 화면(프론트)이 아니라 서버 쪽에서 합니다.

CORS 에러는 왜 생길까

브라우저에는 오래된 안전 규칙이 하나 있습니다.

바로 same-origin policy, 우리말로 "같은 출처 정책"입니다.

쉽게 말해 웹페이지는 자기와 같은 출처의 서버하고만 자유롭게 통신할 수 있습니다.

다른 출처의 서버에 데이터를 요청하면 브라우저가 일단 막고 봅니다.

이때 브라우저 콘솔에 빨갛게 뜨는 게 바로 CORS 에러입니다.

중요한 건 서버가 요청을 거부한 게 아니라는 점입니다.

서버는 멀쩡히 답을 보냈는데, 브라우저가 그 답을 화면에 넘겨주지 않고 중간에서 막은 것에 가깝습니다.

여기서 말하는 '출처'가 뭘까

출처(origin)는 웹 주소를 이루는 세 가지가 합쳐진 것입니다.

프로토콜(http인지 https인지), 도메인(사이트 주소), 그리고 포트 번호입니다.

이 셋 중 하나라도 다르면 브라우저는 "다른 출처"로 봅니다.

예를 들어 앞서 다룬 localhost와 포트 이야기처럼, 같은 내 컴퓨터라도 포트 번호만 다르면 다른 출처가 됩니다.

비교	주소	같은 출처일까
기준 주소	http://localhost:3000	-
포트만 다름	http://localhost:8080	다른 출처
프로토콜만 다름	https://localhost:3000	다른 출처
경로만 다름	http://localhost:3000/about	같은 출처

표에서 보듯 주소 뒤에 붙는 경로(/about 같은 부분)만 다른 건 같은 출처로 칩니다.

반면 프로토콜, 도메인, 포트는 하나만 어긋나도 다른 출처가 됩니다.

왜 굳이 이렇게까지 막을까

불편해 보이지만 이 규칙은 사용자를 지키기 위한 것입니다.

아무 사이트나 다른 출처에 마음대로 요청을 보낼 수 있다면 어떻게 될까요.

내가 어떤 이상한 사이트에 접속한 순간, 그 사이트의 코드가 내 은행 사이트나 메일 서버에 몰래 요청을 보낼 수도 있습니다.

로그인된 상태를 틈타 내 정보를 빼갈 위험이 생기는 것입니다.

그래서 브라우저가 경비원처럼 문 앞을 지키면서, 다른 출처로 가는 요청은 일단 허가를 확인합니다.

그럼 어떻게 풀까

해결의 핵심은 서버가 "이 출처는 통과시켜도 된다"고 허가증을 내주는 것입니다.

이 허가증이 바로 응답에 붙는 Access-Control-Allow-Origin이라는 헤더입니다.

서버가 응답을 보낼 때 이 헤더에 "이 출처는 허용"이라고 적어주면, 브라우저는 그제야 답을 화면에 넘겨줍니다.

반응형

Access-Control-Allow-Origin: http://localhost:3000

여기서 꼭 기억할 점이 있습니다.

이 헤더는 화면 쪽 코드(프론트엔드)가 아니라 요청을 받는 서버(백엔드)가 붙여줘야 합니다.

MDN 문서에서도 CORS는 서버가 응답 헤더로 허용 여부를 알려주는 방식으로 설명합니다.

그래서 CORS 에러는 화면에서 아무리 코드를 고쳐도 잘 안 풀리고, 대개 서버 설정을 바꿔야 해결됩니다.

⚠️ CORS 에러가 떴을 때 화면 코드부터 뒤지는 경우가 많은데, 실제로 손대야 할 곳은 대개 백엔드 서버입니다.

AI로 코딩하는데 CORS가 왜 나올까

요즘은 AI에게 화면(프론트엔드)과 서버(백엔드)를 나눠서 만들어달라고 하는 경우가 많습니다.

이렇게 둘을 따로 띄우면 주소나 포트가 자연스럽게 달라집니다.

즉 서로 다른 출처가 되고, 화면이 서버에 데이터를 요청하는 순간 CORS 에러를 만나게 됩니다.

그래서 AI로 웹을 처음 붙여볼 때 이 에러를 만나는 건 이상한 일이 아닙니다.

개인적으로는 CORS를 처음부터 "내가 뭘 잘못했나" 싶은 버그로 볼 필요는 없다고 생각합니다.

원리만 알면, AI에게 "백엔드에 CORS 허용 설정을 추가해줘"라고 정확히 요청할 수 있으니까요.

자주 묻는 질문

CORS 에러는 프론트에서 고치나요, 백엔드에서 고치나요

728x90

대개 백엔드(서버)에서 고칩니다.

허용 여부를 알려주는 Access-Control-Allow-Origin 헤더를 붙이는 주체가 요청을 받는 서버이기 때문입니다.

화면 코드만 고쳐서는 잘 해결되지 않는 경우가 많습니다.

CORS 에러가 뜨면 서버가 고장 난 건가요

아닙니다.

서버는 대개 정상적으로 답을 보냈고, 브라우저가 안전 규칙 때문에 그 답을 화면에 넘겨주지 않은 것입니다.

그래서 서버 자체의 오류라기보다 출처 허용 설정이 빠진 경우가 많습니다.

정리

CORS 에러는 브라우저가 다른 출처끼리의 통신을 안전을 위해 막으면서 생기는 현상입니다.

출처는 프로토콜, 도메인, 포트로 정해지고 하나만 달라도 다른 출처가 됩니다.

해결은 서버가 허용 헤더를 내주는 것이고, 그래서 손댈 곳은 대개 백엔드입니다.

원리를 알아두면 AI로 프론트와 백엔드를 붙이다 이 에러를 만나도 당황하지 않게 됩니다.

 

 

참고한 자료

MDN 한국어 CORS 문서와 CORS 에러 문서를 참고했습니다.