데이터 엔지니어링 위클리 #7 | Lakehouse 2.0, Data Platform System

2025. 4. 15. 23:41ㆍ데이터 엔지니어링

Data Engineering Weekly #7

Articles

엔지니어로서 조사 문서를 활용하여 혼돈을 명확성으로 바꾸는 방법

이 글은 소프트웨어 엔지니어가 문제 해결 과정에서 Investigative Docs를 활용하여 혼돈을 정리하고 명확성을 얻는 방법에 대해 설명합니다. 이를 통해 팀 내 신뢰를 구축하고 경력을 개발하는 데 도움을 줄 수 있습니다.

  • Investigative Docs는 문제를 명확히 정의하고, 해결 과정을 문서화하여 팀원들과의 소통을 원활하게 합니다.
  • 작성된 문서는 학습 자원으로 활용되며, 향후 유사한 문제를 예방하는 데 도움을 줍니다.
  • 이 문서의 구성 요소로는 요약(TLDR), 배경, 문제 감지, 조사 단계, 해결 방법 및 배운 내용이 포함됩니다.

개요

이번 글에서는 Karthik Subramanian이라는 소프트웨어 엔지니어가 제안하는 "조사 문서(Investigation Docs)"라는 개념에 대해 다룰 것입니다. 이 글에서는 복잡한 문제를 해결하는 과정을 체계적으로 정리함으로써 엔지니어들이 어떻게 혼란스러운 상황에서 명확성을 찾을 수 있는지를 설명합니다. Karthik는 Rippling에서 일하고 있으며, 그의 경험을 바탕으로 조사 문서의 중요성과 그 활용 방안을 소개합니다.

조사 문서의 필요성

소프트웨어 엔지니어로서 우리는 종종 버그, 시스템 장애 등 다양한 문제에 직면하게 됩니다. 이러한 상황에서 조사 문서를 작성하는 것이 가지는 장점은 다음과 같습니다:

  • 명확성: 문제를 체계적으로 요약하고 정리하는 과정에서 사고가 정리됩니다.
  • 배포 용이성: 잘 작성된 문서는 팀원들과 이해관계자들과 쉽게 공유할 수 있어 정보의 일관성을 유지할 수 있습니다.
  • 책임감 향상: 문제 해결 과정을 문서화하면 문제에 대한 주인의식을 보여줍니다. 이는 팀 내 신뢰를 쌓는 데 도움이 됩니다.
  • 학습 도구: 이전의 조사 문서는 유사한 문제를 예방하는 데 도움이 됩니다.

조사 문서는 개인의 성장뿐만 아니라 팀 전체의 발전에도 기여하는 효과적인 도구입니다.

조사 문서의 구성 요소

조사 문서는 보통 다음과 같은 내용을 포함합니다:

  • TLDR: 문제와 해결 방법을 간단히 요약하는 섹션.
  • 배경/맥락: 시스템이나 과정에 대한 배경 설명.
  • 문제 탐지: 문제가 어떻게 발견되었는지, 필요한 경우 타임라인 포함.
  • 조사 단계: 원인 규명을 위한 절차나 사용한 쿼리 및 대시보드 기록.
  • 해결 방법: 원인 파악 후 문제 해결 단계 설명.
  • 교훈: 조사를 통해 얻은 학습 내용.

조사 문서의 활용

Karthik는 복잡한 상황에서 조사 문서를 작성하는 것이 생각보다 유용하다고 강조합니다. 그는 Slack 대화와 분산된 쿼리 셀들 속에서 명확한 정보가 부족해 혼란에 빠졌던 경험을 공유합니다. 조사 문서를 통해 상황을 정리하고, 새로운 가설을 세워 문제를 효과적으로 해결할 수 있었습니다.

또한, 조사 문서를 통해 다른 엔지니어와의 소통이 원활해졌으며, 문제의 본질을 빨리 파악할 수 있었던 점도 언급했습니다.

조사 문서 공유 및 실행 계획

조사 문서를 작성하는 것만으로 끝나서는 안 되고, 이를 공유하여 팀과 조직 전반에 걸쳐 학습과 협력의 기회를 만드는 것이 중요합니다. Karthik는 다음과 같은 접근 방식을 추천합니다:

  • 공유: 팀 회의나 관련 슬랙 채널에서 조사 결과를 발표.
  • 피드백 요청: 팀원들에게 의견을 요청하여 추가적인 인사이트를 얻음.
  • 행동 항목 생성: 학습 내용을 기반으로 구체적인 작업 항목을 만들어 실천.
  • 추적 및 검토: 생성한 행동 항목이 시행되고 있는지 정기적으로 점검.

결론

조사 문서는 시스템적인 문제 해결, 지식 공유, 개인의 성장에 중요한 역할을 합니다. 이는 작은 버그부터 큰 운영 문제까지 다양한 문제에 적용될 수 있습니다. 조사 문서의 핵심 구성 요소를 포함시킴으로써, 자신의 문제 해결 과정을 문서화하면 현재의 문제를 해결할 뿐만 아니라 미래의 도전 과제를 해결할 준비도 할 수 있습니다. Karthik의 사례를 통해 여러분도 조사 문서를 써보는 것을 추천드립니다. 이를 통해 혼란을 명확성으로 바꿔 보세요.

2025-04-14 00:34:23
High Growth Engineer
How to turn chaos into clarity with Investigation Docs as an engineer

데이터 플랫폼은 스택이 아니다 - 그것은 시스템이다

이 글에서는 데이터 플랫폼 구축에서 일반적으로 발생하는 오류, 즉 비즈니스 요구에 맞지 않는 솔루션의 개발과 이를 통해 발생하는 문제를 다루고 있습니다. 저자는 데이터 엔지니어가 플랫폼의 기술적 복잡성에 초점을 맞추는 데 그치고, 실제로 조직의 필요와 목표에 맞춘 시스템을 설계해야 한다고 강조합니다.

  • 데이터 플랫폼의 성공은 기술적 요소보다 비즈니스의 요구와 목표에 잘 맞추어져 있어야 한다.
  • 기존의 레이어 모델과 기능 모델의 한계를 언급하며, 기능적 역량 모델을 통한 접근이 필요하다.
  • 데이터 엔지니어는 비즈니스 이해도를 높이고, 이를 바탕으로 적절한 문제 해결 능력을 개발해야 한다.

개요

이 글은 데이터 엔지니어링 관련 경험과 교훈을 나눈 글로 시작합니다. 작성자는 금융 회사에서 Apache Kafka와 Kappa 아키텍처를 사용하여 데이터 플랫폼을 구축했습니다. 기술적으로 능숙하게 플랫폼을 설계했지만, 궁극적으로 비즈니스의 실제 요구를 이해하는 데 실패하여 런칭이 예상보다 저조했던 경험을 공유합니다. 작성자는 데이터 플랫폼이 단순한 기술 스택이 아니라 비즈니스 시스템으로 이해되어야 한다고 주장하며, 실제 필요한 문제를 해결하는 것의 중요성을 강조합니다.

데이터 플랫폼의 정의

저자는 IBM의 정의를 인용하며 데이터 플랫폼을 기술 솔루션으로, 데이터의 수집, 저장, 정제, 변환, 분석, 관리 기능을 제공하는 것으로 설명합니다. 이는 데이터의 사이클을 완전하게 지원할 수 있는 층으로 구성됩니다. 하지만 이러한 계층적 모델은 종종 실제 비즈니스 요구 사항을 반영하지 못하는 한계가 있다고 언급합니다.

계층 모델의 한계

계층 모델은 각 기술 구성 요소를 나열하고 설명하지만, 그 자체로 종합적으로 비즈니스의 문제를 해결하지는 못합니다. 예를 들어, 보건 분야와 같이 특정 산업의 요건을 충족하지 못할 수 있습니다. 작성자는 이러한 접근법이 체크리스트 사고방식을 초래한다고 지적하며, 이는 결국 비즈니스의 데이터 요구 사항을 충족하지 못할 수 있다고 경고합니다.

기능적 능력 모델

기능적 능력 모델은 데이터 플랫폼이 해야 할 일, 즉 요구되는 기능을 정의하는 접근 방식입니다. 데이터 플랫폼이 데이터를 수집하고, 통합하고, 저장하며, 처리하고, 관리하는 등의 기능을 수행해야 한다는 것입니다. 작성자는 이 모델이 비즈니스의 실제 요구와 연결되지 못한 점에서 한계가 있다고 봅니다.

변화하는 요구 사항

기능적 능력 모델은 비즈니스의 필요에 따라 변경될 수 있어야 한다고 강조합니다. 즉, 데이터 플랫폼을 구축할 때 회사의 과거와 현재는 물론 미래의 요구 사항을 반영해야 하며, 이를 지속적으로 점검하는 것이 필요합니다. 이러한 접근은 단순한 기술적 구성 요소의 나열보다 더 실질적이고 즉각적인 솔루션을 제공합니다.

결론

기능적 능력 모델은 데이터 엔지니어와 비즈니스 파트너 간의 협력을 증진시키고, 데이터 플랫폼의 목표가 비즈니스 요구와 일치하도록 하는 데 중요한 역할을 합니다. 중요한 것은 기술 솔루션이 아닌 비즈니스 해결책으로서 데이터 플랫폼을 바라보는 시각입니다. 따라서, 작성자는 데이터 엔지니어들이 기능적 능력 모델에 초점을 맞추어 더 나은 솔루션을 구축해야 한다고 결론짓습니다.

2025-04-09 02:15:04
Data Engineer Things
The Data Platform Isn’t a Stack — It’s a System

레이크하우스 2.0: 레이크하우스 1.0이 의도했던 개방형 시스템 | 제 1부

이 글에서는 Lakehouse 1.0의 한계와 이에 대한 해결책으로 등장한 Lakehouse 2.0의 필요성을 다루고 있습니다. Lakehouse 1.0은 데이터 레이크와 데이터 웨어하우스를 통합하려 했으나, 중앙집중식 아키텍처와 공급업체 종속성을 강요하는 문제점이 있었습니다. 이에 반해 Lakehouse 2.0은 모듈화된 컴포넌트와 진정한 상호운용성을 강조하여 개방적이며 유연한 데이터 환경을 지향합니다.

  • Lakehouse 1.0의 문제점: 중앙집중식 통제, 공급업체 종속, 이기종 환경의 비호환성
  • Lakehouse 2.0의 특징: 개방형 테이블 포맷, 여러 엔진 호환성, 데이터의 유연한 진화
  • 산업의 발전: AWS의 Iceberg 지원 발표는 열린 구조의 중요성을 보여줌
  • 향후 개선 방향: 메타데이터와 카탈로그 계층의 진화를 통한 데이터 관리의 혁신

개요

현대 데이터 아키텍처의 발전을 이해하기 위해서는 Lakehouse 1.0과 그 후속으로 등장한 Lakehouse 2.0의 차이를 살펴보아야 합니다. Lakehouse 1.0은 데이터 레이크와 데이터 웨어하우스의 장점을 결합한 하이브리드 구조로, 유연성과 신뢰성을 동시에 제공하고자 했습니다. 하지만 시간의 흐름 속에서 이 구조는 중앙 집중화된 통제와 독점적인 컴퓨팅 환경에 의존하게 되면서 진정한 개방성을 상실하게 되었습니다.

Lakehouse 1.0: 비전과 현실의 괴리

Lakehouse 1.0의 기본 개념은 원시 데이터를 마치 호수처럼 저장하고, 데이터 웨어하우스처럼 분석하는 것이었습니다. 초기의 목적은 데이터의 조각화 문제를 해결하고, 모든 데이터를 한 플랫폼에서 관리함으로써 비즈니스 통찰력을 통합하는 것이었습니다. 그러나 이 과정에서 많은 문제들이 발생했습니다.

  • 모듈화 부족: 데이터 팀들은 필요한 기능을 위한 모듈화된 아키텍처를 원했으나, 대신 그들은 특정 벤더의 독점 생태계에 갇히게 되었습니다.
  • 프라이빗 컴퓨팅: 데이터 레이크와 웨어하우스의 통합에도 불구하고, 컴퓨팅 엔진은 주로 Spark에 의존하며 벤더의 배급 방식에 깊이 연결된 경향이 있었습니다.
  • 거버넌스와 카탈로그의 단편화: 데이터의 진정한 출처를 정의하고 신뢰할 수 있는 방법이 부족했습니다.

이러한 문제들로 인해, Lakehouse 1.0은 "소유된 통합"이라는 새로운 형태의 문제를 야기하였고, 오히려 두 개의 독립적인 진실 출처를 만들어 내는 결과를 초래했습니다.

Lakehouse 2.0: 새로운 패러다임의 등장

Lakehouse 2.0은 이러한 문제점을 해결하기 위해 등장했으며, 더 개방적이고 모듈화된 아키텍처를 지향합니다. 이제는 특정 벤더에 종속되지 않고도 데이터 저장소와 컴퓨팅 엔진을 자유롭게 조합하여 사용할 수 있게 되었습니다.

  • 모듈화: 데이터 저장소, 메타데이터, 컴퓨팅 엔진이 독립적으로 발전할 수 있게 되면서, 팀들은 자신에게 가장 적합한 도구를 선택할 수 있는 권한을 얻었습니다.
  • 오픈 테이블 포맷: Apache Iceberg, Apache Hudi, Delta Lake와 같은 오픈 포맷을 도입함으로써, 다양한 데이터 처리 엔진들이 단일 테이블 포맷을 사용하여 상호 운용할 수 있게 되었습니다. 이로 인해 팀은 데이터 전송의 필요 없이 최적의 엔진을 선택할 수 있게 되었습니다.
  • 거버넌스와 접근 제어의 강화를 통한 신뢰성 증대: 중앙 집중화된 모델을 뛰어넘고, 데이터의 출처 및 신뢰성을 명확히 정의할 수 있는 구조가 갖춰졌습니다.

결론

Lakehouse 2.0은 데이터 아키텍처의 새로운 장을 열고 있습니다. 데이터 저장과 컴퓨팅 사이의 완전한 분리가 이루어짐으로써, 조직은 필요에 따라 유연하고 다층적인 데이터 전략을 수립할 수 있습니다. 이러한 발전은 데이터 생태계의 진정한 개방성과 상호 운용성을 보장하며, 이로 인해 기업들은 더욱 효율적이고 강력한 데이터 활용을 이룰 수 있을 것입니다. Lakehouse 2.0의 출현은 이렇게 진화된 데이터 아키텍처가 21세기 비즈니스 환경에서 어떻게 중요한 역할을 할지에 대해 새로운 가능성을 제시합니다.

2025-04-11 04:21:10
Modern Data 101
Lakehouse 2.0: The Open System That Lakehouse 1.0 Was Meant to Be | Part 1

Jobs

원티드 채용공고(최근 7일)

주요 업무(최근 7일)

필요한 기술(최근 7일)

필요한 경험(최근 7일)

필요한 소프트 스킬(최근 7일)

반응형

'데이터 엔지니어링' 카테고리의 다른 글

데이터 제품 중심 솔루션: DataOS란?  (0) 2025.03.26
데이터 웨어하우스란?  (0) 2024.02.20
[Kerberos] Kerberos Authentication Explained | A deep dive 번역  (0) 2023.03.14
[Delta Lake] 데이터 레이크하우스: 프로토콜  (0) 2022.03.18
[Delta Lake] 데이터 레이크하우스: 테이블 활용하기  (0) 2022.03.18

관련글

티스토리툴바