인프라 플랫폼 QA는 무엇을 검증하는가 — 제어 평면·데이터 평면·비동기 수렴·멀티테넌시

개념

웹 서비스 QA의 감각이 어디서 어긋나는가

웹 서비스 QA에서 결함은 대개 요청 한 번의 응답 에서 드러난다. 버튼을 누르면 화면이 틀리거나, API를 부르면 응답이 틀린다. 인프라 플랫폼에서는 응답이 맞아도 결함일 수 있다. 서버 생성 API는 202 Accepted 를 돌려주고 끝난다. 결함은 그 뒤 몇 초에서 몇 분 사이, 사용자가 보지 않는 곳에서 일어난다.

[웹 서비스]                         [인프라 플랫폼]
요청 → 응답 (결과가 응답에 있다)       요청 → 202 → ... 스케줄링 → 이미지 복사 → 네트워크 연결 → ACTIVE
                                                  ↑ 어느 단계에서든 멈추거나, 되돌려지지 않거나,
                                                    다른 테넌트의 자원을 건드릴 수 있다

여기서부터 이 모듈이 계속 쓰는 말들이 나온다. 지금 외울 필요는 없고, 읽다가 막히면 이 표로 돌아오면 된다.

202 Accepted 라는 응답 코드도 위 그림에 나온다. "요청은 접수했다, 다 됐다는 뜻은 아니다" 라는 뜻이다. 이 모듈의 결함이 거의 다 이 말 뒤에서 생긴다.

Private Cloud 관리 플랫폼, GPUaaS, AI 학습·추론 플랫폼은 모두 이 구조다. 이 모듈의 첫 문장은 이것이다. 인프라 플랫폼의 결함은 응답이 아니라 수렴하지 않는 상태와 남은 리소스로 드러난다.

제어 평면과 데이터 평면

인프라 플랫폼은 두 평면으로 나눠 보면 검증 대상이 정리된다.

중요한 성질이 하나 있다. 제어 평면이 멈춰도 데이터 평면은 계속 돌아야 한다. API 서버가 재시작되는 동안 이미 실행 중인 학습 작업이나 추론 엔드포인트가 멈추면 안 된다. 이것 자체가 핵심 검증 기준이고, 레슨 7의 장애 주입에서 다시 본다.

요청이 아니라 상태를 검증한다 — 비동기 수렴

선언형 시스템(Kubernetes)이든 명령형 API(OpenStack)든, 인프라 리소스는 원하는 상태 와 현재 상태 를 갖고, 컨트롤러가 현재 상태를 원하는 상태로 끌고 간다. QA가 검증할 것은 "요청이 받아들여졌다"가 아니라 "정해진 시간 안에 원하는 상태로 수렴했고, 그 과정의 중간 상태가 허용된 것뿐이었다" 이다.

[서버 생성 상태 모델 — 검증 기준으로 쓴 것]
허용 경로:   BUILD → ACTIVE
허용 경로:   BUILD → ERROR  (단, error 필드에 원인 코드 필수)
금지:       ACTIVE → BUILD (사용자 조작 없이)
금지:       BUILD 상태로 15분 초과 체류
수렴 시간:   p95 90초 이하 (플레이버 gpu.a100.1, 이미지 캐시 적중 기준)
종료 후:     ERROR 로 끝나면 포트·볼륨·예약된 GPU 가 60초 안에 반환

이 기준을 테스트 코드로 옮길 때 가장 흔한 실수는 sleep(60) 한 뒤 상태를 한 번 보는 것이다. 모듈 13 레슨 5의 대기 전략이 인프라 검증에서 더 중요해진다.

def wait_for_status(get_status, target, allowed, timeout_s, interval_s=2):
    """상태를 폴링하며 전이 경로 전체를 기록한다."""
    history = []
    deadline = time.monotonic() + timeout_s
    while time.monotonic() < deadline:
        status = get_status()
        if not history or history[-1] != status:
            history.append(status)
        if status not in allowed:
            raise AssertionError(f"허용되지 않은 상태 {status}, 경로 {history}")
        if status == target:
            return history
        time.sleep(interval_s)
    raise AssertionError(f"{timeout_s}초 안에 {target} 미도달, 경로 {history}")

이 함수가 하는 일은 셋이다. 경로를 기록 해서 실패 시 어디서 멈췄는지 보여준다. 허용되지 않은 중간 상태 를 즉시 실패로 잡는다. 타임아웃을 기준에서 가져온다(임의 값이 아니라). 폴링 간격이 너무 짧으면 API에 부하를 주고, 너무 길면 짧게 스쳐 간 금지 상태를 놓친다. 상태 변경 이벤트(Kubernetes watch, 알림 큐)를 구독할 수 있으면 폴링보다 정확하다.

부분 생성 누수와 부수 효과

인프라 리소스는 여러 하위 리소스로 조립된다. GPU 서버 하나에 포트·볼륨·보안 그룹 연결·GPU 예약·과금 이벤트가 따라온다. 생성이 중간에 실패하거나 삭제가 중간에 멈추면 일부만 남는다. 이것이 인프라 플랫폼에서 가장 자주, 가장 조용히 쌓이는 결함이다.

실무에서 효과가 큰 방식이 테스트 전후 스냅샷 비교 다. 테스트 프로젝트의 리소스·사용량·할당량을 테스트 시작 전에 찍고, 테스트가 정리까지 끝낸 뒤 다시 찍어 비교한다. 차이가 있으면 제품 결함이거나 테스트의 정리 결함이다. 둘 다 기록할 가치가 있다. 테스트의 정리 결함도 결국 스테이징을 오염시켜 다른 테스트를 플래키하게 만든다.

멀티테넌시와 격리

Private Cloud 플랫폼은 여러 조직·팀·프로젝트가 같은 물리 자원을 나눠 쓴다. 격리 실패는 보안 사고다. 격리는 층마다 따로 검증한다.

API 권한 검증에서 자주 놓치는 것이 존재 은닉 이다. 다른 프로젝트의 서버 ID로 조회했을 때 403 Forbidden 을 주면, 공격자는 그 ID의 리소스가 존재한다 는 것을 안다. 정책에 따라 404 로 통일하는 경우가 많다. 어느 쪽이 정책인지 확인하고 기준으로 쓴다(모듈 38 레슨 1의 "명세에 없어서 QA가 더해야 하는 기준").

소버린·에어갭 환경이 더하는 제약

데이터 주권을 보장하는 소버린 클라우드, 공공·금융·연구기관의 폐쇄망 설치형 플랫폼은 검증에 고유한 조건을 더한다.

"외부 인터넷 차단 상태에서 설치가 끝나는가"는 의외로 자주 깨진다. 개발 환경에서는 누군가의 스크립트가 공용 저장소에서 헬름 차트나 파이썬 패키지를 조용히 받아 오기 때문이다. 네트워크를 실제로 끊은 환경에서의 설치 검증 을 릴리스 전 층에 둔다.

인프라 플랫폼 검증 기준의 뼈대

이 레슨의 내용을 기준 체크리스트 뼈대로 묶으면 모든 리소스 유형에 반복 적용할 수 있다.

리소스 유형 X 에 대해
[ ] 생성: 정상 수렴 시간, 허용 중간 상태, 실패 시 원인 코드
[ ] 생성 실패: 하위 리소스·쿼터·예약·과금 원상 복구
[ ] 수정: 실행 중 리소스에 대한 영향 (재시작 여부 명시)
[ ] 삭제: 하위 리소스 정리, 과금 중단, 삭제 중 실패 시 재시도 가능성
[ ] 동시성: 같은 리소스에 동시 수정·삭제, 멱등성 키
[ ] 격리: 다른 프로젝트 권한·쿼터·네트워크·스토리지·관측
[ ] 제어 평면 장애: 데이터 평면 워크로드 지속
[ ] 업그레이드: 이전 버전에서 만든 리소스 유지·조작 가능
[ ] 폐쇄망: 외부 의존 없음

실무에서 왜 필요한가

GPU 클라우드에서 부분 생성 누수 하나가 남기는 비용은 웹 서비스의 화면 결함과 차원이 다르다. GPU 예약이 반환되지 않으면 수천만 원짜리 장비가 아무도 쓰지 않는데 가득 찬 상태 로 보인다. 과금 이벤트가 삭제 후에도 나가면 고객 신뢰와 정산 분쟁으로 이어진다. 이런 결함은 응답만 보는 테스트로는 절대 잡히지 않는다.

채용 공고의 "Private Cloud 관리·AI 학습·추론·AI 에이전트 플랫폼의 기능 검증"과 우대사항의 "Kubernetes/OpenStack, GPU·AI 워크로드 등 인프라 플랫폼 도메인에서 QA를 해 본 경험"이 요구하는 것은 도구 이름보다 이 감각이다. 면접에서 "API 테스트를 자동화했다"보다 "202 이후의 상태 경로를 기록하는 대기 함수로 BUILD 체류 결함을 잡았다", "테스트 전후 스냅샷 비교로 포트 누수를 찾았다"가 도메인 경험을 증명한다.

실습 과제

과제 1 — 평면 나누기 (10분)

아래 결함을 제어 평면·데이터 평면으로 분류하고, 각각을 잡을 검증 방법을 한 줄로 적는다.

1. 학습 작업을 취소했는데 GPU 가 노드에서 계속 할당된 것으로 보인다
2. 추론 엔드포인트의 p99 지연이 업그레이드 후 두 배가 됐다
3. 프로젝트 쿼터 화면에 다른 프로젝트 사용량이 합산된다
4. API 서버 재시작 중 실행 중인 VM 의 네트워크가 30초 끊긴다
5. 볼륨 삭제 후 새 볼륨에서 이전 데이터 일부가 읽힌다

과제 2 — 상태 모델 기준 (20분)

"추론 엔드포인트 생성"의 상태 모델(허용 경로·금지 전이·최대 체류 시간·수렴 시간·실패 후 정리)을 본문 형식으로 쓴다. 모델 가중치 다운로드, GPU 스케줄링, 헬스체크 통과를 중간 상태로 포함한다.

과제 3 — 스냅샷 비교 설계 (20분)

테스트 전후에 찍을 스냅샷 항목(리소스 목록·사용량·할당 가능 GPU·과금 이벤트 등)을 정하고, 차이가 났을 때 제품 결함과 테스트 정리 결함을 가르는 절차를 적는다.

과제 4 (선택) — 폐쇄망 설치 검증 (15분)

외부 인터넷이 차단된 고객 환경에 플랫폼을 설치·업그레이드하는 검증 계획을 쓴다. 네트워크를 실제로 끊는 방법, 외부 의존을 찾아내는 관찰 방법, 통과 기준을 포함한다.

자가 체크리스트

• 인프라 플랫폼의 결함이 응답이 아니라 상태와 남은 리소스로 드러나는 이유를 설명할 수 있다
• 제어 평면과 데이터 평면을 구분하고 각각의 결함 모습과 검증 방법을 말할 수 있다
• 제어 평면 장애 중 데이터 평면이 지속돼야 한다는 기준을 안다
• 상태 모델을 허용 경로·금지 전이·체류 시간·수렴 시간으로 기준화할 수 있다
• 경로를 기록하고 금지 상태를 즉시 잡는 폴링 대기 함수를 설계할 수 있다
• 부분 생성 누수와 쿼터·과금·예약·감사 로그 부수 효과를 검증할 수 있다
• 테스트 전후 스냅샷 비교로 누수를 찾는 방법을 안다
• 멀티테넌시 격리를 API·쿼터·네트워크·스토리지·GPU·관측 층으로 나눠 검증할 수 있다
• 소버린·에어갭 환경이 검증 도구·증거·설치 검증에 주는 제약을 말할 수 있다

흔한 실수

202를 받고 테스트를 끝낸다. 인프라 리소스는 수렴해야 생성된 것이다.

sleep 후 상태를 한 번 본다. 중간의 금지 상태와 멈춘 지점을 놓친다.

생성 실패 테스트에서 응답만 본다. 남은 포트·볼륨·예약·카운터를 본다.

403과 404를 구분하지 않는다. 존재 여부 노출이 정책 위반일 수 있다.

개발 환경에서 설치가 되니 폐쇄망에서도 된다고 가정한다. 네트워크를 실제로 끊고 확인한다.

참고 자료

• Kubernetes Components — control plane과 노드 구성요소
• OpenStack Compute (Nova) — Server concepts and status
• Agent Sandbox on Kubernetes (Northflank) — 격리 백엔드 비교
• 이 커리큘럼 안: 모듈 4 레슨 2 「리스크 식별」, 모듈 12 레슨 1 「API 테스트」, 모듈 13 레슨 5 「대기 전략」, 모듈 38 레슨 1 「AI가 판정할 수 있는 검증 기준」