견고한 데이터 엔지니어링 Part 1 데이터 엔지니어링 기반 구축하기

Part 1 데이터 엔지니어링 기반 구축하기 리뷰

이 책은 위 이미지의 데이터 엔지니어링 수명 주기(와 드러나지 않는 요소)를 기반으로 설명한다.

1장 데이터 엔지니어링 상세

데이터 엔지니어링이 무엇인지 정의하고 어떻게 진화해왔으며 기업의 데이터 성숙도에 따라 어떻게 적용하면 되는지 방법론들을 제시한다.

이 책에서 정의한 데이터 엔지니어링은

• 원시 데이터를 가져와 다운스트림 사용 사례를 지원하는
• 고품질의 일관된 정보를 생성하는 시스템과 프로세스의 개발, 구현 및 유지관리 정도로 요약할 수 있다.

데이터 엔지니어의 진화는

• 비즈니스 데이터 웨어하우스
• 빅데이터 등장
• 클라우드 환경
• 데이터 과학 등의 등장을 배경으로 바뀌어왔다.

이를 바탕으로 많은 환경의 데이터 엔지니어링 솔루션/기술 등이 등장했다. 더 자세한 내용은 뒷장에서 설명한다.

1장에서 인상깊은 내용은 데이터 관리의 기업화는 대기업 문화였다면 현대에는 소규모 기업에서도 채택되고 있다는 점이다. 하지만 기존의 방식과 대조적으로 탈중앙화와 민첩성에 중점을 두고 사용한다. 여기서 탈중앙화는 모놀리식이 마이크로서비스 패턴으로 변모하거나 VM, 클라우드 사용으로 변화된 분산 처리 기술로 인한 것이 아닐까 싶다.

재밌게 본 내용 중 다른 내용은 데이터 엔지니어를 두 타입으로 분리한 것인데 각각 A형 데이터 엔지니어, B형 데이터 엔지니어다.

여기서 A는 추상화(abstraction)를 의미하고, B는 구축(build)을 의미한다. 전자는 아키텍처를 가능한 추상적이고 단순하게 유지하며 다양한 기업에 분포된 반면, 후자는 데이터 도구를 심도있게 활용해 높은 데이터 성숙도를 보이는 기업에 속한다. 그래서 지금의 나는 어떤 데이터 엔지니어이며 어떻게 나아가고 싶은지 생각하게 된다.

---

2장 데이터 엔지니어링 수명 주기

위에 이미지를 다시 꺼내보려 한다.

여기서 보여주는 전체 구조들에 대한 주요 컴포넌트의 설명들이 주를 이룬다.

수명주기를 짧게 요약하면 다음 5개 단계로

1. 데이터 생성
2. 데이터 저장
3. 데이터 수집
4. 데이터 변환
5. 데이터 서빙 으로 나눌 수 있다.

이러한 수명 주기를 거치며 관련된 고려 사항을 파악해야 한다. 데이터 생성 단계는 원천 시스템 평가 (원천 데이터의 생성 속도, 스키마 변경시 대처 방안 등)가 필요하다. 데이터 저장 단계에서는 스토리지 시스템 평가 (스토리지 차후 확장 처리, 메타데이터 캡처 여부 등)를 고려해야한다.

데이터 수집과 변환 단계에서는 배치로 처리할 것인지 스트림으로 처리할 것인지 고려해야 하며 마지막인 데이터 서빙은 분석, 머신러닝, 역ETL 중 어느 방향으로 데이터가 활용될 것인지에 따라 달라진다.

수명 주기 내에서 드러나지 않는 요소는 다양하게 정리할 수 있는데데

• 보안
• 데이터 관리
  • 데이터 거버넌스
  • 데이터 모델링 및 설계
  • 데이터 계보
  • 데이터 통합과 상호 운용성
  • 데이터 수명 주기 관리
  • 개인정보 보호
• 데이터 옵스
  • 자동화
  • 모니터링 및 관찰 가능성
  • 사고 대응
• 데이터 아키텍처
• 오케스트레이션
• 소프트웨어 엔지니어링

이렇게 구분된다. 이 중에서도 모니터링 및 관찰 가능성이 경험상 매우 중요하면서도 구축하기 어려운 부분인 것 같다.

특히 컴퓨팅 분산환경, MSA 환경에서 옵저빌리티를 구현하기 위해서는 ELK 스택 등 다양한 스택들을 활용해 각 노드들에서 파생되는 로그들을 수집하고 이를 시각화하는 것이 말로는 참 단순하지만.. 어떤 로그를 수집하고 어떻게 보여줄 것인지, 어플리케이션 단에서 나오는 것과 메트릭 단에서 나오는 것. 이런 것들이 각각 달라서 잘 설계하는 것이 훨씬 중요할 것으로 보인다.

---

3장 우수한 데이터 아키텍처 설계

큰 범위의 엔터프라이즈 아키텍처를 설계할 때는 가역적 의사결정 (되돌릴수 있는 의사결정)과 변경 관리 트레이드 오프를 고려해야한다. EA의 하위 요소 중 하나인 데이터 아키텍처에서는 운영 (무엇을?) / 기술 (어떻게?) 아키텍처를 고려해야 한다.

구체적 원칙은 다음과 같다.

1. 공통 컴포넌트를 현명하게 선택하라.
   • 객체 스토리지, 버전 제어 시스템, 관찰 가능성, 모니터링 및 오케스트레이션 시스템, 처리 엔진 등
2. 장애에 대비하라.
   • 가용성 (작동 가능한 시간), 신뢰성 (시스템이 의도한 기능대로 수행할 확률), 복구 시간 목표 (장애 최대 허용 시간), 복구 시점 목표 (복구 후 허용 가능한 상태)를 기반으로 장애를 평가
3. 확장성을 위한 아키텍처를 설계하라.
4. 아키텍처는 리더십이다. : 개별 기여 작업을 잘 위임하기.
5. 항상 아키텍처에 충실하라. : 기본 아키텍처에 대해 깊이 이해하고 목표 아키텍처를 개발하며 이것에 대한 시퀀싱 계획을 잘 수립하기
6. 느슨하게 결합된 시스템을 구축하라 : 시스템은 작은 컴포넌트들로 구성됨. 추상화 계층을 통해 다른 서비스와 상호작용하기. 다른 팀의 기술 세부는 걱정하지 않기.
7. 되돌릴 수 있는 의사결정을 하라.
8. 보안 우선순위를 지정하라
   • 강화된 경계 보안 모델 : 기존 보안 모델은 경계를 넘으면 안전하다고 간주함. 하지만 클라우드/분산 환경에서는 이 경계가 의미 없거나 우회되기 쉬움 -> 정체성 기반, 세분화된 권한, 데이터 중심 보안 등을 별도 보안 계층을 적용
9. 핀옵스를 수용하라
   • 사례: AWS 비용 관리 여정 - ab180 블로그 포스트

이 장에서는 다음과 같은 주요 아키텍처 개념들을 설명한다.

1. 도메인과 서비스
2. 분산 시스템, 확장성, 장애 대비 설계 : 수평 확장 사용
3. 결합 : 계층, 모놀리스, 마이크로서비스
4. 사용자 : 싱글, 멀티테넌트
5. 이벤트 기반 아키텍처 : 스트리밍 및 메시징 시스템
6. 브라운필드 / 그린필드 : 레거시 아키텍처 이해하기 / 유행만 쫓지 않기

구체적인 데이터 아키텍처 유형들은 다음과 같다.

• 데이터 웨어하우스
  • 조직 DWA : 운영계와 정보계 분리. 데이터 중앙 집중화 및 구성 (ETL로 데이터 축적적)
  • 기술 DWA : MPP(Massively Parallel Processing) - 마스터 노드가 쿼리 파싱하고 플랜 생성해서 워커 노드로 분산하고 작업 수행
• 데이터 마트 : 단일 부서/ 비즈니스 라인에 초점 맞춰 구성된 DW의 하위 집합
• 데이터 레이크 : 정형과 비정형 데이터를 한곳에서. 맵리듀스, 스파크, 하이브 등 처리 기술 사용 가능. -> 쓰기만을 고려하고 만들어서 결국 사용할 때 관리 비용 급증. (하둡 클러스터 관리와 생태계 이해를 기반으로 한 고급 인력…)
• 데이터 레이크 하우스 : 데이터 레이크처럼 쓸 수 있으면서 ACID 트랜잭션 지원.

여기부터 초면(혹은 잘 모르는)인 데이터 처리 아키텍처다.

• 모던 데이터 스택 : 모듈화 해서 구분하기. 데이터 원천 / 데이터 웨어하우스 / BI와 시각화 … PnP 모듈식 구성
• 람다 아키텍처 : 스트리밍 실시간 프레임워크 등장으로 배치&스트리밍을 단일 아키텍처로 조정할 필요가 생김. 이에 대한 초기 대응 방안으로 배치, 스트림 각각 별도로 받아서 쿼리 결과 집계하는 방식
• 카파 아키텍처 : 람다 단점인 중복 로직관리 편의를 위해 나온 방법. 스트림으로 모두 변환. 복잡하고 비용이 많이 듦.
• 데이터 흐름 모델, 통합 배치, 스트리밍 : 배치 및 스트림 처리의 문제는 이를 통합하는것.
  • 구글은 데이터 흐름 모델, 아파치 빔 프레임워크를 제시.
  • 모든 데이터를 이벤트로 간주하고, 실시간 이벤트 스트림은 무한 데이터이고 배치 이벤트는 유한 이벤트 스트림. 이 개념으로 거의 같은 코드를 사용해 같은 시스템을 이용.
• IoT용 아키텍처
  • 장치(사물) : 최소한의 데이터 수집 전송 능력을 가짐. 이를 전송할 때의 요인들 -> 다운스트림 데이터 수집에 어떤 영향을 미치는지 알아야함.
  • 장치와 인터페이스하는 컴포넌트 : IoT 게이트웨이 (수신처에 라우팅하는 허브. 와이파이 규격), 수집, 스토리지 (메시지 큐나 시계열 db 등), 서빙 등

이 장에서는 다양한 데이터 아키텍처의 구체적 사례들을 나열하며 종류별로 설명했다.

---

4장 데이터 엔지니어링 수명 주기 전체에 걸친 기술 선택

어떤 기준으로 어떤 항목의 기술을 선택해야하는가?

아키텍처는 전략적이고 (무엇을, 왜, 언제에 초점) 도구는 전술적이다. (어떻게에 초점)

완벽함은 우수함 good 의 적이다. 그러니 기술을 얼마나 빠르게 변경할 수 있는지 충분히 고려해야 한다.

이에 따라 수반되는 비용도 고려한다.

• 설비 투자 비용 (온프레미스 이용 / 실제 설비)
• 운영 비용 (클라우드 이용 / 종량제 부과)
• 총 소유 기회비용 : 이 기술을 선택하면 다른 기술로 변경이 어려움
• 핀옵스 : 비용 모니터링으로 적절하게 운용하기

결국 필요할 때 필요한 제품, 기술을 잘 사용하는게 관건인 것 같다. 그러니 아키텍처를 설계하고 사용하는 지금. 현재를 위한 계획을 아래의 기준들을 생각하며 설계한다.

• 구축과 구매
  • 오픈 소스 소프트웨어 (커뮤니티 관리 oss, 상용 oss - 데이터브릭스, 컨플루언트 등)
• 모놀리식과 모듈식
• 서버와 서버리스
• 최적화, 성능, 벤치마킹
  • 요구사항에 맞는 적절한 벤치마킹 비교 필요

---

정리

이번 Part 1 리뷰에서는 데이터 엔지니어링의 정의와 진화, 그리고 이를 구성하는 핵심 아키텍처와 수명 주기를 전체적으로 조망해보았다.
각 장에서는 데이터 엔지니어의 역할 유형(A형/추상화, B형/구축), 수명 주기의 구성 요소, 그리고 우수한 데이터 아키텍처를 설계하기 위한 원칙들을 실무적으로 풀어냈다.

특히 관찰 가능성과 보안, 핀옵스 등 현대적인 운영 관점의 요소들이 아키텍처 전반에 걸쳐 중요하게 다뤄졌다. 람다/카파 아키텍처, 데이터 레이크 하우스, 모던 데이터 스택 등 다양한 처리 모델들을 소개하며 맥락에 따라 기술을 고르는 기준을 제시했다. 기술 선택은 ‘완벽함’이 아닌 ‘변화 대응력’과 ‘적절한 트레이드오프’에 기반해야 한다는 조언은 현실적인 인사이트였다. 끝!