Data Eng Wiki

Consensus Engineering

19 min read

Consensus Engineering

“AI는 분석 생산을 싸게 만든다. 현실에 합의하는 것을 싸게 만들지는 않는다.”

핵심 개념

데이터 스택의 각 시대는 하나의 제약을 없애고 새로운 희소 자원을 만들었다.

시대없앤 제약새 희소 자원
Pre-modern (~2013)—데이터에 닿는 것 자체
Cloud DW (~2016)스토리지·컴퓨트·semi-structured파이프라인 구축 능력
Modern Data Stack (~2020)ETL 마찰, Reverse ETL로 실행까지분석을 만드는 시간
Post-AI (~2026)분석·대시보드 생산 비용 ≈ 0consensus

Pre-AI에는 consensus가 희소성에서 자연 발생했다. 대시보드는 조직도와 일치하는 중첩 폴더에 정리되어 있었고, 만드는 데 오래 걸렸다 — 계측·ETL·dbt 모델·LookML PR을 배포한 다음에야 클릭 하나하나로 손수 제작했다. BI 도구의 위계가 회사가 대시보드를 만들고 유지할 만큼 신경 쓰는 모든 것을 암묵적으로 전달했다.

Post-AI에는 그 마찰이 사라졌다. 제품 도메인 전문가가 깊이 아는 영역에 대해 분석하고 대시보드를 띄우는 게 그 어느 때보다 쉬운데 — 다른 모든 사람에게도 똑같이 쉽다. 모든 사람이 조금씩 다른 질문을 하고, 다른 슬라이스를 보고, 다른 지표 정의를 쓰고, 다른 숫자에 도달하고, 다른 결론을 낸다.

consensus는 모호한 용어처럼 들리지만 엔지니어링하고, 단언하고, 측정할 수 있다.

측정 — consensus divergence rate

가장 실용적인 기여는 consensus를 지표로 만든 것이다.

테스트 루프:

  1. 지난 분기 이사회 자료의 모든 지표를 가져온다
  2. 각 지표에 대해 질문한다 (“활성 고객이 몇 명인가?“) — 회사가 쓰는 모든 인터페이스 × 모델 조합으로 (코딩 에이전트, 동료, BI 벤더, Slack 봇…)
  3. 서로 다른 답이 몇 개 돌아오는지 센다
  4. =1이면 축하. >1이면 모든 trace를 읽어 불일치를 파악하고, 수정을 배포하고, 2부터 반복

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)

결정적 프레이밍 전환:

어떤 model × interface가 최고인지의 테스트가 아니라, 우리 지침이 어떤 model × interface든 같은 답을 얻을 만큼 명확한지의 테스트다. 모델이 틀린 적은 없다고 가정하라 — 당신의 컨텍스트가 덜 명세되었을 뿐이다.

이것이 LLM Evaluation의 일반적 관점(“어느 모델이 정확한가”)을 뒤집는다. 정확도가 아니라 재현성을 측정한다.

답만이 아니라 경로를 평가한다

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

불완전한 과정으로 도달한 올바른 숫자는 blessed path로 생산된 올바른 숫자만큼 가치 있지 않다 — 그리고 다음 모델 릴리스에서 깨질 가능성이 훨씬 높다.

측정 가능하게 만드는 방법:

  • trace를 정규화한다 — READ_DOMAIN_DOC, VIEW_DASHBOARD, READ_SEMANTIC_VIEW, EXECUTE_SQL, SYNTHESIZE_ANSWER
  • 매 실행마다 주변 시스템을 스냅샷한다 — 모델, 프롬프트, 도구, 코드, 평가 코퍼스, 당시 가용했던 지식의 해시

eval 실패의 수리는 두 가지를 동시에 요구한다 — 모델·harness에 대한 깊은 이해 그리고 회사 특유의 직관: 도메인 컨텍스트가 모호했나? 데이터 모델이 불완전하거나 에이전트 관할 밖에 정의되었나? 사용자가 필요한 접근권을 가졌나?

새 모델이 너무 자주 나와 다음 frontier가 문제를 풀어주기를 바라기 쉽지만, 진전은 컨텍스트가 빠진 harness에 frontier 토큰을 태우는 게 아니라 eval의 “failure taxonomy”를 만들고 태워 없애는 것으로 이룬다.

이 실패 trace가 만든 조직적 효과가 기술적 효과만큼 중요하다 — 그것이 데이터 팀이 포괄적 문서와 eval을 쓰는 데 시간을 떼어낼 mandate를 주었고, 둘 다 앞으로 직무 책임의 일부가 되었다.

전제 조건 1 — agent-readable artifacts

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

유비: SNL이 스스로를 재발명한 방식. 예전엔 팟캐스트를 통째로 듣고 SNL을 보고 월요일마다 북마크한 대시보드를 열었다 — opt-in했다. 오늘날 주 단위는 피드에 수동적으로 나타나고, 사람들은 LLM이 리뷰하고 알고리즘이 노출한 클립으로 원본을 발견하며, 원본은 결코 안 볼 수도 있다.

2027년에는 CPO가 매주 모든 제품 런칭 대시보드를 스캔하는, 에이전트가 배포한 서브에이전트를 통해 팀의 런칭을 알게 될 것이다.

구체적 실천:

  • 데이터 제품별 llms.txt — 대시보드의 raw code·필터·오너·진입점·폴더 구조·시각화·렌더된 값을 마크다운으로 선언
  • provenance 지침 — 더 깊이 들어가는 법, 이 쿼리가 다른 모델·코드·비즈니스(프로젝트·조직도·로드맵·목표)와 어떻게 관계되는지
  • 사람용 UI와 에이전트용 표현을 함께 설계 — Ramp는 React 인터페이스와 나란히 마크다운 descriptor, fetchable SQL, 캐시된 .csv를 낸다

SEO와의 결정적 차이: Google 알고리즘은 통제할 수 없는 블랙박스지만, 사내 데이터 팀은 LLM 판독 가능한 산출물을 만들면서 동시에 그것을 소비하는 전사 에이전트도 만든다. 양쪽을 다 소유하는 사치가 있다.

전제 조건 2 — agent-operable, agent-agnostic

어떤 데이터 사이언티스트도 웹 UI를 클릭하고 다니고 싶어하지 않고, 곧 모든 이해관계자에게도 그럴 것이다. 팀은 예전 클릭을 자동화하는 대신, 에이전트가 코드로 직접 조작할 수 있는 것에 닿을 때까지 작업을 스택 아래로 밀어내고 agent-operable하지 않은 벤더를 그만 쓴다.

“난 정말 당신의 에이전트를 쓰고 싶지 않다. 내 에이전트로 당신의 것을 쓰고 싶다.”

갱신 시점에 명백해진다 — 데이터 팀이 거기서 만들기를 멈추고 재무 팀이 의존하기를 멈추면 BI 도구를 churn하기 쉽다.

벤더 lock-in의 새로운 형태: end-to-end를 표방하는 post-AI 도구들이 요구하는 것 — 시맨틱 레이어 전부를 그들의 독점 언어로, 모든 모델·대시보드를 그들 도구에만, 모든 이해관계자를 그들 도구로만, 그리고 사용자 활동을 그들이 당신의 비즈니스를 이해하는 데 쓰게.

당신의 지능을 남의 인터페이스에 가두지 마라. 모델·harness·인터페이스가 충분히 빠르게 움직여서 지금의 사용자 선호는 한 분기 뒤엔 다르게 보일 것이다.

대안: 컨텍스트와 커넥터를 최대한 headless하게 만들어 동료를 쓰든 코딩 에이전트를 쓰든 BI 도구를 쓰든 Slack 봇을 쓰든 같은 답을 얻게 한다. 이것이 곧 consensus 요구사항 그 자체다.

전제 조건 3 — SQL 모양이 아닌 질문에도 답하기

이해관계자들은 수년의 Looker·Tableau 경험으로 “SQL 모양의 질문”이 무엇인지에 대한 직관을 발달시켰다. SQL은 숫자에 훌륭하다 — 집계·필터·그룹화. 하지만 “Gong 콜을 확인해봐, 왜 건설 버티컬에서 딜을 잃고 있지?” 에는 전혀 맞지 않는다.

이해관계자를 SQL 모양의 질문으로 스스로를 제한하도록 훈련시키지 마라.

비용 비대칭이 핵심 제약이다: Snowflake에서 1억+ 행 집계는 사소하고 싸고 빠르지만, LLM으로 10만 개 Gong 콜 전사를 파싱하는 것은 사소하지 않고 비싸고 느리다.

해법 — 의미를 위한 pre-modeling: 전체 비정형 데이터셋에 AI tagger를 한 번, 오프라인으로 돌리고, 사람들이 묻는 질문에서 관찰한 구조로 출력을 다시 쓴다. Gong 콜에 loss_reason, objection_type, mentioned_competitor — 카드 트랜잭션 모델이 정규화된 vendor·merchant category 컬럼을 가져 어떤 미래 분석이든 GROUP BY할 수 있는 것과 같은 방식이다.

비정형 데이터를 파싱하는 법은 사람들이 묻는 질문 유형을 관찰한 다음 그 요청을 미래 질문에 대해 더 싸고 확장 가능하게 만드는 것으로 배운다.

⚠️ 이것을 벤더에 위임하지 마라. Ramp는 Gong 콜·이메일을 처리해 Salesforce에 free-text를 쓰는 벤더를 먼저 썼는데, 어느 시점에 벤더의 태깅 분포가 경고 없이 바뀌었고 그들이 설명하거나 디버그하거나 되돌릴 수 없었다. 핵심 win/loss rate 리포팅을 재현할 수 없었다.

세일즈 인텔리전스의 복리를 벤더에 위임하면 이런 일이 생긴다. 최선의 경우 당신이 소유하지 못하고, 최악의 경우 그들이 깨뜨리는데 당신이 고칠 수 없다.

지금은 자체 인프라 위 버전 관리된 프롬프트 + 실무자가 정의한 택소노미로 돈다. 오류마다 개선되고 제품 런칭마다 갱신되며, 세일즈 팀 질문을 리뷰해 어떤 필드를 공유 모델로 승격할지 정한다.

왜 시맨틱 레이어가 C-suite 대화에 올라왔나

두 가지 이유:

  1. 데이터 팀이 없는 회사들(압도적 다수)이 에이전트를 벤더에 직접 꽂는 것으로 AI 여정을 시작한다. 이것이 ETL과 데이터 모델링을 건너뛴다. 개인은 빠르게 일하지만 조직 전체에서 아무것도 일관되지 않은 재현성 위기로 이어진다. 거의 모든 Applied AI 피치의 첫 단계가 forward-deployed 팀이 시맨틱 레이어를 만드는 것인 이유

  2. “intelligence exhaust”에 가치가 있다 — 모든 “이거 이상한데”, 모든 지표 명료화. 컨텍스트는 당신의 네 벽 안에서 복리로 쌓이거나, 남의 벽 안에서 쌓인다.

    시맨틱 레이어 없이 agentic 벤더를 raw 데이터에 직접 연결하는 것에 대한 최고의 반론: 답이 틀릴 수 있다는 것만이 아니라, 모든 수정이 당신의 스택을 고치는 대신 벤더에게 당신의 비즈니스를 가르치는 데 간다는 것.

좋은 시맨틱 레이어가 인코딩하는 것: 모든 tribal knowledge(“Card TPV는 45일 이후 환불을 제외한다”, “건설 버티컬 매핑이 2025 Q2에 바뀌었다”), 지표에 대한 모든 판단, north star·drumbeat·product pod. 직원이 첫날부터 만지는 모든 시스템으로 밀어 넣는다.

효과: 신입 SWE 인턴부터 노련한 세일즈 임원까지 time-to-productive가 줄고, 새 영역을 배우는 IC가 백지에서 시작하지 않고 앞서 온 모든 사람의 판단을 상속한다.

데이터 사이언티스트 역할의 재정의

훌륭한 데이터 사이언티스트의 시험은 더 이상 분석 하나를 탁월하게 수행하는 능력이 아니다. 자기 판단을 인프라에 인코딩해 지식을 스케일하는 능력, 그래서 모든 미래의 에이전트·의사결정·직원이 그 사람의 “무엇이 참이고 무엇이 중요하고 왜인지”의 표현에서 출발하게 하는 능력이다.

2027년의 의사결정은 대시보드를 한 번도 열지 않고 “대시보드를 읽은” 임원들이 내릴 것이다 — 수백만 명이 Saturday Night Live를 보지 않고 SNL 스케치를 보는 것과 같이. 데이터 제품이 어떻게 발견되고 잘리고 재조합될지, 사용자가 어떤 인터페이스에 있을지 예측할 수 없다.

post-AI 데이터 사이언티스트의 일은 편집을 거쳐도 의미가 살아남게 하는 것이다.

실행 체크리스트

  • 이사회 지표부터 — 가장 자주 보이고 divergence 비용이 가장 큰 것
  • 모든 인터페이스 × 모델 조합으로 ask_everywhere 하네스 구축
  • 답만이 아니라 trace를 정규화하고 저장
  • eval failure taxonomy를 만들고 태워 없애기
  • 데이터 제품에 llms.txt 계열 기계 판독 표현 추가
  • 벤더가 API/MCP를 일급으로 노출하는지를 조달 기준에 넣기
  • 비정형 데이터에 대해 질문 로그 → 택소노미 → 오프라인 태깅 루프 구축
  • 태깅·정의를 버전 관리된 자체 자산으로 유지 (벤더 위임 금지)

연관 개념

Source: The Shape and Feel of the Post-AI Data Stack

그래프 뷰

백링크