개발 착수 미팅은 보통 권한 이야기로 끝납니다. 서버 접속 정보, 클라우드 콘솔, 도메인 관리자 페이지, 앱 스토어 계정을 한꺼번에 열어달라는 요청이 들어옵니다. 일정이 급하니 대표 계정 아이디와 비밀번호를 그대로 넘기는 경우가 많습니다.
문제는 납품 이후입니다. 검수가 끝나고 잔금까지 치렀는데 외주사 담당자의 계정이 그대로 살아 있는 회사가 많습니다. 누구에게 무엇을 언제 열어줬는지 적어둔 곳이 없으면, 닫을 목록 자체를 만들 수 없습니다.
루트·대표 계정을 공유하면 회수 방법이 비밀번호 변경뿐입니다
대표 계정 하나를 여러 사람이 함께 쓰면 접속 기록에 전부 같은 사람으로 남습니다. 장애가 났을 때 누가 무엇을 바꿨는지 가릴 수 없고, 권한을 거두려면 비밀번호를 바꿔 모두를 한꺼번에 끊는 방법밖에 없습니다.
AWS 공식 문서는 루트 사용자용 액세스 키를 만들지 말라고 명시합니다. 루트 사용자는 결제 정보를 포함해 계정의 모든 서비스와 리소스에 접근할 수 있기 때문입니다. 멤버 계정이라면 루트의 비밀번호와 액세스 키, 서명 인증서를 아예 제거하라고 권고합니다.
루트나 대표 계정 공유는 "급해서 한 번만"이 통하지 않는 항목입니다. 한 번 넘기면 그 계정은 계약이 끝날 때까지 공용 계정이 됩니다.
클라우드는 서브계정보다 임시 자격 증명이 먼저입니다
AWS는 사람이 접근할 때 장기 자격 증명 대신 IAM Identity Center와 임시 자격 증명을 쓰라고 권고합니다. 공식 문서는 사람 사용자에 "함께 협업하는 외부 사용자"도 포함된다고 적어두었습니다. 외주 인력이 바로 이 경우입니다.
다만 Identity Center를 지원하지 않는 서드파티 클라이언트나 AWS 외부에서 돌아가는 벤더 환경이라면 IAM 사용자의 장기 액세스 키를 쓰라고 같은 문서가 허용합니다. 외주사 빌드 서버가 여기에 해당하는 일이 많습니다.
장기 키를 발급했다면 액세스 키는 사용자당 최대 2개라는 제한과 '마지막 사용 시각' 정보를 함께 쓰세요. 실제로 쓰이지 않는 키를 확인한 뒤 비활성화하고, 문제가 없으면 삭제하는 순서가 공식 절차입니다.
스토어 권한은 계정 전체가 아니라 앱 단위로 주세요
Google Play Console 권한은 계정 수준과 앱 수준으로 나뉩니다. 계정 수준은 개발자 계정의 모든 앱에 적용되고, 앱 수준은 선택한 앱에만 적용됩니다. 외주사에는 앱 수준만 주는 것이 기본입니다.
App Store Connect 역할은 Account Holder, Admin, App Manager, Developer, Finance, Marketing, Sales, Customer Support 여덟 가지입니다. 공식 도움말에 따르면 앱별 접근 제한은 App Manager, Developer, Marketing, Sales, Customer Support에서 가능하고 Admin과 Finance는 제한할 수 없습니다.
같은 문서는 보고서(Reports) 접근 권한을 함께 주면 앱 제한이 적용되지 않는다고 안내합니다. 외주사에 매출 보고서까지 열어줄 이유는 보통 없으니 그 체크는 빼세요.
구글 플레이는 권한에 만료일을 걸 수 있습니다
Play Console은 사용자를 초대할 때 'Set access expiry date'를 선택해 만료일을 함께 넣을 수 있습니다. 공식 도움말은 만료일을 정하지 않으면 사용자가 무기한으로 접근한다고 분명히 적어두었습니다.
이미 초대한 사용자도 사용자 상세 페이지에서 만료일을 걸 수 있고, 권한 그룹에도 같은 설정이 있습니다. 계정 소유자는 여러 사용자의 만료일을 한 번에 연장할 수도 있습니다.
검수 예정일에 2주를 더한 날짜를 만료일로 넣으시길 권합니다. 잊고 못 닫는 상황이 사라지고, 하자보수가 길어지면 연장하면 됩니다. 초대는 30일 안에 수락하지 않으면 만료되니 발급 시점도 맞춰두세요.
코드 저장소는 조직 구성원이 아니라 외부 협력자로 넣으세요
GitHub의 외부 협력자는 조직 구성원이 아니면서 조직 저장소 하나 이상에 접근하는 사람입니다. 외부 협력자는 팀에 넣을 수 없어서 권한이 저장소별로만 붙습니다. 회수 범위가 분명해지는 쪽이 오히려 장점입니다.
저장소 역할은 Read, Triage, Write, Maintain, Admin 순으로 권한이 커집니다. 코드를 푸시하고 풀 리퀘스트를 병합하는 작업은 Write로 충분합니다. 협력자 접근 관리와 저장소 삭제·공개 범위 변경은 Admin에만 있습니다.
유료 플랜에서 비공개 저장소에 외부 협력자를 추가하면 라이선스 1개를 사용합니다. 포크에서 작업하게 할 거라면 포크에도 따로 추가해야 접근이 됩니다.
권한을 준 날짜와 범위는 계정 밖에 적어두세요
콘솔 화면은 '지금 누가 있는지'만 보여줍니다. 언제 어떤 이유로 열어줬는지는 남지 않습니다. 그래서 권한 대장을 계약 폴더 안에 따로 두는 편이 안전합니다. 표 한 장이면 됩니다.
- 시스템 이름: 클라우드, 서버, 저장소, 스토어, 도메인 중 무엇인지
- 계정 식별자: 초대한 이메일 주소 또는 IAM 사용자명
- 부여한 역할과 범위: 어느 앱, 어느 저장소, 어느 서버까지인지
- 부여일과 만료 예정일
- 요청자와 승인자 이름
- 회수일과 회수를 확인한 사람
콘솔 기록에만 의존하면 늦습니다. GitHub 조직 감사 로그는 최근 180일 이벤트만 보여주고 조직 소유자만 볼 수 있습니다. 1년 전 프로젝트의 발급 내역은 거기서 찾을 수 없습니다.
검수가 끝나면 닫을 항목은 이 여섯 가지입니다
잔금 지급 전에 한 번에 처리하는 것이 가장 쉽습니다. 돈이 넘어간 뒤에는 회수 요청에 대한 응답이 눈에 띄게 느려집니다.
- 서버 접속 키와 SSH 공개키: 서버에 등록된 외주사 키를 직접 지웁니다
- 클라우드 액세스 키: 비활성화한 뒤 삭제까지 확인합니다
- 2단계 인증 등록 기기와 백업 코드: 외주사 담당자 휴대폰이 등록돼 있으면 해제하고 백업 코드를 재발급합니다
- 결제수단: 외주사 카드로 결제 중인 서비스를 자사 카드로 바꿉니다
- 코드 저장소 권한: 외부 협력자 제거와 배포 키·토큰 정리를 함께 합니다
- 관리자 계정: 스토어 사용자 삭제와 클라우드 관리자 권한 회수
Apple 쪽 사용자 삭제는 Account Holder 또는 Admin 역할이 필요합니다. 공식 도움말은 캐시 때문에 접근 차단이 완전히 끝나기까지 최대 10분이 걸릴 수 있다고 안내하니, 삭제 직후 접속이 된다고 해서 실패로 보지 마세요.
사람을 지워도 남는 열쇠가 따로 있습니다
가장 자주 놓치는 항목은 사람 계정이 아니라 기계용 열쇠입니다. GitHub 공식 문서는 저장소에 배포 키를 추가하면 그 개인 키를 가진 사람은 나중에 조직에서 제거된 뒤에도 저장소를 읽거나 쓸 수 있다고 경고합니다.
같은 구조가 다른 곳에도 있습니다. 서버 환경변수 파일에 적힌 데이터베이스 비밀번호, CI에 저장된 배포 토큰, 외주사 개인이 만든 스토어 API 키가 그렇습니다. App Store Connect는 사용자당 개인 API 키를 1개 가질 수 있고, Account Holder나 Admin이 조회하고 폐기할 수 있습니다.
계정 목록만 비우고 끝내면 문은 닫고 창문은 열어둔 셈입니다. 키와 토큰은 사람과 별도로 세어야 합니다.
바로 못 닫는 항목은 계약서에 기간과 조건으로 적어두세요
하자보수 기간에는 외주사가 서버를 들여다봐야 하는 일이 생깁니다. 그래서 '납품일에 전부 회수'는 지켜지지 않습니다. 남길 권한을 범위와 기간으로 못 박아두는 편이 현실적입니다.
예를 들어 이렇게 씁니다. 하자보수 기간 6개월 동안 운영 서버 로그 읽기 권한과 테스트 트랙 배포 권한만 유지하고, 데이터베이스 접속·결제 설정·관리자 권한은 검수 완료일에 회수합니다. 추가 작업은 건별로 요청받아 임시 권한을 발급하고 작업 종료 시 회수합니다.
함께 넣을 조항은 세 가지입니다. 외주사가 보관한 소스와 데이터 사본의 삭제 확인서, 재위탁 시 사전 서면 동의, 회수 지연에 대한 책임입니다. 삭제 확인서는 서면으로 받아두는 것만으로도 나중에 쓸 데가 생깁니다.
이렇게 하면 오히려 일정이 느려지는 경우도 있습니다
개발 인원 1~2명, 기간 4주짜리 프로젝트에 권한 체계를 세밀하게 설계하면 손해입니다. 권한 신청과 승인에 드는 시간이 줄어드는 위험보다 큽니다. 1인 개발사와 일할 때는 특히 그렇습니다.
이 규모에서는 설계를 늘리지 말고 범위를 좁히세요. 운영 서버는 열지 않고 개발 서버만 주는 것, 저장소 하나만 외부 협력자로 붙이는 것, 스토어는 내부 테스트 트랙까지만 주는 것으로 끝나는 경우가 많습니다. 반대로 운영과 유지보수까지 계속 맡긴다면 회수가 아니라 만료일 갱신 주기를 정하는 문제가 됩니다.
권한 범위를 정리할 때는 실무 가이드의 다른 글도 참고하세요. 스토어 설정은 Google Play Console 공식 도움말, 클라우드는 AWS IAM 보안 권고를 그대로 따르면 됩니다. 계약 단계에서 범위를 함께 정리하고 싶다면 Codeforest에 문의하세요.
결론: 여는 날과 닫는 날을 같은 문서에 적어두세요
개발 기간에 열어줄 범위는 '그 담당자가 그 주에 하는 작업'까지입니다. 루트와 대표 계정은 공유하지 않고, 클라우드는 임시 자격 증명이나 별도 사용자로, 스토어는 앱 단위로, 저장소는 외부 협력자 Write로 주면 대부분 충분합니다.
닫을 때는 접속 키와 SSH 키, 2단계 인증 기기, 결제수단, 저장소 권한과 배포 키, 관리자 계정을 목록으로 확인하세요. 하자보수 때문에 남겨야 하는 권한은 범위와 기간을 계약서에 적고, 그 날짜를 권한 대장에 함께 남기면 됩니다.