외주 맡길 때 계약서

말로만 맡기면 나중에 결과물이 누구 것인지부터 싸우게 돼요. 범위·금액·저작권을 적은 종이 한 장이 돈과 관계를 같이 지켜요.

쉽게 말하면

가게 인테리어를 맡길 때 견적서도 계약서도 없이 "알아서 예쁘게 해 주세요" 하고 공사를 시작하는 사장님은 없죠. 어디까지 고치는지, 얼마인지, 언제 끝나는지를 종이에 적고 시작해요. 개발 외주도 똑같은 공사예요. 그런데 다른 점이 딱 하나 있어요. 인테리어는 공사가 끝나면 그 벽이 당연히 내 가게 벽이 되지만, 개발 결과물은 대금을 다 내도 권리가 자동으로 사장님 것이 되지 않아요. 그래서 계약서가 인테리어 때보다 오히려 더 중요해요.

이 문서는 외주 맡기기의 다음 단계예요. 누구에게 맡길지 정했다면, 이제 무엇을 종이에 적고 시작할지를 다뤄요. 남이 써 온 계약서를 읽는 요령은 계약서 읽는 법에 따로 있어요.

말로 맡기면 어디서 꼬이나

계약은 원래 말로도 성립해요. 카톡으로 "300에 해 주세요" "네 알겠습니다"를 주고받았다면 그것도 계약이에요. 문제는 성립이 아니라 증명과 해석이에요. 싸움이 나는 지점은 늘 비슷해요.

1범위에서 먼저 갈라져요. 사장님은 "예약 기능이면 당연히 예약 취소도 포함"이라 생각하고, 개발자는 "취소는 별도 건"이라 생각해요. 둘 다 거짓말을 하는 게 아니에요. 적어 두지 않아서 각자 다르게 기억할 뿐이에요.
2돈 순서에서 감정이 상해요. 먼저 다 주면 사장님이 불안하고, 끝나고 다 받기로 하면 개발자가 불안해요. 지급 시점을 안 정하면 이 불안이 서로를 의심하는 말로 나와요.
3"완성"의 기준이 없어서 끝이 안 나요. 사장님 눈에는 버그가 남았고, 개발자 눈에는 다 만든 거예요. 검수 기준이 없으면 이 다툼은 판정할 방법 자체가 없어요.
4마지막에 권리 문제가 터져요. 서비스가 잘돼서 기능을 추가하거나 다른 개발자에게 넘기려는 순간, "그 코드의 저작권은 저에게 있는데요"라는 말을 들어요. 가장 큰 싸움이 가장 늦게 와요.

계약서는 개발자를 의심하는 문서가 아니에요. 서로 다르게 기억할 수 있는 것들을 미리 하나로 맞춰 두는 문서예요. 좋은 개발자일수록 계약서를 반가워해요. 자기도 지켜지니까요.

계약서에 꼭 있어야 하는 칸

법률 용어를 몰라도 돼요. 아래 칸들이 있는지 없는지만 확인하면 사고의 대부분을 막아요. 개발자가 계약서를 가져왔다면 이 표를 옆에 놓고 하나씩 대조해 보세요.

칸	무엇을 적나	안 적으면 생기는 일
결과물 정의	만들 화면과 기능을 목록으로 구체적으로	"그건 원래 포함이 아니에요" 추가금 분쟁
금액과 지급 시점	계약금·잔금 비율, 잔금은 검수 뒤에	다 줬는데 미완성, 또는 다 만들었는데 못 받는 싸움
일정	납기일, 늦어지면 어떻게 할지	기약 없는 잠수를 따질 근거가 없어요
수정 횟수	무료 수정 몇 회, 그 뒤는 회당 얼마	한쪽은 무한 수정 요구, 한쪽은 건건이 추가금
저작권 양도	결과물과 소스코드의 권리가 나에게 오는지	내 서비스인데 법적으로 내 것이 아닌 상태
검수 기준	무엇이 되면 "끝"으로 치는지	완성이냐 미완성이냐를 판정할 방법이 없어요
하자보수	오픈 뒤 몇 개월간 버그 무상 수리	오픈 다음 날 발견한 버그도 유료 견적
인도물 목록	소스코드·계정·문서까지 받을 것 전부	화면만 받고 가게 열쇠는 못 받은 상태
비밀유지	손님 정보와 사업 아이디어 보호	내 아이디어가 남의 포트폴리오와 다음 고객에게 가요

전부 새로 쓸 필요는 없어요. 정부 부처와 공공기관이 소프트웨어 개발용 표준계약서를 무료로 배포해요. 그걸 바탕으로 결과물 목록과 금액 칸만 내 프로젝트에 맞게 채우는 게 가장 안전한 출발이에요. 큰돈이 걸린 계약이라면 서명 전에 변호사나 공공 법률 상담 창구에서 한 번 검토받는 것을 권해요.

제일 중요한 한 칸, 결과물은 누구 것인가

저작권법의 원칙은 만든 사람이 저작권을 갖는다예요. 외주 개발자가 만든 코드의 저작권은, 계약서에 넘긴다는 말이 없으면 원칙적으로 개발자에게 남아요. 대금을 전부 지급했다는 사실만으로 저작권이 자동으로 넘어오지 않아요. 이 한 줄을 모르는 채 외주를 맡기는 사장님이 정말 많고, 이 한 줄 때문에 서비스가 잘된 뒤에 발목이 잡혀요. 자세한 원리는 저작권 문서에 있고, 내 사안이 어떤지는 한국저작권위원회 같은 공공 상담 창구에서 확인할 수 있어요.

위험한 계약

제5조 대금 "총 300만 원을 지급한다" (저작권 언급 없음)

돈 얘기만 있어요. 결과물의 권리는 개발자에게 남아 있어서, 기능 추가나 개발자 교체 때마다 협의가 필요한 상태가 돼요.

안전한 계약

제5조 대금 + 제6조 권리 귀속 "결과물과 소스코드의 저작권은 잔금 지급과 동시에 발주자에게 양도한다"

돈과 권리가 같이 움직여요. 잔금을 주는 순간 결과물이 법적으로도 내 것이 돼요.

권리와 함께 실물도 챙겨야 해요. 저작권을 양도받아도 소스코드 파일과 계정을 못 받으면 금고 소유권만 있고 열쇠가 없는 셈이에요. 소스코드 저장소(깃허브), 도메인, 호스팅 계정은 처음부터 사장님 명의로 만들고 개발자를 초대하는 방식이 가장 안전해요. 받을 것의 전체 목록은 인수인계 문서에 있어요.

포트폴리오 사용은 따로 정해요

개발자가 "이 작업을 포트폴리오에 올려도 되나요"라고 물으면, 안 될 이유는 없지만 범위를 적어 두세요. 화면 캡처까지는 좋지만 소스코드 공개나 손님 데이터가 보이는 화면은 안 된다는 식으로요. 이걸 안 정하면 비밀유지 조항과 부딪혀요.

사장님이 실제로 겪는 장면

장면 1 · 오픈 두 달 뒤, 기능을 추가하려는데

“그 코드는 제 저작물이라서요. 다른 개발자에게 넘기시려면 코드 사용료를 따로 협의하셔야 해요.”

계약서에 저작권 양도 조항이 없었다면 이 말이 법적으로 성립할 수 있어요. 대금 완납과 권리 이전은 다른 문제거든요. 이 상황이 되면 협상력은 이미 개발자 쪽에 있어요. 계약서의 한 줄이 이 장면 자체를 없애요.

장면 2 · 검수 기준이 없던 프로젝트의 마지막 주

“저는 다 만들었다고 보는데요. 잔금을 먼저 주셔야 나머지 버그를 봐 드릴 수 있어요.”

"완성"의 기준을 안 적으면 마지막 주에 반드시 이 대화가 와요. 처음에 검수 항목을 목록으로 적고 "검수 통과 후 잔금" 순서를 계약서에 박아 두면, 이 대화는 감정싸움이 아니라 목록 대조 작업이 돼요.

이 걱정에는 이 문장

걱정되는 상황별로, 계약서에 들어가 있어야 하는 문장의 뼈대예요. 개발자와 조건을 조율할 때 "이런 취지의 조항을 넣고 싶어요"라고 그대로 말하면 돼요. 정확한 법률 문구는 표준계약서의 해당 조항을 그대로 가져다 쓰는 게 안전해요.

걱정되는 상황	계약서에 들어갈 문장의 뼈대
잘된 뒤에 결과물이 남의 것이 될까 봐	"결과물과 소스코드의 저작권은 잔금 지급과 동시에 발주자에게 양도한다"
다 만들었다며 잔금부터 달라고 할까 봐	"발주자가 붙임 목록대로 검수를 완료한 뒤 며칠 안에 잔금을 지급한다"
중간에 잠수를 탈까 봐	"납기일보다 일정 기간 이상 늦어지면 발주자는 계약을 해지하고 기지급금 반환을 요구할 수 있다"
수정을 부탁할 때마다 추가금이 나올까 봐	"검수 전 수정은 몇 회까지 대금에 포함하고, 초과분은 회당 얼마로 한다"
오픈하자마자 버그가 나올까 봐	"검수 완료일부터 몇 개월간 하자는 무상으로 수리한다"
화면만 받고 열쇠를 못 받을까 봐	"소스코드 저장소·도메인·호스팅 계정은 발주자 명의로 하고, 접근 권한을 잔금과 동시에 인계한다"

지금은 신경 쓰지 않아도 되는 때

외주 자체가 없으면 이 문서도 필요 없어요. 바이브캠퍼스에서 사장님이 직접 만드는 동안에는 계약할 상대가 없으니까요. 만든 결과물을 어떻게 내 것으로 챙기는지는 코드 내보내기를 보면 돼요. 계약서는 남의 손을 빌리는 순간부터 생각하면 늦지 않아요.

외주를 맡기더라도 전부 정식 계약서가 필요한 건 아니에요. 로고 시안 하나, 배너 몇 장 같은 소액 일회성 작업이면 도장 찍는 계약서 대신 문자나 메일 한 통이면 충분해요. 단 네 가지는 꼭 글자로 남기세요. 무엇을, 얼마에, 언제까지, 결과물은 누구 소유인지. 이 네 줄이 있으면 나중에 다퉈도 근거가 남아요. 외주 중개 플랫폼을 거치는 경우에는 플랫폼 약관과 에스크로가 기본 안전장치 역할을 해 줘서 부담이 더 줄어요.

선을 하나만 긋는다면

자주 묻는 것

Q. 표준계약서는 어디서 구하나요?: 정부 부처와 공공기관이 소프트웨어·콘텐츠 분야 표준계약서를 무료로 배포해요. 검색창에 "소프트웨어 표준계약서"를 치면 공공기관 배포본이 나와요. 조항 뼈대는 그대로 두고 결과물 목록·금액·일정 칸만 채우는 방식이 가장 안전해요.
Q. 계약서 쓰자고 하면 관계가 어색해지지 않을까요?: 반대예요. 경력 있는 개발자일수록 계약서를 반가워해요. 자기 대금과 작업 범위도 같이 보호되니까요. 계약서 얘기에 유난히 불쾌해하는 상대라면 그 반응 자체가 판단 재료예요.
Q. 소스코드는 뭘로 어떻게 받아요?: 압축파일 전달보다 깃허브 저장소를 사장님 계정 소유로 만들고 개발자를 초대하는 방식이 좋아요. 작업 기록이 전부 남고, 계약이 끝나면 초대만 해제하면 돼요. 받을 것 전체 목록은 인수인계 문서에 있어요.
Q. 개인 프리랜서에게 주는 돈은 세금 처리를 어떻게 하나요?: 상대가 개인이면 지급할 때 일정 비율을 원천징수해서 신고하는 방식이 일반적이고, 사업자면 세금계산서를 받아요. 어느 쪽인지에 따라 처리와 증빙이 달라지니, 첫 지급 전에 세무사나 국세청 상담으로 내 경우를 확인하는 게 안전해요.

확인해 보세요

하나 더

잔금은 언제 주는 게 가장 안전할까요?

직접 해보기

계약서의 결과물 칸을 화면으로 먼저 만들어 보세요

외주 계약에서 제일 다투는 칸이 결과물 정의예요. 말 대신 화면으로 보여주면 다툴 거리가 사라져요. 원하는 서비스의 화면을 바이브캠퍼스에서 직접 만들어 보세요. 그 화면 목록이 그대로 계약서의 결과물 칸이 되고, 견적도 훨씬 정확해져요.

스튜디오에서 화면 만들어 보기

더 깊이 (안 읽어도 괜찮아요)

양도받아도 안 넘어오는 권리가 있어요 · 저작권을 양도한다고만 적으면, "고쳐서 새로운 것을 만들 권리"(2차적저작물작성권)는 넘어오지 않은 것으로 보는 게 저작권법의 원칙이에요. 서비스는 계속 고치며 크는 물건이라 이 권리가 빠지면 곤란해져요. 그래서 양도 조항에 "2차적저작물작성권을 포함하여 양도한다"까지 적는 게 정석이에요. 표준계약서에는 대개 이 문구가 들어 있으니, 내 계약서에 있는지만 확인하세요.

결과물 전부를 내 것으로 만들 수는 없어요 · 개발자는 오픈소스 부품과 자기가 오래 다듬어 온 도구를 섞어 결과물을 만들어요. 오픈소스 부분은 애초에 개발자 것도 아니라 각자의 사용 규칙(오픈소스 라이선스)을 따르고, 개발자의 기존 도구는 양도 대신 "내 서비스에 계속 쓸 수 있는 허락"을 받는 식으로 처리해요. 계약서에 이 구분이 있으면 오히려 꼼꼼한 개발자라는 신호예요.

비밀유지계약(NDA)은 언제 따로 쓰나 · 본계약 안에 비밀유지 조항이 있으면 대개 충분해요. 계약 전에 아이디어를 자세히 설명해야 하는 단계라면, 그때는 본계약이 아직 없으니 비밀유지계약을 먼저 쓰는 의미가 있어요. 다만 아이디어 자체는 법이 보호해 주는 범위가 좁아서, 서류보다 빠른 실행이 더 강한 보호책이라는 것도 알아 두세요.

이것만 기억하세요

·계약은 말로도 성립하지만, 다툼이 나면 글자만 남아요. 최소한 문자로라도 적어요
·잔금은 검수 통과와 소스코드·계정 인계와 한 묶음으로 줘요
·수정 횟수와 하자보수 기간은 숫자로 적어요
·소액 일회성 작업은 문자 네 줄(무엇을·얼마에·언제까지·누구 소유)이면 충분해요