'폭포수 방법론' 검색 결과 1건

  1. 2009.02.02 설계가 완벽하지 않아야 하는 이유 (10)

설계가 완벽할 수 없는 이유를 읽고 씁니다.

저는 윗 글에 동의합니다. 설계는 완벽할 수 없습니다(사실 명제). 그리고 저는 설계를 완벽하게 하는 것이 가능하다고 하더라도 그렇게 해서는 안된다고 생각합니다(가치 명제).


1. 설계가 완벽할 수 없는 이유

소프트웨어는 소프트한가?에서도 인용한 적이 있고, 윗 글에도 나와있지만 짧게 요약하자면 세상이 바뀌거나, 내가 더 똑똑해지기 때문에 완벽한 설계란 좀처럼 얻어내기가 힘듭니다.

하지만 가정을 해봅시다. 세상(and/or 요구사항)이 바뀔 일도 없고, 나는 이미 천재이고 모든 도메인 지식을 다 가지고 있기 때문에 더이상 똑똑해질 일도 없다고 칩시다. 그렇다면 설계가 완벽해질 수 있을 것입니다. 그런데, 설계를 완벽하게 하고나서 코딩을 시작하는 것이 과연 좋을까요?


2. 설계가 완벽하지 않아야 하는 이유

2.1. 완벽한 설계의 가치

완벽한 설계(design)라는 가정 이면에는 완벽한 분석(analysis)이 전제되어 있습니다. 하지만 설계는 설계일 뿐 작동하지 않습니다(Executable UML 같은 시도도 있지만 뻘짓으로 간주하겠습니다). 그리고 작동하지 않는 소프트웨어는 고객에게 아무런 가치를 전달하지 못합니다.

즉, 완벽한 분석에 이어 완벽한 설계를 하느라 프로젝트 기간의 (이를테면) 절반 정도가 지나도 프로젝트는 아무런 가치를 창출하지 못합니다. 그 이후에 구현 조금, 테스트 조금, 배포 조금 하는 방식을 따른다면 이 때부터 가치가 창출되기 시작하겠지만 선행 분석/설계를 하는 프로젝트의 대부분은 끝까지 그 스타일을 유지하죠. 완벽한 설계 이후에는 완벽한 구현과 완벽한 테스트 단계가 오고, 그제야 완벽한 배포를 하는 소위 완벽한 폭포수(waterfall) 프로세스가 완성됩니다. 결국 프로젝트가 완전히 끝나야 가치가 전달되기 시작합니다.

2.2. Self-funding point와 BEP

애자일 방법론에서는 사용자에게 가치를 주는 작은 기능들을 단위로 하여 약간의 분석/설계/개발/테스트/배포를 짧은 주기로 반복합니다. 따라서 프로젝트 초창기부터 작동하는 소프트웨어를 고객에게 전달할 수 있게 됩니다. 다음은 폭포수 방식과 애자일 방식의 차이를 극명하게 보여주는 그래프입니다:


출처: The Origin of Value

참고로, Self-funding point란 프로젝트에서 발생하는 수익이 프로젝트를 지속하기 위한 비용과 일치하는 지점을 말합니다. 이 지점을 지나면 프로젝트는 소위 "밥벌이"를 한다고 볼 수 있습니다. 한편, 프로젝트에 현재 투입되고 있는 비용을 지속적으로 자체 충당(self-funding)하면서, 그 이전에 투입된 비용까지 다 갚아버리는 지점을 BEP - 손익분기점 - 라고 합니다.

빨간 선은 프로젝트에 투입되는 비용입니다. 위 그래프에서는 애자일이나 폭포수나 투입되는 비용이 동일한 것으로 간주하고 있습니다. 애자일 방법론을 실천하는 사람들은 애자일 방법론이 더 저비용일 것이라고 주장할 것이고, 폭포수 방법론을 실천하는 사람들은 폭포수 방법론이 더 저비용일 것이라고 주장할 것인데, 이 부분에서는 일단 중립을 지켜보도록 하죠.

녹색선은 애자일 프로젝트가 만들어내는 가치입니다. 짧은 이터레이션을 돌면서 잦은 릴리즈를 하기 때문에 프로젝트 초반부터 가치를 생산하기 시작합니다. 파란선은 폭포수 프로젝트가 만들어내는 가치입니다. 앞에서 설명한 이유로 인해 프로젝트 막바지가 되어야 가치가 생산되기 시작합니다.

녹색선은 애자일 방법론에 유리한 방식으로 약간 편향되어 있는데, 좀 더 공평하게 하자면 기울기가 초기에는 낮다가 점점 높아지는 꼴을 취해야 합니다. 왜냐하면 초반에는 기능의 수가 적기 때문이죠. 그래프를 그런 식으로 수정하고 나면 애자일 프로젝트의 self-funding point가 조금 더 늦춰지겠지만 여전히 폭포수 프로젝트에 비해서는 빠르겠죠. 그리고 이 상태가 유지된다면 애자일 프로젝트가 폭포수 프로젝트에 비해 훨씬 이른 시기에 BEP(break-even point. 손익분기점)에 도달합니다.

추가: 위 그래프에서 애자일 방법론의 self-funding point라고 한 부분은 사실 BEP로 표시되어야 하는데 잘못 표시한 것이 아닐까 싶습니다. self-funding point는 녹색선의 기울기가 빨간선의 기울기와 같아지는 지점이어야겠죠. 이 그림보다 예쁜 그림이 Software by Numbers 본문에 나오죠:

이 그림에서는 기울기의 변화와 면적을 보시면 됩니다. 초기 투자 기간(Investment period)의 기울기가 서서히 변하고 있는 까닭은 초기부터 가치를 전달하고 있기 때문입니다. 하지만 아직은 비용이 더 크기 때문에 전체적인 가치(면적)는 마이너스 입니다. 하지만 특정 지점(self-funding point)에 이르르면 프로젝트에 투입되는 비용과 프로젝트가 창출하는 가치가 같아집니다(기울기가 0). 그 이후엔 투입되는 비용은 고정된 반면 창출되는 가치는 점점 늘기 때문에(지속적인 릴리즈) 기울기가 점점 높아집니다. 이 기간동안 초기에 투입된 비용을 갚아나갑니다(payback period). 이 상태가 지속되면 어느 순간 손익분기점(break-even time)에 도달하고 그 이후부터는 수익이 발생하기 시작합니다.


2.3. 프로젝트 중단

프로젝트가 잘 굴러가고 있다가도 갑자기 중단되는 경우가 있습니다. 일선 관리자들이나 개발자 같은 실무자들은 대체 왜 그런 결정이 내려졌는지 자세히 알지 못하는 경우가 많지만 어쨌건 빈번하게 발생하는 일입니다. 위 그래프에서 x축으로 10 정도 되는 지점에서 프로젝트가 중단되었다고 칩시다.

그래프 상으로 애자일 프로젝트는 이미 BEP를 지나 수익을 발생시키고 있지만 폭포수 프로젝트는 아직 투자 단계입니다. 사실 재무/회계 관점에서 소프트웨어 프로젝트가 거대한 블랙박스로 인식되지 않고 릴리즈 단위로 인식될 수 있다면 애자일 프로젝트는 self-funding point 이후엔 어지간해서는 중단될 이유가 없어집니다(재무/회계 관점에서 당장 그렇게 인식되지 않는다 하더라도 적어도 방어 논리를 약간은 만들어낼 수 있을겁니다).

여기서 강조하고 싶은 이야기는, 재무/회계 관점에서 소프트웨어 프로젝트가 좀 더 정밀하게 분석되면 될수록 폭포수 방식의 문제가 더 크게 부각될 것이라는 점입니다.

2.4. 재고와 도요타 생산 방식

과잉 재고는 나쁜 것입니다. 1) 재고를 최소화하고, 2) 공정 상의 흐름이 끊기지 않게 하고, 3) Push 방식이 아닌 Pull 방식을 채택하면 일단 표면적인 도요타 생산 방식이 만들어집니다. 이 중에서 이 논의와 특히 관련이 깊은 것은 앞의 두 가지 입니다. 소프트웨어에서의 재고란 노력이 투입되었으나 아직 최종 사용자의 가치와 연결되지 않은 모든 것을 말합니다. 완벽한 설계는 전형적인 재고입니다. 둘째, 공정 상의 흐름이 끊어지지 않으려면 각 단계에서 작은 단위로 끊임없이 가치가 흘러야 합니다. 앞 단계에서 거대한 작업이 끝날 동안 뒷 단계에서 손 놓고 대기하고 있으면 흐름이 끊어지는 것입니다. 완벽한 설계는 흐름을 끊기게 하는 주요 원인입니다. 완벽한 분석, 완벽한 구현,완벽한 테스트도 마찬가지 입니다.

(얼마 전에 프로젝트 시작부터 개발자가 바글바글이라는 글을 읽었는데, 프로젝트 시작부터 개발자가 바글바글한 것이 문제인 이유는 공정 상의 흐름이 끊기기 때문입니다. 즉, 앞의 공정(완벽한 분석과 설계)이 끝나지 않으면 개발자가 놀아야 하는 것이 문제인거죠. 이에 대한 해법은 두 가지입니다. 하나는, 처음엔 개발자 없이 시작해서 프로젝트 중간에 개발자를 투입하는 것, 또 하나는 공정이 끊기지 않게 해서 초반부터 개발자가 일을 할 수 있게 하는 것.

하지만, 전자의 방식대로 하려면 조직 구조가 인력 풀 방식 혹은 직군별 팀 방식으로 운영되어야 하고 각 프로젝트의 특정 단계에 소위 "투입"되거나 "파견" 나갔다가 해당 단계가 끝나면 "철수"하는 식으로 일을 해야 합니다.

이러한 조직 구성이 효과적인 면도 분명 있겠지만 저는 별로 인간적인(humane) 방식이 아니라고 생각하고, 인간은 인간적인 방식으로 일해야 즐겁고 효과적으로 일할 수 있을 것이라고 믿습니다. 이 문제는 다음 기회에 더 쓰도록 하겠습니다. Ray님 블로그의 글은 잘 읽고 있습니다만 워낙 서로의 경험이 다르기 때문인지 의견 차이가 큰 것 같습니다. 그래서 더 열심히 읽고 이해하려고 노력하고 있습니다.)

이 밖에 "The Goal"의 제약이론도 관점이 약간 다르지만 이와 유사한 내용을 담고 있죠. 이에 대해서는 도요타 방식과 제약이론이라는 글을 참고해주세요.


3. 결론

이러한 이유로 저는 완벽한 설계가 가능하다고 하더라도 완벽한 설계를 하지 않는 것이 더 좋다고 생각합니다.


저작자 표시
신고
< Newer     Older >

티스토리 툴바