Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 데이터 엔지니어링의 새로운 패러다임을 제시하며, 단순한 물리적 테이블이나 파이프라인 대신 '데이터 자산'을 계약(Contract) 형태로 정의할 것을 제안합니다. 이 자기 조직화 스택은 소비자가 필요한 결과와 보장 조건을 명시하면, 엔진이 내부 구현 변경에 관계없이 일관된 결과를 제공하는 것이 핵심입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기사람은 데이터의 의미와 정책을 정하고, 엔진은 테이블과 파이프라인을 구성하고 재편하는 차세대 데이터 스택 제안. AI로 새 파이프라인을 쉽게 만드는 만큼 중복과 관리 부담도 커지는 문제에서 출발
customer_spend, 리팩터링하기 두려운 수천 개 모델, 삭제하지 못하는 페타바이트 규모의 좀비 테이블이 쌓임
기존 오케스트레이션 모델을 그대로 둔 채
코딩 에이전트만 도입하면 새 파이프라인 생성 비용은 거의 사라지지만 기존 파이프라인 수정 위험은 여전히 높음
개별 프롬프트에는 최적화됐지만 웨어하우스 전체의 혼란을 키우는 저품질 파이프라인이 늘어남
정적 스타 스키마와 공통 차원은 사람이 데이터를 탐색하고 질문에 답할 수 있도록 설계돼 왔음
지능을 IDE에서
런타임으로 옮기고 에이전트가 데이터를 소비해 답을 만든다면, 물리적 모델을 사람의 이해에 맞춰 고정할 필요가 줄어듦
의존성 그래프는 사람이 입력하는 고정 구조가 아니라 재사용, 비용, 정확성을 고려해 엔진이 유지하는 동적 산출물이 됨
정의, 정책, 판단의 소유권은 여전히 사람에게 남음
Steven Strogatz의
Sync가 다루는 반딧불이의 동시 발광과 심박 조율 세포의 동기화처럼, 개별 요소가 취약해도 중앙 지휘자 없이 전체 질서가 생길 수 있음
자기 조직화 스택의
데이터 자산은 안정적인 식별자를 가진 지속적인 논리적 데이터 제품임
의미, 데이터의 행 단위인 그레인, 각 하위 소비자에게 보장할 계약을 선언함
자산 자체가 행동하거나 독자적인 백그라운드 LLM 프로세스를 실행하지 않음
오케스트레이션 엔진은
다섯 가지 핵심 루프로 그래프를 조정함
합성(Synthesize): 새 요청에 필요한 물리적 테이블과 변환을 구성함
통합(Consolidate): 겹치는 명세를 찾아 작업의 공유, 분리, 병합을 제안함
검증 및 복구(Verify and Repair): 모든 그래프 변경과 장애 복구를 하위 소비자 계약에 대조해 검사함
조정(Coordinate): 활성 소비자 계약을 깨뜨리지 않도록 버전이 있는 변경을 원자적으로 활성화함
상위 판단 요청(Escalate): 의미의 모호함이 진행을 막으면 근거와 절충안을 붙여 담당자에게 구체적인 질문 하나를 전달함
자산의 정체성과 물리적 구현을 분리하는 것이 핵심임
customer_spend_30d요청은 테이블, 조인 키, cron 대신 결과와 보장 조건만 명시함
UTC 기준 직전 30개의 완결된 달력 날짜에 대한 고객별 지출을 반환함
승인된 구매 금액과 고객 식별 정의를 사용하고, 해당 구매가 없는 고객도 포함함
새로 이용 가능한 원천 데이터를 5분 안에 반영하고, 영업 애플리케이션이 의존하는 동안 자산을 유지함
엔진은
시맨틱 계층의 공인 원천, 엔터티 키, 단위, 승인된 계산식, 시간 규칙으로 의도를 해석함
그럴듯한 컬럼명 추측을 비즈니스 정의로 취급하지 않으며, 의미 정의가 없으면 SQL로 추측하는 대신 질문을 올림
계획기는 의도를
공식 명세와 테스트로 변환함
고객당 한 행이라는 조건은 유일성 검사로 연결됨
지출이 없는 고객을 포함하려면 고객 레지스트리와 외부 조인이 필요함
승인된 구매 금액 정의는 원시 원장과의 대사 규칙을 제공함
첫 소비자에게는 원시 구매 데이터를 직접 변환하는 방식이 5분 SLA를 저렴하게 충족하므로 단순한 직접 파이프라인을 만듦
이후 지원 에이전트가
UTC 기준 완결된 90일의 동일 지표를 요청하면, 계획기는 두 자산의 USD 구매 정의, 고객 식별 규칙, 날짜 경계가 같은지 확인함
현재 시각까지의 초 단위 이동 구간이라면 같은 일별 집계를 공유할 수 없음
조건이 맞으면 90일 이력을 가진
customer_spend_daily
중간 자산을 제안함
원천 이력과 접근 정책을 확인하고 일별 집계를 백필한 뒤, 새 90일 자산과 기존 30일 자산을 이 중간 집계에 연결함
두 번째 요청이 최적 아키텍처를 바꾸지만,
기존 영업 애플리케이션의 계약은 유지됨
사람이 할 수 있는 리팩터링을 엔진이 직접 수행하는 것이 핵심임
기존 기술에도 일부 토대가 있음
Kubernetes는 원하는 상태와 실제 상태를 맞추는 조정 루프를 대중화함
자산 중심 오케스트레이터는 작업 스케줄에서 데이터 자산으로 사고의 중심을 옮김
웨어하우스의 동적 테이블과 구체화 뷰는 증분 갱신을 자동화함
이 도구들은 여전히 사람이 그래프를 작성하도록 요구하지만, 자기 조직화 스택은
그래프 작성 자체를 엔진으로 옮김
런타임은 두 상태를 버전별로 유지함
목표 상태(Desired State) 는 소비자가 계약한 결과와 SLA임
관측 상태(Observed State) 는 실제 구현, 계보, 워터마크, 상태 정보임
새 요청, 검사 실패, 계약 만료가 두 상태 사이에 차이를 만들면 엔진이 그래프 변경을 제안함
LLM은 의도 해석과 SQL 후보 작성에 도움을 줄 수 있지만,
모델의 확신은 변경 승인 근거가 아님
후보는 결정론적 계획기, 타입 검사, 접근 통제, 비용 통제, 독립 검증의 제약을 받아야 함
스케줄도 이 판단에서 파생됨
일별 집계는 원천 워터마크가 전진하면 실행되고, 기간별 뷰는 UTC 자정에 구간을 이동함
DAG는 영속적인 진실의 원천이 아니라 개별 변경을 위한
일회성 실행 계획이 됨
지속해서 남는 것은 자산, 계약, 결정임
account_id만으로 조인하면 이력이 두 개인 계정의 구매가 중복 계산될 수 있음
스키마 검사, null 검사, 집계 후 기본 키 유일성 검사는 모두 통과해도 총액은 틀릴 수 있음
검증 대상은 문법적 형태뿐 아니라
의미적 불변 조건이어야 함
승인된 구매 정의와 대사하면 중복 매출을 발견하고 원인을 새 일별 의존성까지 추적할 수 있음
유효 기간을 반영하도록 조인을 고친 뒤, 동일한 입력 스냅샷에서 기존 구현과 새 구현을 비교하고 비즈니스 불변 조건을 독립적으로 검사함
계산과 테스트를 모두 작성한 LLM이 자기 가정을 스스로 인증해서는 안 됨
검증 후 활성화에는
동시성 통제가 필요함
테스트 중 새 소비자가 30일 자산의 의존성을 등록했다면 기존 검증 근거는 더 이상 최신이 아님
조정기는 트랜잭션 레지스트리의 엄격한 리비전 번호에 활성화를 연결하고, 자산을 준비한 뒤 계약 변경 여부를 확인해 활성 포인터를 원자적으로 전환함
저장 백엔드가 나뉘어 있다면 블루/그린 이전을 조정함
결함이 검증을 통과했다면 복구 기록은
노출 기간에 잘못된 데이터를 읽은 모든 하위 소비자를 식별해야 함
테이블을 롤백해도 에이전트가 이미 수행한 행동은 되돌릴 수 없음
시스템을 이해하는 출발점은 스키마보다
의사결정 기록이 됨
세 번째 소비자가 90일 가구별 지출을 요청했는데 승인된 가구 정의가 거주지 기준과 연결된 청구 계정 기준으로 나뉜다면, 엔진은 추측하지 않음
각 정의의 고객 묶음, 재사용 가능한 자산, 비용을 보여주고 도메인 담당자에게 선택을 요청함
사람이 의미를 선택하면 엔진은 그 결정을 권한이 있는 도메인 범위에 적용하고 그래프를 도출함
모든 명확화, 명세, 제안, 검증 보고서, 배포는
불변 의사결정 로그로 연결됨
활성 자산의 요구사항마다 원인이 된 결정, 정책, 메시지를 추적할 수 있음
household_spend_90d
예시는 가구 정의를 semantic:primary_residence_household@2
와 결정 decision:d17
에, 지출 정의를 승인된 정책에, UTC 기준 90일 조건을 요청 메시지에 연결함
W3C PROV와 OpenLineage 같은 표준에 기반한 기록은 스타 스키마가 맡았던 이해의 역할을 대신함
장애 대응은 실패한 작업이 아니라
깨진 계약에서 시작함
운영 콘솔은 어떤 계약이 미충족인지, 어떤 소비자가 영향을 받는지, 어떤 최근 그래프 변경이 관련되는지, 엔진이 어떤 복구를 테스트 중인지 순서대로 보여줘야 함
운영자에게는
자율 동작을 멈출 수단이 필요함
도메인 전체의 재구성을 동결하거나, 자산을 정상 동작이 확인된 버전에 고정하거나, 과거 입력으로 변경 제안을 재실행할 수 있어야 함
자기 조직화 스택은 자산을 만들기만 하지 않고
사용이 끝난 자산을 정리함
영업 애플리케이션이 30일 지출 구독을 해제하면
customer_spend_30d
를 종료하되 90일 지원 자산은 유지함
분기 말에만 실행되는 재무 작업이 있을 수 있으므로 단순 쿼리 로그만으로 사용 여부를 판단하지 않음
정리 여부는
명시적인 계약 만료, 규정상 보존 정책, 재구성 비용을 함께 고려함
물리적 테이블을 가상 뷰로 바꾸거나, 이력을 보존한 채 연산을 중단하거나, 마지막 공유 소비자가 사라진 중간 테이블을 제거할 수 있음
이 설계는 데이터 엔지니어를 없애는 것이 아니라
엔지니어가 작성하는 대상을 바꿈
요구를 취약한 DAG로 번역하는 대신 런타임이 따라야 할 경계와 규칙을 설계함
오케스트레이터를 한 번에 교체할 필요는 없음
현실적인 중간 단계는 기존 데이터 파이프라인 옆에
맥락 파이프라인(Context Pipeline) 을 구축하는 것임
플랫폼과 오케스트레이션 엔진 구축은
네 가지 우선순위에서 시작할 수 있음
소비자 계약을 독립적인 핵심 요소로 관리하고, 누가 자산에 의존하며 무엇을 보장받았는지 SQL과 분리해 기록함
계획기보다 시맨틱 계층에 먼저 투자해 공식 정의로 동등성을 증명할 수 있게 함
승인된 정의에 맞춰 출력을 독립적으로 확인하고 근거의 품질을 평가하는 반증 중심 검증을 구축하며, 에이전트가 자기 작업을 채점하지 못하게 함
사람의 모든 명확화 결정을 권한, 적용 범위, 영향을 받은 자산과 함께 데이터로 보존함
지향하는 구조에서는 새 요청이 그래프를 만들고, 중복이 그래프를 재편하고, 계약 미충족이 복구를 촉발하며, 계약 만료가 그래프를 단순화함
사람은 의미를 작성하고, 엔진은 그래프를 작성함