생각/TIL,WIL

면접 준비

kyunghoonk00k 2022. 12. 21. 13:50
반응형

1. 시간복잡도와 공간복잡도가 무엇인지 설명해주실 수 있을까요?

시간복잡도: 알고리즘의 절대적인 실행 시간을 나타내는 것이 아닌 알고리즘을 수행하는 데 연산들이 몇 번 이루어지는 지를 숫자로 표기

공간복잡도 : 프로그램을 실행시킨 후 완료하는 데 필요로 하는 자원 공간의 양

 

2. 스택, 큐에 대해 설명해주실 수 있을까요?


스택(stack)이란 어떠한 자료를 쌓아서 올려놓은 형태의 자료구조입니다.
책상에 쌓여있는 책들이나 싱크대의 접시를 예시로 들 수 있습니다.

📝 스택의 특징
스택은 위의 그림과 같이 아래에서 위로 쌓이는 형식이며 가장 최근에 들어온 자료를 top이라고 부릅니다.
뻥튀기를 꺼낼 때 가장 아래쪽의 뻥튀기를 꺼내려면 위에서부터 차례대로 뻥튀기를 꺼내야 하는 것처럼 가장 위쪽(최신)의 데이터부터 꺼낼 수 있으며 이러한 스택의 구조를 후입선출(LIFO, Last In First Out)의 구조라고 합니다.
즉, 스택의 경우 자료의 삽입과 삭제는 한 곳(top)에서만 이루어지게 됩니다.

만약 스택이 비어있을 때 자료를 꺼내려고 시도를 하면 스택 언더플로우(Stack Underflow)가 발생하고
반대로, 스택이 꽉 차있을 때 자료를 넣으려고 하면 스택 오버플로우(Stack Overflow)가 발생하게 됩니다.

웹 브라우저 뒤로가기 : 가장 나중에 열린 페이지부터 뒤로 가기를 실행합니다.
문서작업에서 Ctrl+Z 

📝 큐의 특징
정해진 곳(top)에서만 자료의 삽입과 삭제가 이루어지는 스택과는 다르게 큐는 Rear부분에서 자료의 삽입이, Front부분에서 자료의 삭제가 이루어집니다. 
비비탄총의 탄창에 비비탄을 넣고 사격 시 가장 먼저 넣었던 비비탄이 먼저 나가는 것처럼 큐는 선입선출(FIFO, First In First Out)의 자료구조를 가집니다.

 

3. 배열, 링크드리스트를 비교하여 설명해주실 수 있을까요?

 

 

Array는 연속된 메모리 공간에 존재하고 Linked List는 메모리 상에서 떨어져 있는 데이터들이 앞의 데이터와 뒤의 데이터를 기억하는 형태로 존재한다.
Array에 저장되어 있는 데이터를 조회할 때는 O(1)로 가능하지만 Linked List는 O(N)이 소요된다.
Array에 데이터 추가 및 삭제할 때는 O(N)이 소요되지만 Linked List는 O(1)로 가능하다.
추가적으로 Array는 컴파일 과정에서 메모리가 할당되는 정적 메모리 할당인 반면 Linked List는 런타임 환경에서 메모리가 할당되는 동적 메모리 할당이다.
또한 배열은 Stack 영역에 메모리 할당이 되고, Linked List는 Heap 영역에 할당이 된다.

 

4. CORS란 무엇이고 어떻게 허용할 수 있나요?


브라우저에서는 보안적인 이유로 cross-origin HTTP 요청들을 제한합니다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요합니다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 
동의하지 않는다면 브라우저에서 거절합니다.

이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing)라고 부릅니다.

그래서 브라우저에서 cross-origin 요청을 안전하게 할 수 있도록 하는 메커니즘입니다.

프로토콜 - http와 https는 프로토콜이 다르다.
도메인 - domain.com과 other-domain.com은 다르다.
포트 번호 - 8080포트와 3000포트는 다르다.

 

5. 사용자 패스워드를 전송하고 보관하는 방법을 설명해주실 수 있을까요?


유저 패스워드 > 클라이언트 평문으로 서버전송 >

서버는 단방향 해시함수로 암호화(수학연산에 의해 암호화된 데이터:다이제스트)하여 보관 >

다이제스트로는 원본 데이터를 구할수없음 이것을 단방향해시함수 라고함>

단방향해시함수는 부르트 포스공격의 위험이 있어 키스트레칭(다이제스트 n번반복) >

솔팅(패스워드에 임의의 문자열 추가하여 해싱)하여 보안강도를 높인다.

 

6. var, let, const 에 대해 설명해주실 수 있을까요?



자바스크립트 엔진은 소스코드를 한 줄씩 순차적으로 실행하기에 앞서, 변수 선언을 포함한 모든 선언문(ex. 변수 선언문, 함수 선언문 등)을 찾아내 먼저 실행한다. 
즉, 변수 선언이 어디에 있든 상관없이 다른 코드보다 먼저 실행되는 특징을 호이스팅(hoisting)이라 한다.

스코프
스코프(scope)는 식별자(ex. 변수명, 함수명, 클래스명 등)의 유효범위를 뜻하며, 선언된 위치에 따라 유효 범위가 달라진다. 전역에 선언된 변수는 전역 스코프를, 지역에 선언된 변수는 지역 스코프를 갖는다.

전역 변수는 어디에서든지 참조가 가능한 값이다. 반면, 지역 변수는 함수 몸체 내부를 말한다. 따라서 지역 변수는 자신의 지역 스코프와 그 하위 지역 스코프에서 유효하다.

앞에서 발견한 var 키워드의 문제점은 크게 세 가지가 존재한다.

변수 중복 선언 가능하여, 예기치 못한 값을 반환할 수 있다.
함수 레벨 스코프로 인해 함수 외부에서 선언한 변수는 모두 전역 변수로 된다.
변수 선언문 이전에 변수를 참조하면 언제나 undefined를 반환한다.

ES6에서 나온 let과 const 키워드는 위의 세 가지 문제점을 해결했다.

1. 변수 중복 선언 불가
(1) let

let 키워드로는 변수 중복 선언이 불가하지만, 재할당은 가능하다.

(2) const

const가 let과 다른 점이 있다면, 반드시 선언과 초기화를 동시에 진행되어야 한다.

const도 let과 마찬가지로 재선언이 불가하며, 더 나아가 재할당도 불가하다. 재할당의 경우, 원시 값은 불가능하지만, 객체는 가능하다. const 키워드는 재할당을 금지할 뿐, '불변'을 의미하지 않는다.

2. 블록 레벨 스코프
let, const 키워드로 선언한 변수는 모두 코드 블록(ex. 함수, if, for, while, try/catch 문 등)을 지역 스코프로 인정하는 블록 레벨 스코프를 따른다.

위 var 키워드로 예를 들었던 것을 그대로 가져와 바꾸면 아래와 같은 결과가 나온다.

3. 변수 호이스팅
(1) let

let 키워드로 선언한 변수는 선언 단계와 초기화 단계가 분리되어 진행된다. 즉, 런타임 이전에 자바스크립트 엔진에 의해 선언 단계가 먼저 실행되지만, 초기화 단계가 실행되지 않았을 때 해당 변수에 접근하려고 하면 참조 에러가 뜬다.

따라서 let 키워드로 선언한 변수는 스코프의 시작 지점부터 초기화 단계 시작 지점까지 변수를 참조할 수 없는 일시적 사각지대(Temporal Dead Zone: TDZ) 구간에 존재한다.

(2) const

const 키워드는 선언 단계와 초기화 단계가 동시에 진행된다.

 

7. Promise란 무엇인지 설명해주실 수 있을까요?

 


프로미스는 자바스크립트 비동기 처리에 사용되는 객체입니다.
프로미스는 주로 서버에서 받아온 데이터를 화면에 표시할 때 사용합니다. 

Pending(대기) : 비동기 처리 로직이 아직 완료되지 않은 상태
Fulfilled(이행) : 비동기 처리가 완료되어 프로미스가 결과 값을 반환해준 상태
Rejected(실패) : 비동기 처리가 실패하거나 오류가 발생한 상태

 

8. Hoisting이란 무엇인지 설명해주실 수 있을까요?

즉, 변수 선언이 어디에 있든 상관없이 다른 코드보다 먼저 실행되는 특징을 호이스팅(hoisting)이라 한다.

 

9. async& await

 


 await를 사용하지 않았다면 데이터를 받아온 시점에 콘솔을 출력할 수 있게 콜백 함수나 .then()등을 사용해야 했을 겁니다. 하지만 async await 문법 덕택에 비동기에 대한 사고를 하지 않아도 되는 것이죠.

기존의 비동기 처리 코드 방식으로 사고하지 않아도 되는 장점이 생깁니다. try catch입니다. 프로미스에서 에러 처리를 위해 .catch()를 사용했던 것처럼 async에서는 catch {

 

 

HTTP 프로토콜이란?
HTTP(Hypertext Transfer Protocol)는 웹을 개발하는 사람이라면 누구나 다 알아야 하는 통신 프로토콜입니다. 프로토콜이란 상호 간에 정의한 규칙을 의미하며 특정 기기 간에 데이터를 주고받기 위해 정의되었습니다. 통신 프로토콜을 쉽게 풀어보면 “나는 이렇게 줄 테니 넌 이렇게 받고 난 너가 준거 그렇게 받을께” 정도가 되겠네요 :)
웹에서는 브라우저와 서버 간에 데이터를 주고받기 위한 방식

 

11. Arrow Function 이란 무엇인지 설명해주실 수 있을까요?

 

 

즉, Arrow Function(화살표 함수)은 '함수 스코프'를 생성합니다. 다만, 실행 컨텍스트 생성시 this 를 바인딩하지 않습니다.
정리하면, 메소드를 사용하려면 메소드 축약형, 기존 방식을 그렇지 않다면 화살표 함수를 사용하면 될 것이고, 화살표 함수는 메소드 안에서 같은 this 를 바라보게 할 때 즉, 내부 함수로서 사용하는 경우에 의의가 있다고 할 수 있습니다.

 

12. ‘==’와 ‘===’ 연산자의 차이는 무엇인지 설명해주실 수 있을까요?

 

  • ==은 서로 다른 유형의 두 변수의 [값] 비교
  • === 은 값과 자료형까지 엄격한 비교를 한다.

13. Virtual DOM이란 무엇이고 Real DOM과의 차이는 무엇인가요?

텍스트 파일로 만들어진 웹 문서를 브라우저에 렌더링 하려면 브라우저가 이해할 수 있는 구조로 메모리에 올려야 한다.

.HTML 파일이 브라우저에 표현되는 과정
(1) 브라우저의 렌더링 엔진은 웹 문서를 로드 한다. (흔히 우리가 작업한 HTML 파일을 브라우저에 끌어 올리는 행위를 생각하면 쉬울 것 같다.)

(2) 웹 문서를 로드 한 후, 웹 문서를 브라우저가 이해할 수 있는 구조로 구성하여 메모리에 올린다.

(3) 그리고 브라우저는 브라우저가 이해할 수 있는 구조를 그려낸다.

브라우저가 이해할 수 있는 구조
브라우저의 렌더링 엔진은 모든 요소(Element)와 속성(Attribute)등을 각각의 객체로 만들고 이것을 트리 구조로 구성한다. 우리는 이를 DOM이라고 부르고 있는 중이다.

개발자가 DOM의 구조를 신경 쓰면서 코드를 작성하고, 최적화를 위해 Virtual DOM의 diff 알고리즘(비교알고리즘)을 수정하지 않을 수 있게 React는 그것을 보조

 

15. useRef 에 대해 아는 만큼 설명해주실 수 있을까요?

DOM 을 직접 선택해야 하는 상황이 발생 할 때도 있습니다. 예를 들어서 특정 엘리먼트의 크기를 가져와야 한다던지, 스크롤바 위치를 가져오거나 설정해야된다던지, 또는 포커스를 설정해줘야된다던지 등 정말 다양한 상황이 있겠죠

 

16. 리액트 컴포넌트의 라이프사이클에 대해 설명해주실 수 있을까요?

 

컴포넌트가 렌더링을 준비하는 시점부터 페이지가 언마운트 될 때 까지의 사이클을 말합니다
크게 세가지 유형으로 나눌 수 있는데 생성 될때, 업데이트 할 때, 제거할 때이다. 이를 리액트에서는 마운트, 업데이트, 언마운트라고 한다.
여기서 마운트는 DOM이 생성되고 웹 브라우저 상에서 나타나는 것을 뜻하고, 반대로 언마운트는 DOM에서 제거되는 것을 뜻한다.
주의하여 볼 것은 업데이트 부분인데, 업데이트는 다음과 같은 4가지 상황에서 발생한다.

props가 바뀔 때
state가 바뀔 때
부모 컴포넌트가 리렌더링 될 때
this.forceUpdate로 강제로 렌더링을 트리거할 때

 

17. JSX란 무엇인가요?

javascript+xml
마크업과 로직이 합쳐짐
JavaScript 코드 안에서 UI 관련 작업

 

20. 세션과 쿠키를 비교하여 설명해주실 수 있을까요?


쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷합니다. 그 이유는 세션도 결국 쿠키를 사용하기 때문입니다.
가장 큰 차이점은 사용자의 정보가 저장되는 위치입니다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다.
보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠릅니다. 그 이유는 세션은 서버의 처리가 필요하기 때문입니다.
보안, 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다.
라이프 사이클, 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있습니다.
반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됩니다. 예를 들어, 크롬에서 다른 탭을 사용해도 세션을 공유됩니다. 다른 브라우저를 사용하게 되면 다른 세션을 사용할 수 있습니다.
속도, 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다.

쿠키/세션은 캐시와 엄연히 다르다!
캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것입니다.
한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있습니다.
보통 쿠키와 세션의 차이를 물어볼 때 저장위치와 보안에 대해서는 잘 말하는데 사실 중요한 것은 라이프사이클을 얘기하는 것입니다.

 

21. 브라우저에서 이용할 수 있는 스토리지는 무엇이 있는지 설명해주실 수 있을까요?


로컬 스토리지 세션 스토리지
데이터 유지 브라우저 종료시 보관 브라우저 종료시 삭제
데이터 범위 동일한 도메인 전역 공유 브라우저간 공유 안됨

- 쿠키
- 쿠키는 만료기한이 있는 키-값 저장소 입니다. same site 옵션을 strict로 설정하지 않았을 경우 다른 도메인에서 요청했을 때 자동 전송되며, 4KB가지 데이터를 저장할 수 있고 만료기한을 정할 수 있습니다. 쿠키를 설정할 때는 document cookie로 쿠키를 볼 수 없게 httponly 옵션을 거는 것이 중요하며, 클라이언트 똔느 서버에서 만료기한 등을 정할 수 있는데 보통 서버에서 만료기한을 정합니다.
- 로컬스토리지
- 로컬 스토리지는 만료기한이 없는 키-값 저장소입니다. 10MB까지 저장할 수 있으며 웹브라우저를 닫아도 유지되고 도메인 단위로 저장, 생성됩니다. HTML5를 지원하지 않는 웹 브라우저에서는 사용할 수 없으며 클라이언트에서만 수정 가능합니다.
- 세션 스토리지
- 세션 스토리지는 만료기한이 없는 키-값 저장소입니다. 탭 단위로 세션 스토리지를 생성하며, 탭을 닫을 때 해당 데이터가 삭제됩니다. 5MB까지 저장이 가능하며 HTML5를 지원하지 안흔 웹 브라우저에서는 사용할 수 없습니다. 클라이언트에서만 수정 가능합니다.

 

23. ContextAPI 란 무엇인가요?

 

프로젝트 안에서 전역적으로 사용 할 수 있는 값을 관리 할 수 있습니다.  "상태" 가 아닌 "값" 이라고 언급을 했는데요, 이 값은 꼭 상태를 가르키지 않아도 됩니다

. 이 값은 함수일수도 있고, 어떤 외부 라이브러리 인스턴스일수도 있고 심지어 DOM

 

24. 이분탐색이 무엇이고 시간복잡도는 어떻게 되며 그 이유는 무엇인가요?

 

- 오름차순으로 정렬된 리스트에서 특정한 값의 위치를 찾는 알고리즘이다.
- 처음과 마지막의 중간값을 선택하여, 찾고자 하는 값과 크고 작음을 비교하는 방식으로 반복하여 탐색을 진행한다.

**필수조건** : 오름차순으로 정렬된 리스트

**장점** : 모든 값을 순회하는 일반탐색보다는 속도가 빠르다.

**시간 복잡도** : log2N ( 한 번 탐색할때마다 , 탐색의 범위가 1/2로 줄어 들기 때문에)

 

25. 트리, 그래프를 비교하여 설명해주실 수 있을까요?

그래프의 특징
- 그래프는 순환 혹은 비순환 구조를 이룬다

- 그래프는 방향이 있는 그래프와 방향이 없는 그래프가 있다.

- 루트 노드의 개념이 없다 / 부모-자식 관계라는 개념이 없다.

- 2개 이상의 경로가 가능하다.(무방향, 방향, 양방향 가능)

- 그래프는 네트워크 모델이다.

-------아래는 트리 

사이클이 존재하지 않는 방향 그래프이다.

이러한 특성 때문에 '최소 연결 트리'라고 부르기도 한다.

트리와 그래프 비교
             그래프 트리
방향성 방향, 무방향 방향만
사이클 순환, 비순환, 자기순환 비순환만
루트노드 루트 개념 없음 한 개의 루트 존재
부모-자식 부모-자식 개념없음 1개의 부모노드(루트 제외)
모델 네트워크 모델 계층 모델
간선 수 자유 N-1개

 

29. TCP 3 way handshake란 무엇인지 설명해주실 수 있을까요?

- TCP는 신뢰성을 확보할때 3 way handshake라는 작업을 진행합니다.
- SYN(SYNchronization) 단계 : 클라이언트는 서버에 클라이언트의 ISN(Initial Sequence Numbers)을 담아 SYN을 보냅니다. ISN은 새로운 TCP연결의 첫 번째 패킷에 할당된 임의의 시퀀스 번호를 말하며(예시로 12010을 들었습니다) 이는 장치마다 다를 수 있습니다.
- SYN + ACK(ACKnowledgement) 단계: 서버는 클라이언트의 SYN을 수신하고 서버의 ISN을 보내며 승인번호로 클라이언트의 ISN + 1을 보냅니다.
- ACK 단계: 클라이언트는 서버의 ISN +1 한 값인 승인번호를 담아 ACK를 서버에 보냅니다.
- 이렇게 3 way handshake 과정 이후 신뢰성이 구축되고 데이터 전송을 시작합니다. 참고로 TCP는 이 과정이 있기 때문에 신뢰성이 있는 계층이라고 하며 UDP는 이 과정이 없기 때문에 신뢰성이 없는 계층이라고 합니다.

 

31. TCP 와 UDP 를 비교하여 설명해주실 수 있을까요?

데이터를 보내기 위해 사용하는 프로토콜

연결 지향 방식이다.
3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
흐름 제어 및 혼잡 제어.
높은 신뢰성을 보장한다.
UDP보다 속도가 느리다.
전이중(Full-Duplex), 점대점(Point to Point) 방식

 TCP는 연속성보다 신뢰성있는 전송이 중요할 때에 사용하는 프로토콜로 예를 들면 파일 전송과 같은 경우에 사용됩니다!

[ UDP 특징 ]
비연결형 서비스로 데이터그램 방식을 제공한다
정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
신뢰성이 낮다
TCP보다 속도가 빠르다

신뢰성보다는 연속성이 중요한 서비스 예를 들면 실시간 서비스(streaming)에 자주 사용됩니다.

 [ UDP 서버의 특징 ]
UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없다.
소켓 대신 IP를 기반으로 데이터를 전송한다.
서버와 클라이언트는 1대1, 1대N, N대M 등으로 연결될 수 있다.
데이터그램(메세지) 단위로 전송되며 그 크기는 65535바이트로, 크기가 초과하면 잘라서 보낸다.
흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.
파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 중요시 되는 경우에 사용된다.

 

Q) 흐름제어(Flow Control)와 혼잡제어(Congestion Control)이란?
 

흐름제어는 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것입니다.
 예를 들어 송신하는 곳에서 감당이 안되게 데이터를 빠르게 많이 보내면 수신자에서 문제가 발생하기 때문입니다.

혼잡제어는 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것입니다. 만약 정보의 소통량이 과다하면

패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막습니다.

부모-자식 관계가 성립하기 때문에 계층형 모델이라고도 한다.

 

32. Base64 인코딩이란 무엇인가요?


. 인코딩(encoding)은 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해서 다른 형태나 형식으로 변환하는 처리 혹은 그 처리 방식을 말한다.
 동영상이나 이미지영역에서도 많이 사용되는 용어지만 우리는 Binary Data를 Text로 바꿔주는 Base64 인코딩에 대해서 알아봐야하기 때문에 이하는 생략하겠다.

Base64는 HTML 또는 Email과 같이 문자를 위한 Media에 Binary Data를 포함해야 될 필요가 있을 때, 포함된 Binary Data가 시스템 독립적으로 동일하게 전송 또는 저장되는걸 보장하기 위해 사용한다
이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법입니다. 이 방법을 사용하면 서버와의 연결을 열고 이미지에 대해 서버에 HTTP요청을 할 필요가 없다는 장점이 있습니다. 하지만 Base64 문자열로 변화할 경우 37%정도 크기가 더 커지는 단점이 있습니다.


33. 프로세스와 스레드를 비교하여 설명해주실 수 있을까요?


프로세스는 운영체제로 부터 자원을 할당받는 작업의 단위
스레드는 프로세스가  할당받은  자원을 이용하는 실행의 단위 

멀티 프로세스를 쓰지 않고 멀티 쓰레드를 써야 통신 비용이 적어 자원의 효율성이 증가함 시스템 콜이 줄기 때문에

 

35. 깊은 복사와 얕은 복사의 차이는 무엇이고 JS에서 각각을 구현하는 방법은 어떻게 되는지 설명해주실 수 있을까요?

 

1. 얕은 복사(Shallow Copy)

객체를 복사할 때, 해당 객체만 복사하여 새 객체를 생성한다.
복사된 객체의 인스턴스 변수는 원본 객체의 인스턴스 변수와 같은 메모리 주소를 참조한다.
따라서, 해당 메모리 주소의 값이 변경되면 원본 객체 및 복사 객체의 인스턴스 변수 값은 같이 변경된다.

Object.assign()
Spread 연산자 (전개 연산자)


2. 깊은 복사(Deep Copy)

객체를 복사 할 때, 해당 객체와 인스턴스 변수까지 복사하는 방식.
전부를 복사하여 새 주소에 담기 때문에 참조를 공유하지 않는다.

깊은 복사된 객체는 객체 안에 객체가 있을 경우에도 원본과의 참조가 완전히 끊어진 객체

JSON.parse && JSON.stringify

 느리다는 것과 객체가 function일 경우,  undefined로 처리한다는 것이 단점입니다.

완벽한 Deep copy를 위한 다른 방법
재귀적으로 깊은 복사를 수행
Lodash의 cloneDeep 함수 사용

 

37. JS의 passed by value 와 passed by reference 에 대해 아는 만큼 설명해주실 수 있을까요?

 

 

값에 의한 호출과 참조에 의한 호출
값에 의한 호출은 값 자체가 저장됨 원시 x 참조타입

참조에 의한 호출은 객체의 참조값 주소를 저장함. '

 

38. 고차 함수란 무엇인지 설명해주실 수 있을까요?

함수를 다른 함수의 파라미터로 넘길 수도 있고 반환(return) 값으로 함수를 받을 수도 있는 프로그래밍 형태

함수를 일급 시민(first-class citizen)으로 대해준다는 것을 들어봤을 겁니다. 왜냐하면 자바스크립트 또는 다른 함수형 프로그래밍 언어 함수들은 전부 객체(objects)이기 때문입니다.

자바스크립트에서, 함수는 객체의 특별한 타입입니다. 함수는 Function 객체

고차 함수는 함수를 인자로 받거나 또는 함수를 반환함으로써 작동 하는 함수를 말합니다. 간단히 말하자면, 고차 함수는 함수를 인자로 받거나 함수를 출력(output)으로 반환하는(return) 함수를 말합니다.

 

41. VanillaJS와 비교하여 리액트를 사용하는 이유에 대해 설명해주실 수 있을까요?

 

동적으로 변하는 웹 서비스가 많아진 상황에서 가상 DOM을 이용함 으로써 동적인 변화가 있을 때 DOM전체를 바꾸는 것이 아닌 필요에 따라 원하는 부분의 DOM을 보다 효율적으로 DOM을 조작시키기 위해 내부적으로 Virtual DOM을 활용하는 reconciliation(재조정) 과정을 통해 DOM을 업데이트시키는 react를 사용한다.

 

42. 상태의 불변성이 중요한 이유가 무엇인가요?

 

불변하다는 것(immutable)은 객체가 최초 생성되었을 때의 값이 변하지 않고 유지된다는 의미이다.
객체의 불변성을 지키면 원본 데이터가 변경, 훼손되는 것을 막을 수 있다.

의도치 않게 값이 변경될 수도 있고, 해당 변수가 어디 있는지 추적하기도 어려워진다.

  • 이전 상태와 비교해서 변경된 부분만 리렌더링해야 하기 때문에 이전 상태가 원본을 유지해야 한다.
  •  내부 속성값만 변경해서는 참조 값이 변경되지 않는데, 참조 값이 변경되지 않은 경우 상태가 변경되지 않은 것으로 판단하고 리렌더링되지 않는다.

 

43. Lazy loading과 Code splitting에 대해 아는 만큼 설명해주실 수 있을까요?

 

레이지 로딩은 필요 시점까지 객체의 초기화를 연기시키기 위해 컴퓨터 프로그래밍에 흔히 사용되는 디자인 패턴의 하나로 적절하게 사용될 경우 프로그램의 운영 차원에서 효율적이다.

 

어플리케이션의 크기가 커지게 된다면 번들파일도 따라서 커진다는 사실을 잊어서는 안됩니다. 특히 굉장히 거대한 서드파티 라이브러리를 포함하고자 하는 경우에는 엄청나게 큰 파일을 맞닥뜨리게 될 것입니다. 따라서 이런 거대한 번들 파일을 막기 위해서 필요할 때만 불러와 코드를 Splitting

 

44. Server Side Rendering, Client Side Rendering, Static Site Generation 의 장단점을 설명해주실 수 있을까요?

 

 클라이언트 사이드에서 HTML문서 렌더링을 할 것이냐 아니면 서버 사이드에서 HTML문서를 렌더링 할 것이냐로 구분

 

Server Side Rendering

HTML로 사전 렌더링

  1. 첫 페이지 로딩 시간이 CSR 방식과 비교해 매우 짧다. (하지만 그림에서 보듯이 별도의 JS 파일 등을 다운받아 적용하기까지는 시간이 좀 더 소요되어 사용자의 인터랙션에 정상적인 반응을 보일때까지 기다리는 시간이 어느정도 발생할 수 있다)
  2. 이미 렌더링 된 HTML 문서가 전달되므로 SEO(Search Engine Optimazation)이 CSR 방식에 비해 적용하기 더 우수하다.
  3. 사용자 정보를 서버측 세션으로 관리하기 용이하므로 CSR 방식에 비해 보안이 우수하다.

반면 단점으로는 각 페이지별로 매번 로딩시간 및 새로고침 현상이 발생한다는 점은 UX및 UI에 심각한 영향을 초래할 수 있다. 또한 서버에서 렌더링을 마친다는 것은 서버가 담당하는 일이 더욱 많아지는 것이므로 부하에 걸릴 위험도 존재한다고 한다.

 

Client Side Rendering

브라우저는 먼저 자바스크립트 번들을 다운로드 한 다음 사용자가 컨텐츠를 보기도 전에 다운로드한 자바스크립트 번들을 실행

  1. 초기 로딩 속도를 제외하면 나머지 부분은 매우 빠른 사용자 인터랙션 속도를 보여준다. 이미 다운받은 번들링 된 js 파일에 렌더링에 필요한 모든 로직이 들어있기 때문.
  2. 따라서 새로고침이나 화면 깜빡임등이 (개발자가 의도한 상황이 아닌 이상) 발생하지 않는다. 이는 UX에 엄청난 이점을 가져다 준다.
  3. 서버가 클라이언트 뷰(View)단에서 처리할 일을 더이상 신경쓰지 않아도 된다.

로딩이 완료되기까지 그저 빈 화면을 보고 있을 수 밖에 없다. 또한 첫 페이지가 위와 같은 빈 화면이라는 말은 검색 엔진이 해당 문서를 바라볼 때 기입된 내용이 없기 때문에 SEO 최적화에도 많은 어려움이 따른다. (또한 CSR에서는 meta tag 수정 등의 어려움 등도 존재하기에 더욱 어렵다)

 

 SSG의 정적(Static)은 SSR 처럼 전체 프로세스가 각 사용자 요청에 수행되는 것이 아닌 빌드 시간에 수행됩니다. 그렇기 때문에 SSG가 서버 사이드 렌더링보다 훨씬 더 빠릅니다.

SSG는 빌드 시 리액트 앱에서 HTML 페이지를 만들기 때문에 모든 요청에 대해 HTML 페이지를 작성할 필요가 없으며 클라이언트 사이드의 브라우저에서도 HTML 페이지를 작성할 필요가 없습니다.

 

 결점 중 하나는 빌드 시간입니다. 수천 개의 페이지가 있는 경우 모두 빌드되는데 많은 시간이 걸립니다.

 

45. Event bubbling 과 capturing 을 비교하여 설명해주실 수 있을까요?

 

이벤트가 발생했을 때 해당 이벤트가 더 상위의 화면 요소들로 전달되어 가는 특성

하위에서 상위 요소로의 이벤트 전파 방식을 이벤트 버블링(Event Bubbling)

 

이벤트 버블링과 반대 방향으로 진행되는 이벤트 전파 방식

 

47. https://naver.com을 주소창에 입력했을 때 일어나는 과정에 대해 아는 만큼 설명해주실 수 있을까요?

 

Browser는 캐싱된 DNS 기록들을 통해  https://naver.com에 대응되는 IP 주소가 있는지 확인한다

 요청한 URL이 캐시에 없으면, ISP의 DNS 서버가 https://naver.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS query를 날린다

Browser가 서버와 TCP connection을 한다

Browser가 웹 서버에 HTTP 요청을 한다.

서버가 요청을 처리하고 response를 생성한다

서버가 HTTP response를 보낸다

Browser가 HTML content를 보여준다

 

48. 상태관리의 대표적인 도구 하나와 그것의 원리에 대해 구체적으로 설명해주실 수 있을까요? 예를 들어 리덕스라면 리덕스가 무엇이고 어떻게 활용이 되는지, 어떤 흐름으로 데이터가 들어왔다가 나가는지, 데이터 흐름은 양방향인지 단방향인지, 어떤 함수가 데이터를 가져오게 해주는지 등을 언급해주시면 좋습니다.

 

State 저장고를 만들어 State를 입력하거나 사용

Action

액션은 말그대로 Redux를 움직이는 Action 한마디로 함수와 같은 개념이다. 특정한 State를 조작하기 위해 사용한다. 액션 하나로 다중의 State로 조작이 가능하고 Redux 안에서의 움직임을 설정할 수 있다.

Reducer

리듀서는 만약 액션이 실행되었을 경우 실행된 액션에 따라서 State의 데이터를 조작하는 기능이다. 말그대로 직접 State에 간섭하며 액션에 따라 어떤 State를 할 수 있을지 지정해주는 기능이다. 주로 Action에서 Reducer로 데이터 혹은 실행명령을 전달하는 과정을 Dispatch라고 한다.

Store

스토어는 말그대로 State의 저장고라고 볼 수 있다. 여기에 Redux에서 관리하는 State를 확인할 수 있으며 주로 Reducer에서의 변화를 확인하고 자체적으로 Reducer의 데이터대로 변경시켜준다. 이러한 과정을 Subscribe라고 할 수 있다. 그리고 Store에서 직접 컴포넌트로 데이터를 전달할 수 있는 것을 Selector 라고 한다.

 

  1. 상태가 변경되어야 하는 이벤트가 발생하면 변경될 상태에 대한 정보가 담긴 Action 객체가 생성됨
  2. 이 Action 객체는 Dispatch 함수의 인자로 전달됨
  3. Dispatch 함수는 Action 객체를 Reducer 함수로 전달해줌
  4. Reducer 함수는 Action 객체의 값을 확인하고, 그 값에 따라 전역 상태 저장소 Store의 상태를 변경함
  5. 상태가 변경되면 React는 화면을 다시 렌더링함

Redux에서는 Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐름!

 

 

 

49. 브라우저 렌더링 과정에 대해 아는 만큼 설명해주실 수 있을까요? 예를 들어 화면에서 DOM이 어떻게 결정되고, CSS는 어떻게 입혀지는지 등을 언급해주시면 좋습니다.

 

1. 사용자가 주소표시줄(사용자 인터페이스)에 URI를 입력

2. 브라우저 엔진에게 URI(입력받은 주소값) 전달

3. 브라우저 엔진  URI(입력받은 주소값)에 해당하는 데이터를 자료저장소에서 먼저 찾아본다.

      같은 데이터를 받아오면는 낭비를 방지하기 위해 자주 받아오는 데이터를 저장해두고 사용하기 때문 (캐싱)

      이로인해 효율적인 렌더링을 사용 할 수 있다.

     ( Web Storage > localStorage, sessionStorage, Cookie )

4-1. 자료저장소에 값이 없는경우 렌더링 엔진에게 URI값을 전달

4-2. 렌더링 엔진 3번에 값이 있다면  대한 데이터를 분석하고,
          없어서 추가 데이터 요청이 필요하면 URI(입력받은 주소값)을 통신레이어에 전달한다.

5. 통신레이어에게 전달  > 서버에  html,css,javascript  값을 서버에 요청

6. 통신레이어에게 전달받은  html,css 는 렌더링 엔진이 파싱  (DOM tree, CSSOM tree 구축)  한다.

7. 통신레이어에게 전달받은   javascript 를 통신레이어가 자바스크립트 해석기에게 전달해서 해석

     자바스크립트 해석기에서 해석된 결과가 6번에서 파싱된  DOM tree 를 조작한다.

8. 조작이 완료된  DOM node(DOM tree 구성요소) 는  render object(render tree구성요소) 로 변한다.

9. ui 백엔드에 전달되어 render object가 화면에 그려진다.

 

  1. HTML 파싱
  2. 외부 리소스 가져오기
  3. CSS 파싱 및 CSSOM 생성
  4. 자바스크립트 실행
  5. DOM과 CSSOM 병합 후 렌더 트리 생성
  6. 레이아웃 계산 및 페인트

HTML을 분석함으로써 만들어짐

 

50. Web Vital을 개선할 수 있는 방안에 대해 설명해주실 수 있을까요? 예를 들어 LCP, CLS, FID 각각의 개념, 진단법, 각 지표 개선에 효과적인 조치 방안을 언급해주시면 좋습니다.

실험실 데이터 (Lab Data)

  • 실제 사용자의 데이터가 아닌 특정 단말기나 네트워크 환경에서 측정한 성능 추정치
  • 예를 들어 Chrome dev tool 에서 측정하거나, lighthouse CLI로 측정
    • Chrome dev tool 에서 측정할 경우, 브라우저의 Private 모드에서 측정하는게 좋다 (브라우저의 확장 플러그인 등이 성능 측정에 영향을 끼칠 수 있기 때문)
  • 특정 네트워크 환경에서 측정하므로 측정할 때마다 점수의 차이가 있음

현장 데이터 (Feild Data)

  • 실제 사용자 데이터
    • 여러 단말기의 네트워크 환경에서 해당 웹페이지를 방문하는 실제 사용자로부터 익명으로 수집된 성능 데이터
  • Core Web Vitals의 취지는 사용자의 경험을 측정하는 것이기 때문에 현장 데이터를 반영하는 것이 기본이라고 함
    • 즉 검색 순위에 반영되는 것은 현장 데이터가 반영된다고 한다
  • 현장 데이터는 Google Search Console, PSI (Page Speed Insight)에서 확인 가능

1. LCP (Largest Contentful Paint)

  • 페이지의 주요 콘텐츠(시각적으로 큰 콘텐츠)가 표시되기까지 걸린 시간을 나타내는 지표
    • 뷰포트 내에서 이미지/비디오/텍스트 블록 중 시각적으로 가장 큰 사이즈를 차지하는 블록이 처음으로 브라우저에 paint 되기까지의 시간을 의미
    • 사이즈가 큰 콘텐츠(예를들면 p태그 보다 h1태그)가 중요하기 때문에 사이즈가 큰 콘텐츠가 얼마나 빨리 표시되느냐가 중요하다고 함
  • 대상: First View
  1. 렌더링을 빠르게
    • LCP 표시까지의 Long task가 많은 케이스
    • LCP 표시까지의 Long task가 많을 경우 당연히 렌더링이 늦어지게 되므로 LCP의 점수가 낮아지게 됨
    • 즉, (LCP 표시 전까지의)CSS, JS 실행 시간을 단축하는 것이 포인트
  2. 서버 응답 시간 향상
    • 서버의 응답속도가 느린 케이스
    • LCP뿐만 아니라 서버의 응답속도가 느린 경우 여러 지표에 영향을 끼침
    • 렌더링에는 크게 문제가 없으나, 서버와의 통신에서 많은 시간이 소요되는 경우 근본적으로 서버 성능 개선이 필요하다고 볼 수 있음
  3. 파일 사이즈 단축
    • 파일 사이즈가 필요 이상으로 큰 케이스
    • 예를 들어 실제 표시되는 이미지 사이즈는 50px * 50px 임에도 불구하고 실제 불러오는 이미지는 필요 이상의 큰 사이즈인 경우가 의외로 많다
    • 즉, 필요한 최적의 사이즈 이미지 파일을 불러오도록하여 네트워크 통신량을 줄이는 것이 포인트
    • 위의 사례 외에도 webp 형식 대응도 하나의 방법
    • PNG형식과 비교하여 26% 사이즈 절감이 가능하다고 함

2. FID (First Input Delay)

  • 웹페이지 반응성에 대한 지표
  • 사용자가 최초 입력(인터랙션)이 가능하기까지 걸린 시간을 의미
    • 유저의 인터렉션 이후, 이에 대한 이벤트 핸들러를 실행할 준비가 되기(메인 스레드가 idle 해지기) 까지의 시간
  • 브라우저의 JS 엔진은 기본적으로 싱글 스레드로 작동하므로 메인 스레드에 남은 작업이 있다면 사용자가 인터랙션을 하더라도 이벤트 핸들러가 동작하지 않는다
    • 즉, 버튼은 눌렀는데도 반응을 하지 않는 상황이 일어남
  • 자바스크립트가 너무 많다거나 연산이 많은 코드를 동작시키는 등의 문제를 개선하면 SEO에 도움이 된다고 함
  • 현장 데이터에서는 실제 유저가 인터렉션을 하지 않기 때문에 FID를 측정 불가
    • 대신 이를 간접적으로 측정하는 지표인 TBT를 사용

※ 측정 기준치:100ms(50ms 로 변경될 가능성이 있다고 함)

 

처리시간이 긴 JS (Long task) 개선이 포인트

  • Long task 동안에는 유저가 페이지를 조작할 수 없게 됨
  • JS를 분할하거나 불필요한 JS를 삭제하는 것이 포인트
  • 즉, TBT 단축화 => FID 향상
    • BT (Blocking Time): 50ms 이상 소요되는 JS (처리시간이 긴)
    • TBT (Total Blocking Time): ↑BT의 합계 시간

FID 개선 순서

  1. TBT가 느린 요인을 분석 (Lighthouse나 Page Speed Insight)
  2. 원인이 되는 JS를 추출, 왜 느린지 분석
  3. 불필요한 부분을 제거/분할하거나 비동기 처리

3. CLS (Cumulative Layout Shift)

  • Layout Shift의 빈도를 정량화하여 시각적 안정성을 측정하는 지표
    • Layout Shift: 페이지 렌더링 과정에서 기존 요소들이 밀려나는 것을 의미함
    • 예를 들어, 페이지의 어느 영역을 클릭하려고 할 때 그 자리에 광고가 들어오면서 의도치 않게 광고를 클릭하게 되는 상황 (광고뿐만 아니라 다른 요소들도 마찬가지)
    • 즉, 레이아웃이 깨지거나 변경되는 경우나 요소의 위치가 바뀌어 잘못된 클릭을 유도하게 되는 것

콘텐츠의 높이(height)를 미리 지정하여 확보해두는 것이 포인트

  • 광고 콘텐츠 요소, 이미지 콘텐츠 요소가 중간에 추가되는 케이스
  • 해당 콘텐츠의 높이를 사전에 지정해 둠으로써 Layout Shift가 일어나지 않도록 할 수 있음
반응형

'생각 > TIL,WIL' 카테고리의 다른 글

패스트캠퍼스 수강 후기  (0) 2023.12.07
[TIL]2022.12.15  (0) 2022.12.15
[WIL]2022.12.04 ~ 12.11  (0) 2022.12.12
[WIL]2022.11.27 ~ 12.04  (0) 2022.12.05
[WIL]2022.11.20~26  (0) 2022.11.27