От Ильича до Ильича
by sonnet 2006 이글루스 TOP 100 2007 이글루스 TOP 100 2008 이글루스 TOP 100 2009 이글루스 TOP 100 2010 이글루스 TOP 100 2011 이글루스 TOP 100
rss

skin by 이글루스
五卿博士
記一. 이 글은 방명록을 겸합니다. 저한테 하실 말씀이 있는 분께서는 이 글 밑에 공개(혹은 비공개) 글로 남겨주시면 됩니다. 옛 방명록은 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]
記二. 링크는 자유롭게 하셔도 좋습니다. (저는 강제할 수 없는 규칙을 두는 것을 좋아하지 않습니다)
記三. 글을 안 쓰니까 아예 들어오게 되질 않아서 습관을 바꿔 보려고 합니다. 별것 아닌 거라도 좀 쓰면서 들여다보는 습관을 다시 붙이는 쪽으로. (2013년 1월 21일 추가)

떠든 사람: 이재율
by sonnet | 2020/12/12 20:21 | 블로그/일상 | 트랙백 | 덧글(54)
Programmers at Work
오래 전에 마소지에서 이 책을 번역해서 연재했었고 (예상과 달리 번역되지 않은 부분은 없었음), 학생 시절에 영향을 많이 받은 책 중 하나

Programmers at Work: Interviews With 19 Programmers Who Shaped the Computer Industry

세탁기 메이택의 사용자 그룹은 왜 존재하지 않는가를 생각해 본 적이 있습니까? 세탁기를 사용하는데 동호회 따위는 필요하지 않기 때문이죠. 빨랫감을 집어 넣고 버튼을 누르면 그것으로 끝나죠. 마찬가지로 정보 처리를 하는 데는 하드웨어도 소프트웨어도 필요 없습니다. 일을 거들어 주는 기계만 있으면 됩니다. 하드웨어, 소프트웨어보다 어떤 일을 하는지가 중요합니다. […]

예, 그렇습니다. 만약 컴퓨터 회사가 토스터를 디자인한다면 어떻게 될까 생각해보셨습니까? 잠자리에서 일어나 아침 식사로 토스트를 먹으려고 합니다. 먼저 토스터의 스위치를 ON으로 켭니다. 만약 토스터가 제너럴 일렉트릭사 제품이라면 빵을 넣고 그대로 기다리기만 하면 됩니다. 그러나 토스터가 컴퓨터 회사에서 만든 제품이라면 어떻게 될까요. 제일 먼저 2분 동안 토스터 체크를 해야 하겠죠. 그 뒤 시스템 디스크를 넣고 시스템을 작동시킵니다. 그리고 나서 아침 식사 디스크를 넣어서 ‘LOAD TOASTER CODE’하고 타이프합니다.

그런 다음에는 어떻게 될까요. 메뉴가 나옵니다. ‘어떤 빵으로 하시겠습니까?’라고 묻습니다. 만약 캘리포니아의 프로그램이라면 메뉴에는 크로와상, 베이커리, 잉글리시머핀, 호밀빵 그리고 보통 때 먹는 빵이 들어가 있을 겁니다.

빵에는 A, B, C, D, E 라는 부호가 붙어 있습니다. 오늘 아침은 머핀을 먹어야지, 하고 C를 누릅니다. 그런데 아무 것도 일어나지 않습니다. 리턴키를 누르는 것을 깜빡 잊었기 때문입니다. C를 누르면 기계가 척척 반응하리라고 생각하겠죠. 어쨌든 실행키를 눌러야 합니다. 이것으로 끝났다고 생각하십니까?

물론 아닙니다. 이것은 컴퓨터 회사가 만든 토스터입니다. ‘틀림없습니까?’라고 물어 오기 마련입니다. 배는 고픈데 그런 자질구레한 것까지 물어오다니, 토스터를 바닥에 내동댕이치고 싶어질 겁니다. 어떻습니까? 머리가 혼란스럽지요. 지금까지 컴퓨터 때문에 짜증이 난 적은 없습니까? ‘아니지, 그렇게 해서는 안 되지, 2, 3천 달러를 쏟아 넣었는데’라고 흥분을 가라앉히고 참아 넘겨야 합니다. 모두 참고 있으니까요. 컴퓨터를 사용할 때마다, 몇 백만 명이 넘는 사람들이 이런 식의 넌센스를 경험하고 있습니다.

자, ‘예’라고 타이프하고 리턴키를 눌렀습니다. 그런데 에러 메시지가 나타납니다. 다른 키를 눌러야 했습니다. 그래서 매뉴얼을 조사해 보았지만 아무 것도 알 수 없었습니다. 도대체 이유가 뭘까요? 그 매뉴얼은 이미 바뀌어 버린지 오래이고 그것의 원형에 대해서만 설명하고 있기 떄문입니다. 자, 이것저것을 해서 드디어 2번 투입구에 빵을 넣습니다. 그리고 어느 정도 구울지를 지시합니다. 그러자 컴퓨터가 물어 봅니다. ‘같은 일을 반복하지 않도록 오늘 아침 식사를 세이브해 둘까요?’ ‘예’라고 타이프합니다. 그러자 또 컴퓨터가 ‘1번 투입구에 디스크를 넣으시오’라고 지시합니다. 그런데 포멧된 디스크가 옆에 없는 것을 알아차렸습니다.

여기에서 판매자에게 전화를 해서 디스크를 포멧하고 있는 동안, 이런 사태에서 벗어나 아침 식사를 편하게 먹는 방법은 없는지 묻습니다. 판매자는 ‘아, 그랬군요. 3천 달러의 하드 디스크 시스템을 MS-DOS 버전 9.8과 함께 사세요. 그러면 그런 골치 아픈 문제는 깨끗이 해결됩니다. 새로운 매뉴얼도 붙어 있습니다’라고 합니다. 이러는 동안에 출근 시간은 한참 전에 지났습니다. 이것이 바로 현실입니다. (Jef Raskin 편 중에서)



- 돈은 곧 권력과 명성이라고 생각되는데, 성공을 거둔 뒤 당신에게 어떤 변화가 있었습니까?

옛날에 저는 낡아 빠진 오렌지 운반용 트럭을 타고 돌아다녔습니다. 1970년대에 샀던 것이지요. 인터내셔널 하베스타 회사 제품이었습니다. 이미 미대륙을 두, 세 번 횡단했던 트럭이었지만, 모든 것이 갖추어져 있었고 뒷 칸에서 잘 수도 있었습니다. 당시 저는 애플사 간부였습니다. 그래서 그 낡아 빠진 트럭을 몰고 부하들과 함께 점심을 먹으러 다녔습니다. 정신이 없을 정도로 바빴기 때문에 그 때 어떤 차가 유행하고 있는지 전혀 몰랐습니다.

그 당시 모두가 포르셰 928이나 메르세데스 벤츠를 타고 다녔습니다만 저는 그런 종류의 분에 넘치는 차는 별로 갖고 싶지 않았습니다. 그런데 부하들이 제대로 된 차를 사라고 재촉하더군요. 그래서 동생과 상의를 했는데 동생이 좋은 아이디어를 생각해 냈습니다. 동생이 “벤츠나 포르셰의 새 차와 같은 가격이면 중고지만 훌륭한 롤스로이스를 살 수 있어요. 그러면 누구도 이러쿵저러쿵하지도 않고 동료들의 요구도 맞추어 줄 수 있을 거예요.”라고 알려 주었어요. 그래서 저는 중고 롤스로이스를 손에 넣었습니다. 그리고 나서 웃지 못할 일이 벌어졌습니다. 그 때까지 말도 걸어 오지 않던 동료가 싱글벙글거리며 말을 걸어 오더군요.

어쨌든 이 나라의 시덥지 않은 민주주의에 대해 많이 배웠습니다. 주유소에 가면 눈썹을 휘날리며 종업원이 달려와서 롤스로이스의 유리를 닦더군요. 그리고 저더러 <선생님>이라고 부르더군요. 한 번은 레스토랑 정면의 주차 금지 구역에 차를 세웠는데 아무도 무어라고 말하지 않더군요. 심지어 종업원은 이렇게 말했습니다. “선생님, 대단히 감사합니다. 입구에 차를 세워 주셔서 정말 감사합니다. 누가 봐도 롤스로이스를 몰고 다니는 손님이 저의 가게에 식사를 하러 오셨다는 것을 알 수 있으니까요.” 맥도날드 드라이브숍에 가는 것도 즐거웠습니다. 롤스로이스를 타고 나서 비로소 세상 돌아가는 이치를 알게 되었습니다. 공항에 가면 다섯 명이나 뛰어나와 차의 문을 정중히 열고 “샌프란시스코 국제 공항에 잘 오셨습니다”라고 손을 비비더군요. 낡은 차를 타고 다닐 떄는 눈길도 주지 않더니, 팁을 많이 받을 수 있다고 생각한 것인지 그들은 거대한 <고철 덩어리>에 경의를 표시했습니다.

그리고 카이저사의 대공장에 차를 몰고 갈 수도 있었습니다. 일렬로 줄을 서 있는 경비원의 제지를 전혀 받지 않고요. 공장을 견학하고 싶었는데, 전에는 쉽사리 허가를 내주지 않았습니다. 그래서 롤스로이스를 타고 그 곳까지 갔었죠. “멈포드씨와 약속이 있습니다.” “아, 그렇습니까, 어서 들어가세요.” 정말 쉽게 들어갈 수 있었습니다. 애플사를 떠난 후 롤스로이스를 팔아 치웠지만. (Jef Raskin 편 중에서)


다들 주식으로 돈을 많이 벌었는데, 보스가 똥차를 끌고다니는 바람에 차를 바꿀 수 없었던 부하들의 애환을 그린...

by sonnet | 2020/02/15 21:15 | | 트랙백 | 덧글(1)
브룩스의 법칙
두 번째 잘못된 사고방식은 추정 및 일정 관리에서 투입된 노력을 셈할 때 쓰는 단위에 나타나 있는데, 바로 맨먼스man-month라는 단위다. 물론 프로젝트 비용은 투입된 사람 수와 달수의 곱에 따라 변한다. 하지만 작업 진척도는 그렇지 않다. 그러므로 맨먼스 단위로 작업량을 잰다는 것은 위험하고도 기만적인 미신과도 같다. 거기에는 사람과 일정이 서로 교환 가능하다는 인식이 깔려 있다.

사람과 일정이 교환 가능한 유일한 경우는, 어떤 일을 여러 사람에게 나눠줄 수 있으면서 서로 간에 소통할 필요가 없는 경우다(그림 2.1). 이것은 밀을 수확하거나 목화를 따는 일에는 들어맞겠지만, 시스템 프로그래밍에는 대략이라도 해당되지 않는다.


만약 작업의 성격상 순서가 있어서 나누기가 어렵다면, 거기에 어떤 노력을 더 쏟아 붇더라도 일정에는 아무런 영향을 미치지 못한다.(그림 2.2). 아기가 세상에 태어나려면 임신부가 몇 명이든 아홉 달이 필요하다. 버그를 찾고 고치는 것이 순차적으로 진행될 수밖에 없으므로 소프트웨어 개발 작업은 이처럼 분할이 어려운 경우가 많다.

분할은 가능하지만 나뉜 하위 작업들을 처리하는 데 커뮤니케이션이 필요하다면, 거기에 들어가는 노력 또한 전체 작업에 포함되어야 한다. 따라서 이런 경우는 아무래도 사람과 기간을 대등하게 맞바꿔 계산한 것에 못 미치는 결과를 기대할 수밖에 없다(그림 2.3).

커뮤니케이션으로 추가되는 부담은 훈련과 의사소통의 두 부분으로 나뉜다. 모든 작업자는 기술적인 내용, 작업 목표, 전반적인 전략, 업무 계획 등에 대해 훈련을 받아야 한다. 이런 훈련은 분할할 수가 없는 작업이므로 그 부담은 추가로 투입되는 사람 수에 비례해서 증가한다. [1]

의사소통 쪽은 좀 더 좋지 않다. 각 파트가 모든 파트와 개별적으로 조정을 해야 한다면, 커뮤니케이션 부담은 n(n-1)/2배가 된다. 일대일 의사소통의 횟수는 세 명의 경우 두 명일 때보다 세 배가 되며, 네 명이라면 여섯 배가 된다. 만약 세 명, 네 명, 그 이상의 사람이 모여서 회의를 통해 문제를 해결해야 한다면 일은 더욱 심각해진다. 커뮤니케이션 문제 때문에 더해지는 부담은 작업을 나눠서 얻는 이점을 완전히 상쇄할 수도 있는데, 그림 2.4에 이런 상황이 나타나 있다.

소프트웨어를 만든다는 것은 본래 조직적인 활동, 즉 복잡한 상호연관성을 가진 활동이기 때문에 의사소통에 품이 많이 들 수밖에 없으며, 작업 분할로 확보된 개별 업무 시간을 금방 잠식해 버린다. 따라서 사람을 더 투입하는 것은 일정을 단축시키기는커녕 더 늘어지게 만든다.

[...] 지금까지의 내용을 극도로 단순화한다면, 다음과 같은 브룩스의 법칙을 제시할 수 있을 것이다.

“늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다.”

이렇게 하여 우리는 맨먼스에 관련된 미신을 걷어낼 수 있다. 프로젝트에 소요되는 기간은 순서대로 처리해야 하는 내부 요소에 좌우되며, 필요한 최대 인원수는 독립된 하위 작업의 개수에 좌우된다. 이 두 가지 수치를 파악했을 때, 관리자는 더 적은 수의 사람과 더 긴 기간에 기초한 일정을 수립할 수 있다. (유일한 위험은 제품이 시대에 뒤쳐지게 되는 것이다). 그러나 더 많은 사람과 더 짧은 기간으로는 실행 가능한 일정을 만들어 내지 못한다. 부족한 시간 탓에 망가진 소프트웨어 수는 다른 이유로 그렇게 된 경우를 모두 합한 것보다도 많다.

Brooks Jr., Frederick P. 1995. The Mythical Man-Month: Essays on Software Engineering, Anniversary(2nd) ed. Addison-Wesley Professional. (강중빈 역, 『맨먼스 미신 : 소프트웨어 공학에 관한 에세이』. 서울: 인사이트. pp.15-19, 25-26)
by sonnet | 2020/02/03 14:12 | 과학기술 | 트랙백 | 덧글(10)
<< 이전 다음 >>