개발자

개발·전략 모두 할 수 있다면··· ‘코딩 리더’에 주목할 이유

Matthew Tyson | CIO 2022.06.02
개발자의 정년은 짧아서 관리직 전환만이 유일한 전망이며, 이러한 전환은 현업으로 돌아갈 수 없는 외길이라는 인식이 많다. 하지만 이러한 인식이 바뀌고 있다. 

소프트웨어 업계의 많은 리더가 개발자 출신이다. 개발자는 기술에 능숙해지고 자신감을 얻으면서 경영진으로 커리어를 확장하기를 원하지만 한편으론 성취감을 주는 현업 생활을 포기하고 싶어하지 않는다.
 
ⓒGetty Images Bank

그렇다면 ‘코딩 리더’라는 커리어를 살펴보자. 이 새로운 리더 유형은 ‘전략’ 그리고 ‘기술 실무’를 모두 담당하며 비즈니스와 기술 부문을 망라한다. 최신 코딩 기술을 놓치지 않는 이 리더는 프로젝트 운영 역량을 갖추고 있고, 업계 발전 상황을 훤히 꿰고 있으며, 기업에 변화가 필요한(혹은 가장 도움이 될 수 있는) 부분을 파악할 수 있다. 

그리고 이 트렌드는 소프트웨어 업계의 사소한 문제 중 하나로, 개발자 사이에서 자신이 형편없는 관리자 밑에서 일한다고 느끼는 문제를 해결하는 데 도움을 줄 수도 있다. 

오해 : 프로그래머는 좋은 리더가 될 수 없다
코드 개발자의 일상적인 업무는 상세하고 한 줄 한 줄씩 이뤄지는 경우가 많으며, 숲보다는 나무를 보는 경향이 있다. 엔지니어에게 ‘위험’은 (무언가를) 구축하는 데 사로잡혀 자신이 하는 일의 비즈니스적 가치를 놓치는 것이다. 이를 일시적인 기술적 과제(다리 건설)로 인해 더 높은 목적(점령군 저항)을 무색하게 만드는 ‘콰이강의 다리(Bridge on the River Kwai) 실수’라고 생각한다. 

하지만 개발자의 역할이 커지면서 (개발자의) 비전은 개별적인 요소(기술)를 파악하는 것뿐만 아니라 더 많은 시스템과 프로세스까지 포괄한다. 숙련된 개발자가 특히, 개발 중인 특정 시스템에 관한 지식이 광범위해지면 고부가가치 영역에 뛰어들거나 변화를 지원하거나 높은 수준의 관점을 유지할 수 있다. 아울러 비즈니스 감각까지 더하면 금상첨화다. 

여기서 코드 개발자에게 필요한 사고방식의 변화는 우선순위의 균형을 고려하는 것이다. 실무를 뛰는 개발자는 코딩 외에 다른 모든 것이 방해된다고 보는 경향이 있지만 성공적인 코딩 리더는 비즈니스 및 기술 요구사항의 중요성을 고려해야 한다. 이는 일과 삶에 동등하게 주의를 기울이는 워라밸과 유사하다.

코딩 리더는 나무와 숲을 포함하는 넓은 시야를 유지하는 방법, 나무와 숲 사이를 전환하는 방법, 나무와 숲 사이에서 정보를 주고받아 인사이트를 흐르게 하는 방법을 알아야 한다. 물론 사람들을 이끄는 일도 포함된다.

또 다른 오해 : 코드 개발자는 인간관계가 좋지 못하다
이는 진부한 생각이다(물론 어느 정도는 사실이기도 하다). 기계는 논리적이고 적절한 방식으로 명령을 내리면 원하는 행동을 수행하게 할 수 있다. 사람은 그렇지 않다. 사람을 이끄는 일은 조금 다르다. 개발자가 실무에서 다른 사람을 이끄는 역할로, (더 나아가) 관리자를 이끄는 역할로 나아가면 그 차이점이 더 커진다.

어떤 사람은 인간관계와 관련해 사람들의 니즈, 두려움, 욕망을 이끌어내는 방법, 성격 차이로 인한 갈등이 발생하는 곳을 감지하는 방법, 사람들이 성장할 수 있는 곳을 보는 방법, 직원과 효과적으로 소통하여 직원은 물론 기업의 성공을 지원하는 방법 등의 요령을 잘 알고 있다.

하지만 나머지는 이러한 요령을 학습해야 하며, 때로는 학습이 어려울 때도 있다. 코드 개발자도 다르지 않다. 인간 상호작용의 중요성을 인정함으로써 코드 개발자는 For-루프(for-loop) 또는 기능 구성요소 작성이 겁나고 이질적이었을 때 그랬던 것처럼 인사이트와 스킬을 얻을 수 있다. 회사의 내부 사정은 인터넷만큼 복잡하다. 물론 코드 개발자는 다른 코드 개발자와 기술 인력을 이끄는 데 유리하다는 장점이 있다.

코딩 리더도 ‘같은 사람’이다
모든 개발자는 다음의 시나리오를 알 것이다. 프로젝트 관리자가 어슬렁어슬렁 걸어 들어와 간트 차트(프로젝트 관리 도구)를 보면서 터무니없는 예상을 하기 시작한다. 아니면 민망하게도 유행어를 남발하기 시작한다. 개발자에게 비즈니스 요구사항을 효과적으로 전달하는 것은 중요하다. 둘 사이의 효과적인 다리가 되는 것은 더욱더 중요하다.

실제 경험보다 좋은 것은 없다. 이를테면 참호 안에 있을 때 어떤 느낌인지 알 수 있는 건 상당한 가치가 있다. 실무 개발자의 입장에서 생각할 수 있는 역량은 기술 관리 성과를 개선하는 데 중요한 부분이다.

‘코딩 대 관리’의 문제를 조사하고 고민하던 중에 우연히 자동차 정비소에 갈 일이 있었다. 매장 규모가 꽤 컸는데, 주인이 직접 자동차 밑에 들어가서 문제 진단을 돕는 것을 봤다. 리더가 의지와 역량이 있다면 엔지니어는 분명 존중하게 된다. 이러한 존중과 애정은 리더를 ‘우리와 같은 사람’으로 보는 소프트웨어 세계에서도 마찬가지다.

리더가 계속 코딩을 해야 하는가?
코드 개발자이자 관리자인 몽고DB(MongoDB)의 CTO 마크 포터는 “다양한 유형의 CTO가 있다. 소규모 회사의 첫 제품 개발을 주도하는 CTO는 반드시 코드를 개발해야 한다. 아웃바운드 활동에 집중하는 대기업의 CTO는 그렇지 않다”라고 말했다. 즉, 직접 코딩을 포기해야 하는 역할이 있지만 코딩을 좋아하고 계속하고 싶어 하는 동시에 관리직으로 승진하고 싶은 사람을 위한 역할도 있다. 

요즘에는 깊이 있는 실무 기술 지식을 갖춘 유명한 리더를 쉽게 찾을 수 있다. 이를테면 AWS의 워커 보겔스와 브레이브(Brave)의 브렌든 에이크는 실무 개발자가 우려하고 있는 온갖 구체적인 사항을 알고 있다. 기술 도구 영역에서 이러한 종류의 전문 지식은 더욱더 빛을 발한다. 코딩 리더는 사내 개발자뿐만 아니라 고객과도 관계를 돈독히 할 수 있다. 코딩 리더는 개발자가 축구 선수나 전투기 조종사보다는 클래식 음악가와 같다는 것을 보여준다. 클래식 음악가는 악기를 연주할 줄 아는 지휘자로 성장할 수 있다.

커리어 패스와 관련해 코드 개발자 또는 IT 리더 중 하나(또는 앞으로 나아갈 길을)를 선택해야 한다는 개념이 점차 모호해지고 있다. 이것이 분리보다는 스펙트럼으로 볼 수 있다. 한쪽 끝에는 순수한 비즈니스 리더가 있고, 다른 쪽 끝에는 순수한 엔지니어가 있다. 대부분의 CIO, CTO 또는 여타 기술 리더는 두 가지 측면을 일부 혼합할 것이고, 코딩 리더는 이 스펙트럼의 중간 정도에 위치한다.

관리자가 돼야 할까? 아니면 코드 개발자가 돼야 할까? 아마도 정답은 ‘둘 다’일 것이다.

* Mattew Tyson은 다크 호스 그룹의 설립자다.
ciokr@idg.co.kr
 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.