Top

Debug It! 실용주의 디버깅 [소프트웨어 개발자가 꼭 알아야 할 디버깅의 정석]

  • 원서명Debug It!: Find, Repair, and Prevent Bugs in Your Code (ISBN 9781934356289)
  • 지은이폴 부처
  • 옮긴이박일
  • ISBN : 9788960771413
  • 25,000원
  • 2010년 06월 29일 펴냄 (절판)
  • 페이퍼백 | 268쪽 | 185*235mm

판매처

  • 현재 이 도서는 구매할 수 없습니다.

책 소개

고급 소프트웨어 엔지니어로 거듭나기 위해 꼭 필요하면서도 간과하기 쉬운 디버깅 기술. 개발 플랫폼에 무관하게 전문 소프트웨어 개발자가 디버깅에 대해 알아야 할 모든 이론과 지식, 실전 경험을 망라해둔 디버깅의 정석. 저자가 쌓아온 노하우와 디버깅 철학을 이 책에 모두 공개한다!


[ 소개 ]

직업 프로그래머는 한 치의 오차도 없이 버그의 근본 원인을 제거하는 기술을 익힌다. 디버깅 기술은 평소 버그 있는 코드를 생성하고 이를 수정하면서 얻는 경험에서 배울 수 있다. 이 책에는 저자가 그렇게 얻은 생생한 경험이 적혀있다. 이 책에서 얻은 실전 경험을 바탕으로 버그를 줄이고, 버그가 있더라도 훨씬 쉽게 찾을 수 있도록 코드를 작성하는 방법을 익힐 수 있다.

『Debug It! 실용주의 디버깅』은 확신을 가지고 버그를 잡는 데 도움이 될 만한 도구, 기법, 접근 방법을 제공한다.

전문 디버깅의 비밀은 버그의 전 과정, 즉 디버깅을 쉽게 할 수 있도록 소프트웨어를 만드는 것에서부터, 버그를 찾고 재현하고 진단하고 마지막으로 수정하는 과정까지를 전부 보여준다. 자바냐 기계어냐, 서버냐 임베디드 마이크로컨트롤러냐, 애자일이냐 전통적인 방법이냐에 상관없이 기본적인 버그 수정 원칙을 적용할 수 있다.

이 책에서는 소프트웨어만의 독특한 기능을 통해 실제로 어떤 일이 벌어지는지 보여줄 수 있는 경험주의적인 접근 방법, 안정적이고 편하게 버그를 재현할 수 있는 방법의 중요성, 공통적인 실수를 피할 수 있는 방법 등을 배울 수 있다. 흔히 사용되는 도구를 활용해 고객이 버그를 발견하기 전에 먼저 자동으로 찾을 수 있는지도 익힌다. 또한, 결정적인 내부 정보에 알아서 접근하고, 버그를 생성하는 깨진 가정이 어디인지 알려주는 '스스로 디버깅하는' 소프트웨어를 만들 수 있다.


[ 이 책의 구성 ]

■ 1부. 문제의 핵심
1부에서는 개발 중인 소프트웨어를 통해 내부에서 뭐가 어떻게 실행되는지를 보는 경험주의 접근법과, 이에 기반한 핵심 디버깅 방법(재현, 진단, 수정, 반영)을 소개한다.

■ 2부. 큰 그림
고쳐야 하는 문제가 있다는 걸 처음에 어떻게 찾을 수 있을까? 디버깅 과정을 소프트웨어 개발 프로세스 안에 어떻게 넣을 수 있을까?

■ 3부. 디버깅 비급
3부에서는 다음과 같은 좀 더 어려운 주제를 살펴본다.
• 1~2부에서 살펴본 방법들은 모든 버그에 적용할 수 있지만 특별한 조치를 해줘야 하는 버그도 있다.
• 디버깅은 해당 버그 때문에 열 받은 사용자가 불평 전화를 걸어오기 훨씬 전부터 시작한다. 특정 도구나 프로세스를 써서 이런 일을 미연에 방지할 수 없을까?
• 마지막으로 빠지기 쉬운 여러 가지 함정도 알아본다.

저자/역자 소개

[ 저자 서문 ]

디버깅에 관한 책은 왜 이렇게나 없는 걸까? 설계, 코드 구현, 요구 사항 분석, 방법론 같은 소프트웨어 엔지니어링 책은 참 많은데, 유난히 디버깅만큼은 아직까지도 저자나 출판사의 관심을 못 받고 있다. 이 책이 이런 현실을 조금이나마 개선할 수 있기를 바란다.

코드를 작성했다면 언젠가는 (아마 곧바로) 디버깅을 해야 할 것이다. 디버깅은 다른 무엇보다도 지적인 과정이다. 디버깅은 디버거나 코드로 하는 것이 아닌 머리로 하는 것이다. 문제의 근본 원인을 파악하는 것, 이것이 가장 근본이다.

나는 오랫동안 여러 팀에서 굉장한 사람들과 함께 일해 왔다. 비트 슬라이스(bit-slice) 프로세서에서 실행되는 마이크로 코드에서부터 디바이스 드라이버, 임베디드 코드, 메인스트림 데스크톱용 소프트웨어, 웹 애플리케이션까지 다양한 분야의 소프트웨어를 작업해왔다. 이렇게 동료들과 함께 얻은 교훈을 이 책에서 여러분과 함께 공유하고자 한다.


[ 저자 소개 ]

폴 부처(Paul Butcher)
비트 슬라이스 프로세서에서 돌아가는 마이크로 코드에서부터 고수준의 선언적 프로그래밍에 이르는 다양한 분야에서 일해왔다. 폴은 최신 기술을 개발하는 여러 훌륭한 개발 팀과 같이 일할 기회를 제공해 준 스타트업 회사 덕분에 이런 경험을 할 수 있었다.


[ 옮긴이의 말 ]

프로그래머의 하루 일과를 살펴본다면, 아마 '디버깅'하는 데 대부분의 시간을 보낼 것입니다. 우리가 코드를 한 줄 작성한 후에 제대로 돌아가는지 보기 위해 디버거를 실행하는 그 순간부터 이미 디버깅은 시작됩니다.

정말 그렇다면, 어째서 서점에는 디버깅 관련서를 찾아 보기 힘든 걸까요? 그나마 출간된 책들조차 대부분 특정 플랫폼에서 특정 툴이나 API를 어떻게 쓰는가를 다룰 뿐입니다. 대학이나 학원에서 디버깅을 배웠다는 얘기도 들어본 적이 없습니다.

('디버깅과 섹스의 공통점' 이라는 유머에서도 나온 얘기지만) 그 이유는 아마도 우리가 이미 디버깅을 잘 알고 있다고 생각하기 때문일 것입니다. 수영은 배우지만 뛰는 법은 배우지 않는 이유는 이미 우리가 어렸을 때 수없이 넘어지면서 뛰는 법을 스스로 배웠기 때문입니다. 마치 초보 개발자 시절에 코드 사이에 printf를 끼워넣고 F10으로 한 줄 한 줄 내려가면서 밤새워 버그를 잡아가며 디버깅을 독학한 것처럼 말이죠.

하지만 '전문가' 가 되려면 그냥 알고 있는 수준에서 머무르면 안 됩니다. 뛰는 법을 모르는 사람은 없지만 일반인과 육상선수 사이에는 엄청난 차이가 있습니다. 마찬가지로 디버거 사용법은 디버깅의 극히 일부입니다. 자동차 운전을 배웠다고 해서 바로 F1 레이싱에서 우승할 수는 없습니다. 그렇다면 '디버깅' 전문가가 되려면 무엇을 해야 할까요?

저는 '온라인 게임에서 사례로 살펴보는 디버깅'이라는 주제로 KGC(Korea Games Conference) 09와 NDC(Nexon Developers Conference) 10에서 발표를 했습니다. 겨우 10년차 개발자가 디버깅이라는 주제로 사람들 앞에서 발표를 할 수 있었던 가장 큰 이유는 제가 리니지2 서버개발팀에서 근무하고 있기 때문입니다. 다행인지 불행인지 리니지2가 오랫동안 많은 분의 사랑을 받아오면서 디버깅거리도 끊이질 않았습니다. 장애가 발생했을 때의 손실이 엄청나기 때문에 항상 긴장하면서 개발하지만 문제는 어김없이 튀어나옵니다. 그리고 문제를 해결하면서 새로운 무엇인가를 배울 수 있었습니다.

'디버깅' 발표를 준비하면서 주변에서 디버깅을 성공한 사람들을 관찰하기 시작했습니다. 왜 이 사람들은 다른 사람보다 빨리, 정확하게 버그를 찾을 수 있었을까? 계속 관찰하다 보니 몇 가지 패턴을 찾을 수 있었습니다.
• 무턱대고 디버거부터 실행하는 게 아니라, 어디가 문제일지를 생각하면서 디버깅 계획을 잡는다.
• 다양한 정보를 종합적으로 분석한다.
• 작은 이상증상도 놓치지 않는다.
• 설명이 안 되는 부분을 그냥 넘어가지 않는다.
등등...
덕분에 저의 디버깅 습관도 많이 좋아질 수 있었습니다.

저는 이 책 『Debug it! 실용주의 디버깅』을 원서로 5번, 번역하면서 다시 5번 넘게 읽었습니다. 그럼에도 불구하고 읽을 때마다 새로 느끼는 게 있었습니다. 저자 폴 부처는 이 책에 디버깅의 과정을 체계적으로 정리하고, 각 단계별로 다양한 사람들의 사례, 노하우, 실수로부터 배운 교훈들을 공유해뒀습니다. 어디에서도 듣기 힘든 살아있는 지식입니다. 게다가 재미있기까지 합니다. 이 책을 읽고 나면 스스로가 조금은 달라진 것을 느낄 수 있을 것입니다.


[ 옮긴이 소개 ]

박일
연세대 컴퓨터과학과를 졸업했다. ‘박피디의 게임 아키텍트 블로그(http://parkpd.egloos.com)’를 운영하고 있으며, 2000년에 개발을 시작해 지금은 리니지2 서버팀에서 근무하는 중이다. 옮긴 책으로는『스크럼』(2008), 『xUnit 테스트 패턴』(2010)이 있다.

목차

목차
  • 1부 문제의 핵심
  • 1장 구조적인 접근
    • 1.1 디버깅은 ‘버그를 없애는 것’ 그 이상이다
    • 1.2 경험주의 접근법
    • 1.3 핵심 디버깅 과정
    • 1.4 중요한 일부터 먼저
    • 1.5 실천하기
  • 2장 재현
    • 2.1 고민하기 전에 재현부터 해보자
    • 2.2 소프트웨어 제어
    • 2.3 환경 제어
    • 2.4 입력 제어
    • 2.5 재현 방법 다듬기
    • 2.6 정말로 재현할 수 없다면?
    • 2.7 실천하기
  • 3장 진단
    • 3.1 잠깐, 지금부턴 과학을 할 겁니다
    • 3.2 계략
    • 3.3 디버거
    • 3.4 실수
    • 3.5 심리전
    • 3.6 진단 확인
    • 3.7 실천하기
  • 4장 수정
    • 4.1 전투 준비
    • 4.2 테스트
    • 4.3 증상이 아닌 원인을 고친다
    • 4.4 리팩토링
    • 4.5 체크인
    • 4.6 코드 리뷰 받기
    • 4.7 실천하기
  • 5장 반영
    • 5.1 이게 어떻게 돌아가고 있었지?
    • 5.2 뭐가 잘못된 거지?
    • 5.3 다시는 이 문제가 생기지 않을꺼야
    • 5.4 선순환 구조 만들기
    • 5.5 실천하기
  • 2부 큰그림
  • 6장 문제 발견
    • 6.1 버그 추적
    • 6.2 고객과 작업하기
    • 6.3 지원 팀과 일하기
    • 6.4 실천하기
  • 7장 실질적인 무관용
    • 7.1 버그 우선순위
    • 7.2 디버깅할 때의 마음가짐
    • 7.3 품질 결함 수렁에서 빠져나오기
    • 7.4 실천하기
  • 3부 디버깅 비급
  • 8장 특수한 경우
    • 8.1 기존 릴리스 패치
    • 8.2 하위 호환성
    • 8.3 병렬
    • 8.4 하이젠버그
    • 8.5 성능 버그
    • 8.6 임베디드 소프트웨어
    • 8.7 서드파티 소프트웨어 버그
    • 8.8 실천하기
  • 9장 이상적인 디버깅 환경
    • 9.1 자동 테스팅
    • 9.2 소스 관리 시스템
    • 9.3 자동 빌드
    • 9.4 실천하기
  • 10장 소프트웨어가 스스로를 디버깅하게 만들기
    • 10.1 가정과 단언문
    • 10.2 디버깅 빌드
    • 10.3 자원 누수와 예외 처리
    • 10.4 실천하기
  • 11장 안티 패턴
    • 11.1 우선순위 인플레이션
    • 11.2 프리마돈나
    • 11.3 유지 보수 팀
    • 11.4 화재 진압
    • 11.5 새로 작성하기
    • 11.6 코드 주인의식 실종
    • 11.7 흑마술
    • 11.8 실천하기
  • 부록 A 자원
    • A.1 소스 관리 시스템과 이슈 추적 시스템
    • A.2 빌드와 지속적인 통합 도구
    • A.3 유용한 라이브러리
    • A.4 다른 도구

관련 블로그 글

디버깅과 테스팅의 교본『Debug It! 실용주의 디버깅』
사용자 삽입 이미지
Debug It! 실용주의 디버깅
소프트웨어 개발자가 꼭 알아야 할 디버깅의 정석
폴 부처(Paul Butcher) 지음 | 박일 옮김
2010년 6월 29일 출간예정 | 268쪽 | 25,000원
 YES24, 교보문고, 인터파크, 강컴, 알라딘


1. 잘하면 재미있지만, 잘못하면 짜증난다.
2. 힘들다.
3. 하면 할수록 늘지만, 너무 자주 하는 건 싫다.
4. 밤에 할 때가 많다.
5. 대놓고 얘기하긴 부끄럽다(얘기할 때는 몇 배 부풀린다).
6. 다들 궁금해한다.
7. 책이 별로 없다.


무슨 이야기일까요? 아무래도 좀 난~한 이야기이긴 하지만, 미성년자가 저희 책을 사볼 일은 거의 드물(?) 테므로, 밝히자면, 이 책『Debug It! 실용주의 디버깅』의 역자 박일님이 자신의 블로그 "박피디의 게임 아키텍트 블로그'에 올렸던 '디버깅과 섹스의 공통점'이라는 블로그 글에서 발췌한 내용입니다. 7가지만 추렸지만, 블로그 글을 읽어보시면 역자분이 밝힌 20가지 외에도 수많은 분들이 공통점을 올려주셨네요. 재미있는 예제 글이었습니다. 하지만 실전에선 후자는 누가 알려주지 않아도 몸으로 익히면 그만이고 뭔가를 추구하는 데 어려움이 없는 반면, 디버깅은 개발자들을 졸졸 쫓아다니는 족쇄같은 것으로 뿌리치기도 힘들고 제대로 알기도 어려운 것이 아닐가 싶습니다.

소프트웨어 개발 분야가 발달하고 번창함에 따라 각종 기술과 개발방법론에 대한 책은 엄청나게 쏟아져 나오고 있습니다. 그러나 그 중에서도 유일하게, 이론으로 정립된 서적이나 문헌이 드문 분야가 디버깅 분야가 아닐까 싶습니다. 최근 들어 테스팅 관련 서적이 드물지 않게 쏟아져 나오고 있어서 이에 대한 갈증을 메워주는 역할을 합니다. 그리고 디버깅 관련서적도 심심치않게 보이는 건 사실입니다.

저희 에이콘에서만도 "리눅스 디버깅과 성능 튜닝", "실전 윈도우 디버깅", "메모리 분석과 활용 제1권", "WinDbg로 쉽게 배우는 Windows Debugging" 등 수 권의 디버깅 관련 서적을 출간했습니다. 도구에 관한 설명이나 실제 코드 예제 등을 들어가며 설명하기에 실전에서 활용하기에 충분한 책입니다. 그러나 제목에서 알 수 있듯이 리눅스나 윈도우 등 특정 플랫폼에서 적용가능한 책인 경우가 많아 전체적인 개념을 익히기에는 뭔가 아쉬운 점이 있었습니다.

이 책 『Debug It! 실용주의 디버깅』은 아무도 속시원히 알려주지 않았고, 개발자들을 여간 괴롭히지 않았던, 이론을 정립하기도 실전에서 제대로 활용하기도 너무 힘들었던 디버깅에 관한 모든 것을 알려줍니다.

1부. 문제의 핵심, 2부. 큰그림, 3부. 디버깅 비급 세 부분으로 나뉜 이 책이 돋보일 수밖에 없는 이유는 이 책의 세부 내용을 구성한 방식에 있습니다.

이 책에서 저자 폴 부처는 난해하고도 어려운 갖가지 디버깅 이론과 실제, 그 철학을 설명하는 데 있어 실전적인 방법을 차용합니다. 우선 저자를 비롯한 개발자들이 현장에서 부딪힌 갖가지 수많은 사례들을 보여줍니다.

일례로 두 가지를 들려드릴까요. 프린터 디바이스 드라이버를 개발한 뒤 출력물에 이상한 가로줄이 생기는 버그를 테스팅 팀에게서 신고 받은 개발자 데이브의 일화. 자신의 사무실에서 아무리 프린트를 해봐도 이상한 점을 발견할 수가 없었고, 테스트 환경과 개발 환경에도 별 차이점이 없습니다. 결국 "사무실 위층에 귀신이 살고 있다"라고밖에 주장할 수 없었지요. 그러나 결국 면밀한 조사 끝에 개발사 사무실 전기 배선에 문제가 있었음을 발견합니다. 전력 문제로도 이런 버그가 발생할 수 있음을 알려주는 재미있는 일화지요.

또 하나의 일화. 마이크로소프트 사 인턴으로 취업해 엄청난 삽질을 한 한 개발자의 이야기도 있습니다. CodeView라는 디버거 팀에서 일을 하며 당시 출시전인 C 컴파일러(마이크로소프트 C/C++ 7.0)의 버그 탐색 과정에 들어간 혈기 넘친 젊은 개발자. 왕성한 의욕으로 몇 천 줄이 넘는 소스파일의 전처리 결과에 대한 버그 리포트를 올립니다. 하지만 일주일 지나 엄청난 노력을 기울인 그의 버그 리포트는 중복 판정을 받게 됩니다. 버그 리포트를 훑어보는 일이 얼마나 중요한지 그제서야 알게 되죠.

이처럼 디버깅이란, 우리가 지금까지 알고 있듯이, 너무 멀리 있지도 않으며 아주 어려운 것도 아닙니다. 수많은 변수가 있을 수 있으며 '등잔 밑이 어둡다'는 말처럼 주변의 사소한 것들에 신경을 쓰면 쉽게 찾을 수 있는 것도 많습니다. 이를 위해 저자는 독자들이 흥미와 호기심을 자아낼 수많은 일화와 사례, 그리고 '조(Joe)란느 개발자의 질문'을 통해 누구나 궁금해왔던 버그에 관한 질문을 재미있게 답해줍니다. 또한 두 줄짜리 핵심 요약을 통해 해당 단락과 절을 요약해 디버깅의 핵심을 알려줍니다.

<조의 질문> 몇 가지
1. 코드에 로그를 남겨놔야 할까요?
2. 비결정적 버그가 왜 문제가 되나요?
3. 일일노트가 디버깅에 어떤 도움이 될까요?
4. ‘땜질 코딩’도 괜찮나요?
5. 꼭 컴퓨터로 버그를 추적해야 할까요?
6. 병목이 없다면 어떻게 하죠?
7. 어떻게 하면 경고를 전부 없앨 수 있을까요? ...... and much more

이처럼 여러분이 궁금해하셨던 내용이 이 책에 모두 담겨있습니다.

<핵심 요약> 몇 가지
1. 디버깅은 반복 과정이다.
2. 소프트웨어의 작동에 영향을 미칠 수 있는 것이라면 무엇이든 소프트웨어의 환경이 될 수 있다.
3. 많은 실험을 빠르게 해보는 게 좋다.
4. 동시에 여러 개를 변경하면 잘못된 결론에 이를 수 있다.
5. 뭐든지 우리가 이해하지 못하는 부분은 잠재적인 버그다.
6. 디버깅은 순간이지만 테스트는 남는다.
7. 고쳤을 때 아무런 효과가 없다면 원했던 부분을 고친 게 아니다.
8. 깨끗한 소스에서 시작한다. ...... and much more

그야말로 재미와 얻을거리의 관점에서 저희 출판사의 '조엘 온 소프트웨어'와 인사이트에서 출간한 '실용주의 프로그래밍'에 버금가는 디버깅의 완전 교본이라고 할 수 있습니다.

고급 소프트웨어 엔지니어로 거듭나기 위해 꼭 필요하면서도 간과하기 쉬운 디버깅 기술. 개발 플랫폼에 무관하게 전문 소프트웨어 개발자가 디버깅에 대해 알아야 할 모든 이론과 지식, 실전 경험을 망라해둔 디버깅의 정석. 저자가 쌓아온 노하우와 디버깅 철학을 이 책에 모두 공개한다!

xUnit 테스트 패턴』의 번역을 마칠 즈음인 어느 날, 호기 있게 이 책의 출간을 적극 권유해주신 박일님의 이 책에 대한 애정은 매우 깊었습니다. 디버깅 서적 시장이 협소함에도 불구하고, 모든 개발자의 필독서로서 우리 땅에서 반드시 출간해야 할 책이라고 일갈하시는 역자님의 열정에 저희도 설득될 수밖에 없었구요. 번역 출간을 앞둔 지금, 박일님의 주장은 한 치도 어긋남이 없을 것이라 믿습니다.

리눅스든 윈도우든 어떤 플랫폼이든 상관없이 모든 소프트웨어 개발자가 꼭 읽으시고, 자신의 내공을 업그레이드하기에 2% 부족했던 그 간극을 메우실 훌륭한 책으로 자리매김하게 되길 바랍니다.

이 책은 지금 YES24, 교보문고, 인터파크, 강컴, 알라딘에서 예약판매 중입니다.

CC

크리에이티브 커먼즈 라이센스 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안