나는 과거에 스스로를 성장하는 개발자, 꾸준한 개발자라는 타이틀을 사용해서 포장하고는 했다. 실제로 소프트웨어를 전공하면서 성실히 프로젝트를 진행했고 CS 지식을 쌓았다. 하지만 방향성 없는 꾸준함은 지속 가능하지도 않고 효과적이지도 않다는 사실을 깨닳기 까지는 얼마 걸리지 않았다.
항상 성장하고 싶다, 성장할 수 있는 조직에 들어가고 싶다고 말은 하면서 정작 성장하는 개발자란 무엇일지 고민조차 해보지 않았었다.
“성장하는 개발자”란 결국 “좋은 개발자”가 되겠다는 말과 같다. 그렇다면 “좋은 개발자”가 무엇인지 알아야 좋은 개발자로 성장할 수 있지 않을까? 성장을 언급하기 전에 좋은 개발자에 대한 정의를 블로그, 컨퍼런스, 유튜브 등을 통해 찾아보고, 스스로 고민해 보았다.
훌륭한 개발자에 대한 정의는 사람마다 다르고 이에 대한 정답은 없다고 생각한다. 그렇더라도 대다수의 개발자가 생각하는 연차별 좋은 개발자란 무엇이고 주니어로서 무엇을 준비하면 좋을지 여러 시니어 개발자들의 글을 참고하여 정리해보았다.
-
좋은 개발자
연차에 요구되는 역량을 발휘할 수 있고 조직내 비즈니스 가치를 창출할 수 있으며 조직 문화를 개선할 수 있는 개발자
개발자의 연차에 따라서 좋은 개발자의 기준은 달라질것이다. 5년차 개발자의 역량을 가진 10년차 개발자에게 능력있는 개발자라고 하지는 않을 것처럼 말이다.
1 ~ 3년차
코딩 역량을 보여주고 실무 프로세스에 익숙해지는 데 초점을 맞춘다.
- 코드베이스를 이해하고 필요한 테스트를 추가하는 등 기존의 코드를 유지보수 시키고 발전시키기 위한 요청사항을 처리할 수 있다.
- CS 지식을 기반으로 기본적인 업무 대화를 이해하고 파악할 수 있다.
- 컨벤션을 지키며 코드를 다른사람이 이해하기 편하게 작성할 수 있다.
- 공식 레퍼런스를 보고 사용법을 스스로 익힐 수 있다.
- 경험한 사용법을 문서화해서 팀 내에 전파할 수 있다.
나는 무엇을 하고 있는가?
- 스터디를 주최하여 다양한 의견에 대해 토론하기
- 하나의 CS 주제를 선정하고 사람들 앞에서 발표
- 발표후 질문을 받으며 부족한 부분을 고찰
- OOP 학습을 위한 “오브젝트” 서적을 읽고 장별로 느낀점을 공유
- 하나의 CS 주제를 선정하고 사람들 앞에서 발표
- 습관을 통한 지속적 학습
- 1일 1커밋
- 1일 1커밋에 대한 부정적인 시각도 존재하지만 내가 1년동안 1일 1커밋을 하고 느낀바는 긍정적이었다. (이에 대한 포스트를 추후에 작성해봐야겠다)
- 1일 1커밋을 통해 학습에 대한 강제성 부여
- 의미없는 커밋을 하게 되었을때의 죄책감을 통한 원동력 부여
- 1일 1커밋
5년차
개발 생산성과 난제 해결 측면에서 경쟁력을 쌓는데 초점을 맞춘다.
- 현재의 문제만을 해결하기 위한 기술 선택이 아닌 앞으로의 서비스를 더 잘 만들기 위해 현재의 문제를 해결할 수 있는 기술을 선택 할 수 있는 역량
- 기술 뿐만 아니라 유지보수에 대한 비용까지 고려하여 개발하는 역량
- 중형에서 대형 기능을 독립적으로 완성할 수 있는 역량.
- 어려운 난제를 해결할 수 있고 문제의 본질적인 원인을 파악하여 개선할 수 있는 역량
- 자신보다 높거나 적은 연차의 사람들을 설득 시킬수 있는 소통 역량
나는 무엇을 하고 있는가?
- 스프링의 내부 구조를 직접 구현
- 프레임워크의 내부 동작 원리를 이해하여 문제 발생시 근본적인 원인을 파악하기 위한 지식을 학습.
- 프로젝트에 기술을 도입하는 이유를 스스로 질문 하고 문서화 하여 공유
- 다른 선택지와 비교하여 프로젝트에 적합한 기술을 선택하고 그 이유를 공유
- 5년차에도 꾸준히 학습할 수 있는 원동력 찾기
- 사람의 의지력은 나약하다.
- 강제성을 부여하기 위해서 열정적인 동료들과 스터디를 진행하기
- 순수하게 개발에 대한 이야기를 나누고 자극을 받을수 있는 친구 만들기
10년차
개발 생산성 기술 리딩, 난제 해결에 대한 피드백과 문화를 만들고 구성원의 영량을 향상 시키는데 초점을 맞춘다.
- 대규모 프로젝트를 높은 수준의 생산성으로 설계, 세분화 할 수 있다.
- 별도의 가이드 없이 스스로 기존 시스템/제품의 문제를 능동적으로 발견하고 솔루션을 제공.
- 소규모 그룹의 개발 문화를 리딩할 수 있다.
- 구성원의 역량을 향상 시킬 수 있다.
나는 무엇을 하고 있는가?
- 학과 후배들을 대상으로 멘토링을 진행
- 문제 발생시 답 보다는 방향을 제시하기 위해 노력
- 생각과 선택을 강요하지 않도록 노력
- 다양한 가치관을 형성하고 커리어를 고려해 볼 수 있도록 내 생각을 강요하지 않게 주의
마치며
지금까지 좋은 개발자에 대한 다양한 생각을 정리해보았다. 연차가 올라갈 수록 설계 능력 뿐만 아니라 소프트스킬과 조직 문화를 리딩하는것이 중요하다는 것을 알 수 있었다. 개인적으로 문제 해결 능력이나 클린 코드 역량은 개인 스스로의 노력 만으로도 성장이 가능하지만 소프트스킬과 설계 역량의 경우 다양한 조직 구성원간의 상호작용을 통한 학습이 중요하지 않을까 생각해보았다.
각 연차별 필요한 역량을 어떻게 하면 빨리 습득할 수 있을까 고민해 보았는데, 좋은 개발 문화를 가진 조직에 입사하는것도 좋은 방법이 될 수 있지 않을까 싶다.
연차, 직급에 상관없이 자신의 의견을 말할 수 있고, 그에 대한 건전한 피드백을 받을 수 있는 문화라면 자신의 소프트스킬 역량을 향상 시는데 도움이 될 것이다.
또한 “설계는 트레이드오프의 산물”이라는 말이 있듯이 다양한 프로젝트 경험을 통해서 적합한 선택을 하는것이 중요한데, 만약 코드리뷰 문화를 도입한 조직이라면 리뷰를 통해서 내가 미처 고려하지 못한 부분을 피드백 받으며 더 훌륭한 설계를 할 수 있는 역량을 길러낼 수 있을것이라고 생각한다.
3년, 7년 후 미래에 다시 이 글을 보게 되었을때 스스로 많이 성장했다고 느끼기를 바라면서 이러한 역량을 가진 개발자로 성장해 있는 것을 목표로 열심히 나아가도록 하겠다.
ps.
위에서 정리한 연차별 개발자로서의 역량과 다른 의견을 공유해주실수 있다면 감사하겠습니다.
다양한 개발자 분들의 의견을 통해서 저의 짧은 시각으로는 보지못한 영역을 고민해 볼 수 있는 계기를 주시면 감사하겠습니다.
참고 자료 📚
우리가 부르는 시니어 개발자는 누구인가? | 우아한형제들 기술블로그
The Differences Between a Junior, Mid-Level, and Senior Developer
요기요 R&D Center에 무엇이든 물어보세요! (1)