Test Scenarios Journeys - MZC-CSC/mc-web-console GitHub Wiki

Test Scenarios — 여정 / 설치검증

생성: 2026-09-28 · 결과 기준: 최근 실행 2026-09-16 · 대상 배포 버전: web:0.5.2 infra:0.12.9 conn:0.12.18 wf:0.5.1 app:0.5.2 data:0.5.3 cost:0.5.2 obs:0.5.0

← Test Scenarios

업무 여정 (J)

J2

RBAC 온보딩 & 역할별 데모 시나리오 — 결과: ⬜ 미실행

역할 모델

사용자 ──소속──▶ 사용자그룹 ──할당──▶ 역할
                                      ├─ platform-role : 역할별 노출 메뉴 정의
                                      ├─ workspace-role: workspace에 할당하는 역할로 사용 유무
                                      └─ csp-role      : 대상 CSP 역할 매핑 (임시자격증명 발급용)

페르소나	그룹	클릭 가능 메뉴	타 메뉴 URL 직접 접근	CSP 임시자격증명
관리자 (admin)	grp-admin	전체 (Settings 포함)	—	✅
bill-viewer	grp-bill	Cost Analysis	unauthorized	✅ (viewer 매핑 역할)
bill-운영자	grp-bill-ops	Cost Analysis (+설정/실행)	unauthorized	✅ (billing-읽기쓰기 CSP 역할)
application-viewer	grp-app	SW Catalogs (조회)	unauthorized	✅
application-운영자	grp-app-ops	SW Catalogs (+배포/등록)	unauthorized	✅ (app-배포 CSP 역할)
workflow-viewer	grp-wf	Workflows (조회)	unauthorized	✅
workflow-운영자	grp-wf-ops	Workflows (+생성/실행)	unauthorized	✅ (wf-실행 CSP 역할)
monitoring-viewer	grp-mon	Monitorings (조회)	unauthorized	✅
monitoring-운영자	grp-mon-ops	Monitorings (+알람/에이전트 설정)	unauthorized	✅ (mon-수집 CSP 역할)

확정 스펙: ① 그룹·역할(3종 구성 포함)은 플랫폼 설치 시점에 시드, 계정 9종만 온보딩으로 추가. ② viewer 계열도 임시자격증명 발급 가능 (역할별 매핑된 CSP 역할로). ③ 비할당 메뉴 URL 직접 접근은 unauthorized 처리. ④ 사이드바 메뉴·Approvals 화면 정의 원본 = mc-iam-manager/asset/menu/menu.yaml. ⑤ 콘솔의 임시자격증명 요청 버튼은 미구현(TODO) — 구현 전까지 API 직접 호출로 검증(TC-IAM-TEMPCRED-01), 구현 후 TC-IAM-TEMPCRED-UI-01 작성.

Phase 0 — 설치 시드 검증 (그룹·역할은 설치 시점에 추가됨)

그룹/역할은 관리자 UI가 아니라 플랫폼 설치 시점에 시드된다. Phase 0은 시드가 온전한지 API로 검증하는 contract 단계다 (데모에서는 화면으로 시드 결과를 보여주는 것으로 대체 가능).

Step	검증	기대결과	관련 TC
0-1	그룹 시드	grp-* 9종 존재	TC-IAM-SEED-GROUPS-01
0-2	역할 시드	permission.yaml의 역할 전부 존재 + platform 메뉴 일치 + csp-role 매핑 존재	TC-IAM-SEED-ROLES-01
0-3	그룹-역할 할당 시드	PERSONAS group→platformRole 매핑과 일치	TC-IAM-SEED-GROUP-ROLE-01

Phase 1 — 공통 온보딩 (역할별 반복)

Step	화면	행동(주체)	기대결과	관련 TC
1-1	/auth/signup	가입 신청 (페르소나)	신청 완료, 로그인 불가 상태	TC-IAM-SIGNUP-01
1-2	Settings > Approvals	승인 + 그룹 배정 (관리자)	승인됨, 그룹 소속 확인	TC-IAM-APPROVE-01
1-3	/auth/login	로그인 (페르소나)	성공, 역할 반영된 세션	TC-IAM-LOGIN-01
1-4	첫 화면	사이드바 확인	자기 메뉴만 노출/클릭 가능	TC-IAM-MENU-VIS-01
1-5	타 도메인 메뉴 URL 직접 접근	강제 진입 시도	비노출 + 직접 URL도 거부(unauthorized)	TC-IAM-MENU-VIS-02

Phase 2 — 역할별 데모 (각 역할 = demo 1회 실행 단위)

J2-A 관리자 전체 메뉴 순회 → Approvals에서 대기 사용자 승인 시연 → CSP 임시자격증명 발급(관리 매핑) → 발급된 자격증명 식별자 확인.

J2-B1 bill-viewer / J2-B2 bill-운영자 로그인 → 사이드바에 Cost Analysis만 → 진입(iframe 로딩 확인) → viewer: 설정성 버튼 비노출·임시자격증명 요청 거부 확인 / 운영자: 비용 설정 변경 1건 + 임시자격증명 요청 → 매핑된 CSP 역할(billing)로 발급됨 확인.

J2-C1 application-viewer / J2-C2 application-운영자 로그인 → SW Catalogs만 → viewer: 카탈로그 조회, 배포 버튼 비노출 / 운영자: 카탈로그 항목 배포 1건 + 임시자격증명(app-배포 역할) 발급 확인.

J2-D1 workflow-viewer / J2-D2 workflow-운영자 로그인 → Workflows만 → viewer: 워크플로우 목록·이력 조회만 / 운영자: 워크플로우 생성→실행 1회 + 임시자격증명(wf-실행 역할) 발급 확인.

J2-E1 monitoring-viewer / J2-E2 monitoring-운영자 로그인 → Monitorings만 → viewer: 대시보드 조회만 / 운영자: 알람 규칙 1건 생성 + 임시자격증명(mon-수집 역할) 발급 확인.

임시자격증명 공통 검증 스텝 (전 역할)

콘솔 요청 버튼이 미구현(TODO)이므로 당분간 API 직접 호출로 검증한다. 버튼이 추가되면 T-1을 UI 클릭으로 교체하고 TC-IAM-TEMPCRED-UI-01을 구현한다.

Step	행동	기대결과	관련 TC
T-1	자격증명 요청 API 호출 (역할 토큰)	csp-role 매핑 조회됨	TC-IAM-TEMPCRED-01
T-2	발급 응답 확인	매핑된 CSP 역할명으로 STS 자격증명 발급 (accessKey/token 존재, 만료시각 유효)	TC-IAM-TEMPCRED-01

J3

워크플로우 기반 서비스 생성 (Infra / K8s / nodegroup) — 결과: ⬜ 미실행

항목	내용
페르소나	workflow-운영자(wfoperator) 또는 admin — wfoperator는 platform-role 시드 전까지 admin으로 실행
목표	생성 화면에서 정의 방식으로 workflow를 선택해, 선택한 workflow대로 Infra/K8s/nodegroup이 구성됨을 확인한다
사전조건	withWorkspace + 실행 가능한 workflow가 mc-workflow-manager에 등록돼 있음
계층	L2 (실 CSP — K8s는 ephemeral, 종료 시 삭제)

플로우 3종

J3-1 — Create Infra with workflow (TC-INFRA-CREATE-WF-01)

Step	화면	행동	기대결과 (assert)
1	Infra Workloads > Create Infra	정의 방식 = workflow 선택	workflow 목록 로딩·표시 (mc-workflow-manager 조회)
2	workflow 목록	Infra 구성 workflow 선택 → 실행	생성 요청 수락, workflow 실행 시작
3	Infra 목록	구성 완료 대기	workflow 정의대로 Infra 구성 (nodegroup/node 수·스펙 일치), Running
4	(teardown)	생성된 Infra 삭제	ephemeral — e2e-{runId}-* 잔존물 없음

J3-2 — Create Cluster with workflow (TC-K8S-CREATE-WF-01/02)

CSP별 생성 특성이 달라 지원 workflow를 구별해 진행한다:

CSP 특성	의미	대응 workflow	TC
cluster-only	클러스터만 생성, nodegroup은 이후 별도 추가	wf-k8s-cluster-only	TC-K8S-CREATE-WF-01
cluster+nodegroup	생성 시 nodegroup 동시 구성 필수/기본	wf-k8s-with-nodegroup	TC-K8S-CREATE-WF-02

Step	화면	행동	기대결과
1	K8s Workloads > Create Cluster	workflow 목록에서 CSP 특성에 맞는 workflow 선택	목록에 해당 CSP 지원 workflow만/구분 표시
2	실행	생성 요청	workflow 실행, cluster Creating
3	목록	Active 대기	cluster-only: nodegroup 0 / with-nodegroup: 정의된 nodegroup·node 수 일치
4	(teardown)	cluster 삭제	K8s는 ephemeral — 즉시 삭제

J3-3 — Add NodeGroup with workflow (TC-K8S-NODEGROUP-WF-01)

Step	화면	행동	기대결과
1	K8s Workloads > cluster 선택	Add NodeGroup 클릭	workflow 목록 표시
2	workflow 선택 → 실행	nodegroup 추가 요청	workflow 실행 수락
3	cluster 상세	완료 대기	workflow 정의대로 nodegroup 추가 (이름·node 수 일치), 기존 nodegroup 불변
4	(teardown)	cluster 삭제(J3-2와 연계) 또는 nodegroup 제거	잔존물 없음

검증 포인트 (workflow ↔ 실제 구성 대조)

"해당 workflow대로 구성"의 판정은: workflow 정의(mc-workflow-manager API에서 조회)에서 기대 리소스 명세(nodegroup 수, node 수, 스펙)를 읽어 → tumblebug 조회 결과와 대조한다. UI 표시 일치는 그 다음 단계 assert.

J5

operator의 Infra Workload 운영 여정 — 결과: ⬜ 미실행

항목	내용
페르소나	operator (운영 담당)
목표	운영 중인 Infra Workload의 node 제어와 nodegroup 스케일을 콘솔에서 수행한다
사전조건	withInfra — 풀의 Infra Workload가 Running (acquire가 resume 수행)

Steps:

Step	화면	행동	기대결과	관련 TC
1	Infra Workloads 목록	대상 Workload 선택	상세 패널 노출, node 목록 표시	—
2	node 목록	node 재시작	targetAction=Reboot → Running 복귀, publicIP 불변	TC-INFRA-NODE-REBOOT-01
3	nodegroup 패널	스케일 아웃 (1→2 node)	node 2대 Running, 목록 수 일치	TC-INFRA-NODEGROUP-SCALE-01
4	nodegroup 패널	스케일 인 (2→1 node)	원복, 잔존 node 정상	TC-INFRA-NODEGROUP-SCALE-02

J11

nodegroup 스케일 아웃 → nginx 설치 → NLB 연결·헬스체크 — 결과: ⬜ 미실행

항목	내용
페르소나	admin 또는 application-운영자(appoperator) — appoperator는 platform-role 시드 전까지 admin으로 실행
목표	운영 중인 Infra Workload를 스케일 아웃해 서비스 용량을 늘리고, nginx를 배포한 뒤 NLB로 노출해 헬스체크까지 확인한다
사전조건	withInfra — 풀의 Infra Workload Running (acquire가 resume 수행)
계층	L2 (실 CSP) — NLB·추가 node는 과금 대상

Steps:

Step	화면	행동	기대결과 (assert)	관련 TC
1	Infra Workloads 목록	대상 Infra 선택	상세 패널, nodegroup 목록 표시	—
2	nodegroup 패널	스케일 아웃 (1→2 node)	요청 수락, 신규 node Creating 전이	TC-INFRA-NODEGROUP-SCALEOUT-01
3	node 목록	전체 Running 대기	신규 node Running + 기존 node id/publicIP 불변(덮어써짐 사고 방어) + UI 노드 수 일치	TC-INFRA-NODEGROUP-SCALEOUT-01
4	Remote Command	nginx 설치 (nodegroup 대상 원격 명령)	명령 성공 응답, 각 node에서 curl localhost:80 200	TC-INFRA-CMD-NGINX-01
5	NLB	NLB 생성 — 해당 nodegroup의 node들 등록 + 포트 매핑(80→80)	PostNLB 성공, 대상 node 수 = nodegroup node 수, listener/target port 일치	TC-INFRA-NLB-CREATE-01
6	NLB 상세/목록	health check 응답 확인 (Check Health)	GetNLBHealth 응답에서 등록 node 전부 healthy (전이 대기 허용)	TC-INFRA-NLB-HEALTH-01
7	(teardown)	NLB 삭제 → 스케일 인(2→1) 원복	DelNLB 성공, 풀이 원래 구성(1 node)으로 복귀 후 suspend	—

설치 후 통합 검증 (IV)

IV1

v07 실행: 시나리오 · spec

로그인 & RBAC 초기 설정 — 결과: ⏭️ SKIP(09-11)

항목	내용
페르소나	admin
목표	클린 설치 직후 admin 로그인 → 그룹 생성 → (역할 할당) → 사용자 생성 → 그룹에 사용자 배정까지, RBAC 부트스트랩 전체 흐름이 화면에서 동작하는지 확인
사전조건	없음(비로그인 상태에서 시작) — 독립 실행, 테마 전체의 첫 관문
계층	L1(ui)

Steps:

Step	화면	행동	기대 결과
1	로그인	#id/#password 입력 → #loginbtn	POST /api/auth/login 성공, 인증 후 화면 진입
2	Groups	부모 노드 선택 → #btn-add-child → #create-group-form(#group-name 등) 입력 → 저장	POST /api/mc-iam-manager/Createorganization 성공, 트리에 새 그룹 노출
3	Roles	(확인만) Role 마스터 목록 존재 확인 — 그룹에 직접 역할을 할당하는 UI는 이 빌드에 없음(아래 비고)	역할 마스터(admin/operator/viewer/billadmin/billviewer) 목록 표시
4	Users	Add User(#usercreate 위저드) → 사용자 정보 입력 → 생성	사용자 생성 성공
5	Users	생성한 사용자 행 선택 → Assigned Groups 패널 → + Add Group → 그룹 선택 → Assign	그룹 배정 성공 — 현재 라이브 환경에서 404 재현됨(아래 비고)
6	(확장 포인트)	역할별 메뉴 구성이 실제로 다르게 노출되는지 확인	구현 완료(2026-08-21) — Step 2~5와 독립된 별도 test로 분리, 데모 계정 15종 전수 검증(아래 "Step 6" 절 참조)

IV2

v07 실행: 시나리오 · spec

Cloud Resources 제어 — 결과: ✅ PASS(09-11)

항목	내용
페르소나	admin
목표	Cloud Resources 화면군(Networks/SecurityGroups/SSHKeys/Disks/ServerSpecs/ServerImages/MyImages/NLBs)이 정상 로드되고, 여러 CSP의 자원이 한 목록에 함께 표시되는지 확인
사전조건	withWorkspace(admin) — 독립 실행, 다른 IV 여정에 의존하지 않음
계층	L1(ui)

Steps:

Step	화면	행동	기대 결과
1	Networks	화면 진입	#vnet-list-table 렌더, Provider 컬럼에 2개 이상 서로 다른 CSP 값 존재(멀티클라우드 확인)
2	SecurityGroups	화면 진입	#sg-list-table 렌더
3	SSHKeys / Disks / ServerSpecs / ServerImages / MyImages / NLBs	각 화면 진입	목록 테이블(#sshkey-list-table / #disk-list-table / #spec-table / #image-table / #myimage-list-table / #nlb-list-table)이 Tabulator로 초기화되어 렌더, 진입 중 미처리 JS 예외(pageerror) 없음

IV3

v07 실행: 시나리오 · spec

Workflows로 Infra/K8s 제어 — 결과: ⏭️ SKIP(09-11)

항목	내용
페르소나	admin
목표	Workflows 화면(iframe, mc-workflow-manager/Jenkins)에서 Infra 워크플로우 잡과 K8s 워크플로우 잡을 각각 RUN해 자원을 생성 — ★ 체인의 자원 생성 지점. 이후 IV4~IV7이 여기서 만든 자원을 이어받는다
사전조건	withWorkspace(admin) — 독립 실행(IV1/IV2에 의존하지 않음). 단 IV4~IV7은 이 여정의 산출물(Infra/K8s 이름)에 의존
계층	L1(ui, iframe)

Steps:

Step	화면	행동	기대 결과
1	Workflows	Workspace/Project 선택 후 화면 진입	iframe 로딩(mc-workflow-manager-fe 등록 후 /web/workflow/list), postMessage 핸드셰이크(accessToken/workspaceInfo/projectInfo) 수신
2	Workflows	Infra 관련 잡의 RUN 클릭 → 파라미터 입력 팝업에 e2e-{runId}-iv-infra + nodegroup ng01,ng02 입력 → 제출	Infra Workload 생성 요청 접수
3	Workflows	K8s 관련 잡의 RUN 클릭 → 파라미터 입력 팝업에 e2e-{runId}-iv-k8s + nodegroup ng01 입력 → 제출	K8s Workload 생성 요청 접수
4	Infra/K8s Workloads(native)	두 자원이 최종적으로 Running/Ready 상태에 도달	이후 여정이 이어받을 수 있는 상태

IV4

v07 실행: 시나리오 · spec

Infra/K8s 제어 — 결과: 🚧 BLOCKED

항목	내용
페르소나	admin
목표	IV3이 Workflow로 생성한 Infra/K8s 자원을 native 화면(Infra Workloads/K8s Workloads)에서 직접 제어(재부팅/스케일 등)할 수 있는지 확인
사전조건	withWorkspace(admin) — IV3 의존. 같은 런에서 IV3이 만든 e2e-{runId}-iv-infra/e2e-{runId}-iv-k8s를 이름으로 재탐색
계층	L1(ui)

Steps:

Step	화면	행동	기대 결과
0	Infra/K8s Workloads	선행 자원 존재 확인(가드)	없으면 🚧 BLOCKED로 자기보고, 원인 모를 FAIL로 죽지 않음
1	Infra Workloads	e2e-{runId}-iv-infra 검색 → 상세 진입	목록/상세에서 nodegroup ng01,ng02 확인
2	Infra Workloads	제어 동작(예: node reboot) 수행	상태 전이 확인
3	K8s Workloads	e2e-{runId}-iv-k8s 검색 → 상세 진입	nodegroup ng01 확인
4	K8s Workloads	제어 동작(예: nodegroup scale) 수행	상태 전이 확인

IV5

v07 실행: 시나리오 · spec

SW Catalogs 제어 (인프라가 있는 상태에서) — 결과: 🚧 BLOCKED

항목	내용
페르소나	admin
목표	IV3이 만든 Infra/K8s 자원을 대상으로 SW Catalogs(iframe, mc-sw-catalog)에서 SW를 설치할 수 있는지 확인
사전조건	withWorkspace(admin) — IV3 의존. Infra/K8s 둘 다 대상(배포 방식이 다를 수 있음 — VM SW 설치 vs K8s workload 배포)
계층	L1(ui, iframe)

Steps:

Step	화면	행동	기대 결과
0	Infra/K8s Workloads	선행 자원(Infra+K8s) 존재 확인(가드)	없으면 🚧 BLOCKED
1	SW Catalogs	화면 진입	iframe 로딩 + 핸드셰이크
2	SW Catalogs	e2e-{runId}-iv-infra 대상 SW 설치	설치 요청 접수
3	SW Catalogs	e2e-{runId}-iv-k8s 대상 SW(workload) 배포	배포 요청 접수

IV6

v07 실행: 시나리오 · spec

Cost Analysis 제어 (인프라가 있는 상태에서) — 결과: 🚧 BLOCKED

항목	내용
페르소나	admin
목표	IV3이 만든 Infra/K8s 자원의 비용 항목이 Cost Analysis(iframe, mc-cost-optimizer)에 각각 반영되는지 확인
사전조건	withWorkspace(admin) — IV3 의존. Infra/K8s 둘 다(K8s는 nodegroup 단위 비용까지)
계층	L1(ui, iframe)

Steps:

Step	화면	행동	기대 결과
0	Infra/K8s Workloads	선행 자원(Infra+K8s) 존재 확인(가드)	없으면 🚧 BLOCKED
1	Cost Analysis	화면 진입	iframe 로딩 + 핸드셰이크
2	Cost Analysis	Infra(e2e-{runId}-iv-infra) 비용 항목 확인	항목 존재(과금 반영에는 시차가 있을 수 있음 — 존재 여부만 확인)
3	Cost Analysis	K8s(e2e-{runId}-iv-k8s) nodegroup 단위 비용 항목 확인	항목 존재
4	Cost Analysis	IV2에서 관측된 CSP 집합과 교차 확인	멀티클라우드 비용 집계 일관성(coverage 관점)

IV7

v07 실행: 시나리오 · spec

Monitoring 제어 (인프라가 있는 상태에서) — 결과: 🚧 BLOCKED

항목	내용
페르소나	admin
목표	IV3이 만든 Infra/K8s 자원에 Monitoring(iframe, mc-observability) 에이전트를 설치할 수 있는지 확인
사전조건	withWorkspace(admin) — IV3 의존. Infra/K8s 둘 다(설치 방식이 다를 수 있음 — VM agent vs K8s용 모니터링)
계층	L1(ui, iframe)

Steps:

Step	화면	행동	기대 결과
0	Infra/K8s Workloads	선행 자원(Infra+K8s) 존재 확인(가드)	없으면 🚧 BLOCKED
1	Monitoring	화면 진입	iframe 로딩 + 핸드셰이크
2	Monitoring	e2e-{runId}-iv-infra 대상 모니터링 에이전트 설치	설치 요청 접수
3	Monitoring	e2e-{runId}-iv-k8s 대상 모니터링 설치(화면이 제공하는 방식대로)	설치 요청 접수

IV8

v07 실행: 시나리오 · spec

Data Migrations 제어 — 결과: ⏭️ SKIP(09-11)

항목	내용
페르소나	admin
목표	Data Migrations(mc-data-manager, iframe) 화면이 정상 로딩되고 postMessage 핸드셰이크가 성공하는지 확인
사전조건	withWorkspace — 독립 실행
계층	L1(ui, iframe)

Steps:

Step	화면	행동	기대 결과
1	Data Migrations	화면 진입	iframe 로딩, 토큰/workspace postMessage 핸드셰이크 수신
2	Data Migrations	iframe 내부 root 렌더 확인	콘텐츠 표시(빈 화면/에러 아님)