Section3 기술면접

Q. UI, UX의 개념과 두 개념의 관계에 대해서 설명해 주세요.

UI는 사용자 인터페이스를 의미합니다. 
즉, 사용자가 애플리케이션 또는 웹사이트와 상호작용하는 방식을 디자인하는 것입니다. 
UI 디자인은 사용자가 더 쉽게 애플리케이션을 이해하고 사용할 수 있도록 하는 것이 목적입니다. 
따라서 UI 디자인은 주로 디자인, 레이아웃, 색상, 폰트 등과 같은 시각적인 측면을 중심으로 합니다.

반면, UX는 사용자 경험을 의미합니다. 
UX 디자인은 사용자가 제품 또는 서비스를 사용하는 동안 느끼는 감정, 경험, 만족도 등을 고려하여 제품이나 서비스를 디자인하는 것입니다. 
즉, UX 디자인은 사용자가 원하는 기능을 쉽고 간편하게 이용할 수 있도록 설계하는 것입니다. 
따라서 UX 디자인은 UI 디자인뿐만 아니라 사용자의 행동, 욕구, 생각 등을 고려하여 설계합니다.
즉, UI 디자인은 UX 디자인의 일부분으로서 사용자 경험을 개선하기 위한 요소 중 하나입니다. 

결론적으로, UI와 UX는 사용자의 만족도를 높이기 위해 서로 밀접한 관계를 가지고 있는 두 개념입니다.

 

Q. Styled Components를 사용해 보면서 느낀 장점을 이야기해 주세요.

Styled Components는 React 애플리케이션에서 컴포넌트 스타일링을 하는 데 사용되는 JavaScript 라이브러리입니다. Styled Components를 사용하면 CSS와 JavaScript를 함께 사용할 수 있으므로, 스타일을 컴포넌트에 적용하는 방법이 매우 직관적이고 간단해집니다. 
Styled Components를 사용하면 다음과 같은 장점을 누릴 수 있습니다.

1.컴포넌트 기반 스타일링
Styled Components를 사용하면 컴포넌트를 정의할 때 스타일을 동시에 정의할 수 있습니다. 
이를 통해 각각의 컴포넌트를 독립적으로 스타일링할 수 있으며, 이는 애플리케이션 유지보수 및 개발 생산성 측면에서 매우 효과적입니다.

2.스타일 재사용성
Styled Components는 컴포넌트 단위로 스타일을 정의하므로, 스타일 재사용성이 매우 높아집니다. 
예를 들어, 특정 스타일을 정의한 컴포넌트를 다른 컴포넌트에서 재사용할 수 있습니다.

3.Props를 활용한 동적 스타일링
Styled Components는 컴포넌트의 props를 활용하여 동적인 스타일링을 할 수 있습니다. 
예를 들어, 버튼의 크기나 색상 등을 props로 전달하여 스타일링할 수 있습니다.

 

Q. useRef는 React에서 참조할 DOM 요소나 컴포넌트의 인스턴스를 저장하기 위해 사용되는 Hook입니다. 
useRef를 사용하면 다음과 같은 상황에서 유용하게 사용할 수 있습니다.

1. DOM 요소에 직접 접근해야 할 때
React에서 DOM 요소에 접근하려면 일반적으로 refs를 사용합니다. 
useRef를 사용하면 컴포넌트의 렌더링과 관계없이 DOM 요소에 직접 접근할 수 있습니다.
 이를 통해, DOM 요소에 대한 참조를 유지하고, 다양한 조작을 수행할 수 있습니다.
예를 들어, input 요소에 포커스를 주거나, scrollTop 값을 변경하여 스크롤 위치를 제어할 수 있습니다.

2. 컴포넌트에서의 인스턴스를 유지해야 할 때
React에서 컴포넌트 인스턴스를 유지하려면 refs를 사용합니다. 
useRef를 사용하면 컴포넌트 인스턴스를 참조하고 유지할 수 있습니다. 
이를 통해, 인스턴스에 대한 참조를 유지하고, 다양한 조작을 수행할 수 있습니다.
예를 들어, 특정 컴포넌트 인스턴스의 특정 메소드를 호출하여 특정 작업을 수행하거나, 
컴포넌트 인스턴스를 직접 조작하여 특정 상태를 변경할 수 있습니다.

 

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

props drilling은 React에서 컴포넌트 간에 데이터를 전달할 때, 데이터가 중간 컴포넌트를 거쳐 전달되는 상황을 의미합니다.  이 때, props를 통해 데이터를 전달하는 것은 간단하지만, 컴포넌트 구조가 복잡해지면 관리하기 어렵고 코드가 지저분해질 수 있습니다.

이러한 문제를 해결하기 위해 상태관리 라이브러리를 사용하면, 컴포넌트 간의 데이터 전달을 보다 효율적으로 처리할 수 있습니다. 예를 들어 Redux를 사용한다면, 애플리케이션 전역에서 상태를 관리할 수 있습니다. 컴포넌트 간에 데이터 전달을 위한 props drilling이 줄어들어 코드가 더욱 간결해지고 유지보수성이 향상됩니다.  
또한 상태를 중앙 집중적으로 관리할 수 있으므로, 상태의 일관성을 보장하고 상태 업데이트를 더욱 쉽게 처리할 수 있습니다.

 

 

 

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

Semantic HTML은 HTML 요소를 의미 있는 태그로 작성하는 것을 의미합니다.
즉, 웹 페이지에서 각 요소가 어떤 의미를 가지는지 명확하게 표현하는 것입니다.

1.검색 엔진 최적화 (SEO) Semantic HTML을 사용하면 검색 엔진이 웹 페이지의 구조와 내용을 더 잘 이해할 수 있습니다. 검색 엔진은 웹 페이지의 컨텐츠를 분석하여 색인화하는데, Semantic HTML을 사용하면 컨텐츠를 더 잘 인식하고 검색 결과의 순위가 상승할 수 있습니다.

2. 웹 접근성 (Accessibility) 웹 접근성은 장애인이나 고령자 등이 웹 페이지에 접근하는데 어려움이 없도록 하는 것을 의미합니다. Semantic HTML을 사용하면 스크린 리더 등 보조 기기를 사용하는 사용자도 웹 페이지의 구조와 내용을 더 잘 이해할 수 있습니다.

3. 코드 가독성 및 유지보수성 Semantic HTML을 사용하면 각 요소가 어떤 의미를 가지는지 명확하게 표현되므로 코드의 가독성과 유지보수성이 향상됩니다. 예를 들어, 제목을 표시하기 위해 div 태그를 사용하는 것보다는 h1 태그를 사용하는 것이 코드를 이해하기 쉽고 수정하기도 쉽습니다.

따라서 가능한 한 의미 있는 태그를 사용하고, 요소의 구조와 역할을 명확하게 표현하는 것이 좋습니다.

 

 

Q. IP 프로토콜의 한계에 대해서 설명해 주세요.

IP 프로토콜은 인터넷 상에서 데이터를 주고받을 때 사용되는 프로토콜 중 하나입니다. 하지만 IP 프로토콜은 다음과 같은 한계가 있습니다.

1.비신뢰성
IP 프로토콜은 데이터 전송 시에 신뢰성을 보장하지 않습니다. 즉, 데이터가 전송 중에 손실되거나 중복으로 전송될 수 있습니다. 이러한 문제점은 패킷 손실과 같은 문제를 야기할 수 있으며, 신뢰성이 요구되는 어플리케이션에서는 문제를 발생시킬 수 있습니다.

2.보안성
IP 프로토콜은 기본적으로 데이터 암호화 기능을 제공하지 않습니다. 따라서, 데이터가 암호화되지 않고 전송되기 때문에 데이터 유출 및 해킹 등의 보안 문제가 발생할 수 있습니다.

3.품질 제어
IP 프로토콜은 데이터 전송 시에 품질 제어를 보장하지 않습니다. 따라서, 네트워크의 혼잡 상황이나 패킷 손실 등의 이유로 인해 데이터 전송 속도가 느려지는 현상이 발생할 수 있습니다.

이러한 IP 프로토콜의 한계는 인터넷이 발전하면서 문제로 대두되고 있으며, 이를 해결하기 위해 다양한 프로토콜이 개발되고 있습니다. 
예를 들어, TCP 프로토콜은 IP 프로토콜의 비신뢰성 문제를 해결하고, SSL/TLS 프로토콜은 보안 문제를 해결하는 등 IP 프로토콜의 한계를 보완하는 역할을 하고 있습니다.

 

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

HTTP(HyperText Transfer Protocol)는 웹 상에서 데이터를 주고받기 위한 프로토콜입니다. HTTP 프로토콜의 특징은 다음과 같습니다.

1. 무상태성(Stateless)
HTTP 프로토콜은 클라이언트와 서버 간의 통신이 끝나면 상태 정보를 유지하지 않습니다. 
이러한 특징을 무상태(Stateless)라고 합니다. 
이는 서버 측에서 클라이언트에 대한 상태 정보를 유지하지 않아도 되기 때문에 서버의 부하를 줄일 수 있습니다. 
하지만 상태 정보를 유지해야 하는 경우에는 쿠키(Cookie)나 세션(Session)을 이용하여 해결할 수 있습니다.

2.비연결성(Connectionless)
HTTP 프로토콜은 클라이언트와 서버 간의 통신이 끝나면 연결(Connection)을 유지하지 않습니다. 
즉, 요청(Request)을 보내고 응답(Response)을 받으면 바로 연결을 종료하는 구조입니다. 
이는 서버 측에서 연결을 유지하지 않아도 되기 때문에 서버의 부하를 줄일 수 있습니다. 
하지만 이러한 구조는 요청(Request)과 응답(Response) 사이에 추가 정보를 주고받을 수 없기 때문에 HTTP/1.1에서는 Keep-Alive 기능을 제공하여 이를 보완하고 있습니다.

3.요청과 응답(Request/Response) 구조
HTTP 프로토콜은 클라이언트가 서버에게 요청(Request)을 보내면, 서버는 그에 대한 응답(Response)을 보내는 구조입니다. 
이러한 구조는 클라이언트와 서버 간의 상호작용을 가능하게 하며, 클라이언트가 원하는 리소스(Resource)를 요청하고, 서버가 그에 대한 응답을 보내는 방식으로 작동합니다.

4. 단순한 구조
HTTP 프로토콜은 단순한 구조를 가지고 있습니다.
 HTTP 프로토콜의 요청(Request)과 응답(Response)는 각각 시작줄(Start Line), 헤더(Header), 본문(Body)으로 구성되며, 
이러한 구조는 프로토콜의 이해와 구현을 용이하게 만들어줍니다.