오늘학교는 어떻게 일주일에 한 번씩 새로운 기능을 넣을 수 있나요?(부제: DDD(Data-driven, Dev-Ops, Design System) 덕분에 10X 엔지니어링 조직으로 거듭나기)
안녕하세요. 저는 오늘학교 앱의 모바일 클라이언트 개발 업무를 하고 있는 Ed입니다.
아테나스랩 구성원은 목적 조직인 스쿼드와 기능 조직인 챕터에 이중으로 소속되어, 직군 간에 원활한 협업을 통해 고객에게 가치있는 기능을 빠르게 제공하기 위한 방법을 고민해왔습니다.
🔥 일주일마다 기능 업데이트하기
애플 앱스토어에는 앱 버전 기록을 확인할 수 있는 메뉴가 있습니다. (앱스토어에서 오늘학교를 검색 후 설치 페이지의 [새로운 기능] > [버전 기록]에서 확인 가능합니다.) 앱 버전 기록을 시간순으로 확인해 보면, 개발팀이 어떻게 기능을 추가하고 개발을 진행하고 있는지 유추해볼 수 있습니다.
아래 이미지의 오늘학교의 앱 버전 기록을 보면, 지난 1년 동안 대체로 주 단위로 기능이 출시가 된 것을 알수 있습니다. 이렇게 빠른 주기로 출시가 가능했던 것은 아테나스랩이 만들어온 협업 문화 덕분이라고 생각합니다.
저는 그동안 회사 내부에서 경험해왔던 아테나스랩의 협업 문화와 이러한 문화를 통해, 어떻게 아테나스랩이 일주일에 한 번씩 속도감 있게 새로운 버전의 앱을 출시할 수 있는지 적어보려고 합니다.
기능 개발을 위한 시간은 언제나 부족하기 마련입니다.😢 만들어낼 기능은 많은데 개발 속도는 더뎌, 초조하고 답답한 느낌이 들 때가 있습니다. 더불어 여러가지 장애와 긴급 상황에 대응하거나 운영 업무를 처리하다 보면 실제로 개발에 투입할 수 있는 시간은 생각보다 많지 않다는 생각이 듭니다. 그래서 가끔씩 터질만한 기능만 골라서 만들 수 있는 초능력(?)이 있으면 좋겠다는 생각을 하기도 합니다.
다른 사람보다 10배 이상의 가치를 만들어 내는 엔지니어를 우리는 10X 엔지니어라고 합니다. 아테나스랩 개발자는 팀 문화와 열정적인 동료 덕분에 다른 팀 보다 같은 노력으로 더 많은 가치를 만들어냅니다. 먼저, 기획챕터 덕분에 10X 엔지니어가 될 수 있었던 이야기를 해보려고합니다.
기획챕터 덕분에 10X 엔지니어 되기 : ① Data-Driven 의사결정
엔지니어의 리소스를 유효한 작업에 투입하실 수 있도록 기획챕터의 PO/PM 분들은 Google Analytics(이하 GA)와 데이터베이스의 데이터를 통해 가설을 검증하고 있습니다. 이 과정이 처음부터 원활하게 진행되었던 것은 아닙니다. 이전에는 모든 클라이언트 개발자가 “이 이벤트 도대체 어디에서 사용되는 건가요?”라는 질문을 하루에 몇 번씩 받아, 개발에 집중하기 어려웠습니다. 반대로 기획챕터에서는 기획에 필요한 데이터 확인이 어려워 기획이 늦어지는 문제가 발생하고 있었습니다. 애써 해당 이벤트가 어떤 역할을 하는지 코드 속에서 찾아내더라도, 코드 내에서 적절한 곳에 이벤트가 삽입되어 있지 않아 분석이 불가능한 경우도 많았습니다.
이를 해결하기 위해서는 앱에서 수집하고 있는 GA를 보다 쉽게 확인할 수 있어야 했습니다. 그래서 GA 이벤트와 이벤트가 집계되는 상황을 정리한 GA 핸드북을 만들기 시작했습니다. 이후 기획챕터에서 GA 핸드북을 사용하기 편한 상태로 한 번 더 재구성하여 현재는 쉽게 GA 핸드북을 사용하고 있습니다.
GA 핸드북을 재구성하는 과정에서 실제 수집 중인 데이터와 문서에 기재된 데이터가 일치하지 않을 수 있다는 점을 알게 되었습니다. 프로덕트는 지속적으로 변화하기 때문에, 처음에 작성한 플로우를 기준으로 작성된 문서가 현재 플로우와 맞지 않기 때문이었습니다. 그래서 기획챕터에서는 클라이언트챕터와 협업하여 GA 문서와 실제 수집되는 이벤트가 일치하는지 확인하는 작업을 진행했습니다. 이를 통해 잘못 수집된 데이터로 인해 정확하지 않은 수치로 의사결정이 이루어질 뻔한 아찔한 상황을 방지할 수 있었습니다. 이렇게 데이터를 쉽게 활용하기 위해 GA 이벤트를 정리하면서 데이터의 정확도도 함께 높일 수 있었습니다.
잘 정리된 데이터는 기획자의 좋은 의사결정을 돕고, 좋은 의사결정은 개발자가 더 임팩트 있는 기능 위주로 작업을 할 수 있도록 돕습니다. GA 이벤트를 확인하고 오류를 검증하는 일을 하면서 데이터에 기반한 의사 결정을 위해서는 다음과 같은 과정이 필요하다는 것을 알게 되었습니다.
Lesson Learned
1. GA 이벤트 네이밍 및 문서는 읽기 쉽게 구조화하는 것이 좋다. — 개발자, 기획자, 마케터, 운영, 경영진 모두가 쉽게 이해할 수 있는 형식이 좋습니다.
2. GA 이벤트 문서가 지속적으로 현재를 반영할 수 있도록 유지하기 위해서는 신규 기능 추가 / 기존 기능 변경 시 GA 문서를 업데이트 하는 개발 프로세스가 필요하다. —만약, 문서와 실제 수집되는 이벤트 간에 차이가 너무 많이 난다면 문서와 코드를 하나하나 대조해 보면서 동기화하게 됩니다.
3. GA에서 다른 데이터 수집/분석 도구로 쉽게 넘어가기(Ex. 핵클, 키네시스 등) 위해서는 클라이언트에서 GA 이벤트를 전송하는 모듈을 만들고 해당 모듈을 일괄적으로 호출하게 하는 것이 필요하다. — 더 좋은 분석 도구가 나오거나, 비용 상의 이슈로 인해 반드시 넘어가야 하는 시점이 옵니다.
* 모든 경우에 적용되는 것이 아닌 당시 상황과 비즈니스 맥락에 따른 교훈입니다.
디자인챕터 덕분에 10X 엔지니어 되기 : ② Design System
아테나스랩에는 디자인 시스템이 있어, 모바일 개발자가 퍼블리싱을 할 때 재사용 가능한 UI를 가져와 사용하는 경우가 많습니다. 디자인 시스템이 구성되어 있으면 일반적인 상황에서 클라이언트 엔지니어의 퍼블리싱 속도가 10배 가량 빨라집니다.
디자인챕터에서 작년에 디자인 시스템을 기획하고 제안해 주셔서 클라이언트챕터에서도 이런 디자인 시스템의 이점을 톡톡히 누릴 수 있었습니다. (디자인 시스템 구축에 대해서는 디자인 챕터의 Ken이 작성해주신 ‘디자인시스템: 협업의, 협업에 의한, 협업을 위한’ 블로그 글의 내용에서 자세하게 다루고 있습니다.) 클라이언트챕터의 개발 속도는 점점 빨라졌고 지금도 계속 기능 개발에 가속도가 붙고 있는데, 여기에는 디자인 시스템의 기여가 아주 큽니다. 뿐만 아니라 회사에서도 이 프로젝트를 적극적으로 지원해 주셨습니다. 이렇게 좋은 회사 문화, 높은 기준을 가진 동료들, 적절히 선택한 도구 등 여러 박자가 맞아 떨어질 때 선순환을 빠른 성장이 가능하다는 것을 아테나스랩에 와서 배우게 되었습니다.
다만, 디자인 시스템을 현재 프로덕션 코드에 적용할 때의 속도 조절이라는 이슈가 있습니다. 머지 충돌과 개발 리소스, 테스트의 어려움 때문에 앱의 모든 부분에 한 번에 디자인 시스템을 적용할 수 없기 때문입니다. 따라서 적절히 범위를 나누고 현재 개발 리소스를 체크하며 디자인 시스템 적용 속도를 조절해야 합니다.
디자인 챕터의 디자인 시스템 구성을 엔지니어링 관점에서 지원하며 아래와 같은 교훈을 얻게 되었습니다.
Lesson Learned
1. 디자인 시스템 모듈을 추가하는 것보다 기존 UI를 디자인 시스템에 맞게 변경하는 것이 훨씬 어렵고 오래 걸린다.
2. 디자인 시스템에 모호한 부분이 있을 경우에는 디자이너와 1:1로 같은 화면을 보면서 이야기하는 것이 도움이 된다.
3. 개발팀, 디자인팀, 기획팀이 동일하게 확인할 수 있는 최신화된 디자인 시스템 문서를 유지하는 것이 전반적이 제품 개발 속도 향상에 도움이 된다.
4. 디자인 시스템을 잘 구성하고, 디렉토리(또는 Repository)를 잘 분리하면 추후 다른 제품을 개발할 때에도 큰 도움이 된다.
5. 디자인 시스템을 구성하는 것은 엔지니어링 기술부채를 줄여준다.
* 모든 경우에 적용되는 것이 아닌 당시 상황과 비즈니스 맥락에 따른 교훈입니다.
팀 문화 덕분에 10X 엔지니어 되기 : ③ 데브옵스 문화
우리가 성취하고자 하는 목표를 잘 달성하기 위해선 팀원 간의 신뢰도를 높이고 문화를 가꾸어 나가기 위한 노력이 중요할 때가 많습니다. 우리는 개개인의 역량의 합보다 큰 시너지를 만들어내어 성장하는 스타트업이기 때문입니다.
칸반으로 대표되는 데브옵스 문화가 형성되어 있는 팀에서는 적절한 칸반 도구를 선정하면, 회사 전체가 마치 한 팀처럼 움직이기 때문에 성과를 달성할 수 있습니다. 또한, 서로 다른 도구 간에 적절한 연계를 통해 중복과 노이즈를 최소화하고 항상 최신화된 데이터를 전체 팀원이 볼 수 있게 하여, 높은 가시성과 투명성을 통해 회사 차원의 합리적인 의사 결정을 이끌어 낼 수 있습니다. 이렇게 데브옵스 문화를 꽃 피우기 위해서는 회사의 문화 역량이 필요하고, 아직 초기 스타트업인 아테나스랩의 문화는 팀원 개개인의 참여로 조금씩 그 모습을 갖춰나가고 있습니다.
온보딩 문화를 만들고, 회고를 통해 실수와 실패를 보완하고, 문제가 생길 때마다 아이디어를 모으는 회의인 “스워밍”을 통해 함께 문제를 해결해나가는 과정은 어쩌면 마법처럼 각각의 일을 한 번에 성사시켜 만들어진 것이 아니라, 팀 전체가 아테나스랩이라는 정원을 가꾸듯 모든 팀원의 꾸준한 관심과 수고가 모여 가능한 것이라고 생각합니다.
데브 옵스를 실천하며 아래와 같은 배움을 얻게 되었습니다.
Lesson Learned
1. 칸반은 개발자에게만 중요한 것이 아니라 CS, 마케팅 조직 등 운영 업무 위주로 돌아가는 팀에서 중요한 도구이다. — 프로젝트 위주로 돌아가는 팀에서는 간트 차트의 비중이 상대적으로 높은 편이다.
2. 여러 명이 작업할 때는 함께 업데이트하고 참고할 수 있는 단 하나의 문서가 도움이 많이 된다. — 정보가 이 곳 저 곳 산재되면 프로젝트 진행 속도에 지연이 생길 수 있다.
3. 문화나 제도를 정착한다는 것은 여러 번의 반복과 커뮤니케이션이 필요하다.
4. 실수를 인정하고, 투명하게 공유하는 문화를 위해서는 심리적 안정감과 동료의 지원이 필요하다.
* 모든 경우에 적용되는 것이 아닌 당시 상황과 비즈니스 맥락에 따른 교훈입니다.
Flutter 덕분에 10X 엔지니어 되기
기술 기반 플랫폼 비즈니스에서 중요한 요소 중 하나는 우리에게 적절한 기술을 선택하는 것입니다.
오늘학교 앱이 탄생하게 된 배경에는 마크라는 백엔드 개발자의 일화가 있습니다. 전해져 내려오는(?) 이야기에 따르면, 마크라는 서버 개발자가 Flutter를 학습하며 앱을 만들기 시작했던 것이 계기가 되었다고 합니다. 이렇게 개인과 팀의 학습 문화와 기술 결정이 전체 비즈니스의 방향을 바꿔놓을 수 있습니다.
사업의 성장을 위해서는 적은 비용으로 큰 가치를 만들어내야 합니다. 그래서 우리는 Flutter라는 도구를 선택했습니다. 이 도구를 사용하면 하나의 코드로 안드로이드와 iOS 두 가지 플랫폼에 대해 화면 및 기능을 구현할 수 있습니다. Flutter를 통해 각 플랫폼별 개발자를 각각 채용하는 비용과 별도의 조직을 유지해야 하는 비용 등을 줄일 수 있습니다.
또한, Flutter Framework는 skia라는 별도의 렌더링 엔진을 탑재하고 있어 네이티브 API에 구애받지 않고 UI를 그려줄 수 있습니다. 덕분에 디자인챕터에서 iOS, Android 동일한 시안으로 제작한 UI를 쉽게 구현할 수 있습니다.
Flutter로 개발하면 iOS, 안드로이드 다 알아야 하는거 아니에요?
Flutter 덕분에 개발 비용이 줄긴 했지만, 어려운 점도 있습니다. Flutter는 모바일 개발자와 일부 스타트업, 개발 대기업 등에서 인지도가 높으나, 아직까지 Flutter를 사용하는 앱 서비스가 많지 않고, 네이티브 기능이 Flutter로 지원되기까지 딜레이가 존재하며, Flutter SDK를 지원하지 않는 개발 서비스가 많습니다.
여기서 어려운 점이 발생하게 됩니다. 모바일 개발팀이 외부 업체의 부족한 Flutter 지원 이슈 해결을 위해 iOS 및 안드로이드 네이티브 지식도 공부면서 비즈니스 임팩트도 함께 만들어가야하는 것입니다. 바로 지난 주에는 카카오 모먼트 플랫폼이 네이티브를 지원하지 않아 직접 네이티브 코드를 작성해야 하는 이슈가 있었습니다. 이 글을 쓰는 지금은 앱 내에서 채팅을 지원하기 위한 SaaS의 푸시 관련 이슈로 인해 스위프트 코드를 작성하고 있습니다. 이처럼 iOS와 Android가 동작이 다르거나, Flutter 라이브러리가 지원하지 않는 기능의 경우 네이티브 코드를 직접 작성하는 것이 유리할 수 있습니다.
이렇게 다양한 기술을 습득하고 비즈니스 이슈를 잘 해결하기 위해서 우리는 신규 팀원의 빠른 Flutter 적응 및 꾸준한 학습 문화가 필요하다고 생각했습니다.
그래서 총 4단계로 이루어진 온보딩 과정을 만들기에 이르렀고 각 단계는 실행과 피드백, 그리고 셀프체크를 기본으로 하는 커리큘럼이 완성되었습니다.
좋은 앱을 만들려면 Flutter만 알면 되나요? 아테나스랩 개발자들의 끊임없는 탐구정신
좋은 제품을 만들기 위해서는 Flutter와 기술 지식 뿐만 아니라 다양한 직군과 협업할 수 있는 역량을 갖추는 것이 필요했습니다. 스타트업의 특성 상 이전에 경험해보지 못한 새로운 업무 방식이 도입되고 상황에 따라 업무 방식이 지속적으로 바뀌다 보니 팀원의 지속적인 학습이 무엇보다 중요합니다.
많은 경우 내부에서 경험해보거나 솔루션이 없는 이슈가 발생하기도 하는데 이런 경우에는 외부 커뮤니티와 세미나를 적극적으로 활용했습니다. 아테나스랩이 입주해 있는 프론트원에서는 디캠프 주관으로 다양한 세미나가 열립니다. 덕분에 모바일 개발자도 제품을 개발하기 위해 데이터를 활용하는 방법, 제품의 성장을 위한 전략 구성 방법 등 다양한 주제의 세미나를 들을 수 있고, 관련 세미나를 들은 팀원들이 클라이언트챕터로 세미나 내용을 공유해줍니다.
한 팀으로 일하는 회사
아태나스랩은 회사 전체를 한 팀이라고 부르고, 하위 조직은 챕터라고 부릅니다.저도 클라이언트 팀이 아닌 클라이언트 챕터의 개발자라고 불립니다. 아테나스랩에 합류해서 배운 점은, 좋은 제품을 개발한다는 것은 나 혼자만 잘해서 되는 것이 아닌 동료와 함께 팀을 이루어 달성할 수 있는 목표라는 것이었습니다. 그래서 아테나스랩의 10X 엔지니어란, 혼자 잘하는 엔지니어가 아닌 팀 공동의 목표를 달성하기 위해 서로 호흡을 맞춰나가며 사용자를 위한 제품을 만들어내는 엔지니어가 아닐까 하는 생각을 해봅니다.
저희 아테나스랩과 함께 성장하실 분을 찾고 있습니다! 🕶
좋은 서비스를 만드는 것에 더불어, 저희 아테나스랩과 더 나은 기술을 고민하고 서로 자극이 될 수 있는 조직을 만들며 성장하고 싶은 분들은 아래 채용 중 포지션 페이지를 참고해 주세요 🎉
채용 중 포지션 : https://prompie.com/s/alq3upis/
