B. 즉시 실행

승인 없이 지금 바로 GPU를 쓰는 경로. 과금이 언제 시작되고 언제 끝나는지가 핵심이다.

선행 A. 온보딩 전체. 특히 즉시 등급 노드가 등록되어 있고 팀에 그 유형이 허용되어 있어야 한다.

S-09 인스턴스 시작에서 중지까지

사용자 · 5분 · 선행 S-05, S-06, S-08

가장 기본이 되는 경로다. 여기서 과금 규칙을 확인해 둬야 나머지가 이해된다.

전제 팀 크레딧이 충분하고, 허용된 즉시 유형 노드가 가용 상태다.

절차

인스턴스 화면에서 미기동 노드를 고른다.
시작 을 누른다.
상태가 provisioning → pending → running으로 바뀌는 것을 본다. running이 된 시각을 기록해 둔다. 여기서부터 과금이다.
몇 분 두었다가 중지 를 누른다. 중지 시각을 기록해 둔다.
상태가 stopping을 거쳐 stopped가 되는 것을 본다.

기대

✅ 시작 직후 대시보드의 현재 소진율이 그 유형 단가만큼 올라간다.
✅ 예상 소진 시점이 당겨진다.
✅ 실행 중 인스턴스 상세에 퍼블릭 IP·GPU·VRAM 메트릭이 표시된다.
✅ 중지 후 사용량 리포트 항목별 차감에 그 인스턴스가 나타난다.
✅ 차감액 ≈ running 유지 시간 × 시간당 단가.
✅ 원장에 hold(선점) → capture(확정) → release(잔여 반환)가 남는다.
✅ 감사 로그에 instance.start와 instance.stop이 남는다.

중요 — 과금 구간

시작 클릭      running        중지 클릭      실제 stopped
   │             │              │              │
   ├── 무과금 ───┼─── 과금 ──────┤─── 무과금 ────┤
   │             │              │              │
 hold 선점    과금 시작       과금 종료      선점 반환

양쪽 끝이 모두 무료다.

앞: provisioning·pending 동안은 차감되지 않는다. GPU가 실제로 올라와 running이 되는 순간부터 시작한다. 기동이 느린 것은 사용자 책임이 아니다.
뒤: 중지를 누른 시각까지만 과금된다. 실제 정지 전이가 몇 분 걸려도 청구되지 않는다.

선점(hold)은 시작 클릭 시점에 걸린다. 과금과는 별개다. 선점은 "쓸 수 있는 돈을 잡아두는 것" 이고 과금은 "실제로 빼는 것"이다.

S-10 자동 중지 타이머 조정

사용자 · 2분 · 선행 S-09

켜두고 잊어버리는 것이 크레딧이 새는 가장 흔한 이유다. 그래서 기본으로 타이머가 걸린다.

절차

실행 중인 인스턴스 상세에서 자동 중지까지 남은 시간을 본다.
+30 / +10 / -10 같은 버튼으로 조정한다.
값이 즉시 반영되는지 본다.

기대

✅ 시작 시 기본 4시간이 걸려 있다.
✅ 조정하면 남은 시간이 바로 바뀐다.
✅ 타이머가 0이 되면 자동으로 중지되고, 정산은 수동 중지와 동일하다.
✅ 자동 중지 시 감사 로그에 시스템 행위자로 기록된다.

알아둘 것 예약으로 띄운 인스턴스는 자동 중지 시각이 예약 종료 시각으로 고정된다. 임의로 늘릴 수 없다.

S-11 보안 그룹 규칙 추가·삭제

사용자 · 3분 · 선행 S-09

절차

인스턴스 상세 아래 보안 그룹 카드로 간다.
인바운드 탭에서 규칙 추가 를 누른다.
프로토콜·포트·소스 CIDR·설명을 넣고 추가한다.
목록에 나타나는지 확인한다.
삭제해 본다.

기대

✅ 추가·삭제가 AWS에 즉시 반영된다. Voltra DB에 사본을 두지 않는다.
✅ 카드에 이 노드의 voltra:managed=true 태그 보안 그룹 실제 상태입니다 안내가 보인다.
✅ 인스턴스가 중지 상태여도 규칙을 다룰 수 있다. 보안 그룹은 노드에 상주하는 설정이다.

알아둘 것 voltra:managed=true 태그가 없는 보안 그룹은 Voltra가 건드리지 않는다. 고객이 직접 만든 규칙을 보호하기 위해서다. 0.0.0.0/0을 넣으면 경고가 뜬다. SSH는 본인 IP(/32)만 여는 것을 권한다.

S-12 SSH 키페어로 접속

사용자 · 3분 · 선행 S-09

절차

인스턴스 화면 우측 상단 키페어 다운로드 를 누른다.
.pem 파일을 받는다.
안내대로 권한을 바꾸고 접속한다.

chmod 400 ml-research.pem
ssh -i ml-research.pem ubuntu@<퍼블릭 IP>

기대

✅ 팀 단위 키페어가 내려온다. 여러 번 받아도 같은 키다.
✅ 인스턴스 상세의 SSH 접속 카드에 실제 IP가 채워진 명령이 표시된다.
✅ 공개키를 노드의 ~/.ssh/authorized_keys에 1회 등록하면 접속된다.

알아둘 것 현재는 팀 공용 키다. 노드에 키를 심는 것은 자동화되어 있지 않아 최초 1회는 수동 등록이 필요하다.

S-13 허용되지 않은 유형 시작 시도

사용자 · 1분 · 선행 S-06

절차 Org Admin이 팀에 허용하지 않은 유형의 인스턴스를 시작해 본다.

기대

✅ type_not_allowed로 거부된다.
✅ 애초에 목록에 안 보이거나 시작 버튼이 막혀 있다.
✅ Org Admin이 팀 관리에서 그 유형을 허용하면 즉시 쓸 수 있게 된다.

S-14 가용 노드 없이 시작 시도

사용자 · 1분 · 선행 S-05

절차 조직 풀의 해당 유형 노드가 전부 사용 중이거나 비활성일 때 시작해 본다.

기대

✅ no_capacity로 거부된다.
✅ 크레딧이 차감되지 않는다. 선점했더라도 되돌아온다.
✅ 노드가 점유되지 않는다.
✅ 팀에 가용 노드가 없어 시작하지 못했습니다 알림이 간다.
✅ GPU 예약 화면의 조직 노드 풀에서 전부 사용 중인 것을 눈으로 확인할 수 있다.

해결 + 노드 추가 요청으로 증설을 요청한다(S-23).

즉시 실행의 no_capacity는 정당한 차단이다. 그 노드가 물리적으로 존재하지 않으면 시작할 수 없다. 반면 서버급 예약은 가용과 무관하게 신청된다. 예약 자체가 증설 요청이기 때문이다.

이 묶음이 끝나면

즉시 실행의 전 구간(시작·과금·중지·정산·부가 기능)을 확인한 것이다.

다음: C. 서버급 예약 — 승인이 필요한 자원은 규칙이 다르다.

S-09 인스턴스 시작에서 중지까지​

S-10 자동 중지 타이머 조정​

S-11 보안 그룹 규칙 추가·삭제​

S-12 SSH 키페어로 접속​

S-13 허용되지 않은 유형 시작 시도​

S-14 가용 노드 없이 시작 시도​

이 묶음이 끝나면​