외주 개발 완료 시 받아야 할 산출물 체크리스트

웹사이트나 웹서비스 개발이 완료되면 화면과 기능을 검수한 뒤 프로젝트를 종료하게 됩니다.

이때 서비스가 정상적으로 작동한다는 이유만으로 인계가 모두 끝났다고 생각하기 쉽습니다.

하지만 실제 운영과 유지보수를 위해서는 완성된 화면 외에도 여러 자료와 계정이 필요합니다.

• 소스코드
• 데이터베이스
• 서버 계정
• 도메인
• 관리자 계정
• 외부 API
• 디자인 원본
• 운영 문서
• 백업
• 알려진 문제

이 자료를 받지 못하면 다음과 같은 상황에서 문제가 생길 수 있습니다.

• 다른 개발 업체로 유지보수를 변경함
• 내부 개발자가 기능을 추가함
• 서버를 이전함
• 업체와 연락이 되지 않음
• 장애 후 서비스를 복구함
• 외부 API 키를 변경함
• 담당자가 퇴사함
• 관리자 사용법을 잊어버림

따라서 외주 개발 완료 기준에는 기능 검수뿐 아니라 서비스를 독립적으로 운영할 수 있는 상태로 인계받는 과정이 포함되어야 합니다.

산출물 범위는 계약 전에 정해야 합니다

프로젝트가 끝난 뒤 갑자기 소스코드나 디자인 원본을 요청하면 계약 범위에 포함되지 않았다는 답을 받을 수 있습니다.

개발 시작 전에 다음 내용을 정하는 것이 좋습니다.

• 어떤 산출물을 받을 것인가?
• 어느 시점에 받을 것인가?
• 어떤 파일 형식으로 받을 것인가?
• 편집 가능한 원본도 포함되는가?
• 소스코드 사용·수정 권한은 어떻게 되는가?
• 계정은 누구 명의로 생성하는가?
• 데이터는 어떤 방식으로 인계하는가?
• 운영 문서를 어느 수준으로 제공하는가?

견적서나 계약서에 산출물 목록을 부속 문서로 첨부할 수도 있습니다.

1. 전체 소스코드

맞춤 개발 프로젝트라면 실제 운영 중인 최신 소스코드를 확보해야 합니다.

프로젝트에 따라 다음 코드가 분리되어 있을 수 있습니다.

• 사용자 웹 프론트엔드
• 백엔드 API
• 관리자 페이지
• 배치·자동화
• 크롤링
• AI 처리
• 인프라 설정
• 모바일 앱
• 공통 라이브러리

소스코드를 받을 때는 단순한 압축 파일보다 Git 저장소 권한을 함께 받는 것이 좋습니다.

소스코드에서 확인할 항목

• 실제 운영 버전과 같은가?
• 최신 변경 사항이 반영됐는가?
• 프론트엔드와 백엔드가 모두 있는가?
• 관리자 페이지가 포함됐는가?
• 자동화 작업 코드가 포함됐는가?
• 빌드할 수 있는가?
• 실행 방법이 있는가?
• Git 이력이 있는가?
• 테스트 코드가 있다면 포함됐는가?
• 비밀정보가 코드에 노출되지 않았는가?

Git 저장소 권한

가능하면 의뢰사 소유의 GitHub 또는 GitLab 조직에 저장소를 두는 것이 좋습니다.

확보할 항목은 다음과 같습니다.

• 저장소 최고 관리자 권한
• 기본 브랜치
• 운영 배포 브랜치
• 버전 태그
• 커밋 이력
• Issues 또는 작업 기록
• 배포 자동화 설정
• 패키지와 비밀값 관리 위치

개발 업체 계정에 저장소가 있다면 의뢰사 계정으로 이전하거나 복제본을 만들어야 합니다.

2. 실행과 설치 문서

소스코드가 있어도 실행 방법을 모르면 다른 개발자가 이어서 작업하기 어렵습니다.

문서에는 다음 내용을 포함할 수 있습니다.

• 필요한 운영체제
• Node.js·PHP·Python 등 버전
• 라이브러리 설치 방법
• 개발 서버 실행 명령
• 빌드 명령
• 데이터베이스 연결 방법
• 환경변수 설정
• 초기 데이터 생성
• 테스트 계정
• 자주 발생하는 오류

간단한 README.md 파일로도 정리할 수 있습니다.

실행 문서 예시

1. Node.js 20 설치
2. 저장소 내려받기
3. npm install 실행
4. .env.example을 복사해 .env 생성
5. 데이터베이스 연결 정보 입력
6. npm run dev로 개발 서버 실행
7. localhost:3000 접속

프로젝트 구조가 복잡하다면 서비스별 실행 순서도 필요할 수 있습니다.

3. 환경변수 목록

환경변수에는 서비스 운영에 필요한 설정이 들어갑니다.

• 데이터베이스 주소
• 서버 주소
• 결제 API 키
• 이메일 API 키
• 알림톡 키
• 소셜 로그인 키
• AI API 키
• 파일 저장소 정보
• 암호화 키
• 관리자 설정

실제 비밀값과 함께 각 항목의 용도도 정리하는 것이 좋습니다.

DATABASE_URL:
운영 데이터베이스 연결 주소

PAYMENT_SECRET_KEY:
결제 승인과 취소에 사용

EMAIL_API_KEY:
인증 메일과 알림 메일 발송에 사용

환경변수는 일반 문서나 공개 저장소에 올리지 않고 안전한 비밀번호 관리 도구 등을 이용해 전달하는 것이 좋습니다.

4. 데이터베이스

회원, 주문, 문의, 콘텐츠와 업무 데이터가 저장되는 핵심 자산입니다.

다음 자료가 필요할 수 있습니다.

• 데이터베이스 접속 정보
• 데이터베이스 백업 파일
• 테이블 구조
• 마이그레이션 파일
• 초기 데이터
• 데이터 관계 설명
• 백업과 복구 방법
• 개인정보 저장 항목

데이터베이스 인계 시 확인할 것

• 최신 운영 데이터인가?
• 백업 파일을 실제로 복구할 수 있는가?
• 개인정보가 안전하게 전달되는가?
• 테스트 데이터와 운영 데이터가 구분되는가?
• 암호화된 데이터의 키가 있는가?
• 자동 백업이 설정되어 있는가?
• 데이터 보존·삭제 정책이 있는가?

단순한 접속 비밀번호만 받기보다 독립된 백업 파일도 확보하는 것이 안전합니다.

5. 사용자 업로드 파일과 저장소

사용자가 올린 이미지와 첨부파일은 데이터베이스가 아니라 별도 저장소에 있을 수 있습니다.

• AWS S3
• Cloudflare R2
• 서버 디스크
• CDN
• 외부 이미지 서비스
• 워드프레스 미디어 폴더

확보할 항목은 다음과 같습니다.

• 저장소 계정
• 버킷 이름
• 접근 권한
• 파일 백업
• 공개·비공개 설정
• 용량과 비용
• 삭제 정책
• 파일 URL 구조

소스코드와 데이터베이스만 받아서는 파일까지 복구하지 못할 수 있습니다.

6. 서버와 클라우드 계정

서비스가 운영되는 인프라 정보를 받아야 합니다.

• AWS
• Google Cloud
• Microsoft Azure
• Naver Cloud
• 가비아
• 카페24
• Vercel
• Netlify
• 기타 호스팅

서버 인계 항목

• 최고 관리자 계정
• 사용자·역할 권한
• 서버 인스턴스
• 데이터베이스
• 파일 저장소
• 네트워크
• 방화벽
• 도메인 연결
• SSL
• 백업
• 로그
• 모니터링
• 월 비용
• 결제 수단

의뢰사 계정에 서버를 구축했다면 개발 업체의 접근 권한을 프로젝트 종료 후 재점검해야 합니다.

7. 배포 문서

새로운 개발자가 코드를 수정한 뒤 운영 서버에 반영할 수 있어야 합니다.

배포 문서에는 다음 내용이 포함될 수 있습니다.

• 개발·테스트·운영 환경
• 배포 명령
• Git 브랜치
• 자동 배포 조건
• 환경변수 위치
• 데이터베이스 마이그레이션
• 배포 전 백업
• 배포 후 확인 항목
• 문제가 생겼을 때 되돌리는 방법

배포 체크리스트 예시

1. 운영 데이터베이스 백업
2. 변경 코드 검수
3. 운영 브랜치 병합
4. 데이터베이스 마이그레이션
5. 운영 서버 배포
6. 로그인·결제·관리자 확인
7. 오류 로그 점검
8. 문제 발생 시 이전 버전 복구

운영 서버에서 코드를 직접 수정하는 방식은 피하는 것이 좋습니다.

8. 도메인과 DNS

홈페이지 주소와 이메일, 외부 서비스 인증에 필요한 정보입니다.

• 도메인 관리 계정
• 등록자 명의
• 만료일
• 결제 수단
• DNS 설정
• 서브도메인
• 회사 이메일 설정
• 외부 서비스 인증값

DNS 전체 설정을 화면 캡처나 문서로 백업해 두는 것이 좋습니다.

9. SSL 인증서

HTTPS 연결에 필요한 설정입니다.

• 인증서 종류
• 발급 방법
• 만료일
• 자동 갱신
• 갱신 담당자
• 서버 설정

무료 인증서라도 자동 갱신이 정상적으로 작동하는지 확인해야 합니다.

10. 관리자 페이지 계정

운영자가 사용하는 최고 관리자 계정을 받아야 합니다.

• 관리자 주소
• 최고 관리자 ID
• 비밀번호 재설정 방법
• 2단계 인증
• 관리자 역할
• 테스트 계정
• 퇴사자·개발자 계정
• 권한별 접근 범위

업체 이메일로 만들어진 최고 관리자 계정은 회사 이메일로 변경하는 것이 좋습니다.

11. 외부 API와 서비스 계정

서비스가 연결된 모든 외부 도구를 목록으로 정리해야 합니다.

• 결제
• 이메일
• 문자
• 알림톡
• 소셜 로그인
• 지도
• AI API
• 채팅 상담
• 분석 도구
• CRM
• ERP
• 공공 데이터
• Notion
• Google Sheets

외부 서비스별 인계 항목

• 서비스명
• 계정 소유자
• 관리자 URL
• API 키
• 월 비용
• 결제 수단
• 사용량
• 갱신일
• 허용 도메인
• 콜백 URL
• 웹훅 URL
• 담당자
• 장애 문의처

API 키는 프로젝트 종료 후 필요에 따라 재발급하는 것이 안전합니다.

12. 결제 서비스 자료

결제가 있는 서비스라면 특히 꼼꼼하게 인계해야 합니다.

• PG 관리자 계정
• 상점 ID
• 운영·테스트 API 키
• 결제 웹훅
• 정산 계좌
• 환불 권한
• 정기결제 구조
• 결제 실패 처리
• 테스트 카드·계정
• 심사 관련 문서

실제 결제와 환불을 회사 담당자가 직접 처리할 수 있는지 확인해야 합니다.

13. 이메일·문자·알림톡 설정

• 발신 이메일
• 발신번호
• 알림톡 채널
• 승인된 템플릿
• 이메일 템플릿
• 발송 조건
• 실패 시 처리
• 발송 내역 확인
• 월 사용료

인계 후 테스트 메시지를 직접 발송해 보는 것이 좋습니다.

14. 소셜 로그인 계정

• 카카오 개발자 앱
• 네이버 개발자 앱
• Google Cloud 프로젝트
• Apple 로그인
• 허용 도메인
• Redirect URI
• 동의 항목
• 비즈니스 인증
• 앱 소유권

프로젝트 종료 후 개발 업체 개인 계정에만 앱이 남아 있지 않은지 확인해야 합니다.

15. 디자인 원본

프로젝트에서 디자인을 제작했다면 편집 가능한 원본 제공 여부를 확인합니다.

• Figma
• Adobe XD
• Photoshop
• Illustrator
• 로고
• 아이콘
• 이미지 원본
• 디자인 시스템
• 폰트 정보
• 애니메이션 원본

Figma라면 단순 보기 권한이 아니라 파일 복제와 편집이 가능한 권한이 필요할 수 있습니다.

16. 콘텐츠 원본

• 홈페이지 문구
• 번역본
• 제품 정보
• 포트폴리오
• 이미지
• 영상
• 첨부파일
• 개인정보처리방침
• 이용약관

관리자에 입력된 콘텐츠 외에도 원본 파일을 별도로 보관하는 것이 좋습니다.

17. 라이선스 목록

다음 자산에는 별도 사용 조건이 있을 수 있습니다.

• 유료 폰트
• 스톡 이미지
• 아이콘
• 워드프레스 플러그인
• 테마
• 차트 라이브러리
• PDF 도구
• 지도
• 영상·음원
• 오픈소스

라이선스 문서에 포함할 내용

• 자산명
• 구매자
• 구매 계정
• 사용 가능 범위
• 사용 도메인
• 갱신일
• 연간 비용
• 이전 가능 여부
• 대체 필요 여부

업체 라이선스를 빌려 사용했다면 계약 종료 후 계속 사용할 수 있는지 확인해야 합니다.

18. 요구사항과 기능 문서

• 최종 기능 목록
• 사용자 유형
• 권한
• 사용자 흐름
• 관리자 업무
• 외부 API
• 포함·제외 범위
• 변경 이력
• 완료 기준

처음 작성한 기획서보다 실제 최종 결과에 맞게 업데이트된 문서가 중요합니다.

19. API 문서

백엔드 API가 있다면 다음 정보가 필요할 수 있습니다.

• API 주소
• 요청 방식
• 인증
• 입력값
• 응답값
• 오류 코드
• 권한
• 테스트 방법
• 호출 제한

Swagger나 Postman Collection 형태로 제공할 수도 있습니다.

20. 관리자 사용 설명서

운영 담당자가 실제 업무를 수행할 수 있도록 문서를 제공받는 것이 좋습니다.

• 로그인
• 회원 조회
• 콘텐츠 등록
• 이미지 업로드
• 주문·결제 확인
• 환불
• 통계
• 엑셀 다운로드
• 관리자 계정
• 오류 발생 시 연락 방법

문서와 함께 화면 공유 방식으로 인계 교육을 진행할 수도 있습니다.

21. 운영 매뉴얼

관리자 사용법보다 더 넓은 서비스 운영 절차입니다.

• 신규 회원 처리
• 결제 실패 처리
• 환불
• 문의 처리
• 데이터 수정
• 정기 작업
• 백업
• 장애 대응
• 외부 API 문제
• 개인정보 삭제
• 계약 만료 서비스

개발 업체만 알고 있던 수동 작업이 있다면 반드시 문서화해야 합니다.

22. 테스트 계정과 검수 기록

• 일반 회원
• 기업 회원
• 관리자
• 최고 관리자
• 결제 테스트 계정
• 권한별 테스트 계정
• QA 체크리스트
• 해결된 오류
• 미해결 오류
• 검수 승인 기록

테스트 계정에 실제 개인정보가 포함되지 않도록 주의해야 합니다.

23. 알려진 문제와 제한사항

모든 서비스를 완벽한 상태로 만들기는 어렵습니다.

다음 내용을 솔직하게 인계받는 것이 좋습니다.

• 아직 해결하지 않은 오류
• 특정 브라우저 제한
• 수동으로 처리하는 업무
• 대용량 데이터 제한
• 외부 API 제약
• 향후 개선 권장 사항
• 기술 부채
• 곧 만료되는 서비스

이 정보가 없으면 새 운영자나 개발자가 같은 문제를 다시 분석해야 합니다.

24. 백업과 복구 자료

• 소스코드 백업
• 데이터베이스 백업
• 파일 백업
• 백업 주기
• 저장 위치
• 보관 기간
• 복구 방법
• 복구 테스트 결과

백업 파일이 존재한다는 것보다 실제로 복구 가능한지가 더 중요합니다.

25. 계정과 권한 목록

모든 계정을 하나의 표로 정리하는 것이 좋습니다.

최종 인계 절차

1. 산출물 목록 확인

계약서와 실제 제공 자료를 비교합니다.

2. 계정 소유권 확인

의뢰사가 최고 관리자 또는 소유자 권한을 갖는지 확인합니다.

3. 인계 미팅

개발 업체가 다음 내용을 설명합니다.

• 전체 구조
• 배포
• 관리자
• 외부 API
• 정기 작업
• 알려진 문제

4. 독립 실행 확인

가능하다면 다른 개발 환경에서 소스를 실행해 봅니다.

5. 백업 복구 테스트

데이터베이스와 파일을 실제로 복구할 수 있는지 확인합니다.

6. 운영 기능 테스트

• 로그인
• 관리자
• 결제
• 이메일
• 알림
• 파일
• 핵심 기능

7. 접근 권한 정리

유지보수에 필요하지 않은 개발 업체 계정과 API 키를 정리합니다.

전체 산출물 체크리스트

[ ] 프론트엔드 소스
[ ] 백엔드 소스
[ ] 관리자 소스
[ ] 자동화·배치 코드
[ ] Git 저장소 권한
[ ] 실행 문서
[ ] 빌드 문서
[ ] 환경변수 목록
[ ] 데이터베이스 접속
[ ] 데이터베이스 백업
[ ] 데이터 구조
[ ] 업로드 파일
[ ] 서버 계정
[ ] 배포 문서
[ ] 도메인
[ ] DNS
[ ] SSL
[ ] 관리자 계정
[ ] 외부 API 목록
[ ] 결제 계정
[ ] 이메일·알림 계정
[ ] 소셜 로그인 계정
[ ] 분석·검색 도구
[ ] 디자인 원본
[ ] 콘텐츠 원본
[ ] 라이선스 목록
[ ] 최종 기능 문서
[ ] API 문서
[ ] 관리자 매뉴얼
[ ] 운영 매뉴얼
[ ] 테스트 계정
[ ] QA 기록
[ ] 알려진 문제
[ ] 백업·복구 방법
[ ] 전체 계정 목록

마무리

외주 개발 프로젝트의 완료는 화면과 기능이 작동하는 것만을 의미하지 않습니다.

의뢰사가 독립적으로 서비스를 운영하고, 필요할 때 다른 개발자가 이어서 관리할 수 있는 상태까지 인계되어야 합니다.

특히 다음 항목은 반드시 확인하는 것이 좋습니다.

• 최신 소스코드
• 데이터베이스와 파일
• 서버·도메인 계정
• 외부 API와 결제 계정
• 실행·배포·운영 문서
• 관리자 사용 방법
• 백업과 복구
• 알려진 문제

산출물 목록을 프로젝트 종료 시점에 처음 논의하기보다 견적과 계약 단계에서 미리 합의해야 합니다.