앱 외주개발 시작 전 접근권한: 회사 계정 공유 대신 5가지를 정하는 법
앱 외주개발 시작 전 접근권한: 회사 계정 공유 대신 5가지를 정하는 법
앱 MVP 외주를 시작할 때 개발사에 소스 저장소, 클라우드, 도메인, 분석 도구 접근을 줘야 할 수 있습니다. 이때 중요한 질문은 “아이디와 비밀번호를 전달할까?”가 아니라 어떤 회사 자산에, 누가, 어떤 일을 위해, 언제까지 접근해야 하는가입니다. 개인의 관리자 계정을 넘기는 대신 회사가 소유한 공간에서 초대와 역할을 분리하면, 착수·변경·종료 시점의 확인 기준도 남길 수 있습니다.
먼저 접근권한과 계정 소유를 분리하세요
외주 인력이 기능을 개발한다고 해서 회사의 모든 관리자 권한이 필요한 것은 아닙니다. 접근권한은 특정 자산에서 특정 행동을 할 수 있는 범위이고, 계정 소유는 그 자산의 최종 관리·결제·복구 책임이 누구에게 있는지에 관한 문제입니다. 두 가지를 같은 개인 계정에 묶으면, 외주 종료 뒤에도 무엇을 회수하고 누가 확인할지 흐려집니다.
Google Cloud의 IAM 보안 가이드는 필요한 범위 중 가장 작은 범위에서 역할을 부여하고, 광범위한 Owner 역할은 거의 모든 자원과 정책을 바꿀 수 있으므로 보편 접근이 필요한 경우에만 쓰라고 안내합니다. GitHub도 조직 저장소 역할을 나누고 역할에 맞는 범위만 부여하도록 설명합니다. 이 글은 특정 서비스의 설정 방법이 아니라 그 원칙을 MVP 외주 착수 기록으로 옮기는 방법입니다.
이미 개발이 끝난 뒤 자산을 되찾는 상황이라면 앱 외주개발 인수인계 체크리스트를 함께 보세요. 이 글은 그보다 앞선 착수 시점에 권한을 어떻게 열지에 집중합니다.
외주 시작 전 한 장에 적을 5가지
1. 자산 이름과 회사 소유자를 씁니다
소스 저장소, 배포 환경, 도메인 관리, 앱 스토어 콘솔, 분석 도구처럼 자산을 나열합니다. 각 항목마다 회사 안에서 최종 소유·복구·결제 확인을 맡는 사람 또는 팀을 적습니다. “개발사가 만들었으니 개발사 계정”처럼 추정하지 말고, 현재 실제로 로그인·복구 권한을 가진 주체를 확인하세요.
2. 필요한 작업과 최소 역할을 연결합니다
“개발 접근” 한 줄 대신, 보기·코드 반영·배포·설정 변경·결제 확인처럼 필요한 작업을 나눕니다. GitHub 문서는 조직 저장소에 Read, Triage, Write, Maintain, Admin처럼 다른 역할을 둘 수 있다고 설명합니다. 실제 서비스의 역할 명칭은 달라도, 필요한 일을 먼저 적고 그 일을 할 수 있는 가장 좁은 역할을 확인하는 방식은 그대로 적용할 수 있습니다.
3. 개인 로그인 공유 대신 초대 경로를 정합니다
개인 비밀번호, 복구 수단, 인증 코드를 전달하는 방식은 누가 어떤 작업을 했는지 구분하기 어렵게 만들 수 있습니다. 가능하다면 회사가 소유한 조직·프로젝트에 외부 협업자를 초대하고, 초대 대상·자산·역할·승인자를 기록하세요. 초대 기능이 없는 도구라면 대체 운영 방식과 책임자를 별도 문서에 남기고, 비밀값을 작업 티켓·메신저·스크린샷에 복사하지 않는 기준을 정합니다.
4. 시작·변경·회수 조건을 같이 적습니다
권한을 준 날짜만 적으면 범위가 커졌을 때 확인하기 어렵습니다. 시작 전에는 승인자와 최초 역할, 진행 중에는 역할 변경 이유와 승인자, 종료 전에는 회수 대상과 확인자를 적어 두세요. Google Cloud는 조건부 역할 바인딩으로 접근 만료를 둘 수 있고, 일시적 상향 권한을 고려할 수 있다고 안내합니다. 모든 도구가 이 기능을 제공하는 것은 아니므로, 도구 기능을 단정하지 말고 팀의 회수 시점과 확인 방식을 먼저 결정하면 됩니다.
5. 권한표와 실제 화면을 함께 검수합니다
문서에 Write라고 적었다고 실제로 그 범위만 열렸다는 뜻은 아닙니다. 초대 후에는 외주 인력과 회사 담당자가 필요한 작업만 가능한지, 불필요한 관리자 화면이나 다른 프로젝트가 보이지 않는지 확인합니다. OWASP는 설계 단계에서 사용자 유형·자원·행동을 열거하고, 권한이 올바르게 적용되는지 테스트하며, 배포 후에도 권한이 과도해지지 않았는지 주기적으로 검토하라고 권고합니다.
자산별로 같은 권한을 주지 마세요
아래 표는 특정 제품의 필수 설정값이 아니라, 외주 착수 전 팀이 확인할 질문입니다. 각 행의 실제 역할과 방법은 사용 중인 도구·계약 범위·데이터 흐름에 따라 달라질 수 있습니다.
자산 | 외주 작업의 예 | 착수 전 확인 질문 |
|---|---|---|
소스 저장소 | 코드 확인·변경 요청 제출 | 저장소별 역할, 리뷰·병합 권한, 외부 협업자 초대가 분리되어 있는가? |
클라우드·배포 | 개발·테스트 환경 확인 | 운영 환경까지 필요한가, 프로젝트·자원 범위를 더 좁힐 수 있는가? |
도메인·DNS | 연결값 확인 또는 변경 요청 | 변경 권한과 최종 승인자가 구분되어 있는가? |
분석·오류 도구 | 이벤트·오류 원인 확인 | 개인정보나 운영 데이터가 불필요하게 넓게 노출되지 않는가? |
앱 스토어 콘솔 | 빌드 제출 준비 | 제출·정산·계약 관련 권한을 같은 역할에 묶을 필요가 있는가? |
외주 계약에서 무엇을 공유해도 되는지 정리하는 단계는 앱 MVP 외주 전 NDA 글과 연결해서 볼 수 있습니다. 하지만 NDA가 있다고 해서 모든 관리자 접근이 필요한 것은 아닙니다. 공유 자료의 범위와 시스템 권한의 범위를 각각 확인하세요.
권한 요청이 들어왔을 때의 짧은 판단 순서
요청한 사람이 누구인지와 맡은 작업을 확인합니다.
그 작업에 필요한 자산과 행동을 한 줄로 적습니다.
더 좁은 프로젝트·저장소·역할로 가능한지 먼저 봅니다.
회사 소유자와 승인자가 같은지, 다르다면 누가 최종 확인하는지 남깁니다.
초대 후 실제 범위와 종료·회수 조건을 검수 기록에 적습니다.
이 순서는 “이 권한이면 안전하다”는 보증이 아닙니다. 서비스 구조, 외주 범위, 고객 데이터, 배포 방식, 계약 내용에 따라 필요한 보안·법무 검토가 달라질 수 있습니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 특정 도구 설정, 정보보안 수준, 법적 적합성, 앱 심사 또는 사업 성과를 보장하지 않습니다.
자주 묻는 질문
개발사에 회사 관리자 계정을 그대로 줘도 되나요?
모든 상황에 같은 답을 적용할 수 없습니다. 다만 필요한 작업·자산·기간을 먼저 적고, 회사 소유 공간에서 역할이나 초대 범위를 분리할 수 있는지 확인하는 편이 좋습니다. Google Cloud와 GitHub의 공식 문서도 필요한 범위를 넘기지 않는 역할 부여를 설명합니다. 실제 접근 방식은 사용 도구와 계약 범위에 맞춰 정하세요.
외주개발 중에는 관리자 권한이 꼭 필요하지 않나요?
필요한 작업에 따라 다릅니다. 코드 반영, 배포 설정 확인, 결제·조직 관리처럼 작업의 성격이 다르므로 한 가지 권한으로 묶지 않는 편이 좋습니다. 필요한 행동과 자산을 연결한 뒤, 더 좁은 역할로 가능한지 실제 도구 화면에서 확인하세요.
권한 회수는 개발이 끝난 뒤에만 하면 되나요?
종료 시점만 보지 않는 편이 좋습니다. 역할이 바뀌거나 담당자가 바뀔 때도 변경 이유와 승인자를 남기고 실제 권한을 다시 확인하세요. OWASP는 배포 후에도 권한이 설계된 범위를 넘지 않는지 주기적으로 검토할 것을 권고합니다.
비밀번호나 인증 코드를 문서에 적어도 되나요?
실제 비밀번호, 인증 코드, 토큰 같은 비밀값은 작업 문서·티켓·메신저·스크린샷에 남기지 않는 편이 좋습니다. 문서에는 초대 대상, 자산, 역할, 승인자, 확인 시각처럼 권한 검수에 필요한 최소 기록만 남기세요.