[노트] Deview 2023 Day1
이번 Deview 2023 Day1은 FE 세션 위주로 들었습니다. 코로나 이후 오랫만에 오프라인 세션이라 흥미롭게 참관했습니다.
하나의 코드로 React, Vue, Svelte 등 모든 프레임워크를 지원할 수 있는 CFCs Reactive
#FE # CFCs
FE에서 함수형 프레임워크의 공통점을 분석하여 Cross 플랫폼 지원이 가능하도록 도와주는 라이브러리이다. 함수형 프레임워크를 선언, 등록, 해제, 반환(state, mounted, unmounted, result) 4가지 과정으로 일반화하였고 이 과정을 가지고 있는 React, Vue, Svelte에 맞게 import 하여 라이브러리 사용이 가능하다. 프레임워크의 경계를 넘나드는 대규모 조직에서 코어 로직을 개발하는데 사용하면 적합하겠지만, 일반 서비스 조직에서 러닝커브 때문에 프레임워크를 넘나드는 경우가 얼마나 있을지 의문이며 새로운 컨셉의 언어를 배워야하는 기회비용이 들 수 있을 것 같다. 다만 코어 로직을 CFCs로 미리 일반화해두면 이 후 프레임워크의 전환에 자유로울 수 있고 이 후 나올 주제인 Micro FrontEnd와 조합하여 사용한다면 꽤나 유의미한 사용성을 가질 것 같다. FE만 전문적으로 하는 조직에서 어떤 고민을 하는지 단편적으로 나마 확인할 수 있는 경험이여서 흥미로웠다. 또한 네이버에서 CFCs Static DOM, CFCs Dynamic DOM, CFCs Warp 등등 FE에서 프레임워크를 넘나들 수 있는 고민을 지속적으로 하고 있는 것 같기 때문에 관련 기능을 어떻게 발전하여 정착할 수 있을지 지켜보자.
눈으로 보며 듣는 음성 기록, 클로바노트 서비스의 웹 기술 톺아보기
#zoom open api #clova #monorepo #pwa
네이버 클로바 조직에서 사용하는 전반적인 웹기술을 살펴볼 수 있었다. 우선 서버응답없이 동작할 수 있어햐 하는 앱인 클로바노트에서 PWA를 적극적으로 활용하고 있는 점이 흥미로웠는데, 서버가 연결되어있지 않을 때는 CRUD에서 Read만 가능하고 Create, Update, Delete는 불가하도록 분기로직이 필요하다. (다음 분기는 PWA가 생소하여 몰랐지만 사용한다면 기본적인 내용인듯하다.) 서버가 연결되면 결과를 바로 패치하고 서버가 연결되어 있지 않다면 로컬디비인 IndexedDB를 사용하여 임시로 저장하고 이 후 서버가 연결되면 IndexedDB의 내용을 동기화한다. PWA를 위해 서비스워커에 비즈니스 로직을 사용하지만 서비스워커 로직은 웹배포에 바로 동기화되지 않기 때문에 5분 혹은 일정시간이 지나면 웹배포 여부를 체크하여 서비스워커 로직을 갱신하는 별도 워커를 사용한다고 한다. (기본적으로 24시간안에 브라우저가 알아서 갱신) 이 외에도 manifest.json, indexedDB의 효과적인 관리방법, 서비스워커에서의 디비접근 등등 웹을 앱처럼 사용하는 PWA 사용법을 간접적으로 확인함으로써 막연했던 PWA에 조금은 가까워진 느낌을 받았다.
다음 주제는 반응형 UX에 관련한 내용이였고 UserAgent는 더 이상 사용되지 않아야 하기 때문에 클로바에선 최초한의 정보만 참조할 뿐 디바이스를 판단하는데 사용하지 않는다. 오로지 화면은 반응형 크기에 따라 노출 방식이 결정된다. 반응형에 따라 노출되는 컴포넌트, 동작해야하는 이벤트 (PC환경에선 드래그, Mobile환경에선 롱프레스 같은) 가 달라야 하기 때문에 위키로 반응형 사이즈에 따라 제공하는 스팩을 다르게 정리해둔 게 인상적이였다.
다음 주제는 클로바노트에 zoom api 연동 경험기, 일반적인 서드파티 api 연동 케이스였기 때문에 특별한 점은 없었고, zoom에서 브로드캐스트 방식으로 비동식 송신을 받아오는 케이스가 있는데 이 경우 순서 및 상태를 보장할 수 없기 때문에 RestAPI로 상태를 더블체크한다고 한다. (소켓송신은 비동기이기 때문에 대게 이런 기법을 많이 사용한다.) 그리고 몰랐던 사실인데 이미 zoom api를 이용한 서드파티 앱들이 많이 있었고, zoom api가 상당히 잘되어 있다고 한다.
다음 주제는 모노레포 사용기 및 아토믹 디자인 패턴, 일반적인 내용이지만 하나 기억나는 멘트가 있다면 "저장소가 나뉘면 업무도 나뉜다." 이 말이 상당히 공감이 되었고 전체 프로젝트에 복잡도만 관리할 수 있다면 모노레포가 적극적인 리뷰문화를 장려할 수 있다는 것에 동의한다. (추가로 Docker로 모노레포 각각 저장소를 빌드캐싱한다고 하는데 이 부분 나도 적용해야겠다.)
마지막 주제는 리코일, 현재 가장 React 친화적인 상태관리 라이브러리이며 동시에 러닝커브가 낮아 인기를 얻고 있다. 리덕스에서 리코일로 옮긴 이유가 React18의 동시성때문이라고 한다. 랜더링 스케줄러를 사용할 수 있는 유일한 상태관리 도구이기 때문, 난 다른 장점 때문에 아직 Redux를 사용하고 있지만 프로젝트 상황에 따라 적합한 상태관리 도구는 다르다고 생각하기 때문에 리코일에 대한 최소한의 학습도 필요하겠다.
중요한 건 꺾이지 않는 마음: 스마트에디터의 도전
스마트에디터, 네이버 서비스 전반적으로 글을 편집할 때 사용하는 에디터이다. 스마트에디터를 전문으로 하는 조직이면 FE 태동기부터 네이버에서 FE 조직으로써 꽤나 유서깊은 조직일 것 같고 그 만큼 제안하는 고민, 컨셉들도 흥미로웠다. 우선 스마트에디터의 히스토리, 인상깊었던건 ...
에디터 서비스이기 때문에 FE 개발과 관련하여 고민해볼 부분이 많았을 것 같다.
- Undo, Redo
- Chunk
- Action > 대단히 Functional한 구현체를 만들어서 사용한다. 인풋, 아웃풋에 따라 구현체가 체이닝되고, Success & Fail에 따라 다음 호출 함수가 결정되는 등등 RxJS, Promise 등등 기존에 Functional한 구현체들의 장점을 조합하여 Action이란 구현체를 재정의하였다.
일하다보면 같은 컴포넌트를 서비스에 따라 다르게 보여줘야 하는 경우를 가끔 만나게 되는 스마트에디터조직에서도 같은 고민을 하고 있었고 Dart Sass를 이용한 디자인 일반화 경험기를 공유했다. 마크업을 잘 몰라서 이해가 잘 안되긴 했는데 나중에 필요한 경우가 있을 때 참고해야겠다.
GraphQL 잘 쓰고 계신가요? (Production-ready GraphQL)
#GraphQL
SSR환경에서의 Micro-Frontend 구현과 퍼포먼스 향상을 위한 캐시전략
#Micro FrontEnd #MFE
FE 개발자라면 한 번쯤 고민해봤을 주제인 Micro Frontend를 깊이있게 고민해보고 부딪혀본 경험기.