블로그내용소개 – 에릭 립퍼트


[블로그내용소개] 에릭 립퍼트 – 전구하나바꾸는데 마이크로소프트 직원 몇 명이 필요할까?

원문 : http://blogs.msdn.com/ericlippert/archive/2003/10/28/53298.aspx

위 내용이 번역되어진 책이 최근에 조엘의 두번째 책으로 엮어졌습니다.
읽다보니 역시나 조엘의 블로그 만큼이나 재미난 것들이 많더군요. 아직 읽는 중입니다.

이 글에서 나온 내용중에 너무나 지금 하고 있는 일에 딱 맞는 조언이 될 수 있을 것 같아서 한번 생각해보자는 의미에서 발췌해서 보냅니다.
(오래된 글인데, 역시 좋은 글은 언제 읽어도 도움이 되는 것 같습니다. 자세한 내용은 원문을 살펴보시면 되겠습니다.)

물론 우리 회사가 마이크로소프트와는 다른 성격의 제품을 생산하는 곳이라 약간 다르기도 하고 마이크로소프트자체의 프로세스가 상당히 복잡하고 까다로와서 아래와 같이 될 수도 있지만, 어쨌든 한번쯤 기능을 추가하실 때 생각해볼만한 문제라고 생각합니다.

(한때 우리가 마이크로소프트를 이기자? 라고 외치셨던 분이 계셨습니다. 높으신 분으로 … 생각해보면 이기긴 힘들 것 같습니다. ㅎㅎ)

[내용]
마이크로소프트에 근무하고 있는 에릭 립퍼트라는 사람이 VBScript 에 기능을 추가하는 일을 담당하고 있을 때 벌어진 일화를 소개하고 있습니다.

고객이 특정 기능(일반적으로 사용되지 않는 기능)을 추가해달라고 요구하는 상황에서 예기했던 내용이라고 합니다. 물론 이 기능을 에릭이 추가하는데는 5분도 걸리지 않는다고 합니다. 하지만 이러한 기능을 넣을 수 없었던 이유에 대해서 아래와 같이 얘기했습니다.

“전구 하나 바꾸는데 마이크로 소프트 직원 몇 명이 필요하다고 생각하십니까?”

# 요구 기능을 5분 안에 구현하기 위한 개발자 1명
# 명세를 작성하기 위한 프로그램 관리자 PM 1명
# 명세의 지역화 문제를 검토하기 위한 지역화 전문가 1명
# 명세의 접근성과 사용성 문제를 검토하기 위한 지역화 전문가 1명
# 발생 가능한 보안 취약점을 점검하기 위한 개발자 1명, 테스터 1명, PM 1명 (최소인원)
# 보안 모델을 명세에 추가하기 위한 PM 1명
# 테스트 계획을 작성할 테스터 1명
# 테스트 스케줄을 갱신할 테스트 리더 1명
# 테스트 케이스를 작성하고 테스트 자동화 방법을 만들 테스터 1명 (단위테스트만 하는 개발자형 테스터가 따로 있는 모양이군요)
# 무작위로 버그를 찾아내기 위한 테스터 3-4명
# 문서를 작성하기 위한 기술 저장 1명
# 문서를 교정하기 위한 기술 검토자 1명
# 문서를 교정하기 위한 편집자 1명
# 새로 작성한 문서를 기존 문서에 추가하고 목차, 인덱스를 갱신할 문서 관리자 1명
# 문서와 에러 메시지를 윈도우에서 지원하는 모든 언어로 번역하기 위한 번역자 25명
# 이들 업무를 조정하고 개발 비용을 부사장에게 승인 받아야 할 상위 관리자 팀.

이들 중 개별적으로 시간이 많이 소요되는 건 없지만 다 더하면 상당한 시간을 소모하게 됩니다. 그것도 아주 간단한 기능을 구현하기 위해서 말이죠. 그리고 위 작업은 모든 것이 딱 맞아 떨어질 때를 가정한 것입니다. 만약 처음에 작성한 코드 다섯 줄에 버그가 있다면 어떻게 할까요? 우리는 버그를 찾고, 다시 테스트를 수행하는 등의 작업을 하기 위한 비용을 추가해야 할 것입니다.

처음 생각한 5분 이라는 개발 시간은 많은 사람의 작업과 비용으로 확장됐습니다. 그저 한 고객에 자신이 원하는 기능을 담은 1회용 VB6 컨트롤을 만드는 수고를 덜어 주기 위해서 말입니다. 미안합니다, 그렇게 하는 것은 사업상 불가능 하군요. 마이크로소프트 직원은 덜 익은 소프트웨어를 출시하는 일이 없도록 매우 열심히 노력합니다. 소프트웨어를 올바르게 작성하는 것 – 무엇보다도 평범한 일반 사용자가 보안 문제 없이 쉽게 기능을 사용할 수 있도록 보장하는 것 – 은 비용이 상당히 많이 드는 일입니다.

하지만 우리는 그 일을 잘 해내야 합니다. 우리가 새로 만드는 스크립트 엔진을 수억 명이 사용하고 수천만 명이 프로그래밍할 테니까요.

보편적인 일반 사용자와 관련이 없는 기능을 새로 작성하는 것은, 주요 기능을 구현하고 버그를 잡으며 보안 취약점을 찾을 자원 (사람, 시간, 돈)을 훔치는 일과 다를 바 없습니다.

끝.

위와 같은 내용입니다.

밑줄친 부분을 해석할때 오해를 갖게되면 곤란하니… 다시 얘기하면 어쨌든 우리는 제품을 내놓기도 하지만, 커스터마이징도 해줍니다. (이런 경우를 같이 하고 있는 상황을 염두해두고 이해하시면 좀 안맞는 상황일 수 있습니다)

내부적으로 연구소가 PS 팀 또는 다른 협력업체에게 릴리즈 한다는 개념 선상에서 이해하시면 좋을 것 같습니다.

(고객에게 바로 릴리즈하는 것은 SI 죠? 안그렇습니까? 우리 회사는 SI 이다 라고 생각하시면 쩝 머 그런거겠죠. 그럼 여기서 생각은 스탑. – SI 하면서 고객에 요구하는데 안하면 안되지 않습니까?)

어쨌든 마이크로소프트와 우리가 다르다고 생각하십니까? 그렇죠 여러가지 여건이나 상황은 다를 수 있습니다. 머 그럼 여기서 생각은 또 멈춰버리겠네요. 그럼 재미 없겠죠? 어쨌든 상황은 마소나 우리나 비슷한 것 같습니다. 제품을 패키징해서 내보내고 있으니까요. 제품 출시가 계속 되는 한은 위 문제를 우리 것으로 소화해서 고민해볼 만한 가치가 있는 것 같습니다.

한번쯤 사간나실때 읽어보시고 (원문을) 생각하는 시간을 가져보시기 바랍니다.