CORS 이슈 해결법 (Http&Socket)

웹 개발을 하면서 누구나 한 번쯤은 마주하는 골칫덩이, 바로 "CORS 이슈"에 대해 알아보고자 해요. 처음엔 이 문제가 왜 생기는지 모른 채 에러 메시지에 당황했다면, CORS와 얽힌 "프로토콜, 도메인, 포트" 등 IT 세상에서 빠질 수 없는 용어들도 함께 정리해 보면 좋아요.

 

CORS (Cross-Origin Resource Sharing)

CORS 문제가 왜 이리 자주 언급될까

 우선, 왜 이렇게 CORS가 중요하게 여겨지는지부터 알아볼게요. 간단히 말해, CORS는 웹 애플리케이션에서 보안과 직접적으로 관련이 있어요. 우리가 웹 브라우저를 사용할 때, 브라우저는 기본적으로 "보안"을 최우선적으로 생각해요. 그래서 데이터를 주고받을 때, 다른 도메인 간 요청은 막는 게 기본이에요. 예를 들어, 브라우저는 서로 다른 두 웹사이트(도메인) 간 자기 마음대로 데이터를 주고받지 못하게 막죠. 이렇게 다른 도메인으로부터 오는 요청을 기본적으로 차단하는 보안 장치를 "Same-Origin Policy(동일 출처 정책)"라고 불러요. 그런데 특정 개발 상황에서는 이 보안 체계가 문제를 일으키는 거예요. 이게 우리가 흔히 "CORS 이슈"라고 부르는 거죠.

 CORS라는 단어를 처음 들어보는 사람도 있겠지만, 사실 이 문제는 웹 개발자라면 누구나 마주칠 수 있어요. 특히, REST API를 사용해서 백엔드와 프론트엔드가 데이터를 주고받아야 하는 환경이라면 100% 알아야 할 지식이죠. 예를 들면, 프론트엔드 개발자가 특정 서버에서 데이터를 불러오려고 하다가 CORS 에러를 맞닥뜨리는 경우가 많아요. 또 요즘은 클라이언트-서버 구조의 시스템이 많기에, 모바일 앱 개발자나 클라우드 서비스를 사용하는 개발자들도 이와 관련된 문제를 쉽게 마주해요. 심지어는 데이터 분석가도 외부 데이터를 끌어오는 작업 중 CORS 이슈를 겪을 수 있어요. 그래서 단순히 "내 문제가 아니야"라고 넘길 수 없는 내용이에요.

 

CORS란

CORS란 Cross-Origin Resource Sharing의 줄임말이에요. 다른 말로 하면, 서로 다른 출처(resource) 간에 데이터를 주고받도록 허용하는 기술이에요. 기본적으로 웹 애플리케이션은 동일한 프로토콜(https 혹은 http), 도메인(예: www.ex.com), 그리고 포트(예: 8080)가 같아야 데이터를 주고받게 설계돼 있어요. 만약 이 세 가지 중 하나라도 다르다면, 브라우저는 이 요청을 차단해요. 이유는 간단해요. 보안을 위한 조치예요. 하지만, 우리가 개발 환경에서는 종종 이런 상황이 필요하죠. 예를 들어, 도메인이 www.app.com인 사이트에서 데이터를 가져오려고 하는 프론트엔드가 www.api.com 서버에 요청을 보낼 때, CORS를 해결하지 않으면 에러가 발생하는 거죠. 이걸 컨트롤하기 위해 CORS라는 메커니즘이 등장했어요. 백엔드 서버에 적절히 설정만 해두면, 이런 문제를 해결할 수 있어요.

아래의 예시와 같이 프로토콜(https), 도메인(ex.com), 포트(:3000) 모두 동일해야 동일 출처라고 볼 수 있어요.

"동일 출처 = 프로토콜 + 도메인 + 포트"

https://ex.com ↔ https://ex.com	✅ 동일
https://ex.com ↔ http://ex.com	❌ 다름 (프로토콜)
https://ex.com ↔ https://api.ex.com	❌ 다름 (서브도메인)
https://ex.com ↔ https://ex.com:3000	❌ 다름 (포트)

 

 

CORS 해결법

CORS 문제를 해결해야 여러 출처 간 매끄럽게 데이터를 교환할 수 있어요. 클라이언트-서버 간 협업이 늘어나는 오늘날, API 요청이 원활하게 이루어질 수 있다는 건 대단히 중요한 일인데요. 하지만 백엔드 쪽에서 설정을 잘못할 경우, 보안 구멍이 생길 가능성이 있기에 주의해야 해요. 예를 들어서, 데이터를 요청할 때 아무 출처의 요청이나 무작정 허용하게 되면 해킹의 위험이 커질 수 있어요. 그래서 적절한 설정을 통해 사용 가능 출처를 제한적으로 허용하는 것이 필요해요. 즉, 편의성과 보안성 사이에서 균형을 맞추는 게 중요하죠.

 그럼, 실제로 어떻게 CORS 문제를 해결해야 할까요? 가장 기본적인 방법은 백엔드 서버에서 Response 헤더를 수정하는 거예요. 예를 들어, 특정 출처만 허용하려면 아래와 같이 설정하면 돼요.

• Access-Control-Allow-Origin: [허용할 도메인]
• Access-Control-Allow-Methods: GET, POST 등 요청 메서드
• Access-Control-Allow-Headers: Authorization 등 요청 헤더

어려울 필요 없죠? 그 외에도 로컬 개발 환경에서만 급하게 테스트해야 한다면, 브라우저에 플러그인을 설치하거나 프록시 서버를 활용할 수도 있어요. 이런 팁들은 단기적인 해결책으로는 유용하겠지만, 배포 단계에서는 가급적 권장되지 않아요. 본질적으로는 서버 레벨에서의 설정이 CORS 해결의 기본이예요!

 

 요약하자면, CORS 이슈는 웹 개발 보안과 관련된 장치지만 적절히 해결하지 않으면 개발 과정에서 큰 걸림돌이 될 수 있어요. 단기적인 해결책도 있지만, 무엇보다 중요한 포인트이자 장기적인 관점에서 서버에서의 꼼꼼한 설정이 핵심이예요.

 

웹소켓에서 CORS 이슈

이때, 들었던 궁금증 중 하나가 'http 통신이 아닌, 소켓 통신일 때는 CORS 이슈가 없을까?' 하는 건데요.

 그래서 찾아보니 소켓(Socket.IO 등 WebSocket 기반 통신) 방식에서도 CORS는 고려해야 해요. 다만 작동 방식이 HTTP 요청과 다르고, CORS가 적용되는 범위와 처리 방식이 다른 특징이 있어요. WebSocket은 최초 연결 시 HTTP 핸드셰이크를 사용하는데, ws:// 또는 wss://로 통신하기 전에 브라우저는 HTTP 요청을 먼저 보내요. 이 초기 핸드셰이크 요청이 다른 출처(origin) 일 경우, 브라우저는 CORS 정책에 따라 차단할 수 있게 돼요.

 

항목	일반 HTTP 요청 (REST API)	WebSocket
CORS 검사	브라우저에서 자동 처리 (OPTIONS 사전 요청 포함)	핸드셰이크 요청 시 Origin 헤더 기반 검사
OPTIONS 프리플라이트	O	❌ 없음
차단 시 증상	403 오류 + CORS 에러	WebSocket 연결 실패 (Error during WebSocket handshake)

 

실제로 대부분의 브라우저는 WebSocket의 Origin 헤더를 보내고, 서버 측에서 origin 검사 로직을 구현하지 않으면, 보안상 문제가 생길 수 있어요. *모든 도메인 허용 시, XSS, CSRF 등의 공격 위험에 노출될 있으니 CORS 정책이 느슨하더라도, Origin 검증은 보안 필수 요소예요.