자기 조직화 데이터 스택

오늘날 데이터 엔지니어는 두 가지 일을 한다. 어떤 테이블이 존재해야 하는지 결정하고(데이터 모델링), 최신 상태를 유지하도록 스케줄, 의존성, 재시도, 백필을 오케스트레이션 엔진에 수작업으로 연결한다. 한 달 뒤 약간 다른 질문을 담은 새로운 비즈니스 요구사항이 도착하면, 엔지니어는 선택에 직면한다. 다른 사람이 만든 취약한 DAG를 역설계하는 데 사흘을 쓰며 문서화되지 않은 가정을 파악하고 하류에서 조용히 문제가 발생할 위험을 감수할 것인가, 아니면 SQL을 복사해 새 테이블을 만들 것인가.

합리적인 엔지니어라면 누구나 새 테이블을 선택한다. 이런 생존 본능을 200명의 엔지니어와 3년이라는 시간에 걸쳐 곱하면 현대 데이터 웨어하우스가 된다. 엔트로피가 높은 난립 상태다. customer_spend의 수십 가지 버전, 아무도 감히 리팩터링하지 못하는 수천 개의 모델, 아무도 감히 삭제하지 못하는 페타바이트 규모의 좀비 테이블이 생긴다.

지금까지 AI는 이 불에 기름만 부었다. 근본 오케스트레이션 모델은 바꾸지 않은 채 엔지니어에게 코딩 에이전트를 제공함으로써, 새 파이프라인 생성 비용은 거의 0으로 낮춘 반면 기존 파이프라인을 리팩터링하는 위험은 여전히 극도로 높게 남겨 두었다. 그 결과 단일 프롬프트에 맞춰 국소적으로 최적화하면서 전역 웨어하우스 혼란을 가속하는 AI 생성 ‘잡동사니 파이프라인’이 폭증했다.

데이터 모델링은 인간 소비자를 위한 인간 활동이었기에 수작업 난립을 용인했다. 분석가가 다른 사람의 질문에 답할 수 있을 만큼 웨어하우스를 탐색하도록, 정적인 스타 스키마와 공통 차원을 설계한다. 가독성이 모델의 존재 이유 전체다.

지능을 IDE 밖에서 런타임으로 옮긴다면 에이전트는 이 가정을 무너뜨린다. AI 에이전트가 데이터를 소비하고 답을 생산할 때, 물리 모델은 더 이상 인간의 이해를 위한 박물관 전시물처럼 구성되거나 인간의 손으로 유지될 필요가 없다. 의존성 그래프는 엔지니어가 그리는 경직된 입력이 아니라, 소비자 요구가 변함에 따라 재사용성, 비용, 정확성을 최적화하며 오케스트레이션 엔진이 유지하는 동적 출력이 된다.

인간에게 남는 것은 의미다. 사람은 여전히 시스템이 준수해야 할 정의, 정책, 판단을 소유한다. 나는 이 설계를 자기 조직화 데이터 스택이라 부른다.

어떤 살아 있는 시스템을 자세히 보면 역설이 눈에 띈다. 개별 부분은 취약하지만 전체는 깊이 조직되어 있다. 수학자 Steven Strogatz는 그의 고전 저서 _Sync_에서 우주가 어떻게 이 묘기를 부리는지, 즉 중앙 지휘자 없이 혼돈에서 어떻게 질서가 출현하는지 묻는다. 강둑을 따라 있는 수천 마리 반딧불이는 어떻게 완벽하게 동시에 빛나기 시작할까? 개별 심박 조율 세포는 어떻게 동기화되어 일정한 심장 박동을 만들어 낼까?

중앙의 인간 안무가를 출현하는 질서로 대체하려면, 데이터 자산이 무엇인지 바꿔야 한다. 자기 조직화 스택에서 자산은 스토리지에 놓인 물리 테이블이 아니다. 안정적인 정체성을 가진 영속적이고 논리적인 데이터 제품이다. 자산은 자신의 의미론적 의미, 그레인, 그리고 각 하류 소비자에 대한 약속을 선언한다.

자산은 행동하거나 멋대로 백그라운드 LLM 프로세스를 실행하지 않는다. 단지 경계를 선언하고, 오케스트레이션 엔진은 다섯 가지 핵심 루프를 통해 그래프를 조정한다.

• 합성: 새 요청에 필요한 물리 테이블과 변환을 구축한다.

• 통합: 겹치는 명세를 감지하고, 기반 작업의 공유, 분할 또는 병합을 제안한다.

• 검증 및 복구: 배포 전에 모든 그래프 변경 또는 장애 복구를 하류 계약에 대해 테스트한다.

• 조정: 활성 소비자 약속이 깨지지 않도록 버전이 지정된 변경을 원자적으로 활성화한다.

• 에스컬레이션: 의미론적 모호성이 진행을 막을 때마다 근거와 절충안을 갖춘 하나의 구체적인 질문을 인간 소유자에게 제시한다.

다섯 루프 모두를 가능하게 하는 하나의 아키텍처 분리가 있다. 자산은 물리 구현이 바뀌어도 정체성을 유지한다. 계약은 자산에 속하고, 엔진은 물리적 장치를 소유한다. 이 분리를 통해 플랫폼은 어떤 하류 소비자도 통합 방식을 다시 작성하게 하지 않고 웨어하우스를 지속적으로 재배선할 수 있다.

실제로 어떻게 작동하는지 보자. 영업 애플리케이션에는 각 고객의 지난 30일간 지출이 필요하다. 사람이 입력하든 에이전트가 API를 통해 보내든, 요청은 결과와 약속만 명시한다.

customer_spend_30d를 생성하라. UTC 기준 이전의 완전한 달력일 30일 동안 각 고객의 지출을 고객당 한 행으로 반환하라. 승인된 구매 금액 및 고객 식별 정의를 사용하라. 조건에 맞는 구매가 없는 고객도 포함하라. 새로 이용 가능한 소스 데이터를 5분 안에 반영하라. 영업 애플리케이션이 이 자산에 의존하는 동안 이 자산을 유지하라. customer_spend_30d

테이블, 조인 키, cron 스케줄에 대한 언급은 없다. 환각 없이 이 의도를 해석하기 위해 엔진은 의미 계층에 의존한다. 즉, 권위 있는 소스, 엔터티 키, 단위, 승인된 계산, 시간 규칙이다. 이것이 설계의 하중을 지탱하는 벽이다. 시스템은 열 이름에 관한 그럴듯한 추측을 비즈니스 정의로 바꿀 수 없다. 의미가 빠져 있으면 SQL에서 추측하는 대신 미결 질문을 에스컬레이션한다.

의미 계층에서 플래너는 정형 명세를 컴파일하고 자체 테스트를 자동으로 도출한다. _고객당 한 행_은 유일성을 강제하고, _지출이 0인 고객 포함_은 고객 레지스트리와의 외부 조인을 요구하며, _승인된 구매 금액_은 원시 원장에 대한 조정 규칙을 제공한다. 원시 구매 데이터에 대한 직접 변환은 이 첫 소비자에게 5분 SLA 내에서 저렴하게 제공되므로, 엔진은 단순하고 직접적인 파이프라인을 구축한다.

그렇다면 한 달 후 지원 에이전트가 동일한 지표를 완전한 UTC 기준 90일에 대해 요청하면 어떻게 될까?

오늘날의 스택에서는 코딩 코파일럿이 기꺼이 원시 구매 데이터를 다시 스캔하는 중복 파이프라인을 만들어 낸다. 자기 조직화 스택에서는 플래너가 물리 테이블 너머의 기반 명세를 살펴본다. customer_spend_30d와 새 90일 요청이 정확히 같은 DNA를 공유한다는 점을 발견한다. USD 구매 정의, 고객 식별 규칙, 그리고 결정적으로 완전한 UTC 일 경계가 동일하다. 현재 시점의 초에 끝나는 롤링 윈도우는 집계를 공유할 수 없기 때문이다.

사람이 키보드에 손을 대지 않아도 시스템은 적응한다.

1. 90일 이력을 가진 공유 customer_spend_daily 중간 자산을 제안한다.

2. 소스 이력이 존재하는지 확인하고, 접근 정책을 점검하며, 일별 롤업을 백필한다.

3. 일별 테이블 위에 90일 지원 자산을 만들고, 기존 30일 영업 자산이 새 일별 중간 자산을 읽도록 조용히 재배선한다.

새 비즈니스 요구사항으로 인해 엔진은 공유 자산을 만들고 기존 자산을 재배선한다.

숙련된 엔지니어라면 누구나 10분 안에 그 리팩터링을 수행할 수 있다. 핵심은 아무도 수행할 필요가 없었다는 점이다. 두 번째 요청이 최적 아키텍처를 바꾸었고, 오케스트레이션 엔진은 영업 애플리케이션의 계약을 보존하면서 그래프를 재조직했다.

통합은 맹목적인 지시가 아니다. 다른 통화 정책, 고객 정의, 접근 범위 또는 회계연도 달력에는 별도 구현이 필요하다. 비슷한 열 이름과 일치하는 샘플 행은 동등성을 결코 입증하지 못한다. 오직 정형 정의만이 입증할 수 있다.

유효한 공유에도 열역학적 비용은 따른다. 공유 의존성은 장애의 영향 범위를 넓히며, 한 실시간 소비자를 만족하기 위해 무거운 중간 자산을 5분마다 새로 고치는 비용은 두 개의 별도 파이프라인을 실행하는 비용보다 클 수 있다.

불필요한 반복 변경을 피하기 위해 플래너는 감쇠 제어 시스템처럼 동작한다. 실제 컴퓨팅 비용을 측정하고, 재조직 전에 최소 기대 절감 임계값을 요구하며, 자산 리팩터링 빈도에 상한을 둔다. 진정한 중복을 발견하면, 의존자가 마이그레이션할 때까지 두 기존 인터페이스 뒤에서 물리 구현을 병합한다.

이는 플랫폼 팀이 기념하는 대상을 바꾼다. 테이블 수나 파이프라인 속도가 아니라, 최적 비용으로 이행된 소비자 계약이다. 때로 새 요청에 대한 최선의 대응은 아무것도 만들지 않는 것이다.

이 비전의 일부는 이미 존재한다. Kubernetes는 조정 루프(희망 상태와 실제 상태)를 대중화했다. 자산 중심 오케스트레이터는 우리의 사고 모델을 작업 스케줄에서 데이터 자산으로 옮겼다. 웨어하우스 동적 테이블과 구체화된 뷰는 증분 새로 고침을 자동화한다.

하지만 이 도구들은 모두 여전히 사람이 그래프를 작성할 것을 기대한다. 자기 조직화 스택은 그래프 작성 자체를 오케스트레이션 엔진으로 옮긴다.

이를 안전하게 수행하기 위해 런타임은 희망 상태(소비자가 계약한 결과와 SLA)와 관측 상태(실제로 존재하는 구현, 계보, 워터마크, 상태)에 대한 버전 지정 뷰를 유지한다. 새 요청, 실패한 검사 또는 만료된 약속이 둘 사이에 격차를 만들면 엔진은 그래프 변이를 제안한다.

엔진은 의도와 관측 상태를 지속적으로 비교하며, 제안된 그래프 변경부터 그 결과까지의 전체 경로를 소유한다.

LLM은 의도를 파싱하고 후보 SQL을 초안하는 데 도움을 줄 수 있지만, 모델의 확신은 그래프 변경을 승인하지 않는다. 초안은 결정론적 플래너, 타입 검사, 접근 게이트, 비용 제어, 독립 검증으로 제한된다.

스케줄링은 이러한 결정에서 직접 출현한다. 소스 워터마크가 전진할 때 일별 롤업이 실행되고, 윈도우형 뷰는 UTC 자정에 앞으로 이동한다. 이는 전통적인 파이프라인 DAG를 뒤집는다. DAG는 더 이상 시스템의 지속적인 진실 원천이 아니라, 단일 변경을 위해 생성되는 일시적 계획인 폐기 가능한 실행 산출물이 된다. 지속되는 것은 자산, 약속, 결정이다.

검증 없는 자율성은 자동화된 혼돈일 뿐이다. 엔진이 공유 일별 지출 테이블을 활성화하기 전에, 해당 변경이 30일 소비자의 계약을 깨지 않는다는 점을 입증해야 한다.

데이터 엔지니어의 주말을 망치는 고전적인 함정을 생각해 보자. 과거 식별자 팬아웃이다. 고객 식별 소스가 과거 계정 병합을 추적하고, 승인된 귀속 규칙이 구매 당시 활성 상태였던 매핑을 사용한다고 하자. 후보 변환이 부주의하게 account_id만으로 조인하면, 과거 매핑이 두 개인 모든 계정의 구매는 두 번씩 집계된다.

그 깨진 테이블에 표준 구문 테스트를 실행하면 어떤 일이 일어나는지 보자.

• 스키마 검사? 통과.

• 널 검사? 통과.

• 집계 후 기본 키 유일성? 통과.

전통적인 대시보드의 모든 녹색 신호가 당신을 속인다. 합계가 그저 틀린 것이다.

자기 조직화 스택은 단순한 구문이 아니라 의미론적 불변식에 대해 검증한다. 승인된 구매 정의에 대한 조정 검사는 즉시 이중 집계된 매출을 드러내고, 이를 제안된 일별 의존성까지 추적한다. 엔진은 유효 기간을 존중하도록 조인을 수정하고 검증을 다시 실행한다. 동일한 입력 스냅샷에서 이전 구현과 새 구현을 비교하는 동시에 비즈니스 불변식을 독립적으로 검사한다. 계산과 그 테스트를 모두 작성하는 LLM은 자신의 가정을 인증할 수 없다.

검증이 끝난 뒤 활성화는 동시성도 처리해야 한다. 테스트가 진행되는 동안 새 소비자가 30일 자산에 대한 의존성을 등록하면 근거는 오래된 것이 된다. 이를 포착하기 위해 조정자는 트랜잭션 레지스트리 내부의 엄격한 개정 번호에 각 활성화를 연결한다. 자산을 스테이징하고, 테스트 중 계약이 바뀌지 않았는지 확인하며, 활성 포인터를 원자적으로 전환한다. 또는 별도 스토리지 백엔드 전반에 걸쳐 블루/그린 마이그레이션을 조정한다. 결함이 빠져나가더라도 복구 기록은 노출 기간에 잘못된 데이터를 읽은 모든 하류 소비자의 이름을 담는다. 테이블을 롤백해도 에이전트가 이미 취한 행동을 되돌릴 수는 없기 때문이다.

오케스트레이션 엔진이 물리 모델을 유지한다면, 사람들은 시스템을 이해하기 위해 어디로 가야 할까? 스키마가 아니라 결정으로 가야 한다.

세 번째 소비자가 _90일간 가구 지출_을 요청한다고 하자. 엔진은 승인된 가구 정의 두 가지를 찾는다. 하나는 사람들을 물리적 거주지로 묶고, 다른 하나는 연결된 청구 계정으로 묶는다.

엔진은 추측하지 않는다. 각 정의가 고객을 어떻게 그룹화하는지, 어느 기존 자산을 각각 재사용할 수 있는지, 각각의 비용이 얼마인지를 보여 주며 도메인 소유자에게 하나의 정밀한 질문을 에스컬레이션한다. 인간이 의미를 선택하고, 엔진은 해당 선택을 승인된 도메인으로 한정해 그래프를 도출한다.

모든 명확화, 명세, 제안, 검증 보고서, 배포는 불변의 결정 로그에 연결된다. 라이브 자산의 모든 요구사항은 그 인과적 기원을 직접 가리킨다.

W3C PROV 및 OpenLineage 같은 표준을 기반으로 하는 이 기록은 과거 스타 스키마가 수행하던 인지적 역할을 대체한다. 테이블이 무엇을 의미하는지 추측하기 위해 SQL 파일을 역설계하는 대신, 자산이 왜 존재하는지, 무엇을 보장하는지, 누가 그 정의를 승인했는지를 읽는다. 인간의 판단은 버전이 지정된 데이터로 축적된다.

새벽 3:00에 이것이 깨지면, 내가 그리지 않은 그래프를 어떻게 디버그할까? 실패한 작업이 아니라 깨진 약속에서 시작하라.

전통적인 오케스트레이터에서는 DAG가 설계 그 자체이므로 DAG를 읽어 디버그한다. 여기에서는 설계가 명세와 결정에 존재한다. 누군가 신경 쓰는지 알아보기 위해 빨간 작업 상자를 추적하는 대신, 운영자 콘솔은 순서대로 네 가지 질문에 답한다. 어떤 약속이 이행되지 않았는지, 어떤 소비자가 영향을 받는지, 어떤 최근 그래프 변경이 이를 건드렸는지, 엔진은 어떤 복구를 테스트 중인지다. 또한 제동 장치 없는 자율성은 첫 번째 사고를 견디지 못하므로, 운영자는 도메인 전반의 재조직을 동결하고, 자산을 알려진 정상 버전에 고정하거나, 과거 입력에 대해 제안을 재실행할 수 있다.

마찬가지로 중요하게도 살아 있는 스택은 스스로 뒤를 정리한다. 생물학에서 뼈는 응력이 가해지는 곳에서 자라고 하중이 사라지는 곳에서 녹는다. 현재 데이터 웨어하우스에는 신진대사가 없다. 질량만 축적한다.

자기 조직화 스택에서 영업 애플리케이션이 결국 30일 지출 구독을 중단하면, 엔진은 90일 지원 자산은 유지하면서 customer_spend_30d를 폐기한다. 분기 말에만 실행될 수 있는 재무 작업이 있기 때문에 순진한 쿼리 로그 수집에 의존하지 않는다. 대신 명시적인 계약 만료, 규정 준수 보존 정책, 재구축 비용을 함께 고려한다. 물리 테이블을 가상 뷰로 강등하거나, 이력을 유지하면서 컴퓨팅을 동결하거나, 마지막 공유 의존자가 사라진 뒤 중간 테이블을 완전히 해소할 수 있다.

이 설계는 데이터 엔지니어를 없애지 않는다. 우리가 작성하는 것의 수준을 높인다. 요청을 취약한 DAG로 번역하는 인간 컴파일러 역할을 멈추고, 런타임이 따라야 할 경계와 물리 법칙을 설계하기 시작한다.

이 전환을 시작하기 위해 하룻밤 사이에 오케스트레이터를 교체할 필요는 없다. Ian Macomber가 최근 AI 이후 데이터 스택에서 주장했듯이, AI는 분석 생산을 저렴하게 만들며, 이는 _현실에 대한 엔지니어링 합의_가 새로운 병목이 된다는 뜻이다. 오늘날 가장 실용적인 임시 방편은 기존 데이터 파이프라인과 나란히 전용 컨텍스트 파이프라인을 구축하는 것이다. 즉, ETL에서 ECL로(추출, 맥락화, 연결) 전환하는 것이다. 코딩 에이전트가 볼 수 없는 400줄 SQL 파일에 비즈니스 규칙을 묻어 두는 대신, 컨텍스트 파이프라인은 엔터티 정의와 도메인 결정을 권위 있는 계층으로 추출하고, 버전을 지정하며, 연결한다. 그 컨텍스트 계층이 성숙하면 코딩 에이전트를 위한 참조 자료에 그치지 않고 오케스트레이터의 제어 평면이 된다.

데이터 플랫폼이나 오케스트레이션 엔진을 만든다면, 여기서 시작하라.

1. 소비자 약속을 일급 요소로 만들어라. 각 자산에 누가 의존하는지, 무엇을 약속했는지를 이를 이행하는 SQL과 분리해 기록하라.

2. 플래너보다 먼저 의미 계층에 투자하라. 엔진은 정형 정의로부터 동등성을 입증할 수 있는 대상만 재조직할 수 있다.

3. 적대적 검증을 구축하라. 승인된 정의에 대해 출력을 독립적으로 검사하고, 근거의 등급을 매기며, 에이전트가 자신의 작업을 평가하게 하지 마라.

4. 결정을 데이터로 다뤄라. 모든 인간의 명확화를 그 권한, 범위, 그리고 영향을 준 자산과의 연결과 함께 포착하라.

오늘날 파이프라인 DAG는 사람이 데이터 아키텍처를 기록하는 곳이다. 자기 조직화 스택에서는 오케스트레이션 엔진이 계속 그것을 작성한다. 새 요청이 그래프를 만들고, 중복이 그래프를 재구성하며, 실패한 약속이 복구를 촉발하고, 만료된 약속이 그래프를 단순화한다. 인간은 의미를 작성하고, 엔진은 그래프를 작성한다.

이것이 내가 에이전트 시대에 원하는 오케스트레이션 엔진이다.

모든 권리 보유, Dewpeche Private Limited. 정보 제공 목적으로 링크를 제공하며 이를 보증하지 않습니다. 이 뉴스레터에 표현된 모든 견해는 저 자신의 것이며, 현재·과거·미래 고용주의 의견을 대변하지 않습니다.