대한민국 소프트웨어, 리스타트 위기를 넘어 도약으로

4 | 대한민국 소프트웨어, 리스타트

시작하는 글 11

대한민국 소프트웨어는 위기? ............................................... 12

소프트웨어 엔지니어링을 지배하라! 27

정도의 차이가 있을 뿐 요구사항 명세는 개발의 핵심이다 ......... 32

요구사항, 요구사항 명세, 설계는 다르다 ................................. 36

회사에서 만드는 소프트웨어가 망해간다면 UX에 주목하자 ..... 44

UX란 개발 이상의 것이다 ...................................................... 48

사용자의 말보다 행동을 믿자 ................................................ 55

아키텍트가 없더라도 아키텍처는 꼭 필요하다 ......................... 59

PM과 아키텍트는 다르다 ...................................................... 63

사공이 많은 프로젝트 팀이라면 아키텍트가

반드시 필요하다 .............................................................. 66

매뉴얼을 만들기보다 매뉴얼이 필요 없는

소프트웨어를 만들자 ....................................................... 70

제대로 테스트하려면 자원, 프로세스, 문서가 필요하다 ........... 73

최적의 테스트 기법을 찾아라 ................................................ 76

테스트하기 전에 품질을 개선할 수 있는 방법이 있다면

그걸 선택하자 ................................................................. 80

01P A R T

•차례•

차례 | 5

개발자도 테스트해야 한다..................................................... 83

형상관리와 버전관리는 다르다 .............................................. 87

소프트웨어 프로덕트 라인은 은총알이 아니다! ....................... 92

우수한 품질은 명확한 품질 기준에서 나온다 .......................... 97

QA는 체크리스트를 채우는 게 아니라

품질을 완성하는 것이다 ................................................. 100

프로세스를 개선하려면 절차, 도구, 인력

모두 개선해야 한다. ....................................................... 106

CMMI와 애자일 방법론은 양립하기가 매우 어렵다 ............... 110

애자일 방법론은 한물 간 방법론이 아니다! ............................116

CMMI가 적당한 조직이 있다!.............................................. 122

레거시의 저주를 피하려면 선후배 모두

노력해야 한다 ............................................................... 130


소프트웨어, 사람이 만든다! 135

자격증은 프로젝트 관리자의 역량을 보증하지 못한다 ........... 139

인본주의 관리가 효과가 있으려면 개발자의 자세가

매우 중요하다 ............................................................... 142

진짜 보수개발자와 진짜 진보개발자가 일하는

문화를 만들자 ............................................................... 145

업무가 중심이 되는 일터를 만들자 ....................................... 150

야근은 필요악이라도 악일 뿐이다 ........................................ 156

관리자는 회의를 하면 일을 한다고 생각한다.

이건 정말 착각이다! ....................................................... 166

이해당사자의 역학관계를 파악하자...................................... 172

일을 지정하기보다 범위를 정하자 ........................................ 176

멋진 의사결정 결과보다 그 과정이 더 중요하다 .................... 180

신입사원에게는 멘토링을 하자 ............................................ 184

02P A R T

차례 | 7

피드백이 성공하려면 문제에 대한 객관화가 먼저다 ............... 189

이기지 않는 게 이기는 것이다. ............................................. 192

아이디어를 많이 얻으려면 말을 자르지 마라 ......................... 196

너무 적게 혹은 너무 많이 측정해서는 안 된다 ....................... 199

프로젝트 관리자는 완전한 잣대가 돼서는 안 된다 .................204

갑질은 대물림해서는 안 된다 ..............................................208

을을 대하는 자세 ............................................................... 212

외호내혐 PM이 강한 팀워크를 만들 수도 있지만

그래도 문제는 있다 ........................................................ 216

관리자도 0.5MM는 힘들다 .................................................220

영업을 하든 관리를 하든 둘 중에 하나만 하자 ......................223

권한이 없다면 관리할 수 없다 ..............................................226

성공일지라도 팀원이 꼭 좋아하는 건 아니다 .........................230

프로젝트에서 시간은 늘 부족하다 ........................................234

열심히 일한 개발자에게 잠깐의 휴식이라도 허하라 ...............236


위험을 감수하고 이익을 극대화하라! 241

제안서나 기획서가 아무리 상세해도 불확실성을

최소화하지는 못한다 ..................................................... 245

위험, 이슈, 문제를 구분하자 ................................................ 249

PM은 불확실성의 화신이다 ................................................254

불확실성이 제거되지 않는다는 건 프로젝트가

망해간다는 명백한 증거다 ..............................................258

불확실성을 극복하려면 팀 내 이견을 최소화해야 한다 .......... 261

일찍 실패하는 것이 좋다 ..................................................... 265

계획이 변하더라도 계획은 늘 세워야 한다 ............................269

프로젝트는 어쨌든 끝난다 ..................................................273

03P A R T

차례 | 9

맺는 글 277

오픈 이노베이션을 DNA화하라, 그리고 DNA의 핵심은

사람임을 잊지 말자! ...................................................... 278

시작하는 글


대한민국 소프트웨어는 위기?

직장경력만으로 보자면 소프트웨어 업계에 발을 들여 놓은 지 10년이

넘었다. 여기에 컴키드로서 GW-Basic으로 프로그래밍을 시작한 아마

추어 프로그래머로 보낸 시간까지 더하면 25년이 조금 안 된다. 컴퓨터

와 지낸 시간이 오래됐기에 주위에는 이 분야와 관련된 지인이 많다.

서버 엔지니어인 친구가 있다. 이 친구를 만나면 이야깃거리가 다양

하다. 아무래도 같은 IT 분야에 있다 보니 상당 부분 업계 이야기다. 얼

마 전에도 이 친구를 만나 세상 사는 이야기를 나누다 보니 자연스럽

게 대화의 흐름이 업계 쪽으로 흘러갔다. 이 친구는 대한민국의 IT 상

황을 70년대 미싱공장으로 생각했다.

70년대 미싱공장 하면 나와 연배가 비슷한 사람들은 대개 전태일 열

사를 떠올릴 것이다. 노동법 대로 일하고 싶다는 말을 남기고 분신한

전태일 열사 말이다. 하나뿐인 소중한 생명을 희생함으로써 대한민국

의 열악한 노동현장은 그나마 조금이라도 바뀔 수 있었다. 시대는 빠

르게 지나 전태일 열사의 노동현장이었던 공장은 값싼 노동력을 찾아

해외로 옮겨졌다.

시작하는 글 | 13

그 자리는 대개 휘황찬란한 쇼핑몰이나 고층의 벤처 빌딩이 차지했

다. 그리고 우리는 새로운 천 년을 맞으면서 벤처라는 신기원을 그 공

간에서 키웠다. 밀레니엄 신드롬 이후 10년이 지난 지금 IT 노동자로서

첨단에서 활동하는 친구는 우리 분야의 사람들을 70년대 미싱공장의

노동자라고 부른다.

재봉과 미싱으로 돈을 버는 미싱공장 노동자와 최첨단의 IT 기술로

돈을 버는 IT 엔지니어를 동일선상에 두고 이야기하는 친구의 논리를

이쪽 분야에서 일하지 않는 사람들이 들으면 말도 안 된다고 생각할 것

이다. 하지만 이쪽 분야에서 일하고 있는 사람들이라면 친구의 과격한

비유에 고개를 끄덕일지도 모른다. 친구는 왜 그런 말을 했을까? 그리

고 과격한 친구의 말에 별 거부감을 느끼지 않은 이유는 뭘까?

대한민국 은행 역사상 초유의 사건이 벌어졌다. 농협의 전산망이 마

비된 사건이다. 몇 시간이면 해결될 거라 생각한 사건은 며칠이 지나도

해결될 기미가 보이지 않았고, 결국 사건의 원인에 대해 검찰까지 나서

는 국가적인 이슈가 되고 말았다. 농협 사태를 요약하자면 간단하다.

은행 시스템을 관리하는 서버에서 최고 권한을 지닌 루트 계정이 해

킹됐고, 해킹한 계정으로 모든 서버에 대해 무차별적인 삭제 명령이 내

려졌다. 거대한 은행 업무를 마비시킨 해킹 수법은 rm, dd 명령으로 요

약할 수 있다. 이 사건으로 전 국민이 rm, dd 명령을 알게 됐고 검찰에

서 이런 명령이 내려진 진원지를 조사해 보니 공용 노트북이라는 결론

이 내려졌다.


사건 초기에는 내부 소행이라고 가닥이 잡혔으나 검찰에선 결국 북

한 정보부대의 해킹으로 일어난 사건이라고 결론 내렸다. 북한의 소행

이라는 정부 발표에 일각에선 짜맞추기식 수사가 아니냐는 반론이 제

기됐지만 일단 결론이 북한의 소행으로 난 이상, 전 국민의 이슈였던

농협사태는 그렇게 마무리됐다.

IT 종사자로서 사건을 일으킨 배후가 북한이라는 발표는 참으로 놀

라웠다. 초기에 이 사건을 들은 IT 종사자들은 드디어 터질 일이 터졌

다고 생각했기 때문이다. 나도 농협 사건을 처음 들었을 때 1년 전쯤에

들은 뉴스가 생각났다. 아마도 이 사건을 떠올린 사람은 나뿐만이 아

닐 것이다. 농협에서 아웃소싱한 개발자가 과도한 업무 강도 탓에 폐를

잘라냈다는 소식이었다. 처음에 이 이야기를 들었을 때 무슨 인터넷

신문의 가십성 기사가 아닌가라는 생각이 들었다.

하지만 기사뿐 아니라 인터넷 커뮤니티에서 당사자의 입을 통해 들

은 사건의 전말은 놀라웠다. 2년 동안 자정이 넘는 시간에 퇴근하기를

반복하면서 면역력이 급격히 나빠지고 이 때문에 폐에 염증이 생겼다

고 한다. 항생제를 써도 염증이 나아지지 않자 결국 폐를 일부 절단하

는 수술을 받게 됐다고 한다. 대한민국에 노동환경 개선이 꽃을 피우

던 시절에나 있을 법한 일이, 그것도 최첨단을 달린다고 여겨지는 IT

분야에서 일어나다니 말도 안 된다는 생각이 들었다.

이런 이유로 농협 전산망 사태가 벌어지고 내부자 소행일 수도 있다

는 소문이 돌 때 폐를 잘라낸 노동자의 이야기가 생각났다. 그만큼 근


무 환경이 열악하니 거기에 앙심을 품은 사람이 나올 수도 있다는 생

각이 들어서였다. 하지만 수사 결과, 다행히도(?) 농협 사태는 북한의

소행이라는 결론이 났다.

과도한 업무 강도 탓에 폐를 잘라낸 개발자, 그 직원을 파면한 회사,

북한에 해킹 당한 은행. 어떤가? 놀랍지 않은가? 마치 70년대의 신문

기사를 읽는 것 같다. 즉, 유해한 작업 환경에서 일하다가 병이 난 노동

자, 그 직원을 쫓아낸 회사, 북한의 사주를 받고 노동자들이 파업을 주

동한다고 발표하는 검찰의 기사를 같은 날 같은 사회면에 보도하는,

70년대의 신문 기사를 읽는 듯하다. 이쯤 되면 IT 업계에 근무하지 않

는 독자라도 내 친구가 현재 IT 업계는 70년대 미싱공장 같다고 말하

는 데 동감할 것이다.

소프트웨어 개발과 관련된 대한민국의 현재 상황은 마치 일종의 옴

니버스 형식의 블랙 코미디 영화를 한 편 보는 것 같다. 첫 번째 에피소

드가 농협 사태와 폐를 잘라낸 노동자였다면, 두 번째 에피소드는 게임

의 유해성을 확인하려고 투철한 기자 정신으로 무장한 기자가 초등학

생들이 한참 게임을 즐기고 있던 PC방의 전원을 차단했던 사건에서 시

작한다. 사회면을 장식하는 폐륜 범죄의 이면에는 그 주범으로 언제부

터인가 ‘게임’이 등장하기 시작했다. 어릴 적부터 폭력성이 짙은 게임에

노출된 청소년들이 폭력적으로 변해서 그런 폐륜적인 범죄를 저질렀다

는 스토리다.

게임의 중독성이 초등학생에게 얼마나 큰 영향을 미치는지 보려고


기자는 어느 PC방을 찾아가 과감히 전원을 차단해 버렸다. 격한 반응

이 나오자 기자는 게임 때문에 초등학생이 폭력적으로 변했다는 결론

을 내렸다. 상상력이 풍부하지만 말도 안 되는 기자의 실험은 단번에

다양한 패러디를 탄생시켰다. 예를 들자면 프로그래밍의 유해성을 입

증하려고 데스크탑 PC로 프로그램을 짜는 프로젝트 룸에 전원을 내

려 버리면 개발자들이 아우성을 칠 테니 프로그램이 개발자에게 악영

향을 준다는 걸 증명한 셈이라는 식의 패러디가 봇물을 이뤘다.

청소년의 수면권 보장, 게임 중독, 패륜적인 범죄 등 전혀 소프트웨

어와 관련이 없어 보이는 이슈의 중심에 소프트웨어가 놓이게 된 셈이

다. 요약하자면 게임이 유발하는 중독성과 폭력성에서 청소년을 보호

하려고 정부와 정치권은 게임 셧다운제를 통과시켰고, 게임 업체는 이

법안에 맞춰 청소년 사용자의 게임 사용을 심야 시간에 제한해야 한

다. 과연 이 법안이 효과 있을까? 청소년이 게임에 과몰입하는 이유는

게임이 있기 때문이기도 하지만 사실은 청소년의 게임 과몰입을 책임

져야 할 부모가 그 역할을 제대로 하지 못해서다. 아이와 부모가 대화

를 많이 하고 함께 시간을 보낸다면 그 어떤 청소년이 게임에만 온통

정신을 팔고 있을까? 그들이 소비할 게 결국 게임밖에 없기 때문에 게

임에 과몰입하는 것이다.

이런 근본 문제를 바로잡을 생각은 하지 않고 온통 그 잘못을 게임

업계에만 묻는다. 마치 칼을 사용해 범죄를 저지르는 사람들이 있는데

그들이 범죄를 저지르지 않게 할 방법을 고민하는 게 아니라 칼을 만


든 사람에게 왜 칼을 만들었냐고, 칼을 만들었으니 대책을 세우라는

형국인 셈이다.

게임 셧다운제 말고도 대한민국에서 게임을 만든다는 건 상당히 힘

든 일이다. 심의를 통과하지 못하면 애써 만든 좋은 게임이라도 출시

할 수 없었다.1 이런 게임 업계에 대한 규제는 ‘주차장 지붕’ 사건으로

그 정점을 찍었다. 게임업체를 등록하려고 구청에 간 신생 게임업체가

사무실이 입주한 오피스텔의 주차장 지붕이 불법시설이어서 게임업

체로 등록하지 못했다는 사연이 인터넷에 퍼졌다. 결국 게임업체의 발

목을 잡는 규제에 대한 비판 여론이 높아졌다. 그리고 이런 게임업체

에 대한 규제를 줄여보자는 차원에서 논의가 진행됐다.

한마디로 웃긴 상황이 펼쳐진 셈이다. 한편에서 게임업체에 가해지

는 다양한 규제를 고쳐보자는 노력이 전개됐지만, 다시 한편에서는 게

임 셧다운제를 들고 나와 게임업체를 제재하는 형국이 됐으니 말이다.

셧다운제를 도입하는 건 신생업체에게 일종의 진입장벽이다. 심야에

청소년의 게임 사용을 제한하는 시스템을 도입해야 하기 때문이다. 모

든 역량을 좋은 게임을 만드는 데 쏟아도 성공 여부가 불확실한데 그

역량의 일부를 정부 규제를 맞추는 데 써야 하기 때문이다. 그뿐만 아

니라 형평성에도 어긋난다. 해외에서 사업을 하는 게임업체는 어떻게

할 것인가? 국내법으로 제재하지 못하기 때문에 해외 업체에게는 게

임 셧다운제가 아무 소용이 없다.

1　 국내 아이폰 앱스토어에는 게임 카테고리가 얼마 전까지 없었다가 최근에야 생겼다.


대한민국 IT 업계의 블랙코미디는 이뿐만이 아니다. 세계는 SNS에

서 비즈니스를 창출하고 있는데 국내는 아직도 포탈에 머물고 있고,

자고 나면 해킹으로 털리는 신상정보가 된 탓에 대한민국의 주민등록

번호는 더는 개인정보가 아니며, 국내 굴지의 소프트웨어 회사가 오픈

소스를 전혀 사용하지 않고 토종 기술로 윈도우 호환 운영체제를 만들

었다고 거짓말했다가 그 진실이 만천하에 드러난 IT계의 황우석 사건.

이것 말고도 정말 다양한 에피소드가 많다. 이런 에피소드를 모아 대

한민국 소프트웨어 업계를 주제로 드라마를 만든다면 막장 드라마 시

청률에 육박하는 결과를 얻을 수 있지 않을까?

이처럼 소프트웨어 개발을 타이틀로 건 막장 드라마가 펼쳐지는 가

운데 클라이맥스가 펼쳐진다. 아이폰발 모바일 혁명으로 촉발된 IT 혁

신 때문에 국내 휴대폰 제조업체가 위기에 처한다는 에피소드다. 상황

이 심각하게 돌아가자 언론에서는 위기의 원인을 소프트웨어에 있다

고 진단했다. 그리고 사람들도 대한민국의 소프트웨어가 위기라고 인

식하고 정부와 공기업, 대기업을 중심으로 대한민국의 소프트웨어를

살리겠다는 정책이 발표되고 실천에 옮기려고 한다. 업계의 한 사람으

로서 이유야 어떻든 소프트웨어의 중요성이 부각되는 것은 기분 좋은

일이다.

하지만 그동안 정부 주도 사업이 보여준 관료주의적 결과물에 익숙

해진 나머지, 정부 주도로 무엇을 만든다는 이야기에 그다지 호의적인


평가를 내리지 못하겠다는 반응도 많다. 대기업은 소프트웨어가 중요

해지자 자체적으로 소프트웨어 인력을 키우려고 전방위적으로 소프

트웨어 인력을 뽑고 있다. 대기업의 상대적인 복지 혜택에 이끌려 옮겨

가는 인력 때문에 중소 소프트웨어 업체에서는 인력난에 허덕인다.

여기저기서 들리는 대한민국 소프트웨어를 둘러싼 이야기와 움직임

은 마치 질풍노도의 사춘기 청소년의 행동처럼 충동적이고 돌발적이

어서 앞을 내다보기가 쉽지 않다. 빠르게 변하고 다양한 담론이 펼쳐지

는 대한민국 소프트웨어 환경에서 인생의 황금기를 온전히 소프트웨

어 개발을 하면서 보내는 사람으로서 과연 좋은 소프트웨어를 만들려

면 어떻게 해야 할까, 라는 의문이 들었다.

이 질문에 답하려면 좋은 소프트웨어란 무엇인가?부터 정의해야 한

다. 구글의 검색 엔진, 트위터, 페이스북, iOS, 안드로이드. 일단 좋은

소프트웨어라는 단어를 들으면 이런 소프트웨어가 떠오른다. 이런 소

프트웨어는 좋은 소프트웨어일까? 소프트웨어를 어떻게 개발하고 소

프트웨어가 어떻게 작동하는지조차 모르는 사람들에게 물어도 이런

소프트웨어는 좋은 소프트웨어라고 평가할 것이다. 당연하다. 이런 소

프트웨어는 좋은 소프트웨어가 맞다.

에버노트(http://evernote.com)라는 서비스가 있다. 에버노트는 아이

폰과 같은 스마트폰으로 메모를 간단하게 적고 다양한 IT 기기에서 자

신이 적은 메모를 동기화하는 서비스다. 에버노트는 좋은 소프트웨어


일까? 이 소프트웨어가 좋은 소프트웨어냐고 묻는다면 많은 사람들

이 쉽게 답하지 못할 것이다. 왜냐면 에버노트를 사용해 본 사람들이

아니라면, 그리고 사용했다고 하더라도 자신이 필요를 느끼지 못하는

사람이라면 사용하기 편리하더라도 좋은 소프트웨어라고 평가하기가

쉽지 않기 때문이다. 여기서 좋은 소프트웨어를 정의할 때 고려해야

할 요소가 하나 나온다. 바로 소프트웨어의 사용자가 누구냐라는 것

이다.

사용자가 어떤 필요에 의해 소프트웨어를 사용하느냐에 따라 좋은

소프트웨어와 나쁜 소프트웨어가 결정될 것이다. 예를 들어, 많은 사

람들이 iOS가 좋은 소프트웨어라고 평가하더라도 휴대폰의 다양한

설정을 임의로 변경하고 싶은 사람은 iOS에 후한 점수를 주지 않을 것

이다. 안드로이드가 iOS보다 안 좋은 부분도 있지만 이 사람은 안드로

이드를 사용하면 iOS보다 손쉽게 스마트폰 설정을 할 수 있기에 안드

로이드가 더 좋은 소프트웨어인 셈이다.

좋은 소프트웨어를 정의하려면 대상 사용자가 있어야 한다. 투자자

나 경영자 입장에서는 적은 돈을 들여 많은 돈을 벌어들이고 시장점유

율을 세계 최고로 만들어 전 세계 사람들이 자사를 인식하게 해 주는,

예를 들자면 구글의 검색엔진이나 iOS, 안드로이드 등이 좋은 소프트

웨어라 생각할 수 있다. 하지만 백인백색이라 했듯이 세상엔 다양한

사람들이 있고 그들에게 맞는 좋은 소프트웨어란 모두 다른 법이다.


좋은 소프트웨어에 대해 장황하게 설명한 이유는 이렇다. 우리가 제

조업 분야에서 유발된 소프트웨어 위기라는 말은 상당히 허구에 가깝

다. 어떻게 보면 언론이나 정부에서 호들갑을 떠는 소프트웨어 위기는

제조업의 붕괴를 걱정한 담론에 불과하다고 생각한다. 과거 제조업의

우위는 거의 제조역량에 달려 있었다. 하지만 제품에서 소프트웨어가

차지하는 비중이 커지면서 더는 제조역량에 의존해 비교우위를 점할

수 없게 됐다. 바로 여기서 소프트웨어 위기론이 등장한다.

극단적으로 말해서 내가 GW-Basic으로 프로그래밍을 처음 시작

했을 때부터 대한민국 소프트웨어는 늘 위기였다. 단돈 500원만 주면

5.25인치 플로피 디스크에 미국에서 나온 최신 게임을 불법 복사해서

즐길 수 있었다. 이런 상황은 국내에서 나온 게임도 마찬가지다. 열정과

돈을 들여 선배 개발자들이 만든 게임을 단돈 500원이면, 아니 친구에

게 말만 잘하면 공짜로 내 컴퓨터에서 즐길 수 있었다.

이런 상황은 시간이 흘러도 그다지 개선되지 않았다. 가끔 불법복제

단속을 피하려고 정부, 학교, 회사에서 선심 쓰듯이 소프트웨어를 구

매하는 것 말고는 소프트웨어는 공짜라는 인식이 팽배했다. 결국 대한

민국의 소프트웨어 시장은 애초부터 형성되지 않았고 꿈과 열정으로

버티고 버틴 개발자들 덕분에 그 명맥을 유지했다.

이런 상황 탓에 많은 개발자들은 자신의 이름으로 소프트웨어를 만

들어 팔기보다 월급쟁이가 되는 길을 택했다. 말하자면 유명 포탈 회


사에 취직하거나 온라인 게임 개발자가 되거나 대기업에 들어가 휴대

폰이나 전자제품에 탑재되는 임베디드 소프트웨어를 개발하면서 월

급을 받았다. 소프트웨어 개발자는 많지만 정작 대한민국이라는 타이

틀을 걸고 내세울 만한 변변한 소프트웨어가 나오지 않게 된 배경은

이렇다.

좋은 소프트웨어란 무엇인가? 정부나 대기업에서 걱정하는 제조업

을 떠받쳐줄 그런 소프트웨어만이 좋은 소프트웨어가 아니다. 전 세계

를 호령하는 페이스북, 트위터, 구글과 같은 서비스를 제공하는 것만

이 좋은 소프트웨어가 아니다. 물론 그런 것도 좋은 소프트웨어가 맞

다. 내가 이야기하고 싶은 바는 지금 우리가 걱정하는 그런 휘황찬란

한 소프트웨어만이 좋은 소프트웨어는 아니라는 점이다.

개인이 필요하면 돈을 내고 만족하면서 쓸 수 있는 소프트웨어가 바

로 좋은 소프트웨어다. 그리고 그런 소프트웨어를 만드는 회사가 많아

진다면 비로소 구글, 페이스북, 트위터, 안드로이드, iOS와 같은 파급

력 있는 서비스나 소프트웨어가 대한민국을 대표하는 소프트웨어라

는 타이틀을 걸고 나올 것이다. 그렇다면 좋은 소프트웨어를 만들려

면 어떻게 해야 할까? 이 질문에 답하기 전에 한 가지 이야기를 더 해

야겠다.

학교에서 문제아로 낙인 찍힌 학생들을 처리하는 방법으로 전학을

이용할 때가 있다. 그런데 그렇게 전학 간 학생이 다시 문제를 일으키

면 그 학교에서는 다시 다른 학교로 전학을 보내 버린다. 그다지 좋은


표현은 아니지만 이를 폭탄 돌리기라고도 한다. 말하자면 언제 터질지

모르는 폭탄을 다른 사람에게 넘기는 것처럼, 문제 학생이 언제 큰 사

고를 칠지는 모르지만 일단 자신의 학교에서만 치지만 않으면 된다는

생각으로 학생을 전학시키는 것이다.

물론 이런 문제 학생을 전학시키는 조치는 해당 학교만의 문제가 아

닐 것이다. 근본적으로 문제 학생을 학교에서만 다루게 하는 현행 교육

체계가 더 큰 문제다. 학교에서는 어떻게든 해결하려고 하지만 현실적

으로 문제아를 다룰 만한 적절한 해결책이 없기에 그런 방법을 사용할

때가 많을 것이다. 그렇다고 면죄부를 받는 건 아니다.

문제 학생을 처리하는 방법은 전형적인 대증요법에 가깝다. 근본 문

제를 처리하기보다 표면상의 문제만 터지지 않으면 괜찮다는 태도가

만연할 때 이런 대증요법이 선호 1순위가 된다. 그런데 근본 문제를 해

결하려면 대개 전체를 뜯어고쳐야 하므로 전체적인 권한을 지닌 사람

이 욕 먹을 각오를 하고 소매를 걷어 올리고 나서지 않으면 안 된다.

소프트웨어를 만드는 조직에서도 문제아를 다루는 듯한 대증요법

에 의존하는 경우를 자주 봤다. 제대로 된 소프트웨어를 만들려면 형

편없는 소프트웨어를 만드는 근본원인을 해결해야 한다. 하지만 그런

원인을 잘 알고 있는 실무자들이 형편없는 소프트웨어를 만들어내는

요인을 공공연하게 이야기해야 하는데 그게 쉽지 않다. 그런 이야기를

하면 일단 맡은 일이나 잘하라는 핀잔을 받기 십상이다.


이런 핀잔을 들을 각오로 관리자에게 임시방편으로 소프트웨어를

업그레이드하고 대응하면 더 큰 문제가 터질 것이라고 보고해도 최고

경영자의 눈치를 봐야 하는 관리자들은 일단 폭탄을 자신이 갖고 있

다는 사실을 말하기가 상당히 껄끄럽다. 그러다 보니 다른 부서에 폭

탄을 돌리게 되고, 결국 그 폭탄 때문에 회사는 큰 위기를 맞게 된다.

대한민국에서 좋은 소프트웨어가 나오지 않는 이유는 뭘까? 문제아

를 고치려면, 아니 문제아가 나오지 않게 하려면 문제아를 만드는 환경

을 뜯어고쳐야 한다. 좋은 소프트웨어가 나오지 않는 이유도 이와 비

슷하다. 좋은 소프트웨어가 나올 만한 환경이 아니라서 정부나 회사에

서 그토록 바라는 좋은 소프트웨어가 나오지 않는 것이다. 이 책에서

는 좋은 소프트웨어를 만들려면 무엇을 고쳐야 할지 살펴보겠다. 여기

서 다루는 내용은 새로운 것이 아니다. 우리가 몰라서 안 하는 것도 아

니다. 그동안 선배들이 그렇게 했기에, 사회가 그렇게 요구했기에, 그렇

게 개발하고 만들었기에 대한민국의 소프트웨어는 지금의 상황에 처

한 것이다.

어떻게 보면 이 책에서 다루는 이야기는 회사 혹은 개발팀의 미시적

인 차원의 노력인 셈이다. 주차장 지붕 사건, 게임 셧다운제와 같은 이

슈는 일개 회사가 바꿀 수 없는 것이다. 거시적인 차원의 문제도 더 나

은 소프트웨어를 만들려면 반드시 해결해야 할 것이다. 물론 이 세상

은 거시적인 것도 바뀌어야 하지만, 우선 미시적인 변화가 있어야 거시

적인 변화도 생긴다고 본다.


인간이 평등하게 사는 세상을 만들려면 우선 가정에서 남편과 아내

가 평등해야 하고 부모와 자식이 종속관계가 아닌 수평적인 관계여야

한다. 즉, 가정이라는 미시공간에서의 노력이 현실화되고, 그런 노력이

응축될 때 우리 사회가 평등화되는 거시적인 변화가 일어난다고 생각

한다. 폐를 잘라낸 개발자, IT계의 황우석 사건 같은 문제는 우리가 속

한 조직에서도 얼마든지 개선할 수 있는 미시적인 문제다. 자, 그렇다

면 좋은 소프트웨어를 만들려면 어떻게 해야 할까? 지금부터 대한민

국 소프트웨어, 리스타트를 위해 달려보자.

P A R T

01

소프트웨어 엔지니어링을 지배하라!


좋은 제품을 만들려면 회사의 엔지니어링 역량이 뛰어나야 한다. 물론

소비자가 원하는 바를 정확하게 파악하는 능력, 소비자의 마음을 사로

잡는 멋진 디자인, 소비자의 시선을 끄는 광고, 영업, 고객 서비스 모두

중요하지만 품질이 뛰어난 제품을 만들려면 그런 제품을 만들 수 있는

엔지니어링 역량이 중요하다. 이런 논리를 적용한다면 소프트웨어 개

발에서도 소프트웨어 엔지니어링이 매우 중요하다.

그렇다면 소프트웨어 엔지니어링은 기계공학이나 전자공학과 같은

수준의 엔지니어링이라고 할 수 있을까? 일단 내 생각은 소프트웨어

엔지니어링이 엔지니어링이란 타이틀을 지니곤 있지만 일반적으로 생

각하는 수준의 엔지니어링은 아닌 듯하다. 우선 소프트웨어 엔지니어

링이 공학이 아니냐 맞냐를 이야기하려면 공학의 정의를 내려야 할 것

같다. 구글에서 ‘공학’으로 검색하면 위키피디아의 정의가 가장 먼저 나

오니 그것으로 이야기를 전개해 보겠다.

공학(工學, Engineering)은 인류의 이익을 위해 과학적 원리, 지

식, 도구를 활용해 새로운 제품, 도구 등을 만드는 것이다.

소프트웨어 공학을 사용해 새로운 소프트웨어나 도구를 만들어 내

기 때문에 공학이라고 할 수 있으나, 중요한 것은 소프트웨어 공학이

라고 하려면 반드시 과학적 원리, 지식, 방법을 사용해야 한다는 것이

다. 토목공학이 생기기 이전인 중세 시대에도 대성당이나 성과 같은 대

1부 _ 소프트웨어 엔지니어링을 지배하라! | 29

규모 석조 건물을 지었다. 그 당시에 사람들이 대규모 건물을 지었으니

그 사람들도 토목공학을 썼다고 할 수 있을까?

중세 시대의 사람들은 예전부터 전해 내려오거나 자신들이 시행착

오를 겪으면서 터득한 노하우를 써서 건축물을 지었을 것이다. 가상의

예를 들면 이런 것이다. 터를 다질 때 양을 잡아 제사를 지내지 않으

면 터가 잘 안 잡혀서 건물이 무너진다고 믿는 장인이 있다고 하자. 그

래서 이 사람은 항상 큰 석조 건물을 지을 때 터를 다지기 전에 반드시

제사를 지내는 것을 주요한 공정으로 넣는다고 해보자. 또 그렇게 지

어서 건물이 무너지지 않는다면 이 사람이 지내는 고사라는 건 올바

른 방법일까?

조금 비약적인 예이기는 하지만 어떤 방법을 쓰든 과거에도 대규모

건축물을 지었지만 토목공학을 이용해 건물을 지었다고 보지는 않는

다. 대신 장인의 기술과 약간의 공학적인 기초 지식을 활용해 건물을

지은 것이다. 하지만 오늘날 기초를 다지는 것은 공학적인 판단을 토대

로 진행된다. 단지 고사를 지내면서 터 다지기가 잘 되기만을 바라진

않는다. 그것이 가능한 이유는 토목공학을 뒷받침하는 과학적 지식이

있기 때문이다.

어릴 때부터 컴퓨터를 접하고 지금도 소프트웨어를 만드는 일을 업

으로 삼고 있지만 내 전공은 기계공학이다. 그래서 난 항상 소프트웨

어를 만드는 것과 기계를 만드는 것의 유사성과 상이점을 생각해 본


다. 기계공학을 활용해 제품을 만드는 경우를 살펴보겠다. 뜨거운 유

체가 흐르는 파이프를 만드는 업무가 생기면 엔지니어가 설계한 파이

프가 공학적으로 안전하고 성능을 만족할 수 있을지 증명해 줄 도구

(과학적)가 기계공학엔 정말로 많다.

재료역학을 활용하면 인장강도, 전단강도, 비틀림 토크, 항복강도,

피로파괴 여부 등을 계산해 파이프가 망가지지 않을지 알 수 있다. 열

역학을 활용하면 뜨거운 유체가 흐르면서 파이프로 얼마만큼의 열이

뺏길지, 열이 빠져나가지 않으려면 단열저항으로 얼마를 써야 할지 알

아낼 수 있으며, 유체역학을 활용하면 일정량의 유체를 단위 시간당

흘려 보내려면 파이프의 지름은 얼마여야 하고, 파이프와 유체 사이에

유체 저항이 발생해 유속 감소가 일어나지 않는지를 모두 수식을 토대

로 계산해 낼 수 있다. 즉, 기계공학을 활용하는 엔지니어는 기계공학

이 의지하는 과학적 원리, 도구, 지식을 활용할 수 있다.

소프트웨어 분야에서도 마찬가지다. 메모장과 같은 간단한 소프트

웨어를 만든다고 했을 때도 만드는 사람에 따라 정말로 다양한 방법

을 써서 메모장을 만들 수 있다. 물론 프레임워크나 디자인 패턴을 활

용한다면 설계나 구현에서 차이점이 줄어들 수 있지만, 기계공학 측

면에서 보면 다양한 공학적 지식을 적용한 판단이라기보다 소프트웨

어를 개발하는 사람들의 경험에 따라 달라지는 경우가 많다고 볼 수

있다.


따라서 우리가 소프트웨어 엔지니어링이라고 하는 것은 어쩌면 토

목공학이 도입되기 이전에 대규모 건축물을 짓는 상태와 비슷하다고

할 수 있다. 우리가 활용하는 소프트웨어 엔지니어링에는 이산수학, 알

고리즘과 같은 배경 지식을 활용하는 것도 있지만 개발자의 경험에 따

라 소프트웨어를 개발할 때 적용되는 기술이 달라지기도 한다.

소프트웨어 엔지니어링이 완벽하게 성숙하지 않았다고 해서 우리가

제대로 일을 하지 못한다는 건 아니다. 우리가 만든 소프트웨어를 탑

재한 자동차가 거리를 누비고, 우리가 만든 소프트웨어가 탑재된 스마

트폰으로 친구들과 연락을 주고받을 수 있다. 소프트웨어 엔지니어링

의 수준이 완벽하지 않다 하더라도 우리는 소프트웨어 엔지니어링으

로 나름의 결과를 내온 셈이다.

소프트웨어 엔지니어링을 잘 활용해 훌륭한 성과를 낼 때도 있지만

내가 직간접적으로 경험한 어떤 프로젝트에서는 소프트웨어 엔지니어

링을 제대로 활용하지 못해 그 결과가 처참한 경우도 있었다. 먼 미래

에는 소프트웨어 엔지니어링의 수준이 한 차원 더 높아져 다른 공학

분야처럼 더 나은 소프트웨어를 만드는 데 크게 기여할 때가 올 것이

다. 하지만 현재 상황에서 최적의 결과를 내놓으려면 현재의 소프트웨

어 엔지니어링이 지닌 장단점을 정확하게 파악해 활용하는 능력을 키

우는 것이 중요하다. 자, 그렇다면 지금부터 완전하지는 않지만 그래도

유용한 소프트웨어 엔지니어링을 잘 활용하는 방법을 알아보자.


정도의 차이가 있을 뿐 요구사항 명세는 개발의 핵심이다

프로젝트의 실패 원인을 요구사항이 정확하게 정의되지 않아서라고

보는 보고서나 연구 결과가 많다. 이런 이유로 프로젝트를 할 때마다

요구사항을 명확하게 정의하고 나서 다음 단계로 넘어가는 게 중요하

다고 한다. 그런데 현실을 보면 그렇지 않다. 요구사항을 작성하는 게

중요하다고 하지만 실제 현장에서는 요구사항 정의 작업이 있더라도

그런 활동을 하면서 완벽한 요구사항 명세서를 작성하는 경우가 매우

드물다.

협력업체와 함께 GUI가 복잡한 소프트웨어를 개발하는 프로젝트의

PM을 맡은 적이 있다. 이때가 처음으로 갑으로 일할 때였다. 그전까지

갑이 요구사항을 명확하게 정의하지 않아 개발할 때 어려움을 많이 겪

었다. 이 점이 을의 입장에서 일할 때 가장 큰 불만이었기에 갑이 되면

요구사항을 명확하게 정의해서 협력업체에 넘겨 주고 싶었다. 이런 이

유로 협력업체에 의뢰한 개발 영역에 대한 요구사항을 명확하게 정의하

고자 요구사항 명세서(Requirement Speci�cation)를 작성했다.


사실 그전까지 요구사항 명세서를 아주 상세하게 작성한 경험이 없

었다. 단지 고객과의 인터뷰나 사전 조사를 통해 고객이 원하는 바를

듣고 고객의 요구사항을 만족하려면 어떤 기능이 필요한지 정리한 게

전부였다. 그리고 이렇게 정리한 내용을 토대로 고객이 사용할 화면 기

준으로 GUI 설계서를 작성했다. 지금도 이런 식으로 프로젝트가 진행

되는 현장이 많을 것이다.

막상 협력업체에 넘길 요구사항 명세서를 작성하려니 난감했다. 고

객 회사에서 진행되는 우리 회사 프로젝트와 협력업체가 물리적으로

따로 떨어져 있어 의사소통 문제가 있을 것으로 생각했다. 이런 문제를

최소화하려면 요구사항 명세서를 세부적인 상황까지 작성해서 넘겨야

할 것 같았다. 같은 곳에서 작업을 하는 프로젝트 팀원이라면 오해가

있을 때 간단한 대화로 풀 수 있는 내용도, 세부적으로 정리하다 보니

요구사항 명세서의 분량이 점점 늘어났다. 몇 페이지로 끝날 거라 생각

한 요구사항 명세서 작업은 그 자체가 하나의 프로젝트로 바뀌었다.

물론 요구사항 명세서를 명확하게 작성하다 보니 불명확한 요구사

항이 정리되는 이득도 있었지만 세부적인 내용까지 완벽하게 정리했어

도 요구사항 명세서를 읽는 협력업체 사람에 따라 그 해석을 달리하는

경우도 있었다. 이러한 경우 요구사항 명세서대로 기능이 구현되지 않

을 때도 잦았다. 처음 요구사항 명세서를 작성할 때 의도한 것처럼 요

구사항 명세서를 완벽하게 작성한다고 해서 의사소통 과정에서 오류

가 완전히 없었던 것도 아니고 개발 단계에서 요구사항 때문에 변경이


없었던 것도 아니다. 흔한 말 몇 마디로 넘겨주는 갑의 요구사항보다

상황은 많이 좋았지만 요구사항 명세서 작성과 그것을 협력업체에 이

해시키는 데 적지 않은 시간과 노력이 들었다.

애자일 방법론을 적용해 프로젝트를 수행하면 요구사항 명세서가

상당히 간략해진다. 애자일 방법론을 적용할 때는 팀원들이 프로젝트

가 시작할 때부터 종료할 때까지 하나의 팀이 되어 프로젝트를 수행하

기 때문에 프로젝트 첫날부터 마지막 날까지 고객이 어떤 요구를 하고

어떤 변경을 요구했는지 개략적으로 파악하기 쉽다. 따라서 애자일 방

법론을 적용하는 프로젝트는 물리적으로 분리된 곳에서 일하는 조직

이 요구사항 명세서라는 문서에만 의존해 파악하는 것보다 더 자세한

사항을 알 수 있다.

애자일 방법론을 적용한다고 이런 암묵적인 지식이 자동으로 습득

되는 건 아니다. 애자일 방법론을 철저하게 적용하려는 노력이 필요하

다. 스크럼을 사용하든 XP를 사용하든 사용자의 요구사항을 암묵적

으로 변형하는 과정에서 팀원들의 적극적인 참여가 필요하고, 이런 참

여를 토대로 만들어진 기능을 프로젝트 초반부터 고객에게 보여줌으

로써 피드백을 받고 그 결과를 반영하는 일련의 과정이 필요하다. 일반

적인 방법에 따라 개발하는 프로젝트 팀에서 문서화된 요구사항에 의

존하던 것을 프로젝트 팀원들의 팀 활동과 그 과정에서 형성된 암묵적

지식을 바탕으로 개발하는 것이다.


그렇다면 요구사항 명세서를 명확하게 작성하는 건 의미가 없는 걸

까? 절대 그렇지 않다. 이것은 상황에 따라 다르다. 애자일 방법론을 써

서 요구사항 명세를 굳이 문서화하지 않아도 팀원들의 암묵적인 지식

으로 전환할 수 있는 팀이라면 요구사항 명세서를 자세하게 작성하는

게 낭비일 수 있다. 하지만 이런 상황이 아니라면 요구사항 명세를 작

성하는 건 상당히 의미 있는 일이다. 요구사항 명세서는 어떤 상황에

서 자세하게 작성해야 할까? 내가 요구사항을 명확하게 작성하려고 노

력했던 프로젝트가 여기에 해당한다.

물리적으로 분리돼 있는 프로젝트 팀이나 기능 조직으로 구성된 회

사처럼 의사소통을 실시간이 아닌 메일이나 정기적인 회의로 하는 곳

이라면 요구사항 명세서를 반드시 작성해야 한다. 이런 조직에서는 요

구사항 명세서가 네트워크를 타고 전파되기 때문에 마치 요구사항 명

세서가 전부인 것처럼 보이는 경향이 있다. 이런 폐해가 발생할 때가 있

지만 그래도 요구사항 명세서를 잘 작성하는 게 중요하다.2 관료적인

분위기에서 요구사항 명세서조차도 명확하게 하지 않으면 늘 목소리

크기로 싸움이 결판나기 때문이다.

2　 이런 폐해를 예방하는 방법은 아키텍트 편을 읽어보자.


요구사항, 요구사항 명세, 설계는 다르다

요구사항 명세서가 중요하다고 하더라도 막상 요구사항 명세서를 작성

하려면 난감할 때가 많다. 도대체 어디까지 요구사항 명세서를 작성해

야 할지 감이 잡히지 않기 때문이다. 요구사항 명세서의 작성 범위를

정확하게 파악하려면 요구사항, 요구사항 명세, 설계의 차이를 살펴보

는 게 좋다.

요구사항이라고 하면 흔히 사용자의 요구사항을 떠올리지만 소프트

웨어를 성공적으로 개발하려면 다양한 이해당사자의 요구사항을 적

절하게 반영하는 게 중요하다.3 이해당사자의 니즈를 반영하는 요구사

항은 대개 자신들이 피상적으로 원하는 것이나 있으면 좋을 듯한 것을

말할 때가 많아서 모호하며, 이런저런 제약조건을 고려하지 않고 말하

는 것이라서 다양한 이해당사자에게서 수집한 요구사항 사이에 모순

이 발생할 때도 흔하다.

고객의 불만사항을 종합적으로 관리하는 시스템을 만든다고 가정

3　 이해당사자에 대한 정의는 ‘이해당사자의 역학관계를 파악하자’에 있다. 이해당사자의 개념을

정확하게 알고 싶은 독자는 해당 장을 먼저 읽어보자.


해보자. 이 프로젝트에도 다양한 이해당사자가 있을 것이다. 우선 불만

사항을 웹상에 입력하는 고객 입장에서 “불만사항을 간단하게 입력하

고 빨리 처리되어 그 결과를 실시간으로 알려줬으면 좋겠다”라는 요구

사항이 있고, 이런 불만사항을 처리하는 담당자 입장에서는 “업무량

을 고려해 처리 가능한 불만사항만 할당받았으면 좋겠다”라는 요구사

항이 있을 수 있다. 고객이 바라는 즉각적인 불만사항 처리라는 요구사

항과 담당자 입장에서 업무량을 고려한 불만사항 처리라는 요구사항

은 서로 모순되는 요구사항이다.

아울러 고객이 빨리 처리됐으면 좋겠다고 말했을 때 ‘빠른 처리’에

대한 기준도 상당히 모호하다. 어떤 고객은 불만사항을 접수한 후 하

루 정도 지나고 나서 처리돼도 빨리 처리됐다고 생각할 수도 있고 접수

후 한 시간 만에 처리돼도 늦게 처리됐다고 생각할 수도 있기 때문이

다. 담당자 입장에서 말한 ‘업무량을 고려한 적절한 처리’도 마찬가지

다. 하루에 1건을 적당하다고 생각하는 직원이 있을 수도 있고 한 시간

에 1건을 적당하다고 생각하는 직원이 있을 수도 있기 때문이다.

간단하게 살펴봤지만 이해당사자의 니즈를 모아둔 요구사항은 일단

모호하다는 것과 요구사항 사이에 모순이 있다는 특징이 있다. 여기서

요구사항과 요구사항 명세를 나누는 경계를 파악할 수 있다. 요구사항

명세는 요구사항에 있는 모호함과 모순이 명확함과 조화로 바뀌는 것

이다. 요구사항을 요구사항 명세로 전환하고자 흔히 요구사항 분석이

라는 작업을 한다. 요구사항 분석을 하면서 고객과 담당자 간에 상호


충돌하는 요구사항을 타협하고 적절한 중간 지점을 찾는 과정에서 기

존에 있던 모호함이 명확함으로 바뀐다.

프로젝트 팀에서 요구사항 분석가로 지정된 팀원이 서로 상충하는

고객 요구사항과 팀원의 요구사항을 해결하고자 통계적 기법을 사용

해 고객이 빠른 처리라고 느낄 만한 불만사항 처리 기간을 도출했으며,

아울러 기존 업무 처리 현황 자료와 고객 불만사항 처리 담당자의 인

터뷰를 토대로 적절한 처리량을 도출했다. 이렇게 정량화한 자료로도

두 이해당사자의 요구사항에 있는 간극을 줄일 수 없을 때 프로젝트

의사결정권자에게 보고해 적절한 선을 찾을 수 있게 한다.

결국 이런 요구사항 분석 과정을 거쳐 정리된 것이 바로 요구사항 명

세다. 말하자면 요구사항 명세서에는 “빨리 처리됐으면 좋겠다”라는 요

구사항과 “업무량을 고려해 일을 처리하면 좋겠다”라는 모호한 요구

사항이, “시간이 어느 정도 걸리면 빠르다고 느낄지”, “처리량이 하루

평균 몇 건이면 적절하다고 느낄지”가 정량화되어 기록된다.

아울러 요구사항 분석이나 요구사항 명세서 작성에는 모두 한 가지

답만이 있는 활동이 아니다. 앞서 살펴본 예처럼 통계, 인터뷰, 기존 자

료조사 등을 활용해 요구사항 분석을 수행할 수도 있다. 그리고 이처

럼 요구사항을 분석한 결과를 사용자 스토리 카드처럼 간단한 방법으

로 요구사항 명세서로 표현하거나 유스케이스를 이용해 회사마다 나

름대로 정의해둔 요구사항 명세서로 정리할 수도 있다. 핵심은 요구사

항 명세서를 작성할 때 어떤 방법을 쓰든 요구사항에 있는 모호함과


모순이 요구사항 명세서로 적힐 때 명확하고 조화롭게 정리돼야 한다

는 것이다.

요구사항 분석을 마친 불만사항 처리 시스템의 요구사항 명세서에는

다음과 같은 내용이 적힐 것이다.

• 고객이 입력한 불만사항은 최소 1시간, 최대 4시간 안에 처리돼야 한다.

• 처리 후 결과는 상담원이 고객의 휴대폰으로 전화로 통보한다.

• 아울러 그 결과는 SMS와 메일로 통보돼야 한다.

• 상담원이 처리할 수 있는 일일 불만사항은 최대 7건, 최소 2건이다.

그렇다면 요구사항 명세와 설계에는 어떤 차이가 있을까? 우리가 해

결해야 할 문제를 명확하게 기술한 것이 요구사항 명세였다면 설계는

해결책의 영역이라고 할 수 있다. 따라서 요구사항 명세는 소프트웨어

로 어떻게 구현할지 설명하지 않지만 요구사항을 해결책으로 구현할 때

해결책을 고민해야 하는 방향을 제시하고 한편으로 제한하기도 한다.

요구사항은 크게 기능 요구사항과 비기능 요구사항으로 나뉜다. 비

기능 요구사항은 기능 요구사항을 제외한 모든 요구사항을 말한다. 메

일 시스템에서 메일 보내기와 메일 받기가 기능 요구사항이라면 “메일

의 용량은 최대 2GB로 제한한다.”는 비기능 요구사항에 해당한다. 앞

에서 요구사항이 방향을 제시하고 제한하기도 한다고 했는데, 바로 비

기능 요구사항이 주로 이런 역할을 한다.


불만사항 처리 시스템에서 설명한 요구사항 명세 가운데 “불만사항

은 1~4시간에 해결돼야 한다.”와 “상담원이 처리할 수 있는 불만사항

은 2~7건이다.”가 바로 비기능 요구사항 명세다. 기능은 아니지만 시스

템을 구현하고 나서 우리가 제대로 시스템을 구현했는지 확인하는 주

요 기준에 해당하는 요구사항이기 때문이다. 물론 이런 기준을 만족시

키려면 단순히 소프트웨어 개발만으로 가능하지 않다.

이는 몰려드는 불만사항에 비해 처리할 상담원 수가 적다면 이러한

비기능 요구사항을 충족시킬 수 없기 때문이다. 따라서 시스템을 설계

할 때 적절한 상담원 수를 고려해 상담원이 불만사항을 비기능 요구사

항에서 제시하는 수준으로 처리할 수 있게 시스템을 만들어야 한다.

이런 맥락에서 요구사항은 해결책을 고민해야 하는 방향이나 범위를

제한한다고 할 수 있다.

설계와 요구사항이 어떻게 다른지 한 번 살펴보자. 최근 화두가 되

는 안드로이드 폰의 OS를 포팅하는 프로젝트가 있다고 하자. 마케팅

부서에서 시장조사를 한 결과, 소비자가 빠른 UI 반응성을 원한다는

요구사항을 제시했다고 하자. 소프트웨어 개발 팀에서 이 요구사항을

달성하려면 요구사항을 분석해 요구사항 명세로 만들어야 한다.

요구사항 명세를 만든 결과, “사용자가 UI를 터치한 후 0.5~0.8초 안

에 원하는 결과가 출력돼야 한다”로 비기능 요구사항이 정리됐다. 이

비기능 요구사항을 만족하려면 소프트웨어만으로는 불가능하다. 하

드웨어가 사용자의 터치를 인식해 소프트웨어에 전달하는 데 얼마나


걸리고, 소프트웨어에서 처리한 결과를 하드웨어에 전달했을 때 하드

웨어가 그 결과를 화면에 표시하는 데 얼마나 걸릴지도 정의해야 하기

때문이다.

비기능 요구사항을 토대로 하드웨어와 소프트웨어가 어떻게 처리할

지 결정하는 것을 시스템 설계라고 한다. 사용자 입장에서 터치하고

그 결과가 0.7초 정도 만에 나오면 만족할 만하다. 이런 과정에서 하드

웨어가 어떤 방식으로 터치를 인식하고 화면에 표시하며, 소프트웨어

가 어떤 연산을 했으며, 하드웨어와 소프트웨어 사이에 시간 분배를

어떻게 했는지 사용자 입장에서는 관심이 없다. 하지만 소프트웨어 개

발자는 이런 세부사항을 고려해 해결책을 만들어야 한다. 그래서 설계

를 해결책 영역이라고 한다.

요구사항 명세나 설계에 대해 이런 설명을 듣고 요구사항 명세서나

설계서에 무엇을 적어야 할지 감을 잡았더라도 막상 문서에 이런 내용

을 적으려고 하면 막막할 때가 있다. 일단 어떤 양식으로 이런 내용을

적을지 고민이 된다. 컨설턴트로 소프트웨어를 개발하는 조직을 두루

두루 다녀 보면 이런 문서가 많이 부족하다. 개발자는 직업명에서도

알 수 있듯이 개발이 주다. 따라서 이런 문서를 만드는 것을 가욋일로

생각하는 경향이 있다. 말 그대로 개발자이기 때문에 개발, 즉 코드를

만드는 일을 중요 업무라 여기기 때문이다.

굳이 문서를 만들라고 한다면 설계는 그나마 개발과 근접한 업무라서

설계서는 만든다. 하지만 설계보다 멀리 떨어진 요구사항 명세서는 거의


손대지 않는다. 그래서 요구사항 명세서의 상태는 설계서보다 안 좋다.

그리고 설계서라고 적혀 있지만 막상 열어 보면 요구사항이 적혀 있는

경우도 있고, 요구사항 명세서라고 적혀 있지만 그 안에는 아주 약간의

요구사항 명세와 나머지가 설계와 관련된 내용으로 채워진 경우도 있다.

문서가 아예 없는 것보다 부실해도 이런 문서가 있는 편이 낫다. 하

지만 더 좋은 소프트웨어를 만든다는 관점에서 보면 최소한 요구사항

명세서와 설계서는 분리하는 편이 좋다. 앞에서 설명했듯이 요구사항

명세와 설계는 본질적으로 다른 것이다. 요구사항 명세는 우리가 해

결해야 할 문제를 정의하는 것이고, 설계는 문제에 대한 답을 다는 것

이다. 교과서의 문제와 답처럼 정확하게 나누기가 쉽지 않다. 그리고

대개 문제를 고민해서 해결책을 생각하기 때문에 두 개를 분리해 내

기도 어렵다.

하지만 굳이 두 가지를 분리해 내라고 제안하는 것은 이런 작업을 의

식적으로 나눠서 하다 보면 두 가지 관점에서 통찰력을 얻을 수 있기

때문이다. 요구사항 명세서를 작성하면서 이해당사자가 소프트웨어를

사용했을 때 얻을 가치를 고민하게 된다. 한편으로 설계서를 작성할 때

는 오로지 구현 관점에서만 문제 해결 방법에 집중해서 고민할 수 있

다. 그리고 구현을 통해 해결책을 얻었을 때 분리된 요구사항과 설계에

대한 종합적인 통찰을 확보할 수 있다.

말하자면 요구사항 명세서나 설계서라고 적어 놓고 그 속엔 요구사

항과 설계가 혼재해 있을 때 이는 한마디로 사고가 정리되지 않은 것


이다. 즉, 해결해야 할 문제가 정리되지 않으니 해결책도 명확하게 정리

되지 않는다. 이런 이유로 요구사항 명세서와 설계서는 각각 작성해야

한다. 그렇다면 어떤 방식으로 정리해야 할까?

앞서 말했지만 각자의 환경에 맞는 것을 택하면 된다. 일반적인 요구

사항 명세서가 좋은 곳도 있고 스토리 카드, 유스케이스 등이 편한 곳

도 있을 것이다. 그렇다만 설계는 어떨까? 회사에서 독립적으로 정한

표기법을 써도 되고 UML이나 구조적 방법의 다이어그램을 써도 좋

다. 다만 그런 표기법을 보고 팀원들이 서로 다른 생각만 하지 않으면

된다. 형식도 중요하지만 더 중요한 건 요구사항 명세와 설계로 얻는

통찰이다.


회사에서 만드는 소프트웨어가 망해간다면 UX에 주목하자

『사용자 경험 스케치』(인사이트, 2010)라는 책을 읽다 보면 재미있는

이야기가 나온다. 그 이야기를 옮겨 보면 이렇다. 젖소가 나이를 먹으면

점점 생산하는 우유의 양이 줄어 든다. 이에 비해 젖소가 먹는 사료의

양은 일정하기 때문에 이 시점이 되면 젖소를 키워서 얻는 것보다 잃는

게 많아진다. 이 책에서 젖소 이야기를 하는 것은 나이 든 젖소가 우리

가 만드는 소프트웨어와 비슷한 특징이 있기 때문이다.

소프트웨어를 만들어서 판매하다 보면 여러 가지 이유로 해마다 새

로운 기능을 추가해서 업데이트한다. 그런데 문제는 여기에 있다. 해마

다 똑같은 개수의 기능을 추가해서 넣더라도 새로운 기능이 전체 기능

에서 차지하는 비중은 점점 줄어든다. 소프트웨어를 출시한 첫해에 기

능이 10개였고 10년 동안 매년 꾸준히 10개의 기능을 출시했다고 해

보자. 출시 후 1년이 지난 시점에 새로운 기능이 소프트웨어에서 차지

하는 비중은 반이겠지만, 10년 후에는 같은 노력으로 10개의 기능을

추가해도 새로운 기능이 차지하는 비중은 고작 10퍼센트에 불과하다.


문제는 새로운 기능을 추가하면서 기존의 기능을 개선하고 버그를

수정하는 작업도 병행해야 한다는 것이다. 게다가 이렇게 추가한 기능

이 사용자에게 인기를 얻으면 좋지만 개념 없이 기능만 추가했다가는

마이크로소프트에서 리본 인터페이스를 도입하기 직전에 경험한 기능

의 홍수에 시달릴 수도 있다. 아울러 기능의 홍수 때문에 사용자가 느

끼는 UX는 더욱 형편없어질 것이다.

그림 1 리본 인터페이스 이전의 워드 툴바

결론적으로 우유 생산량보다 사료비가 많이 든 늙은 젖소처럼, 우리

가 만드는 소프트웨어도 어느 시점에 이르면 새로운 고객을 유치하기

보다 유지비용이 많이 들게 된다. 그렇다면 어떻게 해야 할까? 우리가

지금까지 만들어 온 소프트웨어를 모두 버리고 원점에서 다시 만들어

야 할까? 물론 이것도 답일 수 있다. 하지만 다른 측면에서 답을 찾아

볼 수도 있다.


혁신의 간극(Innovation Gap)이라는 게 있다. 혁신의 간극은 일리노

이 공대의 디자인 연구소 학장인 패트릭 휘트니가 말한 개념이다. 기업

이 회사를 운영하면서 비즈니스와 기술의 생산능력이 늘면서 물건은

쉽게 만들어내지만 소비자의 욕구나 필요에 대한 감을 잃게 됐다고 한

다. 말하자면 기업의 운영 능력은 발달해서 효율적으로 제품을 만들게

됐지만, 실상 그렇게 만든 제품에는 고객, 즉 사용자가 그 제품을 현실

에서 어떻게 사용하는지에 대한 지식이 결여되어 제품은 점점 혁신적

이지 않게 된다는 것이다.

사내 지식

시간

고객이 일상에서원하는 것

회사에서제품을 만드는 방법

혁신의간극

그림 2 혁신의 간극

혁신의 간극이라는 개념은 우리가 만들어내는 소프트웨어가 정말

형편없는 소프트웨어가 되어 가는 이유를 잘 설명해 주는 것 같다. 초

기 시장에 제품을 출시할 때는 고객의 목소리에 기반을 둔 제품이었

다. 시간이 지나면서 회사 내 조직을 만들고, 프로세스를 구축하고, 도


구를 사용해 제품을 더욱 효율적으로 만들게 됐지만, 반대로 그런 과

정에서 초기 제품을 출시하게 해준 고객의 목소리는 사라지는 것이다.

사실 비용을 줄이고 시장에 제품을 빨리 출시하기 위해 조직을 효율

화하는 것을 게을리할 수 없다. 다만 그런 기업 내부의 논리에 매몰될

때 우리가 만들어내는 소프트웨어 때문에 고객들은 좌절하고 괴로워

하다 다른 제품을 찾아 떠날 수 있다.

우리가 UX라는 화두에 주목해야 하는 이유가 바로 여기에 있다.

UX를 방법론화하고 교조적으로 따른다면 또 다른 재앙의 시작이겠

지만 UX를 통해 우리가 그동안 놓친 고객에 대한 통찰을 확보할 수

있다면 늙어서 노쇠한 젖소를 새로운 캐쉬카우로 환골탈태할 수 있기

때문이다.


UX란 개발 이상의 것이다

이 글을 쓰는 시점에 애플의 아이폰4S가 발표됐다. 지금 쓰고 있는

아이폰의 약정기간은 이제 3개월밖에 남지 않았다. 국내에 아이폰이

나오자마자 구매해서 2년 가까운 기간 동안 사용한 셈이다. 지금까지

아이폰에 대한 내 점수는 100점 만점에 100점이다. 사용기간이 2년

이 다 됐기 때문에 배터리가 빨리 소모된다는 점을 빼면 정말 잘 만든

제품이다. 그동안 전자제품을 구입해서 쓰면서 이번처럼 만족한 적은

없었다.

아이폰을 사기 전까지 약간의 아픔이 있었다. 아이폰 출시 직전까지

아이폰은 ‘다음달 폰’이었다. 다음 달이면 반드시 출시될 거란 소문은

무성했지만 막상 다음달이 되면 그 다음달로 출시가 연기됐다는 소문

이 돌았기 때문이다. 다음달 폰에 낚여 휴대폰 교체 시기가 늦어지자

직장 동료가 구매한 윈도폰을 보고 충동적으로 똑같은 윈도폰을 구매

해 버렸다. 잠깐이나마 동료의 윈도폰을 사용했을 때 내가 스마트폰에

원하던 인터넷, 메일, 글쓰기 등이 모두 가능했기 때문이다. 하지만 이

선택은 내가 가전제품을 구입하면서 내린 결정 중 최악이었다.


메일 하나 보내기도 그다지 쉽지 않았고 인터넷은 모바일 페이지가

아니면 접속할 엄두를 내지 못했다. 이런 부가 기능이야 쓰지 않을 수

도 있다고 생각하면 속은 편하지만, 전화 기능이 제대로 동작하지 않

거나 알람만 믿고 잤다가 알람이 울리지 않아 몇 년에 한 번 할까 말까

하는 지각을 며칠 반복하고 나자 충동구매한 윈도폰에 대한 정이 떨어

지고 말았다. 그때 ‘다음달 폰’이 비로소 국내에 출시됐다. 일말의 미련

도 없이 위약금을 모두 물고 아이폰을 구매했다. 그리고 이렇게 한 것

은 내가 그동안 가전제품을 구매하면서 내린 결정 중 최고였다.

UX가 중요하다고 한다. 최악의 선택이었던 윈도폰과 최고의 선택인

아이폰을 두고 봤을 때 어느 쪽이 UX가 좋을까? 기능만 두고 보면 윈

도폰이나 아이폰은 거의 비슷하다. 전화도 되고, 문자도 보낼 수 있으

며, 메일과 인터넷, 그리고 프로그램도 사용자가 직접 설치할 수 있다.

굵직한 기능만 보면 윈도폰과 아이폰은 차이가 없다. 두 스마트폰의

차이점은 사용자가 직접 스마트폰을 사용할 때 발생한다.

같은 기능을 하는 스마트폰일지라도 아이폰 사용자가 윈도폰 사용

자보다 자신이 원하는 과업을 쉽게 처리할 수 있다. 과업을 처리하는

과정에서 사용자가 느끼는 경험의 질을 따진다면 단연코 아이폰 사용

자의 것이 윈도폰의 그것보다 우월할 것이다. 그리고 이런 UX의 차이

때문에 사용자는 적지 않은 돈을 지불하고도 같은 기능이 탑재된 윈

도폰이 아닌 아이폰을 택한다. 사용자의 굳게 닫힌 지갑을 쉽게 열게

하는 UX란 도대체 뭘까?


UX를 모르는 사람들에게 UX를 설명할 때 내가 가장 잘 인용하는

정의가 있다. 바로 닐슨 노먼 그룹의 정의다. 닐스 노먼 그룹의 UX 정의

를 옮겨 보면 이렇다.

1 우수한 UX의 기본적인 조건은 불편함 없이 고객의 요구사항을 만

족하는 것이다.

2 제품을 만들어내는 단순함과 우아함, 그리고 이런 단순함과 우아

함은 사용자가 제품을 소유하거나 사용할 때도 얻는 것이다. 진짜

UX란 사용자가 원한다고 말한 것이나 체크리스트에 있는 기능을

제공하는 수준 이상이다.

3 높은 수준의 UX를 회사에서 달성하려면 엔지니어링, 마케팅, 그래

픽, 산업 디자인, 인터페이스 디자인과 같은 다양한 분야의 서비스

를 완벽하게 융합해야 한다.

스마트폰의 UX를 생각해 보면 괜찮은 스마트폰이란 사용자가 메

일을 보내거나 전화를 걸거나 인터넷을 할 때 불편함이 없어야 한다

는 뜻이다. 요구사항 관점에서 보면 기능 요구사항이 제대로 구현돼

야 한다.

닐슨 노먼 그룹에서는 기본적인 기능이 제대로 구현된 것만으로 UX

가 뛰어나다고 보지 않았다. 닐슨 노먼 그룹에서 내린 UX에 대한 두 번

째 정의(2)의 핵심인 단순함과 우아함을 개발 관점에서 굳이 정의하자

면 비기능 요구사항으로 정의할 수 있다. 고객이 원하는 것과 체크리스

트에 있는 기능이 기능 요구사항에 해당한다면 비기능 요구사항은 기


능 요구사항을 제외한 것이므로 닐슨 노먼 그룹에서 말하는 단순함과

우아함은 비기능 요구사항에 해당한다.

그렇다면 소프트웨어 개발 관점에서 UX를 정의하면 UX란 우리가

개발해야 할 요구사항으로 정의할 수 있을까? 물론 도식적으로 닐슨

노먼 그룹에서 말하는 UX 정의를 기능 요구사항과 비기능 요구사항으

로 나눠 버리면 UX란 우리가 개발해야 할 요구사항 명세 정도로 환원

시킬 수도 있다.

하지만 닐슨 노먼 그룹의 나머지 정의(3)를 살펴보면 UX를 요구사항

명세로 환원할 수 없다는 사실을 알 수 있다. 소프트웨어 개발에서 가

장 중요한 시발점은 요구사항이라고 했다. 말하자면 소프트웨어 개발

을 이끌어 가는 인자는 요구사항 명세다. 따라서 요구사항을 명확하게

정의하는 것이 중요하다.

하지만 훌륭한 UX라는 것은 단순하게 소프트웨어 프로젝트 팀이

할당받은 요구사항 명세를 완벽하게 구현하는 것만으로 달성할 수 없

다. 마케팅, 그래픽, 산업 디자인, 인터페이스와 같이 소프트웨어와 완

전히 별개의 분야와 완벽하게 협업해야만 고품질의 UX를 얻을 수 있

다. 정리하자면 훌륭한 UX란 소프트웨어 개발 팀만이 노력해서 되는

게 아니다.

지인 가운데 휴대폰의 사용성과 관련된 일을 하는 사람이 있다. 그

분은 휴대폰의 사용성을 정량적으로 측정하는 작업을 오래전부터 해

왔다. 아이폰이 국내에 막 도입되려고 할 때 지인을 만나 휴대폰 UI와


관련한 이야기를 들었다. 지인이 일하는 조직에서 휴대폰의 사용성이

중요하다는 게 이슈가 되어 디자인 가이드 같은 것을 작성하게 됐다고

한다.

디자인 가이드 작업이 한창 진행될 무렵 해당 사업부의 담당임원을

대상으로 한 업무 보고가 있었다고 한다. 그 자리에서 담당임원은 당

시에 출시된 휴대폰의 UI에 대해 이렇게 촌평했다고 한다.

애플리케이션을 한참 쓰다가 종료하려고 종료 버튼을 누르려는데,

버튼이 너무 작아서 나 같이 나이 먹은 사람은 누르기 힘들 것 같

다는 생각이 들더군. 내 생각에 버튼 크기는 얼마 이상으로 딱 정

해서 디자인 가이드에 적어 놨으면 좋겠는데.

버튼이 커지면 누르기야 편해지겠지만 전체적인 UI 디자인이 변경

돼야 한다는 게 문제였다. 그런데 담당임원의 지시로 버튼 크기의 최솟

값이 디자인 가이드에 들어가면서 디자이너 관점에서는 영 마음에 들

지 않는 UI가 만들어질 형국이었다고 한다.

디자인 위원회라는 말이 있다. 디자인을 하거나 디자인을 평가할 때

위원회를 조직해 수행하는 것을 말한다. 대체로 이 디자인 위원회에서

만들어내는 디자인은 평균만 가더라도 잘 나온 결과다. 위원회의 특성

상 최적의 답을 찾기보다 위원끼리의 권력 구조나 협의의 결과가 반영

되기 때문이다.


디자인에서는 통일성이 무척 중요하다. 이런 통일성은 단순히 디자

인 가이드에 버튼 크기는 몇 픽셀 이상으로 할 것으로 정하거나, 디자

인 위원회에서 몇 날 며칠을 머리를 싸매고 토론한다고 해서 얻어지는

게 아니다. 특히 UX를 구성할 때 사용자의 마음속에서 UI를 사용하

면서 일관된 멘탈 모델을 구성할 수 있게 해야 한다. 이런 건 수천 페이

지에 달하는 디자인 가이드로도, 수백 명의 베테랑 위원으로도 달성

하지 못한다.

구글에서는 수많은 서비스를 제공한다. 구글의 서비스를 써보면 엔

지니어가 만든 것처럼 UI가 조금 부실하다는 생각이 든다. 하지만 쓰면

쓸수록 사용자 UI에 일관성이 있거나 UX가 동일하다는 느낌을 받는

것은 최근에는 어떤지 잘 모르지만 구글의 검색제품 및 고객서비스 부

문을 담당한 마리사 메이어 부사장 덕분이었다.

구글의 최종 서비스를 고객에게 제공하려면 반드시 메이어 부사장

의 손을 거쳐야 했다. 가령 구글에서 메이어 부사장보다 직급이 높은

사람이 와서 ‘검색 버튼’이 누르기 어려우니 조금 더 크게 만들어보는

게 어떻겠냐고 하더라도 메이어 부사장이 봤을 때 형편없는 조언이라

면 제품에 반영되지 않았을 것이다.

아이폰을 쓸 때마다 새삼 감탄하는 것은 UX의 통일성이다. 이런 통

일성이 제품의 모든 곳에서 통용된다는 사실은 제품의 처음부터 끝까

지 디자이너 한 명이 내적 통일성을 고려해 설계하지 않으면 불가능한


일이다. 스티브 잡스의 표현을 빌리자면 어썸(Awesome)한 UX는 스타

디자이너의 역량을 인정하는 조직에서 가능한 일이다. 즉, 아무리 뛰

어난 디자이너를 총괄 수석 디자이너 자리에 앉힌다 하더라도 직급으

로 디자인에 관한 의사결정이 밀리는 곳이라면 어썸한 디자인이 나올

수 없다.

정리하자면 이렇다. 닐슨 노먼 그룹의 정의를 따르자면 훌륭한 UX

란 소프트웨어 개발팀과 다양한 분야의 팀이 완벽하게 융합될 때 얻

을 수 있다. 그리고 이런 완벽한 융합은 UX에 대한 내적 통일성을 완벽

하게 유지할 수 있는 스타 디자이너의 역량을 인정하고 그것이 발휘될

때 비로소 가능하다. 소프트웨어를 개발하는 팀 입장에서 보면 UX란

자신들이 맡은 요구사항 명세를 만족하는 소프트웨어를 만드는 것이

다. 결론적으로 보자면 소프트웨어 개발 팀만으로는 훌륭한 UX를 만

들 수 없다. 물론 소프트웨어 개발 팀 입장에서 UX는 요구사항 명세로

환원시킬 수 있다. 그렇다 하더라도 정말로 훌륭한 UX를 만드는 것은

요구사항 명세를 구현하는 것 이상의 일임을 명심해야 한다.


사용자의 말보다 행동을 믿자

소프트웨어를 만들 때 사용자의 니즈를 파악하는 방법으로 대면 인

터뷰를 자주 사용한다. 모든 일이 그렇듯이 이 인터뷰를 제대로 하려

면 정말 자원이 많이 필요하다. 우선 고객이 제공하는 자료나 기초 자

료 분석을 토대로 인터뷰 때 사용할 질문지를 만들어야 한다. 인터뷰

를 효율적으로 진행할 수 있게 질문지를 완성했다면 인터뷰 대상자에

게 발송하고 미리 질문에 대한 답을 생각해 오게 한다.

인터뷰를 효율적으로 하려고 인터뷰 대상자를 몇 명씩 모아서 그룹

인터뷰를 진행하면 의견을 적극적으로 제시하는 사람을 중심으로 흘

러가기 때문에 1회 인터뷰 시 인터뷰 대상자는 가능하다면 1명으로 제

한하는 게 좋다. 1회 인터뷰에 1명으로 제한한다면 하루에 진행할 수

있는 인터뷰는 대략 2번 정도다. 한 번에 2시간 정도 필요하다면 인터

뷰를 마친 후 정리할 시간을 포함하면 하루에 2번이 적당하다. 내 경우

최대 4번까지 한 적이 있는데 정말 힘들고 집중도 되지 않는다.

인터뷰가 끝나고 나면 인터뷰 내용을 정리해 인터뷰 결과서를 작성

한 후 인터뷰 대상자에게 기록한 내용과 본인이 말한 내용이 일치하는


지 확인한다. 인터뷰 결과서를 토대로 현재 시스템의 문제점을 파악하

거나 고객의 요구사항을 도출하는 작업을 시작한다.

앞서 소개한 인터뷰 방법을 사용해 인터뷰 대상자 10명을 상대로 인

터뷰한 프로젝트가 있었다. 인터뷰를 준비하는 데 1주일, 인터뷰하는

데 1주일, 그 결과를 정리하는 데 1주일로 프로젝트 기간 중 한 달을 거

의 인터뷰에 쏟아 부었다. 이해당사자가 많은 프로젝트여서 명확한 요

구사항을 도출하는 게 중요하다고 생각했기 때문에 과도하지만 인터

뷰에 집중했다.

이런 인터뷰를 토대로 고객의 공통된 요구사항이 도출됐다. 자신들

의 업무를 절차에 맞춰 수행했으면 좋겠다는 의견이 절대다수였다. 일

을 하는 데 체계성이 없이 상관이나 고객부서에서 급하다고 하는 일

을 중심으로 처리하다 보니 문제가 많다는 의견이었다. 프로젝트 팀은

이런 인터뷰 결과를 토대로 업무를 절차대로 수행할 수 있는 시스템을

설계하고 개발했다.

고객의 요구사항대로 시스템을 만들어 오픈했다. 그런데 막상 오픈

하고 나서 절차성이 중요하다고 말한 사용자들이 시스템을 쓰면서 보

인 반응은 시스템이 너무 절차적이라는 평가였다. 사용자들의 기대대

로 만들었음에도 그다지 평가가 좋지 않자 프로젝트 팀원들은 적잖

이 당황했다. 우여곡절 끝에 프로젝트는 마무리됐지만 시스템이 너무

절차적이어서 현실을 반영하지 못하고 있다는 불평을 계속 들었다.


관찰이 대상의 행동을 바꾼다는 말이 있다. 사람들의 속마음과 겉

으로 표현되는 게 다르기 마련인데, 타인의 시선을 의식해야 하는 인터

뷰 자리에서 질문을 받으면 솔직한 심정보다 좋아 보이는 모범 답안을

말하는 경향이 많다. 프로젝트 경력이 조금씩 쌓이면서 고객의 요구사

항을 파악하려고 하는 인터뷰가 상당히 회의적으로 여겨졌다. 그래서

되도록 인터뷰가 아닌 다른 방법으로 고객의 요구사항을 파악하려고

한다.

하지만 어쩔 수 없이 인터뷰를 하는 경우도 있다. 프로젝트 외부에

서 일종의 형식성을 원할 때다. 프로젝트를 시작하고 나서 이해당사자

의 참여를 독려하거나 관심을 얻으려고 할 때가 바로 여기에 해당한다.

나는 요구사항을 도출하는 수단으로서의 인터뷰에 회의적일 뿐 프로

젝트의 내외부 환경이나 이해당사자의 개략적인 역학관계를 파악하는

데는 인터뷰가 효과적이라고 생각한다.

그렇다면 사용자가 정말로 원하는 바를 파악하려면 어떻게 해야 할

까? 그때는 사용자의 행동을 보는 편이 더 낫다. 예를 들어, 기존에 사

용하는 소프트웨어가 있다면 해당 소프트웨어를 사용하는 모습을 관

찰하는 것이다. 그런 소프트웨어가 없다면 고객이 실제로 일하거나 생

활하는 현장으로 들어가 고객이 어떤 식으로 행동하는지 관찰하는 게

낫다. 흔히 말하는 민족지학, 섀도우잉(shadowing), 맥락을 고려한 인터

뷰(Contextual Interview)를 하는 게 좋다.


사용자를 파악할 때 인터뷰 방식이 적합하지 않은 것은 앞서 말

했듯이 사용자의 말에 의존한다는 것과 실제 사용자가 일하는 맥락

(context)을 분리한 인터뷰 장소에서 진행하기 때문이다. 이에 반해 맥

락을 고려한 인터뷰는 사용자의 행동을 사용자가 일하는 맥락에서 관

찰함으로써 말에 의지하는 인터뷰의 한계를 극복한다.

물론 사용자의 행동을 잘 관찰기록하는 것만으로 좋은 소프트웨어

를 만들 순 없다. 우리가 관찰한 바를 토대로 사용자를 만족시키는 소

프트웨어를 만드는 것은 별개의 이야기다. 다만 훌륭한 소프트웨어를

만드는 과정에서 말에 의지하는 인터뷰보다 행동을 관찰하는 방법이

더 좋은 소프트웨어를 만들 가능성을 높인다.


아키텍트가 없더라도 아키텍처는 꼭 필요하다

컨설턴트로서 가끔 다른 조직에서 만든 소프트웨어 개발 관련 산출물

을 볼 때가 있다. 컨설턴트지만 배울 게 정말로 많은 조직도 있고 반대

로 코드 말고는 그다지 소프트웨어 개발 산출물이라고 부를 만한 게

없는 경우도 있다. 소프트웨어 개발 산출물의 수준은 차치하더라도

코드가 정말로 괜찮은 조직과 형편없는 조직의 차이가 어디에서 오는

가를 고민해 보면 아키텍처에 있는 것 같다. 아키텍처를 늘 고민의 중

심에 두는 조직에서는 코드의 수준도 전반적으로 높지만 아키텍처를

고민하지 않는 조직에서는 코드의 수준이 형편없을 때가 많다.

임베디드 소프트웨어를 만드는 조직과 협업했을 때의 일이다. 이 조

직에서 만든 소프트웨어를 검토하면서 이상한 점을 발견했다. 모듈별

로 입력 신호의 이상 유무를 체크하는 로직이 구현돼 있었는데, 상식

적으로 봤을 때 소프트웨어에 입력되는 입력 신호가 이상이 있는지 한

번 검증하고 나서 검증된 신호를 각 모듈에서 사용한다면 굳이 입력

신호의 이상 유무를 모듈별로 검증할 필요가 없었다. 그렇다면 왜 이

런 현상이 일어난 것일까?


한동안 고민을 하다가 이 조직에서 소프트웨어를 개발하는 방법을

알고 나서 그 이유를 알 수 있었다. 소프트웨어를 처음 설계할 때 간

단하게 아키텍처를 잡았지만 그 아키텍처를 지속적으로 개선하지 않

았다. 그러다 임베디드 소프트웨어의 기능 구현이 다급해지자 아키텍

처를 고려해 소프트웨어를 개선하는 게 아니라 기능 구현을 최우선시

했다.

기능 구현을 맡은 담당자에게 일이 바로 떨어지면 담당자들은 기능

구현의 우선순위가 가장 높았기에 아키텍처를 고려해 개발하지 않고

일단 자신이 맡은 모듈에서 이상이 없도록 개발하는 데 전념했다. 자

신이 맡은 모듈에 문제가 없어야 했기에 입력신호로 받은 입력값에 문

제가 있는지 검증하는 로직을 구현해서 넣었고, 결국 이런 이유로 개발

자의 수만큼 입력신호를 검증하는 로직이 들어갔던 것이다.

이 조직에서 아키텍처를 지속적으로 개선하고 유지했다면 어떻게 됐

을까? 새로운 기능을 추가한다면 우선 아키텍처 레벨에서 검토를 했을

것이다. 따라서 새로 추가되는 입력신호가 있다면 이상 유무를 체크하

는 모듈에 신규 입력신호에 대한 이상 유무를 체크하는 로직을 추가했

을 것이다. 그러고 나서 추가된 신호를 사용하는 모듈에서는 이미 신호

가 검증됐다는 사실을 확신할 수 있으므로 기능 추가에만 집중했을 것

이다. 그러면 이 조직에서 만든 소프트웨어는 좋은 소프트웨어의 요건

이라고 할 수 있는 응집도가 높은 코드가 됐을 가능성이 높다.

소프트웨어를 개발하고 통합하기 전까지, 소프트웨어 비기능 요구


사항이 제대로 구현될 수 있을지 판단할 수 있는 수단은 아키텍처를

검토하는 방법이 유일하다. 앞서 소프트웨어 요구사항(명세)은 흔히

기능 요구사항과 비기능 요구사항으로 구별할 수 있다고 했다. 기능 요

구사항이란 소프트웨어가 동작할 때 소프트웨어가 제공해야 하는 기

능이다. 비기능 요구사항이란 기능 요구사항을 제외하고 소프트웨어

에 요구되는 요구사항이다. 비기능 요구사항의 대표적인 것으로 가용

성, 응답성, 변경 용이성, 유지 보수성, 확장성 등이 있다.

아키텍처 설계를 하면서 이런 비기능 요구사항을 달성할 수 있을지

를 검토하지 않는다면 개발자들이 각계전투 식으로 만든 모듈을 모두

합쳐서 통합했을 때가 돼서야 비기능 요구사항을 달성했는지 알 수 있

다. 예를 들어, 어떤 소프트웨어 시스템에 가용성 99.9퍼센트를 달성하

라는 비기능 요구사항이 할당됐다고 해보자. 아키텍처를 두고 이런 가

용성을 달성할 수 있을지 검토하지 않는다면 개발자들이 만든 모듈을

모두 통합한 뒤 가용성을 검증하는 테스트를 실행했을 때 비로소 비

기능 요구사항을 달성할지 알 수 있다. 운 좋게 비기능 요구사항을 만

족한다면 다행이지만 그렇지 못한다면 정말 개발자에게 지옥과도 같

은 부분 최적화의 오류에 빠진다. 아키텍처 수준에서 성능이 나오지

않는 문제를 코드 최적화로 땜질해야 하기 때문이다.

아키텍처의 또 다른 역할로는 기능 할당이 있다. 아키텍처의 중요한

역할 가운데 하나는 요구사항에 있는 문제영역을 상세 설계라는 해결

책 영역(알고리즘)으로 사상시키는(mapping) 가교 역할이다. 아키텍트


는 아키텍처를 작성하면서 응집도가 높고 결합도가 낮은 코드를 만들

수 있게 기능 요구사항 가운데 비슷한 것들을 모아서 그룹핑하고 이를

구현의 단위인 모듈 단위로 떨어트려서 실제 개발을 담당한 개발자가

자신이 맡은 모듈에 전념할 수 있게 한다.

흔히 현업에서 아키텍처를 고민하지 않고 개발을 할 때 개발자 위주

로 개발이 진행된다. 즉, 아키텍처 위주로 소프트웨어가 만들어지는

게 아니라 개발 팀의 역학관계대로 소프트웨어가 만들어진다. 흔히 말

해서 4개의 조직이 컴파일러를 만든다면 4단계를 지닌 소프트웨어가

만들어진다는 콘웨이의 법칙이 적나라하게 적용된다.4 응집도가 높고

결합도가 낮은 코드의 핵심이라고 할 수 있는 인터페이스 설계는 선행

적이 아니라 후행적으로 결정된다. 이런 코드는 흔히 유지보수도 힘들

고 확장하기도 쉽지 않다.

프로젝트에 아키텍트가 있는 경우는 흔치 않다. 여러 가지 이유로

팀 내 아키텍트가 없을 수도 있다. 하지만 아키텍트가 없어도 기능 개

발이 시작하기 전에 반드시 아키텍처를 작성해야 한다. 애자일 방법

론을 적용할 때는 형식적인 방법을 사용할 때보다 아키텍처의 정밀성

이 떨어질 수 있겠지만 비기능 요건의 구현 가능성이나 기능할당을

위해 어느 정도 아키텍처를 설계해야 한다. 규모가 큰 소프트웨어 시

스템을 개발할 때는 아키텍처 작성의 필요성을 아무리 강조해도 지나

치지 않다.

4　http://en.wikipedia.org/wiki/Conway's_Law


PM과 아키텍트는 다르다

PM은 개발해서는 안 된다는 이야기가 있다. 왜 그럴까? 일단 PM이

개발에 집중하기 시작하면 관리에서 손을 놓게 된다. 현실에서는 개

발자가 부족해서 PM이 개발에도 참여해야 할 때가 무척 많다. 팀원

이 PM과 개발자 두 명뿐이고 개발자 혼자서 개발하기가 벅차다면 당

연히 PM도 개발해야 할지도 모른다. 이처럼 규모가 작은 프로젝트는

논외로 하고, 프로젝트 규모도 제법 되어 관리할 게 많을 때 PM이 관

리에서 손을 놓고 뭔가를 만들고 있다면 프로젝트는 그때부터 산으로

가기 시작한다.

PM이 개발을 하면 안 되는 이유는 간단하다. PM은 프로젝트라는

숲을 봐야 하는 사람인데 개발을 시작하면 자신이 키우는 나무만 보

게 된다. 하루 종일 나무를 돌보기 때문에 나무와 애착이 깊어지지만

그 사이에 여기저기서 나무가 말라 죽거나 불이 나서 숲은 서서히 죽어

간다. 조금 어렵게 풀어 보자면 PM은 부분 최적화가 아닌 전체 최적화

를 하는 역할이기 때문에 관리에 집중해야 한다. 개발이란 자신이 맡


은 기능을 최고로 만드는 작업이다. 하지만 관리는 일부 기능을 멋지

게 개발하는 것을 포기하더라도 전체적인 기능을 조화롭게 만드는 일

이다.

이런 논리를 따르자면 PM은 아키텍트를 맡아도 안 된다. 아키텍트

라는 역할을 별도로 두는 호사를 누리는 프로젝트는 흔하지 않다. 굳

이 아키텍트라는 역할을 프로젝트에 도입해야 할 정도로 프로젝트에

서 개발하는 소프트웨어의 아키텍처를 잡는 게 중요하다면 PM 말고

다른 팀원이 아키텍트 역할을 맡는 게 좋다. 왜 그럴까?

아키텍트는 기술적인 측면에서 개발할 소프트웨어의 전체를 최적화

하는 역할을 맡는다. 앞에서 PM은 부분 최적화가 아닌 프로젝트의 전

체 최적화를 하는 사람이라고 했다. 전체 최적화 측면에서 보면 아키

텍트나 PM이나 비슷한 형식의 업무를 하는 셈이다. 이런 논리를 따르

자면 아키텍트가 PM을 맡아도 되고 PM이 아키텍트를 맡아도 될 것

같다. 하지만 그렇지 않다.

PM은 말 그대로 프로젝트의 전체적인 최적화를 추구하는 사람이

다. 기술적인 것과 비기술적인 것을 최적화하는 역할인 셈이다. 따라서

기술적인 상황과 비기술적인 상황 사이에서 충돌이 발생할 때 PM은

둘 사이에 최적화 지점을 찾아내야 한다. 이런 상황에서 아키텍트는

PM이 기술적인 면에서 판단할 수 있게 도와야 하지만 기술적인 측면

에서의 최적화라는 관점을 유지해야 한다.


아키텍트이자 PM인 사람이 있다고 하자. 이 사람은 이전 프로젝트

에서 아키텍트로 활약했다. PM이지만 그 본성을 보자면 철저한 아키

텍트다. 사람에 따라 다를 수 있지만 어제까지 아키텍트로서 소임을

다하던 이 사람은, 아키텍처의 완성도와 프로젝트 관리요소 사이에

충돌이 발생할 때 어떤 선택을 할까? 아마도 관리적인 측면에서 선택

하기보다 아키텍처의 완결성을 중요시하는 선택을 할 것이다. 물론 반

대로 관리지향적인 사람이 아키텍트를 맡았을 때는 반대되는 선택을

할 것이다.

아키텍트나 개발자는 모두 기술적인 관점에서 일한다. 그게 맞다. 엔

지니어인데 개발할 때 정치적인 판단을 한다면 그 프로젝트는 십중팔

구 말 잔치로 끝나거나 문제투성이인 소프트웨어가 만들어지고 말 것

이다. 하지만 프로젝트란 기술만이 전부가 아니다. 다양한 이해당사자

가 관여하고 그들 사이에 이해관계를 성공적으로 조정해서 결과를 내

는 게 중요하다. 따라서 이런 관점에서 의사결정을 내리면서 기술적인

최적화도 고려하려면 PM과 아키텍트의 역할은 분리하는 게 맞다.


사공이 많은 프로젝트 팀이라면 아키텍트가 반드시 필요하다

좋은 아키텍트란 뭘까? 도메인마다 좋은 아키텍트에게 필요한 역량이

다를 것이다. SI 프로젝트의 아키텍트에게 필요한 기술 영역과 자동차

용 임베디드 소프트웨어 개발 프로젝트의 아키텍트에게 필요한 기술

영역은 다를 것이다. 따라서 단순히 어떤 기술을 어느 정도 수준으로

갖춘 사람을 아키텍트로 평가할 수는 없다. 도메인마다 다른 문제이기

때문이다.

기술적인 내용을 배제하고 간단하게 아키텍트를 정의하자면 도메인

에 관계 없이 정의를 내릴 수 있다. 프로젝트 수행 관점에서 아키텍트

란 프로젝트에서 만들어내는 소프트웨어의 아키텍처를 소유한 사람

이다. 여기서 아키텍처를 소유한다는 의미는 집과 같은 재산을 소유한

다는 의미와 다르다. 아키텍처와 관련된 이슈가 발생해 그 이슈를 책임

지고 처리해야 한다면 아키텍처를 소유했다고 볼 수 있다. 당연히 발생

한 문제를 맡아서 처리해야 하니 아키텍처에 대한 독점적인 권한과 소

유권이 아키텍트에게 있는 셈이다.


도메인에 관계 없이 아키텍트가 해야 하는 가장 중요한 업무는 뭘

까? 요구사항 명세라는 문제를 소프트웨어라는 해결책으로 변환하는

작업을 진두지휘해야 한다. 즉, 요구사항 명세에서 소프트웨어로 바꿀

때 아키텍처를 만들어 소프트웨어 개발 전략을 수립해야 한다. 이때

다양한 이해당사자가 변환 작업에 참여하기 때문에 이해당사자의 주

장을 잘 듣고 아키텍처에 성공적으로 반영하는 게 아키텍트의 핵심적

인 역할이다.

기술적인 판단 문제가 이해당사자의 목소리에 파묻힐 때 아키텍처

에 재앙이 닥친다. 예를 들자면 기술적인 검토 없이 최신 기술을 프로

젝트에 도입하라는 요구사항이 있을 때 아키텍트가 치열한 논쟁 없이

정치적인 판단만으로 그런 요구사항을 수용해 버리면 아키텍처의 수

준도 낮아지고 프로젝트에서 만들어내는 결과도 보장할 수 없다.

오래전에 어떤 회사에서 전략적인 파트너십을 맺은 회사의 소프트

웨어를 판매해 주려고 새롭게 시작하는 프로젝트마다 해당 소프트웨

어를 반영한 아키텍처를 꾸미라는 회사 지침이 내려왔다고 한다. 물론

어떤 프로젝트에서는 전략적 파트너십을 맺은 회사의 소프트웨어가

도움이 될 수도 있었지만 대부분의 프로젝트에서는 그 소프트웨어가

필요하지 않았다. 아키텍트가 있는 프로젝트에서도 잘못된 회사 정책

에 반기를 들지 못해 해당 소프트웨어를 억지춘향 식으로 사용했다고

한다.

물론 앞선 예처럼 아키텍트가 회사에서 강압적으로 내려오는 정책


에 맞서 싸우는 사명감까지 지녀야 한다는 의미는 아니다. 그런데 회

사에서 기술적 판단을 엔지니어가 하지 않을 때가 있다. 이때가 바로

회사가 기술적으로 망해가는 시점이라고 할 수 있다. 아키텍트라고 해

서 특별히 역사적 사명을 갖고 이 땅에 태어난 건 아니지만 기술적으

로 올바르지 않은 결정에서 자신에게 소유권이 있는 아키텍처를 최대

한 보호해야 한다. 물론 이런 정치적 싸움에 아키텍트가 앞장 설 필요

는 없다. 그래서 앞에서 아키텍트와 PM은 다르다고 말한 것이다. 다만

PM이 정치적 외풍에서 프로젝트를 보호해 낼 수 있게 아키텍트가 기

술적인 리더십을 최대한 발휘해야 한다.

모터로 제어되는 시스템을 만드는 회사가 있었다. 이 회사의 문제는

고객이 시스템에 대한 변경을 요청하려면 기구나 하드웨어, 소프트웨

어 개발을 맡은 담당자와 직접 이야기를 해서 수정사항을 반영해야 한

다는 것이었다. 그런데 시스템에 대한 변경요청이 따로 관리되다가 문

제가 생기고 말았다. 고객이 모터의 RPM 한계치를 높여달라는 요청을

소프트웨어 개발자에게 했고, 소프트웨어 개발자 입장에서는 상수 값

정도만 바꾸는 간단한 일이었기에 별 고민 없이 변경사항을 반영했다.

그런데 이 변경사항 때문에 필드 테스트를 하다가 시스템이 망가지고

말았다. 시스템을 변경된 모터 속도를 견디게끔 설계하지 않았기 때문

이다.

앞의 예는 기구, 하드웨어, 소프트웨어가 합쳐지는 시스템을 만들

때 변경을 전체적인 관점에서 고려하지 않았기 때문에 생기는 문제다.


소프트웨어만으로 구성된 시스템을 만들 때도 전체적인 관점에서 변

경을 고려하지 않으면 이와 비슷한 문제가 생긴다. 아키텍처가 필요

한 이유를 다룬 장에서 본 예에서처럼 담당자별로 모듈을 할당해 두

면 자신이 맡은 모듈의 완성도만을 고려해서 동일한 로직을 구현하게

된다. 이런 부분 최적화의 문제는 아키텍처가 없어도 생기지만 대규모

프로젝트에서 아키텍처만을 만든다고 해서 이 문제가 완전히 해결되

진 않는다.

아키텍트 없이 아키텍처를 만들 수 있을지 모르겠지만 그렇게 애써

만든 아키텍처에 대한 소유권을 아무도 갖고 있지 않을 때 아키텍처는

쓸모없어진다. 소유권이 없는 아키텍처는 공공재와 비슷하다. 쓰는 사

람은 있어도 관리하는 사람이 없을 때 공공재는 망가지고 금방 훼손

된다. 물론 재산권처럼 아키텍트가 아키텍처에 대해 완전한 소유권을

갖지는 못하지만 아키텍처를 쥐고 전체적인 관점에서 접근하려는 시

각을 아키텍트가 갖고 있다는 것만으로도 프로젝트 산출물의 결과가

달라진다. 따라서 여기저기 엮인 사람이 많고 참여하는 개발자도 정말

많다면 반드시 아키텍트라는 역할을 팀에 둬야 한다.


매뉴얼을 만들기보다 매뉴얼이 필요 없는 소프트웨어를 만들자

뜬금없이 퀴즈 하나를 내보겠다. 프로젝트에서 만드는 산출물 가운데

실제 개발에는 도움을 주지 않지만 들어가는 노력이 상당한 것은 무엇

일까? 물론 정답은 없다. 사람이나 프로젝트에 따라 다르지만 내 경험

에 비춰 생각해 보면 매뉴얼이 그렇다. 매뉴얼은 정말로 손이 많이 간

다. 물론 프로젝트에 따라 매뉴얼을 작성하는 사람이 프로젝트 외부에

있을 수도 있지만 보통 프로젝트 팀 내에서 매뉴얼을 만든다. 사실 매

뉴얼은 프로젝트가 종료될 시점에 만들기 때문에 팀에 큰 부담이 없다.

하지만 소프트웨어 화면을 캡처해 화면마다 설명 이미지를 넣고 그걸

문서로 만들다 보면 상당한 자원이 들어간다.

물론 열심히 만들어 놓은 매뉴얼을 사용자가 잘 읽어 보고 소프트웨

어를 사용할 때 도움을 받으면 그걸로 만족하겠지만, 내 경험을 보더라

도 시스템을 사용하다 막혔을 때 매뉴얼을 읽으면서 도움을 받았던 적

은 별로 없다. 매뉴얼에 적힌 정보는 상당히 뻔한 내용이어서 굳이 매

뉴얼을 읽어보지 않아도 되는 것이 많았다. 정작 시스템을 사용하면서


곤란을 겪으면 헬프 데스크나 개발자를 찾아서 문제를 해결했다.

시스템이 업그레이될 때 매뉴얼도 함께 수정하면 그나마 매뉴얼이

의미가 있지만 대부분 시스템이나 소프트웨어와 매뉴얼이 따로 노는

경우가 허다했다. 매뉴얼을 만들어 보기도 하고 매뉴얼을 두고 시스템

을 사용해 보면서 얻은 결론은 그다지 도움이 되지 않는 매뉴얼은 차

라리 만들지 않는 편이 더 낫다는 것이다. 그런데 막상 매뉴얼을 만들

지 않자니 뭔가 개운하지 않다. 그렇다면 매뉴얼을 만들지 않으면서도

묘한 뒷맛을 느끼지 않으려면 어떻게 해야 할까?

지금은 아이폰이 대세라 모든 휴대폰이나 스마트폰이 아이폰을 기

준으로 평가받는다. 잠시 아이폰이 대세인 세상을 잊고 연아폰이나 햅

틱폰처럼 피처폰이 대세였던 때로 돌아가보자. 아이폰 가격과 맞먹는

피처폰을 2년 약정으로 사와서 포장을 뜯을 때마다 항상 보게 되는

부속품이 있다. 바로 매뉴얼이다. 피처폰의 다양한 기능을 설명해둔

매뉴얼은 상당히 두껍다. 제품박스가 작아서 가로, 세로 크기를 늘릴

수 없기에 두께가 상당하다. 이 매뉴얼을 볼 때마다 휴대폰에 기능이

참 많구나, 라는 생각을 한다. 하지만 그렇게 생각만 할 뿐 실제로 매뉴

얼을 읽어 보진 않았다.

아이폰을 처음 샀을 때의 기억이 생생하다. 꿈에도 그린 아이폰을

드디어 우리나라에서 써볼 수 있다는 기분 때문이기도 하지만 포장을

뜯었을 때 본 매뉴얼 때문이기도 하다. 아이폰도 휴대폰인지라 기능을

설명하는 매뉴얼이 있었지만 분량이 정말 적었다. 기존 휴대폰의 매뉴


얼과 비교했을 때 10분의 1도 채 안 되는 분량이었다. 아이폰의 기능

을 생각하면 휴대폰보다 기능이 더 뛰어날 텐데도 설명서의 분량이 상

당히 적다는 사실에 적지 않게 놀랐다. 그렇다면 왜 아이폰의 매뉴얼

은 일반 피처폰의 매뉴얼보다 분량이 적을까?

답은 아이폰은 매뉴얼이 필요 없게 만들었기 때문이다. UI가 직관적

이어서 굳이 매뉴얼을 찾아 기능을 공부하지 않아도 한 번 보면 누구

나 쓸 수 있다. 프로젝트를 하면서 매뉴얼을 만들지 않아도 될 힌트를

아이폰에서 얻을 수 있다. 우리가 만드는 소프트웨어를 직관적이고 쓰

기 쉽게 만들면 된다. 다시 말해, 소프트웨어 자체에 매뉴얼이 담겨 있

으면 된다.

명백한 것은 빼고 의미 있는 것을 넣으라는 말이 있다. 매뉴얼이 필

요 없는 시스템을 만들자는 관점에서 이 말을 해석하면 이렇다. 명백

한 매뉴얼이 없어도 시스템의 UI가 뛰어나서 UI만 보고도 그 의미를

파악할 수 있게 만들어야 한다. 이렇게 하지 못하다 보니 우리가 만든

시스템 때문에 고생할 사용자를 위해 매뉴얼을 만들어야 하는 것이다.


제대로 테스트하려면 자원, 프로세스, 문서가 필요하다

프로젝트에서 개발 업무가 한창 바빠지자 개발 관련 이슈만 제외하고

관리할 게 없어진 적이 있다. 이슈 관리에 일이 없어진 PM은 한가한 시

간을 활용해 팀원들이 개발한 소프트웨어를 테스트해주겠다고 나섰

다. 해당 프로젝트의 팀원들은 PM의 도움이 무턱대고 반갑지만은 않

았다. PM의 성격이 꼼꼼한 편이라서 소프트웨어 곳곳에 숨겨진 버그

를 무차별적으로 찾아낼 게 뻔했고, PM은 득의양양한 표정으로 버그

목록을 하나 가득 만들어서 팀원들에게 수정하라는 업무지시를 하리

라는 것이 팀원들 머릿속에 그려졌기 때문이다.

규모가 일정 범위를 넘어가지 않는 이상 프로젝트에 테스터가 할당

되는 경우는 극히 드물다. 옳고 그름을 떠나 특히 SI 프로젝트의 경우

이런 현상이 심하다. 고장이 났을 때 사람에게 큰 영향을 끼치는 임베

디드 소프트웨어의 경우, 치명적인 고장과 직결되는 결함을 개발 과정

에서 찾아내는 게 매우 중요하다. 따라서 SI 프로젝트를 하면서 누리기

힘든 호사, 즉 전문 테스터와 함께 일할 때가 있다.


몇 년 전 임베디드 소프트웨어를 개발했던 프로젝트에서도 개발자

1명에 테스터 0.5명이 할당되는 호사를 누렸다. 확실히 전문 테스터가

있으면 개발 과정에서 결함을 발견하는 일이 수월해진다. 결함이 없는

소프트웨어를 만드는 것도 중요하지만 이미 들어간 결함을 소프트웨

어를 출시하기 전에 고치는 것도 중요하다. 개발자가 직접 자신이 만든

것을 테스트할 때보다 전문 테스터가 테스트할 때 결함을 더 많이 발견

했고 찾아내기 쉽지 않은 골치 아픈 결함도 쉽게 찾을 수 있었다.

프로젝트에서 테스트가 중요하다고 말한다. 하지만 현실은 그렇지

않다. 이런 이상과 현실의 괴리가 얼마만큼 차이가 나는지 판단하는

가장 쉬운 방법은 테스트에 할당되는 자원을 살펴보는 것이다. 물론

내 프로젝트로 한정 짓자면 상관이나 조직에서, 그리고 고객도 테스트

가 중요하다고 했지만 정작 프로젝트에 테스트할 수 있는 자원은 할당

되지 않았거나 할당됐더라도 극히 일부에 불과했다. 즉, 말과 행동이

일치하지 않고 이상과 현실의 괴리가 무척 컸던 셈이다.

테스트 주도 개발(TDD, Test-Driven Development)이라는 명목으로 테

스트도 개발자의 영역으로 보는 경향이 있다. TDD라는 기법 덕분에

테스트를 개발자의 역할로 판단하더라도 실제로 TDD를 하려면 어

찌 됐든 자원이 필요하다. 개발자의 역량이 TDD를 할 수 있어야 하고

PM이든 조직에서든 TDD를 왜 해야 하는지 이해하는 문화가 있어야

한다. 이런 것들이 뒷받침되지 않는다면 개발자는 TDD를 할 수 없다.

전문적인 테스터가 프로젝트에 할당됐더라도 테스트가 원활하지 않


을 때가 많다. 가장 큰 이유는 개발자가 제대로 된 소프트웨어를 만들

고 있는지 확인할 기준이 없기 때문이다. 이런 기준은 대개 요구사항

명세서, 아키텍처 설계서, 단위 설계서에 있다. 하지만 대부분의 프로

젝트 현실에서는 전문 테스터가 테스트 기준을 알아내려고 이런 문서

를 열었을 때 실망을 금치 못한다. 문서가 있더라도 대부분 테스트 기

준으로 뽑아 낼 만한 콘텐츠가 부족하거나, 있더라도 실제 개발된 코

드와 맞지 않는 형식상의 문서일 때가 많다. 이런 경우 전문 테스터가

할당됐더라도 프로젝트에 기여할 여지가 크게 줄어든다.

제대로 된 테스트를 하려면 전문 테스터라는 자원도 필요하지만 전

문 테스터가 테스트할 수 있는 기준을 제공해주는 문서가 충실히 작

성돼 있어야 한다. 이런 문서는 결국 설계자나 개발자들이 그런 문서

를 만들어 낼 만한 개발 프로세스에 따라 일해야 한다는 뜻이다. 이런

문서를 만들어내기가 어렵다면 전문 테스터와 프로젝트 초반부터 프

로젝트에 참여해 무엇을 테스트해야 할지 배워야 한다. 프로젝트를 일

반적인 폭포수 방식이 아닌 애자일 방법론에 따라 구성해야 한다는

뜻이다.

앞에서 예로 든 프로젝트에서도 테스트 기준으로 삼을 만한 문서는

없었다. 하지만 PM이 처음부터 프로젝트에 관여했기에 웬만한 요구사

항 명세를 파악했다. 이런 이유로 문서는 없었지만 PM은 테스트를 훌

륭하게 해냈다. 길게 썼지만 결론은 간단하다. 프로젝트에서 제대로 된

테스트를 하고 싶다면 인력, 프로세스, 문서가 필요하다.


최적의 테스트 기법을 찾아라

단위 테스트를 정말로 철저하게 했던 프로젝트가 있다. 이 프로젝트에

서는 단위를 함수로 정의했다. 일반적으로 사용하는 공용 라이브러리

의 함수는 단위 테스트를 하지 않고, 프로젝트 내부에서 만든 함수에

대해서만 단위 테스트를 수행했다. 단위 테스트에서 사용하는 테스트

케이스를 추출하는 기준은 구문 커버리지(statement coverage)를 100퍼

센트 달성하는 것으로 했고, 입력 변수의 경계 값을 확인할 수 있게 경

계 값 분석을 통해 테스트 케이스를 추출했다. 물론 단위 함수가 그렇

게 복잡하지 않았기에 함수 하나를 테스트하는 데 테스트 케이스가

많이 필요하진 않았지만 함수 자체가 많아서 전체적으로 테스트 케이

스가 무척 많았다.

그래도 이 프로젝트가 다행인 건 능력 좋은 테스터가 프로젝트에 할

당됐다는 점이다. 테스터는 단위 함수가 매우 많고 단위 함수의 입력

변수마다 경계 값 분석을 통해 테스트 케이스를 추출한다는 게 쉽지

않다는 점을 파악하고 입력 변수의 타입을 검사해 단위 테스트 케이

스를 자동으로 만들어주는 프로그램을 개발했다. 단위 테스트 도구


를 이용해 단위 테스트를 자동화했고 단위 테스트 도구를 이용한 덕

분에 테스트 기준인 구문 커버리지를 100퍼센트 만족하는지도 쉽게

알 수 있었다.

이 프로젝트에서 단위 테스트에 집중한 이유는 간단하다. 단위 함수

를 합쳐서 통합이 잘 됐는지 보는 통합 테스트를 하려면 필요한 테스

트 케이스 개수가 무척 많아진다. 프로젝트 팀은 통합 테스트에서 필

요한 모든 테스트 케이스를 뽑아서 제대로 개발을 했는지 검증하기가

쉽지 않을 거라 판단했다. 따라서 단위 함수 수준에서 검증을 철저히

해서 일단 단위 함수에는 결함이 없다고 가정하기로 했다. 단위 함수

에 결함이 없다는 사실을 확신할 수 있다면 통합 테스트에서는 탐사적

테스트 기법을 활용해 통합과 관련된 문제만 잡아내자는 전략이었다.

앞서 설명했듯이 단위 테스트는 테스터에게 전권을 일임했다. 이에

반해 통합 테스트는 통합을 수행한 개발자가 주도적으로 참여하는

것을 원칙으로 했고 통합의 난이도가 높은 모듈은 전문 테스터에게

맡겼다.

모든 프로젝트가 쉽지 않다. 특히 이 프로젝트도 기간이 무척 짧아

서 리스크가 무척 많았던 프로젝트다. 초반에 예상한 리스크가 많았

지만 그래도 이 프로젝트가 성공할 수 있었던 이유는 적절한 개발자가

참여했고 전문 테스터의 도움을 받을 수 있었기 때문이다. 그리고 그렇

게 할당된 자원으로 실행할 수 있는 테스트 가운데 가장 효과가 좋을

만한 테스트 방법을 선택해서 적용했다는 점이다.


프로젝트 계획을 수립할 때 테스트 계획을 수립한다. 그리고 테스

트 프레임워크를 회사 규정상 따라야 하는 조직도 있다. 프로젝트 계

획을 세울 때 고려하는 테스트 계획이나 회사에서 규정으로 제공하

는 테스트 프레임워크를 보면 다소 천편일률적이고 틀에 박힌 것 같

다. 요구사항 명세서, 아키텍처 설계서, 단위 설계서를 작성하고 나면

검토를 수행하고, 단위 함수를 작성하고 나면 단위 테스트를 실행하

며, 통합하고 나면 통합 테스트를 수행하고, 고객에게 인도할 때 인수

테스트를 실행한다.

물론 팀에 자원도 충분하고 일정에도 여유가 있다면 이런 검토와 테

스트를 모두 수행할 수 있다. 하지만 현실을 보면 이런 계획대로 검토

나 테스트 작업이 모두 수행되지는 않는다. 요구사항 명세, 아키텍처

설계 등의 문서 작업이 지연되면 검토 작업은 요식적으로 변하고 개발

이 제대로 끝나지 않으면 단위 테스트와 통합 테스트는 거의 생략하다

시피 한다. 결국 인수 테스트라는 명목으로 고객이나 최종 사용자를

동원해 결함을 발견한다. 모든 프로젝트가 이렇지는 않겠지만 많은 프

로젝트가 테스트 단계를 이런 식으로 진행하는 것도 사실이다.

프로젝트를 성공으로 이끌려면 현실을 직시하고 변화하는 환경에

적응해야 한다. 이 이야기는 테스트에도 적용된다. 한정된 자원과 기

간, 그리고 그 자원과 시간 내에 어떤 테스트를 했을 때 효과를 극대화

할 수 있을지 고민하고 알맞은 테스트 방법을 찾아 적용해야 한다. 회

사에서 제공하는 테스트 프레임워크나 선배나 이전 프로젝트의 계획


서를 참고해 세운 테스트 계획으로 프로젝트의 성공을 담보할 수는 없

다. 예를 들어, 프로젝트 팀에 있는 리스크를 최소화하는 방향으로 테

스트를 적용하자는 리스크 주도 테스트(Risk driven test)도 이런 생각과

맥이 닿는다고 할 수 있다.


테스트하기 전에 품질을 개선할 수 있는 방법이 있다면 그걸 선택하자

V&V라는 단어를 들어 봤는가? V&V는 Veri�cation & Validation의

약자다. 우리말로 옮기자면 검증과 확인이다. 언뜻 보면 같은 단어를

뉘앙스만 다르게 표현한 것 같은데, 소프트웨어 개발 관점에서 보면 검

증과 확인은 완전히 다른 것이다. 검증은 요구사항 정의서나 설계 문서

대로 소프트웨어를 만들었는지 보는 것이고, 확인은 고객이 원하는 대

로 소프트웨어가 만들어졌는지를 보는 것이다. 같은 단어 같지만 둘은

완전히 다른 개념이다.

그렇다면 테스트와 V&V 사이에는 어떤 관계가 있을까? 테스트는

V&V를 수행하는 방법 가운데 하나다. 테스트란 소프트웨어를 실행

해 그 결과가 기준과 같은지 다른지를 살피는 것이다. 여기서 기준이란

단위 설계서, 아키텍처 설계서, 요구사항 명세서가 될 수 있다. 단위 테

스트란 단위 설계서대로 단위가 만들어졌는지 검증(Verification)하는

것이고 통합 테스트란 통합된 단위나 모듈들이 아키텍처 설계서대로

통합되는지를 검증하는 것이다. 이에 반해 인수 테스트는 고객의 요구


사항대로 소프트웨어가 만들어졌는지 확인(Validation)하는 것이다.

테스트를 하면 왜 품질이 좋아질까? 프로젝트 팀에서 개발하는 소

프트웨어를 테스트해서 결함을 발견하고 이 결함을 수정하면 당연히

소프트웨어의 품질이 좋아진다. 검증 목적으로 테스트를 수행하면 결

함을 발견할 수 있고, 그런 결함을 수정하면 소프트웨어의 품질이 좋

아지는 것이다.

하지만 이런 점이 테스트의 한계이기도 하다. 검증을 목표로 수행하

는 테스트의 지향점은 설계서나 정의서라는 기준이다. 이런 기준이 올

바르게 정의된 것이고, 개발한 소프트웨어가 이런 기준을 벗어나거나

기준에 미치지 못하면 우리는 소프트웨어에 결함이 있다고 말한다. 그

런데 이런 기준이 잘못된 것이라면 어떨까? 이 산일 거라고 믿고 열심

히 올라왔는데 사실은 옆에 있는 산을 올라야 하는 상황이다.

테스트 말고 검증의 방법으로 사용할 수 있는 건 뭐가 있을까? 대표

적으로 검토가 있다. 검토의 방법에는 실시간으로 개발과 검토가 동시

에 이뤄지는 짝 프로그래밍부터 동료 검토, 워크스루, 그리고 인스펙션

과 같은 아주 형식적인 것도 있다. 테스트가 완성된 소프트웨어를 두

고 정의서나 설계서대로 만들어졌는지를 검증하는 거라면 검토는 고

객이 요구하는 바를 정의서로 잘 정리했고 그렇게 정리한 정의서가 아

키텍처 설계서, 단위 설계서로 잘 정리됐는지를 보는 것이다. 검토와 테

스트는 모두 검증이라는 항목 아래에 있지만 바라보는 관점이 다르다.

내가 경험한 프로젝트 현장에서 프로젝트 계획서에는 요구사항 검


토, 아키텍처 검토, 단위 설계 검토, 코드 검토와 같은 활동이 적혀 있

었지만 대개 이런 검토 활동은 이뤄지지 않았다. 이런 활동을 했다고

하더라도 대개 형식적으로 할 때가 많았다. QA 활동에서 지적을 받지

않으려고 하는 요식적인 행위로 끝날 때가 많았다는 뜻이다.

짝 프로그래밍을 하면서 나는 검토의 힘을 깨달았다. 혼자서 코딩

삼매경에 빠져 소프트웨어를 개발했다면 단위 테스트나 아니면 아주

뒤늦게 프로젝트가 끝날 쯤에 예비 인수 테스트를 수행하면서 발견했

을 고약한 버그를 짝 프로그래밍을 하면서 발견할 수 있었기 때문이

다. 그것도 한두 개가 아니다. 아주 많이 발견했다. 그런 이후로 난 검토

매니아가 됐다.

테스트는 품질을 좋게 하는 아주 좋은 방법이다. 하지만 비용이 많

이 든다. 시간을 내서 해야 하고 결함을 발견했을 때 불행히도 결함을

수정하려면 비용이 많이 들 때가 많기 때문이다. 그렇다고 테스트가

효과가 적다는 건 아니다. 테스트로만 찾을 수 있는 결함이 있을 때도

있다. 이를테면 부하 테스트가 여기에 속한다. 심한 부하를 받아도 시

스템이 잘 견딜 수 있는지 설계서를 백날 검토해도 정확히 알 수 없다.

이때는 소프트웨어에 부하를 거는 테스트를 해야 한다. 이에 반해 검

토는 프로젝트 초반부터 적은 비용으로 효과를 많이 볼 수 있는 방법

이다. 따라서 테스트도 중요하지만 테스트 말고 품질을 개선할 방법이

있다면 우선적으로 그런 방법을 고민해야 한다.


개발자도 테스트해야 한다

다양한 테스트 가운데 내가 가장 선호하는 테스트는 단위 기능을 확

인하는 단위 테스트다. 이유는 뭘까? 경험상 각 개발자가 맡은 모듈에

서 단위 테스트를 완벽하게 수행하고 나서 통합을 하면 이때 발견되는

문제는 통합에서 생기는 거라고 확신할 수 있기 때문이다. 즉, 단위 테

스트를 수행하면 통합 과정에서 생기는 문제를 쉽게 찾을 수 있다.

말이 사람의 행동을 규정한다. 우리 자신을 개발자라고 부르는 순간

우리가 할 일은 개발로 한정된다. 물론 가끔 설계도 하고 어떨 때는 설

계한 내용을 검토할 때도 있고 가끔 테스트를 하는 경우도 있지만 개

발자는 개발자이기에 개발을 주업으로 삼는다. 그래서 테스트는 개발

자의 일이 아닌 테스터의 일로 생각한다.

TDD 덕분에 개발자와 테스터라는 말의 힘으로 규정돼 생긴 묘한

경계가 허물어졌다. TDD를 할 때 개발자는 테스트를 우선적으로 수

행하고 그 테스트를 만족하는 것을 코드로 만드는 식으로 일을 하기

때문이다. 물론 TDD의 마침표는 개발에서 끝나지만 그 시작은 제대


로 된 테스트 케이스를 만드는 것이다. 따라서 TDD를 하면 개발자는

자연스럽게 테스트를 고민하게 된다.

TDD를 하면 여러모로 좋다. TDD를 하면 1차적으로 단위 테스트

를 개발자가 끝내고 전문 테스터가 있다면 테스터는 통합 테스트에 전

념하면 된다. 앞서 내가 단위 테스트를 통해 이루려는 목적을 TDD로

달성할 수 있다. TDD가 좋다고는 오래전부터 이야기됐고 실제로 현장

에서 적용하는 경우도 제법 있다고 들었다. 하지만 내가 경험한 현업에

서는 보편적으로 사용된다고 말하기는 어려운 것 같다. TDD를 하면

좋지만 팀원 간의 실력 차가 있는 프로젝트 현실에서 TDD를 해야 한

다고 강요하기도 어렵다.

팀원들의 실력 차 때문에 TDD를 팀 내 공식적인 실천법으로 선언

할 수 없을 땐 어떻게 할까? 난 이런 경우 개발자들에게 적어도 자신이

맡은 영역의 단위 테스트는 챙길 것을 요구한다. 개발자인 팀원에게 단

위 테스트를 적절하게 알아서 챙기라고 요구하면 사람마다 수행하는

단위 테스트의 수준이 다르다. 이때 테스트 커버리지 종류와 수준을

정해서 팀에서 수행하는 단위 테스트의 수준을 동일하게 유지할 수 있

다. 예를 들자면 단위마다 구문 커버리지를 100퍼센트 달성해야 한다

는 기준을 정하고 팀원들이 지킬 것을 요구한다.

개발자인 팀원에게 단위 테스트를 요구하고 단위 테스트의 종류와

커버리지까지 지정하면 TDD를 적용하지 않았지만 TDD를 적용한 효

과를 누릴 수 있다. 개발자가 자신이 짠 코드를 테스트하면서 테스트


커버리지를 기준점 이상으로 끌어 올리기 위해 테스트하기가 쉬운 코

드를 작성하려고 고민하기 때문이다.

책임이란 참 무서운 것이다. 프로젝트에서는 협업 정신을 발휘해 다

른 팀원의 일도 고려해서 자신이 맡은 일을 해야 하지만 내 책임 범위

를 벗어나는 순간 고민의 깊이가 달라진다. 아무리 친하게 지내는 프로

젝트 동료라도 내 일이 아닌 이상, 정말 내 일처럼 고민하기 어렵다. 이

런 인지상정이 단위 테스트에도 적용된다.

단위 테스트를 전문 테스터의 일로 규정해 버리면 테스트 커버리지

기준을 만족시키는 테스트 케이스를 만드는 일은 전문 테스터의 일이

된다. 물론 단위 함수를 테스트할 설계서나 문서가 충분하다면 단위

테스트를 만드는 일이 그다지 어렵지 않을 수 있지만 현실은 그렇지 않

다. 아울러 이런 문서가 있더라도 코드 특성상 테스트 커버리지 기준

을 모두 충족하는 테스트 케이스를 만들기가 불가능할 때도 있다. 전

문 테스터가 아무리 노력해도 코드를 고치지 않는 이상 팀에서 정한 테

스트 기준을 만족시킬 수 없다는 뜻이다.

하지만 개발자에게 단위 테스트의 기준을 만족시키는 책임을 주면

개발자는 코드를 짤 때부터 단위 테스트의 결과를 염두에 두고 짠다.

테스트하기 쉬운 코드를 짤 가능성이 높다는 뜻이다. 이것은 TDD를

하면서 개발자가 얻는 통찰과도 비슷하다. 확실히 단위 테스트 기준

을 정하고 그 기준을 만족시키는 일을 개발자에게 부여했을 때 코드의

품질이 높아지는 경험을 했다.


개발자는 뭔가를 만들어 가는 사람이고 테스터는 만든 것을 어떻게

든 고장을 내야 하는 사람이라서 기본적으로 코드를 대하는 태도가

다르다. 그래서 개발자는 코드가 망가지지 않는 방법을 선택해 코드를

테스트한다. 이런 이유를 들면서 개발자보다 테스터가 테스트하는 게

효과적이라고 주장하는 경우도 있다. 이런 의견도 상당히 타당하다.

하지만 앞 장에서도 살펴봤듯이 테스트만으로 코드의 품질이 좋아

지는 건 아니다. 아울러 테스트 말고 코드의 품질을 개선할 방법이 있

다면 그것을 선택하는 게 좋다. 어떻게 보면 개발자가 테스트했을 때

나쁜 결과가 나올 코드를 원천적으로 작성하지 않는 게 최고의 테스

트 방법이라고 생각한다. 모든 범죄가 그렇듯이 사후수습보다 사전예

방이 가장 좋다. 물론 버그가 범죄와 동급의 것은 아니지만 프로젝트

생애를 봤을 때 버그나 결함 때문에 발생하는 피해를 생각하면 버그나

결함은 프로젝트 세계에서 범죄라 할 수 있다. 즉, 개발자가 테스트를

고려한다면 이런 범죄를 저지를 가능성이 줄어들 것이다.


형상관리와 버전관리는 다르다

포크레인이 좋은 도구일까, 꽃삽이 좋은 도구일까? 어떤 도구가 좋다

고 생각하는가? 사실 이 질문의 답은 사람마다 다르다. 질문이 상당히

모호하기 때문이다. 도구는 가치 중립적이다. 도구의 좋고 나쁨을 평가

하려면 반드시 용도라는 맥락을 미리 정의해야 한다. 제대로 된 답을

얻기 위해 질문을 조금 바꿔보자. 화단 정리를 한다면 포크레인이 좋

은 도구일까, 꽃삽이 좋은 도구일까?

당연히 꽃삽이 답이다. 포크레인이 땅은 잘 파겠지만 화단을 정리하

기에는 적합하지 않다. 한줌의 흙을 파서 이리저리로 옮겨야 하는 화단

정리에는 꽃삽이 안성맞춤이다. 화단정리뿐 아니라 일을 할 때 효율적

으로 하려면 그에 걸맞은 도구를 써야 한다. 그렇게 하지 않으면 생산

성이 개선되지 않는다. 그런데 우리네 프로젝트 환경을 보면 꽃삽이 필

요한 곳에 포크레인을 쓰고 포크레인을 써야 할 때 꽃삽을 쓸 때가 비

일비재하다. 대표적으로 형상관리와 버전관리가 그렇다.


프로젝트 관리체계를 갖추고 프로젝트를 운영하는 조직에서는 대개

형상관리라는 것을 한다. 이 용어에 익숙한 사람도 있겠지만 반대로

이 용어에 익숙하지 않은 사람도 있다.

형상관리에서 가장 핵심적인 개념이 하나 있는데 바로 형상항목

(Con�guration Item)이다. 형상항목이란 다양한 정의가 있겠지만, 최종

제품에 영향을 주는 중간산출물을 의미한다. 소프트웨어를 개발하

는 프로젝트를 생각해 보면 소스 코드가 대표적인 형상항목에 속한다.

아울러 소스 코드를 만들 때 참조하는 각종 설계서, 요구사항 문서도

형상항목이다.

형상관리는 쉽게 말해서 프로젝트에서 관리해야 하는 형상항목으

로 무엇이 있는지 정하고 형상항목을 절차에 따라 관리하는 것이다.

이렇게 형상항목을 체계적으로 관리하는 이유는 그렇게 하지 않았

을 때 프로젝트의 최종 산출물인 소프트웨어의 품질이 나빠지기 때

문이다.

형상관리도 관리 활동에 속하므로 형상항목, 예를 들어 요구사항

문서를 바꾸려 한다면 요구사항을 바꿔달라는 형상 변경 요청서를

작성해야 한다. 이런 변경 요청을 접수한 PM은 변경 요청서를 분석해

프로젝트 예산이나 기간에 큰 영향을 주지 않는 선에서 변경 요청을

받아들일 수 있다면 해당 변경 요청서를 반영해 형상항목을 변경한

다. PM이 변경 요청을 받아들이려면 프로젝트 범위가 바뀌어야 한다


고 판단될 때 형상 변경 위원회를 소집해 형상 변경 요청서를 심의해

야 한다.

형상관리를 잘 모르는 독자를 위해 조금 풀어 썼는데, 형상관리를

처음 접하는 독자는 형상관리란 상당히 관료적인 냄새가 풍기는 관리

방법이라고 생각했을 것이다. 사실 앞에서 말한 게 형상관리의 전부는

아니다. 형상항목이 제대로 관리되는지 감사하는 형상 감사도 실시해

야 하고 변경 요청이 제대로 반영됐는지도 PM이 지속적으로 모니터링

해야 한다.

형상관리는 상당히 관리적인 활동이다. 그런데 이렇게 관리적인 활

동을 왜 해야 할까? 변경에 엄청나게 큰 비용이 들거나 변경 때문에 큰

영향을 받는 도메인인 항공, 국방, 발전, 자동차 분야에서는 상당히 효

과적인 접근방법이라서 형상관리가 필요악처럼 사용된다. 하지만 우리

가 속한 소프트웨어 분야를 보자. 과연 이런 형상관리가 필요할까? 상

당히 어려운 질문이다. 일단 즉답을 피하고, 우리가 많이 쓰는 버전관

리란 무엇인지 살펴보자.

버전관리란 말을 들으면 대개 CVS, 서브버전과 같은 도구를 떠올릴

것이다. 버전관리 도구란 소프트웨어를 구성하는 소스 코드, 설정 파

일, 리소스 파일이 변경될 때마다 자동으로 버전을 생성해서 관리해

주는 도구다. 아울러 버전관리 도구엔 여러 개발자가 공동으로 개발

하는 기능도 있다. 따라서 버전관리라는 말을 들었을 때 대표적인 버


전관리 도구를 떠올리는 것은 당연하다. 버전 관리 활동을 파일을 직

접 조작하는 식으로 진행할 수도 있지만 그렇게 하는 것은 낭비가 심

하다. 따라서 버전 관리를 할 때는 버전관리 도구를 잘 쓰는 게 편하다.

그렇다면 버전관리와 형상관리는 어떻게 다를까? 사실 다르다고 말

하기는 어렵다. 형상관리 활동의 일부로 버전관리가 포함되므로 형상

관리가 버전관리를 포함한다고 보는 게 맞다. 그럼에도 이번 장의 제목

을 “형상관리와 버전관리는 다르다”라고 정한 이유가 있다. 버전관리

를 쓰는 맥락과 형상관리를 쓰는 맥락이 다르기 때문이다. 꽃삽을 써

야 할 때와 포크레인을 써야 할 때가 다른 것처럼 말이다.

내가 경험한 프로젝트 가운데 대개 버전관리면 충분할 때가 있었지

만 프로젝트 외적인 이유로 형상관리를 도입해서 쓸 때가 흔했다. 다시

말해, 적절한 도구를 사용해 프로젝트를 수행하지 않은 셈이다. 반대

로 내가 컨설팅했던 조직 가운데 형상관리가 필요한데 버전관리조차

하지 않는 곳도 있었다. 포크레인이 필요한데 손으로 땅을 파니 일이

제대로 될 리가 없었다.

이런 문제가 일어나는 이유는 다양하겠지만 일할 사람에게 사용할

도구를 선택할 자유나 권한을 주지 않기 때문이다. 버전관리로 충분

한 프로젝트 팀에 회사 정책이니 반드시 형상관리를 하라고 지시한다.

당연히 프로젝트에 도움도 안 되고 형식적인 형상관리로 끝난다. 반대

로 형상관리로 대규모 형상항목을 관리해야 할 조직에서 버전관리 도

구도 쓰지 않고 형상관리를 하지 않으니 여기저기서 문제가 터진다. 개


발자들은 이런 문제를 지적하지만 조직에서는 다양한 이유로 이런 문

제를 받아들이지 않는다.

PM으로서 프로젝트를 시작할 때는 프로젝트에 필요한 게 무엇인지

파악해야 한다. 형상관리가 필요한 경우는 대규모 시스템 개발을 할 때

다. 소프트웨어만 개발하는 게 아니라 하드웨어와 기구(기계)도 개발

하는 경우다. 이때는 프로젝트 팀 내외로 노출되지 않는 사소한 변경

때문에 프로젝트가 영향을 받기 때문에 다소 관료적이라도 형상관리

를 쓰는 게 좋다. 아울러 프로젝트를 둘러싼 분위기가 상당히 관료적이

거나 적대적일 때 형상관리를 써야 한다. 고객이 요구사항을 마구 바꾸

거나 문제가 생겼을 때 그 책임을 프로젝트 팀에 전가하려는 분위기라

면 PM은 이런 적대적인 분위기에서 팀을 보호하는 수단으로 형상관리

를 고려하는 것이 좋다.

형상관리가 필요한 경우를 제외한 나머지 경우에는 버전관리를 쓰

는 게 좋다. 버전 관리의 필요성에 대해서는 여러 책에서 이야기했으니

다시 이 책에서 반복하지 않겠다. 소프트웨어를 개발하는 조직이라면

팀원이 많건 적건 반드시 버전관리 도구를 써야 한다. 그렇지 않고 파

일 서버에 의존해 개발한다면 그 프로젝트는 프로젝트 기간 동안 파일

이 삭제되는 문제나 버전 충돌 문제로 골치를 앓을 것이다.


소프트웨어 프로덕트 라인은 은총알이 아니다!

소프트웨어 프로덕트 라인(So�ware Product Line)이라는 게 있다. 줄여

서 SPL이라고 부른다. SPL은 제조업 분야에 제품 라인업과 비슷한 개

념이다. 제품 라인업은 제품을 개발할 때 저가 제품부터 고가 제품까

지 일렬로 세워 놓고 공통으로 들어가는 부품을 개발하고 이것들을

넣거나 빼면서 제품을 만드는 방법이다. 자동차 산업에서는 이러한 제

품 라인업 개념을 잘 사용한다.

즉, 소형차 플랫폼, 중형차 플랫폼, 대형차 플랫폼을 만들어 각 플랫

폼별로 디자인이 차별화된 자동차를 개발하고, 엔진 같은 것은 플랫폼

과 상관없이 여러 차종에 걸쳐 두루두루 사용한다. 예를 들면 국내에

서 생산되는 소나타와 K5는 중형차 플랫폼을 함께 쓰고, 디자인을 차

별화해서 제품을 만들며, 소나타와 K5에 탑재되는 엔진은 대형차나

준중형차에서도 사용할 때가 있다.


공용화 전략에 바탕을 둔 제품 라인업은 다양한 제품을 제조하는

경우 상당히 효과적인 접근법이다. 여러 제품을 싼 가격에 만들 수 있

기 때문이다. 다양한 고객을 대상으로 소프트웨어 제품을 만들어야

하는 경우 SPL도 제품 라인업처럼 상당히 괜찮은 접근법이다. 즉, 소

프트웨어의 기초 부품과 같은 것을 만들어 넣고 빼면서 소프트웨어를

만들기 때문에 기초 부품만 잘 만들고 쉽고 빠르게 조립할 수만 있다

면 비용과 시간 측면에서 상당히 효율적이다. 물론 말은 쉬운데 구현

은 그렇지 못하다.

소프트웨어를 개발하는 조직에서 생산성을 높이는 일을 주로 하고

있기 때문에 몇 년 전에 이러한 SPL의 중요성을 고객들에게 많이 이야

기하곤 했다. SPL의 개념을 설명하면서 대표적인 성공사례로 노키아

를 들었다. 노키아의 휴대폰이 전 세계를 지배하고 있을 때 여러 성공

요인이 있었지만 SPL이 주요한 성공 요인으로 지목됐기 때문이다. 노

키아가 휴대폰 제국의 황제로 군림할 당시 1년에 25~30개의 모델을 출

시했다. 모델 개수가 이렇고 여기에 전 세계로 휴대폰이 출시되는 상황

을 생각한다면 개발해야 할 소프트웨어의 양이 엄청나다.

따라서 다양한 고객을 대상으로 제품을 생산해내는 노키아 입장에

서 SPL은 꼭 필요했다. 소프트웨어의 기본 재료를 만들어 놓고 이것을

조립해서 사용한다는 전략이 없다면 다출시 모델 전략은 실현할 수 없

었을 것이다. 물론 개발자를 많이 고용한다면 가능하기도 했으나 이익

이 급격히 감소했을 것이다.


한때 전 세계를 지배했던 노키아가 이제 그 앞날을 예측할 수 없는

상황이다. 외국인 CEO를 영입하고 이 CEO가 한때 캐쉬카우의 근본

이던 플랫폼이 불타오르고 있다고 말했다. 그러더니 심지어 자사의 핵

심역량이라고 할 수 있는 SPL의 심장인 심비안을 버리고 윈도 기반의

휴대폰을 개발하고 있다. 노키아가 황금기를 누릴 당시만 해도 노키아

의 운명이 이렇게 되리라고 누가 예측할 수 있었을까?

아이폰이 나오기 전까지 노키아의 전략은 상당히 효과적이었다. 그

리고 제품을 만드는 사람들은 흔히 이렇게 이야기했다. 다양한 계층의

고객을 만족시키려면 다양한 제품을 출시하는 다모델이 필요하고 이

런 것들을 쉽게 만들 수 있는 SPL 같은 방법이 핵심이라고 말이다. 하

지만 아이폰은 이런 논리를 완전히 뒤집어 버렸다. 하드웨어, 기구, 소

프트웨어의 완벽한 통합, 제품과 서비스를 이어주는 완벽한 생태계를

구축함으로써 게임의 룰을 바꿔 버린 셈이다. 결국 이처럼 변화한 환

경에서 노키아의 독점적 위치를 유지해 준 SPL이란 자산은 이제 발전

을 가로막는 덫으로 변해 버렸다.

잘 알려진 사실이지만 노키아 내부에서도 아이폰과 같은 제품을 만

들 가능성이 있었다고 한다. 하지만 그런 변혁의 기회를 놓치고 나자

간단한 다이어트로 회복할 상황이 빼와 살을 깎는 대수술이 아니면

회복 불가능한 사태가 되어버렸다. 여기서 얻을 수 있는 교훈은 뭘까?


흔히 말하는 효율성의 덫에 걸려서는 안 된다는 것이다. SPL은 구축

하기 쉽지 않지만 일단 구축했을 때 소프트웨어 회사에서 SPL을 통해

달성할 수 있는 효율성은 극대화된다. 극단적으로 설정 파일의 변경만

으로도 고객이 원하는 소프트웨어를 만들 수 있기 때문이다. 엔지니어

입장에서 최소한의 노력을 들여 효율을 극대화할 수 있는 SPL은 일종

의 은총알로 느껴진다. 하지만 이런 효율성의 매력에 빠져 안일하게 지

내다 보면 은총알이라고 여겼던 무기로도 죽지 않는 늑대가 나타나기

시작한다. 말하자면 소프트웨어 개발 조직이 효율성의 덫에 걸려 스스

로 자멸의 길로 들어서기 시작한다.

노키아처럼 자신이 만든 SPL을 포기하는 극약처방을 통해 효율성의

덫에서 탈출하려는 계기를 마련하는 조직도 있지만 대개의 조직에서

는 과거의 성공에 연연하면서 덫과 함께 고사하는 경우가 많다. 다른

회사와의 경쟁에서 이기려면 다른 기업보다 더 빨리 더 적은 자원으

로 소프트웨어를 만드는 게 중요하다. 이런 효율성의 관점에서 본다면

SPL은 상당히 유효한 방법이다. 하지만 지금 하는 것을 더 잘하는 것

에 열중하다 보면 시장의 변화를 파악하지 못하게 된다. 지금 하는 것

을 잘하는 것보다 시장에서 원하는 것을 할 기회를 놓치는 것이다. 다

른 말로 하자면 효율적으로 일을 하는 데 빠져서 효과적으로 시장을

지배할 기회를 놓친다.


물론 노키아처럼 SPL과 같은 효율성을 택할지, SPL을 만들 자원으

로 아이폰과 같은 새로운 개념의 제품을 만들지는 엔지니어의 의사결

정이 아닌 경영자의 의사결정일 수 있다. 그렇다 하더라도 소프트웨어

개발에서 효율성을 추구할 때 항상 효과성의 개념도 신경 써야 한다.

그렇지 않다면 우리가 열심히 만든 SPL과 같은 도구가 적이 아닌 우리

를 잡는 덫이 될 수 있기 때문이다.

대한민국 소프트웨어, 리스타트 위기를 넘어 도약으로

Documents