[소프트웨어 개발] Man-Month 허상과 히어로 개발자

늘상 그렇듯,

오늘도 일개 개발자로서 체감하는 개발현실을 얘기해볼까 합니다.

'일개 개발자'로서의 생각이기 때문에 코끼리의 꼬리만 만지고 있다고 생각하셔도 무방합니다.

Man-Month는 한 사람이 한 달간 하는 일의 규모를 토대로,

프로젝트에 투입할 인력과 일정을 계획할 때 사용합니다.

10명이 1년간 프로젝트를 진행해야하면,

10명 x 12개월 = 120 M/M(Man-Month)

120 M/M 규모의 프로젝트라고 말할 수 있습니다.

프로젝트에 투입한 사람을 좀 더 늘려볼까요?

120 M/M 프로젝트에 12명을 투입하면,

120 M/M / 12명 = 10개월

12개월에서 10개월로 2개월이 줄었습니다.

이 수식에는 한가지 전제가 필요합니다.

투입되는 인력의 수준이 동일하다는 전제이지요.

하지만, 소프트웨어 개발에 발담고 있는 동안,

여실히 깨달은 사실은 개발자 간에 수준이 천차만별이라는 것입니다.

초보개발자와 고급개발자 간의 차이가 20배가 넘는다는 글을 읽은 적도 있습니다.

입사 직후에 정말 아무 것도 몰랐던 저와

여전히 아무 것도 모르는 지금의 저만 비교해봐도

20배는 가뿐히 넘는 것처럼 느껴집니다.

소프트웨어 개발은 제조의 영역과 예술의 영역 사이 어디쯤 위치하기 때문에,

초보개발자와 고급개발자 간의 차이가,

제조업계의 비숙련공과 숙련공의 차이보다는 월등하게 크고,

연습생과 천재 아티스트 간의 차이보다는 좀 작을 거라 생각합니다.

게다가 때로는 대체불가능한 사람이 있습니다.

그런 히어로 개발자들은 개발자들 사이에서는 천재 아티스트와 맞먹는 파급력을 지닙니다.

초보개발자와 히어로 개발자의 간극은 거의 무한대에 가까울 거라 생각합니다.

왜냐하면, 히어로 개발자의 기발한 발상은,

히어로 개발자가 아니면 도출해낼 수 없는 직관의 비약에서 나오기 때문입니다.

제가 일하는 곳에서도,

히어로 개발자 다섯 분이 있습니다.

무려 다섯 분이나 있다는 사실 자체에 놀랍기도 하고 행복하기도 합니다.

약간의 사례를 소개해보겠습니다.

외부 개발자가 사용할 수 있게 API를 설계하는 시간이었습니다.

기존 담당자는 견고하게 구축되어있는 아키텍쳐를 언급하며,

현 아키텍쳐를 기준으로 다음 버전을 준비하고자 하였습니다.

지극히 논리적이고 합리적이었습니다.

히어로 개발자가 딴지를 걸기 전까진요.

히어로 개발자는 기존 담당자의 논리를,

실제로 API를 사용하는 개발자가 불편할 수 있다는 논리로 깨버렸습니다.

히어로 개발자가 원하는 '사용하기 편한' API를 준비하기 위해서는,

오랜 전통을 가지고 있는 아키텍쳐를 전부 바꿔야했습니다.

그렇기 때문에 담당자는 굉장히 강하게 거부의견을 펼쳤습니다.

그렇지만, 히어로 개발자는 그 어느때보다 단호한 고집으로 자신의 주장을 관철했습니다.

아키텍쳐보다 사용자 편의가 우선한다는 히어로 개발자의 의견에 전적으로 동의합니다.

아키텍쳐 따위야 언제든지 바꿀 준비가 되어있어야 합니다.

아키텍쳐가 중요하지 않다는 얘기는 아닙니다.

당연히 아키텍쳐는 소프트웨어 개발에 근간이 됩니다.

하지만, 아키텍쳐보다 중요한게 있습니다.

바로 실제로 소프트웨어를 사용할 사람들이지요. :)

물론 사용자 요구사항은 천차만별입니다.

경우에 따라서는 자신이 요구하는게 뭔지 모르는 경우도 있습니다.

따라서, 요구사항을 비판적으로 가려낼 수 있는 합리적인 절차가 필요합니다.

그 부분에 대한 논의는 다음으로 미뤄두겠습니다.

또 다른 예도 있습니다.

라이브러리 A에서 DB가 필요한 경우가 있었습니다.

라이브러리 A에서 DB 파일을 열고 read / write 해야만 할까요?

그렇게 되면 라이브러리를 사용하는 프로세스에서 DB에 직접 read / write 하게 될지도 모릅니다.

자칫하면 DB에 있는 table을 drop할 수도 있겠지요.

그걸 방지하기 위해 서버-클라이언트 구조를 차용하여,

클라이언트에서 서버에 DB 오퍼레이션을 요청하고,

서버에서는 인증된 오퍼레이션에 대한 동작을 처리하도록 구조를 잡지요.

하지만, 히어로 개발자는 라이브러리 A에서 직접 서버-클라이언트 구조를 만드는 것 대신,

컴포넌트 B에서 마침 사용 중인 서버-클라이언트 구조를 절묘하게 이용하는 것을 제안합니다.

컴포넌트 B의 역할상 라이브러리 A가 기생해도 아무 문제없는 구조였습니다.

히어로 개발자의 제안으로 플랫폼은 불필요한 프로세스를 만들지 않았습니다.

히어로 개발자들의 고집과 발상은 대체불가능합니다.

소프트웨어 개발업체에서 하는 가장 큰 착각은,

이런 히어로 개발자를 부속품 갈아끼우듯이 교체할 수 있다는 겁니다.

아직 제 경험이 미천하긴 하지만,

제 경험상 히어로 개발자는 교체할 수 없습니다.

히어로 개발자를 바꾸면 소프트웨어는 다른 모양으로 변하게 됩니다.

소프트웨어가 원래 가고자 했던 방향으로는 더 이상 갈 수 없습니다.

이 글의 시작은 Man-Month였는데요.

결론은 "히어로 개발자는 대체불가능하다" 정도가 되겠네요.

히어로 개발자는 제조영역 종사자라기 보다는 예술영역 종사자라고 보는게 맞습니다.

애초에 피카소나 샤갈을 다른 사람으로 대체할 수 있다는 정신나간 소리를 하는 사람이 있나요?

히어로 개발자들도 마찬가지입니다.

히어로 개발자가 많아져 소프트웨어 업계 전반의 개발자에 대한 인식이 바뀌면 좋겠습니다.

끝_