처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.07.02 33
#AI

든든하라고 넣은 '폴백'이 오히려 서비스를 무너뜨린다고요?

Hacker News 원문 보기
든든하라고 넣은 '폴백'이 오히려 서비스를 무너뜨린다고요?

든든하라고 넣은 폴백이 서비스를 무너뜨린다고요?

서비스를 만들다 보면 누구나 이런 걱정을 해요. “메인 시스템이 갑자기 죽으면 어떡하지?” 그래서 많이들 넣는 게 폴백(fallback)이에요. 폴백이 뭐냐면, 원래 쓰던 경로가 실패했을 때 자동으로 다른 대체 경로로 갈아타게 해두는 안전장치예요. 예를 들면 메인 DB가 응답을 안 하면 복제본을 대신 읽거나, 캐시 서버가 죽으면 그냥 기본값을 내려보내거나, 원격 호출이 실패하면 예전에 저장해둔 값을 쓰는 식이죠. 딱 봐도 안전해 보이잖아요.

그런데 AWS에서 오랫동안 대형 장애를 분석해온 엔지니어들은 조금 의외의 이야기를 해요. 바로 이 '안전장치'가 오히려 서비스를 통째로 쓰러뜨리는 주범이 되는 경우가 아주 많다는 거예요.

왜 폴백이 위험할까요

가장 큰 이유는, 폴백 경로는 평소에 거의 안 쓰인다는 데 있어요. 생각해보면 당연하죠. 메인이 멀쩡할 땐 폴백 코드는 한 번도 실행되지 않아요. 그러다 보니 이 경로엔 아무도 모르는 버그가 조용히 숨어 있을 수 있어요. 테스트도 잘 안 되고, 실제 트래픽을 받아본 적도 없거든요. 그런데 하필 메인이 죽는 그 절체절명의 순간에, 한 번도 제대로 굴러본 적 없는 이 코드가 갑자기 모든 트래픽을 떠안게 되는 거예요.

두 번째 문제는 더 무서운데요. 메인이 죽는 상황은 대부분 '트래픽 폭증'이나 '네트워크 장애' 같은 이유로 생겨요. 그런데 그 똑같은 이유가 폴백 경로에도 똑같이 영향을 주는 경우가 많아요. 즉 메인이 감당 못 할 만큼 부하가 몰려서 쓰러졌는데, 그 부하가 고스란히 폴백으로 넘어가니 폴백도 똑같이 쓰러지는 거죠. 결국 안전장치가 하나 더 있어서 더 안전한 게 아니라, 실패가 연쇄적으로 번지는 도미노가 되어버려요. 실제로 아마존 초창기에도 데이터베이스가 폴백 모드로 넘어갔다가 그 폴백이 부하를 못 견뎌서 훨씬 더 큰 장애로 번진 사례가 있었대요.

그럼 어떻게 해야 하나요

이 글에서 말하는 핵심 대안은 '정적 안정성(static stability)'이라는 개념이에요. 이게 뭐냐면, 장애가 났을 때 뭔가 새로운 동작(새 호출, 새 경로 전환)을 하려고 애쓰는 대신, 지금 가지고 있는 상태 그대로 계속 동작하도록 설계하자는 거예요. 예를 들어 의존하는 서비스가 죽어도 마지막으로 받아둔 정상 데이터를 계속 내려주면, 굳이 폴백으로 갈아탈 필요가 없죠.

그리고 폴백을 꼭 써야 한다면, 평소에도 일부러 그 경로를 굴려주라고 해요. 정기적으로 폴백을 실제로 태워서 '식지 않게' 유지하는 거죠. 넷플릭스가 카오스 엔지니어링으로 일부러 장애를 내면서 폴백을 훈련시키는 게 딱 이 맥락이에요. 또 폴백 용량을 미리 넉넉하게 확보해두거나, 아예 폴백 대신 빠르게 에러를 반환하고(fail fast) 재시도를 백오프와 함께 거는 방식도 대안으로 제시해요.

업계 맥락에서 보면

사실 이건 AWS만의 이야기가 아니에요. 구글 SRE 책에서도 비슷한 원칙이 나오고, 서킷 브레이커(circuit breaker) 패턴으로 유명한 넷플릭스 Hystrix, 요즘 많이 쓰는 Resilience4j 같은 라이브러리도 결국 '어떻게 폴백을 안전하게 다룰까'를 고민한 결과물이에요. 다만 이 글이 던지는 메시지는 한 발 더 나가요. “서킷 브레이커랑 폴백을 넣었으니 안심”이 아니라, “그 폴백 자체가 검증됐는지, 부하를 감당할 수 있는지”를 의심하라는 거죠.

한국 개발자에게

국내에서도 MSA(마이크로서비스)로 넘어가면서 Spring Cloud, Resilience4j로 @Retry, @CircuitBreaker, fallbackMethod를 습관처럼 붙이는 경우가 많아요. 그런데 이 글의 교훈은 명확해요. 폴백 메서드를 그냥 '에러 안 나게' 붙여두고 잊어버리면, 정작 대형 이벤트(커머스 대규모 세일, 트래픽 폭증) 때 그게 터진다는 거예요. 폴백 경로도 부하 테스트를 해봤는지, 정적 안정성으로 대체할 순 없는지 한 번쯤 점검해볼 만해요.

한 줄로 정리하면, 안전장치를 많이 넣는 것보다 '검증된 안전장치'가 훨씬 중요하다는 거예요. 여러분 서비스의 폴백 코드, 마지막으로 실제 트래픽에서 돌아본 게 언제인가요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

AI 도구, 직접 활용해보세요

AI 시대, 코딩으로 수익을 만드는 방법을 배울 수 있습니다.

AI 활용 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.