왜 시스템 개발만 하면 싸워댈까? : 49가지 분쟁 사례로 배우는 프로젝트...

시스템 개발만 하면 싸워댈까?

49가지 분쟁 사례로 배우는

프로젝트 관리 비법

왜

시스템 개발만 하면 싸워댈까?49가지 분쟁 사례로 배우는 프로젝트 관리 비법

왜

지은이 호소카와 요시히로

옮긴이 최미정

펴낸이 박찬규 엮은이 이대엽 디자인 북누리 표지디자인 아로와 & 아로와나

펴낸곳 위키북스 전화 031-955-3658, 3659 팩스 031-955-3660

주소 경기도 파주시 문발로 115 세종출판벤처타운 311호

가격 25,000 페이지 272 책규격 188 x 240mm

초판 발행 2014년 10월 30일

ISBN 978-89-98139-69-8 (13000)

등록번호 제406-2006-000036호 등록일자 2006년 05월 19일

홈페이지 wikibook.co.kr 전자우편 [email protected]

NAZE, SYSTEM KAIHATSU WA KANARAZU MOMERUNOKA? by Yoshihiro Hosokawa

Copyright © Yoshihiro Hosokawa, 2013

All right reserved.

First published in Japan by Nippon Jitsugyo Publishing, Tokyo.

This Korean edition is published by arrangement with Nippon Jitsugyo Publishing, Tokyo

in care of Tuttle-Mori Agency, Inc., Tokyo through Enters Korea Co., Ltd., Seoul.

이 책의 한국어판 저작권은 (주)엔터스코리아를 통한 저작권사와의 독점 계약으로 위키북스가 소유합니다.

신 저작권법에 의해 한국 내에서 보호를 받는 저작물이므로 무단 전재와 복제를 금합니다.

이 책의 내용에 대한 추가 지원과 문의는 위키북스 출판사 홈페이지 wikibook.co.kr이나

이메일 [email protected]을 이용해 주세요.

이 도서의 국립중앙도서관 출판예정도서목록(CIP)은

서지정보유통지원시스템 홈페이지(http://seoji.nl.go.kr)와

국가자료공동목록시스템(http://www.nl.go.kr/kolisnet)에서 이용하실 수 있습니다.

(CIP제어번호: CIP2014029649)

「벤더는 발주자 협력 없이 독자적으로 시스템을 개발할 수 없다!」

어느 시스템 개발과 관련된 소송 사건에서 재판관이 실제로 했던 말입니다. 제대로 된

시스템을 개발하려면 발주자와 벤더는 반드시 서로 협력해야 합니다. 그렇지 않으면 요

구사항을 제대로 관리할 수 없고, 이해관계가 어긋나 프로젝트 기획이나 품질관리까지

소홀해지고 최악의 경우에는 계약 내용을 이행하지 못하게 됩니다.

결과적으로 프로젝트는 실패하고 발주자와 벤더는 엄청난 인적, 경제적 손실을 보게 됩

니다.

이렇게 프로젝트가 실패하는 원인은 대체 뭘까요?

그리고 발주자와 벤더는 서로 어떻게 협력해야 할까요?

이 책은 여러 IT 분쟁 사례를 비롯해 제가 IT 기술자였던 시절과 컨설턴트 시절에 겪었

던 경험을 바탕으로 프로젝트의 실패 원인을 분석하고 해결책을 고민해 정리한 것입

니다.

「아리스카와 도코」라는 가상의 IT 전문변호사가 주인공으로, 시스템 개발 중에 발생하

는 여러 문제를 이야기 형식으로 풀어 구성했습니다. 책에서 제시한 해결 방안은 실제

IT 소송이나 현장의 분쟁 사례를 근거로 했습니다.

이 책은 계약 단계부터 검수 단계까지 시스템을 개발하면서 발생할 수 있는 모든 분쟁과

해결 방안을 담았습니다. 독자 여러분이 이해하기 쉽게 폭포수 모형 개발 방식을 기준

으로 썼지만 문제 해결 방안은 애자일 모델링이나 시제품 모형 등에도 적용할 수 있습

니다.

그리고 프로젝트 관리 지표인 CMMI와 ITIL, PMBOK 등을 참고로 프로젝트 성공에

필요한 다양한 자료를 실었습니다.

이 책은 프로젝트의 QCD (품질(Quality ), 가격(Cost ), 납품(Delivery/Time ) )를

준수하려고 고민하는 프로젝트 매니저와 IT 기술자는 물론 발주자까지 시스템 개발로

얻을 수 있는 이점을 예측할 수 있어 유용합니다.

preface

늦었지만 잠시 제 소개를 하겠습니다. 저는 대학 졸업 후 대기업 계열 소프트웨어 개발

회사에 입사해 초기에는 IT 기술자로, 나중에는 프로젝트 매니저로 여러 시스템 개발

프로젝트에 참여했습니다. 개발 회사에서 퇴사한 후에는 컨설팅 회사로 옮겨 IT 프로세

스 컨설팅 업무를 했습니다. 현재는 이런 경력을 인정받아 도쿄 지방재판소의 IT 사건

담당 조정위원으로 배속돼 날마다 수많은 IT 분쟁 사건을 다루고 있습니다. 말하자면

저는 학문적 가치를 추구하는 학자나 연구원이 아니라 실무자라는 뜻입니다. 이 책 또

한 시스템 개발과 프로젝트 관리의 이상형을 제시하는 학술 서적이 아니라, 프로젝트의

각 단계에서 업무를 처리하는 방법을 분석해 놓은 “잡초 교과서”입니다.

이 책의 주인공인 도코는 여러 문제의 해결 방안을 직설적으로 제시합니다. 그러나 도

코가 제시하는 해결법이 “유일무이한 정답”은 아닙니다.

각자 자신의 프로젝트에 대입해 「나라면 어떻게 할까?」, 「더 좋은 방법은 없을까?」 고민

하며 읽어주길 바랍니다. 그러면 정형화된 방법론이 아닌 자신에게 딱 맞는 방법론을

찾을 수 있을 겁니다.

부디 이 책이 여러분의 프로젝트를 성공으로 이끄는 데 조금이라도 이바지하면 좋겠습

니다.

도쿄지방재판소 IT 전문 조정위원

호소카와 요시히로

※ CMMIⓇ는 미국 카네기 멜론 대학이 등록한 소프트웨어 품질 보증 상표다.

※ ITILⓇ(IT Infrastructure Library)는 영국정부조달기관이 등록한 유럽연합상표다.

※ PMBOK는 미국 프로젝트 관리 협회(Project Management Institute=PMI)가 등록한 프로젝트

관리 전문 상표다.

CONTENTS

머리말 04

이 책이 전제로 하는 개발공정 12

등장인물 15

※ V는 벤더가, U는 발주자가 주의해야 할 사항을 표시한 것입니다.

요구사항 정의(말했다 VS. 안 했다, 하기로 했다 VS. 안 했다)

CASE 1 발주자가 요구사항을 계속 추가할 때 20

CASE 2 요구사항 정의란 도대체 무엇인가? 24

CASE 3 발주자가 요구사항 정의를 벤더에게 전담할 때 28

CASE 4 소프트웨어 패키지의 함정 ① 32

CASE 5 소프트웨어 패키지의 함정 ② 36

CASE 6 확정되지 않은 요건은 어떻게 처리할까? 40

CASE 7 벤더가 멋대로 성능 요건을 제외했을 때 44

CASE 8 요구사항 변경의 영향 범위를 파악할 수 없을 때 48

CASE 9 발주처 담당자가 벤더와 친할 때 52

CASE 10 요구사항 정의 없이 개발했을 때 56

CASE 1 1 업무 요건에 누락된 요소가 있을 때 60

CASE 12 시스템 개발 범위는 어떻게 정할까? 64

CHAPTER1REQUIREMENT DEFINITION

V

U V

V

U V

U V

U V

U

V

U

U V

U V

U V

DATA요구사항 정의서 체크리스트 68

비기능적 요구사항 개요 69

요구사항 추적표 예시 70

COLUMN1 IT 분쟁 판결까지 얼마나 걸릴까? 72

프로젝트 계획과 관리 (일정표 체크만이 관리는 아니다)

CASE 13 프로젝트 위험 관리는 어떻게 할까? 74

CASE 14 벤더는 발주자 측 위험요소를 어떻게 관리해야 할까? 78

CASE 15 벤더가 진척도를 거짓으로 보고 했을 때 82

CASE 16 발주자가 위압적인 태도를 보일 때 86

CASE 17 발주자의 참여의식을 높이려면 어떻게 해야 할까? 90

CASE 18 핵심 팀원이 병으로 쓰러졌을 때 94

CASE 19 벤더를 변경했는데 프로젝트 관리자까지 퇴사했을 때 98

CASE 20 프로젝트 계획서는 어떻게 써야 할까? 102

DATA프로젝트 계획서 기재항목 예시 106

프로젝트 관리 계획 기재항목 예시 110

WBS(Work Breakdown Structure: 작업분류체계)와 EV(Earned Value: 획득가치) 114

COLUMN2 사회적 통념에 따른 판결 118

U V

CHAPTER2PROJECT PLANNING AND MANAGEMENT

V

U V

V

V

V

V

U

U V

설계(벤더와 발주자가 협의할 사항)

CASE 21 산출물을 객관적으로 검토할 수 있는 사람은? 120

CASE 22 체크리스트는 어떻게 활용해야 할까? 124

CASE 23 발주자가 만든 요구사항 정의서에 누락된 사항이 있을 때 128

CASE 24 검수한 시스템에서 설계 오류가 발견됐을 때 132

CASE 25 설계서에도 저작권이 있을까? 136

CASE 26 설계 단계에서 소프트웨어 패키지가 부적합하다고 밝혀졌을 때 140

CASE 27 소프트웨어 패키지의 결함은 어떻게 평가할까? 144

DATA설계서 체크리스트 148

COLUMN3 조정을 신청하면 손해 볼 일은 없다? 152

프로그래밍(작동만 하면 끝이 아니다)

CASE 28 프로그래밍 순서는 어떻게 정할까? 154

CASE 29 사소한 버그를 내버려두면 큰 손해를 입는다 158

CASE 30 문제 해결 우선순위는 어떤 기준으로 판단할까? 162

CHAPTER3DESIGN

V

V

V

V

V

U V

V

U V

CHAPTER4PROGRAMMING

V

V

V

CONTENTS

CASE 31 보안 정보는 어디까지 파악해야 할까? 166

CASE 32 프로그램 품질을 어떻게 개선해야 할까? 170

DATA소스코드 체크리스트 174

COLUMN4 조정위원을 얕보지 마라 176

테스트(뭘 테스트해야 하는지 아는가?)

CASE 33 테스트를 효과적으로 하려면 어떤 준비가 필요할까? 178

CASE 34 프로젝트 완료는 무엇을 기준으로 판단할까? 182

CASE 35 발주자는 산출물의 품질을 어떻게 평가해야 할까? 186

CASE 36 컴퓨터 시스템 검수란 무엇일까? 190

CASE 37 검수 후 오류가 발견되면 어떻게 해야 할까? 194

CASE 38 불특정 다수가 사용하는 시스템은 어떻게 테스트해야 할까? 198

DATA개발용 SLA(Service Level Agreement: 서비스 수준 협약) 사례 202

검수 계획서, 테스트 시나리오 체크리스트 204

COLUMN5 IT 변호사란? 208

V

V

V

CHAPTER5TEST

V

U V

U V

U V

V

U

U V

CONTENTS

계약과 프로젝트 완료(뭘 약속했지?)

CASE 39 프로젝트 책임자의 역할은? ① 210

CASE 40 프로젝트 책임자의 역할은? ② 214

CASE 41 시스템 개발 계약서에는 어떤 사항이 들어가야 할까? 218

CASE 42 개발 규모가 원래 산정했던 견적보다 커졌을 때 222

CASE 43 계약서 없이 프로젝트를 진행하면 어떤 문제가 생길까? 226

CASE 44 프로젝트 관리의 중요성 230

CASE 45 가발주서만 접수하고 작업을 시작했을 때 234

CASE 46 프로젝트에 외부 자문인력이 꼭 필요할까? 238

CASE 47 도코가 보낸 메일 242

CASE 48 「발주자의 신의성실의 원칙」이란? 246

CASE 49 프로젝트 성공 모델은? 250

DATA소프트웨어 계약 시 포함해야 하는 조항 254

COLUMN6 IT 분쟁을 피하려면? 260

도코의 체크리스트 261

도코가 추천하는 책 269

참고문헌 270

CHAPTER6COMPLETION OF A CONTRACT AND THE WORK

U

U

U V

V

V

V

V

V

V

U V

U V

이 책이 전제로 하는 개발공정이 책은 폭포수 모형 개발 방식을 전제로 작성했지만 공정이나 업무 단계 구분 , 산출물 등의 명칭

은 조직마다 다를 수 있으므로 소속한 조직에서 사용하는 용어로 대체해 읽어 주십시오 .

1. 요구사항 정의

• 현행업무와 이를 지원하는 기존 시스템을 분석하고, 개선점과 필요한 기능을 도출해 새로운 시스템의

개발 범위와 목적, 정책 등을 결정.

• 위 내용을 바탕으로 요구사항 정의.

• 요구사항 정의 내용을 바탕으로 시스템 또는 인수 테스트 시나리오와 평가서 결정.

산출물

• 현행업무와 기존 시스템을 분석한 결과로 문제점 도출

• 새로운 업무 프로세스 설계

• 요구사항 정의와 수행 범위 계획

• 시스템 개발 목적과 방침 수립

• 기능적 요구사항 정의

• 비기능적 요구사항 정의

• 개발과 운용 및 이관을 위한 전제 조건과 제약 조건 설정

• 시스템 테스트와 인수 테스트 시나리오와 평가서 등

2. 외부설계

• 요구사항을 구현하기 위한 개발방법론과 하드웨어 및 소프트웨어, 네트워크 등을 정의한 시스템 구성

명시.

• 필요한 소프트웨어 기능을 도출하고 정리해 각 구성 요소에 할당.

• 사용자 인터페이스를 포함한 외부 인터페이스와 구성 요소 간의 인터페이스 결정, DB와 파일 정의.

• 통합 테스트 시나리오 검토.

산출물

• 개발방법론

• 시스템 구성(소프트웨어 구성 포함)

• 기능정의서

• 인터페이스 설계서

• 화면설계서와 메시지 정의서

• DB 설계서와 파일 설계서

• 통합 테스트 시나리오(외부)와 평가서 등

3. 내부설계

• 시스템을 구성하는 소프트웨어의 동작과 처리 모듈 할당.

• 프로그램 구조나 프로그램 사이의 인터페이스 등을 개발할 수 있게 상세히 정의.

산출물

• 모듈 구성도

• 프로그램 목록

• 데이터 처리 방식

• 프로그램 명세서

• 내부 인터페이스 정의

• 변수와 상수 정의

• 통합 테스트 시나리오(내부용)와 평가서

• 단위 테스트 시나리오와 체크 항목과 평가서 등

4. 프로그래밍과 단위 테스트

• 프로그램 작성과 단위 테스트.

• 통합 테스트를 준비하려면 테스트 시나리오를 확정하고 테스트 환경을 구축해야 함.

• 실제 시스템을 가동하는 데 필요한 각종 매뉴얼 작성.

산출물

• 프로그램

• 각종 설정 파일과 데이터

• 단위 테스트 결과와 평가서

• 통합 테스트 시나리오 확정판

• 통합 테스트 환경 준비

• 운용 매뉴얼, 사용자 매뉴얼

5. 통합 테스트

• 시나리오에 따라 통합 테스트

• 시스템 테스트 설명서와 평가서 작성

• 테스트 환경 준비

산출물

• 통합 테스트 결과와 평가서

• 시스템 테스트 시나리오 확정판

• 시스템 테스트 환경 준비

6. 시스템 테스트

• 운용 테스트를 포함한 시스템 테스트 시행

• 인수 테스트 준비

산출물

• 시스템 테스트 결과와 평가서

• 인수 테스트 시나리오 확정판

• 인수 테스트 환경 준비

7. 인수 테스트

• 발주자 주체로 실제 업무 프로세스와 시나리오에 따라 테스트 시행

※ 대부분 이 테스트 결과에 따라 계약 이행 여부를 판단

산출물

• 인수 테스트 결과와 평가서

• 최종 산출물 전체

이 책의 등장인물

다이조

쇼스케

아야네

이치로

도코

도코 사무실에서 만남

(존대)

도코 사무실에서 만남

(존대)

친구(반말)

선배(존대)

후배(반말) 고객(존대)

의뢰

(반말)

친구(반말)

아버지

(존대)

아들

(반말)

대학 재학 중 사법시험에 합격한 26세의 젊고 유능한 변호사로 유명한 법률사무소인 「신마루노

우치 법률사무소」에서 기업 법무 전문가로 활동 중이다.

최근에는 컴퓨터 시스템과 관련된 「IT 분쟁」이 모두 그녀에게 맡겨져 골치를 앓고 있다.

IT 분쟁은 「클라우드」니 「RDB」니 하는 비전문가에게 어려운 용어가 오가고, 증거자료로 제출

된 산출물 역시 외계 용어나 다름없는 프로그램 파일이다. 게다가 결함이 있어도 업무 수행은

가능하다거나 아무리 비용을 지급한 발주자라도 개발에 책임이 있다는 등 일반적인 비즈니스

상식으로는 이해하기 어려운 판결도 많아서 대부분 변호사가 IT 분쟁을 꺼린다. 그녀는 관심분

야도 아닌 IT 분쟁에 시간을 뺏기고 싶지 않았지만 어쩌다 보니 수많은 분쟁을 해결해 “IT 변호

사 도코 님”이라는 명성까지 얻는다. 그러다 보니 자연스럽게 대학 동기나 동호회 사람까지 IT

분쟁을 상담해오기 시작한다.

도코의 또 다른 고민은 모두가 인정하는 미인이지만 좀처럼 인연이 나타나지 않는 것이다. 고

객에게 「덜떨어졌다!」, 「멍청하다!」라고 독설을 내뱉는 성격 탓이겠지만, 정작 본인은 전혀 모르

고 있다.

TOKO ARISUGAWA아리스가와 도코

도코의 대학 후배로 같은 서예 동아리 출신이다. 이제 갓 대학을 졸업한 23세 아가씨로 미팅과

노래방을 좋아한다. 작은 소프트웨어 개발 회사인 「이글 소프트웨어」에서 프로그래머 겸 시스

템 엔지니어 겸 고객상담원으로 대활약 중이다.

그런데 프로젝트 운이 없는 건지 참여하는 프로젝트마다 분쟁이 끊이지 않는다. 프로젝트 매니

저가 발주자와 문제가 생겨 고민하는 모습을 보다못해 도코에게 자주 상담하러 온다.

똑똑하고 열정적이지만 자신의 외모에 자신감이 넘쳐서 도코를 내심 라이벌로 생각한다. 그녀

가 왜 영세 소프트웨어 개발 회사에서 근무하는지는 미스터리다.

대형 유통기업 「에치고야」의 후계자다. 성격은 좋지만 온실 속 화초로 자란 도련님이라 쉽게 남

을 믿었다가 실패하는 일이 많다. 딱 한 번 도코와 영화를 보러 갔지만 태평하고 우유부단한 성

격 탓에 3시간 45분 만에 차였다.

그러데 도코가 우연히 에치고야의 고문변호사를 맡게 되면서 재회한다. 최근 본사 시스템 기획

부장으로 취임해 온라인 쇼핑몰 구축이라는 중대한 프로젝트를 맡게 됐으나, 아직 본인이 얼마

나 중요한 업무를 맡았는지 이해하지 못하고 있다. 도코는 그런 쇼스케가 영 미덥지 않아 발주

자의 역할이 무엇인지 따끔하게 충고한다.

AYANE SAIONJI

SHOSUKE NARIKANE

사이온지 아야네

나리카네 쇼스케

쇼스케의 아버지로 부모님이 경영하던 작은 채소가게를 대형 프랜차이즈 유통기업으로 키워낸

수완가다. 외아들인 쇼스케가 후계자로서 미덥지 않아 불안하다. 고문변호사인 도코를 매우 신

임해 법무 상담뿐만 아니라 아들 문제며 넥타이 색깔까지 조언을 구한다.

도코의 대학 동기로 같은 스터디그룹 출신이다. 당시 자기소개를 하면서 「좋아하는 말은 늘 진

실하게」라는 발언을 한 뒤로 “성실이”라고 불린다.

대형 IT 벤더에 취직해 프로젝트 매니저로 팀을 선도해야 하는 상황이지만, 마음이 약한 탓에

발주자와 팀원 사이에 껴서 늘 고민한다.

자, 도코는 자신을 찾아온 친구들의 고민을 과연 어떻게 해결할까요?

……정체불명.

DAIZO NARIKANE

ICHRO ARICA

TAMAMON

나리카네 다이조

아리카 이치로

타마몬?

요구사항 정의(말했다 vs. 안 했다, 하기로 했다 vs. 안 했다)

CHAPTER

1

1장에서는 수많은 분쟁의 근본 원인이 되는 요구사항 정의

과정을 알아보겠습니다. 요구사항 정의에서 반드시 결정해

야 하는 사항과 분쟁의 원인으로 가장 많이 꼽히는 잦은 요

구사항 변경, 요구사항 정의를 벤더에게 내맡기는 발주자, 최

종 사용자를 무시한 요구사항 정의, 개발 목적과 요구사항의

관계, 요구사항 추적 가능성 등을 설명하겠습니다.

발주자가 요구사항을 계속 추가할 때시스템 개발에서 가장 중요한 업무는 어떤 기능이 필요한지 요구사항을 정의하는 일입

니다. 하지만 아직 만들어지지 않은 시스템의 기능을 정확히 정의하기란 쉽지 않습니

다. 발주자와 벤더가 제아무리 사전에 요구사항 정의를 끝내고 수행 범위를 결정했다고

해도 개발 도중에 기능을 추가하거나 변경해 프로젝트가 혼란에 빠지는 일은 비일비재

합니다.

개요

아야네가 근무하는 소프트웨어 개발 회사는 대형 전자제품 제조사로부터 영업지원 시스템 개발을 의뢰받

았습니다. 시스템의 목적은 트위터(Twitter ) 같은 SNS에서 자사 제품과 경쟁사 제품을 고객이 어떻게 생

각하는지 의견을 수집해 이를 토대로 판매전략을 세우는 것입니다1 . 그런데 요구사항 정의가 끝났는데도

발주자가 계속해서 기능을 추가하고 변경을 요구합니다. 그 바람에 개발 진행이 더뎌지고 일정은 2개월이

나 지연된 상태입니다.

아야네: 설계가 끝났어도 한참 전에 끝났어야 하는데, 발주자가 또 요구사항을 추가하고 있어요! 게다가 납

품일 연장은 절대 안 된다고 하니 정말 너무하지 않아요?

도코: 무슨 소리야? 시스템을 개발하면서 요구사항 정의가 제때 끝나는 것 봤니? 그런 일은 내 미모를

인정하지 않는 남자 수보다 적을걸.

아야네: 선배, 도대체 그 근거 없는 자신감은 어디에서 나오는 거예요? 그보다 이대로면 설계나 프로그래

밍할 기간이 점점 줄어들어요. 매일 날밤 새워도 기간 내에 개발하기는 글렀어요.

도코: 야근하면 되지. 애써 봐.

아야네: 그런 저주 퍼붓지 말고요.

도코: 네 괴로움은 곧 나의 즐거움. 아우 고소해.

1 저자 주: 소위 말하는 빅데이터 분석. 인터넷이나 전화, 판매점 등에서 수집한 고객의 의견을 지역이나 나이, 성별, 기타 여러 가지 관점으로 분석해

그 결과를 토대로 마케팅 전략을 수립. DB에 기록된 정보를 임의의 키워드로 추출해서 분석해야 하므로 고난도의 기술이 필요한 개발이다.

CASE 1 CHAPTER1

Requirement definition

V

요구사항 정의 21

아야네: 선배 정말 악마예요.

도코: 마음대로 지껄여. 그래서 그 갑님의 요구가 뭐야?

아야네: 예를 들면 “고객 의견” 분석 같은 거예요. 처음엔 지역과 나이, 성별 분석만 하면 된다더니 중간에

다른 사람이 껴들어서 직업별, 기호별 분석도 넣어달라는 거예요. 그래서 화면설계서 그려 가면,

또 다른 사람이 껴들어서 매뉴얼 내려받기를 넣어달라, 입력순서가 다르다며 계속 요구가 늘어나

요.

도코: 발주자 의견이 정리가 안 돼서 요구사항은 계속 늘어나는데 납품일과 예산은 그대로다. 그래서 벤

더는 일정에 쫓겨 품질이 떨어지는 시스템을 그대로 납품해버리고, 결국 프로젝트는 파탄 나버린

다. 내 미모 때문에 가정을 버리는 남자 수만큼 많은 일이야. 발주자는 이따위 시스템에 비용을 지

급할 수 없다고 나올 테고, 벤더는 발주자가 일정 무시하고 요구사항 추가해서 그렇다며 싸우겠지.

아야네: 그러면 어느 쪽이 이겨요?

도코: 때에 따라 다르지만 내가 알기로는 벤더 측에도 어느 정도 책임이 있다는 판례가 많아.

아야네: 아니, 왜요? 벤더가 무슨 잘못을 했다고?

도코: 2004년 3월 10일 도쿄지방재판소의 판례2가 도움될 거야. 발주자는 전문가가 아니라서 요구사

항을 변경했을 때 어떤 문제가 발생하는지 몰라. 그래서 벤더는 발주자가 요구사항을 추가하거나

변경하면 어떤 위험이 따르는지 설명할 의무가 있어. 비용이 증가하면 견적을 다시 계산해서 추가

비용을 청구해야 하고.

아야네: 일단 다른 기능을 없애자고 부탁하긴 했어요.

도코: 작업량이나 품질, 재작업 가능성까지 고려해서 협의했으면 상관없지만, 실제로 그렇게 깔끔하게

끝나는 프로젝트 본 적 있니? 못하는 건 못한다, 비용 추가할 건 더 추가해야 한다고 확실히 말해

야 해.

아야네: 고객에게 그런 말을 어떻게 해요?

도코: 정말로 고객의 신뢰를 얻으려면 어떻게 하는 게 좋을지 잘 판단해. 그 정도 협상 능력도 없으면 애

초에 IT 업으로 밥 벌어먹을 생각을 하지 말아야지.

아야네: 구체적으로 어떻게 하면 돼요?

2 저자 주: 한 벤더가 공공단체로부터 업무 시스템 개발을 의뢰받았다가 납품일이 지연돼 고소당한 사건. 도쿄지방재판소에서 2004년 3월 10일 판

결이 내려졌다. 발주자가 일정에 맞춰 요구사항을 결정해주지 않은 잘못도 있지만, 벤더 또한 발주자에게 요구 사항을 철회해 달라는 요청이나 추가

비용을 설명하지 않아서 프로젝트 관리를 소홀히 했다는 판결이 내려졌다. 이런 이유로 벤더는 애초 계약한 금액보다 훨씬 적은 개발비를 받았다.

22 왜 시스템 개발만 하면 싸워 댈까?

도코: 정기적으로 요구사항 변경 문제를 논의할 회의를 여는 거야3 . 그 시기에 요구사항 변경이나 추가

요청이 들어오면 그것을 수용했을 때 어떤 이점이 있고, 어떤 위험성이 따르는지 설명하는 거지.

그리고 기간 연장이나 비용 추가, 기타 발생할 수 있는 문제점 등을 구체적으로 설명하고 협의해

야 해.

아야네: 결국 시간과 노력이 필요하단 말이군요.

도코: 사실 설계 단계에서 요구사항 변경이 나오는 건 당연한 일인데 다들 그걸 이해하지 못해. 원칙대

로라면 프로젝트 기획이나 견적 산출 단계에서 요구사항 변경 검토에 드는 비용도 고려해야 하는

데 말이야.

아야네: 그럼 경쟁입찰에 불리하잖아요.

도코: 그런 비용을 인정하지 않는 발주자와는 애초에 거래하지 않는 게 상책이야. 전략적으로 필요한 프

로젝트면 적자 볼 각오를 하고 해야겠지. 프로젝트 비용이나 수행 범위는 실무자끼리 대충 상의해

서 결정하기 어려워. 프로젝트가 엎어지면 몇 억 몇십 억을 날리게 되는 일이라 발주자와 벤더 모

두 엄청난 타격을 입게 되니까. 그럼 결국 양사의 경영에도 영향을 미칠 수밖에 없어. 요구사항 관

리를 우습게 보면 큰코다쳐.

아야네: 우습게 본 적 없어요.

도코: 아직 일 처리가 물렀어! 삭힌 홍시처럼 흐물흐물 물러터졌어. 프로젝트 계획 단계에서 요구사항 변

경에 대처하기 위한 관리 공수도 계산했어야지. 최소한 외부설계 공정이 끝날 때까지는 정례 회의

주제로 요구사항 변경 검토를 넣어야 해. 추가 변경에 필요한 견적을 일단 계산하고, 구현 가능한

지 어떻게 구현할지 선택지를 준비해서 각 장단점을 설명하고 협의해야 해4 . 다른 기능을 없애는

건 그 후에 고려할 문제야. 그리고 요구사항 정의와 설계 이후의 공정을 따로 계약하는 것도 좋아.

아야네: 고객에게 무조건 맞춰주는 게 능사는 아니란 뜻이군요.

도코: 당연하지. 난 의뢰인과 항상 싸우는걸.

아야네: 그것도 자랑은 아닌 것 같은데…….

도코: 어떤 일이든 잘하려다 보면 의견 차이로 싸울 수밖에 없어. 임시방편으로 상황을 모면하려는 태도가 오히려 더 불성실한 거야.

3 저자 주: 일본 경제산업성에서 발행한 「정보시스템 표준 거래 계약서」의 제21조 3항은 외부설계검토회의를 다음과 같이 설명한다. ‘외부설계검토회

의에서 갑이 요구사항 정의서를 검토해 내용을 바꾸려면 작업기간이나 위탁요금 등의 계약 조건(본계약과 개별계약 내용 변경)을 제33조 절차에 따

라 수정해야 한다.’

4 저자 주: 스코어링 매트릭스(scoring matrix)를 활용해 기능을 추가하면 어떤 점이 이득이고 손해인지 비교해 판단하는 것이 효과적이다.


아야네: 프로젝트 진행에는 어느 정도 배짱도 필요하다는 뜻이군요.

도코: 당연하지. 매도 먼저 맞는 게 낫다고 싸울 거면 빨리 싸우는 게 좋아. 요구사항 정의 때만 철저히

결정해두면 다른 부분은 웬만큼 순조롭게 흘러가거든.

아야네: 그런데 선배 보면 꼭 그렇진 않잖아요.

도코: 무슨 뜻이야?

아야네: 선배 남자랑 사귀면 금세 싸우고 헤어지잖아요. 그런 사람 입에서 다른 부분은 순조롭게 흘러간다

니 신뢰가 안 가요. 앗, 아야야. 선배, 아파요! 법전을 던지면 어떡해요?! 악, 사람 살려~!

◉ 발주자가 요구사항을 바꾸려고 하면 그에 따른 이점과 문제점을 명확히 설명하고 협의해서 수

용 여부를 결정한다.

◉ 기능 추가 요청이 있으면 때에 따라 추가 견적을 산출한다.

◉ 요구사항 변경이나 추가 가능성을 예상하고 그에 따른 관리 공수 비용까지 고려해서 견적을

산출한다.

CHAPTER1

POINT

요구사항 정의란 도대체 무엇인가?시스템 개발에서 요구사항 정의는 크게 세 가지로 나눌 수 있습니다. 첫 번째는 개발해

야 할 업무의 흐름과 입출력 조건을 정하는 「업무 요건」, 두 번째는 시스템이 반드시 갖

춰야 할 기능을 결정하는 「기능 요건」, 그리고 세 번째는 시스템의 속도나 용량, 사용성

과 보안 등을 정의하는 「비기능적 요건」(data chapter 1 참고)입니다. 발주자와 벤더

는 이러한 요건을 철저하게 논의해야 합니다.

개요

앞에서 아야네는 발주자가 시스템 요건을 계속해서 변경하거나 추가할 때 무엇을 주의해야 하는지 배웠

습니다. 그러나 「요구사항 정의」라는 업무가 구체적으로 어떤 것인지 아직 감을 잡지 못한 듯합니다.

아야네: 선배, 요구사항 정의에서는 구체적으로 뭘 결정해야 하는 거예요?

도코: 그걸 다 설명하려면 책 한 권은 써야 해.

아야네: 대략적으로라도 좋으니까 가르쳐주세요. 그걸 모르면 선배가 하는 얘길 앞으로도 좇아갈 수 없을

것 같단 말이에요.

도코: 안 좇아와도 돼. 그보다 너 앞으로도 계속 나한테 공짜 상담할 생각이야?

아야네: 귀여운 후배가 힘들 때 도와주는 건 당연한 일이잖아요. 안 그래요?

도코: 하나도 안 귀엽거든. 하지만 네가 앞으로도 그런 초보적인 질문을 하면 나만 귀찮으니 간단하게

알려줄게.

아야네: 앗싸! 잘 부탁합니다.

도코: 요구사항 정의 단계에서 가장 먼저 해야 하는 건 대상 업무의 처리 과정과 흐름5등을 정의하는 거

야. 예를 들어 회사에서 경비 정산을 자동화하는 시스템을 만들면 경비 정산 업무를 누가 누구에

게 의뢰하는 건지, 결과는 누구에게 확인해야 하는지 등을 전산과 상관없이 정의3 3 3 3 3 3 3 3 3

해 보는 거야.

5 저자 주: 업무 흐름을 확인하면서 나온 문제점을 시스템으로 해결할지 다른 방법으로 대처할지 판단해 시스템화할 범위를 결정한다. 도식화한 업무

흐름도에 선을 긋거나 UML 컨텍스트 맵(Context Map)을 작성하는 것이 일반적이다.

CASE 2 CHAPTER1

Requirement definition U

V


아야네: 왜 전산과 상관없이 정의해요?

도코: 사람이 하는 편이 더 효율적이고 적합한 업무까지 시스템화하면 오히려 업무에 지장을 줄 수 있거

든.

아야네: 아, 그렇군요. 옆자리에 있는 과장님께 도장 잠깐 빌려서 결재하면 될 걸 굳이 시스템에 입력해서

승인될 때까지 기다리거나, 인쇄해서 전달해도 될 문서를 일부러 사내 클라우드에 접속해 참조하

라고 할 필요는 없죠.

도코: 바로 그런 뜻이야. 엉뚱한 업무까지 시스템화하는 실수를 막으려면 전산을 생각하지 않고 업무 흐

름을 정의할 필요가 있어. 그리고 그중에서 어떤 업무를 시스템화하는 것이 좋을지 검토하는 게

철칙이지.

아야네: 이해했어요.

도코: 발주자와 벤더가 통신판매회사 콜센터 시스템 업무 요건을 정의할 때 논의한 기록이 있어. 참고될

거야.

벤더: 콜센터 업무는 크게 봤을 때 고객에게 전화로 주문을 받아서 주문표를 작성하고 물류팀에 전

달하는 것이죠?

발주자: 맞아요.

벤더: 그중에서 시스템화할 건 걸려온 전화번호 정보로 고객정보를 호출해 모니터에 보여주는 거

죠? 주문표 작성은 필요 없으세요? 같은 화면에서 작성할 수 있게 할 수 있는데.

발주자: 그건 필요 없어요. 오히려 사용이 복잡해지기만 할 것 같아서 범위에 넣지 않았어요. 그보다 전

화를 건 사람의 정보를 통신사에서 받아서 시스템에 이용할 수는 없나요?

벤더: 기술적으로는 가능하지만, 특수 장비를 도입해야 해서 초기비용이나 부대비용이 많이 늘어날

거예요. 정보입력 업무에서 절감한 비용으로 대체한다고 해도 시스템화 목적인 비용 절감과

맞지 않고요.

도코: 콜센터 업무 흐름을 확인하고 시스템화 범위를 어떻게 정하는지6 알겠지? 중요한 건 시스템화를

왜 하기로 했는지 목적을 잘 생각해서 그에 맞지 않는 요구사항은 과감히 정리하는 거야. 얼핏 들

으면 통신사에서 개인정보를 받으면 편할 것 같지만 “비용 절감”이라는 목적에 맞지 않으니 빼버

리는 거야. 이런 게 중요해.

6 저자 주: 업무 흐름을 확인하면서 나온 문제점을 시스템으로 해결할지 다른 방법으로 대처할지 판단해 시스템화할 범위를 결정한다. 도식화한 업무

흐름도에 선을 긋거나 UML 컨텍스트 맵을 작성하는 것이 일반적이다.


아야네: 하긴 얘기하다 보면 처음 목적을 잊어버리는 일이 자주 있긴 해요. 업무 요건 정의는 웬만큼 알겠

어요.

도코: 시스템화할 범위를 포함해 업무요건이 어느 정도 분명해지면 시스템에 필요한 기능을 검토하는

기능 요건 정의에 들어가.

아야네: 기능 요건 정의요?

도코: 시스템에 어떤 정보를 입력하고 어떤 연산 과정을 거쳐 어떤 정보를 어디에 출력할 건지 업무요건

을 기준으로 정하는 거야7 . 이 콜센터 시스템의 표면적인 요구사항은 “고객정보 검색 기능” 하나

뿐이야. 콜센터 직원이 컴퓨터 화면에 고객 전화번호를 입력하면 그 값을 기준으로 기존 고객데이

터를 검색하고 해당하는 고객의 모든 정보를 화면에 표시해 주는 기능이지.

아야네: 굉장히 단순하네요.

도코: 단순한 시스템 같아도 직원 권한을 관리하는 기능이나 보안, 운용 관련 기능 등이 필요해. 하지

만 그 설명은 생략할게. 기능 요건은 시스템에 꼭 필요한 기능을 구체적으로 결정하는 단계라서 여기에 빠진 항목이 생기거나 잘못 이해한 부분이 있으면 분쟁의 직접적인 불씨가 될 수 있으니 매우 신중해야 해. 무슨

일이든지 시스템화하는 목적을 가장 먼저 생각하고, 앞서 말한 업무요건 정의와 비교해서 합목적

성, 합리성, 타당성, 다양성, 정확성 등을 검토해 진행해야 해. 발주자와 벤더가 기능 요건 체크리

스트를 만들어 논의하는 게 중요해. 모든 프로젝트 과정 중에 가장 중요한 부분이니까 귀찮더라도

대충 하지 말고 확실하게 정의해야 해.

아야네: 그 밖에 “비기능적 요건”이라는 것도 있죠?

도코: 아까 말했던 콜센터 시스템이 전화번호를 입력하고 데이터가 표시될 때까지 5분이 걸리면 시스템

목적을 달성했다고 할 수 없잖아? 마우스밖에 안 쓰는 콜센터 직원에게 키보드 입력을 강요하는

시스템 역시 사용성이 떨어져서 제대로 만들었다고 할 수 없어. 시스템을 만들 때는 반응 속도나

데이터 용량 등의 성능 요건과 사용자가 쉽게 쓸 수 있게 사용성을 고려해야 해. ‘이 화면 표시는

30초 이내로 한다.’거나 ‘이 화면은 마우스만으로도 작동할 수 있게 한다.’처럼 기능 이외에 시스템

이 반드시 갖춰야 할 성능과 특성을 비기능적 요건으로 정의해 두는 거지.

아야네: 기능만 생각하며 만들다가는 잊어버리기 쉽겠어요.

7 저자 주: 은행 ATM에서 예금을 출금하는 기능을 예로 들면 “출금금액 입력 화면을 표시”, “금액입력 접수” 등이 입력에 해당한다. 그리고 입력한 금

액이 예금잔고보다 적은지 확인하는 작업이 연산에 해당하며, 연산 결과에 따라 출금을 결정하고, 기계에 출금 명령을 내려 통장과 장부 데이터를 고

치고 처리 종료 화면을 표시하는 것이 출력이다.


도코: 실제로 비기능 요건을 잊어버려서 대형사고가 나는 일도 상당히 많아. 기능 요건이야 프로그램을

수정하거나 추가하면 어떻게든 마무리가 되잖아. 성능 요건 같은 건 수억 원에서 수십억 원 하는

하드웨어를 쓸모없게 만들 수 있어서 진짜 조심해야 해.

아야네: 반품할 수도 없을 테니까요.

도코: 그 밖에 비기능적 요건에는 내구성, 보안 등 굉장히 여러 가지 항목이 있어. 그중에는 발주자가 아

는 것과 벤더가 아는 것이 섞여 있어서 양사가 무릎을 맞대고 앉아 철저히 논의하지 않으면 빠진

항목이 생겨 큰 사고로 이어질 수 있으니 정말 조심해야 해. 요구사항 정의에서 결정해야 하는 항

목은 69쪽에 실린 ‘비기능적 요구사항 개요’를 잘 보고 공부해둬.

◉ 업무요건을 검토할 때는 전산 시스템을 생각하지 않는다.

◉ 요구사항은 시스템화하는 목적에 맞는지 판단해서 채택한다.

◉ 요구사항 정의는 발주자와 벤더가 철저하게 논의해서 결정해야 한다.

CHAPTER1

POINT

발주자가 요구사항 정의를 벤더에게 전담할 때요구사항 정의 단계에서 시스템에 필요한 기능과 성능 요건을 올바르게 도출하려면 벤

더의 기술적인 안내와 사업자 사이의 역할을 초월한 논의가 필요합니다.

개요

아야네는 ‘진흙탕 프로젝트’에서 벗어나 새로운 프로젝트를 맡게 됐습니다. 이번 발주자는 모든 요구사항

정의를 벤더에게 맡긴 덕에 개발이 순조롭다며 아야네는 상당히 즐거워했습니다. 하지만 도코는 예전에

담당했던 분쟁 사건의 발주자와 비슷하다며 충고합니다.

아야네: 이번 고객은 무조건 동작하기만 하면 된다며 모든 요구사항 정의를 우리에게 맡겨서 정말 편해요.

그냥 우리 마음대로 하면 되거든요. 그래서 오늘은 오랜만에 미팅 나가려고 하는데 선배도 갈래

요? 어차피 저녁에 할 일도 없잖아요.

도코: 인류를 위해서 내 언젠가 그 요망한 혀를 뽑아주겠어.

아야네: 무, 무슨 인류씩이나.

도코: 그런데 조심해. ‘저희는 아무것도 모르고 그저 벤더에게 맡겼습니다.’는 말은 법정에서 제일 자주

듣는 말이야.

아야네: 그래도 물어보면 답변도 잘해주고, 우리가 정한 요건을 보여주면 금세 이해해주는 고객인걸요.

도코: 관여 안 하는 고객이 ‘좋은 고객’이란 생각은 네가 ‘난 귀여워’라고 떠드는 것만큼 큰 착각이야.

아야네: 뜬금없이 제 얘기가 왜 나와요!

도코: 뇌는 금붕어 수준인데 미니스커트에 서클렌즈 끼고 남자들에게 끼부리면 다 넘어올 거라는 얄팍한

계산속이 아주 훤히 보이거든. 하긴 그런 여자 좋다고 침 흘리는 남자들이 있으니 더 짜증 나지만.

아야네: 선배, 혹시 욕구불만이에요?

도코: ……어디 장도리 없나.

아야네: 아우 왜 또 그래요. 그런데 관여 안 하는 고객이 왜 안 좋아요?

CASE 3 CHAPTER1


V


도코: 내가 담당했던 사건 중에도 그런 사례가 있어. 대출 신청자의 융자 이력을 외부 정보회사에서 받

아 대출금액을 결정하는 금융기관 시스템8 개발 건이었는데, 발주자는 벤더의 실적만 보고 믿고

맡겼던 거야.

아야네: 발주자는 벤더의 실적을 가장 믿죠.

도코: 그런데 뚜껑을 열어봤더니 정보관리회사에서 넘어오는 융자 이력 데이터 형식이 생각했던 것과

전혀 달라서 새로운 시스템에서 도저히 이용할 수 없는 거야. 데이터 구분값이나 문자코드가 완전히

달라서 그대로 연계해봐야 외계어처럼 출력되거나 행이 다 깨져서 알아볼 수 없게 될 상황이었어.

아야네: 저런.

도코: 심지어 그 사실을 설계가 다 끝날 무렵에 안 거야. 뒤늦게 데이터 변환 방법부터 새로 검토해야 하

니 계획은 엉망진창이 됐지. 요구사항 정의며 설계, 테스트 계획까지 전부 고쳐야 해서 일정도 엄

청나게 늦어질 수밖에 없었어. 어떻게든 납품일에 맞추려고 허둥대다 보니 테스트나 리뷰도 제대

로 안 한 오류투성이 시스템이 만들어진 거야. 글자 깨짐, 행간 깨짐, 처리 중단 등등 문제가 한두

개가 아니었어. 발주자도 그제야 노발대발 난리가 났지.

아야네: 정말 난리였겠어요.

도코: 벤더는 ‘데이터가 매우 특수했다’고 말했지만, 발주자는 ‘문외한인 우리가 그걸 어떻게 아느냐. 애

초에 요구사항 정의서에도 없던 변환 프로그램 따위를 멋대로 만들어서 이 사달이 났으니 전적으

로 벤더가 잘못했다’며 길길이 날뛰었어.

아야네: 그 상황에선 발주자가 확실히 피해자네요.

도코: 그건 아마추어적인 생각이야. 이 분쟁의 원인은 발주자의 ‘알아서 해주세요’와 벤더의 ‘맡겨주세요’

가 더해진 합작품이야.

아야네: 합작품요?

도코: 그래. 발주자는 상세한 입력정보를 직접 확인하지 않았고, 벤더는 리뷰도 안 하고 멋대로 해석해

시스템을 만들었으니까.

아야네: 우린 그렇게 대충 일하지 않아요. 지금 발주자도 그렇게 얼렁뚱땅하지는…….

도코: 너희가 만든 요구사항 정의서를 발주자가 제대로 검토하고 확정해줬어? 실제 업무 흐름에 대입해

서 각 기능을 시뮬레이션하거나, 연계해야 할 시스템 담당자와 혹시 모를 위험요소는 논의했어?

사용성이나 처리 속도와 관련된 협의는?

8 저자 주: 흔히 말하는 「신용정보관리시스템」이다. 외부 신용정보관리사에서 대출희망자의 금융 거래 이력과 정보를 조회해 현재의 수입을 비롯한 담

보물 유무와 재산 종류, 보증인 정보 등을 바탕으로 대출 가능 금액(신용대출금액)을 산출한다.


아야네: 아니요. 거기까진…….

도코: 벤더는 그런 요소를 하나하나 점검하고 요청해야 할 의무가 있어.

아야네: 그런 건 발주자가 자발적으로 해야 하는 일 아니에요?

도코: 무슨 어처구니없는 소리야! 개발 경험이 적은 발주자가 요구사항 정의 단계에 뭘 해야 하는지 알 리가 없잖아. 그런 걸 “개발자식 발상”이라고 하는 거야. 발주자에

게 반드시 확인을 요청해야 해!9

아야네: 뭘 그렇게 깐깐하게.

도코: 벤더는 발주자가 결정해야 하는 모든 사항을 안내하고, 일정대로 끝날 수 있게 관리해야 해.

아야네: 제가 본 책에서 요구사항 정의는 발주자 책임이라고 나왔었는데요.

도코: 그건 결정한 요건을 책임져야 한다는 뜻이지, 뭘 결정해야 하는지는 전문가인 벤더가 알려줘야 해.

세상엔 ‘벤더의 지시 따위 안 받겠다’는 오만한 발주자도 있지만, 그래도 역시 여러 가지 시스템 개

발 경험이 있는 벤더가 더 다양한 지식을 갖고 있잖아. 발주자는 벤더의 경험치를 무시해선 안 되

고, 벤더 역시 자신들의 전문성이 무시당하는 걸 모르는 척해서는 안 돼. 일전에 가르쳐준 요구사

항 정의 항목을 참고로 너희가 꼼꼼히 관리해.

아야네: 그렇군요.

도코: 한 가지 덧붙이자면, 요구사항 정의를 할 때만큼은 각자의 역할에 얽매이지 말아야 해.

아야네: 얽매이지 말라니 무슨 뜻이에요?

도코: 서로 고려할 사항이 있으면 허심탄회하게 이야기해야만 완전성을 확보할 수 있어. 벤더가 사용자

입장을 고려하지 않고서 ‘화면 반응 속도가 느린데 괜찮을까?’라는 문제를 제기할 수 있겠어? 마

찬가지로 발주자 역시 벤더가 기한 내에 많은 기능을 만들 수 있는지 고민해 봐야 해. 한마디로 요

구사항 정의를 제대로 하려면 팀 전체가 이해할 때까지 논의해야만 한다는 뜻이야.

아야네: 팀요?

9 저자 주: 2004년 3월 10일 도쿄지방재판소 판결. ‘Y(공급자)는 수급자의 의사결정이 필요하면 (중략) 구체적인 과제와 기한을 제시하고, 결정해 주

지 않을 때 발생할 수 있는 문제점을 설명해야 한다. 여러 가지 선택지 중 하나를 선택해야 하면 각 장단점을 밝혀 기한 내에 X(수급자)가 결정할 수

있게 이끌어야 한다.’ 이 판결문은 발주자가 의사결정을 내려주지 않아 문제가 발생했더라도 벤더 역시 책임이 있음을 뜻한다.


도코: 프로젝트마다 조금씩 다르지만 요구사항을 정의하고 관리하는 책임자와 주요 개발 팀원, 업무 프

로세스 전문가, 발주처 담당자, 최종 사용자, 운용담당 그리고 관련된 외부 시스템 담당자까지 포

함해 모두 한 팀이야. 시스템화하려는 업무와 관련된 모든 사람의 의견을 수집하는 게 중요하니까.

회의에 직접 참여하기 어려울 때는 설문 형식으로라도 의견을 모아야 해.

아야네: 역할분담에 집착하면 안 되겠군요.

도코: 한 설문 조사10에 의하면 프로젝트 실패 원인의 90%가 요구사항 정의와 관련이 있대. 그러니 어

려운 건 당연한 일이야.

아야네: 왠지 슬슬 걱정되네요. 오늘 미팅 나가지 말까.

도코: 어머, 별걱정 다 한다. 신경 쓰지 말고 다녀와.

아야네: 네?

도코: 지금 실컷 놀아놓고 나중에 프로젝트 망가지면 그때 피 토하며 머리 싸매면 되지. 호호호. 아하하

하하하.

아야네: 서, 선배. 삐뚤어진 성격은 여전하네요.

10저자 주: 정보처리추진기구 소프트웨어 엔지니어링 센터에서 발표한 「설문조사보고 2005/6/29-1/1 SODEC의 조사결과」에 기재된 내용

◉ 벤더는 발주자가 결정해야 할 사항과 미리 조사해야 할 내용을 적극적으로 안내한다.

◉ 요구사항 정의는 각자의 역할을 떠나서 철저히 논의한다.

◉ 요구사항을 정의할 때는 가능한 한 업무와 관련된 모든 사람이 참여한다.

CHAPTER1

POINT

소프트웨어 패키지의 함정 ①소프트웨어 패키지는 시스템화 대상 업무의 기본 기능을 갖추고 있어 간단한 설정과 추

가 프로그램 설치만으로 사용할 수 있어서 비용이나 품질면에서 매우 유용합니다. 그러

나 자사의 업무 시스템에 맞지 않는 소프트웨어를 도입해서 분쟁이 생기는 일도 대단히

많습니다.

개요

도코는 의뢰인인 대형 유통회사에 방문했다가 우연히 사장의 장남인 나리카네 쇼스케와 재회합니다. 쇼스

케는 온라인 쇼핑 시스템 개발을 맡았다며 매우 기뻐하지만 도코는 소프트웨어 패키지를 이용한 개발에

어떤 위험요소가 있는지 충고합니다.

쇼스케: 도코, 도코 맞지? 나야 나. 옛날 남자친구도 잊은 건 아니겠지?

도코: 옛날 남자친구는 무슨. 그런데 현장 업무 수행하러 간 거 아니었어?

쇼스케: 수행? 벌써 하고 왔지. 시코쿠 시에 있는 마루가메 매장에서. 계산대부터 물류 관리 일까지 다 했

어. 그랬더니 점장이 이제 나한테 더 가르쳐 줄 게 없다잖아.

도코: 하도 일을 못 하니까 방해하지 말고 빨리 돌아가라는 뜻이었겠지. 그래서? 이번엔 어느 부서를 괴

롭히는 중이야?

쇼스케: 시스템 기획실에 있어. 이번에 우리 회사도 온라인 쇼핑몰을 만들려고 하거든. 내가 총책임을 맡게

됐어.

도코: 괜찮겠어? 온라인 쇼핑몰은 많은 데이터를 한 번에 처리해야 해서 정보 처리 속도도 중요하고 1엔

이라도 틀리면 큰일나서 정확성이 무엇보다 중요하잖아. 게다가 컴퓨터나 스마트폰 사용을 잘 못

하는 고객까지 고려해야 해서 굉장히 복잡한 시스템일 텐데.

쇼스케: 괜찮아, 괜찮아. 내가 잘 아는 개발 회사에서 소프트웨어 패키지라던가? 아무튼 온라인 쇼핑몰용

으로 만들어진 소프트웨어가 있다고 그걸 가져와서 우리 회사에 맞게 고치면 금세 만든대.

도코: 과연 괜찮을까? 소프트웨어 패키지를 잘못 도입해서 실패하는 사례가 하도 많아서 말이야.

쇼스케: 그래?

CASE 4 CHAPTER1


V


도코: 얼마 전에도 그런 일이 있었어. 학생 수가 몇만 명은 되는 대학교에서 학생들의 수강신청을 웹으

로 접수할 수 있는 시스템을 만들려고 소프트웨어 패키지를 도입했는데 그 소프트웨어가 학교 규

모에 대응하지 못해서 실패하고 말았어11 .

쇼스케: 대응을 왜 못해?

도코: 한 학생이 수강신청을 하면 그 사이에 다른 학생이 똑같은 과목을 신청하지 못하게 막아야 하는데

그러지 못한 거야. 전문용어로 배타 제어라고 해.

쇼스케: 동시에 등록할 수 있게 하면 안 돼?

도코: 그랬다간 50명이 정원인 강의를 100명이 동시에 신청할 수도 있잖아. 학생 수가 적은 학교라면

몰라도 몇만 명이나 되는 대학교의 인기강의는 수강신청 기간에 접속이 집중돼서 동시 등록이 가

능해지면 굉장히 곤란해.

쇼스케: 그럼 소프트웨어를 고치면 되잖아?

도코: 문제는 바로 그거야. 소프트웨어 패키지란 건 한 가지 소프트웨어를 만들어 많은 사람에게 저렴한

가격으로 제공하는 비즈니스라 개별 대응은 웬만해서 잘 안 하거든. 데이터 배타 제어를 해주면

되지만 일일이 응대하다 보면 개발회사가 적자를 볼 수 있어서 좀처럼 해주려 하지 않아.

쇼스케: 그래도 결국엔 개별적으로 대응해줘야 하는 거 아니야?

도코: 그래서 소프트웨어 패키지는 대부분 프로그램을 고치지 않고 설정만 고쳐서 출력항목을 바꾸거나

소프트웨어에 없는 기능은 부가기능을 설치하는 수준에서 지원해줘.

쇼스케: 흠. 그런 방법을 쓰다니 머리 좋네.

도코: 너랑 비교하면 모든 영장류가 천재지. 그렇다고 자세히 이해할 필요는 없어. 소프트웨어 패키지가

업무 성격에 따라 어느 정도 고칠 수 있다는 것만 알면 돼.

쇼스케: 그럼 문제없잖아.

도코: 어느 정도 선에서 고칠 수 있다는 말이야. 즉 한계가 있다는 뜻이지. 너희 회사 제품 중에 채소에

생산농가 이름 표시하는 것 있지?

쇼스케: 응. 굉장히 평판이 좋아. 생산자별 매상 분석도 가능해서.

도코: 그럼 상품 데이터를 관리할 때 상품별 생산자 명도 입력할 수 있어야 하잖아? 네가 도입하려는 소

프트웨어 패키지에 그런 독자적인 항목을 추가할 수 있는지 확인해 봤어?

11 저자 주: 2010년 1월 22일 도쿄지방재판소에서 판결이 내려진 실제 사건. 어느 학교법인 시스템 개발 프로젝트에서 발주자가 학교 규모를 고려해

특별한 지시를 내리지 않은 바람에 과부하 등의 문제가 발생해 시스템이 작동하지 않았다. 그러나 재판소는 ‘새로운 시스템은 여러 학부에서 수많은

관계자가 동시에 접속할 수 있다는(중략) 전제로 만들어진 것이기에 피고가 구체적으로 지시하지 않았더라도 원고는 상세설계를 맡은 이상 시스템

의 적합성을 분석하고 해당 기능을 추가하거나 커스터마이징해 대응했어야 한다.’며 벤더에게도 일정한 책임이 있다는 판결을 내렸다.


쇼스케: 모르겠네. 겨우 항목 하나 추가하는 건데 아까 말한 설정을 고치면…….

도코: 그렇게 간단하지 않아. 화면이나 장표처럼 단순히 출력하는 항목만 바꾸는 건 설정으로 어떻게 되

지만 상품 데이터처럼 시스템 내의 산더미 같은 프로그램 속에서 호출하는 데이터 설정을 고치는

건 굉장히 많은 프로그램을 수정해야 하거든. 소프트웨어 개발 회사도 쉽게 고쳐주지 않을 거야12 .

설령 고쳐준다고 해도 수억 원의 비용을 요구할 거야.

쇼스케: 그럼 어떻게 되는데?

도코: 생산자별 상품관리는 못 하게 될 테고, 업무 흐름 자체가 완전히 뒤바뀔 가능성이 커. 그럼 사내 업무 프로세스나 관련된 사람의 역할 분담까지 바뀌는 사태가 생길지 몰라.

쇼스케: 그랬다간 아빠가 때려죽이려 할 텐데. 어떡해야 해? 소프트웨어에 무슨 문제점이 있는지 처음엔

모르잖아.

도코: 도입을 결정한 소프트웨어라도 문제점을 발견하면 고집하지 말아야 해. 괜찮아 보여서 결정한 소

프트웨어라도 꼼꼼하게 조사해 보면 업무 방법을 바꿔야 하거나 구상했던 시스템화 방법이 다르

거나 하는 문제가 발견되기도 하거든. 여러 소프트웨어 패키지를 동시에 평가해서 가장 나은 것을

고르고 나머지는 여차했을 때의 대안으로 마련해 놓는 게 좋아.

쇼스케: 대안으로 마련해 놓는다고?

도코: 벤더에게 자료와 평가용 소프트웨어를 미리 준비시켜놓고, 채택이 가장 유력한 패키지에서 문제

점이 발견됐을 때 준비해둔 다른 패키지를 조사하는 거지.

쇼스케: 그럼 초반에 소프트웨어 비용을 낭비하게 되잖아.

도코: 그건 벤더나 개발회사와 교섭해야지. 벤더가 가져온 소프트웨어로 발주자가 요구했던 기능을 구

현하지 못해서 ‘소프트웨어 패키지에 그러한 기능이 애초부터 없었던 것과 가동해야 할 시기까지

만들어내지 못한 것은 하자로 간주한다’는 판결13이 나온 적도 있어. 잘만 교섭하면 비용은 안 들

수 있어.

쇼스케: 아, 그렇구나. 다행이다.

도코: 모자라긴. 그런 상황을 생각하기 전에 발주자가 벤더와 함께 위험요소를 찾아내 대책을 세울 생각

을 해야지. 소프트웨어 패키지 도입은 일반적인 개발과 달리 여러 가지 위험요소가 많아서 특별히

더 조심해야 해.

12 저자 주: 소프트웨어 패키지 개발 회사는 기술적으로 가능해도 ‘DB 구조를 바꾸면 다른 프로그램에 영향을 줄 수 있어 안정성을 보장할 수 없다’거나

‘DB 구조는 지적 재산에 해당하는 것이라 공개적으로 밝히고 고칠 수 없다’는 이유로 대응해 주지 않는 곳이 많다.

13 저자 주: 도쿄지방재판소 2010년 1월 22일 판결. 학교법인 시스템 개발 관련 판례. 벤더가 가져온 소프트웨어 패키지에 배타 제어 기능, 오류 관리

기능이 없어서 ‘해당 소프트웨어 패키지에 이러한 기능이 애초에 없었고, 사용 직전까지 만들어내지 못한 것은 하자에 해당한다’는 판결을 내렸다.


쇼스케: 흠. 우리 벤더도 지금 추천한 소프트웨어보다 더 좋은 제품은 없다고 했지만 정말 그런지 알 수 없

는 거네.

도코: 지금 제안한 소프트웨어를 혹시라도 적용할 수 없으면 어떻게 할지 물어봐. 그래야 벤더도 당당하

게 다른 소프트웨어를 검토할 수 있거든. 깐깐하게 보일지 몰라도 그게 오히려 친절한 행동이 될

수 있어. 많은 벤더가 특정 소프트웨어를 고집하다가 자멸했거든. 그런 사태가 벌어지기 전에 벤더

도 자신을 보호할 수 있는 대안을 준비해 둬야 해.

쇼스케: 하긴 나중에 소프트웨어에서 문제점이 발견되면 벤더가 더 힘들 테니까.

도코: 그리고 적합성 분석과 개발 및 도입 작업, 패키지 구매 단계로 분리해서 계약하는 게 좋아.

쇼스케: 계약서를 세 개나 만들라고?

도코: 그렇게 계약하면 적합성 분석 후에 패키지 구매나 도입 방법 등을 쉽게 바꿀 수 있잖아.

쇼스케: 그렇겠네. 영 쉬운 일이 아니네.

도코: 고생은 그다음부터야. 방금 말해준 건 패키지를 도입할 때 고려해야 하는 가장 기본적인 사항이야.

더 중요한 건……. 앗, 회의 시간 다 됐네. 나중에 다시 말해줄게.

쇼스케: 더 자세히 가르쳐줘. 오늘 저녁 식사라도 같이 하면서 얘기할까?

도코: 89년산 샤토 페트뤼스14라도 사주면 갈게.

쇼스케: 알았어. 바로 준비할게.

도코: ……뭣?

14 역자 주: 샤토 페트뤼스 로마네콩티와 함께 프랑스산 최고급 와인으로 유명한데 특히 1989년산 와인은 미화로 약 3만 8천 달러(한화 4천만 원)를

호가한다.

◉ 벤더는 제안한 패키지가 업무에 적합하지 않을 때를 대비해 대안을 준비한다.

◉ 적합성 분석과 소프트웨어 구매, 개발, 도입 작업을 따로 분리해서 계약하는 게 유리하다.

CHAPTER1

POINT

소프트웨어 패키지의 함정 ②소프트웨어 패키지 도입에는 벤더의 기술력이 부족하거나 실제 업무에 소프트웨어가

맞지 않는 등의 위험요소가 늘 도사리고 있습니다. 발주자와 벤더는 문제에 직면했을

때 서로의 상황과 처지를 적극적으로 공유하고 허심탄회하게 논의해야 합니다.

개요

도코는 자칭 “전 남자친구”라고 주장하는 쇼스케와 식사를 하게 됐습니다. 도코의 말투는 까칠했지만 천

하태평인 쇼스케가 걱정돼 낮에 얘기했던 소프트웨어 패키지를 도입했을 때 주의해야 할 사항을 일러줍

니다.

도코: ……나 원 참. 그냥 한 말인데 진짜 샤토 페트뤼스가 있는 레스토랑에 데려오다니. 도대체 너희 집

얼마나 부자야?

쇼스케: 괜찮아. 아빠가 너랑 저녁 먹는다니까, ‘걔는 입이 고급이니까 절대로 쩨쩨하게 굴지 마’라고 하셨

어.

도코: 왠지 너희 아버지가 날 굉장히 오해하고 계신 것 같은데…….

쇼스케: 소프트웨어 패키지를 도입할 때 뭘 더 주의해야 해?

도코: 아 참 그렇지. 가장 주의할 점은 벤더의 기술력이야.

쇼스케: 기술력? 벤더가 직접 소프트웨어를 제안했으니 수정할 기술력은 당연히 보유하고 있지 않겠어?

도코: 꼭 그렇지만은 않아. 보통 발주처로 파견 나가는 개발자는 여러 시스템을 다루다 보니 전문 기술

력이 없는 사람이 많거든. 전문 기술력이 있는 개발자는 워낙 여기저기 부르는 곳이 많아서 한 프

로젝트에 딱 붙어 있지 못하고 겸업하는 일이 많고.

쇼스케: 인기 많은 사람은 어딜 가나 고생이구나. 내가 그 마음 잘 알지.

도코: 패키지를 제안한 벤더에 기술력이 없으면 정말 힘들어. 별로 어렵지 않은 걸 물어봐도 1주일 넘게

답변을 안 주기도 하고, 발주자 업무에 맞게 소프트웨어를 고쳐야 할 때도 추가 장치가 필요한 건

지 설정을 바꿔야 하는지 몰라서 헤매거든. 기능을 약간 고치기만 하면 쓸 수 있는 소프트웨어라

도 잘못 고쳐서 아예 못 쓰게 만들어버릴 위험성도 있어.

CASE 5 CHAPTER1


V


쇼스케: 그럼 도입에 성공한 회사들은 어떻게 한 거야?

도코: 가장 이상적인 건 소프트웨어를 개발한 회사의 기술자가 프로젝트에 참가하는 거야. 소프트웨어

의 내부까지 잘 아는 사람이 처음부터 함께하면 실패할 확률이 훨씬 낮아.

쇼스케: 현실적으로 그러긴 어렵지 않아?

도코: 벤더와 발주자끼리 성공한 프로젝트도 있긴 해. 한 금융회사에서 서버 운용 관리 시스템15을 도

입했는데, 세계적으로 유명한 소프트웨어였지만 해외 제품이라 벤더에도 기술력이 있는 사람이

없었어.

쇼스케: 그럼 도입하기 어렵지 않아?

도코: 1주일에 한 번 지원해줄 개발자를 찾긴 했지만 도저히 그 사람에게 개발 책임자 역할을 맡길 순 없

었어. 벤더는 어쩔 수 없이 서버 운영 업무를 잘 알고, 서버 기기 조작법을 웬만큼 아는 인력을 충

원했어.

쇼스케: 그런 식이면 고객이 만족 못 하지 않아?

도코: 처음엔 그랬지. 그런데 벤더가 처음부터 솔직하게 상근 인력에 전문 기술력이 없다는 사실을 밝혔

어. 대신에 프로젝트 진행에 맞춰 개발자를 교육하는 기술력 향상 계획을 세워 제시했어.

쇼스케: 기술력 향상 계획?

도코: 소프트웨어 개발회사에서 시행하는 교육을 받게 하는 거지. 그리고 주 1회 지원해주는 개발자에게

기술교육을 부탁하고, 소프트웨어 개발회사에는 24시간 대응할 수 있는 창구를 마련해달라고 했

어. 그렇게 일정에 맞춰 기술력을 높여가며 진행할 수 있다는 걸 논리적으로 설명했어.

쇼스케: 그래서 어떻게 됐어?

도코: 발주자는 벤더 책임자와 지원 개발자의 인격을 믿고 상사와 패키지 개발 회사와 상의하고 나서 기

술력 향상이 가능하다고 판단했어.

쇼스케: 대단하다.

도코: 하지만 그게 다가 아니야. 발주자도 함께 배우겠다고 나섰어. 전부 이해하긴 어렵겠지만 하다못해

소프트웨어의 표면적 기능이라도 제대로 이해하면 나중에 도움이 될 거라고.

쇼스케: 존경스럽다.

15 저자 주: 조직 내에 도입한 서버의 가동 상태나 건전성을 감시하고 전력공급이나 셧다운 등 여러 가지 작업을 일괄 처리하는 시스템


도코: 그 결과 성공적으로 시스템을 도입할 수 있었어. 물론 도입 과정에서 옥신각신하긴 했지만 문제가 발생했을 때 발주자와 벤더가 솔직하게 해결책을 논의할 수 있는 환경과 지식을 갖고 있었다는 게 성공의 열쇠였지.

쇼스케: 과부 설움은 홀아비가 아는 것처럼?

도코: 그거랑은 좀 다르지만……. 어쨌든 벤더가 기술정보를 공개할 줄 아는 마인드를 가졌고, 발주자가

포용력과 책임의식이 있어서 성공한 사례로 볼 수 있어.

쇼스케: 그 벤더도 대담하다. 자칫 잘못하면 고객이 화낼 수도 있는 상황이었잖아.

도코: 매도 먼저 맞는 게 낫다고 생각해서 처음부터 솔직하게 말했대.

쇼스케: 그렇구나. 나도 얼마 전에 마루가메 매장에서 횟감용 생선을 깜박 잊고 냉장고에 안 넣어서 왕창

버린 일이 있는데 빨리 아빠에게 말해야겠다.

도코: 역시 너희 마트에서 물건 못 사겠다.

쇼스케: 또 주의해야 할 건 없어?

도코: 그럼 끝으로 하나 더 알려줄게. 소프트웨어가 업무에 적합하지 않을 때 해당 소프트웨어를 쓸지

다른 제품을 찾아볼지 어떻게 판단해야 할까?

쇼스케: 글쎄 잘 모르겠는데.

도코: 그 소프트웨어를 사용하면 업무 흐름이나 방법을 바꿔야 하잖아? 아까 말했던 채소 생산자 표기

나 관리를 없애야 하는 것처럼.

쇼스케: 그래. 하지만 그건 불가능해.

도코: 왜 불가능하다고 생각해?

쇼스케: 그야 생산자 표기는 우리 회사의 중요한 전략이니까…….

도코: 바로 그거야.

쇼스케: 뭐?

도코: 자사의 중요한 전략이나 시스템화를 계획했던 처음 목적에 맞지 않으면 그 소프트웨어 패키지는

사용하지 않는 게 좋아.

쇼스케: 그렇구나. 그렇게 판단하면 되는구나.


도코: 예를 들어 매장에서 사용하는 신용카드 결제 단말기의 기능을 엄청나게 향상할 수 있는 소프트웨

어가 있는데 사용법이 복잡하면 매장 직원들의 생산성은 오히려 떨어지잖아.

쇼스케: 아, 우리 회사에도 예전에 그런 일이 있었어.

도코: 매장의 생산성을 높이는 게 시스템화하는 목적이라면 아무리 고성능의 시스템이라도 사용하지 않

는 게 맞아. 반대로 상품관리나 매출 분석에 상당히 도움이 되고, 그게 경영전략과 맞으면 시스템

에 맞춰 매장 직원을 교육해서라도 도입하는 게 좋고.

쇼스케: 결국 경영 방침에 따라 판단해야겠구나.

도코: 시스템을 개발할 때 “현장의 목소리에 귀 기울여라.”라고 하는데 그건 뭐든 현장의 요구에 맞추라

는 뜻이 아니야. 경영자라면 회사 전략에 비춰 무엇을 더 중시할지 판단하고, 벤더도 그런 점을 미

리 파악해서 소프트웨어 패키지를 선정하고 대안도 마련해서 제안할 줄 알아야 해.

쇼스케: 대단하다 도코. 역시 내 전 여친이라니까.

도코: 누가 여자친구야? 달랑 영화 한 번 봤잖아!

쇼스케: 부끄러워하긴. 그럼 지금부터라도 정식으로 사귈까?

도코: 헛소리 집어치워.

◉ 벤더는 자신의 기술력이 부족할 때 객관적으로 평가하고 기술력 향상 계획을 세워 발주자와

협의해야 한다.

◉ 소프트웨어 패키지를 선택할지 말지는 발주자의 경영전략이나 시스템화 목적에 비춰 판단

한다.

CHAPTER1

POINT

확정되지 않은 요건은 어떻게 처리할까?요구사항 정의 단계가 끝날 때까지 시스템 개발에 필요한 모든 요건이 결정되는 일은 매

우 드뭅니다. 결정 나지 않은 요건은 미해결 항목으로 두고 해결담당자나 기한 등을 정

해 꾸준히 관리하는 것이 중요합니다.

개요

쇼스케는 온라인 쇼핑몰 개발 사업을 책임지게 됐지만 각 부서에서 요청하는 수많은 요구사항을 제대로

정리할 수 없었습니다. 벤더가 더는 기다리기 어렵다고 재촉하자 쇼스케는 도코에게 조언을 구합니다.

쇼스케: 도 도코, 나 좀 살려줘.

도코: 무슨 일이야? 온라인 쇼핑몰 일이 잘 안돼?

쇼스케: 큰일 났어. 요구사항 정의 기한이 벌써 석 달이나 지났는데 우리가 확정해주지 않아서 일정이 지

연된다고 벤더 담당자가 노발대발이야.

도코: 횡설수설하지 말고 자세히 말해봐.

쇼스케: 사람들이 막 이것저것 요구하는 통에 도무지 정리가 안 돼. 판촉부장은 ‘쇼핑몰에서 물건을 사면

포인트가 적립되게 해 달라’, 시스템 관리부장은 ‘신용카드 결제 시스템을 더 강화해 달라’, 게다가

영업본부장은 뒤늦게 ‘판매실적을 분석할 수 있는 기능을 만들어 달라’며 요구해서…….

도코: 예상한 요구사항보다 훨씬 많은 요청이 들어와서 고를 수 없다는 거지?

쇼스케: 게다가 매장 직원들한테 작동화면을 보여줬더니 입력해야 하는 항목이 너무 많다느니 화면이 복

잡하다느니, 글자가 너무 작다 등등 불만을 마구 쏟아내는 거야. 그러고는 결국 나보고 어떻게 해

보라고 난리잖아.

도코: 호되게 한 번 당해보는 것도 좋은 경험이 될 거야.

쇼스케: 매정한 소리 하지 말고 제발 도와줘! 어떻게 해야 해?

도코: 그야 모든 요구사항의 효과와 실현성, 단점 등을 검토해 순위를 정하고, 비슷한 기능은 하나로 묶

어야지.

CASE 6 CHAPTER1


V


쇼스케: 그럴 시간이 없어. 벤더 담당자가 당장 설계를 시작하지 않으면 오픈 날짜 절대 못 맞춘대.

도코: 아직 설계 들어간 게 하나도 없어?

쇼스케: 시스템 개발은 요구사항 정의가 확실히 정해져서 다시는 변경이 없을 때 다음 단계로 넘어갈 수

있잖아? 폭포수 모형16이라고 하나?

도코: 그렇게 진행했다가는 쇼핑몰 오픈이 사그라다 파밀리아 성당17 완공보다 늦어질걸. 모든 요구사

항이 확정될 때까지 기다리는 건 현실적으로 불가능해.

쇼스케: 그렇다고 요구사항 결정도 안 된 상태에서 진행할 수 없잖아?

도코: 지금 결정해야 하는 것과 그렇지 않은 게 있어. 방금 얘기한 것 요구사항 중에서 “포인트 적립” 같

은 건 결제와 관련된 기능이라서 다른 부분에도 영향을 미칠 수 있기 때문에 사전에 결정하고 진

행하는 게 맞지만 매장 직원들이 말한 요구사항은 화면을 설계할 때 정해도 돼.

쇼스케: 신용카드 결제 보안 기능은?

도코: 보안은 대단히 중요하지만 다른 기능에 영향을 주진 않아서 나중에 추가해도 돼. 판매실적 분석

기능은 딱히 그게 없다고 다른 기능이 안 움직이는 건 아니니 다음 단계에서 결정해도 되고. 이런

식으로 지금 꼭 결정해야 하는 것만 먼저 골라내 확정하면 요구사항 정의는 일단락할 수 있어18 .

다른 미해결 항목은 나중에 결정하고.

쇼스케: 그게 훨씬 현실적이긴 하다.

도코: 문제는 미해결 항목을 관리하는 방법이야. 미해결 항목이라고 그냥 내버려두면 안 돼. 하나하나 철

저히 관리해야 해.

쇼스케: 어떻게?

도코: 누가 언제까지 어떤 방법으로 미해결 항목을 해결할지 하나하나 정하고, 전체 진척도를 어떻게 관

리할지 정책을 세우면 돼. 그리고 미해결 항목을 기한 내에 해결하지 못했을 때 어떻게 할지 대책

을 미리 결정해 두는 거야. 발주처 책임자가 판단해서 여차하면 그 기능을 빼고 오픈할 수도 있고.

쇼스케: 뭐든 사전에 정해둬야 하는구나.

16 저자 주: 요구사항 정의 → 설계 → 개발 → 테스트와 같이 단계별 공정을 명확히 구분해 진행하는 개발 방식. 마치 폭포수와 같이 일단 ‘설계 단계’로

들어가면 이전 단계로 돌아갈 수 없어서 붙여진 이름이지만 실제 프로젝트를 진행하다 보면 어쩔 수 없이 이전 단계로 돌아가야 하는 일이 많다.

17 역자 주: 스페인 건축가 가우디가 1882년에 공사를 시작해 현재까지 작업 중인 건축물.

18 저자 주: 모든 요구사항을 Must(필수), Should(가능한 경우), Could(하면 좋은 경우), Won’t(미래에 하고 싶은 것) 등으로 분류하는 MSCoW 분

석이 유명하다.


도코: 중요한 건 미해결 항목을 해결할 사람에게 나름의 권한이 있어야 해. 임직원이 아무리 온갖 요구

를 해도 마지막에는 자신의 말을 따르게 할 수 있는 권한이 필요하거든.

쇼스케: 그럼 미해결 항목 담당자는 높은 사람으로 배정해야 해?

도코: 담당자 직위가 높지 않더라도 뒷배가 고위직이면 상관없지.

쇼스케: 그렇구나.

도코: 모든 미해결 항목을 이런 식으로 정리하고 나서 일정이나 해결담당자의 능력을 조사하고 검토에

필요한 환경 등을 모두 함께 검토해 관계자와 합의하면 요구사항 정의는 끝이야.

쇼스케: 그러면 왜 다들 그렇게 하지 않는 거야?

도코: 예전에 IT 분쟁 조정을 함께했던 엔지니어에게 물었더니 벤더 측 개발자가 그런 공정을 제대로 공

부하지 않고 무책임해서래. 최근에는 “요구사항 정의는 발주자 책임”이라는 풍조가 너무 강하게 퍼졌거든.

쇼스케: 살벌하다.

도코: 그 엔지니어는 예전에 증권회사 업무 시스템을 담당했는데 개발이 끝난 후에도 10년간 발주처에

상주했었대.

쇼스케: 우와. 그럼 뭐 그 회사 직원이나 다름없겠다.

도코: 그렇지. 일반 사원보다도 업무나 시스템적으로 잘 알아서 납품지연이나 품질저하가 얼마나 경영

에 영향을 미치는지도 잘 알아.

쇼스케: 왠지 시스템 터줏대감 같네.

도코: 맞아. 발주자가 요건을 정의하지 못해서 질질 끌면 오히려 막 화를 냈대.

쇼스케: 뭐!? 고객에게?

도코: ‘자기가 만든 시스템’에 책임감을 느끼기 때문이야. 그런 사람은 직접 간부실로 가서 요구사항을

결정하기도 해.

쇼스케: 그럼 고객이랑 사이가 나빠지지 않아?

도코: 싸우긴 해도 사이가 나빠지는 일은 드물어. 그런 벤더와 발주자가 소송까지 갔다는 얘긴 못 들어

봤어.

쇼스케: 그 벤더 전투적이긴 하지만 멋지다.


도코: “어떻게 하면 돼요?”, “언제까지 정해주실 거죠?”라며 ‘발주자에게 맡기는 개발자’와는 차원이 다

르지. 기개가 느껴지잖아.

쇼스케: 좋겠다. 우리 회사에도 그런 사람 안 오나?

도코: 그런 사람이 가면 넌 매일 욕 먹을걸.

쇼스케: 에이, 왜 또 그래.

도코: 요즘엔 시스템 개발이나 운용을 해외에 맡기기도 하고, 클라우드를 사용하면서 자체 시스템이 없

는 회사도 많아서 책임감 있는 개발자가 상당히 줄었어. 그래서 많이 아쉽다는 얘길 하더라고.

쇼스케: 고객을 혼내는 벤더라. 역시 책임감이 있으니까 화도 내는 거겠지. 앗, 그러고 보니 너도 우리 아빠

에게 그 정도 일은 직접 결정하라며 자주 화내지 않아?

도코: 비서 생일 선물이니 넥타이 색깔 같은 쓸데없는 걸 물어보니까 그렇지.

쇼스케: 혹시 우리 회사에 엄청난 책임감을 느껴서 아니야? 나중에 안방마님 자리 노리고?

도코: 무슨 헛소리야! 네 아버지 나이가 내 두 배거든.

쇼스케: 뭐? 아빠가 아니라 내 얘긴데.

◉ 미해결 항목의 관리 방침을 결정하면 요구사항 정의는 일단락된다.

◉ 미해결 항목은 해결담당자와 기한을 정해 해결될 때까지 관리한다.

◉ 벤더는 발주자를 이끌 자신감과 책임감이 있어야 한다.

CHAPTER1

POINT

벤더가 멋대로 성능 요건을 제외했을 때인터넷을 매개로 하는 시스템의 응답 속도처럼 외부 네트워크에 따라 좌우되는 성능은

장담하기 어렵습니다. 그러나 아무 계약도 하지 않으면 발주자가 손해를 볼 수 있어 위

험합니다.

개요

쇼스케는 요구사항 정의가 일단락돼 안심하고 있습니다. 그러나 그의 태평한 성격을 잘 아는 사장(쇼스케

의 아버지)은 정말로 개발이 순조롭게 진행 중인지 확인하고자 고문 변호사인 도코에게 진행상황 조사를

의뢰합니다.

쇼스케: 일부러 날 만나러 여기까지 오다니 정말 감동이야.

도코: 딱히 너 만나러 온 거 아니야. 사장님이 걱정된다고 보고 오라셔서 온 거야. 이런 건 정말 계약에도

없는 일인데.

쇼스케: 에이 부끄러워하긴.

도코: 누가 부끄러워해! 잔소리 그만하고 요구사항 정의서나 보여줘.

쇼스케: 뭐? 아아 그거? 그게 어디 있더라. 설계 단계부터는 벤더 일이니까 마음이 팍 놓여서 어디에 뒀는

지 잊어버렸어. 아아, 여기 있네. 굉장히 많은데 다 볼 거야?

도코: 봐야지. 일부러 이걸 보려고 온 건데. ……그런데 이 부분은?

쇼스케: 왜? 무슨 문제 있어?

도코: “발주자 요청서”에는 쇼핑 화면에서 상품을 골라 담은 후 장바구니에 정보가 반영되는 시간과 구

매확정 버튼을 누른 후 명세 표시 화면이 나오는 데 걸리는 시간이 “3~4초 정도”라고 쓰여 있거

든. 그런데 요구사항 정의서에는 “일반적인 쇼핑몰과 비슷하게”라고 쓰여 있어. 이건 사실상 성능

요건을 제외한 거나 마찬가지야.

쇼스케: 아, 그건 내가 벤더에게 “3~4초 정도면 좋겠다”고 했더니 “그럼 일반적인 쇼핑몰과 비슷하게 할

게요”라면서 적은 거니까, 벤더도 3~4초로 알고 있을 거야.

CASE 7 CHAPTER1


U


도코: 하지만 회의록에도 그런 내용이 없잖아.

쇼스케: 회의 때 들은 사람도 많은데 상관없지 않아?

도코: 일전에도 느꼈지만, 이 벤더 일하는 게 너무 수상해. 인터넷 화면 응답 속도는 장담하기 어려우니

까 멋대로 말을 바꿔놓은 게 분명해.

쇼스케: 어쩔 수 없지 않아? 사용자가 많으면 인터넷이 좀 느려지고 그러잖아.

도코: 물건 사는데 구매완료까지 5초가 걸릴지 10분이 걸릴지 모르면 넌 어떻게 할래?

쇼스케: 음……. 하느님께 기도하려나?

도코: 짐 싸서 어디 순례라도 다녀오지그래!

쇼스케: 하지만 인터넷이란 건 원래 좀…….

도코: 그래서 성능을 약속하지 않으면 위험하다는 거야. 인터넷 속도는 통신사와의 계약이나 송수신 데

이터의 크기를 조절해 허용범위까지 제어할 수 있고, 서버 내에서 시간이 걸리는 연산 처리는 다

양한 방법으로 해결할 수 있어. ……응? 잠깐, 그럼 세션19이나 쿠키20 관리는 어떻게 하기로 한

거야. ……역시 아무것도 검토 안 했네. 이러면 큰일 나.

쇼스케: 세션? 쿠키? 그게 뭐야?

도코: 페이지 응답 속도가 비정상적으로 길 때 세션을 제대로 끊지 않으면 그 컴퓨터로 다시 로그인하지

못할 위험이 있어. 사용자가 입력한 신용카드 번호 같은 걸 기억해 두는 장소가 쿠키인데, 정확한

타이밍에 삭제하지 않으면 카드 정보가 컴퓨터나 서버에 남게 돼.

쇼스케: 잘 이해가 안 되는데, 그러면 무슨 문제가 생기는데?

도코: 우선 고객이 상품을 장바구니에 넣고 나서 정말 장바구니에 담겼는지 확인하거나, 다음 상품을 보

기까지 수십 초가 걸릴 가능성이 있어. 고객은 그 사이에 처리가 제대로 되는 건지 불안하고 짜증

날 테고 자연스럽게 다른 쇼핑몰로 가버려서 단골이 계속 줄겠지.

쇼스케: 그, 그건 곤란한데.

도코: 더 곤란한 일은 그다음부터야. 구매 결정 버튼을 눌렀는데 처리 시간이 너무 오래 걸려 네트워크

연결 시간이 초과하면 고객은 구매했다고 생각하는데 실제로 구매가 안 될 수 있어. 그리고 컴퓨

19 저자 주: 컴퓨터 간에 데이터를 송수신하기 위한 논리적 연결. 사용자 PC가 서버에 자신을 인증하고 나면 통신을 마칠 때까지 원활하게 메시지 교환

이 이뤄지지만, 종료할 때 정상적으로 끊어지지 않으면 같은 컴퓨터로 다시 접속했을 때 문제가 생길 수 있다.

20 저자 주: 사용자 PC에 만들어지는 데이터 임시파일. 서버에 사용자가 접속하면 임시 정보를 참고해 쉽게 접근할 수 있게 돕지만 이름과 비밀번호 같

은 정보가 기록된 채 제대로 지워지지 않으면 악의를 가진 다른 사람이 참조할 수 있다.


터를 강제로 꺼서 프로그램이 비정상적으로 종료되면 구매를 결정하지 않은 상품이 발송되거나

청구될 수도 있어.

쇼스케: 그런 일이 생기면 온라인 쇼핑몰만이 아니라 매장 신용까지 떨어져버릴 거야!

도코: 자칫하면 고객이 손해배상 소송까지 할 수 있어서 금전 면이나 신용 면에서 엄청난 손해를 볼 수

있어.

쇼스케: 그런데 그런 기능은 온라인 쇼핑몰을 구축할 때 당연히 고려하는 항목 아니야?

도코: 글쎄. ‘말 안 해줘서 몰랐다’고 하는 벤더도 상당히 많아. 대형 벤더도 성능과

관련한 약속은 잘 안 하려고 하거든. 성능 요건과 그에 따른 보안 요건은 검토 및 설계, 프로그래밍

에 많은 자원이 들어가서 벤더 측면에서 보면 수익이 마이너스가 될 수 있어.

쇼스케: 우리한테 필요한 요건인데 벤더가 약속해 주지 않으려고 하면 어떻게 해야 해?

도코: 기본사항에 성능 요건을 조건부로 결정해 두는 거야.

쇼스케: 조건부?

도코: 예를 들면 같은 시스템을 인터넷에 연결하지 않고 로컬 서버에서 작동했을 때의 속도를 정의하는

거야. 그 정도면 벤더도 약속해 줄 테니까. 그걸로 시스템의 기본 성능을 일단 보장받는 거지.

쇼스케: 먼저 서버 내에서의 처리 속도를 결정해 놓는다는 거지?

도코: 그러고 나서 최대한 빨리 실제 네트워크를 연결해 검증하는 거야. 원칙적으로는 요구사항 정의 때

소프트웨어 패키지 개발회사의 테스트 서버 등을 빌려서 시행해보고 그 결과를 바탕으로 실현 가

능한 처리속도를 정의해야 하지만.

쇼스케: 결과가 나쁘면 어떡해?

도코: 그래서 요구사항 정의 단계에서 해야 하는 거야. 그 단계에선 데이터 크기나 네트워크 속도 등 여

러 가지를 바꿀 수 있고, 여차하면 소프트웨어 패키지 자체를 바꿀 수도 있으니까. 일전에 말했던

것처럼 요구사항 정의를 별도로 계약하라는21 이유가 바로 이거야. 간혹 시스템 최종 테스트 단

계에서 성능 검토를 하는데 특히 인터넷을 사용하는 시스템은 그러면 너무 늦어. 반드시 조기에

검증해야만 해.

쇼스케: 그렇군. 그나저나 겨우 문장 한 줄 바꾸는 게 이렇게 큰 변화를 줄 수 있다니 요구사항 정의란 거

진짜 무섭다.

21 저자 주: 경제산업성도 추천하는 계약 방식으로 ‘다단계 계약’이라 부른다. 발주자가 전체적인 개발 비용을 가늠하기 어렵고, 프로젝트에 착수할 때

벤더가 산출해준 견적보다 비용이 늘어날 수 있는 단점이 있지만 공정별로 벤더를 선정할 수 있다는 장점도 있다.


도코: 문장 한 줄로 몇십억을 손해 볼 수 있으니 꼼꼼하게 체크해야 해. 그런데 이번 벤더는…….

쇼스케: 문제 있어 보여?

도코: 요구사항 정의서는 계약서 첨부 문서나 다름없이 중요한 서류라 재판에서도 굉장히 중요하게 생

각하거든. 그런 문서를 스리슬쩍 자기들 편의대로 고쳐놓고, 심지어 회의록에도 명시하지 않았다

는 건 악질적인 느낌이 들어. 초기 단계에서 위약금 주고 교체하는 편이 나을 것 같아.

쇼스케: 어, 어떡해! 아빠한테 또 혼날 텐데.

도코: 아빠한테 혼나는 게 문제야! 회사 경영과 내 고문비용이 위험에 처할 상황인데 빨리 어떻게든 해!

◉ 성능 요건은 조기에 검증해 구현 방식을 검토하는 데 활용해야 한다.

◉ 발주자와 벤더는 발주자가 요청한 요구사항과 실제 요구사항 정의서에 차이점이나 빠진 항목

이 없는지 꼼꼼하게 확인해야 한다.

◉ 벤더가 멋대로 요구사항 정의서를 고치면 계약을 파기하는 것이 좋다.

CHAPTER1

POINT

요구사항 변경의 영향 범위를파악할 수 없을 때시스템의 요건, 설계, 프로그램은 서로 복잡하게 얽혀 있습니다. 그래서 상호 관계를 관

리하는 요구사항 추적표를 작성하지 않으면 수정 요청이 있을 때 그 영향 범위가 얼마나

되는지 파악할 수 없어서 분쟁이 생길 수 있습니다.

개요

아야네는 도코의 충고대로 발주자와 함께 요구사항을 다시 검토했습니다. 그런데 이미 결정한 요구사항과

설계서를 수정했을 때 어디까지 영향이 미칠지 파악하기 어려워 곤란했습니다.

아야네: 아하하하, 나리카네 쇼스케라는 분 정말 재미있네요. 전형적인 부잣집 도련님이에요. 선배에게 그

런 친구가 있는지 정말 몰랐어요.

도코: 몰라도 사는 데 전혀 지장 없는 녀석이야.

아야네: 그래도 부자잖아요? 선배에게 굉장히 호감이 있나 본데 그냥 사귀지 그래요?

도코: 나 좋다는 남자가 어디 한둘이니?

아야네: ……선배 사는 게 참 즐겁겠어요.

도코: 무슨 뜻이야! 너야말로 허구한 날 미팅에 빠져서 즐겁게 살잖아?

아야네: 매일 야근하느라 별로 그렇지도 못해요.

도코: 어이쿠, 그것참 안됐구나. 호호호호, 왜 갑자기 기분이 좋지.

아야네: 자꾸 그렇게 심술부리면 점점 결혼하기 힘들어져요.

도코: 시끄러워! 상담할 게 있으면 빨리 말해.

아야네: 알았어요. 일전에 말했던 프로젝트 있잖아요.

도코: 발주자가 무슨 말이든 다 들어준다던 프로젝트?

CASE 8 CHAPTER1


V


아야네: 맞아요, 바로 그 프로젝트요. 선배 충고를 듣고 프로젝트 매니저에게 얘기해서 고객과 요구사항을

다시 한 번 진지하게 검토했는데요.

도코: 그랬더니 여러 가지 요구사항이 나왔다?

아야네: 네. 인터넷 경매 시스템을 개발하는 프로젝트인데 진행 중인 경매만 검색할 수 있는 기능이 필요

하다고…….

도코: 그 검색 조건을 추가하면 달라지는 게 많아?

아야네: 많아요. 출품 종류와 현시점에 가장 높은 금액으로 검색하는 기능은 개발하려던 건데, 출품자 신용

도와 입찰자 이름으로 검색할 수 있게 해달라는 의견도 나왔어요.

도코: 신규 요건을 고객과 제대로 상의했어?

아야네: 네. 선배가 말해준 대로 새로운 요건을 추가할 때 필요한 비용과 위험성, 단점 등을 고객에게 설명

하고 상의했어요. 그래도 출품자와 입찰자 관리 DB 구조는 고쳐야 할 것 같아요.

도코: 고치면 되잖아.

아야네: 그렇게 되면 그 DB에 접근하는 다른 프로그램도 고쳐야 한단 말이에요.

도코: 고치면 되지.

아야네: 그걸 호출하는 다른 프로그램에도 영향이 미칠 텐데…….

도코: 밤새워서 고치면 되잖아? 수정했을 때 영향을 받는 범위를 파악하는 건 원래 힘들잖아? 호호호호.

아야네: 잘 아시면서! 프로그램이나 DB, 설계, 기능, 검수항목을 고쳤을 때 어디에 어떤 영향을 미칠지 전

혀 예측할 수 없어요.

도코: 호호호. 그렇게 여기저기에 영향을 미치는 시스템을 만드는 것 자체가 추적 가능성을 떨어뜨려 문

제를 만드는 원인이 돼.

아야네: 추적 가능성요?

도코: 각 프로그램 기능이 어떤 설계를 바탕으로 만들어졌고, 그 설계는 어떤 요구사항에 의해 만들어졌

는지 추적하는 거야. 이런 관리는 상당히 까다롭지.

아야네: 맞아요. 사실 아무도 그걸 파악하지 못하고 있어요.

도코: 쉬운 일이 아니긴 해. 요구사항과 설계, 설계와 프로그램이 일대일로 단순하게 연결된 건 아니잖

아?


아야네: 여러 요구사항에서 여러 설계가 나오고, 프로그램 역시 여러 가지로 나뉘거나 통합돼서, N대N의

그물망 구조가 돼버리니까요.

도코: 그래서 프로젝트를 관리할 때는 요구사항 추적표를 만들어야 해.

아야네: 요구사항 추적표요?

도코: 요구사항, 설계항목, 프로그램, 검수항목 하나하나에 ID를 붙이고, ID 간의 연계성을 한 장의 표로

만들어 놓는 거야.

아야네: ID 간의 연계성요?

도코: 출품자 관리 DB에 필요한 항목을 결정하려면 그것의 근거가 되는 요구사항이 있을 거잖아?

아야네: 네. ‘경매 목록을 출품자 이름으로 검색해서 화면에 표시한다’, ‘출품자는 로그인 후 이름 이외의 정

보를 수정할 수 있다’ 등의 요구사항이 있어요.

도코: 그런 요구사항 하나하나에 ID를 붙여서 출품자 관리 DB 설계서 ID와 연결해 알기 쉽게 표로 만드

는 거야. 마찬가지로 설계서 ID와 이를 바탕으로 만든 프로그램 ID, 더 나아가서 검수항목 ID도 연

계성을 알 수 있게 관리하는 거지. (71쪽 ‘요구사항 추적표’ 참고)

아야네: 그 표를 더듬어가면 수정에 따른 영향범위를 파악할 수 있겠군요.

도코: 지금 설명한 건 단순히 요구사항과 설계서를 연결하는 방법이지만 실제로는 한 요구사항이 또 다

른 요구사항을 도출하기도 하고, 설계 내용 사이에 관련성이 생기기도 해서 상당히 복잡해.

아야네: 규모가 크면 사람 힘으로는 힘들겠어요.

도코: 맞아. 그래서 규모가 큰 프로젝트는 전용 소프트웨어를 활용해야 해.

아야네: 요구사항 추적용 소프트웨어요? 소프트웨어는 비용도 많이 들고 번거로운데.

도코: 원칙대로라면 이런 비용도 프로젝트 관리비용의 일부로 견적에 넣었어야 해. ‘우리 프로젝트는 관리비용이 비싸지만 그만큼 효율적이다’라고 벤더가 발주자에게 본

인의 부가가치를 강조하는 게 좋아.

아야네: 경쟁입찰에서는 그런 식으로 말하기가 어려워요.

도코: 무조건 저렴한 걸 선호하는 발주자와는 거래하지 않는 편이 좋다고 전에도 말했지? 빌딩을 건축

하는 시공사는 작업원이 안전하게 일할 수 있게 안전망 비용을 아끼지 않아야 하고, 선박 수송을

하는 사람은 선박 보험비를 아끼지 않아야 하는 법이야. 구체적인 성과물이 보이지 않아도 필요한

건 주장해야지.


아야네: 그나저나 큰일이에요. 벌써 프로그램 개발도 일부 들어간 상태라 당장 요구사항 추적표를 그릴 수

도 없거든요.

도코: 그럼 최소한 요구사항과 시스템 테스트, 사용자 테스트 항목22만이라도 ID로 연결해둬. 최소한 가

동 후에 기능이 누락되거나 잘못되는 건 막을 수 있으니까. 그것도 어려우면 최종 사용자가 주로

사용하는 기능과 관련된 요구사항과 사용자 테스트 항목만이라도 ID로 연결해 둬. 아무것도 안 하

는 것보다는 나을 거야. 재판에서도 주로 사용하는 기능이 작동하면 시스템 완성을 인정해주는 사

례가 많거든.

아야네: 무슨 말인지 알겠어요. 그나저나 선배는 변호사인데 IT에 관해 많이 아시네요. 차라리 직업을 바꿔

보면 어때요?

도코: 싫어. 변호사가 훨씬 속 편해.

아야네: 그런 게 아니라…… 아니, 아무것도 아니에요. 아무튼 프로젝트 매니저에게 말할게요. 고맙습니다.

저 갈게요.

도코: 무슨 말 하려던 것 같았는데……. 혹시 내 의견을 반론하려던 건가?

22저자 주: 시스템 테스트와 사용자 테스트 항목은 원래 요구사항에 맞춰 작성하므로 대응 관계를 ID로 연결하기가 비교적 쉽다.

◉ 요구사항, 설계, 프로그램, 테스트 케이스는 요구사항 추적표를 이용해 쌍방향으로 추적할 수

있게 관리한다.

◉ 벤더는 발주자에게 추적 가능성 관리에 필요한 공수를 이해시켜야 한다.

CHAPTER1

POINT

발주처 담당자가 벤더와 친할 때벤더에게 악의가 있든 없든 벤더와 발주자가 친하면 벤더에게 편한 요건만 가져갈 수 있

고, 업무지식 부족으로 누락되는 요소가 생길 위험성이 있습니다.

개요

쇼스케는 도코로부터 벤더와 계약을 파기하라는 이야기를 듣고 어떤 절차로 계약을 파기할지 고민하다

도코의 사무실로 찾아옵니다. 그 밖에도 시스템 개발과 관련된 지식이 있는 사람이 사내에 없어서 누구에

게 요구사항 정의를 맡길지 고민인 듯합니다.

쇼스케: 도코, 나 왔어. 어라, 무슨 책 읽어? 『고르바초프 회상록』?

도코: 그래. 나, 이 사람 굉장히 좋아하거든.

쇼스케: 그런 대머리가 좋아? 심지어 머리에 점도 있어.

도코: 넌 어떻게 그런 것만 보니? 불치의 병이라고까지 불린 불황을 뛰어난 솜씨로 타파한 영국의 마거

릿 대처, 살벌한 공산당의 지배를 붕괴시킨 구소련의 미하일 고르바초프, 그리고 고르바초프와 함

께 동서냉전을 종결시킨 미국의 로널드 레이건, 모두 내가 진심으로 존경에 마지않는 대정치가들

이야.

쇼스케: 너 예전부터 ‘타파’니 ‘붕괴’니 하는 것 참 좋아하더라.

도코: 내 인간성을 근본적으로 오해하는 거 아니야?

쇼스케: 그렇게까지 생각하진 않지만 일전에 너가 ‘빌딩 해체 현장이 제일 흥분돼’라고 말했었잖아.

도코: 왠지 속이 시원하잖아. 커다란 건물이 와르르……. 이런 얘긴 관두자. 오늘은 일전의 그 수상한 벤

더와 계약 파기하려고 상담하러 왔지?

쇼스케: ……역시 예리해.

도코: 그러고 나서 요구사항 정의서는 제대로 조사했어?

쇼스케: 응. 조사했더니 네가 말했던 것처럼 문제가 대단히 많았어. 벤더가 가져온 소프트웨어 패키지는 외

CASE 9 CHAPTER1


U


국 제품이었는데, 우리에게 필요한 국내 판매실적 분석도 안 되고 개인정보를 주고받을 때 통신이

나 DB에 암호화도 전혀 안 했더라고. 그 밖에도 중요한 요건이 많이 빠져있었어.

도코: 그럴 줄 알았어. 그런데 너희 회사 담당자는 그렇게 많은 기능이 빠졌는데도 몰랐던 거야? 아무리

문외한이라도 판매실적 분석이 업무와 직결되는 것 정도는 알잖아?

쇼스케: 실은 우리 회사에 원래 있던 직원 중에는 시스템 개발을 알 만한 사람이 없어서 새로 채용한 사람

이었어.

도코: 그럼 요건을 더 잘 검토할 수 있는 사람이잖아.

쇼스케: 그런데 그 사람이 예전에 그 벤더에서 일했었대.

도코: 뭐라고? 그럼 설마 벤더와 발주처 담당자가 옛날 동료였단 말이야?

쇼스케: 역시 좀 그렇지.

도코: 친하다고 무조건 나쁘지는 않아. 대기업 시스템실에서는 시스템 개발을 맡았던 벤더 출신을 채용

하는 일도 많으니까. 하지만 이번처럼 벤더에게만 유리하게 요건을 바꿨다는 건 요구사항 담당자

가 문제의 핵심이라는 뜻 아니야?

쇼스케: 한통속이 돼서 슬쩍 눈감아준 건가?

도코: 그건 모르지. 하지만 내가 담당한 사건 중에도 비슷한 사례가 있어. 벤더 출신 개발자가 어떤 기업

에 입사해서 그 회사 시스템 개발을 자기가 원래 근무했던 벤더에게 맡긴 사건이었어.

쇼스케: 확실히 비슷하네.

도코: 그 회사도 사내에 시스템 개발을 잘 아는 사람이 없어서 벤더 출신인 사원에게 요구사항 정의를

맡겼어. 그런데 여러 가지 요건이 벤더에게 유리하게 정의된 거야. 악의는 없었지만 친한 벤더 직

원과 이야기하다 보니 그런 식으로 결정이 나버렸대.

쇼스케: 그럼 뚜껑을 열었을 때 엄청나게 비난받지 않았어?

도코: 당연하지. 인수 테스트 담당자는 이런 시스템을 쓸 수 없다며 엄청나게 추궁하고, 뒤늦게 벤더에

변경을 요청하려니 막대한 비용을 청구할 게 뻔해서 발주처 담당자는 이러지도 저러지도 못하는

상황이었어.

쇼스케: 자기가 뿌린 씨앗이긴 해도 힘들었겠다.

도코: 그랬던 것 같아. 그래서 그 직원은 갑자기 회사를 그만둬버렸어.


쇼스케: 그건 너무 무책임하잖아.

도코: 그 밖에도 시스템에 여러 문제가 많아서 발주자는 결함과 요구사항 정의 미비를 이유로 비용 지급

을 거부했어. 당연히 벤더는 비용 지급을 주장해서 재판까지 갔지.

쇼스케: 그래서 어떻게 됐어?

도코: 최종적으로는 아무리 발주처 담당자가 벤더 출신이었어도 요구사항을 정한 건 발주처 담당자여서

발주자가 상당한 비율로 비용을 지급하게 됐어.

쇼스케: 그럼 우리 회사도 마찬가지야?

도코: 똑같지는 않지만 비슷한 상황이긴 해. 그래도 손해가 적을 때 빨리 계약을 해지하는 편이 좋아. 위

약금은 발생하겠지만.

쇼스케: 위약금? 어떡해. 아빠한테 또 혼나겠다.

도코: 좋은 격언 하나 알려줄게. 흔히 문제없이 프로젝트를 완수하면 우수한 관리자라고 하잖아. 하지만 더욱 우수한 관리자는 손해를 감수하고라도 문제를 조기에 해결해서 최종적으로 조직에 이익을 주는 사람이야.

쇼스케: 문제가 있는 게 더 낫다는 뜻이야?

도코: 문제가 없는 편이 당연히 낫지. 하지만 여러 프로젝트를 경험해 보면 누구나 난관에 부딪히고 문

제가 일어나. 그럴 때 손해를 최소한으로 줄이고 앞으로 나아가는 것이 순탄한 프로젝트를 운영하

는 것보다 훨씬 더 용기와 지혜와 체력이 필요하잖아? 그래서 그런 경험이 있는 관리자를 높이 평

가하는 거야.

쇼스케: 그렇구나. 그럼 나도 아빠에게 칭찬받을 수 있을까?

도코: 100대 정도 때린 후에 어루만져줄지도 모르지.

쇼스케: 읔! 그런데 앞으로 어떻게 해야 해? 이번 벤더와 계약을 파기한다고 해도 우리 회사에 요구사항을

담당할 만한 사람이 없어.

도코: 아무리 시스템에 정통한 사람이라도 외부에서 영입한 사람은 참관인으로 두는 게 좋아. 대신 업무

흐름을 잘 알고 시스템화 목적을 제대로 이해하는 사람을 책임자로 앉혀야 해. 외부 인력밖에 없

는 상황이면 실제로 그 시스템을 사용할 사람, 시스템 운영관리자가 될 사람을 포함해서 타당성을

검토하는 게 좋아.

쇼스케: 타당성 검토?


도코: 화면 전환이나 항목을 결정한 부분, 계산이나 로직이 만들어진 부분을 그때그때 꼼꼼하게 확인하

는 거야. 설계 단계부터 프로그래밍 단계까지.

쇼스케: 담당자를 안 믿는 것 같아서 기분 나빠하지 않을까?

도코: 쇼스케. 너의 그런 성격은 장점이자 단점이야. 하지만 “trust but verify”.

쇼스케: 뭐라고?

도코: ‘신뢰하되 검증하라’. 레이건이 고르바초프와 중거리 핵미사일의 전면 폐지를 교섭하면서 자주 썼

던 말이야.

◉ 발주처 담당자가 개발을 맡은 벤더 출신이면 최종 사용자와 운영자가 꼼꼼하게 타당성을 검토

해야 한다.

◉ 벤더는 이런 관리를 적극적으로 제안한다.

CHAPTER1

POINT

요구사항 정의 없이 개발했을 때요구사항 정의 없이 개발하면 발주자와 벤더가 각자의 주장만을 내세워 진흙탕 싸움으

로 번지기 쉽습니다. 하지만 나중에라도 협력해서 요구사항을 다시 정의할 수 있으면

관계는 개선될 수 있습니다.

개요

이치로는 도코와 대학 동기이자 같은 스터디 그룹에서 공부했던 친구로 현재는 대형 IT 벤더에서 근무하

고 있습니다. 그는 최근 한 프로젝트의 매니저로 중도 투입됐는데 요구사항 정의서 없이 개발이 진행 중

이라 힘들어했습니다.

이치로: 네, 네가 봤을 때 어때?

도코: 어쩌고 말고 할 것도 없네. 이런 계약서로는 누가 뭐라고 주장해도 아무 증거가 안 돼. “재고관리

시스템 스타일”이라는 게 대체 무슨 말이야? 너희 회사 늘 이렇게 일하니?

이치로: 느, 늘 이렇진 않아. 이번엔 사장님끼리 세부적인 얘긴 전혀 안 하고 계약해버리는 바람에…….

도코: 상사끼리 계약하는 게 반드시 나쁜 것만은 아니지만 이렇게 시스템화 목적이나 개선할 업무조차

명확하지 않은 상태에서 무조건 진행하라고 명령하면 담당자가 고생할 수밖에 없어. 성실이 너도

힘들지 않아?

이치로: 저기 있잖아. 몇 년째 말하지만 내 이름은 이치로인데…….

도코: 알아 알아. 네가 스터디 그룹에서 자기소개할 때 “좌우명은 ‘늘 진실하게 살자’입니다”라고 하는 바

람에 그렇잖아. 인제 와서 이치로라고 부르려니 입에 영 안 붙어. ……그런데 이건 너무 심하다. 계

약서에 “○○스타일”이라는 내용도 그렇고, 요구사항 정의서 없이 바로 만든 화면설계서에 있는

동작과 관련된 설명은 무슨 메모 수준이고, 요구사항 관련 회의록 내용도 너무 단편적이라 전혀

이해할 수 없잖아.

이치로: 할 말이 없다. 나도 갑자기 인계받은 거라…….

도코: 뭘 만들 건지도 분명하지 않고 내용도 너무 대충이야. 이 상태로 개발을 진행했다가는 보나 마나

실패할 게 뻔해.

CASE 10 CHAPTER1


V


이치로: 안 그래도 발주자가 ‘이 기능이 없다, 이 화면이 없다, 이런 기능은 요청하지 않았다’면서 매일 난

리야.

도코: 발주자에게 요구사항을 제대로 제시해달라고 항의해 보지 그랬어.

이치로: 요구사항은 화면설계서와 회의록에 다 있는데 뭘 물어보느냐는 식이야.

도코: 이 설계서는 입출력도 연산도 너무 엉망이라 사용할 수 없어. 이걸로는 못 만든다고 하지 그랬어?

이치로: 발주자는 예전 담당자였으면 다 알 내용인데 내가 들어오고 나서 얘기가 달라졌다며 못마땅해. 불

명확한 부분은 명확하게 요구사항 정의를 하자고 부탁해봤는데 인제 와서 무슨 소릴 하냐고 전혀

협조해주지 않아.

도코: 상황이 점점 나빠졌구나.

이치로: 출입 금지당하기 직전이야. 그보다 ‘이대로면 계약을 파기하겠다. 소송을 걸겠다’는 사람까지 있어.

도코: 흠. 요구사항과 계약 내용을 이어줄 문서가 전혀 없으니, 발주자는 ‘우리가 원하는 건 전부 만들어

줘야 한다’고 할 테고, 벤더는 ‘비용과 기한 내에 가능한 수준으로 만든다’고 주장하며 싸우겠지. 진

흙탕 싸움이 되겠는걸.

이치로: 재판까지 가면 어떻게 돼?

도코: 해결이 안 나지. 게다가 판결까지 2년에서 5년 정도 걸릴 거야.

이치로: 그렇게 오래 걸려? 그건 더 곤란한데.

도코: 그래서 재판은 안 하는 게 제일 좋아.

이치로: 발주자가 요구하는 대로 비용을 확 깎아주고 끝내는 게 나으려나.

도코: 역시 대기업다운 발상이다. 그런데 이 메일 내용을 보면 발주처 담당자는 늦더라도 완성하고 싶은

모양인데.

이치로: 예전에 보낸 메일이야. 이제는 경영진까지 상황을 알게 된 바람에 그런 얘기는 전혀 안 해.

도코: 흠. ……이 얘기가 참고될지는 모르겠는데.

이치로: 무슨 얘기?

도코: 예전에 한 운송업체의 핵심업무 시스템 개발과 관련된 재판에서 대립해야 할 발주자와 벤더가 조

기 해결을 목표로 일치단결한 예가 있어. 재판소의 조언도 있었지만, 양사 실무 담당자가 시스템

결함과 관련해서 허심탄회하게 논의하고 조사해서 해결할 수 있었어.


이치로: 실무 담당자끼리는 의외로 통하는 게 있으니까.

도코: 그 결과 결함이 생긴 원인이 발주자와 벤더 모두에게 있다는 걸 깨닫고 대립점이 많이 줄어서 조

기에 분쟁을 해결할 수 있었어.

이치로: 대단하다. 그럼 우리도 재판까지 가면…….

도코: 그게 아니지. 재판까지 안 가고도 해결할 수 있잖아? 잘만 하면 계약을 유지할 수 있는 역전의 기

회가 될 거야.

이치로: 정말?

도코: 이 문제의 원인은 미비한 계약과 요구사항이잖아? 그렇지?

이치로: 응

도코: 너희 회사에서 인수인계를 제대로 안 한 건 잘못이지만, 애초에 요구사항 정의나 계약 자체가 미

비한 건 양측 모두에게 책임이 있어. 잘못은 잘못이니까 제대로 대화해봐.

이치로: 하지만 그럴 분위기가 아니야.

도코: 공식적인 회의에서 말하면 안 돼. 먼저 적들 가운데에서 아군을 찾는 게 중요해. 완성하고 싶다는

메일을 보낸 사람은 누구야?

이치로: 발주처 실무 팀장이야.

도코: 그럼 일단 그 사람과 얘기해봐. 회의 석상에서는 말을 못할 수도 있지만, 개인적으로는 통하는 부

분이 있을지도 모르잖아? 다시 한 번 요구사항 정의서를 제대로 정리해보자고 솔직하게 말해봐.

상대방도 이겨봐야 아무 득이 없는 재판을 하는 것보다는 훨씬 생산적이라고 생각하지 않겠어?

이치로: 글쎄 잘 될까?

도코: 상대가 난색을 보이면 요구사항 정의 공정만이라도 다시 진행하자고 부탁해봐. 적어도 분쟁으로

파탄 나는 일은 면할 거야.

이치로: 그렇긴 하겠다.

도코: “대화로 풀라”는 말이 굉장히 성의 없는 중재처럼 들릴지 모르지만, 조정 과정에서 보면 대화만 좀

일찍 했더라도 좋았을 텐데 하는 사건이 정말 많아. IT 분쟁이 일어나는 원인은 책임분담을 제대로

안 했거나 사소한 오해 또는 확인을 철저히 안 해서야.

이치로: 언제부터 이렇게 서로의 입장만 내세우게 됐을까? 한 사람이 양보할 수 없다고 나오면 나머지 사

람도 우르르 동조해 버리는 분위기야.


도코: 개인끼리면 그렇게까지 고집부리지 않고 이해해 주기도 하니까 먼저 상대 측에서 비슷한 처지인

사람을 골라 몰래 동맹을 맺어. 그리고 요구사항 정의서를 제대로 정리하고 나서 둘이 함께 높은

양반들에게 보여줘. 굳이 재판까지 갈거면 그 후에도 늦지 않아.

이치로: 그렇지. 그러면 되겠다.

도코: 가장 중요한 건 계약서 내용과 요구사항을 맞춰두는 거야. 하지만 요구사항이나 산출물은 개발 도

중에 바뀔 수도 있으니까 계약서와 별지로 만들어 놓는 게 좋아.

이치로: 우선 길이 열린 것 같다. 응, 왠지 할 수 있을 것 같아.

도코: 그래 자신감 가져.

이치로: 도코 정말 고마워.

도코: 앗 뭐야 갑자기. 야 왜 갑자기 가까이 오고 그래.

이치로: 있잖아.

도코: 갑자기 손은 왜 잡고……. 네 마음 다 알아. 오랜만에 만나니까 내 미모를 다시 깨달았겠지. 그렇지

만 아직 대낮에 이러면, 게다가 여긴 사무실이야.

이치로: 오늘 여기 온 게 행운이야. 고마워. 진심으로 고마워.

도코: …… 뭣?

이치로: 역시 뭐니뭐니해도 친구가 최고다. 또 올게. 잘 있어.

도코: …… 뭐, 뭐래!

◉ 요구사항 정의가 없는 분쟁은 진흙탕 싸움이 되므로 싸우는 중이라도 빨리 요구사항을 정리해

서 프로젝트를 부활시킬 방도를 모색하는 게 좋다.

◉ 프로젝트를 재개하려면 담당자끼리 개인적인 대화를 하는 것이 좋다.

◉ 계약서와 요구사항 정의서, 산출물 목록은 별지로 만들어 첨부한다.

CHAPTER1

POINT

업무요건에 누락된 요소가 있을 때벤더가 발주자에게 요구사항을 물을 때는 단순히 업무 프로세스만 확인하는 게 아니라,

사용성이나 업무 속성도 주목해야 미처 깨닫지 못한 사항까지 발견할 수 있습니다.

개요

이치로는 요구사항을 다시 정리할 수 있게 됐습니다. 하지만 제조업 업무 지식이 부족했던 탓에 업무 프

로세스에 정의되지 않은 예외적 활동까지는 파악하지 못해서 업무 요건에 누락된 부분이 발견됐습니다.

도코: 왜 또 왔어?

이치로: 무, 무슨 기분 안 좋은 일 있어? 혹시 내가 무슨 실수라도……?

도코: 그런 거 아니니까 신경 쓰지 마. 그래서 재고관리 시스템은 어떻게 됐어?

이치로: 네 덕분에 잘 진행되긴 하는데 그러고 났더니 다른 문제가 생겨서 다시 잘 안 되고 있어.

도코: 잘 되고 있다는 거야 아니라는 거야!?

이치로: 그게, 발주처 담당자랑 협력해서 요구사항을 새로 정리했는데, 서두르다 보니 업무 요건에 또 빠진

부분이 나왔어.

도코: 요구사항은 어떤 식으로 정리했는데?

이치로: 재고관리 담당자에게 업무 프로세스를 확인했어.

도코: 재고관리 업무 프로세스를?

이치로: 으응. 업무 프로세스 문서23가 있었는데. 그걸 바탕으로 재고관리 담당자에게 설명을 들었어. 언

제 어떻게 의뢰를 받고, 어떤 작업을 하는지. 프로세스는 누락된 부분 없이 잘 쫓았다고 생각했는

데.

도코: 하지만 누락된 요소가 나온 거지?

23저자 주: 시스템화 대상 업무의 절차 등을 기재한 문서. 발주자 업무를 조사할 때 부서별 역할을 정의한 업무분담서 등과 함께 참조한다.

CASE 11 CHAPTER1


V


이치로: 그래. 업무 프로세스에 없는 예외적 업무가 있었던 거야.

도코: 어떤 일?

이치로: 이번 재고관리 업무는 창고에 보관된 수백 대의 출하용 컴퓨터를 관리하는 일이거든.

도코: 모델 번호별 재고수와 일련번호를 목록으로 관리하는 시스템 말이지?

이치로: 맞아. 영업담당자가 출하요청을 하면 재고관리 담당자가 창고에 남은 제품 수량을 점검할 수 있게

돕는 시스템이야.

도코: 필요한 수량의 컴퓨터에 출하일과 납품처를 예약해 놓겠구나.

이치로: 주문 수량이 재고량보다 많을 때는 재입고까지 기다렸다가 제품을 출하해. 미리 예약만 해놓고.

도코: 그런데 뭐가 문제야?

이치로: 가끔 영업담당자가 재입고까지 기다릴 수 없다고 당장 출하해달라는 경우가 있대. 그럴 땐 조금

늦게 출하해도 되는 다른 주문 물량을 빼 와서 내보낸대.

도코: 그게 프로세스에는 없던 업무구나.

이치로: 그래. 우린 그런 일이 있을 거라고 예상하지 못해서 업무 요건에 정의하지 않았어.

도코: 정규 프로세스에 누락된 요소가 없는 걸 확인하고 안심했구나. 하지만 실패는 실패고 요구사항 정

의 담당자가 몰랐던 건 잘못이야. 넌 금융 시스템을 주로 해 와서 제조업의 재고관리는 잘 몰랐

지?

이치로: 몰랐어. 게다가 갑자기 떠맡은 프로젝트라…….

도코: 발주자에게 그런 건 상관없지! 한심한 소리 하지 마. 제품을 출하할 때 “새치기”가 생기는 건 업계

상식이야. 벤더가 그런 상식을 몰라서 패소한 재판24도 있어.

이치로: 뭐라고? 재판?

도코: 여행사 시스템이었는데. 운영자가 원격지에서 서버에 접속해 데이터를 수정할 수 있는 기능이 없

었던 게 원인이었어.

24 저자 주: 2004년 6월 23일 도쿄 지방 재판소 판결. 이 재판은 벤더가 여행회사 시스템에 “운영자가 직접 서버의 데이터를 변경할 수 있는 기능”을 만

들지 않은 것이 채무불이행인지 여부를 따지는 것이었다. 재판소는 계약서 별첨 자료에도 없던 이 기능이 “여행상품 판매 업무에 반드시 필요한 기

능”이라며 업계 일반 상식에 비춰 시스템이 미완성됐다고 판단했다.


이치로: 운영자가 DB에 직접 접속해서 데이터를 고치는 기능은 일반적으로 필요한 기능이 아니잖아? 도

저히 이해가 안 가.

도코: 벤더의 개발자도 그렇게 생각했을 거야. 일반적인 시스템은 운영자가 DB에 직접 접근하면 오히려

위험하니까. 하지만 여행사 시스템은 그게 반드시 필요한 기능이었어. 그래서 발주자가 명확히 요

청하지 않았더라도 상식적으로 갖춰야 하는 기능이라는 판결이 났어.

이치로: 업계 상식을 모르면 엄청난 사태가 벌어질 수 있구나.

도코: 다 그렇지는 않겠지만, 적어도 발주자 업계의 “상식”을 무시하면 안 돼.

이치로: 큰일이네.

도코: 이번처럼 네 업무지식이 부족하면 재고관리 담당자가 시스템 개발에 참여하게 하면 돼.

이치로: 부, 부탁해봤는데 영 바쁜 것 같더라고. 그래서 구두로라도 설명을 들으려고 내가 직접 가서 물어

보고 있어.

도코: 물어볼 때도 업무 프로세스 위주로 물으면 누락된 요소가 나올 수밖에 없어. 요구사항을 도출하려

면 업무 프로세스 이외에 운영자의 행동까지 주목해서 질문해야 해.

이치로: 행동?

도코: 그래. 업무 범위만이 아니라 운영자가 업무 중에 어떤 행동을 하는지도 물어봐야 해.

이치로: 어떤 식으로?

도코: 예를 들면 몇 시에 출근해서 어떤 회의에 참석하고, 어떤 사람이 찾아와서 어떤 부탁을 하는지 물

어보는 거야.

이치로: 너무 꼬치꼬치 캐묻는 게 아닐까?

도코: 출퇴근 시간은 배치 처리25할 시간대를 결정하기 위한 자료가 돼. 운영자가 퇴근하고 난 뒤에 주

로 배치를 돌리지만, 운영자가 평소에 몇 시까지 근무하는지는 본인이 제일 잘 알잖아? 시스템 담

당자가 밤 11시 정도에 배치를 돌리기 시작한대도, 운영자가 ‘분기 말에는 자정 넘게 일한다’고 할

수도 있으니까.

이치로: 아 그런 얘기구나. 하긴 예전에 그런 일이 있긴 했어.

25저자 주: 대량의 데이터를 일괄적으로 처리하는 것. 업무에 지장을 줄 수 있어서 주로 운영자가 시스템을 이용하지 않는 야간 시간대에 이뤄진다.


도코: 그리고 회의 때 재고관리 분석 보고서가 필요할 수도 있잖아. 시스템에서 재고 데이터를 엑셀로

자유롭게 출력할 수 있게 DB를 구축해 달라는 의견이 나올지도 몰라.

이치로: 그럴 수 있겠다.

도코: 누가 찾아와서 부탁한다는 건 예외적인 업무가 들어올지도 모른다는 뜻이야. 단발성 업무라면 신

경 쓰지 않아도 되겠지만 자주 있는 일이라면 시스템화해야 해.

이치로: 그런 건 업무 프로세스만으로 파악하기 어렵겠다.

도코: 운영자의 특징을 분석하는 것도 요건 도출에 도움이 돼. 중장년층 운영자가 많으면 글자를 크게

해서 사용성을 높이고, 많은 업무를 한 번에 처리해야 하는 사람이면 컴퓨터 메모리 용량에도 유

의해야 해.

이치로: 그런 건 우리가 묻지 않으면 모르고 넘어가기 쉽겠다.

도코: 그렇지? 그런 모든 요소를 고려하지 않으면 새 시스템에 불만이 점점 쌓이게 돼. 반대로 잘만 대

응하면 고객만족도를 높일 수 있어.

이치로: 잘 알았어. 더 노력해볼게. 참 혹시 오늘 밤에…….

도코: 오늘 밤?

이치로: 별로 안 내키면 거절해도 되는데.

도코: 그러니까 뭘?

이치로: 저기. 고객에게 물어볼 질의서를 같이 만들어 줄 수 없을까? 물론 비용은 지급할게.

도코: …….

이치로: 저, 어떻게 안 될까? ……앗 아야! 힐 신고 발을 밟으면 어떡해, 아파 아프다니까…….

◉ 요구사항 정의 대상 업무는 운영자에게 배운다.

◉ 업무 요건은 단순히 정규 프로세스만을 확인하지 않고, 운영자의 행동이나 계절성 등도 포함

해 확인한다.

CHAPTER1

POINT

시스템 개발 범위는 어떻게 정할까?벤더가 발주자에게 요구사항을 물을 때는 단순히 업무 프로세스만 확인하는 게 아니라,

사용성이나 업무 속성도 주목해야 미처 깨닫지 못한 사항까지 발견할 수 있습니다.

개요

이치로는 프로젝트가 자리 잡기 시작해 도코에게 감사 인사를 하러 옵니다. 두 사람은 이번 시스템 개발

의 요구사항 정의와 시스템 개발 범위의 정의를 소재로 이야기를 나누게 됩니다.

이치로: 도, 도, 도코.

도코: 있잖아, 남의 이름 부를 때 제발 더듬지 좀 마. 그렇게 부르면 힘 빠져.

이치로: 이, 일전엔 늦게까지 도와줘서 정말 고마웠어.

도코: 정말 내가 왜 그 시간까지 네 일을 도왔는지!

이치로: 그, 그래서 오늘은 도와준 답례를 가져왔어.

도코: 뭐? 답례? 어머 그래? 답례받으려고 도와준 건 아니지만……. 그래서 뭔데? 너무 비싼 건 부담스

러운데.

이치로: 자, 우리 회사 사은품이야. “타마몬”이 그린 일러스트 메모장, 볼펜, 포스트잇도 있어. 이거 정말 인

기 사은품이라 회사에서 빼 오기 힘들었어.

도코: 타, 타마몬…….

이치로: 부족해? 목욕 수건도 있는데 다음에 가져올게.

도코: 고, 고마워. 이걸로 충분하니까 안 가져와도 돼. 흠, 타마몬이란 말이지……. 그래서 프로젝트는 어

떻게 됐어?

이치로: 덕분에 궤도에 올랐어. 요구사항 조정도 거의 끝났고.

도코: 그래? 잘됐네.

CASE 12 CHAPTER1


V


이치로: 일전에 네가 말해준 여행사 분쟁처럼 “당연히 알고 있어야 할 업무 지식”이 판결 근거가 된다는

사실에 놀랐어. 솔직히 계약서나 견적서 같은 문서만 볼 거로 생각했는데 의외로 현실적인 요소도 보는구나.

도코: 계약서나 견적서도 중요하지만 작업 실태를 명확히 파악할 수 있는 건 요구사항 정의서와 설계서,

계획서, 회의록이야. 보통 그런 문서를 참고로 판결을 내려.

이치로: 하긴, IT 사업에서 계약만으로 업무 실태를 파악하기는 어렵지.

도코: 특히 요구사항 정의서가 중요해. 요구사항 정의서는 “약속한 기능”을 명확하게 나타내는 중요한

판단 자료야.

이치로: 요구사항 정의는 정말 만만치 않은 일이야. 이번처럼 업무 프로세스를 듣고 시스템화 범위를 결정

해도 운영자의 업무 패턴에 따라 예상치 못한 요소가 튀어나올 수도 있으니까. 아무리 조사해도

다 포함한 게 맞는지 불안해.

도코: 그래. 옛날처럼 컴퓨터로 하는 업무가 웬만큼 정해져 있으면 요구사항도 정형화되겠지만 요즘엔

사용자도 다양하고 컴퓨터 종류와 기능도 워낙 여러 가지니까.

이치로: 정확하게 개발범위를 정의하고 요구사항을 빠짐없이 도출해서 업무 목적을 실현할 방법은 없을

까?

도코: 정답은 없지만 단순한 아이디어로 요구사항을 쉽게 검토하고 개발범위를 올바르게 정의한 사례를

본 적이 있어

이치로: 어떤 아이디어?

도코: 시스템화 범위와 요구사항 도출은 뭘 근거로 정할까?

이치로: 시스템화 목적 아니야? 시스템화 목적을 달성하려고 시스템을 만드는 거니까. 이번 재고관리를 예

로 들면 재고관리업무의 전산화와 생산성 향상이겠지.

도코: 시스템화 목적은 너무 추상적이라 요구사항이나 개발 범위를 정의할 때 직접적인 근거자료로 활

용하기 어렵지 않아?

이치로: 그래서 그런지 개발하는 중에는 목적을 점점 잊게 돼.

도코: 내가 본 사례는 목적이 아니라 그걸 실현하기 위한 방침에 주목했어26 . 너희 시스템은 목적을 달

성하는 방침이 어떤 거야?

26 저자 주: 시스템 개발 목적과 방침은 혼동하기 쉽다. 목적은 시스템 도입으로 얻을 수 있는 이익(“비용 삭감”이나 “신규고객 획득”)을 나타내서 구체적

인 업무 내용과 연결짓기 어렵지만 본문 중에 쓴 방침은 시스템화로 업무가 어떤 식으로 나아지는지 정의한 것이라 요구사항을 도출하는 자료로 적

합하다.


이치로: 음 그러니까,

• 재고관리 작업 절차를 간소화한다.

• 정형화된 업무나 시간이 걸리는 업무는 전산화해 작업 속도를 높인다.

• 컴퓨터를 잘 못 쓰는 사람도 조작하기 쉽게 만든다.

이를 통해 업무를 전산화하고 생산성을 향상하는 거지.

도코: 업무 프로세스와 운영자 질의로 도출한 요구사항을 이 “방침”에 견줘서 검증하는 거야.

이치로: “방침과 요구사항을 비교분석”하는 거구나.

도코: 맞아. 예를 들면 너희 발주자가 요청한 기능 가운데

• 많은 재고를 한 번에 추출하고 싶다.

• 이미 예약된 물량을 나중에 들어온 급한 주문 건으로 자동으로 돌릴 수 있게 하고 싶다.

이 두 가지 요건은 ‘정형화된 업무나 시간이 걸리는 업무는 전산화해 작업 속도를 높인다’는 방침

과 연결되지? 그러니까 이건 개발 범위에 꼭 들어가야 하는 요건이야.

이치로: 듣고 보니 그러네. 목적과 달리 방침과 요건은 구체적이라 연결짓기가 더 쉽구나.

도코: 그렇지? 그런데 중요한 건 그다음이야. 이번에는 거꾸로 방침을 달성하기 위한 요구사항이 이

것뿐인지 고민할 필요가 있어. 너희 시스템을 예로 들면 “정형화된 업무”나 “시간이 걸리는 업

무”가 더 없는지 찾는 거야. 프로세스를 확인하고 운영자에게 물어서 빠진 요건이 없는지 검증

하는 거지27 .

이치로: 아, 그러면 발주자도 미처 깨닫지 못했던 시스템 개발 목적을 달성하기 위한 요건을 찾을 수 있겠

구나.

도코: 너희 시스템에 추가할 게 떠오르지 않아?

이치로: 출하 승인 업무가 좀 걸려. 출하 승인을 받으려면 문서를 출력해서 창고와 본사에 있는 승인 담당

자에게 도장을 받아야 하거든. 이 업무에 시간이 걸리면 아무리 출하 물량을 자동으로 관리해도

생산성 향상이라는 시스템 개발 목적을 달성하기가 어려워.

도코: 그렇게 방침에서 필요한 요건을 찾아보면 요구사항 정의가 더 쉽지 않을까?

27 저자 주: ‘필요한가’를 상향식으로 검증하고, ‘충분한가’를 하향식으로 검증한다. 신호등을 예로 들면 빨강과 파랑은 신호등에 “필요한” 색이지만 보라

색은 불필요하므로 제외한다. 신호등은 시간에 따라 움직이므로 “노란색”까지 포함해야 “충분하다”는 것을 알 수 있다.


이치로: 그러게. “정형화된 업무와 시간이 걸리는 업무”로 생각하니까 여러 가지 다른 업무까지 떠올라.

도코: 그렇게 목적 달성을 위한 방침에서 요구사항 후보를 선별하고, 그 방침을 달성하는 데 필요한 요

구사항을 다 갖추면 시스템화 범위도 자연스럽게 결정되지 않을까?

이치로: 하긴 업무 프로세스 윤곽선만 그리면28 놓치는 부분이 많지.

도코: 고기잡이에 비유하자면 프로세스를 선으로 그리는 방법은 그물로 물고기를 잡는 것과 같아. 한꺼

번에 많이 잡을 수 있어서 효과적이지만 빠져나가는 물고기도 그만큼 많거든. 방침과 연결하거나

역추적하는 방법은 낚시와 같아. 어떤 물고기를 잡을지 표적이 분명하니까 확실성이 높지. 두 가지

방법을 잘 조합하면 요구사항도 빠짐없이 정의할 수 있고 개발범위도 결정할 수 있어.

이치로: 대단하다.

도코: 물론 이런 방법이 모든 개발에 통용되는 건 아니야. 기존 시스템을 개선할 때 이런 방법을 쓰면 괜

한 헛수고가 돼. 새로운 시스템 구축, 특히 지금까지 시스템화되지 않은 업무를 대상으로 할 때 효

과적이야.

이치로: 재고관리 시스템은 매우 흔하지만 고객이 업무에 시스템을 도입하는 건 처음이니까 적용해 봐야

겠다. 한 수 배웠어. 고마워. 돌아가면 바로 방침과 요구사항을 비교해 볼게. 또 빠진 부분이 나올

지도 모르겠다. 다음에 올 땐 타마몬이 그려진 일러스트 목욕 수건 가져올게.

도코: 됐어!

28 저자 주: 업무 흐름도 일부를 선으로 에워싸서 시스템 대상 범위를 표시하는 방법으로 가독성이 높아 효과적이다. 방침에서 기능을 도출하는 방법과

병행하면 교차 검사도 돼 기능이 누락되는 것을 미리 막을 수 있다.

◉ 시스템화 방침과 요구사항을 양방향으로 검토하면 요구사항을 빠짐없이 정의할 수 있을 뿐만

아니라 효과적으로 개발 범위를 정의할 수 있다.

CHAPTER1

POINT


요구사항 정의서 체크리스트 U V

용어규약집을 작성했는가?

발주자의 요구나 업무과제를 모두 검토했는가?

예외적 상황까지 포함해 업무 프로세스를 검토했는가?

새로운 업무에서 운영자가 맡을 역할이나 책임, 행동 패턴을 검증했는가?

시스템화 범위에 누락된 요소나 불필요한 요소가 없는가?

발주자의 조직 특성을 고려해 전제조건과 제약조건을 확인했는가?

발주자의 기술력을 고려해 전제조건과 제약조건을 확인했는가?

기존 시스템을 분석해 전제조건과 제약조건을 확인했는가?

개발과 테스트 환경을 고려해 전제조건과 제약조건을 확인했는가?

기술적 전제조건과 제약조건을 확인했는가?

다양한 사용 환경과 이용 상황을 고려해 전제조건과 제약조건을 확인했는가?

법률 규정을 모두 확인했는가?

확정되지 않은 전제조건이나 제약조건은 없는가?

모든 요구사항이 시스템화 목적에 충분히 부합하는가?

모든 업무와 각 기능의 입력, 연산, 출력을 정의했는가?

실행 시 기동시간이나 응답 속도, 필요한 용량 등과 같은 성능을 정의했는가?

운영자에게 사용자 화면과 사용성을 설명하고 확인받았는가?

운용 담당자에게 운용 요건을 확인받았는가?

데이터 이송 담당자나 원본 서버 담당자에게 이송 요건을 확인받았는가?

요구사항 간에 모순이나 어긋나는 점은 없는가?

요구사항에 우선순위를 정했는가?

각 요구사항의 책임자(요구사항 변경이나 삭제 시 승인자)는 명확한가?

확인되지 않은 의견이나 정보를 요구사항 목록에 포함하지는 않았는가?

수용하지 않은 요구사항의 거부 사유가 타당한가?

각 기능을 구현하는 데 필요한 자원, 일정, 비용을 검토했는가?

프로젝트 계획서에 모순이 없는가?

미결 요건의 결정 시기와 결정 방침, 책임자 등이 명확한가?

요구사항을 기준으로 시스템 테스트, 운용 테스트, 사용자 테스트 시나리오와 평가기준을 작성했는

가?

DATA_CHAPTER1

68


비기능적 요구사항 개요

시스템을 개발하는 데 필요한 요구사항 가운데 시스템 성능이나 사용성, 보안 등을 정의한 비기능적 요구사항은

형태가 보이지 않아서 매우 까다롭습니다. 여러 단체가 비기능적 요구사항을 연구했지만 이 책에는 이해하기 쉽

고 다양한 요건을 포함하고 있는 JUAS(일본정보시스템 사업자 협회)에서 발표한 비기능적 요구사항 분류를 소

개하겠습니다.

비기능적 요구사항 분류

특성 부특성 설명

기능성

합목적성, 정확성, 상호운용성, 보안성, 기능성 표

준적합성

명시된 환경에서 소프트웨어를 사용하면 사용

자 문서에 기재됐거나 암시적으로 필요한 기능

을 제공하는 제품 능력

신뢰성성숙성, 결함허용성, 회복성, 신뢰성 표준적합성 명시된 환경에서 소프트웨어를 사용하면 지정

한 수준의 성능을 유지하는 제품 능력

사용성

이해성, 학습용이성, 조작성, 사용성 표준적합성 명시된 환경에서 소프트웨어를 사용하면 이해

하기 쉽고 배우기 쉬워서 사용자에게 매력적인

제품 능력

효율성시간효율성(컴퓨터 시스템 효율), 시간효율성(업

무효율), 자원 효율성, 효율성 표준적합성

명시된 환경에서 활용하는 자원의 양에 비해

적절한 성능을 제공하는 소프트웨어 제품 능력

유지보수성분석성, 변경용이성, 안정성, 시험성, 유지보수성

표준적합성

수정하기 쉽게 구현한 소프트웨어 제품 능력

이식성환경적응성, 설치성, 공존성, 대체성, 재활용성,

이식성 표준적합성

한 환경에서 다른 환경으로 이동하기 쉽게 구

현한 소프트웨어 제품 능력

결함억제성발생방지, 결함확대방지책 신뢰성 높은 소프트웨어를 개발해 운용에 필요

한 모든 사항을 정의한 것

효과성

금액으로 환산 가능한 평가(정량평가), 금액으로

환산 불가능한 평가(정성평가·KPI), 일반적 지

표에 따른 평가

비용과 시스템 투자 효과 예측

운용성

운용 서비스 품질 목표(SLA), 운용용이성, 장애대

책, 재해대책(DR)

이용자의 요구에 따라 서비스를 제공하고, 주

어진 조건에서 특정 허용범위의 서비스를 요청

한 기간에 제공할 수 있는 능력

기술요건

시스템 구현 방식, 시스템 구성, 시스템 개발방법,

개발기준/표준, 개발환경

사전에 정해진 틀이나 구조, 또는 비기능적 요

구사항을 토대로 프로젝트 내부에서 검토해 결

정한 것

출처:사단법인 일본정보시스템 사업자 협회 「비기능적 요구사항 정의 가이드라인」

69


요구사항 추적표 예시

시스템 요건이나 설계가 바뀌면 그와 관련된 다른 문서와 프로그램도 빠짐없이 수정해야 합니다. 수정한 요소가

어떤 문서와 프로그램에 영향을 미치는지 정확하게 파악하려면 요구사항 추적표를 만들어 양방향으로 추적할

수 있게 하면 효과적입니다.

작업산출물 사이의 양방향 추적을 가능하게 하는 방법을 설명하기 전에 알아두면 좋은 시스템 개발 V 모형을 간

단히 설명하겠습니다.

다음은 시스템 개발의 일반적인 공정 관계를 나타낸 그림으로, 실선 화살표는 작업순서를 나타내고 점선 화살표

는 상호 정합성을 유지하기 위한 산출물의 연관성을 나타냅니다.

시스템 개발 V모형과 양방향 추적 가능성

위 그림을 보면 요구사항 정의서는 외부설계서와 시스템 테스트 관련 문서(계획서와 명세서, 테스트 시나리오

등)에 논리적 모순이 없어야 함을 알 수 있습니다. 그러므로 요구사항 정의서를 수정하면 외부설계서나 시스템

테스트 관련 문서 등도 수정해야만 합니다. 이는 다른 문서나 프로그램도 마찬가지입니다.

추적 가능성 확보란 이처럼 수정해야 할 부분이 어딘지 구체적으로 쉽게 추적할 수 있는 것을 의미합니다. 사실

많은 프로젝트가 이와 같은 추적 가능성을 확보하지 못해 요건이나 설계를 변경했을 때 누락된 요소가 생겨 분

쟁이 발생합니다.

그래서 이런 양방향 추적 가능성을 확보하려고 고안한 것이 다음 도표와 같은 “요구사항 추적표”로 상당히 효과

적입니다. 요구사항 추적표를 작성해 관리하면 변경이 있을 때 어디에 영향을 주는지 일목요연하게 알 수 있습

니다.

요구사항 정의 시스템 테스트

외부설계 통합 테스트

내부설계 단위 테스트

프로그램

70


요구사항 정의서와 외부설계서의 추적표 예시

외부설계

요　건

설계1 설계2 설계3

설계11 설계12 설계13 설계21 설계22 설계31 설계32 설계33

요건Ａ

요건A-01

● ● ●

요건A-02

● ● ●

요건A-03

●

요건Ｂ

요건B-01

● ● ●

요건B-02

● ● ●

요건B-03

● ●

요건C ●

요건D ● ●

이렇게 관리하면 “요건 A-02”에 변경사항이 생겼을 때 “설계21”, “설계31”, “설계33”이 영향을 받는 것을 금방

알 수 있습니다. 위 도표는 요구사항과 외부설계만으로 작성했지만 똑같은 방법으로 외부설계와 내부설계, 외부

설계와 프로그램 등과 같이 작성하면 요건을 변경했을 때 누락된 요소가 생겨 분쟁이 발생하는 일은 훨씬 줄 것

입니다.

추적표를 작성하고 유지하려면 많은 공수가 들어서 일정 규모 이상의 프로젝트에서는 대부분 전용 시스템을 사

용합니다.

71

column1

IT 분쟁, 판결까지 얼마나 걸릴까?

IT 관련 소송만이 아니라 재판이나 조정은 깜짝 놀랄 만큼 오랜 시간이 걸립니다. 필

자의 경험으로 말씀드리면 소송이 최초로 제기된 시점부터 1심에서 판결이나 화해와

같이 결론이 나기까지는 약 1년~3년이 걸리고, 그 후 조정으로 넘어가도 비슷한 시

간이 걸리므로 다 합치면 2~6년까지 오랜 시간이 걸립니다. 소송 당사자에게는 상당

히 부담스럽고 고통스러운 시간입니다.

왜 이렇게 오랜 시간이 걸릴까요? 제 생각에 재판관이 너무 바쁜 것도 원인 중 하나인

듯합니다. 민사 제22부의 재판관님께 여쭤보니 그분은 동시에 약 100건이 넘는(100

건 정도면 양호한 편이라고 할 정도) 사건을 담당하고 계셨습니다. 그러니 재판이나

조정에 월 1회(대부분 1~2시간 정도)밖에 시간을 내지 못하는 것도 어쩌면 당연한

일일지 모릅니다.

다른 한 가지 원인은 피고와 원고가 서류를 준비하는 데 시간이 오래 걸리기 때문

입니다. 앞서 설명해 드린 것처럼 재판에는 온갖 증거서류가 제출되는데 그중에서

도 하자 목록을 만드는 데 엄청난 시간이 소요됩니다. 하자 목록은 분쟁 대상 시스

템에 있어야 마땅한 기능이나 성능이 갖춰지지 않은 부분을 한 번에 정리해 벤더가

이에 반론하는 내용을 담은 문서입니다. IT 전문가가 아닌 발주자가 시스템 어디에

어떤 문제가 있다고 하나하나 명시하기란 상당히 어려운 일입니다. 그래서 이 문서를

작성하는 데만 몇 달이 걸리기도 합니다.

법적 분쟁은 당사자에게 시간적, 금전적으로 상당한 부담이 되므로 소송을 하는 동

안 제대로 경영하지 못할 때도 있습니다. 문서 작성에 반년을 허비할 바에야 IT 전문

가에게 도움을 요청해 신속하게 서류를 제출하는 것이 원고나 피고, 재판관 모두에게

유리합니다.

7272

프로젝트 계획과 관리(일정표 체크만이 관리는 아니다!)

CHAPTER

2

‘프로젝트는 타당한 계획만 세워도 절반은 성공이다’라는 말

처럼 올바른 계획과 관리는 프로젝트를 성공으로 이끄는 지

름길입니다.

2장에서는 프로젝트 계획서에 꼭 필요한 항목을 소개합니다.

특히 프로젝트 위험 관리와 정량적 진척 관리 방법을 자세히

설명하고, 프로젝트 체제와 관련된 문제도 설명하겠습니다.

왜 시스템 개발만 하면 싸워댈까? : 49가지 분쟁 사례로 배우는 프로젝트...

Documents

Transcript of 왜 시스템 개발만 하면 싸워댈까? : 49가지 분쟁 사례로 배우는 프로젝트...