구축 끝나고 운영으로 넘길 때, 어디서 다툼이 날까요 | 5가지

먼저 짧게 답부터 드릴게요. 구축이 끝나고 운영으로 넘어갈 때 다툼은 대개 다섯 곳에서 나요. 검수 때 남은 결함은 누가 고치나, 하자보수 1년은 언제부터 세나, 운영 문서는 납품물인가, 같이 돌리는 기간의 비용은 누가 내나, 넘겨받은 직후 장애는 누구 책임인가예요. 다섯 곳 모두 계약서에 “인수인계한다” 한 줄만 있을 때 생겨요. 직접 만들고 운영해 본 개발사 기준으로, 미리 적어 둘 문장까지 정리했어요.

“검수 확인서에 도장 찍으셨잖아요. 그 뒤로 들어온 건 유지보수 요청이에요.”

구축이 끝나고 두세 달쯤 지나 자주 듣는 말이에요. 발주자는 처음부터 있던 문제라고 보고, 개발사는 검수가 끝났으니 새 요청이라고 봐요. 둘 다 틀린 말은 아닌데, 계약서에 기준이 없으니 정할 방법이 없어요.

구축(SI)과 운영(SM)을 어떻게 나눠 계약하는지는 SI와 SM은 어떻게 다를까요에서, 운영으로 넘어갈 때가 됐는지 알아보는 신호는 구축이 끝나면 언제 운영(SM)으로 넘어갈까요에서 다뤘어요. 이 글은 그 사이, 넘기는 순간에 생기는 다툼만 봐요.

---

1. 구축은 끝났는데 왜 인수인계에서 다툼이 날까요

계약서가 ‘만드는 일’은 자세히 적고 ‘넘기는 일’은 한 줄로 끝내기 때문이에요. 기능 목록과 일정은 몇 장씩 쓰면서, 인수인계는 “산출물 일체를 인계한다” 정도로 끝나는 경우가 많아요. 그 한 줄이 무엇을 뜻하는지는 문제가 생긴 뒤에야 따지게 돼요.

개발외주비용을 따질 때도 마찬가지예요. 총액은 비슷한데 한 견적엔 인수인계 지원이 들어 있고 다른 견적엔 없다면, 운영으로 넘어가는 첫 달에 차이가 드러나요.

자사 실무 기준 예시 — 인수인계에서 다툼이 나는 다섯 곳

다툼 지점	이렇게 말이 엇갈려요	계약서에 미리 적을 것
① 남은 결함	”검수 끝났으니 유지보수” vs “검수 때 이미 있던 문제”	검수 확인서에 붙이는 미결 결함 목록과 처리 기한
② 하자보수 시작일	”오픈한 날부터” vs “검수 끝난 날부터”	하자보수 시작일을 날짜로
③ 운영 문서	”견적에 문서 작성은 없었어요” vs “당연히 주는 줄”	운영 인수 산출물 목록과 확인 방법
④ 병행 운영 비용	”인수인계도 일이라 별도예요” vs “구축에 포함된 줄”	인수인계 지원 기간·횟수·담당자
⑤ 인수 직후 장애	”넘겨받은 뒤 바꾼 탓” vs “원래 결함”	넘기는 날의 버전 기록과 변경 기록

(자사 실무 기준 예시예요. 특정 고객사 사례가 아니에요.)

2. 검수 때 남은 결함은 누가, 언제까지 고치나요

검수 확인서에 미결 결함 목록을 붙이고, 그 목록은 구축팀이 기한 안에 고친다고 적어 두면 다툼이 사라져요.

실무에선 결함이 하나도 없는 상태로 검수가 끝나는 일이 드물어요. 오픈 일정 때문에 “사소한 건 오픈 뒤에 고치자”며 서명하는 경우가 많죠. 문제는 그 “사소한 것”의 목록이 어디에도 없을 때예요. 두 달 뒤 같은 증상이 신고되면 검수 때 있던 결함인지 새로 생긴 문제인지 가릴 근거가 없어요.

그래서 서명할 때 세 가지를 같이 남겨요.

1. 미결 결함 목록 — 번호, 증상, 심각도
2. 처리 기한 — 목록마다 언제까지 고칠지
3. 처리 주체 — 목록에 있는 건 구축 계약 범위로 처리한다는 문장

검수를 어떤 순서로 하고 결함 등급을 어떻게 나누는지는 개발 외주 검수, 어떻게 해야 분쟁이 줄어들까요에 정리해 뒀어요. 여기서 더할 건 하나예요. 목록에 없는 결함과 목록에 있는 결함은 처리 경로가 달라야 해요. 목록에 있는 건 구축의 남은 일이고, 없는 건 다음 장에서 볼 하자보수나 유지보수로 가요.

용어 정리 — 하자보수는 납품한 결과물이 약속한 기준에 못 미칠 때 개발사가 고쳐 주는 일이에요. 하자담보책임 기간은 그 책임을 지는 기간이고요. 실무에선 “무상 하자보수 1년”처럼 말하는데, 이 기간에 들어온 요청이라고 다 무상은 아니에요. 처음 약속한 기준에 못 미친 것만 하자예요.

3. 하자보수 1년은 오픈한 날부터 세나요, 검수한 날부터 세나요

계약서에 적은 날부터예요. 그래서 날짜로 적어 둬야 해요. 오픈일과 검수 완료일, 최종 산출물을 넘긴 날이 몇 주씩 벌어지는 일이 흔하거든요. 그 몇 주가 하자보수 끝자락에서 다툼이 돼요.

공식 기준은 이렇게 정해 두고 있어요.

공식 외부 기준 — 하자보수 기간과 책임 범위

기준	내용	적용 범위
민법 제667조	완성된 결과물에 하자가 있으면 발주자는 상당한 기간을 정해 보수를 청구하거나, 보수와 함께 또는 보수 대신 손해배상을 청구할 수 있어요	도급 계약 일반
민법 제670조	하자 보수·손해배상 청구와 계약 해제는 목적물을 인도받은 날부터 1년 안에 해야 해요. 인도가 필요 없으면 일이 끝난 날부터 세요	도급 계약 일반
소프트웨어 진흥법 제60조 제1항	사업을 끝낸 날, 즉 시험·검사를 거쳐 최종 산출물을 인도한 날부터 1년 안에 생긴 하자에 담보책임을 져요	국가기관 등이 발주한 SW 사업
소프트웨어 진흥법 제60조 제2항	발주자가 준 물품의 품질·규격이 기준에 못 미치거나, 발주자 지시대로 구축해서 생긴 하자는 책임이 없어요. 단, 부적절한 걸 알고도 알리지 않았다면 예외예요	국가기관 등이 발주한 SW 사업

(소프트웨어 진흥법은 2020년 6월 9일 전부개정, 2020년 12월 10일 시행 기준이에요. 실제 적용은 계약서와 법무 검토로 확인하세요.)

공공 사업은 법이 “최종 산출물을 인도한 날”이라고 정해 줘서 그나마 기준이 있어요. 민간 계약은 계약서가 기준이라 “검수 완료 후 1년” 같은 표현만으로는 부족해요. 검수가 언제 끝났는지부터 서로 다르게 기억하거든요. “하자보수 기간은 20○○년 ○월 ○일부터 1년”처럼 날짜를 박아 두세요.

하자와 유지보수의 경계를 어떻게 나누는지, SLA에 무엇을 넣는지는 유지보수 계약(SLA), 어디까지 넣어야 할까요에서 다뤘어요.

4. 운영 매뉴얼과 배포 절차도 납품물인가요

납품물 목록에 적혀 있을 때만 납품물이에요. 소스코드와 설계서는 대개 목록에 있지만, 운영팀이 실제로 매일 쓰는 문서는 빠지는 일이 많아요. “견적에 문서 작성은 없었다”는 말이 나오는 지점이에요.

운영으로 넘어간 뒤 필요한 건 코드보다 이런 것들이에요.

자사 실무 기준 예시 — 운영 인수 산출물과 확인 방법

산출물	담길 내용	받았는지 확인하는 법
배포 절차서	빌드·배포 순서, 되돌리는 방법	운영팀이 문서만 보고 스테이징에 한 번 배포해 봐요
운영 매뉴얼	정기 작업, 백업 주기, 로그 위치	백업 파일 하나를 실제로 복원해 봐요
장애 대응 문서	증상별 첫 조치, 연락 순서	지난 테스트 중 났던 장애 하나로 따라 해 봐요
환경·설정 목록	서버, 도메인, 외부 서비스, 설정값 위치	목록과 실제 콘솔을 한 줄씩 대조해요
변경 이력	주요 설계 변경과 그 이유	최근 변경 세 건의 이유를 담당자에게 물어봐요

(자사 실무 기준 예시예요. 프로젝트 규모에 따라 목록은 달라져요.)

확인 방법 열이 핵심이에요. 문서를 받았다는 것과 그 문서로 운영할 수 있다는 건 다른 얘기거든요. 계약서에는 “운영 인수 산출물 목록(별첨)을 납품하고, 발주사가 확인 절차를 마친 날을 인수 완료일로 본다”처럼 적어요. 계정과 명의를 누구 이름으로 둘지는 지금 개발사와 헤어져도 서비스가 돌까요에서 따로 다뤘어요.

CRM 개발 비용처럼 고객 데이터가 계속 쌓이는 시스템이라면 데이터 백업과 복원 절차를 목록 맨 위에 두세요. 데이터 수집 프로그램 외주 개발도 비슷해요. 수집에 쓰는 계정과 API 키가 누구 이름인지 목록에 없으면, 넘겨받은 다음 날 수집이 멈출 수 있어요.

운영사 Tip 저희는 인수인계 문서를 “구축팀이 없을 때 운영팀이 혼자 할 수 있나”로 확인해요. 문서를 넘긴 날, 구축팀 없이 운영팀만 배포를 한 번 해 보게 하는 거예요. 막히는 지점이 곧 빠진 문서예요.

5. 같이 돌리는 기간, 비용은 누가 내나요

정해 두지 않았다면 서로 상대가 낸다고 생각해요. 구축팀이 운영팀과 겹쳐 일하는 기간, 이른바 병행 운영 기간이에요. 구축사는 계약이 끝났으니 추가 일이라고 보고, 발주자는 인수인계까지가 구축이라고 봐요.

숫자로 보면 차이가 생각보다 커요.

가정 예시 — 병행 운영 기간을 2주로 잡았을 때와 정하지 않았을 때

항목	2주로 정함	정하지 않음
구축팀 참여	개발자 1명이 2주간 운영팀 문의에 답함	질문할 때마다 “확인 후 연락드릴게요”
운영팀이 겪는 일	첫 배포·첫 장애를 구축팀과 같이 처리	첫 장애를 혼자 맞음
비용	견적서에 이미 반영	건마다 추가 비용 협의

(설명을 위한 가정 예시예요. 적정 기간은 시스템 규모와 운영팀 경험에 따라 달라요.)

그래서 구축 견적 단계에서 “인수인계 지원 ○주, 교육 ○회, 담당자 ○○“를 적어 달라고 하세요. 앱 개발 외주 비용을 비교할 때도 이 항목이 있는 견적과 없는 견적을 같은 줄에 놓으면 안 돼요. SI 견적이 어떤 구조로 계산되는지는 SI 개발 비용, 도급 구조부터 봐야 하는 이유에 정리해 뒀어요.

6. 넘겨받은 직후 장애는 누구 책임인가요

넘기는 날의 상태를 기록해 두면 가릴 수 있어요. 운영팀이 넘겨받고 일주일 만에 장애가 나면, 구축 때부터 있던 결함인지 운영팀이 설정을 바꿔서 생긴 건지가 첫 다툼이에요. 기록이 없으면 양쪽 다 증명할 방법이 없어요.

넘기는 날 남길 것은 세 가지예요.

1. 버전 기록 — 넘긴 시점의 코드 버전(태그)과 배포된 버전이 같은지
2. 설정 백업 — 서버·데이터베이스 설정을 그날 기준으로 저장
3. 변경 기록 시작 — 그날부터 누가 무엇을 바꿨는지 남기기

이렇게 해 두면 장애가 났을 때 넘긴 버전으로 되돌려 재현해 볼 수 있어요. 넘긴 버전에서도 나면 구축 결함, 아니면 그 뒤 변경을 봐요.

공공 SW 사업에는 참고할 기준이 하나 더 있어요. 앞의 표에 적은 소프트웨어 진흥법 제60조 제2항이에요. 발주자가 지시한 방식대로 구축해서 생긴 하자는 개발사 책임이 아니에요. 다만 개발사가 그 지시가 적절하지 않다는 걸 알고도 알리지 않았다면 책임이 남아요. 민간 계약에도 이 구조를 빌려 쓸 만해요. 구축 중에 “이렇게 하면 운영에서 문제가 될 수 있다”고 알린 내용을 회의록이나 메일로 남겨 두는 거예요.

7. 계약서에는 어떤 문장으로 적어 두면 될까요

다섯 곳마다 한 문장씩이면 충분해요. 길게 쓸수록 해석이 갈리니 날짜와 목록으로 적어요.

자사 실무 기준 예시 — 인수인계 조항에 넣을 문장 5가지

1. 남은 결함 — 검수 확인서에 첨부한 미결 결함 목록은 구축 계약 범위로 보고, 각 항목에 적힌 기한까지 처리한다.
2. 하자보수 시작일 — 하자보수 기간은 20○○년 ○월 ○일부터 1년으로 한다.
3. 운영 문서 — 운영 인수 산출물 목록(별첨)을 납품하고, 발주사가 확인 절차를 마친 날을 인수 완료일로 본다.
4. 병행 운영 — 인수 완료일 전후 ○주 동안 구축사 담당자 ○명이 운영팀 문의에 응하며, 이 비용은 구축 대금에 포함한다.
5. 인수 직후 장애 — 인수 완료일의 코드 버전과 설정을 양측이 확인해 보관하고, 장애 원인은 이 기준으로 가린다.

(자사 실무 기준 예시 문구예요. 실제 계약서는 법무 검토를 거쳐 정하세요.)

흔한 실수 “산출물 일체를 인계한다” 한 줄로 끝내는 거예요. ‘일체’에 무엇이 들어가는지 양쪽 생각이 달라서, 결국 목록을 새로 만들며 다투게 돼요. 다른 하나는 유지보수 업체를 따로 정해 놓고 구축사와 운영사가 한 자리에 앉는 날을 잡지 않는 거예요. 두 회사가 직접 만나지 않으면 문서에 없는 사정은 전해지지 않아요. 운영 중에 업체를 바꿀 때 무엇부터 넘겨받는지는 유지보수 업체를 바꿀 때, 무엇부터 넘겨받아야 할까요에 순서대로 적어 뒀어요.

8. 운영까지 해 본 개발사는 인수인계를 어떻게 볼까요

저희는 인수인계 문서에서 “왜 이렇게 바뀌었나”를 가장 먼저 봐요.

롯데백화점 수원 푸드홀 실시간 혼잡도 시스템(2024년 5월 오픈)을 만들 때, 관리자 페이지에서 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 처음 JavaFX로 만든 부분을 C#으로 다시 구현해서 해결했죠. 이런 결정은 코드만 보면 이유가 안 보여요. 넘겨받은 사람이 이유를 모르면 “원래 방식으로 돌려 보자”는 같은 시도를 되풀이하게 돼요. 납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각하는 이유예요.

그래서 저희는 변경 이력을 인수인계 산출물에 꼭 넣고, 운영팀이 구축팀 없이 배포 한 번을 해 보는 날을 일정에 미리 잡아요. 그날 막히는 곳이 인수인계에서 빠진 곳이에요.

구축 계약을 앞두고 인수인계 조항을 어떻게 적어야 할지 막막하다면, 아직 운영 방식이 정해지지 않았어도 괜찮아요. 넘기는 날 무엇을 남길지부터 같이 정리해 볼 수 있어요. 저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해 온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 인수인계 조항, 넘기는 날 기준으로 같이 적어 봐요 →

9. 자주 묻는 질문 (FAQ)

하자보수 1년은 오픈한 날부터 세나요, 검수한 날부터 세나요?

계약서에 적힌 날이 기준이에요. 공공 SW 사업은 소프트웨어 진흥법 제60조가 시험·검사를 거쳐 최종 산출물을 인도한 날부터 1년으로 정해요. 민간 계약은 민법 제670조가 인도받은 날부터 1년 안에 청구하도록 하지만, 오픈일과 검수일이 다를 수 있으니 계약서에 시작일을 날짜로 적어 두는 편이 다툼을 줄여요.

AI 개발 외주는 기획부터 검수까지 맡길 때 인수인계도 따로 정해야 하나요?

정해 두세요. AI 기능은 코드만 넘겨받아선 같은 결과가 안 나올 수 있어요. 모델 버전, 프롬프트, 평가에 쓴 데이터와 결과, API 키 명의까지 인수인계 산출물 목록에 넣고, 검수 기준에도 같은 평가 세트를 쓰면 넘겨받은 뒤 결과가 달라졌을 때 원인을 가릴 수 있어요.

인수인계 기간에 드는 비용은 구축 견적에 들어 있나요?

견적서에 적혀 있지 않으면 들어 있다고 보기 어려워요. ‘인수인계 지원 ○주, 교육 ○회’처럼 기간과 횟수가 적혀 있는지 먼저 확인하세요. 앱 개발 외주 비용을 여러 업체와 비교할 때도 이 항목이 있는 견적과 없는 견적은 같은 기준이 아니에요.