5  주니어에서 시니어로

주니어 개발자로서 (그리고 회사에 중급 단계가 있다면 중급 개발자/소프트웨어 엔지니어로서) 일에 익숙해지면, 자연스럽게 다음 단계인 시니어 개발자를 바라보기 시작할 것입니다.

무엇을 시니어 개발자로 볼지는 표준화되어 있지 않으며, 이에 대해서는 누구나 확고한 의견을 가지고 있습니다. 어떤 이들에게는 고성장 스타트업에서의 3년입니다. 다른 이들에게는 2년에서 8년까지 걸릴 수 있습니다. 또 다른 이들은 연차는 상관없다고 말합니다(진심일 수도 있고 아닐 수도 있습니다).

다른 사람들의 생각은 어느 정도까지만 중요합니다. 정말 중요한 것은 여러분의 회사(또는 여러분이 면접을 보는 다른 회사들)가 시니어에게 무엇을 기대하는지, 그리고 시니어 개발자의 시장 급여 수준에 걸맞은 보수를 지급하는지입니다. 결국 보수가 따르지 않는 시니어 직함은 아무 의미가 없습니다!

운이 좋다면 그 회사에는 시니어에게 요구하는 사항을 확인할 수 있는 엔지니어링 사다리가 있을 것입니다. 그렇지 않다면 전략 섹션에서 엔지니어링 사다리를 다룬 내용(장 26)을 확인하십시오.

결국 시니어 개발자라는 직책을 얻는 것은 두 단계로 이루어진 과정입니다.

1. 회사가 명시한 필수 기술과 성과를 (전부는 아니더라도) 충분히 갖추는 것
2. 그 직무에 채용될 만큼 요구 사항을 충분히 충족한다는 점을 성공적으로 내세우는 것, 즉 자신을 마케팅하기

즉, 공식적으로 시니어 엔지니어가 되기 전부터 시니어 엔지니어처럼 행동해야 하는 경우가 많습니다. 다행히도 이는 첫 직장을 구할 때 겪는 닭이 먼저냐 달걀이 먼저냐 하는 문제보다 훨씬 쉽습니다. 대부분의 회사는 현재 직무를 유지한 채로 더 많은 책임을 맡는 것을 기꺼이 허락할 것입니다!

5.1 원하는 직무에 걸맞게 행동하기

설문 조사를 해 보면, 개발자들은 다음 단계를 준비하면서 길러야 할 몇 가지 자질을 거의 한결같이 꼽습니다:

• 탄탄한 기술 전문성과 기초에 대한 완전한 숙달
• 팀 업무에 미치는 영향
• 다른 팀과 협업하는 능력
• “큰 그림” 보기
• 소통, 소통, 또 소통
• 다른 사람 멘토링하기

여러분의 엔지니어링 사다리에 무엇이 적혀 있든, 이러한 기술은 가능한 한 많이 연습하고, 연습하고, 또 연습하는 것이 좋습니다. 이는 경력 전반에 걸쳐 여러분 자신과 주변 사람들에게 도움이 되는, 시니어 엔지니어의 자질로 일반적으로 인정받는 것들일 뿐입니다.

참고: 이에 대한 자세한 내용은 시니어 개발자 장, 장 6

5.1.1 기술 전문성

기술 역량에 관해서는, 드레이퍼스 기술 습득 모델(Dreyfus Model of Skill Acquisition)에서 자신이 어떻게 성장하고 있는지 생각해 보십시오:

그림 「Dreyfus Model of Skill Acquisition」은 저작권자의 별도 허락이 필요하거나 출처가 확인되지 않아 번역판에 싣지 않습니다. 원문 사이트에서 그림 보기

지금까지의 여정에서 여러분은 아마 초보자(Novice)에서 능숙자(Competent) 단계로 나아갔을 것입니다. 자신의 분야에서 전문가(Expert)를 향해 나아가면서, 여러분은 메타 학습 기술에 주의를 기울이고 싶어질 것입니다. 즉, 자신의 일을 배울 때 제1원리에 기반한 직관(장 17)에 집중하는 것입니다.

주니어에서 시니어로 성장하는 과정에서 배우는 것의 상당 부분은 암묵지를 얻는 일입니다. 세상의 모든 프로그래밍 책을 읽을 수는 있지만, 정의상 여러분은 여전히 사람들이 글로 적을 수 있는 것에 한정됩니다. 그것이 바로 형식지이며, 여러분이 알아야 할 모든 것에 비하면 대개 빙산의 일각에 불과합니다.

Tacit Knowledge

엔지니어링에서 암묵지는 실제로 존재합니다. 수업이나 책에서는 배울 수 없는 모든 교훈에 늘 주의를 기울이십시오. 커리어를 정말로 폭발적으로 성장시키고 싶다면, 그 교훈들을 다른 모든 사람을 위해 글로 남기는 습관을 들이십시오(장 18 - 많이 쓰십시오!).

이 여정을 걷는 사람은 여러분만이 아닙니다. 수많은 동료 개발자들도 자신이 배운 것을 글로 남겨 두었습니다. 자신의 경험만으로 배울 수 있는 데에는 한계가 있습니다. 그렇다면 다른 사람의 경험을 빌려 보는 것은 어떻습니까? 직접 겪어 보는 것과 같지는 않지만, 예를 들어 공개된 포스트모템을 꼼꼼히 읽어 보면 가장 높은 평가를 받는 회사에서조차 많은 장애가 오류 처리, 설정, 하드웨어, 모니터링 부족, 그리고 사람의 실수를 허용하는 프로세스로 귀결된다는 사실을 알 수 있습니다.

5.1.2 커리어 전략

많은 사람들은 시니어 개발자를 “큰 그림을 볼 수 있는 사람”이라고 정의합니다. 모두가 그것이 중요하다는 데 동의하지만, 그것을 어떻게 정의해야 할지 정확히 아는 사람은 없습니다. 그것은 여러분의 기술적인 작업이 비즈니스/제품의 맥락에서 어떻게 들어맞는지, 혹은 코드베이스의 역사와 향후 로드맵 사이에서 균형을 잡으며 더 넓은 아키텍처 안에 어떻게 들어맞는지와 관련이 있습니다. 그러니 가끔씩은 일상적인 업무에서 한 걸음 물러나 더 넓게 바라보십시오!

큰 이동을 하기 전에, 자신이 원하는 것이 무엇인지 확실히 알고, 그에 앞선 6~12개월 동안 시간을 들여 그에 맞게 자신의 입지를 다져 두십시오. 시니어로서 GraphQL API를 만드는 일을 하고 싶습니까? 그렇다면 주니어일 때 먼저 해 보는 것이 좋습니다. 그 논리는 이렇습니다. 주니어에게는 그만큼 큰 영향력을 기대하지 않지만, 시니어에게는 분명히 기대합니다. 따라서 주니어나 중급 개발자로서 조금 더 오래 이리저리 자리를 모색하는 것도 가치가 있을 수 있습니다. 그렇게 하면 온 마음을 다해 몰두할 수 있는, 커리어를 결정짓는 시니어 개발자 역할을 맡기에 완벽한 위치에 설 수 있기 때문입니다. 더 좋은 방법은, 회사가 사내 “순환 근무”를 하는 직원을 공식적으로 지원하는 제도를 마련하여, 여러분을 붙잡아 두면서도 성장시키는 것입니다!

현재 직장에서 즐거웠던 일들을 목록으로 만들어 보는 것이 도움이 될 수 있습니다. 동료들 사이에서(여러분은 인맥을 쌓아 왔지요?) 특히 흥미로워 보이는 일들을 적어 두고, 회사나 프로젝트 안에서 그런 일들을 접할 기회를 얻도록 노력하십시오. 이것은 양방향으로 이루어지는 일입니다. 자신이 좋아하고 잘하는 것을 알아낸 다음, 그 일을 더 많이 할 수 있도록 자신의 입지를 다지는 것입니다.

참고: 이것이 바로 이 책의 전략 섹션 전체가 다루는 주제입니다!

그런데 무엇을 하며 일하기를 좋아하는지뿐만 아니라, 누구와 함께 일하기를 좋아하는지도 눈여겨보면 좋습니다. Keavy McMinn의 사례를 참고하십시오.

5.2 시니어 엔지니어로서 자신을 마케팅하기

아직 완전히 준비되지 않았다고 느낄 수도 있습니다. 지원하려는 시니어 엔지니어 직무나 승진의 요건을 모두 갖추지 못했을 수도 있습니다. 시도해서 손해 볼 것은 없습니다. 그것이 가면 증후군 때문에 드는 생각인지 아닌지도 알 수 없고, 처음에 실패하더라도 다음을 위한 값진 피드백과 연습을 얻게 됩니다!

아는 것과 아직 모른다는 것을 아는 것 사이의 더닝-크루거 효과를 기억하십시오.

Dunning-Kruger Effect

주니어에서 시니어로 넘어가는 사람들은 특히 “절망의 계곡”에 있거나 막 그곳에서 빠져나오고 있을 가능성이 높습니다. 그 곡선 위에는 마법처럼 반박할 여지 없는 시니어가 되는 지점이 존재하지 않습니다. 이 모든 것은 하나의 스펙트럼이며, 어쩌면 시니어들의 유일한 공통점은 능력 대비 자신감의 정점과 저점을 모두 겪고 회복했다는 것뿐일지도 모릅니다. 균형 잡힌 시각을 유지하기 위해 다른 사람들에게 자신이 잘하고 있는지 물어보거나, 자신이 아는 것을 가르쳐 볼 수 있습니다.

소수자 배경을 가진 개발자는 평가 과정에서 (의식적이든 무의식적이든) 구조적인 편견에 맞닥뜨릴 수 있습니다. 이는 불공평한 일이지만 동시에 엄연한 현실이기도 합니다. 신뢰받는 후원자는 여러분에게 큰 도움이 될 수 있습니다. 후원자를 찾기 어렵다면, Mekka Okereke가 “The Difficulty Anchor”라고 부르는 기법이 있습니다. 힘든 일이지만 강력한 지지자를 얻을 수 있는 훌륭한 전략입니다.

시니어 개발자로서 자신을 마케팅하기 시작할 때는 자신의 성과와 경험담을 정리해 두는 것이 좋습니다. 예를 하나 들자면, AWS 면접 과정에서는 AWS의 14가지 리더십 원칙 중 하나를 보여 주는 성과와 상호작용의 사례를 요구합니다. 대부분의 회사는 이만큼 형식을 갖추지는 않겠지만, “~했던 때에 대해 말씀해 주십시오” 같은 형태의 질문은 어떤 식으로든 하게 될 것입니다. 포트폴리오와 작업의 증거는 여전히 중요하지만, 주니어 시절 기여한 수많은 프로덕션 작업에 기댈 수 있으므로 그 중요성은 덜합니다. 인용할 수 있는 정량적 결과에 특히 주의를 기울이십시오. 연간 비용 절감액, 월간 활성 사용자 증가, 상호작용까지의 시간(Time To Interactive) 단축 등 여러분을 돋보이게 하는 지표라면 무엇이든 좋습니다.

특히 블로그 글쓰기, 발표, 팟캐스트, 동영상 튜토리얼 제작, 오픈 소스 활동 등 공개적으로 하는 모든 일은 지식과 인맥을 동시에 키우는 데 도움이 되며, 기회가 먼저 찾아올 가능성을 열어 줍니다. 모든 단계에서 가면 증후군과 맞서 싸워야 한다는 것을 기억하십시오!

참고: 전술(Tactics) 섹션의 자신을 마케팅하기 장(장 39)에서 더 많은 아이디어를 찾을 수 있습니다.

5.3 주니어 엔지니어, 시니어 엔지니어

개선할 방향에 대한 아이디어를 얻고 싶은 주니어 엔지니어라면, 일련의 대조되는 문장을 만들어 보는 것이 흥미로운 연습이 될 수 있습니다. 저는 온라인에 있는 주니어에서 시니어로 가기 위한 수많은 조언을 살펴보고, 이를 코드, 학습, 행동, 팀이라는 네 가지 범주로 나누어 약 30개의 비교로 정리했습니다. 이것은 요구 사항이 아니라 간결한 의견일 뿐이라는 점에 유의하십시오! 우리는 모두 어떤 면에서는 주니어이고, 다른 면에서는 시니어입니다. 이러한 아이디어의 요소들이 이 책 전반에 걸친 원칙, 전술, 전략에 스며들어 있음을 알게 될 것입니다.

5.3.1 코드

• 주니어는 해결책을 수집합니다. 시니어는 패턴을 수집합니다.
• 주니어는 코드가 동작하게 만듭니다. 시니어는 코드가 계속 동작하게 합니다.
• 주니어는 기능을 전달합니다. 시니어는 성과를 전달합니다.
• 주니어는 버그를 만든 후에 고칩니다. 시니어는 버그를 미연에 방지하는 도구를 만듭니다.
• 주니어는 요구되기 때문에 테스트를 작성합니다. 시니어는 좋은 테스트를 작성하도록 요구합니다 – 그렇게 하지 않으면 어떤 일이 벌어지는지 직접 보았기 때문입니다.
• 주니어는 기술 부채를 싫어합니다. 시니어는 기술 부채가 되어 버린 코드를 직접 작성해 본 적이 있습니다(그리고 언제 그대로 두고 언제 마이그레이션해야 하는지 압니다).
• 주니어는 코드를 DRY하게 유지하는 것을 좋아합니다. 시니어는 성급한 추상화를 피합니다(Avoid Hasty Abstractions).
• 주니어는 처음부터 최고의 코드를 작성하려고 합니다. 시니어는 코드가 작성되는 것보다 읽히고, 옮겨지고, 복사되고, 삭제되는 일이 훨씬 많다는 것을 이해합니다.
• 주니어는 도구를 사용하는 법을 압니다. 시니어는 언제 도구를 사용하지 말아야 하는지 압니다.

5.3.2 학습

• 주니어는 일회성 사이드 프로젝트를 만듭니다. 시니어는 자신의 사이드 프로젝트를 매일 사용하며, 이는 대개 본업에서 생산성을 높이기 위해서입니다.
• 주니어는 올바른 답을 찾는 법을 배웁니다. 시니어는 올바른 질문을 던지는 법을 배웁니다.
• 주니어는 자신이 알아야 할 것을 압니다. 시니어는 자신이 알 필요가 없는 것을 압니다.
• 주니어는 다른 사람에게서 모범 사례를 흡수해야 합니다. 시니어는 제1원리와 직접 겪은 고통으로부터 모범 사례를 도출할 수 있습니다.
• 주니어는 문서와 튜토리얼이 없으면 막힙니다. 시니어는 명세를 읽고 소스를 들여다보는 것을 두려워하지 않습니다.
• 주니어는 확고한 신념을 가지고 있을 수 있습니다. 시니어는 확고한 신념을 바꿔야 했던 경험이 있습니다.
• 주니어는 실패하면 자기 자신을 의심합니다. 시니어는 자신에게 시간을 더 주고 다시 시도하기만 하면 된다는 것을 압니다.
• 주니어는 뉴스를 빠짐없이 챙깁니다. 시니어는 트렌드(특히 메가트렌드 – 장 29)를 꾸준히 파악합니다.
• 주니어는 실수를 피하려고 합니다. 시니어는 이미 온갖 실수를 다 저질러 보았고, 어떻게 수습하는지도 압니다.
• 주니어는 소프트웨어 업계의 클리셰를 비웃습니다. 시니어는 그 모든 클리셰에 일말의 진실이 담겨 있다는 것을 압니다.

5.3.3 행동

• 주니어는 최고를 추구합니다. 시니어는 충분히 좋은 것을 사랑합니다(장 16).
• 주니어는 “예”라고 자주 말해야 합니다. 시니어는 “아니요”라고 더 많이 말해야 합니다.
• 주니어는 주어진 업무를 해내려고 노력해야 합니다. 시니어는 필요에 따라 자신의 업무를 재설계해야 합니다.
• 주니어는 오픈 소스에 대해 불평합니다. 시니어는 오픈 소스가 불평하는 사람이 아니라 기여하는 사람 덕분에 돌아간다는 것을 이해합니다.
• 주니어는 문제를 해결합니다. 시니어는 문제가 문제가 되기 전에 찾아냅니다.
• 주니어는 다른 사람들이 하는 말에서 출발합니다. 시니어는 자신에게 필요한 것에서 출발합니다.
• 주니어는 직접 만드는 방법을 압니다. 시니어는 언제 사서 써야 하는지 압니다.
• 주니어는 개발자 경험을 비교합니다. 시니어는 사용자 경험과 추상화 누수에 숨은 비용을 찾습니다.
• 주니어는 글쓰기를 뒷전으로 미룹니다. 시니어는 글쓰기를 코딩만큼 중요하게 여깁니다.
• 주니어는 주석을 남깁니다. 시니어는 맥락을 제공합니다.

5.3.4 팀

• 주니어는 자기 팀 안에서 일합니다. 시니어는 언제, 어떻게 팀의 경계를 넘어 일해야 하는지 압니다.
• 주니어는 자신의 성과를 키웁니다. 시니어는 팀의 성과를 키웁니다.
• 주니어는 모범 사례를 배우기 위해 페어링합니다. 시니어는 전문 지식을 나누고 사물을 새로운 시각으로 보기 위해 페어링합니다.
• 주니어는 끌려들어 갑니다. 시니어는 동의를 얻어 냅니다.
• 주니어는 신뢰를 얻어내야 합니다. 시니어는 신뢰를 불러일으킵니다.
• 주니어는 멘토를 찾아 나섭니다. 시니어는 동료에게서 배우는 법을 압니다.
• 주니어는 자기 자신을 발전시키는 데 힘씁니다. 시니어는 가르침, 멘토링, 리더십을 통해 팀의 역량을 몇 배로 끌어올리는 존재가 되어 팀을 발전시키는 데 힘씁니다.

이것들은 스스로를 발전시킬 방법에 대한 상상력을 자극하기 위한 간결하고 이상화된 비교일 뿐이라는 점에 유의하십시오. 저는 어떤 자질이 주니어나 시니어에게만 고유하다거나, 모든 시니어 또는 모든 주니어가 이 모든 자질을 항상 실천한다고 말하는 것이 결코 아닙니다.

5.4 남을 것인가, 떠날 것인가

마지막으로, 현재 회사에서 승진을 노릴 것인지, 아니면 다른 회사로 옮기면서 시니어 개발자로 도약할 것인지의 문제가 있습니다. 이는 여러분이 직접 결정해야 할 문제이지만, 적어도 다른 회사의 면접을 보는 편이 언제나 더 낫습니다. 다른 회사의 제안을 손에 쥐고 있으면, 현재 회사에서 승진을 요구할 거의 빈틈없는 근거를 갖게 됩니다.

이전에도 구직 활동을 해 본 적이 있으니, 이번에는 훨씬 수월할 것입니다. 일반적인 경로(온라인 채용 공고, 밋업과 콘퍼런스에서의 네트워킹)로 일자리를 찾는 것 외에도, 이 단계에서 여러분에게 열리는 새로운 기회도 알고 있어야 합니다. 예를 들어, 사내 채용 담당자, 외부 리크루터, 벤처 캐피털 등 온갖 부류의 채용 담당자가 여러분의 콜드 메일에 더 호의적으로 반응할 것입니다. 또한 온라인에서 쌓은 관계(글쓰기나 트위터를 통해서 말입니다. 그동안 꾸준히 해 왔겠지요?)를 활용하여 채용 공고가 나기 전에 기회를 찾을 수도 있습니다. 어떤 형태든 지인의 소개는 정문으로 지원하여 5초 만에 훑어보는 이력서로 다른 모든 지원자와 경쟁하는 것보다 낫습니다. 마지막으로, 시니어 개발자로서 자신을 어필하는 데 있어 큰 부분은 면접에서 자신의 경험 수준을 전달할 수 있는 능력입니다. 스토리텔링은 모든 시니어 채용 과정에서 놀라울 만큼 큰 비중을 차지합니다.

회사를 옮기면 연봉 인상 폭이 더 크다는 것은 잘 알려진 사실입니다. 5~10% 인상 대신 50~400% 인상을 받을 수도 있는데, 다른 도시에 있는 다른 업계의 회사에 다른 직급으로, 다른 급여 체계를 적용받으며 입사할 수 있기 때문입니다. 물론 이는 인생의 큰 변화이지만, 회사를 옮길 때 인상 폭이 더 큰 경우가 흔합니다. 또한 주니어 개발자였을 때는 협상력이 별로 없었다는 단순한 사실도 있습니다. 이제는 실제로 여유를 가지고 협상(장 31)을 연습해 볼 수 있습니다.

이력서를 다양하게 꾸리는 것도 고려해 볼 만합니다. 같은 회사에서 주니어에서 시니어로 올라가면 다양한 프로젝트, 기술, 의견, 문화를 접할 기회가 줄어듭니다. 에이전시에 있다면 스타트업으로 옮기는 것을 고려해 볼 만합니다. 스타트업에 있다면 대기업을 고려해 볼 만합니다. 대기업 경력은 일부 형태의 에이전시(프리랜싱 포함)에서 큰돈을 벌어다 줄 수 있습니다. 그 밖에도 여러 경우가 있습니다. 경력 초기일수록 여기저기 옮겨 다니며 자신에게 진정으로 맞는 곳을 찾기가 더 쉽습니다.

현재 개발자 브랜드가 좋지 않은 곳에서 일하고 있다면 개발자 브랜드가 좋은 곳으로 옮기는 것을 고려해 볼 만합니다. 그렇게 하면 인맥과 퍼스널 브랜드를 키우는 데 도움이 됩니다. 전 Google 엔지니어의 기술력을 의심하는 사람은 거의 없습니다.

반대로, 현재 좋은 브랜드를 가진 곳에서 일하고 있다면 실패의 위험이 더 낮으므로 더 큰 개인적 성장과 금전적 이익을 위해 다음 일자리에서는 더 많은 위험을 감수하고 싶을 수도 있습니다.