CORS란, 출처가 다른 자원들을 공유한다는 뜻으로, 출처에 있는 자원을 다른 출처에 있는 자원으로 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 것을 말합니다.
요청을 보내기 위해선, 요청 보내는 대상과 프로토콜이 같아야하고, 포트와 도메인이 같아야합니다.
이를 해결하기 위해선 특정 HTTP 헤더를 추가하여 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하여 이슈를 해결할 수 있습니다.
[정리]
CORS란, 출처가 다른 자원들을 공유한다는 뜻으로, 다른 출처에 있는 자원으로 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 것을 말합니다.
만약 CORS가 없다면 다른 사이트가 현재 사이트를 똑같이 모방할 수 있고, 이로 인해 개인 정보 추출과 같은 공격을 받을 수 있기 때문에, 브라우저를 보호하고 필요한 경우에만 서버와 협의하여 요청할 수 있도록 하기위해 CORS가 필요합니다.
요청을 보내기 위해선 브라우저상 동일 출처 리소스 공유 원칙으로 보내는 대상과 프로토콜이 같아야하고, 포트와 도메인이 같아야합니다.
만약 API주소와 홈페이지 도메인이 다를 경우 즉, 프론트와 서버간 통신시 서버와 프론트의 도메인이 다를경우 통신이 안되는 이슈가 발생하며, 이것을 CORS 이슈라고 합니다.
이를 해결하기 위해서는 서버에서 특정 도메인을 헤더를 통해 열어줘야하며 모든 도메인을 열어줄경우 보안에 문제가 발생하여 주의해야합니다.
cross-origin
이란 다음 중 하나라도 다른 경우를 말합니다.
프로토콜 : http, https는 프로토콜이 다르다
도메인 : domain.com과 other-domain.com은 다르다
포트번호 : 8080포트와 3000 포트는 다르다.
CORS없이 모든 곳에서 데이터를 요청하게되면, 다른 사이트에서 원래사이트를 똑같이 흉내낼 수 있게됩니다.
그렇게하면 사용자가 원래 사이트와 동일한 다른 사이트에서 로그인하게되고, 로그인하게되면, 악의적으로 사용자의 정보를 추출하는 것처럼 공격받을 수 있습니다.
이렇게 공격받지 못하도록 브라우저에서 보호하고, 필요한 경우에만 서버와 협의하여 요청할 수 있도록 하기 위해 CORS가 필요합니다.
브라우저는 HTML, CSS 명세에 따라 HTML 파일을 해석해서 표시합니다.
먼저, 렌더링엔진은 HTML문서를 파싱해서 DOM트리를 구축합니다.
그리고나서 CSS 마크업을 파싱해서 앞에서 구축한 DOM트리와 함께 렌더링 트리를 만듭니다.
렌더링 트리는 화면에 보여줄 것들만 가지고 있기 때문에, 구축이되면, 순차적으로 화면에 배치합니다.
부모에서 자식 순서로 배치가되고, 배치 후 그리기를 시작합니다.
script파일을 body tag 가장 아래 위치시키거나, 혹은 불필요한 무거운 파일들을 제한하면 됩니다.
모두 데이터 저장소의 역할을 하지만,
로컬 스토리지의 경우 저장한 데이터를 지우지 않는 이상 영구적
으로 데이터를 보관합니다.
세션 스토리지의 경우, 브라우저를 닫는 것처럼 세션을 종료하면, 정보가 삭제됩니다.
쿠키의 경우, 다른 저장소와 비교하면, 용량도 작고 암호화되어있지 않아 정보가 유출될 수 있습니다. 또한, 웹사이트에 쿠키를 설정하면, 모든 웹 요청에 쿠키 정보가 포함되어있어 서버에 부담이 증가합니다. 이를 보완하고자 로컬스토리지와 세션스토리지가 나왔습니다.
-> 다시
쿠키는 만료기한이 있으며 간단한 사용자의 정보를 기억할 수 있습니다. 그러나 용량이 작기때문에 팝업창 다시보지 않음과 같은 기능에 적합합니다. 또한, 암호화되어있지 않아 사용자의 정보가 도난당할 수 있고 모든 웹 요청에 쿠키 정보가 포함되어 서버에 부담이 증가한다는 단점이 있습니다.
이를 보안하고자 로컬스토리지와 세션 스토리지가 나왔습니다.
로컬 스토리지의 경우 저장한 데이터를 지우지 않는 이상 영구적
으로 데이터를 보관합니다. 따라서 자동로그인 기능에 적합합니다.
세션 스토리지의 경우, 브라우저를 닫는 것처럼 세션을 종료하면, 정보가 삭제됩니다.
따라서 비로그인 장바구니나 상세페이지에서 리스트페이지로 되돌아갈때 페이지 값이 이전과 같게 유지하고 싶을지 사용하면 좋습니다.
서버사이드 렌더링은 서버측에서 렌더링하는 방식으로, 기존에 존재하던 방식입니다.
사용자가 브라우저를 통해 주소창에 요청하면, 해당 주소에 있는 서버에서 컨텐츠를 전부 취합하여 HTML
로 만든 뒤 응답하여 보내줍니다.
클라이언트사이드 렌더링은 클라이언트 측에서 렌더링을 하는 방식으로, 클라이언트가 처음 한 번 HTML
, CSS
, JS
만 다운하여 서버에서 전체 페이지를 로딩해서 보여줍니다.
이후 사용자의 요청이 있으면 그 부분만 서버가 JSON
파일을 제공해서 보내줍니다.
클라이언트는 서버가 보내준 JSON파일을 해석한 뒤, HTML
을 그리는 역할을 JS
에서 수행해서 렌더링합니다. 따라서 초기속도가 서버사이드 렌더링보다는 조금 느리다는 단점이 있습니다.
렌더링 엔진은 HTML을 한줄씩 차례대로 내려가면서 파싱하여 DOM을 생성합니다.
이때 만약 JS를 만나면 DOM생성을 일시적으로 중단하고, JS코드를 파싱하기위해 JS엔진에게 제어권을 넘깁니다.
JS파싱이 끝나면 다시 제어권을 넘겨받아 중단된 부분부터 다시 HTML 파싱을 재시작하여 DOM트리를 생성하기 때문에 중간에 렌더링이 멈춥니다.
저는 마지막 프로젝트에서 github actions을 이용해 파이프라인을 만들었는데, CI/CD는 지속적인 통합과 자동 배포를 말합니다.
CI
는 애플리케이션에대한 새로운 변경이 있을 경우, 자동으로 변경된 부분을 빌드하고 테스트하여 통합하는 것을 말합니다.
만약, CI를 사용하지 않는다면, 새로운 변경사항이 발생할때 충돌할 수 있고, 이로인해 서비스 장애를 불러 일으킬 수 있기 때문에, 자동으로 작업하고 결과만 개발자에게 알려주는 CI를 사용하는 것이 좋습니다.
CD
는 애플리케이션을 자동으로 배포하는 것을 말합니다.
CI에서 Build되고 Test된 후, 배포 준비가 되자마자 자동화하여 배포하는 것을 말합니다.
github와 같은 저장소를 사용해서 소스 코드를 관리할 경우, AWS에 호스팅 서비스를 배포하면 자동으로 배포해주고 개발자에게 알려줍니다.
크로스 브라우징은 웹 표준에 따라 서로 다른 OS 나 플랫폼에 대응하는 것을 말합니다.
브라우저별 렌더링 엔진이 다른 상황에서도 문제없이 동작하게하는 것을 목표로 합니다.
attribute는 HTML 텍스트 문서에 있고 초기값을 전달하기 때문에 변하지 않습니다.
property는 attribute에 대한 HTML DOM트리안에서의 표현이며 변할 수 있습니다.
document type 약자로 웹 문서가 어떤 HTML 버전으로 작성되어있는지 미리 선언해서 웹 브라우저가 내용을 올바르게 표시할 수 있도록 해주는 것입니다.
none, flex, inline, inline-block, block, grid가 있습니다.
문서 상에 요소를 배치하는 방법으로 relative, absolute, fixed, sticky등이 있습니다.
SASS와 SCSS는 CSS를 편리하게 사용할 수 있도록 하며 추가 기능이 있는 스크립트 언어입니다.
SCSS는 중괄호, 세미콜론 형식으로 되어있습니다.
SASS는 들여쓰기와 줄바꿈 형식으로 되어있습니다.
장점으로는 모듈화할 수 있고, 변수화할 수 있으며 중첩화할 수 잇어 코드의 가독성또한 좋습니다.
flexbox는 flex-direction을 통해 축의 방향을 바꾸며 기본적으로 수평/수직 중 한 방향으로만 레이아웃을 나눌 수 있습니다.
주로 list items들을 수평으로 레이아웃을 만들때 사용했습니다.
HTML
한 줄씩 차례대로 아래로 내려가면서 파싱하여 DOM을 생성합니다.
근데 만약 중간에 JavaScript를 만나면 DOM생성을 임시적으로 중단하고 JavaScript 코드를 파싱하기 위해서 JavaScript 엔진에게 제어권을 넘깁니다.
JavaScript 파싱이 끝나면 다시 제어권을 넘겨받아 중단된 부분부터 다시 HTML 파싱을 재시작하여 DOM 트리를 생성하기 때문에 도중에 렌더링이 멈추는 것입니다.
시맨틱 마크업이란 태그가 의미를 잘 전달하도록 작성하는 것입니다.
즉, 태그를 그 용도에 맞게 사용하는 것으로 예를들어, header나 footer부분을 header, footer라는 네이밍으로 사용.
혹은 내비게이션에
(CSS in JS는 자바스크립트 코드에서 CSS를 작성하는 방식으로 라이브러리는 styled components를 사용한다.)
개인적으로 사용했을 때 가장 큰 장점은 조건문이나 반복문, 간단한 연산 등을 할 수 있어서 CSS를 마치 프로그래밍 하듯이 코딩할 수 있다는 장점이였던 것 같습니다.
따라서 조건에따라 색을 변경한다던가 사진을 변경한다던가 할 수 있었습니다.
또 다른 장점으로는 랜덤 문자열로 이루어진 클래스명을 만들어 컴포넌트끼리 확실하게 분리하기때문에 컴포넌트 단위로 생각할 수 있습니다.
단점은 css in css보다 처음에 배울때 조금 어려웠습니다.
간단한 폰트적용도 꽤 검색해야해서 처음 배울때는 조금 어려웠지만, 적응하고나니 앞서 말씀드린 장점들때문에 더 자주 사용하고 있습니다.
또 다른 단점으로는 css in Js는 라이브러리를 사용하기 때문에 라이브러리 추가는 곧 번들 사이즈가 증가함을 의미합니다. 이렇게되면, 다운로드 시간이 오래 걸리기 때문에, 사용자 경험에 치명적입니다. 하지만 이 부분에 관해서는 규모가 작은 프로젝트에서 사용해봐서 아직 직접 경험해보진 못했습니다.