Wonny
팀 빌딩부터 시스템 운영, 두 번의 대규모 장애까지
올해 2월, 디스콰이엇의 CTO 역할을 제안 받았다. MAU가 약 10만에서 꾸준히 성장하는 제품이 운영되고 있으나 기존 제품팀은 전원 퇴사하는 상황이었고, 디스콰이엇 팀은 올해 안에 PMF 찾는 것을 목표로 하고 있었다. 나에게 기대하는 역할은 대표인 솔이 PMF 찾는 일에 더 집중할 수 있도록 제품과 팀 운영에 대한 전반적인 책임을 가져가는 것이었다.
제품팀을 0명부터 꾸리고 제품을 통해 비즈니스 성과를 내야 한다는 부담과 책임이 무거운 역할이라고 생각했고, ‘CTO라는 거창한 역할을 맡게 되는 건 아닌지’, ‘이미 성과나는 제품을 망하게 하는 건 아닌지’와 같은 여러 불안한 마음이 들기도 했다. 하지만 그간 매니징을 하며 생긴 가설과 제품을 만들며 쌓아온 레슨을 검증해 볼 수 있는 큰 기회라고 느꼈다. 그래서 약간은 뻔뻔한 마음으로 나를 적임자라고 판단한 솔의 선택을 믿고 합류를 결정했다. (내가 부족하면 그건 다 솔 탓)
그렇게 3월에 입사를 하고 지난 수습 기간 동안 다양한 일을 했다. 2017년, 트레바리에 첫 번째 개발자로 입사하여 3년 동안 개발팀을 이끌었던 경험이 있으니 겪어본 상황을 반복하는 일도 많지 않을까 기대했지만 그렇지 않았다. 내가 바닥부터 새롭게 만든 제품을 운영하는 것과 3년의 기간 동안 여러 맥락이 쌓이며 규모와 복잡도를 키워온 제품을 이어서 운영하는 것은 난도 차이가 컸다.
그러다 보니 또 직접 때려 맞으며 새로운 경험을 하고 있고, 얻어맞으며 배운 게 아까워서라도 수습 기간 동안의 회고를 남겨보려고 한다. 각각의 꼭지들마다 여러 고민과 레슨이 있었는데 자세히 설명하기에는 글이 너무 길어져서 뭉뚱그린 부분이 많다. 나중에 추가적인 글을 쓸 거라고 미래의 나에게 미뤄본다. 🤤
팀 빌딩
CTO의 역할을 잘 해내느냐 아니냐는 원하는 기준 이상의 역량을 가진 동료를 빠르게 채용할 수 있느냐 아니냐에 상당 부분 달려있다고 생각했다. 입사한 날부터 당장 MAU 10만 짜리의 제품을 운영하며 올해 안으로 비즈니스 성과를 만들어야 했기 때문이다.
그래서 합류를 고민하기 시작하자마자 그간 같이 일하고 싶다고 찜꽁(?)한 분들 중 디스콰이엇과도 잘 맞을 거 같은 분들을 꼬시기 시작했다. 때마침 운좋게 탐나는 분이 지원하시기도 했다. 감사하게도 나의 꼬심에 넘어가주셔서 인턴으로 함께해준 오즈를 포함해 5명짜리 개발팀으로 수습 기간을 함께 보낼 수 있었다.
같이 일하고 싶은 동료의 기준은 명확했다. 1) 개발만 잘하는 게 아니라 일까지 잘해서 의미있는 성과를 만들 수 있는 사람, 2) 프로젝트를 리딩할 정도의 커뮤니케이션과 협업 역량이 있는 사람, 3) 맡은 일에 대한 주도성과 책임감이 강한 사람, 4) 글을 논리적이고 구조적으로 쓸 수 있는 사람이었다. 팀 규모를 작게 유지할 예정이기 때문에 더더욱 한 명 한 명의 역량이 중요했다.
실패 없는 빠른 채용이 필요했기에 그간 함께 일해봤거나 같이 스터디를 하며 이러한 기준을 충족한다고 느껴왔던 분들 위주로 모셨다. 덕분에 빠르게 목표했던 팀 문화를 조성하고 효율적인 협업이 가능했다. 또 모두가 주도적으로 프로젝트를 리딩할 수 있을 정도의 역량과 의지를 가지고 있던 덕에 예상보다 빨리 여러 실험을 병렬적으로 진행하는 팀으로 일하게 되었다.
팀 문화 조성
입사 후 가장 많이 신경 쓴 부분은 팀 문화였다. 내가 목표한 팀의 모습은 1) 서로 신뢰하고 친밀하여 심리적 안정감을 바탕으로 활발한 회고와 피드백이 오고가고, 2) 매일 최소 3깔깔 이상을 하며 즐겁게 일하고, 3) 맡은 직무의 하드 스킬 뿐만 아니라 자신의 강점과 관심사를 다양하게 활용하여 팀에 기여하고 성과를 내는 모습이었다.
팀 문화 조성을 위해 한 일은 다양한데 대략 이런 장치들을 만들었다. 1) 보다 편안한 커뮤니케이션을 도와주는 ‘ㅇㅇ님’ 대신 닉네임 사용 2) 디테일한 매니징 없이도 팀이 원활하게 돌아가게 도와주는 데일리/위클리 셀프 플래닝 및 회고 3) 팀 차원의 지속적인 성장을 위한 격주 팀 회고 4) 프로젝트와 팀의 헬스를 체크하고 싱크를 맞추는 리더십 위클리 미팅 5) 빠르게 팀/비즈니스/제품을 이해하도록 도와주는 온보딩 프로세스 6) 서로의 기대치 조율을 위한 수습 피드백 프로세스, 7) 매일 서로의 컨디션을 체크하는 데일리 체크인 8) 하루 3깔깔을 위한 활발한(?) 헛소리와 드립까지…
나름대로 목표한 팀의 모습에 근접했고 모든 팀원이 높은 만족도를 표해줬다. 이제는 잘 조성한 문화를 바탕으로 성과를 만드는 것에 집중하고 있다.
개발팀 문화 조성
개발팀 문화는 위생 상태와 비슷해서 한 번 좋은 환경을 경험하고 나면 나쁜 환경으로 돌아가기 어렵고, 좋은 환경을 경험해보는 것만으로도 알게모르게 수많은 행위들이 몸에 배게 된다. 강남언니에서의 성숙한 제품팀 문화와 여러 빠르고 안정적인 개발 방법론, 지난 창업에서의 구글 DORA 프로젝트를 바탕으로한 제품팀 코칭을 통해 생산성적인 개발팀 문화가 무엇인지 경험하며 익힌 게 많았고, 이 경험과 레슨들을 최대한 재현하며 개발팀 문화를 조성하고자 했다.
개발팀에서는 이런 변화를 만들었다. 1) 200줄 이하의 PR 단위, 가설 검증이 가능한만큼의 MVP 프로젝트 기획 등과 같이 모든 작업에서 가능한 작게 일하기, 2) Trunk-based development 브랜칭 전략 3) 하루에도 여러 번 변경사항을 운영 서버에 배치 4) 버그 관리 프로세스 5) Dual-Track Development 6) 엔지니어가 주도하는 인수 테스트 7) 지표 중심 프로젝트 8) 도메인 중심의 아키텍처 설계 9) 모니터링 도구 정상화 10) 이벤트 텍소노미/보편 언어 딕셔너리/시스템 비전 등 문서 작성 및 문서 작성 일상화 11) 인프라 변경을 통한 CD와 테스트 환경 개선 등.
생산성을 위한 아주 기본적인 환경과 프로세스를 갖추었다. 개발팀 문화를 만들 때는 보통 기존 팀의 관성을 깨는 게 어려운데 모두가 새로 입사한 상황인 덕에 관성이랄게 없어서 비교적 수월하게 안착한 거 같다. 하지만 아직 컴파일 속도, 테스트 자동화 등 DX 측면에서의 아쉬운 부분들과 팀 차원의 협업 경험 부족과 사용하는 개발 스택들의 능숙도 낮음 등의 과제들이 남아있다.
시스템과 제품팀 운영
LLM 활용이 보편화된 이후 더더욱 코딩 자체 보다는 비즈니스와 제품, 팀의 특성에 맞는 적절한 기술을 선택하고 시스템을 구성하는 게 성과를 내는데 더 효과적인 일이라고 생각한다. 그래서 입사하고부터 비즈니스와 제품, 팀의 특성을 파악하며 그에 맞는 기술 스택과 시스템 청사진을 하나씩 그리기 시작했다. 또 그에 맞게 제품 개발 프로세스를 다같이 같이 맞춰나가고 있다.
모든 팀이 그렇겠지만 속도와 안정성 모두를 챙기는 게 중요했다. PMF를 찾기 전의 팀이기 때문에 빠른 실험이 가능해야 하면서도 MAU가 10만 정도가 되는 제품을 안정적으로 운영해야 하는 상황이기 때문이다.
그래서 전체적으로 사용하는 언어와 기술을 통일해나가고, 프론트엔드에 더 강점이 있는 팀 구성을 살리면서 개발 속도를 높이기 위해 Next.js와 Supabase를 사용한 프론트엔드 엔지니어링 중심의 풀스택 개발 방식을 시도해보고 있다. 각 프론트엔드 개발자가 프로젝트를 리딩하면서 DB 설계나 서버 아키텍처 등의 백엔드 작업이 헤비한 경우에는 백엔드에 더 무게를 가진 팀원이 여러 프로젝트를 서포트하고 있다.
또 인턴인 오즈와 함께 2개월 동안 shadcn/uI 컴포넌트에 디자인과 몇몇 기능을 추가하여 빠른 마크업을 도와주는 UI Component들을 구현했다. SNS/커뮤니티 제품인만큼 앱이 필요하다고 느꼈고 프론트엔드에 무게가 있는 팀이니 React-Native와 Expo를 활용한 기존 반응웹 제품을 패킹한 앱도 준비하기 시작했다.
그 외에는 코딩 외에 필요한 운영 리소스를 최소화하기 위해 테스트 자동화와 Feature Flag 등을 도입하여 CI/CD를 개선하고 있고, 팀 차원의 전체 학습 비용을 낮추기 위해 주요 기술마다 스페셜리스트 제도를 운영하여 각 기술에 대한 전문성을 쌓고 공유하는 책임을 나눴다. 컨벤션과 자주 코딩하게 되는 패턴의 Best Practice를 정의하는 등 코딩 시 자잘한 고민을 줄여 개발 속도를 높이는 걸 조금씩 챙기고 있다.
크고 작은 사건사고들
모두 순조롭게 진행되지는 않았다. 크고 작은 사건사고들이 있었고 다사다난했다. 가장 끔찍했던 두 사건을 꼽아보자면 4월 6일부터 4월 11일까지의 간헐적으로 로그인이 실패하는 장애와 4월 26일의 AWS 전체 중단 사태가 생각난다.
첫 번째 사건은 입사한지 한 달이 되었을 즘에 약 6일 정도 간헐적으로 로그인이 실패하는 장애가 발생했던 일이다. 모니터링 시스템이나 프로세스를 미리 챙기지 못했던 터라 해당 장애가 발생했다는 사실을 장애 발생 시작 후 4일이 지나서야 알게 되었다.
그동안 신규 가입자 수 지표가 1/4토막으로 뚝 떨어졌고, 인지한 시간부터 개발자 전원이 이틀동안 장애를 붙잡고 씨름을 했다. 이때 처음으로 기존 시스템을 대대적으로 파악하기 시작했다. 간헐적으로 로그인 API가 실패한다는 현상만의 정보로 트러블 슈팅을 해야 하는 상황이었기 때문이다. 이때 진작 인프라랑 시스템을 더 파악해둘걸 하는 아쉬움이 컸다.
결과적으로는 내가 백업 데이터베이스 연결을 위해 변경했던 라우팅 테이블 설정 때문에 일부 서브넷에서 외부 요청을 받지 못하는 문제였다. 이것저것을 뒤져보다 팀원인 진이 에러 발생의 정확한 시작 시점을 찾게 되었고, AWS Trail를 통해 그 시간대에 변경된 인프라 설정을 발견하여 원인을 파악하고 해결할 수 있었다. 지금 생각해보면 장애 현상상 당연히 네트워크 설정부터 찾아봤어야 했는데 그때는 아직 파악하지 못한 시스템에서 알 수 없는 장애가 발생한다는 사실에 당황하여 더 허둥됐던 거 같다.
이때의 일로 팀 전체가 회고하면서 기존 시스템을 이해하는 게 시급하다는 인식을 공유했고 5주 가량 기존 시스템을 파악하고, 시스템의 안정성을 높이기 위한 일들을 진행하였다. 이 기간 동안 다같이 모니터링 방법과 CI/CD를 개선하는 것부터 자잘하게는 안 쓰는 코드를 제거하는 일까지 80여개의 작업과 100여개의 버그를 해결하였다. 그 결과 5주 만에 시스템에 대한 이해도와 안정감이 팀 전체 평균 10점 만점에 2점에서 7점으로 높아질 수 있었다.
두 번째는 사용하고 있던 AWS의 모든 서비스가 약 한 시간 가량 중단된 일이었다. 원인은 AWS 요금 체납이었는데 입사하자마자 AWS의 비용과 4개월치 이상의 크레딧이 남아있다는 걸 확인했었기에 예상치도 못한 일이었다.
이슈를 해결하고 원인을 파악해보니 과거에 두 달 가량 AWS support 플랜이 사용됐는데 알고보니 AWS support 플랜은 크레딧으로 결제되지 않는다는 정책이 있었다. 하필 연결된 법인 카드가 퇴사한 분의 것이라서 3개월 동안 결제가 실패됐었다. 또 AWS 관리자 이메일이 퇴사자 개인 메일과 개발팀이 공용으로 사용했던 지메일로 설정되어 있어서 체납 알림 메일을 확인하지 못했다. 그 뒤로 또 한 번의 팀 회고를 통해 재발을 방지하기 위한 알럿 설정과 사용하고 있는 모든 SaaS와 비용을 파악하고 관리자를 개발팀 그룹 메일로 변경하는 등의 작업을 했다.
돌이켜보면 두 사건 모두 기본적인 걸 잘 챙기지 못해서 생긴 일이었다. 나의 미흡함으로 이걸 다 때려맞으면서 대규모 장애가 연달아 생겼다는 사실에 부끄러웠고, 지인들에게 버그 제보가 올 때마다 더 나은 제품으로 탈바꿈하겠다는 자극을 많이 받았었다.
마무리
수습 기간을 보내며 가장 뿌듯한 건 기존과 신규 멤버 모두 다같이 합세해서 팀 분위기와 만족도를 높일 수 있었던 것과 제품과 팀 운영의 많은 부분을 담당하면서 대표인 솔이 고민할 수 있는 시간을 늘려준 것이다. 내가 잘 적응하고 성취 경험을 쌓을 수 있게 도와준 동료들 덕이라 생각한다. 좋은 사람들과 하루 중 가장 긴 시간을 함께 웃으며 보낼 수 있음에 감사하다.
가장 아쉬운 건 중간에 개인적인 일들이 벌어짐과 동시에 감기에 걸리게 되어 3주 정도 일에 몰입하지 못했던 기간이 있었던 것이다. 또 아직 유저에 대한 이해가 부족하여 제품 기획에 어려움을 겪고 있는 것도 아쉽다. 그리고 시스템과 제품 지표을 더 민첩하게 모니터링하여 대응하지 못하고 있는 것은 개선이 시급하다고 생각된다.
앞으로는 위에서 언급한 기술적으로 아쉬운 부분들을 개선하며 꾸준하게 유저 인터뷰를 하며 제품을 기획하고자 한다. 또 채용 수수료 무료인 스타트업 채용 플랫폼이나 앱 런칭과 같은 제품적으로 도약할 수 있는 시도들을 시작했다. 아마 성공보다 실패하는 시도들이 훨씬 많겠지만 3개월 뒤, 6개윌 뒤에는 그 시도에서 레슨을 쌓아 성과를 더 잘내는 팀이 되어있을거라 믿으며 더 치열하게 달려보고자 한다.
