CTO라는 단어가 처음 한국에 등장하고 부터 지속적으로 나오던 "진짜 CTO,가짜 CTO Blah Blah..."의 글들도 10여년지 지난 지금 시들한 것 같다.
그도 그럴 것이 CTO의 역할(Roles)은 조직의 구성에 따라 차이가 날수 밖에 없다는 것을 대다수가 인정하는 분위기가 되었기 때문이고 산업이 다양해지면서 같은 C-Level이라고 하더라도 다양할 수 있다는 경험이 축적되어서가 아닐까 싶다.
CTO가 하는 일에 대해서 알아보자
기술 스택 관리
회사 운영에 필요한 기본적인 운영 서비스/툴 부터 시작해서
비즈니스에 필요한 기술 비전과 로드맵을 정하고 관리해야 한다.
예를 들면,
- 사내 랜선 까는 것부터 시작해서 OS설치, 백오피스용 서비스나 ERP관리, CRM과 같은 기본 운영에 필요한 모든 기술적인 것에 관여
- 회사의 비즈니스가에 맞춰 적합한 기술을 채택하고 C-Level과 논의된 비즈니스 방향에 맞는 로드맵을 구축 및 하위 조직원들과 공유, 실행, 개선(트랜드 반영) 등
과 같은 일이다
랜선깔기를 왜 CTO가 관여해야 하는지 모르겠다면, 사내에 있는 직원들의 전공과 경험 등을 훑어보길 바란다.
상/하위로 라우터(공유기로) 배치 해놓고 게이트웨이 IP 동일하게 입력해 네트워크 마비시키는 사람들만 즐비할텐데 ^^;;
오피스 네트워크는 빌딩 관리실에서 관여한다고?
빌딩 인터넷 마비되면 해결되기 전까지 그 비싼 인력들 다 손가락 빨게 만들겠다면... 뭐 ^^;;
백오피스에 지원조직이 있어서 랜선깔기, OS설치, 백오피스용 서비스와 같은 기본 운영 기술은 관여할 필요가 없다면?
필요 없다 생각되면 관여하지 않아도 된다, 하지만 CTO가 운영 서비스에 해당하는 기술에 관여하지 않는다라... 이런경우라면 아마도 백오피스 조직에도 별도의 C-Level이 있지 않을까 싶다.
그렇지 않은 경우는 완전히 관여하지 않더라도 허벅지까지 발은 담궈 놓는 것을 추천한다.
누군가는 스타트업일 때만 위 모든 것을 하고 기업이 커지면 일이 자연스럽게 덜어진다고 생각할지도 모른다.
반은 맞는 말이라 본다. 자연스럽게 덜어질 수도 있지만 비단 회사뿐만이 아니다.
어떤 형태의 사회든 역할(Roles)이 나눠지는 과정은 정말 길고 험난하다. 자연스럽게 나눠진다면 당신은 정말 행운아!!!
여튼 기술 스택 관리에 대해서는 내가 이 조직에서 어떤 CTO여야 하는지 생각해 보면 본인의 역할이 어느 정도는 명확히 정의 되지 않을까 생각된다.
리드 개발자 및 엔지니어
회사 비즈니스에 필요한 서비스나 기술을 사용한 결과물을 만들어내는 과정에 CTO는 리드 개발자 및 엔지니어야 한다.
정의된 기술 스택을 바탕으로 인프라 설계부터 구성, 코어 개발을 리딩, 지속적으로 결과물을 개선한다.
나는 왕년에 개발자였지만 지금은 실무를 하지 않는 CTO(흔히 볼 수 있는 기술 이사)라고?
조직 내에 나의 분신인 에이스가 있지 않는가? 솔직히 말하자. 사실 그 친구가 CTO 역할을 하고 나는 그냥 정신적 지주라고 ^^;
큰 규모의 회사로 탈바꿈 하여 역할이 나뉘어져 있는 경우라면 모르겠으나 작은 규모의 조직이라면 조직 구성 상의 단점 또는 조직원의 불만의 사유가 될 수 있음에 유의하자
초기에는 CTO가 리드 개발자, 엔지니어 였다가 조직이 커짐에 따라 조직원에 역할을 나누어 주게 되는 경우가 이상적인 형태일 것이다. 하지만 조직원에게 개발자,엔지니어 역할을 주었다 해서 CTO가 해당 기술을 놓아야한다는 말이 되지는 않는다.
본인이 기술 동향과 기술과 관련된 논의에서 배제될 정도로 실무와 관련된 정보에 취약하다면 CTO의 타이틀 반납을 고려해야하지 않을까?
조직의 구성이 다양하니 CTO 타이틀은 진짜 CTO역할을 하는 이들에게 주고 본인의 타이틀을 만드는게 서로에가 나은 것이 아닐까 생각한다.
팀 빌더
CTO는 팀 빌더여야만 한다. 좋은 팀 빌더, 나쁜 팀 빌더는 논외의 이야기.
C-Levels, 매니저, 리더 또는 소규모 팀을 조직해야 하는 조직원 등은 우선 팀 빌딩에 대한 본인만 방향을 가지고 있어야 한다.
과거 본인의 경험을 바탕으로하거나 여러 회사에서 사용하고 증명되어온 개발 방법론 및 조직 운영 법등을 사용해서 효과적으로 나만의 팀을 만들 수 있어야 한다.
팀 빌딩 시, "카더라"에 기반하거나 본인이 경험하지 못한 채 적용되는 운영법들은 팀 빌딩이 실패한다면 본인 뿐만 아니라 조직(회사) 평판에도 큰 영향을 준다는 것을 명심해야 한다.
CTO로 부임했으나 이미 팀(조직)과 운영 방법이 자리 잡혀있다.
고생이 많다. ^^;
지금의 팀이 가지고 있는 운영 방법이 무조건 틀리고 나의 방법론이 옳다는 식의 접근만 지양하라. 지금 팀의 운영이 안정적이지 않더라도 이 팀의 문화는 쉽게 바꿀 수 있는 것이 아니다. 시간을 두고 천천히 필요하다 싶은 부분만 조직원들과 이야기하면서 교정해라.
대다수가 자신이 성공한 방법을 여기서 새로 적용하면 좋다는 착각 아닌 착각을 하게 되는데, 급격한 변화는 CTO가 바뀐 것만으로 충분하다. 그리고 지금의 운영 방법이 "틀리다"가 아니라 "다르다"로 말 장난 하는 경우도 간혹 있는데, 급격한 변화를 주도 하는 것만으로도 "틀리다"를 몸으로 표현하는 것이라는 것을 잊지 말라.
회사의 조직 문화에 의해 개발 조직의 운영 방법을 바꾸기가 쉽지 않다.
개발 조직의 문화가 기업 문화로 안착된 회사가 아니라면 개발 조직 팀 빌딩에 가장 큰 걸림돌이 대 전제로 작용하는 기업의 문화다.
개발자에게만 배려가 너무 강한 개발 문화(개발자에게만 적용되는 어와둥둥)라면 개발 조직과 타 조직이 격리 되지 않다면 회사의 조직 문화와 조화가 힘들 수도 있다.
또는 회사의 조직 문화가 개발 조직과 맞지 않는 경우지만 회사의 문화가 우선 시 되는 경우도 있는데, 이 경우 별 수 없지 않은가? 지속적으로 개선 요청을 하는 수 밖에... 두드려라 언젠가는 열릴 것이다. 아니면 팀이 와해되거나 ^^;
C-Levels간의 R&R(역할과 책임)이 있는데 회사의 문화가 정체된 채로 변화가 없다는 것은 당신은 C-Level이 아닐 수도 있으니 C-Levels간의 대화가 필요하지 않을까 싶다.
시니어 매니저
CTO는 시니어 매니저여야만 한다.
자신의 조직의 리더와 매니저들이 당면할 수 있는 기술적이거나 트더블에 의한 심리적 이슈가 발생할 때, 큰 조직의 시니어 매니저(매니저를 위한 매니저)와 같이 다양한 경험 또는 기술적 우위를 바탕으로 당면한 이슈를 해결하거나 케어할 수 있어야 한다.
특히 작은 조직이라면 각 조직원은 리더 또는 매니저의 역할을 수행하기에 이 역할은 정말 중요하다 볼 수 있겠다.
여기서 "시니어" 라는 단어로 인해 시니어 매니저가 꼭 나이가 많아야만 가능하다는 생각을 하기 좋은데, 여기서 "시니어"는 해당 직무에 대한 "경험", "기술적 우위"가 중요하기에 나이가 많은 매니저가 경험에서 우위를 가질 수는 있지만 지금과 같이 여러가지 신기술이 어우러지는 환경에서는 경험과 기술은 나이와는 무관한 비즈니스도 많다는 것을 잊지 않았으면 한다.
말이 나온 김에 나이로 리스펙을 강요하는 조직원과 회사는 거르길 바란다.
커뮤니케이터 ( with C-Levels, Managers/Leaders/Staffs )
커뮤니케이션은 CTO가 하는 일 중에 가장 중요한 일이라고 생각한다.
- C-Levels과의 비즈니스와 회사 조직의 현재와 미래에 대한 논의
- 조직 내 매니저, 리더, 실무 조직원과의 업무 공유 및 지시, 진행 상황 및 결과 보고 체계 구성 및 개선
- 조직 내 발생하는 크고 작은 이슈에 대한 최종 책임자로서의 커뮤니케이션
등으로 나누어 볼 수 있겠다.
다른 C-Levels들이랑 커뮤니케이션이 되지 않는다.
C-Level에 대한 이해를 보면 C-Level들은 각자 맡은 분야 내외도 타 C-Level과 공유하며 회사 전반적인 업무와 프로세스를 알고 있어야 한다고 했다. 너무 기술적인으로 치우친 이야기가 아니라면 C-Levels들은 이해할 수 있다. 내가 너무 기술만 가지고 이야기하고 있지 않은지 또는 다른 C-Levels들이 타 C-Levels의 업무에 대한 정보 습득 게을리 하지 않는지 확인해 보길 바란다.
지금은 한 분야의 조직에서 비즈니스를 끌어가는 형태가 아닌 여러 조직이 각자의 분야의 전문성을 바탕으로 협업을 하는 문화가 정착된 경우가 많기 때문에 대화가 되지 않는다는 것은 나 또는 타 C-Levels에게 결격 사유가 있지 않나 생각된다.
개발 조직에서 나를 좋아하지 않는 것 같다.
"좋아하지 않는 것 같다"와 "좋아하지 않는다"는 다르다. 이 것부터 확실히 하기 바란다.
피터의 법칙을 아는가? 관료제의 관점으로 보면 CTO는 기술 조직의 최고 직위이다. 따라서 나는 언제나 무능한 사람으로 비추어 지는게 맞다. "나를 좋아하지 않는다"는 조직원이 나를 무능하게 보이거나 무능한 하기 때문에라고 생각하면 고민이 쉽게 풀리지 않을까 싶다.
"나를 위해 회사가 존재하는가?" / "회사를 위해 내가 존재하는 것인가?" / "나와 회사(조직)가 공존하길 원하는 것인가?"
위 세 질문은 하나의 질문이다. 답을 낼 수 있다면 내가 해야할 일은 쉽지 않은가?
자신이 가진 것을 내려 놓지 못하는 사람이 높은 직위로 간다면 그 결과는 뻔하지 않는가 ^^;
장담하건데, 작은 조직으로 성공한다 하더라도 큰 조직으로 바뀔 때 내려 놓지 못하는 성향이 권한을 나누는 과정에서 문제를 만들 확률이 높을 것이다.
그리고 사업 관리
당연하겠지만 CEO, 다른 C-Levels 과 함께 회사 각자 소임에 맞는 형태로 사업(또는 외부 사업)관리를 한다.
주로 CTO 기술 제안/영업, 사업을 위한 팀 조직/관리 및 팀 내 R&R, 감수 등이다.
직급을 받은 경우라거나 직급과는 다르게 역할(Roles)만 CTO인 경우라할 지라도 범위의 차이가 있을지언정 CTO가 해야하는 일은 위의 내용과 크게 다르지는 않을 것이다.
CTO가 하는 일이 너무 많은 것이 아닌가 생각할 수도 있겠지만 어디 다른 C-Levels들을 보라. 이 정도 안하는 사람이 있는지 ^^;
C-Levels은 결코 쉬운 직급이 아니다.
아무튼, ...화이팅!
