Promise ~ 웹 서버 기초 (기술면접)

👉 JavaScript

❓ Promise의 기능과 필요한 이유에 대해서 설명해주세요.

Promise는 JavaScript에서 비동기 처리에 사용되는 객체입니다.

기존에 사용하던 CallBack 방식에서 에러/예외 처리의 어려움, 그리고 CallBack 함수가 중첩되어 있는 경우 가독성이 떨어지던 CallBack Hell의 단점을 보완하기 위해 ES6에서 등장했습니다.

Promise는 생성되고 종료될 때 까지 Pending(대기), Fulfilled(이행), Rejected(실패) 세 가지의 상태를 가지며 Fullfilled 상태가 되면 then()을 이용해, Rejected 상태가 되면 catch()를 이용해 다음의 행동을 처리할 수 있도록 하여 앞선 문제들을 보완했습니다.

순수함수란 무엇인가요? 불변성과 사이드 이펙트와 연결하여 설명해주세요.

순수함수란 같은 입력 값을 받았을 때, 항상 같은 출력을 반환하며 Side Effect를 가지지 않는 함수를 말합이다.

함수 내에서 어떤 구현이 함수의 외부 상태나 값에 영향을 끼치는 경우, 해당 함수는 Side Effect가 있다고 이야기 합니다. 즉, 순수 함수는 이러한 Side Effect를 초래하지 않고 어떠한 외부 상태도 변환하지 않는 불변성을 가진 함수입니다.

순수 함수는 같은 입력에 대한 값을 예측 가능한 함수이고, 외부 상태로부터 완전히 독립적이기 때문에 변화하는 상태들에 관련된 버그로부터 완전히 면역이 있습니다. 함수 body 내에 있는 코드만 점검하면 되기 때문에 리팩토링과 재구성도 쉽다는 장점도 가졌습니다.

따라서 순수 함수를 이용하여 구현할 수 있는 프로그램이라면, 순수 함수를 사용하는 것이 좋습니다.

👉 React

React의 state와 props에 대해서 설명해주세요.

props란 컴포넌트의 속성을 설정할 때 사용하는 요소이며, 부모 컴포넌트에서 자식 컴포넌트로만 전달이 가능합니다. props는 전달받는 컴포넌트 내에서 수정이 불가능하며 읽기 전용으로만 사용할 수 있습니다.

state는 컴포넌트 내부에서 바뀔 수 있는 상태 값을 의미하며, 컴포넌트에서 스스로 관리할 수 있는 값입니다. state가 변경되면 컴포넌트의 리 렌더링을 발생시킵니다.

부모 컴포넌트의 상태를 자식 컴포넌트가 변경하고 싶다면, 부모 컴포넌트에서 props로 상태를 변경하는 함수를 전달하고 자식 컴포넌트에서 그것을 호출하여 부모 컴포넌트의 상태를 변경할 수 있습니다.

React 컴포넌트의 key 속성에 대해서 설명해주세요.

리액트는 컴포넌트의 상태나 속성이 변할 때마다 render()함수를 호출하는데, 이 때 render()함수는 새로운 리액트 요소 트리를 반환하고 이를 기존의 요소 트리와 비교해 새로운 변경점에 대해서만 재렌더링을 수행합니다.

여기서 기존 요소들 뒤에 새로운 내용을 추가할 경우 새로운 부분에 대해서만 재렌더링 되지만 새로운 요소를 기존요소 앞에 추가할 경우 모든 부분이 재렌더링 됩니다. 바로 이런 상황을 최적화 하기 위해 key 속성을 사용합니다.

각 요소에 key 속성을 부여하면 더 이상 모든 요소를 렌더링하지 않고 추가된 부분만 재렌더링 하는 효율적인 렌더링을 시도합니다.

useEffect의 dependency array에 대해서 설명해주세요.

useEffect란 컴포넌트 내에서 Side Effect를 실행항 수 있게 하는 Hook입니다.

useEffect를 사용할 때는 두 가지 인자가 필요합니다. 첫 번째 인자에는 콜백 함수, 그리고 두번째 인자에는 배열을 받는데 이 배열을 바로 dependency array, 종속성 배열이라고 합니다.

useEffect는 화면이 처음 렌더링 될 때, 그리고 종속성 배열 안에 있는 value의 값이 바뀔 때마다 실행되게 됩니다.

만약 종속성 배열을 입력하지 않는다면 컴포넌트가 새롭게 렌더링 될 때 마다 useEffect 함수가 작동되게 되고, 빈 배열을 입력할 경우 첫 렌더링에 한 번만 실행됩니다.

👉 HTTP/네트워크

CSR과 SSR의 차이점에 대해서 설명해주세요.

웹 페이지를 클라이언트와 서버 중 어디서 렌더링하느냐에 따라 SSR과 CSR로 나뉘게 됩니다.

CSR은 클라이언트에서 웹 페이지를 렌더링합니다. 만약 서버로 요청이 들어오면 SSR과 다르게 완성된 웹 페이지가 아니라 뼈대가 되는 단일 페이지(Single Page)와 자바스크립트 파일을 응답으로 보냅니다. 응답을 받은 후 브라우저에서 이 단일 페이지와 JS 파일로 동적으로 HTML을 생성해 웹 페이지를 렌더링하는 과정을 거쳐 사용자에게 화면을 보여주게 됩니다.

따라서 사용자가 첫 화면을 보기까지 비교적 오랜 시간이 걸리게 된다는 단점이 있습니다. 또, 브라우저가 서버에서 받아오는 최초의 HTML 파일은 거의 데이터가 들어있지 않은 파일이기 때문에, 서버에 등록된 웹 사이트들을 돌아다니면서 HTML 문서를 분석하고 판단하는 검색 엔진이 해당 페이지를 분석하기 어렵다는 단점이 있습니다.

SSR은 이러한 CSR의 문제점으로 인해 도입되게 되었습니다. SSR은 웹 페이지를 서버에서 렌더링합니다. 만약 서버로 요청이 들어오면 서버는 데이터를 불러와 웹 페이지를 완전히 렌더링 된 페이지로 변환 후 클라이언트에 응답을 보냅니다.

따라서 첫 번째 페이지의 로딩이 빠르고, 모든 콘텐츠가 문서 안에 담겨져 있기 때문에 좀 더 효율적인 검색 엔진을 기대할 수 있습니다. 하지만 SSR은 초기 정적 웹 사이트에서 발생했던 깜빡임 이슈가 존재해 CSR에 비해 좋지 않은 사용자 경험을 제공한다는 단점이 있습니다.

GET 메서드와 POST 메서드의 차이점에 대해 설명해주세요.

웹에서 정보나 리소스를 요청할 때는 HTTP프로토콜을 사용하며 요청의 목적에 따라 다른 HTTP 메서드를 사용합니다.

GET 메서드는 특정 리소스를 수정하지 않고 조회하거나 받아와야 할 때 사용합니다.

반면 POST 메서드는 특정 리소스를 추가할 때 주로 사용하며 GET메서드와는 다르게 추가할 내용을 담은 요청 body가 필요합니다. POST는 데이터를 추가하기 때문에 서버의 리소스에 영향을 줄 수 있으므로 처리시 신중해야 합니다.

👉 웹서버 기초

HTTP 메세지 구조에 대해 설명해주세요.

HTTP 메시지의 구조는 크게 헤더와 바디로 나뉩니다. HTTP 메시지에는 요청과 응답 두 가지 유형이 있는데 둘 다 조금씩 차이가 있으나 유사한 구조를 가지고 있습니다.

먼저 헤더에는 start line과 HTTP headers가 있습니다. start line은 응답시 status line이라고도 하며 항상 첫번 째 줄에 위치하여 요청이나 응답의 상태를 나타냅니다.

HTTP headers에는 요청을 지정하거나, 메시지에 포함된 본문을 설명합니다. 그 다음 헤더와 본문을 구분하는 빈 줄인 empty line이 있습니다. 마지막으로 body는 payload라고도 하며 요청 및 응답과 관련된 데이터, 문서를 포함합니다. 이 바디는 선택적으로 사용합니다.

Same-Origin Policy와 CORS에 대해서 설명해주세요.

SOP와 CORS는 모두 브라우저의 보안 관련 정책입니다.

SOP, 동일 출처 정책은 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용 하는 것을 제한하는, 한마디로 “같은 출처의 리소스만 공유 가능하고, 동일한 출처로만 요청을 보낼 수 있다”는 정책입니다.

이 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 XSS, CSRF 등의 공격을 받을 수 있는 경로를 줄여주는 아주 기본적인 보안 정책입니다. 하지만 웹에서는 다른 출처에 있는 리소스를 가져와서 사용하는 일이 아주 흔하기 때문에, 몇 가지 예외 상황에 대래 다른 출처로도 요청을 보낼수 있도록 허용합니다. 그 예외 상황 중 하나가 CORS 요청을 지킨 리소스 요청입니다.

CORS는 교차 출처 리소스 공유입니다.

브라우저에서는 보안의 이유로 cross origin http요청들을 제한하는데 cross origin요청을 하려면 서버의 동의가 필요합니다. 만약 서버가 동의할시 브라우저에서는 요청을 허락하고 동의하지 않는다면 브라우저에서 거절합니다.

이렇게 허락을 구하고 거절하는 메커니즘을 http-header를 이용하는데 이를 CORS라고 합니다.

예를 들어, Access-Control-Allow-Origin 등의 추가 HTTP 헤더를 사용하여 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할수 있는 권한을 부여하도록 브라우저에 알려주는 역할을 합니다.

CORS는 브라우저와 서버 간의 안전한 교차 출처 요청 및 데이터 전송을 지원하기 때문에 보안 문제를 예방하고 허용하는 Origin만 요청할 수 있습니다.