맨위로가기

단일 진실 공급원

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

단일 진실 공급원(SSOT)은 조직 내에서 데이터의 일관성을 유지하기 위한 개념으로, 특정 정보에 대해 단 하나의 신뢰할 수 있는 출처를 두는 것을 의미한다. 여러 정보 시스템이 존재하는 환경에서 SSOT 구현은 어려움에 직면하며, 전사적 서비스 버스(ESB), 마스터 데이터 관리(MDM), 데이터 웨어하우스(DW) 등의 아키텍처를 활용하여 구현할 수 있다. MDM은 여러 시스템의 허브 역할을 하며, 이벤트 스토어(ES)는 시스템 상태 변경을 저장하는 데 사용된다. 데이터 웨어하우스는 보고 및 분석을 위해 데이터를 통합하지만, 다른 시스템을 업데이트하는 데 사용되지 않기도 한다. SSOT는 소프트웨어 개발의 소스 코드 관리 및 분산 SaaS 데이터(DSD) 시스템에서도 적용될 수 있다.

더 읽어볼만한 페이지

  • 데이터베이스 정규화 - 제3정규형
    제3 정규형은 관계형 데이터베이스 설계 시 데이터 중복을 줄이고 무결성을 유지하기 위한 정규화 단계로, 제2 정규형을 만족하며 기본 키가 아닌 속성에 대한 전이적 종속성을 제거하는 것을 목표로 한다.
  • 데이터베이스 정규화 - 제2정규형
    제2 정규형은 데이터베이스 정규화 단계로서, 테이블 속성들이 기본키에 완전 종속되도록 하여 데이터 중복과 갱신 이상을 줄이고 데이터 일관성을 유지하는 것을 목표로 합니다.
  • 데이터 모델링 - 빌딩 정보 모델링
    빌딩 정보 모델링(BIM)은 건축물의 전 생애주기 동안 발생하는 정보를 디지털 모델로 통합 관리하는 프로세스이다.
  • 데이터 모델링 - 저장 프로시저
    저장 프로시저는 데이터베이스 관리 시스템에서 SQL 문들을 미리 컴파일하여 저장하고, 모듈화, 보안성, 성능 향상, 유지보수 용이성과 같은 특징을 가지며, 데이터베이스 시스템마다 구현 방식과 지원하는 언어가 다를 수 있는 코드 묶음이다.
  • 데이터 관리 - 데이터 센터
    데이터센터는 컴퓨터 시스템 및 관련 장비와 지원 인프라를 수용하는 시설로, 기술 발전에 따라 규모와 중요성이 확대되었으며, 에너지 효율과 보안을 고려하여 설계 및 운영되고, TIA-942 표준에 따른 티어 분류와 친환경 기술 도입이 이루어지고 있다.
  • 데이터 관리 - 정보 아키텍처
    정보 아키텍처는 정보 시스템 및 정보 기술 분야에서 공유 정보 환경의 구조적 설계를 의미하며, 웹사이트, 소프트웨어 등의 구성과 레이블링을 포함하여 검색 용이성과 사용성을 지원하고, 도서관정보학에 기원을 두고 있다.
단일 진실 공급원
개요
유형정보 관리 개념
목표조직 내 모든 데이터 요소에 대한 단일 참조 지점 제공
관련 용어데이터 거버넌스
데이터 품질
마스터 데이터 관리
상세 내용
중요성의사 결정 개선
효율성 향상
위험 감소
도전 과제구현 복잡성
지속적인 유지 관리 필요
조직 문화 변화 요구
이점
정보 일관성조직 전체에서 데이터 불일치 감소
의사 결정 개선정확하고 신뢰할 수 있는 데이터를 기반으로 의사 결정 가능
효율성 향상데이터 검색 및 분석 시간 단축
위험 감소오류 및 규정 위반 가능성 감소
구현
단계데이터 감사 및 정리
마스터 데이터 관리 시스템 구축
데이터 거버넌스 정책 수립
사용자 교육 및 지원
사례
금융 서비스고객 정보 관리, 사기 탐지
헬스케어환자 기록 관리, 임상 연구
제조제품 정보 관리, 공급망 관리

2. 구현

단일 진실 공급원(SSOT)의 이상적인 구현은 현실적으로 많은 기업에서 여러 어려움에 직면한다. 이는 다수의 정보 시스템을 운영하는 과정에서 각 시스템이 동일한 개체(예: 고객 정보)와 관련된 데이터에 접근해야 할 필요성이 빈번하게 발생하기 때문이다.

특히 많은 시스템이 공급업체로부터 상용 기성품 형태로 구매되어 세부적인 수정이 어려운 경우가 많다. 이로 인해 각 시스템은 공통 데이터나 개체의 자체적인 복사본을 저장하고 유지하게 되는데, 이는 각 시스템이 데이터의 복사본을 가지는 결과를 낳아 SSOT 원칙에 직접적으로 위배된다. 예를 들어, 전사적 자원 관리(ERP) 시스템(예: SAP, Oracle e-Business Suite)은 고객 정보를 저장할 수 있으며, 고객 관계 관리(CRM) 시스템 역시 고객 정보의 일부 또는 전체 복사본을 필요로 한다. 마찬가지로 창고 발송 시스템도 배송 주소와 같은 고객 데이터의 복사본을 가질 수 있다. 시스템 공급업체가 이러한 데이터 구조의 변경을 지원하지 않는다면, 각 시스템의 데이터 복사본을 SSOT를 가리키는 참조(포인터)로 대체하는 것은 현실적으로 불가능할 수 있다.

이러한 현실적인 제약 속에서 여러 정보 시스템을 사용하는 조직이 SSOT를 구현하기 위해 고려할 수 있는 다양한 아키텍처적 접근 방식들이 존재한다.

2. 1. 존재론적 상호작용

단일 진실 공급원(SSOT) 개념이 성립하기 위한 필수 조건은 특정 사실이나 아이디어에 대해 단 하나의 진실만이 존재한다는 존재론적 조건에 달려 있다. 이는 IT 분야뿐만 아니라 일반적인 의미에서도 마찬가지로 적용되는 주장이다.[1] 많은 경우, 특정 네임스페이스 내에서나, 이름 충돌 또는 더 넓은 범위의 이름 충돌 문제가 적절히 처리된다면 네임스페이스 간에서도 이는 큰 문제가 되지 않는다.[1]

그러나 가장 넓은 범위의 맥락에서는 존재론적 불일치가 발생하기 쉬우며, 따라서 관련된 인식 체계들을 비교하고 조정하는 과정이 필수적이다. 또는 최소한 협상이나 거래 교환이라도 필요하다.[1] 이러한 조정의 대표적인 예로, 서로 다른 두 종교(X와 Y)의 신학 대학 도서관이 SSOT 구조를 통해 정보를 교환하는 경우를 들 수 있다. 이때 진실의 통일은 "종교 X는 신이 보라색이라고 주장한다" 그리고 "종교 Y는 신이 녹색이라고 주장한다"와 같이 각자의 주장을 명시하는 수준에서 이루어져야 한다. "신은 보라색이다" 또는 "신은 녹색이다"처럼 어느 한쪽의 주장을 절대적인 진실로 규정해서는 안 된다.[1]

2. 2. 아키텍처 또는 아키텍처적 특징

단일 진실 공급원(SSOT)의 이상적인 구현은 현실적으로 많은 기업에서 구현하기 어려운 과제이다. 여러 정보 시스템이 동일한 개체(예: 고객) 데이터를 각기 다른 방식으로 접근하고 저장해야 하는 경우가 많기 때문이다. 특히 상용 기성품 소프트웨어는 수정이 어려워 각 시스템이 데이터의 자체 복사본을 유지하게 되면서 SSOT 원칙과 멀어지게 된다. 예를 들어, 전사적 자원 관리(ERP) 시스템(예: SAP, Oracle e-Business Suite), 고객 관계 관리(CRM) 시스템, 창고 관리 시스템 등은 각각 동일한 고객 정보를 부분적으로 또는 전체적으로 복제하여 저장할 수 있다.

이러한 상황에서 여러 정보 시스템을 운영하는 조직이 SSOT를 구현하기 위해 고려할 수 있는 주요 아키텍처 패턴은 다음과 같다.

이 중 전사적 서비스 버스(ESB)는 특정 시스템에서 데이터가 변경되었을 때, 관련된 다른 시스템들이 해당 업데이트를 수신할 수 있도록 지원하는 방식이다. 어떤 개체(entity)에 대해 골든 레코드(golden record), 즉 가장 정확하고 신뢰할 수 있는 데이터 원본을 지정하고, 이 데이터에 변경(생성, 수정, 삭제)이 발생하면 ESB를 통해 이를 구독하는 다른 시스템들에게 전파하여 각 시스템이 자체 데이터를 최신 상태로 유지하도록 한다.

각 아키텍처는 SSOT를 구현하는 서로 다른 접근 방식을 제공하며, 조직의 특성과 요구사항에 따라 적합한 방식을 선택하거나 조합하여 사용될 수 있다. 예를 들어, 마스터 데이터 관리(MDM)는 특정 데이터 유형에 대한 중앙 집중식 마스터를 구축하는 데 중점을 두며[8], 데이터 웨어하우스(DW)는 분석 및 보고를 위한 통합된 데이터 뷰를 제공하는 데 목적을 둔다. 이벤트 스토어는 시스템의 모든 상태 변경 이력을 기록하여 데이터의 일관성을 확보하는 방식이다.

한편, 시스템 간 데이터를 직접 주고받는 포인트 투 포인트(point-to-point) 방식도 가능하지만, 시스템 수가 증가함에 따라 연결 및 관리 복잡성이 기하급수적으로 증가하여 확장성이 떨어지므로 일반적인 IT 아키텍처로는 권장되지 않는다.

2. 2. 1. 마스터 데이터 관리 (MDM)

마스터 데이터 관리 (MDM) 시스템은 다른 시스템에 "단일 진실 공급원"이 없을 수 있는 특정 개체에 대한 진실 공급원의 역할을 수행할 수 있다. 일반적으로 MDM은 여러 시스템의 허브 역할을 하며, 이 시스템들 중 다수는 특정 개체에 대한 정보의 다양한 측면을 업데이트하는 것을 허용할 수 있다(즉, 해당 측면에 대한 진실 공급원 역할을 할 수 있다).

예를 들어, 고객 관계 관리 (CRM) 시스템은 콜센터 운영자가 업데이트하는 고객 정보의 대부분 측면에 대해 "단일 진실 공급원"이 될 수 있다. 그러나 고객은 CRM 시스템과는 다른 백엔드 데이터베이스를 사용하는 고객 서비스 웹사이트를 통해 자신의 주소를 직접 업데이트할 수도 있다. 이러한 경우, MDM 애플리케이션은 여러 소스로부터 업데이트를 수신하고, 어떤 업데이트를 신뢰할 수 있는 골든 레코드(golden record)로 간주할지 결정하는 중개자 역할을 수행한다. 그 후, 이 업데이트된 데이터를 구독하는 모든 시스템에 배포한다.

데이터를 여러 구독 시스템에 효율적으로 배포하기 위해 MDM 애플리케이션은 일반적으로 전사적 서비스 버스 (ESB)와 같은 기술을 필요로 한다.[8]

2. 2. 2. 이벤트 스토어 및 이벤트 소싱 (ES)

이벤트 지향 아키텍처에서는 시스템 상태를 상태 변경의 정렬된 순서로 저장하는 [https://martinfowler.com/eaaDev/EventSourcing.html 이벤트 소싱] 패턴을 구현하는 경우가 점점 더 많아지고 있다.[3] 이 패턴을 사용하려면 이벤트 스토어가 필요한데, 이는 시스템 상태를 변경하는 모든 이벤트를 보관하도록 설계된 특별한 종류의 데이터베이스이다.

이벤트 소싱, 명령 쿼리 책임 분리(CQRS), 도메인 주도 설계(DDD), 메시징 패턴을 결합한 아키텍처에서 이벤트 스토어는 사실상 단일 진실 공급원(SSOT) 역할을 한다. 모든 상태 변경 이벤트가 이벤트 스토어를 거치기 때문에, 이를 직접 구독하여 변경 사항을 알 수 있어 엔터프라이즈 서비스 버스(ESB)와 유사한 역할도 수행할 수 있다는 추가적인 장점이 있다. 또한, 모든 이벤트를 저장하므로 데이터 웨어하우스의 기능도 겸한다. 마지막으로, 이벤트 스토어 시스템을 통해 [https://microservices.io/patterns/data/shared-database.html 공유 데이터베이스 패턴]을 구현하여 단일 진실 공급원을 확보할 수도 있다.

데이터 웨어하우스는 여러 출처의 데이터를 결합하여 보고 및 분석을 지원하는 것이 주 목적이다. 데이터 웨어하우스의 데이터는 다양한 소스에서 통합된 결과물이므로, 종종 사실상 단일 진실 공급원(SSOT)으로 간주되기도 한다. 하지만 일반적으로 데이터 웨어하우스의 데이터는 다른 운영 시스템을 업데이트하는 데 사용되지 않는다. 대신, 여러 이해관계자에게 보고하기 위한 "단일 진실 공급원"으로 기능한다. 데이터는 데이터 웨어하우스 자체에서 생성되는 것이 아니라 운영 시스템에서 가져오므로, 운영 데이터 소스에는 다른 버전의 진실이 존재할 수 있다. 따라서 이런 맥락에서 데이터 웨어하우스는 단일 진실 버전(Single Version of the Truth)이라고 부르는 것이 더 정확하다.[4]

2. 2. 3. 데이터 웨어하우스 (DW)

데이터 웨어하우스(DW)는 여러 정보 시스템을 사용하는 조직에서 신뢰할 수 있는 단일 정보 소스를 구현하기 위한 접근 방식 중 하나이다. 데이터 웨어하우스의 주요 목적은 여러 소스에서 가져온 데이터를 결합하여 보고 및 분석을 지원하는 것이다. 데이터 웨어하우스는 데이터 변환 및 통합 프로세스를 통해 데이터를 결합하므로, ''사실상'' 단일 진실 공급원(Single Source of Truth, SSOT)으로 사용되는 경우가 많다.

그러나 일반적으로 데이터 웨어하우스에서 얻은 데이터는 다른 운영 시스템을 업데이트하는 데 사용되지 않는다. 대신, 데이터 웨어하우스는 여러 이해관계자에게 보고하기 위한 "신뢰할 수 있는 유일한 정보원" 역할을 한다. 이는 데이터 웨어하우스가 다른 데이터 소스에 존재하는 다양한 버전의 정보를 통합하여 보여주기 때문에, "단일 버전의 진실"이라고 표현하는 것이 더 정확할 수 있다. 데이터 웨어하우스 자체가 데이터의 원천(origin)이 아니라, 다른 시스템에서 가져온 데이터를 정리하고 보고하는 역할을 수행하기 때문이다.

2. 3. 소스 코드

소프트웨어 설계에서는 동일한 스키마, 비즈니스 로직 및 기타 요소들이 여러 다른 종류의 소스 코드에서 반복되는 경우가 많으며, 각 버전은 스스로를 "소스 코드"라고 지칭한다. 이러한 문제를 해결하기 위해, 단일 진실 공급원(SSOT)의 개념을 소프트웨어 개발 원칙에도 적용할 수 있다. 예를 들어, 재귀적 트랜스파일과 같은 과정을 사용하여 단일 진실 공급원을 여러 종류의 소스 코드로 반복적으로 변환하는 것이다. 이렇게 함으로써 모든 종류의 소스 코드가 동일한 SSOT에서 파생되어 구조적으로 서로 일치하게 된다.[5]

2. 4. 분산 SaaS 데이터 (DSD)

기업 간 거래 소프트웨어 데이터 생태계와 같이, 데이터를 중앙에서 저장하고 참조 위치에서 관리하는 것이 현실적으로 어려울 때가 있다. 이러한 경우 기업들은 분산 SaaS 데이터(DSD) 시스템을 사용한다. DSD 시스템은 마치 항공 교통 관제와 유사한 역할을 수행한다. 즉, 데이터가 저장된 각각의 위치에 업데이트된 내용을 전송하고 데이터의 정확성을 강제함으로써, 중앙에서 데이터를 관리하고 제어하는 기능을 제공한다.

3. 참조


  • DRY 원칙
  • SOLID (객체 지향 설계)
  • 관계 정규화
  • 단일 진실 버전 (Single version of the truth)
  • SoR
  • UNIX 철학
  • KISS 원칙 (KISS)
  • 순환 보고
  • 블록체인

참조

[1] 웹사이트 IBM Smarter Planet - Operational risk management for financial services http://www.ibm.com/s[...]
[2] 웹사이트 BAYT Job Site - June 2014 http://www.bayt.com/[...]
[3] 웹사이트 Event Sourcing https://martinfowler[...] 2021-12-06
[4] 웹사이트 What Is a Data Warehouse? https://www.oracle.c[...] 2023-08-10
[5] 논문 Why Google stores billions of lines of code in a single repository https://dl.acm.org/d[...]
[6] 웹사이트 IBM Smarter Planet - Operational risk management for financial services http://www.ibm.com/s[...]
[7] 문서 Single Source of Truth (SSOT) for Service Oriented Architecture (SOA)
[8] 문서 BAYT Job Site - June 2014
[9] 문서 Why Google stores billions of lines of code in a single repository
[10] 문서 Syncari Site


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com