시스템 설계 답변 프레임 Q&A (가정 분리 → 측정 → 대응 우선순위)

Q1. 시스템 설계 질문에서 답변이 퍼집니다. 어떻게 고정하죠?

답변

시스템 설계 면접에서 가장 위험한 패턴은 “일단 Redis를 붙이고, Kafka를 붙이고, 샤딩한다"처럼 솔루션 이름부터 나열하는 것입니다. 면접관은 특정 기술명을 맞히는지보다 문제를 어떻게 좁히고, 어떤 근거로 선택하는지를 봅니다. 그래서 답변은 아래 5단 프레임으로 고정하는 편이 안전합니다.

1. 목표 재확인: 지금 설계가 최적화해야 하는 것은 처리량, 지연시간, 비용, 정합성, 운영 안정성 중 무엇인지 확인합니다.
2. 가정 분리: 트래픽 규모, 읽기/쓰기 비율, 데이터 크기, SLA, 장애 허용 범위, 예산을 숫자로 둡니다.
3. 핵심 경로 식별: 사용자가 체감하는 요청 경로와 내부 비동기 경로를 나눕니다.
4. 측정 지표 선언: p95/p99 latency, error rate, QPS, DB CPU, cache hit ratio, queue lag처럼 판단 기준이 되는 지표를 먼저 둡니다.
5. 대응 우선순위 제시: 저비용 개선 → 병목 제거 → 구조 분리 → 수평 확장 순서로 말합니다.

이 프레임을 쓰면 질문이 “URL Shortener를 설계해 보세요"든 “주문 시스템을 설계해 보세요"든 답변의 뼈대가 유지됩니다. 중요한 것은 초반 30초 안에 “무엇을 최적화할지"를 잠그는 것입니다.

Q2. 가정은 어느 정도 숫자로 잡아야 하나요?

답변

숫자는 정확한 예측이 아니라 설계 방향을 결정할 정도의 해상도면 충분합니다. 예를 들어 조회 API라면 아래처럼 말할 수 있습니다.

• DAU 100만, 피크 시간대 5만 동시 접속
• 읽기:쓰기 비율 95:5
• p95 300ms 이하, 오류율 0.1% 이하
• 데이터는 1년 보관, 최근 30일 조회가 90% 이상
• 강한 정합성이 필요한 경로와 eventual consistency가 가능한 경로를 분리

이 정도 가정이면 캐시가 필요한지, 비동기 처리가 허용되는지, DB 단일 인스턴스가 버틸지, 읽기 복제본이 필요한지 판단할 수 있습니다. 반대로 “트래픽이 많으면 캐시합니다"처럼 말하면 기준이 없어 보입니다.

면접에서는 가정을 제시한 뒤 바로 “가정이 달라지면 설계도 바뀐다"고 덧붙이는 것이 좋습니다. 예를 들어 결제 승인처럼 정합성이 핵심인 도메인은 캐시보다 트랜잭션 경계와 멱등성이 우선이고, 피드 조회처럼 읽기 부하가 큰 도메인은 캐시/사전 계산/페이지네이션 전략이 먼저입니다.

Q3. 예시: 조회 API가 느린 상황은 어떻게 답하나요?

답변

먼저 문제를 “API가 느리다"로 두지 말고 병목 후보를 분리합니다.

답변 예시는 이렇게 가져갈 수 있습니다.

“먼저 p95 지연이 DB, 애플리케이션, 외부 의존성 중 어디서 발생하는지 분리하겠습니다. SQL 로그와 APM으로 query count, slow query, DB CPU를 확인하고, 풀스캔이면 인덱스/쿼리를 먼저 고칩니다. 읽기 비중이 높고 데이터 변경이 적다면 cache-aside를 적용하되 TTL, 무효화, stampede 방지까지 같이 설계합니다. 그래도 읽기 부하가 크면 CQRS 형태의 읽기 모델이나 리드 레플리카를 검토하겠습니다.”

이 답변의 장점은 기술 선택이 원인과 연결된다는 점입니다. Redis, replica, CQRS를 모두 언급하더라도 “왜 지금 필요한지"가 보입니다.

Q4. 설계 답변에서 트레이드오프는 어떻게 말하나요?

답변

트레이드오프는 기술의 단점 목록이 아니라 선택 기준입니다. 아래처럼 한 문장으로 정리하면 좋습니다.

• 캐시: 지연시간과 DB 부하는 줄지만, 무효화/정합성/스탬피드 운영 부담이 생깁니다.
• 비동기 큐: 사용자 응답은 빨라지지만, 처리 지연·중복 처리·DLQ 운영이 필요합니다.
• 샤딩: 쓰기 확장은 가능하지만, 조인/트랜잭션/리샤딩 비용이 커집니다.
• 리드 레플리카: 읽기 확장은 쉽지만, replication lag로 read-your-writes 문제가 생길 수 있습니다.
• 마이크로서비스 분리: 팀 독립성은 올라가지만, 네트워크 장애·분산 트랜잭션·관측 복잡도가 증가합니다.

좋은 답변은 “그래서 저는 언제 적용하겠다"까지 붙습니다. 예를 들어 “p95가 목표를 초과하고 DB CPU가 포화이며, 쿼리 최적화 후에도 읽기 부하가 대부분이면 캐시를 검토하겠습니다"처럼 조건을 말하면 실무 판단처럼 들립니다.

Q5. 꼬리질문: 장애가 나면 어떻게 복구하나요?

답변

시스템 설계 면접에서 장애 대응은 가산점이 큽니다. 설계가 그럴듯해도 운영 시나리오가 없으면 미완성처럼 보입니다. 답변에는 최소한 아래 4가지를 넣으세요.

1. 감지: SLI/SLO, 알림 기준, 로그/트레이스/메트릭 위치
2. 완화: rate limit, circuit breaker, fallback, degraded mode
3. 복구: 재처리, DLQ replay, 데이터 보정, 캐시 warm-up
4. 재발 방지: runbook, postmortem, 테스트/알림 보강

예를 들어 큐 기반 주문 후처리라면 “consumer lag가 임계치를 넘으면 알림을 보내고, producer rate limit 또는 작업 우선순위 조정을 적용합니다. 중복 처리는 idempotency key로 막고, 실패 메시지는 DLQ로 보낸 뒤 원인 수정 후 replay합니다"라고 답할 수 있습니다.

Q6. 1분 답변 템플릿은 어떻게 만들면 좋나요?

답변

아래 템플릿을 그대로 외워두면 다양한 질문에 적용할 수 있습니다.

“먼저 요구사항과 SLA를 확인해 읽기/쓰기 비율, 정합성 수준, 피크 트래픽을 가정하겠습니다. 그다음 핵심 요청 경로를 나누고 p95 latency, error rate, DB/캐시/큐 지표로 병목을 측정합니다. 초기에는 인덱스·쿼리·페이징 같은 저비용 개선부터 적용하고, 한계가 보이면 캐시, 비동기 큐, 읽기 모델 분리, 수평 확장을 단계적으로 검토하겠습니다. 각 선택은 정합성, 운영 복잡도, 비용의 트레이드오프가 있으므로 장애 대응과 롤백 방법까지 함께 설계하겠습니다.”

핵심은 “단계적으로"입니다. 처음부터 대규모 아키텍처를 제시하면 과설계로 보일 수 있습니다. 작은 시스템이 커질 때 어떤 신호에서 다음 단계로 넘어가는지 설명해야 합니다.

면접 전 체크리스트

• 첫 문장에서 목표/SLA를 확인했는가?
• 트래픽·데이터·정합성 가정을 숫자로 말했다는가?
• 핵심 경로와 비동기 경로를 분리했는가?
• 지표 없이 기술명을 나열하지 않았는가?
• 각 기술 선택의 트레이드오프를 1개 이상 말했다는가?
• 장애 감지·완화·복구·재발 방지 흐름을 언급했는가?
• “가정이 달라지면 설계도 바뀐다"는 유연성을 보여줬는가?

흔한 실수

• 정답형 답변: “무조건 Kafka를 씁니다"처럼 조건 없이 말한다.
• 과설계: 작은 서비스에도 샤딩, 멀티 리전, 이벤트 소싱을 한 번에 붙인다.
• 운영 누락: 배포, 모니터링, 롤백, 데이터 보정 방법을 말하지 않는다.
• 정합성 혼동: 강한 정합성이 필요한 쓰기 경로와 eventual consistency가 가능한 읽기 경로를 섞는다.
• 측정 부재: p95, error rate, lag 같은 지표 없이 감으로 개선안을 고른다.

요약

• 설계 면접은 정답 맞히기가 아니라 사고 과정 검증이다.
• 가정 → 지표 → 병목 → 단계적 대응 → 트레이드오프 순서로 말하면 꼬리질문에서도 흔들리지 않는다.
• 기술명보다 “언제, 왜, 어떤 신호에서 적용하는가"를 말해야 실무형 답변이 된다.

다음 글

• DB 병목 대응 순서 Q&A
• JPA 성능 면접 Q&A
• API 성능 Q&A