"주니어가 시니어로 넘어가는 가장 첫 번째 요소는 _____입니다." | 마이크로소프트 출신 개발자

📌 Editor's comment

성장의 의지가 있는 주니어 개발자라면, 기술 선택부터 학습 방법까지 고민이 많을 것입니다. 🤔

이번 인터뷰에서는 멘토님이 직접 경험한 시행착오와 함께, 주니어 개발자들에게 꼭 필요한 인사이트를 전해드립니다.

 

멘토님의 솔직한 이야기와 조언을 지금 만나보세요!

성장의 의지가 있는 주니어 개발자분들을 위해 마이크로소프트 출신 개발자인 백엔드 멘토님을 모시고 이야기를 나눴습니다.

🚀 멘토님께 질문했습니다!

• 기술 스택 선택 시, 현재 트렌드와 개인의 흥미 사이에서 어떻게 균형을 잡아야 할까요?
• “엉덩이가 무거운 사람이 이긴다“” 라는 말이 있습니다. 개발공부도 마찬가지일까요? 하루 절대적인 공부량의 기준 궁금합니다.
• 어떠한 개념을 공부할 때, 또는 어떠한 테스크를 구현할 때, 어느 정도의 깊이까지 가야할지 잘 모르겠습니다.
• 같은 시간에서도 남다른 성취를 보이는 이들은 무엇이 다른 걸까요?
• 신입 개발자가 흔히 저지르는 실수가 있다면 무엇일까요?

Q. 기술 스택 선택 시, 현재 트렌드와 개인의 흥미 사이에서 어떻게 균형을 잡아야 할까요?

훌륭한 질문입니다. 저 개인적으로는 개인의 흥미가 최우선이라고 생각합니다. 많은 주니어 분들의 이력서를 검토해주면서 가장 느끼는 것은 여러가지를 많이 할 줄 안다에 방점을 찍고 싶어 하는 것 같다는 것입니다. 

하지만 주니어가 시니어로 넘어가는 가장 첫번째 요소는 한 분야에 대해 누구보다 깊게 아는 것입니다. 엔지니어에게 주어진 가장 큰 과제는 문제해결입니다. 내가 단순히 특정한 기술을 아는데 그치지 않고, 이 기술이 어떤 기반에서 동작하고 있고 어떤 로직으로 동작하는지 이해가 있어야 어려운 문제를 풀 수 있습니다. 이런 나의 문제해결능력이 팀 내에 누구보다 자신이 있다면 자신은 이미 어엿한 시니어라고 봐도 무방합니다. 

트렌드를 쫓아가는 것도 물론 중요하지만, 트렌드를 쫓아간다 하더라도 이게 어떠한 맥락으로 이 트렌드가 생겼는지 아는 것이 중요합니다. 현재의 트렌드를 파는데에 흥미가 돋지 않는다면 저는 개인의 흥미를 더 깊게파는 쪽으로 추천드립니다.
 

Q. “엉덩이가 무거운 사람이 이긴다” 라는 말이 있습니다. 개발공부도 마찬가지일까요? 하루 절대적인 공부량의 기준 궁금합니다.

이것은 개인차가 있는 분야라고 생각되네요. 절대적인 공부량이 중요하다고 생각하지 않습니다. 내가 언제 어떠한 목표를 이룰 수 있는가, 그리고 얼만큼 꾸준히 할 수 있는가가 더 중요하다고 생각됩니다. 공부는 결코 단기간의 싸움이 아니고 장기적인 걸음입니다. 내가 지쳐서 공부를 그만두게 된다면 그것이 더욱 손해입니다. 

회사에서 일해보셨다면 애자일 방법론에 대해 들어보셨을 겁니다. 애자일 방법론을 택하는 이유는 나 스스로를 투명하게 만들어 현실적인 목표를 이루기 위함입니다. 초반 마일스톤에는 팀이 예측한 결과량과 실제 나온 결과량을 비교하여 그 갭을 측정합니다. 초과 달성을 했다면 팀 예측보다 더 나아갈 수 있다는 것이고, 달성하지 못했다면 예측이 너무 낙관적이란 뜻입니다. 

이런 방법론은 개인의 공부량을 결정하는데 꽤 도움이 됩니다. 한 달 단위로 내가 이 기간동안 끝내고 싶은 것들을 적어보세요. 그리고 그것들을 쪼개서 매일매일 얼마나 달성했는지 기록합니다. 한 달이 끝나면 예측과 결과물의 갭을 측정하고, 다음달도 계획을 세우고 갭을 측정합니다. 

여기서 가장 중요한것은 내가 지치지 않고 지속가능할 수 있는 공부량을 측정하는 겁니다. 이렇게 가시적으로 성과가 보이게되면 실제로 내가 얼마나 성장하고있는지 눈으로 쉽게 파악할 수 있고, 이게 다시 동기부여가 되는 선순환이 됩니다.
 

Q. 어떠한 개념을 공부할 때, 또는 어떠한 테스크를 구현할 때, 어느 정도의 깊이까지 가야할지 잘 모르겠습니다.

좋은 질문입니다. 실제로 많이 들었던 질문이기도 합니다. 다른 질문에서도 대답한 것이긴 한데 그냥 겉핥기로 넘어가는 것은 별로 추천하지 않습니다. 어차피 깊이 들어간다 해도 깊이 파고드는데 한계가 나올겁니다. 

이럴때 멘토링 시스템이 도움이 됩니다. 제가 멘티님께 실제로 추천한 방법입니다. 일단 모르는 부분이 나오면 질문을 정리해봅니다. 해당 내용을 구글링 혹은 ChatGPT를 통해 알아봅니다. 여기서도 해결이 잘 되지 않는다면 내가 찾았던 결과물과 내가 이해한 것을 먼저 정리해서 얘기하고 멘토님께 질문을 합니다. 

그러면 찾은 내용과 이해한 내용을 기반으로 멘토님이 이해가 더 잘되도록 설명해주실 겁니다. 다시 질문으로 들어가서, 최대한 깊게까지 가시고 모르는 부분을 멘토님께 질문해서 더욱 뚫어나가보세요.
 

Q. 같은 시간에서도 남다른 성취를 보이는 이들은 무엇이 다른 걸까요?

이건 보통 남의 떡이 더 커보인다고들 하죠. 정말로 그 사람이 놀라운 성취를 이뤘는지는 실제로 알기는 쉽지 않습니다. 특정한 분야에서 더 특별히 잘하는 사람이 있을수도 있습니다. 

하지만 공부는 길고 긴 장거리 마라톤과 같습니다. 내가 공부를 멈추지 않는다면 언젠가는 내가 한참 앞설수밖에는 없습니다. 가령 다양한 분야로 넓게 아는 사람이 있을 수 있죠. 하지만 본인이 한 분야에 대해 깊게 알고 있을 수도 있는거죠. 성취를 남과 너무 비교하려 하지 마세요. 그보다는 나에 집중하는 것이 더 좋습니다. 내가 꾸준히 해나간다면 성취도 자연스레 따라오게 되어있습니다.
 

Q. 신입 개발자가 흔히 저지르는 실수가 있다면 무엇일까요?

저 역시도 신입때 많이 저지른 일이기도 한데요. 학교에서 과제 제출하듯이 일감을 처리해서는 안된다는 겁니다. 학교 과제는 보통 Test Case를 통과하는데 주묵적이 있고, 그러다보니 특정 과제의 목표만을 향해 무작정 달려나가는 경향이 있습니다. 

하지만 제품을 완성할 때에는 제품의 완성도도 못지않게 중요합니다. 더 많은 시나리오와 더 많은 Edge Case를 생각하여 테스트와 검증을 하고, 테스트 코드를 넣어두어 다른 사람이 이 Feature를 깨트리지 않게 하는 것이 중요합니다. 이를 위해서는 제품 전반적으로 좀 더 알 필요가 있지요. 그래서 쉬운일은 아닙니다. 단순히 로직의 에러만 잡으려는 것은 아니거든요. 프로그래밍을 모르는 사람들과 많은 커뮤니케이션을 통해 이 기능의 Scope와 확장가능성 여부를 판별하는게 중요합니다. 

또한, 내가 만든 Feature의 Ownership을 가지고 사후에 기능의 무결성을 종종 체크하는 것도 중요하지요. 이것이 시야를 넓혀나가는 과정입니다. 이런 태도로 개발을 진행하다보면 나의 Ownership Features가 늘어나게 되고 점점 팀에 기여하는 양이 늘어날 수 있습니다.

깊이 있는 인사이트와 현실적인 조언이 담긴 멘토님들의 인터뷰와 커리어 성장 콘텐츠가 데브클럽에서 정기적으로 업데이트되고 있습니다.

실력 있는 현직 개발자 멘토들과 직접 소통하고, 생생한 실무 노하우와 커리어 성장 전략을 배워보세요!

👉 데브클럽 한 달 동안 무료로 시작하기