개발자의 삶

상태(state)란?

상태는 변하는 데이터입니다. 특별히 UI, 프론트엔드 개발에서는 "동적으로 표현되는 데이터"입니다.

로컬 상태란?

다른 컴포넌트와 데이터를 공유하지 않는 폼(form) 데이터는 대부분 로컬 상태

input box, select box 등과 같이 입력값을 받는 경우가 이에 해당

전역 상태란?

다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태

서로 다른 컴포넌트가 사용하는 상태의 종류가 다르면, 꼭 전역 상태일 필요는 없다.

출처(source)가 달라도 된다.

그러나, 서로 다른 컴포넌트가 동일한 상태를 다룬다면, 이 출처는 오직 한 곳이어야 한다.

만일 사본이 있을 경우, 두 데이터는 서로 동기화(sync)하는 과정이 필요한데, 이는 문제를 어렵게 만든다.

그렇다면 전역으로 상태를 관리해야 하는 경우는?

ex) 홈페이지 다크모드, 국제화 설정(홈페이지 영어 -> 한글로 번역 )

Side Effect란?

"함수의 입력 외에도 함수의 결과에 영향을 미치는 요인"입니다. 대표적으로 네트워크 요청, API 호출이 Side Effect"

하지만 상태 관리 툴이 반드시 필요하지는 않다.

상태 관리 툴이 없어도 충분히 규모 있는 애플리케이션을 만들 수 있다.

그러므로 장단점을 인지하고 사용해야 한다.

위 컴포넌트의 state를 props를 통해 전달하고자 하는 컴포넌트로 전달하기 위해 그 사이는 props를 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 데이터를 전달하는 현상을 의미한다.

위 그림처럼 컴포넌트 A의 state를 컴포넌트 D로 전달하기 위해선 사이에 있는 컴포넌트 B, C를 거쳐야 한다.

<Props Drilling의 문제점>

Props의 전달 횟수가 5회 이내로 많지 않다면 Props Drilling 은 큰 문제가 되지 않지만,

규모가 커지고 구조가 복잡해지면서 Props의 전달 과정이 늘어난다면 아래와 같은 문제가 발생한다.

● 코드의 가독성이 매우 나빠지게 됩니다.

● 코드의 유지보수 또한 힘들어지게 됩니다.

● state 변경 시 Props 전달 과정에서 불필요하게 관여된 컴포넌트들 또한 리렌더링이 발생.

따라서, 웹성능에 악영향을 줄 수 있다.

이러한 상황에 다양한 상태관리 라이브러리(Redux, Context api, Mobx, Recoil)를 사용하여 방지할 수 있다.

Redux

Redux에서는 컴포넌트와 상태를 분리하는 패턴을 배운다.

따라서 상태 변경 로직을 컴포넌트로부터 분리하여 표현에 집중한, 보다 단순한 함수 컴포넌트로 만들 수 있다.

기존에 배운 React의 데이터 흐름에 따르면, 최상위 컴포넌트에 위치시키는 것이 적절하다.

하지만 이런 상태 배치는 다음과 같은 이유로 다소 비효율적이라고 느껴질 수 있다.

1. 해당 상태를 직접 사용하지 않는 최상위 컴포넌트, 컴포넌트1, 컴포넌트2도 상태 데이터를 가짐

2. 상태 끌어올리기, Props 내려주기를 여러 번 거쳐야 함

3. 애플리케이션이 복잡해질수록 데이터 흐름도 복잡해짐

4. 컴포넌트 구조가 바뀐다면, 지금의 데이터 흐름을 완전히 바꿔야 할 수도 있음

라이브러리인 Redux는, 전역 상태를 관리할 수 있는 저장소인 Store를 제공함으로써 이 문제들을 해결

1. 상태가 변경되어야 하는 이벤트가 발생하면, 변경될 상태에 대한 정보가 담긴 Action 객체가 생성
2. 이 Action 객체는 Dispatch 함수의 인자로 전달.
3. Dispatch 함수는 Action 객체를 Reducer 함수로 전달
4. Reducer 함수는 Action 객체의 값을 확인하고, 그 값에 따라 전역 상태 저장소 Store의 상태를 변경
5. 상태가 변경되면, React는 화면을 다시 렌더링

   즉, Redux에서는 Action → Dispatch → Reducer → Store 순서로 데이터가 단방향으로 흐르게 된다.

+ https://facebookarchive.github.io/flux/docs/in-depth-overview/

좋은 UX를 만드는 요소

1. 유용성(Useful) : 사용 가능한가?

2. 사용성(Usable) : 사용하기 쉬운가?

3. 매력성(Desirable) : 매력적인가?

4. 신뢰성(Credible) : 신뢰할 수 있는가?

5. 접근성(Accessible) : 접근하기 쉬운가?

6. 검색 가능성(Findable) : 찾기 쉬운가?

7. 가치성(Valuable) : 가치를 제공하는가?

User Flow

User Flow 다이어그램을 그리면 좋은 이유

1. 사용자 흐름 상 어색하거나 매끄럽지 않은 부분을 발견하여 수정할 수 있음

2. 있으면 좋은 기능을 발견하여 추가하거나 없어도 상관없는 기능을 발견하고 삭제할 수 있음

제이콥 닐슨의 10가지 사용성 평가 기준 (Jakob's Ten Usability Heuristics)

여기서, Heuristic(휴리스틱)이란? '체험적인'이라는 뜻으로, 완벽한 지식 대신 직관과 경험을 활용하는 방법론

1. 시스템 상태의 가시성 (Visibility of system status)

합리적인 시간 내에 적절한 피드백을 통해 사용자에게 진행 상황에 대한 정보를 항상 제공해야 한다.

2. 시스템과 현실 세계의 일치 (Match between system and the real world)

내부 전문용어가 아닌 사용자에게 친숙한 단어, 구문 및 개념을 사용

3. 사용자 제어 및 자유 (User control and freedom)

사용자는 종종 실수를 한다.

현재 진행 중인 작업에서 벗어날 수 있는 방법,

혹은 실수로 수행한 작업을 취소할 수 있는 방법, ’탈출구’를 명확하게 제공해야 한다.

4. 일관성 및 표준 (Consistency and standards)

외부 일관성 : 일관적인 사용자 경험을 제공하기 위해서 플랫폼 및 업계의 관습을 따르자.

사용자에게 익숙한 UI를 제공해라. 잘 알려진 UI 디자인 패턴을 사용하는 것이 좋다.

내부 일관성 : 사용자가 혼란스럽지 않도록 제품의 인터페이스나 정보 제공에 일관성이 있어야 한다.

예시) 한 제품 내에서 같은 인터페이스를 유지한다.(버튼의 모양, 위치, 아이콘 크기 등)

5. 오류 방지 (Error prevention)

오류가 발생하기 쉬운 상황을 제거하여 사용자의 실수를 방지해야 한다.

6. 기억보다는 직관 (Recognition rather than recall)

사용자가 기억해야 하는 정보를 줄인다.

7. 사용의 유연성과 효율성 (Flexibility and efficiency of use)

초보자와 전문가 모두에게 개별 맞춤 기능을 제공하도록 한다.

8. 미학적이고 미니멀한 디자인 (Aesthetic and minimalist design)

인터페이스에는 관련이 없거나 불필요한 정보가 포함되지 않도록 한다.

콘텐츠와 기능의 우선순위를 정하고 우선순위가 높은 것을 잘 제공하고 있는지 확인해야 한다.

9. 오류의 인식, 진단, 복구를 지원 (Help users recognize, diagnose, and recover from errors)

사용자가 이해할 수 있는 언어를 사용하여 문제가 무엇인지 정확하게 표시하고, 해결 방법을 제안해야 한다.

10. 도움말 및 설명 문서 (Help and documentation)

추가 설명이 필요 없는 것이 가장 좋지만, 상황에 따라 이해하는 데 도움이 되는 문서를 제공해야 한다.

UI(User Interface, 사용자 인터페이스)

사람들이 컴퓨터와 상호 작용하는 시스템

화면상의 그래픽 요소 외에도, 키보드, 마우스 등의

물리적 요소도 컴퓨터와 상호 작용하기 위한 시스템이므로 UI

GUI(Graphical User Interface, 그래픽 사용자 인터페이스)

사용자가 그래픽을 통해 컴퓨터와 정보를 교환하는 작업 환경

UX(User Experience, 사용자 경험)

사용자가 어떤 시스템, 제품, 서비스를 직•간접적으로 이용하면서 느끼고 생각하는 총체적 경험

※UX는 UI를 포함

기본 계산기 애플리케이션을 생각해 보자.

특별히 보기 싫다거나, 보기 좋은 디자인의 UI는 아니다.

오히려 투박하다면 투박한 디자인이다.

하지만 계산기의 기능을 제대로 제공한다는 점에서 UX는 훌륭합니다.

꼭 좋은 UX가 좋은 UI를 의미하지 않음을 보여준다.

정리하자면, UI와 UX는 서로 다르지만 떼려야 뗄 수 없는 관계이며, 서로를 보완하는 역할

UI 디자인 패턴

모달 (Modal) :

기존에 이용하던 화면 위에 오버레이 되는 창 닫기 버튼, 혹은 모달 범위 밖을 클릭하면 모달이 닫히는 것이 일반적이며,모달을 닫기 전에는 기존 화면과 상호작용할 수 없다.

토글 (Toggle):

토글은 On/Off를 설정할 때 사용하는 스위치 버튼

색상, 스위치의 위치, 그림자 등의 시각적 효과를 주어 사용자가 토글의 상태를 직관적으로 알 수 있게 만들어야 함.

보통 On/Off와 같이 두 개의 옵션이 있을 때 사용하지만, 여러 개의 옵션이 있을 때에도 토글을 사용할 수 있다.

단, 이때에도 어느 옵션이 선택되어 있는지 직관적으로 알 수 있어야 하며,

옵션의 개수가 너무 많다면 탭을 사용하는 것을 고려해야 한다.

탭 (Tab):

콘텐츠를 분리해서 보여주고 싶을 때 사용하는 UI 디자인 패턴

가로로 한 줄로 배열된 형태가 가장 흔하지만, 세로로 배열하거나 여러 줄로 배열할 수도 있다.

단, 각 섹션의 이름이 너무 길지 않아야 하고,

섹션의 구분이 명확해야 하며,

현재 어떤 섹션을 보고 있는지 표시해 주어야 한다.

태그 (Tag):

콘텐츠를 설명하는 키워드를 사용해서 라벨을 붙이는 역할

사용자들은 자신이 작성한 콘텐츠에 태그를 붙임으로써 콘텐츠를 분류할 수 있고,

태그를 사용하여 관련 콘텐츠들만 검색할 수도 있다.

자동완성 (Autocomplete):

사용자가 내용을 입력 중일 때 사용자가 입력하고자 하는 내용과 일치할 가능성이 높은 항목을 보여주는 것

사용자가 정보를 직접 입력하는 시간을 줄여주고, 정보를 검색할 때 많이 사용

드롭다운 (Dropdown):

선택할 수 있는 항목들을 숨겨놓았다가, 펼쳐지면서 선택할 수 있게 해주는 UI 디자인 패턴

객관식 문제의 선택지와 비슷한 개념

보통 화살표 버튼을 누르면 펼쳐지게 만들지만, 그냥 마우스를 올려놓아도 펼쳐지게 만들 수도 있다.

중요한 것은 사용자가 자신이 선택한 항목을 정확히 알 수 있게 만드는 것

아코디언 (Accordion):

접었다 폈다 할 수 있는 컴포넌트로, 보통 같은 분류의 아코디언을 여러 개 연속해서 배치

기본적으로는 화면을 깔끔하게 구성하기 위해서 사용하며,

트리 구조나 메뉴바로 사용할 경우에는 상하 관계를 표현하기 위해서 사용하는 경우가 많고,

콘텐츠를 담는 용도로 사용할 때에는 핵심 내용을 먼저 전달하려는 목적을 가질 때가 많다.

캐러셀 (Carousel):

공항의 수하물 컨베이어 벨트, 또는 회전목마라는 뜻의 영단어로,

컨베이어 벨트나 회전목마처럼 빙글빙글 돌아가면서 콘텐츠를 표시해 주는 UI 디자인 패턴

페이지네이션 (Pagination):

한 페이지에 띄우기에 정보가 너무 많은 경우, 책 페이지를 넘기듯이 번호를 붙여 페이지를 구분해 주는 것

사용자가 원하는 페이지로 바로바로 접근할 수 있다는 장점이 있지만,

페이지를 넘기기 위해서는 잠시 멈춰야 하기 때문에 매끄러운 사용자 경험과는 거리가 멀 수 있다는 단점도 있다.

무한 스크롤 (Infinite Scroll, Continuous Scroll):

페이지네이션과 마찬가지로 한 번에 띄우기엔 정보가 너무 많을 때 사용하는 UI 디자인 패턴

페이지네이션과 같이 잠시 멈춰서 페이지를 선택할 필요가 없기 때문에 보다 더 매끄러운 사용자 경험을 제공합니다. 하지만 콘텐츠의 끝이 어딘지 알 수 없다는 점, 지나친 콘텐츠를 찾기 힘들다는 점 등의 단점도 있다.

보통 페이지의 맨 아래에 도달하면 추가 콘텐츠를 로드해 오는 방식으로 만든다.

처음부터 모든 콘텐츠를 로드해 온 후 조금씩 보여주는 방식으로 구현하는 것은

진정한 의미의 무한 스크롤이라고 할 수 없으므로 주의해야 한다.

GNB (Global Navigation Bar), LNB (Local Navigation Bar):

GNB(Global Navigation Bar)는 어느 페이지에 들어가든 사용할 수 있는 최상위 메뉴,

LNB(Local Navigation Bar)는 GNB에 종속되는 서브 메뉴 혹은 특정 페이지에서만 볼 수 있는 메뉴

예시에서는 탭 형식으로 최상단에 위치한 메뉴가 GNB, 마우스를 올렸을 때 드롭다운 형식으로 내려오는 서브 메뉴가 LNB

GNB는 말했듯이 어느 페이지에 있든 사용할 수 있도록 항상 동일한 위치에 있어야 한다.

GNB가 있다 없다 한다거나 위치가 자꾸 변하면 사용자 경험에 악영향을 줄 수 있다.

그리드 시스템 (Grid System)

Margin :

화면 양쪽의 여백

Column :

콘텐츠가 위치하게 될 세로로 나누어진 영역

(표준적으로 휴대폰에서 4개, 태블릿에서 8개, PC에서는 12개의 컬럼)

상대 단위를 사용하여 콘텐츠가 창 크기에 맞춰서 크기가 변하도록 설정하는 것이 좋다.

기기마다 화면의 크기가 조금씩 다르고, 브라우저의 크기를 사용자 마음대로 바꿀 수도 있기 때문

Gutter :

Column 사이의 공간으로, 콘텐츠를 구분하는데 도움을 준다.

Gutter의 간격이 좁을수록 콘텐츠들이 연관성 있어 보이고, 넓을수록 각 콘텐츠가 독립적인 느낌을 준다.