당신의 개발자들은 결코 느리지 않다

몇 달 전 투자도 많이 받고 주목도 받고 있는 한 스타트업 대표로부터 질문을 받은 적이 있다. 개발 일정이 의도한대로 끝나지 못한 책임을 누가 가져가야 하느냐에 대한 질문이었다. 나는 주저 없이 그것은 일정을 제대로 계획하지 못한 프로젝트 매니저와 회사의 책임이 가장 크다고 말했다.

하지만 그 대답을 들은 대표는 별로 탐탁지 않아했다. 그의 생각은 어느 그룹이든 열심히 하는 개발자들도 있는 반면에 요령을 피우는 개발자도 있지 않냐는 것이다. 그런 개발자들의 잘못도 매니저가 가져간다는 것은 부당하다는 것이었다.

이런 생각이 이 회사의 대표만의 생각은 아닐 것이다. 대부분의 비즈니스 사람들은 개발자들이 태만하거나 능력이 월등하지 못할 경우에 일정에 차질이 생길 수 있다고 오해를 하는 경우가 많다. 결국 이런 오해로 서로에 대한 신뢰관계를 무너뜨리고 같은 목표와 비전을 가지고 일하는데 있어서 큰 장애가 되고 만다.

개발자들은 느리지 않았다.

실제 프로젝트의 통계를 살펴보면 대부분의 개발 프로젝트는 개발자들의 능력보다도 어떤 의사결정이 늦어지거나 테스트 프로세스가 미흡할 경우의 이유로 늦어지는 경우가 더 많다. 이것을 뒷받침 해주는 데이터가 Sprintly라는 회사에 의해서 발표되었다.

Sprintly는 애자일 기반의 프로젝트 관리 툴을 제공하는 회사로 클라우드 환경에서 많은 개발 팀들이 그 툴을 이용하고 있다. 때문에 그들의 툴을 사용하고 있는 개발팀들의 데이터들을 통해서 특정 패턴들을 발견할 수 있었다.

먼저 개발자들이 티켓을 처리하는 속도가 결코 느리지 않았다는 것이다. 그들은 굉장히 다양한 회사들의 개발 프로젝트들을 조사하였다. 그들은 약 75%의 티켓 즉, 업무 리스트들이 평균 175시간에 해결되는 것을 추출해낼 수 있었다. 즉, 전체 프로젝트가 완료되는 시간에 비추어 굉장히 짧은 시간이었다.

두 번째로는 실제로 티켓의 개발이 시작 되기 전에 티켓이 수정되거나 우선순위를 조정하기 위해서 굉장히 많은 시간을 보내는 경우가 많았다. 이것을 칸반 이라는 애자일 방법론에서는 리액션 타임이라고 부르는데 주로 티켓을 만들고 우선순위를 정하기 위해서 걸리는 시간을 이야기 한다.

마지막으로 그들의 데이터를 통해서 실제 각각의 업무가 “완료” 단계의 상태에서 “배포준비”로 가는데 까지 시간이 꽤 오래 걸린다는 것을 볼 수 있었다. 이 데이터가 의미하는 것은 실제로 개발된 스펙이 원하던 것인지 검토하고 다시 수정하는 시간이 오래 걸린다는 것이다.

그렇다면 왜 실제 개발 프로젝트가 지연되고 느려지는 것일까? 

업무의 잦은 스위칭

먼저 개발자들을 느리게 하는 것은 한꺼번에 다양한 일을 처리해야 하는 경우이다. 즉, 처리해야 할 우선순위가 바뀌거나 먼저 처리해야 될 우선순위의 업무가 생겼을 경우이다. 개발자가 아니고서는 이해하지 못하는 사실이 있다.

만약 A라는 업무를 50% 정도 완료한 뒤에 B라는 업무를 진행했다고 하자. B의 업무를 진행하고 A를 다시 진행한다며 그 업무는 과연 50%일까? 다른 업무에 머물러 있는 시간과 업무 성격에 따라서 적어도 70% 정도의 업무가 될 때가 많다.

다양한 실험을 하고 알고리즘을 개발하는 업무라면 더더욱 그 업무에만 집중하는 것이 효율이 좋다. 실제 리드 개발자들은 다양하게 업무들을 스위칭하며 일하는 경우가 많다. 코드리뷰를 수행하고 짝 프로그래핑 그리고 여러 미팅을 다니게 되는데 이런 개발자가 실제 핵심 모듈을 개발하는 역할까지 수행해야 한다면 그 생산성을 보장받기가 어렵다.

조엘 스폴스키 또한 이것에 대한 자신의 의견을 피력한 적이 있다.

“개발자들에게 한번에 하나 이상의 업무를 할당해서는 안 된다. 좋은 매니저라면 개발자들을 한가지 업무에 집중해서 좋은 생산성을 보장해줄 필요가 있고 그 외의 여러 장애물도 같이 제거해 주어야 한다. 어떤 급하게 처리해야 할 업무가 있다면 스스로 처리할 수 있는 문제인지를 한번 생각해봐야 한다.”

불분명한 요구사항

실제 요구사항들은 지나치다 싶을 정도로 자세하게 작성 되어야 한다. 만약 개발자들이 그 요구사항을 이해하고 있지 않다면 어떻게 개발이 가능할 것인가? 실제 많은 프로젝트들을 보더라도 개발을 시작할 때 보다 자세한 스펙들을 작성하는 경우가 상당하다.

그리고 더 중요한 것은 제품에 대한 책임 결정권자가 그 기능에 대해서 정말 심각하게 고려하지 않은 경우가 많다. 그럴 경우에 개발자들은 왜 이 기능이 사용자에게 필요한지에 대한 이해가 없이 시작한 개발은 결코 창조적인 아이디어가 나올 수 없을뿐더러 그들 스스로도 개발자인지 아님 코더인지에 대한 정체성에 혼란이 오기 마련이다.

요구사항에서는 적어도 기능에 대해서 어떤 기능을 누가 왜 필요한지에 대한 이야기를 풀어내야 하고 더불어 다양한 상황에 대한 테스트 케이스들을 작성해주어야 하는 것이 가장 기본적인 스펙이 된다.

여기서, 요구사항이 터무니 없이 추상적이라면 그것은 더 세부적으로 나눠서 작성해야 한다는 뜻이 된다.

요구사항들의 변경

마지막으로 개발자들에게 있어서 가장 큰 불만 중 하나는 실제 업무가 시작된 뒤에 그것이 다시 바뀌는 경우이다. 개발자들이 변경하는 것 자체를 싫어하는 것은 아니다. 비즈니스 전략과 반응에 따라서 얼마든지 스펙은 변경될 수 있다. 하지만 그런 구체적인 사유와 데이터가 아닌 단지 시작 전에 정확하게 분석하지 못해서 오는 변경이라면 분명 시간적으로 낭비가 되는 것이다.

물론, 개발자들은 정신적인 데미지도 함께 느끼면서 내가 만드는 것이 없어지거나 바뀔 수 있다는 불안감 때문에 코드 퀄리티에도 영향을 주게 될지도 모른다.

실제 개발을 시작하기 전에 중간 레벨 정도의 목업 프로토타입만 먼저 구현하는 것도 한가지 대안이 될 수 있을 것이다. 포켓웍스(Pocketworks)의 토빈 해리스(Tobin Harris)는 다음과 같이 이야기 했다.

“어떤 프로젝트에서는 프로타입을 통해서 철저히 분석하는 것이 더 빠를 수 있다. 우리는 개발 전에 사용자와의 인터렉션과 흐름에 대해서 충분히 생각하지 못한다. 그래서 결국 구현 후에 다시 그것을 생각해보게 되고 다시 개발하게 되는 것이다.”

이런 잦은 변화가 수반될 수 있다는 점에서 애자일 방법론에서 이야기하는 짧은 주기를 통해서 만든 결과물을 리뷰하고 다시 일정을 조정한다는 것은 큰 의미가 있다.

매니저들은 개발자들이 성공적으로 그들의 개발 역량을 잘 발휘할 수 있는 환경을 제공해줄 책임을 가지고 있다. 먼저 개발자들에게 딜레이 된 개발일정을 불평하기 보다는 먼저 그들 스스로 자신이 제공한 일정과 환경에 대한 책임을 먼저 생각해 보면 어떨까?

성공적인 개발팀을 만들기 위해서는 명확한 비전이 공유되어야 하고 비즈니스 사람들과 같은 목표 아래 프로젝트가 진행되어야 할 것이다. 개발자들 또한 자신의 할 일을 줄이기 위해서 토론하고 일하기 보다는 그 목표를 같이 만들어가기 위한 적극적인 참여가 필요하다. 왜냐하면 우리는 코더가 아니라 창작물을 다루는 개발자들이기 때문이다.

글: 박경훈