구조화된 데이터 디자인 전략이 중요한 이유: 예

배경

이전 두 기사에서는 데이터 기반 설계 시 고려 사항, 특히 비즈니스 데이터가 잠재적인 비즈니스 가치를 나타내는 방식에 대해 중점적으로 다루었습니다. 핵심 메시지는 구조화된 데이터 아키텍처가 내재적 가치를 추출할 수 있는 기술적 기반이라는 것입니다. 하지만 해당 기사들은 개념적 수준에서 관련 주제를 소개하는 데 초점을 맞췄습니다. 오늘은 좀 더 구체적이고 공감하기 쉬운 사례를 통해 이 개념을 설명하고자 합니다. 데이터 중심 사고방식에 맞춰 애플리케이션을 설계하는 방법에 대한 이야기를 들려드리겠습니다.

하지만 먼저, 왜 관심을 가져야 할까요?

하지만 바로 본론으로 들어가기에 앞서, 오늘날 데이터가 과거보다 왜 더 중요한지 다시 한번 살펴보겠습니다.  역사적으로 많은 기업은 데이터 수집과 저장을 주로 감사 및 규정 준수와 같은 거버넌스 목적으로 수행해 왔습니다. 따라서 역사적으로 데이터 수집 및 저장은 기업 운영에 대한 일종의 "세금"으로 여겨졌으며 직접적인 운영적 비즈니스 가치는 거의 인식되지 않았습니다.

이제 바뀐 점은 수집된 데이터를 활용해 비즈니스 프로세스를 최적화하고 고객 경험을 개선할 수 있다는 점을 더욱 확실히 이해하게 되었다는 것입니다. 예를 들어, 최근 디지털 소매업체 설문 조사에 따르면 이 두 가지 목표(비즈니스 프로세스 업그레이드 및 고객 경험)가 설문에 참여한 모든 사람의 57%에게 디지털 변환의 주요 동인이었습니다. 사업체 . 중요한 관찰, "왜 중요한가"의 본질은 데이터 기반 워크플로가 외부 도메인(예: 고객 경험)과 내부 도메인(핵심 비즈니스 프로세스) 모두에서 비즈니스에 영향을 미친다는 것입니다. 따라서 가장 중요한 비즈니스 워크플로의 품질과 비용 효율성을 강화하려면 신중하고 계획적인 데이터 전략이 필수입니다. 또한, 워크플로가 관찰된 데이터 배출을 데이터 수집 및 분석 인프라로 전송하도록 계측화되면 워크플로 자체도 지속적으로 분석하고 개선할 수 있으며, 그 결과 지속적으로 적응하고 최적화된 비즈니스 워크플로가 탄생합니다.

참고로, 디지털 전환과 관련하여 이들 기업이 가장 심각하게 우려했던 것은 이들 디지털 프로세스의 사이버 보안을 보장하는 것이었습니다. 이는 결국 이 동일한 데이터 원격 측정 및 분석 접근 방식이 핵심적인 역할을 하는 또 다른 영역입니다. 하지만 이는 다른 기사에서 다루도록 하겠습니다. 

신청서: 레스토랑 주문 및 배달

사고 실험으로 넘어가서, 저는 오늘날의 코로나바이러스에 적응한 라이프스타일에서 우리 중 많은 사람이 공감할 수 있는 이야기를 선택했습니다. 레스토랑 음식 주문 및 배달을 위한 온라인 서비스를 제공하는 애플리케이션입니다. 식사는 고객이 지정한 레스토랑에서 온라인으로 주문하며, 사용자는 고객이 직접 주문한 음식을 픽업하거나 서비스에서 배달받도록 선택할 수 있습니다.

이 스토리에서 우리는 애플리케이션 소유자의 역할을 맡게 될 것입니다. 그 역할에서 우리는 여러 가지 우려 사항을 해결해야 하며, 이를 두 가지 범주로 나눌 것입니다. 첫째, 필요한 운영 활동, 둘째, 미래 지향적 전략적 우려 사항입니다.

첫 번째 세트(필수 운영 활동)에는 다음과 같은 문제가 포함됩니다.

• 레스토랑 찾기 및 특징화(위치 및 영업 시간 포함)
• 메뉴 항목 및 가격에 대한 데이터 수집
• 레스토랑에 주문 알리기
• 결제 처리
• 주문을 픽업하고 배달할 인력의 가용성에 대한 데이터 유지
• 주문 준비 및 배송 상태 추적

두 번째 우려 사항은 일상 업무와는 관련이 없지만 그렇다고 해서 덜 중요한 것은 아닙니다. 이러한 문제를 미리 생각한다면 기업은 민첩하고 적응력 있게 행동하고 지속적으로 개선할 수 있습니다. 이런 종류의 우려 사항에 대한 예는 다음과 같습니다.

• 수요는 어떻게 예측할 수 있나요? 이는 단순히 일중/주중 시간대별 총 수요일 수도 있고, 레스토랑별처럼 더 세부적인 수치일 수도 있습니다.
• 어떤 종류의 도구, 프로세스 또는 워크플로가 공급업체(레스토랑)에 비즈니스 통찰력을 제공합니까?
• 음식이나 배달 가격을 어떻게 동적으로 조정할 수 있나요?
• 내 애플리케이션이 퍼블릭 클라우드에 호스팅된다고 가정할 때, 운영 인프라 비용을 어떻게 최적화할 수 있을까?

물론, 이는 우리가 가질 수 있는 모든 우려 사항의 일부에 불과하지만, 이 작은 집합만으로도 확장 가능한 데이터 처리 파이프라인을 지원하는 구조화된 데이터 아키텍처의 중요성을 강조하는 좋은 논의를 할 수 있기에 충분합니다.

데이터 아키텍처 또는 데이터 파이프라인/닭이 먼저냐 달걀이 먼저냐

애플리케이션 소유자의 역할을 가정하고 전반적인 데이터 전략을 고려하려면 먼저 비즈니스 워크플로를 나열하고 각각의 데이터 처리 요구 사항을 파악해야 합니다. 예를 들어 근처에 영업 중인 레스토랑을 찾아 각 레스토랑의 메뉴와 품목 가격을 제시하는 워크플로가 있습니다. 레스토랑을 위치와 영업 시간별로 필터링한 후, 특정 레스토랑의 메뉴를 찾아야 하며, 배달 기사의 가용성을 기준으로 필터링해야 할 수도 있습니다. 그리고 우리는 각 워크플로(결제 처리, 운전자와 배달 담당자 매칭 등)에 대해 이를 수행할 수 있습니다.

또는 마찬가지로 합리적으로 우리는 기본 데이터 "원자", 즉 필요한 데이터 구성 요소부터 고려를 시작할 수도 있습니다. 우리는 중요한 데이터 원자를 식별하고 열거하며, 특히 비즈니스 워크플로우를 지원하는 데 필요한 모든 메타데이터 어휘와 함께 해당 데이터 원자의 균일한 표현과 일관된 의미론을 갖는 데 특히 주의를 기울였습니다. 샘플 애플리케이션에서 데이터 원자의 예로는 다음이 있습니다. 레스토랑, 고객 및 운전자의 위치 데이터 , 메뉴 및 송장에 필요한 음식 항목 , 배달 품질을 필터링하고 추적하는 데 사용되는 시간 , 고객 및 운전자 결제 워크플로와 관련된 결제 정보 입니다.

워크플로의 데이터 처리 파이프라인 또는 대안적으로 데이터 "원자" 중 어느 것을 데이터 전략에 사용할 것인지는 닭이 먼저냐 달걀이 먼저냐의 문제입니다. 두 관점 모두 유용하며, 더 중요한 것은 상호 의존적이라는 것입니다. 기본 데이터 원자에 대해 생각하지 않고는 데이터 처리 파이프라인에 대해 추론할 수 없고, 처리 파이프라인의 요구 사항을 고려하지 않고는 데이터 아키텍처를 개발할 수 없습니다. 하지만 일반적으로 저는 워크플로를 먼저 통과하여 데이터 원자를 열거한 다음, 데이터 파이프라인의 세부 설계를 하기 전에 데이터 아키텍처의 구조적 설계에 접근하는 방식을 권장합니다. 워크플로가 더 동적인 이유는 비즈니스가 발전함에 따라 워크플로가 추가되고 수정되는 반면, 기반 데이터에는 더 많은 이력 및 관성이 있기 때문입니다. 따라서 데이터 아키텍처는 사전에 고려하는 것이 더 중요합니다.

구체적인 사례에 대한 전체적 데이터 아키텍처 및 파이프라인 접근 방식 적용

다시 예시로 돌아가서, 애플리케이션 소유자로서 우리는 핵심 비즈니스 핵심 워크플로와 이를 지원하는 데 필요한 데이터 원자에 대한 관점을 상당히 잘 알고 있다고 가정해 보겠습니다. 앞서 논의한 내용에서 우리는 워크플로에 필요한 몇 가지 기본 데이터 요소, 즉 위치, 시간, 음식 항목, 결제 정보를 파악했습니다. 이전 기사의 내용을 요약하자면, 데이터 아키텍처는 구문의 균일성, 의미의 일관성, 데이터에 대한 추론과 관리를 위한 메타데이터 어휘라는 3가지 핵심 목표를 달성할 수 있어야 합니다. 따라서 이제 우리는 이러한 원칙을 적용하여 오늘의 예에서 열거된 특정 데이터 원자에 대한 데이터 아키텍처 고려 사항을 논의할 수 있습니다.

위치 데이터 원자에 초점을 맞춰 3가지 핵심 데이터 아키텍처 목표를 고려해 보겠습니다.

• 첫째, 균일한 데이터 표현 구문은 무엇입니까?
  첫 번째 생각은 거리 주소로 위치를 나타내는 것입니다. 왜냐하면 그것이 일반적으로 레스토랑과 고객이 자신의 위치를 나타내는 방법이기 때문입니다. 하지만 배달하는 운전자를 추적하기 위한 위치 요구 사항을 고려해 보세요. 운전자는 종종 이동 중이거나 주요 고속도로에 있거나 거리 주소로 잘 설명되지 않는 위치에 있을 수 있습니다. 대신 위도와 경도를 지정하는 것이 해당 워크플로의 위치를 나타내는 더 나은 방법일 수 있으며, 이 형식은 여전히 레스토랑 및 고객 위치에도 적합합니다. 하지만 운전자는 일반적으로 레스토랑이나 고객 위치로 길을 찾아야 하므로 운전자의 (위도/경도) 위치와 고객의 (도로 주소) 위치를 연관시킬 수 있는 방법이 여전히 필요합니다. 따라서 더 신중하게 고려된 선택은 모든 위치 데이터를 위도 및 경도로 정규화하는 것(필수적인 "표준" 표현)일 수 있지만, 거리 주소가 처음 제공될 때 거리 주소를 위도/경도로 변환하는 기능("수집" 워크플로)을 제공하는 것입니다.
• 두 번째로 고려해야 할 사항은 일관된 의미론 입니다. 
  위치가 위도/경도로 정규화되었다고 가정하면 이는 모호하지 않은 해석이 가능한 잘 확립된 표준이기 때문에 비교적 간단합니다. 그러나 일관된 의미론의 또 다른 측면은 정밀도, 즉 암묵적으로 암시되는 데이터의 정확성과 관련이 있습니다. GPS 및 매핑 데이터의 정확도는 암묵적으로 제한적이므로 데이터 소스의 품질에 따라 일정한 정밀도(예: 가장 가까운 초각, 약 100피트)로 위치를 지정하거나 가변 정밀도로 위치를 지정할 수 있습니다. 유연성을 위해 후자를 선택하는 경우 다음에 설명하는 메타데이터를 사용하여 각 위치 데이터 인스턴스의 정밀도를 주석으로 표시해야 합니다.
• 데이터 아키텍처의 세 번째 목표는 수집된 데이터 요소에 주석을 달고 풍부하게 만들 수 있는 기능을 갖추는 것입니다.
  위치의 경우, 앞서 언급한 대로 데이터의 정확도가 포함될 수 있습니다. 하지만 추가적으로 인간 친화적인 측면, 특히 수집된 주소 데이터를 보존하기 위해 위치에 거리 주소를 주석으로 달고 싶을 수도 있습니다. 이것은 여러 개의 주소가 동일한 위도/경도에 매핑되는 경우(아파트 단지 등)에 특히 중요합니다. 또 다른 강화 기능으로는 위치 데이터 필드가 수집된 타임스탬프가 있는데, 이는 위치 데이터가 빨리 오래되어 버리는 운전 중인 운전자에게 유용할 수 있습니다.

우리는 위치 에 대한 요구 사항에 대해서만 이야기했으며 이제 다른 데이터 필드에 대해서도 비슷한 연습을 실시할 수 있습니다. 그러나 각 데이터 원자에 대한 모든 우려 영역을 나열하는 대신 몇 가지 주목할 만한 관찰 결과를 강조하겠습니다.

• 시간 데이터 원자에 관하여: 시간 가치의 표현은 매우 까다롭기로 악명 높다. 구문적으로(예: 24시간 형식 대) 다를 수 있습니다. 12시간제에 오전/오후를 더한 것)과 의미적으로(예: 시간대 개념 및 일광 절약 시간제 관찰에 따른 변화). 따라서 시간 표현은 정규화되어야 할 가능성이 높습니다(예: GMT로 정규화하거나 Unix/Linux 사용자의 경우 "시대 이후" 초).
• 음식 항목 데이터 인스턴스는 매우 다양할 수 있으며 고유한 요구 사항이 있습니다. 데이터 원자는 종종 자유형이기 때문에 통일된 구문을 사용하는 것보다 표준 메타데이터 어휘집이 더 유용합니다. 일부 메타데이터 필드는 "차갑게 유지해야 함" 또는 "견과류 포함"과 같은 항목별 정적 속성을 위한 것이지만, "매운 정도" 또는 "선호하는 조미료"와 같은 인스턴스별(주문별) 식품 항목 정보에 필요한 다른 메타데이터 필드도 있습니다. 어느 경우든, 디자인 목표는 메타데이터 필드에 대해 통일된 구문과 일관된 의미 체계를 갖는 것인데, 이를 통해 전체 메뉴 항목 인벤토리에서 공유될 수 있습니다.
• 또 다른 주요 고려사항은 데이터 규정 준수와 거버넌스입니다. 한 가지 측면은 데이터 보존 정책으로, 고객의 IP 주소나 운전자의 위치 기록 등 일부 필드는 단기간 동안만 보존될 수 있습니다. 또 다른 일반적인 고려사항은 일부 필드에는 보안이나 개인정보 보호 제약이 있을 수 있다는 것입니다. 예를 들어 결제 정보가 있습니다. 메타데이터 증강은 두 가지 경우 모두에 대한 해결책입니다. 메타데이터는 데이터 보존을 위해 IP 주소나 위치 값에 데이터 만료 시간을 주석으로 표시하는 데 사용해야 합니다. 결제 정보의 경우 메타데이터를 사용하여 보안 요구 사항(예: 저장 중인 데이터 암호화 필요성 또는 영구 데이터 저장소의 지리적 위치 제약 조건 지정)을 전달할 수 있습니다.

이 사례는 아직 피상적으로만 보여졌을 뿐이지만, 현실 세계 시나리오와 관련된 많은 문제점을 부각시켰습니다. 그러나 현실 세계에서 데이터 전략을 고민하는 과정은 여기서 끝나지 않고 반복적이고 지속적입니다. 데이터 요소가 비즈니스 워크플로를 구현하는 데이터 처리 파이프라인에 입력됨에 따라 데이터 아키텍처에 대한 반복적인 조정 및 개선이 이루어집니다. 기존 워크플로가 향상되고 새로운 워크플로가 추가됨에 따라 새로운 데이터 아톰과 함께 기존 데이터 아톰에 대한 추가적인 데이터 아키텍처 요구 사항도 발견하게 될 것입니다.

마무리 생각

이 예시는 간결성을 위해 간소화되었지만 여전히 워크플로를 데이터 아키텍처에 미치는 영향에 매핑하는 데 있어서 핵심 원칙을 보여줍니다. 이 과정은 항상 비즈니스 요구 사항, 즉 고객 경험과 해당 요구 사항을 충족하는 데 필요한 비즈니스 프로세스를 고려하는 것으로 시작됩니다. 다시 말해, 비즈니스 프로세스는 비즈니스 어휘의 요소를 정의합니다. 다음 단계의 구체성에서는 프로세스가 데이터 파이프라인에 매핑되어 데이터 어휘를 활용합니다. 

핵심 원칙은 구문, 의미론, 주석을 정의하는 강력한 데이터 아키텍처가 데이터 파이프라인을 효율적으로 개선하고 새로운 워크플로를 쉽게 추가할 수 있는 기반을 구축한다는 것입니다. 비즈니스 계층 추상화에서는 기존 비즈니스 프로세스를 쉽게 수정할 수 있으며 새롭거나 떠오르는 비즈니스 프로세스를 신속하게 온라인으로 전환할 수 있음을 의미합니다. 반대로, 데이터 어휘, 데이터 아키텍처 프레임워크 또는 이를 비즈니스 요구 사항과 연결하는 영역 중 어느 하나에서 신중한 결정을 내리지 못하면 궁극적으로 취약하고 불안정한 시스템이 되어 새로운 비즈니스 요구 사항에 민첩하게 대응할 수 없게 됩니다.