코드스테이츠 섹션2 기술면접 예상질문

개요

• 섹션 2를 마무리하며 학습했던 내용들에 대해 기술면접에 나올만한 질문들에 답변을 준비하며 복습합니다.

---

학습 목표

• 프론트엔드 개발자 기술 면접에 대해서 이해합니다.
• 기술 면접에서 요구하는 올바른 답변이 무엇인지 이해합니다.
• 기술 면접 준비를 직접 해봅니다.
• 모의 기술 면접을 실제 해보거나 시청하면서, 어떻게 기술 면접을 할지 고민해봅니다.

---

JavaScript

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

// 정의 및 기능

"Promise 는 단어 그대로 '약속'입니다. "
"비동기 연산이 종료된 이후에 결과를 제공하겠다는 '약속'입니다."
"Promise 가 미래에 제공하는 결과로는 실패 혹은 완료와 그 결과 값을 나타냅니다."

"또, Promise 를 사용하면 비동기 메서드가 마치 동기 메서드처럼 값을 반환할 수 있습니다."
"Promise 에 처리기를 연결하면 결과값, 실패 사유 등을 처리할 수 있게 됩니다."

// 필요한 이유

"Promise 는 비동기 작업시에 결과를 제공받기위해 필요합니다."

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

// 순수함수란?

"순수함수란, 오직 함수의 입력만 함수의 결과에 영향을 주는 함수입니다."

// 사이트 이펙트와 연결

"따라서, 사이드 이펙트가 없는 예측 가능한 함수입니다."

// 불변성과 연결

"메모리에 이미 담긴 데이터를 변경하지 않는다는 뜻입니다."
"메모리에 이미 단긴 데이터가 변경되면 사이드 이펙트가 발생할 수 있기 때문입니다."

"따라서 메모리에 이미 담긴 데이터를 업데이트 하고 싶을 시에는 새로운 변수 혹은 객체를 선언하여 할해당 데이터를 할당하는 것이 불변성에 합당한 방식입니다."

---

React

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

// state

"'상태', 즉 컴포넌트 내에서 변할 수 있는 값입니다."

"토글, 체크박스, 인풋밸류 등에서 대표적으로 쓰입니다."

"React 에서 제공되는 useState() Hook 또는 외부 상태관리 라이브러리를 사용하여 관리합니다."

// props

기본적으로 리액트에서는 setState만을 사용하여 state를 변경하게 한다. 이는 상태가 변경될 때 리액트에게 리렌더링을 하라는 명령을 요청하기 위함이다. 즉, setState는 리액트에게 상태가 변경되었으니 리렌더링을 하라는 트리거이다. 그렇기때문에 props를 단순하게 할당연산자로 변경하는 경우 setState를 사용하지 않았기 때문에 props가 바뀌었음에도 불구하고 리액트가 상태가 변경됐는지 알아채지 못해 리렌더링을 하지 않는다. 만약 부모 컴포넌트의 state를 자식 컴포넌트에서 변경하고 싶다면 state 끌어올리기를 사용하면 된다. state 끌어올리기는 부모 컴포넌트의 state를 변경하는 함수(setState)를 자식 컴포넌트에게 props로 넘겨 자식 컴포넌트에서 부모의 state를 변경하게 하는 것이다.

 

"'변하지 않는 값'이면서 '부모 컴포넌트에서 전달 받은 값'입니다."

"어떤 타입의 값도 할당하여 전달할 수 있도록 '객체 형태'입니다."
"그리고 '읽기 전용 객체'입니다."

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

// 컴포넌트의 key 속성

"리액트는 컴포넌트의 key 프로퍼티 값이 변하면 새로운 요소로 인식합니다."
"즉, 리액트는 key 프로퍼티 값을 기준으로 각 컴포넌트들을 인식합니다."

"따라서 컴포넌트의 key 프로퍼티 값을 state 로 주게되면 상태변화를 통해 여러개의 컴포넌트가 있는 것 같은 효과를 줄 수 있습니다."
"대표적으로 Motion UI 에서 key 값을 state 로 주고 Slider 를 구현합니다."

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

// useEffect 의 dependency array

"useEffect 는 디펜던시 어레이의 요소에 해당하는 상태가 변경될때 마다 실행됩니다."

"예를들어, 디펜던시 어레이가 inputValue 라는 상태를 요소로 가지고 있다고 했을때, setInputValue 를 통해 inputValue 가 변경될 때마다 useEffect 내부에 있는 함수를 실행시켜줍니다."

"디펜던시 어레이가 비어있는 경우는 해당 컴포넌트 첫 렌더링 시에만 실행됩니다."
"디펜던시 어레이가 아예 없느 경우는 모든 상태가 변경 될때, 렌더링 될때마다 실행됩니다."

---

HTTP/네트워크

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

// '어디서' '렌더링'을 하느냐?

"웹사이트가 그려지는 과정인 '렌더링'을 '어디서' 하느냐의 차이가 있습니다."

"SSR 은 서버(백엔드) 에서 렌더링을 수행합니다." 
"CSR 은 클라인트(브라우저;프론트엔드) 에서 렌더링을 수행합니다."

// 각각의 장점

"SSR 은 SEO 와 첫 화면 렌더링 속도의 장점이 있습니다.

주로

• 검색 엔진의 색인이 필요한 경우
• 콘텐츠가 주를 이루는 뉴스나 강의 페이지 같은 경우

이러한 경우에는 CSR이 적절하다고 생각합니다.

단점으로는

"  TTV와 TTI. 즉 인터렉션을 가능한 시점의 공백이 꽤 깁니다. 첫 화면을 본 후에 실제로 서비스를 이용하기까지 시간이 걸린다는 단점도 있습니다. 예를 들어 로그인이 필요한 사이트가 SSR을 사용한다면 로그인 입력 창은 빨리 렌더링되었지만 아이디 비밀번호를 기입하고 로그인 버튼을 눌렀을 때 아무런 상호작용이 일어나지 않는 경험을 할 수 있습니다.

"CSR 은 상호작용 측면에서 월등한 UX 제공하는 장점이 있습니다." TTV와 TTI가 거의 동시에 이루어지기때문에 UX가 뛰어납니다. 하지만 사용자가 첫 화면이 렌더링 될 때 까지 기다리는 시간이 길다는 단점과 검색엔진이 검색하기 어렵다는 단점이있다. 주로

• 검색 엔진의 색인이 필요한 경우
• 콘텐츠가 주를 이루는 뉴스나 강의 페이지 같은 경우

이러한 경우에는 CSR이 적절하다고 생각합니다.

 

// 결론

"따라서 요즘은 상황에 따라 SSR 과 CSR 을 합쳐서 각각의 장점을 취하는 것이 트렌드입니다."

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

 GET과 POST의 특징만 보아도 차이가 나긴하지만 추가적으로 차이점을 정리해보면 다음과 같다.

 

• 사용목적 : GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용한다.
• DB로 따지면 GET은 SELECT 에 가깝고, POST는 Create 에 가깝다고 보면 된다.
  
  
• 요청에 body 유무 : GET 은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST 는 body 에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다.
  
  
• 멱등성 (idempotent) : GET 요청은 멱등이며, POST는 멱등이 아니다.
  
  

멱등이란?

멱등의 사전적 정의는 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같을 것 이다. 반대로 POST는 리소스를 새로 생성하거나 업데이트할 때 사용되기 때문에 멱등이 아니라고 볼 수 있다. (POST 요청이 발생하면 서버가 변경될 수 있다.)

 

 

 

GET과 POST는 이런 차이들이 있기 때문에 사용하려는 목적에 맞는 확인한 후에 사용해야한다.

GET과 POST 이외에도 PUT , DELETE 등을 적절히 사용하는게 좋은데 예를들어 봇의 경우에 사이트를 돌아다니면서 GET 요청을 날린다. 이럴 때 DELETE 등을 GET으로 처리하면 봇에 의해 서버에 있는 리소스들이 삭제 되는 상황이 일어 날수 있다! 항상 기술을 사용할 때 왜 를 잊지말자.

---

웹서버 기초

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

// 크게 요청과 응답으로 나뉨

"HTTP 메세지는 크게 "요청"과 "응답"으로 나뉩니다."

// 구조

"'요청'과 '응답' 각각 Start Line/Status Line 을 시작으로 Header 와 Body 로 이루어져 있습니다."

// Start Line (head)

"Start Line 은 1) HTTP 메서드 2) 요청 대상 3) 프로토콜 버전 을 포함합니다."

// Status Line (head)

"Status Line 은 1) 프로토콜 버전 2) 상태 코드 3) 상태 텍스트 을 포함합니다."

// Header (head)

"요청을 지정하거나, 메시지에 포함된 본문ㅇ르 설명하는 헤더의 집합입니다."

// Body (payload)

"모든 요청에 Body 가 필요하지 않으며 데이터 정보를 나타냅니다."

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

// SOP

"'동일 출처 정책'은 '같은 출처의 리소스만 공유가 가능한 정책'입니다."

"'출처'란 프로토콜, 호스트, 포트로 이루어져있습니다.'

// CORS

"'교차 출처 리소스 공유'를 뜻합니다."
"즉, 특정 외부 출처에게 특정 리소스에 접근할 수 있는 권한을 부여해주는 것 입니다."

"서버의 응답 헤더에 'Access-Cotrol-Allow-Origin' 작성 등을 통해 접근 권한을 부여해 줄 수 있습니다.

---

참조

코드스테이츠 프론트엔드 부트캠프
MoDerN Web Docs

https://velog.io/@hyeonwooga/%EB%85%B8%ED%8A%B8-56-%EC%84%B9%EC%85%982-%EA%B8%B0%EC%88%A0%EB%A9%B4%EC%A0%91-%EC%A4%80%EB%B9%84 블로그