온프레미스 환경에 인프라 플랫폼을 배포하는 일은 단순히 설치 스크립트를 실행하는 과정이 아닙니다. 고객사마다 서로 다른 네트워크, 보안 정책, 하드웨어, 운영 절차에 맞추어 설치와 업그레이드를 일반화하고 일관된 사용자 경험을 제공할 수 있어야 합니다. 우리가 통제할 수 없는 고객 인프라에 플랫폼을 배포/운영하면서 마주한 문제와 경험에 대해 소개합니다.
복합 인프라 환경에서 AI·HPC 워크로드를 스케줄 및 관리 • 연계 솔루션: 파이프라인 저작 도구, LLM 라우터 및 관제 허브, 기타 연동 기능 및 애플리케이션 우리가 배포하는 곳 • 엔터프라이즈 데이터센터 • 연구 기관 및 대학 • GPU·NPU 이기종 클라우드 우리가 만드는 소프트웨어지만 고객의 인프라 위에서 동작
· 추론 · 에이전트 MLOps 애플리케이션 TokenOps FastTrack 3 학습 및 파인튜닝 GUI 파이프라인 Continuum Router / Hub 운영 플랫폼 코어 고객 인프라 AgentOps LLM 요청 라우팅 및 서빙 컨트롤 플레인 Backend.AI Suite 세션 · 스케줄링 · GPU 분할 · 쿼터 · 스토리지 연동 · 모니터링 가속기 드라이버 디바이스 파일 오버레이 네트워크 NIC 스토리지 마운트 파일 권한 SSO / LDAP 승인 워크플로우 GPU / NPU 인터커넥트 네트워크 고속 스토리지 계정 및 접근 제어
추론, 에이전트를 하나의 플랫폼에서 고객이 이미 서빙 중인 모델 앞단 라우팅·미터링 학습 및 파인튜닝용 파이프라인과 스케줄링 FastTrack 3 FastTrack 3 FastTrack 3 학습 및 파인튜닝 파이프라인 미배포 학습 및 파인튜닝 파이프라인 Continuum Router / Hub Continuum Router / Hub Continuum Router / Hub LLM 요청 라우팅 및 서빙 제어 LLM 요청 라우팅 및 서빙 제어 미배포 Backend.AI Suite Backend.AI Suite Backend.AI Suite 세션 · 스케줄링 · GPU 공유 · 모니터링 미배포 세션 · 스케줄링 · GPU 공유 · 모니터링 고객 인프라 고객 인프라 고객 인프라 GPU · 네트워크 · 스토리지 · IdP GPU · 네트워크 · 스토리지 · IdP GPU · 네트워크 · 스토리지 · IdP
고객 인프라 위에 설치되므로, 플랫폼에 대한 지식 외에 다음과 같은 다양한 계층에 대한 지식이 필요 • 인프라: 네트워크, 스토리지, GPU·NPU, 인터커넥트 Infiniband, RoCEv2 • 사이트 통합: 고객사 환경에서의 설치·운영, 고객사 프로세스와의 연동 SSO 등 • 애플리케이션 및 워크로드: 학습과 서빙, MLOps 도구 및 상황에 따른 활용 방안 • 모델: vLLM/SGLang 구동 및 최적화, LLM 라우팅, KV 캐시 티어링 • 기타 플랫폼을 넘어서는 일반적인 AI 질문 등
하기 어려우나, 자동화 가능한 일과 사람이 여전히 필요한 일로 구분할 수 있음 MAKE IT WORK · 자동화 가능 이론상 계획과 배포 운영과 지원 사이트 구성 · 설치 문제 해결 · 기본 문의 · 워크로드 실행 MAKE IT USEFUL · 사람이 여전히 필요 주로 고객과 함께 논의하고 만들어나가야 하는 일 AI 운영 방식 개선 · 프로세스 효율화 · 다음 단계 결정 반복되는 일 자동화 목표 판단과 소통 사람이 담당
할 작업. 크게 두 가지의 소스 • 고객과의 설계 논의: HA 구성 여부, 네트워크 스택 · L4/L7, 인터커넥트, 서브넷과 V irtual IP, 스토리지 등 • 수집 스크립트: 각 호스트에서 실행하여 설치에 필요한 세부 정보 자동 수집 • 하드웨어 일반 정보, OS, CPU/메모리/NUMA, 디스크와 마운트, GPU와 가속기, 커널, sysctl · limits • 네트워크 및 보안, 인터페이스, 사용 포트 및 방화벽 규칙, SELinux/AppArmor, 프록시, 아웃바운드 접속 허용 여부 등 • 주요 관련 OS 패키지 설치 여부, Docker/containerd 버전 및 런타임 설정, 시간 동기화, 설치에 필요한 권한 부여 여부 • 기존 Backend.AI 설치 · 구성 현황, 라이선스 현황, 인증서 현황 등 주로 기존 고객사 업그레이드시 필요
입력으로 변환 두 가지 산출물: 호스트 및 역할을 정의하는 인벤토리 inventory.py 및 환경 설정 파일 .env 패키지 수집 OS용 오프라인 번들 사이트 정보 현장에서 수집 inventory.py 고객 사이트 배포 토폴로지 반입, 설치 Pyinfra 배포 스크립트 .env 초기 계정, 시크릿
• 사전에 노트북 사용 확인 받았으니 당일에는 별도의 작업 PC만 연결 가능 • GUI 확인에 브라우저가 필요하지만 현장에는 서버 콘솔만 있거나 방화벽 정책이 열리지 않아 접속 불가 • 현장 휴대폰 반입 불가 극단적인 경우 명령어 잊어버리면 점심 때 나가서 검색 후 기억했다 오후에 실행 호스트와 스토리지 • 사전 설치 목록에 NVIDIA 드라이버, CUDA 런타임, 컨테이너 툴킷, Fabricmanager가 있었으나 막상 도착해서 보면 드라이버만 설치되어 있음 • 서버는 준비되었으나 사용자 데이터 저장을 위한 공유 스토리지가 연결 중 • Docker data root를 큰 용량의 보조 디스크로 옮겼으나 OS 디스크가 계속 가득 차는 현상 • containerd는 버전 29부터 별도의 경로 사용 • 네트워크 • 서버간 VRRP가 차단되어 keepalived 기반 HA 구성 계획 실패
사이트 구성과 배포 스크립트를 터미널 화면에서 비교적 쉽게 확인. 적어도 어떤 순서로 설치하면 되는지 기억에 의존하지 않고 따라가기 편함. 구성 검토 노드, 서비스 배치, 버전, 배포 대상 실행 전 점검 구성 일관성과 사전 점검 실행과 모니터링 단계별로 배포를 실행하고 상태와 출력 을 확인
환경을 파악하고 Pyinfra 스크립트를 활용하여 설치 진행 사이트 컨텍스트 맥락 설치 스킬 SITE.md 토폴로지와 제약, 아키텍처 참조 각 스킬이 실제 pyinfra 명령을 조립 · 실행 사전 점검 구성 검사 OS · Halfstack Manager · 서비스 서비스 검증 실행 환경: 모든 것이 격리 네트워크 내에서 동작 현재: 테스트 팜에 적용 중 Coding Agent CLI 번들 바이너리, 허용 목록 도구 로컬 LLM 엔드포인트 API 엔드포인트 로컬 vLLM 설치 지식은 모델이 아니라 하네스 페르소나, 스킬, 서브에이전트 에 있음 vLLM 컨테이너 Qwen3.8 27B FP8 번들에 포함된 이미지 29 GB 가중치, 80 GB GPU 1장
Backend.AI 26.7 · Qwen3.6 27B 2026년 7월 . 헤드리스 실행으로 설치 후 GPU 세션 기동까지 도달 측정 결과 실패 108분 F21 비대화형 셸의 PATH에 pyinfra 없음 허용 명령 목록 스킬이 venv 바이너리를 직접 호출 Pyinfra 설치 스크립트 실행과 읽기 전용 상태 점검 fact 확인 만 설치자 확인 없이 실행 GPU 노드 1 CPU 노드 1 전체 패키지 설치 모델 추론 대기 시간 오류 패턴 DB에 멈추고 질문 규칙 F29 cwd 초기화 루프, 같은 명령 18회 반복 모든 명령에 cd pyinfra 323 순차 명령 발견 번호 F23 GPU 할당 모드는 수정 대상이 아닌 사이 트 정책 추가 80 규칙으로 F 현재 병렬 웨이브로 배치 처리 강제 가드레일 실행 금지 목록 OS 업그레이드, 네트워크/방화벽 변경, 전체 노드 대상 명령 금지 사이트 정책은 운영자에게 GPU 할당 모드와 사이트 설정은 확인 없이 변 경하지 않음
없는 경우더라도, 사이트 밖에서 테스트 미러 팜을 만들고 에이전트를 활용. 에이전트는 사무실에서 사이트별 스크립트를 생성하고, 생성된 스크립트와 번들만 격리망 환경으로 반입. 방문 전 · 테스트 팜 현장 에이전트와 모델은 여기서 실행 에이전트 없음, 모델 없음 • 수집한 사이트 정보로 고객 구성을 미러링: 노드 수, OS, 네트워크 제약 등 • 미러 환경에서 Autopilot 반복 실행 및 조정. 사이트별 설치 스크립트와 설정 파일 생성 • 미러 설치가 통과할 때까지 검토, 수정, 재실행 스크립트 번들 • 오프라인 번들과 생성된 스크립트를 반입. TUI 설치 또는 스크립트 직접 실행 • 고객 네트워크 안에는 LLM, 모델 가중치, 에이전트가 없음 • 미러와 현장의 차이는 현장 점검에서 발견하고 엔지니어가 대응 한계 테스트 팜이 모든 하드웨어·네트워크 세부사항을 재현하지는 못함. 생성된 스크립트는 현장 작업을 줄여주는 목적.
배치, 라우팅, TLS Derive 방화벽 규칙과 다이어그램 1 연결 모드 선택 2 사이트 구성 검증 3 방화벽 요청서 생성 고가용성 DB 클러스터에 프록시 기반 연결 배치 규칙: 클러스터 멤버 배포 호스트, 포트 충돌 등 각 규칙에 출발지, 목적지, 포트와 근거가 되는 의존성을 기재 site-designer physical validate site-designer firewall generate -format justification site-designer dep resolve postgresql_node --mode ViaProxy 한 번 정의, 사이트마다 검증 • • • • 서비스 모델, 의존성, 포트는 한 번 정의. 배치, 연결 모드, 점검은 사이트별로 수행 설치 전: 실제 호스트 SSH 탐색, 설계 대비 포트·방화벽 점검 내보내기를 통해 pyinfra inventory.py와 .env를 생성. 사이트별 수작업 인벤토리 불필요 GUI 버전: 서버와 서비스 배치를 화면에서 고객과 함께 검토
사무실 현장 · 고객 1 수집 2 설계 3 패키징 4 점검 5 설치 고객 호스트에서 수집 스크립트 실행 설계 논의: HA 구성, 네트워 크, 스토리지 연결 등 Site Designer: 의존성, 배치 , 연결 모드 네트워크 팀에게 전달할 방화 벽 요청서 생성 pyinfra inventory.py, .env, 오프라인 번들 테스트 팜의 Autopilot이 만 든 사이트별 스크립트; 이후 Site Designer가 인벤토리 내보내기 실제 호스트 SSH 탐색 설계 대비 포트·방화벽 비교 TUI 설치기, 단계별, 콘솔만 으로 반복 단계는 허용 목록 아래 Autopilot 사용 중 개발 중 사용 중 개발 중 사용 중 · 테스트 중 사이트마다 달라지는 것과 달라지지 않는 것 • 1 5단계 자체는 모든 사이트에서 동일 배포 단계 표준 . 개별 사이트 정보와 실 사이트 점검이 사이트별로 다르게 적용 • 콘솔 전용 호스트, 격리망 환경, 설계 단계에서 수집한 정보와 다른 현장 상황: 4 5단계에서 사이트 엔지니어 역량으로 대응하고, 2 3단계로 빈도를 줄임
환경은 계속 변함 • 방화벽이 여러 가지 이유로 서비스 IP를 차단하기 시작 자동 탐지 규칙 • WebSocket 트래픽이 어느 날 갑자기 차단되어 앱 스트리밍이 실패함 • 만료된 SSL 인증서로 인해 서비스에서 브라우저 경고 발생 • NVIDIA 드라이버 업데이트 후 특저 사용자 코드 실행새 NCCL 오류 발생 • 실사용 시작: 사용자가 많아지면서 소규모 사용자 검증 단계에서는 드러나지 않던 문제와 질문이 나타남. 이 문제와 질문 또한 사이트별로 다를 수 있음 • 기본적인 세션, 스토리지, 이미지 사용법 질문. 초기 설정에 없던 쿼터, 스케줄링, 새로운 연동 요청 • 초기 티켓의 상당수는 사용법 질문이므로, 사용자·관리자 대상 초기 및 정기 교육 진행
수업 시간 12:30 16:30 에만 GPU 사용 가능. 강사는 항상 가능. 학생 12:30 이전 수업 시간 12:30 16:30 16:30 이후 새 세션 생성 불가 GPU 사용 가능 새 세션 생성 불가 강사 항상 GPU 사용 가능 커스텀 워크플로 이런 고객 요청은 코어 기능으로 해결하기 어려운 경우가 많음. Control Panel에서는 Backend.AI SDK/API 기반 워크플로를 작성하고 GUI에서 관리하는 기능을 제공. 스케줄, 활성화/비활성화, 드라이런, LLM 보조 스크립트 초안 작성 등. 이 워크플로는 1분마다 반복 실행되어 현재 시각에 따라 학생 키페어 정책을 전환.
속도를 높여줄까요? 어떻게 검증하나요? 일반 AI 기술에 관한 답변 플랫폼의 위치 다중 사용자 환경에서 긴 컨텍스트를 재사용할 때 첫 토큰까지의 프리필 시간이 줄어듦. 캐시 자체는 플랫폼 위에서 LMCache 같은 서드 파티 서빙 구성요소가 담당 효과는 워크로드에 따라 다름: 멀티턴 에이전트와 긴 컨텍스트 RAG 는 효과 있음. 짧은 단발 프롬프트는 거의 없음. 우리 역할은 라우팅: 해당 컨텍스트를 이미 보유한 워커로 요청을 전달하는 방식으로 간접적 연계 스토리지 RDMA 경로와 노드 NIC 대역폭을 확인한 뒤에만 테스트. 그 측정값이 상한선. 절대 성능 상한은 고객의 서빙 스택과 인프라 스펙 장애와 기능 요청 외에 생태계에 관련된 전반적인 질문도 들어옴.
지식의 저장소 저장소 담는 것 제품 수준, 모든 사이트에 유효 • 특정 설치에 의존하지 않는 Backend.AI 설치·운영 절차 • 설치·지원 업무를 하는 엔지니어가 작성하고 검토 • 고객용 문서로 재가공하여 전달 담지 않는 것 특정 사이트/설치 방식에 관련된 모든 것 • 호스트, 접근 경로, 고객별 제약: 이는 Giftbox 사이트 기록에 속함 • Giftbox 케이스에서 일반화 가능한 발견은 가이드로 승격
Giftbox에 들어오고, 각각 추적되는 케이스로 관리. 세 종류의 기록을 분리해, 다음 조사에서 현재 상태와 과거 케이스를 구분. 사이트 구성 조사 기록 재사용 가능한 절차 현재 사실인 것 무슨 일이, 언제 있었는가 어디서든 해야 할 일 • 호스트, 서비스, 접근 경로: Part 1의 수집 스 크립트에서 확보 지속 업데이트 • 케이스 보고서: 관찰, 근거, 조치 • 사이트 공통 점검 항목 • 검증된 결과와 미해결 질문 • 사전 요건과 검증 단계 • 운영 제약: 고객과의 지속적인 소통에서 사이트 컨텍스트 로드 조사 각 지원 케이스마다 해당 기록 갱신
엔지니어와 에이전트는 같은 파일을 읽음. 파일 구조 생성된 사이트 뷰 설치당 디렉터리 하나 같은 파일에서 렌더링 sites/<installation>/ supports.yaml 호스트, 서비스, 접근 dossier.md 사이트별 컨텍스트 cases/ YYYY-MM-DD-issue.md • 사이트당 한 페이지: supports.yaml의 호스트·서비스 인벤토리, 도시에, cases/*.md 메타데이터의 케이스 목록 make view • 엔지니어는 생성된 페이지를 열람하고, 에이전트는 원본 파일을 읽음 케이스 근거, 조치, 결과 케이스가 끝나면 에이전트가 발견 사항을 분류하고 파일을 로컬에서 수정해 PR을 작성. 엔지니어가 검토하고 병합. 케이스 기록 에이전트가 분류, PR 생성 사이트 dossier 이 설치에서 계속 유효한 사실 dossier.md 내부 런북 runbook 사이트 간 재사용되는 조사·운영 절차 runbooks/ Enterprise Guide 제품 수준 지식, 고객 문서로 공개
에이전트 작업으로 구분할 수 있음. 현재는 첫 단계만 일상적 활용 중 Level 1 · 쌓아둔 지식만 활용 Level 2 · 읽기 전용 접근 Level 3 · 전체 운영 에이전트가 하는 일 Giftbox에 이미 있는 내용으로 답변: 케이 스 이력, 사이트 기록, 플랫폼 운영 노트, Enterprise Guide 참조 저장된 접근 정보로 사이트에 접속. 점검만 하고 변경하지 않음 고객 시스템에서 복구 작업을 포함한 자율적 운영 상태 현재 사용 중 제한된 사례에서 테스트 중 내부 팜 아직 계획 없음 에이전트가 읽는 것은 Giftbox 저장소 내의 문서가 전부. 읽기 전용은 도구별 DB 사용자, API 토큰 로는 강제 가능하지만 셸에서의 읽기 전용 강제는 어려움. 명령 허용/거절 목록은 우회가 쉽고, 운영 서버는 샌드박싱이 어려움. 같은 장애 요인에 더 큰 위험 이유
엔지니어 · 고객 시스템 에이전트 · Giftbox 기록만 1 문의 2 사이트 컨텍스트 3 근거 4 검토, 조치 5 검증, 기록 질문, 장애, 워크로드 요청 메일, 채팅, 전화로 접수; 엔지 니어가 입력 에이전트가 Giftbox 로드: 사 이트 구성, 케이스 이력, 절차 사이트당 디렉토리 하나, 버 전 관리 에이전트가 케이스 분류, 근 거 수집, 기록 PR 초안 작성 고객 시스템: 읽기 전용 접근 강제 아직 불가 엔지니어가 발견 사항 확인, 고객과 조율 Site Designer · Pyinfra로 변경 적용 결과 보고, 후속 조치 추적 엔지니어가 PR 병합. 케이스 가 새로운 사이트 컨텍스트가 됨 현재 수동 접수 사용 중 사용 중 · Level 1 엔지니어 수행 사용 중 • 에이전트는 읽고 정리. 사이트 기록, 케이스 이력, 근거. • 고객 시스템에 닿는 모든 작업은 읽기 전용 접근을 강제할 수 있을 때까지 엔지니어가 결정하고 실행.
및 기록 갱신까지 Part 1 · 배포 방문 전 · 사무실 현장 · 고객 1 수집 사용 중 2 설계 개발 중 3 패키징 사용 중 4 점검 개발 중 5 설치 사용 중 · 테스트 중 사이트 기록 Giftbox: 같은 사이트 정보가 계획에서 지원까지 이어짐 에이전트 · Giftbox 기록만 엔지니어 · 고객 시스템 Part 2 · 지원 고객 1 문의 현재 수동 접수 2 사이트 컨텍스트 사용 중 사용 중 · 테스트 중 · 개발 중 / 수동, 엔지니어 수행 3 근거 사용 중 · Level 1 4 검토, 조치 엔지니어 수행 5 검증, 기록 사용 중
lablup
reverentgeek
techseoconnect
akademiya2063
jonoalderson
popppiees
destraynor
tammyeverts
elsirapls
sarafernandez
brad_frost
jonyablonski
gurzu
