외주 맡기기
내 서비스를 남에게 돈 주고 만들게 하는 일이에요. 잘 되면 시간을 사는 것이고, 잘못되면 내 가게 열쇠를 남이 들고 있는 상태가 돼요.
쉽게 말하면
가게 인테리어를 맡기는 것과 똑같아요. 업체가 와서 벽을 세우고 조명을 달고 떠나요. 이때 사장님이 챙겨야 할 건 완성된 가게만이 아니에요. 도면·전기 배선도·열쇠를 받아야 해요. 그게 없으면 나중에 전구 하나 갈려고 해도 그 업체를 다시 불러야 하고, 그 업체가 문을 닫으면 내 가게인데도 손을 못 대요. 외주 개발에서 도면은 코드, 열쇠는 저장소와 계정이에요.
외주는 나쁜 게 아니에요. 사장님이 장사에 쓸 시간을 지키는 정상적인 방법이에요. 다만 완성품만 받고 끝내면 안 된다는 게 이 문서의 전부예요.
코드가 어디 있는지, 누구 계정에 올라가 있는지 모르는 상태예요. 다음 수정부터 그 업체 말고는 아무도 못 해요.
업체가 사라져도 다른 사람에게 그대로 넘길 수 있어요. 가격 협상력도 여기서 나와요.
개발사와 프리랜서, 무엇이 다른가
둘 다 코드를 만들어 주지만 사고가 났을 때의 모습이 달라요. 가격만 보고 고르면 나중에 후회하는 지점이 여기예요.
| 맡기는 곳 | 장점 | 조심할 점 |
|---|---|---|
| 개발사(법인) | 담당자가 바뀌어도 회사가 남아요. 세금계산서·계약서 절차가 갖춰져 있어요 | 값이 비싸요. 작은 수정에도 절차가 붙어 느릴 수 있어요 |
| 프리랜서 개인 | 빠르고 값이 낮아요. 사장님과 직접 이야기하니 말이 덜 새요 | 그 사람이 아프거나 취업하면 멈춰요. 대체 인력이 없어요 |
| 에이전시 중개 | 사람을 대신 찾아 주고 대금을 중간에 맡아 줘요 | 수수료가 붙어요. 실제 만드는 사람이 누구인지 확인해야 해요 |
| 직접 만들고 일부만 맡기기 | 화면은 내가 만들고 어려운 부분만 사서 붙여요. 가장 싸요 | "어디까지가 내 몫인지"를 내가 알아야 해요 |
규모보다 대체 가능성
회사가 크냐 작냐보다 이 사람이 없어져도 다른 사람이 이어받을 수 있느냐가 중요해요. 코드가 내 저장소에 있고 문서가 있으면, 프리랜서에게 맡겨도 대체가 됩니다. 그게 없으면 대기업에 맡겨도 인질이에요.
견적서에서 봐야 할 네 칸
견적서를 받으면 대부분 총액부터 봐요. 총액은 사실 가장 덜 중요한 숫자예요. 같은 금액이라도 아래 네 칸이 비어 있으면 나중에 두 배가 나와요.
| 봐야 할 칸 | 이렇게 적혀 있으면 위험 | 이렇게 적혀 있어야 안전 |
|---|---|---|
| 범위 | "쇼핑몰 구축 일체" | 화면 이름을 하나하나 적어야 해요. "상품목록·상세·장바구니·결제·주문내역·관리자 상품등록" 처럼요 |
| 기간 | "약 2개월" | 언제 무엇을 보여 줄지 나눠 적어야 해요. 중간에 눈으로 확인하는 날이 최소 한 번은 있어야 해요 |
| 수정 횟수 | 안 적혀 있음 | "각 화면 수정 3회까지 포함, 이후 건당 얼마" 처럼 숫자와 단가가 같이 있어야 해요 |
| 유지보수 | "납품 후 협의" | 무상 수정 기간이 며칠인지, 그 뒤 월 얼마인지, 그 돈으로 무엇을 해 주는지 적혀야 해요 |
"유지보수 포함"은 문장이 아니에요
포함이라는 말만 있고 무엇이 포함인지가 없으면 나중에 전부 추가 견적이 돼요. 최소한 이 세 가지를 나눠서 물어보세요. 오류가 나면 고쳐 주는가, 손님이 늘어 서버가 버거우면 손봐 주는가, 문구나 사진을 바꿔 달라는 것도 되는가. 셋은 값이 다른 일이에요.
그리고 견적서에 없는데 반드시 돈이 드는 것들이 있어요. 도메인 값, 호스팅 서버 값, 결제사 수수료 같은 것들이요. 이건 개발비가 아니라 매달 나가는 월세예요. 누가 결제하는 계정으로 걸어 둘지 처음에 정하세요.
계약서에 꼭 넣을 세 줄
긴 계약서를 다 읽기 어려우면 이 세 줄만 확인하세요. 분쟁의 대부분이 이 세 줄이 없어서 생겨요.
- 1코드 소유권. "대금 완납 시 결과물에 대한 권리를 발주자에게 양도한다"가 적혀 있어야 해요. 돈을 냈다고 자동으로 내 것이 되지는 않아요. 만든 쪽에 권리가 남는 것이 원칙이라, 넘겨받으려면 글자로 적어야 해요.
- 2저장소 위치. "코드는 발주자 명의 저장소에 보관하며 작업 중에도 접근 권한을 부여한다"를 넣으세요. 완성 뒤에 받는 게 아니라 처음부터 내 창고에 쌓게 하는 거예요.
- 3인수인계. "납품 시 실행 방법, 계정 목록, 배포 순서를 문서로 제출한다"를 넣으세요. 코드만 있고 띄우는 법을 모르면 코드가 없는 것과 비슷해요.
문구는 전문가에게 확인하세요
여기 적은 건 무엇을 빠뜨리면 안 되는지에 대한 설명이지 법률 자문이 아니에요. 금액이 크거나 이미 다툼이 생겼다면 계약 실제 문구는 변호사나 법률 상담 창구에서 확인하세요. 저작권 이야기는 저작권 문서에서 더 볼 수 있어요.
대금은 한 번에 다 주지 않는 게 보통이에요. 착수·중간·완료로 나누고, 마지막 잔금은 인수인계 문서까지 받은 다음 지급하도록 적어 두세요. 잔금이 남아 있는 동안에는 연락이 잘 됩니다.
분쟁은 늘 같은 자리에서 난다
장면 1 · 외주 개발자가 말했다
“그건 처음 범위에 없던 기능이라 추가 견적으로 잡아야 할 것 같아요.”
이 말 자체는 부당하지 않아요. 문제는 처음 범위가 글자로 없었다는 거예요. "쇼핑몰 만들어 주세요" 안에 쿠폰이 들어 있는지 아닌지는 사람마다 다르게 읽어요. 다툴 일이 아니라 처음에 화면 목록을 적어서 막을 일이에요.
장면 2 · 손님이 전화했다
“결제가 안 되는데요. 어제부터 계속이에요.”
여기서 갈려요. 코드가 내 저장소에 있으면 아무 개발자에게나 보내 그날 고쳐요. 없으면 만든 업체에 연락해 답을 기다려야 해요. 급한 건 사장님이고 그 업체는 안 급해요. 이 비대칭이 외주 분쟁의 진짜 정체예요.
장면 3 · 새로 부른 개발자가 말했다
“이거 어떻게 띄우는지 모르겠어요. 서버 접속 정보 있으세요?”
인수인계 문서가 없을 때 나오는 말이에요. 이 상태면 새 개발자는 처음부터 다시 만들자고 할 확률이 높아요. 이미 낸 개발비를 한 번 더 내는 셈이에요. 그래서 인수인계는 친절 항목이 아니라 돈이에요.
정리하면 다툼은 세 자리에서만 나요. 범위를 안 적어서, 열쇠를 안 받아서, 띄우는 법을 안 물어봐서요. 기술 문제가 아니라 종이 문제예요.
직접 만들고 부분만 맡기기
가장 돈이 덜 드는 방법은 통째로 맡기지 않는 거예요. 화면과 흐름은 바이브캠퍼스에서 직접 만들어 보고, 막히는 부분만 사람을 부르는 순서예요.
- 1스튜디오에서 먼저 만들어 봐요. 손님이 보는 화면과 버튼 흐름을 직접 만들어요. 완벽하지 않아도 돼요. 이걸 MVP라고 불러요.
- 2막히는 지점을 목록으로 적어요. "결제가 실제로 되게", "주문이 쌓이게" 처럼 문장으로 적어요. 이 목록이 그대로 견적 요청서가 돼요.
- 3그 목록만 견적을 받아요. 화면이 이미 있으니 개발자가 상상할 필요가 없어요. 범위가 좁으면 값도 기간도 줄어요.
- 4만든 것을 개발자에게 넘겨요. 스튜디오에서 결과물을 파일로 내려받거나, 연결 센터에서 깃허브 계정을 연결해 내 저장소로 내보낼 수 있어요. 처음부터 코드가 내 쪽에 있는 상태로 시작하는 거예요.
- 5고쳐서 돌려받은 뒤 확인해요. 실제 손님처럼 처음부터 끝까지 한 번 눌러 보세요. 이때 배포와 계정 접근까지 같이 넘겨받아요.
이 순서의 진짜 이득
값을 아끼는 것보다 큰 게 있어요. 사장님이 무엇을 만들고 싶은지 스스로 알게 된다는 점이에요. 화면을 한 번 만들어 본 사장님은 견적서를 읽을 줄 알아요. 그 상태로 협상하는 것과 아무것도 모르고 협상하는 것은 완전히 다른 자리예요.
자주 묻는 것
- Q. 견적이 세 배씩 차이 나요. 왜 이래요?
- 대부분 범위를 다르게 읽었기 때문이에요. 싼 곳은 화면만 만들고, 비싼 곳은 관리자 화면과 테스트까지 잡은 경우가 많아요. 값을 비교하기 전에 각 견적서의 화면 목록을 나란히 놓고 보세요. 목록이 같은데도 차이가 크면 그때 협상하면 돼요.
- Q. 코드를 받아도 저는 못 읽는데 의미가 있나요?
- 있어요. 사장님이 읽으려고 받는 게 아니라 다음 사람에게 주려고 받는 거예요. 집문서를 못 읽어도 집문서는 갖고 있어야 하는 것과 같아요.
- Q. 저장소를 제 명의로 하자고 하면 기분 나빠하지 않을까요?
- 정상적인 요구예요. 제대로 하는 곳은 오히려 먼저 제안해요. 이걸 거부하는 곳이 있다면 그 이유를 물어보세요. 대부분 남의 프로젝트 코드를 돌려 쓰고 있어서인 경우가 있어요.
- Q. 만들다 중간에 그만두게 되면 돈은 어떻게 되나요?
- 계약서에 중도 해지 조항이 있으면 그대로 따라요. 없으면 다툼이 됩니다. 그래서 단계별로 나눠 지급하는 게 안전해요. 지금까지 만든 것까지만 정산하고 끝낼 수 있으니까요.
- Q. 완성됐다는데 제가 뭘 확인해야 하나요?
- 손님이 하는 행동을 처음부터 끝까지 직접 해 보세요. 가입하고, 담고, 결제하고, 취소까지요. 그리고 휴대폰으로도 같은 걸 해 보세요. 화면이 깨지는 문제는 여기서 대부분 나와요.
- Q. 프리랜서에게 돈을 줄 때 그냥 계좌이체하면 되나요?
- 지급 자체는 이체지만 세금 절차가 따로 붙는 경우가 많아요. 사업자라면 비용 처리와 신고 방법이 달라지니, 첫 건을 지급하기 전에 세무 담당자나 국세청 상담 창구에 확인하세요. 나중에 정리하려면 훨씬 번거로워요.
- Q. 만든 사람이 나중에 이 코드를 다른 곳에 팔면요?
- 그래서 소유권 조항이 필요해요. 다만 개발자가 원래부터 갖고 있던 공용 도구까지 못 쓰게 하기는 어려워요. 내 서비스만의 부분은 내 것으로, 공용 도구는 그쪽 것으로 나누는 게 보통이에요. 문구는 계약 단계에서 확인하세요.
확인해 보세요
개발사가 "완성됐습니다"라며 사이트 주소를 보내왔어요. 잔금을 주기 전에 반드시 받아야 할 것은?
하나 더
견적서 두 장이 왔는데 한 장은 300만 원, 한 장은 900만 원이에요. 가장 먼저 할 일은?
직접 해보기
맡기기 전에 화면부터 한 번 만들어 보세요
만들고 싶은 걸 문장으로 적으면 화면이 나와요. 완성이 목적이 아니라 견적 요청서를 손에 쥐는 게 목적이에요. 여기서 만든 화면 목록이 그대로 범위가 돼요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
고정가와 시간제, 무엇이 나은가 · 총액을 못 박는 방식은 예산이 예측되지만, 개발자가 위험을 값에 미리 얹어서 비싸져요. 일한 시간만큼 내는 방식은 싸게 시작하지만 끝이 안 보일 수 있어요. 만드는 것이 명확하면 고정가, 계속 바꿔 갈 것이면 시간제에 상한선을 함께 두는 식이 무난해요.
"이거 하루면 되죠?"가 위험한 이유 · 화면에 버튼 하나 더 다는 일은 눈에는 작아 보여요. 하지만 그 버튼이 돈을 건드리면 실패했을 때 처리, 중복 요청 방지, 기록 남기기가 따라붙어요. 가게로 치면 계산대에 카드 단말기 하나 놓는 일이 배선·정산·영수증까지 건드리는 것과 같아요. 작아 보이는 요청일수록 무엇이 같이 딸려 오는지 물어보세요.
만든 사람이 사라진 코드를 살리는 순서 · 이미 벌어졌다면 순서가 있어요. 먼저 결제사·서버·도메인 계정의 주인 명의부터 내 것으로 돌려놓아요. 서비스가 죽는 건 코드가 없어서가 아니라 결제 카드가 만료돼서 인 경우가 많거든요. 그다음에 지금 돌아가는 화면을 그대로 복사해 두고, 새 개발자에게 "이대로 다시 만들되 하나씩 옮기자"고 요청해요.
이것만 기억하세요
- ·총액보다 범위·기간·수정 횟수·유지보수 네 칸을 먼저 봐요
- ·계약서 세 줄: 코드 소유권, 내 명의 저장소, 인수인계 문서
- ·잔금은 인수인계까지 받은 다음에 지급해요
- ·다툼은 기술이 아니라 종이에서 나요. 화면 목록을 적어서 시작해요
- ·직접 만들어 본 뒤 막히는 부분만 맡기면 값도 위험도 줄어요