미팅에는 대표와 기획자가 나왔습니다. 포트폴리오도 괜찮고 응대도 좋았습니다. 계약하고 두 달 뒤, 개발자와 처음 통화했는데 회사 이름이 다릅니다.
"아, 저희는 개발 파트너사예요."
이런 구조는 생각보다 흔합니다. 그리고 그 자체로 문제는 아닙니다. 문제는 발주자가 몰랐다는 것, 그래서 나중에 무언가 잘못됐을 때 누구에게 말해야 하는지 아무도 모른다는 것입니다.
왜 나눠서 맡기는가
먼저 재하도급이 왜 생기는지 알면 판단이 쉬워집니다.
정상적인 이유
- 웹은 잘하는데 앱은 안 해 봤다 → 앱만 전문 팀에 맡김
- 개발은 강한데 디자인은 약하다 → 디자인 스튜디오와 협업
- 특정 기술(결제 연동, 3D, AI)만 별도 전문가가 필요
이건 오히려 좋은 신호일 수 있습니다. 못 하는 걸 억지로 하는 것보다 낫습니다.
경계할 이유
- 영업만 하는 회사가 수주해서 통째로 넘김 (중간 마진만 가져감)
- 인력이 없는데 수주부터 하고 나서 사람을 구함
- 단가를 맞추려고 더 싼 팀에 재하청
이 경우 발주자가 낸 돈의 상당 부분이 중간에서 빠지고, 실제 만드는 쪽 예산이 줄어듭니다. 결과물 품질에 그대로 나타납니다.
계약 전에 물어볼 세 가지
껄끄러운 질문이 아닙니다. 정상적인 업체는 담담하게 답합니다.
① "이 프로젝트는 어느 분들이 하시나요?"
역할별로 누가 하는지 물어보세요. 기획·디자인·개발(프론트/백엔드)·앱. 회사 소속인지 외부 협업인지도 함께.
답이 구체적이면 실제 배치가 되어 있는 것이고, "저희 팀에서 진행합니다"만 반복되면 아직 안 정해졌을 가능성이 있습니다.
② "제가 개발자와 직접 이야기할 수 있나요?"
이 질문에 대한 반응이 많은 걸 말해 줍니다. 흔쾌히 자리를 만들어 주는 곳과, 창구를 일원화해야 한다며 피하는 곳이 있습니다.
창구 일원화 자체는 합리적인 운영 방식이라 그것만으로 나쁘다고 볼 수는 없습니다. 다만 프로젝트 내내 만드는 사람과 한 번도 대화하지 못하는 구조라면, 요구사항이 전달되는 과정에서 정보가 얼마나 새는지 확인할 방법이 없습니다.
③ "외부에 맡기는 부분이 있으면 계약서에 적어도 될까요?"
여기서 표정이 바뀌는 곳이 있습니다. 재하도급이 있는 게 문제가 아니라, 적기를 꺼리는 게 문제입니다.
계약서에 넣을 문장
전면 금지는 현실적이지 않고 오히려 손해일 수 있습니다. 동의 조건부 허용이 좋습니다.
재위탁 수급인은 도급인의 사전 서면 동의 없이 이 계약상 업무의 전부 또는 일부를 제3자에게 위탁할 수 없다. 동의를 받아 위탁하는 경우에도 수급인은 제3자의 이행에 대하여 도급인에게 직접 책임을 진다. 위탁하는 업무의 범위와 수탁자를 도급인에게 서면으로 고지한다.
두 번째 문장이 핵심입니다. 책임을 원 수급인이 계속 진다는 것. 이게 없으면 문제가 생겼을 때 "그건 파트너사 쪽 문제라서요"라는 답을 듣게 되고, 발주자는 계약 관계도 없는 회사와 씨름해야 합니다.
소스 코드가 흐려지는 지점
재하도급에서 가장 자주 사고가 나는 곳이 저작권입니다.
A업체와 계약하면서 "결과물의 저작권은 도급인에게 귀속한다"는 조항을 넣었다고 합시다. 그런데 실제로 코드를 쓴 건 B업체입니다. A와 B 사이에 같은 조항이 없으면, B가 만든 코드의 권리는 B에게 남아 있습니다. 발주자는 A로부터 받을 수 없는 권리를 받기로 계약한 셈입니다.
그래서 이 문장을 함께 넣어야 합니다.
수급인은 제3자에게 위탁하는 경우, 그 결과물의 지식재산권이 도급인에게 귀속되도록 수탁자와 필요한 약정을 체결한다.
디자인에서도 같은 문제가 생깁니다. 디자인 스튜디오가 만든 시안의 권리, 사용한 폰트의 라이선스, 스톡 이미지의 이용 범위가 전부 여기 걸립니다. 이 부분은 견적서의 '콘텐츠 별도' 한 줄에서 더 자세히 다뤘습니다.
진행 중에 알아채는 신호
계약 때 못 물었더라도 중간에 보이는 게 있습니다.
- 회신 속도가 갑자기 느려짐 — 중간에 한 단계가 더 있으면 왕복 시간이 두 배가 됩니다
- 질문의 답이 "확인해 보고 말씀드리겠습니다"로 일관됨 — 답하는 사람이 만드는 사람이 아닐 때 나타납니다
- 문서와 코드의 결이 다름 — 기획서는 꼼꼼한데 실제 화면이 어긋나면 전달 과정에서 샌 것입니다
- 커밋 기록의 계정이 여럿 — 소스 저장소 접근 권한이 있으면 누가 작업했는지 보입니다
이걸 발견했다고 해서 계약을 깰 일은 아닙니다. 다만 알고 관리하는 것과 모르고 당하는 것은 다릅니다. 알게 되면 요청하세요. 실제 개발자를 포함한 정기 회의를 하나 만들어 달라고. 대부분 들어줍니다.
우리는 이렇게 씁니다
작은 팀이 모든 걸 직접 하는 게 항상 가능하지는 않습니다. 저희도 영상 촬영이나 특수한 하드웨어 연동 같은 건 전문 팀과 함께합니다.
다만 그럴 때는 계약 전에 먼저 말합니다. "이 부분은 ○○와 함께 합니다. 대신 일정과 품질 책임은 저희가 집니다." 발주자가 이걸 알고 결정하는 것과, 두 달 뒤에 알게 되는 것은 완전히 다른 일입니다.
정리
- 재하도급 자체는 문제가 아닙니다. 모르는 것이 문제입니다.
- 계약 전에 세 가지를 물으세요: 누가 하는지 / 개발자와 대화 가능한지 / 계약서에 적을 수 있는지
- 계약서에는 동의 조건부 허용 + 원 수급인 책임 유지 + 재위탁분 저작권 확보를 넣으세요.
- 진행 중이라면 회신 속도와 답변의 결에서 신호가 보입니다.
질문을 꺼내기 어색하다면 이렇게 시작하면 됩니다. "혹시 파트너사와 함께 하시는 부분이 있으면 미리 알고 싶어서요. 문제 삼으려는 게 아니라 연락 경로를 정리해 두려고요."
업체를 고르는 단계의 전체 검증 항목은 홈페이지 제작 업체 고르는 법에, 계약서 조항 전반은 웹사이트 제작 계약서의 권리 다발 문제에 정리해 두었습니다.