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

  • 이 문제에는 정해진 결말, 정답이 없다.
    • 최종적으로 도출될 설계안은 우리가 설계 과정에 들인 노력에 비하면 그다지 중요하지 않다.

  • 많은 사람들이 시스템 설계 면접은 지원자의 설계 능력과 기술적 측면을 평가하는 자리라고 생각하지만, 사실 그 이상이다!
    • 지원자가 협력에 적합한 사람인지,
    • 압박이 심한 상황도 잘 헤쳐 나갈 자질이 있는지,
    • 모호한 문제를 건설적으로 해결할 능력이 있는지를 살펴본다.


효과적 면접을 위한 4단계 접근법


시스템 설계 면접은 전부 제각각이고 정답도 없지만, 절차나 범위에는 공통적인 부분이 있다.


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


  • 시스템 설계 면접을 볼 때는 생각 없이 바로 답을 내서는 좋은 점수를 받기 어렵다.
    • 깊이 생각하고, 질문하여 요구사항과 가정들을 분명히 해야 한다.
    • 중요한 건 올바른 질문을 하는 것, 적절한 가정을 하는 것, 시스템 구축에 필요한 정보를 모으는 것이다.

그렇다면 어떤 질문을 해야 할까?

  • 구체적으로 어떤 기능들을 만들어야 하나?
  • 제품 사용자 수는 얼마나 되나?
  • 회사의 규모는 얼마나 빨리 커지지라 예상하나?
  • 회사가 주로 사용하는 기술 스택은 무엇인가?
  • 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가?

예시 → 뉴스 피드 시스템 설계

  • 지원자

    • 모바일 앱과 웹 앱 가운데 어느 쪽을 지원해야 하나요?
  • 면접관

    • 둘 다 지원해야 합니다.
  • 지원자

    • 가장 중요한 기능은 무엇인가요?
  • 면접관

    • 새로운 포스트를 올리고, 다른 친구의 뉴스 피드를 볼 수 있도록 하는 기능입니다.
  • 지원자

    • 뉴스 피드는 시간 역순으로 정렬되어야 하나요?
    • 묻는 이유는, 피드에 올라갈 포스트마다 다른 가중치가 부여되어야 하는지 알고 싶어서 입니다.
  • 면접관

    • 문제를 단순하게 하기 위해, 일단 시간 역순으로 정렬된다고 가정합니다.
  • 지원자

    • 한 사용자는 최대 몇 명의 사용자와 친구를 맺을 수 있나요?
  • 면접관

    • 5000명입니다.
  • 지원자

    • 사이트로 오는 트래픽 규모는 어느 정도 입니까?
  • 면접관

    • 일간 능동 사용자(DAU)는 천만 명입니다.
  • 지원자

    • 피드에 이미지나 비디오도 올라올 수 있나요?
  • 면접관

    • 이미지나 비디오 같은 미디어 파일도 포스트할 수 있어야 합니다.

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


이번 단계에서는 개략적인 설계안을 제시하고, 면접관의 동의를 얻는 것에 초점을 맞춘다.

  • 설계안에 대한 최초 청사진을 제시하고, 의견을 구하라.
    • 면접관을 마치 팀원인 것처럼 대하라.
    • 훌륭한 면접관들은 지원자들과 대화하고 설계 과정에 개입하기를 즐긴다.

  • 화이트보드나 종이에 핵심 컴포넌트를 포함하는 다이어그램을 그려라.
    • 클라이언트, API, 웹 서버, 데이터 저장소, 캐시, CDN, 메시지 큐 등..

  • 최초 설계안에 시스템 규모에 관계된 제약사항들을 만족하는지를 개략적으로 계산해봐라.
    • 가능하다면 시스템의 구체적 사용 사례도 몇 가지 살펴보자.
    • 미처 고려하지 못한 에지 케이스(edge case)를 발견하는 데도 도움이 된다.

예시 → 뉴스 피드 시스템 설계

  • 이 설계는 두 가지 처리 플로우로 나눠 생각해 볼 수 있다!
    • 피드 발행
    • 피드 생성

  • 피드 발행
    • 사용자가 포스트를 올리면 관련된 데이터가 캐시/데이터베이스에 기록되고, 해당 사용자의 친구 뉴스 피드에 뜨게 된다.

  • 피드 생성
    • 어떤 사용자의 뉴스 피드는 해당 사용자 친구들의 포스트를 시간 역순으로 정렬하여 만든다.


3단계: 상세 설계


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

  • 특히 선임급 개발자 면접이라면, 시스템의 성능 특성에 대한 질문을 던질 것이다.
    • 그 경우 질문 내용은 시스템의 병목 구간이나, 자원 요구량 추정치에 초점이 맞춰져 있을 것이다.
    • 대부분의 경우, 면접관은 우리가 특정 시스템 컴포넌트들의 세부사항을 깊이 있게 설명하는 것을 보길 원한다.

  • ex) 단축 URI 생성기
    • 해시 함수의 설계를 구체적으로 설명하는 것

  • ex) 채팅 시스템
    • 지연시간을 줄이고, 사용자의 온/오프라인 상태를 표시하는 것

면접 시에는 시간 관리에도 특별히 주의를 기울여야 한다.

  • 면접관에게 긍정적 신호를 전달하는 데 집중해야 한다.
    • 불필요한 세부사항에 시간을 쓰지 말자!

예시 → 뉴스 피드 시스템 설계

  • 뉴스 피드 시스템의 개략적 설계를 마친 상황이라고 가정한다.
    • 이제 두 가지 중요한 용례를 보다 깊이 탐구해야 한다.

  1. 피드 발행


  1. 뉴스 피드 가져오기


4단계: 마무리


면접관은 설계 결과물에 관련된 몇 가지 후속 질문을 던질 수도 있고, 추가 논의를 진행하도록 할 수도 있다.

  • 면접관이 시스템 병목구간, 혹은 좀 더 개선 가능한 지점을 찾아내라 주문할 수 있다.

    • 거기에 대고 설계가 완벽하다거나, 개선할 부분이 없다는 답은 하지 말자!
  • 우리가 만든 설계를 다시 한번 요약해주는 것도 도움이 될 수 있다.

    • 여러 해결책을 제시한 경우에는 특히 중요하다.
  • 오류가 발생하면 무슨 일이 생기는지 따져보면 흥미로울 것이다.

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

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

  • 시간이 좀 남았다면, 필요하지만 다루지 못했던 세부적 개선사항들을 제안할 수 있다.


해야 할 것


  • 질문을 통해 확인하라.
  • 문제의 요구사항을 이해하라.
  • 정답이나 최선의 답안 같은 것은 없다는 것을 명심하라.
    • 스타트업 = 중견 기업 → 설계안이 같을 수가 없다!
  • 가능하다면 여러 해법을 함께 제시하라.
  • 각 컴포넌트의 세부사항을 설명하고, 가장 중요한 컴포넌트부터 진행해라.

하지말아야 할 것


  • 전형적인 면접 문제들에도 대비하지 않은 상태에서 면접장에 가지 마라.
  • 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 마라.
  • 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하지 말고, 개략적 설계부터 해라.
  • 진행 중에 막혔다면, 힌트를 청하기를 주저하지 마라.
  • 소통을 주저하지 마라.
profile
기억보단 기록을

1개의 댓글

comment-user-thumbnail
2023년 7월 27일

감사합니다. 이런 정보를 나눠주셔서 좋아요.

답글 달기