잔금까지 냈는데 버그가 나왔습니다 — 무상 수정은 어디까지인가

아닙니다. 여기서 많이 어긋납니다.

검수는 "인수했다" 는 뜻이지 "결함이 없다" 는 뜻이 아닙니다. 검수 단계에서 발견할 수 없었던 결함은 인수 후에도 개발사의 책임으로 남습니다. 이걸 하자담보책임이라고 합니다.

검수 후에도 개발사 책임인 것:

검수 시점에 드러나지 않은 결함 (특정 조건에서만 나는 오류)

명세대로 만들었는지 겉으로 확인할 수 없는 부분 (동시 접속 시 데이터 꼬임 등)

시간이 지나야 나타나는 문제 (데이터가 쌓이면 느려지는 구조)

검수로 넘어간 것:

검수 때 보고도 넘어간 사항 (화면 색상, 문구 등 눈에 보이는 것)

검수 확인서에 "이의 없음" 으로 서명한 항목

그래서 검수 확인서에 "본 확인은 하자담보책임을 면제하지 않는다" 한 줄을 넣어두면 나중에 다툴 일이 줄어듭니다. 없어도 법적으로 책임이 사라지진 않지만, 개발사가 "검수 끝났잖아요" 라고 나올 때 대화가 빨리 끝납니다.

개발사와 부딪히는 지점은 대부분 여기입니다. 기준은 하나입니다.

"합의한 명세대로 동작하는가"

애매한 것 세 가지:

"느리다" — 명세에 응답 시간 기준이 있으면 하자, 없으면 다툼이 됩니다. 계약 때 "목록 조회 3초 이내" 처럼 숫자를 적어두면 이 다툼이 사라집니다.

"쓰기 불편하다" — 대부분 추가 요구입니다. 다만 명세대로 만들었는데 실제로 업무가 안 돌아간다면, 명세를 같이 만든 책임도 개발사에 있습니다.

외부 서비스가 바뀌어 깨진 경우 — 카카오·PG사가 API 를 바꿔서 연동이 끊긴 것은 하자가 아닙니다. 유지보수 계약의 영역입니다.

명세가 부실할수록 이 선이 흐려집니다. 다툼의 뿌리는 대개 버그가 아니라 명세를 안 적어둔 것입니다.

계약서에 하자보수 기간이 적혀 있으면 그 기간이 우선합니다. 없다면 민법상 도급의 하자담보책임 기간이 적용되고, 소프트웨어는 통상 납품일로부터 1년으로 봅니다.

실무에서 흔한 계약 형태:

3개월 — 소규모 프로젝트에서 자주 보입니다

6개월 — 가장 흔합니다

1년 — 규모가 크거나 공공 발주에서 씁니다

기간을 셀 때 주의할 점:

시작일이 "납품일" 인지 "검수 완료일" 인지 적어야 합니다. 검수가 늘어지면 한 달 넘게 차이 납니다.

하자를 고치는 동안은 기간이 멈추는지 정해두는 게 좋습니다. 안 그러면 대응을 미루는 쪽이 이득을 봅니다.

기간이 끝나도 개발사가 알면서 숨긴 결함은 책임이 남습니다.

기간이 끝난 뒤: 유지보수 계약으로 넘어갑니다. 월 정액이든 건당이든, 하자보수가 끝나는 시점에 무엇으로 이어갈지 미리 정해두지 않으면 그 사이에 서비스가 방치됩니다.

감정이 앞서면 오래 걸립니다. 순서대로 밟는 게 빠릅니다.

STEP 1 — 하자를 문서로 특정한다

말로 하면 "재현이 안 된다" 로 끝납니다. 이렇게 적어 보냅니다.

어떤 화면에서, 어떤 순서로 눌렀을 때

무엇을 기대했고 실제로 무엇이 나왔는지

화면 녹화나 캡처, 발생 시각

명세서의 어느 항목과 어긋나는지

마지막 줄이 핵심입니다. 명세를 짚으면 "추가 요구" 라는 반박이 막힙니다.

STEP 2 — 기한을 정해 통지한다

"확인 부탁드립니다" 는 기한이 없어서 계속 밀립니다. "9월 15일까지 수정 일정을 회신해 주십시오" 처럼 날짜를 적고, 이메일 등 남는 방식으로 보냅니다.

STEP 3 — 내용증명

회신이 없거나 거절이 반복되면 내용증명을 보냅니다. 이 단계에서 대부분 대화가 재개됩니다. 하자 내역·근거 조항·요구 사항·기한을 적습니다.

STEP 4 — 하자보수 보증금 또는 상계

계약에 하자보수 보증금이 있으면 여기서 씁니다. 없다면 미지급 잔금이 남아 있는 경우 상계를 주장할 수 있습니다. 그래서 잔금을 전액 지급하기 전에 하자보수 조항을 확인하는 편이 안전합니다.

STEP 5 — 지급명령 / 소액사건

3,000만원 이하는 소액사건심판으로 갈 수 있고, 지급명령은 상대가 이의하지 않으면 빠르게 끝납니다. 다만 여기까지 오면 시간이 많이 듭니다. STEP 1 의 문서화가 잘 되어 있을수록 앞 단계에서 정리됩니다.