[TIL] Naver FE News 2022-02

[TIL] Naver FE News는 Naver FE 팀에서 매월 첫째주 수요일에 업로드하는 FE 관련 이슈들을 팔로우 하면서 관심있는 내용을 학습하고 정리하는 컨텐츠입니다. [ https://github.com/naver/fe-news ]

1. Web 3.0은 무엇인가?

https://itnext.io/what-do-you-need-to-know-about-new-era-of-internet-web-3-0-as-a-frontend-developer-55e51f2cd03f

🔥What You Need to Know About the New Era of Internet Web 3.0 As a Frontend Developer

• 저커버그가 facebook의 사명을 meta로 바꾸면서 많은 기업들도 자신들의 web 3.0(meta-universe)을 향한 계획과 비전을 공개했다.
• 그런데 현재를 기준으로 web3.0을 명확히 정의하기란 쉽지 않고 아직 구현되지 않은 개념이다.
• 따라서 web 3.0에 도달하기 까지 web의 역사를 간단히 살펴보면서 맥락 속에서 web 3.0이 무엇인지 araboza.

" web 1.0 [ 1991 ~ 2004 ] "

• text와 image 기반의 static page로 이루어진 웹페이지가 전부였다.
• 유저는 정보를 소비할 뿐이었다.
• 인터넷은 보안이 매우 취약한 공간이었다.
• 웹사이트는 돈벌이 수단이 아니었다. (광고도 없었다.)
• flash와 javascript가 등장했다.

" web 2.0 [ 2004 ~ 현재 ] "

• 소비의 방식이 Read에서 Interactive로 전환되었다.
• 유저도 정보의 생산자가 되었다.
• 하지만 정보의 보관/저장/관리는 소수의 빅테크 기업들이 장악했다.
• 이에 따라, 빅데이터 기반의 Data Science와 Machine Learning이 중요해졌다.
• 기업들은 광고를 위해 빅데이터를 사용했고 유저는 돈벌이 수단으로 전락했다.

" web 3.0 [ ~ upcoming ] "

• 정보의 소유권까지 유저가 독점하는 시대
• 키워드 : OpenSource, Decentralize(탈중앙화), NFT(대체 불가 토큰), BlockChain, Cryptocurrency(암호화폐), Virtual Avatar
• BlockChain은 권력 집단의(정부, 은행, 글로벌 기업) 헤게모니에 대한 도전이기 때문에 기술의 목적과 가치에 상관없이 언제쯤 주류가 되어 새로운 시대를 열어갈 지는 미지수이다.
• 게임을 통해 디지털 세상에서의 경제/정치 활동에 익숙한 지금의 어린 세대가 기성 세대가 되는 순간 web3.0이 새로운 시대를 열 것으로 기대한다.

Web 3.0에 대한 나의 생각

  Web 3.0에 대해서 내 주관적 관점은 비관에 가깝다.
  첫번째로 헤게모니 집단과의 공존 방법에 대해 명확한 내용이 없다. 그렇다면 Web 3.0은 헤게모니 집단의 붕괴를 원하는 것인가? 이러한 아나키즘적인 사고를 전제로는 달성될 수 없는 목표라고 생각한다.
  두번째로 어린 세대들이 가상 세계에서의 삶에 기성 세대보다 친숙하다고 해서 현실과 가상을 나누는 이분법적인 사고를 전제로도 달성될 수 없다고 생각한다. 결국 현실과 가상이 잘 융합될 수 있도록 해야하는데 이에 관해서도 아직은 예측이 어렵다.
  마지막으로 정보의 소유권을 유저가 독점한다고 해서 유저에게 마냥 좋은 일은 아니라고 생각한다. AI와 빅데이터는 개인이 컨트롤할 수 없는 영역이고 결국 기업의 서비스를 제공받아야 하는데 정보 독점을 하게 된다는 것은 이러한 편리함 대신 나만의 안전을 선택한다는 것이다. 절대 다수의 사람들이 이에 대해서 동의할 지는 미지수다.
  따라서 Web 3.0은 아직은 더 지켜볼 필요가 있다. 다만, Web 3.0이 지향하는 가치에 대해서는 동의하기 때문에 이를 현실과 어떻게 타협해가면서 적용시킬지 또는 어떤 혁신을 통해 세상이 바뀌게 될 지 기대해본다.

 

2. 프론트엔드 상태 관리에 대한 여정

https://devblog.kakaostyle.com/ko/2022-01-13-1-frontend-state-management/

프론트엔드 상태 관리에 대한 여정

• 카카오스타일 팀이 Jotai를 도입하기 까지의 과정
• 선언형 UI : 변수와 뷰를 동기화 시키는 방법
  • ${변수}와 같이 뷰에 변수를 선언적으로 넣는다.
  • 이 변수를 React에서 상태라고 부른다.
• Mobx와 Redux-Toolkit 사용 경험
  • 링크에 들어가보면 실제 사용했던 코드 구조를 보여준다.
  • 글로벌 상태를 하나의 스토어에 두는 Redux 컨셉이 별로임
  • 비동기 처리 복잡함
  • 계산된 속성과 일반 속성의 사용법이 다름
• Jotai 사용 경험
  • 큰 state를 정의하는 대신, 개별 상태(atom)을 정의해서 조합한다.
  • 개념이 단순하고 코드 크기가 작다. (Recoil 보다 단순하다.)
  • 간단한 Jotai의 사용법
    • 원하는 상태가 있으면 atom으로 정의(useState 쓰듯이)
    • 그 상태가 필요한 컴포넌트에서 useAtom으로 콜해서 사용
    • 액션은 쓰기 전용 atom으로 정의
  • 정의하면 모든 atom은 전역으로 공유된다.
  • 독립된 공간이 필요하다면 Provider로 감싸주면 된다.

 

3.  Javascript에서도 SOLID 원칙이 통할까?

https://velog.io/@teo/Javascript에서도-SOLID-원칙이-통할까

Javascript에서도 SOLID 원칙이 통할까?

• JS는 함수형 프로그래밍을 토대로 Java의 언어적 껍데기를 입힌 언어이기 때문에 함수형이면서 동시에 객체지향의 성격을 지니고 있다. 따라서, 완벽한 객체지향 언어를 토대로 설계된 SOLID라는 좋은 원칙은 JS에서 100% 적용하기는 힘들다.
• 클래스는 함수와 데이터 그리고 타입에 대한 개념이지 꼭 객체지향만을 위한 원칙은 아니기 때문에 SOLID 원칙을 함수 위주의 JS,  TS를 기준으로 재해석 해본다.

S : Single Responsibility Principle(SRP) - 단일 책임 원칙
  - 객체는 오직 하나의 책임을 가져야 한다. = "변경"에 대해 오직 하나의 이유만이 있어야 한다.
O : Open-Closed Principle(OCP) - 개방-폐쇄 원칙
  - 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
  - 새로운 기능의 추가가 일어 났을 때에 기존 코드의 수정 없이 추가가 되어야 하고, 내부 매커니즘이 변경되어야 할 때에는 외부의 코드 변화가 없어야 한다.
L : Liskov Substitution Principle(LSP) - 리스코프 치환 원칙
  - 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
  - 상속을 받은 하위 타입과 상위 타입을 서로 치환해도 프로그램에 문제가 없어야 한다.
    - 정사각형을 직사각형의 하위 타입으로 정의하면 안된다.
    - 정사각형의 제약사항이 직사각형의 조건과 일치 하지 않음으로 상속받으면 안된다.
I : Interface Segregation Principle(ISP) - 인터페이스 분리 원칙
  - 사용자가 필요하지 않은 것들에 의존하게 되지 않도록, 인터페이스를 작게 유지하라.
  - 인터페이스를 최대한 분리하고 분리된 인터페이스를 선택적으로 상속하도록 한다.
    - 뭉탱이(?) 인터페이스를 만들지 마라.
D : Dependency Inversion Principle(DIP) - 의존관계 역전 원칙
  - 추상화에 의존하고 구체화에 의존하지 마라 -> 의존성 주입

• 함수형 프로그래밍의 단일 책임 원칙
  • 가급적 데이터를 다룰 때 for문 보다는 함수형 method를 사용하자. (filter, foreach, map, sort...)
  • 단, 가독성과 응집도를 기준으로 융통성있게 선택해야 한다.
  • 순수함수로 작성하자.
    • 1개의 반환값이 반드시 존재한다.
    • 같은 인자를 넣었을 때에는 항상 같은 값을 반환한다.
    • 함수 외부의 어떠한 값을 변화시켜서는 안된다.

• 함수형 프로그래밍의 개방-폐쇄 원칙
  • FP의 Method와 webpack loader와 같은 플러그인 또는 middleware가 이에 해당한다.
  • 함수가 params에 option이나 flag가 많다면 함수를 매개 변수로 넘김으로써 OCP를 지켜보자.
  • Redux의 middleware, Webpack의 loader, vite의 plugin과 같이 아주 많은 곳에서 이러한 원칙을 잘 지켜 유연한 확장과 견고한 매커니즘을 유지하는 좋은 설계를 가지고 있다.
  • 이 OCP 원칙은 함수형 개발의 설계에서 아주 아주 아주 중요하다.
• 함수형 프로그래밍의 리스코프 치환 원칙
  • 이 원칙은 상속을 기반함으로 함수형 프로그래밍에게 바로 적용하기는 힘들다.
  • 하지만 먼저 선언된 조건들과 나중에 선언된 조건들이 서로 충돌이 나는 것을 방지해야 한다 혹은 선언형 프로그래밍에서 발생하는 순환 종속성을 만들어 내는 infinite cycle을 만들지 말아야 한다는 원칙 정도로 대체할 수 있을 것 같다.
• 함수형 프로그래밍의 인터페이스 분리 원칙
  • 이 원칙은 함수가 하나의 모듈인 FP에서 위반 사례를 찾기란 쉽지 않다.
  • 그래도 저자가 생각했을 때 관련 경험들을 본문에 몇가지 적어 두었다.
    • TS의 인터페이스
    • 너무 큰 모듈은 쓰지 말자 (JQuery 사례)
• 함수형 프로그래밍의 의존관계 역전 원칙
  • React의 hook : 내부 동작은 모르지만 동작의 결과는 알 수 있다.
  • axios 요청을 따로 분리함으로써 데이터 요청이라는 추상화 된 layer를 사용하고 가져오는 데이터를 조작할 수 있다. (테스트 시 mock 데이터를 준다던가..)

시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 SOLID 원칙을 잘 지켜 적용하자.

 

4. 유용한 도구들

• 간단하게 페이지 레이아웃 구성을 만들 수 있도록 도와주는 온라인 도구
• https://layout.bradwoods.io/

CSS Layout Generator

• 크롬 개발 툴에도 뷰 사이즈를 조정할 수 있지만 이 크롬 익스텐션을 사용하면 여러 개의 반응형 화면을 한꺼번에 볼 수 있다.
• https://chrome.google.com/webstore/detail/responsive-viewer/inmopeiepgfljkpkidclfgbgbmfcennb/related

Responsive Viewer