AI 이후의 데이터 엔지니어링

며칠 전, AI가 점점 더 코드를 작성하게 되면서 소프트웨어 엔지니어링에서 무엇이 핵심으로 남는지 묻는 LinkedIn 설문을 올렸습니다. 53%는 아키텍처와 트레이드오프를 꼽았습니다. 20%는 품질과 오너십, 25%는 제품과 문제 발견을 선택했습니다.

이 설문은 데이터 엔지니어링을 특정해서 묻지는 않았지만, 나온 답은 우리에게도 그대로 적용됩니다. AI가 시니어 엔지니어만큼 유창하게 파이프라인을 생성할 수 있게 되면, 문제는 우리 도구 상자가 바뀌느냐가 아닙니다 — 그건 분명히 바뀝니다. 문제는 다음입니다. 애초에 자동화하기엔 늘 너무 중요했던 사고는 무엇이었으며, 우리는 왜 그것이 더 기계적인 작업들 아래 묻히도록 내버려 두었는가.

제 대답은, 줄일 수 없는 핵심 작업은 결코 데이터를 옮기는 일이 아니었다는 것입니다. 그것은 언제나 의미에 관한 일이었습니다. 그리고 우리가 써 온 프레임워크 — ETL — 은 사실 의미를 포착하도록 설계된 것이 아니었습니다.

Extract, Transform, Load는 특정한 역사적 순간의 직무 설명으로서는 타당했습니다. 소스 시스템은 사일로화되어 있었고, 포맷은 일관되지 않았으며, 누군가는 데이터가 있는 곳에서 사용될 수 있는 곳으로 옮기는 코드를 작성해야 했습니다. 데이터 엔지니어가 바로 그 누군가였습니다.

하지만 솔직히 말하면, 변환(Transformation) 단계는 언제나 가장 취약한 부분이었습니다. 팀들은 비즈니스 룰을 SQL 로직이나 Python 함수로 인코딩해 파이프라인 코드 안에 묻어두고, 인프라와 함께 버전 관리했지만, 애플리케이션 코드와 같은 수준의 엄격함으로 다루는 경우는 드물었습니다. “활성 사용자(active user)”의 정의가 바뀌면 — 그리고 그것은 항상 바뀌었습니다 — 누군가는 그 정의가 들어 있는 모든 위치를 찾아 업데이트해야 했고, 전부 잡아냈기를 바라야 했습니다.

AI는 이제 이런 종류의 코드를 생성하는 데 능숙합니다. 완벽하진 않지만, 파이프라인 구성이라는 기계적 작업이 더 이상 의미 있는 차별화 요소가 아닐 정도로는 충분히 능숙합니다. 변환 로직을 잘 작성하는 능력 위에 직업적 정체성을 세워왔다면, 그 정체성은 압박을 받게 됩니다.

하지만 이것은 상실의 이야기가 아닙니다. 명료함의 이야기입니다. 기계적 작업은 언제나 그 아래의 더 중요한 작업을 가리고 있었습니다. AI가 그 현실을 직면하게 만드는 것은, 이상하게도 선물입니다.

대체물로 떠오르는 프레임워크는 기술 아키텍처라기보다는 목적의 재정렬에 가깝습니다. Extract, Transform, Load 대신 Extract, Contextualize, Link를 떠올려 보세요.

Extract는 그대로 남습니다. 데이터는 여전히 소스 시스템에서 분석 환경으로 이동해야 하며, 이 작업은 여전히 엔지니어링 판단을 요구합니다 — 신뢰성, 지연 시간, 볼륨, 실패 모드에 대한 판단 말입니다. AI가 점점 더 기계적인 부분을 처리하겠지만, 무엇을 언제 어떻게 추출할지에 대한 아키텍처 결정은 소스 시스템과 다운스트림 결과를 모두 이해하는 사람의 몫입니다.

Contextualize에서 진짜 변화가 일어납니다. 이는 데이터에 의미론적 의미를 부여하는 작업입니다 — “매출(revenue)”이 Finance와 Sales에서 서로 다르게 계산된다는 점, 클릭스트림 이벤트의 타임스탬프가 청구(billing) 레코드의 타임스탬프와는 다른 의미를 가진다는 점, 한 시스템에서의 null 값이 정보의 부재를 뜻하지만 다른 시스템에서는 명시적인 사용자 선택을 뜻한다는 점을 이해하는 것입니다. AI는 이 작업을 대규모로 초안 작성할 수 있습니다 — 필드 정의를 추론하고, 엔터티를 분류하고, 어떤 인간 팀도 완전히 수동으로 주석을 달 수 없는 데이터 환경 전반에서 관계를 매핑할 수 있습니다. 하지만 AI가 할 수 없는 것이 있습니다. 스스로에 대해 책임지는 것입니다. 어떤 추론이 맞는지에 대한 판단, 정의를 선언할 조직적 권한, 발견된 패턴을 강제되는 계약으로 공식화할지의 결정 — 이것은 인간에게 속합니다. Contextualize는 AI의 추론과 인간의 판단이 만나는 지점이며, 그 목적을 위해 특별히 구축된 파이프라인에 의해 구조화됩니다.

Link는 데이터 환경 전반의 엔터티 관계에 관한 것입니다 — CRM의 고객 레코드를 제품 데이터베이스의 사용자 레코드와 연결하고, 분석 시스템의 이벤트를 지원 도구의 세션과 연결하는 것입니다. AI가 데이터를 소비하는 코드를 더 많이 생성할수록, 시스템 간 엔터티가 어떻게 연관되는지 추론하는 능력은 덜 가치 있어지는 것이 아니라 더 가치 있어집니다. 연결(linkage)은 맥락을 휴대 가능하게 만드는 것 — 데이터 환경의 한 부분에서 구축된 의미가 나머지와의 관계 속에서 근거를 갖게 해주는 것 — 입니다.

이 글의 나머지에서는 ECL이 아키텍처 수준에서 어떻게 동작하는지, 세 가지 추상적 개념이 아니라 세 가지 구체적인 파이프라인으로서 다루고, 왜 이 셋이 모두 필요한지를 설명합니다.

첫 번째 기법은 early binding입니다. 데이터가 이동하기 전에, 데이터가 생성되는 시점에서 의미론적 의도를 포착하는 것입니다.

데이터 계약(data contracts)은 이 아이디어의 실용적 구현입니다. 본질적으로 계약은 데이터 생산자와 소비자 사이의 합의이며 — 스키마, 데이터 품질 기대치, 오너십, 그리고 각 필드의 의미론적 의미를 명시합니다.

Data Engineering Weekly는 _Data Contracts: A Missed Opportunity_에서 이 격차를 정확히 짚었습니다. 데이터 업계가 계약이 무엇인지 논쟁하고 이를 설명하기 위한 거버넌스 프레임워크를 초안으로 작성하는 동안, 소프트웨어 엔지니어링은 조용히 다른 조직 원리로 수렴하고 있었습니다. 즉, 명세(specification)를 실제 실패 의미론을 가진 실행 가능한 제약(executable constraints)으로 다루는 것입니다. 데이터 업계는 계약을 문서로 취급했습니다. 소프트웨어 엔지니어는 그것을 인터페이스로 취급했습니다 — 깨질 수 있고, 버저닝 함의를 가지며, 단지 설명하는 것이 아니라 동작을 강제하는 것 말입니다.

위키에 존재하고 누군가 기억날 때 업데이트되는 데이터 계약은 문서입니다. 생산 시점에서 강제되는 데이터 계약 — 예고 없이 스키마가 바뀌면 파이프라인을 실패시키고, 품질 임계치가 위반되면 소비자에게 경고하며, AI 에이전트가 결정론적으로 추론할 수 있는 — 그것이 아키텍처입니다.

이는 AI 비중이 큰 세상에서 덜 중요해지는 것이 아니라 더 중요해집니다. AI 에이전트가 변환 코드를 생성할 때, 나쁜 계약은 대규모로 증폭됩니다. 에이전트는 주어진 로직을 충실히 구현할 것입니다. 입력을 지배하는 계약이 모호하거나 강제되지 않는다면, 만들어지는 오류는 고립적이기보다 체계적일 것입니다. early binding은 인간의 의도가 AI가 실제로 작업할 수 있는 형태로 공식화되는 메커니즘입니다.

하지만 early binding만으로는 근본적인 한계가 있습니다. 그리고 그 한계를 이해하는 것이 Contextualize 파이프라인이 왜 필요한지를 설명합니다.

잘 계약된 데이터셋이 현대적 Medallion 아키텍처를 통해 이동할 때 무슨 일이 일어나는지 생각해 보세요.

Bronze 레이어에서는 데이터가 소스에 가깝게 착지합니다 — 원시(raw) 상태에 가깝고 최소한의 변환만 거치며, 계약의 보장도 대체로 유지됩니다. Silver는 정합(conformance) 규칙을 적용합니다: 중복 제거, 타입 캐스팅, 가벼운 표준화. 데이터가 Gold에 도달할 때쯤이면, 파이프라인은 데이터를 대신해 일련의 편집적 결정(editorial decisions)을 내린 상태입니다. 집계는 세밀한 이벤트를 메트릭으로 압축합니다. 엔지니어는 비즈니스 로직을 테이블의 형태 속에 구워 넣습니다. Gold 레이어는 특정 질문 집합에 최적화된 산출물입니다 — 파이프라인을 만들 당시 중요해 보였던 질문들 말입니다.

early binding 계약은 소스에서는 도움을 주지만, 이후의 각 홉에서 이런 침식을 막을 수는 없습니다 — 특히 계약이 실행 가능(executable)하기보다 서술적(descriptive)으로 취급될 때는 더 그렇습니다. 변환을 거치며 의미가 드리프트하는 것을 막는 강제 메커니즘이 없다면, ‘전화 게임(telephone game)’은 파이프라인 안에서 조용히 진행됩니다. 소비자가 Gold 레이어를 쿼리할 때쯤이면, 그들은 원래 의도에서 여러 번의 편집적 결정을 거쳐 멀어진 산출물을 다루고 있을 수 있습니다.

이것이 early binding만으로는 해결할 수 없는 문제입니다. 각 변환 레이어는 소스에서 포착된 맥락을 점점 더 압축해 버립니다. 따라서 실제로 필요할 때 맥락을 복구할 수 있는 능력을 보존하는 보완적 접근이 필요합니다.

전통적인 late binding은 비즈니스 룰의 적용(application) 을 쿼리 시점으로 미뤘습니다. 하지만 그 룰의 정의(definition) 까지 미루지는 않았습니다 — 도메인 전문가는 여전히 이를 upfront로 명시해야 했고, 다만 물리적 테이블에 구워 넣는 대신 시맨틱 레이어를 통해 적용했을 뿐입니다. 복잡한 도메인에서는 그 지식 엔지니어링 과정 자체가 병목이었습니다.

더 전향적인 접근은 정의 자체를 미루고 — 그 작업을 전용 파이프라인에 맡기는 것입니다.

Contextualize 파이프라인은 데이터 인프라와 나란히 동작하는 별도의 에이전틱(agentic) 파이프라인입니다. 임무는 하나입니다. 살아 있고 검증된 의미론적 맥락의 저장소를 구축하고 유지하는 것. 이는 Extract 파이프라인의 일부가 아닙니다. 쿼리 시점 프로세스도 아닙니다. 자체 트리거 모델, 검증 레이어, 저장소를 갖춘 1급 엔지니어링 산출물입니다.

트리거는 스케줄 기반이 아니라 이벤트 기반입니다. 새 데이터셋이 착지할 때마다 자동으로 파이프라인이 시작됩니다. 기존 데이터셋의 경우에는, 연속 프로파일링(continuous profiling)이 의미 있는 변화를 모니터링합니다 — 새 컬럼이 생기거나, 컬럼이 삭제되거나, 데이터 분포가 업스트림에서 무언가 바뀌었다고 시사할 만큼 이동하는 경우 등입니다. 이러한 이벤트는 영향을 받는 엔터티에 대해 파이프라인을 다시 트리거합니다. 의미론적 맥락은 일회성 주석 작업이 아닙니다. 데이터가 진화하는 것을 따라갑니다.

파이프라인 자체는 에이전틱합니다. AI 에이전트가 들어오는 데이터를 분석합니다 — 스키마, 샘플 값, 통계 프로파일, 계보(lineage) — 그리고 의미론적 의미를 추론합니다. 이 필드는 무엇을 나타내는가? 어떤 비즈니스 엔터티에 속하는가? 데이터 환경의 다른 데이터와 어떤 관계가 있는가? 그 결과로 구조화되고 버전 관리되는 맥락 산출물을 만들어냅니다. 즉, 도메인 전문가가 모든 시나리오를 사전에 명시하지 않아도 의미를 추론한 결과들입니다.

그 추론은 자동으로 커밋되지 않습니다. 구조적으로 라벨링 워크플로우처럼 동작하는 검증 레이어로 라우팅됩니다 — 왜냐하면 구조적으로, 실제로 그것이 라벨링 워크플로우이기 때문입니다. LLM-as-Judge가 높은 신뢰도의 추론을 인간 리뷰 없이 검증합니다. 중간 신뢰도의 추론은 도메인 전문가에게 라벨링을 위해 노출됩니다. 낮은 신뢰도이거나 이견이 있는 추론은 더 깊은 조사 대상으로 플래그됩니다. 인간은 모든 산출물을 리뷰하는 것이 아니라, 불확실한 것들을 리뷰합니다. ML 파이프라인에서 통하는 모든 라벨링 자동화 기법이 여기에도 적용됩니다.

검증된 산출물은 Context Store에 저장됩니다 — 의미론적 정의, 엔터티 분류, 관계 맵을 담는 전용의 버전 관리되고 쿼리 가능한 저장소입니다. 이것이 ECL이 요구하는 새로운 인프라 컴포넌트입니다. 다운스트림 에이전트는 원시 데이터를 쿼리하고 그 자리에서 의미를 즉흥적으로 추론하지 않습니다. 먼저 Context Store를 쿼리해 검증된 맥락에 기반해 이해를 고정(ground)한 뒤 데이터를 쿼리합니다. 맥락은 안정적이고 재사용 가능하며 감사 가능(auditable)합니다 — 덧없는 쿼리 시점 추론의 정반대입니다.

의사결정 기준은 의미론적 성숙도나 도메인이 얼마나 잘 이해되어 있느냐가 아닙니다. 데이터가 당신의 책임 경계(accountability boundary) 대비 어디에서 오느냐에 관한 것입니다.

데이터셋이 통제된 환경에서 기원할 때 — 조직의 책임 범위 안에 있는 팀이나 시스템이 생산할 때 — early binding이 올바른 도구입니다. 생산자와 소비자는 조직적 맥락을 공유합니다. 계약은 협상될 수 있고, 강제될 수 있으며, 그에 대한 책임을 물을 수 있습니다. 생산 팀은 자신들이 선언한 스키마와 커밋한 의미론에 대해 책임을 지게 할 수 있습니다. 강제 가능하게 만드는 관계가 존재하므로, 규정된 맥락(prescribed context)이 가능합니다.

데이터셋이 그 경계 밖에서 기원할 때 — 서드파티 피드, 파트너 데이터, 공개 데이터셋, 마켓플레이스 소스 — 그 관계는 존재하지 않습니다. 외부 제공자에게 데이터 계약을 강제할 수 없습니다. 스키마는 예고 없이 바뀔 수 있습니다. 의미론은 선언되는 것이 아니라 추론됩니다. 이때 Contextualize 파이프라인이 제 역할을 합니다. 발견된 맥락(discovered context)만이 유일하게 가능한 종류입니다.

하지만 그 경계는 순전히 조직적인 것만은 아닙니다. 거버넌스가 부실한 내부 데이터 — 소비자에 대한 책임이 없는 팀이 생산하고, 스키마가 문서화되지 않았고, 정의가 일관되지 않은 데이터 — 는 같은 조직 안에 있더라도 사실상 통제 불가능합니다. 진짜 테스트는 조직도에서의 위치가 아닙니다. 책임입니다. 책임이 존재하는 곳에서는 early bind 하세요. 책임이 없는 곳에서는 Contextualize 파이프라인이 발견하도록 하세요.

피드백 루프는 양방향으로 유지됩니다. 반복적인 프로파일링, 추론, 검증을 통해 구축된 발견 맥락은 시간이 지나며 규정된 맥락으로 승격(graduate)될 수 있습니다. 조직이 충분히 일관되게 수집하여 프로파일링하고 검증하고 내부 데이터 제품으로 재배포하는 외부 데이터셋은, 그 시점에서 통제 불가능에서 통제로 경계를 넘습니다. Contextualize 파이프라인은 그 전환을 가능하게 하는 것이며 — 결과적으로 계약이 ‘가정된 것’이 아니라 ‘신뢰할 수 있는 것’이 되게 합니다.

모든 데이터를 early-bindable로 취급하는 데이터 환경은 취약합니다. 이미 이해하는 것만 계약할 수 있고, 분석 환경에서 점점 더 큰 비중을 차지하는 통제 불가능 데이터를 다룰 메커니즘이 없습니다. 모든 데이터가 발견이 필요하다고 취급하는 데이터 환경은, 배운 것을 강제 가능한 보장으로 공식화하지 못합니다. 제대로 동작하는 아키텍처는 책임 경계를 정확히 읽고, 양쪽에 올바른 기법을 적용합니다.

이제 세 개의 파이프라인이 존재하므로, 질문은 이렇게 바뀝니다. 맥락은 실제로 어떻게 아키텍처를 따라 이동하며, 어떻게 잃어버리지 않을까?

기존의 정신 모델은 잘못되었습니다. 맥락은 데이터 파이프라인 안으로 이동하지 않습니다 — 만약 그렇다면, 변환 단계마다 잃어버릴 것이고, 그것이 바로 Medallion 침식 문제입니다. 맥락은 파이프라인 옆으로 이동합니다. 메타데이터, 계보 기록, 계약의 출처(provenance)로서 말입니다. 변환은 데이터를 바꾸고, 메타데이터는 의미를 보존합니다.

릴레이는 이렇게 동작합니다. early binding은 기원 지점에서 규정된 맥락 — 스키마, 필드 수준 의미론, 생산 팀 오너십, 품질 임계치 — 을 컬럼 값이 아니라 메타데이터에 존재하는 실행 가능한 계약으로 찍어 넣습니다(stamp). 계보(lineage) 도구는 이를 Bronze, Silver, Gold를 거쳐 전파하며, 적용된 변환과 각 단계에서 데이터를 지배했던 계약에 대한 기록을 유지합니다. Contextualize 파이프라인은 그 계보를 추론 과정의 일부로 읽습니다 — 오늘의 필드가 어떤 모습인지뿐 아니라, 그것이 어떻게 도달했는지의 역사와 소스에서 약속된 커밋까지 이해합니다. 검증된 추론은 Context Store에 저장되고, 이것이 릴레이의 종착지가 됩니다. 원래 계약과 누적된 계보에 모두 근거한, 데이터 의미에 대한 내구적이고 쿼리 가능한 기록입니다.

이를 구체화해 주는 비유는 git입니다. 파일은 수십 번의 커밋에 걸쳐 크게 수정될 수 있습니다 — 리팩터링되고, 이름이 바뀌고, 이동되고, 다시 쓰이더라도 — 그것이 어떻게 그곳에 이르렀는지에 대한 맥락은 결코 잃어버리지 않습니다. 파일 자체가 아니라 커밋 히스토리에 살기 때문입니다. Gold 레이어는 최신 커밋입니다. 계보 그래프는 git log입니다. Context Store는 현재 파일이 모든 이야기를 말해주기를 바라는 대신, 그 로그를 체계적으로 읽어 구축하는 이해입니다.

이 재구성 — 파이프라인에서 릴레이로 — 는 데이터 엔지니어가 실제로 무엇을 구축할 책임이 있는지 바꿉니다. 변환은 점점 더 자동화될 수 있습니다. 메타데이터 인프라, 계보 그래프, 이를 읽는 Contextualize 파이프라인, 그리고 그로부터 축적되는 Context Store — 이것이 지속적인 인간의 판단이 필요한 엔지니어링 표면(engineering surface)입니다.

그리고 이제, 가장 중대한 엔지니어링 작업이 어디로 이동했는지에 도달합니다.

Context Store는 비즈니스 정의가 존재하는 곳입니다 — 위키의 문서로서가 아니라, 엔지니어가 Gold 테이블에 구워 넣은 로직으로서가 아니라, 다운스트림 시스템이 쿼리할 수 있고 신뢰할 수 있는 버전 관리되고 검증된 산출물로서 말입니다. 여기서 Finance와 Sales의 “revenue”에 대한 경쟁적 해석이 해결됩니다 — 조직 정치가 아니라, 어떤 추론이 공식화될 자격을 얻는지를 결정하는 신뢰도 기반 프로세스로 말입니다. 여기서 AI 소비자들은 임시방편적 추론으로 되돌아가지 않고, 신뢰성 있게 행동하는 데 필요한 고정되고 안정적인 맥락을 찾습니다.

이 표면은 ‘쿼리 가능한 데이터’와 ‘신뢰할 수 있는 데이터’를 구분합니다. 테이블이 완벽하게 파티셔닝되고, 인덱싱되고, 복제되어 있더라도 의미론적으로 틀릴 수 있습니다 — 세 번의 변환 전에 소스 계약에서 드리프트했지만 아무도 감지하지 못한 정의 위에 구축된 경우 말입니다. Context Store는 그 실패 모드를 닫는 곳입니다.

AI가 더 많은 변환 코드를 생성하고 AI 에이전트가 더 큰 규모로 데이터를 소비할수록, 이 표면의 중요도는 커집니다. 오래되었거나 상충하는 맥락 산출물 위에서 동작하는 에이전트는, 회복 가능한 오류가 아니라 체계적 오류를 만들어냅니다. 신뢰성을 지배하는 엔지니어링 작업 — Contextualize 파이프라인의 트리거 모델 설계, 라벨링 워크플로우 구조화, 어떤 검증 신뢰도 임계치가 공식화의 자격을 얻는지 결정, 정의가 진화함에 따라 맥락 산출물을 버전 관리 — 는 모든 단계에서 인간의 판단을 요구합니다.

실무자들은 여전히 이를 대규모로 수행하는 패턴을 찾아가는 중입니다. 툴링은 성숙해지고 있습니다. 조직이 Context Store의 오너십을 어떻게 거버넌스할지, 팀 간 충돌을 어떻게 재정(adjudicate)할지, 발견된 맥락에서 규정된 맥락으로의 승격을 어떻게 관리할지는 진짜로 열린 질문입니다. 여기가 실제 최전선입니다.

설문으로 돌아가 봅시다. 53%는 아키텍처와 트레이드오프가 줄일 수 없이 인간에게 남는다고 했습니다. 데이터 엔지니어링 맥락에서, ECL은 실무에서 그것이 어떤 모습인지를 보여줍니다.

다음 10년의 데이터 엔지니어는 ‘의미의 아키텍처’를 소유합니다. 그들은 소스에서 계약적 기반을 설계합니다 — 실행 가능하고, 강제 가능하며, 버전 관리되는 기반입니다. 그들은 맥락이 모든 변환 레이어를 거치며 잃어버리지 않도록 운반하는 계보 인프라를 구축합니다. 그들은 Contextualize 파이프라인과 Context Store — 추론이 구축되고 검증되고, 다운스트림의 모든 것이 의존하는 정의로 공식화되는 인프라 — 를 설계하고 거버넌스합니다. 그들은 맥락을 upfront로 규정해야 할 때와 발견되도록 두어야 할 때를 이해하며, 둘 다 가능하게 만드는 시스템을 구축합니다.

하지만 이것은 기술적 역할만은 아닙니다. 맥락 침식은 기술적 실패만큼이나 조직적 실패입니다. 팀들이 의미론적 정의를 공유하지 않는 이유는, 그렇게 하도록 유인하는 오너십 모델이 없기 때문입니다. 계약을 강제하는 사람이 없는 이유는, 생산 팀이 자신들이 обслуж하는 소비자에게 책임을 지지 않기 때문입니다. 이 새로운 프레임에서 데이터 엔지니어는 기술 시스템과 그것을 하나로 묶는 조직적 합의를 모두 구축하는 사람입니다. 그들은 아키텍처와 조정(coordination)의 교차점에 서 있습니다 — 설문 응답자들이 줄일 수 없이 인간적이라고 올바르게 지목한 두 가지 말입니다.

“Data Engineer”라는 타이틀은 업데이트가 필요할지도 모릅니다. 우리가 실제로 설명하고 있는 것은 Context Architect — 주요 재료가 데이터 이동이 아니라 데이터 의미이고, 파이프라인이 아니라 출처(provenance)이며, 변환 로직이 아니라 변환 로직을 신뢰할 수 있게 만드는 의미론적 인프라인 사람 — 입니다.

ECL이 무엇이고 무엇이 아닌지에 대해 솔직하고 싶습니다. 이것은 재정렬입니다 — AI가 과거의 업무 모습 중 더 많은 부분을 처리하게 된 지금, 실제 일이 무엇인지에 대한 사고 방식입니다. 완성된 방법론이 아닙니다. early binding 계약을 Contextualize 파이프라인과 Context Store에 연결하는 툴링은 아직 성숙하는 중입니다. 누가 Context Store를 소유하는지, 팀 간 충돌을 어떻게 재정하는지, 발견된 맥락이 어떻게 공식화의 자격을 얻는지에 대한 조직적 패턴은 아직 확립된 템플릿이 없습니다. 실무자들은 지금 이 순간에도, 프로덕션 환경에서 규모 있게 신뢰성 있게 동작하는 컨텍스트 파이프라인을 구축하는 엔지니어링 패턴을 만들어가고 있으며, 진행하면서 해답을 찾아가고 있습니다.

바로 그것이 이 순간을 주의 깊게 볼 가치가 있는 이유입니다. 최전선은 진짜로 열려 있습니다. 맥락의 아키텍처적·조직적 작업에 투자하는 실무자들 — 계약을 실행 가능한 인프라로 다루고, 계보를 1급 엔지니어링 관심사로 구축하며, Contextualize 파이프라인과 Context Store를 과거에 ETL 파이프라인을 소유했던 것만큼 진지하게 거버넌스하는 사람들 — 이 앞으로 10년의 규율을 정의할 것입니다.

아키텍처와 트레이드오프가 줄일 수 없이 인간적이라고 말한 53%는 옳았습니다. 우리는 아직 어떤 아키텍처인지, 어떤 트레이드오프인지 몰랐을 뿐입니다.

이제는 압니다.

모든 권리 보유, Dewpeche Private Limited. 정보 제공 목적의 링크를 제공했으며, 어떤 형태의 보증/지지를 시사하지 않습니다. 이 뉴스레터에 표현된 모든 견해는 제 개인 의견이며, 과거·현재·미래의 고용주들의 의견을 대표하지 않습니다.