금융보안과 한국 소프트웨어 미래의 심각성

아래 기사는 필자가 안철수연구소의 부사장/CTO 였던 거의 9년전인 2006년에 연두기자회견때 기자들과 인터뷰했던 내용이었다. 필자도 금융권을 해킹할 수 있다는 내용일 만큼 파격적이어서 그 당시에는 여러군데 기사가 나왔었다. 당시에 잠깐 큰 이슈가 되었었지만 내용의 심각성때문인지 곧 덮어졌다. 아마도 이해관계가 얽힌 다양한 기득권층에게 이익이 되지 않기 때문이었으리라고 추측한다.

요새 농협의 증발해 버린 돈 사건에서 처럼 중국 해커들이 돈을 인출해 가는 것은 필자가 기자회견에서 예견했듯이 너무 뻔한 인과의 결과이기 때문에 앞으로도 계속 발생할 것이며 억울한 피해자가 속출할 것이다. 금융보안의 문제는 고객의 편리함을 제공한다는 명분아래 필연적인 보안의 취약점이기에 피하기도 어렵다. 시작이 잘못된 것이다.

금융권에서의 보안 불감증의 문제보더도 더 중요한 것이 소프트웨어 산업의 멸망이다. 사회에 만연된 불감증으로 지금대로 가다가는 한국 소프트웨어 산업도 금융 문제와 같이 깊은 늪에 빠질 것이다. 필자가 그동안 여러 저서를 통해 얘기해 왔지만 8년 전의 금융 보안에 대한 경고와 같이 미래 10년 후의 한국 소프트웨어가 암울해 보이는 것은 사실이다. 근본적인 변화는 없이 얼굴화장이나 하는 정도의 소극적인 변화로는 현재 처한 한국 소프트웨어의 문제는 해결되지 않는다.

아인슈타인이 다음과 같이 말했다.
"같은 일을 반복해서 되풀이하면서 다른 기대를 소망하는 것은 미친 짓이다."
"Insanity: doing the same thing over and over again and expecting different results."

이제 탁상공론은 그만하고 기득권도 내려놓고 근원적인 개혁을 시작하지 않으면 한국 소프트웨어는 없다.

아래는 8년전 기사이다.

안철수 연구소 “대한민국은 사이버전쟁 전야…중국해커에 노출 무방비” [기사원본가기]
기사입력 2006-03-20 21:28 | 최종수정 2006-03-20 21:28 0




[쿠키인터넷] “대한민국은 사이버전쟁 전야같다.”

안철수연구소의 김익환 최고기술책임자(CTO) 겸 부사장은 20일 서울 세종로 프레스센터에서 열린 ‘안철수연구소 창립 11주년 기념’ 기자간담회에서 “보안불감증이 심각하다”며 이같이 말했다.

김 부사장은 “기업이나 은행,기관 모두 마음만 먹으면 공격할 수 있고 막을 방법은 없다”며 “나 역시도 지금 당장 해킹할 수 있을 만큼 보안이 취약하다”고 덧붙였다.

그는 중국 해커들이 가장 두려운 대상이라고 언급한 뒤 “한국은 아직까지 폐쇄적인 구조라 금전적 이득을 얻기 힘들기 때문에 공격을 감행하지 않고 있는 것 같다”고 설명했다. 인터넷뱅킹을 예로 들면 미국은 외화의 송금 및 반입이 자유로운 오픈타입인 반면 한국은 외화 거래가 자유롭지 않은 폐쇄타입이라는 것.

공개키기반구조(PKI)와 관련해서도 의문을 제시했다. 일각에서 PKI는 공격할 수 없는 최상의 장치라고 얘길 하지만 실제로는 ‘뚫린다’는 게 김부사장의 얘기다. 그는 “PKI는 숫자 두개를 곱해서 나온 조합으로 얼마든지 해킹할 수 있다”며 “다만 시간이 오래 걸려 못 뚫는다는 얘기가 나오는 것”이라고 덧붙였다.

그는 또 “10년전만 해도 재미로 해킹하던 ‘매시브 어택(massive attack)’이 주를 이룬 반면 현재는 금전적 이득을 얻기 위한 피싱 등 무작위 공격이 기승을 부리고 있다”며 “미래에는 특정대상을 겨냥한 전세계 어떤 업체도 못 막는 공격이 자행될 것”이라고 경고했다.

2004년 3월 안철수 연구소에 영입된 김 부사장은 서울대 공대를 나와 미국 산호세주립 대학에서 전산학을 공부한뒤 실리콘밸리의 모체인 스탠포드 대학에서 컴퓨터공학 석사 학위를 받았다. 그는 GE를 거쳐 선마이크로시스템즈에서 현재 구글의 최고경영자인 에릭 슈미트와 함께 근무하는 등 쟁쟁한 IT전문가들과 함께 실무 경력을 쌓았으며 1995년부터 9년간 실리콘밸리에 소프트웨어 회사인 스탠포드 소프트웨어사를 설립해 운영했다. 저서로는 ‘대한민국에는 소프트웨어가 없다’가 있다.

국민일보 쿠키뉴스 이경선 기자 bokyung@kmib.co.kr

SW 개발자 대우 - 10년 전과 달라졌나?

아래 글 "SW 개발자가 우대받는 사회를 만들자"는 필자가 10년 전인 2004년에 정부의 요청으로 기고한 기사였다. 필자가 "대한민국에는 소프트웨어가 없다"라는 책을 출판 한 때가 2003년 이었으니까 그 다음 해이다. 그 때도 SW 개발자를 우대하자는 취지였는데 10년 동안 전혀 변한 것이 없다는 것을 증명한다. 지금도 필자가 비슷한 기사를 쓰는 것을 보면 10년 전과 복사판이다. 전체적인 분위기는 더 악화된 것 같은 생각도 든다. 그만큼 정부, 학계, 기업이 전혀 변하지 않았다. 10년 동안 우리는 무엇을 했는가? 그럼 앞으로 10년이 더 지난다고 변할 수 있는가? 공자님이 2천년 전에 하신 말씀도 아직까지도 따라하지 못하는데 과연 무엇을 바랄 수 있을까 하는 생각도 든다. 지금도 수 많은 탁상공론들이 난무한다. 10년 동안 변하지 않았다는 것을 명심하고 공멸하지 않기 위해서는 모두 기득권을 내려놓고 진심으로 변화하기를 바란다.

SW 개발자가 우대받는 사회를 만들자

한국의 소프트웨어 산업이 발전하기 위해서는 여러 가지 요소가 필요하다. 현실감 있는 정부의 정책도 있어야 하고, 회사도 적합한 환경을 제공해야 되고 소프트웨어 개발자들의 열정도 있어야 한다. 그 중에 개발자들의 열정은 회사나 정부정책에 많은 영향을 받을 수 밖에 없다. 현재는 여러 가지 이유로 소프트웨어에 종사하는 개발자들이 좋은 대우를 받지 못한다. 개발자들이 좋은 대우를 받지 못하니 그 길을 선호할 리 없다. IT 거품이 일어났을 때 몇 년간을 제외하고는 모두가 기피하고 희망이 없는 직종이 되어 버렸다. IT 거품이 꺼지면서 시장수요가 줄었다고는 하나 근본 원인은 다른 곳에 있다.

필자가 소프트웨어분야에 오랫동안 기술자로 근무하면서 새로운 기술을 습득하기 위한 방법중의 하나가 컨퍼런스나 세미나에 가는 것이다. 지금부터 수년 전 미국에서 돌아온 지 얼마 되지 않았을 때였다. 어느 소프트웨어 신기술 세미나에 참석한 적이 있는데 20대나 30대로 보이는 젊은 층밖에 없는 것이었다. 나와 같은 연령대의 사람은 한명도 없었다. 왜 40대, 50대의 기술자는 없는 것인가 생각해 보았다. 미국과 같은 분위기를 생각하고 갔다가 앉아 있기가 민망해서 중간에 나와 버렸다. 그러면서 생각해 보니 미국에서는 빌 게이츠 같은 최고 경영자들이 제품데모도 하고 프리젠테이션도 직접 하는데 한국에서는 최고경영자가 직접 프리젠테이션 하는 경우를 본적이 없다. 그럴 수 있는 능력도 없을 것이다. 높은 직위에 있는 사람들은 보고 받고 결정만 하지 실제 경험은 하지 않기 때문이다.

사회에 잘못된 통념이 있다. 어느 회사나 왜 승진하려면 꼭 관리가 되어야 하는 것일까. 나이 들면 젊은 사람들과 신기술에서 경쟁하기 어렵다고 한다. 나는 동의하지 않는다. 이유는 다른 곳에 있다. 기술습득에 시간을 소비하지 않고 관리업무에 시간을 소비하기 때문이다. 관리업무도 하고 기술습득도 하려면 뒤떨어 질 수 밖에 없다. 실제 소프트웨어 회사의 현황을 살펴보자. 회사의 종류를 살펴보면 단발성의 프로젝트를 주로 하는 SI 업체를 제외하면 정말 경쟁력 있는 패키지 소프트웨어를 만드는 기업은 몇 손가락에 꼽힌다. SI 업체는 수 많은 단발성의 프로젝트를 하므로 관리쪽이 더 중요하다. 기술자는 찬밥신세가 되기 쉽다. SI 업체가 아니고 패키지를 개발하는 소프트웨어회사에서도 소프트웨어 엔지니어로 시작해서 능력 있는 사람들은 대부분이 서서히 관리직으로 넘어가게 된다. 관리직으로 넘어가지 못하면 도태되어 회사를 그만 두는 수 밖에 없다. 사농공상의 전통문화와 굴뚝산업에 익숙한 경영진들의 경영방식 때문에 소프트웨어산업은 악순환을 거듭할 수 밖에 없다. 전문가의 가치를 모르니 전문가가 생겨나기 어렵고 전문가가 없으니 좋은 제품을 만들 수가 없고 그러니 경쟁력이 떨어져 장기적으로 성공하기 어렵게 된다.

미국의 소프트웨어회사를 방문하게 되면 주시해 볼 것이 있다. 주요 기술직에 있는 사람을 만나게 될 때 잘 주시해 보면 대개 나이가 많은 사람들임을 알게 될 것이다. 40대에서 50대 60대 까지도 있다. 그런 사람들의 명함에는 보통 “Fellow Engineer”, “Chief Engineer”, “Chief Scientist” 라고 쓰여 있다. 이러한 사람들이 회사에서 하는 역할은 기술적 업무와 중요한 결정을 담당하게 되는데 관리쪽 일은 전혀 안 하는 경우가 대부분이다. 관리쪽 일을 하게 되면 이미 기술자로서의 능력을 조금씩 상실하게 된다. 회의에서 만나더라도 이런 사람들의 결정이 가장 중요하다는 것을 명심해야 한다. 새 제품을 기안하는 사람은 마케팅부서 같은 기획조직에서 시작할 지 모르나 그 기안을 승인하는 것은 기술적인 면에서는 이런 최고 기술자가 한다. 기술적으로 승인이 안 나면 프로젝트는 취소될 수 밖에 없다. 기술적으로 안 된다는데 무대포로 밀어 붙일 수는 없다. 이런 기술자는 회사의 운명을 좌우할 수 있는 직위이다. 비슷한 명칭으로는 기술이사나 아키텍트라고도 할 수 있다.

요새 한국에서 아키텍트라는 말을 많이 사용한다. 사람마다 의미를 조금씩 다르게 사용한다. 한가지 경우를 살펴보자. 소프트웨어분야에는 많은 요소기술이 있다 J2EE, 닷넷, CBD 등등 많다. 이러한 요소기술 전문가라는 뜻으로 아키텍트라는 명칭을 붙인다. 요소기술 아키텍트는 양성되기가 상대적으로 쉽다. 경험보다는 지식적인 부분이 더 많기 때문에 교육으로 쉽게 양성될 수 있다. 이러한 요소기술 아키텍트보다는 전체 개발 프로세스를 이해하고 어떠한 제품도 처음부터 끝까지 개발할 수 있는 체계와 정책을 수립할 수 있는 경험과 지식을 균형되게 소유한 확장형 아키텍트가 바로 최고의 기술자이며 또 필요한 것이 한국 소프트웨어의 현실이다. 이론적인 요소기술 지식으로서는 세계 어느 나라에도 뒤지지 않는다. 소프트웨어 엔지니어들을 보면 열심히 공부하는 사람들이 많다. 소프트웨어 엔지니어링, UML 방법론 등 책에서 다 익힐 수 있다. 하지만 오케스트라의 지휘자같이 전체적인 측면에서 바라볼 수 있는 경험과 지식을 두루 갖춘 안목있는 확장형 아키텍트가 필요한 것이다.

소프트웨어기술자들이 언론매체에서 앤티 IT라는 말을 만들어 절망적인 상황을 표현했듯이 지금과 같은 기업문화에서는 소프트웨어 엔지니어들의 희망도 없고 아키텍트나 Chief Engineer와 같은 국가발전의 원동력이 될 기술자도 양성되기 어렵다. 모두 관리자의 길로 빠질 수 밖에 없고 전문지식 없이 기술적인 판단을 할 수 밖에 없다. 그렇게 해서는 올바른 결정이 나올 수도 없고 기술적으로 경쟁력 있는 제품이 생산될 리 만무하다. SI 업체와 같이 수주를 받아서 개발해 주는 회사는 되도록이면 저렴한 임금의 초급엔지니어들을 사용해서 이윤을 남기는 것이 최대의 목적이니까 하청업체에다가 헐 값에 넘기게 되고 하청업체는 당연히 값싼 엔지니어를 고용할 수 밖에 없는 것이 소프트업계에 종사하면 누구나 다 아는 현실이다. 이러한 환경에서 회사에서 최고의 연봉과 지위를 보장 받는 아키텍트들을 고용한다는 것은 어려울 수 밖에 없다.

이러한 소프트웨어 문화 때문에 아키텍트라고 불리는 전문기술자 숫자가 절대적으로 부족하다. 이제부터라도 아키텍트를 양성하는 것도 중요하고 그러한 아키텍트들이 살아남을 수 있는 기업의 문화가 중요함은 두말할 나위도 없다. 소프트웨어 기술자들이 기술직에 전념할 수 있는 환경을 기업이 제공해 줄 수 있다면 소프트웨어발전의 기초는 세워진 것이다. 동시에 정부의 정책도 이런 기술자들을 정부관리에 등용할 수 있는 기회를 만들면 현실에 맞는 정책이 수립되지 않을까 생각된다. 소프트웨어가 발전하기 위해서는 천재 경영자가 필요한 것이 아니고 소프트웨어 기술자가 우대 받고 존경 받는 문화가 가장 중요하다. 그러면 좋은 소프트웨어는 저절로 나온다.

SWEBOK - SW 프로세스 #1 소개

SWEBOK SW Process #1 - 2014-11-02

8장 Software Engineering Process (소프트웨어 공학 프로세스)

(*** 필자주석) 1장의 "Requirements"를 끝내고 2장 설계를 설명하는 것이 순서이긴 하지만 국내 소프트웨어 산업에서 가장 많이 유행했던 용어가 "프로세스" 이었기 때문에 순서를 바꾸어 이 Chapter를 먼저 설명하기로 한다. 프로세스는 효용성 면에서 가장 논쟁적인 이슈이기도 하다. 프로세스라는 일반 용어는 수천 년간 사용되어 왔다. 어떤 일을 체계적인 단계를 정해서 각 단계에 시작 상태가 있고, 정해진 행위를 하고, 산출물이 나오는 것을 표준화하는 것이다. 요리를 해도 프로세스가 있고 골프를 치러가도 프로세스가 있다. 하지만 천재 물리학자인 스티븐 호킹이 말하기를 "인간에게 표준은 없다." 라고 했다. 과학에서도 똑같은 시험결과가 나오지 않는 것과 같이 인간 사회에서의 행동 패턴을 어떤 하나의 표준 프로세스로 정의할 수는 없다는 것이다. 인생에도 생로병사의 표준 프로세스가 있다고 생각하면 있는 것이지만 모든 사람의 인생이 다르기 때문에 표준이 없다 라고 말할 수도 있다. 프로세스라는 용어 자체가 극도로 추상적인 단어이기 때문에 증명도 어렵고 반증도 어려운 세계이다. 이런 추상화된 세계의 특성에 따라 자연히 사기꾼들이 성행하게 되니 매우 조심할 일이다.

프로세스에 관한 한 국내 소프트웨어 업계에서는 미국의 CMMI나 유럽의 SPICE와 같은 인증위주로 진행되어 왔다. 사실 이런 인증들은 돈만 들이고 문서만 적당히 만들어 내면 누구나 인증을 받을 수 있다는 것은 업계의 관계자들이라면 모두 알고 있다. 현실을 반영하기 보다는 조작에 가까운 문서를 작성해서 인증을 받는 경우도 비일비재하다. 그렇게 인증을 받았다고 자랑스럽게 언론기사에 광고할 수도 있지만 그런 인증들은 ISO와 같은 국제 표준도 아니고 사실은 인증도 아닌 등급일 뿐이다. 아래 문장을 읽어보면 그 실체를 조금 더 객관적으로 이해할 수 있다.
 

Organizations can be “Rated” at a Capability or Maturity Level based on over 300 discreet “Specific” and “Generic” Practices. Intended to be broadly interpreted, the CMMI is not a “Standard” (ala ISO), so achieving a “Level” of CMMI is not a certification, but a “rating.”

 

CMMI의 경우 SEI가 자기들이 정한 어떤 기준에 맞으면 그 수준을 인정하는 것이고 그런 인증을 요구하는 소수의 업체들과 비지니스를 하려면 필요하긴 한다. 하지만 인증이 실력으로 가치가 있는지 아닌지를 판단하기 위해서는 자기 이력서에 인증 경험을 적어서 취업에 도움이 된다면 가치가 있다고 보면 된다. 국내 이력서에서 프로세스 경험을 적은 것을 심심치 않게 보았다. 국방이나 자동차산업과 같은 특수한 분야에서는 도움이 될 수 있다. 하지만 실리콘밸리에서는 취업에 도움이 되기 보다는 그게 뭔지를 설명하느라 시간만 낭비할 것이다. 실리콘밸리의 회사에서 면접 시에 프로세스에 대한 질문은 하지 않는다.

프로세스의 진정한 가치는 체크리스트와 같은 형식이 아닌 산출물의 내용에 있고, 그 내용의 충실성을 지속할 수 있는 현실적인 프로세스에 있다. 국내에서는 이벤트용으로 인증 받았으니 언론에 자랑스럽게 내는 것은 이해하지만 그 속을 들여다 보면 대부분 실속은 없고 결론적으로 보면 언론에 기사 내는 것이 가장 큰 혜택 중의 하나이다. 이런 관행이 국내 SW 업계 경영자들의 맹목적인 경영방침을 반영하기도 한다. 이런 점이 기업평가 사이트인 glassdoor.com에서 보듯이 국내 기업의 경영진들이 외국인 엔지니어들에게 전문성이 없다는 평가를 받는 이유이다. 인증을 받고 외국 파트너와 얘기를 시작할 수는 있지만 결국은 품질을 확보할 수 있는 현실적인 프로세스여야 가치가 있다. 실리콘밸리에 가서 SW 엔지니어들에게 CMMI나 SPICE를 아는지 물어보면 대부분 용어도 들어본 적도 없다는 것에 놀랄 것이다. 더욱 놀라운 것은 실리콘밸리의 벤처회사도 국내에서 CMMI의 최고 등급을 받은 회사보다 훨씬 더 현실적으로 좋은 프로세스를 가지고 있고 개발도 더 잘한다는 것이다.

국내에서 생각하는 프로세스와 실리콘밸리에서 경험하는 프로세스는 겉모습과 용어는 같을 지 모르지만 속을 들여다 보면 완전히 다르다. 같은 용어라도 모든 회사에게 다 다르게 적용된다. 옳은 것도 아니고 틀린 것도 아니고 적용을 잘해야 하는 것이 프로세스의 어려운 점이다. 손자병법을 읽는 것은 쉬우나 현실에 적용하는 것은 완전히 다르다. 많은 사람들이 손자병법을 읽었지만 손무가 되기는 어렵다. 즉 손자병법을 읽었다는 인증은 받을 수 있지만 소프트웨어 개발이라는 전쟁은 수행하기 쉽지 않다. 아무튼 국내는 소프트웨어 프로세스가 극단적으로 형식적인 면에 치우쳐 적용되고 있는 갈라파고스 섬이다. 대부분의 회사는 프로세스 정립에 돈과 시간을 낭비할 확률이 높지만 시행착오를 하면서 배운다고 위안을 해보자. 단 국내 소프트웨어 산업이 돈과 시간 낭비하다가 외국 경쟁사에 뒤떨어지지 않을 정도만 시행착오를 해 보는 것이 좋겠다.

소개 - SW 공학 프로세스

공학 프로세스는 Resource를 투자해 어떤 Input을 Output으로 변환시키기 위한 일련의 행위를 의미한다. 전기, 기계, 토목, 화학과 같은 전통적인 공학에서는 에너지와 물리적인 형태를 다른 형태로 변환시키는 것이다. 소프트웨어 공학에서는 소프트웨어 엔지니어가 요구사항분석, 설계, 구현, 테스트, 형상관리와 같이 소프트웨어를 개발하고 유지보수하는 일련의 행위와 관련되어 있다. 여기서는 가독성을 위해 "소프트웨어 공학 프로세스"를 그냥 "소프트웨어 프로세스"라고 부르기로 한다.

소프트웨어 공학 프로세스는 다음과 같은 여러 목적을 위해 이용된다.
* 사람들간의 이해, 소통, 협업을 돕고,
* 소프트웨어 프로젝트의 관리를 돕고,
* 소프트웨어 품질을 측정하고 향상시키고
* 프로세스 자체의 개선을 돕고
* 프로세스 실행을 자동화하기 위한 기반으로 이용된다.

소프트웨어 공학 프로세스 지식영역은 다음과 같이 나누어 진다.

1. 소프트웨어 프로세스 정의 (Definition)
1.1 소프트웨어 프로세스 관리 (Management)
1.2 소프트웨어 프로세스 구조 (Infrastructure)

2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)

3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)

4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)

5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)

위의 5개의 Topic을 다음 Post 부터 하나씩 설명하기로 한다.

SWEBOK - 소프트웨어 요구사항 #9 (최종)

SWEBOK 해설 Software Requirements #9 (최종)

(***필자주석) 이번 포스트가 Software Requirements의 마지막 포스트인 도구에 관한 꼭지이다. 이제 Requirements를 끝내고 다음은 설계(Software Design)에 대한 포스트를 시작될 것이다. 이 꼭지는 양이 많지 않으니 먼저 번역을 하고 주석을 달도록 하겠다.

1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

Software Requirements와 관련된 도구는 크게 두 가지로 나누어 진다. "모델링 도구"와 "요구사항 관리도구" 이다.

요구사항 관리도구는 문서화(Documentation), 추적(Tracing), 변경관리(Change Management) 등이 있는데 실제 개발에 큰 영향을 미친다. 사실 요구사항 추적이나 변경관리는 도구가 없이 수행하기는 비현실적이다. 요구사항 관리도구는 요구사항 관련 업무에 핵심적이기 때문에 많은 회사들이 요구사항 관리도구에 투자를 했다. 반면에 훨씬 더 많은 회사들은 만족스럽지는 않지만 스프레드시트와 같은 임시변통(Ad hoc)의 방법으로 관리한다.

(***필자주석) 국내에는 도구에 대한 맹신이 있다. 사실 SWEBOK에서도 도구에 대해서 마지막에 몇 줄로 간단히 언급했듯이 그렇게 많은 비중을 들이지 않았다. 필자는 국내 회사들이 필요 없는 도구에 대한 광적인 집착을 보이는 경우를 많이 보아왔기 때문에 주의를 주고 싶다. 괜히 필요 없는 건강식품을 믿고 먹다가 돈과 건강을 잃는 피해를 입지 않기 바란다. 거의 대부분의 국내 회사는 도구에 신경쓰기에 앞서서 도구를 이용할 내용을 잘 적는 것에 먼저 모든 노력을 하기 바란다. 지금까지 SWEBOK에서 얘기한 것이 바로 내용을 잘 적기 위한 원리를 설명한 것이다. 도구는 내용이 있을 때 마지막으로 걱정할 문제이고 또 그래야지만 자신에게 맞는 적절한 도구를 분별하고 현명하게 구입할 수 있는 능력이 생긴다.

SWEBOK에서 언급한 2가지 도구 중 모델링 도구에 관해서 많이 언급하지 않았지만 예를 들면 UML의 유스케이스 다이어그램을 만들어 주는 도구가 그 중의 하나이다. UML의 많은 다이어그램 중에 유스케이스 다이어그램은 Requirements를 명시하는 방법 중의 하나이다. 모든 프로젝트의 경우에 이용할 수 있는 방식은 아니지만 많은 경우에 사용되기는 한다.

요구사항 관리도구는 양날의 칼이다. 마치 타이거 우즈의 골프채 같은 것이다. 일반 아마추어 골퍼들이 타이거 우즈의 골프채가 좋다고 똑같은 골프채를 사서 친다면 재앙일 것이다. 비싸기만 하고 손해 본다. 그러지 않아도 요새 골프존마켓의 광고에서 고객과 골프상점 점원이 골프채를 서로 잡고 고객은 가져가려고 하고 점원은 안 뺏기려고 티격태격 한다. 고객 말은 "유소연이 이거 들고 일등 했거든요" 점원 말은 "당신은 유소연이 아니거든요. 손님한테 맞는 채를 사셔야 하거든요". 이 광고의 교훈은 비싼 도구와 나에게 맞는 좋은 도구는 다르다 이다. 물론 골프채의 경우는 비싼 채를 들고 다녀야 남들한테 졸부의 과시도 되고 하니까 전혀 가치가 없는 것은 아니다. 마찬가지로 회사의 경우에도 잘 알지는 못하니까 비싼 도구라도 사서 혹시라도 실패 시에 책임도 면하고 자기 과시도 하는 대기업 경영진들도 있다. 왜 비싸고 좋다는 도구를 샀는데 개발이 잘 안될까 하는 것을 필립 그린스펀은 유치원생이 비행기에 올라타서 이 버튼 저 버튼 눌러보면서 왜 비행기가 안 뜨지 하는 것과 같다고 말했다.

추적 관리도구 같은 경우가 어설프게 사용했다가 큰 피해를 입는 경우이다. 요구사항 내용을 적는 능력이 충분히 있고 그런 상태에서 요구 사항을 추적을 하겠다면 필수적인 도구이다. 스프레드시트를 사용하겠다는 경우는 매우 간단한 경우에 해당한다. 수십 명이 개발하는 규모 정도의 프로젝트만 해도 요구사항을 스프레드시트로 관리하기에는 어려울 수 있다. 특히 변경이 자주 일어난다면 변경관리는 거의 불가능하다. 하지만 아무리 도구가 좋다고 한들 내용이 제대로 적혀 있지 않으면 관리하는데 쓸데 없는 비용만 든다. 차라리 추적이나 변경 관리를 하지 않는 것이 좋을 수도 있다.

그럼 언제 도구가 효용성을 발휘할까? 이 답은 글을 쓰는 것과 비교해서 얘기할 수 있다. 내가 글을 쓰려고 하는 데 원고지에다 연필로 쓸까? 간단한 노트패드로 쓸까? 비싼 MS 워드로 쓸까? 하는 질문과 같다. 어떤 도구를 사용하든 먼저 글을 쓸 내용이 준비 되어 있어야 한다. 즉 생각하는 역량이 있은 다음에야 도구가 도와주는 것이다. 도구는 지원하는 도구일 뿐이지 글을 적는 데 핵심은 아니다. 뭘 적을 지도 모르는데 워드 띄워 놓고 쓰레기나 타이핑한다고 글은 나오지 않는다. 요구사항의 내용을 잘 적을 수 있을 때 편리성을 도와 주는 것이 도구인 것이다. 도구가 내용을 도출하는데는 도움이 되지 않는다. 내용을 도출하는 것은 전적으로 두뇌가 하는 행위이기 때문이다. 도구는 마지막에 기록하는데 도움이 되는 것이다.

결론을 말하자면 요구사항관리도구를 사용해서 혜택을 받을 수 있기 위해서는 어느 정도 수준에 올라야만 한다. 아직 국내의 SI 프로젝트나 회사내부 프로젝트의 경우나 다 SRS를 제대로 작성하고 개발하는 경우가 거의 없다. 앞 장에서 말한 대로 인수테스트를 적을 수 있는가 없는가 로도 그 판단을 할 수 있다. 그런 상태에서는 도구를 사용하는 것이 거추장스러운 존재가 될 가능성이 크다. 반대로 SRS를 잘 적을 수 있는 데 도구가 없다면 문제가 될까? 아마 약간의 효율성 저하가 있을 수는 있겠지만 실리콘밸리의 대부분의 벤처기업이나 중소기업들은 요구사항 관련 도구가 없이도 웬만한 규모의 프로젝트는 잘 수행하고 있다. 도구에 관한 문제는 미리 걱정할 필요도 없고 스스로 SRS 작성 역량이 늘어가면 필요한 도구를 선택할 수 있는 역량이 생긴다. 그 때까지는 도구 영업사원들의 과대광고에 현혹되어 피해를 입지 않기 바란다.

SRS를 잘 적는데 실패하는 프로젝트는 보기 어렵다. 반대로 SRS를 잘 적지 않고 성공하는 프로젝트도 보기 어렵다. 그래서 SW 프로젝트는 처음부터 이미 성공할지 실패할 지를 알 수 있다. 이렇게 SW 산업의 성공 조건은 간단하다. 하지만 "간단한 것이 더 어렵다"는 격언처럼 SW 전 생명주기에서 가장 중요하고 어려운 것이 바로 SRS이라고 SW 공학에서 강조한다.

그리고 다음부터 포스트할 설계에 관한 내용도 SRS를 잘 알고 있어야 이해가 쉽다. 필자도 읽고 이해하는 수준이 아니라 머리 속에서 이 원리를 습관적으로 이용하기 위해서 수 없이 반복해서 읽곤 한다. SWEBOK도 여러 번 숙지하면서 읽었어도 항상 새롭게 깨닫는 내용들이 있다. 독자들도 가능하다면 처음부터 다시 한 번 읽어보기를 권장한다.

SWEBOK - 소프트웨어 요구사항 #8

SWEBOK 해설 Software Requirements #8

(***필자주석) 앞 포스트에서 인수테스트라는 얘기를 했다. 인수테스트를 작성해야 한다는 것은 소프트웨어 공학에서 많이 들었기 때문에 반론의 여지가 없겠지만 언제 작성하는지가 핵심이다. 지금까지 한국의 소프트웨어 회사에서 한번도 본 적이 없는 것이 인수테스트를 가지고 계약하는 것이다. 계약 시에 인수테스트를 충분히 적을 만큼 요구사항이 자세히 나와 있지도 않거니와 설령 나와 있다고 해도 계약을 위해 인수테스트를 작성한다는 생각을 하지 않을 것이다. 인수테스트를 어느 시점에 작성할 수 있는 역량과 현실에서 언제 작성하는가의 이슈는 다르다. SRS 와 함께 완성할 수 있는 역량이 있다면 언제든지 원하는 시점에 완성할 수 있다. 필자가 실리콘밸리에서 록히드와 계약을 하고 개발을 해주었을 때 SRS보다 더 중요한 것이 인수테스트였다. SRS의 내용은 다르게 해석할 여지가 조금 남아 있지만 인수테스트는 100% 통과해야지만 계약을 준수하는 것이다. 하나라도 통과하지 못하면 계약위반이다. 반대로 인수테스트만 통과하면 계약은 종료된다.

물론 실리콘밸리의 회사가 모든 계약에서 이렇게 하는 것은 물론 아니다. 하지만 그렇게 해야 될 때는 그렇게 한다. 할 수 있는 역량은 있지만 필요에 따라 하기도 하고 안하기도 한다. SRS를 잘 적을 수 있어야만 가능하다. 특히 국방부나 원자력발전소와 같이 대규모의 정교하고 안정된 소프트웨어를 개발할 때 중요해진다. 국내에서는 거의 모든 대규모의 프로젝트가 지연된다. 대규모 프로젝트일수록 인수테스트가 중요해지는데 SRS도 정확하지 않은 상태에서 계약시에 인수테스트를 작성한다는 것은 불가능하다.

역량과 이론과 현실의 삼각 관계에서 어떤 선택을 해야 하는가는 항상 어려운 이슈이다. 무모한 동키호테가 될 수도 있고 이론의 늪 속에 빠져 버릴 수도 있다. 하여튼 이론에서는 인수테스트가 SRS 같이 나와야 하지만 여러 가지 이유로 그렇지 않은 경우가 훨씬 많다. 이 쪽지의 주제가 바로 이론과 다를 수 있는 현실적인 고려사항이다. 현실에서는 고려해야 사항들도 이론과 마찬가지로 중요하다.

1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)

이 전체 챕터의 제목인 "요구사항 지식영역"에서 지금까지 진행한 소제목들이 순서적으로 진행하는 것처럼 보이지만 그것은 편의상 단순하게 나열한 순서일 뿐이다. 요구사항은 전체 소프트웨어 생명주기에 관계된다. 미래에 개발될 제품을 위한 요구사항을 위한 변경 관리와 이미 개발된 제품에 대한 요구사항의 유지의 두 가지가 소프트웨어 공학 프로세스의 성공의 핵심이다.

모든 회사가 요구사항을 작성하고 유지하는 문화를 가지고 있는 것은 아니다. 특히 제품에 목숨을 걸고 한정된 자원 밖에 없는 역동적인 신생기업의 경우 이런 문서작업을 불필요한 오버헤드라고 생각하는 것이 통상적이다. 하지만 이런 회사들이 성장하고 고객이 늘고 제품이 진화함에 따라 과거의 요구사항에 대한 내용을 파악함으로써 미래를 위한 변경에 따른 영향과 파급효과를 이해할 수 있다. 그래서 요구사항문서와 변경관리는 성공적인 요구사항 관리 프로세스에서 핵심적인 역할을 한다.

(***필자주석) 요구사항의 문서가 없이 제품만 가지고 있는 경우는 사상누각과 같다. 더 이상 발전할 수가 없고 기존 제품만 유지보수 하는 것이 최선의 결과이다. 마치 빌딩을 지었는데 설계문서가 없는 것과 같다. 과거의 기억을 되살리면서 겨우 유지보수는 하겠지만 더 큰 빌딩을 지으라고 하면 머리의 기억만으로 지금까지 겪었던 경험과 시행착오를 기억할 수는 없다. 또 인력이 변경되면서 그런 과거의 배움은 사라지고 결과물만 남아있다. 새 제품을 개발하면서 적어도 과거에 개발할 때 결정한 사항이나 기술의 선택에 대한 배경이나 이론을 문서 없이 기억하기는 어렵다. 실제로 개발할 때 보면 복잡한 이슈의 경우 며칠 전에 정한 결정사항도 결과만 기억하지 결정에 이른 복잡한 과정은 기억하지 못하는 경우도 많다. 1,2년이 지나서 비슷한 상황이 생겼을 때 시행착오를 하지 않으려면 과거의 정보는 필수이다. 기억에 의존해서 소프트웨어를 장기간 개발하려고 한다면 소프트웨어를 너무 쉽게 생각한 것이거나 동호회 수준의 제품을 개발을 하고 있는 것이다.

7.1 Iterative Nature of the Requirements Process (요구사항 프로세스의 반복적인 특성)

경쟁적이고 시장 주도의 소프트웨어 영역에서는 점점 더 신속한 개발에 대한 압박이 크다. 더군다나 이미 개발되어 있는 아키텍처(구조) 위에서 업그레이드도 해야 하고 새 제품도 만들어야 하고 기존 제품도 유지해야 하는 동시에 벌어지는 다양한 일이 있다. 그래서 요구사항을 도출하고, 기준선(Baseline)을 긋고, 개발팀에게 넘기는 이론적인 순서로 차례로 수행한다는 것은 현실의 요구사항 프로세스에서는 거의 불가능하다. 그래서 대규모 소프트웨어 프로젝트에서 실제 요구사항이 처음에 완벽하게 이해되고 명시된다는 것은 신화적인 얘기이다.

대신에 요구사항은 설계가 가능할 만한 수준의 품질과 상세도로 반복적인 작업을 통해 정리되어 간다. 어떤 프로젝트에서는 모든 특성을 이해하기 전에라도 기준선을 긋고 개발을 하기도 한다. 물론 잘못된 요구사항이 나중에 발견되면 엄청난 피해를 입는 리스크가 있다. 하지만 소프트웨어 엔지니어들은 프로젝트 관리에 의한 일정을 따라야 하는 제약하에서 움직인다. 그런 환경하에서 주어진 자원으로 작성할 수 있는 최고 품질의 요구사항을 만들어야 한다. 예를 들어 요구사항에 대한 어떤 가정도 분명한 근거가 있어야 하고 알려진 문제에 대해서도 확실히 해결할 수 있다는 근거하에서 가정을 해야 한다.

(***필자주석) SRS를 작성하는 과정에서 가장 어려운 부분이 바로 Assumptions and Dependencies (가정과 의존) 부분이다. 통상적인 국내 개발에서 보면 엄청나게 많은 가정을 가지고 프로젝트를 시작한다. 만약에 가정을 모두 미리 해결할 수만 있다면 프로젝트는 주어진 일정에 정확하게 끝나야 한다. 일정이 지연되는 이유는 알건 모르건 어떤 가정이 생각대로 진행되지 않았기 때문이다. 가정에는 기술적인 이슈도 있지만 인사관리의 이슈도 있고 외주 회사나 플랫폼과 같은 타 회사의 일정에 관계되기도 한다. 그런 경우 가정과 함께 의존성도 생긴다. 이 수 많은 가정을 얼마나 잘 인식하고 도출해 내는 것이 첫번째 필요한 역량이고 그 다음에 어떤 가정을 언제 해결하는가 하는 것을 결정하는 것이 두번째 중요한 이슈이다. 대부분의 국내 회사에서는 거의 희망에 가까운 가정을 하고 해결 계획도 부족한 상태에서 프로젝트에 뛰어든다. 수 많은 가정이 깨어지면서 프로젝트는 아수라장이 된다. 사실은 많은 가정은 아예 초기에 인식조차도 못한다. 이런 상황에서 프로젝트가 제 일정에 끝날 확률은 거의 없다. 프로젝트의 리스크 관점에서는 기능요구사항보다도 훨씬 더 중요하다. 기능요구사항보다 중요한 것이 비기능요구사항이고 그보다 더 중요한 부분이 바로 "가정과 의존" 부분이다. 가정을 모두 해결하고 프로젝트에 들어가는 것은 현실적으로 불가능하다. 그래서 어떤 가정은 해결하고 어떤 가정은 리스크를 택하게 되는데 여기서 인간의 지혜와 경험으로 인한 현명한 결정이 핵심이다. 이 부분이 경험의 차이가 가장 큰 부분이다.

이런 반복적인 모델로 개발하기로 한 프로젝트에서는 요구사항 분석가는 현재 반복주기에 필요한 요구사항의 기준선을 긋고 그 기준선에 기반해서 개발팀은 설계와 구현을 함과 동시에 요구사항 분석가는 다음 반복주기를 위한 요구사항의 기준선을 긋기 위해 분석 작업을 한다. 이 개발모델은 고객에게 제품을 빨리 제공함과 동시에 재작업을 최소화하는 방법이다.

(***필자주석) 대충 보면 이런 방식이 바로 애자일 방식의 개념과 비슷하다. SWEBOK의 저자들이 폭포수 모델을 중심으로 적었을 것이라고 생각한다면 착각이다. 이미 20년 전에도 폭포수 모델의 장단점과 애자일 모델의 필요성에 대한 논쟁도 있었다. 필자도 실리콘밸리의 회사 중 GE와 GTE Government System을 제외하고는 모두 애자일 개념을 사용했다. 물론 그 당시에는 "애자일" 이라는 용어를 사용하지는 않았다. 나중에 만들어진 용어일 뿐이지 그런 행위는 이미 과거 수십 년 전에도 존재하고 있었다. 마치 애자일 방식이 소프트웨어 개발을 잘하는 최신 비법이라고 생각한다면 거대한 착각이다. 소프트웨어 개발의 핵심은 변하지 않았고 그냥 언저리 편법이 건강식품처럼 유행을 타기는 한다. 먼저 정통을 알고 그 다음에 상황에 따라 응용하는 것은 좋지만 정통은 해본 적도 없으면서 편법만 배워서 해결하려고 한다면 100% 실패할 수 밖에 없다.

거의 모든 경우에 요구사항의 이해는 기준선에서 끝나지 않고 설계와 구현단계까지 진화하며 계속된다. 이는 당연히 개발주기의 후반부에서 요구사항의 변경을 초래한다. 소프트웨어 요구사항에서 꼭 이해해야 할 가장 중요한 점은 요구사항의 많은 부분이 변경된다는 것이다. 이유로는 분석 과정에서의 오류도 있지만 많은 경우에 환경의 변화 때문이다. 환경에는 고객의 운영환경, 비지니스 환경, 정부의 규정 변경, 시장의 변화 등이 있다. 무슨 이유든지 간에 요구사항은 변경될 것이라는 것을 인정하고 그 영향을 최소화하도록 불가피하게 준비작업을 해야 한다는 것이다. 변경할 사항은 공식 검토와 승인 프로세스를 따라야 하며 요구사항 추적, 영향력평가, 형상관리와 같은 세심한 관리를 해야 한다. 그래서 요구사항 분석은 생명주기의 전반부에만 한정된 것이 아니라 전체 생명주기에 다 관련된 행위이다. 통상적인 프로젝트에서 소프트웨어 분석 행위는 최초의 도출 과정부터 변경관리의 마지막 단계까지 시간에 따라 계속 진화한다. Top-down 분석과 디자인 모델링의 상위기법과 Bottom-up 구현과 Refactoring 방식의 하위기법의 두 가지 방식이 중간 지점에서 만나도록 해서 두 방식의 좋은 점만을 이용할 수도 있다. 그러나 현실적으로 이런 두 가지 방식의 조합은 소프트웨어 엔지니어들의 경험과 성숙도가 최대한도로 요구되므로 어렵다.

(***필자주석) 앞 쪽에서 필자가 걱정한 것 중의 하나가 SWEBOK이 요구사항이 변할 수 있다고 하는 것이다. 여기서는 한 술 더 떠서 변경 가능성이 아니라 요구사항은 필연적으로 변경된다고 얘기한다. 그럼 변경은 기정사실화 하고 변경이 되기 때문에 요구사항 분석을 대충 하는 것이 좋은가 하는 착각을 하게 된다. 반대로 생각하면 변경이 될 것이기 때문에 그에 대비해서 먼저 분석을 잘해 놓고 나중에 변경 추적, 영향력 분석 등 중요한 이슈들을 분석하고 변경에 대한 대책을 세울 수 있어야 한다. 최초의 SRS가 없다면 변경 시에 더 어려운 일을 당하게 된다. 만약에 요구사항이 전혀 변하지 않고 차라리 문서를 작성하지 않아도 피해가 적다. 결론은 변경이 벌어질 것이기 때문에 SRS를 더 잘 작성해 놓아야 한다.

7.2 Change Management (변경관리)

변경관리는 요구사항 관리의 중심이 되는 토픽이다. 이 토픽은 변경관리의 역할, 프로세스, 변경 내용에 대한 분석 방법에 대한 이슈를 다룬다. Software Configuration Management KA 에서 관련 내용을 다룬다.

7.3 Requirements Attributes (요구사항 속성)

SRS는 요구되는 사양만을 포함하는 것이 아니라 그 외 부수적인 정보들도 포함한다. 부수적인 정보는 요구사항을 관리하고 이해하는 것을 돕는 역할을 한다. 그 중에는 여러 관점에서 본 분류체계(Section 4.1 Requirements Classification), 검증 방법, 관련된 인수테스트계획 등이 있다. 또 각 요구사항이 나온 배경, 요구사항의 근원, 변경 이력 등도 포함된다. 그 중에서도 가장 중요한 속성은 각 요구사항을 식별할 수 있는 고유한 아이디(ID)이다.

(***필자주석) 결국은 나올 수 있는 것은 다 나온다. 각 요구사항을 추적하려면 당연히 고유한 ID가 있어야 한다. 하지만 이런 행위도 요구사항이 적절한 단위로 세세히 나누어지고 잘 분류되어 있을 때 유용한 것이지 수시로 변하거나 대충 큰 단위로 분류를 해 놓았다면 얻는 것보다 시간 낭비할 가능성이 크다. 결국 기본이 되어 있지 않으면 소프트에어 공학에서 말하는 기법을 무조건 사용하는 것은 혜택보다는 피해가 크다.

7.4 Requirements Tracing (요구사항 추적)

요구사항 추적은 요구사항의 근원이 무엇이고 어느 곳에 영향을 미치는 가를 알게 한다. 특히 요구사항이 변경될 때의 영향도 평가에 필수적이다. 요구사항은 뒤로는 시스템 요구사항과 같이 생성의 근원과 요구한 이해관계자들을 인식할 수 있도록 한다. 반대로 앞으로는 그 요구사항을 만족시키는 설계, 소스코드, 테스트 케이스, 심지어는 사용자 매뉴얼의 어떤 부분과 관련이 있는지 까지 추적할 수 있어야 한다.

요구사항 추적은 통상적으로 복잡한 Directed Acyclic Graph(비순환 방향성 그래프, DAG) (Computing Foundation KA참조) 를 형성한다. 이런 DAG나 추적 매트릭스를 관리하는 행위는 전체 생명주기에서 필수적으로 고려해야 하는 행위이다. 만약에 추적표가 제대로 갱신되지 않는다면 영향도 평가를 신뢰할 수 없다.

(***필자주석) 요구사항 추적이 필요하다고 얘기하지만 현실적으로 국내에서 요구사항 추적을 할 정도로 SRS를 잘 적을 수 있는 회사가 있을 까 궁금하다. 기능요구사항은 비기능요구사항에 비해 상대적으로 쉬운 편이다. 실리콘밸리에서도 제대로 하기 어렵고 그래서 잘 이용하지 않는 것이 요구사항 추적이다. 추적을 하라고 하기도 난감하고 하지 말라고 말하기도 난감하다. 특히 대기업일 경우 소프트웨어 공학의 도입에 따라 비싼 도구를 이용해서 시도를 하기도 하지만 그 신뢰성과 효과는 미지수이다. 추적을 하느냐 안하느냐를 결정하기 전에 먼저 SRS를 제대로 적으면서 수 년의 경험을 한 다음에서야 추적을 시도할 것을 권장한다. 프로세스가 요구하니까 무조건 시도했다가는 시간만 낭비하기 딱 좋은 주제이다.

7.5 Measuring Requirements (요구사항 측정)

소프트웨어의 프로젝트에서 어떤 요구사항이 있으면 Volume("양") 에 관한 개념을 가져야 한다. 이 개념은 개발에 드는 비용, 유지보수에 드는 비용, 변경에 드는 비용의 규모를 측정하는데 필요하다. 또 다른 요구사항과 상대적으로 비교할 필요가 있을 때도 유용하다. Functional Size Measurement (FSM, 기능크기측정)이 Function의 규모를 측정하는 기법이다. 이와 관련된 정보는 Software Engineering Process KA에서 다룬다.

(***필자주석) 어떤 요구사항이 있을 때 개발비용과 일정이 얼마나 걸릴까 하는 것은 경영진과 관리자의 최고 관심사이다. 그러니 이 토픽이 소프트웨어 공학에서 없어질 수가 없다. 하지만 이론적이고 수학적인 방법이 과연 가능할까 하는 회의가 든다. 이론적인 소프트웨어 공학자들이 측정이론을 주장해도 일단 필자는 믿지 않는다. 이 부분은 인간의 고유 영역이라고 본다. 규모를 측정하고 일정을 산정할 때의 가장 큰 변수는 누가 개발하는 것이냐 이다. 모든 개발자들의 역량이 다른데 그 상황에 따라서 산정을 다르게 해야 한다. 개발이 끝난 후에 SLOC(소스코드 라인수)나 Function Point를 이용해서 비교하기도 하지만 난이도를 고려하지도 않고 코딩 스타일에 따라 천차만별이기 때문에 큰 의미를 부여할 수 없다. 그럼에도 불구하고 휴대폰에 들어간 소스코드가 몇백만 라인이다 라는 식으로 말할 때는 대충 규모를 판단하는 데 도움이 된다.

8. Software Requirements Tools (도구) - 다음 Post에서 다룬다

SWEBOK - 소프트웨어 요구사항 #7

SWEBOK 해설 Software Requirements #7

(***필자주석) 지금까지 요구사항의 도출, 분석을 지나 명시(Specification) 했다. 이제는 내가 명시한 것이 맞는 것인지를 어떻게 증명하는 검증단계에 왔다. 여기서 대충 넘어가면 재앙이 벌어진다. 바로 소프트웨어공학의 1:10:100 법칙에 따른 피해가 벌어진다. 이 단계를 게을리 하면 잘못된 정보를 가지고 다음 단계인 설계를 열심히 하게 된다. 잘못 명시된 요구사항을 설계 단계에서 발견하면 그나마 다행히도 10배의 피해만 입게 된다. 즉 오류를 수정하는 데 들어가는 비용이 10배가 든다. 그 다음 단계인 코딩 단계에서 발견되면 100배의 비용이 들어 간다. 테스트 단계에서 발견되면 1000배의 비용이 들어간다.

쉽게 이해하려면 건축을 생각하면 된다. 건물을 설계단계의 종이에서 고칠 때와 다 만들어 놓고 고칠 때를 상상해 보면 된다. 이론으로 아는 사람은 많지만 실제 벌어지는 국내 프로젝트에서는 똑같은 시행착오를 지금까지 일이십년을 반복해 오고 있다. 그 이유에는 수십가지가 있지만 모두 다 잘못된 핑계에 불과하다. 필자의 책에서도 누누이 얘기하지만 고쳐지지는 않는다. 유일하게 키움증권의 차세대 프로젝트가 제대로 된 SRS를 작성하고 필자가 아는 한 국내에서 처음으로 제 일정에 완성한 프로젝트였다. 필자의 주장을 증명한 케이스이기도 하다. 이에 관해 지디넷(zdnet)에 실린 기사이다.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140728162641&type=xml

지금까지의 국내 관행대로 똑같은 방법으로 진행한 프로젝트는 모두 일정연기라는 똑같은 결과를 가져왔고 필자의 주장대로 수행한 유일한 프로젝트는 성공했다. 사실은 필자의 주장이 아니라 IEEE의 전문가들 혹은 실리콘밸리의 회사들의 평범한 관행일 뿐이다. 기본을 무시하고는 어떤 것도 잘 될 수는 없다는 것을 보여준다. 건축, 자동차, 전자, 소프트웨어나 모두 다 같다.

앞 단계의 명시단계에서 오류를 범했더라도 아직도 늦지 않았다. 아직은 종이 서류에 불과하고 공사는 시작하지 않았으니 피해 없이 고칠 수 있는 마지막 기회다.

1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)

작성된 요구사항 문서(SRS)는 검증(Validation)과 테스트(Verification)을 해야 한다. 즉 작성한 소프트웨어 엔지니어가 요구사항을 제대로 이해했다는 것을 검증해야 한다. 더 나아가 문서가 회사의 표준에 맞게 작성되어 있고, 이해할 수 있고, 일관성 있고, 완성도 있게 작성되었다는 것을 검증하는 것도 중요하다. 회사의 표준 용어가 외부의 표준 용어와 다르게 사용된다면 그 두 용어 사이의 매핑 테이블을 만들어야 한다. 이런 점에서 누구나 다 이해하는 표준인 공식적인 표기법(Formal Notation)의 방식을 이용해서 작성했다면 매핑 테이블 같은 것을 만들지 않아도 되는 장점이 있다. 고객과 개발자 등을 포함한 모든 이해관계자들이 문서를 검토해야 한다. 이 문서는 소프트웨어 생명주기에 나오는 모든 산출물(설계문서, 소스코드등) 과 동일한 수준으로 그리고 동일한 방법으로 형상관리를 해야 한다. 요구사항관리도구를 이용해서 요구사항 문서를 만드는 경우에도 마찬가지의 형상관리를 해야 한다.

(***필자주석) 형상관리를 소스코드 관리로 한정해서 생각하는 개발자들이 많지만 사실은 요구사항문서(SRS)가 소스코드만큼 중요하기 때문에 철저한 형상관리(여기서는 버전관리를 의미) 해야 한다. 하지만 대부분의 국내 프로젝트는 SRS는 버전관리를 할 만큼 정확하게 적히지도 않고 소스코드와 내용이 일치되지도 않기 때문에 버전관리를 하나 안하나 의미가 없다. SWEBOK에서 말하는 SRS를 형상관리하라는 말은 글로벌 수준의 회사를 기준으로 말하는 것이고 그렇지 않은 회사는 형상관리 하느라 노력한 대가도 없고 그냥 관리비용만 늘어가니 국내에서는 적당히 형식적으로만 하면 될 것이다. 항상 그렇지만 내용이 충실하면 관리가 중요해 지지만 내용이 부실하면 관리를 해도 의미가 없다. 그냥 형식적인 회사 프로세스에서 형상관리를 요구한다면 역시 형식적으로 흉내만 내면 된다. 그래서 기초가 부족한 상태에서 프로세스를 도입한다고 해야 시간과 비용만 들고 피해만 입는다.

적어도 한 번 이상의 검증을 해야 하고 그 검증을 위한 회의 일정을 공식적으로 미리 정해 놓고 하는 것이 정상이다. 근본적인 목적은 개발자원이 투입되기 전에 문제가 있는 지를 찾아내는 것이다. 다시 말하지만 검증(Validation)은 요구사항문서가 우리가 원하는 소프트웨어를 정확하게 제대로 정의했는지를 조사하는 것이다.

(***필자주석) SRS는 필자의 경험으로 Full Review를 적어도 2번 이상은 해야 한다. 한 번에 통과한다는 것은 기적이다. 아직까지 한 번도 본 적이 없다. 가장 잘 적은 경우의 시나리오는 한 번 검토하고, 검토한 결과에 따라 수정하고, 두 번 째 회의에 모여 모든 이해관계자가 승인해 주는 경우이다. 두 번에 통과하기도 매우 어렵다. 여기서 통과하느냐 마느냐 하는 것도 SRS 내용을 자세히 적었을 때 어려운 것이다. 차라리 내용이 대충 추상적으로 제목 정도만 적혀 있으면 통과하기는 쉽다. 대충 적힌 문서는 시비를 걸기 어렵기 때문이다. 나중에 문제가 생겨서 그렇지 일단 SRS는 통과한다. 나중에 수백 배의 피해를 입는 조삼모사이다. 국내 기준으로 보면 RFP 혹은 기획서 정도의 내용이 적힌 문서가 계약에서 통과된다. 그런 것을 SRS 검증이라고 얘기 할 수는 없다. 결국 진정한 SRS는 한 번도 검증되지 않은 상태에서 설계나 코딩이 벌어지게 되는 것이 국내 현실이다. SWEBOK이 가정한 개발 환경과 실제 국내 환경과는 갭이 크니 그걸 감안해서 잘 해석해야 한다.

6.1 Requirement Review (요구사항 검토)

검증에서 가장 많이 사용되는 방법은 조사(Inspection) 혹은 검토(Review)이다. 여러 명의 검토자 들에게 오류, 잘못된 가정, 불명확한 설명, 비표준적인 내용 등을 찾도록 부탁한다. 검토자 그룹의 멤버가 중요한데 예를 들어 적어도 한 명의 고객대표가 참석해야 한다. 검토하기 쉽도록 체크리스트 같은 가이드가 도움이 되기도 한다. 통상적으로 검토는 시스템 정의서 (System Definition), 시스템 사양서(System Specification), SRS(Software Requirements Specification) 이 완성된 다음에 진행된다.

(***필자주석) SWEBOK에서 체크리스트가 있으면 도움이 될지도 모른다고 했는데 이 부분을 잘못 해석하면 체크리스트에 있는 Yes/No 형식의 답을 한다고 생각하면 오산이다. 체크리스트가 제공해 주는 것은 검토를 해야 할 주제를 혹시라도 빼먹지 않도록 하는 것이지 검토 자체를 도와주는 것이 아니다. 예를 들어 "문서의 가독성"을 검토해야 하는데 Yes/No 로 대답한다면 잘못된 것이다. 체크리스트는 올바른 검토를 하기 위해 필요한 가이드이지 체크리스트가 없어서 검토를 못하는 것도 아니고 체크리스트가 있다고 해도 검토를 제대로 하는 것은 더군다나 아니다. 여행 준비물 체크리스트 정도의 의미라고 생각하면 된다. 필자에게 템플릿과 체크리스트를 보여달라고 하는 개발자들이 많은데 검증의 품질과는 거의 관계가 없다는 것을 알기 바란다.

6.2 Prototyping (프로토타이핑)

프로토타이핑은 개발자가 어떻게 사양을 이해했는가를 검증하는 방법이다. 겸사겸사 눈에 잘 보이니 새로운 요구를 추가하기 쉽기도 하다. 요구사항 도출(Elicitation) 때와 마찬가지로 프로토타입이 효율적으로 사용될 수 있는 부분이 있다. 프로토타입의 장점은 개발자가 어떻게 이해했는가를 볼 수 있는 가장 좋은 방법이고 동시에 무엇이 잘못되었는지를 발견하고 의견을 주기에도 적합하다. 동적인 유저인터페이스를 글로 설명하기는 어렵운 반면에 동적인 애니메이션이 훨씬 더 잘 설명할 수 있다. 프로토타입으로 검증된 요구사항이 수정될 가능성은 매우 낮은 것이 장점이다. 안전요구사항이나 중요한 핵심적인 기능들은 프로토타이핑을 해보는 것이 중요하다. 하지만 프로토타이핑의 단점도 있다. 사용자들이 미적인 이슈에 사로 잡혀 진정한 기능을 게을리 볼 수 있는 위험성도 있고 프로토타이핑의 품질이 나쁘다는 데 있다. 그래서 프로토타이핑 보다는 시나리오북 (Flip-chart based mockup) 같은 방식을 선호하기도 한다. 프로토타입은 개발비용이 많이 든다. 그렇더라도 나중에 잘못된 소프트웨어를 개발하는 것보다는 프로토타이핑을 하는 것이 좋을 수도 있다. 만약 프로토타입이 최종 제품과 비슷한 모습을 가지고 있다면 꼭 버릴 필요는 없다.

(***필자주석) SWEBOK에서 프로토타이핑한 결과를 100% 버려야 한다고 주장할 수는 없는 상황이기 때문에 프로토타입을 실제 제품에 사용할 수도 있다고 하지만 필자의 경험으로는 프로토타입은 버리는 것이 옳다. 프로토타입은 가장 신속히 개발해서 SRS를 검증하는 것이 목표이기 때문에 한가하게 아키텍처 생각하고, 주석 달고, 공통코드 추출하고, 에러처리하고, 등등 할 시간이 없다. 그런 코드를 나중에 그대로 써 먹는다는 것은 얻는 것보다 잃는 것이 많다. 물론 프로토타입에 사용한 코드의 일부분을 사용하는 것은 문제가 없지만 프로토타입은 말 그대로 모형이다. 아파트 모델하우스를 고쳐서 실제 살 집을 만들지 않는 것과 같이 프로토타입은 100% 버린다고 생각해라.

6.3 Model Validation (모델 검증)

분석과정 중에 모델 기법을 사용했다면 모델의 품질을 검증하는 것이 필요하다. 예를 들어 객체모델(Object Model)인 경우 정적 분석(Static Analysis)을 통해 객체간에 어떤 데이터가 움직이는 지와 같은 것을 검증할 수 있다. 만약 공식표기법(Formal Notation)이 사용되었다면 공식적인 로직에 기반한 검증방법을 사용하는 것이 가능하다. 이 부분은 Software Engineering Models and Methods KA 와 밀접하게 관련되어 있다.

(***필자주석) 이 꼭지는 대부분의 독자는 건너 뛰어도 된다고 생각한다. 그 이유는 통상적인 SRS에서는 설계의 상위부분을 다루게 되는데 그럴 경우에 Modeling 기법도 사용하고 Formal Notation도 도입할 수 있는데 국내에서는 SRS 단계에서 그 정도까지 생각하는 경우가 거의 없기 때문에 이 꼭지는 거의 의미가 없다. 모델링은 설계단계에서 수행하는 것이라는 흑백논리의 오류인 것이다. 이 점은 앞 단계에서도 이미 언급되었지만 분석이나 설계단계에서 할 일이 흑백논리로 정해지는 것이 아니고 경우에 따라 원칙을 잘 적용하는 것이 실용주의인 소프트웨어공학을 잘하는 것이다.

6.4 Acceptance Tests (인수 테스트)

소프트웨어 요구사항의 필수적인 단계는 개발이 요구사항에 적힌 그대로 개발이 완료되었냐는 것을 확인하는 것이다. 확인될 수 없는 요구사항은 희망사항(Wishes)에 불과하다. 그러므로 확인하기 위해서 꼭 필요한 일은 어떻게 확인할(Verify) 지를 계획하는 것이다. 대부분의 경우에 인수테스트(Acceptance Test)를 사용한다.

(***필자주석) 확인(Verify)하기 위해서는 확인할 대상이 정확이 명시되어 있어야 한다. 확인할 대상이 대충 적혀 있다면 확인을 아무리 잘한다고 한들 의미가 없다. 그래서 필자가 책에서도 말했지만 세계적인 테스트팀이 와도 SRS가 잘 적혀있지 않다면 소프트웨어 품질이 좋아지지 않는다고 하는 이유이다. 하여튼 일단 테스트를 잘 하는 것은 일부라도 품질을 높이기 위해서는 중요하다. 근래 많이 사용하는 테스트 방법론인 V-Model 혹은 V-testing model을 보면 인수테스트 외에도 많은 종류의 테스트가 있다. 확실한 것은 SRS에 대응되는 테스트는 인수테스트이고 인수테스트가 바로 계약에 사용되는 문서이다. 다른 테스트는 계약에 필요한 것이 아니고 개발을 진행하면서 중간에 필요한 테스트들이다. 고객에게 약속한 최종사양은 인수테스트에서 모두 명시되어야 하고 인수테스트만 통과하면 계약은 종료된다.

인수테스트를 도출하고 설계하는 것이 비기능요구사항 (Nonfunctional Requirements) 의 경우에 매우 어렵다. 검증이 가능하려면 먼저 충분히 분석되고 작은 컴포넌트로 나누어지고 숫자적으로 표현될 수 있어야 한다. Software Testing KA 에서 인수테스트에 관한 추가정보를 얻을 수 있다.

(***필자주석) SRS를 적성할 때 요구사항 종류에는 기능요구사항과 비기능요구사항이 있는데 비기능요구사항은 생각해 내기도 쉽지 않다. 생각해 내기도 어려운 데 테스트 하기도 어렵다. 특히 초보자들은 잘 모르니까 "빨리" "사용하기 용이한" 등 추상적인 용어를 사용하게 된다. 그런 용어는 SRS를 적을 때 절대 사용하면 안 되는 감점요인이다. 그리고 프로젝트 실패 중에서도 큰 실패의 원인은 대부분 비기능요구사항의 부족에서 발생한다. 조금이라도 비기능요구사항의 완성도를 높이기 위해서는 많은 실무 경험이 있어야 한다. 비기능요구사항은 템플릿이나 체크리스트조차 만들기 어렵다. 비싼 상용도구를 사용하더라도 도움이 될 수준까지 자세히 가르쳐 줄 수가 없다. 그러다 보니 국내 대부분의 프로젝트는 아예 비기능요구사항을 적지도 않고 진행하기도 한다. 하여튼 비기능요구사항을 충분히 자세히 적을 수 있다면 이미 글로벌 개발 역량을 가지고 있는 것이다. 즉 SWEBOK을 읽을 것이 아니라 SWEBOK을 작성할 수 있는 수준일 것이다. 그만큼 어려운 것이 비기능요구사항의 작성이다.

7. Practical Considerations (현실적인 고려사항) - 다음 Post에서 다룬다

8. Software Requirements Tools (도구)

SWEBOK - 소프트웨어 요구사항 #6

SWEBOK 해설 Software Requirements #6

(***필자주석) 요구사항의 도출, 분석을 지나 명시(Specification)하는 단계에 왔다. 여기에서 SWEBOK의 본질이 무엇인지를 다시 회상해 보자. SWEBOK은 가이드이다. 방법을 가르쳐 주는 문서가 아니다. 가이드 없이 방법을 준다면 시행착오는 필연적이다. 필자의 경험으로 보면 SWEBOK과 같은 가이드는 인생의 가이드와 같다. 그 가이드 아래에서 학교를 가야겠다든지 전공을 전산학을 하겠다든지 하는 큰 골격이 생긴다. 그 골격을 따라가다 보면 실제 실행할 자세한 내용이나 따라 할 모델이 필요하다. 그런 모델이 소프트웨어 요구사항에서는 템플릿이나 샘플이라고 할 수 있다. 하지만 모델이 있다고 혼자서 배울 수 있는 것은 아니고 학교와 같이 스승이 필요하다.

SWEBOK은 방법이 아니라 가이드이다. 매우 중요한 가이드이지만 경험 없이 SWEBOK이 말하는 문장이나 단어를 공감하고 가슴으로 느끼기는 쉽지 않다. 그렇지만 지속적으로 인식하고 있어야 나중에 경험을 할 때 진정으로 도움이 된다. Chicken-and-Egg 문제이다. 필자도 실리콘밸리에서 많은 경험을 먼저 하고 나서 SWEBOK을 나중에 접했기 때문에 진정으로 공감을 할 수 있었지만 독자의 경험의 정도에 따라서 별 도움이 되지 않을 수도 있다는 생각을 한다. 특히 1,2년 경험의 개발자들에게 SWEBOK이 도움이 될지는 회의적이다. 마치 유치원생에게 명심보감을 가르치는 상황과 같다. 그런 경우에 지속적으로 가르쳐서 외우게 하여 인생관을 형성한 것이 선조들의 지혜로운 교육방법이었다. 경험이 없는 상태에서 "왜" 해야 하는 지를 이해하기 어려운 상황에서는 외우는 것이 가장 좋은 가르침의 방법이다. 필자가 태극권을 배우면서 초보자들은 "왜" 를 물어보지 않고 관장님이 시키는 대로 그냥 따라 하는 것이 가장 좋은 배움의 방법이라는 것을 나중에 깨달았다. 경험의 정도에 상관 없이 혹은 지금 얼마나 공감하는 지에 상관없이 SWEBOK을 읽고 또 읽고 하는 것은 결국은 누구에게나 도움이 된다고 생각한다.
 

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)

대부분의 엔지니어링 전문가들에게는 "명시(Specification)" 라는 용어는 제품의 목표를 숫자로 표현하는 것을 의미한다. 소프트웨어 공학에서는 Software Requirements Specification(SRS)는 "시스템적으로 검토될 수 있고 평가될 수 있고 승인될 수 있는 문서" 를 의미한다. 하드웨어 컴포넌트를 포함하는 복잡한 시스템에서는 System Definition (시스템 정의서), System Requirements (시스템 요구사항), 그리고 Software Requirements(소프트웨어 요구사항)과 같은 3가지 종류의 문서가 작성되기도 한다. 간단한 소프트웨어 제품의 경우에는 세 번 째 문서인 소프트웨어 요구사항만 작성이 된다. 이 꼭지에서는 이 3가지 종류의 문서가 적절히 조합해서 사용될 수 있도록 모두에 대해서 설명한다. System Engineering은 SWEBOK의 다른 챕터인 "Related Disciplines of Software Engineering" 에서 설명된다.

(***필자주석) 위에서 3가지 종류의 문서라고 말하는데 그 문서들을 하나씩의 파일로 착각하기 쉽다. 아주 간단한 소프트웨어의 경우에는 하나의 파일로 충분할 수도 있지만 보통은 하나의 파일이 아니라 여러 개의 단위 문서가 집합해서 만들어진 문서의 집합을 말한다. 예를 들어 SRS만 해도 비행기와 같은 거대한 시스템을 만들 때에는 수십개, 수백개, 수천개의 문서로 만들어 지기도 한다. 그 중의 한 부류가 필자가 계속 SRS와 다르다고 언급하는 기능명세서(Functional Description)이다. 기능명세서는 SRS의 극히 일부분일 뿐이다. 각 회사나 정부기관마다 SWEBOK이 말하는 원칙은 모두 동일하게 따르지만 실제 문서의 이름들은 다 다를 수 있다. 실제로 필자는 문서 이름까지 같은 회사는 경험해 본 적이 없다. 즉 모든 회사마다 사용하는 템플릿은 다 상이하다는 얘기이다. 하지만 원칙과 내용은 동일하니 한 회사에서 SRS를 적을 수 있으면 다른 회사에 가서도 SRS를 무난히 적을 수 있다.

5.1 System Definition Document (시스템 정의)

가끔 "사용자 요구사항 문서 (User Requirements Document)" 혹은 "운영문서(Operations Document)"이라고 부르기도 하는 문서인데 시스템의 요구사항을 적는 문서이다.

이 문서는 산업 도메인의 관점에서 상위 수준의 시스템 요구사항을 적는다. 이 문서는 시스템 사용자나 고객 혹은 회사의 마케팅부서(대중에게 파는 소프트웨어인 경우)의 관점을 대표한다. 그러므로 여기에 사용하는 용어도 기술이 아닌 산업 도메인의 관점에서 사용해야 한다. 다음과 같은 내용이 적힌다.

* 시스템 요구사항
* 목표와 배경
* 운영될 환경 (Target Environment)
* 제약 사항 (Constraints)
* 가정 (Assumptions)
* 비기능 요구사항 (Non-Functional Requirements)
* 시스템 전체를 이해할 수 있는 개념 모델(Conceptual Model)
* 사용 시나리오 (Usage Scenario)
* 주요 조직과 사용 워크플로어(Workflow)

(***필자주석) 개발자 경험에 따라 각 항목에 무슨 내용을 적어야 할지 모르는 경우가 많다. 첫번째 항목인 시스템 요구사항은 기능을 적는다고 가정하고 나머지 항목들은 왜 필요한지 조차도 인식하기가 쉽지 않다. 하지만 현실에서 큰 문제가 생기고 외국에서 소송의 대상이 되는 것들은 기능이 아니고 기능 외의 것들이다. 기능은 모든 사람들이 신경 쓰고 있기 때문에 빠뜨리기가 어렵다. 하지만 다른 것들은 무엇을 적는 것인지도 잘 모르는 상태에서 실제 적어야 할 것의 극히 일부분만 적는 경우도 생긴다. 불행히도 책에서는 원칙적인 가이드를 줄 수 있을 뿐 구체적인 항목을 나열해 줄 수는 없다. 모든 소프트웨어가 다르기 때문이다. 그래서 원칙을 특정한 자신의 환경에 적용할 수 있는 응용 능력이 필요하고 그 응용능력은 경험에서 나온다. 이런 역량을 학교나 학원이나 정부기관에서 가르칠 수는 없는 것이다.

5.2 System Requirements Document (시스템 요구사항)

비행기와 같이 소프트웨어와 하드웨어가 같이 필요한 시스템을 개발하는 사람들은 소프트웨어 요구사항과 시스템 요구사항을 따로 적는 것이 통상적이다. 이런 방식에서는 시스템 요구사항을 먼저 적고 거기서 소프트웨어 요구사항이 파생되어 나온다. 엄격하게 말하면 System Requirements Specification은 시스템공학(System Engineering)의 분야이고 소프트웨어 가이드인 SWEBOK의 영역 밖이다.

(***필자주석) 바로 위에서 "엄격히 말하면 System은 SWEBOK의 영역이 아니다"라고 말하지만 사실은 System이나 Hardware나 Software나 모두 Requirements나 Specification을 적는 원칙도 같고 유사한 분석 역량을 필요로 한다. 다만 도메인 영역이 다르므로 거기서 특성의 차이가 있기 때문에 다르다고 할 수 있지만 현실적으로는 90% 이상이 같다. Template도 비슷하고 문서의 구조도 비슷하고 많은 경우에 똑같은 Template을 사용하기도 한다. 필자의 이전 책인 "글로벌 소프트웨어를 꿈꾸다(2010년)"에서 차이점과 유사점에 대해 설명한 적이 있다.

5.3 Software Requirements Specification (SRS, 소프트웨어 요구사항 명세서)

이 Specification 행위가 끝나면 나오는 산출물이 바로 SRS이다. 이 SRS는 다음의 행위를 하기 위한 기반으로 이용된다.

* 고객과 개발자와 계약에 사용된다. 대중에게 파는 제품을 만드는 경우에는 회사의 마케팅부서와 동의를 해야 한다. 제품에서 구현 할 것과 구현하지 않을 것을 명시한다.

(***필자주석) 여기서 무엇을 구현할 것을 적는 것은 당연한데 무엇을 구현하지 않겠다는 것이 생소해 보일 지 모르나 무척이나 중요하다. 개발외주 소송의 원인의 많은 부분을 차지하는 것이 무엇을 안 하겠다는 것을 계약서에 확실히 얘기하지 않았기 때문이다. 예를 들어 우리 제품은 "한글, 영어, 중국어를 지원한다"라고 적으면 정확한 의미를 전달하지 못한다. "한글, 영어, 중국어 외에는 어떤 언어도 절대 지원하지 않는다" 라고 적어야 조금은 더 정확한 의미를 전달할 수 있다. 이 문장만 해도 아직 더 자세히 적어야 할 것이 많지만 나중에 SRS 작성법을 가르치게 되면 그 때에 설명하기로 하고 이것은 가이드인 만큼 여기서 중단한다.

* 설계가 시작되기 전에 철저한 평가를 통해 나중에 재설계가 벌어지는 일을 줄인다.

(***필자주석) 분석과 설계를 대충하고 날코딩으로 들어갈 때의 문제가 바로 재설계와 재구현이다. 잘못된 관행을 고치는 방법도 모르고 관행적으로 그렇게 하고 있는 것이 불행한 현실이다. 열심히는 일하지만 비효율적이고 품질도 낮아진다.

* 검증(Validation)과 테스트(Verification)를 위한 목적으로 사용한다.

(***필자주석) 용어의 혼동을 피하기 위해 설명하자면 Validation은 무엇을 구현할 것인가를 검증하는 것이고 Verification은 구현하기로 약속한 것을 제대로 구현했는지를 검증하는 것이다. 즉 Validation은 스펙검토이고 Verification은 테스트이다.

* 소프트웨어 제품을 고객에게 설명하는 목적으로 사용한다.

(***필자주석) 이 문장이 너무 당연한 것처럼 보일지 모르나 이 원칙을 지키면서 SRS를 작성하는 경우를 국내에서는 본 적이 없다. 구체적으로 말하자면 SRS가 완성되면 개발자들은 개발을 시작하지만 마케팅 부서는 SRS를 기반으로 카탈로그도 만들고 언론기사도 작성하고 영업활동도 준비할 수 있다. 기술문서 부서는 SRS를 보고 사용자 매뉴얼을 작성하기 시작한다. 물론 완성하기 위해서는 화면 이미지와 같이 나중에 나오는 것도 있지만 대부분의 내용은 SRS에 나와 있다. 만약 발주자인 고객이라면 SRS를 보고 자기가 원하는 제품인지를 알 수 있어야 하고 나중에 분란의 소지가 전혀 없을 정도로 자세히 적혀야 한다. 그러니까 국내에서 통상적으로 벌어지는 현상인 개발한 다음에 보고 나서 이것 저것 고쳐 달라고 하는 것은 이 꼭지의 원칙을 지키지 않은 것이다. 단 한 줄의 원칙이지만 해야 할 일로 보면 지금 하고 있는 일의 몇 배의 일을 해야 할 지 모른다.

* 마지막으로 제품 향상을 위한 기반으로 사용된다.

(***필자주석) SRS는 항상 제품이 진화함에 따라 같이 진화한다. 새 제품이 나온다고 처음부터 SRS를 다시 적는 것은 잘못된 것이다. 제품과 소스코드와 SRS는 항상 같은 버전을 최신으로 유지해야 한다.

SRS는 보통은 자연언어(Natural Language)로 적는다. 하지만 정규식(Formal)이나 준정규식(Semi-Formal)을 이용한 설명이 보충되게 된다. 아키텍처의 설명이나 어떤 특정한 내용을 자세히 쉽게 설명하기 위해 필요한 적절한 표기법의 선택이 필요하기도 하다. 특정한 표기법이 좋다 나쁘다가 아니고 일반적인 원칙은 Requirements를 정확히 표현하는 표기법을 사용하라는 것이다. 안전 요구사항(Safety Requirements)이나 법규(Regulation)와 같이 외적인 요소가 치명적일 경우에 특히 정확하게 명시할 수 있어야 한다. 하지만 표기법 선택은 직원들의 교육 유무, 보유스킬, 작성자의 선호도, 검토할 사람들의 선호도에 따라 결정되기도 한다.

SRS를 프로젝트 비용, 인수조건, 성능, 일정, 재사용성 등의 수치를 측정하는 품질 지표(Quality Indicator)가 이미 개발되어 있다. 그리고 SRS에 적히는 각 문장의 품질을 측정하는 지표에는 꼭 할 것 (Imperative), 불충분한 문장, 선택적인 문장 등의 특성이 있다. 그리고 전체 SRS 문서의 품질을 측정하는 지표에는 문서의 양, 가독성, 명시화, 깊이, 문장 구조 등이 있다.

(***필자주석) 여기에서 말하는 품질지표(Quality Indicator)는 필자가 요구공학을 가르칠 때 채점을 하기 위한 항목이기도 한데 예를 들어 가독성만 해도 관련자들이 읽어서 쉽게 이해하지 못한다면 가독성이 낮은 것이다. 작성자만 이해하는 SRS는 잘 작성된 것이 아닌 것이다. 또 불충분한 문장의 경우에는 너무 많은 잘못된 경우가 있다. "빨리", "사용자 친화적", "안정적인" 이런 용어들은 모두 다 감점이 되는 용어들이며 SRS에서는 사용하면 안 되는 용어이다. 이런 용어들은 이전 단계인 고객요구사항 문서에서는 어느 정도 허용될 수도 있지만 SRS에서는 이런 용어를 변경해서 정량적으로 정확히 명시해야 한다.

이 꼭지까지 도출, 분석, 명시(즉 SRS를 작성)하는 가이드까지 설명했지만 현실적으로 작성할 수 있는 능력이 생길 수는 없다. 일단 여기서는 SRS가 자신이 생각하고 있던 것과는 다르다는 것 정도만 인식해도 많은 도움이 된다.

6. Requirements Validation (검증) - 다음 Post에서 다룬다
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

SWEBOK - 소프트웨어 요구사항 #5

SWEBOK 해설 Software Requirements #5

(***필자주석) 이 꼭지는 "분석" 이라는 행위에 대한 설명인데 가장 핵심적인 행위인 "Specification(명시)"는 다음 꼭지에 있다. 지금까지 요구사항 도출도 하고 이 꼭지에서 분석을 한 다음에야 마지막 단계인 "Specification(명시)"를 한다. 도출, 분석, 명시란 단어가 다 비슷하게 들리는 이런 것들의 차이가 무엇인지는 사실 어느 정도 경험해 보기 전에는 이해하기가 어려울지 모른다. 진정한 이해를 위해서 경험이 있으면 좋겠지만 경험이 없어도 이해하고 행동할 수 있는 선각자들도 있으니 IEEE에서 SWEBOK을 출간했을 것이라고 믿는다. 필자는 SWEBOK을 읽으면서 그 동안의 경험을 회상하며 다시 한 번 정리를 할 수 있는 기회가 되었으니 SWEBOK의 가치를 가슴 깊이 느낀다.

SWEBOK에서도 말했지만 필자가 책이나 기사에서 수 없이 얘기한 "SRS는 기능명세서(Functional Specification)가 아니다" 라고 했음에도 불구하고 아직도 기능명세서가 SRS라고 착각하고 있는 독자들도 있다. "기능명세서는 작성할 필요가 없을지도 모르나 SRS는 꼭 작성해야 한다" 라고 말한다면 더 착각을 불러일으킬지 모르지만 나중에 SRS에 관한 것을 다 이해하고 나면 저절로 이해가 될 것이다. 하지만 지금은 이해는 가지 않더라도 앞 꼭지에서도 여러 번 설명했듯이 더 이상 착각은 하지 않았으면 하는 바램이다.

그리고 이 꼭지를 이해하기 위해서는 앞 꼭지들에서 언급한 기초적인 용어와 지식을 확실히 알고 있어야 한다. 앞 꼭지들을 소화하지 않고 이 꼭지를 이해한다는 것은 불가능하다. 아마도 실용가치 없는 표면적인 지식만 습득할 수 있을 뿐이다. 앞 꼭지들에서 소개된 많은 용어들이 나오니까 다시 한번 읽어 보는 것도 좋을 것이다. 필자도 SWEBOK을 여러 번 읽었지만 읽을 때마다 새로 느끼는 것이 있다. 그만큼 심오한 문서이다.

1장 Software Requirements (소프트웨어 요구사항)

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

2. Requirement Process (요구사항 프로세스)

3. Requirement Elicitation (요구사항 도출)

4. Requirements Analysis (요구사항 분석)


이 꼭지는 요구사항의 분석(Analysis)를 하기 위해 필요한 프로세스를 설명하며 그 목적은 다음과 같다

* 요구사항들 간에 상충되는 부분을 발견하고 조율한다.

* 소프트웨어가 어떤 조직과 어떤 운영환경에서 사용되는 지에 대한 범위를 명확히 한다.

* 소프트웨어 요구사항을 추출하기 위해 상위의 시스템 요구사항을 자세히 명시한다.

(***필자주석) 대부분의 소프트웨어는 시스템의 일부분으로 동작된다. 예를 들어 휴대폰이나 자동차 등과 같이 하드웨어를 컨트롤하는 임베디드 소프트웨어뿐만 아니라 대부분의 소프트웨어는 알게 모르게 소프트웨어가 사용되는 전체 환경 즉 시스템이 요구하는 요구사항에 따라서 소프트웨어 요구사항이 나오게 된다. 그러기 위해서는 시스템 요구사항을 먼저 정확히 도출하는 것이 필수이다.

전통적으로 요구사항 분석(Requirements Analysis)은 구조분석방법(Structured Analysis Method)과 같은 구조적인 분석을 이용한 개념모델을 만드는 것이었다. 그런 구조분석방법으로 명시하는 것도 중요하지만 그 전에 상충되는 요구사항을 먼저 조율해야 하고 조율을 위한 요구사항 협상(Requirements Negotiation)시에 각 이해관계자의 손익관계를 계산하기 쉽도록 먼저 요구사항 분류(Requirements Classification)에 대한 설명을 하기로 한다.

결론적으로 요구사항은 다음 목적을 위해서 정확히 명시되도록 모든 노력을 기울여야 한다.

- 요구사항이 검증될 수 있어야 한다
- 실현가능성이 있다는 것을 증명할 수 있어야 한다
- 비용이 얼마나 들지를 측정할 수 있어야 한다

4.1 Requirements Classification (요구사항 분류)

요구사항은 다음과 같은 여러 가지 관점에서 분류되어야 한다.

* 요구사항이 기능요구사항(Functional Requirements)인가 비기능요구사항(Nonfunctional Requirements)인가? 이에 대한 설명은 앞 꼭지 1.3에서 설명되었다.

* 요구사항이 상위 시스템에서 명시된 것인가? 혹은 출현되는 특성(Emergent Properties. Section1.4 참조)인가? 혹은 이해관계자가 직접 명시한 요구사항인가?

(***필자주석) 근본적으로 요구사항은 직접적으로 명시한 것 외에도 아무도 말하지 않았지만 암묵적으로 생겨나는 것들이 있다. 그런 것들을 놓치지 않고 찾아내어 명시하는 것이 중요하다. 만약 누가 말한 것만을 적어서 요구사항이 완성될 수 있다면 타이피스트의 역할에 불과할 것이다. 경험이 많으면 많을 수록 그런 암묵적인 요구사항을 되도록 많이 적을 수 있다.

* 요구사항이 제품의 요구사항인가? 제품을 만들기 위한 프로세스에서 요구되는 사항인가? (Section 1.2 참조). 프로세스에서 요구되는 사항의 예에는 특정한 개발자가 개발하도록 계약에서 명시할 수도 있고 소프트웨어 공학 방법론을 명시할 수도 있고 특정한 표준기법을 준수하도록 결정할 수도 있다.

(***필자주석) 실제로 UML을 사용하기로 결정했더라도 EA를 사용할 지 랩소디를 사용할 지와 같이 도구의 선호도는 다를 수가 있고 생산성에 영향을 끼친다. 혹은 java를 사용할 지 C++을 사용할지도 마찬가지이다.

* 요구사항의 우선 순위(Priority)를 정한다. 소프트웨어를 만드는 목적에 가깝게 부합할수록 우선 순위가 높다. 우선 순위를 분류하는 방법의 한 예로는 필수 사항, 매우 중요, 중요, 선택사항 등으로 분류하는 방법도 있다. 우선순위는 제품의 기능으로서의 중요성 뿐 아니라 개발비용을 고려해서 균형 있게 평가되어야 한다.

* 요구사항의 범위(Scope of requirements) - 어떤 요구사항이 영향을 미치는 범위를 의미한다. 어떤 비기능요구사항은 Global Scope로서 전체 소프트웨어에 영향을 미치고 모든 컴포넌트에서 그 사항을 고려하여야 한다. 반면에 어떤 요구사항은 일부 컴포넌트에만 영향을 미친다. Global Scope는 소프트웨어의 아키텍처에 지대한 영향을 미치고 그에 따라 모든 하위 컴포넌트의 설계가 결정된다. 반면에 부분적인 범위(Narrow Scope)의 요구사항은 소수의 컴포넌트 설계에만 영향을 미친다.

* 요구사항의 변동성과 안정성 (Volatility/Stability) - 어떤 요구사항은 소프트웨어의 생명주기가 끝날때까지 계속 변해 간다. 심지어는 개발하는 중간에도 변하는 경우도 있다. 이런 요구사항이 미래에 변동할 가능성에 대한 예측을 어느 정도 할 수 있어야 한다. 예를 들어 금융권 전산 시스템에서 "예금이자를 지급해야 한다"는 요구사항은 "어떤 금융상품이 면세상품이다"를 결정하는 것보다는 훨씬 변할 확률이 적을 것이다. 이자는 금융권의 근원적인 기반이기 때문에 변하지 않는다고 가정해도 되지만 면세인 금융상품은 정부의 정책에 따라 수시로 변할 수 있다. 이런 가정에 따라 미래의 변화를 적용할 수 있도록 컴포넌트를 미리 인식하고 설계를 유연하게 해야 한다.

요구사항 지식영역(KA)의 마지만 부분인 Section 7.3 에서 Requirements Attributes(요구사항 특성)을 다루는데 요구사항 분류와 중복되는 부분이 있으니 참조하기 바란다.


4.2 Conceptual Modeling (개념모델)

소프트웨어가 해결하려고 하는 실제 세상의 문제를 모델로 만드는 것이 요구사항 분석의 핵심이다. 개념모델의 목적은 해결하려는 문제가 무엇이고 해결책이 무엇인지를 이해하는데 도움을 주는데 있다. 이 꼭지는 Software Engineering Models and Methods 지식영역과 밀접한 관계가 있다.

다음과 같은 여러 종류의 개념 모델 방식이 사용될 수 있다.
- 유스케이스 다이어그램 (Use-case Diagram)
- 데이터 흐름도 모델(Data Flow Model),
- 상태모델(State Model),
- 목표지향 모델 (Goal-based Model),
- 사용자관계 모델(User Interaction Model),
- 객체지향 모델(Object Model),
- 데이터 모델
- 등등

이 중에 많은 모델은 UML (Unified Modeling Language) 표기법 중의 일부분이기도 하다. 특히 유스케이스 다이어그램은 통상적으로 내부의 구조와는 상관 없이 행위자(Actor, 즉 사용자일 수도 있고 외부의 시스템일 수도 있다)의 유스케이스로 시스템의 기능을 외부의 관점에서 묘사하는 것이 가능할 때 흔히 사용된다. 이런 모델링 표기법의 선택은 다음과 같은 요소를 고려하여 결정된다.

* 문제의 본질 - 어떤 소프트웨어는 엄청난 분석 작업을 요구하기도 한다. 예를 들어 SysML의 방식 중의 하나인 "상태 파라미터 모델"(State and Parametric Model)은 정보시스템(Information System) 관련 소프트웨어보다는 실시간 소프트웨어에 적합하다. 이와 정 반대되는 시스템에서는 객체(Object) 다이어그램이나 액티비티(Activity) 다이어그램이 통상적으로 사용된다.

(***필자주석) 현실에서 가장 어려운 결정은 어떤 다이어그램을 사용할 것인가 하는 결정이다. 모든 다이어그램을 작성하는 것은 가장 나쁜 결정이다. 많은 중복이 생기고 시간 낭비이기 때문이다. 이 결정은 논리보다는 경험에 의한 통찰력이 우선인 인간 고유의 영역이다. 이런 영역에서 방법론에서 열거한 모든 다이어그램을 만든다는 것은 소프트웨어 공학의 목표와는 정 반대인 최악의 결정이다.

* 소프트웨어 개발자의 전문성 - 개발자가 익숙한 모델링 표기법을 사용하는 것이 개발 생산성이 높다는 것을 고려해야 한다.

* 고객의 프로세스 요구사항 (1.2 Product and Process Requirements 참조) - 고객이 자기들이 이해하기 쉬운 표기법으로 개발하도록 요구할 수 있다. 이 요구사항은 당연히 바로 위의 개발자들이 익숙한 표기법과 상충될 수 있다.

어떤 표기법을 사용하든 소프트웨어 전체를 이해할 수 있는 콘텍스트(Context)을 묘사하는 것이 중요하다. 소프트웨어 콘텍스트는 개발하려는 소프트웨어와 그 소프트웨어가 작동되는 외부환경과의 인터페이스를 보여주는 것이 핵심이다. 이 꼭지는 어떤 특정한 표기법을 가르쳐 주는 것인 목적이 아니고 모델링의 의도와 목적에 대한 가이드를 하는 데 있다.

(***필자주석) 모델링 표기법은 UML도 계속 버전이 바뀌면서 변경되어 왔고 SysML이 나오기도 하고 계속 변화하기 때문에 어떤 특정한 표기법이 최선이라고 할 수가 없다. 위의 상황에 따라 적절한 표기법을 사용하는 것이 최선이다. 국내에서는 UML이 거의 정답으로 생각할 정도로 편중되어 있지만 다른 표기법이 더 유용하다면 그럴 필요는 없다. UML도 만능이 아니고 표현 능력에 한계가 있다. 그냥 하나의 표기법일 뿐이니 생각의 폭을 넓히기 바란다.

4.3 Architectural Design and Requirements Allocation (아키텍처 설계와 요구사항 할당)

개발의 어느 시점인가에 아키텍처가 만들어져야 한다. 요구사항 단계에서의 아키텍처 설계는 소프트웨어 설계 단계와 중복되는 부분인데 분석과 설계 단계를 깨끗하게 나눈다는 것은 현실적으로 불가능하다. 즉 아키텍처는 요구사항 분석 때 시작해서 설계 단계에서 마무리 한다. 이 꼭지는 당연히 소프트웨어 설계 지식영역과 밀접히 관련되어 있다.

소프트웨어 분석가는 소프트웨어 설계자로서의 역할도 해야 한다. 요구사항을 분석하고 상세히 명시하는 과정에서 이 요구사항들을 구현할 수 있는 아키텍처가 만들어 져야 한다. 어떤 컴포넌트에 할당된 요구사항을 만족시키기 위해 설계를 하다 보면 다른 컴포넌트와의 인터페이스를 더 자세히 추가적으로 생각하게 되고 그런 과정을 계속 지나다 보면 분석 작업의 완성도가 높아지는 결과를 얻는다.

대규모의 프로젝트에서는 이런 하나의 컴포넌트에 부과된 요구사항들에 따라 구조 설계를 하다 보면 모든 하위 시스템의 분석을 다시 되풀이하게 하는 상황을 만든다. 자동차 브레이크의 예를 들어보자. 브레이크의 요구사항에는 제동거리, 열악한 환경에서의 안전성, 부드러운 제동, 페달 압력 등이 있고 이런 요구사항들이 ABS(Antilock Braking System) 시스템에 요구된다고 하자. 이런 ABS에 대한 소프트웨어 기능과 요구사항이 정해진 다음에야 자동차의 무게와 브레이크에 사용될 하드웨어 등 파생되는 요구사항들이 결정될 수 있다.

4.4 Requirements Negotiation (요구사항 협상)

"협상"이라는 용어는 여기서는 "상충점 해결(Conflict Resolution)" 과 같다. 여러 이해관계자들 사이의 상충되는 문제를 해결하는 것을 의미한다. 상충되는 문제에는 기능요구사항, 비기능요구사항, 자원 등이 있다. 개발자가 일방적인 결정을 하는 것은 현명하지 않고 각 이해관계자들과 의논하여 동의를 구하거나 적절한 조율점을 찾아야 한다. 대부분의 경우 이런 결정들이 최종 고객이 원하는 것인지를 항상 확인하는 것이 계약상 문제를 일으키지 않기 위해 중요하다. 요구사항 분석이 진행됨에 따라 새로운 문제가 계속 발생하고 기존의 요구사항이 변하는 상황이 계속된다. 이런 변화에 따른 소프트웨어 검증에 대한 이슈도 계속 따라온다.

요구사항 우선순위 결정은 단순히 중요한 사항이 무엇인지를 인지하는 것으로써가 아니라 단계적인 출시를 할 경우에 어떤 요구사항을 포함할지를 계획하고 상충되는 문제를 미리 해결하기 위해서 사용하는 것이 중요하다. 이를 위해서는 산업 도메인 지식, 정확한 개발기간 측정역량에 기반한 복잡한 결정 역량이 필요하다. 현실에서는 이를 위한 정확한 데이터를 얻기가 어려운 것이 문제이다.

요구사항은 독립적인 것이 아니고 서로 영향을 주는 경우가 많다. 현실에서는 분석가가 모든 요구사항을 다 알지 못하는 상태에서 요구사항의 우선순위를 결정하는 잘못을 저지르기도 한다. 우선순위의 결정에는 "비용과 가치" 의 상대적인 분석을 해야 하는데 이는 모든 이해관계자에게 주는 혜택과 구현하지 않았을 때 발생하는 불이익에 대한 평가를 할 수 있어야 한다. 이는 모든 요구사항의 개발에 드는 비용을 다 분석하고 비교해야 한다는 것을 의미한다.

또 다른 우선순위 결정 방법으로는 "계층분석 프로세스" 로서 모든 기능을 2개씩 비교해서 어느 것이 얼마나 더 중요한지를 선발해 내는 방식도 있다.

(***필자주석) 여기에서 글로 설명한 것 보다 현실에서 우선순위를 정하는 것은 무척이나 어렵다. 어떤 기능을 안 만들면 다른 기능이 자동적으로 의미가 없어지는 의존적인 경우와 같이 상관관계가 복잡하게 나타난다. 비용측정도 어렵고 안 했을 때의 피해측정도 어렵고 우선순위 결정은 결국 아무리 많은 데이터를 수집하더라도 대부분은 통찰력에 의한 결정이 된다.

4.5 Formal Analysis (형태적 분석)

(***필자주석) 이 부분은 정확한 의미로 번역하기가 어렵지만 이해를 돕기 위해 미리 설명을 하자면 프로그래밍 언어와 같이 정해진 공식을 이용해서 요구사항을 표현하는 방법을 말한다. 대부분의 소프트웨어 개발의 경우는 이런 방법을 사용하지 않지만 State Machine 과 같이 특수한 경우에는 이런 방식이 유용할 수도 있다. 일단 번역은 하지만 이 꼭지는 상대적으로 덜 중요한 주제이니 가볍게 넘어가는 것을 권장한다.

형태적 분석은 후반부 꼭지인 5.3과 6.3과도 관련되어 있다. 또 다른 지식영역인 Formal Method in Software Engineering Models and Methods Knowledge Area 와도 관련되어 있다.

형태적 분석은 일체성이 높은 특수한 소프트웨어의 경우에 많은 영향을 끼쳤다. 요구사항의 형태적인 표현은 규칙을 가진 언어(Semantic Language)로 표현한다는 것을 의미한다. 그런 형태적인 표현은 두 가지 혜택이 있다. 첫째, 요구사항을 애매모호하지 않게 표현하여 잘못 이해하는 경우를 없앤다. 둘째, 논리적으로 검증하기가 쉽다. 형태적 표현은 그를 분석할 수 있는 도구를 필요로 하며 두 종류의 도구가 있다. "정리 증명기(Theorem Provers)"와 "모델 검증기(Model Checker)" 가 있다. 하지만 이런 도구조차도 100% 자동으로 검증할 수 있는 방법은 없다. 그래서 형태적 분석 방법을 유용하게 사용할 수 있는 소프트웨어는 매우 제한적이다.

그래서 형태적 분석은 요구사항 분석의 후반부에 사용하는데 초점을 둔다. 분석 초기에는 아직 비즈니스 목표나 사용자 요구사항도 정해지지 않은 상태에서 형태적 분석을 사용한다는 것은 매우 비생산적이다. 그러나 일단 모든 요구사항이 안정적으로 정해지고 상세히 설명되어 있다면 일부분의 핵심 요구사항은 형태적 분석을 사용하는 것이 좋을 수도 있다.

5. Requirements Specification (명시) - 다음 Post에서 다룬다

6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

SWEBOK - 소프트웨어 요구사항 #4

SWEBOK 해설 Software Requirements #4

1장 Software Requirements (소프트웨어 요구사항)

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

2. Requirement Process (요구사항 프로세스)

3. Requirement Elicitation (요구사항 도출)

(***필자주석) 먼저 시작하기 전에 국내의 프로젝트 발주과정의 하나인 RFP(Request For Proposal, 제안요청서)와 비교해 보자. 지금 이 요구사항 도출 단계가 지나면 말 그대로 요구사항이 도출될 것이다. 그럼 이 요구사항이 도출된 다음에 RFP가 나가야 할까 아니면 그 전에 나가야 할까? 요구사항 도출단계 전에 나가야 한다면 추상적이고 큼직큼직한 희망사항 정도 적힐 수 밖에 없다. 국내의 RFP는 대부분 이 정도 수준에 속한다. 요구사항을 도출하는 것도 많은 시간과 비용이 들기 때문에 계약을 하기 전에 그런 비용을 지불할 개발업체는 없다. 과거 유사한 프로젝트에 사용했던 문서를 하루 밤새거나 며칠 정도 걸려 수정해서 만들어 내는 경우가 대부분이다.

그러니까 결국 요구사항 도출의 행위도 계약이 끝난 다음에 하게 될 테고 그러다 보면 그 다음 단계인 Software Requirements Specification(SRS)는 계약도 이미 다 끝난 마당에 더욱 더 제대로 적을 이유도 없다. 결국 대부분의 프로젝트는 "요구사항 도출" 마저도 계약이 체결된 후이기 때문에 제대로 작성하려는 동기가 없다. 이런 상황에서 SRS가 제대로 적히길 바란다는 것은 어떻게 보면 망상이다.

그러나 전세계 개발방법론들은 기본적으로 SRS를 만드는 과정이 존재하고 계약상 제출해야 하는 의무가 있으니 제출용 문서를 작성하기는 한다. 대부분은 프로젝트가 종료되기 바로 전에 만든다. 개발에 도움이 되지 않는 문서를 제출용으로 만든다는 것은 시간낭비이고 불행한 일이다. 건물 다 지어 놓고 설계도를 만드는 것과 같다.

요구사항 도출은 요구사항의 출처가 무엇인가와 소프트웨어 엔지니어가 어떻게 요구사항을 수집하는가에 관한 주제를 다룬다. 요구사항 도출은 소프트웨어가 해결하려고 하는 문제에 대한 이해를 하기 시작하는 가장 최초 단계이다. 이것은 전적으로 인간이 하는 행위이다. 이해관계자(Stakeholder)가 인식되고 개발자와 고객과의 관계가 설정되는 단계이다. 요구사항 도출은 다른 용어로 "Requirement capture(요구사항 포착)" 혹은 "Requirement Discovery(요구사항 발견)" 혹은 "Requirement Acquisition(요구사항 수집)"이라는 용어를 사용하기도 한다. 요구사항 도출을 잘 하기 위한 가장 기본적이고 중요한 원칙은 다양한 이해관계자들 사이의 적절한 커뮤니케이션이다., 이 커뮤니케이션은 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)동안 계속된다. SDLC의 여러 단계에서 다른 종류의 이해관계자들이 관련된다. 분석책임자(Requirement Specialist)는 개발이 시작되기 전에 이 이해관계자들 사이의 커뮤니케이션 채널을 위한 연결고리를 미리 만들어 두어야 한다. 크게 도메인 전문가들과 기술 전문가들 사이의 중재를 해야 하는 것은 필수이다.

(***필자주석) 요구사항 도출은 전적으로 인간이 하는 행위라고 적혀 있다. 물론 문서편집기등 도구는 사용하겠지만 근본적으로 인간의 결정이 수시로 필요한 창조적인 영역이다. 즉 Doors와 같은 요구사항 작성도구나 표준 템플릿에다 내용만 적기만 하겠다는 생각이 얼마나 한심한 생각인지를 알 수 있을 것이다. 개발자들이 스스로의 가치를 비하하는 잘못된 생각이다.

요구사항 도출의 가장 중요한 요소는 프로젝트의 범위를 모두에게 인식시키는 것이다. 이를 위해 개발하려고 하는 소프트웨어의 목적과 기능의 우선순위를 명시하여 고객이 원하는 중요한 기능이 먼저 만족되도록 항상 명심해야 한다. 그럼으로써 분석책임자가 낮은 우선순위의 기능에 쓸데없이 시간을 낭비하거나 필요도 없는 기능을 개발하지 않도록 해야 한다. 또 다른 한편으로는 초기 단계에서는 명시되지 않는 기능들을 나중에 수용할 수 있도록 확장성 있게 요구사항들을 표현해야 한다.

(***필자주석) 나중에 여러 템플릿을 보면 알겠지만 SRS의 초반부는 소프트웨어를 왜 개발하려는 가에 관한 목적과 비지니스 전략에 관한 내용들이다. 왜 개발하는지를 알아야 무엇을 개발할 내용이 결정되는 것이다.

3.1 Requirements Sources (요구사항 출처)

요구사항은 많은 출처로부터 온다. 그런 모든 출처를 하나도 빠짐 없이 밝혀야 하고 정보를 받아야 한다. 다음과 같은 다양한 출처를 인식하고 그들을 관리해야 한다.

* Goal(목적) - 목적은 "Business Concern(사업의 관심)" 혹은 "Critical Success Factor(핵심성공요소)" 라고 하기도 하는데 상위수준의 목표를 의미한다. 그러다 보니 개발을 위한 동기부여를 하기도 하지만 애매모호하게 적히기도 한다. 소프트웨어 개발자들은 이 애매모호함 속에서 개발할 가치가 있는 것을 알아 내고 개발비용의 산정을 할 수 있게 많은 노력을 기울여야 한다. Feasibility Study(실현성조사)가 이런 결정을 하기 위해 사용하는 저렴한 방법이다.

(***필자주석) 실현성조사가 아무리 저렴하다고 해도 시간적으로 모든 기능의 실현성을 조사해 볼 수는 없는 것이 현실이다. 되도록 해보지 않고 결정할 수 있는 역량이 중요하다. 리스크관리 중의 하나가 해보지 않은 기능을 관리하는 것이다. 그래서 경험자의 통찰력이 필수이다.

* Domain Knowledge(도메인 지식) - 소프트웨어 개발자는 제품 도메인에 대한 지식을 습득하거나 가지고 있어야 한다. 도메인 지식은 요구사항이 도출되면서 전체적으로 이해되기 쉽게 도와준다.

(***필자주석) 필자의 저서에서 소프트웨어 개발자로서 도메인과 소프트웨어 기술의 비율에 대한 설명을 20:80 정도라고 했다. 도메인 전문가가 따로 있고 개발 전문가가 다르니 개발자가 도메인 전문가가 되기 위해 너무 많은 비중을 투입하는 것은 옳지 않다.

* Stakeholder(이해관계자) - 앞 꼭지에서 "Process Actor((행위자)" 라고 했었다. 많은 소프트웨어들이 불만족스럽게 만들어 진 이유가 한 그룹의 이해관계자들의 목소리를 다른 그룹을 희생하면서 들어주기 때문이었다. 그렇게 만들어진 제품은 사용하기 어렵거나 고객의 문화나 고객의 회사구조를 뒤엎어야 하는 경우가 생긴다. 그러므로 소프트웨어 개발자는 여러 이해관계자의 관점(Viewpoints)을 인식하고, 그들을 모두 대표할 수 있어야 하고, 관리해야 한다.

* Business Rules (비지니스 규칙) - 비지니스가 운영되는 규칙에 대한 내용이다. 예를 들면 대학교의 학과등록 소프트웨어를 개발한다면 "학생은 등록금을 내지 않으면 코스를 등록할 수 없다" 와 같은 규칙을 말한다.

* Operational Environment (운영환경) - 소프트웨어가 운영되는 환경으로부터도 요구사항이 도출된다. 예를 들어 실시간 시스템에서는 타이밍(Timing)에 관한 제약사항이 있을 수 있고 비지니스 영역에서는 정보처리량이나 대응시간과 같은 성능 문제가 있을 수 있다. 이 요구사항은 실현가능성의 문제가 있을 수도 있고 개발비용이나 설계 구조에 큰 영향을 미칠 수 있기 때문에 능동적으로 찾아내야 하는 중요한 정보이다.

* The Organizational Environment (조직 환경) - 소프트웨어는 비지니스 프로세스를 구현하기도 한다. 비지니스 프로세스는 고객의 회사구조, 문화, 내부정책에 따라 달라진다. 개발자는 이런 점을 민감하게 인식하고 있어야 하고 새로운 소프트웨어가 이런 고객 환경을 강제로 변경해야지만 작동할 수 있도록 만들면 안 된다.


3.2 Elicitation Techniques (도출 기법)

요구사항 출처가 모두 알려지면 소프트웨어 개발자는 요구사항 도출을 시작할 수 있다. 명심해야 할 것은 요구사항은 이미 만들어져 있어서 가서 주워오기만 하면 되는 완성품이 아니다. 대부분은 개발자가 여러 정보를 종합해서 요구사항을 조립해 내야 한다. 이 꼭지에서는 이해관계자인 인간이 요구사항에 관련된 정보를 표현하도록 유도하는 기법을 다룬다. 이것은 매우 어려운 작업이다. 개발자는 이해관계자들이 자신들이 원하는 것을 잘 표현하는 능력이 없다는 것을 잘 인지하고 있어야 한다. 그들은 중요한 사항들을 빼먹기도 하고 비협조적이기도 하고 협조할 능력 조차가 없을 수도 있다.

요구사항 도출 행위는 수동적인 행위가 아니고 심지어는 매우 협조적인 이해관계자들에게서 조차 정확한 정보를 얻어내기 위해서도 매우 열심히 일해야 한다. 많은 비지니스 정보나 기술 정보들은 암묵적 정보라서 너무 당연해 보이기 때문에 얘기를 해주지 않는다. 혹은 고객으로부터 제품을 주고 피드백을 얻기 전까지는 알 수 없는 정보도 많다. 그러므로 요구사항 도출을 위한 사전계획, 확인과 검증은 매우 중요하다. 많은 도출 기법들이 존재하는데 다음과 같은 방법들이 있다.

* 인터뷰 - 가장 전통적인 방법인 이해관계자들과의 인터뷰인데 장점과 단점이 있다는 것을 이해하고 인터뷰를 어떻게 진행할 지를 잘 계획하고 있어야 한다.

* 시나리오 작성 - 시나리오는 요구사항에 대한 전후 사정과 전체 맥락을 이해하는데 좋은 방법이다. 이 방법은 개발자들이 "혹시 이런 경우라면" 이나 "이렇게 되는 건가요" 와 같은 질문을 던지고 확인할 수 있게 도와준다. 가장 통상적인 방법은 유스케이스(Use Case) 를 이용한 표현방식이다. 요즈음에는 이 방식이 가장 많이 사용되고 있다.

* 프로토타입 - 이 방식은 애매모호함을 없애는 가장 좋은 방법이다. 여러가지 방법이 있는데 종이에다가 화면 시나리오를 그린 Paper Mockup(종이 모형)도 있고, 베타 버전을 사용할 수도 있고 여러가지 방법을 여러 단계에서 적절히 중복해서 사용할 수도 있다. 통상적으로 너무 자세하지 않게 대충 만든 모델 (Low Fidelity Model)을 사용하는 것이 좋다. 그 이유는 너무 자세하게 적어서 유연성을 없애고 설계에 제약이 가해지는 경우가 있다.

(***필자주석) UI에서 너무 자세하게 명시함으로서 설계나 구현 방식을 몇 배 어렵게 만드는 경우를 자주 보았다. 중요한 것은 사용자가 편하고 목적을 성취하면 되는 것이지 구체적인 방법을 미리 명시할 필요는 없다. 구현방법은 개발자에게 자유롭게 맡겨놓음으로써 개발의 효율성을 높이고 비용과 일정을 절감할 수 있다.

* 그룹 회의(Facilitated Meeting) - 이 회의의 목적은 종합적인 내용을 정하는 것이다. 한 개인이 정할 수 없는 경우에 여러 명의 이해관계자들이 모여서 좋은 의견을 낼 수 있다. 또 중요한 것은 상충되는 요구사항들이 이 방법으로 모든 이해관계자들에게 초기에 노출되도록 하는 것이다. 이 방법이 잘 이용되면 일관성 있고 깊이 있는 여러 요구사항들의 집합이 도출되는 것도 장점이다. 하지만 그룹회의는 중재자의 지휘아래 매우 조심스럽게 진행되어야 한다. 목소리 큰 그룹이나 직위가 높은 이해관계자의 주장이 받아들여지고 다른 이해관계자는 무시될 수가 있는 것이 조심해야 할 사항이다.

* 관찰 (Observation) - 실제 운영환경에서 소프트웨어를 어떻게 사용하고 주위의 어떤 자원과 교류하고 소통하는지를 개발자가 옆에서 구경하면서 관찰하는 기법이다. 이 방식은 비용이 많이 드는 반면에 말로 설명하기 어렵거나 보기 전에는 감지하기 어려운 비지니스 프로세스 등을 알아내는 데는 효과적이다.

* 사용자 이야기 (User Stories) - 이 방식은 애자일 방법론과 같이 단계적인 개발 방법론에서 많이 사용된다. 주로 사용자 수준의 상위 요구사항을 간단하게 고객의 용어를 이용하여 설명한다. 통상적인 문장은 "이런 "역할" 로 이런 "혜택"을 얻기 위해 "무엇"을 하기 원한다." 와 같은 방식으로 적힌다. 사용자 이야기는 개발자가 개발하는 비용을 측정할 수 있을 만큼만 최소한의 정보만을 적는 것이 좋다. 잘못 사용되면 너무 많은 자세한 정보를 초기 단계에서 받고 나서 나중에 쓸모 없이 되거나 수정해야 하는 경우이다. 이 방법은 도출 초기 단계에 사용하는 것이고 구현단계에 가기 전에는 자세한 수준의 내용이 적혀져야 한다.

* 나머지 기법들 - 다른 많은 기법들이 존재한다. 경쟁사 제품 분석도 있고 데이터 마이닝 기법도 있고 고객이 요청한 기능목록 등 다양한 출처가 있을 수 있다.

(***필자주석) 위에서 나열한 여러 방법들을 이용하여 요구사항을 도출했다고 하자. 이 시점에서 저지르는 가장 빈번하고 치명적인 실수는 이제 코딩을 시작할 만큼 내용을 안다 라고 착각하는 것이다. 실제로 여기서 도출한 내용을 버젓이 SRS라고 부르기도 한다는 것이다. 혹은 기능명세서 또는 요구사항 명세서라고 부리기도 한다. 큰 착각이다. 절대 SRS가 아니다. SRS를 작성하려면 지금까지 작성한 문서 양의 몇 배를 작성해야 한다. 아마 10배의 양을 작성해야 할지도 모른다. 이제 시작에 불과한데 마치 끝났다고 착각할 수 있는 것을 조심해야 한다.

4. Requirements Analysis (분석) - 다음 Post에서 다룬다
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

SWEBOK - 소프트웨어 요구사항 #3

SWEBOK 해설 -  Software Requirements #3

1장 Software Requirements (소프트웨어 요구사항)

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

2. Requirement Process (요구사항 프로세스)

(***필자주석) 이 블로그를 가끔 가다 읽는 독자를 위해 이 쯤에서 다시 한번 Software Requirements Specification (SRS)라는 용어를 살펴보자. SRS는 Software Requirements를 Specify 한 문서이다. 즉 Requirements와 Specification이 다르다는 것을 의미한다. 달라도 엄청 다르다. 양적으로 10배 100배의 차이가 나기도 한다. 하여튼 일단은 Requirements를 잘 수집해야 Specification을 잘 적을 수 있다는 것은 상식적이다. 이 꼭지는 Requirements 프로세스에 대한 주제를 다룬다. 아직까지 Specification에 관한 내용은 전혀 다루지 않았다. Specification은 Requirements를 도출한 다음에 다른 꼭지에서 다루게 된다.

독자들이 만약에 이 꼭지가 잘 이해가 안되거나 한다면 전혀 걱정하지 말고 그냥 넘어가라고 하고 싶다. 프로세스에 관련된 영역은 사실 꽤 높은 수준에 오른 사람들이 효율적으로 운영할 수 있는 영역이다. 이해를 하더라도 실행을 하기는 어려운 영역이다.

이 토픽에서는 "1장 소프트웨어 요구사항" 의 나머지 5개 토픽에 대한 소개와 요구사항 프로세스가 전체 소프트웨어 공학 프로세스와 어떻게 연관되어 돌아가는 지를 보여준다.

2.1 Process Model (프로세스 모델)

프로세스 모델은 요구사항 프로세스에 대한 다음 3가지 특성을 이해하도록 돕는다.

• 1. 요구사항 프로세스는 소프트웨어 생명주기의 앞 쪽에만 존재하는 분리된 단계가 아니다. 대신 프로젝트의 출발과 함께 시작되어서 생명주기가 끝날 때까지 계속 수정되면서 정제되는 행위이다.


• 2. 요구사항은 버전관리되어야 하는 형상의 하나로서 소프트웨어 생명주기의 모든 단계에서 나오는 다른 산출물(형상)과 마찬가지로 똑같은 방식으로 관리되어야 한다.


• 3. 회사와 프로젝트의 종류에 따라 다르게 적용되어야 한다.

(***필자주석) 여기에 매우 심오한 문장이 들어 있다. 1번에서 생명주기가 끝날 때까지 계속 수정된다는 얘기인데 이 말을 잘못 이해하면 그야말로 주먹구구식으로 개발하면서 SWEBOK을 따라 했다고 우겨댈 수 있는 위험한 문장이다. 이 말은 폭포수 모델(Waterfall Model)을 극단적으로 해석해서 한 번 적으면 절대로 변하지 않는다는 극단론자들에 대한 조언 정도로 받아들이면 될 것이다. 즉 한 번 적힌 요구사항은 변하지 않는다는 이상적인 폭포수 모델은 이 세상에 존재하지 않는다고 보는 것이 옳다. 그렇더라도 국내에서는 "요구사항은 절대 변하면 안 된다" 라고 해석하는 것이 옳다. 국내에서 그런 기준에서 수행해도 실리콘밸리에서 "자주 변할 수 있다" 라는 기준에서 작성할 때보다도 더 많은 양이 변하게 될 것이다. "변한다" 는 문장에서 국내와 실리콘밸리의 기준이 다르기 때문이다. "SWEBOK에서 요구사항이 변경될 수 있다고 했다" 라고 주장한다면 국내에서는 작성하다 만 문서가 난무할 것이고 소프트웨어공학과는 전혀 상관없는 행위가 될 것이다.

2번은 형상관리라는 용어를 소스코드의 버전관리 정도의 좁은 의미로 잘못 사용하는 경우를 국내에서 많이 봤는데 형상은 이 세상의 모든 실체는 형상이다. 여기서는 요구사항 한개 한개가 형상이고 소스코드는 파일 하나 하나가 형상이고 테스트 케이스도 형상이고 SRS 문서 전체도 하나로서의 형상이다. 이런 모든 형상은 베이스라인이라고 하는 어떤 기준선에 따라서 독립된 세트로 관리를 하는 것이 형상관리이다. 나중에 형상관리 KA 꼭지에서 나오겠지만 형상관리도 다 한다고 하지만 진정으로 정교하게 형상관리를 하는 회사는 국내에서 대기업을 포함해서 거의 볼 수 없었다.

3번은 필자에게 가장 많이 들어오는 요청인 "샘플과 템플릿을 보여주세요" 라는 말이 왜 별로 도움이 안 되는 지를 말해주는 문장이다. 어떤 사람이 시금치를 먹고 건강해 졌다고 내가 따라 하면 안 된다. 원칙에 따라 내 몸에 맞게 적용해야 하는 것이 소프트웨어 공학의 기본이고 모든 템플릿은 시작일 뿐이고 원칙을 이해 못한 상태에서는 피해만 준다. 샘플 역시 마찬가지이다. 건강의 원칙을 모르는 상태에서 시금치를 먹는 것은 득보다는 실이 많을 것이다. 더 이상 필자에게 템플릿이나 샘플을 달라는 요청이 없는 시대가 빨리 오기를 기대해 본다. 어차피 템플릿은 인터넷에 많고 다 동일한 내용을 포함하고 있다.

요구사항의 후반부 꼭지인 Elicitation(도출), Analysis (분석), Specification (명시), Validation (검증)에 있어서 프로젝트의 중요에 따라 모두 다른 모양으로 설정되고 수행된다. 또 마케팅 부서의 요구사항이나 구현가능성에 대한 정보를 요구사항 프로세스에 제공한다.

(***필자주석) 필자가 가장 많이 받는 질문 중의 하나가 "코딩을 해 보기 전에는 기능이 가능한 건지 알 수가 없다" 이다 . 이럴 때는 먼저 프로토타입을 만들어 보는 것이다. 그렇다고 모든 것을 만들어 보면 절대 안 된다. 경영자가 빨리 결정하기 위해서는 일단 그럴 시간이 없다. 결국 심각한 기능의 경우에는 미리 검증해 볼 수도 있지만 프로젝트는 어느 정도의 리스크를 가지고 시작할 수 밖에 없는 것이 현실이다. 그래서 리스크관리가 프로젝트 관리에서 필수적인 행위이다. 사실이 이런데도 프로젝트를 수행하면서 리스크관리를 전혀 하지 않는 경우도 많이 보았다. 리스크는 어느 프로젝트이든 존재하는데 존재자체를 인지하지 못하고 있다는 것은 리스크가 매우 크다는 것을 의미한다.

2.2 Process Actors (프로세스 행위자)
행위자는 요구사항 프로세스에 참여하는 모든 이해관계자들이다. 이 프로세스는 근본적으로 상호규제적인 특성을 가진 프로세스이기 때문에 이해관계자(Stakeholder)들과 소프트웨어 개발자들 사이에 조율을 필요로 한다. 요구사항 분석전문가(Requirements Specialist) 뿐만이 아니라 관련하는 많은 사람들이 소프트웨어에 대해 작건 크건 어떤 부분에 대해 주장할 권리가 있다. 이런 이해관계자들의 종류는 프로젝트에 따라 다르지만 사용자와 고객(사용자와 항상 같지 않음)은 항상 포함된다. 일반적으로 다음과 같은 이해관계자들이 있다.

• 1. Users (사용자) - 소프트웨어를 직접 사용하는 그룹인데 그 중에서도 다양한 역할이 있다.


• 2. Customers (고객) - 소프트웨어의 개발을 요청하거나 타겟 시장을 대표하는 사람들이다.


• 3. Market Analysts (시장분석가) - 일반 다수 대중을 목표로 하는 시장에서는 요청하는 고객이 없고 회사의 마케팅 조직이 고객을 대신해서 시장의 요구를 만들어 낸다


• 4. Regulators (규제기관) - 금융이나 대중교통과 같은 분야의 소프트웨어는 규제의 대상이 되고 규제기관의 요구를 준수해야 한다.


• 5. Software Engineers (개발자) - 개발자들은 당연히 소프트웨어를 효율적으로 개발하기 위해 과거의 컴포넌트를 재사용한다든지 하는 효율성의 이해관계가 있다. 어떤 프로젝트의 경우에는 개발자들의 재사용 요구사항이 다른 고객의 요구사항들보다 더 비중이 클 수도 있다. 또 어떤 특수한 요구사항의 경우에는 개발자들의 기술력에 따라 개발비용이나 출시일정에 큰 영향을 줄 수도 있다. 이런 모든 다양한 요구사항이 식별되어야 한다.

모든 이해관계자들의 요구사항을 만족시키는 것은 불가능하다. 그렇기 때문에 이들 사이에서 조율을 해야 하는 것이 개발자의 역할이다. 예산, 기술력, 정부규제등 모든 제약조건 아래서 모든 핵심 이해관계자들 에게 수용 가능한 균형 잡힌 결론을 이끌어 내야 하는 것이다. 이를 위한 전제 조건은 모든 이해관계자가 식별되어야 하고 각 이해 관계자들의 "관심이해사항"이 분석되어야 하고 그에 따른 요구사항이 도출되어야 한다.

(***필자주석) SWEBOK 저자들은 "모든 이해관계자들의 요구사항을 만족시키는 것은 불가능하다" 라는 문장에서 "will not be possible" 이라고 했다. 가능한 경우가 있다면 "may not be possible" 이라고 해야 할 텐데 모든 이해관계자들이 모두 만족하는 경우는 없다는 것을 의미하고 필자의 경험으로 봐서도 100% 공감한다. 필자의 책에서도 말했듯이 "모든 고객을 만족시키려고 하는 것은 100% 실패하는 방법이다" 라고 빌 크로스비도 말했다. 상용제품의 경우에는 모든 사람들을 만족시키겠다는 그럴듯한 패러다임에 현혹되어 프로젝트가 진행이 안 되는 경우를 많이 보았다. 반대로 SI 프로젝트의 경우에는 절대 양보하지 않는 상충되는 두 이해관계자들 사이에서 조율에 어려움을 겪는 경우도 많이 보았다. 다 자기 욕심을 조금도 버리지 않으려고 하다가 모두가 손해 보는 시나리오로 가는 경우이다.

하지만 말이 쉽지 조율이라는 것이 보통 어려운 일이 아니고 책으로 가르칠 수 있는 것도 아니고 경험이 필요한 진정한 소프트웨어 공학의 영역이다. 그래서 분석작업, 즉 Software Requirements Specification을 작성하는 일이 어려운 것이고 가장 최고의 개발자만이 할 수 있는 일이다.

이런 어려운 일을 템플릿이나 채우면 된다고 생각한다면 망상에 불과하다.

2.3 Process Support and Management (프로세스 지원과 관리)
이 토픽은 요구사항 프로세스에 필요한 자원의 관리에 대한 영역이다. 프로세스에서 벌어지는 활동과 비용, 인적자원, 교육, 도구와의 연결고리를 만드는 것이 목표이다.

(***필자주석) 역시 간략하게 표현했지만 관리영역인 만큼 행위와 자원을 적절히 연결하고 관리해야 한다. 관리가 어렵다기 보다는 무엇을 관리해야 할지를 도출하는 것이 훨씬 더 어려운 영역이다. 즉 무슨 도구를 사용해야 할 지, 누가 SRS를 작성할 지 등을 결정하는 것부터 시작해서 인간이 결정해야 하는 많은 사항들이 있다.

2.4 Process Quality and Improvement (프로세스 품질과 개선)

이 토픽은 요구사항 프로세스의 품질과 개선에 대한 측정이다. 즉 소프트웨어 개발 비용과 기간 그리고 고객의 만족도의 관점에서 요구사항 프로세스가 해야 하는 핵심 역할을 강조 한다. 프로세스 품질과 개선에 도움이 되게 처음부터 방향을 정해준다. 프로세스 품질과 개선은 뒤에 나오는 Software Quality KA(소프트웨어 품질 지식영역)와 Software Engineering Process(소프트웨어 공학 프로세스)와 밀접하게 연관되어 있다. 다음과 같은 주제를 다룬다.

• - 프로세스 개선과 표준 모델에 제안하는 요구사항 프로세스 적용범위


• - 요구사항 프로세스의 측정과 벤치마킹


• - 개선 계획과 수행


• - 보안관련 개선 계획과 수행

(***필자주석) 프로세스라는 용어가 기본적으로 매우 추상적인 용어라서 구체화 하기 전에는 경험자가 아니면 상상하기가 어렵다. 프로세스 개선이라고 하는 행위는 CMMI나 SPICE와 같이 한국 업체들이 한 때 열심히 적용하려고 했던 분야이다. 프로세스에 관한 수행은 먼저 프로세스의 각 단계에 해당되는 행위를 충분히 수행할 수 있는 수준이 되었을 때 전체적인 프로세스를 개선한다든지 하는 의미가 있다. 각 단계도 제대로 못하는 상황에서는 프로세스가 도움보다는 피해를 준다. SWEBOK의 저자들은 독자들이 어느 정도 수준에 있다고 가정하고 프로세스에 대한 토픽을 얘기할 지 모르나 필자가 보는 국내 소프트웨어 회사에서는 먼저 SRS를 어느 정도 작성할 수 있는 능력이 있고 나서 프로세스에 대한 고려를 해보는 것이 좋다.

즉 내용이 중요한가 프로세스가 중요한가에 대한 이슈인데 예를 들면 음식을 만들지도 못하는데 담을 그릇을 걱정할 필요는 없다. 요리학원도 다니고 음식을 만들 수 있는 상태가 되면 음식에 맞는 그릇을 사면 된다. 그런 면에서 SWEBOK은 각 수준의 사람들이 각 수준에서 이해할 수 있는 용어들이 있고 또 받아드려야 하는 행위들이 있다. 수준이 향상됨에 따라 다시 읽게 되면 공감하는 부분이 계속 있을 것이다.

3. Requirement Elicitation (요구사항 도출) - 다음 Post에서 다룬다

4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

SWEBOK - 소프트웨어 요구사항 #2

SWEBOK 해설 -  Software Requirements #2

1장 Software Requirements (소프트웨어 요구사항)

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

1.1 Definition of a Software Requirements (소프트웨어 요구사항의 정의)


기본적으로 Software Requirements는 현실에서 어떤 문제를 해결하기 위해 묘사되는 특성(Property)이다. 해결하려고 하는 문제는 기업의 비지니스 프로세스일 수도 있고, 기존 제품의 개선일 수도 있고, 기구의 컨트롤 시스템일 수도 있고 수 많은 문제들이 있다. 인간 사용자나 비지니스 프로세스나 기구나 대체적으로 동작하는 방식은 복잡하다. 요구사항이라는 것은 소프트웨어가 동작하는 방식에 연관되어 있는 다양한 수준의 사람들이 요구하는 모든 기능들이 고려되는 복잡한 집합체이다.

(***필자주석) 모든 이해관계자들이 요구하는 기능을 다 집어넣는 다는 것은 가장 나쁜 요구사항 작성법이다. 바로 Kitchen Sink라고 말하는 쓰레기 통이다. 요구사항 작성이 어려운 것은 이 모든 이해 관계자들을 조율해서 가장 현실적인 제품을 만들어 내는 것이다.

Software Requirements의 필연적인 특성은 기능으로서나 혹은 시스템에 부과되는 비기능요구사항으로서나 각각 하나씩 독립적으로 검증될 수 있어야 한다는 것이다. 이런 검증은 매우 어렵거나 많은 비용이 들 가능성이 있다. 예를 들어 Call Center의 요구사항을 테스트하기 위해서는 시뮬레이션 프로그램을 개발해야 할지도 모른다. 소프트웨어 요구사항 작성자나 테스트계획이나 품질검증부서는 현실적으로 가능한 자원의 한도 내에서 모든 요구사항이 검증될 수 있다는 것을 보장해야 한다.



또 요구사항은 제한적인 자원과 프로젝트의 트레이드오프를 선택할 수 있도록 우선순위를 명시해야 하는 특성을 가지고 있다.

(***필자주석) 요구사항 작성시 우선순위의 명시는 필수이다. 보통 저지르는 실수는 전부 다 중요하다고 적은 것이다. 그렇게 하려면 적을 필요도 없다. 항상 일정과 자원과 기능의 상충되는 목표를 조율하기 위해서는 모든 기능의 우선순위를 적절히 배분해서 명시해야 한다. 그래서 여러 이해관계자들 사이에서 조율이 필요하다. Kitchen Sink는 최악의 요구사항이라는 것을 인식해 놓기 바란다. 버릴 고객은 과감히 버려야 한다.

1.2 Product and Process Requirements (제품요구사항과 프로세스 요구사항)



제품요구사항은 개발하려고 하는 소프트웨어 제품의 기능이나 제약에 관한 것이다. 반면에 프로세스 요구사항은 소프트웨어를 개발하는 과정에서 부과되는 제약사항들이다. 예를 들어 "이 소프트웨어는 RUP 프로세스 방식을 이용해서 개발할 것이다" 와 같은 것들이다. 혹은 Java를 이용한다와 같은 것들이다.



어떤 소프트웨어는 암묵적인 프로세스 요구사항을 가지고 있다. 예를 들어 테스팅의 경우 특수한 테스팅 기계가 필요할 수도 있고 국방부 프로젝트와 같이 공식적인 문서작성 방식을 따라야 하는 경우도 있다. 프로세스 요구사항은 개발조직에서 자체적으로 설정할 수도 있고, 고객이 설정할 수도 있고  안전검증기관과 같이 국가기관에서 설정할 수도 있듯이 다양한 요구자가 있다.



1.3 Functional and Nonfunctional Requirements (기능요구사항과 비기능요구사항)



기능요구사항은 소프트웨어가 실행하는 기능(Function)을 묘사한다. 보통 기능(Capability) 혹은 특성(Feature) 이라고 알려져 있다. 테스팅 관점에서는 제품 동작을 검증하기 위해서 유한한 테스팅 단계에 의해 검증이 가능한 단위를 의미한다.

(***필자주석) 테스트 케이스의 설명으로 요구사항을 정의할 수 있다는 것이 바로 Agile 방법론 중의 하나이다. 어차피 요구사항과 테스트 케이스가 일대일 매핑이 가능하다면 같은 기능을 두 번 명시하는 것은 중복이라고 할 수 있다. 즉 테스트의 자세한 설명으로 내가 무엇을 개발할지 확실히 알 수 있는 제품이라면 당연히 요구사항을 추가로 적을 필요는 없다. 하지만 그런 제품은 많지 않다는 것이다. 예를 들어 사용자의 관점에서 테스트를 할 수 있는 홈페이지 같은 것들은 숨어있는 로직이 별로 없기 때문에 테스트 케이스를 작성하나 요구사항을 작성하나 큰 차이가 없다. 이럴 경우는 선택의 문제라고 할 수 있다. 정상적인 경우는 요구사항은 요구사항 방식으로 적는 것이 99%의 경우에 해당한다고 보면 된다. 또 요구사항 대신에 테스트 케이스를 적는다고 하더라도 요구사항 작성역량이 있는 상태에서 결정하는 것이 옳다. 기본도 되어 있지 않은 상태에서 테스트 케이스로 요구사항을 대신한다는 것은 매우 위험한 일이다.

비기능요구사항은 제품에 기능 외에 제약사항이 있다는 것을 의미한다. 용어로는 제약요구사항 (Constraint Requirements) 혹은 특성요구사항 (Quality Requirements)이라고 한다. 더 자세하게 나누면 성능요구사항 (Performance Requirements), 유지보수요구사항 (Maintainability Requirements), 안전요구사항(Safety Requirements), 상호운영성성요구사항 (Interoperability Requirements) 등 많은 비기능적인 요구사항들을 의미한다.

(***필자주석)  현실적으로 이 비기능요구사항이 기능요구사항에 비해 작성하기 훨씬 어려운 부분이다. 난이도로 볼 때 10배 이상 어렵다고 볼 수 있다. 그만큼 기능요구사항을 적을 때 보다 훨씬 더 많은 경험이 필요한 분야이다. 템플릿에도 자세한 설명이 나와 있지도 않고 가르쳐 줄 수도 없다. 원칙을 이해하고 상상력을 동원해 적어야 하는 부분이다. 제품의 심각한 문제는 주로 이 비기능요구사항의 부족함에서 생긴다. 소프트웨어 개발에서의 큰 소송은 발주자와 개발자의 커뮤니케이션의 오해에서 생기는데 기능요구사항보다는 비기능요구사항에서 문제가 될 확률이 훨씬 높다. 이 문제는 교육이나 강의로 가르쳐 줄 수 있는 문제가 아니고 같이 일하면서 경험을 쌓으면서 커가는 역량이다.

1.4 Emergent Properties (출현특성)
이 특성은 어느 하나의 컴포넌트에서 나오는 요구사항이 아닌 여러 개의 컴포넌트의 상호작용에 의해 출현되는 요구사항이다. 예를 들어 Call Center에서 얼마나 많은 전화를 응대할 수 있는가 하는 것은 전화 중계기, 전산 시스템, 그리고 전화응대 직원이 현실 상황에서 어떻게 상호작용하는 것에 의해서 결정된다. 이 출현특성은 시스템 아키텍처에서 매우 중요하게 고려되는 요소이다.

(***필자주석) 순수 소프트웨어만을 개발하는 경우라면 소프트웨어 아키텍처만 걱정하면 되겠지만 많은 소프트웨어는 하드웨어 시스템과 같이 연관되어 있다. 그게 소프트웨어 역사에서의 최초 사용도이기도 했다. 바로 임베디드 시스템이다. 그러므로 소프트웨어 요구사항을 작성한다고 하면 많은 경우에 시스템 요구사항과 시스템 아키텍처가 상위수준에서 우선적으로 명시되게 되어 있다. 앞으로도 이 차이점에 대해 뒷부분 여기저기서 나오겠지만 일단은 생각하는 방식과 작성하는 방식은 하드웨어나 소프트웨어나 동일하다는 것을 인식해 놓기 바란다.

1.5 Quantifiable Requirements (정량적인 요구사항)



소프트웨어 요구사항은 명확하게 (Clearly) 그리고 애매모호하지 않게(Unambiguously) 명시되어야 한다. 그리고 가능한 한 정량적으로 명시되어야 한다. "대충" 그리고 "검증할 수 없게" 적는 것은 피해야 한다. 사람마다 다르게 해석되는 대표적인 용어의 예가 "신뢰할 만한" 그리고 "사용자에게 친숙한" 과 같은 용어이다. 정량적인 요구사항은 특히 비기능요구사항의 경우에 중요하다. Call Center의 경우에 정량적으로 비기능요구사항을  명시한 예를 보면 "시간당 처리량(Throughput)이 현재보다 20% 증가해야 하고 치명적인 오류는 시간당 1 * 10**(-8) 보다 작게 발생해야 한다"이다. 이 상위수준의 정량적 요구사항에 따라서 하위 컴포넌트에게 많은 자세한 요구사항이 생겨날테고 또 시스템 어키텍처에 많은 제약을 가하게 될 것이다.

(***필자주석) 정량적으로 적는다는 것이 생각보다는 훨씬 어렵다. 잘 적을 수 있다면 이미 글로벌 분석가 수준이다. 대부분의 초보자들의 핑계는 해보지 않고 어떻게 숫자를 얘기할 수 있느냐고 한다. 해보지 않고도 알 수 있는 방법은 과거의 경험으로 유추하거나 현재의 환경에서 미래를 시뮬레이션 해서 상상해야 하는 매우 어려운 지식산업의 영역이다. 그리고 통찰력도 필요하다. 이 부분을 잘 명시할 수 없다면 외국에서는 계약이 성립되지도 않거니와 운이 좋아 계약을 했다고 해도 100% 소송의 대상이다. 계약의 기쁨이 악몽으로 변하는 지름길이기도 하다. 국내 소프트웨어 SI 업체와의  계약을 보면 이 부분이 매우 취약하다.

1.6 System Requirements and Software Requirements (시스템요구사항과 소프트웨어요구사항)



"시스템"은 International Council on Software and Systems Engineering(INCOSE)에서 다음과 같이 정의된다.



시스템은 원하는 목적을 위해 상호작용해야 하는 모든 요소들의 집합이다. 즉 하드웨어, 소프트웨어, 펌웨어, 사람, 데이터 정보, 조작기술, 시설, 서비스 등 모든 지원시설이다.



시스템요구사항은 시스템 전체에게 부과되는 요구사항이다. 소프트웨어를 포함하는 시스템에서는 당연히 시스템요구사항으로부터 소프트웨어요구사항이 파생되어 나오게 된다. 한편으로는 사용자요구사항(User Requirements)은 고객이나 최종 사용자의 입장에서 정의된다. 반면에 시스템요구사항은 사용자요구사항과 같이 사용자의 관점에서만 본 시스템이 아닌 정부의 규제 조항이나 안전요구사항과 같은 모든 요구사항을 의미한다.

(***필자주석) 시스템요구사항과 소프트웨어 요구사항은 앞으로도 계속 혼란을 가져오는 이슈이므로 조금이라도 빨리 확실한 이해를 해 두는 것이 중요하다. 근본적으로 생각하는 방식은 같지만 생각할 대상이 시스템에서는 광범위하므로 소프트웨어 만의 경험으로는 작성하기 어려운 것은 사실이다. 산업 도메인 지식도 있어야 하고 하드웨어나 경우에 따라 펌웨어에 대한 기본 이해는 하고 있어야 한다.

2. Requirement Process (요구사항 프로세스) - 다음 Post에서 다룬다

SWEBOK - 소프트웨어 요구사항 #1

SWEBOK 해설 - Software Requirements #1



1장 Software Requirements (소프트웨어 요구사항)

(*** 필자주석) "Requirements"를 "요구사항"이라고 편의상 번역해 놓았으나 국내에서는 고객 요구사항, 기능명세서, 요구사항 명세서등 다양한 이름으로 잘못 번역되어 있기 때문에 필자는 기존의 잘못된 이해에 대한 혼란을 피하기 위한 유일한 방법으로 앞으로 계속해서 "Requirement"로 표현한다. 국내에서 시용하는 대부분의 문서와는 100% 일치하지 않으니 기존에 알고 있던 문서와 매칭시키려는 노력은 이 연재가 끝나기 전까지는 당분간 보류하기 바란다. 나중에 전체를 이해하고 나면 국내의 모든 문서가 어느 위치에 있고 다른 방법론의 어떤 문서와 매치되는지를 알 수 있으나 지금으로서는 혼란만 일으키니 지금까지 알고 있던 문서는 당분간 머리 속에서 지워버리자.

소개



소프트웨어 요구사항 지식영역은 소프트웨어 전체 생명주기에서 다음 주제를 다룬다.



* Elicitation(도출)

* Analysis (분석)

* Specification (명시)

* Validation (검증)

* Management (관리)



Requirements와 관련된 활동이 제대로 수행되지 않는다면 소프트웨어 프로젝트는 매우 위태롭다고 이론가들이나 실무자들 모두에게 인식되고 있다.

(***필자주석) 이 문장은 이론가들이라면 수도 없이 들어 보고 주장하는 문장이지만 실제로 위태로운 정도를 상상하기가 어렵다. 하지만 필자의 30년 경험상 학교숙제나 간단한 스마트폰 앱을 개발할때도 Requirements 활동을 하지 않으면 구현을 시작하지 않을 정도로 위태로움을 느낀다. 하지만 초보자들에게 아무리 위태롭다고 해야 그 심각성을 이해시키기는 불가능하다. 바로 "칩 히스"가 "스틱" 이라는 베스트셀러에서 얘기한 "지식의 저주"이다. 초등학생들에게 공부를 잘하라고 아무리 얘기한들 그 중요성을 깨달을 수는 없다. 하지만 세계 최고의 소프트웨어 실무 전문가인 수백 명의 저자들이나 30년을 실리콘밸리의 글로벌회사부터 벤처기업까지에서 일했던 필자가 그 심각성을 주장한다면 다시 한 번 고려하는 것이 좋을 것이다.

Software Requirements는 현실의 문제를 해결하기 위한 소프트웨어 제품의 필요기능과 제한사항을 표현한다. 한편으로 "Requirements Engineering" 이라는 용어는 Requirements의 체계적인 관리라고 정의되어 있다. 하지만 이 "Requirements 지식영역"에서는 용어의 혼란을 피하고 일관성을 위해서 "Software Engineering"을 의미하는 경우가 아니고는 "Engineering" 이라는 용어를 여기서는 사용하지 않는다. 같은 이유로 시중의 다른 문서들에서 사용되는 "Requirements Engineer" 라는 용어도 여기서는 사용하지 않는다.

그 대신 Requirements를 수행하는 사람들을 "Software Engineer" 혹은 "Requirements Specialist" 라는 용어를 사용하기로 한다. Requirements Specialist는 일반적으로  Software Engineer가 아닌 사람들이 분석작업을 할 경우 붙이는 용어이지만 그렇다고 Software Engineer가 분석 작업을 할 수 없다는 것은 아니다. 즉 Software Engineer이든 개발자가 아닌 Requirements Specialist이건  둘 다 분석 작업을 할 수 있다.

(*** 필자주석) 여기서 저자들이 "소프트웨어 공학"이라는 용어로 잘못 유도되는 잘못을 피하기 위해 아예 공학이라는 말을 사용하지 않겠다는 것이다. 필자도 "소프트웨어 공학" 이라는 용어를 사용하는 것을 극단적으로 피한다. 실무 경험이 없으면서 이론적으로 "소프트웨어 공학" 을 안다고 하는 것이 어불성설인데 그런 이론가들과 필자와의 차이를 두기 위해서이다. 필자는 실리콘밸리에서 자란 실무전문가이지 소프트웨어 공학 이론가는 아닌 것이다.

하여튼 "공학" 이라는 말이 많은 혼란을 일으키고 공학이라는 이름 아래 선 무당들이 국내 소프트웨어를 잘못 이끌어 가는 것을 피하기 위해서는 공학의 진정한 의미를 깨닫기 전에는 일단 공학이라는 단어를 사용하지 않겠다는 저자들의 말에 필자도 전적으로 동의한다. 필자가 평생 동안 소프트웨어 공학을 실행했으면서도 소프트웨어 공학을 한다는 말은 하지 않는 이유이다. 이 부분이 필자의 고민이었듯이 저자들의 심오한 철학적인 면까지도 엿볼 수 있다.

Software Requirements를 수행하는 방법을 프로세스의 관점(Process-based Breakdown)에서 순서대로 나열하면 마치 폭포수모델(Waterfall Model)의 Top-down 방식으로 생각할 수 있다. 하지만 그것은 착각이고 Requirements 과정을 순서적으로 설명하는 것은 각 Requirements의 상세과정을 수행하는 각 과정에서 필요한 자원과 제약사항 등에 대한 설명을 하기 위한 하나의 분류방법인 것이다. 이런 프로세스 관점의 순서대로 설명할 수도 있지만 프로세스가 아닌 제품 관점(Product-based Breakdown)으로 단계를 나눌 수도 있다. 예를 들어 System requirements, Software Requirements, Prototype, Use cases 등과 같은 방법도 하나의 방법이다.



여기에서는 프로세스의 관점에서 나누는데  그것 때문에 마치 프로젝트의 시작시점에서 Requirements의 활동을 모두 완벽하게 수행해야 하는 독립적인 프로세스로 착각할 수 있다. 하지만 Requirements Process는 매우 복잡하고 개발 후반부의 설계, 구현, 테스트, 유지보수, 형상관리 등 모든 지식영역과 매우 밀접하게 관련되어 있다. 즉 하나의 독립된 프로세스는 아니다. 순서적으로 진행할 수도 있고 다른 지식영역 활동과 병행해서 진행할 수도 있다.

(*** 필자주석) 국내에서 거의 모든 사람들이 착각하는 것이 저자들이 얘기하듯이 분석단계를 개발시작시에 첫 단계에서 작성해서 완성하는 것이라고 이론적으로 생각하는 것이다. 반대로 더 큰 착각은 그게 어려우니까 그냥 대충하고 넘어가고 나중에 상세한 부분을 정해나가겠다는 것이다. 둘 다 잘못된 것이다. 하나는 지극히 느린 국방부의 접근 방법이고 두 번째는 개집 만드는 경우에는 괜찮지만 전세계 소프트웨어의 99.9%에 해당되는 상용제품을 만드는 경우에는 나쁜 방법이다.

이미 저자들이 앞부분에서 불충분한 Requirements의 위험성에 대해서 경고했지만 지금 실감하기는 어려울 것이다. 아무튼 이것도 잘못이고 저것도 잘못이라고 하는데 일단 머리에 인식해 두고 계속 경험하면서 과연 저자들이 무엇을 전달하려고 했는지 깨달아 보자.

또 독립된 프로세스라고 생각하고 SRS를 작성하기 위한 문서 Template을 달라고 하는 사람들이 많은데 Template은 인터넷에 널려 있는 것에 불과하고 지금 이 문서에서 말하는 복잡성이나 어려움에 대한 이해를 못하고 있는 것이다. 템플릿은 음식을 담는 그릇일 뿐 중요한 것은 그릇에 담을 내용물인 음식을 만드는 것이다. 필자의 책에서도 언급했지만 더 이상 Template을 찾아 헤매는 노력은 하지 않기 바란다.

"Software Requirements 지식영역"은 다음과 같은 Topic으로 구분된다



1. Software Requirements Fundamentals (본질)

2. Requirements Process (프로세스)

3. Requirement Elicitation (도출)

4. Requirements Analysis (분석)

5. Requirements Specification (명시)

6. Requirements Validation (검증)

7. Practical Considerations (현실적인 고려사항)

8. Software Requirements Tools (도구)

(*** 필자주석) 국내에서 용어의 혼란 때문에 정확한 의미를 이해하는 것이 어려울지 모른다. 특히 Requirements와 Specification의 차이는 문서의 양으로 비교했을 때 10페이지와 1000페이지의 차이일 정도로 크다. 그런데 Requirements를 작성하고서는 Specification을 작성했다고 착각한다. 용어도 요구사항, 고객요구사항, 명세서, 기능명세서, 요구사항명세서 등을 혼용해서 사용하기도 한다. 다 똑같은 문서를 의미하는 것으로 착각하기도 한다. 그래서 필자가 영어를 그대로 사용하지 절대 번역을 하지 않는다. 지금 이 단계에서는 Software Requirements Specifications(SRS)이 위의 8가지 Topic의 결과로 나오는 문서이고 그 중간 과정에서 나오는 문서가 Requirements 라는 것 정도만 이해하고 넘어가자.

위  8개의 Topic은 다음 Post 부터 하나씩 설명하기로 한다.

SWEBOK 해설 시리즈 - 소개

SWEBOK 시리즈  #1 - 2014-06-04



SWEBOK에 대한 소개



Software Engineering Body of Knowledge (SWEBOK, 소프트웨어 공학 지식체계)은 소프트웨어 공학의 지식체계에 대한 ISO/IEC 국제 표준이다. 필자가 그 내용의 심오함에 감탄한 문서이기도 한다. 그 감탄은 필자가 수십 년간 소프트웨어 개발을 해 왔기 때문에 가능한 것이지 충분한 경험 없이는 감동을 느끼기는 어려울 것이라고 생각한다. 이 문서는 법적인 표준이 아니라 소프트웨어 업계에서 일반적으로 공감하는 내용으로서 전 세계 수백 명의 소프트웨어 전문가들이 자발적으로 참여해서 만든 문서이다. 2004년에 V2가 발간되었고 2014년에 V3가 발간되었다. SWEBOK은 거의 모든 소프트웨어 공학활동의 기반이 되는 바이블 같은 문서인 만큼 모든 경우를 설명하는 세세한 내용을 담을 수는 없고 어느 정도 추상적인 수준으로 작성되었다는 것은 자연스러운 일이다.



대부분의 실리콘밸리 소프트웨어 회사에서의 실무적인 경험은 체계적이기는 하지만 공학이론에서 시작한 것이 아니라 현실에서 정립된 방법론이었다. 그런 상황에서 우연히 SWEBOK을 처음 접했을 때 이렇게 훌륭한 문서가 있나 하는 느낌을 받았다. 필자의 수십 년 개발경험의 핵심을 그대로 적어 놓은 것 같았다. 그런 면에서 소프트웨어 공학의 바이블이라고 불리는 것도 전혀 놀랍지 않다. 하지만 그렇게 훌륭한 문서임에도 불구하고 현실적인 이용가치는 거의 없다는 것이 필자의 생각이다. 마치 멋진 예술 작품을 보는 느낌이다. 멋진 그림을 실제로 그릴 수 있게 차근차근 공부해 나가는 것이 이 시리즈의 목적이다.



SWEBOK을 읽고서 이해하고 훌륭한 소프트웨어를 개발한다는 것은 망상이다. 현실과 연결하는 고리가 없기 때문이다. 추상적인 이론은 하나지만 현실은 백이면 백 모두 다르다. 다양하게 응용해서 적용하는 것은 각자 알아서 해야 하는 일이다. 그럼에도 불구하고 소프트웨어 공학의 바이블답게 모든 핵심과 함께 심지어는 가끔가다 요령이나 힌트까지 적혀 있다. 그런 점에서 순수 이론만을 강조하는 문서는 아니지만 각자 처한 환경에 맞게 해석해서 현실에 어떻게 적용하는 지는 최고 경험자가 아니면 불가능한 수준이다. 손자병법과 같이 훌륭한 내용이지만 응용하는 것이 어렵다.



먼저 SWEBOK에 들어가기 전에 근본적으로 소프트웨어 공학에 대한 실체를 이해해 볼 필요가 있다. 소프트웨어의 역사가 60년이 넘어가면서 그 동안에 쌓인 Know-how가 미국의 소프트웨어 산업계에 녹아 들었다. 실리콘밸리에서는 'Software Engineering' 이라는 용어조차도 생소하다는 것은 현실적인 소프트웨어 개발 역량과 소프트웨어 공학 이론을 안다는 것과는 인과관계가 별로 없다는 것을 의미한다. 소프트웨어 공학이 선구자의 입장에서 학계의 연구의 필요성은 있겠지만 현실에서 무조건 받아들이는 것은 조심해야 할 일이다.



소프트웨어 공학은 현실에서 소프트웨어를 잘 개발하는 방법을 연구하는 학문이다. 이론이 현실을 논한다는 데서 모순이기도 하다. 먼저 소프트웨어 공학 자체가 너무 추상적인 단어이기 때문에 종교적인 신념과 같이 사람에 따라 받아들이는 정도가 다르다. 소프트웨어 공학 이론의 세계적인 대가라고 할 수 있는 이바 야콥슨(Ivar Jacobson)조차 그의 저서에서 소프트웨어 공학의 문제점에 대해 다음과 같이 언급했다.



* 단기적인 유행(FAD)과 패션(Fashion)에 의한 흥행

* 검증되지 않은 미숙한 이론에 근거

* 비교할 수도 없는 너무 많은 방법론

* 평가할 수 있는 실험 결과의 부재

* 학계의 연구와 산업계의 실용성의 차이



이 말은 소프트웨어 공학을 맹목적으로 믿고 따라하기 보다는 생각할 만한 요소가 많다는 것을 말해준다. 야콥슨의 말을 한마디로 요약하면 실전을 다루는 소프트웨어 공학을 이론적으로 접근했다는 것이 문제이다. 이론과 현실의 괴리이다. 많은 소프트웨어 개발자들이 소프트웨어 공학에 현혹되어 불필요한 활동을 하게 된 데에는 이론에 너무 집착했기 때문이다.



결론적으로 필자가 SWEBOK의 심오함에 감동했음에도 불구하고 최고 전문가가 아닌 사람들이 실제 현실에 적용하기에는 너무 어렵다. 그래서 그 간극을 메워주기 위한 노력으로 마치 바이블을 해석하듯이 국내 현실에 맞게 시리즈로 설명해보려고 한다.



지금부터 본격적으로 SWEBOK에 대한 해석을 시작해 보자. 필자의 주석은 (***필자주석)으로 표시하였고 나머지 부분은 SWEBOK을 번역한 부분이다.



SWEBOK는 다음의 5가지 목적으로 작성되었다.

1. 세계적으로 소프트웨어 공학에 대해 일관성 있는 정보를 전달한다

2. 소프트웨어 공학의 범위를 명확히 정하고 전산학, 수학, 프로젝트 관리와 같은 다른 활동과의 차이를 명백히 한다

3. 소프트웨어 공학의 내용을 설명한다

4. 소프트웨어 공학의 지식체계에 대한 쉬운 Top-Down 접근방법을 제공한다.

5. 인증이나 자격증의 교과 과정을 위한 기반을 제공한다

(***필자주석) 공식적인 문서답게 딱딱한 용어로 표현되었지만 소프트웨어 공학(즉 개발을 잘하는 방법)에 대해 혼란을 없애고 본질을 이해시키는 것이 목적이다.

이 목적을 위해 15개의 지식영역(KA, Knowledge Area)으로 분류한다.

(***필자주석)  소프트웨어 전문가가 되기 위해 알아야 할 영역이 15개라는 것을 의미한다. 동시에 많은 시간이 걸린다는 것을 의미한다. 심지어는 Software Requirements와 같이 한 분야에 5년 10년이 걸려도 잘 하기 어려운 분야가 있다. 진정한 소프트웨어 전문가가 된다는 것은 프로그래밍을 잘 한다는 것 외에도 많은 것이 필요하다.

1  Software Requirements (소프트웨어 요구사항)
2  Software Design (소프트웨어 설계)
3  Software Construction (소프트웨어 구현)
4  Software Testing (소프트웨어 테스팅)
5  Software Maintenance (소프트웨어 유지보수)
6  Software Configuration Management (소프트웨어 형상관리)
7  Software Engineering Management (소프트웨어 공학 관리)
8  Software Engineering Process (소프트웨어 공학 프로세스)
9  Software Engineering Models and Methods (소프트웨어 공학 모델과 방법론)
10  Software Quality (소프트웨어 품질관리)
11  Software Engineering Professional Practice (소프트웨어 공학 전문가 기량)
12  Software Engineering Economics (소프트웨어 공학 경제학)
13  Computing Foundations (컴퓨팅의 기반)
14  Mathematical Foundations (수학적 기반)
15  Engineering Foundations (공학적 기반)



각 지식영역(KA)은 다시 2 혹은 3 수준의 토픽(Topic)으로 나누어져서 원하는 토픽를 쉽게 찾을 수 있도록 했다.

(***필자주석) SWEBOK이 소프트웨어 생명주기의 모든 영역을 다루므로 책 한두 권으로 전문가가 될 수 있는 것은 아니다. 하나의 KA만 해도 평생을 향상시키면서 가는 것이기 때문에 배우면 배운 만큼 향상된 것으로 생각해야지 언제 완성시킨다는 개념은 없다.

이제 긴 여행을 시작해 보자.

개발자의 커뮤니케이션이란 무엇인가?

저서 "글로벌 소프트웨어를 말하다"의 31장



회사를 컨설팅하다 보면 가장 많이 듣는 소리가 “개발자들은 커뮤니케이션을 못한다” 라고 한다. 그러고는 소위 훌륭한 경영자는 개발자들의 커뮤니케이션을 향상시키기 위해 커뮤니케이션 전문 컨설팅을 받는다. 불행이도 그런 커뮤니케이션 스킬은 개발자들을 목표로 한 것이 아니다. 실리콘밸리의 회사에서 아침에 와서 묵묵히 하루 종일 자기 사무실에 앉아서 한 번도 나오지 않고 일하고 있는 개발자는 커뮤니케이션이 전혀 없는가? 재택근무 하면서 일주일에 한 번만 회사에 나와서 잠깐 회의하고 가는 개발자는 커뮤니케이션을 충분히 하지 않고 있는 것인가?  모두 틀렸다. 그들은 아주 커뮤니케이션을 잘 하고 있다. 영업사원이 하는 종류의 커뮤니케이션을 하지 않고 있을 뿐이다.



개발자들의 커뮤니케이션의 목적은 무엇인가?  개방, 협업, 공유이다. 그럼 아무도 안 만나고 어떻게 개방, 협업, 공유를 한단 말인가? 만나서 하는 것은 개방, 협업, 공유가 아니라 개방, 협업, 공유를 하기 위한 준비작업을 하는 것이다.



개방, 협업, 공유가 효율적으로 일하는 가장 좋은 방법이며 자신의 스킬을 향상시키는 가장 좋은 방법이다. 선배한테만 배우는 것이 아니라 동료한테서도 배우고 후배한테서도 배우는 것이 있다. 이 세상에 혼자서 배워서 프로가 될 수 있는 것은 없다. 있다면 얘기해 주기 바란다. 천재 골퍼인 타이거 우즈도 스승이 없었던 적이 한 번도 없었고 천재 김연아도 항상 코치가 필요하다. 그런데 무슨 베짱으로 소프트웨어를 혼자 할 수 있다고 하는 지 모르겠다. 개방, 협업, 공유를 하지 않으므로써 얻는 장점은 오직 한가지이다. 자기만 아는 비밀로 얻는 직업의 안정성(Job Safety)이다. 소위 영업 사원들이 “Red Book” 이라고 자기의 비밀고객명부를 혼자만 가지고 있는 것이다. 개발자도 그런 안전 장치인 비밀정보를 가질 수 있다면 일단 단기적인 안전성은 확보한 것이다. 실제로 국내 소프트웨어 회사에서는 많은 개발자가 자신만의 비밀정보를 만들어 다른 사람이 쉽게 파악하지 못하는 안정권에 들어가는데 성공했다. 실리콘밸리에서는 비밀정보가 되기 위한 경계를 넘기기가 불가능하다. 그러기 전에 아마 해고 당할 것이다. 비밀임계치를 넘기지 못하도록 만드는 것이 회사의 책임이다.



그런 공유와 개방를 강제화 하는 것이 것이 바로 기반 시스템과 프로세스이다. 하지만 공유와 개방은 했지만 아직도 협업은 완성되지 않은 상태로 남아 있다. 개방과 공유를 해도 협업이 없으면 지식이 미완성된 상태로 남는다. 협업은 개인들의 자발적인 노력이 받쳐주어야 한다. 회의에서 아무런 말도 하지 않고 다른 사람을 도와주려고 하는 마음이 없으면 협업은 되지 않는다. 그래서 아무리 강제로 개방과 공유를 해도 남과 협업해서 일을 하려고 하지 않으면 개방과 공유의 효과가 반감된다.



여기서는 개발자의 핵심 역량인 개방과 공유를 하기 위한 커뮤니케이션이 무엇인지 알아보기 쉽도록 통상적으로 생각하는 커뮤니케이션 방법과 개발자들의 커뮤니케이션 방법을 비교해서 보자.



 말을 잘 한다  <-> 문서를 잘 만든다.



개발자는 말을 잘할 필요가 없다. 말을 잘하는 것 대신에 조용히 문서를 잘 만들면 된다. 말은 오래 기억되지 않는다. 그리고 오해의 소지가 많다. 회의가 끝난 다음에 회의록을 적어보내면 틀렸다고 하는 경우가 많다. 개발하려는 제품의 사양을 말로 할 필요가 없다. 문서로 적고 다 검토하게 요청하면 된다. 개발자가 말을 하는 경우는 분석이나 설계의 검토회의나 코드리뷰를 할 때이다. 그 외에는 업무상 말로 할 이슈가 거의 없다.

협상을 잘 한다  <-> 정확하게 명시한다



개발자는 일단 무엇을 왜, 언제, 어떻게 하는지를 정확하게 명시하는 것이 핵심이고 그건 개발자들이 가장 잘 할 수 있는 것이다. 영업이나 고객등 다른 부서와의 협상은 관리자나 소수의 분석가의 담당이다. 정확한 정보를 관리자와 분석가에게 입력하는 것이 개발자들의 책임이다. 개발자들이 직접 협상하러 나가면 대부분 싸우고 망친다. 개발자로서 협상의 기술까지 가지고 있으면 좋지만 기본이 자신만의 로직으로 작동하는 개발자의 특성상 모순에 가깝다.



사수가 가르친다 <-> 멘토가 가이드 한다.



둘 다 선배한테서 뭔가 배운다는 입장은 똑 같은데 무엇이 차이인가? 국내회사에서 사수한테 배운다고 하지만 사실은 모순투성이이다. 사수라고 하면 일단 고급 개발자인데 사수가 바쁘지 않다면 회사가 인력관리를 잘 못하는 것이고 바쁘다면 가르쳐 줄 시간이 없는 것이다. 대부분의 회사는 사수가 가르쳐 줄 시간이 없어 말만 사수지 결국은 혼자서 고생하면서 겨우 배워 간다. 사실 사수도 조수한테 잘 가르쳐줘서 금방 자기를 따라잡으면 불안하기도 할 테고 시간도 없으니 많은 시간 내서 가르쳐 줄 수도 없다. 결국 사수는 인간의 본능으로 보나 회사에서의 우선순위로 보나 조수를 제대로 가르쳐 준다는 것은 기대하기 어렵다. 그럼 실리콘밸리에서 새로운 회사를 들어가면 아무것도 모르는 상태에서 멘토가 정해지는 데 무엇을 배울까? 멘토가 하는 일은 거의 없다. 어디에 어떤 정보가 있나를 가르쳐 주는 것이 멘토의 일이다. 그런 것을 가르쳐 주는데는 하루에 5분이면 된다. 즉 이슈관리시스템의 IP 주소가 이거다. 설계문서의 위치는 소스관리시스템의 어느 디렉토리에 있다. 이런 것들이다. 그 다음부터는 다 알아서 공부하고 일을 할 수가 있다. 이게 바로 멘토와 멘티의 커뮤니케이션인 것이다. 가내 수공업처럼 사수가 가르쳐 줄 때까지 노예처럼 살 필요가 없다. 이런 커뮤니케이션이 가능하게 된 것은 기반시스템과 문서가 이미 다 준비되어 있기 때문에 가능한 것이다. 이 두가지가 준비되어 있지 않다면 국내처럼 사수만을 바라보며 기다리는 수 밖에 없다. 사실은 항상 사수가 더 실력이 좋다고 할 수는 없다. 가지고 있는 정보의 폐쇄성에 의해 단기간 가짜 실력의 우위를 누리기도 하지만 장기적으로는 별 것도 아닌 것으로 들통나기도 한다.



회의를 자주 한다  <-> 재택근무 한다



국내 소프트웨어 회사와 실리콘밸리 회사의 개발자와의 하루 일과 중에 가장 다른 것이 이것이다. 국내 회사에서는 과장 정도 되는 지위만 오르면 회의하느라 하루 종일 뛰어 다닌다. 과장이면 이제 조금 개발을 알 정도의 경험인데 개발은 물 건너가고 회의만 한다. 반면에 실리콘밸리에서는 회의는 일주일에 한 번이나 와서 잠깐 하는 것이고 집에서 일할 수도 있다. 집에서 일한다고 정보가 단절 된 것이 아니고 회의를 많이하는 국내 회사보다도 더 많은 정보를 기반시스템을 통해 공유한다. 그러니까 회의를 할 필요도 없이 모든 사람이 공유할 수 있는 지식인 것이다. 정보의 공유가 아니라 어떤 심각한 결정을 해야 하는 경우가 되어야 일주일에 한번 회의하면 된다. 자잘한 결정들은 이미 기반시스템을 통해 서로 다 대화하고 이미 다 결정했다. 만나서 하는 비 효율적인 회의를 할 필요가 별로 없는 것이다. 그래서 국내 회사에는 회의실이 항상 모자란다. 그것도 낭비다. 회의실을 늘리면 늘리는 대로 그래도 모자란다. 아무리 늘려도 사용하고자 하는 사람은 끝이 없다. 처음부터 근본적으로 잘못된 것이다.



보고를 자주 한다  <-> 보고는 기반시스템을 본다



필자가 컨설팅을 하면서 가장 듣기 싫어하는 말이 바로 “보고하러 간다” 이다. 사람을 앞에 놓고 말을 들어보는 것이 중요한 경우가 가끔 있겠지만 시시때때로 보고하러 간다. 실리콘밸리에서는 어떤 때는 주간 회의를 빼 놓고는 거의 보고하러 갈 필요가 없다. 그 이유는 보고해야 될 자료가 다 기반시스템이나 저장소에 있기 때문이다. 그것도 훨씬 더 보기 좋은 형태로 되어 있기 때문에 누구를 오라고 할 필요가 없다. 그러는 것이 시간이 더 걸리고 보고하는 사람이 만들어 온 자료는 그 사람의 관점 밖에 보지 못한다. 다른 관점에서 보고 싶을 때 다른 자료를 또 만들어서 다시 보고해야 한다. 예를 들어 새 버전을 출시하기 위해서 버그를 고쳐야 하는데 지금 몇 개나 남아 있고, 누가 몇 개를 고쳤고, 지금 일이 밀려있는 개발자가 누구고, 어느 컴포넌트가 할 일이 제일 많은지 등등 물어볼 수 있는 관점이 수십개 혹은 수백개는 된다. 이슈관리시스템에서 그냥 누구나 보면 다 있는 정보인데 와서 보고하라고 하면 보고자가 자기의 관점에서 자료를 만들어 와서 보고한다. 그래서 필자는 컨설팅 하면서 상관이 보고하라고 하면 상관 컴퓨터에 가서 이슈관리시스템을 놓고 같이 보면서 질문에 따라 다 보여주라고 한다. 보고서 만드느라 시간 들이고 종이 낭비한다. 실리콘밸리의 경우는 자신이 직접 훨씬 더 잘 볼 수 있는데 아예 그런 보고를 요구할 리가 없다. 회사 컨설팅을 할 때 사장님들에게 이슈관리시스템을 사용하는 것이 훨씬 더 많은 정보를 정확하게 볼 수 있으니까 버튼 몇 번만 누르시면 됩니다 라고 얘기해도 듣지 않는다. 그래서 회의와 보고에 끌려다니다 보니 고급개발자는 영원히 개발 실무에서 멀어지게 된다. 인재의 손실이다.



개발자의 커뮤니케이션을 일반 커뮤니케이션과 혼동하면 안된다. 인간 관계를 소홀히 하는 개발자도 있다. 하지만 기본적으로 정보의 공유가 개발자의 커뮤니케이션의 핵심이기 때문에 기반시스템을 얼마나 잘 사용하고 문서를 얼마나 정확히 적느냐가 중요하다. 인간관계로 영업을 할 때나 연봉협상을 유리하게 하려면 협상의 스킬이기 때문에 말을 잘해야 한다. 그래서 일반 커뮤니케이션도 잘하면 나쁘지는 않다. 단 기본적인 개발자 커뮤니케이션을 소홀히 하면 안된다.

글로벌 소프트웨어 회사의 필요조건과 특징

저서 "글로벌 소프트웨어를 말하다"의 27장



글로벌 소프트웨어 회사가 가져야 하는 조건은 무엇일까? 많은 필요조건을 늘어놓을 수 있다. 하지만 충분조건은 아니다. 성공할 모든 필요조건을 명시할 수 있다면 좋겠지만 회사의 성공여부를 가장 잘 예측하는 벤처투자가들도 확률이 10% 밖에 안된다. 하지만 그들은 안될 것 같은 회사들은 금방 가려낼 수 있다. 필요조건 중의 하나만 모자라면 투자하지 않는다. 투자를 할 이유를 찾는 것은 어렵지만 투자를 하지 않아야 할 이유를 찾는 것은 쉽다. 필자가 보는 관점은 영업, 재무, 기획역량이나 CEO의 비전 같은 것이 아니고 소프트웨어 회사의 심장인 개발역량의 관점에서만 본다. 개발 역량이 없으면 나머지가 다 있더라도 성공할 수 없다. 마찬가지 논리로 여기있는 개발역량 조건을 다 만족시킨다고 해서 충분조건은 아니기 떄문에 글로벌 개발역량을 보장하는 것은 아니다. 하지만 필자가 생각할 때 여기 있는 것 정도면 역량이 매우 높은 회사인 것은 분명하고 충분조건에 매우 가깝다고 볼 수 있다.



이 중의 일부분은 국내 회사중 단기간에 팔고 버리는 생명주기가 짧은 제품과 항상 최신 버전 하나만 유지해도 되는 포털서비스 같은 회사에서는 해당되지 않을 수도 있으나 특수한 경우일 뿐이고 제품 생명주기가 길고 여러 버전을 유지해야 하는 경우가 일반적인 경우라고 할 수 있다. 여기서는 글로벌 회사가 될 수 없는 조건들을 늘어 놓는 방식으로 적는다. 이 중에 하나라도 해당되면 글로벌 회사의 역량은 없다고 보면 된다.

• 개발자가 재택 근무를 할 수 없다.

재택근무를 할 수 있다는 것은 많은 것이 준비되어 있다는 것을 의미한다. 개발자들이 재택근무를 한다고 시뮬레이션을 해보면 안되는 많은 이유를 발견할 수 있을 것이다. 그 안되는 것을 다 해결해야만 한다. 재택근무가 가능한 상태에서 회사가 어떤 근무정책을 선택하는 가는 아예 재택근무를 할 수 없는 상황과는 다르다.

• * 개발자들을 계속 회의 한다고 불러 댄다

개발중인 개발자 들과 많은 얘기를 해야 한다는 것은 계획이 없다는 것을 뜻한다. 계획이 없으니 개발자들에게 심심하면 물어보아야 한다. 간식과 같이 궁금하면 불러댄다. 관리자나 기획팀이 주요 원인이다. 위의 재택근무를 할 수 없는 이유 중의 하나이기도 하다. 열정적인 회의가 열심히 일하는 모습으로 관리자가 착각할 지 모르나 이는 분석단계와 같이 많은 협업이 필요한 개발의 초기에만 나타나야 하는 모습이다.

•  * 멘토가 시간을 많이 소비해서 가르쳐주지 않고는 신입사원이 일을 시작할 수 없다

사수가 가르쳐 주어야 일을 시작할 수 있다면 진퇴양난이다. 바쁜 사수가 시간을 낼 수도 없고 그렇다고 신입사원들을 놀게 내버려둘 수도 없다. 이 역시 모든 문제를 한 눈에 보여주는 확실한 증거이다. 글로벌 회사에서 이런 소리 하는 경우는 본 적이 없다.

• * 제품 릴리스를 일 년에 세 번 이상 한다.

제품 릴리스를 자주 한다는 것을 고객서비스를 잘 한다고 착각하지 말아라. 일 년에 세 번의 릴리스면 필자의 경험으로 유지보수하느라 허덕대는 수준이다. 이 정도면 독약을 먹고 있는 것이다. 잦은 제품 릴리스는 상상도 할 수 없는 많은 문제를 가져온다. 초기에 조금이라도 많이 팔아야 생존해야 하는 회사가 빠져드는 달콤한 유혹이다. 장기적으로 살아남기 위해서는 고객에게 욕을 먹더라도 자주 릴리스를 하지 말아라. 그래서 회사가 망한다면 일찍 망하고 다른 일을 찾는 것이 현명하다.

• * 백발이 성성한 개발자가 한 명도 없다.

SW 관련 외국 컨퍼런스를 가보면, 나이 지긋한 백발의 엔지니어를 만나는 것이 어렵지 않다. 지식은 경험을 통해 시간이 흐르면서 지혜와 통찰력으로 변화되어 간다. 이런 전문가가 없이 젊은 개발자들만을 데리고 일을 하겠다는 것은 젊은 군졸들이 전쟁을 하는 것과 같다. 전투는 하겠지만 전쟁에서 승리하기는 힘들다.

•  * 지금 없어지면 제품 유지보수에 큰일 나는 개발자가 있다.

회사를 판단하는 방법 중의 하나가 '누가 중요한 개발자인가' 이다. 담당자가 퇴사해서 문제가 생겼습니다 라고 말하는 회사는 미래가 불안한 회사이다. 그런 개발자가 한두 명이 아닐 테니 지뢰 속에서 살고 있는 것이다. 우리 회사는 개발자가 나가도 유지보수에는 아무 문제 없습니다 라고 안심할 수 있어야 제대로 된 회사이다. 단 직원이 나가면 미래의 역량은 감소한다.

•  * 시장에 나온 새로운 개발 도구는 다 가지고 있다.

돈 많은 대기업에서 주로 벌어지는 현상인데 도구 공부는 재미는 있지만 실력향상과는 관계가 없다. 골프채 많이 가지고 있는 사람이 골프 잘 치지 못한다. 소위 장비병은 아마추어들에게만 나타나는 병이다. 설령 도구의 차이가 있더라도 편하고 싼 평범한 도구를 잘 사용하는 것이 좋다. 회사 출퇴근 하는데 벤츠가 필요한 것이 아니고 그냥 조그만 자동차 하나 있으면 된다. 나머지는 실용성과는 관계없는 개발에 방해가 되는 과시용이다.

• * 코드를 많이 복사해서 사용한다.

스포츠로 말하면 가장 기본인 달리기 체력이 없는 것이다. 필자가 10년 전에 출간한 책에서도 복사하지 말라고 샘플코드를 적어 놓은 적이 있는데 국내 개발자들은 아직도 변한 것이 없다. 10년 동안 변화가 없는 것을 보면 앞으로도 희망이 보이지 않는다. 코드 복사하는 이유는 빨리 개발해야 한다는 이유에서이다. 복사하고 난 다음 뒤치다꺼리는 생각하지도 못하는 근시안이다. 이 문제가 얼마나 심각한 것인지는 회사가 커지면 안다. 그 때까지는 뭐 큰일이라고 그러냐고 무시하다가 막상 당하게 되면 지금 치루는 비용의 10배, 100배의 비용을 치루게 될 것이다.

• * 코딩하면서 예외 처리를 하지 않는다.

위의 코드 복사 문제와 비슷하지만 복사보다는 미래의 예상 피해도는 작다. 하지만 꼭 지켜야 하는 기초 체력중의 하나이다.

• * 코딩을 각자 다 자기 스타일로 한다.

코딩 스타일의 표준화는 로마에 가면 로마법을 따라야 하는 현지법이다. 내 법이 옳다고 현지 법을 지키지 않는 다는 것은 관리가 안되는 오합지졸이며 불량배이다. 가독성이 생길 수가 없다. 빈 칸도 나중에는 못 고치는 게 잘 되는 회사에서 미래에 벌어지는 현상임을 깨닫는다면 표준화된 코딩의 중요성을 추측할 수 있다.

•  * 어떤 개발자가 마지막 1 주일에 소스코드를 왜 몇 줄을 고쳤는지 모른다

소스코드관리시스템과 이슈관리시스템을 사용해야 하는 기본적인 목적이다. 열심히 일한다고 생각하는 개발자들이 의외로 엉터리인 경우가 많다. 누가 무엇을 왜 하는 지를 서로 아는 것이 투명성이다. 이 투명성이 없는 회사는 일정관리나 리스크관리를 할 수 없다. 그냥 서로 믿고 가다가 봉변 당하기 쉽다.

• * 착한 개발자가 피해를 입는다

깨끗한 물과 더러운 물이 섞이면 깨끗한 물이 피해를 입는다. 한 편이 약속한 대로 하지 않을 경우에 지저분한 쪽보다는 깨끗한 쪽에서 수정하는 게 더 쉽기 때문에 제대로 개발한 사람에게 일이 더 많아진다. 일이 훨씬 많더라도 지저분한 쪽을 고치게 해야 한다. 아니면 그나마 남아있던 깨끗한 쪽도 다 사라질 것이다.

•  * 보고하느라 시간을 많이 보낸다.

'이게 뭐예요?' 라고 물어 보면 '이슈관리시스템에 가서 보세요' 라고 말할 수 있다면 회사가 잘 돌아간다는 증거이다. 보고는 보고자의 주관적인 관점을 접하게 된다. 또 보고의 문제는 보고자료를 예쁘게 만드느라 시간을 낭비한다. 아마도 개발자가 파워포인트를 가장 많이 사용하는 나라가 한국일 것이다. 개발자들이 파워포인트를 만들 일이 없어야 한다. 보고라는 것은 정보가 공유가 되지 않았기 때문에 요구하는 것이다. 유비가 제갈량에게 보고하라고 하지 않는다. 항상 무슨 일을 하는지 알고 있기 때문이다. 보고해서 알게 된다면 사후 약방문이다. 국내회사에서 이슈관리시스템만 잘 사용해도 보고의 90%는 없어진다. 그리고 객관적인 정보를 여러 관점에서 항상 볼 수 있다.

•  * 개발자가 휴가를 2주 갔다 올 시간이 없다.

'놀 수 없는 사람은 해고시킨다' 라는 말이 있다. 어떤 사람이 중요한 것과 대체 가능한 것과는 다르다. 대체가능하면서 중요한 개발자가 가장 중요한 개발자이다. 대체가능하지 않고 중요한 사람은 회사에 엄청난 위험성을 주는 사람이다. 유비나 제갈량 같이 CEO나 CTO 수준에서는 대체가 불가능하지만 개발자 수준에서는 그렇게 되면 안된다.

• * 모든 결정에 ROI(투자대비효과)를 달라고 한다.

화사에서 결정을 하는 두가지 요소는 통찰력과 근거이다. 통찰력이 없이 근거만으로 움직이는 회사는 모든 일에 ROI를 가져오라고 한다. 통찰력 없는 CEO나 임원이 무지한 상태에서 책임을 피하려는 목적이 크다. 이런 회사는 개발자들이 일하기 피곤하고 얼마든지 조작된 ROI를 만드는 부작용이 생긴다.

• * 다음에 개발할 제품이 무엇인지 모른다.

다음에 개발할 제품에 대한 정보가 없이 지금 제품을 개발하고 있다면 안개 속을 걷는 것과 같다. 아키텍처는 미래를 내다볼 수 있어야지 가치가 있다. 많은 재작업이 항상 벌어지는 원인이 되고 이랬다 저랬다 개발자들에게는 짜증나는 상황이 벌어진다.

•  * 문서를 만들기는 하나 보지는 않는다.

보지 않는 문서가 만들어 지는 데는 여러가지 원인이 있으나 어떤 원인이든지 회사가 엄청난 비용을 낭비하고 있고 개발체계가 전혀 잡혀있지 않다는 것을 말해준다. 보지 않으려면 절대 만들지 않는 것이 좋다. 연습을 한다고 생각하면 큰 착각이다. 잘못된 연습은 잘못된 선입관과 잘못된 습관을 만들어 내니 아예 하지 않는 것이 잘못하는 것보다는 낫다.

• * 물려줄 자산이 없다.

물려줄 자산이 있다는 것은 부자란 얘기이다. 부자의 #1 걱정은 상속이라고 한다. 상속을 걱정해보지 않은 사람은 금전적으로 부자가 아니라고 한다. 소프트웨어 회사의 자산은 튼튼한 소스코드이다. 대부분은 개발자 자신도 유지보수를 못하는 상태라 회사를 떠나고 나면 남은 사람들은 새로 개발하는 상황이 부지기수다. 다른 사람들에게 물려줄 자산이 없는 것이다. 부모의 상속 없이 자식이 새로 만들어서 자수성가한다는 것은 고생이다.



이런 많은 특징들이 글로벌 회사에서는 벌어지지 않는다. 사실 모두가 독립적인 것은 아니고 인과관계와 상관관계가 있기도 하지만 회사의 종류에 따라 우선순위는 다를 수 있다. 필자는 회사에 들어가서 보기 전에도 강연을 함으로써 그 회사의 역량을 알 수 있다. 강연의 주선부터 시작해서 강연을 마치고 강연비 지급이 완료되는 것까지가 강연의 생명주기이다. 잘 되어 있는 회사는 필자가 아무런 의문을 가질 필요도 없이 오직 강연준비만 잘하면 되게 만든다. 내가 이동해야 하는 모든 동선을 포함해서 강연장의 준비 등 전혀 걱정할 필요 없이 미리 얘기해 준다. 머리 속으로 시뮬레이션을 완벽하게 한다. 반대로 혼란스러운 회사는 내가 물어 보면서 내 살 길을 찾아야 한다. 가르쳐 주는 정보도 부실해 회사 안에서도 길을 헤매기도 한다. 강연의 내용에 집중할 시간에 다른 곳에 낭비하고 있으니 둘 다 피해이다.



좋은 식당과 나쁜 식당의 차이가 고객이 어떻게 행동할 지 모르는 식당이라고 한다. 새우튀김에서 머리를 먹는지 안 먹는지 애매모호한 경우가 있다. 새우 크기에 따라 다르고 튀긴 정도에 따라 다르다. '손님이 알아서 먹으세요' 라는 식당은 고급식당이 아니다. 생각할 필요가 없이 즐길 수 있게 만들어야 한다. 개발자도 개발에만 집중하고 나머지는 신경 쓸 필요 없게 만들어 주는 회사가 좋은 회사이다.



위에서 언급한 많은 실패의 특징 중에 대부분이 해당된다면 난감하다. 탈무드에서 두 개의 거짓말은 해도 된다고 했다. 물건을 이미 산 사람에게 잘 샀다고 얘기하는 것과 결혼한 남자에게 부인이 아름다워서 행복하게 살 것이라는 거짓말이다. 소프트웨어 회사에 컨설팅가서 이미 가능성이 없는 회사에는 얘기한다고 해도 도움이 안되니 그냥 잘한다고 말해준다. 발전 가능성이 있는 회사에서는 이런저런 점을 개선해야 한다고 말한다. 즉 축구 동호회에 가서는 축구 잘한다고 칭찬하지만, 국가대표팀에 가서는 그 따위로 축구해서 무슨 월드컵에 나가냐고 얘기하는 것이다. 그러니 나중에라도 필자의 말을 믿지 말고 스스로 판단하기 바란다. 어떻게 고치는지에 대한 방법은 책 여러 권이 필요할 정도의 방대한 내용이니 먼저 의지가 생긴 다음에 생각해야 할 일이다.