기술면접준비

1. 재귀

답변 
= 재귀를 활용하기 좋은 상황은 두 가지가 있습니다.
우선 주어진 문제를 비슷한 구조로 쪼개어 더 작은 문제로 나눌 수 있는 경우입니다.
이는 피보나치 수열의 n번째 수를 구하는 문제처럼 몇 번째 수를 구하든 동일한 구조의 작은 문제로 나눌 수 있는 구조를
재귀를 활용하면 더 간결한 코드로 문제를 해결할 수 있게 됩니다.

두번째는 중첩된 반복문이 많거나 반복문의 중첩 횟수를 예측하기 어려운 경우입니다. 이는 객체를 문자열로 바꾸는 함수에서
객체는 배열이나 객체도 담을 수 있기때문에, 얼마나 중첩되어 있는지 예측하기 어렵기 때문에 반복문을 사용하기에는 적절하지 않습니다.
이럴때 재귀를 활용하면 문제를 해결하기 용이합니다.

또한 모든 재귀 함수는 반복문으로 표현할 수 있는데, 재귀를 적용할 수 있는 대부분의 경우에는 재귀를 활용한 코드가 더욱 간결합니다.

 

 

---

2. Redux

상태관리 라이브러리의 필요성에 대해서 설명해 주세요.

답변
- 우선 우리는 서비스의 규모가 커지고 관리해야할 state가 많아지면 이를 체계적으로 관리하기 위해서 상태관리라는 라이브러리를 사용합니다.
우선 상태관리 라이브러리는 말 그대로 state를 관리를 목적으로 하는 라이브러리입니다. 대표적으로 리덕스를 말할 수 있습니다.

리덕스는 모든 state를 store라는 중앙 상태 저장소에 모든 상태를 저장하고 , 이 상태는 Reducer함수를 통해 수정될 수 있습니다.
그리고 이러한 Reducer함수는 이전 상태와 액션 객체를 dispatch로 사용가능한데요..

이러한 라이브러리가 필요한 이유는 우선 props drilling를 방지할 수 있습니다.
프롭스 드릴링은 컴포넌트가 특정값을 사용하기 위해서 여러 상위 컴포넌트에서 props를 정의하고 전달받는 과정을 말하는데
쉽게 말하자면 자식컴포넌트가 부모 컴포넌트의 상태를 사용하고자 한다면 필요없는 다른 컴포넌트에서 props를 전달받으며 사용해야 하는 문제인데요
이러한 상황에선느 사용하지도 않는 props를 정의해야하고, 필요없는 코드들이 증가합니다. 이러한 문제를 상태관리 라이브러리를 사용한다면
피할 수 있습니다.

또 컴포넌트를 순수함수로 유지할 수 있습니다. 리액트의 컴포넌트는 순수 함수로 유지되도록 하는것을 권장하는데
외부데이터를 가져와 사용하거나,. 브라우저 이벤트에 의존한다면 순수함수를 유지할 수 없습니다. 이럴때 상태관리 라이브러리를 사용한다면
순수함수 컴포넌트로 만들어 줄 수 잇씁니다.

Redux는 앱의 상태를 중앙에서 관리하기 때문에 디버깅이 쉽습니다. Redux DevTools와 같은 도구를 사용하면 앱의 상태 변화를 쉽게 추적할 수 있습니다.
따라서 상태 관리 라이브러리는 React와 함께 사용하면 상태 관리를 더욱 예측 가능하고 일관된 방식으로 관리할 수 있으며, 코드의 가독성을 높이고 디버깅을 쉽게 할 수 있도록 도와줍니다.

 

 

---

3. 웹 표준 & 웹 접근성

Semantic HTML의 필요성을 예시를 들어 설명해 주세요.

답변
- 시맨틱 html이란 각 html 태그가 포함하는 내용에대한 정보를 제공한다는 것을 의미합니다.
div 나 span태그는 정보를 제공하지 못하기떄문에 시맨틱하지 못하지만 만약 header나 main, footer같이 어느정도 예측할 수 있다면
시맨틱하다고 합니다. 이렇게 왜 시맨틱한 html이 필요할까요? 

"Semantic HTML은 구조를 만드는 것을 넘어 의미를 갖게 만드는데 필요합니다.
시맨틱 요소의 예시로는 header, main, nav, footer tag 등이 있는데,

HTML에는 많은 종류의 요소가 있지만, div와 span tag 두 가지 요소만 알아도 충분히 화면의 구조를 만들 수 있습니다.
하지만, 이 두 요소의 이름에는 의미가 없기 때문에 요소의 이름으로는 각 요소가 어떤 역할을 하는지 알 수 없습니다.
하지만 시맨틱 요소를 사용하면 요소의 이름만 보고도
해당 요소가 어떤 역할을 하는지, 요소가 가진 의미를 통해 파악할 수 있게 됩니다.
시맨틱한 HTML을 작성하면 개발자간 소통, 검색 효율성, 웹 접근성에 효과를 볼 수 있습니다.
요소의 이름만 봐도 의미를 파악할 수 있기 때문에 그만큼 의미를 전달하기 위한 시간과 id, class 작성에 필요한 시간 소모도 줄어들고 
개발자간 소통이 원활해집니다. 또한 검색 엔진은 HTML 코드를 보고 문서의 구조를 파악하기 때문에 시맨틱 요소를 사용함으로써 HTML에 의미를 부여하는 것만으로도 검색 효율성을 높일 수 있습니다.
마지막으로 시맨틱 요소를 사용하면 화면의 구조를 짜는 것을 넘어 구조에 대한 정보를 전달할 수 있어 요소에 담긴 콘텐츠도 더 명확하게 전달할 수 있으므로 웹 접근성을 향상시킬 수 있습니다"


1. 검색 엔진 최적화 (SEO, Search Engine Optimization)

검색 엔진을 가지고 있는 사이트는 봇을 사용해 각 사이트의 정보를 수집한다. 시맨틱 태그를 통해 구성된 사이트는 태그 자체가 의미를 가지기 때문에 봇이 정보를 수집하기 용이하다. 즉, 검색 엔진 최적화(SEO)에 유리하다.

2. 접근성 (accessibility)

시맨틱 태그를 사용한 사이트는 코드를 보다 쉽게 interpret 할 수 있다. 따라서 다양한 디바이스나 브라우저를 통해 접근하더라도 더욱 쉽게 사이트를 보여줄 수 있게 된다. 즉, 사이트의 접근성이 높아진다. 특히 시각장애인들의 경우에는 사이트 문서를 읽어주는 스크린 리더를 사용하는데, 이 경우에도 시맨틱 태그를 활용한 사이트가 훨씬 유리하다.

3. 코드의 간결성 & 가독성

<div>, <span> 과 같이 의미가 불분명한 태그로 코드를 작성하면, 태그가 감싸고 있는 컨텐츠가 어떤 내용인지 바로 이해하기 어렵다. 반면 시맨틱 태그는 감싸고 있는 내용이 어떤 의미인지를 내포하고 있다는 점에서 코드를 한눈에 이해하기 쉽다. 즉, 코드가 간결해지고 가독성이 좋아진다.

---

4. 네트워크 심화

HTTP 프로토콜의 특징에 대해 설명해 주세요.

답변
- 모든 형태의 데이털르 전송할 때 http를 사용하는데 이러한 http의 특징은 4가지가 있습니다.

1. Client-Server 구조  = 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있다.
Request Response 구조
클라이언트는 서버에 요청을 보내고 응답을 대기
서버가 요청에 대한 결과를 만들어 응답

2. 무상태성(Stateless)
HTTP에서 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다.
간단한 예시를 들자면 이렇다.
클라가 서버에게 “저녁에 치킨먹자”고 말했고 서버가 “그래”라고 답했다.
저녁이 되어 클라는 서버에게 “먹으러 가자”고 말했고 서버는 대답했다. “뭘?”
서버가 클라이언트 상태를 보존하지 않음
장점 : 서버 확장성 높음 (스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송

3. 비연결성(Connectionless)
4. 단순/확장 가능

1. Client-Server 구조
답변
Client-Server 구조에서 각각의 Server와 Client는 독립되어 있다.

Client는 Server에 요청(Request)를 보내고 응답이 올 때까지 대기하고,

Server는 Client에서 받은 요청(Request)에 대한 결과를 만들어 응답을 하는 것이다.

즉 Client-Server 구조는 Request-Response 구조와 같은 것이다.

Server에서 비즈니스 로직과 데이터를 Client에 독립적으로 처리할 수 있도록 만든 구조이다.

즉, Client와 Server는 독자적으로 발전할 수 있어 빠르게 발전해왔다.



2. 무상태성(Stateless)

Stateless란, 말 그대로 서버가 클라이언트의 상태를 저장하지 않는다는 것이다.

Stateful과 대비되는데, 두 사례를 각각 생각해보자.

(1) Stateful
일상 생활에서 이러한 상황을 생각해보자.

손님: 노트북 모델 Z의 가격은 얼마인가요?
직원: 100만원입니다.

손님: 이 모델 2개 구매하겠습니다.
직원: 총 200만원입니다. 현금으로 결제하실까요, 카드로 결제하실까요?

손님: 카드로 결제하겠습니다.
직원: 200만원 결제 완료되었습니다. 감사합니다.
이 상황에서 우리는 직원이 손님의 이전 상태를 저장하고 있음을 알 수 있다.

즉, 직원이 Context를 보존하고 있는 것이다.

→ 첫 대화에서 도출한 response인 ‘모델 Z의 가격’이라는 정보를 2번째 대화에서 활용하고 있고, 2번째 대화에서 도출한 response인 ‘총 구매 금액’을 3번째 대화에서 사용하고 있다. 즉, Client의 Context(State)가 저장되고 있는 상황인 것이다.

→ 하지만, 이 상황에는 문제가 있다. 그 고객에 대해 같은 직원이 응대해야하는 것이다. 즉, 같은 Client에 대해 항상 같은 Server가 응답해야하므로 Scale-Up을 기대하기는 힘들다.

(2) Stateless
반면, Stateless는 Stateful과 다르게 밑과 같은 상황으로 비유될 수 있다.

손님: 노트북 모델 Z의 가격은 얼마인가요?
직원A: 100만원입니다.

손님: 이 모델 2개 구매하겠습니다.
직원B: 어떤 모델 말씀이실까요?

손님: 카드로 결제하겠습니다.
직원C: 어떤 모델을 몇 개 구매하시는 건가요?
위 대화는 Stateless의 상태이다. 즉, 손님의 이전 정보(context/state)를 저장하지 않으므로 위와 같은 상황이 벌어진다. 이를 해결하기 위해선 어떻게 해야 할까?

A: 정보를 계속해서 추가해서 요청을 보내야한다.

즉, 밑과 같이 대화를 해야한다.

손님: 노트북 모델 Z의 가격은 얼마인가요?
직원A: 100만원입니다.

손님: 노트북 모델 Z를 2개 구매하겠습니다.
직원B: 200만원입니다. 카드로 결제하시나요, 현금으로 결제하시나요?

손님: 노트북 모델 Z 2대를 카드로 결제하겠습니다.
직원C: 총 200만원 결제되었습니다. 감사합니다.
Stateful의 대화와 전혀 다른 방식이다.

첫 번째 대화에서 손님(=Client)이 구매할 모델을 Server(여기서 직원)가 저장하지 않으므로 두 번째 요청에서 구매할 노트북 모델 정보와 구매할 양을 보낸다. 그리고, 세번째 요청에서는 두 번째 요청의 정보에 결제 수단까지 추가로 요청 정보에 추가를 해서 보낸다.

→ 즉, Request를 보낼 때 Client가 추가 데이터를 전송해야한다는 문제점이 존재한다.

→ 하지만, 이러한 Request 방식은 항상 같은 서버에 연결될 필요가 없으므로 Scale-Up에 유리하다.


3. 비연결성(Connectionless)
요청을 한 후 응답을 받으면 바로 연결을 종료한다. → 즉, 불필요한 연결을 하지 않아 서버 유지 자원이 감소하는 것이다.

→ 서버 유지 자원을 효율적으로 사용 가능하다.


4. 단순/확장 가능
HTTP가 이렇게까지 성공할 수 있었던 이유는, 단순하며 확장 가능하기 때문이다.

클라이언트에서 요청이 발생하면 TCP의 3-way handshake를 통해 연결하고,

서버에서 결과를 처리하여 응답을 받으면 4-way handshake를 통해 연결을 해제한다.

즉, 요청-응답 과정에서만 연결이 되고, 사용 안 할 땨는 연결을 바로 끊어버리고(connectionless),

클라이언트의 상태를 저장하지 않는(stateless) 단순한 과정을 거치기 때문에 HTTP가 이렇게까지 성장할 수 있었다.

최근 HTTP/3.0에서는 UDP를 사용하긴 하지만, 아직은 HTTP/1.1이 대세이므로 단순/확장 가능이 큰 특징 중 하나라고 생각하자.