C. 서버급 예약

H100 같은 서버급 자원은 승인을 거친다. 승인 순간 선불 확정 차감이고 취소가 없다. 그래서 규칙이 즉시 실행과 완전히 다르다.

선행 A. 온보딩. 서버급(reserved) 등급 유형이 등록되어 있고 팀에 허용되어 있어야 한다.

핵심 전제 — 신청은 가용과 무관하다

서버급 예약은 풀에 노드가 없어도 신청된다. 예약 자체가 증설 요청이기 때문이다. Super Admin이 승인 과정에서 Capacity Block을 확보해 배정한다. 화면에 보이는 가용 노드는 참고 정보이지 승인 조건이 아니다.

S-15 예약 신청에서 승인까지

사용자 → Super Admin · 5분 · 선행 S-04, S-06, S-08

절차 — 사용자

GPU 예약에서 서버급 유형을 고른다.
대수(1~16), 시작·종료 일시를 넣는다.
예상 비용이 실시간으로 계산되는 것을 본다.
선불 결제·취소·환불 불가에 동의합니다 를 체크한다.
예약 신청을 누른다.

절차 — Super Admin 6. 예약 승인 큐에 새 건이 뜬다. 7. 신청 팀의 크레딧, 요청 대수, 기간, 현재 가용을 확인한다. 8. 승인 을 누른다.

기대

✅ 신청 직후 상태가 submitted. 예약 코드 RSV-xxxx가 부여된다.
✅ 이 시점에는 아직 차감되지 않는다.
✅ 승인 큐에 나타난다. 팀 잔여와 예상액이 나란히 보인다.
✅ 승인 순간 상태가 approved로 바뀌고 예상액이 통째로 확정 차감된다.
✅ 팀에 예약이 승인·확정되었습니다 / 예상액 n C가 확정 차감(선불)되었습니다 알림이 간다.
✅ 사용량 리포트 항목별 차감에 usage_reservation으로 나타난다.
✅ 감사 로그에 reservation.submit과 reservation.approve가 남는다.

과금이 다른 이유

즉시 실행   시작 ──── 실제 사용 시간만큼 ──── 중지 시 정산
서버급 예약  승인 ──── 전액 선불 확정 ──── 안 써도 환불 없음

Capacity Block은 플랫폼이 AWS에 미리 값을 치르고 확보하는 자원이다. 팀이 안 써도 비용은 이미 나갔다. 그래서 선불이고 환불이 없다.

관련 GPU 예약 신청 · 예약 승인·조정·반려

S-16 동의 없이 신청 시도

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

동의는 프론트 체크박스만이 아니라 서버가 강제한다. API를 직접 호출해도 막힌다.

절차 동의 체크박스를 비운 채 신청한다.

기대

✅ ack_required로 거부된다: 선불 결제·취소·환불 불가 동의가 필요합니다.
✅ 예약이 만들어지지 않는다.
✅ 화면에서는 애초에 신청 버튼이 비활성이다.

S-17 잘못된 기간으로 신청 시도

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

기간은 임의로 정할 수 없다. 1일 단위로 최대 14일, 그 이상은 7일 배수로 최대 182일이다.

절차 아래를 각각 시도한다.

입력	결과
20일	`invalid_duration`. 14일 초과는 7일 배수만 된다
21일	✅ 통과 (7의 배수)
200일	`invalid_duration`. 182일이 상한이다
종료 ≤ 시작	`종료가 시작보다 빠릅니다`
과거 시작 시각	`과거 시점은 예약할 수 없습니다`
즉시 등급 유형	`instant_type`. 예약 없이 바로 실행하면 된다
팀 미허용 유형	`type_not_allowed`

기대

✅ 각 경우가 위 표대로 거부된다.
✅ 슬롯 경계 때문에 N일에서 1시간쯤 모자라도 통과한다. ±2시간 오차를 허용해 일수로 반올림 판정한다.

이 규칙은 AWS Capacity Block의 제약이다. 화면에는 규칙만 안내하고 내부 용어는 노출하지 않는다.

S-18 조건 조정 후 수락

Super Admin → 사용자 · 5분 · 선행 S-15

요청 그대로 줄 수 없을 때 쓴다. 4대를 2대로, 다음 주를 다다음 주로 바꿔 회신하는 식이다.

절차 — Super Admin

승인 큐에서 조건 조정 을 누른다.
대수·시작·종료 중 바꿀 것을 넣는다. 안 넣은 항목은 원안을 유지한다.
조정 사유를 반드시 적는다. 빈 값이면 거부된다.
회신한다.

절차 — 사용자 5. 알림을 받고 예약 상세로 간다. 6. 조정된 조건과 사유를 확인한다. 7. 조정안 수락 을 누른다.

기대

✅ 회신 후 상태가 adjusted. 팀에 운영팀이 예약 조건을 조정해 회신했습니다 알림이 간다.
✅ 승인 큐에서는 사라진다. 이제 공은 사용자에게 있다.
✅ 수락 순간 approved가 되고 재승인 없이 확정 차감된다.
✅ 차감액은 조정된 조건 기준이다. 원안 금액이 아니다.
✅ 운영에 조정안이 수락되어 예약이 확정되었습니다 알림이 간다. 시작일 전에 노드를 확보하라는 안내가 함께 온다.
✅ 감사 로그에 reservation.adjust와 reservation.accept_adjustment가 남는다.

조정 기간도 같은 규칙을 받는다 Super Admin이 조정한 기간이 1~14일 / 7일 배수 규칙을 벗어나면 invalid_duration으로 거부된다. 사용자와 같은 제약이다.

무응답은 자동 반려된다 응답 기한은 조정된 시작일이다. 그때까지 수락도 거절도 없으면 자동 반려되고 양쪽에 알림이 간다. 무기한 교착을 막는 장치다.

S-19 조건 조정 후 거절

Super Admin → 사용자 · 3분 · 선행 S-18

절차 S-18의 1~6까지 같고, 마지막에 조정안 거절 을 누른다.

기대

✅ 상태가 cancelled가 된다.
✅ 차감이 없다. 승인 전이라 아무 크레딧도 나가지 않았다.
✅ 팀에 조정안을 거절해 예약이 취소되었습니다 확인 알림이 간다.
✅ 운영에도 알림이 간다: 조정안이 거절되었습니다 / 확보 예정 물량에서 빠집니다.

거절은 사용자 행동이지만 운영에도 알린다. 조정안을 만들 때 이미 물량 확보 계획에 넣었기 때문에, 결말을 모르면 안 쓸 자원을 잡아둔다.

취소와 거절은 다르다

	시점	차감	가능 여부
조정안 거절	승인·차감 전	없음	✅ 가능
예약 취소	승인·차감 후	이미 나감	❌ 불가

S-20 예약 반려

Super Admin · 2분 · 선행 S-15

절차

승인 큐에서 반려 를 누른다.
사유를 적는다. 필수다.
반려한다.

기대

✅ 상태가 rejected가 된다.
✅ 차감이 없다.
✅ 팀에 예약 신청이 반려되었습니다 알림이 사유와 함께 간다.
✅ 감사 로그에 reservation.reject가 사유와 함께 남는다.

이미 처리한 건을 다시 처리하려 하면 not_pending으로 거부된다. 승인·반려·조정은 submitted 상태에서만 된다.

S-21 승인된 예약 취소 시도

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

절차 승인된 예약에서 취소를 시도한다.

기대

✅ cancellation_not_allowed로 거부된다: 서버급 예약은 선불 확정 자원으로 취소할 수 없습니다. 조건 변경이 필요하면 플랫폼 운영에 문의하세요.
✅ 화면에 취소 버튼 자체가 없다.
✅ 크레딧은 그대로 나간 상태다.

그래서 신청 전에 확인할 것

기간이 정말 필요한 만큼인가. 짧게 잡고 늘리는 것은 안 된다.
대수가 맞는가.
팀 크레딧이 충분한가.
팀원이 그 기간에 실제로 쓸 수 있는가.

S-22 크레딧 부족 상태로 승인 시도

Super Admin · 3분 · 선행 S-15

신청은 됐지만 승인 시점에 팀 잔여가 예상액보다 적은 경우다.

전제 예약 신청 후 그 팀이 다른 데 크레딧을 써서 잔여가 예상액 아래로 떨어졌다.

절차

승인 큐에서 팀 잔여와 예상액을 비교한다. 부족이 표시된다.
그대로 승인을 눌러 본다.

기대

✅ 승인 신호는 들어가지만 확정 차감에서 실패한다.
✅ 최종 상태가 rejected가 된다. approved로 남지 않는다.
✅ 팀에 예약이 자동 반려되었습니다 알림이 사유와 함께 간다.
✅ 운영에도 reservation_auto_rejected 알림이 간다.
✅ 차감이 없다. 잔액이 음수가 되지 않는다.

여기서 "자동 반려"는 크레딧 부족을 뜻한다. 가용 노드 부족이 아니다. 가용은 애초에 승인 조건이 아니다.

해결 Org Admin이 팀 예산을 늘리거나(미할당 풀에서), Super Admin이 조직에 크레딧을 더 판매한 뒤 다시 승인한다.

관련 예약 승인·조정·반려 · 크레딧 판매

S-23 노드 추가 요청과 처리

사용자 → Super Admin · 5분 · 선행 S-06

풀에 노드가 모자랄 때 증설을 요청하는 경로다. 예약과 별개의 트랙이다.

절차 — 사용자

GPU 예약 화면의 + 노드 추가 요청 을 누른다.
노드 타입, 필요 대수, 사유를 적는다.
요청한다.

절차 — Super Admin 4. 노드 요청 큐에서 요청을 본다. 5. 실제로 노드를 확보해 노드 풀 관리에서 등록한다. 등록 시 이 요청을 지정한다. 6. 요청 대수만큼 등록되면 자동으로 완료 처리된다.

기대

✅ 요청 코드가 부여되고 상태가 pending이다.
✅ 요청 1건에 노드를 등록할 때마다 등록 n / 요청 m으로 진행이 쌓인다.
✅ 요청 대수를 채우는 순간 자동으로 approved 가 되고 팀에 알림이 간다: 요청하신 노드 n대가 풀에 등록되었습니다.
✅ 감사 로그에 request.node_add와 node_request.done이 남는다.

직접 처리도 된다 노드 등록 없이 요청 큐에서 바로 완료나 반려를 누를 수도 있다. 반려는 사유가 함께 저장되고 팀에 전달된다.

실패 경로

상황	결과
다른 조직 노드로 요청을 채우려 함	`org_mismatch`
이미 완료·반려된 요청	`already_decided`

관련 노드 추가 요청 처리 · 노드 풀 관리 · GPU 예약 신청

예약 상태 한눈에

                  ┌── 반려 ──────────────▶ rejected
                  │
submitted ────────┼── 승인 ─┬─ 잔여 충분 ─▶ approved ─▶ active ─▶ completed
   │              │         └─ 잔여 부족 ─▶ rejected (자동 반려)
   │              │
   │              └── 조정 ──▶ adjusted ─┬─ 수락 ─▶ approved
   │                                     ├─ 거절 ─▶ cancelled
   │                                     └─ 무응답 ─▶ rejected
   └── 취소 (approved 이후로는 불가)

approved 이후 시작 시각이 되면 노드가 배정되고 active가 된다. 종료 시각에 자동으로 정리되어 completed가 된다.

이 묶음이 끝나면

승인·조정·반려·자동 반려·증설 요청까지 예약의 모든 갈래를 본 것이다.

다음: D. 서버리스 — GPU를 띄우지 않고 LLM만 쓰는 경로.

S-15 예약 신청에서 승인까지​

S-16 동의 없이 신청 시도​

S-17 잘못된 기간으로 신청 시도​

S-18 조건 조정 후 수락​

S-19 조건 조정 후 거절​

S-20 예약 반려​

S-21 승인된 예약 취소 시도​

S-22 크레딧 부족 상태로 승인 시도​

S-23 노드 추가 요청과 처리​

예약 상태 한눈에​

이 묶음이 끝나면​