3장 시스템 설계 면접 공략법

서론

꿈꾸던 회사의 면접 기회가 왔다고 상상해보자. 그런데 면접 세션에 "시스템 설계 면접"이 적혀있다. 시스템 설계는 수백 명, 수천 명의 엔지니어들이 참여하여 개발한 제품일 것이다. 하지만, 1시간안에 1명의 면접자가 완벽하게 설계할 수 있을까? 정답은 아니다. 

 

그렇다면, 왜 시스템 설계 면접이 있을까? 시스템 설계 면접은 두 명의 동료가 모호한 문제를 풀기 위해 협력하여 해결책을 찾아내는 과정에 대한 시뮬레이션이다. 당연하게도 문제는 정답이 없다. 최종적으로 도출된 설계안은 설계 과정에 들인 노력에 비하면 중요하지 않다. 그렇다. 설계 과정을 토대로 면접자의 기술적 측면, 협력, 탈압박, 문제해결능력 등 다양한 능력을 확인할 수 있다.

 

목표

시스템 설계 면접에 관한 팁들을 살펴보고, 면접을 공략하는 효과적인 접근법을 배워보자.

 

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

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

 

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

엔지니어인 우리에게는 어려운 문제를 풀고 최종 설계를 바로 내놓고 싶은 욕구가 있다. 하지만, 그러면 잘못된 시스템을 설계할 가능성이 높아진다. 엔지니어가 가져야할 가장 중요한 기술 중 하나는 올바른 질문을 하는 것, 적절한 가정을 하는 것, 그리고 시스템 구축에 필요한 정보를 모으는 것이다.

 

질문을 던지면 면접관을 여러분이 질문에 대한 답을 바로 내놓거나, 여러분 스스로 어떤 가정을 하기를 주문할 것이다. 후자의 경우에는 그 가정을 화이트보드나 종이에 적어두어야 한다. 나중에 필요해질 때가 있기 때문이다.

 

그렇다면, 어떤 질문을 해야할까? 요구사항을 정확히 이해하는 데 필요한 질문을 하자. 아래는 그 예시가 될 수 있다.

1. 구체적으로 어떠 기능들을 만들어야 하는가?
2. 제품 사용자 수는 얼마나 되나?
3. 회사의 규모는 얼마나 빨리 커지리라 예상하나? 3달, 반년, 1년 뒤 예상 규모는 어느 정도인가?
4. 정렬이 필요한가?

 

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

개략적인 설계안이 나왔다면, 면접관의 동의를 구하자. 해당 과정은 면접관과 협력하며 진행하면 좋다.

 

1. 설계안에 대한 최초 청사진을 제시하고 의견을 구하라. 면접관이 마치 팀원인 것처럼 행동해라. 훌륭한 면접관은 지원자와 대화하고 설계 과정에 개입하는 것을 즐긴다.
2. 화이트보드나 종이에 핵심 컴포넌트를 포함하는 다이어그랩을 그려라. 클라이언트, API, 웹서버, 데이터 저장소, 캐시, CDN, 메시지 큐 같은 것들이 포함될 수 있을 것이다.
3. 최초 설계안이 시스템 규모에 관계된 제약사항들을 만족하는지 개략적으로 계산해보자. 계산 과정을 소리 내어 설명해라. 아울러, 이런 개략적 추정이 필요한지는 면접관에게 미리 물어보자.

가능하다면 시스템의 구체적 사용 사례도 몇 가지 살펴보자. 고려하지 못한 edge case를 발견하는 데 도움이 되기 때문이다.

 

예제

뉴스 피드 시스템을 설계하라고 했다고 가정해보자. 시스템이 실제로 어떻게 동작하는지 지금 당장 이해할 필요는 없다. 상세한 내용은 11장에서 설명한다고 한다.

 

개략적으로 살펴보면 2가지의 처리 flow인 feed 발행, feed 생성을 나눠 생각해볼 수 있다. 

• 피드 발행
  • 사용자가 포스트를 올리면 관련된 데이터가 캐시/데이터베이스에 기록되고, 해당 사용자의 친구 뉴스 피드에 뜨게 된다.
• 피드 생성 
  • 어떤 사용자의 뉴스 피드는 해당 사용자 친구들의 포스트를 시간 역순으로 정렬하여 만든다.

그림 3-1과 3-2는 피드 출력과 피드 생성 플로를 각각 개략적으로 그린 것이다.

 

3단계 상세 설계

이제 면접관과 해야할 일은 컴포넌트 사이의 우선순위를 정하는 것이다. 어떨 때는 면접관이 면접자가 집중 했으면 하는 영역을 알려주기도 한다. 어떨 때는, 시스템의 성능 특성에 대한 질문을 던질 것이고, 해당 경우 질문 내용은 시스템의 병목 구간이나 자원 요구량 추정치에 초점이 맞춰져 있을 것이다. 대부분의 면접관은 면접자가 특정 시스템 컴포넌트들의 세부사항을 깊이 있게 설명하는 것을 보길 원한다. 가령 문제가 단축 URL 생성기(URL shortener) 설계에 관한 것이었다고 해 보자. 그렇다면, 면접관은 해시 함수의 설계를 구체적으로 설명하는 것을 듣고 싶어할 것이다. 채팅 시스템에 관한 문제였다면, 어떻게 하면 지연시간(latency)을 줄이고 사용자의 온/오프라인 상태를 표시할 것인지를 듣고자 할 것이다. 

면접 시에는 시간 관리에도 특별히 주의를 기울여야 한다. 사소한 세부사항을 설명하느라 정작 능력을 보일 기회를 놓쳐버리게 될 수도 있기때문이다. 면접자는 면접관에게 긍정적인 시그널(signal)을 전달하는 데 집중해야 한다. 불필요한 세부사항에 시간을 쓰지 말자.

 

예제

뉴스 피드 시스템의 개략적 설계를 마친 사항이라 해보자. 또한, 면접관도 해당 설계에 몬작하고 있다고 가정하자. 이제 아래 두 가지 중요한 용례를 보다 깊이 탐구해야 한다.

1. 피드 출력
2. 뉴스 피드 가져오기

위 그림은 각각에 대한 상세 설계이다. 해당 설계안에 대해서는 11장에서 보다 깊이 설명한다.

 

4단계 마무리

이제 면접관은 설계 결과물에 관련한 몇 가지 후속 질문을 던질 수도 있고 면접자가 스스로 추가 논의를 진행하도록 할 수도 있다. 아래 몇 가지 지침을 활용하도록 하자.

• 면접관이 좀 더 개선 가능한 지점을 찾아내라 주문할 수도 있다. 이때, 개선할 부분이 없다는 답은 하지 않도록 하자. 개선할 점은 언제나 있기 마련이다. 
• 만든 설계를 한 번 다시 요약해주는 것도 도움이 될 수 있다. 여러 해결책을 제시한 경우에는 특히 중요하다. 긴 면접 세션이 끝난 뒤에 면접관의 기억을 환기시켜주는 효과가 있기때문이다.
• 오류가 발생하면 무슨 일이 생기는지 따져보면 흥미로울 것이다.
• 운영 이슈도 논의할 가치가 충분하다. 메트릭은 어떻게 수집하고 모니터링할 것인가? 로그는? 시스템은 어떻게 배포해 나갈 것인가?
• 미래에 닥칠 규모 확장 요구에 어떻게 대처할 것인지도 흥미로운 주제다. 예를 들어, 현재 설계로 백만 사용자는 능히 감당할 수 있다고 해보자. 천만 사용자를 감당하려면 어떻게 해야 하는가?
• 시간이 좀 남았다면, 필요하지만 다루지 못했던 세부적 개선사항들으 제안할 수 있다.

이제 마지막으로 해야할 것과 하지말아야 할 것 을 정리해보자.

 

 해야할 것

• 질문을 통해 보다 완벽하게 확인해라. 스스로 내린 가정이 옳다 믿고 진행하지마라.(절대로)
• 문제의 요구사항을 이해하라.
• 정답이나 최선의 답안 같은 것은 없다는 점을 명심하라.
• 면접관이 면접자의 사고 흐름을 이해할 수 있도록 하라. (소통)
• 가능하다면 여러 해법을 함께 제시해라.
• 개략적 설계에 면접관이 동의하면, 각 컴포넌트의 세부사항을 설명하기 시작하라. 가장 중요한 컴포넌트부터 진행.
• 면접관의 아이디어를 이끌어 내라. 좋은 면접관은 같은 팀원처럼 협력한다.
• 포기하지 마라.

 

하지말아야 할 것 

• 전형적인 면접 문제들에도 대비하지 않은 상태에서 면접장에 가지 마라.
• 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 마라.
• 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하지 마라. 
• 진행 중에 막혔다면, 힌트를 청하기를 주저하지 마라.
• 다시 말하지만, 소통을 주저하지 마라. 침묵 속에 설계를 진행하지 마라.
• 설계안을 내놓는 순간 면접이 끝난다고 생각하지 마라. 의견을 일찍, 그리고 자주 구하라.

 

시간 배분

• 1단계 - 3분 ~ 10분
• 2단계 - 10분 ~ 15분
• 3단계 - 10분 ~ 25분
• 4단계 - 3분 ~ 5분

 

 

 

 

Reference

• 가상 면접 사례로 배우는 대규모 시스템 설계 기초