구조화된 데이터 설계 전략이 중요한 이유: 사례로 알아보기

F5 에코시스템 | 2020년 10월 19일

배경

앞선 두 편의 글에서는 데이터 기반 설계 시 고려해야 할 사항, 특히 비즈니스 데이터가 잠재적인 비즈니스 가치를 어떻게 나타내는지에 초점을 맞췄습니다. 핵심 메시지는 구조화된 데이터 아키텍처가 이러한 내재적 가치를 끌어낼 수 있게 해주는 기술적 토대라는 것이었습니다. 다만 이전 글들은 관련 주제를 개념적 차원에서 소개하는 데 중점을 두었습니다. 오늘은 좀 더 구체적이고 공감하기 쉬운 예시를 통해 이러한 개념을 살펴보고자 합니다. 즉, 데이터 우선 사고방식에 부합하는 애플리케이션 아키텍처를 어떻게 구상할 수 있는지에 관한 이야기입니다.

하지만 먼저—왜 이게 중요할까요?

하지만 본론으로 바로 들어가기 전에, 오늘날 데이터가 과거보다 더 중요해진 이유를 되짚어 보겠습니다. 역사적으로 많은 기업은 감사 및 규정 준수와 같은 거버넌스상의 이유로, 주로 데이터 자체를 보관하는 데 목적을 두고 데이터를 수집하고 저장해 왔습니다. 따라서 데이터 수집과 저장은 실질적인 비즈니스 운영 가치가 거의 없는, 기업 운영에 부과되는 일종의 ‘세금’으로 여겨져 왔습니다.

이제 달라진 점은 수집된 데이터를 활용해 비즈니스 프로세스를 최적화하고 고객 경험을 개선할 수 있다는 인식이 한층 확산되었다는 것입니다. 예를 들어, 최근 디지털 소매 기업을 대상으로 실시한 설문 조사에 따르면 비즈니스 프로세스와 고객 경험의 개선이라는 두 가지 목표가 전체 조사 대상 기업 중 57%에서 디지털 혁신을 추진하는 주된 동력이었습니다. 여기서 핵심적으로 주목해야 할 점, 즉 ‘이것이 왜 중요한가’의 본질은 데이터 기반 워크플로가 고객 경험과 같은 대외 영역뿐 아니라 핵심 비즈니스 프로세스와 같은 내부 영역에서도 비즈니스에 영향을 미친다는 것입니다. 따라서 가장 중요한 비즈니스 워크플로의 품질과 비용 효율성을 확보하려면 신중하고 체계적인 데이터 전략이 필수적입니다. 또한 워크플로에서 생성되는 관측 데이터를 데이터 수집 및 분석 인프라로 전송하도록 계측하면 워크플로 자체를 지속적으로 분석하고 개선할 수 있으며, 그 결과 끊임없이 적응하고 최적화되는 비즈니스 워크플로를 구현할 수 있습니다.

참고로, 이들 기업이 디지털 혁신과 관련해 가장 크게 우려한 점은 바로 이러한 디지털 프로세스의 사이버 보안을 확보하는 것이었습니다. 알고 보면 이 역시 동일한 데이터 텔레메트리 및 분석 접근 방식이 핵심적인 역할을 하는 또 다른 영역이지만, 이에 관한 이야기는 다른 글에서 다루겠습니다.

애플리케이션: 레스토랑 주문 및 배달

이제 사고 실험으로 넘어가 보겠습니다. 오늘날 코로나바이러스에 적응한 생활 방식 속에서 많은 분이 공감할 만한 사례로, 음식점 음식 주문 및 배달을 위한 온라인 서비스를 제공하는 애플리케이션을 선택했습니다. 고객이 지정한 음식점에서 온라인으로 음식을 주문하며, 사용자는 직접 주문한 음식을 찾아가거나 서비스에서 배달까지 해 주도록 선택할 수 있습니다.

이 이야기에서 우리는 애플리케이션 소유자 역할을 맡게 됩니다. 이 역할에서는 다양한 사안을 다뤄야 하며, 이를 두 가지 범주로 나누겠습니다. 첫째는 필수 운영 활동이고, 둘째는 미래 지향적인 전략적 사안입니다.

첫 번째 범주인 필수 운영 활동에는 다음과 같은 고려 사항이 포함됩니다:

위치와 영업시간을 포함한 음식점 정보 검색 및 특성 파악
메뉴 항목 및 가격 데이터 수집
레스토랑에 주문 내역 전달
결제 처리
주문 상품을 픽업하고 배송할 인력의 가용성에 관한 데이터 관리
주문 준비 및 배송 상태 추적

두 번째 고려 사항은 일상적인 운영과는 다소 거리가 있지만, 그 중요성은 결코 덜하지 않습니다. 이러한 문제를 사전에 고려하면 비즈니스가 민첩성과 적응력을 갖추고 지속적으로 개선될 수 있습니다. 이러한 고려 사항의 예는 다음과 같습니다:

수요를 어떻게 예측할 수 있을까요? 시간대별 또는 요일별 총수요를 단순히 예측할 수도 있고, 음식점별로 더 세분화해 예측할 수도 있습니다.
공급업체(레스토랑)에 비즈니스 인사이트를 제공하려면 어떤 도구, 프로세스 또는 워크플로를 활용할 수 있나요?
음식 또는 배달 요금을 어떻게 동적으로 조정할 수 있을까요?
애플리케이션이 퍼블릭 클라우드에서 호스팅된다고 가정할 때, 운영 인프라 비용을 어떻게 최적화할 수 있을까요?

물론 이는 우리가 고려해야 할 다양한 사항 중 일부에 불과하지만, 이처럼 범위를 좁힌 항목만으로도 확장 가능한 데이터 처리 파이프라인을 지원하는 구조화된 데이터 아키텍처의 중요성을 부각하는 유익한 논의를 진행하기에 충분합니다.

데이터 아키텍처인가, 데이터 파이프라인인가/닭이 먼저인가, 달걀이 먼저인가

애플리케이션 소유자라는 가상의 역할에서 전반적인 데이터 전략을 검토할 때, 먼저 비즈니스 워크플로를 열거하고 각 워크플로의 데이터 처리 요구 사항을 파악할 수 있습니다. 예를 들어 현재 영업 중인 인근 음식점을 찾은 다음 각 음식점의 메뉴와 항목별 가격을 보여 주는 워크플로가 있습니다. 이 워크플로에서는 위치와 영업시간을 기준으로 음식점을 필터링한 뒤, 사용자가 선택한 특정 음식점의 메뉴를 조회해야 하며, 경우에 따라 배달 기사 배정 가능 여부를 기준으로 추가 필터링할 수도 있습니다. 결제 처리, 배달과 기사 연결 등 각각의 워크플로에 대해서도 이와 같은 작업을 수행할 수 있습니다.

또는 마찬가지로 합리적인 접근으로, 필요한 데이터 구성 요소인 기본 데이터 ‘원자’부터 검토를 시작할 수도 있습니다. 중요한 데이터 원자를 식별하고 열거하되, 비즈니스 워크플로를 지원하는 데 필요한 메타데이터 어휘와 함께 이러한 데이터 원자가 통일된 방식으로 표현되고 일관된 의미를 갖도록 하는 데 특히 주의를 기울여야 합니다. 예제 애플리케이션의 데이터 원자로는 다음과 같은 것들이 있습니다. 레스토랑, 고객, 배달 기사의 위치 데이터, 메뉴와 청구서에 필요한 음식 항목, 배달을 필터링하고 배달 품질을 추적하는 데 사용되는 시간, 그리고 고객 및 배달 기사 결제 워크플로와 관련된 결제 정보입니다.

데이터 전략의 출발점으로 워크플로의 데이터 처리 파이프라인과 데이터 ‘원자’ 중 어느 쪽을 택할지는 닭이 먼저냐 달걀이 먼저냐의 문제입니다. 두 관점 모두 유용하며, 더 중요한 것은 서로 의존한다는 점입니다. 기반이 되는 데이터 원자를 고려하지 않고 데이터 처리 파이프라인을 논할 수 없으며, 처리 파이프라인의 요구 사항을 고려하지 않고 데이터 아키텍처를 설계할 수도 없습니다. 그렇지만 일반적으로는 먼저 워크플로 전반을 훑어 데이터 원자를 열거한 다음, 데이터 파이프라인을 세부적으로 설계하기 전에 데이터 아키텍처의 구조화된 설계에 착수하는 접근 방식을 권장합니다. 워크플로는 더 역동적이기 때문입니다. 비즈니스가 발전함에 따라 워크플로는 추가되고 수정되는 반면, 기반 데이터에는 더 많은 역사와 관성이 있으므로 데이터 아키텍처는 사전에 충분히 숙고할수록 더 큰 이점을 얻습니다.

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

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

Zooming in on the 위치 데이터 원소를 자세히 살펴보면서 데이터 아키텍처의 3가지 핵심 목표를 각각 고려해 보겠습니다.

첫째, 통일된 데이터 표현 구문은 무엇일까요?
처음에는 음식점과 고객이 일반적으로 위치를 나타내는 방식인 도로명 주소로 위치를 표현하는 것이 좋겠다고 생각할 수 있습니다. 하지만 배달 중인 기사의 위치를 추적하는 데 필요한 사항을 고려해 보세요. 기사는 이동 중인 경우가 많으며, 주요 고속도로 위에 있거나 도로명 주소로 정확히 설명하기 어려운 장소에 있을 수도 있습니다. 따라서 이 워크플로에서는 위도와 경도로 위치를 나타내는 것이 더 나을 수 있으며, 이 형식은 음식점과 고객의 위치에도 사용할 수 있습니다. 그러나 기사는 일반적으로 음식점이나 고객의 위치로 이동해야 하므로, 기사의 위치(위도/경도)를 고객의 위치(도로명 주소)와 연결할 방법이 여전히 필요합니다. 따라서 더 신중한 선택은 모든 위치 데이터를 위도와 경도로 정규화하여 필수적인 ‘표준’ 표현으로 사용하되, 도로명 주소가 처음 제공될 때 이를 위도/경도로 변환할 수 있도록 하는 것일 수 있습니다(‘수집’ 워크플로).
두 번째로 고려할 사항은 일관된 의미 체계입니다.
위치가 위도/경도로 정규화된다고 가정하면, 이는 명확하게 해석할 수 있는 잘 정립된 표준이므로 비교적 간단합니다. 그러나 일관된 의미 체계에서 고려해야 할 또 다른 측면은 정밀도, 즉 데이터가 암시하는 정확성입니다. GPS 및 지도 데이터는 본질적으로 정확도에 한계가 있으므로, 데이터 소스의 품질에 따라 위치를 일정한 정밀도(예: 가장 가까운 각초 단위, 약 100피트)로 지정하거나 가변 정밀도로 지정할 수 있습니다. 유연성을 위해 후자를 선택한다면, 다음에 설명할 메타데이터를 사용하여 각 위치 데이터 인스턴스의 정밀도를 명시해야 합니다.
데이터 아키텍처의 세 번째 목표는 수집된 데이터 요소를 주석 처리하고 보강할 수 있는 역량을 갖추는 것입니다.
위치 데이터의 경우 앞서 언급했듯이 데이터의 정밀도를 포함할 수 있습니다. 또한 사람이 쉽게 이해할 수 있도록 위치에 도로명 주소를 주석으로 추가할 수 있으며, 특히 수집된 주소 데이터를 보존하는 데 유용합니다. 이는 아파트 단지처럼 여러 도로명 주소가 동일한 위도/경도에 매핑될 수 있는 경우에 특히 중요합니다. 또 다른 보강 정보로는 위치 데이터 필드가 수집된 시점을 나타내는 타임스탬프가 있을 수 있습니다. 이동 중인 운전자의 경우 위치 데이터가 빠르게 오래된 정보가 될 수 있으므로 이 정보가 중요할 수 있습니다.

지금까지는 위치에 대한 요구 사항만 살펴보았으며 이제 다른 각 데이터 필드에 대해서도 비슷한 방식으로 검토할 수 있습니다. 하지만 각 데이터 요소와 관련된 모든 고려 사항을 일일이 열거하기보다는, 몇 가지 주목할 만한 사항을 짚어보겠습니다:

Regarding the 시간 데이터 원자와 관련하여: 시간 값을 표현하는 것은 매우 까다롭기로 유명합니다. 구문적으로(예: 24시간제와 12시간제+오전/오후)도, 의미적으로(예: 시간대의 개념 및 일광 절약 시간제 적용에 따른 차이)도 달라질 수 있습니다. 따라서 시간 표현은 GMT로 정규화하거나 Unix/Linux 사용자의 경우 ‘에포크 이후 경과한 초’로 나타내는 등의 방식으로 표준화해야 할 가능성이 큽니다.
음식 항목 데이터 인스턴스는 고유한 요구 사항에 따라 매우 다양할 수 있습니다. 이러한 데이터 원자는 형식이 자유로운 경우가 많으므로, 구문을 통일하려 하기보다는 표준 메타데이터 어휘를 사용하는 편이 더 유용합니다. 일부 메타데이터 필드는 “차갑게 유지해야 함” 또는 “견과류 함유”와 같은 항목별 정적 속성을 나타내는 데 사용되지만, “매운맛 정도” 또는 “선호하는 양념”과 같은 인스턴스별(주문별) 음식 항목 정보를 나타내려면 다른 메타데이터 필드가 필요합니다. 어느 경우든 메뉴 항목의 전체 목록에서 메타데이터 필드를 공통으로 사용할 수 있도록, 설계 목표상 해당 필드의 구문을 통일하고 의미를 일관되게 유지해야 합니다.
그 밖의 주요 고려 사항으로는 데이터 규정 준수와 거버넌스가 있습니다. 그중 하나는 데이터 보존 정책으로, 고객의 IP 주소나 배달 기사의 위치 기록과 같은 일부 필드는 짧은 기간 동안만 저장할 수 있습니다. 또 다른 일반적인 고려 사항은 일부 필드에 보안 또는 개인정보 보호 제약이 적용될 수 있다는 점이며, 그 예로는 결제 정보가 있습니다. 메타데이터 보강은 두 경우 모두에 대한 해결책입니다. 데이터 보존을 위해 메타데이터를 사용하여 IP 주소나 위치 값에 데이터 만료 시간을 명시해야 합니다. 결제 정보의 경우 메타데이터를 사용하여 저장 데이터 암호화 필요성과 같은 보안 요구 사항을 전달하거나 영구 데이터 저장소의 지리적 위치 제약 조건을 지정할 수 있습니다.

이 예시는 여전히 겉핥기 수준에 불과하지만, 실제 시나리오와 관련된 여러 고려 사항을 잘 보여 주었습니다. 그러나 현실에서는 데이터 전략을 구체화하는 과정이 여기서 끝나는 것이 아니라 반복적이고 지속적으로 이루어집니다. 데이터 요소가 비즈니스 워크플로를 구현하는 데이터 처리 파이프라인에 투입됨에 따라 데이터 아키텍처도 반복적으로 조정되고 개선됩니다. 기존 워크플로를 개선하고 새로운 워크플로를 추가하면서 기존 데이터 원자에 대한 추가적인 데이터 아키텍처 요구 사항과 새로운 데이터 원자를 발견하게 됩니다.

마무리 생각

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

핵심 원칙은 구문, 의미 체계, 주석을 정의하는 견고한 데이터 아키텍처가 데이터 파이프라인을 효율적으로 개선하고 새로운 워크플로를 손쉽게 추가할 수 있는 기반을 마련한다는 것입니다. 비즈니스 계층의 추상화 관점에서 보면, 이는 기존 비즈니스 프로세스를 쉽게 수정하고 새롭게 등장하는 비즈니스 프로세스를 신속하게 도입할 수 있음을 의미합니다. 반대로 데이터 어휘, 데이터 아키텍처 프레임워크, 또는 이를 비즈니스 요구 사항과 연계하는 작업 중 어느 하나라도 충분히 숙고하지 않고 결정하면, 결국 취약하고 불안정하며 새로운 비즈니스 요구 사항에 민첩하게 대응하지 못하는 시스템으로 이어집니다.