처음 개발을 시작할 때 마주치는 가장 당혹스러운 오류가 바로 "CORS 정책에 의해 차단됨"이에요. 마치 뭔가 위법한 일을 저지른 것처럼 들리지만, 그렇지 않아요. 브라우저가 입장 명단을 확인하고 있을 뿐이에요.
이 오류가 머릿속을 녹이는 이유는, 메시지가 마치 당신을 탓하는 것처럼 보이는데 사실 그 규칙을 어긴 건 당신이 아니기 때문이에요. 프론트엔드와 백엔드로 상황을 정리해 볼게요. 앱에는 브라우저에서 실행되는 프론트엔드(식당 홀)가 있고, 다른 곳에 있는 백엔드(다른 사이트의 주방)에서 무언가를 가져오고 싶어 해요. 예를 들어 mysite.com이 api.othersite.com에서 데이터를 불러오려 한다고 해볼게요.
문지기와 입장 명단. 모든 백엔드에는 문지기가 있어요. 이 문지기는 브라우저 안에서 자신에게 말을 걸어도 되는 다른 사이트 목록을 들고 있어요. 프론트엔드가 api.othersite.com을 호출하려 하면, 브라우저는 조용히 그 문지기에게 먼저 다가가 물어봐요. "mysite.com이 명단에 있나요?"
- 명단에 있으면 통과되고 데이터가 돌아와요.
- 명단에 없으면, "CORS 정책에 의해 차단됨." 문 앞에서 돌려보내져요.
비로소 납득이 되는 반전이 있어요. 이걸 집행하는 건 브라우저이고, 그 이유는 당신을 보호하기 위해서예요. CORS는 Cross-Origin Resource Sharing의 약자인데, 지금 당장 잊어버려도 돼요. 모든 브라우저에 내장된 안전 규칙이에요. 이 규칙이 존재하는 이유는, 어느 탭에서 우연히 들어간 수상한 사이트가 당신이 이미 로그인해 있는 은행으로 조용히 요청을 보내지 못하게 막기 위해서예요. 브라우저가 당신의 경호원 역할을 하는 거예요. 다만 거절 메시지가 마치 당신이 용의자인 것처럼 표현될 뿐이에요.
CORS인지 확인하는 결정적 방법. 브라우저가 아닌 다른 무언가가 똑같은 호출을 했을 때 어떻게 되는지 확인해 보면 돼요. 에이전트가 그 API를 호출하거나 터미널에서 실행하면, CORS 오류 없이 데이터가 와요. 브라우저가 없으면 문지기도 없고 명단도 없어요. CORS는 순전히 브라우저의 규칙이에요. 터미널에서는 되는데 웹 앱에서는 안 된다면, 거의 항상 이 문제예요.
그리고 수정은 대부분 당신 쪽에서 하는 게 아니에요. 상대방 사이트가 자신의 입장 명단에 당신 사이트를 추가해야 해요. "mysite.com은 허용"이라고 명시하는 작은 설정이에요. 양쪽 모두 당신이 관리한다면 직접 추가하면 되고, 상대방 쪽을 관리하지 않는다면 표준적인 방법은 브라우저에서 직접 호출하는 대신 자신의 서버를 거쳐서 호출하는 거예요. 서버끼리 통신하면 문지기가 없거든요.
CORS는 당신을 벌하는 게 아니에요. 브라우저가 상대방 사이트의 문지기에게 당신이 명단에 있는지 묻는 것뿐이에요. 해결책은 명단에 추가되는 것이지, 문 앞에서 소리치는 게 아니에요.