외주 개발 프로젝트가 마무리되는 순간, 발주자가 가장 많이 빠뜨리는 단계가 클라우드·인프라 인계예요. Git 레포·디자인 원본은 챙기지만, AWS/GCP 콘솔의 명의·결제 카드·IAM 키·도메인 DNS·모니터링 토큰은 외주사 계정에 남아 있는 채로 잔금이 정산되곤 해요. 그러다 3개월 뒤 갑자기 신규 기능 배포하려고 콘솔에 들어가면, 비밀번호가 바뀌어 있고 외주사 담당자가 퇴사한 상태예요.
2026년 들어 저희에게 들어오는 외주 개발사 교체 의뢰의 약 35%가 "코드는 받았는데 인프라가 외주사 명의로 묶여 있어 운영을 못 한다" 는 케이스였어요. 한 달 안에 풀 수 있는 문제이지만, 인계 단계에서 7가지를 합의해 두지 않으면 인수자가 사후에 1,000~3,000만원 비용을 추가로 떠안기 시작해요. 오늘은 그 7단계를 한 페이지로 정리해 봤어요.
이유는 단순해요. 클라우드 자원은 '명의'·'결제'·'권한'·'네트워크' 4개 레이어가 분리되어 있고, 각 레이어가 서로 다른 시점에 정리돼야 해요. 명의는 콘솔 소유 계정, 결제는 카드/세금계산서, 권한은 IAM/IRSA/SSO, 네트워크는 도메인·DNS·SSL·CDN. 이 중 하나라도 외주사 쪽에 남아 있으면, 발주자가 콘솔에는 들어갈 수 있어도 결제·DNS 변경·SSL 갱신 같은 결정적 순간에 막혀요.
실제 사례 하나. 작년 한 푸드테크 스타트업은 외주 개발사가 자기 법인 카드로 AWS 결제를 걸어 두고 나갔어요. 6개월 뒤 외주 분쟁이 터지자 외주사가 카드 분리를 거부했고, 한 주 동안 청구서가 발주자에게 안 들어와서 'past due' 상태로 가다가 RDS·CloudFront 가 일부 정지될 뻔했어요. 인수인계 12자산 가이드의 시크릿 인벤토리 항목과 짝으로 운영하면 이런 사고는 막을 수 있어요.
가장 먼저 하는 게 AWS Account / GCP Organization / Azure Tenant 의 루트 계정 이메일을 발주자 도메인 이메일로 변경하는 거예요. 외주사가 자기 도메인 이메일(예: vendor@xxxstudio.com)로 만들어 둔 계정을, 발주자 도메인 이메일(예: aws-root@yourcompany.com)로 바꿔야 해요. AWS 의 경우 Account Settings > Contact Information 에서 변경하고, MFA 디바이스도 발주자 측 보안 담당자가 등록한 새 디바이스로 갈아끼워야 해요. 이 작업이 끝나야 다음 단계가 의미가 있어요.
발주자 명의 카드를 등록하고, 외주사 카드는 즉시 제거해요. 분기 정산이 걸린 경우 발주자 카드와 외주사 카드를 한 달간 병행 등록하는 안전 모드도 가능해요. 세금계산서 발행처도 발주자 사업자번호로 변경하고, 직전 1~3개월 청구서를 PDF 로 모두 다운로드해서 보존해요. 결제 분리가 끝나야 외주사가 콘솔에 남아 있어도 자원 사용량을 더 늘릴 수 없어요.
외주사 도메인 이메일로 만들어진 모든 IAM 사용자를 비활성화하고, 사용 중인 Access Key 와 Service Account Key 를 새 키로 교체해요. EKS/GKE 의 IRSA·Workload Identity 도 점검해서, 외주사 IAM 역할에 묶인 워크로드를 발주자 측 역할로 다시 매핑해요. 이 단계에서 누락이 가장 흔하게 발생해요. CI/CD GitHub Actions 의 OIDC 설정도 같이 점검하지 않으면, 외주사 IAM 역할이 사라진 다음 날 배포가 모두 실패해요.
AWS Secrets Manager / Parameter Store, GCP Secret Manager, GitHub Actions Secrets, Vercel/Netlify Env, Supabase service_role, 토스페이먼츠 시크릿 키, OpenAI/Anthropic API 키, Sentry/Datadog/Slack 웹훅 — 사용 중인 모든 시크릿을 한 페이지 인벤토리로 정리하고, 인계일 기준으로 로테이션할 키 목록과 그대로 둘 키 목록을 분리해요. 외주사가 한 번이라도 본 적 있는 키는 원칙적으로 모두 로테이션해요.
도메인 등록 대행사(가비아·후이즈·Cloudflare Registrar) 의 소유자 정보를 발주자 명의로 변경하고, DNS 호스팅 계정도 발주자 콘솔로 이전해요. SSL 인증서가 발급된 인증기관 계정(예: Let's Encrypt 자동 갱신용 IAM 키, 유료 SSL 의 갱신 알림 이메일) 도 같이 이전해야 다음 갱신 주기에 SSL 만료 사고가 안 터져요. CDN(Cloudflare/CloudFront) API 토큰도 새로 발급해서 외주사 토큰을 폐기해요.
Sentry, Datadog, Grafana Cloud, NewRelic, Slack incident 채널, PagerDuty/OpsGenie 의 권한을 모두 발주자 측 사용자로 이전하고 외주사 사용자는 'View Only' 로 한 달간 유지하다가 인계 D+30 일에 완전 제거해요. 이 1개월 'View Only' 기간이 중요한 이유는, 인계 직후 발생하는 P1/P2 인시던트의 컨텍스트를 외주사가 한 번 더 자문해 줄 수 있게 하기 위함이에요.
최종 사인오프 문서에 (a) 명의 이전 완료 스크린샷 5장, (b) 분리된 결제·세금계산서 증빙, (c) 로테이션 완료된 시크릿 목록(해시), (d) 30/60/90 비상 자문 SLA(예: 30일 무상, 60일 시간당 18만원, 90일 시간당 22만원)를 첨부해요. 비상 자문은 인계 직후 1개월에 평균 0.7건이 발생해요. 이걸 미리 합의해 두면, 외주사가 갑자기 사라져서 발주자가 정해진 가격에 사람을 못 구하는 상황을 막을 수 있어요.
외주 개발 잔금 정산은 코드 검수 후 바로 끝나는 게 아니라, 클라우드 인계가 끝난 시점에 진짜로 끝나요. 이 7단계를 사인오프 직전 2주 동안 차례로 풀어 두면, 인계 후 1년 동안 마주칠 운영 사고의 60% 가 미리 사라져요.
포텐랩은 30개 이상 외주 프로젝트에서 '클라우드 인계 + 30/60/90 비상 SLA' 를 표준 마지막 단계로 운영하고 있어요. 외주 개발사를 찾고 계시다면 포텐랩에 상담을 한번 받아 보세요. 수행완수율 97%, Notion 기반 투명 소통, 그리고 끝까지 이전 가능한 명의·결제·권한 구조로 안정적 파트너십을 약속드려요.