미니 데이터센터 운영 — 사건이 일어나는 곳

구축과 운영은 다른 일이다

18장의 검수 체크리스트를 통과한 순간, 이 랙의 성질이 바뀐다. 「만드는 물건」에서 「지키는 물건」이 된다. 그러면 잘하는 기준도 바뀐다.

누가 운영하는가 — 아홉 개의 자리

혼자 다 하면 아무것도 못 배운다. 역할을 나누면 「내가 못 보는 것」이 생기고, 그 순간부터 인계와 에스컬레이션이 필요해진다. 그것이 운영의 본체다.

층과 존은 직교한다. 층(floor)은 물리 배치이고 존(zone)은 보안등급이다. 같은 층 랙에 다른 존이 섞일 수 있고, 같은 존이 여러 층에 걸칠 수 있다. 이 어긋남 자체가 교보재다 — 물리적으로 옆자리인데 논리적으로 다른 망이라는 것을 관제 화면에서 두 뷰를 겹쳐 보며 체감한다.

4F  운영 (NOC/SOC)          ← 위층 장애는 국소적이다
       ▲
      2F/3F  전산실 · AI 전산실
       ▲
      1F  시설 (전력·냉방·소방)     ← 아래층 장애는 위로 번진다

의존 방향:  1F ──▶ 2F/3F ──▶ 4F   (단방향)

무엇을 보는가 — 기준선과 네 개의 화면

18장 실습에서 만든 기준선 표가 이 장의 입력이다. 이상은 절대값이 아니라 기준선과의 차이로 정의한다. 「랙 온도 31 C」는 그 자체로 아무 뜻이 없고, 「평시 26 C 였는데 31 C」가 되어야 사건이 된다.

사고 카탈로그 — 서른네 가지

훈련은 미리 적어 둔 목록에서 나온다. 즉흥적으로 고장을 내면 학생마다 다른 것을 배우고, 채점 기준이 강사의 기분이 된다.

고장을 어떻게 넣는가 — 48종과 안전장치

사고는 기다리는 것이 아니라 넣는 것이다. 강사 패널에서 클릭 한 번으로 들어가고, 두 서비스가 나눠 갖는다.

안전장치 — 주입보다 원복이 중요하다

주입과 해제도 로그로 남긴다. 강사의 조작 역시 사건이고, 학생이 보는 타임라인에 같이 남아야 상관분석이 성립한다. 「11시 03분에 무언가 일어났다」와 「11시 03분에 강사가 net_delay 를 주입했다」는 사후 검토에서 완전히 다른 자료다.

런북 — 세 개를 끝까지 써 본다

런북은 판단이 필요한 지점을 미리 표시해 둔 절차서다. 전부 기계적으로 쓸 수 있으면 그건 런북이 아니라 스크립트이고, 자동화하면 된다. 런북이 필요한 이유는 판단이 남기 때문이다.

런북 1 — ENV-03 UPS 절체

[상황]  상용 전원 상실. UPS 배터리로 전환됨.
        18장 계산에 따르면 보호 부하 196 W 에서 잔여 약 11분.

[0-1분]  확인
    1. 관제 화면 상단 HUD 에서 UPS 잔여 시간을 읽는다.  ← 추정하지 말고 읽는다
    2. envsim /shed 를 호출해 부하 그룹별 소비와 차단 시 영향을 받는다.
    3. 정전 범위를 확인한다 (이 랙만인가, 강의실 전체인가, 건물인가).
       → 두꺼비집 확인. 우리 회로만 내려갔다면 복전 가능성이 높다.

[1-3분]  통보
    4. 운영 리드에게 보고. 서비스 데스크에 "계획되지 않은 중단" 공지 준비.
    5. 진행 중인 작업 확인: 파인튜닝 잡, 체크포인트 쓰기, 백업.

[3-6분]  판단  ★여기가 런북이 대신할 수 없는 지점★
    6. 무엇을 먼저 끄는가. 원칙은 두 가지다.
         (a) 상태가 없는 것부터        → 추론 서빙은 껐다 켜도 잃는 것이 없다
         (b) 소비가 큰 것부터          → 잔여 시간을 가장 많이 벌어 준다
       그런데 이 둘이 충돌할 때가 있다:
         - DGX Spark 는 소비가 크지만(480 W) 애초에 UPS 에 안 물려 있다
         - 미니 PC 2번(관제)은 소비가 작지만 끄면 상황을 볼 수 없게 된다
       → 관제와 방화벽은 마지막까지 남긴다. 「보는 눈」과 「말할 입」이다.

[6-10분] 정상 종료
    7. 순서:  추론 서빙 → k3s 워커 → k3s 컨트롤 → 스토리지 → 미니PC 1,3,4
    8. 각 단계마다 완료를 확인하고 다음으로 간다. 동시에 내리지 않는다.
       (동시에 내리면 스토리지가 쓰기 도중에 끊길 수 있다)
    9. 마지막까지 남기는 것: 미니PC 2(관제) · 방화벽 · 스위치 B

[복전 후]  기동
   10. 역순으로 올린다.  전력 → 망 → 스토리지 → 컨트롤 → 워커 → 서빙
   11. 18장 기준선과 대조한다. 다른 값이 있으면 그것이 다음 사건이다.

[사후 24시간 내]
   12. 타임라인 작성: 몇 분에 무엇을 봤고 무엇을 결정했는가.
   13. 이번에 판단이 늦어진 지점을 찾아 런북에 반영한다.

런북 2 — GPU-03 열 스로틀로 처리량 저하

[증상]  추론 tok/s 가 기준선의 60% 로 떨어졌다. 오류는 없다.

[가장 흔한 오진]
    "모델이 바뀌었나" → 바뀌지 않았다
    "요청이 늘었나"   → 큐 길이는 정상
    ※ 오류가 없는 성능 저하는 대개 물리 계층이다. 위를 먼저 보면 시간을 버린다.

[1] 온도를 본다 (층을 건너간다)
    - 랙 A 상단 흡기 온도를 기준선과 비교
    - DGX Spark 의 클럭이 내려가 있는가
    - 18장 냉각 계산: 0.81 kW 는 방이 흡수한다 —
      그런데 방이 못 흡수하는 상황이 생겼는가?
        · 문이 닫혔나  · 에어컨이 꺼졌나  · 랙 뒤에 물건이 쌓였나
        · 팬에 먼지가 끼었나

[2] 원인이 시설이면 시설 담당에게 넘긴다
    ★ 이 시나리오의 핵심은 「내 계통이 아니다」를 빨리 판정하는 것이다.
      GPU 플랫폼 담당이 GPU 안에서 원인을 계속 찾으면 영원히 못 찾는다.

[3] 임시 조치 (근본 해결 전까지 서비스를 유지한다)
    - 배치 크기를 줄여 발열을 낮춘다 → 처리량은 더 떨어지지만 안정된다
    - 또는 한 대만 돌리고 한 대를 쉬게 한다
    ※ 어느 쪽이든 SLO 를 못 지킨다. 그 사실을 먼저 알린다.

[4] 사후
    - 온도-처리량 곡선을 기록한다. 몇 도에서 스로틀이 시작되는가.
    - 그 값이 이 랙의 새로운 운영 한계다. 기준선 표에 추가한다.

런북 3 — FLT-03 네트워크 링크 플랩

[증상]  간헐적으로 연결이 끊겼다 붙는다. 재현되지 않는다.

[왜 어려운가]
    증거가 사라지는 유형이다. 확인하러 가면 이미 정상이다.
    → 그래서 절차의 첫 단계가 "고치기"가 아니라 "잡아두기"다.

[1] 먼저 증거를 남긴다   ★순서가 반대면 실패한다★
    - 스위치 포트의 링크 up/down 카운터를 기록  (누적값이라 사라지지 않는다)
    - ping 을 -i 0.2 로 걸어 두고 로그로 남긴다
    - SIEM 에서 해당 시간대 syslog 를 건져 둔다

[2] 범위를 좁힌다
    - 어느 포트인가 → 카운터가 오르는 포트를 찾는다
    - 한쪽만인가 양쪽인가 → 케이블·SFP·포트 중 무엇인지 갈린다
    - 18장에서 트렁크를 2가닥으로 했으므로,
      한 가닥이 플랩해도 서비스는 살아 있다. 그래서 "천천히" 볼 수 있다.
      ★ 이중화의 진짜 값어치는 가용성이 아니라 「조사할 시간」이다 ★

[3] 교체는 하나씩
    - 케이블 교체 → 관찰 → 재발하면 다음
    - 두 개를 동시에 바꾸면 무엇이 원인이었는지 영영 모른다

[4] 사후
    - 원인 부품을 폐기하고 자산 대장에서 내린다
    - 같은 로트의 다른 케이블이 있는지 확인한다  ← 대개 여기서 두 번째가 나온다

연쇄 — 아래층이 위층을 죽인다

단일 장애만 훈련하면 실제 중대 사고에 대비하지 못한다. 실제 사고는 거의 언제나 연쇄이고, 연쇄는 의존 방향을 따라 흐른다.

ENV-01  냉동기 정지
   │
   │  (유휴 상태에서는 분당 0.2 C — 배속 x10 이 필요하다)
   ▼
   랙 흡기 온도 상승
   │
   ▼
GPU-03  DGX Spark 열 스로틀           ← 3F
   │
   ▼
INC-04  추론 지연 SLA 위반            ← 3F
   │
   ▼
INC-03  경보 폭주                     ← 4F. SLA 위반 알림이 초 단위로 쌓인다
   │
   ▼
   운영 리드가 진짜 원인(1F)을 못 본다  ← 이것이 이 연쇄의 진짜 피해다

차단 지점은 여러 곳이지만, 각각 대가가 다르다:
    1F 에서: 예비 냉방 가동          → 가장 좋다. 그런데 예비가 있는가?
    3F 에서: 배치 축소로 발열 감소   → 서비스는 살지만 SLO 는 깨진다
    4F 에서: 경보 억제(suppress)     → 시야는 확보되지만 다른 것을 놓칠 위험

이 한계 자체가 교보재다. 시뮬레이터가 어디까지 진짜인지 학생이 아는 것과 모르는 것은 다르다. 실제 운영에서도 「이 대시보드의 이 값은 추정치다」를 아는 사람과 모르는 사람의 판단이 갈린다.

에이전트에게 운영을 맡기면

근무자 아홉 자리를 사람이 다 채울 수 없다. 그래서 에이전트가 앉는다. 그러면 새로운 문제가 생긴다 — 틀렸을 때 어떻게 막을 것인가.

통제는 프롬프트가 아니라 문서로 한다

사후 감시 — AOC 다섯 단계

수집(collection) → 탐지(detection) → 선별(triage) → 대응(response) → 킬 스위치

    수집   에이전트의 도구 호출·게이트 판정·실행 흔적을 전부 남긴다
    탐지   비정상 패턴을 찾는다 (반복 실패, 권한 경계 접근, 예산 초과)
    선별   사람이 봐야 할 것만 큐에 올린다  ← 여기가 없으면 INC-03(경보 폭주)이 된다
    대응   플레이북 실행. 되돌릴 수 없는 조치는 HITL 승인 큐로
    킬     그래도 안 되면 멈춘다

사람의 자리는 「대응」 단계의 승인 큐다.
모든 것을 승인하면 자동화의 뜻이 없고,
아무것도 승인하지 않으면 통제의 뜻이 없다.
→ 무엇을 승인 대상으로 둘 것인가가 설계다.

AGT-01 — 에이전트가 틀렸을 때

[상황]  에이전트가 장애 대응 중 잘못된 조치를 했다.
        예: 디스크 고갈 경보에 대응해 로그를 지웠는데,
            그것이 진행 중인 보안 조사의 증적이었다.

[이 시나리오가 묻는 것]
    1. 그 조치가 게이트를 통과한 이유는 무엇인가?
       → "로그 삭제"가 허용 도구 목록에 있었다. L1 에 금지가 없었다.
    2. 누가 책임지는가?
       → 에이전트가 아니라 게이트를 그렇게 설정한 사람이다.
    3. 어떻게 막는가?
       → L1 에 "증적 디렉터리 삭제 금지"를 추가하고 컴파일한다.
         코드는 건드리지 않는다.
    4. 이미 지워진 것은?
       → 18장의 3-2-1. 콜드 스토리지에 있다. 없으면 이 시나리오는 재해가 된다.

[핵심]
    자동화의 사고는 「AI 가 이상하다」가 아니라
    「권한 설계가 이상하다」로 읽어야 고칠 수 있다.

훈련을 설계한다

훈련은 난이도 순이 아니라 성격 순으로 배치한다. 쉬운 것부터 어려운 것으로 가면 학생이 「기술이 늘면 다 된다」고 배우는데, 운영에서 어려운 것은 대개 기술이 아니라 판단과 조율이다.

무엇으로 평가하는가

15장에서 클러스터 운영 지표로 Goodput·MFU 를 봤다. 그건 기계의 지표이고, 이 절의 것은 조직의 지표다. AI 데이터센터 운영은 두 가지를 같이 봐야 한다 — GPU 가 놀지 않는 것과, 사람이 사고에서 배우는 것.

이 두 장이 앞의 열일곱 장과 만나는 곳

18·19장은 새로운 내용을 가르치지 않는다. 앞 장에서 세운 식을 손으로 확인한다.

참고 자료

• mrgrit/kt66 — 시나리오 34종, 고장 주입 48종, envsim·noc·injector
• mrgrit/kt66 · scenarios — 시나리오별 주입 대상·증거 위치·구현 상태
• mrgrit/dawnofagi — L1~L4 제어 평면, 게이트, AOC, HITL 승인 큐
• mrgrit/el34 — kt66 의 베이스가 된 4-tier 보안 실습 랩
• Wazuh 문서 — SIEM 수집·탐지 규칙
• Google SRE Book · Postmortem Culture — 비난 없는 사후 검토
• 이 과목 15장(운영·관측) · 16장(국내 사례의 장애 기록) — 이 장의 절차가 그 사례들에서 나왔다