코엑스에서 열린 4년 만의 컨퍼런스. 15년째 이어지는 최대 규모의 개발자 컨퍼런스. NAVER DEVIEW.

이제는 이런 컨퍼런스들을 참가하면서 개발 트렌드와 실무에서 다른 개발자분들이 어떤 식으로 작업을 진행하는지 볼 필요성이 있다고 생각했습니다. 그리고 세션들의 내용들도 FE에서부터 AI까지 폭넓게 있었기에 시간이 아깝지 않을 거라고 생각했습니다.

DEVIEW는 DAY1, DAY2로 2일간 진행되며 저는 DAY1만 참가하였습니다.

컨퍼런스는 키노트 진행 이후에 A, B, C, D 섹션으로 구분하여 동시에 4개의 발표가 진행되는 형식으로 진행되었습니다. 총 6개의 발표를 들을 수 있으며 저는 아래 발표를 들었습니다.

1. KEYNOTE NAVER Clova X
2. 하나의 코드로 React, Vue, Svelte 등 모든 프레임워크를 지원할 수 있는 CFCs Reactive NAVER Search(최연규)
3. 눈으로 보며 듣는 음성 기록, 클로바노트 서비스의 웹 기술 톺아보기 NAVER Cloud(임대현/이은성)
4. UI 빌더를 지탱하는 레고 블록 같은 아키텍처 만들기 NAVER ETECH(김훈민)
5. 중요한 건 꺾이지 않는 마음: 스마트에디터의 도전 NAVER ETECH(김성원/이진)
6. 이제는 AI가 읽고(Language), 보고(Vision), 생성하는 Large-scale Multimodal의 시대입니다 NAVER Search(전동현)
7. SSR환경에서의 Micro-Frontend 구현과 퍼포먼스 향상을 위한 캐시전략 쿠팡(박찬진)

DEVIEW 발표 자료와 영상은 DEVIEW 홈페이지에서 확인하실 수 있습니다(영상은 행사종료 이후 업로드).

제가 각 발표를 들으면서 새롭게 알게 된 점, 생각해보았던 것들 위주로 포스팅을 진행하겠습니다.

KEYNOTE

Keynote는 B섹션에서(가장 큰 홀) 진행되었습니다. 매번 영상으로만 보던 컨퍼런스 현장을 눈앞에서 보니 신기한 기분이 절반, 깔끔한 발표 진행에 감탄하는 기분이 절반이었습니다.

Keynote는 Naver의 Hyperscale AI인 HyperClova X에 대한 이야기였습니다. IT공룡기업 네이버가 가지고 있는 수많은 서비스들에 Hyperscale AI를 접목했을 때 얻을 수 있는 여러 도약을 설명하고, 이를 위해서 네이버가 준비한, 그리고 앞으로 할 일에 관해 설명하였습니다.

HyperCLOVA X 그리고 Naver Studio

HyperCLOVA X는 2020년 9월부터 네이버가 준비한 Hyperscale AI입니다. ChatGPT는 한국어를 배운 외국인에 비유하면서, HyperCLOVA X는 한국에 특화된 데이터를 바탕으로 대답하기 때문에 더 우수하다고 말하였습니다.

제가 가장 흥미로웠던 부분은 직접 만드는 AI, NAVER Studio에 관한 이야기였습니다.

“HyperClova X는 언어모델이다. 아무것도 가르치지 않은 언어모델은, 학습된 내용을 그대로 내뱉는 앵무새와 비슷하다.”

뭐든 대답하는 것이 아니라, 바라는 형태로 가공하는 작업을 진행 중이라고 하였고, 이는 Naver Studio에서 사용자가 직접 시도해볼 수 있다고 하였습니다. 그러면 각 분야별 전문가들이 AI를 커스텀하여서 사용할 수 있다는 것이죠.

저는 이 이야기를 들으면서, 이제 이런 식으로 Narrow AI가 사라지는가? 라는 생각을 하였습니다.

사실 저는 단순한 수준의 AI 개발자 직군의 미래에 대해 회의적입니다. “AI의 미래는 너무 밝지만, 그렇기 때문에 AI 개발자가 할 일이 지금보다 줄어들지 않을까”라는 생각 때문이죠. 그 이유 중의 하나가 ‘만능 AI’인 Hyperscale AI의 필연적인 등장이었습니다. 그리고 그것을 컨퍼런스에서 실시간으로 보고 있으니, 거대 AI가 다른 AI들을 잡아먹는 걸 보는 것 같았습니다.

그래도 미래는 어떻게 될지 모르니까요. 알파고 이후로 AI에 최대 관심이 쏠린 지금, Hyperscale AI들이 어디로, 어떤 기술들로 튀어 나갈지 계속 주시해야겠네요.

네이버 데이터센터 그리고 삼성전자

네이버는 국내에서 최대 규모의 데이터센터를 보유한 기업입니다. 즉, AI를 돌릴 가장 좋은 환경을 가지고 있다고 해도 과언이 아니겠죠. 그런 네이버가 삼성전자와 협력하여 AI 반도체 솔루션를 제작하고 있다고 합니다.

네이버와 삼성전자가 손을 잡고 개발한다니 확실히 든든한 느낌이었습니다. 물론 엑시노스와 같은(…) 글로벌 대비 아쉬운 성능이 나오면 결국 해외에서 반도체들을 들여와야겠지만, 이 도전이 잘 해결되어서 국내 기술들로만 만들어 내는 모습을 기대하고 싶네요.

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

네이버의 STT 서비스인 클로바 노트에 적용된 웹 기술들을 설명해주는 발표였습니다.

PWA

클로바 노트는 PWA를 통해서 어플을 서비스한다고 합니다. PWA는 Progressive Web Application의 약자로 웹개발을 위해 만든 프로그램을 바로 어플리캐이션 형태로 만들어내는 기술을 말합니다. 이때, 처리하기 까다로운 문제 중 하나가 오프라인 상태에서 어플의 행동입니다. 웹은 기본적으로 인터넷이 되는 상황을 가정하니 말이죠.

그래서 그 문제는 오프라인 상태에서는 CUD 작업을 내부 저장소(local storage, indexedDb)에 저장하고 네트워크가 가능해지면 그때 Sync를 맞추는 식으로 작업하셨다고 합니다. 이때 사용한 방식이 CRDT라고 하셨는데, CRDT가 뭘까요?

CRDT(Conflict-free Replicated Data Types)

CRDT는 Figma, Google Docs와 같은 실시간 협업 툴에서, 충돌이 나지 않으면서 동시에 같은 데이터를 수정할 수 있게 도와주는 기술입니다.

CRDT는 변경 사항 각각을 유니크한 키를 만들어서 서버에 저장하는 방식으로 서버에서의 병합 과정 없이 사용자들의 입력값의 충돌을 피할 수 있습니다.

그리고 이를 지원하는 yorkie라는 오픈소스 라이브러리가 있습니다. (github, site)(한국 분들이 주로 활동하시는거로 보입니다)

CRDT와 또 다른 동시 편집 기술인 OT에 대해 설명하는 좋은 글도 참고하시면 좋겠네요.

---

그리고 PWA는 웹 브라우저에 의존하기 때문에 caching이 브라우저에서 발생해버리고, 이는 배포가 바로 반영되지 않는 문제가 있었다고 하십니다. 그래서 이를 위해서 추가로 로직을 넣으셨다고 하네요. caching에 대해서 크게 생각하지 않았는데 더 신경 써야겠습니다.

반응형 UI 그리고 반응형 UX

이제 반응형 UI는 너무 당연한 것이 되어버린 2023년… 프론트 개발자의 웃음이 끊이지 않는 것 같습니다.

그런데 새로운 용어가 나왔네요, 바로 반응형 UX.

이제는 폰에서도 마우스를 쓸 수 있고, 노트북에서 터치가 가능합니다. 태블릿은 말할 것도 없죠. 따라서 기존의 user Agent만으로 분기하여 UI, UX를 나누던 방법이 이제는 잘 통하지 않습니다. 따라서 이제는 마우스인지, 터치인지 분기하여서 UX를 구현해야 한다고 말씀하셨습니다. (modernizr라는 라이브러리를 통해 구분할 수 있어 보입니다만, 기본적으로는 CSS3와 HTML5의 지원 범위를 체크하는 라이브러리로 보이네요. 그리고 현재 사이트 접속이 안 된다고 합니다)

모노레포

클로바노트는 프로젝트를 하나의 레포지토리에서 관리하는 “모노레포” 방식을 사용한다고 합니다.

모노레포의 기술적인 장점은 다음과 같습니다.

• 반복적인 환경 세팅, 코드 중복 최소화
  • 매번 세팅해줘야 하는 린팅 규칙과 같은 부분을 하나의 파일로 관리할 수 있습니다.
• 효율적인 의존성 관리
  • 서로 다른 프로젝트에서 중복적인 package를 사용할 때. 이를 하나의 패키지로 관리할 수 있습니다.
• 단일 이슈 트래킹
  • 하나의 이슈에 대해서 여러 프로젝트 멤버들이 트래킹할 수 있습니다.
  • 리뷰 문화가 활성화됩니다.
• 통일된 CI/CD
• 각자의 역할에 집중된 작은 패키지들

지금 보고 계시는 이 블로그는 git submodule을 사용하여서 구현하였습니다만, 결국 서비스별로 레포지토리가 분리되어있고, 최상위 레포지토리는 빌드와 배포 관련 코드가 바뀌지 않는 한 변경되지 않습니다. 따라서 (그마저도 부실한) 빌드와 배포를 제외하고는 모노레포의 장점은 없고, 그냥 하나의 레포지토리에서 묶어놓은 특징밖에 없다는 것을 깨달았습니다. 다음 프로젝트는 모노레포를 사용해서 구현해봐야겠네요. 모노레포는 npm, yarn과 같은 대부분의 패키지 툴에서 관련 기능들을 제공하고 있습니다.

아토믹 디자인 패턴

아토믹 디자인 패턴은, 모듈을 원자부터 페이지 단위까지 구분하여서 조립하는 식으로 개발을 진행하는 패턴을 이야기합니다.

저는 현재 페이지-컴포넌트 형태만 유지하면서 개발을 진행하고 있었습니다. container-presenter, compound component, 등등.. 필요에 따라 패턴을 이것저것 적용하면서 만들고 있죠. 하지만 결국 이러한 방식은 코드의 통일성을 해치고 복잡도가 올라감을 현재 “강하게” 느끼고 있습니다. 개발 코드는 가능한 한 명확해야하며, 통일된 규칙을 따르는 게 코드가 쉬워지고, 코드가 쉬워야 개발이 쉬워집니다.

이러한 갈증이 있는 도중 아토믹 디자인 패턴을 소개받았습니다. 물론 실제로 이렇게 완벽하게 구분 짓는것이 쉽지는 않겠으나, 한번 도전해봐야 할 것 같습니다. 이제는 패턴으로 발생하는 오버헤드를 조금 눈감아 주고, 그 이득을 맛보고 싶네요.

카카오 프론트엔드 팀의 아토믹 디자인

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

네이버 스마트 에디터를 담당하는 NAVER ETECH 팀의 HomeBuilder, nBilly(HomeBuilder 2.0)에 관한 발표였습니다.

UI 빌더

페이지를 구성하는 여러 가지 블록을 레고처럼 GUI로 조작하여서 실제로 사용될 수 있는 페이지를 만드는 것을 도와주는 프로그램이 UI 빌더라고 합니다. 이 내용은 2021년 DEVIEW 발표 자료를 참고하시면 더 이해하기 쉽습니다.

저는 먼저 이 프로덕트를 보고, “프론트엔드 시장은 저런 식으로 넘어갈 수 있겠구나!” 라는 생각이 들었습니다. 코드를 모르는 일반인들도 최대한 사용하기 쉽게 GUI로 화면을 구성하면 code 없이 웹사이트 전체를 구축할 수 있으니 말이죠. 워드프레스와 파워포인트 그 사이 어딘가를 지향하는 느낌입니다. 물론 프론트엔드 개발자가 사라지진 않겠죠, 화면만 그리는 것 말고도 할 일은 아직 많으니까요. 하지만 저런 기술이 더 발전하면 개발 속도도 훨씬 빨라지길 기대하게 됩니다.

아키텍처

첫 아키텍처 구조와 최종 아키텍처의 구조

아키텍처를 어떻게 설계하여서, 복잡도를 낮추고, 최소한의 비용으로 최대한의 개발을 해내는지에 관한 이야기였습니다. 문제를 만나고, 그 문제를 해결하기 위해서 아키텍처를 하나씩 추가, 변경해 나가는 모습이 매우 인상적이었습니다. 물론 발표를 들으면서 해당 내용을 온전히 이해하기에는 벅찼지만, 문제를 대하는 태도, 가져야 하는 자세, 사고방식 등을 엿볼 수 있었던 발표여서 가장 기억에 남는 발표 중 하나였습니다. 저도 이런 자세로 개발을 이어 나가고 싶네요.

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

쿠팡의 프론트엔드를 Micro-Frontend로 전환하는 이야기를 해주신 발표였습니다.

Micro-Frontend

말 그대로 화면 전체가 아닌, 각 컴포넌트 별로 구현, 빌드, 배포하는 기술입니다. 저는 Micro service의 프론트엔드 버전을 생각하였습니다.

큰 규모의 서비스를 운영하며, 다양한 팀들과 협업하다 보면 Micro-Frontend는 언젠가 만나게될 운명처럼 보였습니다(발표자분은 구현이 어려우니 꼭 필요에 의해서 구현하라고 당부하시긴 했습니다.). 하지만 리액트, 뷰와 같은 프론트를 어떻게 분리한다는 걸까요?

그 방법은

1. 런타임시에
2. 원격지의 파일을 가져와
3. 동적으로 렌더링(삽입)

이었습니다.

어쨌든 각 프론트의 컴포넌트 파일들은 import 하여서 합쳐지니, 해당 import 위치를 원격지의 파일로 변경하는 것이 핵심 아이디어입니다. 이와 관련된 라이브러리들도 있기 때문에 해당 구현은 어렵지 않다고 하네요.

하지만 SSR에서 이를 구현하려면 여러 문제가 발생하기 때문에, 이후 발표는 해당 문제 해결법을 위주로 진행되었습니다. 흥미로운 이야기들이 많으니 꼭 한번 보시길 추천합니다.

캐시

캐시… 캐시를 이렇게 중요하게 생각하는지 몰랐습니다. 그냥 “브라우저에서 지원해주는 건 믿고 써도 되지 않나..?” 정도로만 생각했죠. 하지만 CDN서버를 만들고, 어떤 데이터를 캐싱할지에 대해 설명해 주시니, 정말 생각지도 못한 많은 문제가 있음을 느꼈습니다.

캐싱이 있을 때와 없을 때의 그래프를 보고, 너무나도 압도적인 성능 차이를 느꼈습니다. 캐싱에 대해서도 공부를 해봐야겠네요.

프론트엔드도 Docker

또한 도커 빌드를 통해서 캐싱전략도 취한다고 합니다. 주제와 맞지 않아 언급만 하고 넘어가긴 했습니다.

저는 개발환경, 배포 환경을 모두 Docker로 설정하고 사용하고 있습니다. (역시나) 캐싱과 같은 부분을 크게 고민하지는 않고 있습니다. 빌드시간이 좀 걸리더라도 어차피 제 서비스들이고, 사용자가 많지 않기 때문이죠. 그리고 Docker는 DevOps나 백엔드쪽의 고민이라고 생각하고, 사용에만 초점을 두고 Docker를 사용하고 있었습니다.

하지만 이제는 더 이상 그렇게 안일할 수 없다는 생각이 들었습니다. SSR 때문에 프론트도 백엔드 못지않게 서버를 사용하기 시작하고 빌드, 배포, CI/CD에서 이제 Docker는 특수한 경우가 아니면 늘 따라오기 때문이죠. 백엔드스러운 내용들이라도 잘 살펴보고 공부할 필요가 있겠습니다.

마무리

프론트엔드로서 여러 가지를 생각해 볼 만한 발표들을 정리해 보았습니다. 역시나 느낀 것은 “아직 많이 부족하다.” 입니다. 하지만 또 한편으로는 “실무도 크게 다르진 않군. 삽질.” 또한 느꼈습니다.

지금까지 실서비스를 운영해보지 않은 것은 아닙니다만(DACON, DAPADA) 사용자가 그리 많지 않았고, 정말 가벼운 서비스들이었기에 큰 문제가 발생한 적은 없었습니다. 그렇기 때문에 개발에 대해서 너무 무디게 생각하게 된 점도 있는 것 같습니다. 지금부터라도 다시 감각을 날카롭게 만들어서, 더 빠르고, 더 가볍고, 더 안정적인 프로그램을 만들도록 노력해봐야겠네요.