견고한 데이터 엔지니어링 Chapter 2.1 - 데이터 엔지니어링 수명주기

이 글은 스터디 활동에서 진행하는 견고한 데이터 엔지니어링 정리입니다.

견고한 데이터 엔지니어링

---

2.1 데이터 엔지니어링 라이프사이클이란?

데이터 엔지니어링 라이프사이클은 원시 데이터를 유용한 최종 제품으로 전환하는 과정을 설명하는 프레임워크이다. 이 라이프사이클은 데이터를 생성하고, 저장하며, 수집하고, 변환한 후 분석가, 데이터 과학자, ML 엔지니어에게 제공하는 단계를 포함한다. 이 과정은 5단계로 나뉜다.

 

• 데이터 생성
• 데이터 저장
• 데이터 수집
• 데이터 변환
• 데이터 서빙

데이터 엔지니어링 라이프사이클은 원천 시스템에서 데이터를 가져와 저장하는 것으로 시작된다. 저장된 데이터는 변환 과정을 거쳐 분석가, 데이터 과학자, ML 엔지니어에게 제공되며, 이를 통해 데이터가 유용한 정보로 변환된다. 이때 저장은 데이터가 처음부터 끝까지 흐르면서 모든 단계에서 중요한 역할을 하며, 단일한 단계가 아니라 데이터 라이프사이클 전반을 지원하는 기반이다.

 

라이프사이클의 중간 단계인 저장, 수집, 변환 과정은 항상 일정한 순서를 따르지 않으며, 때로는 서로 겹치거나 반복되기도 한다. 이러한 유연성은 라이프사이클을 실질적으로 구현하는 과정에서 중요한 특징이다.

 

또한, 이 라이프사이클을 뒷받침하는 요소로는 보안, 데이터 관리, DataOps, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링과 같은 기반 요소들이 있다. 이들은 데이터 엔지니어링 라이프사이클의 모든 단계에서 필수적이며, 이러한 기반 요소 없이는 데이터 엔지니어링의 각 과정이 제대로 기능하지 못한다.

---

2.1.1 데이터 수명 주기 대 데이터 엔지니어링 수명 주기

데이터 수명 주기와 데이터 엔지니어링 수명 주기는 서로 관련이 있지만, 그 범위에서 차이가 있다. 전체 데이터 수명 주기는 데이터를 생성, 저장, 사용, 폐기하는 전 과정을 포함하며, 조직 내에서 데이터를 처리하는 모든 단계를 포괄한다. 즉, 데이터가 만들어져서 최종적으로 사라지기까지의 모든 과정을 다룬다.

 

반면, 데이터 엔지니어링 수명 주기는 데이터 수명 주기의 하위 집합으로, 데이터 엔지니어가 직접 제어하고 책임지는 단계들에 초점을 맞춘다. 주로 데이터를 수집, 저장, 변환, 제공하는 과정에 집중하며, 데이터가 어떻게 효율적으로 처리되고 전달되는지를 다룬다.

 

따라서 데이터 엔지니어링 수명 주기는 기술적, 운영적 과정을 중심으로 다루는 반면, 전체 데이터 수명 주기는 데이터의 전반적인 관리 및 활용을 포괄하는 더 큰 그림을 다룬다.

 

데이터 엔지니어링 라이프사이클은 전체 데이터 라이프사이클의 하위 집합

---

2.1.2 데이터 생성

원천 시스템(source system)은 데이터 엔지니어링 라이프사이클에서 데이터를 제공하는 출처를 말한다. 이러한 원천 시스템은 다양한 형태를 띨 수 있는데, 예를 들어 IoT 장치, 애플리케이션 메시지 큐, 트랜잭션 데이터베이스 등이 포함된다. 데이터 엔지니어는 이 소스 시스템으로부터 데이터를 가져오지만, 일반적으로 원천 시스템 자체를 소유하거나 제어하지 않으며, 대신 원천 시스템에서 데이터가 어떻게 생성되고 관리되는지 이해하고 작업해야 한다.

 

데이터 엔지니어는 원천 시스템의 작동 방식, 데이터가 생성되는 속도와 빈도, 생성되는 데이터의 종류와 구조에 대해 실무적인 지식을 가져야 하며, 원천 시스템이 변동될 경우에 대비해 시스템 소유자와 긴밀한 소통을 유지할 필요가 있다. 예를 들어, 애플리케이션 코드가 변경되거나 데이터베이스 기술이 새로워지면 파이프라인이 중단될 수 있기 때문이다.

원천 시스템의 예시. 어플리케이션 DB

 

데이터 엔지니어링에서 주요 과제 중 하나는 다양한 소스 시스템을 다루는 것이다. 전통적인 관계형 데이터베이스 관리 시스템(RDBMS)과 같은 원천 시스템은 오랜 기간 동안 많은 애플리케이션에서 사용되어 왔다. 이러한 시스템은 여전히 현대적인 소프트웨어 개발에서 널리 쓰이지만, 최근에는 IoT 군집과 같이 새로운 유형의 원천 시스템이 등장하고 있다. IoT 장치들은 데이터를 중앙 시스템으로 전송하며, 이 방식은 점점 더 일반화되고 있다.

 

따라서 데이터 엔지니어는 전통적인 애플리케이션 데이터베이스에서 최신 IoT 군집에 이르기까지 다양한 원천 시스템을 이해하고, 이 시스템에서 데이터를 효율적으로 수집하고 처리할 수 있는 능력을 가져야 한다.

원천 시스템의 예시. IOT 스원과 메시지 큐

원천 시스템 평가 : 주요 엔지니어링 고려 사항

원천 시스템을 평가할 때 데이터 엔지니어가 고려해야 할 여러 요소가 있다. 이 요소들은 데이터의 특성과 시스템의 작동 방식에 따라 달라지며, 다음과 같은 질문을 통해 원천 시스템의 적합성을 평가할 수 있다.

1. 데이터 원천의 특성: 원천이 애플리케이션 데이터인지, IoT 기기 데이터인지에 따라 접근 방식이 달라진다.
2. 데이터 유지 방식: 원천 시스템이 데이터를 장기간 보관하는지, 아니면 짧은 시간 후 삭제하는지 파악해야 한다.
3. 데이터 생성 속도: 데이터가 초당 얼마나 생성되는지, 데이터량이 시간당 얼마나 되는지 등의 속도를 평가한다.
4. 데이터 일관성: 데이터 품질 검사를 통해 출력 데이터에서 예상치 못한 null 값이나 형식 오류가 얼마나 자주 발생하는지 확인해야 한다.
5. 오류 발생 빈도: 원천 시스템이 오류를 얼마나 자주 발생시키는지도 중요한 평가 요소이다.
6. 데이터 중복성: 중복 데이터의 발생 여부와 중복된 데이터가 다운스트림에 미치는 영향을 고려한다.
7. 데이터 지연: 동시에 생성된 데이터 중 일부가 더 늦게 도착할 가능성을 평가해야 한다.
8. 스키마 구조: 원천 시스템의 데이터 스키마가 어떤 구조인지, 데이터를 분석하기 위해 여러 테이블을 조인해야 하는지 파악해야 한다.
9. 스키마 변경 처리: 스키마가 변경되었을 때 이를 어떻게 처리하고 다운스트림 사용자에게 전달할 것인지에 대한 계획이 필요하다.
10. 데이터 수집 빈도: 원천 시스템에서 데이터를 얼마나 자주 수집해야 하는지 결정해야 한다.
11. 데이터 추적 방식: 상태 저장 시스템의 경우, 데이터가 주기적 스냅샷으로 제공되는지, 아니면 변경 데이터 캡처(CDC) 방식으로 제공되는지 확인한다.
12. 성능에 미치는 영향: 원천 시스템에서 데이터를 읽을 때, 성능에 어떤 영향을 미치는지 고려해야 한다.
13. 업스트림 데이터 종속성: 원천 시스템이 다른 시스템에 종속되어 있는지, 업스트림 시스템의 특성을 파악해야 한다.
14. 데이터 품질 검사: 늦은 데이터나 누락된 데이터를 확인하기 위한 품질 검사가 이루어지고 있는지 확인한다.

원천 시스템의 다양한 속성에 따라 데이터 엔지니어는 데이터를 효율적으로 수집하고 처리하기 위해 이 모든 요소들을 고려해야 한다. 특히 스키마는 시간이 지나면서 진화할 수 있으며, 이를 데이터 파이프라인에서 적절하게 반영해야 한다. 스키마가 없는 시스템은 메시지 큐나 플랫 파일 등을 활용해 데이터를 관리하고, 고정된 스키마는 전통적인 관계형 데이터베이스에서 사용하는 방식이다.

 

스키마(schema)는 데이터의 계층적 구조와 조직 방식을 정의하는 중요한 개념이다. 데이터 엔지니어가 처리하는 원천 시스템에서의 데이터는 스키마에 의해 구조화되어 있으며, 이는 데이터 변환 및 분석 과정에서 중요한 역할을 한다. 스키마의 두 가지 주요 유형은 "스키마리스"와 "고정된 스키마"로 나뉜다.

정의	미리 정의된 데이터 구조로, 테이블, 필드, 데이터 타입이 고정되어 있음.	동적 데이터 구조로, 애플리케이션이 데이터를 저장할 때 그 구조를 정의함.
사용 환경	관계형 데이터베이스 (예: MySQL, PostgreSQL 등)	NoSQL 및 문서형 데이터베이스 (예: MongoDB, Cassandra 등)
유연성	낮음 – 스키마 변경 시, 전체 데이터베이스 구조를 수정해야 함.	높음 – 스키마를 사전에 정의할 필요가 없으며, 데이터가 유동적임.
관리 편의성	안정적 – 미리 정의된 구조로 데이터 일관성이 유지됨.	유동적 – 스키마 변화에 따라 유연하게 대응할 수 있지만, 구조적 일관성이 떨어질 수 있음.
변경 처리	변경이 어렵고 복잡함 – 스키마를 변경할 때 마이그레이션 작업이 필요함.	변경이 용이함 – 새로운 필드를 추가하거나 데이터 구조를 변경하는 것이 비교적 간단함.
데이터 일관성	매우 높음 – 데이터 구조가 고정되어 있어 데이터 품질 및 일관성 유지가 쉬움.	중간 – 데이터 구조가 자유로워 일관성이 떨어질 수 있으며, 데이터 불일치 가능성이 있음.
예시	고객 테이블에 있는 이름, 주소, 생년월일 필드가 고정됨.	JSON 문서에서 이름, 주소 필드를 사용하지만, 생년월일 필드는 나중에 추가될 수 있음.
적합한 사용 사례	명확한 구조와 일관성을 요구하는 경우  ex) 금융, ERP 시스템 등	빠른 개발과 유연성이 필요한 경우  ex) 소셜 미디어, IoT 데이터 등

 

스키마는 Agile 소프트웨어 개발 방식에 따라 지속적으로 진화할 수 있으며, 데이터 엔지니어는 이러한 변화에 대응해 데이터를 효율적으로 변환하고 분석해야 한다. 스키마 변화는 데이터 파이프라인을 유연하게 설계하는 것이 핵심 과제 중 하나이며, 스키마의 불일치와 데이터 품질 저하를 방지하기 위해 신속한 대응이 필요하다.

 

데이터 저장

데이터 저장은 데이터 엔지니어링 라이프사이클에서 중요한 단계이며, 성공적인 데이터 처리에 필수적이다. 특히 클라우드 아키텍처에서는 여러 스토리지 솔루션을 조합하여 사용한다. 이러한 스토리지는 단순히 데이터를 저장하는 것 이상의 기능을 제공하며, 복잡한 쿼리와 데이터 변환도 지원한다.

 

저장 시스템은 수집, 변환, 제공 단계와 상호작용하며, 전체 데이터 파이프라인에 걸쳐 데이터를 처리하는 방식에 영향을 미친다. 예를 들어, 클라우드 데이터 웨어하우스는 데이터를 저장하고 처리할 수 있으며, 스트리밍 시스템인 Apache Kafka와 Pulsar는 데이터를 실시간으로 수집하고 저장하며 쿼리까지 가능하게 한다.

 

결국, 데이터 저장 방식은 데이터 엔지니어링 라이프사이클의 다른 모든 단계와 긴밀하게 연결되어 있어, 성능과 효율성을 최적화하는 것이 매우 중요하다.

저장 시스템 평가: 주요 엔지니어링 고려 사항

저장 시스템을 평가할 때 고려해야 할 주요 엔지니어링 질문들은 데이터 저장 방식의 성능, 확장성, 그리고 데이터 수명 주기 전반에 걸친 적합성을 평가하는 데 도움을 준다. 다음은 저장 시스템을 선택할 때 고려해야 할 주요 질문들이다.

 

• 쓰기 및 읽기 속도: 해당 스토리지 솔루션이 아키텍처에서 요구하는 쓰기 및 읽기 속도를 충족할 수 있는지 확인해야 한다.
• 병목 현상 방지: 저장 시스템이 다운스트림 프로세스에서 병목 현상을 일으키지 않는지 평가해야 한다.
• 스토리지 기술의 이해 및 최적 활용: 선택한 스토리지 기술을 충분히 이해하고, 이를 최적으로 사용하고 있는지 평가해야 한다. 예를 들어, 객체 스토리지에서 랜덤 액세스 업데이트를 사용하는 것은 성능 저하를 일으킬 수 있다.
• 미래 확장성: 스토리지 시스템이 예상되는 미래의 데이터 규모를 처리할 수 있는지 확인해야 한다. 총 스토리지 용량, 읽기 및 쓰기 처리 속도 등의 한계를 고려해야 한다.
• SLA 준수: 다운스트림 프로세스가 요구하는 서비스 수준 계약(SLA)을 충족할 수 있는지 확인해야 한다.
• 메타데이터 관리: 스키마 진화, 데이터 흐름, 데이터 계보 등의 메타데이터를 적절하게 관리하고 캡처할 수 있는지 평가해야 한다. 메타데이터는 미래의 프로젝트와 아키텍처 변경에 대비하는 중요한 요소이다.
• 저장 솔루션의 유형: 스토리지가 순수한 객체 스토리지인지, 또는 복잡한 쿼리 패턴을 지원하는 클라우드 데이터 웨어하우스인지에 따라 다른 고려 사항이 필요하다.
• 스키마 처리 방식: 스토리지 시스템이 스키마에 구애받지 않는지(객체 스토리지), 유연한 스키마를 사용하는지(Cassandra), 혹은 강제된 스키마를 사용하는지(클라우드 데이터 웨어하우스)를 확인해야 한다.
• 데이터 거버넌스 및 추적: 마스터 데이터, 골든 레코드, 데이터 품질, 데이터 계보를 어떻게 추적하고 관리할 것인지에 대한 전략이 필요하다. 데이터 거버넌스는 데이터 품질을 유지하고 규제에 준수하기 위해 필수적이다.
• 규제 및 데이터 주권: 스토리지가 지리적 규제와 데이터 주권을 준수하는지 확인해야 한다. 예를 들어, 특정 지역에는 데이터를 저장할 수 있지만, 다른 위치에는 저장할 수 없는 경우가 있을 수 있다.

 

 

데이터 접근 빈도의 이해와 저장 시스템

데이터 접근 빈도를 이해하는 것은 효율적인 스토리지 솔루션을 선택하는 데 중요한 요소이다. 데이터는 그 "접근 빈도에 따라 '온도'"로 분류되며, 이 온도 개념에 따라 데이터를 저장할 위치와 방식을 결정할 수 있다.

1. 핫 데이터 (Hot Data) : 가장 자주 액세스되는 데이터로, 하루에도 여러 번, 심지어 초당 여러 번 검색되는 데이터이다. 주로 사용자 요청을 처리하는 시스템에서 사용되며, 빠른 검색이 필수적이다. 이러한 데이터는 고속 검색을 지원하는 스토리지 시스템에 저장해야 한다.
2. 미온적 데이터 (Warm Data) : 비교적 적게 액세스되는 데이터로, 주로 매주나 매달 정도로 검색된다. 핫 데이터만큼 자주 사용되지 않으나, 여전히 가끔씩 필요하다.
3. 콜드 데이터 (Cold Data) : 거의 쿼리되지 않는 데이터로, 장기 보관용으로 적합하다. 콜드 데이터는 규정 준수 목적으로 저장되거나, 다른 시스템에서 발생할 수 있는 치명적인 오류에 대비해 백업 데이터로 보관된다. 클라우드 환경에서는 저렴한 보관 비용을 제공하지만, 검색 시 비용이 높을 수 있는 특수 스토리지 계층이 제공된다.

---

2.1.4 데이터 수집

데이터 소스와 원천 시스템의 특성, 그리고 데이터가 어떻게 저장되는지 이해했다면, 다음 단계는 데이터를 수집하는 것이다. 데이터 엔지니어링 라이프사이클에서 원천 시스템에서 데이터를 수집하는 과정은 매우 중요하다.

 

데이터 수집의 주요 과제는 원천 시스템이 데이터 엔지니어의 직접적인 제어 하에 있지 않다는 점에서 발생한다. 원천 시스템은 때때로 무작위로 반응하거나, 품질이 떨어지는 데이터를 제공할 수 있으며, 이러한 문제로 인해 데이터 흐름이 중단될 위험이 있다. 또한, 데이터 수집 서비스가 여러 이유로 중단되거나 예기치 않게 작동을 멈출 수도 있다. 이로 인해 저장, 처리, 제공 과정에 필요한 충분한 데이터가 확보되지 못할 수 있다.

 

신뢰할 수 없는 원천 시스템과 수집 과정은 데이터 엔지니어링 전체에 영향을 미치며, 특히 데이터 파이프라인의 다른 단계에서 병목 현상을 초래할 수 있다. 따라서 원천 시스템의 특성과 데이터를 수집하는 과정에서 발생할 수 있는 문제들을 미리 파악하고 대비하는 것이 중요하다.

 

결국, 원천 시스템에서 데이터 수집의 주요 질문과 문제에 대해 명확하게 이해하고 대비한다면, 데이터 엔지니어링 라이프사이클에서 수집 단계는 더 안정적으로 진행될 수 있다.

배치 vs 스트리밍

배치와 스트리밍 방식은 데이터 수집과 처리에서 중요한 선택지이다. 각 방식은 특정한 사용 사례와 요구 사항에 따라 적합한 상황이 달라지며, 각각의 장점과 단점이 있다.

 

특징	배치 처리	스트리밍 처리
처리 방식	일괄 처리	실시간 처리
데이터 적시성	처리 완료 시점에만 데이터 사용 가능	데이터 생성 후 바로 사용가능
사용 사례	분석, 머신 러닝, 주기 적인 대규모 데이터 처리	실시간 모니터링, 금융 거래 감시, 실시간 사용자 행동 분석
장점	대규모 데이터를 효과적으로 처리, 자원소모 적음	즉시 데이터를 처리, 응답 가능, 빠른 피드백 가능
단점	대량의 데이터를 한 번에 처리하여 자원 효율성이 높음	실시간 처리로 인해 자원이 많이 소모될 수 있음
적합한 데이터 유형	주기적으로 발생하는 대규모 데이터	연속적으로 발생하는 데이터 (실시간 로그, 사용자 활동 등)
다운스트림 시스템 연동	배치 완료 후에만 다운스트림 시스템에 데이터 제공	실시간으로 다운스트림 시스템에 데이터 제공

배치와 스트림 수집에 대한 주요 고려사항

스트리밍 수집과 배치 수집을 선택할 때는 여러 요소를 고려해야 한다. 실시간 데이터 수집이 필요한지, 다운스트림 시스템이 그 속도를 감당할 수 있는지부터 시작해서, 스트리밍 수집이 주는 이점과 그에 따른 추가 비용과 유지 관리의 복잡성을 모두 평가해야 한다.

 

• 데이터 흐름 속도 처리: 실시간으로 데이터를 수집할 경우, 다운스트림 시스템이 그 데이터를 처리할 수 있는지를 평가해야 한다. 스트리밍은 빠르게 데이터를 처리하므로 시스템이 과부하되지 않도록 주의해야 한다.
• 실시간 필요성: 실시간으로 데이터를 처리할 필요가 있는지, 아니면 몇 분 단위로 데이터를 축적하는 마이크로 배치가 적절한지 고려해야 한다. 실시간 처리가 꼭 필요한 상황인지 확인하는 것이 중요하다.
• 사용 사례 분석: 스트리밍 수집이 해당 프로젝트에 실질적으로 어떤 이점을 제공하는지 파악해야 한다. 배치 처리보다 어떤 점에서 더 나은 결과를 얻을 수 있는지 검토해야 한다.
• 비용 및 유지 관리: 스트리밍 방식은 배치 방식보다 더 많은 자원, 비용, 유지 관리가 필요할 수 있다. 이를 통해 장기적인 운영 비용이 어떻게 변할지 분석해야 한다.
• 시스템 안정성 및 중복성: 스트리밍 수집이 안정적으로 작동하고, 장애 시에도 시스템이 복구 가능하도록 중복성을 확보하는 것이 중요하다.
• 적합한 도구 선택: 관리형 서비스(Amazon Kinesis, Google Cloud Pub/Sub)를 선택할지, 오픈소스 솔루션(Kafka, Flink 등)을 직접 구축할지 결정해야 한다. 관리형 서비스는 쉽게 운영되지만, 비용이 더 많이 들 수 있으며, 자체 구축은 유연하지만 관리 복잡성이 크다.
• ML 모델 및 예측 시스템: 머신러닝 모델을 사용 중이라면 실시간 데이터를 활용하여 온라인 예측과 지속적 학습을 제공할 수 있는지 확인해야 한다.
• 프로덕션 환경 영향: 실시간 수집이 프로덕션 환경에 부하를 주지 않는지 평가해야 한다. 실시간 수집이 시스템 성능에 어떤 영향을 미치는지 분석하는 것이 필요하다.

 

스트리밍은 실시간 데이터 처리의 장점을 제공하지만, 관리 비용이 높고 인프라에 장애가 발생할 경우에도 안정성을 유지해야 한다. 반면, 배치 처리는 안정적이고 자원 효율적이지만 실시간 데이터를 제공하지 못한다는 한계가 있다.

 

따라서 스트리밍을 도입하기 전, 실시간 처리가 정말 필요한지, 어떤 구체적인 이점을 제공할지, 또한 인프라가 안정적이고 비용 대비 효율적인지 철저히 검토한 후 도입하는 것이 중요하다. 머신러닝 모델과 같은 시스템에서 실시간 데이터를 활용하는 경우도 이러한 고려 사항에 포함될 수 있다.

푸시 vs 풀

데이터 수집 방식에는 푸시(Push)와 풀(Pull) 모델이 있으며, 이 두 가지 방식은 데이터를 소스 시스템에서 어떻게 수집하는지에 따라 구분된다.

구분	푸시(Push)	풀(Pull)
작동 방식	원천 시스템에서 데이터를 직접 보내는 방식	수직 시스템이 데이터를 요청하여 가져오는 방식
데이터 전달 주체	원천 시스템	수집 시스템
데이터 전달 시점	데이터 발생 시 즉시 전송	수집 시스템이 주기적으로 요청하여 데이터를 사져옴
장점	실시간 데이터 처리에 적합	주기적 대규모 데이터 수집에 적합
단점	소스 시스템의 부하가 증가할 수 있음	데이터 전송 지연 및 일정한 간격으로만 처리 가능

 

 

• 푸시 모델: 메시지 큐에서 소스 시스템이 데이터베이스 변경 사항을 감지할 때마다 큐에 푸시하여 처리하는 방식. 예를 들어, 애플리케이션에서 사용자 이벤트가 발생하면 그 데이터를 실시간으로 메시지 큐에 보내는 구조다.
• 풀 모델: ETL 프로세스에서 수집 시스템이 정해진 시간마다 소스 시스템(예: 데이터베이스)에서 데이터를 가져오는 방식이다. 예를 들어, 매일 밤 일정 시간에 고객 데이터를 업데이트하기 위해 소스 데이터베이스에서 데이터를 풀링해 가져오는 것을 생각할 수 있다.

스트리밍 수집은 데이터를 실시간으로 지속적으로 전송하는 방식이다. 푸시 모델의 일종으로, 소스 시스템에서 발생하는 데이터를 즉시 엔드포인트로 전송하여 실시간으로 처리할 수 있다.

 

이 방식은 주로 IoT 센서, 실시간 로그 분석, 금융 거래 모니터링 같은 애플리케이션에서 사용된다. 데이터를 쌓아두지 않고 실시간으로 분석하거나 처리해야 할 때 스트리밍 수집이 매우 유용하다. 예를 들어, 수많은 센서에서 수집된 데이터는 실시간으로 서버에 전송되어 바로 분석되고, 필요한 대응이 즉시 이루어질 수 있다.

 

푸시와 풀 방식은 각각 실시간 처리와 주기적 데이터 수집에 적합하며, 스트리밍 수집은 실시간 데이터 처리가 필요한 환경에서 필수적인 방법이다.

---

 

2.1.5 데이터 변환

데이터를 수집하고 저장한 후, 데이터 엔지니어링 라이프사이클의 다음 단계는 변환이다. 변환은 데이터를 원래의 형태에서 다운스트림 사용 사례에 맞게 변경하는 작업이다. 변환되지 않은 데이터는 유용하지 않기 때문에, 이 단계에서 데이터는 보고서, 분석, 머신러닝(ML) 등의 목적에 맞는 형태로 변환된다.

 

변환의 기본 단계는 다음과 같다.

 

• 데이터 형식 변환: 수집된 데이터를 올바른 데이터 유형으로 변환. 예를 들어, 문자열 데이터를 숫자나 날짜 형식으로 변환하거나, 불필요한 데이터를 제거하는 작업.
• 스키마 변환 및 정규화: 데이터 구조를 변경하고, 정규화를 적용하여 데이터를 표준화.
• 데이터 기능화: 머신러닝 모델 학습을 위해 데이터를 기능으로 추출하는 과정.

변환 단계에서 고려할 주요 사항

1. 비용과 투자 수익률(ROI): 변환 과정에 드는 비용과 이에 따른 사업적 가치를 고려해야 한다. 이 과정이 실제로 비즈니스에 얼마나 기여할 수 있는지 평가하는 것이 중요하다.
2. 변환의 단순성과 고립성: 변환 작업은 가능한 한 단순하고, 다른 프로세스에 영향을 미치지 않도록 고립되어야 한다.
3. 비즈니스 규칙 반영: 변환 과정에서 비즈니스 로직이 반영되어야 한다. 예를 들어, 판매 데이터에서 총 매출을 계산하는 것처럼, 변환 작업은 비즈니스 프로세스를 명확히 반영할 수 있어야 한다.
4. 변환 방식의 선택: 배치 처리 또는 스트리밍 처리를 선택할 수 있다. 모든 데이터는 기본적으로 스트리밍 형태로 시작되며, 배치는 이러한 스트림을 대량 처리하는 특수한 방법이다. 최근에는 스트리밍 방식이 더욱 인기를 얻고 있으며, 특정 도메인에서는 배치 처리를 대체할 가능성도 있다.

변환은 독립적인 작업처럼 보이지만, 실제로는 데이터 라이프사이클의 다른 단계와 밀접하게 얽혀 있다. 예를 들어, 소스 시스템에서 데이터를 수집하는 동안 이미 일부 변환 작업이 이루어질 수 있으며, 스트리밍 파이프라인 내에서도 추가적인 변환 작업이 이루어진다.

• 예시: 데이터가 웨어하우스로 전송되기 전에 추가 필드와 계산이 더해져 '보강'될 수 있다.

데이터 변환은 종종 비즈니스 로직에 의해 좌우된다. 데이터는 비즈니스 규칙을 반영하여 재사용 가능한 요소로 변환되며, 이를 통해 다운스트림 사용자가 데이터를 활용할 수 있게 된다. 예를 들어, 판매 데이터를 통해 총 매출을 계산하는 것이 그 예이다. 변환 단계에서는 이러한 비즈니스 로직을 명확하게 구현하는 것이 중요하다.

 

머신러닝(ML)에서는 데이터 변환의 중요한 부분이 기능화이다. 이는 모델 학습에 필요한 데이터를 추출하고 향상시키는 과정으로, 도메인 전문 지식과 데이터 과학 경험을 결합해야 하는 복잡한 작업이다. 데이터 과학자가 기능화를 결정하면, 데이터 엔지니어는 이를 파이프라인에서 자동화할 수 있다.

 

변환은 데이터 엔지니어링 라이프사이클의 중요한 단계로, 데이터를 유용한 형태로 변경하여 가치를 창출하는 역할을 한다. 변환 과정은 비즈니스 로직, 머신러닝을 위한 기능화, 그리고 데이터를 활용할 수 있는 최적의 방식으로 이루어져야 한다.

 

데이터 서빙

데이터 엔지니어링 라이프사이클의 마지막 단계는 데이터 제공(서빙)이다. 이 단계에서는 수집, 저장, 변환된 데이터를 실제로 사용하여 가치를 창출하게 된다. 데이터를 사용함으로써 실질적인 목적을 달성할 수 있으며, 그렇지 않으면 데이터는 단순히 쌓여 있는 비활성 자산에 불과하다.

 

데이터에서 가치를 얻는다는 것은 사용자마다 다른 의미를 지닐 수 있다. 데이터를 활용하여 비즈니스 의사결정을 개선하거나, 실시간 분석을 수행하거나, 머신러닝 모델을 학습시킬 수 있다. 하지만 데이터가 실제로 실용적인 목적에 사용되지 않으면, 그 데이터는 의미를 잃는다.

 

데이터 허영(vanity) 프로젝트는 이러한 무가치한 데이터의 집합을 의미한다. 많은 회사가 빅데이터 시대에 들어서면서, 데이터 레이크에 방대한 데이터를 쌓아두기만 하고 이를 유용하게 사용하지 않는 실수를 저질렀다. 클라우드 기술과 최신 데이터 웨어하우스, 스트리밍 시스템도 이러한 허영 프로젝트의 위험성을 내포하고 있다. 따라서 데이터를 수집하는 과정에서부터 궁극적인 비즈니스 목적을 염두에 두어야 한다.

 

데이터 제공은 데이터 엔지니어링 라이프사이클에서 가장 흥미로운 단계 중 하나이다. 이 단계에서 데이터를 소비하는 다양한 방식들이 등장하며, 이를 통해 데이터가 실제 비즈니스에 기여하게 된다. 머신러닝(ML) 엔지니어들은 이 단계에서 고급 기술을 적용하여 데이터를 활용할 수 있으며, 이를 통해 분석, ML 모델 훈련, 역방향 ETL 등의 작업을 진행한다.

 

• 분석(Analytics): 데이터는 비즈니스 인사이트를 제공하기 위해 분석된다. 비즈니스 인텔리전스(BI) 도구를 통해 보고서와 대시보드를 만들고, 실시간 데이터를 기반으로 중요한 의사결정을 내리는 데 도움을 준다.
• 머신러닝(ML): ML 엔지니어들은 데이터를 활용하여 모델을 학습시키고, 예측 및 분류 작업에 사용한다. 데이터는 기능화 과정을 통해 머신러닝 모델에 적합한 형태로 제공된다.
• 역방향 ETL(Reverse ETL): 처리된 데이터를 다시 소스 시스템으로 보내는 작업이다. 예를 들어, 분석된 데이터를 마케팅 자동화 시스템으로 보내거나, 머신러닝 모델의 예측 결과를 CRM 시스템으로 다시 통합할 수 있다.

데이터 엔지니어링의 마지막 단계인 데이터 제공은 데이터를 비즈니스에 실질적으로 적용하여 가치를 창출하는 핵심 단계이다. 데이터가 잘 수집되고 변환되었다면, 이 단계에서 데이터를 실제로 활용해 분석, 머신러닝, 역방향 ETL과 같은 다양한 방식으로 가치를 극대화할 수 있다.

 

분석

 분석(Analytics)은 대부분의 데이터 작업에서 핵심적인 역할을 한다. 데이터가 저장되고 변환된 후에는 이를 바탕으로 보고서와 대시보드를 생성하고, 임시 분석을 수행할 준비가 된다. 분석은 비즈니스 인텔리전스(BI)뿐만 아니라 운영 분석, 임베디드 분석과 같은 다양한 형태로 나타난다.

분석 유형

 

 

비즈니스 인텔리전스 (BI)

 

비즈니스 인텔리전스는 과거와 현재의 기업 상태를 설명하기 위해 데이터를 수집하고 분석하는 방식이다. BI는 비즈니스 로직을 적용하여 원시 데이터를 처리하고, 이를 바탕으로 보고서와 대시보드를 생성한다. BI 시스템에서는 데이터가 깨끗한 형태로 저장되며, 비즈니스 로직은 보고서와 대시보드가 정확한 결과를 도출하도록 돕는다.

 

셀프 서비스 분석이 가능한 수준에 도달한 회사에서는 비즈니스 사용자가 IT의 개입 없이 데이터를 직접 분석할 수 있다. 그러나 이는 데이터 품질, 조직 내 사일로, 데이터 기술 부족 등의 문제로 인해 실행하기 어려운 경우가 많다.

 

운영 분석 (Operational Analytics)

 

운영 분석은 주로 현재의 운영 상태에 대한 분석에 초점을 맞추며, 실시간 대시보드 또는 인벤토리 상태와 같은 데이터를 사용하여 즉시 실행할 수 있는 통찰력을 제공한다. 운영 분석은 과거보다는 현재와 실시간 데이터에 집중하며, 실시간으로 조치를 취할 수 있도록 한다. 이는 전통적인 BI와 달리, 실시간 데이터 스트리밍이나 파이프라인을 통해 데이터를 처리하는 것이 특징이다.

 

임베디드 분석 (Embedded Analytics)

 

임베디드 분석은 SaaS 플랫폼 등에서 고객에게 제공되는 분석으로, 내부 BI와는 다른 복잡한 요구 사항을 갖는다. 예를 들어, 기업은 수천 명의 고객에게 개별적인 데이터와 분석을 제공해야 하며, 이 과정에서 각 고객은 오직 자신의 데이터에만 접근할 수 있어야 한다.

 

임베디드 분석은 접근 제어가 매우 복잡하고 중요하다. 기업 내 데이터 유출이 발생할 경우 큰 신뢰 위반으로 이어질 수 있으며, 고객 손실 및 평판에 심각한 영향을 미칠 수 있다. 따라서 데이터 보안 및 액세스 제어는 임베디드 분석에서 가장 중요한 요소 중 하나이다.

 

따라서 분석은 기업 내 데이터를 활용하여 중요한 통찰력을 제공하는 핵심 요소로, BI, 운영 분석, 임베디드 분석의 세 가지 주요 형태로 나타난다. 각각의 분석 형태는 다루는 데이터의 시점과 목적에 따라 차이가 있으며, 데이터 품질, 보안, 액세스 제어 등 다양한 요소들이 성공적인 분석을 위한 필수 조건이 된다.

 

멀티 테넌시란?

멀티테넌시는 현대의 스토리지 및 분석 시스템에서 중요한 기능 중 하나로, 여러 고객(테넌트)이 동일한 시스템이나 인프라를 공유하면서도 각자의 데이터가 격리되고 보안이 유지되도록 하는 구조를 의미한다. 데이터 엔지니어는 이러한 멀티테넌시 환경에서 여러 고객의 데이터를 공통 테이블에 저장하면서도 각 고객이 자신의 데이터만 논리적 뷰를 통해 접근할 수 있도록 설정할 수 있다.

이를 구현하기 위해서는 적절한 컨트롤과 필터가 필요하며, 고객 간의 데이터가 혼재되지 않도록 보장해야 한다. 데이터 엔지니어는 이러한 구조를 설정할 때 데이터 보안과 격리에 대한 세부 사항을 깊이 이해하고 있어야 하며, 각 고객의 데이터가 철저히 보호될 수 있도록 설계해야 한다.

이와 같은 멀티테넌시 시스템은 효율적인 자원 활용을 가능하게 하지만, 동시에 데이터 보안과 프라이버시에 대한 높은 수준의 요구 사항을 만족시켜야 한다.

머신 러닝

머신러닝(ML)의 도입은 많은 기업에서 가장 흥미로운 기술 발전 중 하나로 꼽힌다. 기업이 충분한 데이터 성숙도를 달성하게 되면, 그들은 머신러닝을 통해 해결할 수 있는 문제들을 발견하고 이를 기반으로 실무를 조직할 수 있게 된다.

 

데이터 엔지니어의 역할은 분석과 머신러닝 사이에서 많은 부분이 겹친다. 데이터 엔지니어링, ML 엔지니어링, 그리고 분석 엔지니어링 사이의 경계는 매우 모호하다. 데이터 엔지니어는 분석 파이프라인뿐만 아니라, 머신러닝 모델을 학습시키는 데 필요한 인프라도 지원해야 한다. 예를 들어, 데이터 엔지어는 ML 모델 학습을 위한 Spark 클러스터를 유지하고, 팀 간의 작업을 조율하며 데이터 계보를 추적하는 시스템을 제공하는 책임을 맡을 수 있다.

 

최근 데이터 엔지니어링과 머신러닝을 결합한 도구로 피처 스토어가 많이 사용되고 있다. 피처 스토어는 피처의 버전과 이력을 관리하고, 팀 간 피처를 공유하며, ML 엔지니어의 부담을 덜어주기 위한 운영 기능을 제공한다. 데이터 엔지니어는 이 시스템을 지원하는 핵심 역할을 맡아 머신러닝 작업을 지원하게 된다.

 

Feature store 는 data engineer와 data scientist의 업무를 매개해주는 중앙 창고 https://medium.com/daria-blog/feature-store-%EB%9E%80-4c53d18c1149

 

데이터 엔지니어가 머신러닝에 대한 이해를 가지는 것은 매우 중요하다. 기본적인 머신러닝 기술뿐만 아니라 데이터 처리 요구사항, 회사 내 ML 모델 사용 사례, 그리고 조직 내 각 분석 팀의 책임을 알고 있어야 효율적인 커뮤니케이션과 협업이 가능하다. 데이터 엔지니어는 다른 팀과 협력하여, 독립적으로는 만들기 어려운 시스템과 도구를 구축하는 데 중추적인 역할을 하게 된다.

 

기업이 머신러닝을 도입할 때는 몇 가지 중요한 사항을 고려해야 한다. 첫째, 머신러닝 모델이 신뢰할 수 있는 데이터를 바탕으로 구축되었는지 확인해야 한다. 품질이 낮은 데이터는 부정확한 결과를 초래할 수 있기 때문에 데이터 품질에 대한 평가가 필요하다. 둘째, 데이터 과학자와 머신러닝 엔지니어가 필요한 데이터를 쉽게 발견할 수 있도록 데이터 접근성을 보장해야 한다. 셋째, 데이터 엔지니어링과 머신러닝 엔지니어링 사이의 기술적, 조직적 경계를 명확히 하는 것이 중요하다. 마지막으로, 사용되는 데이터 세트가 실제 사실을 반영하고 있으며, 편향되지 않았는지 신중히 검토해야 한다.

 

기업들이 머신러닝 도입을 서두르다가 실패하는 경우가 많다. 적절한 기반 없이 머신러닝에 투자하는 것은 위험할 수 있다. ML을 성공적으로 적용하기 위해서는 우선 견고한 데이터 인프라를 구축해야 하며, 분석 역량을 충분히 개발한 후에 머신러닝 프로젝트를 진행하는 것이 바람직하다.

역 ETL

역방향 ETL은 데이터 엔지니어링 라이프사이클에서 처리된 데이터를 다시 소스 시스템으로 되돌려 보내는 작업이다. 과거에는 역방향 ETL이 비효율적이고 수동적인 패턴으로 간주되어 크게 주목받지 못했으나, 최근에는 분석 및 머신러닝에서 얻은 결과를 프로덕션 시스템이나 SaaS 플랫폼으로 다시 공급하는 중요한 과정으로 자리 잡고 있다.

 

예를 들어, 마케팅 분석가가 데이터 웨어하우스에서 데이터를 분석하고 이를 기반으로 입찰 전략을 세운 후, 이를 Google Ads와 같은 광고 플랫폼에 다시 업로드하는 과정을 역방향 ETL이라고 할 수 있다. 과거에는 이러한 작업이 수동적이고 복잡했지만, Hightouch, Census 등의 도구가 등장하면서 자동화된 역방향 ETL 작업이 가능해졌다.

 

역방향 ETL은 특히 SaaS 플랫폼이나 CRM 시스템 같은 외부 시스템으로 데이터를 푸시하는 데 유용하다. 예를 들어, 기업은 데이터 웨어하우스에서 분석된 고객 지표를 CRM으로 다시 보내 고객 관리에 활용할 수 있다. 이는 Google Ads처럼 데이터를 다시 외부 광고 플랫폼으로 보내는 것도 가능하게 해준다.

 

향후, 데이터 엔지니어링과 ML 엔지니어링의 발전에 따라 역방향 ETL의 사용이 더욱 활발해질 것으로 예상된다. 다만, 이 개념이 계속해서 "역방향 ETL"이라는 이름을 유지할지는 불확실하며, 기술이 진화하면서 데이터 스트림을 통해 실시간으로 변환된 데이터를 소스 시스템으로 다시 전송하는 방식이 주류가 될 수 있다. 결국, 중요한 것은 변환된 데이터가 소스 시스템으로 올바르게 반환되고, 그 과정에서 계보와 비즈니스 프로세스가 적절히 관리되는 것이다.