오늘 팀원 한 명이 면담을 신청해서 이런저런 얘기를 나눴는데, 어쩌다보니 이직으로 주제가 옮겨갔다. 팀원이 지금보다 더 좋은 곳으로 간다면 축하의 박수와 함께 보낼 수 있을 정도로 이직 자체를 나쁘게 생각하지 않는데, 문제는 그 시기였다. 그 팀원은 한 회사에서 3년은 너무 길다고 생각하고 있었다.
면담 자리에서 생각나지 않아서 말은 못했지만, 나중에 그 의견을 곱씹어보니 과거에 읽었던 글이 생각난다.
Full Cycle Developers at Netflix이라는 글이다. (번역본은 여기)
넷플릭스 기술 블로그에서는 2018년에 공개한 글이지만, 이 글은 2021년에 접했다. 이 글은 Full Stack 이 아닌 Full Cycle 개발자를 정의하고 있다. 이 글에서 말한 사이클이란 흔히 말하는 소프트웨어 개발 수명 주기(Software Development Life Cycle, SDLC)과 일맥상통하다.
SLDC는 분석, 계획, 개발, 테스트, 배포, 유지보수라는 과정을 거치는데 넷플릭스의 기술 블로그는 SLDC와는 조금 다르게 하나의 사이클을 설계, 개발, 테스트, 운영, 지원의 단계로 나누고 있다.
여기서 중요한 건 사이클
이라는 단어다. 국어로는 주기
라는 단어가 가장 적합하다.
같은 현상이나 특징이 한 번 나타나고 부터 다음번 되풀이되기까지의 기간.
출처: 네이버 국어 사전
즉, 사이클은 1번 돌고 끝나는게 아니다. 1회성 납품이 아닌 이상에야 대부분의 소프트웨어 특히 서비스 업체의 개발팀은 이 사이클을 서비스가 종료할 때까지 지속적으로 반복하게 된다.
이제 1년 조금 넘은 주니어 팀원에게 이 사이클을 다 완벽하게 돌아보라는건 과한 욕심일 수도 있다. 다만 사이클을 한 번 돌 때와 여러 번 돌 때는 많은 차이가 있다고 자신있게 말할 수 있다.
사이클을 지속적으로 돌면 어느 순간 자신의 발목을 붙잡는 건 대부분 자신이 짠 코드 혹은 설계다. 나 역시 “왜 그때의 나야, 왜 코드를 이렇게 짰니, 왜 설계를 이렇게 거지같이 했니"하고 혀를 찰 경우가 많다. 회사마다 사정이 다르겠지만 경험상 1년 반 ~ 2년부터 겪게 되며, 이 때 정말 많은 걸 배우게 된다.
또한 자신이 짠 코드를 수정하게 될 때는 추가 개발이 들어올 때와 지원 업무가 들어올 경우가 많다. 추가개발이나 지원 업무를 위해 코드를 추가/수정하게 되면 내가 작성한 코드가 얼마나 확장이 힘든지, 가독성이 얼마나 떨어지는지, 이 클래스는 왜 이렇게 혼자서 많은 짐을 짊어지고 있는지 몸소 체험할 기회가 된다.
결론적으로 다들 이직은 언젠가 하겠지만 이렇게 여러 사이클을 겪어본 사람과 아닌 사람은 큰 차이가 있다. 수학에서 1 x 10 = 10
이지만 1년 짜리 업무를 10번 반복한다고 10년 경력의 개발자가 되는건 아니다.
결론적으로 난 한 군데서 최소 3년을 일해보길 권한다.
이 글은 작은 기업에 재직하는 개발자를 대상으로 썼습니다. 주로 스타트업같이 외주가 아닌 자신의 서비스를 운영하는 기업이 기준입니다. 또한 “제대로” 된 회사라는 전제 하에 쓴 글입니다.