inflearn logo
강의

講義

知識共有

知らないと昇進できないシステムデザイン

分散システムにおける ユニークID 生成器(Unique ID Generator in Distributed System)

처음 접하는 문제에서 하이레벨 디자인의 완성도를 높이는 방법이 궁금합니다.

11

ejaebbang1448

投稿した質問数 3

0

안녕하세요, 좋은 강의 감사드립니다. 현재 해외 취업을 목표로 시스템 디자인 인터뷰를 준비 중인 수강생입니다. 낯선 문제를 만났을 때 하이레벨 디자인에서 딥다이브로 넘어가는 과정에 어려움이 있어 조언을 구하고자 합니다. 강의 시퀀스인 [요구사항 정의 -> 하이레벨 디자인 -> 딥다이브(API, 모델링 등) -> 리뷰]를 준수하며 연습하고 있으나, 익숙하지 않은 도메인에서는 하이레벨 디자인 단계에서 예외 케이스나 컴포넌트를 제대로 커버하지 못하는 경우가 많습니다. 그러다 보니 딥다이브(c)를 진행하는 도중에 설계 오류를 발견하고 다시 하이레벨(b)을 번복하게 됩니다. 처음 보는 문제에서도 하이레벨 디자인을 탄탄하게 잡고 갈 수 있는 접근법이나, 이러한 번복 플로우를 줄일 수 있는 인터뷰 팁이 있을지 여쭤보고 싶습니다.

소프트웨어-설계 시스템-디자인 소프트웨어-공학

回答 1

0

altoformula

안녕하세요 이재영님,

좋은 질문입니다.

사실 시스템 디자인 인터뷰에서는 하이레벨 디자인을 한 번에 완벽하게 맞추는 것을 기대하지 않습니다. 오히려 처음에는 70~80% 수준의 설계를 만들고, 딥다이브 과정에서 발견한 문제를 어떻게 보완하는지를 보는 경우가 많습니다.

다만 말씀하신 것처럼 익숙하지 않은 도메인에서 하이레벨 설계가 흔들리는 경우에는 몇 가지 체크리스트를 가지고 접근하면 도움이 됩니다.

제가 추천하는 방법은 하이레벨 디자인을 그리기 전에 반드시 아래 질문들을 먼저 스스로 던지는 것입니다.

  1. 데이터는 어디서 생성되는가?

  2. 읽기가 많은가, 쓰기가 많은가?

  3. 실시간성이 중요한가?

  4. 데이터 크기는 어느 정도인가?

  5. 장애가 발생하면 무엇이 가장 치명적인가?

  6. 순서(Ordering)가 중요한가?

  7. 강한 일관성(Strong Consistency)이 필요한가?

  8. 글로벌 서비스인가, 단일 리전 서비스인가?

대부분의 시스템은 결국... Client → API → Processing Layer → Storage → Cache/Search 라는 공통 패턴 안에서 움직이기 때문에, 위 질문에 대한 답만 정리해도 필요한 컴포넌트가 상당 부분 자연스럽게 드러납니다.


또 하나의 팁은 하이레벨 디자인 단계에서 "설계"보다 "리스크 목록"을 먼저 만드는 것입니다.

예를 들어 X를 설계한다고 하면

  • Fan-out 문제

  • Celebrity Problem

  • Timeline 정렬

  • Hot Partition

  • 캐시 무효화

같은 리스크를 먼저 적고 시작합니다(여기는 여러 시스템 디자인를 접해보는게 좋습니다) 그러면 하이레벨 설계가 해당 리스크들을 해결하는 방향으로 자연스럽게 발전하게 됩니다.

그리고 인터뷰 중에 딥다이브하다가 설계 오류를 발견해서 하이레벨로 다시 올라가는 것은 오히려 좋은 신호일 수 있습니다.

예를 들어 "지금까지는 단일 DB로 설명했는데, 읽기 트래픽 규모를 고려하면 이 부분은 샤딩이 필요하겠습니다." 처럼 명시적으로 수정 이유를 설명하면 인터뷰어는 "이 사람이 설계를 검증하면서 진행하는구나" 라고 받아들이는 경우가 많습니다 ㅎㅎㅎ (그래서 제 생각에는 좋은 듯)

실제 FAANG 계열 인터뷰에서도 처음 설계를 끝까지 고수하는 것보다, 새로운 정보가 나오면 설계를 업데이트하는 능력을 더 높게 평가하는 경우가 많습니다.

개인적으로는 처음 보는 문제를 만났을 때, 요구사항 → 트래픽 추정 → 병목 예상 → 리스크 목록 작성 → 하이레벨 디자인 순서로 접근하는 연습을 추천드립니다.

하이레벨 디자인은 결국 "컴포넌트를 그리는 과정"이 아니라 "어떤 리스크를 해결할 것인가를 표현하는 과정"에 가깝기 때문에, 리스크를 먼저 찾는 습관이 생기면 익숙하지 않은 도메인에서도 훨씬 안정적으로 설계할 수 있게 됩니다.

그리고 너무 걱정하지 않으셔도 되는 부분이, 시스템 디자인 인터뷰를 많이 본 지원자들의 공통적인 성장 포인트가 바로 말씀하신 "딥다이브하다가 하이레벨을 수정하는 경험"입니다. 그 과정을 반복하면서 처음 보는 문제도 점점 더 빠르게 구조화할 수 있게 됩니다. 🙂

Design a Toast Notification System 미션 관련 질문드립니다.

0

36

1

아주 작은 정오표 전달드립니다.

0

52

2

실제로 작은 기업에서 기획 롤

1

26

1

강의자료가 누락됐어요

0

73

2

order_product 까마귀발

0

44

2

공통 코드 , 계층 구조 질문

1

38

1

OEM에서 하는 A-SPICE

0

39

2

[DB설계] 탈퇴 유저의 구독 정보 유지 및 이메일 마스킹 관련 질문입니다.

0

53

1

자연키 vs 대리키 실무질문

0

28

1

1:N 관계에서 중간테이블 (연관엔티티)

0

57

2

공통코드 관련한 질문 드립니다.

0

74

1

차단 등 검증 로직의 위치

0

66

2

SP를 아직도 사용하나요?

0

60

2

캐시전략 - Write-behind

0

52

2

일대일 fk 위치

0

43

1

websocket 연결 질문

0

76

1

채팅 시스템 메시지 플로어 질문드립니다

0

92

1

시니어엔지니어 지원

0

104

1

시스템 디자인 2권이나 머신러닝에 대한 계획

0

163

1

강의자료 어디서 받나요?

0

129

1

화면이 보이는 강의가 있고 안보이는 강의가 있어요?

1

222

2

수정사항 제보

1

230

3

채팅 시스템 key value 관련 질문이 있습니다!

0

287

1

강의 계획 관련

2

363

2