CTO vs VP Engineering

개발자로서 스타트업을 하다 보면 CTO의 역할에 대해 많은 고민을 하게 된다. 특히나 몇 명 안되는 소규모 개발조직일 때는 큰 의미가 없는 직함이지만 점점 회사 규모가 커지면서 보다 명확한 R&R을 정의하지 않으면 CTO 당사자와 다른 사람 모두가 혼란에 빠지기도 한다. 게다가 VP Engineering이라는 자리를 만들게 되는 경우 과연 CTO 와 VP Engineering은 어떻게 다른지, 어떤 관계인지에 대한 고민이 필요하다.

엄밀히, CTO와 VP Engineering은 사전적인 정의가 명확히 있는 것도 아니어서 R&R이 각 조직의 상황에 맞게 유동적으로 바뀔 수 있고 또 그래야 하겠지만서도 일반적으로는 CTO를 보다 기술 자체에 무게를 두는 경영진으로, VP Engineering은 개발팀의 manage에 더 무게를 두는 경영진으로 나눈다.

유명 벤처 캐피탈리스트인 Fred Wilson블로그의 글에서 다음과 같이 정의를 내리고 있고,

A VP Engineering is ideally a great manager and a great team builder. He or she will be an excellent recruiter, a great communicator, and a great issue resolver. The VP Eng’s job is to make everyone in the engineering organization successful and he or she needs to fix the issues that are getting in the way of success.
A CTO is ideally the strongest technologist in the organization. He or she will be an architect, a thinker, a researcher, a tester and a tinkerer. The CTO is often the technical co-founder if there is one (and you know I think there must be one).

또 다른 유명 벤처 캐피탈리스트이고 창업가인 Mark Suster은 역시 자신의 블로그에서 다음처럼 구분을 하고 있다.

http://www.bothsidesofthetable.com/want-to-know-difference-between-a-cto-and-a-vp-of-engineering/
The CTO / Lead Architect — If you want to build a great technology company, you’ll need a “rockstar” engineering lead. … The best CTO’s / Chief Architects are purists.
The VP Engineering aspires to manage teams. … And first and foremost a VP of Engineering is a people manager

이런 유명 인사들의 구분이나 정의를 따라가는 것도 나쁘지 않지만 바로 현장에서 이런 고민을 해 가는 사람의 의식의 흐름을 따라가 보는 것도 좋은 방법인 듯 하다. 해서 꽤 잘나가는 결제 관련 스타트업인 Stripe의 CTO, Greg Brockman을 원작자의 동의를 구해 번역 소개할까 한다.

그나저나, 이 CTO 와 VP Engineering 의 역할 구분이 비단 회사 단위에서만 필요한게 아니라 어느 정도 규모가 되는 개발조직 안에서도 나름 필요한게 아닐까 라는 생각은 항상 있으나 technical leader 와 manager 를 구분하기 힘든 우리 나라 사정상 항상 아쉬울 따름…

#define CTO

내가 개발자로 Stripe에 참여한건 2010년이다. 처음에는 서버 구조를 설계하고, Stripe의 신용카드 정보 저장소를 만들고, 다른 개발자들이 쉽게 작업하도록 내부 시스템의 추상화를 하는 등 백엔드 작업을 했다. 코딩을 좋아했지만 채용을 하고 회사 문화를 만들고 회사의 첫 티셔츠 디자인 (물론 회사의 첫 디자이너가 들어온 다음에는 폐기처분 됐다.) 같은 것들도 했다. 코딩보다 이런 일들을 더 좋아했던게 아니라, 내가 일원이고 싶은 환경에 대한 강한 비전이 있었고 그걸 실현하려고 노력했을 뿐이다.

시간이 지나면서 코딩이랑 상관 없는 책임이 점점 늘어 났다. Nelson Elhage의 표현을 빌자면, 내 업무는 “초기 직원”이 되어 있었다. 회사 문화에 대한 지침을 쓰고, 새로 들어온 직원들을 안착시키고, 채용을 챙기는 등의 일을 하며 시간을 보냈다. 코딩을 포기해야 할 때라고 생각하기도 했지만 어떻게든 코딩을 다시 할 방안을 찾아내기는 했다.

약 1년 반 전에, 나는 공식적으로 CTO가 되었다. 이미 하고 있던 일들에 명칭을 붙인 것 뿐이었고 회사 내 대부분의 반응은 “어라, Greg이 이미 CTO인거 아니었어?” 였다. 이 글은 그 이후에 벌어진 일들에 대한 것이고, 함께 개발팀을 구축할 파트너를 찾고, 회사가 커지면서 내 역할을 정립하는 것에 대한 내용이다.

VP Engineering 채용하기

지난 여름경, 나는 개발팀의 원하는 것들을 파악하기 위해 모두와의 1:1 면담을 시작했다. 화요일을 면담만으로 채웠더니 퇴근시간 즈음에는 완전히 녹초가 되었다. 재충전이 되어 효율적이 되었을 무렵에는 다시 화요일이 되었고 이런 나날의 연속이었다.

이런 시간을 보내면서 나의 역할이 기술적인 것일지 사람 관리에 대한 것일지 선택해야 한다는걸 알았다. 개인적으로는 코딩보다 더 사랑하는 것을 찾을 수 없었지만, 회사 입장에서는 우리가 채용한 훌륭한 직원들을 지원하는 것도 중요했다. 다른 회사 CTO인 친구는 VP Engineering을 채용하면서 큰 변화를 겪었다는 얘기를 해 주었다. VP Engineering에 대한 얘기는 들어본 적이 있었지만, 실제로 그런 역할의 사람을 구할 수 있을거란 생각은 안해봤었다. 결국 VP Engineering을 채용하기로 하고 CEO 및 내부 직원들을 설득했다.

내부에서는 아무도 그 역할을 하고 싶어 하지 않았다. 우리 회사는 그동안 나처럼 뭔가를 만들기 좋아하는 훌륭한 개발자들을 주로 뽑아 왔지, 전체 조직을 운영하는걸 좋아하는 사람을 뽑지는 않았었다. 때문에 VP Engineering은 외부에서 채용해야 했다.

일년 반이 넘는 시간 동안 수많은 전문 관리자들과 얘기를 해봤는데 극히 일부만이 내가 진심으로 같이 일하고 싶은 사람들이었다. 시간상 그 일부 사람들을 기다리는게 불가능 했기에 채용 전문 회사를 쓸 준비를 했다.

극적인 전개는 아니지만, 그러는 중에 마음에 들었던 사람들 중 하나인 Marc Hedlund가 회사를 옮길 수 있게 되었다. 나는 개발팀 멤버 각각과 일반적인 VP Engineering 채용 뿐 아니라 이 특정 후보자에 대해 얘기를 나눴고 25명의 팀 전부가 모여 같이 얘기하기도 했다. 우리는 VP Engineering이 정확히 어떤 일을 해야 할지 몰랐지만 확실히 아는건 이 역할이 1:1 면담을, 지금은 주로 개발자들과의 면담이지만 회사가 더 커지면 주로 관리자들과의 면담을, 많이 할 거라는 점이었다. 그래서 1:1 면담을 잘 하는 후보자를 뽑은 후에 다른 역할을 같이 고민해 보는게 최고의 전략이라고 생각했다.

그래서 Marc와의 인터뷰 일정을 짰는데, 아침 10시부터 저녁 6시까지 개발팀 전원과의 연이은 1:1 혹은 1:2 미팅 이후에 회사 전체와 만나는 것을 포함한 4일짜리 일정이었다. 이런 힘들고 빡빡한 인터뷰 일정은 확실히 초인적인 체력을 요하는 터여서 수 차례 괜찮은지 물어봤는데, 그는 전혀 문제 없다고 확신을 주었다.

또한 Marc와 같이 일했던 사람들과도 얘기를 해봤는데, 일부는 Marc의 소개로 또 일부는 다른 경로로 소개받은 사람들이었다. 내가 만났던 사람들 모두의 확실한 피드백은 “Marc는 제게 큰 영향을 줬고 훌륭한 멘토였어요”, “그와 여전히 연락하고 지내요”, “그랑 다시 일해보고 싶네요” 같은 것이었고, 그런 피드백을 받는 사람과 정말 일을 하고 싶어졌다.

마지막으로 중요했던 것은, 나와 Marc가 개인적으로 같이 일하기 좋은지였다. 우리는 같이 개발팀을 키우고 이끌어야 하는 책임이 있는 터라 잘 협력하지 못한다면 문제가 생기리라는걸 알았다. 우리는 Strip이 직면한 문제들, Marc의 관리/리더십 스타일 등에 대해 얘기하며 많은 시간을 보냈다.

내가 그에게 “우리가 이견이 생기면 어떻게 해야 할까요?”라고 물었을 때 그는 “지금 하는 것 처럼 얘기를 해봐야죠. 이상적인 것은, 우리가 개발팀을 더 훌륭하게 만들려 한다는걸 서로 믿는 거에요. 혹시나 접근 방법에 이견이 생긴다면 얘기를 해보고 여전히 이견이 남아 있다면 그 접근 방법은 일단 미뤄두면 되요”라고 말했다.

후에 내가 절차에 관해 물어봤을 때 그의 대답은 “확실히 이 회사는 관리자를 채용해본 적이 없군요.”였다. 그는 우리의 관리자 채용 과정을 설계하는 일을 했다. 웃기는건, 우리의 현 개발자 채용 과정을 만든 계기가 된, 예전 개발자 채용 과정에 대한 내 반응이 이와 똑같았다는 것이다.

VP Engineering을 채용한 후

결국 우리는 Marc를 채용했고 실제 업무 시작 전에 각종 이메일 리스트와 메신저에 그를 추가했다. 회사 내에서 무슨 일들이 일어나는지, 특정한 문제들을 어떻게 접근할지를 얘기하거나 서로의 이메일 초본을 검토하는 등을 하면서 많은 시간을 보냈다.

Marc가 본격적으로 업무를 시작하자 나는 곧바로 모든 1:1 면담 업무를 그에게 넘겼다. 그는 또 내가 덜어내고 싶은 어떤 일이든 자신에게 넘기라고 했는데, 당시 내 업무량이 얼마나 과도했는지 그 얘기가 내 귀엔 음악처럼 들렸다. Marc는 채용 업무가 내가 넘길 업무 중 하나일 거라고 얘기했다. 솔직히 놀랐던 것은, 채용이 (CTO와 VP Engineering 중) 누구에게 더 적합한 업무인지 몰랐고 내가 직접 챙기는걸 그만할 수 있을거라는 생각도 못했다. 헌데 채용은 전형적인 VP Engineering의 역할 중 하나였고 내가 그동안 해 온 많은 일들이 전부 일반적으로는 VP Engineering의 역할이라는걸 알게 되었다.

시간이 지나면서 중요한 변화는 사람들이 문제를 내가 아닌 Marc에게 가져가도록 하는 것이었고 이 부분에서 내가 가장 잘한 일은 하와이로 (내 첫) 휴가를 다녀온 후에 CTF3를 만들면서 몇몇 개발자들과 숨어버린 것이다. Marc가 점점 많은 사람들과 일하게 되면서 어떤 그룹이 직면한 문제나 조직 변화에 대한 것들을 더 잘 알게 되자 나는 점점 더 많은 역할을 그에게 넘겼다.

새 경영진을 받아들이는건 절대 매끄럽지 않다. 시작이 잘못되는 경우도 있고 변화의 강도가 큰 경우도 있다. 어떤 경우는 새 경영진을 위해 조직 문화가 바뀌어야 하고 어떤 경우는 새 경영진이 조직 문화에 맞춰 변화해야 한다. 내 생각에 많은 개발자들이 직면하는 것과 같은 문제를 나 또한 겪고 있었는데, “잘못된 것” 과 “우리 방식이 아닌 것” 의 차이를 구분 못하고 있었다. Marc는 채용이나 팀장급 회의, 의사소통 방식 등이 나와 매우 달랐고 모든게 문제 없이 돌아가고 있다는걸 내가 이해하기까지는 꽤 시간이 걸렸다.

이 와중에 내가 얻은 최고의 조언은, 권한 위임에는 두 가지 방법이 있다는 것이다: 하나는 완전히 권한을 위임하는 것이고 (몇몇 큰 원칙만을 정할 뿐 나머지에 대해서는 권한 위임 받은 사람을 간섭하지 않아야 한다), 다른 하나는 직접 세부적인 것까지 참견하는 거다. Mark Zuckerberg가 제품에 관여하는 것 처럼 후자의 방법이 유효할 때도 있다. 하지만 딱 한 분야에서만 그렇게 해야 한다. (일반적이지 않지만, 권한 위임 받을 사람이 나와 매우 흡사한 방식으로 일을 하도록 훈련시키는 경우도 있겠지만 이런 방식이 작동을 할 지라도 좋은 방법은 아니다.) 일반적으로는 모든 일들에 참견해서 의사결정을 뒤엎어 버리고는 사라져 버리는 “sparse micromanagement”가 최악이다.

나와 Marc의 협업 방식은 매우 간단했다: 같이 많은 시간을 보냈다. 처음에는 매 주 두 번, 월요일과 금요일에 한 시간씩 둘이서 이야기를 나눴다. 할 얘기가 많지 않을 때도 있었지만 우리가 무슨 걱정이 있고 무슨 일을 하고 있는지, 어디에서 무슨 일이 일어나는지 얘기 나누면서 시간을 보내는 것 자체가 매우 중요했다. 그 결과, 처음에는 Marc가 어떻게 반응할지 전혀 몰랐던 문제들에 대해 며칠 정도면 예상할 수 있게 되었고 결국 Marc의 반응을 즉시 예상할 수 있을 정도로 잘 이해하게 되었다. 우리는 몇가지 의사소통 팁을 사용했는데 핸드폰 메신저를 사용하거나 “X를 할 계획인데 이견이 없으면 24시간 안에 할 예정입니다” 같이 말하기 등이다.

여러분이 급성장하는 회사를 운영한다면 조직 자체가 여러분의 손을 떠나서 계속해서 변화한다는걸 알게 된다. Marc가 조직에 변화를 주는 법을 배워가는 와중에 나 역시 똑같은 것을 새로 배워 간다는걸 깨달았다. 회사는 몇몇 친한 친구들 집단 수준에서 던바의 숫자를 넘는 규모로 커졌고 서로 만난 적 없는 사람들 간에도 일이 잘 돌아가도록 하는 생각해 내야 했다. 이런 와중에 같이 일을 하는, 더 큰 조직을 운영해 본 경험이 있는 파트너가 있다는건 매우 값진 일이었고 나 혼자였다면 어떻게 해쳐왔을지조차 알 수 없었다.

내 역할

내 할일이 곧 없어져서 해야할 일을 찾아야 할 상황에 도달했고, 이게 상당히 고무적이었던게 최근 일년여간 내 역할은 주로 그날 그날의 문제들에 대응을 하는 것이었고 내가 집중하고 싶은 것을 스스로 찾게 된 첫 기회였기 때문이다.

약 20명의 CTO와 VP Engineering들을 만나면서 CTO의 역할에 대한 탐구를 했다. 이전에 나는 CTO는 chief architect여야 한다고 생각했는데, 내가 만난 사람들로부터 어떻게 그 생각을 바꿨는지를 알고 싶었다. 당시 나는 chief architect인 동시에 “초기 직원” 역할을 다 할려고 했으나 어떻게 하면 다 잘 할 수 있을지 모르는 상태였다. 더 겁났던건, 모든 사람들이 내가 의사 결정을 해야 한다고 생각해서 전체 조직이 느려지는게 아닐까 라는 것이었다.

놀랍게도, 내가 만난 사람들 중 한 명 만이 CTO를 chief architect로 생각하고 있었고 나머지는 오히려 개발 조직을 잘 굴러가게 하는 조정자 정도로 여기고 있었다. 어떨 때는 시니어 엔지니어들을 연결해 주고, 어떨 때는 멘토링을 하기도 했다. 특히 인상적이었던건, CTO가 제품 최고 담당자를 겸하는 경우였다. 제품 최고 담당자와 시스템 담당자 사이에는 엄청난 차이가 있는데, 좋은 제품은 간단하고 쉬워야 하고 나쁜 제품과 쉽게 구분이 되는 반면 좋은 시스템은 직접 큰 규모로 구축을 해봐야만 알 수 있다. 때문에 제품 최고 담당자를 부업무로 하는게 chief architect를 부업무로 하는 것 보다 훨씬 쉽다.

우리 개발자들이 중요한 일들과 개선 작업을 하도록 북돋아 주는 것이 가장 중요한 역할임을 깨달았다 (더불어 최근에 매우 훌륭한 개발자들을 뽑아온 터라 그 외 다른 일들은 별로 중요하지 않을 수 있었다). Marc와 나는 Stripe의 핵심 기능 개선을 위한 주요 프로젝트들을 착수시키기 위한 작업을 했다. 나는 거기에 추가로 각 시스템들을 개선할 개발자 그룹인 “architecture working group”을 출범시키고 우리 시스템에 대해 의견을 나눌 포럼을 만들었다.

전혀 예상치 못했던 것인데, 어느 순간 보니 내가 회사의 주요 정보 이동 경로에서 빠져 있었다. 나는 Marc가 합류하기 이전의 조직에 대한 정보를 갖고 있긴 했지만 그 이후의 변경 사항을 제대로 알지 못했다. 내가 누군가에게 X가 문제라거나 Y가 올바른 접근이라고 얘기를 해도 그건 전부 과거에 기반한 것이었다. 마치 해변에 묶여 있던 배가 누군가 줄을 자른 후에 바다떠에서 표류하는 격이었다. 무엇보다도 이 문제는 날이 갈수록 심각해 졌다.

조직 내에서 무슨 일이 벌어지는지, 매일 매일의 문제가 뭔지를 알려면 어떻게 해야 할지 고민하다 크게 네 가지 방법이 있다는걸 깨달았다.

  1. 직접 일을 한다: 직접 코딩을 한다면 뭐가 좋고 나쁜지 직접 알 수 있다.
  2. 많은 사람들과 얘기한다: 종합적인 관점과 의견을 가질 수 있다.
  3. 일들을 관찰한다: architect 역할을 하면서 코드 변경 사항을 모두 보면 된다. (실제로 한 달 정도 이렇게 일을 했었는데, 정말 시간 낭비였다. 대부분의 변경 사항들은 작성자들의 생각이 바뀐 결과였다.)
  4. 업무 계획을 짠다: 모든 업무 계획들을 짤 수는 있겠지만 이게 다른 피드백 수집 방법 없이 가능할지는 모르겠다.

그리고 내가 이 중 아무 것도 안하고 있다는걸 알았다. 이 중에 내가 가장 하고 싶은게 뭔지는 쉽게 알았지만 어떻게 그걸 할지는 또 다른 문제였다.

다양한 방식으로 코딩을 직접 해 보려고 했으나 대부분 실패였다. 예를 들어, “구석으로 가서 프로토타입을 만들어온 후 개발자에게 던져주고 개선하라고 하거나 관리 안된 상태로 두기”같은 것들 이었다. 이런 식으로 일하는 CTO들이 있긴 하지만 실제 잘 작동하는 경우를 보진 못했다. 훨씬 좋은 방식은 “실무 개발자와 같이 일해서 프로토타입을 만드는 것”이었다. 하지만 이 방법은 개발자의 시간을 뺐어야 해서 역시 쉽지 않은 방법이었다.

최근에 코딩 작업을 다시 시작한 CTO와 저녁식사를 같이하면서 그의 비밀이 뭔지 물어본 적이 있다. 어떻게 그렇게 할 수 있었을까? 그는 나를 쳐다보고는 “코딩이 제가 좋아하는 일이에요. 다른 어떤 일 보다도 코딩을 잘 한다는걸 알죠. 필요했던건 그 영향력을 활용하는 방법을 찾는 거였어요.”라고 말했다. 그가 발견한 방법은, 그의 회사 기반 시스템에 쓰이는 오픈소스 플랫폼을 만들어서 그의 회사와 산업 전체를 개선하는 것이었다.

지난달부터 나도 개발팀 일원으로 코딩을 다시 하기 시작했다. 다른 일들이 계속 있었기 때문에 쉽지는 않았지만 코딩에 많은 시간을 쏟을 수록 점차 조직 전반에 대한 이해가 높아졌고 다른 개발자들이 하는 일에 더욱 흥미를 느끼고 업무가 향상되도록 더 잘 도울 수 있게 되었다.

종종 이런 결정을 내린게 맞는지 되돌아 보기도 한다. 코딩을 하느라 더 고차원의 업무를 못하는건 아닐까? 하지만 (다른 CTO로부터) 내가 들은 최고의 조언 중 하나는, 문제는 시간 관리가 아니라 열정 관리라는 것이다. 당신이 더 고차원의 문제를 처리할 수 있도록 열정을 재충전 해주는 일을 찾는게 중요하다.

당분간 내 역할은, 완전하지는 않지만 대략 이런 모습일 테고 지금도 코딩을 하느라 매우 바쁘다.