Search Results for '외주'

1 POSTS

  1. 2007.11.02 소프트웨어 개발 계약: 이론 vs 현실 6
학교 다닐 때 소프트웨어 공학 책에서는 일단 요구사항을 뽑고 명세서를 작성한 후에 이를 근거로 비용을 계산하고 프로젝트가 완료되는 시점을 결정하는 완료 테스트(acceptance test)를 설계해야 한다고 배웠습니다. 물론 예기치 않은 요구 사항 변경에 대해서는 일정 지연이나 초과 예산에 대해 갑이 책임을 져야 한다는 조항도 들어가야 할 테고요.

하지만 제가 소프트웨어를 개발해 오면서 겪은 상당수의 소프트웨어 개발 계약(대부분 소규모이긴 하지만)은 매우 주먹구구식이었습니다. 매우 불투명한 목표(요구 사항)를 설정한 후에 일단 투입 인원과 일정을 고정시키고 이를 근거로 비용을 산출하는 방식이죠. 일단 비용과 일정이 고정되어 있는데 소프트웨어 추정 기술이 무슨 필요가 있는지도 모르겠습니다.

구체적인 요구사항은 계약이 이루어진 후에야 작성되는데, 이 과정부터 이제 갑과 을은 심리전을 치러야 합니다. 이미 계약은 이루어졌으니 갑 입장에서는 최대한 뽑아낼 건 뽑아내야 하고, 을 입장에서는 이미 받기로 한 돈은 정해져 있으니 일을 최소한으로 만드는 것만이 살아날 길입니다. 이렇게 불온한 동거가 시작되면서 프로젝트는 난항을 겪게 됩니다.

이렇게 밀고 당기기를 거듭한 끝에 초기 요구사항을 확정했다고 해도 안심할 것은 못 됩니다. 요구사항 변경에 대해 어떤 조항도 없었기 때문에 갑 입장에서는 쉽게 변경 요청을 합니다. 물론 을 입장에서는 시간을 끌고 버티면 안 해줄 수도 있기 때문에 최대한 못하겠다고 우는 소리를 하며 버티는 것이 일반적입니다.

일이 끝나는 시점도 분명하지 않습니다. 일정보다 일을 빨리 끝내면 일을 더 만들어서 줄 것이 뻔하기 때문에 일정은 절대로 단축되지 않습니다. 또한 개발이 완료되었다고 해도 유지보수에 대해서도 별도의 계약이 없었기 때문에 '의리상 지원 기간'이라는 개념이 생깁니다. 향후 추가 계약을 염두에 두고 마음 같아서는 관두고 싶지만 의리상 해주는 유지보수가 생기는 거죠.

이론과 현실의 차이 때문에 괴리감이 큽니다. 제대로 된 계약을 하는 방법은 어떤 게 있을까요?