대규모 트래픽 처리 관련 면접 질문 - 실전 시스템 설계 가이드

대규모 트래픽 처리는 백엔드 개발자의 핵심 역량입니다. "사용자가 1000만 명이라면?", "초당 10만 건의 요청이 온다면?" 같은 질문에 체계적으로 답변할 수 있어야 해요. 실제 시스템 설계 경험을 바탕으로 핵심 포인트들을 정리해보겠습니다.

1. 대규모 시스템 설계 시 가장 먼저 고려해야 할 것은 무엇인가요?

답변: 가장 중요한 것은 요구사항을 명확히 하는 것입니다. 대규모라는 게 구체적으로 어느 정도인지, 어떤 종류의 트래픽인지 파악해야 해요.

트래픽 특성 파악이 첫 번째입니다. 읽기 중심인지 쓰기 중심인지에 따라 설계가 완전히 달라져요. 예를 들어 유튜브는 읽기가 99%라서 CDN과 캐싱에 집중하지만, 은행 시스템은 쓰기 정확성이 더 중요하죠.

데이터 규모와 성장률도 중요합니다. 현재 1TB인 데이터가 1년 후 10TB가 될지 100TB가 될지에 따라 샤딩 전략이나 스토리지 선택이 달라져요.

지역적 분산도 고려해야 합니다. 글로벌 서비스면 지역별 레이턴시를 줄이기 위해 멀티 리전 구성이 필요하고, 국내 서비스면 단일 리전으로도 충분할 수 있어요.

예산과 팀 규모는 현실적인 제약사항입니다. 아무리 좋은 아키텍처라도 운영할 인력이 없거나 비용이 과도하면 의미가 없어요.

비즈니스 요구사항도 핵심입니다. 금융 서비스라면 정확성과 보안이 최우선이고, 소셜 미디어라면 실시간성과 가용성이 더 중요하죠.

실제로 이커머스 시스템을 설계할 때, 일반 조회는 약간의 지연이 있어도 괜찮지만 결제 과정에서는 정확성이 절대적으로 중요하다고 판단해서 서로 다른 아키텍처를 적용했습니다.

2. 티켓팅 시스템처럼 순간적인 대규모 트래픽을 어떻게 처리하시겠습니까?

답변: 티켓팅 시스템은 가장 까다로운 케이스 중 하나입니다. 평상시 거의 트래픽이 없다가 예매 시작과 동시에 수십만 명이 몰리는 상황이거든요.

대기열 시스템 구현이 핵심입니다. 모든 사용자를 동시에 서버로 보내면 시스템이 죽으니까, 가상 대기열을 만들어서 순서대로 입장시켜야 해요. Redis의 Sorted Set을 활용해서 타임스탬프 기반으로 순서를 매기고, 초당 일정 수만큼만 실제 예매 페이지로 진입시킵니다.

CDN과 정적 캐싱으로 기본적인 부하를 줄입니다. 콘서트 정보, 좌석 배치도, CSS/JS 파일 등은 미리 CDN에 배포해서 오리진 서버 부하를 최소화해요.

읽기와 쓰기 분리가 중요합니다. 좌석 조회는 읽기 전용 복제본에서 처리하고, 실제 예매는 마스터 DB에서만 처리합니다. 좌석 상태는 약간의 지연이 있어도 괜찮지만 예매는 정확해야 하니까요.

낙관적 락과 재고 관리로 동시성을 처리합니다. 같은 좌석에 여러 명이 동시에 예매를 시도할 때, 데이터베이스 레벨에서 제어해야 해요. Version 필드나 Unique 제약조건을 활용합니다.

Circuit Breaker와 Graceful Degradation을 적용합니다. 결제 시스템이 과부하되면 예매를 일시 중단하거나 대기열로 돌려보내는 식으로 전체 시스템 다운을 방지해야 해요.

미리 준비된 인프라 확장도 필수입니다. 평상시 2대 서버로 운영하다가 예매일에는 50대로 늘리는 식으로, 미리 Auto Scaling 정책을 세팅해두고 테스트까지 완료해야 합니다.

실제 경험에서는 콘서트 티켓팅 시스템에서 대기열 없이 운영했다가 서버가 다운됐던 적이 있어요. 그 후 Redis 기반 대기열을 도입하고, 초당 100명씩만 입장시키도록 제한해서 안정적으로 운영할 수 있었습니다.

3. 실시간 채팅 서비스가 동시 사용자 100만 명을 지원하려면 어떻게 설계해야 하나요?

답변: 실시간 채팅은 일반적인 HTTP 요청-응답과는 다른 접근이 필요합니다.

WebSocket 연결 관리가 핵심인데, 100만 개의 동시 WebSocket 연결을 하나의 서버가 감당할 수 없어요. 일반적으로 서버 한 대당 1만-2만 연결 정도가 한계라서, 최소 50대 이상의 서버가 필요합니다.

Connection Load Balancing이 어려운 부분입니다. HTTP와 달리 WebSocket은 상태를 유지하는 연결이라서 Sticky Session이 필요해요. 사용자별로 특정 서버에 고정 연결되도록 해야 합니다.

Message Broker 활용이 필수입니다. 사용자 A가 서버1에 연결되고 사용자 B가 서버2에 연결된 상황에서, A가 B에게 메시지를 보내려면 서버 간 통신이 필요해요. Redis Pub/Sub이나 Apache Kafka를 활용해서 메시지를 라우팅합니다.

메시지 저장 전략도 중요합니다. 모든 메시지를 실시간으로 DB에 저장하면 성능 문제가 생기니까, 일단 메모리나 메시지 큐에 저장하고 배치로 DB에 저장하는 방식을 사용해요.

읽음 처리와 알림이 복잡한 부분입니다. 누가 언제 메시지를 읽었는지 추적하려면 별도의 상태 관리가 필요하고, 오프라인 사용자에게는 푸시 알림을 보내야 해요.

채팅방별 샤딩으로 부하를 분산할 수 있습니다. 채팅방 ID를 해시해서 특정 서버군에서 처리하도록 하면 관련 사용자들의 메시지를 효율적으로 라우팅할 수 있어요.

메시지 순서 보장도 고려해야 합니다. 네트워크 지연이나 서버 처리 순서 때문에 메시지가 뒤바뀔 수 있는데, 타임스탬프나 시퀀스 번호로 순서를 보장해야 해요.

실무에서는 Slack 클론을 만들면서 처음에는 단순한 WebSocket 서버 하나로 시작했는데, 사용자가 늘면서 Redis Pub/Sub을 도입하고 서버를 여러 대로 확장했습니다. 가장 어려웠던 부분은 사용자가 채팅방을 나갔다 들어왔을 때 이전 메시지 히스토리를 효율적으로 로드하는 것이었어요.

4. 검색 엔진이 초당 10만 건의 검색 쿼리를 처리하려면 어떻게 해야 하나요?

답변: 검색 엔진은 읽기 집약적인 시스템의 대표적인 예입니다.

검색 인덱스 최적화가 가장 중요해요. Elasticsearch나 Solr 같은 전용 검색 엔진을 사용해야 하는데, 일반 데이터베이스의 LIKE 검색으로는 절대 이런 성능을 낼 수 없어요. 역인덱스 구조로 키워드별로 문서를 미리 매핑해둬야 합니다.

인덱스 샤딩과 복제가 핵심입니다. 10만 RPS를 처리하려면 검색 인덱스를 여러 노드에 분산해야 해요. 문서 ID 기반이나 키워드 기반으로 샤딩하고, 각 샤드마다 복제본을 만들어서 읽기 부하를 분산시킵니다.

캐싱 전략을 여러 층에서 적용해야 해요. 인기 검색어는 애플리케이션 레벨에서 캐시하고, 검색 결과도 Redis에 캐시해서 같은 쿼리가 오면 바로 응답할 수 있게 합니다.

자동완성과 연관 검색어도 성능에 큰 영향을 줍니다. Trie 자료구조나 n-gram 기법을 활용해서 사용자가 타이핑하는 동안 실시간으로 제안할 수 있어야 해요.

검색 품질과 개인화를 위해서는 별도의 랭킹 알고리즘이 필요합니다. 하지만 실시간으로 복잡한 계산을 하면 성능이 떨어지니까, 미리 계산된 점수를 인덱스에 저장해두고 사용합니다.

로그 기반 학습으로 검색 품질을 개선할 수 있어요. 사용자들이 어떤 결과를 클릭했는지, 어떤 검색어를 다시 입력했는지 분석해서 랭킹을 조정합니다.

지역화와 언어 처리도 고려해야 해요. 한국어는 형태소 분석이 필요하고, 영어는 stemming이나 lemmatization이 필요합니다. 이런 텍스트 전처리도 성능에 영향을 주죠.

실시간 인덱싱이 까다로운 부분입니다. 새로운 문서가 추가되면 즉시 검색 가능해야 하는데, 전체 인덱스를 재구성하면 시간이 오래 걸려요. 증분 인덱싱이나 Hot-Cold 구조를 사용해서 해결할 수 있어요.

실제 경험에서는 뉴스 검색 서비스를 만들면서 처음에는 MySQL의 Full-Text Search를 사용했는데, 기사가 100만 건을 넘어가니까 검색 속도가 급격히 느려졌어요. Elasticsearch로 이전한 후 동일한 쿼리가 5초에서 0.1초로 단축됐습니다.

5. 라이브 스트리밍 서비스가 동시 시청자 100만 명을 지원하려면 어떻게 해야 하나요?

답변: 라이브 스트리밍은 대용량 미디어 데이터를 실시간으로 전송해야 하는 특수한 케이스입니다.

CDN이 절대적으로 중요합니다. 100만 명이 동시에 시청한다면 네트워크 대역폭만으로도 엄청난 비용이 들어요. AWS CloudFront나 Cloudflare 같은 글로벌 CDN을 활용해서 사용자와 가까운 지역에서 스트리밍을 제공해야 합니다.

적응형 비트레이트 스트리밍이 필수입니다. 사용자의 네트워크 상황에 따라 1080p, 720p, 480p 등 다양한 화질을 제공해야 해요. HLS나 DASH 프로토콜을 사용해서 네트워크 상황이 나빠지면 자동으로 낮은 화질로 전환됩니다.

스트리밍 서버 분산이 핵심입니다. 스트리머의 영상을 받아서 여러 화질로 인코딩하고 CDN으로 배포하는 Origin 서버가 병목이 될 수 있어요. 지역별로 Ingest 서버를 두고 부하를 분산시켜야 합니다.

실시간 채팅 시스템도 함께 고려해야 해요. 인기 스트리머의 채팅은 초당 수천 개의 메시지가 올라오는데, 이를 모든 시청자에게 실시간으로 전달해야 합니다. 메시지 샘플링이나 우선순위 기반 전송을 고려해야 해요.

지연시간 최소화가 중요한 요구사항입니다. 전통적인 스트리밍은 30초 정도 지연이 있지만, 라이브 상호작용이 중요한 서비스에서는 3-5초 이하로 줄여야 해요. WebRTC나 Low-Latency HLS 같은 기술을 활용합니다.

시청자 수 집계와 분석도 실시간으로 처리해야 합니다. 100만 명의 시청자가 들어오고 나가는 이벤트를 실시간으로 처리해서 정확한 동시 시청자 수를 보여줘야 해요.

장애 대응과 백업이 특히 중요합니다. 라이브는 한 번 끊어지면 복구할 수 없으니까, 다중 경로와 백업 시스템을 구축해야 해요. Primary와 Backup 인코더를 동시에 운영하는 경우도 있어요.

실제로 게임 스트리밍 플랫폼 개발에 참여했을 때, 인기 스트리머의 방송이 시작되면 순식간에 10만 명이 몰려서 서버가 다운되는 경우가 자주 있었어요. CDN을 여러 업체로 분산하고, 시청자 수에 따른 Auto Scaling을 구현해서 안정성을 크게 개선할 수 있었습니다.

6. 글로벌 소셜미디어 서비스의 뉴스피드는 어떻게 설계해야 하나요?

답변: 뉴스피드는 개인화와 실시간성을 동시에 만족해야 하는 복잡한 시스템입니다.

Push vs Pull 전략을 적절히 조합해야 해요. 팔로워가 적은 사용자는 게시물을 올릴 때 모든 팔로워의 뉴스피드에 미리 push하고, 셀러브리티처럼 팔로워가 많은 사용자는 뉴스피드 요청 시 pull로 가져오는 하이브리드 방식을 사용합니다.

뉴스피드 랭킹 알고리즘이 핵심인데, 단순한 시간순 정렬이 아니라 사용자의 관심도, 게시물의 인기도, 게시 시간 등을 종합해서 점수를 매겨야 해요. 하지만 실시간으로 복잡한 계산을 할 수는 없으니까 미리 계산된 점수를 활용합니다.

캐시 계층 설계가 매우 중요해요. 각 사용자별로 뉴스피드를 Redis에 캐시해두고, 새로운 게시물이나 상호작용이 있을 때마다 업데이트합니다. 하지만 모든 사용자의 뉴스피드를 캐시하기에는 메모리가 부족하니까 활성 사용자 위주로 선별적 캐시를 적용해야 해요.

실시간 업데이트 처리도 까다로운 부분입니다. 좋아요, 댓글, 공유가 발생할 때마다 관련된 뉴스피드를 실시간으로 업데이트해야 하는데, 이를 동기적으로 처리하면 성능 문제가 생겨요. 이벤트 기반 비동기 처리를 사용합니다.

지역별 데이터 분산이 필요해요. 한국 사용자의 뉴스피드를 미국에서 가져오면 지연시간이 길어지니까, 지역별로 데이터를 복제하고 동기화해야 합니다. 하지만 글로벌 인플루언서의 게시물은 모든 지역에서 접근 가능해야 하니까 복잡해져요.

컨텐츠 필터링과 안전도 중요합니다. 스팸, 혐오 표현, 부적절한 콘텐츠를 실시간으로 필터링해야 하고, 특정 지역의 법적 요구사항도 고려해야 해요.

A/B 테스트와 개인화 학습을 위한 인프라도 필요합니다. 사용자의 행동 데이터를 실시간으로 수집해서 머신러닝 모델을 지속적으로 업데이트하고, 다양한 알고리즘을 실험할 수 있는 환경을 구축해야 해요.

실제 경험에서는 소셜 네트워크 서비스의 뉴스피드에서 가장 어려웠던 부분이 "친구의 친구" 같은 간접 관계의 콘텐츠를 어떻게 효율적으로 가져오느냐였어요. 그래프 데이터베이스와 캐싱을 조합해서 해결했지만, 관계가 복잡해질수록 성능 최적화가 어려웠습니다.

7. 온라인 게임의 실시간 매칭 시스템은 어떻게 설계하면 좋을까요?

답변: 게임 매칭 시스템은 레이턴시와 공정성을 동시에 고려해야 하는 독특한 시스템입니다.

매칭메이킹 알고리즘이 핵심인데, 단순히 먼저 들어온 순서대로 매칭하는 게 아니라 실력, 지역, 대기시간 등을 종합 고려해야 해요. ELO 레이팅이나 TrueSkill 같은 알고리즘으로 실력을 수치화하고, 비슷한 수준의 플레이어들을 매칭시킵니다.

지역별 매칭 풀 관리가 중요해요. 한국 플레이어와 미국 플레이어를 매칭시키면 핑이 높아져서 게임 경험이 나빠지니까, 지역별로 매칭 풀을 분리해야 합니다. 하지만 특정 지역에 플레이어가 적으면 대기시간이 길어지는 트레이드오프가 있어요.

실시간 매칭 큐 관리가 기술적으로 까다로운 부분입니다. 수십만 명의 플레이어가 동시에 매칭을 요청하는 상황에서, 조건에 맞는 플레이어들을 빠르게 찾아서 그룹을 만들어야 해요. Redis의 Sorted Set이나 우선순위 큐를 활용해서 효율적으로 처리할 수 있습니다.

매칭 서버의 부하 분산도 고려해야 해요. 인기 게임은 전 세계적으로 동시 접속자가 수백만 명에 달하는데, 이를 단일 매칭 서버로 처리할 수는 없어요. 게임 모드별, 지역별로 매칭 서버를 분산하고 로드밸런싱해야 합니다.

대기시간 관리와 백필이 사용자 경험에 중요해요. 너무 엄격한 조건으로 매칭하면 대기시간이 길어지니까, 시간이 지날수록 조건을 완화하는 전략을 사용합니다. 또한 게임 중 나간 플레이어를 대체할 백필 시스템도 필요해요.

치팅 방지와 신뢰도 시스템도 매칭에 영향을 줍니다. 핵 사용자나 독성 플레이어는 별도 풀에서 매칭시키거나, 신뢰도가 높은 플레이어들끼리 우선 매칭시키는 방식을 사용해요.

게임 서버 할당과 세션 관리까지 고려해야 완전한 시스템이 됩니다. 매칭이 성공하면 적절한 게임 서버를 할당하고, 모든 플레이어가 정상적으로 접속할 때까지 세션을 유지해야 해요.

실무에서는 배틀로얄 게임의 매칭 시스템을 개발했는데, 100명을 한 게임에 매칭시키는 게 생각보다 어려웠어요. 처음에는 단순하게 100명이 모이면 게임을 시작했는데, 실력 차이가 너무 커서 게임이 재미없어졌어요. 실력 기반 매칭을 도입한 후 게임 만족도가 크게 향상됐습니다.

8. 대규모 파일 업로드/다운로드 시스템은 어떻게 최적화하나요?

답변: 대용량 파일 처리는 일반적인 웹 요청과는 다른 접근이 필요합니다.

청크 기반 업로드가 기본입니다. 큰 파일을 작은 조각으로 나누어서 병렬 업로드하면 속도도 빠르고 네트워크 오류 시 해당 청크만 재업로드하면 되니까 효율적이에요. 일반적으로 5-10MB 단위로 청크를 나눕니다.

**직접 업로드 방식(Direct Upload)**을 사용해서 서버 부하를 줄일 수 있어요. 클라이언트가 파일을 애플리케이션 서버를 거치지 않고 직접 S3나 GCS 같은 스토리지에 업로드하게 하는 거죠. 서버는 Pre-signed URL만 생성해주면 됩니다.

CDN과 엣지 로케이션을 활용해서 다운로드 성능을 최적화합니다. 전 세계에 분산된 엣지 서버에 파일을 캐시해서 사용자와 가까운 곳에서 다운로드할 수 있게 해요.

압축과 중복제거로 스토리지 비용을 절약할 수 있습니다. 같은 파일이 여러 번 업로드되는 경우 해시값을 비교해서 하나만 저장하고 참조만 늘리는 방식을 사용해요.

메타데이터 관리가 의외로 중요합니다. 파일 이름, 크기, 업로드 시간, 사용자 정보 등을 별도 데이터베이스에 저장해서 빠른 검색과 관리를 가능하게 해야 해요.

바이러스 스캔과 콘텐츠 필터링도 고려해야 합니다. 대용량 파일일수록 악성코드가 숨어있을 가능성이 높고, 저작권 침해 콘텐츠일 수도 있어요. 업로드와 동시에 스캔하되, 사용자 경험을 해치지 않게 비동기로 처리해야 합니다.

대역폭 제한과 QoS를 적용해서 전체 시스템 성능을 보호해야 해요. 한 사용자가 너무 큰 파일을 업로드해서 다른 사용자들의 서비스 이용에 지장을 주면 안 되니까요.

재시작 가능한 업로드를 지원해서 사용자 편의성을 높일 수 있어요. 네트워크가 끊어지거나 브라우저를 닫아도 이어서 업로드할 수 있게 하는 거죠.

실제 프로젝트에서는 동영상 공유 플랫폼을 만들면서 처음에는 단순하게 전체 파일을 한 번에 업로드받았는데, 큰 동영상 파일(1GB 이상)에서 자주 실패가 발생했어요. 청크 기반 업로드로 바꾸고 AWS S3 Multipart Upload를 활용한 후 성공률이 95%에서 99.5%로 향상됐습니다.

9. 대규모 시스템에서 데이터 정합성을 어떻게 보장하나요?

답변: 분산 시스템에서는 완벽한 일관성과 성능을 동시에 달성하기 어려워서 적절한 트레이드오프가 필요합니다.

Eventually Consistent 모델을 많이 사용해요. 즉시 모든 노드에서 일관된 데이터를 보장할 수는 없지만, 시간이 지나면 결국 일관성이 보장되는 방식입니다. 소셜미디어의 '좋아요' 수 같은 경우 몇 초 정도의 지연은 허용 가능하죠.

SAGA 패턴으로 분산 트랜잭션을 처리합니다. 여러 서비스에 걸친 작업을 순차적으로 실행하고, 중간에 실패하면 이미 완료된 작업들을 역순으로 보상(Compensating) 트랜잭션을 실행해서 롤백하는 방식이에요.

Event Sourcing과 CQRS를 활용할 수도 있습니다. 모든 상태 변경을 이벤트로 저장하고, 현재 상태는 이벤트들을 재생해서 계산하는 방식이에요. 읽기와 쓰기를 완전히 분리해서 각각 최적화할 수 있어요.

분산 락과 리더 선출이 필요한 경우도 있습니다. 여러 서비스가 동시에 같은 자원을 수정하려 할 때 분산 락으로 제어하거나, Raft나 PBFT 같은 합의 알고리즘으로 리더를 선출해서 순서를 보장할 수 있어요.

데이터 검증과 모니터링이 매우 중요해요. 분산 시스템에서는 버그나 네트워크 장애로 인한 데이터 불일치가 발생할 수 있으니까, 주기적으로 데이터를 검증하고 불일치를 감지하는 시스템이 필요합니다.

Idempotency 보장도 핵심입니다. 같은 작업을 여러 번 실행해도 결과가 동일하도록 설계하면, 네트워크 재전송이나 재처리 상황에서도 안전해요.

실무에서는 전자상거래 시스템에서 주문과 결제, 재고 관리가 서로 다른 서비스로 분리되어 있었는데, 네트워크 장애로 인해 결제는 성공했는데 재고 차감이 실패하는 경우가 있었어요. SAGA 패턴을 도입해서 결제 성공 후 일정 시간 내에 재고 차감이 확인되지 않으면 자동으로 결제를 취소하는 로직을 구현했습니다.

10. 시스템 장애 시 빠른 복구를 위한 전략은 무엇인가요?

답변: 대규모 시스템에서는 장애가 발생할 것을 전제로 하고 빠른 감지와 복구에 집중해야 합니다.

Circuit Breaker 패턴으로 장애 전파를 차단합니다. 외부 의존 서비스가 응답하지 않으면 계속 요청을 보내는 대신 즉시 실패 처리하고 대체 로직을 실행해요. 전체 시스템이 연쇄적으로 다운되는 것을 방지할 수 있습니다.

Auto Healing과 Self Recovery를 구현합니다. 서버나 컨테이너에 문제가 생기면 자동으로 재시작하거나 새로운 인스턴스로 교체하는 거죠. Kubernetes의 Health Check와 Restart Policy를 활용하면 쉽게 구현할 수 있어요.

Blue-Green Deployment나 Canary Deployment로 안전한 배포를 보장합니다. 문제가 있는 버전을 배포했을 때 즉시 이전 버전으로 롤백할 수 있게 해야 해요.

실시간 모니터링과 알림 시스템이 핵심입니다. 장애를 빨리 감지할수록 복구 시간이 단축되니까, 핵심 지표들을 실시간으로 모니터링하고 임계치를 넘으면 즉시 알림을 받아야 해요.

Runbook과 자동화된 대응을 준비합니다. 자주 발생하는 장애 유형에 대해서는 대응 절차를 문서화하고, 가능하면 자동화해서 사람의 개입 없이도 복구될 수 있게 해야 해요.

다중 가용 영역(Multi-AZ)과 재해 복구를 구성합니다. 하나의 데이터센터에 문제가 생겨도 다른 지역에서 서비스를 계속할 수 있어야 해요. RTO(복구 시간 목표)와 RPO(복구 시점 목표)를 명확히 정하고 이에 맞는 전략을 세워야 합니다.

Graceful Degradation으로 핵심 기능은 유지합니다. 전체 시스템에 문제가 생겨도 가장 중요한 기능만은 계속 작동하도록 우선순위를 정해야 해요.

포스트모템과 지속적 개선이 중요해요. 장애가 발생하면 원인 분석하고 재발 방지책을 마련하는 것까지가 장애 대응의 마지막 단계입니다.

실제 경험에서는 데이터베이스 마스터 서버가 갑자기 다운됐을 때, 자동 페일오버가 작동하지 않아서 30분간 서비스가 중단된 적이 있어요. 그 후 정기적인 페일오버 테스트를 도입하고, 모니터링 시스템을 개선해서 같은 문제를 방지할 수 있었습니다.

핵심 정리

대규모 트래픽 처리는 단일 해결책이 아닌 여러 기술의 조합으로 해결해야 하는 복합적인 문제입니다.

면접에서 중요한 포인트:

1. 체계적 접근: "일단 서버부터 늘려보자"가 아니라 병목 지점을 분석하고 단계별로 해결하는 체계적 사고를 보여줘야 합니다.

2. 트레이드오프 이해: 성능 vs 일관성, 비용 vs 안정성, 복잡성 vs 유지보수성 등의 트레이드오프를 이해하고 비즈니스 요구사항에 맞는 선택을 할 수 있어야 해요.

3. 실제 경험: "이론적으로는 가능하다"가 아니라 "실제로 해봤더니 이런 문제가 있었고 이렇게 해결했다"는 구체적인 경험이 중요합니다.

4. 확장성 고려: 현재 요구사항뿐만 아니라 10배, 100배 성장했을 때도 대응할 수 있는 확장 가능한 설계를 제시할 수 있어야 해요.

5. 모니터링과 운영: 시스템을 만드는 것만큼 안정적으로 운영하는 것도 중요하다는 것을 이해하고, 모니터링과 장애 대응 경험을 어필해야 합니다.

면접관은 정답을 외우는 사람보다는 문제를 체계적으로 분석하고 합리적인 해결책을 제시할 수 있는 사람을 원합니다. 기술 스택보다는 사고 과정과 의사결정 근거를 명확하게 설명할 수 있는 것이 더 중요해요.