더 많은 일을 하면서 더 빨리 하기
모순입니다. 어떻게 더 많이 하면서 더 빨리 할 수 있을까요?

앨린 톰슨(Allyn Thompson)이란 사람이 있습니다. 아마추어 망원경 제조에서는 전설적인 인물이라고 합니다. 1947년에 다음 책을 출판했고 지금도 고전으로 읽히고 있다고 합니다.



그 사람이 이런 말을 했습니다.

It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror.

4인치 반사경을 만든 다음에 6인치 반사경을 만드는 것이, 6인치 반사경 하나 만드는 것보다 더 빠르다.

이름하여, 망원경을 처음 만드는 사람을 위한 톰슨의 법칙(Thompson's Rule for first-time telescope makers)이라고 합니다.

제가 이 법칙을 처음 알게 된 것은 Programming Pearls라는 책(국내에는 인사이트에서 "생각하는 프로그래밍"으로 출간)의 저자로 유명한 Jon Bentley의 CACM 기사(CACM 1985년 9월판, Vol. 28 No. 9)에서 였습니다. 그 기사의 제목은 "Bumper-Sticker Computer Science"로, 글의 내용은 자동차 범퍼에 스티커로 붙이고 다니는(혹은 그럴만한) 전산학의 격언들에 대한 것입니다.

각 격언에는 그 말을 한 사람, 혹은 그 말을 발견했고 또 좋아하는 사람에게 크레딧이 주어져 있는데 이 격언에는 빌 맥키먼(Bill McKeeman)이라는 사람의 이름이 붙어있습니다. 이 사람은 공학 계산용 소프트웨어로 유명한 MATLAB의 개발자 중 한사람으로, 컴퓨터 역사를 함께 한 숨은 영웅이라고 해도 과언이 아닙니다. 그런 사람의 이름이 붙어 있으니 더더욱 이 격언에 대한 신뢰가 생깁니다.

분명히 전자, 즉 4인치 반사경 만들고 또 6인치 반사경 만드는 것은 돌아가는 길입니다. 반사경 2개를 만들어야 하니 하는 일도 더 많습니다. 그냥 6인치 반사경 하나 만들어버리고 말지 뭐하러 2개나 만듭니까? 결국 원하는 것은 6인치 반사경이라면. 그런데, 신기하게도 더 많이 하는 것이 더 빨라집니다.

왜 그럴까요? 4인치 만드는 것은 비교적 금방 할 수 있기 때문입니다. 그리고 그걸 하고 나면, 내가 더 똑똑해지기 때문입니다. 내 기술이 더 나아지기 때문입니다. 경험이 쌓이기 때문입니다. 이 투자는 곧 복리로 이득을 얻게 되기 때문입니다. 단순 산술 계산으로는 이런 점을 놓치기 쉽습니다. 우리는 자기가 하는 일에 의해 자신 역시 변할 수 있습니다. 뭔가 일을 한다는 것은 쌍방향적 변화를 야기합니다. 하지만 무엇을 먼저 하느냐, 어떤 길을 택하느냐에 따라 순탄하냐 험난하냐가 결정되기도 합니다. 지름길인 것 같은데 고생 죽사게 하면서 더 오래 걸리는 길이 있고, 돌아가는 것 같은데 술술 넘어가고 금방 가는 길이 있는 겁니다.

처음부터 크고 어려운 일을 하는 것은 학습 곡선이 가파르고 비용이 큽니다. 하지만 작고 쉬운 것을 먼저하고 나면 애초의 그 가파른 곡선이 낮은 언덕으로 바뀌어 있습니다. 총 비용을 따져서 오히려 이득인 경우가 많습니다.

박응주씨에게서 들은 이야기입니다. 응주씨가 대학에서 알고리즘 강의를 들었답니다. 그 수업은 매주 과제를 하나씩 내주고 학생들이 그걸 다음주까지 프로그램을 작성해서 풀게해서, 그걸 토대로 성적에 반영했다고 합니다. 채점 기준은 세 가지였다고 합니다. 프로그램 실행 속도와 제출시간, 그리고 정확성(테스트 케이스를 얼마나 통과하냐). 빨리 답을 내놓는 프로그램일수록 높은 점수를 받고, 남들보다 먼저 코드를 제출할수록 또 높은 점수를 받으며, 정확한 답을 할수록 높은 점수를 받습니다. 아, 제약이 몇가지 있었습니다. 무엇보다, C언어로 작성을 해야 했습니다.

응주씨는 이 과제를 우선 파이썬 같이 찰흙처럼 말랑말랑하고 다루기 쉬운 언어로 먼저 푼 다음, 그 코드를 C언어로 다시 작성해서 제출했다고 합니다. 남들보다 더 많은 일을 한 것이죠. 결과는? 수행 속도 면에서도 좋은 점수를 얻었고, 대다수의 사람보다 빨리 제출할 수 있었다고 합니다.

저 역시, 어차피 자바 환경에서 돌아가야할 시스템인데, 일단 파이썬(정확히는 Jython이라고 자바 환경에서 구현된 파이썬)으로 만들고 야금야금 자바로 변환해서 그 효과를 톡톡히 본 적이 몇 번 있습니다. 특히, Jython 같은 환경을 사용하면 첫번째로 만든 4인치 반사경 단계부터 바로 실제 환경에서 그대로 사용가능하고 또 그걸 점진적으로 6인치로 바꾸기 쉽다는 장점이 있습니다.

벤틀리의 기사에 다음과 같은 격언들도 있네요.
Prototyping cuts the work to produce a system by 40 percent. --Larry Bernstein, Bell Communications Research


Translating a working program to a new language or system takes 10 percent of the original development time or manpower or cost. --Douglas W. Jones, University of Iowa

몰입에 대한 연구로 유명한 미하이 칙센트미하이 교수는 말합니다. 우리가 가장 몰입이 잘 되는 때는 지루함과 두려움의 사이에 있을 때라고. 너무 쉬운 것은 지루하고, 너무 어려운 것은 두렵습니다. 또, 외국어 학습 이론에 대한 대가 크라센(Stephen Krashen) 교수 같은 사람은 i+1 이론을 이야기 합니다. 현재 자신의 수준을 i라고 했을 때 거기에서 약간 상위레벨의 지식으로 학습을 해야 가장 좋다, 뭐 이런 어찌보면 상식적인 이야기이죠.

몰입이 잘 되고, 적당히 도전적이고, 재미있고, 교육적이고... 많은 경우 이 표현들은 다 동의어입니다(see also 재미있게 공부하기). 어려운 일을 대면했을 때 "오히려 더 많이 하면서 더 쉽게, 더 빨리 할 수 있는" 길은 없나 자문해 보세요. 꼭 프로그래밍에만 적용되는 이야기는 아닐 것입니다.

많이 해서 더 빨리 하는 경우와 그 근본 원리는 같은데, 좀 다른 법칙으로 "순서를 바꾸면 같은 일도 훨씬 쉽게 또 빨리 할 수 있다"는 게 있습니다(제가 경험적으로 만들었습니다). 하려던 일들의 집합은 유지하지만 그 속에서 순서를 바꾸는 겁니다.

예를 들어, 저는 조직의 문화, 사람들, 그들의 마인드를 바꾸는 일을 해오고 있는데, 제 컨설팅 경험 초기에는 일단 눈에 가장 띄는 문제에 집중 했습니다. 가장 저항이 센 사람들하고 먼저 씨름을 했지요. 그런데 이렇게 하면 컨설턴트도 지치고 컨설팅 받는 사람도 지쳐버립니다. 밖에서 구경하는 사람들도 재미가 없구요. 그래서 처음에 오히려 변화에 대해 욕구가 있는 사람들을 대상으로 시작을 해봅니다. 신기하게도 이렇게 하다보면, 이전에 저항감이 강하던 사람들이 경계심을 풀거나, 우리가 진행하는 일에 관심을 갖기 시작하는 경우가 많았습니다. 미는 것(push)이 아니고 끌어 당기는 것(pull)이지요.

예전에 Contagious Success(전염성 성공)라는 책을 읽었습니다. 전세계에서 하이 퍼포먼스를 보이는 집단을 방대하게 조사한 연구를 토대로 쓴 책입니다. 부제가 Spreading High Performance Throughout Your Organization(조직에 높은 퍼포먼스를 퍼뜨리기)입니다. 제목만으로도 매우 끌리는 책인데요.

이 책의 골자는 다음과 같습니다. 조직을 퍼포먼스 순으로 세 그룹으로 나누었을 때(하이 퍼포먼스 집단 10%, 평균적 퍼포먼스 집단 52%, 낮은 퍼포먼스 집단 38%) 그 중 52%의 중간 그룹, 즉 "거의 하이 퍼포먼스에 도달한" 집단에서 다시 상위 20%에 해당하는 집단의 퍼포먼스를 끌어올리는 것이 가장 효과적이고 전체적으로도 가장 큰 효과를 낼 수 있다고 합니다.

또 다른 적용 분야로는 책읽기가 있습니다. 노스모크의 HowToReadIt이라는 페이지에 있는 조각 그림 읽기 Jig-Saw Puzzle Reading(원래 이런 이름이 있는 건 아니고 제가 이름 붙였습니다)가 그 예가 되겠습니다. 저는 읽다가 지루하거나 혹은 어려워서 진도가 안나가면 책을 후루룩 훑으면서 재미있을만한 부분을 골라서 먼저 읽습니다. 그런식으로 읽다보면 아까 어렵거나 지겨워 건너뛴 부분이 어느새 "재미있거나 이해하기 쉬운" 내용으로 변해있는 것을 발견하게 됩니다. 제 생각으로는 이 방법으로 책읽기 속도가 1.5배 이상 빨라진 것 같습니다. 그 외에 단어공부에도 적용가능합니다(일명 Frontier Zone 방법이라고해서 매일 접하는 단어에서 자기가 확실히 아는 단어, 아예 모르는 단어는 제외하고 어중간한 단어부터 공부하는 겁니다).

벤틀리는 자신의 기사 말미에서 여느때처럼 숙제를 냅니다. 기사에 소개된 격언들에 대해 다음 실험을 해보는 겁니다:
  • 규칙을 좀 더 정확하게 재진술 해보라
  • 규칙을 지지하는 작고 구체적인 예를 제시해 보라
  • 좀 더 큰 프로그램에 대해 적용되는 실제 사례의 무용담을 찾아보라
  • 규칙에 대해 비평해 보라. 언제나 참인 것은 무엇이고 때로는 우리를 오도할 수도 있는 것은 무엇인가?
좋은 과제 같습니다. 여러분들도 자신의 경험을 돌아보세요. 더 많이 하면서 오히려 더 빨리 할 수 있었던, 혹은 일의 순서를 바꾸는 것만으로 전체 속도가 높아졌던 때는 언제였나요? 구체적으로 어떤 상황이었나요? 그 때 어떤 조건과 상황이 그걸 가능하게 했을까요? 오늘날 내가 가진 문제에 비슷한 조건과 상황을 만들어 낸다면 어떨까요?

--김창준
by 애자일컨설팅 | 2006/04/07 02:03 | 트랙백(12) | 덧글(21)
트랙백 주소 : http://agile.egloos.com/tb/1762301
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from ** Exclusive.. at 2006/04/07 09:10

제목 : 더 많은 일을 하면서 더 빨리 하기
더 많은 일을 하면서 더 빨리 하기 <......more

Tracked from 이오공감의 흔적 at 2006/04/07 11:59

제목 : 2006년 4월 7일 이오공감
인텔 맥에서 XP를 돌린다!  by bikbloger애플은 현지 시간으로 4월 5일, 인텔CPU를 탑재한 맥에서도 윈도XP를 구동할 수 있는 프로그램인 Boot Camp 공식 베타판을 웹사이트에 공개했습니다...반드시 고쳐야 하는 습관, 지각 -1  by mokuren나는 굉장한 지각쟁이다. 초등학교6년을 포함해 중학교, 고등학교, 심지어 대학교 생활을 하는 동안에 지각하지 않은 날은 거짓말 조금 보태서 스무 날 정도 밖에 안 되었던...더 많은 일을 하면서 더 빨리 하기  by 애자일컨설팅제가 이 법칙을 처음 알게 된 것은 ......more

Tracked from 고안해 내는 재능 at 2006/04/07 13:43

제목 : 제대로 하려면 제대로된 과정을 밟아라.
더 많은 일을 하면서 더 빨리 하기 경험과 직관적인 능력을 겸비하여 설계, 코딩을 바로 시작하는 사람은 얼마나 좋을까? 하지만 그렇게 되기 위해 나름대로 과정을 거쳤을 것이다. 만약 경험과 능력이 부족한 상황에서 직관적인 개발은 미래를 예측하지 않는 실수를 범할 수 있다. 당시엔 빠른 결과물을 만들수 있지만 소프트웨어 역시 성장을......more

Tracked from Taek's blog at 2006/04/07 22:53

제목 : 더 많은 일을 하면서 더 빨리 하기
더 많은 일을 하면서 더 빨리 하기 좋은글이네요.. 대단하세요!! 대학교 프로젝트 같은것도... 일단 무언가 빨리 해버리고나서 거기서 고치고 지우고 추가하고 해서 하는게 아웃풋은 더 좋은것 같은데... 이런것도 연장선상으로 보면 같은 말인지? ...more

Tracked from Math + Finan.. at 2006/04/08 00:06

제목 : Premium, Claims, Loss ration
더 많은 일을 하면서 더 빨리 하기 어젯밤, 사무실에서 다들 난제 하나로 고민에 빠지시다. 내 보기에 변수는 열몇개인데 저걸 어떻게 컨트롤하나.. 담보가짓수도 한두개가 아닌데. 내가 무슨 문제를 풀 때 보통 시작하는 건 문제를 가장 단순한 구조로 simplify시키는 것이다. 이것도 담보 두 개로 세팅(즉 n=2)해......more

Tracked from SNAIPER의 조그마.. at 2006/04/08 18:05

제목 : &quot;더 많은 일을 하면서 더 빨리하기&quo..
오늘 RSS 페이퍼를 보니 김창준님이 꽤 생각해볼만한 글을 하나 적으셨더군요. 그 내용은 다음과 같습니다. 더 많은 일을 하면서 더 빨리 하기 이 글을 읽고 생각하다 보니 저도 이런 일은 불과 얼마전에 있었음이 생각나더군요. 이 블로그에도 글이 있는데, 아래 쪽 넥슨 입사 문제 풀기입니다. 제가 그 문제를 처음 풀 때 알고리즘도 알고리즘이었습니다만, 목표는 ruby 답게 풀기였습니다. 왜 이것에 매달렸다면 처음 C#으로 코딩을 해서 데브피아 자료실에 올린 일이 있었습니다. 한 3~4년 전 일인데, 그 ......more

Tracked from 아름다운 프로그래밍 at 2006/04/24 11:26

제목 : 더 많이 하면 더 빨라질 수 있다!
더 많은 일을 하면서 더 빨리 하기 위 글은 애자일 이야기의 김창준씨의 글이다. 소프트웨어 개발과 관련해서 참 대단한 분이다. 예전에 노스모그라는 위키를 운영한다는 것을 신문에서 읽은 이후로 마소에서 그리고 그 밖의 여러 곳에서 "김창준"이라는 이름을 꽤 볼 수 있었......more

Tracked from 스마슈의 방 at 2006/07/28 10:25

제목 : (펌글) 더 많은 일을 하면서 더 빨리 하기
더 많은 일을 하면서 더 빨리 하기 흠.... 지금 시기에 적당한 글... 류짱의 아스트랄 월드 (http://blog.naver.com/pimpzila/70004545731)에서 보고 퍼 오다~. 아래는 원문 복사...모순입니다......more

Tracked from 체리필터의 인생이야기 at 2006/08/31 12:27

제목 : 애자일 프로그램이란...
애자일 프로그램이 뭔지 궁금했는데...이 글이 많은 도움이 된거 같다.한국 내에서도 애자일 문화가 정착 될 날이 빨리 오길 바란다....more

Tracked from Jongwook's B.. at 2006/09/08 08:59

제목 : 더 많은 일을 하면서 더 빨리 하기
Xper.org 운영자로 유명한 김창준씨의 글 (원문보기) 뭔가 일을 할때 문제를 모두 한꺼번에 생각하다보면 통 해결 방안이 보이지 않거나 전혀 엉뚱한 곳에 도착하는 경우가 종종 있습니다. 저같은 경우 해보지 못했던 업무를 처음 맡았을때, 특히 그 일을 해야하는 시간이 적으면 적을수록 더욱 그런 문제에 자주 부딪히게 되는데요, 의욕이 앞서거나 욕심이 과했기 때문이기도 하겠지만 결국 그 문제에 대한 경험이 부족한 것도 원인이겠지요. 급할수록 돌아가라는.....more

Tracked from 날마다 새롭게~ at 2007/03/05 15:47

제목 : 쉬운 것 먼저 하기
우리는 흔히 크고 작은 일들이 산접해 있을 때, 중요한 일에만 매달리죠. 일거리가 많이 널려 있을 때는 자잘하고 쉬운 것 부터 하는 것이 요령이랄까요 100가지의 일 중, 쉬운 것 50개를 해치우고 나면 50%의 성과를 이룬 것이고, 나머지 50%의 일만 남았다는 생각이 드는 반면에, 중요한 일만 매달리다가 해결이 안되면 진척율은 0%. 그야말로 좌절(OTL)이죠. 쉬운 것 부터 하기 -&gt; 자신감 얻기 -&gt; 스케줄 관......more

Tracked from 날아오르다 at 2010/11/11 10:27

제목 : ㅇㅇ
더 많은 일을 하면서 더 빨리 하기...more

Commented by HFK at 2006/04/07 02:51
좋은 글이네요. 많이 배우고 갑니다.
Commented by eritaka at 2006/04/07 04:47
그러네요 좋은 글입니다!
Commented by xissy at 2006/04/07 06:54
동감합니다.
Commented by Jimmy at 2006/04/07 07:17
김창준씨 이 글 아주 맘에 드는군요. 요즘 일을 늘어놓고 힘에 겨워서 한숨짓던 중인데, 그래도 실수 않고 진행시킬수 있는 원리가 이런데 있었군요. 용기를 주는 글이기도 하지요. 건필하시길.
Commented by kebie at 2006/04/07 08:28
TDD 와 묘하게 닮았네요. ^^;
Commented by Mini at 2006/04/07 12:32
격무에 시달리다보면 기민함과 점진적 이라는게 계속 프로그래밍에만 적용하려하고 삶에서 계속 분리되곤 했는데, 잃어버린 반쪽을 찾은 느낌입니다.
Commented at 2006/04/07 13:11
비공개 덧글입니다.
Commented by 니코 at 2006/04/07 13:12
좋은 말이네요. 저도 포스트잇에 적어서 모니터 옆에 붙여뒀습니다:)
Commented by azureciel at 2006/04/08 01:10
자주 읽고 갑니다. 그런데, 몰입에 대한 연구로 유명한 교수는 미하이 칙센트미하이 입니다. 수정하면 좋겠습니다.
많이 배우고 갑니다. 감사합니다.
Commented by 유즈미 at 2006/04/08 08:49
좋은 말씀 고맙습니다.
Commented by 애자일컨설팅 at 2006/04/08 09:59
[azureciel님] 오자가 있었네요. 지적 감사합니다.
Commented by 알렉스 at 2006/04/08 22:34
좋은글 감사합니다.
Commented by 박종선 at 2006/04/10 01:14
개인적으로 천체관측을 좀 하면서 망원경을 다루어봤는데, 첫 예제가 마음에 들었습니다.
저 역시 programming을 하는데, 전 PERL이나 C로 짜고 나서 Java로 옮기는.. :) (Java가 상대적으로 약하다 보니.. ^^;)

어떤 새로운 가설을 검증하는데는, 자신만의 무기가 필요한것이라 생각이 됩니다.

이는 어떤 학문분야에서든, 세상 살이에서든 다 적용되는것 같습니다.. ^^

즐거운 한주 시작하세요~~~ ^^;
Commented by 마일 at 2006/04/10 12:29
정말 배울 게 많은 글 같아요. 특히 한번에 모든 일을 끝내려고 하는 제게는요. ^^
Commented by 이한길 at 2006/04/16 15:49
좋은 글 잘 읽었습니다... 고맙습니다.
Commented by 파장 at 2006/04/19 00:01
미하이 직센트 관련책을 많이봤는데요
이사람 책 좋아합니다.
Commented by nkokon at 2006/04/24 19:23
역시나 아는게 있어야 공부도 할 맛이 나더군요.
지금의 공부방식에 질문을 던져주는 글이었습니다.
Commented by 홍홍 at 2006/04/25 10:07
스스로 돌아볼 수 있게 하는 글이네요.
Commented by oiyoup at 2006/04/28 01:50
음... 그 순간은 빠를지 몰라도 공통부분을 잘 코딩하면 그것을 반복적으로 사용할 경우 그 공통부분을 먼저 코딩하는것이 나중에 생각해보면 더 빠르다는 것...너무 일반적이죠.
Commented by w0os at 2007/06/18 18:07
주옥같은 글이네요 ^^

정말이지 많은 것을 느낄 수 있게 해주는 포스트였습니다^^;
Commented by 라이언 at 2007/11/09 17:01
아주 좋은 글입니다.
예를 들었던, 독서에 관한 부분에 저도 공감을 합니다. 저도 책을 읽을때는 처음부터 순서대로 읽지 않습니다. 차례(목차)를 보고 가장 관심이 가는 부분부터 읽어나갑니다. 그러다보면 다른 부분들도 궁금해져 꾸준히, 그리고 재미있게 책을 읽어나갈 수 있습니다.
이걸 프로그래밍에도 적용해 보아야겠군요. 좋은 글 감사합니다.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >