'소프트웨어 변경 비용' 검색 결과 1건

  1. 2009.01.02 소프트웨어는 소프트한가? (4)

"소프트웨어는 소프트하지 않다"를 읽고 씁니다.


1. 소프트웨어 변경 비용 모델들

소프트웨어의 기능을 변경하고자 할 때 비용이 적게 들면 이를 두고 "소프트"하다고 표현합니다. 전통적으로는 프로젝트가 시작되고 시간이 흐를수록 변경 비용이 기하급수적으로 증가한다고 말합니다. 즉, 프로젝트 초창기에는 소프트하지만 시간이 지날수록 점점 소프트하지 않게 된다는 얘기입니다. 그림으로는 보통 이렇게 그립니다:

[그림1. 전통적 모델]

Y축이 비용(Cost), X축이 시간(Time) 입니다. Barry Boehm이 대략 30년 전에 그린 그림인데 여전히 많이 인용되고 있죠. 프로젝트 초기 단계에는 구현된 결과물이 없을 테니 변경이라는 것은 고작 머리 속 생각을 바꾸는 정도일 것이고 변경 비용은 거의 0에 가깝습니다. 한편, 프로젝트가 완료되고 현장에 배치(deploy)되거나 포장되어 매장에 출시된 후에 기능을 수정하고자 한다면? 엄청난 비용이 들 수 있습니다. 일견 맞는 말 같습니다.

하지만 10년쯤 전 Kent Beck은 소프트웨어 변경 비용을 아래와 같이 낮출 수 있다고 말합니다:

[그림2. Kent Beck의 그래프]

애자일 방법론의 여러 실천법(agile practices)을 통해 그렇게 할 수 있다고 주장합니다. 간결한 설계, 지속적 통합, 잦은 릴리즈, 테스트 주도 개발, 리팩토링, 짝 프로그래밍, 전체 팀 등 다양한 요소들이 이러한 변경 비용을 가능하게 해준다고 말합니다.

이 두 가지 극단적인 주장들(그림으로만 보자면)의 중간쯤 되는 모델들도 있죠. 이를테면 Poppendieck 부부의 Lean Software Development에서는 그래프 두 개를 합쳐놓아야 한다고 주장합니다:

[그림3. 짬뽕1]

크리스탈 방법론으로 유명한 Alistair Cockburn이나 IBM의 Scott Ambler 등도 이와 비슷한 모델을 제시했었죠. David  Anderson은 Agile Management for Software Engineering이라는 책에서 이를  S-Curve 모델이라고 부릅니다:

[그림4. 짬뽕2]

대충 두 부류로 나누자면 Boehm의 그림(1번)을 전통적 변경 비용 모델로, 나머지 그림들(2,3,4번)을 애자일 변경 비용 모델로 볼 수 있겠습니다.


2. 소프트웨어가 소프트해야 하는 이유

실제로 소프트웨어가 소프트한지 아닌지(사실 명제)를 이야기하기 전에, 소프트웨어가 소프트해야 하는지 아닌지(가치 명제)를 따져보면 좋겠습니다.

소프트웨어 프로젝트가 실패하는 원인 중 단골로 꼽히는 것이 “요구사항의 잦은 변화”입니다. 요구사항의 변화 빈도를 낮추면 성공 확률을 높일 수 있다는 해석이 가능합니다. 변화 빈도를 낮추려면 소프트웨어가 소프트하지 않다는 인식을 심어주어야 합니다.

한편, “요구사항의 잦은 변화”라는 문제에 대해 근본원인분석(root cause analysis)을 해보면 다른 해법을 찾을 수도 있습니다. 애초에 요구사항이 자주 변하면 왜 문제가 되는지를 따져보는 것이죠. 그 이유는 당연히 변경 비용이 크기 때문입니다. 그렇다면 변경 비용이 대체 왜 큰 것인지를 다시 물어보는 것이죠. 결국 변경 비용을 증가시키는 원인을 찾아서 이를 충분히 제거할 수 있다면 요구사항의 잦은 변화는 더 이상 문제가 아니게 됩니다.

이와 같이 “요구사항의 잦은 변화”라고 하는 동일한 문제에 대해 서로 다른 두 가지 해법이 존재합니다. 이 두 가지 해법 중 어느 것이 더 나은 방법일까요? 애자일 방법론에서는 당연히 후자가 나은 방법이라고 말합니다.

프로젝트 성공률을 높이기 위해 요구사항의 변화를 막는 것은 기본적으로 Win-Lose 게임입니다. 프로젝트가 성공하면 개발사는 돈을 받을 수 있어서 좋지만 개발을 의뢰한 고객은 프로젝트가 진행되는 동안 발생한 시장의 변화에 맞추어 요구 사항을 수정할 기회를 포기해야 하니까요. 게다가 시장이 변하지 않더라도 요구 사항은 수정될 수 있습니다. 왜냐하면 프로젝트가 진행되는 동안 시장에 대한 우리의 지식이 변하기 때문입니다. (코드가 바뀌어야 하는 이유 참고)

따라서 소프트웨어는 소프트해야 합니다.


3. 소프트웨어는 소프트한가?

소프트웨어가 소프트한게 좋다고 치고, 그럼 과연 소프트웨어는 실제로 소프트할까요? 이게 중요한 질문일 수 있죠. 하지만 이 질문은 사실 예/아니오 질문이 아닙니다. 정도(degree)의 문제입니다. 따라서 질문을 바꿔야죠.

“소프트웨어는 얼마나 소프트한가?”

이 질문에 대해서도 대답하기가 쉽지 않습니다. 왜냐하면 어떤 소프트웨어이냐에 따라 다르고, 우리가 프로젝트를 어떻게 수행 하느냐에 따라 다르기 때문이죠. 그래서 질문을 또 바꿔야겠습니다:

“소프트웨어는 얼마나 소프트해질 수 있는가?”

질문을 이렇게 바꾸면 답을 할 필요가 별로 없어집니다. 소프트웨어는 소프트해야 한다는 위 논의에 동의하기만 한다면, 이 질문에 대한 답이 없어도 질문을 보는 순간 우리가 뭘 어떻게 해야 하는지 감이 오기 때문이죠.

우리는 소프트웨어가 최대한 소프트해지도록 노력해야 합니다. 고객에게 소프트웨어가 소프트하지 않다는 인식을 심어주기 위해 노력할 것이 아니라, 양자가 어떻게 협업을 해야 소프트웨어가 주어진 상황 하에서 조금이라도 더 소프트해질 수 있는지 알아내기 위해 노력해야 합니다.

이상적인 얘기라고 생각하실지 모르겠습니다. 그럴지도 모르죠. 특히나 내부 고객을 상대하는 상황이 아닌 대다수의 SI 프로젝트에서는 꿈 같은 얘기일 수도 있습니다.

이게 가능하냐 안 가능하냐를 떠나서 우리가 지향할 바가 무엇이냐에 대한 얘기라고 생각해주시기 바랍니다.


4. 관련자료


저작자 표시
신고
< Newer     Older >

티스토리 툴바