treeru.com
하드웨어

사무실에서 시작하는 AI 서버 인프라 — 16대 서버 실전 구성기

2026-02-22
Treeru

클라우드 없이, 사무실에서 AI 인프라를 만들었습니다. AI 전용 GPU 서버를 중심으로 리버스 프록시, 프로젝트 서버, 백업 서버까지 총 16대를 역할별로 분리하고 SSH 키 기반 메시 네트워크로 연결했습니다. 네트워크 대역폭 실측, 보안 설정, CPU 안정화까지 — 온프레미스 AI 인프라의 실전 구성 과정을 공유합니다.

16대

서버 수

17개

SSH 키 교차 등록

2.5Gbps

최대 내부 대역폭

0건

보안 사고

서버 역할 분리

16대 서버를 5가지 역할 그룹으로 분리했습니다. 각 그룹은 독립적으로 운영되며, 장애가 다른 그룹에 전파되지 않도록 설계했습니다.

AI 두뇌 서버 (1대)

모든 AI 추론의 핵심. GPU, 대용량 메모리, 3-Tier 스토리지를 갖춘 메인 서버.

  • • CPU: AMD Ryzen 9950X3D
  • • RAM: 96GB DDR5
  • • GPU: NVIDIA RTX PRO 6000 (96GB VRAM)
  • • 스토리지: Optane 905P + 980 PRO + NVMe 3-Tier

AI 보조 서버 (1대)

FAQ, 단순 질문을 처리하는 경량 AI 서버. 크로스서버 추론으로 메인 서버의 처리량을 70% 증가.

  • • CPU: AMD Ryzen 7500F
  • • RAM: 16GB DDR5
  • • GPU: RTX 5060 Ti (16GB VRAM)
  • • 스토리지: NVMe 1TB

리버스 프록시 (1대)

모든 외부 트래픽의 진입점. SSL 종료, 도메인 라우팅, 로드밸런싱을 담당.

  • • CPU: Intel N100
  • • RAM: 12GB
  • • 역할: Caddy/Nginx 리버스 프록시
  • • 스토리지: NVMe 512GB

프로젝트 서버 (7대)

웹 서비스, API, 데이터베이스 등 개별 프로젝트를 운영하는 서버 그룹.

  • • CPU: Ryzen 5700G / 5800U / 5825U / 7840HS
  • • RAM: 32~64GB
  • • 총 7대, 프로젝트별 1:1 할당
  • • 서버 간 독립 운영

경량 서버 (5대)

모니터링, 로그 수집, 경량 API 등 보조 역할을 담당하는 미니 서버.

  • • CPU: Intel H255
  • • RAM: 16GB
  • • 총 5대 (일부 SSD 512GB~1TB)
  • • 저전력·저소음 운영

콜드백업 (1대)

NFS 기반 네트워크 스토리지. 전 서버의 중요 데이터를 정기 백업. 구축 과정은 NFS 콜드백업 서버 글을 참고하세요.

  • • CPU: AMD 5825U
  • • RAM: 32GB
  • • 스토리지: IronWolf 12TB × 2 (SATA)
  • • NIC 2개 (이중화)

역할 분리의 원칙

장애 격리

프로젝트 서버 장애가 AI 서버에 영향을 주지 않음. 역방향도 동일.

리소스 독립

AI 추론의 VRAM/GPU 사용이 웹 서비스의 CPU/메모리와 경쟁하지 않음.

수평 확장

프로젝트 서버는 1대 추가로 새 서비스 배포 가능. AI 서버는 보조 GPU로 확장.

네트워크 대역폭 계층

모든 서버는 동일 서브넷(10.0.10.0/24)에 연결되어 있지만, NIC 성능에 따라 2가지 대역폭 계층으로 나뉩니다. iperf3 양방향 동시 측정(--bidir) 결과입니다. 케이블·포트 점검을 통해 100Mbps 구간을 완전히 제거하고, 전 서버를 1Gbps 이상으로 통일했습니다.

Tier 1: 2.5Gbps 연결 (5대)

서버 역할CPUNIC 링크실측 송신실측 수신
프로젝트 서버 A5700G2,500 Mb/s2.35 Gbps2.18 Gbps
웹 서버7840HS2,500 Mb/s2.33 Gbps2.34 Gbps
프로젝트 서버 B5800U2,500 Mb/s2.32 Gbps2.33 Gbps
경량 서버 DH2552,500 Mb/s2.34 Gbps2.25 Gbps
AI 보조 서버7500F2,500 Mb/s2.31 Gbps2.24 Gbps

AI 서버(10Gbps NIC)와 2.5Gbps NIC 간 연결. AI 보조 서버는 케이블/포트 교체로 100Mbps → 2.5Gbps 승격 (24배 개선).

Tier 2: 1Gbps 연결 (10대)

서버 역할CPU실측 송신실측 수신
경량 서버 AH255923 Mbps860 Mbps
프로젝트 서버 C5825U922 Mbps883 Mbps
프로젝트 서버 D5825U921 Mbps925 Mbps
프로젝트 서버 E5825U921 Mbps919 Mbps
경량 서버 BH255921 Mbps934 Mbps
프록시 서버N100921 Mbps938 Mbps
프로젝트 서버 F5825U921 Mbps861 Mbps
경량 서버 CH255920 Mbps910 Mbps
프로젝트 서버 G5825U920 Mbps924 Mbps
백업 서버5825U920 Mbps838 Mbps

전 서버 920Mbps 이상 송신 달성. 이전 측정 대비 저속 서버(456~731Mbps)가 모두 정상 1Gbps로 복구됨.

네트워크 최적화 이력

초기 측정(2/21) 후 케이블·포트 교체를 진행하여 100Mbps 계층을 완전히 제거했습니다.

서버이전 (2/21)현재 (2/26)조치
AI 보조 서버95 Mbps2.31 Gbps케이블/포트 교체 → 2.5Gbps 승격 (24배)
프로젝트 서버 D456 Mbps921 Mbps1Gbps 정상 도달 (2배)
프로젝트 서버 C610 Mbps922 Mbps정상화 (51% 개선)
프로젝트 서버 E731 Mbps921 Mbps정상화 (26% 개선)

대역폭 계층 요약

2.5Gbps (5대)

AI 서버 ↔ 주요 서버. 대용량 파일 전송, 모델 배포, 크로스서버 추론에 활용. AI 보조 서버 승격으로 추론 오버헤드 대폭 감소.

1Gbps (10대)

전 서버 920Mbps 이상 실측. API 호출, 로그 수집에 충분한 대역폭. 100Mbps 계층 완전 제거 완료.

SSH 메시 보안

16대 서버 전체에 17개 SSH 공개키를 교차 등록하여 모든 서버 간 양방향 키 인증이 가능합니다. 비밀번호 인증은 전면 비활성화했습니다.

SSH 키 인증 구조

등록된 SSH 키 (17개)

  • • 외부 작업환경 키 × 1 — 모든 서버 접속용
  • • AI 두뇌 서버 키 × 1
  • • 프록시 서버 키 × 1
  • • 웹 서버 키 × 1
  • • 프로젝트/경량 서버 키 × 12
  • • 백업 서버 키 × 1

키 타입 및 방식

  • • 알고리즘: Ed25519 (최신 표준)
  • • 배포: 모든 서버의 authorized_keys에 17개 전부 등록
  • • 접속: 어떤 서버에서든 다른 서버로 즉시 SSH 가능
  • • 관리: 서버 추가 시 새 키 생성 → 전체 서버에 배포
보안 항목내부 16대외부 백업설명
PasswordAuthOFFON비밀번호 로그인 차단 (키 인증만 허용)
PermitRootLoginOFF기본값root 직접 로그인 차단
MaxAuthTries3회6회인증 시도 제한으로 무차별 공격 방어
sudo NOPASSWD적용적용운영 자동화를 위한 sudo 패스워드 면제
DenyUsers적용외부 서버 IP 차단 (격리 정책)

왜 메시 구조인가?

전통적인 점프호스트(bastion) 구조 대신 메시를 선택한 이유: 모든 서버가 배포, 모니터링, 백업을 위해 상호 통신해야 합니다. 점프호스트는 단일 장애점(SPOF)이 되고, 서버 간 직접 통신이 불가합니다. 메시 구조에서는 17개 키를 전체 서버에 배포하면 어떤 서버에서든 다른 서버로 즉시 접근 가능하며, 비밀번호 인증 OFF + MaxAuthTries 3으로 보안을 유지합니다.

외부 서버 격리

외부 네트워크에 위치한 백업 서버는 내부 접근이 완전 차단됩니다. 내부 → 외부는 가능하지만, 외부 → 내부는 네트워크 + SSH 이중 차단입니다.

격리 메커니즘 (이중 차단)

차단 계층방법효과
1. 네트워크WireGuard VPN에서 내부 대역(10.0.10.0/24) 라우팅 제거외부 서버 → 내부 서버 ping/SSH 불가
2. SSH내부 16대 전체에 DenyUsers 설정VPN 우회 시에도 SSH 접속 거부

허용되는 방향

  • 내부 서버 → 외부 백업 서버 (SSH 접속)
  • 내부 서버 → 외부 백업 서버 (파일 전송, 백업)

차단되는 방향

  • 외부 백업 서버 → 내부 네트워크 (ping 불가)
  • 외부 백업 서버 → 내부 서버 (SSH 거부)

왜 이중 차단인가?

네트워크 차단만으로는 VPN 설정 변경 시 우회 가능합니다. SSH 레벨에서도 차단하면 설령 네트워크가 뚫려도 인증 단계에서 거부됩니다. 외부 서버가 탈취되더라도 내부 인프라에 접근할 수 없는 구조입니다.

CPU 부스트 제어

서버를 24시간 운영할 때 가장 큰 적은 열(heat)입니다. CPU 터보 부스트를 비활성화하면 순간 최대 클럭이 제한되지만, 온도와 전력이 안정되어 장기 운영 신뢰성이 올라갑니다.

부스트 비활성화 적용 현황

서버 그룹CPU적용 여부사유
AI 두뇌 서버9950X3D미적용최대 AI 추론 성능 유지 필요
AI 보조 서버7500F미적용보조 추론 성능 유지
프록시 서버N100 (Intel)적용리버스프록시는 CPU 성능 불필요
웹 서버7840HS적용웹 서빙에 부스트 불필요
프로젝트 서버 (5대)5825U × 5적용장기 운영 안정성 우선
백업 서버5825U적용NFS 서빙에 부스트 불필요
경량 서버 (4대)H255 × 4미적용저전력 CPU — 부스트 영향 미미

AMD (amd-pstate-epp)

# systemd 서비스로 부팅 시 자동 적용
[Service]
ExecStart=/bin/bash -c \
  'echo 0 > /sys/.../boost'
ExecStop=/bin/bash -c \
  'echo 1 > /sys/.../boost'
RemainAfterExit=yes

boost 파일에 0을 쓰면 터보 부스트 비활성화. 서비스 중지 시 자동 복구.

Intel (intel_pstate)

# Intel은 값이 반대 (1=끔, 0=켬)
[Service]
ExecStart=/bin/bash -c \
  'echo 1 > /sys/.../no_turbo'
ExecStop=/bin/bash -c \
  'echo 0 > /sys/.../no_turbo'
RemainAfterExit=yes

intel_pstate의 no_turbo 파일에 1을 쓰면 비활성화. AMD와 경로·값이 반대.

부스트 제어 핵심 포인트

power-profiles-daemon 주의

이 데몬이 부팅 시 부스트를 다시 켤 수 있습니다. After= 설정으로 순서를 보장해야 합니다.

AI 서버는 미적용

AI 추론은 CPU 클럭 영향을 받습니다. 대신 GPU 전력 제한으로 온도를 관리합니다.

일시 복구 가능

systemctl stop으로 언제든 부스트 복구 가능. 임시 고성능 작업 시 유연하게 전환.

결론: 운영 원칙 정리

사무실 온프레미스 AI 인프라 운영에서 지키고 있는 5가지 원칙입니다.

1

역할별 서버 분리

AI, 프록시, 프로젝트, 백업을 물리적으로 분리합니다. 한 서버의 장애가 다른 역할에 전파되지 않습니다.

2

키 인증 Only, 비밀번호 OFF

17개 SSH 키를 교차 등록하고 비밀번호 인증을 비활성화합니다. 무차별 공격을 원천 차단합니다.

3

외부 서버 이중 격리

네트워크(VPN) + SSH(DenyUsers)로 이중 차단합니다. 외부 서버 탈취 시에도 내부 접근 불가.

4

CPU 안정화로 장기 운영

AI 서버 외에는 터보 부스트를 OFF합니다. 24/7 운영 시 온도·전력 안정성이 곧 신뢰성입니다.

5

대역폭 파악 후 배치

iperf3로 실측한 뒤 대역폭이 높은 연결에 핵심 서비스를 배치합니다. 추측이 아닌 데이터 기반.

인프라 전체 요약

항목현황
서버 수16대 (내부) + 1대 (외부 백업)
네트워크10.0.10.0/24, 2.5Gbps 5대 + 1Gbps 10대 (전 서버 1G 이상)
SSH 보안17개 키 메시, 비밀번호 OFF, MaxAuthTries 3
외부 격리WireGuard + DenyUsers 이중 차단
CPU 부스트 제어8대 적용 (프로젝트/프록시/백업)
AI GPURTX PRO 6000 + RTX 5060 Ti (크로스서버)
백업IronWolf 12TB × 2, NFS 네트워크 스토리지

클라우드 없이 사무실에서 AI 인프라를 운영하는 것은 충분히 가능합니다. 중요한 것은 서버 수가 아니라 역할 분리, 보안, 안정성의 원칙입니다. 서버가 늘어나면 Grafana + Prometheus 통합 모니터링 도 함께 구축해 실시간 상태를 파악하는 것을 권합니다. 이 원칙 위에서 크로스서버 추론, 동시 접속 부하 테스트, GPU 전력 최적화가 의미를 가집니다.

T

Treeru

웹 개발, IT 인프라, AI 솔루션 분야의 실무 인사이트를 공유합니다. 기업의 디지털 전환을 돕는 IT 파트너, Treeru입니다.

공유

댓글

(4개)
4.85/ 5

로그인하면 댓글을 작성할 수 있습니다.

2026-02-22
555.0

사무실 온프레미스 AI 인프라를 이렇게 체계적으로 정리한 글은 처음 봅니다. SSH 메시 보안 부분이 특히 실무에 도움됩니다.

2026-02-22
4.954.9

클라우드 비용 때문에 온프레미스를 고민 중이었는데, 16대 서버를 역할별로 나누는 전략이 현실적이네요. CPU 부스트 제어는 몰랐던 포인트입니다.

2026-02-22
4.854.8

iperf3로 실제 대역폭을 측정하고 계층화한 부분이 좋습니다. 케이블/포트 교체로 100Mbps를 완전히 없애고 전 서버 1Gbps 이상으로 통일한 점이 인상적입니다.

관련 글

© 2026 TreeRU. All rights reserved.

본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.