Thoughts2019. 9. 26. 14:00

앞선 글에서 불확실성을 관리하는 것이 곧 커리어 관리가 될 수도 있음을 살펴봤다. 불확실성 관리가 없는 계획은 곧 신뢰할 수 없는 계획으로 바뀌게 마련이고, 신뢰할 수 없는 계획을 내놓고 납기일을 약속하는 개발자는 곧 관리자와 다른 팀의 신뢰를 잃게 된다. 

 

그렇다면 불확실성은 대체 어떻게 관리해야 하는가? 

 

불확실성을 관리하는 방법을 알기 위해서는 보통 불확실성이 어떤 형태로 드러나는지를 살펴봐야 한다. 형태가 없는 것을 관리할 수는 없는 노릇 아닌가. 그러나 불확실성의 형태를 살펴보기 전에 먼저, 한 가지만 살펴보고 넘어가자.

 

우리는 프로젝트의 불확실성을 적정 수준 이하로 관리하기 위해 애자일 방법론을 도입해 왔다. 애자일 방법론은 (특히 스크럼은) 2주 단위의 스프린트마다 새로운 목표를 세우고, 그 목표가 완수되는 정도를 측정함으로써 팀의 속도를 평가하고 그 결과를 다음 계획에 활용한다. 이처럼 프로젝트의 실행 과정을 더 이상 잘게 쪼갤 수 없을 때 까지 쪼개는 행위는, 2주라는 기간 안에 완료할 수 있다는 확신이 서는 (다시 말해 그 규모에 있어서 불확실성이 거의 존재하지 않는) 작업만을 스프린트의 실행 대상으로 삼는다는 것을 전제한다. 간단하게 들린다. 

 

그러나 '2주라는 기간 안에 완료할 수 있다는 확신이 서는 작업만을 스프린트에 포함시키는' 것 자체가 이미 만만한 작업은 아니라는 것을 우리는 깨달을 필요가 있다. 왜 그런가? 

 

여러분이 여러 팀으로 구성된 어떤 조직의 일원이라고 해 보자. 보통 이 조직은 어떤 공통의 목표를 달성하기 위해 함께 움직이지만, 각 팀은 그 팀이 관리하는 소프트웨어의 특성에 따라 상이한 개발 체계를 따르는 것이 일상적이다. 한 팀에서 당연한 일이 어떤 팀에게는 전혀 당연하지 않다. 이 간단한 한 문장은 굉장히 많은 것을 의미한다. 예를 하나 살펴보자. 많은 팀이 이용하는 플랫폼 소프트웨어를 관리하는 팀 A가 있다. 이 플랫폼 소프트웨어는 운 나쁘게도 다른 팀으로 하여금 특정 모듈을 스스로 업데이트하도록 강제한다. 그 문제 때문에 팀 A는 매주 한 번씩 소프트웨어를 릴리즈하며, 다른 팀으로부터 접수되는 코드 리뷰 요청을 전담하는 온콜(on-call)을 둔다. 이 담당자는 일주일에 딱 이틀간만 다른 팀으로부터 접수된 코드를 리뷰한다. 이런 개발 체계는 CI/CD를 당연시하는 팀 B에게는 재앙에 가깝다. 코드 리뷰 요청을 제때 넣지 않으면 일주일을 날린다. 리뷰된 코드가 제 때 머지되지 않으면 또 일주일이 날아간다. 팀 B의 개발자는 이 문제를 제대로 숙지하지 않은 탓에 2주, 그러니까 스프린트 1회 분량의 시간을 날리고 매니저로부터 문책을 당한 경험이 있다. 

 

이런 형태의 불확실성은 조직 형태와도 밀접한 관련이 있다. 어떤 조직이 크면 클수록, 각 팀의 규모가 작으면 작을수록 이런 문제는 도드라진다. 우리는 이것을 보통 커뮤니케이션 오버헤드(communication overhead)라는 말로 퉁치지만, 그 실체는 훨씬 복잡하다. 

 

 

 

Posted by 이병준

소중한 의견, 감사합니다. ^^