넘겨받을 수 있는 구조인가요 | 계약할 때 정해둘 이관 조건 6가지

먼저 짧게 답부터 드릴게요. “나중에 개발사를 바꿔야 할 때 서비스가 잘 넘어올까”는 헤어지는 순간에 결정되지 않아요. 만들기 시작할 때, 즉 계약·발주 단계에서 거의 다 정해져요. 소스코드를 받기로 적어둬도, 다른 사람이 그 소스로 빌드를 재현하지 못하면 실제로는 못 옮겨요. 그래서 ‘무엇을 받을지’만 적지 말고 ‘받은 걸로 혼자 돌릴 수 있는지’를 계약 조건으로 못 박아야 해요. 이 글은 발주 전에 정해둘 이관 조건 6가지를 정리했어요.

“계약서에 소스코드 넘겨준다고 적었으니 괜찮겠지.” 개발 외주를 맡길 때 흔히 이 선에서 안심해요. 그런데 몇 년 뒤 업체를 바꾸려고 하면, 소스는 받았는데 그걸로 서비스가 안 돌아가는 경우가 생각보다 많아요. 문제는 보통 ‘넘겨주느냐’가 아니라 ‘넘겨받은 걸로 돌릴 수 있느냐’에서 터져요. 이건 처음 계약할 때 어떻게 만들어 달라고 요구했는지에 달려 있어요.

1. 이관은 왜 ‘계약할 때’ 결정될까요

운영 이관이 되는 구조인지 아닌지는 코드를 어떻게 쌓았느냐, 계정을 누구 이름으로 열었느냐, 문서를 만들면서 남겼느냐에 달려 있어요. 이건 전부 개발이 진행되는 동안 쌓이는 거예요. 프로젝트가 끝난 뒤에 “이관 가능하게 해주세요”라고 하면, 없던 문서를 뒤늦게 만들고 계정을 옮기느라 추가 비용과 시간이 들어요.

그래서 이관은 ‘마지막 단계의 일’이 아니라 ‘처음부터 넣어두는 조건’으로 봐야 해요. 발주서나 계약서에 이관 가능성을 조건으로 적어두면, 개발사도 그 전제로 만들어요. 이 순서를 바꾸는 것만으로 나중에 겪는 분쟁이 크게 줄어요.

2. 소스코드 ‘양도’와 ‘빌드 재현’은 어떻게 다를까요

소스코드를 넘겨받는 것과 그 소스로 서비스를 다시 띄우는 것은 다른 일이에요. 요즘 서비스는 소스만 있다고 돌지 않아요. 어떤 버전의 도구로 빌드하는지, 어떤 설정값이 필요한지, 외부 서비스 키는 어떻게 넣는지가 함께 있어야 다른 사람이 재현할 수 있어요.

그래서 계약 조건에 “소스코드 제공”만 적지 말고, “제3자가 그 소스로 빌드와 배포를 재현할 수 있는 문서까지 포함”이라고 적어두세요. 이상적으로는 인수인계 전에 개발사가 아닌 사람이 한 번 그 문서대로 띄워보는 ‘재현 테스트’를 검수 조건에 넣는 거예요. 여기까지 해두면 “소스는 받았는데 안 돌아가요” 상황을 막을 수 있어요.

3. 계정과 명의는 처음부터 ‘우리 이름’인가요

서버, 도메인, 앱 스토어, 외부 서비스 계정이 개발사 이름으로 열려 있으면, 소스코드를 아무리 잘 받아도 실제 운영을 못 가져와요. 계정 안에 데이터와 설정이 들어 있는데 그 계정 주인이 개발사거든요.

가장 깔끔한 건 계약 초기에 발주사 명의로 계정을 만들고, 개발사는 거기에 작업자 권한으로만 들어오게 하는 거예요. 처음부터 이렇게 시작하면 나중에 옮기는 수고가 아예 없어요. 이미 개발사 명의로 진행 중이라면, 명의 이전 절차와 시점을 계약서에 적어두는 게 다음으로 좋아요.

4. 문서는 ‘끝나고’가 아니라 ‘만들면서’ 쌓였나요

운영 문서는 프로젝트가 끝난 뒤 몰아서 쓰면 부실해지기 쉬워요. 만들던 사람이 기억에 의존해 뒤늦게 적으니까요. 그래서 “완성 후 매뉴얼 제공”이 아니라 “개발 중 산출물로 운영 문서를 함께 갱신”을 조건으로 두는 게 좋아요.

꼭 필요한 문서는 세 가지예요. 어떻게 띄우고 배포하는지 적은 절차서, 장애가 났을 때 무엇부터 보는지 적은 대응 가이드, 외부 서비스와 계정 목록이에요. 이 세 가지가 있으면 새 업체가 와도 서비스가 멈추지 않고 이어져요.

5. 한 사람에게 권한이 몰려 있지 않나요

이관이 어려운 또 다른 이유는 권한이 한두 사람에게 몰려 있을 때예요. 그 사람이 자리를 비우거나 연락이 끊기면 아무도 손을 못 대요. 발주 단계에서 “접근 권한은 역할별로 나누고, 발주사도 최상위 관리자 권한을 하나 보유한다”를 정해두면 이 위험이 줄어요.

여기서 데이터표 하나로 정리해볼게요. ‘받는다고 생각하는 것’과 ‘실제로 받아야 하는 것’은 이렇게 달라요.

항목	받는다고 생각하는 것	실제로 받아야 넘어가는 것
소스코드	압축 파일 하나	빌드·배포 재현 문서 포함
계정	로그인 정보	발주사 명의 + 최상위 관리자 권한
문서	완성 후 매뉴얼	운영 중 갱신된 절차·대응 가이드
외부 서비스	연동됨	계정 목록 + 명의·결제 주체 확인

6. 계약서에는 어떤 문장으로 넣을까요

조건을 정했으면 계약서 문장으로 남겨야 효력이 있어요. 산출물 조항에 소스코드와 함께 “빌드·배포 재현 문서, 운영 절차서, 계정·외부 서비스 목록”을 명시하고, 검수 기준에 “제3자 재현 확인”을 넣어두세요. 이관 지원 기간도 적어두면 좋아요. 새 업체가 들어오는 동안 기존 개발사가 며칠 또는 몇 주간 질의에 답해주는 기간이에요.

참고로 소프트웨어 진흥법에서는 하자담보 책임 기간을 계약에서 따로 정하지 않으면 1년으로 봐요. 이관 지원과 하자보수는 별개이니, 두 기간을 각각 명확히 적어두는 게 다툼을 줄이는 길이에요.

용어 한 줄 정리 — 빌드(build): 소스코드를 실제로 돌아가는 프로그램으로 조립하는 과정이에요. 런북(runbook): 서비스를 띄우고 장애에 대응하는 절차를 적어둔 문서예요. 이관 지원 기간: 업체가 바뀔 때 기존 개발사가 질의 응답으로 도와주는 기간이에요.

7. 운영해본 개발사는 이관을 어떻게 볼까요

직접 서비스를 운영해본 개발사는 “언젠가 이 코드를 다른 사람이 받을 수도 있다”를 전제로 만들어요. 그래서 문서를 만들면서 쌓고, 계정 명의를 처음부터 정리하고, 권한을 나눠둬요. 이건 떠날 준비가 아니라, 발주사가 어느 상황에서도 서비스를 쥐고 있게 하는 기본기예요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하며 자체 SaaS 4종을 직접 운영해왔어요. 운영까지 해보면 “잘 넘겨받을 수 있는 구조”가 왜 처음부터 설계돼야 하는지 몸으로 알게 돼요. 개발 외주를 맡기기 전에 이관 조건을 어떻게 적을지 고민이라면, 운영까지 해본 회사와 함께 짚어봐요 →. 계약 전 실물로 확인할 항목은 지금 개발사와 헤어져도 서비스가 돌까요에, 구축에서 운영으로 넘길 때 다툼이 나는 지점은 구축 끝나고 운영으로 넘길 때 어디서 다툼이 날까요에 더 자세히 정리해뒀어요.

자주 묻는 질문

소스코드만 받으면 업체를 바꿀 수 있는 거 아닌가요?

소스코드는 필요 조건이지 충분 조건이 아니에요. 그 소스로 빌드와 배포를 재현할 문서, 계정, 설정값이 함께 있어야 실제로 옮겨져요. 계약서에 ‘제3자 재현 가능’까지 조건으로 넣는 게 안전해요.

이관 조건을 넣으면 개발비가 올라가나요?

문서화와 계정 정리에 약간의 손이 더 들 수는 있어요. 다만 나중에 이관이 안 돼서 겪는 재구축 비용에 비하면 훨씬 작아요. 처음부터 전제로 두면 추가 비용도 거의 생기지 않아요.

이미 진행 중인 프로젝트인데 지금이라도 할 수 있나요?

네, 지금부터라도 계정 명의 이전 시점을 합의하고, 운영 문서를 산출물로 추가하고, 재현 테스트를 검수에 넣으면 돼요. 끝난 뒤 몰아서 하는 것보다 지금 넣는 게 훨씬 수월해요.