‘데뷰(DEVIEW) 2023’ 웹 세션을 돌아보며

데뷰(DEVIEW)는 네이버에서 주관하는 국내 최대 규모의 개발자 컨퍼런스다. 국내외 개발자들이 모여 최고의 기술과, 경험, 노하우를 공유하고 함께 성장하는 것을 모토로 삼는다. 데뷰 2023은 지난 2월 27일, 28일 양일간 열렸다. 올해는 선착순 신청을 통해 티켓을 무료로 배부했는데, 대학교 수강신청이나 인기 콘서트 티켓팅에 버금갈 정도로 경쟁이 치열했다. 나도 티켓팅을 시도했지만 실패해서 이후 올라온 영상으로 세션을 확인해야만 했다.

올해 역시 다양한 세션이 준비됐는데, AL/ML, 클라우드, 웹, 모바일, 서버 등 개발과 관련된 거의 모든 분야의 주제를 다뤘다. 모든 세션을 다루기에는 분량이 너무 많아, 이번 글에서는 웹 파트의 주요 세션들을 중심으로 간단히 내용을 요약하고 느낀 점을 공유하고자 한다.

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

• 연사: 최연규(NAVER Search)

세션 요약

CFCs(Cross Framework Components)는 하나의 컴포넌트로 여러 프레임워크(React, Vue, Angular, Svelte 등)에서 교차해서 사용할 수 있는 구조의 컴포넌트를 말한다. CFCs 모듈은 하나의 컴포넌트를 모든 프레임워크에서 사용할 수 있도록 변환해 준다.

컴포넌트는 일반적으로 메서드, 이벤트, UI, 상태로 구성되어 있다. 프레임워크 전용 컴포넌트가 아닌 경우 하나의 컴포넌트를 래핑하거나, 마운트해서 프레임워크 컴포넌트로 만든 후 사용해야 한다. 이 과정에서 메서드, 이벤트, UI, 상태를 부분적으로 지원하는 경우가 대부분이다. 컴포넌트별로 수정해야 할 사항들이 많아질수록 복잡도는 몇 배로 증가하게 된다.

CFCs의 컨셉

1. CFCs DOM : DOM을 생성하거나 변경하는 UI 컴포넌트를 프레임워크에서 지원
2. CFCs Reactive : DOM보다 유틸 컴포넌트에 상태를 부여하여 프레임워크에서 지원

이미지, 비디오 등을 처리하는 유틸 컴포넌트인 ImReady를 지원하기 위해 CFCs Reactive를 개발하기 시작했다. 이벤트 기반이 아닌 상태 기반으로 감지하는 방식을 선택했다. 여러 프레임워크에서 state → mount → unmount → result 방식이란 공통점이 있었고, 여러 이벤트에서도 감지할 수 있기 때문이다.

또한 CFCs Reactive는 프레임워크와 유사한 라이프사이클을 제공한다. 상태를 선언, 변화, 감지할 수 있고 여러 프레임워크에 호환이 가능하다. 바닐라 컴포넌트를 프레임워크에 지원하기 위한 중간 단계의 호환 코드인 adapter도 제공한다.

느낀 점

나는 회사에서 프론트엔드 개발을 리액트로만 해와서, 이렇게 여러 프레임워크에 호환되어야 하는 코드를 작성할 기회가 별로 없었다. 다른 라이브러리(Vue, Svelte)도 써본 적은 없지만, 전반적으로 라이프 사이클이나 상태를 관리하는 흐름은 비슷해서 언젠가 필요할 때 빠르게 배울 수 있을 것 같다고 생각했다. 또한 다양한 프레임워크 기반의 코드 베이스가 존재하는 큰 규모의 회사나 레거시가 많은 회사에서는 유용하게 써볼 수 있을 것이다.

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

• 연사: 임대현, 이은성(NAVER Cloud)

세션 요약

클로바노트는 말을 글로 옮겨주는 서비스로, 클로바노트 V2에서는 오프라인 지원 예정이다. 팀에서 PWA를 Next.js, next-pwa, workbox를 가지고 구현했다. 오프라인 지원 방법은 온라인 상태에서 C(Create), U(Update), D(Delete)에 대한 로직을 Service Worker에 Cache로 들고 있어야 한다. 그리고 CUD가 필요한 부분은 Indexed DB를 통해 로컬 DB에 저장 후, 온라인이 되었을 때 싱크를 맞춰 주어야 한다.

PWA 서비스 배포를 하면 기존에 로컬 브라우저에 저장되어 있던 CSS, JS 등의 파일이 바로 업데이트되지 않는다. 서비스 워커에 저장된 해당 파일들이 OS, 브라우저마다 다른 스펙으로 일정 시간 후(일반적으로 24시간), 자동 배포가 이루어지는데 이를 제어할 수가 없었다. 이를 웹 워커 로직을 구현하여 5분마다 주기적인 업데이트하여 해결했다.

또한 사용자들이 점점 더 다양한 디바이스를 사용함에 따라 반응형 UX를 도입했다. PC에서도 터치를 할 수 있고 모바일에서도 마우스를 쓸 수 있는데, 이를 구별해 주기 위해 modernizr를 사용했다. user-agent는 참고용으로만 사용한다.

클로바노트에서 사용하는 주요 웹 기술로 최근에는 ZOOM을 연동했다. 단순하게 줌 음성 파일을 클로바노트로 작성해 주는 자동화 기능 구현을 넘어, 라이브스트림을 통해 실시간으로 회의록을 작성하는 기능을 구현했다. 이 과정에서 RTMP(Real Time Message Protocol)을 사용했고, 이 통신을 맡을 서버를 node-media-server를 통해 구축했다.

모노레포를 도입한 경험도 있다. 여러 기술적인 장점이 있는데 가장 큰 장점은 팀과 협업하는 관점에서 규칙을 같이 가져갈 수 있다는 점이다. 특히 하나의 레포에 있다 보니 관심이 많아지면서 적극적으로 코드 리뷰를 하기 시작했다. 더불어 클로바팀의 개발 문화는 아프리카 속담에 “한 아이를 기르기 위해서는 온 마을이 노력해야 한다”라는 말이 있듯이, 아이에만 집중하지 말고 어떤 마을을 아이에게 줄지 고민해야 한다는 것이다.

느낀 점

클로바노트라는 흥미로운 서비스에 대해 알 수 있는 시간이어서 유익했다. 사용하기 편하고 보기에도 깔끔한 서비스를 만들기 위해 보이지 않는 곳에서 팀이 얼마나 노력했는지도 잘 느낄 수 있었다. ZOOM 연동, 모노레포, 아토믹 디자인 시스템, 리코일 등의 내용은 프론트엔드 개발을 어느 정도 해 본 사람이라면 대부분 경험해 봤거나, 최소한 들어보았을 내용일 것이다. 특히 인상 깊었던 점은 이 도구들을 팀의 상황에 맞게 어떻게 커스텀 했는지 솔직하게 공유해 줘서, 이런 점에서 많은 인사이트를 얻을 수 있었다.

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

• 연사: 김훈민(NAVER ETECH)

세션 요약

내 마음대로 조립할 수 있는 레고 블록 같은 컴포넌트를 만들고 싶다는 목표를 가지고 시작했다. 팀이 다른 조직들을 지원하는 개발 대리인의 역할을 해왔는데, 앞으론 기술 제공자가 되어 필요한 곳이 우리가 만든 도구를 가져다 쓰는 식으로 업무 방식을 바꾸려고 노력했다.

그래서 레고 블록 같은 SDK를 만들기로 했고, 그 시작이 데이터 플로우였다. Redux 아키텍처를 일부 커스텀해서 토대를 쌓고 2-계층 아키텍처를 만들었다. 하지만 이 계획을 실행하다 보니 여러 문제들이 생기기 시작했다.

첫 번째 문제는 코어 로직이 너무 까다롭다는 점이다. 기능이 추가되고 요구사항이 변경될 때마다 코어의 로직을 수정해야 하는 번거로운 일들이 발생했다. Headless UI처럼 만들어서 로직만 제공하고, 뷰는 알아서 만들게 하는 것을 기대했으나 결과적으로 코어와 프로덕트의 책임이 모호해지는 결과가 나타났다. 2-계층 아키텍처 특성상 책임을 두 곳에 분산하는 데 코어를 작게 만들면 프로덕트가 많은 책임을 떠맡게 되었다. 이 문제를 해결하기 위해 1) 기초 라이브러리 및 유틸리티 2) 모델 및 상태관리 3) UI 빌더 4) 서비스 애플리케이션 이렇게 계층을 4 단계로 나누고 책임을 재설계했다.

두 번째 문제는 프로덕트 뷰가 너무 무겁다는 점이다. 프로덕트 계층에서 만들어야 하는 UI 컴포넌트가 너무 많았고 UI 파운데이션의 부재를 느꼈다. 이를 해결하기 위해 공통 UI 체계인 디자인 시스템을 만들었다. 디자이너가 없는 상황에서 디자인 시스템을 만들어야 해서 괜찮은 기성품에서 시작해 디자인 시스템을 구축했다. 이때 차크라 UI를 선택했는데 컴포넌트를 61종이나 지원했다. 또한 커뮤니티가 잘 되어 있고, 피그마 리소스를 지원하는 등 커스텀하기 좋다는 점이 매력적이었다.

세 번째 문제는 커스텀 동선이 너무 길다는 점이다. 우선 사용자 관점에서 너무 불친절하다는 것이 문제였다. 이를 위해 변경을 모듈화해서 동선을 최소화하는 방향으로 나아갔다. 관심사를 1) 모델 2) 뷰 3) 로직 4) 프로퍼티까지 네 가지로 분리해, 사정을 가장 잘 아는 사람에게 책임을 부여했다. 예를 들어, 프로퍼티는 UI 빌더에 옮기는 식으로 말이다. 결과적으로 동선이 짧아져 예측 가능성을 높일 수 있었다.

느낀 점

이번 세션은 블로그에서 에디터 서비스를 지탱하는 ‘nBilly’ 플러그인을 만들며, 고민했던 문제들을 알 수 있어서 유익했다. 여러 사람이 각자 다른 목적으로 사용하는 SDK와 같은 서비스를 만들기 위해선, 혼자 개발하는 과정에 비해 고려할 점이 정말 많다는 것도 느꼈다. 이러한 문제 해결 과정을 상세하게 볼 수 있어 더 의미 있었고, 아키텍처가 문제 해결을 위해 계속 바뀐다는 점에서 살아있는 소프트웨어 같다는 생각도 들었다. 만약 디자인 시스템이나 UI 빌더를 만드는 팀에 있다면, 엔지니어로서 많은 인사이트를 얻을 수 있을 것이다.

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

• 연사: 오제관, 권기범(NAVER Glace)

세션 요약

네이버 플레이스에선 GraphQL를 어떻게 사용하고 있을까? 첫 번째로 GraphQL 스키마는 클라이언트 중심으로 설계가 이루어진다. 여러 개의 데이터 소스가 있어도 클라이언트 데이터 스키마만 바라보고 사용할 수 있다. 이미지 섬네일을 불러올 때 불필요하게 복잡한 스키마가 만들어지는 경우가 있는데, 이때 field argument를 사용해서 간결한 스키마로 만들 수 있다.

GraphQL 에러 핸들링 방식은 GraphQL이 모든 요청에 대한 응답을 200 상태 코드로 내려주기 때문에 다른 방식의 접근이 필요했다. 금칙어를 사용해야 할 경우도 있는데, 이러한 데이터를 하나의 스키마에서 가져오기 위해 유니온 타입이 사용된다.

또한 확장이 필요한 경우 인터페이스를 통해 확장할 수 있는데, 기본 에러 인터페이스를 만들고 그 인터페이스를 다른 여러 종류의 에러(중복 에러, 금칙어 에러 등) 타입에 사용한다. 이렇게 하면 깔끔하고 명시적인 에러 핸들링이 가능하다.

더불어 타입을 커스텀하게 지정하는 방법은 예를 들어, email, url, phoneNumber 등의 값들은 string으로 받을 수도 있지만 너무 광범위할 수 있다. 이런 경우 GraphQL의 스칼라를 통해 더 좁고 명확한 타입을 지정해 줄 수 있다.

느낀 점

그래프QL(GraphQL)은 API를 위한 쿼리 언어로 최근 몇 년간 여러 곳에서 사용하고 있는데, 아직 REST 방식에 비해 레퍼런스나 문서가 부족한 점이 아쉬웠다. 이번 세션을 통해 그래프QL 사례를 좀 더 살펴볼 수 있어 유익했다. 기본적인 그래프QL을 공식 문서를 기반으로 사용해 봤다면, 여기서 좀 더 응용해 보고 싶을 때 참고하면 좋을 것이다.

5. SSR환경에서의 Micro-Frontend 구현과 퍼포먼스 향상을 위한 캐시전략

• 연사: 박찬진(쿠팡)

세션 요약

우선 쿠팡의 마이크로 프론트엔드 아키텍처 전환 도입 배경은 광고 및 프로모션 랜딩 페이지를 만들면서 많은 팀이 사용하게 되었고, 이에 신규 기능 개발 요청이 많아지게 됐다. 리소스는 제한되어 있기에 대응이 어려워진 것이다. 처음에는 외부에서 단일 패키지에 코드 커밋을 하는 방식으로 시작했으며, 모노레포로 각 서비스별 패키지를 두고 개발하는 방식으로 발전했지만 여전히 문제는 남아 있었다.

결국 마이크로 프론트엔드를 도입을 하게 되었다. 컨테이너 중심으로 각 파트를 통합하고, 인터페이스 기반 느슨한 결합을 통해 직접 참조를 지양하는 방향으로 설계했다. 또한 각각 마이크로 프론트엔드 번들을 독립적으로 배포했다. 이 설계의 핵심은 코드를 통합할 때 런타임에서, 원격으로, 그리고 동적으로 통합한다는 점이다.

다만 여기서도 문제가 발생했는데 바로 번들러를 원격, 그리고 동적으로 임포트 할 수 있는지에 대한 이슈였다. 이를 해결하기 위해 Webpack Module Federation을 도입하여 런타임에서 여러 모듈을 통합했다. SSR 관점에서 보더라도 Next.js에서는 Federated SSR을 지원하고, Dynamic HTML Streaming을 통해 각각의 FE 서버에서 만들 HTML을 컨테이너에서 통합할 수 있다.

하지만 이 방법을 사용했을 때의 가장 큰 문제는 각각의 위젯 팀마다 서버를 따로 운영해야 한다는 점이다. 팀에서 원하는 방식은 각각 따로 빌드된 컴포넌트 번들을 SSR 할 때 런타임에서 불러오는 것이었다. 그래서 런타임 원격 코드 동적 로딩을 서버 사이드와 클라이언트 사이드에서 고민 후 개선했으며, 여러 모듈을 버전별로 배포하고 롤백하는 과정을 거쳤다.

느낀 점

이 세션에선 발표 후반부에 데모를 직접 보여준 것이 인상적이었다. 마이크로 프론트엔드를 도입하기까지 여러 시행착오를 겪었고, 이런 경험을 공유하기까지 얼마나 많은 노력이 있었는지 알 수 있었다. 마이크로 프론트엔드에 대해 궁금하거나, 도입을 준비하고 있다면 참고해 보면 좋을 것이다.

마치며

이번 데뷰 2023 웹 분야 주요 세션을 살펴보니, 많은 개발팀에서 높은 수준의 기술적인 도전을 하고 있음을 알 수 있었다. 늘 같은 도구만 사용하면 생산성은 높을 수도 있지만, 새로운 도구를 받아들일 기회가 줄어 시야가 좁아질 수 있다. 이미 국내에서도 데뷰나 파이콘처럼 수준 높은 개발 컨퍼런스가 점점 많아지고 있다. 또한 관심만 가지면 해외에서 열리는 컨퍼런스도 얼마든지 온라인으로 참여할 수 있다. 

개발자로서 긴 커리어를 만들어 가려면 자신만의 컴포트 존을 벗어나는 것이 중요한데, 그 순간은 귀찮고 힘들겠지만 꼭 필요한 과정이라 생각한다. 이때 컨퍼런스를 통해 인사이트를 얻는 것도 하나의 방법이니 적극 활용해 보길 바란다. 더 많은 세션 내용은 DEVIEW 2023 공식 홈페이지에서 확인할 수 있다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.