네이버 DEVIEW 2023 1일차 후기

Mar 12, 2023 eunbin20

올 해 2월 27일 코엑스에서 열린 DEVIEW 2023 day1에 다녀왔습니다. 🥁🥁

이번에 진행된 네이버 DEVIEW 2023은 약 3년만에 개최되는 오프라인 행사라고 합니다! 수 많은 인파 속에서 세션이 끝나면 바로 다음 세션장으로 이동하고, 또 줄서서 입장하며 정신없는 하루를 보내고왔습니다.(총 3500명의 인원이 참여했다고 하네요.. 😇)

이번 컨퍼런스에서는 총 46개의 세션이 진행되었는데요, 이중 GraphQL, Micro-Frontend, SSR 등 저의 업무와 관련있는 도구들에 대한 세션이 있어 제가 만들고 있는 서비스에 접목하여 해결할 수 있는 문제들이 있을것이라는 기대감으로 세션에 참여하였습니다.

그럼 본격적으로 DEVIEW 2023 후기를 시작하겠습니다!

네이버 DEVIEW

네이버 DEVIEW는 내일을 향한 개발자의 시선이라는 의미를 담고있습니다. 국내 최대의 개발자 컨퍼런스로 네이버를 비롯하여 라인, 쿠팡 등 다양한 빅테크 기업의 개발자분들이 진행하시는 다양한 세션이 진행됩니다.

이번 컨퍼런스에서는 인공지능과 머신러닝, 클라우드, 웹, 검색, 모바일, 자연어처리, 데이터, 보안, 멀티미디어, 추천, 인프라 등 총 46개의 세션이 진행되었습니다. 한 타임 당 3개에서 4개의 세션이 진행되었고, day1 하루에만 22개의 세션이 진행되었습니다. 이중 대다수를 차지한 세션의 주제는 역시 AI(인공지능과 머신러닝)였습니다. (AI관련 세션만 24개로 절반 이상을 차지하네요 🤭)

모든 세션들은 https://deview.kr/2023/sessions 에서 발표자료와 간단한 설명을 확인 할 수 있고, 발표 영상도 곧 공개된다고 합니다.

세션

저는 총 4개의 세션에 참여하였습니다.

하나의 코드로 React, Vue, Svelte 등 모든 프레임워크를 지원할 수 있는 CFCs Reactive

NAVER Search 최연규

CFCs(Cross Framework Components)는 하나의 컴포넌트를 다양한 프레임워크에서 공통적으로 사용할 수 있는 구조로 만들어주는 라이브러리입니다.

네이버에서는 egjs라는 js 오픈소스 라이브러리를 개발하고있는데요, 이 라이브러리를 다운로드받는 프레임워크들이 React, Vue2, Vue3, Svelt, Angular 등등으로 다양했다고 합니다. 이때 들었던 생각이 “잘 만들어진 자바스크립트 컴포넌트를 여러 프레임워크에서 사용하게 할 순 없을까?”라는 생각에서 CFCs 라이브러리가 생겨나게 되었다고 합니다.

CFCs Reactive는 함수형 컴포넌트를 지원하는 프레임워크들에 해당 기능을 제공하기 위해 함수형 컴포넌트들의 공통점을 분석하여 각각의 과정을 공통화하였습니다.

함수형 컴포넌트의 공통적인 실행 흐름을 일반화하면 다음과 같습니다.

state 선언
mounted에서 등록
unmounted에서 해제
result에서 state를 반환

위 흐름대로 바닐라 자바스크립트로 작성되어있는 코드를 CFCs Reactive Adapter 코드로 래핑하면 위와 같은 과정 각각을 CFCs의 라이프사이클과 프레임워크들의 라이프사이클을 매칭하여 코드를 실행시킨다고 합니다.

이 라이브러리를 만들기 위해서는 모든 프레임워크의 동작 방식에 대해서도 알고있어야하고, 바닐라 자바스크립트로 짜여져있는 코드에 Adapter 코드를 입혀서 크로스플랫폼화한다는 컨셉을 깊이 이해하고있어야 할 것 같습니다. 😓 네이버와 같이 FE의 규모가 큰 회사에서는 이런 고민을 할 수도 있구나.. 하는 신기함과 동시에 이렇게 상상만 할 수 있었던 방법을 직접 도입해 현업에서 사용하고 계신 것이 놀라웠습니다.

눈으로 보며 듣는 음성 기록, 클로바노트 서비스의 웹 기술 톺아보기

NAVER Cloud 임대현/이은성

클로바노트 서비스에서 사용하는 전반적인 웹기술을 소개해주셨습니다. 클로바노트는 회의중에 주고받은 음성들을 인식하여 텍스트로 변환해주고, 목소리 인식을 위한 화자 분리, 검색, 다운로드 등의 기능을 제공합니다. 또한 Zoom과 연동이 가능하여 Zoom에서 진행한 회의에 대해서도 자동으로 회의록을 만들어서 저장해줍니다.

오프라인 지원(PWA) PWA를 통해 네이티브 앱과 같이 푸시 알림 기능을 제공하고있다고 합니다. 또한 오프라인에서 작동되는 동안에는 CRUD 중 Read만 가능한 상태이기 때문에 이에 대한 분기처리를 진행하고, 나머지 요청들은 IndexDB에 임시로 저장하고 인터넷에 연결된 후 요청을 한 번에 보내는 방식으로 처리한다고합니다.
모노레포

“저장소가 나뉘면 업무도 나뉜다” 모노레포를 사용하면 반복적인 환경 세팅과 코드 중복을 최소화를 통해 개발속도가 향상됩니다. 또한 하나의 레포지토리에서 작업을 함으로써 코드리뷰 문화가 향상되고, 전체적인 팀의 개발 상황을 파악하기가 용이해졌다고 합니다.
아토믹패턴 아토믹 디자인 패턴에서 말하는 ‘아토믹’이란, 더 이상 분해되지 않는 수준이라는 의미를 가지고있는데요, 여기서 ‘더 이상 분해되지 않는 수준’은 다소 애매한 기준이라고 생각하셨다고 합니다. 그래서 mui와 같은 UI 라이브러리에서 제공하는 수준을 분자라고 정의하고 다음과 같이 클로바노트 웹서비스만의 디자인 패턴을 정립하셨다고 합니다.

프로젝트의 폴더 구조 개선이 필요할 때 참고하면 좋을만한 내용인 것 같습니다👍

이밖에도 Zoom, UX, 리코일 등 해당 서비스에서 사용하는 웹 기술들에 대한 내용을 다루어주셨는데요, 크게는 기술 스택, 작게는 하나의 메서드를 선택하여 도입하게 된 배경과 근거에 대한 설명 속에서 서비스와 기술스택에 대한 정확한 이해와 지금과 같은 선택을 하기까지 겪었을 시행착오가 느껴져 인상깊었습니다.

저도 제가 개발하는 서비스에서 사용하는 기술에 대한 더 깊은 이해를 통한 명확한 근거를 가지기 위해 더 노력해야겠다는 생각이 들었습니다.

UI 빌더를 지탱하는 레고 블록 같은 아키텍처 만들기

NAVER ETECH 김훈민

비즈니스가 성장하면할수록, 제품과 기술은 점점 파편화되고, 그로인해 개발 비용이 증가합니다. 프론트엔드에서는 이 문제를 해결하기 위해 어플리케이션을 모듈화하려는 시도를 하지만, 이 문제는 해결이 그리 쉽진 않습니다. 그 방법 중 하나로 많이 사용되는 것이 디자인시스템인데요, 발표자님께서는 이 디자인시스템에서 UI 빌더라는 개념으로 확장하여 이 문제에 접근하셨습니다.

그리고 그 과정에서 레고 블록같은 아키텍처를 지향하며 그 과정에서 마주친 문제들을 하나씩 해결해나가신 과정을 한 단계씩 소개해주셨습니다.

이 세션은 구체적으로 어떤 문제를 어떻게 해결했는지를 관전하는 것도 정말 유익했지만, 개발자가 서비스에서의 문제를 어떤 방식으로 진단하고, 처방하여 문제를 해결해나가는지에 대한 단계적인 흐름을 볼 수 있었던 정말 좋은 발표였습니다. 특히 마지막에는 문제를 해결하는 좋은 방법이 될 수는 있지만 비즈니스적인 가치를 따졌을 때 손해라면 오버엔지니어링일 수 있다라는 결론에 다다릅니다.

공짜 점심은 없다

라는 명언을 남기시며 개발자가 기술을 이용해 문제를 해결하는 과정에서 잊지말아야할 생각을 강조해주신 것 같습니다.

너무 좋은 세션이었지만 점심시간 이후 졸음이슈로 인해 끝까지 집중력을 가지고 듣지 못한 것 같아 개인적으로 아쉬움이 남습니다. 발표 영상이 올라온다면 꼭 다시 한 번 들어보고싶습니다.

GraphQL 잘 쓰고 계신가요? (Production-ready GraphQL)

NAVER Glace 오제관/권기범

네이버 MY플레이스는 식당이나 오프라인 점포에 방문한 사용자가 리뷰를 남기고 공유할 수 있는 서비스입니다. 이 과정에서 필요한 사용자 정보를 불러오는 API, 리뷰 정보를 불러오는 API 그리고 장소/업체에 대한 정보를 가져오는 API 등등 다양한 서버가 각각의 역할에 따라 나누어져있었습니다. 그리고 이 서버들은 대부분 REST API로 구현이 되어있습니다.

이렇게 다양하게 분산되어있는 API를 조합하여 필요한 데이터들을 유연하게 서빙해주기위해 GraphQL 서버를 구축하셨다고합니다.(Backend For Frontend)

이렇게 GraphQL 서버와 클라이언트를 모두 운영하며 아래 8가지의 개념들을 통해 문제들을 어떻게 해결해나갔는지를 공유해주셨습니다. 이 중에서 기억에 남는 문제들 몇가지를 말씀드리겠습니다.

Schema
Field Argument
Enum
Error Handing
Field Resolver
Custom Scalar
Normalization
Fragment

클라이언트에서 UI 렌더링을 위해 복잡한 조건을 다루어야하는 경우

가끔은 클라이언트에서 어떤 UI를 사용자에게 보여줄지말지에 대한 플래그값을 계산하기 위해 복잡한 조건식이나 무거운 연산이 필요한 경우가 있습니다.

이때 Field Resolver를 이용해 해당 조건들과 연산을 수행하는 위치를 서버로 옮기고, 클라이언트는 간단히 isShowable 과 같은 필드만 불러와 UI를 렌더링하도록 만들어줄 수 있습니다. 발표자분께서는 이를 Server-Side Hoisting이라는 개념으로 설명하셨습니다.

사용되지 않는 필드 제거하기

아폴로 클라이언트의 경우, 최상위 쿼리에서 각각의 필드가 사용되고있는지 아닌지를 판단하기가 어렵습니다. 쓰는 곳이 없는 필드가 계속해서 불필요하게 호출되는 상황은 네트워크 리소스의 낭비라고 볼 수 있습니다. 이런 코드가 누적되다보면 실제로 서버 부하가 생길 수도 있습니다.

이를 해결하기위한 방안으로 페이스북에서 만든 Relay라이브러리를 사용할 수 있다고 합니다. Relay에서는 각 컴포넌트에서 자신에게 필요한 필드를 Fragment로 정의하여 Bottom-up 방식으로 선언하여 하나의 쿼리를 만들어 요청을 보냄으로써 꼭 필요한 데이터에 대한 요청만 호출될 수 있도록 개선할 수 있습니다.

Relay에 대해 들어보긴 했지만, 러닝커브가 높다는 소문을 듣고 지레 겁을 먹었었는데, 배우기 어려운 라이브러리인만큼 제대로 사용했을 때 큰 이점을 누릴 수 있겠다라는 생각이 들었습니다.

이밖에도 GraphQL의 클라이언트 캐시, 스칼라 타입 등 GraphQL에 대한 전반적인 내용을 톺아볼 수 있는 시간이었습니다. 특히나 네이버 마이플레이스에서도 GraphQL 서버와 클라이언트 구축을 위해 Apollo 라이브러리를 사용하고있어 반갑기도 했습니다.

후기

훌륭한 개발자분들이 다양한 기술 영역에 도전하며 겪은 여러 경험과 노하우를 엿볼 수 있어 아주 유익하고 재미있는 시간이었습니다. 이번 세션을 진행해주신 모든 연사님들을 보며 ‘저런 발표를 하려면 그 분야에 대해 얼마나 많은 탐구를 통한 깊은 이해도를 가져야하는걸까..’ 하는 생각을 하며 네이버 개발자분들의 기술력에 감탄했습니다.

그리고 ‘네이버에는 서비스가 참 많다’라는 생각도 들었습니다. 이미 알고있는 서비스 외에도 몰랐던 서비스들이 많았고, 알고는 있었던 서비스에서도 몰랐던 기능들이 많았습니다.

하지만, 이해하기 어려운 내용도 많았고 우리 서비스들과는 다른 환경에서의 문제들을 해결한 케이스들이 대부분이라 이 방법들을 직접 가져와서 해결하기엔 무리가 있겠다는 생각이 들어 조금 아쉬웠습니다.

작은 꿀팁이 있다면,, 세션장에 들어가기 전 미리미리 줄을 서세요..

안그러면 바닥에 앉아서 들으셔야합니다 🥲 가까운 건 좋지만 다리가 조금 저리고 목이 아팠습니다 🤕

그럼 이만 DEVIEW 2023 후기를 마칩니다! 👋