데이터 엔지니어의 하루 1

나는 현재 네덜란드의 한 무역회사에서 데이터 엔지니어로 일을 하고 있다. 

데이터 엔지니어링이라는 직무가 사실 생긴지 얼마 되지 않아 회사마다 정의하는 방식이 다르기도 하고, 다루는 업무도 천차만별이다. 우리 회사의 경우 데이터 팀이 생긴지도 얼마 되지 않아 규모가 작지만, data-driven 조직이 되기 위한 목표와 전략이 명확하고, 회사 서포트도 빵빵하고, 각기 다른 데이터 관련 직무(데이터 엔지니어, 사이언티스트, 애널리스트)와 역할 분담이 나름 체계적으로 구성되어 있는 편이다.

데이터 엔지니어가 이론적으로 어떤 일을 하는지는 이미 잘 쓰여진 글들이 많으니 생략하고, 일주일 동안 내가 데이터 엔지니어로서 어떤 일을 하고 있는지를 하루 하루 기록해볼까 한다. 이번주를 예시로 Day1 - Day5까지 작성을 해보려고 한다. 

참고로 이를 작성하고 있는 이번주는 시기적으로 바쁜 프로젝트가 끝나고 새로운 프로젝트가 오기 전이라 비교적 한가한 시기에 속한다.

Day 1 월요일

이메일/모니터링 확인

월요일, 오늘은 재택근무를 하는 날이다.
9시쯤 책상에 앉아 이메일을 확인한다.
다행히 플랫폼이나 데이터 관련 모니터링에 알람이 온 것은 없다.

data scientist와 협업

시차가 있는 아시아 지사에서 일하는 데이터 사이언티스트가 머신러닝 모델 아웃풋 스키마 변경 작업이 끝났다는 이메일이 왔다. 저번주에 이 분이 머신러닝 모델 아웃풋을 보내왔는데 이미 스키마 변경을 두번이나 했고 추후에 또 바뀔 여지가 있었다. 스키마를 변경하게 되면 ML framework 쪽 뿐만 아니라 아웃풋을 처리하는 파이프라인도 계속 스키마를 업데이트 해줘야 하기 때문에, 더 static 하게 관리할 수 있도록 다른 스키마를 제안했고, 해당 작업이 끝났다고 알려온 것이다. 

나는 칸반보드에 이 테이블에 의존하는 다른 파이프라인을 업데이트 하도록 티켓을 생성했다.

스크럼

9시 반에는 매니저와 스크럼 미팅이 있어, 지난주 금요일에 한 일을 업데이트 하고, 오늘 무엇을 했는지 브리핑을 했다. (현재 데이터 엔지니어는 나 혼자라 매니저와 둘이서 스크럼을 한다.)
스크럼이 끝난 후 아까 생성한 티켓 작업을 시작했다.

파이프라인 업데이트

첫번째는 ML output을 스테이징 하고 데이터 마트에 넣는 파이프라인에서 스키마 정의와 아웃풋 테이블을 업데이트 해 줬다. 
그 후에는 데이터 마트에 있는 이 테이블을 사용하는 pyspark job이 있는데 해당 테이블을 사용하는 로직을 수정했다. 스키마를 업데이트 한 덕에 join하는 구문이 훨씬 간단해졌다. 
하지만 기존에 정의한 unit test 중 하나가 스키마가 달라진 값에 실패했다. unit test 에 사용하는 샘플 데이터의 스키마 역시 변경해준 후 모든 테스트가 성공하는 것을 확인 후 브랜치를 (PR 생성 후 ) 병합한다.

해당 티켓을 클로즈 하고, 다른 작업중에 있는 티켓을 살펴본다.
저번주 금요일에 로직 업데이트를 완성하고 아직 테스트를 못한 작업이 있다.
로직 업데이트 후 추출된 아웃풋을 확인하는데, 99%는 데이터가 잘 맞지만 1%정도가 결과값이 예상한 값과 다르다. 뭔가 이상해서 데이터를 계속 살펴보았다. 시간별로 추출해보고 다른 칼럼으로도 추출해보고, 그러던 와중 2주전에 업데이트 했던 코드에 이상이 있음을 발견했다. 2주전에 큰 릴리즈가 있었고 데이터 퀄리티를 검증하는 시기여서, 그리고 전체 데이터중 아주 작은 양의 데이터라 다행히 라이브 서비스 되는 것들에는 지장이 없었다. 바로 티켓과 브랜치를 생성하고, 버그를 고치고, 파이프라인을 개발환경에서 실행한다.

파이프라인이 완성되는데 까지는 꽤 걸린다. 어느덧 시간도 점심시간이 되어서 파이프라인이 실행되는 동안 점심을 먹는다. 머리를 식힐겸 잠깐 산책도 하고온다.

data analyst와 협업

돌아오니 파이프라인은 끝나있었고 데이터가 맞음을 다시 검증했다. 종종 코드 업데이트 자체보다 테스트하고 검증 하는것이 더 오래 걸리는 편이다. 해당 브랜치는 메인에 병합을 하고 금요일에 작업한 브랜치는 하지 않았다. 애널리스트에게 데이터가 맞음을 한번 더 검증하기 위해 내일 시간이 되는지 물어보고 30분짜리 미팅을 잡았다.

데이터 애널리스트가 seed file 업데이트를 위해 PR(Pull Request)을 생성하는데 궁금한 것이 있다고 하여 화상 통화를 한다. 저번주에 새로 도입한 방식인데, 기존에 사용하던 다른팀에서 관리하는 방식이 프론트엔드와 디비 싱크가 불안정하여 우리 팀에서는 신뢰를 잃었고, 그리하여 우리는 일단 자체적으로 csv 파일로 관리를 하기로 했다. 애널리스트가 사용할 repo를 만들고 csv파일을 업데이트 하면 CI/CD 파이프라인이 해당 파일을 스토리지에 업데이트 하는 식이다. PR을 리뷰하고 코멘트 한 부분을 함께 업데이트 하여 애널리스트의 첫 PR을 merge했다.

data quality 모니터링

통화가 끝난 후 우선순위에 있는 티켓을 보니 데이터 퀄리티 모니터링에 추가해야 할 것이 있었다. 모니터링이 필요한 부분을 SQL 로 작성하여 커밋하고, PR을 생성한 뒤 merge 한다.