소프트웨어에 대한 책을 쓰게 된다면 소프트웨어와 개발자에 대한 심도 깊은 이해와 소프트웨어를 개발하는 공장과 공정에 대한 것을 쓰고 싶었다.

주말에 서점에서 "소프트웨어 프로젝트의 모든 것" 이라는 신간 책을 보았다.  주로 대부분의 기술 서적이  외국 서적을 번역하는 수준인 현실을 감안할 때 국내  소프트웨어  전문가가 직접 집필한 책이라 더욱 눈에 띠었다. 

너무 많은 내용을 한 권에 담을려고 하다 보니 다소 이야기의 깊이가 낮지 않나라는 생각이 들기도 하지만 , 소프트웨어를 개발하는 데 있어 필요로 하는 전반적인 사항들을 폭넓게 정리가 되어 있는 책이다. 별도로 프로젝트 관리나 기타 전문 Software Engineering 교육을 받지 못한 개발자나 관리자분들은 한번쯤 읽어보면 많은 도움이 될 것이다.

개인적으로는 소프트웨어의 요구사항을 정리하는 SRS ( Software Requirement Specification ) 를 강조하는 부분이 특히 공감이 간다. 다양한 사용자와 환경적 요구 사항을 체계적으로 수렴하고 이를 기술하는 것이야 말로 간과하기 쉬운 아주 중요한 것이기 때문이다.

좀 더 다양한 실제 사례가 소개되었으면 하는 아쉬움은 남지만 S/W에 관한 아주 실용적인 책이다.

최근 이런 질문을 받았다.  "앞으로 SaaS 분야의 전망은 어떻게 생각하는가?"
이렇게 대답하였다. "사용자들이 얻게 되는 이득과 개발업체들이 얻게되는 이득을 고려할 때 합리적 선택을 한다면 SaaS시장은 지속적으로 성장할 것이다."

"합리적 선택"은 경제학 분야에서 많이 사용하는 이론이다. 팀 하포트가 집필한 경제학 콘서트란 책은 "합리적 선택이론"에 근거하여 십대들의 구강성교가 늘어나는 이유를 설명하는 것을 비롯해 다양한 사회 현상을 설명한다. 합리적 선택은 다양한 상황하에서 발생한다. 가령, 서울에서 부산까지 출장을 가야 한다고 하자. 이 때 이용할 수 있는 교통편은 자가용과 고속버스만 있다고 생각해 보자. 만일 바로 부산에서 일을 마치고 돌아와야 한다면 정상적이라면 고속버스를 선택할 것이다. 그러나 중간에 대전에서 잠시 들려 고객을 만나고 부산에서 돌아오는 길에 대구에서 잠시 고객을 만나야 한다면 자가용을 선택할 것이다. 바로 이러한 선택이 합리적 선택이다.

합리적 선택에 근거해 국내 소프트웨어 시장을 생각해 보자. 왜 국내 소프트웨어 분야가 점점 활성화되지 못하는 것일까?

개발자 입장에서 생각해 보자. 대학에서 전공을 선택하는 학생 입장에서 소프트웨어 개발자는 노력에 비해 보수가 적은  3D분야로 알려져 있다. 따라서 전공선택에 있어서도 소프트웨어 개발에 특별한 사명감(?)을 갖고 있는 학생을 제외하고 우수한 학생들은 의대나 생명공학같은 학과를 선택한다. 이런 과정에서 전산을 선택한 학생들은 졸업 후 다시 한번 취업을 위해 합리적으로 선택을 해야 한다. 당연히 이 때 선택은 가급적 규모가 크고 안정적이며 대우가 좋은 대기업을 선택한다.  대기업에 선택받지 못한 예비 개발자는 벤처나 중소 기업을 선택할 수 밖에 없다. 물론 소프트웨어 분야를 포기하고 다른 업종을 선택할 수도 있다.

그런데 문제는 솔루션 개발 분야에서 많은 부분을 차지하고 있는 벤처나 중소기업들의 경우 먹이사슬의 가장 하단부에서 피를 빨리고 있다는 것이다. 대부분의 프로젝트들이 대형SI들이 수주를 하고 이들 업체에게 하청관계로 일을 할 수 밖에 없는 업체들은 울며겨자먹기 식으로 과다한 업무를 적은 대가를 받고 개발을 한다. 이런 상황에서 중소기업이 할 수 있는 유일한 방법은 개발자에게 적은 보수를 주고 과다한 개발 업무를 수행하는 방법밖에는 없다. 이런 상황에서 개발자가 선택할 수 있는 합리적인 선택은 일단 경력과 실무를 쌓고 대형SI나 다른 안정적인 기업으로 이직을 하는 것이다. 그나마 이렇게라도 이직을 하는 개발자는 능력과 경쟁력을 갖춘 개발자라 할 수 있다. 이러한 경쟁력도 없는 개발자는 더욱 열악해진 상황에서 개발을 해야 한다. 이 과정에서 그는 자신의 신세를 친구나 후배에게 직.간접적으로 이야기를 한다. 따라서 예비 개발자는 본인의 개발자로서 미래에 대해  불확실성을 느끼며 다시 악순환이 반복된다.

이제 다시 솔루션 분야의 개발자가 아니라 CEO의 입장에서 생각해 보자. 멋진 기술력을 바탕으로 솔루션을 개발하고 이 제품을 시장에 내놓는다. 초기 영업과 마케팅을 위해 많은 노력을 기울인다. 이러한 영업과 마케팅은 실제적으로 대부분의 프로젝트를 수주한 대기업에게 집중될 수 밖에 없다. 또한 이렇게해서 프로젝트가 성사가 되더라도 저가로 수주한 프로젝트로는 수익을 맞출 수가 없다. 따라서 회사를 운영하기 위해 할 수 있는 방법은 개발자에게 적은 임금을 주고 개발을 하거나 다시 재하청을 주는 수 밖에 없다.  이미 창업과 회사 운영을 위해 많은 부채를 안고 있는 CEO들은 무한 책임을 지기때문에 다른 선택도 할 수 없다. 유일하게 CEO들이 할 수 있는 선택은 회사를 지키면서 끝까지 함께하는 것이다.

고객 입장에서의 합리적 선택을 생각해 보자. 프로젝트를 발주하는 고객 입장에서 현재 구조라면 당연히 대형SI회사에게 발주하는 것이 합리적인 선택이다. 왜냐하면 해당 프로젝트에 대한 책임을 질 수 있기 때문이다. 작은 회사에 발주를 했다 해당 회사에 문제가 생겨 어려움에 빠지는 것을 결코 바라지 않기 때문이다.

지금까지 상황은 실제 우리 소프트웨어 업계의 모습이다. 과연 이런 상황에서 어떤 합리적인 선택을 해야 할까? 

컴퓨팅 파워와 하드디스크 용량이 증가함에 따라 개인의 노트북과 데스크탑에 존재하는 정보의 양도 기하급수적으로 함께 늘고 있다.  현재 개인적으로 사용하고 있는 노트북의 경우 200G HDD인데 거의 80% 정도 데이타가 쌓여 있다. 사실 이들 정보 중 찾지 못해서 제대로 이용하지 못하는 정보도 상당수 존재한다. 이러한 문제를 해결할 수 있는 방법으로 구글이나 네이버 같은 검색 업체는 데스크탑 검색 프로그램을 무료로 제공하고 있다. 개인적으로 이들 프로그램이 유용하기는 하지만 색인 과정에서 발생하는 CPU의 Load와 색인 파일의 크기 때문에 별로 선호하지는 않는다.

- 디렉토리와 폴더에 의한 파일 검색

과거 가장 유용하게 파일을 분류.활용하는 방법이 바로 사용자가 자신의 입맛대로 폴더와 디렉토리를 생성하고 이를 잘 분류하여 사용하는 것이었다. 가장 손쉬운 방법이지만 정보가 많아지면 원하는 정보를 찾기가 만만치 않다. 아마도 얼마지나지 않아 "  아니 그 파일이 그게 어디 있더라?" 내지는 기억하지 못해 다시 관련된 정보를 인터넷에서 검색하는 경우가 반복될 가능성이 크다. ( 나만 이런가? ^-^ )  이러한 방법은 실제 정보를 물리적인 분류(디렉토리와 폴더)로 매핑시키고 이를 통해 찾는 것이다. 과거에 기억으로 지식관리 시스템에서 이를 물리적인 맵(Physical Map)이라고 하고 개발했던 적이 있었는데 그다지 감동적인 방법은 아니었다.

- 태그 등 논리적인 방법에 의한 파일 분류 및 검색

보통 하나의 정보는 그 의미에 따라 여러 분류를 갖는다.  가령, Voip 기술이 모바일 시장에 미치는 영향 이란 보고서는 [ 기술 -> Voip ] 디렉토리에 속할 수도 있지만 [ 시장 동향 -> 모바일 시장 ]에 속할 수도 있다. 이 경우, 물리적인 맵으로는 파일을 복사하여 두 개의  폴더에 중복해서 둘 수 밖에 없다. 이러한 것을 피하기 위해 과거 지식관리 시스템에서 하나의 물리적인 파일(정보)에 여러 논리적인 맵을 매핑하는 1 :   N 매핑을 사용하였다. 이러한 방법을 맵 형태로 구현할 경우 논리 지식맵이 되고 , 일반 텍스트 나열 방식으로 구현하면 흔히 말하는 태그라 말 할 수 있다.

이러한 물리적인 방법과 논리적인 방법은 혼합되어 사용되어 질 경우 정말로 대량의 파일을 관리할 때 편하게 사용할 수 있다. 실제 , 이 방식으로 크게 성공한 회사는 바로 애플과 구글이다.
 
- 애플의 소프트웨어의 사용성은 검색에서 시작해서 검색으로 끝난다.

애플이 제공하는 소프트웨어는 대부분 스마트 분류와 검색을 제공한다. 여기서 스마트 분류와 검색이란 파일은 하나만 존재하지만 여기에 다양한 분류 기준과 검색 기준을 제공하여 논리적인 폴더를 구성하게 해주는 기능을 말한다.

가령, 애플은 윈도우의 탐색기에 해당하는 파인더라는 유틸리티를 제공한다. 파인더는 스마트 폴더라는 것을 제공하는 데 , 스마트 폴더는 특정 범위에 있는 문서의 제목이나 내용 중 특정 내용을 포함하는 문서들만을 논리적으로 구성하여 디렉토리처럼 관리할 수 있다. 가령, 아래 그림 처럼 파일 중  thinkfree가 제목이나 내용에 포함되어 있는 파일들만을 논리적으로 구성하여 왼편의 맵(사이드바)에 추가하여 파일을 활용할 수 있다.


또한 메일에서도 스마트 메일 상자라는 기능을 제공하는 데 수신되는 메일 중 특정 조건에 해당하는 메일을 논리적으로 분류하여 관리할 수 있다. 가령, 외부 웹2.0 관련된 그룹에서 오는 메일들을 분류하여 관리할 수 있다.



사진 또한 마찬가지 이다. 스마트 앨범이라는 기능을 제공하여 사진의 속성별(앨범,모든 텍스트,....,제목)로 기준을 정해 놓고 이들을 논리적으로 구분하여 관리할 수 있다.


이러한 사용성이 가장 극대화하여 효과를 본 프로그램은 아이튠이다. "아이튠의 스마트 재생 목록"은 39개의 음악 파일의 속성을 AND 나 OR로 조합하여 검색한 음악 파일을 가상 폴더를 만들어 분류하여 관리할 수 있다. 이렇게 분류한 가상 폴더를 아이팟에 바로 동기화하여 휴대할 수 있으니 사용자 입장에서는 대량의 음악 파일을 관리하는 데 있어 기존의 폴더 폴더 방식 보다 편리할 수 밖에 없다. 그냥 연결하면 자동으로 원하는 파일이 항상 동기화가 된다.


- 구글 서비스의 사용성은 검색에서 시작해서 검색으로 끝난다.

애플이 데스크탑상에서 검색 기능을 활용해서 멋진 소프트웨어를 개발했다면 웹에서는 구글이 이러한 기능을 자사 서비스에 적극 채용하여 사용자를 감격하게 만든다.

G메일은 대용량 메일을 제공한다. 사용자는 대용량 메일을 마치 메일 아키이브로 사용한다. 나도 거의 모든 메일을 Gmail로 포워딩한 후 이를 저장해 둔다. 이렇게 보관된 메일을 분류하여 찾는 것은 무척 어려운 일이다. 그러나 G 메일에서는 너무도 쉽다. 라벨(태그)을 만들고 이를 이용하여 수신된 메일에 대한 필터를 만들면 해당 메일이 자동으로 분류되기 때문이다. 애플의 스마트 메일상자와 동일한 기능을 제공한다.


구글 리더 또한 마찬가지이다. 태그를 명시하고 구독하는 블러그에 태그를 명시하면 모든 분류가 해결된다.


구글 Docs 또한 "Search Options"이란 기능을 통해 문서에 대한 검색을 하고 이를 가상 폴더로 만들 수 있다.


특히, 웹 서비스의 경우 Ajax 프로그래밍은 이러한 기능을 구현하는 데 아주 적합하다.  구글의 서비스들이 그러한 사실을 잘 증명한다. Ajax를 마치 윈도우 프로그래밍이나 자바 스윙 프로그래밍처럼 생각할 경우 심각하게 이기적인 서비스를 개발하게 된다. 이후에 Ajax를 사용하여 개발한 이기적인 서비스에 대해서는 다시 언급하기로 한다.

- 새로운 소프트웨어 개발에서 사용성은 검색에서 시작해서 검색으로 끝나야 한다.

현재의 소프트웨어와 서비스는 대량의 정보를 생성,분류,검색,공유 하는 기능을 효율적으로 제공하고  있다. 이미 과거의 경험에서 우리는 대용량 정보 분류와 검색에서 더 이상 물리적인 폴더와 디렉토리 만으로는 만족할 수 없다는 사실을 알았다. 따라서 이들 방법외에 논리적인 분류와 검색 방법을 효과적으로 제공해야 한다. 개인적으로 이들 기능은 모든 소프트웨어와 서비스들의 기본 기능 중의 하나라고 생각한다.

실제, 다음의 항목들은 정보의 속성들이다. 이러한 속성을 이용하여 다양한 논리적인 검색과 가상의 폴더를 만들어 활용할 수 있다.

파일 타입 , 파일 명, 파일 크기 , 작성 일, 최종 수정일 , 태그 , 작성자 , (협업 시) 공동 작업자 ,버전 정보 , 코멘트 , 중요도 그리고 본문 , 폴더 명, 폴더 위치(웹 또는 데스크탑 또는 모바일 ),...

예를 들어,  C 드라이브에 있는 정보중 파일 타입은  HWP 이고 2008년에 작성한 문서들 중에서 박재현과 그의 패밀리들이 작성한 파일을 모으되 웹 오피스와 씽크프리가 들어가 있는 문서들. 이런 기능은 오피스 프로그램에 반드시 필요한 것이다. 마찬가지로 다른 분야에서도 기본적으로 필요하다.

이러한 생각을 아주 제대로 반영한 훌륭한 프로그램이 있어 소개한다. Leap가 바로 이러한 생각을 가장 잘 반영한 프로그램이다. 지난 주 사용하던 맥의 파일 시스템이 깨져서 시스템을 새로 정리하던 중에 발견한 프로그램으로 사용하면 할 수록 감탄이 나왔다. 아쉽게도 맥버전만 제공하기 때문에 윈도우에서는 이용할 수 없다.


물리적인 맵과 태그,  파일 속성에 기반한 논리적인 맵을 기준으로 한 실시간 검색을 제공한다. 기존의 데스크탑 검색 프로그램처럼 전문 검색을 위해 비싼 색인 과정도 없다. 파일 타입 등의 속성과 태그 그리고 물리적인 위치 등을 조합하여 바로 원하는 문서를 찾을 수 있다. 화면의 오른쪽에 위치한 태그 생성기는 파일을 드래그하여 놓으면 관련된 태그를 입력하는 창이 나온다. 이 창에 태그를 입력하면 태그가 생성된다. 다소 아쉬운 것은 이렇게 찾은 문서를 논리적인 폴더로 구성(저장)할 수 없다는 것이다. 이 점을 제외하고는 직관적인 UI를 포함하여 아주 멋진 소프트웨어이다. 개인적으로는 웹 서비스 또는 응용 프로그램의 기획자나 개발자가 꼭 한번 사용해 보고 기억해 두는 것이 좋은 사례라 할 수 있다. 아마도 당분간 새로운 충격이 없는 한 새롭게 구상하는 프로그램은 이러한 프레임웍 기반으로 하게 될 것 같다^^.

Why software sucks... and what you can do about it

이 책에서 주장하는 것을 간략히 정리하면 ,
S/W에 있어 사용성은 무척 중요하다. 그런데 괴짜들인 개발자는 사용자를 위한 사용성에 크게 신경쓰지 않는다. 자기가 만족하면 OK다. 사용성 개선을 위해 사용자들은 개발자와 회사에 무엇이 불편한지 이야기를 해야 한다고 시종일관 강조하고 있다. 심지어 자신이 만든 suckbusters.com에 의견을 모아 집단적으로 의견을 전달하자고 말하고 있다. 

책을 한마디로 평가하면 제목만큼 올해 읽은 책중 가장 개떡(?,책의 제목을 인용한 것이니 오해마세요^-^)같은 IT 관련 서적이 아닌가 싶다. 일반 사용자들이 읽기에는 다소 전문적인 반면, 개발자들과 관련자들이 읽기에는 너무 평이한 내용이 아닌가 싶다. 아니 기대했던 내용을 전달받지 못했다. 이러한 생각이 들기까지 책을 정독하고 나중에 다시 한번 읽으면서 내가 잘못 이해하는 부분이 있나? 라고 반문을 했었다.

처음 책을 접하고 기대했던 내용은 말 그대로 S/W와 서비스들중 개떡같이 만든 것들을 좀 열심히 비판(내지 비난)하고 많은 생각을 하게 만드는 것을 기대했는데 원하는 것은 접할 수 없었던 것 같다. 물론 책의 초반부에 언급된 개떡같은 소프트웨어들의 사용성에 대한 문제에 대해서는 동의한다. 당연하고 일반적인 이야기이기 때문이다. 그러나 중반 이후 저자는 소프트웨어 개발자가 괴짜고 그러하기 때문에 이러하다라는 것을 시종일관 말하고 있다.  두서없는 전개에 주제에 집중할 수 없는 복잡한 내용들이 무척 혼란스럽다.

가십과 관심을 끌기위한 책인가 ? 아니면 숨어있는 어떤 통찰력이 뛰어난 멋진 서술인가? 라는 판단을 좀 더 하기 위해 블로그를 뒤져 보았다. 여러 평가들이 보인다.

긍정적인 평가
http://inuit.co.kr/1457
http://www.buggymind.com/127
http://dobiho.com/?p=945
http://ggaman.com/tt/900

부정적인 평가
http://www.cozydev.com/51, 행복한 개발을 위한 블러그
http://wisefree.tistory.com , ^-^

아마 나도 부정적인 평가를 내린 사람중의 하나인 것 같다.

과거 죠엘의 블러그를 읽으면서 그의 해박한 경험을 전달받으며 느꼈던 감정을 기대했었는데 좀 아쉽다.  혹 , 개발자로서 사용성에 대한 경험이 필요한 분들은 죠엘의 블러그를 참고하길 바란다. 그리고 사용성에 대한 정보가 필요한 개발자나 기획자는 Jakob Nielsen의 블러그가 많은 도움이 될 것이다. 그리고 번역서로는 스티브 크룩의 『Don't Make Me Think 2/e』의 한글판인 상식이 통하는 웹사이트가 성공한다(2판) 상세보기 가 많은 도움이 될 것이다. 출판된 책보다는 온라인 블러그가 보다 현실적인 정보를 제공하는 것 같다. 아마도 이 책이 나오기까지의 시간동안 웹이 너무도 빨리 변하는 듯하다.

그리고 나는 소프트웨어 개발자를 괴짜라 생각하지 않는다. 그저 평범한 사람이다. 물론 개중에는 본인이 특별하다고 생각하는 개발자가 있을 수 있지만 소수라고 생각한다. 단지 새로운 것을 좋아하고 이를 받아들이는 데 일반인보다 적극적인 사람들이 개발자가 아닌가 생각한다.  힘들어도 평생 새로운 기술을 접해야만 먹고 살 수 있는게 바로 개발자란 직업이다. 오히려 이 책의 저자가 지적한 사용성의 문제는 개발자들의 문제가 아니라 소프트웨어를 포함한 모든 재화(commoditization)에 해당하는 것 같다. 항상 최초의 재화는 부족하고 모자라다. 문제는 얼마나 빨리 이것을 채우는 것인가가 경쟁력이고 이러한 회사들 만이 살아남는다.

로버트 L.글래스의 우리가 미처 알지 못한 S/W공학의 사실과 오해(Facts and fallacies of software engineering)에서 ...

구매한지 몇 달이 지난 책인데 이제서야 정독을 하고 있습니다. 개발에 있어 참고할 만한 재미난 통계 정보들이 있어 정리해 봅니다. 이 책은 소프트웨어 개발에 있어 관리, 개발 생명 주기, 품질 그리고 각 과정상에 발생하는 오류에 대해 정리하고 있습니다 .특히, 가장 개발자들이 싫어하는 유지보수에 대해 참고할 의견들이 많은 것 같습니다.

1. 관리에 대해

- Al Davis , "뛰어난 관리가 뛰어난 기술보다 중요하다."

- 소프트웨어 개발에 있어 가장 중요한 요소는 프로그래머의 자질이다"
무척 중요한 사실입니다. 사람중심의 개발에 반대되는 것이 아마 프로세스 중심의 개발이라고 할 수 있습니다. 어떤 것이 중요할까요? 물론 사람중심이 정답일 것입니다. 그러나 만약 사람 중심의 시각에서 해당 개발자가 충분한 자질을 갖지 않는다면 어떻데 될까요? 결국 이러한 문제 상황에 봉착했을 때 할 수 있는 방법은 프로세스를 만들고 이를 규정화하는 것 입니다. 물론 프로세스 기반의 개발의 경우 이를 이해시키고 강제시키는 것이 가장 어려운 일이지만요.. 자질있는 프로그래머... 참 요즘은 찾아 보기 어렵죠..!

- 최상의 프로그래머는 최악의 프로그래머보다 28배 더 뛰어나다.
- 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 지체된다."
역설적으로 우리나라 SI의 경우 이러한 사실에 정반대로 프로젝트를 관리하죠. 납기일에 맞추기 위해 막판 개발자 추가 투입.... ^-^

2. 개발 생명 주기에 대해

- 개발 생명 주기의 비율은?
요구분석 20% , 설계 20% , 코딩 20% , 오류 제거 40%

- 위기의 프로젝트의 가장 흔한 원인 2가지 중 하나는 불안정한 요구사항이다.

3. 유지보수에 대해

전체 소프트웨어 공정 비용 중 60%가 유지보수 비용이고 그중 60%가 기능 강화(enhancement)에 드는 비용이랍니다.  나머지는 17% 오류 수정 , 18%는 다른 플랫폼 지원들을 위해 드는 적응성 유지(adaptive maintenance) 비용 , 그리고 마지막 5%는 리팩토링 비용이라고 합니다.

이러한 유지보수를 위해서는 기존 시스템을 이해하는 게 정말 중요합니다.  실제 기존 시스템을 이해하는 게 유지보수에서 가장 어려운 작업입니다. 다른 사람이 설계하고 개발된 시스템을 코드를 통해 역으로 이해해야 하기 때문입니다. 평균적으로 기존 시스템을 이해하는 데 걸리는 시간은 전체 유지보수 시간중 대략 30% 정도라고 합니다. 아마 이 경우 , 기존 시스템을 잘 이해할 수 있도록 문서나 코드 들이 잘 정리돼어 있어야 겠죠.  이렇치 않을 경우 제 경험한 전체 유지보수 시간이 기하급수적으로 늘고 결국 다시 짜야 합니다 라는 담당자의 보고를 받게 됩니다 ^-^.  참고로 Fjelstedz 와 Hamlen가 정의한 유지보수의 생명주기는 다음과 같습니다.
 
-수정 사항의 정의와 이해(15%) - 시스템 문서 검토(5%)-로직 추적(25%)-수정사항 구현(20%)-테스트와 디버깅(30%)-문서 업데이트(5%)

4. 품질에 대해

소프트웨어 품질의 7개 속성 - 이식성, 신뢰성, 효율,사용편의성, 테스트 용이성, 이해 용이성, 수정 용이성

여기서 효율이란 S/W가 실행 시간과 사용 공간에 있어 얼마나 효율적인지를 의미하는 것이며 이해 용이성과 수정 용의성은 유지보수 담당자가 얼마나 쉽게 이해하고 수정을 할 수 있는지를 말하는 것입니다.  어차피 정답은 없지만 개발자로서 내가 개발하고 있는 소프트웨어가 얼마나 높은 품질을 갖고 있는 가는 의미있는 일 입니다. 물론, 생각해 보면 좌절할 수도 있겠지만요^-^.

오류의 발견 위치
- 오류의 반이 모듈의 15%에서 발견된다.
- 오류의 80%가 단지 모듈의 2% 이내에서 발견된다.
- 대락 80%의 결함이 모듈의 20%에서 나오고 모듈의 절반정도는 오류가 없다.

결국 소프트웨어는 여러 개발자가 모듈을 나눠서 개발하기 때문에 특정 모듈을 맡은 개발자에 의해서 대다수의 오류가 만들어진다고 생각할 수 있습니다. 결국 오류를 완벽하게 제거할 수 없기 때문에 모듈 개발시 난위도를 조절하여 개발 역할을 나누고 , 오류 수정은 심각한 것을 수정하는 전략이 필요하겠죠...

5, 후기
소프트웨어 분야에 있어 관리자가 아니라 개발자로 오래 남는 다는 것은 결국 자신이 그 일에 매우 능숙하게 된다는 것과 동시에 다른 부분의 사람들이 갖지 못하는 권력(?)을 갖는 것이기도 합니다. 이를 악용하는 사례들도 많이 있지만 대다수의 개발자들은 오래 동안 개발자로 남길 원할 것 입니다. 정말 코드로 승부하려는 개발자들 에게 다시 한번 격려를 보냅니다.  요즘은 그런 생각이 드네요 CTO라는 직업으로 뭘 해야 하나? ^-^. 관리자인가 개발자인가..직원인가 임원인가..