외주개발 인수인계 체크리스트: 소스코드·서버·DB·배포·운영문서까지 확인할 것 > 인사이트

본문 바로가기

인사이트

#외주개발

외주개발 인수인계 체크리스트: 소스코드·서버·DB·배포·운영문서까지 확인할 것

결론부터 말하면, 외주개발 인수인계의 기준은 ‘완성된 화면을 확인했다’가 아니라 ‘발주사 계정으로 새 담당자가 실행·배포·복구·운영할 수 있다’입니다. 최소한 소스코드 저장소, 클라우드와 도메인 소유권, 환경변수와 API 키, DB 구조와 백업, CI/CD 배포 절차, 관리자 권한, 운영 런북, 유지보수 범위를 한 번에 확인해야 합니다.

외주개발 인수인계를 위해 노트북 화면의 코드 저장소와 서버 대시보드를 확인하는 업무 장면
외주개발 인수인계는 완성 화면이 아니라 운영 권한과 재현 가능성까지 확인하는 절차입니다.

외주사가 개발 완료라고 말하는 순간, 창업자와 PM은 보통 화면 검수에 집중합니다. 회원가입이 되는지, 결제가 되는지, 관리자 페이지에서 데이터가 보이는지 확인합니다. 물론 기능 검수는 중요합니다. 다만 실제 운영 단계에서는 더 위험한 문제가 뒤늦게 드러납니다. Git 저장소는 받았는데 최신 운영 코드가 아니거나, 서버가 외주사 명의 계정에 남아 있거나, 배포 키와 결제 웹훅 시크릿을 외주사만 알고 있거나, DB 백업은 있지만 복구 방법이 없는 상황입니다.

특히 웹·앱 MVP, SaaS 프로토타입, 예약·매칭·결제 서비스, CRM, 관리자 대시보드, AI API 연동 서비스는 화면보다 보이지 않는 연결이 많습니다. 프론트엔드, 백엔드, DB, 스토리지, 문자·메일·카카오 알림, PG 결제, OAuth 로그인, 배치 작업, 자동화 워크플로, AI 모델 호출 비용까지 얽혀 있기 때문입니다. 따라서 인수인계는 최종 납품의 부속 절차가 아니라 운영 리스크를 줄이는 별도 프로젝트로 보아야 합니다.

1. 인수인계의 합격 기준: 문서만 보고 새 사람이 운영할 수 있는가

인수인계 완료 = 최신 코드가 발주사 소유 저장소에 있고, 발주사 명의 인프라에서, 문서만 보고 빌드·배포·장애 대응·백업 복구를 수행할 수 있는 상태.

외주개발에서 가장 흔한 착각은 소스코드 압축 파일을 받으면 충분하다고 보는 것입니다. 하지만 운영 가능한 서비스는 코드만으로 구성되지 않습니다. 운영 서버의 환경변수, DB 마이그레이션, 배포 권한, 스토리지 버킷, 도메인 DNS, SSL 인증서, 관리자 계정, 로그 확인 위치, 장애 시 연락 체계가 함께 있어야 합니다.

GitHub 문서에서도 저장소는 다른 사용자나 조직 계정으로 이전할 수 있고, 조직 저장소에는 역할별 권한을 줄 수 있습니다. 실무적으로는 개인 계정보다 발주사 조직 계정을 만들고 그 안에 저장소, 팀, 권한을 정리하는 방식이 이후 내부 개발자 채용이나 업체 변경에 유리합니다. ([docs.github.com](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository?apiVersion=2022-11-28&utm_source=openai))

외주개발 인수인계 수준을 비교하는 대시보드와 체크 테이블
좋은 인수인계는 화면 확인이 아니라 재배포와 복구 가능성으로 판단합니다.
인수 수준상태운영 리스크판단
Level 0화면과 기능만 확인개발사가 사라지면 운영 구조를 알 수 없음검수 전 단계
Level 1소스코드와 서버 접속 정보 일부 수령빌드 실패, 배포 실패, 권한 누락 가능불완전 인수
Level 2새 담당자가 문서만 보고 로컬 실행, 스테이징 배포, DB 복구 테스트 가능업체 변경과 내부 개발자 인계 가능운영 가능한 인수

2. 인수인계는 잔금 직전이 아니라 계약 단계에서 정해야 한다

인수인계 문제는 대부분 개발이 끝난 뒤 발견되지만, 원인은 계약과 범위 정의 단계에 있습니다. 산출물 목록에 소스코드만 적혀 있고 서버, DB, 배포 문서, 외부 API 계정, 관리자 매뉴얼이 빠져 있으면 외주사는 화면 구현을 납품으로 볼 수 있습니다. 발주사는 운영 가능한 서비스를 기대했는데, 계약서에는 운영 전환 기준이 없는 것입니다.

따라서 계약 전에는 산출물 표를 따로 만들어야 합니다. 소스코드, 디자인 파일, DB 스키마, API 문서, 관리자 매뉴얼, 배포 문서, 서버 구성도, 외부 서비스 계정 목록, 유지보수 범위를 항목별로 적고 검수 기준을 붙입니다. 계약 조항 정리가 필요하다면 외주개발 계약서 필수 조항 체크리스트를 함께 참고하는 것이 좋습니다.

계약 시점에 정할 것왜 필요한가예시
최종 산출물 목록납품 범위 분쟁 방지Git 저장소, Figma, ERD, API 문서, 배포 문서
소유권·사용권 범위후속 개발과 업체 변경 가능성 확보소스코드 사용권, 재사용 제한, 오픈소스 고지
인수인계 검수 조건화면 검수가 아닌 운영 검수 기준 확보새 환경 실행, 스테이징 배포, DB 복구 테스트
잔금 지급 조건인수인계 누락 방지최종 검수와 권한 이전 완료 후 지급
유지보수 범위버그 수정과 기능 변경의 경계 설정하자보수, 서버 장애, 외부 API 변경 대응

단, 소스코드 저작권과 지식재산권은 계약 문구에 따라 해석이 달라질 수 있습니다. 이 글은 법률 자문이 아니라 운영 관점의 체크리스트입니다. 중요한 서비스라면 계약서 작성 단계에서 법률 검토를 병행하는 편이 안전합니다.

3. 소스코드와 Git 저장소 체크리스트

첫 번째 확인 대상은 최신 소스코드입니다. 여기서 최신이라는 말은 단순히 파일 날짜가 최근이라는 뜻이 아닙니다. 현재 운영 서버에 배포된 코드와 연결되는 커밋, 브랜치, 태그, 빌드 방법이 확인되어야 합니다.

체크 항목확인 질문받아야 할 산출물
저장소 소유권개인 계정이 아니라 발주사 조직 계정으로 이전됐는가?GitHub, GitLab, Bitbucket 저장소 관리자 권한
최신 커밋운영 서버에 배포된 커밋 SHA가 무엇인가?운영 버전 태그, 릴리즈 노트
브랜치 전략main, develop, staging, hotfix 기준이 있는가?브랜치 규칙 문서
실행 문서새 노트북에서 README만 보고 실행되는가?README, 설치 명령, 의존성 버전
의존성 고정패키지 버전이 잠금 파일로 관리되는가?package-lock, yarn.lock, pnpm-lock, requirements, poetry.lock 등
마이그레이션DB 구조 변경 이력이 코드로 남아 있는가?migration 파일, seed 데이터
라이선스상용 사용이 제한되는 라이브러리가 있는가?오픈소스 사용 목록, 라이선스 메모
빌드 산출물빌드 결과물이 어디서 생성되고 배포되는가?빌드 스크립트, Dockerfile, 배포 설정

주의할 점은 ZIP 파일만 받는 방식입니다. ZIP은 커밋 이력, 브랜치, 변경 이유, 리뷰 기록을 잃어버립니다. 예외적으로 내부 보안 정책상 Git을 사용할 수 없다면 별도 형상관리 방식이라도 있어야 합니다. 그러나 대부분의 스타트업과 SaaS 서비스라면 발주사 조직 저장소로 직접 이전받는 편이 안전합니다.

4. 서버·클라우드·도메인 권한 이관 체크리스트

서비스가 실제로 운영되는 곳은 코드 저장소가 아니라 서버와 클라우드입니다. AWS, Google Cloud, Azure, Naver Cloud, Cafe24, Vercel, Render, Supabase, Firebase 등 어떤 플랫폼을 쓰든 핵심은 하나입니다. 결제와 관리자 권한이 발주사에 있어야 합니다.

영역필수 확인 사항누락 시 위험
클라우드 계정루트 계정, 결제 수단, 조직 관리자 권한, MFA업체 변경 시 서버 통제 불가
서버 리소스인스턴스, 컨테이너, 서버리스 함수, 로드밸런서, 스토리지 목록비용 추적과 장애 대응 불가
도메인·DNS도메인 소유자, DNS 레코드, CDN, SSL 인증서사이트 중단, 인증서 만료, 메일 발송 장애
스토리지이미지, 첨부파일, 로그, 백업 저장 위치와 권한파일 손실, 개인정보 노출
네트워크방화벽, 보안그룹, IP 허용 목록, VPC 구조접속 장애 또는 과도한 노출
스케줄러cron, queue worker, batch job, webhook 재시도 구조정산, 알림, 자동화 작업 누락
비용월 예상 비용, 비용 알림, 사용량 급증 지점예상치 못한 클라우드 과금

외주사 명의 서버를 그대로 쓰는 경우가 있습니다. 초기에는 편해 보이지만 장기적으로는 위험합니다. 외주사가 비용을 미납하거나 계정을 정리하거나 담당자가 퇴사하면 발주사가 복구할 방법이 제한됩니다. 최소한 운영 전에는 발주사 명의 계정으로 이전하고, 외주사는 필요한 범위의 IAM 사용자나 협업 권한만 받도록 구성해야 합니다.

5. 환경변수, API 키, 시크릿은 별도 인수인계가 필요하다

현대 웹서비스는 코드 안에 모든 설정을 넣지 않습니다. 배포 환경별로 DB 주소, JWT 시크릿, 결제 키, 문자 발송 키, AI API 키, OAuth 클라이언트 시크릿이 다릅니다. The Twelve-Factor App은 설정을 코드와 분리해 환경변수로 관리하는 방식을 설명합니다. 동시에 OWASP는 시크릿 관리에서 최소권한과 빠른 회전 가능성을 강조합니다. 즉, 인수인계 문서에는 값 자체보다 변수명, 용도, 저장 위치, 교체 방법이 정리되어야 합니다. ([12factor.net](https://www.12factor.net/config?utm_source=openai))

구분예시인수인계 기준
인증JWT_SECRET, SESSION_SECRET, OAuth Client Secret발주사 계정으로 재발급 또는 회전
DBDATABASE_URL, DB_USER, DB_PASSWORD운영·스테이징 분리, 읽기/쓰기 권한 분리
결제PG 상점 ID, 결제 키, 웹훅 시크릿발주사 PG 계정, 테스트·운영 키 구분
알림SMS, 카카오 알림톡, 이메일 발송 키발송 계정 소유권과 충전 방식 확인
파일S3 bucket key, CDN token버킷 권한, 공개 범위, 삭제 정책 확인
AIOpenAI, Anthropic, Google, Azure 등 API 키모델명, 사용량 제한, 비용 알림, 프롬프트 버전 기록
자동화Zapier, Make, n8n, Slack webhook트리거 조건, 실패 알림, 재시도 방법 문서화

실무적으로는 외주사가 사용하던 키를 그대로 이어받기보다, 발주사 계정에서 새 키를 발급하고 기존 키를 폐기하는 방식이 안전합니다. 특히 결제, 개인정보, AI API처럼 비용과 보안 영향이 큰 키는 인수인계 완료 후 바로 회전 계획을 세워야 합니다. 키 값을 문서에 평문으로 남기거나 메신저로 전달하는 방식은 피해야 합니다.

6. DB 인수인계: 백업보다 복구가 중요하다

DB는 서비스의 실제 자산입니다. 소스코드를 다시 만들 수는 있어도, 회원·주문·예약·상담·정산 데이터가 사라지면 사업 운영이 멈출 수 있습니다. 그래서 DB 인수인계는 스키마와 백업 파일을 받는 수준에서 끝나면 안 됩니다. 복구 테스트까지 확인해야 합니다.

AWS Backup 문서도 복구 테스트 개념을 별도로 다룹니다. AWS를 쓰지 않는 서비스라도 원칙은 같습니다. 백업이 있다는 말보다 언제, 어디에서, 어떤 권한으로, 얼마 만에 복구되는지를 확인해야 합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html?utm_source=openai))

항목확인할 내용검수 방법
DB 종류와 위치PostgreSQL, MySQL, MongoDB, Redis 등 구성접속 정보와 리소스 목록 확인
스키마테이블, 컬럼, 인덱스, 제약조건ERD 또는 schema dump 검토
마이그레이션변경 이력과 롤백 가능 여부빈 DB에 migration 실행
백업 정책주기, 보관 기간, 암호화, 저장 위치자동 백업 설정 화면 확인
복구 절차명령어, 권한, 예상 복구 시간스테이징 환경에서 실제 복구 테스트
개인정보삭제 요청, 마스킹, 다운로드 권한관리자 기능과 DB 정책 대조
초기 데이터카테고리, 권한, 설정값, 기본 템플릿seed 파일 또는 운영 설정 문서 확인

DB에서 자주 누락되는 항목은 초기 설정 데이터입니다. 예를 들어 관리자 권한 목록, 상품 카테고리, 예약 가능 시간, 수수료율, 알림 템플릿은 코드가 아니라 DB에 들어 있을 수 있습니다. 운영자가 신규 서버를 만들었을 때 이런 데이터가 없으면 서비스는 실행되지만 실제 업무는 할 수 없습니다.

7. 배포와 CI/CD: 버튼 하나가 아니라 절차 전체를 받아야 한다

배포 인수인계의 목표는 새 담당자가 같은 결과를 재현하는 것입니다. 외주사 개발자 PC에서만 빌드되는 구조라면 인수인계가 아닙니다. AWS Well-Architected의 운영 우수성 관점에서도 여러 환경, 작은 변경, 자동화된 통합과 배포, 롤백 같은 운영 방식은 중요한 관리 항목으로 다뤄집니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operate.html?utm_source=openai))

배포 항목확인 질문필요 문서
환경 구분local, dev, staging, production이 어떻게 다른가?환경 매트릭스
빌드 명령프론트엔드와 백엔드 빌드 명령은 무엇인가?README, package scripts, Dockerfile
CI/CD 도구GitHub Actions, GitLab CI, Jenkins, Vercel 등 어디서 실행되는가?workflow 파일, 권한 목록
배포 트리거main merge, tag 생성, 수동 승인 중 어떤 방식인가?배포 플로우 문서
롤백배포 실패 시 이전 버전으로 돌아갈 수 있는가?롤백 절차, 이전 이미지 또는 릴리즈 보관 위치
마이그레이션배포 전후 DB 변경 순서는 어떻게 되는가?배포 체크리스트
배포 권한누가 운영 배포를 승인하고 실행할 수 있는가?권한표, 승인 절차

작은 팀에서는 CI/CD가 없고 SSH 접속 후 수동으로 배포하는 경우도 있습니다. 그 자체가 항상 문제는 아닙니다. 다만 수동 배포라면 더 자세한 체크리스트가 필요합니다. 어떤 브랜치를 pull 하는지, 어떤 명령으로 빌드하는지, 어떤 프로세스를 재시작하는지, 실패하면 어디까지 되돌리는지 문서가 있어야 합니다.

소스코드부터 서버, DB, 배포, 운영문서까지 이어지는 외주개발 인수인계 흐름도
소스코드만 받는 것이 아니라 운영 가능한 흐름 전체를 넘겨받아야 합니다.

8. 관리자 시스템과 운영 권한 체크리스트

많은 외주개발 프로젝트에서 관리자 페이지는 ‘일단 만들어 드렸다’ 수준으로 끝납니다. 하지만 실서비스에서는 관리자 시스템이 운영팀의 업무 도구입니다. 회원을 검색하고, 예약을 변경하고, 결제를 취소하고, 콘텐츠를 수정하고, 알림을 재발송하고, CS 이력을 확인해야 합니다.

관리자 영역확인할 질문누락 시 문제
계정 생성최초 최고관리자 계정은 누가 만들고 어떻게 복구하는가?관리자 잠김, 퇴사자 계정 의존
권한 등급운영자, CS, 재무, 마케터 권한이 분리되는가?개인정보 과다 접근, 실수 삭제
감사 로그누가 어떤 데이터를 수정했는지 남는가?분쟁과 사고 원인 추적 불가
데이터 다운로드엑셀 다운로드 범위와 마스킹 기준은 무엇인가?개인정보 유출 위험
수동 처리예약 변경, 환불, 재발송, 상태 보정이 가능한가?CS 대응 지연
콘텐츠 관리배너, FAQ, 공지, 약관을 운영자가 수정할 수 있는가?간단한 변경도 개발 의존
운영 매뉴얼운영자가 매일 쓰는 기능 설명이 있는가?담당자 교체 시 업무 단절

AgentMit이 BizMit 기반 관리자 시스템이나 업무 자동화 프로젝트를 볼 때 가장 먼저 확인하는 것도 이 부분입니다. 기능이 많은 관리자보다 중요한 것은 운영자가 실수 없이 쓸 수 있는 권한 구조, 검색 조건, 상태값 정의, 로그, 엑셀 처리 기준입니다.

9. 운영문서와 런북: 장애가 났을 때 누구나 같은 순서로 움직여야 한다

런북은 특정 작업을 수행하기 위한 단계별 절차입니다. AWS Well-Architected Framework는 런북에 목표, 필요한 도구와 권한, 오류 처리, 예외, 에스컬레이션이 포함되어야 하며 중앙 위치에 게시되고 절차 변화에 따라 업데이트되어야 한다고 설명합니다. 외주개발 인수인계에서도 이 기준을 그대로 적용할 수 있습니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/ops_ready_to_support_use_runbooks.html?utm_source=openai))

런북 종류반드시 포함할 내용예시
배포 런북배포 전 확인, 실행 명령, 검증, 롤백릴리즈 전 DB 백업 후 배포
장애 런북증상별 확인 위치, 로그, 담당자, 우선순위로그인 실패, 결제 실패, 알림 미발송
백업 복구 런북복구 명령, 권한, 복구 대상, 검증 방법어제 03시 백업을 스테이징에 복구
계정 관리 런북관리자 생성, 퇴사자 권한 회수, MFA 초기화운영자 퇴사 시 권한 회수 절차
외부 API 런북결제·문자·AI API 장애 시 대체 처리PG 장애 시 주문 상태 확인 방법
비용 관리 런북사용량 확인, 알림 기준, 급증 시 조치AI API 사용량 급증 시 임시 제한

운영문서는 길다고 좋은 것이 아닙니다. 담당자가 급한 상황에서 따라 할 수 있어야 합니다. 좋은 런북은 목적, 대상 환경, 필요한 권한, 실행 순서, 성공 기준, 실패 시 되돌리는 방법, 연락처가 한 화면에 들어오도록 구성됩니다.

10. 유지보수 범위: 무상 하자보수와 기능 고도화를 분리하라

인수인계가 끝나면 바로 유지보수 이슈가 시작됩니다. 여기서 중요한 것은 ‘버그’와 ‘변경 요청’을 구분하는 것입니다. 계약 범위에 있던 기능이 명세대로 작동하지 않으면 하자보수에 가깝습니다. 반면 관리자 필터 추가, 결제 수단 추가, AI 응답 품질 개선, 새로운 통계 리포트, 외부 CRM 연동은 기능 고도화로 봐야 할 가능성이 큽니다.

구분예시사전에 정할 것
하자보수명세된 회원가입이 특정 브라우저에서 실패무상 기간, 대응 시간, 재현 조건
운영 지원배포 지원, 서버 재시작, 로그 확인월 포함 시간, 긴급 대응 채널
보안 패치프레임워크 취약점 업데이트정기 점검 여부, 비용 기준
외부 API 변경PG, 지도, 로그인, AI API 정책 변경무상 여부와 작업 범위
기능 고도화새 관리자 메뉴, 자동화 워크플로, 통계 대시보드별도 견적과 일정
데이터 작업주문 상태 보정, 회원 데이터 일괄 수정승인 절차와 백업 기준

유지보수 예산을 잡을 때는 단순 개발비만 보지 말고 운영 부담을 함께 계산해야 합니다. 견적 구조를 다시 정리해야 한다면 외주개발 비용 산정 방법을 참고해 기능 개발, 운영 지원, 인프라 비용, 고도화 비용을 나누어 보는 것이 좋습니다.

11. 잔금 전 반드시 해볼 3가지 실전 테스트

인수인계 문서가 좋아 보여도 실행해 보지 않으면 모릅니다. 잔금 지급 전에는 최소 세 가지 테스트를 권장합니다. 이 테스트를 외주사 담당자만 수행하면 안 됩니다. 발주사 측 내부 담당자, 신규 개발자, 또는 제3자 개발 파트너가 문서만 보고 수행해 보는 것이 가장 좋습니다.

외주개발 잔금 전 최종 인수인계 체크리스트를 검토하는 PM 업무 장면
마지막 검수는 문서가 아니라 직접 실행·배포·복구해 보는 과정이어야 합니다.
테스트방법합격 기준
새 노트북 실행 테스트저장소를 새로 clone하고 README만 보고 로컬 실행프론트·백엔드가 실행되고 기본 시나리오가 동작
발주사 계정 배포 테스트발주사 클라우드와 CI/CD 권한으로 스테이징 배포외주사 개인 계정 없이 배포 성공
DB 복구 테스트백업 파일 또는 자동 백업을 스테이징 DB에 복구핵심 테이블과 관리자 기능이 정상 확인

이 세 가지를 통과하면 적어도 다음 개발자가 이어받을 수 있는 최소 기반은 확보됩니다. 반대로 여기서 막히면 화면상으로는 완성된 서비스라도 운영 인수는 아직 끝나지 않은 것입니다.

12. 서비스 유형별로 추가 확인할 항목

웹사이트 리뉴얼·랜딩페이지

  • 도메인, DNS, SSL 인증서, 호스팅 소유권
  • 관리자 CMS, 폼 수신 메일, 스팸 방지 설정
  • GA4, Search Console, 픽셀, 광고 전환 스크립트 권한
  • 이미지 원본, 폰트 라이선스, 콘텐츠 수정 매뉴얼

예약·매칭·결제 서비스

  • 예약 상태값 정의: 대기, 확정, 취소, 노쇼, 환불
  • PG 관리자 권한, 웹훅 수신 URL, 정산 기준
  • 알림톡·문자 발송 실패 시 재발송 방법
  • 운영자가 수동으로 상태를 보정하는 절차

SaaS·관리자 대시보드

  • 테넌트 또는 고객사별 데이터 분리 구조
  • 관리자 권한, 감사 로그, 데이터 다운로드 제한
  • 요금제, 구독, 사용량 제한, 결제 실패 처리
  • 고객사 온보딩과 계정 비활성화 절차

AI 기능·자동화 워크플로

  • 사용 모델명, 프롬프트 버전, 응답 포맷, 실패 처리
  • API 사용량 제한, 월 비용 알림, 캐싱 기준
  • 업무 자동화 트리거와 중복 실행 방지 장치
  • AI 응답을 사람이 검수해야 하는 구간과 로그 보관 기준

AI 기능은 특히 키 하나만 넘겨받아서는 부족합니다. 어떤 입력 데이터가 모델로 전달되는지, 개인정보가 포함되는지, 실패했을 때 기본 응답은 무엇인지, 비용이 급증할 때 어떤 제한을 거는지까지 운영 기준을 정해야 합니다.

13. 이미 인수인계가 꼬였다면: 복구 순서

이미 외주사가 떠났거나 담당자가 바뀌어 문서가 없는 상태라면, 감정적으로 책임 소재를 따지기 전에 현황 동결부터 해야 합니다. 운영 서버와 DB의 현재 상태를 백업하고, 비용 결제와 도메인 만료일을 확인한 뒤, 권한과 리소스 목록을 작성해야 합니다.

  1. 현재 운영 상태 스냅샷: 서버, DB, 스토리지, 도메인, 배포 상태를 먼저 기록합니다.
  2. 계정 소유권 확인: 클라우드, 도메인, Git, PG, 문자, 메일, AI API 계정이 누구 명의인지 확인합니다.
  3. 최신 코드 식별: 운영 서버의 배포 경로와 Git 커밋을 대조합니다.
  4. 환경변수 목록화: 값이 아니라 변수명, 용도, 적용 환경부터 정리합니다.
  5. 백업과 복구 확인: DB 백업이 있는지, 실제 복구 가능한지 확인합니다.
  6. 최소 런북 작성: 배포, 장애 확인, 계정 관리, 백업 복구부터 문서화합니다.
  7. 시크릿 회전: 발주사 계정으로 새 키를 발급하고 기존 키를 폐기합니다.

장애 원인 추적이 어렵다면 로그와 관측성부터 정리해야 합니다. 작은 팀이 최소한의 모니터링 구조를 잡는 방법은 OpenTelemetry 관측성 가이드도 함께 볼 만합니다.

14. 발주사가 외주사에 바로 물어볼 질문 20개

  • 현재 운영 서버에 배포된 최종 커밋 SHA는 무엇인가요?
  • 발주사 조직 계정으로 Git 저장소를 이전할 수 있나요?
  • 운영·스테이징·개발 환경별 환경변수 목록이 있나요?
  • 환경변수 값은 어디에 저장되어 있나요?
  • 운영 서버는 누구 명의 계정에서 결제되고 있나요?
  • 도메인과 DNS는 어느 계정에서 관리되나요?
  • DB 백업 주기와 보관 기간은 어떻게 되나요?
  • 최근 백업으로 복구 테스트를 해본 적이 있나요?
  • 배포는 누가, 어디서, 어떤 명령으로 하나요?
  • 배포 실패 시 롤백 절차가 있나요?
  • 관리자 최고 권한 계정은 누가 보유하나요?
  • 퇴사자나 외주사 계정을 어떻게 회수하나요?
  • 결제, 문자, 이메일, 지도, AI API 계정은 누구 명의인가요?
  • 웹훅 실패 시 재시도 또는 수동 보정 방법이 있나요?
  • 첨부파일과 이미지 원본은 어디에 저장되나요?
  • 로그와 에러는 어디에서 확인하나요?
  • 현재 알려진 버그와 기술부채 목록이 있나요?
  • 오픈소스 라이선스나 유료 플러그인 사용 내역이 있나요?
  • 무상 하자보수와 유상 변경 요청의 기준은 무엇인가요?
  • 다음 개발자가 투입될 때 1시간 안에 설명할 수 있는 구조 문서가 있나요?

AgentMit 관점: 인수인계는 다음 개발을 위한 출발선입니다

AgentMit은 외주개발을 단순히 납품 코드로 보지 않습니다. 실제 운영 가능한 서비스로 전환되어야 다음 고도화가 가능합니다. MVP를 만들고 끝나는 것이 아니라, 관리자 시스템, 자동화, AI 기능, SaaS 구조, 배포와 유지보수까지 이어져야 합니다.

이미 개발된 서비스의 상태가 불안하다면 먼저 인수인계 진단부터 진행하는 것이 좋습니다. Git 저장소, 서버, DB, 배포, 운영 문서를 확인하면 지금 바로 유지보수가 가능한지, 재구축이 필요한지, 일부만 보강하면 되는지 판단할 수 있습니다. AgentMit은 BizMit 기반의 관리자 대시보드, 업무 자동화, AI 서비스 개발, 정부지원 MVP 이후 실서비스 전환까지 연결해 범위 점검과 개발 실행을 함께 도울 수 있습니다.

외주사가 개발 완료라고 말했지만 운영 인수가 불안하다면, 소스코드·서버·DB·배포·운영문서 기준으로 현재 상태를 먼저 점검해 보세요. 필요한 경우 AgentMit에 범위 리뷰, MVP 고도화 견적, 실서비스 개발 상담을 요청할 수 있습니다.

FAQ

Q1. 외주개발 완료 후 소스코드만 받으면 인수인계가 끝인가요?

아닙니다. 소스코드는 핵심 산출물이지만 실행 방법, 환경변수, 배포 절차, 서버 권한, DB 백업과 복구, 관리자 계정, 외부 API 키, 운영 런북이 함께 있어야 실제 운영 가능한 인수인계로 볼 수 있습니다.

Q2. 서버 계정이 외주사 명의인데 그대로 운영해도 되나요?

권장하지 않습니다. 장애, 비용 결제, 권한 회수, 업체 변경 상황에서 발주사가 통제권을 잃을 수 있습니다. 최종 운영 전에는 클라우드, 도메인, DNS, 스토리지, 배포 계정을 발주사 명의 또는 발주사 조직 계정으로 옮기는 것이 안전합니다.

Q3. .env 환경변수나 API 키는 어떻게 넘겨받아야 안전한가요?

평문 파일을 메신저로 주고받는 방식은 피해야 합니다. 변수명, 용도, 적용 환경, 저장 위치, 교체 절차를 문서화하고 실제 값은 발주사 계정의 시크릿 저장소나 클라우드 환경변수로 재등록한 뒤 기존 외주사 키는 회전 또는 폐기하는 방식이 안전합니다.

Q4. DB 백업 파일을 받으면 충분한가요?

백업 파일만으로는 부족합니다. 백업 주기, 저장 위치, 보관 기간, 암호화 여부, 복구 명령, 복구 예상 시간, 실제 복구 테스트 결과를 함께 확인해야 합니다. 특히 결제, 예약, 회원 데이터가 있는 서비스는 복구 테스트가 인수인계 검수 항목이어야 합니다.

Q5. 외주개발 유지보수 범위는 인수인계 때 어디까지 정해야 하나요?

버그 수정, 서버 장애 대응, 배포 지원, 외부 API 변경 대응, 보안 패치, 기능 변경 요청, 데이터 보정 작업을 구분해야 합니다. 무상 하자보수와 유상 유지보수의 기준, 응답 시간, 담당 채널, 월 포함 작업량을 문서로 남기는 것이 좋습니다.

참고자료

  • GitHub Docs의 저장소 이전 및 조직 저장소 권한 문서를 참고해 소스코드 저장소 소유권과 권한 분리 기준을 정리했습니다. ([docs.github.com](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository?apiVersion=2022-11-28&utm_source=openai))
  • The Twelve-Factor App과 OWASP Secrets Management Cheat Sheet를 참고해 환경변수와 시크릿 이관 기준을 정리했습니다. ([12factor.net](https://www.12factor.net/config?utm_source=openai))
  • AWS Well-Architected Framework의 런북 가이드와 AWS Backup의 복구 테스트 문서를 참고해 운영문서와 DB 복구 검수 기준을 정리했습니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/ops_ready_to_support_use_runbooks.html?utm_source=openai))

자주 묻는 질문

외주개발 완료 후 소스코드만 받으면 인수인계가 끝인가요?
아닙니다. 소스코드는 핵심 산출물이지만 실행 방법, 환경변수, 배포 절차, 서버 권한, DB 백업과 복구, 관리자 계정, 외부 API 키, 운영 런북이 함께 있어야 실제 운영 가능한 인수인계로 볼 수 있습니다.
서버 계정이 외주사 명의인데 그대로 운영해도 되나요?
권장하지 않습니다. 장애, 비용 결제, 권한 회수, 업체 변경 상황에서 발주사가 통제권을 잃을 수 있습니다. 최종 운영 전에는 클라우드, 도메인, DNS, 스토리지, 배포 계정을 발주사 명의 또는 발주사 조직 계정으로 옮기는 것이 안전합니다.
.env 환경변수나 API 키는 어떻게 넘겨받아야 안전한가요?
평문 파일을 메신저로 주고받는 방식은 피해야 합니다. 변수명, 용도, 적용 환경, 저장 위치, 교체 절차를 문서화하고 실제 값은 발주사 계정의 시크릿 저장소나 클라우드 환경변수로 재등록한 뒤 기존 외주사 키는 회전 또는 폐기하는 방식이 안전합니다.
DB 백업 파일을 받으면 충분한가요?
백업 파일만으로는 부족합니다. 백업 주기, 저장 위치, 보관 기간, 암호화 여부, 복구 명령, 복구 예상 시간, 실제 복구 테스트 결과를 함께 확인해야 합니다. 특히 결제, 예약, 회원 데이터가 있는 서비스는 복구 테스트가 인수인계 검수 항목이어야 합니다.
외주개발 유지보수 범위는 인수인계 때 어디까지 정해야 하나요?
버그 수정, 서버 장애 대응, 배포 지원, 외부 API 변경 대응, 보안 패치, 기능 변경 요청, 데이터 보정 작업을 구분해야 합니다. 무상 하자보수와 유상 유지보수의 기준, 응답 시간, 담당 채널, 월 포함 작업량을 문서로 남기는 것이 좋습니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 8층 101호 DD-33,34호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.