Kwangmin Kim - 데이터 라이프사이클 설계

1 라이프사이클을 잘못 이해하면 거버넌스가 망가진다

데이터 라이프사이클을 설명할 때 가장 흔히 쓰이는 그림은 왼쪽에서 오른쪽으로 흐르는 파이프라인이다. 생성 -> 수집 -> 저장 -> 처리 -> 분석 -> 폐기. 직관적이고 단순하다. 그런데 이 그림이 실제 데이터 거버넌스 설계에서 가장 큰 오해를 만들어낸다.

파이프라인 관점에서 보면 각 단계는 앞 단계의 출력을 받아서 처리하고 다음 단계로 넘긴다. 단방향이다. 이 관점을 따르면 “품질 관리는 처리 단계 이후에 하면 된다”, “보안은 저장 단계에서 처리하면 된다”, “표준은 처음에 한 번 만들면 된다”는 결론에 이른다. 그 결과 각 단계가 독립적으로 설계되고, 각 단계 담당팀이 분리되고, 데이터 거버넌스가 여러 팀의 책임으로 쪼개진다.

DMBOK은 “데이터 관리는 라이프사이클 관리다”를 핵심 원칙으로 제시하면서, 동시에 “서로 다른 유형의 데이터는 서로 다른 라이프사이클 특성을 갖는다”고 명시한다 (DAMA International, 2017, Ch.1). 이것은 라이프사이클이 단일한 직선이 아니라, 각 단계 간에 복잡한 피드백 관계가 존재하는 순환 구조라는 뜻이다. 활용 단계에서 발견한 문제가 표준으로 피드백되고, 품질 진단 결과가 모델 설계를 수정하고, 보안 이슈가 접근 통제 정책을 개선한다. 이 피드백 루프가 작동하지 않으면 거버넌스는 시간이 갈수록 현실과 멀어지는 문서 더미가 된다.

이 글에서는 데이터 라이프사이클의 각 단계가 어떻게 연결되어 있는지, 그 연결 지점에서 어떤 설계 결정이 필요한지를 구체적으로 다룬다.

2 6단계 라이프사이클의 구조

데이터 거버넌스 관점의 라이프사이클은 다음 6개 단계로 구성된다. 각 단계는 앞 단계를 전제하고, 동시에 뒤 단계에 의해 검증된다.

+--------------------------------------------------------------+
|                                                              |
|   정책/표준  ->  모델 설계  ->  메타 관리  ->  데이터 보안         |
|       ^                                          |           |
|       |                                          v           |
|   데이터 활용  <-  데이터 품질  <-----------------              |
|                                                              |
+--------------------------------------------------------------+

이 순환의 각 단계를 실제 시스템과 연결해서 이해해야 한다. 앞선 글(데이터 거버넌스란 무엇인가)에서 DAMA 10대 지식 영역의 구조와 라이프사이클의 개괄을 다뤘다면, 여기서는 각 단계 내부의 설계 결정에 집중한다.

3 1단계: 정책과 표준 수립

3.1 표준이 없으면 모든 것이 나중에 비용이 된다

정책과 표준은 데이터 거버넌스의 출발점이다. 그러나 많은 조직에서 “표준을 만들자”는 결정이 이루어지는 시점은 이미 수백 개의 테이블과 수천 개의 칼럼이 존재하는 시점이다. 이미 존재하는 시스템에 사후적으로 표준을 적용하는 것은 처음부터 표준을 적용하는 것보다 10배 이상 어렵다. 이것이 표준 수립을 라이프사이클의 맨 처음에 배치하는 이유다.

DMBOK은 데이터 정책을 “데이터의 생성, 취득, 무결성, 보안, 품질, 사용에 대한 기본 규칙을 성문화한 것”으로 정의하며, 정책(what to do)과 표준/절차(how to do)를 구분한다 (DAMA International, 2017, Ch.3). 정책이 “고객 데이터는 정본 시스템에서만 생성한다”라면, 표준은 “고객 테이블의 칼럼명은 CUST_ 접두어를 사용한다”이고, 절차는 “신규 칼럼 추가 시 DA 검토를 거친다”다. 이 세 가지가 분리되어 있어야 정책 변경 없이 표준만 개선할 수 있고, 표준 변경 없이 절차만 조정할 수 있다.

3.2 표준의 3계층 구조: 용어, 단어, 도메인

데이터 표준은 세 가지 계층으로 구성된다. 이 세 계층이 독립적으로 정의되어 있어야 서로를 조합해서 새로운 칼럼을 표준에 따라 명명할 수 있다.

표준 용어(Term)는 비즈니스 개념의 공식 이름이다. “고객”, “주문”, “결제금액”이 용어의 예시다. 용어는 한글 이름과 영문 이름이 매핑되고, 이것이 테이블명과 칼럼명의 기초가 된다. 예를 들어 “고객” 용어의 영문이 “CUSTOMER”라면 고객 관련 테이블은 TB_CUSTOMER_로 시작해야 한다.

표준 단어(Word)는 용어를 구성하는 최소 단위다. “고객”이 용어라면 “고객”은 동시에 단어다. “주문금액”은 “주문”과 “금액” 두 단어의 조합이다. 칼럼명을 구성할 때 사용하는 단어와 약어(Abbreviation)를 표준화한다. “금액”의 약어를 “AMT”로 정했으면 모든 금액 관련 칼럼명은 _AMT로 끝나야 한다. 이 약어 체계가 없으면 “AMOUNT”, “AMT”, “PRICE”, “COST”가 혼재하게 된다.

표준 도메인(Domain)은 데이터의 타입과 허용 값의 범위를 정의한다. DMBOK은 도메인을 “속성 간 형식과 값 집합의 일관성을 보장하는 수단”으로 설명한다 (DAMA International, 2017, Ch.5). 예를 들어 “금액 도메인”은 NUMBER(15,2) 타입이고 0 이상의 값만 허용한다. “성별 코드 도메인”은 코드 도메인으로서 성별 코드 그룹의 값만 허용한다. 도메인이 칼럼에 매핑되면, 품질 진단 엔진이 이 도메인 규칙에 따라 실제 데이터를 자동으로 검증할 수 있다.

이 3계층의 연결 관계가 핵심이다. 단어는 기본 도메인과 연결된다. “금액”이라는 단어로 끝나는 칼럼은 특별한 지정이 없으면 “금액 도메인”을 기본으로 사용한다. 이 연결 관계가 있으면 신규 칼럼을 추가할 때 도메인 매핑을 수동으로 하지 않아도 단어 기반으로 자동 추론할 수 있다.

계층	정의	예시	연결
표준 용어	비즈니스 개념의 공식 이름	고객, 주문, 결제금액	한글명-영문명 매핑
표준 단어	용어를 구성하는 최소 단위	고객, 주문, 금액	약어 매핑 (금액->AMT)
표준 도메인	타입 + 허용 값 범위	금액형: NUMBER(15,2), >= 0	단어-도메인 기본 연결

3.3 복수 표준의 현실적 관리

이상적으로는 전사 표준 하나가 모든 시스템에 적용되어야 한다. 그러나 현실에서는 이미 수십 년 된 레거시 시스템, 패키지 솔루션(SAP, Oracle ERP 등), 인수합병으로 통합된 외부 시스템이 각자의 명명 규칙을 갖고 있다. 이들에게 전사 표준을 강제 적용하는 것은 불가능하거나 너무 많은 비용이 든다.

실용적인 해결책은 복수 표준을 허용하되 명시적으로 관리하는 것이다.

범주	설명	관리 방식
전사 공개 표준 (Public)	신규 시스템에 적용하는 기준 표준	표준 사전에서 정의, 준수율 측정
로컬 표준 (Local)	특정 시스템의 자체 표준	전사 표준과의 매핑 테이블 관리
비표준 (Non-Standard)	표준 미적용 레거시 시스템	비표준 칼럼 목록 관리, 점진적 전환 계획

각 시스템이 어느 범주를 따르는지 메타데이터로 관리하면 표준 미준수율을 수치로 파악하고 점진적으로 개선하는 계획을 세울 수 있다.

AI 자동화와의 연결 지점도 여기에 있다. 레거시 시스템의 비표준 칼럼명을 전사 표준 용어와 자동으로 매핑하는 것이 LLM 기반 자동화의 유력한 적용 분야다. 칼럼명 CUST_NM이 표준 용어 “고객명”에 해당한다는 것을 AI가 제안하고, DA가 검토해서 확정하는 방식이다.

4 2단계: 모델 설계

4.1 ERD는 문서가 아니라 살아있는 설계 기준이다

데이터 모델(ERD)은 많은 조직에서 설계 초기에 한 번 만들고 이후에는 업데이트되지 않는 문서로 취급된다. 이것이 “문서로서의 ERD”다. 반면 거버넌스 관점에서 ERD는 실제 DBMS 스키마의 기준이 되어야 하는 “설계 기준으로서의 ERD”다.

DMBOK은 “모델이 만들어진 후에는 최신 상태로 유지해야 한다. 요구사항이 변경될 때, 비즈니스 프로세스가 변경될 때 모델도 업데이트해야 한다”고 명시하며, “개발 이터레이션 종료 시 물리 모델을 역공학(reverse engineer)하여 논리 모델과 일치하는지 확인하는 것이 모범 사례”라고 권고한다 (DAMA International, 2017, Ch.5).

이 두 가지 역할의 차이는 작지 않다.

구분	문서로서의 ERD	설계 기준으로서의 ERD
DBMS와의 관계	현실과 달라도 방치	불일치 시 갭 분석 알람 발생
변경 프로세스	없음	ERD 수정 -> DDL 자동 생성 -> 변경 요청
유지보수	초기 1회성	지속적 동기화

ERD와 DBMS 사이의 이 살아있는 연결이 모델 설계 단계를 라이프사이클의 실질적인 구성 요소로 만든다.

4.2 논리 모델과 물리 모델의 분리를 유지하는 이유

논리 모델은 DBMS 독립적인 비즈니스 개념의 표현이다. 물리 모델은 특정 DBMS에 최적화된 구현이다. DMBOK은 정순 공학(forward engineering) 과정을 CDM -> LDM -> PDM -> 데이터베이스 구조 순서로 정의한다 (DAMA International, 2017, Ch.5). 이 분리를 유지하는 것이 번거롭게 느껴질 수 있지만, 분리를 포기하는 순간 다음 문제들이 발생한다.

DBMS 마이그레이션 비용 증가. Oracle에서 PostgreSQL로 이전할 때 논리 모델이 없으면 Oracle 물리 모델을 보고 비즈니스 개념을 역으로 추출해야 한다. Oracle 특유의 물리 구현(NUMBER 타입, 파티셔닝 방식, 인덱스 힌트)과 비즈니스 로직을 분리하는 작업이 추가된다.

시스템 통합 난이도 증가. 두 시스템의 “고객” 테이블을 통합할 때 각각의 논리 모델이 있으면 비즈니스 개념 수준에서 차이를 파악하고 통합 전략을 세울 수 있다. 물리 모델만 있으면 칼럼명과 타입의 차이만 보이고, 그 차이가 비즈니스 개념의 차이에서 비롯된 것인지 단순히 명명 규칙의 차이인지 판단하기 어렵다.

4.3 데이터 흐름 설계: 계보와 영향도 분석의 기초

데이터 흐름 관리는 어떤 테이블에서 어떤 테이블로 데이터가 이동하는지, 그 과정에서 어떤 변환이 일어나는지를 메타데이터로 관리한다. DMBOK은 데이터 계보(lineage) 도구를 “속성의 원천 구조를 캡처하고 유지하여 영향도 분석(impact analysis)을 가능하게 하는 소프트웨어”로 정의한다 (DAMA International, 2017, Ch.5).

이것은 단순히 ETL 파이프라인의 문서화가 아니다. 데이터 흐름 정보가 메타데이터로 관리되면 두 가지 핵심 기능이 가능해진다.

데이터 계보(Data Lineage). 마트 테이블에서 이상 값이 발견되면 데이터 흐름을 역방향으로 추적해서 원천 테이블의 어떤 레코드가 문제인지 찾을 수 있다. 운영 DB -> DW -> 마트 -> BI 보고서로 이어지는 경로에서 오류 원인을 자동으로 역추적하는 것이다.

영향도 분석(Impact Analysis). 운영 DB의 특정 칼럼을 변경하기 전에, 그 칼럼을 참조하는 모든 하위 시스템(ETL, DW, 마트, BI 보고서)을 자동으로 파악할 수 있다. 이 정보 없이는 칼럼 하나를 변경하기 위해 DBA가 수동으로 영향 범위를 조사해야 하고, 놓친 곳에서 장애가 발생한다.

5 3단계: 메타 관리

5.1 자동 수집과 수동 입력의 경계를 정확히 긋는다

메타 관리 단계에서 가장 중요한 설계 결정은 어떤 메타데이터를 자동으로 수집하고, 어떤 메타데이터를 사람이 입력해야 하는지를 명확히 구분하는 것이다.

DMBOK은 “메타데이터는 아키텍처, 모델링, 스튜어드십, 거버넌스, 품질 관리, 시스템 개발, IT 및 비즈니스 운영, 분석 등 데이터 생성, 처리, 사용과 관련된 다양한 프로세스에서 발생한다”고 설명한다 (DAMA International, 2017, Ch.1). 이 다양한 원천을 기술 메타와 비즈니스 메타로 구분하면 수집 전략이 명확해진다.

구분	예시	수집 방식	불일치 위험
기술 메타	테이블명, 칼럼명, 데이터 타입, NULL 허용, 인덱스	DBMS 카탈로그에서 자동 수집	수동 입력 시 즉시 불일치
비즈니스 메타	업무 정의, 데이터 오너, 생성 프로세스	사람이 직접 입력	자동 생성 시 형식만 있고 내용 없음

이 경계를 정확히 긋지 않으면 두 가지 문제가 생긴다. 자동 수집 가능한 것을 사람이 입력하게 하면 불필요한 작업 부담과 불일치가 발생한다. 반대로 사람이 입력해야 하는 것을 자동 생성하려고 하면 의미 없는 메타데이터가 쌓인다. 예를 들어 칼럼 코멘트를 칼럼명에서 자동 추출하면 CUST_ID의 설명이 “CUST ID”가 되는 것처럼 형식만 있고 내용이 없는 메타데이터가 생긴다.

5.2 비즈메타와 데이터 맵: 사용자가 실제로 찾을 수 있게

기술 메타데이터가 “테이블에 어떤 칼럼이 있는가”를 설명한다면, 비즈니스 메타데이터는 “이 데이터가 업무적으로 무엇인가”를 설명한다. 그런데 실제 데이터 사용자, 특히 분석가들은 “주문 테이블”을 찾는 것이 아니라 “최근 3개월 고객별 구매 금액”이 어느 테이블에 있는지를 찾는다.

비즈메타(Business Metadata)는 이 탐색을 가능하게 하는 레이어다. 테이블을 업무 주제 영역(고객, 주문, 결제, 재고 등)으로 분류하고, 각 테이블과 칼럼에 업무 정의를 등록한다. DMBOK이 강조하는 비즈니스 용어사전(Business Glossary)이 바로 이 역할을 한다 (DAMA International, 2017, Ch.3). 데이터 맵은 이 분류 체계를 시각화해서 전사 데이터 구조를 한눈에 파악할 수 있게 한다.

데이터 맵의 설계 포인트는 비즈니스 계층과 기술 계층을 별도로 제공하는 것이다. 같은 테이블을 비즈니스 사용자는 업무 주제(고객 -> 고객 기본정보 -> TB_CUSTOMER)로 찾고, 개발자는 시스템 이름(CRM -> schema_main -> TB_CUSTOMER)으로 찾는다.

6 4단계: 데이터 보안

6.1 보안과 활용은 충돌이 아니라 균형이다

데이터 보안을 라이프사이클에 포함시키는 것에 저항감을 느끼는 개발팀이 있다. “보안 때문에 데이터를 쓰기 어렵다”는 불만이 나온다. 이 충돌은 보안을 “접근 차단”으로만 이해할 때 생긴다.

거버넌스 관점의 보안은 “적절한 맥락에서 적절한 사람이 데이터에 접근할 수 있게 하는 것”이다. 개인정보를 포함한 고객 데이터를 분석팀에 제공할 때 비식별화 규칙을 통해 안전하게 제공할 수 있다면, 오히려 보안 체계가 없을 때보다 더 많은 데이터를 활용할 수 있다. “이 데이터는 보안상 줄 수 없다”에서 “이 데이터는 이렇게 처리하면 줄 수 있다”로 바뀌는 것이다. 앞선 글에서 다룬 “보안은 제약이 아니라 신뢰의 기반”이라는 원칙이 구체적으로 적용되는 지점이다.

6.2 중요데이터 등급 체계의 설계 원칙

등급 체계를 설계할 때 중요한 것은 숫자가 아니라, 각 등급의 기준이 명확하고 접근 통제 정책과 직접 연결되는 것이다. 등급 정의서에는 다음 질문에 대한 답이 포함되어야 실제 운영에서 판단 기준이 된다.

질문	등급별 답변이 필요한 이유
누가 조회할 수 있는가	접근 통제 정책의 기초
조회 시 마스킹이 필요한가	비식별화 규칙 적용 기준
테스트 환경에 복사할 때 어떻게 처리하는가	개발/운영 환경 분리 정책
외부에 제공할 수 있는가	데이터 제공 정책의 기초

개인정보(PI)는 등급 체계와 별도로 관리한다. 개인정보는 법적 규제(개인정보보호법, GDPR)의 적용을 받으므로 등급과 다른 처리 기준이 적용된다. 수집 목적, 보존 기간, 제3자 제공 여부, 파기 방법이 법률에 따라 결정된다.

6.3 비식별화는 규칙이다, 사람의 판단이 아니라

비식별화를 “담당자가 케이스바이케이스로 판단한다”고 운영하면 즉시 불일치가 생긴다. A 담당자는 전화번호 뒷 4자리를 마스킹하고, B 담당자는 앞 3자리만 마스킹한다. 규정에 어긋나는 데이터 제공이 발생한다.

비식별화 규칙은 칼럼 유형별로 명확하게 정의되어 시스템에 등록되어야 한다. 그리고 데이터를 제공할 때 이 규칙이 자동으로 적용되어야 한다. 이것이 “비식별화 규칙 관리”가 독립된 컴포넌트로 필요한 이유다.

7 5단계: 데이터 품질

7.1 품질 진단의 3단계: 프로파일링에서 업무 규칙까지

품질 진단을 한 번에 모든 규칙을 적용하는 것으로 설계하면 실패한다. DMBOK은 “소규모의 집중된 노력, 즉 기본적인 개념 증명(proof of concept)으로 시작하는 것이 보통 최선”이라고 권고한다 (DAMA International, 2017, Ch.13). 현실에서 처음 품질 진단을 실행하면 엄청난 양의 오류가 발견된다. 오류가 너무 많으면 어디서부터 시작해야 할지 모르고, 담당자들은 “데이터가 원래 그렇다”며 포기한다.

효과적인 품질 관리는 단계를 밟는다.

1단계: 프로파일링. 실제 데이터의 분포를 파악한다. NULL 비율, 고유값 수, 최대/최소값, 상위 빈도 값을 수집한다. 이 단계는 판단을 하지 않는다. 현재 상태를 있는 그대로 파악하는 것이다. DMBOK은 프로파일링 도구를 “데이터 콘텐츠를 탐색하고, 기존 메타데이터에 대해 검증하고, 데이터 품질 갭을 식별하는 도구”로 정의한다 (DAMA International, 2017, Ch.5).

2단계: 도메인 규칙 진단. 칼럼에 매핑된 도메인의 규칙을 검증한다. 금액 칼럼에 음수가 있는가, 날짜 칼럼에 유효하지 않은 형식이 있는가, 코드 칼럼에 정의되지 않은 코드값이 있는가. 칼럼 단위 검증이므로 자동화하기 쉽고, 도메인만 잘 정의되어 있으면 추가 설정 없이 실행된다.

3단계: 업무 규칙 진단. 여러 칼럼 또는 여러 테이블 간의 관계를 검증한다. “주문 완료 상태인 주문에는 반드시 결제 정보가 있어야 한다”, “출발일은 도착일보다 이전이어야 한다”, “재고 수량은 입고 합계에서 출고 합계를 뺀 것과 일치해야 한다”. 비즈니스 로직을 알아야 정의할 수 있으므로 업무 담당자와 DA가 협업해서 규칙을 작성해야 한다. DMBOK은 “데이터 품질 규칙을 정의하는 것은 대부분의 사람들이 데이터를 규칙의 관점에서 생각하는 데 익숙하지 않기 때문에 도전적”이라고 인정하면서, “평가 결과를 공유하는 것이 규칙을 이끌어내는 가장 좋은 방법”이라고 제안한다 (DAMA International, 2017, Ch.13).

7.2 품질 점수화: 측정하지 못하면 관리하지 못한다

품질 진단 결과를 수치로 표현하면 경영진에게 보고할 수 있고, 개선 전후를 비교할 수 있고, 부서별/시스템별 품질 수준을 비교할 수 있다.

DMBOK은 품질 점수 계산 공식을 다음과 같이 제시한다 (DAMA International, 2017, Ch.13).

\[ValidDQI(r) = \frac{TestExecutions(r) - ExceptionsFound(r)}{TestExecutions(r)}\]

\(r\) 은 테스트하는 규칙이다. 10,000건에 대해 규칙 \(r\) 을 실행하여 560건의 예외가 발견되면 \(ValidDQI = 9440/10000 = 94.4\%\) 다.

점수 설계 시 주의할 점은 두 가지다. 단순히 오류 건수를 집계하면 큰 테이블의 오류가 작은 테이블을 압도하므로, 반드시 오류율 기준으로 비교해야 한다. 또한 도메인 규칙 오류와 업무 규칙 오류에 다른 가중치를 줄 수 있다. 업무 규칙은 비즈니스 영향이 더 크므로 높은 가중치를 주는 것이 합리적이다.

8 6단계: 데이터 활용

8.1 활용이 목적이고, 거버넌스는 수단이다

데이터 거버넌스의 모든 노력이 향하는 최종 목적지는 데이터의 신뢰할 수 있는 활용이다. 표준을 만들고, 모델을 설계하고, 메타데이터를 관리하고, 품질을 진단하는 모든 활동은 결국 “필요한 사람이 필요한 데이터를 필요한 시점에 신뢰할 수 있는 형태로 사용할 수 있게” 하기 위한 것이다.

이 관점에서 활용 단계의 설계는 “어떻게 하면 사용자가 데이터를 쉽게 찾고, 안전하게 접근하고, 신뢰하고 사용할 수 있는가”로 귀결된다.

8.2 DW 없이 Federation으로: ETL 비용을 줄이는 설계

전통적인 데이터 활용 아키텍처는 운영 DB -> ETL -> DW -> 마트 -> BI 도구로 이어지는 파이프라인이다. 이 파이프라인은 데이터 양이 많고 복잡한 분석이 필요한 경우에는 합리적이다. 그러나 모든 데이터 활용 요구가 이 수준을 필요로 하지는 않는다.

Data Federation은 DW 적재 없이 원천 시스템의 데이터를 직접 쿼리해서 제공하는 방식이다. 메타데이터 시스템에서 “비즈 뷰(Business View)”를 정의하고, 승인된 뷰에 대해서만 접근을 허용한다. 뷰의 결과를 캐싱하면 DB 부하도 제어할 수 있다.

활용 방식	적합한 경우	한계
DW/마트 기반	대용량 집계, 복잡한 조인, 히스토리 분석	ETL 구축/운영 비용
Federation 기반	소규모 리포트, 실시간 현황, 테이블 데이터 확인	대용량 처리 시 성능 제약

두 방식은 배타적이 아니라 보완적이다. 핵심 분석은 DW로, 일상적 조회는 Federation으로 구성하면 ETL 범위를 줄이면서 데이터 접근성은 높일 수 있다.

9 피드백 루프: 라이프사이클이 순환하는 방식

6단계를 한 번 거치는 것으로 끝이 아니다. 각 단계에서 발생하는 신호가 다른 단계의 개선을 촉발한다.

발견 지점	신호	피드백 대상
품질 진단	특정 도메인에서 오류율 급증	표준(1단계): 도메인 규칙 재검토
데이터 활용	분석가가 필요한 데이터를 찾지 못함	메타 관리(3단계): 비즈메타 보강
보안 운영	권한 없는 접근 시도 발생	보안(4단계): 등급 기준 재검토
변경 요청	특정 테이블 변경 요청 빈발	모델 설계(2단계): ERD 재검토
활용 결과	부서별 “매출” 숫자 불일치	표준(1단계): 용어 정의 통일

이 신호들이 시스템 내에서 자동으로 감지되고, 담당자에게 전달되고, 개선 액션으로 연결되는 구조가 거버넌스의 “지속적 개선 사이클”이다. DMBOK이 거버넌스 프로그램의 3대 요건으로 제시하는 “지속 가능성(Sustainable), 내재화(Embedded), 측정 가능성(Measured)”은 모두 이 피드백 루프가 작동해야 달성된다 (DAMA International, 2017, Ch.3).

이 사이클이 없으면 거버넌스 시스템은 초기 구축 이후 점점 현실과 멀어지는 유물이 된다. 순환이 끊어지는 가장 흔한 지점은 피드백 채널의 부재다. 분석팀이 품질 문제를 발견했지만 표준팀에 전달할 채널이 없거나, 전달하더라도 표준 변경 프로세스가 없어서 방치되는 경우가 빈번하다. 거버넌스의 실질적 성패는 이 피드백 경로가 작동하는지에 달려 있다.

10 관련 주제

카테고리 내 연결