소스코드 에스크로 2026 — SW 임치·하자보수 범위·기술지원 계약 7단계

외주 계약서 검토는 대개 착수 전에 끝난다. 금액, 일정, 산출물 목록을 확인하고 도장을 찍는다. 그런데 실제로 발주처가 곤란해지는 시점은 계약 체결 시점이 아니라 검수가 끝난 다음 날부터다. 개발사가 연락을 늦게 받기 시작하고, 버그를 고쳐 달라고 하면 "그건 추가 개발입니다"라는 답이 오고, 2년 뒤 개발사가 사업을 접으면 서비스가 통째로 멈춘다.

이 글은 계약 이후를 지키는 세 가지 장치를 다룬다. 소스코드 에스크로(SW 임치), 하자보수 범위, 기술지원·유지보수 계약이다. 세 개는 서로 다른 문제를 푼다. 하나로 나머지 둘을 대신할 수 없다.

소스코드 에스크로가 실제로 하는 일, 그리고 못 하는 일

소프트웨어 임치는 개발사가 소스코드와 기술정보를 제3의 기관(수치인)에 맡겨 두고, 계약서에 미리 적어 둔 사유가 발생했을 때만 발주처가 그것을 받아 가는 제도다. 저작권법 제101조의7이 근거 조항이고, 국내에서는 한국저작권위원회가 대표적인 수치인 역할을 한다.

여기서 오해가 시작된다. 많은 발주처가 임치를 "돈 내면 소스코드를 받는 옵션"으로 이해한다. 아니다. 임치는 조건부 청구권이다. 조건을 안 쓰면 아무 일도 일어나지 않는다.

오른쪽 열이 이 글의 나머지 전부다. 임치를 걸어 놓고 안심한 발주처가 정작 개발사와 틀어졌을 때 아무것도 못 하는 이유는, 문제가 오른쪽 열에서 터지기 때문이다.

⚠️ 임치 계약과 저작권 양도 계약을 같은 것으로 아는 발주처가 많다. 임치는 보관이고 저작권 양도는 권리 이전이다. 임치물을 받아도 저작재산권이 개발사에 있으면 그 코드를 다른 업체에 넘겨 수정하게 하는 순간 2차적저작물작성권 침해가 된다. 계약서에 "본 소프트웨어의 저작재산권(제22조의 2차적저작물작성권 포함)은 발주처에 귀속한다"를 별도로 박아야 한다.

계약 이후를 지키는 7단계

순서가 있다. 앞 단계를 건너뛰고 뒤 단계만 계약서에 넣으면 조항은 있는데 작동하지 않는 상태가 된다.

1~2단계가 계약서 본문, 3~4단계가 임치 계약, 5~7단계가 검수·운영 단계다. 실무에서 가장 많이 빠지는 건 2단계와 5단계다. 둘 다 "당연히 되겠지"라고 넘어가는 항목이라 계약서에 문장이 없다.

⚠️ 임치를 계약 막바지에 붙이려 하면 개발사가 "임치 수수료는 별도 청구"라고 나온다. 착수 전 견적서에 임치 비용을 포함시켜 놓으면 이 실랑이가 없다. 금액 자체는 프로젝트 대비 1% 미만이라 견적 협상의 쟁점이 되지도 않는다.

임치물 목록 — "빌드 가능한 상태"를 계약서에 정의하라

임치의 실질적 실패는 대부분 "받았는데 안 돌아간다"이다. 소스코드 압축 파일 하나만 임치해 두면, 인도받은 뒤 새 업체가 그것을 열고 나서 이렇게 말한다. "이거 어떤 버전으로 빌드했는지 모르겠는데요."

계약서 부속서에 임치물을 항목으로 열거하고, "제3자가 이 목록만으로 빌드·배포를 재현할 수 있어야 한다"는 문장을 넣는다. 이 한 문장이 목록의 누락을 방어한다.

환경변수는 키 이름과 용도만 임치한다. 실제 값(API 키, DB 비밀번호)까지 넣으면 그건 임치가 아니라 보안 사고 대기 상태다. 값은 발주처가 별도 보관한다.

설계 산출물 쪽은 시스템 구성도 작성법에서 다루는 논리·물리 구성도가 그대로 임치물로 쓰인다. 착수 단계에 만든 문서가 여기서 두 번째 값어치를 한다.

⚠️ 임치물 검증을 옵션으로 두지 마라. 수치인 기관은 "받은 파일을 보관"할 뿐 "그게 빌드되는지"를 기본으로 확인하지 않는다. 유상 검증 서비스가 따로 있고, 임치물이 실제로 실행 가능한지를 확인해 주는 것은 그 절차다. 검증 없는 임치는 봉투에 백지를 넣어 둔 것과 구분되지 않는다.

갱신 주기 — 스냅샷은 낡는다

임치는 그 시점의 스냅샷이다. 착수 6개월 차에 한 번 임치하고 이후 2년간 갱신하지 않으면, 개발사가 폐업했을 때 발주처가 받는 건 2년 전 코드다. 그 사이에 결제 모듈이 바뀌었고 기능이 40개 늘었다면, 받은 코드로는 현재 서비스를 복구할 수 없다.

갱신 주기는 프로젝트 성격으로 정한다. 기능이 계속 추가되는 서비스는 분기 1회, 완성 후 유지만 하는 사내 시스템은 반기 또는 연 1회로 충분하다. 중요한 건 주기를 계약서에 숫자로 쓰는 것이다. "필요 시 갱신"은 갱신하지 않겠다는 뜻이다.

⚠️ 갱신 의무를 개발사에만 맡기면 실제로는 안 한다. 갱신 완료 증빙(수치인 기관 접수증)을 유지보수 대금 지급 조건에 연동해 두면 그때부터 지켜진다. 조항 한 줄이 아니라 지급 조건에 걸어야 작동한다.

하자와 추가 개발의 경계선은 문서가 그린다

여기가 실제 분쟁의 90%가 발생하는 지점이다. 발주처는 "안 되니까 고쳐 달라"고 하고 개발사는 "그건 계약에 없던 겁니다"라고 한다. 둘 다 진심이다. 판단 기준이 없기 때문이다.

기준은 하나다. 합의된 사양과 다르게 동작하면 하자, 사양에 없던 것을 요구하면 추가 개발이다. 그러면 "합의된 사양"이 어디에 적혀 있느냐가 전부가 된다.

마지막 두 줄이 이 표의 핵심이다. 같은 현상이 문서 유무로 하자가 되기도 하고 유상 작업이 되기도 한다. 비기능 요구사항(응답 시간, 동시접속, 브라우저 범위)을 안 적어 두면 성능 문제는 전부 발주처 부담이 된다.

경계를 그리는 문서는 세 개다. 요구사항 정의서가 무엇을 만들지, 기능 정의서가 어떻게 동작할지, 테스트 케이스가 무엇을 통과해야 인수인지를 정한다. 이 글에서 그 작성법을 반복하지는 않겠다. 다만 임치와 하자보수 조항은 그 문서들이 있어야 작동한다는 점만 기억하면 된다.

⚠️ "검수 완료" 도장을 찍는 순간 하자보수 기간이 시작되고, 그 이후 발견되는 사양 미달은 하자로 주장하기가 급격히 어려워진다. 검수는 화면을 눌러 보는 자리가 아니라 테스트 케이스를 하나씩 통과시키는 자리다. 통과하지 못한 항목이 있으면 조건부 검수로 남기고 미결 목록과 기한을 문서에 남긴다.

하자보수 기간 — 법정 기본값과 계약 기본값

계약서에 하자보수 기간을 안 쓰면 기간이 무한이 되는 게 아니라, 법에 정해진 기본값이 적용된다.

핵심은 표의 마지막 열이다. 실제 분쟁은 기간이 6개월이냐 12개월이냐에서 터지지 않는다. "이게 하자냐"에서 터진다. 그래서 기간을 12개월로 늘리는 협상보다 하자 정의를 한 줄 더 구체적으로 쓰는 협상이 값어치가 크다.

공공 SW 영역에서는 하자보수 범위를 무한정 넓게 해석해 사실상 무상 유지보수를 요구하는 관행이 문제로 지적돼 왔고, 그래서 하자와 유지관리를 구분하는 가이드라인이 만들어졌다. 민간 계약도 같은 구분을 그대로 쓰면 된다. 하자는 고치는 것, 유지보수는 계속 돌아가게 하는 것이다.

⚠️ 하자보수 기간의 기산점을 "검수 완료일"이 아니라 "최종 대금 지급일"로 써 놓은 계약서를 종종 본다. 발주처가 대금을 늦게 주면 하자보수 기간도 같이 늦게 시작되므로 언뜻 유리해 보이지만, 실제로는 개발사가 "지급이 안 됐으니 하자보수 의무가 개시되지 않았다"고 주장할 여지를 준다. 기산점은 검수확인서 날짜로 고정하는 게 안전하다.

유지보수·기술지원 계약의 비용 구조와 SLA

무상 하자보수가 끝나면 그 다음은 유상이다. 여기서 발주처가 준비 없이 맞닥뜨리는 게 요율이다.

정액 유지보수 요율은 공공 부문에서 계약금액의 15% 수준이 권고돼 왔지만 실제 반영률은 그보다 낮게 형성돼 왔다. 민간 발주처가 참고할 지점은 숫자 자체가 아니라 요율을 계약금액에 연동할지, 실제 작업량에 연동할지다. 변경이 거의 없는 사내 시스템에 15%를 매년 내는 건 과하고, 반대로 기능이 계속 붙는 서비스에 시간제만 걸어 두면 예산이 튄다.

3,000만 원짜리 시스템을 3년 운영한다고 하면 정액 10% 기준 유지보수만 900만 원이다. 초기 견적의 30%가 운영비로 더 나간다는 뜻이고, 이 금액을 착수 전 예산에 안 잡아 두면 2년 차에 유지보수를 끊게 된다. 유지보수를 끊은 시스템은 3년 차에 보안 패치가 밀려 결국 재구축 견적을 다시 받는다.

⚠️ "무상 유지보수 1년 포함"이라는 견적서를 그대로 믿지 마라. 그 문장은 대개 하자보수를 유지보수라고 부른 것이다. 무상 범위에 OS·라이브러리 보안 패치, 외부 API 규격 변경 대응, 데이터 백업 확인이 포함되는지를 항목으로 물어보면 실제 범위가 드러난다.

SLA는 응답시간이 아니라 복구시간으로 쓴다

기술지원 계약에서 가장 흔한 허점은 SLA를 "1시간 내 응답"으로만 써 두는 것이다. 응답은 "확인했습니다" 한 줄로 충족된다. 그 뒤 사흘이 걸려도 계약 위반이 아니다.

등급 정의는 발주처 업무 기준으로 쓴다. "서버 다운"이 아니라 "고객이 주문을 넣을 수 없는 상태"처럼 써야 개발사가 등급을 낮춰 잡는 걸 막는다. 감액 조항은 금액이 크지 않아도 넣는다. 실효는 배상이 아니라 등급 협의를 진지하게 만드는 데 있다.

⚠️ 대응 가능 시간대를 안 쓰면 기본값은 평일 근무시간이다. 야간 주문이 많은 커머스인데 SLA에 시간대가 없으면, 금요일 밤 결제 장애는 월요일 오전에 접수된다. 24시간 대응이 필요하면 그 비용을 감수하고 명시하고, 필요 없으면 굳이 사지 마라.

계정과 인프라 소유권 — 에스크로보다 먼저 확인할 것

실무에서 발주처를 실제로 묶어 두는 건 소스코드가 아니다. 계정이다. 소스코드는 임치로 확보했는데 클라우드 계정이 개발사 명의고, 도메인이 개발사 대표 개인 이메일로 등록돼 있고, 앱스토어 개발자 계정이 개발사 것이면 코드를 손에 쥐고도 아무것도 못 한다. 앱 업데이트 하나 올리려면 개발사의 협조가 필요하다.

원칙은 단순하다. 돈이 나가는 계정은 전부 발주처 카드로 등록한다. 개발사가 대납하고 청구하는 구조는 편해 보이지만, 관계가 끝나는 시점에 그 계정들이 전부 인질이 된다. 개발 편의를 위해 개발사에 관리자 권한을 주는 건 괜찮다. 소유권을 넘기는 것과는 다르다.

웹·앱을 순수하게 외주로 맡길 때도 마찬가지다. 포텐랩(Potenlab) 같은 곳처럼 계정 명의를 처음부터 발주처로 세팅하고 시작하는 방식이면 종료 시점에 이관 작업 자체가 없어진다. 프로젝트 첫 주에 30분이면 끝나는 일이고, 끝나고 나서 하면 두 달이 걸린다.

⚠️ 앱스토어 개발자 계정 이전은 애플·구글의 별도 승인 절차를 거치고 수 주가 걸린다. 개발사와 사이가 틀어진 뒤에는 상대 협조가 필요한 이 절차가 사실상 멈춘다. 앱 프로젝트라면 계약서에 "개발자 계정은 발주처 사업자명으로 신규 개설하고 개발사는 관리자 권한만 부여받는다"를 첫 조항으로 넣어라.

발주처가 착수 전에 확정해야 할 항목

계약서 서명 전에 답이 나와 있어야 하는 목록이다. 하나라도 비어 있으면 그 항목은 나중에 협상이 아니라 분쟁이 된다.

• 저작재산권 귀속 주체. 2차적저작물작성권 포함 여부를 명시했는가
• 개발사가 재사용하는 자체 라이브러리·프레임워크의 이용 조건. 영구·무상·양도 가능한 라이선스인가
• 오픈소스 라이선스 목록과 등급. 소스 공개 의무가 있는 라이선스가 섞여 있는가
• 임치 여부, 수치인 기관, 개시 시점, 갱신 주기. 숫자로 적었는가
• 임치물 목록과 "빌드 재현 가능" 문구. 부속서로 첨부했는가
• 임치물 인도 사유(release condition). 폐업·부도·합병·유지보수 거부·SLA 반복 미달 중 무엇을 넣을 것인가
• 하자보수 기간과 기산점. 검수확인서 날짜로 고정했는가
• 하자 정의와 제외 항목. 비기능 요구사항(응답 시간, 동시접속, 지원 브라우저)을 숫자로 적었는가
• 검수 기준. 테스트 케이스 통과율로 정의했는가
• 유지보수 요율과 산정 방식. 정액인가 시간제인가, 연간 상한이 있는가
• SLA 등급별 복구 목표와 대응 시간대
• 계정·인프라 명의. 도메인, 클라우드, 저장소, 스토어, PG, 외부 API 각각
• 인수인계 산출물과 시점. 종료 시 어떤 문서를 며칠 안에 받는가

⚠️ 이 목록을 개발사에 그대로 보내 답변을 받아 보면 업체 선별 효과가 크다. 항목별로 명확한 답이 오는 곳과 "그건 진행하면서 협의하시죠"가 오는 곳이 갈린다. 후자는 계약 이후 협상이 매번 그런 식이 된다.

흔한 실패 5가지

1. 임치는 걸었는데 갱신을 안 했다. 착수 시 1회 임치 후 3년 방치. 개발사 폐업 후 받아 보니 현재 서비스와 기능이 절반쯤 다르다. 갱신 주기를 계약서에 숫자로 쓰고 지급 조건에 연동해야 한다.

2. 소스는 받았는데 빌드가 안 된다. 압축 파일 하나만 임치돼 있고 의존성 잠금 파일, 빌드 스크립트, 환경변수 목록이 없다. 새 업체가 환경을 복원하는 데만 3~4주와 수백만 원이 든다. 임치물 목록에 "제3자 빌드 재현 가능"을 조건으로 걸어야 막힌다.

3. 하자 정의가 없어 모든 수정이 유상이 된다. 요구사항 정의서가 한 장짜리 개조식이라 "합의된 사양"을 특정할 수 없다. 개발사가 모든 수정을 추가 개발로 분류해도 반박할 근거가 없다. 문서 품질이 곧 하자보수 범위다.

4. 계정이 개발사 명의라 코드가 무용지물이 된다. 저작권도 발주처, 임치도 완료. 그런데 AWS 계정과 앱스토어 계정이 개발사 것이다. 이전에 두 달이 걸리고 그 사이 서비스는 개발사 통제 아래 있다.

5. 유지보수 예산을 안 잡아 2년 차에 끊는다. 초기 구축비만 예산에 반영하고 연 10~15%의 운영비를 계상하지 않는다. 2년 차에 유지보수 계약을 종료하고, 3년 차에 라이브러리 보안 취약점이 쌓여 재구축 견적을 다시 받는다. 재구축비는 초기 구축비보다 대개 비싸다.

⚠️ 다섯 가지 중 넷은 계약서 조항 몇 줄로 예방된다. 유일하게 조항으로 못 막는 건 5번이다. 이건 예산 편성의 문제라, 구축비를 승인받는 자리에서 3년 총소유비용으로 같이 올려야 한다.

AI-Native 팀이 인수인계를 다루는 방식

나무숲(TreeSoop)은 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 쓴다. 그러다 보니 인수인계 문서가 프로젝트 종료 시점의 별도 작업이 아니라 개발 중에 계속 갱신되는 물건이 된다.

구체적으로는 세 가지가 달라진다. 첫째, 실행 절차서(로컬 구동부터 배포까지)가 코드와 같은 저장소에 커밋된다. 코드가 바뀌면 절차서도 같은 커밋에서 바뀐다. 둘째, 그 절차서로 실제 환경을 처음부터 재현하는 검증을 주기적으로 돌린다. "문서대로 따라 하면 되나"를 사람이 아니라 자동화된 절차가 확인한다. 셋째, 임치물 목록이 이 검증을 통과한 파일 집합과 일치한다. 임치 시점에 목록을 새로 만들 필요가 없다.

이 방식은 발주처 입장에서 두 가지 값어치가 있다. 임치물이 실제로 빌드된다는 것이 계약 종료 전에 이미 확인돼 있고, 개발사를 바꾸더라도 새 팀의 온보딩 기간이 몇 주에서 며칠로 줄어든다. 작동 원리는 AI-Native 개발 방식에 정리해 두었다.

⚠️ AI 도구를 쓴다는 게 문서가 자동으로 생긴다는 뜻은 아니다. 오히려 생성 속도가 빨라 검증되지 않은 문서가 대량으로 쌓이기 쉽다. 발주처가 물어봐야 할 건 "AI를 쓰느냐"가 아니라 "그 문서대로 환경이 재현되는 걸 누가 언제 확인하느냐"다.

자주 묻는 질문

Q. 소스코드를 그냥 계약서로 넘겨받으면 임치가 필요 없지 않나요?

소유권과 보관은 다른 문제다. 계약서에 "소스코드를 인도한다"고 써 있어도 개발사가 부도나 폐업으로 사라지면 인도를 청구할 상대가 없다. 임치는 그 상황에서도 제3자 기관에 물건이 남아 있게 하는 장치다. 반대로 프로젝트 진행 중에도 저장소 접근 권한을 계속 받고 매 스프린트 코드를 확인하는 구조라면 임치의 실익은 줄어든다. 개발사가 저장소를 열어 주지 않는 계약일수록 임치가 필수가 된다.

Q. 임치 비용은 누가 냅니까?

정해진 규칙은 없고 협상 사항이다. 실무에서는 발주처가 부담하거나 프로젝트 견적에 포함시키는 경우가 많다. 금액이 프로젝트 규모 대비 1% 미만이라 부담 주체보다 견적서에 항목으로 들어가 있는지가 더 중요하다. 견적 확정 후에 꺼내면 별도 청구 실랑이가 붙는다.

Q. 하자보수 기간을 2년으로 늘려 달라고 요구해도 되나요?

요구할 수는 있지만 개발사가 그 리스크를 견적에 얹는다. 대개 기간을 늘리는 것보다 하자 정의를 구체화하는 쪽이 같은 비용으로 더 많이 얻는다. 6개월이라도 하자 범위가 명확하면 실제로 고쳐지고, 2년이라도 "하자 여부는 개발사 판단"이면 아무것도 안 고쳐진다.

Q. 개발사가 자체 프레임워크를 쓴다는데 괜찮습니까?

계약 전에 두 가지를 문서로 받아라. 그 프레임워크의 소스가 임치물에 포함되는지, 그리고 계약 종료 후에도 영구·무상으로 쓸 수 있는지다. 둘 중 하나라도 아니면 그 시스템은 그 개발사 없이 유지될 수 없다. 종료 후 라이선스료를 매년 청구하는 구조도 실제로 존재하니 금액과 기간을 명시적으로 확인한다.

Q. 개발사와 이미 사이가 틀어졌습니다. 지금 뭘 먼저 해야 하나요?

순서가 있다. ① 계정 접근 권한부터 확인한다. 도메인, 클라우드, 저장소, 스토어 계정에 발주처가 관리자로 들어갈 수 있는지 지금 로그인해 본다. ② 최신 소스와 DB 백업을 확보한다. ③ 미결 하자 목록을 날짜와 함께 문서로 정리해 서면(이메일)으로 통지한다. 구두 요청은 나중에 증거가 되지 않는다. ④ 그다음에 계약 해지와 인수인계 협상을 시작한다. 순서를 바꿔 해지 통보를 먼저 하면 ①②를 못 하게 될 수 있다.

정리

계약 이후를 지키는 장치에서 결과를 가르는 지점은 세 가지다.

첫째, 임치물이 실행 가능한 상태인가. 소스코드 파일이 아니라 빌드·배포를 재현할 수 있는 묶음이어야 한다. 목록에 의존성 잠금 파일, 배포 스크립트, 환경변수 목록, 실행 절차서가 들어 있고 갱신 주기가 숫자로 적혀 있으면 임치가 작동한다. 압축 파일 하나면 봉투에 백지를 넣은 것과 같다.

둘째, 하자의 정의가 문서에 숫자로 적혀 있는가. 하자보수 기간을 6개월에서 12개월로 늘리는 협상보다, 응답 시간·동시접속·지원 브라우저를 숫자로 적어 두는 쪽이 실제로 더 많은 걸 무상으로 고치게 만든다. 경계선은 기간이 아니라 사양이 긋는다.

셋째, 돈이 나가는 계정이 발주처 명의인가. 저작권과 임치를 다 챙기고도 클라우드·스토어·PG 계정이 개발사 것이면 서비스 통제권은 넘어오지 않는다. 프로젝트 첫 주에 30분이면 정리되는 일이고, 관계가 끝난 뒤에 하면 두 달이 걸린다.