1. 들어가며
안녕하세요. 잡플래닛 Data Insight & Strategy팀(이하 DIS팀)의 Analytics Engineer 정성현입니다.
DIS팀의 미션은 데이터가 흐르는 조직을 만드는 것입니다. 제가 생각하는 데이터가 흐르는 조직이란 “데이터가 필요한 형태로, 체계적으로 정리되어 있고 모든 구성원이 높은 수준의 데이터 문해력을 갖추고 있어서 쉽고 빠르게 데이터를 이해하고 활용하는 조직”입니다. 이 포스트에서는 데이터가 흐르는 조직을 위한 첫 단계인 잡플래닛 데이터 웨어하우스 구축 여정을 소개합니다.
2. 기존 분석 환경
2-1. 기존 분석 환경 소개
기존의 데이터 분석 환경은 2016년에 구축되었습니다. 2016년은 알파고와 이세돌의 대국으로 인해 데이터, 머신러닝, 딥러닝과 같은 개념들이 대중의 관심을 받기 시작한 시점이었지만, 이러한 개념과 기술들이 널리 이해되거나 활용되지는 않았습니다. 잡플래닛에서도 데이터 활용의 주된 목적은 서비스 현황 파악에 초점이 맞춰져 있었습니다.
당시 구성원들의 주된 니즈는 "데이터에 직접 접근하여 필요한 데이터를 추출"할 수 있는 것이었으며, 특히 "개발자의 도움 없이도 여러 데이터 소스를 결합하여 조회할 수 있는 것"이 중요했습니다. 반면, 화려한 시각화나 고급 분석 기능에 대한 니즈는 크지 않았습니다. 데이터를 직접 추출할 수 있다면 엑셀을 활용해 가공하는 편이 더 수월했기 때문입니다. 즉 당시의 니즈는 데이터 분석을 통한 인사이트 도출보다는 기본적인 데이터 탐색(확인)에 가까웠다고 볼 수 있습니다.
그렇게 만들어진 분석 환경에서 작은 변화와 발전이 있긴 했지만, 전체적인 구조는 2023년까지 약 7년간 유지되었습니다. 2023년 초 운영 중이던 데이터 파이프라인 아키텍쳐는 다음과 같습니다.
- Kafka: 분산 메시징 시스템으로, 데이터를 실시간으로 그리고 안정적으로 스트리밍할 수 있게 해줍니다. 애플리케이션에서 발생하는 실시간 로그 메시지를 Queue 형태로 관리하고 영구 저장하며, Producer가 메시지를 보내면 Kafka에 적재되고 Consumer가 이를 가져가서 처리합니다
- Hive: HDFS(Hadoop Distributed File System)에 저장된 대용량 데이터를 Column based Table 형태로 구조화합니다. 테이블 메타 데이터는 Hive Metastore에 저장되며, 대화형 분산 SQL 쿼리 엔진인 Presto는 이 Metastore에 등록된 테이블을 사용합니다.
- Zeppelin: 사용자는 웹 기반 Notebook 인터페이스에서 Presto Query를 실행해 데이터를 조회합니다.
2-2. 문제
시간이 지남에 따라 데이터 분석에 대한 니즈가 증가하고 데이터 드리븐 의사결정이 중요해지기 시작했습니다. 그러나 기존의 데이터 분석 환경은 당시의 니즈(데이터 탐색과 확인)에는 최적화된 시스템이었지만 새로운 니즈를 충족시키기에는 여러 문제점이 있었습니다.
문제1. 시스템 가용성 및 성능 저하
기존 데이터 분석 환경은 서버 다운 빈도가 잦고 응답 속도가 낮아 데이터 분석 작업이 자주 지연되었습니다. 당시 제플린을 담당하는 EC2 인스턴스가 단일 서버로 구성되어 있었기 때문에 사내 여러 구성원이 동시에 쿼리를 실행하거나 높은 처리량을 유발하는 쿼리를 실행할 때마다 메모리/CPU 부족 등으로 오류가 발생했습니다. 서버가 다운될 때마다 인프라 담당자에게 요청하여 EC2 인스턴스를 매번 수동으로 종료하고 재실행해야 했습니다. 그렇게 데이터 분석가를 비롯한 사내 구성원들은 필요한 데이터를 로드하기 위해 긴 대기 시간을 감수해야 했고, 이는 전체적인 작업의 효율성을 크게 저하했습니다.
문제2. 데이터 모델링 비효율성
운영계 레플리카 DB를 대상으로 쿼리하다 보니, 필요한 데이터를 추출하기 위해서는 다수의 정규화된 테이블을 파악하고 조인해야만 했습니다. 이렇게 만들어진 유구한 역사를 가진 복잡한 쿼리는 처리 시간을 증가시켰을 뿐만 아니라 쿼리의 로직 파악도 어렵게 만들었습니다. 데이터 분석가는 기존에 작성된 쿼리들의 로직을 파악하는 데 많은 시간을 소비해야 했고 정확한 결과를 얻기까지 오랜 시간이 소요되었습니다.
문제3. 데이터 가시성 제약
과거 데이터들을 따로 저장하고 있지 않다 보니 현재 시점의 데이터에 한정해 분석해야 했습니다. 이 때문에 시간에 따른 트렌드 분석이나 장기적인 패턴을 확인하기 어려웠으며 데이터 추출 시점에 따라 집계 결과가 달라지곤 했습니다. 이러한 데이터 가시성 제약은 결국 신뢰할 만한 데이터 분석과 제공을 어렵게 하고 데이터 기반 의사 결정에도 영향을 주었습니다.
문제4. 자동화 미비
스케줄링 기능이 없었기에 쿼리 실행의 자동화가 불가능했습니다. 매일 아침 데이터 분석가 혹은 다른 부서의 담당자가 수동으로 쿼리를 실행해야 했으며, 이러한 수동 작업은 인적 리소스를 낭비할 뿐만 아니라 휴먼 에러의 가능성도 높였습니다. 반복되는 불필요한 루틴은 업무의 효율성을 저하하고 일관성 없는 데이터 처리를 초래하곤 했습니다.
문제5. 메타데이터 관리 미흡
테이블 디스크립션의 체계적인 관리가 부족했습니다. 데이터베이스 테이블과 컬럼에 대한 메타데이터가 제대로 관리되지 않아 근속 연수가 긴 일부 담당자의 기억에 의존해 디스크립션을 만들어가야 했습니다. 특히 새로운 팀원이나 다른 부서 동료들이 데이터를 이해하고 사용하는 데 어려움을 겪게 했으며, 이는 사내 데이터 활용성의 저하로 이어졌습니다.
문제6. 데이터 통합 제약
내부 DB와 외부 데이터 소스(Amplitude, Braze, Appsflyer 등) 간의 연결 및 통합이 원활하지 않아 다양한 소스의 정보를 종합적으로 활용하는 데 많은 제약이 있었습니다. 운영계 레플리카 DB의 쿼리 결과를 csv로 다운 받고, Amplitude 데이터를 Amplitude 웹 콘솔 상에서 csv로 다운 받아 로컬 환경에서 분석해야 했습니다. 데이터 통합의 어려움은 사용성을 저하했고 분석의 정확성과 신뢰성을 해치는 요소로 작용했습니다.
3. 데이터 웨어하우스 구축
위 문제들을 해결하기 위해 잡플래닛의 데이터 웨어하우스를 구축하였습니다.
3-1. 현재의 데이터 파이프라인 아키텍쳐
3-2. 파이프라인에 대한 소개
1. DMS에서 개인 식별 정보 처리
개인 식별 정보(Personally Identifiable Information, PII)란 성명, 생년월일, 전화번호, 이메일 주소 등 개인을 식별할 수 있는 정보를 나타냅니다. 정보계에는 데이터 분석, 의사결정 지원, 보고서 작성, 인사이트 도출 등을 목적으로 하기에 개인 식별 정보가 필요하지 않습니다. 따라서 정보계에는 개인 식별 정보를 제외하는 것이 당연하고 필수적이라고 할 수 있습니다.
AWS DMS (Data Migration Service)는 데이터 마이그레이션과 동시에 데이터 변환 작업을 수행할 수 있는 기능을 제공합니다. DMS에서 마이그레이션 작업을 설정할 때 JSON 형식으로 Table mappings와 Transformation rules를 정의합니다.
- Table mappings에는 마이그레이션할 데이터 테이블과 컬럼을 선택하는 규칙을 정의합니다. 어떤 스키마의 어떤 테이블이 마이그레이션 대상인지, 특정 조건에 따라 데이터를 필터링할지 여부를 지정할 수 있습니다.
- Transformation rules에는 선택된 데이터에 적용될 변환 작업을 정의합니다. expression 필드에 SQLite 함수를 사용하는 표현식을 작성하여 직관적인 방식으로 데이터 마스킹, 데이터 타입 변경, Default 값 설정 등을 적용할 수 있습니다.
DMS를 통해 개인 식별 정보(PII)를 마스킹함으로써 정보계(GCP)에는 개인 식별 정보가 저장되지 않도록 하였습니다.
2. BigQuery 중심의 데이터 플랫폼
BigQuery는 GCP 기반 데이터 분석 환경의 핵심이라고 볼 수 있습니다. GCP의 다른 서비스들이 BigQuery를 중심으로 구성되어 있다고 해도 과언이 아닙니다. 전체 서비스 인프라가 AWS에 있는 경우에도 BigQuery를 사용하기 위해 GCP에 분석 환경을 별도로 구축하는 기업들이 많습니다. 저희도 예외는 아니었습니다. 당시 AWS에서 데이터 웨어하우스를 구축하는 것과 GCP BigQuery를 활용하는 것을 비교했고, 결과적으로 BigQuery를 선택했습니다.
BigQuery를 선택한 데에는 몇 가지 주요 이유가 있습니다.
- 빠르고 쉬운 도입: 과거 경험으로 GCP의 여러 서비스를 사용하는 것이 익숙했습니다. 장기적으로 보았을 때 BigQuery를 중심으로 파이프라인을 구축하는 것이 더 신속하고 용이할 것이라는 경험적 판단이 있었습니다. BigQuery가 완전 관리형 서비스이고, 당시 우리 서비스에서 데이터 레이크 구축 필요성이 높지 않았습니다.
- 테이블 미리보기 기능: 미리보기 기능을 통해 쿼리를 실행하지 않고도 테이블의 스키마와 일부 샘플 데이터를 미리 확인할 수 있습니다. 쿼리를 실행하지 않고도 데이터의 구조와 내용을 빠르게 파악할 수 있다는 점은 데이터가 흐르는 조직을 만드는 데 있어서 꽤 중요한 요소라고 판단했습니다.
- Google Workspace와의 원활한 연동: 사내에서 Google Workspace를 적극적으로 활용하고 있었습니다. BigQuery는 Google Workspace, 특히 스프레드시트와 원활하게 연동되어 데이터 ingestion 및 다양한 분석 작업을 간편하게 수행할 수 있도록 지원했습니다.
BigQuery의 도입은 잡플래닛의 데이터 분석 인프라를 근본적으로 변화시켰습니다.
- BigQuery의 서버리스 아키텍처 덕분에 사내 구성원들이 높은 처리량을 요구하는 쿼리를 동시에 실행해도 시스템이 다운되는 일이 없어졌습니다. 자동 스케일링으로 필요에 따라 CPU와 메모리 자원을 동적으로 조정하기 때문에 응답 속도가 느려지거나 서버 오류가 발생하던 문제를 자연스레 해결할 수 있었습니다. 이전에 EC2 인스턴스를 수동으로 재시작해야 했던 번거로움이 사라졌고 데이터를 로드하는 동안 기다려야 했던 대기 시간도 대폭 줄어들었습니다.
- Scheduled Query를 활용해 쿼리 실행의 자동화가 가능해졌습니다. 담당자가 매일 아침 수동으로 쿼리를 실행할 필요가 없어졌습니다. 사전에 정의된 스케줄에 따라 자동으로 쿼리가 실행되기에 인적 리소스를 효율적으로 사용할 수 있게 되었고 휴먼 에러도 크게 줄었습니다. 자동화를 통해 데이터 처리의 일관성과 정확성이 향상되었고 전반적인 업무의 효율성이 높아졌습니다.
- 다양한 데이터 소스를 통합하여 분석할 수 있게 되었습니다. 잡플래닛은 Product Analytics Tool로 Amplitude를 사용하고 있었는데 Amplitude GUI상에서 이벤트 데이터를 BigQuery로 쉽게 Export(내보내기) 할 수 있었습니다. 수동으로 csv 파일을 다운 받아 로컬 환경에서 분석할 필요 없이 플랫폼 내에서 모든 데이터 소스를 쉽게 관리하고 분석할 수 있게 되었습니다. 이에 따라 데이터 분석의 효율성과 정확성이 크게 향상되었습니다.
3. Dataform을 활용한 데이터 모델링
데이터 변환 작업은 데이터 웨어하우스에 로드된 원본 데이터를 분석 가능한 형태로 가공하는 중요한 단계입니다. Dataform은 ETL 과정 중 '변환(Transform)' 단계에 특화된 데이터 엔지니어링 툴로, 복잡한 SQL 워크플로를 체계적으로 관리할 수 있도록 돕습니다. 구체적으로 살펴보면 Dataform은 개발, 테스트, 버전 관리, 의존성 관리, 스케줄링과 같은 중요 기능들을 제공하여 데이터 웨어하우스에서 로드된 데이터의 변환 작업을 효율적으로 수행할 수 있게 해줍니다.
과거에는 데이터 변환 도구를 선택하는 일이 비교적 간단했습니다. dbt가 이 영역에서 대표적인 도구로 자리 잡고 있었기 때문입니다. 하지만 2023년 Dataform의 공식 출시 이후 GCP(Google Cloud Platform)와의 뛰어난 호환성을 바탕으로 Dataform이 부상하기 시작했습니다. 개발, 협업, 배포, 거버넌스, 비용 등을 고려해 dbt와 비교한 결과 잡플래닛의 GCP 기반 데이터 분석 환경에서는 종합적인 운영 효율성 측면에서 Dataform을 채택하는 것이 더욱 유리하다고 판단했습니다.
Dataform의 핵심 기능은 다음과 같습니다.
- 코드 기반 데이터 정의 (SQLX): SQLX는 SQL과 JavaScript를 통합한 것으로, 복잡한 데이터 변환 로직을 JavaScript로 구현하고 SQL 쿼리에 삽입할 수 있습니다.
- 버전 관리 및 협업: Git 기반 버전 관리 시스템을 통해 모든 데이터 모델과 관련 코드를 저장하고 변경 사항을 추적할 수 있습니다. 브랜치를 만들어 여러 사용자가 동시에 작업할 수 있고 코드 리뷰, 승인, 배포 등 협업에 용이합니다.
- 자동화 및 모니터링: 코드 변경 시 자동으로 빌드 및 테스트를 수행하여 코드 오류를 사전에 발견하고 방지하여 데이터 파이프라인의 안정성을 높입니다. 예약에 따라 자동으로 데이터 모델을 실행하여 데이터 파이프라인 운영을 자동화합니다.
- 데이터 품질 보증: 데이터 모델에 대한 유닛 테스트를 지원하여 데이터의 정확성과 일관성을 검증할 수 있습니다.
(Dataform의 자세한 사용 방법은 다른 포스트에서 다룰 예정입니다.)
3-1. Dimensional Modeling
데이터 모델링은 데이터가 흐르는 조직을 만드는 데 필수적인 요소 중 하나입니다. 많은 조직이 '데이터 기반 의사결정'을 지향하면서도 이 중요한 부분을 간과하는 경우가 많습니다. 대부분의 조직은 비즈니스 가치를 창출하기 위한 체계적인 계획 없이 데이터 시스템을 구축하곤 합니다. 성공적인 데이터 활용을 위해서는 데이터 아키텍처가 조직의 목표와 비즈니스 로직을 반영할 수 있도록 설계되어야 합니다. 데이터 모델링은 이러한 요구사항을 충족시키기 위해 데이터에 적절한 구조와 형식을 부여하는 중요한 과정입니다.
이 과정이 제대로 수행되지 않으면 사용자가 데이터를 이해하기 어려워지고, 활용도 또한 떨어질 수 있습니다. 예를 들어, 중복 데이터가 제거되지 않거나 데이터 간의 관계가 모호한 경우, 비즈니스 용어와의 매핑이 잘못되어 있는 경우에 사용자는 데이터의 의미를 정확히 파악하기 어렵고 원하는 분석을 수행하기 위해 추가적인 전처리 작업이 필요하게 됩니다. 따라서 체계적인 모델링 없이는 수집된 데이터가 최종 사용자에게 실질적인 가치를 제공하기 어렵습니다.
(Dataform을 활용하여) 데이터 웨어하우스 구축에 따른 이점은 다음과 같습니다. (여기서 “데이터 웨어하우스”라 함은 시스템(솔루션)으로서의 데이터 웨어하우스가 아니라, 모델링(Layer) 관점에서의 데이터 웨어하우스를 의미합니다.)
- 필요한 데이터를 쉽게 추출할 수 있게 되었습니다. 우선 Dimension Table과 Fact Table로 데이터 모델을 구분했습니다. Dimension Table에는 유저, 기업, 이력서, 채용 공고, 채용 지원 등 주요 마스터 데이터가 포함되고, Fact Table에는 주문, 결제, 지원 내역 등 측정 가능한 사실(Fact) 데이터가 포함됩니다. 여기서 중요한 점은 Dimension Table과 Fact Table이 무 자르듯 완벽하게 구분되지 않으며 여러 관점을 아우를 수 있는 최적(최선)의 의사 결정이 필요하다는 점입니다. 즉 처음에는 “채용 지원”을 Fact로 생각할 수 있습니다. 유저는 여러 번의 지원을 할 수 있으며 유저의 각 지원 건별 지원 상태(Status) 변화 내역이 중요할 수 있기 때문입니다. 그러나 만약 지원 건에 대한 정보 자체를 중시한다면 이 테이블을 Dimenstion Table로 만들 수 있습니다. 이렇게 구축된 데이터 웨어하우스에서는 복잡한 조인 없이도 필요한 데이터를 쉽게 추출할 수 있었으며 이전과 비교하여 쿼리 로직이 매우 단순해졌고 처리 시간도 크게 개선되었습니다.
- 특정 시점의 스냅샷 데이터를 저장하여 과거 데이터에 대한 분석이 가능해졌습니다. 예를 들어 주문 Fact 테이블에는 날짜별로 주문 데이터가 누적되고, 고객 Dimension 테이블에는 고객의 속성 변경 이력이 관리되고 있습니다. 이 두 데이터를 조합하면 특정 시점의 고객 속성에 따른 주문 현황을 분석할 수 있게 됩니다. 과거에는 데이터 추출 시점에 따라 분석 결과가 달라지는 문제가 있었지만, 이제는 일관된 분석 결과를 얻을 수 있게 되었습니다.
- Data Dictionary를 자동화하여 관리할 수 있게 되었습니다. Dataform은 데이터 모델을 코드로 정의하기 때문에 모델에 대한 설명과 메타데이터를 코드에 직접 입력하는 방식으로 문서화할 수 있습니다. 즉 테이블의 정의 코드 상단 어떤 데이터가 어떤 목적으로 저장되는지, 각 컬럼은 무엇을 의미하는지 등의 내용을 명시할 수 있습니다. 이렇게 코드 내 문서화된 메타데이터는 테이블의 변화가 생길 때마다 디스크립션을 따로 작성해야 했던 관리 포인트를 줄였을 뿐만 아니라, 버전 관리를 통해 지속적으로 관리되기 때문에 일관성과 투명성이 보장됩니다. 모든 데이터 웨어하우스 테이블에 대한 명확한 정의가 문서로 존재하게 되었고 새로운 팀원이나 타부서 구성원들도 이 메타데이터를 참고하여 데이터를 쉽게 이해하고 활용할 수 있게 되었습니다.
config { type: 'incremental', schema: 'dw_jp', name: 'dim_users', description: '유저 정보', columns: { user_id: "유저 ID", signup_ts: '유저 회원가입 일시', is_internal: '내부 직원 계정 여부', occupation : { description: '직종 정보', columns: { occupation_level1_id: '1차 직종 ID', ... } ...
- Workflow, Lineage를 한눈에 파악할 수 있게 되었습니다. Dataform에서는 데이터 모델 간의 의존성을 명시적으로 정의할 수 있습니다. 예를 들어 멤버십 결제 Fact 테이블은 제품 Dimension 테이블에 의존하며, 제품 Dimension 테이블은 ODS의 제품 테이블 및 제품 카테고리 테이블에 의존한다는 것을 코드에 지정할 수 있습니다. 이렇게 의존성이 정의되면 Dataform은 각 모델의 실행 순서대로 자동으로 실행해 줍니다. 업스트림 모델이 실행되지 않으면 다운스트림 모델도 실행되지 않게 되며 모델 사이에 Data Quality를 체크하는 로직(Assertions)을 통해 데이터 품질 테스트를 진행하여 데이터 오염 문제를 방지할 수 있습니다. BigQuery 예약 쿼리 기능만으로는 이러한 의존성 관리가 어려웠지만, Dataform의 도입을 통해 데이터 파이프라인 전체에 걸쳐 체계적인 의존성 관리가 가능해졌습니다. 이를 통해 데이터 품질과 파이프라인 안정성이 크게 향상되었습니다.
4. BI
데이터 웨어하우스에 적재된 데이터를 바탕으로 주제별 데이터 마트(Data Mart)를 구축하고 있습니다. 데이터 마트는 특정 비즈니스 영역이나 부서에 특화된 데이터 집합으로, 분석 및 보고 목적에 최적화되어 있습니다. 데이터 마트를 Tableau, Metabase, 스프레드시트 등 다양한 BI 툴과 연결하여 전사 구성원들이 자유롭게 데이터에 접근하고 분석할 수 있는 환경을 만들고 있으며 툴에 대한 제약 없이 구성원 개개인의 업무 특성에 맞는 방식으로 데이터를 활용할 수 있도록 돕고 있습니다.
5. Airflow로 오케스트레이션
데이터 웨어하우스 구축 외에도 다양한 데이터 처리 작업은 Airflow로 오케스트레이션하고 있습니다. 예를 들어 3rd Party Tool로부터 수집한 원본 데이터를 BigQuery에 주기적으로 적재하거나 머신러닝 모델의 학습 및 예측 파이프라인을 자동화하는 등의 작업은 Airflow로 관리합니다.
4. 결론과 회고
4-1. 결론
데이터 웨어하우스 구축을 통해 잡플래닛의 데이터 분석 환경이 크게 개선되었습니다. 시스템 가용성 및 성능 저하, 데이터 모델링 비효율성, 데이터 가시성 제약, 자동화 미비, 메타데이터 관리 미흡, 데이터 통합 제약 등의 이슈들이 상당 부분 해소되었습니다.
새롭게 구축된 GCP 기반 데이터 웨어하우스 환경에서는 BigQuery의 서버리스 아키텍처와 확장성을 활용하여 높은 성능과 안정성을 보장할 수 있게 되었습니다. 또한 Dataform을 도입하여 체계적인 데이터 모델링과 파이프라인 관리가 가능해졌고, BI 툴과의 연계를 통해 전사 데이터 활용도가 높아졌습니다.
이를 통해 데이터를 쉽고 빠르게 이해하고 활용할 수 있는 "데이터가 흐르는 조직"에 한 발 더 가까워졌다고 볼 수 있습니다. 향후에도 지속적인 개선을 통해 데이터 기반 의사결정 체계를 더욱 공고히 해나갈 계획입니다.
4-2. 회고
이 여정을 통해 가장 크게 얻은 교훈은 데이터 분석 환경 구축, 더 나아가 데이터가 흐르는 조직을 만들기 위한 여정은 결코 한 사람의 노력만으로는 불가능하다는 점입니다.
- 처음에는 순전히 기술적인 측면에 집중했지만, 프로젝트가 진행될수록 여러 동료와의 협력이 필수적이라는 것을 느꼈습니다. 데이터 엔지니어들과 지속적으로 소통하며 데이터 파이프라인을 개선해 나갔고, 백엔드 개발자들과 협업하여 테이블의 로직과 디스크립션을 파악하는 작업을 거쳤습니다. 그리고 데이터 분석가를 비롯한 여러 데이터 사용자와 커뮤니케이션하며 데이터 모델링 결과가 비즈니스 로직을 반영하고 빠른 의사 결정에 기여할 수 있도록 만들었습니다.
- 데이터 품질의 책임이 특정 개인이나 부서에 한정될 수 없다는 점을 느꼈습니다. 데이터 조직, 소프트웨어 개발 조직뿐만 아니라 비즈니스 조직, 운영 조직, 고객 경험 조직 등 회사 내 모든 구성원이 데이터 품질에 대한 책임을 공유해야 합니다. 구성원 간 협업을 촉진하고, 데이터가 어떻게 활용되는지에 대한 인식을 높이며, 데이터 품질 관리를 위한 프로세스와 인프라를 갖추는 것이 데이터 품질 문제를 개인이나 특정 부서에 온전히 맡기는 것보다 훨씬 더 큰 가치가 있음을 알게 되었습니다.
5. 앞으로
- 데이터 거버넌스 구축
데이터 웨어하우스 환경을 체계적으로 관리하고 데이터 자산에 대한 거버넌스를 강화하기 위해 GCP의 Dataplex를 도입하고 있습니다. Dataplex는 데이터 레이크, 데이터 웨어하우스 등 분석 환경을 하나의 통합된 시스템에서 구축하고 관리할 수 있는 지능형 데이터 통합 및 분석 서비스입니다.
이를 통해 달성하고자 하는 주요 목표는 데이터 검색 시간을 단축하고 데이터 기반 의사결정의 속도를 향상하는 것입니다. 비즈니스 용어집(Business Glossary)을 포함한 데이터 카탈로그를 활용하여 용어와 정의를 표준화함으로써 도메인 데이터 이해도를 높일 수 있을 것이라 기대합니다. 데이터 거버넌스 체계를 수립하여 지금껏 축적한 잡플래닛의 데이터 자산의 효과적으로 활용할 수 있을 것입니다.
- 데이터 민주화 및 LLM 활용 확대
데이터가 흐르는 조직을 만들기 위해서는 단순히 기술적인 인프라를 구축하는 것만으로 충분하지 않습니다. 전사적으로 데이터 문해력을 높이고 데이터 기반 의사결정 문화를 내재화하는 노력이 병행되어야 합니다. 이를 위해 데이터 리터러시 교육, SQL 교육, BI툴 활용 교육 등을 지속적으로 운영하여 데이터 민주화(Data Democratization)에 앞장서고자 합니다.
더불어 대화형 AI(LLM)를 데이터 분석 및 의사결정 프로세스에 접목하여 SQL이나 툴 사용 방법을 잘 몰라도 누구나 쉽게 데이터를 활용할 수 있는 환경을 조성하고자 합니다. 이러한 접근을 통해 기존과는 차별화된 방식으로 데이터 기반 의사결정 문화를 발전시키고자 합니다.
6. 마치며
분석 외부에 있는 사람들은 데이터 분석 결과물을 만들기 위해 그 이면에 어떤 복잡한 과정이 숨어 있는지 잘 인식하지 못합니다. 사용자에게 제공되는 여러 대시보드, 분석 인사이트, 예측 모델 등의 결과물 뒤에는 보이지 않는 견고한 데이터 파이프라인이 있습니다.
데이터가 흐르는 조직을 만들기 위해서는 확장 가능하고 안정적인 데이터 파이프라인 아키텍처가 필수적입니다. 잡플래닛 데이터 조직은 이러한 중요성을 잘 인식하고 있으며, 클라우드 네이티브 아키텍처에 기반한 최신 데이터 파이프라인을 지속적으로 고도화하여 안정적이고 확장 가능한 환경을 구축하기 위해 노력하고 있습니다.
끝으로 저희와 함께 데이터가 흐르는 조직을 만들어갈 Analytics Engineer를 모시고 있습니다. 데이터가 흐르는 조직을 만들고 문화를 바꾸는 새로운 도전을 함께하실 분들의 많은 지원 부탁드립니다.
Share article
Subscribe to 잡플래닛 테크블로그
