#데이터베이스 ai #오라클 #관계형데이터베이스 #IoT
요약: 왜 이 문서가 중요한가?
Oracle AI World 컨퍼런스의 핵심 내용과 관계형 데이터베이스의 역사적 의의를 다루는 것으로, 라리 엘리슨의 비전과 현대 AI 기술의 한계를 이해하는 데 필수적입니다. 특히 기존의 거대한 관계형 데이터베이스 인프라와 생성 AI를 어떻게 통합할 것인가 하는 문제는 엔터프라이즈 환경에서 가장 현실적인 도전입니다. 데이터베이스 설계 철학부터 최신 AI 기술까지 40년 경력의 전문가들이 논의하는 내용으로, 소프트웨어 아키텍처와 기술 경영진들에게 매우 실용적인 통찰을 제공합니다.
상세 요약
1단계: 핵심 논의 주제 및 배경
1.1 Oracle 컨퍼런스의 변화
- 마케팅 전략의 급변: Oracle Cloud World에서 시작했던 컨퍼런스가 행사 중반에 Oracle AI World로 변경됨
- 비즈니스 우선순위 반영: AI가 Cloud보다 더 매력적인 주제로 간주되는 현실을 보여줌
1.2 게스트 소개 및 배경
- Demetri: 40년 이상의 데이터베이스 경력 보유
- 초기: 어셈블리 언어로 메인프레임 시퀀셜 파일 개발
- P 시스템(pre-relational 시스템) 경력
- 프랑스의 Inter Technique에서 P 시스템 기반 하드웨어 및 소프트웨어 개발
- 첫 관계형 데이터베이스: Oracle
2단계: 관계형 데이터베이스의 역사적 의의
2.1 SQL의 등장과 Oracle의 승리
- IBM의 연구 vs Larry Ellison의 실행
- SQL 표준 연구는 IBM에서 출발했으나 초기에 구현하지 않음
- Ellison의 핵심 전략: 강공적 판매 전략 (aggressive sales strategy)
- 거래 중심의 영업 방식 (deal-driven approach)
- 고객에게 소프트웨어 판매 후 자체 구현 강요
- 고가의 컨설턴트 제공 (시간당 $600)
- Oracle vs Informix 경쟁
- Oracle의 비즈니스 모델과 플랫폼 고착 전략이 경쟁사 압도
2.2 플랫폼 지배력의 이동
- 관계형 데이터베이스의 표준화: SQL이 사실상 표준으로 확립됨
- 애플리케이션 레이어의 중요성: 1990년대 중반 이후, 데이터베이스보다는 애플리케이션이 플랫폼을 지배한다는 인식 변화
- 시대별 경쟁 기술
- 1980-90년대 초: Page-level locking(Sybase) vs Row-level locking(Oracle)
- Sybase의 성능 우위, 하지만 Oracle의 일관성 우위
- 1990년대: Triggers와 Stored Procedures 전쟁
- 1980-90년대 초: Page-level locking(Sybase) vs Row-level locking(Oracle)
2.3 데이터베이스 구성요소의 진화
- SQL의 강력함: DDL(Data Description Language) + Query Language
- 메타데이터를 통한 스키마 설계 및 구현
- 이 구조가 현대 AI와의 통합에서도 여전히 중요
3단계: 데이터베이스 스키마 설계 및 메타데이터의 현실
3.1 Merise 방법론과 개념 모델링
- 개념 모델링의 가치: 데이터베이스 구현 전에 비즈니스 개념을 먼저 정의
- Entity-Relationship(ER) 다이어그램으로 구조화
- 개념 단계에서는 구현 기술과 독립적
- 물리적 구현 시 선택: 관계형, 시퀀셜 파일, 객체 데이터베이스 등
3.2 현실의 스키마 문제
- 대부분의 데이터베이스 스키마 현황:
- 부실하게 설계되어 빠르게 출시된 제품이 대부분
- 다년간의 패치와 핫픽스로 인한 고도의 복잡성
- 문제점:
- 중복 데이터 존재
- 정규화 규칙(Normal Form) 위반
- 순환 참조 (circular references)
- 메타데이터 품질 저하
3.3 메타데이터의 중요성과 어려움 (매우 중요)
- 메타데이터 정제의 난제: 데이터 정제는 ETL로 가능하나, 메타데이터 정제는 극도로 어려움
- 기업 환경에서의 현실:
- 개념적 설계 vs MVP(Minimum Viable Product) 철학의 충돌
- 초기 설계의 부실함이 장기적 기술 채무로 작용
- 현재의 엉망진창한 스키마 상태에서 AI를 적용할 수 없음
4단계: 생성 AI와 관계형 데이터베이스의 통합 문제
4.1 근본적인 패러다임 충돌
-
관계형 데이터베이스의 원래 목적
- 1970년대: 당시 컴퓨터는 인간의 복잡한 개념(주문, 고객 등)을 직접 처리 불가
- 해결책: 추상화 계층 도입 → 관계형 모델 탄생
-
현재의 역설
- 현대 AI(생성 AI)는 인간의 텍스트를 이해함
- 따라서 구조화된 관계형 데이터를 다시 인간 텍스트로 변환해야 AI가 활용 가능
- 결과: 관계형 데이터베이스는 생성 AI에게 “나쁜” 형식
4.2 Oracle 26 AI와 스키마 임베딩
-
Oracle의 솔루션 방향: Oracle Database 26 AI
- Autonomous Database의 진화
- Vector database 통합
- 관계형 테이블과 벡터화된 데이터 간의 조인 가능성
-
Schema Embedding의 핵심 문제
- 단일 테이블 변환: 비교적 간단 (트랜잭션 데이터 → 텍스트)
- 복수 테이블 관계 변환: 매우 복잡
- 외래키(Foreign Key), 기본키(Primary Key) 관계를 어떻게 텍스트로 표현할 것인가?
- 이것이 가장 어려운 문제이며, Ellison의 1.5시간 강연에서도 명확한 해결책이 없었음
4.3 Larry Ellison의 Oracle AI World 키노트 분석
-
기술적 발표의 한계:
- 개념적 설명은 충분했으나 구체적인 구현 방법은 부재
- 실제로 작동하는 방식에 대한 상세 설명 부족
-
Demetri의 Agent Scripts 비판
- Salesforce Agentforce에서 소개된 “Agent Scripts”
- 개념: Agent 구성에 코드를 직접 임베드
- 문제점: Agent 자체의 가치가 훼손됨 (수작업으로 코드 작성해야 하므로)
- 실제 모습: Agent는 단순히 programmatic shell일 뿐, 진정한 자동화가 아님
5단계: 해결 방안 탐색
5.1 Blob 데이터 타입의 재조명
- Blob의 원래 목적: 비정형 데이터 저장
- 새로운 가능성: 구조화된 SQL 데이터를 Blob으로 변환
- 문제점: Blob에서 역변환(de-blob)이 복잡함
- 하지만 이 접근이 관계형 데이터와 생성 AI 간 가교 역할 가능
5.2 LLM을 번역 계층으로 활용
- 패러다임 전환: LLM을 "솔루션"이 아닌 "인터페이스"로 인식
- 구체적 활용:
- Relational 데이터 구조를 이해하는 LLM
- 의도(Intent)를 SQL로 안정적으로 변환
- SQL 쿼리를 통한 데이터 검색 후 텍스트 생성
- 이 방식이 데이터 무결성과 일관성 보장
5.3 Facebook의 실제 사례
- MySQL 성능 개선: Facebook이 MySQL을 최적화하며 기여
- PHP 성능화: Project Hip Hop으로 PHP를 동적으로 C 코드로 컴파일
- 선택적 기술 활용:
- 트랜잭션/분석용: MySQL (관계형)
- 특정 요구사항: NoSQL (비정형)
- 이 하이브리드 접근이 여전히 가장 실용적
6단계: 기술 스택 및 아키텍처 고려사항
6.1 프라이빗 AI 구축 (Enterprise AI)
-
기본 개념: Private data + Pre-trained LLM = Enterprise Brain
- 기업의 고객 데이터를 공개 API(예: OpenAI)에 노출하지 않음
-
실제 구현 방법 (전문가의 개인적 접근)
- PostgreSQL 선택 (PG Vector 플러그인 활용)
- IoT 데이터 수집 엔진으로 데이터 유입
- 모델 파인튜닝 및 RAG (Retrieval-Augmented Generation) 적용
-
기업 AI의 현실:
- C3.AI가 수년 전부터 구현 (완벽하지는 않음)
- 완전 오픈소스 솔루션도 있으나 품질 문제 존재
6.2 하이퍼스케일 데이터센터 인프라의 변화
-
Oracle Cloud Infrastructure (OCI) 트렌드
- Stargate 프로젝트로 대규모 투자 진행 중
- Nvidia H100, B100, GB200 칩 기반 인프라 구축
-
아키텍처 변화의 속도
- 2년마다 완전히 새로운 기술 스택 등장
- 냉각 시스템, 전원 배분, 데이터센터 레이아웃 모두 변경
- 기존 투자의 낙후화(obsolescence) 속도 가속화
-
표준화 노력: Open Compute Project (OCP)
- 하이퍼스케일러들 간 호환성 및 상호운용성 추구
- Rack 설계, 냉각 아키텍처 통일 시도
- 각 하이퍼스케일러의 독자적 최적화 vs 표준화의 균형 문제
6.3 소프트웨어 추상화의 역할
- 기존 하드웨어 활용의 가능성
- 소프트웨어 추상화 계층이 충분하면 구형 기술도 느리지만 계속 활용 가능
- 하지만 역사적 경험: 이론과 현실의 괴리 발생 가능
7단계: AI 거품과 지속가능성 논의
7.1 현재 AI 투자의 현실
-
막대한 인프라 투자
- 기업과 부유층: AI 인프라에 전재산 투자 중
- Stargate, Colossus, Microsoft Foxcon fab 등 대규모 프로젝트
- 총 수조 달러 규모의 투자
-
투자 수익성의 불확실성
- 현재 기술이 예상한 ROI를 제공할 것인가?
- 투자 회수 기간 vs 기술 낙후화 속도의 불균형
7.2 생성 AI의 미래 모니터화
-
거품 가능성
- 비즈니스 관점에서 많은 AI 솔루션이 과장된 주장 제시
- 브리핑 콜에서 들은 많은 마케팅 주장이 실제 검증 시 근거 부족
-
중요한 질문
- 투자의 현실화 가능성 vs 지속불가능한 거품
- 현재의 무료 서비스 지속 가능성 (ChatGPT, Claude)
7.3 비용 모델의 진화
-
구독 모델의 한계
- 전례: 과거 Per-task 모델은 실패
- 미래: 광고 도입, 구독 확대, 기업 라이센싱 혼합
-
지속가능성 시나리오
- 시나리오 1: 5억 사용자 × 월 20달러 = 월 100억 달러 가능성
- 시나리오 2: 효율성 개선으로 전력/하드웨어 수요 감축
- 시나리오 3: 시장 붕괴 및 투자 철수 (가장 비관적)
8단계: 운영 체제 및 프라이버시 이슈
8.1 Windows 11 25H2 업데이트의 AI 통합
-
Microsoft의 Co-Pilot 임베드
- 운영체제 차원에서 AI 기능 강화
- 프라이버시 침해 우려 증가
-
문제점
- 사용자 동의 없는 광범위한 데이터 수집
- Windows/macOS의 감시 기능 강화
- Linux의 상대적 자유도 재평가
8.2 Apple의 AI 전략
-
M5 칩 발표
- A19 Pro의 신경망 가속기(Neural Accelerators) 포팅
- 기술 의미:
- Tensor cores for matrix multiplication (GPU는 기본적으로 미제공)
- 별도 커널로 행렬 연산 최적화
- iPhone 17 Pro의 AI 성능 대폭 향상
-
Apple의 서버측 기술 (추측)
- 공개되지 않은 서버 기술 개발 중
- 텍사스에서 제조 (자체 설계 기반)
- AMX extension: Early M series에서부터 임베드됨
8.3 프라이버시 선택
- Linux의 가능성
- 감시 기능 부재로 “자유로운 노트북” 제공
- 이전 MacBook Air 11"를 Ubuntu로 변환 시 뛰어난 성능
- 모바일(Android/Linux 기반) vs 데스크톱 분절화 극복 가능성
- Chromebook, Android-to-Desktop 이동으로 조용히 진행 중
9단계: 하드웨어 및 소비자 선택
9.1 노트북 선택 기준
-
MacBook Pro 16"의 문제
- M4 칩으로 강력하지만 과도하게 무거움 (약 1000 파운드에 가까운 느낌)
- 대부분의 사용자에게는 오버스펙
-
MacBook Air 15" (M2 이상) 추천
- 대부분의 업무에 충분한 성능
- 무게와 두께의 균형 우수
- 비용 효율성
- iPad Air와 유사: Pro 버전이 필요 없음
-
오래된 MacBook Air 11" + Ubuntu
- “마법같은” 성능
- 집안 IoT 용도 최적화
- OldEdition 같은 자동화 도구 운영 가능
- 의문: Linux에서 구형 기계가 왜 이렇게 잘 작동하는가?
- Windows/macOS: 최신 기능으로 인한 성능 저하
- Linux: 최적화된 커널과 경량 환경
9.2 스마트폰 시장 동향
-
iPhone 17 Pro
- 신경망 가속기로 AI 처리 대폭 개선
- 카메라 성능 개선
- 오렌지 색상 변색 논란 (실제: 알루미늄 표면 벗겨짐일 가능성)
-
Samsung Galaxy Edge vs iPhone Air
- Galaxy Edge: 200메가픽셀 카메라, 광학 줌
- iPhone: Fusion 카메라 시스템도 우수함
- 선호도: 라이프스타일 선택 (Apple) vs 기술 사양 (Samsung)
-
시장 현황
- Samsung: 여전히 세계 1위 스마트폰 제조사
- Apple은 생활방식(lifestyle) 브랜드로서의 가치
- Samsung은 기술 리더십 측면에서 Apple 선행 (예: 폴더블폰)
10단계: 데이터베이스 기술의 미래 전망
10.1 SQL의 영원함 (매우 중요)
- 역사적 증명: 30년 이상 기업 데이터가 관계형 데이터베이스에 저장
- 미래 전망: 가장 광범위하게 알려진 쿼리 언어 (프로그래밍 언어보다 더 많은 사람이 알 것으로 추정)
- NoSQL의 실패:
- Facebook: 메인 피드에서 NoSQL로 이동했으나 분석용으로는 MySQL 유지
- 시장 현실: 거의 모든 비즈니스 데이터가 여전히 관계형 데이터베이스에 저장
10.2 구조화된 데이터 vs 비정형 데이터
-
구조화 데이터의 우위
- 트랜잭션 데이터: 구조화된 형태 필수
- 비즈니스 추상화 계층으로 작동
- 컴퓨터 처리 최적화
-
비정형 데이터의 현실
- 텍스트, 단락, 소셜 미디어 포스트
- 이전: Lotus Notes (반정형) vs SQL의 전쟁
- 현재: AI/생성 AI의 등장으로 비정형 데이터의 가치 재평가
- 미래: 두 세계의 통합 필요 (schema embedding의 필요성)
10.3 기업 문화와 기술 선택
-
“좋은 기술 vs 충분한 기술” 철학
- Larry Ellison의 고명한 지적: “Sometimes good enough is good enough”
- Sun Microsystems 붕괴 시기의 명언
-
현실의 선택
- 값비싼 E10K 서버 vs 저가 Linux 박스
- PHP + MySQL이 “충분한” 이유 (현재 인터넷의 25% 이상이 WordPress)
- WordPress 자체는 기술적으로 완벽하지 않으나 “돈을 버는” 도구
- 핵심: 기술의 우수성보다 비즈니스 성과(Margin)가 우선
10.4 기업 AI의 실제 과제
-
기존 인프라와의 통합 필수
- “Brown Field” 관리: 기존의 거대한 레거시 시스템
- 완전히 새로운 AI 시스템으로 대체 불가능
- 기존 기술의 효율성이 여전히 뛰어남
-
일부 구형 기술의 우월성
- 대규모 데이터 처리 시 관계형 DB가 LLM보다 효율적
- 구조적 트랜잭션 일관성 필요 시 AI는 적절하지 않음
11단계: 문화 및 철학적 성찰
11.1 Matrix와 철학적 메타포
-
Architect의 명언 (The Matrix Reloaded에서)
- 첫 번째 Matrix: 완벽한 유토피아, 인간이 거부
- 두 번째 설계: 인간의 고통과 불완전함 반영, 수용됨
-
현재 AI 개발의 패러독스
- AGI/초지능은 "유토피아"로 판매됨
- 하지만 인간은 투쟁과 의미를 통해서만 가치를 느낌
- 이 기본적 인간 본성이 간과됨
11.2 소비문화의 몰락과 재정의
-
전자상거래 거품 (E-commerce Bubble)
- Pets.com의 실패 (2000년)
- Amazon의 “구조적 우위”
- 주(state) 차원의 세금 감면 (장년 간)
- 적자 운영 허용 (수년)
- 현금 흐름 생성 (배당금 없음)
- 결과: 월스트리트 속임 성공, 자유로운 자금 조성
-
최신 AI 상거래의 문제
- CNBC 등 미디어의 과장된 주장
- 예: “Walmart가 ChatGPT 사용하면 사람들이 2배 더 많은 화장지 구매”
- 현실: 동일한 e-commerce BS가 "AI 포장"으로 재출시
- 기술 혁신 없이 마케팅만 변경
11.3 K-pop과 AI의 상징성
-
제조된 엔터테인먼트
- K-pop 그룹: 철저히 기획되고 제작된 상품
- 가수보다 성우(보컬 담당자)가 더 인기 증가
-
AI 셀러브리티의 불가능성
- 인간은 AI의 "기술적 성취"에 환호하지 않음
- "인간의 성취"라는 증명이 필수
- AI 가수 아이디어: 흥미로우나 근본적 한계
- 핵심 통찰: 인간은 "인간의 노력"에만 가치 부여
주요 용어 정의
| 용어 | 설명 |
|---|---|
| 관계형 데이터베이스 | 테이블 형태의 행과 열로 데이터를 저장, SQL로 쿼리 |
| DDL (Data Description Language) | 데이터 구조를 정의하는 언어 (CREATE, ALTER, DROP) |
| PL/SQL | Oracle의 프로시저형 SQL 확장 |
| T-SQL | Microsoft SQL Server의 프로시저형 SQL 확장 |
| 정규형 (Normal Form) | 데이터베이스 설계 최적화 기준 (1NF, 2NF, 3NF 등) |
| 메타데이터 | 데이터를 설명하는 데이터 (스키마, 구조 정보) |
| Blob (Binary Large Object) | 바이너리 형태의 대용량 데이터 저장 타입 |
| Vector Database | 벡터 형태의 임베딩 데이터 저장 (AI/생성 AI용) |
| Schema Embedding | 관계형 스키마를 벡터/텍스트 형태로 변환 |
| RAG (Retrieval-Augmented Generation) | 검색된 데이터를 바탕으로 텍스트 생성 |
| Agent Scripts | Salesforce Agentforce의 프로그래밍 가능한 Agent 스크립트 |
| Brown Field | 기존의 레거시 IT 인프라와 기술 |
| Stargate | OpenAI와 SoftBank, NVIDIA의 AI 인프라 프로젝트 |
실용적 팁 및 주의사항
팁:
- 기업 환경에서 AI 도입 시, 기존 관계형 데이터베이스를 완전히 버리지 말 것. 하이브리드 접근이 필수.
- 메타데이터 정제의 어려움을 간과하지 말 것. 데이터 정제보다 메타데이터 정제에 더 오랜 시간 소요.
- 개념 모델링 단계의 중요성 재인식. MVP 속도와 장기적 유지보수성의 균형 필요.
- 새로운 기술 투자 시, 기존 소프트웨어 추상화 계층의 효율성을 재평가할 것.
- 기존 기술(WordPress, MySQL)의 "충분함"을 존중할 것. 모든 문제가 최신 기술로 해결되지 않음.
주의:
- Agent와 AI 자동화 도구의 “노-코드” 약속을 그대로 믿지 말 것. 실제로는 상당한 맞춤 코딩 필요 (Agent Scripts 사례).
- AI 인프라 투자의 ROI 불확실성을 간과하지 말 것. 기술 낙후화 속도가 투자 회수 기간을 초과할 수 있음.
- 현재의 무료 AI 서비스(ChatGPT, Claude) 이용 시 지속불가능성 고려. 향후 광고나 구독 모델로 전환 가능.
- 프라이버시: Windows 11 최신 업데이트와 macOS의 감시 기능 증가에 주의. 프라이버시 중시 시 Linux 고려.
- 구형 하드웨어의 완전한 대체 어려움. 특히 AI 인프라는 2년마다 아키텍처 변경으로 기존 투자 낙후화 위험.
코드 및 기술 예제
1. PostgreSQL기반 프라이빗 AI 구축 (개념도)
-- 기본 데이터 테이블
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(100)
);
-- Vector 임베딩을 위한 테이블 (PG Vector 플러그인)
CREATE TABLE customer_embeddings (
id SERIAL PRIMARY KEY,
customer_id INTEGER REFERENCES customers(id),
embedding vector(1536), -- OpenAI 임베딩 차원
content TEXT
);
-- 관계형 데이터와 벡터 데이터의 조인 쿼리
SELECT c.id, c.name, ce.content
FROM customers c
JOIN customer_embeddings ce ON c.id = ce.customer_id
WHERE ce.embedding <-> '[0.1, 0.2, ...]'::vector < 0.5;
설명:
- 구조화된 고객 데이터는
customers테이블에 유지 - 벡터 임베딩은 별도 테이블에 저장하여 정규화
- LLM의 쿼리 이해 및 관계형 데이터 검색 후 텍스트 생성
2. Agent Scripts (Salesforce Agentforce) 패턴
// Agent 정의에 임베드된 코드
agent {
name: "SalesAssistant",
instructions: "...",
// 직접 코딩된 비즈니스 로직 (Agent Scripts)
scripts: {
validateLead: function(lead) {
if (lead.score > 50) {
return "High priority";
}
return "Low priority";
},
fetchData: function(query) {
// SQL 쿼리로 관계형 DB 접근
return database.query(query);
}
}
}
문제점:
- 이렇게 코드화되면 "에이전트"가 아니라 "복잡한 함수"일 뿐
- 자동화의 진정한 의미 상실
3. 데이터베이스 성능: Row-level vs Page-level Locking
-- Oracle (Row-level Locking) - 더 안전하지만 느릴 수 있음
BEGIN TRANSACTION;
UPDATE orders SET status = 'processed' WHERE id = 123; -- 한 행만 잠금
COMMIT;
-- Sybase (Page-level Locking) - 더 빠르지만 주의 필요
-- 한 페이지(여러 행) 전체가 잠김
BEGIN TRANSACTION;
UPDATE orders SET status = 'processed' WHERE id = 123;
-- 여러 행이 영향을 받을 수 있음
COMMIT;
학습 리소스 및 참고 자료
기본 학습
-
관계형 데이터베이스 역사
- Oracle의 경쟁사 (Sybase, Informix, DB2)
- SQL 표준의 진화
-
데이터베이스 설계
- Merise 방법론
- Entity-Relationship (ER) 다이어그램
- 정규화 (Normal Forms)
-
메타데이터 관리
- 스키마 설계 도구 (IDEF, UML)
- 데이터 거버넌스
고급 주제
-
생성 AI와 데이터 통합
- Vector Databases (Pinecone, Weaviate)
- Retrieval-Augmented Generation (RAG)
- Schema Embedding 연구
-
엔터프라이즈 AI 아키텍처
- Private LLM 구축
- 데이터 보안 및 개인정보보호
- Hybrid AI Systems
-
기술 선택과 비즈니스
- TCO (Total Cost of Ownership) 분석
- Legacy System Integration
- MVP vs Long-term Scalability 균형
관련 기술 및 도구
- 데이터베이스: PostgreSQL, Oracle Database 26 AI, MySQL
- AI/ML: Claude, ChatGPT, Anthropic Endpoints
- 벡터 DB: PG Vector, Pinecone, Weaviate
- 인프라: Open Compute Project (OCP) 표준, NVIDIA H100/B100
권장 도서
- “The Prince” by Niccolò Machiavelli - 비즈니스와 권력에 대한 기본 교과서
- 관계형 데이터베이스 설계 및 정규화 - 학술 자료
결론 및 핵심 통찰
-
SQL은 죽지 않는다: 30년이 넘도록 기업 데이터의 표준. 향후 50년 이상 지속될 것.
-
관계형 DB는 필요악: 생성 AI 시대에도 기존의 거대한 관계형 데이터베이스 인프라는 유지되어야 함. 완전 대체는 불가능.
-
메타데이터가 핵심: 데이터 정제보다 메타데이터 정제가 더 어려움. 스키마 설계 단계의 중요성 재인식 필수.
-
하이브리드 아키텍처 필수: 관계형 데이터 + 벡터 임베딩 + LLM의 조합이 현재 최선의 해결책.
-
"충분함"의 가치: 최신 기술만이 정답은 아님. WordPress, MySQL 같은 “충분한” 기술이 여전히 인터넷의 25% 이상 구성.
-
AI 투자의 현실성 검토: 현재의 막대한 AI 인프라 투자가 지속가능한지, 거품인지 관찰 필요. 기술 낙후화 속도 고려 필수.
-
프라이버시와 자유: Windows/macOS의 감시 강화 대비 Linux의 자유도 재평가 가치 있음.
-
인간 중심의 가치: AI 기술의 가치는 "인간의 성취"를 돕는가에 있음. 순수 AI 성취는 시장에서 평가 받지 못함.