외주 계약서 문장, 실제 프로젝트 4건에서 거꾸로 써 봤어요

먼저 짧게 답부터 드릴게요. 외주 계약서에 넣을 조항 목록은 이미 많이 나와 있어요. 그런데 실제로 분쟁이 나는 자리는 조항이 없어서가 아니라, 조항이 있는데 무엇을 기준으로 할지 비어 있어서예요. 저희가 실제로 만든 프로젝트 4건에서 가장 애먹은 지점을 하나씩 골라, 그 일이 다시 생기지 않으려면 계약서에 어떤 문장이 있어야 했는지 거꾸로 적어 봤어요.

“계약서에 검수 조항도, 하자보수 조항도 다 있었어요. 그런데 막상 문제가 생기니 이게 하자인지 아닌지부터 서로 말이 달랐어요.”

개발 외주 업체와 일해 본 분들이 자주 하는 말이에요. 어떤 조항이 꼭 있어야 하는지는 외주 계약서, 어떤 조항이 빠지면 나중에 문제될까요에 정리해 뒀어요. 이 글은 그 다음 단계, 조항 안에 무엇을 적어야 하는지를 실제 사례로 보여 드려요.

---

1. 조항은 있는데 왜 분쟁이 날까요

과학기술정보통신부는 2020년 소프트웨어 사업 표준계약서 6종을 만들면서 “필요하면 과업을 바꿀 수 있다” 같은 모호한 문장을 변경 사유별 세부 기준으로 바꿨어요. 법령 개정, 기술·정책 환경 변화, 금액 조정 없는 경미한 변경처럼 나누고, 바뀐 내용은 과업내용 변경관리 내역서로 남기게 했죠.

민간 외주 계약서는 아직 이 수준까지 안 가는 경우가 많아요. “주요 기능”, “정상 동작”, “합리적인 범위” 같은 말이 그대로 남아 있어요. 이 말들은 문제가 없을 땐 아무 일도 안 하다가, 문제가 생기면 양쪽이 서로 다르게 읽어요.

계약서에 자주 남는 말	분쟁 때 갈리는 질문
정상 동작	어떤 환경에서, 몇 대가 동시에 붙었을 때?
주요 기기 지원	어느 기종, 어느 운영체제 버전까지?
검수 완료	누가, 무엇을 기준으로, 며칠 안에?
경미한 변경	몇 시간 일이면 경미한가?

(공식 기준 출처: 과학기술정보통신부, 2020년 SW사업 표준계약서 6종 발표. 위 표의 표현 목록은 공식 자료가 아니라 자사 실무 경험 기준이에요.)

2. 롯데 푸드홀 사례 — ‘운영 환경’ 문장이 있어야 했어요

롯데백화점 수원 푸드홀 실시간 혼잡도 시스템은 캐논코리아와 컨소시엄으로 4개월 동안 만들었어요(기획 1 · 디자인 1 · 개발 2). 어려웠던 건 화면이 아니었어요. 보안 요건 때문에 내부·사설 네트워크로 구성해야 했고, 센서 여러 대가 동시에 데이터를 보내면서 취합이 늦어지는 현상이 나왔어요.

이런 프로젝트라면 계약서 범위 조항에 이 문장이 있어야 해요.

넣을 문장 — “시스템은 [사설망/인터넷망] 환경에서 동시 접속 장치 [N]대 기준으로 동작하며, 데이터 반영 지연은 [N]초 이내를 기준으로 검수한다.”

숫자가 들어가는 순간 “느리다”는 감상이 “기준을 넘었다”는 사실이 돼요. 이 프로젝트의 전체 과정은 롯데 푸드홀 실시간 혼잡도 시스템 사례에 있어요.

3. 같은 프로젝트에서 — ‘구현 방식 변경’ 문장도 필요했어요

같은 현장에서 관리자 페이지에서 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 저희는 초기 JavaFX 구현을 C#으로 다시 구현해서 해결했어요.

발주자 입장에선 “기술을 바꾸면 돈이 더 드는 거 아니냐”가 먼저 걱정될 거예요. 그래서 이런 문장이 있으면 좋아요.

넣을 문장 — “합의한 성능 기준을 충족하지 못해 구현 방식을 바꾸는 경우, 그 비용과 일정은 개발사가 부담한다. 요구사항 변경으로 인한 경우는 제[N]조 과업 변경 절차를 따른다.”

원인을 두 갈래로 나눠 두면 “누가 내느냐”로 다툴 일이 줄어요. 계약 뒤에 비용이 붙는 다른 길은 개발 외주 비용이 계약 뒤에 늘어나는 5가지 길에서 다뤘어요.

4. 캐논 유틸리티 사례 — ‘테스트 조합 목록’을 부록으로

캐논코리아 카메라 펌웨어 업데이트 유틸리티는 Windows와 Mac 양쪽에서 쓰는 프로그램이었고 2개월에 만들었어요. 가장 큰 부담은 다양한 펌웨어 버전과 장치 조합의 테스트였어요.

이런 일은 “주요 기종 지원” 한 줄로는 범위가 안 잡혀요. 테스트할 조합을 아예 표로 붙여요.

넣을 문장 — “검수 대상 기종·펌웨어·운영체제 조합은 부록 [N]의 목록으로 한정한다. 목록 밖 조합에서 생긴 문제는 하자가 아니라 추가 지원 요청으로 처리하며, 그 범위와 일정은 별도로 정한다.”

목록이 있으면 발주자도 좋아요. 무엇이 검증됐는지 눈으로 확인할 수 있으니까요. 이 프로젝트 이후 업데이트 관련 고객 문의가 줄고 Mac 사용자도 업데이트를 쓸 수 있게 됐어요.

5. 코닥 앱 사례 — ‘오류 처리’도 납품물이에요

코닥 인스턴트 프린터 블루투스 연동 앱(iOS, 연결 검증은 안드로이드 기기까지)은 2개월 프로젝트였어요. 핵심 난제는 수많은 휴대폰 기종과 프린터 사이의 연결 및 오류 처리였어요.

하드웨어 연동 앱은 연결이 끊겼을 때 무슨 화면이 뜨는지가 사용자 경험의 절반이에요. 그런데 계약서 납품물 목록엔 보통 “앱”만 적혀 있어요.

넣을 문장 — “납품물에는 연결 실패·중단·재시도 상황별 화면과 안내 문구 목록을 포함하며, 검수는 이 목록의 각 상황을 재현해 확인한다.”

이 프로젝트로 사진 인화기와 휴대폰 연동이 안정됐어요. 자세한 내용은 코닥 프린터 블루투스 앱 사례에 있어요.

6. 지구조각가 사례 — ‘기기별 화면 차이’ 검수 기준

지구조각가 건설장비 쇼핑 플랫폼 리뉴얼은 5개월 동안 쇼핑몰과 관리자 기능, 현장 작업일보까지 만들었어요(기획 1 · 디자인 1 · 개발 2). 지금 회원 5,549명, 작업일보 10,973건이 쌓여 있어요. 까다로웠던 건 아이폰과 안드로이드의 픽셀 차이로 작업일보 서명 영역이 어긋나는 문제였어요.

서명처럼 법적 의미가 있는 화면은 “잘 보이면 된다”로 넘어가면 안 돼요.

넣을 문장 — “서명·결제·약관 동의 등 [지정 화면]은 부록의 기기 목록 전부에서 입력 영역과 저장 결과가 일치하는지 화면별로 확인한 뒤 검수를 마친다.”

검수를 어떤 순서로 하는지는 개발 외주 검수, 어떻게 해야 분쟁이 줄어들까요를 같이 보세요.

7. 계약 전에 발주자가 직접 채울 표

네 사례를 합치면 계약서에서 숫자나 목록으로 바꿔야 할 칸은 이 정도예요.

칸	발주자가 정할 것	사례
운영 환경	망 구성, 동시 접속 장치 수, 허용 지연 시간	롯데 푸드홀
구현 방식 변경	원인별 비용 부담	롯데 푸드홀
테스트 조합	기종·버전·운영체제 목록	캐논 유틸리티
오류 상황	실패·중단·재시도 화면 목록	코닥 앱
기기별 검수	꼭 같아야 하는 화면 지정	지구조각가
경미한 변경	몇 시간까지를 경미로 볼지	공통

마지막 칸은 사례마다 꼭 나왔어요. 저희는 보통 작업 시간 기준으로 정해 두자고 제안해요. 변경 요청 비용이 어떻게 계산되는지는 변경 요청 비용, 외주에서 어떻게 계산할까요에 있어요.

흔한 실수 계약서 표준 양식을 그대로 쓰고 부록을 비워 두는 거예요. 본문 조항이 아무리 좋아도 기준 숫자와 목록이 부록에 없으면 검수 때 쓸 게 없어요.

8. 운영까지 해 본 개발사가 계약 단계에서 묻는 것

네 건 모두 어려움은 화면 설계서 밖에서 나왔어요. 사설망, 센서 동시 전송, 기기 조합, 픽셀 차이. 그래서 저희는 계약 전 상담에서 화면 목록보다 “어디서, 몇 대가, 어떤 기기로 쓰나요”를 먼저 물어요. 자체 SaaS 4종을 직접 운영하면서 생긴 습관이기도 해요. 출시 다음 날부터 들어오는 문의는 대부분 이 질문들에서 나오거든요.

계약서 부록을 어떻게 채울지 막막하다면 지금 쓰는 기기와 환경 목록만 들고 오셔도 괜찮아요. 범위·검수 문장을 같이 정리해 드릴게요. 우리 프로젝트 계약서, 기준 숫자부터 같이 채워 볼까요 →

저희는 10년 넘게 50개 이상의 프로젝트를 만들어 왔고, 롯데·캐논 같은 곳과도 함께해 왔어요. 발주자 자리와 운영자 자리, 양쪽에서 계약서가 어디서 비는지 겪어 봤어요.

9. 자주 묻는 질문 (FAQ)

개발 외주 계약서에 운영 환경까지 적어야 하나요?

적는 게 좋아요. 사설망인지, 어떤 기기·운영체제 버전에서 쓰는지, 동시에 몇 대가 붙는지가 빠지면 검수 기준도 비어요. 저희 경험상 가장 오래 걸린 문제는 대개 이 운영 환경에서 나왔어요.

기기 호환성 테스트 범위는 계약서에 어떻게 써야 하나요?

“주요 기기에서 동작” 대신 테스트할 기기·운영체제·버전 목록을 부록으로 붙이세요. 목록 밖 기기에서 생긴 문제를 하자로 볼지 추가 요청으로 볼지도 한 줄로 정해 두면 다툼이 줄어요.

개발 중에 기술을 바꿔야 하면 비용은 누가 내나요?

합의한 기준을 못 맞춰서 바꾸는 거면 대개 개발사 몫이고, 요구사항이 바뀌어서라면 과업 변경으로 다시 합의해요. 성능 기준을 숫자로 적어 두면 원인이 금방 갈려요. 앱 외주 과정 전체는 앱 외주, 출시까지 발주자는 단계마다 무엇을 할까요에 정리해 뒀어요.