Tech Lead가 되는 과정
오랜만에 글을 씁니다. 서비스 출시하느라고 정신이 없었거든요.
그래도 서비스는 기대했던 것 보다 훨씬 잘 나와서 다행이에요.
Tech Lead의 역할
어느덧 Leader가 된지 1년이 되어갑니다.
전에는 서비스팀 팀장으로, 지금은 개발팀 Lead Developer로 일하고 있는데요.
케이스 바이 케이스긴 하지만, 개발 쪽은 신기하게도 팀장이 되어도 실무를 합니다. 관리만 하지 않아요. 그러다보니 일이 정말 많은데요.
테크리드는 크게 세가지 역할을 하게 됩니다. 매니저, 개발 리더, 개발자.
여기에 상황에 따라 기획이나 마케팅, 디자인까지 결정하게 되는 경우도 있어요.
Manager
관리만 하는 것도 얼마나 힘든지 관리직을 해보신 분들은 아실 겁니다.
특히 개발자들이 갑인 시대에 팀원들의 이탈을 예방하고, 함께 성장해서 성과물까지 만들어내야 하는 건 참 쉽지 않습니다.
일본 제조업에서 출발한 클래식한 리더십부터 미국 실리콘 밸리에서 출발한 트렌디한 리더십까지, 온갖 리더십을 공부하고 실전에 녹여본 경험이 있어도 항상 팀원과 회사 모두를 100퍼센트 만족시킬 수는 없거든요.
결국 여러 상황을 겪으면서 자신만의 기준이 세워지게 되고, 나만의 리더십이 생기는 것 같아요.
그렇게 관리자로서 조직 관리, 체계 구축, 일정 관리, 리소스 관리, 업무 분배, 채용, 평가, 외부 커뮤니케이션, 경영진과의 소통, 성과 보고 등 온갖 일을 하게 됩니다.
특히 스타트업은 체계라고는 출퇴근 밖에 없는 경우가 많아요. 없는 체계를 만들면서 조직원들과 회사가 안정적으로 받아들이고, 터득할 수 있도록 스텝 바이 스텝 적용시켜야 합니다. 교육도 해야 하고요.
Lead Developer
그리고 개발 리더로서의 일도 해야합니다.
정책 구성, 아키텍처 설계, 인프라 설계, 시스템 설계, 기술 선택, 코딩 컨벤션 작성, 코드 리뷰, 기술 교육 등의 일을 해요.
이렇게 글로 쓰면 별거 아닌 것 같지만… 정말 하나도 쉬운 게 하나도 없습니다.. -_-
토큰, 보안, 개인정보 관리 정책 등 이런 기본적인 것들도 여러가지 사례와 레퍼런스를 참고해서, 현재 우리 상황에 맞는 최적의 방법을 선택하고 구현해야 하거든요.
너무 쉽게 가면 유저 경험과 개발자들의 근로 의욕이 떨어지고, 너무 어렵게 가면 개발 시간이 오래걸려 시장 속도를 못따라 갑니다.
그 외의 일들도 쉽지 않아요. 아키텍처나 시스템도 너무 어렵게 설계하면 현재의 생산성이 떨어지고, 심한 경우에는 팀원들이 자괴감을 느끼기도 합니다. 그렇다고 쉽게 설계하면 미래의 생산성이 떨어지고, 유지보수가 어려워지거든요.
결국 개발일정을 맞출 수 있을 정도로만 어려우면서, 교육했을 때 팀원들이 잘 따라올 수 있고, 미래에 서비스가 커질 것을 예상하면서 scalable한 구조로 가야합니다.
그리고 선택할 수 있는 권한이 있다는 건 그만큼 책임도 따라옵니다. 때로는 내 선택 하나에 팀이나 회사가 위기에 빠질 수도 있거든요.
Developer
관리자, 개발 리더 역할을 하면서 개발 실무자로서 또 일을 합니다.
내 코드가 우리 팀의 레퍼런스가 되기 때문에, 먼저 개발해서 예시를 보여줘야해요. 그래야 팀원들이 내 코드를 레퍼런스 삼아 참고하면서 개발하거든요. 그런데 예시가 될 코드를 이상하게 짤 수는 없으니까… 그거에 대한 공부를 또 엄청 합니다.
어려운 기능은 직접 개발해야할 때도 있고요. 팀원이 개발하다 어려움을 느끼면 대신 해줘야 할 때도 있습니다.
이것 말고도 중요하다고 생각하는 부분이 또 있습니다.
바로… 내가 잘 모르는 분야에서도 문제해결을 해야한다는 것인데요.
오늘이 토요일인데, 저는 오늘도 일을 했습니다. 이유는 앱을 업데이트 하면서, 기존 유저와 업데이트 된 앱을 사용할 유저를 분기해서 처리해야하는데, hotfix에 집중하느라 실수로 인프라 쪽을 고려하지 않았다는 것을 어제 퇴근하고 발견했거든요. 그래서 다급히 인프라를 세팅해야 했습니다.
서비스 초기기도 하고, 시간이나 개발인력이 부족하다보니, 인프라를 삼중화한다거나 api gateway를 구현하지 않은 상황이었거든요. 결국 NLB Listener와 TLS port 설정만으로 문제를 해결 했습니다.
이런 경우 외에도, 플랫폼 사업자나 SDK를 제공해주는 쪽에서 실수를 하는 경우도 있는데, 그럼에도 불구하고 우리 서비스는 제공되어야 합니다. 그래서 버그가 수정 되기를 마냥 기다릴 수는 없는 경우도 있는데요. 이런 상황이면 경영진도 팀원들도 O_O 이런 눈으로 저를 바라봅니다. (나도 처음 겪어 본다고…)
나도 잘 모르는데 어떻게든 문제를 해결해야하는 대표적인 상황 같아요.
전설 속의 동물 Senior
예전에 제가 생각했던 시니어는 모르는 게 없고, 모든 걸 다 할 줄 아는 사람으로 생각했습니다. 다른 분야에 비해 개발자는 유난히 senior, lead 이런 이름에 부담이 큰 것 같아요. 그래서인지 ‘난 아마 평생 시니어가 되지 못할 거야’라는 생각을 갖고 살았습니다.
그런데 오늘 발생했던 이슈를 해결하면서 이런 생각을 했어요.
“대체 내가 어디까지 해야하지..?”
그러다가 문득 이런 생각이 들었습니다.
“음… 이렇게 살다보면 나도 모르는 사이에 언젠간 시니어가 되는 게 아닐까?”
지금 시니어 개발자들도 분명 처음부터 시니어가 아니었을 겁니다. 처음 선택했던 분야에서만 계속 일 하고 있지도 않았을 거고요.
다양한 분야에서 다양한 문제를 해결하다보니, 자신도 모르게 다 할줄 아는 슈퍼맨이 되어버린 거라고 생각합니다.
제가 스스로를 점검할 때 쓰는 건데요. Engineering Ladders 입니다.
이 표에 의하면 Level 4부터는 Senior라고 하네요.
링크는 여기 있습니다.
제 레벨은… 비밀입니다.
제 역할이 Tech Lead긴 하지만, 어디가서 Tech Lead라고 말하지 않고 개발자라고 말합니다. 당당하게 Tech Lead라고 말하기에는 스스로 부족하다고 생각해서 인데요.
요즘은 그마저도 부담스러운지 그냥 직장인이라고 말합니다…
