EP174: 인터뷰를 쉽게 만드는 16가지 코딩 패턴

원문: EP174: 16 Coding Patterns That Make Interviews Easy

---

이번 주 시스템 설계 리프레셔:

• URL Shortener는 어떻게 작동하는가? (Youtube 영상)

• 인터뷰를 쉽게 만드는 16가지 코딩 패턴

• 데이터베이스를 어떻게 배울 것인가?

• 브라우저에 URL을 입력하면 무슨 일이 일어나는가?

• HTTPS는 어떻게 작동하는가?

• Netflix의 Scaling 진화 과정

---

인터뷰를 쉽게 만드는 16가지 코딩 패턴

1. Two-Pointer Technique

2. HashMaps

3. Linked Lists

4. Fast and Slow Pointers

5. Sliding Window Technique

6. Binary Search

7. Stacks

8. Heaps

9. Prefix Sum

10. Trees

11. Tries

12. Graphs

13. Backtracking

14. Dynamic Programming

15. Greedy Algorithms

16. Intervals

Over to you: 이 목록에 어떤 코딩 패턴을 추가하시겠습니까?

---

데이터베이스를 어떻게 배울 것인가?

데이터베이스는 웹사이트와 앱부터 엔터프라이즈 시스템까지 모든 것을 구동합니다. 데이터베이스를 마스터하는 데 도움이 되는 학습 로드맵을 소개합니다:

1. Database Fundamentals "데이터베이스란 무엇인가", RDBMS, SQL vs NoSQL, ACID vs BASE, OLTP vs OLAP, Transactions, Isolation Levels 등의 주제를 포함합니다.

2. Data Models and Types Relational Databases, Non-Relational Databases, Data Types (Integer, String, Boolean, Date, JSON 등)와 같은 주제로 구성됩니다.

3. Querying and Language SQL Basics (SELECT, INSERT 등), Advanced SQL (Views, Indexes, CTEs 등), NoSQL Querying (Aggregation과 Key-Value Lookups)와 같은 주제를 포함합니다.

4. Indexing and Optimization Indexing (B-Tree, Hash, Bitmaps), Query Execution Plans, Denormalization vs Normalization, Sharding, Connection Pooling, Query Batching과 같은 주제로 구성됩니다.

5. Security, Backups, and Scaling User Roles, Permissions, Encryption, SQL Injection, High Availability (Replication과 Failover), Horizontal vs Vertical Scaling과 같은 주제를 포함합니다.

6. Tools and Ecosystem Popular SQL Databases, NoSQL Database, GUI Tools, ORMs, Cloud DB 서비스 (RDS, DynamoDB, Google Cloud SQL 등)와 같은 주제로 구성됩니다.

Over to you: 데이터베이스 학습 목록에 무엇을 더 추가하시겠습니까?

---

브라우저에 URL을 입력하면 무슨 일이 일어나는가?

단계별로 살펴보겠습니다.

Step 1: 사용자가 브라우저에 URL (bytebytego.com)을 입력하고 Enter를 누릅니다. 가장 먼저 해야 할 일은 URL을 IP 주소로 변환하는 것입니다. 매핑 정보는 보통 캐시에 저장되어 있어서 브라우저는 여러 계층의 캐시에서 IP 주소를 찾습니다: 브라우저 캐시, OS 캐시, 로컬 캐시, ISP 캐시. 브라우저가 캐시에서 매핑 정보를 찾지 못하면 DNS (Domain Name System) resolver에게 해석을 요청합니다.

Step 2: 어떤 캐시에서도 IP 주소를 찾을 수 없으면, 브라우저는 DNS 서버로 이동하여 IP 주소를 찾을 때까지 재귀적 DNS 조회를 수행합니다.

Step 3: 이제 서버의 IP 주소를 얻었으므로, 브라우저는 서버에 HTTP 요청을 보냅니다. 서버 리소스에 안전하게 접근하려면 항상 HTTPS를 사용해야 합니다. 먼저 TCP 3-way handshake를 통해 서버와 TCP 연결을 설정합니다. 그런 다음 서버가 클라이언트에 public key를 전송합니다. 클라이언트는 public key를 사용하여 session key를 암호화하고 서버로 전송합니다. 서버는 private key를 사용하여 session key를 복호화합니다. 이제 클라이언트와 서버는 session key를 사용하여 암호화된 데이터를 교환할 수 있습니다.

Step 4: 서버가 요청을 처리하고 응답을 돌려보냅니다. 성공적인 응답의 경우 상태 코드는 200입니다. 응답에는 HTML, CSS, Javascript 세 부분이 있습니다. 브라우저는 HTML을 파싱하여 DOM tree를 생성합니다. 또한 CSS를 파싱하여 CSSOM tree를 생성합니다. 그런 다음 DOM tree와 CSSOM tree를 결합하여 render tree를 만듭니다. 브라우저가 콘텐츠를 렌더링하여 사용자에게 표시합니다.

---

HTTPS는 어떻게 작동하는가?

HTTPS는 암호화를 사용하여 브라우저(클라이언트)와 웹사이트 서버 간의 안전한 통신을 보장합니다.

1. TCP Handshake: 보안 통신이 시작되기 전에 클라이언트와 서버는 먼저 TCP handshake 프로세스를 사용하여 기본 연결을 설정합니다. 이 시점에서 데이터는 암호화되지 않습니다.

2. Certificate Check: 이 단계는 서버의 신원을 확인하기 위한 것입니다. 클라이언트가 지원하는 암호화 알고리즘을 제안하는 "hello" 메시지로 TLS handshake를 시작합니다. 서버가 알고리즘을 선택하고 public key가 포함된 디지털 인증서를 전송하며 응답합니다. 클라이언트는 인증서가 신뢰할 수 있는 Certificate Authority (CA)에서 발급된 것인지 검증합니다.

3. Key Exchange: 클라이언트가 인증서를 검증하면 key exchange 프로세스를 시작합니다. 클라이언트는 서버의 public key(인증서에서)를 사용하여 session key를 암호화합니다. 암호화된 session key가 서버로 전송되고, 서버는 private key를 사용하여 복호화할 수 있습니다. change cipher spec 메시지는 이 시점부터 모든 메시지가 합의된 session key와 cipher를 사용하여 암호화될 것임을 나타냅니다. 이 단계에서는 비대칭 암호화를 사용하여 session key를 안전하게 교환합니다.

4. Data Transmission: 이제 양쪽 모두 공유된 session key를 사용하여 대칭 암호화(더 빠름)로 전환합니다. 메시지는 동일한 키로 암호화되고 복호화됩니다. 이제 교환되는 모든 데이터가 안전하고 비공개입니다.

Over to you: HTTPS 프로세스를 설명하기 위해 무엇을 더 추가하시겠습니까?

---

Netflix의 Scaling 진화 과정

수년에 걸쳐 Netflix는 여러 성장 단계를 거쳤습니다. 각 단계마다 scaling 접근 방식을 진화시켜야 했습니다.

1. Stage 1 (Early Streaming Architecture) 클라이언트, API, 데이터베이스로 구성된 전형적인 3-tier 아키텍처였습니다. API 애플리케이션의 이름은 NCCP (Netflix Content Control Protocol)였습니다. 모든 기능을 포함하는 monolithic 애플리케이션이었습니다.

2. Stage 2 (Introducing Microservices) 더 많은 기능이 추가되면서 엔지니어링 속도를 유지하는 것이 중요해졌습니다. 이를 지원하기 위해 monolithic 애플리케이션을 microservices로 분리했습니다. NCCP 애플리케이션에서 기능들을 추출하여 별도의 애플리케이션으로 개발했지만, orchestration 로직은 NCCP 애플리케이션에 남아 있었습니다.

3. Stage 3 (Zuul Gateway) 다음으로 Netflix는 애플리케이션을 분할했습니다. NCCP는 재생 경험을 위해 유지되고, 다른 API들이 다른 기능들을 처리하기 시작했습니다. 클라이언트와 서비스 간의 결합도를 줄이기 위해 Zuul API Gateway가 도입되었습니다.

참조: Netflix TechBlog

Over to you: Netflix가 현재 수준으로 확장한 방법에 대해 다른 nuance를 접해본 적이 있으신가요?