노노니 | 실전 서비스 기획자의 인사이트 블로그

외주로 서비스를 개발하고 막상 결과물을 받아보니 처음 기획서와 전혀 다른 모습이라면 정말 당황스러울 수밖에 없습니다. 시간과 비용을 투자했는데 원하던 것과 다른 결과물을 받았다면 이것을 그대로 받아들여야 할까요, 아니면 법적으로 대응할 수 있을까요? 기획서의 법적 효력과 실질적인 대응 방법을 이해하는 것이 중요합니다.

 

기획서의 법적 지위

기획서는 작업의 가이드이자 작업의 범위가 됩니다. 계약서에서 포괄적으로 정의한 서비스의 내용을 구체화한 문서가 바로 기획서입니다. 따라서 기획서는 단순한 참고 자료가 아니라 계약의 일부로서 법적 효력을 가집니다.

기획서에 명시된 기능, 화면, 프로세스는 외주사가 반드시 구현해야 하는 작업 범위입니다. 발주자와 외주사 모두 기획서를 기준으로 작업 범위와 완료 여부를 판단하게 되므로, 기획서는 매우 중요한 법적 근거 자료가 됩니다.

 

합의된 변경은 문제없음

기획서와 결과물이 달라도 기획서보다 더 나은 방법을 논의하여 작업한 경우 문제가 없습니다. 프로젝트를 진행하다 보면 더 효율적이거나 사용자 경험이 좋은 방법을 발견하게 되고, 발주자와 외주사가 협의하여 기획서를 수정하는 경우가 있습니다.

이렇게 양측이 합의하고 회의록이나 문서로 변경 사항을 기록했다면 수정된 내용이 새로운 작업 기준이 됩니다. 중요한 것은 변경이 일방적이 아니라 쌍방의 합의에 의한 것이어야 한다는 점입니다.

 

법적 대응이 가능한 경우

분명히 기획서가 있는데도 불구하고 기능을 변형시키고, 작업해야 할 부분을 누락하거나 개발해야 할 부분을 개발하지 않고 개발한 것처럼 보이도록 만든 경우 법적 대응이 가능합니다.

예를 들어 기획서에는 결제 기능이 명시되어 있는데 구현하지 않았거나, 회원 등급별 권한 관리가 있어야 하는데 단순하게 만들어버렸거나, 관리자 페이지의 통계 기능을 빼버린 경우가 이에 해당합니다. 특히 겉으로는 완성된 것처럼 보이지만 실제로는 작동하지 않는 기능을 넣어둔 경우는 더욱 문제가 됩니다.

 

작업 완료의 기준

작업의 완료는 발주사가 제시한 범위를 맞추고 약속한 품질을 달성하는 것이 조건입니다. 단순히 외주사가 "작업 끝났습니다"라고 말한다고 해서 완료된 것이 아닙니다.

기획서에 명시된 모든 기능이 구현되어야 하고, 각 기능이 정상적으로 작동해야 하며, 약속한 성능과 품질 기준을 충족해야 완료라고 할 수 있습니다. 테스트를 통해 버그가 없는지 확인해야 합니다.

 

대금 지급 거부와 환수

발주자가 원하지 않는 작업물로 완료했다고 한다면 결과물에 대한 인수를 하지 않을 것이고 대금의 지급이 없을 뿐만 아니라 이미 지급한 비용도 환수 요구하게 됩니다.

계약서에는 일반적으로 작업이 계약대로 완료되지 않았을 경우 잔금 지급을 거부하고 작업물을 인수하지 않을 수 있다는 조항이 포함되어 있습니다. 더 나아가 외주사의 귀책으로 작업이 완료되지 못했다면 이미 지급한 선금과 중간금의 환불을 요구할 수도 있습니다.

 

법적 대응의 현실

하지만 법적 대응까지 가면 문제가 커지고 발주자가 손해를 보게 됩니다. 소송에는 시간과 비용이 들고, 그 사이에 서비스 출시는 계속 미뤄집니다. 소송에서 이기더라도 실제로 대금을 회수하기까지 오랜 시간이 걸릴 수 있고, 외주사의 재정 상태에 따라서는 회수 자체가 불가능할 수도 있습니다.

따라서 법적 대응은 최후의 수단으로 남겨두고, 문제가 커지기 전에 예방하고 관리하는 것이 훨씬 현명합니다. 소송으로 가는 것보다 프로젝트를 성공적으로 완료하는 것이 모두에게 이익입니다.

 

주간 단위 관리의 중요성

외주 일정 내내 매주 작업의 진행과 결과를 확인하여 원하는 결과물이 나오도록 관리해야 합니다. 정기 미팅을 통해 그 주에 완료된 작업을 직접 확인하고, 기획서와 일치하는지 점검하세요.

문제가 발견되면 즉시 지적하고 수정을 요구하세요. 초기에 발견한 문제는 쉽게 수정할 수 있지만, 프로젝트 말미에 발견한 문제는 수정하기 어렵거나 불가능할 수 있습니다. 작은 편차도 누적되면 큰 차이가 되므로, 매주 꼼꼼히 확인하는 것이 중요합니다.

 

기획서 변경 시 문서화

프로젝트 진행 중 기획서를 변경할 필요가 있다면 반드시 문서로 남기세요. 회의록에 어떤 부분을 왜 변경하기로 했는지 명확히 기록하고, 가능하면 기획서 자체를 수정하여 최신 버전으로 관리하세요.

구두로만 "이 부분은 이렇게 바꿔주세요"라고 하면 나중에 "그렇게 요청받지 않았다" 또는 "원래 기획서대로 했다"는 주장이 나올 수 있습니다. 모든 변경 사항은 이메일이나 문서로 기록하여 나중에 분쟁의 여지를 없애야 합니다.

 

작업 범위 누락 발견 시 대응

기획서에 명시된 기능이 누락된 것을 발견하면 즉시 외주사에게 지적하고 추가 작업을 요구하세요. "이 기능은 기획서 몇 페이지에 명시되어 있는데 구현되지 않았습니다"라고 구체적으로 지적하세요.

외주사가 "그건 추가 비용이 필요합니다"라고 주장할 수도 있지만, 기획서에 명확히 있는 기능이라면 원래 계약 범위에 포함된 것이므로 추가 비용 없이 작업되어야 합니다. 기획서를 근거로 제시하면서 단호하게 요구하세요.

 

최종 인수 전 철저한 검수

최종 인수 전에는 기획서를 옆에 놓고 하나하나 대조하며 검수하세요. 모든 화면, 모든 기능, 모든 프로세스가 기획서대로 구현되었는지 체크리스트를 만들어 확인하세요.

이 과정에서 발견된 문제는 잔금 지급 전에 모두 수정되어야 합니다. 일단 잔금을 지급하고 나면 외주사가 추가 수정에 소극적이 될 수 있으므로, 완벽하게 검수한 후에 최종 대금을 지급하는 것이 안전합니다.