[카테고리:] IT외주

서버 운영 유지보수는 개발이 끝난 뒤에 생각하면 이미 늦습니다. 출시 당일까지는 모두가 화면을 보고 있습니다. 그런데 그 다음 주 화요일 새벽 두 시, 결제가 되지 않는다는 문의가 쌓이기 시작하면 상황이 완전히 달라집니다. 발주사 담당자는 개발사 PM에게 전화를 걸지만 받지 않습니다. 아침이 되어 연락이 닿으면, 프로젝트를 만들었던 개발자는 이미 다른 프로젝트에 배정되었다는 답을 듣습니다. 계약서에는 ‘유지보수 1년’이라고 적혀 있습니다. 그런데 그 한 줄이 지금 이 장애를 누가 몇 시간 안에 고치는지는 아무것도 정해주지 않습니다.

디비컨설팅은 100건 이상의 웹·앱·플랫폼 프로젝트를 구축하고 운영까지 이어받아 왔습니다. 삼성물산 홈닉, GS건설 엘리시안 리조트, 하나투어 하나오픈챗, LS일렉트릭 테크스퀘어, 가천대학교 학사관리 시스템처럼 출시 이후에도 계속 돌아가야 하는 시스템들입니다. 그 경험에서 반복적으로 확인한 것은, 운영 단계의 사고가 기술 문제로 시작되는 경우는 드물다는 사실입니다. 대부분은 ‘누가 책임지는지’를 발주 단계에서 정하지 않은 결과로 나타납니다.

출시 직후가 가장 위험한 구간인 이유

개발 기간 중에는 모든 관심이 프로젝트에 집중되어 있습니다. 개발자도 배정되어 있고, PM도 매주 회의를 잡고, 문제가 생기면 그 자리에서 잡힙니다. 문제는 검수가 끝나고 잔금이 지급된 다음부터입니다. 프로젝트 조직은 해산되고, 시스템은 그때부터 실제 사용자를 받기 시작합니다. 관심이 가장 낮아지는 시점과 부하가 가장 높아지는 시점이 겹칩니다.

실사용자는 테스트 데이터처럼 행동하지 않습니다

검수 환경에서는 수십 건의 데이터로 확인합니다. 실제 서비스에서는 첫 주에 수천 건이 들어옵니다. 동시 접속, 이미지 업로드 용량, 푸시 발송량, 결제 재시도 같은 항목은 실사용 트래픽을 받아본 뒤에야 한계가 드러납니다. 개발 검수 단계에서 기능이 모두 통과했다는 것과, 실제 부하에서 견딘다는 것은 다른 이야기입니다.

장애는 대부분 코드가 아니라 연결 지점에서 납니다

운영 중 실제로 서비스를 멈추는 원인은 대개 외부와 맞닿은 부분입니다. 결제 대행사 인증서 만료, 문자·알림톡 발송 한도 초과, 도메인이나 SSL 인증서 갱신 누락, 서버 디스크 용량 초과, 외부 API 사양 변경. 어느 것도 개발사가 잘못 만들어서 생긴 문제가 아닙니다. 그래서 ‘하자보수’에 해당하지 않고, 그래서 아무도 자기 일이라고 생각하지 않습니다.

만든 사람이 남아 있지 않으면 대응 시간이 몇 배로 늘어납니다

같은 장애를, 그 코드를 직접 쓴 개발자는 한 시간 안에 원인을 찾습니다. 처음 보는 개발자는 구조를 파악하는 데만 이틀이 걸립니다. 문서가 없으면 더 걸립니다. 유지보수 계약이 ‘월 몇 시간 지원’ 형태로만 되어 있으면, 발주사는 그 파악 시간까지 자기 비용으로 지불하게 됩니다.

SLA를 꼼꼼히 써도 해결되지 않는 부분

이 문제를 검색하면 대부분 ‘SLA를 제대로 쓰라’는 조언이 나옵니다. 응답 시간, 복구 시간, 가동률을 숫자로 못 박으라는 것입니다. 맞는 조언이고, 개발 외주 계약서에 반드시 들어가야 하는 항목입니다.

다만 SLA는 약속을 문서로 만드는 장치이고, 그 약속을 실행할 사람이 남아 있는지는 다른 문제입니다. 프로젝트 단위로 발주하면, 개발사는 납품 시점에 그 인력을 다음 프로젝트로 옮깁니다. 계약상 ‘4시간 내 응답’은 지켜집니다. 접수 담당자가 4시간 안에 접수했다는 뜻이기 때문입니다. 실제로 코드를 열어볼 사람이 언제 붙는지는 SLA에 적혀 있지 않습니다.

그래서 운영 문제는 조항의 문제가 아니라 팀 연속성의 문제입니다. 계약서를 강하게 쓰는 것보다, 만든 팀이 남는 구조로 발주하는 것이 먼저입니다.

발주사가 실제로 선택하는 세 가지 구조

운영을 누가 맡느냐는 결국 어떤 구조로 발주했는지에 따라 결정됩니다. 선택지는 세 가지입니다.

	국내 개발사 (프로젝트 단위)	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
출시 후 인력 잔류	낮음	보통	높음
장애 시 1차 응답 주체	접수 창구	발주사 본인	한국 PM
업무시간 외 장애 대응	어려움	발주사가 직접 대응	시차를 활용해 커버
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외에 직접 발주하면 단가는 분명히 내려갑니다. 문제는 운영 단계입니다. 장애가 났을 때 상황을 정리하고, 우선순위를 정하고, 영어로 지시하고, 조치 결과를 검증하는 일이 전부 발주사 담당자에게 넘어옵니다. 사내에 그 일을 할 개발 인력이 없다면, 절감한 단가는 담당자의 밤과 주말로 지불됩니다.

반대로 시차는 제대로 설계하면 오히려 자산입니다. 한국 시간 새벽은 인도 기준으로 업무 시간입니다. 한국인 PM이 접수와 판단을 맡고 글로벌 개발팀이 그 시간대에 손을 대는 구조라면, 국내 개발사가 ‘내일 오전에 확인하겠습니다’라고 답하는 시간에 이미 조치가 진행됩니다.

인수 전에 정해야 할 6가지

운영을 넘겨받기 전에 다음 여섯 가지는 문서로 확정하시기를 권합니다. 여섯 항목 모두 개발이 끝난 뒤에는 협상력이 급격히 떨어지는 항목입니다.

1. 장애 등급과 등급별 대응 시간

‘신속히 대응’은 기준이 아닙니다. 서비스 전체 중단, 핵심 기능 장애, 일부 화면 오류를 등급으로 나누고, 등급별로 최초 응답 시간과 임시 복구 목표를 각각 적으십시오. 특히 ‘최초 응답’과 ‘복구 착수’를 구분해서 쓰는 것이 중요합니다. 이 둘을 한 문장으로 합쳐 두면 접수만으로 의무가 이행됩니다.

2. 대응 시간대와 시차 처리 주체

평일 09-18시인지, 24시간인지, 주말과 공휴일은 어떻게 되는지를 명시합니다. 해외 인력이 포함된 팀이라면 시차를 누가 흡수하는지가 핵심입니다. 발주사가 영어로 직접 연락해야 하는 구조인지, 한국인 PM이 창구가 되는 구조인지에 따라 담당자의 실제 부담이 완전히 달라집니다.

3. 서버·도메인·계정의 명의

클라우드 계정, 도메인, SSL 인증서, 앱스토어와 구글 플레이 개발자 계정, 결제 대행사 가맹점 계정. 이것들이 개발사 명의로 되어 있으면 나중에 업체를 바꿀 때 서비스를 인질로 잡힌 상태가 됩니다. 가능하면 전부 발주사 명의로 개설하고, 개발사에는 접근 권한만 부여하십시오. 이미 개발사 명의로 진행되었다면 개발사 교체를 검토하기 전에 명의 이전 절차부터 확인해야 합니다.

4. 운영 서버 배포 권한과 절차

누가 운영 서버에 코드를 반영할 수 있는지, 반영 전에 누구의 승인이 필요한지, 문제가 생겼을 때 되돌리는 절차가 무엇인지를 정합니다. 권한이 한 사람에게만 있으면 그 사람이 휴가일 때 서비스가 멈춥니다. 반대로 아무나 반영할 수 있으면 원인 추적이 불가능해집니다.

5. 하자보수와 유지보수의 경계

계약한 기능이 명세대로 동작하지 않는 것은 하자이고 무상입니다. 새 기능을 추가하는 것은 유상입니다. 분쟁은 그 사이에서 발생합니다. 외부 API 사양이 바뀌어서 연동이 깨진 경우, OS 버전이 올라가서 화면이 틀어진 경우, 사용자가 늘어서 느려진 경우는 어느 쪽인지 미리 적어두어야 합니다. 비용 산정 구조 자체는 앱 유지보수 비용에서 항목별로 정리해 두었습니다.

6. 원 개발 인력의 잔류 여부와 인계 문서

가장 중요하지만 가장 자주 빠지는 항목입니다. 만든 개발자 중 몇 명이 운영 기간에도 남는지, 남지 않는다면 무엇을 문서로 남기는지를 확정하십시오. 최소한 API 명세, DB 스키마, 배포 절차, 외부 연동 계정 목록, 알려진 이슈 목록은 인계 대상이어야 합니다. 이 문서가 없으면 나머지 다섯 항목을 아무리 잘 써도 대응 속도가 나오지 않습니다.

디비컨설팅이 운영을 이어받는 방식

IT 아웃소싱을 전담팀 형태로 진행하기 때문에, 운영은 별도 단계가 아니라 같은 팀이 계속 맡는 구간입니다. 진행 절차는 다섯 단계입니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 이 단계에서 운영 기준까지 함께 정의합니다. 장애 등급, 대응 시간대, 계정 명의를 개발 착수 전에 정해두면 인수 시점의 협상이 사라집니다. 무엇을 문서로 정리해야 하는지는 요구사항 정의서에서 다뤘습니다.
2. 개발팀 구성 — 전담팀을 2~4주 안에 구성합니다. 인력 단위가 아니라 팀 단위로 배정되기 때문에, 출시 이후에도 같은 인원이 유지됩니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 것이 기준입니다.
4. 테스트 및 배포 — QA 프로세스를 거친 뒤 배포합니다. QA를 전담 조직이 맡는지 개발자가 겸하는지의 차이는 QA 전담팀에서 설명했습니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다. 소스코드는 발주사에 귀속되며, API 명세·DB 스키마·배포 절차 문서까지 인계 대상입니다.

구조의 핵심은 단순합니다. 발주사는 한국인 PM 한 사람과 한국어로 소통하고, 그 PM이 요구사항 정의·일정·검수·장애 접수와 판단을 책임집니다. 글로벌 개발팀을 발주사가 직접 관리하지 않습니다.

출시 후에도 계속 돌아가고 있는 시스템들

운영을 감당할 수 있는지는 실제로 운영해 본 시스템으로 판단하시는 편이 정확합니다.

• 삼성물산 — 홈닉 · 주거 플랫폼 앱. 입주민이 매일 쓰는 서비스로, 중단이 곧 민원이 되는 유형입니다.
• GS건설 — 엘리시안 리조트 · 리조트 웹과 앱 통합 구축. 예약이 몰리는 성수기 부하를 전제로 설계했습니다.
• 하나투어 — 하나오픈챗 · 여행 상담 채팅 서비스. 실시간 응답이 서비스 품질 그 자체인 구조입니다.
• LS일렉트릭 — 테크스퀘어 · 산업 B2B 거래 플랫폼.
• 직방 — 호갱노노 · 부동산 데이터 서비스.
• 가천대학교 · 학사관리 시스템. 수강신청처럼 특정 시점에 부하가 집중되는 시스템입니다.
• 센터필드 · 센트로폴리스 · 그랑서울 · 프라임 오피스 빌딩 관리 시스템.
• 교보생명 · 사내벤처(글펍) 커뮤니티 서비스.

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 인력이 없거나 한두 명뿐이어서, 장애 시 판단을 내려줄 사람이 없는 기업
• 이미 출시한 서비스가 있는데 만든 개발사와 연락이 잘 되지 않는 기업
• 구축과 운영을 한 팀에 맡겨 인계 손실을 줄이고 싶은 기업
• 실사용자가 매일 쓰는 서비스여서 중단 시간이 그대로 비용이 되는 기업
• 웹 개발 외주 또는 앱 개발 외주를 준비 중이면서, 발주 단계에서 운영 조건까지 함께 정하고 싶은 기업

반대로 권하지 않습니다

• 사내에 운영 조직이 이미 있는 경우. 인프라 담당과 백엔드 인력이 상시 대기하는 조직이라면, 외부에 운영을 맡기는 것이 오히려 단계를 늘립니다. 필요한 구간만 인력 단위로 보강하는 편이 낫습니다.
• 내부 정책상 외부 인력의 운영 서버 접근이 불가능한 경우. 접근 권한 없이 장애 대응을 위탁하면 책임만 이전되고 조치는 되지 않습니다.
• 월 운영 예산을 전혀 잡지 않은 경우. 구축비만 확보하고 운영비를 0으로 두면, 어떤 구조를 택하든 두세 달 안에 같은 문제가 반복됩니다. 이 경우에는 구축 범위를 줄여서 운영 예산을 확보하는 것이 먼저입니다.
• 단순 서버 임대나 모니터링 도구만 필요한 경우. 그것은 호스팅 업체의 영역이고, 개발팀을 붙일 필요가 없습니다.

자주 묻는 질문

해외 개발팀이 대응하는데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 장애 접수, 상황 판단, 우선순위 결정, 조치 결과 확인이 모두 PM 책임입니다. 발주사가 영어로 개발자에게 직접 지시하는 상황은 발생하지 않습니다.

소스코드와 서버는 누구 소유가 되나요?

소스코드는 발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계 대상입니다. 서버와 클라우드 계정도 발주사 명의로 개설하는 것을 권장하며, 저희는 필요한 접근 권한만 받아 운영합니다. 언제든 다른 업체로 이관하거나 내부 인력으로 전환할 수 있는 상태를 유지하는 것이 원칙입니다.

다른 회사가 만든 시스템의 운영만 맡길 수 있나요?

가능합니다. 다만 인계 자료의 상태를 먼저 확인해야 합니다. 소스코드 접근, 서버와 계정 권한, DB 구조, 외부 연동 목록이 확보되는지에 따라 착수 시점이 달라집니다. 자료가 부족하면 구조 파악 기간을 별도로 잡고, 그 결과를 문서로 남긴 뒤 운영에 들어갑니다.

기획서나 문서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 운영 위탁의 경우에는 현재 서비스 주소, 월 사용자 규모, 최근 발생한 장애 유형 정도만 알려주시면 검토가 가능합니다.

운영 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중에도 조정할 수 있습니다. 출시 직후 몇 달은 인력을 두텁게 두고 안정화된 뒤 축소하는 방식이 일반적입니다.

정리

서버 운영 유지보수에서 실제로 문제가 되는 것은 계약서에 적힌 시간이 아니라, 그 시간을 지킬 사람이 남아 있는지입니다. 장애 등급, 대응 시간대, 계정 명의, 배포 권한, 하자와 유지보수의 경계, 원 개발 인력의 잔류 여부 — 이 여섯 가지를 인수 전에 문서로 정해두면 대부분의 분쟁이 사라집니다. 그리고 이 여섯 가지가 자연스럽게 지켜지는 구조는 구축과 운영을 같은 팀이 맡고, 그 팀과의 소통을 한국인 PM이 책임지는 형태입니다. IT 외주에서 분쟁이 반복되는 이유도 결국 같은 지점에 있습니다.

“완료됐습니다”라는 한 줄에서 시작되는 문제

개발 검수는 개발사가 “완료됐습니다”라고 통보한 순간에 시작하는 일이 아닙니다. 그런데 실제로는 그 순간에 처음 시작하는 회사가 대부분입니다.

화면을 열어 봅니다. 로그인이 됩니다. 목록이 보이고 버튼이 눌립니다. 겉으로는 문제가 없습니다. 담당 팀장은 이 화면을 보고 승인 여부를 판단해야 합니다. 그런데 무엇을 기준으로 판단할지가 손에 없습니다. 계약서에는 “상호 협의하여 검수한다”고만 적혀 있습니다. 기획 단계의 요구사항은 메신저와 메일과 회의록에 흩어져 있습니다. 어떤 기능은 빠진 것 같은데, 빠진 것인지 애초에 범위가 아니었는지 확인할 문서가 없습니다.

그래서 대개 이렇게 끝납니다. “일단 오픈하고 수정하죠.” 잔금을 지급합니다. 다음 주에 결제 오류가 나옵니다. 개발사에 연락하면 그건 추가 개발이라는 답이 옵니다. 이 시점에 발주사가 쓸 수 있는 카드는 없습니다. 이미 승인했고, 이미 지급했습니다. 절반 이상의 외주 프로젝트가 납기 후 분쟁으로 끝나는 이유도 대부분 여기서 갈립니다.

이 글의 근거

디비컨설팅은 한국인 PM이 검증된 글로벌 개발팀을 관리하는 방식으로 100건 이상의 프로젝트를 수행했습니다. 협업 중인 글로벌 파트너사는 50개 이상이고, 고객 만족도는 98%입니다.

이 숫자를 먼저 말씀드리는 이유는 하나입니다. 프로젝트가 100건을 넘기면 실패하는 지점이 반복적으로 보입니다. 그리고 그 지점은 대부분 기술이 아닙니다. 개발 검수를 승인할 기준이 계약 시점에 문서로 존재하지 않았다는 것, 그 한 가지입니다.

아래는 그 반복을 정리한 내용입니다.

개발 검수가 실패하는 구조적인 이유

검수 기준이 계약 시점에 없었습니다

검수는 비교 작업입니다. 비교에는 대상이 두 개 필요합니다. 완성된 결과물과, 처음에 합의한 기준입니다. 기준이 없으면 검수는 비교가 아니라 감상이 됩니다. “괜찮아 보이는데요”와 “좀 부족한 것 같은데요” 사이에서 회의가 끝나고, 결론은 목소리가 큰 쪽으로 납니다.

기준은 개발이 끝난 뒤에 만들 수 없습니다. 결과물을 본 다음에 쓰는 기준은 이미 결과물에 맞춰진 기준입니다. 그래서 요구사항 정의서를 어디까지 써야 하는지가 검수의 출발점입니다.

“동작한다”와 “요구사항을 충족한다”를 구분하지 않았습니다

개발사가 시연하는 것은 “동작한다”입니다. 발주사가 확인해야 하는 것은 “요구사항을 충족한다”입니다. 이 둘은 자주 다릅니다.

정산 기능을 예로 들겠습니다. 화면에서 숫자가 나옵니다. 동작합니다. 그런데 부분 환불이 섞인 달의 정산 금액이 맞는지는 화면을 눌러서 알 수 없습니다. 시연은 성공 경로만 보여줍니다. 요구사항 충족 여부는 실패 경로에서 갈립니다.

검수 담당자가 개발 내용을 모릅니다

검수를 맡는 사람은 보통 그 업무를 가장 잘 아는 실무 팀장입니다. 업무는 압니다. 그러나 이 기능이 어떤 데이터를 어디에 어떻게 쌓고 있는지는 모릅니다. 그래서 질문을 만들 수 없습니다. 개발사가 “그건 구조상 그렇게 됩니다”라고 답하면 검증할 방법이 없습니다.

담당자의 잘못이 아닙니다. 발주사 안에 개발 언어로 질문할 수 있는 사람이 없는 상태로 프로젝트를 시작한 결과입니다.

잔금 지급과 검수 승인이 같은 시점에 묶여 있습니다

많은 계약서가 검수 승인일에 잔금을 지급하도록 되어 있습니다. 이 구조에서는 승인하는 순간 협상력이 사라집니다. 승인 이후에 발견된 문제는 전부 추가 요청이 되고, 추가 요청은 대부분 유상입니다. 최종 비용이 견적의 1.5배가 되는 일은 드물지 않습니다. 개발 외주 계약서에서 서명 전에 확인할 조항에 이 지급 구조가 포함되어야 하는 이유입니다.

선택지는 세 개입니다. 차이는 “누가 검수 기준을 쓰는가”입니다

발주 방식을 정할 때 보통 단가를 비교합니다. 그런데 결과를 결정하는 변수는 단가가 아니라, 검수 기준을 누가 쓰는가입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
검수 기준 작성 책임	개발사	발주사 본인	한국 PM
검수 소통 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 개발팀에 직접 발주하는 방식이 기대만큼 싸지 않은 이유가 여기 있습니다. 단가는 내려갑니다. 대신 국내 개발사가 해 주던 일 하나가 발주사로 넘어옵니다. 요구사항을 영어로 명세하고, 검수 항목을 정의하고, 결과물을 항목별로 대조하는 일입니다.

이 일은 발주사의 시니어급 인력만 할 수 있습니다. 그리고 몇 주가 걸립니다. 그 시간은 견적서에 나타나지 않습니다. 회사에서 가장 바쁜 사람의 일정에서 조용히 빠져나갑니다.

핵심은 이것입니다. 검수 기준을 정의하는 일은 없어지지 않습니다. 누군가는 해야 합니다. 국내 개발사에 맡기면 비용으로 지불하고, 해외에 직접 발주하면 발주사 담당자의 시간으로 지불합니다. 한국인 PM을 두는 IT 아웃소싱 방식은 그 일을 맡을 사람을 프로젝트 안에 두는 방식입니다.

디비컨설팅이 검수를 통제하는 방식

진행 방식은 5단계입니다. 각 단계가 검수 관점에서 무엇을 남기는지를 기준으로 설명하겠습니다.

① 상담 및 요구 분석 — 한국인 PM이 발주사와 한국어로 요구사항을 정리하고 문서화합니다. 이 문서가 검수 기준의 원본이 됩니다. 기능 단위로 “무엇이 되면 완료인지”를 이 단계에서 적습니다. 기획서가 없는 상태로 오시는 경우가 많고, 그 상태를 전제로 시작합니다.

② 개발팀 구성 — 정리된 요구사항에 맞춰 2~4주 내에 전담팀을 구성합니다. 팀을 먼저 만들고 요구사항을 거기에 맞추지 않습니다. 순서가 반대가 되면 범위가 팀 사정에 맞춰 휘어집니다.

③ 프로젝트 개발 — 진행 상황을 투명하게 공유합니다. 마지막에 한 번 검수하는 대신, ①에서 만든 문서의 항목이 하나씩 닫히는 것을 확인합니다. 몰아서 하는 검수는 이미 늦은 검수입니다.

④ 테스트 및 배포 — QA를 거친 후 릴리즈합니다. 이 시점의 확인 대상은 화면이 아니라 ①의 문서입니다. QA 전담팀이 없는 개발사를 피해야 하는 이유가 이 단계에서 드러납니다.

⑤ 운영 및 유지보수 — 운영을 이어가고, 인계 시에는 문서와 함께 넘깁니다. 소스코드, API 명세, DB 스키마, 배포 절차가 포함됩니다. 출시 이후의 비용 구조는 앱 유지보수 비용에서 따로 정리했습니다.

발주사가 영어로 소통하는 구간은 없습니다. 요구사항 정의, 일정, 검수는 한국인 PM의 책임입니다.

인수 전에 확인할 6가지

인수 전 개발 검수에서 확인할 항목은 여섯 개입니다. 각 항목 뒤에, 그것이 가능하려면 발주 시점에 무엇이 있어야 했는지를 함께 적었습니다. 대부분은 지금 만들 수 없는 것입니다.

1. 요구사항 정의서 대비 기능 대조표

기능 목록을 받는 것과, 요구사항 정의서의 각 항목에 결과물을 1:1로 붙인 표를 받는 것은 다릅니다. 후자를 요구하십시오. 항목마다 구현 여부, 확인 방법, 확인한 사람이 적혀 있어야 합니다.

이 표는 요구사항 정의서가 있어야 만들 수 있습니다. 문서가 없으면 대조표는 결국 개발사가 만든 기능 목록이 됩니다.

2. 소스코드와 저장소 이관, 그리고 귀속

전체 소스코드와 저장소를 넘겨받으십시오. 소유권이 발주사에 귀속되는지 계약서에서 확인하십시오. 압축 파일 하나가 아니라 커밋 이력이 남은 저장소 단위로 받는 것이 맞습니다. 외부 서비스 계정과 키도 인계 대상입니다.

이 조항은 계약서에 있거나 없습니다. 인수 시점에 새로 협상할 수 없습니다.

3. API 명세 · DB 스키마 · 배포 절차 문서

이 세 가지가 없으면 다음 개발사는 코드를 읽는 데만 몇 주를 씁니다. 배포 절차는 “누가 어떤 명령으로 어디에 올리는지”가 한 문서에 정리되어 있어야 합니다. 특정 담당자의 머릿속에 있는 상태는 인계가 아닙니다. 개발사를 교체해야 하는 상황에서 이 문서의 유무가 이관 비용을 결정합니다.

4. 더미 데이터가 아닌 실사용 데이터 기준 테스트

시연은 대부분 정리된 데이터로 진행됩니다. 실제 데이터는 지저분합니다. 공백이 들어간 이름, 누락된 값, 예상보다 긴 텍스트, 과거 시스템에서 옮겨온 이력이 섞여 있습니다. 이관 데이터나 실제 운영 데이터로 다시 확인하십시오. 여기서 나오는 문제가 오픈 직후 장애의 대부분입니다.

5. 장애와 예외 상황에서의 동작

결제가 중간에 실패했을 때, 외부 API가 응답하지 않을 때, 같은 요청이 두 번 들어왔을 때 무엇이 남는지 확인하십시오. 정상 경로는 대체로 동작합니다. 사고는 예외에서 납니다. 로그가 남는지, 실패한 거래를 나중에 찾을 수 있는지도 함께 보십시오.

6. 잔금 지급 시점과 검수 승인의 분리

검수 승인일과 잔금 지급일을 같은 날로 두지 마십시오. 승인 후 일정 기간의 하자보수 기간을 두고, 그 기간이 지난 뒤에 잔금을 지급하는 구조가 안전합니다. 하자보수의 범위도 문서로 정해 두십시오. “버그는 무상, 신규 기능은 유상”만으로는 부족합니다. 다툼은 그 경계에서 생깁니다.

이것도 계약 조항입니다. 인수 직전에 만들 수 없습니다.

이 방식으로 만든 서비스

• 삼성물산 홈닉 — 주거 플랫폼 앱
• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합
• 하나투어 하나오픈챗 — 여행 상담 채팅
• 직방 호갱노노 — 부동산 데이터 서비스
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 가천대학교 학사관리 시스템

공통점은 규모가 아니라 검수 난이도입니다. 대기업과 대학은 내부 승인 절차가 있고, 문서 없이 인수하지 않습니다. 요구사항 정의서와 인계 문서가 처음부터 갖춰져야 통과되는 프로젝트들입니다. 전체 구축 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합합니다

• 웹·앱·플랫폼을 외주로 만들어야 하지만 내부에 개발 총괄이 없는 경우
• 기획서가 아직 없고, 해결할 문제와 필요한 기능 수준만 정리된 경우
• 국내 개발사 견적이 예산을 넘고, 해외 발주는 관리 부담 때문에 망설이는 경우
• 이전 프로젝트에서 인수 후에 문제가 나왔던 경험이 있는 경우

권하지 않습니다

• 내부에 시니어 개발자와 QA가 이미 있고, 요구사항 정의서와 검수 기준을 직접 쓸 수 있는 조직이라면 굳이 필요하지 않습니다. 이 경우 개발 인력만 확보하는 방식이 더 저렴합니다.
• 며칠 안에 결과물이 필요한 일이라면 맞지 않습니다. 전담팀 구성에 2~4주가 필요합니다.
• 요구사항을 정리할 시간을 전혀 낼 수 없는 상황이라면 시작하지 않는 편이 낫습니다. ① 단계에는 발주사의 시간이 반드시 들어갑니다. 몇 주가 아니라 몇 차례의 회의 수준이지만, 그것도 어렵다면 결과가 좋지 않습니다.

자주 묻는 질문

해외 개발팀이면 의사소통은 어떻게 됩니까?

발주사는 한국인 PM과 한국어로만 소통합니다. 개발팀과 직접 회의하거나 영어로 문서를 쓰는 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과의 소통에서 생기는 오해는 PM이 흡수해야 하는 비용이고, 발주사로 넘기지 않습니다.

기획서가 없는데 검수 기준을 정할 수 있습니까?

가능합니다. 그리고 그 상태로 시작하는 경우가 더 많습니다. 첫 상담에 필요한 것은 네 가지입니다. 해결하려는 문제, 주요 사용자, 반드시 있어야 하는 기능 3~5개, 일정과 예산의 범위입니다. 이 네 가지가 있으면 요구사항 정의서를 만들 수 있고, 그 문서가 검수 기준이 됩니다. 기획서를 완성한 뒤에 오시라고 말씀드리지는 않습니다. 그 작업이 사실 가장 어려운 부분입니다.

소스코드 소유권은 어떻게 됩니까?

발주사에 귀속됩니다. 소스코드와 저장소 전체를 인계하고, API 명세, DB 스키마, 배포 절차 문서까지 함께 넘깁니다. 다른 회사로 유지보수를 옮기더라도 문서만으로 이어받을 수 있는 상태로 인계하는 것을 원칙으로 합니다. 이 조건은 계약서에 명시합니다.

팀 규모는 조정할 수 있습니까?

전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있습니다. 진행 중에도 조정이 가능합니다. 초기 개발에는 인원을 늘리고 안정화 이후에 줄이는 형태가 일반적입니다.

검수에서 문제가 나오면 어떻게 됩니까?

요구사항 정의서에 있는 항목이 충족되지 않았다면 저희 책임으로 처리합니다. 정의서에 없던 요구라면 범위 변경으로 보고 일정과 비용을 다시 협의합니다. 이 구분이 가능한 이유는 ① 단계에서 만든 문서가 있기 때문입니다. 문서가 없으면 모든 논의가 “원래 그렇게 말했는지”를 다투는 일이 됩니다.

정리

개발 검수는 마지막 단계의 확인 절차처럼 보이지만, 실제로는 발주 시점에 결정되는 일입니다. 검수 기준은 개발이 끝난 뒤에 만들 수 없습니다. 결과물을 보고 쓴 기준은 결과물을 통과시키는 기준이 되기 때문입니다. 그래서 질문은 “어떻게 검수할 것인가”가 아니라 “발주 시점에 검수 기준을 쓸 사람이 우리 회사 안에 있는가”입니다. 있다면 개발 인력만 확보하면 됩니다. 없다면 그 역할을 대신 맡을 한국인 PM이 필요합니다. 단가를 비교하기 전에 이 질문을 먼저 정리하시는 것을 권합니다.

개발사 교체를 검색해서 이 글을 보고 계신다면, 아마 지난 몇 주 동안 거의 같은 내용의 주간 보고를 반복해서 받고 계실 겁니다. 진행률은 지난달에도 80%였고 이번 달에도 80%입니다. 데모는 매번 “거의 다 됐다”는 설명과 함께 열리지만, 화면 두세 개를 넘기면 멈춥니다. 수정 요청에 답이 오는 데 이틀이 걸리고, 그 답은 대개 “확인 후 회신드리겠습니다”입니다.

이 상태에서 가장 먼저 드는 생각은 교체가 아니라 계산입니다. 이미 지급한 기성금이 얼마인지, 여기서 손을 떼면 그 돈이 어떻게 되는지, 새로 시작하면 처음부터 다시 해야 하는 것은 아닌지를 먼저 따지게 됩니다. 그래서 대부분의 발주사는 필요한 시점보다 훨씬 오래 버팁니다. 한 달만 더 기다려 보자는 판단이 세 번 반복되면 분기가 지나가 있습니다.

이 글은 개발사 교체를 언제 결정해야 하는지, 결정 전에 무엇을 확보해야 하는지, 교체할 곳을 어떤 기준으로 골라야 하는지를 순서대로 정리했습니다. 미리 말씀드리면 결론은 “더 좋은 개발사를 찾으십시오”가 아닙니다. 첫 번째 개발사가 실패한 이유는 대개 그 회사의 성의 문제가 아니라 발주 구조의 문제이고, 같은 구조를 가진 다른 회사로 옮기면 같은 일이 다시 일어납니다.

디비컨설팅은 100개 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 협업하며, 고객 만족도 98%를 유지하고 있습니다. 삼성물산, GS건설, LS일렉트릭, 하나투어, 가천대학교의 서비스를 구축했습니다. 아래 내용은 그 과정에서 반복적으로 확인한 패턴입니다.

개발사 교체가 논의되는 프로젝트의 공통 구조

멈춘 프로젝트를 들여다보면, 원인이 담당 개발자의 역량보다 앞선 단계에 있는 경우가 많습니다. 계약 시점에 이미 정해진 세 가지 구조 때문에 프로젝트는 대체로 같은 방식으로 멈춥니다. 저희가 IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조를 따로 정리한 이유도 여기에 있습니다.

요구사항이 문서로 존재하지 않습니다

착수 시점에 발주사가 받은 문서가 제안서와 견적서뿐인 경우가 많습니다. 화면 정의서, 기능 명세, 예외 처리 규칙이 없는 상태로 개발이 시작되면 이후의 모든 논의가 기억에 의존하게 됩니다. 회의에서 이야기한 기능이 빠져 있을 때 발주사는 “분명히 말씀드렸다”고 하고, 개발사는 “그 범위는 계약에 없었다”고 합니다. 양쪽 다 거짓말을 하는 것이 아니라 판단할 근거가 없는 것입니다.

이 구조에서는 분쟁이 사실 확인이 아니라 협상으로 흐릅니다. 그리고 협상은 대개 발주사에게 불리합니다. 개발사는 남은 일정과 투입 인력을 알고 있고 발주사는 모르기 때문입니다. 요구사항 문서는 개발을 잘하기 위한 부속물이 아니라, 분쟁이 생겼을 때 사실관계를 확정하는 장치입니다.

진행률 보고를 검증할 방법이 없습니다

“80%”라는 숫자는 검증 가능한 형태가 아닙니다. 무엇을 기준으로 80%인지, 남은 20%에 어떤 작업이 포함되는지가 정의되어 있지 않기 때문입니다. 진행률이 몇 달째 같은 자리에 머무는 프로젝트는 일이 아예 진행되지 않아서가 아니라, 처음부터 진행률을 셀 수 있는 단위로 쪼개지 않았기 때문에 그렇게 보입니다.

검증 가능한 보고는 숫자가 아니라 상태로 옵니다. 어떤 기능이 테스트 서버에 올라가 있고, 어떤 기능이 검수 대기이고, 어떤 항목이 아직 착수되지 않았는지가 목록으로 나와야 합니다. 발주사가 직접 눌러 볼 수 있는 테스트 환경이 없다면, 지금 받고 있는 진행률은 근거를 확인할 수 없는 숫자입니다.

산출물과 소스코드가 개발사 안에만 있습니다

세 번째 구조가 교체를 가장 어렵게 만듭니다. 소스코드가 개발사 계정의 저장소에만 있고, 서버와 도메인과 각종 API 키가 개발사 명의로 발급되어 있고, 데이터베이스 구조를 아는 사람이 그쪽 개발자 한 명뿐인 상태입니다. 이때 교체는 계약 해지의 문제가 아니라 이관의 문제가 됩니다.

이 구조는 시간이 지날수록 나빠집니다. 코드는 늘어나지만 문서는 늘지 않기 때문입니다. 출시 이후에도 같은 문제가 이어지는 이유는 인수인계되지 않은 코드가 유지보수 비용을 만드는 구조와 동일합니다.

교체를 망설이게 만드는 것은 이미 쓴 돈입니다. 하지만 실제로 비용을 키우는 것은 결정을 미루는 시간입니다. 이미 지급한 금액은 교체를 하든 하지 않든 회수되지 않는 반면, 지연되는 동안 발생하는 비용 — 시장 진입 시점을 놓치는 손실, 담당자가 조율에 쓰는 시간, 그리고 매달 늘어나는 이관 범위 — 은 계속 새로 발생합니다. 판단 기준은 “지금까지 얼마를 썼는가”가 아니라 “이 개발사와 계속 갔을 때 남은 일정 안에 완료될 근거가 있는가”입니다.

교체 전에 확인할 6가지

교체를 결정했다면, 통보 전에 확보해야 할 것이 있습니다. 순서가 중요합니다. 해지 의사를 먼저 전달하면 협조를 받기 어려워지는 경우가 많기 때문에, 아래 항목은 가능한 한 통보 이전에 확인하시는 편이 안전합니다.

1. 소스코드와 형상관리 접근 권한이 우리에게 있는지

Git 저장소에 발주사 계정으로 접근할 수 있는지 확인하십시오. 볼 것은 세 가지입니다. 저장소의 소유 계정이 누구인지, 전체 커밋 이력을 내려받을 수 있는지, 현재 운영 중인 버전이 어느 브랜치인지입니다. 개발사가 완성된 파일만 압축해서 전달하는 방식이라면 이력이 없는 코드를 받게 되고, 다음 개발사는 왜 그렇게 구현했는지를 알 수 없습니다. 서버, 도메인, 클라우드, 외부 API 계정의 명의도 같은 기준으로 확인하십시오.

2. 산출물 범위가 문서로 존재하는지

계약서에 적힌 산출물 목록과 실제로 받은 문서를 나란히 놓고 비교하십시오. 최소한 기획서(화면 정의서), API 명세, 데이터베이스 스키마, 배포 절차서 네 가지는 있어야 다음 개발사가 이어받을 수 있습니다. 특히 배포 절차서가 없으면 코드를 받아도 서비스를 다시 띄우지 못하는 상황이 생깁니다. 없다면 지금 요청하십시오. 계약 관계가 유지되는 동안이 이 요청이 통하는 마지막 시점입니다.

3. 중도 해지 조항과 기성 정산 기준

계약서에서 해지 통보 기간, 귀책사유 판단 방식, 기성 정산 기준, 지연배상금 조항을 먼저 확인하십시오. 기성 정산이 투입 공수 기준인지 완료 산출물 기준인지에 따라 정산 금액이 크게 달라집니다. 완료 산출물 기준이라면, 2번에서 확인한 문서 상태가 그대로 협상 근거가 됩니다. 다음 계약에서 같은 상황을 피하려면 개발 외주 계약서에서 서명 전에 확인할 조항을 함께 보시는 것이 좋습니다. 이 단계에서 오간 메일과 회의록을 시간순으로 정리해 두시는 것도 실무적으로 도움이 됩니다.

4. 이어받을 수 있는 상태인지, 재개발이 빠른지

감정이 아니라 기준으로 판단해야 하는 항목입니다. 다음 중 해당하는 것이 많다면, 재개발이 이어받기보다 빠른 경우도 있습니다.

• 코드에 주석과 문서가 거의 없고, 함수·변수 이름만으로 의도를 알 수 없다
• 데이터베이스 구조가 정리되지 않아 화면 하나를 고치면 다른 화면이 깨진다
• 테스트 코드가 전혀 없어 수정 후 정상 동작을 수동으로만 확인할 수 있다
• 사용된 프레임워크나 라이브러리 버전이 이미 지원 종료 상태다
• 완료로 보고된 기능 중 실제로 동작하는 비율이 절반 이하다

반대로 기능이 화면 단위로 분리되어 있고, 데이터 구조가 정리되어 있고, 배포가 재현 가능하다면 이어받는 편이 유리합니다. 판단 방식 자체는 고칠 것과 다시 만들 것을 가르는 기준과 같습니다. 다만 이 판단은 코드를 열어 보지 않고는 할 수 없습니다. 교체 후보 업체에 기존 코드 진단을 먼저 요청하시고, 진단 없이 견적부터 제시하는 곳은 한 번 더 확인해 보시는 것이 좋습니다.

5. 지식재산권과 소스코드 소유권이 누구에게 귀속되는지

계약서에 소유권 귀속 조항이 있는지, 있다면 누구에게 귀속되는지 확인하십시오. 이 조항이 아예 빠져 있거나, 개발사가 저작권을 보유하고 발주사에 사용권만 부여하는 형태로 되어 있는 경우가 적지 않습니다. 후자라면 코드를 받아도 다음 개발사가 자유롭게 수정하고 배포할 수 있는지가 불확실해집니다. 제3자 라이브러리나 상용 솔루션이 포함된 경우, 그 라이선스가 발주사 명의로 이전 가능한지도 함께 확인하십시오.

6. 다음 개발사에게 넘길 인수 패키지를 어떻게 확보할 것인지

교체는 해지로 끝나지 않고 인수로 끝납니다. 통보 전에 인수 패키지 목록을 문서로 만들어 두시고, 해지 합의서에 그 목록과 인계 기한을 명시하십시오. 최소 구성은 다음과 같습니다.

• 전체 소스코드와 커밋 이력
• 데이터베이스 스키마와 운영 데이터 백업
• 서버·도메인·클라우드·외부 API 계정의 명의 이전
• 기획서, API 명세, 배포 절차서
• 미완료 기능 목록과 알려진 결함 목록
• 인계 후 일정 기간의 질의 응답 창구

마지막 항목이 실무에서 가장 자주 빠집니다. 인계 직후에는 반드시 질문이 생기는데, 그 시점에 연락이 닿지 않으면 문서가 있어도 시간이 걸립니다.

교체할 곳을 고르는 기준

여기까지가 실무 준비입니다. 그런데 준비를 다 하고 새 업체와 계약해도 6개월 뒤에 같은 자리에 서 있는 경우가 있습니다. 회사 이름만 바뀌고 구조가 그대로였기 때문입니다.

앞에서 정리한 세 가지 — 문서화되지 않은 요구사항, 검증 불가능한 진행률, 개발사 안에만 있는 산출물 — 는 특정 회사의 문제가 아니라 발주 방식의 문제입니다. 그래서 후보를 볼 때 확인해야 하는 것은 포트폴리오의 화려함이 아니라, 이 세 가지가 누구의 책임으로 정의되어 있는지입니다. 현실적으로 선택지는 세 가지입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

국내 개발사는 한국어로 소통하고 요구사항 정의도 맡아 주지만 단가가 높습니다. 예산이 맞지 않으면 인력 등급이나 투입 기간을 줄이게 되고, 그 지점에서 앞의 구조가 다시 생깁니다. 방금 겪은 프로젝트가 국내 개발사였다면, 비슷한 조건으로 다시 계약하는 것은 같은 구조를 한 번 더 시도하는 선택입니다.

해외 팀에 직접 발주하는 방식은 단가가 분명히 낮습니다. 문제는 표에서 굵게 표시한 두 칸입니다. 요구사항을 정의하는 책임과 매일의 조율 부담이 발주사 본인에게 넘어옵니다. 사내에 개발 조직과 PM이 있는 회사라면 이 방식이 가장 저렴합니다. 그런데 지금 개발사 교체를 검토하는 회사는 대부분 사내에 그 역할을 할 사람이 없습니다. 없는 상태에서 영어와 시차를 끼고 팀을 관리하면, 낮은 단가로 시작해도 재작업이 쌓여 총비용은 기대만큼 내려가지 않습니다. 견적의 1.5배가 되는 일은 드물지 않습니다. 항목별로 어떻게 벌어지는지는 IT 외주개발 비용 비교에 정리해 두었습니다.

남는 것은 세 번째 열입니다. 개발 단가는 해외 직접 발주와 같은 수준이고, 요구사항 정의와 일정 관리와 검수는 한국인 PM이 책임집니다. 발주사는 한국어로 한 사람과만 이야기합니다. 특별히 새로운 방식은 아닙니다. 국내 개발사가 담당했던 관리 역할과 해외 팀의 단가를 분리해 결합한 것이고, 프로젝트를 멈추게 한 세 가지 항목의 책임 소재를 계약 단계에서 확정해 두는 방식입니다. 디비컨설팅의 IT 아웃소싱이 이 구조로 운영됩니다.

디비컨설팅이 이관을 진행하는 방식

1. 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화하는 단계입니다. 이관 프로젝트에서는 여기에 하나가 더 붙습니다. 기존 산출물의 상태를 진단합니다. 소스코드와 데이터베이스 구조를 열어 보고, 이어받을 범위와 다시 만들어야 하는 범위를 나눠 문서로 정리합니다. 이 단계에서 확정된 문서가 이후의 재작업을 대부분 없앱니다. 견적이 이 단계 이후에 확정되는 이유도 같습니다.

2. 개발팀 구성

진단 결과에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할과 인력 등급을 확정하고 한국인 PM이 팀에 배정됩니다. 발주사는 이 PM을 통해서만 커뮤니케이션합니다. 글로벌 개발팀을 어떻게 검증하고 운영하는지는 인도 IT 아웃소싱의 진화에서 더 자세히 다뤘습니다.

3. 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 스프린트 단위로 동작하는 결과물이 테스트 환경에 올라가고, 발주사는 진행률 숫자가 아니라 실제 화면으로 확인합니다. 개발팀과의 일정 조율, 우선순위 정리, 이슈 처리는 PM이 맡습니다. 발주사 담당자가 조율에 하루를 쓰지 않습니다.

4. 테스트 및 배포

QA 프로세스를 거친 뒤 배포합니다. 이관 프로젝트에서는 신규 기능 테스트와 함께, 기존에 동작하던 기능이 그대로 동작하는지 확인하는 회귀 테스트가 특히 중요합니다. 배포 절차는 다른 사람이 그대로 따라 할 수 있는 형태로 문서화합니다.

5. 운영 및 유지보수

문서와 함께 인계하고 장기 지원을 이어갑니다. 소스코드, API 명세, 데이터베이스 스키마, 배포 절차서가 발주사에 남습니다. 분명히 말씀드리면, 지금의 문제는 이 단계가 없었기 때문에 생겼습니다. 첫 번째 개발사가 문서 없이 코드만 들고 있었기 때문에 교체가 어려워졌고, 그 상태가 협상에서 그대로 불리하게 작용했습니다. 인계 문서는 다음 개발사를 위한 것이 아니라, 발주사가 언제든 선택할 수 있는 상태를 유지하기 위한 것입니다.

실제 구축 사례

• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트, 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 직방 — 호갱노노, 부동산 데이터 서비스
• 가천대학교 — 학사관리 시스템

산업군은 교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT에 걸쳐 있습니다. 도메인이 달라도 요구사항을 한국어로 확정하고 검수 기준을 먼저 정한 뒤 진행하는 방식은 동일하게 적용됩니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 조직이나 PM이 없어, 요구사항 정의부터 맡길 곳이 필요한 경우
• 진행 중인 프로젝트가 멈춰 있고, 기존 산출물 진단부터 시작해야 하는 경우
• 국내 개발사 견적이 예산을 넘지만 품질 기준은 낮추고 싶지 않은 경우
• 해외 팀 수준의 단가는 필요하지만 영어 커뮤니케이션과 시차 조율은 감당할 수 없는 경우
• 소스코드와 문서를 반드시 자사에 남겨야 하는 경우

이어받는 대상이 모바일 서비스라면 앱 개발 외주, 웹 서비스나 플랫폼이라면 웹 개발 외주 쪽 진행 방식을 함께 참고하시면 됩니다.

반대로, 권하지 않습니다

• 사내에 개발 조직과 PM이 이미 있고 단가만 낮추려는 경우 — 해외 팀에 직접 발주하시는 편이 더 저렴합니다.
• 남은 작업이 며칠 수준의 소규모 수정인 경우 — 팀을 구성하는 시간이 작업 시간보다 길어집니다.
• 요구사항을 끝까지 확정하지 않고 일단 시작하려는 경우 — 이 방식은 첫 번째 실패의 원인과 동일합니다. 저희와 하셔도 같은 결과가 나옵니다.
• 업체 선정 기준이 최저 단가 하나인 경우 — 그 기준에는 항상 더 낮은 곳이 있고, 지금 상황이 그 결과일 수 있습니다.

자주 묻는 질문

해외 개발팀인데 의사소통은 어떻게 됩니까?

발주사는 한국인 PM하고만 한국어로 소통합니다. 해외 개발팀과 직접 이야기하는 일은 없습니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임이며 회의도 한국 시간 기준으로 진행됩니다. 영어로 스펙을 다시 쓰거나 시차에 맞춰 새벽에 회의를 잡는 일은 발주사 쪽에서 발생하지 않습니다.

이관 비용은 어떻게 산정됩니까?

인력 등급별 단가와 투입 기간을 기준으로 산정하고, 기획·디자인·개발·QA·배포·유지보수를 항목별로 구분해 제시합니다. 이관 프로젝트는 기존 산출물 진단 결과에 따라 이어받는 범위가 달라지므로, 진단 이후에 범위와 금액이 확정됩니다. 진단 전 금액은 개략 견적이며, 확정 시 차이가 어디에서 발생했는지도 함께 설명드립니다.

기획서가 없는데 견적이 가능합니까?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 일정과 예산의 범위만 있으면 개략 견적을 드릴 수 있습니다. 멈춰 있는 프로젝트라면 기존 화면과 코드가 기획서 역할을 일부 대신하기도 합니다. 기획서를 만들어 오시는 것이 아니라, 기획서를 만드는 일부터 함께하는 것이 1단계입니다.

팀 규모를 조정할 수 있습니까?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중에도 조정할 수 있습니다. 이관 초기에는 진단과 정리에 인력을 집중하고 이후 개발 인력을 늘리는 형태로 구성할 수 있습니다.

소스코드 소유권은 누구에게 있습니까?

발주사에 귀속됩니다. 소스코드만이 아니라 API 명세, 데이터베이스 스키마, 배포 절차 문서까지 인계 대상에 포함합니다. 이 항목을 강조하는 이유는, 지금 개발사 교체가 어려워진 원인이 대부분 여기에 있기 때문입니다. 코드와 지식이 개발사 한쪽에만 있으면 발주사는 협상에서 선택권을 잃고, 남는 선택지는 계속 끌려가는 것뿐입니다. 소유권과 인계 문서를 계약 단계에서 확정해 두면, 다음에는 교체를 검토할 일이 생겨도 그것이 위기가 아니라 그냥 선택이 됩니다.

정리

개발사 교체는 회사를 바꾸는 일이 아니라 구조를 바꾸는 일이어야 합니다. 요구사항이 문서로 남는지, 진행률을 발주사가 직접 확인할 수 있는지, 소스코드와 문서가 발주사에 귀속되는지 — 이 세 가지가 계약서에 정해져 있지 않으면 다음 개발사에서도 같은 주간 보고를 받게 됩니다. 지금 비교해야 할 것은 후보들의 포트폴리오보다 이 세 가지의 책임 소재이고, 사내에 개발 조직이 없다면 그 책임을 한국어로 대신 지는 PM 층이 구조 안에 반드시 있어야 합니다.

내년 상반기 출시를 목표로 새 서비스를 만들기로 했습니다. 기획안은 대략 정리됐고 예산도 승인을 받았습니다. 그런데 다음 회의에서 결론을 내야 하는 안건이 하나 남아 있습니다. 개발자 채용 vs 외주, 어느 쪽으로 갈 것인가.

내부 의견은 대개 갈립니다. 한쪽은 “이번 기회에 개발 조직을 내재화하자”고 하고, 다른 한쪽은 “고정비가 한번 늘면 되돌릴 수 없다”고 합니다. 양쪽 다 틀린 말이 아니라서 회의는 길어지고, 결국 “일단 견적이나 몇 군데 받아보자”로 끝납니다.

이 결정이 어려운 진짜 이유는 비교 대상이 잘못 놓여 있기 때문입니다. 대부분의 회의에서는 개발자 한 명의 연봉과 외주 견적서 한 장을 나란히 놓고 비교합니다. 그러나 실제로 비교해야 하는 것은 서비스를 출시하고 최소 1년간 운영하는 데 필요한 전체 구조입니다. 이 글은 그 구조를 다섯 가지 항목으로 나눠 정리한 것입니다.

디비컨설팅은 100건이 넘는 웹·앱·플랫폼 프로젝트를 수행해 왔습니다. 삼성물산(홈닉), GS건설(엘리시안 리조트), 하나투어(하나오픈챗), 직방(호갱노노), LS일렉트릭(테크스퀘어), 교보생명, 가천대학교가 그 목록에 들어 있습니다. 그 과정에서 “뽑을까, 맡길까”를 두고 몇 달을 보낸 회사를 반복해서 만났고, 각 선택이 6개월 뒤에 어떤 형태로 돌아오는지도 반복해서 봤습니다. 아래는 그 관찰을 정리한 내용입니다.

채용과 외주를 비교할 때 대부분 빠뜨리는 5가지

1. 개발자 한 명은 팀이 아닙니다

서비스 하나를 출시하려면 최소한 서버(백엔드), 사용자가 보는 화면(웹 프론트엔드 또는 모바일 앱), 디자인, 품질 검증(QA), 그리고 이 전부를 순서대로 엮는 사람이 필요합니다. 시니어 개발자 한 명을 뽑아도 나머지 역할은 그대로 남습니다.

그러면 세 가지 중 하나가 일어납니다. 직군별로 추가 채용을 이어가거나, 빈 역할만 부분 외주로 붙이거나, 대표나 기획 담당자가 사실상 PM 역할을 겸하게 됩니다. 현실에서 가장 흔한 것은 세 번째이고, 총비용 관점에서 가장 비싼 것도 세 번째입니다. 본업에 써야 할 시간이 그대로 빠져나가는데, 그 시간은 어떤 회계 항목에도 잡히지 않기 때문입니다.

2. 연봉은 인건비의 일부일 뿐입니다

채용을 검토할 때 계산에 들어가는 숫자는 보통 연봉 하나입니다. 실제로 나가는 항목은 그보다 넓습니다.

• 4대보험 사업자 부담분과 퇴직급여 충당
• 채용 수수료, 또는 채용에 들어가는 내부 담당자의 시간
• 장비, 개발 도구·클라우드 라이선스 등 1인당 고정 지출
• 입사 후 실제 산출물이 나오기 시작할 때까지의 온보딩 기간
• 퇴사 시 다시 발생하는 채용 비용과 공백 기간

구체적인 금액은 직군, 연차, 회사 규모, 지역에 따라 크게 달라지므로 여기에 숫자를 적지 않겠습니다. 어디선가 본 평균값을 옮겨 적는 것보다, 각자의 조건으로 직접 계산해 보시는 편이 정확합니다. 다만 방향은 분명합니다. 채용의 총비용은 연봉표에 적힌 숫자보다 항상 큽니다. 그리고 이 항목들은 서비스가 출시되든 안 되든 매달 나갑니다.

3. 팀이 갖춰질 때까지 걸리는 시간

채용 결정에서 자주 빠지는 항목이 시간입니다. 공고를 올리고, 서류를 보고, 면접을 보고, 처우를 협의하고, 전 직장 인수인계를 기다리고, 입사 후 우리 서비스의 맥락을 익히는 데까지 — 한 명당 이 과정이 반복됩니다. 직군이 네다섯 개면 순차적으로 다시 반복됩니다.

그동안 시장은 기다려 주지 않습니다. 출시 시점을 기준으로 역산했을 때 채용만으로 팀이 제때 갖춰지지 않는다면, 그 계획은 이미 성립하지 않는 것입니다. 참고로 디비컨설팅은 프로젝트 성격에 맞는 전담팀을 2~4주 안에 구성합니다. 개발 착수 시점을 몇 달 앞당길 수 있는지가 실제로는 단가보다 큰 차이를 만드는 경우가 많습니다. 단계별 소요 시간은 앱 개발 기간이 계획보다 길어지는 이유에 정리해 두었습니다.

4. 물량이 줄었을 때 되돌릴 수 있는가

개발 물량은 일정하지 않습니다. 1차 출시 직전이 가장 많고, 출시 후 안정화 기간을 지나면 눈에 띄게 줄어듭니다. 서비스가 예상만큼 크지 않았을 때도 마찬가지입니다.

외주 계약은 프로젝트가 끝나면 종료되거나 규모를 줄일 수 있습니다. 고용은 그렇지 않습니다. 채용으로 갖춘 팀은 물량과 무관하게 고정비로 남습니다. 반대 방향의 위험도 있습니다. 어렵게 뽑은 개발자가 1년 안에 퇴사하면 그 사람 머릿속에만 있던 설계 의도가 함께 나갑니다. 문서가 남아 있지 않으면 회사에 남는 것은 코드뿐이고, 다음 사람은 그 코드를 해석하는 데만 몇 주를 씁니다.

5. 출시 이후를 누가 맡는가

출시는 끝이 아니라 시작입니다. OS 버전이 올라가고, 결제·소셜로그인·지도 같은 외부 연동의 정책이 바뀌고, 보안 패치가 필요해지고, 사용자 문의를 반영한 개선 요청이 쌓입니다. 이 부분을 누가 맡을지 정해두지 않으면 출시 3개월 뒤에 지금과 똑같은 회의를 다시 하게 됩니다. 어떤 항목에서 비용이 발생하는지는 앱 유지보수 비용의 실제 구조에서 항목별로 정리했습니다.

외주를 택한다고 자동으로 싸지지는 않습니다

여기까지만 읽으면 외주가 답처럼 보일 수 있지만, 그렇지 않습니다. 외주에서 비용이 새는 지점은 단가가 아니라 재작업입니다. 요구사항이 정리되지 않은 상태로 발주하면 개발사는 자기 해석대로 만들고, 검수 단계에서 “이게 아닌데”가 나오고, 그 차이를 메우는 비용은 대부분 발주사가 부담합니다.

그래서 외주의 성패는 개발사의 기술력보다 요구사항을 누가 책임지고 정의하느냐에서 갈립니다. 발주 전에 어디까지 정리해 두어야 하는지는 요구사항 정의서, 어디까지 써야 할까에서, 견적이 실제 정산액과 벌어지는 지점은 IT 외주개발 비용이 견적보다 더 나오는 구조에서 다뤘습니다.

실제 선택지는 두 개가 아니라 네 개입니다

“채용이냐 외주냐”라는 이분법이 결론을 막습니다. 실무에서 놓인 선택지는 네 개이고, 각각 부담하는 항목이 다릅니다.

	직접 채용	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	높음	낮음	낮음
팀 구성까지 걸리는 시간	매우 김(직군별 순차 채용)	보통	김	2~4주
요구사항 정의 책임	발주사 본인	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	한국어	영어	한국어
담당자 투입 시간	매우 많음	보통	매우 많음	적음
물량 감소 시 조정	어려움(고정비)	계약 단위 종료	어려움	가능
재작업 리스크	보통	낮음	높음	낮음
총비용 관점	높고 고정	비쌈	기대만큼 안 싸다	실질 절감

이 표에서 실제로 결정을 가르는 행은 “개발 단가”가 아니라 “요구사항 정의 책임”과 “담당자 투입 시간”입니다. 두 행이 굵게 표시된 열, 즉 직접 채용과 해외 직접 발주는 사내에 개발 프로젝트를 이끌어 본 사람이 있어야 성립합니다. 그런 사람이 없다면 단가가 아무리 낮아도 그 열은 선택지가 아닙니다. 실제로 저희가 만난 실패 사례의 상당수는 기술 문제가 아니라 이 자리가 비어 있었던 경우였습니다.

반대로 회사가 이미 개발 조직을 운영하고 있고, 만들려는 서비스가 회사의 핵심 제품이며, 앞으로도 계속 고도화할 계획이라면 직접 채용이 맞습니다. 그 경우 이 글의 나머지는 참고 자료 이상은 아닙니다.

디비컨설팅이 이 구조를 통제하는 방식

디비컨설팅의 IT 아웃소싱 모델은 한국인 PM이 프로젝트를 책임지고, 검증된 글로벌 개발팀이 실제 개발을 맡는 구조입니다. 고객사는 한국인 PM하고만 한국어로 소통합니다. 진행은 다섯 단계로 나뉩니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 이후 발생할 재작업의 대부분이 이 단계에서 제거됩니다.
2. 개발팀 구성 — 프로젝트 성격에 맞는 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진척 상황을 투명하게 공유합니다. 고객사 담당자가 하루를 조율에 쓰지 않는 것이 이 단계의 목표입니다.
4. 테스트 및 배포 — QA 프로세스를 거친 뒤 배포합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 운영을 지원합니다.

이 구조에서 요구사항 정의와 일정 관리의 책임은 한국인 PM에게 있습니다. 즉 앞의 표에서 “발주사 본인”이라고 적힌 칸을 회사가 떠안지 않습니다. 국내 채용 대비 평균 40~60%의 비용 절감이 나오는 것도 단가만의 결과가 아니라, 재작업과 관리 시간이 줄어든 결과입니다.

실제로 만든 것들

구조에 대한 설명보다 실제 결과물이 판단에 도움이 됩니다.

• 삼성물산 – 홈닉 · 주거 플랫폼 앱
• GS건설 – 엘리시안 리조트 · 리조트 웹·앱 통합 구축
• 하나투어 – 하나오픈챗 · 여행 상담 채팅 서비스
• 직방 – 호갱노노 · 부동산 데이터 서비스
• LS일렉트릭 – 테크스퀘어 · 산업 B2B 거래 플랫폼
• 교보생명 · 사내벤처(글펍) 커뮤니티 서비스
• 가천대학교 · 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 · 프라임 오피스 빌딩 관리 시스템

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 산업별 사례는 포트폴리오에서 확인하실 수 있고, 만들려는 것이 앱인지 웹 서비스인지에 따라 앱 개발 외주 또는 웹 개발 외주 페이지를 참고하시면 됩니다.

이런 기업에 적합합니다

• 사내에 개발 조직이 없거나, 있어도 신규 서비스를 맡길 여력이 없는 기업
• 출시 시점이 정해져 있어 순차 채용으로는 일정을 맞출 수 없는 기업
• 1차 출시 이후 개발 물량이 줄어들 가능성이 있어 고정비 증가가 부담스러운 기업
• 해외 개발 리소스의 단가는 필요하지만, 영어로 요구사항을 정의하고 관리할 인력은 없는 기업
• 기존 외주에서 재작업과 일정 지연을 겪고 원인을 구조에서 찾고 있는 기업

반대로 권하지 않습니다

• 만들려는 서비스가 회사의 핵심 제품이고, 앞으로 수년간 계속 고도화할 계획이라면 — 장기적으로는 내재화가 맞습니다. 다만 1차 버전만 외부에서 만들고 이후 내재화하는 방식은 가능합니다.
• 이미 잘 돌아가는 개발 조직이 있고 단순히 인력 한두 명이 부족한 상황이라면 — 채용이나 인력 단위 계약이 더 단순합니다.
• 무엇을 만들지가 아직 정해지지 않았다면 — 개발보다 기획 정리가 먼저입니다. 이 단계라면 상담만 받아보셔도 됩니다.
• 가장 낮은 견적 하나만 보고 결정하실 계획이라면 — 그 기준으로는 저희가 선택되지 않을 가능성이 높고, 재작업까지 포함한 총비용에서도 서로에게 좋지 않습니다.

자주 묻는 질문

해외 개발팀이면 의사소통은 어떻게 하나요?

고객사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 개발팀과 영어로 직접 대화하실 일은 없습니다. 협업 시 실제로 자주 발생하는 문제와 대응 방식은 인도 개발자 채용 가이드에 정리해 두었습니다.

비용은 어떻게 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 항목에서 금액이 발생하는지 확인하실 수 있습니다. 총액 한 줄짜리 견적은 나중에 재작업 분쟁의 원인이 됩니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산의 범위만 있으면 개략 견적을 드릴 수 있습니다. 기획서를 완성한 뒤에 문의하려다 몇 달을 보내는 경우가 많은데, 그 정리 자체를 함께 하는 편이 빠릅니다.

시작한 뒤에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 앞의 표에서 “물량 감소 시 조정” 항목이 채용과 갈리는 지점이 이 부분입니다.

소스코드 소유권은 누구에게 있나요?

발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 이 조건은 계약서에 명시해 두시는 것이 좋습니다 — 개발사를 바꾸거나 이후 내재화할 때 실제로 회사에 남는 자산이 여기서 결정되기 때문입니다.

정리

개발자 채용 vs 외주는 연봉과 견적서를 나란히 놓고 답할 수 있는 질문이 아닙니다. 서비스를 출시하고 1년간 운영하는 데 필요한 역할이 몇 개인지, 그 팀이 언제 갖춰지는지, 물량이 줄었을 때 되돌릴 수 있는지, 그리고 요구사항을 정의하고 일정을 책임질 사람이 회사 안에 있는지 — 이 네 가지가 실제 판단 기준입니다. 마지막 항목의 답이 “없다”라면 직접 채용도 해외 직접 발주도 성립하지 않고, 한국인 PM이 그 자리를 맡는 구조가 남습니다. 디비컨설팅이 하는 일이 정확히 그것입니다.

개발 외주 계약서를 처음 받아 보면 대부분 금액부터 확인합니다. 총 계약금이 예산 안에 들어오는지, 착수금 비율은 어느 정도인지, 잔금은 언제 나가는지. 숫자에 문제가 없으면 서명합니다.

그런데 실제 분쟁은 거의 그 숫자에서 시작되지 않습니다. 개발이 끝났다고 말하는 개발사와 아직 끝나지 않았다고 말하는 발주사가 같은 계약서를 놓고 정반대로 해석할 때 시작됩니다. 계약서에 “요구사항에 따라 개발한다”는 문장은 분명히 있는데, 그 요구사항이 무엇인지는 계약서 어디에도 정의되어 있지 않기 때문입니다.

디비컨설팅은 삼성물산, GS건설, 하나투어, 직방, LS일렉트릭, 교보생명 등과 100건 이상의 웹·앱·플랫폼 프로젝트를 수행해 왔습니다. 그 과정에서 반복해서 확인한 것이 있습니다. 프로젝트가 무너지는 지점은 대부분 계약서에 적혀 있던 조항이 아니라, 계약서에 비어 있던 칸이었습니다.

이 글은 개발 외주 계약서에 반드시 들어가야 할 7가지 조항과, 그 조항들이 왜 계약서만으로는 지켜지지 않는지를 정리한 것입니다.

금액란은 분쟁을 막지 못합니다

모든 분쟁은 “완료”의 정의에서 시작됩니다

개발사는 기능 목록에 적힌 항목이 동작하면 완료라고 봅니다. 발주사는 그 기능을 실제 업무에서 문제없이 쓸 수 있어야 완료라고 봅니다. 두 입장 모두 계약서 위반이 아닙니다. 계약서가 어느 쪽도 정의하지 않았기 때문입니다.

이 상태에서 일정이 밀리기 시작하면 협상 카드는 하나뿐입니다. 잔금입니다. 발주사는 잔금을 붙잡고, 개발사는 인력을 뺍니다. 프로젝트는 그때부터 완성이 아니라 종료를 향해 갑니다.

계약서가 대체로 침묵하는 네 가지 질문

표준 계약서 양식을 그대로 쓴 경우, 다음 네 가지는 거의 비어 있습니다.

• 무엇을 충족해야 검수가 통과되는가
• 요구사항이 바뀌었을 때 추가 비용은 어떤 기준으로 산정되는가
• 납품물에 코드 외에 무엇이 포함되는가
• 출시 후 발견된 문제는 하자인가 새 작업인가

네 가지 모두 개발이 시작되기 전에는 사소해 보이고, 끝날 무렵에는 프로젝트 전체를 좌우합니다. IT 외주 프로젝트가 납기 후 분쟁으로 끝나는 구조를 따로 정리해 둔 글도 함께 참고하시면 좋습니다.

서명 전에 확인할 7가지 조항

1. 검수 기준 — 무엇을 충족해야 완료인가

가장 중요한 조항입니다. “발주사의 검수 후 인수한다”는 문장만으로는 부족합니다. 검수 항목이 문서로 첨부되어야 하고, 그 문서가 계약서의 일부라는 문장이 있어야 합니다.

검수 기간도 명시해야 합니다. 기간이 없으면 발주사는 무한정 검수할 수 있고, 개발사는 무한정 대기해야 합니다. 반대로 “납품 후 7일 내 이의가 없으면 자동 인수” 같은 조항이 들어 있으면, 내부 검토가 늦어지는 것만으로 검수권을 잃습니다. 조항을 읽을 때 이 자동 인수 문구가 있는지 반드시 확인하십시오.

2. 요구사항 변경 절차 — 추가 비용이 생기는 기준

개발 중 요구사항은 바뀝니다. 문제는 바뀌는 것이 아니라, 무엇이 “변경”이고 무엇이 “원래 포함”인지 판단할 기준이 없다는 것입니다.

기준선이 되는 요구사항 정의서가 계약서에 첨부되어 있어야 이 판단이 가능해집니다. 정의서 없이 시작한 프로젝트에서는 모든 요청이 협상 대상이 되고, 그 협상에 발주사 담당자의 시간이 통째로 들어갑니다.

변경 절차 조항에는 최소한 이 세 가지가 있어야 합니다. 변경 요청을 누가 접수하는가, 공수 산정 결과를 며칠 안에 회신하는가, 발주사가 승인하기 전에는 착수하지 않는다는 확인입니다.

3. 산출물 목록 — 코드 외에 무엇을 받는가

코드만 받으면 다음 개발사가 그 코드를 해석하는 데 다시 비용이 듭니다. 계약서 산출물 목록에 다음 항목이 들어가 있는지 확인하십시오.

• API 명세서
• 데이터베이스 스키마 및 ERD
• 서버 구성도와 배포 절차 문서
• 외부 연동 서비스 계정과 키의 이관 목록
• 관리자 기능 사용 안내

특히 마지막 두 항목이 자주 빠집니다. 결제사, 문자 발송, 지도, 푸시 같은 외부 서비스가 개발사 계정으로 붙어 있으면, 계약이 끝나도 서비스의 일부는 개발사 손에 남습니다.

4. 소스코드와 지식재산권 귀속

“소스코드는 발주사에 귀속된다”는 한 문장이 있는지 확인하십시오. 없다면 넣어야 합니다. 대금을 완납해도 저작권이 자동으로 넘어오지는 않습니다.

개발사가 자체 보유한 공통 모듈이나 프레임워크를 쓰는 경우가 있는데, 그 부분은 소유권이 아니라 사용권으로 정리되는 것이 일반적입니다. 그렇다면 사용 범위와 기간에 제한이 있는지, 이후 다른 개발사가 유지보수할 때 문제가 되지 않는지를 문서로 확인해야 합니다.

디비컨설팅의 계약 기준은 단순합니다. 소스코드는 발주사 귀속이며, API 명세·DB 스키마·배포 절차 문서까지 함께 인계합니다. 다음 파트너가 저희가 아니어도 이어받을 수 있는 상태로 넘기는 것이 원칙입니다.

5. 하자보수 범위와 기간

하자보수 기간만 적고 범위를 적지 않는 계약서가 많습니다. 그러면 출시 후 발견된 모든 문제가 “이건 하자입니다” 대 “이건 추가 개발입니다”의 대립으로 갑니다.

범위를 가르는 기준은 검수 기준 문서입니다. 검수 항목에 있었는데 동작하지 않으면 하자, 검수 항목에 없던 것을 새로 요구하면 추가 개발입니다. 1번 조항이 5번 조항을 지탱하는 구조입니다.

또 하나, 하자보수와 운영 유지보수는 다릅니다. OS 업데이트 대응이나 외부 라이브러리 정책 변경 대응은 하자가 아니라 별도 계약 영역입니다. 이 부분은 앱 유지보수 비용이 출시 후에 발생하는 구조에서 더 자세히 다뤘습니다.

6. 투입 인력의 등급과 교체 조건

견적서에는 시니어 개발자 기준 단가가 적혀 있는데 실제로는 다른 인력이 들어오는 경우가 있습니다. 계약서에 투입 인력의 등급과 인원, 투입 기간이 명시되어 있어야 확인이 가능합니다.

교체 조건도 필요합니다. 개발사 사정으로 인력이 바뀔 때 동급 이상으로 대체한다는 조항, 그리고 인수인계 기간을 별도 일정으로 잡는다는 조항입니다. 인력 교체 자체보다 인수인계 없는 교체가 일정을 무너뜨립니다.

7. 지연 책임 — 누구의 지연인가

지연 배상 조항은 대부분 개발사의 지연만 다룹니다. 그런데 실제 프로젝트에서 일정이 밀리는 흔한 원인 중 하나는 발주사 측의 회신 지연입니다. 디자인 확정, 콘텐츠 전달, 검수 회신이 늦어지면 개발도 함께 멈춥니다.

양방향으로 쓰인 조항이 결과적으로 발주사에게 유리합니다. 발주사 귀책 사유가 정의되어 있으면, 개발사가 “고객사 때문에 늦었다”고 사후에 주장할 여지가 사라지기 때문입니다. 책임 소재가 애매한 계약서일수록 분쟁에서 불리한 쪽은 문서를 덜 남긴 쪽입니다.

그런데 이 조항들은 계약서만으로 지켜지지 않습니다

7가지를 모두 넣어도 한 가지 문제가 남습니다. 검수 기준과 요구사항 정의서를 누가 쓰느냐입니다.

이 문서는 발주사의 업무를 이해하면서 동시에 개발 공수를 판단할 수 있는 사람만 쓸 수 있습니다. 그런 사람이 조직 안에 없으면, 계약서의 1번과 2번 조항은 서명 시점에 이미 빈 껍데기입니다. 조항은 있는데 그 조항이 참조하는 문서가 없는 상태가 되기 때문입니다.

그래서 한국 기업이 개발 외주에서 실제로 마주하는 선택지는 이렇게 정리됩니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
검수 기준 작성	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외 개발사에 직접 발주하면 단가는 확실히 내려갑니다. 다만 계약서의 핵심 조항을 지탱하는 문서를 발주사가 직접, 영어로, 개발 공수까지 판단해 가며 써야 합니다. 사내에 개발 조직이 없는 회사에게 이 방식이 기대만큼 저렴해지지 않는 이유가 여기에 있습니다. 절감한 단가가 담당자의 시간과 재작업으로 돌아옵니다.

단가 차이가 총비용 차이로 이어지지 않는 구조는 IT 외주개발 비용이 견적을 넘어서는 지점에서 항목별로 정리해 두었습니다.

디비컨설팅이 계약 이전 단계에서 하는 일

IT 아웃소싱 프로젝트는 다음 5단계로 진행됩니다. 앞의 두 단계가 계약서의 조항을 실제로 작동하게 만드는 부분입니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요구사항을 한국어 문서로 정리합니다. 검수 기준과 변경 판단의 기준선이 여기서 만들어집니다. 이후 재작업의 대부분이 이 단계에서 제거됩니다.
2. 개발팀 구성 — 프로젝트에 맞춘 전담팀을 2~4주 안에 구성합니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 것이 목표입니다.
4. 테스트 및 배포 — QA 프로세스를 거쳐 릴리스합니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 운영을 지원합니다.

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수는 PM의 책임입니다. 계약서에 적힌 조항을 지탱하는 문서를 발주사가 직접 쓰지 않아도 되는 구조입니다.

이 구조로 만든 것들

• 삼성물산 — 홈닉, 주거 플랫폼 앱
• GS건설 — 엘리시안 리조트 웹·앱 통합 구축
• 하나투어 — 하나오픈챗, 여행 상담 채팅 서비스
• 직방 — 호갱노노, 부동산 데이터 서비스
• LS일렉트릭 — 테크스퀘어, 산업 B2B 거래 플랫폼
• 교보생명 — 사내벤처 글펍, 커뮤니티 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드 · 센트로폴리스 · 그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 와디즈 — 글로벌 플랫폼

100건 이상의 프로젝트, 50개 이상의 글로벌 파트너사, 고객 만족도 98%. 다른 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 조직이 없거나, 있어도 신규 구축을 맡길 여력이 없는 기업
• 이전 외주에서 검수 단계까지 갔다가 분쟁으로 끝난 경험이 있는 기업
• 국내 견적이 예산을 넘는데, 해외 직접 발주는 관리할 사람이 없는 기업
• 웹 개발 외주 또는 앱 개발 외주를 3개월 이상 규모로 검토 중인 기업

반대로 권하지 않습니다

• 사내에 기획자와 개발 리드가 이미 있는 기업. 요구사항 정의를 직접 하실 수 있다면 해외 인력을 직접 계약하는 편이 더 쌉니다. 저희 구조의 가치가 그 부분에 있기 때문입니다.
• 2~3주 안에 결과물이 필요한 프로젝트. 전담팀 구성에만 2~4주가 걸립니다.
• 단순 홈페이지 제작. 페이지 몇 개의 브로슈어형 사이트라면 저희 구조는 과합니다. 판단 기준은 홈페이지 제작 비용이 업체마다 갈리는 이유에 정리해 두었습니다.
• 가장 낮은 견적이 기준인 발주. 검수 기준과 문서 인계를 계약에 넣으면 견적은 올라갑니다.

자주 묻는 질문

소스코드 소유권은 어떻게 되나요?

발주사 귀속입니다. API 명세서, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이후 유지보수를 다른 회사가 맡아도 이어받을 수 있는 상태로 넘기는 것을 기준으로 삼습니다.

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 검수가 모두 PM의 책임 범위입니다. 개발팀과의 영어 소통은 PM이 담당하며, 발주사가 부담하지 않습니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 알려주시면 개략 견적을 드립니다. 상세 요구사항 정의서는 계약 전 상담 단계에서 함께 만듭니다.

비용은 어떤 기준으로 산정되나요?

등급별 단가에 투입 기간을 곱하는 방식입니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 항목에서 비용이 발생하는지 확인하실 수 있습니다.

진행 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고 진행 중 조정도 가능합니다. 조정 절차는 계약서의 변경 조항에 반영합니다.

정리

개발 외주 계약서에서 분쟁을 가르는 것은 금액란이 아니라 검수 기준, 변경 절차, 산출물 목록, 소스코드 귀속, 하자보수 범위, 인력 교체 조건, 지연 책임 일곱 칸입니다. 그리고 이 조항들은 그것이 참조하는 문서 — 요구사항 정의서와 검수 기준서 — 를 누군가 실제로 써야만 작동합니다. 그 문서를 발주사가 직접 쓸 수 없다면, 계약서를 아무리 잘 써도 서명 시점에 이미 절반은 비어 있는 셈입니다. 외주 파트너를 고를 때 인원수보다 먼저 봐야 할 것이 그 문서를 누가 책임지는가인 이유입니다.