앱 외주개발 서비스 계정 인수: 소유권·권한·비밀값 교체를 나누는 5가지 기준
앱 외주개발 서비스 계정 인수: 소유권·권한·비밀값 교체를 나누는 5가지 기준
앱 외주개발이 끝날 때 “계정 정보를 받았다”는 말만으로 운영 인수가 끝났다고 판단하면 위험합니다. 사람이 로그인하는 계정, 자동화가 호출하는 서비스 계정, 배포 과정의 비밀값, 결제·분석 도구의 소유 조직, 긴급 상황에서 되돌릴 수 있는 경로는 서로 다른 대상입니다. 하나의 스프레드시트에 아이디를 모아 두는 일과 실제 운영 권한이 이전되는 일도 같습니다.
GitHub는 조직 역할로 전체 관리자 권한을 주지 않고도 특정 작업 권한을 부여할 수 있다고 안내합니다(C001). 또 GitHub Actions의 비밀값은 저장 위치와 접근 정책에 따라 범위가 달라질 수 있으며, 장기 자격 증명 대신 OIDC 같은 직접 인증 경로를 검토할 수 있다고 설명합니다(C002). Google Cloud도 서비스 계정을 사람 계정과 구분되는 워크로드용 ID로 설명합니다(C003). 다만 이 글은 특정 도구의 설정값이나 귀사의 계약 범위를 대신 판단하지 않습니다.
먼저 답하기: 서비스 계정 인수는 ‘비밀번호 전달’이 아니라 소유·권한·비밀값·자동화·복구를 각각 검증하는 일입니다
가장 먼저 계정 목록을 두 종류로 나눕니다. 사람의 이름으로 로그인하는 사용자 계정과, 앱·배포·연동 작업이 호출하는 비인간 계정입니다. 그다음 각 항목에 소유 조직, 현재 관리자, 사용 목적, 연결된 자동화, 마지막 접근 검증일, 비상시 복구 담당을 따로 기록합니다. 알 수 없는 항목을 추측해 채우지 않는 것이 인수의 시작입니다.
구분 | 확인할 질문 | 완료로 오해하기 쉬운 신호 |
|---|---|---|
소유권 | 조직이 관리·결제·복구 권한을 갖는가 | 외주사가 초대 링크를 보냄 |
사람 권한 | 운영자별 필요한 역할과 승인자는 누구인가 | 새 운영자가 로그인함 |
서비스 계정 | 어떤 워크로드가 어떤 권한으로 쓰는가 | 키 파일 한 개를 받음 |
비밀값 | 저장 위치·접근 범위·교체 순서는 무엇인가 | 비밀값 목록만 복사함 |
복구 | 교체 실패나 장애 때 누가 어디서 되돌리는가 | 담당자 연락처만 있음 |
표는 모든 서비스에 같은 권한을 요구하는 양식이 아닙니다. 현재 확인된 사실, 아직 확인하지 못한 사항, 실제 변경 전 필요한 승인과 검증 순서를 분리하기 위한 기록 틀입니다.
기준 1: 소유 조직과 사람별 역할을 먼저 확인합니다
외주 개발자 개인 계정이 유일한 관리자인 상태에서는 로그인 정보를 받아도 조직이 운영 권한을 확보했다고 볼 수 없습니다. 해당 서비스의 조직·프로젝트·결제 계정에서 누가 소유자 또는 관리자 역할을 갖는지, 운영자가 어떤 업무 때문에 어느 범위의 권한이 필요한지 목록으로 확인하세요.
GitHub의 조직 역할 문서는 특정 작업을 수행하는 역할을 사용자나 팀에 할당할 수 있음을 설명합니다(C001). 이 사실은 모든 외주 프로젝트가 GitHub를 사용한다는 뜻도, 특정 역할 구성이 항상 충분하다는 뜻도 아닙니다. 다만 ‘전체 관리자 하나’와 ‘업무별 권한’은 다른 결정이라는 점을 점검하는 공식 근거가 됩니다.
기준 2: 서비스 계정은 사람 계정과 별도 자산으로 기록합니다
서버 배포, 백업, 분석 수집, 푸시 발송처럼 사람이 직접 로그인하지 않는 작업에는 서비스 계정이나 토큰이 쓰일 수 있습니다. Google Cloud는 서비스 계정을 워크로드가 쓰는 ID로 설명하며, 생성·권한 부여·키 관리가 별도 관리 대상임을 안내합니다(C003). 실제 서비스가 Google Cloud가 아니라면 해당 공급자의 공식 문서에서 같은 역할을 확인해야 합니다.
인수표에는 계정 이름이나 키 값 자체를 쓰지 말고, 목적·소유 프로젝트·필요 권한·연결 자동화·교체 담당자처럼 노출 위험이 낮은 메타데이터를 남기세요. 비밀값을 문서나 메신저에 복사하는 행위는 인수 증거가 아니라 새로운 노출 경로가 될 수 있습니다.
기준 3: 비밀값 교체는 의존성 확인 뒤에 순서를 정합니다
비밀값을 바꾸는 일은 중요하지만, 교체 자체가 완료 신호는 아닙니다. 배포 워크플로, 서버 환경변수, 외부 API, 예약 작업이 같은 자격 증명을 참조하는지 먼저 확인해야 합니다. GitHub는 저장소·환경·조직 단위의 비밀값과 접근 정책을 구분해 설명합니다(C002). 어느 범위에 있는 비밀값인지 모른 채 한 곳만 바꾸면 나머지 자동화가 이전 값을 계속 쓸 수 있습니다.
안전한 기록 순서는 ‘변경 대상 확인 → 영향받는 작업 확인 → 새 값 등록 → 제한된 검증 → 이전 값 폐기 여부 판단 → 결과 기록’입니다. 실제 도구의 교체 방식과 폐기 가능 시점은 공급자 문서와 계약상 지원 범위에 따라 달라지므로, 이 순서를 특정 보안 설정의 보장으로 해석하면 안 됩니다.
기준 4: 자동화의 성공 메시지와 운영 권한 확보를 구분합니다
배포가 한 번 성공했거나 대시보드가 열렸다고 해서 모든 인수가 끝난 것은 아닙니다. 그 실행이 어떤 계정과 환경을 사용했는지, 새 운영자가 승인·로그 확인·복구를 할 수 있는지, 실패 시 알림이 누구에게 가는지를 분리해 확인해야 합니다. 특히 외주사의 개인 이메일이나 개인 장치에만 알림·복구 수단이 남아 있다면 조직의 운영권은 아직 완전히 이전되지 않았을 수 있습니다.
이 단계에서는 실제 고객 데이터나 비밀값을 문서에 옮기지 마세요. 작업명, 확인일, 확인자 역할, 성공·실패 상태, 다음 조치만 기록해도 인수 진행 상황을 충분히 구분할 수 있습니다.
기준 5: 권한 축소와 비상 복구를 같은 날의 한 작업으로 보지 않습니다
인수가 끝난 뒤 외주 인력의 접근을 줄이는 결정은 필요할 수 있습니다. 그러나 새 운영자의 접근 검증, 배포·연동의 정상 동작, 비상 연락과 되돌리기 절차가 준비되기 전에 일괄 삭제하면 복구 책임이 더 불명확해질 수 있습니다. 계약 종료일, 유지보수 지원 범위, 장애 대응 약속은 실제 계약서와 상대 서비스의 설정을 기준으로 따로 확인하세요.
운영 전환 전체 흐름을 더 점검하려면 앱 외주개발 운영 전환: 배포 승인·환경값·되돌리기를 나누는 5가지 기준도 함께 보세요. 이 글은 배포 전환의 책임 경계를, 현재 글은 서비스 계정과 비밀값 인수의 기록 경계를 다룹니다.
인수 직전에 남길 최소 기록
각 사람 계정과 서비스 계정의 소유 조직·목적·현재 역할
비밀값 자체가 아닌 저장 위치·영향 작업·교체 상태
새 운영자의 제한된 접근·배포·로그 확인 결과
외주 접근 축소 전 필요한 계약·지원 범위 확인
교체 실패 시 연락·되돌리기·다음 확인 시점
이 다섯 줄은 인수 완료를 선언하는 문구가 아닙니다. 확인된 사실과 남은 의존성을 분리하는 운영 기록입니다. 실제 서비스의 권한, 자격 증명, 계약상 의무와 개인정보 처리 범위는 각 공급자의 최신 문서와 조직의 승인 절차로 다시 검토하세요.
자주 묻는 질문
외주사가 계정 정보를 전달하면 인수가 끝난 건가요?
아닙니다. 로그인 가능 여부는 한 가지 관찰일 뿐입니다. 소유 조직, 사람별 권한, 자동화가 쓰는 비밀값, 긴급 복구 경로와 실제 접근 검증을 각각 확인해야 합니다.
서비스 계정 비밀값은 모두 즉시 바꿔야 하나요?
서비스와 자동화의 의존성을 확인하지 않고 일괄 교체하면 배포나 연동이 멈출 수 있습니다. 어떤 작업이 어떤 자격 증명을 쓰는지 기록하고, 교체·검증·되돌리기 순서를 정한 뒤 진행하세요.
외주 개발자 권한을 바로 삭제해도 되나요?
최소 권한 원칙은 중요하지만, 운영자가 복구할 수 있는지와 계약상 지원·인수 범위를 먼저 확인해야 합니다. 접근을 줄이는 결정과 실제 삭제 시점은 별도로 남기세요.
인수 체크리스트를 지키면 보안이나 장애가 보장되나요?
아닙니다. 이 글은 특정 서비스의 보안 인증이나 장애 예방을 보장하지 않는 운영 기록 틀입니다. 실제 권한 설계와 계약, 사용하는 서비스의 공식 문서를 함께 검토해야 합니다.
출처: GitHub Actions secrets, GitHub organization roles, Google Cloud service accounts