10.7 기술면접 공부 정리

알고리즘 및 자료구조 관련 문제

 

1. 링크드 리스트 vs 어레이

- 구조 

배열 : 연속된 메모리 공간에 데이터를 저장하고, 각 요소는 인덱스르 통해 접근한다.

링크드 리스트 : 각 요소가 데이터와 다음 노드에 대한 포인터를 포함한다. 메모리 공간이 연속적이지 않다.

 

- 크기

배열 : 고정 크기로 선언된다. 크기 변경이 불가능한다.

링크드 리스트 : 동적 크기로, 노드를 추가하거나 제거할 수 있어서 크기가 유동적이다.

 

- 접근 시간

배열 : 인덱스를 사용하기에 O(1)의 시간복잡도

링크드 리스트 : 특정 노드에 접근하려면 O(n)이 걸릴 수 있다.

 

- 삽입 및 삭제

배열 - 삭제 후 남은 요소들을 이동해야 하므로 O(n)의 시간복잡도

링크드 리스트 - 노드의 포인터만 변경하면 되므로 O(1)시간에 삽입 및 삭제가 가능하지만 , 특정 노드를 찾는데 O(n)이 걸릴 수 있다

 

- 메모리 사용

배열 - 메모리 공간이 고정되어 있어서 , 사용하지 않는 공간이 낭비된다.

링크드 리스트 - 필요한 만큼의 메모리만 사용되므로 효율이 상대적으로 좋을 수 있다.

 

2. 힙(Heap) 이란?

Heap 은 완전이진트리 형태의 자료구조 이다.

여러 값중 최대, 최소를 빠르게 찾아내도록 만들어진 자료구조 이다.

 

종류는 최대힙(루트노드가 가장 큰 값을 가진다) , 최소힙 (루트노드가 가장 작은 값을 가진다) 2가지가 있다.

 

- 시간 복잡도

삽입 , 삭제는 O(logn) 

최대 최소 조회는 O(1) => 루트 노드 조회!

 

- 삽입 , 삭제

삽입 - 트리의 마지막에 추가하고 비교하여 위치를 조정한다.

삭제 - 루트노드를 삭제하고 마지막 노드를 루트로 이동한 후 , 자식 노드와 비교하여 위치를 조정한다.

 

3. 해시 테이블 이란?

Hash 란 각각의 데이터를 고유 숫자 값으로 표현하고 , 이를 이용하여 특정 데이터의 존재 여부를 확인하거나 데이터를 추출하는 작업이다.

 

Hashing의 과정에는 Hash함수 , Hash 테이블이 사용된다.

 

Hash Table은 데이터를 효율적으로 저장하고 검색하기 위해 사용하는 자료구조 이다.

 

Hash 함수를 이용하여 key를 Hash value로 변환하고 , 이 Hash값을 인덱스로 사용하여 데이터를 저장한다.

 

Hash 함수를 통해 데이터가 교유한 숫자 값으로 변환되면 , Hash Table에 접근하여 데이터를 조회하거나 추출하게 된다.

 

이때 해시함수가 서로다른 키에 대해 같은 Hash 값을 반환함으로 Hash Table의 같은 위치에 두개 이상의 데이터가 저장되려는 현상을 충돌이라고 한다.

 

- 충돌 처리

1. 체이닝 - 동일한 해시 값을 가진 요소들을 연결리스트로 저장

2. 리니어 프로빙 (Linear Probing) - 충돌이 일어나면 해당 해시값의 다음 값부터 순회를 시작하여 처음으로 나오는 Hash Table의 빈 공간에 데이터를 저장한다.

 

-Hash Table 사용 이유는?

- 해시 테이블은 데이터 저장 & 검색 속도가 빠르다. (검색할때 시간 복잡도 - O(1))

- 해당 키에 대한 데이터가 이미 존재하는지 중복확인이 쉽다 => 캐쉬를 구현할 때 사용 (중복 확인이 빨라 바뀐 정보가 있는지 없는지를 빠르게 조회 가능하다.)

 

저장공간이 많이 필요한게 단점이다!

 

네트워크

1. Http 와 Https의 정의와 차이는?

Http : Hyper Text Transfer Protocol 

Https : Http + Secure

 

둘다 웹에서 데이터를 전송하는데 사용하는 프로토콜이다.

 

-Http

 

Http는 웹 브라우저와 서버 간에 데이터를 전송하기 위한 프로토콜이다.

주로 Html 문서 , 이미지 , 비디오 등 다양한 형식의 데이터를 전송할 때 사용된다.

특징 - 각 요청과 응답이 독립적이며 , 연결이 유지되지 않는다.

기본보트 - 기본적으로 포트 80을 사용한다.

데이터 전송시 암호화 되지 않으므로 , 중간에서 데이터가 변조되거나 도청 될 수 있다.

 

-Https

데이터의 기밀성과 무결성을 위하여 SSL, 또는 TLS 프로토콜을 사용하여 데이터 전송을 암호화 한게 Https이다. (Http의 보안보전)

기본포트 - 기본적으로 포트 443을 사용합니다.

인증서를 통해 서버의 신원을 확인할 수 있다.

보통 구글은 Https를 사용하는 웹사이트에 대하여 SEO에서 높은 우선순위를 부여한다.

 

2. Http 메소드에는 어떤 것이 있나요?

크게 8가지가 있지만, 주로 사용되는 것은 GET , POST , PUT , DELETE , PATCH 총 5가지 이다.

 

-GET

  - 리소스를 조회하는 메서드

  - url 입력 , 링크 클릭도 get 요청에 해당함

  - 멱등성 존재  - 여러번 조회해도 리소스는 변하지 않는다.

  - get요청에서 서버에 데이터를 전달하는 경우, 쿼리스트링을 통해서 전달

 

-POST

  - 리소스를 생성하는 메서드

  - 성공적으로 완료하면 201(Created) HTTP 응답을 반환

  - 데이터를 메세지 바디에 key-value 형식으로 전달

  - GET 과 비교하면 데이터가 외부로 노출되지 않으므로 보안상 이점이 있음

  - POST는 조회가 가능하지만, 멱등성이 없으므로 같은 결과값이 나오는 것을 보장 안함 , 추가로 GET은 캐싱을 이용하므로 조회속도도 POST에 비하여 우수함

  - body에 담아 전송하므로 , 메세지 길이의 제한이 없음

 

-PUT

  - 리소스를 완전히 대체 (덮어쓰기)

  - 부분수정이 불가하고, 멱등성을 지님

 

-PATCH

  - PUT 처럼 리소스 수정 역할이지만, 리소스를 부분 변경함

  - PATCH 메서드를 지원하지 않는 서버가 있음  (그럴 경우 POST사용)

  - 멱등성을 지니지 않음

 

-DELETE

  - 리소스를 제거

  - 멱등성을 지님

 

  

3. TCP와 UDP의 차이는?

TCP - Transmission Control Protocal : 전송 제어 프로토콜

 

인터넷을 통해 디바이스에서 웹 서버로 데이터를 전송하는 네트워크 프로토콜이다.

TCP는 연결 기반이므로, 데이터를 전송하는 동안 수신자와 발신자 사이에 연결을 설정하고 이를 유지한다.

데이터가 완전하게 도착하도록 보장한다 => 메신저, 이메일 , 웹 검색등에서 사용한다.

 

장점 

 

TCP는 운영체제와 독립적으로 작동하므로 시스템과 디바이스 간 상호 운용성이 향상된다.

TCP는 데이터를 전송할 때 오류를 검사하여 전송된 데이터가 목적지에 온전하게 도달하도록 보장한다.

TCP는 수신자의 용량에 따라 데이터를 전송하는 속도를 최적화하고 변경한다.

TCP는 데이터가 목적지에 도달했는지 확인하고 실패한 경우 재전송을 시도한다.

 

단점

 

TCP는 상당히 많은 대역폭을 사용하여, UDP 보다 속도가 느리다.

전송중에 소량의 데이터라도 손실되면 다른 정보를 로드하지 못할 수 있다. ex) 페이지에서 이미지같은 한 요소가 로드되지않으면 다른 페이지 데이터도 로드되지 않을 수 있음

근거리 통신망이나 개인 영역 네트워크에서 제대로 작동하지 않음

 

 

UDP - User Datagram Protocol : 사용자 데이터그램 프로토콜

 

TCP에 비해 안전성은 떨어지지만 더 빠르고 간단하다. - 게임같은데에 쓰인다.

비연결 방식이므로 사전연결을 설정하지 않는다.

 

장점

 

- 더 작은 패킷을 더 적은 오버헤드로 전송하여 엔드투엔드 지연을 줄인다.

- 일부 패킷이 누락되더라도 데이터를 전송하므로 패킷 손실로 인해 전체 전송이 중단되지 않는다.

- 브로드 캐스트 및 멀티 캐스트 기능을 통해 하나의 UDP 전송을 여러 수신자에게 한 번에 전송할 수 있다.

- UDP 전송은 TCP 보다 빠르고 효율적이다.

 

단점

- 성공적으로 데이터가 도달했는지 여부를 확인하지 않는다.

- 온전하게 데이터가 도착한다고 보장할 수 없다.

- 라우터가 데이터 패킷의 우선순위를 정하는 경우 , UDP 패킷보다 TCP 패킷을 먼저 전송할 가능성이 높다.

- 패킷이 어떤 순서로든 도착할 수 있다.

 

요약 => 안전성은 TCP , 빠른거는 UDP

 

 

4. 쿠키와 세션 , 웹스토리지의 정의와 차이는?

Http 프로토콜은 비연결지향 + 상태정보유지를 하지 않음 

=> 쿠키와 세션은 해당 약점을 보완하기 위하여 사용

 

쿠키 : 사용자가 웹사이트 방문시 , 해당 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일

Http에서 클라이언트의 상태정보를 쿠키형태로 클라이언트 PC에 저장하였다가 필요시 정보를 참조하거나 재사용

 

세션 : 일정 시간동안 사용자로부터 들어오는 요구를 하나의 상태로 보고, 브라우저 종료전까지 클라이언트의 요청을 유지

서버에 저장되고 브라우저를 닫으면 삭제됨, 보안적으로 중요한 정보들을 서버안에서 다루기 위해 사용한다.

 

웹스토리지 : 클라이언트에 데이터를 저장한다. 

로컬 스토리지 - 데이터 영구저장 (로그인 자동)

세션 스토리지 - 브라우저 닫으면 초기화 (입력폼 저장)

쿠키대신 사용하는 이유 => 네트워크 요청시 서버로 전송되지 않고, 더 많은 자료를 보관가능 (쿠키는 서버로 전송 / 웹스토리지는 클라측에서만 접근 가능)

 

쿠키와 세션의 가장 큰 차이는 저장 위치

쿠키 - 클라이언트의 웹 브라우저가 지정하는 메모리

세션 - 서버의 메모리 

또한 쿠키는 클라이언트도 모르게 접속되는 사이트에 의해 설정될 수 있기 때문에 한 도메인당 20개, 한개의 쿠키 당 4kb로 제한

세션은 용량이나 개수 제한없음

 

4. 웹소켓 vs SSE vs Polling vs Long polling 

웹소켓 - 요청한 클라이언트에만 응답하는 것이 아닌 (Http) , 웹 소켓 프로토콜을 통해서 웹 소켓 포트에 접속한 모든 클라이언트에게 이벤트 방식으로 응답함 (연결을 한번만 맺으면 됨)

전이중 연결과 웹소켓 서버가 필요함

방화벽을 열지 않고도 양방향 통신 가능함

트래픽이 많은 서버의 경우 CPU 부담 갈 수 있음

 

SSE (Server Sent Events) - Html5 표준안, 서버에서 클라이언트 단방향 통신 , 웹 소켓은 서버와 클라간의 연결을 유지해야 하지만, SSE의 경우 Http 연결만 되어 있으면 클라이언트 요청이 없이도 서버에서 클라이언트로 데이터 보낼 수 있음.

Real-Time Push Notification 전송 가능

 

Polling & Long Polling - 클라이언트에서 Http request 를 주기적으로 서버로 날려서 이벤트 내용을 전달 받음

구현은 쉽지만 계속해서 request가 들어오면 서버의 부담이 많아지고 클라이언트의 응답 받는 속도도 저하

대시보드 처럼 일정하게 계속 갱신되어야 하는 데이터의 경우 사용

=> 이를 보완한 Long Polling : 서버 쪽에서 Http 응답에 대한 접속 시간을 늘림, 하지만 다수의 클라이언트에서 동시에 이벤트 발생한 경우 서버의 부담이 급증함

 

 

 

 

 

 

프론트엔드 전반

 

1. 브라우저 렌더링의 과정

로더가 서버로부터 전달받은 리소스 스트림을 읽음

DOM , CSSOM 생성 - 파서가 문서를 파싱해 생성함

브라우저의 자바스크립트 엔진은 서버로부터 응답된 자바스크립트를 파싱하여 AST(Abstract Syntax Tree)를 생성 이때 JS는 DOM API를 통해 DOM , CSSOM 변경 가능

DOM , CSSOM 으로 렌더링 트리 생성

레이아웃 - 렌더링 트리를 토대로 그려질 노드와 스타일 , 크기를 계산

페인트 - 렌더링 트리의 각 노드를 실제 픽셀로 변환함

 

2. CSR 과 SSR의 차이는?

CSR : Client Side Rendering

클라이언트에서 JS를 사용하여 페이지를 렌더링하는 방식 

초기 html페이지가 로드 된후 , js가 클라이언트에서 실행되어 필요한 데이터를 가져오고 , dom을 업데이트하여 보여줌

초기 로딩시 html, css, js가 모두 다운되어야 하므로 첫 페이지 로딩시간이 김

대신 상호작용이 빠름

검색엔진이 js를 실행하진 않아서 검색엔진최적(SEO)에 불리

 

 

SSR : Server Side Rendering

서버에서 HTML 페이지를 렌더링하여 클라이언트에 전송함

서버에서 렌더링 완료된 HTML만 전송받아 초기 로딩 시간이 짧고 사용자가 빠르게 콘텐츠 볼 수 있음

페이지 전환 시 전체 다시 로드해야 하므로 CSR보다 사용자 경험이 별로임

SEO에 유리함

 

3. Rest API란?

REST API(Representational State Transfer Application Programming Interface)는 웹 기반의 API 설계 원칙 중 하나로, 클라이언트와 서버 간의 통신을 위한 아키텍처 스타일

REST는 HTTP 프로토콜을 기반으로 하며, 웹 리소스에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하는 데 사용됨

 

-REST API는 리소스를 URI(Uniform Resource Identifier)로 식별 , 클라이언트는 이 URL을 통해 리소스에 접근함

-REST API는 HTTP 메소드를 사용하여 리소스에 대한 작업을 수행 (GET , POST....)

 

REST 아키텍처는 클라이언트와 서버 간의 중간 계층(예: 프록시 서버, 게이트웨이 등)을 허용

 

=> Restful 아키텍쳐를 따르는 API는 개발자에게 직관적이고 사용하기 쉬운 인터페이스를 제공한다!

 

 

 

4. 주소창에 웹 주소를 입력했을때의 흐름

1. 브라우저 검색창에 주소 입력
2. 브라우저는 캐싱된 dns 기록을 통해 해당 도메인 주소와 대응하는 ip주소 확인
3. 캐싱된 기록 없으면 http를 사용하여 dns에 입력된 도메인 주소 요청
4. dns가 웹브라우저에게 찾는 사이트의 ip주소를 응답
5. 웹브라우저가 웹서버에게 Ip주소를 이용하여 html문서 요청
6. 웹어플리케이션서버와 데이터베이스에서 웹페이지 작업을 처리
7. 위 처리 결과를 웹서버로 전송
8. 웹서버는 웹브라우저에게 Html문서 결과를 응답
9. 웹브라우저는 화면에 웹페이지 내용물 출력

 

 

5. 리액트는 이벤트 위임을 사용하는가?

리액트는 이벤트 위임 (Event Delegation) 방식을 사용한다.

이벤트 위임은 이벤트 리스너를 부모 요소에 등록하고, 자식 요소에서 발생하는 이벤트를 부모 요소가 처리하는 방식이다.

이벤트 위임의 작동 방식

1. 부모 요소에 이벤트 리스너 등록 : 이벤트 리스너를 DOM의 최상의 요소에 등록한다. 이로 인해 자식 요소에서 발생하는 이벤트는 부모 요소에서 처리된다.

2. 이벤트 전파 : 자식 요소에서 이벤트가 발생하면, 이벤트는 DOM트리를 따라 부모 요소로 전파된다. 이 과정에서 React는 이벤트를 캡쳐하고, 이벤트가 발생한 자식 요소에 대한 정보를 확인한다.

3. 성능 최적화 : 이벤트 위임을 사용하면 , 각 자식 요소에 개별적으로 이벤트 리스너를 등록한 필요가 없으므로 메모리 사용을 줄이고 성능을 최적화 할 수 있다.

 

이벤트 위임은 이벤트 버블링을 활용하여 이벤트를 처리하는 방법이다.

React는 이벤트 버블링을 통해 부모 요소에 등록된 이벤트 리스너가 자식 요소에서 발생한 이벤트를 처리할 수 있도록 하여, 코드의 간결성과 성능을 향상시킨다.

 

CSS 

1. 박스 모델이란?

모든 html요소는 박스 모델을 기반으로 렌더링 되며 , 요소의 크기와 위치를 결정하는 모델이다.
콘텐츠 - 패딩 - 보더 - 마진 

박스 모델은 웹 페이지의 요소가 어떻게 구성되고 표시되는지를 이해하는 데 중요한 개념!!

 

2. 인라인 요소 vs 블록 요소

인라인요소는 새로운 줄에서 시작하지 않고 필요한 만큼 너비만 차지 - span , img
블록요소는 새로운줄에서 시작하고 전체 너비 차지 - div 

 

JS

1. Js 에서 This 는?

자바스크립트의 경우 함수 호출 방식에 의해 this에 바인딩할 객체가 동적으로 결정된다.

1) 첫번째, 일반 함수로 호출된 경우 this는 전역 객체. 그리고 이 this는 브라우저에서 window 객체가 됨. (Node.js 에서는 global)
2) 두번째, 메소드로 호출되었다면 this는 해당 메서드가 속한 객체를 가리킴
3) 세번째, 함수가 호출될 때 apply, call 또는 bind가 사용되었다면 첫번째 인자로 전달하는 값에 this 를 바인딩 합니다.
4) 마지막으로 함수가 호출될 때 생성자 함수 내부에서의  this는 새로운 객체를 참조. new 키워드로 생성자 함수를 호출할 때, this는 새로 생성된 객체를 가리킴

 

 

2. 콜백함수란?

콜백함수는 파라미터로 전달받은 함수를 말한다.  
파라미터로 콜백함수를 전달받고 함수 내부에서 필요할 때 콜백함수를 호출할 수 있다.

 

- 함수를 인자로 받기 때문에 필요에 따라 함수의 정의를 달리해 전달할 수 있다.
- 함수를 굳이 정의하지 않고 익명 함수로도 전달 가능하다.

 

 

3. Async / Await

가장 최근의 나온 비동기 처리 문법으로 기존의 `callback` 이나 `Promise` 의 단점을 해소하고자 만들어졌다.

`callback` 이나 `Promise` 의 경우에 단점은 꼬리에 꼬리를 무는 코드가 나올 수도 있다. 흔히들 콜백 지옥, then() 지옥이라고 부른다.

 

`await` 를 통해 `Promise` 반환 값을 받아 올 수 있다. `await` 는 `async` 함수 안에서만 동작한다.

 

Promis~ then 과의 차이점

- 에러 핸들링
    - `Promise` 를 활용할 시에는 `.catch()` 문을 통해 에러 핸들링이 가능하지만, `async/await` 은 에러 핸들링 할 수 있는 기능이 없어 `try-catch()` 문을 활용해야 한다
- 코드 가독성
    - `Promise`의 `.then()` 지옥의 가능성
    - 코드가 길어지면 길어질수록, `async/await` 를 활용한 코드가 가독성이 좋다.
    - `async/await` 은 비동기 코드가 동기 코드처럼 읽히게 해준다. 코드 흐름을 이해 하기 쉽다.

 

 

4. var , let , const 차이

`var` 에서는 중복 선언과 재할당이 모두 가능하다.  
마지막에 할당된 값이 최종으로 변수의 값으로 저장된다.
`var` 변수가 선언된 함수 내부의 어디서든 참조가 가능하지만, 외부로는 참조가 불가능하다.
`var` 는 호이스팅이 발생한다.


`let` 에서는 중복 선언을 허용하지 않는다. 재할당은 가능하다
`let` 과 `const` 는 블록 단위 스코프(block-level scope)이다


`const` 에서도 `let` 과 동일하게 중복 선언을 허용하지 않는다. 재할당도 불가하다
`let` 과 `const` 는 블록 단위 스코프(block-level scope)이다


`let` , `const` 는 호이스팅이 발생하지만, 다르게 작동한다.
`let` , `const` 로 변수를 선언하는 경우에는, 변수의 선언과 초기화 사이에 일시적으로 변수 값을 참조할 수 없는 구간인 `TDZ(Temporal Dead Zone)` 가 존재하기 때문에 벌어지는 현상이다.

호이스팅은 발생하지만, 값을 참조할 수 없기 때문에 동작하지 않는 것처럼 보인다.

 

 

5. 호이스팅 이란

JavaScript에서 호이스팅(hoisting)이란, 인터프리터가 변수와 함수의 메모리 공간을 선언 전에 미리 할당하는 것을 의미한다.

var로 선언한 변수의 경우 호이스팅 시 undefined로 변수를 초기화한다.

반면 let과 const로 선언한 변수의 경우 호이스팅 시 변수를 초기화하지 않는다.

 

호이스팅은 코드가 실행하기 전 `변수선언/함수선언`이 해당 스코프의 최상단으로 끌어 올려진 것 같은 현상을 말한다.

- 자바스크립트 엔진은 코드를 실행하기 전 실행 가능한 코드를 형상화하고 구분하는 실행 컨텍스트를 위한 과정을 거친다.
- 자바스크립트 엔진은 코드를 실행하기 전 실행 컨텍스트를 위한과정에서 모든 선언(var, let, const, function, class)을 스코프에 등록한다.
- 코드 실행 전 이미 `변수선언/함수선언`이 저장되어 있기 때문에 선언문보다 참조/호출이 먼저 나와도 오류 없이 동작한다.  
    (정확히는 var 키워드로 선언한 변수와 함수 선언문일 경우 오류 없이 동작한다. 이는 선언이 파일의 맨 위로 끌어올려진 것 처럼 보이게 한다.)
- 실행 컨텍스트는 실행 가능한 코드가 실행되기 위해 필요한 환경을 의미하고 실행되기전 이러한 실행 컨텍스트 과정(코드를 구분하는 과정)을 거친다.

 

6. 스코프와 클로저

스코프 : 변수가 유효한 범위 , JS에서는 렉시컬 스코프를 따른다. JS는 코드를 실행하기 전에 렉시컬 환경을 먼저 분석한다.

 

클로저 : 함수와 그 함수가 선언된 렉시컬 환경의 조합 , 클로저를 통해 외부 스코프에서 선언된 변수를 내부 함수에서 접근할 수 있게 된다.

데이터 은닉과 캡슐화를 가능하게 한다.

 

 

7. 실행 컨텍스트 

실행 컨텍스트 : 실행할 코드에 제공할 환경 정보들을 모아놓은 객체

JS는 동일한 환경에 있는 환경 정보들을 모은 실행 컨텍스트를 콜스택에 쌓아올린 후 실행하여 코드의 환경과 순서를 보장할 수 있게 된다.

 

 

TypeScript

1. Type vs Interface

interface => extends 로 확장

type => & 기호로 확장

 

interface는 속성간 충돌을 해결하기 위한 단순한 객체의 타입을 만든다.

그러나 타입의 경우, 재귀적으로 순회하면서 속성을 머지 하는데, 이경우 일부에서 Never가 나오면서 머지가 안될 수 있다 (type은 원시 타입이 올 수도 있으므로 , 충돌이 나서 제대로 머지가 안되는 경우에 Never가 나옴)

 

=> `type`은 새로운 속성을 추가하기 위해서 다시 같은 이름으로 선언할 수 없지만, `interface`는 항상 선언적 확장이 가능하다

 

2. TypeScript 사용하는 이유는?

1. 정적 타입 검사 - 컴파일 타임에 타입 검사를 수행하여 런타임 오류를 사전에 방지한다.

2. 코드 가독성 및 유지보수성 향상