기술면접 준비하기 - 2

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

---

Promise는 JavaScript에서 비동기 작업을 처리하기 위한 객체이다.
비동기 작업은 일반적으로 네트워크 요청이나 파일 읽기와 같이 시간이 걸리는 작업을 말한다.

Promise는 이러한 작업을 더 효율적으로 처리할 수 있도록 도와준다.

Promise의 주요 기능

1. 비동기 작업의 성공 또는 실패를 처리: Promise는 비동기 작업의 결과가 성공인지 실패인지를 나타내는 상태를 가진다.
   작업이 성공하면 완료된(resolve) 상태가 되고, 실패하면 거부된(reject) 상태가 된다.
   이 상태에 따라 적절한 동작을 수행할 수 있다.

2. 연속된 비동기 작업의 체인화: Promise는 비동기 작업을 연속적으로 체인화할 수 있는 기능을 제공한다.
   이를 통해 여러 비동기 작업을 순차적으로 실행하거나, 병렬로 실행하고 모든 작업이 완료될 때까지 기다릴 수 있다.

3. 에러 핸들링: Promise는 작업 중 발생한 에러를 캐치하고 처리할 수 있다.
   then() 메서드 체인의 마지막에 위치한 catch() 메서드를 사용하여 에러를 캐치하고 적절한 오류 처리를 수행할 수 있다.

Promise를 사용하는 이유

1. 비동기 작업의 순서와 상태를 관리할 수 있다. 작업이 완료될 때까지 기다릴 필요 없이,
   작업이 완료되면 콜백 함수를 실행하는 대신 Promise 객체를 반환받아 다음 작업을 수행할 수 있다.

2. 복잡한 비동기 로직을 간결하게 표현할 수 있다.
   Promise 체인을 사용하면 작업의 순서와 상태 전이를 명확하게 표현할 수 있다.

3. 에러 처리가 용이하다. catch() 메서드를 사용하여 비동기 작업 중 발생한 에러를 캐치하고 처리할 수 있다.
   이를 통해 코드의 안정성을 높일 수 있다.

4. 비동기 작업을 병렬로 실행할 수 있다. Promise.all() 메서드를 사용하면 여러 개의 Promise를 동시에 실행하고, 모든 작업이 완료될 때까지 기다릴 수 있다.
   
   

💬 요약하면, Promise는 비동기 작업을 관리하고 순서를 제어하며, 코드를 간결하고 안정적으로 작성할 수 있게 한다.

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

---

순수함수는 동일한 입력에 대해 항상 동일한 결과를 반환하며, 외부의 상태를 변경하지 않는 함수이다.
즉, 함수의 실행은 오직 인자에만 의존하며, 함수 내부에서 다른 변수나 상태를 변경하지 않는다.

순수함수의 특징

1. 입력에 대해 항상 동일한 출력을 반환한다: 같은 인자로 호출되면 항상 같은 결과를 반환한다.
   이는 함수의 실행이 외부의 상태에 의존하지 않고 오로지 인자에만 의존하기 때문에 가능하다.

2. 외부 상태를 변경하지 않는다: 함수 내부에서 다른 변수나 객체의 값을 수정하지 않는다.
   이는 함수의 실행이 프로그램의 다른 부분에 영향을 주지 않고 독립적으로 실행될 수 있음을 의미한다.

불변성(Immutability)

불변성은 데이터의 변경 불가능성을 의미한다.

즉, 한 번 생성된 데이터는 그 값을 변경할 수 없는 것을 말한다. 불변성은 순수함수와 관련이 깊은 개념이다.

순수함수는 외부 상태를 변경하지 않기 때문에 데이터의 불변성을 유지할 수 있다.
함수의 실행 결과로 생성된 데이터는 수정할 수 없으며, 필요한 경우 새로운 데이터를 생성하여 반환한다.

사이드 이펙트(Side Effect)

사이드 이펙트는 함수의 실행 결과로 함수 외부의 상태나 환경에 영향을 주는 것을 말한다.

예를 들면, 전역 변수의 값 변경, 파일에 쓰기, 네트워크 요청 등이 사이드 이펙트에 해당한다.

순수함수는 외부 상태를 변경하지 않으므로 사이드 이펙트가 없다.

💬 요약하면, 순수함수는 동일한 입력에 대해 항상 동일한 결과를 반환하며 외부 상태를 변경하지 않는다.
이를 통해 함수 실행의 불변성과 사이드 이펙트의 부재를 보장하며, 코드의 예측 가능성과 안정성을 증가시킨다.

💡 React의 state와 props에 대해서 간결하게 설명해주세요.

---

React에서 state와 props는 컴포넌트의 데이터를 다루는 두 가지 주요 개념이다.

State (상태)

• 컴포넌트 내에서 관리되는 데이터를 나타낸다.
• state는 컴포넌트 내에서 변경 가능하며, 컴포넌트가 렌더링될 때 화면에 반영된다.
• state는 클래스형 컴포넌트에서 this.state를 통해 정의되고 변경할 수 있으며,
  함수형 컴포넌트에서 useState 훅을 사용하여 정의하고 변경한다.
• state의 변경은 주로 setState 메서드나 useState 훅의 반환 값인 setter 함수를 사용하여 이루어진다.

Props (속성)

• 부모 컴포넌트로부터 전달받은 데이터를 나타낸다.
• props는 부모 컴포넌트에서 자식 컴포넌트로 전달되며, 자식 컴포넌트는 props를 읽기 전용으로 사용한다.
• props는 컴포넌트 내에서 변경할 수 없으며, 부모 컴포넌트에서만 변경 가능하다.
• props는 함수의 매개변수로 전달되거나 컴포넌트 태그의 속성으로 전달된다.
  
  

💬 요약하면, state는 컴포넌트 내에서 관리되고 변경 가능한 데이터이며, props는 부모 컴포넌트로부터 전달되는 읽기 전용 데이터이다. State는 컴포넌트의 내부 상태를 관리하고 렌더링 결과에 반영하며, Props는 컴포넌트 간에 데이터를 전달하고 조합하여 재사용성을 높이는 데 사용된다.

💡 React 컴포넌트의 key 속성에 대해서 간결하게 설명해주세요.

---

React 컴포넌트의 key 속성은 각각의 요소를 구별하기 위한 고유한 식별자이다.
key는 컴포넌트 배열을 렌더링할 때 사용되며, 각 요소의 고유성을 유지하고 성능을 최적화하는 데 도움을 준다.

key 속성의 특징

1. 고유성 유지: key는 각 요소를 고유하게 식별하기 위해 사용된다.
   컴포넌트 배열을 렌더링할 때 React는 key 값을 사용하여 각 컴포넌트를 추적한다.

2. 재조립 최소화: key를 통해 React는 컴포넌트의 변경 여부를 더 효율적으로 판단할 수 있다.
   key가 변경되면 React는 해당 컴포넌트를 새로 생성하고 이전 상태를 버리는 대신 이전에 생성된 컴포넌트를 재사용하지 않는다.

3. 성능 최적화: key를 사용하여 React가 컴포넌트를 효율적으로 재조립하고 다시 렌더링하는 데 도움이 된다.
   특히 동일한 위치에서 컴포넌트를 추가, 제거 또는 재정렬할 때 성능상의 이점이 있다.

key 속성은 컴포넌트 배열을 렌더링하는 동안 필수적으로 제공되어야 한다.
일반적으로 고유한 식별자인 ID나 인덱스를 사용하여 key 값을 설정한다.

그러나 배열 내 요소의 순서가 동적으로 변경되는 경우에는 고유성을 유지하기 위해 안정적인 식별자를 선택해야 한다.

💬 요약하면, key 속성은 React 컴포넌트 배열을 렌더링할 때 각 요소를 고유하게 식별하기 위한 속성이다.
key를 지정함으로써 컴포넌트의 재조립을 최소화하고 성능을 향상시킬 수 있다.

💡 useEffect의 dependency array에 대해서 간결하게 설명해주세요.

---

useEffect 훅은 React 함수형 컴포넌트에서 부작용(side effect)을 다루는 데 사용된다.

useEffect의 두 번째 매개변수인 dependency array(의존성 배열)는
특정 값들의 변경을 감지하여 useEffect의 동작을 제어하는 데 사용된다.

dependency array의 주요 특징

1. 의존성 목록: dependency array에 포함된 값들은 useEffect가 동작하기 위해 의존하는 값들이다.
   즉, 해당 값들 중 하나라도 변경되었을 때에만 useEffect가 실행된다.

2. 빈 배열([]): dependency array가 빈 배열인 경우, useEffect는 컴포넌트가 처음 렌더링될 때 한 번만 실행되며, 그 이후에는 다시 실행되지 않는다. 이는 컴포넌트가 마운트(mount)되었을 때만 특정 동작을 수행하고 싶을 때 유용하다.

3. 값의 변경 감지: dependency array에 포함된 값들 중 하나라도 변경되면, useEffect는 재실행된다
   변경을 감지하는 기준은 값의 동등성 비교(Shallow Equality Comparison)이다. 즉, 값의 내용이 변경되지 않으면 useEffect는 재실행되지 않는다.

4. 모든 값 감지: dependency array를 생략하면, useEffect는 매 렌더링마다 실행된다.
   이는 컴포넌트의 모든 렌더링 사이클마다 특정 동작을 수행하고 싶을 때 사용된다.
   대신, useEffect가 매 렌더링마다 실행되기 때문에 성능에 영향을 줄 수 있으므로, 신중하게 사용해야 한다.
   
   

💬 요약하면, dependency array는 useEffect의 동작을 제어하기 위해 의존하는 값들을 나타내는 배열이다.
값의 변경을 감지하여 useEffect를 실행하며, 빈 배열인 경우에는 한 번만 실행되고, 값이 변경되지 않으면 실행되지 않는다. 생략하면 매 렌더링마다 실행된다.

💡 CSR과 SSR의 차이점에 대해서 간결하게 설명해주세요.

---

CSR(클라이언트 사이드 렌더링)과 SSR(서버 사이드 렌더링)은 웹 애플리케이션의 렌더링 방식에 대한 차이를 나타낸다.

CSR(클라이언트 사이드 렌더링)

• 클라이언트 사이드에서 렌더링이 이루어지는 방식이다.
• 서버는 초기 HTML, CSS, JavaScript 파일을 제공하고, 클라이언트에서 JavaScript를 통해 동적으로 컨텐츠를 렌더링한다.
• 사용자가 웹 페이지에 접근하면 먼저 빈 페이지가 로드되고, JavaScript 파일이 다운로드되어 실행되어야 한다.
• 컨텐츠를 동적으로 가져와서 렌더링하기 때문에 초기 로딩 속도가 느릴 수 있으나, 이후에는 빠른 네비게이션과 상호작용이 가능하다.
• 주로 React, Angular, Vue.js 등의 프론트엔드 프레임워크와 함께 사용된다.

SSR(서버 사이드 렌더링)

• 서버에서 렌더링이 이루어지는 방식이다.
• 서버는 초기 요청에 대해 완전한 HTML을 생성하여 클라이언트에 전달한다.
• 사용자가 웹 페이지에 접근하면 완전한 페이지가 로드되고, 클라이언트에서 별도의 렌더링 과정 없이 바로 보여진다.
• 초기 로딩 속도는 빠르지만, 상호작용이 필요한 부분에서는 추가적인 네트워크 요청이 필요하다.
• 서버 측에서 렌더링이 이루어지기 때문에 검색 엔진 최적화(SEO)에 유리하다.
• 주로 Next.js, Nuxt.js 등의 SSR 프레임워크와 함께 사용된다.
  
  

💬 요약하면, CSR은 클라이언트 사이드에서 JavaScript를 통해 동적으로 렌더링되는 방식이고,
SSR은 CSR과 다르게 서버에서 초기 HTML을 생성하여 전달하는 방식이다.
CSR은 초기 로딩 속도가 느릴 수 있으나 상호작용이 빠르며, SSR은 초기 로딩 속도가 빠르지만 상호작용에는 추가 요청이 필요하다. SSR은 SEO에 유리하며, CSR은 프론트엔드 프레임워크와 함께 사용된다.

💡 GET 메서드와 POST 메서드의 차이점에 대해 간결하게 설명해주세요.

---

GET 메서드와 POST 메서드는 HTTP 프로토콜에서 사용되는 두 가지 주요한 요청 메서드입니다.

GET 메서드

• 서버로부터 정보를 요청하기 위해 사용된다.
• 요청된 데이터는 URL의 쿼리 매개변수로 전달된다.
• 요청은 노출되며, 브라우저 히스토리에 기록되므로 즐겨찾기와 공유 가능하다.
• 데이터 전송량에 제한이 있으며, 캐싱 가능하다.
• 보안적인 측면에서 민감한 정보를 전송하는 데에는 적합하지 않다.
• 주로 데이터 조회, 검색, 필터링 등의 요청에 사용된다.

POST 메서드

• 서버로 데이터를 제출하고 수정하기 위해 사용된다.
• 요청된 데이터는 요청 본문에 포함되어 전달된다.
• 요청은 노출되지 않으며, 브라우저 히스토리에 기록되지 않는다.
• 데이터 전송량에 제한이 없으며, 캐싱되지 않는다.
• 보안적인 측면에서 민감한 정보를 안전하게 전송할 수 있다.
• 주로 데이터 생성, 수정, 삭제 등의 요청에 사용된다.
  
  

💬 요약하면, GET 메서드는 서버로부터 정보를 요청할 때 사용되고, URL에 데이터가 노출된다.
반면에 POST 메서드는 서버로 데이터를 제출하고 수정할 때 사용되며, 요청 본문에 데이터가 포함된다.
GET은 조회 및 검색과 같은 요청에, POST는 데이터 생성 및 수정과 같은 요청에 주로 사용된다.

💡 HTTP 메세지 구조에 대해 간결하게 설명해주세요.

---

HTTP 메시지는 클라이언트와 서버 간에 교환되는 데이터의 구조화된 형식이다.

HTTP 메시지의 구조

1. 시작줄(Start Line): HTTP 요청 또는 응답의 첫 줄로, 요청 라인 또는 상태 라인으로도 알려진다.
   메서드, URL(요청) 또는 상태 코드(응답), HTTP 버전 정보가 포함된다.

2. 헤더(Headers): 시작줄 다음에 위치하며, 여러 개의 헤더 필드로 구성된다.
   각 헤더 필드는 이름과 값의 쌍으로 이루어져 있으며, 요청 또는 응답에 대한 추가 정보를 제공한다.
   예를 들어, Content-Type, Content-Length, Cookie 등이 포함될 수 있다.

3. 빈 줄: 헤더와 본문 사이에 존재하는 빈 줄로, 헤더의 끝을 나타낸다.

4. 본문(Body): 선택적으로 존재하는 부분으로, 요청 또는 응답의 데이터가 포함된다.
   본문은 생략될 수도 있으며, 전송될 데이터의 형식은 Content-Type 헤더에 의해 지정된다.
   예를 들어, HTML, JSON, 이미지 등의 데이터가 본문에 포함될 수 있다.
   
   

💬 요약하면, HTTP 메시지는 시작줄, 헤더, 빈 줄, 본문으로 구성된다.
시작줄에는 요청 라인 또는 상태 라인이 포함되고, 헤더는 추가 정보를 제공한다.
빈 줄은 헤더와 본문 사이를 구분하며, 본문에는 요청 또는 응답에 대한 데이터가 포함된다.

💡Same-Origin Policy와 CORS에 대해서 간결하게 설명해주세요.

---

Same-Origin Policy와 CORS는 웹 브라우저에서 보안을 유지하기 위해 사용되는 정책이다.

Same-Origin Policy (동일 출처 정책)

• Same-Origin Policy는 웹 브라우저에서 스크립트로부터 오는 보안 공격을 방지하기 위한 정책이다.
• 동일 출처란 프로토콜, 호스트, 포트가 모두 동일한 경우를 말한다.
• Same-Origin Policy에 따라 스크립트는 동일 출처의 리소스만에 접근할 수 있다.
• 다른 출처의 리소스에 접근하려면 명시적으로 권한을 부여받아야 한다.
• Same-Origin Policy는 기본적으로 동작하여 웹 애플리케이션의 보안을 강화한다.

CORS (Cross-Origin Resource Sharing)

• CORS는 Same-Origin Policy의 제한을 완화하기 위한 메커니즘이다.
• 서로 다른 출처의 리소스에 대한 접근을 허용하기 위해 추가적인 HTTP 헤더와 정책을 사용한다.
• 서버는 요청이 허용된 출처에서 온 것인지 확인하기 위해 Access-Control-Allow-Origin 헤더를 응답에 포함시킨다.
• 클라이언트는 브라우저의 지원을 통해 서버로부터의 추가 권한을 확인하고, 접근이 허용되는 경우에만 리소스에 접근할 수 있다.
• CORS는 AJAX와 같은 비동기 요청, 웹 폰트, 이미지, 스크립트 등 다양한 리소스에 대한 교차 출처 접근을 지원한다.
  
  

💬 요약하면, Same-Origin Policy는 동일 출처의 리소스에만 접근을 허용하는 정책이고,
CORS는 다른 출처의 리소스에 대한 접근을 허용하기 위한 메커니즘이다.
CORS는 서버의 응답 헤더와 클라이언트의 브라우저 지원을 통해 교차 출처 접근을 제어한다.