최근 프론트엔드 개발에서 사실상의 표준으로 자리매김 하는 기술이 있습니다. 바로 SSR, Server Side Rendering인데요. Next.js를 비롯한 다양한 프레임워크에서 SSR을 손쉽게 구축할 수 있는 솔루션을 제공하고 있습니다. 토스 또한 SSR을 도입하여 많은 사용자에게 빠르고 안정적인 경험을 제공하려고 노력하고 있는데요.오늘은 SSR 아키텍처 운영을 위해 반드시 알아두어야 할, SSR 서버의 최적화와 관련된 이야기를 해보려 합니다. 최적화를 통해 토스는 서비스 운영에 필요한 SSR 서버의 수를 절감하여 비용을 개선할 수 있었습니다.SSR은 Server Side Rendering의 약자로, 화면의 렌더링이 서버에서 이루어지는 아키텍처를 의미합니다. 사전적인 의미는 이러하지만 일반적으로 현대의 SSR은 “첫 HTML 렌더링을 서버에서 처리하고, 이후의 렌더링 사이클은 클라이언트에서 처리”하는 하이브리드 형태의 SSR을 가리킵니다. Next.js, Astro 등의 현대적인 웹 프레임워크는 기본적으로 제공하는 아키텍처입니다. Static Site Generation이나 Dynamic SSR처럼 다양한 방식이 있습니다.SSR은 “첫 HTML 렌더링을 서버에서 처리”하기 때문에, 사용자의 화면에 컨텐츠가 그려지는데 걸리는 시간(FCP, First Contentful Paint)가 더 짧습니다. 토스는 이전에 CSR(Client Side Rendering) 아키텍처를 사용하고 있었는데요. 사용자의 화면에 JavaScript 번들이 모두 다운로드된 다음 첫 렌더링을 실행하면서 인증, 데이터 요청 등의 과정을 거치다보니 화면이 렌더링되는 시간이 상대적으로 길었습니다.이때 SSR 아키텍처를 도입하게 되면서, 인증과 데이터 처리의 첫 과정이 서버에서 먼저 모두 이루어진 다음 사용자는 완성된 HTML을 받아보면서 로딩 속도를 상당히 감축할 수 있었습니다.하지만 공짜 점심은 없죠. SSR을 도입하면 SSR 서버를 구축해야 합니다. Static Serving으로 처리가 가능한 CSR 아키텍처에서는 별도의 로직을 구현하는 서버를 만들 필요가 없습니다. 요청자가 요청한 위치의 파일을 돌려주기만 하면 됩니다. 하지만 SSR은 요청에서 필요한 정보를 파악하고, 적절한 페이지 파일을 가져와 렌더링을 처리한 후, 완성된 HTML과 JS 번들을 돌려주어야 합니다. 다행히 토스에서 사용하는 Next.js는 SSR 서버 구축을 아주 쉽게 할 수 있도록 도와줍니다. 토스 앱의 동작에 필요한 몇몇 미들웨어와 라우팅 로직을 커스텀 서버에 구현하는 정도로 마무리할 수 있었으니까요.그러나 서비스의 성장에 따라 SSR 서버로 유입되는 트래픽이 늘어나면서, 서버의 숫자도 상당히 늘어나게 되었습니다. 또한 SSR 아키텍처의 빠른 로딩이라는 이점을 위해 SSR을 도입하는 서비스의 숫자도 점점 늘어났습니다. 이에 따라 SSR 서버의 숫자가 관리하기 어려울 만큼 많아졌고, 이들의 숫자를 줄여야 한다는 문제 의식이 발생합니다. 트래픽을 줄일 수는 없기 때문에, 같은 트래픽에서 서버의

Software 개발 프로젝트를 진행하다보면 기술을 데모하거나 POC를 하기 위한 간단한 데모 웹페이지나 데모 앱이 필요한 경우가 생기게 됩니다.이때 유용한 것이 간단한 SPA(Single Page App)으로 구성하는 Static web page인데요.SPA를 구현을 도와주는 웹개발 프레임워크들도 많이 나와 있지요.(Next.js, Gatsby, Hugo, Nuxt, Jekyll, etc...)SPA로 데모앱을 만들고 접근성 확보를 위해 웹에 간단하게 Static web page로 구성하여 호스팅을 하게 되는데.이때 사용할 수 있는 여러가지 프레임워크를 지원하는 서비스들이 많이 나와있습니다. (Netlify, StackBlitx, AWS Amplify, etc...).또한 Python으로 SPA기반의 데모웹을 만들어보고 웹호스팅까지 할 수 있는 Streamlit이나 Gradio같은 서비스(프레임워크 포함) 도 있습니다.이러한 서비스는 Machine learning모델을 서비스를 위한 빠른 웹앱 개발에 특화되어 있습니다.(기회가 되면 다른 글에서 다루어 보겠습니다)Next.js는 React 기반 웹 애플리케이션을 개발하기 위한 오픈 소스 프레임워크입니다.서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 자동 코드 분할, 이미지 최적화 등 다양한 기능을 제공하여 빠르고 사용자 친화적인 웹 앱 개발을 가능하게 합니다.• None 서버 사이드 렌더링: 페이지를 클라이언트에 전송하기 전에 서버에서 HTML, CSS 및 JavaScript를 렌더링하여 페이지 로딩 속도를 높입니다.• None 정적 사이트 생성: 빌드 단계에서 HTML, CSS 및 JavaScript를 정적 파일로 생성하여 웹 앱을 정적 사이트로 배포할 수 있습니다.• None 자동 코드 분할: 페이지 로딩 속도를 높이기 위해 필요한 코드만 로드합니다.• None 이미지 최적화: 이미지를 자동으로 최적화하여 웹 앱의 성능을 향상시킵니다.• None SEO 친화적: 서버 사이드 렌더링 덕분에 검색 엔진 크롤러가 페이지를 쉽게 인덱싱할 수 있습니다.• None 다양한 라우팅 옵션: 기본 라우팅과 함께 파일 기반 라우팅, 동적 라우팅, 캐치올 라우팅 등을 지원합니다.• None API 라우팅: 서버 측 API를 쉽게 만들고 관리할 수 있습니다.• None 커뮤니티 지원: 활발한 커뮤니티와 풍부한 문서 및 튜토리얼을 제공합니다. Next.js는 다음과 같은 경우에 적합합니다.빠르고 사용자 친화적인 웹 앱을 개발하고 싶을 때• None SEO에 최적화된 웹 앱을 만들고 싶을 때• None React 기반 웹 앱을 개발하고 싶을 때• None 다양한 기능을 제공하는 프레임워크를 원할 때• None Next.js는 배우기 쉽고 사용하기 편리하며 다양한 기능을 제공하여 웹 앱 개발을 크게 간소화할 수 있는 강력한 프레임워크입니다.Hume AI는 AI기술로 Text, Voice, Vision으로 부터 사람의 감정을 인식하는 API를 서비스하는 회사입니다.API를 서비스할 수 있는 데모앱을 Next.js기반으로 만들어 공개하고 있어 이를 이용하여 테스트 하였습니다.여기서는 이 웹앱을 로컬에서 빌드하고 실행해보고 최종적으로는 Netlify와 AWS Amplify에 배포해봅니다.웹 개발자들이 정적 웹사이트나 SPA(Single Page App)을 호스팅하기 위해 자주 활용하는 두 가지 인기 옵션은 Netlify와 AWS Amplify입니다.두 플랫폼 모두 Git 저장소에서 자동 빌드 및 호스팅을 지원하여 정적 사이트 배포를 매우 간편하게 해줍니다.이번 글에서는 실제 NextJS 앱 배포 사례를 바탕으로 각각의 장단점을 비교해보겠습니다.Next.js로 작성된 Hume AI의 Example 데모앱을 Netlify와 AWS Amplify에 각각 배포해보았습니다.Netlify는 자신을 "모던 웹 프로젝트를 자동화하는 플랫폼"이라고 소개합니다.Git으로부터의 지속적 배포, 서버리스 함수, 글로벌 CDN, 도메인 관리, SSL/TLS 인증서 등을 지원합니다Netlify로 호스팅 하는 가장 간단한 방법은 'Deploy manually'로 빌드된 Output file들을 Drag and drop이나 browse to upload방식으로 upload하면 손쉽게 자동 생성된 url에 연결되어 웹앱을 손쉽게 호스팅할 수 있습니다.실행을 완료하고나면 Netlify에서 호스팅하는 URL을 갖게 됩니다.AWS Amplify는 단일 페이지 앱과 정적 사이트를 포함한 전체 스택 서버리스 웹앱을 빌드하고 배포할 수 있는 종합 솔루션으로,다른 AWS 서비스 위에 계층화되어 있습니다.Web UI에 접근할 필요없이 Source Code 폴더 내에서 Amplify configuration을 통해 Amplify의 Framework를 통합시켜주고, CLI환경에서 'amplify publish' 명령을 통해 한번에 빌드부터 배포까지 실행할 수 있습니다.실행을 완료하고 나면 AWS Amplify에서 호스팅하는 URL을 갖게 됩니다.Netlify와 AWS Amplify는 모두 고유한 기능과 고려 사항을 갖춘 정적 웹 페이지를 호스팅하기 위한 강력한 솔루션을 제공합니다.Netlify는 단순성과 사용 편의성이 뛰어나 배포 요구 사항이 간단한 중소 규모 프로젝트에 이상적입니다.반면, AWS Amplify는 고급 사용자 정의 옵션과 더 넓은 AWS 생태계와의 원활한 통합을 제공하므로 확장성과 유연성이 필요한 대규모 프로젝트에 적합합니다.궁극적으로 Netlify와 AWS Amplify 사이의 선택은 프로젝트 요구 사항, 예산, 해당 플랫폼에 대한 친숙도에 따라 달라집니다.결국 자신에게 가장 적합한 플랫폼은 특정 요구 사항과 기술 수준에 따라 다릅니다.Netlify와 AWS Amplify는 모두 무료 평가판을 제공하므로 두 가지 모두 시도하여 자신에게 가장 적합한 플랫폼을 확인하는 것이 좋습니다.

리뉴얼 된 글로벌 웹사이트처음 당근에 들어오기 전, 저는 당근을 사용하는 1800만 유저 중 한 명이었어요. 중고거래 뿐만 아니라 지금은 동네모임까지 생긴 동네생활을 사용하며 이웃들과 도움을 주고 받고 따뜻한 마음을 느끼며 누군가의 이웃이 되는 그 행복이 저를 당근으로 이끌었네요. 저는 프론트엔드코어 팀의 웹사이트 파트에서 당근의 콘텐츠를 웹에 올리고 퍼뜨리고 있는 프론트엔드 개발자 lea.lah 입니다.당근에 웹사이트가 있다는 것, 알고 계셨나요? 많이 접속해보셨을 기업 소개 사이트 외에도, www.daangn.com/ 이라는 콘텐츠 중심의 웹사이트가 있답니다. 이제는 중고거래 뿐만 아니라 동네 업체, 알바, 부동산, 중고차, 그리고 곧 올라갈 모임까지 다양한 당근의 콘텐츠가 올라가 있어요. 그리고 꽤 많은 유저가 웹을 방문하고 있답니다.월 140만 명이 오가는 당근닷컴당근은 앱이 메인인 회사이기 때문에, 웹의 필요성이 대두 되기까지 꽤 오랜 시간이 걸렸어요. 이 글에서는 어떻게 초기 웹사이트가 개발되었고, 어떤 부분들을 챙겼으며, 어떻게 리뉴얼까지 이르렀는지 전반적인 내용을 담아보고자 해요. 앱에서 뿐만 아니라 웹으로 검색하는 유저도, 앱은 없지만 이웃, 지인, 가족으로부터 공유받은 당근의 콘텐츠를 열어보는 유저도 모두 접하고 탐색할 수 있는 당근닷컴을 한번 구경해보실래요?https://karrotmarket.com/?in=toronto-11052인터넷을 쓴다면 웹은 필요해요.당근은 MAU 1,800만 명이라는 큰 숫자의 유저를 보유하고 있어요. 하지만 몇 년 전까지만 해도, 어느 검색 사이트에서 검색하든 중고거래 게시글을 제외한 당근의 콘텐츠(알바, 부동산, 중고차, 동네업체)는 나오지 않았어요. 앱에 많은 콘텐츠가 갇혀 앱이 없는 유저는 공유된 글이 어떤 글인지 확인하지도 못했죠. 무조건 앱을 다운로드하거나 안 보거나, 하는 모 아니면 도의 선택지만 주어졌어요.하지만 다양한 서비스가 생기며 점점 빠르게 커져가는 당근의 생태계에서 콘텐츠가 앱에만 갇히는 건 큰 손실이에요. ‘난 굳이 앱까지 다운받고 싶지 않은데?’, ‘그냥 글만 보여주면 되지 왜 다운까지 받아야 해’ 하며 이탈하는 유저를 잃게 되고, 이탈한 유저들은 “당근”을 매개체로 한 지역 기반 커뮤니티를 모르게 되기 때문이죠. 우리가 얼마나 다양한 서비스를 운영하고 있고, 따뜻한 당신 근처의 이웃들을 만들기 위해 어떤 커뮤니티를 만들고 어떤 시도를 하고 있는지 유저에게 아예 보여줄 수가 없는 거예요.첫 삽은 그렇게 뜨기 시작했어요. World Wide Web에 콘텐츠를 올리자. 당근을 모르고, 평소 관심이 적었던 유저들에게 우리의 커뮤니티를 보여주자. 그럼 우리 플랫폼에 공감할거야. 그렇게 웹에 글을 노출하기 위해 URL을 따고 페이지를 만들기 시작했어요.코어 팀의 To-do와 Not To-do는 무엇일까?여기서 제가 속한 팀에 대한 소개를 해볼게요. 저희 팀은 프론트엔드 개발자들로 이루어져 있어요. 당근은 목적 조직이지만, 저희 팀은 Tech Core 조직으로 기능 조직과

안녕하세요, 인프랩 프런트엔드 개발자 융디입니다.최근 인프런 유저분들이 정성스럽게 작성해 주신 수강평과 질문&답변 페이지를 SNS에 공유 했을 때, 가장 먼저 보이는 링크 미리보기 이미지에 변화가 생겼다는 것을 눈치채신 분들이 계실까요?혹시 눈치채지 못하셨다면 이 글을 읽기 전, 본인이 인프런에 작성한 자랑스러운 수강평과 질문&답변 게시글을 SNS 에 공유해보세요. 아마도 이 글을 더 흥미롭게 읽으시는데 도움이 되실 것이라 생각합니다.그럼 이제, OG 이미지가 동적으로 생성되게 개발하면서 얻은 경험을 공유해보도록 하겠습니다.인프런은 동적으로 생성되는 OG 이미지가 왜 필요할까?인프런에는 강의를 수강한 학생과 강의를 제공하는 지식공유자 분들이 직접 작성한 좋은 콘텐츠가 많습니다. 이 콘텐츠를 외부에 공유할 때는 주로 링크 복사를 통해 SNS에 공유되는 경우가 많죠.하지만, 실제로 위와 같이 외부에 공유된 콘텐츠는 링크를 통해 직접 인프런 사이트에 접근해서 내용을 확인하지 않는 이상 어떤 내용을 담고 있는 콘텐츠인지 한 눈에 확인하기 어려운 경우가 많습니다.참고로 최근 수강평 상세 페이지의 유입 referrer 지표를 보면, SNS 공유를 통해 인프런 웹사이트에 접근하는 사용자가 큰 비중을 차지하고 있습니다. 데이터 지표로 이를 확인한 이상, 링크 공유 시 표시되는 미리보기 이미지를 이른 시일 내에 개선하고자 하는 니즈가 커졌습니다.이를 개선하고자, 다른 웹사이트들의 OG 이미지를 참고하다가 매주 슬랙에 공유되는 GeekNews 링크의 OG 이미지가 딱 이 문제를 해결해 줄 것 같다는 느낌이 들었습니다.그 이유는 평소 GeekNews 아티클을 골라 볼 때, OG 이미지에 있는 아티클의 제목과 간략한 내용을 확인하고 관심 있는 주제라면 자연스럽게 링크를 클릭하고 있었기 때문입니다.이에 따라, 인프런 유저 콘텐츠 페이지에도 OG 이미지를 동적으로 생성하여 적용하기로 결정했습니다.어떻게 콘텐츠마다 동적으로 OG 이미지 생성할까?동적으로 OG 이미지를 만들 수 있는 다양한 방법 중, Vercel 에서 HTML/CSS를 SVG로 변환하여 빠르고 다이나믹하게 소셜 이미지를 만들 수 있는 오픈 소스 라이브러리 를 제공하는 것을 발견했습니다.Vercel에서 제공하는 라이브러리인 를 사용하는 방법은 매우 간단합니다.공식 문서에 친절하게 나와 있는 대로 Next.js 프로젝트에 해당 의존성 라이브러리를 설치하고, 사용하고 있는 Next.js 프로젝트의 라우터 방식에 맞게 API 라우터를 생성하여 라이브러리 인터페이스에 맞게 코드를 작성해 주면 됩니다.라이브러리 사용 시, 참고해야 할 사항은 아래와 같습니다.• Node.js 16 이상만 지원합니다.• 는 Node.js 런타임을 지원하지 않습니다. Edge 런타임에서만 동작합니다.• 내부 핵심 엔진인 satori 가 허용하는 일부 HTML/CSS 기능만 지원합니다.웹 페이지에 동적 OG 이미지 적용하기동적으로 생성되는 OG 이미지를 웹 페이지에 적용하는 방법 또한 매우 간단합니다.동적 OG 이미지를 적용할 페이