학습 내용
Proxy
CORS 정책
CORS = 교차 출처 리소스 공유(Cross-Origin Resource Sharing)
추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.
브라우저에서 기본적으로 API를 요청할 때,
브라우저의 현재 주소와 API의 주소의 도메인이 일치해야만 데이터를 접근할 수 있게 되어 있다.
만약 다른 도메인에서 API를 요청해 사용하려면, CORS 설정이 필요하다.
하지만, React 라이브러리, 혹은 Webpack Dev Server에서 제공하는 proxy 기능을 사용하면 CORS 정책을 우회할 수 있다.
Proxy Server
프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.(위키백과 참조)
서버와 클라이언트 사이에 대리로 통신을 중계한다.
기능
보안
클라이언트에서 특정 URL로 HTTP 요청을 서버에 보낼 경우,
서버에 주소가 쉽게 노출된다.
외부 사용자가 서버로 접근하기 쉬워지게 된다.
프록시 서버를 거쳐서 서버에 HTTP 요청을 보내면,
외부 사용자가 서버의 위치를 알아내기 어렵다.
즉, 서버의 IP를 숨기는 것이 가능하고 이는 외부로부터 위험을 막아주는 역할을 한다.
*서버에 접근하는게 왜 위험한가?
만약 실제 서비스에서 서버에 중요한 정보(개인정보 등)가 있으면,
사용자들의 개인정보가 노출되므로
아무도 그 앱을 사용하지 않을 것이다.
캐시
프록시 서버 중 일부는
프록시 서버에 요청된 내용들을 캐시를 이용하여 저장한다.
만약 클라이언트에서 서버로 새로운 요청을 보냈는데,
캐시에 저장한 데이터는 서버에 다시 요청하지 않고,
캐시에서 클라이언트에 바로 전달한다.
즉, 원격 서버에 접속하여 데이터를 가져올 필요가 없게 된다.
이는 불필요한 네트워크 요청을 감소한다.
따라서, 전송 시간을 절약할 수 있게 되고,
네트워크 병목 현상을 방지하는 효과도 얻는다.
그럼 캐시란 무엇일까?
컴퓨터 과학에서 캐시는 "데이터나 값을 미리 복사해 놓는 임시 장소"를 가리킨다.
캐시는 언제 사용?
- 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸릴 경우
- 값을 다시 계산하는 시간을 절약하고 싶은 경우
왜 사용?
- 시스템의 효율성을 위해 사용한다.
(캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간없이 더 빠른 속도로 데이터에 접근할 수 있다)
더 빠른 속도로 데이터 접근 -> 더 적은 시간 소모
React Proxy
설명
React 앱 개발 시, API 서버와 통신을 가능하게 해주는 라이브러리이다.
React 앱 개발 단계에서는, 로컬 환경에서 React 앱을 실행한다.
-> API 서버와 통신이 필요할 경우가 있다.
-> 이 때, CORS 에러가 종종 발생한다.
왜? 보통 localhost:3000 에서 프론트엔드 기능 개발을 하는데,
보안 상 이 주소에서 서버로 접근하지 못하도록 막기 때문이다.
왜? localhost:3000 에서 접근이 가능하게 하면, 누구나 접근할 수 있을 것이다.
-> 이 문제를 해결하기 위해, React Proxy를 사용한다.
React Proxy를 사용하면, CORS 정책을 우회한다.
동작 방식
Proxy 적용 전
Front End <-> Browser <-> Back End
1. Front End 에서 Browser로 HTTP 요청
2. Browser 에서 Server에 접근 권한 있는지 확인
3. Back End 에서 Browser로 응답
4. Browser에서 Front End로 응답 파기 여부 결정(CORS 에러)
Proxy 적용 후
- Front End 에서 Browser로 HTTP 요청
-- proxy -- - Proxy를 통해 Server에 우회 요청
- Proxy를 통해 Client에 우회 응답
- Front End 에서 받은 응답을 Browser에 전달(CORS 에러 X)
Proxy를 설정해 HTTP 통신하기
종합 퀴즈
워터폴(Waterfall) 개발 방식
-
시스템 테스트는 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인한다. 만약 요구사항을 만족하지 않는다면 다시 요구분석 단계로 돌아가 새로 개발을 하기도 한다.
-
베타 테스트는 고객의 실제 사용 환경에서 수행되는 테스트이다.
미리 선별된 유저들이 해당 제품을 사용해 보는 테스트 방법이다. -
테스팅 단계에 이르러서 이슈가 발견되는 경우가 왕왕 생긴다.
지속적 통합(Continuous Integration)
- 개발자들은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합한다(지속적 통합).
이 때, 기본적인 테스트도 작동시킬 수 있으므로,
이러한 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 테스트 해볼 수 있다.
지속적 배포(Continuous Delivery/Deployment)
- 이 프로세스를 완료하면 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 된다.
- Release - Deploy - Operate 단계에서 꾀할 수 있다.
- 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화한다.
- 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로,
테스트 자동화와 코드 릴리스 자동화도 포함된다.
YAML에 대한 설명
- YAML 파일은 "" (큰따옴표) 없이 문자열 작성이 가능해,
설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한 눈에 들어온다. - JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박에서 벗어날 수 있다.
- YAML을 JSON으로 변환해 사용할 수 있다.
- YAML 파일은 JSON 파일과 다르게 주석을 작성할 수 있다.
JSON 파일은 주석을 작성할 수 없기 때문에,
해당 파일 하나만 두고 커뮤니케이션 하기 까다롭다.
하지만, YAML 파일은 애초에 파일 내에 주석을 작성할 수 있기 때문에,
커뮤니케이션 하기가 훨씬 수월하다.
CORS 정책에 대한 설명
- 웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의된다.
두 객체의 스킴, 호스트, 포트가 모두 일치하는 경우 같은 출처를 가졌다고 말한다.
proxy에 대한 설명
- proxy를 사용해 CORS 정책을 우회하여 백엔드 서버는 응답을 React 앱으로 보내고,
React 앱은 받은 응답을 백엔드 서버 대신 브라우저에게 전달하기 때문에,
출처가 같아지게 된다.
질의응답
질문: React proxy 사용하는 이유
- 실제 배포할 때는 쓰지 않는다고 하셨는데, 개발 단계에서만 사용하나요? Yes.
- React proxy의 주 목적은 React 앱 개발 시 cors 에러 없이 API와 통신하기 위해서 인가요? Yes.
- proxy 서버의 기능과 기대 효과가 아래와 같은데, 개발 단계에서 이 기능이 꼭 필요한가요?
클라이언트 ip 숨김 -> 보안 강화
캐시에 데이터 저장 -> 네트워크 요청 감소 -> 전송시간 절약
Yes.
답변
상황: 이미 상용화된(배포) 서비스가 있음. 프론트엔드 기능을 추가해야 함.
배포된 API 서버는 http://localhost:3000/ 에서 접근하지 못하도록 막을 것이다. 보안 상 이유로.
왜? localhost:3000의 접근을 허용하면, 누구나 접근이 가능할 것이다.
하지만, 프론트엔드 기능 개발 시, local에서(localhost:3000) 개발한다.
즉, 프론트엔드 개발자들이 localhost:300에서 접근할 수 있는 방법이 필요하다.
이 때 사용하는게 React Proxy이다.
Proxy 서버와 React Proxy
Proxy 서버: 클라이언트와 서버의 간접적 통신을 돕는 응용 소프트웨어.
React Proxy: React 개발 서버에서 다른 서버와 통신을 돕는 proxy 서버를 설정해주는 라이브러리(툴)
