재귀
재귀를 활용하기 좋은 상황은 언제인지 예시를 들어 설명해 주세요.
재귀는 어떠한 것을 정의할 때, 자기 자신을 참조하는 것을 의미합니다. 이러한 재귀를 활용하기 좋은 상황은 첫째로, 주어진 문제를 비슷한 구조의 더 작은 문제로 나눌 수 있는 경우와 둘째로, 중첩된 반복문이 많거나 반복문의 중접 횟수를 예측하기 어려운 경우가 있습니다.
재귀 함수는 문제를 더 이상 쪼갤 수 없는 경우인 base case와 재귀가 일어나는 경우인 recursive case로 나누어 작성하며, 모든 재귀 함수는 반복문으로 표현할 수 있지만, 재귀를 적용할 수 있는 대부분의 경우에는 재귀를 적용한 코드가 더욱 간결하고 이해하기 쉽기 때문에 사용합니다.
재귀를 활용하기 좋은 상황은 크게 두 가지가 있습니다.
첫 번째는 주어진 문제를 비슷한 구조의 더 작은 문제로 나눌 수 있는 경우입니다. 예시로는 피보나치 수열의 n번째 수를 구하는 문제가 있습니다. 피보나치 수열의 n번째 수는 n-1번째 수와 n-2번
째 수를 합한 값입니다. 몇 번째 수를 구하든 동일한 구조의 작은 문제로 나눌 수 있는 구조인 것입니다. 이런 상황에서 재귀를 활용하면 간결한 코드로 문제를 해결할 수 있습니다.
두 번째는 중첩된 반복문이 많거나 반복문의 중첩 횟수를 예측하기 어려운 경우입니다. 예시로는 객체를 문자열로 바꾸는 함수가 있습니다. 객체는 배열이나 객체도 담을 수 있으며, 얼마나 중첩되
어 있을지 예측하기 어렵기 때문에 반복문을 사용하기에는 적합하지 않습니다. 이럴 때 재귀를 활용하면 가장 깊은곳에 있는 배열이나 객체까지 확인할 수 있습니다.
UI/UX
UI, UX의 개념과 두 개념의 관계에 대해서 설명해 주세요.
UI는 사용자 인터페이스의 약자로, 사람들이 컴퓨터와 상호 작용하는 시스템을 의미하고, UX는 UI를 포함하는 좀 더 포괄적인 개념으로, 사용자 경험의 약자입니다. 즉, 사용자가 어떤 시스템, 제품, 서비스를 이용하면서 직/간접적으로 느끼는 총체적인 경험을 의미합니다.
UX와 UI는 서로 밀접한 관계이지만, 항상 좋은 UX가 좋은 UI를 보장하는 것은 아니고, 반대로, 좋은 UI가 좋은 UX를 보장하는 것도 아닙니다. 하지만, 나쁜 UI는 보통 나쁜 UX를 유발하기 때문에 이 두 개념은 서로 다르지만, 계속해서 서로를 발전시킬 수 있는 상호 보완적인 관계라 할 수 있습니다.
UI는 사람들이 컴퓨터와 상호 작용하는 시스템을 의미합니다. 키보드, 마우스 등의 물리적 요소도 컴퓨터와 상호 작용하기 위한 시스템이므로 UI라고 볼 수 있으나, 프론트엔드 개발자로서의 UI는
보통 화면상의 그래픽 요소인 GUI를 의미합니다.
UX는 사용자가 어떤 시스템, 제품, 서비스를 직•간접적으로 이용하면서 느끼고 생각하는 총체적 경험을 의미합니다. 제품, 서비스 그 자체에 대한 경험은 물론, 홍보, 접근성, 사후 처리 등 직간접적
으로 관련된 모든 경험을 사용자 경험이라고 할 수 있습니다.
UX는 UI를 포함합니다. 또한 좋은 UX가 좋은 UI를 의미하거나, 좋은 UI가 항상 좋은 UX를 보장하지는 않습니다. 하지만, 나쁜 UI는 보통 나쁜 UX를 유발합니다. 프론트엔드 개발자는 UI를 개선
함으로써 UX를 개선할 수 있으며, UX가 좋지 않은 곳에서 UI 개선점을 찾아낼 수도 있습니다.
Custom Component
- Styled Components를 사용해 보면서 느낀 장점을 이야기해 주세요.
평소 일반적인 CSS를 사용할 때에는 class나 id 이름을 짓느라 고민하고, 중복되어 문제점이 발생하거나, CSS 파일 내에서 제가 원하는 부분을 찾아서 작성하기가 어려운 부분이 있었습니다.
반면, Styled Components는 일단 CSS in JS 관련 라이브러리 중 가장 인기 있는 라이브러리이며, ES6 문법인 Template literals를 사용하여 컴포넌트 선언 후 백틱 안에 기존 CSS를 작성하는 방식으로, 앞서 말한 CSS의 단점을 보완할 수 있어서 유용하다고 생각했습니다.
Styled Components는 CSS 파일을 따로 작성할 필요 없이 컴포넌트 단위로 스타일 속성을 작성할 수 있게 해주는 라이브러리입니다.
CSS 파일을 따로 작성할 필요가 없기 때문에 크게 세 가지 장점을 느낄 수 있습니다.
첫째, class, id 이름을 짓느라 고민할 필요가 없습니다. CSS 파일을 따로 작성해야 할 때에는 스타일을 적용할 요소를 특정하기 위해서 class와 id를 작성해야 했습니다. 하지만 Styled
Components를 사용하면 CSS 코드가 작성된 컴포넌트가 곧 스타일을 적용할 컴포넌트이기 때문에 class와 id를 사용해서 요소를 특정하지 않아도 됩니다.
둘째, CSS 파일에서 내가 원하는 부분을 찾기위해 시간을 쓰거나 길어진 CSS 파일을 쪼개서 관리할 필요가 없어졌습니다. 앞서 말했듯 Styled Components를 사용하면 애초에 CSS 파일을 작
성할 필요가 없기 때문에 CSS 파일을 관리할 필요도 없어졌습니다.
셋째, 스타일 속성이 겹쳐서 내가 원하는 결과가 나오지 않는 일이 줄어들었습니다. CSS 파일을 작성하다보면 같은 종류의 요소에 같은 종류의 스타일 속성을 작성하게 되는 일도 생겼고, 이럴 때
에는 뒤에서 작성된 속성이 적용되면서 내가 의도한 바와는 다른 화면이 나오기도 했습니다. 하지만 Styled Components는 컴포넌트 단위로 스타일 속성을 작성하기 때문에 속성이 겹치는 일이
없었습니다.
- useRef가 필요한 상황을 예시를 들어 설명해 주세요.
focus, text selection, 미디어 재생, 애니메이션 적용 등 DOM 엘리먼트의 주소값을 사용해야 하는 경우 useRef를 사용합니다. 특정한 상황을 제외한 대부분의 경우 기본 React 문법을 벗어나 useRef 를 남용하는 것은 부적절하고, React의 특장점인 선언형 프로그래밍 원칙과 배치되기 때문에, 조심해서 사용해야 합니다.
useRef는 특정 요소의 DOM 주소값을 가져오는 React Hook입니다.
React는 기본적으로 DOM에 직접 접근하는 것을 금지하고 있습니다. React는 가상 DOM을 사용해서 SPA를 구현하기 때문에, DOM을 직접 조작하는 것은 React의 작동 방식과도 맞지 않고,
원하는 결과가 나오지 않을 수도 있기 때문입니다.
그럼에도 DOM에 직접 접근해야하는 예외 상황들이 있습니다. 바로 DOM 엘리먼트의 주소값을 활용해야 하는 경우로, 가장 대표적인 예시는 특정 요소에 포커스를 설정해야하는 상황이 있습니다.
이럴 때 useRef를 사용해서 DOM 주소 값을 받아와 사용할 수 있습니다.
하지만 앞서 말했듯 DOM에 직접 접근하는 것은 React의 작동 방식과 맞지 않기 때문에, 이런 예외적인 상황을 제외하고는 useRef를 사용하거나 DOM에 직접 접근해서는 안 됩니다.
Redux
- 상태관리 라이브러리의 필요성에 대해서 설명해 주세요.
기존 React 상태 관리 방식에서는 해당 상태를 직접 사용하지 않는 컴포넌트들도 상태 데이터를 가져서 props와 상태 끌어올리기 등 원하는 컴포넌트에 도달할 때 까지 반복해주어야 하고, 애플리케이션이 복잡해질수록 데이터 흐름도 복잡해지며, 컴포넌트 구조가 바뀌면 지금의 데이터 흐름을 완전히 바꿔야 할 수도 있다는 문제점이 있습니다. 이러한 문제점들을 해결하기 위해서는 상태 관리 라이브러리가 필요합니다.
Redux와 같은 상태관리 라이브러리는 전역 상태 저장소를 제공해줍니다.
기존의 React에서는 자식 컴포넌트에 props를 내려줘서 상태를 전달해줬습니다. 이 경우에는 해당 상태를 사용하지 않는 컴포넌트들도 오로지 상태를 전달해주기 위해서 props를 받아야 했고,
이를 props drilling이라고 합니다.
상태 관리 라이브러리는 전역 상태 저장소를 제공해줌으로써 이 props drilling 문제를 해결해줍니다. 전역 상태 저장소가 있다면 props를 내려줄 필요없이 바로 이 저장소에 접근해서 필요한 상태
를 가져다 사용하면 되기 때문입니다.
- Redux의 주요 개념들과 연결 관계를 설명해 주세요.
Redux는 컴포넌트와 상태를 분리하여 전역에서 상태 관리를 해줄 수 있게 해주는 상태 관리 라이브러리로, 주요 개념으로는 Action, Dispatch, Reducer, Store가 있습니다.
Redux의 동작 방식을 간략히 설명드리면, 먼저, 상태 변경 이벤트 발생 시, 변경될 상태 정보가 담긴 Action 객체가 생성되어 Dispatch 함수의 인자로 전달되고, 이 Dispatch함수는 Action 객체를 Reducer 함수로 전달하여 Action 객체의 값을 확인한 후, 그 값에 따라 전역 상태 저장소인 Store의 상태를 변경시키고 상태가 변경되면 최종적으로 React가 화면을 리렌더링 하는 방식으로 동작하게 됩니다.
Redux의 주요 개념으로는 Action, Dispatch, Reducer, Store가 있으며, Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐르게 됩니다.
Action은 말 그대로 어떤 액션을 취할 것인지 정의해 놓은 객체입니다. 해당 Action 객체가 어떤 동작을 하는지 명시해주는 type 속성을 가집니다.
Dispatch는 Reducer로 Action을 전달해주는 함수입니다. Dispatch의 전달인자로 Action 객체가 전달되며. Action 객체를 전달받은 Dispatch 함수는 Reducer를 호출합니다.
Reducer는 Dispatch에게서 전달받은 Action 객체의 type 값에 따라서 상태를 변경시키는 함수로, Reducer가 리턴하는 값이 새로운 상태가 됩니다. 이 때, Reducer는 순수함수여야 합니다.
외부 요인으로 인해 기대한 값이 아닌 엉뚱한 값으로 상태가 변경되는 일이 없어야하기 때문입니다.
Store는 Redux의 전역 저장소로, Redux 앱의 state가 저장되어 있는 오직 하나뿐인 저장소의 역할을 합니다.
웹 표준 & 웹 접근성
- Semantic HTML의 필요성을 예시를 들어 설명해 주세요.
Semantic HTML은 HTML이 단순히 구조를 정의하기 보다는 각 태그가 포함하는 정보에 대한 의미를 갖도록 한다는 뜻입니다. HTML에는 많은 종류의 태그가 있지만,
<div>태그와<span>태그 만으로도 충분히 화면의 구조를 만들 수 있습니다. 하지만, 이런 방식으로 짜여진 구조만 보고 각 요소들이 어떤 역할을 할 지 알아낼 수 없습니다. 반면, 시맨틱 요소로 화면을 구성하면 요소의 이름만 보고도 화면에서 어떤 역할을 하게되고 어떤 내용을 담게 될 지를 명확하게 알 수 있습니다. 이로써 개발자간 소통이 원활해지고, 검색 효율성도 증대되며, 웹 접근성을 향상시킬 수 있다는 장점이 있습니다.
Semantic HTML은 말 그대로 의미있는 HTML로, HTML이 구조를 만드는 것을 넘어 의미를 갖게 만드는데 필요합니다. 시맨틱 요소의 예시로는
<header>,<main>,<nav>,<footer>등이 있습니다.
HTML에는 많은 종류의 요소가 있지만,<div>와<span>두 가지 요소만 알아도 충분히 화면의 구조를 만들 수 있습니다. 하지만, 이 두 요소의 이름에는 의미가 없기 때문에 요소의 이름으로는
각 요소가 어떤 역할을 하는지 알 수 없습니다. 하지만 시맨틱 요소를 사용하면 요소의 이름만 보고도 해당 요소가 어떤 역할을 하는지, 요소가 가진 의미를 통해 파악할 수 있게 됩니다.
시맨틱한 HTML을 작성하면 개발자간 소통, 검색 효율성, 웹 접근성에 효과를 볼 수 있습니다.
요소의 이름만 봐도 의미를 파악할 수 있기 때문에 그만큼 의미를 전달하기 위한 시간과 id, class 작성에 필요한 시간 소모도 줄어들고 개발자간 소통이 원활해집니다.
또한 검색 엔진은 HTML 코드를 보고 문서의 구조를 파악하기 때문에 시맨틱 요소를 사용함으로써 HTML에 의미를 부여하는 것만으로도 검색 효율성을 높일 수 있습니다.
마지막으로 시맨틱 요소를 사용하면 화면의 구조를 짜는 것을 넘어 구조에 대한 정보를 전달할 수 있어 요소에 담긴 콘텐츠도 더 명확하게 전달할 수 있으므로 웹 접근성을 향상시킬 수 있습니다.
네트워크 심화
- IP 프로토콜의 한계에 대해서 설명해 주세요.
IP는 인터넷 프로토콜의 약자로, 인터넷이 통하는 네트워크에서 어떤 정보를 수신하고 송신하는 통신에 대한 규약을 의미합니다. 지정한 IP 주소에 패킷이라는 통신 단위로 데이터를 전달하는데, 정확한 출발지와 목적지를 파악할 수 있다는 점에서 적절한 통신 방법으로 보이지만, 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하는 비연결성과, 중간 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 소실되더라도 클라이언트는 파악할 방법이 없으며, 전달 데이터의 용량이 클 경우 서로 다른 노드들을 통해 패킷이 전달되기 때문에, 패킷의 순서를 보장할 수 없다는 비신뢰성 등의 한계가 존재합니다.
IP 프로토콜의 한계로는 비연결성, 비신뢰성이 있습니다.
인터넷 프로토콜(IP)는 패킷 단위로 통신하며, IP 패킷은 소포처럼 출발지 IP 주소, 목적지 IP 주소 정보를 포함하고 있습니다. 패킷은 한 번 전송되면 목적지에 도착할 때까지 인터넷 망의 수 많은
노드를 지나게 됩니다.
이 때, 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 됩니다. 이걸 비연결성이라고 합니다.
또한 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없습니다. 목적지에서도 패킷의 순서가 바뀌거나 소실된 상태로 도착할 수 있습니다. 이걸 비
신뢰성이라고 합니다.
- HTTP 프로토콜의 특징에 대해 설명해 주세요.
HTTP 프로토콜은 클라이언트 서버 구조, 무상태성, 비연결성 등이 있습니다. 클라이언트 서버 구조는 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 구조이며, 무상태성은 서버가 클라이언트의 상태를 보존하지 않아 응답 서버를 쉽게 바꿀 수 있어 서버 확장성을 보장하는 특징입니다. 로그인이 필요한 서비스의 경우 유저의 상태를 유지해야 하기 때문에, 쿠키, 세션, 토큰 등을 이용해야 하는 한계가 있습니다. 비연결성은 실제 요청을 주고 받을 때만 연결을 유지하여 최소한의 자원으로 서버를 유지하는 특징으로, 빠른 속도로 응답하는 장점이 있습니다. 하지만 매번 자원을 보낼 때 마다 TCP/IP 연결을 새로 맺어야 하는 것은 매우 비효율적이기 때문에 HTTP 지속 연결로 문제를 해결할 수 있습니다.
HTTP는 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있으며, 무상태성, 비연결성이라는 특징을 갖습니다.
무상태성은 서버가 클라이언트의 상태를 기억하지 않는다는 뜻입니다. 즉, 상태 기억의 주체가 클라이언트가 된다는 말이며, 중간에 요청을 처리하는 서버가 바뀌어도 클라이언트가 상태를 잘 담아
서 요청을 보내면 응답을 제대로 받을 수 있습니다. 서버가 바뀌어도 응답에 문제가 없다는 뜻은, 필요에 따라 서버를 무한히 증설할 수 있다는 의미입니다. 즉, 무상태성이라는 특성 덕에 서버의 무
한한 증설이 가능해집니다.
비연결성은 요청과 응답을 주고 받은 후에 서버와의 연결을 끊는 것을 의미합니다. 서버와의 연결을 지속하지 않고 필요할 때에만 연결하기 때문에 최소한의 자원만 사용하게 된다는 장점이 있습니
다. 하지만 HTTP 1.0 버전은 여러 요청을 보내야 할 때에도 매 요청마다 서버 연결과 종료를 반복하는 비효율성이 발생한다는 한계가 있습니다. 이러한 한계점을 HTTP 1.1 버전에서는 지속 연결
과 파이프라인, HTTP 2.0 버전에서는 멀티플렉싱을 활용해서 해결합니다.
인증 / 보안
- Cookie의 MaxAge, Expires 옵션이 무엇인지, 설정하지 않으면 어떻게 되는지 설명해 주세요.
Cookie란 서버에서 클라이언트에 데이터를 저장하는 방법을 의미합니다.
MaxAge, Expires 옵션은 쿠키의 유효기간을 정하는 옵션입니다.
MaxAge 는 쿠키의 유효기간을 초 단위로 설정하고,
Expires 옵션은 클라이언트의 시간, 날짜를 기준으로 유효기간을 설정합니다.
만약 이러한 옵션을 설정하지 않으면 쿠키가 영원히 남아있기 때문에 보안에 취약할 수 있습니다.
Cookie는 HTTP 프로토콜의 비상태성을 보완하기 위한 수단으로, 브라우저에 데이터를 저장할 때 사용합니다. Cookie의 MaxAge 옵션은 쿠키를 얼마나 유지할 것인지, Expires 옵션은 언제 폐
기할 것인지 지정하는 옵션입니다.
두 옵션을 동시에 설정하면 MaxAge가 더 높은 우선 순위로 적용됩니다. 이 두 옵션중 하나라도 설정하지 않으면, 해당 쿠키는 브라우저가 닫힐 때 폐기 됩니다. 따라서 쿠키를 빠르게 폐기하고 싶
다면 옵션을 설정하지 않는 것이 좋고, 쿠키를 계속 사용하고 싶다면 두 옵션 중에 하나라도 설정해주는 것이 좋습니다.
이 때, 브라우저를 종료하면 삭제되는 임시 쿠키를 세션 쿠키(Session Cookie)라고 하고, 설정한 옵션만큼 사용가능한 쿠키를 영속성 쿠키(Persistent Cookie)라고 합니다.
