line·2026년 6월 22일·5분 읽기큐레이션 요약

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 AI 시대의 업무 혁신과 역할 전환

PJ One Piece는 생성형 AI 에이전트로 비즈니스 질문, 데이터 분석, 결과 해석, 다음 액션까지 연결해 분석 업무의 단절을 없애려는 프로젝트입니다. 기존에 평균 2주 걸리던 분석을 약 10분 만에 수행할 수 있게 되었고, 사업부 구성원의 절반 이상이 사용하는 플랫폼으로 확산되었습니다. 핵심은 단순한 SQL 자동화가 아니라 도메인 지식, 분석 프로세스, 도구, 로그와 피드백을 결합해 조직의 분석 역량을 지속적으로 축적하는 데 있습니다. ## 프로젝트 출범 배경: 세 가지 단절 - **비즈니스와 데이터의 단절** - DWH와 BI가 있어도 SQL 작성, 테이블·컬럼 선택, KPI 정의, 결과 해석에는 높은 장벽이 남아 있었습니다. - 데이터에 접근할 수 있는 것과 사업 담당자가 필요한 정보를 스스로 얻는 것 사이에 ‘마지막 1마일’이 존재했습니다. - **분석 프로세스 내 단절** - 과제 정의, 분석 설계, 실행, 리뷰, 액션이 담당자와 도구의 차이로 분리되었습니다. - 사업 배경과 의사 결정 목적이 제대로 전달되지 않아 재작업이 발생했고, 단계 사이의 대기 시간으로 리드타임이 길어졌습니다. - 분석 품질이 균일하지 않고 결과가 실제 액션으로 이어지는 속도도 떨어졌습니다. - **도메인 간 단절** - 사업마다 KPI, 테이블 구조, 사용자 행동, 시책 맥락이 달라 분석 지식과 패턴이 특정 도메인에 머물렀습니다. - 시책 평가, 퍼널 분석, 원인 분석처럼 구조가 유사한 분석도 조직 전체에서 재사용하기 어려웠습니다. ## 분석 에이전트로 분석 흐름 연결 - 사용자는 채팅 형태의 화면에서 자연어로 질문을 입력합니다. - 에이전트는 질문의 목적을 해석하고 분석 계획을 세운 뒤 다음 작업을 수행합니다. - 필요한 데이터와 문서 탐색 - SQL·Python 기반 집계 및 분석 - 시각화와 보고서 작성 - 결과 해석과 추가 분석 제안 - 다음 의사 결정과 액션 검토 - 자연어 질문만으로 분석을 시작할 수 있어 사업 담당자가 데이터 사이언티스트에게 요청하고 기다리는 구조를 줄입니다. - 질문 정리, 지표 선택, 비교 축, 리뷰 관점, 추가 분석 판단을 로그로 남겨 분석 지식과 패턴을 재사용 가능한 자산으로 만듭니다. ## 분석 플랫폼을 구성하는 다섯 가지 요소 - 사용자와 상호작용하는 애플리케이션 - 추론과 도구 사용을 담당하는 LLM 기반 에이전트 - SQL·Python 실행, 사내 문서 조사, 시각화 도구 - 도메인 지식, 스킬, 테이블 정보를 제공하는 지식 베이스 - 실행 로그, 사용자 피드백, 모니터링과 평가를 담당하는 측정 시스템 - 지식 영역은 도메인별 플러그인으로 확장할 수 있으며, 사용량이 늘수록 지식과 분석 패턴이 축적됩니다. ## 자연어 질문을 분석 요구 사항으로 변환 - 사용자가 상세한 분석 설계를 직접 작성하도록 요구하지 않고, 에이전트가 부족한 전제 조건만 확인합니다. - 예를 들어 캠페인 효과 분석에는 대상 정책, 기간, KPI, 비교 대상, 분석 단위, 제외 조건 등이 필요합니다. - 서비스 이해, KPI 정의, 집계 주의사항, 정책 탐색 방법, 리뷰 관점은 도메인 지식으로 관리합니다. - 테이블과 컬럼의 의미, 사용 조건, 적절한 활용 상황도 별도로 정비합니다. - 에이전트는 이미 확정 가능한 항목과 사용자 확인이 필요한 모호한 항목을 구분해 불필요한 질문을 줄입니다. ## 필요한 데이터에 안전하게 접근하는 구조 - 대규모 테이블 정보를 한꺼번에 LLM에 제공하지 않고 단계적으로 공개합니다. - 먼저 테이블 목록으로 후보를 좁힘 - 선택한 테이블의 상세 정의 확인 - SQL 작성 전에 컬럼 설명, 샘플, 파티션 조건, 사용상 주의사항 확인 - 원천 테이블을 그대로 사용하지 않고, 분석에 적합한 속성을 결합한 와이드 테이블을 논리적 뷰나 실제 테이블로 제공합니다. - 복잡한 JOIN을 줄여 SQL 생성 난이도와 오류 가능성을 낮춥니다. - SQL 실행 전후에 시스템 차원의 가드레일을 적용합니다. - `SELECT` 중심의 읽기 전용 제한 - 공개된 테이블 정의 및 사용 규칙 검증 - 파티션 조건 확인 - 개인정보·민감 정보 접근 제한 - 결과 행 수 제어 ## 멀티 에이전트로 분석 맥락 유지 - 슈퍼바이저형 멀티 에이전트 구조를 사용합니다. - 메인 에이전트는 사용자 요청, 분석 목적, 확인된 내용, 다음 판단 과제를 계속 관리합니다. - 통계 검정, 시계열 분석, 클러스터링, 리뷰 등 전문 작업은 역할이 제한된 서브 에이전트에 위임합니다. - 전체 분석 설계와 전문 작업을 분리해 긴 시행착오나 전문 분석이 전체 맥락을 압박하지 않도록 합니다. - 장시간 분석 중에는 발견 사항, 분석 설계, 사용 가능·불가능한 데이터, 제약 조건을 공유해 사용자가 중간에 방향을 수정할 수 있게 합니다. ## 로그와 스킬을 통한 조직 자산화 - 실행 로그로 다음 내용을 추적합니다. - 입력과 출력 - 에이전트의 도구 사용 과정 - 전제 조건 확인 방식 - 분석 설계와 생성된 SQL - 오류가 발생한 지점 - 사용자와 분석 담당자의 피드백을 결합해 프롬프트, 도구, 데이터, 스킬 중 개선이 필요한 영역을 백로그로 관리합니다. - 반복되는 분석은 스킬로 일반화합니다. - 범용 스킬: 시계열 분석, 클러스터링 등 - 도메인 특화 스킬: 월간 보고서, 정책 모니터링 등 - 스킬에는 전제 조건, 비교 축, 주의사항, 결과 해석 방법까지 포함해 다른 담당자와 도메인에서도 재사용할 수 있도록 합니다. ## 선행 도입으로 확인한 사업 가치 - 일부 서비스 사업부에 도입한 결과 구성원의 절반 이상이 사용하는 분석 플랫폼으로 성장했습니다. - 데이터 사이언티스트뿐 아니라 프로덕트 오너와 현장 구성원도 일상 업무에서 먼저 질문하는 진입점으로 활용하고 있습니다. - 기존 요청부터 결과 회신까지 평균 약 2주 걸리던 분석을 약 10분 만에 실행할 수 있게 되었습니다. - 월 수백 건의 분석이 실행되며 데이터 활용 인원이 빠르게 증가했습니다. 분석 AI를 도입할 때는 SQL 생성 자동화에만 집중하기보다, 도메인 지식 관리·데이터 접근 통제·분석 맥락 유지·로그 기반 개선까지 함께 설계하는 것이 중요합니다. 특히 반복 분석을 스킬과 조직 자산으로 축적해야 단기적인 생산성 향상을 넘어 지속적으로 성장하는 분석 플랫폼을 만들 수 있습니다.

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

sql대규모 언어 모델AI 에이전트생성형 AI+4

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

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기

카카오는 기존 Hadoop 환경에 AI 에이전트를 연결해 추천 지표 분석 절차를 자동화했다. 핵심은 새로운 플랫폼이나 권한을 추가하는 것이 아니라, 사람이 알고 있던 데이터 접근 절차·지표 정의·판단 기준을 Markdown 기반 스킬과 컨텍스트 문서로 정리하는 데 있었다. AI는 분석 초안을 빠르게 만들고 다음 질문을 제안하지만, 결과의 정확성과 최종 판단은 사람이 검증해야 한다. ## 반복적인 추천 지표 분석의 비효율 - CTR 하락, 실험군 반응, 배포 후 사용자군 변화 등을 확인하려면 다음 과정을 반복해야 한다. - 분석 환경 접속 - 적절한 테이블 탐색 - SQL 작성 및 실행 - 결과 해석 - 연령대·카테고리·시간대 등 관점별 추가 분석 - 질문은 간단해도 데이터 준비와 추출에 많은 시간이 걸린다. - 반복적이고 절차가 정형화된 업무이므로 AI 자동화에 적합하다. ## Hadoop 접속 절차를 Agent Skill로 정리 - 기존 Hadoop 접속 스크립트와 실행 환경은 그대로 활용했다. - AI가 Hadoop을 사용할 수 있도록 접속·쿼리 실행 방법을 `SKILL.md` Markdown 문서로 작성했다. - 여러 스킬을 묶은 사내 플러그인 `hadoop-butler`를 통해 AI가 다음 작업을 수행하도록 했다. - Hadoop 클러스터 접속 - 분석 목적에 맞는 SQL 작성 - 쿼리 제출 및 결과 수집 - 결과 정리와 인사이트 도출 - 새로운 분석 플랫폼이나 MCP 서버를 구축하기보다, 기존 인프라에 업무 지식을 “접착제”처럼 추가한 접근이다. ## 컨텍스트 문서로 분석 기준 명시 - 분석 디렉터리에 `CLAUDE.md`, `AGENTS.md`와 같은 컨텍스트 문서를 배치했다. - 문서에는 다음 정보를 담았다. - 분석 대상 테이블과 Hadoop 클러스터 - `watch_length`, `valid_view` 등 주요 컬럼의 의미 - 사용자·세션 집계 기준 - CTR 등 주요 지표의 정의 - 명확한 기준을 문서화하면 AI가 매번 테이블과 컬럼의 의미를 추측하지 않아도 된다. - 이는 AI의 분석 품질을 높이는 동시에 팀의 데이터 지식을 문서화하고 신규 구성원의 온보딩에도 도움을 준다. ## AI는 분석 초안을 만들고 사람은 질문을 확장 - 자연어로 분석 목적을 설명하면 AI가 첫 번째 리포트와 추가 분석 후보를 제시한다. - 이상치 확인, 실험 결과 비교, 주간 현황 점검처럼 반복 업무에 특히 효과적이다. - 대시보드가 수치를 빠르게 보여준다면, 자연어 분석은 “어디를 더 살펴볼지”를 제안한다. - 사용자는 초안 결과를 확인한 뒤 세부 사용자군이나 특정 기간 등으로 질문을 이어가며 분석을 구체화할 수 있다. - AI 결과는 최종 결론이 아니라 검토 대상이며, 쿼리 기준과 지표 정의를 사람이 확인해야 한다. ## AI가 그럴듯하게 만드는 의미·성능 오류 - **의미 오류** - 사용자 수 집계에 계정 단위 식별자인 `user_id` 대신 세션 성격의 `session_user_id`를 사용할 수 있다. - 쿼리는 정상 실행되지만 실제 사용자 수 의미와 다른 결과를 낼 수 있다. - **성능 오류** - 여러 컬럼에 대해 `COUNT(DISTINCT ...)`를 한 번에 실행하는 SQL을 생성할 수 있다. - Hive에서는 이 방식이 단일 리듀서로 처리되어 매우 느려질 수 있다. - 컬럼별 쿼리를 분리해 병렬 실행하는 방식이 더 적절하다. - 문법적으로 올바른 SQL과 업무적으로 올바른 분석은 다르므로, 도메인 지식과 실행 엔진 특성에 대한 검증이 필요하다. ## 문서화와 회귀 테스트로 품질 관리 - 자주 발생하는 오류를 지침에 명시적으로 추가했다. - 사용자 수 집계에는 반드시 `user_id` 사용 - 모든 컬럼명은 백틱으로 감싸 예약어 충돌 방지 - 다중 `COUNT(DISTINCT)`는 컬럼별로 분리해 병렬 실행 - 스킬과 프롬프트가 늘면서 한 지침 수정이 다른 기능을 깨뜨리는 회귀 문제가 발생했다. - 이를 해결하기 위해 MLflow 기반 E2E 평가 파이프라인을 구축했다. - 스킬별 기대 동작을 테스트 시나리오로 정의 - 에이전트를 헤드리스 모드로 실행 - LLM Judge가 결과를 평가 - 도구 호출 순서, 실행 트레이스, 최종 출력까지 다층 검증 - 배포 전 전체 시나리오를 자동 회귀 테스트 - 자연어 지침도 소프트웨어처럼 테스트와 배포 관리가 필요하다는 점을 강조한다. ## 실용적인 도입을 위한 네 가지 요소 - **모델**: 자연어 요청을 이해하고 분석 절차를 수행하는 에이전트 - **컨텍스트**: 테이블, 피처, 지표 정의와 업무 규칙 - **실행 환경**: 실제 데이터에 접근할 수 있는 기존 Hadoop 인프라 - **검증 루프**: 결과와 도구 실행 절차를 확인하는 자동 테스트 체계 반복 업무에 AI를 도입할 때는 새로운 시스템부터 만들기보다, 기존 절차와 도메인 지식을 문서화하고 실행 환경에 연결하는 것이 효과적이다. 다만 AI의 결과를 그대로 신뢰하지 말고, 명확한 분석 기준과 회귀 테스트를 함께 마련해야 실무에서 안전하게 활용할 수 있다.

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

sqlAI 에이전트context-engineeringhadoop+4

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

도메인 전문가를 코드화하기: Spotify 데이터 어시스턴트를 뒷받침하는 컨텍스트 레이어 | Spotify Engineering

Spotify의 데이터 어시스턴트가 신뢰할 만한 답변을 제공하는 핵심은 거대한 스키마를 LLM에 모두 넣는 것이 아니라, 도메인 전문가가 선별한 맥락 계층을 구축하는 데 있다. 이 맥락은 관련 데이터셋, 검증된 질문-SQL 예시, 업무 문서로 구성되며 각 도메인 팀이 소유하고 관리한다. 결국 AI는 전문가를 대체하기보다 전문가의 지식을 여러 사용자에게 확장하는 역할을 한다. ## 대규모 데이터 환경에서 스키마만으로 부족한 이유 - Spotify에는 7만 개 이상의 데이터셋과 페타바이트 규모의 데이터가 있다. - 모든 스키마를 LLM의 컨텍스트에 넣는 방식은 다음과 같은 한계가 있다. - 컨텍스트 윈도우가 전체 데이터 웨어하우스를 담기에 부족하다. - 컬럼 타입만으로는 실제 업무 의미를 알 수 없다. - 예를 들어 `INT64` 컬럼만 보고는 테스트 데이터와 실제 데이터의 구분, 또는 “활성 사용자”의 정의를 알 수 없다. - 테이블 수가 많을수록 모델은 비슷한 테이블 중 잘못된 대상을 선택하면서도 자신 있게 답할 수 있다. - 따라서 스키마와 LLM 사이에 도메인별 의미와 사용법을 담은 별도의 맥락 계층이 필요하다. ## Spotify 데이터 에이전트의 동작 방식 - 사용자가 자연어로 질문하면 에이전트가 다음 과정을 수행한다. - 적절한 데이터 맥락을 선택한다. - SQL을 생성한다. - 데이터 웨어하우스에서 쿼리를 실행한다. - 답변, 생성된 SQL, 사용한 출처를 함께 반환한다. - ReAct 루프를 사용해 도구 호출 결과에 따라 추론과 행동을 반복하고, 필요하면 쿼리를 수정한다. - 사용자는 결과뿐 아니라 답변이 어떻게 만들어졌는지도 확인할 수 있다. - Slack 봇, IDE와 AI 도구에서 사용할 수 있는 MCP 서버, 전용 웹 UI로 제공된다. - 관련 지식 기반이 없을 경우에도 이를 명시해 답변의 한계를 투명하게 드러낸다. - 2025년 8월 기준 2,100명 이상의 사용자가 13,000건 이상의 대화에서 활용했으며, 광고·팟캐스트·음악·오디오북·재무 등 177개 클러스터를 지원한다. ## 도메인별 클러스터 모델 Spotify는 데이터 도메인을 “클러스터”라고 부른다. 클러스터는 특정 조직, 프로젝트, 이니셔티브 또는 관심 주제를 중심으로 구성되며, 각 클러스터는 이름이 지정된 전문가 팀이 소유한다. - **데이터셋** - 관련 웨어하우스 테이블과 전체 스키마를 포함한다. - 컬럼 카디널리티, 자주 등장하는 값의 샘플, 파티션 구조 등을 프로파일링한다. - 예를 들어 `country` 컬럼에 `US`, `GB`, `SE` 등이 존재한다는 정보는 모델이 적절한 `WHERE` 조건을 작성하는 데 도움을 준다. - **질문-SQL 쌍** - 전문가가 작성하거나 검토한 질문과 SQL의 조합이다. - 단순한 예시가 아니라 해당 도메인에서 권장되는 쿼리 패턴과 데이터 의미를 가르치는 few-shot 자료로 사용된다. - **문서** - 업무 용어, 팀별로 달라지는 정의, 데이터 사용 시 주의점 등을 기록한다. - 어떤 컬럼을 사용해야 하고 어떤 컬럼을 피해야 하는지도 설명할 수 있다. - 클러스터의 범위, 포함할 테이블, 중요한 예시는 데이터 과학자와 애널리틱스 엔지니어 등 도메인 전문가가 결정한다. ## 자동 생성보다 전문가 검토가 중요한 이유 - Spotify는 데이터 웨어하우스의 과거 쿼리 기록에서 질문-SQL 쌍을 자동으로 생성하는 방법을 검토했다. - 실제 쿼리이므로 유용할 것처럼 보였지만, 큐레이터가 승인한 예시는 전체의 12.5%에 불과했다. - 나머지 87.5%에는 다음과 같은 쿼리가 포함되어 있었다. - 일회성 탐색이나 디버깅 쿼리 - 다시 사용하지 않을 임시 분석 - 잘못된 테이블을 사용한 쿼리 - 기술적으로는 맞지만 다른 사용자에게 잘못된 패턴을 가르치는 쿼리 - 쿼리 기록에는 정보가 많지만, 어떤 쿼리가 표준적인 지식인지는 자동으로 표시되지 않는다. - 따라서 AI가 데이터의 진실을 결정하도록 하지 않고, 전문가가 예시를 검토하고 정식 사례로 승인한다. - 목적은 전문가를 대체하는 것이 아니라 전문가의 판단을 재사용 가능한 형태로 확장하는 것이다. ## 클러스터의 지속적인 건강 관리 데이터 스키마와 업무 규칙은 계속 변하기 때문에, 한 번 만든 맥락이 영원히 정확한 것은 아니다. - 테이블이 교체되거나 폐기될 수 있다. - 컬럼명이 변경될 수 있다. - 비즈니스 정의와 분석 방식이 달라질 수 있다. - 기존 질문-SQL 쌍이 변경된 스키마와 호환되지 않을 수 있다. - Spotify는 여러 신호를 종합해 클러스터 건강 점수를 계산한다. - 기반 데이터의 상태 - 최근 스키마 변경 이후에도 curated pair가 유효한지 여부 - 실제 사용자가 묻는 질문을 충분히 다루는지 - 생성된 SQL을 재현할 수 있는지 - 기타 품질 및 활용 지표 - 문제가 발생하면 건강 점수가 낮아지고, 전문가에게 필요한 정비 작업이 제안된다. - 클러스터 소유자는 대시보드의 점수와 세부 신호를 보고 우선적으로 관리할 영역을 결정한다. ## 사용자 대화로 이어지는 피드백 루프 - 모든 대화와 쿼리는 기록되어 클러스터 소유자에게 전달된다. - 소유자는 질문, 답변, 생성된 SQL, 사용자 피드백을 확인할 수 있다. - 전문가가 질문-SQL 쌍을 승인하거나 문서를 보완할 때마다 이후 사용자에게 제공되는 맥락이 개선된다. - 즉, 실제 사용 과정이 새로운 품질 관리와 지식 축적의 자료가 된다. - 어시스턴트의 신뢰도는 모델 자체보다 그 모델이 참조하는 맥락의 품질과 최신성에 달려 있다. ## 실용적인 시사점 데이터 AI를 구축할 때는 모든 스키마를 한꺼번에 제공하기보다, 도메인별로 범위를 나누고 전문가가 검증한 예시와 업무 규칙을 함께 관리하는 것이 효과적이다. 또한 자동 생성된 지식은 그대로 신뢰하지 말고 사람의 검토를 거치며, 스키마 변경·사용 패턴·쿼리 재현성을 기반으로 지속적인 품질 관리를 해야 한다.

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

sqlAI대규모 언어 모델모델 컨텍스트 프로토콜+4

cloudflare·2026년 5월 28일·4분 읽기큐레이션 요약

Cloudflare의 데이터 플랫폼과 그 위에 구축한 AI 에이전트 이야기

Cloudflare는 여러 데이터베이스와 스트림에 흩어진 데이터를 하나의 SQL 인터페이스로 통합하기 위해 데이터 레이크하우스 플랫폼 **Town Lake**를 구축했다. Town Lake는 신선하고 정확한 원천 데이터와 빠른 분석용 샘플 데이터를 함께 제공하며, 권한 관리·PII 탐지·감사 기능을 기본으로 포함한다. 그 위에 자연어로 질문하면 감사 가능한 답을 제공하는 AI 데이터 에이전트 **Skipper**를 구축해 데이터 접근성을 높이려 했다. ## 데이터 파편화와 접근성 문제 - Cloudflare는 초당 10억 건이 넘는 이벤트를 처리하고 330개 이상의 도시, 120개 이상의 국가에서 네트워크를 운영한다. - 데이터가 다음과 같은 다양한 시스템에 분산되어 있었다. - Postgres: 계정 및 업무 메타데이터 - ClickHouse: 분석 이벤트 - BigQuery: 집계 데이터 - R2: 원시 로그 - Kafka: 실시간 이벤트 스트림 - 시스템마다 인증 방식, 쿼리 언어, 보존 기간이 달라 간단한 질문에도 여러 시스템을 알고 있어야 했다. - 올바른 테이블과 조인 방법이 조직 내 암묵지에 의존했다. - 예를 들어 ClickHouse의 사용량 테이블과 Postgres의 고객 차원 테이블을 연결하려면 별도의 고객 ID 변환 규칙을 알아야 했다. - 기존 분석 파이프라인은 초당 7억 건 이상의 이벤트를 처리하기 위해 데이터를 샘플링했다. - 대시보드에는 적합하지만 청구 금액 계산이나 보안 조사처럼 정확한 전체 데이터가 필요한 작업에는 부적합했다. - 일부 내부 리포팅 시스템은 외부 업체와 다른 클라우드에 의존하고 있어 비용과 운영상 종속성도 발생했다. ## 구축 목표 - 적절한 권한과 업무상 필요가 있는 모든 직원이 Cloudflare 데이터를 한곳에서 조회할 수 있도록 했다. - 사용 목적에 따라 서로 다른 데이터 품질을 제공하려 했다. - 청구·보안 조사: 신선하고 정확한 비샘플링 데이터 - 대시보드·탐색: 빠른 응답을 위한 다운샘플링 데이터 - PII를 자동으로 식별하고 민감한 테이블은 기본적으로 제한했다. - 모든 데이터 접근을 감사할 수 있도록 하고, 권한을 일정 기간 동안만 부여하도록 설계했다. - R2, Workers, Cloudflare Access, Workflows 등 Cloudflare 자체 제품 위에 플랫폼을 구축했다. - 최종적으로 SQL을 몰라도 자연어로 데이터를 조회할 수 있는 인터페이스를 제공하는 것이 목표였으며, 이것이 Skipper로 이어졌다. ## Town Lake의 데이터 레이크하우스 구조 Town Lake는 오브젝트 스토리지에 저장된 데이터를 쿼리 엔진으로 조회하고, 메타데이터 계층을 통해 데이터베이스처럼 사용하는 레이크하우스 구조다. - **Apache Trino** - 통합 쿼리 엔진으로 사용된다. - 하나의 SQL 쿼리에서 Postgres, ClickHouse, R2의 Iceberg 테이블을 함께 조인할 수 있다. - 필터를 ClickHouse로 푸시하고, Postgres의 계정 차원 데이터와 R2의 청구 집계 데이터를 결합하는 식으로 쿼리를 최적화한다. - **R2 Data Catalog와 Apache Iceberg** - 차갑거나 따뜻한 데이터를 R2에 저장한다. - Iceberg의 스키마 변경, 시점 조회(time travel), 파티션 변경, 데이터 컴팩션 기능을 활용한다. - 오래된 데이터는 분 단위에서 시간 단위, 다시 일 단위로 집계해 저장 비용을 줄인다. - Parquet 파일을 R2에 저장하면 동일한 데이터를 OLAP 데이터베이스에 보관하는 것보다 비용이 낮다. - **DataHub** - 테이블, 컬럼, 소유 팀, 데이터 계보(lineage), 용어집 정보를 관리한다. - 사용자가 특정 테이블의 의미를 물으면 컬럼 설명, 담당 팀, 상위 입력 테이블, 하위 소비 테이블까지 제공한다. ## 권한 관리와 데이터 거버넌스 - **Lifeguard**가 데이터 접근 제어를 담당한다. - 접근 규칙은 D1에 저장하고, 내부 접근 관리 시스템에서 사용자·그룹 정보를 동적으로 가져온다. - 이 정보를 결합해 JSON 정책을 생성하고 Trino가 HTTP를 통해 읽도록 한다. - Skipper와 Gateway에도 기본적인 권한 정보를 전달해 쿼리가 실행된 뒤가 아니라 진입 단계에서 접근을 차단할 수 있다. - 권한을 업무 목적과 기간에 맞춰 부여함으로써 민감 데이터에 대한 불필요한 상시 접근을 줄인다. - 데이터 접근 기록을 남겨 누가 어떤 데이터에 접근했는지 감사할 수 있도록 했다. ## PII 자동 탐지 - **Skimmer**는 테이블의 모든 컬럼을 지속적으로 검사하는 PII 탐지 스캐너다. - 각 컬럼에서 행을 샘플링하고 Workers AI를 이용해 PII 포함 여부를 분류한다. - 이를 통해 데이터 카탈로그에 민감도 정보를 자동으로 반영하고, 민감한 테이블이나 컬럼의 기본 접근 정책을 강화할 수 있다. ## 자연어 데이터 에이전트 Skipper - Skipper는 Town Lake 위에서 동작하는 AI 데이터 에이전트다. - 사용자가 영어로 질문하면 관련 데이터와 메타데이터를 찾아 SQL 기반 답변을 생성한다. - 데이터 위치, 테이블 구조, 조인 관계, 권한을 사용자가 직접 알 필요를 줄이는 것이 목적이다. - 자연어 질의의 예시는 다음과 같다. - 최근 분기의 매출 기준 상위 100개 고객 조회 - 특정 ASN에서 발생한 고위험 Bot Management 이벤트 검색 - 일정 금액 이상 지출한 고객의 청구 지원 티켓 분석 - 답변은 단순한 생성형 응답이 아니라 데이터에 근거하고 감사 가능한 형태여야 한다는 점이 중요하다. ## 실용적인 시사점 데이터 플랫폼을 구축할 때는 저장소 통합만으로는 충분하지 않다. 통합 쿼리 엔진, 메타데이터 카탈로그, 데이터 계보, 세분화된 권한 관리, PII 탐지, 감사 기능을 함께 설계해야 데이터가 실제 조직 전체에서 활용된다. 또한 정확성이 필요한 업무와 속도가 중요한 분석 업무에 동일한 데이터 처리 방식을 적용하지 않고, 목적에 따라 원천 데이터와 샘플 데이터를 구분하는 전략이 효과적이다.

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

sqlAI 에이전트apache-icebergdata-governance+4

aws·2026년 5월 12일·3분 읽기큐레이션 요약

Amazon Redshift, 통합 데이터 레이크 쿼리 엔진을 탑재한 AWS Graviton 기반 RG 인스턴스 출시 | Amazon Web Services

Amazon Redshift의 새로운 RG 인스턴스는 AWS Graviton 기반으로, 기존 RA3보다 데이터 웨어하우스 워크로드를 최대 2.2배 빠르게 처리하면서 vCPU당 가격은 30% 낮춘다. 또한 데이터 웨어하우스와 Amazon S3 데이터 레이크를 하나의 엔진에서 SQL로 조회할 수 있어, Apache Iceberg는 최대 2.4배, Apache Parquet은 최대 1.5배 향상된 성능을 제공한다. 이를 통해 대규모 AI 에이전트 쿼리와 저지연 분석 workload의 비용과 운영 복잡성을 함께 줄이는 것이 핵심이다. ## 데이터 웨어하우스와 데이터 레이크를 함께 처리해야 하는 배경 - 기업은 구조화되고 자주 조회되는 데이터는 데이터 웨어하우스에, 대규모·다양한 데이터는 비용 효율적인 데이터 레이크에 저장하는 방식으로 운영하고 있다. - AI 에이전트가 사람보다 훨씬 많은 쿼리를 실행하면서 쿼리 처리량과 운영 비용이 급증하고 있다. - Redshift는 BI 대시보드, ETL, 실시간 분석, 자율형 AI 에이전트처럼 빠른 응답이 필요한 workload를 대상으로 성능 개선을 이어 왔다. - 2026년 3월에는 신규 쿼리 성능을 최대 7배 높여 BI와 ETL 응답 시간을 단축했다고 설명한다. ## AWS Graviton 기반 RG 인스턴스 - RG 인스턴스는 AWS Graviton 프로세서 기반의 새로운 Amazon Redshift 인스턴스 제품군이다. - RA3 대비 데이터 웨어하우스 workload를 최대 2.2배 빠르게 처리한다. - vCPU당 가격은 RA3보다 30% 낮다. - 고빈도 쿼리와 낮은 지연 시간이 중요한 분석 및 agentic AI workload에 적합하다. - 기존 RA3 인스턴스와 `ra3.xlplus`, `ra3.4xlarge` 및 대응하는 `rg.xlarge`, `rg.4xlarge` 구성을 비교할 수 있다. ## 통합 데이터 레이크 쿼리 엔진 - Redshift의 단일 SQL 엔진으로 데이터 웨어하우스 테이블과 Amazon S3 데이터 레이크를 함께 조회할 수 있다. - Apache Iceberg 데이터 조회 성능은 RA3 대비 최대 2.4배, Apache Parquet은 최대 1.5배 빠르다. - 데이터 레이크 쿼리는 별도의 Spectrum 서비스가 아니라 Redshift 클러스터 노드에서 실행된다. - 기존 외부 테이블, 스키마, 쿼리 문법과 Spectrum 쿼리를 그대로 사용할 수 있어 애플리케이션 코드 수정이나 외부 테이블 재생성이 필요 없다. ## 비용 및 보안상의 변화 - 데이터 웨어하우스와 데이터 레이크를 각각 별도 시스템으로 운영할 필요가 줄어든다. - 데이터 레이크 쿼리가 VPC 내부에서 실행되므로 네트워크 경계를 단순하게 유지할 수 있다. - 기존 IAM 역할을 그대로 사용할 수 있다. - Spectrum의 데이터 스캔 요금인 TB당 5달러가 발생하지 않아 전체 Redshift 비용을 낮출 수 있다. - 실제 절감액은 쿼리량, 데이터 레이크 스캔 규모, 인스턴스 구성에 따라 달라지므로 AWS Pricing Calculator로 산정해야 한다. ## 마이그레이션 방법 - AWS Management Console, AWS CLI, AWS API를 통해 새 RG 클러스터를 생성하거나 기존 클러스터를 이전할 수 있다. - 통합 데이터 레이크 쿼리 엔진은 기본적으로 활성화된다. - **Elastic Resize** - 호환되는 구성에서 인플레이스 마이그레이션을 수행한다. - 약 10~15분의 다운타임이 발생한다. - **Snapshot and Restore** - RA3 스냅샷으로 RG 클러스터를 새로 생성한다. - 마이그레이션 과정에서 클러스터 설정을 변경하려는 경우 적합하다. - 마이그레이션 경로를 통해 비용, 호환성, 실행 계획을 확인하고 자동화할 수 있다. ## 리전 및 요금 옵션 - RG 인스턴스는 미국, 캐나다, 유럽, 아시아 태평양, 남아메리카의 여러 AWS 리전에서 제공된다. - 한국 리전(서울)도 지원 대상에 포함되어 있다. - Provisioned Redshift에서는 약정 없는 시간 단위 온디맨드 요금제와 비용 절감을 위한 Reserved Instance를 선택할 수 있다. - 제공 리전은 변경될 수 있으므로 실제 도입 전 AWS 리전별 지원 현황을 확인해야 한다. 실제로 도입할 때는 기존 RA3 workload의 쿼리 패턴과 S3 데이터 스캔량을 기준으로 RG의 성능·비용을 비교하는 것이 좋다. 호환 가능한 클러스터라면 Elastic Resize를 우선 검토하고, 설정 변경이나 검증이 필요하면 Snapshot and Restore 방식을 사용하는 것이 적절하다.

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

sqlAI 에이전트amazon-s3apache-iceberg+4

toss·2026년 4월 23일원문

토스플레이스 데이터봇 ‘판다(PANDA)’를 소개합니다 : 모든 팀원이 데이터 전문가처럼 일하는 방법 (새 탭에서 열림)

토스플레이스는 데이터 분석가에게 집중된 단순 추출 요청을 해결하고 전사적인 데이터 민주주의를 실현하기 위해 AI 데이터 분석 어시스턴트 ‘판다(PANDA)’를 개발했습니다. 판다는 단순한 챗봇을 넘어 표준 데이터 마트 정비와 에이전트 기반의 자율 루프 시스템을 통해 데이터 조회부터 실무 인사이트 제공까지 수행하며, 출시 후 전사 구성원의 70%가 활용하는 필수적인 도구로 자리 잡았습니다. 기술적 복잡함보다 비즈니스 맥락과 데이터 거버넌스에 집중함으로써, 누구나 데이터 분석가의 도움 없이도 정확한 의사결정을 내릴 수 있는 환경을 구축했다는 데 큰 의의가 있습니다. ### 데이터 신뢰성을 위한 표준 데이터 마트(SSOT) 구축 * AI가 일관된 답을 낼 수 있도록 Data Analysis와 Platform 팀이 협업하여 핵심 데이터를 단일화된 테이블로 정비했습니다. * **표준 네이밍 컨벤션:** 테이블명은 `{역할}_{도메인}_{주제}`(예: fact_device_error_log)로, 컬럼명은 `{접두어}_{대상}_{속성}_{접미어}`(예: is_merchant_active)로 규칙화하여 AI가 이름만으로도 데이터의 목적을 이해하게 했습니다. * 모든 테이블과 컬럼에 상세 설명을 추가하여 AI가 데이터를 정확하게 탐색할 수 있는 기반 정보를 제공했습니다. ### 데이터 선택의 정확도를 높이는 Scoring & Ranking 시스템 * 질문에 대해 매번 다른 테이블을 선택하는 문제를 방지하기 위해 유사도와 신뢰도를 결합한 점수 체계를 도입했습니다. * **최종 점수 산출:** `(질문-테이블 유사도) × (데이터 계층 가중치)` 공식을 적용합니다. * **계층별 가중치:** 전사 주요 지표(SSOT)는 4배, 검증된 표준 마트는 3배, 도메인 마트는 2배, 원시 로그 데이터는 1배의 가중치를 부여하여 가장 신뢰할 수 있는 소스를 우선 선택하게 합니다. * dbt tags를 활용해 관리되는 테이블만 Manifest 파일로 가져와 탐색 범위를 최적화했습니다. ### 비즈니스 맥락 연결과 에이전틱 루프(Agentic Loop) * ‘설치 매장’이나 ‘업종 분류’와 같은 비즈니스 용어 정의를 데이터 구조와 연결하여 AI가 단순 수치 이상의 맥락을 파악하도록 설계했습니다. * AI가 스스로 상황에 맞는 도구를 선택하고, 결과가 부정확할 경우 스키마를 다시 확인하여 쿼리를 수정 및 재실행하는 자율적 재시도 과정을 거칩니다. * '테이블 탐색 → 쿼리 실행 → 결과 검증 → 수정 → 최종 결과 도출'의 과정을 반복하며 정답률을 높이는 구조를 갖췄습니다. ### 실무 활용성을 고려한 답변 구조 및 성과 * 단순 숫자 나열이 아니라 **결과, 조회 기준, 실무 인사이트**라는 3단계 구조로 답변을 제공하여 사용자의 해석 시간을 단축했습니다. * 출시 직후 전체 팀원의 절반 이상이 사용했으며, 현재는 70%의 사용률을 기록하며 데이터 요청에 대한 심리적 문턱을 낮추고 실질적인 업무 방식의 변화를 이끌어냈습니다. * 개발자, 기획자 등 비데이터 직군에서도 활발히 사용하며 데이터 분석가의 리소스를 고부가가치 분석 업무에 집중할 수 있도록 지원합니다. 성질 급한 AI 모델의 성능에만 의존하기보다, **데이터의 표준화와 비즈니스 로직의 명확한 정의(Governance)**가 선행될 때 비로소 실효성 있는 AI 서비스가 완성된다는 점을 시사합니다. 사내 데이터 민주화를 고민한다면, 기술적 기교 이전에 AI가 읽기 좋은 데이터 환경을 만드는 것부터 시작할 것을 추천합니다.

sqlAI데이터베이스 설계머신러닝+4

datadog·2026년 3월 4일원문

에이전트를 위한 MCP 도구 설계: Datadog의 MCP 서버 구축을 통해 배운 교훈 (새 탭에서 열림)

AI 에이전트를 위한 관측성(Observability) 인터페이스 구축 시, 단순히 기존 API를 그대로 노출하는 방식은 컨텍스트 창의 한계와 비용 문제로 인해 한계가 명확합니다. Datadog은 MCP(Model Context Protocol) 서버를 구축하며 데이터 포맷 최적화, SQL 기반 쿼리 도입, 도구의 효율적 관리라는 세 가지 핵심 설계를 통해 에이전트의 작업 효율을 극대화했습니다. 결과적으로 이러한 설계 변경은 에이전트의 추론 정확도를 높이는 동시에 토큰 사용량을 줄여 운영 비용을 절감하는 효과를 가져왔습니다. ### 컨텍스트 창 효율성 극대화 * **데이터 포맷 최적화**: JSON은 프로그래밍 방식에는 적합하지만 토큰 소모가 큽니다. 평면적인 데이터에는 CSV(토큰 약 50% 절감)를, 계층 구조가 있는 데이터에는 YAML(약 20% 절감)을 사용하여 동일한 컨텍스트 내에 더 많은 정보를 담았습니다. * **필드 트리밍**: 에이전트에게 불필요한 필드를 기본 출력에서 제거하고 필요한 경우에만 요청하게 함으로써, 동일한 토큰 예산 내에서 레코드 수용량을 최대 5배까지 늘렸습니다. * **토큰 기반 페이지네이션**: 레코드 개수 단위로 데이터를 끊어 보내는 전통적인 방식 대신, 실제 소비되는 토큰량을 기준으로 응답을 제한하여 에이전트의 컨텍스트 창이 예기치 않게 가득 차는 문제를 방지했습니다. ### 단순 조회를 넘어선 SQL 기반 쿼리 도입 * **서버 측 집계**: 에이전트가 수천 개의 로그를 직접 내려받아 트렌드를 분석하는 대신, 서버에서 SQL을 실행하여 요약된 결과만 받도록 개선했습니다. * **비용 및 성능 개선**: SQL을 통해 꼭 필요한 필드만 선택(SELECT)하고 행을 제한(LIMIT)함으로써, 평가 시나리오에서 실행 비용을 약 40% 절감하고 정답률을 높였습니다. * **에이전트 적응력**: AI 에이전트는 SQL 작성에 매우 능숙하며, 이를 통해 컨텍스트 윈도우에 들어갈 데이터를 스스로 세밀하게 제어할 수 있게 되었습니다. ### 도구 비대화 방지 및 관리 전략 * **유연한 도구 설계**: 개별 API 엔드포인트마다 도구를 만드는 대신, 하나의 도구가 여러 유즈케이스를 처리할 수 있도록 스키마를 범용적으로 설계하여 도구의 총 개수를 줄였습니다. * **도구 세트(Toolsets) 분리**: 모든 도구를 한꺼번에 노출하지 않고, 핵심 도구와 특정 워크플로우를 위한 선택적 도구 세트를 구분하여 에이전트의 혼란을 방지하고 컨텍스트 소모를 최소화했습니다. * **도구 계층화**: "어떻게 작업을 수행할지"를 묻는 도구와 실제 동작 도구를 분리하여 검색 효율을 높였습니다. 다만, 이 방식은 레이턴시 증가라는 기회비용이 발생하므로 신중한 적용이 필요합니다. AI 에이전트를 위한 도구를 설계할 때는 인간 사용자를 위한 API 설계와는 다른 접근이 필요합니다. 에이전트가 데이터를 직접 처리하게 두기보다, 서버 측에서 데이터를 가공하고 요약할 수 있는 강력한 쿼리 기능을 제공하고 전송 포맷을 최적화하는 것이 성능과 비용 측면에서 모두 유리합니다.

sql데이터베이스 설계datadog옵저버빌리티+4

figma·2026년 2월 17일·4분 읽기큐레이션 요약

데이터 사이언티스트로서 영향력을

데이터 과학의 영향력은 A/B 테스트나 최적화에만 있지 않으며, 복잡한 시스템을 이해하기 쉽게 만들고 정확성과 운영 안정성을 높이는 데에도 있다. 특히 빌링처럼 여러 시스템과 상태 변화가 얽힌 영역에서는 데이터 과학자가 도메인 지식, 데이터 모델링, 검증 도구, 엔지니어링 협업을 함께 수행해야 한다. 글은 데이터 과학을 ‘풀스택’ 분야로 보고, 과거와 현재의 시스템 동작을 설명하며, 기술적 방향과 품질 기준까지 정의해야 한다고 주장한다. ## 데이터 과학은 풀스택 분야다 - 데이터 과학자의 역할은 팀에 따라 실험 설계, 제품 분석, 데이터 모델링, 계측, 시스템 검증 등 크게 달라진다. - Figma는 한 프로젝트 안에서도 여러 역할을 수행할 수 있는 풀스택 데이터 과학자를 지향한다. - 빌링은 사용자에게 직접 보이는 제품이면서 동시에 복잡한 백엔드 시스템이므로, 단순한 기회 분석이나 실험만으로는 충분하지 않다. - 정확한 청구는 고객 경험과 플랫폼에 대한 신뢰에 직접 영향을 미친다. - 따라서 데이터 과학자는 다음과 같은 업무를 수행한다. - 빌링 도메인과 업무 규칙 이해 - 여러 팀과의 협업 - 시스템 동작을 설명하고 검증하는 도구 개발 - 데이터 품질과 계측 개선 - 정해진 데이터 과학 플레이북을 적용하기보다, 파트너 팀과 함께 실제로 필요한 지원 방식을 정의하는 것이 중요하다. ## 차트와 모델 외에도 시스템을 설명하는 방법이 있다 - 예측이나 추론 모델이 항상 가장 영향력 있는 데이터 과학 작업은 아니다. - 복잡한 시스템에서는 현재 또는 과거의 결과가 왜 발생했는지 설명하는 일이 더 중요할 수 있다. - Figma의 좌석 기반 빌링에서는 다음 요소가 여러 시스템에 걸쳐 상호작용한다. - 좌석 할당 및 제거 - 권한 변경 - 계약 조건 - 업그레이드 경로 - 워크스페이스 상태 - 특정 시점에 발생한 상태 전환 - 인보이스의 단순한 한 줄 청구 항목도 실제로는 여러 제품 이벤트와 빌링 규칙의 결과다. - 이를 해결하기 위해 **Invoice Seat Report**라는 데이터 애플리케이션을 구축했다. - 제품 사용 이벤트, 계약 메타데이터, 빌링 규칙, 과거 상태 전환을 통합한다. - 각 좌석 요금이 왜 발생했는지 평이한 언어로 설명한다. - 고객 지원, 주문 관리, 엔터프라이즈 담당자가 고객에게 청구 내역을 설명할 수 있게 한다. - 엔지니어가 예상치 못한 청구 동작을 디버깅할 때도 활용된다. ## 신뢰할 수 있는 설명에는 데이터 기반이 필요하다 - 보고서를 만드는 일은 단순히 여러 테이블을 조회하는 작업이 아니었다. - 좌석 상태가 시스템마다 어떻게 변화하는지에 대한 공통된 정신 모델을 먼저 만들어야 했다. - 이를 위해 다음 작업이 필요했다. - 엔지니어와 데이터 흐름 및 업무 규칙 검증 - 과거 데이터의 불일치 정리 - 누락된 이벤트에 대한 새로운 계측 요청 - “무슨 일이 일어났는가”뿐 아니라 “왜 일어났는가”를 기록하도록 로그 개선 - 기존 로그는 결과만 남기고 원인을 기록하지 않는 경우가 있어, 미래의 분석 가능성을 높이기 위한 시스템 변경도 함께 진행했다. - 특히 레거시 다년 계약처럼 좌석 이력이 드문 경우나, 초기 업그레이드로 데이터에 공백이 생기는 경우를 별도로 처리해야 했다. - 빌링 규칙을 SQL과 데이터 변환 로직으로 옮길 때는 각 규칙을 추적하고 디버깅할 수 있도록 구현해야 했다. ## 데이터 과학자는 기술적 방향도 정의할 수 있다 - 비즈니스 규칙을 측정 가능한 검증 조건으로 바꾸면 데이터 과학은 제품 분석을 넘어 시스템 품질 관리에 기여할 수 있다. - 이런 검증은 다음 목적에 활용된다. - 무엇이 “정상”인지 정의 - 데이터 및 시스템 동작의 드리프트 감시 - 회귀 버그 조기 탐지 - 미묘한 이상 상태 발견 - 개발 환경과 운영 환경에서 결과 검증 - 빌링처럼 상태가 누적되는 시스템에서는 좌석 할당, 상태 전환, 인보이스 계산이 모두 의도한 규칙과 일치해야 한다. - 작은 계산 오류도 고객의 청구 금액과 서비스 신뢰도에 영향을 줄 수 있다. - Figma가 가격·상품 구성·빌링 로직을 대규모로 재설계했을 때도 데이터 과학은 다음을 검증하는 역할을 맡았다. - 새 로직이 의도대로 작동하는지 - 데이터가 파이프라인을 통해 정확히 흐르는지 - 예상하지 못한 빌링 상태가 발생하지 않는지 - 개발과 운영 환경 모두에서 결과가 일관적인지 복잡하고 중요한 시스템에서 데이터 과학자는 분석 결과를 제공하는 사람을 넘어, 시스템을 설명 가능하게 만들고 정확성을 검증하는 기술 파트너가 되어야 한다. 따라서 실험 중심의 역할에만 한정하지 말고, 도메인 모델링·데이터 품질·계측·자동 검증까지 업무 범위를 확장하는 것이 실용적인 접근이다.

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

sql옵저버빌리티데이터 사이언스데이터 엔지니어링+3

toss·2025년 12월 8일원문

사업자 데이터 리터러시 높이기: BC Monthly Report 발행기 (새 탭에서 열림)

토스는 각 사업부별로 흩어져 있던 사업자(Business Customer, BC) 데이터를 통합하여 '단일 진실의 근원(SSOT)'인 데이터 마트를 구축하고, 이를 기반으로 전사적인 월간 리포트를 발행하여 비즈니스 의사결정 구조를 혁신했습니다. 이 과정에서 파편화된 지표 정의를 하나로 모으고 현업의 니즈를 반영한 결과, 전사 구성원들이 동일한 기준으로 사업 현황을 파악하고 데이터에 기반해 실질적인 액션 아이템을 도출할 수 있는 환경이 마련되었습니다. 이러한 여정은 단순한 데이터 정리를 넘어 토스 전반의 데이터 리터러시를 높이고 비즈니스 성장을 가속화하는 기폭제가 되었습니다. **단일 진실의 근원(SSOT)을 위한 데이터 마트 구축** * 쇼핑, 광고, 페이 등 각 사업부별로 분산되어 관리되던 사업자 데이터를 통합하여 전사적으로 공통된 언어를 사용하는 'BC 데이터 마트'를 설계했습니다. * 사업부별로 상이했던 매출과 비용 발생 기준을 표준화하기 위해 도메인 담당자들과의 소통을 거쳐 '토스에서 활동하는 사업자'에 대한 명확한 정의를 수립했습니다. * 이를 통해 "이번 달 매출을 발생시킨 사업자가 몇 명인가?"라는 기초적인 질문에 대해 전사가 동일한 숫자로 답변할 수 있는 기술적 기반을 마련했습니다. **통찰을 제공하는 Monthly BC Report 설계 및 자동화** * 데이터의 전파력을 높이기 위해 신규(New), 이탈(Churn), 유지(Retained) 트렌드와 매출 규모별 티어(Tier) 분석을 포함한 월간 리포트를 기획했습니다. * 단순 지표 나열이 아닌, 코호트 리텐션(Cohort Retention) 분석을 통해 플랫폼 만족도를 확인하고, 이탈 가맹점 리스트 등 실무자가 즉시 활용 가능한 로우 데이터(Raw Data)를 함께 제공했습니다. * 데이터 파이프라인은 Airflow를 통해 마트를 구축하고 Jenkins로 배치 작업을 수행하며, 최종적으로 태블로(Tableau)와 SQL을 연동해 매달 자동으로 업데이트되는 환경을 구현했습니다. **현업 피드백을 통한 리포트의 고도화와 데이터 리터러시 확산** * PO, 세일즈 팀장 등 실제 사용자의 니즈를 파악하기 위해 심층 인터뷰를 진행하고, 이를 바탕으로 '회원 가입' 단계 분석이나 도메인 간 활성화 순서 등 구체적인 지표를 리포트에 추가했습니다. * 리포트 발행 이후 사업자 데이터에 대한 전사적 관심이 급증하며, 이탈 가맹점 상세 분석이나 데일리 트래킹 등 후속 심화 분석 프로젝트로 이어지는 성과를 거두었습니다. * 고정된 포맷에 안주하지 않고 매달 현업의 피드백을 반영하여 지표를 개선함으로써, 조직 전체의 데이터 이해도와 활용 능력을 점진적으로 상향 평준화했습니다. 데이터 마트 구축과 리포트 발행은 끝이 아닌 시작이며, 현업과의 지속적인 피드백 루프를 통해 리포트를 ' 살아있는 문서'로 관리하는 것이 중요합니다. 조직 내 데이터 리터러시를 높이고 싶다면 표준화된 지표 정의부터 시작해 구성원들이 실제 업무에 바로 적용할 수 있는 액션 중심의 데이터를 제공하는 단계적 접근이 필요합니다.

sqldata-analysisdata-pipelineairflow+4

discord·2025년 4월 8일원문

dbt 오버클러킹 (새 탭에서 열림)

디스코드는 2,500개 이상의 데이터 모델과 100명 이상의 개발자가 협업하는 페타바이트급 데이터 환경을 관리하기 위해, dbt의 기본 기능을 넘어선 커스텀 확장 시스템을 구축했습니다. 초기 도입 시에는 20분이 넘는 컴파일 시간과 개발자 간의 작업 충돌 등 확장성 한계에 부딪혔으나, 이를 자동화된 백필(Backfill)과 생산성 도구로 해결하며 견고한 데이터 분석 기반을 마련했습니다. 이 사례는 대규모 데이터 웨어하우스 환경에서 dbt를 효율적으로 확장하려는 기업들을 위한 기술적 청사진을 제시합니다. ### dbt 선정 배경과 주요 장점 * **엔지니어링 철학과의 일치:** 오픈 소스를 지향하고 엔지니어링의 유연성과 투명성을 중시하는 디스코드의 철학에 따라 dbt를 채택했습니다. * **도구 간 통합 및 모듈화:** 오케스트레이터인 Dagster와의 원활한 통합은 물론, SQL 기반의 모듈식 설계를 통해 코드 재사용성과 유지보수성을 확보했습니다. * **품질 관리:** 데이터 품질을 보장할 수 있는 포괄적인 테스트 프레임워크를 활용하여 신뢰할 수 있는 데이터 변환 프로세스를 구축했습니다. ### 대규모 데이터 환경에서의 한계점 * **긴 컴파일 대기 시간:** 프로젝트 규모가 커짐에 따라 전체 프로젝트를 재컴파일하는 데 20분 이상이 소요되어 개발 생산성이 급격히 저하되었습니다. * **증분 전략의 비효율성:** dbt가 기본적으로 제공하는 증분(Incremental) 구체화 전략은 디스코드의 페타바이트급 데이터 볼륨을 처리하기에 최적화되어 있지 않았습니다. * **동시성 충돌 문제:** 여러 개발자가 동시에 작업하는 과정에서 서로의 테스트 테이블을 덮어쓰는 등 협업상의 혼선과 자원 낭비가 발생했습니다. ### 확장성을 위한 커스텀 최적화 전략 * **성능 중심의 코어 확장:** dbt의 표준 기능을 확장하여 대규모 조직에 적합한 커스텀 시스템을 구축함으로써 개발 사이클을 획기적으로 단축했습니다. * **자동화된 백필 시스템:** 수동 개입이 많이 필요한 복잡한 데이터 백필 과정을 자동화하여 운영 리소스를 절감하고 데이터의 정합성을 높였습니다. * **플랫폼 독립적 설계:** Google BigQuery를 사용하면서도 특정 클라우드 제공업체에 종속되지 않는(Provider-agnostic) 구조를 취해 범용적인 적용이 가능하도록 설계했습니다. 디스코드의 이러한 시도는 단순한 도구 도입을 넘어, 대규모 데이터 스택을 운용할 때 발생하는 병목 현상을 엔지니어링 기반의 커스텀 솔루션으로 해결할 수 있음을 보여줍니다. 데이터 규모가 급격히 성장하는 조직이라면 dbt의 기본 기능에만 의존하기보다, 자사의 인프라에 맞춘 자동화와 확장 도구를 결합하는 전략이 필수적입니다.

sqlscalability데이터 엔지니어링dbt+3

datadog·2024년 6월 28일원문

대규모 시계열 인덱싱 (새 탭에서 열림)

Datadog은 5년 사이 데이터 규모가 30배 이상 급증함에 따라, 기존의 시계열 인덱싱 시스템에서 발생하는 성능 병목과 유지보수 문제를 해결하기 위해 아키텍처를 재설계했습니다. 수조 건의 이벤트를 효율적으로 처리하기 위해 인덱스 서비스를 시계열 데이터 저장소와 분리하였으며, 쿼리 로그를 분석해 인덱스를 자동으로 생성하는 전략을 취했습니다. 이 글은 RocksDB와 SQLite를 기반으로 한 초기 인덱싱 서비스의 구조와 대규모 시계열 데이터를 관리하기 위한 Datadog의 기술적 접근 방식을 다룹니다. ### 메트릭 플랫폼의 계층별 구조 * **수집(Intake) 계층:** 데이터 포인트는 메트릭 이름, 태그(env, host, service 등), 타임스탬프, 수치 값으로 구성됩니다. 수집된 데이터는 메시지 브로커인 Kafka로 전달되어 분석, 인덱싱, 아카이빙 등 다양한 용도로 독립적으로 소비됩니다. * **저장(Storage) 계층:** 데이터 저장소는 두 개의 서비스로 나뉩니다. '시계열 데이터베이스'는 `<시계열_ID, 타임스탬프, 값>` 튜플을 저장하고, '시계열 인덱스' 서비스는 RocksDB를 기반으로 `<시계열_ID, 태그>`를 매핑하여 쿼리 시 필터링과 그룹화를 담당합니다. * **쿼리(Query) 계층:** 분산 쿼리 계층은 인덱스 노드에서 검색된 식별자를 바탕으로 시계열 데이터베이스에서 실제 값을 가져와 병합하며, 필터와 집계 함수(avg 등)를 적용해 최종 결과를 도출합니다. ### 쿼리 로그 분석을 통한 자동 인덱싱 전략 * **풀 스캔 방지:** 특정 메트릭의 전체 데이터를 조회하는 비효율적인 스캔을 피하고자, 태그 기반의 인덱스를 생성하여 쿼리 실행 속도를 최적화했습니다. * **동적 인덱스 생성:** 시스템은 백그라운드 프로세스를 통해 실시간 쿼리 로그를 분석합니다. 쿼리 횟수, 실행 시간, 입력 대비 출력 식별자 비율을 따져 리소스 소모가 큰 '고선택성' 쿼리에 대해 자동으로 인덱스를 생성합니다. * **구체화된 뷰(Materialized Views):** 자주 사용되는 복잡한 쿼리를 미리 계산된 인덱스 형태로 저장함으로써, 반복되는 쿼리 요청을 단순한 키-값 조회로 변환해 CPU와 메모리 리소스를 획기적으로 절감합니다. ### 임베디드 데이터베이스를 활용한 시스템 설계 * **SQLite 기반의 메타데이터 관리:** 인덱스 정의와 쿼리 로그 등 읽기 중심의 데이터는 Go 애플리케이션 내에 임베디드된 SQLite에 저장됩니다. SQL의 유연성 덕분에 CLI를 통한 디버깅과 테이블 관리가 용이합니다. * **RocksDB를 통한 고성능 쓰기 처리:** 매일 발생하는 수조 건의 인덱싱 데이터는 고성능 키-값 저장소인 RocksDB가 처리합니다. 별도의 서버 프로세스 없이 애플리케이션에 직접 통합되어 성능 극대화를 꾀했습니다. * **인덱스 수명 주기 관리:** 일정 기간 쿼리가 발생하지 않아 쓸모없어진 인덱스는 시스템이 자동으로 삭제하여 저장 공간을 효율적으로 관리합니다. 대규모 분산 환경에서 모든 데이터에 대해 미리 인덱스를 생성하는 것은 불가능에 가깝습니다. Datadog의 사례처럼 실제 사용자의 쿼리 패턴을 모니터링하고, 리소스 집약적인 쿼리에 대해 인덱스를 동적으로 생성하는 '쿼리 기반 최적화' 방식은 폭발적인 데이터 성장세 속에서 시스템 가용성을 유지하는 매우 실용적인 전략입니다.

sql데이터베이스 설계datadogApache Kafka+4

datadog·2023년 12월 21일원문

셀프 서비스 분석 확장: 5,000명의 직원에게 힘을 실어주는 도구들 (새 탭에서 열림)

Datadog은 200명에서 5,000명 규모로 급격히 성장하는 과정에서 발생하는 데이터 병목 현상을 해결하기 위해, 모든 직원이 중앙 데이터 팀의 도움 없이 스스로 데이터를 활용할 수 있는 '셀프 서비스 분석' 체계를 구축했습니다. 오픈 소스 기술을 기반으로 데이터 수집부터 변환, 발견, 리포팅까지 이어지는 통합 툴킷을 제공함으로써 데이터 팀은 단순 운영 업무에서 벗어나 고부가가치 과제에 집중할 수 있게 되었으며, 전사적으로 데이터 기반의 의사결정 문화를 정착시키는 성과를 거두었습니다. ### 셀프 서비스 분석의 세 가지 기둥과 사용자 분류 * 셀프 서비스 분석은 모든 임직원이 중앙 팀의 개입 없이 스스로 데이터를 활용해 의사결정을 내리는 상태를 지향하며, 이는 '데이터(Data)', '도구(Tools)', '지식(Knowledge)'이라는 세 가지 핵심 요소로 뒷받침됩니다. * 사용자의 데이터 숙련도와 니즈에 따라 사용자를 세 가지 페르소나로 분류하여 맞춤형 환경을 제공합니다. * **탐험가(Explorers):** 잘 정돈된 데이터와 미리 구축된 리포트를 활용하는 일반 사용자. * **빌더(Builders):** 직접 쿼리를 작성하고 팀을 위한 대시보드를 생성하는 숙련된 사용자. * **전문가(Experts):** 새로운 데이터를 노출하고 비즈니스 로직을 유지하며 데이터 품질을 제어하는 고숙련 사용자. ### 데이터 제품화와 단일 진실 공급원(SSOT) 구축 * 엔지니어링, 마케팅, 영업, 인사 등 모든 부서가 동일한 데이터를 바라볼 수 있도록 중앙 집중화된 '단일 진실 공급원(Single Source of Truth)'을 확립했습니다. * 'Bring Your Own Data(BYOD)' 툴을 개발하여, 데이터를 생성하는 어떤 팀이든 이를 분석 환경에 직접 노출하고 공유할 수 있는 자율성을 부여했습니다. * 데이터의 신뢰성을 높이기 위해 강력한 명명 규칙(Conventions)을 적용하고, 상세한 문서화와 데이터 품질 모니터링 시스템을 통해 사용자가 데이터를 믿고 사용할 수 있는 환경을 조성했습니다. ### 기술적 셀프 서비스 툴 스택: 수집에서 발견까지 * **데이터 수집(Intake):** 내부 데이터 스토어 및 서드파티 도구와 연결되는 커넥터, 데이터 요청을 위한 유저 인터페이스, 파이프라인 가시성 및 알림 기능을 제공합니다. * **데이터 변환(Transformation):** 전사 데이터 분석가들이 dbt와 SQL을 사용해 각 부서의 비즈니스 로직을 직접 제어할 수 있는 개발 환경을 구축했습니다. 이를 통해 데이터 모델링 레이어의 일관성을 유지하면서도 부서별 자율성을 보장합니다. * **데이터 발견(Discovery):** 모든 데이터셋과 필드에 대한 검색 기능을 제공하며, 데이터 리니지(Lineage), 소유권, 민감도, 신뢰도 등 풍부한 메타데이터를 제공하여 사용자가 필요한 데이터를 쉽게 찾고 이해할 수 있게 합니다. ### 실용적인 결론 조직이 커질수록 데이터 팀의 인원을 늘리는 것만으로는 데이터 수요를 감당할 수 없습니다. Datadog의 사례처럼 데이터 자체를 하나의 '제품'으로 취급하고, 현업 담당자들이 직접 데이터를 가공하고 소비할 수 있는 인프라와 가이드라인을 제공하는 것이 확장성 있는 데이터 문화를 만드는 핵심입니다. 이를 위해서는 도구의 도입뿐만 아니라 데이터 품질에 대한 엄격한 기준 확립과 사용자 교육이 반드시 병행되어야 합니다.

sqlPostgreSQLdbtopen-source-tools+4

datadog·2021년 2월 10일원문

엔지니어링 스포트라이트: 마엘 니송 (새 탭에서 열림)

인도양의 작은 섬 레위니옹에서 시작해 자바스크립트 생태계의 핵심 도구인 Yarn의 메인 유지보수자가 되기까지, Maël Nison의 여정은 끊임없는 호기심과 오픈소스에 대한 열정으로 가득 차 있습니다. 그는 페이스북 부트캠프를 통해 Yarn 프로젝트에 합류한 뒤, 단순한 기여자를 넘어 프로젝트를 TypeScript 기반의 모듈형 구조로 재설계하고 커뮤니티 주도형 프로젝트로 탈바꿈시키는 데 결정적인 역할을 했습니다. 현재 Datadog의 프론트엔드 플랫폼 팀에서 근무하면서도 Yarn의 비전과 로드맵을 이끄는 그는, 기술적 해결책을 모두와 공유하는 오픈소스 정신이 개인과 공동체를 어떻게 성장시키는지 잘 보여줍니다. **Yarn의 진화와 다각적인 리더십** * 페이스북 입사 초기, 신규 입사자 교육 프로그램인 '부트캠프'를 통해 Yarn 프로젝트를 접하고 업무 시간의 상당 부분을 오픈소스 기여에 투입하기 시작했습니다. * 초기 내부 도구 성격이 강했던 Yarn을 TypeScript로 완전히 재작성하고 아키텍처를 모듈화하여, 특정 기업에 종속되지 않는 진정한 커뮤니티 오픈소스 프로젝트로 발전시켰습니다. * 프로젝트를 관리하며 개발자 역할을 넘어 제품 매니저, 팀 리드, 고객 지원, 인프라 설계, 웹 디자인 등 다방면의 역할을 수행하며 '1인 CEO'와 같은 경험을 쌓았습니다. **DarkBASIC에서 시작된 프로그래밍의 기초** * 프랑스 툴루즈의 중학교 시절, 점심시간마다 모이던 프로그래밍 클럽에서 DarkBASIC이라는 게임 제작 언어를 배우며 개발의 세계에 입문했습니다. * 화면 위에서 물고기가 움직이고 거품을 쏘는 간단한 2D 게임을 만들며, 코드를 수정하면 즉시 결과가 바뀌는 논리적인 과정에 매료되어 평생의 직업으로 삼기로 결심했습니다. * 2000년대 초반 3G 네트워크와 펜티엄 III 프로세서가 표준이던 시절부터 PHP 웹사이트를 구축하고 SQL 취약점을 직접 경험하며 실전 기술을 익혔습니다. **워크플로우 최적화와 실용적 교육** * 깃허브(GitHub)가 없던 시절, 포럼을 통해 소스 코드를 공유하며 누구나 필요한 해결책을 사용할 수 있게 하는 오픈소스의 본질을 체득했습니다. * 기존 CMS(콘텐츠 관리 시스템)들의 복잡한 관리 페이지 구조에 의문을 품고, 게시물을 클릭해 즉시 수정하는 직관적인 워크플로우를 고민하며 '사용자 경험 최적화'에 대한 철학을 세웠습니다. * 이론보다 실무 중심의 프로젝트와 동료 평가를 중시하는 프랑스의 교육 기관 EPITECH에서 수학하며, 자기 주도적 학습 역량과 실용적인 엔지니어링 기술을 연마했습니다. Maël Nison의 사례는 단순히 기술적인 숙련도를 높이는 것을 넘어, 자신이 마주한 불편함을 해결하고 그 결과물을 커뮤니티와 공유하는 습관이 어떻게 세계적인 오픈소스 리더로 성장하는 밑거름이 되는지 보여줍니다. 새로운 기술을 익힐 때 단순히 사용법을 익히는 데 그치지 않고, 오픈소스 프로젝트에 작은 기여부터 시작해 보는 것은 커리어 개발과 기술적 통찰력을 동시에 얻을 수 있는 가장 확실한 방법입니다.

sql데이터베이스 설계오픈 소스TypeScript+4

datadog·2017년 5월 17일원문

데이터독에서 솔루션 엔지니어로 일한다는 것 (새 탭에서 열림)

Datadog의 솔루션 엔지니어는 기술적 전문성과 고객 커뮤니케이션 능력을 결합하여 제품의 기술적 문제를 해결하고 발전을 이끄는 핵심적인 가교 역할을 수행합니다. 이들은 고객의 복잡한 기술 요구사항을 해결하는 동시에 내부 개발 팀과의 긴밀한 협업 및 임베딩 프로그램을 통해 지속적으로 기술 역량을 확장해 나갑니다. 결과적으로 솔루션 엔지니어링 직무는 개인의 적성에 따라 순수 엔지니어링, 제품 관리(PM), 또는 세일즈 엔지니어링 등 다양한 커리어 경로로 성장할 수 있는 유연한 토대를 제공합니다. **솔루션 엔지니어의 기술적 업무 범위** * 고객이 제품 사용 중 겪는 다양한 기술적 문제(에이전트 설정, 통합 구성, 대시보드 시각화, 얼럿 버그 등)를 티켓 시스템을 통해 해결합니다. * 단순한 상담을 넘어 직접 소스 코드를 분석하고, 필요에 따라 버그를 수정하거나 기술적 조사를 수행하는 심도 있는 엔지니어링 역량이 요구됩니다. * 고객의 요구를 정확히 이해하기 위해 멀티태스킹 능력을 발휘하며, 리눅스(Linux), 루비(Ruby), SQL 쿼리 등 폭넓은 기술 스택을 활용합니다. **고객 경험과 제품 개선의 연결** * 실시간 채팅과 기술 콜을 통해 고객과 직접 소통하며, 사용자가 필요로 하는 새로운 기능에 대한 피드백을 가장 먼저 수집하여 제품 개선에 기여합니다. * 문제가 즉각 해결되기 어려운 경우 창의적인 단기 우회 방법(Workaround)을 제시하며, 이 과정을 통해 제품의 내부 구조에 대한 깊은 지식을 습득합니다. * 문서화 작업을 통해 내부 지식을 공유하고, 고객이 스스로 문제를 해결할 수 있는 환경을 구축하는 데 동참합니다. **역량 강화를 위한 임베딩 프로그램과 프로젝트** * '임베딩(Embedding)' 제도를 통해 솔루션 엔지니어가 다른 엔지니어링 팀에 2주간 완전히 합류하여 실제 스프린트 업무를 수행하며 내부 설계 방식과 기술적 도전 과제를 경험합니다. * 업무 숙련도가 높아지면 데모 환경 개선이나 내부 프로세스 자동화와 같은 사이드 프로젝트를 주도적으로 수행할 수 있는 권한이 주어집니다. * 개별 엔지니어의 성향에 맞춰 코딩 중심의 프로젝트나 제품 기능 구현 등 커리어 경로를 맞춤형으로 설계할 수 있도록 지원합니다. Datadog의 솔루션 엔지니어 직무는 빠르게 변화하는 기술 환경에서 고객과 직접 소통하며 실질적인 문제를 해결하고 싶은 개발자에게 적합합니다. 기술적 깊이를 더하는 동시에 제품의 비즈니스적 가치를 함께 고민하고 싶은 분들에게 강력히 추천되는 커리어 경로입니다.

sqldatadogLinuxruby+3