brunch

브런치북 스타트업 종사자를 위한 네번째 25화

라이킷 12 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신현묵 Jul 09. 2018

어설픈, CTO... 개발도, 회사도 망친다.

어설프게 하는 사람이 가장 위험함.

가장 위험한 것은 어설픈 사람입니다. 어떤 사람이 가장 어설픈 것인지 이야기해드립니다. 특히, 스타트업 CEO들은 이런 사람들을 주의해서 보셔야 합니다.

오래된 개발경험과 명확한 도메인에 대한 지식, 비즈니스의 구성과 환경에 대해서 잘 모르는 CTO는 개발 조직에게도 회사에게도 가장 큰 문제를 만들고, 제어할 수 없는 기술적 부채를 만들어 냅니다.

첫째. 개발이 중요하다고 이야기하지만 정작 중요한 의사결정에 대한 것은 잘 모르는 CTO

개발자와 대화를 하는 것이 첫 번째입니다. 소프트웨어 개발은 대부분 의사소통과 대화, 명확한 목표와 정교한 플랜에 의해서 도달하며, 대부분은 직접 개발을 하고 있는 개발자들이 가장 중요합니다.

그들의 부족한 부분을 찾고, 필요한 부분을 찾아 주어야 합니다.

그리고, 문제 있는 개발자와 잘못 구성된 구조에 대해서 잘 체크하게 됩니다.

중요한 이슈, 앞뒤의 문제에 대해서 선택을 해주어야 합니다. 비록, 잘못된 선택이라도 CTO가 의사 결정하는 것이 맞습니다. 직원에게 그 문제를 떠 넘기지 않죠. 기술의 선택에 대해서 책임지는 자리입니다.

둘쩨. 타인이 만든 소프트웨어나 서비스는 못쓰겠다는 CTO

현대의 개발 툴들 대부분은 고도로 정교하게 만들어진 상황이고, 대부분의 것들은 만들어진 상용제품을 적정한 비용을 지불하고 사용하는 것이 바람직합니다. 특히, 서버 모니터링이나 데이터 지표와 관련된 서비스나 관련된 내용을 개발하는 '바퀴의 재발명'을 반복하는 사람들이 있습니다.

이들은 현재 개발 트렌드를 전혀 모르는 구태의연한 구닥다리 오래된 개발자입니다.

특히, 비즈니스가 IT 중심이 아닌 서비스 상의 이슈라면 대부분의 개발 내용들은 '개발 테크 중심'이 아니게 됩니다.

셋째. 개발을 할 줄아는 것 같은데 프로토타입만 만드는 CTO

서비스가 만들어지고, 10만~100만, 1000만 사용자를 위해서 고도로 분업화된 서비스가 만들어지는 상황에서 프로토타입만 만들어서 개발 조직에게 후속 개발을 넘겨주고, 이에 대해서 자신이 매우 뿌듯해하는 CTO도 문제가 있습니다.

서비스 개발의 30은 비기능 중심이고, 30은 유지보수와 관련된 이슈, 30은 요구사항이나 비즈니스 요구사항에 맞는 비중이며, 10은 반복적인 유틸리티 서비스와 관련된 사항으로 대부분 구성됩니다. 프로토타입만으로는 이와 같이 분리된 형태의 서비스가 구성되기 어렵습니다.

서비스를 혼자서 개발하고 유지 보수하고, 문서화나 리팩터링 이슈까지 커버하려면, 프로토타입만으로는 이 문제가 해소가 안됩니다.

대부분 이렇게 프로토타입으로 구성된 서비스로 서비스가 확대되다 보면, 각종 서비스의 확장이 느려지고, 하나를 고치면, 또 하나가 문제가 생기는 현상이 반복적으로 발생되고, 결국. 서비스의 유지보수가 불가능한 기술적 부채가 엄청나게 폭주되는 서비스들이 만들어집니다.

대부분 버전 1에서 프로토타입을 구성한 이후에는 구조적인 부분에 대한 아키텍처링을 통하여서 제대로 된 서비스를 다시 디자인해야 하기 때문에, 프로토타입만 만들도 우쭐 되는 CTO는 결국 비즈니스의 속도를 감당할 수 없습니다.

넷째. 비즈니스에 대한 이해도가 전혀 없는 CTO

하이테크 한 설루션을 만드는 스타트업의 경우에도 마찬가지입니다. 만들어지는 서비스나 설루션이 해당 비즈니스의 구성과 속도, 환경과 맞아야 합니다. 매우 당연하게 비즈니스에 대한 이해도가 떨어지는 CTO는 결국 문제를 일으킵니다.

IT서비스의 대부분은 비즈니스 모델과 운명이 동일합니다. 내부에 필요한 관리 프로그램까지 비즈니스에 대한 폭넓은 지식이 없으면, CTO 역할을 꾸준하게 할 수 없습니다.

다섯째. 다른 C레벨과 다툼이 없는 CTO

비즈니스의 속도와 상황에 따라서 불필요하거나, 반복적이고. 버려지는 작업들이 빈번하게 발생합니다. 이에 대한 의사결정 과정에 있어서 CEO와 CPO, CFO와의 반복적인 회의와 개발 조직의 구성에 대한 의견들은 빈번한 불협화음이거나 속도 문제 때문에 이견이 발생하는 것은 매우 당연합니다.

급한 인사 결정 과정이나 비개발자의 시선, 기획이나 디자이너 등의 비개발 조직과의 이슈, 영업과 마케팅 조직과의 이슈 등에 대해서 언제나 문제 상황에 만나게 되며, 이에 대해서 언제나 토의와 토론을 반복합니다.

여섯째. 비대한 개발 조직을 운영하려는 CTO

가장 적절한 개발 조직의 비중은 전체 인력 구성의 1/3이 적당합니다. 그 어떤 IT스타트업이거나 중소기업이라고 하더라도 그 이상의 비중은 대부분 만들어지지 않습니다.

그리고, 비즈니스 모델이 미리 계획되어 있다는 전제조건하에서는 해당 업무들을 충분하게 버릴 것과 해야 할 것들을 구분하면서 순차적으로 진행이 가능하게 됩니다. ( 물론, 이 결정의 대부분은 CEO의 결정입니다. CTO가 책임져야 할 영역은 아니죠. )

마지막으로 일곱 번째, 자신의 자리가 자신이 필요한 자리인지 모르는 CTO

대부분의 스타트업의 초기에 CTO자리에 있다고 하더라도, 조직이 커지거나, 비즈니스가 복잡해짐에 따라서 자신의 역량에 대해서 잘 평가하고, 이에 적합한 사람이나 인재에게 양보를 하게 됩니다.

또한, 반대로 비즈니스의 속도가 이미 둔화되고, 비즈니스의 형태가 마무리되는 형태가 된다면, 자신의 자리에 머물기보다는 해당 비즈니스의 속도에 맞는 후배에게 자리를 양보할 줄 알아야 합니다.

CTO는 개발 전체를 책임지고,

비즈니스의 구성에 맞는 개발 스택을 구성하고,

비즈니스의 속도에 맞춘 프로세스와 개발 조직을 세팅하고,

비개발 조직과의 연관성과 가치적인 부분에서 IT조직이 최대한의 서포트를 수행하려 합니다.

언제나처럼 이야기합니다.