버즈빌 Supply 그룹의 Product Growth 팀의 Luke입니다. 저희 버즈빌에서 지난 몇 년간 겪어온 프론트엔드 아키텍처 변화를 공유하려 합니다. AngularJS에서 시작해 Vue, React를 거쳐 Next.js까지, 각 전환점에서의 고민과 선택 과정을 솔직하게 담았습니다.

AngularJS에서 Vue로: 통합 어드민의 시작

초기 버즈빌은 광고주(Demand)와 매체사(Supply)를 위한 두 개의 AngularJS 어드민을 별도로 운영했습니다. 각각 다른 앱으로 개발되어 캠페인 관리, 리포팅 같은 기본 기능들이 중복 구현되어 있었습니다. AngularJS 1.x의 복잡한 구조 때문에 새로운 요구사항에 대응하기도 점점 어려워졌습니다.

기술 부채가 쌓이자 프레임워크 전환과 함께 두 어드민을 통합하기로 결정했습니다. React도 고려했지만, 프론트엔드 뿐만 아니라 백엔드 개발자가 동시에 사용하는 프로젝트인데 당시에는 React가 Class형 컴포넌트만 쓸 때였는데 Vue가 러닝커브가 낮고 AngularJS의 템플릿 기반 개발 경험과도 자연스럽게 이어지는 장점이 있었습니다.

쉽지만은 않았지만 Vue로의 전환을 끝낸 뒤 Vue 전환 과정에서 중복된 코드를 정리하고 공통 기능을 모듈화하면서 코드베이스가 절반으로 줄었습니다. 개발 속도도 눈에 띄게 향상됐고, 무엇보다 하나의 통합 어드민에서 Demand와 Supply 기능을 함께 관리하니 일관성 있는 사용자 경험을 제공할 수 있게 되었습니다.

BFF 도입: 프론트엔드를 위한 백엔드

초기에는 서버 개발자와 협업하기 위해 Vue 프로젝트 위에 Python Django 레이어를 추가하여, 프론트엔드와 백엔드 간의 통신을 Django를 통해 처리했습니다. 이를 통해 버즈빌의 백엔드 서버와 안정적으로 연동할 수 있었죠.

하지만 당시 버즈빌은 MSA(Microservice Architecture)를 채택하고 있었기 때문에, 프론트엔드는 하나의 백엔드가 아니라 수많은 마이크로서비스들과 통신해야 했습니다. 이러한 구조에서 Django는 초기에는 유용했지만, 시간이 지나면서 프론트엔드 개발자가 직접 Python으로 Django 코드를 관리해야 했고, 이는 프론트엔드 개발자가 익숙하지 않은 백엔드 기술 스택까지 다뤄야 한다는 부담으로 이어졌습니다. 결과적으로 Django 레이어는 오히려 개발 속도를 늦추는 요인 중 하나가 되었습니다.

이를 해결하기 위해 BFF(Backend For Frontend) 레이어를 도입했습니다. Node.js Express 서버를 Django와 프론트엔드 사이에 두고, 프론트엔드 팀이 직접 필요한 형태로 API를 설계할 수 있게 한 것이죠. 여러 Django API를 조합해 프론트엔드에 최적화된 응답을 만들거나, 인증/캐싱 같은 공통 로직을 한 곳에서 처리할 수 있게 되었습니다.

물론 서비스 레이어가 늘어난 만큼 모니터링 포인트도 늘었지만, APM 도구를 도입해 안정성을 확보했고, 결과적으로 프론트엔드 개발 속도가 크게 향상되었습니다.

WebView + React: Native SDK의 대안

버즈빌은 파트너 앱에 광고 지면을 제공하는데, Native SDK 방식을 사용했습니다. 하지만 새 기능을 추가하려면 파트너사가 SDK를 업데이트하고 앱을 재배포해야 했죠. 앱 출시 주기가 길거나 업데이트 정책이 보수적인 파트너사의 경우 개선사항 반영이 2년 이상 걸리기도 했습니다.

이 문제를 해결하기 위해 WebView 기반 React SPA로 전환했습니다. 파트너 앱은 WebView만 띄우고, 그 안에서 React 앱이 동작하는 구조입니다.

당시에 처음 시도하는 Webview 지면 연동이어서, 많은 시행착오를 겪었지만 이 이야기를 다 쓰려면 또 글이 길어질거 같아서, 시간 나면 다음 포스팅에서 적어보려고 합니다. 결과적으로 지면이 성공적으로 런칭되어, 함께 고생한 팀원들과 워크숍도 다녀왔습니다.

Turborepo로 모노레포 구축

WebView 전략이 성공하면서 웹뷰를 통한 광고 서빙에 대한 니즈가 늘어나게 되었습니다. 그렇게 되어 프로젝트가 늘어날수록 각각의 리포지토리에서 설정 관리, 공통 컴포넌트 동기화, 패키지 버전 관리가 점점 복잡해졌습니다.

이 시점에 Turborepo를 도입해 모노레포 구조로 전환했습니다. Lerna, yarn workspace 등 여러가지 옵션이 있었지만 Vercel이 시장 파이를 점점 넓혀가고 있었고, FE개발자가 많지 않은 상황에 강력한 기능보다는 생산성이 더 중요했기 때문에, 당시 Zero configuration을 지향하던 Turborepo를 선택했습니다. 모든 WebView 프로젝트를 하나의 리포지토리에서 관리하고, 공통 UI 컴포넌트와 유틸리티는 packages/에 모아 각 프로젝트에서 import해 사용하는 구조죠.

초기에는 기존 리포지토리들을 합치면서 Git 이력을 보존하는 작업이 까다로웠고, Turborepo 의존성 문제에 많은 시간을 쓰기도 했습니다. 하지만 지금은 10개 이상의 프로젝트를 효율적으로 관리하며 개발자 경험을 크게 개선했습니다.

Server-Driven UI로 유연성 확보

파트너사마다 원하는 UI 레이아웃이 달랐고, 새로운 디자인을 실험할 때마다 클라이언트 배포가 필요했습니다. 이를 해결하기 위해 Server-Driven UI 아키텍처를 도입했습니다.

UI를 작은 모듈로 나누고, 서버에서 JSON 형태로 “어떤 컴포넌트를 어떤 순서로 배치할지” 지시하면 클라이언트가 이를 해석해 화면을 구성하는 방식이죠. 예를 들어 A 파트너는 리스트형 레이아웃을, B 파트너는 그리드형 레이아웃을 원한다면, 서버 설정만 바꿔 즉시 적용할 수 있습니다.

이 접근법은 강력했지만 복잡도도 높았습니다. 모든 가능한 조합을 고려한 설계가 필요했고, 특정 컴포넌트 조합에서 UX 문제가 생기지 않도록 검증 로직도 필요했죠. 운영팀을 위한 설정 편집 도구와 미리보기 기능도 개발해야 했습니다. 이러한 투자 덕분에 현재는 코드 배포 없이도 다양한 실험과 커스터마이징이 가능해졌습니다.

Next.js 도입: 팀의 표준 스택으로

React 프로젝트가 늘어나면서 React App의 한계를 느끼기 시작했습니다. SSR이 필요한 경우 별도 설정이 복잡했고 많은 고객사에서 성능에 대해 민감했는데 이를 충족시키기가 어려웠습니다.

Next.js로 전환하면서 많은 것이 해결되었습니다. SSR을 이용해 기본적인 Server driven UI 값들을 미리 불러올 수 있게 되어 초기 로딩이 빨라졌고, 특히 WebView 환경에서 체감 성능이 크게 개선되었습니다. API Routes로 BFF 기능 일부를 Next.js 안으로 통합하면서 아키텍처도 단순해졌죠.

파일 기반 라우팅 덕분에 프로젝트 구조가 직관적이 되었고 개발 워크플로우가 한층 매끄러워졌습니다. 지금은 Next.js가 팀의 표준 프레임워크로 자리잡아 모든 신규 프로젝트에 사용되고 있습니다.

Hybrid SDK로 WebView-Native 통신 최적화

WebView 내 웹 앱은 네이티브 기능(외부 브라우저 호출, 뒤로가기 이동 등)을 호출해야 하고, 네이티브는 웹에 이벤트(웹뷰 호출데 대한 결과값)를 전달해야 합니다. 웹뷰 연동시 연동건마다 별도의 브릿지 코드를 작성했는데, 기능이 늘어나면서 관리가 어려워졌죠 특히나 고객사의 네티이브 개발자들과 커뮤니케이션 핑퐁에 많은 리소스가 소모되었습니다.

이를 해결하기 위해 Hybrid SDK를 개발했습니다. Android 및 iOS에서 통일된 인터페이스를 구축했죠. 웹에서는 window.buzzvilSdk.postMessage(payload) 하나로 모든 네이티브 기능을 호출할 수 있게 되었습니다.

다음 과제: Vue 어드민의 점진적 마이그레이션

현재 Vue 어드민은 안정적으로 운영되고 있지만, 팀의 주력 스택이 React/Next.js로 옮겨간 상황에서 기술 스택 분열은 부담이 되고 있습니다. 신규 개발자는 Vue와 React를 모두 익혀야 하고, 이는 이후에도 지속적으로 허들이 되고 있습니다.

하지만 운영 중인 대규모 어드민을 한 번에 전환하는 것은 위험합니다. 그래서 점진적 마이그레이션 전략을 세웠습니다. 먼저 신규 기능은 모두 React로 개발하고, 기존 Vue 페이지와 iframe으로 연결합니다. 마이크로 프론트엔드와 비슷한 구조로 독립적인 페이지부터 하나씩 React로 재작성하면서, 과도기적으로 마이크로 프론트엔드 아키텍처로 두 프레임워크를 공존시킬 계획입니다.

앞으로 2-3년 내 모든 어드민을 Next.js 기반으로 통합하는 것이 목표입니다.

마치며

AngularJS에서 시작해 Vue, React를 거쳐 Next.js까지, 버즈빌 프론트엔드 팀의 기술 여정을 공유했습니다. 돌이켜보면 각 전환점마다 나름의 이유와 고민이 있었고, 완벽한 선택은 없었습니다.

중요한 것은 현재 상황에서 최선의 선택을 하고, 문제가 생기면 과감하게 개선하는 자세였습니다. BFF로 개발 속도를 높이고, WebView로 배포 유연성을 확보하고, 모노레포로 관리 효율성을 개선한 것처럼요.

앞으로도 새로운 기술과 도전이 기다리고 있을 것입니다. WebAssembly, AI 기반 개발 도구 등 흥미로운 기술들이 계속 등장하고 있죠. 하지만 기술 자체보다는 “우리 팀과 서비스에 정말 필요한가?“를 먼저 묻는 자세를 유지하려 합니다.

비슷한 고민을 하는 개발자분들께 이 글이 작은 도움이 되었기를 바랍니다. 기술 선택에 정답은 없지만, 다른 팀의 경험에서 인사이트를 얻을 수는 있으니까요.

버즈빌 개발자 지원하기 (클릭)

버즈빌 테크 리크루터와 Coffee Chat하기 (클릭)