당연한 이야기
맞다. 당연한 소리다.
하지만 가끔 우리는 당연한 것을 본질을 잊고 지낼 때가 많다.
다른 무수한 장점이 있다고 해도 개발자가 개발을 잘 못한다면, 개발 생산성이 떨어진다면 개발자로서 인정받을 수 없다.
스포츠 선수들을 보면 여러 유형의 선수가 있다.
야구를 예로 들면
1. 무뚝뚝하지만 타자로서 타율, OPS(출루율+장타율) 등 주요 지표가 최상위인 선수.
2. 타율 평균. 후배들을 잘 챙기는 리더십이 좋은 선수.
3. 타율 평균에 팀내 분위기 메이커인 선수.
등 선수가 있다. 어떤 선수가 팬, 감독, 다른 선수들한테 가장 인정받을 것인가?
당연히 1번이다.
자 여기 아래처럼 개발자가 있다. 개발 생산성 평균을 3이라고 하자.
1. 성격이 엄청 좋아 주변을 잘 챙기는 개발자. 개발 생산성 2.
2. 다양한 아이디어를 내는 개발자. 개발 생산성 3.
3. 무뚝뚝한 개발자. 개발 생산성 5.
4. 공유와 문서화에 진심인 개발자. 개발 생산성 3.
꼭 한 명의 개발자를 뽑아야 한다면 누구를 뽑을 것인가?
당연히 3번이다.
축구 선수면 축구를, 야구 선수면 야구를, 개발자면 개발을 잘 해야 한다. 다른 것을 아무리 잘 해도 인정받을 수 없다. 개발자가 개발을 잘 못하는데 다른 것을 잘 하면 도리어 폄훼될 수도 있다. '아 저 사람은 개발을 잘 못하니 다른 것으로 인정받으려고 하나봐'라고. 실제 그런 사람들에 대한 이야기를 듣거나 봐왔으니까. "그 이사님, 실무 능력은 하나도 없는데, 사장님을 진짜 잘 챙기더라. 그러니까 능력도 없는데 저 자리까지 올라갔지. 물론 그것도 능력이지만" 따위의 이야기들. 축구 선수가 축구를 잘하면서 리더십 있으면 더 인정받을 수 있다. 야구 선수도 마찬가지다. 개발자도 마찬가지다. 개발을 잘 할 때 다른 능력들이 빛을 발하며 더 인정받을 수 있게 된다.
아직 실력이 부족하다면 어떻게 해야 할까?
개발 생산성이 팀 내 평균 이하라면 다른 것에는 최대한 신경을 끄는 게 좋다. 주변 사람 챙기는 것, 아이디어를 내는 것, 사내 사람들 만나는 것 등등 최대한 관심을 끄고 개발에 집중하는 게 좋다. 최소한 평균 정도 생산성에 도달할 때까지는. 아이디어가 생각나도 자제하고 묵묵히 개발을 하는 것이 좋다. 자기 몫을 못하는 상황에서 주변 사람을 챙긴다고 해도 인정받지 못한다. 도리어 평가만 안 좋아진다. '저 사람은 자기 일도 못하면서 남의 일까지 관심 갖더라'라는 평가를 받을 수도 있다. 뜬금 없는 타 팀의 요청에는 정중히 거절하고 본인 업무에 집중하는 게 최선이다. 그런 업무는 도와줘도 인정받지 못하기 때문이다.
개발자 유형
예전에 개발자 유형을 아래 6가지로 나눴다.
- 탐정: 버그와 오류 원인을 잘 찾아내는 개발자
- 해적: 다른 기업의 기술 블로그만 보고도 그대로 구현해내는 개발자
- 천재: 알고리즘 개선 등을 통해서 10~20배가 아니라 최소 100배 이상의 개선을 이끌어내는 개발자
- 공장: 꾸준한 속도로 비슷한 것을 빨리 구현해 내는 개발자
- 위키 또는 스택오버플로우: 자신이 맞딱뜨린 문제와 해결책을 정리해서 공유하는 개발자
- 허브: 커뮤니케이션 의사소통 능력이 뛰어나 타팀과 협업할 때 시너지 효과를 내는 개발자
사실 여기서 공장은 거의 기본에 가깝다. 비슷한 것을 엄청 빠른 속도로 찍어낼 수 있을 정도로 숙련된 프레임워크가 반드시 하나 정도는 있어야 한다. 최소한 팀 내 평균 속도에 도달해야 한다. 그게 기본이다.