무상 하자보수, 몇 개월이고 어디까지일까요 | 기준표
하자보수 기간은 민법상 인도일부터 1년, 공공 소프트웨어 사업도 사업 완료 뒤 1년이 기본이에요. 민간 계약은 1~12개월 사이에서 합의해요. 기간을 세기 시작하는 날, 하자보수 범위를 가르는 상황 10가지, 유상으로 넘어가는 시점을 표로 정리했어요.

먼저 짧게 답부터 드릴게요. 무상 하자보수 기간의 법적 기본값은 1년이에요. 다만 민간 계약은 합의로 정할 수 있어서 실제 계약서에는 1개월부터 12개월까지 다양하게 적혀요. 기간보다 더 자주 다투는 건 범위예요. 하자보수는 “만든 대로 안 돌아가는 것”만 고쳐요. 운영체제 업데이트, 외부 서비스 변경, 기능 추가는 무상 기간 안에도 범위 밖일 수 있어요. 직접 만들고 운영해 본 개발사 기준으로 기간과 범위를 표로 정리했어요.
“오픈한 지 두 달 됐는데 오류가 나서 연락했더니, 이건 하자가 아니라 유지보수라고 해요.”
발주자가 가장 당황하는 순간 가운데 하나예요. 유지보수 요율은 유지보수 비용은 얼마를 잡아야 할까요에 정리해 뒀어요. 이 글은 그 앞 단계, 돈을 내지 않고 고쳐 받을 수 있는 기간과 범위만 다뤄요.
1. 하자보수 기간은 법으로 정해져 있나요

기본값은 있어요. 다만 민간 계약에서는 합의가 먼저예요.
공식 외부 기준
| 구분 | 하자보수 기간 | 근거 |
|---|---|---|
| 민법(도급 계약의 기본 규칙) | 결과물을 인도받은 날부터 1년 안에 보수·손해배상을 청구. 인도가 필요 없는 일은 일이 끝난 날부터 | 민법 제670조 |
| 공공 소프트웨어 사업 | 사업 완료 뒤 1년 동안 무상 하자보수. 계약에 없던 추가 개발, 추가 인력 투입, 추가 교육·기술 지원은 유상 유지관리로 처리 | 계약예규 용역계약일반조건 제58조(전자신문 2021년 3월 보도 기준) |
| 책임을 줄이는 약정 | 기간과 범위를 줄이는 약정은 가능. 다만 수급인이 알고도 알리지 않은 사실에 대해서는 책임을 피하지 못해요 | 민법 제672조 |
(조문 요약이에요. 공공 계약예규는 개정될 수 있으니 실제 사업은 공고 시점의 조문을 확인하세요. 분쟁이 걸린 경우엔 법률 전문가와 상의하세요.)
자사 실무 기준 — 민간 계약에서 자주 보는 기간
| 프로젝트 규모 | 계약서에 흔히 적히는 무상 기간 |
|---|---|
| 소규모(단순 웹·앱) | 1~3개월 |
| 중간 규모 | 3~6개월 |
| 규모가 크거나 공공 기준을 따르는 계약 | 12개월 |
(자사 실무에서 본 범위예요. 정해진 기준이 아니라 합의 사항이에요.)
계약서에 기간이 아예 없다면 민법의 1년이 기본값으로 돌아가요. 반대로 “1개월”이라고 적혀 있다면 그게 먼저예요. 그래서 견적을 비교할 때 금액 옆에 무상 기간이 몇 개월인지를 같이 적어 두세요. 같은 개발 외주 비용이라도 무상 3개월과 12개월은 다른 물건이에요.
2. 기간은 언제부터 세나요

“3개월”이라고 적어도 어느 날부터 세는지에 따라 실제로 쓸 수 있는 기간이 달라져요.
| 세기 시작하는 날 | 발주자에게 | 주의할 점 |
|---|---|---|
| 납품일(코드 전달일) | 불리해요 | 검수하는 동안에도 기간이 흘러요 |
| 검수 완료일 | 무난해요 | 검수를 미루면 개발사 쪽 부담이 길어져 검수 기한도 같이 적어야 해요 |
| 오픈일(실제 서비스 시작일) | 유리해요 | 오픈이 발주자 사정으로 늦어지면 다툼이 생겨요 |
(자사 실무 기준이에요.)
가장 덜 다투는 건 검수 완료일이에요. 대신 검수 기한을 함께 적어요. “납품 뒤 며칠 안에 검수 결과를 알리지 않으면 검수가 끝난 것으로 본다”는 문장이 그 역할을 해요. 검수 기간을 며칠로 잡을지는 외주 검수 기간은 며칠 잡고, 누가 무엇을 확인할까요에 있어요.
용어 정리 — 하자보수는 만든 것이 약속한 대로 돌아가지 않을 때 무상으로 고치는 일이에요. 유지보수는 정상으로 돌아가는 서비스를 계속 손보는 유상 계약이고요. 기산일은 기간을 세기 시작하는 날을 말해요. 실무에선 “하자보수 기산일이 검수일이에요, 오픈일이에요?”라고 물어요.
3. 하자보수 범위는 어디까지 무상일까요

기준은 하나예요. 요구사항 정의서나 계약서에 적힌 대로 돌아가는가. 적힌 대로 안 돌아가면 하자고, 적힌 것 밖의 일이면 하자가 아니에요.
| 상황 | 대개 어느 쪽인가요 | 이유 |
|---|---|---|
| 1. 정의서에 있는 기능이 동작하지 않아요 | 무상 | 약속한 결과가 아니에요 |
| 2. 검증하기로 한 기기·브라우저에서 화면이 깨져요 | 무상 | 지원 범위 안이에요 |
| 3. 납품 때부터 있던 보안 취약점이 발견됐어요 | 무상 | 인도 시점의 결함이에요 |
| 4. 검증 범위에 없던 기기에서 오류가 나요 | 유상 | 범위 밖이에요 |
| 5. 버튼 문구나 화면 배치를 바꾸고 싶어요 | 유상 | 변경 요청이에요 |
| 6. 기능을 하나 더 넣고 싶어요 | 유상 | 추가 개발이에요 |
| 7. 발주자가 준 데이터의 형식이 달라 오류가 나요 | 유상 | 원인이 제공 자료에 있어요 |
| 8. 사용법 문의, 운영자 교육이 더 필요해요 | 유상 | 공공 기준도 추가 교육·기술 지원은 유상으로 봐요 |
| 9. 운영체제나 브라우저가 새로 나온 뒤 오류가 나요 | 계약서에 따라 | 4번 문단에서 따로 다뤄요 |
| 10. 사용자가 늘어 느려졌어요 | 계약서에 따라 | 성능 기준이 적혀 있었는지가 갈라요 |
(자사 실무 기준이에요. 실제 판단은 계약서와 요구사항 정의서 내용에 따라 달라져요.)
1~3번은 다툴 일이 거의 없어요. 문제는 정의서가 얇을 때예요. “회원 가입 기능”이라고만 적혀 있으면 소셜 로그인 오류가 하자인지 추가 개발인지 가를 근거가 없어요. 하자보수 범위는 결국 정의서의 두께만큼만 보장돼요.
4. 가장 자주 다투는 세 가지는 무엇일까요

표의 9번, 10번과 외부 서비스 연동이에요. 셋 다 코드가 바뀐 게 아니라 바깥 환경이 바뀐 것이라 양쪽 생각이 갈려요.
운영체제·브라우저 업데이트
앱은 해마다 새 운영체제가 나와요. 납품 때 멀쩡하던 화면이 새 버전에서 어긋날 수 있어요. 계약서에는 이렇게 적어 두면 돼요.
- 납품 시점에 지원하는 버전을 숫자로 적어요
- 무상 기간 안에 나온 새 버전 대응을 무상에 넣을지, 유상으로 할지 한 줄로 정해요
외부 서비스 변경
결제, 지도, 소셜 로그인 같은 연동은 상대 회사가 규격을 바꾸면 우리 쪽도 고쳐야 해요. 개발사 잘못이 아니라서 대개 유상이에요. 연동이 많은 서비스일수록 무상 기간과 별개로 유지보수 계약이 필요한 이유예요.
성능
“느려요”는 기준이 없으면 하자로 볼 근거가 없어요. 동시에 몇 명이 쓸 때 몇 초 안에 응답한다는 숫자가 정의서에 있었다면 하자, 없었다면 증설이나 개선 작업이에요.
운영사 Tip 저희는 자체 SaaS 4종을 운영하면서 오류 신고를 받으면 먼저 “어제도 그랬나요”를 물어요. 어제는 됐는데 오늘 안 되면 바깥에서 무언가 바뀐 거고, 처음부터 안 됐다면 만든 쪽 문제일 가능성이 커요. 발주자도 신고할 때 언제부터 그랬는지와 어떤 기기인지를 같이 적어 주면 하자인지 아닌지가 훨씬 빨리 가려져요.
5. 무상 기간이 끝나면 언제 유상으로 넘어가나요

흔히 “무상 기간이 끝나는 날 유지보수 계약을 시작한다”고 생각해요. 그런데 3번 표를 보면 무상 기간 안에서도 유상인 일이 열 가지 가운데 다섯 가지예요. 그래서 전환 방식은 두 가지로 나뉘어요.
| 방식 | 어떻게 돌아가나요 | 맞는 경우 |
|---|---|---|
| 이어 붙이기 | 무상 기간이 끝나는 날 유지보수 계약 시작. 그 전의 변경 요청은 건별 견적 | 오픈 뒤 변경이 거의 없는 서비스 |
| 겹치기 | 오픈일부터 유지보수 계약 시작. 하자는 무상, 나머지는 유지보수 범위에서 처리 | 오픈 직후 고칠 게 많은 서비스 |
(자사 실무 기준이에요.)
이어 붙이기는 초기 비용이 적어 보이지만, 오픈 직후 요청이 몰리면 건마다 견적을 받고 승인하느라 시간이 걸려요. 오픈 뒤 3개월에 실제로 어떤 일이 생기는지는 오픈 후 3개월에 예산이 다시 들어요 | 실제 프로젝트 6건 기록에서 볼 수 있어요.
유상으로 넘어간 뒤의 요율은 초기 개발비 대비 연 11~20% 선이 공개된 기준이에요. 공공 부문 평균이 11.1%, 한국소프트웨어산업협회 대가 산정 가이드가 등급별로 11~19%를 제시해요. 계약서에 넣을 범위는 유지보수 계약(SLA), 어디까지 넣어야 할까요를 참고하세요.
6. 무상 기간을 길게 받으면 그만큼 이득일까요

꼭 그렇지는 않아요. 무상 기간은 공짜가 아니라 견적에 이미 들어 있는 값이에요. 개발사는 그 기간에 대응할 인력을 계산해서 금액을 정해요.
그래서 무상 기간을 늘려 달라고 하면 세 가지 가운데 하나가 일어나요.
- 견적이 올라가요
- 견적은 그대로인데 무상 범위가 좁게 적혀요
- 견적도 범위도 그대로인데 대응이 느려져요
세 번째가 가장 곤란해요. 겉으로는 유리한 계약인데 실제로 받는 건 줄어요. 기간을 늘리는 것보다 범위를 또렷하게 적고 대응 시간을 정하는 쪽이 발주자에게 남는 게 많아요.
흔한 실수 “하자보수 1년”이라는 한 줄만 확인하고 넘어가는 거예요. 기간만 있고 범위와 기산일이 없으면, 막상 오류가 났을 때 그게 하자인지부터 다시 합의해야 해요. 기간·기산일·범위·접수 방법 네 가지가 한 묶음이에요.
7. 계약서에는 무엇을 적어 두면 될까요

하자보수 조항을 볼 때 확인할 것들이에요.
- 기간 — 몇 개월인가요
- 기산일 — 납품일, 검수 완료일, 오픈일 가운데 어느 날인가요
- 무상 범위 — 요구사항 정의서 기준이라고 적혀 있나요
- 제외 항목 — 변경 요청, 외부 서비스 변경, 발주자 제공 자료로 인한 오류
- 환경 변화 — 새 운영체제·브라우저 대응은 어느 쪽인가요
- 접수와 대응 시간 — 어디로 알리고, 며칠 안에 답을 받나요
- 판단이 갈릴 때 — 하자인지 아닌지 의견이 다르면 어떻게 정하나요
7번은 빠지기 쉬운데 가장 쓸모 있어요. “원인을 개발사가 먼저 조사해 알리고, 개발사 책임이 아니면 조사 비용을 정산한다”처럼 순서만 정해 둬도 다툼이 짧아져요. 다른 조항은 외주 계약서, 어떤 조항이 빠지면 나중에 문제될까요에서 확인하세요.
8. 운영해 본 회사는 하자를 어떻게 볼까요

저희는 만든 것을 직접 운영해요. 그래서 하자를 “납품한 날의 결함”으로만 보지 않아요. 실제 운영 환경에 올라가야 드러나는 문제가 있거든요.
롯데백화점 수원 푸드홀 혼잡도 관리 시스템이 그랬어요. 관리자 화면에서 등록한 광고가 현장 사이니지에서 끊기는 문제가 있었고, 처음 JavaFX로 만든 부분을 C#으로 다시 만들어 해결했어요. 시험 환경에서는 보이지 않던 문제였어요. 실시간 시스템은 오픈이 끝이 아니라 시작이라, 저희는 배포 뒤 조정 단계까지 처음부터 일정에 넣어요.
발주자에게 권하는 건 하나예요. 계약 전에 “오픈하고 나서 다시 고친 부분이 있었나요, 그때 비용은 어떻게 했나요”라고 물어보세요. 무상 기간이 몇 개월인지보다 이 질문의 답이 그 회사가 하자를 어떻게 다루는지 더 잘 보여 줘요.
저희는 10년 넘게 50개 이상의 프로젝트를 만들었고 롯데·캐논 같은 곳과도 함께해 왔어요. 받은 계약서의 하자보수 조항이 한 줄뿐이라 불안하다면, 그 한 줄만 들고 오셔도 돼요. 기간·기산일·범위를 같이 채워 볼까요 →
9. 자주 묻는 질문 (FAQ)
하자보수 기간은 보통 몇 개월인가요?
법이 정한 기본값은 1년이에요. 민간 계약은 합의로 정할 수 있어서 작은 프로젝트는 1~3개월, 규모가 있으면 6~12개월로 적는 경우가 많아요.
운영체제 업데이트 때문에 생긴 오류도 무상인가요?
계약서에 정해 두지 않으면 매번 다투는 지점이에요. 납품 시점의 지원 버전을 적고, 그 뒤 버전 대응은 어느 쪽인지 한 줄로 정해 두세요.
무상 하자보수 기간에는 유지보수 계약이 필요 없나요?
하자보수는 만든 대로 안 돌아가는 것만 고쳐요. 기능 추가, 문구 변경, 서버 관리, 사용법 문의는 무상 기간 안에도 범위 밖이에요. 구축에서 운영으로 넘어가는 시점은 구축이 끝나면 언제 운영(SM)으로 넘어갈까요를 참고하세요.