내부 문서

사내 서버·스토리지·백업 인프라 구성 안내

기술 스택 12분 읽기backupdocspublic-docserver-infrastructurestorage

사내 서버·스토리지·백업 인프라 구성 안내

문서 개요

사내 서버 인프라는 장비 한 대를 구입하는 일이 아니라 계산 자원, 운영 데이터, 공유 파일, 백업과 복구 절차를 하나의 시스템으로 설계하는 작업입니다.

업무 서비스
    ↓
서버 · 가상머신 · 컨테이너
    ↓
운영 스토리지
    ↓
백업 저장소 · 외부 또는 오프라인 사본

이 문서는 일반적인 구성 원칙을 설명합니다. 실제 장비 모델, 내부 주소, 관리자 계정, 백업 위치와 복구 자격증명은 접근이 통제된 비공개 운영 문서에서 관리해야 합니다.

구축 전에 정해야 하는 목표

장비 사양보다 먼저 데이터와 업무의 중요도를 분류합니다.

  • 어떤 서비스를 사내에서 실행할 것인가
  • 어떤 데이터를 저장하며 얼마나 증가하는가
  • 서비스 중단을 얼마나 허용할 수 있는가
  • 장애 발생 시 어느 시점의 데이터까지 복구해야 하는가
  • 몇 시간 또는 며칠 안에 복구해야 하는가
  • 외부 인터넷이 끊겨도 필요한 업무가 있는가
  • 개인정보와 기밀자료에 어떤 접근 정책이 필요한가
  • 장비와 소프트웨어를 관리할 담당자가 있는가
  • 클라우드, 사내, 하이브리드 중 어떤 운영 방식이 적합한가

복구 목표를 정하지 않고 고가의 장비부터 구입하면, 실제 장애에서 필요한 데이터가 백업되지 않았거나 복구 시간이 예상보다 길어질 수 있습니다.

구성 방식 선택

클라우드 중심

서버와 데이터베이스를 클라우드에서 운영하고 사내에는 네트워크와 사용자 기기만 둡니다.

  • 초기 장비 투자와 물리 관리 부담이 적음
  • 원격근무와 지점 연결이 단순함
  • 사용량, 외부 연결과 공급자 정책 관리가 필요함
  • 인터넷 장애 시 영향을 검토해야 함

사내 장비 중심

서버와 저장소를 조직이 관리하는 공간에 설치합니다.

  • 데이터 위치와 네트워크를 직접 통제할 수 있음
  • 내부 대용량 전송과 특수 장비 연동에 유리할 수 있음
  • 전원, 냉각, 부품, 보안, 백업과 장애 대응 책임이 커짐

하이브리드

민감 데이터와 내부 서비스는 사내에 두고, 외부 공개 서비스·백업·확장 자원은 클라우드를 이용합니다.

  • 업무 성격에 따라 실행 위치를 선택할 수 있음
  • 계정, 네트워크, 데이터 동기화와 장애 경로가 복잡해질 수 있음

한 가지 방식이 항상 우월한 것은 아닙니다. 데이터 위치, 지연 시간, 규정, 운영 인력과 총비용을 함께 비교합니다.

기본 물리 구성

영역 구성 요소 확인할 사항
설치 공간 랙 또는 잠금 가능한 장비 공간 출입, 환기, 온도, 먼지, 침수 위험
전원 UPS, 전원 분배 장치 총 부하, 유지 시간, 안전 종료, 배터리 관리
계산 자원 서버 CPU, ECC 메모리, 확장 슬롯, 원격 관리
운영 디스크 SSD 또는 NVMe 성능, 내구성, 장애 대응 방식
공유 저장소 NAS, 파일 또는 오브젝트 스토리지 용량, 처리량, 권한, 스냅샷
백업 저장소 별도 NAS, 디스크, 테이프 또는 클라우드 운영망 분리, 보관 기간, 복구 시험
네트워크 서버·스토리지 스위치와 NIC 실제 처리량, 이중화, 여유 포트
관리 원격 관리 인터페이스 관리망 분리, 접근 통제, 로그

서버의 CPU와 메모리만 보지 않습니다. 디스크 처리량, 네트워크, 전원, 냉각과 부품 교체 가능성이 전체 성능과 가용성을 결정합니다.

규모별 구성 예시

1단계: NAS 중심

직원 기기
   ↓
파일 서비스 또는 NAS
   ├─ 운영 데이터
   ├─ 스냅샷
   └─ 외부 백업

공유 파일과 소규모 협업이 중심이고 상시 실행할 서버 애플리케이션이 많지 않을 때 적합합니다. NAS 자체의 디스크 보호와 별도의 백업을 구분해야 합니다.

2단계: 서버와 NAS 분리

업무 사용자
   ↓
서버 1대
├─ 가상머신
├─ 컨테이너
└─ 내부 서비스
   ↓
NAS 또는 공유 스토리지
   ↓
별도 백업 저장소

애플리케이션 실행과 파일 저장을 분리합니다. 서버가 고장 나도 데이터와 백업이 같은 장비에만 남지 않도록 설계합니다.

3단계: 운영형 서버 구성

Load Balancer 또는 서비스 진입점
        ↓
서버 A · 서버 B · 서버 C
        ↓
공유 또는 분산 스토리지
        ↓
별도 백업 · 외부 복구 사본

서비스 중단 영향이 크고 여러 애플리케이션을 운영할 때 계산 자원을 여러 대로 분산합니다. 다만 서버 수를 늘리는 것만으로 고가용성이 완성되지는 않습니다. 네트워크, 스토리지, 전원과 운영 절차의 단일 장애 지점도 함께 확인합니다.

서버 사양을 정하는 방법

다음 항목을 측정하거나 예상해 계산합니다.

  • 동시에 실행할 가상머신과 컨테이너 수
  • 서비스별 CPU·메모리 사용량
  • 데이터베이스의 메모리와 디스크 요구량
  • 하루·월간 데이터 증가량
  • 파일 크기와 동시 사용자 수
  • 백업 시간대와 백업 데이터 양
  • 암호화·압축·중복 제거에 필요한 자원
  • 향후 확장 카드, GPU와 네트워크 추가 가능성

운영에 필요한 최소 용량만 맞추지 않고 장애, 업데이트와 향후 증가를 위한 여유를 둡니다. 단, 사용 근거 없이 지나치게 큰 장비를 구입하면 유지비와 교체 비용만 증가할 수 있습니다.

가상머신과 컨테이너

가상머신과 컨테이너는 서로 대체 관계라기보다 목적이 다릅니다.

구분 가상머신 컨테이너
격리 단위 운영체제를 포함한 독립 환경 호스트 커널을 공유하는 애플리케이션 환경
적합한 경우 서로 다른 OS, 강한 환경 분리, 기존 서버 이전 웹·API·Worker, 빠른 배포, 동일 이미지 반복 실행
운영 항목 OS 패치, 이미지, 스냅샷 이미지, 레지스트리, 설정, 오케스트레이션

가상머신 안에서 컨테이너를 실행하는 혼합 방식도 사용할 수 있습니다. 중요한 것은 실행 환경을 문서화하고, 데이터가 컨테이너 내부에만 남지 않도록 영구 저장소를 분리하는 것입니다.

스토리지 계층

데이터 성격에 따라 저장소를 나눕니다.

로컬 고속 스토리지

  • 데이터베이스 임시 작업
  • 가상머신 디스크
  • 애플리케이션 캐시
  • LLM 모델 캐시와 작업 공간

NVMe 같은 고속 저장장치를 사용할 수 있지만 서버 장애 시 접근이 중단될 수 있으므로 영구 보관과 복구 방식을 별도로 설계합니다.

공유 스토리지

  • 부서 공유 파일
  • 여러 서버가 함께 사용하는 데이터
  • 설치 이미지와 모델 파일
  • 장기 보관 자료

사용자·그룹별 권한, 변경 이력, 스냅샷과 보관 정책을 관리합니다.

백업 스토리지

  • 운영 데이터와 별도의 실패 영역에 위치
  • 일반 사용자가 직접 수정하거나 삭제하지 못하게 제한
  • 보관 기간과 삭제 정책 적용
  • 외부 또는 오프라인 사본 유지
  • 정기적인 복구 시험 실시

RAID와 스냅샷은 장애 대응 시간을 줄이는 도구이지만 독립적인 백업을 대신하지 않습니다. 장비 전체 손상, 계정 탈취, 악성 삭제, 화재와 침수 같은 사고에는 별도 사본이 필요합니다.

백업과 복구

백업은 복사 작업보다 복구 가능성을 확인하는 운영 절차입니다.

운영 데이터
   ├─ 빠른 복구용 스냅샷
   ├─ 별도 백업 저장소
   └─ 외부 또는 오프라인 사본

일반적으로 여러 사본을 서로 다른 저장 방식과 위치에 두는 3-2-1 원칙을 출발점으로 사용할 수 있습니다. 중요한 데이터는 변경이 어렵거나 분리된 사본을 추가하고, 백업 작업의 성공 여부뿐 아니라 실제 복구 결과까지 확인합니다.

백업 정책에는 다음 항목을 포함합니다.

  • 백업 대상과 제외 대상
  • 전체·증분 백업 주기
  • 데이터별 보관 기간
  • 암호화와 백업 키 관리
  • 백업 관리자와 복구 승인자
  • 외부·오프라인 사본
  • 복구 우선순위와 목표 시간
  • 정기 복구 시험과 결과 기록

가용성과 단일 장애 지점

다음 구성 요소가 하나뿐일 때 장애 영향을 확인합니다.

  • 인터넷 회선
  • 방화벽과 핵심 스위치
  • 서버 전원과 UPS
  • 가상화 호스트
  • 공유 스토리지
  • 인증과 DNS
  • 백업 저장소
  • 운영 담당자와 복구 지식

모든 것을 이중화할 필요는 없습니다. 업무 중단 손실과 구축·운영 비용을 비교해 중요한 지점부터 개선합니다. 이중화된 장비도 같은 전원, 같은 랙, 같은 관리 계정에 의존하면 하나의 사고에 함께 영향을 받을 수 있습니다.

모니터링과 운영

최소한 다음 상태를 관찰합니다.

  • CPU, 메모리, 디스크 사용률
  • 디스크 오류와 스토리지 지연 시간
  • 네트워크 처리량과 패킷 오류
  • 서버·스토리지 온도와 전원 상태
  • 가상머신·컨테이너 상태
  • 백업 성공 여부와 마지막 복구 시험
  • 인증 실패와 관리자 작업
  • 인증서와 저장 용량 만료 예측

경보는 많이 만드는 것보다 누가 언제 확인하고 어떤 절차로 대응할지 정하는 것이 중요합니다.

보안 원칙

  • 서버, 스토리지와 관리 인터페이스를 일반 사용자망에서 분리합니다.
  • 관리자 계정과 일반 업무 계정을 분리하고 MFA를 적용합니다.
  • 서버와 장비의 기본 계정·기본 암호를 변경합니다.
  • 운영체제, 펌웨어와 애플리케이션 패치를 관리합니다.
  • 서비스별 필요한 포트와 대상만 허용합니다.
  • 백업 저장소의 삭제 권한을 제한합니다.
  • 로그에 비밀번호, 토큰과 개인정보를 남기지 않습니다.
  • 원격 관리 접속을 승인된 경로로 제한합니다.
  • 폐기 디스크와 장비의 데이터를 안전하게 삭제합니다.

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

장비 가격만 비교하면 실제 운영비를 놓칠 수 있습니다.

  • 서버·스토리지·네트워크 장비
  • 랙, UPS, 전원 공사와 냉각
  • 디스크와 배터리 교체
  • 소프트웨어 구독과 지원 계약
  • 외부 백업 저장 공간과 전송
  • 전력 사용량
  • 운영 인력과 장애 대응 시간
  • 장비 보증 종료와 교체 주기
  • 예비 부품과 긴급 복구 비용

클라우드와 사내 장비를 비교할 때도 동일한 가용성, 백업, 보안과 운영 범위를 기준으로 총비용을 계산합니다.

구축 순서

  1. 서비스와 데이터 목록을 작성합니다.
  2. 중요도별 복구 시점과 복구 시간을 정의합니다.
  3. 클라우드·사내·하이브리드 방식을 비교합니다.
  4. 계산·메모리·스토리지·네트워크 요구량을 산정합니다.
  5. 전원, 설치 공간과 단일 장애 지점을 확인합니다.
  6. 운영 스토리지와 백업 저장소를 분리합니다.
  7. 모니터링, 패치와 접근 권한을 구성합니다.
  8. 장애와 복구 절차를 시험하고 기록합니다.

참고 문서

구체적인 장비 수량과 성능은 실제 애플리케이션 측정값, 데이터 증가량, 복구 목표와 운영 조직을 기준으로 결정합니다.

시리즈 안내

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

  1. 사내 IT 인프라와 네트워크 기본 구성 안내
  2. 사내 서버·스토리지·백업 인프라 구성 안내
  3. 사내 LLM·AI 인프라 구축 기술 스택 안내