[인프런 온라인 밋업] 스포티파이에서 데이터 직군은 도대체 무슨 일을 하나요?

 인프런에서 데이터 직군 현업자에 대한 온라인 밋업이 열린다고 하여, 해당 유튜브 라이브를 실시간으로 시청해보았다.

 

백엔드 엔지니어 출신의 개발자가 데이터 엔지니어로 전향하게 된 계기, 그리고 어떤 일을 하는지 등에 대해서 이야기하고,

 

실제 많은 데이터 직군에 대해 어떠한 차이점이 있는지 늘 궁굼해왔는데 이에 대해서 잘 설명해주셨다.

 

 

도메인을 변경하게 된 계기와 이유

 네이버에서 스프링 개발자로 4.5년간 일하다, 마지막 2년 동안 스칼라와 스파크에 대해서 공부를 해왔는데

마침 다른 팀에서 스파크와 Hbase 기술을 사용한 프로토 타입 프로젝트를 제안받아 진행했었고, 이가 너무 잘 맞는 업무여서 전향하게 되었다.

 데이터는 상황, 사람, 세상을 설명하는 도구였고 이는 또다른 차원의 배움이였으며 새로운 기술적 경험이었다.

또 새로운 기술적 경험으로 더 많은 데이터를 빠르게 처리하기 위한 패러다임, '데이터 서비스'의 다른 개발 운영 방식이 맘에 들었다.

 

데이터 엔지니어의 현실

 실제로 엄청나게 복잡하고 어려운 스파크 파이프라인 개발 및 스칼라 코드 작성, 로그 수집을 위한 카프카 클러스터 운영 등을 생각했으나, 실제 업무는 아래와 같았다.

 

• 백엔드 서비스(Java) & 데이터 파이프라인(Scala)
• SQL 기반 데이터 프로덕트
• 스트리밍 파이프라인 (near-real-time)
• 데이터 모델링
• 데이터 검증, 퀄리티 분석
• 대시보드

특히 SQL 기반 데이터 프로덕트, 데이터 검증, 퀄리티 분석, 대시보드와 같은 데이터 사이언티스트, 데이터 애널리스트가 한다고 생각 했던 일들이 주요 업무가 되기도 했다.

 

데이터 직군의 차이

데이터 엔지니어, 사이언티스트, 애널리스트, 애널리스트 엔지니어 등의 차이는?

뭔가 느낌적인 느낌으로 이해할 수 있는 미묘한 차이인 것 같다.

 

Engineering vs Science

• 엔지니어링 = 자동화, 최적화
• 사이언스 = 가설 검증, 이해

데이터 분야는 데이터 이해 자체가 중요하기 때문에 특히 둘이 같이 필요한 경우가 많다.

데이터 크기가 커지거나 로직이 복잡해지면 엔지니어링의 힘을 빌려야하는 순간이 오기도 한다.

⇒ 데이터 사이언스, 엔지니어링은 같이 가는 부분이 많은 것 같다.

 

스포티파이에서는?

아래와 같은 에코 시스템(생태계)를 가지고 있다.

• GCP
• Dataflow, BigQuery, Google Cloud Storage(GCS), Pub/Sub, … 나머지 많은 데이터 툴링은 in-house 개발
• 언어: Scala, SQL, Python
• Jupyter Notebook, Dbt

 또, 누구나 데이터를 액서스 시스템을 통해 조회할 수 있고, 상당 수의 데이터가 언제든지 real-time online analysis가 가능한 형태로 저장된다.

직무에 상관없이 BigQuery, Jupyter Notebook을 통해 데이터를 확인하는 것이 매우 흔하다.

 

데이터 엔지니어가 주로 하는 일은?

플랫폼 조직에서

플랫폼은 많은 부분이 백엔드로 이루어짐

• 데이터 엔지니어라도 백엔드 지식이 필요한 것이 맞다

데이터 파이프라인을 실행할 수 있는 환경 구축 필요

대규모 데이터 수집

• 데이터를 수집할 수 있는 환경 구축
• 스키마 에볼루션(Schema evolution)
  • 데이터는 계속 변경되나, 그것을 이해하는 스키마도 계속 변경되어야하는데, 이를 어떻게 관리할지 하위 호환 등을 어떻게 처리할지 생각해야한다.

Data warehouse/Data lake ⇒ 다양한 형식의 데이터 제공

• Parquet in GCS, BigQuery
• Sampled data

 

비즈니스 조직에서

한 비지니스 도메인의 데이터 수집 및 전처리

데이터 모델링

다양한 데이터 간의 조합을 통해 가치 창출

데이터 퀄리티 모니터링

• On-time delivery
• Anomaly detection, …

 

데이터 사이언티스트가 주로 하는 일은?

데이터 분석과 퀄리티 검증

비지니스에 필요한 매트릭스 데이터 디자인

비즈니스 니즈에 따른 데이터 가공과 생성

• 해당 영역이 특히 엔지니어링 부분과 겹치는 영역이 많은 것 같다.

대시보드, 리포트

 

데이터 엔지니어? 사이언티스트?

데이터 엔지니어는 조직에 따라 다양한 업무를 할 가능성이 있음

데이터 분석 영역이 더 많은 데이터를 처리할 수 있게 발전하면서 두 영역의 경계가 모호해지고 있는 듯

 

Q) SQL로 할 수 있는 작업을 Spark로 대체해야 하는가?

• 데이터 엔지니어링 플랫폼은 최적화에 훨씬 다양한 옵션을 제공
• 테스트 작성 또한 수월함

 

저는 현업에서...

모든 사용자의 인터렉션 하나 하나 수집. 이는 매일 약 120 Bilion의 로그

회사는 이를 위해 많은 경제적 자원을 사용 중.

이러한 데이터는 사용자 분석, A/B 테스트, 매트릭스, ML 등 다양하게 사용됨.

 

데이터 엔지니어의 역할

계속 늘어나는 데이터 양에 대비한 파이프라인 최적화

데이터 모델링: 새로운 유즈케이스 vs 하위호환성 관리

여러 데이터 간의 pre-aggregation

• 플랫폼 차원에서의 어그리게이션을 수행

퀄리티 모니터링 및 커뮤니케이션

• 일관성, 정확도 등을 데이터를 통해 모니터링
• 문제가 발생하면 장애처럼 관리하고 클라이언트 팀에 전달

 

데이터 직군에서 필요한 마인드 셋

데이터 직군의 역할은 데이터 생성자와 사용자를 이어주는 연결고리 역할이다.

• 양쪽을 전부 이해하려는 관심과 노력이 필요
• Ex) mobile ↔ data ↔ product
• 좋은 데이터 서비스를 양쪽을 자연스럽게 연결시켜주어야 좋은 데이터 서비스

데이터 * 데이터 = 또 다른 데이터

• 데이터는 다양한 조합으로 이해할 수 있고, 새로운 시각을 줌
• 다양한 데이터간의 조합을 통해 또 다른 가치 발견

 

Nitpicking (꼬투리 잡는 자세)

데이터’만’ 보는 사람들이 원하는 정확도는 기대치가 매우 높을 수 있다

• 특히 다른 BE에서 데이터 직군으로 이동했다면, 스스로 가지고 있는 기대치를 올리는 편이 좋을지도
  • ex) API 왜 한번에 성공 못함? & 99% 정확도면 안된다. 99.9%로 가자

데이터 보는 사람이 꼬투리를 잡아야 데이터의 퀄리티가 올라간다

• Too good? Too bad? 일단 의심해라

 

데이터 직군 스킬트리

SQL Fluency는 매우 매우 중요

• SQL은 간단한 것 같지만 그래서 어렵다
  • Join 등의 실수로 데이터가 매우 어그러질 수 있다.
• 데이터 에코 시스템은 다른 도메인보다 역사가 짧다보니 unit-test 등의 기능이 부족한 편
  • 그러므로 SQL을 정확히 쓰고, 정확히 읽는 것이 중요함

하지만 SQL & 데이터 사용은 접근성이 낮으므로 또 다른 기술적 장점을 키우는 것이 중요하다.

 

데이터 직군과 AI

데이터 직군 = 데이터로 문제를 해결하고 질문에 답을 하는 사람들

SQL만 작성하는 것이 데이터 직군의 일은 아님

SQL로 받은 결과를 이해, 검증, 설명하는 것 까지가 우리의 역할

• 검증은 한 문장으로 설명할 수 없는 복잡한 지식이 필요한 경우가 많음

---

발표 세션은 여기까지였으며, 아래는 진행했던 Q&A이다.

 

Q&A

데이터 분석을 막 입문하는 사람에게 조언

• 실무에서 데이터 보는 사람은 많을 것이다. 대화를 통해 데이터를 심도있게 이해하는 과정이 저연차에서 중요한 것 같다.
• 데이터를 데이터만 보는게 아닌, 서비스 등의 Context를 함께 가져가면서 보는 것이 좋을 것 같다.
• 데이터 분석가는 아니지만, 데이터 분석을 할 때, 내가 원하는 질문을 명확히 하고 분석을 수행한다. 데이터 분석이라는게 끝이 없는 것으로 보이기 때문에 어디에서 시작했는지 잊어버리기 쉽다.

 

데이터 대시보드 & 레포트 등의 작업을 하는데 한계에 부딪힌 것 같다. 돌파구는?

• 저라면 어떤 데이터가 더 필요한지 제안하며 영향력을 높일 것 같다.
• 데이터라는 것이 항상 부족하기 때문에, 더 많은 데이터를 제안할 수 있는 사람이 되어 영향력을 올리자.

 

BE와 AI 엔지니어의 차이

• 데이터 엔지니어링, 데이터 사이언스 잘 맞는 사람
  • 데이터 보는 것을 좋아해야 한다.
  • 파이프 라인을 만들어도 스케줄링을 하면 계속 돌아가는 거라, 결국에는 거기서 나온 아웃풋을 분석하는 것이 마지막 데이터 엔지니어가 하는 일이 되더라.
  • 데이터 보는 것을 즐기고 이해하려는 노력을 기울일 수 있어야 한다.
• 차이
  • AI 엔지니어링을 안해서 잘 모르겠지만, AI & ML은 프로덕션에 나갈 수 있는 최적화의 접점을 찾아가는 것
    • 수많은 실패와 수행을 진행해야하는데, 이러한 것을 견딜 수 있는 태도
  • 백엔드 엔지니어는 단계적 완성
    • 개발-배포 사이클이 명확하기 때문에 충족도 만족도가 다를 수 있다.

 

데이터를 잘 쌓일 수 있게 하는 고민, 설계시 유의하는 점, 업무에서 우선순위

• 클라이언트에서 전달받는 데이터의 경우 릴리즈 사이클이 너무 길다. 잘못된 데이터를 바꾸기까지 너무 오래걸리고, 업데이트를 안받는 사용자도 있다. 롱테일 문제.
  • 파이프라인 전처리 등을 통해 최대한 쓰레기가 쌓이지 않도록 고민
• 기존에 있는 데이터와의 하위호환성이 항상 중요하다.

 

데이터를 분석할 때, 유용한 사고의 틀이 있으면 좋겠다. 데이터 분석 및 검증에서 수치의 정합성을 파악하는 노하우?

• 가설을 가지고 데이터에 들어간다.
  • 길을 잃을 수 있는 확률이 너무 높다. 시간을 너무 쏟게 된다.
  • 내가 궁굼한게 무엇인가? 등을 명확히 하고 SQL을 작성
• 분석하고 검증하는 과정에서 정합성 파악 노하우
  • 실제로 개발한 사람이 더 잘 아는 경우가 많다.
    • Client에서 이런 데이터를 받았는데, FE 개발자한테 가서 “이거 맞는 것 같아요?” 했을 때, “어 이거 맞는 것 같아요” 등 답을 준다.

 

데이터 엔지니어가 같이 일하고 싶은 분석가는?

• 데이터 분석가는 실제 어떻게 많은 것들이 디자인되고, 실제 임플리먼테이션이 되었는가에 몇 발자국 떨어진 사람들이다.
  • 자기 혼자 가설을 세우고 데이터 분석을 시작하는 사람이 많다.
    • 데이터 분석 자체가 잘못된 경우가 많았다.
    • 데이터를 볼 때, 어떻게 데이터가 만들어졌는지 이해하려는 사람들과 일하기 편했던 것 같다.
    • 데이터가 모든 것을 설명해주지 않으니, 데이터 분석을 정확하고 잘 하려면 어떻게 구현이 되었는지 어느정도 이해하는 것이 필요한 것 같다.

 

어떤 역량을 기르면 분석가로 잘 일할 수 있을까?

• 기본적인 CS 지식
• 백엔드에서는 데이터가 어떻게, 스키마가 어떻게, 어느 때 데이터가 나오는지 등의 대화를 따라갈 수 있는 소양
  • 도메인 마다 조금 씩 다를 것 같기는 하다.

 

스포티파이의 데이터 분석 결과 공유 방법

• 데이터 요구자에 따라서 달라진다
• 보통 프레젠테이션을 통한 방법이 마무리 단계에서 이루어진다.
• 대시보드 등의 시각화는 라이브 변화에 따른 조회자가 많거나, 스냅샷을 따기 어려울 때 사용한다.
• 데이터 Access는 플랫폼을 통해 요청하면 별 문제가 없으면 자유롭게 요청 가능.

 

데이터를 사용한 방법은 과거를 통해 미래를 예측하는 방법인데, 100%가 아니다 보니 부정적인 시각이 있다. 회사를 설득하는 방법은?

• 데이터 만으로 의사결정을 푸쉬하는 것이 아닌, 데이터가 의사결정에 도움을 줄 수 있는 방향으로 데이터를 공유하는 방식이 변경되어야 하지 않을까?
  • 데이터가 이러니까 이렇게 하는게 맞습니다. (X)
  • 데이터가 이러니까 패턴을 찾아보니 가능한 옵션은 이런 것이 있고, 이런 것들 중에서 결정을 해보는 방향으로 데이터를 사용 (O)
• 데이터가 정확하다고 모든 것을 말하는 것이 아니기 때문.
  • 데이터가 1%밖에 안되는 것인데 중요한가? 안 중요한가?
    • 나중에 PM하고 확인해보니, 비즈니스 차원에서 1%도 놓칠 수 없으니 가지고 가야한다로 의사결정됨.
• 데이터 = 의사결정을 도와줄 도구

 

최근 데이터 처리를 위해 SaaS 도입 사례가 증가한다. 스파크 등 하둡 등 오픈소스 다루는 역량이 앞으로도 중요할까요? 이런 상황에서 어떤 기술 & 커리어를 밟아야할까요?

• 스파크, 하둡이 어떤 매커니즘인지 공부하는 것은 매우 중요하다고 생각한다.
  • 우리는 개발자니까.
  • 어디에서 어떻게 일하게 될지 모르는데, 그런 맥락에서 그 내부가 어떻게 돌아가는지 기본적으로 중요할 것 같다.
• 어떤 기술을 메인으로 가져가야할지는 본인도 모르겠다.
  • 백엔드 영역에 발을 들여보는게 중요하지 않을까?
    • 쿠버네티스, 데이터 파이프 라인 등

 

최근 하고 있는 공부는?

• 파이썬
  • 창의적으로 사용 가능
  • 데이터 직군에서 할 수 있는 일들이 많아진다.
  • 그냥이 아닌 잘 할 수 있어야겠다.

 

AI 발전이 데이터 직군에 끼치는 전망

• 개발자는 문제를 푸는 사람이라고 생각한다.
  • 입에서 나온 아이디어를 기술로 실현
    • 이것 자체는 AI가 대체될 수 있지만, 이것을 검증하고 최적화된 방법인지 확인하는 것은 대체될 수 없는 지식인 것 같다.