시스템 설계를 위한 Thing 모델링: 사물·요소의 경계와 운영 체계

시스템 경계를 관리 가능한 단위로 만드는 방법

물리 세계와 디지털 세계를 함께 다루는 시스템에서는 디바이스, 소프트웨어 객체, 데이터 자산, 서비스 프로세스, 정책을 서로 다른 방식으로 관리하기 쉽다. 이 대상을 Thing(사물, 요소)이라는 공통 단위로 모델링하면 아키텍처의 일관성, 관측성, 거버넌스를 같은 기준으로 다룰 수 있다.

Thing은 경계가 분명하고 식별할 수 있는 개체다. 고유 ID와 상태, 행위를 가지며 외부와 상호작용하기 위한 인터페이스를 제공한다. 생성·변경·폐기로 이어지는 수명주기도 함께 가진다. 따라서 물리적 대상뿐 아니라 디지털 객체와 개념·정책에도 적용할 수 있는 추상화가 된다.

대상을 나눌 때는 세 축이 유용하다. 실재성 기준에서는 물리 사물인 디바이스, 데이터·객체 같은 디지털 사물, 개념·정책을 구분한다. 활동성 기준에서는 데이터·자산처럼 수동적인 대상과 서비스·에이전트처럼 능동적으로 동작하는 대상을 가른다. 수명주기 기준에서는 자산·정책처럼 영속적인 대상과 이벤트·임시 리소스처럼 단명하는 대상을 구별한다.

Thing은 이벤트와 데이터를 생산하거나 API를 소비하는 역할을 맡을 수 있다. 상위 Thing이 하위 Thing을 집합 또는 합성해 복합 기능을 제공하는 구조도 가능하다. 동시에 접근 통제, 규정 준수, 관측성을 적용하는 최소 거버넌스 단위가 된다.

식별자부터 관계까지 설계에 포함할 항목

Thing의 식별과 메타데이터는 운영의 출발점이다. 글로벌 고유 ID, 네임스페이스, 버전을 부여하고 스키마·태그·소유권·민감도 메타데이터를 표준화해야 한다.

상태 전이는 암묵적으로 두지 않는다. 초안→활성→사용중→폐기처럼 상태를 정의하고, TTL·보존정책·아카이빙·삭제 절차와 예외 처리까지 설계 범위에 포함한다.

행위를 제공하는 방식도 구분할 필요가 있다. 동기 API와 비동기 이벤트, 명령·쿼리 인터페이스를 분리하고 SLA, 재시도, 멱등성, 역치 기반 제어 같은 운영 규칙을 정한다.

소유·의존·집합·참조 관계는 그래프로 표현하고 무결성 제약을 둔다. 온톨로지나 용어사전과 연계하면 도메인 전반의 의미를 일관되게 유지할 수 있다. 로그·지표·트레이스 3종 텔레메트리를 기본으로 수집하며, ABAC/RBAC 접근제어, 정책 평가, 변경 이력(Audit)을 Thing 관리에 내장한다.

서로 다른 시스템에서 Thing을 쓰는 방식

도메인 모델에서는 엔터티, 값 객체, 애그리게이트를 Thing 프레임으로 표준화할 수 있다. 경계 컨텍스트 사이의 Thing 계약 스키마를 관리하면 변경이 미치는 범위를 줄일 수 있다.

IoT와 디지털 트윈에서는 디바이스 레지스트리, Shadow/Twin 상태 동기화, 텔레메트리 파이프라인이 Thing 관리 대상이 된다. 펌웨어와 구성을 Thing으로 다루면 롤아웃과 롤백 절차를 안전하게 구성할 수 있다.

데이터 카탈로그와 지식 그래프에서는 데이터셋, 컬럼, 파이프라인, 품질 규칙을 Thing으로 등록한다. 계보(Lineage)와 품질 점수를 연결해 신뢰도를 기준으로 데이터를 소비하도록 지원한다.

API에서는 REST 리소스와 GraphQL 타입을 Thing으로 정의해 버전과 수명주기를 일관되게 맞춘다. ETag와 조건부 요청은 낙관적 잠금에 활용할 수 있으며 경쟁 상태를 막는 데 쓰인다.

CMDB에서는 서버, 서비스, 구성 항목을 Thing으로 인벤토리화한다. IaC와 연결하면 실사 상태와 정의의 드리프트를 탐지하고 자동 수정할 수 있다.

등록과 변경이 운영으로 이어지는 흐름

Thing 사양은 레지스트리에 등록되기 전에 스키마와 정책 검증을 거친다. 검증이 통과하면 트랜잭션으로 메타데이터를 저장하고 생성 이벤트를 발행하며, 디지털 트윈은 이를 받아 초기 상태를 만든다. 이후 변경 요청은 ETag를 활용해 버전 충돌을 확인한다.

⤢✕

입력은 Thing 사양, 스키마, 정책이다. 처리 단계에는 검증, 트랜잭션 저장, 이벤트 발행, 트윈 초기화가 포함된다. 생성 응답과 버전 ETag, 업데이트 이벤트가 결과로 남는다. 스키마 또는 정책 위반에는 400, 버전 충돌에는 409를 반환하고 트랜잭션 롤백을 처리한다.

유형에 따라 달라지는 운영 제약

구분	성능	확장성	일관성	안정성	운영 편의
물리 사물(디바이스)	실시간 제약 높음, 네트워크 변동성 큼	대량 디바이스 수평 확장 필요	최종 일관성 수용 빈도 높음	현장 장애 영향도 큼	원격 관리·OTA 자동화 중요
디지털 사물(데이터/객체)	저장·조회 지연 최적화 가능	파티셔닝·캐시로 고확장	강·약 일관성 선택 설계	스토리지 내 장애 도메인 관리	스키마·버전 자동 검증 편의
서비스/프로세스	지연·처리량 SLO 중심	무상태 확장 용이	분산 트랜잭션 최소화 권장	서킷브레이커·재시도 내장	배포·롤백 자동화 중요
개념/정책	성능 요구 낮음	정책 카탈로그 수평 확장	정책 평가의 결정적 일관성 요구	변경 영향 관리가 핵심	정책 수명주기·감사 용이

모델의 통일이 바꾸는 운영 방식

도메인 간 계약을 명확히 하면 재작업률이 20~30% 감소할 것으로 기대할 수 있다. 스키마와 버전을 관리하면 변경 리드타임도 줄일 수 있다.

관측성을 표준화하면 MTTR을 30% 이상 단축할 수 있으며, 멱등성과 락 전략은 장애 전파를 최소화하는 기반이 된다. 공통 Thing 컴포넌트의 재사용은 신규 기능 출시 속도를 높이고, 이벤트 표준화는 파이프라인 증설 비용 절감으로 이어진다.

민감도와 소유권 메타데이터를 기반으로 접근제어의 정확도를 높일 수 있다. 변경 이력과 감사 추적성을 확보하면 컴플라이언스 대응도 수월해진다.