7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기

FEConf2024년 10월 15일About 3 min

7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기 관련

7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기 (1)

토스 코어에는 86명의 FE 개발자들이 함께 있고 250개의 서비스를 운영하고 있습니다. 제가 속한 플랫폼 팀에서는 86명의 FE 개발자가 사용하는 모노리포를 관리하며 250개 서비스의 배포부터 모니터링까지 같이 관리하고 있습니다. 이런 인프라 관리를 좀 더 쉽게 하기 위해서 IaC를 통해 형상 관리를 자동화하고 있고, 다양한 개발자들이 기여할 수 있는 환경을 만들기 위해 노력하고 있습니다. 토스 코어 팀의 프론트엔드 개발자들이 이러한 다양한 업무들에 집중하는 목적이 무엇일까요? 가장 큰 목적은 토스의 프론트엔드 UX/DX를 세계 최강으로 만들기 위함입니다. 토스의 프론트엔드 플랫폼이 세계 최강의 프론트엔드가 되기 위해 어떤 노력을 하고 있는지 하나씩 살펴보겠습니다.

FEConf2024^[1]에서 발표한 <7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기>를 정리한 글입니다. 발표 내용을 2회로 나누어 발행합니다. 1회에서는 프론트엔드의 라이프 사이클에 대해 간단히 알아보고 4가지 버프 방법에 대해 알아보겠습니다. 2회에서는 나머지 3가지 버프에 대해 알아보고, 시행착오로 배운 것들에 대해 알아봅니다. 본문에 삽입된 이미지의 출처는 모두 이 콘텐츠와 같은 제목의 발표 자료로, 따로 출처를 표기하지 않았습니다.

안녕하세요. 저는 토스 코어 FE 플랫폼 팀에서 Frontend Ops 유닛을 리딩하고 있는 정석호라고 합니다. 오늘은 ‘7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기'에 대해 설명해 보려고 합니다. 저는 특히 프론트엔드와 인프라에 관심이 많아서 이와 관련된 작업들을 주도적으로 하고 있습니다. 최근에는 프론트엔드 서비스의 안정성을 위해 좋은 환경을 가꾸는 것에 집중하고 있습니다.

이번 글에서 다루는 것들은 아래와 같습니다. 구체적인 코드 조각이나 구현 방법은 다루지 않으니 참고해 주세요.

풀고자 했던 문제들
아이디어와 임팩트
겪었던 시행착오와 운영 이슈

토스 코어의 프론트엔드

토스 코어에는 86명의 FE 개발자들이 함께 있고 250개의 서비스를 운영하고 있습니다. 제가 속한 플랫폼 팀에서는 86명의 FE 개발자가 사용하는 모노리포를 관리하고 있고 하루 평균 머지 리퀘스트 요청은 50개 정도 됩니다. 또한 250개의 서비스의 배포부터 모니터링까지 같이 관리하고 있습니다.

또, 사내에서 사용하는 공통 라이브러리는 약 220개 정도입니다. 이런 인프라 관리를 좀 더 쉽게 하기 위해서 IaC를 통해 형상 관리를 자동화하고 있고, 다양한 개발자들이 기여할 수 있는 환경을 만들기 위해 노력하고 있습니다.

토스 코어 팀의 프론트엔드 개발자들이 이러한 다양한 업무들에 집중하는 목적이 무엇일까요?

가장 큰 목적은 토스의 프론트엔드 UX/DX를 세계 최강으로 만들기 위함입니다. 토스의 프론트엔드 플랫폼이 세계 최강의 프론트엔드가 되기 위해 어떤 노력을 하고 있는지 하나씩 살펴보겠습니다.

프론트엔드 서비스 라이프 사이클

이러한 노력을 알아보기 전에 아래 그림을 통해 프론트엔드 서비스가 어떻게 만들어지고 유저에게 어떻게 전달되는지 알아보겠습니다.

먼저 토스 코어의 UX 팀이 디자인 시스템을 만들어 주고, 디자이너 분들이 디자인 툴을 활용해 디자인을 합니다. FE 개발자들은 이를 기반으로 소스 코드를 작성하고 웹서비스를 배포합니다. 이렇게 배포된 서비스는 네이티브 앱안에 있는 웹뷰를 통해 사용자에게 제공됩니다.

그럼 토스 코어에서 세계 최강의 프론트엔드 플랫폼을 만들기 위해 어떤 노력을 하고 있을까요? 위 그림에서 파란색으로 칠한 부분이 바로 이번 글의 주제이자 토스 코어의 7가지 마법입니다. 이제부터 7가지 마법에 대해 하나씩 알아보겠습니다.

이미지 최적화 마법

Next.js 이미지 컴포넌트

첫 번째 주제는 이미지 최적화 마법입니다. Next.js를 활용해 개발해 보신 분이라면 Next.js의 이미지 컴포넌트를 사용해 봤을거라 생각됩니다. Next.js의 이미지 컴포넌트는 아래와 같은 특징을 가지고 있습니다.

기기에 적절한 디바이스 별 사이즈로 자동 변환
이미지 로딩 시 Layout Shift 방지
고해상도 이미지를 저 해상도로 우선 표시(Blur-up)
외부 이미지 사용 가능(e.g. CDN)

3년 전 토스를 돌아보면, 대부분의 서비스가 Next.js의 SSG(Static Site Generation)를 통해 만들어진 CSR(Client Side Rendering) 서비스였습니다. 하지만 Next.js의 이미지 컴포넌트는 SSR 서버의 온디맨드 기능이기 때문에 SSG로 만들어진 페이지에서는 사용이 불가능하다는 아쉬움이 있었습니다.

즉, Next.js의 이미지 옵티마이제이션 디폴트 로더는 오직 Next.js에서만 사용할 수 있고, Next.js에서도 SSG나 CSR에서는 사용할 수 없습니다.

Next.js 이미지 컴포넌트 사용 문제 해결하기

토스 팀에서는 Next.js의 디폴트 로더를 사용하지 않고 Next.js와 독립된 이미지 최적화 API를 이용해 앞서 말한 것을 해결해 보고자 했습니다.

가장 쉽게 접근할 수 있는 방법은 AWS의 Lambda@Edge를 사용하는 것입니다. 앞단에는 CDN을 배치하고 뒷단에는 이미지 최적화 로직을 수행하는 람다를 배치하여 서비스에 이를 사용할 수 있게 구성했습니다. 하지만 람다를 운영하면서 각종 시행착오를 겪었습니다.

서비스를 이중화하기 위해서는 다른 제공 업체의 서버리스 펑션 서비스를 사용해야 하는 경우도 발생하고, 기존 소스코드가 오래되었다면 Node.js의 버전을 강제로 업데이트해야 배포할 수 있는 리스크도 존재했습니다. 뿐만 아니라 트래픽이 갑자기 몰리게 되면 람다 서비스 비용이 기하급수적으로 커질 수도 있었습니다.

저는 이러한 문제를 이미 토스 서버 플랫폼에서 잘 해결해나가고 있다고 생각했습니다. 그래서 이미 잘 만들어진 토스 서버 플랫폼 인프라에 서버를 띄워보고 싶다는 생각을 했습니다. 이렇게 하면 DC1 / DC2 이중화 및 점진적인 배포도 지원이 되고, 그라파나를 통한 서버 지표 모니터링은 물론 실시간 로깅도 가능합니다.

이 시도를 통해 안정적으로 IDC 인프라를 사용하여 앞서 말한 장점들을 모두 얻을 수 있었습니다. 다시 말해 이미지 최적화 마법을 통해 모든 환경에서 이미지 최적화를 사용할 수 있게 되었습니다. 현재는 250개의 서비스에서 최적화된 이미지를 사용할 수 있게 되었습니다. SSR은 물론 SSG 및 CSR, 그리고 Next.js가 아닌 환경에서도 이미지 최적화 마법을 사용 중입니다.

비디오 썸네일 마법

Video 태그의 썸네일 속성

다음으로 비디오 썸네일 마법에 대해 알아보겠습니다. video 태그를 사용할 때 아래와 같이 poster 속성을 사용하여 비디오가 로딩될 때 보여줄 썸네일 이미지를 설정할 수 있습니다.

이 속성을 사용하여 썸네일을 설정하려면 영상을 만들고 이미지를 뽑아낸 다음, 이미지를 업로드하는 작업이 필요합니다. 다시 말해 실제로 업로드된 주소를 기준으로 poster 속성에 주소를 적고 실제 서비스 배포를 해야 합니다. 이런 작업은 생산성을 떨어뜨리고 꽤나 귀찮은 작업일 수 있습니다.

썸네일 속성 설정을 위한 문제 해결하기

위와 같이 poster 속성 설정을 위한 비효율적인 작업 문제를 해결하기 위한 방법은 어떤 것이 있을까요? 썸네일 이미지를 실시간으로 생성해 주는 서버를 생각해 봤습니다. 아래 그림과 같이 원하는 특정 시간과 함께 비디오 주소를 넣으면 해당 시간에 맞는 프레임을 동적으로 생성해 주는 서버입니다.

이 아이디어를 통해 비효율적인 작업 없이 동영상을 업로드함과 동시에 썸네일을 사용할 수 있게 해결할 수 있습니다. 썸네일을 바꾸고 싶을 때도 썸네일 이미지 업로드 과정 없이 시간 파라미터만 바꾸면 썸네일이 교체되도록 할 수 있습니다.

동영상에서 썸네일 이미지를 캡쳐하여 서버에 업로드하고, 업로드된 이미지를 poster 속성에 매번 지정해야 하는 비효율적인 문제를 해결할 수 있는 두 번째 마법이었습니다.

폴리필 마법

세 번째로 소개드릴 마법은 폴리필 마법입니다. 인터넷 환경에는 다양한 브라우저들이 존재하고, 특정 브라우저에서는 지원되지 않는 구현체들도 간혹 존재합니다. 대표적으로 인터넷 익스플로러 11에서는 Promise 객체를 지원하지 않습니다. 이러한 문제를 어떻게 해결할 수 있을까요?

폴리필 사용

대표적인 방법은 폴리필을 이용하는 것입니다. 폴리필이란, 아래와 같이 빈 구현체를 채워주는 스크립트라고 이해할 수 있습니다.

폴리필을 가장 쉽게 사용하려면 바벨을 사용하면 됩니다. @babel/preset-env라는 라이브러리를 사용하여 아래와 같이 인터넷 익스플로러 11을 기준으로 최소 지원 브라우저를 설정하여 구현체를 채울 수 있습니다.

폴리필의 문제점과 해결 방안

하지만 이 방법을 최신 브라우저에서 쓰면 단점이 존재합니다. 최신 브라우저에서는 이미 지원하는 구현체들을 내려받게 되어 사용자, 서비스 제공자, CDN 모두에게 불필요한 네트워크 비용이 발생하게 됩니다.

이러한 문제를 해결할 수 있는 방법인 폴리필 서버에 대해 알아보겠습니다. 폴리필 서버에서는 유저 에이전트의 정보를 읽고 해당 유저의 브라우저에 어떤 폴리필 구현체가 필요한지 체크하여 필요한 구현체만 전송하는 작업을 수행합니다.

이런 아이디어는 저희뿐 아니라 다양한 클라우드 서비스에도 존재합니다. 대표적으로 polyfill.io라는 서비스가 있습니다. 하지만 몇 달 전에 어떤 기업에 인수되고 나서 보안 안정성 문제가 발생했고, 해당 서비스를 이용한 트위터 등에서 화면이 제대로 보여지지 않는 문제가 발생했습니다. polyfill.io의 사이트도 접근 불가능한 사이트가 되어버렸습니다.

토스에서는 애초부터 다른 서비스의 불확실한 안정성에 우리 서비스를 맡기고 싶지 않았습니다. 조금 더 독립적이고 외부에 의존하지 않는 안정적인 서비스를 운영하고 싶었고, 자체적인 서비스를 구현하게 되었습니다.

어떤 방법으로 구현되었는지 살펴볼까요? 위 그림을 보면 오리지널 람다를 바라보고 있는 CDN을 통해서 구현된 것을 알 수 있습니다. 람다에서 유저 에이전트 헤더를 사용해서 파라미터를 받았고, 그 유저 에이전트 헤더를 파싱해서 어떤 구현체를 포함할지 확인하고, CDN을 통해 자바스크립트 번들을 브라우저에게 전달해줍니다.

이런 폴리필 마법으로 인해 인터넷 익스플로러에서는 732 KB의 번들을 내려받는 반면 크롬이나 사파리에서는 거의 빈 함수만 내려받는 정도의 수준으로 가벼운 번들만 전송받을 수 있었습니다.

이 내용은 이번 글뿐만 아니라 토스 테크 블로그에 똑똑하게 브라우자 폴리필 관리하기라는 내용으로 작성되어 있으니, 필요한 분들은 이 글을 읽어보고 자세한 구현을 따라해 보아도 좋을 것 같습니다.

스켈레톤 마법

다음은 스켈레톤 마법입니다. 우리가 어떤 웹페이지의 화면을 띄울 때는 반드시 필요한 구간이 있습니다. 바로 네트워크 구간입니다. 네트워크 연결이 되어 있지 않다면 페이지를 띄우기는 어려울 것입니다. 실제로 SSR 서버에서 이 웹뷰의 페이지를 내려받는 순간까지 웹뷰에는 아무런 화면이 뜨지 않습니다. 이런 경우에 사용할 수 있는 방법이 바로 스켈레톤입니다.

Loading…

네트워크를 통해 페이지를 내려받아서 렌더링 하기 전에 화면에 보여줄 수 있는 방법은 여러 가지가 있습니다. 빈 화면을 보여줄 수도 있고, 빙글빙글 돌아가는 로더 페이지를 보여줄 수도 있습니다. 하지만 사용하는 웹서비스의 모든 페이지에서 동일한 로더를 보게 되면 사용자 경험이 좋지 않을 것 같습니다.

스켈레톤

저는 이런 사용자 경험을 개선하기 위해 접속한 페이지의 UI 형태를 미리 알고, 해당 UI 형태의 스켈레톤을 보여주는 방법을 생각했습니다. 웹뷰가 로딩되는 동안 이 스켈레톤 UI를 보여주는 것입니다. 스켈레톤 서버를 따로 실행하여 접속한 URL을 파싱 해서 파싱 한 데이터를 기반으로 미리 정의한 스켈레톤 타입을 페이지에 맞게 보여주는 방식입니다.

그럼 간단한 예시를 살펴보겠습니다. 아래와 같이 특정 JSON에 특정 주소에 따라 스켈레톤 타입을 정의해둘 수 있습니다. 이 타입을 활용해 ‘shopping/상품목록’에 접속했을 때는 list-only라는 스켈레톤을 보여주고, ‘tossfeed/목록페이지’에 접속했을때는 card-only라는 스켈레톤을 보여줄 수 있습니다.

이처럼 다양한 스켈레톤 타입을 미리 구현해두고 페이지에 맞는 스켈레톤을 보여준다면 유저는 똑같은 로딩 화면을 보지 않고 상황에 맞는 스켈레톤을 보게 되어 사용자 경험이 좋아질 수 있습니다.

지금까지 토스의 7가지 플랫폼 서버 마법 가운데 4가지를 알아봤습니다. 다음 글에서는 5~7번째 마법인 애셋, 오픈 그래프, 웹 모듈 마법에 대해 알아보겠습니다. 또한 이 과정에서 겪은 시행착오도 공유하려고 합니다.

7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기 (2)

이번 글에서는 프론트엔드에 거는 버프 마법, 애셋, 오픈 그래프, 웹 모듈 마법을 알아보려고 합니다. 나아가 7가지 마법의 절망 편도 알아보겠습니다. 7가지 마법을 잘 활용하면 안정성 높고 개발하기 쉬운 프론트엔드 인프라를 구축할 수 있습니다. 한편 절망 편에서 소개한 시행착오 내용들은 유의하여 앞으로 만나게 될 문제점들을 이겨내는 데 도움을 줄 것입니다.

애셋 마법

토스 앱을 사용할 때 유저별로 다양한 UI를 적용하여 사용할 수 있습니다. 예를 들어 다크 테마와 라이트 테마, 큰 글씨 모드, 그리고 기기별로 다른 세이프 에어리어인 노치 UI 등이 있습니다. 이렇게 유저마다, 기기마다 다른 UI에 어떻게 대응할 수 있을까요?

네이티브 앱 정보

앞서 설명한 기기별 정보는 네이티브 앱에서만 얻을 수 있는 정보입니다. 즉, 네이티브 앱에서 전달하는 정보들을 활용해 웹페이지에서 이를 읽어서 대응하는 방식이 필요합니다.

위 그림의 순서와 같이 HTML을 로드하고 자바스크립트와 CSS를 로드합니다. 그리고 JS 앱 브릿지를 호출하여 네이티브 앱으로부터 정보들을 동적으로 불러오고, 이 정보를 토대로 동적으로 CSS를 그리고 적용하여 렌더링 할 수 있습니다.

하지만 토스에서는 HTML, 자바스크립트, CSS가 모두 로드되고 앱 브릿지를 호출하는 과정까지 시간이 너무 느리다고 생각했습니다. 이를 해결하기 위한 아이디어는 어떤 것이 있을까요?

동적 CSS Variables

다양한 아이디어를 생각해 보았는데요, 그 중 대표적인 방법이 동적 CSS Variable이라는 방법입니다. 유저 에이전트를 통해서 기기별 정보를 넘겨주면 애셋 서버에서 CSS Variables를 동적으로 전달해 주는 방식입니다.

간단한 예시를 보겠습니다. 네이티브 앱에서 웹뷰를 설정할 때 아래처럼 유저 에이전트를 커스텀할 수 있습니다. 아래 이미지의 노란색 부분이 바로 유저 에이전트 뒤에 붙인 커스텀 유저 에이전트입니다. SafeArea와 4개의 숫자를 적었고, ColorPreference와 dark라는 문자열을 적어뒀습니다. 이 정보들을 통해 SafeArea의 수치가 몇인지, 그리고 ColorPreference는 다크인지 라이트인지를 미리 알 수 있습니다.

이러한 정보들을 토대로 애셋 서버에서는 아래 이미지와 같이 CSS Variables를 미리 작성해서 브라우저에게 넘겨줄 수 있습니다.

애셋 서버 덕분에 HTML, 자바스크립트, CSS를 로드한 다음 JS 앱브릿지를 호출할 필요 없이 바로 CSS를 적용해서 화면을 보여줄 수 있었습니다. 즉, 자바스크립트 의존성 없이 CSS 로드 직후 바로 적용이 될 수 있습니다. 로드 의존성 없이 완성된 CSS를 내려받기 때문에 화면이 깜빡거리는 문제 없이 화면이 뜨자마자 다크 테마, 큰 글씨 모드, 네이티브 노치 UI까지 모두 대응할 수 있었습니다.

오픈 그래프 마법

다음은 오픈 그래프 마법입니다. 지금부터 설명할 마법은 앱과 관련 없는 다른 외부의 마법이라고 보시면 됩니다. 이 마법은 유저들끼리 URL을 서로 공유할 때 뜨는 미리 보기 이미지와 관련이 있습니다. 아래와 같이 토스 테크 블로그의 URL을 트위터에 공유하면 아래와 같은 미리 보기 이미지가 뜨게 됩니다. 바로 이런 미리 보기 썸네일을 만드는 방법이 바로 오픈 그래프 마법입니다.

URL의 미리 보기가 바뀐다면?

만약 위의 글의 제목이 바뀐다면 어떤 과정이 필요할까요? 아마도 설정해둔 이미지를 교체해야 할 것입니다. 제목을 수정하고, 이미지를 다시 만들어 내려받고, CDN에 업로드하고, 업로드한 이미지를 다시 적용시켜야 하는 번거로움이 발생합니다.

제목과 배경 이미지를 조합하여 해결하기

이런 번거로움을 해결하기 위해 제목과 배경 이미지를 조합하면 어떨까요? 제목에 따라 이미지를 동적으로 불러오는 방법을 사용해 보겠습니다.

아티클 제목인 ‘똑똑하게…’와 배경 이미지를 조합해 그림의 오른쪽과 같은 이미지를 만들 수 있습니다. 즉, 아티클 제목은 타이틀 변수를 통해 전달하고, 배경 이미지는 URL을 전달한 다음 이미지를 생성하여 사용하는 것입니다. 이번에 자세한 구현 방법은 소개하지 않겠습니다. 대신 이 동작을 구현하는 힌트, Headless Browser Puppeteer Screenshots를 찾아보시면 좋을 것 같습니다.

이 마법을 사용하면, 아티클 제목이 바뀔 때마다 새로운 이미지를 만들어 업로드할 필요 없이, 타이틀 파라미터와 URL만 수정하면 썸네일을 수정할 수 있습니다. 타이틀 변수가 서버로부터 받는 정보라면, 서버에서 타이틀 변수만 수정하면 사실 프론트엔드에서는 건드릴 것 없이 썸네일 이미지를 수정할 수 있습니다.

웹 모듈 마법

드디어 마지막 마법인 웹 모듈 마법입니다. 웹 모듈에 대해서는 생소하실 거라고 생각합니다. 웹 모듈은 디자인 시스템과 디자인 툴에 영향력을 끼치는 요소입니다. 웹 모듈에 대해 설명하기 전에 우선 토스의 디자인 툴에 대해 설명드리고 싶습니다.

Framer Code Component

토스 디자이너분들이 가장 많이 사용하는 강력한 디자인 툴은 Framer입니다. Framer의 가장 대표적인 기능 중 하나는 Framer Code Component입니다. 이 기능을 활용하면 실제 리액트 컴포넌트를 가져와서 UI로 보여줄 수 있습니다. 즉, 실제로 디자인 시스템에서 작성한 리액트 컴포넌트를 Framer에 불러와서 디자인을 확인할 수 있습니다.

Framer Code Component의 제약 사항

다만 이 기능에서 토스 디자인 시스템 (TDS)와 같은 외부 디자인 시스템 코드를 가져와서 사용하려면 다양한 제약들이 있습니다. 대표적으로 Framer에서 NPM Import 기능은 실험적 기능이기 때문에 상황에 따라 제대로 동작하지 않는 경우가 발생할 수 있습니다.

다른 제약은 바로 ES 모듈 기반 코드만 가져올 수 있다는 점입니다. 이 제약은 토스 팀에 가장 큰 제약 사항이었습니다. 왜냐하면 TDS는 CommonJS 기반으로 번들링 되기 때문입니다. 따라서 TDS를 Code Component에서 사용하는 것이 불가능했습니다.

제약 사항 해결하기

아래 그림은 토스에서 이를 해결한 구조입니다. TDS와 Framer Code Component 사이에 TDS 웹 모듈 (ES 모듈)을 볼 수 있습니다. 토스에서는 중간에 TDS 웹 모듈을 배치하여 이를 해결했습니다. 웹 모듈에 대해 자세히 알아볼까요?

아래 그림과 같이 Framer Code Component를 사용할 때 URL을 기준으로 컴포넌트를 불러올 수 있습니다. HTTPS 프로토콜을 사용하여 의존성을 가져오고 있는 부분이 바로 웹 모듈입니다. URL Imports, HTTPS Imports, Network Imports와 같은 키워드를 들어본 적 있나요? 이런 방법을 통해 모듈을 임포트 하는 방법입니다.

esm.sh와 같은 클라우드 웹 모듈 서비스가 대표적인 예시입니다. esm.sh에서 React 라이브러리를 가져와서 컴포넌트를 그릴 수 있습니다.

ES 모듈과 웹 모듈에는 차이점이 있습니다. 일반적으로 사용하는 ES 모듈은 node_modules를 통해 의존성을 임포트 합니다. 반면 웹 모듈은 CDN을 통해 전송받은 파일을 통해 의존성을 임포트 합니다. Framer에서는 아래 그림과 같이 웹 모듈을 이용해서 CDN을 통해 웹 모듈을 임포트 합니다.

따라서 토스 UX 팀에서는 디자인 시스템에 있는 코드들을 디자인 팀에 넘길 때, 웹 모듈을 통해서 Framer에 적용한다고 볼 수 있습니다.

웹 모듈 마법을 통해 토스 디자인 시스템의 코드 베이스는 그대로 가져가서 서비스 코드에 전혀 영향을 주지 않게 되었습니다. 그리고 Framer Code component를 사용할 수 있어서 미리 만들어 놓은 디자인 시스템과 동일한 일관성 있는 디자인을 사용하면서 개발을 빠르게 할 수 있는 생산성까지 얻을 수 있었습니다.

웹 모듈을 제공하는 클라우드 서비스는 다양합니다. 앞에서 살펴본 esm.sh를 비롯해 esm.run, skypack.dev 등이 대표적입니다. 하지만 토스에서는 이 서비스를 그대로 쓰기는 어려웠습니다. self-hosted가 미제공되었고, 제공이 되더라도 esm 표준을 준수하지 않았기 때문에 export map이 제대로 작동하지 않는 문제도 생겼습니다. 그리고 유명한 라이브러리에 대응하기 위해 하드코딩으로 대응된 부분도 있었습니다.

이런 문제점으로 인해 토스만의 웹 모듈 서버를 만들게 되었고, 아래와 같이 URL과 캐럿 버전까지 명시하여 웹 모듈을 사용할 수 있게 되었습니다.

참고로, esm.sh는 self-hosted와 프라이빗 레지스트리를 제공하는 Go 언어 기반의 오픈소스입니다. 현재 토스에서도 esm.sh 도입하려고 검토 중입니다. 여러분들도 esm.sh를 활용해 웹 모듈 서비스를 사용해 보면 좋을 것 같습니다.

구현을 위한 Cheat Sheet

지금까지 7가지 마법에 대해 알아보았습니다. 이번 글에서는 실제 구현을 위한 코드나 내용은 최대한 빼고 설명했는데, 혹시 실제 구현에 대한 질문이 생길 수도 있을 것 같아서 아래와 같은 목록을 작성했습니다.

실제 구현을 위해 이와 같은 라이브러리들을 활용을 했습니다. 위 키워드를 활용하면 여러분도 구현에 필요한 힌트를 얻을 수 있을 것 같습니다.

시행착오 (7가지 마법 절망편)

지금까지는 7가지 마법을 희망차게 소개하면서 이 마법들을 사용하면 프론트엔드에 버프를 걸 수 있다고 소개했습니다. 하지만 뒤에는 절망 편도 존재합니다. 바로 다양한 시행착오를 겪은 내용인데, 하나씩 설명드리겠습니다.

클라우드 인프라 이중화의 어려움

AWS 람다를 통해 서비스를 구현할 때 만약 람다 자체가 장애를 일으키면 서비스를 운영할 수 없을 것입니다. 토스는 안정성이 가장 중요한 서비스이기 때문에 AWS에 장애가 나도 서비스가 정상적으로 동작 되어야 합니다. 이를 대비하기 위해 다른 업체에 이중화를 구현할 수 있습니다. AWS에 구현된 내용을 Cloudflare에도 구현해두는 것입니다.

이중화를 통해 장애 대응을 할 수 있지만 이로 인해 다양한 클라우드 제공 업체에 따로 배포해야 하고, 로그나 모니터링도 따로 확인해야 합니다. 즉, 운영 복잡도가 올라간다는 단점이 존재합니다. 이러한 문제점을 해결하기 위해 토스에서는 자체적으로 서버들을 구현하게 됐습니다.

Serverless Node.js 버전 따라가기

이미지 최적화 서비스가 처음 만들어질 때 사용한 Node.js의 버전은 14, 16 정도였습니다. 이 버전을 사용하여 서비스를 운영하다가 반드시 버전 변경을 해야 하는 상황을 만나면 많은 번거로움이 생깁니다. AWS에서는 현재 Node.js 16기반의 람다를 수정하는 것조차 허용하지 않습니다. Node.js 16은 너무 오래된 버전이기 때문입니다. 따라서 운영 중인 서비스의 코드 베이스를 강제로 올려서 빌드한 후 알맞은 버전으로 배포를 해야 합니다.

이런 과정은 감당하기 힘든 리스크가 될 수도 있습니다. 이렇게 버전에 대한 End-Of-Life를 만나게 되더라도 클라우드 제공 업체가 아닌 토스 팀 스스로 주도권을 가져가고 싶었습니다. 직접 구현한 서버를 통해 강제 업데이트를 최대한 피하고 시간이 여유로울 때 차근차근 버전을 올릴 수 있도록 했습니다.

API 호출 비용

세 번째는 바로 API 호출에 따른 비용 문제입니다. 타임 어택과 같은 이벤트성 트래픽은 매우 짧은 시간 동안 급격한 트래픽이 발생하기 때문에 CDN이 있어도 캐시가 제대로 동작하지 않을 수 있습니다. 캐싱 되지 않았을 때 발생하는 트래픽 비용은 람다가 호출되는 만큼 발생하기 때문에 트래픽을 미리 예측하고 비용을 계산해야 할 수 있습니다. 반면 토스에서는 자체 서버를 통해 람다 서비스 비용을 아낄 수 있었습니다.

QueryString 기반의 API 인터페이스

다음 시행착오는 인터페이스에 관한 내용입니다. 앞서 설명드린 다양한 서버들의 인터페이스는 대부분 QueryString으로 동작합니다. 이로 인해 CDN에서 캐시를 적용하기 조금 어려웠습니다. 아래와 같이 컬러, 사이즈 순서의 요청과 사이즈, 컬러 순서의 요청은 서로 다른 별개의 캐시로 기록됩니다. 즉, 같은 요청이지만 2개의 캐시가 생기는 문제점이 발생합니다.

이러한 문제에 대해 QueryString보다는 Path 기반으로 적용하여 이 문제를 해결했습니다. 아래와 같이 src=이미지주소&q=80&w=200의 QueryString 기반이 아닌 width=80,quality=75/이미지주소와 같이 Path 기반으로 만들었습니다.

이 아이디어는 직접 고안해낸 방법은 아니고, Cloudflare의 이미지 최적화 API에서 사용하는 기법 중 하나입니다. 이 방법을 도입하여 캐싱 기간을 많이 늘릴 수 있었고 관리도 쉬워지는 장점을 얻었습니다.

람다 최대 응답 페이로드 제한

또 다른 시행착오는 람다의 최대 응답 페이로드의 크기에 제한이 걸려있다는 것입니다. 6MB를 넘는 요청은 비용을 더 지불해도 해결할 수 없는 문제였습니다. 실제로 6MB를 넘는 요청은 제대로 된 응답을 주지 못합니다.

토스에서는 앞서 설명한 비디오 썸네일 서비스에서 6MB가 넘는 경우가 발생했습니다. 가로 영상과 세로 영상이 존재하는데, 가로 영상만 생각하고 가로 길이로 이미지 최적화를 하다 보니 세로 영상의 경우는 썸네일 이미지 사이즈가 엄청 커저버리는 경우가 발생했습니다. 결국 400, 500 등의 응답을 받는 경우가 발생했습니다.

이런 경우가 발생하더라도 실제 서비스에서는 이런 문제가 나타나면 안 된다고 생각합니다. 혹시나 6MB를 넘는 요청이 발생하였더라도, 자체적인 서버 운영 등의 방법을 통해 서비스에 지장을 주지 않게 해야 합니다.

CDN Vary Header

캐싱 정책을 사용할 때 Vary 헤더를 사용해야만 요청 헤더마다 별도의 캐시를 사용할 수 있습니다. 폴리필 서버를 예로 들면, 제가 사용하는 브라우저와 옆 사람이 쓰는 브라우저가 다르지만, 폴리필 JS를 동일하게 받는 문제가 생깁니다. 즉, 인터넷 익스플로러가 먼저 캐싱 해버린 상태로 크롬에서 폴리필 JS를 받으면 익스플로러에서 캐시 된 폴리필 JS를 받게 되는 것입니다.

이러한 문제를 해결하기 위해 요청 헤더를 Vary 헤더로 설정하여 유저 에이전트가 달라지면 캐시를 별도로 사용한다고 명시적으로 세팅해야 합니다.

절망편 정리

시행착오 내용들을 정리하면, 서비스를 이중화를 하면 다양한 업체에 대해 관리해야 하는 문제가 있고, 람다를 사용할 때 Node.js의 버전을 잘 챙겨야 합니다. 이벤트성 트래픽은 캐싱이 어렵기 때문에 트래픽 비용을 잘 고려해야 하고, QueryString보다는 Path 기반의 인터페이스로 만들기를 추천합니다. 람다의 응답 최대 크기는 6MB라는 점을 기억하고 이를 초과하는 경우를 대비해야 하고, Vary 헤더를 잘 사용하여 캐싱 정책을 올바르게 만들어 사용해야 합니다.

마치며

지금까지 프론트엔드에 버프를 걸기 위한 7가지 마법에 대해 희망 편과 절망 편으로 나누어 알아보았습니다. 7가지 마법을 잘 활용하여 안정성 높고 개발하기 쉬운 프론트엔드 인프라를 구축하길 바랍니다. 또, 절망 편에서 소개한 시행착오 내용들도 유의하여 앞으로 만나게 될 문제점들을 이겨내는 데 도움이 되면 좋겠습니다.

7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기 (1)

FEConf2024에서 발표된 ‘7가지 플랫폼 서버로 프론트엔드 버프 마법 걸기’/정석호 토스 코어 Frontend Infra Ops Unit Lead ↩︎