87

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

  • View
    241

  • Download
    15

Embed Size (px)

DESCRIPTION

자레드 리차드슨, 윌리엄 그월트니 주니어 지음 | 최재훈 옮김 | IT Leaders 시리즈 _ 002 | ISBN: 9788995856468 | 20,000원 | 2007년 08월 9일 발행 | 280쪽

Citation preview

Page 1: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드
Page 2: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

Ship It! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

자레드 리차드슨·

윌리엄 그월트니 주니어·

최재훈

Page 3: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

iv

추천의 글 xvi

서 문 xviii

1장 서론 1

1.1 습관화된 탁월함 ............................................. 2

1.2 실용주의적 관점 ............................................. 4

1.3 로드맵 ..................................................... 6

인프라스트럭처 .................................................... 6

기법 ......................................................... 8

프로세스 ......................................................... 8

흔하게 벌어지는 문제와 문제를 해결하는 법 ............................ 8

무엇이 빠졌는가? ................................................. 9

1.4 앞으로 나아가기 ............................................. 10

1.5 이 책을 어떻게 읽어야 하나? ................................... 10

여러분이 개발자이거나 테스터라면 ................................... 10

여러분이 프로젝트 팀 리더라면 ...................................... 11

여러분이 관리자거나 깊게 관련된 고객이라면 ........................... 12

개인이 모여 팀을 이룬다. ........................................... 12

2장 도구와인프라스트럭처 17

아무도 프레드가 겪은 문제를 알지 못한다. ........................... 18

여러분의 하루는 어떻게 다를까요? .................................. 19

프레드가 빠진 함정에 걸리지 말자. .................................. 21

목 차

Page 4: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

v

[01] 모래 상자(Sandbox) 안에서 개발하기 .......................... 23

[02] 자산을 관리하세요 ........................................... 27

저 개가 내 소스 코드를 먹어버렸어요. ................................ 29

어떻게 시작하면 될까요? ........................................... 30

내가 제대로 하고 있는 걸까요? ...................................... 31

경고 신호 ........................................................ 32

[03] 빌드를 스크립트화 하세요. .................................... 34

어떻게 시작하면 될까요? ........................................... 38

내가 제대로 하고 있는 걸까요? ...................................... 39

경고 신호 ........................................................ 39

[04] 자동으로 빌드하세요 .......................................... 40

프리젠테이션 ..................................................... 43

어떻게 시작하면 될까요? ........................................... 44

제대로 사용하고 있는 걸까요? ....................................... 45

경고 신호 ........................................................ 46

[05] 이슈를 추적하세요. ........................................... 46

어떻게 시작하면 될까요? ........................................... 49

제대로 사용하고 있는 걸까요? ....................................... 50

경고 신호 ........................................................ 51

[06] 기능을 추적하세요 ............................................ 52

어떻게 시작하면 될까요? ........................................... 53

제대로 사용하고 있는 걸까요? ....................................... 54

경고 신호 ........................................................ 54

[07] 테스트 장비를 사용하세요. .................................... 55

어떻게 시작하면 될까요? ........................................... 62

제대로 사용하고 있는 걸까요? ....................................... 63

경고 신호 ........................................................ 64

[08] 도구를 선택하는 방법 ......................................... 64

[09] 실험하지 말아야 할 때 ........................................ 66

Page 5: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

vi

3장 실용주의적프로젝트기술 69

[10] 목록에 따라 일하세요 ......................................... 71

왜 목록이 필요할까요? ............................................. 73

목록을 어떻게 사용해야 할까요? ..................................... 74

누구나 사용할 수 있어야 합니다. ..................................... 77

우선순위를 부여해야 합니다. ........................................ 78

시간 예측 ........................................................ 79

죽어 있는 문서가 아닌 살아있는 문서여야 합니다. ...................... 79

측정 가능해야 합니다. ............................................. 80

목표가 있어야 합니다............................................... 82

목록이라면 이래야 합니다. ......................................... 83

이렇게 시작하세요. ................................................ 83

이렇게 하고 있다면 제대로 하고 있는 겁니다. ......................... 84

경고 신호 ........................................................ 84

[11] 기술 리더 .................................................. 86

기술 리더가 필요한 이유 ............................................ 86

기술 리더의 책임 .................................................. 88

팀이 나가야 할 방향을 설정합니다. ................................... 89

프로젝트의 기능 목록을 관리합니다. .................................. 89

기능 요구사항에 우선순위를 부여합니다. .............................. 90

정신을 산만하게 만드는 외적인 요소로부터 팀을 보호합니다. ............. 92

‘목록’은 어떻게 만드나요? .......................................... 93

기술 리더는 어떤 사람일까요? ....................................... 94

이렇게 시작하세요. ................................................ 94

이렇게 하고 있다면 제대로 하고 있는 겁니다. ......................... 96

경고 신호 ........................................................ 96

[12] 매일 협력하고 의사소통하기 ................................... 97

일일 회의가 필요한 이유 ............................................ 97

일일 회의가 좋은 이유 .............................................. 98

Page 6: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

vii

또 엉뚱한 일을 하네 ................................................ 99

바퀴를 다시 발명하기 .............................................. 99

회전초 개발자 ..................................................... 100

전문지식 증폭기 .................................................. 101

팀 커뮤니케이션 ................................................... 101

큰 그림 그리기 .................................................... 102

대안 ......................................................... 103

일일 회의는 이래야 합니다. ........................................ 104

이렇게 시작하세요. ............................................... 105

초점을 놓치지 마세요. ............................................. 106

이렇게 하고 있다면 제대로 하고 있는 겁니다. ......................... 107

경고 신호 ........................................................ 108

[13] 코드를 모두 검토하세요 ....................................... 110

이렇게 시작하세요. ............................................... 120

이렇게 하고 있다면 제대로 하고 있는 겁니다. ......................... 120

경고 신호 ........................................................ 121

[14] 코드 변경 통지 보내기 ........................................ 122

예상치 못한 이점 .................................................. 124

모든 사람에게 코드 통지를 보내세요. ................................. 124

코드 통지를 무시하고 싶다면 그렇게 하세요. ........................... 125

이렇게 시작하세요. ............................................... 125

이렇게 하고 있다면 제대로 하고 있는 겁니다. ......................... 127

경고 신호 ........................................................ 127

[15] 모두 통틀어서 ............................................... 128

4장 예광탄개발 131

예광탄 개발 ....................................................... 131

프로세스 상의 흔한 문제들. ......................................... 132

프로세스 정의하기 ................................................. 133

Page 7: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

viii

TBD는 어떻게 작동할까요? ......................................... 135

시스템 객체를 정의하세요 ........................................... 137

협동해서 인터페이스 정의하세요 ..................................... 140

인터페이스 스텁을 작성하세요. ..................................... 143

계층끼리 대화할 수 있게 만드세요. .................................. 145

스텁에 기능적 코드를 채워 넣으세요. ................................ 147

리팩토링하고 다듬으세요. ........................................... 149

간단한 사례 ....................................................... 152

예광탄 개발 방법론 홍보하기 ........................................ 155

이렇게 시작하세요. ............................................... 159

이렇게 하고 있다면 제대로 하고 있는 겁니다. ......................... 160

경고 신호 ........................................................ 160

5장 일반적인문제와해결방법 161

[16] 도와주세요! 코드를 인수받았어요. .............................. 162

[17] 테스트할 수 없는 코드를 테스트하기 ............................. 164

[18] 기능에 문제가 계속 발생합니다. ............................... 166

[19] 테스트? 우리는 더 이상 테스트를 활용하지 않습니다. ............. 168

[20] 하지만 저는 된다구요! ......................................... 170

[21] 코드를 통합할 때 골치 아픕니다. ............................... 171

[22] 제품을 안정적으로 빌드하지 못합니다. .......................... 173

[23] 고객이 불만을 표출합니다. .................................... 175

[24] 불한당 개발자가 있습니다. .................................... 177

관리자의 관점 ..................................................... 177

[25] 관리자가 불만스러워 합니다. .................................. 181

상사가 매 시간 와서 상황이 어떻게 돌아가나 물으면 어떻게 할까요? ....... 182

[26] 팀이 협동을 못합니다. ........................................ 183

Page 8: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

ix

[27] 핵심적인 부분에 대한 ‘내부의 지지’를 얻지 못합니다. .............. 184

관리자의 관점 ..................................................... 184

개발자의 관점 ..................................................... 186

고객의 관점 ...................................................... 186

[28] 새로운 실천방법이 도움이 안 됩니다. ............................ 188

새로운 실천방법을 도입해선 안 될 시기. ............................... 188

새로운 실천방법을 도입하는 방법 ..................................... 189

[29] 자동화된 테스트가 없습니다. ................................... 192

[30] 우리는 신참 개발자들이고 이끌어줄 사람이 없습니다. ............. 194

[31] ‘죽음의 행진’ 프로젝트에 참여하고 있습니다. ..................... 195

[32] 피쳐 크리프(Feature Creep) 현상이 일어납니다. ............... 197

[33] 프로젝트가 끝날 기미가 안 보입니다. ............................ 198

개발자의 관점 ..................................................... 200

관리자의 관점 ..................................................... 200

고객의 관점 ....................................................... 201

부록 A TIP 조언 요약 .......................................... 203

부록 B 소스 코드 관리 .......................................... 205

부록 C 빌드 스크립트 도구 ...................................... 209

부록 D 지속적인 통합 시스템 .................................... 215

부록 E 이슈 추적 소프트웨어 .................................... 219

부록 F 개발 방법론 ............................................. 223

부록 G 테스트 프레임워크 ....................................... 227

부록 H 추천 도서 목록 .......................................... 233

찾아 보기 ....................................................... 239

Page 9: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

x

“운이 좋았다.”

닷컴 신화를 이끌었고 이제는 수백억 대 자산가가 된 CEO를 모시고 비결을 물었습니다.

세미나에 참석한 학생은 의욕이 넘쳤고, CEO가 뭔가 멋진 대답을 해주리라 기대하는

눈치가 역력했습니다. 하지만 대답은 “운이 좋았다”라는 한마디였습니다.

“운이 좋았다.”

“『Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드』를 어떻게 번역하

게 됐냐?”라고 친구가 물었을 때, 저는 그 CEO마냥 똑같은 대답을 했습니다. 생각해

보면 인터넷 서점 아마존에서 원서를 우연히 보게 됐을 때부터 묘한 인연이 시작됐습니

다. 단지 원서치고 가격이 싸다는 이유만으로 산 책이었습니다. 다행히도 책 복이 있는

지, 책을 받아 읽어보니 기대하지도 않았던 대어를 잡은 기분이었습니다. “다른 사람도

이렇게 훌륭한 책을 알아야 한다”는 사명감에 불타 블로그에 서평을 올린 덕분에 출판

사 위키북스와 인연이 닿게 됐습니다. 하지만 번역을 결심하기까지도 우여곡절이 있었

고 훌쩍 한 해를 넘겼습니다. 그러던 것이 어쩌다 보니 번역을 마치고 역자 서문까지 쓰

고 있는 자신을 발견하게 됐습니다.

요즘은 좋은 번역서가 정말 많습니다. 출판업계 동향을 보면 해외에서 출판된 지 1년

도 안 돼서 한국에 소개되는 책도 많습니다. 훌륭한 책을 빨리 접할 수 있게 된 독자에

겐 정말 행복한 일입니다. 그에 비해 이 책의 원서는 2005년 1월에 초판이 출판되었으

니 어찌 보면 너무 늦게 소개되는 것은 아닌가 하는 생각마저 듭니다. 하지만 이 책은

읽어볼 만한, 아니 읽어봐야 할 책입니다.

역자 서문

Page 10: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xi

개발 경험이 풍부한 자레드와 윌의 조언을 듣고 있자면, “아, 이렇게 하는 거였어?”라

는 감탄사가 절로 튀어나옵니다. 개발자의 관점에서, 기술 리더의 관점에서, 관리자의

관점에서, 그리고 이해관계자의 관점에서 프로젝트를 어떻게 보고 어떻게 다뤄야 하는

지 속 시원하게 밝혀내는 두 사람의 재주가 부러울 따름입니다. 뉴질랜드에서 요트를

타고 돌고래들과 어울려 노는 것도 좋지만, 그 전에 『Ship it! 성공적인 소프트웨어 개

발 프로젝트를 위한 실용 가이드』만한 책을 펴낼 수 있다면 좋겠습니다.

아무쪼록 『Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드』가 제게

주었던 영감과 지식을 여러분도 가져갈 수 있기를 바랍니다. 그리하여 여러분이 신입

개발자에서 기술 리더가 됐을 때, 기술 리더에서 관리자가 됐을 때, 그리고 관리자에서

경연진이 됐을 때, 한국의 모든 소프트웨어 종사자들이 보다 즐거운 하루하루를 보내게

되기를 기원합니다.

2007년 7월, 마지막 활자를 타이핑하며

최재훈

Page 11: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xii

자레드 리차드슨 ㅣ Jared Richardson

자레드 리차드슨은 관리자로 전향한 개발자이다. 그는 모든 걸 위임해버리고 살금살금

빠져나가서 지난 10년간 그래왔듯 코드를 실제로 작성하는 날이야말로 좋은 날이라고

생각한다. http://www.jaredrichardson.net/index.html

윌리엄 그월트니 주니어 ㅣ William Gwaltney Jr.

윌리엄 그월트니 주니어는 20년 이상의 경험을 가진 소프트웨어 개발자이다. 당시에

그는 모든걸 경험해보진 못했어도 경험해 볼만한 건 다 경험해봤다.

자레드와 윌은 현재 세계에서 가장 큰 개인 소유의 소프트웨어 회사인 SAS 주식회사에

서 일하고 있으며 www.PragmaticProgrammer.com을 통해 지은이들을 만나볼

수 있다.

저자 소개

Page 12: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xiii

최재훈 ㅣ http://kaistizen.net, [email protected]

한국과학기술원(KAIST) 전산학과를 이제 막 졸업하고 SK 아이미디어에서 게임 개발

에 뛰어들었다. 스타크래프트를 9년째 즐기고 있지만, 여전히 무한맵 신봉자이며 자칭

무한맵의 초고수다. 시드마이어의 문명과 듄(Dune)의 후속작을 손꼽아 기다리고 있

다. 1년 6개월째 마이크로소프트웨어에 칼럼을 써왔으며 ‘프로그래밍 노트’ 및 ‘커뮤니

티 노트’ 등을 맡아왔다. 인간성이 고리타분한지라 일과 글에서 만큼은 위트를 발휘하

려고 애쓰는 중이다. 아직까진 잘 안 되고 있지만, 나아지리라 믿는다. 아직 멀었다고

생각하지만 정년이 되면 뉴질랜드에서 요트를 타고 돌고래들과 어울려 노는 게 꿈이다.

원대한 계획이라 은퇴자금 마련을 어떻게 해야 하나 고민중이다. 『Ship it! 성공적인

소프트웨어 개발 프로젝트를 위한 실용 가이드』가 역서로는 처녀작이며 선배 번역자들

에게 누를 끼치지 않으려고 최선을 다했다. 블로그를 통해 개발 경험을 나누고, 즐겁게

읽은 책 소개도 하고 있다.

역자 소개

Page 13: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xiv

추천의 글

이 책 외에도 서점 진열장엔 소프트웨어 개발 방법을 다룬 책은 많습니다.

사실, 소프트웨어를 설계하고 만드는 방법을 다룬 책이 많을 뿐더러, 책마다 이야기

하는 게 다르기도 합니다. 불행한 일이지만, 이 같은 접근방법상의 불화는 빛보다는 열

을 더 만들어냅니다. 현장실무자인 우리는 밝은 불빛을 보지 못하고 화상만 입고 끝날

뿐입니다. 아, 그런데다가 우리가 참여하는 프로젝트는 여전히 늦게 끝나겠죠.

우리는 우리 자신과 팀에게 알맞은 더 나은 소프트웨어 개발 방법을 계속 찾아왔습니

다. 하지만 다양한 개발 방법의 장단점을 토론하다 보면 이미 확립된 도그마에 주로 근

거를 둔 고함치기 대회가 되기 일쑤였습니다. 사전에선 도그마를 ‘권위를 내세우지만

그에 합당한 근거는 없는 견해’라고 표현합니다. 이런저런 방법론을 옹호하는 사람들이

자신의 접근방법만이 소프트웨어를 개발하는 올바른 방법이라고 주장할 때마다 우리는

도그마를 확인합니다. 특정 방법만 고집하는 현장실무자에 대한 이야기도 끊임없이 들

려옵니다. 그 방법론이 팀이나 조직에 해가 될 것이 분명할 때조차 말입니다.

진실을 말하자면, 소프트웨어를 개발하는 ‘올바른 방법’ 같은 건 없습니다. 잘못된 방

법은 많지만 모든 프로젝트에, 모든 사람에게, 언제나 통하는 방법론, 접근방법, 철학

이나 도구란 단 하나도 없습니다. 소프트웨어는 사람이 만드는데, 세상에 똑같은 사람

은 없습니다.

그러니 우리는 소프트웨어 개발 실천방법에 대해 실용적인 입장을 견지하려 합니다.

목표에 집중하려 합니다. 우리가 정말로 시그너처 한 뭉텅이를 원하는 걸까요? 아니면

사람들이 이해하길 원하는 걸까요? 어느 날 갑자기 코드 뭉치를 벽에 던져놓고 싶은 걸

까요? 아니면 사람들이 일하는 걸 도와주는 소프트웨어를 만들고 싶은 걸까요?

Page 14: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xv

우리는 새로운 방법을 기꺼이 시도하고 끊임없이 우리의 실천기법을 재평가하고 고쳐

나갈 겁니다. 우리한테 효과적인 방법을 찾길 원합니다. 하지만 그러려면 할 일이 많습

니다. 연구를 많이 해야 하고 엄청난 시간을 투자해야 하는데, 일하는 프로그래머 대부

분은 그럴 시간이 없습니다.

이 때문에 저는 자레드와 윌이 쓴 책의 주제를 주목하게 됐습니다. 이 책은 신뢰할만

한 코드를 규칙적으로 생산해내는 데 필요한 기본적이고 효율적인 도구와 기법을 알려

주는 지침서입니다.

자레드와 윌은 우리가 쓴 『실용주의 프로그래머』를 처음 읽은 독자층에 속하고, 책의

교훈을 마음 깊이 새겼습니다. 자레드와 윌은 대중적인 기민한(Agile) 방법론의 실천

기법과 더불어 우리의 접근방법과 기법을 사용했고, 작은 벤처기업에서부터 세계에서

가장 큰 개인 소유의 소프트웨어 기업을 돌아다니며 자신들에게 효과적이었던 방법을

다듬었습니다.

자레드와 윌은 자신들이 가장 선호하는 기법(technique)과 실천기법(Practice)을

이 책에 적어놨습니다. 이 책의 정보만 있으면 개발 프로세스를 개선하는 수고를 많이

덜 수 있습니다. 어쩌면 ‘실용주의 시작 도구’(Pragmatic Starter Kit) 시리즈로부

터 기술적인 세부사항을 보강할 수 있을지도 모릅니다. 시간이 흐름에 따라, 범위를 넓

혀서 다른 실천기법이나 기법을 실험해보고 싶어질 수도 있습니다. 결국, 그런 게 실용

주의적 방법입니다. 오늘 이 순간, 자신에게 가장 잘 맞는 걸 찾는 겁니다.

저는 이 책이 여러분에게 도움이 되어서, 의자에 맘 편히 기대어 앉아 시스템에게 “만

들어내!”라고 말할 수 있을 경지에 이르게 해줬으면 하고 바랍니다.

앤디 헌트 ㅣ [email protected]

The Pragmatic Programmers, LLC (실용주의 프로그래머, 유한책임회사)

2005년 4월

Page 15: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xvi

여러분이 자기 자신과 자신의 경력을 위해 할 수 있는 가장 현명한 투자 중 하나는 주변

에 적절한 사람을 두는 겁니다. 사람이야 말로 우리가 찾을 수 있는 가장 멋진 자원입

니다. 적절한 사람이란 여러분이 하고 싶은 일이나 여러분이 배우고 싶은 일을 벌써 하

고 있는 사람입니다. 여러분이 하길 원하는 일을 정확히 해낼 수 있는 사람을 찾으세요.

그렇지 않으면 최소한 일을 어떻게 하면 될지 알아낼 수 있는 정말 똑똑한 사람을 찾으

세요. 그들 주변에서 최대한 많은 시간을 보내세요. 그들을 도우면서 배워나가고, 그

사람들이 여러분을 돕게 만드세요. 이 정도 급의 사람과 시간을 보내면 일을 배워서 더

잘하게 됩니다(여러분이 하는 일이 뭐든 간에요).

이것은 훌륭한 생각입니다. 하지만 최고이면서 똑똑한 사람 중에서도 정말 최고인 사

람과 직접 만나기는 힘듭니다. 마틴 파울러, 켄트 벡, 그리고 실용주의 프로그래머들과

같은 사람은 우리 대부분에게 시간을 내주지 못합니다. 하지만 그 사람들의 책, 기사,

그리고 프리젠테이션은 그럴 수 있습니다. 그러니 책을 읽으세요. 한 달에 한 권이라면

그렇게 힘들진 않습니다. 하지만 거기서 멈추진 마세요. 새로운 프로그래밍 언어를 배

우거나 다른 개발 프로세스를 연구해보세요. 그리고 뭔가를 배우는 중간이나 책을 읽는

와중에도, 새로운 아이디어를 지금 업무에 적용할 방법을 찾아보세요. 새 아이디어를

본업에 적용해보세요. 그렇게 하면 회사를 개선시키는 데 도움이 될 뿐만 아니라 (더 중

요한 일인데) 여러분 자신 또한 개선시키게 됩니다.

새로운 아이디어를 접하세요. 머리를 짜내서 새 아이디어를 지금 하는 일에 적용할

방법을 찾으세요. 포기하고 새로운 아이디어가 쓸모없다고 말하긴 쉽습니다. 하지만

다른 방식으로 생각하는 법을 배우는 게 목표입니다. 틀에서 벗어나세요(아니면 적어도

그 틀을 넓히든가요). 서로 관련 없는 개념과 아이디어를 겹치는 법을 배우세요.

서 문

Page 16: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xvii

주변여건과 프로세스를 분석하고 비판하면 약점을 찾아낼 수 있습니다. 어쩌면 지금

프로젝트를 개선시키는 데 도움이 될지도 모릅니다. 아니면 다음 프로젝트에서라도요.

어떻게 되든 생각하는 법을 새로 배우게 될 텐데, 여러분이 어디서 일하든 쓸모 있을 겁

니다. 대부분의 사람은 이런 개념을 결코 배우지 못하고, 훨씬 적은 수의 사람만 잘 해

냅니다.

그러니 이 책의 각 섹션을 다 읽고 나면, 잠시 멈추고 5분 정도 투자해서 오늘 하는

일에 각 개념을 적용할 방법을 찾으려 애써보세요. 잊지 마세요. 애써 생각하지 않아도

나오는 가장 쉬운 해답은 ‘그건 할 수 없어’라는 말입니다. 그보단 더 노력하세요! 새 개

념을 적용할 방법을 찾지 못했다면, 동료를 붙잡고 물어보세요. 자신의 눈으로 보지 못

한다면, 다른 사람의 눈으로 보면 됩니다. 동료의 경험을 활용하는 법을 배우는 것은

어느 분야에서든 장인의 보증수표입니다.

이 책에서(그리고 ‘실용주의 시작 도구’ 시리즈 전체에서) 읽은 걸 가져다가, 자신이

하는 일의 모든 개념을 적용할 방법을 찾아보세요. 이 책을 읽음으로써 직접적인 이익

을 보게 되겠지만, 그 중에서도 여러분이 가져갈 수 있는 가장 큰 이익은 새로운 개념을

적용하는 방법을 배우는 연습일 겁니다.

즐겁게 읽기 바랍니다.

감사의말

먼저 ‘실용주의 프로그래머’ 시리즈에 책을 싣게 해준 앤디와 데이브에게 감사의 인사를

하고 싶습니다. 앤디와 데이브를 위해 책을 쓰는 건 특권이었습니다. 앤디, 특히 당신

은 의무를 넘어서 우리와 여러 시간을 보내며 원고를 봐주고, 글쓰기에 대해 집중강의

를 해줬으며, 때때로 (확신하건대) 우리의 글쓰기 재능에…. 음… 눈살을 찌푸려 줬습

니다.

Page 17: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xviii

데이브, 당신은 책 조판 시스템과 마크업 언어의 세부내용에 대해 묻는 수많은 이메

일에 때를 가리지 않고 답장해줬습니다. 앤디와 데이브 모두 고맙습니다! 더할 나위 없

이 귀중한, 상세하고 건설적인 피드백을 해준 훌륭한 검토자와 공헌자도 많았습니다.

여러분들의 도움이 없었더라면 이 책을 만들어내지 못했을 겁니다. 수잔 헨쇼와 짐 와

이스는 시간을 들여 세련되지 못한 문장을 검토해줬고, 여러 번 읽어줬습니다. 고맙습

니다.

마이크 클라크, 데이비드 복, 켄 푸, 도미닉 플란테, 저스틴 맥카시, 알 츄, 브라이

언 유뱅크스, 그레이엄 브룩스, 그랜트 브레머, 게리 세몬즈, 조 페어, 마크 도너휴,

로버트 지아나시, 롭 사틴, 쉐 에리슨, 스테판 슈미들, 그리고 앤디 레스트에게도 감사

합니다. 여러분 중 몇 명은 아주 이른 시기부터 고생했고, 최근엔 읽었던 걸 다시 읽게

해서 미안한 마음입니다. 진심으로 말하건대, 피드백 모두가 훌륭했고, 이 책을 엄청나

게 개선시키는 데 도움이 됐습니다.

경력을 쌓아오는 내내 여러 사람과 일해왔지만, 몇몇 사람은 우리의 일과 이 책에 더

직접적인 영향을 주었습니다. 짐 와이스, 랜디 흄즈, 그레이엄 라이트, 플린트 오브라

이언, 토비에게 감사의 인사를 하고 싶습니다.

세가랜, 그리고 존 윌뱅크스. 우리의 지금 상사, 오이타 콜맨도 우리에게 용기를 주

고 지지를 보내줬습니다. SAS 같은 세계적인 회사에서 일해서 다행입니다.

기민한 개발 커뮤니티(Agile development communities)의 지혜와 저작물이

없었더라면 이 책을 쓰기란 불가능했을 겁니다. 우리는 XP, 스크럼, 크리스털, 그리

고 수많은 다른 소프트웨어 철학 분야의 전문가가 쓴 책과 글을 읽었습니다. 여러분들

의 고된 노력과 헌신이 없었더라면, 소프트웨어 산업계는 아직도 소프트웨어 개발의 암

흑 시대에 빠져있었을 겁니다. 우리가 암흑으로부터 아직 완전히 빠져 나오건 아닐지

모르지만, 올바른 방향으로 향하고 있습니다. 여러분의 지칠 줄 모르는 작업이 우리 모

두에게 도움을 줬습니다.

Page 18: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xix

오픈 소스 커뮤니티는 무엇도 바라지 않고 세상에 수많은 도구와 아이디어를 주었

으니, 그들에게도 감사해야만 합니다. 전세계의 개발자들이 이타적인 기여를 해준

덕분에 우리가 여기서 논의한 도구 대부분은 공짜로 사용할 수 있습니다. 소스포지

(SourceForge) 팀과 아파치 소프트웨어 재단(Apache Software Foundation)에

게 특별히 감사하고 싶습니다. 여러분이 제공한 서비스와 도구는 우리를 보다 생산적이

게 만들어줬고 세상을 바꿔 놓았습니다.

마지막으로 그리고 가장 중요한 일인데, 우리 주님과 구세주 예수 그리스도에게 감사

드립니다. 그에게 영광이 있으리!

자레드리차드슨과윌그월트니

자레드로부터,

내 아내 데브라는 이 책을 쓰는데 수많은 시간을 보냈습니다. 윌이나 나보다 데브라가

이 책에 시간을 더 쏟아 부은 날도 많았습니다. 데브라가 홀로 부모 역할을 맡아준 덕분

에 내가 이 책을 쓸 여력이 된 날도 있었습니다. 정직하게 말하건대 그녀의 도움과 지원

이 없었더라면 이 노력이 결실을 맺지 못했을 겁니다. 고마워요!

내 아이들, 한나와 앨리자베스는 아빠가 사무실에 틀어박혀 책을 쓰는 동안 여러 밤

과 여러 주말을 견뎌내 줬습니다. 너희들이 이해해주고 사랑해줘서 고맙구나!

윌로부터,

글 쓰느라 여러 밤과 여러 주말을 보냈고 일이 잘 안 풀릴 때 볼멘 소리도 많이 했는데,

이 모든 걸 참아준 내 가족이 너무나 고맙다. 우리 가족이 이 모든 걸 이뤄냈다.

Page 19: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

xx

Page 20: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

1

오늘날 수많은 소프트웨어 개발자들이 답답해하고 있습니다. 힘들게 야근을 하

지만 진행 중인 프로젝트는 끝날 기미가 안 보입니다. 노력이나 열망이 부족해서

그런 것은 아닙니다. 팀 구성원 모두가 프로젝트를 깔끔하게 마무리 짓고 싶어합

니다. 하지만 프로젝트를 어떻게 끝내야 할지 아는 사람이 없습니다. 뭐가 효과

적인 방법인지, 직장에 어떻게 적용해야 할지 공부하고 실험해볼 시간을 마련하

기가 쉽지 않습니다. 사람들 대부분은 일하느라 바쁜 탓에 이런 연구에 착수하기

힘듭니다.

그래서 이 책이 나왔습니다. 이 책은 다양한 규모의 회사에서 여러 프로젝트를

통해 현장에서 검증된 기본적이고 실천적인 충고를 모아놨습니다. 실제로 도움이

된다는 걸 우리가 직접 확인한 방법들입니다. 우리는 몇 주 동안만 회사에 들어와

일하는 컨설턴트가 아닙니다. 우리는 하루하루 출퇴근하며 일했습니다. 우리는 그

럴듯한 아이디어에 달려들었다가 곧이어 다음 계약 건으로 넘어가거나 하지 않았

습니다. 일이 잘못될 때에도 여전히 그 자리에 남아서 무너지는 걸 지켜봤습니다.

반대로 일이 잘 풀리는 것도 지켜봤습니다.

1장

서론

현재의 우리는 반복적으로 하는 행동의 결과이다.

그러므로 탁월함이란 행동이 아니라 습관이다.

- 아리스토텔레스

Page 21: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

2

It!Ship

이 책의 아이디어 중 일부는 유명한 소프트웨어 방법론에서 노골적으로 가져온 것이

고, 마땅히 공적을 받을 만한 곳에 공을 돌렸습니다. 나머지 아이디어는 피와 땀 그리

고 눈물을 흘려가며 제련해낸 것입니다. 수많은 도구와 기술, 그리고 최고의 업무처리

기법(Practice, 실천기법 또는 프랙티스)을 실험했고, 쓸만할 땐 받아들였습니다. 실

패한 것은 던져버렸죠. 여러분이 이 책에서 볼 내용 중 일부만이 원래 모습 그대로입니

다(좋은 일이죠). 우리는 ‘거인의 어깨 위에 서서’ 1, 산업계 최고 전문가들의 아이디어

를 선별해서 적절하게 바꿔놨습니다.

오늘날 소프트웨어 개발팀의 50~70%는 기본적이고 유명한 소프트웨어 업무처리

기법을 사용하지 않고 있습니다. 이들은 무엇을 해야 하는지 몰라서 그런 게 아니라,

단지 어떻게 시작해야 될지 몰라서 그럴 뿐입니다. 우리는 사람들에게 개별 아이디어의

가치를 어떻게 납득시키는지 보여드리고, 초기에 밟아 나가야 할 실질적인 단계를 내놓

을 것입니다. 그러고 나서 엉뚱한 길로 들어서지 않으려면 알아두어야 할 경고 신호를

제공할 겁니다.

‘현장에서 발로 뛰는’ 개발자들이 이 책을 썼습니다. 이 책은 이론이 아닌, 작은 벤처기

업에서부터 세계에서 가장 큰 개인 소유의 기업(SAS)에 이르기까지 우리가 겪은 경험에

바탕을 두고 있습니다. 방법론이 아닌 프로젝트에 실제로 도움이 되는 지침을 제공합니다.

우리는 대중적인 ‘실용주의 시리즈’를 본받아 실제적이고, 가볍고, 읽기 쉽게 구성하

려 했습니다. 아무쪼록 이 책이 다른 ‘실용주의’ 책들이 다져놓은 기반 위에 올라서기를

바랍니다.

1.1 습관화된탁월함

자, 아리스토텔레스의 명언이 여기에 어떻게 적용될까요? “현재의 우리는 반복적으로

하는 행동의 결과이다. 그러므로 탁월함이란 행동이 아니라 습관이다.” 멋진 제품 하나

1 만약 내가 멀리 내다볼 수 있었다고 한다면, 거인의 어깨 위에 서 있었기 때문이다. - 아이작 뉴튼

Page 22: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

3

1장 서론

를 또는 여러 개를 만들었다고 해서 훌륭하다고 단정 지을 수는 없습니다. 우리가 매일

하는 일이, 다시 말해 습관이 탁월함을 결정합니다. 정말 뛰어난 제품은 그저 좋은 습

관이 가져온 부가물에 지나지 않습니다.

아리스토텔레스의 명언을 우리 자신의 삶(직업적인 측면이나 개인적인 측면 모두)에

적용해보면, 우리의 삶은 습관에 따른 부가물이라는 걸 깨닫게 됩니다. 그러니 신중하

게 습관을 선택하는 편이 좋습니다. 사람들 대부분은 어쩌다 보니 지금의 업무절차를

택하게 됐을 뿐입니다. 이유는 가지각색인데, 그렇게 일하도록 배웠다던가, 상사가 그

런 식으로 일했다던가 하는 식입니다. 우리는 더 잘 할 수 있습니다.

의식적으로 좋은 습관을 찾아보고, 일상 생활에 적용해보세요.

이런 식으로 해보세요. 개발 방법론 하나를 선택해서 연구해보고, 그 안에서 자신에

게 맞을 것 같은 습관을 하나 고릅니다(다른 것과는 별도로 사용할 수 있는 습관이어야

합니다). 일주일간 적용해봅니다. 만약 그 습관이 마음에 들고 유익한 것 같으면, 한달

정도 계속 사용해봅니다. 새로운 습관이 자연스러운 일상이 될 때까지 연습합니다. 그

러고 나서 앞서의 과정을 다시 반복합니다. 벽돌을 차곡차곡 쌓아나가듯, 이런 과정을

반복합니다. 이렇게 한번에 하나씩 새로운 습관을 익혀서 탁월함의 기초를 닦는 겁니다.

여러분 환경에 적합하지 않는 방법이라면 겁먹지 말고 제거해 버리세요. 그저 유명하거

나 대중적인 방법이라고 여러분에게 맞지도 않는 방법을 계속 유지해선 안 됩니다. 여

러분에게 무엇이 적합하고 뭐가 맞지 않은지 파악해서 자신만의 방법을 갈고 닦으세요.

“하루하루를 보낸다는 것은 다시 말해 삶을 보낸다는 말이다.” 2 이 말이 옳다면 하루하

루를 어떻게 살아갈 것인지 신중하게 생각해야 할 것입니다.

2 Annie Dillard (U.S. author, poet, and Pulitzer prize winner in 1975 for nonfiction) 애니 딜라드 (미국의 작가이자

시인. 1975년에 논픽션 부분에서 퓰리처 상을 수상했다.)

Page 23: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

4

It!Ship

TIP 조언 1

습관을 선택하세요

그저 되는대로 습관을 만들면 안 됩니다. 신중하게 습관을 선택하세요.

1.2 실용주의적관점

이 책은 뭐가 좋고 그른지를 학술적으로 분석하지 않습니다. 여러분이 취사선택할 수

있는 방법론과 업무처리기법을 모아놓지도 않았습니다.

그 대신 이 책은 실제 소프트웨어 프로젝트에서 우리한테 잘 맞았던 것을 제시합니다.

우리는 효과적인 방법이라는 게 분명해지고서야 새로운 도구나 업무처리기법을 도입해

서 사용했습니다. 우리는 쓸만했던 도구나 업무처리기법을 ‘소프트웨어 개발 도구상자’

에 넣어두고 줄곧 사용해왔습니다. 어쨌거나 우리는 자신이 하고 있는 일이 무엇인지

제대로 알게 됐습니다. 이러한 도구와 업무처리 기법이 여러분에게도 유용하기를 바랍

니다.

우리는 어떤 개발 방법론을 단지 ‘올바른 방법’이란 이유만으로 채택하기엔 여유가 없

는 벤처기업에서 일한 적이 있습니다. 주변여건 때문에 당장 업무에 적용할 수 있는 검

증된 아이디어를 찾아내야 했습니다. 우리는 막대한 자원과 기술을 마음껏 쓸 수 있는

큰 회사에서 일해보기도 했습니다. 그러나 큰 회사조차도 멋진 도구라서 또는 몇몇 전

문가가 추천했다고 해서 특정 도구를 사용하려고 들진 않는다는 걸 알게 됐습니다. 회

사는 당면한 문제를 빠르고 값싸게 풀어줄 해결책을 원합니다. 그래서 우리는 어떤 습

관을 채택하기도 하고 버리기도 하면서, 다른 곳에도 적용할 수 있으면서도 문제를 효

과적으로 풀어낼 수 있는 도구 집합을 만들어냈습니다. 이 책은 여러분의 회사에서도

변화를 불러일으킬 좋은 습관을 모아놨습니다. 그 결과는 놀라울 것입니다.

이 책이 가져다 줄 결과를 묘사하기 위해 ‘두 소프트웨어 회사 이야기’(찰스 디킨즈의

Page 24: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

5

1장 서론

‘두 도시 이야기’에 폐를 끼치겠지만)를 해보겠습니다.

첫 번째 회사는 엉망이었습니다. 꽤 비싼 소스 코드 관리 시스템을 구입하고도 설치

조차 하지 않았습니다. 그 결과, 잠재적인 고객에게 보여줄 데모의 소스 코드를 잃어버

리고 말았습니다. 어떤 기능이 제품에 포함되어야 하는지 아는 사람이 없는데도, 개발

팀 전체가 제품에 달려드는 상황이었습니다. 코드는 불안정했고 거의 5분마다 충돌이

일어났습니다(더 나쁜 순간도 잦았는데, 실제 데모를 하고 있을 때 충돌이 일어나기도

했습니다). 이런 뒤죽박죽인 상황은 사기 진작에 도움이 되지 못했습니다. 회의는 고함

치기 대회로 곤두박질치기 일쑤였습니다. 몇몇 개발자들은 하루 종일 사무실에 틀어박

혀 그 같은 상황을 모면했습니다. 간단히 말해 일하기 나쁜 곳이었습니다. 심각한 문제

가 있다는 걸 모르는 이가 없었지만, 아무도 문제를 해결하지 못했습니다.

두 번째 회사는 훨씬 나았습니다. 비슷한 수의 개발자가 있었지만, 그들은 주요 제품

세 개를 동시에 개발했습니다. 세 프로젝트의 코드는 소스 코드 관리 시스템 안에 들어

있었습니다. 팀 전체가 모여서 일일 회의를 했는데, 짧고, 프로답고, 그리고 효과적이

었습니다. 각 프로젝트마다 종합 계획이 수립되어 있었기에 개발자 모두가 어떤 기능을

개발해야 하는지 알고 있었습니다. 사람들은 채석장 일꾼들의 신조에 따랐습니다. 돌

덩이를 자를 때에도 마음 속에는 성당을 그려야 한다[HT003]. 말인즉, 모든 사람이 보

다 큰 협력체계 안에서 자신의 전문지식과 기술을 적용할 수 있었습니다. 그들은 매우

숙련된 개발자였기 때문에 야단법석 떨지 않고도 제품을 제때 전달해냈고, 심지어 제품

은 안정적이기까지 했습니다.

가장 놀라운 점은 이 두 회사가 6개월도 안 되는 시간을 사이에 둔 같은 회사라는 사

실입니다. 단지 이 책의 원리들을 적용했을 뿐입니다(여러분은 벌써 그러리라 짐작했을

겁니다. 그렇지 않나요?). 일정 기간이 지난 후, CEO는 우리가 ‘탁월함의 분위기’를

가져와 주었고, “알아보기 힘들 정도로 변했다”라고 말했습니다. 이 회사는 우리가 최

3 부록 238쪽 참고 문헌을 참고하세요.

Page 25: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

6

It!Ship

근에 일한 곳 중 하나입니다. 여러분에게 제시하는 것과 거의 동일한 형태의 원리를 적

용했었습니다. 그곳에서 겪은 변혁이 이 책을 쓰게 된 이유 중 하나입니다.

우리는 4명밖에 안 되는 작은 벤처기업에서부터 세계에서 가장 큰 개인 소유의 소

프트웨어 기업인 SAS에 이르기까지 이러한 아이디어를 발견하고 적용해왔습니다.

솔직히, 회사 규모에 상관없이 이런 원리들이 효과적이라는 사실을 알고 우리 자신도

놀랐습니다.

이 책의 아이디어들을 큰 프로젝트의 기초쯤으로 생각하세요. 만약 여러분이 인프라

스트럭처를 적절하게 설정하기 위해 미리 시간을 투자할 의향만 있다면, 프로젝트 생명

주기 나머지 기간 내내 그 효과를 거둬들일 수 있습니다. 물론 모든 업무처리기법을 제

대로 잡은 상태에서 프로젝트를 시작하는 편이 더 쉬울 겁니다. 건물의 깨진 토대마냥,

어떤 것은 쉽게 땜질이 되는 반면에 어떤 것은 매우 구조적인 문제라 고쳐서 원상 복귀

시키려면 꽤 많은 노력이 듭니다.

여러분이 현재 프로젝트를 진행 중이더라도 좋은 습관들을 적용해보기에 늦은 것은

아닙니다. 지금 프로젝트에 이 책의 아이디어 중 일부를 도입해서 즉각적인 효과를 볼

수도 있습니다. 어떻게 하면 되는지는 마지막 장에서 다룰 예정입니다.

1.3 로드맵

아이디어들을 크게 세 영역으로 정리했습니다. 인프라스트럭처, 기법, 그리고 프로세

스입니다(그림 1.1을 보세요). 이 영역들은 고객들이 원하는 제품을 지속적으로 제공

하는 능력과 관련 있습니다.

인프라스트럭처

‘도구와 인프라스트럭처’ 장에서는 여러분 자신과 팀 전체의 삶을 편하게 해줄 소프트웨

어 도구들을 다룹니다. 예를 들어, 좋은 소스 코드 관리 시스템은 프로젝트의 보석 같

Page 26: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

7

1장 서론

그림 1.1 멋진 제품을 만드는 법

버전 관리

Ship It!

인프라스트럭처기술

프로세스

빌드 스크립만들기

지속적인빌드

기능추적하기

이슈추적하기

테스트 작성하고 돌리기

기술 리더

업무 목록

코드 검토

시스템객체 제안하기

인터페이스 제안하기

인터페이스 연결하기

함수추가하기

리팩토링,다듬기,반복하기

코드 변경 통지

일일 회의

은 존재인 소스 코드를 안전하고 결실하게 지켜줍니다. 자동화된 빌드 시스템은 원하기

만 하면 언제 어디서나 빌드를 반복할 수 있게 해줍니다. 또한 여러분이 무엇을 개발해

왔는지 다른 사람들도 알 수 있게 하려면, 버그 보고서와 기능 요청서 그리고 다른 이

슈들을 어떻게 추적하고 관리해야 하는지에 대해서도 논의할 겁니다. 마지막으로 좋은

테스트 장비를 어떻게 사용해야, 여러분이 생각했던 대로 코드가 작동하리라는 자신감

을 갖게 되는지 보여드리겠습니다.

Page 27: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

8

It!Ship

기법

‘실용적인 프로젝트 기법’ 장에서는 여러분과 팀이 매일 ‘힘들이지 않고, 보다 현명하게’

일하는 데 필요한 특정 기법들을 다룹니다. 팀에 기술 리더를 두어서 바깥 세상으로부

터 여러분을 보호하고 알 필요가 있는 것들만 전달받는 방법을 알려드리겠습니다. 그

룹이 제 방향으로 나아가길 원한다면, 여러분 자신의 일이나 팀의 업무를 업무 목록으

로 정리하세요. 팀이 서로 대화를 나누지 않습니까? 누가 뭘 하고 있는지 모릅니까? 모

두를 하나로 결속시키고 동시에 팀 동료의 마음을 얻을 기회가 필요하다면 일일 회의4

를 시작해보세요. 짧은 코드 검토 과정을 통해 동료의 전문 지식을 활용하고 여러분의

지식도 공유할 수 있습니다. 그리고 검토가 끝나면, 코드 변경 내역을 공지해서 나머지

팀원도 알 수 있게 하세요.

프로세스

소프트웨어 개발에 관한 책치고 작가가 선호하는 개발 방법론을 다루지 않고 넘어가는

법이 없습니다. 이 책도 다르지 않습니다. 부족하지만 우리가 예광탄 개발이라고 이름

붙인 방법론을 추가했습니다. 예광탄 개발 방법을 사용하면, 거의 뼈대가 갖춰진 작동

가능한 시스템을 만든 다음에 구현 과정을 거치면서 빠진 부분만 채워넣으면 됩니다.

그러고 나서 실제로 구현하기 위해 빠진 부분을 채워 넣어서 만들기만 하면 됩니다. 예

광탄 개발은 큰 프로젝트를 작게 쪼개서 각 팀이 하나씩 병행해서 작업하기에 좋습니다.

뿐만 아니라 자동화된 테스트에도 알맞습니다.

흔하게 벌어지는 문제와 문제를 해결하는 법

마지막엔, 흔하게 벌어지는 문제들을 제시하고, 앞서 언급한 도구와 기법, 그리고 프

4 “실천가를 위한 실용주의 프로젝트 관리” 참조(위키북스, 2007)

Page 28: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

9

1장 서론

로세스를 사용해서 그런 문제를 어떻게 해결하는지 조언해 드리겠습니다. 수년간 이런

문제를 수도 없이 겪었습니다. 문제 중 일부는 해결했고, 어떤 것은 나중에야 해결법을

알게 됐습니다(지나고 나면 모든 게 확실해 보이는 법이죠). 여러분이 똑 같은 실수를

저지르지 않도록 우리의 경험이 도움이 되기를 바랍니다.

무엇이 빠졌는가?

사람 문제와 요구사항 수집에 대해서 다루지 않습니다. 제대로 된 사람이라면 도구, 기

법, 그리고 프로세스 따위를 프로젝트의 가장 중요한 요소라고 생각하지는 않습니다.

그러나 훌륭한 팀을 모으고 유지하는 것은 책 한 권이 따로 필요한 주제입니다(한 권이

아니라 시리즈가 필요할 수도 있습니다!). 대신 우리는 여러분의 팀이 이미 갖고 있는

기술을 활용하고 키우는 방법에 초점을 맞춥니다.

사람 문제와 마찬가지로, 제품의 요구사항에 대해 배우는 것도 또 하나의 큰 주제입

니다. 메모 카드를 활용하는 방법부터 복잡한 시스템을 도입하는 것에 이르기까지 요

구사항을 수집하는 방법은 다양합니다. 한 장에 담을 수 없는 커다란 주제를 다루려고

하기보단, 계속 변하는 요구사항을 다룰 수 있는 유연한 아이디어를 제공하기로 결정

했습니다. 그 요구사항이 어떤 출처에서 나온 것이든 간에 말이죠. 이 책의 아이디어는

요구사항이 변하지 않는 프로젝트뿐만 아니라 요구사항이 끊임없이 변하는 프로젝트에

도 쓸모가 있습니다. 그러니 여러분은 작은 종이 카드에서 추출한 요구사항 목록이든,

10,000쪽짜리 계약서에 근거를 둔 요구사항이든 상관없이 이 책의 아이디어를 사용

할 수 있습니다.

여러분이 어떤 회사에 있든, 어떤 기술을 사용하건 간에 이 책의 아이디어를 활용할

수 있도록 일반적인 이야기를 하려고 노력했습니다. 그래서 인스톨러 기술이나 코드 최

적화 도구에 대해서는 다루지 않습니다.

Page 29: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

10

It!Ship

1.4 앞으로나아가기

우리는 여러분이 이 책에서 제시하는 아이디어와 습관을, 그것들을 단조(鍛造)해낸 정

신에 입각해서 사용해주길 바랍니다(다시 말해 실용적으로 활용해주기 기대합니다). 읽

고 시도해보세요. 여러분 환경에 적합한 것은 남기고 나머지는 버리세요.

매 장을 읽고 나면 잠시 멈춰서 제시된 아이디어를 사용하고 있는지 판단해보세요.

사용하지 않고 있다면 ‘어떻게 시작해야 하나?’를 읽으세요. 벌써 사용하고 있다면 ‘내

가 제대로 하고 있는 걸까요?’나 ‘경고 신호’를 읽으세요. 올바른 방향으로 나아가고 있

는지 확인할 수 있습니다.

1.5 이책을어떻게읽어야하나?

프로젝트에서 여러분이 맡은 역할에 따라 이 책을 읽는 방법도 달라집니다. 당연한 말

이지만, 여러분이 개발자이거나 테스터라면 팀 리더와는 다른 접근 방식을 택해야 할

겁니다. 하지만 어떤 역할이든 간에 이 책에서 가치 있는 것을 많이 얻을 수 있을 겁니다.

여러분이 개발자이거나 테스터라면

여러분이 현장 실무자, 즉 행동해야 하는 사람이라면 이 책을 처음부터 끝까지 읽으세

요. 각 섹션은 여러분이 개인으로서나 팀 리더로서 매일 활용할 수 있는 실용적인 아이

디어를 제시합니다. 간혹 팀 리더가 아닌 개발자가 팀에 중점을 둔 섹션을 넘어가는 경

우가 있습니다. 정말 바람직하지 못한 생각입니다. 팀 환경이란 대부분 팀 구성원들이

무엇을 요청했는가, 무엇을 체험했는가에 따라 달라집니다. 어떤 도구나 기법, 그리고

프로세스가 회사에 긍정적인 영향을 미칠 수 있는지 알아뒀다가, 제안할 일이 있을 때

마다 명확한 이유를 제시할 수 있어야 합니다. 개발자들이 특정 도구나 기법을 “이게 올

바른 방식이예요.”라며 옹호하는 걸 여러 번 봤습니다. 이런 식의 주장으로는 결코 관

리자를 설득할 수 없을 뿐더러 사실상 반생산적이기까지 합니다. 아이디어를 제시하기

Page 30: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

11

1장 서론

전에 팀에 어떤 이득이 되는지부터 확실히 해둬야 합니다.

어떤 제안이 마음에 드시나요? “Acme Code Systems 사의 소스 코드 관리 시스템

이 필요합니다. 제품이 좋은데다가 모든 사람이 그걸 사용합니다. 이 제품이 최고입니

다!” 다른 방식의 제안도 들어보시죠. “소스 코드 관리 시스템이 필요합니다. 이 시스템

이 있으면 옛날 릴리즈에 접근할 수도 있고, 특정 코드 변경을 되돌리거나 개발자들이

코드 트리를 동시에 건드릴 수도 있습니다. 우리 회사가 개발에 투자한 것을 보호할 수

있는 가장 손쉬운 수단입니다. Acme Code Systems 사는 눈여겨봐야 할 훌륭한 제

품을 만듭니다. 조와 저는 몇 개월 동안 그 제품을 사용해왔고, 생산성이 정말 크게 향

상됐습니다. 이 제품이 어떻게 도움이 되었는지 목록을 작성해봤습니다. ”

여러분이 프로젝트 팀 리더라면

팀의 주변여건과 작업 흐름을 점검하는 데 이 책을 사용하세요(이미 가끔씩 점검을 하

고 있을 겁니다. 맞나요?). 팀이 일하는 방식을 재점검할 기회를 갖도록 하세요. 기초

적인 요구사항을 다룰 수 있는 기본적인 도구 집합을 가지고 있습니까? 여러분 팀의 기

술은 견실한 제품을 내놓고, 능력 있는 개발자를 배출할 만큼의 수준이 됩니까? 깔끔하

고 잘 정의된 프로세스를 갖고 있나요?

팀이 일하는 방식을 검토할 때, 개별 항목이 타당한지 반드시 확인하도록 하세요. 예

전에는 적합했지만 이제는 쓸모없어진 도구나 업무처리기법을 여전히 사용하고 있지는

않나요?

햄의 1/3을 잘라서 버리고 요리하는 여성에 대한 이야기를 들어보셨습니까? 왜 그렇

게 요리하는지 묻자, 그녀는 어머니가 그런 식으로 요리했다고 대답했습니다. 어머니

에게 이유를 묻자, 자신의 어머니가 요리하던 방식이라고 했습니다. 마침내 할머니와

대면했습니다. 할머니는 어렸을 때 햄을 통째로 담을 팬이 없어서 끝자리를 잘라내곤

했는데, 그것이 습관이 돼버렸다고 고백했습니다.

Page 31: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

12

It!Ship

지난 해의 프로젝트나 할머니의 괴팍함이 아닌 지금 이 순간의 필요에 따라 습관을 형

성하도록 주의하세요.

팀 전체가 필요한 도구, 기술, 그리고 프로세스에 접근할 수 있도록 하세요. 무엇이

왜 효과적인지 알아야만 팀을 효과적으로 이끌어나갈 수 있습니다. 각각의 섹션에는 막

도입할 시기에 도움이 될만한 팁이 제시되어 있습니다. 뿐만 아니라 걷잡을 수 없이 커

지기 전에 문제를 파악할 수 있도록 경고 신호도 제시했습니다.

여러분이 관리자거나 깊게 관련된 고객이라면

상위 관리층이라면 적절한 정보를 요청하는 것만으로도 팀이 일하는 방식에 영향을 크

게 미칠 수 있습니다. 이 책은 팀이 사용해야 할 핵심요소 일부를 보여주고, 어떤 질문

을 던져야 하는지 알려줍니다. 예를 들어 지난 출시 때의 수정 건 목록을 요청하면, 그

정보를 원한다고 말하는 셈이 됩니다. 각 섹션을 읽으면서, 여러분이 원하는 방향으로

사람들을 이끌어 줄 산출물이 없는지 눈여겨 보세요. 팀 리더들에게 그 산출물을 제출

하게끔 하면 됩니다. 그렇지만 이런 요청은 주의해서 해야 합니다. 관료주의적 잡일을

만들고 싶진 않을 겁니다. 사람들을 이끌 때는 신중하게 요청해야 합니다.

관리자가 돼서 일상 업무에서 제외되었으니, ‘어떻게 시작해야 될까요?’ 장을 대충

훑어보고 넘어가려고 할지 모릅니다. 하지만 각 주제가 무엇을, 왜 다루는지 이해하고

싶을 겁니다.

개인이 모여 팀을 이룬다

이 책이 다루는 개념 중 대부분은 개인이 아닌 팀 구성원, 모든 팀, 그리고 관리자가 사용

해오던 것입니다. 누군가가 업무처리 기법을 먼저 사용해보고 쓸만하다 싶어서 팀과 공유

하는 일은 흔합니다. 우리는 이런 일을 반복해왔고, 다른 이가 그렇게 하는 걸 지켜봤습니

다. 여러분도 똑같이 할 수 있습니다. 그렇게 해 본 누군가의 이야기를 들려드리겠습니다.

Page 32: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

13

1장 서론

기민성지원시스템의빠른성장

- CafePress.com의 도미닉 플란테, 저스틴 맥카티 공저

지난해 초 CafePress.com에서 막 일하기 시작했을 무렵, 관리층은 기민한 실천기법(Agile

practices)을 도입하는 데 적극적이었습니다. 그러나 개발 환경은 자신감을 갖고 변화를

이뤄내는 데 필요한 기본적인 지원 시스템을 갖추고 있지 못 했습니다.

사람들이 자신만의 제품(티셔츠나 머그잔 같은)을 쉽게 디자인하고 구매할 수 있도록

CafePress의 핵심 기능을 확장하는 ‘직접 만들고 사기’ 프로젝트를 시작했습니다. 프로젝

트는 웹 프리젠테이션 계층에 더해 명확한 비즈니스 및 퍼시스턴스 계층을 도입하려는 첫

시도였습니다. 비즈니스 및 퍼시스턴스 계층은 대부분 테스트 주도 방식으로 개발됐습니

다. 개발자는 NUnit 프레임워크를 사용해 테스트를 작성했습니다. 그와 동시에, 웹 계층

에서 사용하는 클래스들을 컴파일하고 배치하는 반복적인 작업을 하려고 NAnt를 도입했

습니다. 그런 다음 서브버전 코드 저장소로 들어오는 모든 체크인을 지속적으로 통합하려

고(예를 들어, 컴파일하고 테스트를 돌려보기 위해) CruiseControl.NET을 묶어 넣었습니

다. 마무리로, ‘치킨 리틀’이란 애칭을 붙인 작지만 눈에 띄는 (그리고 음향까지 나는) 워크

스테이션에다가 CCTray�를 돌려서 빌드 상태를 알리게 했습니다.

서브버전, CruiseControl.NET, NAnt, 그리고 NUnit 간의 상호운영은 쾌적한 협력환경

을 꾸리는 데 도움이 됐습니다. 이론이 분분한 벤더 분석이나 구매 결정은 없었습니다. 게

다가 이런 지원 시스템들은 개발자가 원해서 도입됐습니다. 관리층의 지시 때문에 도입한

것이 아닙니다.

이렇게 자동화를 시작한 이래로 우리 팀은 커졌고, 여러 신참자들이 테스트 수트와 프로

5 빌드 실패를 알려주는 트레이 아이콘 애플리케이션입니다.

Page 33: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

14

It!Ship

이 이야기처럼 개발자가 주도해서 변화를 일으키는 게 이상적이라고 생각합니다. 변화

를 도입하려는 관리자를 실망시키려는 건 아닙니다. 하지만 가장 훌륭하고, 가장 적합

한 변화 사례는 현장에서 나왔다는 걸 알게 됐습니다. 일을 하는 사람이 어떤 문제가 해

결돼야 하는지 잘 알기 마련입니다.

그러니 여러분이 관리자이든, 개발자든, 테스터든, 또는 기술 리더이든 “이 책을 써

먹으세요.” 개인적인 일이나 회사업무에서 빠진 부분을 찾아내서, 어떻게 해야 여러분

의 삶이 좀 더 편해질지 알아보세요.

젝트 자동화 도구를 개선해나갔습니다. 최근 업데이트 중 일부는 자동화된 테스트 환경 배

포 기능뿐만 아니라 100% 스크립트로 만들어진 개발환경구성 기능까지 포함합니다. 하지

만 돌아보면, nant 테스트가 여전히 가장 많이 사용되는 타겟입니다.

이런 도구들이 출현하기 전에는 우리가 하루 동안 나누는 대화는 대부분 빌드 실패에 대

해 사람들에게 질문하거나 API 변경을 통지하는 것이었습니다. CruiseControl.NET이 빌

드를 처리해주기 때문에, 개발자들은 빌드를 원래 상태대로 유지하는 게 얼마나 중요한지

이해했고 그렇게 하려고 헌신했습니다. 누구도 잘못된 체크인 때문에 작업을 정지해야 하

는 상황을 좋아하지 않았습니다. 지원 시스템을 제대로 갖춰놓으니, 자연스럽게 소프트웨

어 설계와 구현에 대해 이야기 나누게 됐고, 주변 환경 때문에 발생한 좌절감으로부터 빠

져나올 수 있었습니다.

우리가 처음에 들인 노력 전부가 테스트한 코드를 즉시 전달하는 데 도움이 됐고, 초창

기에 한 투자 덕분에 ‘치킨 리틀’이 꿱꿱거릴 때마다 그 값어치를 할 수 있었습니다.

Page 34: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

15

1장 서론

기민함이란게뭐죠?

기민함이란 소프트웨어 개발팀이 변화하는 환경에 재빨리 적응하는 능력을 일컫습니다. 이것

은 변화하는 요구사항에 맞춰 재설계하는 걸 뜻하기도 하고, 새로운 버그에 신속히 대처하거나 새

기술을 빨리 도입하는 걸 뜻할 때도 있습니다. 일반적으로, 기민한 팀은 관료주의보다 결과에 신경

씁니다. http://www.agilemanifesto.org/ 에서 기민한 소프트웨어에 대해 자세히 알아볼 수

있습니다.

웹 사이트에서 가져온 다음 인용문이 기민한 관점을 꽤 잘 요약하고 있습니다.

“우리는 직접 해보거나 다른 사람을 도와주면서 소프트웨어를 더 잘 개발하는 방법을 밝혀나

가고 있다. 이 같은 작업을 통해 우리는 다음과 같은 가치에 도달했다.

프로세스나 도구보다는 사람과 상호작용에,

포괄적인 문서보다는 실제로 도움이 되는 소프트웨어에,

계약 협상보다는 고객과의 협력에,

계획을 따르는 것보다 변화에 맞추어나가는 것에,

왼쪽에 명시한 항목도 가치 있지만, 우리는 오른쪽 항목을 더 중요하게 여긴다."

Welcome any question! 무엇이든지 물어 보세요!

Page 35: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

16

It!Ship

Page 36: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

17

집을 지으려는 두 남자(마이크와 조)가 있었습니다. 한 남자(마이크)는 연장을 구

매하고 사용법을 익히는 데 상당한 시간과 돈을 썼습니다. 다른 남자(조)는 갖고

있던 연장을 들고 집을 짓기 시작했습니다. 당연하게도, 조의 집이 먼저 형태를 갖

추기 시작했습니다. 마이크가 공기 압축기와 못총(nail gun) 사용법을 익히고 있

을 때, 조는 못을 박았습니다. 하지만 마이크가 학습곡선을 넘어서 집을 짓기 시작

하자, 순식간의 조를 넘어섰습니다. 마이크는 시간을 투자해서 연장 사용법을 익

힌 덕분에 더 나은 집을 더 빨리 지을 수 있었습니다. 다음 번에 집을 짓는다면, 누

가 더 빨리 끝낼지는 자명하지 않습니까?

마이크와 마찬가지로, 우리에게도 마음껏 쓸 수 있는 도구가 많습니다. 당장 일

해야 한다는 조급함 때문에 조처럼 무턱대고 이미 익숙한 도구를 들고 일에 착수할

수도 있습니다. 아니면 다시 돌아가서 일하는 방식을 평가해볼 수도 있습니다. ‘도

구와 인프라스트럭처’에서 소개한 도구 중 일부는 여러분의 회사에서 사용할 수 없

2장

도구와 인프라스트럭처

…코딩하는 시간이 기능을 추가하는 데 소요되는 유일한 비용은

아니다. 훗날 기능 확장이 어려워지는 것도 비용 중 일부이다. …

상충되지 않는 기능들을 고르는 게 중요하다.

- 존 칼맥

Page 37: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

18

It!Ship

을지도 모르겠습니다. 도구를 거의 사용하지 않는 회사에서 일할지도 모르겠네요. 그

렇다면 뒷맛이 나쁘겠네요. ‘도구와 인프라스트럭처’를 정독하고 우리가 논의한 도구가

일상 업무에 긍정적인 영향을 미칠 수 있을지 생각해보길 권합니다.

보통 회사의 보통 개발자인 프레드의 하루를 살펴봅시다. 그의 업무 경험은 회사에서

사용하는 도구나 인프라스트럭처 같은 주변 환경의 영향을 많이 받습니다.

아무도 프레드가 겪은 문제를 알지 못한다

아침에 출근한 프레드는 윌마가 보낸 이메일을 확인했습니다. 그녀가 지난 밤에 수정한

코드에 대한 글이었습니다. 변경된 코드가 필요했기 때문에 프레드는 네트워크 드라이

브에서 윌마의 코드를 내려 받았습니다. 한 시간 정도 이리저리 만지작거리고 나서, 윌

마의 코드를 컴파일 되게끔 만들었습니다. 프레드는 몇 분 간 그녀가 수정한 코드를 두

번 확인했는데, 제대로 작동하는 듯했습니다. 그런 후에 프레드는 어제 써놓은 메모를

보고 기억을 되살렸습니다. 새 기능(Feature)을 거의 다 작성했습니다. 3일이나 작업

한 끝에 마침내 오늘 점심 무렵에는 끝낼 수 있으리라 생각했습니다.

솟구치는 열정에, 프레드는 코드 에디터를 열었습니다. 그러나 소스 코드는 온데간

데 없었습니다. 우울한 감정이 덮쳐 들었습니다. 프레드는 작업했던 결과를 윌마의 코

드로 덮어씌웠다는 걸 깨달았습니다. 3일 간의 작업이 30초 만에 날아갔고, 복구할 방

법도 없었습니다. “젠장, 처음 있는 일도 아니지, 마지막일 리도 없고… 이 직업의 고

난 중 하나일 뿐인데 뭘.”

때마침 판매부서의 리차드가 지난주에 요청한 버그 수정 건이 얼마나 진전됐나 확인

하려 들렸습니다. 프레드는 움찔했습니다. 새 기능 추가 작업에 정신이 팔려 버그 건은

잊어버렸습니다. 리차드는 작업 지연을 탐탁지 않아 했고, 프레드는 오늘 내로 마무리

하겠다고 약속했습니다.

프레드는 기한이 지난 버그를 오후 늦게서야 고칠 수 있었습니다. 고객에게 보낼 업

Page 38: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

19

2장 도구와 인프라스트럭처

데이트를 준비하다가, 고객은 자신이 수정한 버전이 아닌 이전 버전의 제품을 사용한다

는 걸 깨달았습니다. 다른 직원들이 퇴근 준비를 시작할 무렵에 프레드는 아내에게 전

화해서 저녁 식사 약속을 취소했습니다. 그런 후 수정된 코드를 적용하기 위해 네트워

크 드라이브에서 이전 버전의 제품을 찾기 시작했습니다.

필요한 버전의 코드를 찾는 데 한 시간 정도가 걸렸고, 코드가 작동하게 하는 데 또

한 시간이 걸렸습니다. 오래된 코드 베이스에 수정된 코드를 적용하는 데 한 시간을 더

쓰고 나서야 하루 일과가 끝났습니다.

긴 하루였지만 프레드는 투자한 시간을 자랑스럽게 여겼습니다. 프레드는 회사의 성

공을 위해 기꺼이 최선을 다해 일했습니다. 비록 그의 가족이 자신을 항상 이해해주는

것은 아니지만 말입니다.

다음날 고객은 프레드가 예전 버그를 다시 불러낸 데다가 새로운 버그를 두 개나 만

들어냈다는 사실을 발견했습니다.

여러분의 하루는 어떻게 다를까요?

프레드의 입장에서 생각해보도록 하죠. 아침에 출근해서 베티가 보낸 이메일을 발견했

는데 코드를 변경했다고 합니다. 여러분의 회사는 소스 코드 관리 시스템 (SCM) 패키

지를 사용합니다. 이 시스템은 중앙 저장소에 모든 코드 변경 내역을 저장하고 있어서

필요하다면 변경 내역을 내려 받을 수 있습니다. 그래서 여러분은 SCM으로부터 베티

가 업데이트한 코드를 받아 로컬 컴퓨터에 있는 코드와 통합합니다. 충돌이나 코드 덮어

쓰기가 일어나는 경우에는 변경한 코드가 사라질지도 모른다고 SCM이 경고해줍니다.

이제, 여러분은 한 줄짜리 빌드 명령을 내리고, 베티가 변경한 코드는 여러분이 작성

한 코드와 함께 컴파일 됩니다. 회사가 표준 빌드 시스템을 사용하기 때문에 베티는 여

러분과 똑같은 방법으로 코드를 빌드합니다. 프레드와는 달리, 여러분의 컴퓨터에선

코드가 돌아가게 하려고 한 시간씩이나 낭비할 필요가 없습니다.

Page 39: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

20

It!Ship

출근해서 막 일을 시작하려는데, 판매 부서의 리차드가 지난 주에 요청한 버그 수정

건에 대해 물으러 들렀습니다. 프레드와 마찬가지로, 여러분도 버그 수정 건에 대해 잊

고 있었습니다. 그러나 여러분은 버그 추적 소프트웨어의 주간 보고서를 확인하는 습관

이 있습니다. 그래서 월요일에 버그 수정 건을 기억해냈습니다. 여러분은 버그를 수정

해놨고, 고객을 위한 업데이트도 준비해놨습니다. 리차드는 만족스러워 했고, 여러분

에 대해 좋은 감정을 갖고 돌아갔습니다.

버그를 고치려면 고객이 사용하는 제품 버전에 알맞은 소스 코드부터 찾아야 합니다.

여러분은 SCM 소프트웨어에게 예전 버전을 달라고 요청합니다. 네트워크 드라이브를

검색하느라 시간을 낭비할 필요가 없을 뿐더러 예전 코드 트리를 사용하는 바람에 옛날

버그가 다시 생길 일도 없습니다.

버그가 가득한 코드 트리를 사용할지라도, 여러분의 빌드 프로세스에는 자동화된 테

스트 수트가 포함되어 있습니다. 이 수트는 흔한 버그를 잡기 위해 고안된 가벼운 테스

트 집합을 실행시킵니다. 옛날 버그가 다시 등장하더라도, 고객이 눈치채기도 전에 잡

아낼 수 있습니다.

하루 일과가 끝날 때가 되자, 여러분은 제 시간에 퇴근해서 가족과 함께 멋진 식사를

갑니다. 그때까지도 프레드는 일하고 있었고, 그의 아내는 다시 한 번 화가 났습니다.

여러분은 삼일짜리 기능 추가 작업을 끝내고, 다음날 출근해서는 다음 작업에 착수할

준비가 됐습니다. 여러분은 프레드보다 생산적입니다. 그러나 여러분이 더 똑똑하거나

더 헌신적인 것은 아닙니다. 여러분과 프레드 둘 다 헌신적이고 총명한 개발자입니다.

유일한 차이점은 여러분의 회사는 중요한 도구 몇 개를 업무에 도입한 데 반해, 프레

드의 회사는 그렇지 않았다는 사실입니다. SCM이나 버그 추적 소프트웨어 같은 도구

를 적재적소에 배치하세요. 그러면 견고한 개발 인프라스트럭처를 갖게 돼서 흔해 빠진

골치거리 상당수를 별 것 아니게 만들 수 있습니다.

Page 40: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

21

2장 도구와 인프라스트럭처

그림 2.1 도구와 인프라스트럭처

프레드가 빠진 함정에 걸리지 말자

프레드는 버그를 고치고 발등에 떨어진 불을 끄느라 바쁜 나머지 더 나은 방법이 있다

는 걸 깨닫지 못했습니다. 성공적인 프로젝트치고 강력한 기본 틀, 즉 인프라스트럭처

를 적절히 배치하지 않는 경우는 없습니다. 여기서 말하는 인프라스트럭처는 소스 코드

관리 시스템이나 빌드 도구처럼 여러분이 제품 개발에 사용하는 도구와 업무처리기법

을 말합니다. 여러분은 다른 도구를 사용할지도 모릅니다. 하지만 그 범주는 프로젝트

를 막론하고 동일할 겁니다. 이 장은 모든 프로젝트에서 사용해야 하는 기본적인 도구

에 대해 설명합니다.

몇몇 주제는 너무 뻔한 소리처럼 들릴 수도 있습니다. 그럼에도 불구하고 그런 주제

를 포함시키로 했습니다. 뻔한 주제라고 해서 널리, 그리고 올바르게 사용되고 있다는

뜻은 아닙니다.

대부분의 영역에서는 잘 정비되어 있는 팀이라도 큰 허점이 있을 수 있습니다. 다른

버전 관리

인프라스트럭처

빌드 스크립만들기

지속적인빌드

기능추적하기

이슈추적하기

테스트 작성하고 돌리기

버전 관리

인프라스트럭처

빌드 스크립만들기

지속적인빌드

기능추적하기

이슈추적하기

테스트 작성하고 돌리기

Page 41: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

22

It!Ship

곳엔 엄청난 돈을 투자하고도 정작 중요한 도구는 빠졌을 수도 있습니다. 여러분이 어

떤 벤더의 제품을 도입했느냐에 따라 허점도 다릅니다. 벤더는 그 제품이 여러분을 위

해 모든 걸 해 준다고 말했을 테지만요.

허점이 있을 수 있다는 사실을 염두에 두고, 각 섹션을 읽었으면 잠시 멈춰서 여러분

이 일하는 방식과 책의 내용을 비교해보세요. 만약 그 도구나 아이디어를 사용하지 않

고 있다면, 왜 그런지 스스로에게 물어보세요. 한 번도 들어본 적이 없습니까? 경험해

본 적이 없나요? 여러분에게 맞지 않았나요? 도구나 아이디어를 사용하고 있더라도 올

바르게 쓰고 있는 걸까요? 그렇지 않다면 개선하기 위해 뭘 해야 할까요?

Page 42: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

23

2장 도구와 인프라스트럭처

01 모래 상자(Sandbox) 안에서 개발하기

여러분은 코드를 동료와 어떻게 공유합니까? 놀라울 정도로 많은 팀이 명확히 답하지

못할 겁니다. 상당수의 팀이 모든 소스 코드와 기타 파일을 크고 낡은 디스크 드라이브

를 통해 공유하고 있습니다. 누군가 조금만 손 대면-파일 하나를 수정한다던가, 코드

를 컴파일하면-곧바로 다른 개발자가 그 영향을 받습니다. 사람들의 삶은 언제나 불쾌

한 놀라움으로 가득하겠죠.

추수감사절 날 붐비는 주방과 비슷합니다. 사람들은 아무거나 던져넣을 테고 엉망진

창이 됩니다. 꽤나 의욕을 꺾는 작업 환경임에 틀림없습니다. 이렇게 운영해나가는 팀

이 많더라도, 여러분은 보다 안전하고 전문가다운 태도를 취할 수 있습니다. 이런 태도

야말로 여러분의 도구와 인프라스트럭처에 엄청난 영향을 발휘합니다. 그러니 처음부

터 바로잡을 필요가 있습니다.

새겨둬야 할 기본 법칙은 하나뿐입니다. 적당한 시기가 올 때까지 여러분이 하는 일

때문에 다른 사람이 방해받지 않게 하세요. 그래서 이것을 ‘모래상자 개발’이라 부릅니

다. 모든 개발자가 자신만의 놀이터에서 놀고, 다른 사람을 귀찮게 하지 않는 겁니다.

쉬워 보일지도 모릅니다. 소스 코드를 분리하는 것은 특히 간단해 보일 겁니다(27쪽

의 2_02절 ‘자산을 관리하세요’를 참고하세요). 하지만 진짜 알아둬야 할 점은 소스 코

드뿐만 아니라 데이터베이스 인스턴스나 웹 서비스와 같이 여러분이 의존하는 모든 것

을 분리해야 한다는 것입니다.

생산적으로 일할 수 있도록 개발용 컴퓨터를 고안해야 합니다.1 한 컴퓨터가 빌드

과정 전체에 영향을 줘선 안 됩니다. 누구도 다른 개발 컴퓨터에 기댈 필요가 없어야

합니다.

1 개발자마다 서로 다른 편집기나 심지어 서로 다른 통합개발환경(IDE)를 사용해도 무방하다는 뜻입니다.

Page 43: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

24

It!Ship

하지만 다른 개발자가 여러분이 작성한 코드를 어떻게 구할 수 있을까요? 소스 코드

는 레포지토리(repository)라고 불리는 저장소를 통해 공유됩니다. 저장소는 일종의

거대한 공유 디스크입니다. 하지만 사서(司書)가 있어서 관리를 해준다고 생각하면 됩

니다. 그 사서가 사람들이 정확한 버전의 파일(또는 다른 자원)을 꺼내가도록 해줍니다.

그러니 사람들이 서로의 멱살을 잡으며 일하지 않게 됩니다. 파일을 저장소로 보내고(체

크인), 가져오는(체크아웃) 소프트웨어 도구를 사용하면, 각자 자신의 컴퓨터에서 작업

할 수 있습니다.

그림 2.2 샌드 박스 개발 셋업

팀 동료가 뭘 하든 상관없이, 자신의 개발 컴퓨터에서 소스 코드의 로컬 복사본을 수정

하고, 컴파일하고, 빌드하고, 테스트합니다. 데이터베이스, 웹 서버, 또는 다른 자원

을 사용할 때는 다른 사람이 같은 자원을 사용하고 있지는 않은지 확인해야 합니다. 작

업한 코드가 마음에 들면 저장소로 보내서 체크인하면 됩니다.

그런데 완성된 제품을 고객에게 어떻게 전달할까요? 개발자 컴퓨터, 그리고 저장소

와 더불어 빌드 컴퓨터가 있습니다. 빌드 컴퓨터는 무인 서버입니다. 이것은 저장소에

서 최신 소스 코드를 가져와서 빌드하고 테스트하기를 반복할 뿐입니다. 이렇게 빌드되

개발자 컴퓨터

저장소

빌드 컴퓨터 출시된 제품

개발자 컴퓨터

저장소

빌드 컴퓨터 출시된 제품

Page 44: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

25

2장 도구와 인프라스트럭처

어 나온 것을 제품 출시라 합니다.

이렇게 출시된 제품은 각 빌드 후에 버려지기 일쑤입니다. 그러나 가끔은 이렇게 출시된

것을 고객이나 최종사용자가 사용할 제품으로 내놓게 됩니다. 여느 때의 오전 10시 빌드

이건, 몇 달간 땀 흘리며 노력한 후에 나온 마지막 빌드이건 동일하게 빌드됩니다.

빌드 컴퓨터가 독립적인 개체인 덕분에 빌드는 항상 일관성 있게 이뤄집니다. 어떤

이유로든 개별 개발자의 컴퓨터를 참조하지 않습니다. 저장소에서 입력값을 받고 특별

히 고안된 빌드 컴퓨터에서 모든 과정이 이뤄져서 결과가 나옵니다. 개발자가 꽁수를

부리지 않는 한 이 시스템은 잘 돌아갑니다.

TIP 조언 2

모래 상자 안에서 노세요.

“모래 상자 안에서 놀기”가 쉽지 않을 때도 있습니다. 데이터베이스 라이센스나 웹 서

버 포트가 모자란 경우에 특히 그렇습니다. 데이터베이스를 하나만 설치하고, 개발자

마다 분리된 인스턴스를 만들어줄 수 있습니다. 인스턴스 하나만 지원하는 데이터베이

스를 사용해야 한다면, 디스크 공간을 쪼개는 방법도 있습니다(예를 들어, 조는 1000

번부터 1999번까지의 테스트 계정 데이터를 할당받고, 수는 2000번부터 2999번의

계정을 할당받는 식으로 공간을 나눌 수 있습니다). 이렇게 해도 서로 간섭할 위험은 남

아 있습니다. 하지만 안 하는 것보단 낫습니다.

웹 서비스와 같은 다른 자원의 경우에는 모든 개발자가 자신의 인스턴스가 어떤 건지

정확히 파악해야 합니다(서비스를 제공하든 테스트를 하든 간에 말입니다).

분리라는 기본 아이디어를 염두에 두고, 모래상자 효과를 달성하기 위해 필요한 다른

도구와 인프라스트럭처에 대해 알아보기로 합시다.

Page 45: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

26

It!Ship

출시할제품은어디에서나오나요?

여러분의 빌드 컴퓨터에서 고객에게 전달할 출시 제품을 만들 수도 있고, 아닐 수도 있습니다.

그러나 여러분이 사용하는 빌드 컴퓨터이든, 제품 출시용 빌드 컴퓨터이든 동일한 스크립트, 동일

한 저장소 등을 사용합니다.

몇 가지 차이는 있을 수 있습니다. 출시된 코드 집합을 기록해 놓으려고 저장소 내에 가지

(Branch)나 꼬리표(Tag)를 만들기도 하고, 다양한 플랫폼을 지원하기 위해 코드를 인스톨러로

감싸기도 합니다.

Welcome any question! 무엇이든지 물어 보세요!

Page 46: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

27

2장 도구와 인프라스트럭처

02 자산을 관리하세요

대부분의 회사는 자산 관리를 위해 대규모 시스템과 사람을 투입합니다. 말인 즉, 회사

는 컴퓨터, 자동차, 부동산, 사무용 스테플러 등의 물리적 자산을 추적합니다. 소프트

웨어 프로젝트에서는 업무가 좀 더 간단합니다. 추적해야 할 것이라곤 파일에 불과합니

다. 하지만 프로젝트가 시작된 이래로 빌드에 사용된 모든 파일의 모든 버전을 추적해

야 합니다.

이런 만만찮은 업무를 하려면 버전 컨트롤 시스템(VC)이라고도 불리는 소스 코드 관

리(SCM) 시스템이 필요합니다. 재능있는 사서가 그렇듯, 소스 코드 관리 시스템은 저

장소(또는 데이터베이스) 내의 모든 자산(파일)을 추적하고, 파일에 안전하게 접근할

수 있도록 조정합니다. 물론 이 시스템은 소스 코드를 보관합니다. 하지만 그래픽 파일,

빌드 스크립트, XML 쪼가리, 문서, 모든 사람들이 의존하는 작지만 중요한 펄(Perl)

스크립트 같은 것도 모두 관리합니다.

SCM을 제대로 설치했다면, 이런 일을 할 수 있습니다.

�팀이�프로젝트�규모의�‘취소’�버튼을�갖게�됩니다.�어떤�것도�최종적이지�않고�실수

를�쉽게�돌이킬�수�있습니다([TH03]2�참조).

�여러�명이�동시에�한�파일을�편집할�때�(또는�그러길�원할�때)�충돌을�조정할�수�있

습니다.

�여러�버전의�소프트웨어를�추적할�수�있습니다.�지난�출시�제품의�버그를�고치는�

와중에도�다음�출시�제품에�기능을�추가할�수�있습니다.

�어떤�파일이�변경됐는지�기록할�수�있습니다(언제�누가�고쳤는지도�기록할�수�있죠).�

특정�시점의�작업을�고스란히�꺼내올�수�있습니다.�

2 부록 238쪽 참고 문헌을 참조하세요.

Page 47: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

28

It!Ship

여러분의 개발사 전체가 불타버리더라도 저장소에 백업해뒀다가 복구할 수 있어야 합

니다. 제품 전체를 빌드하기 위해 필요한 모든 걸 갖고 있어야 합니다. 그렇지 못하면

아마도 도구를 제대로 사용하고 있는 게 아니겠죠.

TIP 조언 03

필요한 거라면 체크인하세요.

자바 런타임(선 마이크로시스템즈 사가 무료로 제공하는)이나 다른 특정 제품을 빼놓는

사람도 있습니다. 그런 사람은 SCM 시스템에 이런 것들을 저장해놓지 않습니다. 여러

분의 제품이 자바 런타임 같은 제품의 다양한 버전과 잘 작동한다면 괜찮습니다. 하지

만 특정 버전에 의존하고 있다면, 다른 회사가 그 제품을 계속 제공하고 지원하리라고

도박하는 셈임을 알아야 합니다.

“제품을 빌드하는 데 필요한 모든 걸 SCM에 보관하라”는 조언에 유일한 예외는 직

접 생성할 수 있는 파일입니다. 회사 내부의 다른 제품을 기반으로 만들어진 150개의

라이브러리(JAR 파일이나 DLL 파일에 저장된)가 있다고 해 봅시다. 이런 것들마저

SCM에 저장한다면 우스울 겁니다. SCM에 원래 소스 코드가 있으니, 필요하면 다시

빌드할 수 있습니다. 하지만 150개 라이브러리가 모두 타 회사에서 가져온 거라 그것

들 없이는 다시 빌드할 수가 없다면, SCM에 넣으세요.

또 한가지 고려할 점은 제품이 (그리고 회사 전체가) 사라지기도 한다는 사실입니다.

벤더가 사업에서 물러나거나 오픈 소스 도구의 지원자들이 그 제품을 지원하지 않기로

결정해도 살아남을 수 있습니까? 중요 벤더가 사업을 그만두거나 오픈 소스 프로젝트가

사라져도 제품을 내놓을 수 있습니까? 오픈 소스든 상업용이든 제품은 예상치 못하게

사라지곤 합니다.

제품을 빌드하고, 배포하고, 실행시키는 데 필요한 모든 것이 소스 코드 관리 시스템

에 있어야 합니다. 그렇지 않다면, 디스크 공간 좀 아껴볼 요량으로 개발 프로젝트의

Page 48: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

29

2장 도구와 인프라스트럭처

장기적 생존 능력을 위험에 놓이게 하는 꼴이 됩니다.

말로 표현하고 나니 멍청한 짓거리 같이 들립니다. 그렇지 않나요?

SCM을 사용하면 제품의 특정 버전 (또는 현재 버전)에 접근할 수 있습니다. 특정 변

경 내역을 되돌릴 수도 있습니다. 이렇게 일하면, 사고 때문에 개발 시간을 날리진 않

습니다. 덮어씌우거나 날려버리기엔 여러분이 한 일은 소중합니다. 여러분이 한 일을

소스 코드 시스템에 저장해서 변경 내역을 되돌릴 수 있도록 하세요.

저 개가 내 소스 코드를 먹어버렸어요.

여러분은 제품 소스 코드가 어디 있는지 아십니까? 소스 코드 전체를요? 모든 버전에

대해 알고 있나요? 확신하세요? 나머지 팀 구성원들도 여러분만큼 확신하나요?

그림 2.3 서브버전 GUI 클라이언트가 보여주는 리비전 변경 내역

Page 49: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

30

It!Ship

적당한 사례를 들어보죠. 우리가 참여했던 작은 닷컴 벤처 기업은 최신식 소스 코드

컨트롤 시스템에 6자리나 되는 돈을 썼습니다(아 벤처 캐피털의 즐거움이란!). 하지만

그들은 시스템을 설치조차 하지 않았습니다. 세 개발자 (네, 세 명뿐이었습니다.) 각

자는 완전히 다른 버전의 제품 코드를 갖고 있었습니다. 자신만의 고유한 버그 집합과

함께요.

이 중 어느 버전도 회사가 잠재적인 고객에게 보여줬던 데모와 일치하지 않았습니다.

서로 다른 버전을 조정하려고 엄청나게 노력한 뒤에야, 결국 포기하고 앞으로 사용할

버전을 하나 골랐습니다.

SCM을 설치하고 선택한 버전의 코드를 넣고, 그때부터 그 코드를 부지런히 사용했

습니다. ‘진짜’ 프로젝트 코드가 어느 것인지 모르는 사람이 없게 됐고, 개발자는 마음

의 평안을 찾아갔습니다. 이와 더불어 제품의 품질도 개선되었습니다.

어떻게 시작하면 될까요?

어떤 종류의 소스 코드 컨트롤 시스템도 사용하고 있지 않다면, 그걸 최우선 순위로 놓

으세요.

최근 조사에 따르면 미국 내 IT 기업 중 약 40 퍼센트는 소스 코드 또는 버전 컨트롤

제품을 전혀 사용하지 않는다고 합니다.

�몇몇�SCM�시스템을�평가해보세요(205쪽�부록�B를�참조하세요).�우리는�진심으

로�CVS나�서브버전을�추천합니다(앞�쪽의�그림�2.3을�보세요).

둘�다�무료이고�세계에서�가장�큰�소프트웨어�회사들이�사용하고�있습니다.�상

업용�솔루션을�선택하더라도,�이�제품들은�기능을�비교하는�데�기준이�되어�줄�

겁니다.�

2. SCM�사용법을�익히세요.

1.

Page 50: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

31

2장 도구와 인프라스트럭처

3. �흔히�쓰는�기능을�어떻게�사용하는지�알려줄�한�페이지짜리�퀵-스타트�가이드

(Quick-Start�Guide)를�만드세요(주의�사항을�알려주는�‘경고�신호’를�보려면�

39쪽의�목록을�확인하세요).

4. �팀원에게�시스템을�보여주세요.�모든�사람이�그�시스템을�편안하게�느끼도록�만

드세요.

5. 코드와�지원�파일을�임포트(Import)하세요.

6. 모든�파일을�SCM으로�관리하세요.

내가 제대로 하고 있는 걸까요?

우선, 시스템을 활발하게 사용하고 있나요? 코드 체크인 간격이 몇 주-며칠일지라도-

씩이나 된다면, 활발히 사용하고 있는 게 아닙니다. 이것은 (여러분이 한 일을 백업하

고, 정확하고 세밀한 내역을 유지한다는) 본래 목적 전체를 망칩니다. 작성한 코드가

출시용 트리(production tree)에 들어갈 준비가 안 되어 있더라도, 시스템에 개인적

인 공간을 만들어서 코드를 두면 됩니다.

당장 워크스테이션의 하드 드라이브가 망가진다면, 어느 정도의 작업을 잃게 됩니까?

하루나 이틀 치 이상이라면, 일하는 방식을 바꿔보세요.

새 기계를 가져와서 개발 준비를 하는 데 얼마나 걸리나요? 모든 빌드 스크립트와 개

발 자원을 체크인 해놨습니까?

SCM의 기능을 신속히 수행할 수 있습니까? 코드를 체크아웃하는 데 20분 걸리고,

변경 내역을 체크인 하는 데 또다시 15분이 걸린다면, 체크인을 자주 할 리 없습니다.

기본적인 상호작용은 빨라야 합니다.

차이점 내역을 불러내는 것과 같은 동작은 CPU와 디스크에 엄청난 부담을 줍니다.

그런데도 노후한 컴퓨터에 SCM 소프트웨어를 놓아서 모든 상호작용을 고되게 만드는

회사가 꽤나 많습니다.

Page 51: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

32

It!Ship

하드웨어는 싸지만 개발 시간은 비쌉니다. 교육, 하드웨어 구매, 또는 새 SCM 소프

트웨어 때문에 얼마가 들던, SCM은 여러분을 따라갈 수 있을 정도로 빨라야 합니다.

SCM 저장소를 백업하고 있나요? 오늘밤 회사 빌딩이 불타버리더라도, 다른 컴퓨터

에 복구할 수 있도록 외부 백업을 하고 있나요? 저장하고 있는 데이터를 잃어버린다면

훌륭한 SCM일지라도 아무 소용 없습니다. 최소한 주 단위로 완벽한 외부 백업을 받아

놓도록 하세요.

마지막으로, 시스템이 다음의 기본적인 작업을 쉽게 수행할 정도는 되는지 알고 있습

니까? 여러분이 알아둬야 할 최소한의 작업 목록입니다.

프로젝트�전체를�체크아웃하기

SCM에�저장된�최근�코드와�수정한�코드�사이의�차이점�보기

�특정�파일의�역사(History)�보기–이�파일을�변경한�사람이�누구이고,�언제�변경

했는지

다른�개발자가�변경한�것을�로컬�복사본에�업데이트하기

변경한�것을�SCM에�밀어�넣기�(다시�말해,�커밋하기)

SCM에�밀어�넣은�최근�변경�내역을�제거하기�(또는�취소하기)

지난�화요일에�있던�그대로�소스�트리의�복사본을�가져오기

경고 신호

�활동�없는�저장소.�사용되지�않는�저장소는�쓸모�없는�저장소입니다.�개발자�각자

가�정기적으로�체크인하고�체크아웃해서,�매�시간마다�활동하는�걸�볼�수�있어야�

합니다.

�완전하지�못한�저장소.�제품을�빌드하는�데�필요한�파일�중�일부만�갖고�있다면,�

제�역할을�못하고�있는�겁니다.�‘실험용’�출시나�테스트용�소스�트리가�저장소에�저

Page 52: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

33

2장 도구와 인프라스트럭처

장�안�된�것은�아닌지�주의하세요.�중요한�XML�파일이나�데이터베이스의�컨텐트

도�마찬가지입니다.

�느린�접근.�파일을�체크인하거나�체크아웃하는�데�오래�걸리면,�결국�사람들은�시

스템을�사용하지�않을�겁니다–지금은�시스템을�사용하고�있더라도�말이죠.

�잃어버린�파일,�손상된�파일.�어떤�버전�컨트롤�시스템(이름은�거론하진�않겠지만�

어떤�큰�회사가�만든)은�주기적으로�파일을�‘먹어’버리는�것으로�유명합니다.�무료

로�사용할�수�있는�CVS3나�서브버전4과�같은�진짜�시스템으로�업그레이드�하세요.

3 http://www.cvshome.org

4 http://subversion.tigris.org

Page 53: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

34

It!Ship

03 빌드를 스크립트화 하세요

빌드는 소스 코드를 동작 가능한 프로그램으로 바꾸어놓습니다. 프로그래밍 언어와 컴

퓨터 환경에 따라, 이것은 여러분이 소스 코드를 컴파일하고 필요하다면 이미지 파일과

다른 자원을 하나로 묶게 됨을 뜻합니다. 컴파일과 자원을 묶는 작업에 사용되는 스크

립트, 프로그램, 기술이 모두 합쳐져 빌드 시스템이란 걸 만들어냅니다.

IDE 내에서 컴파일하고 빌드하는 걸 말하는 게 아님을 기억해주세요. 대부분의 경우

엔 프로젝트를 컴파일 하는 데 개발자 개인의 IDE 사용하고 싶진 않을 겁니다. 여러분

혼자 그 IDE를 사용한다고 해도요(23쪽의 2_01절 ‘모래 상자 안에서 개발하기’를 참

고하세요). 빌드 컴퓨터에서 ‘공식’ 빌드를 하는 것과 병행하여 여러분 자신의 컴퓨터에

서도 빌드해야 함을 말하려 합니다. 왜 그런지 설명해줄 짧은 이야기를 읽어보시죠.

빌리는 제품을 빌드할 준비가 됐습니다. 그래서 IDE를 실행시키고, 올바른 프로젝

트다 싶은 걸 엽니다. 빌리는 IDE를 사용해 프로젝트를 다시 빌드합니다. IDE가 일을

끝내자, 빌리는 IDE를 종료시키고 프로그램을 인스톨러 디렉토리에 복사합니다. 그런

후 인스톨 프로그램을 열어서 빌드한 프로그램을 지정해서 인스톨러를 빌드하라고 시

킵니다.

인스톨러가 만들어지자, 빌리는 인스톨러가 제대로 작동하는지 확인하려고 인스톨러

를 실행시킵니다. 인스톨러는 곧바로 오류를 냅니다. 빌리는 제품에 사용하는 제삼자

의 위젯 최신 버전을 복사하는 걸 깜박 잊었다는 사실을 기억해냅니다. 그래서 위젯 최

신 버전을 인스톨러 디렉토리에 복사합니다. 인스톨러를 다시 빌드한 후, 그는 프로그

램이 사용하는 그래픽 파일의 최신 버전을 복사했어야 했다는 걸 깨닫습니다. 그리고…

마라톤 같이 끝이 보이지 않습니다. 그렇지 않나요? 빌리는 밤 늦게까지 일한데다가

수당을 받지 못하는 초과근무를 하는 바람에 ‘버피’5 재방송을 놓쳤습니다.

5 미국의 인기 드라마. 여주인공이 예쁘답니다.

Page 54: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

35

2장 도구와 인프라스트럭처

밥 역시 오늘 자신의 제품을 빌드할 겁니다. 밥은 코드가 있는 폴더로 가서 빌드 스크

립트를 실행시키기 위해 한 줄짜리 명령어(예를 들어, ant build_installer 나 make

all과 같은)를 칩니다. 스크립트가 (제품에 필요한 모든 걸 자동으로 가져와서) 제품을

빌드하고, 인스톨러를 만들고 테스트합니다. 밥이 할 일은 끝났습니다.

이 시나리오를 통해 자동화된 빌드 시스템을 사용하는 것과 수작업으로 제품을 만들

어나가는 것의 차이를 알 수 있습니다. 빌리는 수많은 실수를 저질렀습니다. 빌드를 자

동화함으로써 밥이 피해갔던 실수들이죠. 빌리가 까먹고 수행하지 않았던 단계를 밥의

스크립트는 자동으로 처리해줬습니다.

빌리가 늦게까지 일하는 걸 보고 더 성실한 사원이라 생각할 사람이 많을지도 모르지

만, 우리는 차라리 밥과 일하겠습니다(아니면 밥처럼 일해야죠!). 과정을 자동화함으로

써 각 단계를 보다 정확하게 만들 뿐 아니라 (에러 날 가능성도 줄어듭니다) 일찍 퇴근

할 수도 있습니다. 밥처럼 말이죠.

갖가지 방식으로 제품을 빌드할 수 있습니다. 이와 비슷한 절차를 밟아나가면 됩니다.

코드를�컴파일한다.

컴파일된�코드를�인스톨러�프로그램에�복사한다.

�(예를�들어,�데이터베이스�드라이버와�파서�같은)�제삼자가�만든�라이브러리�최

신판을�옮겨놓는다.

HTML�파일이나�그래픽�파일처럼�코드가�아닌�파일을�가져다�놓는다.

설명서를�인스톨러에�복사해�넣는다.

인스톨러를�빌드한다.

빌드나 패키징 과정에서 손으로 하는 작업이 있다면 문제가 있는 겁니다. 초반에 시간

을 투자해서 문제를 해결할 것인지, 매번 손수 작업을 처리해나가느라 시간을 낭비하다

가 한 단계를 빼먹거나 실수하는 바람에 부득이한 문제가 벌어지고 나서야 문제를 해결

1.

2.

3.

4.

5.

6.

Page 55: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

36

It!Ship

할 것인지, 어느 것을 선택하시겠습니까? 첫 번째 옵션을 고르면 프로젝트 초반에 시간

을 현명하게 투자하는 겁니다. 두 번째 옵션은 블랙홀입니다. 제품 생명에 문제와 좌절

을 일으키는 원천이 될 겁니다. 다시 말해, 튼튼한 집을 짓는 데 기초를 날림으로 하면

나중에 훨씬 더 열심히 일해야만 합니다.

TIP 조언 04

첫날에 빌드를 스크립트화 하세요.

적어도 배치 파일이나 셸 스크립트를 사용해서 빌드를 수행하세요(물론 이보다 나은 방

법이 많습니다. 곧 알아볼 겁니다).

잠깐만요! 울고 계시네요. 그냥 IDE를 써서 이런 단계를 수행하면 안 되냐구요? 글

쎄요. 그렇게 할 수는 있지만 이런 문제가 있습니다.

�빌드�컴퓨터가�같은�IDE를�사용할�것�같진�않네요(IDE를�배치�모드에서�작동시키

는�건�대체로�성가신�일입니다.�심지어는�불가능할�때도�있습니다).

�(고참이든�신입이든�간에)�팀�전체가�같은�IDE를�쓰도록�강요해야�할�겁니다.�그게�

받아들여질�만�할�때도�있겠지만,�해결되는�문제보다�발생하는�문제가�많습니다.

�모든�사람이�같은�IDE를�쓰더라도�(새�라이브러리,�다른�컴파일러�설정�같은)�개발�

환경�상의�변경�사항을�모두에게�전달하기�힘들�수�있습니다.

극복하지 못할 정도는 아니지만, 다루기 까다로운 문제입니다. 이 때문에 우리는 빌드

자동화를 IDE 세상으로부터 분리시키는 편이 훨씬 쉽다는 사실을 알게 됐습니다. 하지

만 빌드가 아무리 복잡하더라도 명령 하나로 실행시킬 수 있어야 합니다.

명령 하나로 프로젝트를 빌드할 수 없다면 팀 구성원 대부분은 신경 쓰려 하지 않을

겁니다. 다른 일도 마찬가지겠지만, 쉽지 않으면 아무도 하지 않습니다. 모든 개발자

컴퓨터에서 프로젝트를 손쉽게 (그리고 한결같이) 빌드할 수 있다는 건 훌륭한 개발팀

이 되어간다는 징표입니다.

Page 56: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

37

2장 도구와 인프라스트럭처

우리의 희망과는 달리, 항상 일이 잘 풀리는 건 아닙니다. 우리는 가지각색의 회사를

다녔었지만 그 중 한 회사에서는 특정 컴퓨터에 설치된 특정 IDE 안의 버튼을 눌러서

제품을 빌드했습니다. 그러다가 그 빌드를 구성한 개발자가 회사를 떠났습니다. 남은

개발자 중 누구도 떠나버린 개발자의 컴퓨터와 그 ‘마법 버튼’ 없이 시스템을 빌드할 방

법을 몰랐습니다. 우리는 코드를 어떻게 빌드했었는지 관리자에게 말해줬습니다. 그러

자 그들은 몹시 충격을 받았고 어찌할 바를 몰랐습니다.

회사 내의 어떤 컴퓨터에서라도 똑 같은 방법으로 제품을 빌드할 수 있어야 합니다.

만약 여러분이 제품 빌드 방법을 모른다면, 다른 사람이 알 가능성도 희박합니다.

TIP 조언 05

어떤 컴퓨터에서라도 빌드가 되어야 합니다.

긴급한 상황에서 (체크인 해놨던) 똑같은 스크립트를 사용함으로써 개발자 컴퓨터로 빌

드 컴퓨터를 대체할 수 있습니다. 어떤 컴퓨터에서 뽑은 빌드라도 빌드 컴퓨터에서 뽑

아낸 빌드와 한 비트까지도 같도록 하는 게 목표입니다(타임스탬프, 컴퓨터의 IP 주소

나 이름 같은 건 제외하구요).

빌드 스크립트가 복잡해야 하는 건 아닙니다. 이 예제는 완전하고 쓸모있는 Ant 스

크립트입니다. 그러면서도 꽤나 시원스럽고 읽기 쉽습니다(XML의 꺾음 괄호에도 불구

하고 말입니다).

<?xml version="1.0" ?>

<project name="SimpleExample" default="doall">

<property name="build.dir" value="./build" />

<property name="dist.dir" value="./dist" />

<target name="init">

<mkdir dir="${build.dir}" />

Page 57: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

38

It!Ship

<mkdir dir="${dist.dir}" />

</target>

<target name="compile" depends="init">

<javac srcdir="."

destdir="${build.dir}"/>

</target>

<target name="dist" depends="compile">

<jardestfile="${dist.dir}/SimpleExample.jar"

compress="true">

<filesetdir="${build.dir}"/>

</jar>

</target>

<target name="doall" depends="dist">

</target>

</project>

어떻게 시작하면 될까요?

자동화된 빌드가 없는 새 제품을 물려 받았다면, 다음 단계를 밟아 빌드 스크립트를

제대로 갖춰놓아야 합니다.

�여러분이�스트립트를�작성하는�동안은�팀�구성원�한�명을�뽑아�수동으로�시스템

을�빌드하게�하세요.

각�빌드�단계를�정의하세요.

�빌드�도구를�선택하되�그�도구가�짐이�되면�다른�선택사항을�다시�검토할�준비

를�하세요.�

�각�단계를�점진적으로�스크립트화하세요.�수작업을�하나하나�제거해나가세요.

�다른�컴퓨터에서�스크립트를�돌려보세요.�특정�컴퓨터에서만�작동되는�코드를�

찾아낼�수�있습니다.

1.

2.

3.

4.

5.

Page 58: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

39

2장 도구와 인프라스트럭처

�이제�여러분이�도와주지�않아도�다른�팀�구성원이�스크립트를�사용할�수�있는지�

확인해보세요.

이런 조치를 취하고 나면 모든 사람이 쓸 수 있는 스크립트를 갖게 될 겁니다.

제대로 사용하고 있는 걸까요?

다음 조건을 충족시킨다면, 수동 빌드 시스템을 제대로 사용하고 있는 겁니다.

명령어�하나면�빌드가�됩니다.

소스�코드�관리�시스템(SCM)에서�코드를�내려�받아�빌드할�수�있습니다.

어느�컴퓨터에서라도�빌드가�됩니다.

외부�환경(특정�네트워크�드라이브�같은)에�의존하지�않고도�빌드가�됩니다.

이 항목 중 하나라도 문제가 있다면, 여러분의 빌드 과정을 다시 들여다보세요.

경고 신호

빌드에�수작업�단계가�포함되어�있습니다.

다른�컴퓨터에서�돌리려면�빌드�스크립트를�수정해야�합니다.

팀�구성원�중�몇�명만이�빌드�스크립트를�수정할�줄�압니다.

6.

Page 59: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

40

It!Ship

04 자동으로 빌드하세요

무인 빌드는 자동으로 빌드하는 걸 말합니다. 하지만 자동 빌드를 구현하기 전에 명령

하나로 실행시킬 수 있는 수동 빌드 시스템부터 제대로 갖추고 있어야 합니다. 제대로

된 수동 빌드 시스템을 갖추고 있지 못하다면 34쪽의 2_03절 ‘빌드를 스크립트화하세

요’로 돌아가세요. 존재하지도 않는 프로세스를 자동화할 수는 없습니다.

일단 제품을 자동으로 빌드할 수 있게 됐다면, 얼마나 자주 빌드를 해야 할까요? 이

상적으로는 코드가 변경될 때마다 다시 빌드해야 합니다. 그렇게 하면 어떤 변경사항이

빌드를 깨뜨리는 즉시 그 사실을 알 수 있습니다. 빌드 시스템에 가볍게 구성된 스모크

테스트(Smoke Test)6 집합을 추가하세요. 그러면 기본적인 수준의 기능적 보험 또

한 얻게 됩니다. 이런 종류의 시스템을 지속적인 통합(Continuous Integration)이

라 부릅니다. 지속적인 통합(CI라고도 하는) 도구는 깨끗한 비개발자 컴퓨터(빌드 컴퓨

터)에서 누군가 코드를 커밋할 때마다 프로젝트를 다시 빌드합니다. 코드가 커밋될 때

마다 다시 빌드하면 컴파일 에러가 나자마자 잡아냄으로써 코드 베이스를 깨끗하게 유

지할 수 있습니다. 테스트 수트를 돌려서 기능적 에러도 잡아낼 수 있습니다. 우리는

CruiseControl7이라는 오픈 소스 CI 도구를 사용합니다. 지원이 잘 되는 데다가 확

장성도 뛰어나며 공짜이기까지 합니다!

불행하게도 대부분의 개발 회사(거의 70 퍼센트나 됩니다. 부록 H.1 [Cus03] 참고)가

CI 시스템은 고사하고 일일 빌드조차 신경쓰지 않습니다. CI 시스템을 갖추고 있는 회사

들은 끊임없이 더 나은 코드와 좀 더 안정된 제품을 내놓는 최고의 회사에 속합니다. 어쩌

면 이런 종류의 기술을 소개할만한 회사라면 매우 앞서 있을 것이며, 그렇기 때문에 더 나

은 코드를 내놓는 거라 주장할지도 모르겠습니다. 하지만 우리는 동의하지 않습니다.

6 55쪽, 2_07절 '테스트 장비를 사용하세요' 또는 http://msdn2.microsoft.com/ko-kr/library/ms182613(VS.80).

aspx 를 참고하세요.

7 CruiseControl은 SourceForge.net에서 호스팅 받고 있는 오픈 소스 지속적인 통합 시스템입니다. http://cruisecontrol.

sourceforge.net/

Page 60: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

41

2장 도구와 인프라스트럭처

우리는 모든 질 나쁜 커밋을 거의 즉시 잡아내는 충실한 ‘가상 빌드 모니터’를 갖음으

로써 이득을 볼 수 있다고 믿습니다. CI 도구는 컴파일되지 않는 코드를 항상 표시해

놓습니다. 또한 여러분이 추가하는 걸 잊어먹은 새 파일이나 수정했던 파일도 잡아냅

니다. 자동화된 빌드 시스템은 우리 인간이 곧잘 놓치는 상세 내역을 잡아내는 데 선수

입니다.

TIP 조언 06

지속적으로 빌드하세요.

그림 2.4 CuriseControl 상태 보고서 웹 페이지

Page 61: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

42

It!Ship

뿐만 아니라 여러분은 “컴파일 되나?”에서 “작동하나?” 단계로 넘어갈 수 있습니다. 테

스트 수트를 잘 선택함으로써 기본적인 기능성을 다시 테스트하고, 버그가 다시 발생하

는 것(버그 회귀)을 막을 수 있습니다. 이런 시스템이 있다면, 개발자들은 컴파일 실패

를 해결하거나 같은 버그를 계속해서 다시 고치는 대신 기능을 추가하는 데 시간을 쏟

을 수 있습니다. 수동 테스트로는 이런 정도의 보장을 해줄 수가 없습니다. 모든 코드

변경에 대해 즉시 피드백을 줌으로써 문제를 조기에 잡아내서 빨리 고칠 수 있습니다.

이것은 CI 시스템을 가진 회사가 다른 곳보다 항상 우월할 수밖에 없는 가장 큰 이유 중

하나입니다.

여러분의 회사를 CI 시스템을 가진 회사 범주에 넣으세요. 여러분이 생각하는 것보

다 더 쉽고, 효과가 어마어마할 겁니다.

버그회귀가뭔가요?

버그 회귀란 고쳤던 문제가 슬그머니 코드로 돌아오는 걸 말합니다. 실수로 나쁜 코드를

SCM에 넣거나 (문제를 고친 다음에 말이죠), 똑같은 실수를 다시 저질렀을 때 이런 문제가 발생합

니다. 버그가 다시 발생하면 기운이 많이 꺾입니다.

여러분이 고친 모든 버그에 대해 테스트를 작성하고 CI 시스템에서 그 테스트를 돌린다면, 문

제 있는 코드가 커밋될 때 버그 회귀를 잡아낼 수 있습니다. 이 전략은 버그 회귀를 효과적으로 차

단합니다.

Welcome any question! 무엇이든지 물어 보세요!

TIP 조언 07

지속적으로 테스트하세요.

Page 62: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

43

2장 도구와 인프라스트럭처

세계에서 가장 큰 개인 소유의 소프트웨어 기업인 SAS(무슨 인연인지 우리의 고용주

랍니다)에선 500만 줄이 넘는 코드가 CI 시스템 아래 있습니다. 사실, 일반적으로 여

러 개의 가지(Branch)가 이 정도 크기이니, 실제로는 500만의 갑절이나 되는 코드가

관리되고 있는 겁니다(참고 문헌 [Cla04]8에 실린 우리의 이야기를 보세요). 만약 CI

가 그만한 크기에서 작동한다면, 여러분의 회사에서도 작동할 겁니다.

CI 시스템이 정말 그만한 가치가 있을까요? 글쎄요. 우리가 경험했던 꽤 큰 회사에

서는 한 빌드가 실패하면 연쇄적인 문제를 일으켜서, 전사적으로 150여 개의 다른 프

로젝트가 밤샘 빌드에 실패하게 만드는 중요한 프로젝트가 있었습니다. CI 시스템이

오후 일찍 에러를 잡아냈지만, 시스템이 베타 상태였고 감시하는 이도 없어서, 그날 밤

150여 개의 프로젝트가 빌드되지 못 했습니다. 이 작은 결함이 여러 대륙의 개발 팀에

충격을 주었습니다. 이 사건 바로 직후에 이런 종류의 오류를 막으려고 전사적인 규모

로 CI 시스템을 도입하는 데 박차를 가했습니다.

프리젠테이션

CI 시스템을 설치하기로 결정했으면, 결과를 어떻게 제출할지 좀 생각해봐야 합니다.

모든 CI 시스템이 HTML로 결과를 출판할 수 있습니다. 또한 대부분의 CI 시스템은

이메일을 보낼 수도 있습니다(122쪽 3_14절 ‘코드 변경 통지 보내기’를 보세요). 하지

만 이것은 빙산의 일각에 불과합니다. 약간만 손보면 보다 흥미로운 방식으로 결과를

보여줄 수 있습니다.

빌드 시스템에 RSS 피드(77쪽의 ‘RSS가 뭔가요’를 보세요) 기능을 넣으세요. RSS

피드는 빌드 정보를 밀어냄으로써 사람들이 끝없이 밀려오는 이메일을 헤쳐 나가지 않

게 해줍니다.

8 [Cla04] Mike Clark. Progmatic Project Automation. How to Build, Deploy, and Monitor Java Application.

2004. 238쪽, 참고 문헌 참조.

Page 63: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

44

It!Ship

라바 램프(Lava lamp)를 추가하세요. 대부분의 빌드 시스템은 X10 모듈(X10

module)9을 사용해서 시각 장치를 조정합니다. 라바 램프10를 사용하는 사람도 있고

오비언트 오브(Ambient Orb)11를 선호하는 이도 있습니다. 그렇지만 여러분 마음에

드는 거라면 뭐라도 상관 없습니다. 알림 장치를 즐겨보세요.

어떻게 시작하면 될까요?

좋은 빌드 시스템부터 제대로 갖추고 있어야 자동화된 빌드 시스템이라는 다음 단계로

나갈 수 있습니다.

사용할�자동�빌드�시스템을�선택하세요.�직접�만들지는�마세요.12

빌드�시스템을�돌릴�‘깨끗한’�컴퓨터를�구하세요.

�자동�빌드�시스템을�설치하고�여러분의�환경에�맞춰�설정하세요.�모든�설치�과

정을�문서화해�놓으세요.

그게 다입니다! 이런 종류의 시스템은 꽤나 쉽게 설치할 수 있고, 투자 대비 수익률(관

리층에는 ROI라고 알려져 있는)은 보통 첫 몇 달 안에 손익분기점에 달합니다. 만약

관리층이 그 이점을 보지 못하면, 우선 자신의 컴퓨터에서 시스템을 돌리세요. CI 시스

템을 사용해 본 적이 없는 사람은 실제 시연을 봐야지만 그 개념이 얼마나 강력한지를

인정하게 됩니다.13

9 X10 모듈은 여러분의 컴퓨터에서 전기 스위치를 제어할 수 있습니다. 사람들은 X10 모듈을 사용해서 형광등에서 라바 램프에 이

르기까지 어떤 종류의 장치라도 조정합니다. http://x10.com 에서 확인해보세요.

10 마이크 클라크가 한 것처럼 말이죠. http://www.pragmaticprogrammer.com/pa/pa.html

11 마이클 스완슨의 블로그는 http://blogs.msdn.com/mswanson/articles/169058.aspx 입니다.

12 우리는 즉석 알림 시스템을 직접 만들려고 하는 사람을 여럿 보았습니다. 하지만 공짜로 쓸 수 있는 완전히 검증된 기업 수준의 CI

시스템이 있는데 왜 그런 일을 합니까? 완전히 무르익은 프로젝트가 갖고 있는 보고 기능이나 특징의 절반도 추가하지 못 할 겁니다.

215쪽 부록 D에 CI 제품 목록을 보세요. 아무튼 바퀴를 다시 발명하는 건 실용적이지 못합니다.

13 CI 시스템을 빨리 익히고 싶다면, 마이크 클라크가 제작한 ‘CruiseControl in Action’ 동영상을 보세요. http://media.

pragprog.com/movies/auto/CruiseControl_MikeClark.html.

1.

2.

3.

Page 64: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

45

2장 도구와 인프라스트럭처

사고가났어도그사실을아는사람이없다면…

세상에서 가장 좋은 빌드 시스템이라도 여러분이 결과를 보지 않는다면 아무 소용 없습니다. 대부분

의 시스템은 자동으로 이메일을 보냅니다. 이 기능을 활용하세요. 우리는 이 기능에 대해 엄청나게

저항하는 모습을 본 적이 있습니다. 하지만 일단 팀이 익숙해진 뒤에는 이메일을 수용하고 그 혜택

을 받아들이는 모습 또한 보았습니다. 여러분은 이런 통보 기능에 의존하게 될 것입니다. 그리고 결

국에는 ‘모든 게 정상이다’라는 메시지가 도착하고서야 하루 일과를 마칠 수 있게 될 겁니다.

제대로 사용하고 있는 걸까요?

만약 여러분이 자동 빌드 시스템 (또는 CI 시스템)을 사용하고 있다면, 대부분의 소프

트웨어 팀보다는 한참 앞서 있는 겁니다. 하지만 여전히 여러분 스스로에게 물어봐야

할 질문이 있습니다.

�시스템에�테스트가�포함되어�있습니까?�아무튼�시스템이�작동하지�않는다면�컴파

일이�되든�말든�아무도�관심을�두지�않습니다.

시스템에�신경�쓰는�사람이�있습니까?�알림�시스템은�켜져�있습니까?

빌드가�깨지면�빨리�고쳐집니까?�아니면�며칠씩�그대로�방치됩니까?

�합리적인�시간�내에�빌드가�끝납니까?�아니면�너무�오래�걸려서�끝날�기미가�안�보

입니까?

이런 질문에 우호적으로 답변할 수 있다면, 여러분의 팀은 기능을 추가하는 데 시간

을 쏟을 수 있을 겁니다. 마지막 6개월이 남은 어느 시점에 기능 X를 깨뜨린 코드가 어

느 줄에 있는지 추적하지 않아도 됩니다.

Page 65: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

46

It!Ship

경고 신호

자동�빌드�시스템이�자주�깨집니다.

팀이�깨진�빌드를�무시합니다.

빌드가�멈추고,�누구도�눈치채지�못합니다.

05 이슈를 추적하세요

이슈 목록은 꽤나 간단한 개념입니다. 누군가 버그나 다른 중요한 이슈를 보고하면, 여

러분은 잊어먹지 않도록 그 보고서의 사본을 보관하고 싶을 겁니다. 꽤나 간단합니다.

그렇죠?(개발자들은 버그에 대해 말할 때 지나치게 까다롭게 굴곤 하기 때문에, 우리는

보다 부드럽고 정치적으로 올바른 용어인 ‘이슈’를 사용할 겁니다).

하지만 이슈를 추적하는 것은 이슈 자체를 단지 설명하는 것 이상의 일입니다. 이슈

의 세부 사항에 대해 효과적으로 의사소통하고, 세부사항을 추적할 때는 신중을 기해야

합니다. 다음 사항을 알아둘 필요가 있습니다.

어느�버전의�제품에�이슈가�있습니까?

어느�고객이�그�이슈에�부딪혔습니까?

얼마나�심각합니까?

�그�문제가�사내에서�재현되었습니까?�(누가�재현했습니까?�여러분이�그�문제를�재

현할�수�없을�때�그들이�도와줄�수�있습니다.)

고객의�환경(운영체제,�데이터베이스�등등)은�무엇입니까?

어느�버전의�제품에서�이슈가�처음�발생했습니까?

어느�버전의�제품에서�이슈가�고쳐졌습니까?

누가�이슈를�고쳤습니까?

Page 66: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

47

2장 도구와 인프라스트럭처

누가�수정�사항을�검증했습니까?

시간이 지남에 따라, 화이트보드나 종이카드로는 감당할 수 없는 수준에 이르렀음을 눈

치채게 될 겁니다. 프로젝트의 복잡도는 매우 급격하게 증가합니다. 이런 매체들로 정

보를 보관할 수 있는 건 분명하지만, 검색을 하거나 기술 지원팀을 위해 웹 페이지에 게

시할 수는 없습니다. 화이트보드나 종이카드는 확장이 잘 안될 뿐더러 공유하기도 어렵

습니다. 그보다는 데이터베이스에 정보를 보관하세요.

데이터베이스가 있다면, 고객이 전화를 걸어왔을 때 기술 지원팀이 이슈를 신속하게

찾아볼 수 있습니다. 기술 지원팀은 고객에게 이슈를 이미 알고 있다는 것과 다음 버전

에서 그 문제가 고쳐질지 여부를 말해줄 준비가 되어 있어야 합니다(아래의 그림 2.5에

서 예를 볼 수 있습니다).

그림 2.5 이슈 추적 입력 스크린 예제

* 오픈 소스 프로젝트 X 한글 입력기 ami 에서 스크린샷을 찍었습니다.

Page 67: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

48

It!Ship

여러분은 장기적이고 제품 전반에 걸친 (그리고 회사 전반에 걸친) 기억을 만들어내

야 합니다. 그렇지 않으면 회사 규모의 알츠하이병에 걸리는 수밖에 없습니다. 발견했

던 문제를 힘들게 다시 발견하는 게 계속될 겁니다. 고객 뿐만 아니라 테스터와 개발자

를 좌절시키고 그들의 시간을 낭비하게 되겠죠.14

TIP 조언 08

모두가 잊어버리는 사태는 피해야 합니다.

좋은 이슈 추적 시스템이라면 주어진 제품에 대해 활동 보고서를 생성해줄 겁니다. 얼

마나 많은 이슈가 입력됐는가? 얼마나 많은 이슈가 고쳐졌고, 얼마나 오래 걸렸는가?

등등. 이런 종류의 보고서는 프로젝트의 문제 지점을 파악하는 데 사용될 수 있습니다

(연구에 따르면, 버그, 이슈는 서로 응집되는 경향이 있습니다. 고르게 분포되는 경우

는 거의 없습니다).

추적 시스템을 사용해서 제품의 알려진 이슈 목록이나 개발자가 해야 할 일의 목록을

생성할 수 있습니다. 만약 이슈를 고치는 사람이 없다면, 이슈를 찾느라 시간 낭비해봐

야 무의미합니다.

작은 소프트웨어 벤처에서 일하고 있는 용감한 개발자 해리와 로이드의 경우를 생각

해보죠. 우리가 그들을 만났을 때, 그들은 책상 위 벽에 포스트잇을 붙여서 모든 이슈

를 추적했습니다. 이 작은 종이 쪼가리가 그들이 버그를 추적하는 유일한 수단이었습니

다. 그들은 이렇게 해도 문제없다고 우리를 안심시켰습니다. 그래도 우리는 표준 이슈

추적 패키지를 사용해야 한다고 주장 했습니다. 우리는 약간 불안했고, 아직 문제가 생

기진 않았어도 이 시스템을 고치자고 말했습니다. 하지만 그들은 우리를 달랬고, 우리

는 새 시스템으로 넘어갔습니다.

14 여러분이 이미 알고 있다고 말하는 한 고객은 거의 모든 문제를 용서한다고들 말합니다. 고객이 여러분에게 버그를 알려줘야 하는

상황이라면, 그들은 아무것도 용서치 않습니다.

Page 68: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

49

2장 도구와 인프라스트럭처

이제 이 기업은 주요 수입원 중 하나가 될 매우 큰 고객사를 갖게 됐습니다. 어느 날

이 고객사가 전화를 걸어서 이슈 X가 언제쯤 고쳐질 건지 알고 싶다고 했습니다. 그들

은 두 릴리즈 전에 이 이슈를 알렸고, 참을성 있게 기다리는 일에도 지쳤다고 말했습니

다. 왜 우리가 그들을 무시하는지 알고 싶어했습니다. 해리와 로이드는 그 이슈에 대해

들은 바가 없었고, 고객이 단순히 혼동하는 거라고 주장했습니다. 우리는 결국 그 이슈

를 고쳤고, 그 고객사는 화를 조금 풀었습니다. 하지만 우리는 그 고객을 ‘열광하는 팬’

수준으로 되돌려 놓지는 못했습니다.

6개월 후, 해리의 책상을 옮기다가 바닥에 떨어져 있는 포스트잇을 발견했습니다.

고객의 이슈에 뒤이어 크고 붉은 글씨로 “중요! 잊지 말 것!”이라고 쓰여 있었습니다.

포스트잇이 책상 뒤로 떨어지자, “눈에서 멀어지면 마음도 멀어진다”라는 격언대로 그

들은 그 이슈에 대해 잊고 말았습니다. 여러분이 이슈 추적 시스템을 사용하면, 해리와

로이드에겐 없었던 안전망을 갖게 될 겁니다.

이슈 추적 시스템은 상세 내역을 기록합니다. 여러분이 어떤 일을 해놨는지, 무엇을

고쳤는지 고치지 않았는지, 그리고 무엇을 고칠 예정인지를 추적하려면 이슈 추적 시스

템이 필요합니다. 화이트보드, 인덱스 카드, 또는 용수철로 철한 공책이라도 몇 달간

은 여러분의 요구를 감당할 수 있을 수 있습니다. 하지만 그렇게 오래가지는 못 합니다.

기업 수준으로 확장할 수 없다는 것은 분명합니다.

어떻게 시작하면 될까요?

만약 지금 이슈 추적 시스템을 갖고 있지 않다면, 기다리지 마세요. 여태까지 부닥친

모든 이슈를 옮길 때까지 이전을 미루지 마세요. 그것은 감탄할만한 목표이긴 합니다.

하지만 수동 시스템을 깔끔하게 정리하고 나서 자동화된 시스템을 사용하려 들지 마세

요. 그냥 최대한 빨리 이슈 추적 시스템을 사용하세요. 새 시스템에 새 이슈를 입력하

면, 시간이 지남에 따라 상당한 양의 정보를 축적돼서 이슈 추적 시스템이 생생한 자원

Page 69: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

50

It!Ship

이 될 겁니다. 새 시스템에 데이터를 넣을 시간이 있다면, 좋습니다! 하지만 데이터를

집어넣고 나서 시스템을 사용해야 한다고 생각하진 마세요.

이슈�추적�시스템을�고릅니다(219쪽�부록�E).

여러분이�사용할�테스트�시스템을�구축하고�사용법을�익힙니다.

내부�사용자를�위해�한�쪽짜리�퀵-스타트�가이드를�만드세요.

이�시스템에�새�이슈를�보관하기�시작하세요.

시간이�나면�이전�이슈를�새�시스템으로�옮기세요.

제대로 사용하고 있는 걸까요?

어떤 종류의 시스템을 사용하든 간에 이슈를 추적한다면, 잘 하고 있는 겁니다. 정말

중요한 문제는 여러분이 시스템에 충분한 정보를 저장하고 있는지, 내부적으로 그 시

스템을 사용하는지 여부입니다. 다음 질문을 사용해서 여러분이 성공했는지 평가해보

세요.

�아직�해결�못한�최우선사항의�목록을�생성해낼�수�있습니까?�두�번째�계층에서�발

생한�문제는�어떻게�됐습니까?

지난�주에�고친�것들의�목록을�생성할�수�있습니까?

시스템이�해당�이슈를�수정한�코드를�참조할�수�있습니까?

�기술�리더가�이�시스템을�사용해서�개발팀이�할�일을�목록으로�뽑아낼�수�있습니까?

시스템에서�정보를�가져오는�방법을�기술�지원�팀이�알고�있나요?

�어떤�이슈가�고쳐졌을�때�기술�지원팀(그리고�다른�사람이나�부서)이�알�수�있도록,�

시스템이�‘관심�있는�관계자’에게�통지해줄�수�있습니까?

1.

2.

3.

4.

5.

Page 70: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

51

2장 도구와 인프라스트럭처

경고 신호

시스템을�사용하지�않습니다.

시스템에�작은�이슈들이�너무�많이�있습니다.

이슈�관련�측정자료가�팀�구성원의�성과를�평가하는�데�사용됩니다.15

그건버그가아니라기능이라구요!

버그(이슈라고 부르기도 하는)의 짧은 정의는 여러분이 의도한 바대로 작동하지 않는 소프트웨어 내

의 무엇입니다. 이 정의는 데이터 소실과 시스템 고장부터 간단한 철자법 오류까지 모든 걸 포함합

니다.

반면 기능은 기존 제품의 개선될 점을 말합니다. 지나치게 열심인 판매 또는 마케팅 부서가 자신들

이 원하는 기능을 더 높은 우선순위로 놓으려고 개선해야 될 사항을 버그로 분류하도록 절대 내버려

둬서는 안 됩니다.

15 이것은 위험천만한 비탈길입니다. 더 많은 이슈를 보고하거나 고친 사람이 더 생산적이라고 말하고 싶어지기 쉽습니다. 하지만 측

정 자료를 사용해서 생산성을 평가하는 건 제대로 먹히지 않습니다. 만약 여러분이 입력된 이슈 숫자에 따라 급여를 인상한다면, 시

스템은 순식간에 적합하지 않고 남의 흠이나 잡아내는 버그로 가득 차게 될 겁니다.

Page 71: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

52

It!Ship

06 기능을 추적하세요

새 기능(Feature)은 추가된 기능성(Functionality)을 일컫습니다.16 새 기능은 제품

이 이전에는 못 했던 것을 할 수 있게 만들어줍니다. 예를 들어, 제품이 다른 벤더의 데

이터베이스와 통신할 수 있게 만드는 것도 새 기능입니다. 반면에 지원되는 데이터베이

스와 적절히 작동하도록 만드는 건 버그 수정입니다. 이 두 가지는 서로 다릅니다. 그

러니 다르게 취급해야 합니다.

여러분이 기능 요구를 정확히 추적해야 할 이유는 많습니다. 새 기능에 대한 사용자

의 요구를 평가하고 다음 버전을 위해 할-일 목록을 생성해낼 수도 있기 때문입니다.

또한 누가 어떤 기능을 요청했는지 아는 것이 우선순위를 매기는 데 있어 중요합니다.

만약 가장 작은 고객사가 어떤 기능을 요청했지만 가장 큰 고객사 중 여섯이 다른 기능

을 요청했다는 사실을 안다면, 기능 목록의 우선 순위를 적절하게 잡을 수 있습니다.

여러분은 두 기능을 모두 추가할 수도 있습니다. 하지만 일의 순서를 매길 수단을 갖는

게 중요한 겁니다.

기능을 추적하지 않으면 몇 개는 잊어버리게 될 겁니다. 그렇게 되면 그 기능을 요청

했던 고객은 여러분이 건성이라고 믿게 됩니다. 그건 고객에게 보내고 싶은 긍정적인

메시지는 아닙니다.

이슈 목록을 추적하듯이 기능을 추적하세요. 통합된 기능 요구 목록을 유지하세요.

기능에 우선순위를 매기고, 그 기능을 연구하거나 추가하는 데 소요될 간단한 시간 예

측치를 유지하세요. 보다 이목을 끌기 위해서 화이트보드에 최상위 항목들을 기록해놓

고 싶을 수도 있겠네요.

16 기능 Feature와 기능성 Functionality는 어떻게 다른 걸까요? 기능은 제품의 특성을 말하고, 기능성은 특성에 접근하는 방법을

뜻합니다. 마이크로소프트 워드에는 문서를 여는 ‘기능’이 있습니다. 마우스로 열기 메뉴를 선택하던가 단축키 Alt+O를 누르면 문

서를 열 수 있습니다. 이때 메뉴와 단축키를 기능성이라 할 수 있습니다.

Page 72: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

53

2장 도구와 인프라스트럭처

피쳐크리프(FeatureCreep)현상을조심하세요

많은 제품이 90 퍼센트 완료 표시를 하고선 결코 끝나지 않습니다. 그런 제품에는 항상 추가하거

나 끝내야 할 기능이 몇 개 더 있습니다. 웬일인지, 개발팀이 얼마나 더 해내든 간에, 그 제품은 절

대 출시할 준비가 되지 않습니다. 이런 제품은 피쳐 크리프라는 병폐 때문에 고통 받고 있는 겁니

다. 간단히 말해, 기능이 계속 추가되는 겁니다. 현재 있는 기능도 계속 개선될 뿐 완료되지 않습니

다. 결국 여러분은 ‘바닥까지 사포질하는’ *1 꼴이라는 사실을 깨달아야 합니다. 여러분에겐 언제 광

내기를 그만두고 실제로 제품을 내보내야 하는지 결정할 수단이 필요합니다. 이 문제를 다루기 위해

선, 모든 기능과 버그에 견고한 우선순위가 붙어있는지를 완전히 확실하게 해두어야 합니다. 여러분

이 작업하는 모든 일에 우선순위를 매기면, 관리층이 우선순위 목록에 줄을 긋고 어떤 것을 내보낼

지 내보내지 않을지 결정하기 쉬워집니다. 더 이상 임의로 결정한다던가, 개인적 취향에 따르지 않

게 됩니다. 개발자, 판매 부서, 그리고 궁극적으로 고객에게 그 변경이 얼마나 중요하냐에 따라 결

정이 내려집니다.

같은 이유에서, 여러분은 우선순위가 할당된 목록에 없는 것을 작업해선 안됩니다(71쪽, 3_10절 ‘목

록에 따라 일하세요’를 보세요).

*1 ‘바닥까지 사포질하기’는 목재업의 용어입니다. 이것은 광내기 위해 가구를 사포로 닦는 걸 일컫습니다. 하지만 사포질을

너무 많이 하면 선을 넘어서 나무에 손상을 줄 위험이 매우 큽니다. 초보자들이 흔히 하는 실수죠.

오래된 격언이 있습니다. “글로 적지 않으면, 없었던 일이나 마찬가지다”. 적는 것보다

도 훨씬 좋은 게 있습니다. 컴퓨터가 여러분을 위해 추적하게 하세요. 그렇게 하지 않

으면 마치 그런 일이 일어난 적이 없었던 것처럼 될지 모릅니다.

어떻게 시작하면 될까요?

이슈 추적 섹션의 ‘어떻게 시작하면 될까요?’와 아주 똑같습니다(46쪽의 2_05절 ‘이

슈를 추적하세요’를 보세요).

Page 73: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

54

It!Ship

제대로 사용하고 있는 걸까요?

다음 사항에서 ‘예’라고 말할 수 있으면 상태가 좋은 겁니다.

�다음에�출시할�기능의�목록을�만들어야�할�때�이�시스템을�첫�번째�정류장으로�사

용합니다.

제품에�대한�새로운�아이디어를�정기적으로�시스템에�기록합니다.�

�제출한�기능�중�상당수가�받아들여지지�않습니다.�그렇지�않다면,�여러분은�기능

을�입력하기�전에�선별하고�있는�겁니다.

�이�시스템에서�보고서를�실행시켜서�지난�제품�버전의�‘새�기능’�목록을�생성할�수�

있습니다.

�이해관계자들이�기능의�상태를�쉽게�확인할�수�있을�테고,�제품이�자신들의�기대

에�부합하니�마음을�편히�먹을�겁니다.

경고 신호

새�기능이�추가되지�않습니다.

모든�것이�우선순위�1입니다.

기능이�추가되기는�하지만�구현되는�법이�없습니다.

적절치�않은�기능이�추가됩니다.

Page 74: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

55

2장 도구와 인프라스트럭처

07 테스트 장비를 사용하세요

테스트 장비란 테스트를 만들고 실행시키는 데 사용할 수 있는 도구 또는 소프트웨어

툴킷을 말합니다. 그 대안이라면 직접 제작한 독립형 테스트가 있습니다(또는 보다 간

단한 게 있습니다. 테스트를 전혀 안 할 수도 있죠!).

테스트를 자동화하지 않았다면, 스크립트로 테스트를 돌릴 수가 없습니다. 테스트

수트를 돌릴 사람이 필요하고, 그러면 시간과 돈이 듭니다. 게다가 사람은 매번 조금씩

다르게 일을 처리합니다. 대화식 테스트는 더할 나위 없이 귀중한 노력입니다. 하지만

좋은 자동화된 테스트 수트도 마찬가지입니다. 좋은 테스트 수트는 좋은 테스터나 개발

자와 마찬가지로 천금의 가치가 있습니다. 좋은 테스트 수트는 제품이 훌륭한 모양새를

갖추는 데 도움을 주고, 이슈를 재빨리 파악하고 개발자에게 제품 상태에 대해 재빨리

피드백해줍니다. 우리는 CI 시스템 내부에서 돌아가는 좋은 자동화된 테스트 수트만큼

품질을 높일 수 있는 실천방법을 본 적이 없습니다.

TIP 조언 09

제품을 작동시켜보세요–테스트를 자동화하세요.

‘기성품’ 테스트 프레임워크를 사용하는 것엔 이점이 많습니다. 예를 들어 기능 집합은

여러분이 스스로 만들어내는 것보다 포괄적입니다. 유명한 프레임워크를 선택하면 보

완적인 제품을 많이 찾을 수 있습니다. 예를 들어 많은 XUnit 테스트 장비에는 출력

포맷에 기반을 두고 보고서를 생성할 수 있는 지원 제품이 있습니다. 다양한 코드 검사

기가 만들어낸 출력을 수집해서 가공해주는 오픈 소스 도구인 MetaCheck17는 훌륭

한 예입니다. 여러분이 SourceForge.net에 방문해서 JUnit에 대해 검색해보면,

17 http://metacheck.sourceforge.net

Page 75: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

56

It!Ship

Junit의 기본 기능을 확장하거나 강화하는 프로젝트를 수십 개나 찾을 수 있을 겁니다.

표준 프레임워크를 사용하면 공짜로 추가기능을 많이 얻을 수 있습니다.

반면 회사 전반에 걸쳐 표준적이고 호환성 있는 테스트 프레임워크를 사용하지 않으

면, 호환되지 않는 일련의 장비와 마주치게 될 겁니다(세 명의 개발자와 두 명의 테스터

에게 한 문제를 풀라고 해보세요. 그러면 9개의 해답을 얻게 될 겁니다).

팀의 모든 사람이 똑같은 문제를 몇 번이고 다시 풀어서, 바퀴를 계속해서 다시 발명

하는 걸 원치 않는다면, 반드시 모든 사람이 사용할 수 있는 공통 프레임워크가 있어야

합니다. 달리 말해, 여러분의 작업을 효율적으로 향상시키고 싶다면 모든 사람이 같은

프레임워크를 사용해야 합니다.

결함주도테스트

결함 주도 테스트는 결함이 있었던 (또는 아직도 있는) 코드 지점을 겨냥함으로써 테스트 창조 노력

을 이끌어줍니다. 테스트를 만들기 위한 이 간단하고 효율적인 접근법은 지금 제품 내에 버그가 있

는 곳을 주목합니다. 역사적인 문제 영역에 신경 쓰지 마세요. 오늘 점심 때 개발자들이 무엇에 대

해 불평했는지 살펴보세요. 개발자들이 지금 당장 추적(trace)하고 있는 코드가 뭔가요? 오늘 개발

자가 작업하고 있는 코드를 찾아서 자동화된 코드를 만드는 데 쓰세요.

결함 주도 테스트를 사용하면, 개발팀이 현재 마주친 이슈를 직접 다룰 수 있는 테스트 수트를 빨리

만들 수 있습니다. 코드 중 한 부분이 불안정해지면, 이런 종류의 테스트가 재빨리 그 코드를 ‘접종’

하고 활성화된 결함이 되풀이해서 발생하는 걸 방지합니다. 한 제품 영역이 안정되면, 적용 범위 테

스트를 해야 할 긴급한 필요성이 없어지게 됩니다. 무제한의 자원이 있다면, 우리 모두는 자동화된

테스트로부터 100 퍼센트의 코드 적용 범위를 달성하려고 노력할 겁니다. 하지만 이곳 현실 세계에

서 우리는 한정된 자원을 가장 적절한 곳에 적용해야 합니다.

Page 76: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

57

2장 도구와 인프라스트럭처

가볍고 유연한 테스트 프레임워크를 선택해서 프로젝트의 특정 요구에 부합할 수 있

게 하세요. 너무 뻣뻣해서 여러 프로젝트 라인에 도움을 주지 못해선 안 됩니다.

테스트 프레임워크에 명령창 인터페이스가 있어야 합니다. 그래야 외부 스크립트나

도구에서 작동시킬 수 있습니다. 또한 단위 테스트, 제품 테스트, 또는 통합 테스트를

다룰 수 있어야 합니다.

TIP 조언 10

유연하고 많은 사람이 사용하는 테스트 장비를 사용하세요.

테스트의 종류는 다양합니다. 각각이 서로 다른 종류의 문제를 짚어내기 위한 것입니다.

단위 테스트(Unit Test)는 개별 클래스나 객체를 테스트하기 위해 고안되었습니다.

단위 테스트는 독립형이고 일반적으로 작동시키기 위해 다른 클래스나 객체가 필요하

지 않습니다. 단위 테스트의 삶의 유일한 목적은 한 뭉치의 코드 내에 논리가 적절히 작

동하는지 확인하는 것입니다.

기능 테스트(Functional Test)는 제품 전체의 적절한 동작(또는 기능)을 테스트하

기 위해 작성됩니다. 기능 테스트는 제품 전체 또는 한 제품 내의 주요 하부 시스템을

다룰 수 있습니다. 기능 테스트는 시스템 내에 많은 객체를 갖습니다.

성능 테스트(Performance Test)는 제품이 (또는 중요 하부 시스템이) 얼마나 빨

리 작동할 수 있는지 측정합니다. 이런 테스트를 하지 않고선, 어떤 코드 변경이 제품

의 반응 속도를 향상시켰는지, 퇴보시켰는지 말할 수 없습니다(그렇지 않으면 스톱워치

를 정말 잘 다룰 수 있어야겠죠).

부하 테스트(Load Test)는 수많은 클라이언트나 파워 유저 집단이 (혹은 둘 다가!)

큰 부하를 걸었을 때 제품이 어떻게 작동하는지 모의 실험합니다. 성능 테스트와 마찬

Page 77: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

58

It!Ship

가지로, 이런 종류의 테스트를 하지 않고선 코드 베이스가 향상됐는지 퇴보됐는지 객관

적으로 말할 수 없습니다.

스모크 테스트(Smoke Test)는 가벼운 테스트이고, 제품의 중요 부분을 작동시키

기 위해 조심스럽게 작성되어야 합니다. 빨리 실행되면서도 제품의 적합한 부분을 작동

시키기 때문에 스모크 테스트를 사용하게 됩니다. 그 기본적인 아이디어는 기본 기능을

호출했을 때, “연기가 나는지”, 즉 실패하는지 알아보기 위해 제품을 돌려보는 겁니다.

스모크 테스트는 CI 시스템과 함께 사용하기에 아주 좋습니다. 왜냐하면 스모크 테스

트는 빠르기 때문입니다. 제품의 생명 주기 동안, 아마도 여러분이 활발히 돌려보는 스

모크 테스트는 번갈아 가며 바뀔 겁니다. 스모크 테스트 수트는 활발한 개발 영역 또는

알려진 버그 영역을 겨냥합니다.

통합 테스트(IntegrationTest)는 제품 라인의 다양한 부분이 서로 잘 협력하는지

를 살펴봅니다. 통합 테스트는 여러 제품을 아우릅니다. 때로는 여러분의 제품뿐만 아

니라 여러분이 사용하는 제삼자의 제품까지도 말이죠. 예를 들어 제품에 사용되는 갖가

지 데이터베이스가 통합 테스트의 일부로써 수행될 수 있습니다. 여러분은 이런 테스트

가 제품의 경계를 가로지를 수 있기를 원할 겁니다. 통합 테스트는 데이터베이스와 같

이 제품이 의존하는 컴포넌트의 새 버전을 검증하는 데 흔히 쓰입니다. 만약 여러분이

선호하는 데이터베이스의 새 버전이 나오면, 제품이 새 버전과 작동할 수 있는지 알고

싶을 겁니다. 데이터베이스까지 내려가서 기능을 실행시켜보는 테스트 수트라면 기능

에 대한 의문점을 풀어주는 동시에 새 컴포넌트의 성능은 어떠할지 언뜻 감을 잡을 수

있게 해줘야 합니다.

가짜 클라이언트 테스트(Mock client test)는 클라이언트의 관점에서 테스트를 만

들기 위해 사용됩니다. 가짜 클라이언트 테스트는 최소한의 기능적 명세를 충족시키는

지 확인하면서 제품에 대한 일반적인 사용 시나리오를 재생산하려고 합니다. 이런 종류

의 테스트는 가장 흔히 사용되는 코드 경로를 다루기 위한 핵심적인 테스트 적용 범위

를 제 위치에 놓는 데 매우 효과적입니다. 옆의 사이드바를 보세요.

Page 78: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

59

2장 도구와 인프라스트럭처

가짜클라이언트테스트

가짜 클라이언트 테스트는 우리가 개발한 개념인데 빠르게 인기를 얻고 있습니다. 여러분의 제품

이 어떻게 사용되는지 생각해보세요. 클라이언트 애플리케이션이나 낮은 수준의 코드 (만약 여러분

이 API를 작성하고 있다면)가 제품을 사용할 수도 있습니다. 클라이언트의 행동을 모방하는 테스트

수트를 작성하세요. 가짜 클라이언트 테스트는 보통의 클라이언트가 하듯이 여러분의 제품(또는 하

부 시스템)을 사용합니다. 여러분은 가짜 객체(Mock Object)*1가 서버나 애플리케이션 자원을 흉

내 내듯 클라이언트를 ‘모방’해왔습니다. 가짜 클라이언트 테스트는 보통 통합 테스트로 분류됩니다.

왜냐하면 가짜 클라이언트 테스트는 살아있는 시스템에 대해 동작하기 때문입니다. 가짜 클라이언

트 테스트는 함께 묶여서 성능 및 부하 테스트가 될 수 있습니다. 아니면 개별적으로 스모크 테스트

로 사용될 수 있습니다. 그 개념은 꽤나 유연하고 강력합니다. 만약 여러분이 사용자 시나리오 집합

을 갖고 있다면, 가짜 클라이언트 테스트에 밀어 넣어서 시나리오가 실행되는지 검증할 수 있습니다

(그리고 여러분이 코드 베이스을 리팩토링한 뒤에도 계속 작동하는지도 검증할 수 있습니다).

가짜 클라이언트 테스트를 사용하면, 시스템의 가장 중요한 코드 경로를 실행시킵니다. 실행되는

코드가 호출하는 경로를 말이죠. 가짜 클라이언트 테스트는 다른 테스트 방법론처럼 코드 적용 범위

백분율을 제공하지는 않습니다. 하지만 가장 중요한 적용 범위를 제공합니다. 가짜 클라이언트 테

스트는 테스트 자원에 대한 수요가 많은 회사에서 특별히 중요합니다.

모든 종류의 테스트를 살펴보면, 가짜 클라이언트 테스트는 최고의 투자 대비 수익률을 안겨준다는

걸 알게 될 겁니다. 만약 여러분이 테스트가 없는 프로젝트를 책임지게 된다면, 가짜 클라이언트 테

스트부터 만들고 다른 종류의 테스트는 나중에 추가하세요. 가짜 클라이언트 테스트와 결함 주도 테

스트(56쪽의 사이드바를 보세요.)를 결합하는 전략을 채택하면, 가장 주의 기울여야 할 코드 영역

이 가장 효율적인 방식으로 테스트 적용 범위를 받도록 보장할 수 있습니다.

*1 http://www.mockobjects.com/Faq.html를 보세요.

Page 79: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

60

It!Ship

질 나쁜 테스트 프레임워크 때문에 발목 잡혀선 안 됩니다. 아주 유연한 제품을 사용

해야 합니다. 내일이 되면 오늘 쓴 테스트 프레임워크와는 다른 무언가를 테스트해야

할지도 모릅니다. 유연한 제품이라면, 그저 테스트 할 거리를 집어 들고 계속 일해 나

갈 수 있을 겁니다. 지나치게 특화되었거나 경직된 프레임워크를 사용한다면, 새로운

툴킷을 찾아서 처음부터 다시 익혀야 할 겁니다. 시간이야말로 가장 소중한 자원입니다.

재사용하지도 못하는 도구를 익히느라 시간 낭비하지 마세요.

제법 큰 회사에서 우리는 결함 주도 테스트와 가짜 클라이언트 테스트를 결합한 훌륭

한 사례를 목격했습니다. 점심 시간에 개발자들이 제품 핵심부의 특정 코드가 지난 주

에 세 번이나 깨졌다고 불평하는 소리를 들었습니다. 문제는 제품 전체를 날려먹을 정

도로 심각해서 그 팀은 문제를 찾아내느라 거의 하루를 썼습니다. 문제를 고치자 첫 번

째 문제와 연관된 또 다른 문제가 튀어나왔습니다. 두 번째 문제를 격리시키느라 반나

절이 걸렸습니다. 그런데 두 번째 문제를 고치고 나자 첫 번째 문제가 다시 나타났습니

다. 이번엔 몇 시간 만에 문제를 찾아냈습니다. 소프트웨어 팀 전체가 매번 말려들어서

제자리걸음만 했습니다. 다른 일을 할 수가 없었죠. 우리는 대략 계산해보았는데, 이

문제 때문에 그 팀은 2 인월(人月, Man-Month)을 소모했습니다.

점심 식사를 하는 무리가 되풀이되는 문제에 대해 말하는 걸 듣고 난 후, 우리는 해당

영역을 맡은 테스터에게 새로운 지시를 내렸습니다. 테스터들은 상위 수준의 코드(문제

가 있는 하위 수준의 코드를 사용하는 클라이언트에 해당하는)의 관점에서 테스트를 만

들었고, 특히 지난 주에 발생한 버그를 드러내는 테스트를 작성했습니다. 기본적인 테

스트를 제대로 갖춰놓는 데는 테스터 한 명이 반나절만 일하면 됐습니다. 그 문제를 디

버깅하느라 엄청난 시간을 쏟아 붓고 벌써 그 이슈를 잘 정의 내린 개발자들이 예제 코

드를 제공해준 덕분입니다.

그러고 나서 우리는 이렇게 만든 테스트를 CI 시스템에 추가해서 개발자가 코드를 추

가시키거나 변경할 때마다 테스트를 실행시키게 했습니다. 그 다음 주에, 누군가 예전

의 결함 있는 버전의 코드를 다시 불러들였습니다. CI 시스템이 새로 추가한 테스트를

Page 80: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

61

2장 도구와 인프라스트럭처

돌리고 있었기 때문에, 새 코드가 추가된 지 반시간도 지나지 않아 그 문제를 잡아냈습

니다. 한 시간도 안돼서 문제를 해결해서 검증까지 마쳤습니다(자동화된 테스트로 말이

죠). CI 시스템과 새로 추가된 테스트가 없었더라면, 그 문제가 제품에 은근슬쩍 돌아

와선 똑 같은 문제를 다시 일으켰을지도 모릅니다.

테스트는 클라이언트(상위 수준의 코드)의 관점에서 쓰여집니다. 클라이언트의 관점

이란 가짜 클라이언트 테스트 저변에 깔린 원리이기도 합니다.

그림 2.6 모든 테스트가 통과했다는 걸 보여주는 JUnit 콘솔

Page 81: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

62

It!Ship

여기에 JUnit 테스트 코드 예제가 있습니다(테스트가 통과했음을 보여주는 GUI가 그

림 2.6에 제시되어 있습니다).

import junit.framework.*;

public class AdditionTester extends TestCase {

public void testAdd() {

assertEquals(5, 2 + 3);

}

public static void main (String[] args) {

junit.swingui.TestRunner.run(AdditionTester.class);

}

}

좋은 테스트 프레임워크라면 개발 노력에 심대한 영향을 미칠 수 있습니다. 그 테스트

프레임워크는 효과적으로 사용한다면 매우 강력한 도구입니다. 여러분 환경에 알맞은

프레임워크를 찾기 위해 시간을 투자하고, 효과적으로 사용하는 법을 익히도록 하세요.

어떻게 시작하면 될까요?

여러분의 팀이 테스트를 전혀 갖고 있지 않다면, 기술 리더와 (또는 관리자와) 그 문제

를 상의하고 싶을 겁니다. 테스트의 이점을 보여주기 위해 여러분의 책임 영역 내에서

테스트를 추가해도 됩니다. 하지만 최대의 효과를 보려면 팀 전체가 참여해야 합니다.

만약 팀이 벌써 테스트를 작성하고 있다면, 어떤 프레임워크를 사용하고 있는지 알아

보세요. 많은 개발자가 자신만의 프레임워크를 작성합니다.–절대 그러지 마세요! 하

지만 회사의 누구라도 표준 프레임워크나 도구에 정착해 있다면, 어떤 제품인지 그리고

왜 그것을 선택했는지 알아보세요. 그들의 경험과 전문 지식을 활용하세요.

일단 프레임워크를 선택했으면, 결함 주도 전략을 써서 테스트를 만듭니다. 우리는

여러분에게 가짜 클라이언트 테스트를 만들라고, 그리고 CI 시스템에서 모든 테스트를

Page 82: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

63

2장 도구와 인프라스트럭처

돌리라고 강력히 제안합니다. CI 시스템은 테스트가 정기적으로 돌아간다는 걸 확신시

켜줄 최고의 방법입니다.

테스트�도구와�툴킷을�선택하세요.

문제�영역에�테스트를�추가하세요.

�테스트가�자동�빌드�시스템�내에서�돌아가도록�하세요(40쪽�2_04절�‘자동으로�

빌드하세요’를�보세요).

역사에대해선잘몰라요

역사적으로 이슈가 많은 코드가 항상 형편 없는 개발자를 가리키진 않습니다. 코드가 이런 범주에

빠지게 되는 이유는 많습니다. 그 코드가 매우 난해한 탓일 수 있습니다. 아니면 같은 영역에 여러

명의 개발자가 있어서 서로의 작업이 충돌하는 것인지도 모릅니다. 새 개발자가 다른 동료의 업무를

인계 받았다가 다른 업무로 넘어갔을 수도 있습니다.

버그 발생 횟수가 큰 코드라고 해서 형편없는 개발자가 작성했으리라 짐작하지 마세요. 그 대신 문

제를 해결하기 어려운 부분이라 생각하세요. 일단 여러분이 그런 복잡성을 파악하고 나면 매우 효과

적인 테스트를 작성할 수 있을 겁니다.

제대로 사용하고 있는 걸까요?

만약 여러분이 방향을 제대로 잡았다면 다음 질문에 분명하게 대답할 수 있을 겁니다.

테스트�수트가�효율적입니까?�테스트가�버그를�잡아내고�있나요?

�코드�적용�범위18의�숫자는�얼마인가요?�시간이�지남에�따라�숫자가�커지고�있나요?

18 코드 적용 범위(Code Coverage, 코드 커버리지)란 여러분이 돌리는 테스트가 작동시키는 코드 줄의 양을 일컫습니다.

1.

2.

3.

Page 83: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

64

It!Ship

여러분이�테스트하는�제품이�안정적입니까?

테스트가�자동으로�실행되고�있습니까?

�테스트가�성공했는지�실패했는지�알려줍니까?(만약�테스트가�성공했는지�실패했

는지를�여러분이�직접�결정해야�한다면,�테스트가�자동화되지�않은�겁니다).

�여러분�회사의�모든�사람이�테스트를�추가할�수�있습니까?(그렇지�않다면,�아마도�

프레임워크가�지나치게�복잡하기�때문일�겁니다).

경고 신호

만약 테스트가 다음 사항에 들어맞는다면 여러분의 전략을 다시 검토하세요.

작동하지�않는다.

어떤�문제도�잡아내지�못한다.

너무�오래�실행된다.

유지�보수하는�데�엄청난�노력이�든다.

08 도구를 선택하는 방법

우리가 논의한 각 범주에 해당하는 도구를 사용하지 않고 있다면, 다시 생각해보시길

바랍니다. 예컨대 빌드 시스템을 IDE에 묶어놓으면 안 됩니다. 요즘 가장 대중적인

IDE를 사용하면 거의 모든 일을 해낼 수 있습니다. 최신 IDE는 코드를 요리저리 다뤄

냅니다. 물론 이런 다목적 도구는 여러 가지 일을 제대로 해내기는 하지만, 어떤 것 하

나 특출나게 잘 해내지는 못합니다.

여러분이 원하는 일을 제대로 해내지도 못하는 번들 제품을 쓰기보단, 여러분의 필요

에 딱 맞는 도구를 찾는 데 시간을 투자하세요. 지금 사용하는 도구와 타협하지 마세요.

Page 84: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

65

2장 도구와 인프라스트럭처

어떤 도구를 찾던 간에 광범위한 범위의 상용 또는 오픈 소스 제품 중에서 고를 수가 있

습니다. 여러분이 사용하는 도구는 업무에 가장 적합한 도구여야 합니다. 각 분야에서

최고의 소프트웨어 제품을 쓰도록 하세요.

도구가 XML이나 일반 텍스트 파일과 같은 개방된 포맷을 사용하는지 확인하세요.

개방된 포맷으로 읽고 쓰는 도구를 사용해야 개방된 포맷을 사용하는 다른 도구와도 ‘이

야기’를 나눌 수 있습니다(양쪽 파일의 의미 구조가 일치하거나 일치하게끔 변환될 수

있다고 가정할 때). 이런 융통성이 있으면 다양한 도구를 한데 묶어서 완전한 시스템을

갖출 수 있습니다. 겉보기엔 서로 관련 없어 보이는 도구를 이런 식으로 상호작용하게

하면 놀라운 정도의 시너지 효과를 볼 수 있습니다.

TIP 조언 11

업무에 가장 적합한 도구를 사용하세요.

오픈 소스 자바 빌드 도구인 Maven은 이 같은 개념이 훌륭하게 적용된 사례라 하겠습

니다. Maven은 Ant 스크립트와 Ant의 스크립트 언어인 Jelly를 사용해서 빌드 프

로세스를 캡슐화합니다. 테스트는 자동으로 실행되고(Maven은 JUnit 테스트 프레임

워크를 작동시킬 수 있습니다), 테스트가 끝나면 Maven이 테스트 결과를 HTML 보

고서로 변환시켜 줍니다. 보고서는 가공되지 않은 테스트 결과부터 코드 적용 범위 분

석이나 정적 코드 분석에 이르기까지 다양합니다. Maven을 사용하면 이런 도구들을

한데 묶을 수 있습니다. 왜냐하면 모두 입력값과 출력값으로 개방된 포맷을 사용하기

때문입니다. Maven은 간단히 정보를 연결해 냅니다. 비록 Maven이 하는 일을 엄청

나게 단순화시킨 짤막한 묘사이긴 해도 핵심은 알 수 있습니다. 도구가 공개된 포맷으

로 읽고 쓰기만 하면, 그 도구들을 한데 묶을 수 있습니다.

반대되는 사례로써 Electronic Design Interchange Format (EDIF)라 불리는

포맷을 살펴보도록 하죠. 이 포맷을 사용한 초창기 프로그램 대부분은 멋진 임포트 유

Page 85: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

66

It!Ship

틸리티를 갖추고 있어서 EDIF 포맷인 데이터를 읽을 수 있었습니다. 하지만 어떤 프로

그램도 EDIF 포맷으로 데이터를 추출하게 해주진 않았습니다. 경쟁 제품에서 이전하

긴 쉬워도 일단 EDIF 포맷으로 데이터를 만들고 나면 떠날 수 없게 만들어 놓은 겁니다.

이런 ‘기능 집합’으론 여러분이(또는 제삼자가) 이 시스템을 보강할 도구를 작성하기란

불가능합니다. 이런 불합리함 때문에 EDIF의 목적이 완전히 퇴색됐습니다. 개방된 포

맷을 읽고 쓰는 도구를 사용하세요. 벤더들이 여러분을 묶어놓게 놔둬선 안 됩니다.

TIP 조언 12

공개된 포맷을 사용해서 여러 도구를 통합하세요.

09 실험하지 말아야 할 때

제품 주기 중 중요한 부분(빌드 시스템 같은)은 절대 틈새 기술이나 비핵심 기술로 작성

해선 안 됩니다. 특히나 그 기술을 아는 개발자가 없을 경우에는 말이죠. 회사 사람이

라면 누구라도 설정하고 유지 및 보수할 수 있는 기술을 사용해야 합니다. 기술을 갖고

놀 장소가 있으면 좋고, 전문적인 개발을 위해선 그런 장소가 반드시 있어야 되기도 합

니다. 하지만 중요한 곳에서 그러면 안 됩니다. 실험은 임계 경로 밖에서 해야 합니다.19

한 벤처기업에선 빌드 스크립트를 새로 나온 언어로 작성했습니다. 그것은 빌드 스크

립트를 작성한 개발자를 위한 학습 프로젝트였습니다. 더 나빴던 것은 빌드 시스템이

아닌 범용 스크립트 언어를 사용했다는 겁니다. 빌드 스크립트에는 애매모호한 언어적

특징을 한껏 버무린 스파게티 코드가 25쪽 이상이나 들어가 있었습니다. 말할 것도 없

이, 그 코드는 이해할 수 없을 지경이었습니다. 개발자의 컴퓨터나 특정 네트워크 드라

19 프로젝트의 임계 경로란 프로젝트 진행을 늦출만한 모든 걸 포함합니다. SCM 시스템과 빌드 스크립트가 임계 경로 안에 있는 항목

으로 좋은 사례라 하겠습니다. SCM 시스템이나 빌드 스크립트가 망가지면, 다른 모든 일도 중지됩니다.

Page 86: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

67

2장 도구와 인프라스트럭처

이브, 그리고 특정 버전의 소프트웨어 컴포넌트에 의존적인 하드 코딩된 빌드 스크립트

였습니다. 그 프로그램은 난잡하기 그지 없었습니다.

핵심적인 기술(빌드 시스템 같은)을 기술 실험 대상으로 삼아선 안 됩니다. 팀 구성원

중 누군가가 배우고 싶어하는 멋진 신기술이 아닌, 여러분의 빌드 환경에 적합하게 고

안된 도구를 사용하세요. 기술을 배워도 되는 비임계 영역은 많습니다. 절대 한 컴퓨터

에서만 돌아가는 자동화된 도구는 만들지 마세요. 절대 네트워크 드라이브 의존성을 하

드 코딩하지 마세요. 필요한 걸 모두 SCM 시스템 안에 집어넣고, 네트워크 드라이브

를 하찮은 문제로 만드세요.

예컨대, 여러분이 자바를 사용하는 회사에서 일한다면, Ant를 빌드 스크립트로 사

용하는 걸 고려해보세요. Ant는 삶의 목적 자체가 자바 프로그램을 빌드하는 것입니다.

그러니 Python같은 언어보다는 Ant로 자바 빌드 스크립드를 작성하는 편이 훨씬 쉽

습니다. Python은 훌륭한 언어지만, 자바에 대핸 아무것도 모릅니다. 빌드 시스템을

선택할 땐 지금 가진 전문지식을 활용하세요.

이 규칙만 고수하면 많은 걸 얻습니다. 도구를 유지보수하기 훨씬 쉬워집니다. 회사

사람이라면 누구라도 해당 기술을 활용하고 조정할 수 있을 겁니다. 또한, 경험을 쌓아

나감에 따라, 주어진 상황에 아주 적합한 듯 보이지만 실제로는 그렇지 않은 기술 때문

에 발목 잡히는 일도 사라집니다.

하지만정말멋진물건이라니까요!

이 규칙의 예외가 되어야 마땅하다고 생각하는 특정 기술이 있다면, 시간과 돈을 써서 사람들을 훈

련시키세요. 새 기술을 가져다 놓기만 하고, ‘아주 좋은 기술이니까 다들 알아서 익히겠지’라고 생각

해선 안 됩니다. 그런 식으로 일이 풀리는 경우는 없습니다. 피드백을 줘서 사람들에게 여러분이 기

대하는 바를 알게 하세요. 이런 피드백의 효과는 선생의 재능을 반영하지, 학생의 우둔함을 반영하

지는 않는다는 걸 명심하세요

Page 87: Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

68

It!Ship

경험만이 주어진 기술의 결점을 말해줄 수 있습니다.

언급할만한 가치가 있는 또 다른 위험은 여러분 자신이 이해하지 못하는 일을 코드 마

법사(또는 빌드 스크립트)가 하게끔 내버려두는 일입니다. 여러분 대신 도구가 세부사

항을 처리하게 놔두는 건 좋지만, 여러분이 그러한 세부사항을 벌써 이해하고 있을 경

우에만 그래야 합니다. 세부사항을 이해하지 못하면, 문제가 발생했을 때 한참 헤매게

됩니다. “이해하지도 못하는 마법사는 사용하지 마세요.” ([HT00] 참고).

TIP 조언 13

임계 경로 기술에 친숙해지세요.