Inside AB180 인터뷰의 네 번째 주인공은 '에어브릿지 프론트엔드 팀' 입니다.

에어브릿지는 하루 기준 300만 대의 모바일 디바이스와 약 3,000만 개의 쿠키 데이터를 분석하고 있는 기여도분석 서비스(기여도분석 서비스가 궁금하시다면 » 모바일앱 마케팅에 어트리뷰션 툴을 사용해야 하는 이유) 입니다. 총 20명이 넘는 개발팀이 함께 일하고 있으며, 프론트엔드팀은 에어브릿지의 대시보드, 랜딩페이지, 이용가이드 등을 개발하고 있습니다.

대시보드는 일반적인 B2C 서비스에 비해서 다루는 정보량과 그 안에 들어가야할 인터렉션의 종류가 무궁무진합니다. 그렇기에 프론트엔드 개발자로서는 도전해야 할 과제의 난이도가 높고, 하드트레이닝을 통해서 개인의 성장 또한 가져갈 수 있는 환경이죠.

본 글에서는 에어브릿지의 프론트엔드 팀이 어떻게 일하고 있는지 기술스택, 테스팅, 로그 수집 및 모니터링, CI/CD, 협업, 코드리뷰 및 회고, B2B 대시보드 개발 특이성 – 7가지 분야로 나누어 아주 상세히 소개해드릴 예정입니다. 들려드리고 싶은 이야기가 아~~주 많으니, 현재 프론트엔드 개발자이시거나 프론트엔드 개발에 관심이 있으시다면 아주 흥미롭게 살펴볼 수 있으실거에요 👀✨

🌟프론트엔드 팀은 함께 일할 동료를 공개적으로 찾고 있습니다. (산업기능요원 현역 T/O 보유)🌟
프론트엔드 개발팀 지원하러 가기 ▸

1. 기술 스택

에어브릿지는 많은 모던 Web Application들과 같이 JavaScript(ESNext)를 언어로 사용하며, UI 구성을 위한 라이브러리로 React를 사용하고 있습니다.

Vue.js 등 많은 최신 기술들이 있음에도 React를 선택한 이유는, 크게 생태계적인 측면과 에어브릿지의 기술적 요구사항 때문입니다.

개발 생태계의 경우, 기술을 활용하는 것에 있어서 (1) 얼마나 많은 개발자들이 Active하게 논의하는지, (2) 얼마나 많은 오픈소스 프로젝트 들이나 라이브러리들이 제공되고 있는지의 2가지 요소로 이뤄져 있습니다. 사용자 경험을 극대화하기 위해 React 커뮤니티가 새로운 방법론들을 제시하는 것이 좋았습니다.

기술적 요구사항의 경우, 에어브릿지는 애널리틱스 대시보드의 특성상 데이터의 양이 많고, 화면이 많이 변화합니다. 약 3년 전 Meteor를 통해 MVP를 개발한 후, AngularJS 등을 대안으로 검토한 바가 있습니다. 그러나 AngularJS의 2-way binding의 경우 (그리고 Meteor의 경우 심지어 DB까지 클라이언트와 동기화) 빠르게 Web App을 개발하는 것에는 적당하지만, 많은 데이터가 들어올 경우 성능의 문제가 발생하는 것을 여러 차례 경험하게 되었습니다.
단방향 흐름으로 데이터를 제어하고, 많은 데이터를 빠르게 DOM에 매핑, 업데이트할 수 있다는 측면에서 React를 선택하였습니다.

Developer Survey Results 2019 - Stack Overflow

Stackoverflow의 2019년 Survey에 따르면 React는 Professional Developers 사이에서 AngularJS에 이어서 근소한 3위를 차지하고 있기에 믿을 만한 생태계를 구축해나가고 있다고 봐야겠지요.

또한 에어브릿지에서는 React 생태계와 연결된 여러 라이브러리나 기술들을 사용합니다. Redux가 전역 상태 관리 저장소로 기능하고, 중간에서 미들웨어로 Redux-Saga를 써서 API 통신 등 데이터 흐름을 제어하는 역할을 하고 있습니다.

또한 협업과 안정성 향상 관점에서 Immer와 TypeScript를 도입하기 위한 준비를 하고 있습니다.

2. 테스팅

보통 테스팅과 관련된 내용이 나오면, TDD나 BDD 등 여러 방법론이 나옵니다. 에어브릿지의 기능이 많아질 수록, 에어브릿지에서 처리하는 데이터의 양이 많아질 수록 테스트의 중요도 역시 높아지게 됩니다.

다만, 현재는 빠른 제품 개발을 통해 PMF(Product-Market Fit)를 맞추는 것이 더욱 중요하다고 판단하여, 일부 Test-driven한 개발을 희생하고 개발 속도에 무게를 싣고 있습니다.

에어브릿지는 Cypress를 사용하여, 사용자가 실제로 클릭하고 행동하는 것을 mocking하는 Smoke test를 작성합니다. Cypress는 특정 branch에서 master를 향한 풀리퀘스트(PR)가 열리고, 내가 해당 branch가 있는 Remote Repository를 향하여 새로운 commit을 push할 때마다 자동으로 CI workflow 내에서 돌아가게 설계되어 있습니다.
개발자는 새로 개발하거나 수정하는 기능에서 어떻게 동작하는 것이 Happy path인지를 작업 시작 전에 미리 정의하며, 기능적 장애가 발생한 사항에 대해서도 관련 동작을 테스트 코드에 추가합니다. 이를 통해 쌓인 시나리오들은 특정 기능의 증가분이 붙는 것과 상관없이 사용자의 사용 시나리오를 보장하고, 동일한 문제가 다시 발생하지 않도록 막는 역할을 합니다.

또한 컴포넌트 별로 기초적인 Unit Test를 작성하고 있습니다. Unit Test를 작성하는 이유는 서비스의 안정성 향상 측면도 있지만, 의외로 개발자간의 상호 협력을 위해서도 필요하다고 생각합니다. A가 만든 컴포넌트를 B가 사용할 때, 이 컴포넌트가 무엇이며, 어떤 값을 어떤 방식으로 넣어야 의도한대로 나오는지 아는 것이 중요하기 때문입니다.

3. 로그 수집 및 모니터링

에어브릿지는 장애 발생시 정확하고 빠르게 에러를 확인해 대응하고, UI / UX 디자이너분들과 제품을 개선하기 위해 다양한 로그를 수집합니다.

에러 수집의 경우 logger 툴로 Sentry를 사용하고 있으며, 사용자 행동 수집용으로는 LogRocket을 사용하고 있습니다.

프론트엔드 팀에서 로그를 수집할 때, 중요하게 생각하는 것은 개인정보보호와 로그 체계화를 통한 액션아이템 수립입니다. 우선, 개인 및 기업의 중요한 데이터를 다루는 애널리틱스 대시보드에서 GDPR 등의 규제를 어기지 않도록, 개인정보를 배제하고 순수하게 사용자 행동만을 분석할 수 있도록 어떤 데이터를 수집할 것인지 항상 고려합니다.

또한, 수집된 로그를 바탕으로 사용성이 떨어지거나 장애로 인해 불편함을 겪는 사항을 점검하고, 이를 개선하기 위한 단기 / 장기적 액션아이템을 개발 팀뿐만 아니라 제품 개발 자체에 녹여낼 수 있도록 하는데 많은 고민을 하고 있습니다.

4. CI/CD

에어브릿지의 프론트엔드 팀은 CircleCI를 사용해 테스트, 배포를 진행합니다.처음에 CircleCI를 사용하게 된 큰 이유 중 하나는, 기존에 사용하던 Jenkins로는 작업 속도가 빨라지고 동시에 진행되는 작업의 양이 많아질 수록, 빠르고 병렬적으로 테스트를 진행하는 것이 성능 및 비용을 고려하였을 때 어려웠기 때문입니다.

Jenkins를 최적화하고 비용을 낮추기 위한 고민을 하는 것보다, 관련된 기능을 잘 제공하는 CircleCI를 사용하는 것이 결국 시간과 비용을 절약한다고 생각하였습니다. 현재는 이 decoupling 결정에 만족하며, branch 그룹 별로 각각 필요한 workflow를 구성하는 등 CircleCI를 잘 사용하고 있습니다.

5. 기획 및 디자인과의 협업

기획과 디자인 결과물은 프론트엔드 단계에서 정확하게 구현될 수 있어야 합니다. 여기에서 프론트엔드 팀의 작업 공수 효율화를 위해 보다 효과적인 개발 워크플로우가 필요합니다. 에이비일팔공 프론트엔드 팀 또한 개발 정확도와 효율화를 위해 많은 문제들을 마주해왔습니다. 그리고 수 차례 시행착오를 겪으며 아래와 같이 해결해왔지요!

<개발 정확도와 효율화를 위해 당면했던 대표적인 문제들과 해결안>

  1. 공통된 컴포넌트가 반복되어 발생하는 작업 비효율
    ⇒ 기획, 디자인, 프론트엔드 팀이 작업에서 사용하는 컴포넌트를 분류, 재 라벨링하여 개발 시 다시 활용할 수 있는 컴포넌트 리스트를 정리하고 같은 컴포넌트명으로 커뮤니케이션 할 수 있는 협업 환경 구축
  2. 새로운 스타일의 무분별한 발생으로 인한 예외 처리
    ⇒ 앞서 정리된 컴포넌트 리스트를 기반으로 기획 프로세스 진행, 예외 건 발생 시 모든 협업자 간 커뮤니케이션으로 컴포넌트 리스트 재정리
  3. 개발 정확도를 위한 협업자와의 대화 시간 소요 다대
    ⇒ 각 팀의 작업 과정과 툴 사용 시나리오 등을 공유하여, 협업 단계에서 이전 팀의 작업이 유연하게 연계될 수 있도록 함 (디자이너 팀은 Git을 배우고, 프론트엔드 팀은 디자인 스타일 요소에 대해 이해할 수 있는 시간을 마련해왔습니다)

개발 정확도와 효율화를 위해 두 팔 걷어 붙이고 협력하는 기획 및 디자인 팀이 에이비일팔공에 있습니다. 덕분에 불필요한 리소스를 줄이고, 완성도 있는 결과물을 위해 지속적으로 노력해올 수 있었습니다.

5.1. Pre-Sketch & 킥오프 미팅

우선 기획과 디자인 팀은 특정 기능에 대한 기획서가 나오면, 처음부터 Pre-sketch회의를 진행합니다. Pre-Sketch 회의에서는 초기 제품에 대한 Mock-up을 간단히 그리고, 그 Mock-up에 대해서 논의하는 시간을 가지는데요. 이를 통해서 기획 의도를 UX/UI가 싱크하는 과정을 거치게 됩니다.

프론트엔드팀은 이 회의에 참석해서 기획자의 기획 의도와 GUI 디자이너의 Mock-up 발전 방향을 함께 듣고 논의에 참석할 수 있습니다. 특히 이 과정에서 GUI 디자이너의 의도 자체가 많은 프론트엔드 팀의 리소스를 요구하는 일이라면, 미리 다른 대안이 없는지 함께 체크해보는 것도 리소스 절감에 있어 매우 중요합니다.

또한 Pre-Sketch 미팅을 통해서 어느 정도 결과물이 정해지면, 이에 대한 상세설계서가 UX 디자이너에 의하여 작성됩니다. 킥오프 미팅에 상세설계서를 보면서 어떤 화면이 어떻게 구성될지를 같이 논의하는데, 고민의 내용과 결과물에 대해서 듣고 개발하는 것은 향후에 QA 리소스를 절감해줄 수 있습니다.

개발자에게 중요한 것은 실력도 실력인데, 도메인 지식이 그만큼 중요합니다. 마케팅 관련되어서 어떤 이해관계자가 어떤 수요를 가지고 있고, 그것을 어떻게 표현하고 있는지를 아는 것이 중요한데, Pre-sketch와 킥오프 미팅을 통하여 작게나마 이러한 비즈니스 도메인에 대한 이해도를 높이는 것이 가능해집니다. 이는  프론트엔드 팀의 장기적인 동기부여에 도움이 됩니다.

5.2. 컴포넌트 시스템

상호간의 리소스를 최적화한다는 차원에서 UI/UX와 프론트엔드 팀이 컴포넌트 시스템을 구축하는 것은 매우 중요합니다.

현재 에어브릿지에는 매주 1차례의 회의를 통하여 디자이너와 개발자가 공통으로 발전시킬 컴포넌트를 정합니다. 또한 기존 컴포넌트 중에서도 개선이 필요한 컴포넌트가 있는지 확인합니다.

프론트엔드에서는 React 안에서 이를 하나의 컴포넌트로 관리하고, 디자이너분들은 스케치(Sketch)툴을 사용하여서 개발쪽 컴포넌트와 매칭된 공통 컴포넌트들을 관리합니다.

최근 에어브릿지에서는 개발을 모르는 디자이너가 개발을 배우게 되어, git 써서 수정하게 되고, 개발에서는 어떻게 코드 뭉치를 컴포넌트로 정의해서 관리하고 있는지를 배우게 된 과정을 발표하였습니다.

처음부터 컴포넌트 시스템을 쌓아올리기는 매우 어렵습니다. 그러나 이렇게 서로를 이해하는 과정에 전제된다면, 불필요한 리소스의 재사용을 막을 수 있을 뿐만 아니라, 더욱 효율적으로 협력할 수 있게 됩니다.

에어브릿지는 이러한 컴포넌트 시스템 구축을 통하여 결과적으로 목표는 우리 회사만의 스타일셋을 가지게 되는 것을 목표하고 있습니다.

5.3. QA 및 배포 준비

보통 QA는 3명의 담당자들을 정하여 수행하게 되는데, 여기서는 기획자인 CPO(PM)과 UI/UX 디자이너들, 그리고 CTO(혹은 팀장)이 참여합니다. 또한 에어브릿지 자체 QA 엔지니어와 함께 일하고 있기에 QA 엔지니어도 이 프로세스에 항시적으로 참여합니다.

프론트엔드 팀에서는 Black box QA를 기본 원칙으로 하고 있습니다. Black box QA 환경을 형성하기 위해서는 QA를 진행하시는 담당자들이 실제로 인터랙션을 해볼 수 있는 환경을 구축해주는게 중요하기 때문에 에어브릿지는 Sur.ge나 Netlify와 같은 라이브 배포 툴을 사용하고 있습니다.

그래서 라이브로 master에 배포하기 전에 어떻게 실제로 동작할지를 기획, 디자인, QA쪽에서 언제든지 확인할 수 있도록 도와줍니다.

기능은 단 한 번에 완성되지 않습니다. 따라서 몇 번의 iteration을 돌면서 실제로 사용자가 사용하는 것처럼 QA를 돌리고, 그 과정에서 나온 이슈와 개선 사항들을 처리하게 됩니다. 그리고 모든 QA 사항들이 반영되었을 때 최종 PR을 날리게 됩니다.

6. 코드리뷰 및 회고 문화

기본적으로 최종적인 코드 리뷰 이전에 이미 Black box의 QA가 진행된 상태고, 통상적으로 10개 이상의 개선 및 보완 요청이 들어올뿐만 아니라, 또한 당연히 Cypress의 Smoke test 시나리오들을 모두 통과해야 합니다. 그렇기에 PR이 날려진 순간에 코드 퀄리티는 최소한이 보장된 상태가 됩니다.

이렇게 최종 PR이 날려졌다고 가정할 때 해당 PR은 총 3명 이상의 Approve를 받아야지만 Merge 될 수 있습니다. 이 과정에서 자연스럽게 저희는 서로의 코드를 리뷰해주고 코멘트를 달아주고 있습니다.

때로는 치명적인 코드가 발견될 수도 있습니다. 이럴 때는 코멘트를 단순히 주는 것으로 멈추지 않고 Blocking을 걸어서 아예 그 문제가 해결되지 않고서는 Merge 자체가 안되도록 강제할 때도 있습니다.

한편, 저희 팀은 코드의 가독성을 매우 중요하게 생각합니다. 그렇기에 Airbnb의 lint 규칙을 가져와서 사용하고 있습니다. Airbnb의 lint 규칙은 매우 strict하게 된 편인데, 성능 향상보다는 코드의 가독성을 높이는 방향으로 구성되어 있어 좋다고 생각합니다. 또한 네이밍 컨벤션의 경우에도 이러한 원칙 위에서 지켜나가도록 노력하고 있습니다.

현재 회고는 일주일에 1회 팀 회고를 진행하며, 각자 한 주 동안 일을 하며 힘들었던 점이나 개선해야 할 점을 이야기하며, 서로의 어려움에 공감하고 액션아이템들을 수립하는 것을 목적으로 합니다. 다만, 현재 회고의 문제는 각각의 태스크들이 다소 추상적으로 다뤄진다는 것에 있기 때문에 장기적으로는 태스크 단위의 마이크로 회고 또한 실시하고자 노력하고 있습니다.

7. B2B 대시보드 개발의 특이성 : 빅데이터의 시각화

B2B 대시보드의 프론트엔드에서 가장 풀기 어려운 것은 많은 정보량을 어떻게 대시보드의 성능 저하 없이 효율적으로 보여줄 수 있을지의 문제입니다.

많은 정보량은 대시보드의 성능과 직결되고, 그 대시보드의 성능을 최적화 하는 것은 기술적으론 난이도가 높은 일입니다. 아무리 백엔드에서 가공해서 데이터를 준다고 해도, 그 양이 적지 않고, 또한 가공되지 않은 raw data도 내려올 때에도 있기 때문입니다.

이렇게 많은 데이터를 HTML에 그냥 DOM으로 그려넣는 순간 바로 대시보드가 버벅이게 됩니다. 따라서 이걸 어떻게 데이터를 나눠서 프론트엔드에서 보여주거나 가상화할 것인지, 어떤 도구를 써서 최적화를 할 것인지에 대한 문제가 항상 발생하며, 저희는 이를 최적화하고 있습니다.

두 번째로는 많은 양의 데이터를 ‘어떻게’ 표현해줄지를 해결할 때 생기는 기술적, 커뮤니케이션 요구사항이 많습니다.

애널리틱스 자체는 설정 자체도 커스터마이즈할 것이 많고, 데이터와의 인터렉션이 많습니다. 또한 이를 표현할 때 차트나 표가 많이 들어갑니다. 차트를 구성할 때 bar, sankey, line 등 다양한 차트 중에서 무엇을 고를지도 함께 고민해야 하며, 표를 구성할 때에도 fixed column이나 fixed row의 문제가 있으며, 스크롤을 내릴 때 이를 sticky하게 만드는 것과 같은 세부 사항의 구현이 필요합니다.

한편, 인터렉션을 구성할 때에도 어느 정도까지 인터렉션이 버벅이지 않고 구현될 수 있는지를 생각해보고 UX와 협의하는 과정도 필요합니다.

즉, 수정해야할 것도 많고, 고려해야 할 내용도 많습니다. 에어브릿지 프론트엔드팀은 이런 당면한 문제들을 해결하면서 성장할 수 있었습니다.

Fun Fact : 사내 React To-do-list 강의

여러 직군의 사람들이 같은 공감대를 가진 상태에서 합을 맞춰나간다면, 보다 빠르고 쉽게 원하는 목표로 나아갈 수 있다고 생각하고 있습니다. 조금이라도 보탬이 되기 위해, 프론트엔드 팀에서는 비정기적으로 React를 사용한 사내 교육을 진행합니다.

AB180 내의 많은 분들께서 프로그래밍에 관심을 가지고 계시기에, 교육 수요를 물으면 많은 분들께서 참여의사를 밝히십니다. 처음 프로그래밍을 접한다고 생각하며 기술적 내용보다는 하나의 주제를 같이 구현하면서 지식을 습득하는 방식으로 교육을 제작, 진행합니다.

가장 최근에 진행한 교육은 ‘나만의 TMI 퀴즈 만들기’입니다. 다른 사람들이 나를 얼마나 잘 알고 있는지 문제를 내고, 답에 대한 결과를 보여주는 웹서비스를 구현해 배포하는 과정을 진행하였습니다. 교육을 진행하며 각자의 생각하는 방식이나 응용 방법을 보며 저희 역시 자극을 받고 배우게 됩니다.

또한, 이런 교육을 통해 UI 디자이너분들도 코딩에 관심을 가지고, 실제 프론트엔드 개발 과정에서 마크업이나 스타일 작성을 직접해 Git에 커밋하는 등 프론트엔드 업무 능률의 향상에도 도움이 되었습니다.

Fun Question : 어떤 사람과 일하고 싶은지?

에어브릿지 프론트엔드 팀에서 가장 중요하게 생각하는 것은 ‘소통’입니다.

여기서 말하는 소통은 인간으로서 상호간에 존중을 바탕으로 시행하는 언어적 소통, 업무를 할 때 충분히 자신이 가지고 있는 컨텍스트를 가지고 있는 소통, 그리고 개발자로서 얼마나 가독성이 좋은 코드를 작성할 수 있는지입니다.

아무리 일을 잘하는 개발자라도, 그 분이 소통을 중요시하지 않는다면 그 분이 짠 코드는 서로 리뷰를 받기가 어렵고, 또한 향후에 그 분이 떠나고 난 뒤에 아무런 소용이 없이 legacy로 전락하게 될 것입니다.

한편, 소통을 하지 않는다면 B2B 제품을 만드는데 필수적인 도메인 지식을 얻을 수 없으며, 기획자와 UX/UI 디자이너의 컨텍스트와 의도를 이해하지 못하여 향후에 개발된 기능 자체가 엉뚱한 QA 요청들을 받거나, 타 직군에 계신 분들과 잦은 마찰을 일으킬 수 있습니다.

에어브릿지 프론트엔드 팀은 작더라도 점진적이고, 꾸준한 개선을 선호합니다. 함께 소통을 통하여 부족한 부분을 메꿔나가고, 서로 더욱 발전을 도모할 수 있는 좋은 동료를 기다립니다.

프론트엔드 팀은 함께 일할 동료를 공개적으로 찾고 있습니다.

blog banner pc
blog banner pc