사무실에서 시작하는 AI 서버 인프라 — 16대 서버 실전 구성기
클라우드 없이, 사무실에서 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대)
| 서버 역할 | CPU | NIC 링크 | 실측 송신 | 실측 수신 |
|---|---|---|---|---|
| 프로젝트 서버 A | 5700G | 2,500 Mb/s | 2.35 Gbps | 2.18 Gbps |
| 웹 서버 | 7840HS | 2,500 Mb/s | 2.33 Gbps | 2.34 Gbps |
| 프로젝트 서버 B | 5800U | 2,500 Mb/s | 2.32 Gbps | 2.33 Gbps |
| 경량 서버 D | H255 | 2,500 Mb/s | 2.34 Gbps | 2.25 Gbps |
| AI 보조 서버 | 7500F | 2,500 Mb/s | 2.31 Gbps | 2.24 Gbps |
AI 서버(10Gbps NIC)와 2.5Gbps NIC 간 연결. AI 보조 서버는 케이블/포트 교체로 100Mbps → 2.5Gbps 승격 (24배 개선).
Tier 2: 1Gbps 연결 (10대)
| 서버 역할 | CPU | 실측 송신 | 실측 수신 |
|---|---|---|---|
| 경량 서버 A | H255 | 923 Mbps | 860 Mbps |
| 프로젝트 서버 C | 5825U | 922 Mbps | 883 Mbps |
| 프로젝트 서버 D | 5825U | 921 Mbps | 925 Mbps |
| 프로젝트 서버 E | 5825U | 921 Mbps | 919 Mbps |
| 경량 서버 B | H255 | 921 Mbps | 934 Mbps |
| 프록시 서버 | N100 | 921 Mbps | 938 Mbps |
| 프로젝트 서버 F | 5825U | 921 Mbps | 861 Mbps |
| 경량 서버 C | H255 | 920 Mbps | 910 Mbps |
| 프로젝트 서버 G | 5825U | 920 Mbps | 924 Mbps |
| 백업 서버 | 5825U | 920 Mbps | 838 Mbps |
전 서버 920Mbps 이상 송신 달성. 이전 측정 대비 저속 서버(456~731Mbps)가 모두 정상 1Gbps로 복구됨.
네트워크 최적화 이력
초기 측정(2/21) 후 케이블·포트 교체를 진행하여 100Mbps 계층을 완전히 제거했습니다.
| 서버 | 이전 (2/21) | 현재 (2/26) | 조치 |
|---|---|---|---|
| AI 보조 서버 | 95 Mbps | 2.31 Gbps | 케이블/포트 교체 → 2.5Gbps 승격 (24배) |
| 프로젝트 서버 D | 456 Mbps | 921 Mbps | 1Gbps 정상 도달 (2배) |
| 프로젝트 서버 C | 610 Mbps | 922 Mbps | 정상화 (51% 개선) |
| 프로젝트 서버 E | 731 Mbps | 921 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대 | 외부 백업 | 설명 |
|---|---|---|---|
| PasswordAuth | OFF | ON | 비밀번호 로그인 차단 (키 인증만 허용) |
| PermitRootLogin | OFF | 기본값 | root 직접 로그인 차단 |
| MaxAuthTries | 3회 | 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가지 원칙입니다.
역할별 서버 분리
AI, 프록시, 프로젝트, 백업을 물리적으로 분리합니다. 한 서버의 장애가 다른 역할에 전파되지 않습니다.
키 인증 Only, 비밀번호 OFF
17개 SSH 키를 교차 등록하고 비밀번호 인증을 비활성화합니다. 무차별 공격을 원천 차단합니다.
외부 서버 이중 격리
네트워크(VPN) + SSH(DenyUsers)로 이중 차단합니다. 외부 서버 탈취 시에도 내부 접근 불가.
CPU 안정화로 장기 운영
AI 서버 외에는 터보 부스트를 OFF합니다. 24/7 운영 시 온도·전력 안정성이 곧 신뢰성입니다.
대역폭 파악 후 배치
iperf3로 실측한 뒤 대역폭이 높은 연결에 핵심 서비스를 배치합니다. 추측이 아닌 데이터 기반.
인프라 전체 요약
| 항목 | 현황 |
|---|---|
| 서버 수 | 16대 (내부) + 1대 (외부 백업) |
| 네트워크 | 10.0.10.0/24, 2.5Gbps 5대 + 1Gbps 10대 (전 서버 1G 이상) |
| SSH 보안 | 17개 키 메시, 비밀번호 OFF, MaxAuthTries 3 |
| 외부 격리 | WireGuard + DenyUsers 이중 차단 |
| CPU 부스트 제어 | 8대 적용 (프로젝트/프록시/백업) |
| AI GPU | RTX PRO 6000 + RTX 5060 Ti (크로스서버) |
| 백업 | IronWolf 12TB × 2, NFS 네트워크 스토리지 |
클라우드 없이 사무실에서 AI 인프라를 운영하는 것은 충분히 가능합니다. 중요한 것은 서버 수가 아니라 역할 분리, 보안, 안정성의 원칙입니다. 서버가 늘어나면 Grafana + Prometheus 통합 모니터링 도 함께 구축해 실시간 상태를 파악하는 것을 권합니다. 이 원칙 위에서 크로스서버 추론, 동시 접속 부하 테스트, GPU 전력 최적화가 의미를 가집니다.
댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
사무실 온프레미스 AI 인프라를 이렇게 체계적으로 정리한 글은 처음 봅니다. SSH 메시 보안 부분이 특히 실무에 도움됩니다.
클라우드 비용 때문에 온프레미스를 고민 중이었는데, 16대 서버를 역할별로 나누는 전략이 현실적이네요. CPU 부스트 제어는 몰랐던 포인트입니다.
iperf3로 실제 대역폭을 측정하고 계층화한 부분이 좋습니다. 케이블/포트 교체로 100Mbps를 완전히 없애고 전 서버 1Gbps 이상으로 통일한 점이 인상적입니다.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.