수많은 기업이 스노우플레이크(Snowflake), 빅쿼리(BigQuery) 같은 강력한 클라우드 데이터 웨어하우스와 fivetran, dbt 같은 세련된 도구들을 도입했습니다. 이른바 ‘모던 데이터 스택(Modern Data Stack, MDS)’의 시대가 열린 것입니다. 하지만 도구가 화려해졌음에도 불구하고, 현업의 데이터 엔지니어와 분석가들이 느끼는 고통은 줄어들지 않았습니다. 오히려 관리해야 할 도구가 늘어나면서 복잡성은 더 커졌고, 정작 경영진이 원하는 ‘정확한 숫자’ 하나를 뽑아내는 데 며칠이 걸리는 아이러니한 상황이 반복되고 있습니다.

우리는 여기서 질문해야 합니다. 인프라는 이미 클라우드로 옮겨갔고, 파이프라인은 자동화되었는데 왜 데이터는 여전히 파편화되어 있을까요? 왜 데이터 팀은 여전히 ‘데이터 정제’라는 끝없는 늪에서 허우적거리고 있을까요? 이것이 바로 모던 데이터 스택이 마주한 ‘마지막 난제(The Last Hard Problem)’입니다.

기술적 화려함 뒤에 숨겨진 ‘데이터 신뢰성’의 붕괴

모던 데이터 스택의 핵심은 ‘분리’였습니다. 저장소와 연산이 분리되었고, 데이터 추출(Extract)과 로드(Load)가 먼저 일어난 뒤 웨어하우스 내부에서 변환(Transform)하는 ELT 방식으로 패러다임이 바뀌었습니다. 이론적으로는 매우 효율적입니다. 하지만 이 과정에서 치명적인 맹점이 발생했습니다. 바로 ‘데이터의 맥락(Context)’과 ‘품질 제어’가 파이프라인의 뒤편으로 밀려났다는 점입니다.

과거의 전통적인 ETL 방식은 데이터를 넣기 전에 엄격하게 검증했습니다. 반면 현대의 ELT 방식은 일단 모든 데이터를 쏟아붓고 나중에 정리합니다. 문제는 ‘나중에’라는 시점이 모호하며, 데이터가 쌓일수록 변환 로직(SQL)은 거대한 스파게티 코드가 되어버린다는 것입니다. 결과적으로 데이터 웨어하우스는 ‘데이터 호수’가 아니라 ‘데이터 늪’이 되어버립니다. 분석가는 쿼리를 실행하지만, 그 결과값이 왜 이렇게 나왔는지 추적하는 데 더 많은 시간을 소비하게 됩니다.

왜 이것이 ‘마지막’ 난제인가?

컴퓨팅 파워의 부족이나 저장 공간의 한계는 이미 기술적으로 해결되었습니다. 이제 남은 문제는 기술적 구현 능력이 아니라, 데이터의 흐름을 어떻게 정의하고 관리하며 신뢰할 것인가라는 ‘거버넌스’와 ‘운영’의 영역입니다. 이는 단순히 툴 하나를 더 도입한다고 해결되지 않습니다.

• 시맨틱 레이어의 부재: 동일한 ‘매출’이라는 지표를 두고 마케팅 팀과 재무 팀이 서로 다른 정의를 사용하며, 이를 통합하는 단일 진실 공급원(Single Source of Truth)이 없습니다.
• 데이터 계보(Lineage)의 불투명성: 상위 소스 데이터가 변경되었을 때, 이것이 최종 대시보드의 어떤 지표에 영향을 주는지 즉각적으로 파악하기 어렵습니다.
• 운영 체계의 부재: 소프트웨어 개발에는 CI/CD와 테스트 코드가 있지만, 데이터 파이프라인에는 여전히 ‘돌아가니까 둔다’는 식의 임기응변식 운영이 많습니다.

실제 사례: 급성장하는 이커머스 A사의 딜레마

최근 급격히 성장한 한 이커머스 기업 A사는 최신 MDS를 모두 구축했습니다. 하지만 어느 날 CEO가 “지난달 순이익이 왜 대시보드마다 다른가?”라는 질문을 던졌을 때, 데이터 팀은 패닉에 빠졌습니다. 마케팅 대시보드는 ‘취소 주문’을 제외하지 않았고, 재무 대시보드는 ‘반품 예정’ 건을 미리 반영했기 때문입니다.

이들은 dbt를 통해 변환 로직을 관리하고 있었지만, 각 분석가가 각자의 SQL 파일에서 지표를 정의하는 방식을 고수했습니다. 결국 ‘순이익’이라는 단 하나의 정의를 합의하고 이를 코드화하여 모든 대시보드에 강제 적용하는 ‘시맨틱 레이어’를 구축하기 전까지, 그들은 매주 월요일 회의마다 숫자의 정당성을 두고 논쟁해야 했습니다.

해결을 위한 기술적 접근과 트레이드오프

이 난제를 해결하기 위해 최근 업계에서는 ‘데이터 계약(Data Contracts)’과 ‘시맨틱 레이어(Semantic Layer)’라는 개념이 부상하고 있습니다. 데이터 계약은 데이터 생산자(백엔드 개발자)와 소비자(데이터 분석가)가 데이터의 스키마와 품질에 대해 사전에 합의하는 일종의 API 명세서와 같습니다.

실무자를 위한 단계별 액션 가이드

모던 데이터 스택의 늪에서 벗어나 데이터 신뢰성을 회복하고 싶다면, 다음의 단계를 밟으십시오. 도구를 바꾸는 것이 아니라 프로세스를 바꾸는 것이 핵심입니다.

• 1단계: 핵심 지표 사전(Metric Dictionary) 작성 – 툴을 켜기 전에 엑셀이나 노션에 우리 회사가 정의하는 ‘활성 사용자’, ‘매출’, ‘이탈률’의 정확한 계산식을 명문화하십시오. 합의되지 않은 지표는 코드로 구현하지 마십시오.
• 2단계: 데이터 계약(Data Contract) 도입 – 소스 시스템의 스키마 변경이 파이프라인을 깨뜨리는 것을 방지하기 위해, 백엔드 팀과 데이터 팀 간의 변경 알림 프로세스를 구축하거나 스키마 검증 도구를 도입하십시오.
• 3단계: 테스트 자동화 – dbt test와 같은 도구를 활용해 ‘Null 값 체크’, ‘Unique 값 체크’ 등 기본적인 데이터 품질 테스트를 파이프라인의 필수 단계로 포함시키십시오.
• 4단계: 시맨틱 레이어 검토 – 반복되는 복잡한 JOIN 문과 계산식을 개별 쿼리가 아닌, 중앙 집중식 정의 레이어(예: Cube, dbt Semantic Layer)로 옮겨 분석가들이 정의된 지표만 호출하게 만드십시오.

결론: 도구의 시대에서 운영의 시대로

결국 모던 데이터 스택의 마지막 난제는 기술의 부족이 아니라 ‘약속의 부족’에서 옵니다. 우리는 너무 오랫동안 ‘어떤 툴이 더 빠른가’에 집착했지만, 이제는 ‘어떻게 하면 이 데이터를 믿을 수 있는가’에 집중해야 합니다.

데이터 엔지니어링의 정점은 화려한 파이프라인을 구축하는 것이 아니라, 비즈니스 사용자가 의심 없이 데이터를 사용하여 의사결정을 내릴 수 있는 환경을 만드는 것입니다. 지금 당장 여러분의 대시보드에서 가장 논란이 많은 지표 하나를 골라, 그 정의를 문서화하는 것부터 시작하십시오. 그것이 모던 데이터 스택의 마지막 퍼즐을 맞추는 첫걸음이 될 것입니다.