지난 번에는 경쟁력있는 시니어 개발자로 성장하는 방법에 대한 글을 썼다. 그럼 미들 레벨의 개발자나 주니어 레벨의 개발자들은 어떤 역할을 해야 하는걸까? 또 어떻게 해야 일을 잘한다고 평가받을 수 있을까?
오늘은 필자가 리더의 역할로 살아가면서 팀에 많은 도움이 되는 개발자들은 어떤 개발자이며 어떤 일들을 하는 사람인지에 대해서 이야기해보고자 한다.
얼마전 페이스북 개발자의 성과 만들기 라는 제목의 블로그 내용을 보았는데 그 안에는 페이스북에서 어떠한 기준으로 개발자를 평가하는지에 대해 쓰여져 있었다. 페이스북에서 직접적으로 쓰는 용어는 아니라 각색을 했다고 하니 어느 정도 감안해야겠지만 내가 사람들을 바라보는 요소가 매우 비슷하다고 생각하여 인상 깊게 읽었다.
과거에는 개발자에 대한 평가를 얼마나 짧은 시간 안에 버그없이 많은 기능을 만들어내는지가 주된 평가요소였다고 생각한다. 개발자가 외주 개발자라고 한다면 지금도 어느 정도 유효하다고 생각될지도 모르겠다. 하지만 최근의 조직 문화가 자기 조직화(self-organization) 중심의 문화로 바뀌어가면서 개발자 역시 단순히 요구하는 기능을 만들어주기만 하면 되는 것이 아니라 그 이상의 역할을 기대하게 되었다.
단순히 기능을 얼마나 많이 만들었는지보다 그 기능을 통해서 어떤 성과를 달성했고, 그 성과를 달성하는데 얼만큼의 기여를 했느냐가 더 중요하게 되면서 사용자들에게 외면받는 기능은 아무리 많이 개발해도 좋은 평가를 받기가 힘들어졌고 수동적으로 요구되는 기능을 개발하는 것이 아닌 과제 선정에 보다 적극적인 자세로 참여하는 방식으로 변화해야 했다. 하지만 여전히 기술에 대한 품질이나 협업과 같은 문화적인 측면에서 과소평가 되는 부분들이 많다고 생각한다. 페이스북에서 제시한 내용 중 이미 널리 알려진 프로젝트 성과를 제외한 항목들에 대해 우리 조직에서의 실제로 일어나는 사례 중심으로 조금 각색해서 나열해보겠다.
성과 평가 항목 별 사례
엔지니어링
좋은 품질을 유지하기 위한 활동을 했다
- 매주 뉴렐릭에 올라오는 지표들을 정리해서 공유하고 20개의 개선 백로그를 생성해서 관리했다.
- Github Action 에 lint 를 연동하여 룰 위반시 PR이 머지가 되지 않도록 설정했다.
개발 생산성 향상에 기여를 했다
- 개인정보 마스킹 처리 로직을 공통 모듈화 하여 팀에 공유하고 팀원들이 사용할 수 있도록 도왔다.
- ssh tunneling script를 팀 내에 공유해서 팀원들이 손쉽게 사용할 수 있도록 했다.
- 로컬 테스트 환경을 Dockerize 해서 팀원들이 손쉽게 테스트 코드를 실행할 수 있도록 했다.
코드, 설계 품질이 떨어지는 레거시 코드를 개선하거나 테스트 코드를 보강하였다.
- 기존에 존재하지 않던 회원가입 API의 API Spec 문서를 코드를 파악하여 작성했다.
- 테스트 코드가 존재하지 않던 회원탈퇴 기능의 테스트 코드를 작성했다.
안정성, 퍼포먼스를 크게 개선했다
- 장바구니 API 의 성능 개선 작업에 핵심적인 아이디어를 제공하여 기존 대비 5배의 성능 개선을 이끌어 냈다.
피플&컬쳐
업무에 도움이 되는 지식이나 정보를 공유했다
- 1분기 데브데이에서 ‘일 잘하는 개발자가 되기’ 라는 주제로 발표를 진행했다.
- 1월부터 12월까지 총 TIL 을 100건을 작성했고 20건을 밋업시간에 공유했다.
채용 및 온보딩에 기여했다
- 5월에 입사한 아무개님의 온보딩 파트너로 온보딩에 도움을 주었다.
- 1월부터 12월까지 총 200건의 채용 서류 검토 작업 및 50건의 인터뷰에 참여했다.
- 인터뷰 프로세스 수립 및 평가 기준을 만드는데 기여했다.
좋은 업무 문화를 만드는데 기여했다
- 4월 팀 회식 때 팀원들이 함께 같이 할 게임(구스구스덕)에 대한 아이디어를 내고 진행을 이끌었다.
- 팀 내 마니또 프로그램 아이디어를 내고 주도함으로써 팀원들간에 친해지는 시간을 만들었다.
- 매주 헬스체크&밋업 시트를 팀 내 공유하고 실행했던 액션아이템을 정리했다.
- 밋업 개선 위원회에 참여하여 밋업 프로세스 개선하는데 기여했다.
리더십
다른 개발자들의 성장과 동기부여에 기여했다
- 1월부터 6월까지 매달 1on1을 6명의 구성원들에게 진행했다.(총 36회)
- 아무개님의 멘토를 맡아서 1월부터 6월까지 12회의 멘토링 시간을 가졌다.
- 1월부터 6월까지 도메인 시니어들을 대상으로 총 24회의 리더십 트레이닝을 진행했다.
기술에 대한 가이드를 만드는데 기여했다
- 정기 컨벤션 논의 미팅에서 5건의 아이디어를 제시했고 3건의 아이디어가 정식 컨벤션으로 채택되었다.
- 정기 컨벤션 논의 미팅 내용에서 결정된 컨벤션 내용을 공식 문서화 하여 반영했다.
- REST API 설계 가이드를 작성하고 개발팀 전체에 공유하였다.
- ERD 작성 가이드를 만들고 공유하여 구성원들이 ERD를 작성할 떄 참고할 수 있도록 제공했다.
여기에서 중요한 부분 중 하나는 팀 내에서 맡겨진 업무를 진행하면서 이루어진 부분들은 프로젝트 성과로 다뤄지고 자발적인 선택에 의해서 이루어진 것들이 그 외의 성과로 다뤄져야 한다고 생각한다.
예를 들면 내가 팀 내에서 간편결제 기능을 만들기로 했고 그 과정에서 결제 기능 관련된 부분을 리팩토링을 하고 간편결제 기능에 대한 테스트 코드를 붙였다면 그건 과제를 진행하면서 요구되는 최소한의 품질 수준을 달성하기 위한 업무의 과정이지 엔지니어링 성과라고 보기 어렵다. 반면 내게 맡겨진 업무는 아니지만 우연히 어떤 버그를 발견하였고 버그 수정과 더불어 테스트 코드를 보완했다면 그건 엔지니어링 성과라고 볼 수 있다.
위의 예시들이 모두 동일한 임팩트를 가지고 있지는 않을 것이다. 마찬가지로 모든 개발자에게 동등한 조건을 요구할 수도 없다. 주니어 개발자들은 기술적 경험이 부족한만큼 컨벤션 논의나 성능 개선 등에는 기여하기 어려울 수 있지만 팀 내 화합을 위한 아이디어나 진행, 기술 문서 정리와 같은 것들은 기여할 수 있다. 시니어들 역시 그런 부분에 기여할 수 있겠지만 그것만 가지고는 부족할 것이다. 기술 공유나 멘토링, 가이드와 같은 좀 더 임팩트가 큰 성과들을 만들어내야할 것이다.
다시 일 잘하는 개발자로 돌아가보자. 내가 얘기하고 싶은 것은 ‘뛰어난 커뮤니케이션 능력, 문제 해결 능력을 갖춰야 한다.’ 이런 것이 아니다. 결국 내가 어떤 것을 해냈고 어떤 기여를 했는가이다. 아무리 내가 어떤 능력이 뛰어나다고 해도 그 능력이 발휘되어 어떤 결과로 이어지지 않으면 그건 그 능력이 없는 것과 동일하다.
내가 일하고 싶은 개발자, 그리고 일 잘하는 개발자들은 단순히 맡겨진 기능을 빨리 개발하는 개발자가 아니었다. 개인의 입장이 아니라 팀과 조직의 입장에서 자발적으로 다양한 부분에 주도적으로 기여하는 사람들이었다. 여러분이 조직에서 기여한 것들을 위의 항목들의 예시와 비교해가며 생각해보자. 나는 얼마나 다양한 것들에 기여하고 있는가? 프로젝트 성과 하나만을 바라보고 있진 않은가? 반대로 내 주변에 함께 일하고 싶은 개발자, 일 잘하는 개발자들은 어떤 것들을 해왔는지 생각해보자.