외주 개발 맡기기 전에 꼭 알아야 할 것들

외주 개발, 왜 이렇게 무서운 얘기가 많을까

개발 커뮤니티나 스타트업 모임 가면 외주 공포 이야기가 끊이질 않아요. "소스코드를 안 줘요", "중간에 연락이 끊겼어요", "결과물이 기대와 완전 달라요." 이런 이야기를 들으면 외주 자체를 꺼리게 되죠.

근데 솔직히 말하면, 이런 사고의 대부분은 계약과 커뮤니케이션 문제예요. 기술력이 부족해서 실패하는 경우보다, 뭘 만들지 제대로 합의하지 않아서 실패하는 경우가 훨씬 많거든요.

실제로 이런 일이 일어나요

소스코드 미인도 사례. 계약서에 소스코드 소유권 조항이 없으면, 법적으로 코드 저작권은 개발한 쪽에 있어요. 저작권법상 프로그램 소스코드는 원칙적으로 직접 개발자에게 귀속되거든요. 실제로 소스코드 무단 재사용으로 4천만 원 배상 판결이 나온 사례도 있어요. 계약서에 한 줄 안 넣었다가 서비스 전체를 날릴 수 있는 거예요.

연락두절 사례. 선금 받고 사라지는 건 극단적인 경우고, 더 흔한 건 "서서히 늦어지는" 패턴이에요. 답장이 하루에서 이틀로, 이틀에서 일주일로 늘어나다가 결국 프로젝트가 흐지부지되는 거죠. 위시켓 같은 플랫폼이 에스크로 시스템을 도입한 것도 이런 문제 때문이에요.

하청 재외주 사례. 한국소프트웨어산업협회 통계를 보면 외주 분쟁의 약 30%가 하도급 관련이에요. A 업체에 맡겼는데 실제로는 B한테 넘어가고, B는 또 C한테 넘기고. 가격은 내려가는데 품질도 같이 내려가는 구조예요.

계약서에 반드시 넣어야 할 것들

계약서 얘기하면 "귀찮다", "신뢰로 하자" 이런 반응이 많은데, 이게 진짜 중요해요. 꼭 들어가야 할 핵심 조항을 짚어볼게요.

소스코드 및 지적재산권 귀속. "본 프로젝트에서 생성된 모든 소스코드, 디자인, 기술 문서의 저작권 및 소유권은 의뢰인(갑)에게 귀속된다." 이 한 문장이 없으면 나중에 큰일 납니다. 별도 합의가 없으면 법적으로 개발자 쪽 소유예요.

기능 명세서 첨부. "이쁘게 해주세요" 같은 모호한 요구는 분쟁의 씨앗이에요. 화면 단위로 어떤 기능이 있는지, 입력값과 결과값이 뭔지 구체적으로 적어야 해요. 완벽하지 않아도 돼요. 와이어프레임이나 간단한 화면 설명이라도 있으면 훨씬 나아요.

마일스톤과 중간 검수. 3개월짜리 프로젝트를 마지막에 한 번에 받으면 안 돼요. 2주마다 중간 산출물을 확인하고, 방향이 맞는지 체크해야 해요. 일정이 밀리는 것도 이 단계에서 조기에 발견할 수 있어요.

변경 요청(CR) 절차. 개발 중간에 "이것도 추가해주세요"는 반드시 발생해요. 이걸 어떻게 처리하는지 — 추가 비용이 드는지, 기존 기능과 교체하는지 — 미리 정해두세요. 구두 합의는 분쟁의 시작이에요.

하자 보수 기간. 최소 1개월. 납품 후에 버그가 발견됐을 때 무상으로 수정해주는 기간이에요. 이거 없으면 납품 다음 날부터 "추가 비용"을 요구받을 수 있어요.

미완성 시 환불 조건. 기능 명세서 기준으로 몇 퍼센트 미만이면 환불, 같은 기준이 있어야 해요. 없으면 "거의 다 했는데요"라는 말에 반박하기 어려워요.

싼 게 비지떡? 꼭 그런 것만은 아니에요

"비싸면 좋겠지"라는 생각도 위험해요. 대형 에이전시에 맡기면 PM 비용, 오버헤드가 붙어서 실제 개발에 쓰이는 비용은 전체의 50~60%밖에 안 되는 경우도 있거든요.

반대로 너무 싼 곳은 앞에서 말한 것처럼 리스크가 커요. 저희가 보기에 핵심은 가격 자체보다 투명성이에요. 어디에 얼마가 쓰이는지 설명해주는 업체, 중간 과정을 보여주는 업체가 결과적으로 좋은 업체예요.

커뮤니케이션이 반이에요

기술적으로 뛰어난 팀이라도 소통이 안 되면 원하는 결과가 안 나와요. 확인해볼 포인트가 몇 가지 있어요.

슬랙이나 디스코드 같은 실시간 채널을 쓰는지. 주간 보고나 데모를 보여주는지. 질문에 당일 안에 답변이 오는지. 이 세 가지만 확인해도 업체 수준이 대충 보여요.

그리고 레퍼런스를 꼭 공유하세요. "이런 느낌으로"라고 말하는 것보다 비슷한 서비스의 스크린샷을 보여주는 게 100배 정확해요. Figma, 노션, 심지어 종이에 그린 거라도 괜찮아요.

위험 신호는 이런 거예요

계약서 없이 시작하자는 곳. "다 됩니다"만 반복하는 곳. 중간에 뭘 만들고 있는지 안 보여주는 곳. 연락이 하루 넘게 안 되는 곳. 이런 신호가 보이면 아무리 포트폴리오가 좋아도 다시 생각해보세요.

좋은 외주 관계는 결국 명확한 기대치와 투명한 소통에서 나와요. 저희 딱4주는 프로젝트 시작 전에 기능 범위를 확정하고, 매주 중간 데모를 드리고, 소스코드는 100% 고객 소유예요. 당연한 얘기 같지만, 이게 안 되는 곳이 생각보다 많거든요.