행복한 아빠

프로그램 경제학 본문

하고싶은말

프로그램 경제학

행복한아빠 2009. 12. 21. 10:02
개발자라면 시간이라는 제약에서 벗어날 수 없습니다. 항상 마감에 쫓기고 내게 할당된 시간보다 항상 요구사항이 더 많습니다. 비단 개발자에게만 해당되는 이야기는 아니지만, 제한된 시간이라는 자원을 어떻게 활용하느냐에 따라 그 사람의 능력이 좌우됩니다. 프로그래머는 어떻게 자원을 슬기롭게 활용해야 할까요?
이미지출처: http://www.flickr.com/photos/lapideo/198046070/


나의 최대 프로그램 에너지
위에서 우리가 쓸 수 있는 자원을 시간이라고 이야기했지만 사실 우리 작업은 여러가지 요소에 영향을 받을 수 있고, 밥먹듯 야근하거나 철야하면 자원(시간)을 어느정도 더 확보할 수 있다는 점이 있습니다. 그래서 그냥 자원을 "올바른 프로그램을 얼마나 많이 만들어 낼 수 있는가"를 그냥 제 맘대로 에너지로 표현했습니다.


첫번째 그림은 한정된 기간에서 밤새워 가며 시간을 늘리면 품질이 떨어지는 경향을 나타냅니다. 품질이 떨어지면 에러와 버그를 처리해야 하는 시간을 또 사용하여야 하기 때문에 생산성 감소로 이어집니다. 따라서 두번째 그림처럼 한정된 기간에서 시간을 늘려도 어느 순간은 생산성이 높아지지 않습니다.

한정된 기간 내에서의 우리가 프로그램에 쏟을 수 있는 에너지는 제한적이라는 겁니다. 아무리 밤새워도 그게 그만큼 늘어나지는 않습니다. 다만 옆에 쓰러져있는 전우의 시체를 볼 뿐입니다.


과다 설계
한정된 에너지를 어떻게 배분해서 사용해야 하는지에 대한 문제가 남았습니다.
우리는 설계나 코딩(설계/코딩 구분하지 않습니다)할 때 수 많은 의사결정을 합니다. 특히 잘 설계된 애플리케이션을 만들기 위해 앞으로의 확장에 대해 고려할 때가 많습니다.
그러면 이렇게 확장이 쉬운 설계가 항상 옳은 것일까요? 현재는 없지만 앞으로 추가될 기능에 대해 고민하고 설계를 진행하지 못하는 경우를 많이 봤습니다. 이 말을 기억하면 좋겠습니다.
자기가 고민하는 것들 중 실제 일어나는 일은 1%도 안된다.
너무 과장된 말이겠지만 실제 고민하는 일 중 일어나는 것은 극소수입니다. 지금 고민하고 있는게 앞으로 확실히 일어날 것이 아니라면 설계에서 과감히 빼는게 좋습니다. 이유는 다음과 같습니다.

1. 확장설계는 어렵습니다. 앞으로 일어날 것 같은 일을 설계하는 것은 많은 에너지를 소비합니다.
2. 유지보수해야 합니다. 확장된 설계는 보통 복잡해지기 마련입니다. 복잡해진 이것도 유지보수해야 합니다. 복잡해진 프로그램 에러도 잡아야 하고 버그도 잡아야 합니다. 여기에 에너지 또 쏟아야 합니다.
3. 뜻하지 않은 변경에 취약합니다. 예상한데로 변경이 발생하면 행복하겠지만 항상 내가 뜻하지 않는 방향으로 요구사항이 변하기 마련입니다. 복잡해진 설계를 바꾸는 건 훨씬 많은 에너지를 소비합니다.
3. 없어질 수도 있습니다. 요구사항은 변화무쌍합니다. 힘들게 공들여 만든 기능이 필요 없어질 가능성은 얼마든지 있습니다. 이 경우 그 기능은 삭제하는게 좋습니다. 유지보수 비용 들어가니까요. 그동안 그 설계에 쏟은 에너지 쓸모 없게 됩니다. (피눈물 나지요)

여기에 쏟은 에너지 때문에 진정 써야할 곳에 쓰지 못하는 경우 종종 보았습니다. 예를 들어 열심히 배운 멋진 디자인 패턴을 확장(?)을 위해 억지로 프로그램에 끼워넣는 경우가 그렇습니다. 고객 관점에서 진짜 내가 에너지를 쏟아야하는 부분이 어디인지 잘 판단하십시오.

설계할 때 확장보다는 애플리케이션이 가져야 할 본질(essence)을 찾는데 주력하세요. Essence는 의외로 단순한 경우가 많습니다.

비용 비교
앞으로 추가될 것 같은 기능이 있습니다. 추가될 가능성을 10%라고 가정합니다. 이 기능확장을 위해 쏟아야할 에너지가 100 이라고 가정합니다.
반면 이 기능확장 준비를 하지 않은 상태에서 앞으로 이 기능이 추가되면 2배 힘들어질 거라고 가정합니다. 즉 200의 에너지가 소비됩니다. (헉.. 준비해야 할 것 같군요)

- 기능확장을 준비할 경우
말할 것 없이 100 이라는 에너지를 투입합니다.

- 기능확장을 준비하지 않은 경우
에너지 투입이 될 수도 있고 그렇지 않을 수도 있습니다. 이런 경우 통계적으로 기대값을 계산합니다.
기대값 : 투입비용(200) x 확률 (10%)  = 20
20 정도만 프로젝트 차원에서 에너지를 준비하면 됩니다. 확실히 경제적으로도 이게 좋습니다.

이건 그 기능이 추가될 확률에 의해 투입비용 대 기대값이 결정됩니다. 그러나 일어날 것 같은 일 대부분은 생각보다 일어나지 않는 사실을 기억하세요.


해결책
현재 요구사항에 충실한 설계를 하는게 에너지를 아끼는데 좋습니다. 현재 시점에서 설계의 본질을 찾아 단순화시키고 아끼고 아낀 에너지는 설계나 프로그래 기본에 충실하는데 쓰시는게 좋습니다. 설계에서 쓸데없는 가지를 치거나 코딩 표준을 맞추거나 주석 충실히 달아 놓으세요. 그리고!! 단위 테스트 보강하시는 것 잊지 마십시오. 차라리 여기에 에너지를 쏟으세요.


변화에 대한 대응법
이제 우리는 단순한 설계와 프로그램 기본에 충실했고 무려 70% 이상의 코드 커버리지를 가지는 단위테스트가 있습니다. 요구사항은 항상 내가 상상하는 것 그 이상이었습니다. 그러나 요구사항 변경 두렵지 않습니다. 요구사항 변경에 따른 기존 코드 삭제 그렇게 아깝지 않습니다.

변경하다가보니 비슷한 부분이 3번이상 발견되었습니다. 합치면(추상화) 뭔가 단순해질 것 같습니다. 그 때 추상화하여 확장포인트를 만듭니다.점점 현실에 잘 적응하는 애플리케이션이 만들어집니다.

미래의 일을 정확히 예언할 수 있는 부채도사라면 확장설계도 나쁘지 않습니다.
우리가 그런 부채도사는 아닙니다. ^^


2 Comments
댓글쓰기 폼