[Yonikim] 미드-시니어 개발자로의 성장

 

요새 회사에서 "너가 미드 개발자로서의 역할을 수행해야 한다" 라는 압박 아닌 압박을 계속해서 받고 있다. 이 말을 들었을때 가장 먼저 든 생각은,

 나는 아직 배워야 할 것 투성이고 다른 팀원들이랑 개발 년차 차이도 별로 안나는데, 내가 어떻게 중간관리자 역할을 수행해? 

였다. 시니어 개발자와 나 사이의 간극이 좁혀지려면 아직 멀었다고 생각했고, 개발자로서 성장하기 위해선 시니어 개발자에게 더 배워야만 한다고 생각했다.

 

집에 와서 내 미래에 대한 고민을 다시 해봤을때 '아, 회사가 나를 믿고 또 내 실력을 인정해주고 있기 때문에 이런 말을 해주는 거구나' 라는 생각과 함께 이제까지의 내 생각이 잘못되었음을 깨달았다.

배움과 성장에 대한 욕구는 언제나 있었으나, 이러한 욕구와는 다르게 안일함에 빠져 있었고 또 게을렀다는 걸 인정한다. 누가 알려줘야만 배울 것인가? 

 

그렇다면 미드-시니어 개발자로서 어떻게 성장할 수 있을까? 게임에서 레벨업 하듯이 어떠한 조건만 충족하면 시니어 개발자가 될 수 있는 것일가? 

 

---

주니어, 미드레벨과 시니어 개발자의 차이점

 

주니어, 미드레벨, 시니어 개발자는 수년간의 프로그래밍 경험과 연관된 것만이 아니다. 

 

1. 지식 

명백하게 시니어 개발자는 주니어 및 미드레벨 개발자보다 더 많은 지식을 보유하고 있다. 디자인 패턴, 아키텍처, 텍스트 자동화, 성능, 보안 등을 공부하는 것은 미드레벨-시니어 개발자들과의 격차를 줄이는 좋은 방법이다. 

소프트웨어 개발이 어떻게 이뤄져야 되는지에 대해서 아는 것은 중요하다. 하지만 이런 것들을 아는 것만이 시니어 개발자로 만들어주지는 않는다. 지식은 개발자들의 급을 정하는 가장 큰 지표가 아니다. 여러가지 지표들 중 하나일 뿐이다.

 

2. 코딩 

코딩은 컴퓨터와의 커뮤니케이션이 아니다. 코딩은 사람들 간의 커뮤니케이션이고 또한 컴퓨터를 가르치는 행위이다. 

코드는 미래에 그 코드를 작업할 다른 개발자(미래의 나 포함) 들이 이해할 수 있어야 한다. 코드를 한번도 본 적 없는 새로운 팀이 와서 코드를 열어본다 해도 코드만 보고 새로운 기능 개발과 버그 픽스를 시작할 수 있어야 한다. 

 

시니어 개발자는 단순하고, 단도직입적이며, 어쩌면 멍청해 보이기까지 하는 코드를 짠다. 이는 프로그래밍 분야에서 개발자가 가질 수 있는 가장 중요한 자질이다. 시니어 개발자는 KISS 법칙을 따른다. :Keep It Simple, Stupid

시니어 개발자의 코드는 관리적 측면과 스케일링 측면이 고려되면서 짜여진다. 시니어 개발자는 자신이 짠 코드를 미래에 다룰 다른 사람들을 생각하며 코딩을 하고, 주니어 개발자는 그저 컴퓨터에서 잘 돌아가는 것만 생각하며 코딩을 한다. 

 

미드 개발자들은 그들의 익숙한 작업 중에 나오는 문제들에 대해서는 올바른 질문을 할 순 있지만, 좀 더 복잡한 작업들에 있어서는 도움을 필요로 한다. 

시니어 개발자들은 '올바른 질문' 을 던질 줄 알며, 어떤식으로 이런 질문들을 풀어나갈지를 안다.

 

시니어 개발자들이 그들의 테크 스택을 꿰뚫고 있다는 것은 그다지 놀랄 일은 아니지만, 코딩 스킬 외에도 회사 내에서 쓰이고 있는 모든 툴들과 애플리케이션에 대해서 알고 있다는 것은 괄목할 만한 일이다.

 

주니어 개발자로써 더 성장하고 싶다면 코드를 간결하게 쓰는 연습을 해야 하고 개발 싸이클을 여러번 돌아봐야 한다.

시니어 개발자가 되기 위해서는 반복적인 일들을 처리하는 것 이상의 것들을 배우는 데에 집중을 해야 한다. 가장 어려운 문제들을 맡으려고 해야 하며, 나의 테크 스택을 마스터 해야 한다. 또한 자신보다 경험이 적은 개발자들의 버팀목이 되어야 한다. 

 

어떤 바보라도 컴퓨터가 이해할 수 있는 코드를 짤 수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. 

 

(출처: https://medium.com/react-native-seoul/주니어-미드-레벨-시니어-개발자의-차이점-955af58dd446)

 

 

---

시니어 개발자가 갖춰야 할 4가지

 

1. 기술적 리딩

기술적 리딩은 모든 것을 가르쳐 주는 선생님의 모습을 말하는 것이 아니다. 동료들과 함께 모르는 분야를 스터디하고, 후임 개발자가 기술을 스스로 깨우칠 수 있도록 인사이트를 제공하며, 때때로 리뷰나 페어를 통해 함께 세부적인 구현을 하는 것이다. 

 

2. 업무적 리딩

업무적 리딩은 기술적으로 판단을 내린 결과에 대해 책임을 지는 것을 말하는 것이 아니다.

개발을 시작할 때 작게는 프레임워크나 라이브러리를 선택하는 것부터 크게는 아키텍처를 구성하는 것까지 여러가지 진영이 존재하기 때문에 우리는 늘 선택의 기로에 서곤 한다. 뿐만 아니라 적용 시점을 언제로 할지 판단하는 것부터 내부적으로 구현 일정을 추정해야 하고, 더 나아가 대외적으로 협의해야 하는 경우도 빈번하게 일어난다.

이러한 결정과 추정 그리고 협의적인 측면은 기술적인 선택과 기술의 적용시점 판단 그리고 구현 규모나 일정 추정에 대해 적극적으로 의견을 내고 하나의 의견으로 만드는 것을 필요로 하는데, 이것이 바로 업무적 리딩을 지칭하는 것이다.

 

3. 생산성 우위

구현체를 많이 만들거나 유지보수성, 확장성이 높은 개발을 하는 것으로 생각할 수도 있다. 흔히 우리는 이런 개발자를 손이 빠른 개발자로 지칭한다. 단순히 요구사항을 빠르게 만드는 것에서 그치는 것이 아니라 더 나아가 품질이 보장되는 구현체를 만들고 만약 구현체에 문제가 발생하더라도 빠르게 해결을 해야 한다.

 

4. 난제의 해결

과거의 경험으로는 구현하기 어려운 상황에 처해있을때 원활하게 문제를 해결하는 것을 기본으로, 구현하기 어려운 제품의 기능을 RFC 문서나 레퍼런스를 보면서 체계적으로 만들 수 있어야 한다. 또한 까다로운 요구사항이 제시되었을 때 다양한 오픈소스를 찾아 이를 기반으로 커스터마이징해서 해결할 수 있어야 한다.

 

(출처: https://techblog.woowahan.com/2525/)