웹 개발을 하다 보면 한 번쯤 이런 상황을 만나게 됩니다.
왜 브라우저에서는 요청이 안 되지?"
개발자 도구의 Console을 확인해보니 처음 보는 빨간 에러가 나타납니다.
Access to fetch at 'http://localhost:8080/...'
from origin 'http://localhost:3000/...'
has been blocked by CORS policy바로 개발 초보자들을 당황하게 만드는 CORS 에러입니다.
이번 글에서는 복잡한 설정 방법부터 외우기보다 CORS가 무엇이고, 브라우저는 왜 이런 검사를 하는지부터 쉽게 이해해보겠습니다.
1. CORS란?
CORS는 Cross-Origin Resource Sharing의 약자입니다.
→ 서로 다른 출처(Origin) 간의 리소스 공유
개발자들은 보통 CORS를 "콜스"라고 부릅니다.
이름만 보면 어려워 보이지만 핵심은 생각보다 단순합니다.
어떤 웹페이지가 자신과 다른 출처의 서버에 있는 리소스를 사용하려고 할 때, 브라우저와 서버가 정해진 규칙에 따라 해당 접근을 허용할 수 있도록 하는 방식입니다.
2. 그런데 '출처(Origin)'가 뭘까?
CORS를 이해하려면 먼저 Origin이라는 개념을 알아야 합니다.
웹에서 출처를 판단할 때는 기본적으로 다음 요소를 확인합니다.
예를 들어 다음 주소를 살펴보겠습니다.
http://localhost:3000
http → 프로토콜
localhost → 호스트
3000 → 포트이 요소를 기준으로 출처가 같은지 다른지를 판단할 수 있습니다.
3. localhost인데 포트만 달라도 다른 출처일까?
네. 웹 개발을 처음 할 때 특히 많이 헷갈리는 부분입니다.
프론트엔드 개발 서버와 백엔드 API 서버를 다음과 같이 실행했다고 가정해보겠습니다.
| 구분 | 주소 |
|---|---|
| 프론트엔드 | http://localhost:3000 |
| 백엔드 API | http://localhost:8080 |
둘 다 localhost이고 프로토콜도 http입니다.
하지만 하나는 3000번 포트, 다른 하나는 8080번 포트를 사용하고 있습니다.
그래서 프론트엔드에서 백엔드 API로 요청을 보내는 상황에서 CORS를 만나게 되는 경우가 많습니다.
4. 브라우저는 왜 다른 출처를 신경 쓸까?
그렇다면 이런 의문이 생깁니다.
"그냥 다른 서버의 데이터를 가져오게 해주면 되는 것 아닌가?"
웹페이지가 아무런 제한 없이 다른 출처의 리소스에 접근할 수 있다면 사용자의 정보나 인증 상태 등을 악용하려는 공격에 노출될 위험이 커질 수 있습니다.
그래서 브라우저에는 기본적으로 동일 출처 정책(Same-Origin Policy, SOP)이라는 중요한 보안 원칙이 있습니다.
하지만 실제 웹 서비스를 만들다 보면 다른 출처와 통신해야 하는 상황이 많습니다.
예를 들어 프론트엔드 서버와 API 서버가 분리되어 있거나, 외부 API를 사용하는 경우가 대표적입니다.
그래서 필요한 것이 바로 CORS입니다.
5. CORS는 어떻게 허용할까?
핵심 아이디어는 서버가 브라우저에게 "이 출처의 접근은 허용한다"는 정보를 전달하는 것입니다.
이때 자주 보게 되는 대표적인 HTTP 응답 헤더가 Access-Control-Allow-Origin입니다.
Access-Control-Allow-Origin: http://localhost:3000쉽게 표현하면 서버가
라고 브라우저에게 알려주는 것과 비슷합니다.
브라우저는 이러한 CORS 관련 응답 정보를 확인해 다른 출처에서 해당 리소스를 사용할 수 있는지를 판단합니다.
6. 그러면 CORS 에러는 서버가 고장 난 걸까?
꼭 그렇지는 않습니다.
서버 자체는 정상적으로 동작하고 있어도 브라우저가 CORS 정책에 따라 응답을 사용할 수 없다고 판단할 수 있습니다.
따라서 CORS 에러를 만났다면 단순히 "API 서버가 죽었나?"만 확인할 것이 아니라, 다음과 같은 부분도 함께 살펴볼 필요가 있습니다.
7. OPTIONS와 Preflight는 또 뭘까?
CORS를 검색하다 보면 Preflight나 OPTIONS라는 용어도 자주 보게 됩니다.
특정 cross-origin 요청에서는 브라우저가 실제 요청을 보내기 전에 서버가 해당 요청을 허용하는지 먼저 확인하는 요청을 보낼 수 있습니다.
↓
"이 요청 보내도 돼?" (Preflight / OPTIONS)
↓
서버
↓
"허용해!"
↓
실제 요청
다만 모든 cross-origin 요청에서 Preflight가 발생하는 것은 아닙니다. 이번에는 "실제 요청 전에 허용 여부를 미리 확인하는 경우도 있다" 정도만 기억해두면 충분합니다.
8. CORS 1분 안에 다시 이해하기
글로 살펴본 내용을 오늘의 IT한입 Shorts로 한 번 더 정리해보세요.
9. CORS 핵심 정리
| 개념 | 의미 |
|---|---|
| CORS | Cross-Origin Resource Sharing |
| Origin | 프로토콜 + 호스트 + 포트로 구분 |
| CORS 역할 | 다른 출처의 리소스를 정해진 규칙에 따라 공유할 수 있도록 함 |
| 대표 헤더 | Access-Control-Allow-Origin |
다음에 개발 중 CORS 에러를 만난다면 무작정 에러 메시지부터 복사해 검색하기 전에,
부터 생각해보세요. CORS 에러를 이해하는 출발점이 훨씬 명확해질 겁니다.
분명 배웠는데 막상 설명하려면 헷갈리는 개발 기초 개념, 오늘의 IT한입에서 쉽고 짧게 하나씩 정리합니다.
CORS처럼 개발 공부 중 자꾸 헷갈리는 개념들을 짧고 쉽게 정리한 콘텐츠도 함께 확인해보세요.
'IT개발 > Tech Notes' 카테고리의 다른 글
| 정보처리기사 필기｜XP(eXtreme Programming)란? 핵심 가치와 실천 방법 쉽게 정리 (0) | 2026.10.07 |
|---|---|
| 교착상태(Deadlock)란? 쉬운 예시로 이해하는 데드락 개념과 발생 조건 (0) | 2026.10.01 |
| 동기(Synchronous)와 비동기(Asynchronous) 차이란? 초보자도 이해하는 쉬운 예시 (0) | 2026.09.21 |
| localhost와 127.0.0.1이란? 개발할 때 localhost:8080을 사용하는 이유 (0) | 2026.09.16 |
| 공인 IP와 사설 IP 차이 쉽게 이해하기｜192.168로 시작하는 이유는? (1) | 2026.09.16 |
댓글