나를 성장하게 해 준

아이리스에게

• 목 차 •

1부 논쟁의 전장 ...................................................2

이론이 먼저냐, 실제가 먼저냐? ...........................................3

‘위험하며 오도誤導하다’

- 파나스의 논문을 통해 본 소프트웨어 연구 실정 ...................9

‘은총알은 없다’

- 프레드 브룩스를 통해 본 소프트웨어 연구 실정 ................. 13

가장 뛰어나고 명석한 두뇌들이 내놓은 보고서 ..................... 17

조사 결과 몇 가지 .................................................. 19

추천 사항 몇 가지 .................................................. 21

결론 .................................................................... 24

2부 기술 진영에서 .............................................. 28

인지적 견해

: 소프트웨어 설계를 보는 다른 시각 ................................... 29

실증 연구 결과 ...................................................... 30

설계의 본질 .......................................................... 31

한국 독자를 위한 서문 .................................................... xiii

2판추천서문 .................................................................. xx

1판추천서문 ................................................................xxiii

1판서문 .......................................................................xxv

2판서문 ..................................................................... xxvii

기타 연구 결과 ...................................................... 33

앞으로 나갈 방향 ................................................... 35

소프트웨어 오류에 대한 단상 ............................................ 37

생각 정리 ............................................................. 40

소프트웨어 오류 제거에 대한 실험적 관점 ........................... 42

테스트에 관한 실험이 있었다 ................................... 43

실험 결과 ............................................................. 44

몇 가지 짚고 넘어갈 사항 ........................................ 48

기타 놀라운 연구 결과 ............................................ 49

다양한 테스트 종류 ......................................................... 52

소프트웨어 품질과 소프트웨어 유지보수 사이의 관계 ............ 56

소프트웨어 유지보수는 해결책이지 골칫거리가 아니다 .......... 60

단일 지점 제어 ............................................................... 65

사용자 편의성

- 유행어인가, 도약인가? ................................................. 70

3부 최신 무기 정보 ............................................. 76

방법론

재사용: 소프트웨어 부품

- 노스텔지어와 데자뷰 .................................................... 77

과거로 돌아가기 .................................................... 78

좀 더 자세히 들어다 보기 ........................................ 79

무엇을 배웠나? ..................................................... 81

쓸데없는 걱정은 마십시오. ...................................... 83

참고문헌 .............................................................. 85

자동 프로그래밍

- 칵테일 파티 미신? ....................................................... 86

프로토타이핑에 대한 단상 ................................................ 90

표준과 표준 준수: .......................................................... 94

정말 소프트웨어 품질을 높이는 데 도움이 되나? .................. 94

vi

틀린 그림 찾기 ...................................................... 96

도구

권장 사항: 소프트웨어 .................................................... 98

도구 모음의 최소 권장 기준 .............................................. 98

요구사항 정의 ......................................................102

설계 ...................................................................102

구현 ...................................................................102

점검 ...................................................................102

유지보수 .............................................................103

관리 ...................................................................103

문서화 ................................................................103

다목적/기타 ........................................................103

잔소리: 소프트웨어 분야에서 ..........................................105

최신의 ‘비약적 발전’ 살펴보기 .........................................105

CASE: 과장없는 케이스 .........................................107

CASE와 4GL: 이익은 얼마인가? .......................................109

CASE 도구 결과 ...................................................110

3GL과 4GL 비교 실험 ...........................................112

3GL과 4GL 사례 연구 ...........................................113

컴파일러 개발, 무엇이 문제인가? .....................................115

언어

고차원 언어: ................................................................119

어느 정도가 적당한가? ...................................................119

4GL의 미래를 준비해야 할까? ..........................................123

문제 ...................................................................124

태도 ...................................................................124

입장 ...................................................................125

해법을 향해 .........................................................126

결론 ...................................................................127

코볼, 도대체 무엇이 문제인가? ........................................128

vii

4부 지휘 본부에서 .............................................133

관리

소프트웨어 세계에서 업적 달성하기 ..................................134

소프트웨어 생산성을 바라보는 새로운 방법 ........................139

생산성과 G 이론 ...........................................................143

베리 보엠이 제시하는 소프트웨어 프로젝트 관리 ‘W 이론’ ....146

기타 프로젝트 관리 이론과 소프트웨어에 대한 적용 ....149

소프트웨어 생산성 향상: 누가 무엇을 하고 있는가? .............151

소프트웨어 측정 기준: 피뢰침과 팽배한 긴장 ......................154

품질 관리: 허울 벗기 ......................................................157

품질을 측정하는 다른 방법이 있는가? ......................157

다른 진영 ............................................................159

소프트웨어 제품에서 ‘품질’을 관리할 수 있을까? .................162

실패한 소프트웨어 프로젝트에 관한 전설 ...........................166

마케팅

당신이라면 루드비히 2세에게서 중고차를 사겠는가? ............169

컨설팅

컨설팅의 진정한 비밀 .....................................................172

미래학자의 과거 들춰보기 ...............................................177

사용자 지원: 눈 맞추기만으로는 부족하다 ..........................185

5부 연구실에서 .................................................190

연구

구조적 연구라고? ..........................................................191

[해결된/해결되지 않은] 문헌 연구 문제 .............................195

작은 논쟁 하나: 참고 문헌의 장단점 ..................................198

기술이전

내년에 뜰까? ...............................................................200

기술 성숙도 연구에 관한 고찰 ..........................................200

viii

허점이 많은 소프트웨어 기술 이전 ....................................203

[생산성을 높이는 길은 험난하다] ......................................203

기술 이전에 관한 미신 ....................................................208

교육

소프트웨어 교육: 새로운 정보 제공처 ................................211

전산학과 교수에게 보내는 공개 편지 .................................215

유지보수를 고려한 설계 .........................................216

현존하는 소프트웨어의 정복자들 .............................220

6부 전장 사후 분석 ............................................227

전산학이 진짜 과학이 되며,소프트웨어 공학이

진짜 공학이 되려면 ...............................................228

‘문제 해결’에 대한 당연한/기발한 생각 ..............................232

소프트웨어 실패:왜 실패할까? .........................................236

예측에 대한 무능 ..................................................237

불안정한 요구사항 ................................................240

일시적 유행과 오해 ...............................................241

정리 ...................................................................245

응용 분야의 중요성 ........................................................247

사라진 즐거움을 찾아주시겠습니까? .................................252

뜨거운 열정을 지닌소프트웨어 개발자에게 바치는 헌정시 .....255

이 책에서 발췌한 단상 모음 ....................................263

에필로그 ......................................................................262

부록 .........................................................................267

특별부록: 재미있는 용어 사전 ..........................................275

베타리더 한마디 ............................................................282

ix

역사는 반복된다

2006년도 저물어 가는 이 시점에서 15년이나 더 된 책을 다시 펴낼 이유가 있을

까? 더 빨리 더 최신의 정보를 습득하기에도 정신이 없는 상황에서 구닥다리 옛날

이야기를 읽으면 시간 낭비가 아닐까? 얼핏 드는 생각이지만 상당히 그럴싸하다.

하지만 여기에는 함정이 있다.

칼 마르크스는 중요한 역사적 사건은 두 번 반복된다는 헤겔의 말에 첫번째 일

어나는 사건이 비극이라면 두번째 일어나는 사건은 희극이라고 덧붙였다. 이 책

본문에 나오는 4GL에 대한 맹신과 같은 어리석은 일이 요즘은 일어나지 않는다고

함부로 속단할 수 있을까? 그런 의미에서 희극 한 편을 소개하겠다.

2년 전에 이름만 들으면 누구나 알 수 있는 유명한 한 회사에서 컨설팅을 의뢰

받았다. 납기일 준수와 재사용성을 높이기 위해 임베디드 분야에 사용하는 소프

트웨어를 체계화 시켜서 공장factory에서 사용하는 BOMBill of Material처럼 관리하는

방법에 대한 내용이었다. 자초지종을 들어보니 이를 위해 객체지향 방법론을 도

입하고 누구나 이름만 들어도 아는 R사에서 개발한 R이라는 도구(따지고 보면 자동

프로그램을 가능하게 만든다고 선전한 4GL을 계승하는 현대판 도구다)를 도입하려고 한

다는 내부 전략을 파악했다. 하지만 21세기식 은총알을 사용한 늑대 인간 사냥에

는 전혀 관심이 없었기에 정색을 하면서 납기일 준수와 재사용 부품 제작은 이런

식으로 간단하게 해결할 수 없는 문제라고 잘라서 말했다.

옮 긴 이 글

x

저자인 로버트 L 글래스(밥)가 요즘도 이런 종류의 대화가 공공연히 이뤄진다

는 사실을 알았으면 과연 어떤 말을 할까? 사람 좋은 웃음과 더불어 “아니 이 사

람아, 내가 입버릇처럼 말했지만 은총알은 세상 어디에도 없다구!”라고 어깨를 툭

쳤을지도 모르겠다.

소프트웨어 컨플리트 2.0은 어떻게 보면 사람을 대단히 불편하게 만드는 책이

다. 분명히 배경은 과거이지만 이야기는 현재 진행형으로 생생하게 전개된다. 손

오공이 부처님 손바닥을 벗어나지 못하듯이 15년전에서 몇 발자국 벗어나지 못한

현재 상황을 바라보면서 심지어는 절망을 느낄지도 모른다. 하지만 불편함을 조

금만 참고 선배의 발자취를 따라가다보면 이 세상 고민은 혼자 다 짊어지고 있다

는 부담에서 벗어나도록 이끌어주는, 뜻이 통하는 말동무를 찾았다는 기쁨이 싹

터오르기 시작하면서 한가닥 희망이 보일 것이다.

천부적인 재주꾼인 밥이 이끄는 재미있는 이야기에 푹 빠져보자. 수동적인

자세에서 벗어나 주변 사람들과 이 책을 함께 읽고 치열하게 논쟁도 벌이면서

말이다.

감사의 말

이번 프로젝트의 일등 공신은 공역자인 이해영씨이다. 여느 다른 소프트웨어 공

학 서적과는 달리 이 책은 수 많은 비유와 은유로 교묘하게 숨겨진 함정이 곳곳에

존재하므로 번역 과정에서 상당히 어려운 난관에 직면한 경우가 한 두번이 아니

었다. 이해영씨는 이런 어려운 난관을 무사히 뚫고 지나가도록 최선을 다했다. 정

말 감사한다.

다음으로 베타리더를 맡아주신 김재범님, 김형준님, 권오혁님, 권일경님, 박응

주님, 이광수님, 이선우님, 임현수님, 진헌규님, 채원석님, 최원영님, 최재훈님께

감사드린다. 학계와 실무에 걸쳐 다양한 분야에서 다양한 관점으로 번역 원고를

읽고 검토해주셨기에 이번 번역서가 한층 독자 여러분에게 쉽게 다가가리라 생각

한다. 늘 그렇듯이 잘 구성된 멋진 팀과 함께 일하면 즐겁고 보람차다.

xi

또한 이런 어려운 책을 기획해서 맡겨주신 위키북스 담당자분께 감사드린다.

국내에서 이런 책을 출간하기란 쉽지 않은 결정임에도 불구하고 부족한 역자를

믿고 흔쾌히 진행을 결정하셨으리라.

마지막으로 요한 세바스찬 바하와 요요마에게 감사한다. 번역이 뜻대로 잘

안풀릴 때마다 아름다운 첼로 선율로 바쁜 마음을 한 템포 쉬어가도록 만들어

주었다.

첫 눈 내리는 날

박재호

즐거운 지적 유희

저자가 서문에서 밝히듯이, 이 책은 원래 1990년에 출판되었다가 2006년에 재판

된 책이다. 그래서 확실히 시대에 뒤떨어지는 내용이 없지 않다. 그럼에도 불구하

고 아주 재미있는 책이다. 읽는 이의 사고를 자극하기 때문이다.

툭 터놓고 얘기해서, 지금 진행 중인 프로젝트에 가시적으로 도움을 준다거나,

내일 작성할 코드 품질을 높여준다거나, 이렇듯 구체적인 지침이나 즉각적인 효

과를 구한다면 다른 책을 찾아보기 바란다. 좋은 책이 많다.

이 수필집은 지적 유희를 즐기는 소프트웨어 관련자들에게 적합한 책이다. 일

상 업무에 파묻혀서 돌아보지 못했던 주제, 한번쯤 떠올려는 봤으나 깊이 파고들

지 못한 주제, 동료들과 좋은 토론거리가 될 주제를 다룬 글이다. 또한 읽고 생각

하는 만큼 사고 폭을 넓혀주는 글이다.

독자 여러분들이 저자가 펼쳐놓은 지적 유희의 세계에 흠쩍 빠져들기 바란다.

xii

감사의 말

오랫동안 함께 일하면서 프로젝트를 잘 끌어주는 공역자, 박재호씨에게 커다란

고마움을 전한다. 그리고 이번 번역에 참여해주신 베타리더님들 모두에게 너무

감사드린다. 소중한 시간을 내주시고 활발한 피드백을 보내주셨다. 그분들 덕택

에 작업이 한층 더 즐거웠다. 마지막으로 좋은 책을 맡겨주신 위키북스 출판사

담당자분께 감사드린다.

이해영

xiii

친애하는 한국 독자 여러분께,

이번에 소프트웨어 컨플릭트 2.0을 출간하게 되었습니다.

소프트웨어 컨플릭트 2.0은 합의와 화합보다는 논쟁과 분란에 초점을 맞춘다는

측면에서 다소 특이한 책입니다. 제가 이러한 책을 내놓은 데는 이유가 있습니다.

합의란 논쟁을 다듬은 결과이며, 화합을 가장한 분란은 오히려 해가 된다고 믿기

때문입니다. 제가 한국 문화에 익숙하지 않은 탓에 (하지만 이 서문 후반부를 보세요)

한국 독자분들이 이런 접근 방식을 좋아할 지 모르겠습니다. 우리 서양에서는 일

반적으로 한국 문화가 논쟁과 분란을 지양한다는 시각을 갖고 있습니다. 하지만

어쨌거나, 제 의도는 소프트웨어 분야에 분분한 논쟁과 분란을 밝은 곳으로 끌어

내어 공개적으로 토론하면서 해결해 나가자는 겁니다.

이 책에서 제가 관심을 쏟는 분야는 소프트웨어 공학, 특히 소프트웨어 공학

의 실무입니다. 저는 제 자신이 소프트웨어 실무자들과 공통점이 많다고 생각합

니다. 제 스스로가 오랫동안 소프트웨어 실무자 중 한 사람이었으며, 그들이 걸어

가는 길과 방식에 커다란 신념이 있기 때문입니다. 또한 저는, 한국이든 미국이든

유럽이든, 전 세계 소프트웨어 실무자들이 궁극적으로는 같은 문제, 같은 관심사,

같은 목표를 추구한다고 믿습니다. 제 믿음이 옳다면, 여러분은 이 책에서 제가

토로하는 바를 즐기고, 납득하고, 교훈을 발견할 것입니다.

한 국 독 자 를 위 한 서 문

xiv

독자 여러분과 저는 이미 한 번 만났습니다. 제가 집필한 책 ‘Facts and Fallacies

of Software Engineering’이 수년 전 한국어판1)으로 출간되었습니다. 제가 집필한

책 중에서는 첫 번째 한국어판이었죠. ‘Software Runaway와 Computing Calamities’

와 같은 책 몇 권은 일본어와 중국어로 번역되었습니다만, 한국어로는 한 권만이

여러분을 만났습니다.

저는 이 책이 여러분과 앞으로 이어질 오랜 만남의 시작이기를 바랍니다. 제가

집필한 책은 십여 권이 넘으며, 좀 더 많은 책이 한국어판으로 나왔으면 합니다.

게다가 저는 이미 한국과 인연이 깊습니다. 제 최근 차 두 대가 대우에서 만든 차

였답니다. 그리고 제게는 한국인 아들이 있습니다. 스티브는 서울 근교에서 태어

났으며, 출생 당시 이름은 윤민규였습니다. 저는 3살쯤 된 스티븐을 한국 고아원

에서 입양했습니다. 지금은 멋진 젊은이로 자랐고, 7월이면 마흔이 됩니다. 그 녀

석이 하루가 다르게 성장하는 모습을 제 눈으로 직접 보고 있죠!

아무쪼록 독자 여러분이 소프트웨어 컨플릭트 2.0을 즐겁게 읽기 바랍니다.

2006년 늦여름

로버트 L. 글래스

옮긴이_1: ‘소프트웨어 공학의 사실과 오해’라는 제목 ‘인사이트'에서 출간되었습니다.

xv

로버트 L 글래스(밥이라는 애칭으로도 불린다) 는 지금까지 50여 년 동안 전산 분야

에서 파란만장한 경험을 쌓아왔으며, 1954~1957년까지 항공우주 업계 노스 아메

리칸 에비에이션2)에서 3년 동안 일한 경험을 시작으로 밥은 소프트웨어 부문에서

진정한 선구자 중 한 명으로 거듭났다.

노스 아메리칸 사에서 근무한 경험이 계기가 되어 에러로젯-제너럴3)

(1957~1965년)과 보잉4)(1965~1970년, 1972~1982년)과 같은 우주항공 회사에서 계속

일하게 되었다. 밥이 맡은 임무는 주로 응용 프로그램 전문가가 사용하는 소프트

웨어 도구 개발이었다. 우주 탐사로 들떠 있던 1960년대와 1970년대는 우주항공

업계의 일원으로서 정말 흥미진진한 시기였으며, 전산 분야 일원으로서도 더할

나위 없이 짜릿한 시기였다. 두 분야 모두 급속히 성장하고 있었으며, 전망은 하

늘을 찌를 정도였다!

항공우주 업계에서 몸담은 동안 밥이 배운 교훈은 자신이 소프트웨어 기술은

좋아하지만 관리자는 하기 싫어한다는 사실이었다. 밥은 줄곧 기술 전문가라는

스스로의 위치를 계발해왔으며, 이것은 밥의 경력에 두 가지 측면에서 큰 영향을

끼쳤다. (a)기술적인 지식은 항상 최신이고 유용했다, (b)상대적으로 경제적인 능

력과 관리 지식은 그만큼 감소했다.

옮긴이_2: 노스 아메리칸 에비에이션은 한국전에서 미그 전투기 킬러로 맹활약했던 F-86 세이버 전투기 제작사이며, 아폴로 프로그램에서 사령선과 서비스 모듈을 개발한 회사이다. 1996년 보잉에 합병되었다.

옮긴이_3: 군사용이나 민수용 로켓 추진체를 만드는 회사다.

옮긴이_4: 역사상 가장 성공적인 상용 여객기인 보잉 7xx 시리즈를 만들었으며, 한국 공군이 차세대 전투기로 채택한 F-15K를 개발한 회사이다.

지 은 이 소 개

xvi

기술적으로 더 이상 승진하기 어려운 직위에 이르자(히히!) 5), 밥은 학계로 눈

을 돌렸다. 밥은 1982~1987년 사이에 시애틀 대학교의 소프트웨어 공학 대학원에

서 교편을 잡았으며, 역시 너무나 학문적인 소프트웨어 공학 연구소(SEI, Software

Engineering Institute)에서 1년을 보냈다. 초창기 밥은 워싱턴 대학교에서 도구에 초점

을 맞춘 연구를 몇 년 정도(1970~1972년) 진행했었다.

학계에서 몸담고 있던 시절에 밥이 깨달은 교훈은 머리는 소프트웨어 공학 이

론을 즐길지 몰라도 마음은 실무에 있다는 사실이었다. 확실히 업계에서 사람을

빼낼 수는 있었으나, 사람에게서 업계에 대한 미련을 버리게 할 수는 없다. 새로

이 깨달은 교훈을 바탕으로 밥은 오랜 기간 동안 느껴왔던 전산 이론과 실무 사이

에 존재하는 ‘대화 단절’을 해소할 방법을 찾기 시작한다.

밥은 25권이 넘는 다양한 서적과 90편이 넘는 전문 논문을 작성하는 방법으로

전산 학계가 내놓은 발견을 평가하고 이를 실무에 실질적인 도움이 되도록 만드

는 전환 작업에 초점을 맞추기 위해 여러 가지 시도를 해왔다(이런 작업은 확실히

어려우며, 밥의 글과 신념에서 개척자 기질이 배어나는 이유가 바로 여기에 있다). 소프트

웨어 공학 강의와 세미나는 현업 개발자에게 이론적인 측면과 우수 사례에 초점

을 맞춘다.

밥이 발행하는 소식지인 ‘The Software Practitioner’ 역시 같은 맥락이다. 밥

이 명예 편집자로 있는 엘스비어Elsevier에서 여러 해 동안 편집을 맡은 좀 더 학술

적인 ‘Journal of Systems and Software’ 잡지에서도 마찬가지 냄새가 난다. 밥이

‘CACMCommunication of the ACM ’과 ‘IEEE Software’에 주기적으로 기고하는 칼럼도

비슷한 분위기이다. 비록 밥의 저술은 심각하면서도 반골적인 성향이 다분하지

만, 전산 분야에 통용되는 해학이 상당수 담겨 있다.

이 모든 사항을 고려하건대, 밥이 컴퓨팅 분야에서 가장 자랑스럽게 생각하는

순간이 언제일까? 1995년에 스웨덴 린코핑 대학교가 수여한 명예 박사 학위를 받

았을 때와 1999년에 ACM 전문가 학회의 특별 회원으로 임명되었을 때다.

옮긴이_5: 영어로 glass ceiling이 승진의 최상한선이라는 뜻인데, 공교롭게도 밥의 성이 바로 Glass이다.

xvii

사적인 이야기를 하자면, 로버트 L 글래스는 친자 두 명과 양자 두 명의 아버지

이며, 정보 시스템 관련 학계에서 활약하는 아이리스 베세이와 결혼했다.

로버트 L 글래스에게 연락하려면 developer.* 편집진에게 문의하기 바란다.

http://www.developerdotstar.com

xviii

앤드류 헌트, The Pragmatic Programmers, LLC, 객원 추천 서문 작성

앤디 헌트는 The Pragmatic Programmers, LLC의 공동 창립자이며, 프로그래머이

자 저자이자 출판업자로 널리 알려져 있다. 또한 앤디는 애자일 동맹Agile Alliance의

공동 창립자로, 훌륭한 소프트웨어를 개발하고 다른 사람도 함께 사용할 수 있도

록 돕는 일에 커다란 관심이 있다. 앤디는 공동 저자인 데이브 토마스와 함께 실

용주의 프로그래밍Pragmatic Programming을 만들었으며, 이 책에서 일반적으로 쉽게

받아들이는 통념을 과감히 깨고 개발자, 사용자, 관리자, 투자가에게 제대로 통

하는 핵심이 무엇인지 밝히고 있다. 앤디의 전자편지 서명인 ‘∧ndy’는 uucp6) 와

ihnp4 7)를 사용하던 구석기 시대로 거슬러 올라간다.

http://www.pragmaticprogrammer.com

도날드 J. 리퍼, Reifer Consultants Incorporated, 객원 추천서문 작성

도날드 J. 리퍼는 산업계와 정부 기관에서 30년 넘게 축적한 경험을 토대로 소프

트웨어 공학과 관리 분야를 선도하는 인물 중 한명이다. 리퍼씨는 현재 RCI의 대

표로, 자사의 소프트웨어 기능과 역량을 확장하기 위해 투자와 전략을 개발하려

는 포춘 500대 기업의 경영진을 지원하고 있다. 또 재임기간 동안 DoD(미국방성)

에 혁신을 불러일으킨 공로로 1995년 대중 서비스Outstanding Public Service 부문에

옮긴이_6: uucp는 Unix to Unix CoPy 약어로 컴퓨터 사이에 파일 전송, 전자편지 배달, 뉴스그룹 동기화와 같은 작업을 수행하는 프로그램과 프로토콜을 총칭한다. 인터넷이 널리 퍼지기 전에 다이얼 업 모뎀만으로 통신을 했기 때문에 초창기 유닉스 환경에서 널리 사용되었으나, 인터넷 환경이 발전함에 따라 자연스럽게 사라져버렸다.

옮긴이_7: ihnp4는 Indian Hill Network Processor 4의 약어로 인터넷에서 동작하는 SMTP가 존재하기 전에 전화선으로 통신하기 위해 만든 전자편지 프로토콜이다. 1989년 2월에 완전히 서비스가 중단되었다.

공 헌 한 사 람 들

xix

서 국방성 메달을 받았으며 소프트웨어 공학 부문에서 쌓은 업적으로 2002년에는

AIAA 소프트웨어 공학 수상자로 선정되기도 했다.

http://www.reifer.com

니콜라스 즈베진트조프, Software Management Network,

객원 집필가, ‘컨설팅의 진짜 비밀’ 작성

니콜라스 즈베진트조프는 테스트, 문서화, 변경, 기능 수정, 역공학 등 기존 시스

템 관리 부문에서 국제적인 전문가로 활동하고 있다. Software Management News

(1983~1994년) 소식지 창간자이자 편집장을 역임했으며, 널리 신뢰성을 인정받고

있는 이 소식지는 설치형 소프트웨어 업계에도 영향을 미쳤다.

http://www.softwaremanagement.com

길레스 후버, ospreydesign, 책 표지와 내부 디자인

길레스 후버는 책 디자인 분야에 뛰어들기 전에 거의 15년 동안 소규모 자영업과

기업형 그래픽 디자인 부문에서 일해왔다. 방대한 책 수집 버릇으로 인해 이삿짐

센터 직원의 눈총을 받기도 했던 후버는 프리랜서로 불현듯 책 디자인에 뛰어든

이후 한눈을 팔지 않았다. 자신이 직접 운영하는 책 디자인 블로그인 foreword는

현재 방문자가 하루 5천명이 넘으며, 책과 책 디자인에 대한 후버씨의 열정은 여

전히 뜨겁다. 후버씨는 사진을 공부하고 있으며, 조지아 주의 메이컨에서 낡은 집

을 천천히 수리하면서 자식 같은 고양이 네 마리와 함께 살고 있다.

http://ospreydesign.com

우디 콤프톤, 미술가, 로버트 L. 글래스 초상화를 그림

우디 콤프톤은 드럼 연주와 모터사이클을 즐기는 만화가이다. 우디는 플로리다에

위치한 게인스빌 근처에 살며, 밤낮이 바뀐 생활을 한다. 우디는 아내와 네 마리

애완 쥐, 검은 고양이와 함께 산다. 우디는“Is this Tomorrow?”에 실릴 모든 연재

만화를 직접 그린다.

http://www.isthistomorrow.com/

xx

몇 달 전 거의 사용하지 않는 벽장 구석을 정리하다가, 1980년대 후반부터 1990년

대 초반까지 모아두었던 컴퓨터 잡지 상자를 우연히 발견했습니다.

당시 한여름 내내 모든 잡지를 뜨겁게 달구던 사안이 있었는데, 바로 모티프

Motif 8)와 오픈룩Open Look9)이 벌이는 GUI 전쟁에서 누가 승리할 것인가 하는 것이

었습니다. 두 시스템의 기술적인 장단점을 비교하는 논쟁은 세세하고도 격렬했습

니다.

물론, 이 논쟁은 전혀 쓸데없는 짓이었죠.

CP/M10)과 S-100 버스11)를 사용하던 구석기 시절의 잡지에는 코드 작성이라는

고역을 영원히 종식시켜준다는 새 데이터베이스 제품 광고도 있었습니다. 보고서

생성과 데이터베이스 질의에 평이한 자연어를 사용하므로, 조만간 프로그래머라

는 직업이 사라지리라 예측했습니다.

물론, 그런 일은 일어나지 않았습니다.

당시 잡지는 여러 가지 기술적인 사안을 엇비슷한 방식으로 다루었습니다. 그

리고 모든 사안은 유사한 생명주기를 거쳐갔습니다. 처음 선보이고, 들떠서 더 많

옮긴이_8: 모티프는 OSF(Open Software Foundation)에서 만든 X11용 위젯 집합

옮긴이_9: 오픈룩은 선 마이크로시스템에서 만든 X11용 위젯 집합

옮긴이_10: CP/M은 게리 킬달이 만든 인텔 8080과 자일로그 Z80 CPU에서 동작하는 운영체제이다. MS-DOS의 기본 모델이기도 하다.

옮긴이_11: S-100 버스는 IEEE696-1983이라고 불리는 컴퓨터 버스로 첫 개인용 컴퓨터로 인정 받는 알테어 8800에 탑재된 시스템 버스이다. CP/M 운영체제와 함께 당시 전문적인 개인용 컴퓨터를 주름잡던 업계 표준이었다.

2 판 추 천 서 문

xxi

은 기대를 하게 되며, 요란하게 선동하기도 하며, 오랜 기간에 걸쳐 신중하게 논

쟁을 벌이다, 결국은 다음 새로운 기술이 레이더에 포착되면서 결국 묻혀서 사라

지는 생명주기 말입니다.

새로운 컴퓨터 언어, 새로운 방법론, 새로운 프레임워크 같은 기술 출현에도 불

구하고, 대다수 소프트웨어 프로젝트는 여전히 일정에 쫓기고, 예산을 초과해서

사용하지만, 구현된 기능은 미흡합니다. 애초에 문제 핵심을 제대로 파악하지 못

했기에 헛다리를 짚었던 탓이죠.

기술 진보가 제대로 된 소프트웨어의 정시 출시에 그다지 기여하지 못했다는

사실은 분명합니다. 그럼에도 불구하고, 수많은 잡지와 책은 하나같이 그때나 지

금이나 저차원 기술에 초점을 맞추고 있습니다.

다행스럽게도, 우리에게는 밥 글래스와 같이 논의를 고차원으로 끌어올리는 저

자가 있습니다.

밥의 수필은 소프트웨어 실무자들이 겪는 현실에 초점을 맞춥니다. 여기에 뜬

구름 잡는 소리는 없습니다. 소프트웨어 실무자들이 직면하는 상황은 어떤 면에

서든 나름대로 특수하며, 밥은 이러한 상황의 중요성을 이해합니다. 그래서 만병

통치 처방전이나 모든 상황에 통하는 충고는 내놓지 않습니다.

대신, 그는 사고를 키워주는 양식을 제공합니다.

11세기 철학자 피에르 아벨라르12)는 이렇게 말했습니다. “지혜는 의심에서 출

발한다. 의심에서 의문이 생겨나고, 답을 구하는 과정에서 진실을 깨닫는다.”

소프트웨어 논쟁을 다루는 밥의 수필에서 여러분은 의심의 씨앗과, 근본적인

의문과, 동료 탐구자를 만날 것입니다.

새 기술이 내거는 모호한 공약을 의심하십시오. 답을 구해야 할 원천적인 의문

을 제기하십시오. 밥 글래스가 말하는 의도를 숙고하십시오. 그리고 거기서 멈추

옮긴이_12: 피에르 아벨라르는 1070∼1142 동안 살았던 프랑스의 저명한 스콜라 철학자이며 신학의 대가이다

xxii

지 마십시오. 밥이 인용하는 서적을 찾아 읽으십시오. 프레드 브룩스와 데이비드

파나스의 글도 읽으십시오. 실용주의 프로그래머 시리즈 책을 찾아 보십시오. 밥

의 다른 책과 글도 읽으십시오.

그리고 무엇보다 올바른 질문을 던지십시오.

2005년 10월,

앤드류 헌트,

The Pragmatic Programmers, LLC

www.pragmaticprogrammer.com

xxiii

대체로 기술 서적에서 유머를 찾아보기란 참 어렵습니다. 하지만 적절한 유머는

새로운 개념을 배우는 과정을 한층 흥미진진하게 만듭니다. 제가 밥 글래스의 글

을 좋아하는 이유가 여기에 있습니다. 소프트웨어 공학 공동체 리더들이 한창 뜨

겁게 논쟁 중인 주제를 놓고, 밥은 풍자와 재치로 자신의 생각을 피력합니다. 밥

의 의견은 재미나고도 놀랄 만한 통찰력이 있지만, 때때로 커다란 파장을 불러 일

으키기도 합니다. 그는 유머가 넘치면서도 인간적입니다. 천부적인 이야기꾼으

로, 의미 심장한 일화와 비유를 사용합니다. 또한 밥 글래스는 좋은 스승이기도

합니다. 자신의 의견을 납득시키는 한 방편으로 역사, 윤리, 철학 속 교훈을 우리

에게 가르쳐 줍니다.

이 책은 근본적으로 논쟁과 논쟁 관리를 다루는 책입니다. 프로그래머/소프트

웨어 엔지니어와 관리자를 대립시킵니다. 안정과 변화, 말과 행동, 공약과 결과를

논하면서 이론과 실제를 대조합니다. 논쟁의 모든 측면을 보여줍니다. 또한 독자

가 스스로 생각해서 자신의 의견을 정립하게 만듭니다.

이 책은 또한 변화와 변화 관리를 다루는 책입니다. 기존 관념을 있는 그대로

받아들이지 말고 도전하라고 충고합니다. 변화가 더딜지라도 말입니다. 그리고

가까운 장래에 모든 문제를 해결해 주는 만병 통치약은 없다고 말합니다.

그러면서도 소프트웨어 공학이 최신 이론과 실제 적용면에서 차이가 큰 ‘이유’

를 생각해 보라는 질문을 던집니다.

이 책에서 제대로만 관리하면 논쟁도 건전하다는 사실을 기본 전제로 삼는 이

유는 실무자들이 자신의 생각을 성급히 구현하기 전에 논쟁을 통해 신중하게 숙

1 판 추 천 서 문

xxiv

고하도록 만들기 때문입니다. 밥은 가장 기본적인 논쟁으로 이론과 실제 사이에

존재하는 논쟁을 꼽습니다. 밥은 실무자 편에 서서, 어느 쪽도 상대측 도움 없이

는 발전하기 어렵다는 주장을 폅니다.

저 역시 실무자의 한 사람으로서 밥의 의견과 부연 예제에 크게 공감합니다. 이

제껏 제가 학계와 벌여온 수많은 논쟁이 밥과 같은 맥락에 있었습니다. 밥이 느꼈

던 좌절감을 저 역시 맛보았습니다. 그의 논지와 같은 의견으로 전투에서는 승리

했으나, 전쟁은 이겨내지 못했습니다.

이 책이 논쟁을 일으킬 소지가 다분한 이유는 이 분야에 뿌리 박힌 미신을 타파

하려 하기 때문입니다. 개인적으로 많은 부분에서 밥의 의견에 동의하지만, 기술

과 기술의 변천이라는 영역에서는 밥과 의견을 달리합니다. 밥은 혁명론자인 반

면, 저는 진화론자입니다. 밥이 좀 더 급격한 해결책을 구한다면, 저는 점진적인

진보를 추구합니다. 이렇듯 독자를 생각하게 만들고 변화시켜 나가는 것, 이것이

바로 이 책의 목적입니다.

이 책을 많이 좋아하지만, 몇 가지 문제점도 있습니다. 첫째, 책이 너무 깁니다.

저자가 할 말이 많은 탓에, 종종 핵심에 이르기까지 너무 오래 걸립니다. 둘째, 책

이 너무 짧습니다. 뭔가 해결책이 나올 법한 시점에 이르자마자, 저자는 이야기를

중단하고 독자가 스스로 생각하게 만듭니다.

당연히 저는 여러분께 이 책을 읽으라고 권합니다. 소프트웨어 관리자, 소프트

웨어 공학도, 학계 관련자, 컴퓨터 공학도, 프로그래머, 현업 종사자 등 모두에게

도움이 될 책입니다. 저자가 말하려는 논지와 그 의미를 곱씹으십시오. 그래서 그

속에 숨겨진 가치를 찾으십시오. 밥의 말을 글자 그대로 받아들이지는 마십시오.

밥은 위장의 천재이므로 독자 여러분의 주의를 끌어서 더 생각하게 만들려는 글

을 곧이곧대로 해석해서는 안 됩니다. 그의 의견에 동의하지 않는다면 더욱 좋습

니다. 적어도 어떤 주제에 대하여 나름대로 의견이 있다는 뜻이며, 바로 여러분의

의견이 소프트웨어 공학 분야의 미래를 만들기 때문입니다.

도날드 J. 리퍼, 대표

Reifer Consultants, Inc.

xxv

논쟁과 난상토론은 전산학과 소프트웨어 공학 분야에서 너무나 오랫동안 회피해

온 주제이다. 사람 나이로 따지자면 한 세대도 채 안 되기에, 이 분야는 젊음에 따

르는 성장의 고통을 고스란히 맛보고 있다. 그럼에도 불구하고 업계에서는 의견

을 진실로, 주장을 사실로 내놓는 행태가 잦다. 일부 사실과 대다수 진실이 가설

에 불과하다는 점을 전혀 인정하지 않은 채 말이다. 저명한 전산학자 데이비드 파

나스조차도 전산학에서 믿고 있는 진실 대다수를 ‘민간 신앙’이라고 부른 이유는

실험적으로 증명된 바가 없기 때문이다.

이 분야에 논쟁과 분란이 없다는 뜻이 아니다. 전산학자나 소프트웨어 공학자

N명이 머리를 맞대고 사안을 논하면, 흔히 옳은 의견 혹은 최선의 의견이 적어도

N개는 쏟아진다. 1989년 ICSEInternational Conference on Software Engineering 기조 연설

에서 빌 커티스는 이를 멋지게 표현했다. “한 방에 모인 설계자 15명 중 두 사람만

동의하면 이 두 사람이 다수가 된다.”

하지만 일반적으로 이러한 논쟁은 회의실이나 휴게실 내 분쟁으로만 그칠 뿐

공개적으로 드러나지 않는다. 이렇게 문제를 숨기는 행동은 종종 기이한 결과를

초래하는데, 한 예로 정형 검증Formal Verification의 가치에 대한 의견 차이가 곪아

터져서 1989년 Communications of ACM13)에서 상대를 인격적으로 비난하는 사태

저자 주_13: 사건의 발단은 ‘Program Verification: The Very Idea’라는 논문이다. 저자는 미네소타 대학교(University of Minnesota) 철학 교수이자 인문학 교수이기도 한 제임스 H. 페처 James H. Fetzer이다. Communications 1988년 9월호에 게재된 이 논문은 정형 검증에 대하여 매우 부정적인 견해를 피력했다. 가장 격렬한 반응은 같은 저널 1989년 3월호에서 터져나왔다. 정형 기법 지지자 10명은 페처 교수가 ‘왜곡’, ‘심한 오해’, ‘허위 진술’, ‘오보’ 하고 있으며 “인식이 부정확하며 무책임하고 위험하다”고 비난했다. 페처 교수는 이에 맞서 양쪽 손에 든 총구 불을 뿜기 시작했는데 그는 반대자들이 “사안을 전혀 이해하지 못하며” “지능이 떨어지고” “편협하기는 이를 데 없고” “참기 어려울 만큼 독선적이며” “종교적인 광신자와 이상 숭배자”라고 응수했다. 심지어 그는 동적 상황에서 프로그램 검증을 보여주기 위해, (장래에 발사할 미사일과 함께) 자원자를 모집하기까지 했다.

1 판 서 문

xxvi

까지 발생했었다(10여 년 전에 있었던 첫 번째 폭발은 단순한 요동에 지나지 않았다. 내

책 Software Soliloquies에서 이를 언급한 바 있다).

CACM 4월호에도 유사한 총격전이 있었다. 차후에도 이 문제로 다시 시끄러워

진다고 하더라도 전혀 놀랄만한 일이 아니다.

문제를 감춰서는 안 된다. 논쟁은 올바르게 벌여야 발전이 있다. 논쟁을 피하면

앞서 보았듯이 단절과 침체와 폭발을 초래한다. 한 가지 입장과 태도만 취하기에

는 이 분야의 역사가 너무 짧다. 주요한 의견 차이는 곪아서 썩기 전에 겉으로 드

러내고 말해야 한다.

흔히 이러한 논쟁은 이론과 실제의 차이라는 형태로 드러난다. 사실, 분야가 발

전하는 과정에서 이론과 실제가 기여하는 역할 차이가 논쟁을 일으키는 부분적

원인이다.

이 책에서는 이러한 논쟁 중 일부를 다룬다. 비록 양쪽 관점을 모두 제시하지

만, 이 책은 주로 실무자 입장을 옹호한다. “나는 30년 경력의 실무자이며, 내 머

리는 소프트웨어 공학 학계에 있지만 마음은 여전히 현장에 있다.”고 말해도 괜찮

을 정도로 학계에 몸도 담았었다.

이 책에서는 수필 모음이라는 형식으로 논쟁에 접근하는데, 크게 다음과 같은

몇 가지 주제로 나뉜다.

‘1부 논쟁의 장’은 파나스의 스타워즈Star Wars와 브룩스의 은총알Silver Bullet 논문

처럼 고차원적인 사안을 다루는 수필 모음이다. 또한 이론과 실제의 역사적 관계

를 독특한 시각에서 분석한다.

‘2부 기술 진영에서’는 소프트웨어 기술을 다루는 수필 모음이다. 예를 들면, 한

수필은 소프트웨어 설계라는 사안을 놓고, 소프트웨어 설계가 (인지 활동이라는) 본

질은 제쳐놓고 (방법론과 표현법이라는) 장신구에 치중하는 이유를 자문한다.

‘3부 최신 무기 정보’는 방법론, 도구, 언어에 관한 수필 모음이다. 예를 들면,

한 수필은 CASE 도구, 4GL 언어, 기타 생산성 향상 방법의 가치를 정량적으로 분

석한 자료를 검토하며, 일부 자료는 놀라운 결과를 보여준다.

xxvii

‘4부 지휘 본부에서’는 관리, 마케팅, 컨설팅을 다루는 수필 모음이다. 이 중 네

가지는 최근에 떠오르는 주제인 생산성 향상을 논하면서, 어디서 와서 어디로 가

는지에 관한 견해를 제시한다.

‘5부 연구실에서’는 연구 결과의 기술 이전을 다루는 수필 모음이다. 예를 들면,

한 수필은 전산학 교수에게 현재 교육 과정이 소프트웨어 유지보수를 등한시한

다는 사실을 알리는 공개 편지이며, 또 다른 수필은 이론과 실제 사이의 의사소통

단절이 일으키는 심각한 문제를 소개한다.

‘6부 전장 사후 분석’은 이제껏 토론한 사안을 정리하는 수필 모음이다. 한 수필

은 전산학과 소프트웨어 공학을 이론적으로 접근하는 방식에서 부족한 점을 지적

하고 개선안을 제안한다. 또 다른 수필은 이 분야에서 재미가 점차 사라짐을 통탄

한다.

마지막에는 좀 더 중요한 생각을 모아 ‘논평’ 형식으로 요약한 에필로그가 있다

(먼저 책 뒷부분부터 뒤적이지는 않으리라 믿는다).

이 책의 대상 독자는 소프트웨어 공학 분야를 염려하는 모든 사람들이다. 업

계 실무자도 좋고, 연구원이나 학계 종사자도 좋다. 다소 입맛을 맞추기 까다로

운 독자층이라서, 다양한 방식으로 글을 썼다. 어떤 글은 진지하고, 어떤 글은 (희

망사항이지만) 유쾌하다. 은유법도 사용하고, 지어낸 이야기도 있으며, 때로는 진

짜 사람과 장소에 가짜 이름을 붙이기도 했다. 앞서 출판한 수필 모음인 ‘Software

Soliloquies’(Computing Trends, 1981)에서 사용했던 방식인데, 효과가 있었다고 생각

한다.

이제 시작은 이쯤으로 끝내고, 독자 여러분에게 바통을 넘긴다. 바라건대, 독자

여러분이 여기서 읽은 내용에 대해 의견을 보여주면 좋겠다. 내 의견에 동의하든

동의하지 않든, 수동적인 태도는 버렸으면 좋겠다. 우리 분야에 존재하는 논쟁은

감추고 넘어갈 만큼 사소하지 않다.

로버트 L. 글래스,

1990년

xxviii

1판 서문을 읽었다면, 이 책의 의도를 이미 파악했으리라. ‘소프트웨어 컨플릭트

2.0’은 소프트웨어 공학 분야 내에서 일어나는 근본적인 쟁점을 밝혀내어 상세

히 진술하며, 이 과정에서 소프트웨어 실무자의 관점에 가장 가까운 입장을 옹

호한다.

하지만 원래 서문은 이미 15년이나 지난 책을 말한다. 도대체 15년 전 소프트웨

어 공학 책 재판을 왜 읽어야 할까? 소프트웨어 분야는 기술이 급격히 변해서 5년

만 지나도 구식이 돼버린다. 그럼에도 저자는 15년이나 낡은 책에서 독자 여러분

이 어떤 가치를 찾아낸다고 생각했을까?

솔직히 말해서, ‘소프트웨어 컨플릭트’ 개정판을 발행하자는 의견이 처음 나왔

을 때, 나 역시 그렇게 생각했다. 책 자체가 15년 전 내용일 뿐 아니라, 내 자신이

‘소프트웨어 컨플릭트’ 이후로 여러 권의 책을 펴낸 탓이다. 책을 펴낼 때마다 (당

연히) 사고는 좀 더 새로워지고 현대적으로 바뀌었다. 그래서 내가 시간을 들여 집

필하고 여러분이 시간을 들여 읽을 가치가 있는 프로젝트인지 의심스러웠다.

의문에 답할 목적으로, 참신한 21세기 관점에서 끔찍하게도 오래된 1판을 다

시 읽었다. 책을 읽다 보니, 내용 대부분이 여전히 참신하고 새롭다는 생각이 들

었다.

어떻게 이런 일이 가능할까? 소프트웨어 공학도 입장에서 나는 대개 철학적이

고 개념적인 관점을 고수한다. ‘하우투 How-to’를 다루는 책에는 별로 관심이 없다.

오늘날 벌어지는 플랫폼 전쟁과 언어 전쟁에 어느 한쪽 편을 들 생각도 없다.

나는 소프트웨어 공학 분야에서 지혜를 얻으려면 한 걸음 물러나서, 세세한 사

2 판 서 문

xxix

실로부터 마음을 비우고, 좀 더 깊이 숙고해야 한다고 믿는다. 그리고 이 책에서

바로 그렇게 했다는 사실을 깨달았다.

물론, (에이다 Ada 와 같은) 프로그래밍 언어, (구조적 분석과 설계와 같은) 방법론,

(CASE와 같은) 도구를 상세히 다루는 부분은 책의 진부함을 드러내어 당황스럽기

도 하다. 하지만 세세한 내용은 그때나 지금이나 이 책에서 다루려는 핵심이 아니

다. 미래를 반영하는 현대적인 개념과 철학, 그리고 이에 따르는 논쟁이 그때나

지금이나 변함없이 중요한 개념이다.

그래서 이 낡은 책이 여전히 현대적인 의미를 전달한다는 사실이 놀랍고도 기

뻤다. 어쩌면 독자 여러분은 놀라면서도 흡족하리라. 수필을 읽다 보면 각 절 끝

에 회고 수필을 추가한 사실을 발견할 텐데, 직전 수필에서 진부하다 싶은 부분과

여전히 가치 있다고 믿는 부분을 좀 더 구체적으로 설명했다.

독자 여러분께 소용이 없다고 생각했다면, 이 오래된 애장본의 새 판을 내놓지

않았을 것이다. 이제 판단은 여러분의 몫이다. 예전 독자들이 1991년판을 즐겼던

만큼, 여러분도 ‘소프트웨어 컨플릭트 2.0’을 즐기기 바란다.

진실을 밝히자면, 지난 15년 동안, 1판에서 지적하고 밝혀냈던 논쟁을 다루거

나 해소하는 책이 거의 없었다. 이런 관점에서 보면 처음 출간 당시와 마찬가지로

오늘날에도 이 책은 여전히 현실을 반영한다. 너무나 불행하게도 말이다.

로버트 L. 글래스,

2005년 가을

xxx

1

소프트웨어 컨플릭트

2.0

이론이 먼저냐, 실제가 먼저냐•

‘위험하며 오도• 誤導하다’

- 파나스의 논문을 통해 본 소프트웨어 연구 실정

‘은총알은 없다’ •

- 프레드 브룩스를 통해 본 소프트웨어 연구 실정

가장 뛰어나고 명석한 두뇌들이 내놓은 보고서•

회고: 논쟁의 전장

1부

논쟁의 전장

Software Conflict 2.0

2

이론이 먼저냐, 실제가 먼저냐?

- 이론: 근간이 되는 원리.

- 실제: 이론에 상대되는 활동. 전문적인 업무에 적극적으로 참여함.

(Oxford American Dictionary, 1980)

이론과 실제라는 단어의 뜻이 명확하며 모두가 이해하기에 어느 누가 이 두 단어

를 사용해도 품고 있는 의미에 별다른 의문을 제기하지 않는다. 하지만 두 개념

사이의 순서는 어떨까? 다시 말해, 이론과 실제 중 어느 것이 먼저일까?

십여 년이 넘게 정규 교육을 받은 우리는 이런 질문에 무의식적으로 대답한다.

이론이 먼저 나와서 실제의 틀을 마련한다고. 하지만 이와 같은 무의식적인 답안

에는 심각한 결함이 내재하며 뿌리 깊은 오해가 도사리고 있다.

예를 들어 크리스토퍼 알렉산더1)는 ‘Notes on the Synthesis of Form’ (Harvard

University Press, 1964)에서 이렇게 말했다.

옮긴이_1: ‘A Pattern Language: Towns, Buildings, Construction’를 쓴 저자로 요즘 컴퓨터 분야에서 유행하는 디자인 패턴 개념을 창시한 건축 분야의 권위자이다

3

1부 _ 논쟁의 전장

“비행기를 날게 하는 익형 날개airfoil wing가 발명된 시기는 공기보다

무거운 물체는 날지 못한다고 ‘증명’된 직후이다. 익형 날개에 작용

하는 공기역학은 날개를 사용하고서도 한참이 지나서야 이해하게 되

었다. 결국 공기역학 이론이 익형 날개의 발명에 기여했다기보다는,

익형 날개의 발명과 사용이 공기역학 이론의 발전에 크게 기여한 셈

이다.”

알렉산더에 따르면 실제가 이론보다 선행한다. 이 같이 놀라운 예제가 더 있을

까?

다음은 D.D. 프라이스의 ‘Sealing Wax and String’ 2)에서 발췌한 내용으로 알렉

산더의 예제와 놀랄 만큼 유사하다.

“열역학이 증기 기관에 미친 영향보다 증기 기관이 열역학에 기여한

바가 훨씬 크다. 역사에서 일반적인 사건 발생 순서를 살펴보면 기술

이 과학을 응용한 예는 찾아보기 힘들다. 오히려 과학이 기술을 응용

한 예가 훨씬 많다.”

물론, 예제 두 개로 ‘실제가 이론을 앞선다’는 가설을 증명하지 못한다. 그러한

경향을 입증하기조차 어렵다. 하지만 프라이스는 가설을 증명하려는 가능성을 제

시한다. 예제가 더 있을까?

‘The Sciences of the Artificial’(The MIT Press, 2nd ed., 1981)에서 허버트 A. 사이

몬은 이렇게 말한다.

“시분할 시스템(TSS, Time Sharing System)을 개발하고 개선하려면 일단 만

들어서 어떻게 동작하는지 살피는 방법이 가장 적합하다. 이것이 이

제껏 사용된 방법이다. 사람들은 시스템을 만들고, 수정하고, 단계적

지은이_2: ‘Sealing Wax and String: A Philosophy of the Experimenter’s Craft and its Role in the Genesis of

High Technology’ (Proceedings of the American Association for the Advancement of Science Annual Meeting, 1983)

Software Conflict 2.0

4

으로 개선했다. 물론 이론으로 예측이 가능했다면 이런 실험은 불필

요하다. 하지만 현실적으로 이론이 이를 뒷바침해주지 못했다. 이렇

게 극도로 복잡한 시스템을 잘 아는 사람들 중 이론으로 예측하는 방

법을 제대로 아는 사람을 보지 못했다. 시스템을 이해하려면 먼저 만

들어 놓고 동작을 관찰해야 한다.”

사이몬은 ‘실제가 이론을 앞선다’는 개념을 우리 전산 분야와 소프트웨어 분야

로 한 걸음 더 가까이 끌어들인다. 이제 소프트웨어 분야에서 이론과 실제를 좀

더 자세히 살펴보자.

나는 전산 분야와 소프트웨어 분야의 실제를 봐왔고, 이 분야에서 일어났던 획

기적인 사건도 많이 기억한다. 그래서 내게는 실제가 이론을 앞선다는 개념이 낯

설지 않다. 물론, 컴퓨터의 기원은 북미와 유럽에 산재했던 연구소로 거슬러 올라

간다. 하지만 1950년대 중반에 이르러 전산분야와 소프트웨어 분야는 전문 영역

으로 각광받기 시작했다. 처음에는 실제가 이론을 앞서지 않았다 하더라도, 분야

가 발전하면서 사실상 실제가 이론을 추월했다. 1960년대에 이르러서야 전산학이

라는 학문 분야가 태동하기 시작했다. 그러고 나서 1960년대 후반 혹은 1970년대

초반에야 학문적 연구가 본격적으로 시작됐다.

이 분야의 원로 입장에서 개인적 경험을 떠올려 보면, 실제가 이론을 앞선다는 개

념이 타당해 보인다. 하지만 경험은 그릇된 교훈을 가르치기도 한다. 한 사람의 경

험이 다른 사람의 경험과 완전히 다를 수도 있다. 그렇다면 이 가설을 확인할 다른

방법은 없을까?

지금까지는 전산과 소프트웨어를 한 분야처럼 취급해서 살펴보았다. 그 대신

각 구성 요소를 좀 더 자세하게 들여다 보면 어떨까? 이러한 방법으로 이론과 실

제 사이의 관계를 관찰할 수 있을까?

프로그래밍 스타일은 어떨까? 이론이 먼저일까, 실제가 먼저일까? 확실히, 프

로그래밍 스타일에 관한 책이 출간되기 전에도 많은 프로그램이 쏟아져 나왔

다. 구현 스타일이 멋진 프로그램도 있었고 그렇지 않은 프로그램도 있었다는 사

5

1부 _ 논쟁의 전장

실을 생생히 기억한다. 프로그래밍 스타일은 이론이 나오기에 앞서 실제가 아

주 잘 정립되었다고 생각한다(흥미롭게도 초창기 스타일 책 시리즈인 레가드3)가 지은

‘Proverbs……’ 시리즈는 사실상 우수한 실제 기법을 집대성한 책이었다).

컴파일러는 어떨까? 컴파일러 이론을 문서화하기 훨씬 전에 포트란Fortran, 커

머셜 트랜스레이터Commercial Translator 4), 팩트FACT

5), 코볼COBOL 과 같은 프로그래

밍 언어를 위한 컴파일러가 나왔다. 전산학계의 핵심 주제인 컴파일러 역시 이론

이 발전하기에 앞서 실제가 잘 정립된 경우이다.

심지어 오늘날에도 실제가 이론을 앞서는 예는 존재한다. 시뮬레이션은 복잡한

문제의 설계나 요구사항 정의에 자주 사용하는 시스템 수준의 도구이다. 하지만

전산학계에서는 시뮬레이션이라는 주제를 거의 거론하지 않는다. 최근에 학계가

관심을 보이는 프로토타이핑은 시뮬레이션과 다소 차이가 있다(실무에서 사용하는

시뮬레이션은 문제의 이론을 정립하기 위해서 실용적인 임시 해결책을 만드는 작업이다.

여기서도 실제가 이론을 앞선다!).

사용자 인터페이스 설계는 제록스 PARC6)에서 기원한 이론이지만, 지금은 이론

부문보다 (특히 마이크로컴퓨터) 실제 부문이 더욱 급속히 성장했다.

설계 자체는 아직 이론으로 설명이 안 되는 부분이 많다. 흔히 설계 과목은 방

법론과 표현 방식에 치중하는데, 설계자라면 누구나 설계라는 작업이 단순히 프

레임워크나 기록 방법 이상으로 복잡하다는 사실을 안다. 다시 한 번, 설계 부분

에서도 실제가 이론을 훨씬 앞선다.

사실 소프트웨어 공학의 본질인 ‘문제 해결’이라는 일반 개념에서도 (설계라는

작업처럼) 문제 해결이라는 실제는 까마득한 옛날부터 해오던 일이지만 (앞서 사

옮긴이_3: 헨리 F 레가드는 ‘Programming Proverbs for FORTRAN Programmers’, ‘FORTRAN with Style: Programming Proverbs’, ‘Programming Proverbs’, ‘Pascal with Excellence: Programming Proverbs’, ‘C with Excellence: Programming Proverbs’와 같은 ‘Proverbs’ 시리즈를 집필했다.

옮긴이_4: 커머셜 트랜스레이터는 코볼이 나오기 전에 만들어진, 영어와 유사한 자료처리용 프로그래밍 언어이다.

옮긴이_5: 팩트는 역시 코볼이 나오기 전에 만들어진, 영어와 유사한 자료처리용 프로그래밍 언어이다. Fully Automated Compiling Technique의 약어.

옮긴이_6: 제록스 PARC는 최초로 실용적인 GUI를 탑재한 스타 워크스테이션과 이더넷과 같은 당대 최신 기술을 개발한 Xerox Palo Alto Research Center를 줄여서 부르는 용어이다.

Software Conflict 2.0

6

이먼의 The Sciences of the Artificial에서 언급하듯이) 이론은 여전히 초기 정립 단계

이다.

이렇듯 실제가 이론을 앞서는 예는 끝없이 많다. 놀랍지 않은가? 내 자신의 역

사적 관점에도 불구하고, 이 사실은 내게 여전히 놀라움으로 다가온다. 내 학문적

배경은 이론이 다진 토대 위에 실제가 선다는 개념을 강력히 지지한다. 만약 이

개념이 옳지 않다면 이 사실이 뜻하는 바를 이해해야 한다.

이 개념이 뜻하는 이론과 실제 사이 관계를 도표로 나타내보자. 다음은 내가 그

린 도표이다. 나는 근본적으로 특정 분야에서 실제가 먼저 생겨나 처음에는 급속

히 발전한다고 믿는다. 이론은 실제가 어느 정도 체계를 갖춘 후에 나오게 되며,

이 역시 급속히 발전하다가 어느 시점에서 이론이 실제를 앞지른다.

우선은 이 관계가 참이라고 가정하자. 그렇다면 다음 도표가 의미하는 바는 무

엇일까?

진보 또는지식

실제

이론

시간

먼저, 분야의 초기 단계에서는 실제를 관찰하여 이론을 정립하는 방법이 가장

효율적이라는 점이다. 물론 이론가는 과거 방식에 얽매이지 않고 자유롭게 새로

운 사고를 체계화해야 한다. 하지만 실무, 특히 우수 사례로부터 배울 교훈이 너

무나 많다. 이와 같은 사고는 중요하다. 이제껏 전산분야와 소프트웨어 분야는 거

의 이러한 사고를 따르지 않고 이론을 발전시켜 왔다. 실무 경험이 있는 전산 이

론가는 소수에 불과하다. 우리 분야에서 실무를 흉내 내는 실험적 연구는 거의 없

7

1부 _ 논쟁의 전장

다. 프로그래머에 대한 실증적 연구Empirical Studies of Programmers 7) 일부를 제외하고

는 업계 실무자가 이론 정립에 참여하는 경우도 거의 없다.

즉, 적어도 이론에 대한 초기 접근 방식이 변해야 한다는 뜻이다. 무시하기에는

실무지식이 제공하는 이점이 너무나 크다.

도표에서 얻는 또 다른 결론은 이론이 실제를 추월하는 시점, 즉 실제가 이론

에 귀를 기울여야 하는 시점이 있다는 사실이다. 예를 들어 데이터베이스나 자료

구조와 같은 영역에서 이론이 제공하는 프레임워크는 해당 분야에서 일하는 대

다수 실무자의 지식 수준을 능가한다. 여기서도 마찬가지로 이론이 도달한 수준

에 실제가 미치지 못한다는 뜻이다. 초반에 이론이 실제로부터 배우지 못했듯이,

이번에는 실제가 이론으로부터 배우지 못한다.

다시 말하면, 앞서 소개한 도표는 이론과 실제 사이에 존재하는 근본적인 의사

소통 문제를 보여준다. 현재 전산 분야와 소프트웨어 분야에 현존하는 학문과 실

무의 격차는 도표가 의미하는 바를 이해하지 못한 탓이다.

사실 위 도표는 극도로 단순화한 형태이다. 정확한 그림이라면 이론과 실제가

여러 차례에 걸쳐 앞서거니 뒤서거니 꼬인 모습으로 발전하리라. 하지만 아주 복

잡한 그림일지라도 (확대하면) 위 도표가 의미하는 바는 여전히 타당하다.

실제가 이론을 앞서는가? 어떤 단계에서, 어떤 시점에서는 그렇다. 이제 이론

과 실제 모두가 이 사실이 의미하는 바를 이해하고 활용할 때가 되었다.

감사의 말: 이 생각을 발전시키는 데 도움을 준 아이리스 베시와 데일 다우징에

게 감사를 전한다.

옮긴이_7: ‘Empirical Studies of Programmers’는 ACM SIGCHI이 주관하는 워크숍으로 프로그램 문서, 형식, 협업과 같은 분야에서 일어나는 심리학적인 연구 결과를 발표하는 행사이다.

Software Conflict 2.0

8

‘위험하며 오도誤導하다’- 파나스의 논문을 통해 본 소프트웨어 연구 실정

스타워즈8) 방어 시스템을 놓고 한동안 논쟁이 치열했다.

하지만 이 글은 스타워즈에 관한 논의가 아니다. 스타워즈 논쟁에서 시작된, 소

프트웨어를 바라보는 다른 시각에 대한 글이다.

이 시대를 이끄는 전산학자 중 한 사람인 데이비드 파나스 교수9)가 스타워즈처

럼 복잡한 시스템의 소프트웨어 문제는 극복하기 불가능하다고 주장한 탓에 스타

워즈 위원회 보직을 사임했다는 사실을 아는지 모르겠다.

파나스의 논문10)은 1985년 아메리칸 사이언티스트 9~10월호에 게재되었으며,

각종 전산 전문 저널에도 실렸다. 이 논문에서 그는 시스템의 소프트웨어를 성공

적으로 구축하기 불가능하다고 믿는 이유를 설명한다.

하지만 나는 파나스의 논문을 다른 시각에서 살펴보려 한다. 그는 시스템을 구

축하지 못하는 이유를 논하면서, 소프트웨어 분야의 현 실정을 상당히 곤혹스럽

게 평가했다.

옮긴이_8: US Strategic Defence Initiative, 레이건 시절에 만든 전략적 방위 주도권 혹은 전략적 방위 구상이다. 부시 시절로 들어와서 MD(Missile Defense) 계획으로 부활해서 북핵 문제와 맞물려 상당한 탄력을 받고 있다. 하지만 스타워즈에 이어 MD 시스템 역시 요격 가능성이 떨어지는 불안정한 시스템을 터무니 없이 많은 돈을 들여 개발한다는 비판에 직면해 있다.

옮긴이_9: 데이비드 파나스 교수는 1972년에 쓴 ‘On The Criteria To Be Used in Decomposing Systems into Modules’를 통해 최초로 모듈화 개념을 설명한 소프트웨어 공학 부문의 권위자이다.

옮긴이_10: http://klabs.org/richcontent/software_content/papers/parnas_acm_85.pdf를 참조하기 바란다.

9

1부 _ 논쟁의 전장

파나스 논문은 소프트웨어 실무의 현 실정을 공격하는 발언이 아니었다. 안타

깝게도 일부 전산학자들은 소프트웨어를 놓고 “항상 예산을 초과하고, 일정을 지

연하며, 불안정하다”고 비판하는 경우가 잦다. 이런 주장에 대해 독자 여러분도

나름대로 의견이 있으리라.

실제로 파나스가 공격한 부분은 소프트웨어 연구의 현 실정이었다. 파나스는

자신의 논문에서 당시 소프트웨어 분야를 주도하던 각 연구 방향이 스타워즈에

무용하다고 생각하는 이유를 조목조목 설명했다. 이런 발언은 해당 연구 분야에

어두운 그림자를 드리웠다. 그가 지적한 몇 가지 예를 살펴보자.

흔히 새 언어나 새 도구가 소프트웨어 생산성을 극적으로 향상시키리라는 예측

을 들어보았을 테다. 이에 대해 파나스는 아니라고 말한다. “새 프로그래밍 언어

가 극적인 향상을 가져오리라 기대해서는 안 되며”, “프로그래밍 환경 문제가 우

리 분야의 진짜 장애물은 아니다.”

흠, 그렇다면 수년 내 프로그래머라는 직업이 사라진다는, 소위 자동 프로그래

밍 시스템이라는 방법론은? 파나스는 “자동 프로그래밍 시스템을 둘러싼 주장은

지나치게 과장되었다고 믿는다” 그리고 “알고리즘 자체를 입력하는 경우가 아니

라면, 결과의 효율성은 형편없이 떨어진다. 현재 비절차적 자동 프로그래밍이 내

놓는 성과에 주목할 만한 발전/성과는 없을 것이다.”라고 말한다.

그렇다면 인공지능(AI)의 극적인 발전이 우리에게 희망을 주지 않을까? 파나스는

다시금 비관적인 시각을 피력하며 이렇게 말한다.

오늘날 일반적으로 사용하는 AI는 완전히 다른 두 가지 정의가 있다.

AI-1: 인간의 지능으로만 해결할 수 있었던 문제를 컴퓨터로 해결한다.• 11)

AI-2: 규칙-기반 프로그래밍을 사용하여 인간이 문제를 푸는 방식으로 문•

제를 해결한다.12)

옮긴이 주_11: AI-1의 대표적인 예로 심리학 치료사를 흉내내는 ELIZA가 있다.

옮긴이 주_12: AI-2의 대표적인 예로 결혼 정보 회사에서 사용하는 배우자 대상 찾기 소프트웨어가 있다.

Software Conflict 2.0

10

파나스는 “AI-1 분야에서 눈에 띄는 성과를 본 적이 있다. 하지만 분야만의 고

유한 기술은 없었다.” 라고 언급했다. 다시 말하면, AI-1 방법으로 문제 하나를 해

결한 학습 경험을 다음 문제로 확장하기가 어려웠다는 뜻이다.

“AI-2가 취한 접근 방식은 위험하며 오해를 일으킬 소지가 많다고 생각한다. 프로

그램 동작 방식을 이해하기 어렵고 예측하기도 어렵다. 기술을 일반화하지 못한다.”

여기서 파나스의 공격은 통렬하다. 그는 전문가 시스템이 별로 믿을 만하지 않다고

말한다.

파나스는 소프트웨어 신뢰성 역시 우려를 표한다. “우리는 소프트웨어 신뢰성

을 보장하는 방법을 알지 못한다.”라고 그는 말한다. 그렇다면 소프트웨어 시스템

이 명세를 만족하는지 여부를 수학적으로 증명하는 정확성 증명은 어떠한가? “거

대한 소프트웨어에서 아주 작은 부분이라도 확실하게 정확성을 증명하기란 불가

능하다고 생각한다. 설령 그런 증명이 있다 하더라도 어떻게 해석할지 모른다.”

그는 다음과 같은 예제를 내놓는다. “하드웨어와 입력 데이터에 알지 못하는 오류

가 존재하는 상황에서 프로그램의 정확성을 입증할 수 있는 기술은 없다.”

언뜻 보기에 파나스의 논문은 소프트웨어 연구의 현 상태를 신랄히 비난하는

듯 들린다. 파나스 교수는 이 문제도 언급했을까?

“우수한 소프트웨어 공학은 결코 쉽지 않다.”라고 그는 말한다. “새 기술로 소

프트웨어 설계가 쉬워지고 오류가 사라지리라 생각하는 사람들은 진짜 중요한 문

제를 간과하고 있다.” “향후 20년 동안 연구해도 거대 시스템을 구축하는 어려움

이 감소하리라 기대하지 않는다.” “소프트웨어 연구 중 극소수만이 유용한 성과를

내놓는다. 하지만 좋은 성과가 나머지 연구 결과에 묻히기 때문에 유용한 성과 대

부분은 주목받지 못하고 사라진다.”

진실로 소프트웨어 연구가 미심쩍은 방향으로 엇나가고 있다면 우리는 어떻게

대처해야 할까? 파나스는 여기에 관한 의견도 제시한다.

“문제의 실무적인 측면을 잘 아는 사람들만이 연구 프로젝트 결과가

유용한지 여부를 판단할 수 있다. 응용 분야 연구는 성공적인 연구자

11

1부 _ 논쟁의 전장

와 숙련된 시스템 엔지니어가 참여한 팀에서 판단해야 한다. 다시 말

하면, 유용한 결과를 내놓고 싶은 연구자라면 평가 과정에 실무자를

참여시켜야 한다.”

이제 한 걸음 물러나서 파나스가 한 말을 전체적으로 음미해 보자. 물론 그의

논문은 스타워즈 규모의 실시간 소프트웨어 시스템을 염두에 두었다. 하지만 현

재 연구의 가치를 비판하는 그의 견해 대부분은 대규모 소프트웨어 시스템뿐만

아니라 중소 규모 소프트웨어 시스템에도 적용될 수 있다.

소프트웨어 생산성을 비약적으로 향상시킬 계기, 몇 배로 껑충 끌어올릴 방법

은 무엇일까?

언어나 도구가 아니다.•

자동 프로그래밍 방법론도 아니다.•

소프트웨어 정형 검증도 아니다.•

인공지능도 아니다. •

요즘 인기 있는 소프트웨어 연구 주제 어느 것도 아니다.•

생산성 도약을 고대하는 소프트웨어 실무자에게는 실망스러운 이야기이다.

소프트웨어 연구자에게는 영양가 높은 고민거리이다.

Software Conflict 2.0

12

‘은총알은 없다’- 프레드 브룩스를 통해 본 소프트웨어 연구 실정

지난 이삼십 년 동안 전산학계는 소프트웨어 생산성을 극적으로 향상시키겠다는

공약을 내걸었다. 필사적으로 전산학계 연구자를 믿으려는 관리층은 기꺼이 그들

이 내놓는 아이디어를 족족 받아들였다.

하지만 결과는 대다수 관리자에게 실망을 안겨주었다. 부연하자면, 새로운 연

구 아이디어를 실험적으로 적용해 본 바, 실무에서 생산성을 높이기는 했다. 하지

만 차이가 너무나 미미해서 많은 관리자가 “굳이 왜?”라며 당혹스러워 했다.

연구자들은 상황을 전해 들었지만 별로 주의를 기울이지 않았다. 자신들의 아

이디어가 멋진 결실을 내놓지 못하는 이유를 고민하는 대신, 실무자들이 아이디

어를 제대로 적용하지 못한 탓에 전산 학계가 업적을 공평하게 평가받지 못한다

고 응수했다.

이 문제를 놓고 새로운 관점이 나오고 있다. 전산 분야에서 가장 뛰어나고 명석

한 인재들로부터 말이다.

첫째가 데이비드 파나스이다. 스타워즈 프로젝트를 비판하는 일련의 논문에서

그는 소프트웨어 연구의 현 실정도 비판한다. 소프트웨어 연구가 실무를 비약적

으로 향상시키지 못했으며, 사실상 향상시킬 수 없고, 일부 연구는 “위험하고 오

도할 소지가 있다”고 말한다.

이러한 파나스의 관점을 지지하는 사람들이 있다. 전산 분야에서 의심할 여지

13

1부 _ 논쟁의 전장

없이 가장 중요한 책인 ‘The Mythical Man-Month’의 저자이자 대규모 OS/360

프로젝트를 책임졌던 관리자인 프레드 브룩스가 파나스의 의견에 공감하면서 새

로운 생각을 덧붙였다.

브룩스는 IEEE 컴퓨터 저널 1987년 4월호에 게재한 논문을 통해 자신의 입장

을 표명했다. 이 논문이 곧바로 은총알Silver Bullet 논문13)이라 불리게 된 이유는 소

프트웨어 공학의 근본 문제를 늑대 인간, 즉 은총알로만 죽일 수 있는 괴물에다

비유한 다음, 소프트웨어 분야에서 은총알은 없다고 주장했기 때문이다.

브룩스가 말하려는 바는 무엇일까? 많다. 한 가지를 들자면 소프트웨어 제작은

어렵고 앞으로도 어려울 것이라고 그는 주장한다. 소프트웨어 제작이 어려운 이

유는 소프트웨어가 본질적으로 지니는, 그리고 지녀야 하는 복잡성 때문이다. “소

프트웨어는 어쩌면 인간이 만든 어떤 피조물보다도 복잡하며,” “소프트웨어 시스

템은 컴퓨터보다 상태state 수가 몇 배는 더 많으며,” “소프트웨어의 복잡성은 본질

적인 속성으로,” 수학 분야에서는 복잡한 문제를 단순화한 모델이 문제 해결 도구

로 효과적이지만, 소프트웨어에서 복잡성은 다른 분야에서 사용하는 기술로 해결

하지 못한다.

소프트웨어 제작은 어렵고 앞으로도 어렵다고 단언한 후, 브룩스는 소프트웨어

이론가의 연구 방향을 면밀히 분석하고 파나스와 마찬가지로 소프트웨어 연구가

불충분 하다는 결론에 도달했다. 연구 방향에 전망이 없다는 뜻이 아니라고 브룩

스는 말한다. 그는 고차원 언어, 시분할 시스템, 유닉스나 인터리스프Interlisp14)와

같은 통합 프로그래밍 환경 등의 발전으로 생산성이 이미 한 차례 크게 도약했다

는 사실을 지적한다. 은총알을 찾으려는 현재 연구는 상대적으로 미미한 개선만

을 성취할 뿐이며, 소프트웨어 공학에서 극적인 비약은 이미 일어났는지도 모른

다고 브룩스는 말한다.

옮긴이_13: ‘No Silver Bullet: Essence and Accidents of Software Engineering’ 전문은 http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf 를 참조하기 바란다.

옮긴이_14: 인터리스프는 만든 회사 이름을 따서 BBN 리스프라고도 불리며 리스프 프로그래밍 언어의 변종이다.

Software Conflict 2.0

14

하지만 브룩스는 여기서 멈추지 않는다. 현재 연구 방향에서 극적인 생산성 향

상을 얻지 못한다면, 어디서 얻을 수 있을까? 그는 다소 평범하지만 좀 더 가능성

있는 길을 제시한다.

가능하다면 소프트웨어를 제작하지 말고 구매하라. 1960년대에 비해 19901.

년대에 이르러 패키지 소프트웨어는 훨씬 실용적이 되었다. 브룩스에 따르

면 패키지 제작 기술이 나아져서가 아니라 하드웨어에 비해 소프트웨어의

상대적인 비용이 너무 높아진 탓에, 대다수 비즈니스가 업무에 소프트웨어

패키지를 맞추기보다 소프트웨어 패키지에 업무를 맞추기 때문이다.

점진적으로 소프트웨어를 제작하라. 2. 프로토타이핑으로 소프트웨어 요구사

항을 다듬어라. 소프트웨어를 점진적으로 개발해서 개발 주기 초반부터 부

분적인 해결책을 내놓아라. 소프트웨어 제작이 진정으로 어렵고 앞으로도

어렵다면 근본적으로 새로운 접근 방식을 취해야만 한다.

뛰어난 소프트웨어 설계는 뛰어난 설계자로부터 나온다는 사실을 기억하3.

라. 창의적인 소프트웨어 인재를 고용하고 양성하라. 브룩스는 인재 양성

방법으로,

a. (가장 숙련된 사람이 반드시 최고는 아니라는 사실을 염두에 두고) 가능한

이른 시기에 최고 설계자를 가려내기

최고 기대주에게 경력 조언자 붙이기b.

개인별로 경력 개발 계획과 경력 파일을 만들어서 관리하기c.

상호소통을 통해 서로 자극이 되는 만남의 기회를 제공하기 등을 제시d.

한다.

그렇다면 파나스와 브룩스가 우리에게 전하려는 메세지는 무엇일까? 소프트웨

어 개발은 개념적으로 어렵고, 만병통치약은 없으며, 실무자는 혁명적인 도약을

고대하지 말고 점진적인 발전을 추구해야 한다는 메시지다.

소프트웨어 분야 종사자 중에는 실망하는 사람도 있겠다. 조만간 비약적인 발

15

1부 _ 논쟁의 전장

전이 있으리라 기대하던 사람들 말이다.

하지만 냉정한 현실주의자들에게는 신선한 공기와 같은 생각이다. 드디어 그

림의 떡이 아니라 좀 더 가시적인 무언가에 집중할 수 있겠다. 이제는 소프트웨어

생산성 측면에서 가망성 없는 도약을 고대하는 대신 가능성 있는 점진적 발전을

추구할 수 있겠다.

길을 열어준 데이비드 파나스와 프레드 브룩스에게 감사를 전한다.

Software Conflict 2.0

16

가장 뛰어나고 명석한 두뇌들이 내놓은 보고서

“향후 십년 동안 소프트웨어 생산성, 안정성, 적시성을

10배 이상 향상시킬 기술적 발전은 눈 씻고 찾아봐도 없다.”

“업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다.”

“ 진짜 문제는 기술이 아니다. 오늘날 정말로 심각한 문제는 관리다.”

1980년대 후반 미 국방과학부 특별 위원회가 군용 소프트웨어에 관하여 내놓은

보고서15)는 위와 같이 간결하고도 단호한 문구로 시작한다. 유명한 전산학자인 프

레드릭 P. 브룩스 Jr.가 의장을 맡고 브룩스 자신이 ‘근면한 전문가 그룹’이라 칭하

는 구성원들로 이루어진 이 특별 위원회는, 당시 소프트웨어 분야에서 직면한 여

러 가지 문제점을 비판했다.

자료 처리 분야에 종사하는 일반 소프트웨어 실무자가 군용 소프트웨어 문제를

다루는 보고서에 신경을 써야 할까? 몇 년 전에 나온 보고서라는 점을 감안한다면

보고서가 제시하는 관점이 아직도 유효할까?

보고서의 폭과 깊이와 적시성을 고려해볼 때, 내 대답은 확실히 “그렇다”이다.

옮긴이_15: 국방과학부(Defense Science Board Task Force on Military Software)가 발표한 보고서 세부 목차와 내용은 http://www.acq.osd.mil/dsb/reports.htm를 살펴보기 바란다. 아쉽게도 1993년 이후 자료만 전산화 되어 있으므로 나머지 자료는 우편으로 받도록 신청해야 한다. 이 보고서 원문은 http://stinet.dtic.mil/cgi-bin/GetTRDoc?AD=ADA188561&Location=U2&doc=GetTRDoc.pdf에서 찾을 수 있다.

17

1부 _ 논쟁의 전장

이 보고서는 많은 소프트웨어 괴물을 대적하고 무찌르며 다양한 사실을 올바른

관점에서 조망한다. 게다가 이 보고서를 작성한 사람들은 업계에서 가장 뛰어나

고 명석한 인물들이다.

이 보고서가 나온 1987년 9월 이후로 나는 줄곧 보고서 내용을 곰곰이 생각해

왔다. 그리고 보고서가 1980년대 후반 당시의 소프트웨어 ‘실정’을 반영하는 결정

적인 발언이라고 결론지었다. 개인적으로는 보고서가 내린 결론에 전적으로 동의

하지는 않지만, 동의하지 않는 부분조차도 많은 생각을 불러일으켰다. 여기서 간

단히 정리하는 보고서 내용이 독자 여러분에게도 커다란 자극이 되었으면 한다.

이 보고서가 ‘수년간 군대와 계약업체가 겪어온 제도적 문제’와 ‘새 기술과 새

관리 개념으로 전환하는 문제’를 공략하는 방식은 놀랍기 그지없다. 보고서는 미

국방성이 소프트웨어 조달 부문, 특히 순환 보직과 같이 전통이 오래된 영역을 집

중적으로 개선하고 ‘장교 경력 개발 과정을 구조적으로 조정하여 뛰어난 기술력과

폭넓은 경영 감각을 지니는 기술 관리층 기간 요원을 양성해야’ 한다고 제안한다

(현재 대다수 장교는 대략 2년에 한 번씩 직무를 바꾸므로, 특정 기술 영역에서 실력을 쌓

기가 어렵다).

과거 유사한 의견을 내놓았던 많은 연구를 무시한 군부의 주의를 끌려는 이 보

고서는, 인정사정 보지 않고 연타를 날린다. 힘찬 문체로 간결하고도 명쾌한 주장

과 근거를 펼친 후 권고안을 제시한다.

예를 들어 이전 연구 결과에 대하여 보고서는 다음과 같이 평한다. “앞서 많은

연구가 적절한 결론과 상세한 추천을 충분할 정도로 제시했다. 하지만 대다수가

채택되지 않은 상태이다. 군용 소프트웨어 문제가 실제로 존재한다 해도, 그다지

긴급을 요하지 않는 듯이 보인다.”

조사 결과 몇 가지

하지만 군사 자료를 다루지 않는 일반 개발자에게 이 보고서는 무슨 의미가 있을

까? 다음 조사 결과를 살펴보자.

Software Conflict 2.0

18

시스템 분석에 관하여, 보고서는 소프트웨어 개발에서 요구사항 정의가 •

‘가장 어려운 부분’이라고 지적한다. 요구사항 정의는 소프트웨어 분야에

내재하는 불가피한 문제라고 인정하며, 해결 방법으로 프로토타이핑을 지

지한다.

“소프트웨어 개발에서 가장 어려운 부분은 정확한 요구사항 정의이다. 요

구사항과 장단점 우선순위를 상세히 기록하는 방법에는 흔히 사용하는 그

럴듯한 방법조차 없다. 그릇된 판단이 넘쳐난다. 가장 흔한 판단 오류는 과

도한 기능으로, 이러한 실수가 프로그램 크기와 성능에 미치는 악영향은

설계 주기 후반에야 드러난다. 흔히 저지르는 또 다른 오류는 사용자 인터

페이스를 맘대로 잘못 단정하는 일이다. 우리는 이러한 어려움이 불가피하

다고 본다. 사용자가 운영 환경에서 실제로 써보면서 소프트웨어를 테스트

해보지 않고서는, 그래서 명세를 반복해서 조정하지 않고서는, 소프트웨어

시스템의 동작 요구사항을 정확히 내놓지 못한다고 믿는다. 오늘날에 구축

되는 시스템은 머리 속으로만 분석해서 전체 정황을 예측하기에는 너무나

복잡하다.”

• 4세대 언어4GL에 관하여, 보고서는 소프트웨어 분야에 존재하는 심각한 오

해를 지적하며 3GL과 4GL을 혼합한 접근 방식이 안전하다고 제안한다.

“4세대라는 용어는 올바르지 못하다. 현재 4세대 언어는 3세대 범용 언어

에서 파생하지 않은 언어를 통틀어 지칭한다. 데이터베이스 언어나 스프레

드시트와 같이 특정 응용 프로그램에 사용하는 언어, 프로그램 생성기, 비

절차적 언어, 심지어 프롤로그Prolog와 같은 인공지능 언어까지 포함한다.

각 언어는 특정 영역의 문제를 공략할 목적으로 설계되었다. 그러므로 4세

대 언어는 에이다Ada나 기타 범용 언어와 비교할 수 없다.”

에이다에 관하여, 보고서는 기대와 결과가 어긋남을 언급한다. 에이다가 우•

수한 언어일 가능성이 있으므로 “진지하고 단호하게 지원해야 한다”고 권고

하면서도, 소프트웨어 문제가 언어 하나로 해결될 사안이 아니라는 사실을

지적한다.

19

1부 _ 논쟁의 전장

에이다는 과도한 공약을 내걸었다. 다음과 같은 작업을 하려면 지원 도구

가 필요하다.

소프트웨어 문서 작성과 문서 형식 지정•

소프트웨어와 문서에 대한 버전과 구성 제어•

요구사항, • 설계 명세서, 코드 문서, 소스 코드, 컴파일한 코드, 프로그

램 보고서, 코드 변경, 테스트, 테스트 수행 결과 등에 대한 개발 이력

관리

• 디버깅

프로젝트 일정과 자원(인력/노력) 관리•

이 결과, 기술 담당이 아닌 프로그램　관리자로　하여금　고차원언어　하나

만으로는　어림없는　결과를　기대하게　만들었다.

점진적 구현에 관하여, 보고서는 소프트웨어 개발에서 부족한 점을 인정하•

는 능력을 ‘직업적 겸손’이라 칭한다. 전체 소프트웨어를 개발하는 과정에

서 최소 완성 버전을 만들어 초기에 출시하라고 제안한다.

“자신감 있게 명세서를 작성하고 힘들게 공룡을 만들었던 경험에 따르면,

복잡한 소프트웨어 시스템을 개발하는 가장 간단하고, 가장 안전하며, 가

장 신속하기조차 한 방법은 실제 용도를 바탕으로 우선순위를 정한 다음,

최소 버전을 제작하여 실제로 사용하고 기능을 추가하고 속력을 높이고 크

기를 줄여가는 방법이다. 하지만 점진적 개발은 통상적인……경쟁적 입찰

관례를 깬다. 이제는 조달 과정에서……창의력을 발굴해야 한다.”

기성품 소프트웨어에 관하여, 보고서는 소프트웨어를 제작하는 최선의 방•

법은 ‘아예 제작하지 않기’라고 말한다.

“소프트웨어를 가장 싸게 구하려면, 직접 제작하지 말고 시장에서 구매한

다. 소프트웨어를 가장 빨리 구하려면, 직접 제작하지 말고 시장에서 구매

한다. 소프트웨어를 가장 확실하게 구하려면, 직접 제작하지 말고 시장에

서 구매한다.”

Software Conflict 2.0

20

소프트웨어 평가 기준에 관하여, 보고서는 소프트웨어 제품의 품질을 측정•

할 기준이 절실히 필요하다고 지적하고 실행 가능한 해결책을 제시한다.

“소스 코드 품질, 목적 코드 품질, 문서 품질 등을 평가할 기준이 없다. 전

산 분야 밖에는 복잡한 성능의 품질을 전반적으로 평가하는 기술이 존재한

다. 올림픽 다이빙, 스케이트, 체조 경기의 심판처럼 오늘날에도 훈련받은

심판으로 이루어진 평가단이 소프트웨어 품질을 평가할 수 있겠다.”

추천 사항 몇 가지

보고서는 전체적으로 추천 사항 38개를 제시한다. 이 중 절반 이상이 조직적 변화

와 정치적 변화를 다루는 내용으로, 군대 환경과 밀접한 관련이 있다.

나머지 추천 사항은 일반 자료 처리 공동체가 관심을 가질 만한 주제 몇 가지로

분류할 수 있다. 추천 사항의 논제는 다음 사안이 중요하다는 믿음에 근거한다.

• 점진적 개발과 프로토타이핑

재사용•

에이다•

4GL•

위험 관리•

평가 기준•

각 주제별로 보고서는 다음 사항을 추천한다.

점진적 개발과 프로토타이핑

보고서는 점진적 시스템 개발 방법으로 프로토타이핑을 강력히 지지한다.

21

1부 _ 논쟁의 전장

추천 12: 시뮬레이션과 프로토타이핑 등 점진적 획득으로……위험을 줄인다.

추천 23: ……명세서의 반복 조정, 시스템의 신속 프로토타이핑, 점진적 개발

등을 의무화하라.

추천 24: ……‘폭포수’ 모델의 가정에 의존하는……모두 없애고,……신속 프로

토타이핑과 점진적 개발을 제도화하라.

추천 26: ……사용자와 협력하여 신속 프로토타이핑을 수행하는 능력을 갖추

어……제품을 개발하라.

재사용

보고서는 기존 소프트웨어 컴포넌트와 시스템을 재사용해야 한다는 입장 역시 강

력히 지지한다.

추천 29: ……미국방성 지원으로 개발했더라도……계약업체가 재사용 가능한

모듈로 수익을 얻도록 금전적 보상 제도를 개발하라.

추천 15: ……시스템 소프트웨어 요구사항이 고유하다고 판명이 나기 전까지

기성품 소프트웨어를 사용한다고 가정하도록 프로그램 관리자에게

지시하라.

추천 16: 방법론에 쏟아 붓는 모든 노력은……상용 소프트웨어 도구를 선정하

여 미국방성 필요에 맞게 표준화하는 방법에 쏟아라.

추천 30: ……계약업체가 자체적으로 새 모듈을 개발하기보다는 기존 모듈을

구매하도록 장려하고 금전적 보상 제도를 개발하라.

추천 31: ……프로그램에서 개발하지 않고 구매해도 좋은 하위 시스템, 컴포

넌트, 모듈을 찾아내고 이를 포상하도록 프로그램 관리자에게 지시

하라.

Software Conflict 2.0

22

에이다

예상하듯이 보고서는 군용 표준 언어로 에이다 사용을 강력히 지지한다. 하지만

여기에 몇 가지 경고를 덧붙인다.

추천 8: 계속해서 에이다 언어의 부분집합화를 금지하라.

추천 9: 기술층과 관리층을 대상으로 에이다 실습과 교육에 대한 투자를

늘려라.

추천 32: ……프로토타이핑 모듈 시장을 만들고……처음에는 에이다 모듈과

에이다를 위한 도구에 집중하라.

추천 33: ……에이다 모듈을 기술하는 표준을 정립하라.

4GL

보고서는 4세대 언어 지원에 미온적인 태도를 보인다. ‘생명주기 비용’을 강조하

는 부분은 4GL이 지니는 생산성/유지보수 장점과 효율성 단점을 모두 신중히 검

토해야 한다는 분명한 경고이다.

추천 10: 4GL 언어를 사용해서 얻는 전체 생명주기 비용의 효용이 범용 언어보

다 10배를 넘어서는 경우에만 4GL 언어를 사용한다.

위험 관리

보고서는 시종일관 새로운 관리 방식의 중요성을 강조한다. 그러나 여기서는 위

험에 초점을 맞추는 다음과 같은 관리 방식을 제안한다.

추천 25: ……소프트웨어 획득 과정에서 위험 관리 기술을 필수로 만들어라.

보고서는 예제로 위험 관리 계획을 제시한다.

프로젝트에서 최고 위험 10가지를 밝힌다.1.

각 2. 위험별로 대처 방안을 세운다.

23

1부 _ 논쟁의 전장

매달 최고 위험 목록, 대처 방안, 결과를 수정한다.3.

4. 월간 프로젝트 검토 회의에서 위험 상태를 점검한다.

적절한 조치를 취한다.5.

평가 기준

보고서는 소프트웨어 제품과 공정을 측정하는 기준, 특히 제품 품질을 측정하는

기준의 필요성을 강력히 주장한다.

추천 18: ……소프트웨어 품질을 포상하는 금전적 보상 제도를 마련하라.

추천 19: ……소프트웨어 품질과 완성도를 측정하는 기술과 평가하는 기준을

개발하라.

추천 20: ……구현 상태를 평가하는 기준을 개발하라.

결론

전체 추천항목에서 핵심만 가려보면 위원회가 보고서를 통해 강조하는 메시지가

확연히 드러난다. “새로운 기술 개발을 시도하거나 개발 중인 기술에서 적당히 초

점을 변경하기보다는, 소프트웨어 조달이라는 주제를 완전히 재검토하고 태도와

절차와 정책을 변경해야 한다.“

다시 말하면, 기술적 도약이 소프트웨어를 구제하지 못한다(이 문제에 관한 한, 다

른 어떤 방안도 소프트웨어를 구제하지 못한다). 이럴 경우 관리 방식을 바꾸어야 한다.

자료 처리 종사자들이 듣고 싶은 말은 아닐지 모르지만 들어야 할 말이다.

위원회는 메릴랜드 대학의 빅 바실리, TRW의 베리 보엠, 체이스 맨하탄의 일

레인 본드, IBM의 닐 이스트만, 타탄 연구소의 돈 에반스, 타탄 연구소의 아니타

존스, 카네기 멜론 대학의 메리 쇼, MITRE의 찰스 즈라켓, 여러 정부 대표자와 업

체 대표자 등 뛰어난 전산 전문가와 소프트웨어 전문가로 이루어졌다.

Software Conflict 2.0

24

이 장에서 나왔던 수필을 다시 읽으면서 가장 감동적이었던 점이라면, 내 생각에

묻어나는 통찰력은 전산 분야의 거장들 덕택이라는 사실이다.

예를 들어 이 장 수필 중 하나는 명실상부하게 소프트웨어 공학 분야에서 최고

전산학자인 데이비드 파나스의 생각을 담았다. 1980년대 파나스 교수는 세계가

정치적으로 양극화된 상황에서 논쟁이 격심했던 소위 말하는 스타워즈 미사일 시

스템이라는 기술 주제 한가운데 있었다. 본질적으로 스타워즈는 미사일 방어 체

제를 구축하여 미사일과 핵무기를 비롯해 미합중국을 공격하는 적국의 모든 공격

을 우주에서 파괴하겠다는 아이디어였다.

논쟁은 주로 가능성을 나타내는 “할 수 있는가”와 당위성을 나타내는 “해야 하

는가”를 놓고 벌어졌다. 파나스는 가능성을 나타내는 “할 수 있는가” 측면에서 단

호하게 부정적인 입장을 피력했다. 그러나 나는 그의 논지가 스타워즈의 실행 가

능성보다는 새로운 소프트웨어 공학 방식의 실행 가능성과 더욱 관련이 깊다고

여겼다.

이 수필을 처음 출판했던 당시의 생각은 그랬으며, 이 수필을 다시 출판하는 지

금도 같은 생각이다. 오늘날의 정치가들이 지난 스타워즈 논쟁을 되살렸으므로,

‘가능성’을 묻는 질문은 그때나 지금이나 여전히 중요하다.

이 장에서 언급하기에 파나스보다 더 적합한 인물은 없으며, 필적할 인물이라

•회고•

논쟁의 전장

25

1부 _ 논쟁의 전장

면 프레드 브룩스 정도이다. 그래서 이 절 셋째 수필은 브룩스를 인용한다. 파나

스가 소프트웨어 공학 분야에서 최고 전산학자라면16), 브룩스는 전산학 분야에서

최고 소프트웨어 공학 실무자이다.17)

브룩스의 ‘The Mythical Man Month’는 논쟁할 여지 없이 역사상 가장 중요한

소프트웨어 공학 ‘교훈’을 다루는 서적이며, 이 장에서 언급한 ‘No Silver Bullet’ 역

시 역사상 가장 통찰력 있는 소프트웨어 공학 논문이라 하겠다.

‘No Silver Bullet’이라는 수필에서 브룩스는 소프트웨어 공학 분야의 비약적인

발전은 극도로 일어나기 어려우며 앞으로도 극히 드물리라고 예측한다. 어떤 면

에서 브룩스의 수필과 파나스의 수필은 논지가 거의 같다. 즉 ‘가능성’에 대한 답

은 십중팔구 ‘아니다’라는 말이다. 그러니 최초로 과도하게 낙천적이던 업체와 학

계가 소프트웨어 생산성을 비약적으로 키웠다고 상상한 이후로 소프트웨어 공학

계가 오랫동안 주문처럼 외워오던 ‘비약적 발전’이라는 주장을 이제는 재고하지

않을 수 없다.

이 장에서 전하려는 메시지는 파나스와 브룩스 등 뛰어난 동료들이 설명했듯

이, 앞으로 우리 분야에서 비약적인 발전은 극히 일어나기 어렵다는 전망이다. 비

약적인 발전을 이뤄냈다고 주장하는 사람들은 오히려 이 분야에 도움이 안 된다.

이 장에서 에이다를 다루는 부분은 확실히 시대에 뒤떨어진다. 에이다는 미국

방성이 ‘바벨탑’ 프로그래밍 언어 문제18)를 해결해주리라 기대했던 프로그래밍 언

어이지만, 이 책 초판과 2판 사이에 인기를 잃고 자취를 감췄다.

에이다는 왜 사라졌을까?

가장 먼저, 미국방성은 새 언어를 선택하면서 이전 언어를 모두 폐기해야 한다

옮긴이 주_16: 파나스는 현장에서 실제 개발이 가능한 소프트웨어 공학 부문을 대학에서 연구한다

옮긴이 주_17: 브룩스는 대학에서 실제 연구가 가능한 소프트웨어 공학 부문을 현장에서 개발한다

옮긴이 주_18: 그 당시 미 국방성은 개발 비용과 시간을 절약하기 위해 스위스 육군 칼처럼 범용으로 사용이 가능한 강력한 프로그래밍 언어를 요구하고 있었다. 한마디로 육/해/공/해병대가 모두 공용으로 사용 가능한 비행기를 설계하듯이 프로그래밍 언어도 모든 부문에서 사용하도록 설계하려는 의도가 있었다. 하지만 육/해/공/해병대에서 모두 사용이 가능하도록 만들어진 F-35 Joint Striker Fighter 개발 성공과는 달리 에이다는 결코 그렇게 되지 못했다. F-35에 대한 정보는 http://en.wikipedia.org/wiki/F-35_Lightning_II를 참조하기 바란다.

Software Conflict 2.0

26

고 여겼고 그 결과 정치적 혼란이 생겼기 때문이다.

다음 이유로는, 미국방성이 에이다 사용을 의무화하지 못했기 때문이다. 미국방

성은 10~20년 전에 코볼 사용을 의무화했다. 그러지 않았더라면 코볼 역시 에이다

와 같은 운명을 맞았을 터이다. 실제로 미국방성이 코볼 사용을 의무화하지는 않았

다. 단지, 미국방성으로 납품하는 모든 컴퓨터는 코볼 컴파일러를 설치해야 했다.

결국 효과는 같았다.

또 다른 이유로는, 에이다의 주된 프로그램 영역인 실시간 시스템 부문에서 에

이다가 문제를 얼마나 잘 해결하는가를 둘러싸고 이견이 있었기 때문이다.

마지막으로, 미국방성이 “소 잡을 때 쓰는 칼을 닭 잡을 때 쓴다”고 실시간에

적합한 언어를 범용 언어로 사용해서 에이다를 구하려 했기 때문이다.19)(응용 분야

에 따른 접근 방식은 이 책 후반에서 다룬다).

옮긴이_19: 에이다는 처음부터 실시간과 임베디드 분야를 염두에 두고 설계된 언어이다. 따라서 실시간 도메인에서는 다른 언어보다 뛰어나지만, 문제 영역에 구애 받지 않고 중립적으로 사용하면 평균 언어보다 떨어질 위험을 내포하고 있다. 하지만 이런 위험을 무시하고 특정 도메인에서만 우수한 언어를 범용으로 사용하려는 바람에, 가치가 떨어지고 말았다.

27

1부 _ 논쟁의 전장

28

인지적 견해: 소프트웨어 설계를 보는 다른 시각•

소프트웨어 오류에 대한 단상•

소프트웨어 오류 제거에 대한 실험적 관점•

다양한 테스트 종류•

소프트웨어 품질과 소프트웨어 유지보수 사이의 관계•

소프트웨어 유지보수는 해결책이지 골칫거리가 아니다•

단일 지점 제어•

사용자 편의성 - 유행어인가, 도약인가?•

회고: 기술 진영에서

2부

기술 진영에서

인지적 견해: 소프트웨어 설계를 보는 다른 시각

이 수필에서 다루려는 질문은 “소프트웨어 설계란 무엇인가?”이다.

이상한 질문이라 여길지도 모르겠다. 어쨌거나 우리는 30여 년 넘게 소프트웨

어를 설계해오지 않았던가. 또한 상식적으로 필요하다 싶은 설계 방법론과 설계

언어는 모두 갖추고 있지 않은가? 그런데 이제와서 “소프트웨어 설계란 무엇인

가?”라고 묻는 이유는?

이 시점에서 내가 말하고 싶은 요지는 이제껏 우리가 설계의 피상적인 면만을

논해왔다는 점이다. 방법론은 설계가 아니며 설계를 조직화하는 기반 틀일 뿐이

다. 언어도 설계는 아니며 구상한 설계를 기록하는 표현 방법일 뿐이다. 설계는

머리 속, 두뇌 안에서 일어나는 무언가이며 이는 빛보다 빠른 속력으로 일어난다.

바로 이러한 설계 개념을 여기서 논하려 한다.

나는 오랫동안 소프트웨어를 설계해왔고 설계라는 과목을 가르친 적도 몇 번

있지만 여러분에게 고백할 말이 있다. 설계가 무엇인지 그리고 내가 취한 설계 방

식이 올바른지 진정으로 안다고 느낀 적이 없다.

최근에 들어서야 이것이 나 혼자만의 느낌이 아니라는 사실을 알게 되었다. 시

애틀 대학 대학원 과정에서 소프트웨어 공학을 가르쳤을 때 나를 포함한 몇몇 교

수는 설계 과목을 회피했다. 설계가 진짜로 무엇인지 모르니까 가르치는 방법도

모른다고 느꼈기 때문이다. 나중에 카네기 멜론 대학의 소프트웨어 공학 연구소

에서도 설계를 어떻게 가르칠지 모르겠다는, 아니 사실상 아무도 가르치는 방법

29

2부 _ 기술 진영에서

을 모른다고 느끼는 사람들을 만났다. 그때서야 혼자가 아님에 안도했지만, 여전

히 설계가 무엇인지 모르는 상태였다.

실증 연구 결과

이제 상황이 변할 참이다. 나처럼 설계가 막연한 주제라고 느낀 전산학자들이 설

계의 정체를 연구하고는 답을 내놓기 시작했다.

연구 결과를 이해하려면 먼저 짧은 소프트웨어 역사 속에서 전통이 되어버린

사고1)에 대한 집착을 버려야 한다. 설계의 외적인 표현에 연연하지 말고 사고의

흐름에 초점을 맞춰야 한다. 설계의 비밀은 마음속에 있다.

이 사실을 확연히 깨달았던 순간을 아직도 기억한다. 공군사관학교에서 에이다

언어 교육을 수강하던 중이었다. 주간 교육 마지막 날에 강사는 수강생들을 팀으

로 나누고 문제를 내주었다. 강사가 모두에게 요구사항을 설명하자마자, 내 급우

중 한 명인 보잉 사에서 온 똑똑하고 젊은 친구가 설계안을 내놓았다. 당시 나는

문제조차 이해하지 못해서 고심하는 중이었는데 그 친구는 즉석에서 설계안을 떠

올렸던 것이다! 그때 나는 깨달았다. 설계는 마음속에서 번개처럼 떠오르는 무언

가임을. 그리고 어떤 사람의 번개는 다른 사람의 번개보다 훨씬 빠르다는 사실을.

그렇다면 그 똑똑한 친구의 머리 속에는 실제로 무슨 일이 일어났을까? 이

질문, 적어도 이 질문 뒤에 숨어있는 일반적인 질문에 대한 답이 밝혀지기 시

작했다.

답을 말하기에 앞서, 답이 어떻게 나왔는지 잠시 설명하겠다. 소프트웨어 관련

연구 분야에서 새롭게 등장하는 움직임, 바로 이 새로운 움직임에서 답을 내놓기

시작했다. MCC Microelectronics and Computing Consortium의 빌 커티스와 미시건 대학

의 엘리엇 솔로웨이와 같은 연구진은 소프트웨어 연구에서 프로그램 연구만큼 프

옮긴이_1: 아직도 설계의 외적인 표현에 붙들려 실제 구현 과정에서는 사용하지도 않을 객체지향 다이어그램을 그리고 어마어마하게 복잡한 문서를 작성하고 있다.

Software Conflict 2.0

30

로그래머 연구도 중요하다는 생각에 오랫동안 흥미를 보여왔다. 그들은 이 연구

분야를 ‘프로그래머에 대한 실증 연구’라고 부르며, 이 연구 분야에서 최근에 관심

을 갖고 연구하는 주제가 바로 소프트웨어 설계이다.

이 수필 처음에 화두로 던졌던 “소프트웨어 설계란 무엇인가?”라는 질문을 놓

고, 이들 연구진은 답을 찾아내려는 계획을 세웠다. 설계자의 사고에 개입하지 않

고, 즉 사고 흐름을 방해하지 않고 설계를 수행하는 설계자의 사고 과정을 잡아내

야 했다. 물론 말처럼 그리 쉽지는 않다.

하지만 그들은 ‘프로토콜 분석’이라는 기법을 사용하여 결과를 얻어냈다. 작업

중인 설계자 옆에 조용히 앉아서 소리 내서 생각하라고 요청한 다음, 설계자들의

언행을 기록했다. 설계 작업은 녹음기에, 그룹 설계 작업은 비디오에 담았다. 기

록한 내용을 산더미처럼 모았다. 그런 다음, 설계자들이 하는 일을 이론적으로 체

계화하기 시작했다.

첫 번째로 그들이 밝혀낸 사실에는 그다지 새로운 내용이 없다. 그들은 설계가

다음 활동을 포함한다고 밝혔다.

문제 이해•

문제를 목표와 목적으로 나누기•

문제 해결을 위한 계획을 선택하고 세우기•

계획을 따르기•

제품과 절차를 숙고하기•

별로 도움이 안 되는 정보다. 사실 몇 마디만 바꾸면, 위 목록은 우리가 오랫동

안 알고 씨름해 온 소프트웨어 생명주기라는 개념과 별반 다르지 않다.

위 목록에서 ‘문제 해결을 위한 계획을 선택하고 세우기’라는 항목을 좀 더 깊

이 파고든 후에야 광맥이 드러났다. 아주 간단한 단계가 매우 평범한 항목 속에

숨어있는데, 바로 이것이 설계의 본질이었다.

31

2부 _ 기술 진영에서

설계의 본질

그럼 각 단계는 무엇일까?

설계자는 마음속으로 번개처럼 다음 작업을 수행한다.

마음속으로 모델을 만들어 본다.1.

마음속으로 모델을 실행한다. 즉, 시뮬레이션을 통해 모델이 문제를 해결2.

하는지 확인한다.

(대개 모델이 너무 단순해서) 문제를 해결하지 못하면, 불충분한 모델에서 3.

실패하는 부분을 찾아서 개선한다.

모델이 문제를 해결할 때까지 1 - 3 단계를 반복한다.4.

위 네 단계가 우리의 원래 질문에 답하는 열쇠이므로 좀 더 시간을 들여서 각각

을 살펴보자. 위에서 설명한 문제 해결 단계는 정신적이고, 아주 빠르고, 반복적

이며, 사실상 시행착오를 거듭하는 과정이다. 마음은 문제 해결책을 구상한다. 하

지만 아직 문제의 모든 측면을 완전히 파악하지 못했으므로 해결책이 불충분하리

라는 사실을 안다. 또한 문제 해결책이 모델 형태라는 사실도 마음은 안다. 모델

에 예제를 적용해서 (마음속에서) 재빨리 시뮬레이션을 돌려보고, (여전히 마음속에

서) 시뮬레이션으로부터 실험 결과를 얻어야 하기 때문이다.

그렇다면 설계의 본질은 신속한 모델링과 시뮬레이션이다. 그리고 설계의 핵심

요소는 해결책을 제안하고 실패를 허용하는 능력이다!

말이 난 김에, 같은 연구진이 설계에 미숙한 사람들도 연구했다는 흥미로운 사

실도 전한다. 이들은 모델이 아니라 설계의 표현에 치중했다. 시뮬레이션을 수행

하지도 못했으며 불충분한 설계안을 내놓고는 더 이상 진전하지 못했다. 이와 같

은 발견에서 내가 가장 선호하는 사고 방식 중 하나는 실패가 성공적인 설계의 핵

심 요소라는 생각이다! 직전 시뮬레이션의 끝에는 항상 실패한 모델, 즉 문제를

풀기에 불충분한 설계안이 있다. 따라서 성공하려면 실패하는 능력과 실패를 극

복하는 능력이 필수적이다. 설계를 가르치는 입장에서, 아니 굳이 설계가 아니더

Software Conflict 2.0

32

라도 이런 생각은 참으로 재미난 의미를 내포한다. 실패를 저지르고 이를 극복하

는 방법을 어디서 가르치겠는가?

몇몇 유명한 소프트웨어 설계자 역시 설계에 대하여 같은 생각을 피력했다.

수잔 래머가 인터뷰한 내용을 모아서 마이크로소프트 프레스가 펴냈던

‘Programmers at Work’2)를 읽어보면 그들은 자신이 보는 설계 과정을 다음과 같이

표현한다.

“프로그래밍에서 첫 번째 단계는 상상이다. 일어날 일을 마음속으로

명확히 구체화한다. 이와 같은 초기 단계에서 나는 연필과 종이를 사

용한다. 진짜 그림은 마음속에 있기 때문에……그저 끄적일 뿐이다.”

[찰스 시모니, 멀티플랜 제작자]

“어느 순간에 (설계가) 폭발적으로 떠올라서 머리 속에 모두 들어있

다……머리 속에 온갖 생각이 들어있어서 종이에 옮기지 못한다. 마

음속으로 계속 고치기 때문이다.” [개리 킬달, CP/M 제작자]

“프로그램이 어떻게 돌아갈지 마음속으로 시뮬레이션해야 한다……

무언가를 만들 때……그리고 마음속에 모델을 담고 있어야 한다. 이

건 꽤나 고독한 작업이다.” [빌 게이츠, 마이크로소프트 사 회장]

연구진이 발견한 결과가 유명한 설계자의 발언과 크게 일치한다는 사실이 참으

로 놀랍다.

기타 연구 결과

이 외에도 짚고 넘어갈 주요한 발견 하나가 있다. 프랑스 국립 자동화 정보 연구

센터National De Recherché en Informatique et en Automatique에 근무하는 윌레미엔 비저와

옮긴이_2: ‘컴퓨터 소프트웨어의 창시자들’이라는 제목으로 1994년에 국내에 출간되었다. 아쉽게도 현재 절판 상태이다

33

2부 _ 기술 진영에서

같은 연구진은 “설계자들이 무(無)에서 시작하는 경우는 거의 없다”라는 사실을 발

견했다. 즉, 시뮬레이션을 시작하는 첫 번째 개괄적인 모델은 앞서 유사한 문제에

사용했던 해결책에서 가져온다는 뜻이다. 돌아보면 에이다 수업에서 보잉 사에서

온 젊은 친구가 내 기를 죽였던 방법이 바로 그것이었다. 그는 유사한 문제 유형

을 이미 풀어보았고, 그래서 머리 속에 잠정적인 해결책이 들어있었던 것이다!(개

인적인 부족을 이렇듯 멋지게 합리화하다니 놀랍지 않은가?).

지금까지는 개인이 수행하는 설계를 언급했다. 하지만 모두 알다시피, 1980년

대에 이르러 설계는 팀 업무로 변화했다. 개별 설계자가 감당하기에는 문제가 너

무 커졌고, 게다가 다방면에 걸친 문제를 해결하려면 여러 설계자의 다양한 기술

이 필요하게 되었다.

앞서 언급한 연구진은 팀 설계도 살펴보았다. 그리고 많은 면에서 팀 설계는 개

별 설계의 공유 형태라는 사실을 발견했다.

팀은 서로가 공유하는 정신적 모델을 만든다.•

팀 구성원은 각자 혹은 다같이 공유 모델을 놓고 • 시뮬레이션을 수행한다.

팀은 시뮬레이션을 평가하고 다음 단계 모델을 준비한다.•

하지만 팀 설계와 개별 설계가 다른 면도 있었다.•

설계 과정에서 충돌이 불가피하다. 충돌은 회피하기보다 적절히 관리해야 •

한다.

설계 과정에서 의사소통 기술이 매우 중요해진다.•

아무도 책임지려는 사람이 없어서 사안이 ‘구렁이 담 넘어가듯’ 사라지기•

도 한다.

설계팀은 보통 3명에서 6명이다. 때로 아주 복잡한 프로젝트는 6명으로도 부족

하다. 이때는 설계가 조직적인 문제로 변한다. 전형적으로 설계팀이 조직적인 계

층으로 발전한다. 수석 아키텍트로 이루어진 특수 팀이 전체 설계를 조정하고, 각

설계팀은 특정 문제 영역을 맡는다.

Software Conflict 2.0

34

하지만 팀이든 계층적인 구조이든 (여럿이 참여하는 설계는) 태생적인 문제가 있

다. 설계가 위원회 업무로 변질되어서 온갖 단점을 드러내기도 한다(‘낙타는 위원회

가 설계한 경주마3)’임을 기억하는가). ‘The Mythical Man Month’와 최근 ‘Silver Bullet’

논문에서 프레드 브룩스는 현존 최고 제품, 즉 개념적 일관성이 있다고 우리 모두

가 인정하는 제품은 개인이 설계한 작품이라는 사실을 지적한다. 물론 에이다, 코

볼, IBM 메인프레임 운영체제 등 성공적인 팀 설계도 존재하지만 브룩스가 지적

하듯, 이들은 성공했으나 엉성하다는 비판을 받는다.

앞으로 나갈 방향

이제 새로운 사실을 알았다. 설계를 하는 동안 마음속에서는 잘 정의된 절차를 따

른다. 기존 모델이나 단순화된 새 모델에서 출발하여 모델로 시뮬레이션을 돌리

고 문제를 해결할 때까지 이 과정을 반복한다. 문제가 너무 크거나 복잡할 경우에

는 팀이나 심지어 조직이 설계를 수행한다. 팀과 조직은 개인이 사용하는 기술 대

부분을 사용하지만, 엉성하나 꼭 필요한 팀 절차도 사용한다.

그럼 새로운 사실을 알았으니 이제 어떻게 해야 할까?

나는 세 가지 범주를 제안한다. 설계 교육 면에서, 설계 수행 면에서, 설계 관리

면에서 이러한 발견이 의미하는 바를 고려해야 한다.

설계 교육 면에서, 단순히 방법론이나 표현법 몇 가지를 가르치는 일만으로 충

분하지 않다. 설계를 정신적인 과정으로 보는 새로운 개념을 토대로 한 기반 틀

안에서 방법론과 표현법을 가르쳐야 한다.

설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오

히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이라는 사실을

옮긴이_3: 모리스 자동차 모델을 설계한 알렉 이시고니스가 한 말이다. 낙타는 신체 구조 각 부분을 놓고 보면 생명력과 지구력이 최고이지만 전체적으로 보면 볼품없고 빠르지도 않다. 마찬가지로 위원회가 소속 위원의 의견을 하나 둘씩 받아들여서 반영하다보면 개별적으로는 말이 되지만 전체적으로는 현실에 맞지 않는 균형감각이 떨어진 희한한 표준이 등장함을 비유하고 있다. “사공이 많으면 배가 산으로 간다”라는 한국 속담과도 뜻이 통한다.

35

2부 _ 기술 진영에서

이해해야 한다. 그래야 설계자가 죄책감을 느끼지 않고 올바른 설계 방식을 추구할

수 있다(이를 ‘죄책감 없는’ 설계 방식이라고 불러도 될까? 아니, 너무 심리학적인 용어다).

설계 관리 면에서, 관리자는 의사소통 활성화와 문제 해결에 신경 써서 설계에

기여해야 한다. 한 걸음 더 나가서 실증주의 연구자들은 설계 관리를 통해 설계

과정에서 발생하는 핵심 문제를 관리해야 한다고 제안한다.

더 나은 설계 교육, 설계 수행, 설계 관리라는 목표를 추구하고자, 연구진은 여

러 도구 개념을 제안했다. 이런 도구들을 어떻게 만들지 아직 모르지만 가능만 하

다면 설계 절차에 대한 이해를 크게 높여줄 것이다.

정신적 절차를 지원하는 모델링/시뮬레이션 패키지1.

아이디어 누수를 막아주는 아이디어 보관/추출 패키지2.

핵심 요구사항을 추적하고 설계가 이를 위반할 때 경고하는 전략적 가정 3.

다듬기 도구

사안 기반의 충돌 해결 지원 도구4.

미해결 사안 기록/추적 도구5.

중립적인 토론 지원 도구6.

집단적 아이디어 수집과 조정 도구7.

하지만 설계 절차를 지원하는 도구를 논하기는 시기상조일지도 모르겠다. 지난

30여 년간 설계가 무엇인지 안다고 생각했다가, 이제 막 진정으로 이해하기 시작

했으니 말이다. 당분간은 이 사실만 납득해도 충분하겠다. 이러한 지식을 어떻게

활용할지는 나중에 걱정할 일이다.

이 새로운 발견에 붙일 이름이 필요하다. 연구자들은 이를 ‘인지적 설계 절차’

라고 부른다. 마음에 드는 표현이다. 설계가 정신적 절차라는 의미를 내포하기 때

문이다.

따라서 이 수필에서는 소프트웨어 설계의 인지적 측면을 다루었다.

Software Conflict 2.0

36

소프트웨어 오류에 대한 단상

이 글은 내가 소프트웨어 공학 업계와 학계에 몸담았던 지난 35년 동안에 꾸준히

쌓아온 개인적인 생각이다. 여기서 나는 소프트웨어 오류를 돋보기로 삼아서 소

프트웨어 공학 프로세스와 소프트웨어 공학 제품을 집중적으로 들여다보고 몇 가

지 생각을 전하고자 한다.

생각 1. 기존의 소프트웨어 오류 제거 기술로 찾지 못하는 오류가 존재한다.

이는 프로세스에 대한 생각이다. 기존에 알려진 소프트웨어 오류 제거 프

로세스는 (1)검토, (2)테스트, (3)증명으로 분류된다. 이런 프로세스의 중

요함을 우리는 충분히 알고 있다. 요구사항부터 코딩에 이르기까지 모든

단계에서 검토는 비용상 가장 효율적이다. 단위 테스트에서 시스템 테스

트에 이르기까지 모든 단계에서 테스트는 검토를 보완하기 위해 절대적으

로 필요하다. 증명은 아직 실무적인 오류 제거 기술로 입증받지 못했으나

다른 두 기술과는 판이한 대안이다.

하지만 이 생각에서 정말로 중요한 점은 어느 한 프로세스만으로는 충분

하지 않다는 사실이다. 생각을 조금 확장해보면 다음과 같이 결론지어도

타당하겠다…….

“현재 소프트웨어 오류 문제를 모두 해결하는 단일 프로세스는 존재하지

않는다.”

37

2부 _ 기술 진영에서

생각 2. 결코 찾지 못하는 소프트웨어 오류가 존재한다.

이는 제품에 관한 생각이다. 많은 사람들이 소프트웨어 제품은 인간이 만

든 가장 복잡한 창조물이라고 믿는다. 확실히, 프로그램에 담긴 논리 단위

의 개수를 본다면, 그리고 논리 단위의 조합으로 생기는 뒤얽힌 경로를 감

안한다면 프로그램을 실행하는 경로 수는 폭발적인 조합으로 거의 무한에

가깝다. 오류 없는 소프트웨어란 거의 불가능한 목표라는 사실이 그리 놀

랍지만은 않다.

소프트웨어에서 모든 오류를 제거할 수 없다는 생각은 중요하다. 그렇다

고 모든 오류를 제거하려는 노력을 게을리해도 좋다는 말이 아니다. 요지

는 그게 아니다. 중요한 점은……

“사람 목숨이나 돈이 걸린 시스템에서 사용하는 소프트웨어는 소프트웨어

오류에 대비하여 오류 제거와는 또 다른 준비를 해야 한다.”

사실, 바로 이것이 결함 허용 소프트웨어fault tolerant software라는 분야가 중

요한 이유이자 출현 이유이기도 하다. 결함 허용은 불가피한 오류에 대처

하는 대비책이다.

내 생각이 논쟁의 소지가 있다는 사실을 인정한다. 하란 밀스를 비롯한 몇

몇은 심리적으로 안정된 소프트웨어 엔지니어가 특정 프로세스를 정해진

방식에 따라 사용하면 오류 없는 소프트웨어를 만들 수 있다고 주장했다.

과거에 유사한 주장을 펼쳤던 사람들과는 달리, 그들은 성공할지도 모른

다. 하지만 1988년 현재의 업계 최신 수준과 학계 최신 수준을 감안하건

대, 사람 목숨이나 돈이 걸린 소프트웨어는 오류가 숨어있을 가능성을 무

시해서는 안 된다.

생각 3. 소프트웨어 오류 발견자가 모두 동급은 아니다.

이는 프로세스를 사용하여 제품을 제작하는 사람에 대한 생각이다. 소프

트웨어 개발자의 능력이 30배까지도 차이가 난다는 사실은 여러 차례 확

Software Conflict 2.0

38

인했다. 글렌포드 마이어는 한 소프트웨어 제품을 놓고 어떤 사람들은 다

른 사람들보다 7배나 많은 오류를 찾아낸다는 사실을 발견했다. 낸시 레

비슨의 연구에서는 오류가 60개인 소프트웨어 제품에서 24명 중 9명만이

오류를 하나라도 찾아냈다. “소프트웨어 엔지니어링 이코노믹스Software

Engineering Economics”에 실린 베리 보엠의 특집 기사는 소프트웨어 인력 수

준이 어떤 소프트웨어 프로세스보다도 소프트웨어 생산성에 커다란 영향

을 미친다는 사실을 극명하게 보여준다.

이 생각이 나타내는 바는……

“소프트웨어 오류 제거에서 가장 중요한 요소는 제품의 특성이나 프로세스

의 특성이 아니라 올바른 사람의 선택이다.”

불행하게도 이 생각은 사람을 선택하는 방법까지 말해주지 않는다. 우리

는 여전히 주관적이고 임기응변식 기술을 사용해서 최적인 사람을 선택해

야 한다.

생각 4. 모든 소프트웨어 오류가 동급이 아니다.

이는 앞서 언급한 모든 생각을 정리하는 생각이다. 우선, 모든 소프트웨

어 오류가 나쁘지만은 않다. 때로는 오류 제거로 얻는 이익이 오류 제거

에 드는 비용보다 적다. 게다가 우수한 소프트웨어 엔지니어의 작업 방식

을 연구한 엘리엇 솔로웨이와 같은 연구자는, 우수한 사람들이 ‘나쁜’ 사

람들보다 잘못 시작하는 경우가 많다는 사실을 발견했다. 즉, 좋은 소프

트웨어를 만들려면 적어도 생명주기 초반에는 시행착오를 거치면서 불가

피하게 ‘오류’가 생긴다는 뜻이다. 그러므로 모든 오류가 무조건 나쁘지만

은 않다.

더 중요한 사실이 있는데, 어떤 오류는 다른 오류보다 훨씬 더 나쁘다. 여

기에는 (1)모든 오류 제거 프로세스에도 불구하고 소프트웨어에 남아있는

오류, (2)그래서 시스템을 불안정하게 만들거나 값비싼 대가를 치르게 만

39

2부 _ 기술 진영에서

드는 오류가 포함된다. 나는 1981년 연구에서 이러한 고집불통 오류는 소

프트웨어의 복잡도가 소프트웨어로 해결하려는 문제에 미치지 못할 경우

에 생긴다고 밝혔었다. 예를 들어 소프트웨어가 IF 문에서 두 조건만 검사

하고 세 번째 조건을 무시하거나, 논리 분기에서 다음 문이 사용할 변수

값을 올바로 설정하지 못한 경우이다. 낸시 레비슨은 소프트웨어 오류를

시스템 안정성과 연관짓고, 더 나가서 독립적인 소프트웨어 개발자가 일

반적인 오류를 쉽게 저지르는 경향을 밝혔다. 팀 그램은 이를 ‘치우침 오

류biased errors’라고 부르며, ‘사고라는 덫’에서 생긴다고 말한다.

이 생각에서 중요한 사실은……

“오류 제거와 결함 허용은 모두 최악의 오류, 즉 시스템을 불안정하게 만드

는 오류에 집중해야 한다.”

생각 정리

소프트웨어 오류를 좀 더 상세히 살펴보면, 소프트웨어 자체에 대하여 중요하고

명확한 결론 몇 가지를 얻는다.

현재까지 소프트웨어 오류 문제를 해결해주는 단일 프로세스는 없다. 프로1.

세스가 부족하다는 말이 아니다. 우리에게는 다음이 있다.

검토, 테스트, 증명 프로세스a.

요구사항 테스트와 구조적 테스트b.

통계적 테스트와 안정성 테스트c.

단위 테스트, 통합 테스트, 시스템 테스트d.

수많은 도구와 기술e.

단순히 우리가 아는 어떤 프로세스보다 큰 문제f.

Software Conflict 2.0

40

2. 사람 목숨이나 돈이 걸린 시스템의 소프트웨어는 소프트웨어 오류에 대비

해서 오류 제거를 넘어선 주의를 기울어야 한다. 오류가 없도록 아무리 노

력하고 바란다고 해도, 제품은 여전히 오류가 있다는 가정하에 취급해야

한다.

3. 소프트웨어 오류 제거에서 가장 중요한 요소는 (사실상 모든 소프트웨어 제작

에서 가장 중요한 요소는) 업무에 투입할 인력 선택이다. 우수한 인력은 우수

한 해결책을 내놓는다. ‘나쁜’ 인력은 훨씬 나쁜 해결책을 내놓는다.

4. 오류 제거와 결함 허용은 모두 최악의 오류에 대비해야 한다. 어떤 오류는

저지르기 쉽다. 어떤 오류는 찾기 어렵다. 어떤 오류는 시스템을 불안정하

게 만든다. 대체로 저지르기 쉬우나 찾기 어려운 오류가 시스템을 불안정

하게 만든다.

아쉽게도 결론은 기대에 미치지 못한다. 소프트웨어 오류 제거와 결함 허용에

는 다음이 필요하다.

• 신중하게 선택한 인력

• 효율성이 검증된 프로세스

• 오류와 안정성의 본질 이해

이 정도 수준에 미치지 못하면 오류처리는 어림도 없다.

41

2부 _ 기술 진영에서

소프트웨어 오류 제거에 대한 실험적 관점

소프트웨어에서 오류를 제거하는 가장 효율적인 방법은 무엇일까?

소프트웨어에서 오류를 제거하는 가장 저렴한 방법은 무엇일까?

위 두 질문은 상당히 어렵다. 소프트웨어 개발에 드는 비용을 따져보면 일반적

으로 오류 제거를 소프트웨어 생명주기에서 가장 비싼 부분으로 간주한다. 오류

제거에 드는 비용은 시스템 분석과 설계와 구현에 드는 비용 각각에 비해 거의 2

배에 이른다.

이렇듯 소프트웨어 오류 제거는 어려운 질문이므로 현재 우리가 흔히 생각할

만한 답부터 살펴보려 한다. “사실 A, 사실 B, 사실 C를 알고 있으므로 소프트웨

어 오류를 제거하려면 전략 Z에 돈을 투자하는 편이 가장 낫다”라고 말할 수 있으

면 좋겠다. 하지만 현실은 그리 간단하지 않다.

어째서 간단하지 않을까? 글쎄다. 우선 한 가지 이유를 든다면 소프트웨어 개

발에서 다양한 요소의 효율성에 대한 의견은 많지만 이에 대한 실제적이고 유용

한 자료는 많지 않은 탓이다. 하지만 사실에 근거하지 않은 주관적인 견해가 넘

치는 현실보다 더 나쁜 상황은 소프트웨어 공학 업계에 옹호자가 넘쳐 나는 현실

이다.

이러한 의견과 옹호 덕택에 위와 같이 어려운 질문에 답해주는 정량적 정보가

없을 뿐만 아니라 전체적인 분위기가 감정적으로 흐른다. 옹호자들이 한쪽 입장

Software Conflict 2.0

42

만 너무나 우기는 나머지, 나머지 사람들은 그들 편으로 몰리거나 완전히 싫어하

는 두 가지 태도를 보인다. 의견과 옹호가 개입하면 객관성이 크게 떨어진다.

그런데 의견과 옹호를 타파하려면 객관적인 자료가 필요하다. 그렇지 않은가?

그러면 과연, 앞서 던진 어려운 질문에 답해 줄 자료가 있을까? 이 질문에 대한 압

도적인 답변은 ‘아니오’이다. 사실과 자료를 확보하려면 신중하고 통제된 실험을 수

행해야 하는데, 이런 실험을 수행하는 연구자가 거의 없다. 왜 아무도 안 할까? 이

질문에 답하려다 보면 상황은 더욱 진창으로 빠진다.

한 가지 이유를 찾아보면, 주의 깊게 통제된 실험에는 일반 연구보다 비용이 훨

씬 많이 소요된다. 사실상 돈이 너무나 많이 드는 탓에 소프트웨어 실무자들이 참

여하는 대규모 소프트웨어 제작 부분에서 소프트웨어 실험을 수행하는 사람이 거

의 없다. 정말로 연구가 필요한 부분임에도 불구하고 말이다. 심지어 정부 지원으

로 운영하는 SEI라든가, SPCSoftware Productivity Consortium나 MCC와 같은 업계 컨

소시엄처럼 실험을 수행하리라 여겨지는 곳조차도 예외는 아니다.

하지만 또 다른 이유는 전산학이나 소프트웨어 공학 세계에 흐르는 이상한 기

류 탓이다. 대다수 다른 과학 분야나 공학 분야의 실험적인 부문에서 느껴지는 분

위기는 눈 씻고 찾아봐도 없다. 소프트웨어 실험 연구에 가장 적격이고 적극적이

어야 할 연구자들 스스로가 그저 손을 놓고 있다.

테스트에 관한 실험이 있었다

지금까지는 내가 정말로 말하려는 바에 비해서 꽤나 우울한 서두였다. 이렇듯 우

울하고 암담한 실정에도 불구하고 조금은 진전이 있었다. 테스트에 대한 질문에

답하려는 시도로 꽤나 중요한 실험이 행해졌고, 결국 우리에게 ‘실험으로 얻은 답’

이 생겼다. 완전히 확정적인 답은 아니지만, 실무자와 관리자가 판단 근거로 삼아

도 좋을 만큼 일관성이 있다. 이 경우는 사실 A, B, C로 전략 Z를 선택하는 일이

가능해졌다.

43

2부 _ 기술 진영에서

이 수필을 읽어야 할 이유는, 여기까지 읽었다면 말이다, 실험 결과가 비교적

일관될 뿐만 아니라 실험 결과가 제시하는 소프트웨어 오류 제거 방향이 현재 우

리가 추구하는 방향과 다르다는 사실에 있다.

지금 우리가 추구하는 방향은 무엇일까? 소프트웨어를 열심히 테스트하고, 좀

더 테스트하고, 또다시 테스트한다.

실험이 제시하는 방향은 무엇일까? ‘대다수 오류 찾아내기’와/나 ‘개당 오류 발

견 비용 최소화하기’가 목표라면 테스트보다는 검토를 강조해야 한다고 제안한

다. 설계 검토, 코드 검토, 테스트 검토 등과 같은 검토 말이다. 잠시 후 보겠지만

검토는 테스트보다 더 빠르고, 더 경제적으로, 더 많은 오류를 찾아낸다.

하지만 잠깐 주목하기 바란다! 당장 뛰쳐나가서 개별 테스트 그룹을 몽땅 해고

하거나 테스트 장비 예산을 삭감해서는 안 된다. 이런 결과가 테스트를 중단하라

는 뜻은 결코 아니다. 테스트만으로 충분하지 않으니 검토로 테스트를 보완해야

한다는 말이다. 새 프로그램을 테스트하기 전에 설계와 코드를 검토하는 소프트

웨어 개발자가 별로 없었다는 내 개인적 경험을 감안하건대, 확실히 중요한 발견

이다.

이제 본론으로 들어가자. 이런 실험을 한 연구자는 누구이며 어떤 결론을 얻었

을까?

실험 결과

테스트 영역에서 실험을 수행한 연구팀 셋을 소개한다. 선발 연구팀이 출간한 연

구 결과를 후발 연구팀이 보았다는 사실을 제외하면, 각 팀은 거의 독립적으로 연

구를 진행했다. 소개할 사람들은 다음과 같다.

• IBM 시스템 연구소의 글렌포트 마이어. 그는 CACMCommunications of the

Association for Computing Machinery 1978년 9월호에 ‘A controlled Experiment

in Program Testing and Code Walkthroughs/Inspections’라는 논문으로 연

Software Conflict 2.0

44

구 결과를 발표했다.

• 메릴랜드 대학의 빅터 마실리와 캘리포니아 어바인 주립대학의 리처드 셀

비. 두 사람은 미항공우주국NASA/고다드 우주 비행 센터Goddard Space Flight

Center와 공동 작업을 수행하여 실험 결과를 ‘Comparing the Effectiveness

of Software Testing Strategies’라는 제목으로 IEEE Transactions on

Software Engineering 1987년 12월호에 발표했다.

• 아리조나 주립대학의 짐 콜로펠로와 브링햄 영 대학의 스콧 우드필드. 두

사람은 이름을 밝히지 않은 회사에서 실험을 수행하여 결과를 ‘Evaluating

the Effectiveness of Reliability Assurance Techniques’라는 제목으로

‘Journal of Systems and Software’ 1989년 3월호에 발표했다.

이상은 “테스트 영역에서 실험을 수행한 연구진이 누구인가?”라는 질문에 대한

답이다. 이제 두 번째 질문을 살펴보자. “그들이 얻은 결론은 무엇인가?”

이 질문에 답하려면 먼저 그들이 수행한 실험을 살펴보아야 한다. 각 연구진은

서로 조금씩 다른 각도에서 문제에 접근했다.

마이어와 마실리/셀비는 (모든 요구사항을 만족하는지 확인하는) ‘기능적 테스트’

를 (프로그램 전부를 테스트했는지 확인하는) ‘구조적 테스트’와 비교하고 코드 검토

와도 비교했다. 숙련된 실무자 다수로 구성된 실험 대상에게 상대적으로 작은 프

로그램 몇 개를 제공하고 오류를 찾게 했다.

콜로펠로/우드필드는 탐구 기반을 확장시킴과 동시에 그 범위를 축소했다. 그

들은 통제된 환경에서 실험을 수행하기보다는 대규모 실시간 소프트웨어 프로젝

트에서 얻은 자료를 사용했다. 그리고 설계 검토, 코드 검토, 일반적으로 테스트

라고 부르는 행위를 비교하고 분석했다.

세 연구팀은 유사한 답을 추구했지만 답을 측정하는 방식은 서로 조금씩 달랐

다. 예를 들어, 세 팀 모두는 ‘제거한 오류 개수’와 ‘제거에 든 비용’ 사이의 상관 관

계를 이해하려 했다. 콜로펠로/우드필드는 오류 개수와 비용을 측정하는 새 기준

을 고안해서 이를 오류 검출 효율error detection efficiency과 오류 검출 비용 효율error

45

2부 _ 기술 진영에서

detection cost effectiveness이라고 불렀다.

세 팀이 발견한 결과를 빨리 듣고 싶겠지만 먼저 한 가지만 더 짚고 넘어가겠

다. 안타깝게도 연구를 수행한 방식이 연구 결과에 상당한 영향을 미친다는 사실

이 밝혀졌다.

어떤 면에서 이들 실험은 서로 비교하기 힘든 성격을 보인다. 한 가지 예를 들

면 검토 과정에서 검토자들은 문제를 밝혀낼 뿐만 아니라 해결책도 제안한다. 반

면, (실험 결과를 보면) 테스트 과정에서 개별 테스터들은 오류가 존재한다는 사실

만을 찾아낼 뿐 오류 해결 방법은 제시하지 못한다. 따라서 실험에서 측정했듯이

검토자들은 테스터들보다 더 많은 작업을 수행한다.

또 다른 예로, 프로젝트 자료를 사용했던 콜로펠로/우드필드 연구를 살펴보면

실제 프로젝트에서는 검토를 거쳐 상당한 비중의 오류를 제거한 후에 테스트를

진행했다. 즉, 테스터들은 (1)다른 두 연구의 실험자들과는 다른 유형의 오류를 찾

고 있었고, (2)검토 후에도 남아 있는 오류는 초기에 발견한 오류보다 훨씬 찾기

어려웠다.

이러한 차이는 작게는 사소하지만 크게는 완전히 다른 연구 결과를 초래한다.

여기서 이를 언급하는 이유는 실험에 따르는 어려움을 보여주기 위해서이며 (좀

더 중요하게는) ‘전략’을 선택할 목적으로 ‘사실’을 활용할 때는 신중해야 한다는 점

을 강조하기 위해서이다.

이제 (짜잔!) 연구팀이 발견한 결과를 구체적으로 살펴보자. 먼저, 테스트와 검

토를 비교한 실험에서 바실리/셀비 팀은 코드 읽기가 기능적 테스트나 구조적 테

스트보다 훨씬 낫다는 강력한 증거를 확보했다. 콜로펠로/우드필드 팀은 설계 검

토와 코드 검토가 테스트보다 훨씬 낫다는 사실을 발견했다. 신기하게도 콜로펠

로/우드필드 팀의 실험은 개수 측면보다 비용 측면에서 훨씬 경제적임을 보여준

반면, 바실리/셀비 팀은 반대 결과를 보였다. 어쨌거나 두 연구팀은 ‘검토가 테스

트보다 낫다’는 유사한 결론에 도달했다.

여기서 마이어의 연구 결과는 다른 두 연구팀과 부분적으로만 일치한다. 마이

Software Conflict 2.0

46

어는 검토와 테스트가 동등하게 효과적이며, 비용 면에서 검토가 테스트보다 비

싸다고 결론 지었다.

그렇다면 검토 종류와 테스트 종류는 어떨까? 테스트 종류에 관한 연구 자료가

더 많다. 바실리/셀비 팀의 실험에서는 기능적 테스트가 구조적 테스트보다 오류

를 더 많이 발견하지만, 마이어의 실험에서는 두 테스트가 거의 동일한 결과를 보

여준다. 검토 종류에 관해서는 콜로펠로/우드필드 팀만이 실험을 수행했다. 그들

은 오류 제거에 드는 비용 측면에서 설계 검토가 코드 검토보다 훨씬 효율적이지

만, 제거하는 오류 개수 측면에서 코드 검토가 설계 검토보다 좀 더 효율적이라고

밝혔다.

이렇게 말을 늘어놓으니 정작 배우려는 내용이 무엇인지 혼란스럽다. 표 1은

세 연구팀이 발견한 결과를 요약한 내용이다. 일종의 다수결 원칙에 따라 세 팀이

밝혀낸 사실을 간단히 정리했다.

표1. 오류 제거 전략에 관한 연구 결과, 검토 대 테스트

연구팀 마이어 바셀/셀비 콜로펠로/우드필드

효율성 같음 1. 코드 읽기 1. 코드 읽기

2. 기능적 테스트 2. 설계 검토

3. 구조적 테스트 3. 테스트

비용 효율 코드 검토 코드 읽기 1. 설계 검토

(가장 비쌈) (가장 덜 비쌈) 2. 코드 검토

3. 테스트

(가장 비용 효율이 낮음)

오류 제거 측면에서 검토가 테스트보다 더 효율적이며, 비용 측면에서도 1.

마찬가지이다. 하지만 모든 자료가 이를 뒷받침하지는 않는다.

테스트 종류를 보면, 오류 개수 측면에서 기능적 테스트가 구조적 테스트2.

보다 나으며 비용 측면에서도 마찬가지이다.

검토 종류를 보면, 비용 측면에서 설계 검토가 코드 검토보다 훨씬 더 효율3.

적이지만 개수 측면에서는 코드 검토가 설계 검토보다 낫다.

47

2부 _ 기술 진영에서

그렇다면 오류 제거 전략을 수립하는 과정에서 이 모든 사실을 어떻게 활용해

야 할까?

다음을 제안한다.

반드시 검토를 수행하여 테스트를 보완한다.•

기능적 테스트를 강조하되 구조적 테스트도 수행해야 한다.•

설계 검토와 코드 검토를 모두 수행해야 한다.•

몇 가지 짚고 넘어갈 사항

여기서 몇 가지 짚고 넘어갈 사항이 있다. 예를 들어 연구진이 말하는 기능적 테

스트, 구조적 테스트, 코드 읽기, 검토는 정확히 무슨 뜻일까? 실험 결과를 정확히

이해하지 못한 상태에서 이를 토대로 전략을 세워나가는 행동은 위험하리라.

기능적 테스트는 프로그램의 요구사항 명세서를 기반으로 테스트 범위를 결정

한다. 마이어는 실험자들에게 명세서를 제공한 후 실험자들이 알아서 테스트

하도록 내버려 두었다. 바실리/셀비 팀은 실험자들에게 (유사한 테스트 케이스

그룹을 대표하는 테스트 케이스 하나를 사용하는) 등가 분할equivalence partitioning 4)

과 (알고리즘 또는 방법이 변해야 하는 지점을 테스트하는) 경계값 분석boundary value

analysis을 사용하여 테스트 케이스를 만들라고 요청했다.

구조적 테스트는 프로그램 내부적인 동작 방식에 맞게 테스트 케이스를 만든

다. 마이어는 실험자들에게 명세서와 프로그램 목록을 모두 제공한 후 실험자

들이 맘대로 테스트 케이스를 고안하도록 내버려 두었다. 바실리/셀비 팀은 실

험자들에게 소스 프로그램의 각 문장을 테스트하는 테스트 케이스가 적어도 하

나는 있어야 한다고 요청했다.

옮긴이_4: equivalence partitioning은 등가 분할, 동치 분할, 동등류 분할, 동치 분해 등 여러 표현을 사용한다.

Software Conflict 2.0

48

코드 검토는 (소프트웨어를 실행하지 않는) 정적 작업으로, 참여자들은 소스 코

드를 살펴 오류를 찾는다. 바실리/셀비 팀의 실험자들은 단계적 추상화stepwise

abstraction라는 방법을 사용했다. 이는 소프트웨어에서 핵심적인 하위 프로그램

을 찾아 기능을 파악한 후 이들 개별 기능으로부터 소프트웨어 전체 그림을 파

악하는 방법으로, 이렇게 유추한 기능을 명세서와 비교한다. 반면, 마이어의 실

험자들은 코드 검토 방법으로 워크스루walkthrough/인스펙션inspection을 사용했

다. 여기에는 개개인이 검토 회의 전에 코드를 읽고 마음속으로 소프트웨어 논

리를 따라 테스트 케이스를 실행하는 단계도 포함된다.

콜로펠로/우드필드는 테스트와 검토에 사용한 방법을 구체적으로 밝히지 않지

만, (개발자 400여명이 현대적인 고차원 언어를 사용하여 700,000 행짜리 실시간 코드를

개발했으며 생명주기 각 단계마다 품질 보증 작업이 있었다는 설명을 감안하건대) 대상

프로젝트는 미국방성의 검토/테스트 표준 혹은 유사한 표준을 따르는 군대 프로

젝트였을 가능성이 크다.

기타 놀라운 연구 결과

오래된 실험 결과를 뒤적이기 좋아하는 사람들을 위해서, 앞서 언급하지 않았던

흥미로운 실험 결과 몇 가지를 소개한다.

바실리/셀비 팀은 다음과 같은 재미난 사실을 밝혀냈다.

“발견한 오류 개수, 오류 발견율, 오류 발견에 드는 총 비용은 테스트하는 1.

소프트웨어 유형에 따라 달라진다.” 즉, 응용 프로그램에 따라 테스트 방식

을 달리해야 할지도 모른다는 말이다.

“코드 읽기가 인터페이스 오류를 가장 많이 찾아냈다.” “기능적 테스트가 2.

제어 오류를 가장 많이 찾아냈다.” 즉, 찾으려는 오류 종류에 따라 테스트

방식을 달리해야 할지도 모른다는 말이다.

49

2부 _ 기술 진영에서

“찾아낸 오류 비율을 예측해 달라고 요청했을 때, 코드 검토자들이 가장 정3.

확한 예측값을 내놓은 반면 기능적 테스터들이 가장 부정확한 예측값을 내

놓았다.” 즉, 코드를 뒤적이는 편이 전체적인 그림을 파악하기에 더 적합한

듯 하다.

마이어 역시 다음과 같은 재미난 사실을 발견했다.

“개인에 따라 결과가 엄청나게 차이가 난다.” 즉, 테스트를 누가 수행하느1.

냐가 어떻게 하느냐보다 훨씬 중요하다.

“전체적인 결과는 다소 실망스럽다.” 즉, 어느 오류 제거 방식도, 심지어 2.

여러 방식을 조합한 방식조차 모든 오류를 제거하기에는 역부족이었다.

“워크스루3. walkthrough/인스펙션inspection의 수행 시간과 성과 사이에는 부정

적인 상관 관계가 있다.” 즉, 코드 검토자는 시간이 흐르면서 지겨워한다.

콜로펠로/우드필드 역시 다음 정보를 추가로 밝혀냈다.

“불행하게도, 자료 대부분은 신뢰성과 일관성이 부족했다……자료 수가 작1.

은 이유는 개발자들이 기록에 무심한 탓으로 보인다……품질 보증 자료의

질은 아무도 확인하지 않았다.” 즉, 실제 프로젝트 자료를 사용한다 해도

연구 분석 시 오류가 발생할 가능성이 크다.

“설계 검토로 얻는 성과는 놀랍다.” 즉, 설계 검토는 많은 오류를 적은 비2.

용으로 찾아낼 수 있다.

“흥미롭게도, 테스트라는 안정성 보증 기술은 비용면에서 효율적이지 못하3.

다.” 즉, 테스트가 필요하기는 하지만 매우 비싼 작업이라는 뜻이다.

사실상 이 수필의 결론은 콜로펠로/우드필드 논문이 내린 결론과 같다. “테스

트는 반드시 수행해야 한다. 그러나 검토보다 테스트를 강조하는 전통적인 방식

이 비용면에서 전혀 효율적이지 못하다는 사실을 기업들은 이해해야 한다.” 즉,

이 수필 처음에 던졌던 두 질문에 대한 답이 나온다.

Software Conflict 2.0

50

소프트웨어에서 오류를 제거하는 가장 효율적인 방법은 무엇일까? •

소프트웨어에서 오류를 제거하는 가장 싼 방법은 무엇일까? •

놀랍지 않은가. 이제까지 답을 잘못 알았다는 뜻이 아니다. 새로운 답이 나왔으

므로 이제껏 해온 방식을 돌아봐야 한다는 뜻이다.

게다가 이는 실험 기법을 전산이라는 과학과 소프트웨어 공학이라는 공학에 마

침내 적용하기 시작한 사람들이 내놓은 답변이다.

51

2부 _ 기술 진영에서

다양한 테스트 종류

소프트웨어 개발에서 테스트는 아직도 절대적으로 중요한 위치에 있으며 앞으로

도 변함 없으리라는 증거가 있다. 최근 연구에 의하면 검토가 비용 면에서 훨씬

효율적이고, (문제가 커질 경우) 정확성 증명이 훨씬 확실하겠지만, 어느 방법도 소

프트웨어를 현실과 흡사한 환경에서 테스트하지는 못한다고 한다.

미래에도 테스트가 존재하리라는 사실을 확실히 깨달았으니, 테스트의 진정한

의미란 무엇인지 탐구할 가치가 있다. 테스트에는 다양한 종류가 있으나 흔히 우

리가 테스트를 언급할 때는 이 중 극소수만을 고려한다.

다음은 내가 생각하는 테스트 종류이다.

먼저, 1. 목표 주도 테스트이다. 목표 주도 테스트에서는 테스트 목적에 따라

테스트 수행 방식이 달라진다. 테스트 목적에는 크게 네 가지가 있다.

a. 요구사항 주도 테스트: 제품의 요구사항 전부를 적어도 한 번 이상은

테스트하도록 테스트 케이스를 작성한다. 일반적으로 요구사항마다

테스트 케이스가 적어도 하나는 존재하도록 테스트 케이스 행렬을 만

든다. 이러한 작업을 지원하는 도구도 존재한다. 100% 요구사항 주도

테스트는 모든 소프트웨어 제품에서 필수적으로 수행해야 한다.

b. 구조 주도 테스트: 소프트웨어의 논리적 구조를 합리적인 수준 이상

으로 테스트하도록 테스트 케이스를 만든다. 구조 주도 테스트는 요

Software Conflict 2.0

52

구사항 주도 테스트를 (결코 대체해서는 안 되며) 보완해야 한다. 요구사

항 테스트는 빈틈이 많아서 테스트가 충분하다고 보기 어려운 탓이다.

‘우수한’ 테스트는 프로그램의 논리 구조를 대략 60~70% 정도 테스트

하며, 사람 목숨이나 돈이 걸려있는 소프트웨어라면 95%까지 테스트

해야 한다. 테스트 정도는 테스트 커버리지 분석기Test Coverage Analyzer

라는 도구로 측정할 수 있다. 이러한 도구는 시중에서 바로 구입이 가

능하다.

c. 통계 주도 테스트: 고객이나 사용자가 충분하다고 확신할 만큼 테스트

를 수행한다. 테스트 케이스는 일반적인 사용법 프로파일을 기반으로

작성하며, “정상적인 환경에서 성공률이 96%이다”라는 식으로 단언할

정도로 테스트를 수행한다. 통계 주도 테스트는 요구사항 주도 테스트

와 구조 주도 테스트를 (대체하기보다는) 보완해야 하며, 고객이나 사용

자가 그들이 이해하는 용어로 “소프트웨어가 안정적이어서 사용해도

좋다”는 확신을 원할 경우에 수행한다.

d. 위험 주도 테스트: 소프트웨어가 최악의 실패 시나리오를 모두 통과하

는지 확인하는 테스트이다. 먼저 큰 위험을 분석한다. 이때 소프트웨

어에서 위험을 높이는 지점이 어느 부분인지 파악하고, 그런 다음 해

당 상황을 철저히 테스트한다. 흔히 위험 주도 테스트는 사람 목숨이

나 돈이 걸려있는 소프트웨어에만 사용한다. 다시 한 번 강조하지만,

위험 주도 테스트는 요구사항 주도 테스트와 구조 주도 테스트를 보완

하되 대체하지는 못한다.

2. 목표 주도 테스트 외에도 단계 주도 테스트가 있다. 단계 주도 테스트에서

는 소프트웨어 개발을 진행함에 따라 테스트 본질이 달라진다. 일반적으로

소프트웨어는 전체 시스템 형태만이 아니라 작은 구성요소 형태로도 테스

트해야 한다. 소위 상향식 테스트라는 방법에서는 세 종류의 단계-테스트

가 있는데, 자세한 내용은 잠시 후 설명한다. 하향식 테스트에서는 소프트

웨어란 성숙한 통합체로 점진적으로 통합되는 형식을 따르므로 빈번한 단

53

2부 _ 기술 진영에서

위 테스트는 건너 뛰고 통합 테스트를 확대시켜 나간다.5)

a. 단위 테스트는 시스템에서 가장 작은 구성요소를 테스트하는 절차이

며, 해당 구성요소를 전체 시스템으로 통합하기 전에 이루어진다.

b. 통합 테스트는 결합한 구성요소를 테스트하는 절차이며, 소프웨어가

전반적으로 돌아가는지 확인한다.

c. 시스템 테스트는 통합한 소프트웨어를 테스트하는 절차이며, 전체 시

스템 문맥에서 테스트를 수행한다.

목표 주도 테스트와 단계 주도 테스트의 접점을 찾다 보면 테스터의 지식과 상

식에 부담이 가중되기 시작한다.

예를 들어 단위 테스트, 통합 테스트, 시스템 테스트를 수행하면서 구조 주도

테스트도 수행하는가? 여기서 제시하려는 생각은 다양한 테스트 종류를 병합하는

방법이다. 목표 주도 테스트를 단계 주도 테스트로 편입하는 방식을 고려해보자.

요구사항 주도 테스트는 단계별로 의미가 달라진다. 단위 테스트에서는 테스

트 중인 구성요소의 요구사항을 테스트한다는 뜻이다. 통합 테스트에서는 요구

사항 명세서에 담긴 소프트웨어 요구사항을 모두 테스트한다는 뜻이다. 시스템

테스트에서는 새로운 환경에서 통합 테스트를 반복한다는 뜻이다.

구조 주도 테스트 또한 단계별로 의미가 달라진다. 단위 테스트에서는 소프트

웨어의 최하위 구조, 즉 논리적 분기를 모두 테스트한다는 뜻이다(여기서 이유는

설명하지 않겠지만, 모든 분기 테스트가 모든 구문 테스트보다 더욱 엄격한 테스트 방

법이다). 통합 테스트에서는 모든 단위를 테스트한다는 뜻이다. 시스템 테스트

에서는 시스템의 모든 구성요소를 구성요소가 한 두개 뿐인 통합된 소프트웨어

로 테스트한다는 뜻이다.

옮긴이_5: 하향식 구현 방법을 보면 전체 틀을 잡은 다음에 세부 내역을 구현하는 방법을 사용하므로 통합 테스트 기법을 사용해서 전체 구조를 제대로 유지하고 있는지 확인하는 편이 자연스럽다. 반대로 상향식 구현 방법일 경우에는 개별 컴포넌트를 먼저 구현한 다음에 이를 결합해 가면서 전체 큰 틀을 만들어 나가므로 개별 컴포넌트에 대한 단위 테스트가 중요해진다.

Software Conflict 2.0

54

통계 주도 테스트는 통합 테스트나 시스템 테스트 단계에서만 의미가 있다. 어

느 쪽을 선택할지는 응용 프로그램에 따라 다르지만, 대체로 시스템 테스트가

고객이나 사용자에게 좀 더 의미가 있다.

위험 주도 테스트는 시스템 중요도에 따라 어느 단계에서나 수행해도 좋지만,

대체로 시스템 테스트 단계에서 가장 의미가 있다.

테스트에서 “누가 테스트를 수행하느냐?”라는 고려할 사항이 한 가지 더 있다.

일반적으로 단위 테스트는 소프트웨어 개발자가, 통합 테스트는 개발자와 독립적

인 테스터가, 시스템 테스트는 독립적인 테스터와 시스템 엔지니어가 수행한다.

참고로, 요구사항 주도 테스트와 통계 주도 테스트는 테스트 중인 소프트웨어의

내부 동작을 거의 이해하지 못해도 무방하지만, 구조 주도 테스트와 위험 주도 테

스트는 소프트웨어를 아주 잘 알아야 한다. 따라서 개발자가 테스트에 관여해야

한다.

테스트가 부정확하고 사라질 개념이라고 떠드는 사람들이 일부 있다. 내가 보

는 관점은 전혀 반대이다. 올바로만 수행한다면, 정확하고 철저한 테스트가 가능

하다. 방법을 제대로 이해하고 실천하기 나름이다. 이 짧은 논의를 통해 테스트

개념을 바로 잡았으면 좋겠다.

55

2부 _ 기술 진영에서

소프트웨어 품질과 소프트웨어 유지보수

사이의 관계

소프트웨어 품질이란 무엇일까? 가장 일반적인 답변은 속성 집합으로 정의하는

방식이다. 소프트웨어 품질이 우수하려면 다음 속성을 지녀야 한다.

신뢰성• reliability

효율성• efficiency

인간 공학• human engineering

이해 용이성• understandability

수정 용이성• modifiability

테스트 용이성• testability

이식성• portability

소프트웨어 유지보수란 무엇일까? 사용자가 만족하도록 소프트웨어 기능을 유

지하는 작업이다.

흥미롭게도 품질 속성 일곱 가지 중 거의 대부분이 유지보수의 핵심 개념과

직·간접적으로 관련된다. 사실상, 일곱 가지 중 두 가지는 유지보수 자체를 가리

키며 나머지도 유지보수 개념에서 매우 중요한 속성이다. 다시 말해서 제대로 관

Software Conflict 2.0

56

찰해보면 소프트웨어 품질 향상은 소프트웨어 유지보수성 향상과 거의 동일하다.

소프트웨어 품질을 바라보는 이런 식의 관점은 상당히 특이하다. 흔히 우리는

품질이란 소프트웨어 개발자가 창조하고 품질 보증팀이 감독하는 활동이라 믿고

있다. 소프트웨어를 만든다고? 그럼 당연히 품질이 좋아야지.

하지만 이러한 관점은 근시안적이다. 품질에서 유지보수성 측면이야말로 가장

달성하기 어려운 탓에, 품질을 ‘자동적인’ 무언가로 간주하다 보면 유지보수성 측

면을 쉽사리 망각하기 때문이다.

이제 핵심 표현인 ‘~성’을 고려해서, 근시안적인 관점을 확장하여 유지보수성

측면까지 포함시켜보자. 유지보수성 관점에서 처음 눈에 들어오는 ‘~성’ 두 가지

는 다음과 같다.

• 이해 용이성 - 소프트웨어 원시 코드를 읽는 사람이 기능을 이해하기 쉬운

정도

• 수정 용이성 - 소프트웨어 원시 코드를 읽는 사람이 코드를 변경하기 쉬운

정도

위 두 속성은 전적으로 유지보수에 관한 내용이다. 유지보수 관련자 외에는 소

프트웨어를 수정해야 할 사람이 거의 없고 소프트웨어를 이해해야 할 사람도 거

의 없다(그리고 확실히, 이 둘은 평가하기 가장 어려운 품질 속성이기도 하다). 그렇다면

다른 속성은 어떨까? 유지보수와의 관련 정도에 따라 열거하자면 다음과 같다.

• 신뢰성 - 소프트웨어가 실패하지 않고 제 기능을 수행하는 능력. 유지보수

의 핵심 요소이다! 소프트웨어가 안정적이지 않으면, 유지보수

담당자가 문제를 해결해야 한다.

• 효율성 - 소프트웨어가 시간과 공간 자원을 최소로 사용해서 동작하는 능

력. 마찬가지로, 개발 활동만큼이나 유지보수와 관련이 깊다. 소

프트웨어가 너무 느리거나 너무 많은 메모리를 소모한다면, 유지

보수 담당자가 손을 봐야 한다.

57

2부 _ 기술 진영에서

• 테스트 용이성 - 소프트웨어를 쉽게 테스트하는 능력. 일반적으로는 테스

트를 개발 활동으로 간주하지만, 유지보수 담당자의 업무

중 상당 부분이 (각 변경 사항을 테스트하는) 제품 변경 테스

트와 (변경되지 않은 부분을 테스트하는) 회귀 테스트이다.

• 인간 공학 - 소프트웨어를 쉽게 사용하는 능력. 소프트웨어를 사용하기 어

렵다면, 누가 고생할까? 바로 유지보수 담당자이다.

• 이식성 - 다른 컴퓨터나 운영체제 등 다른 환경에서 소프트웨어를 유용하

게 만드는 능력. 마찬가지로, 소프트웨어를 이식하는 작업은 유

지보수 담당자 몫이 될 가능성이 크다.

품질 속성 중 두 가지가 유지보수와 밀접하게 관련되어 있을 뿐만 아니라, 나머

지 속성도 확실히 연관성이 있다. 그렇다면 소프트웨어 품질 역시 유지보수와 밀

접하게 관련이 있다는 말이다.

사실, 자료 처리 종사자들이 사용하는 다른 ‘~성’ 소프트웨어 품질도 있다. 이

들은 서비스 속성으로, 개발자보다는 사용자의 주요 관심사와 관련이 있다. 적시

성, 정확성, 신뢰성, 비용 등이 여기에 속한다. 하지만 이와 같은 ‘~성’을 지속적으

로 달성하는 책임은 전적으로 유지보수 담당자에게 달려 있다.

이 논의에서 요지는 무엇일까? 우리는 전산을 정의할 때 유지관리를 나중에야

고려하는 경우가 많다. 전산학이나 소프트웨어 공학 분야는 유지보수에 대해 거

의 언급하지 않는다. 최근까지는 도구와 기술조차 없었으며, 심지어 오늘날에도

학계에서는 유지보수에 거의 신경을 쓰지 않는다. 언젠가 사람들이 소프트웨어

분야의 핵심인 유지보수성이 얼마나 중요한지 이해한다면, 그때서야 유지보수가

제대로 된 대접을 받을지도 모른다.

소프트웨어 품질 보증팀을 구성하는 핵심 인력은 궁극적으로 해당 제품의 유지

보수를 담당하게 될 당사자여야 한다고 베리 보엠은 제안했다. 올바른 방향으로

나가는 첫 걸음이 바로 여기에 있다. 베리 보엠의 제안은 문제를 해결할 뿐만이

Software Conflict 2.0

58

아니라, 현재 사람들이 거의 관련시키지 않는 소프트웨어 품질과 소프트웨어 유

지보수라는 두 주제를 명확하게 연관짓는다.

59

2부 _ 기술 진영에서

소프트웨어 유지보수는 해결책이지 골칫거리가 아니다

소프트웨어 유지보수가 골칫거리인가?

오늘날의 전형적인 답변은 “물론이죠.”이다.

이 전형적인 답변에 대한 전형적인 근거는 이러하다. “우리 회사가 소프트웨어

유지보수에 쏟아 붓는 예산을 보십시오. 처음부터 소프트웨어를 잘 만들었다면,

유지보수에 엄청난 돈을 낭비하지 않아도 될텐데.”

글쎄다. 나는 이러한 전형적인 답변이 틀렸다는 입장이다. 내가 보기에는 전형

적인 근거가 틀렸기 때문이다.

사실, 소프트웨어 유지보수는 골칫거리가 아니라 해결책이다!

소프트웨어를 골칫거리로 바라보는 전통적인 관점에서는 특별한 의미의 두 정

보를 간과한다.

다른 ‘딱딱한’ 분야에 비해서 소프트웨어 제품은 ‘부드럽다’. 즉, 쉽게 변1.

한다.

소프트웨어 유지보수는 오류 수정(17%)보다는 개선(60%) 작업 비중이 더 2.

크다.

다시 말하면, 소프트웨어 유지보수는 골칫거리가 아닌 해결책이다. 소프트웨

어 유지보수는 어느 누구도 대신 해주지 못하는 우리만 할 수 있는 작업이며, 단

Software Conflict 2.0

60

지 오래된 문제 위에다 덧칠하는 작업이 아니라 새로운 해결책을 제시하는 작업

이기 때문이다. 만약 소프트웨어 유지보수를 골칫거리가 아니라 해결책으로 본다

면, 더 나은 유지보수에 대한 새로운 통찰력을 얻을 수 있지 않을까?

나는 정말 그렇다고 주장한다.

유지보수를 골칫거리로 바라보는 전통적인 시각에서는 유지보수의 주요 목표

가 비용 감소라고 말한다. 이 역시 나는 잘못된 논지라고 생각한다. 유지보수를

골칫거리가 아니라 해결책이라는 관점에서 보면, 우리가 진정으로 바라는 바는

더 많은 유지보수이지 더 적은 유지보수가 아니라는 사실이 금방 드러난다. 그러

므로 유지보수는 최소 비용이 아니라 최대 효율에 중점을 두어야 한다.

이제 새로운 생각을 펼칠 수 있는 지평이 열렸다. 비용 감소에서 효율 증대로

눈을 돌렸으니, 이 새로운 식견을 어떻게 활용할까?

효율을 극대화시키는 최선책은 최고 인력의 활용이다. 이 결론을 지지하는 자

료는 많다. 자료 대부분은 ‘개인적 차이’를 논하는 문서에서 찾을 수 있다. 예를 들

면 어떤 사람들은 소프트웨어 업무에서 다른 사람들보다 현저한 우위를 보인다.

디버깅: 어떤 사람들은 다른 사람들보다 28배나 우수하다.1.

오류 발견: 어떤 사람들은 다른 사람들보다 7배나 우수하다.2.

생산성: 어떤 사람들은 다른 사람들보다 5배나 우수하다.3.

효율성: 어떤 사람들은 다른 사람들보다 11배나 우수하다.4.

개인적 차이를 간략히 묘사한 위 목록의 결론은, 사람들 사이에 엄청난 차이가

존재하며 최고 결과를 얻는 최선의 방법은 최고 인력 투입이라는 점이다.

여기서 다음 두 가지 의문이 생긴다.

유지보수 문제에 최고 인력을 투입하는 정책이 타당한가?1.

현재 유지보수에 최고 인력을 투입하고 있는가?2.

첫 번째 질문이 두 번째 질문보다 대답하기 어렵다. 첫 번째 질문에 대한 내 대

61

2부 _ 기술 진영에서

답은 “그렇다. 유지보수는 소프트웨어 비즈니스에서 가장 어려운 업무 중 하나다”

이다. 내가 이렇게 생각하는 이유를 설명하겠다.

수년 전, 소프트웨어 유지보수에 관한 책을 공동으로 집필했었다. 검토 과정에

서 익명의 검토자가 유지보수에 대하여 다음과 같은 생각을 피력했었는데, 나는

오늘날까지도 이를 기억한다.

유지보수란,

지적으로 복잡하다. (유지보수 담당자에게 극심한 제약이 가해지는 가운데•

에서도 창조력 발휘가 필요한 작업이다).

기술적으로 어렵다. (유지보수 담당자는 개념, 설계, 코드를 동시에 다룰 •

줄 알아야 한다).

불공평하다. (유지보수 담당자는 항상 무언가 부족하다. 예를 들어 우수한 •

유지보수 문서가 없다).

성공이 없다. (유지보수 담당자는 항상 문제가 있는 사람들을 만난다).•

지저분하다. (유지보수 담당자는 세세한 구현까지 지저분한 수준에서 일해•

야 한다).

과거에 산다. (분명 코드는 누군가 구현에 능숙해지기 전에 작성했다).•

보수적이다. (“긁어 부스럼 만들지 말자”라는 좌우명을 따른다).•

내 결론과 이 검토자의 결론은 같다. 즉, 소프트웨어 유지보수란 매우 복잡하고

어려운 업무이다.

이제 ‘현재 누가 소프트웨어 유지보수를 수행하는가’라는 질문으로 돌아가자.

대다수 전산 업계에서는 신참이나 개발에 능숙하지 않은 사람이 유지보수를 맡

는다. 이유가 있다. 대다수 사람들이 유지보수보다 개발을 선호하기 때문이다.

유지보수는 창의력을 너무나 제한하므로 즐기기 어려운 탓이다. 그러다 보니 자

연적으로 가장 능력이 떨어지고 가장 수요가 낮은 인력이 대개 유지보수를 담당

하게 된다.

Software Conflict 2.0

62

내 추론을 여기까지 따라왔다면, 현 실정이 올바르지 못하다는 사실을 납득하

리라. 유지보수는 골칫거리가 아니라, 상당한 지적 도전이자 해결책이다. 유지보

수의 효율을 최대한 높이려면, 유지보수에 인력을 투입하는 방식이 크게 변해야

한다.

해결 방안을 구체적으로 제안하겠다. ‘뜬 구름 잡기’와 같은 이론적 해결책이

아니다. 관리층이 추진하겠다고 맘만 먹는다면 달성이 가능한 방법이다.

유지보수를 매력적으로 만들어라. 유지보수 업무로 사람들을 끌어올 방법1.

을 찾아라. 어떤 회사는 유지보수 담당자에게 상여금을 지불한다. 어떤 회

사는 상부 관리직으로 승진하려면 필수적으로 거쳐야 할 단계로 만든다.

어떤 회사는 업계 소프트웨어를 전체적으로 이해하는 최선의 방법으로 기

존 소프트웨어를 상세하게 파악하도록 권장한다.

유지보수와 2. 품질 보증을 연결하라. (앞 수필에서 다루었다.)

유지보수 기술을 개선하겠다는 계획을 세워라. 소프트웨어 유지보수를 좀 3.

더 효율적으로 수행하도록 도와주는 도구와 기술이 많이 나왔다(이삼십 년

전에 비하면 크게 달라졌다). 유지보수를 염려하는 관리자라면 교육/도구 선

택과 구매에 우선순위를 부여해야 한다.

‘4. 책임있는 프로그래밍’을 강조하라. 대개 유지보수 담당자는 혼자 일한

다. 이런 사람의 업무 효율을 최대화하려면 자기 업무의 품질에 책임을

부여하는 방법이 최선이다. 최근 인기 있는 ‘비자아적 프로그래밍egoless

programming’ 6)이라는 개념과 반대라는 사실에 주목한다. 비자아적 프로그

래밍은 최종 소프트웨어 제품에서 프로그래머의 사적 참여를 없애고 팀 참

여를 강조한다. 하지만 우수한 제품 품질을 유지하려면 개별 유지보수 담

당자에게 소프트웨어 제품 품질에 대한 책임을 부여해야 한다.

옮긴이_6: 비자아적 프로그래밍은 제랄드 M. 와인버그가 쓴 ‘The Psychology of Computer Programming’에서 처음 나온 개념이다. 하지만 글래스가 말하는 비자아적 프로그래밍은 와인버그가 말하는 비자아적 프로그래밍과는 의미가 조금 다르다. 와인버그가 주장한 개념은 비자아(egoless)라기보다는 자아를 누그러뜨린(less-ego) 성격에 가까우며, 25주년 기념 판에서 와인버그가 이런 사실을 직접 밝힌 바 있다.

63

2부 _ 기술 진영에서

이상이 소프트웨어 유지보수를 개선하는 간단한 네 단계이다. 모든 단계에서

전통적인 소프트웨어 사고 방식을 바꾸어야 한다는 사실에 주목한다. 기술적인

전환은 쉽지만, 사회적인 변화나 정치적인 변화는 그리 쉽지 않다. 대다수 사람들

은 전통적인 시각을 쉽게 떨치지 못한다.

하지만 사고방식을 바꾸려 한다면 반드시 떼야 할 첫 걸음이 있다. 이 수필에서

제시하는 걸음이다.

우리는 소프트웨어 유지보수를 골칫거리가 아니라 해결책으로 보아야 한다. 모

두가 이 사실에 동의한다면, 소프트웨어 종사자들이 업무를 수행하는 방식에 커

다란 변화의 장이 펼쳐질 것이다. 한번 생각해보라.

Software Conflict 2.0

64

단일 지점 제어

가르치는 관점에서 보면, 과학은 별도로 떼내서 진실이라고 가르칠 수 있는 기본

원리들로 이루어진다.

그렇다면 소프트웨어 공학의 기본 원리는 무엇일까? 어떤 사람들은 공학이 ‘부

드러운soft 과학’이라서 기본 원리를 찾아내기 어렵다고 말한다.

내가 소프트웨어 공학의 기본 원리 하나를 추천하겠다. 여기서 추천하는 기본

원리는 보잉 밀리터리 에어크래프트 사에서 일하는 내 친구 리 맥로렌이 ‘단일 지

점 제어single-point control’ 7)라고 부르는 원리이다.

단일 지점 제어는 여러 곳에서 해야 할 일을 한 곳에서 해결한 후 필요한 곳에

서 참조하는 방법이다.

가장 일반적인 단일 지점 제어 예는 라이브러리 루틴과 같은 프로그램 모듈이

다. 제곱근 등과 같은 계산을 프로그램 여러 곳에서 수행해야 할 경우, 우리는 모

든 위치에 동일한 코드를 집어넣지 않는다. 문제 해결 코드를 한 곳에 두고 다른

위치에서 이를 호출한다.

왜 이렇게 할까? 당연히 공간을 절약하기 위해서이다. 당연히 논리가 단순해지기

때문이다. 코드를 변경해야 한다면 한 군데만 손보면 족하기 때문이다.

모듈화가 비록 단일 지점 제어에서 중요하긴 하지만 한 가지 예일 뿐이다. 다른

옮긴이_7: 단일 지점 제어(Single-point control)에 대해 이 책 2판 추천 서문을 쓴 앤드류 헌트는 중복의 해악을 막기 위한 이런 원칙을 DRY(Don’t Repeat Yourself)라고 부른다.

65

2부 _ 기술 진영에서

예로는 무엇이 있을까?

명명된 상수named constant를 사용하면 프로그래머는 프로그램 상수에 이름을

할당한 후, 코드를 구현하고 유지보수하는 동안 상수를 이름으로 참조할 수 있다.

예를 들어 프로그램에서 배열 크기를 100으로 정의한다고 가정하자. 배열을 선언

한 후 배열에 대해 루프를 돌면서 항목을 배열에 할당한다. 프로그래밍 관점에서

코드는 다음과 같다.

Array TABLE (100);

For I=1,100 Do...

TABLE[1] = something;

I=I+1;

If I>100 Then Do-something;

이제 개발자가 아니라 유지보수 담당자 입장에서 생각해보자. 차후에 고객이

항목 100개가 아니라 150개를 TABLE에 담고 싶다고 요청할지도 모른다. 유지보

수 담당자는 어떤 작업을 수행해야 할까? 배열 선언에 사용된 상수 정의 100을 수

정한다. 루프 상수 100을 수정한다. TABLE 종결 조건 검사 100을 변경한다. 배열

크기로 100을 사용하는 코드를 찾아서 모두 고친다. 배열 크기와 무관한 상수 100

은 손대지 말아야 한다.

실수를 저지르기 쉬운 상황이다. 고친 소프트웨어 제품의 품질이 떨어질 가능

성이 생긴다. 대신 코드를 이렇게 구현했다고 가정해보자.

TABLE-SIZE Constant Integer = 100;

Array TABLE (TABLE-SIZE);

For I=1, TABLE-SIZE Do;

...

If I>TABLE-SIZE Then Do-something;

Software Conflict 2.0

66

유지보수 담당자가 TABLE 크기를 변경해 달라는 요청을 받으면, TABLE-

SIZE 상수 선언만 변경하고 프로그램을 다시 컴파일하면 된다. 개발자가 상수를

일관성 있게 사용했다면, 모든 변경은 자동으로 이루어진다. 즉, 유지보수 담당자

가 오류를 저지를 가능성이 현저하게 줄어든다.

자료 선언data declaration은 단일 지점 제어를 활용하는 또 다른 예이다. 다음 코

드를 살펴보자.

A = UNPACK(2,5,PACKED-DATA);

많은 옛 프로그래밍 언어에서는 위와 같은 함수로 PACKED-DATA의 비트 2에

서 비트 5까지에 unpack 연산을 적용한다. 사용 중인 프로그래밍 언어가 이런 방

식을 따르면 비트 문자열을 아주 쉽게 조작할 수 있다.

하지만 프로그램이 많은 비트 문자열을 조작하고 비트 문자열 정의가 시간이

지나면서 변하는 경우라면 문제가 생긴다. 예를 들어 프로그램이 많은 문자열의

비트 2에서 비트 5까지에 unpack 연산을 여러 차례 적용한다고 가정하자. 그리고

시간이 지나면서 문제 본질이 바뀌는 바람에 비트 문자열 정의가 비트 2에서 비트

7까지로 변했다고 가정하자. 이제 유지보수 담당자는 앞서와 같은 문제에 직면한

다. 단지 문맥만 다를 뿐이다.

여기서 가장 좋은 해결책은 선언 구문이 풍부한 언어에서 찾는다. 이런 언어를

사용한다면, 다음과 같은 구현이 가능하다.

Record PACKED-DATA

FIELD Bits 2 through 5

End Record;

언어가 제공하는 의미론적 접착제semantic glue를 적절히 사용한다면 프로그램

전체에서 FIELD를 이름으로 참조할 수 있다. 나중에 비트 명세가 바뀐다 해도 선

언부만 변경하면 충분하며, 이 선언을 사용하는 프로그램 구현부를 일일이 변경

67

2부 _ 기술 진영에서

할 필요가 없다. 명명된 상수와 용도는 다소 다르지만 장점은 매우 유사하다.

표 주도table-driven 코드는 일련의 절차적 문장을 사용하는 대신 표에다 작업 논

리를 정의하는 코드이다. 흔히 표는 부울, 정수, 문자열 등과 같은 상수값을 포함

하며, 프로그램은 표 값을 이용해서 논리 경로를 결정한다.

이 방식에서는 프로그램 논리가 변할 경우, 표 값만 변경하면 된다. 프로그램

논리 내부에 산재한 절차적 코드는 손댈 필요가 없다. 마찬가지로, 프로그램에서

한 군데만 변경하면 나머지도 일관성을 유지하며 자동으로 변한다.

유사한 개념이 파일 주도 텍스트file-driven textual 코드이다. (특히 개인용 컴퓨터에

서 돌아가는 소프트웨어 제품에서) 사용자 인터페이스가 고급스러워지고 개선되면서

사용자 인터페이스 정보를 좀 더 효율적으로 제어할 방법이 필요해졌다. 이 문제

를 해결하는 한 방법으로, 모든 사용자 인터페이스 문자열을 파일 하나에 넣고 프

로그램에서 필요할 때마다 이 파일을 참조한다.

이런 방법은 파일에서 텍스트를 가져오는 과정에 다소 시간이 걸린다는 단점이

있다. 하지만 문자열을 한 곳에 모아둠으로 쉽게 변경할 수 있다는 장점이 있다.

예를 들어, 프로그램의 사용자 인터페이스를 수정하려면 프로그램을 고쳐서 다시

컴파일할 필요 없이 텍스트 파일만 편집하면 된다.

이 개념을 적용하는 흥미로운 예제 하나가 영어와 스페인어 등 여러 언어로 사

용자 인터페이스를 제공하는 프로그램 제작이다. 다른 언어를 제공하는 프로그램

버전을 만들려면, 전적으로 텍스트 파일만 다시 만들면 된다. 프로그램은 손댈 필

요가 없다.

앞서 언급한 단점인 효율성 문제도 사실은 쉽게 해결이 가능하다. 사용자 인터

페이스 자료를 텍스트 파일로 보관한다 해도, 프로그램 시작 시 파일을 읽어들이

면 된다. 프로그램을 실행하는 동안 텍스트를 메모리에 상주시키면, 필요할 때마

다 사용자 메시지를 파일에서 가져오는 부하를 효과적으로 제거할 수 있다.

물론, 단일 지점 제어는 프로그래밍 개념으로만 그치지 않는다. 문서도 한 군데

서만 정보를 기록한 후 여러 곳에서 참조할 수 있다. 특히 데이터베이스에서는 원

Software Conflict 2.0

68

본 자료를 관리해서 사본이 따로 놀지 않도록 해야 한다. 교과 과정을 개발할 때

는 동일한 주제를 여러 과목에서 가르치지 않아야 하므로, 교과목의 단일 제어 지

점을 찾아내서 이러한 문제를 방지할 수 있겠다.

단일 제어 지점을 적용할 수 있는 분야는 대단히 많다. 그래서 나는 단일 제어

지점을 소프트웨어 공학의 기본 원리 후보로 추천한다. 여러분은 어떤 후보를 추

천하겠는가?

69

2부 _ 기술 진영에서

사용자 편의성 - 유행어인가, 도약인가?

사용자 편의성은 우리 모두가 아는 표현이다. 이 단어는 1980년대를 대표하는 유

행어 중 하나가 되었지만, 과연 이게 전부일까?

나는 ‘아니다’라는 쪽에 표를 던진다. 소프트웨어 공학자들이 ‘사용자를 고려’

하기 시작했으며, 이러한 고려가 소프트웨어 사용자 인터페이스에 진정한 도약을

가져왔다고 나는 믿는다. 지난 십여 년간 우리는 전산 분야에서 가장 중요한 진보

를 이루어냈다.

여기서 “사용자를 고려한다”란 무슨 뜻일까? 소프트웨어 공학자들이 사용자 입

장에 서보고 사용자 관점에서 인터페이스를 개발한다는 말이다. 기술 문제부터

공략한 후 인터페이스를 나중에 덧칠하는 전통적인 방식 대신, 인터페이스에서

출발해서 응용 프로그램으로 파고들어야 한다고까지 말하는 사람들도 있다.

제록스 PARC(제록스가 세운 팔로 알토 연구 센터Palo Alto Research Center)가 내디딘

첫걸음에서 상업적인 성공을 거둔 애플 매킨토시에 이르기까지, 사용자 인터페이

스는 진정으로 혁신을 거듭해왔다. 이제는 수많은 소프트웨어 회사가 마치 사용

자의 실제 책상 위처럼 여러 정보를 서로 겹쳐놓는, 소위 ‘윈도우’ 기술을 컴퓨터

제품에 탑재한다. 그래픽 인터페이스는 훨씬 사실적으로 발전하여, 사용자는 문

자와 도표뿐만 아니라 그림도 쉽게 조작한다. 움직이는 그래픽도 멀지 않았다. 고

객이 값을 지불할 용의만 있다면 고품질 음향도 가능하다. 음향 입력은 아직도 제

Software Conflict 2.0

70

약이 크지만, 제한적인 환경이라도 괜찮은 곳에서는 성공적으로 사용하고 있다.

이러한 흥미진진한 진보에는 대가가 따른다는 사실에 주목해야 한다. 성공적인

사용자 인터페이스를 제공하려는 소프트웨어 개발자는 개발 시간을 1.5배, 심지

어 2배까지 예상해야 한다. 사용자 인터페이스 자체가 전문 분야화하고 있다. 그

러므로 일반 대중에게 제품을 내놓으려면, 인터페이스 설계는 물론 구현까지 인

간공학 전문가를 참여시켜야 할지도 모른다.

그렇다면 소프트웨어 엔지니어는 어떻게 ‘사용자를 고려’하는 요령을 향상시킬

수 있을까? 설계자는 기술자가 아니라 예술가처럼 생각해야 하며 사용자 인터페

이스를 의사소통 문제로 다루어야 한다고 폴 헤켈은 제안한다. 그는 설계자가 사

용자 입장에서 좀 더 효과적으로 생각하고 싶다면 영화 제작이나 오락과 같은 전

통적인 예술 분야를 공부해서 유사성을 찾으라고 제안한다.

‘사용자 고려’는 다양한 측면에서 가능하다.

• 시장 조사 - 사용자를 파악하고 그들의 필요와 요구를 이해한다. (필요와

요구가 반드시 동일하지 않지만, 필요를 무시하지 않도록 주의해야 한다).

• 사용자 검토 참여 - 설계를 발전시켜 나가면서 사용자로부터 피드백을 받

는다.

• 프로토타이핑 - 사용자가 자신들의 필요나 요구를 명확히 모른다면, 간단

한 예제를 구축하여 경험하게 한다.

• 사용자 교육 - 최종 인터페이스에 사용자들이 익숙해지도록 도와준다. 제

품 사용에 대한 교육 과정을 제공한다.

• 사용자 지원 수준 - 자습서(도움말) 인터페이스를 신중히 제작하여 자체적

으로 학습이 가능한 소프트웨어를 만든다. 선택적으로 도움말 파일을 살

펴보는 기능을 제공한다. 숙련된 사용자에게는 좀 더 빠른 인터페이스 옵

션을 제공한다. 모든 작업이 실패할 경우에 펼쳐볼 우수한 사용자 문서를

제공한다. 의미 있는 진단 메시지를 제공한다.

71

2부 _ 기술 진영에서

• 사용자 인터페이스 지침 확립 - 사용자 인터페이스를 논하는 책(자료 목

록 참고)이라면 모두가 우수한 인터페이스를 구축하는 방법으로 10여개

에서 100여개에 이르는 지침을 제공한다. 여기에는 단순성, 일관성, 예측

가능성 등이 있다. 자신의 응용 프로그램에 적합한 지침을 찾아서 적용

한다.

소프트웨어 엔지니어와 소프트웨어 관리자는 해당 분야의 발전 상태와 연구 문

헌에 관심을 기울여야 한다. 너무나 빨리 변하는 터라, 자칫 부주의했다가는 구닥

다리 전문가가 될 위험이 크다.

관련 주제를 좀 더 자세히 파고들고 싶다면 다음 문헌을 참조한다.

• ABLEX8)는 ‘인간/컴퓨터 상호작용’이라는 주제를 놓고 책 여러 권을 출판

했다. 제목은 다음과 같다.

‘Advances in Human-Computer Interaction’

‘Human-Computer Interface Design Guidelines’

‘Directions in Human/Computer Interaction’

‘• Abstractions for User Interface Design’, IEEE Computer, September 1985;

Coutaz. 사용자 편의를 고려한 인터페이스를 성공적으로 구현하는 방식을

논한다.

‘• The elements of Friendly Software Design’, Warner Books, 1984; Heckle.

우수한 인터페이스 설계는 기술이 아니라 예술이라고 말하며, 소프트웨어

공학도는 영화 제작자와 같은 예술가가 발휘하는 기교를 배워야 한다고 제

안한다. 훌륭한 인터페이스 디자인을 위한 지침을 나열한다.

‘Design Guidelines for the User Interface to Computer-Based Information •

Systems’, ESD-TR-83-122, 1983; MITRE Corp. 공군에서 지원한 연구 결과

옮긴이_8: HCI 관련 서적을 펴낸 출판사이다. 1997년 이후 HCI 서적 부분은 인텔렉트(http://www.intellectbooks.co.uk/)로 판권이 넘어간 상황이다.

Software Conflict 2.0

72

로, 가장 철저한 지침 목록 중 하나이다.

‘Designing the Star User Interface’, Byte, April 1982; Smith, Irby, Kimball, •

Verplank, and Harslem. (나중에 애플 매킨토시 인터페이스가 된) 초창기 제록

스 스타 인터페이스의 근본 원리를 소개한 논문으로, 제록스 스타 시스템

개발자들이 작성했다.

73

2부 _ 기술 진영에서

소프트웨어 논쟁 원본을 다시 읽으면서 책의 주제가 순식간에 기술적 내용으로

변했다는 사실에 놀라움을 금치 못했다. 이 같은 변화가 우연은 아니었다.

(소프트웨어 공학 분야가 태동하던 1950년대에 시작한) 내 경력 전반에 걸쳐, 나는

의도적으로 소프트웨어 인력 관리자가 되기를 회피하고 소프트웨어 기술자가 되

는 편을 택했다. 이유? 직접 재미난 일을 할 수 있는데, 재미난 일을 하는 사람들

을 관리하는 직업이 무슨 재미가 있겠는가?

그래서 이 책 둘째 장은 기술 주제를 다룬다. 소프트웨어 설계라는 주제보다 더

기술적인 주제가 있겠는가? ‘인지적 견해: 소프트웨어 설계를 보는 다른 시각’에

서 나는 몇몇 유명한 연구진의 경험적 시각을 빌어 설계라는 세계를 들어다 보고,

이 파악하기 힘든 주제의 본질에 대하여 (내게는) 매우 흥미로운 사실을 배웠다.

지금도 지난 세월의 동료들이 현존하는 소프트웨어 설계의 본질이라는 주제에 대

해 가장 결정적인 발견을 했다고 생각한다.

테스트와 유지보수는 내 흥미를 끄는 또 다른 기술 주제 두 가지이다. 소프트웨

어 분야에서 오랫동안 등한시해 온 주제이지만, 나도 모르게 이 두 주제에 마음이

끌린다. 어쩌면 다른 사람들이 무시했기 때문이리라. 다시 한 번 말하지만, 슬프

게도 테스트와 유지보수라는 주제 역시 이 장에서 피력한 예전의 생각이 오늘날

에도 크게 달라지지 않았다.

•회고•

기술 진영에서

Software Conflict 2.0

74

그렇다면 이 장에서 현실에 맞지 않는 내용은 무엇일까? 앞서 언급한 참고 자

료 중 일부는 1980년대로 거슬러 올라간다. 이런 옛날옛적 자료에 계속 의존해서

는 안된다. 이들 ‘옛날옛적’ 자료만큼이나 해당 주제에 심오한 질문을 던지고 심오

한 통찰을 제시한 사람들이 없다는 사실 한 가지만 제외하고 말이다. 그래서 상당

히 오래된 인용에 대해 겉으로는 사과하지만, 참으로 오래된 인용의 현실성에 대

해 속으로는 결코 사과할 마음이 없다.

후반부에 소개하는 참고 자료 중, 이 책을 처음 출간할 당시에는 소프트웨어 무대

에서 빛을 발했으나 점차 소프트웨어 공학 레이더 화면에서 사라져버린 기관이 몇 곳

있다. 당시 실용 중심의 소프트웨어 공학 연구 세계를 이끌던 연구 기관은 SEI, SPC,

MCC 등이 있었다. SEI는 프로세스 쪽으로 치우쳤지만 여전히 소프트웨어 공학 분야

의 선봉에 있다. 반면 SPC와 MCC는 거의 옛 이야기로만 전해진다. 아쉬운 일이다.

소프트웨어 공학 분야에는 우리 모두를 발전시키겠다는 목표에 매진하는 독립 기관

이 진정으로 필요하다.

75

2부 _ 기술 진영에서