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

나혼자 데이터환경 구성

 

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

2부에서 3부로 넘어오는 시간이 조금 길었습니다. 개인적인 일이 매우 많아서 글 쓸 시간이 없다 보니 3부를 시작하는데 시간이 오래 걸렸습니다. 3부는 본격적으로 데이터를 데이터 환경을 구성하는 실제 개발 과정에 대한 경험과 방법에 대해서 다루려고 합니다.

 

물론 자세한 코드나 기법에 대해서는 부족 할 수 있으나 어느 정도 고민 하는 부분을 해결해주는 수준에서는 큰 도움이 될 것 같습니다. 그리고 3부에 들어가기 앞서 2부의 내용을 한번 더 숙지하고 비교하면서 읽어 보시면 아주 큰 도움이 될 것 같습니다.

 

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

 

2부의 내용에서 밑밥을 까는 단계였다면 이제 본격적으로 그물을 던져서 물고기를 낚아야 하는 단계 입니다. 물고기를 낚으려면 먼저 그물을 잘 준비해야 합니다. 

---

제1장) 준비를 철저히 하자

많은 사람들이 준비 없이 일을 시작 합니다. 어떠한 일을 하던지 준비는 필수입니다. 준비에는 여러 가지가 있겠지만 제가 생각하기에 일을 하기에 앞서서 현재의 상황을 파악하는 게 가장 중요한 것 같습니다. 예를 들면 지금의 데이터중에 쓸 수 있는 (데이터 환경에서 쓸 수 있는) 데이터는 무엇이 있는지? 확인하고 이 데이터를 가져오기 위해서는 어떻게 해야 하는지 생각해야 합니다. 

 

제가 예전에 썼던 최소한의 ETL을 위한 RDB 설계에서 처럼 가져올수 있는지 잘 있는지 등을 고려해야 합니다.

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

 

무턱대고 "무조건 가능 합니다." / "언제까지 가능합니다."등의 말을 먼저 한다면 나중에 난감한 상황이 생길 수 있습니다. 그래서 현재의 현황을 파악하는 게 가장 중요합니다.

---

1) 진짜 있어? 잘 있어?

진짜 있는지 확인해보세요.

 

많은 사람들이 데이터가 있다고 하거나 "이렇게 되어 있어요." 라는 말을 그대로 믿습니다. 내가 직접 확인하고 판단하는 게 아니고 있다고 듣고 그렇구나~ 하고 생각합니다. 이렇게 하면 앞서 언급 한것과 같이 막상 데이터를 가져오려고 할 때 가져오지 못하거나 가져오지 못할 만큼 설계가 잘못되어 있어서 가져오지 못하는 경우가 있습니다. 

 

데이터베이스를 가져온다고 가정 했을때 몇 가지 상황이 있는데요. 예를 들면 다음과 같습니다. 

• 데이터베이스에 로그 테이블이 있다고 하였는데, 트랜잭션 테이블인 경우 
• 데이터베이스에 생성일자,수정일자 칼럼이 있다고 하였는 데 있긴 하지만 반영이 안 되는 경우 
• 로그성 테이블이라고 하였는데 로그성 테이블에 업데이트가 일어나는 경우 
• 테이블이 너무 커서 가져 가려고 하면 데이터베이스에 너무 큰 부하를 줄 수밖에 없는 경우 

 

지금 당장 생각나는 경우만 해도 4가지가 있습니다. 이렇듯 데이터를 확인하지 않고 우선 잘 있다고 하니 확인하지 않고 데이터를 사용해야 하는 부서에 일정을 이야기하고 이때까지 해드릴게요~라고 하면 나중에 실제 작업을 할 때 굉장히 난감한 상황이 됩니다.

---

2) 현황을 파악하고 문서화 하기

문서화 하자

 

앞서 이야기했듯이 현황을 파악하는 것도 중요하고 문서화하는 것도 중요합니다. 현황은 파악했지만 혼자만 알고 있거나 어떠한 곳에도 정리하지 않는다면 나중에 누군가 물어봤을 때 정확한 기억을 하기 어렵고 공유 차원에서도 매우 좋지 않습니다. 어떠한 일이든 사람은 함께 해야 하고 회사에서도 공유가 이루어져야 합니다. 

 

그렇기 때문에 각자 개인적으로 정리가 아닌 양식에 맞게 정리가 필요합니다. 다음으로는 제가 생각하는 몇 가지 체크 사항에 대해서 정리해 봤습니다. 각자의 회사 및 팀의 사정에 맞게 확인하셔서 적용하시거나 뺄 수 있는 건 빼면 좋을 거 같습니다.

종류	내용
ETL 관련 공통	- 배치 주기 협의 및 확인  - 배치 시간 및 동기화 최종 시간 협의 및 확인 - 데이터를 가져올때 APPEND , UPSERT , OVERWRITE 등 확인
데이터베이스 ETL 관련	- 데이터베이스 각 테이블의 사이즈 정리  - 데이터베이스 종류 및 네트워크 접속 가능 여부 테스트 및 정리 - 테이블 인덱스 여부 확인  - 데이터가 변환 되거나 로그성인지 트랜잭션 성인지 확인
반정형 데이터 ETL 관련	- 저장소 및 보관주기 협의 및 확인 (Life cycle) - 파일 종류 협의 (json , parquet , Avro 등등)
기타 로그 ETL 관련	- 업체에서 어떤 저장소에 어떠한 형태로 데이터를 넣어줄 수 있는지 배치 주기는 언제인지 협의 및 확인 필요 - 추가적인 비용이 발생하지 않는지 등의 협의 필요

 

지금 생각나는 것만 적어도 상당히 많습니다. 초기에 확인하고 협의해야 하는 내용이 굉장히 많고 밑밥을 까는 작업이 한두 가지가 아닙니다. 이외에도 각자의 회사 및 팀의 사정에 맞게 여러 가지 더 조사를 해야 하는 경우도 있고 필요에 의해서 하지 않아도 되는 것도 있습니다. 

 

그리고 앞에서 데이터 쪽의 현황 및 데이터를 관련자들과 협의를 하였다면 다음으로 사용할 수 있는 자원에 대해서도 확인해야 합니다. 우리가 현재 사용하는 Cloud 환경은 무엇인지? AWS? GCP? Azure? 아니면 IDC 환경인지 등의 여러 가지 환경적인 요인도 중요 합니다. AWS환경이라고 생각하였는데 IDC 환경이라면 구성도가 모두 바뀌어야 하기 때문에 나중에 큰 낭패를 볼 수 있습니다.

---

3) 구성도(설계도) or 데이터 흐름도를 그리자

설계도 없이 어떻게 건물을 지을까?

 

설계도가 없이 지어지는 건물이 있을까요? 설계도가 없이는 건물을 지을 수 없듯이 데이터 환경이나 파이프라인도 마찬가지라고 생각이 듭니다. 그렇기에 데이터 관련 된 무언가를 하기 앞서 구성도(설계도)를 그리는 게 필수입니다. 구성도를 그리는 도구는 아주 여러 가지가 있는데요. 우리가 아주 흔하게 접하는 파워포인트가 가장 흔하고 인터넷에 무료로 사용할 수 있는  draw.io도 굉장히 보편적입니다.

 

Flowchart Maker & Online Diagram Software

 

물론 회사에 유료로 사용하는 도구가 있거나 이미 다른 도구를 사용하고 있다면 그에 맞게 통일해서 그리길 권장합니다. 본인만의 길을 가는 것은 본인 혼자서 할 때만 칭찬받습니다... 웬만하면 회사에서는 남들과 통일성을 맞추는 것을 권장드립니다.

---

제2장) 만들자 

데이터 환경을 만들기 위해서는 여러 가지를 만들어야 합니다. 이 글에서 코드나 기술에 대한 이야기보다는 어떠한 콘셉트로 하였는지 그리고 어떠한 방법으로 만들었는지에 대해서 설명하고자 합니다. 코드 및 기술에 대한 자세한 이야기는 아마도 각자의 회사의 상황과 각자의 기술 스택이 다르기 때문에 같은 데이터를 바라봐도 다르게 생각할 수 있기에 단순히 제가 하였던 내용을 위주로 작성하려고 합니다. 제가 하는 방법이 꼭 맞는 것은 아니며, 제가 해왔던 방법이므로 참고 차원에서 봐주시면 좋을 것 같습니다. 

---

1) 너 자신을 알라

아 테스형

 

굉장히 뜬금없죠? 제가 이 나 혼자 데이터 환경 구성은 G사에서 근무한 경험을 바탕으로 작성하였다고 언급했습니다. G사에서 근무할 때 혼자서 데이터엔지니어링 업무를 하였기에 인적 자원이 굉장히 부족하였습니다. 물론 저 자신을 갈아 넣으면서 만들긴 했지만 혼자서 하였기에 욕심을 버리고 타협할 것은 타협을 하고 인정할 것은 인정을 하고 데이터 환경을 구성하였습니다. 

 

저 같은 경우 GCP에서 구성을 하였는데, 당시에 GCP 서비스를 굉장히 많이 활용하였습니다. 예를 들면 우리는 Orchestration을 위해서 Airflow를 가장 많이 사용합니다. 스케줄 처리에 이만한 게 없습니다. 그런데 내가 현재 혼자서 업무를 처리해야 하는데 굳이 나중을 생각해서 GKE 또는 K8S를 꼭 세팅해서 그 위에 helm을 이용해서 Airflow를 세팅하고 운영까지 할 필요는 없다고 봅니다. 초기에 비용이 조금 더 들어가도 (아주 많이도 아닙니다...) 자신의 상황과 추후에 운영을 위해서 어느 정도의 타협은 필요하다고 생각합니다.

 

그리고 ETL 관련 도구들도 많이 있습니다.  예를 들면 GCP에 Dataflow 등과 같은 도구를 사용할 수 있으며 시각화로 GCP에서 제공하는 Looker studio를 이용해서 BI를 제공할 수도 있습니다. 꼭 비용을 극단적으로 줄이기 위해서 모두 제가 하나씩 세팅하고 운영해야 한다는 욕심을 조금 내려놓고 어느 정도 타협해서 할 필요가 있다고 생각합니다. 

 

---

2) 업무를 잘 나누자

업무 분장 중요하다.

 

너는 너 나는 나! 이런 생각이 아니고 내가 해줄 수 있는 부분과 해줄수 없는 부분을 정확히 파악해서 각자의 일을 잘 나누어야 합니다. 최근에 많은 회사에서 각자도생 시대를 맞이해서 방어적인 태도와 선을 긋는 커뮤니케이션을 하는데 그렇게 하지 말고 서로가 조금만 양보해서 각자 조금씩 서로의 업무 영역을 이해하고 서로 도와주려는 생각으로 한다면 훨씬 일은 수월해집니다.

 

제가 G사에 근무할 당시에 데이터 엔지니어가 저 혼자라서 너무 많은 업무를 담당하였습니다. 조금 나열하면 다음과 같습니다.

• 데이터 환경 구성 및 운영
• 데이터 플랫폼 관리
• 데이터 파이프라인 개발 및 관리
• 데이터 정책 구성 및 관리
• 데이터 시각화 환경 구성 및 운영

위와 같이 혼자서 너무 많은 업무를 담당하였습니다. 그래서 혼자서 뭐든 것을 하기에는 부족하여 당시 데이터 분석팀 팀장님에게 부탁해서 마트 설계 및 팩트 생성등의 업무를 부탁하였습니다. 단, 제가 데이터를 ETL 하고 가공할 수 있는 환경을 잘 만들어서 제공하였고 분석가들이 누구나 쉽게 데이터를 사용하여 마트, 팩트를 만들 수 있도록 하였습니다. 이렇게 하여 서로 상호 간의 시너지를 극대화하여 서로 좋은 사례를 많이 만들었습니다. 

---

마치며...

생각보다 기술적인 이야기가 많이 없어서 많은 분들이 실망(?)을 하셨을 수도 있겠다고 생각합니다. 그런데 앞서 이야기했듯이 코드를 논하고 방법론을 논하면 한도 끝도 없습니다. 각자의 회사의 상황과 팀의 상황이 다르고 각자 가지고 있는 기술의 스택이 전부 다르기 때문에 이 이야기는 하기 어렵다고 봅니다. 

 

저 같은 경우는 Airflow를 사용해서 Orchestration을 하고 python operator를 통해서 데이터를 ELT (Extract / Load / Transform) 처리합니다. 아마 ELT를 선호하시는 분들도 있고 ETL을 선호 하시는 분들도 계시고 python operator를 사용하시는 분들도 있고 BigQuery operator을 사용하시는 분들도 계시고 아예 Airflow를 사용하지 않는 분들도 계실 겁니다. 

 

누군가는 설루션을 통해서 한 번에 처리를 할 수 있고 방법은 너무나도 많기 때문에 각자의 방법에 맞게 사용하시면 좋을 것 같습니다. 제가 이 글을 통해서 말씀드리고 싶은 것은 마인드와 방법적인 부분을 말씀 드리고 싶었습니다. 

 

그리고 최근에 면접관으로 들어가면서 많은 주니어분들이 조언을 구하기 어려운 환경에 처해있고 혼자서 데이터엔지니어로써 데이터 환경을 구축하다 보니 이게 맞나? 틀리나?를 알지 못하고 하는 경우도 있고 혼자서 끙끙 앓는 경우도 많이 보였습니다. 그러한 많은 분들에게 도움이 조금이라도 되고자 이 글을 작성하였으니 조금이나마 도움이 되셨으면 좋겠습니다.

 

 

 

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

 

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