한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.
1. 이 책을 선택한 동기
실무에서 SQL을 다루는 기술을 읽은 이후로, 데이터를 "쓰는 것" 이상의 관점이 궁금해졌습니다. 데이터를 어떻게 수집하고, 어떻게 이동시키고, 어떻게 품질을 유지하는지— 백엔드 너머의 세계가 점점 궁금해지던 차였어요.
저는 프론트엔드 개발자지만, 사이드 프로젝트를 혼자 만들면서 Supabase, Neon DB 같은 도구를 직접 다루다 보면 자연스럽게 데이터 파이프라인이라는 개념을 마주하게 됩니다. 데이터를 어디서 가져와서, 어떻게 가공해서, 어디에 저장할지— 사실 지금까지는 그때그때 즉흥적으로 해결해왔어요. "이건 그냥 INSERT 하면 되겠지", "오류 나면 그때 가서 보면 되겠지" 하는 식으로요.
그런데 데이터 엔지니어링 디자인 패턴이라는 제목을 보는 순간 뭔가 꽂혔어요. 소프트웨어 엔지니어링의 디자인 패턴이라는 개념은 이미 익숙했으니까요. "GoF 패턴을 데이터 엔지니어링에 적용한다고? 그게 가능해?" 하는 호기심이 생겼습니다.
2. 어떤 책인지
데이터 엔지니어링 디자인 패턴은 소프트웨어 엔지니어링의 디자인 패턴 개념을 데이터 엔지니어링 분야에 본격적으로 적용한 실무 가이드입니다. 저자 바르토시 코니에치니는 다양한 비즈니스 도메인과 클라우드 환경을 경험하면서 프로젝트마다 반복적으로 등장하는 공통적인 지점들을 패턴화해냈고, 그 결과물이 바로 이 책이에요.
책의 구성은 실제 데이터 엔지니어링 프로젝트의 워크플로를 그대로 따릅니다.
CHAPTER 2: 데이터 수집 디자인 패턴 (전체 적재, 증분 적재, 복제, 이벤트 주도)
CHAPTER 3: 오류 관리 디자인 패턴
CHAPTER 4: 멱등성 디자인 패턴
CHAPTER 5: 데이터 가치 디자인 패턴
CHAPTER 6: 데이터 흐름 디자인 패턴
CHAPTER 7: 데이터 보안 디자인 패턴
CHAPTER 8: 데이터 스토리지 디자인 패턴
CHAPTER 9: 데이터 품질 디자인 패턴
CHAPTER 10: 데이터 관찰 가능성 디자인 패턴
각 패턴은 문제 → 해결책 → 결과 라는 일관된 구조로 서술됩니다. 패턴의 이름을 붙이고, 어떤 상황에서 필요한지, 어떻게 적용하는지, 그리고 적용 후 어떤 트레이드오프가 따르는지까지 체계적으로 다뤄요.
3. 특히 인상적이었던 점
1. "데이터 엔지니어링에도 이름이 있다"
가장 충격적이었던 건 그동안 제가 아무렇게나 해왔던 작업들에 다 이름이 있다는 사실이에요. 전체 데이터를 통째로 다시 가져오는 방식은 전체 로더(Full Loader) 패턴, 바뀐 것만 가져오는 방식은 증분 적재(Incremental Load) 패턴, 파이프라인 중간에 오류가 난 데이터를 따로 보관하는 건 데드 레터링(Dead Lettering) 패턴이라고 불린다는 걸 이 책을 통해 처음 알았어요.
이름이 있다는 건 단순히 용어 문제가 아닙니다. "아, 이게 왜 이렇게 돼있지?"라는 상황에서 문제를 정확히 진단하고 팀원과 공유할 수 있는 언어가 생긴다는 뜻이거든요.
2. 패턴 구조의 일관성
각 패턴이 문제 → 해결책 → 결과 라는 일관된 포맷으로 서술된다는 점이 좋았어요. 단순히 "이렇게 하면 돼"가 아니라, "이런 상황에서 이런 이유로 이 패턴이 필요하고, 적용하면 이런 장단점이 생긴다"까지 설명해줍니다.
예를 들어 전체 로더 패턴을 설명할 때, EL(Extract-Load) 방식이 이상적인 경우와 이종 데이터베이스 간에는 ETL(Extract-Transform-Load)이 필요한 이유까지 친절하게 짚어줘요. 덕분에 "언제 이 패턴을 쓰면 되는지"가 명확하게 느껴졌습니다.
3. 멱등성(Idempotency)이라는 개념
솔직히 말하면 멱등성이라는 단어 자체는 알고 있었어요. "같은 연산을 여러 번 해도 결과가 같아야 한다"는 거잖아요. 그런데 이게 데이터 파이프라인에서 왜 그렇게 중요한지, 어떻게 설계에 반영하는지는 이 책을 읽고 나서야 피부로 느꼈어요. 파이프라인이 도중에 실패해서 재실행될 때 중복 데이터가 쌓이는 문제— 멱등성을 고려하지 않으면 데이터가 조용히 오염될 수 있다는 걸 그때서야 깨달았어요.
4. 덕분에 무엇을 배웠는가
데이터 파이프라인을 설계하는 눈이 생겼어요. 사이드 프로젝트에서 데이터를 다룰 때 "이걸 전체 로더로 할지, 증분 적재로 할지"를 의식적으로 선택할 수 있게 되었습니다. 작은 프로젝트에서도 선택의 근거가 생기니 훨씬 자신있게 결정할 수 있어요.
오류 처리를 미리 설계해야 한다는 것을 배웠어요. 예전에는 오류가 나면 그냥 로그 찍고 넘어갔는데, 데드 레터링 패턴처럼 오류 데이터를 별도로 격리해서 분석하고 재처리하는 구조를 미리 설계해야 한다는 걸 이제는 알아요.
데이터 품질은 파이프라인 밖에서 보장할 수 없다는 것도요. 입력이 잘못됐을 때 그걸 어디서 잡을지, 품질 검사를 어느 시점에 끼워넣을지— 이게 CHAPTER 9에서 다루는 데이터 품질 패턴의 핵심이었습니다.
데이터 관찰 가능성(Observability)이라는 개념을 제대로 이해했어요. 단순히 모니터링이 아니라, 파이프라인 전체의 상태를 추적하고 이상 신호를 감지하는 시스템을 설계하는 방법— 이게 프론트엔드 개발자인 저에게도 적용 가능한 사고방식이라는 걸 깨달았어요.
5. 좋았던 점
1. 데이터 엔지니어링 전 단계를 망라한 구성
데이터 수집에서 시작해서 오류 처리, 멱등성, 품질 검증, 모니터링으로 이어지는 흐름이 실제 데이터 파이프라인의 생애주기와 정확히 일치해요. 덕분에 "지금 제가 어느 단계의 문제를 다루고 있는가"를 항상 인식하면서 읽을 수 있었습니다.
2. 패턴에 이름을 붙여준다는 것
이 책의 가장 큰 가치는 이름 붙이기라고 생각해요. 전체 로더, 증분 적재, 데드 레터링, 멱등성 설계— 이름이 생기면 팀 내 커뮤니케이션이 달라집니다. 백엔드·데이터 엔지니어 동료와 대화할 때 같은 언어로 이야기할 수 있게 되는 거니까요.
3. 마지막에 있는 "디자인 패턴 요약" 섹션
책 전체 패턴을 한눈에 볼 수 있는 요약 챕터가 있어요. 나중에 어떤 패턴이 있었는지 찾고 싶을 때 인덱스처럼 활용하기 딱 좋았습니다.
6. 아쉬운 점
데이터 엔지니어링을 처음 접하는 독자에게는 진입장벽이 있어요. 분산 시스템, 클라우드 서비스, 데이터 웨어하우스 등의 배경 지식을 어느 정도 갖추고 있어야 내용이 잘 소화됩니다. "데이터 수집이 뭔지"부터 설명해주는 책은 아니에요.
각 패턴에 대한 코드 예제가 있으면 더 좋았을 것 같아요. 어떤 패턴인지 개념은 이해했는데, "그래서 실제로 Python이나 Spark로 어떻게 구현하는 거야?"가 궁금한 순간들이 있었거든요.
7. 이 책을 읽은 덕분에 기대되는 변화
사이드 프로젝트에서 데이터를 다룰 때, 이제는 단순히 동작하는 코드가 아니라 재실행에 안전한 파이프라인을 만들 수 있을 것 같아요. 멱등성을 고려한 UPSERT 쿼리를 쓴다든지, 오류가 난 데이터를 조용히 버리지 않고 별도 테이블에 기록해두는 습관이 생겼거든요.
무엇보다 "이 파이프라인이 잘못됐을 때 어떻게 알 수 있지?"라는 질문을 미리 던질 수 있게 된 것 같아요. 데이터가 조용히 오염되는 건, 파이프라인이 아예 멈추는 것보다 훨씬 위험하다는 걸 이 책을 읽고 나서야 실감했습니다.
프론트엔드 개발자가 데이터 엔지니어링 책을 읽는다는 게 뜬금없어 보일 수 있지만, 풀스택으로 뭔가를 만들고 싶은 사람이라면 꼭 한 번 읽어보길 추천해요. 데이터를 다루는 방식이 달라집니다!
미리보기
