회사에서 요즘 이런 질문을 자주 받습니다.
"그래서 이렇게 하면, 10명이서 하던 일을 7명이서 할 수 있는거야?"

요즘 스마트폰에 역량을 집중하기 위해, 다른 부분의 생산성을 올려 여유 인력을 신제품으로 돌리려는 듯 합니다.
앞의 질문으로 대표되는 S/W 프로젝트의 생산성 향상을 위해
여러 아이디어를 찾아내려 하기도 하고, 중규모 이상의 소스 리팩토링을 하기도 하고,
이런 저런 행동들을 하고 있습니다만, S/W의 복잡성 때문에 오는 생산성 하락을 한방에 잡아줄
영웅적인 방법은 찾기 힘들어 보입니다.

여러가지를 시도해 볼 수 있습니다.
1. 소스코드를 일정한 룰에 맞게 정리하고, 디자인 패턴을 적용하는 등 리팩토링을 수행하여
    초기 소스 분석시간을 줄이고 소스 수정시 Side Effect를 줄일 수 있을 것입니다.

2. 귀찮지만 확실하다고 알려져 방법으로 '정형화된 코드 Inspection' 같은 것들을
    결함이 많이 나오는 파일이나 모듈을 대상으로 실시해서 아예 싹을 잘라 버릴수도 있지요.
     '정형화된 코드 Inspection'은(Code Review나 Code 검토와는 약간 다릅니다.)
    말하자면 일종의 결함 탐색계의 사기캐릭터 정도되는 것 같습니다.
    무작위 테스트나 단위테스트도 기껏해야 30%대의 결함 발견 비율을 나타내는데 반해
    이놈은 제대로만 하면 90%가까이, 대충해도 60%가 넘는 코드상의 결함을 뽑아낸다고 알려져 있습니다.
    대단하지요. 게다가 코드를 바로 보고 찾아내는 것이니, 지루한 디버깅 시간을 들이지 않아도 된다는,
    엄청 좋은 장점이 있습니다.

요즘 많이들 사용되는 'Agile 방법론'으로 통용되는 많은 기법들을 시도해 볼 수도 있습니다.
3. Scrum을 적용해서 일일 스크럼 회의나 스프린트 단위의 프로젝트 진행할 수 있겠지요. ¹⁾
   특별히 구현상의 방법이라기 보다는 프로젝트 팀의 운용에 관한 내용입니다.
   간단하고 적용하기 쉬운데다, 효과가 있다고 알려지면서 최근에 많이들 시도하는 추세입니다.

4. 정보 방열기 설치.
   정보 방열기라는 것은 사람이 많이 자나다닌 곳에 커다란 화이트 보드를 걸어놓고
   프로젝트 진행상황이나 기타의 정보를 적어두는 것을 말하는 데요, 이것을 통해서 의사소통에 들어가는
   비용을 획기적으로 줄일 수 있습니다.

5. 테스트 주도 개발(TDD)
   이른바 xUnit으로 대표되는 Test Framework를 만들고, 코드/함수에 대한 테스트 함수들을 구현해
  자동으로 테스트를 수행하도록 하는 것입니다.
  요즘 왠만한 Java 프로젝트는 모두 이 TDD를 사용하더군요.
  저도 C언어를 사용하긴 하지만 cUnit을 embeded에 부분적으로 포팅하여
  적용해 보고 있는데 기능 구현에 상당히 편리하더군요. 하지만, embeded의 한계와
  전체적으로 적용되지 않으면 큰 효과가 없다는 점(저 혼자 해서 뭐하겠습니까 ㅎㅎ),
  그리고 처음부터 TDD를 목적으로 설계가 되지 않은 프로젝트에 TDD를 적용하려면
  할 일이 엄청나게 많아진다는 점 등이 참 아쉽긴 하더군요.

6. Extreme Programming(XP) 상의 여러 기법들
   짝 프로그래밍, 스토리 카드, TDD+Refactoring, 사용자의 개발기간 중 참여, 등등등..
   잘 알려져 있는 여러 방법들이 있습니다.
  XP가 Agile의 거의 시초쯤 되는 것인 만큼 많이 알려져 있지요.


그런다고 생산성이 올라갈까?

제가 하려고 하는 말은 이런 많은 방법들로 생산성이 올라가지 않을 수 있다는 것입니다.
이것이 작은 부분들에 대한 답은 될 수 있지만 S/W 생산성을 가로막고 있는 본질인
S/W의 '복잡성'이라는 늑대인간을 한방에 물리칠 수 있는 '은탄환'이 될수는 없는 겁니다. ²⁾

저희 회사에서도 위에 적어둔 방법들을 포함하여 많은 아이디어들이 나왔습니다.
업무 배분 방법 등의 고전적인 방법들도 있었고,
현재 업무의 비효율적인 부분들을 찾아내어 이렇게 고치자는 구체적인 것들도 있었습니다.
그런것들 중 어느 하나라도 생산성을 확 올려줄 수 있는 방법들이 있을까요?
없을 것입니다. 네, 없습니다. 그런 게 있었으면 벌써 나왔겠지요.
S/W의 생산성은 잡초 같은 것이어서 하나하나 비효율을 발견하고 하나씩 고쳐나가고
개선해 나가면  3% 향상, 5% 개선 들이 모두 모여서 30% 정도의 개선을 나타낼 수
있을 것입니다.
(위에 제시한 것중 하나인 '어느' 방법론에서는 300% 생산성 향상된다는 믿지못할 말도 있더군요.
 그런게 세상에 어디있습니까? ㅎㅎ)
그러지만 단 한가지 적용으로 S/W 생산성을 몇 십% 올릴 수 있는 방법은 없습니다.

S/W의 본질은 복잡성이고, 그것은 어떤 방법으로도 없앨 수 없기 때문입니다.
자동차와 비교해 보겠습니다. 자동차에도 10만개가 넘는 부품이 들어가지요.
비슷한 함수/모듈 수가 들어간 S/W는 어떨까요.
자동차는 10만개가 넘는 부품이 있겠지만, 그중에 많은 것들은 같은(또는 비슷한)
부품일 것입니다. 볼트, 너트, 와셔...
하지만 S/W는 어떨까요? 모두 다른 기능과 역할을 하는 다른 부품입니다.
같은 것들이 있다면 잘못된 설계이고, 그 중복은 사라져야 할 것이지요.
그 상황에서 나오는 복잡성은 계산하기 힘든것이며 그것이 S/W입니다.

단지 우리가 할수 있는 것은, 저 앞의 방법들을 통해서,
또 각 프로젝트의 비효율적인 부분을 하나하나 찾아 없앰으로써,
팀내의 개발자 간의 커뮤니케이션에 들어가는 비용을 획기적으로 줄임으로써,
생산성을 조금씩 조금씩 모아서 올리는 방법이 최선인 것입니다.


제가 보기에 가장 좋은 방법은

생산성 향상에 골몰하고 있는 S/W팀에 가장 좋은 방법은요.
물론 앞의 방법들도 모두 훌륭하고 비효율을 개선시킬 수 있겠지만,
정말로 10명이 하던 일을 7명이 할 수 있도록 할 수 있는 방법을 찾는다면
저는 '사람에게 투자하라'고 이야기 할 것입니다.

10명이서 할 것을 5명이서 할 수 있을까요? 네, 할 수 있습니다.
뛰어난 개발자를 모은다면 말이죠.
다시 말해보겠습니다.
'보통 개발자 10명이서 할 일을 뛰어난 개발자 5명이 할 수 있습니다.'

이에 대해서는 이미 30년이 넘는 시간동안 많은 연구결과가 있었고,
여러 도서에서 인용되고 있습니다.
한결같이 가장 잘하는 프로그래머는 그렇지 않은 사람보다 20배 정도 생산성이 높다고 말하고 있습니다.
또한 생산성이 높은 개발자들은 몰려다니는 성격이 있답니다.
잘하는 팀에는 잘하는 개발자가 모여 있을 가능성이 많다는 것이죠.
그래서 그런지, 잘하는 그룹과 못하는 그룹 역시 생산성이 최대 10배까지 차이가 났습니다.
심지어 같은 회사 내에서도 잘하는 그룹과 못하는 그룹은 5배까지 차이가 난다고 합니다.

이 말인즉슨, 같은 품질수준의 S/W를 만들어내는데
우리 회사에서 가장 잘하는 팀은 가장 그렇지 않은 팀에 비해,
같은 인원의 5분의 1의 기간만 들일 수 있다거나,
같은 기간의 5분의 1의 인원만 있으면 할 수 있다는 말이거나,
또는 반반일 수도 있다는 말입니다.

여기에 생산성을 높일 수 있는 가장 큰 비밀이 있다고 생각합니다.
바로 '사람에 대한 욕심'입니다.
10배나 일을 잘하는 사람에게 2배 더 주는 연봉은 비싼 것이 아닙니다.
돈으로 모셔올 수 없다면 그에 상응하는 처우나 장비(의외로 잘 통합니다) 제공을
약속함으로써 실력있는 사람들을 모아 정예부대를 만든다면,
그 팀의 생산성은 올라갈 것입니다.

또한 이런 '잘하는 팀'에는 여러 비밀들이 숨어있어서,
서로간의 의사소통을 최대한 자유롭게 하고,
서로서로 도와주고 교육하기를 꺼리지 않아,
머지않아 모두의 실력이 상향평준화 됩니다.

프로젝트도, 특히 Software 프로젝트는 결국 사람이 하는 것입니다.
가장 믿을만하고 가장 잘하는 사람들만을 모아 둔다면
그 팀은 자연히 높은 생산성을 낼 것입니다.

반대로, 아무리 좋은 시스템을 구축하고 잘 구조화된 소스를 가졌다고 하더라도,
개발자 개인들의 개발능력이 그저 그렇다면
결국 그 팀의 생산성 향상은 조금 빛을 발하는 듯 하다가
(소스는 다시 스파게티 처럼 엉키고, 중복코드가 발생하고, 방법론은 무력화되어)
곧 벽에 부딪혀 버리고 말 것입니다.


반대 의견이 있을 수 있습니다.

생산성을 크게 올려주는 예는 실제로 있어보이기도 합니다.
3세대에서 4세대로(또는 5세대) 프로그래밍 언어를 변경한다든지, OOP를 적용한다든지 하면
분명히 같은 품질의 프로그램을 위해 훨씬 적은 노력이 들어갑니다.
^^ 이러한 개선 점은 (언어를 바꿀수는 없으니까요) 우선 제외하고 이야기 한 것입니다.


1) 스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론, 켄 슈와버, 마이크 비들
2) "No Silver Bullet", 프레더릭 브룩스