대한민국 IT 업계의 오래된 민낯, 하나쯤 겪어보지 않으셨습니까? 기획안에 없던 기능을 개발해 달라는 클라이언트의 ‘갑질’에, 완성 직전 “생각보다 기능이 별로네요”라며 잔금을 미루는 단물만 빼 먹는 협상. 혹시 지금도 ‘개발자 착취’라는 범죄에 동참하고 계신 건 아닌지, 양심에 손을 얹고 생각해 봅시다. 이 무법지대에 종지부를 찍을 단 하나의 해결책이 있습니다. 바로 SW분야 표준계약서입니다.
과학기술정보통신부가 2020년 말부터 배포한 이 6종의 표준계약서는 단순한 권고안이 아닙니다 . 이건 이 업계의 새로운 유니폼이자 최소한의 예의입니다. 프리랜서 개발자부터 대기업 프로젝트까지, 이 서류 한 장이 여러분의 사업을 ‘막장 드라마’에서 ‘품격 있는 비즈니스’로 탈바꿈시켜 드리겠습니다 .
왜 표준계약서인가: 입에 풀칠하느라 법정 갈 시간 없다
솔직히 고백하세요. 지금까지 ‘계약서’라는 걸 써본 적이 있나요, 아니면 그저 “네, 알아서 잘 하겠습니다”라는 카톡 한 줄에 목숨을 걸었나요? 실제로 계약서 없이 일을 진행하는 프리랜서가 절반에 육박한다는 통계는 이 업계의 현주소를 적나라하게 보여줍니다 .
표준계약서를 외면하는 것은 업무를 시작하기 전에 총을 겨누고 러시안 룰렛을 하는 것과 다를 바 없습니다. 분쟁은 생각보다 가까운 곳에서 찾아옵니다. 과업 범위가 모호해 추가 개발비를 받지 못하거나, 완성된 산출물의 소유권을 두고 다투는 일은 다반사죠 .
표준계약서 사용 시 주요 장점 비교
| 구분 | 기존 불공정 계약 | SW표준계약서 사용 |
|---|---|---|
| 계약 방식 | 구두 계약, 간이 이메일 | 표준화된 서면 계약 |
| 과업 범위 | 모호하고 변경 시 추가비용 분쟁 | 명확한 과업내용서 명시 |
| 대금 지급 | 잔금 미지급, 체불 위험 | 체계적인 지급 일정 및 조건 명시 |
| 지식재산권 | 권리 귀속 분쟁 발생 | 소유권 및 사용권 명확히 구분 |
| 공공입찰 | 혜택 없음 | 기술평가 가점 부여 (최대 5점) |
6종 전략: 내게 맞는 계약서를 골라라
표준계약서는 총 6종입니다. 마치 맞춤 양복처럼, 여러분의 신분과 상황에 맞는 정장을 골라 입어야 합니다. 잘못 골랐다간 발목이 채이고 허벅지가 터지는 불상사가 생깁니다.
1. 외로운 늑대, 프리랜서를 위한 변명: SW종사자 표준계약서 (2종)
프리랜서라는 이름 뒤에 숨겨진 불안정한 신분, 이제는 안녕입니다. 여러분이 정식 직원처럼 지시를 받으며 일하는지, 아니면 독립적인 ‘1인 기업’으로서 프로젝트를 수행하는지에 따라 선택지가 갈립니다 .
표준근로계약서는 사용자의 지휘·감독을 받는 프리랜서를 위한 방패입니다. 업무 내용, 근로시간, 휴게시간, 그리고 당연한 듯 무시당했던 법정 수당까지 명시하여 더 이상 ‘갑’의 눈치를 보지 않게 해줍니다 .
반면, 표준도급계약서는 진정한 1인 사업자의 품격입니다. 프로젝트 단위로 업무 범위와 보수를 명확히 하고, 결과물에 대한 책임과 권리를 분명히 합니다. 어설픈 잡담 대신 서류로 당당하게 협상하세요 .
2. 진짜 ‘어른’들의 거래: SW사업 표준계약서 (4종)
이제 기업 대 기업의 매너를 논할 시간입니다. 정보시스템 개발부터 유지관리, 상용SW 공급까지, 프로젝트의 성격에 따라 네 가지 옵션이 준비되어 있습니다 .
이 계약서들의 핵심은 ‘과업내용서’에 있습니다. 이른바 ‘기획의 부재’로 인한 수많은 참사를 막기 위해, 발주자는 공급자와 합의한 과업의 내용과 범위를 반드시 문서로 명시해야 합니다 . 사업 중간에 “여기에 이 기능도 추가해주세요”라는 말이 통하지 않게 만드는 겁니다. 변경이 필요하다면, 상호 합의해 서면으로 처리해야 합니다. 이게 비즈니스의 기본 매너입니다.
계약서, 읽는 법부터 다르다: 분쟁을 예방하는 치트키
표준계약서를 다운받았다고 해서 자동으로 프로젝트가 성공하는 건 아닙니다. 이 무기를 제대로 다루는 법을 알아야 합니다.
1. 과업범위(Scope)는 마치 ‘성경’처럼
클라이언트의 입장에서 ‘앱 하나 만들어 줘’라는 말은 참 간단합니다. 하지만 그 한 마디가 개발자에게는 6개월의 지옥을 선물할 수 있습니다. 바로 그 모호함을 해결하는 것이 요구명세서(SRS) 입니다 .
계약서를 쓸 때는 반드시 붙임으로 이 요구명세서를 첨부해야 합니다. “어떤 화면에서, 어떤 버튼을 누르면, 어떤 동작을 하는가”에 대한 구체적인 묘사가 없으면, 완성된 후에 “제가 원했던 건 이게 아닌데요?”라는 말을 법적으로 막을 수 없습니다 .
2. 돈, 이게 다 당신 돈입니다: 대금 결제 조건
“다 만들면 입금해드릴게요”라는 말은 “다 만들고 나면 연락 두절되겠습니다”라는 말과 확률적으로 99% 일치합니다. 표준계약서는 이런 상황을 방지하기 위해 대금 지급의 단계를 명확히 구분합니다. 계약금, 중도금, 잔금. 이 세 가지 마디가 없다면 여러분의 현금 흐름은 순식간에 말라붙을 겁니다 .
3. 이 코드는 내 피와 땀이다: 지식재산권
아무런 합의 없이 계약이 종료되면, 법적으로 산출물의 지식재산권은 발주자와 공급자의 공동 소유가 됩니다 . 만약 여러분이 독점적인 기술을 가졌거나, 특정 모듈을 재사용할 계획이라면 이 부분을 반드시 명시해야 합니다. “이 모듈의 저작권은 저에게 있고, 클라이언트는 사용권만 가진다”고 말이죠. 대기업이 여러분의 코드를 도용해 유사한 제품을 만드는 참사를 막은 성공 사례는 이미 존재합니다 .
더 나아가기: 표준을 넘어 ‘명품’으로
표준계약서를 사용하는 것, 이것이 끝이 아닙니다. 이제는 검수 조항과 하자보수 조항까지 꼼꼼히 챙겨야 합니다. 검수 기간을 며칠로 할지, 문제 발생 시 수정해줄 기간은 어떻게 될지에 대한 구체적인 합의는 이후에 발생할 ‘감정의 골’을 메워주는 시멘트와 같습니다 .
혹시라도 ‘우리는 오래 봐왔으니까, 입으로 하는 약속이면 된다’는 생각이 드신다면, 지금 당장 그 생각을 버리십시오. 비즈니스에서 가장 위험한 것은 불신이 아니라 ‘과도한 믿음’입니다.
SW분야 표준계약서는 여러분의 사업을 지키는 최소한의 금고입니다. 지금 바로 한국소프트웨어산업협회에 접속하여 6종의 계약서를 내려받으십시오. 그리고 다음 미팅 때는 이 서류를 테이블 위에 올려두고 말하세요. “사업 얘기 전에, 우리 예의부터 갖출까요?”
