by
Jan 01. 2021
CTO의 조건
작은 스타트업 CTO 경험담
안녕하세요.
거창한 제목으로 인사드립니다.
현재 작은 스타트업의 CTO를 하고 있습니다.
이 글을 쓰게 된 계기는
최근 개발자로서 미래를 꿈꾸는 많은 분들에게
도전이 될 수 있는 글을 써보고자 이 글을 쓰게 되었는데요.
풀스택 개발자라는 단어가 난무하고, 최신 기술들이 해마다 다르게 나오고 있는 상황 속에서
어느 장단에 맞추어야 하는지 갈피를 잡기 힘든 개발자들을 위해 한번 정리하는 차원으로 이 글을 작성했습니다.
그리고 막연하겠지만, CTO라는 목표를 향해서 하염없이 달려가고 있는 분들을 작게나마 응원하기 위한 바람도 있습니다.
우선 이미 다른 글들을 통해서,
이미 저를 알고 계신 분들도 계시겠지만,
이 글을 통해서 처음으로 저를 보신 분들을 위해서
간략하게 소개를 하고 글을 이어가려고 합니다.
우선 전 삼성 계열사를 통해서 삼성 엔지니어링이라는 회사에서 5년 정도 근무하고,
삼성 SDS 본사에서 ERP 업무를 1~2년 보낸 뒤에
본격 스타트업으로 이직하여, CTO로써 1~2년을 보내었습니다.
그리고 프리랜서로 SK 관련 프로젝트 리더로서 9개월 정도를 보낸 뒤,
패스트 캠퍼스 AWS 관련 강의를 한 뒤,
작년부터 아이고고란 스타트업에 합류해서 CTO로 지금까지 보내오고 있습니다.
https://igogo.kr
개발자로서 짧다면 짧고 길다면 긴 10년째가 되었는데요!
그간 많은 일들이 있었지만, CTO로써의 글을 바로 쓰기에는 부족하다는 생각이 들어서
아이고고 1년을 보낸 이 시점에서 경험담을 한번 공유드려볼까 합니다.
아직은 직원이 12명밖에 되지 않은 회사의
CTO라고 하기에 사실상 개발 팀장이라는 이름이 더 적합하지 않나 생각을 해봅니다만,
작은 회사의 CTO, 큰 회사의 CTO
이런 회사 크기의 유무와 무관하게 CTO라는 직무가 가지는 이름의 무게를 생각하자면,
CTO라 표현하며 글을 쓰는 게 맞는듯합니다.
CTO 가 되기 위해서 무엇을 해야 하고,
어떻게 해야 할까요? 우선 처음 신입사원 때로 돌아가서,
그 당시의 노력들을 떠올려 봅니다.
도약의 계기 (기회를 잡는 것)
당시 엔지니어링 초기 입사했을 때 첫 한 달간의 입사 후에 1달간 무엇을 했는지에 대해서 발표의 시간이 있었습니다. 신입 사원으로는 총 3명이 있었는데요.
3명이 각각 자기소개를 비롯한 다양한 경험들을 발표했던 것으로 기억합니다.
저는 유일하게 회사 안에서 2개의 프로젝트를 진행했다고 말을 했는데요.
지금 생각하면 너무나 유치하고 프로젝트라기엔 너무나 소소한 개발들이었습니다만,
위에서는 그런 패기 어린 모습도 좀 좋게 봐주시지 않았나 생각을 해보네요.
그 당시 기억하기로
인프라 담당자분이 맡겨주신 내부 모니터링 문자 시스템을 손보는 작업.
엔지니어링 내부의 해외 관련 사내 블로그가 있었는데요. 해당 블로그를 개발하는 작업.
인사 프로젝트 작업(토인비)
두 개의 프로젝트였고,
이 프로젝트를 통해서 배운 것들을 6가지로 정리했었습니다.
스트럿츠, 토인비, cgi, jstl, ajax, 리눅스 서버 관련 기동
물론 이 분류가 지금으로써는 맞는지 애매한 부분이 많았지만,
그 당시로서는 "뭐라도 하는 친구"라는 걸 어필하고 싶었나 봅니다.
당시 전 사내 시스템 개발을 너무 하고 싶었는데요.
인사 시스템은 규모가 조금 작고, 레거시라고 부르는 옛날 느낌의 프로그램들로 되어 있어서
다양한 설계나 개발을 경험하기엔 조금 부족하지 않나 생각을 하고 있었습니다.
(물론 추후에는 직무별로 틀리고, 신경 써야 하는 것도 많았기 때문에 간단한 게 아니라는 걸 체감하긴 했습니다. - 약간의 개인적 오해가 있었습니다)
그래서 조금은 빨리 개발을 배우고 싶은 마음에 그런 발표를 했던 것인데요.
첫 6개월을 인사 관련 개발팀에서 개발 작업을 했습니다.
그리고 발표 때문인지 운이 좋게도 몇 개월 안에 내부 포털 및 전체 시스템을 담당하는 부서로 이동하게 되었어요.
결과적으로는 사내에 있는 수많은 소스와 핵심 테이블을 까 볼 수(?) 있는 기회가 생긴 셈이죠.
인사 시스템, 사내 블로그 데이터, 마케팅 모니터링 시스템, 핵심 5대 역량 과제 블로그, 강연 시스템,
포탈 관리, 사우 협의회, 내부 CRM, oden 등 CI/CD 등등
얼추 하나의 기업에 데이터 베이스의 구성이나 구축 방식, 설계적인 측면들에 대해서 조금 더 알 수 있는 기회가 생긴 거죠.
혼자 살아남는 법
보통은 사수에 대한 환상들이 많이 있습니다.
좋은 사수를 만나면 좀 더 나아질 것이라는 기대, 그리고 그 사수가 나를 높은 곳으로 이끌어줄 것이라는 기대.
그리고 많은 것을 알려줄 것이라는 기대 등등 말이죠.
그리고 실제로 그런 사수가 간혹 존재하기는 합니다.
매주 코드 리뷰를 해준다던지, 다양한 훈련을 통해서 좀 더 고차원적인 사람이 되게 한다던지,
스터디를 매주 진행해서 조금 더 많은 것을 체계적으로 알 수 있게 해 준다던지 말이죠.
하지만 전 그런 부분과는 차원이 멀었습니다.
처음 오자마자 개발을 알려준다기보다는 개발할 일거리가 밀려 들어왔고,
인수인계와는 관계없이 바로 투입(?) 되어 일을 시작한 케이스라 실전 경험이 저의 사수였다고 할 수 있는데요. 물론 사수 입장에서는 저를 믿고 맡겼기 때문에 체계적 교육이 없이 일을 진행했을 것이라는 생각을 하긴 합니다. 그래서 조금 쉽지 않은 시간들을 보냈었는데요.
부서가 개발 쪽으로 바뀌고 처음 맡은 게 IT 자산 관리 화면을 만드는 것이었는데요.
기간은 2주, 할당받은 페이지는 14개 거의 하루에 1 페이지 정도씩을 만들어야 겨우 완성이 가능한 수준이었습니다. 선 그나마 기획서와 DB는 있었고, 신입사원으로서 이걸 처리해야 하는 압박과 인정받고자 하는 욕구 등등 서버에 대한 지식도 없고, 그저 mvc에 대한 개념적인 부분과 기존 코드를 토대로 화면을 찍어내야 했는데요.
시간이 생명인 부서에서, 뭔가를 체계적으로 물어보기란 매우 어려운 구조였고, 혼자서 소스만을 보고 이해하고 내 것으로 만들어야 하는 상황들이 계속 연출되었고...
3년이 지난 시점에 마침내 깨닫게 되었습니다.
누가 알려주는 시대는 원래 없었고, 앞으로도 없을 것이라는 것을...
내가 찾아야 하고, 내가 배워야 하고, 내가 알아야 그 넥스트가 존재한다는 것을 말이죠.
혼자로 버틸 수 있게 되니, 프로젝트 단위 업무들도 혼자 할 수 있게 맡겨 주었습니다. 일종의 기회인 셈이죠.
업무 5년 차에 갑자기, 보직이 변경됨에 따라 6개월간 차세대 관련된 프로젝트에 투입되게 되었는데요.
개발자가 총 5~7명 정도 투입이 되었는데, 막상 Faro라는 프레임 워크를 사용해서 개발을 하라는데,
모두 그 해당 지식이 없다 보니 맨땅에 헤딩을 했었는데요.
혼자 버티는 스킬로, 며칠을 홀로 삽질을 하다 보니, 그 해당 프레임 워크 관련된 지식을 그 같은 팀원들에게 공유할 수 있게 되었는데요. 이렇게 혼자 살아남는 생존법을 배우다 보니 어딜 가든 생존할 수 있는 스킬로써, 스타트업에 필요한 스킬 중 하나가 되었습니다.(물론 스타트업이라고 꼭 혼자 뭐든 다 할 수 있어야 하는 건 아니지만, 다양한 경험들은 파트를 넘나들 수 있는 자유를 허락했습니다.)
함께 하는 법 배우기
혼자 살아남는 법에 익숙해지다 보니, 문득 주변 사람들이랑 같이 어울리고, 함께 하는 것에 대해서 조금 소홀해지지 않았나 싶었어요. 그 간 소스들은 주로 svn이나 cvs로 공유를 해왔습니다. 이 것에 익숙하다 보면, git과 같은 소스 공유가 익숙해지지 않더군요. 회사 내에서 몇 번 부서를 옮기면서, 다른 사람들과 소통하고, 교류하고, 또 같이 프로젝트를 진행하기도 했었지만, 계속 그 갈증과 부족함을 채울 수 없었는데요.
수직 상하관계로써, 일을 해야 하는 상황에서는 사실해야 하는 것과 할 일, 그리고 결과만 있으면 되었기 때문에 의사소통 방식은 매우 심플하고, 오히려 일처리의 관점에서는 빠른 결과들이 도출될 수 있었어요. 하지만, 스타트업에 처음으로 가서 해야 했던 일은 의사 결정에 대해서 결정하는 일이었습니다.
어떤 일에 대해서 충분한 회의를 거치고, 그것을 할 것인지 말 것인지를 정하고, 그 정한 일에 대해서 일을 진행해야 했는데요. 이런 회의들이 사실 그 이전 회사에서는 없던 일들이었기 때문에, 이런 일련의 소통을 통해서 일을 진행하는 방식들은 배움이었습니다. 첫 스타트업에서, 대표와 디자이너와 저 이렇게 세 명이서 하나의 새로운 서비스를 만들 때는 이런 과정을 지지고 볶으면서 그래도 꽤 예쁜 서비스가 되었었습니다. 이때 bitBucket을 처음 사용하면서 git의 세계에 입문했죠.
그리고 작년의 프리랜서의 경험에서는 제가 프로젝트를 리딩 하면서, 사람들의 고충도 듣게 되고, 프로젝트를 완성하기 위해서, 여러 가지 방법들을 동원했어야 하는데요.
https://brunch.co.kr/@chickenmoim/5
이런 프로젝트를 통해서 사람들과 함께하는 법을 배우게 됩니다. (git을 조금 더 딥하게 사용하게 되고, 여러 사람이 사용하면서 문제 상황도 많이 겪었어요)
그리고 아이고고에 들어와서 팀원들이 하나둘 생기면서, 업무를 분배하고, 또 함께 웃으면서 즐거워하는 법, 그리고 눈높이를 맞추는 것, 그리고 동료로서 서로 성장해가는 것을 배우게 되었는데요.
업무라는 것을 혼자서 잘하고, 그것을 완수했을 때와 또 여럿이 함께 그 일들을 완수하는 것은 또 다른 일이라는 것을 실감했습니다. 어찌 보면 혼자 하는 일이 더 빠를 수도 있고, 그게 더 마음에 들 수도 있지만, 또 다른 사람과의 경험을 공유하고, 소스도 공유하는 과정을 통해서 다른 점들을 더 많이 알게 되고, 또 한편으로 서로의 실력을 보강하기도 하고, 또 작은 한계들도 깨닫는 것 같아요. 지금은 프로젝트별로 git을 관리하고 배포가 용이한 서비스를 구축해 놓은 상황입니다.
CTO 로서 어찌 보면, 혼자서 할 수 있는 능력, 그리고 여러 사람의 마음을 아우르는 능력, 그리고 그 사람의 기반과 기준치를 잡아서 함께 그 위치로 끌어올려주는 것이 필요하지 않나 이런 생각도 해봅니다.
커뮤니티를 통한 커뮤니케이션 스킬 강화
제가 치킨 모임이라는 커뮤니티를 만들고 운영한 것은 5년 정도 된 일입니다. 커뮤니티 초반에는 다양한 스터디를 진행했었는데요. 각종 팀빌딩을 비롯한 브레인스토밍, 안드로이드 스터디로 5사이클 정도 운영하기도 하고, 또 다양한 프로젝트들을 커뮤니티 내에서 만들고 리딩하고 완성까지 시키는 작업을 몇 번 하게 되었습니다.
이런 소중한 경험들은 스타트업에서도 당장 활용 가능한 스킬들이었는데요. 개발자들의 경우 디자이너와의 소통의 부재가 있는 경우들이 꽤 있습니다. 개발자끼리만 일했다거나, 디자이너의 성향을 잘 모른다거나, 혹은 디자이너가 생각하는 바를 이해하지 못한다거나, 제 다른 글 중에 개발자, 디자이너, 기획자의 동상이몽이라는 글에서 다양한 케이스들을 적어두긴 했습니다. 커뮤니티를 통해 다양한 소통방식을 연구하게 되었고, 그 결과 조금은 다른 직군과 대화도 조금 수월해지지 않았나 싶어요. 대표님들과의 다양한 교류들을 통해서 대표의 마음도 알게 되고(무엇보다 빠르게 시장에 제품이 나오고 싶어 하는 마음), 또 수익이 나지 않을 때의 조바심이나, 팀원이 구해지지 않을 때의 조바심 등등 다양한 케이스를 접하게 되다 보니, 역지 사지의 입장에서 생각해 보게 되는 일이 많이 있었는데요. 이런 일들을 기반으로 회사 내에 여러 가지 문제들이 생길 때 대입하다 보니, 약간의 마찰들을 조금은 수월하게 넘길 수 있었던 것 같아요.
결국에는 사람이 하는 일인데, 결국 서로 간에 일을 하는데 마음을 얻지 못하고, 또 감정이 상하면, 또 잘할 수 있는 일들도 잘하지 못하게 되기 때문에, 소통이라는 것은 결국, 상대와의 다름을 이해하는 것에서 비롯하지 않나 생각을 해봅니다.
결과적으로는 이런 커뮤니티에서 활동한 것들이 타인과의 소통의 자양분이 되었던 것 같아요.
대표의 눈으로 보기
앞서 대표의 시각을 많이 깨달았다고 표현을 하긴 했는데요. 스타트업을 나와서 프리랜서로 가기 전, 그리고 그 이후에 많은 대표님들과 차를 한잔하면서 CTO로의 영입 제안을 받으면서, 어떤 사람이 CTO에 맞을까? 이런 생각을 많이 했습니다. 최근에 "스타트업" 드라마를 보면서, 남도산이라는 CTO를 보면서 사람들이 얼마나 CTO에 대한 환상을 가지게 될까? 이런 생각을 해보았습니다. 어떤 느낌이 CTO에 맞는지 고민이 필요했던 것인데요. 드라마에 언급되었던 남도산 캐릭터도 확실히 CTO로써 갖추어야 할 자질을 가지고 있긴 합니다. 바로 남다른 기술력, 물론 그 드라마에서 그 인공지능에 대한 기술력과 방식을 조금은 쉽게 다룬 측면에 있어서 실제로 인공지능을 다루는 곳 입장에서는 조금 난감한 상황이 있었을 듯한데요.
우선 CTO를 뽑는다고 해서 다 같은 CTO는 아니라는 것입니다. 대표 입장에서는 작은 스타트업의 팀장급을 이야기하는 것일 수도 있고, 혹은 조금 더 성장한 곳에서 개발자를 케어하는 PM 입장을 뽑을 수도 있고, 혹은 더 나아가서 20~40명 정도 되는 기업의 입장에서 회사의 방향성을 설정하고, 그것을 결정하는 자리로써의 조금 더 무거운 CTO를 생각할 수도 있습니다.
초기 스타트업의 경우, 자본이 별로 없기 때문에 투자를 받기 위해서 CTO를 필요로 하는 경우가 많이 있습니다. 그 경우 개발을 잘하거나 이미 CTO의 경험이 있는 사람의 경우는 새로운 곳에 가지 않으려고 할 텐데요. 대표 입장에서는 그럼 어떤 사람을 뽑고 싶을까요?
첫 번째는 연륜이 있는 사람입니다. 5년, 적다면 적고 많다면 많은 경력의 숫자입니다. 5년을 기준으로 많이 생각합니다. 물론 중고생, 대학생들 중에서도 꽤나 날고 기는 친구들이 많아서, 작은 회사의 CTO로 가는 것을 종종 보게 됩니다. 물론 그 기업이 커지는 과정들도 있는데요. 보통 대표 입장에서 과감하게 모험을 하는 것이 아니라면, 이미 여러 가지 산전수전을 겪은 사람을 영입하고 싶어 합니다. 5년 정도의 경력이면 대부분의 문제를 처리할 수 있는 시점으로 보는 것인데요. 이 5년은 정말로 애매한 숫자입니다. 대학교에서 4년 안에 컴공의 경우 개발자를 할지 다른 길로 갈지가 결정됩니다. 컴공이라고 해서 다 개발자를 하지는 않는 것이고, 다른 길이 맞다고 생각하는 사람은 일치감치 다른 일로 가거든요. 회사도 마찬가지입니다. 5년 정도 회사의 일을 해보면, 이 사람이 계속 개발을 하고 싶은 건지, 아니면 그냥 회사 일을 하고 싶은 건지 판가름이 나오게 되어있습니다.
대표 입장에서는 개발 직군의 회사원을 뽑아야 하는 게 아니라, 개발 직군의 개발자를 찾아야 합니다. 회사일을 5년 정도 하게 되면, 일로써의 문제가 아니라 개발이라는 것에 대한 적성으로써의 부분이 스스로에게 드러나게 됩니다. 따라서, 5년 정도 된 개발이 능숙하고, 다양한 개발을 더 하고 싶은 개발자가 뽑아야 하고, 뽑고 싶은 인재인 셈이죠.
두 번째는 대표가 하고 싶은 것을 이루어 줄 수 있는 사람입니다. 개발자의 입장에서 시장을 보면, 대부분 시장은 많이 커졌고, 새로운 서비스들은 매번 나오지만, 이 중에 살아남거나 시장을 독식할 수 있는 경우는 매우 드뭅니다. 대부분 실패할 것이라는 것들을 짐작하고 있어요. 물론 시장을 보지 않는 개발자의 경우는 개발이 재미있을지 여부만으로 판단할 가능성도 있습니다. 대표가 하고 싶은 것이 웹인지, 앱인지, 혹은 데이터 시장인지, 인공 지능인지, 3D 인지 등등 대표가 뽑아야 하고 뽑고자 하는 능력을 가진 사람, 결국 그 사람이 CTO에 갈 수 있는 사람일 텐데요. 저의 입장에서는 백엔드, 프런트, 앱 이 세 가지를 다해보았다는 점에서 많은 분들이 좋게 보아주셨습니다. 물론 저도 얕은 부분이 있기 때문에 제 안주신 곳들 중에서 제 능력을 넘어서는 곳들은 과감하게 거절하고는 했었는데요. 자신이 할 수 있는 것들을 파악하는 것도 중요한 것이라고 생각합니다.
세 번째는 학력입니다. 의외의 대답이라고 생각하실 수 있는데요. 스타트업의 초기 투자 이후에 다양한 투자 심사를 받게 되면, CEO, CTO 기타 직원들의 스펙 및 경험, 그리고 학력 등등의 정보들이 투자의 심사에 중요한 정보가 되곤 합니다. 그래서, 간혹 뉴스에 N사 출신의 스타트업, K사 출신의 스타트업이라는 이름을 붙여 스타트업이 생기기도 하고, 그런 곳들이 투자받는다는 내용들도 꽤 접하실 듯한데요. 이렇듯 대표 입장에서는 혼자 매출을 극대화하는 경우가 아니라면, 이 세 번째도 중요한 요인으로 봅니다.
마지막으로는 이 3가지에서 언급되지 않는 것인데요. 개발자도 대표의 스타일을 보지만, 대표도 개발자의 스타일을 보게 됩니다. 보통 "결이 맞다" 이렇게 표현들을 하는데요. 서로가 아무리 능력이 출중하고 서로 실력이 맞아도, 이 부분이 맞지 않으면, 결별하는 사례들이 있습니다. 서로 마음이 맞아야 바퀴가 굴러갑니다. 그래서 이런 시행착오가 있던 대표님들은 이런 부분도 살펴봅니다. 이런 요인이 다 맞아야 결국 콜링을 하고 함께 해보자는 제안이 오는 것이죠.
이런 내용들을 알고서 대표님들을 만나게 되면, 합류하는 데 있어서 많이 수월해집니다. 물론 부가적으로 스타트업 경험, 대용량 트래픽 경험, 프로젝트 구축 경험, 앱 출시 경험, PM 경험이나 팀장 경험 등등 조건을 늘어놓자고 하면 끝이 없이 이어질 수 있습니다. 반대로 개발자도 엮으로 이 조건은 끝이 없이 펼쳐질 수 있겠죠. 그래서 보통 이렇게 스타트업에 입장에서 서로의 합이 맞아서 딱 잘 굴러가는 케이스는 많지 않습니다. 하지만 위 조건은 절대적 조건이 아닙니다. 대표가 양보할 수도 있고, 개발자가 양보할 수도 있죠. 다양한 협의와 조율을 통해서 조건들은 변경됩니다. 그래서 서로 경험이 있는 경우, 더 빠르게 일이 진행되기도 합니다.
전반적인 얕은 지식
얕은 지식이라고 하니 "지대넓얕"이라는 책이 떠오르는데요.
일부러 지식을 조금씩 알고 있으라는 의미는 아닙니다. 모든 것을 깊게 알고 있으면 좋습니다. 다만 다양한 부분에 대한 어느 정도의 지식이 필요합니다. 모르면 말을 안 했으면 좋겠다.라고 간혹 생각하신적들이 있을듯합니다. 너무나 잘 모르는 윗사람이 뭔가를 지시할 때 나오는 그 북받침.. 아 퇴사 욕구들 등등..
얕은 지식은 최소한 모르는 분야에서도 서로 이해가 가능한 범주 정도의 지식을 의미합니다. CTO의 경우 프런트 지식이 전무할 수 있습니다. 백엔드 출신이라면 더 그럴 가능성이 있겠죠. 이제 리엑트, 엥귤러, 뷰 등등 프런트에서도 PO를 뽑는 시대가 되었습니다. 그만큼 프런트를 경시할 수 없고 중요한 입장이 되었다는 이야기인데요. 이런 트렌트를 읽지 못한다면, 회사는 점점 옛날 방식을 답습하게 될 것입니다. 이건 모두가 원하는 방식은 아니죠. CTO는 최소한 현재 어떤 기술이 발전하고 있고, 어떻게 기술이 사용되는지, 그리고 지금 이 기술을 가지고 있을 때 앞으로 나오는 기술보다 뒤처지게 될 때 어떤 문제점이 생길지에 대한 대비가 되어있어야 한다고 생각합니다. 물론 이 시대에는 회사의 숫자만큼 CTO 가 있기 때문에 각각의 생각은 다를 듯한데요. 어찌 보면, 회사가 추구하는 안정성에 따라서는 과거의 유물을 놓아두는 것이 나은 경우도 있을 것입니다. 하지만, 빠르게 변해야 하는 업종에 가서 개발 중인데 실제로 그렇지 못한 것을 개발하게 되면, 결과가 따라가지 못할 수도 있습니다. 물론 CTO의 역할 중 하나는 안 되는 것을 안된다고 말해주는 것이기도 합니다. 기술적으로 과도하거나, 가질 수 없는 역량을 대표가 밀어붙인다면 그걸 브레이크 해주는 역할도 CTO가 해야 할 역할이라는 점입니다. 예를 들어서 꽃 어플을 개발 중인데, 사용자의 기호나 취향을 분석해서 꽃을 추천해주는 것을 개발해보자. 한데, 갑작스럽게 얼굴을 인식해서 사람들의 꽃에 대한 기호나 취향을 분석해보자고 하면 막아주는 사람이 필요하겠죠. 대표가 어떤 시스템을 만들려고 할 때, 그 시스템이 구현 가능한지 유무를 판단하고, 실제로 구축까지 할 수 있는 지식은 있어야 또 아니라는 판단이 들 때는 아니라고 이야기해주고, 대신 다른 대안들을 제안해 줄 수 있어야 합니다.
프로젝트 개발 역량
다소 CTO의 역할에 이 프로젝트 개발 역량은 필수적 덕목은 아닙니다. 좋은 설계자란 꼭 개발하지 않아도 그것을 할 수 있게 만들어 줍니다. 기획자의 역할과 대표의 역할, CTO의 역할 사이에 어떤 설계자의 역할이 들어간다면, 그 설계자는 CTO일 확률이 높겠죠. 하지만 좋은 기획자의 경우는 CTO나 개발자의 경험도 대체할 수 있습니다. 첫 회사에서 저보다는 20년 앞선 분을 만나고 존경했었는데요. 그분은 개발자가 아니셨지만, 개발에 대한 이해도 하고 계셨고, 설계도 하실 수 있었고, 문제를 찾아내고 짚어내실 수 있었습니다. 점점 관리자의 영역에서 개발을 손대지 않아도 그 그림을 그리고 전체를 볼 수 있는 안목을 가지고 계셨던 건데요. 회사의 구석구석을 알고 있고, 무엇을 어떻게 해야 하는지 알고 있고, 또 서비스나 시스템이 필요한 것들을 알고 대응하실 수 있었던 분이셨습니다. 그런 경우라면, 프로젝트 개발 역량은 필요 없을 것입니다.
하지만, 성장해 나가는 스타트업의 CTO 혹은 이제 갓 프로젝트를 시작하는 입장에서 CTO의 역할에는 프로젝트 개발 역량은 매우 필요한 역할일 것입니다. 그럼 학생들 입장에서, 혹은 이미 2~5년 차 개발자 입장에서 물어볼 수 있겠죠. 프로젝트를 안 하는데, 혹은 안 해봤는데 그런 역량은 어떻게 키울 수 있나요?라고요.
이 부분이 사실상 현재 스타트업 대표의 입장에서, 개발자의 입장에서 풀어야 할 숙제입니다. 개발자는 이 프로젝트 경험을 해야 하고, 대표는 이 경험을 가진 사람을 찾아야 하고, 이 두 사이의 간극이 있기 때문에, 프로젝트를 리딩 해본 경험이 있는 사람들은 더 많은 기회가 생기는 셈이죠.
개발 운영을 하는 것과 프로젝트를 시작부터 끝까지 해보는 것은 확실히 다릅니다. 누군가가 개발환경을 세팅해주는 것, 처음부터 개발환경을 만드는 일은 다른 일이니까요. 첫 회사에서는 struts, spring 으로 프로젝트가 되어있었습니다. 너무 오래된 버전들이어서, 나중엔 이런 버전들이 올라가면서 개념이 복잡해지고 달라져서 적응하기 어려웠는데요.
추후 프로젝트 시작 시에 spring boot, (maven or gradle), (tiles or sitemesh), (mysql or oracle), (jsp or vue) 기본적인 세팅을 진행할 때 어떤 것을 사용할 지에 대한 고민들을 하게 되고, 이런 세팅 과정들을 또 공유하고 나누는 과정들을 토대로 프로젝트가 굴러가게 되었는데요. 이런 경험들 뒤에 다른 프로젝트를 진행할 때는 조금 더 나은 선택들을 하게 되고 조금 더 복잡하지 않게 프로젝트를 구성하게 되었던 것 같아요.
결국 이런 프로젝트를 많이 진행하다 보면, 많은 지름길들을 알게 되고, 같은 프로젝트여도, 조금은 더 속도를 낼 수 있는 방식들을 알게 되는 거죠.
실패를 통한 성장 기회
첫 스타트업에서 나왔습니다. 첫 CTO 이기도 했는데요. 열심히 만든 개발이 무용지물이 되었을 때, 그 아쉬움은 이루 말할 수 없네요. 아마 저보단 대표님께서 더 아쉬우셨겠지만 말이죠. 첫 포부와 달리, 그 결과가 그 기대에 미치지 못했을 때, 실패란 생각이 들지 않을 순 없었는데요. 여러 가지 요인들이 있었겠지만, 개발적 관점에서, 개발을 완수하지 못한 것은 아니었지만, 기술적인 부분 이외에도, 사업적이고 돈이 되는지에 대한 부분에 있어서 개발자라는 생각 때문에 개입하지 못하고, 그저 바라보기만 했던 건 아닌가 생각이 들었습니다.
실패의 쓴 맛 뒤에는 성장 기회들이 찾아왔는데요. 프리랜서의 경험이 그러했습니다. 그리고 다양한 면접들을 토대로, 깨달은 것이 있습니다. 실패하더라도 그다음이 있다는 점인데요. 제일 처음에 스타트업으로 이직을 결심하고 이직하게 되었을 때 가장 두려웠던 부분 중에 하나는 그다음이 없을 것 같아서, 마치 불구덩이로 뛰어드는 건 아닌가 생각이 들었거든요. 다들 실패에 대해서 만류하기도 했고, 하지만 정작, 첫 스타트업이 아쉬운 결말이었지만, 다음 단계들이 있었기 때문에 좋은 경험이었다는 생각이 들었어요. 그래서 도전해 보고자 하는 분이 계신다면, 실패를 두려워하지 않아도 좋다고 말씀드려보고 싶네요. 만약 제가 그 넥스트가 없었다면, 이런 글은 쓰지 않았겠지만 말이죠.
선택의 순간 고려할 것들
최근 몇 년 사이 선택의 순간들이 있었고, 그 선택의 결과들을 후회하지 않습니다. 매번의 선택에서 나름대로의 원칙들이 있었는데요. 첫 번째 회사가 어렵다는 것을 직감했을 때, 그전에 먼저 이직 제안이 왔었지만, 이직을 하지 않았어요. 더 좋은 연봉에 괜찮은 회사로 갈 수 있었지만, 처음 제 손을 잡은 대표님이어서, 그 신뢰를 무너뜨릴 수 없어서였는데요. 한번 가기로 한 것 그래도 끝까지 해보자라는 마음이었는데, 결국 회사를 떠나야 했지만, 그 결정 때문인지, 회사를 떠난 이유를 묻는 말에 거리낌 없이 대답할 수 있게 되었고, 마음의 짐 없이 다른 일들을 해볼 수 있게 되었어요.
두 번째 선택은 프리를 하기로 결정한 이후에 연봉 7~8천 대의 약간은 이름 있는 회사의 CTO 제안이 2군데 왔었어요. 정확한 금액을 이야기할 순 없지만, 프리보다는 계속 경력을 있는 게 더 괜찮다는 생각이 들었는데요. 이미 프리를 하겠다고 결정하고 들어온 제안에 있어서, 프리를 안 하겠다고 결정할 수 없었는데요. 이 결정도 잘했다고 생각하고 있습니다. 다른 곳에 들어갔어도 분명 잘할 순 있었지만, 급박한 시일에 있어서 저의 결정이 다른 사람에게 피해를 줄 수도 있었던 상황이었기 때문에, 아쉬움도 있었지만 프리를 선택했습니다. 이 선택도 후회하지 않는 결정입니다. 그 덕분에 프리랜서의 생리도 알 수 있었고, 또 프로젝트 리더의 경험도 하게 되었으니 말이죠.
세 번째 선택은 다시 스타트업으로 오기로 한 결정입니다. 프리랜서의 기간이 잘 끝이 나고, 기간이 3개월 연장되었고, 계속 연장하거나 더 큰 기업의 프리 자리도 있던 타이밍이었는데요. 계속 프리를 한다고 하면 아마 더 좋은 조건으로 계속 다른 경험들을 쌓을 순 있었을 것 같아요. 절묘한 시점이었는데요. 곧 아이가 태어나는 시점이기도 했기 때문에, 프리랜서의 불확실성과 회사라는 안정성 중에서 회사를 선택하게 되었어요. 그리고 이미 스타트업을 경험한 입장에서 일반적인 회사를 지원해서 갈 수도 있었지만, 스타트업으로써의 도전을 조금 더 이어가고 싶은 마음도 있었는데요. 1년이 지난 시점, 그 결정 역시 잘했다고 생각합니다.
늘 했던 생각들이 있어요. 프리랜서를 하면 어떨까? 프리랜서에서 다시 정규직이 될 수 있을까? 스타트업에 간 뒤에 삶은 어떨까? 스타트업 뒤에 다시 대기업을 갈 수 있을까? 등등 다양한 고민들이 꼬리에 꼬리를 물었던 것 같아요. 그래서인지 조금 더 선택에 있어서 과감한 결단을 내려야 할 때 조금 주저하는 부분들이 있었는데요.
다른 사람이 이랬기 때문에 이래야 한다. 이런 타인의 말에 결정을 내리는 것들은 핑계의 여지를 주는듯해요. 남의 시선과 남의 생각이 아니라, 자기의 생각과 기준이면 충분한 것 같아요. 운영을 한다. 개발을 한다. 백엔드, 프런트, 앱, 등 하나의 역할에 충실한다. 등등 다양한 자기 기준안에 있다면, 다른 사람의 경험과 결과에 휘둘리지 않을 수 있게 되는데요. 시간은 또 빠르게 흐르고, 많은 것들이 빠르게 움직이면 자신만 도태된 것 같은 그 느낌과 착각이 들게 되는데요. 그 걸 극복하는 게 중요한 것 같습니다.
문제의 인식과 해결
아이고고에 처음 와서 한일은 시스템에 문제가 무엇인지 살펴보는 일이었어요. CTO로 왔지만, 앞서 개발자 친구가 있었기 때문에, 함께 이야기하면서 우선순위를 결정하기는 했는데요. 저희는 유아 방문 수업이었고, 많은 일들이 수동으로 이루어지고 있었어요. 그래서 다양한 일들이 필요했죠. 알림 톡을 이용한 스케줄 자동 발송 시스템부터 시작해서, 리포트 시스템까지 기존에 없던 부분이 많았어요. 그런 문제들을 파악하고 개선해야겠다고 느꼈죠.
그리고 웹으로 사용하기에는 부모님이나 튜터 입장에서 많이 불편하겠다는 생각을 했고, 튜터 페이지의 개선과 관리자 페이지 개선, 그리고 앱이 필요하단 생각이 들었어요.
전 자바 개발자였지만, 이 회사에 리엑트 개발자로 들어와서 리엑트 네이티브로 앱을 만들어야겠단 생각을 했어요. 처음에 플루터와 react native 중 선택의 기로가 있었는데요. 기반되는 웹이 리엑트였다는 점이 리엑트 네이티브와 개발 상 비슷한 맥락을 가져갈 수 있을 듯했고, 플루터의 경우는 최근에 나왔다는 점, 그래서 검증이 어렵다는 점을 이유로 리엑트 네이티브로 개발을 하게 되었는데, 결과적으로 완성도 되고, 론칭도 되어서 잘한 선택이라는 생각도 있지만, 성능상을 고려해보면, 시간이 좀 더 있었다면 다른 선택을 할 수도 있지 않을까? 이런 생각을 해보기도 합니다.
이렇게 탄생한 앱!
안드로이드
https://play.google.com/store/apps/details?id=com.igogo
IOS
https://play.google.com/store/apps/details?id=com.igogo
다양한 유아동에게 다양한 클래스를 경험하게 해주는 플랫폼입니다.
3월에 착수를 시작해서 9월에 앱을 론칭했는데요. 개발팀이 크지 않은데요. 작은 규모로써는 꽤나 빠르게 앱을 완성했습니다. API 도 만들고, 앱도 살펴보고, 채팅 서버도 구축하고, 관리하는 어드민 페이지도 만들고요. 물론 결제 및 정산에 관련해서도 만들었죠.
앱은 웹에서 이용하는 고객들이 불편할 것이다. 이것을 개선하게 되면 부모나 튜터 입장에서 훨씬 더 편리해질 것이다라는 관점으로 시작했는데요. 결과적으로는 많은 분들이 편리하다고 이야기해주시고 있습니다.
만약 CTO라는 직군을 해보고자 도전하는 친구에게 해주고 싶은 말이 있다면?
스타트업 대표로서의 관점으로 위에서 설명을 했다면, 대학생, 혹은 신입이나 이제 막 경력이 어느 정도 쌓여가는 입장에서 이런 팀장이나 CTO 등등의 직군에 도전해보고 싶을 거라는 생각을 해보았는데요.
보통은 "하지 마라"가 정설과 같은 대답이라고 생각되긴 할 것 같은데요.
용의 꼬리, 뱀의 머리라는 말도 있는데, 뱀의 머리도 머리거든요. 확실한 건, 회사에서 늘 부속품처럼 느껴져서 뭔가 뜨거운 것이 흐르고 계신 분이라면, 한 번쯤은 도전을 생각해 보는 것도 좋겠다는 생각을 해봅니다.
위로 올라가는 길은 다양하게 있을 것 같아요. 대기업을 가고, 대기업에서 또 다른 대기업으로 이직하고, 그렇게 연차가 쌓여서 팀장을 하게 되고, 또 세월이 지나서 과장> 차장> 부장(각기 직급 체계는 다르겠지만요) 이렇게 직급이 쌓여가는 방식, 아니면 새로운 기회들에 마주하는 경험들, 결국 회사가 성장하면 또 그것에 걸맞은 역량이 필요해지겠지만 말이죠. 좋은 사람을 볼 수 있는 안목이 필요한 것 같아요. 회사에 사람을 뽑아야 하니까요. 이 회사에 알맞은 사람이 누구인지, 어떤 역량이 필요한지, 그리고 구성원 간에 갈등은 어떻게 풀어가야 하는 것인지, 어쩌면 관리자와 같은 일이 피곤해서 더 상위 조직으로 가지 않고 개발자로서 개발일만 하려고 하는 분이 계실 수도 있겠단 생각이 드네요. 아마도 CTO가 된다면, 나중에는 개발일을 안 하게 될 수도 있어요. 혹은 하더라도 점점 커질수록 손을 쓸 수 없어지겠죠. 그때마다 모든 코드들을 컨펌할 수도 없고, 모두 코드를 분석할 수 없을 수도 있어요. 그럼 과감하게 권한을 이양하고 믿어주는 게 필요하겠죠. 그냥 멋있어서 시도해본다기보다는, 할 수 있는 일이 무엇인지, 회사에 어떤 것을 해줄 수 있는지, 회사의 가치에 날개를 달아줄 수 있는지, 등등 보다 많은 것을 생각해보면 좋겠다는 생각이 들었어요. 그전에 일단 개발일도 많이 해보는 게 좋겠죠.
우선 개발 프로세스에 대한 전반적인 이해와 시스템 전반에 대한 개발 플로우를 잘 알고 있는게 좋아요.
저의 경우 잡다한 일들도 많이 해봤었는데요. MFC로 카메라 제어 및 전송, 메일링 시스템 만들기, 강연 시스템, 삼성 single login api 사용, 사내 대량 메일 전송 기능, 클라우드 서버 운영, 안드로이드 모션 앱 제작, 앱 모션 외주, 유니티 증강현실, Centos 리눅스 서버 세팅, 우분투 서버 세팅, DB 설치 및 운영, 자바 스케쥴링, POI를 이용한 액셀 입출력 기능, gcm 등등 SMS 발송 기능을 포함한 slack api 연동 및 jenkins, jira api 등 작은 로그인 기능부터 자잘한 설치를 포함한 일들까지 다양한 경험들이 있다 보니, 어찌 보면, 큰 회사에서 분업화되어있어서 경험하지 않아도 되는 경험까지 조각조각 나있는 경험들로 부족한 부분들을 메워오고 있는데요. 당장에는 필요 없는 경험들도 많고, 모든 경험을 다해야 할 필요도 없지만, 경험된 내용들은 확실히 개발 속도에 있어서 실수를 줄이고, 속도가 생기니까요. 다양한 것들을 많이 경험할 수 있다면 그 기회 속에서 많은걸 해보시는 걸 추천드려요.
대표 입장에서 좋은 CTO 란? (역지사지)
앞서 대표 눈으로 보기와 비슷한 맥락인데요.
CTO 가 되고 싶은 입장에서의 이야기를 바로 앞에서 이야기했다면, 대표의 입장에서 좋은 CTO란 무엇일까요?
대표 눈으로 볼 때 3가지 조건 + 알파가 당연 좋은 CTO 이겠지만 조금 더 살을 붙여볼게요.
대표의 필요를 채워줄 수 있는 사람
- 전 웹 개발자입니다. 하지만 대표는 앱을 개발하고 싶어 해요. 그렇다면 그 방식을 제시해서 그것 할 수 있도록 만들어주어야 합니다. 그것이 설령 배워야 한다면 말이죠. 대표의 눈높이를 생각하고 문제를 해결하고 그 해결 방안을 제시해 주는 것이 필요합니다.
대안을 찾는 사람
- 두 군데의 스타트업에 있으면서 대표님들과 소통할 때 하는 말하는 방식이 있습니다. 안됩니다라고 말하지 않기입니다. 사실 안 되는 건 없거든요. 다만 시간과 노력과 공수가 필요한 거죠. 말도 안 되는 요구사항은 말도 안 되는 시간이 필요한 것이고요. 결국 설득에 있어서, 이런 이야기들은 말장난처럼 들릴지는 몰라도, 듣는 사람의 입장에서, 불가능하다는 생각 때문에 생각의 진행을 멈추어 버리는 게 아니라, 가능한 다른 방식을 찾도록 생각이 변화되도록 합니다. 즉, 이런 방식으로 진행하면 2달의 시간이 걸립니다. 대신 이렇게 진행한다면 2주 만의 시간으로 해결할 수도 있어요. 만약 고객의 불편을 고려한다면, 이렇게 먼저 진행하셔서 무거운 문제를 해결하고, 나머지 문제에 대해서는 점진적으로 해결해보는 방식은 어떠신가요? 이렇게 이야기한다면, 생각보다 더 빠르고 단순하고 괜찮은 해결 방식이 나오기도 합니다. 즉, 안된다라는 말을 하게 되었을 때는 다시 왜 안되는지에 대해서 설명을 요구받게 되고, 그 방식을 설명하다 보면, 방어적이 되어버리거든요. 결과적으로 애초 칼과 방패의 싸움을 하려고 이야기를 한 게 아니지만, 그 이야기를 하고 있는 상황들이 연출됩니다. 따라서 그런 이야기의 대화 방식이 중요한 거죠.
어디가 문제인지를 빠르게 캐치하는 사람
- 기술이 있는 CTO는 서비스 모델에 대한 문제도 빠르게 캐치하지만, 속도가 느려지거나, 서비스의 이상에 대한 문제들도 꽤 빠르게 알아냅니다. 그리고 현재 굴러가는 서비스에 대한 이해도가 높을 경우에는 해당 서비스의 개발자가 아니더라도, 해당 서비스를 빠르게 해석할 수 있습니다. 전체를 알고 내부를 아는 사람은 문제에 대한 대응이 빠릅니다. 물론 이런 사람은 실제로 같이 일해보기 전에 알기는 어려운 케이스이긴 합니다. 다만 레퍼런스 체크나 다양한 방식을 토대로 그런 분인지에 대해서 확인해볼 수 있다면 좋겠죠.
의사소통이 편한 사람
- 대화를 해보면 이 사람이 불편한 사람인지 아닌지 알 수 있습니다. 때로는 좋은 기술을 가지고 있는 것이 그 사람의 장점과 매력이 될 수 있지만, 좋은 기술만 있고 소통이 불편하다면 전체적인 조직에서는 좋지 않은 영향을 줄 수 있습니다. 이미 조직 경색이 상당이 오래 진행된 곳에서는 한 사람이 바뀐다고 변화할 수는 없지만, 만약 그런 경우가 아니라면, 위에 사람이 경직되면 아래도 수직 경직될 가능성이 높습니다. 문화적 유연성에 관련된 이야기인데요. 따라서 조직 문화에 대해서 이해도가 높은 사람이 아무래도 대화도 의사소통도 편합니다.
비슷한 업을 경험한 사람
- 아무래도 금융이면 금융, 커머스면 커머스, 플랫폼이면 플랫폼, 비슷한 업종의 경우 해당 경험에 대한 지식으로 올바른 판단을 내리거나 비슷한 경험치로, 해석이 용이합니다.
개발에 대한 전반적인 프로세스를 아는 사람
- 아무리 소통이 잘되고 문제에 대한 이해가 높아도 시스템이 어떻게 만들어져야 하는지 모르거나, 어떻게 기획하고 만들고 배포하는지 경험이 부족한 경우, 개발 인력에 대한 관리가 어려울 수 있는데요. 충분히 개발을 많이해보고 협업도 많이해본 경험도 중요해요. 혼자만 개발하는건 아니니까요.
개발 일정 수립을 할 수 있는 사람
- 가장 어려운 일은 공수를 산정하는 일인데요. 해당 프로젝트을 수행하는게 걸리는 시간이 어느정도인지 규모를 파악하고 그대로 수행하는 것. 이 부분을 잘 못하면 일정이 미루어지기 마련입니다. 개발일정을 스케쥴링하려면 개발팀내의 각각의 역량 파악도 같이 할 수 있어야 하는데요. 스스로의 개발 타임라인 안에서 일정 수립은 어느정도 가능하지만 이런 일정 파악을 잘 할 수 있는 사람이 대표입장에서는 좋은 CTO라 볼 수 있겠죠.
맺음말(각자의 길이 있다. 그럼에도 도전하려고 한다면, 짊어질 것을 짊어져야 한다.)
CTO의 조건이라는 제목으로 다양한 이야기들을 해보았는데요.
