큰 개발 조직
백엔드만 10명이 넘고, 프런트, 앱(안드로이드, iOS) 개발자, DBA, 데이터 관련 개발자, 시스템 엔지니어, QA 등까지 합치면 50명이 넘는 큰 개발 조직에서 백엔드 개발자로 1년 좀 넘게 일했다. 내가 일했던 곳 중 가장 큰 개발 조직을 갖고 있는 기업에서 퇴사하게 되어 이곳에서 경험과 시도를 적어본다.
경험
분업과 깊이
조직이 크니 당연하겠지만 각자 전문 분야가 있고, 그 해당 업무만 담당한다. 예를 들면 내 경우 백엔드 개발자로서 주로 서비스에 필요한 데이터베이스 테이블 모델을 설계하고 API를 개발하고 운영 이슈 등을 처리했다. 데이터베이스와 API 개발에 대해서 이전보다 깊이 있게 살펴볼 수 있었다. 일일 활성 사용자Daily Active Users(DAU)가 많은 서비스의 백엔드는 어떻게 개발하는지 파악하는데 큰 도움이 되었다. 깊이 있게 파기 보다 이것저것 폭넓게 경험하고 싶다면 큰 개발 조직은 안 맞겠다는 생각도 들었다.
코드 리뷰
코드 리뷰를 경험하고 싶었고, 어떤 효과가 있는지, 왜 꽤 큰 스타트업 개발팀에서는 코드 리뷰를 하는지 궁금했다. 어떻게 하면 더욱 효과적으로 코드 리뷰를 하고 개발 생산성도 향상 시킬 수 있을지 아이디어를 얻을 수 있었다.
속도
기업이 커질수록 당연히 서비스도 많아진다. 서비스가 많아질수록 관리하는데 많은 시간이 필요하다. 서비스 사용자도 많으니 안정성이 중요하다. 그래서 전체적으로 개발 속도가 느려진다. 새로운 기술을 적용하는 것도 느리다. 예를 들면 이슈 발생 가능성이 거의 없는 파이썬 포맷터 적용도 일부만 적용할 수밖에 없었다. 이슈 가능성에 대한 우려, 이슈 발생시 책임 때문에 주저하게 되기 때문이다. 왜 작은 스타트업이 기존 시장을 장악한 기업을 속도로 이길 수 있는지 이해할 수 있었다.
시도
위키 작성
입사 초기에 구두로 많은 설명을 들었다. 같은 것을 두 번 물어볼 수 없기도 하고, 누군가는 기록해두는 게 좋아서 듣는대로 위키에 기록해 두었다. 코드 리뷰 때 반복적으로 받은 리뷰도 기록하고, 새롭게 시도한 것들도 기록했다. 작성 및 편집자로 참여한 글은 300여개가 넘고, 개발 관련 위키글은 100개 이상 적었다. 내 다음에 입사한 다른 개발자로부터 내 위키 글이 큰 도움이 되었다는 이야기를 들었다.
QA(Quality Assurance, 품질 보증) 끝난 뒤 리뷰는 반영하지 않도록 제안
이미 최종 QA가 끝났음에도 팀 내에서 코드 리뷰를 했다. QA 부서로부터 배포 가능 버전이라는 확인을 받았는데, 리뷰가 이루어지고 코드를 수정해야만 했다. 전자제품을 예로 들면 품질 관리 부서한테 확인 도장을 받은 제품을 다시 뜯어서 부품을 갈아 끼우고 있는 것과 비슷한 상황이었다. 이런 리뷰는 배포 하루 전이나 직전에 주로 이루어져서 더 문제였다. 충분히 테스트할 시간도 없는데, 사소한 코드 개선인 경우가 많았고 코드 리뷰를 반영하다가 이슈가 발생했다. QA 뒤 변경하지 않았다면 이슈가 발생하지 않았을텐데, 코드 리뷰 반영 뒤 테스트를 충분히 하지 않았다는 이유로 담당 개발자 혼자 책임을 떠안아야 했다. 그래서 최종 QA가 끝난 뒤 리뷰는 바로 반영하지 않아도 되도록 제안했고 다행히 받아들여졌다.
개발 개선 안건 상정 제도 도입 제안
작은 개발 조직의 경우 CTO나 팀장이 개발팀 내 경력도 많고 지식도 가장 풍부한 경우가 많다. 그래서 CTO나 팀장이 모든 것을 결정해도 큰 문제가 없다. 하지만 개발 조직이 커질수록 팀장 등 관리자 직급은 관리 업무에 시간을 많이 쓰게 된다. 최신 기술을 분석하고, 어떻게 적용하면 좋을지 판단할만한 물리적 시간이 줄어든다. 이런 상태에서 과거 작은 개발 조직처럼 운영하게 되는 경우 팀원이 제안을 해도 CTO나 팀장이 거부하면 적용되지 못하게 된다. 기술적 제자리 걸음, 답보 상태에 빠지게 된다. 규모가 큰 개발조직의 발전을 위해서는 체계적인 안건 상정 및 논의 절차가 필요하지 않을까? 란 주제로 다른 팀원들과 얘기를 나눴고, 같은 문제 의식을 갖고 있는 팀원들과 함께 제안해서 안건 상정 제도가 팀 내 도입되었다.
예전이라면 쉽게 적용되지 못했을 테스트 자동화, 파이썬 포맷터 적용 등이 안건 상정 제도 도입 뒤 안건으로 상정, 통과되어 적용될 수 있었다. 답보 상태에서 벗어날 수 있었다. 예를 들면 다른 팀원이 팀 내에 파이썬 포맷터 Black을 적용하면 좋겠다고 거의 1년 전에 제안했다. 하지만 CTO나 팀장이 바빠서 잊어 버려 논의가 더 이상 진행되지 않았다. 안건 상정 제도 도입 뒤에 안건으로 올라왔고, 토론을 통해서 통과되었다. 안건 상정 제도가 없었다면, 언제 받아들여질지 알 수 없었던 제안이 안건 상정 제도를 통해서 금방 통과된 것이다.
테스트 자동화 도입 제안
안건 상정 제도 도입 이후 테스트 자동화 도입을 제안했다. 깃허브 워크플로우를 활용해서 코드 반영 요청인 풀리퀘스트Pull Request가 오픈 된 경우 테스트 코드를 자동 실행하는 방안이다. 리뷰어 입장에서는 일일이 해당 기능이 작동하는지 확인하지 않아도 되어 리뷰 시간이 절약된다. 리뷰어는 새로 추가된 테스트 코드를 통해서 어떤 기능이 추가 되었는지 명확히 판단할 수 있으며, 해당 테스트가 통과된 뒤에 리뷰를 시작하면 된다. 테스트 주도 개발 방식으로 개발하고 있는 팀원이 적어 전 프로젝트로 도입은 어려웠지만, 내가 담당하는 프로젝트부터 적용할 수 있어서 좋았다.
테스트 주도 개발 발표
테스트 주도 개발 방식으로 팀 내 모든 개발자가 개발하면 개발 생산성이 크게 개선될 거 같아, 전통적인 개발과 테스트 주도 개발, 그리고 애자일를 주제로 발표 및 실습 강의 준비를 했다. 2~3회로 나눠서 하고 싶었지만 기회가 주어지지 않아 1회 밖에 하지 못해서 아쉬웠다. 코드 리뷰보다 테스트가 더 중요하다고 생각하기 때문에 더 아쉬웠다. 테스트 기반 없는 코드 리뷰의 비효율성과 위험성 때문이다.
반복되는 코드 리뷰 가이드로 정리 제안
반복되는 코드 리뷰를 코딩 가이드로 정리하자고 제안했다. 가이드로 정리해두면 코드 리뷰로 인한 병목 시간이 확 감소할 것으로 예상되었기 때문이다. 제안은 안건 상정 제도를 통해서 통과되었지만, 실제 적용 효과까지는 제대로 살펴보지 못하고 나와 아쉬웠다.
타 부서 대상 생산성 향상을 위한 실습 강의 제안 및 진행
기획자분 요청으로 구글 스프레드시트를 활용해서 CSV로 된 원본 데이터를 입력하면 기획자분 원하는 형태로 데이터가 나오도록 만들어 드렸다. 퇴사하게 되어서 어느 정도 직접 수정할 수 있도록 가르쳐 드리는 게 낫겠다는 생각이 들었다. 인사팀장한테 혹시 생산성 향상을 위해 타 부서 대상으로 실습 강의를 진행해도 되냐고 문의한 뒤 괜찮다는 답변을 들어 스프레드시트 실습 강의를 진행했다.
관련 글
아래 글들은 위에 적은 경험과 시도 관련 글들이다.
일일 활성 사용자Daily Active Users(DAU)가 많은 서비스의 백엔드는 어떻게 개발할까?
규모가 큰 개발조직의 발전을 위해서는 체계적인 안건 상정 및 논의 절차가 필요하지 않을까?
테스트Test 기반 없는 코드 리뷰Code Review의 비효율성과 위험성