이타주의 프로그래머의 블로그
Posts tagged 소프트웨어 공학의 사실과 오해
소프트웨어 공학의 사실과 오해 10 – 연구, 마무리
Jan 21st
http://www.yes24.com/24/goods/1418676
연구
그런데, 소프트웨어 연구에는 문제가 있다. 평가적 연구(방법, 모델, 이론 등을 검토하는 연구)가 거의 없다는 것이다. 소프트웨어 공학 연구 유형의 스펙트럼에서 14%만이 평가적 연구다. 컴퓨터 과학 연구도 단지 11%만이 평가적 연구다. 이와는 대조적으로, 정보 시스템과 같은 다른 주요 컴퓨팅 분야에서는 평가적 연구가 67%에 이른다.
p.265
Potts(1993)은 이런 잘못된 연구 방법을 ‘연구한 다음 전파하는 방식’이라고 불렀는데, 이는 새로 연구한 접근방법의 제안과 이를 실무에 전파하기 위해 제시하는 중간에 평가가 없다는 것을 뜻한다. 나는 동일한 상황을 나타내는데 ‘옹호적 연구’란 용어를 사용했다. (…) Tichy와 그의 동료들(1995)은 컴퓨팅 분야에 대한 400개의 연구 논문을 검토해 소프트웨어 공학과 컴퓨터 과학에 대한 40~50%의 논문에 평가적 요소가 결여돼 있음을 알아냈다.
p.266
학계의 소프트웨어 연구자들은 너무도 자주 새로운 개념을 제안하고, 이 새로운 개념이 대단히 중요한 것인 양 과장하고, 이를 즉각적으로 실무에 적용하지 않는 이들을 비난한다. 정형방법도 그런 사례 중 하나다. 연구자들이 평가적 연구를 시작하기 전까지는 그 아이디어의 이득에 대해 잘못 인도했고, 또 잘못 인도할 것이다.
p.267
소프트웨어 업계에는 검증되지 않은 개념이나 기술이 과대 선전되고 있다는 얘기. 하지만 결국 은 탄환Siver Bullet은 발견되지 않았다.
마무리
책을 읽고나서 그 내용을 깨끗하게 잊어버리는 데까지 그리 많은 시간이 걸리지 않는다는 걸 알려준 책이다. -_-;; 한 번 정독을 하고 나서, 블로그에 올릴 부분을 고르려고 다시 정독을 하게 되었는데, 처음에 감탄하면서 읽은 내용에 다시 한 번 감탄하고 있는 나를 발견할 수 있었다.
블로그에 올리면서 다시 또 훑어보았으니 3번은 읽은 셈이다. 예전 같았으면 시간이 아까웠을텐데, 오히려 앞으로 좋은 책은 꼭 여러 번 읽어야겠다는 다짐을 하게 되었다. Debugging Applications를 쓴 존 로빈스 아저씨가 자기는 매년 Code Complete을 다시 읽는다고 했을때, 왜 그럴까 했었는데 이제는 좀 이해가 간다.
소프트웨어 공학의 사실과 오해 9 – 품질
Jan 19th
http://www.yes24.com/24/goods/1418676
품질
소프트웨어 분야에서 품질이란 좋은 품질의 소프트웨어 제품이 가져야하는 7개의 속성의 집합을 말한다. 이 집합은 이식성(portability), 신뢰성(reliability), 효율(efficiency), 사용 편의성(usability), 테스트 용이성(testability), 이해 용이성(understandability), 수정 용이성(modifiability)으로 구성된다.
p.233
사실 여기 나오는 속성 7개가 중요하다기 보다는 품질이란 여러 가지 속성의 집합이라는 사실이 요점인 것 같다.
이 속성에 우선순위를 매기는 것은 불가능하다. 즉, 소프트웨어 품질 속성을 모두 만족시키기 위한 시도에서 일반적인, 올바른 순서는 없는 것이다. 그러나 이 말이 속성에 순서를 매기면 안 된다는 뜻은 아니다. 어떤 프로젝트든 시작할 때부터 이 속성에 우선순위를 정해두는 것은 매우 중요하다.
p.234
이 일은 정말 중요하다! 그렇지 않으면 모두가 자기만의 우선순위를 가지고 개발을 하게 되므로 어떤 사람이 봤을 때는 좋은 코드인데 다른 사람이 봤을 때는 나쁜 코드가 될 수 있다. 리드 프로그래머와 같이 전체 품질에 책임을 지는 사람이 품질 속성에 우선순위를 매겨서 모두가 합의하게 되면, 매번 설계할 때마다 고민할 일도 줄어들고, 피어 리뷰에서 싸우는 일도 줄어들게 된다.
품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다.
p.238
사용자 만족 = 요구사항 충족 + 납기일 준수 + 적절한 비용 + 좋은 품질의 제품
p.238
사용자 만족의 정의에서 볼 수 있듯이 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성은 품질에 속하는 것이 아니다. 신뢰성 역시 품질의 한 가지 속성일 뿐인데, 신뢰성(오류 존재 여부)만을 품질이라고 생각하는 사람도 있다.
이런 개념이 정리되어 있지 않으면 “사용자가 만족하지 못하니 품질이 나쁜 것”이라고 단정하는 실수를 하기 쉽다.
오류는 항상 남아 있다. 심각한 오류를 제거하거나 최소화하는 것이 목표가 돼야 한다. (…) 심각한 오류는 반드시 소프트웨어 에서 제거돼야 한다. 다른 오류도 모두 제거하면 좋겠지만(예를 들면 문서화 오류, 중복된 코드 오류, 도달할 수 없는 경로 오류, 알고리즘에서 무시할 수 있을 정도의 수치상 오류 등), 항상 그럴 필요는 없다.
p.248
개인적으로 “리펙토링할 코드는 항상 남아 있다.”는 생각을 가지고 있는데, 이런 생각은 100% 완벽한 코드를 만들려는 강박관념을 없애주고, 좋지 못한 코드를 발견했을 때 “아, 이 소스코드는 엉망진창이군. 대충 필요한 코드나 추가해야지.”라고 생각하기 보다는, “소스코드란 영원히 부족한 법이지. 우선 이부분만 리펙토링 해볼까.”라고 생각하도록 도와준다.
얼마나 많은 사람들이 제품의 품질을 관리 쪽 책임이라 믿든, 소프트웨어 품질이란 주제에는 기술적 요소가 너무 많아 이를 관리만의 책임으로 미룰 수는 없다는 것이 내 대답이었다. 그리고는 거의 모든 품질 속성이 기술자만이 해결할 수 있는 상당히 기술적인 면을 갖고 있다는 것을 지적했다.
p.281
경영진은 ‘품질 제일’과 같은 슬로건을 걸고 ‘총체적 품질 관리(TQM, Total Quality Management)’와 같은 방법론을 사용하는 것이 소프트웨어 제품의 품질 달성을 위한 주요 접근방법이라 생각하는 것 같다. (…) 경영진은 한 손에는 동기부여와 방법론을 들고 다른 쪽 손에는 일정 압박이란 반 품질적 요소를 적용하려 한다. 두 가지를 모두 하는 것은 불가능하고, 대부분의 기술자들도 이를 알 만큼은 똑똑하다.
p.281, 282
소프트웨어 공학의 사실과 오해 8 – 유지보수
Jan 18th
http://www.yes24.com/24/goods/1418676
유지보수
유지보수는 보통 소프트웨어 비용의 40~80%(평균 60%)를 차지한다. 따라서 유지보수는 소프트웨어 생명주기 중 가장 중요한 단계일 것이다.
p.209
몇 년 전에 신입사원을 가르치면서, “이렇게 하면 나중에 수정하기가 어려우니까 저렇게 하는게 좋다.”라는 식으로 얘기를 했더니 “팀장님은 나중에 수정하는 것을 굉장히 신경쓰시는 것 같아요.”라는 반응을 보였다. 내가 너무 당연하다고 생각하던 걸 신기하다는 듯이 얘기해서 어리둥절 했었는데, 그 때 이런 통계 자료가 있었다면 좋았을 걸.. 이라는 생각이 든다.
소프트웨 유지보수 비용에서 약 60%는 개선 작업에 쓰이는 비용이다. 오류 정정은 약 17% 정도다. 따라서, 소프트웨어 유지보수는 기존 소프트웨어를 보수만 하는 것이 아니라 새로운 기능을 추가할 때도 많다.
p.213
자, 60+17=77%다. 유지보수 비용의 나머지는 어디로 갔나? 18%는 환경이 변하더라도 소프트웨어가 계속 작동할 수 있도록 하는 적응성 유지보수(adaptive maintenance)라 불리는 것에 들어간다. -중략- 그런데 유지보수 비용의 나머지 5%는 뭘까? 이럴 때 항상 나오는 ‘기타’다. 여기에는 소프트웨어를 더욱 유지보수하기 편하게 만드는 작업도 포함된다. 이런 작업을 예전엔 예방적 유지보수(preventive maintenance)라 했고 최근에는 이런 활동을 표현하는데 리팩토링(Refactoring, Fowler 1999)이란 용어가 쓰인다.
p.214, 215
유지보수는 문제가 아니라 해결책이다. -중략- 유지보수는 “우리는 이런 것을 구축했지만 지금 보니 약간 다른 것을 구축했어야 한다.”와 같은 문제를 해결할 수 있는 유일한 방법이다.
p.217
유지보수는 귀찮은 문제를 해결하는 업무이고 그래서 안할수록 좋다라는 느낌이 있었는데, 사실은 신규 개발과 거의 차이가 없는 솔루션 개발 업무라는 것을 배웠다.
소프트웨어 유지보수 생명주기의 각 단계는 개발 생명주기와 거의 같다. 문제에 대한 요구사항을 분석하고, 수정 또는 개선 작업을 한다. 기존 시스템의 설계 컨텍스트 안에서 솔루션을 설계한다. 솔루션을 코딩하고 기존 시스템에 맞춰 넣는다. 코딩된 솔루션을 테스트하면서, 새로 변경한 것이 제대로 동작하는지, 예전에 제대로 작동하던 것들에 영향을 끼쳐 문제를 일으키지는 않는지 확인하다. 그리고 나서, 개선된 부분을 기존 시스템에 반영하고 계속 유지보수한다.
p.219
점진적인 개발 방식을 사용하면 지속적으로 작은 릴리즈를 하고 사용자의 피드백을 받아 개선하게 되니까, 점진적인 유지보수라고 부를 수도 있지 않을까? 처음에 돌고래 스몰토크를 써봤을 때 받은 인상도 비슷한데, 보통의 개발은 아무것도 없는 상태에서 기능을 생성해나가는 느낌이라면, 돌고래 스몰토크에서는 이미 잘 돌아가는 시스템을 리펙토링 해서 기능을 추가해나가는 느낌이었다.
하지만 유지보수 단계에서 “기존 시스템의 설계 컨텍스트 안에서 솔루션을 설계한다.”라는 것이 가장 큰 차이점인데 이는 생각보다 훨씬 어려운 작업이라고 한다. 그 이유는,
설계로 전환하는 시점에서 요구사항의 폭발적 증가, 대부분의 문제에서 설계 솔루션이 하나만 있는 것은 아니라는 사실, 설계는 복잡하고 반복적인 과정이라는 사실, 문제의 복잡성이 25% 증가하면 솔루션의 복잡성은 100% 증가한다는 사실. 이 모든 사실을 조합하면, 설계는 어렵고, 지적이며, 창조적인 작업이란 것을 알 수 있다. 여기서 말하려는 것은 역설계(undesign, 이미 구축된 시스템의 설계를 역공학으로 알아내는 것)라 부를만한 것으로, 이는 최소한 원래의 설계 작업만큼 복잡하다.
p.220
유지보수를 귀찮은 문제를 고치는 하찮은 작업으로 보기 쉽지만, 위의 증거들을 통해서 중요한 솔루션 개발 작업이며, 신규 개발에 필요한 것 이상의 높은 기술을 요구하는 작업이란 사실을 알 수 있다.
하지만 현실에서는 유지보수를 하찮은 작업으로 보는 경우가 많으므로 (담당자 스스로도!) 신입사원이나 경력이 적은 개발자에게 유지보수 업무를 맡기고, 실력이 좋은 개발자는 신규 개발에 투입되는 일이 흔하다. 그렇다보니 초기의 설계를 충분히 이해하지 못한 상태에서 코드의 수정이 이루어지고, 코드는 점점 더 엉망이 되어간다. 그러면 다시 새로운 시스템의 신규 개발이 시작되고 실력있는 사람들은 이 일에 투입된다. 기존에 유지보수를 하던 인력은 이 “실력있는 사람”들이 만든 또 다른 시스템을 유지보수 하게 된다. 불행하게도 여태까지의 내 경험과 일치하는 내용이다.
더 좋은 소프트웨어 공학 기술로 개발하면 더 많은(더 적은 게 아니라) 유지보수가 필요하다. -중략- 이런 시스템은 더 많은 수정이 가해지기 때문에 다른 시스템보다 더 오래 유지된다. 그리고 이런 잘 구축된 시스템은 개선하기가 쉽기 때문에 더 많은 수정이 가해진다.
p.226
이 사실은 “유지보수는 문제가 아니라 해결책이다.”라는 사실에 대한 흥미로운 예다. 유지보수 활동을 솔루션으로 본다면, 더 많은 작업을 할수록 좋다고 생각할 수 있다. 그러나 유지보수를 문제로 보는 시각에 묶여 있으면, 유지보수 활동이 늘어나는 것을 좋게 볼 수 있는 방법이 없다.
p.227
소프트웨어 공학의 사실과 오해 7 – 검토와 검사
Jan 14th
http://www.yes24.com/24/goods/1418676
검토와 검사
비약에 가까운 기법이 하나 있는데, 아이러니하게도 이 기법은 소프트웨어 오류 제거 활동에서 제외되어 한 구석에 처박혀 있다. 엄격한 검사가 그것으로, 소프트웨어에 포함된 오류를 찾기 위해 노력을 쏟는 이 기법은 거의 비약이라 할 수 있다. 연구 조사를 거듭한 결과 검사는 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%를 발견할 수 있다는 것이 밝혀졌다.
p.191
그런데도 불구하고 검토와 검사가 CASE 도구나 여러 방법론과 같은 더 못한 것들도 받던 찬사를 받지 못하는 이유는 아래의 4가지.
- 검사로 돈을 버는 메이저 벤더는 거의 없다.
- 검사에는 새로운 것도 없고 따라서 시장성도 없다.
- 검사는 소프트웨어 생명주기의 뒤쪽 단계에 있는 보이지 않는 부분으로 간주된다.
- 검사는 효율적이긴 하지만, 녹초가 될 정도로 정신을 집중해야 하는 고된 작업이다.
대부분의 방법론이나 프랙티스의 유행의 배경에는 해당 제품으로 돈을 버는 메이저 벤더가 있어왔다는 것이 이책의 일관된 주장이다. 실제로 은 탄환Silver Bullet이란 없기 때문에 애초에 유행할 것이 없지만, 과대선전자들에 의해 근거없는 유행이 생겨난다는 것.
제품의 출시후에 어떤 일이 있었는지 숙고하거나 앞으로 어떻게 개선할 수 있을지에 대해 기록하는 회고를 시행하는 조직이 거의 없다는 얘기에 이어서 아래의 내용이 나온다.
그 결과 소프트웨어 프로젝트에서 배운 모든 교훈은 버려지거나, 프로젝트가 끝날 때 바람과 함께 날아가 버린다. 왜 그럴까? 소프트웨어 분야의 광폭한 일정으로 인해, 어제 프로젝트에서 일하던 프로그래머들이 이미 내일 프로젝트로 흩어져 배치돼 버리기 때문이다. 그리고 거기서는 새로운 일정에 묶여 몇 달 전에 어떤 일이 있었는지 생각할 겨를도 없다.
p.200
결국 소프트웨어 분야는 한 자리에 처박혀 매 프로젝트마다 같은 실수를 반복하고 있고. 소프트웨어 분야의 지혜Wisdom는 증가하지 않는다는 얘기.
어떤 문제에 대한 올바른, 최적의 솔루션이 딱 하나만 있는 경우는 거의 없다고 했던 것을 상기하기 바란다. 솔루션을 검토할 때 다른 개발자가 선택한 방법의 관점에서 검토하는 것은 자신의 방법 관점에서 검토하는 것보다 어렵다. 다른 사람의 신발을 신고 먼 길을 걷는 것은 쉬운 일이 아니다.
p.205
동료 검토Peer Review에는 기술적 측면과 사회적 측면을 모두 중시해야 하는데, 위와 같이 기술적 검토 작업을 훌륭히 하는데 필요한 ‘집중’으로 인해 검토의 사회적 측면에 대한 주의가 감소한다고 한다.
엄격함을 달성하기 위한 집중 때문에 사회적 문제를 해결하기 위해 남겨둔 에너지까지 모두 소모돼 버린다. 따라서 검토기간 동안의 사회적 문제는 심각해질 수 있다. 비자아적 프로그래밍(egoless programming)을 부르짖지만, 우리는 대부분 자신이 작업하는 제품에 이성과 감정을 투영하게 되고, 이로 인해 다른 사람이 우리의 작업을 검토하면 쉽게 상처받는다. -중략- 모든 자아가 위태로워지고 사회적 방어 메커니즘이 감소한 상태에서, 사회학적 폭발을 초래하는 것은 그리 오래 걸리지 않는다.
p.206
동료 검토 하면서 얼굴 붉히는 경험은 다들 있을 것 같다. 잘 먹히는 해결책을 제시할 수 있으면 좋겠지만, 기술적 측면과 사회적 측면에 모두 주의를 기울여야 한다는 사실이라도 업계에 널리 퍼졌으면 좋겠다. 문제가 인식되면 해결책이 도출되는 것은 시간문제가 아닐까.
개인적으로는 저자 워크숍 방식을 코드 리뷰에 사용해보고 싶은 바램이 있다. (해보신 분 있으실지도)
IBM developerWorks – 저자 워크샵 (김창준님)http://www.ibm.com/developerworks/kr/library/dwclm/20081230/
소프트웨어 공학의 사실과 오해 6 – 테스트
Jan 13th
http://www.yes24.com/24/goods/1418676
테스트
연구에 따르면, 프로그래머가 모든 코드를 완전히 테스트했다고 말할 때, 보통 55~60%의 로직 경로만이 실제로 테스트된 것이라 한다. 이는 소프트웨어 제품의 복잡성을 반증하는 것이기도 하고, 소프트웨어를 작성한 사람조차도 그들이 작성한 것에 대해 완전히 이해하지 못함을 보이는 것이기도 하다.
p.172
여기서 알 수 있는 것은, 수많은 종류의 테스트 방법이 존재하지만 소프트웨어 제품의 복잡성 때문에 완벽한 테스트는 불가능하다는 것이다. 이 때문에 (1)테스트를 수행하는 데 있어 타협할 수 밖에 없고, 적절히 선택해 타협하는 것이 매우 중요하며, (2)대부분의 주요 소프트웨어 제품이 오류를 포함한 채 출시되는 것 또한 놀랄만한 일이 아니다(순진한 사람들만이 오류 없는 소프트웨어를 기대한다).
p.173
많은 소프트웨어 전문가들이 오류 없는 소프트웨어를 만드는 것이 가능하다고 주장하며 이를 달성하지 못한 회사나 조직을 비난하지만, 이번 사실에서 명확히 알 수 있듯이 그 영광된 목표는 단지 아주 작은 규모의 소프트웨어 프로젝트에서나 가능할 것이다. 이제, 오류 없는 소프트웨어란 불가능한 목표는 포기하고, 매우 심각한 오류가 없는 소프트웨어 제작과 같은, 좀더 현실적이고 실현 가능한 목표에 집중하는 것이 중요하다.
p.174
어느 정도 규모가 있는 C++ 프로젝트에 유닛테스트를 적용해본 것은 작년이 처음이었는데, 왜 55~60%의 로직 경로만이 테스트 되는지 이해할 수 있을 것 같다. 제품 수준의 코드에는 인자의 유효성 체크, 상태의 유효성 체크, 실패에 대한 체크 등으로 엄청나게 많은 분기가 발생하는데 이런 예외 상황을 완벽하게 테스트하는 것은 비용대비 효율이 떨어지기 때문이다. 높은 테스트 커버리지는 반드시 달성해야만 하는 목표라기 보다는, 프로젝트의 여러 목표 중에 하나가 되어서 우선도를 따져보는 것이 맞는 것 같다. 적당한 테스트 커버리지에 대해서는 지난 번 포스팅 어느 정도의 테스트 커버리지가 필요할까를 참조.
100%의 테스트 커버리지가 가능하다 하더라도, 이는 충분한 테스트 기준이 아니다. 대략 소프트웨어 결함의 35%는 누락된 로직 경로에서, 40%는 로직 경로의 특정 조합을 실행할 때 나타난다. 이런 것들은 100% 커버리지로도 잡히지 않을 것이다.
p.176
100%의 구조적 커버리지가 발견할 수 있는 것은 단지 25%의 오류라는 의미다. 저자가 가진 오류 데이타베이스로부터 산출한 비율이라는 점도 감안하자.
소프트웨어 테스트 도구가 널리 사용되지 않는 데는 세 가지 주요 요인이 있다. 1. 소프트웨어 분야의 경영진과 학계는 모두 앞쪽 단계를 훨씬 더 중요하게 보이도록 만들었다. -중략- 2. 뒤쪽 단계의 작업은 기술적으로 너저분하다. -중략- 3. 생명주기의 뒤쪽 단계에는 일정 압박이 심하다. -중략-
p.181, 182
소프트웨어 업계는 요구분석, 설계, 구현을 지나서 테스트에 대한 관심이 높아지고 있는 것 같다. 앞쪽의 단계에서 은 탄환Siver Bullet을 찾지 못해서 자꾸만 뒤쪽 단계에서 기회를 찾으려 이동한다는 얘기도 있지만, 소프트웨어 분야의 모든 행위에 대해서 한 번씩 조명을 하고, 쓸데없는 미신이나 착각, 오해를 없앨 수 있었으면 하는 바램이다.
소프트웨어 공학의 사실과 오해 5 – 설계
Jan 7th
http://www.yes24.com/24/goods/1418676
설계
요구사항을 설계로 옮겨갈 때 솔루션 프로세스의 복잡성 때문에 ‘파생 요구사항’(특정 설계 솔루션에 대한 요구사항)이 급증한다. 이런 설계상의 요구사항은 종종 원래의 요구사항보다 50배 넘게 늘기도 한다.
- 중략 -
모두들 요구사항 추적 용이성(traceability)이 바람직하다고 생각하지만 (부분적으로는) 요구사항의 폭발적 증가 때문이 이를 실현하기는 어렵다.p.145, 146
현재 진행중인 프로젝트의 프로덕트 백로그(요구사항 리스트 비슷한 것)를 사용자 관점의 것과 개발자 관점의 것으로 2개 관리하자라는 말을 들었을 때, 이 얘기를 하면서 반대했던 기억이 있다. 개발자 관점의 것은 사용자 관점의 것보다 50배나 많아질 수도 있으니까.
소프트웨어 문제에 대해 최상의 솔루션이 하나인 경우는 거의 없다. – 중략 – 문제가 정의됐을 때 훌륭한 설계자들이 모두 동일한 최상의 설계 솔루션을 제시하는 경우는 거의 없다. (“최고의 설계자들이 모인 방에서 두 명의 설계자가 동의한다면 그게 다수 의견이다.”라는 말은 소프트웨어 분야에서 내가 좋아하는 인용구 중 하나다.)
p.150
전적으로 동의하지만, 동시에 이 얘기가 오해를 불러일으킨다고 생각한다. 좋은 설계를 찾기위한 노력을 게을리 하는데 좋은 구실이 되기 때문이다. 하지만 분명히 좋은 솔루션과 나쁜 솔루션이 존재하므로 더 좋은 솔루션을 찾기 위한 노력은 계속되어야 한다. 또 다른 오해는 몇 가지 설계를 두고 논쟁이 생겼을 때 어차피 정답은 없다는 이유로 토론을 회피하는 것이다. 하지만 이 경우에 논쟁의 대상이 되는 몇 가지 설계가 최상의 솔루션들인 경우는 거의 없으며 기본적인 설계 원칙들도 지키지 못하는 경우가 많다. 한 마디로 나같은 보통의 개발자에게는 해당되지 않는 얘기다.
전문 설계자들은 설계 작업에서 핵심을 파악할 때 경험적, 시행착오적 접근방법을 사용한다는 것이다. 관련된 문제에 대한 예전의 설계를 기반으로 해서 설계 솔루션을 하나 생각하고, 마음속으로 이 솔루션에 대표적인 데이터를 조금 넣어보고, 이 데이터에 대한 작동을 모의실험한 다음, 이 솔루션에서 데이터에 대한 출력을 뽑아낸다. – 중략 – 후보 솔루션을 약간 수정해 확인된 문제를 제거하고, 샘플 데이터를 다시 적용해본다. 출력이 맞게 나올 때까지 이 과정을 반복한다.
p.154, 155
다들 이런 경험을 가지고 있을 것 같다. 책에서는 이런 설계 방식을 ‘편의적’ 설계라고 부르는데, 이런 연구 결과를 토대로 다음과 같은 결론을 도출한다.
설계는 예측 가능한, 구조화할 수 있는, 규격화할 수 있는 프로세스와는 거리가 멀고, 너저분하고 시행착오적인 것임을 알 수 있다. 그리고 기억해야 할 것은, 이 연구결과는 최고의 설계자들을 조사해서 얻은 것이라는 점이다. 이보다 못한 설계자들은 훨씬 더 너저분한 프로세스로 작업할 것임은 쉽게 상상할 수 있다.
p.155
“너저분한 프로세스”에 가슴이 아프다. ^^;;
복잡한 프로세스로 인해 최적의 설계는 보통 불가능하므로, 우리는 ‘만족스러운’ 솔루션을 위해 노력해야 한다. 만족스러운(최적이 아니라) 솔루션은 훌륭한 설계에 대한 조건을 충분히 만족시켜, 그 접근방법을 선택해 작업을 계속 하는 데 따르는 위험을 감수할만한 가치가 있는 것을 의미한다(최적의 설계는 불가능하거나 비용대비 효율이 낮다는 전제하에)
p.156
현실과 적절하게 타협할 필요가 있다라는 말로 이해할 수 있는데, 나같이 “만족스러운 솔루션”을 만드는 것도 벅찬 사람에게는 해당되지 않는 얘기다.
소프트웨어 공학의 사실과 오해 4 – 복잡성, 요구사항
Jan 5th
http://www.yes24.com/24/goods/1418676
복잡성
여러분이 이 책을 읽고 아무것도 기억하지 못하더라도 이것만은 기억하기 바란다. 문제의 복잡성이 25% 증가하면 소프트웨어 솔루션의 복잡성은 100% 증가한다. 이 문제를 극복하기 위한 어떤 해결책도 없다는 것 또한 기억하기 바란다. 소프트웨어 솔루션은 복잡한데, 그게 그 녀석의 타고난 본성이다.
p.118
절망적인 얘기 같지만 한 가지 분야로서 존재하려면 복잡성은 필수인 것 같다. 복잡하지 않으면 답이 바로 나오고, 답이 이미 나왔다면 이렇게 많은 사람들이 연구하고, 매번 새로운 솔루션을 개발할 필요는 없지 않을까.
누락된 요구사항
누락된 요구사항은 가장 수정하기 힘든 오류다. – 중략 – 요구사항이 없으면 명세서(specification)에도 나타나지 않을 테고, 명세서로부터 나오는 검토나 검사(inspection)에서도 확인되지 않을 것이고, 요구사항을 만족하는지 검증하기 위한 테스트 케이스도 작성되지 않을 것이다. 따라서 요구사항 누락은 가장 기본적인 오류 제거 방법에서 발견되지 않는다.
p.139, 141
책을 읽기 전에는 한 번도 생각해 본적이 없던 문제다. 테스트 커버리지가 100%가 되어도 누락된 요구사항은 테스트가 안되니 말이다. -_-;; 아래는 저자가 근무하던 우주 항공사의 오류 데이터를 분석한 결과다.
제거하기 어려운 오류 중 가장 눈에 띄는 것은 내가 누락된 코딩 로직 오류라 부르던 것이었다. 이는 제거하기 어려운 오류 카테고리 중 가장 두드러진 것으로 30%를 차지했다. 그 다음으로 중요한 카테고리는 회귀 오류(regression error)로 8.5%를 차지해 30%보다 훨씬 적었다. 제거하기 어려운 소프트웨어 오류 중 세 번째 카테고리는 소프트웨어 오류가 아니라 문서화 오류(8%)라는 것이 흥미롭다.
p.143
여기서 “제거하기 어려운 오류”라는 것은 모든 테스트 과정을 거쳐서 출시된 제품에 여전히 남아있는 오류를 의미한다.
소프트웨어 공학의 사실과 오해 3 – 재사용
Dec 4th
http://www.yes24.com/24/goods/1418676
재사용
소규모 재사용(서브루틴 라이브러리)은 거의 50년 전부터 시작되어 잘 해결된 문제라고 한다. 다시 말해 유효성이 검증되었다는 얘기. 다만 여기서의 논쟁은 컴퓨터 분야의 많은 사람들이 재사용을 새로운 아이디어라고 생각해서 지나치게 열광한다는 점. (p.91)
반면에 대규모 재사용(컴포넌트)은 중요하고 바람직한 것이라 생각하지만, 거의 대부분의 문제가 해결되지 않은채 남아있다고 한다. 다시 말해 유효성이 검증되지 않았다는 얘기. 이는 소프트웨어의 다양성에 기인한 것으로 단순히 너무 어려워서 풀 수 없는 문제다.(p.95)
대규모 재사용은 한정된 범위의 애플리케이션 도메인에 적용한다면 성공할 가능성이 충분히 있지만, 여러 프로젝트나 여러 도메인에 걸쳐 적용하려 한다면 성공할 가능성이 거의 없다(McBreen 2002)
p.98
인정하기는 싫지만 이 말이 사실이라는 걸 부인할 수가 없다. 라이브러리는 더 많은 기능을 제공할수록, 더 많은 제약을 가질 수 밖에 없다. 즉 범용성이 줄어드는 것. 그래서 라이브러리를 가능한 작은 단위로 나누는 것이 중요하다. 각 라이브러리 당 제공하는 기능이 줄어들면 제약도 함께 줄어드므로 범용성이 늘어난다.
재사용에 대한 두 가지 ’3의 법칙’이 있다. (1)재사용 가능 컴포넌트를 만드는 것은 단일 목적의 컴포넌트를 만드는 것보다 세배는 어렵다. (2)컴포넌트는 재사용 라이브러리로 인정할 만큼 일반적이라 생각하기 전에 서로 다른 세 가지 애플리케이션에 적용해봐야 한다.
p.100
대부분의 경력이 공통 라이브러리 제작이었던 나로서도 상당히 공감이 되는 얘기. 작년에 라이브러리가 아닌 서비스용 애플리케이션을 만들 기회가 있었는데 다른 애플리케이션을 신경 쓸 것도 없고, 작업중인 애플리케이션이 잘 동작하는지만 보장하면 되므로 좀 더 수월하다는 느낌을 받았다. 공통 라이브러리는 코드 한 줄을 바꾸더라도 신경 쓸 것이 많고, 모든 애플리케이션에서 문제가 없는지 확인하기가 어렵다.
디자인 패턴 재사용은 코드 재사용의 본질적인 문제에 대한 해결책 중 하나다.
p.111
설계를 재사용하는 행위를 칭찬하는 것. 저자는 아주 오래전부터 해오던 디자인의 재사용에 디자인 패턴이라는 이름을 붙여서 유명해지고, 사람들이 열광하는 것에 대해서는 회의적인 관점을 가지고 있다.
디자인 패턴 개념은 널리 받아들여진다. 지속적으로 확대되고 있는 패턴의 영역을 조사하고 알리는 데 힘쓰는 열정적인 학회도 있다. 실무자들은 자신들에게 익숙하지 않은 새로운 패턴뿐 아니라 패턴의 체계와 구조를 제공한다는 측면에서 그런 활동을 높이 평가한다.
그러나 이런 활동이 실제로 효과가 있는지는 측정하기 어렵다. 일반적인 애플리케이션 프로그램에서 얼마나 많은 부분이 정형화된 패턴을 기반으로 했는지에 대한 연구는 내가 아는 한 없다.p.114
동의하기는 힘들지만, 적어도 귀 얇은 나에게 저자의 비판적인 자세는 너무 존경스럽다.
소프트웨어 공학의 사실과 오해 2 – 추정
Dec 3rd
http://www.yes24.com/24/goods/1418676
추정
프로젝트가 폭주하는 가장 흔한 원인 두 가지 중 하나가 형편없는 추정이라고 한다. (다른 하나는 불안정한 요구사항)
소프트웨어 공학 분야에서는 이런 폭주의 원인이 무엇일까에 대한 질문이 자주 있었다. 이 질문에 대한 대답은, 답하는 사람의 개인적인 주관에 기초하는 경우가 많았다. 어떤 사람들은 적절한 방법론의 부재가 폭주를 야기한다고 말한다. 이런 사람들은 보통 방법론을 파는 사람들이다. 어떤 사람들은 좋은 도구가 없기 때문이라고 말한다(이런 사람들은 무엇으로 먹고 사는 사람들일까?). 어떤 사람들은 프로그래머에게 훈련과 주의가 부족하기 때문이라고 말한다(보통 이런 사람들이 옹호하고, 판매하는 방법론들을 사용하기 위해서는 많은 훈련이 필요하다). 각자 그들이 지지하는 개념을 제시하며 그 개념의 부족이 프로젝트 폭주의 원인이라 주장한다.
p.60
많은 주장들이 결국은 자기들 돈벌려고 하는 얘기라는 것. 그나마 아무에게도 이익을 줄 것 같지 않은 객관적인 대답이 “형편없는 추정”과 “불안정한 요구사항”이란다.
마지막으로 다시 한번 상식적으로 생각해보자. 우리가 앞에서 논한 것처럼 부적절한 시점에 부적절한 사람에 의해 만들어지고 잘 변경되지 않는, 정말 그렇게도 부적절한 소프트웨어 추정이라면, 상대적으로 덜 중요하게 다뤄질 것이라 생각되지 않는가? 틀렸다! 사실 소프트웨어 프로젝트는 거의 항상 일정에 의해 관리된다. 그 때문에 적어도 고위 경영진은 소프트웨어(개발)에서 일정을 가장 중요한 요소로 생각한다.
p.76
두번째 문장에 엄청난 함축이 있다. 우선 추정은 부적절한 시점에 수행되고 있다. 보통 프로젝트를 시작할때 소프트웨어 추정을 하는데, 이 때는 풀고자 하는 문제가 무엇인지도 명확하지 않은 단계이다! 무엇을 만들지도 모르면서 비용과 시간을 추정하는 셈이다.(p.66)
다음으로 추정은 부적절한 사람에 의해 수행되고 있다. 대부분의 경우 소프트웨어 추정은 소프트웨어 제품을 원하는 사람들, 즉 경영진이나 마케팅, 고객, 사용자들에 의해 이루어진다(p.69)
마지막으로 이렇게 잘못된 추정은 프로젝트가 진행되면서 거의 조정되지 않는다.(p.73)
일정에 의한 관리대신에 사용할 수 있는 방법이 몇 가지 제시되고 있다.(p.77)
- 제품에 의한 관리 : 사용 가능한 정도, 어느 정도 작동하는가에 의해 프로젝트의 성공/실패 판단
- 이슈에 의한 관리 : 프로젝트 도중에 발생하는 이슈를 얼마나 잘 해결하는 가에 의해 프로젝트의 성공/실패 판단
- 위험요소에 의한 관리 : 위험요소가 적절히 해결되었는지를 통해 프로젝트의 성공/실패 판단
- 비즈니스 목표에 의한 관리 : 비지니스 능률을 얼마나 향상시켰는가에 따라 프로젝트의 성공/실패 판단
- 품질에 의한 관리 : 제품의 품질 속성을 얼마나 많이 달성했는가에 따라 프로젝트의 성공/실패 판단
솔직히 일정에 의한 관리 방식을 버린다는 게 막막하기만 하지만, 저번 글에서 얘기한 것처럼, 단순히 가로등 밑이 밝다는 이유로 가로등 밑에서 열쇠를 찾고 있었던 것은 아닌지 생각해 봐야겠다.
소프트웨어 공학의 사실과 오해 1 – 작업 환경
Dec 1st
http://www.yes24.com/24/goods/1418676
작업 환경
유명한 책인데 이제야 기회가 되어서 읽어봤다. 역시나 개발자면 누구나 읽어야 할 필독서라는 생각이 든다. 다시 한 번 훑어보면서 감명받은 부분을 정리하는 중.
“단단한(hard) 것이 부드러운(soft) 것을 몰아낸다.”는 옛 말이 있다. 즉 정확하게 측정 가능한(단단한) 것은 그렇지 못한(부드러운) 것에 대해 관심을 가지지 못하도록 하는 경향이 있다. 이 자명한 논리가 소프트웨어 분야에만 국한되는 것은 아니지만, 여기서는 특히 의미가 있는 것 같다. 사무실 공간은 측정하기 쉽다. 생산성 이득은 측정하기 어렵다. 어떤 것이 이기겠는가?
p.45
충분한 사무실 공간이 업무 효율을 높인다는 점을 대부분 알고 있지만, 사무실 공간을 할당할 때가 되면 가능한 많은 자리를 만드려는 생각으로 되돌아간다면서 나온 얘기다.
내 생각에는 일정과 품질도 비슷한 관계인 것 같다. 일정은 측정하기 쉽지만 품질은 측정하기 어렵기 때문에, ‘품질을 만족했는가?’ 보다는 ‘일정내에 마쳤는가?’와 같은 기준이 주로 사용되고 있다. 열쇠는 다른 곳에서 잃어버리고, 가로등 밑이 밝다는 이유만으로 가로등 밑에서 열쇠를 찾고 있는 바보이야기(p.33)가 남의 이야기가 아니다. -_-;;
Recent Comments