본문은 요즘IT와 세계 최대 빅데이터 기반의 번역/현지화(Localization) 기업 Sprok DTS에서 함께 만든 해외 번역 콘텐츠입니다. 필자인 Leonardo Placanic는 ‘Aincrad Tech’의 설립자 및 소프트웨어 엔지니어로, 기업이 모바일 및 웹 애플리케이션에서 가치를 높일 수 있도록 돕고 있습니다. 이번 글은 주니어 개발자가 미드레벨 개발자로 도약하기 위해 필요한 7가지 단계를 설명하고 있습니다.

회원가입을 하면 원하는 문장을
저장 할 수 있어요!

개발

주니어 개발자에서 미드레벨 개발자로 도약하기 위한 7단계

요즘IT의 번역글들

8분

2022.10.17.

24.8K

저는 지난 4년간 소프트웨어 엔지니어로 경력을 쌓았으며, 제가 의뢰받은 작업 수준을 보면 이제 미드레벨 개발자에 속합니다. 어떻게 이 자리까지 성장할 수 있었을까요? 제가 성장하면서 경험한 것들을 7개의 핵심 포인트로 정리해 봤습니다.

1. 시니어 개발자의 피드백을 경청할 것

대다수의 주니어 개발자의 경우, 개발 리더 또는 시니어 개발자, 프로젝트 관리자 등의 공식 명칭을 가진 개발 경력자들을 포함한 팀에서 근무하고 있을 것입니다. 경험이 많은 개발자들의 업무 중 하나는 주니어 개발자의 작업을 확인하고, 이에 대한 피드백과 조언을 통해 주니어 개발자의 실력을 향상시키고, 회사에 도움이 되는 인재로 발전하도록 도와주는 것입니다.

저도 시니어 개발자와 이러한 과정을 겪어본 경험이 있죠. 누군가가 내 작업을 판단하는 것에 익숙하지 않다면 조금은 의아한 기분이 들 수도 있습니다. 그러나 다들 언젠가는 시니어 개발자의 자리에 앉기를 원하는 만큼, 시니어 개발자의 조언을 경청하고 잘 활용해 보세요.

2. 코딩, 테스팅, 리팩터링, 테스팅을 반복할 것

코딩이란 매우 복잡한 과정입니다. 소프트웨어를 최선의 방법으로 만들기 위해서는 소프트웨어 엔지니어링 업계에서 수년간의 경험이 필요합니다. 그러나 업계 특성상 워낙 일이 분주하기에, 기업들이 어쩔 수 없이 소프트웨어 최적화에 대한 책임을 개발자에게 넘기곤 합니다. 제 코딩 실력을 향상하는데 많은 도움이 된 전략은 다음과 같습니다.

코딩을 해볼 것: 생각해낸 솔루션을 도입한 후, 이를 인증하기 위해 몇 번의 테스트를 돌려보세요.
리팩터링[1] 할 것: 바람직한 관행과 지침을 따라 코드를 개선한 후, 최종 검증 과정을 위해 더욱 빈틈없는 테스트를 만드세요.

이와 같이 이중 테스트 단계를 도입한 결과, 저는 개선된 코드와 한층 나아진 기능을 선보일 수 있었습니다.

3. 가능한 스스로 결정을 내릴 것

개발자로서 첫발을 내디딜 때, 특정한 상황에서 어떻게 하면 좋을지 모르는 경우가 많습니다. 코딩 도입 단계에서 기술에 대한 결정이든, 작업 우선순위와 관련된 결정이든, 따로 공지된 바가 없는 한 본인이 최선이라고 생각하는 방법에 따라 행동하고 시도해 보세요.

특히 서로 다른 시간대에서 근무하는 팀의 일원이거나, 개발 리더가 연락이 안 될 경우 스스로 결정을 내리는 능력이 더욱 중요합니다. 스스로 결정을 내림으로써 작업에 방해가 되는 걸림돌을 제거하고 생산성을 높일 수 있습니다. 이는 기업에서 매우 높게 평가하는 부분입니다.

4. 진행 상황과 기대치, 문제점에 대해 소통할 것

어느 회사에서 근무를 하든, 대부분의 직장에서는 작업 진행에 대해 매일 또는 매주 업데이트하는 시간을 가집니다. 이러한 미팅에 참석할 때 본인의 작업 진행 상황에 대해 솔직하게 공유하기를 바랍니다. 특히 현재 겪고 있는 문제점이나 이슈를 꺼내는 것을 추천합니다. 본인 실력에 따라 다르겠지만, 현재 겪고 있는 문제점에 대해 솔직하게 이야기할 경우, 팀에서는 그저 단순한 팁이 아닌 든든한 도움의 손길을 건네줄 것입니다.

기대치와 진행 일정의 경우 요청받는 모든 사항을 수락하기보다는, 기대 이하의 열정을 보이되 기대 이상의 결과를 보여주려고 해보세요. 본인이 겪고 있는 문제에 따라 어떻게 진행할지, 그리고 작업을 완성하기까지 얼마나 많은 시간이 걸릴지 대략적인 진행 상황에 대해 솔직하게 공유하세요.

5. Git을 익힐 것

Git[2]을 UI 버전과 함께 사용하든, CLI 버전과 사용하든, 그 밖의 어떤 방식으로 사용하든 Git은 모든 작업에 매일같이 사용하는 도구입니다. 다른 개발자들과 저장소(repository)를 함께 사용하기 위해서는 브랜치[3]를 리베이스(rebase)[4], 병합, 생성하는 방법을 배우는 과정이 핵심입니다. 조언을 하자면 Git과 관련된 온라인 자료를 살펴보고, 더미 프로젝트를 대상으로 이런저런 시험을 해보면서 Git의 가능성을 발견하는 것을 추천합니다.

이와 동시에 자사의 Git 호스팅 서비스, 즉 Github, Bitbucket, Gitlab 등에 올라오는 활동 내역을 매일 확인하세요. 여기야말로 본인이 프로젝트에 실제로 얼마나 기여하고 있는지, 그리고 본인이 얼마나 성장하고 있는지 확인할 수 있는 곳입니다. 또한 다른 개발자들의 PR을 확인해 볼 수 있는 곳입니다. 특히나 경험이 많은 개발자들의 코딩과 본인의 코딩을 비교해 볼 수 있는 장소이기도 하죠.

6. 본인의 잘못을 파악하고 실수를 통해 배워나갈 것

실수를 해보는 것이 경험을 쌓는 데 가장 큰 도움이 됩니다. 물론 삶에도 적용되는 교훈이지만, 코딩에서는 더욱 중요한 교훈입니다. 작업을 올바르게 처리하고 지침에 따라 행동하며, 튜토리얼을 보는 것으로도 많은 정보를 습득할 수 있지만, 실수를 하고 이를 파악하는 과정을 통해 해당 작업의 원리를 훨씬 더 잘 기억할 수 있을 것입니다. 즉, 개발자로서 실수를 하는 것은 당연한 일이며 이 사실을 받아들여야 합니다. 회사에서 본인의 실수를 인정한다는 것은 실수를 빠르게 파악하고, 이러한 실수를 어떻게 방지할 수 있는지 솔루션까지 함께 이해한다는 것입니다. 주니어 개발자에게는 후자가 더 중요할 것입니다.

실수를 했다면 본인의 실수를 숨기거나, 도망치거나, 타인을 탓하지 마세요. 만약 타인의 실수인 경우, 이러한 실수가 다시 일어나지 않도록 책임을 묻는 게 맞겠지만, 자신이 저지른 실수라면 솔직하게 말하고 책임을 지도록 노력하세요. 장기적으로 봤을 때 이와 같은 솔직한 의사소통은 본인의 성장에도 도움을 주지만, 팀원들 사이의 신뢰 또한 두터워질 것입니다.

7. 360도를 볼 수 있는 개발자가 될 것

업계에서 4년 동안 수많은 개발자들을 봤지만, 최근 들어 A에서 Z까지만 보는 개발자들과 360도를 보는 개발자들 간의 차이가 계속해서 눈에 띕니다. 이게 무슨 뜻일까요? A에서 Z까지만 보는 개발자란 어떠한 업무가 주어졌을 때 몇 가지 단순한 작업을 진행한 후, 제대로 된 결과 또는 오류를 보여주고, 추가적인 지시를 받기 전까지 아무런 행동도 취하지 않는 개발자를 뜻합니다. 이런 유형의 개발자는 2가지 이유로 갈등을 유발합니다. 첫째, A에서 Z까지만 보는 개발자는 다른 사람들이 수시로 지시를 내려줘야만 작업을 진행할 수 있습니다. 둘째, 이런 개발자들은 문제점을 해결하거나 더 나은 결과물을 내기 위해 작업 범위를 벗어나는 법이 없습니다.

360도를 보는 개발자란 주어진 업무를 완수하기 위해 많은 노력을 쏟고, 기대 이상의 결과물을 보여주는 개발자입니다. 여기서 기대 이상의 결과물이란 개선된 솔루션이나 코딩의 도입, 관련된 주제에 관한 경영/기술 지식의 축적, 명확하고 현명한 질문들을 생각해낸 후 다른 팀원에게 연락하는 등의 다양한 행동을 말합니다.

즉, 개발자란 몇 줄의 코딩을 작성하고 실행하여 업무를 완성하는 로봇이 아니라는 것을 처음부터 똑바로 이해하고 있어야 합니다. 개발자가 능력 향상을 위해 할 수 있는 활동은 너무나도 많습니다. 예를 들어, 자신이 개발하고 있는 프로그램의 논리를 이해하는 등 비즈니스 지식을 쌓고, 리팩터링 과정을 개선하거나 최신 기술에 대한 지식을 갖추는 것들이 있습니다.

결론적으로 미드레벨 개발자가 되기 위해서는 최소 1~2년 이상의 경험이 필요하며, 그 기간 동안 무엇을 하는지에 따라 기간은 더 길어지거나 단축될 수 있습니다.

[1] 리팩터링(refactoring)은 소프트웨어 공학에서 결과의 변경 없이 코드의 구조를 재조정하는 것을 뜻한다. 버그를 없애거나 새로운 기능을 추가하는 것은 아니며, 주로 가독성을 높이고 유지보수를 편하게 한다.
[2] 깃(Git)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.
[3] 마스터 버전의 복사본을 만들어 다른 방향으로 작업을 이어가는 것을 뜻한다.
[4] 파생된 브랜치의 기준이 되는 베이스 커밋을 변경하는 것이다.

<원문>

7 Steps to Go from Junior to Mid-level Developer

위 번역글의 원 저작권은 Leonardo Placanic에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.