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

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

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

1. WBS 기반 확정 견적인지

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

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

WBS가 더 궁금하시다면 WBS란 무엇인가: 비개발자를 위한 작업 분해 구조 가이드 에서 자세히 풀어 두었습니다. 견적서를 4축으로 분리해 받는 법은 외주 견적서 항목 보는 법 글에 정리해 두었습니다.

2. 변경관리 절차

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

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

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

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

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

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

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

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

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

5. 인프라 비용 책임 주체

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

처음에 다소 번거롭더라도 발주사 계정에 외주사 IAM을 초대하는 방식이 가장 깔끔합니다. AWS IAM 권한 분리 모범 사례를 따르면 권한도 작업 범위 안으로 제한할 수 있고, 외주가 끝난 시점에 즉시 회수 가능합니다. 저희도 이 방식으로 진행하고 있습니다.

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

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

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

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

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

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

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

마무리

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

자주 묻는 질문

Q. 7가지 중에서 가장 중요한 항목 하나만 꼽는다면?

1번(WBS 기반 분해 견적) 입니다. WBS가 있으면 2~7번 항목 대부분이 자연스럽게 따라옵니다. 변경관리, 진행률, 인수 시점 분리가 모두 WBS의 행을 기준으로 운영되기 때문입니다. WBS 없는 외주는 계약 단계부터 협상의 도구가 없는 셈입니다.

Q. 하자보수 기간은 보통 어느 정도가 적정한가요?

국내 SI 표준은 1~3개월입니다. 트래픽이 많거나 결제·정산 같은 트랜잭션이 핵심인 서비스라면 3개월을 권장하고, 단순한 정보성 사이트라면 1개월도 무리는 없습니다. 무상 하자보수 범위에 "기능 추가"가 들어가지 않도록 계약서에 명시하시는 것이 중요합니다.

Q. 소스 코드 귀속을 계약서에 어떻게 적어야 하나요?

"본 용역의 산출물(소스 코드, 디자인 원본, 문서 일체) 의 저작권 및 소유권은 발주사에 100% 귀속한다." 같은 문장 한 줄이면 충분합니다. 추가로 "용역 종료 시 외주사는 소스 코드 저장소와 모든 원본 파일을 발주사에 인계한다." 를 함께 넣어두시면 인수 시점에 갈등이 줄어듭니다.

Q. 발주사 명의 AWS 계정을 만들기가 부담스럽습니다. 꼭 그래야 하나요?

꼭은 아니지만 강력히 권장됩니다. 외주사 계정에 묶여 있으면 정산·운영 인수 시점에 권한 이관에 시간이 걸리고, 청구서 분리도 어렵습니다. AWS는 무료로 계정 생성이 가능하고, 외주사가 IAM 역할만 받아 작업할 수 있어서 보안 면에서도 발주사 명의 계정이 더 안전합니다.

Q. 계약 전에 외주사가 신뢰할 만한지 어떻게 검증하나요?

3가지를 물어보십시오. 첫째, 진행 중인 프로젝트의 WBS를 (NDA 범위 안에서) 보여줄 수 있는가. 둘째, 변경관리 절차가 문서로 명문화되어 있는가. 셋째, 최근 3개 프로젝트의 런칭 후 운영 사례를 설명할 수 있는가. 세 질문에 즉시 답할 수 있는 회사라면 신뢰성 검증은 어느 정도 통과한 셈입니다.