📖
Aaron's TECH BOOK
  • Intro
    • About me
  • Lecture
    • Kubernetes
      • Begin Kubernetes
    • Kafka
      • Begin Kafka
    • Kotlin
      • TDD, Clean Code Preview
      • woowa Kotlin
    • Java
      • Multithread Concurrency
      • The Java
    • Toby
      • Toby Spring 6
      • Toby Spring Boot
    • MSA
      • 01.Micro Service
      • 02.DDD 설계
      • 03.DDD 구현
      • 04.EDA 구현
    • Spring Boot
    • Spring Batch
    • Spring Core Advanced
    • Spring DB Part II
    • Spring DB Part I
    • JPA API and Performance Optimization
    • JPA Web Application
    • JPA Programming Basic
    • Spring MVC Part 2
      • 01.Thymeleaf
      • 02.ETC
      • 03.Validation
      • 04.Login
      • 05.Exception
    • Spring MVC Part 1
      • 01.Servlet
      • 02.MVC
    • Http
      • 01.Basic
      • 02.Method
      • 03.Header
    • Spring Core
    • Study
      • Concurrency issues
      • First Come First Served
      • Performance Test
      • TDD
      • IntelliJ
  • Book
    • Kafka Streams in Action
      • 01.카프카 스트림즈
      • 02.카프카 스트림즈 개발
      • 03.카프카 스트림즈 관리
    • Effective Kotlin
      • 01.좋은 코드
      • 02.코드 설계
      • 03.효율성
    • 이벤트 소싱과 MSA
      • 01.도메인 주도 설계
      • 02.객체지향 설계 원칙
      • 03-04.이벤트 소싱
      • 05.마이크로서비스 협업
      • 06.결과적 일관성
      • 07.CQRS
      • 08.UI
      • 09.클라우드 환경
    • 몽고DB 완벽 가이드
      • I. 몽고DB 시작
      • II. 몽고DB 개발
    • Kotlin Cookbook
      • 코틀린 기초
      • 코틀린 기능
      • ETC
    • Kotlin in Action
      • 함수/클래스/객체/인터페이스
      • 람다와 타입
      • 오버로딩과 고차 함수
      • 제네릭스, 애노테이션, 리플렉션
    • Kent Beck Tidy First?
    • 대규모 시스템 설계 기초
      • 01.사용자 수에 따른 규모 확장성
      • 02.개략적인 규모 추정
      • 03.시스템 설계 공략법
      • 04.처리율 제한 장치 설계
      • 05.안정 해시 설계
      • 06.키-값 저장소 설계
      • 07.유일 ID 생성기 설계
      • 08.URL 단축기 설계
      • 09.웹 크롤러 설계
      • 10.알림 시스템 설계
      • 11.뉴스 피드 시스템 설계
      • 12.채팅 시스템 설계
      • 13.검색어 자동완성 시스템
      • 14.유튜브 설계
      • 15.구글 드라이브 설계
      • 16.배움은 계속된다
    • 실용주의 프로그래머📖
    • GoF Design Patterns
    • 도메인 주도 개발 시작하기
      • 01.도메인 모델 시작하기
      • 02.아키텍처 개요
      • 03.애그리거트
      • 04.리포지터리와 모델 구현
      • 05.Spring Data JPA를 이용한 조회 기능
      • 06.응용 서비스와 표현 영역
      • 07.도메인 서비스
      • 08.애그리거트 트랜잭션 관리
      • 09.도메인 모델과 바운디드 컨텍스트
      • 10.이벤트
      • 11.CQRS
    • Effective Java 3/E
      • 객체, 공통 메서드
      • 클래스, 인터페이스, 제네릭
    • 소프트웨어 장인
    • 함께 자라기
    • Modern Java In Action
      • 01.기초
      • 02.함수형 데이터 처리
      • 03.스트림과 람다를 이용한 효과적 프로그래밍
      • 04.매일 자바와 함께
    • Refactoring
      • 01.리펙터링 첫 번째 예시
      • 02.리펙터링 원칙
      • 03.코드에서 나는 악취
      • 06.기본적인 리펙터링
      • 07.캡슐화
      • 08.기능 이동
      • 09.데이터 조직화
      • 10.조건부 로직 간소화
      • 11.API 리팩터링
      • 12.상속 다루기
    • 객체지향의 사실과 오해
      • 01.협력하는 객체들의 공동체
      • 02.이상한 나라의 객체
      • 03.타입과 추상화
      • 04.역할, 책임, 협력
      • 05.책임과 메시지
      • 06.객체 지도
      • 07.함께 모으기
      • 부록.추상화 기법
    • Clean Code
    • 자바 ORM 표준 JPA 프로그래밍
Powered by GitBook
On this page
  • 4단계 접근법
  • 1단계: 문제 이해 및 설계 범위 확정
  • 2단계: 개략적인 설계안 제시 및 동의 구하기
  • 3단계: 상세 설계
  • 4단계: 마무리
  1. Book
  2. 대규모 시스템 설계 기초

03.시스템 설계 공략법

대규모 시스템 설계 기초 3장을 요약한 내용입니다.

시스템 설계 면접은 두 명의 동료가 모호한 문제를 풀기 위해 협력하여 그 해결책을 찾아내는 과정에 대한 시뮬레이션이다.

  • 정해진 결말도, 정답도 없다.

  • 설계 기술을 시연하고, 설계 과정에서 내린 결정들에 대한 방어 능력을 보이고, 피드백을 건설적인 방식으로 처리할 자질을 보이는 자리다.

시스템 설계 면접은 설계 능력의 기술적 측면을 평가하는 것 뿐만 아니라, 협력에 적합한 사람인지, 압박이 심한 상황도 잘 헤쳐 나갈 자질이 있는지, 모호한 문제를 건설적으로 해결할 능력이 있는지, 좋은 질문을 던질 능력이 있는지 등을 살펴보는 자리다.

부정적 신호도 놓치면 안 된다. 설계의 순수성(purity)에 집착한 나머지 타협적 결정(tradeoff)을 도외시하고 과도한 엔지니어링(over-engineering)으로 시스템 전반의 비용이 올라갈 수 있다. 완고함, 편협함도 부정적인 신호에 포함된다.

4단계 접근법

시스템 설계 면접에서 절차나 범위에는 공통적인 부분이 있다.

1단계: 문제 이해 및 설계 범위 확정

시스템 설계 면접에서 생각 없이 바로 답을 내서는 좋은 점수를 받기 어렵다.

  • 요구사항을 완전히 이해하지 않고 답을 내놓는 행위는 엄청난 부정적 신호다.

  • 바로 답부터 들이밀지 말고, 속도를 늦추자.

  • 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 하라.

엔지니어가 가져야 할 가장 중요한 기술 중 하나는 올바른 질문을 하는 것, 적절한 가정을 하는 것, 시스템 구축에 필요한 정보를 모으는 것이다.

요구사항을 정확히 이해하는 데 필요한 질문들

  • 구체적으로 어떤 기능들을 만들어야 하나❓

  • 제품 사용자 수는 얼마나 되나❓

  • 회사 규모는 얼마나 빨리 커리리라 예상하나? 석 달, 여섯 달, 일년 뒤의 규모는❓

  • 회사가 주로 사용하는 기술 스택은 무엇인가❓

  • 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것을이 있는가❓

요구사항을 이해하고 모호함을 없애는 게 이 단계에서 가장 중요하다.

2단계: 개략적인 설계안 제시 및 동의 구하기

개략적인 설계안을 제시하고 면접관의 동의를 얻는 단계. 면접관과 협력하며 진행하면 좋다.

.

✅ 설계안에 대한 최초 청사진을 제시하고 의견을 구하자.

  • 면접관을 팀원처럼 대하자. 훌륭한 면접관들은 지원자들과 대화하고 설계 과정에 개입하기를 즐긴다.

✅ 화이트보드나 종이에 핵심 컴포넌트를 포함하는 다이어그램을 그리자.

  • 클라이언트(MW, WEB), API, 웹 서버, 데이터 저장소, 캐시, CDN, 메시지 큐 등이 포함

✅ 이 최초 설계안이 시스템 규모에 관계된 제약사항들을 만족하는지를 개략적으로 계산하자.

  • 계산 과정은 소리 내어 설명하자. 개략적인 추청이 필요한지는 면접관에게 미리 물어보자.

✅ 가능하다면 시스템의 구체적 사용 사례도 몇 가지 살펴보자.

  • 고려하지 못한 에지 케이스(edge case)를 발견하는 데도 도움이 될 것이다.

.

예제

뉴스 피드 시스템을 설계를 계략적으로 보면 두 가지 처리 플로(flow)로 나눠 생각해 볼 수 있다.

  • 피드 발행(feed publishing): 사용자가 포스트를 올리면 관련된 데이터가 캐시/데이터베이스에 기록되고, 해당 사용자의 친구 뉴스 피드에 노출

  • 피드 생성(feed building): 어떤 사용자의 뉴스 피드는 해당 사용자 친구들의 포스트를 시간 역순(최신 포스터부터)으로 정렬하여 생성

피드 발행과 피드 생성 플로를 각각 개략적으로 그린 예시

3단계: 상세 설계

이 단계로 왔다면 면접관과 아래 목표는 달성한 상태일 것이다.

  • 시스템에서 전반적으로 달성해야 할 목표와 기능 범위 확인

  • 전체 설계의 개략적 청사진 마련

  • 해당 청사진에 대한 면접관의 의견 청취

  • 상세 설계에서 집중해야 할 영역들 확인

이제 해야 할 일은 설계 대상 컴포넌트 사이의 우선순위를 정하는 것이다.

  • 매번 다르겠지만, 대부분 면접관은 특정 시스템 컴포넌트들의 세부사항을 깊이 있게 설명하는 것을 보길 원한다.

    • 단축 URL 생성기 설계라면 그 해시 함수의 구체적인 설계를 설명하거나, 채팅 시스템 설계라면 지연시간을 어떻게 줄이고 사용자의 온/오프라인 상태를 표시할 것인지

  • 면접 시 시간 관리에도 특별한 주의가 필요하다.

    • 긍정적 신호를 전달하는데 집중하자.

    • 불필요한 세부 사항에 시간을 쓰지 말고, 능력을 보일 기회를 놓치지 말자.

.

예제

뉴스 피드 시스템의 개략적 설계를 마친 상황이라면 아래 중요한 용례를 보다 깊이 탐구해야 한다.

  • 피드 발행

  • 뉴스 피드 가져오기

피드 발행 상세 설계 예시

뉴스 피드 가져오기 상세 설계 예시

4단계: 마무리

마지막 단계에서 면접관은 설계 결과물에 관련된 몇 가지 후속 질문을 던질 수 있고(follow-up questions) 스스로 추가 논의를 진행하도록 할 수 있다.

✅ 시스템 병목구간, 혹은 좀 더 개선 가능한 지점을 찾아내라는 주문을 받을 수 있다.

  • 개선할 점은 언제나 있게 마련이다. 비판적 사고 능력을 보이고, 마지막으로 좋은 인상을 남길 수 있다.

✅ 만든 설계를 한번 다시 요약해 주자.

  • 기억을 환기시켜주는 효과가 있다.

✅ 오류(서버 오류, 네트워크 장애 등)가 발생하면 무슨 일이 생기는지 따져보면 흥미로울 것이다.

✅ 운영 이슈도 논의할 가치가 충분하다.

  • 메트릭은 어떻게 수집하고 모니터링할 것인가? 로그는? 시스템은 어떻게 배포해 나갈 것인가?

✅ 미래에 닥칠 규모 확장 요구에 어떻게 대처할 것인지도 흥미로운 주제다.

✅ 시간이 남았다면 필요하지만 다루지 못했던 세부적 개선사항들을 제한해 보자.

.

⭕️ 해야 할 것

  • 질문을 통해 확인하라(clarification)

  • 문제의 요구사항을 이해하라.

  • 정담이나 최선의 답안 같은 것은 없다는 것을 명심하라.

  • 면접관이 사고 흐름을 이해할 수 있도록 하라. 면접관과 소통하라.

  • 가능하다면 여러 해법을 함께 제시하라.

  • 개략적 설계에 면접관이 동의하면, 각 컴포넌트의 세부사항을 설명(가자 중요한 컴포넌트부터)하기 시작하라.

  • 면접관의 아이디어를 이끌어 내라. (좋은 면접관은 같은 팀원처럼 협력)

  • 포기하지 말라.

❌ 하지 말아야 할 것

  • 전형적인 시스템 설계 문제에 대비하지 않은 상태에서 면접장에 가지 말라.

  • 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말라.

  • 처음부터 특정 컴포넌트의 세부사항을 너무 싶이 설명하지 말라. (개략적 설계를 마친 뒤 세부사항으로)

  • 진행 중에 막혔다면, 힌트를 청하기를 주저하지 말라.

  • 소통을 주저하지 말라.

  • 설계안을 내놓는 순간 면접이 끝난다고 생각하지 말라. (끝났다고 말하기 전까지 끝난게 아니다)

.

시간 배분

  • 시스템 설계 면접은 모통 매우 광범위한 영역을 다루며 45분 혹은 한 시간은 충분하지 않을 수 있다. 따라서, 시간 관리를 잘 하는 것이 중요하다.

  • 45분의 시간이 주어진다면 시간 분배는 대략적으로 아래와 같이 해볼 수 있다.

    • 1단계: 문제 이해 및 설계 범위 확정 (3~10분)

    • 2단계: 개략적 설계안 제시 및 동의 구하기 (10~15분)

    • 3단계: 상세 설계 (10~25분)

    • 4단계: 마무리 (3~5분)

Last updated 1 year ago