개념
레슨 6에서 설계한 것을 손으로 올려 본다
레슨 6은 도구를 고르고 시험을 설계 하는 레슨이었다. 변경 모델별 상태 전이 표, Zendesk SLA 정책 시험 표, ATF 스위트 다섯 개. 그런데 그 표들은 도구를 한 번도 열어 보지 않고도 쓸 수 있다. 그래서 면접에서 "ServiceNow 변경 모델을 시험해 봤다"고 말하면 다음 질문이 바로 온다. "어느 테이블의 어느 필드를 봤나요?"
이 레슨은 그 질문에 답할 수 있게 만드는 실습이다. 개념은 더 늘리지 않는다. 대신 환경을 받아서, 데이터를 만들고, 설정을 바꾸고, 시험을 돌리고, 증거를 남기는 순서 를 처음부터 끝까지 한 번 밟는다.
실습이 끝나면 산출물 네 개가 남는다.
1. 실습 기록지 무엇을 눌렀고 무엇이 나왔는가 (단계별 화면·레코드 번호)
2. 관찰 목록 기대와 달랐던 것, 정책이 비어 있던 곳
3. ATF 테스트 1건 직접 만들어 실행한 자동 시험과 실행 결과
4. 도구 비교표 같은 흐름을 두 도구에서 만들며 겪은 차이레슨 7의 자격 + 산출물 포트폴리오 에서 "ITSM 도구 설정을 시험하고 인수 기준을 세울 수 있는가" 칸을 채우는 것이 이 네 개다.
실습 환경 두 가지
| ServiceNow 개인 개발자 인스턴스(PDI) | Jira Service Management 무료 플랜 | |
|---|---|---|
| 얻는 법 | ServiceNow Developer 프로그램 가입 후 인스턴스 요청 | Atlassian 계정으로 사이트 생성 |
| 성격 | 전체 플랫폼 이 들어 있는 격리된 인스턴스 (관리자 권한) | 클라우드 제품의 무료 등급 |
| 관리자 권한 | 있음 — 테이블·워크플로·속성까지 바꿀 수 있다 | 사이트 관리자 권한은 있으나 플랫폼 내부는 아님 |
| ITSM 범위 | 인시던트·문제·변경·요청·CMDB·ATF 전부 | 인시던트·요청 중심. 플랜에 따라 변경·SLA 제공 범위가 다르다 |
| 유지 조건 | Developer 사이트에서 10일 동안 활동이 없으면 휴면 되고, 휴면 상태가 이어지면 회수되어 초기화된다 | 사용량 한도(에이전트 수·저장 용량·자동화 실행 횟수)가 있다 |
| 실습 적합도 | 워크플로·승인·SLA·자동 시험까지 전부 | 티켓 흐름과 큐·자동화 감각 익히기 |
PDI의 휴면 규칙 은 실습 계획에 직접 영향을 준다. 실습을 여러 날에 나눠 할 거면 중간에 Developer 사이트에 로그인해 인스턴스를 깨워 둔다. 회수되면 만들어 둔 레코드와 설정이 전부 사라진다. 그래서 이 레슨의 실습 기록지는 도구 밖에 둔다(표·문서 파일). 증거를 인스턴스 안에만 두면 휴면 한 번에 실습이 증발한다.
Jira Service Management 무료 플랜에서 어떤 기능이 포함되는지는 확인 시점마다 달라진다. SLA·변경 관리·감사 로그가 어느 플랜부터인지는 Atlassian 가격 페이지에서 직접 확인하고, 이 레슨의 실습 중 "무료 플랜에서 불가능한 항목"은 그 자체를 관찰 목록에 적는다. 도구가 제공하지 않는 기능은 조직이 규칙으로 메워야 하는 공백 이고, 그 공백이 곧 운영 결함의 자리다(레슨 6의 "Zendesk로 전체 ITSM을 구현하려 한다").
단계 0 — 시나리오를 먼저 고정한다
도구부터 열면 기본 데이터에 휩쓸린다. 실습 전에 가상의 서비스와 정책 을 한 장으로 고정한다. 레슨 3에서 만든 우선순위 매트릭스와 SLA 정책을 그대로 쓰면 된다.
[실습 시나리오 — 사내 급여 포털 "PAY"]
서비스 PAY (급여 조회·명세서 발급), 업무 시간 평일 09:00~18:00, 공휴일 제외
영향 높음 = 전사 로그인 불가 또는 급여일 D-1~D일 명세서 발급 불가
중간 = 특정 사업장(전체의 30% 미만) 영향
낮음 = 개인 1~2명
긴급도 높음 = 급여일 D-3 이내 / 중간 = 이번 달 안 / 낮음 = 기한 없음
SLA P1 응답 15분·복구 4시간 (달력 시간)
P2 응답 30분·복구 8업무시간
P3 응답 4업무시간·복구 3영업일
보류 정지 "공급사 대기" 사유일 때만 타이머 정지
변경 표준 = 계정 권한 추가 / 일반 = 기능 배포 / 긴급 = 악용 중 취약점 패치이 한 장이 실습 내내 기대값 이 된다. 도구가 다르게 동작하면 그것이 관찰이다.
단계 1 — PDI 발급과 첫 점검 (15분)
1. ServiceNow Developer 사이트에 가입하고 개인 개발자 인스턴스를 요청한다
2. 인스턴스 URL·admin 계정·임시 비밀번호를 받는다 → 실습 기록지 맨 위에 적는다
3. 로그인 후 확인할 것
- 인스턴스 릴리스(버전) 이름 → 화면·필드가 문서와 다를 때 근거가 된다
- 목록 화면에서 incident 테이블이 열리는가
- 관리자(admin) 역할이 붙어 있는가주소창 대신 탐색 필터에 테이블 이름을 직접 치는 방법 을 처음부터 익혀 둔다. incident.list, problem.list, change_request.list,
sys_properties.list 처럼 테이블명.list 를 넣으면 해당 테이블 목록이 열린다. 메뉴 구조는 릴리스마다 바뀌지만 테이블 이름은 잘 바뀌지 않는다.
QA가 결함 리포트에 "Incident > Open 메뉴에서" 대신 "incident 테이블에서 state=2 조건으로" 라고 쓰면 재현이 흔들리지 않는다.
단계 2 — 인시던트 한 건을 끝까지 (20분)
시나리오의 P2 인시던트를 하나 만들고 종료까지 끌고 간다. 중간에 각 단계의 레코드 번호와 시각을 기록지에 적는다.
접수 "부산 사업장에서 명세서 PDF 발급이 실패한다" — 영향 중간 / 긴급도 높음
→ 도구가 매긴 우선순위가 시나리오의 P2와 같은가? ← 관찰 1
배정 담당 그룹·담당자 지정
진행 작업 메모(work note)와 고객 공지(additional comment)를 각각 하나씩 남긴다
→ 두 필드의 차이가 화면과 알림에서 어떻게 드러나는가? ← 관찰 2
보류 사유 없이 보류로 바꿔 본다 ← 관찰 3
해결 해결 코드·해결 메모 없이 해결로 바꿔 본다 ← 관찰 4
종료 해결 후 바로 종료해 본다 / 자동 종료 설정을 찾아본다 ← 관찰 5관찰 3~5가 레슨 3의 허용되지 않아야 할 전이 시험을 손으로 한 것이다. 기본 설정의 ServiceNow는 이 중 일부만 막는다. 막히지 않은 칸이 나오면 그것이 결함이 아니라 설정 공백 이다. 기록지에는 이렇게 적는다.
관찰 4 해결 코드 없이 "해결됨"으로 저장됨
기대(시나리오): 불가
실제: 저장됨, 경고 없음
조치 후보: 필수 필드 규칙(UI 정책/데이터 정책) 추가 → state=6 일 때 close_code 필수
영향: 해결 코드 없는 인시던트는 문제 관리의 입력이 되지 못한다(레슨 3)"조치 후보"와 "영향"을 적는 습관이 이 실습의 핵심이다. 관찰만 나열한 기록지는 스크린샷 모음이고, 조치와 영향이 붙으면 설정 검토 보고서 가 된다.
단계 3 — 문제와 알려진 오류로 승격 (15분)
같은 증상의 인시던트를 두 건 더 만든다. 세 건이 쌓이면 문제 기록을 만든다.
1. problem 테이블에 문제 레코드 생성
2. 인시던트 세 건을 문제에 연결한다 (관련 레코드)
3. 원인 분석 칸을 채우고 해결 방법(workaround)을 적는다
4. 문제 상태를 "알려진 오류" 에 해당하는 값으로 바꾼다
5. 원래 인시던트 화면으로 돌아가 문제 링크와 해결 방법이 보이는지 확인한다 ← 관찰 6관찰 6이 레슨 3에서 말한 첫 접촉 해결률을 올리는 가장 싼 방법 의 실체다. 해결 방법이 인시던트 담당자 화면까지 내려오지 않으면, 문서화해도 쓰이지 않는다. "지식 문서로 연결해야 보이는가, 문제 링크만으로 보이는가"를 직접 확인한다.
단계 4 — 변경 세 유형과 승인 흐름 (20분)
change_request 테이블에서 세 유형을 하나씩 만든다.
| 만들 것 | 확인할 것 |
|---|---|
| 표준 변경 "계정 권한 추가" | 템플릿(표준 변경 카탈로그)에서 고르는가, 자유 입력인가. 승인 단계가 있는가 |
| 일반 변경 "명세서 PDF 엔진 업그레이드" | 위험 평가 필드가 무엇인가. 승인 없이 구현 상태로 넘길 수 있는가 |
| 긴급 변경 "악용 중 취약점 패치" | 어느 단계가 생략되는가. 사후 검토 과업이 생기는가 |
그리고 레슨 6의 표에서 가장 값이 큰 한 줄을 직접 시험한다.
[자기 승인 시험]
1. 일반 변경을 만들고 요청자를 현재 로그인 사용자로 둔다
2. 승인자에도 같은 사용자를 지정한다
3. 승인 화면에서 본인이 승인할 수 있는가? ← 관찰 7
기대: 불가 (역할 독립성 — 모듈 35 레슨 3)막히지 않으면 그대로 적는다. 기본 설정이 자기 승인을 막지 않는다면, 구축 인수 기준에 이 항목을 넣어야 한다 는 근거가 생긴 것이다. 이 한 줄이 면접에서 "설정을 시험한 사람"과 "설정을 구경한 사람"을 가른다.
단계 5 — SLA 정의와 경계 관찰 (20분)
SLA는 시간을 다루기 때문에 손으로 시험하기 가장 까다롭다. 실습에서는 세 가지만 한다.
1. SLA 정의 목록을 연다 (contract_sla 테이블)
2. 기본 제공되는 인시던트 SLA 정의 하나를 열어 구조를 읽는다
- 시작 조건 / 정지 조건 / 종료 조건
- 기간(duration)과 일정(schedule) — 업무 시간·공휴일 달력이 여기 붙는다
3. 시나리오의 P2 응답 30분 SLA 를 흉내 낸 정의를 하나 만든다
4. 인시던트를 만들고 task_sla 테이블에서 타이머 레코드가 붙는지 확인한다 ← 관찰 8여기서 반드시 부딪히는 문제가 있다. 경계를 시험하려면 30분을 기다려야 한다. 실무에서 쓰는 세 가지 우회가 있고, 실습에서는 첫 번째만 쓴다.
| 방법 | 방식 | 실습 적합성 |
|---|---|---|
| 기간을 줄인다 | 시험용 SLA 정의의 기간을 30분 대신 2분으로 | 가장 안전. 경계 동작 자체는 같은 코드가 처리한다 |
| 레코드 시각을 과거로 | 생성 시각·타이머 시작 시각 필드를 과거로 수정 | 가능하지만 파생 필드가 따라오지 않아 가짜 통과 가 나기 쉽다 |
| 인스턴스 시계를 옮긴다 | 시스템 시각 조작 | PDI에서 권하지 않는다. 다른 스케줄 작업이 전부 흔들린다 |
기간을 줄이는 방법을 쓸 때는 기록지에 "2분으로 축소해 시험함 — 30분 값 자체는 미검증" 이라고 반드시 남긴다. 모듈 39 레슨 2의 "흉내로 검증한 범위를 기록한다"와 같은 규율이다. 공휴일 달력은 줄일 수 없으므로, 달력에 내일을 공휴일로 추가하고 오늘 18시 이후 접수 티켓의 목표 시각이 어떻게 계산되는지 본다.
단계 6 — ATF 테스트 하나를 만들어 돌린다 (25분)
레슨 6에서 ATF의 스텝 → 테스트 → 스위트 구조를 봤다. 여기서는 테스트 한 개를 실제로 만든다.
0. 먼저 실행기를 켠다
sys_properties.list 에서 sn_atf.runner.enabled 를 true 로 바꾼다
기본값이 꺼짐인 이유: 운영 인스턴스에서 테스트가 돌면 데이터가 오염된다
→ PDI 이므로 켜도 되지만, "운영 인스턴스에서는 켜지 않는다" 를 기록지에 적는다테스트 내용은 단계 2의 관찰 4를 자동화한 것으로 한다.
[테스트] INC-해결코드-필수
스텝 1 Impersonate 역할이 있는 시험 사용자로 전환
스텝 2 Open a New Form 테이블 incident
스텝 3 Set Field Values 단축 설명·영향·긴급도 입력
스텝 4 Submit Form 저장 — 성공 기대
스텝 5 Open an Existing Record 방금 만든 인시던트
스텝 6 Set Field Values 상태 = 해결됨 (해결 코드는 비워 둔다)
스텝 7 Submit Form **실패(오류 메시지) 기대**
스텝 8 Record Validation 해당 인시던트의 상태가 여전히 "해결됨"이 아님스텝 7이 핵심이다. ATF 스텝은 대개 성공을 기대하도록 기본 설정되어 있고, "실패해야 통과"인 시험은 스텝 옵션에서 기대 결과를 뒤집어야 한다. 이 설정을 빠뜨리면 금지 전이 시험이 전부 반대로 판정 된다. 실습에서 한 번 겪어 두면 평생 잊지 않는다.
테스트를 실행하고 결과 화면에서 확인할 것.
- 각 스텝의 통과/실패와 스크린샷
- 실패 스텝의 오류 메시지 전문
- 테스트가 만든 레코드가 실행 후 롤백되는가 ← 관찰 9관찰 9가 ATF의 중요한 성질이다. ATF는 테스트가 만든 데이터를 실행 후 되돌리도록 설계되어 있다. 되돌아가지 않는 데이터가 있다면 그 스텝은 시험 환경을 오염시키는 스텝 이고, 회귀 스위트에 넣기 전에 정리 방법을 정해야 한다. 모듈 39 레슨 1의 테스트 전후 스냅샷 비교 와 같은 발상이다.
단계 7 — 같은 흐름을 Jira Service Management로 (20분)
무료 플랜으로 사이트를 만들고 서비스 관리 프로젝트 를 하나 생성한다. 그리고 단계 2~4를 최대한 반복한다.
1. 요청 유형(request type)을 살펴본다 — 인시던트 신고 / 서비스 요청 / 변경 요청이 있는가
2. 워크플로 편집 화면에서 상태와 전이를 본다
→ "해결됨 → 신규" 전이가 열려 있는가? ← 관찰 10
3. 큐(queue)를 만들어 P2 이상만 모아 본다 — JQL 조건을 직접 쓴다
4. 자동화 규칙을 하나 만든다 (예: 우선순위 P1이면 특정 그룹에 알림)
5. SLA 설정 화면을 찾아본다 — 현재 플랜에서 되는가? ← 관찰 11
6. 변경 관리 기능을 찾아본다 — 승인·위험 평가 필드가 있는가? ← 관찰 12관찰 11·12에서 "이 플랜에서는 안 된다"가 나오면 그것이 결론이다. 레슨 6의 도구 비교표에 직접 확인한 근거 한 줄이 붙는 순간이다. 비교표를 이렇게 채운다.
| 항목 | ServiceNow PDI에서 확인한 것 | JSM 무료 플랜에서 확인한 것 |
|---|---|---|
| 상태 전이 통제 | (직접 적는다) | |
| 필수 필드 강제 | ||
| SLA 정의·일시 정지 | ||
| 변경 승인·위험 평가 | ||
| 자동 시험 | ||
| 설정을 바꾸는 난이도 |
실습 기록지 양식
기록지는 도구 밖의 표 하나면 충분하다. 열은 여섯 개다.
| 단계 | 한 일 | 기대 (시나리오) | 실제 | 판정 | 조치 후보·영향 |"판정"은 일치 / 불일치(설정 공백) / 불일치(제품 결함 후보) / 미검증(흉내) 네 값만 쓴다. 미검증 줄이 몇 개인지가 이 실습의 정직성을 보여준다. SLA 30분을 2분으로 줄여 시험한 줄, 공휴일 달력을 한 날짜만 넣어 본 줄이 여기 들어간다.
실무에서 왜 필요한가
ITSM 도구 구축·운영 직무의 서류에서 "ServiceNow 경험"은 매우 흔하게 적히지만, 면접에서 테이블 이름과 설정 화면을 말할 수 있는 지원자 는 훨씬 적다. PDI 실습 하나로 이 격차를 메울 수 있다. 특히 자기 승인 시험, 해결 코드 필수 시험, SLA 타이머 레코드 확인처럼 기본값이 막지 않는 지점 을 직접 찾아본 경험은 구축 프로젝트의 인수 기준을 쓰는 능력으로 바로 이어진다.
두 도구를 같은 시나리오로 겪어 보는 것도 효과가 크다. 도구 비교 글은 많지만 대부분 기능 목록의 나열이고, "우리 정책을 이 도구에 넣으려면 무엇을 따로 만들어야 하는가"를 말해 주지 않는다. 같은 시나리오를 두 번 올려 보면 그 답이 표로 남는다. 조직이 도구를 고를 때 이 표가 비교 자료보다 강하다.
마지막으로, ATF 테스트를 한 번이라도 만들어 보면 레슨 6의 업그레이드 회귀 스위트 설계가 추상적인 계획에서 견적 가능한 작업 으로 바뀐다. 스텝 하나를 만드는 데 몇 분이 걸리는지 알면 "스위트 다섯 개"가 며칠인지 말할 수 있다.
채용시장에서의 위치
운영 조직의 ITSM 도구 담당자 채용은 대개 두 갈래다. 플랫폼 설정을 만드는 구현·관리자 역할과, 그 설정이 정책대로 동작하는지 보는 운영 품질 역할이다. QA 경력자가 들어갈 자리는 두 번째이고, 여기서 요구되는 증거는 자격증이 아니라 설정을 시험한 기록 이다. PDI는 비용 없이 그 기록을 만들 수 있는 거의 유일한 환경이므로, 포트폴리오에 실습 기록지와 ATF 테스트 실행 결과를 넣는 것만으로 서류의 성격이 달라진다. 다만 PDI 실습을 "ServiceNow 구축 경험"으로 부풀려 적으면 면접에서 바로 드러나므로, "개인 개발자 인스턴스에서 설정 시험을 설계·실행" 이라고 정확히 쓴다.