• Eightfold의 고객 대면 분석과 AI 에이전트
• 소개
• Eightfold.ai 소개
• 제품 영역
• 규모와 인프라
• 분석 시스템 아키텍처
• 데이터 구조
• OLTP vs OLAP 데이터베이스
• ETL Evolution
• 1세대 아키텍처
• 2세대 아키텍처
• 3세대 아키텍처 (Lake House)
• Eightfold의 도전과 StarRocks 선택
• In-product Analytics 필요성
• Redshift의 한계
• StarRocks의 장점
• Agentic Analytics와 미래
• AI 에이전트와 분석의 결합
• Conversational Analytics
• 보안 및 액세스 제어
• 미래 비전
• 시작하는 팀을 위한 조언
• ❓ Q&A 하이라이트
• 성능과 비용
• 데이터 저장 전략
• 파티셔닝과 확장성
• Materialized Views 활용
• 데이터 신선도

Eightfold의 고객 대면 분석과 AI 에이전트

소개

오늘 특별 게스트인 Suresh(Director of Engineering from eightfold)의 발표와 대화를 정리한 내용입니다. 주요 주제는 customer-facing analytics와 AI agents입니다.

Eightfold.ai 소개

• Eightfold는 talent space에 특화된 AI 회사
• 마지막으로 알려진 인재 관련 스타트업은 약 20년 전의 Workday
• Eightfold는 AI 시대에 시작됨 (LLM 이전부터)
• AI 기반 접근 방식으로 talent 문제를 해결

제품 영역

• Talent acquisition management
• Workforce planning
• 기타 인재 관련 제품들

규모와 인프라

• Fortune 500 기업 중 200개 이상이 Eightfold 사용
• careers.microsoft.com, careers.morganstanley.com 등 대기업 채용 사이트 트래픽 처리
• 높은 인프라 안정성과 데이터 분석 능력 필요

분석 시스템 아키텍처

데이터 구조

• Fact tables: clickstream events (대규모)
• Dimension tables: 직원 프로필, 다중 테넌트 데이터 (대규모)
• Star schema 모델 사용 (팩트 테이블과 차원 테이블 결합)

OLTP vs OLAP 데이터베이스

• OLTP (MySQL, Postgres)
• 웹 애플리케이션 백엔드
• point queries에 최적화 (예: SELECT * FROM employee WHERE name = 'Suresh')
• 높은 QPS 지원
• OLAP (Redshift, Teradata, Snowflake, BigQuery)
• 주로 back-office 용도
• 집계 쿼리에 최적화
• 전통적으로 동시성/확장성보다는 분석 능력 중시

ETL Evolution

1세대 아키텍처

• 구조화된 데이터(OLTP) → ETL → Data Warehouse → BI 보고서
• 문제점: Data warehouse도 고정 스키마, 비정형 데이터 처리 어려움

2세대 아키텍처

• 모든 데이터를 Data Lake(HDFS/S3)에 저장 → ETL → Data Warehouse
• Data Science 팀은 Data Lake 직접 사용, BI 팀은 Data Warehouse 사용
• 문제점: 일관성 관리 문제 증가 (2개의 ETL 프로세스)

3세대 아키텍처 (Lake House)

• Data Lake + Data Warehouse 통합
• 구조화/비구조화 쿼리 모두 지원
• 메타데이터/인덱싱 레이어로 구조화 기능 제공
• Databricks, Snowflake 등이 이 방식 채택

Eightfold의 도전과 StarRocks 선택

In-product Analytics 필요성

• LinkedIn 같은 실시간 분석 대시보드 제공 필요
• 기존 Redshift로는 한계
• 서브초 단위 응답 시간 필요

Redshift의 한계

1. 단일 Leader Node 병목
• 모든 쿼리가 Leader Node를 통과
• Compute Node를 추가해도 QPS 제한 존재
2. 파티셔닝 개념 부족
• 다중 테넌트 환경에서 noisy neighbor 문제
3. 비용 효율성 문제
• Concurrency Scaling이 비싸고 시간 소모적
• 최대 10-11 concurrency clusters 제한
4. 서버리스 한계
• EBS 캐시 이점 부족
• I/O 병목현상

StarRocks의 장점

1. 확장성 있는 Front-End Nodes
• 단일 리더 병목 없음
• 무제한 FE 노드 및 백엔드 노드 확장 가능
2. 효과적인 파티셔닝
• 테넌트별 가상 파티셔닝 지원
• 태블릿이 여러 백엔드 노드에 분산
3. 더 나은 성능
• 대략 2배 성능 향상
• 비용도 약 2배 절감
4. 단순한 아키텍처
• 유지보수 용이
• 적은 구성 요소

Agentic Analytics와 미래

AI 에이전트와 분석의 결합

• 에이전트가 사용자 대신 쿼리 수행
• 기존 인간보다 더 많은 쿼리 생성 가능
• 높은 QPS 필요성 증가

Conversational Analytics

• 고정된 보고서/대시보드가 아닌 자유로운 질문-답변
• "이번 분기 총 채용 수는?", "이 후보자의 상태는?" 등 자연어 질문
• StarRocks의 높은 QPS로 이러한 혁신 가능

보안 및 액세스 제어

• 자유 형식의 분석 쿼리에 가드레일 필요
• 권한 경계 위치:
• DB 내부보다 애플리케이션 레이어에 두는 것 권장
• 중앙 집중식 권한 프레임워크 사용
• 모든 시스템에 동일한 액세스 제어 적용

미래 비전

• GPT 플랫폼으로 자연어 질문에 답변
• 보고서, CSV, 템플릿 PPT 등 다양한 형식으로 결과 제공
• 미리 정의된 보고서 없이 대화형 분석 지원

시작하는 팀을 위한 조언

1. QPS 요구사항 파악부터
• 데이터베이스 인프라부터 설계
• 좋은 OLAP 데이터베이스에 먼저 투자
2. 기본 데이터 레이어 견고하게
• 마이그레이션은 수개월 소요 가능
• 새로운 ETL, 유스케이스 고려 필요
3. 데이터 구조와 아키텍처 설계 중요
• 테이블 생성, 비동기 MV 활용
• 사용 패턴에 맞는 최적화

❓ Q&A 하이라이트

성능과 비용

• Redshift 대비 약 2배 성능 향상
• 비용도 약 2배 절감 (특히 스케일링 시)

데이터 저장 전략

• S3에 기본 데이터 저장 (shared data 아키텍처)
• EBS 볼륨에 약 10-20% 데이터 캐싱
• 작은 테이블은 전체, 큰 테이블은 일부 캐싱

파티셔닝과 확장성

• S3에 태블릿 단위로 데이터 저장
• 테넌트 ID 기반 가상 파티셔닝
• 쿼리 시 일부 백엔드 노드만 참여 (전체 클러스터 부하 감소)

Materialized Views 활용

• 파티션별 점진적 새로고침 지원
• 클러스터 성능에 영향 최소화
• 최신성과 성능 사이 트레이드오프 관리

데이터 신선도

• Fact 테이블은 near real-time 유스케이스에 활용
• 높은 조인이 필요한 경우 MV 사용 (신선도 희생)