github·2026년 6월 19일·4분 읽기큐레이션 요약

내부 데이터 분석 에이전트를 구축한 방법

GitHub는 사내 데이터 웨어하우스에 자연어로 질문하면 SQL을 작성하고 결과를 해석해 주는 GitHub Copilot 기반 분석 에이전트 ‘Qubot’을 구축했다. Qubot은 대시보드나 정기 리포트의 대체재가 아니라, 데이터 모델·필터·쿼리 작성법을 몰라도 탐색적 분석을 수행하도록 돕는 도구다. 핵심 성공 요인은 데이터에 대한 구조화된 컨텍스트와 자동화된 평가 체계이며, 이를 통해 분석 정확도뿐 아니라 응답 속도도 크게 향상됐다. ## Qubot의 목적과 활용 범위 - GitHub의 여러 제품·엔지니어링 팀이 데이터 분석가의 도움 없이 제품 텔레메트리를 활용하도록 지원한다. - 사용자는 다음과 같은 탐색적 질문을 자연어로 입력할 수 있다. - 특정 기능의 유지율이 가장 높은 사용자 코호트는 무엇인가? - 지난주 특정 지표의 변화에 가장 큰 영향을 준 제품은 무엇인가? - 정기 보고서나 대시보드를 대체하지 않고, 데이터셋을 빠르게 이해하고 가설을 검증하는 데 초점을 둔다. - 데이터 분석 지원 요청을 줄이고, 데이터 웨어하우스를 사용해 본 적이 적은 직원도 의사결정에 필요한 데이터를 직접 탐색할 수 있게 한다. ## 세 가지 핵심 구성 요소 Qubot은 사용자 인터페이스, 컨텍스트 계층, 쿼리 엔진으로 구성된다. - **사용자 인터페이스** - Slack, VS Code, Copilot CLI에서 사용할 수 있다. - Slack에서는 채널에 질문을 올리면 GitHub.com에서 Copilot Cloud Agent가 실행된다. - 답변은 Slack에 바로 게시되며, 스레드에서 질문을 추가로 구체화할 수 있다. - 분석 결과는 Markdown 보고서로 작성되어 Pull Request에 저장된다. - VS Code와 Copilot CLI에서는 플러그인 설치 후 다른 에이전트·스킬·도구와 함께 사용할 수 있다. - **컨텍스트 계층** - 데이터의 관리 수준에 따라 서로 다른 정보를 제공한다. - Bronze 데이터에는 제품 팀이 제공한 이벤트 스키마와 메타데이터가 포함된다. - Silver 데이터에는 예시 쿼리, 사용 지침, 필수 필터 등이 포함된다. - Gold 데이터에는 해당 데이터셋을 소유한 팀이 정의한 비즈니스 규칙과 지표 정의가 포함된다. - ETL 파이프라인이 추가 신호와 파생 메타데이터를 자동으로 보강한다. - 에이전트는 실행 시점에 GitHub MCP Server를 통해 필요한 컨텍스트를 가져온다. - **쿼리 엔진** - GitHub의 주요 분석 엔진인 Kusto와 Trino를 MCP 서버로 연결한다. - Kusto는 최근 이벤트 데이터를 빠르게 탐색하는 데 적합하다. - Trino는 복잡한 조인과 장기간의 이력 분석에 적합하다. - 사용자가 엔진을 직접 선택하지 않아도 Qubot이 기본적으로 Kusto를 사용하고, 복잡한 질문에는 Trino로 자동 전환한다. ## 컨텍스트 에이전트와 지식 관리 - 컨텍스트 정보는 여러 저장소에 Markdown 형태로 관리된다. - 팀은 표준 템플릿을 사용하거나 관련 컨텍스트가 있는 저장소를 참조해 지식을 기여할 수 있다. - 컨텍스트 에이전트가 정보를 수집한 뒤 정리·정규화해 Qubot이 활용하기 쉬운 구조로 변환한다. - 데이터 모델 자체보다 데이터의 의미, 올바른 필터, 지표 정의, 사용 사례를 함께 제공하는 것이 에이전트의 분석 품질을 높이는 핵심이다. ## 자동화된 평가 프레임워크 - 컨텍스트나 에이전트 설정이 변경될 때마다 배포 전에 오프라인 평가를 수행한다. - 평가 대상은 정확도뿐 아니라 적절한 답을 찾는 데 걸리는 시간과 기존 기능의 회귀 여부다. - 평가 프레임워크는 다음 세 부분으로 구성된다. - **테스트 케이스**: 정답, 기준 SQL, 도메인, 난이도를 포함한 표준 질문 집합 - **실행 오케스트레이션**: GitHub CLI의 `gh agent-task create`를 이용해 테스트를 병렬 실행하고 JSON 결과를 저장 - **통계 집계**: 테스트별 완료율, 정확도, 평균·최소·최대 소요 시간을 계산 - 전체 과정은 테스트 정의 → 여러 차례 실행 → 결과 수집 → 통계 집계 → 설정 비교 순서로 진행된다. - 이를 통해 컨텍스트 추가나 에이전트 변경이 실제 품질 향상으로 이어지는지 검증할 수 있다. ## 도입 효과와 핵심 교훈 - Qubot은 수백 명의 사용자가 수천 건의 쿼리를 실행할 정도로 확산됐다. - 데이터·분석 Slack 채널에 반복적으로 들어오던 질문이 크게 줄었다. - 사용자는 간단한 질문을 직접 해결하고, 분석 전문가는 더 복잡한 문제에 집중할 수 있게 됐다. - Slack, VS Code, Copilot CLI를 함께 제공해 기술 수준과 업무 방식에 따른 진입 장벽을 낮췄다. - 실험 결과, 잘 구조화되고 큐레이션된 컨텍스트는 Qubot의 정확도를 높였을 뿐 아니라 올바른 답을 반환하는 속도도 약 3배 향상시켰다. - 따라서 데이터 문서, 지표 정의, 사용 규칙 같은 컨텍스트 자산을 단순한 문서가 아니라 분석 시스템의 핵심 구성 요소로 관리해야 한다. 실무적으로는 처음부터 모든 데이터를 자동 분석하려 하기보다, 자주 묻는 도메인부터 표준화된 컨텍스트와 기준 테스트를 구축하는 접근이 적합하다. 또한 여러 쿼리 엔진을 사용한다면 사용자가 엔진을 선택하지 않아도 되도록 에이전트가 질문 특성에 따라 자동 라우팅하도록 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)

data-analyticsAI 에이전트모델 컨텍스트 프로토콜slack+4

toss·2026년 6월 16일·4분 읽기큐레이션 요약

2,800만 MAU를 이해하는 유저 Segmentation, TUES

토스의 TUES(Toss User Engagement Segment)는 유저의 서비스 이용 패턴을 기반으로 전체 MAU를 서로 겹치지 않게 분류하는 플랫폼 관점의 세그먼트다. V1은 앱 오픈 시 서비스 이용 확률과 K-Means를 활용했지만, 이용 깊이와 복합적인 서비스 사용 패턴을 충분히 반영하지 못했다. V2는 이용 횟수, Soft Clustering, 서비스별 관여도를 도입해 유저의 현재 상태와 다음 성장 액션을 더 정교하게 파악할 수 있도록 개선됐다. ### 플랫폼 관점의 유저 세그먼테이션이 필요한 이유 - 서비스별로 “A 서비스를 이용한 유저”, “B 서비스를 이용한 유저”를 따로 분류하면 한 유저가 여러 그룹에 중복 포함된다. - 플랫폼 전체 유저를 분석하려면 서로 겹치지 않으면서 전체를 포괄하는 MECE한 분류 체계가 필요하다. - TUES는 유저가 어떤 서비스를 주로 이용하고, 토스 앱을 어떤 목적과 패턴으로 사용하는지 파악하기 위한 도구다. ### TUES V1: 서비스 이용률 기반 분류 - 유저가 앱을 열 때마다 각 서비스를 이용할 확률을 계산했다. - 예: 한 달간 앱을 60회 열고 토스페이를 20회 이용하면 이용률은 33%다. - 서비스별 이용률 분포가 비슷한 유저를 K-Means Clustering으로 묶었다. - 머신러닝 결과를 그대로 사용하지 않고, 주요 서비스와 특징을 분석해 비즈니스와 제품 관점에서 이해하기 쉬운 세그먼트로 재구성했다. - 주요 세그먼트는 다음과 같다. - **고관여**: 여러 서비스를 높은 수준으로 이용하는 유저 - **서비스 지향군**: 토스뱅크, 토스증권, 조회, 혜택, 송금 등 특정 서비스를 주로 이용하는 유저 - **단순 방문**: 앱은 방문하지만 서비스를 거의 이용하지 않는 유저 ### TUES의 주요 활용 - **세그먼트 전환 전략 수립** - 세그먼트별 Retention 차이를 바탕으로 이탈을 줄이고 다음 단계로 이동시키는 전략을 세운다. - 단순 방문 유저를 서비스 지향 유저로, 서비스 지향 유저를 고관여 유저로 전환하는 흐름을 분석한다. - **제품 Growth 전략** - 각 제품의 주요 사용자가 어떤 TUES 세그먼트에 속하는지 파악해 성장 전략을 설계한다. - **유저 행동 분석** - 세그먼트가 언제, 어떤 계기로 바뀌는지 분석할 수 있다. - 이탈 유저, 부활 유저, 서비스 간 이동 패턴도 플랫폼 관점에서 확인할 수 있다. - **탑라인 지표 분석** - 전사 MAU가 변했을 때 어떤 세그먼트가 증감했는지 확인해 변화의 원인이 된 서비스를 추적한다. - 유저 단위로 MAU 증감 원인을 MECE하게 분석할 수 있다. - **타겟 마케팅** - 서비스별 상황에 적합한 세그먼트를 선정해 푸시 등 마케팅에 활용한다. - 토스의 마케팅 도구 TUBA에도 기본 세그먼트로 제공돼 마케터가 쉽게 사용할 수 있다. ### TUES V1의 한계 - **이용 깊이를 반영하지 못함** - 앱 오픈당 서비스를 한 번 이용한 유저와 여러 번 이용한 유저가 동일하게 취급됐다. - **다른 서비스의 관여도를 파악하기 어려움** - 같은 조회서비스 지향 유저라도 혜택서비스를 함께 이용하는 정도가 다르지만 이를 표현하지 못했다. - **한 유저를 하나의 세그먼트로만 분류** - Hard Clustering 방식이라 여러 서비스를 동시에 사용하는 유저의 복합성을 담기 어려웠다. - **신규 핵심 서비스 반영 부족** - 토스쇼핑, 앱인토스, 토스페이 등 새 서비스가 기존 분류에서 ETC로 처리됐다. ### TUES V2의 개선 방식 - **이용률에서 이용 횟수 기반으로 변경** - 서비스별 이용 횟수를 앱 오픈 횟수당 Feature로 사용해 서비스 이용의 깊이를 반영했다. - **Soft Clustering 도입** - 유저를 하나의 세그먼트에 고정하지 않고 여러 세그먼트에 대한 소속 정도를 계산한다. - 여러 서비스를 함께 사용하는 유저의 복합적인 이용 패턴을 표현할 수 있다. - **세 단계 세그먼트 구조 적용** - 서비스별 관여도 - 전체 앱 관여도 - 주 이용 서비스 - 이 구조를 통해 유저가 특정 세그먼트에 속한 이유를 더 상세히 설명하고, 다음 행동(Next Action)을 구체적으로 설계할 수 있게 됐다. ### V2로 가능해진 분석 - 예를 들어 “준고관여·혜택서비스 지향 유저가 고관여로 이동하려면 어떤 서비스 관여도를 먼저 높여야 하는가?”를 분석할 수 있다. - 서비스별 관여도가 Cross Activation 전략의 출발점이 된다. - 각 서비스 조직(Silo)은 자신의 서비스 관여도를 높이는 활동이 전사 세그먼트와 성과에 미친 영향을 정량적으로 추적할 수 있다. - 서비스 이용자와 미이용자의 관여도 수준을 비교해 제품 Growth 전략의 우선순위를 정할 수 있다. ### 향후 발전 방향 - 서비스 유사도 등을 활용해 세그먼트 전환 전략을 빠르게 도출하는 분석 프레임워크 구축 - 유저 프로파일과 서비스 이용 패턴을 결합한 전략적 유저 맵 개발 - MTVi 등 다른 분석 프레임워크와 결합해 세그먼트별 서비스 가치를 정량화 TUES의 핵심은 단순한 유저 분류가 아니라, “현재 어떤 유저인지”와 “어떤 액션을 통해 다음 단계로 이동시킬지”를 연결하는 데 있다. 플랫폼 서비스에서는 서비스별 지표만 따로 보기보다, 전체 관여도와 서비스 간 이용 패턴을 함께 분석하는 세그먼트 체계를 구축하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

data-analytics머신러닝soft-clusteringuser-segmentation+4

aws·2026년 3월 13일원문

Amazon S3 20주년과 다음 단계 구축 | Amazon Web Services (새 탭에서 열림)

Amazon S3는 2006년 출시 이후 20년 동안 단순한 객체 스토리지를 넘어 전 세계 데이터 및 AI 워크로드의 핵심적인 보편적 기반으로 진화했습니다. 기술적 혁신을 통해 11나인(99.999999999%)의 내구성과 완벽한 하위 호환성을 유지하면서도, 비용을 85% 절감하고 엑사바이트 단위의 확장을 실현하며 클라우드 인프라의 표준을 제시하고 있습니다. **비약적인 규모의 확장과 경제성 확보** * 2006년 당시 1PB 수준이었던 총 용량은 현재 500조 개 이상의 객체와 수백 엑사바이트의 데이터를 수용하는 규모로 성장했습니다. * 최대 객체 크기는 5GB에서 50TB로 1만 배 증가했으며, 초당 요청 수는 전 세계적으로 2억 건을 상회합니다. * 기가바이트당 비용은 출시 초기 15센트에서 현재 약 2센트로 85% 감소했으며, 'S3 Intelligent-Tiering'을 통해 고객들은 표준 대비 60억 달러 이상의 비용을 절감했습니다. * S3 API는 업계 표준이 되어 수많은 벤더가 이를 채택하고 있으며, 2006년에 작성된 코드가 수정 없이 오늘날에도 그대로 동작할 만큼 엄격한 하위 호환성을 보장합니다. **규모의 한계를 극복하는 엔지니어링 혁신** * **지속적 데이터 감사:** 마이크로서비스 기반의 감사(Auditor) 시스템이 모든 바이트를 실시간으로 검사하며, 열화 징후가 발견되는 즉시 자동 복구 시스템을 가동하여 데이터 손실을 방지합니다. * **수학적 정확성 증명:** 인덱스 하위 시스템과 액세스 정책 등에 정형 기법(Formal methods)과 자동 추론을 적용하여 시스템의 일관성과 정확성을 수학적으로 증명합니다. * **Rust 언어 전환:** 성능에 민감한 요청 경로와 디스크 스토리지 코드를 Rust로 재작성하여 메모리 안전성을 확보하고, 대규모 운영 환경에서 발생할 수 있는 버그를 컴파일 단계에서 제거했습니다. * **규모의 경제 활용:** "규모가 곧 장점"이라는 철학 아래 시스템이 커질수록 개별 워크로드 간의 상관관계가 낮아지도록 설계하여 전체적인 안정성을 높였습니다. **데이터와 AI를 위한 미래 지향적 기능** * **S3 Tables:** Apache Iceberg 테이블을 완전 관리형으로 제공하며, 자동화된 유지보수를 통해 쿼리 효율을 높이고 스토리지 비용을 최적화합니다. * **S3 Vectors:** RAG(검색 증강 생성) 및 시맨틱 검색을 위해 최대 20억 개의 벡터를 인덱싱하며, 100ms 미만의 낮은 지연 시간으로 네이티브 벡터 검색을 지원합니다. * **S3 Metadata:** 대규모 버킷을 일일이 나열(List)하지 않고도 중앙 집중식 메타데이터를 통해 즉각적으로 데이터를 발견할 수 있어 데이터 레이크 분석 시간을 획기적으로 단축합니다. **권장 사항** S3는 이제 데이터를 저장만 하는 공간이 아니라, 데이터를 이동시키지 않고도 직접 분석하고 AI 모델에 활용할 수 있는 통합 플랫폼입니다. 비용 효율성을 극대화하기 위해 'Intelligent-Tiering'을 기본적으로 활용하고, 복잡한 데이터 파이프라인 대신 'S3 Tables'나 'S3 Metadata' 같은 최신 기능을 도입하여 데이터 관리의 복잡성을 줄이는 전략이 필요합니다.

data-analytics데이터베이스 설계RustAPI+4

google·2026년 3월 12일원문

AI 기반 돌발 홍수 예측을 통한 도시 보호 (새 탭에서 열림)

구글 리서치는 뉴스 데이터를 기반으로 한 새로운 AI 학습 모델을 개발하여 전 세계 도시 지역의 돌발 홍수(flash flood)를 최대 24시간 전에 예측할 수 있는 기술을 공개했습니다. 기존의 하천 홍수 예측과 달리 관측 장비가 부족한 지역에서도 정확한 경보를 제공할 수 있어, 전 지구적인 기상 재해 대응 격차를 줄이는 데 결정적인 역할을 할 것으로 기대됩니다. 이번 확장은 전 세계 20억 명 이상을 보호하려는 구글 홍수 예측 이니셔티브의 중요한 진전입니다. **데이터 공백과 돌발 홍수 예측의 한계** * 돌발 홍수는 전 세계 홍수 관련 사망자의 약 85%를 차지하며, 집중 호우 후 6시간 이내에 발생하여 대응이 매우 어렵습니다. * 하천 홍수는 수위계를 통한 '지상 관측 데이터(ground truth)'가 존재하지만, 돌발 홍수는 관측 장비가 없는 곳에서 급격히 발생하여 학습용 데이터를 확보하기 어렵습니다. * 특히 개발도상국이 집중된 글로벌 사우스(Global South) 지역은 고가의 물리 센서나 고해상도 수문 지도가 부족해 기존 예측 시스템의 혜택을 받지 못하는 '경보 격차'가 존재해 왔습니다. **비정형 데이터를 활용한 'Groundsource' 방법론** * 구글은 과거 돌발 홍수 사건의 시점과 위치를 파악하기 위해 공개된 뉴스 기사를 분석하는 'Groundsource' AI 기술을 도입했습니다. * 대규모 언어 모델인 제미나이(Gemini)를 활용하여 비정형 뉴스 데이터에서 홍수 발생 정보를 정밀하게 추출하고, 이를 기반으로 과거 홍수 사건 데이터셋을 구축했습니다. * 이 데이터셋을 통해 물리적 센서가 없는 지역에서도 AI 모델이 홍수의 패턴을 학습하고 예측할 수 있는 기초를 마련했습니다. **글로벌 스케일링을 위한 모델 구조 및 입력 데이터** * 시계열 데이터 처리에 최적화된 **LSTM(Long Short-Term Memory)** 유닛 기반의 **순환 신경망(RNN)** 아키텍처를 사용합니다. * 기상 예측 데이터뿐만 아니라 도시화 밀도, 지형, 토양 흡수율과 같은 정적인 지리적·인류학적 속성을 모델에 통합했습니다. * 특정 지역의 고비용 센서 대신 NASA, NOAA의 위성 데이터와 구글 딥마인드의 AI 기상 예측 모델(GraphCast) 등 전 지구적으로 사용 가능한 데이터만을 활용하여 확장성을 확보했습니다. * 현재 20x20km 공간 해상도로 작동하며, 뉴스 데이터가 풍부하고 인구 밀도가 높은 도시 지역(100명/km² 이상)을 우선적으로 지원합니다. **성능 평가 및 지리적 평등성 실현** * 모델 평가 결과, 뉴스 기반 학습 모델은 장비가 부족한 남미나 동남아시아 지역에서도 선진국 수준의 예측 정확도(정밀도 및 재현율)를 기록했습니다. * 실제 홍수가 뉴스에 보도되지 않아 오탐으로 분류된 사례를 수동 검수하여 모델의 실질적인 신뢰도가 지표보다 더 높음을 확인했습니다. * 이번 기술 도입을 통해 선진국과 개발도상국 사이의 재난 정보 불균형을 해소하고, 전 세계 어디서나 돌발 홍수에 대비할 수 있는 기반이 마련되었습니다. **실용적 의의** 돌발 홍수 경보가 12시간만 앞서 제공되어도 피해를 60%까지 줄일 수 있다는 점을 고려할 때, 구글의 24시간 예측 시스템은 인명과 재산을 보호하는 강력한 도구가 될 것입니다. 사용자는 구글의 'Flood Hub'를 통해 이러한 실시간 예측 정보를 확인할 수 있으며, 이는 기후 변화에 따른 극한 기상 현상에 대한 커뮤니티의 복원력을 크게 향상시킬 것입니다.

data-analyticsAI머신러닝flood-forecasting+4

discord·2026년 2월 18일원문

디스코드 체크포인트가 출시 (새 탭에서 열림)

Discord는 2025년을 마무리하며 사용자의 활동 기록을 한눈에 살펴볼 수 있는 첫 번째 연말 결산 기능인 ‘Discord 체크포인트(Discord Checkpoint)’를 출시했습니다. 이 기능을 통해 사용자는 지난 한 해 동안 보낸 메시지 수, 음성 채팅 시간, 가장 많이 대화한 친구 등 플랫폼 내에서의 활동을 구체적인 데이터로 확인할 수 있습니다. 이는 사용자가 한 해 동안 Discord에서 쌓은 추억과 기여를 되돌아보고 커뮤니티와의 유대감을 강화하는 계기를 제공합니다. **Discord 체크포인트의 주요 통계 및 확인 방법** * 지난 1년간 전송한 메시지 총량과 음성 채팅 채널에 머문 시간 등 활동량을 수치로 보여줍니다. * 가장 자주 사용한 이모지, 가장 오래 머무른 서버, 그리고 가장 빈번하게 소통한 '베스트 프렌드'가 누구인지 분석하여 제공합니다. * 데스크톱 앱 우측 상단의 깃발 아이콘이나 모바일 앱 '사용자(You)' 탭에 표시되는 체크포인트 배너를 통해 바로 접속할 수 있습니다. * 체크포인트를 확인하기 위해서는 앱을 최신 버전으로 업데이트해야 하며, 설정 내 ‘데이터를 사용하여 환경 개인화’ 옵션이 활성화되어 있어야 합니다. **개인별 카드 매칭과 한정판 보상** * 사용자의 활동 패턴에 따라 총 10가지의 서로 다른 '체크포인트 카드' 중 하나가 결과로 부여됩니다. * 각 카드에는 그에 어울리는 전용 아바타 장식이 포함되어 있어, 본인의 활동 성향을 프로필에 표현할 수 있습니다. * 제공되는 한정판 아바타 장식은 2026년 1월 15일까지 착용할 수 있어 연말연시 분위기를 더해줍니다. **공유 옵션 및 프라이버시 관리** * 분석된 결과 요약본을 채팅창에 간편하게 공유하여 친구들과 결과를 비교하거나 대화를 나눌 수 있습니다. * 모든 데이터는 기본적으로 본인만 볼 수 있는 비공개 상태로 유지되며, 공유 여부는 사용자가 직접 결정할 수 있습니다. * 활동량이 충분하지 않은 계정의 경우 요약 데이터가 생성되지 않을 수 있으므로 참고가 필요합니다. Discord를 꾸준히 이용해 온 사용자라면 지금 바로 앱을 업데이트하여 본인의 2025년 기록을 확인해 보시기 바랍니다. 특히 기간 한정으로 제공되는 아바타 장식은 자신의 활동 정체성을 나타낼 좋은 기회이므로, 잊지 말고 체크포인트를 방문하여 보상을 수령하고 친구들과 추억을 공유해 보시는 것을 추천합니다.

data-analytics사용자 경험discorddata-visualization+3

aws·2025년 12월 2일원문

Amazon CloudWatch, 운영, (새 탭에서 열림)

Amazon CloudWatch가 운영, 보안 및 규정 준수 데이터를 통합 관리하고 분석할 수 있는 새로운 기능을 도입했습니다. 이 업데이트를 통해 데이터 중복과 비용을 줄이면서 여러 소스의 로그를 자동으로 정규화하고, Apache Iceberg 호환 형식을 통해 외부 분석 도구와의 연동성을 극대화했습니다. 이제 사용자는 복잡한 파이프라인 없이도 통합된 환경에서 운영 지표와 비즈니스 데이터를 실시간으로 상관 분석하여 심도 있는 인사이트를 얻을 수 있습니다. **데이터 수집 및 정규화의 간소화** * AWS Organizations와 통합되어 CloudTrail, VPC Flow Logs, AWS WAF, Route 53 리졸버 로그 등 여러 리전 및 계정의 AWS 로그를 자동으로 수집합니다. * CrowdStrike, Okta, SentinelOne, GitHub 등 타사 보안 및 생산성 도구의 로그를 수집할 수 있는 사전 구축된 커넥터를 제공합니다. * OCSF(Open Cybersecurity Schema Framework) 및 OTel(Open Telemetry) 형식을 기본 지원하여 데이터 일관성을 확보하며, Grok 프로세서를 통해 커스텀 파싱과 필드 연산을 수행할 수 있습니다. **Iceberg 호환성을 통한 데이터 개방성 및 비용 절감** * Amazon S3 Tables를 통해 Apache Iceberg 호환 형식으로 로그 데이터에 접근할 수 있는 기능을 도입했습니다. * CloudWatch 내부뿐만 아니라 Amazon Athena, Amazon SageMaker Unified Studio 등 Iceberg를 지원하는 모든 외부 도구에서 별도의 데이터 복제 없이 직접 분석이 가능합니다. * 통합 데이터 저장소 구조를 채택함으로써 여러 도구에 동일한 데이터를 중복 저장할 필요가 없으며, 복잡한 ETL 파이프라인 유지보수에 드는 운영 오버헤드를 줄였습니다. **강력한 로그 분석 및 시각화 도구** * 자연어 기반 쿼리를 비롯해 LogsQL, PPL, SQL 등 다양한 쿼리 언어를 단일 인터페이스에서 사용할 수 있습니다. * 새로운 'Facets' 인터페이스를 통해 소스, 애플리케이션, 계정, 리전 및 로그 유형별로 직관적인 필터링이 가능합니다. * 지능형 파라미터 추론 기능을 지원하여 여러 AWS 계정과 리전에 걸친 방대한 로그 그룹에 대해 효율적인 교차 쿼리를 실행할 수 있습니다. **실용적인 권장사항** 운영 로그와 보안 로그가 서로 다른 도구에 분산되어 있어 상관 분석에 어려움을 겪거나, 로그 분석을 위해 복잡한 ETL 프로세스를 운영 중인 조직에 이 기능을 적극 추천합니다. 특히 CloudWatch의 통합 관리 뷰를 통해 전체 데이터 소스를 한눈에 파악하고, OCSF 정규화 기능을 활용하여 보안 분석의 표준화를 시작하는 것이 좋습니다.

data-analytics로그 관리amazon-s3apache-iceberg+4

toss·2025년 11월 19일원문

LTV를 넘어 서비스의 가치를 측정하는 새로운 지표, MTVi (새 탭에서 열림)

토스는 기존 LTV(LifeTime Value) 지표가 가진 긴 측정 주기와 증분 측정의 어려움을 해결하기 위해 MTVi(Mid term Value - incremental)라는 새로운 지표를 도입했습니다. MTVi는 유저가 특정 서비스를 처음 경험했을 때 향후 1년간 발생하는 재무적 순증 가치를 정의하며, 이를 통해 서비스가 플랫폼 전체에 기여하는 진정한 가치를 정량화합니다. 결과적으로 토스는 서비스별 투자 효율을 판단하고 전사적인 의사결정의 우선순위를 정하는 공통의 언어로 이 지표를 활용하고 있습니다. **기존 LTV 지표의 한계와 새로운 지표의 필요성** * LTV는 보통 3~5년의 긴 기간을 전제로 하기에, 빠른 실험과 개선을 반복하는 서비스 사일로의 의사결정 속도를 따라가지 못합니다. * 투자 회수 주기가 너무 길어 마케팅 비용(CAC) 집행의 적절성을 단기적으로 판단하기 어렵습니다. * 유저 전체의 평균 가치만을 보여줄 뿐, 특정 서비스 이용으로 인해 '추가로' 발생한 증분(Incremental) 가치를 분리해내지 못한다는 맹점이 있습니다. **MTVi의 정의와 산출 로직** * MTVi는 유저가 서비스를 새롭게 경험함으로써 발생하는 '향후 1년간의 순증 재무 가치'를 의미합니다. * A/B 테스트가 어려운 환경을 극복하기 위해 인과추론 방법론인 DID(Difference-in-Difference, 이중차분법) 추정법을 사용합니다. * 특정 월에 서비스를 처음 쓴 그룹(NAU)과 쓰지 않은 그룹(NEVER)을 비교하되, 유저 특성(연령, 활동 규모 등)에 따른 왜곡을 방지하기 위해 세그먼트 단위로 나누어 정밀하게 측정합니다. * 이를 통해 서비스가 없었더라도 발생했을 '자연 성장'분을 제거하고, 해당 서비스로 인해 유도된 순수한 가치 변화만을 남깁니다. **플랫폼 관점에서의 가치 구성** * MTVi는 '서비스 자체의 직접 손익'에 '해당 서비스로 인해 발생한 플랫폼 내 타 서비스로의 전이 가치'를 더해 계산합니다. * 예를 들어 '만보기'처럼 유저에게 혜택을 퍼주어 직접 손익은 마이너스인 서비스라도, 유저를 앱에 더 자주 머물게 하여 다른 금융 서비스 이용을 이끌어낸다면 MTVi는 플러스가 될 수 있습니다. * 이러한 관점은 마이데이터나 송금 등 플랫폼의 기초가 되는 서비스들의 재무적 가치를 증명하는 근거가 됩니다. **데이터 기반 의사결정의 변화** * "유저당 1년간 평균 N원의 가치를 만든다"는 명확한 숫자를 통해 모든 팀이 동일한 기준으로 소통하게 되었습니다. * 마케팅비나 운영비 등의 투자 판단 시, 고객 획득 비용(CAC)이 MTVi를 넘지 않도록 설정하는 등 정량적인 투자 효율 가이드를 제공합니다. * 여러 서비스 중 어떤 것에 먼저 자원을 투입해야 할지 우선순위를 정하는 데 있어 객관적인 지표로 기능합니다. 플랫폼 비즈니스에서 각 서비스가 독립적인 수익을 내지 않더라도 전체 생태계에 기여하는 바를 측정하는 것은 매우 중요합니다. 토스의 MTVi 사례처럼 단순한 매출 합계가 아닌 인과관계에 기반한 '증분 가치'를 측정할 때, 비로소 서비스의 진정한 가치를 이해하고 지속 가능한 성장을 위한 자원 배분이 가능해집니다.

data-analyticscausal-inferencedifference-in-differenceunit-economics+4

figma·2025년 2월 10일·3분 읽기큐레이션 요약

의미 있는 지표 만들기 | 디자인

디자인 시스템은 컴포넌트와 문서를 만드는 데서 끝나지 않고, 사용 데이터로 실제 비즈니스 가치를 입증해야 한다. 적절한 지표를 추적하면 디자인 시스템이 작업 속도, 일관성, 확장성에 미친 영향을 정량화하고 투자와 개선의 근거로 활용할 수 있다. Figma의 실험에서는 디자인 시스템을 사용한 디자이너가 그렇지 않은 디자이너보다 작업을 34% 빠르게 완료했다. ### 디자인 시스템의 효과를 수치로 증명하기 - 디자인 시스템 사용으로 얻는 효과는 단순한 시간 절약을 넘어, 제품 전체와 일관된 디자인을 만든다는 자신감 향상으로도 나타난다. - 디자이너 7명이 주당 20시간씩 집중적으로 일하는 팀에서 34%의 효율 향상은 매주 약 3.5명의 디자이너를 추가한 것과 같은 효과다. - Vanguard는 디자인 시스템을 통해 디자인 업데이트 속도를 50% 높였다. - Headspace는 토큰과 변수를 활용해 단순한 작업에서 20~30%, 복잡한 프로젝트에서 최대 50%의 시간을 절약했다. - Swiggy는 체계적인 추적을 도입한 뒤 기능 출시 시간을 절반으로 줄였다. ### 어떤 신호를 측정할 것인가 - **라이브러리 및 컴포넌트 사용량** - 어떤 컴포넌트, 변수, 스타일이 가장 많이 사용되는지 확인한다. - 자주 사용되는 요소는 디자인 시스템의 핵심 자산으로 볼 수 있다. - 사용량이 낮은 요소는 개선하거나 폐기할 후보가 된다. - **도입률** - 팀과 프로젝트가 디자인 시스템을 실제로 얼마나 채택했는지 측정한다. - 시스템이 존재하는 것보다 실제 업무에 활용되는지가 중요하다. - **일관성 점수** - 제품 전반에서 컴포넌트와 스타일이 얼마나 일관되게 사용되는지 확인한다. - 일관성 지표는 디자인 품질과 유지보수성의 변화를 보여준다. - **절약된 시간** - 컴포넌트 재사용으로 줄어든 디자인 시간을 추적한다. - 시간 절약은 이해관계자에게 디자인 시스템의 투자 가치를 설명하기 좋은 지표다. ### 사용량 데이터가 알려주는 것 - 초기에는 컴포넌트 제작과 문서화 자체에 집중하기 쉽지만, 실제 영향력을 파악하려면 adoption과 usage를 함께 측정해야 한다. - 단순히 컴포넌트 수가 많다는 사실보다 어떤 요소가 실제 업무에서 반복적으로 사용되는지가 중요하다. - 데이터는 다음과 같은 개선 방향을 제시한다. - 자주 사용되는 요소의 품질과 문서 개선 - 사용되지 않는 요소의 원인 분석 - 중복 컴포넌트 통합 - 사용성이 낮은 요소의 재설계 또는 폐기 - 이러한 분석을 통해 디자인 시스템을 정적인 리소스가 아니라 지속적으로 개선되는 운영 체계로 만들 수 있다. ### 도구와 자동화의 활용 - 지표를 지속적으로 수집하려면 사용량과 도입률을 수작업으로 조사하기보다 도구와 자동화를 활용해야 한다. - 컴포넌트, 변수, 스타일의 사용 현황을 정기적으로 수집하면 변화 추이를 파악할 수 있다. - 자동화된 측정은 팀 규모가 커져도 동일한 기준으로 성과를 비교하고, 문제를 조기에 발견하는 데 도움이 된다. ### 데이터를 실행으로 연결하기 - 측정 자체가 목적이 아니라, 데이터를 바탕으로 디자인 시스템의 우선순위를 정하는 것이 중요하다. - 사용량이 높은 요소에는 안정성, 접근성, 문서화 개선을 우선 적용할 수 있다. - 도입률이나 일관성이 낮은 영역은 교육, 문서, 지원 프로세스를 보완해야 한다. - 시간 절약과 출시 속도 같은 지표는 디자인 시스템 팀의 활동을 제품 및 비즈니스 성과와 연결해준다. ### 확장을 고려한 측정 - 조직과 제품이 성장할수록 개인의 체감 효과보다 팀 전체의 반복 가능한 지표가 필요하다. - 사용량, 도입률, 일관성, 절약 시간 등을 지속적으로 기록하면 디자인 시스템이 확장 과정에서 효율성을 유지하는지 확인할 수 있다. - 지표는 단순한 보고용 숫자가 아니라, 디자인 시스템의 투자 방향과 운영 방식을 결정하는 기준으로 활용해야 한다. 실무에서는 모든 지표를 한꺼번에 도입하기보다 컴포넌트 사용량, 디자인 시스템 도입률, 작업 시간 절감처럼 측정하기 쉽고 의사결정에 직접 연결되는 지표부터 시작하는 것이 좋다.

원문 읽기(새 탭에서 열림)

data-analyticsFigma디자인 시스템디자인 토큰+2

figma·2023년 2월 2일·3분 읽기큐레이션 요약

핀터레스트 디자인

Pinterest의 Gestalt 디자인 시스템은 코드 사용량만으로는 전체 채택 현황을 파악하기 어렵다고 보고, Figma 안에서 디자이너들이 컴포넌트를 얼마나 사용하는지 측정하는 ‘디자인 채택률’을 도입했다. 코드 지표는 웹 플랫폼에 한정되고 실제 디자인 단계보다 늦게 나타나는 반면, Figma 지표는 웹·iOS·Android를 아우르며 초기 사용 신호를 제공한다. 이를 위해 Figma REST API 기반의 대시보드 FigStats를 만들어 컴포넌트 사용량을 전체 디자인 요소 대비 상대적으로 분석했다. ## 코드 채택률만으로는 부족한 이유 - Gestalt은 웹뿐 아니라 iOS와 Android용 디자인 컴포넌트도 제공하지만, 기존 코드 채택률은 웹 컴포넌트만 측정했다. - 새 컴포넌트가 실제 제품 코드에 도입되기까지 시간이 걸리므로, 코드 지표에는 채택 지연이 발생한다. - 디자이너가 컴포넌트를 사용하지 않으면 개발자도 해당 컴포넌트의 존재나 필요성을 알기 어렵다. - 따라서 디자인 시스템 채택은 제품 코드 단계가 아니라 디자인 단계부터 시작된다는 관점이 필요하다. ## Figma에서 디자인 채택을 측정하는 이유 - Pinterest 디자이너들의 작업은 Figma에서 이루어지므로, 디자인 시스템 사용 현황을 가장 이른 단계에서 확인할 수 있다. - Figma에서 Gestalt 컴포넌트가 사용되면 웹·iOS·Android 전반에서 향후 코드 컴포넌트를 구축할 근거로 활용할 수 있다. - 디자이너가 실제로 컴포넌트를 사용하는지 확인하면 디자인 시스템 투자 효과와 플랫폼별 개발 우선순위를 설명하기 쉬워진다. ## 단순한 인스턴스·삽입 횟수의 한계 - Figma 기본 라이브러리 분석은 팀별 컴포넌트 인스턴스 수와 삽입 횟수를 제공한다. - 예를 들어 버튼이 수십만 번 사용됐다는 사실은 알 수 있지만, 그 수치가 건강한 채택 수준인지는 판단하기 어렵다. - 대형 파일에 노드가 1,000개 있고 Gestalt 컴포넌트가 10개뿐이라면, 사용량은 존재하지만 전체 디자인의 1%에 불과하다. - 따라서 절대적인 사용 횟수보다 전체 디자인 요소 중 디자인 시스템 컴포넌트가 차지하는 비율이 더 유용한 지표가 된다. ## FigStats와 상대적 채택률 - Gestalt 팀은 Figma REST API를 사용해 FigStats라는 내부 대시보드를 구축했다. - 대시보드는 Figma 파일을 분석해 어떤 Gestalt 컴포넌트가 어느 팀과 파일에서 사용되는지 시각화한다. - 핵심은 컴포넌트 인스턴스 수 자체가 아니라, 전체 노드 또는 디자인 요소 중 Gestalt 컴포넌트가 차지하는 비중을 계산하는 것이다. - 이를 통해 파일 규모가 서로 달라도 디자인 시스템이 실제 작업에 얼마나 깊이 적용됐는지 비교할 수 있다. - 컴포넌트별 사용 현황을 보면 널리 사용되는 컴포넌트와 거의 사용되지 않는 컴포넌트를 구분할 수 있으며, 개선이나 교육이 필요한 영역도 찾을 수 있다. ## 채택 데이터의 활용 - 채택률은 디자인 시스템 팀이 제공하는 가치와 투자 대비 효과를 리더십에 설명하는 공통 언어가 된다. - 사용률이 낮은 컴포넌트는 문서화 부족, 발견성 문제, API나 시각적 설계의 불편함 때문일 수 있다. - 디자인 단계에서 사용이 확인된 컴포넌트는 향후 코드 컴포넌트로 구현할 때 우선순위를 정하는 근거가 된다. - 코드 채택률과 디자인 채택률을 함께 보면 디자인에서 제품 출시까지의 채택 흐름과 지연 구간을 파악할 수 있다. ## Figma 분석 기능의 확장 - 글 작성 당시 Figma 기본 분석은 주로 컴포넌트 인스턴스와 삽입 데이터를 제공했다. - 이후 Figma Library Analytics는 스타일과 변수 데이터까지 포함하도록 확장되었고, Enterprise 고객은 Library Analytics API를 활용할 수 있게 됐다. - 따라서 현재는 컴포넌트뿐 아니라 스타일·변수까지 포함해 조직 전체의 디자인 시스템 채택을 분석할 수 있다. 디자인 시스템의 성공을 평가할 때 단순한 사용 횟수만 보지 말고, 전체 디자인 대비 사용 비율과 플랫폼별 채택 흐름을 함께 측정하는 것이 좋다. 특히 Figma의 디자인 채택률과 코드 채택률을 연결하면 어떤 컴포넌트가 실제 제품으로 이어지는지 더 정확하게 판단할 수 있다.

원문 읽기(새 탭에서 열림)

data-analyticsFigma디자인 시스템rest-api+2

figma·2022년 10월 12일·3분 읽기큐레이션 요약

데이터를 활용하는 방법 | 피그

Figma는 서비스를 제공하는 데 필요한 **기능 데이터**와 제품 개선에 활용하는 **분석 데이터**를 구분해 수집·활용한다. 분석 데이터는 기능 개발, 성능 개선, 커뮤니티 보호를 위한 의사결정을 지원하며, A/B 테스트와 데이터 분석을 통해 사용자 경험을 정량적으로 검증한다. 글은 데이터 활용이 제품을 발전시키는 동시에 고객에게 수집 목적과 책임을 투명하게 설명해야 한다고 강조한다. ## 기능 데이터: 서비스 제공에 필요한 최소 정보 - 이메일 주소는 사용자 이름 부여와 비밀번호 재설정 등 중요한 안내에 사용된다. - 가입 시 이름과 역할을 추가로 수집하며, 이 정도의 기본 정보만으로 파일 생성과 협업을 시작할 수 있다. - 다른 클라우드 서비스와 달리 신원 확인 서류나 문서 등 민감한 정보를 일반적으로 요구하지 않는다. - 유료 플랜의 결제 정보는 Figma가 직접 처리하지 않고 결제 인프라 제공업체인 Stripe가 수집·처리한다. ## 분석 데이터: 제품 개선을 위한 사용 정보 - 사용자가 어떤 기능을 사용하는지, 사용하지 않는지, 이용 과정에서 어려움을 겪는지를 파악한다. - 플랫폼에 접근하는 방식과 같은 메타데이터도 분석 대상에 포함된다. - 사용자 의견이나 소셜미디어 반응만으로는 전체 사용 패턴을 파악하기 어렵기 때문에 정량적 데이터가 필요하다. - 데이터 과학팀이 수집된 정보를 처리·분석해 제품 개발 방향을 세운다. - 주요 활용 목적은 기능 개선, 애플리케이션 성능 최적화, Figma 커뮤니티 보호다. ## A/B 테스트를 통한 기능 개선 - Figma는 UX 리서치, 데이터 분석, 제품 직관에서 세운 가설을 실험으로 검증한다. - 새로운 기능이나 UI 변경이 사용자 행동에 미치는 영향을 정량적으로 비교해 출시 여부를 판단한다. - 공유 모달 개선 사례에서는 가입 후 첫 달에 공유 모달을 여는 사용자가 20%에 불과했고, 그중 실제 파일 공유에 성공하는 비율도 절반이었다. - Figma는 UI를 단순화하고 부차적인 기능을 별도 탭으로 옮겨 공유 과정을 쉽게 만들었다. - 실험 결과: - 초대장을 보내는 사용자 비율이 2% 증가했다. - 파일마다 초대되는 사용자 수가 2% 증가했다. - Figma Community에 작업물을 게시하려는 성향에는 부정적인 변화가 없었다. - 이 결과는 이후 공유 경험을 개선하는 작업의 방향을 설정하는 근거가 됐다. ## 성능 문제와 장애 원인 분석 - Figma의 여러 팀은 플랫폼별 애플리케이션 성능 데이터를 지속적으로 분석한다. - 분석 결과는 성능 개선 과제와 전반적인 사용자 경험 향상에 활용된다. - iOS 앱 베타 출시 후에는 충돌 발생 빈도, 충돌 상황, 영향을 받는 플랫폼을 조사했다. - 분석 결과 프로토타입이 iOS 충돌의 주요 원인 중 하나였으며, 프로토타입 관련 충돌의 25%가 로딩 시작 후 10초 이내에 발생했다. - 이처럼 단순히 충돌 횟수만 보는 것이 아니라, 특정 기능·플랫폼·사용 시점과 연결해 문제의 우선순위를 정한다. Figma의 사례는 필요한 기능 데이터는 최소한으로 수집하고, 분석 데이터는 구체적인 제품 문제를 해결하는 데 사용해야 한다는 점을 보여준다. 데이터 기반 의사결정은 사용자 행동을 더 정확히 이해하게 하지만, 실험 결과를 사용자 경험과 개인정보 보호라는 관점에서 함께 검토하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

data-analyticsiOS데이터 사이언스a-b-testing+2