개발 산출물은 어디까지 제공해야 할까?

개발 산출물은 어디까지 제공해야 할까?

외주 개발 프로젝트가 끝나면 클라이언트는 개발 결과물을 전달받습니다. 하지만 어떤 자료까지 받아야 프로젝트가 완전히 인계된 것인지 판단하기는 쉽지 않습니다.

소스코드만 받으면 된다고 생각할 수 있지만 실제 서비스를 운영하려면 더 많은 정보가 필요합니다. 디자인 원본, 서버와 도메인 계정, 배포 방법, 관리자 사용법, 테스트 결과, 외부 서비스 설정 정보가 없으면 개발이 끝난 뒤에도 기존 개발사에 계속 의존할 수 있습니다.

반대로 개발사 입장에서는 계약에 없던 문서와 자료까지 프로젝트 종료 시점에 한꺼번에 요구받을 수 있습니다. 클라이언트가 당연히 포함된다고 생각한 산출물을 개발사는 별도 작업으로 판단하면서 갈등이 생기기도 합니다.

개발 산출물의 범위에는 모든 프로젝트에 적용되는 하나의 정답이 있는 것은 아닙니다. 프로젝트의 규모, 계약 방식, 기술 구조, 운영 주체에 따라 필요한 자료가 달라집니다.

중요한 것은 프로젝트가 끝난 뒤에 정하는 것이 아니라 계약과 착수 단계에서 제공할 산출물, 형식, 전달 시점, 소유권과 검수 기준을 합의하는 것입니다.

이번 글에서는 외주 개발 프로젝트에서 검토해야 할 주요 산출물과 안전한 인수인계를 위한 기준을 알아보겠습니다.

1. 개발 산출물은 완성된 화면만 의미하지 않습니다

클라이언트가 확인하는 최종 웹사이트나 앱은 개발 결과의 일부입니다. 실제 서비스가 작동하려면 코드, 서버, 데이터베이스, 외부 서비스, 디자인, 운영 정책이 함께 연결되어야 합니다.

따라서 개발 산출물은 프로젝트에서 만들어진 결과와 서비스를 운영하거나 수정하는 데 필요한 자료를 함께 의미할 수 있습니다.

대표적인 개발 산출물은 다음과 같습니다.

• 소스코드와 저장소
• 디자인 원본과 디자인 시스템
• 서버, 도메인, 클라우드 및 외부 서비스 계정
• 배포 및 개발 환경 설정 문서
• 데이터베이스 구조와 API 문서
• 관리자 및 운영 매뉴얼
• 테스트 결과와 알려진 이슈
• 요구사항, 기능 정의서, 화면 설계서

모든 프로젝트에 이 자료가 전부 필요한 것은 아닙니다. 그러나 어떤 항목을 제공하고 어떤 항목을 제공하지 않는지는 명확해야 합니다.

2. 소스코드는 어떤 형태로 전달해야 할까요?

소스코드는 대표적인 개발 산출물입니다. 하지만 압축 파일 하나를 전달하는 것만으로 충분하지 않을 수 있습니다.

프로젝트가 Git과 같은 버전 관리 저장소에서 개발되었다면 저장소 소유권이나 접근 권한을 어떻게 이전할지 정해야 합니다. 최종 코드가 어느 브랜치에 있는지, 실제 배포된 버전과 일치하는지도 확인해야 합니다.

소스코드 인계 시에는 아래 항목을 확인하는 것이 좋습니다.

• 프론트엔드, 백엔드, 관리자 등 전체 코드 저장소
• 최종 배포 버전을 식별할 수 있는 태그나 커밋
• 프로젝트 실행과 빌드 방법
• 필요한 라이브러리와 버전 정보
• 환경 변수의 항목과 설정 방법
• 외부 서비스 및 API 연결 위치
• 소스코드에 포함되지 않는 별도 구성 요소

비밀번호, API 키, 인증서 같은 민감한 정보는 소스코드에 직접 포함하지 않는 것이 좋습니다. 보안이 관리되는 별도 공간을 통해 전달하고, 프로젝트 종료 후 불필요한 접근 권한은 정리해야 합니다.

3. 디자인 파일은 원본과 사용 권한을 확인해야 합니다

개발이 완료된 화면만 있으면 디자인 산출물이 필요 없다고 생각할 수 있습니다. 하지만 서비스 운영 중 새로운 화면을 추가하거나 기존 디자인을 수정하려면 편집 가능한 원본 파일이 필요합니다.

디자인 산출물에는 다음 항목이 포함될 수 있습니다.

• 화면별 편집 가능한 디자인 원본
• 로고, 아이콘, 이미지 등 시각 자료
• 색상, 글꼴, 간격, 버튼 규칙이 포함된 디자인 시스템
• 반응형 화면과 모바일 디자인
• 사용자 흐름과 프로토타입
• 사용한 유료 글꼴과 이미지의 라이선스 정보

특히 외부에서 구매한 이미지, 아이콘, 글꼴, 템플릿은 클라이언트가 계속 사용할 수 있는 라이선스인지 확인해야 합니다. 파일을 전달받았다고 해서 모든 자료의 사용 권한까지 자동으로 이전되는 것은 아닐 수 있습니다.

4. 계정과 접근 권한은 클라이언트 소유로 정리해야 합니다

서비스 운영에 필요한 계정이 개발사 개인이나 개발사 명의로만 생성되어 있으면 프로젝트 종료 후 문제가 생길 수 있습니다. 담당자가 퇴사하거나 개발사와 연락이 끊기면 서버와 도메인에 접근하지 못할 수 있기 때문입니다.

아래와 같은 계정을 확인해야 합니다.

• 도메인 등록 및 DNS 관리 계정
• 클라우드 서버와 호스팅 계정
• 데이터베이스와 파일 저장소 계정
• 애플 및 구글 앱스토어 계정
• 결제, 문자, 이메일, 알림 서비스 계정
• 분석, 오류 추적, 모니터링 도구 계정
• 소스코드 및 디자인 저장소 계정

가능하면 프로젝트 초기부터 클라이언트 명의로 계정을 만들고 개발사에 필요한 권한을 부여하는 방식이 안전합니다.

이미 개발사 계정으로 운영했다면 종료 전에 소유권을 이전하거나 클라이언트를 최고 관리자로 등록해야 합니다. 비밀번호를 메신저에 그대로 보내기보다 안전한 비밀번호 관리 도구를 사용하는 것이 좋습니다.

5. 배포 문서가 있어야 다른 개발자가 서비스를 운영할 수 있습니다

소스코드를 받아도 실행하거나 배포하는 방법을 모르면 서비스 유지보수가 어렵습니다. 특정 개발자의 기억에만 의존하는 프로젝트는 담당자가 바뀌는 순간 운영 위험이 커집니다.

배포 및 환경 문서에는 아래 내용이 포함될 수 있습니다.

• 로컬 개발 환경을 구성하는 방법
• 테스트, 스테이징, 운영 환경의 구분
• 빌드와 배포 절차
• 서버, 데이터베이스, 스토리지의 구성
• 환경 변수와 비밀 정보의 관리 위치
• 정기 작업과 자동화 작업의 설정
• 장애 발생 시 로그와 상태를 확인하는 방법
• 배포 실패 시 복구 또는 롤백 방법

문서가 지나치게 길 필요는 없습니다. 다른 개발자가 문서를 보고 서비스를 실행하고 배포할 수 있을 정도로 핵심 절차와 구조가 정리되어야 합니다.

6. API와 데이터베이스 문서는 프로젝트에 따라 필요합니다

모바일 앱, 외부 서비스 연동, 여러 시스템 간 데이터 교환이 있는 프로젝트라면 API 문서가 중요합니다.

API 문서에는 주소, 요청 방식, 인증 방법, 입력값, 응답값, 오류 코드, 사용 예시 등이 포함될 수 있습니다. 외부 API에 의존한다면 사용 중인 버전과 발급 계정도 확인해야 합니다.

데이터베이스 문서에는 주요 테이블, 필드의 의미, 관계, 백업 방식, 개인정보가 저장되는 위치 등을 정리할 수 있습니다.

모든 데이터 구조를 상세하게 설명하는 문서가 반드시 필요한 것은 아닙니다. 다만 서비스의 핵심 데이터와 개인정보, 결제 및 주문처럼 운영에 중요한 구조는 인수인계할 필요가 있습니다.

7. 관리자와 운영 매뉴얼도 중요한 산출물입니다

서비스는 개발이 완료되었다고 자동으로 운영되지 않습니다. 클라이언트가 회원, 콘텐츠, 주문, 결제, 알림, 통계를 관리할 수 있어야 합니다.

관리자 및 운영 매뉴얼에는 아래 내용을 포함할 수 있습니다.

• 관리자 로그인과 권한 설정 방법
• 회원과 콘텐츠를 관리하는 방법
• 주문, 결제, 환불을 처리하는 방법
• 알림과 메시지를 발송하는 방법
• 데이터를 조회하고 내려받는 방법
• 운영 중 자주 발생하는 오류와 대응 방법
• 개발사에 문의해야 하는 상황

운영 매뉴얼은 화면을 캡처한 문서, 짧은 동영상, 온라인 가이드 등 프로젝트에 적합한 형태로 제공할 수 있습니다.

중요한 것은 문서 형식보다 실제 운영 담당자가 매뉴얼을 보고 필요한 업무를 수행할 수 있는지입니다.

8. 테스트 결과와 알려진 이슈를 함께 전달해야 합니다

프로젝트 종료 시 모든 문제가 완전히 사라지는 것은 아닙니다. 현재 버전에 영향을 주지 않는 제한사항이나 다음 단계에서 개선하기로 한 항목이 남을 수 있습니다.

이런 내용을 숨기기보다 테스트 결과와 알려진 이슈로 정리하는 것이 좋습니다.

테스트 관련 산출물에는 다음 항목이 포함될 수 있습니다.

• 테스트한 기능과 환경
• 주요 사용자 시나리오의 결과
• 발견된 오류와 수정 상태
• 남아 있는 알려진 이슈
• 지원하지 않는 기기나 브라우저
• 성능 또는 보안 점검 결과
• 클라이언트 검수 결과와 승인 기록

알려진 이슈는 단순한 결함 목록이 아닙니다. 클라이언트가 현재 서비스 상태를 이해하고 런칭 후 대응 우선순위를 정할 수 있도록 하는 자료입니다.

9. 산출물의 소유권과 사용 권한을 구분해야 합니다

파일을 전달받는 것과 법적인 권리를 이전받는 것은 같은 의미가 아닐 수 있습니다. 계약서에서 소스코드, 디자인, 문서, 데이터의 소유권과 사용 권한을 명확히 확인해야 합니다.

특히 아래 항목을 검토하는 것이 좋습니다.

• 개발비 지급 후 결과물의 권리가 누구에게 귀속되는지
• 개발사가 기존부터 보유한 공통 모듈의 사용 조건
• 오픈소스 라이브러리의 라이선스
• 유료 글꼴, 이미지, 플러그인의 사용 권한
• 클라이언트 데이터와 개인정보의 소유 및 처리 기준
• 개발사의 포트폴리오 공개 가능 여부

모든 권리를 무조건 이전해야 한다는 의미는 아닙니다. 프로젝트 특성에 맞게 권리 범위를 합의하고, 클라이언트가 서비스 운영에 필요한 권한을 확보하는 것이 중요합니다.

10. 산출물은 목록과 검수 기준으로 관리해야 합니다

프로젝트가 끝날 때 “자료를 모두 전달했습니다”라고 말하는 것만으로는 충분하지 않습니다. 어떤 파일이 전달되었고 클라이언트가 정상적으로 열고 사용할 수 있는지 확인해야 합니다.

산출물 목록에는 아래 내용을 기록할 수 있습니다.

• 산출물 이름과 설명
• 파일 형식 또는 저장 위치
• 최종 버전과 작성일
• 전달 예정일과 실제 전달일
• 담당자와 확인자
• 검수 상태와 보완 사항
• 소유권 또는 접근 권한 이전 상태

소스코드는 실행되는지, 디자인 파일은 편집할 수 있는지, 계정에 실제로 로그인할 수 있는지 확인해야 합니다. 문서가 존재하는지만 보는 것이 아니라 다음 담당자가 실제로 사용할 수 있는지를 검수해야 합니다.

개발 산출물 인수인계 체크리스트

1. 계약서와 견적서에 합의된 산출물 목록을 확인한다
2. 최종 배포 버전과 소스코드 버전이 일치하는지 확인한다
3. 디자인 원본과 외부 자료의 라이선스를 확인한다
4. 서버, 도메인, 스토어, 외부 서비스 계정의 소유권을 정리한다
5. 개발 환경과 배포 방법을 문서로 전달받는다
6. API와 핵심 데이터 구조를 확인한다
7. 관리자 및 운영 매뉴얼을 실제 담당자가 검토한다
8. 테스트 결과와 알려진 이슈를 확인한다
9. 각 산출물의 검수와 승인 상태를 기록한다
10. 불필요한 외부 접근 권한과 공유 링크를 정리한다

산출물 범위는 프로젝트가 끝나기 전에 합의해야 합니다

개발 산출물 분쟁은 프로젝트 종료 시점에 갑자기 생기는 것처럼 보이지만, 대부분 시작 단계의 합의 부족에서 비롯됩니다.

클라이언트는 운영에 필요한 모든 자료가 포함되어 있다고 생각하고, 개발사는 기능 구현만 계약 범위라고 생각할 수 있습니다.

따라서 견적과 계약 단계에서 산출물의 종류, 형식, 전달 시점, 소유권, 검수 기준을 정해야 합니다. 프로젝트 중간에 산출물이 추가되거나 변경된다면 그 내용도 변경 이력으로 남겨야 합니다.

산출물 전달과 검수도 프로젝트 흐름의 일부입니다

외주 개발은 기능을 완성하고 서버에 배포하는 것으로 끝나지 않습니다. 클라이언트가 결과물과 운영 권한을 안전하게 인계받고, 이후에도 서비스를 운영하고 개선할 수 있어야 프로젝트가 실질적으로 완료됩니다.

Pronika는 요구사항, 파일, 업무, 계정 관련 기록, 산출물, 검수 및 승인 내역을 하나의 프로젝트 흐름으로 연결할 수 있도록 돕습니다. 무엇을 언제 전달하고 누가 확인했는지 기록하면 프로젝트 종료 후에도 클라이언트와 개발사가 같은 근거를 확인할 수 있습니다.