Lambda Cloud IAM: GPU 자동화를 개인 키에서 옮길 때 놓치기 쉬운 권한

개인의 권한을 빌리던 작업에 별도 주체가 생겼다

GPU 클라우드 업체 Lambda가 2026년 11월 4일 IAM을 발표했다. 여기서 Lambda는 AWS Lambda 함수 서비스와 다른 회사다. 이번 기능은 사람과 자동화 프로그램에 역할을 배정하는 RBAC, 즉 역할 기반 접근 제어다. 기존 키는 그대로 동작하며, IAM 자체는 무료이고 실행 자원의 비용은 별도로 발생한다. 공식 발표

이 변화는 야간 작업을 다른 담당자에게 넘기는 팀에 유용하다. 개인 키를 새 담당자의 키로 갈아 끼우는 대신, 작업 자체에 service identity(서비스 신원)를 줄 수 있기 때문이다. 다만 독립된 이름을 얻는 것과 최소한의 접근만 갖는 것은 다르다.

이 글은 11월 6일 확인한 공식 문서를 바탕으로 한 도입 분석이다. 아래의 gpu-cleanup 작업과 sandbox·production 워크스페이스는 가상 사례다. 계정 생성, 실제 콘솔 조작, API 거절 응답이나 GPU 종료를 시험한 결과는 제시하지 않는다. 독자가 얻을 결과는 자신의 자동화를 이전하기 전에 채워 볼 권한 인수표와 교체 순서다.

키·소속·역할을 따로 읽어야 하는 이유

서비스 신원은 자동화 프로그램을 나타낸다. API 키는 그 신원으로 요청하기 위한 자격 증명이다. 역할은 할 수 있는 작업을 묶고, 워크스페이스는 자원이 속한 작업 공간이다. 그룹에는 사용자와 서비스 신원을 넣을 수 있으며 구성원은 그룹의 역할과 워크스페이스 소속을 물려받는다. 계정 역할에 포함된 워크스페이스 권한은 해당 신원이 소속된 워크스페이스에 적용되고, 워크스페이스 역할은 지정한 공간에 적용된다. IAM의 관계와 범위

운영 인수 때는 다음 질문을 각각 답해야 한다.

확인할 것	가상 정리 작업의 목표	놓쳤을 때 생기는 문제
실행 주체	gpu-cleanup 전용 서비스 신원	담당자의 다른 업무 권한까지 함께 의존한다
자원 범위	sandbox만 대상	다른 공간의 인스턴스도 작업 후보가 된다
허용 작업	목록 조회와 승인된 정리 대상 종료	새 인스턴스 생성이나 방화벽 수정까지 가능해진다
자격 증명 수명	교체 담당자와 만료·폐기 시점 기록	스크립트를 옮긴 뒤에도 옛 키가 남는다
업무 조건	정리 대상으로 확정한 인스턴스만 처리	IAM이 허용한 종료를 잘못된 대상에 수행한다

마지막 행은 IAM 설정과 별도다. 종료 권한이 있다는 사실은 해당 인스턴스가 유휴 상태이거나 삭제해도 된다는 증거가 아니다. 실제 정리 프로그램은 작업 완료, 보관할 결과물, 제외 대상 같은 판단을 따로 가져야 한다. GPU 사용률 하나만 보고 장시간 대기 중인 학습 작업을 종료해서는 안 되는 이유도 여기에 있다.

가장 먼저 볼 반례: 가입할 때 붙는 기본 역할

현재 IAM 문서는 신원이나 그룹을 워크스페이스에 추가하면 Workspace Member 역할을 기본으로 받는다고 설명한다. 따라서 새 서비스 신원을 sandbox에 넣고 좁은 역할을 추가하는 절차만으로는 최소 권한을 확인할 수 없다. 기본 역할

공식 역할표에서 차이를 보면 이유가 분명해진다.

역할	공식 문서에서 확인한 범위	정리 작업에 대한 판단
Instance Reader	인스턴스 조회	대상 목록을 만드는 단계의 출발점
Instance Terminate	인스턴스 종료	실행 단계에 필요한 권한 후보
Workspace Member	인스턴스 생성·조회·수정·재시작·종료 외 파일시스템·방화벽 등의 작업	조회와 종료만 필요한 작업에는 넓다
Workspace Owner	공간 안의 전체 작업과 구성원 관리	단순 정리 프로그램의 기본 선택으로 삼기 어렵다

예를 들어 서비스 신원에 Instance Reader를 켰는데도 인스턴스를 생성할 수 있다고 하자. 이때 “Reader가 생성까지 허용한다”고 결론 내리기 전에 기본 Workspace Member가 남아 있는지 확인해야 한다. 좁은 역할을 더하는 행위는 이미 받은 넓은 역할을 없애는 행위가 아니다.

이 사례에서는 기본 역할과 불필요한 상속 경로를 확인한 뒤, 대상 공간의 Instance Reader와 Instance Terminate 조합을 검토할 수 있다. 이것은 문서에 근거한 권한 설계안이다. 실제 스크립트가 별도의 지표 조회나 다른 자원 접근을 한다면 추가 권한이 필요할 수 있다. 실패할 때마다 Workspace Owner를 주는 대신 어떤 작업이 부족한지 먼저 분리해야 한다.

직접 권한을 지웠는데도 접근이 남는 경우

또 하나의 가상 상황을 보자. gpu-cleanup에 직접 부여한 Workspace Member를 해제했다. 그러나 이 신원이 research-team 그룹에도 속하고, 그 그룹이 sandbox의 Workspace Member라면 넓은 권한을 물려받는 경로가 남는다. 역할을 하나 지웠다는 이력만으로 작업 범위가 줄었다고 판정할 수 없는 이유다.

Lambda의 effective access는 직접 역할과 그룹 상속을 함께 보여 주는 관점이다. 공식 관리 문서에 따르면 IAM의 Service identities에서 대상 신원을 선택하고 Roles 탭의 View effective access를 통해 워크스페이스별 역할과 계정 역할을 확인한다. API Keys 탭은 키를 관리하는 곳이다. 서비스 신원의 유효 접근 확인

두 정보를 나눠 보는 이유가 있다. 키가 두 개라도 같은 신원에 연결된 키라면, 키 목록만으로 서로 다른 작업 권한을 가졌다고 판단할 수 없다. 키 이름에 read-only라고 적는 것도 역할 배정을 대신하지 않는다. 목록 수집과 종료 실행의 권한을 아예 분리하려면 별도 서비스 신원으로 나누는 설계를 검토할 수 있다. 그 대신 관리할 키·역할·작업 연결이 늘어난다.

콘솔 경로는 공식 문서를 읽어 정리한 것이며 실제 화면·좁은 창 배치·키보드 동작은 확인하지 않았다. 먼저 서비스 신원 생성 절차로 이름 있는 주체를 만들고, 관리 화면에서 접근 범위를 확인하는 흐름으로 사용하면 된다. 단순 메뉴 탐색보다 “어느 경로로 이 권한을 받았는가”를 확인하는 것이 인수의 핵심이다.

GPU 정리 작업을 옮기는 인수표

아래 표는 실제 API 테스트 결과가 아닌 이전 계획의 합격 조건이다. 팀이 소유한 폐기 가능한 자원과 격리된 시험 공간에서 검증하고, 결과 칸을 실제 관측으로 채워야 한다. 종료처럼 자원을 없애는 행동은 운영 자원으로 시험하지 않는다.

확인할 상황	원하는 결과	결과가 다를 때 먼저 확인할 곳
새 키로 sandbox의 인스턴스 조회	대상 공간 목록을 읽을 수 있다	신원 소속, 조회 역할, 키 교체 대상 프로세스
승인된 시험 인스턴스 종료	허용된 대상만 종료한다	종료 역할과 프로그램의 대상 선정 조건
같은 신원으로 새 인스턴스 생성	거절된다	기본 Workspace Member·그룹 상속·넓은 계정 역할
production 자원 접근	허용되지 않는다	직접·그룹의 공간 소속과 역할 범위
옛 키를 폐기한 뒤 그 키로 접근	성공하지 않는다	실제 폐기한 키의 식별 정보와 남은 실행 경로
정리 대상이 없는 날 실행	자원 변경 없이 정상 종료한다	빈 결과를 오류로 오인해 범위를 넓히는 복구 코드

거절을 확인할 때는 응답을 한 가지 상태 코드로 미리 고정하지 않는 편이 낫다. 이 글에서는 Lambda의 실제 오류 코드나 역할 변경 전파 시간을 측정하지 않았다. 요청한 작업, 대상 공간, 키의 식별 정보, 받은 응답을 같이 남기면 인증 문제와 작업 권한 문제를 구분할 근거가 된다. 키 값 자체를 로그에 넣을 필요는 없다.

이 표의 읽기 단계와 종료 단계를 나누면 점진적으로 옮길 수 있다. 먼저 새 신원으로 목록만 비교하고, 기존 작업이 고르던 대상과 차이가 없는지 살핀다. 그다음 승인된 시험 대상에서 종료를 확인한다. 실제 업무 전환 전에는 두 정리기가 동시에 같은 대상에 작동하지 않도록 실행 주체를 하나로 정한다. 이는 공급자가 보증한 이전 기능이 아니라 필자의 운영 제안이다.

키 교체의 끝은 새 키 발급이 아니라 옛 실행 경로의 정리다

공식 발표는 서비스 신원 하나에 키 두 개를 둘 수 있으며, 새 신원으로 옮겨도 기존 개인 키는 직접 삭제하기 전까지 남는다고 설명한다. 따라서 새 키가 한 번 성공했다는 사실과 이전이 완료됐다는 사실을 구분해야 한다. 키 교체와 기존 설정

권한을 확인한 다음에는 아래 순서로 전환 범위를 적어 볼 수 있다.

1. 사용처를 먼저 적는다. 야간 스케줄러, 수동 재실행 경로, 별도 점검 작업 중 어느 것이 옛 키를 쓰는지 정한다. 한 파일만 바꿔도 되는지부터 확인한다.
2. 새 키로 읽기와 제한된 시험을 마친다. 새 신원의 권한이 충분한 동시에 불필요한 작업은 거절되는지 위 표로 확인한다.
3. 실제 실행 주체를 교체한다. 다음 예약 실행과 수동 재실행 경로가 모두 새 신원을 쓰는지 확인한다. 실패하면 먼저 자동 종료를 멈추고 읽기 단계로 좁혀 진단한다.
4. 옛 키를 폐기하고 남은 사용처를 확인한다. 다른 업무가 같은 개인 키를 쓰고 있다면 그 의존성까지 옮길 계획을 정한다. 이전 기간에는 담당자와 종료 시점을 명시한다.

키를 폐기한 뒤 되돌리기를 “그 키를 다시 켜기”로 설계해서는 안 된다. 공식 절차는 키 삭제를 영구 삭제로 설명하며, 새 키의 값도 생성 대화상자를 닫으면 다시 조회할 수 없다. 복구가 필요하면 새 자격 증명을 발급하고 승인된 저장 경로로 배포할 준비가 있어야 한다. 키 생성·삭제 절차

실제 이전 계획에는 키 값을 적는 대신 다음 항목을 남길 수 있다.

작업: gpu-cleanup / 담당 팀:
대상 워크스페이스:
직접 역할 / 기본 역할 처리:
그룹별 상속 역할 / effective access 확인일:
호출하는 작업 목록 / 허용하지 않을 작업:
새 키 식별 정보 / 교체할 실행 경로:
다음 예약 실행 확인 / 옛 키 폐기 예정·완료일:
실패 시 자동 종료 중단 담당자 / 재발급 절차:

어떤 팀이 먼저 바꿀 만한가

사람의 입·퇴사와 무관하게 계속 돌아가야 하는 GPU 자동화, 여러 사람이 공유한 개인 키, 조회만 하면 되는데 관리자 권한을 쓰는 점검 작업이 우선 후보다. 작업 전용 신원은 담당자 교체와 권한 변경을 분리할 근거를 만든다. 실제 운영 비용 절감률이나 사고 감소율은 이번 문헌 분석으로 알 수 없다.

반대로 아직 호출 작업을 파악하지 못한 복잡한 파이프라인이라면 한 번에 모든 키를 폐기하는 전환은 적절하지 않다. 먼저 읽기 전용 작업 하나의 사용처와 권한을 확인하면 이후 이전의 기준을 만들 수 있다. 세밀한 권한을 나누면서 생기는 관리 비용도 팀이 감당해야 한다.

이번 IAM에서 실무적으로 중요한 변화는 자동화를 사람과 분리해 관리할 수 있다는 점이다. 그 이점을 얻으려면 전용 신원, 실제 유효 권한, 옛 키의 폐기를 함께 인수해야 한다. 특히 기본 Workspace Member와 그룹 상속은 새 신원이 예상보다 넓은 일을 할 수 있는지 확인하는 첫 지점이다.

다음에 자신의 작업을 옮길 때 다시 볼 수 있도록 이 글의 저장 기능을 이용해 인수표를 남겨 두면 좋다. 코드 실행과 권한 처리를 분리하는 사례는 GitHub 외부 PR 자동화, 사내 앱을 여러 팀에 열었을 때의 운영 책임은 공유 플랫폼의 배포·인계 분석으로 이어진다. 자원 배정 자체가 고민이라면 GPU 오케스트레이션의 역할을 함께 읽을 수 있다.