🚀 클라이언트 측 vs 서버 측 CORS: 실제 차이점 이해하기

Source: Dev.to

모니터 앞에서 수수께끼 같은 CORS 오류 때문에 소리를 질러 본 적이 있다면…
축하합니다 — 이제 공식적인 웹 개발자입니다. 🎉

CORS는 마치 클럽 앞에 서 있는 엄격한 경비원과 같아서, 당신이 목록에 있다고 맹세해도 들어가지 못하게 합니다.

CORS가 실제로 뭔가요?

CORS는 Cross‑Origin Resource Sharing의 약자입니다 — 멋져 보이지만 실제 의미는:

“브라우저야, 이 웹사이트가 저 다른 웹사이트와 대화해도 될까? 아니면 낯선 사람 위험 상황인가?”

브라우저는 매우 편집증적입니다.
도메인 A가 도메인 B를 호출하면 브라우저는 이렇게 말합니다:

“잠깐. 누가 보냈어? 여권, 아다르 카드, PAN 카드, 그리고 2×2 사진 두 장 보여줘.”

클라이언트‑측 vs 서버‑측 CORS: 반전

사람들은 *“클라이언트‑측 CORS”*와 *“서버‑측 CORS”*를 얘기하지만, 진실은:

CORS를 결정하는 것은 오직 서버뿐입니다. 클라이언트는 허가를 요청하는 혼란스러운 청소년일 뿐.

양쪽 모두 역할을 하니, 이제 살펴보겠습니다.

클라이언트‑측 CORS (일명: 제어의 착각)

개발자들은 종종 이렇게 씁니다:

fetch("/api", { mode: "cors" })

그리고 브라우저가 이렇게 말해 주길 기대합니다:

“네, 알겠습니다! CORS가 활성화되었습니다! 당신은 천재군요!”

하지만 실제로 브라우저가 규칙을 집행합니다:

• mode: "cors" → “제발 들어가게 해 주세요!”
• mode: "no-cors" → “알겠어요, 떠날게요. 어차피 응답을 보고 싶지 않았거든요.”
• credentials: "include" → “쿠키 여기 있어요, 판단은 하지 말아 주세요.”

⚠️ 클라이언트는 CORS를 활성화할 수 없습니다. 요청만 할 수 있을 뿐이며, 키는 여전히 서버에 있습니다.

서버‑측 CORS (진짜 보스)

여기가 실제 마법이 일어나는 곳입니다. 서버가 당신의 오리진을 승인하지 않으면 브라우저가 요청을 차단합니다.

일반적인 응답 헤더:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

올바른 헤더를 받은 뒤에야 브라우저가 요청을 허용합니다.

예시 (Express.js)

const cors = require('cors');

app.use(cors({
  origin: "https://myapp.com",
  credentials: true
}));

예시 (Next.js API 라우트)

export default function handler(req, res) {
  res.setHeader("Access-Control-Allow-Origin", "https://myapp.com");
  res.setHeader("Access-Control-Allow-Credentials", "true");
  // ...요청 처리
}

헤더 하나라도 빼먹으면 CORS 오류가 발생합니다.

Simple vs Preflight 요청 (일명: 브라우저 드라마)

Simple 요청

이것들은 “편안함”을 의미합니다. 브라우저가 허용하는 경우:

• GET 또는 POST와 단순 헤더(Accept, Content-Type이 text/plain, multipart/form-data, application/x-www-form-urlencoded 중 하나인 경우)

Preflight 요청

다음 상황에서 발생합니다:

• PUT, PATCH, DELETE 같은 메서드 사용
• 커스텀 헤더
• JSON 바디(Content-Type: application/json)

브라우저는 먼저 OPTIONS 요청을 보내 서버에게 허가를 묻습니다. 서버가 올바르게 응답하지 않으면 실제 요청이 차단됩니다.

너무 빨리 스크롤한 천재들을 위한 요약 표

마무리 생각

CORS 오류는 마치 우주가 개인에게 공격을 가하는 듯한 느낌을 줄 수 있지만, 규칙은 간단합니다:

1. 클라이언트가 요청을 보냅니다.
2. 서버가 적절한 헤더를 보내 허용 여부를 결정합니다.
3. 브라우저가 그 결정을 강제합니다.

각 파트가 제 역할을 하면 CORS는 고통이 없습니다. 뭔가 잘못되면… 다음 몇 시간 동안 디버깅을 즐기세요. 😅