소프트웨어 1:3 원리


소프트웨어 품질에 관심이 있으신
팀장님과 프로젝트 리더분들을 위해 적습니다.
특히 소프트웨어를 잘 모르시는...



소프트웨어 품질을 높이는 방법은 많습니다.
QA, Unit test, 코드리뷰, 설계강화, Tools, Automated Testing 등등
효과적이고, 프로젝트에서 필요한 것들이죠.

하지만, 이것들이 없어도,
좋은 소프트웨어 품질을 만들어 내는 엔지니어들이 있습니다.
'그럼, 과연 그게 뭘까?' 하는 질문이 들더군요.
품질을 만들어 내는 기본 바닥에 대한 이야기 입니다.



소프트웨어는 1:3을 기억해야 합니다.
정상적인 경우를 위해 100줄의 코드를 작성했다면
예외적인 경우를 위해 300줄의 코드를 작성해야 하죠.

Unit Test용 코드도 동일합니다.
일반적인 경우를 시험하기 위한 코드보다
비정상적인 경우를 시험하는 코드가 3배 많습니다.

설계도 마찬가지입니다.
정상적인 경우를 대비한 설계가 1이라고 하면
예외적인 경우를 대비하는 노력이 3정도 됩니다.

경험상, 이 수치는 복잡도가 높아지면, 점차적으로 올라가게 됩니다.
반대도 성립하고요.



소프트웨어의 품질은 바로 이 '3'에 달려있는 것 같습니다.

크게 세 가지가 영향을 미치는 것 같고요.

1. 시간
정상적인 경우만 고려하는 것이 비해
예외적인 경우도 고려하려면 3배 이상의 노력이 필요합니다.
주어지는 시간을 줄이면, 바로 이 3이라는 부분을 줄이는 거죠.

정상적인 경우에는 잘 동작하지만, 그렇지 않은 경우에는 오류가 발생하는...
그래서, 충분한 시간을 주는 것이 필요합니다.
시간을 줄여서 얻은 결과물과, 정상적인 결과물은 같지 않은 거죠.


2. 사랑
시간이 충분하게 주어져도, 품질이 좋아지지 않는 경우가 있습니다.
자신의 결과물을 사랑하지 않는 경우죠.

일의 성격을 살펴보면,
정상적인 1의 작업은 재미있는 편입니다.
이에 반해, 예외적인 3에 대한 작업은 끈기와 노력이 필요한, 덜 흥미로운 일에 해당하죠.
결과물에 대한 애착이 없다면, 왜 이런 재미없는 일을 굳이 하려고 하겠습니까.

애사심, 열정, 장인정신,
이런 것들이 보이지 않는 원동력인 것 같습니다.


3. 능력
자신의 결과물을 사랑하고, 충분한 시간이 주어져도 품질이 좋아지지 않는 경우는
자신의 능력에 맞지 않는 일을 하는 경우인 것 같습니다.

10이라는 능력을 가졌는데, 난이도 20의 일을 맡기면 잘할 수 없죠.
팀원의 능력을 파악하고, 그에 걸맞는 일을 맡기는 것이
바로 팀장의 기본적인 역할입니다.




시간, 사랑, 능력
이것이 소프트웨어 품질의 근본을 결정짓는 세 가지 요소인 것 같습니다.

그나저나,
어느 관리 팀장님의 말씀이 생각나는 군요.

"애사심을 갖도록 하는 것이 이렇게 어려운 일인 줄 몰랐다."


고맙습니다.

by 제임스 | 2012/03/13 12:52 | 메인스토리 | 트랙백 | 핑백(1) | 덧글(15)

트랙백 주소 : http://jamestic.egloos.com/tb/2910938
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Linked at 소프.. at 2012/04/13 00:11

... ... more

Commented by L君 at 2012/03/13 13:31
좋은 글 잘 읽고 갑니다 !!!
Commented by 제임스 at 2012/03/13 19:03
감사합니다. L군님
봄이 좀처럼 오지를 않네요 ^^
Commented by 천하귀남 at 2012/03/13 13:58
어느 회사가 생각나는군요. 주인정신을 가지라고 하는데 사소한것 하나까지 내결정은 무시되면 노비근성만 남더군요.
Commented by 제임스 at 2012/03/13 19:03
그르게요. 이야기 하는 것과 행동하는 것이 일관되기만 하면 되는데
이게 참 어렵죠. 천하귀남님, 상처를 많이 받으셨나 봅니다.
Commented by 날치 at 2012/03/13 14:46
예외 적인 상황 처리를 위해서는 "충분한 시간"으로 해결이 되질 않는 것 같아요 "파일이 존재하지 않는 상황"과 "누군가 랜케이블을 잘라먹는 상황"까지...

아이러니 하게도 결국 경험을 통해서만 이 예외 적인 상황을 상정 할 수 있는 것 같습니다.

"예외 상황에 의해 발생한 버그" 때문에 내상을 입지 않는 개발자가 되는 게 생존의 조건 중 하나인듯...
Commented by 제임스 at 2012/03/13 19:04
네, 그렇죠.
능력이라면 경험도 포함하는 거죠.
전문가라는 것이 결국 많은 실수를 경험해서, 예외적인 경우을 잘 아는 사람이자나요.
지적해주신 예를 보니, 날치님도 상당한 경험이 있어 보여 좋습니다.
Commented by 해색주 at 2012/03/13 18:23
좋은글 잘 읽었습니다
Commented by 제임스 at 2012/03/13 19:05
네, 해색주님, 고맙습니다.
사진으로 처음 뵙네요. ^^
4명의 아이들과, 와튼스쿨 티셔츠가 인상적이에요~
Commented by 해색주 at 2012/03/14 00:30
작은 처남이 아이들은 와튼 스쿨 보내라고 해서 보내준겁니다. 사랑과 능력치만 맞아도 좋은 게 나오지 않나 싶어요. 사랑만 있어도, 공부해서 능력치 올리고 자기 게임 캐릭터 만들듯이 올릴 수 있으니깐요.
Commented by 제임스 at 2012/03/14 17:08
아 그런거군요. 작은 처남 희망대로 아이들이 와튼 스쿨 학생이 되면 참 좋겠네요. 그러면서도 아버지와 좋은 친구이길 바라고요. 네에, 사랑이 그 중에 으뜸이죠. 미쳐야 미친다. 뭐 그런~
Commented by 이종훈 at 2012/03/14 13:06
테스트를 위한 일정은 무시한 프로젝트 마일스톤이 많습니다.
이런 상황에서 발생하는 제품을 그 누가 사겠습니다.
어느 개발자가 적극 개발하겠습니까?

개발자는 쪼이고, 제품은 안나오고, 원인은 연구소로 돌아오고, 개발자는 스트레스 받고...

1:3 원칙과 3대과제를 적극 알려야겠습니다.
잘 읽었습니다.
Commented by 제임스 at 2012/03/14 17:08
네, 이종훈님. 안좋은 경험이 많으신가 봅니다. 무척 리얼하게 다가오네요. 엔지니어로서 좋은 제품을 만들고 싶은데, 주어진 환경 때문에 그렇지 않게 된다면 참 속상하죠. 팀장님과 경영하시는 분들의 배려가 꼭 필요합니다. ^^
Commented at 2012/03/22 11:42
비공개 덧글입니다.
Commented by 제임스 at 2012/03/22 17:46
아. 그런거군요. 하하
어떻게 하면 비공개 채널로 이야기 하지? 하다가 보니 메일이 있었네요.
다음주에 제가 메일 한통 보내드리겠습니다~ 곧 뵙죠.
Commented by 미물 at 2012/03/23 09:28
넵.. ㅋㅋ

:         :

:

비공개 덧글

◀ 이전 페이지          다음 페이지 ▶