LLM 에이전트 확장의 함정 '의미 맹점'과 계층 트리로 푼 데이터센터 AI 설계

핵심 메시지

• 데모에서 잘 되던 LLM 방식이 수십만 개 장비 규모에서는 문맥창 포화·환각·낮은 재현율로 무너진다.
• 장비 이름은 한 글자 차이로 비슷해 벡터 검색(RAG)도 실패하고, 비슷한 토큰 반복은 LLM 내부 페널티에 걸려 출력이 끊긴다.
• 핵심은 '장비 개수'가 아니라 '트리 깊이'에 맞춰 확장하는 것 — 데이터센터의 계층 구조를 요약해 문맥을 일정하게 유지한다.
• LLM은 계획(무엇을 어디서 찾을지)에만 쓰고, 실제 검색·집합 연산·중복 제거는 결정론적 코드가 맡는다.
• 그 결과 64개~46만 개 GPU 규모에서 정확도 100%, 쿼리당 토큰은 약 9,000개로 거의 일정하게 유지됐다.

쉽게 이해하기

Phaidra의 라훌 싱과 반츠 레브스틱은 AI 데이터센터('AI 팩토리') 운영자가 자연어로 설비 상태를 묻는 AI 에이전트를 만든다. 사용자는 '어느 냉동기가 과열됐나', '데이터홀 전체 온도 분포를 분석해줘' 같은 질문을 던지는데, 업계에 표준 장비 명명 규칙이 없어 고객마다 이름 체계가 제각각이다.

작은 데모에서는 모든 장비 이름을 LLM에 그대로 보여줘도 동작한다. 그러나 1기가와트급 팩토리는 GPU만 40만 개가 넘고, 이를 뒷받침하는 전력계·냉동기까지 더하면 문맥창이 순식간에 포화된다. 발표자들은 '제품은 모든 상황에서 동작하고 조용히 실패하지 않는 것, 데모는 한 번만 되면 되는 것'이라고 구분했다.

대안으로 이름을 벡터로 임베딩해 검색하는 방식도 있지만, 'Chiller 6'과 'Chiller 7'처럼 한 글자만 다른 이름들은 의미 검색이 잘 구분하지 못한다. 또 비슷한 토큰을 계속 출력하면 LLM의 빈도 페널티와 가드레일이 '폭주'로 오인해 출력을 멈춘다. 이름을 여러 조각으로 나눠 병렬 호출하면 존재하지 않는 장비를 지어내거나(환각) 있는 장비를 조용히 누락해 신뢰를 잃는다.

이들이 찾은 통찰은 물리 인프라가 트리 구조라는 점이다. 데이터센터→데이터홀→열→랙→GPU처럼 깊이는 천천히 늘지만 폭은 매우 빠르게 늘어난다. 따라서 개별 장비 수가 아니라 트리 깊이에 맞춰, 즉 하위 선형(sub-linear)으로 확장하도록 설계해야 한다.

구현은 네 가지로 요약된다. ①경로를 요약해 문맥을 압축하는 '선형화기'(64개든 46만 개든 요약 크기가 비슷해진다), ②LLM은 검색이 아니라 '무엇을·어느 범위에서·어떤 필터로 모을지'를 구조화 출력으로 계획, ③미리 색인한 하위 트리에 집합 연산을 적용해 완벽한 재현율 확보, ④매우 모호한 질의는 이름 나열 대신 '패턴'을 만들게 해 백엔드에서 실행. 전체 흐름은 플래너 LLM → 결정론적 리졸버의 2~3단계로, 반복되는 에이전트 루프를 피해 비용을 일정하게 유지한다.

주요 인사이트

• 기존 방식은 GPU 64개에서 정확도 80%였지만 46만 개에서 30%로 급락한 반면, 새 방식은 실제 운영 6개 시스템의 66개 사례를 포함해 모든 테스트에서 정확도 100%, 실패 0건을 기록했다.
• 1기가와트 규모에서 기존 방식은 단일 검증에 1억 1,600만 토큰을 소모하고도 오류가 많았지만, 새 방식은 약 39만 토큰으로 약 300배 적었고 쿼리당 비용이 규모와 무관하게 약 9,000토큰으로 평평했다.
• 카르파티의 소프트웨어 1.0(결정론적 코드)과 3.0(LLM에서 프롬프트로 끌어내는 동작) 프레임을 빌려, '레거시 소프트웨어는 1.0에서 3.0으로 이동하지만 AI 네이티브 시스템은 3.0에서 시작해 검증된 부분을 1.0으로 성숙시킨다'는 역방향 흐름을 제시했다.
• 데이터에 구조(계층·그래프·스키마)가 있다면 LLM이 토큰 단위로 훑는 것은 잘못된 도구이며, 검색·집합 논리·계수·중복 제거처럼 100% 재현이 필요한 일은 결정론적 코드로 옮겨야 한다는 실무 기준을 강조했다.

자주 묻는 질문

관련 AI 소식