우리가 부르는 시니어 개발자는 누구인가?
• 신정호
살기위한 고민
큰 프로젝트를 마치기 전에 저의 진로를 두고 많은 고민을 하였습니다.
개발을 한지 10여년이 지났고, 짧은 시간안에 저의 Technology Tree에서 큰 가지가 나누어 질 것이라고 생각이 들었기 때문에 이 고민은 자연스럽게 삶에 대한 고민으로 이어지고 있었습니다.
그리고 수 많은 고민중에 “나는 어떤 개발자인가?”를 스스로 묻게 되었고, 그 중에 가장 먼저 들었던 생각이 시니어 개발자라는 뜻은 무엇이고, 나는 시니어인지를 되묻게 되었습니다.
이 글을 쓰는 지금은 시니어라는 의미에 대해 나름대로 일단락 지었고, 수 많은 자의적, 타의적 질문 시간을 가지면서 정리를 하였습니다. 물론 이렇게 일단락 지어진 내용은 결론이 아니라 진행형이고 언제든지 바뀔 수 있다고 생각합니다.
그리고 이제 더 나은 결론을 위해 제가 그동안 고민했고 일단락 맺었던 내용을 공유할까 합니다.
가장 먼저 “senior development”라는 간단한 키워드로 구글링을 해보면, 관련된 주제를 가지고 여러 블로그의 글들이 쉽게 검색이 됩니다. 그리고 stack exchange에서도 수백개의 비슷한 질문들을 연결시켜 주는 내용이 검색이 될 것 입니다.
또한 도서 중에서는 로버트 마틴 옹의 “Clean Coder”나 론 제프리스 옹의 “The Nature of Software Development”에서도 좋은 개발자에 대한 가치관이나 행동들을 이야기 하며, 소프트웨어 장인에 대해서 서로 비슷하게 이야기를 풀어 가는 모습을 찾을 수 있을 것 입니다.
다음은 클린코더에서 말하는 소프트웨어 마스터, 즉 장인에 대한 글 중 일부 입니다.
장인은 한가지 이상의 중요 소프트웨어 프로젝트를 주도했던 프로그래머들이다.
그들은 전형적으로 10년 이상의 경력을 가지고 여러 다른 시스템, 언어 및 운영 시스템 작업을 해왔다.
그들은 복수의 팀들을 주도하고 조정하는 법을 알며, 능숙한 디자이너와 건축가들이며, 힘들이지 않고 다른 모든 이들을 위해 코드를 처리할 수 있다.
그들은 경영직 제안을 받고도 이를 거절하거나, 자신들의 주된 기술적 역할과 통합 시켰다.
또한 판독, 연구, 실행, 및 가르치기를 통해 그런 기술적 역할을 유지한다.
the guardian의 개발자 블로그 포스팅 중에 “What does it mean to be a senior developer”에서는 시니어 개발자란 “다른 동료 보다 더 많은 전문지식을 가진사람과 다른 개발자를 리딩하거나 방향을 제시하는 사람”으로 이야기를 하고 있습니다.
이상과 현실의 차이
하지만 현실은 앞선 기준들과 다르게 시니어를 규정짓곤 합니다.
첫번째로 많은 개발 그룹은 연차에 비례해서 시니어와 주니어를 구분짓고 있습니다.
앞선 블로그의 글이나 유수한 책에서 다뤘던 기술력, 판단력, 소통능력을 중심으로 한 시니어에 대한 판단 기준들보다 우리는 개발 경력이 몇년정도 되는가로 시니어 개발자를 구분짓곤 합니다. 아마도 그 이유는 시간이 지나면 관련 지식도 늘어날 것이라는 생각과 시간에 따라 경험이 쌓일 것이라는 전제를 가지고 있기 때문일 것 입니다.
물론 1만 시간의 법칙처럼 끊임없이 어느 단계이상의 수준을 보이려면 절대적인 시간이 필요하다고는 하지만, 모든 사람들이 연차 만큼의 노력을 한다고 생각하는것은 적지않은 오류를 범할 수 있습니다.
그리고 정작 연차가 많아도 경력이 적은 사람과 지식의 차이가 나지 않거나 경험의 차이가 나지 않는 경우를 우리는 쉽게 접하곤 합니다.
두번째로 스타 개발자라는 명성으로 시니어 개발자를 판별하고 그의 모든 능력이 시니어에 가까울 것이라고 기대할 때도 있습니다.
물론 스타 개발자들 중에서 훌륭한 역량을 가지고 계신분들도 존재하지만, 반대로 여러가지 커뮤니티나 강의 또는 저서를 통해 한 순간에 스타 개발자가 만들어 질 때도 있습니다. 그래서 모든 스타 개발자가 시니어 개발자로 지칭되는 것은 매우 위험한 발상입니다.
특히 스타 개발자를 선망하는 분위기가 그룹내에 팽배해 있다면, 외부 활동을 하지 않고 묵묵히 현업에서 일하는 것을 중시하는 개발자는 마치 성장없는 개발자로 비춰지기까지 합니다.
가족 모임에 눈치를 보며 시스템 장애를 처리를 하고, 수 많은 트래픽을 받을 수 있도록 구현을 하며, 버그로 인해 끼니를 거르거나, 상용 배포에 너무 많은 신경을 쏟아부어 하루종일 두통을 겪은 현업 중심 개발자보다, 사람들이 모여드는 컨퍼런스에서 강연을 하고, 잘팔리는 책을 쓰는 개발자를 더 인정하는 이상한 문화가 만들어 질 수도 있습니다.
세번째로 특정 언어나 코딩 능력만으로 시니어 개발자를 판단하는 기준을 세울때도 있습니다.
협업 경험이 적은 개발자분들의 경우, IDE의 환경과 Development Kit에 해박한 개발자와 페어 프로그래밍을 하다보면 마치 선배 개발자의 손은 마술사의 손을 보는듯하고, 그의 아우라는 신을 보는 듯한 신성한 느낌을 받곤 합니다. 특히 신입에게는 선임이 짜 놓은 코드는 문제지의 정답풀이처럼 느껴지곤 합니다. 그래서 선임이 개발 해 놓은 코드를 보며 공부도 하고 이유를 묻기도 하며 하루하루를 감동의 나날들을 보냅니다. 그리고 선배에게 충성을 다 합니다.
하지만 이런 로멘스는 최대 반년이 지나면 여지없이 쌍욕으로 돌변하곤 합니다.
그럼에도 불구하고 개발을 잘한다고 생각하는 사람들의 코드는 오랫동안 후배 개발자의 입에 오르내리게 되는데 그 사람들의 코딩 결과물이나 그들이 가진 개념들을 이야기 해보면 다음과 같은 패턴이 보입니다.
- 트랜드로부터 구조를 잡는게 아니라 아키텍쳐 개념에 기반한 구조로 개발을 한다.
- 언어의 기본적인 개념을 알면서 코딩을 한다.
- 라이브러리나 프레임워크를 도입할 때에는 내부적인 구현 모습을 늘 탐구하고 이해하며 개발하는 모습을 보인다.
하지만 앞선 3가지 모습만을 갖춘 개발자를 시니어라 부를 수 있을까요? 그러기에는 뭔지 모를 2% 부족함이 느껴졌고 개발자에게 언어를 넘어서 어떤 부분을 채워야 하는지 고민이 되었습니다.
시니어가 갖춰야할 싸가지(4가지)에 대하여
대내외적으로 시니어라 불리우는 여러 사람들과 좋은 개발자의 모습에 대해 이야기를 나누고 메모를 하며, 그 기준을 4가지로 정리해 보았습니다.
1. 기술적 리딩
- “기술적 리딩”은 모든것을 가르쳐 주는 선생님의 모습을 말하는 것이 아닙니다. 동료들과 함께 모르는 분야를 스터디하고, 후임 개발자가 기술을 스스로 깨우칠 수 있도록 인사이트를 제공하며, 때때로 리뷰나 페어를 통해 함께 세부적인 구현을 하는 것을 말합니다.
2. 업무적 리딩
- “업무적 리딩”은 기술적으로 판단을 내린 결과에 대해 책임을 지는 것을 말하는 것이 아닙니다. 작게는 프레임워크나 라이브러리를 선택하는 것부터 크게는 아키텍쳐까지 여러가지 진영이 존재하고 늘 우리는 선택의 기로에 서곤 합니다. 그 뿐만아니라 적용 시점 역시 판단을 내려하는 경우가 빈번하게 일어나고 구현 일정 추정을 내부적으로 내리며 대외적으로 협의해하는 경우도 언제나 요구되곤합니다. 이러한 결정과 추정 그리고 협의적인 측면은 기술적인 선택과 기술의 적용시점 판단 그리고 구현 규모나 일정을 추정에 대해 적극적으로 의견을 내고 하나의 의견으로 만드는 것을 필요로 하는데, 이것이 바로 업무적 리딩을 지칭하는 것이라고 생각합니다.
3. 생산성 우위
- “생산성 우위”는 간단합니다. 구현체를 많이 만들거나 유지보수성, 확장성이 높게 개발을 하는 것으로 생각할 수 있습니다. 흔히 우리는 이런 개발자를 손이 빠른 개발자로 지칭합니다. 더 나아가 단순히 요구사항을 빠르게 만드는 것에 그치는 것이 아니라 품질이 보장되는 구현체를 만들고 만약 구현체의 문제가 발생하더라도 빠르게 해결을 하는 모습을 보이는 것이 다른 사람들 보다 생산성이 높다라고 평가 받곤 합니다.
4. 난제의 해결
- “난제의 해결”은 과거 경험으로 구현하기 어려운 상황에 처해 있을때 원할하게 문제를 해결 하는 것을 기본으로, 구현하기 어려운 제품의 기능을 RFC문서나 레퍼런스를 보면서 체계적으로 만들곤 합니다. 또한 까다로운 요구사항이 제시되었을때 다양한 오픈소스를 찾아 그 기반으로 커스터마이징해서 해결을 하는 것을 말합니다.(물론 생짜로 만들기도 하지요…)
시니어는 사실상 없다.
앞서 수립한 기준으로 저를 비롯한 많은 분들에 대해서 생각해 보았습니다.
하지만 현실에서 이런 4가지를 모두 만족하는 시니어는 매우 드물었고, 우리가 시니어라고 많은 분들을 이야기 할 만큼 흔하게 볼 수 없었습니다.
결국 현실에서는 전지전능한 시니어 개발자는 없거나, 만약 있다한들 가뭄에 콩날듯 아주 조금 밖에 없을 것 이라고 생각이 들었습니다. 이렇게 생각하는 것이 정신건강에 좋을 것 같았습니다.
이런 힘빠지는 이야기를 언급한 이유는 시니어를 바라보는 우리의 시선이 잘못된 경우를 심심치 않게 볼 수 있기 때문입니다.
특히 “시니어 개발자는 모든 문제를 다 풀수 있을 것”이라는 막연한 기대감이 우리에게 존재하는 가장 흔한 오류입니다.
이것은 팀으로 영입되는 시니어에게도 지독한 부담감을 주게 됩니다. 이러한 마스터적 기대감과 부담감은 서로에게 좋지 못한 결과를 낳기도 하는데, 가장 큰 문제는 불신과 과장을 낳는다는 겁니다. 영입된 시니어에게 품은 지나친 기대감으로 비롯된 편협한 특정 상황의 지식 비교는 시니어의 실력을 낮추어 평가하는 극단적인 결과를 초래하기도 합니다.
오히려 전지전능한 시니어 개발자는 팀이 만들어 가는 것이라고 생각합니다.
어쩌면 시니어는 존재하지만 시니어의 기준은 존재하지 않는다는 궤변을 말하고 싶습니다.
왜냐하면 A라는 그룹에서는 시니어로서 역량을 펼쳤던 사람이 B라는 그룹에서는 전혀 시니어로서 요구되는 역할을 하지 못하는 경우가 현실에서는 비일비재하게 일어나고 있습니다. 특히 앞서 제시한 4가지 기준에서 기술적 리딩과 업무적 리딩은 조직의 성숙도나 요구사항에 따라 달라질 수 있기 때문에 전지전능한 시니어 개발자라는 기준은 다시 매우 모호해지게 됩니다.
오히려 그룹에서 원하는 시니어의 조건들을 정확하게 세우고 구성원들과 공감하며 그 기준점에 대해 지향한다면 그룹에 맞는 전지 전능한 시니어 개발자는 우후죽순 많아질 것이라고 생각합니다.
지금의 등수라는 것은 비교할 수 있는 수천가지 중에서 몇 가지를 기준으로 선택한 거예요. 그렇게 등수를 매기다 보니까 ‘재는 공부 잘하고, 얘는 못하고’이렇게 되지만 등수 매기는 주제를 바꿔버리면 결과도 바뀌겠죠.
그 상황, 그 시대, 그 시간, 그 조건에서는 서로 비교해서 그사람이 어떠어떠하다고 말할 수는 있어요. 그러나 그렇다고 그 사람이 우월한 것도 아니고, 그렇다고 그 사람이 열등한 것도 아니에요.법륜 스님의 즉문즉설 중에서…
기술 트랜드는 빠르게 바뀌어 가고, 수 많은 라이브러리는 쏟아지며, framework는 나날이 고도화 되어가고 있습니다. 특히 새로운 패러다임이 세상에 안착되고 나면, 그와 관련된 지식들은 파생되어 에어리언처럼 또 다른 지식들을 낳아버리곤 합니다. 그리고 수 많은 진영들이 비슷한 모습을 이루며 발전되어 선택되거나 버려지고 있습니다. 이런 가운데, 특정 지식이나 기술의 경험으로 시니어를 분간하는 것은 큰 오류를 범할 수 있을 것 같습니다.
소프트웨어를 만드는 데에 절대적으로 올바른 방법은 없는 것처럼 시니어 역시 절대적인 기준은 없는 것 같습니다.