일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 카카오
- Spring
- thymeleaf
- OpenCV
- 컴포넌트스캔
- nestJS
- 해시
- 코테
- TypeORM
- 스프링
- 파이썬
- spring boot
- Nodejs
- python
- 시스템호출
- 카카오 코테
- 카카오 알고리즘
- 프로그래머스
- 코딩테스트
- 구조체배열
- C언어
- C++
- @Autowired
- git
- 가상면접사례로배우는대규모시스템설계기초
- @Component
- AWS
- nestjs auth
- 알고리즘
- nestjs typeorm
- Today
- Total
공부 기록장 💻
3장 시스템 설계 면접 공략법 (가상 면접 사례로 배우는 대규모 시스템 설계 기초) 본문
3장 시스템 설계 면접 공략법 (가상 면접 사례로 배우는 대규모 시스템 설계 기초)
dream_for 2022. 12. 25. 00:30책 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 3장 정리
학습 목표
"널리 알려진 제품 X를 설계해 보라" 라는 식의 막연한 시스템 설계 질문은 모호하고, 범위도 지나치게 넓다. 이러한 시스템 설계 면접의 경우, 최종적으로 도출된 설계안이 중요하기보다는, 면접을 통해 설계 과정에서 내린 결정들에 대한 방어 능력을 보이는 자리이며, 면접관의 피드백을 건설적인 방식으로 처리할 자질이 있음을 보이는 것이 중요하다.
시스템 설계 면접은 지원자의 설계 능력의 기술적 측면과 더불어 지원자가 협력에 적합한 사람인지, 압박이 심한 상황도 잘 헤쳐 나갈 자질이 있는지, 모호한 문제를 건설적으로 해결할 능력이 있는지 등을 살펴보는 면접이다. 좋은 질문을 던질 능력이 있는지도 중요하다.
훌륭한 면접관은 부정적 신호(red flag)도 놓치지 않는다. 설계의 순수성에 집학한 나머지 타협적 결정(tradeoff)를 도외시하고 과도한 엔지니어링(over-engineering)을 하고 마는 엔지니어들이 현업에도 많고, 오버엔지니어링의 결과로 시스템 전반의 비용이 올라간다는 사실을 알아채지 못하는 일이 많다. 오버엔지니어링 외에도 완고함, 편협함 등이 부정적 신호의 또다른 예이다.
3장을 통해 시스템 설계 면접에 관한 유용한 팁들을 살펴보고, 시스템 설계 문제를 공략하는 효과적 접근법에 대해 알아보자.
효과적 면접을 위한 4단계 접근법
시스템 설계 면접은 전부 제각각이며, 훌륭한 설계 면접에는 정해진 결말도 정답도 없다. 그러나 그 절차나 범위에는 공통적인 부분이 있으므로 4단계 접근법에 대해 알아보자.
1단계, 문제 이해 및 설계 범위 확정
시스템 설계 면접을 볼 때 생각 없이 바로 답을 내서는 좋은 점수를 받기 어렵다. 요구사항을 완전히 이해하지 않고 답을 내놓는 행위는 아주 엄청난 부정적 신호이다. 답부터 들이밀지 말고, 속도를 늦추는 것이 좋다. 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 해야 한다.
엔지니어가 지녀야 할 가장 중요한 기술 중 하나는 올바른 질문을 하는 것, 적절한 가정을 하는 것, 그리고 시스템 구축에 필요한 정보를 모으는 것이다.
요구사항을 정확히 이해하기 위해서는 적절히 질문을 해야 할 필요가 있는데, 아래와 같은 질문들을 생각해 볼 수 있다.
구체적으로 어떤 기능들을 만들어야 하나?
제품 사용자 수는 얼마나 되는가?
회사의 규모는 얼마나 빨리 커지리라 예상하나? 3달, 6달, 1년 뒤의 규모는 얼마가 되리라 예상하는가?
회사가 주로 사용하는 기술 스택은? 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가?
예제
뉴스 피드 시스템을 설계하라는 요구를 받았다고 가정하였을 때, 질문할 수 있는 것들은 다음과 같을 것이다.
모바일 앱과 웹 앱 가운데 어느 쪽을 지원해야 하나요? 혹은 둘다인가요?
가장 중요한 기능은 무엇인가요?
뉴스 피드는 시간 역순으로 정렬되어야 하나요? 아니면 다른 특별한 정렬 기준이 있나요? (피드에 올라갈 포스타마다 다른 가중치가 부여되어야 하는지 알고 싶은데, 가령 가까운 친구의 포스트가 사용자 구릅에 올라가는 포스트보다 더 우선 순위가 높다거나..)
한 사용자는 최대 몇 명의 사용자와 친구를 맺을 수 있나요?
사이트로 오는 트래픽 규모는 어느 정도입니까?
피드에 이미지나 비디오도 올라올 수 있나요? 혹은 텍스트 데이터만 반영하나요?
이렇게 면접관에게 던질 수 있는 질문 사례를 살펴 보았고, 요구 사항을 정확히 이해하고 모호함을 없애는 것이 이 단계를 통해 얻고자 하는 핵심이다.
2단계, 개략적인 설계안 제시 및 동의 구하기
2단계에서 초점을 맞추어야 하는 것은 개략적인 설계안을 제시하고 면접관의 동의를 얻는 것이다. 이는 면접관과 협력하여 진행할 수 있다.
- 설계안에 대한 최초 청사진을 제시하고 의견을 구하라. 면접관을 마치 팀원인 것처럼 대하라.
- 화이트보드나 종이에 핵심 컴포넌트를 포함하는 다이어그램을 그려라. 클라이언트(모바일/웹), API, 웹 서버, 데이터 저장소, 캐시, CDN, 메시지 큐 등이 포함된다.
- 이 최초 설계안이 시스템 규모에 관계된 제약 사항들을 만족하는지를 개략적으로 계산해 보라. 계산 과정을 소리 내어 설명하고, 이런 개략적 추정이 필요한지 면접관에게 미리 물어보도록 하자.
가능하다면 시스템의 구체적 사용 사례도 몇 가지 살펴보자. 고려하지 못한 에지 케이스를 발견하는 데도 도움이 될 것이다.
구글 검색 엔진을 설계하는 등의 큰 규모의 설계 문제가 아닌 소규모의 백엔드 설계 문제의 경우, API 엔드포인트나 데이터베이스 스키마를 보여줄 수도 있다.
예제
뉴스 피드 시스템의 개략적 설계를 하기 위해, 피드 발행(feed publishing)과 피드 생성(feed building), 이 두가지 처리 flow로 나누어 생각해 볼 수 있다.
- 피드 발행: 사용자가 포스터를 올리면 관련된 데이터가 캐시/데이터베이스에 기록되고, 해당 사용자의 친구 뉴스 피드에 뜨게 된다.
- 피드 생성: 어떤 사용자의 뉴스 피드는 해당 사용자 친구들의 포스트를 시간 역순(최신에서 오래된 포스트 순으로) 정렬하여 만든다,
아래 3-1은 피드 발행의 flow를, 3-2는 피드 생성의 flow를 그림으으로 나타낸 것이다.
3단계, 상세 설계
3단계까지 왔다면, 다음의 목표는 달성한 상태가 된다.
- 시스템에서 전반적으로 달성해야 할 목표와 기능 범위 확인
- 전체 설계의 개략적 청사진 마련
- 해당 청사진에 대한 면접관의 의견 청취
- 상세 설계에서 집중해야 할 영역들 확인
이제 면접관과 해야 할 일은 실제 대상 컴포넌트 사이의 우선순위를 정하는 것이다. 면접관이 집중 했으면 하는 영역을 알려 줄 수도, 또는 시스템의 성능 특성에 대한 질문을 던지며 시스템의 병목 구간이나 자원 요구량 추정치에 초점을 맞출 수도 있다. 대부분의 경우 면접관은 특정 시스템 컴포넌트들의 세부사항을 깊이있게 설명하는 것을 보길 원한다. 예를 들어 출제된 설계 문제가 단축 URL 생성기(URL shortener)인 경우, 해시 함수의 설계를 구체적으로 설명하는 것을 듣고 싶어할 것이다. 채팅 시스템 문제라면, 어떻게 하면 지연 시간(latency)을 줄이고 사용자의 온/오프라인 상태를 표시할 것인지를 듣고자 할 것이다.
면접 시에는 불필요한 세부사항에 시간을 쓰지 않으며 시간을 관리하는 것에도 특별희 주의를 기울여야 한다. 예를 들어, 페이스북에서 뉴스 피드의 순위를 매기는 데 사용되는 EdgeRank 알고리즘에 대해 이야기하는 것은 바람직하지 않다고 할 수 있다. 이는 시간을 너무 많이 쓰게 하는 원인이 될 수 있으며, 규모 확장 가능한 시스템을 설계할 능력이 있다는 것을 증명하는 데는 도움이 되지 않는 부분이기 때문이다.
예제
뉴스 피드 시스템의 개략적 설계를 마친 후, 다음의 두 가지 중요한 용례를 보다 깊이 탐구해야 한다.
1. 피드 발행
2. 뉴스 피드 가져오기(news feed retrieval)
다음은 각각에 대한 상세 설계이다.
4단계, 마무리
마지막 단계에서 면접관은 설계 결과물에 관련된 몇 가지 후속 질문을 던질 수도 있고(follow-up questions), 스스로 추가 논의를 진행하도록 할 수도 있다. 다음의 몇 가지 지침을 활용할 수 있다.
- 면접관이 시스템 병목구간, 혹은 좀 더 개선 가능한 지점을 찾아내라 주문할 수도 있다. 설계가 완벽하다거나 개선할 부분이 없다는 답은 하지 않도록 해야 한다. 이러한 질문은 비판적 사고 능력을 보이고, 마지막으로 좋은 인상을 남길 수 있도록 하는 좋은 기회이다.
- 설계를 다시 한번 요약해주는 것도 도움이 될 수 있다.
- 오류가 발생하면 무슨 일이 생기는지(서버 오류 또는 네트워크 장애 등) 따져 보면 흥미로울 것이다.
- 운영 이슈도 논의할 가치가 충분하다. 메트릭은 어떻게 수집하고 모니터링 할 것인가? 로그는? 시스템은 어떻게 배포해(roll-out) 나갈 것인가?
- 미래에 닥칠 규모 확장 요구에 어떻게 대처할 것인지도 흥미로운 주제다. 현재 설계로는 백만 사용자를 능히 감당할 수 있지만, 천만 사용자는 어떻게 감당해 낼 것인가?
- 시간이 좀 남았다면, 필요하지만 다루지 못했던 세부적 개선사항들을 제안할 수 있다.
면접 세션에서 해야할 것과 하지 말아야 할 것들을 목록으로 정리해보면 다음과 같다.
해야 할 것
- 질문을 통해 확인하라(clarification). 스스로 내린 가정이 옳다 믿고 진행하지 말라.
- 문제의 요구사항을 이해하라.
- 정답이나 최선의 답안 같은 것은 없다는 점을 명심하자. 요구사항을 정확히 이해했는지 다시 확인하라.
- 면접관이 사고의 흐름을 이해할 수 있도록 하라, 면접관과 소통하라.
- 가능하다면 여러 해법을 함께 제시하라.
- 개략적 설계에 면접관이 동의하면, 각 컴포넌트의 세부사항을 설명하기 시작하라. 가장 중요한 컴포넌트부터 진행하라
- 면접관의 아이디어를 이끌어 내라. 좋은 면접관은 팀원처럼 협력할 것이다.
하지 말아야 할 것
- 전형적인 면접 문제들에도 대비하지 않은 상태에서 면접장에 가지 말라.
- 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말라.
- 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하지 말라. 개략적 설계를 마친 뒤 세부사항으로 나아가라.
- 진행 중 막혔다면, 힌트를 청하기를 주저하지 말라.
- 소통을 주저하지 말라.
- 설계안을 내놓은 순간 면접이 끝났다고 생각하지 말고, 의견을 일찍 그리고 자주 구하라.
시간 배분
시스템 설계 면접은 보통 매우 광범위한 영역을 다루며 45분 또는 한 시간이 충분치 않을 수도 있다. 45분의 면접 시간을 가정할 때, 위에서 상술한 각 단계에 시간을 배분해보면 다음과 같다.
1단계 (문제 이해 및 설계 범위 확정) - 3분에서 10분
2단계 (개략적 설계안 제시 및 동의 구하기) - 10분에서 15분
3단계 (상세 설계) - 10분에서 25분
4단계 (마무리) - 3분에서 5분
'# Tech Studies > 가상면접 사례로 배우는 대규모 시스템 설계기초' 카테고리의 다른 글
2장 개략적인 규모 측정 (가상 면접 사례로 배우는 대규모 시스템 설계 기초) (0) | 2022.11.05 |
---|---|
1장 사용자 수에 따른 규모 확장성 (가상 면접 사례로 배우는 대규모 시스템 설계 기초) (0) | 2022.10.30 |
가상 면접 사례로 배우는 대규모 시스템 설계 기초 스터디 시작 (2) | 2022.10.30 |