개요
시스템 설계 면접은 지원자의 설계 능력의 기술적 측면을 평가하는 것도 중요하지만, 그보다는 지원자가 협력에 적합한 사람인지, 압박받는 상황에서 잘 헤쳐 나가는지, 모호한 문제를 건설적으로 해결할 능력이 있는지, 좋은 질문을 던지는 능력이 있는지도 중요하다.
설계의 순수성에 집착한 나머지 타협점(tradeoff)을 도외시하고 과도한 엔지니어링(over-engineering)을 하는 사람도 많다. 오버 엔지니어링은 시스템 전반의 비용이 올라간다.
이번 장을 통해 시스템 설계 면접에서 유용한 팁을 살펴보고, 효과적으로 공략하는 접근법을 알아보자.
시스템 설계 4단계 접근법
1단계 : 문제 이해 및 설계 범위 확정
시스템 설계 면접을 볼 떄, 생각 없이 바로 답을 내서는 좋은 점수를 받기 어렵다. 요구사항을 완전히 이해하고, 깊이 생각하고 질문하여 요구사항과 가정들을 명확하게 하는 것은 아주아주 중요하다. 엔지니어가 가져야할 가장 중요한 기술은 올바른 질문을 하는 것, 적절한 가정을 하는 것, 그리고 시스템 구축에 필요한 정보를 모으는 것이다.
요구사항을 정확히 이해하는데 필요한 질문의 예시를 보자.
•
구체적으로 어떤 기능을 만들어야 하는가
•
제품의 사용자 수는 얼마나 되는가
•
회사의 규모는 얼마나 빠르게 성장하는가, 3달, 반년, 일년 뒤의 규모 예상치는 얼마인가
•
회사가 주로 사용하는 기술 스택(technology stack)은 무엇인가
•
설계를 단순화하기 위한 기존 서비스는 어떤 것이 있는가
지원자: 모바일 앱과 웹 앱 가운데 어느 쪽을 지원해야 하나요? 아니면 둘 다일까요?
면접관: 둘 다 지원해야 합니다.
지원자: 가장 중요한 기능은 무엇인가요?
면접관: 새로운 포스트(post)를 올리고, 다른 친구의 뉴스 피드를 볼 수 있도록 하는 기능입니다.
지원자: 이 뉴스 피드는 시간 역순으로 정렬되어야 하나요? 아니면 다른 특별한 정렬 기준이 있습니까? 제가 특별한 정렬 기준이 있는가 하고 묻는 이유는, 피드에 올라갈 포스트마다 다른 가중치가 부여되어야 하는지 알고 싶어서 인데요. 가령 가까운 친구의 포스트가 사용자 그룹(user group)에 올라가는 포스트보다 더 중요하다거나.
면접관: 문제를 단순하게 만들기 위해, 일단 시간 역순으로 정렬된다고 가정합시다.
지원자: 한 사용자는 최대 몇 명의 사용자와 친구를 맺을 수 있나요?
면접관: 5000명입니다.
지원자: 사이트로 오는 트래픽 규모는 어느 정도입니까?
면접관: 일간 능동 사용자(daily active user, DAU)는 천만 명입니다.
지원자: 피드에 이미지나 비디오도 올릴 수 있나요? 아니면 포스트는 그저 텍스트입니까?
면접관: 이미지나 비디오 같은 미디어 파일도 포스트 할 수 있어야 합니다.
지금까지 여러분이 면접관에게 던질 수 있는 질문 사례를 살펴보았다. 요구사항을 이해하고 모호함을 없애는 게 이 단계에서 가장 중요하다는 것을 명심하자.
Plain Text
복사
이러한 질문 사례들처럼 요구사항을 이해하고 모호함을 없애는 것이 1단계에서 가장 중요하다는 것을 명심하자
2단계 : 개략적인 설계안 제시 및 동의 구하기
2단계에서는 개략적인 설계안을 제시하고 면접관의 동의를 구하는 것에 초점을 맞추어야 한다.
•
설계안에 대한 최초 청사진 제시 및 의견 구하기
•
핵심 컴포넌트를 포함하는 다이어그램 그리기
(모바일/웹 클라이언트, API, 웹 서버, 데이터 저장소, CDN, 메세지 큐 등)
•
최소 설계안이 시스템 규모에 관계된 제약사항들을 만족하지는지 대략적으로 계산
•
가능하다면 시스템의 구체적 사용 사례 확인
2단계에서 API 엔드포인트나 데이터베이스 스키마를 설계하는 것은 시스템 설계의 규모에 따라 다른다. 구글 검색 엔진 설계와 같은 큰 규모의 설계라면 지나치게 세부적인 내용일 것이고, 포커 게임의 백엔드를 설계하는 문제에서는 괜찮을 것이다.
1단계의 뉴스 피드 시스템 설계 문제를 이어나가면서, 개략적인 설계를 어떻게 만들어내는지 예시를 살펴보자. 뉴스 피드 시스텀 설계는 피드 발행과 피드 생성의 두 가지 플로우(flow)로 나눠 생각해 볼 수 있다.
•
피드 발행 : 사용자가 포스트를 올리면 관련된 데이터가 캐시/데이터베이스에 기록되고, 해당 사용자의 친구의 뉴스 피드에 뜨게 된다.
•
피드 생성 : 어떤 사용자의 뉴스 피드는 해당 사용자의 친구들 포스트를 시간 역순으로 정렬하여 보여준다.
3단계 : 상세 설계
여기까지 왔다면 아래의 목표들은 달성했을 것이다.
•
시스템 전반적으로 달성해야하는 목표와 기능 범위 확인
•
전체 설계의 개략적 청사진 마련
•
해당 청사진에 대한 면접관의 피드백 확인
•
상세 설계에서 집중해야 할 영역들 확인
면접마다 집중해야하는 포인트가 다르기 때문에, 우리는 3단계에서 설계 대상 컴포넌트 사이의 우선순위를 정해야한다.
선임급 개발자 면접이라면 시스템 성능 특성이 주요 관심사일 것이고, 질문 내용은 병목 구간이나 자원 요구량 추정치에 초점이 맞춰져있을 것이다. 단축 URL 생성기 설계가 면접에 나왔다면 해시 함수의 설계를 구체적으로 설명하는 것이 중요할 것이고, 채팅 시스템 문제라면 지연 시간을 줄이고 사용자의 온/오프라인을 표현하는 방법이 중요할 것이다.
그 외의 사소한 세부사항들에 시간을 쓰지말자. 중요한 것을 설계하기에도 시간이 부족하다.
뉴스 피드 예시를 이어나가 상세 설계를 진행하고 시각화 해보자.
•
피드 발행
•
뉴스 피드 가져오기
4단계 : 마무리
마지막 단계에서는 설계 결과물에 관련된 몇 가지 후속 질문을 던지거나, 우리 스스로 추가 논의를 진행하도록 할 수도 있다. 다음의 지침을 활용하자.
•
시스템에서 병목구간이나 좀 더 개선 가능한 지점을 찾아달라는 요청을 받으면, 완벽하거나 개선할 여지가 없다는 말은 하지말자.
•
우리가 만든 설계를 다시 한 번 요약하는 것도 도움이 될 수 있다. 이는 기억을 환기시키기 때문에 여러 해결책을 제시한 경우 특히 중요하다.
•
오류가 발생하면 무슨 일이 생길 지(서버 오류, 네트워크 장애 등) 예상해보자.
•
메트릭 수집 방법이나 모니터링, 로그, 배포 등 운영 이슈도 논의할 가치가 있다.
•
미래에 닥칠 규모 확장 요구에 어떻게 대처할지 고민해보자.
•
시간이 남는다면, 필요하지만 다루지 못했던 세부적 개선사항들을 제안할 수 있다.
면접 시 해야 할 것
•
스스로 내린 가정이 옳다고 믿고 진행하지 말고 질문을 통해 확인하기
•
문제의 요구사항 이해하기
•
설계에 정답은 없다는 점 명심하기
•
면접관에게 사고 흐름을 이해할 수 있도록 잘 소통하기
•
가능하다면 여러 해결책 제시하기
•
개략적 설계에 면접관이 동의하면, 중요한 컴포넌트부터 세부사항을 설명하기
•
면접관과 팀원처럼 협력하여 아이디어를 이끌어 내기
면접 시 하지 말아야 할 것
•
전형적인 면접 질문들에 대비하지 않은 채 면접 보지말기
•
요구사항이나 가정들을 명확히 하지 않은채로 설계 하지말기
•
처음부터 세부사항에 너무 깊게 집중하지 말기
•
진행 중 막혔다면, 주저말고 힌트를 요청하기
•
꾸준히 소통하고, 침묵 속에서 설계를 진행하지 말기
•
끝날 때까지 방심하지 말고, 설계안을 내놓는다고 면접이 끝난게 아님을 명심하기
시간 배분
시스템 설계 면접은 보통 광범위한 영역을 다루고 45분에서 1시간정도 진행된다. 이는 충분하지 않을 수 있기 때문에, 시간 관리를 잘 해야한다. 대략적으로 아래와 같이 시간을 사용하는 것이 좋다.(추정치이므로 맹신하지말기)
•
1단계 : 문제 이해 및 설계 범위 확정 - 3분 ~ 10분
•
2단계 : 개략적 설계안 제시 및 동의 구하기 - 10분 ~ 15분
•
3단계 : 상세 설계 - 10분 ~ 25분
•
4단계 : 마무리 - 3분 ~ 5분