Analytics Engineer in Korea
최근에 Analytics Engineering에 대한 중요성이 늘어나면서 Analytics Engineer에 대한 수요가 최근에 많이 늘고 있습니다.
하지만, 우리나라에서는 Analytics Engineer란 직군에 대해서 아직 모르시는 분도 있고, 누군가는 그냥 Data engineer가 조금씩 해당 역할을 하고 있을 수도 있습니다. 오늘(2022년 9월 25일 기준) 원티드에서 해당 직군을 검색했을 때 Line Plus 단 하나의 회사만 검색됩니다.
하지만, 글로벌 Job Search 서비스인 glassdoor에서 검색하면 US에서만 10,000+ 이상의 채용공고를 확인할 수 있었습니다.
무슨 직군인지는 모르겠지만 한국에서는 아직 익숙지 않은 것은 확실해 보입니다. 그럼 이제 무슨 일을 하는 직군인지 살펴보겠습니다.
그래서 Analytics Engineer가 무슨일을 하나요?
Analytic Engineer는 Data Engineer와 Data Analyst가 필요한 능력들이 각각 섞여있으면서 추가로 문서화나 교육적인 능력을 필요로합니다. Data engineer처럼 data를 transform 하는 역할도 하지만 Data analyst처럼 해당 데이터에 대한 도메인 및 정보를 알고 있어서 end user(PO, DA, 일반 데이터를 분석하기 싶은 구성원) 들을 위한 데이터를 가공해서 만들어주고, 해당 데이터를 활용하기 위한 문서 및 교육도 진행하게 됩니다. (엔지니어링 + 데이터 분석 + 데이터 교육 -> 데이터 쟁이!)
사실 지금 해당 업무를 메인으로 또는 부분적으로 수행하고 계신분들이 많을 것 같습니다. 현재 데이터 엔지니어 role로 근무하면서 analyst를 요청을 받아서 buisness table로 만들거나, 도메인을 이해하고 분석 테이블을 생성하거나 looker를 통해서 segment layer를 제공하는 분들도 계실 것이고, 데이터 분석가로 일하면서 Looker를 통해서 분석 explore를 만들어서 end user에게 제공하는 분들도 계실 것입니다.
실제로 dbt에서 작성한 what-is-analytics-engineering이라는 글에서 아래와 같은 내용이 나옵니다.
The term “analytics engineer” is pretty new, and a lot of people doing analytics engineering work don’t go by this title (I didn’t a year ago!). So how do you know if you’re an analytics engineer?
아래는 DBT에서 소개한 Analytic Engineer라면 아래와 같은 문제를 해결하고 있다고 합니다.
- Business 질문에 답변이 가능한 단일 테이블을 생성할 수 있는가?
- wahoure에 table에 가장 깔끔한 naming convention을 많을 수 있는가?
- business user가 Looker에서 문제를 발견하기 전에 문제에 대한 Alert를 notifiction 받는가?
- Analyst나 business user필요한 테이블을 빠르게 이용하기 위해서 무엇을 해야하는지?
- 다운스트림에서 데이터를 정리하지 않고 생성된 데이터의 품질을 향상하려면 어떻게 해야 합니까?
정리해서 말하면 Analyst 및 Business user에게 분석을 위한 데이터 가공과 뛰어난 분석환경 제공이 해당 role의 미션으로 보입니다. 데이터웨어하우징 후에 단순히 대쉬보드 및 리포팅하는 것을 뛰어넘기위해서 필요한 직군으로 보입니다.
왜 갑자기 Analytics Engineering이 중요해지고 있나요?
개인적으로 이 부분은 크게 두 가지 이유가 있다고 생각합니다.
1. Modern Data Stack 의 진화
최근에 많은 데이터 서비스들이 나오면서 해당 제품을 잘 사용하면 한두 명의 엔지니어로도 충분히 데이터 웨어하우스를 구축할 수 있게 됐습니다. Data warehouse로 BigQuery, Redshift, Snowflake같은 데이터웨어하우스 솔루션을 선택하고, Data Ingestion tool로 Fivetran, Segment, Stitch, Hevo같은 서비스를 사용하면 굉장히 빠르게 구축이 가능합니다. 처음 2019년에 처음 Fivetran을 사용했을 때 정말 편하고, 데이터 엔지니어 없어지는거 아닌가하고... 깜짝 놀랐던 기억이 납니다. 하지만, 좋은 건 비싸죠..! Data Ingestion tool 같은 경우에는 비용이 꽤 들어가기 때문에 저는 주로 많은 데이터가 나오는 소스는 직접 파이프라인을 구축하고, 데이터의 양이 적은 소스나 Third-party(Salesforce, Marketo, 등) 서비스를 위해서 사용하고 있습니다.
저는 실제로 전 직장에서 혼자 Fivetran, Airflow, BigQuery, Looker 등의 기술 스택을 사용해서 2달 정도 만에 데이터웨어하우스 구축 및 Looker로 다양한 Dashboard까지 구현했습니다. (물론 야근을 했습니다...!)
기본적인 데이터 웨어하우스 솔루션과 Ingestion tool의 등장으로 기본적인 데이터웨어하우스를 구축하는 것이 더 이상 큰 팀에서만 가능한 일이 아니라 적은 인원으로도 가능하게 됐습니다. 그래서 빠른 시간안에 데이터웨어하우스를 구축한 뒤에 실제로 분석에 필요한 데이터를 위한 transformation에 시간을 사용할 수 있는 환경이 됐다고 생각합니다.
2. 데이터팀의 성장으로 인한 직무의 세분화
이전에 데이터 웨어하우스를 구축한 후 분석을 위한 환경을 구축하면서 쉽지 않았던 부분 중의 하나가 transformation을 위해서는 도메인과 해당 데이터가 어떤 비즈니스 로직을 통해서 쌓이는지 context를 파악하는 것입니다. 데이터 소스가 Product, Sales, Marketing 등 다양한 곳에 존재하기 때문에 엔지니어링에 강점이 있는 데이터 엔지니어분들은 이 부분을 모두 파악할 수 없고 이 부분은 Analyst의 영역이고 수동적으로 요청 받은 토대로 작업하게 됩니다. 도메인 지식 없이 기계적으로 요청을 받아서 하는 경우에는 사실 생산성에도 좋지 않고, 커뮤니케이션 문제도 발생하게 됩니다. 이런 상황에서 Data팀의 규모가 성장하면서 Data Engineer or Data Analyst 중에서 비즈니스에도 관심이 있고, 분석 환경 및 교육에도 관심이 있는 분들이 조금 더 R&R을 잘 나누어 일하게 되었다고 생각합니다. 또, Looker나 DBT같은 툴이 나오면서 Data Analyst 들도 프로그래밍 학습을 통해 Analytics Engineering 쪽으로 많이 넘어가는 추세로 보입니다.
마지막으로 왜 한국은 Analytics Engineering 추세가 느린가요?
이 부분도 개인적으로 2가지 정도 이유가 있다고 생각합니다.
1. Modern Data Stack 으로 전환이 늦음.
한국에서 모던 데이터 스택을 잘 활용하는 회사들이 아직은 많지 않아 보입니다. 아직 Hadoop을 Storage로 사용하고 있는 회사들도 많고, Ingestion Service를 사용하는 회사도 적어보입니다. 여러가지 이유가 있겠지만 크게 보안적인 이슈, 관행적인 이슈가 있어보입니다. 보안적인 이슈는 Ingestion tool같은 경우 데이터가 다른 회사의 서버로 전송되는 부분이 존재하기 때문에 이런 보안적인 문제로(경험해보지 못함, 규제 이슈) 한국에서는 많이 사용하지 못하고 있는것으로 보입니다. 특히, Ingestion tool의 선두주자인 Fivetran도 아직 한국에 서버가 존재하기 않기 때문에 국외로 데이터가 넘어가는 부분이 존재합니다. 관행적인 이슈는 아직 한국에서는 비용이 꽤 발생하는 개발 SaaS를 사용하는 것에 보수적입니다. 이는 SaaS 시장의 규모만 봐도 확인 할 수 있는 부분입니다. 이런 부분 때문에 결과적으로는 작은 팀에서는 Analytics Engineering까지 진행하기가 쉽지 않고, 이 뿐만 아니라 다양한 소스의 데이터들을 통합하지 않거나 오랜 시간이 필요합니다.
DBT 에서 말하는 modern data team.
Today, if you’re a “modern data team” your first data hire will be someone who ends up owning the entire data stack. This person can set up Stitch or Fivetran to start ingesting data, keep a data warehouse tidy, write complex data transformations in SQL using dbt, and build reports on top of a clean data layer in Looker, Mode, Redash, etc.
This job is neither data engineering, nor analysis. It’s somewhere in the middle, and it needed a new title. Starting in 2018, we and a few of our friends in the Locally Optimistic community started calling this role the analytics engineer.
2. 아직 성숙하지 않은 데이터 분석 및 드리븐 문화
아직 한국의 대부분의 회사는 데이터를 잘 활용하는 문화가 부족하다고 느껴집니다. 특히, 일반 사용자들의 데이터 활용 능력이 아직 성숙하지 않고, 대부분 리포트와 대쉬보드를 만드는 정도의 Data 활용사례가 많습니다. 동료 중 Grab에서 일한 경험이 있는 동료한테 2,3년 전 기준으로 Grab에는 DE가 50명이고, DS가 100명, Product DA가 100명이라는 이야기를 듣고 최근에 많이 놀랐던 기억이 있습니다.
위와 같은 이유들로 아직 몇 몇 큰 회사들만 채용중인 것으로 보입니다. 우리나라에서도 토스(비바리퍼블리카) 같은 회사에서 Data Engineer(Analytics)라는 직군을 많이 채용하고 있는것으로 확인됩니다.
정리
이 글에서는 Analytics Engineering이 어떤 역할을 하고, 최근에 왜 많이 생겨났는지를 Modern data stack과 함께 설명해봤습니다. 아직 규모가 작은 회사에서는 Data Engineer도 해당 업무도 진행하게 될 것 입니다. Analytics Engineering을 통해서 반쪽짜리 데이터웨어하우스가 아닌 온전한 데이터웨어하우스로 활용이 가능하다고 생각합니다. 저도 앞으로는 Analytics Engineering 부분 역량 개발을 위해서 노력을 많이 하면서, 관련 글도 많이 작성해 볼 예정입니다.
참조
'Computer Engineering > Data Analysis' 카테고리의 다른 글
| 차원 모델링이란 / Dimensional modeling (3) | 2023.07.17 |
|---|---|
| Pandas에서 시간, 날짜 데이터 변환하기 (총 정리) (0) | 2018.01.16 |
| 캐글 타이타닉 예제를 통해 알아보는 데이터 분석 및 활용 flow (0) | 2018.01.15 |