당근에서 주최하는 당근테크밋업에 다녀왔다. 예전부터 개발자 친화적인 모습을 대외적으로 많이 보여줬고, 기술적인 주제에 대해 다양한 채널을 통해 소통해왔기에 테크 행사를 연다고 하면 배울 거리가 많은 알찬 행사일 것이라는 기대감이 한참부터 있었다. 무엇보다도 올해는 이런저런 이유로 회사 일 외에는 그다지 기술적인 관심을 안/못 기울였기에, 이렇게라도 못다한 과외 학습을 좀 해두고 싶었다.

이미 행사가 열린지 두 달 정도가 지난 지금에서야 뒤늦게 후기를 올리게 된 사유는, 그동안 귀찮아 미뤄둔 것도 있었지만 발표를 자세한 기록없이 듣고 느끼고만 왔기에 복기가 쉽지 않았다(다음부터는 행사 참석하고 시간이 많이 가기 전에 후기를 꼭 써두자). 그래서 행사 영상이 올라오면 이를 다시 보면서, 그때의 감상과 생각을 되새겨보고 싶었다. 후기이니까, 기왕이면.

혹시 그날 행사를 놓치신 분들도 당근 공식 유튜브에서 얼마든지 시청이 가능하니 시간이 된다면 관심이 가는 주제를 보면 좋겠다. 미리 결론부터 말씀드리자면 굉장히 알차고 재미있는 행사였다.

2024 당근 테크 밋업
재생 목록 링크

1.

행사 참가는 참가 신청자들을 대상으로 추첨하여 선정된 사람만이 가능했다. 요새 열리는 여느 테크 행사와 마찬가지로 크게 다를 것은 없었다. 더러는 선착순 신청을 받는 경우도 있는데 개인적으로는 그것보다는 차라리 훨씬 공평한 방법인 것 같다. 피지컬 이슈로 번번히 고배를 마시는 경험을 최근 몇번 했기에, 선착순으로 참가 신청을 받는다고 하면, 추후 발표 영상이 올라오는지 확인한 후에 아예 눈길도 주지 않게 되는 경향이 생겼다. 운영하는 분들의 사정을 감안해서 입장료를 받는 것도 괜찮은 접근같지만 주로 학생 / 취준생을 대상으로 한 행사에서는 그런 부담스러운 방법은 잘 쓰지 않는 듯 하다.

참가 신청은 festa.io 로 받았는데, 늘 그렇듯이 특이사항 없이 매끄럽게 신청할 수 있었다. 그런데 이런 행사가 처음이었어서 그런지, 참가자 선정 발표 공지에서 약간의 해프닝이 있었다.

festa.io 도메인의 이메일로 참가자 선정 / 탈락 이메일이 몇 차례 오는 통에 급기야 사과 공지까지 왔다. 누구의 실수였는지는 모르겠지만 굉장히 놀라고 당황스러웠을 듯하다. 아무튼 나는 어찌저찌 참가자로 선정되었고 행사일만 기다렸다.

행사 안내와 운영

원래 동아리 운영하던 감각과 기억이 있어서인지 행사 운영하는 방식에도 눈길이 갔다. 당근에서는 행사 진행과 운영에 대한 안내를 전달하는 데에 아래의 도구를 활용했다. (더 있을라나)

• 당근 테크 밋업 공식 사이트
• Notion
• 당근 서비스

행사 신청과 기본적인 정보에 대한 것은 (다른 행사들이 대체로 그러했듯) 행사 공식 사이트에 올려놓고, 실제 행사에 참석하는 사람들이 궁금해할 구체적인 행사 정보와 발표 안내 등은 Notion으로 별도 페이지를 만들어서 공유했다. Notion에서는 행사장 정보, 행사 일정, 각 트랙 별 세션 자료 링크 등을 제공했다.

일반에 공개되는 정보와 실제 참가자들에게 필요한 상세 정보를 구분하여서 제공한다는 전략은 탁월했다고 생각한다. 어차피 상세 정보는 실제 참가자들만 궁금하지 외부인은 궁금하지 않을 테고, 참가자들은 자신이 필요한 정보만 모아둔 간략한 사이트를 원할 것이니까. 무엇보다도 Notion은 운영자가 사이트 내용을 수정하면 이것이 실시간 반영되도록 하는 (가장 중요하면서도 편리한) 기능을 자체적으로 제공한다. 운영진에서 이런 기능을 직접 만들어야 하는 수고로움을 덜어준다.

한편 당근이 가지고 있는 서비스 인프라를 적극 활용해서 자신들이 주최하는 행사에 그대로 활용하였다는 점도 흥미로웠다. 행사 참가자들에게 한번에 공지와 안내를 전달할 수 있도록, 당근에서 제공하는 커뮤니티 기능을 사용했다. 앞서 행사 공식 사이트와 Notion은 주최 측에서 일방향적으로 정보를 제공하는 매체였다면, 당근 커뮤니티 기반의 채팅은 주최측과 참가자(전원!)이 자유롭게 소통할 수 있는 매체였다.

이러한 특성을 사용해서 이 채팅방 안에서는 다양한 사람들 간에 실시간적으로 정보가 오고가고, 다양한 일들이 벌어졌다. 주최측은 행사 진행 중 공지할 일이 있으면 바로 이 채팅방을 통해서 공유하였다. 이에 더하여 참가자들은 (기존의 전통적인 방식의 행사 참여를 넘어) 다른 참가자들과 소통하며 행사의 일부분이 되어갔다.

가령,

• 행사 운영 관련하여 누군가가 질문을 올렸는데 주최측이 바로 답변이 어려운 상황일 때 참가자가 이를 대신 답변하는 집단지성을 발휘함
• 행사 도중 분실물이 생긴 경우에 이를 채팅방에 공유하여 주인을 찾아줌
• 기술 도메인이 겹치는 참가자 간에 네트워킹을 제안하고 즉석에서 모임을 개최
  • 행사 경품을 서로 공유하고 교환 제안
• 당근 커뮤니티의 '후기' 기능을 이용하여 이번 행사에 대한 후기를 작성하고 서로 공유
• 후원사 담당자가 채팅 서비스 내에서 자사 부스나 행사를 공유하고 참가 유도

재미있는 것은 이러한 행위들이 누가 시켜서 이루어진 것이 아니라 자발적인 것이었다. 행사에 참여하는 사람들이 모두 대부분 기술에 친숙한 사람들이고, 또 어느정도 검증이 이루어진 커뮤니티 내의 반익명적인 만남에 대한 거부감이 덜한 사람들이다보니, 이러한 생산적이고 긍정적인 커뮤니티 형성이 자연스럽게 이루어진 듯 하다. 무엇보다도 당근이란 서비스가 어느정도 실명제 서비스에 가깝고 기술 행사 특성상 사실상 실명 기반으로 참가하는 상황이다보니, 특이 행동하는 사람이 덜 하고 자발적인 자정 작용이 있는 것도 있었던 것 같다.

비슷한 방식으로 최근 참석한 모 행사에서는 카카오톡 오픈채팅을 활용해서 동일한 목표를 달성했다. 외부 인프라애 의존할 필요 없이 그대로 자사 기능을 활용할 수 있는 환경을 가진다는 것이 굉장히 멋있게 느껴졌다. 이런 것들이 모여서 당근이라는 회사가 기술친화적이라는 이미지를 브랜딩하는 데에 차근차근 한 몫 하지 않을까? 멋있으면서 부럽다는 생각이 들었다.

주절주절 설명이 길어졌는데, 요약하면, 정보 전달의 긴급성, 실시간성 등을 고려하여 설계한 정보 제공의 계층이 절묘하게 맞물려 잘 돌아간 것이 인상적이었다.

2.

행사는 코엑스에서 열렸는데, 집이 한강 이북이다보니 가는 데만 편도 1시간이라 너무나 멀었다. 게다가 하필 그날 원인 모를 이유로 발목을 삐어서 정말 절름발이처럼 어기적어기적 걸어서 행사장까지 갔다. 뭔 행사장이 이리도 먼지... 연차 쓰고 일찍 나왔건만 발이 아파 어디 돌아다닐 수도 없어 딱히 할일이 없어진 나머지 카페에서 대충 업무를 봤다. 세상에...

행사 입장등록하기 전에 근처에서 간단하게 밥을 먹었다. 걍 흔한 오피스 근처 밥집 느낌이었다. 냠.

네트워킹 세션

행사 등록은 10시 30분부터였지만 첫 세션은 12시부터여서 그 사이 여유 시간이 있었는데, 그 시간은 공식적인 네트워킹 시간이었다. 단순히 네트워킹 시간과 공간만 제공되는 것이 아니라, 당근 내부 개발팀 구성원과 이야기를 나눌 수 있도록 네트워킹 행사가 운영되었다.

네트워킹 세션의 운영 방식도 당근스러웠는데, 당근 앱의 '모임'을 사용해서 참가자를 모아 진행되도록 운영되었다. 주제 별로 '일정'이 생성되면, 정해진 숫자만큼 선착순으로 신청하여 네트워킹 그룹이 구성되는 방식이다. 일정 글은 행사 전날 정도부터 순차적으로 '모임' 안에 올라왔는데, 선착순이다보니 일정이 올라오는 족족 모두 마감될 정도로 많은 사람들이 관심을 가졌다. 현직자와 만나 이야기를 나눌 수 있는 기회이니, 당근이라는 회사와 서비스에 대해 알고자 하는 분들께 이보다 더 좋은 기회가 있었을까 싶다. 나의 경우 업무 시간에 모임이 올라오다보니 흥미가 갈 만한 주제의 일정은 일찌감치 다 마감이 되어버렸다...

재미있는 점은, 당연하게도 그 모임에 소속된 사람은 누구나 새로운 일정을 만들 수 있어서, 당근 현직자가 개설한 일정이 아니더라도 다른 테크밋업 참가자들이 자유롭게 즉흥적인 일정을 만들고 참여할 수 있었다는 것이다. 비록 선착순 모집을 놓쳐서 원하던 일정에 들어가지 못했더라도, 네트워킹에 관심이 있는 사람은 누구나 일정을 만들고 참여할 수 있는 기회가 주어지는 셈이다. 이런 다양성과 참여가 당근이라는 서비스의 가져다주는 큰 가치 중에 하나가 아닐까 싶다.

3.

입장등록을 마치면 놀이공원 온 것처럼 손목에 입장권 스트랩을 걸어준다. 이날 행사는 4개 트랙(프론트엔드:A, 서버: B, Data/ML: C, Platform: D)으로 구성되고, 처음 참가신청할 때 신청한 트랙에 맞춰 입장권을 발권해줬다. 원칙상으로는 처음 신청한 트랙에만 입장 및 계속 상주가 가능하고, 다른 트랙은 자리에 여유가 있는 경우에 한하여 입장권이 다르더라도 입장이 가능하다고 안내가 되어있다. 다만 자리가 어느정도 여유가 다 있어서인지 스태프들이 그렇게까지 일일이 신경쓰지는 않는 듯했고, 무엇보다도 뒤로 갈수록 (여느 테크 행사가 그렇듯) 점점 사람이 빠져 자리는 점점 여유로워졌다.

스트랩을 주면서 이렇게 기념품도 준다. 메모장, 볼펜과 같은 간단한 필기구들, (개발자 잇템인) 각종 스티커, 채용 팜플랫 등. 그리고 참가자 설문조사를 마치면 경품 추첨도 할 수 있었는데 나는 위의 Jetbrain 서비스 배지 몇종을 받았다. 누군가는 당근 키캡, 티셔츠 등도 받은 듯 하다. 힝.

그렇게 입장권을 받고 들어와서 처음 자리는 이쯤에 잡았다. 사이사이 돌아다니는 와중에 자리는 몇번 바뀌었다. 발목이 아파 그렇게 열심히 돌아다니지는 못했지만... 의자만 놓여져있는 배치이다보니 노트북 펼치고 뭔가를 보기에는 조금 불편했다. 사람들을 최대한 많이 앉히려면 어쩔 수 없어 보이기는 했다.

세션이 시작되기 전에 사진에서처럼 회사 브랜딩 영상을 쭉 틀어준다. 당근 회사에 대한 소개와 문화에 대해 알 수 있는 영상들인데, 아래 유튜브 재생 목록에서도 볼 수 있다. 아래 목록에 없는 영상들도 간혹 나왔다.

당근에서 함께 일하는 방법 🥕
https://www.youtube.com/playlist?list=PLuro_niZpqx4O7PLpwatlDdhtsAb5vY_Q

4.

발표 영상이 다 업로드된 상황에서 모든 발표를 다 기록할 필요는 없어보이고, 개인적으로 기억에 남고 복기해둘만한 영상들에 대한 것만 기록해본다.

4-1. 프레임워크부터 플랫폼까지: 당근 웹뷰 플랫폼

프론트엔드코어팀 리드의 발표였다. 사실상 FE 트랙의 기조연설과 같은 느낌의 발표였는데, 가장 기억에 남았고 또 생각해볼 거리가 많았다.

발표에도 언급되었듯이 당근 서비스의 Client에 대한 큰 그림을 조망하는 내용은 외부인 입장에서는 들어볼 기회가 좀처럼 없었기에 무척 흥미로운 발표였다. 게다가 나의 지금의 업무가 일반적인 웹 페이지 개발이 아닌 웹뷰 개발이었기에, 발표에서 언급된 큰 꼭지들의 내용들이 (그 정도의 차이가 있을지언정) 나와 우리 팀이 일하면서 가졌던 고민거리들과 상당 부분 겹친다는 것을 느꼈을 때 놀라움을 느꼈다. 한편으로는 우리 팀도 제법 적절하고 맞는 방향으로 나아가고 있다는 생각도 들었어서 뿌듯했고, 우리 팀이 만들고 있는 프로덕트에 새삼스럽게 자부심을 가지게 되는 의외의 계기가 되었다.

발표하시는 분이 발표 서두에, 보통 외부 발표는 FEConf에서만 지금까지 해왔는데, 이렇게 자체 컨퍼런스를 열어서 발표를 하게된 것이 뿌듯하다는 말씀을 하셨다. 참 멋있다고 생각했다. 어떤 단체의 이름을 내걸고 행사를 열어, 추첨을 해서 참가자를 선정해야 할 정도의 인파가 몰리고, 참석자들의 만족도도 대체적으로 높은 것을 경험한다는 건 어떤 기분일까? 여러 기술 집단의 운영에 참가해본 입장으로서 굉장한 자부심과 뿌듯함, 기쁨일 것이라 어렴풋이 상상해본다. 당근 내부에서도 지금의 위치까지 성장하기까지 부단한 노력과 여러 과정들이 있었을 것이기에 더 대단해보인다.

아무튼 감상은 이정도로 하고, 발표 주요 내용을 정리해봤다.

(일반적인) 웹뷰의 역할

• 각 웹뷰가 독립된 가상환경이 되어, 독립된 실행환경으로 기능 제공
• 각 웹뷰가 별도의 소스를 실행할 수 있어, 독립 배포가 가능해짐

이번 발표에서 소개하는 당근의 주요 웹뷰 컴포넌트는 아래 3가지이다.

• 브릿지: 기기와 통신하고 기기의 네이티브 기능을 사용하는 인터페이스
• 프레임워크: 미리 짜여진 큰 틀의 구조를 제공. ex. Next 등
• 플랫폼: 웹앱(HTML/CSS/JS)이 실행되는 기반 환경. ex. Vercel 등

브릿지

🥕 Daangn Metabridge
Repo 링크

당근 앱은 브릿지 컴포넌트를 내부 NPM 패키지로 분리해서 SDK 형태로 사용 및 관리한다. 기존의 Native 연동을 위해 사용해온 브릿지는 아래와 같은 Pain point가 있었다.

• 소통 비용이 너무 큼
• 이에 따라 개발 기간이 길어짐
• 히스토리 파악이 어려워 인수인계 어려움

이를 개선하고자, NPM SDK와 테스트 가능한 웹을 자동 배포하는 시스템을 마련했다. 브릿지의 명세를 JSON 형태로 작성하여 빌드하면, 이를 토대로 SDK가 자동 빌드되고 테스트 가능한 웹도 생성된다(웹이 자동 배포되는건 시간 관계인지 공개되지는 않았다).

테스트 웹을 사용하면 SDK의 동작을 독립적으로 확인할 수 있고, 새 API를 추가/수정하려면 JSON 스키마만 규칙에 맞춰 작성하기만 하면 된다. 굉장히 직관적인 프로세스가 확립되는 셈이며, 발표에서 언급되지는 않았지만 웹 / Native 개발자 모두가 명세를 직접 검토하고 기여할 수 있어 투명하고 신뢰성도 올라갈 것으로 기대된다.

프레임워크

🥕 Daangn Stackflow
공식 페이지 링크

당근은 화면을 그리는 데에 Stackflow를 자체 개발하여서 사용하고 있다. 초기에는 웹에서도 Native스러운 애니메이션과 동작을 모사하기 위한 UI 라이브러리였지만 최근에는 기능이 여러가지 덧대어지면서 프레임워크로서 기능을 확장하게 되었다.

여기에는 이 프레임워크가 처음부터 가져왔던 DX 철학이 반영되어있는데, "개발자가 웹 개발이 아닌 모바일 개발로 느끼도록"하는 것이다.

발표에서는 두 가지 측면의 기능에 대해 다루었다.

• UI Lifecycle: OS 별 분기 필요성과 모바일의 UX 특성에 부합하도록 로직 구현
• Routing: 모바일 어플리케이션의 특성에 부합하면서도, 웹의 기술(URL 기반)을 그대로 가져가면서 동작하는 라우팅 개념의 도입

React Native에서 제공하는 Stack Navigator와 유사한 컨셉이었다.

플랫폼

당근은(발표에서의 설명과 더불어 그 사전적 정의를 떠올려봤을 때 적절하다) 플랫폼을 아래의 개념을 기반으로 설게하고 있었다.

• 개발자가 제품을 만들고, 전달하는 방법을 정의 (버전 관리, 테스트와 QA, 실험)
• 유저가 제품을 만나는 초기 경험을 정의 (로딩의 빠름, 안정성)

발표에서는 위 2개 중 전자, DX 측면에 관련된 것을 중심으로 설명이 있었다. 당근은 아래와 같은 역사를 거쳐 배포 플랫폼을 운영해왔다.

• AWS S3 + Cloudfront
• Vercel
• Cloudflare Page
• Warp

최대한 자체개발하지 않고 외부 서비스에 의존하는 것을 전략으로 하였으나, 각 플랫폼 별 장점과 한계를 경험해본 끝에 자체적인 배포 플랫폼을 개발하기로 결정했다. 상용 서비스들이 제공했던 배포 관련 좋은 DX와 편의성을 제공하는 기능들을 최대한 가져가면서, 비용 효율성도 달성하는 것이 목표였고, AWS S3 + Cloudfront 기반으로 구축했다고 한다.

직관적이고 간편한 UI로, 유연하게 배포 및 버전 관리가 가능해보여서 부러웠다.

Native는 어디에?

(이 단락은 발표와는 직접적으로 무관한 이야기)

이런 저런 이야기들을 적다가, 인터넷을 찾아보니 당근에서의 Frontend 개발에 대해 엿볼 수 있는 몇 가지 아티클들이 있어 첨부한다.

• 당근마켓에 웹 프로젝트 배포하기
• (후기)당근마켓 프론트 개발자 채용 세션

문득 들었던 의문. 앞서 FE리드가 설명하셨듯 당근에서 Web FE 개발은 "개발자가 웹 개발이 아닌 모바일 개발로 느끼도록" 하는 철학 아래에서 진행될 수 있도록 여러 환경을 제공하고 있다.

이런 방향성을 가지게 된 사정이 무엇이었을까? 원래 Native 기반이었던 서비스의 대부분을 Web으로 이전한다는 것은 아주 큰 의사결정이다. 내부 개발팀의 주요 기술 스택이 Web이 된다는 의미로 해석된다. 게다가 오늘 밋업에는 모바일 트랙이 아예 없었다. 오늘 세션들을 종합해보면 어렴풋이 막연하게 짐작가는 부분이 있지만, 그래도 그 결정의 근거들은 궁금해진다.

채용에는 여전히 iOS/Android도 있긴 하던데...

4-2. 프론트엔드에게 배포플랫폼이란

앞서 발표에서 언급된 당근의 배포 플랫폼을 개발하는 분이 공유해주신 발표다. 실제 배포 플랫폼을 개발하고 트러블슈팅하는 입장이실테니, 배포와 컨텐츠 딜리버리에 대하여 생생한 내용을 전달해주셨으리라 생각한다.

개발을 배우는 초기 시절에 봤으면 정말 도움이 크게 되었을 영상이다. 우리가 브라우저에서 보는 웹 페이지의 본질이 무엇인지, 서빙까지 어떤 과정을 거치고 그 과정들이 구체적으로 어떻게 벌어지는지, 이를 바탕으로 Web Frontend가 어떻게 발전해왔는지 등을 압축적이지만 어렵지 않은 깊이로 들을 수 있다.

FE를 공부하면 처음에는 웹 페이지 구현에 관련된 코드 관련 내용에 많은 비용을 할애하기 마련인데, 웹 개발에는 그 외에도 참 다양한 구성 요소에 대한 지식들이 필요하다. 그렇다고 Backend 수준에서 필요한 기술을 다 아우르는 것은 무리가 있다. 영상에서 언급된 각각의 주제 꼭지들을 각기 자세하게 공부해보는 것으로도 큰 도움이 될 듯 하다. 주니어 끝자락인 나도 내용 정리하고 곱씹어보기에 좋았다.

4-3. 아니, 여기도 웹뷰였어요?

당근 동네생활 팀에서 맡은 서비스들을 전부 웹뷰로 전환하는 여정을 설명한 발표였다. 다양한 이야기가 나왔지만, 개인적으로는 웹뷰를 만드는 데에 사용한 SSR 기술에 대한 내용이 가장 기억에 남는 발표였다. SSR을 본격적으로 다루고 특히 React에서의 최신 SSR 기술들(Suspense, React Server Component), 통칭 Streaming SSR에 대한 따끈따끈한 사례를 들어볼 수 있는 발표였다.

앞서 기조 연설과 비슷한 느낌을 받았는데, 우리 팀에서도 웹뷰 기반의 서비스를 만들고 있고 또 SSR로 서비스를 제공하고 있기에 여러 가지 공감가는 내용과 고민이 많았다.

• TTFB(Time to First Byte)와 FCP(First Contentful Paint) 최소화에 있어 CSR과 SSR 사이의 고민점
• 배포 직후 SSR 서버의 라우팅 이슈
• 배포 직후의 Bundle Chunk 갱신 이슈
• Bundle 불일치에 따른 새로고침 이슈
• 사용자에 대한 앱의 업데이트 유도 전략
• ...

게다가 (SPA를 개발하는 입장에서 당연한 이야기지만) 사용자가 가지는 네트워크 및 디바이스 환경의 다양성에서 기인한 여러 이슈를 고려하면서 SSR을 도입해야 했기에, 당근과 같은 일반적인 형태의 모바일 앱을 개발할 때는 훨씬 더 챙길 부분이 많을 것이다. SSR 웹뷰로 서비드를 전환해나가며 겪은 생생한 경험들을 함께 들을 수 있어 귀중한 발표였다. 특히 별로 어렵지 않은 용어들로, 친절하면서도 과하지 않은 정도의 설명을 잘 첨가하여 발표를 해주셔서 초심자가 큰 그림을 그리기에도 매우 좋을 듯하다.

본래 Native 이었던 서비스를 웹뷰 기반으로 전면 전환

발표자가 소속된 팀은 동네생활 탭에서 제공하는 다양한 서비스를 개발하고 있는데, 본래 그 안의 기능들은 전부 Native였다. 2023년 초 정도를 시작으로 이들을 웹뷰로 전환하기 위한 작업을 시작했는데, 발표에서 언급된 이유는 다양한 실험을 공격적으로 하기에는 웹이 더 적합하기 때문이었다. (그게 전부였다)

발표자가 그 이후에 덧붙인 설명들을 곱씹어볼 때, 웹 기반 서비스가 가지는 배포의 유연함을 바탕으로 다양한 실험을 공격적으로 하고자 함 이었으리라 추측해본다. 다양한 신규 서비스들, 더 세부적으로는 다양한 기능과 디자인을 A/B 테스트해보고 지표로 확인할 수 있으려면 빠른 배포 운영이 가능한 환경이 필요했을 것이다. 순수 Native로만 서비스를 구현한다면 배포 자체가 큰 비용이 될 수 밖에 없으니.

앞서 언급했듯 Warp를 자체 개발하는 것도 그렇고, 이래저래 배포 운영에 큰 우선순위를 부여하고 리소스를 투입한다는 것을 느낄 수 있었다.

Native에 준하는 성능을 만들어내기

웹뷰로 전환하더라도 기존 Native에 준하는 성능을 낼 수 있어야했고, 발표자가 속한 팀에서는 웹뷰를 깎아야만 했다. 그렇다보니 자연스럽게 일반적인 CSR이 아닌 SSR 도입을 고려했다.

기존 CSR 웹은 아래의 문제가 있다.

• 신규 배포 직후 번들 업데이트에 따른 네트워크 비용 발생 → FCP까지 지연 발생(흰 화면)
  • 특히 CDN 서비스를 이용할 경우, 해외 Region에 요청하는 경우가 간혹 있음
  • 적절하게 CDN 기능을 사용하면 문제가 해소되지만 완벽하지는 못함
• 번들 로드 후 API 요청시, CORS 요청인 경우 preflight 비용이 큼 (2~300ms 수준). 특히 API가 많아질수록 이슈가 심해짐

결국 네트워크 환경에 의존적인데, 사용자마다 네트워크 환경이 제각각이므로 사용자 경험을 일관성있게 관리할 수 없다. 그래서 SSR을 검토하였지만, 전통적인 SSR 또한 아래와 같은 한계가 있다.

• 요청된 URL의 화면을 완성해야 응답을 주므로, 여전히 네트워크 비용에 의존적
  • 그래서 Streaming SSR(Suspense + RSC)를 적극 도입
• SSR의 사용 방안을 결정해야 한다. 유명 메타 프레임워크를 사용하거나, 직접 SSR 서버를 구현해야 함
  • 당근은 Next.js나 Remix 등을 사용하지 않고 직접 SSR 기능을 구현
  • Vercel에 대한 의존성을 회피하고, 자사 인프라(Warp?) 연동이 용이하도록 직접 구현했다고 한다.
• CSR과 달리 SSR을 위한 서버가 필요하며, 해당 서버의 운영과 모니터링 책임이 발생한다. (새로운 업무)

특히 Web Frontend 도메인의 개발자에게 서버 관리와 모니터링이라는 업무가 부여되는 것은 상당한 부담이라는 솔직한 의견이 인상적이었다. 업무가 새로 생기는 건 물론 부담스럽지만, 업무 도메인이 넓어지는 것은 그 나름의 긍정적인 측면이 있다고 생각한다.

cf) CSR과 SSR, Streaming SSR에 대한 또 좋은 영상

다른 프레임워크는?

(이 단락은 발표와는 직접적으로 무관한 이야기)

나는 한동안 React는 손 놓고 있었기에, 발표에서 언급된 Streaming SSR, React Server Component에 대해 자연스럽게 관심이 갔다. 사실, Streaming SSR이라는 개념 자체는 그다지 새롭지 않다.

• 2018년 초(16.3): React Suspense가 처음 도입
• 2022년 초(18.0): Concurrent Mode 도입
• 2022년 중순(18.2): 실험 기능으로 React Server Component가 처음 소개
• 2024년 12월(19.0): 정식 기능으로 출시

이미 많은 테크 블로그 등에서 Streaming SSR과 관련된 React 기능들을 다뤄왔을 정도로 널리 알려진 개념이고, 얼리어답터 FE 개발자들 사이에서는 UX를 좀 더 개선해줄 놀라운 기능으로 언급되어왔다.

다만 이 Streaming SSR이라는 동작의 컨셉에 대해서는 프레임워크나 라이브러리 별로 약간의 관점 차이가 있었지 않나 싶다. 가령 Nuxt의 경우, SSR은 화면이 모두 준비되어야(Fully rendered HTML) 데이터를 내려보내는 방식이 기본 동작이다(링크). 2019년 정도부터 SSR을 개선하기 위한 방안으로서 Streaming 방식이 다양하게 논의되어왔지만, 코어 개발팀에서는 이 방식의 한계에 좀 더 주목했던 듯 하다. 현재까지도 Streaming SSR은 지원하지 않는다.

cf) https://github.com/nuxt/nuxt/issues/9210

물론 이는 예전 이야기이고, 무려 5년 정도의 시간이 지난 지금 시점에서는 Streaming SSR 방식을 도입하기 위한 검토가 진행되고 있는 것으로 보인다(링크). Streaming 방식에도 명확한 장점이 있거니와, 프레임워크 사용자가 필요에 따라 선택 가능해야 하는 문제이고, 무엇보다도 가장 큰 경쟁 라이브러리가 지원하는 것을 마냥 두고만 볼 수는 없지 않을까 싶다.

cf)

• https://github.com/nuxt/nuxt/issues/4753
• https://github.com/nuxt/nuxt/issues/9210
• https://github.com/nuxt/nuxt/discussions/16119
• https://github.com/nuxt/nuxt/discussions/20560
• https://github.com/nuxt/nuxt/discussions/30121
• https://roe.dev/blog/nuxt-server-components/

마무리

운좋게 가게된 행사인데, 알차고 재미있고 또 배운 점도 많았던 행사여서 좋은 경험이었다. 내년에도 또 당근에서 기술 관련 행사를 열게 되기를 바라며...