CORS를 정책 위반 없이 해결한 방법: Proxy 패턴 적용기
서론
이번 글에서는 대학 프로젝트에서는 경험 못해봤던 실무 환경에서의 CORS 문제 해결 사례를 공유하려 합니다. 대학 시절에는 단순히 서버의 보안 설정을 수정해 CORS 에러를 해결하곤 했지만, 이번에는 보안 정책을 지키면서도 안정적으로 외부 API와 통합한 실무 경험을 다루고자 합니다.
대학 프로젝트 때는 CORS 문제가 생기면 “그냥 허용해 주세요”라며 설정을 변경하곤 했습니다. 하지만 기업 환경에서는 정책상 CORS를 풀 수 없는 경우가 많습니다.
그렇다면 이런 상황에서는 어떻게 해야 할까요? 제가 최근 업무에서 실제로 겪고 해결한 방법을 말씀드려보겠습니다.
오랜만에 보는 CORS 에러
간편 회원가입 페이지를 개발하던 중, 타 부서에서 제공하는 회원가입 API를 브라우저에서 직접 호출하려 했습니다. 하지만 호출을 해보니 익숙한 에러 메시지가 등장했는데요 바로 CORS error 였습니다.
처음에는 “API 제공 부서에 CORS 허용을 요청하면 되겠지?”라고 생각했지만, 돌아온 답변은 단호했습니다. “정책상 불가합니다.” 그 순간, 대학 프로젝트와 실제 서비스 환경의 차이를 실감했습니다.
학생 시절에는 요청만 하면 열어주던 CORS 설정이, 실무에서는 정책적으로 제약된 영역인것입니다.
사실 이런상황은 상상을 해 본적이 없었습니다. 항상 풀어달라면 풀어줄 수 있는 프로젝트에서는 이런 상황을 고려 못해보았던 것입니다.
Browser 대신 Server가 대신 호출: Proxy 패턴
당황하고 있던 저에게 선배 개발자가 명쾌한 조언을 해주셨습니다.
“브라우저에서 직접 호출하지 말고, 우리 서버가 대신 호출하도록 하자.”
즉, 서버 사이드에서 API 요청을 중계(Proxy)하도록 구현하는 방법입니다. 이 방법은 시스템 디자인 패턴 중 하나인 Backend-for-Frontend(BFF)로 볼 수도 있습니다.
저는 다음과 같은 흐름으로 간단한 중계 API를 구현했습니다.
- 클라이언트(브라우저)는 이제 내 서버의 API를 호출
- 내 서버가 내부적으로 타 부서 API 호출
- 응답을 클라이언트에 그대로 전달
이 과정을 통해 CORS 제약을 우회하면서도 정책을 준수하는 시스템을 구현할 수 있었습니다.
후기
겉보기에는 단순한 문제였지만, 저에게는 큰 의미가 있었습니다. 그동안 저는 “이 정도면 되겠지”라는 막연히 낙관적으로 개발하곤 했습니다.
하지만 이번 경험을 통해, 근거 없는 가정보다는 다양한 상황을 미리 고려하며 개발해야 한다는 교훈을 얻었습니다.
이 글이 비슷한 상황을 겪는 분들께 작은 도움이 되었으면합니다. 다음에는 더 가치가 있는 글을 가져오도록 노력해보겠습니다. 읽어주셔서 감사합니다. 😊