승인자 가이드

Alpacon 문서 대부분은 접근을 요청하는 사람을 대상으로 합니다. 이 가이드는 요청을 검토하는 사람, 즉 여러분을 위한 것입니다. Superuser 역할을 가지고 있다면 워크스페이스 곳곳의 민감한 요청이 여러분의 큐로 들어오고, 그 요청을 진행할지는 여러분이 결정합니다. 요청이 하루 동안 어떻게 흘러가는지, 무엇이 도착하고 어떻게 읽으며 어떻게 판단하고 그 뒤 어디를 확인하는지 살펴봅니다.

여러분의 역할

워크스페이스 멤버가 민감한 작업을 하려면 그 요청은 사람이 결정하도록 **요청 관리(Approvals)**로 들어옵니다. 여러분에게 도착하는 요청은 다음과 같습니다.

작업 세션, 작업 세션 수정: 특정 서버에 대한 범위가 정해진 한정 시간 접근입니다.
서비스 토큰, 토큰 수정: Application에 새 자격 증명을 발급하거나, 기존 토큰의 범위·상태를 변경하는 요청입니다.
사용자명, 그룹명 변경: 승인이 필요한 ID 변경입니다.

유형별로 무엇을 보고 무엇을 바꿀 수 있는지는 요청 유형을 참고하세요.

큐를 검토하려면 Superuser 역할이 필요하고, 여기서 몇 가지가 따라옵니다.

여러 사람이 이 역할을 가질 수 있습니다. 어느 Superuser든 대기 중인 요청을 검토할 수 있어, 승인이 한 사람에게 묶이지 않습니다.
Admin은 승인할 수 없습니다. Admin 역할로는 승인 권한이 없고, Superuser 역할이 없는 멤버는 큐 자체를 열 수 없습니다.
Manager는 알림만 받고 결정하지 않습니다. 요청 대상 서버가 속한 그룹의 관리자(Manager)는 대기 중인 작업 세션을 알림으로 받지만 직접 승인할 수는 없습니다.
요청을 만든 채널로는 승인할 수 없습니다. CLI에서 제출한 요청은 CLI가 아니라 웹 콘솔의 요청 관리(Approvals) 큐(또는 Slack)에서 결정됩니다. 요청하는 사람과 결정하는 사람을 분리하기 위해서입니다.
본인 세션은 예외입니다. 본인을 위해 세션을 요청하면 요청 즉시 승인됩니다. 단, 요청 주체가 AI 에이전트인 경우는 예외입니다(아래 참고).

요청 읽기

큐에서 요청을 열면 세부 정보를 볼 수 있습니다. 요청자의 사유, 요청된 리소스(수정 요청이라면 변경 전/후), 위험도, 그리고 작업 세션이라면 AI 사전 검토입니다. 작업 세션이라면 요청된 사용 시간, 기능, 대상 서버, 그리고 요청 이유를 봅니다.

AI 사전 검토

모든 작업 세션 요청에는 AI 사전 검토 카드가 함께 옵니다. 추천 위험도(낮은 위험, 보통 위험, 높은 위험, 심각한 위험), 그 근거, 세션에 대한 추천 기능을 보여줍니다. 추천 기능은 기능 편집기에서 강조 표시되지만 자동으로 적용되지는 않습니다. 사전 검토를 참고 의견으로 삼은 뒤 판단하세요. 요청 검토를 참고하세요.

위험도

각 요청에는 민감도를 한눈에 파악할 수 있도록 위험도가 표시됩니다.

서비스 토큰: 요청된 접근 범위로부터 위험도가 계산되며, 범위별 내역과 사유가 함께 제공됩니다.
작업 세션: 위험도는 AI 사전 검토에서 옵니다.

위험도는 색상으로 구분되므로 높은 위험이나 심각한 위험 요청이 눈에 띕니다.

조정할 수 있는 것

작업 세션이라면 예 또는 아니오에만 머물지 않습니다. 관리자 조정 영역에서 다음을 할 수 있습니다.

기능 변경: 부여하기 전에 scope를 추가하거나 제거합니다.
대상 서버 변경: 서버를 추가하거나 제거합니다.
권고사항 추가: 담당자가 시작 전에 보는 메모입니다.

승인하면 조정한 내용이 결정과 함께 전달됩니다. 다른 요청 유형은 검토 전용이라 있는 그대로 승인하거나 반려합니다. 요청 유형을 참고하세요.

시간 확인하기

시간에 민감한 세션은 사용 시간이 거의 끝나갈 때 경고가 표시됩니다.

곧 만료: 빨리 승인하지 않으면 요청자가 사용할 시간이 없습니다.
이미 지남: 사용 시간이 이미 지나, 지금 승인해도 쓸 수 있는 시간이 없습니다. 재요청을 안내하는 편이 좋습니다.

긴급 경고를 참고하세요.

잘 판단하기

대기 중인 요청에는 승인과 반려가 표시됩니다. 어느 쪽이든 요청자에게 알림이 전송됩니다.

반려하기 전에 먼저 줄이세요. 작업 세션은 부여하기 전에 기능과 서버를 추가하거나 제거할 수 있으므로, 범위가 넓은 요청이라도 돌려보낼 필요가 없는 경우가 많습니다. 실제 작업에 필요한 만큼으로 좁혀 더 작은 범위로 승인하세요. 반려는 아예 진행되어서는 안 되는 요청이나 사용 시간이 이미 지난 요청에 남겨 두세요.

sudo는 가장 신중하게 보세요. 권한 상승(sudo)은 가장 무거운 scope입니다. 세션 사용 시간 동안 세션의 다른 기능 전반에 상승된 sudo 수준 권한을 부여합니다. 세션에 포함하는 것은 첫 관문일 뿐이며, 담당자가 실제로 sudo를 사용할 때마다 그 시점에 다시 확인이 이뤄지고, 사람의 승인을 기다릴 수 있으며, MFA를 요구할 수도 있고, 모든 sudo 작업은 기록에 남습니다. sudo를 부여하기 전에 사유가 정말 sudo를 필요로 하는지 확인하세요. 권한 상승 (Sudo)를 참고하세요.

일괄 처리. 여러 대기 요청을 선택해 모두 승인하거나 모두 반려할 수 있습니다. 다만 일괄 처리는 개별 검토를 건너뛰고 되돌릴 수 없으니 선택 항목을 먼저 확인하세요.

반복 작업 줄이기: 승인 정책

요청을 하나하나 손으로 검토하는 방식은 확장되지 않습니다. 일부 요청은 여러분을 기다리지 않고 처리되도록 설계돼 있습니다.

Superuser가 본인을 위해 요청한 세션은 요청 즉시 승인됩니다.
워크스페이스는 요청의 위험도와 요청 주체에 따라 어떤 작업을 자동으로 통과시키고 어떤 작업을 사람이 검토할지 결정하는 승인 정책을 구성할 수 있습니다. 예를 들어 위험이 낮은 sudo 작업은 자동으로 통과시키고 위험이 큰 작업은 사람의 승인을 기다리게 할 수 있습니다.

요점은 정책으로 다스리고 예외를 검토하는 것입니다. 일상적이고 위험이 낮은 요청은 정해진 경로로 흐르게 두고, 정책이 붙잡아 둔 요청에 주의를 집중하세요. 한 가지 원칙만은 예외가 없습니다. AI 에이전트가 요청한 세션은 어떤 정책과 무관하게 항상 사람의 승인이 필요합니다(아래 참고).

자동 승인을 참고하세요.

세션이 진행되는 동안

승인했다고 해서 시야가 끝나는 것은 아닙니다. Live activity(Execution 하위)는 지금 진행 중인 세션을 보여주어 지켜보고 개입할 수 있게 합니다.

활성 세션은 각각 제목, 남은 시간, 요청된 기능, 대상 서버가 담긴 카드로 표시됩니다. 카드를 열면 실시간 상세 보기로 이동하며, 다음이 스트리밍됩니다.

연결 상태: 실시간, 재연결 중, 연결 종료, 연결 오류 그리고 최신 스냅샷 시각.
상태 이력: 요청에서 승인과 활성을 거쳐 완료·만료·철회에 이르는 수명 주기.
활동 타임라인: 명령, 터미널 열림과 닫힘, sudo 요청과 부여, 파일 전송을 카테고리로 필터링할 수 있는 실시간 피드.

개입이 필요할 때 두 가지 동작이 비상 정지 장치가 됩니다.

세션 완료: 진행 중인 세션을 즉시 종료합니다.
세션 철회: 승인된 세션을 활성화되기 전에 종료합니다.

Live activity를 참고하세요.

세션이 끝난 뒤

세션이 끝나면 그 기록이 책임 추적의 근거가 됩니다.

세션 기록. Audit → Session history는 모든 세션을 누가 요청했는지, 누가 승인했는지, 어떤 권한 범위와 서버가 쓰였는지, 어떻게 끝났는지, 소요 시간, 그리고 AI 분석이 산출한 위험도와 함께 나열합니다. 행을 열면 전체 타임라인, 승인 기록, 분석을 볼 수 있습니다. Sessions를 참고하세요.

녹화와 AI 위험 분석. 종료된 세션의 상세 페이지는 기록 탭에서 활동을 재생하고(Websh 터미널 녹화는 마스킹되며 재생할 수 있습니다), 분석 탭은 세션이 끝난 뒤 AI 검토를 더합니다. 위험도, 평이한 요약, 핵심 지표, 위협 분석(발견된 것이 있으면 MITRE ATT&CK 기법 목록 포함), 대응 가이드를 보여줍니다. 세션 종료 후를 참고하세요.

승인 이력. 여러분의 결정도 기록됩니다. Audit → Governance → Approval history는 과거 요청을 검토자, 결과, 남겨진 사유와 함께 보여주어 “이건 왜 승인됐나”, “sudo의 승인 대 반려 비율은 얼마인가” 같은 질문에 답할 수 있습니다. 승인 이력을 참고하세요.

AI 에이전트가 요청할 때

Alpacon에서는 AI 에이전트도 CLI에서 세션을 요청할 수 있지만, 에이전트의 요청은 항상 사람, 즉 여러분에게 도착합니다. AI 에이전트가 요청한 세션은 Superuser가 요청하더라도 사람의 승인이 필요하며, 어떤 승인 정책이나 본인 자동 승인도 이를 바꾸지 못합니다.

따라서 에이전트 요청도 다른 요청과 똑같이 다루되, 몇 가지는 특히 주의해서 봅니다.

자동 경로가 적용되지 않습니다. 정책이 걸러 줬다고 가정하지 말고 사유와 요청된 scope를 직접 읽으세요.
AI 사전 검토의 위험도와 근거를 활용해 명시된 작업에 필요한 것보다 많은 것을 요구하는 요청을 가려내세요.
부여하기 전에 범위를 줄이세요. 특히 sudo가 그렇습니다. 에이전트가 작업에 필요한 기능과 서버만 정확히 받고 그 이상은 받지 않도록 하세요.

에이전트 요청이 어떻게 만들어지는지는 세션 요청하기를 참고하세요.