Postman에서는 CORS 오류가 발생하지 않는 이유 — 'Access-Control-Allow-Origin' 헤더 문제 완벽 해설

문제 상황

웹 브라우저에서 현재 페이지의 출처(Origin)와 다른 원격 서버로 네트워크 요청을 보내면, 대부분 CORS(Cross-Origin Resource Sharing) 오류가 발생합니다. 대표적인 메시지가 바로 "요청된 리소스에 'Access-Control-Allow-Origin' 헤더가 없습니다"라는 오류입니다.

그런데 흥미롭게도 동일한 API에 Postman 같은 도구로 요청하면 아무런 문제 없이 정상적으로 응답을 받을 수 있습니다. 왜 웹 브라우저에서는 실패하고 Postman에서는 성공하는 걸까요? 두 환경의 응답 동작 차이를 자세히 살펴보겠습니다.

핵심 원인: 동일 출처 정책(Same-Origin Policy)

웹 브라우저는 보안상의 이유로 동일 출처 정책(SOP, Same-Origin Policy)이라는 엄격한 규칙을 적용합니다. 현재 페이지가 로드된 도메인과 다른 도메인으로 요청을 보내려고 하면, 브라우저는 서버에 요청 자체를 전달하기도 전에 이를 차단합니다. 즉, 서버는 요청을 받지도 못했는데 브라우저 콘솔에는 CORS 오류가 표시되는 것입니다.

반면, 같은 출처(동일한 프로토콜, 도메인, 포트)를 가진 리소스에 대한 요청은 기본적으로 허용됩니다.

Postman은 왜 제약이 없을까?

웹 페이지는 XMLHttpRequest 객체나 fetch API를 사용해 원격 서버와 데이터를 주고받을 수 있지만, 앞서 언급한 동일 출처 정책의 제약을 받습니다. 이는 악의적인 웹사이트가 사용자 몰래 다른 사이트의 데이터에 접근하는 것을 막기 위한 필수적인 보안 장치입니다.

그러나 Postman은 웹 페이지가 아니라 데스크톱 애플리케이션(확장 프로그램)으로 동작하기 때문에 브라우저의 동일 출처 정책 적용을 받지 않습니다. 확장 프로그램은 자신의 출처와 무관하게 외부 원격 서버와 자유롭게 통신할 수 있는 권한을 가집니다.

정리

결국 CORS 오류는 서버의 문제가 아니라 브라우저가 클라이언트 측에서 응답을 차단하기 때문에 발생합니다. Postman은 브라우저 환경이 아니므로 이러한 검사 과정 자체가 없고, 따라서 'Access-Control-Allow-Origin' 헤더가 없어도 응답을 그대로 받아볼 수 있는 것입니다. 웹 애플리케이션에서 이 문제를 해결하려면 서버 측에서 적절한 CORS 헤더를 설정해 주어야 합니다.