노노니 | 실전 서비스 기획자의 인사이트 블로그

외주로 서비스를 개발할 때 소스코드 인수는 프로젝트 완료의 핵심 단계입니다. 외주 작업이 끝나면 개발된 서비스를 운영하고 개선하기 위해 모든 소스코드와 관련 자료를 제대로 받아야 합니다. 소스코드를 받지 못하거나 불완전하게 받으면 나중에 유지보수나 기능 추가가 불가능해질 수 있으므로, 어떤 형태로 무엇을 받아야 하는지 명확히 이해하는 것이 중요합니다.

 

소스코드 인수는 필수

외주 개발 후 소스코드를 받는 것이 정상입니다. 외주 작업의 원본 파일과 계정 정보, 각종 내용을 정리하여 완료 보고서와 함께 최종 산출물을 제출받고 이를 확인하여야 외주가 완료됩니다.

소스코드는 서비스를 구성하는 모든 프로그램 코드를 의미합니다. 프론트엔드 코드, 백엔드 코드, 데이터베이스 스키마, 설정 파일 등 서비스가 작동하는 데 필요한 모든 코드를 받아야 합니다. 이것들이 없으면 서비스를 수정하거나 개선할 수 없습니다.

 

깃허브 접근만으로는 부족

깃허브를 통하여 소스코드에 접근할 수 있어도 소스코드 전체를 제출받아야 합니다. 많은 분들이 깃허브 저장소에 접근 권한이 있으면 소스코드를 받은 것이라고 생각하시는데, 이것만으로는 충분하지 않습니다.

깃허브 저장소의 소유권이 외주사에게 있는 상태라면, 외주사가 언제든 저장소를 삭제하거나 접근 권한을 차단할 수 있습니다. 또한 깃허브 계정에 문제가 생기거나 외주사와 연락이 끊기면 소스코드에 접근할 수 없게 될 수 있습니다.

 

소스코드 제출 방식

최종 산출물의 목록에 소스코드를 명시하고 백업(zip) 형태 또는 발주자의 Git 저장소로의 이관으로 받을 수 있습니다. 두 가지 방식 모두 가능하며, 가능하면 둘 다 받는 것이 가장 안전합니다.

백업 파일로 받는 경우 모든 소스코드를 압축 파일로 만들어 제공받습니다. 이 파일은 발주자가 안전한 곳에 보관하면 되고, 필요할 때 언제든 압축을 풀어서 사용할 수 있습니다. 개발 히스토리는 포함되지 않지만 최종 버전의 완전한 코드를 보관할 수 있습니다.

 

깃허브 저장소 이관

발주자의 Git 저장소로 이관받는 방식은 더 권장됩니다. 외주사의 깃허브 계정에 있는 저장소를 발주자의 계정으로 소유권 이전(Transfer)하거나, 발주자 계정에 새 저장소를 만들어 모든 코드와 커밋 히스토리를 복사하는 방법입니다.

이렇게 하면 누가 언제 어떤 코드를 작성했는지, 어떤 기능이 어떻게 개발되었는지 모든 히스토리를 확인할 수 있습니다. 나중에 버그를 추적하거나 과거 버전으로 되돌려야 할 때 이 히스토리가 매우 유용합니다.

 

프로젝트 시작부터 발주자 계정 사용

가장 이상적인 방법은 프로젝트 시작 시점부터 발주자의 깃허브 계정에 저장소를 만들고 외주사에게 접근 권한만 부여하는 것입니다. 이렇게 하면 처음부터 모든 소스코드가 발주자 소유이므로 프로젝트 완료 시 별도로 이관받을 필요가 없습니다.

 

완료 보고서의 중요성

외주 작업이 완료되면 외주사는 완료 보고서를 제출해야 합니다. 완료 보고서에는 사용된 기술 스택, 서버 환경 정보, 데이터베이스 구조, API 문서, 알려진 이슈와 제한사항 등이 포함됩니다.

이 보고서는 나중에 다른 개발자가 프로젝트를 이어받을 때 매우 중요한 참고 자료가 됩니다. 소스코드만 받아서는 전체 구조와 작동 원리를 이해하기 어려울 수 있으므로, 상세한 문서와 함께 받는 것이 중요합니다.

 

최종 산출물 목록

최종 산출물로 받아야 할 것들의 목록을 만들어 계약서나 회의록에 명시해두세요. 소스코드 전체, 데이터베이스 백업 파일, 환경 변수 설정 파일, API 문서, 사용자 매뉴얼, 관리자 매뉴얼, 서버 설정 문서, 외부 서비스 계정 정보, 도메인 및 호스팅 계정 정보 등이 포함됩니다.

각 항목에 대해 어떤 형식으로 제공될 것인지도 명시하세요. 예를 들어 "소스코드는 발주자 깃허브 저장소로 이관 및 zip 백업 파일 제공", "API 문서는 PDF 또는 마크다운 형식" 같은 식으로 구체적으로 정하면 좋습니다.

 

계정 정보 인수

소스코드뿐만 아니라 프로젝트와 관련된 모든 계정 정보도 받아야 합니다. 깃허브 저장소 소유권, AWS나 클라우드 서비스 계정, 데이터베이스 접속 정보, 도메인 관리 계정, 결제 서비스 계정, 문자 발송 서비스 계정, 이메일 서비스 계정 등입니다.

계정 정보를 받을 때는 단순히 아이디와 비밀번호만 받는 것이 아니라, 계정의 소유자 이메일을 발주자의 이메일로 변경하고 결제 정보도 발주자의 것으로 바꿔야 합니다. 외주사의 계정으로 남아있으면 나중에 접근이 차단될 위험이 있습니다.

 

백업의 중요성

소스코드를 받은 후에는 백업해두세요. 소스코드는 서비스의 핵심 자산입니다. 이것이 유실되면 서비스를 운영할 수 없고, 처음부터 다시 개발해야 하는 최악의 상황이 올 수 있습니다.

정기적으로 백업 상태를 확인하고, 백업 파일이 실제로 복구 가능한지 테스트해 보는 것도 좋습니다.

 

문서화 요청

소스코드와 함께 충분한 문서를 받으세요. 개발 환경, 주요 함수와 모듈 설명, 데이터베이스 테이블 구조 등이 문서화되어 있으면 나중에 유지보수하기 훨씬 쉽습니다.

문서가 부족하면 외주사에게 추가 작성을 요청하세요. 개발한 사람이 직접 작성한 문서가 가장 정확하고 유용합니다. 나중에 다른 개발자가 소스코드를 분석하며 문서를 만드는 것보다 처음부터 제대로 된 문서를 받는 것이 훨씬 효율적입니다.