저자: 스티브 맥코넬
출판사: 인사이트
읽으면서, 내가 스스로 소프트웨어 개발자 라고 말하기에는 챙피할 수준이라는 것과 동시에, 무언가 깨달은 것만 같은 느낌에 흥분감이 밀려왔다.
정말 많은 내용을 - 실제 개발보다는 개발 원칙과 개념적인것을 다루고 있지만 - 담고 있는 책의 내용 중 일부 내가 크게 동화된 내용을 옮겨적고자 한다. 후일에도 두고두고 보면서 "나는 소프트웨어 개발 전문가 입니다." 라고 말할 수 있는 수준이 될 때까지 노력해 볼 생각이다.
물론 내가 감명 받은 내용만을 부분적으로 적을것이므로 책의 다른 생략 된 부분에 대해서는 직접 책을 읽어야 할 것이다.
my note 1. 프로세스 기반 개발 vs 책임 기반 개발
저자는 책에서, 실무에서 개발의 방법에는 크게 두가지 부류로 나누어 볼 수 있다고 한다. 첫째는 책임 기반 개발이고, 둘째는 프로세스 기반 개발이다.
책임 기반 개발: 쉽게 말해 영웅중심개발이다. 천재 프로그래머를(영웅) 프로젝트에 투입하는 것이다. 이러한 구조는 영웅 혹은 영웅들에게 커다란 동기를 부여하여 잠재력을 유도하는데에 목적을 둔다. (보통 영웅개발자들은 회사를 위해서가 아니고 나와 나의 자존심을 위해 개발을 하는 경우가 대부분이니까. 영웅들은 돈인나 삶의 질적 가치보다는 그들의 명예를 지키고 그에 따른 희열을 맛보기 위해 개발을 한다. 24시간을 프로젝트에 전념하며 매달리기도 한다.)
프로세스 기반 개발: 잘짜여진 계획과 프로세스 그리고 S/W 공학 기법을 사용하여 개발하는 방법이다. 모든 팀원이 골고루 역할 분배를 받으며, 프로세스에 따라 체계적으로 개발해 나간다. 이런 형태의 개발에서 영웅의 존재는 팀웍을 방해하는 굉장한 방해물이 될 것이다. 영웅들은 제멋대로 자신의 방식을 과시하면서 프로세스를 무시하고 개발하기 때문에! 뭐, 프로세스 기반 개발이 영웅기반 개발보다 세련되 보일 수는 있겠지만, 소규모 프로젝트에서는 불필요한 문서 작업과 회의량만을 늘릴 뿐이다.
어찌됬든 두 방법 모두 실무에서 쓰이고 있고 성공적인 프로젝트 사례도 많다. 허나~! 문제는 이런 방법을 어설프게 따라하려고 했을때 발생한다. 저자는 이것을 각각 이렇게 정의한다.
책임 사칭 조직: 책임 기반 개발을 어설프게 따라하는 조직. 일명. 착취조직!! 똑똑히 일하는 것보다는 열심히 일하는 것을 중시한다. 결과(긴 근무시간)과 원인(높은 동기부여)를 혼동하는 것이다. 친구들의 푸념을 들으면서 이런 조직을 종종 보는데, 이렇게 명확히 정의를 내리고 보니 문제점을 확연히 알겠다.
프로세스 사칭 조직: 관료조직! 프로세스의 형태를 본질보다 중요시하는 조직이다. 쓸데없는 산출물만을 끊임없이 만들어내면서 자신들은 지금 무척 세련되게 잘 해나가고 있다고 착각하는 조직이다. 음.. 일종의.. 세모모양 구멍에 네모모양 블럭을 억지로 끼워 넣는 기분이랄까? 네모모양 블럭은 네모모양 구멍에 넣어야지!
보면서 나는 박장대소를 하며 엄청난 공감을 하게 되는 씁쓸한 현실을 마주해야 했다.
my note 2. 화물 숭배 소프트웨어 공학.
본문에 삽입된 재미있는 이야기를 옮겨두겠다.
예전에 남태평양 어떤 섬에는 화물 숭배라는 종교를 믿는 사람들이 있었다. 당시에 섬 하늘에는 전쟁 물자를 수송하는 비행기들이 많이 다녔고, 섬 사람들은 비행기를 신의 전령이라 믿었다. 그들은 언젠가 신이 자신들에게도 비행기에 엄청난 물자를 실어 보내줄 것이라고 생각했다. 그래서 비행기가 섬으로 착륙할 수 있도록 활주로 비슷한 것을 만들기 시작했고, 활주로 좌우에는 유도등처럼 불을 피워 놓았다. 또 사람이 들어와 앉을 수 있도록 관제탐 같은 통나무 집도 만들었고, 대나무를 깎아 안테나처럼 달아 놓았다. 그 안에서 나뭇가지를 헤드셋처럼 묶고 앉아, 비행기가 착륙하기만을 하염없이 기다렸다. 그들은 이전에 다른 곳에서 본 진짜 활주로의 모습을 재현했다. 적어도 그 형태만큼은 완벽했다. 그러나 비행기는 오지 않았다. 나는 섬 사람들이 "과학적인 연구의 형태와 지침"을 따르기 때문에, 이것을 화물 숭배 과학이라 부른다. 그들은 뭔가 중요한 것을 잊고 있음이 분명했다. 왜냐하면 비행기가 한 대도 오지 않았기 때문이다. -리차드 파인만.
저자는 앞의 책임 사칭 조직과 프로세스 사칭 조직을 "화물 숭배 소프트웨어 공학" 이라고 칭했다. 프로젝트의 성공을 위한 통찰 없이 그 형태만 흉내내는 꼴이, 비행기가 한대도 오지 않는 활주로를 만든 섬 주민과 같기 때문이다.
이런 화물 숭배 소프트웨어 엔지니어는 현재에 안주하며 자신의 방식을 정당화 한다는 것이다. 일 자체가 말도 안됨에도 "우린 원래 이렇게 해 왔는걸" 이라고 말하면서 말이다.
무언가 조금 찔리지 않는가?
my note 3. 소프트웨어 공학 vs 소프트웨어 과학
책에서 이 부분을 읽으면서, 대학을 다니면서 가졌던 모호한 질문을 시원하고 깔끔하게 이해할 수 있었다. 시작은 공학과 과학의 차이점에서부터이다. (저자는, 일반적으로 생각하는 공학과 과학의 차이와 S/W에서의 공학과 과학의 차이가 크게 다르지 않다고 말한다.)
공학은 무엇인가? 공학은, 현재 만드는 제품과 관련된 모든 분야의 지식을 습득해야 한다. 또한 최종 소비자와 관련이 있기 때문에 많은 제약사항을 숙지하고 있어야 한다. 반면 과학은? 과학은, 특정 전문 지식만을 연구해도 된다. 다른 과학자와 관련이 있기에 큰 통제가 따르지 않는다.
단원의 마지막에, 공학과 과학의 차이에 대해 극단적이지만 명료하게 이렇게 정의한다.
" 공학을 전공한 학생은 학업을 마친 후 즉시 작업 현장에 투입 될 준비를 한다. 그리고 과학을 전공한 학생은 연구를 계속할 준비를 한다."
깔끔하지 않은가? 왜 소프트웨어를 전공했다는 학생들이 실무에서 샌님처럼 굴까? 그것은, 학교에서 충분한 공학 수업을 거치지 않았기 때문이다. 많은 학교들이 소프트웨어 공학을 가르친다면서 소프트웨어 과학을 가르치고, 반대로, 소프트웨어 과학을 가르친다면서 공학을 가르치고 있다. 그 두가지의 혼란선상에서, 누구나 이런생각 해보지 않았는가? "개발을 하려면, 많은 언어와 기술을 알아야 하는거야? 아니면.. 하나만 끝까지 파고들면되는거야?"
뭐 대답은 둘 다 아니다. 언어나 기술에 대한것을 아는 것이 당연히 좋겠지만, 내가 소프트웨어 공학자(즉 개발자?) 를 하기로 한 이상, 언어나 기술등 과학과 밀접한 것보다는 수많은 원칙과 다양한 분야를 섭렵하는 것이 맞다. 그럼 얼마나 다양하게??? 이 책은 어디까지 날 깨우쳐주려는건지!! 저자는 그 부분도 친절히 범위를 정의해 주었다 -ㅂ- gogo my note 4.
my note 4. 소프트웨어 엔지니어가 반드시 갖춰야 할 지식 영역.
일단, 이것은 저자가 멋대로 만든것이 아니며, SWEBOK (ACM과 IEEE에서 관리하는 소프트웨어공학 지식체계 프로젝트.) 에서 정의한 것이다. 고로 수많은 경험이 축적된 개발자들의 머리에서 뽑아낸 매우 신빙성 있는 것이라 할 수 있다. 총 10가지이다.
- 소프트웨어 요구사항: 나에겐 아주 귀찮은 존재 영역. -_-
- 소프트웨어 설계: 나 잘났다고 뻐기는 영역이지만 사실은 매우 아마추어 수준. -_-;;
- 소프트웨어 구축: 나의 지식 영역의 50%는 여기에 집중되어 있다.
- 소프트웨어 테스팅: 필요성은 알지만 가볍게 무시하는 수준. -_-
- 소프트웨어 유지보수: 필요성은 알지만 할 줄도 모르고 하기도 귀찮다 -_-;;;
- 소프트웨어 형상관리: 그나마 요근래 맛만 살짝 본 영역.
- 소프트웨어 품질: 테스팅도 안하는데. 품질에 신경쓰겠는가? -ㅂ- 완전무시수준.
- 소프트웨어 공학 관리: 그렇저렇 하는 수준.
- 소프트웨어 툴과 방법론: 소프트웨어 구축을 뺀 나의 남은 지식 영역이 여기에 포함된다.-ㅂ-;;
- 소프트웨어 프로세스: 알만큼 알고 필요성도 알기에 하고는 있지만 귀찮아 하는 수준. -_-
위에서 색이 진할수록 나의 지식영역이 집중포화 되있다고 볼 수 있다. 이야... 영양의 불균형이 지나치게 드러난다. 아마 관련 전공 학사 학위자는 대부분 나와 비슷하지 않을까 한다. 이 부분에서.. 조금은 내 자신이 창피하다. -_- 사실 소프트웨어 설계니 구축이니.. 방법론도, 그냥 아는 것이 많다뿐, 별로 어떻게해야 '잘' 하는 것인지 아직도 모호하다. 다양한 프로젝트에 대한 경험을 쌓아야 하는 문제겠지만 말이다.
my note 5. 소프트웨어 의식 향상
지식을 갖췄다고 해서 다가 아니다. 개발자로서의 의식자체를 업그레이드 해야한다. 저자는 아래와 같은 3단계로 나누고 있다.
의식 1 - 개척자 정신. 소프트웨어로 치면, 야생마.. 프리마돈나.. 수준? 개발자의 자만심과 관련된 의식이라고 한다. 자기 멋대로 막무가내로 개발하지만 어쨋든 결과는 나온다. 가끔은 꽤 성공적일때도 있어서 자신을 천재로 착각하기도 한다. 그럼과 동시에 다른 사람의 의견에 배타적으로 변하고 지식에 닫혀 있다.
의식 2 - 양복쟁이. 일종의 규칙 중시자이다. 이럴때 이렇게 저럴땐 저렇게. 의식 1 상태에서 한계를 깨닫고(당연히 그렇겠지..-_-) 팀 단위 개발을 하기 시작하는 단계라고 한다. 이 단계에서는 방법론을 중시하기 때문에 자칫 잘못하면 프로세스 사칭 팀으로 전락할 수도 있다고 본다.
의식 3 - 계몽 독립 정신! 마지막 단계이다. 원칙에 초점을 맞춘다. 예를들자면, 소프트웨어의 결합도를 낮추고 응집도를 높여야 한다는 원칙을 위해 수많은 디자인 패턴들이 쏟아져 나오는 것을 생각할 수 있겠다. 의식 2 에서는 이것을 반대로 여겨, 디자인 패턴을 써야만 결합도를 낮출수 있다고 착각한다.(물론 사실이지만, 디자인 패턴은 optional 한 것이지 mandatory 한 것은 아니다) 의식 3에서는 결합도를 낮추는 것에 집중하는 것이지, 디자인패턴에 구애받지 않는다.
나는 의식 2에 머물러 있는듯 하다. 그리고 슬픈 것은 의식 1에서 의식2로 넘어온지 얼마 안된것 같은 느낌을 받는다. 나아갈 길이 멀다.
출판사: 인사이트
읽으면서, 내가 스스로 소프트웨어 개발자 라고 말하기에는 챙피할 수준이라는 것과 동시에, 무언가 깨달은 것만 같은 느낌에 흥분감이 밀려왔다.
정말 많은 내용을 - 실제 개발보다는 개발 원칙과 개념적인것을 다루고 있지만 - 담고 있는 책의 내용 중 일부 내가 크게 동화된 내용을 옮겨적고자 한다. 후일에도 두고두고 보면서 "나는 소프트웨어 개발 전문가 입니다." 라고 말할 수 있는 수준이 될 때까지 노력해 볼 생각이다.
물론 내가 감명 받은 내용만을 부분적으로 적을것이므로 책의 다른 생략 된 부분에 대해서는 직접 책을 읽어야 할 것이다.
my note 1. 프로세스 기반 개발 vs 책임 기반 개발
저자는 책에서, 실무에서 개발의 방법에는 크게 두가지 부류로 나누어 볼 수 있다고 한다. 첫째는 책임 기반 개발이고, 둘째는 프로세스 기반 개발이다.
책임 기반 개발: 쉽게 말해 영웅중심개발이다. 천재 프로그래머를(영웅) 프로젝트에 투입하는 것이다. 이러한 구조는 영웅 혹은 영웅들에게 커다란 동기를 부여하여 잠재력을 유도하는데에 목적을 둔다. (보통 영웅개발자들은 회사를 위해서가 아니고 나와 나의 자존심을 위해 개발을 하는 경우가 대부분이니까. 영웅들은 돈인나 삶의 질적 가치보다는 그들의 명예를 지키고 그에 따른 희열을 맛보기 위해 개발을 한다. 24시간을 프로젝트에 전념하며 매달리기도 한다.)
프로세스 기반 개발: 잘짜여진 계획과 프로세스 그리고 S/W 공학 기법을 사용하여 개발하는 방법이다. 모든 팀원이 골고루 역할 분배를 받으며, 프로세스에 따라 체계적으로 개발해 나간다. 이런 형태의 개발에서 영웅의 존재는 팀웍을 방해하는 굉장한 방해물이 될 것이다. 영웅들은 제멋대로 자신의 방식을 과시하면서 프로세스를 무시하고 개발하기 때문에! 뭐, 프로세스 기반 개발이 영웅기반 개발보다 세련되 보일 수는 있겠지만, 소규모 프로젝트에서는 불필요한 문서 작업과 회의량만을 늘릴 뿐이다.
어찌됬든 두 방법 모두 실무에서 쓰이고 있고 성공적인 프로젝트 사례도 많다. 허나~! 문제는 이런 방법을 어설프게 따라하려고 했을때 발생한다. 저자는 이것을 각각 이렇게 정의한다.
책임 사칭 조직: 책임 기반 개발을 어설프게 따라하는 조직. 일명. 착취조직!! 똑똑히 일하는 것보다는 열심히 일하는 것을 중시한다. 결과(긴 근무시간)과 원인(높은 동기부여)를 혼동하는 것이다. 친구들의 푸념을 들으면서 이런 조직을 종종 보는데, 이렇게 명확히 정의를 내리고 보니 문제점을 확연히 알겠다.
프로세스 사칭 조직: 관료조직! 프로세스의 형태를 본질보다 중요시하는 조직이다. 쓸데없는 산출물만을 끊임없이 만들어내면서 자신들은 지금 무척 세련되게 잘 해나가고 있다고 착각하는 조직이다. 음.. 일종의.. 세모모양 구멍에 네모모양 블럭을 억지로 끼워 넣는 기분이랄까? 네모모양 블럭은 네모모양 구멍에 넣어야지!
보면서 나는 박장대소를 하며 엄청난 공감을 하게 되는 씁쓸한 현실을 마주해야 했다.
my note 2. 화물 숭배 소프트웨어 공학.
본문에 삽입된 재미있는 이야기를 옮겨두겠다.
예전에 남태평양 어떤 섬에는 화물 숭배라는 종교를 믿는 사람들이 있었다. 당시에 섬 하늘에는 전쟁 물자를 수송하는 비행기들이 많이 다녔고, 섬 사람들은 비행기를 신의 전령이라 믿었다. 그들은 언젠가 신이 자신들에게도 비행기에 엄청난 물자를 실어 보내줄 것이라고 생각했다. 그래서 비행기가 섬으로 착륙할 수 있도록 활주로 비슷한 것을 만들기 시작했고, 활주로 좌우에는 유도등처럼 불을 피워 놓았다. 또 사람이 들어와 앉을 수 있도록 관제탐 같은 통나무 집도 만들었고, 대나무를 깎아 안테나처럼 달아 놓았다. 그 안에서 나뭇가지를 헤드셋처럼 묶고 앉아, 비행기가 착륙하기만을 하염없이 기다렸다. 그들은 이전에 다른 곳에서 본 진짜 활주로의 모습을 재현했다. 적어도 그 형태만큼은 완벽했다. 그러나 비행기는 오지 않았다. 나는 섬 사람들이 "과학적인 연구의 형태와 지침"을 따르기 때문에, 이것을 화물 숭배 과학이라 부른다. 그들은 뭔가 중요한 것을 잊고 있음이 분명했다. 왜냐하면 비행기가 한 대도 오지 않았기 때문이다. -리차드 파인만.
저자는 앞의 책임 사칭 조직과 프로세스 사칭 조직을 "화물 숭배 소프트웨어 공학" 이라고 칭했다. 프로젝트의 성공을 위한 통찰 없이 그 형태만 흉내내는 꼴이, 비행기가 한대도 오지 않는 활주로를 만든 섬 주민과 같기 때문이다.
이런 화물 숭배 소프트웨어 엔지니어는 현재에 안주하며 자신의 방식을 정당화 한다는 것이다. 일 자체가 말도 안됨에도 "우린 원래 이렇게 해 왔는걸" 이라고 말하면서 말이다.
무언가 조금 찔리지 않는가?
my note 3. 소프트웨어 공학 vs 소프트웨어 과학
책에서 이 부분을 읽으면서, 대학을 다니면서 가졌던 모호한 질문을 시원하고 깔끔하게 이해할 수 있었다. 시작은 공학과 과학의 차이점에서부터이다. (저자는, 일반적으로 생각하는 공학과 과학의 차이와 S/W에서의 공학과 과학의 차이가 크게 다르지 않다고 말한다.)
공학은 무엇인가? 공학은, 현재 만드는 제품과 관련된 모든 분야의 지식을 습득해야 한다. 또한 최종 소비자와 관련이 있기 때문에 많은 제약사항을 숙지하고 있어야 한다. 반면 과학은? 과학은, 특정 전문 지식만을 연구해도 된다. 다른 과학자와 관련이 있기에 큰 통제가 따르지 않는다.
단원의 마지막에, 공학과 과학의 차이에 대해 극단적이지만 명료하게 이렇게 정의한다.
" 공학을 전공한 학생은 학업을 마친 후 즉시 작업 현장에 투입 될 준비를 한다. 그리고 과학을 전공한 학생은 연구를 계속할 준비를 한다."
깔끔하지 않은가? 왜 소프트웨어를 전공했다는 학생들이 실무에서 샌님처럼 굴까? 그것은, 학교에서 충분한 공학 수업을 거치지 않았기 때문이다. 많은 학교들이 소프트웨어 공학을 가르친다면서 소프트웨어 과학을 가르치고, 반대로, 소프트웨어 과학을 가르친다면서 공학을 가르치고 있다. 그 두가지의 혼란선상에서, 누구나 이런생각 해보지 않았는가? "개발을 하려면, 많은 언어와 기술을 알아야 하는거야? 아니면.. 하나만 끝까지 파고들면되는거야?"
뭐 대답은 둘 다 아니다. 언어나 기술에 대한것을 아는 것이 당연히 좋겠지만, 내가 소프트웨어 공학자(즉 개발자?) 를 하기로 한 이상, 언어나 기술등 과학과 밀접한 것보다는 수많은 원칙과 다양한 분야를 섭렵하는 것이 맞다. 그럼 얼마나 다양하게??? 이 책은 어디까지 날 깨우쳐주려는건지!! 저자는 그 부분도 친절히 범위를 정의해 주었다 -ㅂ- gogo my note 4.
my note 4. 소프트웨어 엔지니어가 반드시 갖춰야 할 지식 영역.
일단, 이것은 저자가 멋대로 만든것이 아니며, SWEBOK (ACM과 IEEE에서 관리하는 소프트웨어공학 지식체계 프로젝트.) 에서 정의한 것이다. 고로 수많은 경험이 축적된 개발자들의 머리에서 뽑아낸 매우 신빙성 있는 것이라 할 수 있다. 총 10가지이다.
- 소프트웨어 요구사항: 나에겐 아주 귀찮은 존재 영역. -_-
- 소프트웨어 설계: 나 잘났다고 뻐기는 영역이지만 사실은 매우 아마추어 수준. -_-;;
- 소프트웨어 구축: 나의 지식 영역의 50%는 여기에 집중되어 있다.
- 소프트웨어 테스팅: 필요성은 알지만 가볍게 무시하는 수준. -_-
- 소프트웨어 유지보수: 필요성은 알지만 할 줄도 모르고 하기도 귀찮다 -_-;;;
- 소프트웨어 형상관리: 그나마 요근래 맛만 살짝 본 영역.
- 소프트웨어 품질: 테스팅도 안하는데. 품질에 신경쓰겠는가? -ㅂ- 완전무시수준.
- 소프트웨어 공학 관리: 그렇저렇 하는 수준.
- 소프트웨어 툴과 방법론: 소프트웨어 구축을 뺀 나의 남은 지식 영역이 여기에 포함된다.-ㅂ-;;
- 소프트웨어 프로세스: 알만큼 알고 필요성도 알기에 하고는 있지만 귀찮아 하는 수준. -_-
위에서 색이 진할수록 나의 지식영역이 집중포화 되있다고 볼 수 있다. 이야... 영양의 불균형이 지나치게 드러난다. 아마 관련 전공 학사 학위자는 대부분 나와 비슷하지 않을까 한다. 이 부분에서.. 조금은 내 자신이 창피하다. -_- 사실 소프트웨어 설계니 구축이니.. 방법론도, 그냥 아는 것이 많다뿐, 별로 어떻게해야 '잘' 하는 것인지 아직도 모호하다. 다양한 프로젝트에 대한 경험을 쌓아야 하는 문제겠지만 말이다.
my note 5. 소프트웨어 의식 향상
지식을 갖췄다고 해서 다가 아니다. 개발자로서의 의식자체를 업그레이드 해야한다. 저자는 아래와 같은 3단계로 나누고 있다.
의식 1 - 개척자 정신. 소프트웨어로 치면, 야생마.. 프리마돈나.. 수준? 개발자의 자만심과 관련된 의식이라고 한다. 자기 멋대로 막무가내로 개발하지만 어쨋든 결과는 나온다. 가끔은 꽤 성공적일때도 있어서 자신을 천재로 착각하기도 한다. 그럼과 동시에 다른 사람의 의견에 배타적으로 변하고 지식에 닫혀 있다.
의식 2 - 양복쟁이. 일종의 규칙 중시자이다. 이럴때 이렇게 저럴땐 저렇게. 의식 1 상태에서 한계를 깨닫고(당연히 그렇겠지..-_-) 팀 단위 개발을 하기 시작하는 단계라고 한다. 이 단계에서는 방법론을 중시하기 때문에 자칫 잘못하면 프로세스 사칭 팀으로 전락할 수도 있다고 본다.
의식 3 - 계몽 독립 정신! 마지막 단계이다. 원칙에 초점을 맞춘다. 예를들자면, 소프트웨어의 결합도를 낮추고 응집도를 높여야 한다는 원칙을 위해 수많은 디자인 패턴들이 쏟아져 나오는 것을 생각할 수 있겠다. 의식 2 에서는 이것을 반대로 여겨, 디자인 패턴을 써야만 결합도를 낮출수 있다고 착각한다.(물론 사실이지만, 디자인 패턴은 optional 한 것이지 mandatory 한 것은 아니다) 의식 3에서는 결합도를 낮추는 것에 집중하는 것이지, 디자인패턴에 구애받지 않는다.
나는 의식 2에 머물러 있는듯 하다. 그리고 슬픈 것은 의식 1에서 의식2로 넘어온지 얼마 안된것 같은 느낌을 받는다. 나아갈 길이 멀다.
