1GB 프리티어 VPS 하나로 사이드 프로젝트를 돌린다. 작은 서버, 서비스 몇 개.

지난주에 인프라를 손봤다. 고칠 때마다 같은 걸 물었다. 이제 완전히 고쳐졌나? 다시 안 터지나? 정직한 답은 계속 "아니"였다. 심지어 고친 것 때문에 다음 문제가 터지기도 했다.

그 질문을 그만 묻게 만든 사건을 적어둔다.

사건: 모니터링이 멀쩡한 서버를 죽일 뻔했다

구성은 이랬다.

• 본체: 1GB VPS, API 하나
• watchdog: 다른 서버에서 5분마다 /health 체크. 죽으면 알림, 계속 죽어있으면 클라우드 API로 강제 재부팅.

안전하다고 느꼈다. 자동 복구까지 되니까.

그러다 본체에서 ffmpeg 작업을 돌렸다. 1코어라 CPU를 통째로 먹었고, 그 사이 /health가 10초 안에 응답을 못 했다. watchdog은 "응답 없음 = 죽음"으로 읽었다. 한 번만 더 실패했으면 멀쩡한 프로덕션 서버를 재부팅할 차례였다.

서버는 안 죽었다. 내가 돌린 작업이 느리게 만들었을 뿐인데, 지키려고 만든 게 죽일 뻔했다.

"완전히 고쳐졌나"에 정직한 yes가 없는 이유

1. "고쳐졌나"는 닫힌 질문, 시스템은 열려있다.
막을 수 있는 건 이미 본 실패뿐이다. 변경할 때마다 새 표면적이 생긴다.

2. 작은 서버는 결합도가 높다.
1코어 1기가. 무거운 작업 하나가 나머지를 굶긴다. 격리가 안 되니 "이건 안전"이 옆을 건드린다.

3. 고치는 행위도 변수다.
모니터링도 시스템의 일부고, 이번엔 그게 장애원이었다. 같은 세션에서 알림 스크립트에 실행권한을 준 게 가짜 알림의 원인이 되기도 했다.

4. 자신만만한 답은 싸다.
"됐어, 안전해"는 파급을 확인하기 전에 말하기 쉽다. 도구든, AI든, 나든. 내가 계속 "고쳐졌나"를 물은 건 그 yes를 못 믿어서였고, 안 믿길 잘했다.

진짜 도움이 된 것

보장이 아니라 감지와 되돌리기.

watchdog 수정은 "완벽하게"가 아니었다. 한 번 실패에 단정하지 않기. 몇 번 더 보고 다 실패하면 그때 죽음으로 친다.

code="000"
for i in 1 2 3; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
  [ "$code" = "200" ] && break
  [ "$i" -lt 3 ] && sleep 10
done
# 세 번 다 실패해야 진짜 죽음

순간 스파이크는 30초 안에 회복되니까, 세 번 다 실패면 진짜 죽은 거다. 무거운 작업은 굶길 서버에서 안 돌린다.

결론

"완전히 고쳐졌나"는 어떤 정직한 시스템도 yes라고 못 하는 질문이다. 쓸모 있는 버전은 더 좁다.

• 어떤 알려진 실패를 막았고, 어떻게 검증했나?
• 못 막는 건 뭐고, 어떻게 감지하고 되돌릴 건가?

뭔가 "네, 완전히 처리됐어요"라고 답하면, 보통 그때가 더 들여다볼 때다.