가설사고: 소프트웨어 개발자 관점에서

by seunglee

가설사고, 생각을 뒤집어라8점
우치다 카즈나리 지음, 보스턴컨설팅그룹(BCG) 옮김/3mecca.com(쓰리메카닷컴)

Inuit님 블로그에서 소개하는 글을 읽고 바로 느낌이 와서 지른 책입니다. 책에서는 마케팅 전략이나 컨설팅의 관점에서 얘기를 하지만 저는 해오던 일이 있어서인지 계속 소프트웨어 개발자의 눈으로 생각하게 되네요.

1. 디버깅(Debugging)

디버깅이란 컴퓨터 프로그램의 결함(버그라고도 하죠)을 찾아서 고치는 작업입니다. 그러려면 먼저 결함의 원인을 찾아야 하는데요, 경험적으로 크게 두 가지 방법을 쓰는 것 같습니다. 먼저 탐색적인 방법, 프로그램을 한 단계씩 실행하면서 제작자의 의도와 다르게 동작하는 부분을 찾아내는 겁니다. 두 번째는 “직관적으로” 어떤 부분이 문제일 거라는 예측을 하고 나서 진짜 그것 때문인지를 확인하는 방식입니다. 여러 작업이 동시에 실행되는 멀티스레딩 프로그램의 경우에는 첫 번째 방식으로 버그를 추적하기가 어렵기 때문에 이 방법을 자주 씁니다. 그물을 쳐놓고 유인해서 버그가 걸리는지를 확인하는 건데, 책에서 말하는 가설 사고와 공통점이 있네요.

하지만, 링크한 글에서 inuit님이 얘기했듯이 보통은 두 가지 방법을 섞어서 쓰게 됩니다. 그럴 수밖에 없죠. 어디서부터 탐색을 시작할지 결정하는 것은 역시 경험에서 우러나오는 직관이고, 그물에 걸린 버그의 원인을 찾아내려면 또 다시 탐색이 필요하거든요.

2. 큰 그림

큰 그림을 그리면서 일을 한다는 것은 최종 목표 혹은 결론을 염두에 두고 현재 작업의 의의를 끊임없이 생각한다는 뜻으로 이해합니다. 가설을 먼저 세우고 검증하는 접근 방식의 장점이기도 한데요, 이 부분을 읽으면서 제 머릿속에 떠오른 것은 테스트 주도 개발(Test Driven Development, TDD)이라는 단어였습니다.

보통은 소프트웨어를 먼저 만들고 그 후에 제대로 동작하는지 테스트 합니다. 그게 당연한 것 같죠? 그런데 『테스트 주도 개발』이라는 책에서 켄트 백은 그 순서를 바꿀 것을 제안합니다. 프로그램이 의도한대로 동작하는지 테스트하는 프로그램을 먼저 만들고, 그 다음에 진짜 프로그램을 만들자는 거죠. ((프로그램이라는 용어를 썼는데, 사실 완성된 소프트웨어보다는 이를 구성하는 각각의 모듈(module)을 구현하는 단계에 유용한 개념입니다.))

이 방식에는 여러 장점이 있는데, 그중에서 제가 얘기하고 싶은 것은 모듈의 구체적인 목표와 어떻게 사용될지에 대한 설명이 있기 때문에 공들여 만들고 나서 ‘앗, 이 산이 아닌가봐.’ 하는 경우가 없다는 점입니다. (네, 없어지지는 않죠. 그래도 최소한 줄어는 듭니다 :) 완성된 모습을 먼저 그려놓고 그 속을 채워가는 방식이 실험하기 전에 논문부터 쓴다는 연구자의 얘기(책에 나옵니다)와도 좀 통하지 않나요?

기억을 더듬어보면 우리 공부할 때도 그랬던 것 같습니다. 기본이라는 이름 아래 어디에 쓰일지도 모르는 이상한(?) 개념들을 힘들게 익히고 나면 그제서야 활용 분야라는 녀석이 턱 하고 나타납니다.

‘여기까지 오느라 수고했어. 앞에서 배운 거 기억나지? 나는 여기에 쓰는 거야.’

그러면 무릎을 탁 치고는 개념을 복습하러 갑니다. 벌써 다 까먹었거든요(…) 그런 기억 없으신가요? 저는 특히 선형대수(Linear Algebra)가 그랬는데요, 컴퓨터 그래픽스나 정보검색 등 전혀 생각지도 못하던 분야에 활용되는 걸 보면서 기가 막혀했던 기억이 납니다. 그 후로는 새로운 개념을 공부할 때는 먼저 그 활용 분야부터 살피는 습관이 생긴 것 같아요. 책이나 위키피디아를 볼 때 뒤에서부터 훑어보는 이유도 바로 그런 것이고요.

쓰고 보니 책 소개는 없고 그냥 제 생각만 주저리주저리 늘어놓았군요. 그냥 마무리할게요. 가설을 먼저 세우고 검증해나가는 접근 방식이 생소한 분, 더 효과적으로 일하는 법을 배우고 싶은 분께 이 책을 추천합니다.