［독서기록］ 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2, 3장

📖 제목 : 가상 면접 사례로 배우는 대규모 시스템 설계 기초 : 2, 3장
🙋‍♂️ 저자 : 알렉스 쉬
시스템 설계 관련 면접을 보면 “이 서비스에 필요한 서버 수는 몇 대일까?” “하루에 얼마나 많은 요청이 들어올까?” “저장공간은 얼마나 필요할까?” 같은 질문을 받게 될 수 있다. 이런 질문들은 정확한 숫자를 요구하는 게 아니라, 얼마나 필요할 지를 대략적으로 계산해보는 능력을 보려는 의도다. 이 추론을 개략적인 규모 추정이라고 한다. 쉽게 말해서 ‘대충 머릿속으로 계산해봤을 때 대략 어느 정도인지 감 잡기’를 할 수 있는지가 포인트다. 예시와 함께 어떻게 계산해야 할 지 알아보자.
그리고 3장에서는 시스템 설계 면접은 왜 보는 것인지에 대해 생각해볼 수 있다.

📌2장. 트위터 QPS와 저장소 요구량을 추정해보자

전제 조건

• 월간 사용자 수 : 3억 명
• 50%의 사용자가 매일 트위터를 사용
• 사용자 1명당 평균 2개의 트윗 작성
• 미디어 포함 트윗은 10%
• 데이터는 5년간 보관

QPS 계산

1. 일일 사용자 수(DAU) = 3억 x 50% = 1.5억
2. 하루 트윗 수 = 1.5억 x 2 = 3억 트윗
3. QPS(초당 요청 수) = 3억 / 24시간 / 3600초 = 3,500QPS
4. 최대 QPS(피크타임) = 2배로 잡아 7,000 QPS

   ❓ 최대 QPS는 왜 2배로 잡았을까?
   하루 평균 QPS만으로 시스템을 설계하면 피크 타임에 서버가 터질 위험이 크기 때문에, 보통 기업에서는 2~3배로 최대 QPS를 추정한다. 책에서는 간단한 예시를 위해 2배로 설정했지만, 실제 대규모 서비스에서는 5배까지 버퍼를 두기도 한다.

저장소 요구량

• 트윗 1개 평균 크기 : 140bytes
• 미디어 크기 : 평균 1MB
• 미디어 저장소 요구량 : 1.5억 x 2 x 10% x 1MB = 30TB/일
• 5년간 미디어를 보관하기 위한 저장소 요구량 : 30TB x 365 x 5 = 약 55PB

  ❓ 이렇게 계산하면 여유 저장소 공간이 없을 것 같은데?
  책에서는 추정 방법을 알려주기 위해 “대략적인 계산 예시”를 든 것 같다. 실제 시스템에서는 여유 저장소가 반드시 확보되어야 한다. 스토리지 비용보다 서비스 중단 비용이 훨씬 크기 때문이다. 실제 서비스에서는 추정치 + 20~50%의 여유분을 두는 경우가 일반적이고, AWS나 Azure 등에서는 Auto Scale도 가능하다. 오래된 데이터는 상대적으로 저렴한 장기 보관용 스토리지로 이전시키는 것도 비용 절감 방법이다.

---

✔️추정 결과를 면접관에게 말할 때 주의할 점

• 정답보다 계산 과정을 보는 게 목적이므로, 추론 과정을 설명할 것.
• 계산 결과가 어렵다면 너무 세세한 계산보다는 근사치로 빠르게 추정해서 말할 것.
• 단위는 꼭 붙여서 말할 것(MB, ms 등)
• QPS(초당 요청 수), 최대 QPS, 저장소 요구량, 캐시 용량 등을 계산해보라는 질문이 자주 나오므로 계산해보는 습관을 들이자.

---

📌3장. 시스템 설계 면접이 있는 이유는 무엇인가?

“널리 알려진 소프트웨어 X를 설계해보세요” 라는 질문을 받았다고 치자. 실제로 지금 당장, 앉은 자리에서 대규모 시스템을 한 사람이 설계하기를 원하는 것일까? 어떤 면접관도 정답을 기대하지 않는다. 애초에 이 문제에는 정해진 정답도 없다. 이 면접 자리에서 면접자가 보여야 하는 덕목은 아래와 같다.

• 내가 이런 사고를 거쳐 설계한다는 것을 보여주기
• 설계 과정에서 내린 결정들에 대한 방어 능력 보여주기
• 면접관의 피드백을 건설적인 방식으로 처리할 수 있는 자질이 있음을 보여주기

설계의 순수성에 너무 집착한 나머지 타협적 결정을 도외시하고 오버 엔지니어링을 하지는 않았는지, 너무 편협하거나 완고하게 굴지 않았는지도 잘 생각해보아야 한다.

효과적인 면접을 위한 4단계 접근법

✔️1. 문제 이해 및 설계 범위 확정

빨리 대답한다고 다 좋은 것이 아니다. 정답이 없는 질문에서는 더욱 그렇다. 깊이 생각하고, 요구사항과 가정들을 분명히 한 후에 대답하자. 제품 사용자 수는 얼마나 되는지, 회사의 규모는 얼마이고 앞으로 얼마나 더 커지리라고 예상하는지, 현재 사용 가능한 기술스택은 무엇이 있는지 등 상황 설정에 필요한 추가 정보는 얼마든지 있다.

✔️2. 개략적인 설계안 제시 및 동의 구하기

2장에서 익힌 개략적 설계를 활용하자. 최초 청사진을 제시하고 의견을 구하면 좋다. 면접관을 팀원처럼 대하고 의견을 물어보는 것도 도움이 된다. 훌륭한 면접관들은 지원자들과 대화하고 설계 과정에 개입하기를 즐긴다.

✔️3. 상세 설계

전체 설계의 청사진이 마련되었다면, 해당 청사진에 대한 면접관들의 의견을 청취하고 상세 설계에서 집중해야 할 부분들을 확인해야 한다. 해시 함수 설계를 어떻게 하는지, 또는 지연시간을 어떻게 단축시킬 것인지 등 면접관이 확인하고자 하는 능력에 집중해야 한다. 불필요한 디테일에 시간을 낭비하지 않도록 주의하자.

✔️4. 마무리

• 앞서 설계한 내용을 한 번 다시 요약해주는 것도 정리에 도움이 된다.
• 추가 개선점, 시스템 병목 구간에 대한 질문에 ‘개선점이 없다’, ‘완벽하다’ 같은 대답은 하지 않도록 하자. 개선점은 언제나 있다.
• 오류가 발생하면 무슨 일이 생기는 지 따져보는 것도 흥미로울 것이다.
• 운영 이슈(로그, 모니터링, 배포)에 대해서 논의해 볼 수도 있다.
• 미래에 닥칠 확장 요구에 어떻게 대처할 것인지도 흥미로운 주제다.
• 필요하지만 다루지 못했던 세부 개선사항에 대해 이야기 해보는 것도 좋다.

📌면접을 보기 전에 기억해두어야 할 것들

• 재질문 해서 의도나 요구사항을 구체적으로 확인하자. 내가 내린 가정이 옳다고 믿고 그냥 답변했는데 면접관의 질문 의도와 완전히 다른 답변을 하게 될 수도 있다.
• 정답이나, 최선의 답안은 없다. 요구사항을 정확히 이해하고 생각했는지 다시 확인하자.
• 면접관과 소통하자. 정해진 답만 줄줄 얘기하는 게 아니라 대화를 통해 사고의 흐름을 이해할 수 있도록 해야 한다.
• 가능하다면 여러가지 해법을 함께 제시하자.
• 중요한 내용을 먼저 말하자.