개념
도구는 프랙티스의 그릇이다
레슨 3에서 인시던트 상태 흐름과 SLA 타이머를 시험했다. 그 흐름과 타이머는 어딘가에 설정 되어 있다. 채용 요건의 "Service Now, Zendesk 등 ITSM Tool 구축 또는 운영"은 바로 이 설정을 만들고 유지하는 일이다.
모듈 22 레슨 12에서 테스트 관리 도구를 고를 때 "도구가 프로세스를 대신하지 않는다"고 했다. ITSM 도구도 같다. 레슨 2의 네 차원으로 보면 도구는 정보와 기술 한 칸이다. 조직과 사람, 파트너, 가치 흐름이 정해지지 않은 채 도구를 먼저 사면, 도구의 기본 흐름이 조직의 흐름이 된다. 때로는 괜찮지만, 대개 아무도 선택하지 않은 정책 이 운영된다.
두 도구는 출발점이 다르다
ServiceNow와 Zendesk는 같은 목록에 오르지만 출발점이 다르다.
| 관점 | ServiceNow | Zendesk |
|---|---|---|
| 출발점 | 엔터프라이즈 IT 서비스 관리 플랫폼 | 고객 지원 헬프데스크 |
| 핵심 강점 | 인시던트·문제·변경·요청, CMDB, 서비스 포털, 거버넌스 | 티켓팅, 다채널 접수, SLA 정책, 자동화, 빠른 도입 |
| 변경 관리 | 변경 모델(표준·일반·긴급)과 승인 흐름을 기본 제공 | 전용 변경 관리 워크플로가 없어 규칙으로 흉내 내야 한다 |
| 구성 관리 | CMDB와 서비스 의존 관계 매핑 | CMDB 없음 |
| 도입 규모 | 전담 관리자·구현 파트너가 흔히 필요 | 소규모 팀이 며칠 단위로 시작 가능 |
| ITIL 정렬 | 깊음 | 기본적인 서비스 데스크 흐름은 ITIL에 맞출 수 있으나 전체 ITSM 도구는 아니라는 평가가 많다 |
비교 해설들의 결론은 대체로 일치한다. 엄격한 ITIL 거버넌스와 변경·구성 관리가 필요한 내부 IT 운영에는 ServiceNow, 외부 고객 문의 중심의 비동기 티켓 처리에는 Zendesk. 두 도구를 함께 쓰는 조직도 많다. 고객 문의는 Zendesk로 받고, 그중 IT 인시던트는 ServiceNow로 넘기는 연동이다.
모듈 22에서 다룬 Jira Service Management 도 같은 목록의 후보다. 개발 조직이 Jira를 이미 쓰고 있다면 결함 추적과 인시던트 기록을 연결하기 쉽다는 이점이 있다.
도구 선택 — 레슨 1~5에서 판단 축을 가져온다
모듈 22 레슨 12의 다섯 판단 축 을 ITSM으로 옮기면 이렇게 된다.
| 축 | 질문 | 앞 레슨 연결 |
|---|---|---|
| 프랙티스 범위 | 인시던트·요청만인가, 문제·변경·구성까지인가 | 레슨 2·3 |
| 인증 요구 | ISO/IEC 20000-1 증거를 도구 레코드로 낼 수 있는가 | 레슨 4 |
| 연동 | 결함 추적(Jira)·모니터링·CI/CD와 연결되는가 | 레슨 1 접점 |
| 운영 역량 | 설정을 유지할 전담 인력이 있는가 | 레슨 2 네 차원 ① |
| 총비용 | 라이선스 + 구현 + 업그레이드 대응 + 교육 | 모듈 22 레슨 12 |
"운영 역량" 줄을 과소평가하면 안 된다. 강력한 플랫폼일수록 설정이 복잡하고, 설정을 이해하는 사람이 떠나면 아무도 건드리지 못하는 워크플로 가 남는다.
ServiceNow — 변경 모델을 시험하기
ServiceNow의 변경 관리는 레슨 3의 세 유형을 변경 모델 로 구현한다. 공개 자료들이 정리한 기본 구조는 이렇다.
| 유형 | 도구에서의 성격 |
|---|---|
| 표준 변경 | 사전 승인된 저위험·반복 변경. 템플릿(표준 변경 카탈로그)으로 요청, 매번 승인하지 않음 |
| 일반 변경 | 위험 평가·계획·승인을 거치는 전체 수명주기 |
| 긴급 변경 | 그룹·동료 검토를 건너뛰고 승인 단계로 바로 가서 긴급 승인 그룹이 승인 |
각 유형은 변경 모델 에 연결되어, 거칠 상태와 승인의 유무가 모델마다 정해진다. 일반 변경은 대략 신규 → 평가 → 승인 → 예정 → 구현 → 검토 → 종료 같은 흐름을 따른다(버전과 구성에 따라 다르다).
이 설정에서 시험할 것은 레슨 3의 상태 전이 시험을 유형별로 반복하는 것이다.
| 시험 | 기대 |
|---|---|
| 표준 변경 템플릿 밖의 항목을 표준 변경으로 요청 | 불가 또는 일반 변경으로 전환 |
| 일반 변경이 승인 없이 구현 상태로 전이 | 불가 |
| 긴급 변경의 사후 검토 누락 | 종료 불가 또는 검토 과업 자동 생성 |
| 위험 평가 결과 "높음"인데 저위험 권한자에게 배정 | 배정 규칙이 고위험 승인자로 라우팅 |
| 변경 기간 충돌(같은 CI에 겹치는 일정) | 충돌 경고 |
| 승인자가 요청자 본인 | 자기 승인 불가 |
마지막 줄은 모듈 35 레슨 3의 역할 독립성 과 같은 원칙이다. 도구가 자기 승인을 막지 않으면 변경 권한자 설계가 설정 수준에서 무너진다.
Zendesk — SLA 정책과 트리거를 시험하기
Zendesk의 SLA 정책은 지표를 조합해 정의한다. 도움말 문서가 정의한 주요 지표는 이렇다.
| 지표 | 측정 구간 |
|---|---|
| 첫 응답 시간 | 티켓 생성부터 에이전트의 첫 공개 댓글까지 |
| 다음 응답 시간 | 가장 오래된 미응답 고객 댓글부터 에이전트의 다음 공개 댓글까지 |
| 주기적 업데이트 | 에이전트 공개 댓글 사이의 간격 |
| 일시 정지 가능 업데이트 | 신규·열림·보류 상태의 에이전트 댓글 간격, 대기(Pending) 상태에서 정지 |
| 요청자 대기 시간 | 신규·열림·보류 상태에 머문 시간의 합 |
| 에이전트 작업 시간 | 신규·열림 상태에 머문 시간의 합 |
| 총 해결 시간 | 생성부터 해결까지 전체 |
설정에서 흔히 결함이 되는 규칙이 문서에 명시되어 있다.
- 정책은 조건에 맞는 첫 정책이 적용 되므로, 제한적인 정책을 목록 위쪽에 둬야 한다
- 티켓에 우선순위 값이 없으면 SLA가 적용되지 않는다
- 우선순위마다 달력 시간 / 업무 시간 을 고른다
그리고 트리거 는 티켓이 생성·갱신되는 이벤트 직후 조건을 확인해 실행되고, 닫힌 티켓에서는 실행되지 않는다. 시간 경과를 기준으로 동작하는 규칙은 자동화(automation)가 맡으며, 자동화가 티켓을 바꾸면 그 변경이 다시 트리거를 실행시킬 수 있다.
이 규칙들이 시험 설계를 정한다.
| 시험 | 확인할 것 |
|---|---|
| 우선순위 없이 생성된 티켓 | SLA 미적용 — 이런 티켓이 생길 수 있는 경로(이메일 접수 등)마다 우선순위 자동 지정이 있는가 |
| VIP 조건과 일반 조건을 모두 만족 | 목록 순서대로 VIP 정책이 적용되는가 |
| 대기(Pending) 전환 | 일시 정지 가능 업데이트는 정지, 요청자 대기 시간은 누적 제외 |
| 업무 시간 정책: 금요일 17:55 생성 | 다음 영업일로 목표 계산 |
| 트리거 두 개가 서로의 조건을 만족 | 연쇄 실행·무한 갱신이 없는가 |
| 자동화가 우선순위를 올림 | 뒤따르는 트리거와 SLA 재계산 |
첫 줄이 가장 값이 크다. 우선순위가 비어 SLA 밖에 있는 티켓 은 SLA 보고서에 나타나지 않으므로, 보고서만 보면 달성률이 좋아 보인다. 레슨 4의 SLA 보고서 재계산 심사 에서 이런 티켓을 따로 세는 이유다.
ServiceNow ATF — 업그레이드마다 설정을 회귀 시험하기
ITSM 플랫폼은 벤더가 정기적으로 버전을 올린다. 업그레이드는 기본 기능뿐 아니라 조직이 만든 설정과 맞춤 개발 에 영향을 준다. 매번 사람이 흐름을 전부 눌러 보는 것은 불가능하다.
ServiceNow는 이를 위해 플랫폼 안에서 기능 시험을 자동화하는 ATF(Automated Test Framework) 를 제공한다. 구조는 모듈 13에서 배운 UI 자동화와 비슷하다.
테스트 스텝 재사용 가능한 동작·검증 단위 (레코드 열기, 필드 설정, 제출, 값 검증 …)
테스트 스텝의 나열 — 사용자 행동을 흉내 내고 기대 결과를 확인
테스트 스위트 여러 테스트의 묶음 — 배포·업그레이드 때 한 번에 실행해설 자료들이 강조하는 ATF의 가장 큰 효용은 업그레이드 회귀 다. 몇 주 걸리던 전체 회귀를 몇 시간으로 줄이면 업그레이드 주기를 따라갈 수 있다. 서버 측 스크립트로 사용자 정의 스텝도 만들 수 있다.
ATF 스위트를 설계할 때 우선순위는 레슨 3의 시험 표에서 나온다.
스위트 1 인시던트 핵심 흐름 상태 전이 · 필수 필드 · 배정 규칙 · 우선순위 매트릭스
스위트 2 SLA 타이머 시작·정지·위반 · 업무 시간 · 우선순위 변경 재계산
스위트 3 변경 모델 유형별 상태 전이 · 승인 라우팅 · 자기 승인 차단 · 일정 충돌
스위트 4 서비스 요청 카탈로그 항목별 승인·이행 과업 생성
스위트 5 연동 결함 추적·모니터링 연동 필드 매핑 (가능한 범위)모듈 11에서 자동화할 대상을 고르는 기준 — 자주 반복되고, 결과가 결정적이고, 실패 비용이 큰 것 — 이 그대로 적용된다. SLA 타이머는 시간을 다루는 시험이라 자동화할 때 시계 제어나 과거 시각 레코드 생성 같은 기법이 필요하다. 이런 스텝은 모듈 13 레슨의 대기·동기화 문제와 같은 주의가 필요하다.
구축 프로젝트의 인수 기준
ITSM 도구 구축 프로젝트는 대개 "설정 완료" 로 인수된다. 레슨 1~5를 거친 QA라면 인수 기준을 이렇게 세운다.
| 인수 기준 | 증거 |
|---|---|
| 우선순위 매트릭스 전 칸이 조건대로 판정된다 | 결정 테이블 시험 결과(레슨 3) |
| SLA 정책이 정책서와 일치하고 경계·정지·업무 시간이 맞다 | SLA 시험 결과, 정책 대조표 |
| 변경 모델별 허용되지 않는 전이가 차단된다 | 상태 전이 시험 결과 |
| ISO/IEC 20000-1 대응표의 기록 항목이 도구 필드로 존재한다 | 조항 ↔ 필드 대응표(레슨 4) |
| SLA 보고서를 레코드에서 재계산하면 일치한다 | 재계산 결과 |
| 업그레이드 회귀 스위트가 존재하고 실행 기록이 있다 | ATF 스위트·실행 기록 |
| 설정 문서와 실제 설정이 일치한다 | 설정 내보내기와 문서 대조 |
네 번째 줄이 인증 조직에 특히 중요하다. 인증 심사에서 필요한 기록 — 변경 후 검토 결과, 문제의 원인 분석, 인시던트 해결 코드 — 이 도구 필드로 존재하지 않으면 운영자는 기록할 방법이 없다. 구축 단계에서 대응표를 필드 설계에 반영해야 한다.
운영 중 설정 변경도 변경이다
구축이 끝난 뒤에도 설정은 계속 바뀐다. 새 카탈로그 항목, SLA 목표 조정, 배정 그룹 개편. 이 설정 변경을 ITSM 도구 자신의 변경 관리로 통제 하는 것이 레슨 3의 원칙을 도구에 적용하는 방법이다.
- 설정 변경도 변경 요청으로 기록한다
- 개발·시험 인스턴스에서 먼저 반영하고 ATF(또는 수동 시험)로 회귀를 확인한다
- SLA 목표 변경은 보고서 산식과 과거 비교 가능성 에 영향을 주므로 발효 시점을 기록한다
마지막 줄은 모듈 22 레슨 8에서 대시보드 지표 정의가 바뀌면 추세가 끊긴다고 한 것과 같다.
실무에서 왜 필요한가
ITSM 도구 구축에서 가장 비싼 실패는 운영 첫 분기에 드러나는 설정 결함 이다. SLA가 적용되지 않는 티켓 경로, 승인 없이 구현으로 넘어가는 변경, 공휴일이 빠진 업무 시간. 이런 결함은 기능이 "동작"하므로 사용자 시험에서 잘 드러나지 않고, 보고서 숫자와 감사 기록에서 뒤늦게 드러난다. 레슨 3의 시험 설계를 구축 인수 기준으로 옮기면 이 실패를 출시 전에 막는다.
업그레이드 회귀 자동화는 운영 비용을 통제한다. 업그레이드마다 수동 회귀에 몇 주를 쓰는 조직은 결국 업그레이드를 미루고, 벤더 지원이 끝난 버전에 머물게 된다. ATF 스위트는 업그레이드를 일정 가능한 작업 으로 바꾼다. 이 자동화를 설계할 수 있는 사람은 ITSM 도구 운영 조직에서 드물다.
도구 선택 판단도 QA 경력자가 기여할 수 있는 영역이다. 고객 지원 중심 조직이 변경·구성 관리까지 요구받는 순간 Zendesk만으로는 한계가 드러나고, 반대로 작은 조직이 ServiceNow를 도입하면 설정을 유지할 역량이 없어 기본 흐름에 갇힌다. 레슨 1~5의 판단 축으로 필요한 프랙티스 범위와 운영 역량 을 먼저 정리하면 선택이 명확해진다.