POS 데이터를 통한 정보 활용 사례 데이터의 가격 평가 데이터 활용 사업에 중요하다고 생각되는 것

POS 데이터를 통한 정보 활용 사례

POS 판매 정보는 아래와 같다. {"점포명": "마라난다", "주소": "서울특별시 동대문구 천호대로 18길"}, {"점포명":"봉팔이네 찜닭", "주소": "경상남도 함양군 가야읍 성내담길"}

메뉴 정보는 아래와 같다. {"코드":0005, "메뉴명":"오뚜기 옛날미역 50g"}, {"코드":0006, "메뉴명":"삼선짱뽕"}

위 두 정보를 적절히 가공하면, 다음과 같은 질의가 가능해진다.

1. 서울시 동대문구에서 가장 많이 팔리는 라면은? (자사 경쟁력 피드백)
2. 편의점에서 삼선짬뽕과 같이 팔리는 메뉴는? (1+1 마케팅에 활용 가능)
3. 코로나19에 따른 A 정책의 실효성은? (정책 실효성 검증)
4. 코로나19에 따른 배달량 증가는? (업계 트렌드 파악)

물론, 위와 같은 정보를 얻기 위해서는 엄청난 양의 전처리와 정교한 DB 모델링이 필요하다. 하지만 데이터로서의 상품 가치는 충분하다.

데이터의 가격 평가

데이터의 가격은 희소성과 처리 비용에 의해 결정된다. 하지만 데이터의 가치는 활용자에 따라 상대적이다.

데이터 활용 사업에 중요하다고 생각되는 것

본문과 관련 없이 개인적인 생각이다. 연속성이 중요하다고 생각한다. 수집/전처리/저장/외부발송의 사이클에는 적은 노력으로 관리하고, 그 안에서 발견되는 작은 변화들에 집중 관리할 수 있는 아키텍쳐가 필요하다. 예를 들어, 메뉴명이 "짬짜라"인 가게가 있다. 이런 메뉴는 다른 가게에 존재하지 않으니 ["제육볶음", "김치찌개"]와 같이 분류 기준이 명확하지 않다. 이런 예외 사항은 별도의 DB로 따로 관리하며, "짬짜라"가 유행되어 다른 가게의 메뉴판에도 올라가는 경우를 대비해야 한다.

데이터 레이크 아키텍쳐란? 데이터매쉬 아키텍쳐란?

데이터 레이크 아키텍쳐란?

여러 소스에서 정형/비정형 데이터를 수집한 뒤, 비구조화된 형식으로 데이터 레이크에 저장한다. 데이터 레이크에 저장된 데이터를 직접 전처리하여 ML모델 생성에 사용하거나, 데이터 웨어하우스/데이터마트로 복사해서 정형화된 형태로 데이터 분석할 수 있다.

데이터 레이크 아키텍쳐 운용 시에 문제점

데이터 팀에서 여러 부서의 데이터를 하나로 모아서 관리한다. 따라서 도메인 전문성이 떨어지며, 도메인 특화된 툴을 적용하기 어렵다. 뿐만 아니라, 데이터 팀은 다른 팀을 지원하는데 주된 목적을 가져서 직접적인 성과를 내기 어렵다. 따라서 예산과 인력이 부족하다.

데이터매쉬 아키텍쳐란?

데이터 매쉬(Data Mesh) 아키텍쳐란, 영업/마케팅/회계 등 조직마다 데이터 전문 조직을 두는 아키텍쳐를 말한다. 데이터 전문 조직은 현업자와 밀접한 커뮤니케이션을 통해 고품질의 데이터를 생산하고, 비즈니스 여건에 맞는 도구를 사용을 지원한다. 고품질로 생산된 데이터는 다른 조직과 생성된 데이터를 공유하여 업무 생산성을 높인다.

데이터 엔지니어 역사를 잘 나타낸 유튜브 영상이다.

Question

• 초기 데이터 엔지니어가 생겨난 이유
• ETL에서 MySQL 대신 데이터 웨어하우스가 사용된 이유?
• ELT가 필요해진 이유?
• 데이터 엔지니어의 역할 변화

초기 데이터 엔지니어가 생겨난 이유

90년대에 데이터 분석을 위해 여러 개의 스프레드 시트에서 필요한 정보를 추출하여 하나로 묶고 작업했다. 매우 지루한 작업이고, 인적 오류가 발생할 가능성이 높았다. 이를 소프트웨어 엔지니어가 자동화 했다. 이 때 생겨난 시스템이 ETL 시스템이다.

ETL 시스템이란?

Extract(추출), Transform(변환), Load(적재)의 약자다. 스프레드시트 등 여러 경로에서 데이터를 추출하고, 구조화된 테이블로 저장한다. 저장된 데이터는 BI 툴을 이용해서 비개발 직군은 시각화 등의 지표로 사용 가능하다. 이를 통해 Data Driven한 의사결정이 가능해졌다.

ETL에서 MySQL 대신 데이터 웨어하우스를 사용하는 이유?

초창기에는 MySQL과 같은 Standard Transactional Database를 사용 했다. MySQL은 어플리케이션 운영 등에는 장점을 갖지만, 데이터 분석을 위한 복잡한 쿼리에는 적합하지 않다. 즉, 연속적인 트랜잭션 처리와 데이터 분석용 쿼리가 동시에 발생하기 때문에 느리다. 이에 따라 질의한 쿼리가 중간에 사라지거나 결과가 나오는데 수 분이 걸리기 시작했다.

대안으로 복잡한 쿼리에 강점을 갖는 데이터 웨어하우스를 사용하기 시작했다. 데이터 웨어하우스로 OLAP(온라인 분석 처리) 프레임워크를 사용한다. 즉, 여러 개의 대규모 과거 데이터 세트의 데이터를 결합하는 복잡한 쿼리를 빠르게 처리하는 데 최적화되어 있다.

ELT 시스템이 필요해진 이유?

데이터 사이언티스트가 필요해진 이후로 ELT가 필요해졌다. 기존에 데이터 웨어하우스에 저장된 데이터는 구조화(Structured)되어 있고, 각 조직에서 필요하다고 여겨지는 데이터만을 대상으로 했다.

데이터 사이언티스트는 데이터의 다양한 조합과 전처리 방식을 통해 의미있는 결과를 만든다. 따라서 기존에 비해 유연한 데이터 형식을 필요로 한다. 따라서 데이터 엔지니어는 다양한 소스로부터 데이터를 추출(Extract)하여 가공하지 않은 상태(Raw)로 데이터 레이크에 저장(Load)한다. 데이터 사이언티스트는 데이터 레이크 안에 저장된 데이터를 다양한 형식으로 변환(Transform)하여 ML 모델을 만든다.

데이터 엔지니어의 역할 변화

초창기(90s)에 데이터 엔지니어의 역할은 여러 스프레드 시트 등으로부터 데이터를 추출하여 적재하는 것을 자동화하는 것이었다. 이를 통해 비개발 직군의 팀원들은 자유를 얻었고, 새로운 스크립트를 작성할 데이터 엔지니어가 필요해졌다.

미래 예측을 목표로 하는 데이터 사이언티스트가 등장했고, 데이터 엔지니어는 두 개의 역할이 추가 됐다. 첫 번째는 데이터 사이언티스트의 일회성 미래 예측을 위해 제공할 데이터의 Custom-ETL을 생성하는 것이었다. 두 번째는 ELT를 통해 데이터 사이언티스트가 사용할 데이터 마트를 생성하는 것이었다.