1. 핵심 주장 (What)
Phaidra는 AI 팩토리(초대형 데이터센터)를 위한 AI 에이전트를 구축하는 회사다. 고객이 자신의 데이터센터 상태를 자연어로 질의할 수 있게 한다.
핵심 주장: 1기가와트 규모의 AI 팩토리에는 40만 개 이상의 GPU와 수십만 개의 센서가 있고, 이걸 단순히 LLM 컨텍스트에 넣으면 "Semantic Blindness(의미론적 맹목)" 문제가 발생한다. 해결책은 LLM이 잘 하는 것(계획, 의도 파악)과 잘 못하는 것(구조화 데이터 검색, 정확한 집합 연산)을 명확히 분리하는 것이다.
LLM 기반 쿼리 시스템을 설계할 때의 핵심 패러다임 전환:
- 기존 소프트웨어: 1.0(결정론적 코드) → 3.0(LLM 프롬프트)로 이동
- AI 네이티브 소프트웨어: 3.0으로 시작해서 프로덕션화 과정에서 1.0으로 역행
2. 근거와 맥락 (Why/How)
문제의 배경: Semantic Blindness란?
AI 팩토리의 사용자 쿼리 예시:
- "어떤 칠러가 과열되고 있어?"
- "데이터홀 전체의 온도 분포를 분석해줘"
- "내 GPU 중 문제 있는 게 있어?"
이런 쿼리는 특정 장비 하나에서 그룹 전체까지 다양하다. 그런데 업계에는 표준 네이밍 컨벤션이 없다:
- 알기 쉬운 이름: "Data Hall 11의 Rack-5 GPU"
- 알기 어려운 이름: "CH3-something-something-6"
왜 기존 접근법이 실패하는가:
- 순수 LLM 접근법: 1GW 팩토리엔 40만+ 장비명이 있다. LLM 컨텍스트 윈도우는 유한하다 → 포화 상태 도달
- RAG(벡터 임베딩): "Chiller 6"와 "Chiller 7"처럼 이름이 너무 유사해서 시맨틱 검색이 실패. 20자 문자열에서 한 글자 차이는 벡터 공간에서도 매우 유사
- LLM 주파수 페널티: 비슷한 토큰을 반복 출력하면 LLM 내부 가드레일이 작동해서 출력을 차단. "GPU 100개를 나열해줘" → LLM이 루프인 줄 알고 출력 중단
- 샤딩(분할) 접근법: 장비를 그룹으로 나눠 병렬 LLM 호출 → 환각(없는 장비 생성)과 누락(있는 장비 미포함) 모두 발생 → 미션 크리티컬 시스템에서 치명적
핵심 인사이트: 인스턴스가 아닌 트리 깊이로 성장하라
AI 팩토리는 계층 구조로 되어 있다:
데이터센터 → 데이터홀 → 통로(Aisle) → 열(Row) → 랙(Rack) → GPU
칠러 플랜트 → 칠러룸 → 칠러 → 펌프
냉각탑 유닛
핵심 관찰: 트리 깊이는 매우 천천히 늘어나지만, 너비(장비 수)는 기하급수적으로 증가한다. GPU 수가 64개에서 46만 개로 늘어도 트리 깊이는 거의 동일하다.
3. 구체적 사례와 데이터
4가지 핵심 해결책
① 선형화기(Linearizer)
- 수백만 노드의 그래프를 "루트에서 리프까지의 경로 요약"으로 압축
- GPU에 도달하는 경로: 4개 레이어만 필요
- 64 GPU 시스템과 46만 GPU 시스템이 동일한 크기의 요약을 생성
- LLM에게 전체 장비 목록이 아닌 구조적 맵을 제공
② LLM은 검색이 아닌 계획에 강하다
쿼리 예시: "데이터홀 11에서 과열 중인 GPU 모두 보여줘"
기존 방식: LLM이 모든 GPU 이름을 스캔해서 데이터홀 11에 있는지 + 과열 상태인지 판단
새로운 방식: LLM이 구조화 출력(Search Plan)을 생성
{
"collect": "GPUs",
"scope": "data_hall_11", // 서브트리
"filter": "running_hot"
}
LLM은 계획만 세우고, 실제 검색은 결정론적 코드가 처리
③ 결정론적 리졸버 + 집합 연산
- 사전 인덱싱된 서브트리 활용 (위치 기반, 장비 관계 기반)
- 집합 교차(intersection), 합집합(union) 연산으로 완벽한 리콜 보장
- 퍼지 쿼리도 집합 연산으로 처리 → 100% 재현율
④ 패턴 기반 탐색 (모호한 쿼리용)
- 모호한 쿼리 → LLM이 검색할 패턴을 생성 (전체 이름 목록 대신)
- 예: "CH3-" 으로 시작하는 모든 장비 → 정규식 패턴으로 백엔드 검색
- LLM의 토큰 비용이 일정하게 유지됨 (장비 수에 관계없이)
최종 파이프라인
사용자 쿼리 → [플래너 LLM] → 검색 계획 → [결정론적 리졸버] → 결과 집합
2~3단계 프로세스, 멀티스텝 에이전틱 루프 없음
성능 비교 (실측 데이터)
| 지표 | 구 시스템 | 신 시스템 |
|---|---|---|
| 정확도 @64 GPU | 80% | 100% |
| 정확도 @460,000 GPU | 30% | 100% |
| 토큰 사용 (1GW 검증 패스) | 1억 1,600만 토큰 | 39만 토큰 (300분의 1) |
| 쿼리당 토큰 비용 | 규모에 따라 증가 | 9,000 토큰 고정 |
| 실제 생산 시스템 테스트 | - | 6개 시스템, 66개 케이스, 0건 실패 |
4. 시사점과 실행 포인트
Karpathy의 소프트웨어 프레임워크의 역전
Andrej Karpathy의 관찰:
- Software 1.0: 개발자가 작성하는 결정론적 코드 (정확하지만 유연하지 않음)
- Software 3.0: LLM 프롬프트로 끌어내는 동작 (유연하지만 퍼지함)
- 기존 레거시 시스템 트렌드: 1.0 → 3.0 (코드가 프롬프트로 대체됨)
Phaidra의 역전된 경험:
- AI 네이티브 시스템은 3.0에서 시작해서 1.0으로 성숙한다
- 프로토타입: 모든 것을 컨텍스트 윈도우에 던져서 무엇이 가치 있는지 빠르게 파악
- 프로덕션화: 결정론적으로 처리 가능한 부분을 코드(1.0)로 이동
- LLM에게는 어려운 판단(Hard Judgment)만 남김
LLM이 잘 하는 것 vs. 코드가 해야 하는 것
LLM에게 맡겨야 할 것:
- 모호한 요청 파싱 및 의도 파악
- 어디서 어떤 데이터를 찾아야 할지 판단
- 처음 보는 표현 방식 처리
- 최종 사람이 읽을 수 있는 답변 합성
코드(1.0)가 해야 할 것:
- 구조화된 데이터 탐색 (계층, 그래프, 스키마)
- 정확한 집합 연산 (검색, 교차, 합집합)
- 카운팅, 유사 이름 중복 제거
- 100% 재현 가능해야 하는 모든 것
판단 기준: 구조나 규칙을 코드로 작성할 수 있으면 → 1.0 작업이다
경고: 순수 LLM은 시스템이 크고 잘 구조화되어 있을 때 가장 약하다. 정확히 우리가 운영하는 환경이다.
실행 포인트
- 프로토타입은 3.0으로 빠르게: 무엇이 가능한지 탐색하는 단계에서는 LLM에 모든 것을 던져라
- 스케일 전에 계층 구조를 찾아라: 데이터에 트리/계층/그래프가 있으면 LLM으로 스캔하지 마라
- LLM에게 검색이 아닌 계획을 요청하라: "이름 목록에서 찾아라"가 아니라 "어떻게 찾을지 구조화 출력을 만들어라"
- 결정론적 리졸버를 LLM 앞에 배치하라: LLM → 계획 → 코드 → 실행 → LLM → 최종 답변
- 비용 곡선을 인스턴스 수가 아닌 트리 깊이에 연동시켜라: 1.0 함수 하나 추가 = LLM이 설 수 있는 더 단단한 기반 추가
핵심 요약 (20줄)
- Phaidra는 1GW 규모 AI 팩토리(40만+ GPU)에서 자연어 질의 에이전트를 구축하며 "Semantic Blindness" 문제를 발견했다.
- 50만 개 이상의 센서/장비 이름을 LLM에게 직접 제공하면 컨텍스트 포화, 환각, 누락이 동시에 발생한다.
- RAG는 "Chiller 6" vs "Chiller 7" 같은 유사 이름을 구분 못해 실패하고, 순수 LLM은 유사 토큰 반복으로 내부 가드레일이 차단한다.
- 핵심 통찰: AI 팩토리는 계층 트리 구조이며, 트리 깊이는 매우 천천히 늘어난다 — 인스턴스 수가 아닌 트리 깊이로 시스템을 설계해야 한다.
- 첫 번째 해결책: Linearizer — 수백만 노드 그래프를 "루트→리프 경로 요약"으로 압축, 64 GPU와 46만 GPU 시스템이 동일한 크기의 요약 생성.
- 두 번째 해결책: LLM은 검색이 아닌 계획에 쓴다 — "데이터홀 11의 과열 GPU"를 구조화 출력(collect: GPU, scope: DH11, filter: hot)으로 변환.
- 세 번째 해결책: 결정론적 리졸버가 LLM의 검색 계획을 받아 사전 인덱싱 서브트리와 집합 연산으로 100% 재현율 달성.
- 네 번째 해결책: 모호한 쿼리는 이름 전체 대신 검색 패턴을 LLM이 생성 → 백엔드에서 실행, LLM 토큰 비용 일정 유지.
- 성능: 구 시스템은 64 GPU에서 80%, 46만 GPU에서 30% 정확도 — 신 시스템은 규모 무관 100% 정확도 달성.
- 토큰 효율: 1GW 검증 패스 기준 구 시스템 1억 1,600만 토큰 vs 신 시스템 39만 토큰 (약 300배 절감).
- 비용 곡선: 구 시스템은 규모에 따라 선형 증가, 신 시스템은 9,000 토큰/쿼리 고정 — 완전한 플랫 비용 구조.
- 6개 실제 생산 시스템, 66개 테스트 케이스에서 실패 0건 확인.
- 핵심 교훈: Karpathy의 "1.0→3.0" 트렌드가 AI 네이티브 시스템에서는 역전된다 — 3.0 프로토타입에서 시작해 1.0으로 성숙한다.
- LLM에게는 모호함 파싱, 의도 파악, 최종 답변 합성만 맡겨라 — 나머지는 코드로 처리하라.
- 판단 기준: 구조나 규칙을 코드로 표현할 수 있으면 코드(1.0) 작업이다 — LLM이 구조화 데이터를 토큰 하나하나 스캔하게 만들지 마라.
- LLM은 시스템이 크고 잘 구조화될수록 오히려 더 약해진다 — 정확히 이 약점을 인식하고 설계에 반영해야 한다.
- 1.0 함수 하나 추가 = LLM이 설 수 있는 더 단단한 기반 하나 추가 — "1.1.0 도구"라고 명명.
- 최종 파이프라인: 사용자 쿼리 → 플래너 LLM(계획) → 결정론적 리졸버(집합 연산) → 결과 집합 — 2~3단계로 완결.
- 데이터에 계층/그래프/스키마 구조가 있다면 LLM 스캔이 아닌 인덱싱과 집합 연산으로 처리하라.
- AI 에이전트 설계의 원칙: "LLM이 추측하면 안 되는 모든 것을 코드로 이동하고, 그 구조를 다시 LLM에게 돌려줘라."