[인프라 생존기] NFS 마운트 옵션 변경의 함정, 시니어 빌런의 '올인(All-in)' 작업계획서 (시즌 2-71편)

1. 70편의 네트워크 무지, 그 위험한 연장선

지난 70편에서 L2/L3의 기본도 모르면서 네트워크 교육을 맡겠다던 시니어 빌런의 무책임을 기억하시나요? 기술적 기반이 무너진 시니어가 현장을 주도할 때 어떤 실질적인 위협이 발생하는지, 이번 NFS(Network File System) 최적화 작업계획서 검토 과정에서 그 정점을 목격했습니다. 네트워크를 모르는 이가 네트워크 기반 파일 시스템인 NFS를 만질 때 벌어지는 참사, 그 서막입니다.

🔗 [다시보기] 70편: "모르면 모른다고 하면 돼" – 시니어 빌런의 기적의 교육학

2. NFS 최적화, 그 예민한 레이어 위에서

최근 전사적인 성능 향상을 위해 각 사이트별로 NFS 마운트 옵션을 최적화하는 작업이 예정되었습니다. NFS는 편리하지만, hard/soft, rsize/wsize, intr 같은 옵션 하나 잘못 건드리면 프로세스가 **'D-state(Uninterruptible sleep)'**에 빠지거나 마운트 포인트가 깨져 서비스 전체가 멈출 수 있는, 인프라의 '모세혈관' 같은 존재입니다. 18년 차 아키텍트인 제가 돌다리도 두드려 보며 계획을 세우는 이유입니다.

3. 작업계획서에 'Step-by-Step' 검증이 없다?

그런데 검토를 위해 펼쳐본 시니어 빌런의 작업계획서를 보고 저는 제 눈을 의심했습니다. 수많은 개발, 검증, 운영 서버의 NFS 옵션을 모조리 수정하고 리마운트하는 복잡한 스텝들이 나열되어 있는데, 정작 가장 중요한 **'서비스 영향도 확인'**은 수백 대의 서버 작업을 다 마친 맨 마지막 줄에 딱 한 줄 적혀 있었습니다.

[NFS 작업 최종 단계] 20. 전체 서비스 정상 유무 확인 (끝)

4. "다 터진 다음에 확인하면 그게 '서비스 가용성'입니까?"

인프라 작업의 정석은 **'단계별 검증(Verification per Phase)'**입니다.

1. 개발 환경(Dev) 변경 후 마운트 상태 및 서비스 확인 (Pass 시 다음)
2. 검증 환경(Staging) 변경 후 데이터 입출력 및 서비스 확인 (Pass 시 다음)
3. 운영 환경(Prod) 순차적 적용 및 실시간 모니터링

이게 상식 아닙니까? 개발 서버에서 이미 NFS 핸들이 꼬였으면 거기서 멈추고 **롤백(Rollback)**을 해야지, 운영 서버까지 다 초토화한 다음에 마지막에 확인하겠다는 건 "폭탄 10개를 다 터뜨려 보고, 나중에 건물이 남아 있는지 보겠다"는 무모한 도박과 다를 바 없습니다.

5. 결론: 전문가는 '결과'가 아니라 '리스크'를 설계한다

제가 단계별 확인 절차를 넣어야 한다고 지적하자 그는 오히려 "번거롭게 뭘 매번 확인하냐, 어차피 똑같은 설정인데"라며 혀를 찼습니다. 62편의 AG(Array Group) 사건, 70편의 네트워크 무지 사건에 이어 이제는 **'리스크 매니지먼트'**라는 엔지니어링의 기본 윤리마저 상실한 모습입니다.
 
진짜 전문가는 작업의 속도가 아니라 **'가용성(Availability)'**의 연속성을 설계하는 사람입니다. NFS 옵션 하나를 바꾸더라도 그 뒤에 숨은 서비스의 무게를 느끼지 못하는 자는 인프라를 만질 자격이 없습니다.

---

📖 오늘의 인프라 묵상

"지혜로운 자는 두려워하여 악을 떠나나 미련한 자는 방자하여 스스로 믿느니라" (잠언 14:16)

 
자신의 작업 결과에 대해 근거 없는 자신감을 갖는 것은 엔지니어로서 가장 위험한 신호입니다. 단계별 확인이라는 '겸손한 절차'를 무시하는 자의 끝은 결국 대형 장애라는 재앙뿐입니다.
 
[다음 생존기 예고]
"말은 하지 않았지만, 당신의 구멍을 내가 메우고 있습니다." NFS 옵션 변경 작업에서 개발/검증 단계를 통째로 망각해버린 시니어 빌런. 마운트 포인트 확인조차 생략한 무모한 계획서 앞에서, 지적 대신 '침묵의 백업'을 택한 18년 차 아키텍트의 고독한 사투!
 
인프라 생존기 72편: NFS 작업에서 사라진 '개발/검증' 단계, 시니어 빌런의 위험한 망각 (6월 23일 화요일 오전 8:30 공개 예정)