[한국 소프트웨어 산업협회] 개발자의 작업범위, 발주자의 수정요청, 대응방법

개발자는 발주자와 소프트웨어 개발계약을 체결하면서 개발자가 수행해야 할 작업의 범위가 어느 정도라는 것을 사전에 예상하고 개발기간, 계약금액 등을 결정한다.


그러나 불행하게도 계약초기 개발자가 예상한 작업범위와 실제 작업범위가 일치하는 경우는 거의 없다. 이렇게 개발작업의 범위가 일치하지 않는 원인은 계약서 상 개발자가 수행해야 할 작업범위를 명확하게 규정한 서류가 없다는 점이 일차적인 원인이고,통상 개발자는 과업내역서를 계약서에 첨부하나 그 내용이 너무나도 추상적이고 화려한 미사여구로 포장되어 있어 정작 분쟁이 발생하였을 때 개발자가 실제 작업하기로 한 과업범위를 규정하는 데 아무런 도움이 되지 못하는 것이 현실이다.


이는 개발자의 책임이라 보아야 한다. 그리고 아마도 그 원인의 대부분은 발주자가 개발이 진행되면서 개발프로젝트에 요구하는 사항들이 점차 증가되기 때문일 것이다.


발주자가 개발범위를 수정 또는 증가해 줄 것을 요청하였을 때 이에 대응하는 개발자의 태도는 다양하다.통상 개발자는 투입인력의 증가없이 초기 예상한 개발기간 내에 발주자의 추가요청사항을 끝낼 수 있다고 판단한다면 그대로 수용하는 경향이 있다. (현실적으로는 투입인력이 증가되더라도 개발기간내에 끝낼 수 있다고 판단된다면 개발자는 별다른 이의없이 발주자의 요청사항을 수용한다.)


개발자의 입장에서 발주자의 요청을 거부하기가 힘든 것이 현실이고 초기 과업범위가 불확실하게 규정되었다는 점을 감안한다면 어느 정도는 이해가 가능한 일이다.


그러나 발주자의 요청사항을 수용하면 개발기간도 늘어나고 투입인력이 더 들어 개발자에게 큰 부담이 된다는 점이 분명함에도 개발자가 아무런 조치없이 일단 발주자의 요청을 수용하는 경우는 다소 이해가 되지 않는다. 정말 아무런 조치없이. 그리고 개발기간을 맞추지 못해 발주자가 향후 지체상금을 요청하거나 개발 프로젝트가 원만하게 마무리되지 못하여 분쟁이 발생하였을 때에는 개발자는 뒤늦게 발주자의 추가 요청사항이 지체상금의 원인이고 프로젝트가 마무리 되지 못한 원인이라고 주장한다.


분쟁발생 이후에 개발자의 냉정한(?) 프로젝트 실패분석원인을 들어보면 이해가 되지 않는 것은 아니지만 이를 법원에 주장하여 개발자가 원하는 결과를 이끌어 내는 데는 대단한 어려움이 있다.


계약 초기 작성한 과업내역서로는 개발자의 작업범위를 명확하게 알기가 힘들다는 점, 이 때문에 개발자가 주장하는 발주자의 추가개발요구사항이 과연 추가요구였는지 자체가 불분명하다는 점, 발주자의 추가요청 당시 개발자가 이의를 제기한 문서가 전혀 없다는 점, (반면 개발작업에 버그가 있지만 언제까지는 수정 완료하겠다는 문서나 이메일, 개발기간을 준수하지 못해 언제까지는 개발을 완료하겠다는 문서나 이메일은 정말 흔하게 존재한다.)


소프트웨어 개발계약이 도급계약이라 발주자의 의무사항은 대금을 적시에 지급하는 것뿐이고 개발작업에서 발주자가 요청한 사항을 수용할 것인지 여부는 개발자의 업무범위라고 생각하는 법원의 시각이 있다는 점을 감안한다면 소프트웨어 개발분쟁에서 개발자의 위 주장이 그대로 받아들여지기에는 많은 난관이 존재한다.

이에 개발자는 개발작업이 초기 예상한 것과 다르게 진행되는 부분(발주자의 요청사항 때문이던, 초기 계약에서 양당사자가 명확하게 하지 못한 개발범위 때문이던)이 발생하였을 때 이를 문서로 정리하여 발주자에게 통지하는 프로세스나 습관을 가졌으면 하는 바람을 가지고 있다.(통상 이 역할은 프로젝트의 PM이 담당해야 할 것이다.) 또한 프로젝트에 문제가 있어 개발자와 발주자가 회의를 한 사실이 있다면 그 구체적인 내용을 회의록이라는 형태로 기록하여 쌍방이 보관하는 프로세스를 개발자는 가지고 있어야만 한다.


소프트웨어 개발계약서를 수 차 접해 본 필자로서는 개발자가 수행해야 할 구체적인 개발작업범위는 개발작업을 진행하면서 위에 언급한 문서를 통해서 구체화될 수 밖에 없는 특성을 가지고 있다고 판단한다. 즉, 위에 언급한 문서를 작성하는 행위는 발주자에 대한 불만, 책임전가, 경고의 메시지가 아니라 개발자가 수행해야 할 작업범위를 구체화하는 작업의 일환이라는 점을 발주자에게 인식시킬 필요가 있고 이러한 작업은 대한민국의 모든 개발회사가 과제로 가져가야 할 숙제라 생각한다.


(개발자의 구체적인 작업범위와 관련한 칼럼을 쓰면서 개발자가 활용하였으면 하는 계약조항이 문득 생각나 기재합니다. 물론 아래 기재는 예시사항일 뿐이고 다른 규정도 얼마든지 가능할 것입니다. 개발자님들에게 생각의 단초가 되었으면 합니다.)

1. 개발자의 구체적인 개발범위는 본 프로젝트의 분석, 설계가 끝난 후에 작성된 상세설계서(명칭이 중요한 것은 아닙니다.)로 한다.
2. 이 때 작성된 상세설계서를 근거로 개발자는 개발기간과 계약금액의 합리적인 조정을 발주자에게 요청할 수 있다. 이 때 발주자는 개발기간과 계약금액의 조정대신 개발범위를 조정하여 계약할 수 있다.
3. 상세설계서가 작성된 이후 초기 예상한 개발기간, 계약금액과 상당한 격차가 나 쌍방간에 원만한 조정이 되지 않는 경우 누구나 본 계약을 해지할 수 있다. 이 경우 상세설계이전까지 투입된 인원에 대한 정산을 하는 것으로 본 계약은 해지되며 쌍방은 서로에게 별도의 손해배상청구를 할 수 없다.



초기 개발범위를 확정하기 어려운 소프트웨어 개발계약의 특성을 고려하여 개발이 진행되는 어느 시점에 개발범위를 최종 확정하는 프로세스를 가지면 개발자나 발주자가 개발범위로 인해 분쟁이 발생하는 빈도가 조금 적어지지 않을까 한다.




법무법인 청우 곽용석 변호사 한국소프트웨어산업협회 자문 변호사 / 전문가그룹 대표위원

출처 : http://www.sw.or.kr/column_service/column_view.asp?masteridx=1&idx=47