가설사고: 소프트웨어 개발자 관점에서
Inuit님 블로그에서 소개하는 글을 읽고 바로 느낌이 와서 지른 책입니다. 책에서는 마케팅 전략이나 컨설팅의 관점에서 얘기를 하지만 저는 해오던 일이 있어서인지 계속 소프트웨어 개발자의 눈으로 생각하게 되네요.
![]() |
가설사고, 생각을 뒤집어라 – ![]() 우치다 카즈나리 지음, 보스턴컨설팅그룹(BCG) 옮김/3mecca.com(쓰리메카닷컴) |
1. 디버깅(Debugging)
디버깅이란 컴퓨터 프로그램의 결함(버그라고도 하죠)을 찾아서 고치는 작업입니다. 그러려면 먼저 결함의 원인을 찾아야 하는데요, 경험적으로 크게 두 가지 방법을 쓰는 것 같습니다. 먼저 탐색적인 방법, 프로그램을 한 단계씩 실행하면서 제작자의 의도와 다르게 동작하는 부분을 찾아내는 겁니다. 두 번째는 “직관적으로” 어떤 부분이 문제일 거라는 예측을 하고 나서 진짜 그것 때문인지를 확인하는 방식입니다. 여러 작업이 동시에 실행되는 멀티스레딩 프로그램의 경우에는 첫 번째 방식으로 버그를 추적하기가 어렵기 때문에 이 방법을 자주 씁니다. 그물을 쳐놓고 유인해서 버그가 걸리는지를 확인하는 건데, 책에서 말하는 가설 사고와 공통점이 있네요.
하지만, 링크한 글에서 inuit님이 얘기했듯이 보통은 두 가지 방법을 섞어서 쓰게 됩니다. 그럴 수밖에 없죠. 어디서부터 탐색을 시작할지 결정하는 것은 역시 경험에서 우러나오는 직관이고, 그물에 걸린 버그의 원인을 찾아내려면 또 다시 탐색이 필요하거든요.
2. 큰 그림
큰 그림을 그리면서 일을 한다는 것은 최종 목표 혹은 결론을 염두에 두고 현재 작업의 의의를 끊임없이 생각한다는 뜻으로 이해합니다. 가설을 먼저 세우고 검증하는 접근 방식의 장점이기도 한데요, 이 부분을 읽으면서 제 머릿속에 떠오른 것은 테스트 주도 개발(Test Driven Development, TDD)이라는 단어였습니다.
보통은 소프트웨어를 먼저 만들고 그 후에 제대로 동작하는지 테스트 합니다. 그게 당연한 것 같죠? 그런데 테스트 주도 개발이라는 책에서 켄트 백은 그 순서를 바꿀 것을 제안합니다. 프로그램이 의도한대로 동작하는지 테스트하는 프로그램을 먼저 만들고, 그 다음에 진짜 프로그램을 만들자는 거죠.1
이 방식에는 여러 장점이 있는데, 그중에서 제가 얘기하고 싶은 것은 모듈의 구체적인 목표와 어떻게 사용될지에 대한 설명이 있기 때문에 공들여 만들고 나서 ‘앗, 이 산이 아닌가봐.’ 하는 경우가 없다는 점입니다. (네, 없어지지는 않죠. 그래도 최소한 줄어는 듭니다 :) 완성된 모습을 먼저 그려놓고 그 속을 채워가는 방식이 실험하기 전에 논문부터 쓴다는 연구자의 얘기(책에 나옵니다)와도 좀 통하지 않나요?
기억을 더듬어보면 우리 공부할 때도 그랬던 것 같습니다. 기본이라는 이름 아래 어디에 쓰일지도 모르는 이상한(?) 개념들을 힘들게 익히고 나면 그제서야 활용 분야라는 녀석이 턱 하고 나타납니다.
‘여기까지 오느라 수고했어. 앞에서 배운 거 기억나지? 나는 여기에 쓰는 거야.’
그러면 무릎을 탁 치고는 개념을 복습하러 갑니다. 벌써 다 까먹었거든요(…) 그런 기억 없으신가요? 저는 특히 선형대수(Linear Algebra)가 그랬는데요, 컴퓨터 그래픽스나 정보검색 등 전혀 생각지도 못하던 분야에 활용되는 걸 보면서 기가 막혀했던 기억이 납니다. 그 후로는 새로운 개념을 공부할 때는 먼저 그 활용 분야부터 살피는 습관이 생긴 것 같아요. 책이나 위키피디아를 볼 때 뒤에서부터 훑어보는 이유도 바로 그런 것이고요.
쓰고 보니 책 소개는 없고 그냥 제 생각만 주저리주저리 늘어놓았군요. 그냥 마무리할게요. 가설을 먼저 세우고 검증해나가는 접근 방식이 생소한 분, 더 효과적으로 일하는 법을 배우고 싶은 분께 이 책을 추천합니다.
- 프로그램이라는 용어를 썼는데, 사실 완성된 소프트웨어보다는 이를 구성하는 각각의 모듈(module)을 구현하는 단계에 유용한 개념입니다. [↩]
| Tweet |
이 글과 관련있을지도 모르는 글:
Tags: book, hypothesis, practice, programming, result-oriented
이 글을 찾은 사람들이 쓴 검색어: 가설지향적 사고 / 가설 사고 test /| This entry was posted on Wednesday, December 30th, 2009 at 4:32 pm and is filed under book. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site. |


가설사고, 생각을 뒤집어라…
직장인이 습득해야 할 궁극의 업무 기술을 하나 꼽자면 무엇일까요? 전 문제해결기법(problem solving technique)을 꼽습니다. 문제해결기법 흔히 컨설팅 방법론이라 불리우지만, 보다 일반적인 명칭은 문제해결기법입니다. 아주 거칠게 간략화하면, 문제해결기법은 두 가지 기둥에 의지합니다. 논리적 사고 방식(logical thinking)과 가설 지향적 접근법(hypothesis-driven approach)입니다. 논리적 사고방식은 민토…
가설방법을 디버깅과 아키텍처나 프로그래밍에 적용해서 생각하다니 재미납니다.
저도 덕분에 새로운 응용을 배웠습니다. ^^
참고로 가설사고가 아니라 가설적 방법은 정말 폭넓게 응용이 가능하지요. 좋은글 고맙습니다. ^^
최근에 처음으로 분석 업무를 맡아서 좀 헤매고 있었는데, 덕분에 좋은 방법론을 알게 되었습니다. 이제부터 열심히 갈고 닦아서 든든한 무기로 만드는 건 저의 몫이겠죠. 댓글 고맙습니다.
PS. 보내주신 트랙백이 스팸으로 분류되어 있길래 살려놨습니다 ^^
[...] 때문에 지금 무엇을 해야 할지에 대한 실용적인 지침이 됩니다. 또한, 가설사고 책 소감에서 썼듯이 결과를 먼저 생각하는 접근법은 지금 하는 일의 의미를 큰 [...]
[...] 가설사고를 적용하려고 할 때 가장 어려운 것은 바로 가설을 만드는 겁니다. 그 방법은 어떻게 가르쳐 주기도 애매해서 결국 스스로 경험과 노력을 통해 익히는 수밖에 없는 것 같습니다. 하지만 이런 가설 추론법이 아무런 이론적 근거도 없는 건 아니고, 퍼스(Charles Sanders Peirce)라는 미국 철학자가 귀추법(Abduction)이라고 분류한 바 있습니다. [...]