CTO와 그냥 개발자의 차이
프로그램을 아주 잘 짜는 사람은 CTO로 적임자일까? 연차가 비슷한데 시니어 개발자라 불리는 사람과 CTO의 차이는 무엇일까? 공허한 질문일 수도 있지만 페친인 박훈님을 통해 알게 된 기사를 읽고 내 안에서 생겨난 질문을 글로 써본다. 그리고 글로 남겨진 기존에 했던 비슷한 생각을 엮어본다.
CTO의 전형처럼 보이는 태도를 글로 쓴 저자
<The Best Engineers Think Like Investors, Not Builders>라는 제목의 글, 가장 마지막에는 파트타임으로 CTO 역할을 해주겠다는 저자의 디지털 명함이 있다. 글을 읽어 보면 그는 딱 CTO라는 말에 어울리는 태도에 대해 구체적인 견해를 밝히고 있다.
단어 정의만 두고 보면 기사의 태도가 CTO의 전형이라는 나의 느낌을 설명하기 어렵다.
Chief technology officer, an executive officer in an organization focused on scientific and technological issues
그래서 내 느낌의 근거라고 할 수 있는 관련 글을 찾아보았다.
모던 아키텍트와 CTO
<모던 아키텍트에 대해 개념 잡아보기>란 글을 쓴 적이 있다. 2018년 축적의 시간이란 책을 읽다가 저자인 공대 교수님들의 지적에 영감을 받아 쓴 글이다.
저는 스티브 잡스가 아키텍트였고 좋은 아키텍트들을 곁에 많이 두고 있었다고 봅니다. 바로 이 아키텍처를 가진 혁신가의 생각이 노키아와 애플의 성쇠를 가른 것이죠. - 박영준 교수(서울공대 전기정보공학부/나노, 바이오 응용)
당시 여기서 말하는 아키텍트가 소프트웨어 개발자 사이에서 말하는 소프트웨어 아키텍트와는 상당한 차이가 있다. 하지만, 이 책의 다른 교수님들이 다른 공학 분야에서 공통으로 발생하는 대한민국의 약점으로 개념 설계 역량 부족을 지적하는데, 나는 이 부분이 소프트웨어 아키텍트의 역량과 맞닿아 있다고 생각했다.
산업 분야와 상관없이 우리 산업이 처한 공통적인 문제를 가려 뽑고자 할 때 가장 많이 제기된 키워드는 '개념설계conceptual design' 역량의 부재였다. 개념설계 역량은 제품 개발이 되었건, 비즈니스 모델이 되었건 산업계가 풀어야 할 과제가 있을 때, 이 문제의 속성 자체를 새롭게 정의하고, 창의적으로 해법의 방향을 제시하는 역량으로서... - 이정동 교수(서울공대 산업공학과/기술경영, 정책)
이는 작년에 쓴 <트레이드오프와 아키텍트 그리고 개발자의 소통 문제> 편에서 다룬 상충관계 해결과 밀접한 관련이 있다고 생각한다. 조직의 목표를 향해 나아가는 과정에서 벌어지는 다양한 상충관계를 해결할 수 있어야 한다.
게다가 그러한 상충관계는 조직 내 권력이나 참여자들의 욕망이 부딪히는 상황을 담기도 한다는 점을 담아 최근에 쓴 <아주 이상적인 아키텍처>란 글도 있다. 이들 글에서 다룬 소통의 중심 혹은 중재자 역할을 하는 아키텍트가 CTO와 다른 사람인가? 같은 사람인가?
소프트웨어 개발 방식의 진화
<모던 아키텍트에 대해 개념 잡아보기>편을 쓸 때 인용한 <아키텍트의 죽음(The Death of the Architect)>은 개발 방식의 변화에 따른 현상을 풀어낸 글이라 생각한다. 당시 인용했던 아래 도식은 이를 잘 압축해서 보여준다.
개발과 유지보수라는 이분법이 소프트웨어 개발 단계를 바라보는 주된 시각이던 시절(표에서 2000년 이전)에는 중앙집중적 분업 형태로 개발이 되었고, 아키텍트는 소통과 설계의 중심이 되었다. 그러나 그 후 10년(2000 ~ 2010)의 세월동안 서비스 형태로 소프트웨어가 개발되고 배포되는 일이 늘어난다. 예를 들면 네이버 같은 인터넷 기업이 급부상하는 일을 보라.
그리고 다음 단계에서는 클라우드와 오픈 API 등이 등장하면서 한 기업에 속한 아키텍트가 전체를 관장하는 일이 불가능하거나 효과적이지 않은 상황으로 바뀌어 가고 있다. 물론 그러한 역할 자체는 필요하지만, 일하는 방식이나 권한의 범위 등이 다양한 형태로 바뀌었으리라 추정할 수 있다.
무엇이 경제적인가?
다시 처음에 언급한 기사인 <The Best Engineers Think Like Investors, Not Builders>로 돌아가 보자. 나는 기사 처음에 언급한 작업의 경제성을 설명하는 다양한 문구를 볼 때 대번에 Kent Beck을 떠올렸다. 찾아보니 비교적 근래에 쓴 <소프트웨어 커플링의 의미는 무언가?> 편에 '무엇이 경제적인가?'라는 구절이 있었다.
그리고 2014년 혼자 학습하는데 그쳤지만 영감을 주었던 SAFe의 Lean Budgets 이미지도 보였다. Lean Budgets을 집행한다고 할 때, 의사결정을 하는 보드진이 바람직한 의사결정을 할 수 있게 촉진하고 평소 그런 일상이 문화로 구현되게 하는 사람을 뭐라고 불러야 할까?
출처: SAFe이렇게 질문하면 아키텍트라는 타이틀보다는 CTO가 더 적합하다. 이러한 관점은 조직 운영이나 경영의 IT 거버닝 관점이다.
최고의 엔지니어가 CTO
이제 관점을 전혀 달리 해서 <The Best Engineers Think Like Investors, Not Builders>의 관점을 추출해보자. 저자는 이렇게 주장한다.
In engineering, developing the investor mindset will get you further than knowing the latest tech fad.
나는 이를 엔지니어 관점 혹은 엔지니어의 경력 개발 관점이라고 본다. 이렇게 관점을 틀어서 보면 (조직이나 시장에서 평가하는) 최고의 엔지니어가 CTO가 돼야 한다는 논리로 나의 질문(CTO와 그냥 개발자의 차이)과 질문을 기사와 연결할 수 있다.
이런 그림을 이해하면 투자자의 태도를 지녔다고 할 수 있다. 그렇다면 이치로만 따져 투자자가 원하는 엔지니어가가 될 수 있다. 그리고 당연하게 이런 이해(개념)를 실천으로 바꿀 수 있은 노하우와 훈련이 되어 있어야 한다.
