[인프라 생존기] NFS 마운트의 변수를 무시한 '10분 단위' 스톱워치 계획서 (시즌 2-73편)

1. 72편의 '침묵' 속에 가려진 또 다른 실소

지난 72편에서 NFS 작업계획서에 개발/검증 단계를 통째로 빼먹은 시니어 빌런의 망각을 짚어보았습니다. 제가 말없이 뒤에서 구멍을 메우며 그의 계획서를 더 깊이 들여다보니, 실소를 금치 못할 또 다른 대목이 나타났습니다. 바로 현장의 '호흡'을 무시한 기계적인 10분 단위 시간 배분이었습니다.

🔗 [다시보기] 72편: NFS 작업에서 사라진 '개발/검증' 단계, 시니어 빌런의 위험한 망각

2. NFS 핸들이 꼬여도 '10분'이면 충분하다?

그의 계획서에는 서비스 중지, 옵션 변경, 마운트, 기동 단계가 모조리 **'10분 단위'**로 칼같이 나열되어 있었습니다.

• 22:00 ~ 22:10 : 서비스 중지
• 22:10 ~ 22:20 : NFS 옵션 변경 및 리마운트
• 22:20 ~ 22:30 : 서비스 기동

인프라 현장을 아는 사람이라면 압니다. 특히 NFS는 네트워크 상태나 서버 부하에 따라 마운트 해제(Umount)가 안 되어 'Stale' 상태에 빠지거나, 리마운트 시 타임아웃을 기다려야 하는 등 수많은 변수가 존재합니다. 하지만 그의 계획서에는 이런 **'기술적 레이턴시(Latency)'**에 대한 고민이 단 1분도 녹아 있지 않았습니다.

3. 검증(Verification)은 없고 타임라인만 있는 '엑셀 아트'

정작 중요한 **'단계별 서비스 정상 유무 확인'**은 71편에서 말했듯 맨 마지막에 딱 한 줄뿐인데, 작업 단계 사이사이에는 10분이라는 가짜 여백을 촘촘히 박아두었습니다.

 

이건 엔지니어링이 아니라 보고용 **'엑셀 아트'**입니다. 윗사람들에게는 "계획대로 착착 진행되고 있다"는 착시를 주기에 딱 좋지만, 실전에서 NFS 마운트 하나가 꼬이는 순간 그 10분 단위의 계획은 1단계부터 바로 '패킷 드롭(Packet Drop)' 되듯 휴지조각이 됩니다. 진짜 아키텍트는 시간을 설계하는 게 아니라, 각 단계가 '정상 마운트' 되었음을 증명하는 **'체크포인트'**를 설계해야 합니다.

4. 결론: 서버의 숨소리를 모르는 시니어의 한계

"NFS 마운트가 11분에 완료되면 그다음 작업은 어떻게 하실 겁니까? 타임아웃으로 20분을 넘기면요?"

 

제가 말없이 그의 계획서를 수정하며 느낀 건, 그가 서버와 **'대화'**하는 법을 잊었다는 사실입니다. 서버는 기계지만 그 안의 OS와 NFS 프로토콜은 각기 다른 호흡으로 응답합니다. 그 생동감을 무시한 채 10분 단위로 박제를 해놓은 계획서는, 결국 현장에 들어가 직접 마운트 포인트를 확인해 보지 않은 이의 **'서류상 안도감'**일 뿐입니다.

 

빌런은 오늘도 시계를 보며 작업을 마무리하려 하지만, 아키텍트는 오늘도 마운트 포인트의 응답 속도를 보며 서버의 숨소리를 체크합니다. 인프라는 시계태엽이 만드는 게 아니라 **'철저한 검증'**이 만드는 것이니까요.

---

📖 오늘의 인프라 묵상

"너는 내일 일을 자랑하지 말라 하루 동안에 무슨 일이 일어날는지 네가 알 수 없음이니라" (잠언 27:1)

 

10분 단위로 내일의 작업을 확신하는 오만함보다는, 단 1분을 작업하더라도 예상치 못한 NFS 변수에 대비하는 겸손함이 엔지니어에게는 더 필요합니다. 계획은 완벽할 수 없기에, 우리는 시간 대신 **'상태'**를 믿어야 합니다.

 

[다음 생존기 예고]

"영향 없다더니, NFS 작업 중에 재기동도 안 해봤다고요?" 시니어 빌런의 무책임한 확신 뒤에 숨어있던 보안 담당자의 황당한 고백. 구축한 지 1년이 넘도록 한 번도 꺼본 적 없는 솔루션을 안고 NFS 옵션을 변경해야 하는 아키텍트의 기막힌 사연!

 

인프라 생존기 74편: NFS 작업과 보안 솔루션의 충돌, "재기동 안 해봤는데요?"라는 고백 (6월 25일 목요일 오전 8:30 공개 예정)