Conference Review · 2026 데이터야 놀자

2026 데이터야 놀자 참석 후기:
데이터와 AI가 조직 안에서 실제로 일하려면

유료 참가가 가능한 행사였기에 모든 정보를 공유하거나 공개하는 게시물이 아닌, 분위기 및 이해한 내용을 정리하는 게시물입니다.
핵심 1. 데이터 협업 쿼리 작성보다 오래 걸리는 것은 문제 정의와 암묵지 공유였다.
핵심 2. 데이터 거버넌스 AI가 들어올수록 조직의 용어, 지표, 권한 기준은 더 중요해진다.
핵심 3. 로컬 AI 운영 모델을 올리는 일보다 관측, 검증, 복구 체계가 더 오래 남는 과제다.
핵심 4. 실행형 플랫폼 AI는 조회 도구에서 업무 실행과 연결되는 플랫폼으로 이동하고 있다.

내가 들은 세션

  • AI 쓰는 분석가가 파이프라인까지 만들어버린 이유
  • A/B 테스트만으로는 부족합니다
  • 문과생의 꿈이 오픈소스가 되기까지
  • 데이터 협업이 느린 진짜 이유
  • 사내망에 Claude Code를 심다
  • AI based big data analytics
  • 올해 채용계획을 취소했다.

들어가며

2026 데이터야 놀자 컨퍼런스에 다녀왔다. 데이터 컨퍼런스라고 하면 보통 최신 분석 기법, 데이터 플랫폼, 모델링 사례를 기대하게 된다. 그런데 이번에 개인적으로 더 강하게 느낀 것은 기술 스택 자체보다 "조직이 데이터를 어떻게 요청하고, 해석하고, 실행으로 연결하는가"였다.

현장에서 들은 세션들은 서로 다른 주제를 다뤘다. 데이터 협업 문화, 폐쇄망 환경의 로컬 AI, Azure OpenAI 기반 제조업 R&D 플랫폼 등 방향은 달랐지만 공통된 질문은 비슷했다.

좋은 도구가 있어도, 조직은 왜 여전히 데이터를 느리게 쓰는가?

데이터 협업이 느린 이유는 쿼리가 아니라 암묵지였다

가장 먼저 인상 깊었던 내용은 데이터 요청과 협업에 대한 이야기였다. 흔히 데이터 업무의 병목을 "쿼리를 작성하는 시간"으로 생각하기 쉽다. 하지만 실제로 더 오래 걸리는 구간은 문제를 정의하고, 서로 같은 의미로 이해하는 과정이다.

예를 들어 "최근 신규 입점 가게의 성과를 보고 싶다"는 요청은 얼핏 명확해 보인다. 하지만 실제 분석으로 들어가면 바로 질문이 이어진다.

  • 최근은 며칠 기준인가?
  • 신규 입점의 기준일은 무엇인가?
  • 주문이 한 번이라도 발생한 가게만 볼 것인가?
  • 거래액은 어떤 수수료 기준으로 계산할 것인가?
  • 결과는 일회성 리포트인가, 대시보드인가, 스프레드시트 연동인가?

이런 조건은 조직 안에서 너무 당연하게 여겨져 문서화되지 않는 경우가 많다. 발표에서는 이런 개인과 팀의 배경지식을 암묵지로 보고, 이를 형식지로 바꾸는 것이 데이터 협업 속도를 높이는 핵심이라고 설명했다.

이 부분은 AI 활용에도 그대로 이어진다. 모호한 질문을 사람에게 던지면 사람이 되묻고 정리해 주지만, AI에게 던지면 그 모호함이 그대로 결과 품질의 흔들림으로 이어진다. 데이터 조직이 AI를 잘 쓰려면 프롬프트 스킬보다 먼저 요청 포맷과 지표 정의를 정리해야 한다는 생각이 들었다.

강의 중 자주 언급된 데이터 용어 정리

세션을 들으면서 반복적으로 들렸던 단어들도 따로 남겨두고 싶었다. 아래 내용은 발표 슬라이드의 세부 설명을 옮긴 것이 아니라, 현장에서 들은 흐름을 개인적으로 정리한 것이다.

데이터 웨어하우스

여러 서비스와 운영 시스템에서 발생한 데이터를 분석 목적으로 모아두는 통합 저장소에 가깝다. 흩어진 데이터를 일정한 기준으로 적재하고 정리해 조직 전체 관점에서 함께 볼 수 있는 기반을 만든다.

데이터 마트

데이터 웨어하우스에 모인 데이터 중 특정 팀, 목적, 도메인에 맞게 다시 정리한 분석용 데이터 묶음으로 이해했다. 자주 쓰는 기준과 지표를 미리 정리해두면 분석 요청과 대시보드 작성이 수월해진다.

Input
입력 데이터
Airflow?
워크플로우·스케줄링
Redshift?
웨어하우스 적재·가공
Red...?
후속 처리·제공 계층

핵심은 데이터가 입력되자마자 바로 분석 화면에 뜨는 것이 아니라는 점이다. 수집, 스케줄링, 적재, 가공, 조회 계층을 지나면서 조직이 재사용할 수 있는 분석 데이터로 바뀐다. 그래서 데이터 플랫폼을 이해할 때는 개별 도구 이름보다 "데이터가 어떤 단계에서 어떤 책임을 갖고 이동하는가"를 보는 것이 더 중요하다고 느꼈다.

AI 시대에도 데이터 거버넌스는 더 중요해진다

이번 컨퍼런스에서 반복적으로 느낀 점은 AI가 데이터 거버넌스를 대체하지 않는다는 것이다. 오히려 AI가 조직 안으로 깊게 들어올수록 지표, 용어, 권한, 문서, 요청 방식이 더 중요해진다.

기획, 개발, 데이터, 비즈니스 조직은 같은 단어를 다르게 쓰는 경우가 많다. "활성 사용자", "신규 고객", "거래액", "전환" 같은 단어도 팀마다 기준이 달라질 수 있다. 사람끼리 일할 때도 문제였던 이 차이는 AI 에이전트가 업무를 대신 수행하기 시작하면 더 큰 리스크가 된다.

AI가 잘 답하도록 하기 전에 필요한 기반
  • 공통 용어와 지표 정의
  • 데이터 요청 템플릿
  • 재사용 가능한 데이터 마트와 문서
  • 결과물을 검증하는 책임 구조
  • 팀별 언어 차이를 조율하는 거버넌스

기술적으로는 거창하지 않아 보여도, 이런 기반이 없으면 AI 도입은 데모 수준에 머무르기 쉽다. 좋은 모델을 붙이는 것보다 조직의 언어를 정리하는 일이 먼저일 수 있다.

폐쇄망 로컬 AI 사례에서 본 현실적인 운영 문제

또 다른 세션에서는 보안이 중요한 환경에서 사내망 안에 AI 코딩 에이전트를 구축한 경험담이 다뤄졌다. 이 주제는 개인적으로 특히 흥미로웠다. 요즘 많은 조직이 생성형 AI를 쓰고 싶어 하지만, 개인정보와 내부 코드 유출 우려 때문에 클라우드 기반 도구 사용을 제한하는 경우가 많기 때문이다.

겉으로 보면 요구사항은 단순하다. 외부로 데이터가 나가지 않게 하고, 내부망에서 AI를 돌리면 된다. 하지만 실제 운영은 훨씬 복잡하다. 모델을 고르는 문제뿐 아니라 메모리, 전력, 동시 사용자, 장애 대응, 관측, 검증, 툴 호출 품질이 모두 얽힌다.

로컬 AI는 모델을 올리는 순간 끝나는 것이 아니라, 운영 체계를 설계하는 순간부터 시작된다.

특히 AI 에이전트는 단순 챗봇보다 운영 난도가 높다. 도구 호출이 안정적으로 되어야 하고, 작업 단위가 적절히 쪼개져야 하며, 결과 검증도 필요하다. 모델이 똑똑한가만 볼 것이 아니라, 실제 업무 흐름에서 도구를 얼마나 잘 다루는지와 실패했을 때 어떻게 복구하는지를 함께 봐야 한다.

이 부분은 컨퍼런스 후에도 계속 생각이 났다. AI 도입 논의가 "어떤 모델을 쓸까"에서 멈추면 안 된다. 특히 엔터프라이즈 환경에서는 모델보다 운영, 권한, 책임, 관측 가능성이 더 오래 남는 의사결정이 된다.
(그나저나 폐쇄망에 동작하는 성능도 준수한 에이전트 AI를 구축하는 것은 상당히 비싸다는 것을 알게 되었다.)

제조업 R&D에서 AI는 조회가 아니라 실행으로 이동하고 있었다

제조업 R&D 플랫폼 사례에서는 AI가 단순히 문서를 찾아주거나 SQL을 생성하는 수준을 넘어, 업무 실행과 연결되는 방향으로 진화하고 있다는 점이 인상적이었다.

제조업은 데이터가 많지만 활용까지 걸리는 시간이 길다. 데이터 반출, 정제, 보안, 문서 최신성, 시스템 연결 문제가 복잡하게 얽힌다. 그래서 AI를 붙인다고 바로 인사이트가 나오는 구조가 아니다.

발표에서는 문서 기반 AI, 데이터 분석 AI, API, MCP 같은 연결 방식이 함께 언급됐다. 세부 구현은 옮기지 않겠지만, 핵심 방향은 분명했다.

Connect

흩어진 문서와 데이터를 최신 상태로 연결한다.

Focus

사용자는 SQL이나 시스템 구조보다 질문과 의사결정에 집중한다.

Execute

AI는 조회 결과를 보여주는 데서 그치지 않고 다음 실행 흐름으로 이어진다.

이 흐름은 데이터 조직에도 중요한 신호다. 앞으로의 데이터 플랫폼은 대시보드나 리포트만 제공하는 역할에서 벗어나, 사용자의 업무 맥락과 실행 도구 사이를 연결하는 방향으로 확장될 가능성이 크다.

세션들을 관통한 하나의 질문

서로 다른 발표였지만, 개인적으로는 하나의 질문으로 묶였다.

데이터와 AI가 조직 안에서 실제로 일하려면 무엇이 필요한가?

내가 정리한 답은 세 가지다.

  1. 요청이 명확해야 한다. 데이터 요청이든 AI 요청이든 기간, 대상, 조건, 지표, 출력 형태가 정리되어야 한다.
  2. 조직의 언어가 정리되어야 한다. 같은 단어를 다르게 쓰는 문제는 사람 사이에서도 비용을 만든다. AI가 들어오면 그 비용은 더 커진다.
  3. 운영과 검증이 설계되어야 한다. AI 시스템은 한 번 붙이면 끝나는 도구가 아니다. 권한, 장애, 비용, 품질, 검증 책임이 함께 설계되어야 한다.

이 세 가지는 화려한 기술보다 덜 눈에 띈다. 하지만 실제 도입과 확산에서는 더 결정적인 요소처럼 보였다.

개인적으로 가져갈 적용 포인트

이번 컨퍼런스를 듣고 나서 당장 적용해 보고 싶은 것은 거창한 플랫폼 구축이 아니다. 오히려 작은 문서화와 요청 방식의 개선이다.

예를 들면 데이터 요청을 받을 때 다음 항목을 기본 템플릿으로 강제해 볼 수 있다.

항목 확인할 내용
기간 조회 기준일, 비교 기간, 누적 또는 일별 여부
대상 포함할 사용자, 고객, 상품, 지점, 조직 범위
조건 제외 조건, 필터, 최소 활동 기준
지표 매출, 거래액, 사용자 수 등 계산 기준
출력 표, 그래프, 대시보드, 스프레드시트, 일회성 분석 여부
활용 목적 의사결정, 모니터링, 보고, 실험 검증 등

이 정도만 정리해도 "쿼리 10분, 문제 파악 몇 시간" 같은 상황을 줄일 수 있을 것 같다. AI를 붙이기 전에도 효과가 있고, AI를 붙인 뒤에는 더 중요해질 기반이다.

마무리

2026 데이터야 놀자는 최신 기술을 보여주는 자리이기도 했지만, 개인적으로는 데이터와 AI가 조직 안에서 일하기 위한 조건을 다시 생각하게 만든 컨퍼런스였다.

좋은 모델, 좋은 플랫폼, 좋은 도구는 중요하다. 하지만 그것만으로는 부족하다. 조직의 언어를 정리하고, 요청을 명확히 하고, 운영과 검증 책임을 설계해야 한다. 그래야 데이터와 AI가 "멋진 데모"를 넘어 실제 업무의 속도를 바꾸는 도구가 된다.

AI를 잘 쓰는 조직은 기술을 빨리 붙이는 조직이 아니라, 일을 명확하게 정의할 줄 아는 조직이다.

+후기

행사 스탬프 이벤트를 통해 '임정' 발표자님께서 만든 'n8n이 다해줌'이라는 책도 받았다!

+ Recent posts