Data Catalog, 데이터경험의 심리학 법칙

reckoner
11 min readNov 20, 2022

--

https://cdn-images-1.medium.com/max/1440/1*VKzPws0T9MFTeIk9FsXjOg.png

https://us.semantix.ai/

데이터 카탈로그?

물류 네트워크는 상품을 판매자로부터 구매자에 전달합니다. 배송경로는 복잡하게 얽혀 있으나 상품의 이동상황은 정확히 추적되어야 하고 기능/비용상의 최적화는 지속적으로 이루어져야 합니다.

데이터플랫폼도 동일한 관리가 필요합니다. 다양한 지점에서 수집된 데이터는 여러단계의 처리를 통해 통합/분리되어 최종 소비자에게 전달됩니다. 늘어나는 수집 데이터와 복잡해지는 처리과정에서 필요한 데이터를 탐색하고, 생성과정과 품질 수준을 빠르게 파악할 필요성은 점차 높아집니다. 이러한 이유로 Data Catalog는 이제 각 솔루션 업체의 플랫폼 소개에 빠지지 않고 등장합니다.

현재의 데이터카탈로그 제품은 3.0이라는 세일즈 명칭아래 Table 탐색을 넘어 협업도구의 기능까지 강조하는데 여기서는 현 회사들의 도입 수준인 2.0 ( LinkedIn’s DataHub, Lyft’s Amundsen ) 기준으로 이야기를 진행합니다.

사업담당자로써 경험하는 Data Catalog

잘 관리된 Data Catalog가 데이터조직에게 제공하는 가치는 매우 큽니다.

데이터 생성 과정 확인을 위해 필요했던 커뮤니케이션을 제거하고 장애지점과 영향 대상 파악을 용이하게 하며 데이터 생애주기 관리를 명시적으로 드러냅니다. 명확하게 기입된 tag, comment는데이터 탐색 비용을 절감하고 데이터 담당자 간 협업의 질을 개선시켜줍니다.

그렇다면 엄격하게 관리된 Data Catalog는 조직 전체의 데이터 활용을 향상시킬까요?

데이터 추출이 필요한 제품/사업담당자를 상상해 보겠습니다.

  • 담당자1: OO 상품 구독 매출 관리
  • 담당자2: 전체 구독 상품의 신규/리텐션 마케팅 관리

> 담당자1의 정보 탐색 흐름

OO상품의 구독 여부, 결제 구매 -> 해당 기간 실행 프로모션 정보 -> 전체 상품의 매출정보 -> 기여분 확인

> 담당자2의 정보 탐색 흐름

전체 구독 상품의 구독 상태 -> 3개월 이전 가입상태 + 3개월 기간 중 구독 현황 -> 고객 별 마케팅 유입채널 확인 -> 주 대상 고객 속성 확인

결국 Data Catalog를 사용한 두 담당자는 동일한 어려움을 경험하게 됩니다.

  • 검색어에 따른 테이블 목록 제공 -> 테이블의 선별과 그룹화 단계 필요
  • 총 정보 포괄 -> 직접 그룹화 한 테이블의 신뢰성 확인 필요
  • 검색 0건의 결과 -> 올바른 키워드의 확인

UX/UI의 10가지 심리학 법칙으로 Data Catalog 한계 엿보기

<UX/UI의 10가지 심리학 법칙>은 디자인 의사결정을 위한 근거를 심리학으로 설명하는 책 입니다. 사용자의 관점에서 디자인의 기준을 세운 사례를 소개하고 있습니다. Data Catalog가 사업조직에서 활용되기 어려운 이유 또한 참고해 볼 수 있었습니다.

  1. 제이콥의 법칙: 자신이 이미 알고 있는 서비스들과 같은 방식으로 서비스가 작동하기를 원한다.
  2. 밀러의 법칙: 작업기억에는 7가지 정도의 정보만 담겨질 수 있다. 정보는 덩어리(그룹화)로 기억되고 계층화 될 필요가 있다.
  3. 피츠의 법칙: 대상에 도달하는 시간은 대상까지의 거리 + 대상 크기와 함수 관계에 있다.
  4. 포스텔의 법칙: 자신의 일은 엄격하게, 남의것은 너그럽게, 다양한 사용자의 환경을 정확한 원칙하에 지원해야한다.
  5. 테슬러의 법칙: 복잡성 보존의 법칙, 모든 시스템에는 더이상 줄일 수 없는 일정수준의 복잡성이 있다.

이를 Data Catalog에 투영해보면 다음의 제약이 명확히 드러납니다.

1. 테이블 목록 제시 vs 검색엔진 경험 (제이콥의 법칙)

Data Catalog의 interface상 기본 단위는 테이블입니다. 검색어에 맞추어 관련 tag, comment, description을 가진 테이블이 나열되는데, 이는 사업 담당자에게는 매우 어색한 동작방식입니다. 우리가 정보를 파악해가는 과정은 하나의 맥락 아래 큰 개념에서 작은 개념으로, 상위 개념에서 하위의 개념으로 이루어지나 나열된 정보는 계층단위로 제시되지 않습니다.

2. 평평한 정보 vs 계층화 된 정보 (밀러의 법칙, 피츠의 법칙)

밀러의 법칙을 참고하면, 테이블 목록은 ‘덩어리’로써 계층화 하여 제시될 필요가 있습니다. 피츠의 법칙은 터치 대상이 충분히 크고, 그 간격 또한 실수가 없도록 배치될 것을 강조하는데, ‘정보 덩어리’의 최상위 계층이 가장 자주 사용되는 사업개념으로 구성되어야 함을 생각해 볼 수 있습니다. 다른 의미로 하위계층의 정보는 적절하게 숨겨지되 어떤 정보가 존재하는지는 쉽게 인지할 수 있어야 한다는 의미이기도 합니다.

3. 탐색 실패의 대응 (포스텔의 법칙)

또다른 Data Catalog의 제약은 원하지 않는 결과, 검색의 실패가 빈번하다는 것입니다. 책에서 포스텔의 법칙은 reactive web의 사례를 들며 다양한 브라우저, 모바일 기기에 맞추어 제품 UI가 탄력적으로 변화되는 예를 듭니다.

사업조직의 데이터 탐색 또한 다양합니다. 각 부서마다 자주 쓰는 사업적 개념과 목표, 필요한 정보가 다르기 때문인데 이 문제는 기술적으로 해결되지 않는 부분입니다. 검색실패를 기록으로 남기고 점진적 개선을 시도해 볼 수도 있겠습니다. 하지만 이는 Data Catalog 운영과는 별개의 활동으로 Product 관리 차원의 비용을 필요로 합니다.

4. 사업담당자가 감수해야만 할 복잡성 (테일러의 법칙)

높은 수준으로 Data Catalog가 관리되더라도, 하나의 통합테이블이 구성되더라도 더이상 줄일 수 없는 간극은 존재합니다. 사업전략이 참고할 데이터 계층 구조, 활용해야 할 주요 테이블에 담긴 정보, 주요 테이블 간의 맥락적 관계는 사업담당자의 머릿속에 위치해야 할 필요가 있습니다. 이를 기반으로 사고하고 데이터를 추출하는 활동은 제외되어서는 안됩니다. 이는 전략적 사고의 질을 높이기 위해서라도 필수적인 부분입니다.

솔루션은 없다, 사람이 해결 중인 현업

이쯤 되면 Data Catalog의 한계는 과연 풀 수 있는 문제인가 라는 의구심마저 들게 합니다. 반면 데이터를 활용하는 스타트업과 조직은 끊임없이 늘어나고 있습니다. 데이터 탐색과 추출의 문제는 어떻게 해결되고 있을까요?

정답은 사람입니다. 사업/제품 조직에 위치하거나 중앙의 데이터분석팀에 위치한 데이터분석가가 Data Catalog로써 기능하고 있습니다. 대부분의 분석가는 insight 추출과는 별도의 업무로써 요청 받은 데이터를 여러채널에 문의하여 파악하고, 이를 종합하여 하나의 excel sheet로 제공하는 업무에 50% 이상의 시간을 할애하고 있을 가능성이 높습니다.

시간이 지날수록 이들의 지식은 강화되고 탐색속도는 빨라지고 기여하는 협업자에 의해 데이터카탈로그 는 제한적이나마 유용한 정보가 점차 쌓여갑니다. 그러나 데이터 기반의 전략적 사고는 향상되지 않습니다.

여기서 다시 제이콥의 법칙: 서비스는 같은 방식으로 동작하기를 기대

<사람에게 요청 -> CSV 결과물 전달>의 구조는 사업담당자로써는 가장 적은 리소스로 가장 완결성 있는 정보를 얻는 형태이기 때문에 쉽게 변화되기 매우 어렵습니다. 강제되더라도 명시적인 결과가 즉각적으로 나타나지 않기 때문에 소란이 크게 발생합니다. 예전 몸 담았던 조직에서는 SQL의 강제교육이라는 심리보다 행동에 대한 강제를 수행했었는데 매우 큰 저항과 불만이 있었던것을 기억합니다.

Data Catalog 는 사업전략과 고객행동 결과의 교차점

사람이 해결하는 구조의 부채, 멀어지는 사업과 시장의 간극

때로 편안함은 수동적인 사고를 형성합니다. 수도관으로써의 파이프라인은 단 방향으로 정보를 전달하고 상수처리된 최종상태의 dataset은 소비됩니다. 소프트웨어로써의 파이프라인은 데이터의 품질, 접근성, 보안, 제공 API 등 기술적으로 고도화 되며 신뢰있는 시스템으로 발전합니다. 그러나 공급자는 사업 젼략상 강화되어야 할 데이터, 비어있지 않아야 할 데이터를 정의하지는 못합니다.

해결 방법: 기술적 경계 인정, 양방향 데이터 공급

아쉽지만 현재 사람이 해결하는 구조는 오랫동안 변화하지 못할 것으로 예측됩니다. 그러나 생산성을 개선하고 조금 즐겁게 업무를 변경해 볼수는 있을 것 같습니다.

1. data catalog 활용의 적극적 참여, 생산성 개선

정확하게 해둘 점은 Data Catalog는 데이터조직 내의 최적화로써 기능한다는 점입니다. 이점을 명확히 해두고 살펴보면 데이터엔지니어만이 아닌 분석가도 얻어낼 이득은 다양합니다. 특히 lineage와 데이터품질 모니터링은 기존의 커뮤니케이션 비용은 크게 절감해 줄 수 있습니다.

동시에 data catalog가 완벽하지 않을것을 인정하고 공통의 파이프라인을 규정하고 집중할 필요가 있습니다.애초에 column에 기입된 comment는 후행적인 것으로써 기간이 만료된 정보가 될 소지가 높습니다. 자동화, 변화하는 데이터시스템, 각 영역의 새로운 data format은 반복적인 위협이 됩니다.

2. 사업전략상의 최상위 ‘덩어리’와 계층화를 끊임없이 질문

데이터분석가는 보통은 요청에 대한 답을 제시하는 역할입니다. 고된 역할이지만 흥미로운 위치이기도 한데 사업담당자에게 직접적으로 질문할 수 있는 위치이기도 합니다. 어떤 고객가치를 생각하고 어떻게 계층화하여 머릿속에 가지고 있는지 확인해 볼 수 있습니다.

만약 개념적 완결성이 부족하다면 함께 user persona를 정의하거나 테스트계획을 수립하여 검증해 갈 수 있습니다.

3. 데이터 탐색/추출의 의도적 위임

친절함의 경계가 세워질 필요도 있습니다. 제품/사업 담당자가 중앙의 Data Catalog를 직접적으로 소비할 필요는 없겠으나 Data에서 가용한 정보를 인지할 필요는 있습니다. 기본적 데이터 추출은 위임하고 insight 발굴로 스스로 업무를 조정할 필요가 있습니다.

Data Engineering의 가치 = Dataset, ≠ Data Pipeline

Data Catalog의 시작점은 transparent 한 데이터파이프라인과 single source of truth 관리를 위한 목적에서 출발했습니다. 많은 솔루션 업체들은 오랫동안 해결되지 않을 고통지점임을 알기에 Data Catalog를 활용한 제품소개와 판매에 집중하는 모양새입니다. 덕분에 매우 빠르게 데이터플랫폼의 기능요소로 정착하고 운영 상 필수적인 규약이 될 가능성도 높아보입니다.

하지만 잊지 말아야 할것은 높은 수준의 데이터파이프라인과 엄격하게 관리되는 카탈로그는 그 자체로써는 가치를 제공하지 못한다는 점입니다. 데이터엔지니어링의 가치는 Dataset으로 결정됩니다. 데이터조직 내의 기능적 Catalog와 제품/사업조직의 전략상의 Catalog를 끊임없이 충돌시켜야 하는 이유입니다.

이전 글 보기

참고

--

--