POOOLING FOREST
1851년의 대규모 트래픽 처리: 2만 명의 식사를 설계한 PM의 관점 - 170년 전 런던에서 발생한 2만 명의 식사 대접 사례를 통해, 현대 IT 시스템의 트래픽 처리와 부하 분산
Future Insight

1851년의 대규모 트래픽 처리: 2만 명의 식사를 설계한 PM의 관점

170년 전 런던에서 발생한 2만 명의 식사 대접 사례를 통해, 현대 IT 시스템의 트래픽 처리와 부하 분산 전략, 그리고 사용자 경험(UX)의 본질을 분석합니다.

김형철

CEO / PM

안녕하세요. 풀링포레스트 CEO이자 PM 김형철입니다.

제품을 운영하다 보면 누구나 한 번쯤 '트래픽의 공포'를 마주하게 됩니다. 대규모 프로모션이나 예상치 못한 바이럴로 인해 사용자가 폭주할 때, 서버가 뻗지 않고 버틸 수 있을지, 고객 경험(UX)이 망가지지 않을지 밤새워 모니터링했던 기억이 생생합니다. 저 역시 주니어 PM 시절, 준비되지 않은 이벤트로 서비스를 먹통으로 만들고 등 뒤로 흐르던 식은땀을 잊지 못합니다. 오늘은 170년 전 런던에서 있었던, 어쩌면 역사상 가장 거대했던 '오프라인 트래픽 처리' 사례를 통해 시스템 설계의 본질을 이야기해보고자 합니다.

문제 상황: 4톤의 데이터, 2만 명의 동시 접속자

1851년 12월 25일, 런던 소호의 햄 야드(Ham Yard)에서는 전례 없는 이벤트가 열렸습니다. 런던 최빈곤층을 위한 무료 크리스마스 만찬이었죠. 당시 런던은 대박람회(Great Exhibition)의 화려함 뒤에 극심한 빈곤이 숨겨져 있던 시기였습니다. 기획된 규모는 상상을 초월했습니다.

  • User Traffic (사용자 수): 약 22,500명 (당시 런던 인구의 약 1%)

  • Data Payload (처리해야 할 리소스):

    • 소고기 및 고기류: 4톤 (9,000파운드)

    • 감자: 1.5톤 (3,300파운드)

    • 플럼 푸딩: 2.3톤 (5,000파운드)

    • 맥주(Porter): 5,000파인트

이 정도 규모라면 단순한 '요리'의 영역이 아닙니다. 이것은 거대한 물류 시스템이자, 현대적으로 해석하면 고가용성(High Availability)이 요구되는 대규모 트래픽 처리 과제였습니다. 만약 준비가 부족했다면 현장은 아수라장이 되고, 폭동이 일어났을지도 모를 일입니다.

위기와 깨달음: 셰프가 아닌 시스템 아키텍트가 필요하다

이 프로젝트를 총괄한 알렉시스 소예(Alexis Soyer)는 단순한 요리사가 아니었습니다. 그는 이미 1840년대 아일랜드 대기근 당시, 현장에서 시간당 1,000명을 먹일 수 있는 야전 부엌을 설계하며 '재난 상황에서의 시스템'을 체득한 인물이었습니다.

소예는 직감했습니다. "맛있는 음식을 만드는 것(Core Logic)"만큼이나 중요한 것은 "음식을 적시에 배분하는 것(Delivery Pipeline)"이라는 사실을요. 그는 셰프가 아니라, 시스템 아키텍트로서 이 문제에 접근했습니다. 2만 명이 한 번에 몰리면 병목 현상(Bottleneck)이 발생할 수밖에 없음을 알고, 철저한 부하 분산(Load Balancing) 전략을 세웠습니다.

액션: 19세기식 MSA와 쓰로틀링 전략

소예가 적용한 전략은 현대 IT 기업들이 대규모 트래픽을 처리하는 방식과 놀라울 정도로 흡사합니다.

  1. 쓰로틀링(Throttling) 및 순차 처리:
    그는 2만 명을 한꺼번에 입장시키지 않았습니다. 입장권을 배부하고, 30분 간격으로 300명씩 끊어서 입장시켰습니다. 이는 서버가 처리할 수 있는 양만큼만 요청을 받아들이는 'Rate Limiting'과 정확히 같은 원리입니다. 덕분에 주방(백엔드)은 과부하 없이 일정한 퍼포먼스를 유지할 수 있었습니다.

  2. 비동기 처리 및 오프로딩(Offloading):
    모든 사용자가 현장에서 식사(On-site Processing)를 하도록 강제했다면 공간(리소스)이 부족했을 겁니다. 소예는 'Take-away' 시스템을 도입했습니다. 가장들에게 고기, 푸딩, 커피 등을 싸주어 집으로 가져가게 했습니다. 이는 메인 서버의 부하를 클라이언트(각 가정)로 분산시키는 엣지 컴퓨팅(Edge Computing)적 사고방식이라 할 수 있습니다.

  3. 인프라 최적화:
    그는 일반적인 화덕 대신 자신이 직접 설계한 대용량 조리 기구(Soyer Stove)를 사용했습니다. 이는 마치 범용 CPU 대신 AI 연산에 특화된 GPU나 NPU를 도입해 처리 효율을 극대화한 것과 같습니다.

결론: 압도적인 물량 앞에서도 우아함을 잃지 않기

결과는 대성공이었습니다. 22,500명이 배를 채웠고, 경찰 70명이 배치되었지만 소란은 없었습니다. 심지어 천막 안은 호랑가시나무와 오렌지로 장식되어 있었고, 밴드가 음악을 연주했습니다. 소예는 단순히 '먹이는 기능'만 구현한 것이 아니라, 빈곤층에게 존중받는다는 느낌을 주는 '사용자 경험(UX)'까지 완벽하게 챙겼습니다.

풀링포레스트 팀원들에게 저는 항상 말합니다. "트래픽이 몰린다고 해서 서비스의 품질이 떨어지는 것을 당연하게 여기지 말자"고요. 트래픽 스파이크 상황에서도 우리의 서버는 안정적이어야 하고, 화면은 아름다워야 하며, 사용자는 불편함을 느끼지 않아야 합니다.

개발자나 PM으로서 우리가 만드는 시스템은 단순히 코드가 돌아가는 기계가 아닙니다. 그 끝에는 결국 서비스를 사용하는 '사람'이 있습니다. 1851년의 알렉시스 소예가 4톤의 고기 앞에서 당황하지 않고 따뜻한 한 끼를 대접했듯, 우리도 쏟아지는 요청(Request) 속에서 사용자에게 최상의 경험을 제공할 수 있는 탄탄한 구조를 고민해야 합니다.

오늘 하루, 여러분이 다루고 있는 시스템은 급격한 부하 앞에서도 우아함을 유지할 수 있나요? 막막하다면, 170년 전 소호의 안뜰에서 묵묵히 고기를 썰던 한 셰프의 설계를 떠올려 보시길 바랍니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.