개발자는 같이 일해봐야 한다.
정말 괜찮은 개발자는 팀일 때 역량을 발휘한다.
개발자의 실력을 평가하는 여러 가지 잣대가 있고, 정성적인 평가와 정량적인 것들에 대해서 이야기들을 많이 하게 된다. 여기에, 필자가 개발자를 평가하는 몇 가지 기준과 상황적인 판단에 대해서 정리를 해보자.
자신이 속한 개발팀의 규모와 해야 할 일에 대해서 구체적으로 정리가 첫째 필요함.
1. 현재 개발팀의 단계가 어떤 단계인가? 초기 프로토타입을 빈번하게 하면서 빠르게 BM을 테스트하는 단계인가? 구체화된 프로토타입을 서비스 단계로 전환시키는 단계인가? 서비스를 효과적으로 성능을 개선하기 위한 단계인가? 데이터 기반의 부가적인 가치를 뽑는 단계인가?
각 단계마다 조직의 형태, 뽑아야 하는 사람의 수준, 투입되는 리소스와 자금의 규모, 팀의 성격과 색깔이 모두 다르게 됩니다. 이 정리가 잘 되어야 합니다.
안타깝게도 비개발자들은 이런 BM과 개발팀의 성격을 잘 정리하지 못합니다. 이 정리가 가장 중요합니다.
2. 개발팀의 단계가 정해졌다면, 어느 정도 개발팀의 개발 속도와 BM, 주변 팀들과의 조화와 성장에 대해서 고려를 해봐야 합니다. 아직 미숙한 기획팀과 잘 어울리는 개발자인지, 알아서 조금은 주도적으로 끌고 갈 개발 조직인지, 삽질하는 단계를 잘 커버해야 하는 팀인지, 지속적으로 실험하는 단계는 어느 정도인지에 대해서 개발팀 주변의 조직들을 같이 고민하면서 정리해야 합니다.
3. 비즈니스의 규모, 자금의 상태, 회사의 단계에 대해서 잘 구성해야 합니다. 그리고, 내 조직의 단계를 명확하게 정리해야죠.
최소한, 이 3가지의 기본적인 정리가 되어야 개발팀을 세팅할 JD를 구성하고, 인력을 구할 수 있습니다.
구인하고 뽑고, 같이 일하는 단계에서 다음과 같은 고민을 하는 경우가 있습니다. 그리고, 냉정해져야 하는 경우이죠.
첫째. 커뮤니케이션은 떨어지고, 코딩 스킬도 별로이지만, 빠르게 애플리케이션을 만들어 내고, 책임감도 있어서 서비스를 어떻게든 굴러가게 만드는 개발자.
둘째. 장기적인 관점에서 차근차근 서비스를 단계별로 구축할 줄 알면서, 서비스의 최소화 단계는 지키면서 개발하지만.. 시간 소요와 품질의 비례를 그대로 보여주는 개발자.
셋째. 그동안 팀 프로젝트를 제대로 못해서, 코드 리뷰의 스킬이 떨어지고, 만들어진 코드가 매번 변경되는 상태이지만, 당장의 이슈에 대해서는 괜찮은 개발 성능을 보여주는 개발자.
넷째. 의사소통은 어렵지만, 일단 이해가 가는 상태로 돌입하면, 꽤 몰입도를 보여주는 개발자. 다만, 그 몰입을 하면서 타 개발자와 의사소통이 역시 어려운 개발자.
자, 과연 어떤 개발자와 일하는 것이 좋을까요?
정답은 없습니다.
안타깝게도, 필요한 시기에 필요한 개발자, 필요한 능력을 소유한 개발자를 구인하고 같이 일하려면, 상당히 많은 리소스와 개발 문화, 이를 유지 관리할 개발 총괄 책임자까지 갖추어야 하는 것이 너무 많습니다.
스타트업은 이때에 포기할 것은 포기하고, 선택할 것은 선택해야 합니다. 그리고, 그 판단을 잘해야 합니다.
아직 BM이 확고하지 않고, 사용자 숫자도 그렇게 많지 않을 때에는 서비스를 다시 만들 것을 고려한 상태로 적절한 서비스를 빠르게 만들고 부수기를 반복하면 됩니다.
역시, 개발팀의 규모도 그렇게 크지 않을 것이고요.
위에서 설명한 개발자들을 잘 컨트롤하면서, 적절한 성능과 적절한 버그, 적절한 기능으로 서비스를 동작시키면 됩니다.
다만...
서비스가 안정화되고, BM이 구체화 되게 되면서 이에 대해서 '매우 잔인한 선택'을 해야 합니다.
서비스의 안정화와 레거시의 제거, 미래 지향적인 지속 가능한 서비스의 개발을 위해서는 다음과 같은 사람들은 단호하게 팀원에서 제거해야 합니다.
슬프지만, 해당 팀원이 초기부터 고생해왔던 사람이라고 해도 말이죠.
첫째. 서비스 안정화하는 공통화된 기법이 있음에도 불구하고, 자신만의 스타일을 고집하거나, 자신만의 코딩 방법만을 선택하는 사람.
둘째. 훨씬 좋은 안정화된 외부 서비스가 있음에도 불구하고, 자신이 해당 서비스를 만들겠다고 고집을 피우는 고집불통형.
셋째. 선배 개발자가 만들어 놓은 기존 소스코드의 규칙을 무시하고, 자신이 관리하기 편한 구조로만 개발해야겠다고 고집을 피우면서, 선배 개발자랑 계속 충돌하는 경우.
넷째. 회사의 규칙, 회사의 문화, 회사의 독특한 방식에 대해서 자신은 어울리지 않는다고 거부하고, 자신만의 스타일만 고집하는 경우.
다섯째. 자기 혼자 계발하는 것이 편하다고, 코드 리뷰를 하거나, 필요한 연계 방식에 대해서 문서화를 요구하면, 굳이 그런 것 필요 없이 자기 혼자 대응하려고만 하는 독불장군형 개발자.
여섯째. 자기 혼자 서비스 전체를 모두 할 수 있다고 하지만, 정작 아무것도 제대로 못하면서 소리만 요란한 빈수레형.
일곱째. 혼자서는 개발을 곧잘 하는 것처럼 보였지만, 둘셋이 비슷하게 개발하면서 독자 스타일만 고집하는 개발자.
물론, 이런 사람들을 면접이나 이력서로 구분할 수 있으면 좋겠지만, 그것은 사실상 불가능합니다.
같이 일해봐야 압니다.
그리고, 이렇게 나열되었지만, 자신의 역량으로 혼자 개발하는 초기 스타트업에서는 유력한 개발자 역할을 충실하게 하거나, 규모가 작은 상태에서는 일을 잘하는 개발자로서 경영진의 사랑을 받을 개발자가 될 수 있다는 것을 잊으면 안 됩니다.
실력이 좋고 나쁨을 떠나서...
자신이 있을 자리에 가장 최상의 대우를 받는 다면 아주 좋은 것이고...
자신이 있을 자리가 아니라면, 자신이 있을 자리를 찾아서 떠나는 것이 개발자의 롤이겠죠.
.
.
.
개발자는 같이 일해봐야 압니다.
그리고, 현대의 개발은 소수의 팀이 팀워크를 높여서 일하는 방식을 택합니다.
가능하다면, 개발자들 스스로 커뮤니케이션 스킬과, 고집보다는 넓은 생각으로 팀원들을 생각하고, 선배와 회사를 생각하는 마음을 가지는 것이 동료들에게 좋은 평가를 받을 수 있는 길이라고 생각합니다.
