들어가며
먼저 이 글은 ‘다프나 로젠블룸’님의 What we expect from software developers on each level 이라는 글을 읽고 옮겨본 글입니다.
현업에 오래 있다보면, 가끔씩 나의 위치와 회사 (혹은 주변에서) 바라는 것들이 무엇인지 또한 다른 조직이나 혹은 더 넘어가서 다른 나라의 개발자들은 어떤 위치에 있는지 물어보게 됩니다.
이 글을 옮긴 의도는 제 자신의 위치와 제 자신의 앞으로 갈 방향성을 성찰해보고자 하는 자세에서 시작되었습니다.
아무쪼록 저도 해답을 빨리 얻을 수 있고, 이 글을 읽는 여러분들도 많은 해답을 얻을 수 있었으면 좋겠습니다.
각 레벨의 개발자에 기대하는 것들
저는 저희 조직내의 엔지니어와 QA 분들을 대상으로 레벨 시스템을 도입하였습니다. 또한 도입하기 위해서 저희 부서에서 수행하였던 일을 정리하였고, 그 내용을 이전 글에 작성 하였습니다. 링크
기술 이사진 회의에서 토론을 끝 마쳤고, 모든 구성원들의 기대와 느낌을 피드백 받았습니다. 그 결론을 아래 목록으로 정리 완료 했습니다.
이 글이 “아직 이 레벨에는 도달하지 못했어!” 라는 쥬니어 개발자 혹은 영감을 얻고자 하는 관리자분들에게 도움이 되길 바랍니다.
모든 레벨의 기대요소는, 하위 레벨 의 기대요소를 포함해야 합니다.
물론 각자마다 능력치가 다르므로 아래 포함된 레벨의 기대치에 약 80% 로 보정하면 되지 않을까 싶습니다.
각 기대요소에 태그를 붙여 보았습니다. 요구사항, 레벨업 기회, 기타 등등 인데요, 만약 별도로 언급이 없다면 기대요소는 모두 ‘필수사항’ 입니다. ‘기본’ 과 ‘레벨업 조건’ 들 태그들은 관심 가져주세요.
엔트리 레벨 (Entry Level)
- 작업물과 업무 프로세스에 대해서 발표하고 토론할 수 있어야 합니다.
- 작업툴에 대한 학습과 연구에 관심이 있어야 합니다. (레벨업 기회)
- UI 단의 버그를 재현하고 수정할 수 있어야 합니다.
- 코드를 클린하게 짜는걸 배우고 연습해야 합니다. (레벨업 기회)
- 코드 흐름에 따른 테스트와 버그 수정을 직접 할줄 알아야 합니다. - 커밋까지 직접 해야 합니다
- 멘토의 엄격한 지시하에, 자기 레벨이상의 업무를 수행할 수 있어야 합니다. (레벨업 기회)
- CI/CD 툴과 코드 흐름을 이해하여야 하며, 멘토와 함께 실제 서비스로 배포할 수 있어야 합니다.
- 코드에 대한 주석을 작성하여야 합니다. 또한 코드 가독성도 개선할 수 있어야 합니다. - 상관없는 코드에서 명확하지 않은 주석 같은거 말이죠 (레벨업 기회)
- 피드백 받은 뒤 개선할 수 있어야 합니다. 물론 건설적이고 구체적인 피드백을 줘야 하죠. (기본)
- 필요하다면 도움을 요청할 용기도 필요합니다!
- 다른 사람이 코드를 리뷰한걸 분석하고 또한 이해하여야 합니다.
쥬니어 레벨 (Junior Level)
- 자기 스스로 일정에 대해서 계획을 세우고, 책임질 수 있습니다.
- 실제 서비스에서 생긴 버그를 해결할 수 있습니다. 오류 보고를 보고 재현하고, 조사하고, 수정하고 배포하고.
- 유닛 테스트를 작성하고, 잘 굴러가도록 하여야 합니다. (레벨업 기회)
- 자신의 지식을 공유할 수 있어야 합니다. 내부 채널에 글을 쓰거나, 강연을 하거나, 혹은 유튜브로 올리거나 블로그를 작성하는 것 처럼요. (레벨업 기회)
- 매일 현재 진행 상황에 대해서 이야기 하여야 합니다.
- 개발자 모임에 참석 합니다. (레벨업 기회)
- 스탠드업 미팅에서 다른 팀원들의 상황을 인지하고, 아니면 적어도 나중에라도 최대한 이해를 해야 합니다.
- 시간 기대치를 이해하고, 이슈에 대해서 블로커나 지연되는 것에 대해서 이슈업을 하여야 합니다.
- 업무에 대해서 예상 시간을 산정해야 합니다. (예를 들어 1.5일 같이) 완벽하지 않아도 됩니다. 일단 선정 후에 업데이트 해서 픽스 하시면 됩니다.
- 개인 발전을 위해서 노력하세요. 개선할 영역이 무엇인지 파악하고 노력하세요.
- CI/CD 설정을 위해서 지원합니다. (레벨업 기회)
- 경험이 많은 동료와 짝이 되세요. (레벨업 기회)
- 혼자 스스로 (물론 멘토가 같이) 이미 서비스되고 있는 작은 프로젝트를 유지보수 할 수 있어야 합니다. (레벨업 기회)
- 코드 저장소에 있는 README 에 프로세스나 시스템에 대한 설명을 같이 쓸 수 있어야 합니다.
- 팀의 가이드라인에 따라서 코드리뷰를 진행하여야 합니다.
- 코드리뷰를 할 수 있도록 프로가 되십시오.
중간 레벨 (Mid Level)
- 합리적으로 Context Switch 를 구현할 수 있습니다.
- 스토리를 구현합니다. (업무를 추가하고 예상하고)
- 아키텍쳐가 결정된 의미에 대해서 잘 파악할 수 있습니다. (레벨업 기회)
- 모니터 추가, CI/CD 파이프 수정, DB 백업 변경등 완벽힌 데브옵스 작업을 수행할 수 있어야 합니다.
- 팀 업무가 아닌 독립적으로 작업을 수행할 수 있어야 합니다. (필요할 경우 팀의 제안에도 협조해야 합니다.)
- 디자인 패턴과 같은 모범사례에 익숙하며, 코드상에서 이걸 인식하고 새로운 코드를 작성할 수 있어야 합니다.
- 시스템 아키텍쳐 설계를 지원할 수 있어야 합니다. (레벨업 기회)
- 팀에서 제껄 (적어도) 하나라도 인용해야 합니다. 라이브러리든 뭐든
- 테스트 프레임워크를 세팅하고 테스트를 작성하는데 있어서 멘토 없이 혼자 해내야 합니다.
- 더 많은 주니어 개발자와 어울리십시오. -저는 비추합니다. 오히려 선배와 어울려야 하지 않을까요?- (레벨업 기회)
- 주니어 개발자를 이끌어 주세요.
- 스스로 개발환경을 세팅할 수 있어야 합니다. (레벨업 기회)
- 가독성과 유지 관리가 가능한 코드를 리펙토링할 수 있어야 합니다.
- 다른 사람의 코드를 리뷰하세요.
- 어플리케이션의 사이클을 이해하여야 합니다.
시니어 레벨 (Senior Level)
- 자신의 분야에서 처음부터 밑바닥부터 설계할 수 있어야 합니다.
- CI/CD 툴을 세팅할 수 있어야 합니다.
- 프로젝트의 플랫폼에 대한 가독성, 확장성 및 유지 관리에 대해서 책임져야 합니다.
- 연구후에 팀원들과 고려해서, 프로젝트의 기술스택을 결정할 수 있어야 합니다.
- 중간 레벨과 쥬니어 레벨을 멘토링할 수 있어야 합니다.
- 테스트할 수 있는 플랫폼을 선택하고, 테스트할 것들을 선정합니다.
- 최신 소프트웨어 아키텍쳐 패턴에 대한 지식을 가지고 있으며, 해당 분야에서 작업할 수 있어야 합니다.
- 요구사항을 확인하고 구현 세부 사항에 대해서 팀 내외적으로 논의할 수 있습니다.
- Be active in the API specs (contracts) creation (both ends). - 역주 이 부분에 대해서 해석이 애매해서 해석하지 않았습니다.
- 해당 도메인 내에서 복잡한 버그를 분석할 수 있습니다.
- 자기 업무 분야 밖의 소프트웨어 솔루션도 일반적인 기준내에서 판단이 가능합니다.
- 코드 리뷰에 대한 기준을 정의할 수 있습니다.
- 새로운 기술을 배우고, 트랜드를 따를 수 있으며, 모범사례들을 가져올 수 있습니다. (기본)
- 기존 내부 작업에 데브옵스 작업을 통합할 수 있습니다.
- 알려진 업무나 기술적 문제에 대한 솔루션을 연구하고 제시할 수 있어야 합니다.
- 프로젝트에 사용되는 전체 스택을 이해 하여야 합니다. (레벨업 가회)
- 가능성에 대한 통찰력을 가지고 고객의 요구에 충족하는 방법을 알고 있습니다.
- 솔루션의 문서에 책임을 질 수 있어야 합니다. 예를 들면 코드 저장소에 있는 README 의 프로세스나 시스템에 대한 설명 같은 것들이죠.
테크 리더 / IC 경로 (Tech Lead / IC Path)
저희의 테크 리더들은 프로젝트에서 80% 는 시니어 개발자을 담당하게 되며, 나머지 20% 는 앞으로의 기술을 이끌 책임이 있습니다. 각 분야에 대해서 리딩이 필요합니다. 예를 들어 안드로이드 쪽 리더 같이 말이죠.
- 내부 교육과 연감을 불어주는 말을 할 수 있어야 합니다.
- 앞으로의 성장에 대한 자문을 줄 수 있어야 합니다.
- 해당 지역이나 혹은 온라인으로 각 도메인에 맞는 커뮤니티에 참여하여야 합니다.
- 내부나 외부로 지식을 전달 할 수 있어야 합니다.
- 면접 과정에 참여하야 합니다.
- 클라이언트 시스템에 대한 통합에 대해 방향성과 권장사항을 제공하여야 합니다.
- 클라이언트와 업무에 대해서 이해할 수 있는 팀을 만들 수 있어야 합니다.
- 앞으로 6~12 개월 동안 우리가 직면하게 될 과제에 대해서 생각하고 소통할 수 이썽야 합니다.
- 프로젝트, 서비스, 시스템 및 프로세스의 복잡성을 도메인 관점에서 줄이는 방법에 대해 조언합니다.
- 클라이언트의 비용에 맞추어서 가장 효율적인 UX, 정보 설계, 확장성 및 보안을 갖춘 시스템 아키텍쳐를 설계합니다.
- 플렛폼/프레임워크에 대한 도메인 지식을 가지고 있어야 합니다.
- 도메인의 기술에 대해서 레이더로써 이에 책임을 지고 의사 소통 하십시오.
테크 디렉터 / 관리자 경로 (Tech Director / Manager Path)
- 코딩 습관/관행에 대해서 정의하고 추적하십시오.
- 솔루션 및 시스템 아키텍쳐 관행에 대해서 정의하고 이끌 수 있습니다.
- 지역의 외부 기술 포럼에 참석하고 기여 합니다.
- 고객 비지니스를 이해하고 이러한 이해를 솔루션에 반영할 수 있습니다.
- 부서에 대한 정의를 내릴 수 있습니다. 부서 문화 / 기술 스택 등
- 클라이언트와 신뢰 관계를 생성하고, 각 협업 부서 사람들과 긴밀한 관계를 구축합니다.
- 팀에서 기술적인 장벽들을 없앨 수 있습니다.
- 병목이 되는 경우를 확인하고, 이를 해결하기 위해 구조를 변경할 수 있습니다.
- 팀원들의 성장 계획에 따라서 멘토할 수 있어야 합니다.
- 능력, 성장, 협업 및 혁신을 극대화 하기 위해 역동적인 팀을 구성할 수 있어야 합니다.
- 팀원들에게 1:1 로 이야기할 수 있어야 합니다.
- 디자인과 비지니스 디렉터와 협력하여 목표를 달성하십시오.
- 팀의 충돌을 해결합니다.
- 클라이언트에 대해서 전략적으로 자문을 줄 수 있습니다.
- 건설적인 피드백 문화를 유지관리 할 수 있습니다.
- 커뮤니티 문화를 만드는데 지원할 수 있어야 합니다.
정리
모든 조직은 서로 다른 요구사항을 가지고 있습니다. 우리에게 특화된 레벨이고 이게 다른 회사에서도 동일하게 적용해야 하는 것을 의미하진 않습니다. 시간이 되신다면 이 글을 읽기를 추천 드립니다. 생산성을 해치지 않고 엔지니어링 조직에 레벨을 도입한 방법