외주개발 인수인계 체크리스트: 소스코드·서버·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 | 발주사 계정으로 재발급 또는 회전 |
| DB | DATABASE_URL, DB_USER, DB_PASSWORD | 운영·스테이징 분리, 읽기/쓰기 권한 분리 |
| 결제 | PG 상점 ID, 결제 키, 웹훅 시크릿 | 발주사 PG 계정, 테스트·운영 키 구분 |
| 알림 | SMS, 카카오 알림톡, 이메일 발송 키 | 발송 계정 소유권과 충전 방식 확인 |
| 파일 | S3 bucket key, CDN token | 버킷 권한, 공개 범위, 삭제 정책 확인 |
| AI | OpenAI, 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 하는지, 어떤 명령으로 빌드하는지, 어떤 프로세스를 재시작하는지, 실패하면 어디까지 되돌리는지 문서가 있어야 합니다.

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자 개발 파트너가 문서만 보고 수행해 보는 것이 가장 좋습니다.

| 테스트 | 방법 | 합격 기준 |
|---|---|---|
| 새 노트북 실행 테스트 | 저장소를 새로 clone하고 README만 보고 로컬 실행 | 프론트·백엔드가 실행되고 기본 시나리오가 동작 |
| 발주사 계정 배포 테스트 | 발주사 클라우드와 CI/CD 권한으로 스테이징 배포 | 외주사 개인 계정 없이 배포 성공 |
| DB 복구 테스트 | 백업 파일 또는 자동 백업을 스테이징 DB에 복구 | 핵심 테이블과 관리자 기능이 정상 확인 |
이 세 가지를 통과하면 적어도 다음 개발자가 이어받을 수 있는 최소 기반은 확보됩니다. 반대로 여기서 막히면 화면상으로는 완성된 서비스라도 운영 인수는 아직 끝나지 않은 것입니다.
12. 서비스 유형별로 추가 확인할 항목
웹사이트 리뉴얼·랜딩페이지
- 도메인, DNS, SSL 인증서, 호스팅 소유권
- 관리자 CMS, 폼 수신 메일, 스팸 방지 설정
- GA4, Search Console, 픽셀, 광고 전환 스크립트 권한
- 이미지 원본, 폰트 라이선스, 콘텐츠 수정 매뉴얼
예약·매칭·결제 서비스
- 예약 상태값 정의: 대기, 확정, 취소, 노쇼, 환불
- PG 관리자 권한, 웹훅 수신 URL, 정산 기준
- 알림톡·문자 발송 실패 시 재발송 방법
- 운영자가 수동으로 상태를 보정하는 절차
SaaS·관리자 대시보드
- 테넌트 또는 고객사별 데이터 분리 구조
- 관리자 권한, 감사 로그, 데이터 다운로드 제한
- 요금제, 구독, 사용량 제한, 결제 실패 처리
- 고객사 온보딩과 계정 비활성화 절차
AI 기능·자동화 워크플로
- 사용 모델명, 프롬프트 버전, 응답 포맷, 실패 처리
- API 사용량 제한, 월 비용 알림, 캐싱 기준
- 업무 자동화 트리거와 중복 실행 방지 장치
- AI 응답을 사람이 검수해야 하는 구간과 로그 보관 기준
AI 기능은 특히 키 하나만 넘겨받아서는 부족합니다. 어떤 입력 데이터가 모델로 전달되는지, 개인정보가 포함되는지, 실패했을 때 기본 응답은 무엇인지, 비용이 급증할 때 어떤 제한을 거는지까지 운영 기준을 정해야 합니다.
13. 이미 인수인계가 꼬였다면: 복구 순서
이미 외주사가 떠났거나 담당자가 바뀌어 문서가 없는 상태라면, 감정적으로 책임 소재를 따지기 전에 현황 동결부터 해야 합니다. 운영 서버와 DB의 현재 상태를 백업하고, 비용 결제와 도메인 만료일을 확인한 뒤, 권한과 리소스 목록을 작성해야 합니다.
- 현재 운영 상태 스냅샷: 서버, DB, 스토리지, 도메인, 배포 상태를 먼저 기록합니다.
- 계정 소유권 확인: 클라우드, 도메인, Git, PG, 문자, 메일, AI API 계정이 누구 명의인지 확인합니다.
- 최신 코드 식별: 운영 서버의 배포 경로와 Git 커밋을 대조합니다.
- 환경변수 목록화: 값이 아니라 변수명, 용도, 적용 환경부터 정리합니다.
- 백업과 복구 확인: DB 백업이 있는지, 실제 복구 가능한지 확인합니다.
- 최소 런북 작성: 배포, 장애 확인, 계정 관리, 백업 복구부터 문서화합니다.
- 시크릿 회전: 발주사 계정으로 새 키를 발급하고 기존 키를 폐기합니다.
장애 원인 추적이 어렵다면 로그와 관측성부터 정리해야 합니다. 작은 팀이 최소한의 모니터링 구조를 잡는 방법은 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))

