[공통] 데이터엔지니어링팀의 계획 - 중기편 (3~N년)

반응형

빌딩숲

 

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

 

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

어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고

burning-dba.tistory.com

 

지난 단기편에 이어서 중기 편을 이어가려고 합니다. 만약 여러분이 단기 과정을 어느 정도 끝냈다면 이제부터는 중반에 접어들었을 것이라고 봅니다. 기존의 데이터가 없는 환경에서 이제 플랫폼을 이용하여 무엇을 할 수 있는 단계에 이르렀다고 생각됩니다. 이것은 엄청난 도약입니다. 

 

데이터 없이 경험과 감으로 일하던 환경에서 이제는 사실 기반으로 데이터와 수치를 기반으로 업무를 하는 환경을 조금씩 만들어 가고 있는 과정에 서 있다고 봅니다. 제 생각에는 아마도 중반기의 과정이 가장 고달프고 가장 많은 스트레스를 받는 단계가 아닐까 싶습니다. 


들어가며

앞에서 이야기 했듯이 제 생각에는 이 시기가 가장 고달프고 스트레스받는 시기인 것 같습니다. 왜냐하면 1~2년 많게는 3~5년까지 데이터 플랫폼을 구축하였다면 이제는 이것을 쓰게 해야 하는 단계이며, 사용자의 편의성을 증대시켜야 하는 시기이기 때문입니다. 제가 여러 회사에서 데이터 플랫폼을 구축하고 데이터 환경을 만들면서 느끼는 점은 잘 만들어도 쓰지 않으면 인정을 받지 못한다는 것입니다. 

 

많은 사람들이 저에게 "잘 만든 데이터 플랫폼은 무엇인가요?"라고 묻습니다. 예전에는 저는 최신 기술을 접목하여 만든 고도화된 데이터 플랫폼 아니면 엄청나게 잘 잡혀있는 데이터 거버넌스를 기반으로 만들어진 단단하고 견고한 데이터 플랫폼등 여러가지 기술이나 정책 기반의 데이터 플랫폼을 많이 이야기하였습니다. 하지만 데이터 엔지니어로써 많은 시간을 보내다 보니 제 생각에 가장 잘 만들어진 데이터 플랫폼은 사용자가 잘 쓰는 데이터 플랫폼인 것 같습니다. 

 

사용자가 많은 데이터 플랫폼이 가장 잘 만든 데이터 플랫폼이라고 감히 말하고 싶다.

 

이렇게 하기 위해선 수많은 노력이 필요하며 엔지니어로써 "내가 왜 이걸 하지?"라는 생각이 드는 여러가지 일도 많이 해야 하기 때문인 것 같습니다. 이밖에도 여러 가지 고도화를 통해서 비용을 감축시키고 데이터 플랫폼이 구축되었기에 내가 예상하지 못하였던 다양한 종류와 방대한 양의 데이터를 데이터 플랫폼에 넣어줘야 하는 여러 가지 스트레스도 받습니다. 

 

계획 계획 내용 비고
데이터 플랫폼 홍보/교육 데이터를 사용할 수 있는 환경을 만들었다면 이제는 데이터를 잘 쓰도록 해야함  
다양한 데이터 적재 이미 있는 데이터 또는 기본적인 데이터를 적재 하였다면 이제는 다양한 데이터를 적재 해야함 예시) CRM / GA4 / 타 플랫폼 데이터등
사용자 편의성 증대 데이터 플랫폼을 계속해서 사용자가 사용하기 편한 환경으로 만들어줘야함 (요구사항 수집 및 반영) 예시) 데이터 카탈로그 강화 / Text To SQL등 
데이터 관련 고도화 다양한 사용자와 데이터가 계속해서 유입됨으로 인하여 정책 또한 생성하고 고도화 되어야하며, 기존의 정책도 끊임없이 업데이트 되어야함   

1. 데이터 플랫폼 홍보/교육

솔직히 말해서 많이 하기 싫은 일중에 하나입니다. 이 일을 왜 해야하는지 이해하는데 많은 시간이 걸린 거 같습니다. 왜냐면... 저는 엔지니어니까요. 엔지니어가 왜 어째서? 교육하고 홍보하고를 해야 하지?라는 생각을 정말 많이 했습니다. 그런데, 어느 회사를 가든 이건 엔지니어의 숙명 같습니다. 제가 다녔던 많은 회사에서 SQL 교육이나 데이터의 기초 교육을 진행했을 때 항상 반응이 좋았고, 언제나 환영받았습니다. 그만큼 피드백도 좋았습니다. 

 

제가 앞서 말했듯이 데이터 플랫폼을 아무리 잘 구축해도 사용자가 나 뿐이라면 인정받지 못합니다. 다양한 사용자가 잘 쓸 수 있는 환경을 만들어놨다면 이제 다양한 사용자가 쓸 수 있도록 만들어야 합니다. 요즘에는 AI나 LLM을 통해서 Text To SQL을 쓰는 곳도 굉장히 많지만 기본적으로 이런 것을 쓰기 위해서는 데이터 플랫폼 환경에 접속하는 방법부터 시작해서 정말 수많은 것들을 기본적으로 알아야 합니다. 

 

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

 

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

글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된

burning-dba.tistory.com

 

제가 예전에 써둔 데이터를 적재하고 보기까지라는 글에서 나오는 내용을 주로 교육 콘텐츠로 사용하였습니다. 사람들은 설명하지 않으면 데이터를 어떻게 볼 수 있고 데이터를 보기까지의 수많은 과정이 있다는 것을 알지 못합니다. 뭐... 당연한 이야기겠지만 우리의 사용자들은 각자의 본업이 있고 데이터를 그분들에게 어디까지나 보조 도구입니다. 그렇기 때문에 이 분야에 대해서 우리만큼 알지 못합니다. 이 부분을 받아들이고 우리의 사용자들에게 설명(교육)하는 시간이 필수적이라고 봅니다. 

 

저 같은 경우 전단지 돌린다는 말을 자주 사용 하였는데, 실제로 전단지를 나눠주면서 홍보를 하는것과 똑같다고 봅니다. 이 일을 전담하는 부서가 있어야 하는 거 아니야?라고 할 수 있는데, 전담해줘도 어차피 우리의 사용자들의 궁금증을 시원하게 해소해주려면 본인이 나서야 합니다. 왜냐면 교육만 전담하는 부서가 전달하는 것과 실제 현업의 사람이 전달하는 건 차이가 꽤 큽니다. 


2. 다양한 데이터 적재

아마 데이터 플랫폼을 구축 하겠다는 요구가 있다면 기본적으로 보고 싶은 데이터는 있다는 뜻이고 아마 그 기본적인 데이터는 적재가 되어서 데이터 플랫폼을 구축하고 사용자들에게 오픈하였다고 볼 수 있습니다. 이제 그럼 사용자가 유입되고 데이터 플랫폼이 생겼으니 다양한 데이터를 적재해달라고 요구가 올 것입니다. 

 

즉, 담을 그릇이 생겼으니 다양한 음식을 준비 해달라는 것과 비슷하다고 봅니다. 제가 주로 받았던 요청은 CRM 데이터, GA4 데이터 그리고 서버로그등이었습니다. 그리고 추가적으로 개발팀에서 로그나 데이터를 추가적으로 만들기도 하며 또는 다른 플랫폼에서 나오는 결괏값 데이터를 적재해달라는 요구도 많이 있습니다. 

다양한 데이터들

 

저는 주로 CRM 데이터를 마케팅 부서로부터 가장 먼저 요청 받았던 기억이 있습니다. 그 이후에 서버개발팀에서 요청이 오거나 또는 사업팀으로부터 요청이 오는 경우가 대부분이었습니다. CRM 데이터나 GA4 같은 데이터들은 사실 적재가 그렇게 어렵진 않습니다. 이미 export 기능이 잘 만들어져 있고 연동을 원한다고 하면 방법도 이미 다 있습니다. 여기서 조금 까다로운 게 다른 플랫폼이나 자체구축 플랫폼에서 데이터를 가져오는 일입니다.

 

자체 구축하거나 다른 플랫폼의 경우 데이터를 가져오기 위해서는 ODBC / JDBC등과 같은 커텍터로 직접 연결하거나 이것도 안 될 경우 직접 데이터를 내려받아서 가져오는 부분도 필요합니다. 우리 쪽 시스템이 아니라서 굉장히 까다로운 경우가 많습니다. 그리고 웹 크롤링 데이터나 공공기관 데이터도 주로 요청받는 데이터중 하나입니다.


3. 사용자 편의성 증대

앞서 1번에서 이미 홍보와 교육까지 했는데 또 뭘 해야 하지?라고 생각 할 수 있습니다. 이 부분은 약간 다른 내용입니다. 앞의 내용이 사용자가 진입하게 만들었다면 이제는 진입 후 잘 사용하도록 만드는 방법입니다. 약간 같으면서도 다른데요. 예를 들면 이런 것들입니다. 

 

[Databricks] 비효율적인 작업 추적기 만들기

 

[Databricks] 비효율적인 작업 추적기 만들기

안녕하세요. 주형권입니다.정말 오랜만에 글을 쓰는 거 같습니다. 요즘 내/외부적으로 바쁘게 살고 있어서 글을 쓸 시간이 없습니다... 그래서 한 달에 1개 업로드하기도 어렵습니다.🥺 들어가

burning-dba.tistory.com

[Athena] Query 사용량 및 사용자 추적 대시보드 만들기

 

[Athena] Query 사용량 및 사용자 추적 대시보드 만들기

안녕하세요. 주형권입니다. 지난번에 개발한 GS리테일의 데이터레이크 모니터링 시스템 도베르만에 추가적인 기능을 만들어서 만드는 과정에 대해서 공유하려고 글을 작성하였습니다. 기존에

burning-dba.tistory.com

 

이게 무슨 연관이 있을까 싶겠지만 굉장히 연관이 많습니다. 제가 현재 사용하고 있는 Databricks 환경을 예로 들어보겠습니다. 비효율적으로 판단되는 쿼리의 기준으로 잡습니다. 저 같은 경우 30분 이상 동작하는 Query를 추적하도록 했습니다. 그럼 이걸 하는 이유가 단순히 튜닝을 위한 목적이라고 생각할 수 있지만 다르게 생각하면 사용자들이 그만큼 오래 기다려야 한다는 의미입니다. 

 

이 말인즉 사용자들이 Query를 실행하고 결과를 받기까지 오래 걸린다는 의미입니다. 내가 사용자라면 매번 Query를 할 때마다 30~60분씩 걸린다고 생각하면 얼마나 고달플까요. 물론 수억 수천억 건의 데이터를 1~N년치 이런 식으로 조회하면 사용자도 느리다 생각하겠지만 하루 또는 이틀 치만 데이터를 질의하는데 오래 걸린다? 그럼 저 같아도 쓰기 힘들 거 같습니다. 그렇기 때문에 이와 같은 Query를 추적하여, 테이블에 파티션을 재조정하거나 파티션이 없으면 만들어 준다거나 조금 더 효율적으로 조금 더 빠르게 결과를 받을 수 있도록 할 수 있습니다.

 

또한 사용자들이 데이터를 쉽게 볼 수 있도록 카탈로그를 고도화할 수 있으며 데이터 관련 마트/팩트를 설계하여 제공도 가능합니다. 단순히 데이터를 적재하고 끝이 아닌 사용자가 잘 사용할 수 있도록 계속해서 만들어야 합니다. 카탈로그의 경우 사용자가 플랫폼에 접속해서 속성을 찾아서 보기보다는 하나의 페이지에서 검색이 가능하도록 웹 사이트를 만들어서 제공하면 굉장히 큰 호응을 얻을 수 있습니다. (실제로 그랬습니다.) 


4. 데이터 정책 고도화

데이터 플랫폼을 구축하고 어느 정도 시간이 지남에 따라서 정책은 끊임없이 업데이트되어야 합니다. 예를 들어서 데이터 플랫폼에서 권한 체계만 해도 다양한 부서와 다양한 데이터를 보는 사람들이 다양하게 생기므로 정책을 다르게 수립해야 하는 경우가 많습니다. 

 

또한 다른 플랫폼에서 데이터가 들어오거나 굉장히 민감한 데이터가 들어오는 경우 데이터를 어떻게 어디까지 보여줘야 할지에 대해서도 고민해야 합니다. 예를 들면 민감 정보의 경우 암호화의 방법부터 시작해서 암호화를 하더라도 볼 수 있는 부서 또는 사용자가 있고 어디까지 볼 수 있는지 모두 고민해야 합니다. 물론 거버넌스 또는 보안부서에서 어느 정도 도움을 주긴 하겠지만 어디까지나 이것을 만들어서 적용은 데이터 엔지니어들이 합니다. (데이터 플랫폼이 우리 거니깐...) 그렇기에 이러한 정책을 계속해서 업데이트해야 합니다.

 

추가적으로 데이터 수명주기나 데이터의 관리에 관한 여러 가지 정책도 이제 중기에 접어들면 관리가 필요합니다. 데이터의 양이 매우 작으면 큰 의미가 없지만 데이터의 사이즈가 큰 경우 한 달을 보관하는 것도 그만큼 많은 비용이 들어갑니다. 그렇기 때문에 데이터의 수명주기를 설정해서 데이터가 몇 년 또는 몇 달 치 보관을 할지 정해야 합니다. 데이터의 종류가 다양하고 각기 데이터의 성질과 크기가 다르므로 이 모든 것을 관여하여 정책을 잡아야 합니다. 

 

반응형