자기 조직화 데이터 스택 - 요구에 맞춰 데이터 파이프라인을 재구성하는 설계

사람은 데이터의 의미와 정책을 정하고, 엔진은 테이블과 파이프라인을 구성하고 재편하는 차세대 데이터 스택 제안. AI로 새 파이프라인을 쉽게 만드는 만큼 중복과 관리 부담도 커지는 문제에서 출발 소비자는 테이블이나 실행 순서 대신 필요한 결과와 갱신 주기 등의 보장 조건을 명시. 내부 구현을 바꿔도 기존 애플리케이션이 받는 결과와 조건은 유지하는 구조 예를 들어 고객별 30일 지출과 90일 지출 요청이 들어오면 공통 일별 집계를 만들어 공유. 단, 통화와 고객 정의, 날짜 기준이 같아야 하며 비용과 장애 영향까지 고려해야 함 SQL이 실행되고 스키마 검사를 통과해도 값은 틀릴 수 있음. 승인된 비즈니스 정의로 결과를 독립 검증하고, 의미가 모호하면 추측하지 않고 담당자에게 질문 전환은 기존 파이프라인 옆에 데이터 정의와 의사결정을 추출하고 버전 관리하는 ‘맥락 파이프라인’ 을 만드는 데서 시작. 엔지니어의 중심 업무는 실행 순서 작성에서 의미와 보장 조건, 검증 규칙 설계로 이동 수작업 DAG와 AI가 키우는 데이터 난립 데이터 엔지니어는 데이터 모델링과 스케줄, 의존성, 재시도, 백필을 연결하는 오케스트레이션 작업을 함께 수행함 새로운 요구가 생기면 기존 DAG의 문서화되지 않은 가정을 역추적하고 하위 시스템을 의도치 않게 망가뜨릴 위험을 감수하기보다 SQL을 복사해 새 테이블을 만들기 쉬움 이런 선택이 수백 명의 엔지니어와 수년에 걸쳐 반복되면 중복된 customer_spend, 리팩터링하기 두려운 수천 개 모델, 삭제하지 못하는 페타바이트 규모의 좀비 테이블이 쌓임 기존 오케스트레이션 모델을 그대로 둔 채 코딩 에이전트만 도입하면 새 파이프라인 생성 비용은 거의 사라지지만 기존 파이프라인 수정 위험은 여전히 높음 개별 프롬프트에는 최적화됐지만 웨어하우스 전체의 혼란을 키우는 저품질 파이프라인이 늘어남 정적 스타 스키마와 공통 차원은 사람이 데이터를 탐색하고 질문에 답할 수 있도록 설계돼 왔음 지능을 IDE에서 런타임으로 옮기고 에이전트가 데이터를 소비해 답을 만든다면, 물리적 모델을 사람의 이해에 맞춰 고정할 필요가 줄어듦 의존성 그래프는 사람이 입력하는 고정 구조가 아니라 재사용, 비용, 정확성을 고려해 엔진이 유지하는 동적 산출물이 됨 정의, 정책, 판단의 소유권은 여전히 사람에게 남음 자산은 테이블이 아니라 계약임 Steven Strogatz의 Sync가 다루는 반딧불이의 동시 발광과 심박 조율 세포...