데이터·AI 팀 조직과 커리어 2025 완전 정복: 데이터 엔지니어·분석 엔지니어·ML/AI 엔지니어·플랫폼 엔지니어 역할, Central·Embedded·Mesh 조직 모델, 연봉·채용·커리어 전략

프롤로그 · 도구보다 중요한 건 팀

Season 5 지난 8편에서 Lakehouse·스트리밍·OLAP·오케스트레이션·시맨틱 레이어·Vector/Graph DB·거버넌스·관측성까지 훑었다. 각 장에서 공통으로 반복된 결론이 있다.

"좋은 도구는 나쁜 조직을 구원하지 않는다."

2024-2025년 수많은 조직이 Snowflake·dbt·Databricks·Datadog 같은 최고급 도구를 사고도 데이터 드리븐(data-driven)이 되지 못했다. 이유는 거의 늘 같다.

• 데이터 엔지니어가 쿼리 티켓 공장 노동자가 되어 있거나
• 분석가가 쉬운 대시보드만 반복하고 있거나
• ML 엔지니어가 프로덕션에 모델을 못 올리거나
• AI 엔지니어 직군이 없어 LLM 앱을 데이터 엔지니어가 겸업하거나
• 중앙 팀과 도메인 팀의 경계가 모호해 서로 일을 미루거나

2025년의 데이터·AI 팀 운영은 역할의 분화 · 조직 모델의 선택 · 사람의 성장 경로라는 3축에서 동시에 재설계되고 있다. 이번 글은 그 현주소를 본다.

1장 · 2025년 데이터·AI 역할의 분화

2015년만 해도 "데이터팀"은 대개 Data Engineer + Data Analyst + Data Scientist 3개 역할로 충분했다. 10년 지나며 같은 일이 더 많은 직무로 쪼개졌다.

현대 데이터·AI 직군 지도

10개가 넘는다. 다 다른 직군이 필요하다는 뜻이 아니라, 한 사람이 겸업할 때 어느 역할을 하고 있는지 명확해야 한다는 뜻이다.

분화의 두 축

1. "What / How" 축: 비즈니스에 가까운 질문(What) ↔ 시스템에 가까운 기술(How)
   • Analyst → AE → DE → Platform Engineer 순으로 How 쪽
2. "Data / Model" 축: 데이터 파이프라인 ↔ 모델·AI 시스템
   • DE ↔ MLE ↔ AIE

보통 한 사람은 이 2차원 평면의 한 점에 있고, 커리어는 그 점이 시간에 따라 이동하는 궤적이다.

2장 · Data Engineer vs Analytics Engineer — 누가 무엇을 하나

가장 많이 혼동되는 경계다. 둘 다 SQL·파이프라인을 다루지만, 책임이 다르다.

명확한 구분 기준

Data Engineer (DE)

• 데이터의 수집·저장·플랫폼 책임
• "어떻게 하루 10TB를 안정적으로 Kafka → S3/Iceberg로 흘릴 것인가?"
• 스토리지 포맷, 카탈로그, 컴퓨트 엔진, 권한
• 장애·비용·SLA 주인공
• SWE 배경이 많음, Python/Scala/Java/Go

Analytics Engineer (AE)

• 데이터의 변환·모델링·의미부여 책임
• "raw.orders → marts.revenue_daily를 어떻게 신뢰 가능하게 만들 것인가?"
• dbt/SQLMesh로 SQL 모델링, 테스트, 문서
• 메트릭 정의, 시맨틱 레이어
• 애널리스트 배경이 많음, SQL 중심

한 줄 비유

"Data Engineer는 물길을 파고 펌프를 놓는다. Analytics Engineer는 그 물로 정수를 만들어 생수병에 담는다. Analyst는 그 물을 마시며 보고서를 쓴다."

왜 AE가 독립 직군이 됐나

2015년엔 DE가 파이프라인+변환을 다 했다. 그러나 dbt의 등장 이후, SQL만으로 변환 레이어를 소프트웨어처럼 운영할 수 있게 되며 "SQL을 잘 쓰는 사람이 전담"하는 AE가 가능해졌다. 2024-2025년엔 오히려 AE가 데이터 조직의 중추가 됐다. 비즈니스 도메인을 이해하면서도 코드 품질을 갖춘 희소 인력.

겸업 시 주의

스타트업(팀 1-3명)에선 DE·AE 구분이 무의미하다. 10-30명 규모 넘어가면 명확히 나누는 편이 좋다. 안 그러면 AE가 Spark 튜닝하다 하루 끝내거나, DE가 매일 LTV 정의 질문에 답하다 번아웃 온다.

3장 · ML Engineer vs AI Engineer — 2024년에 탄생한 직군

2023년까진 "ML Engineer"가 거의 모든 AI 업무를 담당했다. 2024년 이후 AI Engineer가 명확히 분화했다.

ML Engineer (전통)

• 데이터 → 모델 학습 → 배포 → 모니터링 파이프라인
• 대부분 자체 모델 학습 전제
• 피처스토어, AB 테스팅, 모델 레지스트리, 드리프트 감지
• 핵심 질문: "내 모델의 AUC/Recall을 얼마나 올릴까?"

AI Engineer (신생)

• 대개 기성 LLM API·오픈 모델을 조합해 제품을 만든다
• 프롬프트·RAG·Agent 워크플로·툴 사용
• 평가(Evaluation), 관측성(LangFuse 등), 비용·지연·안전장치
• 핵심 질문: "내 LLM 제품의 답변 품질을 얼마나 올릴까?"

차이가 실무에서 큰 이유

• ML Engineer는 학습 인프라(GPU 클러스터, Ray, Kubeflow)가 중요
• AI Engineer는 오케스트레이션(LangGraph, 평가, 로깅)이 중요
• 스킬셋이 40% 정도만 겹침

2025년 트렌드

• 큰 조직은 MLE와 AIE를 별도 트랙으로 운영 (OpenAI·Google 밖에서도)
• 스타트업은 "AI Engineer"가 훨씬 많이 뽑힌다 (자체 모델 학습 수요↓)
• ML Scientist / Research Scientist는 논문·연구 중심으로 또 분리

4장 · Data Platform Engineer — 가장 빠르게 성장한 직군

2024-2025년 가장 폭발적으로 커진 직군. 조직이 성숙할수록 "공통 데이터 플랫폼"이 필요하다는 인식이 퍼진 결과.

하는 일

• 내부 개발자 경험(DevEx) 관점에서 데이터 플랫폼 구축
• 셀프서비스 파이프라인 템플릿, CI/CD, 런타임 관리
• 컴퓨트 워크스페이스(예: Spark 클러스터, DuckDB 워커, Airflow/Dagster 호스팅)
• 권한·비용·관측성 공통 레이어
• SRE+DE+인프라 엔지니어의 교집합

왜 따로 필요한가

파이프라인이 100개 넘으면 각 도메인 팀이 본인 것을 "제대로" 운영하기 어렵다. 공통 기반을 주는 플랫폼 팀이 없으면 조직이 스파게티가 된다. 반대로 플랫폼 팀이 너무 두꺼우면 게이트키퍼가 된다. 균형이 핵심.

Platform Product Mindset

훌륭한 Platform Engineer는 본인을 "사내 SaaS 프로바이더"라 본다. 사용자(다른 엔지니어)가 있는 제품을 만든다는 관점. Backstage(Spotify), Unity Catalog 등은 이런 제품화 사고의 결과.

5장 · Central vs Embedded vs Hybrid vs Mesh — 4가지 조직 모델

데이터 팀을 어떻게 사내에 배치할 것인가? 2025년 현재 주류는 4가지.

(1) Central (중앙집중)

• 모든 데이터 인력이 한 중앙 팀에 있다
• 도메인 팀이 요청 → 중앙 팀이 처리
• 장점: 일관성·표준화·전문성 축적
• 단점: 병목, 도메인 이해 부족, "티켓 공장"화
• 어울리는 곳: 초기 스타트업 (3-15명), 소규모 조직

(2) Embedded (임베디드/분산)

• 데이터 인력이 각 도메인 팀에 파견되어 상주
• 중앙 팀은 없거나 최소화
• 장점: 도메인 몰입도·속도↑
• 단점: 표준·공통 플랫폼 부재, 역량 편차, 고립감
• 어울리는 곳: 도메인이 매우 강한 조직, 각 팀이 독립 P&L

(3) Hybrid (중앙+임베디드)

• 중앙 플랫폼·거버넌스·시맨틱 팀 + 도메인 임베디드 분석가/AE
• 중앙이 공통 기반·도구·교육, 임베디드가 도메인 밀착
• 장점: 양쪽 장점 취함
• 단점: R&R(역할과 책임) 명확화 필요
• 어울리는 곳: 대부분의 중규모(30-300명) 조직

(4) Data Mesh (도메인 소유)

• 각 도메인이 데이터 제품(Data Product)을 소유·운영
• 중앙은 공통 플랫폼·표준 제공자 역할
• 계약(Data Contract) 기반 도메인간 교환
• 장점: 확장성, 도메인 책임감
• 단점: 성숙도 높은 조직만 가능, 초기 도입 비용 크다
• 어울리는 곳: 매우 큰 조직(500명+), 독립 도메인 많음 (Netflix·JPMorgan·Zalando 등)

현실의 조합

대부분의 조직은 "Hybrid + 부분 Mesh" 형태로 진화한다. 처음부터 Mesh를 시도하면 실패하는 경우가 많다. 중앙 플랫폼과 거버넌스 기반이 없으면 Mesh는 혼돈일 뿐.

6장 · 스타트업 vs 대기업 — 팀 규모와 역할

초기 스타트업 (Seed-Series A, 10-50명)

• 데이터 인력: 0-2명
• 보통 "Full-stack Data Person": DE+AE+Analyst+DS 겸업
• ML/AI는 외부 API 중심
• 권장: Analytics Engineer 1명 + 엔지니어 SWE 중 SQL 잘하는 사람 조합

성장기 스타트업 (Series B-C, 50-300명)

• 데이터 인력: 3-15명
• 역할 분화 시작: DE 1-2, AE 2-3, DS 1-2, MLE 0-2, 리더 1
• 대개 Central → Hybrid로 전환 시점
• AI 제품 있으면 AI Engineer 1-3명 추가

후기 스타트업 (Series D+, 300-1500명)

• 데이터 인력: 20-100명
• Platform Engineer 전담 팀 필요
• 거버넌스·시맨틱 레이어·MLOps 전담팀
• Hybrid 혹은 부분 Mesh
• 리더십 3-4단계 (팀장 → 디렉터 → VP Data)

대기업·엔터프라이즈 (1500명+)

• 데이터·AI 인력: 수백 명 단위
• Central Platform + Embedded/Mesh 혼합
• CDO(Chief Data Officer) 조직, 거버넌스 자체가 큰 팀
• 사업부별 AI팀을 별도로 가지는 경우 많음 (보험·금융·커머스 등)

한국의 특수성

• 삼성·LG·SK·현대차 등: 대개 계열사 또는 사업부 내부 데이터팀
• 네이버·카카오·쿠팡: 미국식 Hybrid/Mesh 빠르게 수용
• 금융지주: 중앙집중 모델 많으나 AI 자회사(예: KB AI, 우리 FIS) 분리 추세
• 스타트업: 초기엔 "AI엔지니어" 채용이 DE보다 먼저 뜨는 경우 늘어남 (2024-)

7장 · 온콜·지식 공유 문화 — 기술보다 중요

도구·조직 모델보다 더 결과를 좌우하는 건 운영 문화다.

온콜(On-call) 문화

2024-2025년 데이터·AI 팀도 24/7 온콜 체계가 일반화됐다. 이유:

• 경영 대시보드가 24시간 돌아야 함 (글로벌 기업)
• 모델 서빙 장애는 제품 장애
• LLM API 비용 스파이크는 즉각 대응 필요

좋은 온콜 문화의 특징:

• 명확한 런북(Runbook) — 유형별 대응 절차
• 로테이션 — 한 사람에게 몰빵 금지 (번아웃)
• 사후 회고(Postmortem) 문화 — 비난 없는(blameless) 분석
• SLO·Error Budget 기반 (Ep 8 참고)
• 온콜 수당·휴가 보상

지식 공유 문화

• 주간 공유 세션: 팀 내부 기술 공유
• Decision Log: 중요 결정의 맥락 남기기
• Pair work·Shadow: 신입/경력자 온보딩
• Open Source 기여: dbt, Airflow 등에 기여하며 성장

반(反)패턴

• "영웅적 개인"에 의존 — 그 사람 퇴사하면 무너짐
• "말로만 공유하자" — 문서 없음
• "Blamy post-mortem" — 원인보다 누가 잘못인지 따짐
• "온콜은 DE만" — 모델 장애도 DE가 해결하게 강제

8장 · 리더십 경로 — Manager vs Individual Contributor

데이터 커리어에서 가장 흔한 오해: "시니어 = 팀장".

Two Track 시스템

현대 테크 조직은 대부분 Two Track(병렬 트랙) 을 운영한다.

Manager Track

• Team Lead → Engineering Manager → Director → VP
• 사람·예산·전략 책임
• "팀의 성공이 나의 성공"
• 한국 전통 대기업은 이 길이 유일한 경우 많음

IC (Individual Contributor) Track

• Senior Engineer → Staff → Principal → Distinguished → Fellow
• 기술·영향력·시스템 설계 책임
• "내 전문성의 영향력"
• Staff/Principal급은 팀장보다 연봉 높은 경우 많음 (글로벌 빅테크)

선택 기준

사람이 좋아서, 사람으로 문제를 풀고 싶으면 → Manager. 기술이 좋아서, 시스템으로 문제를 풀고 싶으면 → IC.

양쪽 다 리더십이 필요하다. IC도 Staff급이면 기술 리더십(주니어 멘토링, 방향성 제시, 크로스팀 영향)이 필수.

한국 특수성

• 국내는 여전히 Manager Track만 존재하는 회사 많음
• 토스·라인·쿠팡 등은 IC Track 도입
• IC로 성장하려면 회사 선택이 중요 (Staff급 자리가 있는가?)

9장 · 원격·하이브리드·국내 특수성

글로벌 원격 트렌드

• 2020 팬데믹 이후 완전 원격 보편화 → 2023-2024 회귀 (빅테크 사무실 복귀)
• 2025년 기준: 하이브리드가 표준, 풀리모트는 일부 회사
• 데이터·AI 직군은 원격 친화적 (협업 비동기 가능)

해외 회사 원격 채용

• 한국 인재 해외 원격 채용 케이스 증가: Amazon·Google·Meta·스타트업들
• 연봉 차이 크지만 세금·의료·시차 이슈
• 가장 큰 허들: 영어 커뮤니케이션·비동기 문서 문화

국내 특수성

• 많은 국내 기업은 데이터 출근 의무 (보안·규제 이유)
• 금융·공공: 망분리 때문에 원격 어려움
• 스타트업: 완전 원격 비율 아직 낮음 (15-25%)
• 판교/강남 오피스 밀집도 여전

시차·해외 협업 노하우

• 비동기 우선(Async-first): 회의보다 문서·ADR
• 오버랩 시간 확보: 한국 9-11시 = 미국 서부 전날 16-18시
• Single Source of Truth: Notion/Confluence 한 곳에 정리

10장 · 연봉·보상 체계 2025

가장 민감하지만 필수인 주제.

한국 시장 연봉 (2025년 4월 기준, 중앙값 추정)

• 대기업 연봉 + 성과급·스톡옵션 포함 총보상(TC) 기준
• 네이버·카카오·쿠팡·토스는 상단 20-30% 더 높음
• 외국계(Google·Meta·AWS 한국 등)는 상단 50-100% 더 높을 수 있음
• AIE가 2024년 이후 가장 빠르게 상승

해외(미국 빅테크, 원격/현지)

• L4 (Mid): USD 200-300k TC
• L5 (Senior): USD 350-550k TC
• L6 (Staff): USD 550-800k+ TC
• 환율·세금 감안해도 한국 대비 2-4배

보상의 구성요소

• Base: 기본 연봉
• Bonus: 연말 성과급 (보통 연봉의 10-20%)
• Equity/RSU: 주식 (스타트업은 스톡옵션, 상장사는 RSU)
• Signing: 사이닝 보너스 (이직 시 1회성)

연봉 협상 팁

• 여러 오퍼 동시 진행
• Base + Equity + Bonus 분리해 비교
• 첫 오퍼에서 바로 수락 금지 (항상 카운터 존재)
• 경쟁 오퍼 없어도 시장 데이터로 근거 제시 (levels.fyi, 잡플래닛 등)

11장 · 채용·면접 트렌드 2025

2025년 면접 구성 (데이터·AI 공통)

1. 스크리닝(HR): 30분, 이력·동기
2. 테크니컬 스크리닝: 60-90분
   • DE/AE: SQL 라이브코딩 + 파이프라인 설계
   • MLE/AIE: 머신러닝/LLM 개념 + 코딩
3. 온사이트(온라인 4-6시간):
   • 시스템 디자인 (데이터 아키텍처)
   • 알고리즘 코딩 1-2개
   • 케이스 분석 (애널리스트)
   • 행동 면접(Behavioral)
4. 최종 매니저 인터뷰

2025년 특히 중요해진 질문

• "LLM을 활용해 이 문제를 어떻게 풀겠는가?" — DE/AE 직군에도 나옴
• "데이터 품질이 의심될 때 어떻게 조사하나?" — 실무 디버깅
• "비즈니스 메트릭을 어떻게 정의하고 배포하겠나?" — 시맨틱 레이어 이해
• "이 Feature를 프로덕션에 안전히 내보내려면?" — CI/CD·테스트
• "AI 에이전트의 안전장치는?" — AI 안전·평가

AI 면접의 등장

• 일부 기업은 Hackerrank·CodeSignal + AI 평가 도입
• "GPT로 답하면 검출한다" 체제 논쟁 중
• 원격 면접 치팅 방지 기술 확산 (Proctor AI)

한국 특수 면접

• 인적성 검사 (삼성·SK 등)
• 임원 면접 (국내 대기업)
• "왜 우리 회사?" 질문의 무게 높음

12장 · 학습·커리어 전략 2025

주니어(0-3년)에게

• 도메인 전문성 하나 깊게 (커머스·금융·콘텐츠 등)
• SQL + Python 수준급으로
• 한 개 클라우드(AWS/GCP/Azure) 실전 경험
• 오픈소스 기여 1-2개 (작은 패치도 OK)
• AI 리터러시: 자기 일에 LLM을 어떻게 쓰는지

미드(3-7년)에게

• T자형 기술: 한 분야 깊게 + 인접 분야 넓게
• 제품 사고: 단순 파이프라인이 아니라 데이터 제품을 만들 줄 알아야
• 영어: 문서·발표·원격 협업
• 블로그/발표: 업계 네트워크 구축

시니어(7년+)에게

• 선택지 점검: Manager vs IC 트랙 중 본인 성향
• 시스템 디자인 역량: 조직·기술 양쪽
• 멘토링·지식 공유를 업무의 일부로
• 경제·시장·비즈니스 감각 키우기 (숫자를 넘어 회사 전체)

AI 시대의 데이터 커리어

• LLM은 SQL 작성·대시보드 생성은 잘함 → 초급 애널리스트 업무 일부 대체
• 그러나 문제 정의·데이터 품질 판단·비즈니스 맥락·윤리적 판단은 인간 고유
• 2025년 이후 데이터 커리어는:
  • AI와 협업해 생산성 10배 올리는 사람
  • vs AI에 대체되는 반복 업무만 하는 사람
  • 그 격차가 더 커질 것

학습 리소스 추천

• Book: 《Designing Data-Intensive Applications》, 《Fundamentals of Data Engineering》, 《Building Machine Learning Powered Applications》
• Course: dbt Learn, Coursera Deep Learning Specialization, Fast.ai, DeepLearning.AI LLM specialization
• Blog/Newsletter: Benn Stancil, Chip Huyen, Eugene Yan, Seattle Data Guy, 국내는 우아한형제들·카카오 기술블로그
• Community: Locally Optimistic, dbt Community, MLOps Community Slack, 국내는 GDG·각종 밋업

13장 · 실전 — 팀 설계 5가지 레시피

레시피 1: Seed-Series A 스타트업 (20명, 데이터 0명)

• 첫 채용: Analytics Engineer 1명 (겸 DE)
• 도구: Snowflake(or BigQuery) + dbt + Metabase
• 목표: KPI 대시보드 3개, 실험 분석 기반
• 6개월 후: Data Scientist 1명 추가 검토

레시피 2: Series B 스타트업 (100명, 데이터 2명)

• 추가 채용: Data Engineer 1, Analytics Engineer 1 (→총 4명)
• Central 모델, 전담 리더 1명
• 도구: Airflow/Dagster + dbt + Metabase/Looker + Monte Carlo
• 6개월 후: 온콜 체계 정립, 거버넌스 기초

레시피 3: Series C (300명, 데이터 10명)

• Hybrid 전환: 중앙 4-5명 + 도메인 임베디드 3-4명
• 신규: Data Platform Engineer 1명, MLE/AIE 1명
• 도구: Snowflake/Databricks + dbt + Dagster + DataHub + LangFuse (LLM 쓰면)

레시피 4: 대기업 AI TF (50명 규모 신설)

• AI Engineer 10 + MLE 10 + DE 10 + Platform 5 + DS 10 + PM/Design 5
• 기존 중앙 데이터팀과 분리 운영 → 1년 뒤 Mesh화 검토
• 도구: 회사 인프라 + 전용 LLM/Vector DB + 별도 배포 파이프라인

레시피 5: 금융지주 중앙 데이터조직 (200명)

• Central + 사업부별 Embedded
• 거버넌스·개인정보·감사 별도 팀 (20-30명)
• 망분리 환경: on-prem LLM, 자체 Vector DB
• Mesh는 5-7년 로드맵

14장 · 안티패턴 10

1. 도구부터 사고 사람은 나중: Snowflake만 있고 AE 없는 조직 = 비싼 SQL 편집기.
2. 영웅 한 명에 의존: "그 분만 아는" 파이프라인. 퇴사 = 재앙.
3. 엔지니어링 조직에 데이터팀 매몰: 지표보다 "피처 만들기" 우선시. 데이터 팀이 성장 안 함.
4. Mesh를 준비 없이 도입: 중앙 플랫폼 부재에서 각 팀이 알아서 = 혼돈의 데이터 생태계.
5. DE에게 모든 걸 맡김: AE·Platform·Governance 책임까지 DE 한 사람에게.
6. 온콜 수당·로테이션 무: 번아웃 → 퇴사 → 지식 소실 악순환.
7. Blamy Postmortem: 누가 잘못인지 찾는 문화. 숨기기·변명 문화 정착.
8. Manager Track만 존재: 기술 뾰족한 사람이 팀장 되어 비효율 + 이탈.
9. "AI는 데이터팀이": AI 제품이 데이터팀에 내던져짐. 제품 맥락 없이 품질 저하.
10. 연봉 비공개·밴드 부재: 지원자·내부자 모두 협상에서 불리. 공정성 논란.

15장 · 다음 글 예고 — Season 5 Ep 10: "데이터 문화와 전사 확산"

팀을 구성했다면 다음은 문화와 조직 전체의 데이터화. Ep 10은 데이터 문화와 전사 확산 전략.

• Data-Informed vs Data-Driven의 차이
• 임원·비즈니스 사이드의 데이터 리터러시 어떻게 키우나
• 실험 문화 정착 (A/B·MAB·Quasi-experiment)
• KPI·OKR·North Star Metric 설계
• 의사결정 문화와 ADR
• Self-Service BI의 명암
• Finance와 데이터팀의 관계 (예산 싸움)
• 데이터 민주화 vs 거버넌스 균형
• 한국 기업의 "데이터로 일하기" 도입 실패 패턴
• 데이터 CEO·CDO의 역할

"도구가 조직을 바꾸지 않는다. 사람이 바꾼다."

다음 글에서 만나자.

에필로그 · 체크리스트 12

조직·팀을 점검할 때 12가지 질문.

1. 우리 팀 각 사람의 역할(DE/AE/DS/MLE/AIE/Platform)이 명확한가?
2. DE와 AE의 책임 경계가 문서화되어 있는가?
3. 조직 모델(Central/Embedded/Hybrid/Mesh)이 팀 규모에 적합한가?
4. 온콜 체계·런북·로테이션이 운영되고 있는가?
5. Blameless Postmortem 문화가 정착되어 있는가?
6. Manager/IC 두 트랙이 존재하고 기대치가 명확한가?
7. 보상 밴드가 투명하고 시장 수준에 맞는가?
8. 원격·하이브리드 정책이 합리적인가?
9. 주니어 성장 경로 (멘토·교육·프로젝트)가 설계되어 있는가?
10. 시니어가 IC 영향력을 발휘할 수 있는 구조인가?
11. AI·LLM 시대 대비 학습·실험 시간이 허용되는가?
12. 채용 파이프라인이 다양성·공정성을 실질적으로 반영하는가?

"도구가 아니라 팀이 데이터 조직의 운명을 결정한다."

— Season 5 Ep 9, Fin.