서버를 줄였더니 IT시스템 장애가 덜 났다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

서버를 더 사야 한다고 믿었던 첫 달

느린 화면보다 먼저 본 것은 서버 대수였습니다

처음 사무실의 IT시스템을 맡았을 때 가장 많이 들은 말은 “서버가 부족한 것 같다”였습니다. 회계 프로그램은 월말마다 느렸고, 파일 공유 폴더는 오전 10시만 되면 멈칫했으며, 프린터 스풀러까지 늦게 반응했습니다. 겉으로 보면 당연히 서버 증설이 답처럼 보였습니다.

그런데 막상 서버실에 들어가 보니 이상한 점이 먼저 보였습니다. 물리 서버와 가상 서버는 생각보다 많았고, 일부 장비는 CPU 사용률이 높지 않았습니다. 반대로 특정 오래된 서버 하나에 인증, 공유, 백업 에이전트, 사내 프로그램 임시 폴더가 몰려 있었습니다. 저는 이때부터 “장비가 부족한가”보다 “역할이 정리되어 있는가”를 먼저 보기 시작했습니다.

용어를 다시 확인할 때는 기본 정의도 도움이 됩니다. 서버의 개념은 네이버 지식백과 서버 설명처럼 요청을 처리하고 자원을 제공하는 역할로 이해할 수 있습니다. 문제는 회사 안에서 그 역할이 명확하지 않으면, 서버가 많아도 운영자는 매번 감으로 장애를 따라가게 된다는 점입니다.

• 장점: 서버를 바로 사지 않으면 기존 자원의 낭비 지점을 볼 시간이 생깁니다.
• 단점: 초반에는 “아직도 장비 안 샀냐”는 압박을 받을 수 있습니다.
• 사용 팁: CPU, 메모리, 디스크보다 먼저 서버별 담당 업무와 사용 부서를 적어보는 것이 좋았습니다.

제가 써본 방식으로는 서버 성능표보다 “이 서버가 멈추면 누가, 어떤 일을 못 하는가”를 먼저 적는 쪽이 장애 대응에 훨씬 실용적이었습니다.

한 달 동안 실제로 해본 서버 줄이기 기록

저는 새 서버 견적을 잠시 보류하고, 한 달 동안 서버 역할표를 만들었습니다. 거창한 도구부터 쓰지는 않았습니다. 엑셀에 서버명, IP, 용도, 담당 부서, 백업 여부, 접속 계정, 최근 재부팅일, 서비스 포트를 적었습니다. 단순한 표였지만, 이 표 하나로 “아무도 모르는 서버”가 생각보다 많이 보였습니다.

특히 불편했던 점은 담당자가 떠난 뒤에도 남아 있는 임시 서버였습니다. 이름은 테스트 서버인데 실제 업무 데이터가 쌓여 있었고, 개발용으로 만든 공유 폴더를 영업팀이 계속 쓰고 있었습니다. 이런 상태에서는 서버를 추가해도 혼란이 줄지 않습니다. 새 장비가 들어와도 기존의 엉킨 역할이 그대로 복제되기 때문입니다.

IT자산관리 관점이 필요한 이유도 여기에 있습니다. 관련 개념은 IT자산관리시스템 정의에서 더 넓게 확인할 수 있는데, 실제 현장에서는 거창한 시스템보다 “무엇이 어디에 있고 누가 쓰는지”를 꾸준히 갱신하는 습관이 먼저였습니다.

1. 서버별 업무명을 사람이 읽을 수 있는 말로 바꿨습니다.
2. 사용하지 않는 스케줄러와 중복 백업 작업을 멈췄습니다.
3. 공유 폴더 권한을 부서 기준으로 다시 나눴습니다.
4. 테스트 서버에 있던 실제 업무 데이터를 운영 서버로 옮겼습니다.
5. 재부팅이 어려운 서버는 월 1회 점검 시간을 따로 잡았습니다.

네트워크를 만지니 서버 체감 속도가 달라졌습니다

서버 문제가 아닌데 서버처럼 보이는 순간

서버를 줄였는데도 모든 문제가 해결되지는 않았습니다. 다만 이상한 패턴이 보였습니다. 같은 프로그램을 쓰는데 2층 사무실은 느리고, 4층 회의실에서는 비교적 괜찮았습니다. 서버 자원 사용률은 안정적인데 특정 구역에서만 로그인 시간이 길었습니다. 이때부터 원인을 네트워크 쪽으로 옮겨 보기 시작했습니다.

실제 사용 후기처럼 말하면, 이 과정은 꽤 번거롭지만 만족도가 높았습니다. 스위치 포트 표기를 맞추고, 오래된 허브를 걷어내고, 업무망과 방문자 와이파이를 분리하자 “서버가 느리다”는 민원이 줄었습니다. 서버를 새로 산 것이 아니라, 서버까지 가는 길을 정리한 셈입니다.

특히 중소기업 사무실에서는 프린터, NAS, CCTV, 무선 AP, 회의실 장비가 같은 대역에서 뒤섞이는 경우가 많습니다. 평소에는 괜찮아 보이지만, 백업 시간이나 대용량 파일 이동이 겹치면 업무 프로그램까지 느려집니다. 서버를 아무리 좋은 것으로 바꿔도 길목이 막히면 사용자는 여전히 답답합니다.

• 좋았던 점: 네트워크 구간을 정리하니 서버 교체 없이 체감 속도가 개선됐습니다.
• 아쉬운 점: 작업 시간에는 일부 부서의 연결을 끊어야 해서 사전 공지가 필수였습니다.
• 현장 팁: 스위치 포트 라벨, 랜선 색상, 장비명 규칙을 맞추면 다음 장애 때 시간이 크게 줄었습니다.

제가 효과를 본 순서는 장비 구매가 아니었습니다

처음에는 고성능 스위치와 방화벽 견적부터 보고 싶었습니다. 하지만 실제로 효과를 본 순서는 달랐습니다. 먼저 IP 대역을 정리하고, 서버와 사무용 PC, 무선 장비, 보안 장비를 구분했습니다. 그다음 오래된 케이블과 포트 오류가 잦은 구간을 찾았습니다. 마지막에야 교체가 필요한 장비를 골랐습니다.

이 순서가 좋았던 이유는 예산 설명이 쉬워졌기 때문입니다. “좋은 장비가 필요합니다”라고 말하면 비용으로만 보입니다. 반면 “이 포트에서 오류가 반복되고, 이 구간 때문에 회계 서버 응답이 늦어집니다”라고 말하면 운영 리스크로 설명할 수 있습니다. 인프라 개선은 감이 아니라 기록으로 설득해야 하더군요.

그리고 보안 이슈도 무시할 수 없습니다. 최근 기업 환경에서는 단순 장애뿐 아니라 공격 대응까지 운영 범위에 들어옵니다. AI를 활용한 해킹 위협처럼 복합적인 공격 가능성은 관련 네이버 뉴스에서도 다뤄진 바 있습니다. 서버와 네트워크를 분리해서 보는 것이 아니라, 접근 경로와 권한 흐름까지 같이 봐야 하는 이유입니다.

장비를 먼저 고르면 예산 싸움이 되고, 흐름을 먼저 그리면 운영 판단이 됩니다. 서버, 네트워크, 계정, 백업은 따로 움직이지 않았습니다.

1. 서버 IP와 업무용 PC IP를 분리했습니다.
2. 방문자 와이파이는 내부 서버 접근이 안 되도록 막았습니다.
3. 백업 트래픽은 업무 피크 시간을 피해서 돌렸습니다.
4. 공유 폴더 접근 로그를 주 1회 확인했습니다.
5. 장애 문의가 들어오면 위치, 시간, 사용 프로그램을 같이 기록했습니다.

세 대를 없애고 남긴 한 대의 실제 운영 사례

파일 서버, 임시 서버, 백업 서버를 다시 묶어본 날

가장 기억에 남는 사례는 파일 서버 세 대를 정리한 일입니다. 처음에는 부서별로 서버가 나뉘어 있어 안전해 보였습니다. 영업팀 파일 서버, 디자인팀 임시 서버, 백업용 서버가 따로 있었죠. 그런데 실제로는 영업팀 서버에 디자인 파일이 있고, 디자인팀 서버에 계약서 스캔본이 있었으며, 백업 서버에는 6개월 전 작업만 남아 있었습니다.

저는 먼저 삭제부터 하지 않았습니다. 각 서버에서 최근 90일 동안 수정된 폴더를 뽑고, 부서장에게 실제 사용 여부를 확인했습니다. 그다음 새 공유 구조를 만들었습니다. 부서별 폴더, 공용 폴더, 보관 폴더를 나누고 권한을 다시 부여했습니다. 이름만 봐도 용도가 보이도록 폴더명을 정리하니 문의가 줄었습니다.

비용도 현실적으로 달라졌습니다. 새 서버를 사면 장비비, 설치비, 라이선스, 백업 저장소, 유지보수까지 따라옵니다. 반면 이번에는 스토리지 증설과 백업 정책 조정 정도로 끝났습니다. 물론 모든 회사가 서버를 줄여야 한다는 뜻은 아닙니다. 다만 서버 증설 전에 구조를 정리하면, 정말 사야 할 장비와 안 사도 되는 장비가 구분됩니다.

장애가 줄어든 이유는 장비 성능보다 운영 습관이었습니다

통합 작업을 마친 뒤 가장 크게 달라진 것은 속도보다 문의 방식이었습니다. 예전에는 “서버가 이상해요”라는 말만 왔습니다. 이후에는 “공용 폴더는 열리는데 영업 폴더만 늦어요”, “회의실 와이파이에서는 접속이 안 돼요”처럼 문제가 좁혀져 들어왔습니다. 운영자는 이 차이만으로도 대응 시간이 줄어듭니다.

저는 매주 금요일 오전에 20분짜리 점검 루틴을 만들었습니다. 서버 용량, 백업 성공 여부, 네트워크 장비 오류 로그, 신규 계정, 퇴사자 계정 잠금 상태를 봅니다. 이 루틴은 화려하지 않지만 효과가 있습니다. 특히 작은 회사일수록 한 번의 장애가 매출, 상담, 출고, 정산에 바로 닿기 때문에 짧은 반복 점검이 큰 보험처럼 작동합니다.

마지막으로 남긴 한 대의 서버에는 역할을 분명히 적었습니다. 파일 공유와 권한 관리, 백업 에이전트 연동까지만 맡겼습니다. 다른 업무 프로그램을 얹고 싶은 유혹도 있었지만 참았습니다. 서버 한 대가 여러 일을 할수록 편해 보이지만, 장애가 났을 때는 모든 일이 한꺼번에 멈춥니다. 제가 이번 운영에서 배운 가장 큰 장점은 단순함이었습니다.

• 운영 전: 서버는 많지만 담당 업무가 흐릿했고 장애 원인도 넓게 흩어졌습니다.
• 운영 중: 네트워크 흐름과 권한 구조를 정리하면서 불필요한 서버를 줄였습니다.
• 운영 후: 서버 대수는 줄었지만 문의 대응, 백업 확인, 장애 추적은 더 쉬워졌습니다.

실제 사례의 마지막 장면은 꽤 단순했습니다. 월요일 오전 9시 40분, 회계팀에서 파일 열림이 늦다는 연락이 왔습니다. 예전 같으면 서버 재부팅부터 떠올렸을 겁니다. 이번에는 먼저 해당 폴더 접근 로그를 보고, 같은 시간 백업 작업이 돌았는지 확인하고, 회계팀 자리의 스위치 포트 오류를 확인했습니다. 원인은 서버가 아니라 회의실에서 옮겨 꽂은 오래된 랜선이었습니다. 서버를 줄였기 때문에 오히려 원인을 더 빨리 찾은 순간이었습니다.