결국 모든 시스템 설계는 '백프레셔'로 귀결된다

'Attention is all you need' 패러디 같은 제목, 그런데 진지한 글

Lucas F. Costa가 쓴 "Backpressure is all you need"는 제목부터 트랜스포머 논문을 농담조로 가져왔지만, 안에 담긴 메시지는 정말 진지해요. 분산 시스템이든 큐 기반 워커든 마이크로서비스든, 결국 안정성을 결정하는 단 하나의 개념을 꼽으라면 백프레셔(backpressure) 라는 거예요.

백프레셔가 뭐냐면, 영어로 "역압력"이라는 뜻인데요, 데이터를 받는 쪽이 처리 속도를 못 따라갈 때 보내는 쪽에게 "잠깐, 좀 천천히 줘"라고 신호를 보내는 매커니즘이에요. 수도꼭지에서 물이 콸콸 나오는데 받는 양동이가 작으면 넘쳐버리잖아요. 그래서 양동이가 "꽉 찼으니까 잠깐 꺼"라고 수도꼭지에게 알려주는 거죠. 시스템 설계에서 이게 빠지면, 부하가 몰릴 때 모든 게 한꺼번에 무너져요.

백프레셔 없이 무너지는 시나리오

흔한 사례를 풀어볼게요. 웹 API 앞에 메시지 큐를 두고, 워커가 큐에서 작업을 꺼내 처리하는 구조라고 해봐요. 평소엔 잘 돌아가는데, 갑자기 트래픽이 10배 들어오면 어떻게 될까요? 큐는 무한정 쌓이고, 워커는 끝없이 밀린 작업을 처리하느라 점점 응답이 느려지고, 그 사이 사용자는 타임아웃을 받고 재시도를 하면서 부하를 더 늘려요. 결국 데이터베이스 커넥션이 고갈되고 전체 시스템이 다운되죠. 이걸 재시도 폭주(retry storm) 라고 부르는데, 백프레셔가 없는 시스템에서 흔히 벌어지는 죽음의 나선이에요.

반대로 백프레셔가 잘 박혀 있는 시스템은 부하가 몰릴 때 우아하게 거절해요. "지금 처리량 한계에 도달했으니까 일부 요청은 429 Too Many Requests로 돌려보내고, 큐는 일정 크기 이상 안 쌓이게 막고, 업스트림에는 속도 조절을 요청한다"는 식이죠. 일부 요청이 실패하더라도 전체 시스템은 계속 살아 있다는 게 핵심이에요.

어디에 백프레셔가 숨어 있나

사실 우리가 매일 쓰는 도구 안에 백프레셔는 이미 들어 있어요. TCP 프로토콜의 윈도우 사이즈 조절, Node.js Stream의 pipe() 함수, RxJS의 throttle/debounce/buffer, Akka Streams, Project Reactor 같은 리액티브 라이브러리, Kafka 컨슈머의 max.poll.records 설정, Kubernetes의 HPA(수평 자동 스케일러)와 PodDisruptionBudget까지 — 전부 "빠른 생산자와 느린 소비자 사이에 압력을 흐르게 한다"는 동일한 사상의 변주예요.

글의 핵심 주장은 이거예요. 새로운 분산 시스템 패턴이 등장할 때마다 사람들은 그게 '새로운 아키텍처'라고 부르지만, 본질은 백프레셔를 어디에 어떻게 두느냐의 문제다. 서킷 브레이커(Circuit Breaker)도, 벌크헤드(Bulkhead) 격리도, 큐 기반 부하 평탄화(load leveling)도 결국 같은 가족이라는 거죠.

흔히 빠지는 함정

초보 엔지니어들이 자주 빠지는 함정 하나는 "큐만 두면 안전하다"는 착각이에요. 큐는 짧은 스파이크는 흡수해주지만, 지속적인 과부하에는 오히려 독이에요. 큐가 길어질수록 평균 지연시간(latency)이 늘어나고, 데이터 신선도가 떨어지고, 메모리/디스크가 폭발해요. 그래서 큐에는 반드시 유한 크기 제한과 포화 시 정책(drop oldest, reject newest, block producer 등)을 같이 설계해야 해요.

또 하나의 함정은 "오토스케일링이 백프레셔를 대체한다"는 생각이에요. 스케일링은 분 단위로 동작하지만 부하 스파이크는 초 단위로 오거든요. 둘은 보완재지 대체재가 아니에요. 잘 만든 시스템은 백프레셔로 단기 스파이크를 견디고, 오토스케일링으로 중장기 트렌드를 따라가요.

한국 개발자에게 주는 시사점

국내에서도 토스, 쿠팡, 배달의민족 같은 대규모 트래픽 서비스가 늘면서 백프레셔에 대한 이해는 더 이상 SRE만의 영역이 아니에요. 일반 백엔드 엔지니어도 큐를 다루고, gRPC 스트림을 다루고, Kafka 컨슈머를 짜요. 그때마다 "내 코드가 폭주하는 생산자를 만났을 때 어떻게 행동할까"를 한 번씩 생각해보면 사고가 한 단계 깊어져요.

구체적인 실천으로는, HTTP 서버에 동시 요청 제한(concurrency limit)을 거는 것, 워커에 prefetch count를 설정하는 것, 클라이언트 SDK에 지수 백오프(exponential backoff)와 지터(jitter)를 넣는 것 같은 기본기를 챙기는 거예요. 라이브러리 한 줄 차이가 인시던트의 규모를 바꿔놓을 수 있어요.

마무리

결국 안정적인 시스템이란 "빠른 시스템"이 아니라 "무너지는 방식이 예측 가능한 시스템" 이에요. 그리고 그 예측 가능성은 백프레셔에서 시작돼요. 여러분이 운영 중인 서비스에서, 만약 트래픽이 평소의 10배가 들어온다면 가장 먼저 어디가 꺾일까요? 그리고 거기엔 "잠깐 멈춰"라고 말할 수 있는 장치가 있나요?