본문으로 건너뛰기
샐링잇 Sailing-it

IT 외주 맡기기 전에 꼭 확인해야 할 7가지

발주를 처음 해보는 분들이 가장 많이 놓치는 항목 7가지를 정리했습니다. 견적·일정·소스 귀속·운영 책임까지, 계약 전에 체크하면 사고가 절반 이하로 줄어듭니다.

약 3분 분량

위시켓이나 크몽 같은 SI 플랫폼이 활성화되면서 외주를 맡기는 진입 장벽이 많이 낮아졌습니다. 다만 그만큼 “받기 전엔 좋아 보였는데 받고 보니 못 쓰겠더라” 라는 사고도 함께 늘었습니다. 저희가 발주처 미팅을 다니면서 검토한 견적서·계약서를 보면, 사고가 발생하는 자리는 대체로 비슷합니다.

오늘은 그동안 미팅에서 매번 함께 짚어드리는 7가지를 정리해드립니다. 계약 전에 한 번씩 점검하시기만 해도 사고 확률이 절반 이하로 줄어듭니다.

1. WBS 기반 확정 견적인지

견적서가 “총 5,000만 원” 한 줄로 끝나면 위험 신호입니다. 그 안에 무엇이 들어 있는지, 어디서 줄이고 어디서 늘릴지 협상이 불가능하기 때문입니다.

좋은 견적서는 WBS(Work Breakdown Structure, 작업 분해 구조) 가 함께 옵니다. 화면 단위·기능 단위·인프라 단위로 행이 나뉘어 있고, 각 행에 공수(맨데이) 와 담당이 명시된 표입니다. 이 표가 있으면 “SNS 로그인을 빼면 며칠 줄어듭니까?” 같은 질문에 즉시 답을 받으실 수 있습니다.

WBS가 더 궁금하시다면 WBS란 무엇인가: 비개발자를 위한 작업 분해 구조 가이드 에서 자세히 풀어 두었습니다.

2. 변경관리 절차

요구사항은 반드시 바뀝니다. 어떤 프로젝트에서도 변경 없이 끝난 적은 없습니다. 중요한 것은 변경이 발생했을 때 어떻게 처리할지를 계약 전에 합의해두는 일입니다.

저희가 권장하는 흐름은 단순합니다. 변경 요청 → 영향도(공수·일정·비용) 회신 → 발주사 승인 → 반영. 이 절차 없이 “그냥 추가해주세요” 가 반복되면 마지막에 “왜 이렇게 늘어났느냐” 는 분쟁으로 이어집니다. 계약서에 5줄 정도면 충분하니 반드시 명시해두시기를 권합니다.

3. 산출물·소스·IP 귀속

특히 신생 회사나 1인 개발자에게 의뢰하실 때 자주 빠지는 항목입니다. 계약서에 다음을 명시하셨는지 확인해보십시오.

  • 소스 코드 100% 발주사 귀속
  • 디자인 원본 파일(Figma 등) 인계
  • 제3자 라이브러리·아이콘·폰트의 라이선스 정리표

이 항목이 빠져 있으면 외주사를 교체하거나 운영팀이 인수받을 때 문제가 생깁니다. “소스는 우리 거 아닌가요?” 가 통하지 않는 경우가 생각보다 많습니다.

4. 단계별 데모 / 검수 주기

월 1회 데모는 너무 깁니다. 한 달 동안 만든 결과물을 한 번에 확인할 경우, 방향이 어긋나 있어도 되돌리기에 너무 늦습니다. 주 1회 또는 격주 단위가 표준이라고 보시면 됩니다.

매 데모마다 지금까지 만든 결과물을 직접 클릭해 확인하시고, 회의록과 다음 스프린트 백로그를 문서로 남기는 흐름이 안전합니다. 데모가 없으면 마지막 단계에서 “다 다시 만들어 주세요” 가 됩니다. 저희도 초기에 같은 시행착오를 겪었기 때문에, 지금은 모든 프로젝트를 주 단위 데모로 진행합니다.

5. 인프라 비용 책임 주체

AWS·GCP·Supabase 같은 인프라 비용은 발주사 명의 계정에 결제수단을 등록해두시는 편이 안전합니다. 외주사 계정에 묶여 있으면 정산 시점, 운영 인수 시점에 항상 갈등이 발생합니다.

처음에 다소 번거롭더라도 발주사 계정에 외주사 IAM을 초대하는 방식이 가장 깔끔합니다. 저희도 이 방식으로 진행하고 있습니다.

6. 런칭 후 운영·하자보수 범위

“런칭” 으로 계약이 끝난다고 가정하시면 안 됩니다. 사실상 런칭은 운영의 시작입니다. 최소한 다음 항목은 명시해두십시오.

  • 무상 하자보수 기간 (보통 1~3개월)
  • 유상 운영 단가와 SLA(응답 시간, 장애 대응 기준)
  • 인계 문서: 배포 절차, 운영 매뉴얼, 모니터링 알림 채널

이 부분이 비어 있으면 런칭 직후 발견된 버그를 누가 고쳐야 할지부터 분쟁의 시작점이 됩니다.

7. 책임 가능한 한 팀 vs 분산된 외주

“기획은 A, 디자인은 B, 개발은 C, 인프라는 D” 로 나뉘면 문제가 발생했을 때 책임 소재가 흐려집니다. 한쪽에서 “그건 저쪽 책임입니다” 라고 하는 순간 발주사가 중간에서 PM 노릇을 하게 됩니다.

가능하시다면 기획·디자인·개발·인프라를 한 팀에서 책임지는 파트너를 선택하시는 편이 안전합니다. 분산이 불가피하다면 통합 PM을 한 명 두시거나, 발주사 측에서 PM 역할을 직접 수행할 수 있는 인력이 있는지 미리 점검해두시기를 권합니다.

마무리

이 7가지는 저희가 발주처 미팅에서 매번 함께 짚는 항목입니다. 계약 전 체크리스트로 활용하시면 사고 확률이 크게 줄어듭니다. 다음 글에서는 WBS를 어떻게 봐야 하고, 어떤 양식이 좋고 어떤 양식이 위험한지를 더 자세히 풀어드릴 예정입니다.