SharePoint 보안 패치를 적용하며 서비스 다운타임을 줄이려면 팜(Farm) 내 서버별 순차 업데이트와 구성 마법사(Configuration Wizard)의 실행 순서를 정확히 지켜야 한다. 패치 후 오류가 발생했다면 최신 백업 지점으로 데이터베이스를 복구하고 서버를 롤백해 시스템을 정상화한다.
기업 인프라 담당자에게 SharePoint 보안 업데이트는 단순한 버전 업그레이드가 아니라 시스템 가용성과 보안성 사이의 균형을 잡는 작업이다. 특히 RCE(원격 코드 실행)나 권한 상승 같은 치명적인 취약점이 발견되면 즉각 패치해야 한다는 압박을 받지만, 동시에 서비스 중단이나 기능 오류라는 심리적 부담도 함께 느낀다. 체계적인 준비 없는 업데이트는 협업 환경 전체를 마비시킬 수 있으므로, 검증된 절차에 따라 단계별로 접근해야 한다.
보안 패치 공고가 나오면 가장 먼저 업데이트 항목의 위험도를 분석해 적용 순서를 정해야 한다. 원격 코드 실행(RCE) 취약점은 공격자가 외부에서 인증 없이 서버 제어권을 얻을 수 있어 최우선으로 처리한다. 반면 권한 상승(Privilege Escalation) 취약점은 이미 내부 망에 진입한 공격자가 관리자 권한을 얻는 단계다. RCE보다 우선순위는 낮지만 여전히 심각한 위협이므로 즉시 해결해야 한다.
취약점 심각도는 CVE(Common Vulnerabilities and Exposures) 점수를 기준으로 삼아 점수가 높은 항목부터 계획을 세운다. 모든 패치를 한꺼번에 적용하면 문제가 생겼을 때 원인을 찾기 어렵다. 치명적인 취약점을 해결하는 핵심 패치를 먼저 적용하고, 기능 개선이나 마이너 업데이트는 별도의 유지보수 창(Maintenance Window)을 통해 분리해 진행하는 전략이 효율적이다.
서비스 중단 시간을 0으로 줄이는 5단계 업데이트 전략
SharePoint 팜 환경에서 가동 중단 시간을 줄이려면 단일 서버 업데이트가 아닌 롤링 업데이트(Rolling Update) 개념을 도입해야 한다. 팜에 구성된 전면 엔드 서버(Front-end Server)와 응용 서버(Application Server)를 순차적으로 처리하면 사용자 서비스 단절을 막을 수 있다.
- 사전 백업 및 스냅샷 생성: 패치 직전 모든 SharePoint 데이터베이스의 풀 백업을 수행하고, 가상화 환경이라면 서버 전체 스냅샷을 만든다. 패치 실패 시 가장 빠르게 원복할 수 있는 유일한 안전장치다.
- 로드 밸런서 제외 및 트래픽 분산: 업데이트 대상 서버를 로드 밸런서(L4/L7)에서 제외해 사용자 유입을 차단한다. 사용자는 패치 중인 서버가 아닌 정상 가동 중인 다른 서버로 자동 연결된다.
- 바이너리 업데이트 설치: Windows Update나 수동 설치 파일로 보안 패치를 설치한다. 이 단계는 단순 파일 교체 작업이며 아직 서비스에 반영된 상태는 아니다.
- SharePoint 제품 구성 마법사(PSConfig) 실행: 설치한 바이너리를 실제 SharePoint 데이터베이스와 구성 파일에 적용한다. 서버 재시작이나 서비스 일시 중지가 발생할 수 있으며, 팜 내 모든 서버에서 순차적으로 완료해야 한다.
- 검증 및 서비스 복구: 서버 기능이 정상인지 확인한 후 로드 밸런서에 다시 투입해 트래픽을 수신한다.
업데이트 영향도 분석 및 서버별 처리 순서
SharePoint 환경은 역할 기반으로 서버가 나뉘어 있어 업데이트 순서를 잘못 잡으면 팜 동기화 문제가 생길 수 있다. 보통 전면 엔드 서버부터 시작해 응용 서버, 중앙 관리 서버 순으로 진행하는 것이 좋으나, 환경에 따라 구성 마법사 실행 순서가 성능에 영향을 줄 수 있다.
| 대상 서버 역할 | 업데이트 우선순위 | 핵심 주의사항 | 예상 영향도 |
|---|---|---|---|
| Front-end Server | 1순위 (순차 적용) | 로드 밸런서 제외 필수 | 사용자 접속 경로 일시 차단 |
| Application Server | 2순위 (순차 적용) | 백그라운드 작업 및 타이머 서비스 확인 | 검색 인덱싱 및 워크플로우 지연 |
| Central Admin Server | 3순위 (최종 적용) | 관리자 페이지 접근 불가 시간 발생 | 팜 설정 및 관리 기능 일시 중단 |
패치 후 기능 오류 해결 및 완벽한 롤백 체크리스트
보안 패치 후 페이지 로딩 저하, 권한 설정 오류, 특정 웹 파트 작동 불능 같은 사이드 이펙트가 나타날 수 있다. SharePoint는 데이터베이스 스키마가 복잡해 구성 마법사(PSConfig) 단계에서 업데이트가 완료되면 단순히 프로그램을 제거하는 것만으로는 이전 상태로 되돌릴 수 없다.
오류가 발생하면 가장 먼저 SharePoint ULS(Unified Logging Service) 로그를 확인한다. 로그 파일에서 ‘Critical’ 또는 ‘Unexpected’ 수준의 에러 코드를 추적해 DLL 파일 버전 충돌인지 데이터베이스 스키마 불일치 문제인지 판별한다. 특정 서버에서만 문제가 생겼다면 바이너리를 재설치하고 구성 마법사를 다시 실행해 해결한다.
전체 팜 수준에서 기능 장애가 발생해 운영이 불가능할 때는 다음 롤백 체크리스트로 시스템을 복구한다.
- 서비스 중단 및 트래픽 전면 차단: 데이터 오염을 막기 위해 사용자 접속을 차단하고 IIS 서비스를 중지한다.
- 가상 머신 스냅샷 복원: OS 수준의 변경 사항을 되돌리려 패치 전 생성한 최신 스냅샷으로 모든 서버를 롤백한다.
- 데이터베이스 포인트-인-타임 복구(PITR): SQL Server 로그 백업을 이용해 패치 시작 직전 시점으로 데이터베이스를 복구한다. 스키마 변경 사항을 완전히 제거하는 필수 단계다.
- 구성 마법사 상태 재검증: 복구 후 각 서버의 SharePoint 버전이 일치하는지 확인하고, 필요하면 PSConfig를 다시 실행해 팜 정합성을 맞춘다.
- 단계적 서비스 재개: 내부 관리자 그룹이 먼저 접속해 핵심 기능을 테스트한 뒤, 외부 사용자 트래픽을 점진적으로 개방한다.
결론 및 실행 제언
SharePoint 보안 패치는 단순 소프트웨어 업데이트가 아니라 인프라 전체의 안정성을 결정짓는 정밀한 작업이다. RCE 같은 고위험 취약점을 우선 처리하되, 로드 밸런서를 활용한 롤링 업데이트 전략으로 다운타임을 최소화하는 것이 실무자의 핵심 역량이다. 패치 전 백업과 스냅샷 확보는 필수이며, 실패 시나리오에 따른 롤백 절차를 미리 세워둬야 장애 상황에서도 침착하게 대응할 수 있다.
운영 중인 SharePoint 환경의 패치 이력을 점검하고, 위 5단계 전략과 서버별 우선순위를 적용해 보안성과 가용성을 동시에 확보하시기 바란다. 추가 기술 지원이나 상세한 팜 구성 진단이 필요하다면 전문 엔지니어 컨설팅으로 최적의 패치 사이클을 설계하는 것을 권장한다.