2024 당근 테크 밋업 후기(Frontend)

 

2024 당근 테크 밋업에 다녀왔다. 

10/7(월) 코엑스에서 열렸다. 나는 운 좋게 Frontend 세션에 당첨되어 참석하게 되었다.

당근 엔지니어분들의 개발 지식과 현업에서 맞닥뜨린 고민과 해결과정을 알게 되어 뜻깊은 시간이었다.

 

목차

1. 밋업 현장 사진 & 기념품
2. 시간표
3. 세션 요약 및 느낀 점
4. 종합 느낀 점

 

1. 밋업 현장 사진 & 기념품

나는 Frontend 세션에 참여했다. Frontend 외 Server, Data/ML, Platform 세션이 함께 열렸다.

 

많은 개발자 분들이 밋업에 참가하셨다. 다른 회사 개발자분들을 보니 여러 생각이 들었다. IT업에 열정적인 사람이 많다는 생각을 했고, 다들 뭔가 느낌이 비슷해서 역시 개발자다 싶었다ㅎㅎ

 

 

노트, 펜, 안경닦이, 스티커를 기념품으로 받았다. 설문 후 럭키드로우 했는데 JetBrains 에코백을 받았다.

 

2. Frontend 세션 시간표

출처: 2024 당근 테크 밋업

 

3. Frontend 세션 요약 및 느낀 점

✔프레임워크부터 플랫폼까지: 당근 웹뷰 플랫폼

당근 프론트엔드 코어 리드하시는 원지혁 님께서 발표해 주셨다.

프론트엔드코어팀은 다른 프론트엔드 개발자들의 생산성 향상을 돕는 패키지를 새롭게 만드는 팀이다. 중복코드를 줄이는 NPM 패키지부터, 배포 플랫폼까지 프론트엔드 개발자를 위한 도구를 만드는 역할을 한다.

프론트엔드 팀별로 각자 개발에 필요한 도구를 관리한다고 생각했는데 프론트엔드 코어팀의 개념은 신선했다.   

프론트엔드 코어팀이 있으면 프론트엔드 개발자들은 비즈니스 로직 구현에만 집중할 수 있고 보다 빠르고 더 개선된 서비스를 구축할 수 있겠다고 생각했다.

 

당근은 배포 플랫폼을 아래처럼 정의한다.

• 개발자가 제품을 만들고 전달하는 방법을 정의합니다
  • 버전 관리, 테스트/QA, 실험
• 유저가 제품을 만나는 초기 경험을 정의합니다
  • 빠른 로딩, 안정적인 로딩

개발자 측에서 정의는 배포 전 테스트부터 안정적인 배포를 위한 버전관리를 의미합니다.

유저 측 정의는 CDN과 에지 컴퓨팅을 통한 빠른 로딩, 신뢰할 수 있는 서버에 배포하여 안정적인 로딩을 의미합니다. 

 

가장 기억에 남는 내용은 당근 자체 구축 배포 플랫폼인 'Warp(워프)'였다.

Warp의 특징은 아래와 같다.

• AWS S3와 CloudFront를 활용해 자체적으로 구축
• 버전 관리, 배포, 프리뷰 배포, 롤백 등 기존 생태계의 기능들을 지원
• 배포 플랫폼의 역할을 확장해 당근의 프론트엔드 정책을 관리할 수 있도록 설계
• 다양한 워크플로우에서 확장해서 사용할 수 있도록 유연한 구조로 설계

당근은 왜 Vercel이나 Cloudflare처럼 세계적으로 인정받는 서비스를 두고 자체 제작 배포 플랫폼을 구축하고 있는지 궁금했다. 아래 3가지 방안을 고려했으나 적합한 도구가 없어 Warp를 구축했다고 했다.

• AWS S3 + CloudFront: 스토리지에 정적 파일 업로드하는 웹서버 기능, 배포와 버전 관리 등 생산성 기능 별도 CI로 직접 구축해야 함
• Vercel: 자동 배포, 버전 관리 등 생산성 기능 자체 제공. 트래픽 당 과금 정책으로 비용이 많이 발생.
• Cloudflare Pages: Vercel의 대부분의 생산성 기능 제공. 트래픽 많아도 비용 증가 하지 않음. 하지만 간헐적 다른 국가의 Edge로 라우팅 되는 이슈(예: 리전이 미국으로 잡혀 로딩하는데 10초 이상 소요)

 

✔프론트엔드에게 배포플랫폼이란 - nothing or everything

프론트엔드 코어팀의 안현석 님께서 발표해 주셨다.

발표의 주제인 '프론트엔드 배포 플랫폼은 nothing or everything(아무것도 아닐 수도 있고 모든 것일 수도 있다.)'가 인상깊다. 프론트엔드 배포를 위해 당연하게 여기는 과정들이 아무것도 아닐 수 있게 보일 수 있지만, 기술적 발전을 통해 사용자 경험을 향상시킨다면 모든 것이 될 수도 있다는 의미이다.

지금까지 웹사이트의 기술적 발전의 예시는 아래와 같다.

• 초기 웹개발에서는 정적인 웹사이트 위주였다.
• 개인화된 정보를 제공해 주기 위해 동적인 웹사이트가 등장했다.
• 화면 일부를 수정하기 위해 불필요하게 전체 웹사이트를 새로고침해야 했던 문제를 해결하기 위해 비동기 Ajax가 등장했다.
• 보다 빠른 사용자 경험을 위해 SPA가 등장했다.

 앞으로 웹이 나아갈 기술들은 아래와 같다.

• http/3 (QUIC) 프로토콜
• 신규 browser API
• 모듈 시스템
• 번들러
• edge 네트워크

 

CDN을 활용한다면 SPA 배포 플랫폼을 더 발전시킬 수 있다. index.html과 js파일들을 CDN을 통해 캐싱하는 것이다. http헤더를 통해 캐시정책을 정할 수 있다. 

출처: 2024 당근 테크 밋업 발표자료(안현석님의 프론트엔드에게 배포플랫폼이란 - nothing or everything 세션)

 

새로 배포하게 된다면 캐싱 초기화를 위해 CDN의 purge를 사용하면 된다.

출처: 2024 당근 테크 밋업 발표자료(안현석님의 프론트엔드에게 배포플랫폼이란 - nothing or everything 세션)

 

✔아니, 여기도 웹뷰였어요?

당근 동네생활 팀의 김태희 님께서 발표해 주셨다.

동네생활의 모든 서비스는 네이티브 기반이었지만 현재 많은 서비스를 웹뷰로 전환했다.

웹뷰로 전환하게 된 이유는 아래와 같다.

• 빠른 개발 주기 및 배포
• 테스트를 통해 좀 더 많은 실험
• 이를 통해 사용자 가치 상승
• 거의 대부분의 경우 웹뷰로도 충분한 성능과 사용자 경험 줄 수 있음

동네생활 팀에서 웹뷰로 전환하며 부딪혔던 가장 큰 이슈는 '느리지 않게 구현하기'라고 했다. 웹뷰는 기본적으로 렌더링 하기 때문에 네이티브 보다 느릴 수밖에 없다.

이를 해결하기 위해 'Streaming SSR'을 도입했다. 'Streaming SSR'을 도입하게 된 이유는 CSR과 SSR의 장단점에 알아야 한다.

출처: 2024 당근 테크 밋업 발표자료(김태희님의 아니, 여기도 웹뷰였어요? 세션)

출처: 2024 당근 테크 밋업 발표자료(김태희님의 아니, 여기도 웹뷰였어요? 세션)

 

CSR

• 브라우저에서 API 직접 호출
  • JS가 로딩된 이후에 실행되기에 생각보다 API 요청 시점이 느릴 수 있음.
  • 사용자의 네트워크 상황에 따라 API 요청, 응답 자체가 느릴 수 있음(예: 엘리베이터 안, 지하)
• 별도의 Application Server 없이 브라우저에서 직접 API Server에 API요청하기 때문에, cross domain 환경
  • 이때 발생하는 CORS 관련 preflight요청이 100~200ms 정도의 지연 일으킴.

출처: 2024 당근 테크 밋업 발표자료(김태희님의 아니, 여기도 웹뷰였어요? 세션)

 

SSR

• 장점
  • API를 브라우저에서 호출하지 않고 서버에서 호출하기 때문에, 상대적으로 사용자의 네트워크 환경에 영향이 적다.
• 단점
  • CSR에서는 호출하는 API 중 하나가 느리더라도, UI를 사용자에게 먼저 노출하고 로딩 중 표시 등을 통해 사용자에게 아직 처리 중임을 인지시킬 수 있음.
  • SSR에서는 모든 API 응답이 끝나야 화면을 보여줄 수 있어서 API속도가 느리다면 CSR 대비해서 오히려 화면이 늦게 뜰 수 있음

 

Streaming SSR

• 화면을 한 번에 그리지 않고 나눠서 그리는 방식.
• API 호출과 관련 없는 부분은 가장 빠르게 그림.
• API 호출과 같이 외부요인으로 지연될 수 있는 곳들은 나중에 그림.

 

Suspense와 Shell

• Suspense는 React의 비동기 렌더링을 지원하는 컴포넌트이다. 데이터가 준비되지 않았을 때 로딩 상태를 보여주고, 데이터가 준비되면 컴포넌트를 렌더링 하는 역할을 한다
• Shell은 <Suspense> 경계 밖에 있는 부분. 나머지 콘텐츠가 비동기적으로 로드되기를 기다리면서 사용자에게 빠르게 보여주는 역할. Shell이 준비되면 onShellReady 콜백이 실행되고, 여기서 pipe 함수를 호출함으로써 스트리밍이 시작됨.

Suspense 구현 코드

// 적용 전
function ProfilePage() {
  return (
    <ProfileLayout>
      <ProfileCover />
      <Sidebar>
        <Friends />
        <Photos />
      </Sidebar>
      <Posts />
    </ProfileLayout>
  );
}

// 코드 출처: https://ko.react.dev/reference/react-dom/server/renderToPipeableStream#reference

// 적용 후
function ProfilePage() {
  return (
    <ProfileLayout>
      <ProfileCover />
      <Sidebar>
        <Friends />
        <Photos />
      </Sidebar>
      <Suspense fallback={<PostsGlimmer />}> // Suspense
        <Posts />
      </Suspense> // Suspense
    </ProfileLayout>
  );
}

// 코드 출처: https://ko.react.dev/reference/react-dom/server/renderToPipeableStream#reference

const { pipe } = renderToPipeableStream(<App />, {
  onShellReady() {
    response.statusCode = didError ? 500 : 200;
    response.setHeader('content-type', 'text/html');
    pipe(response); // pipe: streaming 시작
  },
  onShellError(error) {
    response.statusCode = 500;
    response.setHeader('content-type', 'text/html');
    response.send('<h1>Something went wrong</h1>'); 
  },
  onError(error) {
    console.error(error);
  }
});

// 코드 출처: https://ko.react.dev/reference/react-dom/server/renderToPipeableStream#reference

 

 

SSR과 Streamin SSR의 동작 차이

출처: https://mxstbr.com/thoughts/streaming-ssr

 

 

웹뷰 전환 이후 문제점

• iOS 키보드 문제. 완벽한 해결책이 없고 해결했다 하더라도 사파리 버전이 올라간다면 언제 막힐지 모름.
• CSR에서 SSR로 전환하며 서버 모니터링 업무 추가됨.
  • 로그 확인, 트래픽에 따라 Server 스펙 충분한지, 병목 현상은 없는지 등을 확인해야 함.
  • CSR의 경우에 클라이언트에서 다른 팀에서 개발한 API를 호출하면 되기에 서버 모니터링할 확률이 적음.

 

우리 팀에 적용 방향

• Streaming SSR이 적합하다고 판단된다.
• 공통된 영역(상단 내비게이션바, 하단 푸터 등)과 상품리스트, 검색옵션 영역은 제일 처음에 그린다. 그 이유는 네비게이션바, 상품리스트, 검색옵션은 필수정보이기에 완성된 상태로 사용자에게 노출되어야 사용자가 불편함을 느끼지 않을 것이다.
• 그 외 광고 영역, 우측 큐레이션 영역 등과 같은 추가적인 호출은 완료되는 대로 그린다. 광고 API는 외부 서비스에서 제공해 주기에 지연이 발생할 가능성이 크기 때문이다. 우측 큐레이션 영역은 중요도가 비교적 낮은 정보이다.
• 우리 팀 서비스에서는 PHP와 Ajax를 활용하여 Streaming SSR과 비슷하게 동작하고 있다. 기술적으로 완전히 다르지만 구현하고자 하는 목적은 비슷하다. 하지만 우리 팀은 SSR은 PHP, 추가 화면 구성을 위한 비동기 요청은 JS코드단에서 Ajax로 호출되고 있어 UI 구성 코드가 파편화되어 있다. 따라서 컴포넌트 관리가 어렵다.
• 앞으로 React, Next.js로 전환한 뒤 Streamin SSR을 방식을 채택한다면 사용자 경험이 향상될 뿐 아니라 컴포넌트 관리가 편해져 개발 생산성이 상승할 것이다.

 

4. 종합 느낀 점 및 정리

• 당근 엔지니어들의 기술적인 도전과 이슈 해결 과정을 들으며 인사이트를 얻을 수 있었다. 앞으로 우리 팀 서비스를 react, next.js로 전환할 때 도움이 될 정보를 많이 얻게 되었다.
• 당근 엔지니어들의 개발 방식에서 배울 점이 많았다. 몇몇은 내가 소홀히 했던 내용이 있어 반성하게 되었다. 업무를 하며 직접 적용할 것이고, 동료 개발자들에게도 알려주어 멋진 개발 환경을 만들어가고 싶다.
  • 당근은 신규 기술 도입/전환 시에 기술 도입 시 장단점, 도입 근거, 가설 검증을 명확히 정리하며 진행한다. 이로 인해 보다 합리적인 의사결정이 가능하다.
  • 당근은 향상된 사용자 경험과 성능 최적화를 위해 다양한 관점에서 고민하며 실행으로 옮긴다. 웹뷰 전환, Streaming SSR, CDN 적용 등이 있다.
  • 당근은 디테일한 요소도 놓치지 않고 개선하기 위해 노력한다. 한 예로 플랫폼 별로 뒤로 가기 버튼에서 사용자가 기대하는 동작이 다르기 때문에  UI, 히스토리 관리를 별도로 하고 있다.
  • 당근은 생산성을 높이기 위해 노력한다. 프론트엔드 코어팀을 두어 프론트엔드 개발자들이 비즈니스 개발에만 몰입할 수 있는 환경을 만든다. 
  • 당근 직원들은 긍정적이며 친절하다. 하루동안 인상이지만 발표자, 안내요원 모두 상냥하셨다.

 

2024 당근 테크 밋업: https://tech-meetup.daangn.com/

2024 당근 테크 밋업