그 전에 2장 '개략적인 규모 측정'을 정리하자.

개략적인 규모 측정

"개략적인 규모 추정"은 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것"이다.

개략적인 규모 측정을 위해서는 2의 제곱수, 응답지연 값, 고가용성에 대해 알고있어야 한다.

최근 기술 도향이 반영된 응답 지연 값에서 알 수 있는 사실은 다음과 같다.

• 메모리는 빠르지만 디스크는 아직도 느리다.
• 디스크 탐색은 최대한 피하라
• 단순한 암축 알고리즘은 빠르다.
• 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라
• 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다.

시스템 설계 면접 공략법

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

• 요구사항을 완전히 이해하지 않고 답을 내놓는 행위는 아주 엄청난 부정적 신호다. 면접은 퀴즈 쇼가 아니며, 정답 따위는 없다는 걸 상기하자.
• 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 하라.
• 이 단계에서 나올만한 질문들의 예시는 다음과 같다. (면접자 to 면접관)
  - 구체적으로 어떤 기능들을 만들어야 하나?
  - 제품 사용자 수는 얼마나 되나?
  - 회사의 규모는 얼마나 빨리 커지리라 예상하나?

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

이 단계에서 초점을 맞추어야 할 것은 개략적인 설계안을 제시하고 면접관의 동의를 얻는 것이다.

• 설계안에 대한 최초 청사진을 제시하고 의견을 구하라.
• 화이트보드나 종이에 핵심 컴포넌트를 포함하는 다이어그램을 그려라.
• 이 최초 설계안이 시스템 규모에 관계된 제약사항들을 만족하는지를 개략적으로 계산해보라.

3단계 상세 설계

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

• 시스템의 병목 구간이나 자원 요구량 추정치에 초점이 맞춰져있을 수 있다.
• 단축 URL 생성기라면 해시 함수의 설계를, 채팅 시스템이라면 지연시간을 줄이고 사용자의 온/오프라인 상태를 표시할 것인지를 듣고자 할 것이다.

4단계 마무리

해야 할 것

• 질문을 통해 확인하라. 스스로 내린 가정이 옳다 믿고 진행하지 마라.
• 문제의 요구사항을 이해하라.
• 정답이나 최선의 답안 같은 것은 없다는 걸 명심하라.
• 면접관이 여러분의 사고 흐름을 이해할 수 있도록 하라. (최대한 얘기하면서, 말 많이 하면서 설계하라)
  하지 말아야 하는 것
• 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 마라.
• 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하지 말라.
• 진행 중에 막혔다면, 힌트를 청하기를 주저하지 말라.
• 다시 말하지만, 소통을 주저하지 말라. 침묵 속에 설계를 진행하지 마라.

번외

Graph DB

1. 그래프 DB란?

그래프 데이터베이스는 데이터와 데이터 간의 관계(연결) 를 최우선으로 관리하는 데이터베이스이다.

전통적인 관계형 데이터베이스(RDB)는 테이블, 행(Row), 열(Column) 구조로 데이터를 저장하지만, 그래프 DB는 다음과 같은 그래프 구조를 사용한다.

• 노드(Node): 개체(Entity)를 나타냄 (예: 사람, 제품, 도시 등)
  
• 엣지(Edge / Relationship): 노드 간의 관계를 나타냄 (예: “친구다”, “구매했다”, “연결되어 있다”)
  
• 속성(Property): 노드나 엣지에 붙는 추가 정보 (예: 사람 노드 → 이름, 나이 / 관계 엣지 → 시작일, 친밀도 등)
  

즉, 그래프 DB는 데이터 그 자체뿐만 아니라 데이터 간의 연결성을 1급 객체로 다룬다는 점이 핵심

2. 왜 그래프 DB를 쓸까?

관계형 DB에서도 JOIN을 사용해 관계를 표현할 수 있지만, 관계가 깊어질수록 성능이 급격히 나빠진다.

그래프 DB는 이런 경우에 관계 탐색을 효율적으로 수행한다.

• 소셜 네트워크 분석
  예: “이 사람의 친구의 친구 중에 같이 일한 적 있는 사람?” → RDB에서는 여러 번 JOIN 필요, 그래프 DB에서는 관계 탐색만으로 빠르게 해결.
  
• 추천 시스템
  예: “내가 본 영화와 비슷한 영화를 본 사람들의 다른 취향”
  
• 네트워크/경로 탐색
  예: “서울에서 부산까지 가장 빠른 경로는?” → 도로 네트워크를 그래프로 표현.
  

3. 장점

• 복잡한 관계 쿼리에 강함: 관계형 DB보다 JOIN 비용이 훨씬 적음.
  
• 직관적인 데이터 모델: 실제 관계를 그래프 구조로 시각화 가능.
  
• 확장성: 관계가 많은 데이터를 다루기에 적합.
  

4. 단점

• 트랜잭션/집계 연산은 RDB보다 약한 경우 많음.
  
• 표준화 부족: SQL처럼 범용 표준 쿼리 언어가 없음 (대신 Cypher, Gremlin 같은 언어 사용).
  
• 특정 도메인에 특화됨: 모든 데이터를 그래프로 표현하는 건 적합하지 않을 수 있음.
  

5. 대표적인 그래프 DB

• Neo4j: 가장 유명한 그래프 DB, Cypher 쿼리 언어 사용.
  
• Amazon Neptune: AWS에서 제공하는 관리형 그래프 DB.
  
• OrientDB, ArangoDB: 멀티 모델 DB로 그래프 기능 포함.
  
• JanusGraph: 대규모 분산 그래프 DB.**