[공통] 나혼자 데이터환경 구성 - 제 2부

 

안녕하세요. 주형권입니다.

제1부 - warming-up에 이어서 두 번째 이야기입니다. 두 번째 이야기는 데이터 환경을 구성하기 위해서 하는 준비 과정을 작성하였습니다. "생각보다 그냥 하면 되는 거 아니야?"라고 생각할 수 있지만 준비할 게 정말 많습니다. 저 같은 경우 사람들을 설득시키는 과정이 굉장히 힘들었고 인식을 바꾸는 과정이 가장 어려웠던 거 같습니다. 

 

물론 사람의 입장의 차이가 모두 있고 팀의 사정이 저마다 다르기에 우리의 일을 모두 좋게 바라볼순 없습니다. 또한 여러 가지 이해관계가 엮여 있으므로 당연히 풀어야 하는 문제입니다. 무조건 우리 쪽의 입장만 들어주고 데이터를 만들어준다면 정말 편하겠지만 상대방의 입장과 상대방의 팀의 입장이 있고 변경하기 어려운 점이 분명히 존재하므로 여러 가지 협의를 통해서 이를 풀어야 합니다.

 

그러한 과정과 몇가지 생각을 정리하여 글을 정리하였습니다. 이 또한 저의 개인적인 생각과 경험을 바탕으로 작성되었기 때문에 참고 차원에서 봐주시길 바라며 실제로 G사에서 했던 내용을 기반으로 작성하였기에 어찌 보면 성공(?) 사례라고 할 수 있습니다. 그리고 어디까지나 데이터엔지니어 입장에서 작성 한 글이므로 공감이 안가실 수 있습니다. 이점 유의해서 봐주세요.

---

제1장) 마음가짐에 대하여

첫 번째는 마음가짐입니다. "응? 뭐지?" 싶을 수 있을 텐데 저는 이게 가장 중요한 거 같습니다. 기술도 중요하지만 역시나 사람과 사람이 일하는 곳이 직장인데 어떻게 기술만으로 일을 하겠습니까? 그렇기 때문에 마음가짐이 가장 중요한 필수요건이라고 생각됩니다. "열심히 하겠어!" 이런 뻔한 이야기가 아니고 여러 가지 생각의 전환을 할 수 있도록 돕는 내용을 작성하였습니다.

---

1) 하나씩 하자

기어다니기 부터 하자

 

사람은 누구나 태어나면서 기어 다니기 시작하고 걷기 시작하고 뛰기 시작합니다. 그 누구도 태어나자마자 뛸 순 없습니다. 데이터도 마찬가지입니다. 누구나 처음부터 뛸 수는 없습니다. 그런데 많은 기업에서는 처음부터 고급분석과 데이터 사이언스를 말합니다. 데이터를 적재하고 기초적인 BI 지표(DAU, NRU 등)가 나오고 그다음에 분석이 필요하다고 생각합니다. 

 

가장 첫 번째로 데이터엔지니어로써 데이터를 사용하는 사용자(데이터 분석가, 데이터 사이언티스트 등)에게 데이터를 빠르고 정확하게 전달해줘야 하는 게 첫 번째라고 생각합니다. 그다음에 분석가들에게 시간을 주고 함께 BI 관련 지표를 만들어고 그 다음에 어떠한 분석이든 시작해야 한다고 봅니다.

 

많은 사람들이 "이거 해주세요. 저거 해주세요." 하는 ASAP 식 업무에 시달리며 이도저도 아닌 데이터 환경을 구성합니다. 그렇게 일하다 보니 하나씩 하는 게 아니고 이거 했다가 저거 했다가 하다 보면 아무것도 아닌 데이터 환경이 됩니다. 만약에 RDB의 OLTP 데이터를 우선 적재하기로 하였다면 우선 그것을 적재하고 그다음에 반정형이든 비정형이든 CRM 데이터든 적재를 해줘야 합니다. 

 

적재가 끝나면 데이터를 함께 가공하여 DAU, NRU 등의 여러 가지 기본 지표를 만들어주고 일단 제공을 해줘야 합니다.(기본 지표는 회사의 성격과 산업군에 따라 다를 수 있습니다.) 기본적으로 볼 수 있는 지표가 나오고 그다음에 분석을 하는 게 순서가 아닐까 싶습니다. 제가 항상 어디 회사를 가도 자주 하는 말이 있는데요. "걷지도 못하는 사람들에게 어떻게 날아다니라고 하느냐?"입니다. 어떠한 일에도 순서가 있고 차근차근해야 한다고 봅니다. 그렇기 때문에 기어 다니기 -> 걷기 -> 뛰기 -> 날기 순서로 가야지 처음부터 날아보세요. 한다면 당연히 정상적인 날기가 불가능합니다.

---

2) OLAP라는 것을 잊지 말아야 한다.

OLAP

 

이 발언은 나름대로 소신발언입니다. 많은 분들이 반발을 할 수 있지만 어디까지나 저의 개인적인 생각이므로 오해 없으셨으면 좋겠습니다. 나는(데이터쟁이) OLAP라는 것을 잊으면 안 됩니다. OLAP는 Online Analytical Processing의 약자입니다. OLAP가 중요한 게 아니고 정확히는 우리는 뒷부분입니다.

 

OLTP(Online Transaction Processing)가 앞에서 데이터를 받는 곳이라면 OLAP는 OLTP의 뒤에서 데이터를 받아서 처리해야 합니다. 그렇기 때문에 OLTP에서 데이터를 정확하게 수집하고 잘 수집해야 합니다. 여기서 설명하는 OLTP가 RDB에 한정되어 있기는 하지만 많은 사람들이 개발자의 입장과 DBA의 입장은 생각하지 않고 무조건 가져가려고만 합니다. 

 

개발을 할 때 이 부분은 어렵다고 설명해도 듣지 않고 무조건 해달라고만 한다면 서로 타협이 아니라 강요입니다. 그렇기 때문에 개발자의 입장과 DBA의 입장을 듣고 우리 쪽에서 할 수 있는 방법이 없는지 찾는 게 필요합니다. 물론 우리 쪽도 어느 정도 해주시면 좋겠다고 말해야겠지만 무조건 요구만 하면 안 됩니다. 그리고 앞서 이야기했듯이 우리는 OLAP입니다. 최근에 물론 OLAP를 통해서 데이터를 제공하는 서비스를 만드는 경우가 많긴 하지만 OLTP가 멈추면 서비스 자체가 멈추므로 OLTP > OLAP로 중요도가 더 높다고 생각합니다. 

 

그렇기 때문에 최대한 OLTP의 서비스에 문제가 없도록 하면서 만드는 부분이 가장 중요하고 협의를 할 때 OLTP의 입장을 최대한 고려해서 데이터를 가져오는 파이프라인을 만들거나 서비스를 만드는 게 중요하다고 생각합니다.

---

3) 오는 게 있으면 가는 게 있어야 한다.

Give and Take

 

"Give and Take" 오는게 있으면 가는게 있어야 합니다. 물론 아무것도 없는 데이터 환경에서 주는 것은 많이 어렵지만... 나중에라도 해줄 수 있는 부분이 있다면 해주는 게 좋습니다. 예를 들면 개발자를 위해서 데이터베이스 스키마 검색을 만들어 준다거나 마케팅팀을 위해서 CRM데이터를 적재하는 파이프라인을 약속하거나 할 수 있습니다. 아니면 데이터 사용자를 위해서 데이터를 손쉽게 볼 수 있는 데이터레이크 시스템 대시보드를 제공하는 것도 하나의 방법이라고 생각합니다. 

 

데이터레이크 대시보드 관련하여 내용은 제가 예전에 썼던 "[DataLake] 데이터레이크 운영 시스템 도입기"를 참고 부탁 드립니다.

[DataLake] 데이터레이크 운영 시스템 도입기

 

저 같은 경우 OLTP에서 데이터를 빠르고 문제없이 가져오기 위해서 데이터베이스 구조를 조금 변경해야 하는 이슈가 있었는데요. 이때 개발자분들이 보실 수 있도록 데이터베이스 스키마 검색 대시보드, 데이터베이스 인덱스 검색 대시보드, 데이터베이스 테이블 용량 대시보드등을 만들어서 제공하였습니다. 그다음에 개발자분들에게 제가 원하는 부분을 설명드렸고 그 이후에는 역시 좋게 받아주셨습니다. 확실히 사람은 Give And Take입니다. 

 

그렇게 협의를 한 내용은 제가 예전에 썼던 "[ETL] RDB에서 데이터 ETL를 위한 최소한의 테이블 설계"에 작성하였습니다.

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

 

위의 내용을 개발자분들에게 PPT로 만들어서 일일이 설명하였고 공감대를 얻어서 이후에 만들어지는 테이블에 대해서 모두 적용해 주셨습니다. 이렇게 함으로써 이후에 별다른 문제없이 데이터를 OLAP로 가져왔습니다. 

 

---

4) 자존심보다는 일을 하자

자존심 잠시 접어두고...

 

이 글을 보는 많은 분들이 스타트업에서 데이터를 시작하시거나 도입을 생각하시는 분들일 것이라고 생각됩니다. 그렇기에 스타트업 기준으로 본다면 자존심을 세우면서 "그건 너 일이고 이건 내일이니 그건 안 할래"라는 마인드로 하지 말고 데이터와 관련된 일이라면 적극적으로 한번 나서보세요.

 

가장 많이들 이야기 나오는 게 CRM 데이터인데요. 보통 마케팅팀에서 주로 사용하시는데, 보통 데이터를 수집하는 업체에서 데이터를 S3와 같은 저장소에 넣어주면 우리가 이걸 가공해서 데이터레이크나 데이터웨어하우스에 넣어줘야 하는 경우가 많습니다. 보통 이러한 데이터는 CSV로 떨어지는데, 이 데이터를 일일이 저장소에서 보거나 하기도 힘들고 업체에서 제공하는 웹사이트로 대규모 데이터나 커스텀하게 보기 어렵습니다. 그렇기 때문에 우리가 어느 정도 가공해서 테이블화 시켜서 제공해 주면 굉장히 도움이 많이 됩니다.

 

하지만 이러한 "업체와의 컨텍은 내가 왜 해야 하지?"라는 생각으로 많은 데이터 엔지니어들이 컨텍을 하지 않습니다. 물론 당연한 듯이 상대방이 왜 안 해? 하면 기분 나쁘지만 상대방이 부탁을 한다면 한번 만들어 주고 위의 3번의 내용처럼 Give and Take를 하면 어떨까요?

---

제2장) 밑밥 깔기

혹시 "밑밥 깔다"라는 말을 들어보셨나요? 밑밥이라는 말은 낚시 용어라고 합니다. (저도 처음 알았어요.) 국어사전에 밑밥을 검색해 보면 다음과 같이 나옵니다.

"물고기나 새가 모이게 하기 위하여 미끼로 던져 주는 먹이"

 

그리고 다음으로 동사 "깔다"라는 말이 나오는데 여기서 깔다는 "바닥에 펴 놓다"의 의미로 쓰입니다. 바닥에 펴 놓다는 의미입니다. 결국 미끼를 바닥에 펴 놓는 것을 의미합니다. 고기 잡기 위해서 미끼 던진다는 의미이죠. 데이터를 수집하기 위해서도 어느 정도 준비 과정이 필요합니다. 어느정도 체계가 잡힌 회사나 데이터를 이미 잘 다루는 회사라면 이러한 밑밥이 잘 깔려 있겠지만 처음 시작 하는 회사의 경우는 그 어떠한 것도 없습니다.

 

그렇기 때문에 이 밑밥을 까는 작업이 굉장히 중요합니다. 그 밑밥을 깔았던 내용을 이번 장에서 소개하려고 합니다. 참고하여 현재의 회사의 사정에 맞게 도입을 고려하시면 좋을 것 같습니다.

---

1) 데이터 설계 

설계는 매우 중요하다

 

설계는 어느 분야에서든 중요합니다. 특히 데이터 분야에서 더욱 중요합니다. 데이터의 경우 전부 쌓아놓고 바꾸기가 매우 어려운 분야이기 때문입니다. 데이터를 쌓고 이를 또 가공하거나 옮기는 작업을 하려면 데이터 마이그레이션 작업이 필요합니다. 이러한 작업은 데이터의 크기와 형태에 따라서 천차만별이며 비용도 엄청나게 많이 발생할 수 있습니다. 

 

내가 아직 데이터가 얼마 없거나 아직 시작을 안 했을 때 미리 설계를 잘해서 나중에 들어가는 추가 비용과 리소스를 최소화할 수 있습니다. 데이터의 경우 탑을 쌓는 과정과 비슷하다고 볼 수 있습니다. 탑을 10층까지 쌓았는데 1층을 다시 만들 순 없습니다. 탑은 이미 2~10층까지 쌓여 있기 때문에 처음부터 다시 쌓거나 새롭게 쌓아야 합니다. 그렇기 때문에 데이터의 처음 설계는 매우 중요합니다.

 

설계는 여러 가지가 있겠지만 보통 초기 스타트업에서는 많은 분들이 정형 데이터인 RDB 데이터, CRM 데이터를 사용하고 반정형 데이터로 주로 Google analytics를 사용하는 것 같습니다. (저의 경험상으론 그렇습니다.) RDB의 경우 제가 앞서 공유를 드렸지만 다시 한번 공유드리면 [ETL] RDB에서 데이터 ETL을 위한 최소한의 테이블 설계로도 충분하다고 봅니다. (물론 DBA 잘 설계하면 좋지만...)

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

 

그리고 Google analytics 로그 설계에 관련해서는 변성윤 님의 블로그에 자세히 나와 있으니 자세한 내용은 참고하시면 좋을 것 같습니다. 데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것

데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것

 

이 밖에도 서버로그 또는 여러 가지 로그가 있겠지만 주로 처음에 시작하면 위의 2가지 로그를 많이 사용하므로 2가지를 언급 하였습니다. CRM 로그의 경우 업체에서 제공하는 스키마 정의서가 있고 이미 정형으로 들어오거나 가끔씩 배열 형태로 들어오긴 하지만 어렵지 않게 데이터를 적재 할 수 있으므로 언급하지 않았습니다. 

---

2) 현황 파악 하기

현황 파악은 무엇보다 중요하다

 

지금 현재 데이터를 어떻게 가져와야 할지 어떤 데이터를 가져와야 할지 현재 내가 사용할 수 있는 비용은 얼마인지 등의 여러가지 현황을 파악해야 합니다. 일단 해본다?라는 접근으로 시작하면 나중에 고치고 고치고 또 고치고 하다 보면 내가 지금 뭘 만드는 건지?라는 생각이 들기 쉽습니다. 

 

제 생각에는 현황 파악 없이 무조건 만들기 부터하면 나중에 덕지덕지라는 표현이 가장 잘 어울리는 거 같습니다. 여기서 말하는 현황파악에는 여러 가지가 있겠지만 지금 생각나는 것을 정리하면 다음과 같습니다. 

항목	내용
가져와야 할 데이터가 무엇인가?	- 데이터베이스의 종류는 무엇이며, 테이블마다 용량은 많은지? 인덱스는 잘 걸려 있는지? - 데이터베이스 이외에 가져와야 하는 데이터는 무엇인지? - 가장 급하게 가져와야 하는 데이터는 무엇인지?
월마다 사용 할 수 있는 비용은?	- 데이터환경을 구성하고 사용할 수 있는 비용이 얼마인지 파악 필요 - 달마다 나가는 비용에 대해서 예측 필요하여 타 부서 및 C레벨 설득 필요
데이터 구조 변경이 가능 한지?	- 데이터베이스를 변경 할 수 있는지 개발자,DBA와 협의 필요  - 데이터베이스를 변경 할 수 없다면 다른 방법은 없는지 협의 필요 - GA등의 스키마가 적절히 잡혀 있는지 확인 필요 (다시 잡아야 하는지 확인 필요) - 여러 데이터의 형태를 변환하여 넣을 수 있는지 아니면 내가 직접 후처리 해야하는지 확인 필요
나를 도와줄 사람이 있는지?	- GA 스키마 설계등을 도와줄수 있는 사람이 있는지? - 데이터베이스의 구조를 변경한다면 구조를 변경할때 적용을 해줄 사람이 있는지? - 혹시 데이터 플랫폼 환경을 인프라팀에서 도와줄수 있는지 아니면 내가 해야 하는지?

 

지금 생각나는 것만 적어도 굉장히 많이 있습니다. 현황을 파악하고 이를 꼭 문서로 작성하거나 데이터화시켜서 언제 어디서나 누구와 이야기를 할 때든 보여주고 확인시켜 줘야 합니다. 생각해 보면 우리가 하는 일이 데이터 기반으로 의사 결정을 돕고 누군가를 설득시키는 일인데 왜 우리는 단순히 말로만 하려고 할까요...

---

3) 데이터 인프라 세팅 

인프라는 어디서든 중요하다.

 

인프라는 어디서든 중요합니다. 실제 세계에서도 인프라는 중요합니다. 우리가 당연하다고 생각하는 도로와 공공시설들은 모두 인프라입니다. 인프라가 없는 지역을 상상해보세요. 정말 불편할 것입니다. 그렇기 때문에 인프라 환경을 세팅하는 것은 매우 중요합니다. 데이터 파이프라인을 만들었는데 인프라가 없다면 데이터를 주기적으로 적재하는 환경을 만들 수 없습니다.

 

이 글의 제목에서 나와 있듯이 이 글은 "나 혼자 데이터 환경 구성"입니다. 혼자서 하다 보니 인프라 구성도 혼자서 했습니다. 물론 어느 정도 인프라팀의 도움을 살짝(네트워크 같은...) 받긴 했습니다. 

 

그리고 이 부분은 TMI 이긴 한데, 제가 다녔던 G사의 환경은 AWS를 기반으로 서비스 환경을 제공하고 GCP를 기반으로 데이터 환경을 제공하였습니다. 그렇기 때문에 서로 간의 다른 플랫폼을 사용하였는데요. 꼭 인프라팀과 협의해서 VPC와 Subnet을 잡아야 합니다. 나중에 AWS와 연결할 때 Subnet 대역이 겹치면 연결이 안 되는 경우가 있습니다. (요즘은 AWS transit gateway가 나오긴 했지만...) 

 

주로 많이 사용하는 도구가 Airflow인데요. 혼자서 구축을 하다 보니 GCP의 Composer를 이용해서 Airflow를 구성하였습니다. 

Cloud Composer 개요  |  Google Cloud

 

Composer를 이용하여 Airflow에 관리 포인트를 줄이고 어느 정도 운영 부담을 덜었습니다. 또한 Composer와 Git을 연동하기 위해서 GCP의 Code Build를 사용하였습니다. 위의 2개를 연동하여 자동 연동이 되는 것은 저의 블로그에 작성하였습니다.

Cloud Build 문서  |  Google Cloud

 

[GCP] Composer를 Git repo에 연동 글을 참고하여 자동으로 Airflow의 GCS Bucket과 Git repo를 연동하여 사용하시면 어느 정도 구색(?)을 갖춘 미니 데이터 플랫폼 환경을 만들 수 있습니다. (물론 스케줄링 밖에 없지만요...)

[GCP] Composer를 Git repo에 연동

 

이밖에도 여러 가지가 있겠지만 우선 데이터를 가져오는 것이 가장 중요하다고 생각하여 이 부분만 언급하였습니다. 추가적인 부분은 개인적으로 질문해 주시면 답변해 드리겠습니다.

 

---

제3장) 대화가 필요해

개그 콘서트 대화가 필요해

 

제가 이 부분은 다른 글에서도 많이 언급하였습니다. 대화를 좀 하세요... 많은 사람들이 "그냥 일은 일이다"라고 생각하는데요. 일은 사람과 합니다. 누구와 무엇을 하든지 사람은 대화를 필요로 합니다. 이메일이나 Slack 메신저로 일을 요구만 한다면 쉽게 굴러가지 않습니다. 그렇기 때문에 대화를 통해서 미리 친해지고 알아가는 부분이 중요하다고 생각합니다. 

 

이 부분도 어쩌면 밑밥을 까는 작업이라고 생각할 수 있겠습니다. 이게 누군가는 정치질(?)이라고 생각할 수 있지만 제가 생각하기에 정치도 좋게 하면 옳다고 봅니다. 누군가를 깎아 내리거나 험담이 아니고 일을 하기 위한 정치는 좋다고 생각합니다. 일을 하기 위해서 친하게 지내는 것인데 왜 나쁘죠? 

 

그리고 데이터로 무언가를 만들고 아무도 사용하지 않는다면 아무 소용이 없습니다. 데이터를 누군가 이용해 주어야지 그때 비로소 빛이 난다고 생각합니다. 내가 데이터를 아무리 잘 적재하고 가공하고 후처리를 해줬다고 한들 아무도 사용하지 않는다면 그게 무엇일까요...? 그냥 데이터 덩어리 아닐까요...? 

 

그렇기 때문에 대화를 통해서 홍보를 하고 이러한 일을 하기 위해서 노력하고 있다는 밑밥이 중요합니다. 나 혼자서 아무도 알지 못하는 일을 한다면 누구도 지지하지 않을 것 같습니다. 저는 언제나 데이터를 사용하는 모든 사람을 고객이라고 합니다. 데이터를 사용해 주는 사람이 있어야 제가 밥그릇 지킬 수 있다고 생각하기 때문입니다. 

 

그렇기 때문에 여러 데이터를 사용하는 부서에게 적극적으로 홍보하고 대화를 통해서 우리를 알리는 작업은 매우 중요합니다. 그리고 데이터를 모른다고 비하하고 폄하하지 말고 가르쳐주고 사용할 수 있도록 해주세요. 관련하여 제가 이전에 작성하였던 글인 [공통] 데이터를 적재하고 보기까지 를 참고하여 교육 자료를 만들거나 공유하면 좋습니다.

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

 

---

마치며...

[공통] 나 혼자 데이터환경 구성 - 제1부를 작성하고 하루 만에 2부를 작성할지는 저도 몰랐습니다... 집에 가서 퇴근하고 글을 쓰다 보니 빠르게 글을 완성한 것 같습니다. 그리고 100% 저의 경험을 기반으로 하였고 제가 혼자서 만든 환경이다 보니 빠르게 작성할 수 있던 것 같습니다. G사에서 많이 힘들긴 했지만 그래도 많은 경험을 하였고 팀장으로서 많은 분들의 지지를 받으면서 굉장히 만족스러운 데이터 환경을 구축하였던 것 같습니다.

 

2부의 경우 데이터 환경을 만들기 전에 초석을 다지는 과정을 설명하고자 글을 작성하였으며, 이 글을 참고하여 스타트업이나 이제 막 데이터를 도입하고자 하는 기업에서 참고하여 많은 도움이 되셨으면 좋습니다. 저의 경험과 스킬을 기반으로 작성하였기 때문에 다른 분들과 많이 다를 수 있지만 여러 가지 방법 중에 하나라고 생각합니다. 

 

그렇게 때문에 어디까지나 참고 차원에서 보시고 궁금하신 내용은 댓글을 달아주시면 답변해드리겠습니다. 많은 주니어 분들이 회사에서 혼자 내던져져서 빠르게 결과물을 만들어 달라는 압박으로 일을 제대로 배우지 못하고 보여주기 식으로 배우는 경우가 많습니다. 그런 부분이 너무 안타까워서 글을 쓴 것도 있고, 예전에는 사수-부사수 관계로 밀착 마크해서 일을 가르쳐줬는데, 이제는 각자도생 시대라서 그런 게 없다 보니 이 글을 통해서 많은 분들이 도움 받길 바랍니다.