미드레벨 SW 엔지니어가 갖춰야 할 7가지 역량

소프트웨어 엔지니어로 2-3년 정도 경력이 쌓이면 이제 주니어 레벨에서 벗어날 준비가 필요하다. 회사에서도 한 단계 높은 미드레벨 개발자의 역량을 요구하기 때문이다. 평균적인 수치로 경력을 2-3년이라고 했지만 이는 사람마다 다를 수 있다. 빠르면 1년 이내 미드레벨에 도달할 수도 있고, 길면 4-5년 차 또는 그 이상이 될 수도 있다. 일반적으로 많은 회사에서 개발자 채용 시 ‘3년 이상의 경력’을 요구하는데, 해외에서는 L4 정도의 레벨을 의미한다. 이번 글에서는 주니어 개발자가 미드레벨에 도달하기 위해, 어떤 역량이 필요한지 필자의 경험을 토대로 살펴보고자 한다.

1. 버그를 고칠 수 있어야 한다

개발자라면 누구나 실수하고 버그를 만들 수도 있다. 버그를 만드는 것 자체는 잘못이 아니다. 만약 스타트업처럼 빠른 배포 주기와 개발 속도를 유지하는 문화라면, 오히려 사소한 버그를 고치느라 속도가 느려지는 것보다는 버그가 있어도 빠른 속도를 유지하는 편이 나을 수도 있다. 다만 누가 만든 버그든 담당하고 있는 팀에서 문제가 발생했다면 책임감을 가지고 고칠 수 있어야 한다.

물론 모든 버그를 혼자 힘으로 고쳐야 하는 것은 아니다. 문제에 대해 잘 아는 사람의 도움을 받아, 빠르게 해결하는 것도 중요한 역량이다. 어디까지 본인이 할 수 있는지 확인하고, 모르는 영역은 팀원들의 노력을 최소한으로 빌려 빠르게 해결하는 것이 좋다. 먼저 혼자 고민하는 시간에 제한을 두고(ex. 30분) 최선을 다해 본 후, 그래도 해결되지 않으면 빠르게 도움을 요청해야 한다. 숙달된 개발자일수록 이 시간은 짧아진다.

나의 경우 회사에서 클라이언트 개발을 맡고 있는데, 가끔 동료 개발자들이 어떤 이슈를 사내 메신저에 올리면 나를 찾지 않더라도 가능하면 꼭 보려고 한다. 그리고 완벽한 도움은 아니어도 도움을 줄 수 있으면 꼭 메시지를 남기려고 한다. 두 가지 이유가 있는데 이러한 단서로 동료가 해당 이슈를 더 빠르게 해결할 수도 있고, 나도 언제 어떤 이슈로 도움을 요청하게 될지 모르기 때문에 미리 신뢰 비용을 적립하는 측면도 있다.

2. 그 기술이 왜 필요한지 명확히 설명할 수 있어야 한다

직급이 올라갈수록 중요한 의사결정을 해야 할 일이 많아진다. 특히 기술적인 의사결정의 경우, 최고 기술 책임자(CTO, Chief Technical Officer)나 각 팀의 테크 리드(Tech Lead)가 주도해 진행할 가능성이 높다. 이때 미드레벨 엔지니어는 새로운 기술에 대한 아이디어를 제안하거나, 어떤 기술을 도입할지에 대해 자신의 의견을 충분한 근거와 함께 제시할 수 있어야 한다.

새로운 기술을 도입할 때, 공식 문서나 관련 자료를 찾아보면 보통 해당 기술의 장점 위주로 정리된 글이 많다. 하지만 “은 탄환은 없다”라는 말이 있듯이 장점만 가지고 있는 기술은 없다. 만약 단점이 없어 보이는 새로운 기술을 도입한다고 해도, 그 기술을 팀에서 학습하는데 들어가는 러닝 커브나, 해당 기술에 능통한 개발자를 채용하는데 드는 시간, 비용 등을 함께 고려할 수 있어야 한다.

예를 들어, 팀에서 모노리포(mono-repo) 형태로 여러 개의 리포지토리를 관리한다는 의사 결정을 내린다고 가정해 보자. 모노리포가 가진 여러 장점이 있는데, 대표적으로 디자인 시스템이나 유틸성 모듈의 경우, 하나를 만들어 여러 리포에 쉽게 적용할 수 있다는 장점이 있다.

반면 이를 관리하는데 드는 비용이 모노리포를 사용하지 않을 때에 비해 훨씬 높고, 복잡도를 낮추기 위해 관리하는 담당자가 없을 경우, 오래 관리하기 힘들다는 단점도 있다. 이럴 때 미드레벨 엔지니어는 기술의 장단점을 비교해 의견을 내고, 그 기술이 왜 필요한지 명확히 설명하여 동료들을 설득시킬 수 있어야 한다.

3. 팀 차원에서 일을 잘할 수 있는 방법을 고민해야 한다

주니어 레벨의 경우, 본인이 이뤄낸 작은 성과에 대해서도 인정받을 수 있다. 하지만 2-3년 정도 경력이 쌓이면 단순히 본인에게 주어진 일을 해내는 것을 넘어, 팀 동료에게도 도움을 줄 수 있어야 한다.

예를 들어, 팀에서 A, B, C 라이브러리를 쓰고 있을 때, 이 중 하나 이상은 잘 알아두고, 해당 라이브러리를 잘 모르는 팀원이 있을 때 가이드 해주는 역할을 하면 좋다. 만약 본인이 동료들에 비해 더 잘 아는 분야가 하나도 없다면, 자주 쓰는 기술 하나 정도는 깊게 공부하는 것이 좋다. 현재 소속된 팀은 물론 나중에 이직할 때도 큰 도움이 될 것이다.

그리고 좀 더 나아가 팀이 더 효율적으로 일할 수 있는 방법에 대해 고민해야 한다. 예를 들어, 프로젝트 빌드 시간을 줄일 수 있도록 배포 프로세스를 개선할 수 있다면, 본인뿐만 아니라 함께 일하는 동료들의 시간도 절약할 수 있다.

4. 일정 수준 이상 퍼포먼스를 낼 수 있어야 한다

앞서 언급했던 것처럼 미드레벨 엔지니어가 되면, 조직에서 개인에게 기대하는 바가 커지게 된다. 다시 말해 ‘전문가’라고 불릴 수 있는 커리어의 시작 단계인 것이다. 그래서 조직은 한 사람이 일정 수준 이상의 퍼포먼스를 낼 것을 기대하며 제품 계획을 세운다.

만약 본인의 퍼포먼스가 기대 이하로 떨어져 일정에 지장을 준다면, 이는 매출이나 주요 지표에도 영향을 줄 수 있다. 조직 입장에서는 손실이 발생하는 것이다. 주니어 레벨의 경우 어느 정도 감안하고 진행할 수 있지만, 미드레벨 엔지니어의 퍼포먼스 저하는 가볍게 여겨지지 않을 때도 많다. 혹시 개인적인 이유로 퍼포먼스를 꾸준히 낼 수 없는 상황이라면, 혼자 고민하기보다는 리더에게 미리 공유해 상황을 빠르게 인지시키는 것이 좋다.

5. 원활한 커뮤니케이션으로 요구사항을 협의해야 한다

미드레벨 엔지니어는 작은 프로젝트에 혼자 투입되어, 주요 의사결정을 스스로 해나가며 일을 진행할 수 있어야 한다. 일을 빠르게 진행해 마감 일정을 맞추는 것은 물론, 필요에 따라서는 스펙을 늘이고 줄이는 결정까지도 스스로 하는 것을 요구받는 단계다.

예를 들어, 2주 안에 새로운 기능을 만든다고 가정해 보자. 주니어 개발자라면 2주 안에 주어진 단위 태스크를 잘 끝내기만 하면 된다. 하지만 미드레벨부터는 그 일정이 합리적인 일정인지, 2주 안에 끝낼 수 없다면 이유가 무엇인지, 스펙에서 어떤 부분은 빼는 것이 좋을지 등을 고민하여 리더와 팀원들에게 공유해야 한다.

만약 2주 안에 무조건 기능을 출시해야 한다면 본인의 요구사항을 정리해 팀을 설득시키거나, 필요에 따라 다른 팀에 협조 요청을 구해야 한다. 또한 일의 우선순위를 매겨 현실적인 개발 범위를 재정의 하는 것도 필요하다.

6. 배포 이후 발생할 수 있는 문제에 대비해야 한다

일반적으로 서비스가 출시되고 버그를 발견하면 중요도에 따라 핫픽스 등으로 고치거나, 정기 배포 일정에 맞춰 버그를 수정한다. 여기서 미드레벨 엔지니어는 이 코드가 배포되었을 때 어떤 문제가 발생할 수 있는지, 단기 또는 중장기적으로 어떻게 해결하고 대응할 것인지에 대한 계획을 세워야 한다.

예를 들어, 웹 애플리케이션에 새로운 기능을 출시했다고 할 때, 만약 ‘서비스를 네트워크 환경이 좋지 않은 지역에서 쓴다면 어떨까?’ 혹은 ‘고령의 사용자가 폰트 크기를 키워 모바일 웹 뷰 환경에서 본다면?’과 같은 상황을 예측해야 한다. 물론 이러한 상황은 발생하지 않을 수도 있다. 하지만 그동안의 개발 경험을 바탕으로 서비스 규모가 더 커졌을 때, 더 많은 사용자가 생겼을 때 예상되는 문제점에 미리 대비할 수 있어야 한다.

7. 코드 이해를 위한 빠른 판단과 행동력이 있어야 한다

누구나 남이 짠 코드를 이해하는 일은 어려울 것이다. 리드미나 주석이라도 친절하게 적혀있으면 다행인데, 가이드 문서도 없고 작업자도 퇴사한 상황이라면 스스로 코드를 파고들어야 한다. 이런 일은 실제 현업에서 많이 발생한다. 그래서 미드레벨 엔지니어는 이러한 코드를 일정 시간 안에 이해하고, 핸즈온(Hands-on)하여 문제를 해결할 수 있어야 한다.

우아한형제들의 김범준 전 대표는 한 인터뷰에서 회사에 처음 입사했을 때 5만 라인 정도의 리눅스 코드 베이스를 받아, 프로젝트를 진행해야 했던 에피소드에 대해 말했다. 당시 그는 소스코드에 이름이 남아 있던 개발자를 찾아가 설명을 요청했는데, 그분이 꼬박 하루 동안 모든 코드에 주석을 달아 주었다고 한다. 만약 혼자서 했다면 한 달이 지나도 못했을 분량을, 도움을 구해 빠르게 시작할 수 있었다. (물론 이러한 부탁에 선뜻 도움을 줄 수 있는 동료가 되는 것도 중요하다.)

마치며

지금까지 미드레벨 엔지니어가 갖추어야 할 역량에 대해 살펴보았다. 개인적으로 위에서 말한 7가지 역량 중 일부만 갖추는 것이 아니라, 모든 역량에 대해 일정 수준 이상을 갖추어야 미드레벨이 될 수 있다고 생각한다. 주니어 레벨 때는 회사가 기대하는 수준이 낮기 때문에, 빠르게 잘하면 점수가 플러스될 것이다. 하지만 미드레벨 엔지니어에게는 일정 수준의 책임을 요구하고, 미흡한 부분이 있으면 마이너스가 될 수도 있다.

이와 같은 이유로 미드레벨 엔지니어를 볼 때는 좀 더 엄격한 기준을 갖춘 곳이 많다. 기준이 너무 팍팍하다고 생각할 수도 있다. 그렇다고 언제까지나 주니어 레벨에 멈춰있을 수만은 없다. 우선 위 역량 중 본인이 어떤 점을 갖추고 있고, 부족한 부분은 무엇인지 파악해 보자. 처음부터 완벽한 사람은 없듯이, 부족한 부분을 채워나가려고 노력한다면 분명 훌륭한 엔지니어로 거듭날 수 있을 것이다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.