스타트업에서 CTO의 역할

Ref. www.popit.kr/%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85%EC%97%90%EC%84%9C-cto%EC%9D%98-%EC%97%AD%ED%95%A0/?_fr=dable&utm_source=dable

제가 쓴 글이 아닙니다. 저에게 도움이 되는 것 같아서 가져왔습니다.

CTO (Chief Technical Officer) 란?

CTO (Chief Technical Officer, 또는 Chief Technology Officer)는 우리말로 ‘최고기술책임자’라고 불리며 보통 회사 내에서 기술과 관련된 최종 의사결정을 내리는 역할을 말합니다. 일반적으로 기술팀을 관리하며 회사의 전략과 기술의 전략이 잘 어울리도록(aligment) 노력하는 일을 합니다.

그러나 CTO의 역할은 늘 고정적인 것이 아니라 회사의 규모, 그리고 기술팀의 규모에 따라서 끊임없이 변화하게 됩니다. 이제 막 시작해서 전체 직원이 3명밖에 되지 않는 회사에서의 CTO 역할과 기술팀 규모만 수백 명에 달하는 성공한 스타트업에서 CTO의 역할은 당연히 다를 수밖에 없고, 달라야만 합니다. 만약 회사와 기술팀이 성장함에 따라 CTO의 역할이 함께 진화하지 못한다면 어느 순간 서비스와 기술은 성장의 정체기를 맞게 됩니다.

성장하는 스타트업에서 뛰어난 CTO 옆에서 보고 느꼈던 경험, 그리고 초기 스타트업에서 성장기를 겪는 과정까지 직접 CTO 역할을 수행하면서 경험한 내용을 정리해 보았습니다.  제 나름대로 스타트업의 기술팀 성장 단계를 아래와 같이 4단계로 나누었고, 각 단계별로 CTO의 역할일 어떻게 진화해 나가는지 살펴보겠습니다.

1. 암흑기 (Dark Era)
2. 성장기 (Growing Season)
3. 기술의 르네상스 (The Renaissance)
4. 성숙기 (Stage of Maturity)

 

Ads by optAd360

---

1. 암흑기 (Dark Era)

암흑기 (Dark Era)

(기술팀 규모 0명~5명)

제가 암흑기라고 표현한 것은 어두운 회사의 분위기를 말하고자 한 것은 아닙니다. 이제 막 시작한 스타트업의 경우 앞으로 회사가 어떻게 성장해나갈지 아직 한 치 앞도 알기 힘들고 불확실성이 가득한 단계이기 때문에 암흑기라고 표현했지만, 사실 어찌보면 이때가 무한한 성장 가능성과 행복한 미래를 자유롭게 꿈꾸며 가슴 두근거릴 수 있는 스타트업의 가장 찬란하고 즐거운 시절일 수도 있습니다.

이제 막 시작한 스타트업은 재무적으로 여유를 갖기 어렵습니다. 초기 자본금이나 시드 투자자금이 있다고 해도 제대로 된 기술팀을 갖추기에는 역부족입니다. 만약, 이 단계에서 초기 멤버, 또는 공동 창업자로서 CTO 자리에 있다면 다음과 같은 역할을 해야만 합니다.

최소 기능 제품(MINIMUM VIABLE PRODUCT)의 구현

초기 스타트업에서 CTO의 가장 중요한 역할 중 하나는 서비스, 또는 제품을 만들어내는 것입니다. 적은 인력으로 빠르게 제품을 시장에 내놓기 위해서는 부수적인 부분을 모두 제외하고 핵심 기능에만 집중한 제품이 필요한데, 이를 보통 ‘최소 기능 제품’이라고 합니다.

아무래도 스타트업 초기에는 모든 인력이 제품 출시를 최대 목표로 하기 때문에 제품 개발의 많은 부분을 수행하는 CTO로서는 그 부담이 매우 클 수 있습니다. 다행히 이 시점에는 기술팀이 CTO 외에는 아무도 없거나, 있다고 해도 1~2명 이기 때문에 특별히 매니지먼트 역할이나 프로세스의 중요성이 크게 부각되지 않습니다.

아무것도 없는 무(無)에서 하나의 서비스나 제품을 만들어낸다는 것은 경험 없이는 정말 어려운 일입니다. 많은 개발 경험은 물론, 다양한 토이 프로젝트 등의 시도가 이 단계에서 큰 도움이 됩니다. 만약, 이러한 경험이 아직 없으신 분이 계신다면 간단한 서비스라도 스스로 만들어보는 것을 강력히 추천해 드립니다.

 

Ads by optAd360

MVP를 구현한다는 것은 단순히 코드만 작성하는 것을 의미하지 않습니다. 이 단계에서 CTO는 해당 서비스를 제공할 서버를 어디에 둘지 (웹호스팅, (V-)IDC, AWS, GCP 등) 결정해야 하며, 도메인과 SSL 인증서 구매 및 설정, DBMS 종류와 방식 등 사소해 보이지만 다양한 부분에 대한 결정을 내리고 실행에 옮겨야 합니다.

초기 기술 스택의 선정

아무리 MVP라고 해도 직접 애플리케이션을 개발해야 한다면 최소한의 몇 가지 기술 요소들을 선택해야 합니다. 대부분 자신이 가장 다루기 편하고 경험이 많은 언어(language)와 프레임워크, 그리고 인프라와 같은 기술 요소를 선택하게 되며 이것이 가장 합리적인 방법이라고 할 수 있습니다. 그럼에도 불구하고, 기술 스택을 선정하는 것이 고민될 때는 아래와 같은 몇 가지 사항들을 고려하는 것이 좋습니다.

개발 생산성

스타트업에서 개발 생산성은 그 무엇보다도 중요한 고려 대상입니다. 페이팔(Paypal )과 링크드인(LinkedIn)의 초기 창업 멤버였던 리드 호프만(Reid Hoffman)은 스타트업의 정의해 대해서 아래와 같이 말했습니다.

스타트업이란, 절벽에서 맨몸으로 뛰어내려, 떨어지는 동안 비행기를 만들어 하늘로 날아가는 것이다. (Starting a company is like throwing yourself off a cliff and assembling an airplane on the way down) – Reid Hoffman

이처럼 스타트업에서 속도는 시장에서의 생존과 직결되는 중요한 요소입니다. 이것이 바로 짧은 시간에 서비스 기능을 구현할 수 있는 웹 애플리케이션 프레임워크들이 실리콘밸리에서 각광을 받게 된 이유입니다. 특히, 루비 온 레일스는 2000년대 중반부터 실리콘밸리의 많은 스타트업들이 웹 애플리케이션 프레임워크로 채택하여 사용하면서 스타트업의 대표적인 프레임워크로 알려져 왔습니다. 하지만 루비 언어의 특성상 서비스 규모가 (아주 많이) 커지게 되면 성능 이슈를 겪게 되는 아쉬운 점을 갖고 있습니다.

이러한 이유로 인해서 Non-blocking I/O 방식의 프레임워크인 Node.js 등이 관심을 받기 시작했습니다. Non-blocking I/O란, 하나의 스레드가 동시에 많은 채널을 관리할 수 있는 I/O 방식으로, 일반적으로 셀렉터(일종의 리스너)를 이용하여 네트워크상의 이벤트를 감지하여 처리하는 방식을 의미합니다. 반면, Blocking I/O는 접속자 한 명당 하나의 스레드를 생성하는 구조의 I/O를 말하며, 직관적으로 데이터 통신을 이해하기는 쉬우나 실제 네트워크상에서의 데이터전송 방식과 다르기 때문에 특정 이유로 데이터가 전송 중단되는 경우 스레드가 대기 상태에 빠져버리는 Blocking을 회피하기가 매우 어렵습니다. 즉, Blocking I/O는 은행의 창구업무로 비유하자면, 앞 손님의 처리가 완료될 때까지 뒤의 손님은 차례를 기다려야 하며, 동시에 많은 손님의 요청을 처리하기 위해서는 많은 수의 창구(스레드)가 필요한 원리와 같습니다.

이처럼 개발 생산성과 성능은 (늘 그런 것은 아니지만 많은 경우) 서로 상충적인 관계(tradeoff )를 가지기 때문에 서비스의 성장에 따라 예상되는 트래픽 규모, 최대 사용자 수의 예측에 따라 초기에 알맞은 기술 요소를선택하는 것이 중요합니다.

학습 속도(Learning curve)

스타트업은 대개 적은 인원으로 시작하여 서비스가 발전함에 따라 인원을 충원하는 방식으로 성장합니다. 이 과정에서 대부분의 스타트업은 대기업과 달리 체계화된 교육과정을 통해 인력을 실무에 배치할 만큼의 여력을 가지고 있지 못합니다. 이러한 이유로 초기 학습 비용이 큰 기술은 해당 기술의 장점에도 불구하고 새로운 인원이 합류하여 서비스 개발에 실질적인 역할을 하기까지 많은 시간이 필요하게 됩니다. 이 때문에 회사 차원에서는 이미 해당 기술에 경험이 풍부한 엔지니어를 선호하게 되고 이것은 그만큼 원하는 인재를 영입하는 데에 어려움으로 작용합니다. 이러한 상황에서 학습 속도가 매우 느린 언어나 프레임워크를 선정하게 되면 해당 기술에 대한 경험이 있는 개발자에 대한 의존도가 더욱 높아지고, 그만큼 인재를 구하는 것이 더 어려워지게 됩니다.

반면, 학습 속도가 빠른 언어나 프레임워크의 경우, 해당 기술을 직접 사용해본 경험이 없더라도 기본 원리나 철학이 유사한 다른 경험을 기반으로 원하는 인재를 채용하는 것이 한층 더 수월해지게 됩니다. 인지도가 없는 상황에서 엔지니어를 쉽게 영입하기 어려운 스타트업에서는 학습 속도가 빠른 언어나 프레임워크를 선택하는 것이 기술 요소를 선택할 때 고려해야 하는 중요한 점 가운데 하나입니다.

성능과 확장성(Performance and Scalability)

기술 스택을 선정할 때 여러 가지 요소를 고려하고 신중하게 결정해야 하는 이유는 선택한기술 스택을 나중에 변경하는 것이 매우 어렵기 때문입니다. 최근에는 마이크로서비스 아키텍처 등의 방식으로 전체 기술 스택을 한번에 바꾸지 않고도 점진적으로 기술 스택을 확장하고 변경할 수 있으나, 그럼에도 불구하고 초기에 개발된 시스템 전체를 완전히 변경(fade-out)하는 데에는 상당한 노력이 필요합니다. 그런면에서 앞서 설명한 ‘개발 생산성’과 ‘학습 속도’의 경우 잘못된 기술 스택의 선정으로 문제가 발생하는 경우 그 사실을 빠른 시점에 인지하는 것이 가능합니다. 반면, 성능과 확장성에 관련된 문제는 일정 시간이 지나 서비스의 이용자 규모나 처리해야 하는 데이터의 양(트래픽)이 많아졌을 때야 비로소 알 수 있어서 잘못된 선택을 초기에 인지하기가 어렵습니다.

그래서 초기 기술 스택 선정 시 간과하기 쉬운 요소 중 하나입니다. 하지만 거꾸로, 성능과 확장성에 대한 지나친 걱정은 ‘마세라티 문제(Maserati Problem)’가 될 가능성이 높습니다. 마세라티 문제란, ‘해당 이슈가 언젠가는 발생할 수는 있지만, 그 시기에 우리는 이미 서비스의 성공을 통해서 마세라티 승용차를 운전하고 있을 것’이라는 뜻을 비유적으로 지칭하는 표현입니다. 즉, 초기에 너무 먼 미래를 지나치게 걱정하는 경우에 사용합니다. 또한, 대부분의 성능 문제는 기술 스택의 잘못된 선정이 원인이 되는 경우보다 애플리케이션의 설계 등의 문제일 가능성이 높기 때문에 지속적인 튜닝과 최적화 작업으로 많은 부분을 극복할 수 있습니다. 결론적으로, 기술 스택을 선정할 때 성능과 확장성을 고려하는 것의 핵심은 지나치게 성능과 확장성을 간과하거나, 반대로 지나치게 먼 미래를 걱정하는 것은 아닌지를 잘 판단하여 합리적인 수준의 기준을 정하는 것입니다.

커뮤니티와 라이브러리의 활성화 정도

소프트웨어 기술에서 말하는 커뮤니티란, 특정 기술을 사용하면서 얻게 된 지식을 공유하고 어려운 부분에 대한 도움을 얻을 수 있는 온라인/오프라인 그룹을 의미합니다. 이러한 커뮤니티는 실제 해당 기술의 이름을 중심으로 모임을 하기도 하고 메일링 리스트를 통해 정보를 공유하기도 하며 컨퍼런스, 밋업 등을 통해 기술에 대한 지식을 주고받기도 합니다. 하지만, 기술 요소 선택 시에 고려해야 하는 커뮤니티란 이러한 명시적 활동만을 의미하지는 않습니다. 실제 스타트업에서 기술을 활용해 개발을 수행하다 보면 여러 가지 난관에 부딪히게 되고 이때 문제를 해결하기 위해 주로 사용하는 방식은 웹 검색을 통해 비슷한 어려움을 겪은 사람들의 사례와 해결책을 참고하는 것입니다. 이러한 의미에서 커뮤니티란, 같은 기술을 실제로 사용하고 이 기술에 대한 시행착오와 노하우를 공유하는 온/오프라인상의 유/무형 집단 전체를 의미합니다. 예를 들어, 어떤 기술이 새롭게 부각되어 해당 기술에 관심을 갖는 사람들의 온/오프라인 그룹은 매우 활성화되어 있지만, 다양한 경우에 적용된 사례나 정보가 부족하여 기본적으로 제공하는 문서(Documentation)에만 의존할 수밖에 없다면 해당 기술은 스타트업에서 필요로 하는 활발한 커뮤니티에 부합하지 않는다고 볼 수도 있습니다.

커뮤니티의 활성화 정도는 개발 과정에서 필요한 도움을 얼마나 쉽게 받을 수 있는지를 말해줄 뿐만 아니라, 현재 개발자들의 관심사와 구인/구직 시장의 트렌드를 반영하기도 합니다. 만약, 서비스를 개발하는 데 사용하는 기술이 매우 활발한 커뮤니티를 가지고 있다면 그만큼 해당 기술에 관심을 두는 개발자들이 많다는 것을 의미하고, 이는 새로운 인력을 영입하는 것이 조금 더 수월하다는 것을 말해줍니다. 반면, 커뮤니티가 작고 활발하지 않은 기술은 적합한 인력을 영입하기 위해 더 많은 노력이 필요하게 됩니다.

개발을 진행하다 보면 유사한 기능을 제공하기 위해서 미리 만들어진 라이브러리를 찾게 되는 경우가 많이 있습니다. 예를 들어, 사용자의 권한을 관리하는 기능은 서비스의 특성과 무관하게 상당 부분 공통점을 가지고 있지만, 직접 기능을 설계하려고 하면 놓치게 되는 예외 케이스들이 발생하게 됩니다. 이러한 경우, 다양한 예외 케이스를 이미 고려하여 해당 문제를 처리할 수 있도록 만들어진 라이브러리를 사용하는 것이 훨씬 더 효율적일 수 있습니다. 각 프로그래밍 언어들은 서로 다른 이름으로 라이브러리를 제공하며 일반적으로 언어와 프레임워크의 역사가 긴 만큼 더욱 안정적이고 다양한 라이브러리들이 존재합니다.

아래는 가장 성공한 스타트업 중 하나로 꼽히는 Uber의 기술 스택을 모아놓은 자료입니다. 이와 같이 다른 회사에서 사용하고 있는 기술 스택이 궁금하다면 StackShare.io와 같은 곳에서 찾아볼 수 있습니다.

Uber의 기술 스택 (Application and Data)

Uber의 기술 스택 (DevOps)

---

2. 성장기 (Growing season)

성장기 (Growing Season)

(기술팀 규모 5명 ~ 수십 명)

이 시기는 MVP를 구현하고 비즈니스나 기술의 가능성을 시장, 또는 투자회사로부터 인정받아 어느 정도 사람에 대한 투자가 가능한 시점입니다. 투자도 유치하고 기술팀의 규모도 커졌으니 CTO의 역할이 줄어들었다고 생각할 수 있지만, 오히려 이때 부터 CTO의 필요성은 점점 커지게 됩니다. 만약, 기존에 기술팀 리더 없이 경영진이 직접 기술팀 매니지먼트를 했다면 이 시점부터 기술적인 이해도 부족 등으로 인해 직접 기술팀을 관리하기 어려울 뿐 아니라, 경영진 자신도 할 일이 너무 많아서 누군가 기술팀을 전담해서 맡아주기를 기대하게 됩니다. (이 때문에 이 시점에 CTO 역할을 맡아줄 동료를 영입하는 경우가 많습니다).

이 시점에서 CTO의 역할은 참으로 다양해집니다. 기술팀 리더로서 안정적인 서비스(Service Reliability)를 유지해야 함은 물론, 빠른 성장 속도만큼 서비스와 제품 개발 퍼포먼스를 유지하면서도 올바른 아키텍처를 지향하도록 노력해야 합니다. 뿐만 아니라, 기술팀의 문화 정립, 기술팀의 인재 영입과 구성원들의 커리어 개발, 사내 보안정책 수립, 심지어 회사에서 사용하는 각종 IT 장비(노트북, 모니터 등)에 대한 자산 관리까지도 해야 합니다.

회사와 기술이 빠르게 성장하는 시기인 만큼 기술과 비즈니스 간의 끊임없는 커뮤니케이션을 통해 기술 전략과 로드맵이 회사의 중장기 전력이 잘 어울리도록(align) 노력해야 합니다. 또한, B2B 서비스를 만들어나가는 스타트업의 경우, CTO는 주요 고객사들과의 관계를 유지하면서 다양한 요구사항들을 전략적으로 판단하여 서비스나 제품 발전에 녹일 수 있어야 합니다.

이제 CTO는 모든 업무를 혼자서 다 수행할 수 없기 때문에 많은 부분을 위임해야 합니다. 이 과정에서 기술팀 각 구성원들과 함께 팀과 개인의 목표를 수립하고 이를 달성할 수 있도록 최선을 다해 지원해야 합니다. (목표를 수립한다는 것이 target goal을 설정한다는 의미가 아니라 일종의 계획을 수립한다는 관점으로 이해하는 것이 좋습니다). 모두가 최선을 다하면서도 즐겁게 일을 하면서도 CTO는 구성원들에게 일을 진행한 과정과 그 결과에 대해서 적절한 피드백을 주어야 합니다. 간혹, 리더는 무조건 위임하고 믿고 칭찬해야 한다고 믿는 분들이 있습니다. 그러나 제가 생각하는 가장 좋은 리더십은 전적으로 위임을 하고 믿기도 하며, 또 어떤 경우에는 함께 고민하며 해결책을 찾아보기도 하면서 상황에 가장 적절한 대응을 하는 것이라고 생각합니다. 이 때문에 필요한 경우에는 팀원들의 성장을 위해서 아쉬운 부분을 솔직하게 전달하는 필요하기도 합니다.

그러면, 성장기에 CTO가 해야하는 역할들에 대해서 몇 가지 알아보도록 하겠습니다.

아키텍처 전략 수립과 개발의 총괄

일반적으로 최소 기능 제품은 고수준의(high level ) 애플리케이션 아키텍처를 갖지 않습니다. 그러나 최소 기능 제품 개발이 완료되고 제품이 다음 단계로 진화하기 전에 애플리케이션의 아키텍처 전략을 수립할 필요가 있습니다. 물론, 때에 따라 이 시기는 좀 더 늦어지거나 빨라질 수도 있습니다. 그러나 대체로 이 단계에서도 애플리케이션 아키텍처의 전략을 수립하기 위해서 전문가를 영입하기는 어렵습니다. 즉, 성장기 애플리케이션 아키텍처를 책임지는 것도 CTO의 중요한 역할 중 하나가 됩니다. ‘소프트웨어 아키텍처’란, 소프트웨어 시스템, 또는 애플리케이션을 실제로 구성하고 있는 기본 구조를 말하기도 하지만 이러한 구조를 만들 때 반드시 지켜야하는 철학과 규칙을 의미하기도 합니다. ‘아키텍처 전략’이란, 이러한 애플리케이션 아키텍처를 어떠한 식으로 발전시켜 나갈 지에 대한 로드맵과 여러가지 선택지에서 무엇을 기준으로 아키텍처에 대한 의사 결정을 내릴지에 대한 기준을 의미합니다.

성장기 스타트업에서는 현재 진행되는 프로젝트를 책임지고 관리하며 유관 부서 및 담당자들 간의 커뮤니케이션을 조율하는 프로젝트 매니저의 역할을 두기도 하고, 그 역할을 각자 개인이 알아서 진행하기도 합니다. 그러나 많은 경우 성장기까지의 기술팀에서 진행하는 서비스 개발은 CTO가 총괄하여 관리하는 경우가 많습니다. 여기서 관리라 일정을 맞추고 일을 시킨다는 의미가 아니라 개발을 진행하는 데에 있어서 문제점이 없는지를 빠르게 파악하고 해결 및 조율하면서 각자가 맡은 역할에 집중하여 좋은 성과를 만들어낼 수 있도록 돕는 것을 의미합니다. 또한, 빠른 성장 속도에도 불구하고 일정 수준 이상의 품질(Quality)이 유지될 수 있도록 신경 써야 합니다. 성장 속도나 개발속도에 큰 영향을 줄 정도로 높은 품질 수준을 만족해야 하는 것은 아니지만, 서비스의 사용자, 또는 고객이 불편함을 느끼지 않을 정도의 성능과 품질은 일정 수준 유지해야 합니다.

개발 문화의 정착

많은 개발자는 선진 개발 문화를 경험하고자 스타트업을 선택하는 경우가 많습니다. 그러나 실제로 개발 문화라는 것은 짧은 시간 내에 “이렇게 하자”라고 해서 만들어지는 것은 아닙니다. 개발 문화란, 수많은 시행착오와 토론을 통해서 조금씩 자리 잡는 그 회사 고유의 개발과 관련된 분위기이며 공기와 같은 것입니다. 즉, 개발 문화는 CTO 혼자서 어떻게 할 수 있는 성격의 것이 아닙니다. 그럼에도 CTO는 대체로 스타트업의 가장 초기부터 함께하는 기술 담당자이기 때문에 이러한 개발 문화를 만들어나가는 데 매우 중요한 역할을 합니다. 또한, 문화라는 것은 인원이 많아질수록 개선해 나가기 어렵기 때문에 적은 인력으로 시작하는 스타트업 초기 및 성장기에 좋은 개발 문화를 정착시키는 것이 중요합니다. 좋은 개발 문화를 정착시키기 위해서 가장 중요한 것은 구성원들의 의견을 최대한 수용하여 다양한 시도를 해보는 것이며, 다른 회사의 시행착오와 성공 사례를 꾸준히 알아보고 도입하려고 노력하는 것입니다.

앞서 말한 것과 같이 개발 문화란 CTO 혼자서 만들어낼 수 있는 것은 아니지만, 리더십이란 결국 조직의 분위기(mood, atmosphere)를 어떻게 만드느냐의 문제이기 때문에 개발 문화 정착에 있어서 CTO의 역할은 매우 중요합니다. 같은 기술팀이라고 해도 서로 영역이 나누어지고 전문분야가 다르다 보니 입장의 차이가 발생할 수 있습니다. 좋은 스타트업 개발 문화를 정착하기 위해서 여러 가지 방법론과 best practice들을 시도하는 것도 중요하지만, 스타트업 개발문화에서 가장 중요한 것 중 하나는 “(지나치다 싶을 정도로 잦고 많은 정보의)공유”를 통해 정보의 공백이 생기거나 참여감이 낮아지는 일이 없도록 노력해야 하며, 코드리뷰와 자유로운 논의를 통해 개발된 코드나 이슈에 대해서 절대로 불평(blame)하는 문화가 없어야 합니다.

빠르고 다양한 시도

많은 스타트업은 사업에 대한 확고한 신념을 가지고 시작합니다. 그러나, 실제 회사를 설립하고 서비스를 운영해 나가다 보면 수많은 불확실성과 마주하게 됩니다. 기대했던 비즈니스 모델이 시장에 외면받거나 법적 규제 등 다양한 이슈로 계획했던 사업 방향의 차질이 생기기도 합니다. 이러한 불확실성 속에서 스타트업은 특유의 장점을 활용하여 빠르고 다양한 시도를 지속해야 합니다.

초기~성장기 스타트업에서는 빠르고 다양한 시도를 하는 데에 있어서 CTO의 역할은 매우 중요합니다. 우선, 다양한 기능 변화에도 안정적인 시스템 운영이 가능하도록 해야 하며, 이러한 다양한 시도가 코드나 서비스를 복잡하게 만들지 않도록 점진적인(teeny-tiny) 개발을 유도해야 합니다. 이를 위해서는 지속해서 자동화된 테스트와 배포가 가능해야 하며 문제가 발생했을 때 빠른 시간 내에 서비스를 rollback 할 수 있는 절차가 준비되어야 합니다. 또한, 잘못된 개발로 인해 데이터가 유실되거나 복구할 수 없는 문제가 생기지 않도록 항상 데이터 백업과 모니터링에 주의를 기울여야 합니다.

기술 부채의 관리

CTO의 역할을 설명한 다양한 자료들은 온라인에서 쉽게 찾아볼 수 있습니다. 그러나 ‘기술 부채 관리’ 역할을 다룬 자료는 많지 않습니다. 기술 부채는 금융 부채와 유사한 점도 많지만, 수치화하기 어려우므로 정확히 측정하거나 관리하기가 어렵습니다. 또한, 기술 부채의 영향은 눈에 잘 띄지 않기 때문에 개발자들이 스스로 관리하기가 쉽지 않습니다. CTO는 일종의 ‘자산 관리자’ 역할을 해야 합니다. 주기적으로 기술 부채 현황을 (정량화 하기는 어렵지만) 파악하고 이를 갚아나가기 위해서 팀원들에게 적절한 업무(task )를 위임하는 것이 중요합니다. 성장기에서 기술부채의 관리를 소홀히 하게 되면 기술팀의 성장이 어느 순간 정체되고 발목을 붙잡히게 됩니다.

기술팀의 인재 영입(채용)

회사가 성장하여 추가로 인력을 채용하는 경우, 이 시기까지 대부분의 후보자들은 CTO와의 인터뷰를 거치게 됩니다. 즉, CTO는 기술 인력을 영입하는 데에 가장 핵심적인 의사결정을 하게 됩니다. 물론, 단순히 의사결정만 하는 것이 아니라, 직접 좋은 인재를 찾기 위해서 다방면으로 알아보는 노력도 게을리하면 안 됩니다. 스타트업에서는 한명 한명의 역할이 매우 중요하기 때문에 인재 영입에서는 그 무엇보다도 신중하고 정확한 의사결정이 필요합니다.

기술팀의 사람 관리

성공한 스타트업의 사례에서 찾아보면 결국 사람이 가장 중요하다는 말을 자주 듣습니다. 즉, 사람에 대한 관리가 회사의 성공과 실패를 결정하는 큰 요인이 된다는 의미입니다. CTO는 기술팀의 인력을 전반적으로 관리하는 역할을 수행해야 합니다. 여기에서 관리란, 개인의 역량과 한계를 정확히 파악하고 현재 수행하고 있는 일과 개인의 적성, 역량이 잘 맞는지 끊임없이 주시해야 함을 의미합니다. 또한, 회사의 발전과 함께 개인의 역량이 성장할 수 있도록 업무를 적절히 ‘안배(arrangement)’하는 것이 중요합니다. 서비스의 발전만을 위해서 중요한 일을 실력 좋은 사람에게 몰아주거나, 아직 경험이 많지 않은 개발자에게 도전할만한 업무를 적절히 할당하지 않으면 장기적으로 회사는 소수의 인력에 의존하게 되고 직원 개인 또한 만족스러운 경험을 하지 못하게 됩니다. 사람에 따라 이러한 관리 역량이 부족한 경우가 있는데, 스타트업에서 CTO는 반드시 기술팀의 사람을 관리할 수 있는 역량을 키워나가야 합니다.

---

3. 기술의 르네상스 (The Renaissance)

기술의 르네상스 (The Renaissance)

(기술팀 규모 수십 ~ 수백 명)

기술팀의 규모가 수십~수백 명을 넘어가게 되면 더 이상 CTO 혼자 정확한 내용들을 속속들이 파악하기 어렵게 됩니다. 물론, 뛰어난 팀원들이 각자 해야 하는 역할을 문제없이 진행한다고 해도 CTO의 역할이 필요 없는 것은 아닙니다. CTO 혼자서 성장기 때 하던 역할을 이제는 더이상 다 할 수 없게 됩니다. 특히, CTO의 가장 중요한 역할 중 하나인 ‘기술에 대한 집중’을 할 수 없고 기술 외적인 부분에 많은 리소스를 할애하게 되면서 기술적인 성장에 신경 쓰지 못하게 됩니다. 모두가 맡은 분야에서 최고의 결과를 만들어낸다고 하여도 전체적인 시각에서 통합적으로 기술을 바라봐야 하는 CTO의 역할은 매우 중요합니다.

그러면 이 단계에서 CTO의 역할을 구체적으로 어떻게 변화하는지 한번 알아보도록 하겠습니다.

역할의 분리 (기술책임자 역할에 비중)

이 때 우리는 VP (of) Engineering(VPE) 이라는 역할에 대해서 생각하게 됩니다. “그게 뭐야?”,  “부사장 같은 거야?”, “CTO보다 높은 거야? 낮은 거야?” 보통 Vice라는 단어가 들어가면 Chief보다 직책상 낮은 것으로 이해하기 쉽지만, 기술팀에 국한해서 본다면 CTO와 VP Engineering은 역할의 차이일 뿐이고 직책의 높고 낮음은 고정적이지 않습니다. 역할이 분명하게 나누어진 영역을 제외하고, 둘 사이에 논의가 필요한 경우 CTO가 최종 의사결정을 내리는 경우가 많지만 경우에 따라 CTO가 VP Engineering에게 이슈를 공유하고 조언을 얻는 경우도 있습니다.

그동안 CTO가 기술과 프로세스, 그리고 관리역할을 모두 수행했다면 이제 이 모든 것을 혼자서 다 할 수 없기 때문에 프로세스와 관리적인 부분과 기술적인 관점에서의 역할을 분리해야 합니다. 기술을 기반으로 현재 진행되고 있는 프로젝트와 서비스는 물론 기술팀의 사람 관리 문화 및 프로세스에 대한 관리 역할을 담당하는 것이 바로 VP of Engineering의 역할입니다. CTO가 뛰어난 기술 리더이며 전체 아키텍트 팀의 리더라면, VPE는 좀 더 많은 수의 Software Engineering팀의 리더이며 사업의 비전과 고객 가치를 기술적인 로드맵에 반영할 수 있는 소통과 관리의 기술을 더욱 필요로하는 개발팀 리더라고 할 수 있습니다. VPE 역시 뛰어난 기술 경험과 배경을 필요로 하기 때문에 우리가 흔히 생각하는 Project(Product) Manger와는 그 성격과 역할이 다릅니다. CTO와 VP of Engineering은 역할만 분리되어 있을 뿐 일을 각자 따로 하는 것은 아닙니다. CTO와 VP of Engineering은 계속 이야기를 나누며 기술적인 성과가 전체 기술팀에 긍정적으로 영향을 미칠 수 있도록 노력해야 합니다.

이제 CTO는 좀 더 순수하게 기술적(Technology-oriented)인 역할에 집중할 수 있게 됩니다. 해커들로 구성된 팀원들과 기술적인 다양한 시도와 연구를 진행하면서 기술의 르네상스를 맞이하게 됩니다. 성공한 IT 스타트업들은 이 단계에서 기술적으로 많은 성취(achievement)를 이뤄내게 됩니다. 만약, 기존 CTO의 성향이 매니지먼트와 프로세스에 강하고 기술적인 부분에 관심이 없다면 이 시점에서 새로운 CTO를 영입하고 기존 CTO를 VP Engineering으로 역할을 바꾸는 것도 가능하지만 많은 논의가 필요합니다. 그럼 이 시점의 CTO의 역할에 대해서 몇 가지를 좀 더 구체적으로 알아보도록 하겠습니다. 이 시기의 CTO의 역할은 다양하고 많기보다 중요한 몇 가지에 집중하게 됩니다.

기술에 대한 전략과 비전 수립

CTO는 회사 내 최고의 기술담당자(#1 Guru)로서 기술에 대한 깊은 통찰력을 통해 기업이 시장에서 생존할 수 있는 기술을 고민하고 마련해야 합니다. VPE가 서비스와 제품의 속도 및 품질의 균형을 맞추기 위해서 노력한다면 CTO는 좀 더 최신기술에 대한 리서치와 프로토타이핑을 직접 실행하면서 기업과 시장에 큰 영향을 줄 수 있는 기술을 연구합니다. 이 단계에서 CTO는 보통 많은 수의 조직을 관리하지 않으며 전체 기술팀에서 일부 아키텍트와 리서처로 구성된 더 작은 CTO실(CTO office) 조직을 두기도 합니다. 이런 방식으로 회사가 기술적으로 뛰어난 경쟁력을 갖도록 노력하는 것이 CTO의 역할입니다.

스타트업은 빠르고 다양한 시도와 더불어 장기적인 기술과 비즈니스에 대한 전략을 중심으로 일관된 방향성을 유지해야 합니다. 이를 위해서는 장기(long-term) 로드맵을 수립하고 이에 맞는 핵심 기술을 발전 시켜 나가야 합니다. 예를 들어, 넷플릭스(Netflix)에서 견고하고 좋은 품질의 추천 시스템에 대한 단계별 로드맵을 수립하고 이에 맞추어 지속적으로 기술을 발전 시켜나감과 동시에, 이 기술을 실제 비즈니스 니즈와 부합할 수 있도록 다양하고 빠른 A/B 테스트를 끊임없이 시도해 나가는 것이 두 마리 토끼를 함께 잡아나가는 대표적인 사례라고 할 수 있습니다.

회사의 기술에 대한 브랜딩과 보호

CTO는 위에서 설명한 기술적 비전을 회사 내부의 구성원에게만 전파하는 것이 아니라 시장(Market)에 전파하는 에반젤리스트 역할도 해야 합니다. 외부 밋업, 컨퍼런스에서 회사가 연구, 또는 보유하고 있는 기술에 대해서 발표하거나 이 내용을 기술팀 블로그나 외부에 기고하기도 합니다.  간혹, 이러한 일들을 부질없는 시간 낭비라고 치부하는 사람들도 있으나 기술팀의 브랜딩과 PR은 CTO의 중요한 역할 중 하나입니다.

뿐만 아니라, 비즈니스에 크게 중요한 영향을 미치는 기술에 대해서는 특허 등을 통해 보호하는 역할도 해야 합니다. 이 부분은 서비스 형태의 비즈니스를 하는 곳보다는 소프트웨어 제품(O/S, DBMS 등)을 만드는 기업에서 특히 강조되는 부분입니다. 그러나 서비스 형태의 비즈니스를 운영하는 스타트업이라고 해도 자칫 중요한 인재가 핵심 기술에 대한 노하우를 가지고 경쟁사로 이직하는 경우가 있을 수도 있기 때문에 (드물지만) 사업에 있어서 아주 중요한 핵심기술에 대해서는 일정 부분 보호할 수 있도록 하는 것도 필요합니다.

---

4. 성숙기 (Stage of Maturity)

성숙기 (Stage of Maturity)

(기술팀 규모 수백 명 이상)

기술팀 규모가 수백 명 이상이 된 곳을 과연 스타트업이라고 말할 수 있을지는 잘 모르겠습니다. 물론, 구성원의 수가 스타트업인지 아닌지를 판단하는 기준은 아니지만, 일반적으로 기술팀의 규모가 수백 명 이상 되는 경우 기술적으로나 비즈니스적으로 상당한 수준 이상에 도달했다고 볼 수 있습니다. 과연 이 단계에서 CTO는 어떤 역할을 수행하게 되는지 알아보겠습니다.

기술 경영

이 단계에서 CTO는 해커, 또는 아키텍트 역할을 넘어서 경영진(經營陣)의 역할을 수행하게 됩니다. 다만, 기업을 경영하는 데에 있어 필요한 다양한 부문(운영, 재무, 영업 등) 중에서 기술적인 부분에 초점을 맞춰 기업의 경영활동을 수행, 또는 지원하게 됩니다. 기업의 연구개발(R&D)을 총 책임지는 것은 물론 이러한 성과물이 기업의 사업전략과 잘 어울려 궁극적으로 기업의 이윤 추구와 존속을 돕도록 합니다. 어찌 보면 이 단계에서 CTO의 역할은 앞서 언급한 기술(Technology)과 관리(Management)의 관점을 모두 포함하면서도 이를 좀 더 폭넓게 확장한 것이라 할 수 있습니다.

이렇게 기업의 비즈니스와 기술이 일정 수준 이상으로 성숙한 이후에도 기업과 기술은 끊임없이 발전하고 성장합니다. 이 때문에 CTO의 역할 역시 끝이라는 것이 없고 끊임없이 발전하고 성장한다고 볼 수 있습니다.

---

맺음말

수학 문제를 풀 때 같은 답을 찾아내는 방법은 무수히 많을 수 있습니다. CTO의 역할 역시 이 글에서 언급한 내용이 언제 어디서나 동일하게 적용된다고 할 수 없습니다. 모든 기업과 산업은 특성이 모두 다르고, 유사한 사업과 규모를 갖는 기업이라고 해도 기업을 구성하고 있는 다양한 특성에 따라 필요로 하는 CTO의 역할은 서로 다를 수 있습니다. 다만, 수학 문제를 풀 때 좀 더 효율적으로 답을 찾아내기 위한 접근방식과 가이드가 있듯이 이 글도 스타트업 CTO로서 어떤 역할을 해야 하는지 정확히 알지 못해서 막막한 분들께 조금이나마 도움이 되었으면 합니다.

이 글을 쓴 저 또한 부족한 점이 많은 사람이고 아직도 배우고 경험해야 하는 것들이 많기 때문에 이 글에서 제가 잘 못 생각하고 있거나 고쳐야 할 부분이 있다면 언제든지 좋은 의견 부탁드리고 싶습니다.