주니어 개발자와 사이드 프로젝트
2021년 07월 11일 작성TL;DR
주니어라면 매일의 업무와 관련된 주제로만 사이드 프로젝트를 하자
시작하며
업무 특성상 주니어나 막 주니어를 벗어난 개발자들과 일할 기회가 많다.
대부분의 경우 프로젝트 마무리쯤 이르러서 커리어와 관련된 질문을 한다.
앞으로 무엇을 더 공부해야 하는지? 또는 현재 이것을 공부하고 있는데 이 방향이 맞는지? 등
성장방향과 방법에 대한 질문이 주된 내용이었다.
열정 넘치는 주니어 개발자들이 공부를 위해서 많이 택하는 방법이 사이드 프로젝트이다.
본 글에서는 주니어 개발자가 사이드 프로젝트를 진행할때 생각할만한 내용을 간단히 적어본다.
개발자 단계
일단 주니어 개발자가 뭔가에 대한 정의를 해보자.
3년이하의 개발자 이런식으로 연차로 나누는 경우도 있는데, 이건 연봉테이블을 만들기 위한 인사팀의 기준이므로 일반화 하기에 적절하지 않은 기준인 것 같다.
기술력을 기준으로 나눌수도 있겠지만, 요새 3년 미만개발자중에도 최신 기술이나 트렌드를 수족처럼 다룰 수 있는 사람들도 많으므로 적절하지 않은 것 같다.
그래서 여기서는 (개인적으로 항상 무난하다고 생각하는 기준인) 데일리 업무에 대한 지속성을 기준으로 나눠본다.
(참고로 리더와 시니어는 전혀 별개이다. 시니어는 업무처리의 시니어리티를 가리켜서 시니어라고 부르기 때문이다. 팀을 리딩하고 멘토링하고 팀원을 케어하는 리더와는 전혀 다른 카테고리이다.)
주니어 개발자
주니어 개발자는 1주일 내외의 지속성을 가지는 업무를 주로 처리한다.
프로젝트 내의 모듈이나 버그에 대한 수정 등의 업무를 주로 처리한다.
구현한 내용이 베스트 프랙티스인지 아닌지에 대한 판단이 불가능하다. (일단 돌아가게는 했는데 어떻게 더 고쳐야 할지는 잘 모른다.)
본인이 맡은 모듈이나 프로젝트가 향후 어떻게 발전될 지에 대한 그림은 그리지 못한다.
일반 개발자
주니어를 벗어난 개발자는 1달 내외의 지속성을 가지는 업무를 주로 처리한다.
대부분 주어진 프레임워크 위에서 간단한 마이크로 서비스를 개발하거나, 약간 복잡한 모듈을 개발하게 된다.
구현한 내용이 베스트 프랙티스 인지 아닌지에 대한 판단이 쉽지 않다. (뭔가 더 나은 방법이 있는 것 같다는 느낌만 있다.)
본인이 맡은 프로젝트가 향후 어떻게 발전될 지에 대한 내용은 이해하지만, 방향을 제시하기는 어렵다.
시니어 개발자
글에서는 여기까지 굳이 구분할 필요 없지만, 하는 김에 시니어까지만 해보자. (시니어, 스태프, 시니어 스태프, 프린시펄 이런 식으로 더 윗 단계들이 있지만, 여기서는 시니어랑 스태프를 묶어서 대충 시니어라고 부른다)
시니어 개발자는 6개월 이상의 지속성을 가지는 업무를 주로 처리한다.
보통 전체 서비스의 특정 부분에 대해서는 회사 내에서 전문가이며,
해당 부분의 베스트 프랙티스가 무엇인지 명확히 알고 있다. (구현을 베스트 프랙티스로 하지 않았어도, 어떤 부분이 문제를 일으킬 수 있는지 알고 해결방법도 알고는 있다. 시간이 없어서 안했을뿐..)
현재 팀이 진행하는 프로젝트가 향후 어떻게 발전될지 이해하고, 다른 프로젝트들과의 관계를 통해 앞으로 진행될 방향을 제시할 수 있다.
주니어 시절을 잘 지내기 위한 3가지 방법
좋다는 기준은 모두 다르기 때문에 강요할수는 없지만, 좋은 주니어는 꾸준히 성장하려고 노력하는 사람이라고 생각한다.
일반적으로 꾸준히 성장하는 것은 자기동기부여가 되어야 하고, 이것은 좋아하는 일 / 분야에 몸담고 있을 때만 가능한 것 같다.
따라서 좋은 주니어 시기를 보내려면,
- 본인이 좋아하는 것을 알고
- 좋아하는 것을 깊이 알려고 노력하고
- 그것들을 본인의 업무와 연결하려고 시도해야
위의 세가지를 찾아가는 과정에 중점을 두면 좋을 것 같다.
방향을 정하자
IT 직종은 상당히 세분화 된 분야가 많기 때문에, 본인이 어떠한 분야로 나아갈 것인지를 정하는 것이 중요하다.
본인이 방향을 미리 정해두지 않고 시키는 일만 계속하다보면 깊이가 없이 다양한 일을 하게 된다. (대부분의 경우 못하는거 아니면 다 시켜야지 라는 회사의 마인드 + 어차피 모르니깐 무엇이든 다 도움이 될거야 라는 개인의 마인드)
좋은 시니어가 없는 회사의 경우, 주니어는 스스로 성장해야하는데, 동일한 기간이 주어졌을때 스스로 공부해서 성장한 것과 특정 분야에 대해서 시니어를 통해 성장하는 것은 엄청난 차이가 있다. (바이올린을 책을 내가 사서 독학 하는 것과 선생님을 통해 레슨을 받고 공부하는 것이 차이라고 생각해도 된다.)
따라서 시니어가 없는 환경일수록 본인이 어떤 방향성을 가지고 성장할지 미리 고민해두는 것이 중요하다.
여기서 말하는 방향은 업무 포지션이라고 생각하면 되고, 방향성을 정하는 제일 쉬운 방법은 여기[^1] TL;DR 에 적어두었다.
물론 잘 모를때 정한 방향성은 성장해나가면서 바뀔 수 있지만, 방향을 찾는 연습을 미리 해두면 나중에 바꿀때도 큰 도움이 되고, 이렇게 정한 방향성은 스스로 공부하거나 발전해나가는데 도움이 된다.
깊이의 범위를 정하자
대부분의 주니어는 다양한 업무를 할당 받아서 다양한 기술들을 쓰게 될텐데, 모든 분야에 대해 전문가가 될 수는 없다.
따라서 각 기술이나 분야에 대해 어느정도 깊이까지 공부를 할지를 앞서 정한 방향성에 맞춰 정해두는 것이 좋다.
데이터 엔지니어가 되고 싶다면, 머신러닝 모델들의 이론적인 부분보다 파인튜닝 / 인퍼런스 하는 방법을 위주로 공부를 하는 것이 좋을 것이다.
깊이를 정하는 간단한 가이드으로는, 주어진 업무를 단순히 처리할 수 있는 수준보다 조금 더 깊게 공부한다는 느낌이면 좋은 것 같다.
예를 들면, NodeJS 에서 async/await 을 이용한 개발을 하는 경우 promise 의 사용법만 아는게 아니라 어떤 과정을 통해 이벤트 루프가 promise 를 처리해서 값을 리턴하게 되는지 정도까지 알아보는 식이다.
(할거면) 업무와 관련된 사이드 프로젝트를 하자
여기서 말하는 사이드 프로젝트는 단순히 라이브러리 등을 사용해보는 PoC 수준의 토이 프로젝트를 말하는게 아니라, 일주일에 몇시간 이상 꾸준히 시간을 소모해서 진행하는 장기적인 프로젝트를 의미한다. (예를 들면, golang 을 이용해서 나만의 웹 프레임워크를 만든다거나 하는 것들이다.
개인적으로 주니어가 사이드 프로젝트를 하는 것을 별로 추천하지 않는다. (그 시간에 사내의 시니어가 작성한 코드나 오픈소스 코드를 많이 읽는 것을 추천한다.)
그래도 무언가 꼭 하고 싶다면 매일의 업무에서 사용하는 기술에 대한 프로젝트를 해야 한다고 생각한다.
이직시 면접에서 가장 중요한 부분은, 이력서에 기재된 내용들에 대해 얼마나 깊이있는 대답을 하는지이다.
현재 다루고 있는 예전 기술들에 대해서도 잘 모르면서 최신기술에 대해서 공부하는 주니어들을 종종 보는데, 매일 사용하지 않는 기술은 공부해도 금방 잊어버리게 되고, 커리어 측면에서는 공부하지 않은 것과 거의 같은 효과라고 볼 수 있다.
예를 들어, 현재 몸담고 있는 회사에서 스프링 부트로 마이크로서비스 아키텍쳐 기반의 서비스를 만들고 있다면, golang 이나 rust 가 요즘 핫하니깐 이 새로운 언어들을 가지고 사이드 프로젝트를 진행하는 것 보다, 기본적으로 사내에서 쓰고 있는 라이브러리들을(Hystrix 라던가) 사용해서 간단한 것들을 만들면서 주요 라이브러리의 특성이나 사용법을 깊이 이해하는 것이 좋다. (라이브러리 코드를 분석해서 사내에서 공유를 한다거나)
그 이후에는 스프링부트 위에서 grpc 로 동기방식 msa 를 구성한다거나, 회사에서 사용하는 postgresql 에 새로 제공되는 CDC 기능을 이용해서 CQRS 를 구현해본다거나, 아니면 회사에서 사용하는 kafka 에 제공되는 events stream 을 써서 이벤트 소싱을 구현해본다거나 하는 식으로, 현재 내가 매일 사용하는 기술중 새로운 내용이나 현재 사용하는 기술의 대안으로 나온 새로운 기술을 한가지씩 추가해서 써보는 것도 좋다.
번아웃에 미리 대비하자
전체 커리어를 봤을때, 대부분의 경우 몇번의 번아웃을 거치게 된다.
번아웃이 오기전에 워크-라이프 하모니를 잘 관리하는 것이 가장 중요하지만, 주니어나 일반 개발자는 알고보니 번아웃 인 경우가 많아서 번아웃을 벗어나는 방법을 미리 찾아 두는게 더 중요한 것 같다.
개인적으로는 게임이나 운동 같은 취미를 가지는 것이 도움이 되었다. 번아웃이 올 것 같다면 중요하지 않은 업무를 대부분 차단하고 (매니저와 이러한 방향에 대해 상담하는 것도 도움이 된다. 인사고과는 잠시 내려놓자..) 업무시간 외에는 취미활동을 하거나 차라리 잠을 자자.
번아웃이 이미 왔다고 느끼는 경우도 마찬가지로 매니저와 이야기한 뒤 고과를 잠시 버리고 개인적인 휴식시간을 최대한 챙기자.
대표적인 증상인 무기력증이 느껴질땐 투두리스트를 만들어서 관리하는 식으로 도파민을 스스로 만들어내는 것도 좋은 방법이다.
번아웃은 개개인 별로 유효한 coping 스킬이 다르므로, 일 외에 자신이 좋아하는 무언가를 미리 찾아두는 것이 좋은 것 같다. (가능하면 컴퓨터와 관계없는 분야로..)
마치며
세상은 불공평하기 때문에 노력으로 넘을 수 없는 선이 있다.
내가 헬스를 몇년간 꾸준히 해서 몸을 만들면, 이상적인 경우에 이승윤씨 정도의 몸을 가질 수 있는 것이지, 줄리엔 강의 몸을 가질 수는 없다.
외부(특히 주변사람)를 기준으로 삼으면, 내가 알게된 새로운 것들에 대해 성취감이나 행복을 얻기가 어려워지는 것 같다.
따라서 어제의 나보다 오늘의 내가 더 나아졌는지에 집중하면서, 하루하루 지내다보면 어느새 행복한 시니어 개발자가 되어 있을 것이다.