외주로 만든 프로그램, 그 회사 아니면 아무도 못 고치는 상태 — 확인하는 법

외주 계약에서 소스코드 소유권을 챙기는 분은 많이 늘었습니다. 그런데 소스를 받고도 다음 해에 같은 업체를 다시 부르는 경우가 여전히 많습니다.

소스코드는 재료입니다. 재료가 있어도 조리 도구와 설명서가 없으면 요리는 안 됩니다. 프로그램도 같아서, 파일만으로는 다음 사람이 이어받지 못하는 상태가 존재합니다.

묶임은 악의에서만 오지 않습니다. 대부분은 넘겨줄 목록을 정해두지 않아서 생깁니다. 아래 다섯 가지를 납품 전에 확인하면 대부분 걸러집니다.

가장 흔합니다. 파일은 다 있는데 실행 파일로 만드는 절차가 그 업체 컴퓨터에만 있는 경우입니다.

특정 버전의 도구, 사내 저장소에만 있는 라이브러리, 손으로 넣어야 하는 설정값 — 이런 것이 문서로 안 남으면 다음 개발자는 첫날을 환경 맞추기로 다 씁니다. 견적이 올라가는 지점이 여기입니다.

확인 문장: "받은 소스만으로 처음부터 빌드하는 절차를 문서로 주시고, 제 컴퓨터에서 한 번 같이 돌려봐 주세요."

말로 "가능합니다" 를 듣는 것과 실제로 한 번 돌려보는 것은 다릅니다. 검수 항목에 넣으면 그 자리에서 드러납니다.

도메인, 서버, 결제사, 문자 발송, 지도 API, 앱스토어 — 프로그램 하나에도 계정이 여럿 붙습니다.

이 계정들이 업체 명의로 만들어져 있으면 소스코드와 무관하게 묶입니다. 서버를 옮기려 해도, 결제사를 바꾸려 해도 그 업체를 거쳐야 합니다. 업체가 폐업하면 되찾는 데 몇 달이 걸리기도 합니다.

확인 문장: "계정은 전부 저희 명의로 만들어 주시고, 목록과 접속 정보를 문서로 주세요."

이미 만들어졌다면 소유자 이전을 요청하면 됩니다. 대부분의 서비스가 소유권 이전 절차를 제공합니다.

코드에 주석이 하나도 없다는 뜻이 아닙니다. 왜 이 구조를 골랐는지가 남아 있느냐입니다.

정산 로직이 왜 이 순서인지, 이 예외 처리가 어떤 사고 때문에 생겼는지, 이 값이 왜 하드코딩됐는지 — 이런 맥락이 없으면 다음 사람은 건드리기를 두려워합니다. 두려우면 새로 만들자고 합니다. 그게 재개발 견적입니다.

확인 문장: "핵심 로직은 왜 그렇게 만들었는지 한 문단씩이라도 남겨 주세요."

분량보다 지점이 중요합니다. 돈이 오가는 계산, 외부 연동, 예외 처리 세 곳만 있어도 충분합니다.

널리 쓰이는 도구 대신 자체 제작 틀로 만든 경우입니다. 그 업체 개발자에게는 빠르지만, 다음 사람에게는 처음 보는 물건입니다.

자체 틀이 무조건 나쁘지는 않습니다. 다만 비용이 어디로 가는지는 알고 선택해야 합니다. 같은 기능을 흔한 방식으로 만들면 나중에 사람을 구하기 쉽고, 특수한 방식으로 만들면 그 업체가 유일한 선택지가 됩니다.

확인 문장: "어떤 기술로 만드시는지, 그 기술을 쓰는 개발자를 시장에서 구할 수 있는지 알려 주세요."

답을 들으면 선택이 됩니다. 안 물어보면 선택이 아니라 결과가 됩니다.

업체가 자기 서버에 올려주고 매달 관리비를 받는 구조입니다. 편하지만, 옮기려는 순간 묶여 있었다는 걸 알게 됩니다.

서버 설정이 문서로 없고, 데이터베이스 접근 권한이 없고, 백업이 업체 계정에만 있으면 이전이 사실상 불가능합니다.

확인 문장: "서버는 저희 계정에 만들고 권한을 주세요. 관리는 맡기더라도 소유는 저희여야 합니다."

관리를 맡기는 것과 소유를 넘기는 것은 다릅니다. 운영을 위탁해도 계정 주인은 발주처여야 합니다.

위 다섯 가지를 한 장으로 정리하면 이렇습니다. 계약서 별지나 검수 확인서에 그대로 넣으면 됩니다.

프리시는 이 목록을 계약 단계에서 먼저 드립니다. 납품 때 협상할 일이 아니라 시작할 때 정해둘 일이라고 보기 때문입니다. 소스코드와 계정은 처음부터 고객사 명의로 만들고, 만들어진 것은 전부 넘어갑니다.

묶이지 않는 것이 업체를 못 믿어서가 아닙니다. 다음 선택지를 남겨두는 것이 서로에게 낫습니다.