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

2006. 3. 15. 07:21

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

원문 : 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 하면서 고객에 요구하는데 안하면 안되지 않습니까?)

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

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

,

Michael Yuan Java blog: "Is Ruby replacing Java? -- Not So Fast"

루비가 자바를 대체한다고? 음.. 아직은 아니다... 라는 내용의 글인데, 요지는 아래와 같다.

1. 우선 우수한 솔루션이 보다 덜 우수한 솔루션을 항상 대체하는 것은 아니다.

2. 경재적인 측면에서도 우수한 프로그래밍 언어를 선택하는 것이 항상 비용이나 생산성 측면에서 보다나은 잇점을 가져다 주지는 않는다.

In software engineering speak, the actual implementation of asystem using a specific programming language has the lowest value inthe value chain

3. 한 프로그래밍 언어가 다른 것을 대체하지는 않는다. 새로운 언어가 새로운 분야를 개척하거나 새로운 언어를 시도하려고하는 신규 개발자들을 유입시키는 역할을 한다. 이러한 점 때문에 새로운 언어를 위한 파이를 키울 필요가 있는 것이다.
ex) 포트란 : Science , 코볼 : Buissiness, 자바: web app. 등등등.

!! Ruby/RoR 은 다음과 같은 점에서 배워야할 중요한 기술이다.

1. Ruby/RoR 의 가장 중요한 점은 Java EE 에서 혁신을 주도할 것이다. C# 이 자바 1.5의 혁신을 주도했던것 처럼.

2. 많은 웹사이트들을 빠르게 개발해야하는 사람들은 (예를들어 컨설턴트 또는 신규창업) Ruby/RoR 이 아이디어나 빠른 베타/프로토타입을 시장에 내놓기 위해 사용하기에 가장 훌륭한 툴이다.

==============
저자의 결론은 어쨌거나 Ruby/RoR 이 자바 프로그램들을 대체하지는 않을 거라는 내용이다. 하지만 Ruby/RoR 이배워야만하는 가치는 있다. 라는 내용인데.. .글쎄.. 과연 컨설턴트나/새로 창업하는? 신규로 시작하는 사람들에게만 유용한것일까?

역시 기존! 과거! 옛것! 등등 류에 깃발을 꽃기란 쉽지가 않은 것 같다.
내공이 높은 사람들을 모두 설득하기에도 역시나 새로운 기술이 얼마나 경험많은 사람의 고집을 꺽을 수 있을까?

모든 것이 비슷한 패턴이다... 이 것 또한 시간이 해결해줄 것인가? 나는? 우리는? 그냥 가만히 있진 말고 시도! 도전! ...

.

'몽상하기' 카테고리의 다른 글

나는 지식노동자인가?  (0) 2006.03.21
블로그내용 소개 - 에릭 싱크  (0) 2006.03.18
블로그내용소개 - 에릭 립퍼트  (0) 2006.03.15
해커와 화가 (1)  (0) 2005.11.14
Web 2.0이란 무엇인가 ?  (0) 2005.11.14
,

해커와 화가 (1)

2005. 11. 14. 12:51

해커와 화가 (1): "아름다운 소프트웨어인지 아닌지 측정할 수 있는 유일한 외부적인 방법은 시간이다. 시간이 지남에 따라서 아름다운 것은 번창하고못난 것은 사라진다. 불행하게도 여기에서 이야기하는 시간은 사람의 수명보다 길 수도 있다. 사무엘 존슨은 한 작가에 대한 평판이일정한 결론에 도달하기까지는 대략 백년 정도의 시간이 걸린다고 지적했다. 여론 형성에 영향을 미치는 작가의 친구와 추종자들이모두 죽어서 없어질 때까지 기다려야 한다는 뜻이다."

흣 재미난 내용이다. 사실 살아있는 동안 훌륭한 것이었다 라는 평가를 받기가 왜 어려운지 대충 이해할 수 있도록 설명해주는 내용 쯤 이랄까....
머 어쨌든 소프트웨어 업계에서 살아남는 것과 훌륭한 녀석을 선별할 수 있는 능력 과는 뗄레야 뗄수 없는 관계가 아닐까생각해본다. 매일 쏟아지는 녀석들 중에서 옥석을 가려내기가 참 어렵다. 이때 위와 같은 방법대로 약간 지켜보는 것만으로 어느정도가려낼 수 있다니.. 흐흐... 남들을 따라가는 형태로 보일 수도 있을 것 같은데, 잘 모르겠다.

문제는 열정과 관심을 잃지 않는 것. 항상 궁금해할 것. 튼튼한 체력! 정도가 아닐까.

,

Web 2.0이란 무엇인가 ?

2005. 11. 14. 10:46

What is Web2.0 Korean translation

웹2.0 에 대한 번역글을 읽어보았다. 결국 2.0 시대의 시발점 또는 화두에 등장하고 있는 것이 역시나 또 구글...
구글구글... 지속적으로 주시할 수 밖에 없는 것 같다. 서비스로서만 생각하던 것이 점차 플랫폼 성격을 띄어가고 있고, 역시나공개된 것들을 기반으로한 기본적을 많은 프로그램들을 설치하지 않아도 되는 형태를 띄고있는, 항상 네트웍에 연결된 요즘에는더더군다나 구글에 의존할 수 밖에 없는 것 같다.

국내에 비슷한 서비스들이 많지만, 역시나 군게일학. 뭔가 따라올테면 따라와바 식의 마구잡이 개발이 아닌 업계를 선도해 나가는 구글의 행보가 맘에 드는 건 당연한 일인 것 같다.

내안에 모든것을 담아내기에는 역부족이 되어버린지 오래... 정보들이 넘쳐나는 것을 스스로 분류하고 체계화해서 갖고있기란 이미 불가능해져버린 요즘이다.

차라리 한쪽 아주 깊숙한 곳에 푹 빠져서 연구하는 사람들이 아닌 다음에야 비슷한 경험들을 하고 있을테니... 이런 시대일 수록 점점 Web2.0 과 같은 형태가 힘을 받을 수 밖에 없는 것 같다.
나 혼자 인 것 같으면서도, 내가아닌 다른사람들의 집단 지식을 활용할 수 있다....!!! 음, 매력적이지 않을 수 없다.

지금은 아니라고 생각할지라도 앞으로 아니 모르는새에 이미 우리 사이에 깊숙히 침투해있는 구글에 대해서 언제까지 모른척할 순 없는 일인 것 같다.

.

,