외주개발 서버 인수 체크리스트: 계정·권한·비용·백업까지 넘겨받는 기준

외주개발로 만든 웹서비스, 앱, SaaS, 관리자 시스템을 출시하기 전에는 소스코드만 받으면 충분하지 않습니다. 실제 운영을 좌우하는 것은 서버 계정, 도메인, DNS, SSL, 배포 권한, 환경변수, DB, 스토리지, 백업, 로그, 알림, 월 비용 리포트입니다. 이 항목이 발주사 명의와 권한으로 정리되지 않으면 기능은 완성됐는데도 장애 대응, 업체 교체, 개인정보 점검, 비용 통제가 막힐 수 있습니다.
대표나 PM 입장에서는 개발 완료 보고를 받았을 때 무엇을 물어봐야 할지 애매합니다. 개발사는 정상 배포됐다고 말하지만, AWS·GCP·NCP 계정이 개발사 명의인지, 도메인 등록 계정이 누구 이메일인지, GitHub Actions나 GitLab CI에서 실제 배포가 가능한지, DB 백업을 복원해 본 적이 있는지까지는 별도 확인이 필요합니다. 이 글은 외주개발 결과물을 운영 가능한 상태로 넘겨받기 위한 실무 체크리스트입니다.
인수 완료의 기준은 ‘파일을 받았다’가 아니라 ‘발주사 또는 다음 유지보수사가 같은 버전을 다시 배포하고, 장애가 났을 때 복구할 수 있다’입니다.
1. 서버 인수의 핵심 원칙: 명의는 발주사, 작업 권한은 위임
가장 먼저 정해야 할 기준은 계정 소유권입니다. 장기 운영할 서비스라면 클라우드, 도메인, 결제, 배포 계정은 발주사 법인 또는 서비스 운영 주체 명의로 두는 것이 안전합니다. 개발사는 작업 기간 동안 필요한 권한을 위임받고, 납품 후에는 유지보수 범위에 맞게 권한을 줄이거나 회수하는 구조가 좋습니다.
AWS, Google Cloud, NAVER Cloud 모두 권한을 역할 또는 서브 계정 단위로 나눠 운영할 수 있습니다. AWS IAM 문서는 MFA, 최소 권한, 장기 액세스 키 정리, 루트 계정 보호를 권장하고, Google Cloud IAM도 리소스 계층에서 최소 권한 원칙을 적용하도록 설명합니다. NCP 역시 하나의 계정을 공유하기보다 Sub Account로 권한을 나누는 방식을 제공합니다. 중요한 점은 특정 클라우드의 메뉴 이름이 아니라 ‘대표 계정을 공유하지 않고, 필요한 사람에게 필요한 권한만 준다’는 운영 원칙입니다.
| 항목 | 권장 소유자 | 외주사 권한 | 인수 시 확인 |
|---|---|---|---|
| 클라우드 루트·결제 계정 | 발주사 법인 | 원칙적으로 직접 공유 금지 | MFA, 결제수단, 청구 이메일, 예산 알림 |
| 운영 서버·DB 관리 권한 | 발주사 | 역할 기반 위임 | 운영·스테이징 권한 분리, 접속 로그 |
| 도메인 등록 계정 | 발주사 | 필요 시 DNS 편집 권한만 | 등록자 정보, 만료일, 네임서버, 기관 이전 잠금 |
| Git 저장소 | 발주사 조직 또는 공동 관리 | 개발·배포 권한 분리 | 소스, 브랜치 보호, 릴리즈 태그, CI 설정 |
| 외부 API·결제·문자 계정 | 발주사 | 테스트키 또는 제한 권한 | 운영키, 웹훅 URL, 정산 계정, 사용량 한도 |
2. 외주개발 서버 인수 체크리스트 전체 구조
서버 인수는 기술 담당자만의 일이 아닙니다. 대표는 소유권과 비용을 봐야 하고, PM은 배포와 운영 절차를 봐야 하며, 마케터는 도메인·검색·전환 스크립트 영향을 확인해야 합니다. 예약, 매칭, 결제, CRM, 관리자 대시보드, AI 자동화 기능이 들어간 서비스라면 데이터와 외부 API 의존성이 더 중요해집니다.

인수 문서에 반드시 들어갈 10개 묶음
- 계정·명의: 클라우드, 도메인, DNS, Git, CI/CD, 결제·문자·메일·지도·AI API 계정의 소유자와 관리자 목록
- 서버 구성: 운영, 스테이징, 개발 환경의 리소스 목록과 용도
- 도메인·DNS·SSL: A, CNAME, TXT, MX, SPF, DKIM, DMARC, 인증서 발급·갱신 방식
- 배포 절차: 누가, 어떤 브랜치에서, 어떤 파이프라인으로, 어떤 승인 후 배포하는지
- 환경변수·시크릿: 실제 값이 아니라 이름, 용도, 보관 위치, 재발급 절차, 권한 범위
- 데이터베이스: DB 종류, 버전, 접근 방식, 마이그레이션, 백업, 복원 절차
- 스토리지: 파일 업로드 저장소, 접근 정책, 공개 버킷 여부, 보관·삭제 기준
- 로그·모니터링: 애플리케이션 로그, 서버 로그, 감사 로그, 에러 추적, 알림 채널
- 보안 설정: MFA, 최소 권한, 방화벽, 보안그룹, 접근 IP, 관리자 권한, 개인정보 접속기록
- 비용·운영: 월 예상비용, 예산 알림, 무료 크레딧 종료일, 예약·커밋 약정, 장애 대응 연락망
3. 클라우드 계정: 루트 계정보다 ‘회수 가능한 권한’이 중요하다
외주개발에서 가장 흔한 문제는 개발사가 본인 계정에 서버를 만들고 발주사에게 서비스 URL만 전달하는 방식입니다. 초기에는 빠릅니다. 하지만 출시 후에는 서버비 청구, 권한 회수, 장애 대응, 개인정보 점검, 업체 교체가 모두 개발사 협조에 의존하게 됩니다. 개발사가 바쁘거나 관계가 악화되면 단순 수정도 지연됩니다.
인수 단계에서는 클라우드 콘솔의 관리자 화면을 함께 열고 다음을 확인해야 합니다.
- 루트 또는 최상위 관리자 이메일이 발주사 소유인지
- MFA가 설정되어 있고 회수 가능한 장치 또는 인증 앱이 발주사 통제하에 있는지
- 개발자 개인 계정, 퇴사자 계정, 테스트 계정이 남아 있지 않은지
- 장기 액세스 키가 불필요하게 생성되어 있지 않은지
- 운영 서버, DB, 스토리지, DNS, 로그에 과도한 관리자 권한이 부여되어 있지 않은지
- 청구서 수신 이메일과 결제수단이 발주사 기준으로 설정되어 있는지
- 예산 알림, 비용 이상 징후 알림, 월별 비용 태그가 설정되어 있는지
정부지원사업으로 MVP를 만들었거나, 창업팀이 무료 크레딧을 사용한 경우에는 계정 명의와 비용 증빙이 더 중요합니다. 클라우드 비용이 개발사 카드로 결제되고 발주사는 총액만 정산받는 구조라면 리소스별 비용을 분석하기 어렵고, 과제 정산 자료로도 설명이 복잡해질 수 있습니다. 세부 기준은 사업별 관리지침을 따라야 하지만, 실무적으로는 발주사 명의의 계정에서 비용과 리소스를 직접 확인할 수 있어야 합니다.
4. 도메인, DNS, SSL: 사이트가 열리는 권한은 개발 권한과 다르다
도메인은 서비스의 입구입니다. 서버가 정상이어도 도메인 등록 계정이나 DNS 계정이 업체 명의이면, 홈페이지 리뉴얼, SaaS 이전, 이메일 인증, 검색엔진 검증, 결제사 도메인 인증에서 막힐 수 있습니다. 특히 Cloudflare 같은 DNS·CDN 서비스를 쓰는 경우 계정 역할에 따라 결제, 멤버 관리, API 토큰, DNS 편집 권한이 달라질 수 있으므로 단순 로그인 정보 전달로 끝내면 안 됩니다.
도메인·DNS 인수 체크
- 도메인 등록기관, 등록자명, 등록자 이메일, 관리자 연락처가 발주사 기준인지 확인
- 도메인 만료일, 자동갱신, 결제수단, 기관 이전 잠금 상태 확인
- 네임서버가 어디를 가리키는지 확인
- A, AAAA, CNAME, TXT, MX, SPF, DKIM, DMARC 레코드 목록을 문서화
- 운영 도메인, 관리자 도메인, API 도메인, 스테이징 도메인을 구분
- SSL 인증서가 자동 갱신인지, 수동 갱신인지, 인증서 발급 계정이 누구 것인지 확인
- CDN, WAF, 리다이렉트, 캐시 규칙, 방화벽 규칙이 있는지 확인
도메인 등록자 정보 변경이나 기관 이전은 등록기관 정책, 잠금 상태, 승인 메일, 이전 제한 기간의 영향을 받을 수 있습니다. 따라서 런칭 전날에 도메인을 옮기려 하지 말고, 최소 며칠 전에는 등록자와 DNS 권한을 먼저 확인하는 것이 안전합니다.
5. 배포 권한과 CI/CD: 다음 업체가 배포를 재현할 수 있어야 한다
소스코드를 받았는데 새 유지보수사가 배포하지 못하는 경우가 많습니다. 이유는 대체로 세 가지입니다. 첫째, 운영 환경변수가 Git 저장소 밖에 있는데 위치를 모릅니다. 둘째, 배포 파이프라인 권한이 개발사 개인 계정에 묶여 있습니다. 셋째, 서버 접속키, 컨테이너 레지스트리, 이미지 빌드 설정, DB 마이그레이션 절차가 문서화되어 있지 않습니다.
GitHub Actions, GitLab CI/CD, Jenkins, Vercel, Netlify, Docker, Kubernetes 등 어떤 방식을 쓰든 인수 기준은 같습니다. ‘코드가 있다’가 아니라 ‘새로운 사람이 동일 절차로 스테이징에 배포하고, 승인 후 운영에 반영할 수 있다’가 기준입니다.
| 구분 | 받아야 할 자료 | 검수 방법 |
|---|---|---|
| Git 저장소 | 전체 소스, 브랜치 전략, 태그, 서브모듈, 빌드 문서 | 새 PC에서 설치·빌드 성공 여부 확인 |
| CI/CD | 워크플로 파일, Runner, 배포 토큰, 승인 규칙 | 스테이징 재배포 테스트 |
| 환경변수 | 키 이름, 용도, 저장 위치, 재발급 절차 | 값 노출 없이 누락 변수 확인 |
| 서버 접속 | SSH 정책, Bastion, VPN, 접근 IP, 운영 접속 승인자 | 발주사 계정으로 접속 가능 여부 확인 |
| 컨테이너·이미지 | Dockerfile, 이미지 저장소, 태그 정책, 롤백 방법 | 이전 버전 롤백 리허설 |
| DB 마이그레이션 | 마이그레이션 명령, 순서, 롤백 가능성 | 스테이징 DB에서 적용 테스트 |
환경변수와 API 키는 엑셀에 평문으로 받는 방식이 안전하지 않습니다. 대신 키 이름, 사용처, 권한 범위, 발급 계정, 재발급 방법, 보관 위치를 문서화하고 실제 값은 GitHub Secrets, GitLab Variables, 클라우드 Secret Manager, 비밀번호 관리자처럼 접근 제어가 가능한 저장소에서 넘겨받아야 합니다. 외부 결제, 문자, 이메일, 지도, AI API 키는 비용 발생과 개인정보 처리에 연결되므로 운영키와 테스트키를 반드시 구분해야 합니다.
6. DB, 스토리지, 백업: 백업 파일이 아니라 복원 가능성을 인수한다
예약·매칭·결제·CRM·SaaS 서비스에서 서버보다 중요한 것은 데이터입니다. 서버는 다시 만들 수 있지만 주문, 결제, 예약, 회원, 메시지, 관리자 변경 이력은 잃으면 복구가 어렵습니다. 개발 완료 시점에 ‘백업 설정했습니다’라는 말만 듣지 말고 실제 복원 가능 여부를 확인해야 합니다.
백업 검수는 백업 복원 테스트 자동화 가이드에서 다룬 것처럼 백업 생성, 보관, 암호화, 복제, 복원 리허설을 함께 봐야 합니다. 외주개발 인수에서는 최소한 최근 백업 파일 또는 스냅샷을 테스트 환경에 복원해 보고, 애플리케이션이 정상 접속되는지까지 확인하는 것이 좋습니다.
데이터 인수 체크리스트
- DB 엔진, 버전, 리전, 인스턴스 사양, 스토리지 용량
- 운영 DB와 개발·스테이징 DB 분리 여부
- 관리자 계정, 읽기 전용 계정, 애플리케이션 계정 권한 분리
- 백업 주기, 보관 기간, 복원 가능한 시점, 복원 예상 시간
- 개인정보, 민감정보, 결제정보, 로그 데이터의 저장 위치
- 파일 업로드 스토리지의 공개 접근 여부와 삭제 정책
- DB 마이그레이션 파일과 실제 운영 DB 스키마 차이
- 데이터 덤프를 받을 경우 암호화 전달, 보관 기간, 파기 방법
개인정보를 처리하는 시스템이라면 법무 검토와 별개로 기술 운영자가 확인해야 할 항목이 있습니다. 개인정보처리시스템 접근권한을 업무에 필요한 범위로 차등 부여하고, 접속기록 보관·점검, 암호화 등 안전조치 기준을 운영에 반영해야 합니다. 처리 규모와 정보 유형에 따라 세부 보관기간과 조치 수준이 달라질 수 있으므로 최신 고시와 내부 개인정보 처리방침을 함께 확인해야 합니다.
7. 로그와 모니터링: 장애가 났을 때 ‘누가 알게 되는가’
서비스를 출시한 뒤 가장 곤란한 상황은 장애가 발생했는데 아무도 모르는 경우입니다. 외주개발 인수에서 로그와 모니터링은 선택 항목이 아닙니다. 특히 결제 실패, 예약 누락, 알림톡 미발송, 관리자 저장 오류, AI 응답 실패처럼 사용자에게 바로 보이지 않는 장애는 로그와 알림이 없으면 며칠 뒤 고객 문의로 발견됩니다.
인수 문서에는 다음 항목이 있어야 합니다.
- 애플리케이션 에러 로그 위치와 검색 방법
- 서버 CPU, 메모리, 디스크, 네트워크 모니터링 기준
- DB 연결 수, 느린 쿼리, 저장공간 임계치
- 배포 성공·실패 로그와 롤백 이력
- 관리자 로그인, 권한 변경, 데이터 다운로드 기록
- 결제, 문자, 이메일, 웹훅, AI API 호출 실패 로그
- 장애 알림 채널: 이메일, Slack, 카카오워크, 문자 등
- 알림 수신자와 업무시간·야간 대응 기준
감사 로그는 단순 개발 편의가 아니라 책임 소재를 확인하는 장치입니다. Google Cloud Audit Logs처럼 관리자 활동과 데이터 접근 이벤트를 구분하는 클라우드도 있고, AWS CloudTrail처럼 계정 활동 추적을 별도로 설정하는 구조도 있습니다. 어떤 도구를 쓰든 인수 시에는 ‘누가 언제 운영 리소스를 변경했는지’를 나중에 추적할 수 있어야 합니다.
8. 월 서버비 점검: 인스턴스 가격만 보면 틀린다
외주개발 완료 후 첫 달에는 비용이 작아 보이다가 출시 이후 갑자기 증가하는 경우가 있습니다. 원인은 서버 인스턴스뿐 아니라 DB 스토리지, 백업, 로그 보관, 이미지 레지스트리, CDN 트래픽, 파일 다운로드, 외부 API, 문자 발송, AI 토큰 사용량일 수 있습니다. 따라서 인수 시에는 월 예상비용을 리소스별로 받아야 합니다.

| 비용 항목 | 확인 질문 | 주의할 점 |
|---|---|---|
| 컴퓨팅 | 서버 사양이 실제 트래픽 대비 적정한가? | 테스트용 고사양 서버가 운영에 남아 있을 수 있음 |
| DB | 스토리지 자동 증가와 백업 보관 비용은 얼마인가? | DB는 서버보다 비용 증가가 빠를 수 있음 |
| 스토리지 | 업로드 파일, 썸네일, 로그, 백업이 어디에 저장되는가? | 공개 버킷, 중복 백업, 미삭제 임시 파일 확인 |
| 트래픽·CDN | 동영상, 이미지, 파일 다운로드가 많은가? | 마케팅 캠페인 후 전송량이 급증할 수 있음 |
| 로그 | 보관 기간과 수집 범위가 적절한가? | 모든 디버그 로그를 장기 보관하면 비용이 증가 |
| 외부 API | 결제, 문자, 이메일, 지도, AI API 사용량 한도가 있는가? | API 키 유출이나 반복 호출로 과금될 수 있음 |
| 알림·보안 | WAF, 모니터링, 에러 추적 도구가 유료인가? | 무료 플랜 한도 초과 시 비용 발생 가능 |
SaaS 운영비는 개발비와 다르게 매달 반복됩니다. MVP 단계라면 비용을 무조건 낮추기보다, 장애 복구와 데이터 보호에 필요한 최소 비용을 정하고 나머지를 줄이는 방식이 좋습니다. 운영비 산정이 처음이라면 초기 SaaS 운영비 산정 가이드처럼 사용자 수, 트래픽, 파일 저장량, 외부 API 사용량을 기준으로 월별 시나리오를 나눠보는 것이 현실적입니다.
9. 업체 교체 전에는 ‘읽기 권한’보다 ‘배포 재현’이 먼저다
새로운 유지보수 업체나 내부 개발자를 투입할 계획이라면 인수 검수의 목표를 명확히 해야 합니다. 단순히 관리자 화면에 로그인할 수 있는지 보는 것이 아니라, 현재 운영 중인 버전을 재현할 수 있는지가 핵심입니다. 재현이 되지 않으면 작은 문구 수정도 위험한 배포가 됩니다.
업체 교체 전 7단계 인수 순서
- 계정 동결 방지: 도메인, 클라우드, Git, 외부 API 계정의 발주사 관리자 권한 확보
- 현재 상태 백업: 운영 DB, 파일 스토리지, 서버 이미지, 환경변수 목록 확보
- 비용 확인: 최근 3개월 청구 내역, 리소스별 비용, 크레딧 종료일 확인
- 권한 정리: 개발사 개인 계정, 불필요한 액세스 키, 공유 비밀번호 회수
- 스테이징 재구성: 새 담당자가 문서만 보고 테스트 환경을 배포
- 운영 배포 리허설: 변경 없는 배포 또는 작은 수정 배포로 파이프라인 검증
- 운영 계약 전환: 장애 대응 범위, 응답 시간, 보안 업데이트, 월 점검 범위 확정
유지보수 계약으로 넘어갈 때는 기능 수정비만 보면 안 됩니다. 장애 대응 시간, 서버 패치, 백업 복원, 보안 업데이트, 로그 점검, 외부 API 장애 확인, 배포 승인 절차를 함께 정해야 합니다. 이 부분은 외주개발 유지보수 SLA 설계 가이드를 참고해 계약 항목으로 분리하는 것이 좋습니다.
10. 인수 완료 보고서에 들어가야 할 산출물
구두 설명은 인수가 아닙니다. 담당자가 바뀌면 사라집니다. 최소한 다음 산출물은 파일 또는 위키 형태로 받아야 합니다.

| 산출물 | 포함 내용 | 합격 기준 |
|---|---|---|
| 인프라 구성도 | 도메인, CDN, 서버, DB, 스토리지, 외부 API 흐름 | 비개발 PM도 장애 구간을 추정할 수 있음 |
| 계정·권한 목록 | 관리자, 개발자, 읽기 전용, 외부 협력사 계정 | 권한 회수 대상이 명확함 |
| 배포 문서 | 브랜치, 명령어, 파이프라인, 승인자, 롤백 | 새 담당자가 스테이징 배포 성공 |
| 환경변수 명세 | 키 이름, 설명, 보관 위치, 재발급 절차 | 값 노출 없이 누락 여부 확인 가능 |
| DB·백업 문서 | 스키마, 마이그레이션, 백업 주기, 복원 방법 | 테스트 복원 기록 존재 |
| 운영비 리포트 | 최근 청구 내역, 월 예상비용, 비용 증가 요인 | 대표가 월 비용을 예산에 반영 가능 |
| 장애 대응 문서 | 알림 채널, 담당자, 1차 조치, 에스컬레이션 | 야간·휴일 장애 연락 기준 존재 |
| 보안 점검표 | MFA, 접근 IP, 공개 포트, 개인정보 접속기록 | 출시 전 위험 항목이 남아 있지 않음 |
11. 외주개발 인수에서 자주 나오는 위험 신호
다음 답변이 반복된다면 인수를 멈추고 추가 점검을 요청하는 것이 좋습니다.
- ‘서버는 저희 계정에 있으니 비용만 보내주시면 됩니다.’
- ‘환경변수는 개발자가 알고 있어서 문서가 없습니다.’
- ‘백업은 자동으로 될 겁니다.’
- ‘DNS는 건드리면 위험하니 그냥 두세요.’
- ‘배포는 담당 개발자 PC에서만 됩니다.’
- ‘운영 DB 접속 계정은 하나만 씁니다.’
- ‘로그는 서버에 들어가서 보면 됩니다.’
- ‘비용은 트래픽이 많아지면 그때 보시죠.’
이 답변들이 모두 나쁜 의도라는 뜻은 아닙니다. 초기 MVP를 빠르게 만들다 보면 운영 문서와 권한 정리가 뒤로 밀릴 수 있습니다. 문제는 출시 후입니다. 고객 데이터가 들어오고 결제가 붙고 마케팅을 시작하면, 작은 권한 누락이 장애 대응 지연과 비용 증가로 연결됩니다.
12. AgentMit이 서버 인수와 유지보수 전환을 볼 때 확인하는 범위
AgentMit은 외주개발 결과물을 단순히 이어받아 수정하는 것보다, 먼저 운영 가능한 구조인지 확인합니다. 특히 웹서비스, SaaS, 관리자 대시보드, 예약·매칭·결제 시스템, 업무자동화, AI 기능이 들어간 서비스는 서버와 데이터 흐름이 기능만큼 중요합니다.
상담 단계에서는 보통 다음 자료를 요청합니다. 현재 서비스 URL, Git 저장소 접근 방식, 클라우드 계정 권한, 도메인·DNS 관리 계정, DB·스토리지 구조, 배포 방식, 최근 장애 이력, 월 비용 내역, 앞으로 추가하려는 기능 범위입니다. 이 자료를 보면 단순 유지보수로 가능한지, 배포 구조부터 정리해야 하는지, 보안·백업을 먼저 보강해야 하는지 판단할 수 있습니다.
BizMit 기반의 SaaS·업무 시스템 개발이나 정부지원 MVP 고도화에서도 같은 기준을 적용합니다. 화면이 예쁘게 완성되는 것보다, 발주사가 계정을 소유하고, 다음 배포를 재현할 수 있고, 비용과 장애를 예측할 수 있어야 실제 서비스로 운영됩니다.
FAQ
Q1. 외주개발 후 AWS·GCP·NCP 계정이 개발사 명의여도 괜찮나요?
장기 운영할 서비스라면 권장하지 않습니다. 서버비 결제, 장애 대응, 개인정보 책임, 업체 교체가 모두 계정 소유권과 연결됩니다. 발주사 법인 이메일과 결제수단으로 클라우드 계정을 만들고 개발사는 필요한 기간 동안 역할 기반 권한을 받아 작업하는 구조가 안전합니다.
Q2. 서버 인수 때 소스코드 말고 꼭 받아야 하는 것은 무엇인가요?
클라우드 루트·관리자 권한, 도메인 등록 계정, DNS 설정, SSL 인증서 갱신 방식, 운영·스테이징 서버 목록, DB 접속 구조, 스토리지 버킷, 환경변수, API 키 목록, CI/CD 배포 권한, 백업 정책, 로그·모니터링, 월 비용 리포트, 장애 대응 문서를 함께 받아야 합니다.
Q3. 환경변수와 API 키를 문서로 달라고 해도 보안상 괜찮나요?
값 자체를 평문 문서로 공유하는 것은 위험합니다. 대신 키 이름, 사용처, 발급 계정, 만료일, 권한 범위, 보관 위치, 재발급 절차를 문서화하고 실제 값은 GitHub Secrets, 클라우드 Secret Manager, 비밀번호 관리자 등 통제된 저장소에서 인수해야 합니다.
Q4. 백업이 있다고 하면 어떻게 검수해야 하나요?
백업 스케줄 화면만 보는 것으로는 부족합니다. 최근 백업 시점, 보관 기간, 백업 대상, 암호화 여부, 다른 계정·리전에 복제되는지, 실제 복원 테스트 결과, 복원 예상 시간, 복원 담당자와 절차를 확인해야 합니다. 가능하면 운영 DB가 아닌 테스트 환경에서 복원 리허설을 진행합니다.
Q5. 외주개발 업체를 교체하기 전 서버 인수는 어떤 순서로 해야 하나요?
먼저 도메인과 클라우드 계정 소유권을 확보하고, 그다음 배포 권한과 환경변수, DB·스토리지 백업, 로그·모니터링, 비용 리포트를 확인합니다. 마지막으로 새 업체가 동일 버전을 스테이징에 배포해 보는 재현 테스트를 진행해야 실제 유지보수 가능 여부를 판단할 수 있습니다.
참고한 공식 문서
이 글의 권한, 백업, 비용, 감사 로그, 도메인 소유권 관련 항목은 특정 클라우드 사업자에 종속된 매뉴얼이 아니라 운영 체크리스트 관점으로 재구성했습니다. 실제 설정명과 정책은 사용 중인 서비스의 최신 공식 문서를 확인해야 합니다.
- AWS IAM Security Best Practices
- AWS Root User Best Practices
- AWS Budgets Documentation
- AWS Backup Restore Testing
- Google Cloud IAM Resource Hierarchy Access Control
- Google Cloud Audit Logs Overview
- NAVER Cloud Platform Sub Account Overview
- Cloudflare Account Roles
- ICANN Information for Domain Name Registrants
- GitHub Actions Secrets
- 국가법령정보센터 개인정보의 안전성 확보조치 기준
마무리: 서버 인수는 출시 직전의 행정이 아니라 운영 리스크 관리입니다
외주개발 프로젝트의 완료 기준을 기능 구현으로만 잡으면, 출시 후 운영 리스크가 발주사에게 남습니다. 계정 소유권, 배포 재현, 백업 복원, 로그 확인, 비용 예측까지 확인해야 비로소 서비스 운영을 시작할 수 있습니다.
이미 개발은 끝났지만 인수 자료가 부족하거나, 업체 교체를 앞두고 서버 구조를 점검해야 하거나, SaaS·관리자·자동화·AI 기능을 실서비스 수준으로 고도화해야 한다면 AgentMit에 범위 검토를 요청해 보셔도 좋습니다. 현재 계정과 서버 구조를 기준으로 유지보수 전환이 가능한지, 어떤 부분을 먼저 정리해야 하는지 현실적인 순서로 함께 점검하겠습니다.

