DB to Data Flow: 내가 데이터 엔지니어링을 선택한 이유

요즘 나는 종종 생각한다. 왜 나는 DB가 아니라 데이터 엔지니어링을 하고 싶을까?

결론부터 말하면, 관심은 데이터베이스에서 시작했지만 여러 번의 경험을 통해 문제의 본질이 결국 데이터가 어떻게 흐르고 운영되는가에 있다는 걸 체감했기 때문이다.
특히 DB를 튜닝해도 전체가 빨라지지 않는 순간을 겪으면서 시선이 저장에서 엔드투엔드(end-to-end) 흐름으로 옮겨갔다.

출발점: 관심은 DB였다

학부 시절, 데이터베이스와 화일구조의 수업이 Database에 대한 관심을 불러일으켰다. 특히, Indexing 부분에 많은 관심이 있었다. “어떻게 저장하고, 어떻게 더 빠르게 찾을까?”라는 질문이 계속 머릿속을 맴돌았다.

그 뒤로는, 시계열 데이터베이스(Time-series Database) 자체가 흥미로웠다. 데이터를 어떻게 저장하고, 어떻게 더 빠르게 읽게 만들지에 집중했다.

그때는 저장 매체의 한계가 특히 크게 보였다. HDD가 병목이 되는 지점을 체감했고, 저장 성능이 전체 시스템의 핵심이라고 생각했다.

관점 전환: 저장에서 흐름으로

하지만 환경이 바뀌었다. 저장소가 빨라질수록, 오히려 병목은 다른 곳에서 더 크게 드러났다. 네트워크 전송, CPU 처리, 그리고 데이터 가공 파이프라인이 시스템 전체 성능과 안정성을 좌우했다.

그때부터 관점이 바뀌었다.

• “DB를 잘 만드는 것”만으로는 충분하지 않았다.
• 데이터를 필요한 형태로 가공해, 필요한 곳까지 안정적으로 흐르게 만드는 일이 핵심이었다.

확신의 계기: COSMOS를 바라보는 방식

COSMOS 프로젝트를 진행하면서 이 관점이 더 선명해졌다.

COSMOS를 간단히 설명하면, 델타(append 중심, 변경/버전이 누적되는) 저장 환경에서 발생하는 비용 문제를 다룬 프로젝트다.
이런 환경에서는 데이터 파일이 계속 쌓이면서 원하는 레코드를 찾기 위한 스캔 비용이 커지고, 전통적인 B+Tree 기반 인덱스는 유지 비용과 저장 오버헤드가 커지기 쉽다.

COSMOS는 이런 특성에 맞춰 B+Tree 기반 인덱싱의 대안 구조를 설계해, 쓰기/변경이 계속 일어나는 저장 형태에서도 인덱스 유지 비용과 공간 사용량을 크게 줄이면서 조회 성능을 확보하는 것을 목표로 했다.

결과는 다음과 같았다.

• 저장 공간 최대 96% 감소
• 특정 쿼리에서 최대 40배 성능 개선

이 경험은 데이터를 다루는 일이 재미있다는 생각을 넘어, 어떤 문제를 풀고 싶은가를 더 구체적으로 만들어줬다.
저장 구조를 개선하는 것만으로도 큰 효과를 볼 수 있지만, 그렇다고 넘쳐나는 데이터를 한 바구니에 담을 수는 없다. 데이터 규모가 커질수록 결국 분산 환경에서 어떻게 효율적으로 저장하고, 어떻게 효율적으로 조회할 것인가가 핵심이 된다고 느꼈다.

그리고 결정적으로, 저장 최적화가 의미 있으려면 그 앞뒤의 과정—수집(ingest)·가공(transform)·제공(serve)—까지 포함한 데이터 흐름 전체가 안정적이어야 한다는 점도 더 분명해졌다.

지금의 목표: 프로젝트에서 운영으로

지금까지의 학습은 내가 원하는 프로젝트 중심이었다. 앞으로는 실제 고객이 원하는 서비스 환경에서 데이터 파이프라인을 설계하고, 장애와 병목을 발견하고, 개선을 반복하는 경험을 쌓고 싶다.

그래서 내가 꿈꾸는 Data Engineer는 단순 구현자가 아니다. 운영 환경에서 데이터 흐름의 품질과 효율을 끝까지 책임지는 사람에 가깝다.

예를 들면 이런 것들이다.

• 데이터 품질(정합성/중복/스키마 변화)과 신뢰성 관리
• 장애 대응과 재처리(backfill), SLA를 만족하는 안정적 운영
• 관측가능성(메트릭/로그/알림) 설계와 병목 진단
• 비용까지 포함한 최적화(컴퓨트/스토리지)

마무리

정리하면, 나의 관심은 DB에서 시작했지만 도착지는 데이터 흐름과 운영이다.

더 나아가, AI 시대가 발전한 이상 데이터 파이프라이닝도 그에 맞춰 발전해야 한다고 생각한다. 그리고, 기술적인 부분보다 비즈니스적인 부분이 더 중요하다고 생각한다. 이러한 생각을 공유하고 싶어 이 블로그를 시작했다.