사내 LLM·AI 인프라 구축 기술 스택 안내

기술 스택2026년 7월 29일 16분 읽기ai-infrastructuredocsgpu-serverllm-infrastructurepublic-doc

사내 LLM·AI 인프라 구축 기술 스택 안내

문서 개요

사내 LLM 인프라는 GPU 서버 한 대에 모델을 설치하는 작업만을 의미하지 않습니다. 사용자 인증, 모델 실행, 사내 문서 검색, 업무 시스템 연동, 사용량 제한, 로그와 품질 평가를 하나의 서비스로 구성해야 합니다.

직원
  ↓ 조직 계정과 권한
사내 AI 포털 · API
  ↓
AI Gateway · 안전 정책
  ├─ LLM 추론 서버
  ├─ 사내 문서 검색
  └─ 승인된 업무 도구
          ↓
  파일 · DB · 업무 시스템

장비는 목표가 아니라 업무 기능을 실행하기 위한 수단입니다. 먼저 사용 사례와 품질 목표를 검증하고, 필요한 모델·동시 사용자·처리량을 측정한 뒤 GPU와 서버를 선택합니다.

먼저 정해야 하는 사용 사례

대표적인 사내 LLM 활용은 다음과 같습니다.

사내 규정·제품·업무 문서 질의응답
회의록, 보고서와 이메일 요약
문서 분류와 구조화된 정보 추출
개발·운영 지식 검색
고객 문의 초안과 상담 내용 요약
승인된 업무 시스템 조회와 작업 요청
번역과 문서 작성 보조

각 사용 사례에 대해 다음 항목을 정의합니다.

사용할 사용자와 부서
연결할 데이터와 접근 권한
필요한 정확도와 응답 시간
동시 사용자와 일일 요청량
외부 모델 API 사용 가능 여부
사람이 확인해야 하는 결과
저장할 대화·로그와 보관 기간
오류나 잘못된 답변이 업무에 미치는 영향

“사내에서 AI를 사용한다”는 목표만으로 장비를 정하지 않습니다. 하나의 구체적인 업무 흐름을 작은 범위에서 검증한 뒤 확장합니다.

구축 방식 비교

외부 모델 API 중심

사내 사용자 → 사내 AI 서비스 → 외부 모델 API
                       └→ 사내 문서 검색·권한 검증

GPU 장비 없이 빠르게 검증할 수 있음
모델 운영과 확장 부담이 적음
사용량과 데이터 전송 정책을 관리해야 함
공급자의 데이터 처리·보관 조건을 확인해야 함

사내 GPU 서버 중심

사내 사용자 → AI Gateway → 사내 LLM 추론 서버
                         └→ 사내 문서·업무 시스템

모델과 처리 데이터를 조직이 관리하는 환경에 둘 수 있음
특수 모델과 네트워크 정책을 직접 통제할 수 있음
장비, 전력, 냉각, 드라이버, 모델과 장애 대응 책임이 생김
사용량이 낮으면 고가 장비의 활용률이 낮아질 수 있음

하이브리드

                   ┌→ 사내 모델
사용자 → AI Router ┤
                   └→ 허용된 외부 모델 API

민감도, 기능, 비용과 처리량에 따라 요청을 사내 모델과 외부 모델로 나눕니다. 데이터 분류와 라우팅 기준이 명확해야 하며, 사용자가 임의로 정책을 우회할 수 없게 합니다.

권장 전체 구조

웹 포털 · 업무 시스템 · 개발 도구
               ↓
        인증 · API Gateway
               ↓
    AI 오케스트레이션 · 정책 계층
       ├─ LLM 추론 Runtime
       ├─ Embedding Runtime
       ├─ RAG 검색
       ├─ 업무 도구 호출
       └─ 비동기 작업 Queue
               ↓
PostgreSQL · Vector 검색 · Object Storage · NAS
               ↓
       로그 · 평가 · GPU 모니터링

사용자 애플리케이션이 GPU 서버를 직접 호출하지 않게 하고, 인증·요청 제한·감사·모델 선택을 담당하는 API 계층을 둡니다.

장비 도입 전에 측정할 항목

LLM 장비 용량은 모델 이름 하나로 결정할 수 없습니다.

모델의 매개변수 규모
가중치 정밀도와 양자화 방식
최대 입력·출력 길이
동시에 처리할 요청 수
첫 응답까지 허용되는 시간
초당 처리해야 하는 토큰 또는 요청
이미지·음성 등 멀티모달 처리 여부
한 GPU에 여러 모델을 올릴지 여부
단일 서버 장애를 허용할 수 있는지 여부
파인튜닝과 추론을 같은 장비에서 수행할지 여부

가중치가 GPU 메모리에 들어가더라도 긴 문맥과 많은 동시 요청은 추가 메모리를 사용합니다. 런타임, 캐시, 프레임워크 오버헤드도 있으므로 계산식만으로 구매하지 않고 실제 모델과 요청 패턴으로 벤치마크합니다.

GPU 서버 구성 요소

영역	확인할 기준	이유
GPU	GPU 메모리, 연산 성능, GPU 간 연결	모델 적재와 처리량
CPU	코어 수, 메모리 채널, PCIe 구성	전처리, 데이터 공급, GPU 보조
시스템 메모리	용량과 ECC 지원	모델 로딩, 캐시, 여러 프로세스
로컬 스토리지	NVMe 용량·처리량·내구성	모델 파일, 캐시, 컨테이너 이미지
네트워크	사용자·스토리지·노드 간 처리량	모델 이동, RAG 데이터, 분산 추론
전원	전원 용량, 이중 전원, UPS	고부하 안정성과 안전 종료
냉각	발열량, 흡·배기, 설치 공간	지속 부하에서 성능과 수명 유지
관리	원격 관리, 상태 센서, 펌웨어	장애 확인과 원격 복구

여러 GPU를 사용하면 GPU가 같은 서버에 있다는 사실만으로 최적 성능이 보장되지 않습니다. PCIe와 GPU 간 연결, CPU 소켓, NIC 배치와 런타임의 병렬화 방식을 함께 확인합니다.

단계별 장비 접근

1단계: 기능 검증

외부 모델 API 또는 기존 개발용 장비 사용
한두 개의 구체적인 업무 흐름 검증
데이터 반출 정책과 품질 평가 항목 정의
사용량과 예상 동시 요청 측정

이 단계에서는 GPU 구매보다 실제 업무 가치와 요구량을 확인하는 것이 우선입니다.

2단계: 소규모 사내 추론

단일 GPU 워크스테이션 또는 서버
하나의 주 모델과 제한된 사용자
로컬 NVMe 모델 캐시
사내 인증과 API Gateway
기본 GPU·응답 시간 모니터링
장비 장애 시 외부 API 또는 서비스 중단 정책

개발용 워크스테이션은 검증에 적합하지만 이중 전원, 원격 관리, 랙 설치와 부품 지원이 필요한 운영 환경에서는 서버형 장비를 별도로 검토합니다.

3단계: 부서 공용 서비스

하나 이상의 GPU를 갖춘 서버형 장비
모델 서비스와 RAG·업무 API 분리
사용자·부서별 요청 제한
별도 모델 저장소와 백업
대기열과 비동기 작업 처리
정기 벤치마크와 품질 평가
장애 알림과 버전 롤백

4단계: 여러 노드 확장

여러 GPU 서버와 공통 진입점
모델·요청 특성에 따른 라우팅
노드와 GPU 상태 기반 스케줄링
고속 스토리지와 노드 간 네트워크
장애 노드 제외와 용량 재배치
중앙 로그·모델 레지스트리·배포 자동화

여러 노드 구성은 단일 서버의 용량이 부족하다는 이유만으로 시작하지 않습니다. 여러 팀과 모델을 공통 플랫폼에서 운영해야 하고 전담 운영 역량이 있을 때 검토합니다.

권장 소프트웨어 스택

영역	선택 예시	역할
운영체제	지원되는 Linux 배포판	GPU 드라이버와 서비스 실행 기반
격리	Container Runtime	재현 가능한 모델 서비스 배포
GPU 연동	GPU Driver, Container Toolkit	컨테이너의 GPU 사용
모델 서빙	vLLM 또는 공급자 Runtime	LLM 추론 API 제공
API 계층	Reverse Proxy, API Gateway	인증, 라우팅, 요청 제한
인증	사내 SSO·OIDC	사용자와 서비스 계정 확인
업무 API	Python 또는 TypeScript 서비스	RAG, 정책, 도구 호출
관계형 DB	PostgreSQL	사용자, 권한, 대화, 평가 상태
벡터 검색	pgvector 또는 별도 Vector DB	문서 의미 검색
파일·모델 저장	Object Storage 또는 NAS	원문, 모델, 평가 데이터 저장
임시 상태	Redis	요청 제한, 캐시, 짧은 상태
작업 큐	Queue 또는 Message Broker	문서 처리와 비동기 작업 분리
관측	Metrics, Logs, GPU Telemetry	지연 시간, 오류, GPU 사용률 확인

제품은 예시이며 특정 런타임에 업무 규칙을 묶지 않습니다. 인증, 권한과 데이터 정책은 모델 서버 앞의 애플리케이션 계층에서 일관되게 적용합니다.

사내 문서 검색과 RAG

RAG는 질문과 관련된 사내 문서를 검색한 뒤 그 결과를 모델의 답변 근거로 제공하는 방식입니다.

문서 수집
  ↓
권한·형식 확인
  ↓
텍스트 추출·분할
  ↓
Embedding 생성
  ↓
Vector·Keyword 색인

사용자 질문
  ↓ 사용자 권한 적용
관련 문서 검색
  ↓
근거와 함께 답변 생성

RAG에서 가장 중요한 것은 벡터 검색 제품보다 문서 권한입니다.

사용자가 원문을 열람할 수 있는 문서만 검색합니다.
부서, 프로젝트와 보안 등급을 검색 필터에 반영합니다.
원문 변경·삭제 시 색인도 갱신합니다.
답변에 근거 문서와 위치를 표시합니다.
근거가 부족하면 추측하지 않고 확인 필요 상태로 처리합니다.
문서 안의 지시문이 시스템 권한을 바꾸지 못하게 합니다.

업무 시스템 도구 연결

LLM에 데이터베이스 관리자 권한이나 범용 실행 권한을 직접 부여하지 않습니다. 허용된 업무를 작은 도구 API로 제공하고 각 도구에서 권한·입력·상태를 검증합니다.

LLM의 도구 요청
    ↓
사용자 권한 확인
    ↓
입력값과 업무 규칙 검증
    ↓
승인된 API 실행
    ↓
결과와 감사 기록 저장

결제, 계약, 삭제, 개인정보 변경과 같은 중요한 작업은 사용자의 재확인이나 담당자 승인을 거칩니다. 재시도되더라도 작업이 중복 실행되지 않도록 고유한 작업 키와 상태를 관리합니다.

보안과 데이터 거버넌스

모델과 데이터의 출처·라이선스·이용 조건을 확인합니다.
사용자가 접근할 수 있는 모델과 문서를 역할별로 제한합니다.
시스템 지침, 사용자 입력과 검색 문서를 서로 다른 신뢰 수준으로 처리합니다.
프롬프트에 포함된 지시가 권한을 우회하지 못하도록 도구를 제한합니다.
모델이 생성한 도구 인수도 외부 입력처럼 검증합니다.
API 키와 인증정보를 프롬프트·모델 파일·로그에 포함하지 않습니다.
개인정보와 기밀정보의 입력·저장·외부 전송 정책을 정의합니다.
대화와 평가 데이터의 보관 기간과 삭제 절차를 정합니다.
모델 서버의 외부 통신 목적지를 제한합니다.
관리자 작업과 중요 도구 실행은 감사 가능한 기록을 남깁니다.

사내에서 모델을 실행한다는 사실만으로 데이터가 자동으로 안전해지는 것은 아닙니다. 계정, 네트워크, 로그, 백업과 운영자의 권한을 함께 관리해야 합니다.

품질 평가와 운영

서비스 도입 전 실제 업무 질문을 익명화해 평가 세트를 만듭니다.

정답 또는 기대 결과
검색해야 하는 근거 문서
답변하면 안 되는 권한 밖 질문
모르는 경우 거절해야 하는 질문
도구 실행 전 확인이 필요한 사례
긴 문서와 애매한 표현
입력 공격과 정책 우회 시도

운영 중에는 다음 지표를 관찰합니다.

첫 응답 시간과 전체 응답 시간
요청·토큰 처리량
GPU 메모리와 사용률
대기열 길이와 실패율
검색 성공률과 근거 표시율
사용자별·부서별 사용량
모델·프롬프트·색인 버전
도구 실행 성공·거절·승인 상태

모델을 바꿀 때는 같은 평가 세트로 품질, 성능과 자원 사용량을 비교하고 이전 버전으로 돌아갈 수 있게 합니다.

백업과 복구

GPU 장비 자체보다 다음 데이터의 복구 우선순위를 명확히 합니다.

문서 원문과 접근 권한
검색 색인을 다시 만들기 위한 원본과 처리 이력
프롬프트·정책·도구 정의
평가 데이터와 결과
사용자 설정과 감사 기록
모델 파일과 배포 설정

다운로드 가능한 공개 모델 파일은 다시 받을 수 있더라도, 내부에서 조정한 모델·어댑터·평가 결과와 정책은 별도 백업이 필요합니다. 검색 색인은 원문에서 다시 만들 수 있는지 절차를 확인합니다.

비용을 계산할 때 포함할 항목

사내 GPU 장비의 총비용에는 구매 가격 외의 항목이 포함됩니다.

GPU 서버, 스토리지와 네트워크 장비
전력, UPS와 냉각
랙 공간과 설치 공사
보증, 지원과 예비 부품
모델·소프트웨어 라이선스
운영과 장애 대응 인력
장비 활용률과 교체 주기
외부 모델 API를 함께 사용하는 비용
백업과 모니터링 저장 공간

장비를 항상 켜두더라도 사용자가 적으면 GPU 활용률은 낮을 수 있습니다. 예상 사용량이 불확실한 단계에서는 외부 API로 측정한 뒤 사내 장비와 총비용을 비교하는 방법이 합리적입니다.

장비 선정 체크리스트

검증한 모델과 Runtime이 해당 GPU를 지원하는가
필요한 모델·문맥·동시 요청이 GPU 메모리에 맞는가
실제 요청 패턴으로 처리량을 시험했는가
CPU·메모리·PCIe·NIC가 GPU를 방해하지 않는가
모델과 캐시를 위한 NVMe 용량이 충분한가
NAS·Object Storage와의 전송 속도가 충분한가
전원 용량, 콘센트, UPS와 냉각을 확인했는가
소음과 발열이 설치 공간에 적합한가
원격 관리, 부품 교체와 지원 방식이 있는가
장비 장애 시 서비스 정책과 대체 경로가 있는가
향후 GPU·스토리지·네트워크를 확장할 수 있는가

구축 순서

구체적인 업무 사용 사례를 하나 선택합니다.
데이터·권한·외부 전송 정책을 정합니다.
외부 API 또는 소규모 장비로 기능과 품질을 검증합니다.
모델, 문맥, 동시 요청과 지연 시간을 측정합니다.
클라우드·사내·하이브리드 총비용을 비교합니다.
벤치마크 결과를 기준으로 GPU·서버·스토리지를 선택합니다.
인증, Gateway, RAG 권한과 모니터링을 구성합니다.
평가·복구·버전 롤백을 시험한 뒤 사용자 범위를 확대합니다.

참고 문서

특정 GPU와 모델은 세대 교체가 빠르므로 공개 문서에는 산정 기준을 유지하고, 실제 제품명·수량·견적은 별도의 비공개 구매 문서에서 관리합니다.

시리즈 안내

이 문서는 사내 IT·AI 인프라 구축 가이드 3부작 중 3편입니다.