ServiceNow Update Set vs Application — 변경 이관의 두 모델

개요

ServiceNow에서 개발한 변경을 다른 인스턴스로 옮기는 방법은 크게 두 가지다. Update Set은 변경 내역을 묶어 XML로 내보내는 전통적인 방식이고, Scoped Application(스코프드 애플리케이션)은 격리된 네임스페이스 안에서 코드와 데이터를 관리하는 모듈 단위 방식이다. 둘 다 “변경을 옮긴다”는 목적은 같지만, 적합한 상황이 뚜렷하게 갈린다. 이 글은 ITSM·Flow Designer 시리즈와 별개로, 플랫폼 기초 자산을 다루는 standalone 글이다 — 두 모델이 어떻게 다르고, 어떤 상황에 무엇을 골라야 하는지를 결정 트리와 함께 정리한다.

OOTB(Out-of-the-Box, 기본 제공) 기준 설명입니다. 인스턴스 버전·플러그인 구성에 따라 동작 및 메뉴 경로가 달라질 수 있습니다.

1. 한 표로 보는 차이

	Update Set	Scoped Application
스코프	전역(Global) 또는 특정 스코프 내 변경 묶음	`x_<vendor>_<app>` 접두어로 격리된 독립 네임스페이스
이관 방식	XML 파일 내보내기 → 대상 인스턴스에서 가져오기(Preview → Commit)	Application 단위로 Source Control 연동 또는 App Store 배포
의존성 처리	자동 추적 한계 있음 — 참조 레코드가 누락되기 쉬움	Application 경계 안에서 의존성 격리, 명시적으로 관리
협업 모델	XML 파일을 팀원 간 전달하거나 인스턴스에서 직접 공유	Git 저장소 기반 브랜치·PR 워크플로우 적용 가능
Source Control 친화도	제한적 — OOTB 기준 직접 연동 없음	Studio에서 Git 연동 지원, 버전 이력 관리 가능
진입 비용	낮음 — 즉시 시작, 별도 설계 불필요	높음 — Application 생성·네임스페이스 설계가 선행되어야 함

2. Update Set — 진입 비용이 낮은 전통 방식

Update Set은 인스턴스에서 이루어진 변경을 sys_update_xml 테이블에 기록하고, 그 묶음을 XML로 내보내는 방식이다. OOTB 기준으로 메뉴에서 현재 Update Set을 지정한 뒤 작업하면, 이후 변경 사항이 해당 Set에 자동으로 쌓인다. 완료된 Set은 XML 파일로 내보내고, 대상 인스턴스에서 가져오기(Import) 후 Preview 단계를 거쳐 Commit하는 흐름이 일반적이다.

강점은 진입 장벽이 거의 없다는 점이다. Application 구조를 설계하지 않아도 즉시 변경을 추적할 수 있어, 소규모 수정이나 긴급 패치에 특히 빠르게 쓸 수 있다. 팀에 ServiceNow 입문자가 많거나 변경 규모가 작을 때 가장 현실적인 선택이 되는 이유이기도 하다.

약점은 의존성 자동 추적의 한계다. Reference 필드가 가리키는 다른 레코드(예: 카탈로그 아이템이 참조하는 변수 셋)가 Update Set에 자동으로 함께 포함되지 않는 경우가 있다. Import 후 참조가 끊어진 채로 동작하는 상황이 흔히 발생하며, Preview 단계에서 Missing References 경고를 꼼꼼히 확인하는 습관이 중요하다. 또한 여러 사람이 동일 인스턴스에서 작업하면 같은 레코드를 서로 다른 Update Set에 담아 충돌(sys_id 중복, 변경 덮어쓰기)이 생기기 쉽다. 이 때문에 Update Set은 소규모·단기 변경에는 강하지만, 팀 규모가 커질수록 관리 부담이 비례해 늘어난다.

3. Scoped Application — 격리와 Source Control을 함께

Scoped Application은 x_<vendor>_<app> 형식의 접두어로 모든 산출물을 격리한다. 같은 이름의 테이블·스크립트·Business Rule(비즈니스 룰)이 전역 스코프와 충돌하지 않는다. sys_app 테이블에 Application 레코드가 생성되고, 그 아래에 속하는 산출물이 모두 해당 스코프 안에서 관리된다. 이 격리 덕분에 Source Control(Git) 연동이 자연스럽고, ServiceNow App Store를 통해 외부에 배포하는 것도 일반적으로 가능하다.

언제 Scoped Application을 꺼낼까? 일반적으로 세 가지 상황이 신호가 된다.

여러 고객사나 팀에 동일 기능을 재배포해야 할 때
기존 전역 자산과 명확히 격리해야 할 때 (네임스페이스 오염 방지)
Git 기반 협업·코드 리뷰 워크플로우를 적용하고 싶을 때

반면 진입 비용은 높다. Application을 생성하고 네임스페이스를 설계하는 작업이 선행되어야 하며, 기존 전역 자산을 Scoped Application으로 이전하는 마이그레이션은 상당한 공수가 든다. 또한 Scoped Application 내부에서 전역 스코프의 테이블이나 스크립트를 직접 호출할 때 제약이 생기는 경우가 있다 — cross-scope access 정책이 명시적 권한 없이는 read/write를 차단하기 때문이다. 설계 단계에서 의존 범위를 명확히 파악해두는 것이 중요하다. “일단 만들고 나중에 격리”는 가장 피해야 할 패턴이다.

4. 결정 트리

어떤 모델을 선택할지 아래 흐름으로 판단한다.

흐름을 간략히 읽으면 이렇다. “재사용·배포할 단위인가?”에서 No라면 Update Set로 충분하다. Yes라면 격리 필요 여부를 확인하고, 격리가 필요하면 Scoped Application이다. 격리가 필요 없더라도 외부(App Store·고객사)에 배포해야 한다면 Scoped Application을 써야 한다. 두 조건 모두 해당하지 않으면 Update Set로 진행한다.

5. 흔한 함정

함정 1

Update Set 의존성 누락

Reference 필드가 가리키는 다른 레코드가 Update Set에 자동으로 포함되지 않는 경우가 있다. Import 후 참조가 끊어진 채로 동작해 원인을 파악하기 어렵다. 이관 전 수동으로 의존 레코드를 Set에 추가하거나, Preview 단계에서 Missing References 항목을 꼼꼼히 확인해야 한다.

함정 2

sys_id 충돌

동일한 sys_id를 가진 레코드를 두 개의 다른 인스턴스에서 독립적으로 수정하면, 어느 한쪽을 Import할 때 덮어쓰기 충돌이 발생한다. 개발·스테이징·운영 인스턴스 간 변경 흐름을 단방향으로 유지하는 것이 일반적인 권장 방식이다.

함정 3

두 모델 혼용

Scoped Application 안에서 Update Set을 또 만드는 패턴은 관리 복잡도를 높인다. Scoped Application은 Source Control(Git) 연동을 통해 이관하는 것이 의도된 방식이다. 두 모델을 혼용하면 어떤 변경이 어느 경로로 이관됐는지 추적이 어려워진다.

함정 4

Source Control 진입 타이밍

Scoped Application을 오랫동안 운영한 뒤 뒤늦게 Git 연동을 시도하면, 이전 변경 이력이 누락되고 마이그레이션 공수가 크게 늘어난다. Application 생성 초기부터 Source Control을 연동하는 것이 훨씬 비용이 적다.

마무리

Update Set과 Scoped Application은 ServiceNow 개발 기초 자산이다. 둘 중 하나가 항상 우월한 게 아니라, 규모·팀 구성·배포 목적에 따라 적합한 모델이 달라진다. 소규모 긴급 패치라면 Update Set이 빠르고, 장기적으로 유지보수하거나 외부에 배포할 모듈이라면 Scoped Application이 더 안정적인 선택이다. Scoped Application 을 선택했다면 다음 단계는 권한 경계 이해다 — Scoped Application vs Global 권한 경계 글에서 Cross-Scope Privilege · Public Script Include · Wildcard ACL 제약을 정리한다.