6대 모의 인터뷰 완전 분석: 문제 → 설계 → 평가

이 문서의 사용법

결론: 이 분석의 목적은 ‘정답 설계 암기’가 아니라, 문제마다 달라지는 핵심 드라이버를 먼저 식별하는 훈련이다.

• 왜(문제): 동일한 템플릿으로 풀면 면접관이 바로 눈치챈다.
• 무엇(개념): 각 문제는 병목·데이터·일관성·비용 중 다른 축이 지배한다.
• 어떻게(설계/선택): 문제 재정의 → 드라이버 식별 → 최소 설계 → 확장/장애.
• 트레이드오프: 범용성 대신 문제 특화.
• 인터뷰 문장: “이 문제의 핵심 드라이버는 ○○입니다.”

---

1) URL Shortener

결론: 이 문제의 핵심은 ‘쓰기보다 압도적으로 많은 읽기’다.

• 문제 재정의(1줄): 짧은 키로 빠르게 리다이렉트한다.
• 요구사항 질문(6): QPS? 읽기/쓰기 비율? 키 길이? 충돌 허용? TTL? 분석 필요?
• 핵심 품질 속성(3): Latency / Availability / Simplicity
• 1차 아키텍처: API → Cache → KV Store
• 데이터 모델/저장소: Key-Value (키→URL), 조인 불필요
• 병목 3 + 확장:
  1. 캐시 미스 → 캐시 히트율 개선
  2. 키 충돌 → 재시도
  3. DB QPS → 샤딩
• 장애 시나리오 2:
  • 캐시 다운 → DB 직접 조회
  • 단일 리전 장애 → 리전 복제
• 면접관 한 문장: “읽기 경로를 최대한 짧게 유지합니다.”
• 흔한 실수 2: 전역 트랜잭션 언급 / 불필요한 RDB 선택

---

2) 식당 예약

결론: 이 문제의 핵심은 ‘중복 예약 방지’다.

• 문제 재정의: 같은 시간·좌석의 중복 예약을 막는다.
• 요구사항 질문: 좌석 모델? 피크 타임? 취소? 홀드 시간? SLA?
• 핵심 품질 속성: Consistency / Correctness / Availability
• 1차 아키텍처: API → Reservation Service → RDB
• 데이터 모델: (restaurant_id, time_slot) 유니크 제약
• 병목 + 확장:
  • 피크 동시 요청 → 락 범위 최소화
  • DB 락 → 샤딩(식당 기준)
• 장애 시나리오:
  • 중복 요청 → Idempotency
  • 부분 실패 → 롤백
• 면접관 한 문장: “중복은 절대 허용하지 않습니다.”
• 흔한 실수: 캐시로 해결 / 락 전략 설명 없음

---

3) 웹 크롤러

결론: 이 문제의 핵심은 ‘비동기 파이프라인과 재처리’다.

• 문제 재정의: 대량 URL을 안정적으로 수집·처리한다.
• 요구사항 질문: 수집량? 중복 허용? robots.txt? 실패 재처리?
• 핵심 품질 속성: Throughput / Fault Tolerance / Scalability
• 1차 아키텍처: URL Frontier → MQ → Parser → Storage
• 데이터 모델: URL 상태 테이블 + 결과 저장
• 병목 + 확장:
  • 네트워크 지연 → 워커 수평 확장
  • 중복 크롤링 → 해시 디듀프
• 장애 시나리오:
  • 워커 실패 → 재시도
  • MQ 적체 → 백프레셔
• 면접관 한 문장: “단계 분리로 실패를 국소화합니다.”
• 흔한 실수: 동기 처리 / Exactly-once 집착

---

4) 탑 셀러(랭킹)

결론: 이 문제의 핵심은 ‘정확도보다 집계 비용’이다.

• 문제 재정의: 가장 많이 팔린 상품을 빠르게 보여준다.
• 요구사항 질문: 실시간성? 정확도? 기간? 범위?
• 핵심 품질 속성: Latency / Throughput / Cost
• 1차 아키텍처: Event Ingest → Aggregator → Cache
• 데이터 모델: 카운터/랭킹 구조
• 병목 + 확장:
  • 집계 연산 → 스트리밍/배치 분리
  • 핫키 → 파티션 분산
• 장애 시나리오:
  • 캐시 만료 → TTL 완화
  • 집계 지연 → 이전 결과 사용
• 면접관 한 문장: “랭킹은 근사치를 허용합니다.”
• 흔한 실수: 매 요청 실시간 계산 / 강한 일관성 요구

---

5) 비디오 공유

결론: 이 문제의 핵심은 ‘대역폭과 저장 비용’이다.

• 문제 재정의: 대용량 비디오를 전 세계에 전달한다.
• 요구사항 질문: 업로드/시청 비율? 해상도? 지역 분포?
• 핵심 품질 속성: Availability / Throughput / Cost
• 1차 아키텍처: Upload API → Storage → CDN
• 데이터 모델: 메타데이터(RDB) + 오브젝트 스토리지
• 병목 + 확장:
  • 업로드 지연 → 비동기 처리
  • 전송 비용 → CDN
• 장애 시나리오:
  • 스토리지 장애 → 복제
  • CDN 미스 → 원본 fallback
• 면접관 한 문장: “전송은 CDN, 메타데이터는 서버입니다.”
• 흔한 실수: DB에 영상 저장 / CDN 언급 없음

---

6) 검색 엔진

결론: 이 문제의 핵심은 ‘색인 비용을 감수한 조회 속도’다.

• 문제 재정의: 대규모 문서에서 관련 결과를 빠르게 찾는다.
• 요구사항 질문: 문서 수? 업데이트 빈도? 랭킹 기준?
• 핵심 품질 속성: Latency / Relevance / Scalability
• 1차 아키텍처: Crawler → Indexer → Query Service
• 데이터 모델: Inverted Index
• 병목 + 확장:
  • 색인 비용 → 배치 처리
  • 쿼리 부하 → 샤딩
• 장애 시나리오:
  • 색인 지연 → 이전 인덱스 사용
  • 노드 실패 → 리플리카
• 면접관 한 문장: “검색 성능은 색인에서 결정됩니다.”
• 흔한 실수: RDB LIKE 검색 / 랭킹 설명 없음

---

6개 문제 비교 표

문제	핵심 병목	DB 성격	캐시 필요	비동기 필요	난이도	자주 나오는 꼬리질문
URL	읽기 QPS	KV	높음	낮음	하	키 충돌?
예약	정합성	RDB	낮음	낮음	중	중복 방지?
크롤러	처리량	혼합	중	높음	중	재처리?
탑셀러	집계	KV/Stream	높음	높음	중	근사 허용?
비디오	대역폭	Object	높음	중	중상	CDN?
검색	색인	Index	중	높음	상	랭킹?

---

흔한 실수 5개 + 교정

1. 동일 템플릿 적용 → 드라이버 먼저 선언
2. 과도한 확장 설계 → 1차 아키텍처 고정
3. 병목 누락 → 최소 3개 명시
4. 장애 시나리오 없음 → 2개 이상
5. 한 문장 요약 없음 → 면접관용 문장 준비

---

면접에서 바로 쓰는 답변 문장 템플릿 8개

1. “이 문제의 핵심 병목은 ○○입니다.”
2. “그래서 이 저장소를 선택했습니다.”
3. “이 지점이 가장 먼저 터집니다.”
4. “확장은 여기서 합니다.”
5. “이 장애는 이렇게 흡수합니다.”
6. “정확성보다 속도를 택했습니다.”
7. “비용을 이만큼 감수합니다.”
8. “이 설계의 한계는 분명합니다.”

---

핵심 체크리스트 12개

1. 문제 재정의
2. 핵심 드라이버 식별
3. 요구사항 질문
4. 품질 속성 3개
5. 1차 아키텍처
6. 데이터 선택 이유
7. 병목 3개
8. 확장 전략
9. 장애 시나리오
10. 트레이드오프
11. 한 문장 요약
12. 흔한 실수 회피

---

30분 복기 플랜(타이머 기준)

• 0–5분: 6문제 핵심 드라이버 암기
• 5–10분: 문제별 한 문장 요약
• 10–15분: 병목/확장 포인트
• 15–20분: 장애 시나리오
• 20–25분: 비교 표 훑기
• 25–30분: 랜덤 1문제 구두 설명

---

한 줄 요약

모의 인터뷰의 핵심은 설계를 외우는 게 아니라, 문제마다 다른 ‘지배 요인’을 먼저 말하는 것이다.

---

• 참고: 시스템 설계 (System Design) : 한번에 인터뷰 합격하기