많은 조직에서는 좋은 개발팀을 갖고 싶어 한다.
좋은 개발팀이라는 것은 개발자들의 생산성이 높고 리텐션이 유지되며 팀 자체가 성장하고 있어 조직의 문제 해결 능력에 지속적으로 큰 기여를 할 수 있는 팀을 말한다. 이런 팀은 외부로부터의 인재 유입도 비교적 수월하며 새로운 아이디어와 혁신에도 비교적 열려있다.
좋은 개발팀을 갖고 싶은 조직은 좋은 개발 문화를 통해 현재의 팀을 좋은 개발팀으로 만들고 유지하길 원한다. Stackoverflow의 서베이나 개발자들을 대상으로 한 여러 조사에서도 나타나듯 개발팀의 문화는 개발자들이 해당 조직에 머무는 이유 중 큰 비중을 차지한다.
좋은 개발 문화란 무엇일까?
모든 조직에 들어맞는 법칙은 없겠지만 일반적으로는 다음과 같은 것들이 물망에 오른다.
1. 서로에 대한 신뢰
2. 지속적인 학습
3. 실수에 관대하고 실수를 통한 성장을 할 수 있는 환경
4. 자기 주도적인 업무
자 좋다. 이제 매니저의 관점에서 위 4가지를 만들기 위해 노력해 보자.
'서로에 대한 신뢰? 이건 시간이 해결해 줄 일이니까 패스.'
'지속적인 학습? 다음 주까지 팀원들에게 '모던 자바스크립트 Deep Dive'를 읽어오라고 해야겠다.'
'실수에 관대하고 실수를 통한 성장을 할 수 있는 환경? 이제 버그 낸 사람한테 조금 덜 뭐라고 해야겠다.'
'자기 주도적인 업무? 이건 당연히 알아서 잘해야지.'
웃자고 적어놓은 내용이지만 실제로 위 항목들을 보고 실제로 비슷하게 생각하는 사람이 있을까 두렵다.
위 항목들은 누군가 시켜서 되는 일이 아니다.
각 팀원이 본인의 업무에 대해 책임감 있는 모습을 보인다면 상호 간의 신뢰가 쌓일 것이고 성장하고자 하는 욕구가 있다면 지속적인 학습을 위해 자발적으로 스터디 그룹 등을 만들 것이며 실수에 관대하고 실수를 통한 성장을 할 수 있는 환경은 코드 리뷰, 테스트 코드, 건강한 장애 부검과 같은 건설적인 프로세스를 통해 갖춰지는 것이며 자기 주도적인 업무 역시 본인의 성장 욕구와 인정 욕구, 산출물에 대한 자부심 등을 바탕으로 스스로 해 나가는 것이다.
조직/매니징의 관점에서는 이러한 문화를 조성하기 위해 어떤 일을 할 수 있을까?
가장 중요하고 또 중요한 첫 번째는 바로 '채용'이다. 실력 있고 책임감 있으며 성장 욕구가 있는 개발자를 채용하는 것이 좋은 개발 문화를 만드는 데 기여하는 비중은 90%가 넘는다고 생각한다. 그다음으로 해볼 수 있는 것들은 앞서 말한 프로세스의 도입, 그리고 그러한 프로세스를 도입하는데 필요한 지원일 것이다. 스터디 그룹을 만든다고 하면 리소스에 대한 지원 등을 해주고 업무에 대한 새로운 툴 도입이나 변화에 대한 시도를 응원해 주는 것이다.
'공부는 좋습니다. 그런데 업무 시간에는 좀... 형평성이...' 굳이 이런 이야기를 하며 기껏 잘 채용한 개발자들의 의욕을 꺾는 조직을 실제로 본 기억이 있다. 현명한 선택이 아니라고 생각한다.
물론 조직 내에서 개인으로서 비관적인 이야기와 부정적인 이야기들로 동료 개발자들의 의욕과 사기를 꺾는 사람들도 있다. 또한 발전 의지가 없고 실력이 낮아 동료 개발자들에게 부정적인 영향을 미치는 사람들도 있다. 이러한 사람들은 조직의 관점에서는 빠르게 털고 갈 수 있다면 털고 가는 게 좋다.
말은 쉽다. 현실은 뛰어난 개발자 한 둘, 비관적인 개발자 한 둘, 애매한 개발자 한 둘이 모여 개발팀이 만들어진다. 그리고 지금 저 사람을 내보내면 대체할 인력도 없다. 자, 이런 상황에서 당신이 매니저라면 어떤 것을 해볼 수 있을까?
첫 번째. 이러니 저러니 해도 인사가 만사다. 좋은 사람을 채용하기 위해 꾸준히 노력하고 발품을 팔아야 한다. 100점짜리 개발자를 데려올 생각은 하지 말자. 뚜렷한 장점이 있고 현재의 개발팀에 좋은 자극을 줄 수 있는 포인트가 있다면 적극적으로 고려해 보자.
두 번째. 조직 내에서의 건설적인 프로세스를 구축하기 위해 노력해야 한다. 코드 리뷰, 테스트 코드, 회고 문화, 장애 부검 등 소위 좋은 개발 문화를 만드는 데 도움이 된다고 알려진 것들은 시중에 널리고 널렸다. 현실적으로 조직에 도입할 수 있고 필요하다고 생각되는 것부터 하나씩 차근차근 도입해 보자. 이 과정에서의 반발이 있다면 최대한 점진적으로 도입해 보고 설득력이 부족하다면 본인의 신뢰자산을 레버리지로 사용하자. 끌어다 쓸 신뢰자산이 없다면 전적으로 본인의 책임이다.
세 번째. 비관적인 태도를 가진 팀원과 적극적으로 소통하자. 고민이 있다면 들어주고 개선이 필요하다고 생각하는 부분에 대해 그렇게 생각한 이유와 함께 솔직하게 피드백을 해야 한다.
네 번째. 본인이 목표로 하는 개발팀의 비전과 이상향에 대해서 끊임없이 구성원들에게 이야기해야 한다. 뛰어난 개발자들은 공감할 것이고 애매한 개발자들은 다소 귀찮아 할 수 있지만 그래도 맞는 방향이라고 생각할 것이다. 비관적인 개발자들은 투덜대다 조직을 떠나거나 적극적으로 합류(전향?)할 것이다.
개발자들이 행복하다고 좋은 개발팀은 아니지만 좋은 개발 문화를 구축하면 그 결과로 개발자들은 더 행복해져야 한다. 그것이 인류 보편적인 가치에 부합해서가 아니라 좋은 개발 문화로 개개인이 행복한 상태가 되어야 그것이 지속 가능하기 때문이다.
이런저런 사족이 길었지만 결국 돌고 돌아 제일 중요한 건 사람이다. 물질의 기본 단위가 원자이듯 조직은 그 조직을 구성하는 사람들의 구성에 따라 성질이 완전히 달라진다. 나는 '사람은 바꿀 수 없지만 스스로 바뀔 순 있다.'라고 생각한다. 사람을 바꾸려고 노력하기보다는 바뀔 수 있는 환경과 분위기를 제안하고 구축하는데 집중하는 것이 조직 관점에서도 개개인의 관점에서도 경제적인 선택일 것이다.