[공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)

어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고 비전에 파생되는 계획을 단/중/장기적으로 실천하는 일이 필요합니다. 비전과 계획이 별거 아닌 것 같지만 이것이 없으면 팀원들은 팀 비전에 대해서 의구심을 느낄 수 있으며 불안감이나 또는 보람을 느끼지 못할 수 있습니다. 

 

그렇기 때문에 비전과 계획은 굉장히 중요한것 같습니다. 이번 글에서는 비전 이야기보다는 실질적인 계획에 대해서 이야기해보고자 합니다. 목표라고 할 수도 있겠네요. 사실 비전은 팀마다 정하기 나름이고 회사의 기조에 따라서 많이 달라질 것 같기에 비전에 대해서 다루지 않고 데이터엔지니어링 팀의 계획에 대해서만 다루고자 합니다.

 

제가 생각 하기에 비전은 조금 더 추상적인 느낌의 긍극적인 목표라면 계획은 구체적인 실행 방안이기 때문에 계획은 큰 틀에서는 비슷할 것 겉으로 보입니다. 제가 팀장을 역임했던 경험과 제로 베이스에서 시작하는 데이터 플랫폼 구축에 관련하여 계획을 세우는 부분에 대해서 실제 행했던 경험을 이야기하고자 합니다. 

---

들어가며

계획은 단기 계획 ➡️ 중기 계획 ➡️ 장기 계획으로 조금씩 나아갑니다. 조금씩 단계를 거쳐가면서 필요한 일과 해왔던 일에 대해서 정리를 하고자 합니다. 현재 2025년 9월 기준으로 속해 있는 LG전자에서는 단기 계획을 넘어서 중/장기 계획을 수립하여 나아가는 단계에 놓여있고 중/장기 계획을 수립하는 과정에 있습니다. 

 

이를 기반으로 현재의 실제 계획을 수행하고 있는 경험과 기존의 회사에서 경험 하였던 계획 수립과 계획 실행을 기반으로 글을 작성하려고 합니다. 생각보다 거창한 이야기는 아닐 수도 있고 엄청나게 혁신적인 이야기는 아닐 수 있지만 아마도 누구나 해야 하고 누구나 필요한 이야기 일 것입니다. 

 

항상 이야기 하지만 저의 이야기가 전부 정답은 아니며, 각자의 상황과 여건에 맞게 받아들이면 좋겠습니다. 이글로 인해서 경험을 해보지 못하여 방황하거나 다른 회사의 사례를 듣고자 하는 분들에게 귀감이 되었으면 좋겠습니다.

단기 계획은 0~2년 정도의 계획이라고 생각 됩니다. 조금 빠르면 0~1년이라고 할 수 있습니다. 이 역시 회사의 여건과 현재 자신의 상황에 따라서 많은 부분이 다를 거라고 생각됩니다. 어느 회사의 경우 조금 여유가 있기에 3년이라고 생각할 수도 있을 것 같습니다. 

 

처음 아무것도 없는 환경에서는 우선 데이터 플랫폼의 선정이 주요하다고 봅니다. 레이크 하우스의 구축을 하거나 데이터 웨어하우스 시스템을 구축하거나 하는 등의 여러가지 플랫폼 구축을 하고 이를 기반으로 모니터링 및 데이터 파이프라인 개발이 필요한 시기입니다. 추가적으로 로그 자체가 없는 경우도 있을 텐데 이 경우 로그를 만드는 작업부터 해야 하는 경우가 있습니다. 다행히 저의 경우 개발자분들이 로그를 미리 만들어주셨기에 로그를 심는 과정부터 진행하진 않았습니다. 만약에 로그가 없지만 빠르게 분석이 필요한 경우 관계형 데이터베이스에서 일단 데이터를 가져와서 인사이트를 얻을 수도 있습니다. 

 

다음은 단기 계획에 대해서 표로 정리한 것 입니다. 순서대로 정리하였으며 필요에 따라서 해도 되고 안 해도 됩니다.

계획	계획 내용	비고
로그 설계/개발	로그가 없다면 설계가 필요함 (이미 있는 경우가 많음)	관계형 데이터베이스의 데이터를 임시로 사용하는 경우도 있음 또는 로그 플랫폼(?)을 사용하기도 함 (Google Analyics / Amplitude 등)
데이터 플랫폼 선정 및 구축	데이터를 담을 데이터 플랫폼 구축 필요함 (예시 : BigQuery / Snowflake / Databricks등)	레이크하우스를 구축할것인지 정보계 데이터 웨어하우스를 만들것인지 구축 범위 협의도 필요
데이터 아키텍처 설계 및 정책 수립	데이터가 어디에 어떻게 적재되고 어떠한 형태로 적재될지부터 정책등을 만들어야함 또한 데이터 관련 정책을 수립하여 데이터가 잘 쌓이고 잘 활용되도록 해야함	참고 : 데이터아키텍처란 무엇인가?
데이터 파이프라인 개발	데이터를 담을 데이터 플랫폼을 구축 하였다면 데이터 플랫폼에 담을 데이터를 가져와야 함
데이터 모니터링 개발	데이터 파이프라인 / 정합성등의 체크를 하는 모니터링 개발	필요에 따라서 파이프라인 구축과 동시에 진행 필요
데이터 플랫폼 운영	데이터 플랫폼을 운영하여 사용자가 잘 사용 하도록 함

---

1. 로그 설계/개발

일단 아무것도 없는 경우 로그 설계부터 시작해야 합니다. 로그를 만들어야지 그것을 담을 그릇을 만들어도 담을 내용물이 있기 때문에 이 작업은 굉장히 중요합니다. 로그를 당연하게도 기획/사업/마케팅등 데이터를 실제 사용할 사람들의 의견을 반영하여 설계를 하는 게 좋습니다. (나중에 만들었는데 실제 사용자가 못쓰면 무슨 소용이겠습니까...?) 

 

아마 이 로그 설계와 개발은 회사의 여건에 따라서 가능 하기도 하고 불가능하기도 하고 오래 걸리기도 하고 빠르게 진행되기도 할 것 같습니다. 관련해서 조금 더 자세한 내용은 아래의 글을 참고하면 좋을 거 같습니다.

 

[공통] 데이터를 적재하고 보기까지

[공통] 데이터를 적재하고 보기까지

 

 

앞서 말한것과 같이 로그가 없으면 만들어야 하지만 아닐 경우 관계형 데이터베이스에서 가져와서 인사이트를 얻을 수도 있습니다. 관계형 데이터베이스에서 데이터를 가져오기 위해선 아무 준비가 없어 가능은 하지만 제가 예전에 썼던 글을 참고하면 조금 더 안전하고(?) 좋은 성능으로 관계형 데이터베이스에서 데이터를 가져올 수 있습니다.

 

[ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계

[ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계

 

---

2. 데이터 플랫폼 선정 및 구축

로그가 어느정도 준비되었거나 관계형 데이터베이스에서 가져오기로 하였다면 데이터를 담을 공간이 필요합니다. 그렇기 때문에 여러 가지 데이터 플랫폼 중에서 하나를 선택하기도 하고 필요에 따라서 여러 개를 선택하기도 합니다. 다만 저는 한 개로 통일하여 사용하시길 권장드립니다. (나중에 관리 포인트가 너무 많아지고 각 데이터플랫폼마다 특색이 달라서 공부할게 많아집니다.) 

 

다양한 데이터플랫폼

 

데이터 플랫폼의 경우 제가 아는 것만 나열해도 10개가 넘을 것 같고 위의 사진에 나오지 않은 여러가지 수많은 오픈소스 플랫폼 /상용 플랫폼 등 여러 가지 플랫폼이 있습니다. 제가 알지 못하는 플랫폼도 엄청나게 많을 거라고 봅니다. 사실 데이터 플랫폼을 무엇을 선택하는지는 본인의 상황과 회사의 상황에 따라서 모두 다른 것 같습니다. 꼭 위의 사진에 데이터 플랫폼을 사용하지 않아도 되고 관계형 데이터베이스를 데이터 플랫폼으로 사용하는 곳도 많이 있습니다. 

 

관련해서는 아래의 글을 참고하면 도움이 많이 될거 같습니다. LG전자에서 1년 동안의 Databricks 구축에 관련된 회고 글입니다. 전반적인 데이터플랫폼 구축 과정을 담고 있으면 이 글의 기술적 압축본이라고 보면 좋을 거 같습니다.

 

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

Databricks와 함께한 데이터 플랫폼 구축 1년 회고

 

---

3. 데이터 아키켁처 설계 및 정책 수립

데이터를 어디서 받아서 어떻게 저장하고 어떠한 단계를 거쳐서 어떻게 제공할지 등의 전체적인 그림을 보여주는 것이라고 알고 있습니다. 대표적으로 Databircks에 메달리온 아키텍처가 있으며, 이러한 데이터 아키텍처를 설계하여 데이터가 어디에 적재되어야 할지 등과 데이터를 어떻게 보여줄지 등을 보여줘야 합니다.

Databricks 메달리온 아키텍처

 

데이터 아키텍처를 설계하고 이를 기반으로 데이터플랫폼을 만들었다면 정책을 세워야 합니다. 데이터 정책에 여러가지 예시가 있는데, 예를 들면 데이터권한 관리 또는 데이터 배치 주기 또는 사용자들에게 제공할 데이터와 제공하지 않을 데이터등의 정책이 필요합니다. 

 

사실 이 부분은 조금 더 큰 범위로 말하면 데이터 거버넌스라고 할 수 있습니다. 그런데 굳이 거버넌스라고 하지 않은 이유는 초기에 거버넌스 부서가 있지 않은 경우가 대부분이고 있다 하더라도 엄청 세세한 부분까지 빠르게 만들어지는 어려울 거라고 봐서 정책이라고 약간(?) 축소하여 말하였습니다. 물론 거버넌스를 처음부터 확실하게 정하고 가면 제일 좋겠지만 초반에 이런저런 인력 및 시간적 이슈로 그렇지 못한 경우가 많아서 정책이라고 표현하였습니다.

---

4. 데이터 파이프라인 개발

로그도 준비가 되었고 담을 그릇(데이터 플랫폼)도 준비가 되었다면 이제는 데이터를 넣어야 합니다. 데이터를 넣을 파이프라인을 만들어서 데이터 플랫폼에서 데이터를 볼 수 있도록 만들어야 합니다. 데이터의 형태는 크게 3가지로 나뉘는데 초반에는 거의 대부분이 정형/반정형 데이터를 취급합니다. (아닐 수도 있지만 저의 경험상으론 그랬습니다.) 정형의 경우 주로 관계형 데이터베이스의 데이터를 의미하고 반정형의 경우 parquet 또는 Json이나 avro 같은 데이터를 의미합니다. 이러한 데이터의 경우 형태가 어느 정도 있기에 가져오는데 무리가 크게 없습니다.

 

우선 정형 데이터의 경우 신경 써야 하는 게 관계형 데이터베이스에서 데이터를 가져올 때 성능을 고려해서 가져와야 합니다. 위에서 언급한 [ETL] RDB에서 데이터를 ETL을 위한 최소한의 테이블 설계를 참고하시면 많은 도움이 될 것으로 보입니다. 아무리 강조해도 관계형 데이터베이스의 성능을 절대적으로 고려해야지 추후에 문제가 없습니다. 나중에 가서 파이프라인을 고치는 행위는 정말 많은 시간과 노력이 필요하고 데이터 파이프라인을 고치지 않고 관계형 데이터베이스를 고치려고 하면 정말 나중에 수십 수백 배의 시간과 노력이 필요합니다. (못 믿겠으면 한번 해보시길 권장...^^)

 

반정형의 경우는 성능도 성능이고 비용을 주로 많이 고민하는 것 같습니다. 아무래도 사용하는 만큼 부과되는 ETL 도구나 AWS / GCP 같은 곳에서 제공하는 도구등을 사용하거나 아니면 Spark 같은 도구등 여러 가지 도구를 사용해서 데이터를 ETL 하실 텐데 성능적으로는 파일 시스템에 분산처리를 하시기에 성능은 아주 잘 나올 것으로 예상됩니다. (아닌 경우도 있습니다.) 그래서 아마도 성능보다는 비용적으로 처리 비용을 아껴서 하시는 것에 중점을 둘 것으로 보입니다. 주로 네트워크 비용 (데이터 전송비용)과 저장비용 그리고 컴퓨팅 비용을 많이 중점적으로 봐야 할 것입니다. 

---

5. 데이터 모니터링 개발

모니터링의 경우 자칫 쉽게 생각하여 나중에 만들지라고 생각할 수 있는데요. 그렇지 않습니다. 생각보다 모니터링만으로도 장애율을 많이 줄일 수 있고 비용적인 부분에서도 많은 부분을 잡아낼 수 있습니다. 자세한 이야기는 제가 이전에 썼던 모니터링 관련 글을 참고하면 좋을 거 같습니다.

 

[Databricks] Job Monitoring 방법론 : 수집📥 알람🚨 보기👀

[Databricks] Job Monitoring 방법론 : 수집📥 알람🚨 보기👀

 

Databricks용으로 쓰긴 했지만 사실상 다른 데이터 플랫폼에도 적용 가능하며 읽어보면 많은 도움이 될 것 같습니다. 제 경험상으로 모니터링만으로도 실시간으로 데이터파이프라인 실패를 감지하고 불필요하게 발생하는 비효율 Query 등을 잡아내서 튜닝을 해주고 많은 것들을 할 수 있습니다. 

---

6. 데이터 플랫폼 운영 

데이터 플랫폼 운영을 굳이 따로 뺀 이유는 생각보다 할 일이 많아서입니다. 단순하게 데이터 추출이나 단순히 모니터링에 그치지 않고 데이터 플랫폼의 성능 튜닝이나 모니터링 고도화 파이프라인 고도화등 여러 가지 해야할 일이 많습니다. 실제로 제가 사용하는 Databricks에서도 Optimize / VACCUM등 여러가지 주기적으로 해줘야 하는 일이 있고 관계형 데이터베이스를 기반으로 데이터 플랫폼을 구축하신 분들이라면 백업과 인덱스 리빌딩등 해야 할게 참 많을 것 같습니다. 

 

여기에 당연하게도 데이터 추출 및 데이터 사용자 관리등도 운영에 포함될 것입니다. 데이터 추출이 엔지니어로써 굉장히 하기 싫은 일이지만 어쩔수 없이 해야할수 밖에 없는 일이고 사용자가 늘어남에 따라서 여러가지 권한 문제나 어디까지 데이터를 제공할지의 문제도 봉착하게 될 것 입니다.

 

여기에 조금 더 나아가 비용의 압박을 조금씩 받기 시작할 것입니다. 보통 2년 차부터 받았던 거 같고 이 부분은 중기 단계에서 조금 더 자세히 다뤄볼까 합니다.