by
Sep 04. 2021
개발 팀 성과 도식화
소프트웨어 개발 노트
스플렌더(Splendor)라는 보드 게임이 있다. 앱 버전도 있어서 인공 지능과 대전을 할 수 있다. 인공 지능에는 여러 가지 모드(Mode)가 있는데, 대충 다음과 같은 것 들이다.
Opportunistic (기회주의 모드): 장기 전략 없이 각 턴에서 가장 가성비 높은 행동을 한다.
Specialized (전문성 강화 모드): 전문성 점수를 높이는 장기 전략을 쓴다.
Balanced (균형 중시 모드): 위의 두 타입을 적당히 섞어서 플레이한다.
[그림 1] 스플레더 게임 모드이 게임의 인공 지능은 별로 강하지 않아서, 세 모드 중 무엇으로 하든 큰 어려움은 없지만, 대체적으로 가장 약한 것은 기회주의 모드다. 운 나쁘게 기회주의 모드에 계속 이득이 가는 패가 깔리지 않는 한, 사람이 약간의 장기 전략만 추구해도 이 모드의 인공 지능은 쉽게 이길 수 있다.
소프트웨어 개발팀의 성과(Performance)를 논하자는 글에서 갑자기 스플렌더 인공 지능 모드에 대해서 설명한 이유는 여기 나온 기회주의 모드가 실제 개발 팀이 일하는 모습과 많이 닮아 있기 때문이다. 거의 모든 소프트웨어 개발 팀은 기획자나 소비자의 요구에 맞춰서 소프트웨어를 만드는 과정에서 다음 두 가지 전략을 섞어서 취할 수밖에 없다.
Opportunistic (기회주의형): 요구 사항이 주어질 때마다 가장 빨리 결과를 내는 방식을 선택한다.
Organized (체계수립형): 장기적으로 개발 체계 정비를 염두에 두고, 요구 사항 처리 시간을 조절한다.
개발 체계는 다음과 같은 측면에서 제대로 된 시스템이나 컨벤션이 수립되어 있는 상태를 의미한다.
이슈 처리 프로세스
이슈 외 개발 문서 작성 방법
개발 환경 문서 작성 방법
코드 형상 관리
코드 리뷰
코드 설정
배포 프로세스
팀이 만드는 소프트웨어의 성격에 따라 필요한 수준은 달라질 수 있지만, 위에 언급된 것들 중에 완전히 무시해도 되는 것은 하나도 없다. 이러한 체계 수립 과정을 건너뛰고 속도를 우선해서 일하는 팀과 체계를 수립해 가면서 일하는 팀의 성과 차이는 어떻게 나타날까? 지금부터 일종의 사고실험(思考實驗)을 통해 두 팀의 성과 차이를 도식화(Illustrate) 해 보여주고자 한다.
개인 성과 도식화
두 팀에서 개인별 성과의 차이는 다음 [그림 2]와 같이 나타난다.
[그림 2] 개인 성과 그래프이 그림으로 표현하고자 한 두 팀의 차이는 다음과 같다:
기회주의형 팀원의 성과는 초기에는 높지만, 시간에 따라 코드 사이즈가 점점 커져가면 특정 시점부터 급격히 하락한다. 이 시점은 주로 개인별 업무 외에 팀원 간 협업이 중요해지는 시점이다.
체계수립형 팀원의 성과는 초기나 나중이나 일정하다.
기회주의형 팀원의 성과는 체계형에 비해 들쭉 날쭉하게 나타난다.
팀 성과 도식화
팀 전체의 성과는 다음 [그림 3]과 같이 나타난다.
[그림 3] 팀 성과 그래프시간이 흐르면 코드 사이즈와 팀 사이즈가 커진다고 가정했다. 또한, 시간이 흐르면서 팀에 유입되는 인원과 팀에서 나가는 인원이 있다고 가정했는데, 그림 아래쪽에 -2, +4 는 2명 나가고 4명 들어온 것을 의미한다. 이 그림에서 표현하고자 한 두 팀의 차이는 다음과 같다:
기회주의형 팀이 체계수립형 팀을 압도하는 것은 초반 잠시다.
기회주희형 팀의 성과 저하는 각 개인의 성과 저하가 주원인이다. 즉 체계수립형 팀에서만 팀 인원 증가가 팀 성과로 이어진다.
기회주의형 팀은 팀원 변동 시 성과 감소 폭이 크며, 그것을 회복하는데 드는 시간도 길다. 전체 성과는 이 그래프를 적분(Integral) 한 것임을 생각하면, 이 차이는 매우 큰 것이다.
기회주의형 팀에서 체계수립형 팀으로 변화
불행히도, 많은 소프트웨어 개발 팀이 처음부터 체계수립형으로 팀을 구축하지 못한다. 팀이 수립되고 처음 몇 달안에 나온 성과가 그 팀의 존속을 결정짓는 경우도 많다. 이런 경우 처음에는 기회주의형으로 작업을 진행할 수밖에 없는데, 그러면 남겨지는 과제는 기존에 기회주의형으로 구축된 팀을 체계수립형으로 변화시키는 것이다.
[그림 4]는 앞서 [그림 3]을 단순화 한 다음, 처음에는 기회주의형 팀으로 시작하여 일정 시간 후에 체계수립형 팀으로 변화하는 하이브리드형 팀의 성과를 덧붙어서 그린 것이다. 이렇게 변화할 수만 있다면 아주 이상적일 것이다.
[그림 4] 이상적인 변화 케이스당연히 이런 변화는 현실에서 불가능하다. 변화 과정에서 팀 성과의 일시적 감소는 불가피하다. 그러나 언제 어느 정도로 감소시킬 것인지는 조절이 가능하다. 다른 작업 없이 온전히 팀 체계 수립에 올인할 수 있는 환경이라면 급진적 변화를 추진해 볼 수 있다. 그런 식의 변화는 다음 [그림 5]와 같이 표현될 수 있다.
[그림 5] 급진적 변화 케이스변화에 올인할 수 없고, 변화 과정에서도 일정한 성과를 내야 한다면, 점진적 변화 방식으로 가야 한다. 앞서 언급한 '개발 체계'의 여러 가지 구성 요소들 중 가장 중요하다고 생각되는 것부터 하나씩 고쳐가면서 장기적으로 모든 체계를 구축해야 한다. 이런 식의 변화는 다음 [그림 6]과 같이 표현할 수 있다.
[그림 6] 점진적 변화 케이스