Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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 직군 지도

| 직군 | 주 업무 | 주 스택 |

|---|---|---|

| **Data Engineer (DE)** | 파이프라인·인프라·스토리지, 데이터 플랫폼 운영 | Spark, Flink, Kafka, Airflow, Iceberg, Snowflake/BigQuery |

| **Analytics Engineer (AE)** | 원시 데이터 → 신뢰 가능한 테이블·메트릭, dbt 모델링 | dbt, SQLMesh, SQL, 시맨틱 레이어 |

| **Data Analyst** | 비즈니스 질문 답변, 대시보드, 실험 분석 | SQL, Looker/Tableau/Mode, 통계 |

| **Data Scientist (DS)** | 통계·실험·ML 모델링, 비즈니스 인사이트 | Python, scikit-learn, causal inference, 실험 플랫폼 |

| **ML Engineer (MLE)** | ML 모델 프로덕션화, 피처스토어·서빙 | Kubeflow, Ray, Feast, Triton, MLflow |

| **AI Engineer (AIE)** | LLM 앱·에이전트·RAG, 프롬프트/평가 | LangGraph, LlamaIndex, LangFuse, pgvector |

| **Data Platform Engineer** | 내부 데이터 플랫폼·Self-Serve·DevEx | Terraform, Kubernetes, Backstage, 런타임 관리 |

| **Data Governance/Steward** | 메타데이터·리니지·PII·컴플라이언스 | DataHub/Collibra/Atlan, OpenLineage |

| **Data Product Manager** | 데이터 제품화, 로드맵, 도메인 접점 | PM 스택 + 데이터 이해 |

| **Analytics Lead / Head of Data** | 조직·전략·비즈니스 임팩트 | 리더십 |

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월 기준, 중앙값 추정)

| 레벨 | DE | AE | DS | MLE/AIE | Platform |

|---|---|---|---|---|---|

| Junior (0-3y) | 5500-7500만 | 5500-7500만 | 6000-8000만 | 6500-9000만 | 6500-9000만 |

| Mid (3-7y) | 8000-1.2억 | 7500-1.1억 | 8500-1.3억 | 9000-1.5억 | 9500-1.5억 |

| Senior (7-12y) | 1.2-1.8억 | 1.1-1.7억 | 1.3-2억 | 1.5-2.3억 | 1.5-2.3억 |

| Staff/Lead (12y+) | 1.8-3억 | 1.8-2.8억 | 2-3.2억 | 2.3-4억 | 2.3-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.