소프트웨어 공학의 사실과 오해 6 – 테스트
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을 찾지 못해서 자꾸만 뒤쪽 단계에서 기회를 찾으려 이동한다는 얘기도 있지만, 소프트웨어 분야의 모든 행위에 대해서 한 번씩 조명을 하고, 쓸데없는 미신이나 착각, 오해를 없앨 수 있었으면 하는 바램이다.
평화로운 전사
http://www.yes24.com/24/goods/2655406
"'마음'이란 안절부절 못하는 정신의 가짜 투영이야. 그것은 잠재의식에서 표면으로 떠오르는, 통제되지 않는 닥치는 대로의 모든 생각을 포함하고 있네. 의식이 마음은 아냐. 자각도 마음은 아냐. 주의력도 마음은 아냐. 마음은 장애물이야. 상태를 악화시키는. 그것은 일종의 인류 진화상의 실수라고 할 수 있네. 인간사의 근본적인 약점이야. 마음은 아무 쓸모가 없어." -중략- 그러나 수학 문제나 전화번호를 생각하는 걸 멈출 수 없을 때, 또는 자네가 의도하지 않았는데도 괴로운 생각이나 기억들이 떠오를 때는 자네의 두뇌가 일하는 것이 아니라 마음이 방황하는 거라네. p.78, 79
"이게 핵심이야. 명상은 두 개의 과정이 동시에 이뤄지지. 하나는 통찰. 이는 일어나는 것에 주의를 기울인다는 뜻이야. 나머지는 항복. 일어나는 생각에 대한 집착을 놓아 버리는 것이지. 이렇게 해서 마음에서 벗어나는 거라네." p.113
"절제? 그건 수준 이하요, 두려움이고, 혼란을 숨기는 것에 불과해. 악마의 딜레마지. 하는 것도 아니고 안 하는 것도 아냐. 아무도 행복하게 해 줄 수 없는, 비틀거리는 타협일 뿐이야. 절제는 무미건조하고 변명을 일삼는 이들, 증언대에 서기 두려워 주변부에만 머무는 사람들을 위한 거지. 그건 웃거나 우는 걸 겁내는 사람들, 살거나 죽는 걸 겁내는 이들의 몫이야. 절제란 악마가 직접 달인, '미적지근한 차'라고!" p.166, 167
"과거를 바꾸기 위해 자네가 할 수 있는 건 아무것도 없어. 그리고 자네가 기대하거나 원하는 대로 미래가 딱 맞춰서 오진 않을 거네. 전사는 과거에도 없었고 미래에도 없을 걸세. 전사는 지금, 여기 있네. 슬픔이나 두려움, 분노, 후회 그리고 죄책감, 자네가 부러워하는 것이나 앞으로의 계획이나 갈망은 모두 과거나 미래에 존재한다네." p.214
"바보는 욕망이 채워지면 '행복'하지만, 전사는 아무 이유 없이 행복하다네. 그래서 행복이 궁극의 훈련이 되는 거라네. 행복은 내가 가르쳐 준 그 모든 것 위에 있어. 행복은 단지 자네가 느낄 수 있는 그 무언가가 아냐. 그건 자네 그 자체라네." p.247
찾을 필요가 없다. 성취란 아무 곳에도 데려다 주지 않는다. 아무 차이가 없으니 지금 그저 행복하라! 모두 하나이기 때문에 사랑은 이 세상의 유일한 실재이다. 그리고 유일한 법이라면 역설, 유머 그리고 변화다. 아무 문제도 없고 없어 왔고 앞으로도 결코 없을 것이다. 당신의 싸움을 놓아 버리고, 마음을 내버려 두라. 걱정을 멀리 던지고 세상 속에서 편히 쉬라. 삶에 저항할 필요가 없으니 그저 최선을 다하라. 눈을 뜨고 각자 생각했던 것 이상인 자신을 바라보라. 당신이 세상이고 당신이 우주다. 당신은 당신 자신이자 그 밖의 모든 이들이기도 하다! 이 모두가 신의 놀라운 각본이다. 일어나라, 일어나 유머 감각을 되찾으라. 걱정 말라, 당신은 이미 자유롭다! p.257, 258
소프트웨어 공학의 사실과 오해 5 – 설계
http://www.yes24.com/24/goods/1418676
설계
요구사항을 설계로 옮겨갈 때 솔루션 프로세스의 복잡성 때문에 ‘파생 요구사항’(특정 설계 솔루션에 대한 요구사항)이 급증한다. 이런 설계상의 요구사항은 종종 원래의 요구사항보다 50배 넘게 늘기도 한다.
- 중략 -
모두들 요구사항 추적 용이성(traceability)이 바람직하다고 생각하지만 (부분적으로는) 요구사항의 폭발적 증가 때문이 이를 실현하기는 어렵다.p.145, 146
현재 진행중인 프로젝트의 프로덕트 백로그(요구사항 리스트 비슷한 것)를 사용자 관점의 것과 개발자 관점의 것으로 2개 관리하자라는 말을 들었을 때, 이 얘기를 하면서 반대했던 기억이 있다. 개발자 관점의 것은 사용자 관점의 것보다 50배나 많아질 수도 있으니까.
소프트웨어 문제에 대해 최상의 솔루션이 하나인 경우는 거의 없다. – 중략 – 문제가 정의됐을 때 훌륭한 설계자들이 모두 동일한 최상의 설계 솔루션을 제시하는 경우는 거의 없다. (“최고의 설계자들이 모인 방에서 두 명의 설계자가 동의한다면 그게 다수 의견이다.”라는 말은 소프트웨어 분야에서 내가 좋아하는 인용구 중 하나다.)
p.150
전적으로 동의하지만, 동시에 이 얘기가 오해를 불러일으킨다고 생각한다. 좋은 설계를 찾기위한 노력을 게을리 하는데 좋은 구실이 되기 때문이다. 하지만 분명히 좋은 솔루션과 나쁜 솔루션이 존재하므로 더 좋은 솔루션을 찾기 위한 노력은 계속되어야 한다. 또 다른 오해는 몇 가지 설계를 두고 논쟁이 생겼을 때 어차피 정답은 없다는 이유로 토론을 회피하는 것이다. 하지만 이 경우에 논쟁의 대상이 되는 몇 가지 설계가 최상의 솔루션들인 경우는 거의 없으며 기본적인 설계 원칙들도 지키지 못하는 경우가 많다. 한 마디로 나같은 보통의 개발자에게는 해당되지 않는 얘기다.
전문 설계자들은 설계 작업에서 핵심을 파악할 때 경험적, 시행착오적 접근방법을 사용한다는 것이다. 관련된 문제에 대한 예전의 설계를 기반으로 해서 설계 솔루션을 하나 생각하고, 마음속으로 이 솔루션에 대표적인 데이터를 조금 넣어보고, 이 데이터에 대한 작동을 모의실험한 다음, 이 솔루션에서 데이터에 대한 출력을 뽑아낸다. – 중략 – 후보 솔루션을 약간 수정해 확인된 문제를 제거하고, 샘플 데이터를 다시 적용해본다. 출력이 맞게 나올 때까지 이 과정을 반복한다.
p.154, 155
다들 이런 경험을 가지고 있을 것 같다. 책에서는 이런 설계 방식을 ‘편의적’ 설계라고 부르는데, 이런 연구 결과를 토대로 다음과 같은 결론을 도출한다.
설계는 예측 가능한, 구조화할 수 있는, 규격화할 수 있는 프로세스와는 거리가 멀고, 너저분하고 시행착오적인 것임을 알 수 있다. 그리고 기억해야 할 것은, 이 연구결과는 최고의 설계자들을 조사해서 얻은 것이라는 점이다. 이보다 못한 설계자들은 훨씬 더 너저분한 프로세스로 작업할 것임은 쉽게 상상할 수 있다.
p.155
“너저분한 프로세스”에 가슴이 아프다. ^^;;
복잡한 프로세스로 인해 최적의 설계는 보통 불가능하므로, 우리는 ‘만족스러운’ 솔루션을 위해 노력해야 한다. 만족스러운(최적이 아니라) 솔루션은 훌륭한 설계에 대한 조건을 충분히 만족시켜, 그 접근방법을 선택해 작업을 계속 하는 데 따르는 위험을 감수할만한 가치가 있는 것을 의미한다(최적의 설계는 불가능하거나 비용대비 효율이 낮다는 전제하에)
p.156
현실과 적절하게 타협할 필요가 있다라는 말로 이해할 수 있는데, 나같이 “만족스러운 솔루션”을 만드는 것도 벅찬 사람에게는 해당되지 않는 얘기다.
소프트웨어 공학의 사실과 오해 4 – 복잡성, 요구사항
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
여기서 “제거하기 어려운 오류”라는 것은 모든 테스트 과정을 거쳐서 출시된 제품에 여전히 남아있는 오류를 의미한다.
시크릿 The Secret
http://www.yes24.com/24/goods/2599166
책 소개
책에서 소개하는 핵심 개념은 간단하다. 나머지는 보충 설명과 개념을 뒷받침하는 실화로 되어 있다.
- 끌어당김의 법칙 – 생각하는대로 이루어진다. ( 생각이 현실을 끌어당긴다. )
- 원하는 바를 구체적으로 정하고, 이미 이루어진 것처럼 생각하고 행동하면 정말로 그렇게 된다.
- 정말로 100억 가진 부자가 된 것처럼 생각하고, 1억짜리 차를 산다거나 하면 정말 100억이 생긴다. -_-;;
- 부정적인 생각을 하면 정말로 그렇게 된다.
- ‘차가 고장나면 안될텐데’라고 생각하면 차가 고장이 난다.
내 감상문
책에서는 양자물리학까지 거론하면서 원리를 설명하지만 지금의 과학기술로는 맞다고도, 틀리다고도 판단할 수 없지 않을까. 책에는 ‘끌어당김의 법칙’을 사용해 성공한 사람들의 다양한 실화가 나온다. 그 실화의 주인공들이 책의 뒤쪽에 소개되는데, 하나같이 인생을 주제로한 단체나 연구소의 설립자, 강연자, 저자, 컨설턴트였다. -_-;;
정말로 100억 가진 부자가 될 수 있건, 없건 상관없이 나는 이 책에서 제시하는 방법이 너무도 유용하다고 생각한다. 그 이유는 아래쪽에 나열해봤다.
잡담
유실장님 블로그에서는 85판이나 인쇄되었다고 하셨는데 내 책은 2008년3월에 샀음에도 불구하고 107쇄다. -_-;;
http://www.yes24.com/24/goods/3618719
책을 읽고도 삶이 바뀌지 않으면 읽어보라고 실천법 책이 나왔다. 만약, 만의 하나, 혹시나 저자가 사기꾼이라더라도 정말 존경스럽다. ^^;;
책에서 제시하는 방법이 유용한 이유
꿈의 구체화
이 책을 읽고나서 내가 바라는 것을 상상해보려고 했는데, 이런, 내가 뭘 바라는지 생각해본 적이 없었다! 뭘 바라는지도 모르는데 이루어 질리가 있나.
그 후로 원하는 것을 상상해 버릇하니 원하는 바가 점점 선명해진다. 그 전에는 원하는 것이 뭐냐고 물어보면 그 때부터 찾았어야 했다.
영어 일기를 쓰다가 찾던 표현들은 나중에 우연히 듣게 되더라도 바로 포착되고, 머리에도 쏙~ 들어온다고 한다. 평소에 내가 바라는 것이 무엇인지 잘 알고 있으면 기회 포착도 쉬울 것 같다.
그냥 행복하기
현재에 그냥 행복하기는 여러 종교와 서적에서 찾아 볼 수 있는 가르침이다. 생각하는 것만으로 현실이 된다니, 미래에 대한 근심을 없애는데 이보다 좋은 방법은 없는 것 같다.
사실일지도..
동양의 전통 문화, 한의학, 인디언의 생활방식과 같이 비과학적으로 보이지만, 전체적인 관점에서는 더 과학적인 경우도 있다. 우리의 의식과 우주가 연결되어 있다는 것은 여러 종교에서 찾아볼 수 있는 견해이고, 멀지 않은 미래에 양자물리학등에 의해 과학적으로 증명될지도 모른다.
돌이켜보면 내가 할 수 있다고 생각한 만큼만 얻었다.
닭이 먼저냐 달걀이 먼저냐의 문제로 볼 수도 있다. 팀장으로 승진해야 팀장이 되는 것이 아니라, 팀장처럼 행동해야 팀장으로 승진하게 된다.
경험적으로 문제해결에 집중하기보다는 바람직한 상황에 집중하는게 더 유익했다. ‘문제’는 부분적인 것으로 꼭 해결할 필요가 없고, 무시할 수도 있다. 반면에 원하는 것, ‘목표’에 집중하면 올바른 길이 보인다. 전체적인 관점이 된다.
감사하기의 효과
긍정적인 마음을 유지하기 위해서 ‘감사하기’를 하면 좋다고 해서 해봤다. 비몽사몽간에 머리를 감으며 회사에 가서 해야만 하는 귀찮을 일들을 생각하는 대신에 감사할 것을 찾아보았더니 의외로 많다. 이 추운 겨울에 정확한 온도의 따뜻한 물이 나오는 것도 너무 감사하고, 아픈데 없이 내 손으로 머리를 감을 수 있는 것도 감사하고, 사회생활에 지장이 없어서 사람 많은 회사에 출근해서 일 할 수 있다는 것도 감사하다.
불필요한 에너지 낭비 없애기
책에서 설명하는 방법이 모든 것을 해결해 준다고 생각하지 않는다. 당연히 꿈을 향해 노력해야 하며, 실화의 주인공들도 열심히 노력했을 거라 생각한다. 다만, 불필요한 불안, 근심을 없애주고 꿈을 향해 나아가는데 힘을 실어주는 방법임은 분명하다.
걱정하지 않는 것 만으로도 불안, 부담, 싫증, 스트레스 등이 없어지는 걸 경험할 수 있다.
더 큰 행복을 찾아서
원하는 바를 찾아서 이미 이루어졌다고 생각하게 되면, 그 다음으로 무엇을 원하는지 찾게 된다. 그런식으로 꼬리를 물고 계속 들어가면 상상 가능한 한도에서 가장 큰, 그리고 궁극적인 행복을 그리게 된다. 첫번째 행복을 위해서 시간을 쓰는 대신 곧바로 골인 지점으로 갈 수 있다.
결국은 도구다
책에서 설명하는 방법도 결국은 도구다. 맞다 틀리다를 논하기 보다는 자신의 상황에 맞게 잘 써서 유익하면 되는 일이다.