버즈빌의 소프트웨어 아키텍트는 어떤 일을 할까?
안녕하세요. 버즈빌에서 ATF(Architecture Task Force) 라는 이름의 팀을 이끄는 이성원입니다. 이 팀은 소프트웨어 아키텍처(Software architecture)를 고민하고 실행하는 소프트웨어 아키텍트(Software architect)가 모인 조직입니다. 2019년 1월 만들어졌으니 이제 약 만 0.5살이 되었네요. 이 글에서는 ATF 팀이 어떤 사람들로 구성되어 있고, 주로 어떤 일을 하는지 누구나 이해할 수 있도록 쉽게 소개하려고 합니다.
소프트웨어 아키텍처, 그게 뭐야?
소프트웨어 아키텍처에 대한 내용은 이전 글 Software architecture: The important stuff에서 간단히 소개한 적이 있습니다. 간단하게 정리해 보면 소프트웨어 아키텍처는 소프트웨어를 구성하기 위해서 고려해야 하는 시스템 디자인을 포함한 중요한 결정들이라고 생각하시면 될 것 같네요.
소프트웨어 아키텍트는 뭐야? 일단 이름은 멋지네.
소프트웨어 아키텍트는 소프트웨어 아키텍처를 고민하는 사람들입니다. 객체 지향 프로그래밍(OOP, Object-oriented programming)이 널리 사용되던 1990년대 후반에 등장해서 자리 잡힌 역할입니다. OOP 덕분에 더 크고 복잡한 애플리케이션 구현이 가능해졌고, 그에 따라 고수준(high-level) 애플리케이션과 시스템 관리가 필요해졌기 때문이죠.
어느 회사나 소프트웨어 아키텍트는 있습니다. 직군 이름에 소프트웨어 아키텍트라고 적혀 있는 사람이 없더라도 누군가 그 역할을 맡고 있을 가능성이 높죠. 규모가 작은 스타트업의 경우 보통 CTO가 해당 역할을 맡고 있습니다. 소프트웨어가 전체적으로 어떤 구조를 가지고 구성될지 고민하고, 결정하고, 실행하죠. 규모가 커지거나 해당 역할이 따로 필요한 경우 엔터프라이즈 아키텍트(Enterprise architect) 혹은 치프 아키텍트(Chief architect)라는 이름으로 분리되어 아키텍트 팀을 리드하기도 합니다.
스타트업인 버즈빌은 왜 ATF가 있지?
디지털 광고 시장의 복잡성
디지털 광고 시장은 생각한 것보다 훨씬 복잡합니다.
“그까이꺼(?) 그냥 사용자한테 광고 이미지 하나 보여주면 되는 게 뭐가 복잡하냐!”라고 생각하실 수도 있죠. 디지털 광고가 생겨나고 성장하면서 생겨난 개념과 기술 등을 차근차근 설명하고 넘어가면 좋겠지만, 이 주제는 추후 따로 한 번 다뤄보도록 하겠습니다. 우선 이 글에서는 애드 테크 분야에 어떤 복잡성이 있는지 간단히 나열해 보죠.
Mobvista에서 제작한 Ad Tech 101 영상을 보면 감을 잡는 데 도움이 될 수도 있겠네요.
디지털 광고, 특히 프로그래매틱 광고는 디맨드 사이드(Demand-side)와 서플라이 사이드(Supply-side)의 필요가 한 군데 얽혀서 돌아갑니다. 디맨드 사이드는 광고를 집행하고자 하는 측, 즉 광고주 측입니다. 서플라이 사이드는 자신들의 사용자에게 광고를 보여줌으로써 수익을 만들고자 하는 측으로, 일반적인 퍼블리셔(Publisher, 서비스 운영 측)가 이에 속합니다. 광고주는 광고를 보여주고 싶고 퍼블리셔는 수익을 만들고 싶으니 둘의 필요성이 딱 맞아떨어진다고 할 수 있죠.
문제는 두 그룹이 서로를 필요로 하고는 있지만 추구하는 방향은 정반대라는 것입니다. 광고주는 가능한 한 저렴하게 광고를 집행하고 싶어 하지만, 퍼블리셔는 같은 사용자를 대상으로 가장 비싸게 광고를 집행하고 싶어 하니까요. 이를 해결하기 위해 다양한 방법들이 등장합니다. 실시간 광고 지면 입찰(Real-time bidding) 등을 통해서 경쟁을 시킨다던가, 애드 네트워크(Ad-network)를 통해서 광고와 지면을 최대한 모은 뒤 활용하기도 하죠.
이 와중에 양쪽을 모두 만족시킬 수 있는 방법은 뭐가 있을까요? 바로 광고의 효율을 높여주는 것입니다. 광고주의 궁극적인 목표는 ‘광고 집행’이 아니라 광고를 통한 구매와 같은 전환, 즉 컨버젼(Conversion)에 있으니까요. 광고를 한 번 보여줄 때 단가가 좀 높을지라도, 전체 지출한 광고 비용 대비 얻은 매출(ROAS, Revenue Over Ad Spending)이 높으면 기꺼이 더 높은 금액을 지출합니다. 조직은 정말 가끔을 제외하고는 합리적인 존재니까요. 퍼블리셔 입장에서도 각 광고 노출을 최적으로 할수록 단가가 높아지니 효율이 높으면 행복해집니다.
광고 효율은 어떻게 높일 수 있을까요? 어제 이커머스 사이트에서 검색했던 제품이 어디를 가나 따라다니며 등장하던 경험 있으시죠? 관심 있는 제품을 다시 보여주면 구매 확률이 높아진다는 광고 상품(리커머스, Recommerce)의 효율이 어느 정도 검증되었거든요. 사용자를 알면 알수록 어떤 광고를 보여줬을 때 전환 가능성이 높을지 더 잘 측정할 수 있습니다. 이를 위해 두 가지 문제를 해결해야 하죠
사용자를 어떻게 잘 알 수 있을까
사용자 정보를 바탕으로 어떻게 광고를 선택해야 할까
사용자를 어떻게 잘 알 수 있을까요? 사용자를 추정하고, 활동을 기록하면 됩니다. 참 쉽죠? 이를 위해 핑거 프린팅(Finger printing), DMP(Data Management Platform) 구성, 사용자 관심사 분석, 트랙킹 픽셀(Tracking pixel) 등 다양한 기술이 필요합니다. 정보를 바탕으로 관심사를 추출하는 기술 역시 이에 포함됩니다. 이 중 하나의 분야만 집중적으로 수행하는 회사들도 꽤 많을 정도입니다.
정보가 모였으면 다음은 추천이죠. 정보를 바탕으로 언제 어떤 광고를 보여줘야 최적의 효율을 만들 수 있을지 고민해야 합니다. 사용자가 어떤 콘텐츠에 반응을 보였는지, 해당 사용자와 비슷한 사용자들은 어떤 관심사를 좋아하는지 등의 정보를 바탕으로 최적의 광고를 찾아내죠. 추천 기술은 역사가 꽤 깊은 기술이면서도 여전히 머신러닝 기술이 빛을 발할 수 있는 정말 중요한 분야입니다.
광고가 잘 노출되었다면, 광고의 효율을 잘 측정하는 것도 중요하겠죠. 일단 보여주고 “잘 됐겠지” 생각하는 것은 모든 시험 문제 답을 5번으로 찍어 놓고 “이 정도면 괜찮겠지” 하는 것과 비슷합니다. 최소한 몇 번 답이 가장 많이 나오는지 정도는 되돌아봐야 다음번 찍을 때 성적이 오르죠.
좋은 사용자에게 적절한 광고를 보여줘도 어떤 이미지를 보여주느냐에 따라서 효율이 달라지기도 합니다. 어떤 지면(배너, 콘텐츠 사이, 비디오 중간 등)에서 보여주느냐에 따라서도 아주 다르죠. 심지어 언제 보여줘야 최적의 효율인지도 다릅니다. 최적의 효율을 내려면 A/B 테스팅은 필수입니다. 똑똑한 광고주는 효율을 높이기 위해 최선을 다하고, 애드 네트워크 등의 중간을 이어주는 업체는 이런 필요를 충족 시켜주기 위해 열심히 기능을 개발합니다.
버즈빌 비지니스의 복잡성
일반 사용자 입장에서 버즈빌을 바라보면 “잠금화면 앱 회사”라고 인식하게 됩니다. 한국과 일본에서 잠금화면 앱인 허니스크린을 운영하고 있고, 미국에서는 Slidejoy라는 이름으로 잠금화면 앱을 운영하고 있으니까요. 하지만 조금만 더 깊게 살펴보면 버즈빌의 비지니스 범위는 그보다 훨씬 더 넓습니다.
버즈빌은 SDK를 만들어서 비즈니스 파트너에게 제공함으로써 서플라이 사이드의 역할을 맡고 있습니다. 퍼블리셔(i.e 파트너사)는 버즈빌 SDK를 자사 서비스에 설치함으로써 손쉽게 광고 지면을 추가하고 수익을 올릴 수 있죠. 퍼블리셔만의 잠금화면을 만들 수 있을 뿐만 아니라, 앱 내 혹은 외부에 다양한 형태의 광고를 추가할 수 있습니다. 이를 통해 버즈빌은 자사의 앱만으로 이루어진 사용자 풀이 아니라 더 넓고 다양한 프리미엄 사용자 풀을 구축할 수가 있죠.
또한 버즈빌은 많은 광고주와 직간접적으로 파트너십을 맺으면서 디맨드 사이드의 역할 또한 맡고 있습니다. 직접 계약을 통해 더 좋은 효율과 적절한 과금을 진행하기도 하고, 다양한 네트워크를 통해 더 넓은 광고주와의 접점을 가져가기도 합니다. 광고 효율이 높아야 하는 것은 두 번 강조해도 모자라죠.
다양한 퍼블리셔와 광고주를 서로 연결해주는 역할을 해야 하니 사용자와 광고를 적절히 연결해주는 것이 매우 중요합니다. 퍼블리셔마다 다르게 제공되는 정보를 취합하고, 사용자의 관심사를 추측하고, 적절한 시점에 관심이 갈만한 광고를 추천하려면 앞서 언급한 핑거프린팅, DMP, 추천, 효율 검증 등의 모든 기술과 데이터가 종합적으로 필요합니다. 그냥 있으면 되는 게 아닙니다. 정말 잘 해야 하고, 더 잘 해져야 하죠.
버즈빌이 가지고 있는 독점적인 장점 중 하나는 로열티 프로그램(e.g 포인트 시스템)을 활용한다는 것입니다. 견물생심이라고, 보통 사람이라면 백화점에 데려다 놓기만 해도 물건이 사고 싶어집니다. 저는 펀샵(funshop.com)에 들어가면 몇 시간 동안 나오지를 못해요. 사용자가 관심을 가질만한 광고에 적절한 포인트를 지급함으로써 사용자의 관심을 끌어올 수 있습니다. 버즈빌은 많은 내부 실험을 통해서 보상을 통한 광고의 효율을 검증했습니다. 구글 또한 이미 보상 비디오 광고(Rewarded Video Ad)을 서비스하고 있고, 더 나아가 보상 광고(Rewarded Ad)로 범위를 늘리려는 움직임을 보입니다.
헌데 이게 또 골치가 아파요. 앞서 말한 내용에 회색 영역(Gray area)이 꽤 많거든요. “사용자가 관심을 가질만한”게 뭘까요. “적절한 포인트”에서 ‘적절한’은 어떻게 정의할 수 있을까요. 포인트는 얼마나 자주 줘야 할까요? 이런 회색 영역들은 모두 연구를 수반한 기술이 뒷받침되어야 하죠.
애드 테크(Ad-tech) 회사로서의 버즈빌
지난 6월 약 90명의 모든 버즈빌 멤버와 함께 사이판으로 워크샵을 다녀왔습니다.포스퀘어(Foursquare)가 광고 회사로서 피봇함으로써 기울어지던 회사를 되살리고 성장 중인 것을 알고 계신가요? 핀터레스트(Pinterest)의 광고 관련 기술이 매우 뛰어나며, 페이스북이 페이스북 오디언스 네트워크(FAN, Facebook Audience Network)로서 광고 업계에서 매우 잘 나가고 있다는 것을 알고 계신가요?
버즈빌은 잠금화면 서비스를 운영할 뿐만 아니라, 로열티 프로그램을 적극 활용하고 독창적인 지면들을 소유한 높은 기술력을 가진 애드 테크 회사입니다. 눈에 보이는 가벼워 보이는 빙산 밑에 얼마나 크고 복잡한 것들이 숨어 있을지 먼 거리에서 넓게 바라보지 않는 이상 쉽게 알아차리기 어려운 법이죠.
그래서 아키텍트는 뭐 하는데?
애드 테크 분야는 슬쩍 봐도 스테이크홀더(Stakeholder, 이해당사자)가 많죠. 퍼블리셔, 광고주를 기점으로 광고 관리자, 지면 관리자, 광고 제작자, 데이터 관리자, 분석가 등 많은 사용자 그룹이 존재합니다. 사용자가 많은 시스템은 필연적으로 기능이 많아지고 복잡해질 수밖에 없습니다. 다들 바라는 게 정말 다르니까요.
복잡한 시스템일수록 소프트웨어 아키텍처가 중요해집니다. 시스템이 변화에 유연해야 하고, 관련 있는 것들은 비슷한 곳에 모으면서도 서로 다른 것들이 서로에게 너무 의존해 있으면 안 되죠. 제품군이 많아지니 재사용성에 대한 고민도 많아지고, 외부 파트너가 사용하는 API를 구성해야 하니 더욱더 깔끔하고 안정적인 개발이 중요해집니다.
아키텍트는 기술만을 보는 직군이 아닙니다. 비즈니스를 살피고 비즈니스에 필요한 기술이 무엇인지 파악합니다. 다른 글에서 얘기했듯 모든 경우에 적용 가능한 단 하나의 정답 따위는 없으니까요. 아키텍트는 비즈니스에 따라 전체적인 그림을 살펴보고 어떤 아키텍쳐가 적합할지 고민하고 실행해야 합니다.
아키텍트는 전체적인 서비스의 구성을 그리고, 서비스 사이의 통신 규약을 정하고, 서비스의 역할을 규정하거나 규정하는 규칙을 수립하기도 합니다. 서비스 간의 구성뿐만 아니라 서비스 내의 소프트웨어 아키텍쳐에도 관여하죠. 프로젝트에 따라서 어떤 아키텍처를 가져가는 것이 좋을지 프로젝트 멤버와 함께 고민하고 논의합니다. 클린 아키텍처를 어떻게 적용해야 할지, 서버리스가 적절할지, MVVM, MVI, RIB 등 어떤 아키텍처를 적용할지, 리액티브 프로그래밍을 어디에 어떻게 활용할지, 서비스 메시는 무엇을 써야 할지, e2e 테스트는 어떻게 수행할지 같은 수많은 고민과 결정 사항들이 놓여 있죠.
또한 아키텍트는 사내 교육 역시 고려해야 합니다. 소프트웨어 엔지니어와 함께 올바른 방향으로 나아가기 위해 아키텍트는 계속해서 방향을 찾고, 공유하고, 함께 논의하고, 진행 상황을 점검하고 이를 다시 반복해야 합니다. 아키텍트 없이 엔지니어만 있으면 열심히 달리는데 방향이 자꾸 엉뚱해질 수 있고, 엔지니어 없이 아키텍트만 있다면 방향은 명확한데 당최 걷지를 않을 수도 있으니까요.
마치며
아키텍트의 일은 목표 지점까지의 도달이 짧은 시간에 이루어지는 것도 아니고, 그 일들이 당장 사용자에게 직접적으로 맞닿는 분야도 아닙니다. 전사적인 공감대와 지지가 없다면 흐지부지되기 쉬운 분야이기도 하죠. 그럼에도 아키텍트의 역할은 서비스와 시스템이 더 크게 성장하기 위해 필수적이며, 엔지니어링의 체질을 건강하게 유지하는 기반이 됩니다.
이 글이 조금이나마 소프트웨어 아키텍트의 역할을 이해하는 데 도움이 되기를 바랍니다. 앞으로도 많은 이해와 깊은 응원 부탁드립니다!
