조직이 커질때에 엔지니어링 속도를 유지하는법

요즘 '구글 엔지니어는 이렇게 일한다.' 라는 책을 읽고있는데, 조직 성장 관련된 챕터를 읽다가 이 책에서 추구하는 조직의 방향성과 비슷한 글이 있어 공유합니다. 👨‍🔧 최고의 엔지니어를 고용하기 좋은 엔지니어들은 좋은 사람들을 따라다니며 팀원을 같이 성장하게 하는데 도움을 줍니다. 최고의 엔지니어를 모셔오기 위해서는 커피챗을 몇 달동안 해야하는 상황이 생기는데, 이러한 과정도 성장에 매우 중요한 요소입니다. 초기 단계 스타트업은 매우 빠르게 움직여야 하고, 실수를 용납할 수 없기에 더더욱 최고의 엔지니어가 필요합니다. 개발도 중요하지만 비즈니스를 이해하고 고객 중심적이며 기업가정신에 열정적이고, 그들이 어떻게 일해야 하는지 이해하는 사람을 고용해야합니다. 처음 시작할 때에는 아름다운 코드를 구현할 여유가 없다는건 당연하다는 걸 이해해야 합니다. 짧은 시간안에 다양한 가치 제안을 시도함으로써 고객에게 가장 가치있는 것이 무엇인지 파악해야 합니다. 👨🏼‍💻 첫날부터 장기로 유지될 아키텍쳐 기반을 구축하기 대규모 엔지니어링 속도의 가장 큰 걸림돌은 견고하고 일관된 토대가 없다는 것입니다. 이러한 방식은 팀이 급격한 성장을 시작할 때, 기반을 버리거나 다시 아키텍쳐를 구성해야 하는 비용을 겪을 수 있습니다. 견고한 아키텍쳐를 구축하려면 먼저 엔지니어링 팀이 확장하는 데 중요하게 생각하는 우선순위를 명확히 결정해야 합니다. 예를 들어 우리가 신생기업일 때부터 테스트 코드를 작성하고 코드 리뷰를 수행하고 있었습니다. (물론 주변에서는 다들 놀라지만요.) 그러나 이러한 과정이 없었다면 우리팀은 잘 운영될 수 없었고, 이후 빠르게 성장하고 많은 엔지니어가 추가되는 시점에는 이미 베이스가 잡혀있었기에 이후 온전히 고객 가치만 바라보며 성장을 높히는데 집중할 수 있었습니다. 💁 그래서 장기로 유지될 아키텍쳐는? 1. 언젠가는 제품 의사 결정을 위해 데이터가 필요합니다. 가능한 데이터 중심으로 가야합니다. 2. 초기 개발자가 잘 아는 프로그래밍 언어와 DB를 선택해야합니다. 3. 첫날부터 테스트 코드를 작성해야 합니다. 테스트가 없는 코드는 빠르게 레거시가 됩니다. 4. 첫날부터 코드리뷰를 해야합니다. 리뷰를 거칠 수록 품질이 보증되는 코드입니다. 😎 엔지니어링 지표를 측정하기 명확한 엔지니어링 지표가 없다면 팀의 성과와 노력을 어디에 집중해야하는지에 대해 무지할 것입니다. 팀별로 측정항목을 볼 수 있도록 대시보드를 구축해야 합니다. (KPI 스코어카드 지표관리) 👁 각 팀들을 작고 독립적으로 유지하기 (Pod 구조) 소규모 스타트업처럼 팀원에게 필요한 사명, 목표, 자원을 부여해야합니다. 그 목표를 달성하기 위한 전략을 파악하는 건 상위권자가 아닌 팀원이 파악해야합니다. 각 포드에는 명확한 리더가 있어야 합니다.