26F12M

Young-Kyoo Kim·2026년 2월 11일

ORB.AI 회의록

1. 회의 배경

1.1 ORB.AI란?

제품 정의

벤더 설명:

"ORB is a new product coming out of the MinIO AI branch. MinIO 
has a smaller team called MinIO AI... where we're building... 
AI based products."

조직:

MinIO AI: MinIO의 AI 전담 팀
ORB: 플래그십 제품
목표: Agentic/Autonomous AI

데모 실패

벤더 양해:

"I wish I could show you ORB because it's pretty impressive, but 
[we] couldn't get the environment stabilizing [in] Kubernetes"

상황:

Kubernetes 환경 불안정
데모 불가
개념 설명으로 대체

2. ORB의 핵심 개념

2.1 데이터 접근의 민주화

현재 문제

벤더 설명:

"Because today, when business has a question, they say, I would 
like to know this. So someone needs to build a SQL statement or 
[write] Python to go and fetch the data."

현재 프로세스:

Business Question
  ↓
Data Analyst (60분 소요)
  ↓
SQL/Python 작성
  ↓
Analysis Report

문제:

시간 소요: 분석가가 60분+ 소요
전문성 필요: SQL/Python 필수
병목: 분석가 리소스 제약

ORB 비전

벤더 설명:

"we're trying to democratize access to data lake... AI, if AI, 
can actually read out of a catalog... and either do the traditional 
query or the traditional Python program."

ORB 프로세스:

Business Question (자연어)
  ↓
ORB (AI)
  ↓
Automated Analysis
  ↓
Instant Answer/Application

효과:

즉시 응답: 60분 → 수 초
전문성 불필요: 자연어 질문
확장성: 무제한 동시 처리

2.2 표준화의 중요성

S3 표준화 (과거)

벤더 설명:

"object storage has done for the industry is standardize access 
to the data to one common API, which is S3"

효과:

Storage API 표준: S3
벤더 독립성: AWS, MinIO, GCS 모두 S3 호환
생태계: 모든 도구가 S3 지원

Iceberg 표준화 (현재)

벤더 비유:

"very similar to what the JDBC connector did 25 years ago. JDBC 
standardized access patterns to database... iceberg, standardized 
access patterns for data across multiple platforms."

JDBC (25년 전):

DB 접근 표준화
SQL 인터페이스 통일
벤더 독립성

Iceberg (현재):

Data Lake 접근 표준화
메타데이터 구조 통일
Query Engine 독립성

AI의 기회

벤더 강조:

"now the iceberg is emerging as the winner of the open format table. 
That means that now we're standardizing access pattern... So now 
this is when the data becomes structured. This is where AI thrives"

Iceberg → AI 활용:

구조화된 메타데이터: AI가 이해 가능
스키마 정보: 컬럼, 타입, 관계
표준 접근: Spark, Trino 무관

3. ORB의 3가지 접근 패턴

3.1 Pattern 1: Query & Answer

정의

벤더 설명:

"You have a question, we'll get you the answer that's more aligned 
to... AI writing SQL or Python."

기능:

입력: 자연어 질문
처리: AI가 SQL/Python 생성
출력: 답변 (텍스트, 표, 차트)

예시:

User: "지난 분기 매출이 가장 높은 제품 Top 5는?"

ORB:
[AI가 자동 생성한 SQL]
SELECT product_name, SUM(revenue) as total
FROM sales
WHERE quarter = 'Q4-2025'
GROUP BY product_name
ORDER BY total DESC
LIMIT 5;

[결과 표시]
1. Product A: $5.2M
2. Product B: $4.8M
...

3.2 Pattern 2: Chat with Data

정의

벤더 설명:

"once you have figured out or understood the data, maybe you want 
to interact with data. So that's the second interface. We have chat"

기능:

대화형: 연속적인 질문
컨텍스트 유지: 이전 대화 기억
탐색적 분석: 드릴다운

예시:

User: "지난 분기 매출을 보여줘"
ORB: [차트 표시]

User: "이 중에서 한국 매출만 보여줘"
ORB: [필터링된 차트]

User: "전년 대비 증감률은?"
ORB: [증감률 분석]

3.3 Pattern 3: Application Building (핵심)

정의

벤더 강조:

"whatever you're asking for, ORB will actually build an application 
for you, put it in a container and deploy to Kubernetes. That's 
the core feature of ORB."

프로세스:

1. User 요청 (자연어)
2. ORB 분석
3. 코드 생성 (Python + React)
4. 컨테이너 빌드
5. Kubernetes 배포
6. User 확인/피드백
7. 수정 반복
8. 최종 배포

예시

벤더 예시:

"business can come and say, I would like to have a dashboard that 
forecast sales on a quarter to quarter basis, but allows me to see 
previous [quarters]."

ORB 작업:

1. Iceberg 카탈로그 분석
   - sales 테이블 찾기
   - 컬럼: date, product, revenue
   - 관계: product → category

2. View/Query 생성
   SELECT 
     QUARTER(date) as quarter,
     SUM(revenue) as total_revenue
   FROM sales
   GROUP BY QUARTER(date)

3. Python Backend 코딩
   - Flask/FastAPI
   - Query 실행
   - Forecast 알고리즘

4. React Frontend 빌드
   - Line Chart (분기별 매출)
   - Trend Line (예측)
   - Filter (제품, 기간)

5. Docker 이미지 생성
   FROM python:3.11
   COPY backend/ /app
   COPY frontend/build/ /app/static

6. Kubernetes 배포
   kubectl apply -f dashboard.yaml

7. User에게 미리보기
   "이게 맞나요? 색상을 바꿀까요?"

8. 피드백 반영
   User: "파란색으로, 월별도 추가해줘"
   ORB: [코드 수정 → 재배포]

9. 최종 승인
   User: "완벽해요!"
   ORB: Production 배포

속도

벤더 강조:

"building a data application... takes probably 20 minutes."

타임라인:

과거 (6개월 전): 40~60분
현재: ~20분
개선 속도: 3~6개월마다 10배 향상

벤더 설명:

"every three to six months, we see a 10 times improvement on 
[foundational] models... six months ago, [it] used to take like, 
40 minutes an hour, so now it's only 20 minutes."

4. ORB의 3단계 부트스트래핑

4.1 Stage 1: Table Sampling & Summaries

프로세스

벤더 설명:

"when you start ORB, we first connect to the catalog, list [all] 
the tables, and start going one table... sampling... data multiple 
times, so that we can start understanding what each column does 
and what it means."

작업:
1. 카탈로그 연결: Iceberg REST Catalog
2. 테이블 목록: 모든 테이블 리스팅
3. 데이터 샘플링: 각 테이블 여러 번 샘플링
4. 컬럼 이해: 각 컬럼의 의미 파악

Table Summaries 생성

벤더 설명:

"after we do all this sampling... we call those table summaries"

예시:

Table: customers
Columns:
- customer_id (INT): Primary Key, 1~100000
- name (STRING): Person names
- email (STRING): Email addresses
- country (STRING): Country codes (KR, US, JP)
- created_date (DATE): Registration dates

Summary:
"Customer master table with 95,432 records. 
Contains customer demographics. 
Main markets: Korea (65%), US (20%), Japan (15%)."

소요 시간

벤더 언급:

"the [bootstrapping] takes a while because we're sampling so much 
data... For us, it takes like an hour, and we only have 53 tables"

예상:

53 테이블: ~1시간
500 테이블: ~10시간 (예상)
최초 1회만: 이후 증분 업데이트

4.2 Stage 2: Correlation Analysis

목적

벤더 설명:

"we start doing what we call a correlation analysis, to try to 
discover if there's data columns with similar names in different 
[tables]."

분석:

유사한 컬럼명 찾기
관계 추론
테이블 클러스터링

예시

테이블 관계 발견:

Table: customers
- customer_id (Primary Key)

Table: orders
- customer_id (Foreign Key?)
- order_id

Table: payments
- order_id (Foreign Key?)
- payment_id

ORB 추론:
"customers.customer_id → orders.customer_id
 orders.order_id → payments.order_id"

암호화된 컬럼명

벤더 언급:

"even if the table name is [encrypted], we will still know there's 
a relationship. But if not, we establish the correlation."

능력:

컬럼명 암호화돼도: 데이터 패턴 분석
값 분포: 통계적 상관관계
Join 가능성: 추론

Clustering

벤더 설명:

"we have like... a clustering of tables, where we say, these tables 
seem to be related, this table seems to be related."

결과:

Cluster 1: E-commerce
- customers
- orders
- payments
- products

Cluster 2: Logistics
- shipments
- warehouses
- inventory

Cluster 3: Marketing
- campaigns
- clicks
- conversions

4.3 Stage 3: Operator Review & Correction

Human-in-the-Loop

벤더 설명:

"we present that to the ORB operator. That's kind of like the 
bootstrapping process... You can review what ORB is assuming... 
and then correct it"

프로세스:

1. ORB 추론 결과 표시
   "customers.customer_id → orders.customer_id?"

2. Operator 확인
   ✅ Correct: "맞습니다"
   ❌ Incorrect: "아니요, customer_code입니다"

3. ORB 학습
   메모리에 저장 → 향후 반영

4. 반복
   모든 관계에 대해

교정 예시

벤더 설명:

"you... can say this group was actually one, or this table is 
actually connected this way"

시나리오:

ORB: "Table A, B, C는 별개인 것 같습니다"
Operator: "아니요, 모두 같은 그룹입니다"
ORB: "알겠습니다. 학습했습니다."

5. 소프트웨어 패러다임 전환

5.1 기존: 코드 작성

전통적 방식:

Requirements → Design → Code → Test → Deploy
(수 주~수 개월)

5.2 ORB: 소프트웨어 생성

벤더 비전:

"the entire software industry coming to a paradigm [where] software 
[is not] written anymore. Software is created on demand."

새로운 방식:

Natural Language Request → ORB → Application (20분)

예시:

Old Way:
"Dashboard 필요" → PM → Dev → QA → Deploy (2주)

ORB Way:
"Dashboard 보여줘" → ORB → Dashboard (20분)

5.3 반복 개선

피드백 루프:

"If the user says, I would like to change colors, I would like 
to add functionality, [in] just plain language, ORB actually 
builds [it]"

예시:

User: "색상을 파란색으로 바꿔줘"
ORB: [코드 수정 → 재배포] "이렇게요?"

User: "필터 추가해줘 - 제품별, 지역별"
ORB: [기능 추가] "이제 필터가 있습니다"

User: "완벽해!"
ORB: "Production 배포할까요?"

6. 기술 스택

6.1 Foundation Models

현재 사용

벤더 설명:

"right now, we're using [foundational model] vendors, because the 
GPUs that we have... it's not enough."

하드웨어:

A100 GPUs: 40개 보유
메모리: 8GB/GPU → 320GB total
문제: 최신 대규모 모델 실행 불가

외부 사용:

Anthropic (Claude)
OpenAI (GPT)
xAI (Grok)

Fine-tuning 경험

벤더 언급:

"we... fine tune[d] our model... when the product was called Unica. 
We were running our own fine tune[d] models... for Prompt Object, 
we also fine tune[d] the model."

이전 제품:

Unica: 자체 Fine-tuned 모델
Prompt Object: Fine-tuned 모델

모델 독립성

벤더 전략:

"we're building ORB in a way that the provider... It's not important 
right now. So we can test different ones"

유연성:

Multi-model 지원
지역별 선택: 규제 대응
최적 모델: 성능/비용

지역별 모델 규제

벤더 우려:

"every region will have different requirements regarding the models 
that they are allowed to use [in the] US, Anthropic, OpenAI, xAI 
are fair play. But... Europe's already locking down some of the models."

예상:

US: OpenAI, Anthropic, xAI 허용
Europe: 규제 시작
Asia/Korea: 미정 (확인 필요)

6.2 Iceberg 의존성

벤더 강조:

"ORB can only understand the data if it's in a [structured] table. 
Right now we [only support] Iceberg."

현재:

✅ Iceberg: 완전 지원
❌ Kafka Topics: 미지원 (향후 가능)
❌ 파일 (Parquet/CSV): 직접 미지원

이유:

메타데이터 필요: 스키마, 타입
Iceberg: 풍부한 메타데이터
표준화: 일관된 접근

7. 릴리스 계획

7.1 현재 상태

벤더 확인:

"ORB is still like three, three to five months away from being 
released."

타임라인:

현재: 2026년 2월
릴리스: 2026년 5~7월
상태: 내부 테스트

7.2 개발 우선순위

Stage 1: 데이터 접근 민주화 (현재)
벤더 설명:

"ORB is all about democratizing access to data. That's right now. 
The stage one is democratizing access to data."

기능:

Query & Answer
Chat with Data
Application Building

Stage 2: 데이터 수집 (향후)
벤더 계획:

"the next stage is to focus on ingestion, because... data needs 
to come in real[time], as it's being produced, we want to start 
[writing to] iceberg."

기능:

Real-time 데이터 수집
Iceberg 직접 쓰기
스트리밍 처리

Stage 3: Real-time 애플리케이션 (미래)
벤더 비전:

"we'll start looking into more of a real time applications... 
we definitely want ORB to be able to infer on data that's coming in."

기능:

Real-time Inference
자동 모델 학습 (가능성)
이벤트 기반 처리

8. SK Hynix 사용 사례

8.1 반도체 제조 데이터 분석

현재 문제

고객사 설명:

"they have a lot of... data analysts. And they have a lot of data... 
pressure sensor data... image... numbers... What they're doing 
right now is they don't really have a pipeline. They rather just 
collect all these... data, and then analyze it."

현황:

다양한 데이터: 압력, 온도, 이미지, 수치
분리된 분석: 각각 별도 처리
통합 불가: 파이프라인 없음

요구사항

고객사 희망:

"I have this specific [recipe] for this semiconductor manufacturing, 
and then... I want to know everything about it. So I don't want 
to do separate analysis for image. I don't want to do separate 
analysis for... pressure sensor data."

목표:

Recipe 기준 통합: 특정 제조 공정
모든 데이터: 이미지 + 센서 + 수치
단일 분석: 통합 처리

8.2 결함 감지 (Fault Detection)

2가지 접근

고객사 설명:

"They have two fault detection processes... one is real time to 
make sure that nothing's going wrong. And two is... at the end 
of the process, has it gone wrong?"

1. Real-time FDC:

목적: 진행 중 오류 감지
시간: 즉시
조치: 공정 중단/조정

2. End-of-Process:

목적: 완제품 검사
시간: 8개월 후
조치: 불량 원인 분석

데이터 규모

고객사 설명:

"when you build a wafer in the fab, it takes eight months to 
finally make [it] as a product. And for that eight [whole] month 
data will keep being accumulated"

특성:

제조 기간: 8개월/웨이퍼
데이터 누적: 지속적
Recipe별: 제품마다 다름

2가지 분석 방법

고객사 설명:

"They have two ways of analyzing things. One is analyzing, comparing 
the data and the rule... and second one [is] only use the data... 
see if it's a failure or not."

Rule-based:

IF pressure > 100 THEN alert("압력 초과")
IF temperature < 50 THEN alert("온도 부족")

Data-driven:

AI 모델이 데이터만으로 불량 판단
(학습된 패턴 기반)

분산 분석 필요

고객사 요구:

"they will have to... do a distributed analysis, because they 
don't want the results to come out [in a] few months... They 
want [it in] real time or... within the eight month time frame."

요구사항:

Real-time: 즉시 결과
8개월 내: 최소 기준
분산 처리: 대규모 데이터

8.3 ORB 적용 가능성

Stage 1 (현재 ORB): 부분 지원

벤더 답변:

"right now, we're [working on] data that [is already in] an 
iceberg [table]. So that means the data already reached the 
iceberg table somehow."

가능:

✅ 이미 Iceberg에 있는 데이터 분석
✅ Recipe별 통합 쿼리
✅ Dashboard 자동 생성

불가능:

❌ Real-time 수집 (Stage 2 필요)
❌ 스트리밍 분석
❌ 자동 모델 학습

Stage 2 (향후): Real-time 지원

벤더 계획:

"the next stage is to focus on ingestion... as data needs to 
come in real[time]"

가능 (향후):

✅ Real-time 데이터 수집
✅ Iceberg 직접 쓰기
✅ 스트리밍 처리

이미지 데이터

고객사 질문:

"structured data... images, image[s]"

벤더 답변:

"image[s], we haven't got [that]... we dropped that and we 
started again."

현황:

❌ 이미지 지원 중단
✅ 재개 예정 (언제인지 미정)
현재: Structured data만

9. 도메인 지식 통합

9.1 현재 제약

벤더 인정:

"domain specific knowledge is something we don't have. That's 
why ORB is still kind of like a general product."

현재:

범용 제품: 일반적인 데이터 분석
제약: Iceberg 데이터만
한계: 도메인 지식 없음

9.2 Legacy 애플리케이션 연동

고객사 문제

고객사 설명:

"they already have like, 1000s of legacy applications, because... 
if you just look at the numeric data... from the fab [you] can't 
even decode it, like, ORB will not know what they're looking at."

상황:

수천 개: Legacy 애플리케이션
도메인 특화: 반도체 제조
암호 같은 데이터: Fab 수치 데이터

연동 불가

벤더 솔직:

"I wish we could connect it to existing applications... But... 
we're trying to have you teach it by actually explaining the process."

현재 방식:

❌ 소스코드 읽기: 불가
❌ 기존 앱 연동: 불가
✅ 수동 교육: 가능

이유:

"we don't want to say, dump [in] your source code and we figure 
[it] out... because [it'll] make ORB feel more confused like 
you have some code that decided to read this table... 100 times."

9.3 학습 방법

벤더 비유:

"it's [like] someone starts teaching like a child. Slowly, we 
start by learning and mastering the process"

프로세스:
1. ORB 부트스트래핑: 테이블 이해
2. Operator 교정: 관계 수정
3. 점진적 학습: 반복
4. 내부 메모리: 축적

Internal Memory System:

"in the ORB internal memory system, it's trying to build like 
an understanding of what each table, each relationship, is."

9.4 향후 가능성

벤더 전망:

"I wouldn't be surprised that we'll be talking about it like in 
a year or two, or even less."

예상:

1~2년 후: 도메인 지식 통합 가능
AI 발전: 빠른 속도
방법: 미정 (연구 중)

10. 자동 모델 학습 (미래)

10.1 가능성

벤더 언급:

"ORB may actually decide to train models... But right now... 
we haven't even started [on] that. We only have talk."

현재:

논의만: 구현 없음
가능성: 있음
우선순위: 낮음

10.2 시나리오

벤더 설명:

"if you have the data, most of the problems that you can do on 
top of data are known, and the most foundational model[s]... 
are trained for that task."

예시:

User: "판매 예측 모델 만들어줘"

ORB (미래):
1. 데이터 분석 (sales 테이블)
2. 적합한 모델 선택 (Time Series Forecasting)
3. 학습 데이터 준비
4. 모델 학습 실행
5. 평가 및 배포
6. 예측 API 제공

어려움:

"it's hard... for me, it's hard to imagine that my product could 
decide to train a very sophisticated model."

11. Sandboxing (보안)

11.1 필요성

벤더 언급:

"one of the interesting features... is sandboxing the AI, because 
sometimes the AI... tr[ies] some wild things."

이유:

AI가 예측 불가능한 시도
데이터 손상 위험
보안 문제

11.2 구현

벤더 설명:

"we don't let the AI run wild, but we put it in a isolated space 
where [it] doesn't see other than the files it has"

격리:

독립 환경: Container/Namespace
제한된 권한: Read-only Iceberg
제한된 파일: 작업 파일만

11.3 현재 상태

데모 실패 이유:

"that's the part of our demo that failed... the sandboxing... 
we're [still] trying to get it right"

상태:

개발 중
안정화 필요
완성도 미달

12. 액션 아이템

12.1 벤더 측 (MinIO AI)

즉시 실행 (릴리스 전)

ORB 안정화
- Kubernetes 환경 수정
- Sandboxing 완성
- 데모 환경 구축
문서화
- 사용자 가이드
- API 문서
- 부트스트래핑 가이드
이미지 지원 재개
- Computer Vision 통합
- Iceberg + 이미지 메타데이터

릴리스 (3~5개월 후)

GA 출시
- Production 준비
- 성능 최적화
- 모델 선택 확정
Stage 2 계획
- Real-time 수집 설계
- 스트리밍 처리
- Kafka 통합

12.2 고객사 측 (SK Hynix)

즉시 실행

데이터 준비
- Iceberg 테이블 확인
- Recipe 데이터 구조화
- 센서 데이터 → Iceberg
요구사항 명확화
- FDC 상세 스펙
- Real-time vs Batch
- 도메인 지식 문서화
ORB 평가
- GA 릴리스 대기 (5~7월)
- Pilot 테스트 계획
- ROI 분석

중기 (ORB GA 후)

Pilot 프로젝트
- 1~2 Recipe 테스트
- Dashboard 자동 생성
- 분석가 피드백
통합 계획
- Legacy 앱 연동 (수동)
- 도메인 지식 입력
- 사용자 교육

13. 예상 효과

13.1 생산성

분석 시간:

기존: 60분+ (분석가)
ORB: 수 초~수 분
절감: 90%+

애플리케이션 개발:

기존: 수 주~수 개월
ORB: 20분
절감: 99%+

13.2 접근성

전문성:

기존: SQL/Python 필수
ORB: 자연어만
사용자 확대: 전 직원

병목 제거:

기존: 분석가 리소스 제약
ORB: 무제한 동시 처리

13.3 혁신

탐색적 분석:

즉각적인 What-if 분석
빠른 가설 검증
데이터 기반 의사결정

14. 위험 요소 및 완화

14.1 릴리스 지연

위험

3~5개월 릴리스 목표
Kubernetes 불안정
Sandboxing 미완성

완화

✅ GA 릴리스 대기
✅ 대안: 기존 도구 활용
✅ Pilot 신중히 계획

14.2 도메인 지식 부족

위험

범용 제품
반도체 제조 지식 없음
Legacy 앱 연동 불가

완화

✅ 수동 교육 (Operator)
✅ 점진적 학습
✅ 기대치 조정

14.3 이미지 데이터 미지원

위험

Computer Vision 필요
현재 중단 상태
재개 일정 불명

완화

✅ 수치 데이터 먼저
✅ 이미지는 향후
✅ 대안 도구 병행

15. 참고 자료

15.1 MinIO AI 문서

ORB 개요 (릴리스 후)
Iceberg 통합 가이드
API 문서

15.2 Iceberg

메타데이터 구조
REST Catalog

15.3 AI/ML

Foundational Models
Fine-tuning
Prompt Engineering

16. 결론 및 다음 단계

16.1 핵심 합의사항

✅ ORB는 혁신적 (소프트웨어 생성)
✅ 3~5개월 후 GA (2026년 5~7월)
✅ Iceberg 필수 (현재)
✅ 도메인 지식 부족 (수동 교육)
✅ Real-time은 Stage 2 (향후)

16.2 즉시 실행 항목

ORB GA 릴리스 대기
Iceberg 데이터 준비
Pilot 계획 수립

16.3 성공 기준

✅ 분석 시간 90% 단축
✅ Dashboard 20분 생성
✅ 전 직원 데이터 접근
✅ Legacy 지식 통합

문서 버전: 1.0
최종 수정일: 2026년 2월 4일
다음 리뷰: ORB GA 릴리스 후 (2026년 5~7월)

부록: 주요 인용문

데이터 민주화

"we're trying to democratize access to data lake... AI... can 
actually read out of a catalog... and either do the traditional 
query or the traditional Python program."

소프트웨어 생성

"the entire software industry coming to a paradigm [where] software 
[is not] written anymore. Software is created on demand."

20분 애플리케이션

"building a data application... takes probably 20 minutes."

Iceberg 표준화

"very similar to what the JDBC connector did 25 years ago... 
iceberg, standardized access patterns for data"

3단계 부트스트래핑

"ORB... first connect to the catalog, list [all] the tables... 
sampling... we call those table summaries... correlation analysis... 
clustering of tables"

도메인 지식

"domain specific knowledge is something we don't have. That's 
why ORB is still kind of like a general product."

Young-Kyoo Kim

engineer

이전 포스트

26F12L

다음 포스트