업무 시스템이 느려졌을 때 서버를 증설하는 것만으로 문제가 해결되지는 않습니다. 요청이 이동하는 네트워크, 데이터를 읽는 저장 장치, 프로그램 자체의 처리 과정에서 지연이 발생할 수 있기 때문입니다. 기업 IT 인프라는 개별 장비의 사양보다 업무 요청이 어디를 거쳐 처리되는지부터 살펴보면 이해하기 쉽습니다.
업무 요청을 따라가면 인프라의 역할이 보입니다
IT 인프라는 정보시스템을 실행하는 하드웨어·소프트웨어·연결 환경을 뜻합니다. IBM의 IT 인프라 설명도 서버, 저장 시스템, 네트워크 장비, 운영체제를 주요 구성 요소로 다룹니다.
직원이 그룹웨어에서 결재 문서를 여는 상황을 가정해 보겠습니다. 요청은 네트워크를 거쳐 프로그램이 실행되는 서버에 도착합니다. 프로그램은 필요한 문서 정보와 첨부파일을 조회하고, 결과를 다시 사용자에게 전달합니다.
이때 데이터베이스는 데이터를 검색·변경하는 소프트웨어이고, 스토리지는 데이터베이스 파일이나 첨부파일을 보관하는 저장 기반입니다. 둘은 연결되어 있지만 같은 개념은 아닙니다. 실제 요청에는 인증이나 캐시가 추가될 수 있으므로 이 흐름을 모든 시스템의 고정 구조로 보아서는 안 됩니다.
서버·네트워크·스토리지는 역할과 확인 항목이 다릅니다
서버는 프로그램을 실행하고 요청을 처리합니다. 웹페이지 제공, 업무 처리, 데이터베이스 운영처럼 기능을 나눌 수 있으며, 이 역할들이 반드시 서로 다른 물리 장비를 뜻하지는 않습니다. 하나의 장비에서 여러 기능을 실행하거나 가상 서버로 분리할 수도 있습니다.
네트워크는 사용자와 시스템 사이의 통신을 담당합니다. 스위치는 장비를 연결하고, 라우터는 네트워크 사이에서 데이터를 전달하며, 방화벽은 정책에 따라 통신을 제어합니다. 무선 AP는 무선 단말의 접속을 제공합니다. Cisco의 네트워크 인프라 설명처럼 연결에는 장비뿐 아니라 관련 소프트웨어도 포함됩니다.
스토리지는 데이터의 저장과 읽기·쓰기를 담당합니다. 서버에 직접 연결하는 DAS, 네트워크로 파일을 제공하는 NAS, 블록 단위 저장 공간을 제공하는 저장 네트워크인 SAN 등이 있습니다. IBM의 데이터 스토리지 설명에서 이 차이를 확인할 수 있습니다. 용량이 충분해도 읽기·쓰기 지연이 크면 업무가 느려질 수 있습니다.
| 구분 | 핵심 역할 | 문제 발생 시 확인할 항목 |
|---|---|---|
| 서버 | 프로그램 실행과 업무 처리 | 프로세스 상태, CPU·메모리, 애플리케이션 오류 |
| 네트워크 | 사용자와 시스템 사이의 통신 | 연결 경로, 지연·손실, 통신 허용 정책 |
| 스토리지 | 데이터 저장과 읽기·쓰기 | 남은 용량, 응답 지연, 저장 장치 오류 |
클라우드는 자원의 제공 방식과 관리 범위를 바꿉니다
서버·네트워크·스토리지가 자원의 역할을 설명한다면, 클라우드는 그 자원을 제공하고 사용하는 방식을 설명합니다. 이 글에서 다루는 퍼블릭 클라우드에서는 사업자의 자원을 서비스로 이용합니다. AWS의 클라우드 인프라 설명에서도 그 기반을 서버·스토리지·네트워킹 장비와 소프트웨어로 설명합니다.
가상 서버를 직접 관리하는 IaaS에서는 기업이 운영체제와 설치한 프로그램을 관리하는 범위가 큽니다. 완성된 업무 소프트웨어를 이용하는 SaaS에서는 기반 관리의 상당 부분을 제공자가 맡습니다. 따라서 클라우드라는 이름만으로 운영 책임을 동일하게 판단할 수 없습니다.
AWS 공동 책임 모델도 고객의 책임이 선택한 서비스에 따라 달라진다고 명시합니다. 도입 전에는 데이터 접근권한, 백업·복구 범위, 장애 문의 창구를 확인해야 합니다. 비용도 서버 이용료와 함께 저장·전송·백업 등 해당 서비스의 과금 항목을 살펴야 합니다.
구성 검토는 장애 영향과 복구 기준에서 시작합니다
다음은 장애 원인을 좁히기 위한 가정 예시입니다. 일부 직원만 접속하지 못한다면 단말과 접속 경로, 권한 차이를 살펴봅니다. 접속은 되지만 조회만 느리다면 프로그램 처리, 데이터베이스 질의, 저장 장치 응답을 함께 확인합니다. 저장만 실패한다면 남은 공간과 쓰기 권한, 애플리케이션 오류를 대조합니다.
이 구분은 점검의 출발점이며 원인 판정표는 아닙니다. 같은 증상이 여러 계층에서 발생할 수 있으므로 발생 시각, 영향받은 사용자, 실패한 기능을 먼저 기록하는 편이 좋습니다.
이중화도 장비 대수만으로 판단하기 어렵습니다. 서버가 두 대여도 공통으로 쓰는 스토리지나 회선이 멈추면 서비스가 중단될 수 있습니다. 한 구성 요소의 장애가 전체 업무를 멈추게 하는 단일 장애 지점을 연결 구조에서 찾아야 합니다.
데이터 복구는 별도로 검토합니다. 업무별로 허용 가능한 중단 시간과 데이터 손실 범위를 정하고, 백업 보관 위치와 복원 절차를 확인합니다. 이는 장비를 많이 구매하기 위한 기준이 아니라 필요한 보호 수준을 정하기 위한 기준입니다.
자주 묻는 질문
서버는 반드시 전산실에 있는 전용 장비여야 합니까?
아닙니다. 서버는 서비스를 제공하는 역할을 가리키기도 하며, 물리 장비나 가상 환경에서 실행될 수 있습니다. 실제 배치와 자원 공유 방식은 구성에 따라 달라집니다.
클라우드로 이전하면 사내 네트워크 관리는 필요 없습니까?
여전히 필요합니다. 사내 단말에서 클라우드 서비스까지 연결되어야 하므로 무선 접속, 인터넷 회선, 접근 정책 등을 관리해야 합니다. 사내 시스템과 연동한다면 그 연결 구간도 점검 대상입니다.
서버를 이중화하면 백업을 생략할 수 있습니까?
그렇게 판단할 수 없습니다. 이중화는 일부 구성 요소의 장애에도 서비스를 이어가기 위한 설계이고, 백업은 필요한 시점의 데이터를 복원하기 위한 수단입니다. 잘못된 삭제나 변경이 복제될 수 있으므로 별도의 복구 수단을 검토해야 합니다.
결론
기업 IT 인프라를 파악할 때는 업무 시스템 하나를 골라 사용자 접속 위치, 처리 서버, 데이터 저장 위치, 외부 서비스 연결을 정리해 보십시오. 이어서 각 구간의 관리 담당자와 장애 시 확인할 정보를 적으면 됩니다. 이 흐름 위에서 성능, 접근권한, 단일 장애 지점, 복구 방법을 검토하면 서버·네트워크·스토리지·클라우드를 실제 업무와 연결해 이해할 수 있습니다.