6월 1일 데이터야놀자 2024에서 들은 내용과 후기를 올려본다.

logo

1. 분석 속에 숨어있는 다크데이터

  • 여성 쇼핑 플랫폼(에이블리) 소속. 지표 분석, 데이터 엔지니어링 등 다양한 업무중
  • 책 다크 데이터 관련
    • 책에서는 다크 데이터: 온갖 누락된 데이터를 지칭
  • 타이타닉 데이터는 아주 좋은 데이터셋이지만, 실제 회사에서는 데이터가 없는 경우도 많음 (물론 하루 TB 단위의 데이터가 쌓이는 회사도 있지만)
  • 의미를 모르는 데이터도 많음. 메타데이터가 제대로 정리되어 있지 않은 경우. 복잡해서 해석이 어려운 경우도 있음
    • 이렇게 분석하기 어려운 데이터를 다크 데이터로 정의
  • 다크 데이터의 예시
    1. 확대 해석: 사내 트렌드와 시장 트렌드를 혼동하는 경우
    2. 잘못된 해석: 알림수신 여부 설정을 앱에서/기기에서 모두 가능. 기기 설정 간과하고, 앱내 데이터만으로 수신율을 판단할 수 있음
    3. 가정: 12월 한정 고등학생 학년별 평균 알바시간 집계할 경우, ‘고3 알바 시간이 가장 길어, 공부 안하고 일만 해’ 라고 어그로 끌 수도 있음 (사실은 수능 끝나고 알바를 많이 한 건데)
    4. 데이터 부족: 측정 기기성능에 따른 차이 (사진 데이터: 카메라 센서, 픽셀수 등 차이 날 수 있음)
    5. 유저 정보: 키, 몸무게, 신발 사이즈 등을 유저가 제대로 입력하지 않았을 경우
    6. 분석가의 실수. 개발자의 실수면 눈에 보이는 에러가 나겠지만, 분석가의 실수는 눈에 띄지 않는 숫자 차이가 날 수 있음(1억 → 1.1억 이럴 경우 코드를 들여다 보지 않으면 에러 난지 모름). 주관 부서에서 정의를 잘못 하면 다른 사람이 잘못된 정의를 따라갈 수도 있음)
    7. 로깅 실수: 특정 버전/경로에서 로깅이 되지 않을 경우
    8. 경험의 에러: 수년 간의 경험에 근거하여, 특정한 방법이 옳을 수 있는데 옳지 않다고 판단하여 간과할 수 있음
  • 결론: 다크 데이터를 찾으려면 어떻게 해야 할까?
    • 각종 모니터링 필요 (슬랙 알람, Airflow, Cron job 등을 통해)
    • 피쳐가 갈수록 커지기 때문에, 다양한 사람이 들여다 볼 필요 있음
    • 여러 정보 필요 (프로모션, 외부 뉴스 등)
    • 큰 회사일수록, 분석가는 여러 분야에 대해서 알고 있어야 옳은 판단을 내릴 수 있음


2. 금융 데이터 및 AI 산업의 현주소의 전망: 기술, 비즈니스 및 규제 관점

  • 금융보안원 AI혁신실 소속
  • 관심사: 해킹 보안 → 백엔드 개발 → AI 데이터 (대학원은 여기로 전공)
    • 금융 분야 AI 활용에 대해 연구개발 중
  • 금융권 채용 트렌드: 캐글 등 데이터 컴피티션 참여자 → 금융권 자체 경진대회 열기 시작. 실무자가 풀고 싶어 하는 토픽으로 대회를 열어 도움을 얻고자 함
  • 여러 데이터 거래소 등을 통해 데이터를 구할 수 있는 방법이 많아지고 있음
    • 관련 프로젝트도 많아지고 있음
    • 데이터 직군이 아니더라도, AI 데이터 관련 기본 지식은 숙지하는 것이 좋음
  • 데이터 관련 현황
    1. ‘20.8 데이터 3법 개정: 데이터 프로젝트시 매번 정보주체의 동의를 구해야 함
      • 가명정보는 동의 없이 활용 가능. 데이터를 가명화/범주화하여 프로젝트에 사용
    2. ‘22.4 데이터 기본법 시행: 데이터 산업 전반 본격 육성 시작
    3. 데이터 경제 활성화 추진과제: 관계부처 합동 발표
  • 데이터 컨소시엄 (크랜데이터)
    • 신한카드 + KCB + SK텔레콤
    • 라이프스타일 분석을 통한 전기차 구매 인구 예측
    • 분석1: 전기차 구매에 있어 전기료 가격 인상이 직접적인 영향을 주는가? → 인과추론 사용
    • 분석2: 전기차 구매 가능성 높은 고객 타겟팅 → 예측모델링 사용
  • 금융데이터 활용 수요 증가 → 데이터 허브 네트워크 및 플랫폼 기능 강화. 회사 간 데이터 송수신
  • 금융데이터거래소: 139개 기업/기관 참여
    • 정부 중심으로 많이 가고 있지만, 활용 넓히기 위해 환경 조성 중
  • 금융데이터 보안(개인정보 유출 방지) 수요 늘고 있음. 데이터 전문기관 최초 4개에서(금보원, 신정원, 금결원, 국세청), 현재는 민간 8개 기관 추가 지정. 해당 기관을 통해서만 데이터 결합 가능
    • 21~23년 결합 건 매년 증가
    • 금융권 내 결합은 많이 증가하지 않음. 타 산업과의 결합 증가 (금융권 데이터만으로는 라이프스타일 보기 어려움)
    • 분석 예시: 카뱅에서 사내 데이터만으로 씬 파일러 신용평가 어려움 → 통신사 등 데이터와 결합
  • 익명처리기술 연구개발
    • 익명화는 데이터를 뭉개는 것. 그럼 활용도 떨어짐
    • 원본 데이터의 통계정 특성, 분포, 표본을 이용하여 원본 데이터와의 유사성을 보존하는 기술
    • 스위스 보험회사 Die Mobiliar 케이스: 원본 데이터로 훈련된 모델을 실서비스에 이용 불가. 합성데이터로 학습시킨 모델 이용 → 성능 95% 보존
    • 합성데이터 알고리즘: Synthpop
  • 국내 금융권 내 AI 도입 현황
    • 기존: AI 기반 외부 솔루션 도입, AI 도입했다고 홍보
    • 현재: 핵심 업무에 AI 자체 개발. 신용평가, 이상거래탐지 등
  • 금융권 XAI
    • 금보원에서 세미나 열었음: 금융분야 설명가능한 인공지능(XAI) 세미나
  • AI 보안 위협에 따른 AI 보안기술 연구 확대. 생성형 AI를 계속 가스라이팅 해서, 모델 로직 유출 유도할 수 있음
  • 데이터 공유는 위험하니, 각 회사의 모델을 공유하는 연합학습(Federated Learning) 개념도 있음
    • 각사의 모델을 aggregation하여 연합 모델 공유해 줌
    • xgboost 하이퍼파라미터를 공유. learning_rate, loss function 등. 이거 기반으로 자사 모델 고도화
  • 최근 연구 주제: 검색증강생성(RAG)
  • 상용 생성형 AI 활용
    • 해외 오픈소스(chatGPT 등)은 데이터가 해외로 나가는 것. 규제상 어려움
  • 전자금융감독규정을 위반하지 않는 IT 아키텍처 설계 필요
    • 금융규제 피해가며 아키텍처 설계하는 인력들이 잘 나감
  • 생성형 AI 특화 보안위협. 스타벅스를 1천번 말하게 시키면 학습 데이터를 말하는 경우가 있음
  • 국내 AI 데이터 관련 2가지 challenge
    • 개인정보 유출 위험
    • 규제, 컴플라이언스 등으로 신기술 도입 어려움
    • 이에 더불어 회사별 내부통제를 뚫어야 함
  • 데이터 결합, 보안, 품질검증 관련 기술 및 서비스는 향후 2~3년간 확장 예상
  • 발표자 개인 페이지: https://mainthread.kr/


3. 한국어 자연어 오픈소스 모델 평가 리더보드 ‘LogicKor’ 제작기

  • 고3 학생
  • 한국어 지원하지 않는 게임(발더스게이트): 번역기를 만들어서 하면 되지 않을까? 하는 생각에 LLM 사용
  • Ai 언어모델 로컬 채널: LLM의 학습 및 추론 방법, 데이터셋 구성 등 정보 공유
  • LogicKor: 한국어 언어모델 평가 벤치마크
    • 기존 한국어 벤치마크, 리더보드의 문제점: 객관식 평가. 특정 task의 성능 확인에 그침(벤치마크의 특성). 실제 언어모델로서는 기능하지 못하는 경우가 있음
    • 주관식 평가 필요. 추론능력이 있는 서술형 벤치마크
  • 데이터셋 생성: 추론능력 및 지시 이행능력 확인 위해 필요한 요소
    • 사실 기반에서 멀어지자
  • 데이터셋 구성
    • 6개 카테고리에 각각 7개의 멀티턴(2턴) 질문. 총 42쌍의 질문
  • 평가: GPT4를 judge 모델로 사용 (정성평가 모델)
  • task가 다른 여러 모델의 합성
    • 예시: 최신 비전(이미지 인식) 모델에 한국어 적용. 한국어로 주어진 표(이미지)의 내용을 설명해 달라 하는 경우
    • 학습 데이터를 줄일 수 있음
  • LLM의 진입장벽
    • 간단한 파인튜닝은 N만원 단위로 가능
    • 단순히 사용, 튜닝하는 정도는 모델 이해도를 필요로 하지 않음
    • Hugging Face에 모델에 대한 모든 것이 있음. LLM 부분 살펴보기
  • 학습 사이트: 디스코드 채널 instruct.kr


4. AI 시대, 나는 과연 어떻게 성과를 내며 살아가야 할까요?

  • MS S&B(중소기업 세일즈) 총괄 리더
    • 중소기업 대상 신흥 AI 시장 관련 업무
    • 중소기업: AI를 기회보다 위협으로 많이 인식
  • 향후 10년 뒤 현재 직업의 50% 이상이 대체될 것으로 예상
  • 1849 골드러시(49ers)
    • 미국 전역, 유럽, 아시아 등 각지에서 집을 팔아 캘리포니아로 이동(샌프란시스코 49ers가 여기서 유래했나 봄). 이 과정에서 죽은 사람도 있음
    • AI를 골드러시로 비유. AI로 업무 개선 시도
    • 금광 근처에서 밥집 열거나, 광부들에게 청바지 판매(→리바이스). 꼭 금을 캐지 않아도(개발자에 비유) 이득을 얻을 수 있음
  • MS 관련
    • 2023 사티아 나델라: Copilot for everyone
    • 주가 성장: 2001 닷컴 버블 시기에는 인력 증가에 따른 성장. 2021~ 성장은 디지털 직원으로의 전환을 통한 Layoff로 성장
  • MS 오피스 365 Copilot
    • 5/14 GPT5 발표 (찾아보기)
    • Teams의 Copilot: Teams로 미팅. 관련 정보를 계속해서 질문하면서 보조 직원이 있는 느낌
    • 오피스에 GPT4o 넣어 작업에 도움
    • Github Copilot: 작업 종류를 말하면(채팅이 아닌 정말 말을 함) 코드 작성. 작년 Github 전체 repository 중 절반의 코드를 AI가 생성. 자면서도 코드 짤 수 있으니
    • Bing AI: 유료(기업) 버전 사용하면 자료 업로드하여 사용. 자료 유출 여지 없음
    • personal assistant에서 팀의 assistant로 진화. Copilot을 팀원처럼 초청하여, 사람들이 말하고 있으면 미팅 자료 요약, 정리 등을 실시간으로 만들어 줌
    • 나와 관련된 미팅 요약, 미팅에서 내가 해야 할 Action Item 요약 등 해 줌
    • Boss가 나한테 요청한 일이 뭐냐고 질문하면, Boss와의 회의 자료 등을 모두 훑어서 정리해 줌
    • 다만 뒷단의 정리가 잘 되어 있지 않으면, 사내 민감정보(연봉 등)를 모두 노출할 수 있음. 그래서 사용 중단한 회사도 있음
    • 곧 Employee ID를 부여하여 사용할 수준
    • 관련 자료를 주면 보고서도 만들 수 있음. 팀의 문화, 특성 등을 이해하여 작성
  • 엑셀 Copilot
    • 시트1: 예산, 시트2: 지출 이라면, 두 시트를 요약하여 소비 결과에 대한 리포트를 작성해 줌
    • 엑셀 데이터를 분석하는 python 코드를 작성할 수도 있음. 엑셀 안에 python 코드 임베드. python 한 줄도 몰라도 분석 가능


5. Do you Know DBT? DBT로 쉽게 모델링하기

  • 당근 데이터 가치화팀 Software Engineer. DBT 도입 배경
  • DBT(Data Build Tool)란?
    • ETL 중 Transformation 담당하는 워크플로우 툴. 데이터 테스트, 모듈화 등
    • Airflow만 쓸 경우 DE 역량 많이 필요한데, 분석가도 엔지니어링 할 수 있도록 돕는 도구
  • 당근이 겪은 문제와 DBT 도입 배경
    • 데이터 보는 것이 어렵다. 데이터의 신뢰도 부족, 추출하는게 복잡함, 추출 조건을 모르겠다 등. 추출 로직이 업데이트가 안 되어 있을 수도 있음
    • 데이터 보는 것이 쉬우려면: 원하는 정보가 이미 정제되어 존재, 신뢰할 수 있는 형태로, 정보가 잘 정의되어 있음, 정보 탐색이 쉬움
  • 신뢰할 수 있는 정보들이 지속 관리되고, 정보를 만드는 것이 쉬워야 함
    1. 신뢰할 수 있는 정보 만들기: DE 영역. 주기적 정보, 정보에 대한 퀄리티 보장(데이터간 의존성, 데이터 테스트 등), 정보 관리(정의, 메타데이터 등)
    2. 도메인 지식이 반영된 비즈니스 로직으로 정보가 만들어져야 함
  • DE 역량에 도메인 지식 vs 도메인 지식에 DE 역량
    • 도메인 지식 가진 사람은 DE 역량자에 비해 많이 늘어남 → 도메인 지식 가진 사람이 DE 역량을 기름
  • DBT with Airflow: 당근의 솔루션
    1. Easy Transformation: yaml과 sql만으로 데이터 가공, 저장
    2. Data Quality: DBT 모델간 의존성 기능을 통해, 모델(스크립트 개념으로 보면 될듯) 간 실행 순서 관리. 가공된 DBT 모델에 대해 테스트 가능(특정 컬럼의 not null, unique 여부)
    3. Documentation: yaml, sql 파일에 결과물(결과 테이블, 컬럼 등)을 적어 놓으면, 자료 요약 가능
    4. Reusability: 반복되는 로직을 재사용성 있는 포맷으로 만들 수 있음
    5. Data Freshness: Airflow 사용 이유. 주기적인 스케줄링을 통해 지속적 관리
    6. Observability: 모델 실행/실패여부 등 모니터링
  • DBT x Airflow: 데이터 만드는 것은 쉬워지지만, 구조나 규칙이 없다면? 각자가 통일된 규칙 없이 데이터 만들다가 데이터가 복잡해지고, 다시 데이터 보는 것이 어려워질 수 있음
    • 직관적이고 쉬운 형태의 구조화가 되어야 함
    • 예시: 앱 데이터 로깅
      • 사용자가 기기에서 특정 액션을 할 경우, 무지성으로 로깅하는 경우 많음. 사용자의 의도 추론
      • Base → Dimension(디멘젼 모델링) → Fact
  • DBT 모델과 Airflow Operator 관리
    • Operator의 단위에 따라 장단점 있음(슬라이드 참고)
    • 모든 dbt model을 각각의 Airflow Operator에서 관리하는 방법 선택
      • Cosmos: DBT 모델간 의존성 관리 도구
      • Airflow 태스크는 많아지지만, Cosmos를 통해 관리
  • DBT: 현재 1.4.0 버전으로 여러 실행 상 문제 해결 중
  • DBT 사용
    • Raw: 원천 데이터
    • Base Layer: 1차 가공 데이터 (DBT의 staging 개념)
      • join, aggregation 없이 원천 데이터와 1:1 매핑. 컬럼 선택, 컬럼명 변경, SQL의 인라인 함수 등만 사용하는 단계
    • Dimension Layer: User, Product 등 특정 개체 속성
      • join, where 등 연산이 시작됨
      • row가 줄어드는 단계. table로 materialize(=테이블로 저장)
    • Fact: 사용자의 이벤트. 어떠한 X가 Y 했다. 유저가 결제했다
      • 복잡한 연산이 들어갈 수 있고, 시간 흐름(X가 언제 Y를 했다) 들어감. 데이터 크기가 큼
      • incremental로 materialize. 파티셔닝 개념
      • 조인 필요 없이, 하나의 모델에 one big fact table로 만들어 fact만 사용해도 충분할 수 있도록 함. 저장 크기가 많아도, 조인 연산이 더 큰 비용
    • 이외에 ref(sql 내에서 다른 모델 의존), macros(반복되는 작업? 주기적으로 스냅샷 저장 등) 사용
    • yaml: null 체크 등 옵션 설정
  • 이외 도구
    • Airflow: DBT와 연계하여 DAG 관리
    • Datadog: 모니터링
    • Datahub: 문서 관리 (모델링 정보)
  • DBT를 통해 쉬운 데이터 사용성 확보
    1. 원하는 정보가 이미 존재 (짧은 쿼리로 접근)
    2. 추가적인 가공이나 확인 필요 없이, 신뢰할 수 있는 형태로 정제되어 있음
    3. 비즈니스에 따른 데이터 정보 정의
    4. 정보 탐색을 빠르게, 쉽게 할 수 있다 → 이거는 쉽지 않은 문제. 해결 중
  • 앞으로는
    • 더 많은 핵심 정보들을 DBT with Airflow로 생산
    • Base / Dimension / Fact 외에 더 필요한 계층에 대해 고민
    • 쉬운 정보 사용 위해 고민. 원하는 데이터의 탐색이 더 쉽도록 탐색 경험 개선. 여러 차트(UI Based chart?)도 활용


6. 챗GPT, 실무에서 바로 쓰는 LLM 최적화 기법 - RAG부터 LLMops까지

  • 챗GPT 이전부터 GPT 책을 내심
  • 목 쉬셔서 ASMR로 발표하시는 게 인상적이었음
  • GPT4o와 같은 LLM의 구조? 인풋-모델-아웃풋. 알고 가야 프롬프트 엔지니어링 이해할 수 있음
  • 프롬프트 엔지니어링 방법들
    • chain of thought
      • 답이 아닌 풀이과정을 뱉어내게 하면, 정확도가 향상됨
      • 모델 사이즈가 크면 chain of thought 성능도 향상
    • contrastive chain of thought
      • 반례를 알려줬더니 성능 향상
      • 고양이 사진 인식에서 강아지 사진을 보여줄 경우, 고양이 인식 잘함
    • chain of code
      • 풀이과정을 코드로 하게 했더니 성능 대폭 향상 (딥마인드 발표)
      • 프롬프트 엔지니어링만이 아닌, 코딩을 버리면 안 되는 이유
      • 위 2개보다 성능 대폭 향상. human error rate 돌파: 사람을 안 써도 됨
    • self consistency
      • API 호출 여러번 하여 다수의 답변 생성하게 한 다음, 투표를 통해 가장 높은 점수의 답변 채택
      • 못 맞출 것도 맞추게 됨
      • 단점: 비쌈. API 호출 여러번 필요. 3번 질문했을 경우, 그걸 가지고 생각하게 하는 호출 추가로 1회 필요 (총 4회) → 비용 4배. 실무에서는 30번은 호출해야 함
    • Diversity of Thoughts (DoT)
      • 같은 프롬프트가 아닌 다양한 관점에서 호출
      • 3개의 Approach 요구(단순 접근, 대수 사용, 시각화 사용)하여 호출 횟수 줄임. 30회 → 5회
    • Self-Notes
      • 채팅이 길어지면 앞의 말을 기억을 못하는데, 이 접근 방식은 앞의 내용을 기억하여 연결시킴
      • context 길이를 늘인 효과: API 호출 줄임
    • Self-Discover
      • 사람의 문제 해결 방식을 모티브로 함
      • 사전에 다양한 추론 방식(reasoning module) 정의(귀납법, 연역법 등). 그 방식 중 LLM이 해결 방식을 고르도록 함
      • 역시 API 호출 줄임. 모듈 목록 주는 콜, 모듈 고르는 콜 2개로 가능
    • Optimizer Instruction: 매직 프롬프트
      • 간단한 지침을 추가한 것
      • 차근차근 생각해봐, 잘하면 팁 100달러 줄게(답변 길이 10% 증가), please 넣기, 이건 내 인생에서 정말 중요한 문제야, 협박(틀리면 맞는다, 숙제 많이 준다) 등
      • 34.0 → 84.2 정도로 증가
      • 너무 과도하게 하면 Hallucination 증가할 수 있음 (욕심이 많아져서)
      • 사람들이 한 말을 학습한 것이니, 팁 주면 길게 얘기해 주는구나 라고 인지하게 됨. Reddit 같은 곳에서 많이 학습했다고 함
  • chatGPT Fine-Tuning (기능 있음)
    • 데이터의 형식을 잘 맞춰서 넣어 주면(공식 문서 오류 남) 튜닝 됨
    • 데이터 1줄에 하나의 발화(대화x)가 있어야 하며, 10개 이상의 대화가 있어야 함
    • 나만의 Fine Tuning 모델을 가지고 훈련시킬 수 있음
  • RAG (Retrieval-Augmented Generation)
    • 인덱싱 데이터베이스?
    • LLM의 추가 학습 없이 생성?
    • Mixture of Experts
      • 프롬프트 엔지니어링 아님
      • 여러 전문가 모델을 합쳐 하나의 큰 모델처럼 문제를 풀어냄
      • 사람과 달리, 50점짜리 10개 모으면 성능이 올라감
      • 능력: 여러 전문가들을 모아 게임 런칭을 7분만에 함
    • Vellum
      • LLM으로 RAG 구현
      • 워크플로우 기반의 LLMops 환경 구현. 7일 무료 체험
      • txt 데이터를 넣고 나서 키워드를 주면, 관련 답변을 해 줌
      • 워크플로우 생성: 여러 LLM을 합쳐서 쓸 수 있음. deploy 하면 시스템에 넣을 수도 있음
    • Flowise.kr
      • 오픈소스
      • 한국 지사가 곧 생김
      • 로컬 환경에서 생성 가능
      • API endpoint 생성 가능하며, 변환해야 하는 python, js code도 만들어 줌
      • Local LLM 지원(Local QnA 기능) → 국내 공공기관, 대기업에서 쓰기도 좋음
        • 외부 API 사용하지 않고, 로컬 서버만 사용
        • 다만 성능은 다소 낮음
  • 최근에는 LLM 기반으로 실생활 문제를 해결하는 AI에 관한 논문 쓰고 계심
  • Q&A: RAG 툴 사용시 입력한 데이터는 어디에 저장되는가?
    • chatgpt 사용하면 거기에 데이터를 넘기는 것
    • 로컬 스토리지 구성할 수도 있음


7. Casual하게 Causality 이해하기

  • 크래프톤(PUBG) 데이터 분석가. 가짜연구소 인과추론팀
  • 인과추론과 온라인 통제실험
  • 인과추론을 배워야 하는 이유
    • 처치에 따른 결과
    • 상품 구성을 바꾸면, 구매 지표가 늘까요?
    • 마스크팩을 붙이고 자면, 피부가 좋아질까?
    • 조직이나 개인의 성장을 위한 문제
  • 인과추론의 근본적인 문제
    • 타노스의 가설 검증. 인구 줄여야 한다는 이론 (맬서스 트랩)
    • 가설: 인구를 절반으로 줄이면, 삶의 질을 개선할 수 있다
    • 실험 대상은 랜덤으로 배정 (사망 or 생존)
      • 사실적 결과: 핑거스냅으로 사망한 실험군. 반사실적 결과: 핑거스냅에서 생존한 실험군
    • 근본적인 문제: 동일 대상에 대해 서로 다른 결과를 관측할 수 없음
    • 우리가 원하는 것: 실험군의 반사실(생존), 그러나 우리가 가진 것은 대조군(생존)
      • 이상과 현실의 차이 때문 → 대조군을 실험군의 반사실과 최대한 유사하게 디자인
    • 인과 vs 상관분석 다른 이유: 편향 때문. 현실상 실험군의 반사실 vs 대조군 차이가 있음
    • AB 테스트처럼 무작위 배정만 편향을 제거할 수 있을까?
    • 편향 제거를 위한 실험 디자인
      • 매칭 (exact 매칭): 실험/대조군을 유사한 대상끼리 짝지음
      • 통제집단합성법: 통제집단 대조군. 처치가 없을 때 실험군과 비슷한 가상의 대조군 생성. 패널 데이터에서 활용하는 방법
    • 요약: 신현준과 즐라탄. 대조군을 최대한 비슷하게 설계?
  • 기안84의 인과추론
    • AOMG 브랜드 컨설팅 편 (기안이 문제 해결시 근거를 제시)
    • 문제 해결 사이클: 문제 정의 → 가설 설정 → 실험 설계 → 실험 분석 → 의사결정
  • AOMG 문제 가정: 앱 다운로드 늘리고 싶은데, 마케팅 예산이 없음
    • 문제 정의: AOMG 로고 변경 요청
    • 가설 설정: 로고를 바꾸면, 앱스토어 방문 유저에 대한 스토어 전환율이 높아지지 않을까? (INTP에게 위화감 조성하니, 모든 MBTI를 아우르는 로고)
    • 실험 설계
      • 육하원칙에 근거. 왜(실험/가설 검증), 언제(실험 기간), 무엇(로고 변경) 등
      • 편향 제거(무작위 배정). 교란 요인(MBTI)의 효과 제거하여 로고 변경 효과 알 수 있도록 함
    • 실험 분석
      • 10.9%p 증가했다면, 증가분이 믿을 만한 수치인가? → p-value
      • 무작위 배정은 잘 이루어졌는가? (실험 설계 확인)
      • MBTI 외에 실험에 영향을 주는 요소
      • 외적 타당성 조사. 이 실험이 다른 실험에도 적용 가능한지
      • 리포트 & 시각화를 통해 자료 신뢰성 확보
    • 의사결정
      • 분석 결과가 좋았다고 해도, 실행(운영) 리소스 고려
  • 요약
    • 문제해결 방법 중 하나 (AB 테스트를 통한 인과추론)
    • 도메인 지식 + 커뮤니케이션이 더 중요. 제품을 이해하지 못하면(게임을 많이 하지 않으면) 유저를 이해할 수 없음. 조직원과 대화도 많이 필요
    • 분석 리포트 제시할 때, 기획자는 데이터 지식이 부족할 것. 근데 분석가는 기획자만큼 제품에 대해 이해하고 있는가? 그러면 허황된 얘기 한다는 말 들을 것
    • 실험 설계가 어려운 회사나 환경에서는, 최소한의 지표 위주로 성공 스토리를 쌓아가야 함


8. Low code, No code가 AI를 만나면 가능한 시나리오와 데모

  • Microsoft Power Platform 소개 (데이터 수집 및 활용 도구)
  • Power Platform: 로우 코드, 노 코드, 프로 코드 플랫폼
    • Power Apps
    • Power Automate: 업무 자동화
    • Power BI: BI 툴. 다양한 분석결과 보고 의사결정
    • Copilot Studio: 과거 Virtual Agent(챗봇 시나리오 생성 툴). 여기에 AI 기능을 얹음
    • Power Pages
    • 이걸 지원하는 툴들: 데이터 커넥터(외부 데이터 연동), AI 빌더, Managed Environments(python 가상환경 생성) 등
  • Power Automate: 클라우드 기반
    • RPA: 사용자의 행동 모방하여 프로세스 자동화 (아웃룩, 그룹웨어 켜기 등)
    • DPA: RPA보다 빠르고 안정적이지만, 범용성 떨어짐. 자동화하려는 시스템이 API를 제공해야 함. API 없는 경우 많음
    • BPM: 비즈니스 프로세스 매니지먼트. Dynamics 365 개념?
  • AI 허브
    • 사용자 지정 모델(내가 데이터 준비하여 모델 학습), 지정하지 않은 모델(이미 학습되어 있는 모델. 신분증 인식, 송장에서 번호 인식, 영수증에서 정보 추출 등)로 구분됨
  • RPA (화면 자동화)
    • 예시: 매일 아침 홍보팀에서 조기 출근하여 관련 기사 수집하는 과정을 모방하여 자동화 (기사 스크래핑 후 메일 전송)
    • 출장비 계산. 출장 거리, 표준 유류비(자가용 이용시), 교통비(KTX 이용시) 등 데이터 이용
    • 레코더 켜서 내가 하는 작업을 보여주면, 그걸 모방함
    • 윈도우 11에 있는 기능!! MS Store에서 Power Automate 받으면 됨 (premium 기능 빼고 지원)
    • 화면 자동화 기능은 Power Automate Desktop에서만 가능
    • 블로그 글 수집 후 특정 상품에 대한 장단점 요약 가능
    • 크롤러는 사이트에서 크롤러 차단할 수 있지만, RPA봇은 봇인지 사용자인지 구분 못함. selenium 같은 건 막음
      • 다만 해외 사이트에서는 팝업 띄워 막는 경우가 있음. 근데 그런 사이트는 보통 API 서비스로 제공. 화면으로는 들어오지 말라는 것
    • 질문: 셀레늄처럼 사용자 액션 하면 중단되나?
      • 기본적으로는 중단됨. 단 PIP 기능으로 작업하면서 동작시킬 수 있음. 현재는 초기 버전이라 매끄럽지 않으나, 점차 개선될 것으로 예상
  • Copilot Studio는 라이트한 기능. 모델 Fine Tuning 원하면 Azure AI Studio 가능


후기

회사와 같은 건물에서 하는 데놀 이거 귀하군요.. 참가자들 중 아무도 몰랐겠지만, 우리 회사와 같은 건물에 있는 MS에서 진행하는 컨퍼런스였다. 19년도에도 같은 장소에서 진행했었는데, 그 때는 나도 지금 회사에 들어오기 전이었고, 당연히 우리 회사가 여기 있는 줄도 몰랐다. 이번에도 나 빼고는 아무도 몰랐을 것이다. 내 명찰을 누가 지나가다 보고 인식했는지도 모르겠다.

각설하고, 요즘 블로그에 올린 글이 데놀, 파이콘 후기 뿐이다… 공부 정말 해야 하는데, 자극이 많이 되는 시간이었다. 개인적으로는 작년보다 더 체득할 게 많았던 것 같다. AI, LLM 툴을 잘 안 쓰고 있는데, chatGPT에서 GPT4o 버전도 제한적으로 제공하고 있으니 앞으로는 작업에 많이 활용해야겠다.

chatGPT가 불러 일으킨 AI, LLM 혁명으로 시대가 많이 바뀐 것을 느낀다. 이제는 chatGPT뿐만 아니라 전반적인 SW들이 모두 AI 기능을 제공한다. 열심히 구글링해서 직접 검색하고, 필요한 그림 있으면 역시 구글링하거나 한땀 한땀 matplotlib으로 그리던 시대가 아니다. 말만 잘 하면 AI가 알아서 찾아 주거나 만들어 준다. 이번에도 boxplot을 직접 그리지 않고 chatGPT를 통해 만드신 분이 있었다. 잘 활용만 한다면 산업 전반에서 작업 속도가 이전보다 배 이상은 빨라졌을 것 같다. 이걸 나만 안 쓰고 있었다.

나름 데이터 일을 한다는 사람이 아직도 2020년의 습관에 머물러 있다니.. 남은 올해는 부지런히 공부하고 블로그 써야겠다.