The Shape and Feel of the Post-AI Data Stack

Author: Ian Macomber (Ramp) | Source: iandmacomber.com | Published: 2026-08-30

한 줄 요약

AI는 분석 생산을 싸게 만들지만 현실에 합의하는 것을 싸게 만들지 않는다 — 데이터 스택 진화의 매 단계가 데이터 사이언티스트의 blast radius를 넓혀왔고, post-AI 시대의 희소 자원은 consensus이며 그것은 엔지니어링·측정할 수 있다.

핵심 주장/내용

네 시대의 타임라인 — 각 단계가 하나의 제약을 없애고 새 희소 자원을 만들었다:

시대	없앤 제약	데이터 사이언티스트의 역할
Pre-modern (~2013)	— (데이터 moat, small data, 정형 데이터에 갇힘)	한 서버에 맞는 질문만
Cloud DW (~2016)	스토리지·컴퓨트·semi-structured	”회사의 모든 데이터”로 범위 확장
Modern Data Stack + Reverse ETL (~2020)	파이프라인 구축 마찰	reporter → operator
Post-AI (~2026)	분석·대시보드 생산 비용 ≈ 0	회사의 현실을 만드는 사람

Pre-modern (~2013) — 세 가지 잔혹한 마찰: Wayfair의 BI가 Waltham, MA에 호스팅된 SQL Server 2012 위에서 돌았고 DBA가 가끔 I-90을 30분 운전해 서버를 추가하러 갔다
- 데이터 moat — 모든 데이터가 같은 DB에 못 들어갔다. DB 간 쿼리는 엄청난 massaging 없이는 동작하지 않았다 (linked server 호출은 영원히 걸리고 자주 실패하고 쿼리 최적화 혜택이 없고 접근하려면 DBA의 handholding이 필요)
- 웹 애널리틱스 — 초기 SQL dialect가 semi-structured VARIANT/JSON을 다루지 못했다. 웹 트래픽이 제품 분석의 핵심인데 거의 항상 JSON으로 표현되므로 기능적으로 웹 애널리틱스 질문에 답할 수 없었다
- 빅데이터 — 1천만~1억 행 사이 어딘가에서 분석이 멈췄다 (그리고 다른 모든 사람의 쿼리도 함께 죽였다). SQL Server 2012는 단일 노드였고 컴퓨트·스토리지 확장이 불가능했으며 컬럼 집계가 아니라 빠른 행 단위 갱신을 위해 만들어졌다
- 구체적 사례: “카드 발급사가 지불의사의 유의미한 예측 변수인가? BIN 3717(AMEX Platinum) 고객이 가격에 덜 민감한가?” — 결제 데이터가 주문 데이터와 다른 물리 DB에 있었고, semi-structured DB가 없어 클릭스트림을 저장하지도 로깅하지도 않았고, 있었다 해도 Cyber Monday 하루의 상품 페이지뷰(1억+) 쿼리는 실패하고 나머지 리포팅까지 죽였을 것
Cloud Data Warehouse (~2016): Snowflake/Redshift/GCP가 온프렘 OLTP SQL Server가 결코 못 하던 세 문제를 풀었다 — 스토리지 무한 확장(“모든 데이터를 한곳에”를 파이프드림에서 해결된 문제로), 컴퓨트 무한·수평 확장(1억+ 행 분석을 핵심 재무 리포트 쿼리와 별도 리소스로), semi-structured 네이티브 읽기(웹 트래픽 접근 가능, funnel 분석 주류화). “훌륭한 데이터 사이언티스트는 비즈니스에 무엇이 가장 중요한지 말해준다. 그건 모든 데이터를 쓸 수 있을 때만 가능하다”
Modern Data Stack (~2020) — 기술보다 느낌: Wayfair가 Hadoop을 도입할 때 Cloudera 구현팀 + 자사 데이터 엔지니어 3명 + 4개월이 걸렸고, 새 언어를 배우고 JVM을 공격적으로 관리해야 했으며 큰 쿼리 하나가 모두를 위해 그것을 깨뜨렸다(항상 일어났다)
- 대조적으로 2020년의 마법: Postgres DB와 몇 개 SaaS 앱과 PMF가 있는 회사의 CTO라면 head of data를 뽑아 신용카드와 API 자격증명을 주고 점심때까지 리포팅이 돌아가기를 정당하게 기대할 수 있었다. SQL만 알면 됐다
- ETL은 새 개념이 아니었지만, 새 데이터를 얻는 것은 늘 엔지니어링에 파이프라인을 만들어달라고 구걸하는 것을 요구했다. 데이터 사이언티스트가 그냥… LinkedIn Ads 데이터를 Zendesk 데이터 옆에, 앱 데이터 옆에, 결제 데이터 옆에 가질 수 있다는 것이 범위를 또 넓혔다. 특히 “있으면 좋은” 분석에서 — Meta의 “No Founder Credit Checks” 광고로 들어온 고객의 신용 손실이 더 나쁘다거나, 추천으로 온 고객이 Zendesk 티켓을 덜 낸다거나. 데이터 팀은 “nice-to-have” 데이터를 위해 엔지니어링 팀에 ETL을 구걸할 수 없다. 관리형 ETL이 Fivetran에서 버튼을 클릭하고 월말에 지불하는 것으로 바꿨다
- ETL이 볼 수 있는 것을 넓혔다면 Reverse ETL은 할 수 있는 것을 넓혔다. AMEX 가격 민감도 예로 돌아가면, 예전에는 결론이 프레젠테이션의 슬라이드 한 장이었고 누군가 원래 인사이트와 비슷해 보이는 후속 조치를 집어가기를 바랄 뿐이었다. Reverse ETL이 데이터 사이언스를 리포팅에서 운영으로 옮겼다 — 갑자기 Iterable에서 라이프사이클 이메일을 트리거하고, Salesforce에서 고객 세그먼트를 갱신하고, 핵심 제품의 모습과 느낌을 바꿀 수 있게 됐다
Post-AI (~2026) — 다섯 가지 요구사항:

1. Agent-Readable Artifacts

인간은 더 이상 데이터 팀 산출물의 주 소비자가 아니고, 대시보드와 분석은 더 이상 최종 산물이 아니다. 산출물이 agentic 인터페이스에 소비되고 LLM이 인간의 눈과 의사결정을 위해 재포장한다. 대시보드는 스프린트 플래닝에서 링크하는 목적지이기를 멈추고, 에이전트가 분해하고 재조립할 수 있는 사실·계약·설명의 저장소가 된다.

SNL 유비: 예전엔 main thing이 main thing이었다 — 팟캐스트를 통째로 듣고, SNL을 보고, 월요일마다 북마크한 Looker 대시보드를 열었다. opt-in했다. 오늘날 SNL의 주 단위는 피드에 수동적으로 나타난다(YouTube의 전체 skit, TikTok의 부분). 사람들은 LLM이 리뷰하고 알고리즘이 노출한 클립으로 팟캐스트를 발견하고, 원본은 결코 안 볼 수도 있다. SNL은 에이전트와 알고리즘에 의해 쪼개지고 재조립되도록 스스로를 재발명했다
2027년에는 CPO가 매주 모든 제품 런칭 대시보드를 스캔하는, 에이전트가 배포한 서브에이전트를 통해 팀의 제품 런칭을 알게 될 것이다. 마케터가 AEO/SEO에 집착하고 X 사고 리더가 추천 알고리즘을 해킹하듯 데이터 사이언티스트도 같은 것을 배우게 된다 — 웹사이트가 Google에 최적화하듯 LLM에 legible한 데이터 제품을 만드는 것
구체적으로: 대시보드의 raw code·필터·오너·진입점·폴더 구조·시각화·렌더된 값을 LLM 소비용 포맷으로 선언 — 데이터 제품별 llms.txt가 마크다운으로 렌더링. 그리고 provenance 지침 — 더 깊이 들어가는 법, 대시보드 쿼리가 다른 데이터 모델·코드와 어떻게 관계되는지, 비즈니스(프로젝트·조직도·제품 로드맵·회사 목표)와 어떻게 관계되는지
SEO는 어렵다. Google 알고리즘이 통제할 수 없는 블랙박스이기 때문. 사내 데이터 팀에게는 LLM 판독 가능한 데이터 산출물을 만들면서 동시에 그것을 소비하는 전사 에이전트도 만드는 사치가 있다. Ramp는 사내 BI 도구와 @Research 에이전트를 손잡고 함께 설계했다 — 대시보드가 사람에게는 React 인터페이스로, 에이전트에게는 마크다운 descriptor, fetchable SQL, 캐시된 값의 .csv 로 표현된다
“CPO가 자기 에이전트에게 서브에이전트한테 제품 런칭이 어땠는지 물어보라고 할 때 당신의 답이 나타나게 하라”

2. Agent-Operable Tools

어떤 데이터 사이언티스트도 웹 UI를 클릭하고 다니고 싶어하지 않고, 곧 모든 비즈니스 이해관계자에게도 그럴 것이다.

팀은 예전에 하던 클릭을 자동화하지 않을 것이다. 대신 에이전트가 코드로 직접 조작할 수 있는 것에 닿을 때까지 작업을 스택 아래로 밀어내고, agent-operable하지 않은 벤더를 그만 쓴다
갱신 시점에 명백해진다 — 데이터 팀이 거기서 만들기를 멈추고 재무 팀이 거기 의존하기를 멈추면 BI 도구를 churn하기 쉽다. 마찬가지로 API/MCP를 일급 운영체제로 노출하지 않거나 UI-우선 인터페이스·워크플로에 가두는 신규 벤더는 고려조차 하지 않게 된다
“난 정말 당신의 에이전트를 쓰고 싶지 않다. 내 에이전트로 당신의 것을 쓰고 싶다.” — @ASpittel
당신의 스택은 에이전트가 조작할 수 있어야 한다. 사실 어떤 에이전트든 조작할 수 있어야 한다

3. Agent-Agnostic Context

end-to-end 솔루션이 되고 싶어하는 post-AI 도구 코호트가 있다. 그들이 요구하는 것: 시맨틱 레이어와 비즈니스 컨텍스트 전부를 그들 도구의 독점 언어로 작성 / 모든 모델·대시보드·분석을 그들 도구에만 보관 / 모든 이해관계자를 그들 도구로만 보내기 / 사용자 활동을 그들이 당신의 데이터와 회사를 이해하는 데 쓰게 허용.

없어서는 안 될 존재가 되려는 벤더에게는 말이 되지만, 하는 쪽에게는 매우 어리석은 일이다
강요되는 선택: 한 벤더를 고르고 비즈니스의 모든 컨텍스트와 사용자를 그들 도구에 넣어 그 벤더와 인터페이스의 미래에 베팅을 잠그거나 — 아니면 컨텍스트와 커넥터를 최대한 headless하게 만들어, 동료를 쓰든 코딩 에이전트를 쓰든 BI 도구를 쓰든 Slack 봇을 쓰든 같은 답을 얻게 하거나
당신의 지능을 남의 인터페이스에 가두지 마라. 모델·harness·인터페이스가 충분히 빠르게 움직여서 지금 회사의 사용자 선호가 한 분기 뒤엔 다르게 보일 것이다

4. Agent-Testable Consensus

Pre-AI에는 데이터 팀이 조직화와 희소성으로 consensus를 만들었다. 대시보드가 조직도와 일치하는 중첩 폴더에 정리되어 있었고, 회사가 어떻게 돌아가는지 알고 싶으면 폴더 구조를 훑는 것에서 시작했다. 그리고 대시보드 만들기는 오래 걸렸다! 데이터 팀은 계측·ETL 파이프라인·dbt 모델·LookML PR을 배포한 다음에야 클릭 하나하나로 대시보드를 손수 제작했다. BI 도구의 위계가 회사가 대시보드를 만들고 유지할 만큼 신경 쓰는 모든 것을 암묵적으로 전달했다.

오늘날 병목은 더 이상 코드 작성과 대시보드 제작이 아니고, 인간은 UI 폴더 구조를 클릭해 데이터 제품을 탐색하지 않는다. 제품 도메인 전문가 데이터 사이언티스트가 깊이 아는 영역에 대해 분석하고 대시보드를 띄우는 게 그 어느 때보다 쉬운데 — 다른 모든 사람에게도 똑같이 쉽다. 모든 사람이 조금씩 다른 질문을 하고, 다른 고객 슬라이스를 보고, 다른 지표 정의를 쓰고, 다른 숫자에 도달하고, 다른 결론을 낼 수 있다
희소 자원은 consensus다. 모호한 용어처럼 들리지만 엔지니어링하고, 단언하고, 측정할 수 있다
초기 테스트/반복 루프:
1. 지난 분기 이사회 자료의 모든 지표를 가져온다
2. 각 지표에 대해 질문한다 (예: “활성 고객이 몇 명인가?“) — 회사가 쓰는 모든 인터페이스 × 모델 조합으로 (코딩 에이전트, 동료, BI 벤더 등)
3. 서로 다른 답이 몇 개 돌아오는지 센다
4. =1이면 축하. >1이면 모든 trace를 읽어 불일치를 파악하고, 수정을 배포하고, 2부터 반복
인터페이스 선택이 답이나 과정을 바꾸지 않을 때 consensus를 달성한 것이다
Ramp의 사내 research harness가 이렇게 동작한다. 어떤 model × interface가 최고인지의 테스트라기보다, 우리 지침이 어떤 model × interface든 같은 답을 얻을 만큼 명확한지의 테스트다. 모델이 틀린 적은 없다고 가정하라 — 당신의 컨텍스트가 덜 명세되었을 뿐이다

“consensus divergence rate” — 어디서 물었는지와 어떤 모델을 썼는지에 따라 답이나 trace가 달라지는 질문의 비율. 이사회 자료와 C-Suite가 매주 보는 것에 대해서는 0이어야 한다

results = ask_everywhere(
    interfaces=["coworker", "coding_agent", "bi", "slack"],
    question="What was net revenue retention last quarter?",
)
assert same_metric_definition(results)
assert values_within_tolerance(results, relative=0.00001)
assert same_authorization_outcome(results)
assert required_evidence_used(results)

5. Compounding Improvements — eval로 컨텍스트를 복리로

Ramp Research를 만들 때 처음엔 모델이 맞는 답을 냈는지에 집중했다. 그런데 trace를 읽는 것이 출력을 보는 것보다 훨씬 도움이 됐다 — 맞은 실행은 관련 도메인 문서를 찾았고, 틀린 실행은 종종 문서를 건너뛰고, 틀린 테이블을 고르고, 틀린 지표와 필터를 썼다.

실패 trace가 research harness에 분석 전 도메인 문서를 강제로 읽히게 할 확신을 줬다. 그리고 데이터 팀이 포괄적 문서 + eval을 쓰는 데 오후를 떼어낼 mandate를 주었고, 앞으로 둘 다 직무 책임의 일부로 간주하게 했다. eval은 올바른 컨텍스트와 도구가 실제로 사용되었는지, 그것을 쓴 것이 올바른 결과를 냈는지 관찰하는 렌즈다
eval이 최종 답과 그 뒤의 증거를 둘 다 테스트한다. 답은 canonical SQL 쿼리의 출력이거나 검증 가능하고 결정적으로 참인 것. 증거는 우리가 신뢰하는 경로를 명시한다 — 관련 도메인 문서 읽기, 특정 semantic view 사용, canonical 대시보드로 이동, 결과 검사
불완전한 과정으로 도달한 올바른 숫자는 blessed path로 생산된 올바른 숫자만큼 가치 있지 않다 (그리고 다음 모델 릴리스에서 깨질 가능성이 훨씬 높다)
측정 가능하게 만들기 위해 trace를 정규화(READ_DOMAIN_DOC, VIEW_DASHBOARD, READ_SEMANTIC_VIEW, EXECUTE_SQL, SYNTHESIZE_ANSWER)하고 매 실행마다 주변 시스템을 스냅샷한다 — 모델, 프롬프트, 도구, 코드, 평가 코퍼스, 그리고 당시 가용했던 지식의 해시
eval이 실패하면 수리에 모델 + 에이전트 harness에 대한 깊은 이해와 회사 특유의 직관이 둘 다 필요하다 — 도메인 컨텍스트가 모호했나? 데이터 모델이 불완전하거나 에이전트 관할 밖 코드에 정의되었나? 사용자가 필요한 접근권을 갖고 있었나?
새 모델이 너무 자주 나와 다음 frontier가 문제를 풀어주기를 바라기 쉽지만, 진전은 컨텍스트가 빠진 harness에 frontier 토큰을 태우는 게 아니라 eval의 “failure taxonomy”를 만들고 태워 없애는 것으로 이룬다

Beyond SQL — 의미를 위한 pre-modeling

Looker·Tableau UI로 수년 고통받은 이해관계자들은 “SQL 모양의 질문”이 무엇인지에 대한 직관을 발달시켰다. BI 도구가 내부적으로 Snowflake 위에서 돌고, Snowflake는 SQL이고, SQL은 숫자에 훌륭하다 — 집계·필터·그룹화. 하지만 “Gong 콜을 확인해봐, 왜 건설 버티컬에서 딜을 잃고 있지?” 나 “Travel pod의 north star 지표가 뭐지?” 에는 전혀 맞는 도구가 아니다.

이해관계자를 SQL 모양의 질문으로 스스로를 제한하도록 훈련시키지 마라. 대신 같은 진입점으로 정형·비정형 질문에 유연하게 답하도록 스택을 세팅하라
가능하지만 사전 설계가 필요하다. Snowflake의 raw 트랜잭션 테이블에서 1억+ 행 집계는 사소하고 싸고 빠르지만, LLM으로 10만 개 raw Gong 콜 전사를 파싱하는 것은 사소하지 않고 비싸고 느리다
채택한 해법은 데이터 pre-modeling과 매우 닮았다 — 다만 shape이 아니라 meaning에 대해서다. 전체 비정형 데이터셋에 AI tagger를 한 번, 오프라인으로 돌리고, 사람들이 묻는 질문에서 관찰한 구조로 출력을 다시 쓴다. Gong 콜에는 loss_reason, objection_type, mentioned_competitor를 추적한다 — 카드 트랜잭션 데이터 모델이 정규화된 vendor·merchant category 컬럼을 가져 어떤 미래 분석이든 GROUP BY할 수 있는 것과 같은 방식
비정형 데이터를 파싱하는 법은 사람들이 묻는 질문 유형을 관찰한 다음 그 요청을 미래 질문에 대해 더 싸고 확장 가능하게 만드는 것으로 배운다
비싼 방법을 먼저 겪었다 — 모든 opportunity에 대해 Gong 콜과 이메일을 처리해 free-text 필드를 Salesforce에 다시 쓰는 벤더를 도입했다. 어느 시점에 벤더의 태깅 분포가 경고 없이 바뀌었고, 그들이 설명하거나 디버그하거나 되돌릴 수 없는 방식이었다. 핵심 win/loss rate 리포팅을 재현하거나 갱신할 수 없었다
- 세일즈 인텔리전스의 복리를 벤더에 위임하면 이런 일이 생긴다. 최선의 경우 당신이 소유하지 못하고, 최악의 경우 그들이 깨뜨리는데 당신이 고칠 수 없다
- 지금은 자체 인프라 위 버전 관리된 프롬프트로 돈다. 실무자가 정의한 택소노미가 오류마다 개선되고 제품 런칭마다 갱신되며, 세일즈 팀 질문을 리뷰해 어떤 필드를 공유 모델로 승격할지 정한다. 모든 갱신이 복리로 쌓이는 지능
왜 시맨틱 레이어가 지금 주류가 되었나 — 두 가지 이유:
1. 데이터 팀과 Snowflake/Fivetran 청구서가 없는 회사들(압도적 다수)이 coworking 도구와 에이전트를 벤더에 직접 꽂는 것으로 AI 여정을 시작한다. 이것이 ETL과 데이터 모델링 단계를 건너뛴다. 개인은 빠르게 일하게 하지만 조직 전체에서 아무것도 일관되지 않은 재현성 위기로 이어진다. 거의 모든 Applied AI 솔루션 피치의 첫 단계가 forward-deployed 팀이 당신의 비즈니스를 기술하는 시맨틱 레이어를 만드는 것인 이유
2. “intelligence exhaust”에 가치가 있다 (Satya의 The Reverse Information Paradox) — 모든 “이거 이상한데”, 모든 지표 명료화. 컨텍스트는 당신의 네 벽 안에서 복리로 쌓이거나, 남의 벽 안에서 쌓인다. 회사의 시맨틱 레이어와 그 위의 온톨로지가 사내 AI 생산성의 핵심이다 — 데이터 사이언티스트의 모든 수정이 축적된 학습이고, 오류를 잡고 과정을 추적하고 수정을 전사에 배포하는 인프라를 만들 때만 복리가 된다
- 이것이 시맨틱 레이어 없이 agentic 벤더를 raw 데이터에 직접 연결하는 것에 대한 최고의 반론이다. 답이 틀릴 수 있다는 것만이 아니라, 모든 수정이 당신의 스택을 고치는 대신 벤더에게 당신의 비즈니스를 가르치는 데 간다는 것. 토큰에 전례 없는 돈을 쓸 거라면 회사의 제도적 지식이 남의 학습 데이터가 아니라 당신의 자산으로 복리가 되게 해야 한다
- 좋은 시맨틱 레이어는 모든 tribal knowledge(“사실 Card TPV는 45일 이후 환불을 제외한다”, “건설 버티컬 매핑이 2025 Q2에 바뀌었다”), 지표에 대한 모든 판단, 모든 north star 지표·drumbeat·product pod을 인코딩해 직원이 첫날부터 만지는 모든 시스템으로 밀어 넣는다. 신입 SWE 인턴부터 노련한 세일즈 임원까지 time-to-productive가 줄고, 새 제품 영역을 배우는 IC가 백지에서 시작하지 않고 앞서 온 모든 사람의 판단을 상속한다

주요 수치 / 사실

데이터 사이언스 라이프사이클: Reality → Data Capture → Context/Modeling → Analysis → Consensus → Decision/Action. 각 시대가 하나의 제약을 없애고 새로운 희소 자원을 만들었다
post-AI 시대는 대시보드 제작과 데이터 질문 비용을 거의 0으로 줄인다. 데이터 출력이 풍부해지면서 데이터 분석이 상품화된다. 이제 희소 자원은 consensus다. Pre-AI에는 consensus가 희소성에서 발현했고(비싸게 손수 만든 대시보드가 조직도 폴더에 중첩), Post-AI에는 consensus가 엔지니어링하는 대상이다
훌륭한 데이터 사이언티스트의 시험은 더 이상 분석 하나를 탁월하게 수행하는 능력이 아니다. 자기 판단을 인프라에 인코딩해 지식을 스케일하는 능력, 그래서 모든 미래의 에이전트·의사결정·직원이 그 데이터 사이언티스트의 “무엇이 참이고 무엇이 중요하고 왜인지”의 표현에서 출발하게 하는 능력이다
2027년의 의사결정은 대시보드를 한 번도 열지 않고 “대시보드를 읽은” 임원들이 내릴 것이다 — 수백만 명이 Saturday Night Live를 보지 않고 SNL 스케치를 보는 것과 같은 방식으로. 데이터 제품이 어떻게 발견되고 잘리고 재조합되고 전달될지 정확히 예측할 수 없고 사용자가 어떤 인터페이스에 있을지조차 모른다. post-AI 데이터 사이언티스트의 일은 편집을 거쳐도 의미가 살아남게 하는 것이다

Data Eng Wiki

탐색기

The Shape and Feel of the Post-AI Data Stack

The Shape and Feel of the Post-AI Data Stack

한 줄 요약

핵심 주장/내용

1. Agent-Readable Artifacts

2. Agent-Operable Tools

3. Agent-Agnostic Context

4. Agent-Testable Consensus

5. Compounding Improvements — eval로 컨텍스트를 복리로

Beyond SQL — 의미를 위한 pre-modeling

주요 수치 / 사실

관련 위키

그래프 뷰

목차

백링크