분기 회의에서 핵심 어휘를 합의하고, 영업과 재무가 매출 정의를 맞추고, 새 데이터셋에 의미와 맥락이 담깁니다. 두 분기 뒤 새 프로젝트가 시작됩니다. 새 팀이 모이고, 같은 단어를 두고 또 다른 의견이 나옵니다. 지난번 합의를 적어 둔 노션 페이지를 찾아보지만, 새 프로젝트에 필요한 단어를 다 담고 있지는 않습니다. 결국 처음부터 다시 맞춰야 합니다.
합의를 적어 둔 문서가 있어도, 그 문서가 다음 프로젝트 시작할 때 자동으로 깔리지는 않습니다. 새로 맡은 사람이 문서를 찾아 읽고, 자기 프로젝트에 맞게 정의를 다시 잡고, 부서 간 합의를 다시 만듭니다. 프로젝트가 바뀔 때마다 같은 일이 반복됩니다.
문서가 있어도 안 되는 이유는 문서가 수동이기 때문입니다. 누군가 찾아서 읽어야 하고, 읽은 사람이 자기 프로젝트에 맞게 해석해야 하고, 해석한 결과를 다시 부서 간에 합의해야 합니다. 합의가 문서가 아니라 조직이 돌아가는 절차 안에 들어와야 이 반복이 끊깁니다. 4편에서는 그 절차를 만드는 방법을 다룹니다.
1. 대전제: 데이터를 구조화하고 연결된 네트워크로 보기
거버넌스가 협업, 지식, 비즈니스 로직, 활동을 한꺼번에 다루려면, 데이터끼리 어떻게 연결되어 있는지가 명시적으로 정의되어 있어야 합니다.
고객 테이블, 주문 테이블, 제품 테이블이 각각 있을 때, 이 셋의 관계는 외래 키 하나에 의존하거나 분석가가 매번 머릿속에서 조립합니다. “고객이 어떤 주문을 만들고, 그 주문이 어떤 제품을 포함하고, 그 제품이 어떤 결제와 이어지는가”가 조직 차원에서 정의되어 있지 않으면, 사람마다 다른 방식으로 연결을 조립하게 됩니다.
이 연결을 명시적으로 정의해 두는 것이 네트워크적 사고입니다.
1) 그래프: 네트워크를 표현하는 기본 도구
네트워크를 표현하는 데 쓰이는 기본 도구가 그래프(graph)입니다. 그래프는 노드(node)와 엣지(edge)로 구성됩니다. 노드는 엔티티(사람, 장소, 개념 같은 실체)이고, 엣지는 그 엔티티 사이의 관계입니다.
| 개념 | 뭘 가리키는가 | 예시 |
|---|---|---|
| 노드(node) | 엔티티. 사람, 장소, 개념 같은 실체 | 고객, 주문, 제품 |
| 엣지(edge) | 노드 사이의 관계 | “주문함”, “포함”, “결제” |
| 방향성(directed) | 엣지에 방향이 있음. A → B가 B → A를 의미하지 않음 | 고객 → 주문 (고객이 주문을 만든 것이지, 주문이 고객을 만든 게 아님) |
| 가중치(weight) | 관계에 수치를 붙여 강도나 속성을 표현 | 친밀도 5/5, 거리 350km |
가장 단순한 그래프는 두 노드와 하나의 엣지로 만들 수 있습니다. 이커머스 도메인에서 제품과 카테고리의 관계를 그래프로 표현하면 이렇습니다.
제품은 Product 타입의 노드이고, 카테고리는 Category 타입의 노드이며, “속함”은 “이 제품이 이 카테고리에 분류된다”는 의미가 정의된 엣지입니다.
2) 지식 그래프: 네트워크에 의미를 얹은 구조
그래프에 도메인 지식의 맥락과 의미까지 함께 담으면 지식 그래프(knowledge graph)가 됩니다. 단순한 그래프는 노드와 엣지만 있지만, 지식 그래프는 각 노드와 엣지에 속성(프로퍼티)이 붙고, 노드의 타입과 관계의 종류가 온톨로지(ontology)로 미리 정의되어 있습니다.
온톨로지는 어떤 도메인에 어떤 개체가 있고, 그것들이 서로 어떻게 연결되는지를 미리 정의해 둔 모델입니다. 지식 그래프와의 관계를 비유하면, 온톨로지가 빈 사전이고 지식 그래프는 그 사전을 따라 실제 데이터를 채운 백과사전입니다.
이커머스 주문 데이터셋의 온톨로지를 그려 보면 이렇습니다.
개체(고객, 제품, 세그먼트, 카테고리, 매출), 속성(grade, price, margin_rate 등), 관계(구매, 분류, 속함, 귀속)가 명시적으로 정의되어 있습니다. “고객은 제품을 구매한다”, “제품은 카테고리에 속한다”, “카테고리는 매출에 귀속된다” 같은 관계가 이름과 함께 적혀 있으면, 같은 데이터를 보고도 사람마다 다르게 해석하는 일이 줄어듭니다.
다음은 이 온톨로지를 따라 실제 데이터를 채운 지식 그래프 예시입니다.
이 그래프를 따라가면 데이터 통합에서 나오는 질문에 답할 수 있습니다. “매출 계산 규칙이 바뀌면 어떤 개념이 영향을 받는가?” → 매출 ← 귀속 ← 카테고리 ← 속함 ← 제품. “VIP 세그먼트의 분류 기준이 바뀌면?” → VIP 세그먼트 ← 분류 ← 고객 → 구매 → 제품. 하나의 정의 변경이 데이터셋 안의 다른 개념에 어떻게 퍼져 나가는지를 관계를 따라 추적할 수 있습니다.
다만 지식 그래프를 만들고 유지하는 일은 쉽지 않습니다. 가장 흔한 장애물은 데이터 입력의 품질과 일관성을 보장하는 일입니다. 어떤 엔티티를 노드로 잡을지, 어떤 관계를 엣지로 정의할지, 그 정의를 누가 갱신할지에 대한 합의가 끊임없이 필요합니다. 관리해야 할 개념의 수가 많아지면 담당자가 압도당하고, 결국 팀들이 시스템을 우회하면서 데이터 품질이 오히려 나빠지는 경우도 있습니다. 구글, 링크드인 같은 회사는 수십 년에 걸친 투자와 전담 인력이 있지만, 대부분의 조직은 그런 자원을 갖추고 있지 않습니다.
3) 지식 그래프 없이도 네트워크 사고는 적용할 수 있다
중요한 건, 지식 그래프를 도입하지 않아도 네트워크 사고의 원칙은 적용할 수 있다는 점입니다. 데이터 프로덕트 사이의 관계를 명시적으로 적어 두는 일, 한 데이터 프로덕트가 다른 프로덕트와 어떻게 연결되는지를 카탈로그에 기록하는 일, 정의가 바뀌면 연결된 프로덕트의 담당자에게 알림이 가게 만드는 일이 모두 네트워크 사고의 적용입니다.
조직의 개념을 정렬시키지 않은 채로 지식 그래프에 투자해 봐야, 결함 있는 토대 위에 쌓은 비싼 시스템이 될 뿐입니다. 핵심은 특정 기술이 아니라, 개념이 네트워크 안에서 어떻게 연결되고, 공유되고, 소통되는지를 명시적으로 정의하고 관리한다는 원칙입니다.
4) 연결이 명시되면 달라지는 것
| 비교 축 | 연결이 명시되지 않았을 때 | 연결이 명시되어 있을 때 |
|---|---|---|
| 분석 결과의 일관성 | 분석가마다 테이블을 다른 방식으로 조인해서 결과가 달라짐 | 조직이 합의한 연결 정의대로 조인하니 결과가 같음 |
| 변경의 영향 추적 | 한 테이블의 정의가 바뀌어도 다른 테이블에 영향이 가는지 파악이 안 됨 | 연결이 보이니 정의 변경의 영향 범위를 추적할 수 있음 |
| 거버넌스의 적용 범위 | 테이블 단위로만 작동해서 테이블 사이의 빈 곳을 못 잡음 | 연결 단위로 작동해서 테이블 사이의 합의도 다룰 수 있음 |
첫 번째는 일관성입니다. 고객과 주문의 연결 방식이 정의되어 있지 않으면, 분석가 A는 고객 ID 기준으로, 분석가 B는 이메일 기준으로 조인합니다. 같은 데이터에서 다른 결과가 나옵니다.
두 번째는 영향 추적입니다. 고객 테이블에서 ID 체계가 바뀌었을 때, 주문 테이블과 결제 테이블에 어떤 영향이 가는지가 연결 정의 없이는 파악이 안 됩니다. 연결이 명시되어 있으면 “고객 ID가 바뀌면 주문과 결제에 영향이 간다”가 바로 보입니다.
세 번째는 거버넌스의 범위입니다. 개별 테이블에 대한 규칙만 있으면, 테이블 사이에서 벌어지는 일은 사각지대로 남습니다. 고객 테이블의 정의는 합의됐는데, 고객과 주문 사이의 관계 정의는 합의되지 않은 상태가 흔합니다. 연결까지 거버넌스 범위에 들어와야 이 빈 곳이 채워집니다. 이것이 다음에 다룰 CLEAN 거버넌스의 출발점입니다.
2. CLEAN 데이터 거버넌스: 협업 학습 네트워크
CLEAN은 Collaborative Learning Networks, 즉 협업 학습 네트워크의 약어입니다. 앞 섹션에서 다룬 네트워크 사고를 거버넌스에 적용한 프레임이며, 일회성 합의를 조직의 반복 가능한 운영으로 바꾸는 데 쓰입니다.
CLEAN 거버넌스는 네 가지 구성요소로 이루어져 있습니다. 협업(Collaboration), 지식(Knowledge), 비즈니스 로직(Business Logic), 활동(Activity)입니다.
| 구성요소 | 다루는 질문 | 산출물 | 책임 주체 |
|---|---|---|---|
| 협업 | 누가 어떤 결정에 참여하고, 충돌은 어떻게 해소하는가 | 사인오프 절차, 의사결정 RACI | 프로덕트 매니저, 도메인 리드 |
| 지식 | 관련된 사람들이 무엇을 알아야 하는가 | 살아 있는 어휘집, 온보딩 가이드 | 데이터 스튜어드 |
| 비즈니스 로직 | 어떤 조건에서 어떤 결과가 나오는가, 예외는 어떻게 처리하는가 | 계산 로직 정의, 룰셋, 정책 | 도메인 전문가, 데이터 엔지니어 |
| 활동 | 사람들이 데이터 프로덕트를 실제로 어떻게 쓰고 있는가 | 사용 로그, 접근 통제 정책, 감사 자료 | 데이터 플랫폼, 보안 팀 |
네 구성요소를 하나씩 풀어 보겠습니다.
1) 협업(Collaboration)
협업 학습 네트워크의 핵심은 사람입니다. 조직 안에서 어떤 역할을 맡고 있는지, 어느 팀에 속해 있는지, 고객인지 파트너인지에 따라 데이터에 대한 접근 권한과 책임이 달라집니다. 협업 거버넌스는 이 관계를 세 차원으로 정리합니다.
| 차원 | 다루는 질문 |
|---|---|
| 조직(Organization) | 팀 구조와 부서 간 관계가 어떻게 되어 있는가? 각 부서가 조직 목표를 달성하기 위해 어떤 순서로 어떤 역할을 맡는가? |
| 사람(People) | 각 팀에 누가 있고, 어떤 역할을 맡고 있고, 어떤 데이터에 접근할 수 있는가? 고객, 외부 벤더, 내부 직원을 구분하는 기준이 명확한가? |
| 파트너(Partners) | 고객사나 공급사 같은 외부 조직이 있는가? 있다면 그 조직의 구조는 어떻게 되어 있고, 데이터 공유 범위는 어디까지인가? |
이 세 차원이 정리되어 있지 않으면, 새 데이터 프로덕트를 출시할 때 “이 결정은 누가 내리나?”부터 매번 다시 물어야 합니다. 이걸 명시하는 가벼운 도구가 RACI 매트릭스입니다. R(Responsible, 실행), A(Accountable, 최종 책임), C(Consulted, 자문), I(Informed, 통보)의 네 라벨로 한 의사결정에 누가 어떻게 관여하는지를 표시합니다.
| 의사결정 | 비즈니스 PM | 데이터 엔지니어 | 법무 | 보안 | 데이터 스튜어드 |
|---|---|---|---|---|---|
| 컬럼 정의 합의 | A | R | C | I | C |
| 스키마 설계 | C | R/A | I | C | C |
| 개인정보 처리 검토 | I | C | R/A | C | I |
| 접근 통제 정책 | I | C | C | R/A | C |
| 출시 게이트 통과 | R/A | C | C | C | C |
이 매트릭스가 잡혀 있으면 새 데이터 프로덕트가 들어올 때마다 “이 결정은 누가 내리나?”를 묻지 않아도 됩니다. 결정마다 라벨이 이미 붙어 있으니 흐름이 자동으로 깔립니다.
2) 지식 (Knowledge)
지식 거버넌스가 다루는 대상은 세 가지입니다.
| 대상 | 뭘 가리키는가 | 예시 |
|---|---|---|
| 리소스 (Resources) | 사람들이 업무 목표를 달성하기 위해 쓰는 모든 형태의 콘텐츠 | 문서, 프레젠테이션, 영상, 스프레드시트, 온보딩 가이드 |
| 데이터 (Data) | 상황을 파악하고 의사결정을 내리기 위해 만들고, 소비하고, 유통하는 정보 | 데이터 프로덕트의 네 측면이 여기에 해당 |
| 코드 (Code) | 모듈화되어 관리할 수 있는 모든 코드 | 계산 로직, 분석 스크립트, ML 파이프라인 |
세 대상이 따로 관리되면 같은 문제가 반복됩니다. 어휘집은 노션에 있고, 데이터 정의는 스키마 파일에 있고, 계산 로직은 코드 저장소에 있는데 셋이 서로 연결되어 있지 않습니다. 지식 거버넌스는 이 셋을 연결하고, 신규 입사자 온보딩에 넣고, 분기마다 갱신하는 정기 절차로 만드는 작업입니다. 절차 안에 들어와야 새 사람이 합류했을 때 같은 정의를 흡수하고, 정의가 바뀌었을 때 관련된 사람들이 알 수 있습니다.
3) 비즈니스 로직 (Business Logic)
모든 조직에는 자원을 관리하고 거래를 처리하는 규칙이 있습니다. 비즈니스 로직 거버넌스는 이 규칙을 세 카테고리로 정리합니다.
| 카테고리 | 다루는 질문 | 예시 |
|---|---|---|
| 재무 (Financial) | 비용, 자산, 매출이 어떻게 계산되는가 | “매출은 총 판매액에서 커미션을 뺀 금액”, “재고 자산은 이동평균법으로 계산” |
| 컴플라이언스 (Compliance) | 어떤 법적, 산업적 규제를 따라야 하는가 | GDPR, HIPAA, SOC 2, 접근성 표준 |
| 프로세스 (Processes) | 업무가 어떤 순서로 흘러가는가 | 주문 접수 → 결제 확인 → 재고 차감 → 출고 → 정산 |
재무 규칙이 명시되어 있지 않으면, 같은 “매출”이라는 단어를 두고 영업은 총 판매액으로, 재무는 커미션 차감 후 금액으로 계산합니다. 컴플라이언스가 명시되어 있지 않으면, 개인정보 처리 방침을 어떤 팀은 지키고 어떤 팀은 모른 채로 데이터를 다룹니다. 프로세스가 명시되어 있지 않으면, 팀마다 각자의 업무 순서를 갖고 있어서 데이터가 어느 시점에 어떤 상태인지가 사람마다 다르게 해석됩니다.
비즈니스 로직 거버넌스는 이 세 카테고리의 규칙을 회의록이 아니라 코드로 형식화하는 작업입니다. 매출 계산 공식이 코드에 박혀 있으면, 누군가 합의와 다른 방식으로 계산하려 할 때 자동으로 차이가 드러납니다.
4) 활동 (Activity)
협업, 지식, 비즈니스 로직이 다 잡혀 있어도, 실제로 사람들이 데이터를 어떻게 쓰고 있는지를 추적하지 않으면 거버넌스는 문서로만 남습니다. 활동 거버넌스는 이 추적을 세 단계로 다룹니다.
| 단계 | 다루는 질문 | 예시 |
|---|---|---|
| 목표 (Objectives) | 각 팀의 목표가 무엇이고, 그 목표들이 서로 정렬되어 있는가 | “마케팅의 전환율 목표와 재무의 매출 목표가 같은 정의를 쓰고 있는가” |
| 행동 (Actions) | 목표를 향해 사람들이 실제로 어떤 행동을 하고 있는가, 그 행동이 추적되고 있는가 | 일간 회의, 행동 분석 도구, 분기 리뷰 |
| 결과 (Outcomes) | 행동의 결과가 무엇이고, 목표에 얼마나 가까워졌는가 | 전환율 변화, 매출 변화, 비용 절감 효과 |
목표가 정렬되어 있지 않으면 팀마다 다른 방향으로 데이터를 씁니다. 행동이 추적되지 않으면 거버넌스가 실제로 돌아가는지 확인할 수 없습니다. 결과가 측정되지 않으면 거버넌스에 들인 노력이 가치를 만들고 있는지 판단할 수 없습니다. 활동 거버넌스는 이 세 단계를 연결해서, 목표를 세우고, 행동을 추적하고, 결과를 측정하는 순환을 만듭니다.
3. 프로세스 맵: 단계마다 모호성을 비추기
거버넌스가 정적 문서로 굳지 않으려면, 모호성을 계속 가시화해 주는 도구가 필요합니다. 그 도구가 프로세스 맵(process map)입니다. 프로세스 맵은 업무 프로세스의 각 단계를 시각화한 다이어그램이며, 시작 노드, 프로세스 노드, 의사결정 노드, 현재 상태 노드로 구성됩니다.
프로세스 맵이 모호성을 드러내는 메커니즘은 단순합니다. 같은 프로세스를 여러 이해관계자에게 그려 달라고 했을 때 서로 다른 맵이 나온다는 사실 자체가 모호성의 지표입니다.
1) 이해관계자마다 다른 프로세스 맵
이커머스 주문 처리 프로세스를 예로 들어 보겠습니다. CS팀에게 주문 처리 흐름을 물으면 이런 맵이 나옵니다.
의사결정 노드 1개, 프로세스 노드 4개입니다. 단순한 흐름입니다.
같은 질문을 재무팀에게 하면 다른 맵이 나옵니다.
의사결정 노드 2개, 프로세스 노드 6개입니다. CS팀의 맵에는 없던 “고객 잔액 확인”과 “주문 차단”이 들어가 있습니다.
두 맵을 놓고 보면 바로 질문이 생깁니다. CS팀은 미수금 확인 절차를 모르는 건가, 아니면 알지만 자기 업무가 아니라고 보는 건가? 재무팀이 말하는 “90일 초과” 기준은 어디에 명시되어 있는가? 이 차이가 프로세스 맵이 드러내는 모호성입니다. 맵을 그리기 전에는 두 팀이 같은 프로세스를 다루고 있다고 생각했지만, 맵을 놓고 비교하면 서로 다른 프로세스를 보고 있었다는 사실이 표면에 올라옵니다.
더 많은 이해관계자 인터뷰를 진행하면 다른 종류의 프로세스 맵이 추가적으로 나옵니다. 물류팀의 맵에는 배송 가능 지역 판별 노드가 추가되고, 운영팀의 맵에는 프로모션 적용 여부 노드가 추가됩니다. 이 맵들의 의사결정 노드 수와 프로세스 노드 수를 비교하는 것만으로도 모호성의 크기를 가늠할 수 있습니다.
| 맵 출처 | 의사결정 노드 | 프로세스 노드 |
|---|---|---|
| CS팀 | 1 | 4 |
| 재무팀 | 2 | 6 |
| 물류팀 | 3 | 7 |
| 운영팀 | 4 | 9 |
같은 주문 처리 프로세스인데 의사결정 노드가 1개에서 4개까지 갈립니다. 이 차이가 곧 조직 안에 숨어 있는 모호성과 지식 격차의 크기입니다.
2) 맵을 통합하고 어노테이션을 달기
여러 이해관계자의 맵을 비교한 뒤에는 그 차이를 해소하기 위해 하나의 통합 맵을 만듭니다. 통합 맵이 만들어지면 그 위에 어노테이션을 달아서 이해관계자 인터뷰에서 드러난 문제를 시각화합니다. 어노테이션에는 다섯 종류가 들어갑니다.
| 어노테이션 | 뭘 표시하는가 | 이커머스 예시 |
|---|---|---|
| 통점(Pain Point) | 프로세스 안에서 반복적으로 불편이 발생하는 지점 | “고객 잔액 확인 화면이 느려서 CS 응대 시간이 길어짐” |
| 차단(Block) | 담당자가 다음 단계로 넘어가지 못하는 지점 | “재고 확인 수단이 없어서 고객에게 정확한 안내를 못 함” |
| 불확실성(Uncertainty) | 데이터나 판단 기준이 불확실한 지점 | “미수금 데이터가 월 1회만 갱신되어서 실시간 잔액을 모름” |
| 리스크(Risk) | 잘못되면 비용이나 손실로 이어지는 지점 | “잔액 확인을 모든 상담원이 하지는 않아서 미수금 주문이 빠져나감” |
| 가치(Value) | 개선하면 큰 효과가 기대되는 지점 | “품절 시 대안 상품을 자동 추천하면 매출 이탈을 줄일 수 있음” |
어노테이션에는 강도를 붙이는 게 도움이 됩니다. 통점이 1~5 척도로 매겨지면, 같은 “불편”이라도 척도 2짜리와 5짜리는 우선순위가 다릅니다. 이해관계자마다 매긴 강도가 다르다면, 그 차이 자체가 다시 모호성을 드러냅니다.
통합 맵의 각 노드에 어노테이션을 달면 이렇습니다.
| 노드 | 어노테이션 | 강도 | 내용 |
|---|---|---|---|
| 잔액 확인 | 통점 | 4 | 잔액 확인 화면 로딩이 느려서 CS 상담원의 응대 시간이 평균 40초 늘어남 |
| 잔액 확인 | 리스크 | 5 | 모든 상담원이 잔액 확인을 거치지는 않아서, 미수금 고객의 주문이 차단 없이 통과되는 경우가 있음 |
| 미수금 90일? | 불확실성 | 4 | 미수금 데이터가 월 1회만 갱신되어서, 갱신 전에 주문이 들어오면 실시간 잔액을 알 수 없음 |
| 재고 확인 | 차단 | 3 | CS 상담원에게 재고 조회 권한이 없어서, 고객에게 재고 여부를 즉시 안내하지 못함 |
| 대안 안내 | 가치 | 5 | 품절 시 유사 상품을 자동 추천하면 이탈 주문의 일부를 전환할 수 있음 |
같은 “잔액 확인” 노드에 통점(강도 4)과 리스크(강도 5)가 동시에 붙어 있습니다. 이 노드가 프로세스 전체에서 가장 먼저 손봐야 할 지점이라는 판단이 어노테이션만으로 잡힙니다. 이해관계자마다 매긴 강도가 다르다면, 그 차이 자체가 다시 모호성을 드러냅니다. CS팀이 잔액 확인의 통점 강도를 2로 매기고 재무팀이 5로 매겼다면, 두 팀이 같은 단계를 다른 무게로 보고 있다는 뜻입니다.
3) 프로세스 맵과 CLEAN의 연결
프로세스 맵이 드러낸 문제는 CLEAN의 네 구성요소로 이어집니다. 불확실성 어노테이션(“미수금 데이터가 월 1회만 갱신”)은 지식 거버넌스에서 데이터 갱신 주기를 명시하는 작업으로 이어집니다. 차단 어노테이션(“재고 확인 수단이 없음”)은 활동 거버넌스에서 시스템 의존성을 추적하는 작업으로 이어집니다. 리스크 어노테이션(“잔액 확인을 모든 상담원이 하지는 않음”)은 협업 거버넌스에서 역할별 책임을 RACI로 박는 작업으로 이어집니다.
2편에서 다룬 컨셉 컴퍼스가 단어 단위의 모호성을 비추는 도구라면, 프로세스 맵은 단계 단위의 모호성을 비추는 도구입니다. 두 도구가 함께 돌아갈 때 거버넌스는 단어와 단계의 두 차원에서 모호성을 추적합니다.
4) BPMN: 프로세스 맵의 산업 표준
프로세스 맵을 조직 전체에서 공유하려면 표기법이 통일되어야 합니다. BPMN(Business Process Model and Notation)이 그 산업 표준입니다. Object Management Group(OMG)이 정리해 ISO 19510으로 비준되었으며, 2026년 시점에도 BPMN 2.0.2가 현행 버전입니다. BPMN은 시작/종료 이벤트, 태스크, 게이트웨이, 시퀀스 플로 같은 표기 요소를 표준화해서, 팀마다 다른 기호로 맵을 그리는 문제를 막습니다. 이 글에서 그린 프로세스 맵은 개념 설명을 위해 단순화한 것이고, 실무에서 조직 단위로 운영할 때는 BPMN 표기법을 쓰는 게 혼선을 줄입니다.
4. 성공 측정 도구: 가치가 어디로 흐르는가
거버넌스와 프로세스가 제대로 작동한다는 사실은 어떻게 확인할까요? 이를 확인하기 위해 사용할 수 있는 다섯 가지 개념이 있습니다. 바로 다관점 디자인, KPI 정의, 문제 풍경, 넛지입니다.
1) 성공 스펙트럼: 상태의 연속체에 가치를 연결하기
프로세스 맵은 단계가 어떤 순서로 흘러가는지를 보여 주지만, 각 단계가 얼마나 가치 있는지, 지금 상태가 좋은지 나쁜지는 알려 주지 않습니다. 성공 스펙트럼(success spectrum)은 이 빈자리를 채우는 도구입니다.
성공 스펙트럼은 가장 이상적이지 않은 상태에서 가장 이상적인 상태까지를 순차적 연속체로 놓고, 각 상태에 세 가지를 연결합니다. 재무 가치, KPI, 성공 지표입니다.
이커머스 주문 프로세스를 성공 스펙트럼으로 그려 보겠습니다. x축에 고객 여정의 상태를 순서대로 놓고, y축에 각 상태의 가치를 놓습니다.
광고 클릭으로 상품 페이지에 도착한 고객의 가치는 유입 비용 -5,000원입니다. 주문을 완료하면 평균 주문액 45,000원이 발생합니다. 재구매 상태의 재무 가치는 아직 모릅니다. 물음표로 남겨 두는 것 자체가 “모르는 것을 아는 상태”로 만드는 작업입니다.
중간 상태의 재무 가치를 정확히 매기기는 어렵습니다. 장바구니에 담은 고객의 가치가 정확히 얼마인지는 모르지만, 상품 페이지만 본 고객보다는 높고 결제 정보를 입력한 고객보다는 낮다는 건 압니다. 정확한 숫자를 못 매기더라도 “매우 낮음~매우 높음” 같은 정성적 가치로 놓으면, 상태 사이의 상대적 크기가 보입니다.
성공 스펙트럼의 핵심은 여기서 “다음 최선의 상태(Next Best State)”를 추가할 수 있다는 점입니다. 현재 장바구니 → 결제 정보 전환율이 50%라면, “전환율 60%”라는 상태를 스펙트럼에 하나 더 얹고, 그 상태의 재무 가치를 추정합니다. 한 번에 재구매까지 뛰려 하지 않고, 한 칸씩 옮기는 흐름을 만듭니다.
각 상태에서 어떤 데이터가 수집되는지를 명시하면 사각지대가 드러납니다.
| 상태 | 수집되는 데이터 | 수집 여부 |
|---|---|---|
| 장바구니 | 상품 ID, 수량, 담은 시점 | 수집 중 |
| 결제 정보 입력 | 결제 수단, 배송지, 할인 코드 | 수집 중 |
| 결제 정보 입력 | 입력 도중 이탈 시점 | 미수집 |
| 주문 완료 | 주문 ID, 결제 일시, 총액 | 수집 중 |
| 재구매 | 재구매 간격, 재구매 경로 | 미수집 |
위의 표를 예로 들면, “입력 도중 이탈 시점”과 “재구매 간격”이 미수집 상태입니다. 이 빈칸이 보이지 않으면 “왜 결제 전환율이 낮은지”, “왜 재구매가 안 일어나는지”에 대한 답을 찾을 데이터가 없다는 사실을 모른 채로 지나갑니다. 성공 스펙트럼 위에 데이터 수집 현황을 매핑하는 작업이 이 사각지대를 표면으로 끌어올립니다.
2) 다관점 디자인: 같은 스펙트럼을 여러 눈으로 보기
앞에서 그린 성공 스펙트럼은 비즈니스 관점입니다. 고객이 다음 상태로 진행할 때마다 조직에 얼마나 가치가 생기는지를 보여 줍니다. 그런데 이 관점만으로는 “고객이 왜 다음 상태로 넘어가지 않는가”에 답할 수 없습니다.
다관점 디자인(multi-perspective design)은 같은 성공 스펙트럼 형식을 쓰되, 관점을 바꿔서 다시 그리는 작업입니다. 비즈니스 관점이 “고객을 다음 상태로 진행시키면 조직에 얼마만큼 가치가 있는가”를 묻는다면, 사용자 관점은 “고객이 다음 상태로 기꺼이 넘어가려면 그 시점에 무엇이 보여야 하는가”를 묻고, 기술 관점은 “그 상태를 구현하려면 무엇이 준비돼야 하는가”를 묻습니다.
세 관점을 상태별로 나란히 놓으면 이렇습니다.
| 상태 | 비즈니스 관점 (가치) | 사용자 관점 (필요) | 기술 관점 (구현 상태) |
|---|---|---|---|
| 상품 페이지 | 매우 낮음 (-₩5K). 유입 비용만 발생 | 상품이 내가 찾던 건지 빠르게 확인할 수 있어야 함. 사진, 핵심 스펙, 가격, 배송 예상일 필요 | 상품 상세 API 완료. 배송 예상일 계산 진행 중 |
| 장바구니 | 낮음. 구매 의사 표현 단계 | 총 결제액이 명확해야 함. 배송비 포함 총액, 할인 적용 결과 필요 | 배송비 포함 총액 계산 미착수 |
| 결제 정보 입력 | 보통. 거래 가능 상태 진입 | 결제 정보를 넘겨도 안전한지 확인돼야 함. 보안 인증 표시, 반품 정책, 배송비 사전 공개 필요 | 암호화 인증서 미착수. 결제 폼 UI 차단됨 |
| 주문 완료 | 높음 (+₩45K). 매출 발생 | 주문이 제대로 처리됐는지 확인돼야 함. 주문 확인, 배송 예정일, 추적 링크 필요 | 주문 확인 알림 발송 완료 |
| 재구매 | 매우 높음 ($?). 고객 생애 가치 상승 | 다시 살 이유가 있어야 함. 할인 쿠폰, 관련 상품 추천, 재주문 기능 필요 | 재주문 기능 미착수 |
3) KPI 정의: 성공 스펙트럼에 OKR을 붙이기
상태의 연속체를 그리는 것에 더해, 각 상태에서 성공이 어떻게 측정되는지를 정의해야 합니다. 여기에 쓰이는 구조가 OKR(Objectives and Key Results)입니다.
성공 스펙트럼의 “상품 페이지” 상태에 OKR을 붙여 보겠습니다.
성공 스펙트럼의 각 상태마다 이런 표가 붙으면, “왜 상품 페이지에서 장바구니로 넘어가지 않는가”에 대한 진단이 구체적으로 됩니다. 방문은 830회인데 CTA 클릭이 35회라면, 문제는 유입이 아니라 페이지 안의 행동 유도에 있습니다. 성공 지표가 아직 정의되지 않았고 성공이 어떤 모습인지에 대한 모호성이 있다면, 이 표를 채우는 작업 자체가 그 모호성을 드러내는 출발점이 됩니다.
KPI를 먼저 정하고 데이터를 거기에 맞추려 하면 순서가 거꾸로 갑니다. 성공 스펙트럼에서 상태의 연속체를 먼저 잡고, 각 상태 사이의 이동을 목표로 정의한 뒤, 그 목표를 측정할 KPI를 붙이는 순서가 맞습니다.
4) 문제 풍경: 성공 스펙트럼을 뒤집기
성공 스펙트럼은 “각 상태가 얼마나 가치 있는가”를 보여 줍니다. 그런데 가치만 보면 한 가지가 빠집니다. 그 가치를 갉아먹고 있는 문제가 어디에 얼마나 있는지입니다.
문제 풍경(problem landscape)은 성공 스펙트럼을 뒤집은 것입니다. 같은 상태 연속체를 x축에 놓되, y축을 긍정적 가치 대신 부정적 가치로 바꿉니다. 각 상태에서 발생하는 통점(pain point)이 얼마나 큰 부정적 영향을 만들어내는지를 시각화합니다.
성공 스펙트럼에서 “결제 정보 입력” 상태의 가치가 “보통”이었습니다. 그런데 이 상태에서 이탈이 많이 일어나고 있다면, 그 이탈을 만들어내는 통점이 무엇인지, 그 통점이 얼마나 큰 부정적 가치를 만들고 있는지를 봐야 합니다. 문제 풍경은 이 질문에 답합니다.
앞에서 그린 이커머스 성공 스펙트럼의 각 상태에 통점을 매핑하면 이렇습니다.
막대가 높을수록 부정적 가치가 큽니다. 성공 스펙트럼에서는 오른쪽 막대가 높을수록 좋았지만, 문제 풍경에서는 높은 막대가 가장 먼저 해소해야 할 통점입니다.
각 통점이 성공 스펙트럼의 어떤 상태, 어떤 목표와 연결되는지를 함께 매핑하면 우선순위가 잡힙니다.
| 통점 | 어떤 상태에서 발생 | 관련 목표 | 강도 (1~5) | 중요도 | 리스크 | 가치 |
|---|---|---|---|---|---|---|
| 배송비가 결제 직전에야 표시 | 결제 정보 입력 | 결제 전환율 올리기 | 5 | 매우 높음 | 높음 | 높음 |
| 결제 수단 3종뿐 | 결제 정보 입력 | 결제 전환율 올리기 | 4 | 높음 | 보통 | 높음 |
| 재구매 유도 수단 없음 | 주문 완료 → 재구매 | 재구매율 올리기 | 5 | 보통 | 보통 | 보통 |
| 상품 설명이 스펙 위주 | 상품 페이지 | 장바구니 전환율 올리기 | 3 | 보통 | 낮음 | 보통 |
“배송비가 결제 직전에야 표시”라는 통점은 “결제 정보 입력” 상태에서 발생하고, “결제 전환율 올리기”라는 목표에 연결됩니다. 성공 스펙트럼에서 “결제 정보 입력 → 주문 완료” 전환의 재무 가치가 이미 잡혀 있으니, 이 통점을 해소했을 때 얼마만큼의 이탈이 줄어들고 그것이 월 매출로 얼마인지를 추정할 수 있습니다. 통점을 단독으로 나열하면 “배송비 표시가 문제다”로 끝나지만, 성공 스펙트럼의 목표와 재무 가치에 연결하면 “이 문제를 고치면 월 얼마의 매출 이탈이 줄어든다”까지 갈 수 있습니다.
성공 스펙트럼이 “어디로 가야 하는가”를 보여 준다면, 문제 풍경은 “무엇이 가로막고 있는가”를 보여 줍니다. 둘을 나란히 놓으면, 가치가 높은 상태 전환에서 가장 큰 통점이 무엇인지가 한눈에 잡히고, 거버넌스가 어디에 먼저 자원을 쓸지가 정렬됩니다.
5) 넛지: 다음 상태로 밀어주는 정보
성공 스펙트럼으로 상태를 잡고, 다관점 디자인으로 각 관점의 필요를 파악하고, KPI로 측정을 붙이고, 문제 풍경으로 통점을 잡았습니다. 남은 질문은 “그래서 사용자를 실제로 다음 상태로 어떻게 밀어주는가”입니다.
넛지(nudge)는 성공 스펙트럼의 각 상태에서 사용자가 다음 상태로 이동하고 싶게 만드는 정보를 적시에 끼워 넣는 일입니다. 여기서 핵심은 정보의 양입니다. 정보가 너무 많으면 사용자가 압도당해서 아무 행동도 하지 않고, 너무 적으면 다음 상태로 이동할 동기가 생기지 않습니다.
| 현재 상태 | 사용자가 그 시점에 가장 궁금한 것 | 넛지 (최적 정보) | 과부하 (정보 과다) |
|---|---|---|---|
| 상품 페이지 | 이걸 사면 언제 오는가 | “오늘 주문하면 내일 도착” | 상세 스펙 10줄 + 리뷰 요약 + 비교표 + 할인 조건 동시 표시 |
| 장바구니 | 총 얼마를 내는가 | “배송비 무료, 총 결제액 45,000원” | 적립금 안내 + 추가 할인 조건 + 멤버십 가입 유도 동시 표시 |
| 결제 정보 입력 | 내 결제 정보가 안전한가 | “256bit 암호화 결제, 7일 무료 반품” | 보안 인증 마크 5개 + 개인정보처리방침 전문 + 이용약관 링크 동시 표시 |
| 주문 완료 | 다시 살 이유가 있는가 | “다음 구매 시 10% 할인 쿠폰” | 추천 상품 20개 + 리뷰 작성 유도 + SNS 공유 유도 동시 표시 |
넛지가 작동하는 이유는 정보를 많이 줘서가 아니라, 그 시점에 딱 필요한 정보만 줘서 다음 행동으로의 마찰을 줄이기 때문입니다.
넛지는 이커머스 고객 여정에만 적용되는 게 아닙니다. 데이터 프로덕트에서도 같은 원리가 작동합니다.
| 상황 | 사용자가 그 시점에 가장 필요한 정보 | 넛지 |
|---|---|---|
| 분석가가 매출 컬럼을 조회할 때 | 이 숫자가 뭘 의미하는가 | 컬럼 옆에 “총 판매액에서 커미션을 뺀 금액” 한 줄 표시 |
| 매출 정의가 바뀌었을 때 | 내가 쓰고 있는 정의가 바뀌었다 | 해당 정의에 의존하는 대시보드 담당자에게 변경 알림 |
| 신규 입사자가 데이터 프로덕트를 처음 볼 때 | 이 데이터가 어디서 왔고 누가 만들었는가 | 데이터 프로덕트의 맥락(생성자, 생성 시점, 갱신 주기) 표시 |
6. 다섯 도구의 사이클
다섯 도구는 따로 쓰는 게 아니라 하나의 순환으로 연결됩니다.
| 순서 | 도구 | 답하는 질문 |
|---|---|---|
| 1 | 성공 스펙트럼 | 어디로 가야 하는가 |
| 2 | 다관점 디자인 | 각 관점에서 무엇이 필요한가 |
| 3 | KPI 정의 | 진척을 어떻게 측정하는가 |
| 4 | 문제 풍경 | 무엇이 가로막고 있는가 |
| 5 | 넛지 | 가로막는 것을 어떻게 해소하는가 |
이 다섯 도구는 이 글에서 다룬 다른 도구들과 맞물려 돌아갑니다. 전체 운영 흐름을 정리하면 이렇습니다.
- 개념 나침반으로 팀 사이의 개념 불일치를 측정한다.
- CLEAN 거버넌스로 비즈니스 로직, 협업, 지식, 활동이 조직 전체에서 어떻게 연결되는지를 매핑한다.
- 프로세스 맵으로 각 단계의 모호성을 드러내고, 성공 스펙트럼으로 현재 상태의 가치를 잡는다.
- 다관점 디자인으로 비즈니스/사용자/기술 관점의 차이를 파악하고, KPI를 붙여 측정 기준을 정한다.
- 문제 풍경으로 통점을 잡고, 넛지로 각 상태 전환의 마찰을 줄인다.
- 결과를 성공 스펙트럼에 다시 매핑하고, CLEAN 거버넌스를 다시 돌려서 다음 분기의 목표를 잡는다.
마무리
4편에서는 한 프로젝트의 합의가 다음 프로젝트로 이어지지 않는 문제를 다뤘습니다. 문서가 아니라 절차에 합의를 박아야 반복이 끊긴다는 전제에서 출발해, 네트워크 사고로 연결을 명시하고, CLEAN 거버넌스로 운영 절차를 잡고, 프로세스 맵으로 단계 단위 모호성을 드러내고, 성공 측정 도구 다섯 가지로 가치의 흐름을 추적하는 데까지 왔습니다.
이 도구들이 분기마다 순환하면, 한 프로젝트에서 잡은 합의가 다음 프로젝트의 출발선에 깔립니다. 매번 처음부터 다시 맞추는 대신, 지난 분기의 성공 스펙트럼 위에서 다음 분기의 목표를 잡고, 문제 풍경에서 줄어든 통점을 확인하고, CLEAN의 각 차원이 한 칸씩 앞으로 이동하는 흐름이 만들어집니다.
통합 데이터 전략 시리즈
(1) ‘진단’: 우리 조직은 어디가 정렬되지 않았는가