데이터 플랫폼 개발 업무를 맡은 지 4개월이 지났다. 어느덧 시스템이 익숙해지고 나니, 문득 이런 궁금증이 생겼다. “우리는 잘하고 있는 걸까? 다른 회사들은 어떤 기술 스택으로, 어떤 고민을 하며 데이터 플랫폼을 만들고 있을까?”
이러한 갈증을 해소하고자 ‘데이터 플랫폼 설계와 구축’이라는 책을 집어 들었다. 하지만 솔직히 말해, 내가 기대했던 것과는 다소 거리가 있었다. 이 글에서는 내가 이 책에서 무엇을 기대했고, 실제로 무엇을 얻었으며, 어떤 아쉬움이 남았는지 솔직하게 이야기해 보려 한다.
1. 기대와 현실의 간극: On-Premise 개발자의 아쉬움
가장 큰 아쉬움은 책의 내용이 나의 개발 환경과 잘 맞지 않았다는 점이다.
책의 부제는 ‘클라우드 데이터 플랫폼 구축 시 고려사항’이다. 책을 읽기 전에는 이 부제를 가볍게 넘겼지만, 책의 반정도 내용이 이 부제에 초점을 맞추고 있었다. AWS, GCP, Azure 등 주요 클라우드 벤더가 제공하는 관리형 서비스(Managed Service)를 활용해 아키텍처를 구성하는 방법이 상세히 설명되어 있었다.
하지만 나의 현실은 달랐다. 우리는 모든 것을 직접 구축해야 하는 온프레미스(On-Premise) 환경에서 개발하고 있다. 클라우드였다면 클릭 몇 번으로 해결될 메시지 큐, 데이터 파이프라인 오케스트레이션, 분산 처리 시스템을 우리는 오픈 소스를 조합하여 직접 만들고 안정화해야 했다.
그런 내게 “AWS Glue로 ETL을 구성하고, Redshift로 웨어하우스를 구축하세요”와 같은 설명은 당장 적용하기 어려운, 조금은 먼 나라 이야기처럼 들렸다.
또한, 스트리밍 데이터를 자세히 다루는 부분도 현재 우리 플랫폼에서는 배치 처리 위주라 당장은 불필요하게 느껴졌다. (물론 언젠가 스트리밍 데이터도 다룰 날이 오기를 기대해본다.)
2. ‘What’은 있지만 ‘How’는 부족했다
또 다른 아쉬움은 구체적인 구현 코드의 부재였다. 책에서는 DB, API, 파일, 스트리밍 등 다양한 데이터 소스를 처리하는 파이프라인의 개념과 흐름을 명확하게 설명한다. 예를 들어, ‘API 서버에서 데이터를 수집해 Kafka에 전달하고, Spark Streaming으로 실시간 처리 후 데이터 레이크에 저장한다’와 같은 아키텍처를 제시한다.
이러한 흐름은 개념적으로 충분히 이해가 갔다. 하지만 내가 정말 궁금했던 것은 그 ‘연결 고리’였다.
예를 들어
- 안정적으로 API 데이터를 수집하고 Kafka Producer로 전송하는 코드는 어떻게 작성해야 할까?
- Spark에서 복잡한 비즈니스 로직을 담은 데이터 변환은 어떻게 효율적으로 처리할까?
- 파이프라인의 각 단계에서 발생하는 오류는 어떻게 처리하고 모니터링해야 할까?
이처럼 실제 개발에서 부딪히는 문제에 대한 구체적인 ‘How’가 부족했기에, 이미 비슷한 고민을 하며 코드를 작성해 온 나에게는 큰 인사이트를 주지 못했다.
3. 그럼에도 불구하고, 이 책의 가치
아쉬운 소리를 많이 했지만, 이 책이 가치가 없다는 뜻은 결코 아니다. 만약 내가 데이터 플랫폼이라는 분야에 처음 발을 들였거나, 이제 막 팀을 꾸려 플랫폼 구축을 시작하는 단계였다면 이 책은 훌륭한 나침반이 되어주었을 것이다.
- 명확한 개념 정리: 데이터 분야는 비슷한 듯 다른 용어들이 많아 혼란스러울 때가 많다. 이 책은 데이터 레이크, 데이터 웨어하우스, 데이터 플랫폼 등 헷갈리기 쉬운 핵심 용어의 정의와 역할을 명확히 짚어준다. 예를 들어, 책에서는 각 구성 요소를 다음과 같이 설명하며 그 차이를 분명히 한다.
- 데이터 레이크 (Data Lake): 정형, 반정형, 비정형 데이터를 포함한 모든 종류의 원천 데이터를 가공하지 않은 원본(Raw) 형태 그대로 저장하는 중앙 저장소. 당장 어떻게 사용할지 정해지지 않았더라도 “일단 모든 것을 쌓아두는” 거대한 호수와 같다. 데이터 사이언티스트나 분석가들이 자유롭게 탐색하며 새로운 인사이트를 발굴하는 기반이 된다.
- 데이터 웨어하우스 (Data Warehouse): 비즈니스 목적에 맞게 정제되고 구조화된(Schema-on-Write) 데이터를 저장하는 분석용 데이터베이스. 특정 주제(예: 매출, 고객, 재고)에 따라 사전에 정의된 스키마에 맞춰 데이터를 통합하고 저장한다. 주로 BI(Business Intelligence) 대시보드나 정형화된 리포트를 만드는 데 사용되며, 빠르고 일관된 분석을 제공하는 것이 목표다.
- 데이터 플랫폼 (Data Platform): 위에서 언급한 데이터 레이크와 웨어하우스를 포함하여, 데이터의 수집, 저장, 처리, 분석, 활용에 이르는 전 과정을 지원하는 기술과 프로세스의 총체. 단순히 데이터를 쌓는 것을 넘어, 데이터 파이프라인(ETL/ELT), 워크플로우 관리, 데이터 거버넌스, 분석 도구 연동 등 데이터가 가치를 만들어내기까지의 모든 여정을 포괄하는 하나의 시스템이다.
- 이처럼 명확한 정의를 통해, “우리가 만든 파일 서버는 ‘데이터 레이크’의 역할을 하고 있구나”, “매일 배치로 만드는 통계 테이블은 ‘데이터 웨어하우스’의 초기 형태구나”와 같이 내가 구현한 부분의 역할을 객관적으로 파악하고 전체 아키텍처 내에서 그 의미를 이해할 수 있게 해준다.
- 핵심 아키텍처 패턴에 대한 통찰: 개념뿐만 아니라, 그 아키텍처를 구성하는 핵심 기술들이 왜 필요한지에 대해 깊이 고민하게 된 것이 큰 수확이었다. 특히 책에 등장하는 여러 아키텍처 다이어그램에서 Apache Kafka와 같은 메시지 큐가 등장하는 점이 눈에 띄었다.
- 솔직히 책에서 Kafka의 내부 동작이나 구현 방법을 상세히 설명해주지는 않는다. 하지만 데이터 생산자와 소비자 사이에 Kafka가 ‘중간 계층’으로 존재하는 것을 보며, ‘왜 직접 데이터를 주고받지 않고 굳이 이 중간 단계를 거칠까?‘라는 근본적인 부분이 궁금해졌다.
- 이 질문에 대한 답을 찾아가는 과정에서, Kafka가 시스템 전체의 안정성과 확장성을 책임지는 핵심 요소임을 깨달았다.
- 결합도 분리 (Decoupling): Kafka는 데이터를 보내는 쪽(Producer)과 받는 쪽(Consumer)이 서로를 전혀 몰라도 되게 만들준다. 이 덕분에 데이터를 처리하는 시스템에 장애가 발생해도, 데이터를 수집하는 API 서버는 아무 영향 없이 계속해서 Kafka에 데이터를 보낼 수 있다. 데이터 유실 없이 안정적으로 시스템을 운영할 수 있게 되는 것이다.
- 트래픽 완충 (Buffering): 갑작스럽게 데이터가 폭증하는 상황을 상상해 보자. Kafka가 없다면 처리 시스템은 그대로 과부하에 걸리겠지만, Kafka가 중간에 있으면 거대한 ‘버퍼’ 역할을 해주어 시스템이 감당할 수 있는 만큼만 데이터를 가져가 처리하게 할 수 있다.
- 확장성: 나중에 실시간 대시보드나 이상 탐지 시스템 같은 새로운 기능이 필요해져도, 기존 시스템을 수정할 필요 없이 Kafka에 쌓인 데이터를 구독하는 새로운 ‘소비자’를 추가하기만 하면 된다.
- 결론적으로 책이 직접 떠먹여 준 지식은 아니었지만, 훌륭한 아키텍처 예시를 통해 ‘왜?‘라는 질문을 던지게 해주고, 스스로 답을 찾아가도록 이끌어 주었다는 점에서 의미가 있었다. 이는 안정적이고 유연한 시스템을 설계하는 시야를 열어준 계기가 되었다.
- 이러한 아키텍처 패턴은 단순히 기능을 구현하는 것을 넘어, 안정적이고 확장 가능한 시스템을 어떻게 만들어야 하는지에 대한 이해를 도왔다. 우리 팀의 데이터 수집 파이프라인을 어떻게 개선해야 할지 구체적인 청사진을 그릴 수 있게 된 계기였다.
무엇부터 시작해야 할지 막막한 입문자나 기획자, PM에게 데이터 플랫폼의 전체적인 청사진을 제시해 준다. 이 책을 통해 로드맵을 그리고 필요한 기술 스택을 논의하는 출발점으로 삼기에 충분하다.
4. 책을 덮으며: 뜻밖의 수확
책을 읽는 내내 아쉬움이 컸던 것은 사실이다. 하지만 책을 덮고 생각해 보니, 이 아쉬움 자체가 나에게는 큰 이득이었다.
책의 내용이 익숙하고, 내가 더 궁금해하는 지점이 책의 범위를 넘어선다는 사실은, 지난 4개월간 내가 헛된 시간을 보내지 않았다는 증거였다. 고민하고 삽질하며 구현했던 코드들이 책에서 설명하는 개념들을 이미 담고 있었다는 사실을 깨달으며, 나름의 자신감과 확신을 얻을 수 있었다.
이 책은 내가 걸어온 길을 되돌아보고 현재 위치를 가늠하게 해주는 ‘기준점’이 되어주었다. 이제 나는 ‘무엇을’ 만들어야 하는지를 넘어, ‘어떻게 더 잘’ 만들 수 있을지를 고민해야 할 다음 단계에 와있다는 것을 명확히 알게 되었다.