Section 3 기술 면접 준비

Section 3 기술 면접 준비

 

UI/UX

 

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

UI(User Interface, 사용자 인터페이스)는 사람들이 컴퓨터와 상호 작용하는 시스템을 의미합니다. 보통 UI라고 하면 떠오르는 화면상의 그래픽 요소 외에도, 키보드, 마우스 등의 물리적 요소도 컴퓨터와 상호 작용하기 위한 시스템이므로 UI라고 볼 수 있습니다.

UX(User Experience, 사용자 경험)의 사전적 의미는 사용자가 어떤 시스템, 제품, 서비스를 직•간접적으로 이용하면서 느끼고 생각하는 총체적 경험입니다. 제품, 서비스 그 자체에 대한 경험은 물론, 홍보, 접근성, 사후 처리 등 직간접적으로 관련된 모든 경험을 사용자 경험이라고 할 수 있습니다. 말 그대로 총체적 경험인 것입니다.

시스템과 상호작용 하는 것 또한 사용자의 경험에 속하기 때문에, UX는 UI를 포함합니다. 하지만 좋은 UX가 좋은 UI를 의미하거나, 좋은 UI가 항상 좋은 UX를 보장하지는 않습니다. 아주 멋진 디자인의 쇼핑몰 앱을 이용한다고 생각해봅시다. 반응 속도도 아주 빠르고 원하는 물품을 고르기도 정말 좋았습니다. 그런데, 장바구니에 넣었던 상품이 장바구니 탭에 들어가보면 없어지거나 수량이 잘못 계산된다면, 혹은 결제 버튼을 눌러도 작동하지 않는다면 결과적으로 좋은 사용자 경험이 될 수 없을 것입니다. 이처럼, UI와 UX는 서로 다르지만 떼려야 뗄 수 없는 관계이며, 서로를 보완하는 역할을 합니다.

 

 

Custom Component

 

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

CSS를 사용할때엔 중복을 피하기 위해 어떤 class 이름이 적절할지 계속 고민해야 했습니다. 또한 id, class 마다 스타일을 지정하며 작성하다보면, 순서를 유의해서 작성한다고 했더라도 수정할 때 해당 스타일을 찾기가 어려웠습니다. styled components는 이런 단점을 보완해줍니다. 먼저 classname을 고민할 필요가 없습니다. 스타일을 컴포넌트 안에 작성해주면 자동으로 무작위의 classname이 지정되기 때문입니다. 또한 컴포넌트화 된 스타일은 재활용하기도 쉽고 props로 내려주는 것도 간단합니다. 계속 특정 class나 id를 생성해 이에 스타일을 부여하는 것과 다르게, 중첩된 사항은 재활용하고, 다양한 경우의 수가 있을 경우엔 삼항연산자를 통해 조건부로 props 내려줄 수 있는 면이 강력한 장점이라고 생각합니다. 또한 이 후 수정할 때도 자바스크립트 파일 안에 있기 때문에 찾기 쉽고 수정도 수월합니다.

 

Q. useRef가 필요한 상황을 예시를 들어 설명해 주세요.

useref는 속성의 정보를 조회하고 수정할 때 리렌더링을 하지 않을 필요가 있을 때 사용합니다. 

일반적인 리액트 컴포넌트는 상태가 변할 때마다 리렌더링 되면서 내 변수들을 초기화합니다. 내부 변수가 초기화되면 해당 컴포넌트 함수의 변수들이 모두 초기화되고 모든 함수 로직이 다시 실행됩니다. 미디어나 애니메이션을 관리할 때엔 이런 리렌더링을 막을 필요가 있습니다. useRef를 사용하면 리렌더링이 되지 않고 컴포넌트의 속성만 조회하고 수정하므로 사용할 수 있습니다. 

DOM요소에 바로 접근할 필요가 있을 때에도 사용할 수 있습니다. 예를 들어 로그인 창을 열었을 때, 입력창을 클릭하지 않아도 자동으로 아이디 입력창에 포커스가 되어 있는 경우를 많이 보실 수 있을 겁니다. 이 포커스 기능에 useref가 사용됩니다.

또한 setTimeout, setInterval과 같은 함수들에 초기화가 필요한 경우에도 사용합니다. 하지만 이런 꼭 필요한 상황 외에는 리액트의 문법을 벗어난 사용법이기 때문에 남용하는 것은 각별히 주의해야 합니다.

 

 

Redux

 

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

상태관리 라이브러리는 Props Drilling 현상을 방지하는 데 필요합니다. 

props drilling이란 수직으로 중첩된 컴포넌트들 안에서 자식 컴포넌트가 상위 컴포넌트의 특정 상태(state)가 필요할 때, 이를 전달받기 위해 수많은 상위 컴포넌트들에게 props가 전달되는 상황을 의미합니다. 앱의 규모가 크고 컴포넌트의 수가 많을 수록 이 전달과정은 복잡해지고, 그러면서 코드의 가독성과 유지보수가 악화되는 상황이 발생하게 됩니다. state를 변경할 때엔 props를 전달한 컴포넌트들 또한 리렌더링 되면서 불필요한 메모리 낭비가 일어나기도 합니다. 이를 방지하기 위해 하나의 전역 관리 저장소에 state를 저장하고 꺼내쓰는 중앙집중형 방식의 상태관리 라이브러리가 필요합니다.

 

Q. Redux의 주요 개념들과 연결 관계를 설명해 주세요.

리덕스의 주요 개념에는 스토어, 리듀서, 액션, 디스패치가 있습니다. 

전역의 state를 저장하고 관리하는 은행 개념의 스토어에 접근하기 위한 방법으로 다른 개념들이 존재한다고 보면 이해하기 쉽습니다.

먼저 상태가 변경되어야 하는 이벤트가 발생하면, 변경될 상태에 대한 정보가 담긴 액션 객체가 생성됩니다. 이 액션 객체는 디스패치 함수의 인자로 전달되고, 리듀서 함수는 이 액션 객체를 전달받아 객체의 값을 확인하고, 이에 따라 스토어의 상태를 변경합니다. 상태가 변경되면, 리액트는 화면을 리렌더링 합니다. 즉, Redux에서는 Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐르게 됩니다.

이런 과정을 거치는 리덕스에는 세가지 원칙이 있습니다. 

첫째, 동일한 데이터는 항상 같은 곳에서 가져와야 합니다. 모든 데이터를 저장하는 스토어와 연결되어 있는 원칙입니다. 두번째, 상태는 읽기 전용이어야 합니다. 액션 객체를 통해서만 상태를 변경할 수 있습니다. 셋째, 변경은 순수함수로만 가능합니다. 상태가 엉뚱한 값으로 변경되는 일이 없도록 스토어와 직접적으로 소통하는 리듀서는 순수함수여야만 합니다.