[개발자 원칙] 제어할 수 없는 것에 의존하지 않기_❸ 조직과 매니징에 적용하기

제어할 수 없는 것에 의존하지 않기의 마지막 연재 글입니다.

앞의 글 보기 : 0. 제어할 수 없는 것에 의존하지 않기

1. 사례) 코드 설계에 적용하기
2. 사례) 이직에 적용하기
3. 사례) 조직과 매니징에 적용하기 <- 이번 글

조직과 매니징에 적용하기

이번에는 인프랩 합류 후 이야기를 해보고자 합니다. 인프랩 합류 후, 처음 한 달 동안 어떤 특별한 액션을 하기보다는 기존 팀원들이 어떻게 일을 하는지, 사내의 프로세스는 어떻게 되는지 지켜보기만 했습니다. 퇴 사 전 들은 조언대로 “가서 바로 무언가를 하려고 하기보다는 1~2달은 가 만히 지켜만 봐라”를 실천한 겁니다. 의도치 않게 이 기간은 조직 내에서 ‘제어할 수 있는 것과 제어할 수 없는 것’을 분류하는 기간이 되었습니다. 당시에 제가 제어할 수 없는 것은 다음과 같습니다.

• 개발팀 전체의 연봉 테이블
• 개발팀 규모의 확장
• 기존에 같이 일해본 혹은 전 직장 분들의 합류
• 기존 서비스의 기술 스택 교체

이 글을 읽는 대부분은 이 4가지가 CTO가 제어할 수 없는 영역이라는 것에 동의하기 어려울 겁니다. 이는 인프랩이란 회사의 특수성에 기인했습니다.

• 회사가 20명이 될 때까지 한 번도 시니어 레벨을 채용한 적이 없던 조직
• 시니어는 조직 전체에 큰 영향을 줄 수 있다는 두려움

한 번도 리더급 시니어의 중간 합류를 경험해보지 못한 조직에서 CTO 합류는 기존 구성원들에게는 미지의 두려움을 주었습니다. 특히나 기 존 서비스의 기술 스택을 교체하는 일을 신뢰 관계가 전혀 없는 새로 온 CTO가 진행하면 기존 구성원들의 반발심만 키울 뿐입니다. 위 4가지 모두 제어한다면 전체적으로 큰 효과를 볼 수 있지만, 당장 제가 제어할 수는 없는 영역이라 생각되어 제가 제어할 수 있는 영역 위주로 신뢰를 쌓기 시작했습니다.

가장 먼저 진행한 것은 1 on 1 미팅이었습니다. 3개월 동안 1인당 최소 2회 이상씩 티타임을 가지며 이야기를 나누었습니다. 상호 유대감을 얼 마나 쌓아놓느냐가 일할 때 정말 중요하다는 사실에 누구나 동의를 하실 겁니다. 어떤 일을 하는 데 있어서 그게 설령 맞는 말이라도 누가 했느냐 에 따라 찬성 혹은 반대를 하기도 합니다. 기존 팀원들에게 제가 어떤 사람인지, 팀원들과 어떤 목표를 달성했으면 하는지, 각 팀원들의 꿈과 비 전은 무엇인지 등을 티타임을 가지며 이야기했습니다. 유대감이 쌓이고 난 뒤부터는 합류 시점에 대표님께 털어놓지 못한 개인적인 고민도 나눌 수 있게 되었습니다.

이 점에서 오히려 CTO로 합류하지 않고, 같은 팀원으로서 합류한 게 도 움이 많이 되었습니다. 처음부터 CTO로 합류했다면, 대표님 면담과 마찬 가지로 다들 자신의 속마음을 터놓고 이야기하기는 어렵지 않았을까 생 각해봅니다.

인간적인 신뢰를 쌓고 난 뒤에는 엔지니어링 영역에서의 신뢰를 쌓는 작업을 시작했습니다. (제어할 수 없는 영역인) 기존 시스템에 큰 변화를 주지 않으면서도 큰 효과를 볼 수 있는 영역으로 모니터링과 로깅 시스템 을 도입하기로 결정했습니다. 365일 24시간 서비스하는 조직에서 모니터 링, 로깅 시스템이 없다는 것은 어두운 산길을 후레시 없이 달려가는 것 과 다를 바 없습니다. 특히 모니터링/로깅 시스템이 없다는 것은 제품의 문제 해결 그 이상의 의미가 있습니다.

바로 ‘과거의 실수로부터 배우지 못한다’는 겁니다.

• 어느 시점부터 문제가 시작된 것일까?
• 이상 징후가 시작된 지점은 언제부터였을까?
• 우리 시스템의 트래픽 임계점은 어디까지일까?

당장 모니터링, 로깅 시스템을 도입하기보다 현재 상황을 먼저 정리하고 확인한 뒤에 당위성을 얻어서 진행했습니다. 이렇게 해야 저에 대한 조직의 신뢰가 더 쌓일 거라 믿었기 때문입니다. 과거의 장애 내역을 정리하고 공유하면서 현재 시스템이 얼마나 불안한 상태인지, 우리가 얼마 나 놓치고 있는 게 많은지 등에 공감대를 형성했습니다. 공감대가 형성된 이후의 일은 쉽습니다. 팀원들과 함께 빠르게 다음과 같은 일을 진행했습 니다.

• 데이터베이스 개선(Aurora PostgreSQL로 마이그레이션)
• 데이터베이스 쿼리Query 로깅 환경 구축 및 슬로우 쿼리 알람 -> 3초 이상 쿼리들에 대한 알람 설정과 발견된 슬로우 쿼리 개선
• 애플리케이션 모니터링 시스템 도입
• 필요한 알람과 불필요한 알람 정리

이 개선으로 서비스의 안정성과 구성원들의 신뢰를 회복할 수 있습니다. 다음으로 개선이 필요한 것은 구성원들의 성장이었습니다. 당시의 인프랩은 외부의 많은 회사가 선택한 기술, 아키텍처, 코드 컨벤션 등을 따르지 않고 독자적인 스타일을 유지하고 있습니다. 그동안 이를 통해서 회 사가 빠르게 성장했지만, 더 큰 규모의 팀이 되려면 결국 동시대를 살아 가는 개발자들의 흐름을 놓치지 말아야 한다는 것이 제 생각이었습니다. 독자적인 스타일은 양날의 검처럼 갈라파고스화가 될 위험도 있기 때문 입니다. 이후부터 개발 팀원 전체가 동시대성을 갖추기 위한, 성장을 위 한 일을 진행했습니다. 물론 이 과정에서도 제어할 수 없는 것은 존재했습니다. 구성원 본인의 성장하고자 하는 열망은 제가 제어할 수 없는 영 역입니다. 혹자는 성장에 대한 열정도 주변에서 심어줄 수 있다고 생각하겠지만, 저는 그걸 성공해본 적이 없습니다. 반면 제가 제어할 수 있는 영역은 다 음과 같습니다.

• 성장에 대한 열망을 가지고 있는 분을 과제와 면접을 통해 채용하기
• 성장에 필요한 과제와 환경을 제공하기
• 옆에서 지켜보면서 적절한 피드백을 전달하기

신규 채용에서는 열망이 있는 분만 뽑았습니다. 그런데 이미 합류한 분 들의 열망은 제가 제어할 수 없는 영역입니다. 운이 좋게도 인프랩의 모든 개발 팀원은 성장에 대한 열망을 가지고 있었습니다. 그래서 제가 제어할 수 있는 성장 환경에 집중할 수 있었습니다.

• 채용 과정에서 실제 웹 서비스를 만드는 과제 테스트 추가하기. 제출된 과제들을 팀원들과 함께 리뷰하면서 외부의 개발자들은 어떤 구조로, 어떤 형태로 코드를 작성하는지 자연스럽게 공유하기
• 앞으로 우리가 갈 길을 기존 개발자 분들에게 명시하는 방향으로 채용 공고 작성하기
• 신규 프로젝트를 새로운 기술 스택만으로 구성하기
• 개발팀 전체가 함께 하는 스터디 진행하기
• 주변의 좋은 시니어들과 팀원들과의 티타임, 미팅 등 주선하기

이런 과정들을 통해서 인프랩 팀은 좋은 코드가 무엇인지에 서로 비슷한 공감대를 형성하고, 테스트 코드를 작성하는 것이 당연해졌으며, 신규 기술 스택을 안정적으로 적용하고 사용합니다.

얼마 전 인프랩 개발팀에 첫 퇴사자가 발생했습니다. 개발팀이 7명에 서 26명이 될 때까지 1년 4개월 동안 퇴사자가 없다가 처음으로 발생한 것이죠. 첫 퇴사자를 경험한 개발팀 입장에서 당황하거나, 전혀 무감각하거나, “어? 나랑 비슷했던 저 친구도 저렇게 큰 회사를 간다고? 나도 해볼 수 있겠는데?” 같은 생각을 하는 팀원도 있을 수 있습니다. 빅테크 기업이 주는 연봉과 복지는 충분히 매력적이기 때문에 스타트업에서 빅테크로 이직을 고민하는 것은 당연합니다.

작은 개발팀을 꾸리고 있는 스타트업에서 빅테크로 이직하는 동료가 많으면 위기를 겪게 됩니다. 내실 있는 중소규모의 개발팀에서 빅테크의 사관학교로 포지션이 변경되는 위기 말이죠. 조금만 삐끗하면 입사 후 1~2년 차에 빅테크로 이직하는 조직이 되고, 1~2년 뒤에 빅테크로 이직하는 것을 목표로 하는 사람들만 입사합니다. 그래서 이런 상황이 발생하 면 CTO나 개발 리더 입장에서 스트레스를 적지 않게 받습니다.

이직이 처우 문제로만 국한되지는 않지만 연봉과 복지도 중요합니다. 그리고 성장은 꼭 지금 조직에서만 가능한 것이 아니므로 빅테크로 한 번 마음이 움직인 사람은 막을 수가 없습니다. 매니징하던 팀원이 빅테크로 이직하고 나서 싱숭생숭한 분위기의 팀을 리드하는 입장에서 ‘제어할 수 없는 것’과 ‘제어할 수 있는 것’은 무엇일까요? 다음은 제가 퇴사가 마무 리되고 난 뒤, 개발팀 스프린트 때 나눈 이야기입니다.

“처음 발생하긴 했지만, 우리 같이 작은 조직에서 빅테크로 이직한 사 람이 나왔습니다. ‘앞으로 더 많은 사람이 퇴사하면 어떡하지’라는 걱정 도 분명히 듭니다. 다만, 반대로 생각하면 이건 우리 개발 조직이 가지고 있는 개발자의 성장 방법이나, 문화, 프로세스 등을 우리보다 훨씬 큰 조 직에서도 인정한 사례나 마찬가지라고 생각합니다.

우리 방식이 정말로 좋은 방식인지 의심했던 사람이 있다면, 그런 의심 을 더는 하지 않아도 됩니다. 물론 한 명이 이직했다고 해서 우리의 방식 이 100% 좋은 방식이다라고 얘기할 순 없지만, 지금의 방식에서 계속 개 선해나간다면 어느 조직에서도 인정할 만한 개발팀, 개발자가 될 수 있다 고 봐도 될 것 같습니다. 큰 회사를 다녔던 제가, 여기 있는 분에게 스타 트업에서 일하는 것의 장점을 이야기하면 내로남불처럼 느껴질 수 있습니다. 확실하게 이야기할 수 있는 것은 전 직장은 제가 입사할 때까지만 하더라도 수많은 스타트업 중 하나였습니다. 퇴사하는 시점에 빅테크가 되어 있고, 그러다 보니 빅테크의 퇴사자가 된 것뿐입니다. 제가 폭발적 으로 성장할 수 있던 것은 스타트업이었던 조직이 빅테크로 성장하는 그 과정을 그대로 겪었기 때문입니다. 여기 계신 분들도 그 경험을 꼭 했으면 좋겠습니다.”

이 내용이 실제로 팀원들에게 어떤 효과를 냈는지는 당장은 알 수가 없 습니다. 미래의 인프랩 개발팀이 어떤 모습이 될지 이 글을 보고 계신 분 들도 같이 눈여겨봐주는 것도 재밌는 일이 될 것 같습니다.

규모가 작은 스타트업에서의 CTO는 전체 개발자의 연봉 테이블을 제 어할 수 없습니다. 회사의 매출, 투자 규모, 다른 직군과의 연봉 격차, 회 사의 연간 예산 계획 등 모든 것을 고려해야 하기 때문입니다. 만약 제가 제어할 수 없는 것에 계속 의존했다면 저는 다음과 같은 불만만 가득한 리더가 됐을 겁니다.

• 개발팀 연봉을 회사가 지원해주지 못해서 개발 팀원 퇴사를 막지 못했어!
• 연봉 테이블 전체를 못 올려주면 계속 퇴사자가 나오는 것은 어쩔 수가 없어!

회사의 매출, 영업이익 등은 지금 당장 제가 제어할 수 없는 영역인데, 당장 해결이 안 되는 영역을 원망해봐야 변하는 것은 없습니다. 그보다는 제어할 수 있는 ‘어떻게 하면 이 상황을 긍정적으로 해석할 수 있을까’를 고민하고 행동으로 옮겨야 합니다. 물론 회사가 부족할 때 함께 해준 팀 원들에 대해 정말 감사한 마음을 갖고, 점진적으로 충분한 보상을 해줘야 하는 것은 당연합니다.

《88연승의 비밀》에 다음과 같은 일화가 나옵니다.

“ 학교의 사정으로 다른 학교에서 경기를 치러야 하는 상황이 됐다. 베 니스 고등학교, 롱비치 시립강당, 롱비치 시립대학, 팬 퍼시픽 대강 당, 산타모니카 시립대학 등을 전전했다. 심지어 LA에서 160킬로미 터나 떨어진 베이커즈필드 전문대까지 가서 홈경기를 치른 적도 있 다. 우리는 수년 동안 홈 코트의 이점을 누릴 수 없었다. 나는 이 불 리함을 유리함으로 바꾸려고 운명이 부여한 상황에서 최선을 다했 다. 나는 선수들에게 이렇게 말했다. ‘장소를 옮겨 가면서 홈경기를 치르면 원정경기에 강해질 것이다. 다 른 곳에서 시합할 때의 산만함과 혼란스러움에 익숙할 테니까.’”

《88연승의 비밀》 중

제어할 수 없는 것에 집중하다 보면 그 무엇도 해결하지 못할 수 있습 니다. 제어할 수 있는 것에 의존하고 집중해야만 어떤 일과 상황을 만나 더라도 앞으로 전진할 수 있습니다. 제어할 수 있는 것과 제어할 수 없는 것을 구분한 뒤 제어할 수 없는 것을 멀리하고, 제어할 수 있는 것에 집중 하면 됩니다. 외부의 요소, 이미 발생한 사건, 결정권이 없는 일 등은 제 어할 수 없습니다. 이들에 의존해선 안 됩니다. 제어할 수 있는 것들에만 의존하도록 해야 합니다. 소프트웨어를 설계한다면 제어할 수 있는 속성 에 항상 의존하게 설계해야 하며, 현실 세계의 문제라면 현재의 사건과 환경을 어떻게 하면 더 유리하게 바라볼 수 있는지 고민하고 행동으로 옮 겨야 합니다.

저의 이 원칙이 여러분들께도 도움이 되었으면 합니다.

긴 글을 읽어주셔서 감사드립니다.