경력의 방향성: 테크니컬 리더(Technical Leader)

업무를 하다 보면, 시키는 일만 하다가 문제를 해결하는 단계를 거쳐 문제를 만드는 단계를 거쳐 올라가게 되는 것을 경험하게 된다. 나는 이게 리더가 되어 가는 과정이라고 생각한다. 내 경험으로 비추어 보면, 소프트웨어 개발하는 사람들의 중요하게 생각하는 경력 방향이 조금씩 바뀐 것 같다. 어느 것이 더 중요하고 덜 중요하다고 생각하지는 않는다. 하지만, 방향성을 가지고 가는 것이 필요한 역량을 준비하는데 효율적이지 않을까 하는 생각한다.

개발자의 경력 방향

내가 생각하는 경력의 방향은 3가지 이다.

내 경력의 초창기에는 과제의 대한 넓은 이해를 바탕으로 제품 출시에 대해서 Risk가 되는 항목을 관리하는 것이 주요 목표인 Project Leader가 중요했다. 이런 부분에 대해서는 PMPBOK[1]과 같이 일반적인 프로젝트 관리(Project Management) 혹은 SW만을 위한 RUP(Rational Unified Process)와 같은 방법론을 중요하게 여기었다. 지금도 큰 회사들은 범위가 큰 제품을 다루기 때문에 이러한 프로세스를 도입하거나 혹은 자체 운영 프로세스를 운용하고 있다. 여러한 운영하는 역할을 가진 Leader들은 여전히 중요한 역할을 하고 있다.

또한, Agile Software가 소개 되면서, 목표 중심의 접근 방법에서 사람 중심, 소통 중심의 작고 기민한 개발 방법으로의 변화가 이루어지고 있다. RUP에서도 이러한 Agile한 접근 방법은 XP(eXtream Programming), Scrum, Kanban등 다양한 Practice들이 소개 되었고, 계속해서 표면적인 Practice만이 아닌 가치와 원칙들을 기반으로 시도되고 있다.

소프트웨어 개발자도 결국은 제품을 만드는 사람이고, 이 제품은 요구 사항을 구현하여 상품화 하는 것이다. 제품의 요구 사항은 당장 스마트폰만 보더라도 어플리케이션, 미들웨어, 시스템 소프트웨어와 같은 큰 분류가 있고, 좀 더 세밀하게 들어가면 해당 분야가 필요로 하는 지식이 전혀 다르다.

단적인 예로 Video 어플리케이션만 하더라도 비디오를 재생하는 부분, 그리고 압축되어 있는 비디오를 사용자가 볼 수 있도록 압축을 풀어 주는 부분,그리고 이 압축 풀린 비디오를 화면에 뿌려 주는 부분 그리고 이 동작을 통합하여 사용자와 연동하는 부분으로 세세하게 나눌 수 있다. 이러한 기술 분야(Technology Domain)가 엄밀히 말하면 모두 다르다고 할 수 있다. 비디오 압축을 풀어주는 Video CODEC 그리고 압축 풀린 화면을 그려주는 Graphic 부부분으로 Domain이 다르다고 할 수 있다. 이러한 분야별로 전문가인 Domain Expert들이 필요하게 되었고 이러한 인력들이 Technical Leader들이 떠오르기 시작했다.

요즘 소프트웨어 회사에서 인력 채용을 할 때에는 코딩 면접을 본다. 예전의 기술 면접과는 차이가 있다. 관련 분야의 Knowledge를 측정 하기 보다는 자료구조 및 컴퓨터 알고리즘에 대한 기본적인 이해, 그리고 실재로 프로그래밍을 할 수 있는 소양, 센스를 확인하는 듯한 느낌이 강하다. 즉, 회사에서 바라는 Software 개발자의 인재상이 바뀌고 있다는 생각이 든다. 이러한 개발 역량은 과제를 운영하거나 특정 분야의 지식으로 만으로는 부족하다고 보고, 실재로 작동하고 복잡한 소프트웨어를 설계하고 구현할 수 있는 인력들을 원하며, 이러한 소프트웨어 개발 역량을 가진 사람들을 Software Architect라고 부르고 있다. 

후배들에게 하는 조언

나는 위에서 이야기 한 Project Leader, Domain Expert 그리고 Software Architect를 개발자의 Career Path로 보고 후배들에게 조언을 하고는 한다.

사람들과 Interaction을 좋아하면서, 제품을 만들어 가는 관점에서 소프트웨어 개발에 관심이 높은 사람들에게는 Project Leader와 관련 내용을 소개하곤 한다. 특히, Agile Software Development에 대해서 많이 설명한다. 나는 XP의 Pair Programming이나 TDD 등에 대해서 관심을 가지고 있었었고, 지금은 Kanban을 일부 적용하면서 사람들과 소통에 대해서 관심을 가지고 있다. 이러한 부분을 소개하면서, 반응을 살피고, 관련 내용, 교육을 소개한다. 자격증도 있어서, 관심있으면 획득하는 것도 좋다고는 이야기 하지만, 꼭 필요한 것은 아니라는 내 생각도 이야기 해준다.

대학원 석사/박사를 희망하는 사람도 종종 있다. 요즘 유행하는 Machine Learning과 같은 학문적인 관심을 가지고 있는 사람들이다. 석사/박사를 하게 되면 무엇이 다른가에 대한 질문이기도 하다. 나는 학사는 내 전공이 어떤 분야인지 이해하는 과정이고, 석사는 해당 분야의 주어진 문제를 푸는 방법을 배우는 과정이라 설명한다. 박사는 한마디로 인류 지식의 지평을 넓히는 사람이라고이야기 한다. 즉, 특정 분야의 "의미있는 문제"를 찾아 다른 사람이 해보지 않은 "새로운 방법(Novel Way)"으로 해결하는 것이라고 설명한다. 이 방향이 Domain Expert가 되어 가는 과정이다. 

Software 개발 역량은(SW Development Competency)는 개발자로의 기본 능력이라고 생각한다. 그래서, 아직은 많은 고민을 하지 못한 후배들에게는 이 부분을 설명한다. 컴퓨터 언어, 알고리즘, 그리고는 설계 관련 이야기를 한다.  이와 같이 이야기 하는 이유는 두 가지 정도이다.

하나는 이 부분이 Software 개발자로서의 경쟁력이기 때문이다. 이야기 한데로, 여러 회사들이 인력 선발할 때 살피는 기본적인 부분이다. 신입이든 경력이든 개발자로 살아 남으려면 기본적으로 이부분이 준비 되어 있어야 한다.

또 하나는 생산성이 다르기 때문이다. 실재 업무는 새로운 기능을 구현을 하거나 기존 코드 (Legacy Code)의 이슈를 수정하는 것이 시작이다. 이 때, Software 개발 능력은 매일 사용해야 한다. 그렇기 때문에, 이 능력의 높고 낮음에 따라 생산성에서 큰 차이가 발생한다.

그래서 나는?

위의 어느 것을 선택하여 나아가던 선택의 문제이지 어느 것이 더 낮다고 이야기 하지는 않는다. 개인 선호도의 문제이기도 하다. 물론, 무시하기 어려운 것은 인력 시장의 선호도 혹은 관련 분야의 전망 또한 선택하는 사람 입장에서는 고려해야 할 부분일 수도 있다. 

하지만, 정말 훌륭한 Technical Leader로 가는 길은 여러 갈래길 나뉘어 져 있지만, 어느 순간에는 만나고 어느 순간에는 갈라진다고 생각한다. 위에서 이야기 한 3가지 방향 중 어떠한 것을 가더라도 서로를 완전히 때어 놓을 수 없고, 다시 만난다. 소프트웨어 제품을 만들다 보면, 사람들과 소통하고 Risk를 관리하는 방법을 배우게 된다. 특정 제품의 해당 기능을 구현하다 보면, 관련 Domain Knowledge가 쌓인다. 실재 개발을 하다 보면, 관련 컴퓨터 언어, 알고리즘 그리고 설계를 배우게 된다. 즉, 업무를 통해서 학습하게 된다. 

중요한 것은, 이런 부분을 자세히 살피지 않으면 알지 못할 수도 있다. 자신이 있는 단계에서 한단계 더 넘어 서려면 더더욱 그러하다. 그래서, 깨어 있어야 하고 공부해야 한다고 생각한다.

지금의 나는 다행이도 여러 가지 경험을 하고 있고, 오늘도 배우면서 좀 더 성장한 내가 되기 위해 고민하고 있다. 그래야, 후배들에게도 그들이 고민하는 부분에 대해서 나의 생각을 이야기 해주고, 그들이 선택하여 나아갈 수 있도록 해줄 수 있다고 믿고 있다.

[1] PMBOK Guide and Standard, https://www.pmi.org/pmbok-guide-standards