• 면접관이 보고자 하는 것은 지원자의 설계 능력 기술뿐만 아니라 협력과 압박에 강한지에 대해서이다.
• 시스템 설계는 아래 4단계에 걸쳐서 진행하면 된다

1. 문제 이해 및 설계 범위 확장

• 구상하려는 서비스 관련 정보를 수집하고 어떤 가정에 대해서 고려해야 한다. 따라서 아래와 같은 정보를 수집하는 것이 중요하다
  1. 구체적으로 어떤 기능이 있는가 ( 서비스 설계를 위한 정보 )
  2. 사용자 수는 얼마나 되는가 ( 트래픽 고려를 위한 정보 )
  3. 회사의 규모가 얼마나 빠르게 커지리라 예측하는가?
  4. 회사가 주로 사용하는 기술 스택은 무엇이 있는가? 설계 단순화를 위해 사용할 수 있는 기존 서비스는 어떤 것이 있는가
  5. 메세징 서비스라면 미디어 파일 유무

2. 개략적인 설계안 제시

• 면접관이 마치 팀인 것처럼 설계안에 대해 의견을 물어도 된다.
• 클라이언트, API, 데이터 저장소 등이 포함된 다이어그램을 그려라.
• 최초 설계안이 서비스의 규모 등의 요구사항에 부합하는지 개략적으로 계산하라
  • 기존의 개략적 규모 추정 방식과 응답 지연시간을 확인해라
• API 엔드포인트나 데이터베이스 스키마 등은 작은 규모의 서비스에서는 어느정도 구상하는 것이 좋다.

⇒ 이러한 개략적 설계안은 미처 고려하지 못한 에지 케이스를 발견하는데 도움이 된다.

3. 상세 설계

상세 설계를 하기 전 위 단계에서 아래 목표들을 달성한 상태이어야 한다.

1. 시스템 전반적으로 달성해야 하는 목표와 기능 범위
2. 전체 설계의 개략적 청사진
3. 해당 청사진에 대한 면접관의 의견
4. 상세 설계에서 집중해야 하는 영역들 확인
   • 카카오톡이면 메세지 생산 / 발행이 있을 것이다.

• 면접관들은 특정 시스템 컴포넌트의 세부 사항을 깊이 있게 보고 싶어 한다.

  • 단축 URL 생성기라면 해시 함수 설계에 대한 구체적 설명을 원할 것이다.

  • 채팅 서비스라면 사용자 온/오프라인 상태 확인 방법과 지연 시간 감소 방안에 대한 설명을 원할 것이다.

    ⇒ 포스팅 캐시로 데이터 캐싱해서 DB 접근을 줄이고, 메세지 큐를 통해서 발행-소비 구조 구축하는 방법을 사용할 수 있을 것이다. 사용자 온라인 여부는 Redis와 같은 데이터 저장소를 사용할 수 있을 것이다.

• 추가적으로 세부 사항을 설명하되, 불필요한 부분에 시간을 투자하는 것은 지양하는 것이 좋다.

  • 가령, 페이스북 뉴스 피드 순위 알고리즘을 설명하는 것은 시간을 너무 많이 잡아먹기도 하고 규모 확장 가능한 시스템 설계 능력을 보이기에 바람직하지 않다.

4. 마무리

• 시스템 병목 구간이나 개선 사항에 대한 고려가 필요하다. 완벽한 서비스 설계는 없기에 이 부분에 대한 고민은 필수적이다.
• 서비스 전체 설계를 요약해주는 것은 관련 기억 환기에 도움이 될 것이다.