• Home
  • About
  • Bookmark
  • Library
  • Search
  •  

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

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

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

    1. 디버깅 (Debugging)

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

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

    2. 큰 그림

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

    보통은 소프트웨어를 먼저 만들고 그 후에 제대로 동작하는지 테스트 합니다. 그게 당연한 것 같죠? 그런데 테스트 주도 개발이라는 책에서 켄트 백은 그 순서를 바꿀 것을 제안합니다. 프로그램이 의도한대로 동작하는지 테스트하는 프로그램을 먼저 만들고, 그 다음에 진짜 프로그램을 만들자는 거죠.1

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

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

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

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

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

    1. 프로그램이라는 용어를 썼는데, 사실 완성된 소프트웨어보다는 이를 구성하는 각각의 모듈(module)을 구현하는 단계에 유용한 개념입니다. []

     이글과 관련이 있을지도 모르는 글

    1. 조엘 온 소프트웨어
    2. 해커와 화가 – 폴 그레이엄
    3. 멀티태스킹은 없다 – 데이비드 크렌쇼

    Tags: , , , , ,

    이글을 찾은 사람들이 쓴 검색어: 소프트웨어 관점 / 소프트웨어 서적 /

    5 Responses to “가설사고: 소프트웨어 개발자 관점에서”

    1. 가설사고, 생각을 뒤집어라…

      직장인이 습득해야 할 궁극의 업무 기술을 하나 꼽자면 무엇일까요? 전 문제해결기법(problem solving technique)을 꼽습니다. 문제해결기법 흔히 컨설팅 방법론이라 불리우지만, 보다 일반적인 명칭은 문제해결기법입니다. 아주 거칠게 간략화하면, 문제해결기법은 두 가지 기둥에 의지합니다. 논리적 사고 방식(logical thinking)과 가설 지향적 접근법(hypothesis-driven approach)입니다. 논리적 사고방식은 민토…

    2. inuit says:

      가설방법을 디버깅과 아키텍처나 프로그래밍에 적용해서 생각하다니 재미납니다.
      저도 덕분에 새로운 응용을 배웠습니다. ^^

      참고로 가설사고가 아니라 가설적 방법은 정말 폭넓게 응용이 가능하지요. 좋은글 고맙습니다. ^^

      • seunglee says:

        최근에 처음으로 분석 업무를 맡아서 좀 헤매고 있었는데, 덕분에 좋은 방법론을 알게 되었습니다. 이제부터 열심히 갈고 닦아서 든든한 무기로 만드는 건 저의 몫이겠죠. 댓글 고맙습니다.
        PS. 보내주신 트랙백이 스팸으로 분류되어 있길래 살려놨습니다 ^^

    3. [...] 때문에 지금 무엇을 해야 할지에 대한 실용적인 지침이 됩니다. 또한, 가설사고 책 소감에서 썼듯이 결과를 먼저 생각하는 접근법은 지금 하는 일의 의미를 큰 [...]

    4. [...] 가설사고를 적용하려고 할 때 가장 어려운 것은 바로 가설을 만드는 겁니다. 그 방법은 어떻게 가르쳐 주기도 애매해서 결국 스스로 경험과 노력을 통해 익히는 수밖에 없는 것 같습니다. 하지만 이런 가설 추론법이 아무런 이론적 근거도 없는 건 아니고, 퍼스(Charles Sanders Peirce)라는 미국 철학자가 귀추법(Abduction)이라고 분류한 바 있습니다. [...]

    Leave a Reply