많은 분들이 며칠 전 글을 읽고서 나머지 새 이야기를 빨리 보여달라는 피드백이 있어서 3년만에(?) 연재를 마치려고 합니다. 연재 마지막 글도 많은 성원 부탁드립니다.
소프트웨어 개발이라는 일은 높은 생산성을 이루기 위한 다양한 고려 사항이 있습니다. 코딩 작업이 무작정 시간만 투여한다고 해서 훌륭한 결과물이 나오지 않을 뿐더러 기술 리더 및 관리자의 역량과 기술 도입 선택 과정에서 생산성의 차이가 확연하게 달라집니다. 뿐만 아니라 중요한 기술 변곡점을 파악하여 회사의 운명을 바꿀 최고 의사 결정자가 누구냐에 따라 기업의 운명까지 좌우됩니다.
우리가 시간과 비용 그리고 역할과 책임을 효율적으로 나누어서 하는 업무의 방정식이 개발 업무에는 해당되지 않는 경우가 많습니다. 어찌 보면 비효율적이고 중복으로 보이는 소위 잉여력(剩餘力)이라고 부르는 요소를 개발 문화에 적용했을 때, 반대로 개발 생산성이 높아지는 것을 목격할 수 있었습니다.
이번 글에서는 개발팀 업무 방식, 신기술 도입, 사내 CTO의 역할 등에서 어떻게 하면 장기적인 기술 변화에 민감한 조직을 생산성에 맞추어 운영할 수 있을지 살펴보겠습니다.
■ 관리자와 엔지니어 수평적인 경력 나누기
우리 나라 IT 기업에서는 관리자로서 우수한 역량을 가진 사람 보다도 개발 능력이 뛰어나 팀 내에서 존경 받는 사람을 개발 팀장으로 승진시키는 것을 자주 보게 됩니다. 스타트업이 회사 규모가 빠르게 커질 때, 외부 사람을 영입하는 부담이 있기 때문에 내부에서 해결하는 방편으로 이런 오류를 범하기도 합니다. 저도 첫 직장에서 2년만에 개발팀장이 되고, 그 이후 2년만에 기술 이사(CTO)의 역할을 하게 되었습니다. 제가 관리자로서 역량이 있는지 검증도 되지 않았고, 준비도 되지 않은 상태였지요. 그나마 이는 작은 스타트업이었지만, Daum 같은 큰 회사에서도 개발 좀 한다 치면 묻지도 따지지도 않고 (승진의 수단으로) 팀장이 시키는 경우가 많았습니다. (최근에는 일정 규모의 스타트업에서는 경험 있는 관리자를 팀장 혹은 기술 임원으로 외부에서 영입하는 경우가 있습니다. )
개발 능력만 좋았던 초보 개발 팀장들이 겪는 많은 시행 착오가 있습니다. 가끔 과거에 하던 대로 코드를 계속 만져서 팀원과 불화가 생기기도 합니다. 팀원들은 팀장이 더 이상 개발에 관여하기 보다 팀원의 업무를 조정하고 외부 팀과 원활히 소통하며 의사 결정을 해서 효율적으로 팀을 운영하는 데 집중해 주길 바라기 때문입니다. 자신이 개발 능력이 뛰어났다 보니 외부에 안된다 라는 말을 못하고, 정작 일을 해야 할 팀원의 능력을 고려하지 않은데 그동안 해 오던 습관대로 업무 지시를 하달(?)하는 경우도 생깁니다. 이럴 때, 팀장 되더니 사람 변했다는 이야기를 듣게 되기 십상입니다.
대부분 글로벌 IT 회사는 개발자 경력 경로에 관리자(Manager) 트랙과 IC (Individual Contributor)트랙이 나눠져 있고, 개발팀에는 두 가지 역할 사이의 협력으로 운영됩니다. 매니저와 IC는 각 레벨에 맞는 독자적인 업무가 주어져 있고, 레벨 간 승진도 그에 따른 평가로 이루어집니다. 외국 회사에서 레벨이란 직무를 정하고 연봉을 나눠 주는 구간의 의미만 있지 수직적인 관계가 아니기 때문에 수평적인 협력이 일반적입니다.
즉, 팀 내에 개발 일정과 업무 조정 및 보고 등 일상 관리 업무를 담당하는 관리자와 기술적인 의사 결정과 팀원 멘토링, 코드 리뷰 등을 담당하는 기술 리더(Principal Engineer 혹은 Architect)를 두는 것은 매우 중요합니다. 이 두 가지 영역을 한 사람이 다 잘할 수 있을 것이고, 따로 두는 것이 비효율적이라고 생각하는 경우가 많습니다. 하지만, 둘 다 잘하는 사람은 거의 없고, 있더라도 여러분 회사에 없을 가능성이 훨씬 높습니다. 팀 내 리더쉽의 불일치로 인한 개발 생산력 저하는 꽤 치명적일 수 있습니다.
Daum에서도 팀 내에 개발팀장과 몇몇의 기술 리더를 따로 두도록 독려했습니다. 하지만, 수평 문화를 고수하기 위해 레벨 제도 없이 팀원-팀장-임원 등 직책을 단순화 해 두었기에 주로 시니어 엔지니어가 맡고 있는 기술 리더라는 자리가 팀원 중에 하나다 보니 직무를 수행해야 하는 동기 부여가 전혀 되지 않았습니다. 이 두 직군의 관계가 파트너 관계여야 하는데, 일부 팀의 경우 잘 동작하기도 했지만 수직적이 되는 경향을 막기도 힘들었습니다. 따라서, 중복적인 인력 배치처럼 보이지만 전사적으로 개발자 경력을 투-트랙으로 관리하는 것이 중요합니다.
■ 잉여력에 기반을 둔 유연한 신기술 도입
개발팀장들의 고민 중 하나는 팀 자원을 어떻게 효율적으로 배분하여 기존 업무를 하면서도 새로운 시도를 할 수 있도록 해 줄건가 하는 것입니다. 다른 팀이 보기에 새로운 시도는 남아 도는 것처럼 생각되니 마치 노는 것처럼 보입니다. 잉여력과 효율성은 보안성과 편의성처럼 트레이드 오프(Trade-off) 관계에 있다고 생각하기가 쉽습니다. 구글에서는 ‘직원 업무 시간의 20%를 창조적 프로젝트에 쏟도록 배려’하는 문화를 가지고 있다는 유명한 일화도 있습니다. (물론 구글 전 직원이던 마리사 메이어 야후! CEO가 허구라고 폭로를 했지만, 그녀의 엔지니어링 배경이 일천하다는 측면에서 CEO로서 차별화하기 위한 거짓이라고 생각합니다.)
출처: [Daum人 해커톤] “즐거운 상상의 나래를 펼치다” 블로터닷넷, 2012
저는 초보 개발 팀장들에게 개인이 아니라 오히려 팀 전체 자원의 20%를 여유롭게 운영하라고 조언해왔습니다. 팀원의 시간은 관리하기 어렵지만, 전체 팀의 자원은 관리할 수 있으니까요. 적어도 팀원 10명 중 2명은 여유롭게 서비스 운영 대신 신규 프로젝트를 하고, 개발 대신에 연구를 하도록 하는 것이죠. 외부의 어떤 압력이 와도 이 버퍼를 유지하는 것이 중요합니다. 팀장이 정말 중요하다고 판단됐을 때 이 자원을 활용할 수 있는 장점도 있습니다. 팀원들은 언젠가 그 20%의 업무를 하게 될 날을 기대하면서 재미없는(?) 운영 업무에 지치지 않을 수 있습니다. 유독 신기술을 미리 써보고 활용해 보길 좋아하는 개발자들에게 유용한 시간이면서 장기적으로 팀의 기술 선택에 도움이 되는 정보를 얻을 수 있기 때문입니다.
팀 내부 뿐만 아니라 Daum에서는 신기술이 어느 정도 궤도에 오르기 까지는 전사 콘트롤 타워를 만들지 않는 정책을 가지고 있었습니다. 개별 팀들이 특정 신기술을 스스로 공부하고 활용하여 이용하는 것을 막지 않았습니다. 어느 정도 규모를 가진 회사들은 사내 표준이라는 것을 만들고 이를 강제하는 것이 일반적입니다. 그게 개발 생산성을 높인다고 생각합니다. 공통 플랫폼팀이 제공하는 사내 라이브러리나 프레임워크의 권고안 정도는 제공하지만, 이를 강제하면 오히려 기술 유연성이 매우 낮아집니다.
Daum 내부 빅데이터 및 클라우드 기술 활용 사례- 윤석찬 (2012)
한참 하둡(Hadoop) 기반 빅데이터 플랫폼이 유행일 때, 다음 사내에서 하둡의 활용 빈도를 조사해 보니 20가지 이상의 프로젝트에서 다양하게 활용하고 있었습니다. 특정 팀에게 해당 기술을 총괄하도록 하기 보다는 팀간의 경험을 공유하는 사내 세미나를 개최하고, 사내 전문가 선정해서 도입하고자 하는 다른 팀에게 노하우를 전달하는 방식을 채택하였습니다. Daum 서비스는 주로 자바 플랫폼을 통해 개발하지만, 캘린더 서비스는 루비(Ruby)로 개발하였고 티스토리는 PHP를 통해 개발되고 있었습니다. 대부분의 백오피스 애플리케이션은 파이썬으로도 개발하며, 소스 콘트롤도 공식 서브버전 서버 뿐만 아니라 git를 함께 활용하기도 했습니다.
흔히 폴리그랏(Polyglot)이라고 불리는 이러한 개발 문화는 하루아침에 만들어 진 게 아니라 오랫동안 개발자과 그들의 업무 환경을 이해하고 성찰하는 과정에 나왔습니다. 아마존은 업무의 규모를 자체적인 운영이 가능한 도메인 단위로 잘게 쪼갠 후, 피자 두 판으로 한끼 식사를 할 수 있을 정도의 작은 개발팀을 구성하여 이들에게 모든 자율성을 부여하는 마이크로서비스(Microservices) 아키텍처와 투-피자(Two-Pizza)팀으로 조직 운영을 하는 것이 대표적이라 할 수 있습니다.
■ 비전가로서 최고 기술 임원(CTO)의 역할
기업의 최고 기술 임원(Chief Technology Officer, CTO)은 기술 직군의 꽃이라고 할 수 있습니다. 누구나 오르고 싶은 꿈을 꾸기도 하는 자리이기도 입니다. 대부분 CTO는 관리자 트랙으로 승진을 거쳐 오르거나 대규모 기술 조직을 이끈 경험이 있는 사람을 선호합니다. 그러다 보니, 기술적인 큰 그림을 그리기 보다는 일상적인 관리 업무가 대부분인 경우가 허다합니다. 팀이나 본부에서 해결되지 못한 많은 머리 아픈 복잡한 문제가 올라오는 자리이기도 합니다. 일반 개발자들은 CTO가 그런 일을 할거라고는 전혀 생각하지 못합니다.
스타트업에서 3년간 작은 조직의 처음 CTO 역할을 경험했는데, 회사의 사업에 변화에 영향을 줄 새로운 기술 기반 사업 모델을 구상하기 보다는 IT 기술 활용으로 빚어지는 법적 소송 부터 소소한 개발자들의 근태 및 불평 등을 계속 해결해야 했습니다. Daum으로 옮긴 후 11년 가까이를 CTO 직속팀으로 있으면서 총 5명의 CTO가 바뀌었는데, 그들의 일상 업무도 크게 다르지 않았습니다. 개발자로 시작해서 개발팀장, 본부장으로 승진한 새로운 CTO들은 반복되는 회의와 업무를 조정하는 관리자의 연장선에 있었습니다. (덕분에 기술적인 조언자 위치에 있었던 제가 사내 개발 문화와 대외 기술 전략 등을 고민하고 실행할 수 있었던 좋은 기회이기도 했습니다.)
앞서 말한 대로 글로벌 IT 기업에는 관리자와 개발자의 투-트랙으로 경력 관리를 합니다. 최정점에서는 VP of Engineering과 CTO가 존재하며, 이들은 전혀 다른 업무를 수행합니다.
클라우데라의 공동 창업자이자 CTO였던 Amr Awadallah의 What does a CTO do? (한국어 번역)라는 블로그 글을 보면, VP of Engineering이 통상적인 관리 업무를 맡는데 반해 CTO는 회사의 장기적인 기술 전략, 개발자들의 정신적 리더, 대외 에반젤리스트의 역할을 해야 한다고 합니다. CTO는 내부 보다는 외부와 소통에 더 많은 시간을 쏟고, 사내 개발 문화의 건강한지 늘 확인하면서, 회사가 필요한 기술 변곡점을 적시에 확인하고 이를 다른 임원들과 공유하여 적절한 의사 결정을 내리도록 하는 것이 가장 중요한 업무입니다.
물론 회사에 따라 이러한 CTO 역할을 VP of Engineering의 다음 포지션으로 맡기도 하고, 엔지니어 트랙에서 명망을 얻은 사람이 수행하기도 합니다. (Amazon의 Werner Vogels 박사나 Microsoft의 Kevin Scott 등은 IC로서 일하는 대표적인 CTO 들입니다. 대형 행사의 강연과 팟캐스트, 유튜브 채널 등 다양한 외부 활동으로 회사의 기술 리더쉽을 전파합니다. )
출처: Defining roles: CTO and/or VP Engineering
사실 국내에서는 이러한 CTO 역할이 생소하여 쉽게 받아들이기 힘듭니다. 다만, 몇몇 IT 기업들이 개발자 관계(Developer Relations)의 중요성을 인식하면서 글로벌 개발 문화나 조직 운영 기법들을 이식하고 있는 경우도 많이 있기 때문에 변화가 있을 것입니다.
저는 많은 개발자들이 관리자가 아니라 별도의 트랙을 따라 수석 엔지니어나 아키텍트, 임원급에 해당하는 특임 엔지니어(Distinguished engineer), 펠로우(Fellow) 혹은 CTO의 역할을 수행하는 것을 보고 싶습니다. (물론 개발만 잘해서는 안되고, 기술적 배경, 트렌드를 보는 통찰력, 소통 능력, 프로젝트에 조언할 수 있는 능력이 함께 있어야겠지요.)
전통적인 IT 기업 뿐만 아니라 오늘날 대부분 일반 기업에서 IT와 기술을 중심으로 하지 않고는 변화하는 세상에 민첩하게 움직이는 비즈니스를 영위하기가 어려워졌습니다. 제조, 금융, 리테일 등 산업 분야의 강자들도 직접 SW 개발팀을 구성하는 일도 많아졌고요. 어찌 보면 개발 조직에 중복으로 관리 인력을 구성하고, 신기술 탐험을 위한 잉여 자원을 두고, 기술 비전을 보여 주는 롤 모델과 경력 트랙을 구성하는 것이 비효율적이고 이상해 보일 수 있지만, 초기에 훌륭한 개발 문화를 정착하는 데 중요한 초석이 될 것입니다.
이번 연재는 이것으로 끝내지만 개발자 비급(祕笈) – 1. 연봉은 실력의 결과가 아니다의 비급 시리즈는 계속 됩니다. 물론 언제 끝날지는 알 수 없지만…
연재 목차
- 훌륭한 개발 문화의 이면(1) – 코딩 테스트인터뷰 제대로 하기
- 훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라!
- 훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?
- 훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?
- 훌륭한 개발 문화의 이면(5) – 소통 비용의 절약 – 서로 API로 말하자
- 훌륭한 개발 문화의 이면(6) – 입사하고픈 회사를 위한 오픈 전략 구사하기
- 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)
* 이 글의 댓글 일부는 Webmention 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.