• 데이터 팀의 가치는 파이프라인·스키마·대시보드의 생산량이 아니라
  조직의 의사결정 변화에서 생기며, 데이터와 행동 사이에는 해석 계층인 관점(Perspective)이 필요함
  Data-Perspective-Action은 신뢰할 수 있는 데이터를 구축하고 비즈니스 맥락에 따라 해석한 뒤, 구체적인 행동을 지속해서 제안하는 운영 모델임
• 2026년 AI & Data Leadership Executive Benchmark Survey에서 데이터·AI 리더의
  93% 가 도입의 핵심 장벽으로 문화와 변화 관리를 꼽았고, 기술을 지목한 비율은 7%에 그침
• 주간 원페이지 문서, 핵심 지표 체계, 이해관계자와의 공동 설계, 모든 분석에 행동 권고를 붙이는 규칙으로
  관점을 습관화하고 실제 결정까지 연결할 수 있음
• AI가 파이프라인·초기 분석·대시보드를 생성할수록
  도메인 지식과 신뢰가 차별점이 되므로, 데이터 팀은 정확한 결과물 제공을 넘어 공동의 현실을 구축해야 함

Data-Perspective-Action이 필요한 이유

• 조직의 가치는 데이터 산출물이 아니라
  결정에서 만들어지며, 원시 출력과 실제 행동 사이에는 해석 계층인 관점이 필요함
• 기술적으로 유능하고 데이터가 정확한 팀도 요청 처리, 티켓 종료, 대시보드 배포처럼 생산량만 최적화하면 조직의 의사결정과 무관해질 수 있음
• 잘 설계된 데이터 시스템도 업무와 결정의 연결을 습관화하지 않으면 우선순위에서 밀리고, 예산을 잃거나 조직 개편으로 사라질 수 있음
  Data-Perspective-Action은 데이터에서 의견을 담은 해석을 거쳐 구체적인 결정으로 이어지는 과정을 의도적으로 반복하는 프레임워크임

프레임워크의 출발점

• 광고 대행사의 월간 보고는 작성에 4주가 걸려 전달될 때 이미 낡은 상태였지만, 워크플로를 약 하루 만에 자동화하면서 남은 시간을 예측 모델에 활용함
• 복잡하지 않은 모델이었지만 채널별 예산 이동에 따른 예상 결과를 보여줘, 고객이 기대 수익을 미리 확인하고
  채널 변경과 실험을 실행할 수 있게 됨
• 이 경험에서 데이터, 해석, 특정 결정으로 이어지는 순서가 형성됐고 이후 여러 조직에 같은 모델을 적용함

1단계: 신뢰할 수 있는 Data

• Data 계층에는 인프라, 신뢰성, 일관성, 정보 흐름, 파이프라인, 스키마, 모델, 대시보드가 포함되며 데이터 엔지니어와 분석 엔지니어의 일상 업무 대부분이 여기에 속함

• 신뢰할 수 없는 데이터로 관점을 만들 수 없지만,
  요청 수신→처리→티켓 종료에서 작업을 멈추면 정확한 데이터를 해석하는 부담이 준비되지 않은 이해관계자에게 넘어감

• 한 팀은 정교한 파이프라인과 스키마, 검증된 갱신 로직을 갖춘 대시보드 200개를 구축했지만 실제 결정 전에 열어보는 것은 10개뿐이었음

• 나머지 190개는 어떤 결정을 위한 것인지 데이터 팀과 이해관계자가 합의하지 않은 채 만들어짐

• 불필요한 대시보드를 폐기했지만, 근본 원인은
  작업 목적에 대한 공동 정의 부재였음

• Data 계층에 머물면 백로그와 업무량은 유지돼도 실제 결정과의 거리가 커져 팀의 우선순위가 낮아지기 쉬움

2단계: Perspective

• Perspective는 정보를 제공하는 팀을 조직에 영향을 미치는 팀으로 바꾸는 계층이며, 추적 중인 지표가 특정 결정에 적합한지 판단하는
  도메인 지식이 핵심임

• 2026 AI & Data Leadership Executive Benchmark Survey에서 고위 데이터·AI 리더의 93%는 도입의 주요 난제로 문화와 변화 관리를 선택했고, 기술을 선택한 비율은 7%였음

• 문화·변화 관리와 기술의 격차:

• 이는 15차례 연례 조사 중 가장 큰 격차였으며, 조사 기간 내내 기술보다 문화와 변화 관리가 반복적인 장벽으로 나타남

• 조직이 인프라와 인재에 투자해도 해석과 변화 실행 역량이 부족하면 성과가 제한됨

• AI가 프롬프트로 파이프라인, 초기 분석, 대시보드를 만들 수 있게 되면서 병목은 구축에서
  신뢰로 이동함

• 출력량이 늘수록 데이터 품질, 거버넌스, 명확한 진실의 정의 같은 가드레일이 더 중요해짐

• Netflix의 Mick Dreeling은 이해관계자가 에이전트에 직접 질의하는 환경에서 정답을 보장하고 기준을 계속 높이는 책임이 데이터 엔지니어링 팀에 있을 가능성이 크다고 봄

• Meta의 Shridhar Iyer는 에이전트가 일반 지식을 흡수해도 도메인 전문성은 사라지지 않을 지식재산이라고 평가함

• Perspective를 체계적으로 개발하는 전문가는 AI 도구가 발전할수록 가치가 커지지만, Data 계층에만 머무르는 업무는 자동화하기 쉬워짐

객관성의 함정

• 데이터 전문가는 해석을 내놓는 일을 권한 침해처럼 느껴 분석에 맥락을 붙이지 않는 수동성에 빠질 수 있음

• 이해관계자는 제한된 시간과 여러 우선순위 속에서 절반만 이해한 대시보드를 직접 해석하거나 직감에 의존하게 됨

• 데이터는 스스로 말하지 않으므로, 데이터 팀이 맥락과 전문성을 바탕으로 신중히 해석하지 않으면 다른 누군가가 대신 해석함

전달 이후를 보지 못하는 문제

• 파이프라인이 흐르고 대시보드가 열리며 테스트가 통과해도, 이해관계자는 CSV를 내려받아 Excel에서 열과 수식을 추가하고 필요할 때마다 분석을 다시 만들 수 있음

• 이런 시스템은 기술적으로 정상이어도 실무에서는
  우회되고 있음

• 이해관계자 5명에게 현재 내리는 결정과 불확실한 지점을 물으면 하루나 이틀 안에 해결 가능한 문제를 찾을 수 있음

• 작은 문제를 선제적으로 해결해 쌓은 신뢰는 데이터 팀이 결정 이후가 아니라 결정 이전의 회의에 참여할 기반이 됨

주간 원페이지로 관점 훈련하기

• 매주 한 페이지를 다음 세 부분으로 작성함

• 데이터가 보여주는 사실을 한 문단으로 정리함

• 현재 비즈니스에 무엇을 뜻하는지 의견을 담아 한 문단으로 해석함

• 다음에 해야 할 일을 구체적인 불릿 1~2개로 제안함

• 관리자, 동료 또는 비즈니스 담당자 한 명과 공유하고 피드백 하나를 받는 주기를
  3개월간 반복하면 의사결정자가 중요하게 여기는 데이터에 대한 직관이 달라짐

• 행동 제안부터 가장 중요한 작업이 시작되며, 불편하더라도 자신의 의견을 형성하는 훈련이 필요함

매크로와 마이크로 지표

매크로 지표는 회사가 건강한지 답하는 소수의 핵심 수치이고, 마이크로 지표는 매크로의 움직임을 설명하는 입력 수치임

• Apple의 Monisha Kanoth는 비즈니스 전체가 합의한 견고한 북극성 지표가 신뢰의 기반이라고 봄

• 수십 개 출처의 데이터를 받던 마케팅 리더를 위해 보고 체계를 매크로 지표 3개와 마이크로 신호 5개로 재구축함

• 한 분기 안에 어떤 숫자를 신뢰해야 할지 모르는 상태에서 벗어나, 이사회 대화에서 성장의 동인과 그렇지 않은 요소를 정확히 말할 수 있게 됨

• 중요한 지표를 정하고 그 무결성을 우선하자 질문과 데이터 팀의 답변 품질도 개선됨

이해관계자와 공동 설계하기

버전 0.8 출시는 완성 전 결과물을 보여주고 이해관계자를 마지막 20%의 구축 과정에 참여시키는 방식임

• 공동 제작은 결과물에 대한 소유감을 만들며, 소유감은 산출물을 실제 행동 약속으로 전환함

• 한 이해관계자가 정말 중요한 질문 100개를 적었고, 이후 몇 년 동안 나온 질문 대부분이 이 목록 안에 있었음

• 이 목록은 구축 로드맵이자 범위 통제 도구로 활용됨

• 새로운 요청이 들어오면 거절 여부가 아니라 기존에 합의한 항목보다 중요한지를 비교할 수 있었음

링크가 아닌 서사를 결과물로 만들기

• SQL 쿼리, 스프레드시트 또는 대시보드 링크만 공유하면 가장 어려운 해석 작업을 사용자에게 넘기게 됨
• 짧더라도
  서사를 작성하면 무엇이 중요한지 선택하고 특정 해석에 책임을 져야 하며, 피드백·반박·수정이 가능한 결과물이 만들어짐
• 생성형 AI는 문장을 다듬는 데 사용할 수 있지만 사고 자체를 맡겨서는 안 됨
• 글쓰기는 사고 과정이며 AI가 고유한 관점을 대신 개발할 수 없음
• 생각에 직접 관여하지 않고 AI가 만든 서사를 그대로 전달하면 시간이 흐르며 축적되는 Perspective 계층을 건너뛰게 됨

3단계: Action

• 권고를 실제 조직 결정으로 바꾸기까지의 간격은 크며, 데이터 팀은 이 전환에 필요한 작업과 자신의 책임을 과소평가하는 경향이 있음
• 분석과 의사결정 회의 사이의 공백은
  명확한 권고, 기회 규모 산정, 지속적인 지지 활동으로 메워야 함
• 데이터 팀이 이 영역에 참여하지 않으면 이해관계자의 해석, 이해관계, 일정이 공백을 채우며 작업에서 가장 중요한 부분의 주도권을 내주게 됨

데이터만 제시하지 않는 규칙

• 모든 분석에는
  권장 행동이 포함돼야 하며 데이터만 단독으로 제시해서는 안 됨

• 마지막에 무언가를 권고해야 한다는 제약은 처음부터 작업 범위를 바꿈

• 특정 질문을 중심으로 조사하게 됨

• 결정과 관련된 지표를 계측하게 됨

• 리더가 움직이는 데 필요한 정보가 무엇인지 고려하게 됨

• 한 성장 기회를 수치화한 모델이 리더십의 행동으로 이어지지 않은 사례에서는 분석의 정확성이 아니라 권고와 공동 맥락이 부족했음

• Data에서 곧바로 Action으로 건너뛰면 관계 형성, 공동 제작, 신뢰 구축이 빠져 권고가 실행되지 않은 채 남을 수 있음

기회 규모와 지속적인 지지

• 분석에서 가설이 나오면 기회가 얼마나 가치 있고 왜 우선해야 하는지 데이터 팀이 직접 수치화해야 함
• 추정치가 틀릴 수 있어도 구체적인 숫자는 의사결정자가 반박할 대상을 제공하며,
  논쟁 가능한 추정치가 모호한 방향보다 결정으로 이어지기 쉬움
• 한 번 발표했다고 로드맵에 반영되는 것은 아니며, Action 계층에 도달하기까지 수개월이 걸릴 수 있음
• 학습 의제(learning agenda)를 유지해 실행된 권고와 실행되지 않은 권고를 추적하고, 여전히 중요한 항목에는 갱신된 수치를 제시하며 계속 지지해야 함
• 첫 발표가 받아들여지지 않았다고 후속 작업을 중단하면 결정까지 연결하는 핵심 업무를 포기하게 됨

프레임워크를 뒷받침하는 조직 구조

• 특정 비즈니스 영역에
  분석 엔지니어 1명과 분석가 1명을 배치하는 듀오가 이상적인 기본 단위임

• 분석 엔지니어는 시스템의 견고성을 책임짐

• 분석가는 서사, 이해관계자 관계, 행동 권고를 맡음

• 서사를 담당할 파트너가 없는 엔지니어는 결정보다 완전성을 위해 구축하기 쉽고, 신뢰할 수 있는 시스템 파트너가 없는 분석가는 설득력 있는 근거를 만들기 어려움

• 기존 조직은 즉시 개편할 필요 없이 한 비즈니스 영역에 두 역할을 한 분기 동안 배치해 모델을 검증한 뒤 확대할 수 있음

• 초기 기업처럼 인프라 업무가 팀 역량 대부분을 차지한다면 듀오 대신 관점을 공유하는 시간을 보호할 수 있음

• 매주 비즈니스 검토를 진행함

• 직접 담당하지 않는 팀을 대상으로 매월 데모를 열 수 있음

• 조직도 자체보다 Perspective를 반복하는
  습관이 더 중요함

장기간 축적되는 운영 리듬

• 관점을 만들고 행동을 지지하는 작업을 매주 반복하면 수개월과 수년에 걸쳐 효과가 축적됨
• 의사결정 과정에 참여할수록 존재 이유가 불분명한 파이프라인, 잡음에 가까운 알림, 앞으로 실제로 필요한 인프라 투자를 더 잘 구분할 수 있음
• 데이터 팀의 역할은 조직 구성원이 현재 상황과 그 의미를 공통으로 신뢰할 수 있는
  공동의 현실을 구축하는 것임
• Data-Perspective-Action은 기술 작업의 목적이 더 나은 결정임을 계속 드러내는 운영 모델이며, 파이프라인과 스키마도 그 결정을 위해 존재함

댓글과 토론