지극히 개인적인 개발자로서 성장하기 위한 방법에 대한 단계별 방법

들어가면서

최근들어 개발자로서의 성장 에 대해 지금의 나는 어디까지 성장한거지?? 앞으로는 어떤식으로 성장할 수 있을까? 에 대한 고민을 하던중 나는 개발에 대한 커리어를 성장시키기 위해 어떠한 고민을 해왔고 앞으로는 어떻게 성장하지 라는 고민을 정리하였고 이를 적어보면 좋을것 같아서 작성해본다. 물론 이것이 무조건 정답이다 이런건 절대 아니다. 나의 경험을 기반으로 지극히 주관적으로 적는것이라 절대적인 지표로 삼지 말고 참고정도만 하면 좋을것 같다.

초기 커리어에 대한 고민 - 방향성

최초로 개발자로서의 취직을 하게 되면 앞으로의 성장포인트는 방향성 이 가장 큰 카테고리라고 생각된다.

물론 본인이 원하는 포지션인Frontend 로 선택 후 입사하여 회사에서도 Frontend 포지션으로 업무를 게속 배정해주고 Frontend 에서의 업무가 핏에 맞는다면 최고로 좋은 케이스이긴 하지만 이렇게 되지 않는 경우가 있고 이때 이러한 포지션에 대한방향성 에 대한 고민이 가장 크다고 생각한다.

이러한 방향성의 대한 고민은 여러가지가 있을수 있는데 개인적으로 생각할때 아래와 같은 케이스들이 가장 많은 포인트 라고 생각된다.

1. 원하는 포지션(Frontend)으로 입사하여 원하는 포지션에 대한 (Frontend) 개발을 하고 싶으나 회사 사정으로 다른 포지션(Back-End) 업무를 진행해야 하는 경우

사실 대책없는 답이라고 생각할 수 있으나 이러한 경우 빠르게 이직준비를 하는게 가장 정답이라고 생각한다. 본인이 원하는 포지션 이 있는데 이를 강제로 다른 포지션 으로 바뀌는건 개발 커리어 성장 에 대한 고민 이전에 개발자 라는 직업에 대한 회의감으로 이어지고 다른 업무를 찾아볼까 생각까지 들게 된다고 생각하기 때문이다. 최근 일부 소규모 회사에서 프론트앤드 개발자 로 면접을 진행후 취업하고 나서 어느순간부터 백엔드 업무 의 일감을 주고 여러가지를 해보는건 본인의 개발경험에도 큰 도움이 된다고 하며 업무를 시키는 경우를 봤다.

물론 본인도 BE -> FE 로 전환 해본 입장에서 두개 전부 해보는건 본인에게 있어 큰 성장의 포인트가 될 수 있다. 다만 이건 자신이 원해서 하는경우이다. 개인적으로 이러한 케이스는 취업사기 라고 소신발언 해본다. 이러한 경우 게속 다니게 되면 나중가서 경력이 올라갈수록 점점 더 이직자체도 어렵기 때문에 빠르게 다른 회사로의 이직을 해보는게 가장 좋다고 생각 된다.

2. 원하는 포지션(Frontend)으로 입사하여 해당 포지션에 대한 업무를 진행하지만 막상 실무를 해보니 자신에게 맞지않아 다른 포지션(Back-End)을 고민하는 경우

내 경우 개발 초반 3년을 PHP를 하며 백엔드개발자로 근무하였으나 당시 react 를 배우며 정말 프론트앤드로 전환을 하고 싶었다. 하지만 아래와 같은 고민이 항상 내 발목을 잡게 되었다.

• 백엔드 개발 3년 경력은 사라지는건 아닐까?
• 다른 이직 경쟁 대상인 프론트 개발자들보다 실무능력이 떨어져 이들과 경쟁할 수 있을까?
• 연봉협상시 백엔드 경력 3년에 대한 경력이 사라지는것은 아닐까?

지금 내가 생각한 이러한 케이스에서는 먼저 해보고 싶은 직군에 대해 깊게 공부하고 이를 토대로 단순한 todoList 같은 간단한 사이드 프로젝트가 아닌 꽤나 볼륨있는 서비스를 만들어보며 정말 다른 직군이 나에게 맞는지 사전에 시도해보는게 좋다고 생각한다. 또한 이러한 직군의 변화를 위해서는 그 다른 사람보다 1.5배 이상의 노력을 하는게 좋다고 생각한다. 실전 업무가 아닌 이론 공부와 사이드 프로젝트만으로 그 직군을 도전해야 하기때문에 정말 큰 노력이 필요하다.

3. 개발자에 대한 회의

직군에 관계없이 내가 개발자 로서 맞는가? 라는 생각을 하는 경우는 어떠한 이유때문에 이러한 회의감이 들었는지 생각을 해보면 좋을것 같다. 여러가지 이유가 있지만 아래의 이유가 해당된다면 사실 빠르게 다른 직업을 찾아보는 것도 좋은 방법이라고 생각된다.

• 개발공부를 게속 하는게 지친다.
• FrontEnd, Back-End 어느 포지션 상관없이 개발 자체가 재미가 없다.

개발자 라는 직업은 개인적으로 게속해서 공부해야하는 직업이라고 생각한다. 개발자가 게속해서 성장하듯 개발언어, 방법론 등도 끊임 없이 변화하고 있기 때문에 이를 게속 학습하여야 더 성장하는 개발자가 될 수 있다. 이러한 배움에 있어 업무 외 시간에도 공부를 하는게 정말 싫다고 느껴지거나 학습하고 나서도 뿌듯함 같은게 느껴지지 않는다면 직업을 찾아보는 것도 좋은 방법이라고 생각된다.

나쁘게 말한다고 생각될수도 있으나 개발자라는 직업을 가진 이상 이러한 학습을 게속해야 살아남을수 있기 때문에 이러한 학습이 싫다면 개발자로 있는 동안 게속해서 스트레스만 받을것 이기 때문에 본인에 적성에 맞는 다른 직업을 빠르게 찾는것도 좋은 방법이다.

개발성장 (2년차 이후 ~5년차) 에 대한 고민

위에서 이야기한 방향성 에 대한 고민이 끝났다면 이제는 개발적인 성장에 대한 고민이 가장 크다고 생각된다. 물론 성장에 있어서는 정답이 없고 수많은 방법이 존재한다. 아래 케이스는 본인이 실제로 시도해서 꽤나 도움을 많이 받은 방법들에 대해 설명을 하고자 한다. 아래의 방법이 절대적인 좋은 방법이라고는 생각하지 않는다. 다만 본인과 핏이 맞다고 생각되면 충분히 시도해도 좋다고 생각한다.

1. 업무 프로젝트를 끝까지 뜯고 맛보고 즐기자.

개발 초기에는 주어진 업무를 개발하는것만 해도 벅차서 작업하고 있는 프로젝트에 대해 더이상 깊게 생각해보지 않는것이 대부분이다. 단순히 로컬에서 담당하는 업무를 위해 실행하고 기능만 만들고 argocd , jenkins 등 구성된 배포툴을 통해 배포하는 정도일 것이다. 이제는 여기에서 한발자국 더 나아가보도록 하자 로컬에서 실행할때 간단하게 실행 스크립트만 실행시키는 부분에 있어서도 어떤식으로 실행이 되는지 환경설정은 어떻게 구성되어있는지, 평소에 불러와서 쓰고만 있던 공용함수 같은것들도 실제로 어떻게 동작하는지, 이렇게 프로덕트를 한개한개씩 살펴보는것이 한층 더 높은 시야로 개발적인 부분을 볼수 있도록 도움을 준다.

이렇게 코드레벨에서 전부 뜯어보았다면 다음으로는 단순하게 배포만 하고 있던 부분을 살펴보자. 어떻게 구성되어있고 배포가 어떻게 이루어 지는지 살펴보고 이를 이해하게 된다면 이는 혼자서 프로젝트를 새로만들어서 배포까지 구성하여 서비스를 낼수있는 퍼포먼스 (물론 실제로 만들기는 힘들 수 있지만..)를 가지게 된다. 물론 처음에는 무슨소리인지도 모르겠고 이해가 안가는 부분들이 있을것이다. 당연히 모르고 이해안가는게 많을수 밖에 없지만 이를 한개한개 검색해나가며 한개한개씩 이해해나가기 시작한다면 이는 곧 본인의 가장 큰 성장동력원이 될것이다.

2. 컨퍼런스 혹은 스터디 는 경우에 따라 큰 도움이 될 수 있다.

개발 컨퍼런스의 경우 성장에 있어 정말 큰 도움이 된다고 생각한다. 때문에 큰 컨퍼런스의 경우 꼭 참가해보도록 하자 비록 개발경력이 얼마 안되어 발표내용을 깊게는 이해하지 못하더라도 좋다. 이러한 컨퍼런스를 참가하면 개발을 잘해보겠다는 의지가 크게 상승하고, 내가 몰랐던 기술의 사용법, 기술 등 여러측면에서 배울점이 많기때문이다.

스터디의 경우 사람마다 다를수 있지만 필자가 생각할때의 스터디는 의지는 있지만 항상 해야지 하고 다음으로 미루는 경우 강제성을 주기 위해 선택하면 좋다고 생각 한다. 다만 스터디를 통해 다른 스터디 구성원들로 부터 여러 도움을 받을 수 있다는 생각이 아닌 본인의 성장을 위한 강제성의 측면으로 가야한다. 물론 스터디를 통해 서로 도움을 주는게 목적이고 이렇게 된다면 정말 좋지만 개인적인 경험으로는 대부분의 스터디의 경우 업무와 같은 의무가 아니기 때문에 막상 하게되면 대충대충 하는 구성원이 많기 때문에 이를 기대했다가는 실망하게 되어 스터디를 안가게 되고 이는 강제성도 사라지기에 성장동력을 잃을 수도 있기 때문이다.

3. 사이드 프로젝트는 정말 좋은 동력원이다.

내가 해보고 싶었지만 실무에는 쓰지못한 최신 library 등 여러 기술을 시도해볼수 있는 가장 좋은 창구이다. 사이드 프로젝트의 주제나 기획, 다자인 때문에 해보기 싶다면 간단한 블로그나 다른 서비스를 클론프로젝트로 진행해보아도 좋다. 아무리 이론으로 공부해보고 TodoList 까지만 해본다고 해도 실제 간단한 프로젝트를 만들며 더욱 심화적인 고민을 할 수 있기 때문에 반드시 구성해 보는 것을 추천한다. 위에서 추천한 업무 프로젝트의 구조 포인트를 적용해보며 시도해보는것도 좋은 방법이다. 해당 프로덕트에 대한 이해도도 훨씬 성장할 수 있고 더 좋은 고민을 해볼 수 있기 때문이다. 물론 사이드 프로젝트 주제같은 고민이 너무 힘들다면 가장 크게 추천해줄수있는건 자기자신의 블로그를 만들어보는걸 개인적으로 추천한다. 물론 다른 훌륭한 블로그 서비스들이 있어서 거기에서 작성해도 상관없지만 본인의 블로그를 운영한다는 자기만족감과 사이드 프로젝트로 게속 업데이트도 하며 1석2조의 성장 포인트가 될것이라고 생각하기 때문이다.

4. 코드를 작성하는 방법에 대한 고민과 성장

물론 성장초기에는 본인이 주로 하는 언어에 대한 노하우, 스킬셋 등의 기술적인 성장이 가장 폭팔적으로 증가할때이고 이러한 관심도가 높을 시기 이다. 이부분에 대해 상대적으로 소홀하라는 것은 절때 아니다. 다만 이러한 스킬 숙련도 좋지만 개발에 있어 코드를 작성하는 방법에 대한 성장도 중요하다고 생각한다. 개발은 혼자하는 작업이 아닌 여러 동료들이 한 코드저장소에서 같이 코드를 보고 작성하고 프로젝트를 만들기 때문에 내가 작성하는 코드에 대한 신뢰성, 코드가 쉽게 읽혀야 하는 가독성 등 코드를 작성하는 방법이 상당히 중요 하다고 생각한다. 또한 이러한 개념은 개발 언어를 구분하지 않기 때문에 개발에 있어 필수 요소 중 한개라 생각든다. 관련해서는 정말 좋은 책들이 많은데 개인적으로 추천하는 도서들은 다음과 같다.

• 좋은코드 나쁜코드
• 좋은 코드를 작성하는 기술
• 리팩토링
• 소프트웨어 장인
• 클린코드

다방면 적인 성장에 대한 고민

개발에 대한 연차가 어느정도 올라가게 되면 코드 작성 방법론, 테스트, 개발 스킬셋 뿐만 아니라 업무에 필요한 커뮤니케이션, 리딩능력 등 다른 부분에 있어 성장에 대한 필요성을 느끼게 된다.

1. 커뮤니케이션 을 잘 해보자.!

개발 초중반까지만 해도 주도적으로 커뮤니케이션 을 크게 하지 않아도 사수, 팀장 이 업무를 분배하고 작업 사항을 큰 틀로 정리하여 주기때문에 실제 업무에 대한 궁금한 부분말고 크게 커뮤니케이션을 하지 않아도 되므로 크게 느끼지 못하지만 점차 개발연차가 늘어갈수록 업무에 대한 커뮤니케이션 비용이 증가하게 된다. 개인적으로 가장 어려운 부분은 작업 범위 산정 및 일정에 대한 이슈로 미스 커뮤니케이션 할 때가 많은데 보통 아래와 같이 처리하면서 이러한 미스커뮤니케이션을 줄일수 있었다.

작업에 대한 철저한 기록

보통 가장 많이 미스커뮤니케이션 나오는 부분이 회의, 슬랙, 구두 로 논의하고 작업하게 되는 경우이다. 이 경우 작업이후 다시 싱크를 맞추어 보다보면 머리에만 의존하여 논의를 하게되다 보니 반드시 서로간의 싱크가 안맞는 경우가 생기게 된다. 때문에 작업해야하는 범위 및 작업 일정에 대한 부분은 회의, 구두 등으로 커뮤니케이션이 되었으면 이를 Jira 혹은 업무툴을 사용해 작성해두면 작업 범위 및 실제 일정에 대해 기록이 되어있어 상당한 커뮤니케이션 미스를 줄일 수 있다.

작업이 병렬적으로 게속 오는 경우 반드시 이를 어필하자

A라는 3일이 소요되는 작업을 하고 있는중 작업한지 2일째에 갑자기 급하다며 처리해달라는 작업이 들어오는 경우가 종종 존재한다. 간단한 작업이라면 상관없지만 어느정도 작업 소요가 된다고 판단되면 현재 하고있는 작업에 대한 일정을 말씀드리면서 조정이 필요하다고 먼저 요청하는것이 가장 중요하다. 물론 작업을 맞기는 기획, 팀장 포지션의 분들이 조율해줄수 있지만 현재의 상황을 가장 잘 아는것은 자기 자신이기때문에 이를 고려못할수 있기 때문에 이런 상황이 오게 되면 먼저 충분히 어필하는것이 중요하다고 생각한다.

2. 팀리딩 어렵고도 어렵다.

개발 경력이 어느정도 쌓이게 되면 자연스럽게 본인의 개발파트 부분(FE,BE...) 혹은 개발팀에서 리딩을 하게 되는 시점이 온다. 이전까지는 라이브러리, 언어 등 개발 커리어 적인 성장만 열심히 하고 자연스럽게 그러한 성장이 회사에서 나를 평가하는 큰 지표중 한개이지만 리딩을 하게된 시점부터는 조금씩 달라지기 시작한다. 단순한 개발 퍼포먼스 뿐만 아니라 본인이 맡은 개발 조직에 대한 관리도 필요하기 때문이다.

관리의 측면에는 조직원들의 업무 관리도 있겠지만 개발팀의 성장을 위한 업무와 기술과제, 이슈 트래킹, 업무 커뮤니케이션 스킬 등 여러 요소에 대해 고민하기 시작해야 한다.

개발 조직 문화

개발팀이라면 업무적인 문화 말고도 각자 회사에서 업무를 하면서도 성장을 할 수 있게 이에 대한 발판을 만들어 주어야 한다. (ex. 코드리뷰 고도화, 기술과제, 사내 스터디 등등) 다만 여러 성장할수 있는 방법이 있지만 자신의 방식만을 고집하게 되면 팀 구성원들이 그 방식을 대부분 싫어할 경우 조직문화는 오히려 악영향만 미치게 된다.\n때문에 개인적으로는 1달 혹은 분기 단위로라도 팀원들과의 1:1 등을 진행하여 어떠한 성장이 필요한지 어떠한 것을 해보고 싶은지 현재의 팀내에서 어떠한것이 별로이고 좋은지 등을 이야기 해보자. 처음에는 어색할수 있어도 주기적으로 진행하게 되면 상당히 긍정적인 효과를 볼 수 있다. 다만 중요한건 1:1 이후 받은 피드백에 대해 어떠한 액션이든 진행해서 개선되고 있다는 것을 보여주는게 가장 핵심이라고 생각한다.

리딩과 개발 포지션 밸런스를 잡아야 한다.!\n사실 가장 힘든 포인트라고 생각한다. 리딩을 하는 입장에서 업무 조율 팀원 관리등 매니징의 업무를 하고 있지만 보통 개부분은 개발업무 도 같이 진행해야하기 때문이다.

본인의 개발적인 성장도 있지만 회사에서 내가 리딩 포지션인지 나에게 원하는 스킬이 팀에 대한 매니징이 주가 되는것인지 리드인 만큼 개발 퍼포먼스 를 가장 잘 뽑아야 하는지 정말 알수 없기 때문이다.

물론 2가지를 전부 다 잘하면 베스트 이지만 2개를 전부 다 잘하는게 정말 어려운일이다. 때문에 한곳에 좀더 포커스를 맞추어야 하는데 가장 빠른 정답은 자신의 더 윗 리더에게 어떤부분을 원하는지 물어보는것이다. 회사 혹은 사람마다 원하는 부분이 다르기 때문에 이는 본인의 더 윗 레벨의 직군분이나 인사팀에게 별도 미팅을 요청하여 본인에게 원하는 요건이 어떤부분이 더 큰지 물어보는게 부담스럽긴 하지만 당연히 물어볼 수 있는 문제이고 가장 명쾌하게 답을 내릴 수 있는 방법이라고 생각한다.