Tech Dive Study 1~5회차 요약

Rookedsysc·2025년 12월 1일

테크다이브 1기 스터디

목록 보기

2/2

테크다이브 스터디란?

rene(르네)님이 AsyncSite에서 모집한 스터디입니다.
시스템 설계 주제를 정해놓고 해당 시스템을 화이트 보드에 그려가며 토론을 하는 형식으로 진행됩니다.. 매주 주제와 사회자, 드라이버를 정합니다. 사회자는 토론이 잘 이어질 수 있도록 진행을 리드하는 역할을 하고 드라이버는 토론하는 내용을 가시화하는 역할을 합니다. ~~드라이버 너무 힘들어...~~

테크 다이브 지금 필요한 건, 프로그래밍 언어가 아닌, 설계의 언어
우리만의 학습 방식
👥 몹 디자인 (Mob Design)
화이트보드 앞에서 함께 설계. 혼자가 아니기에 두렵지 않고, 함께이기에 더 깊게 파고듭니다.
🤖 AI를 파트너로
AI는 우리의 설계를 검증하고, 대안을 제시하는 똑똑한 조력자, 3의동료. 비판적으로 활용하며 사고력을 확장합니다.
⏱️ 5 Phase 몰입 시스템
2시간을 5개 Phase로 나눠 요구사항부터 확장성까지 체계적으로 학습. 시간 압박이 집중력을 만듭니다.

1주차: 단축 URL

1. 요구사항 정의

저희는 기능적 요구사항에는 리다이렉트가 되야하고 5~6글자 사이의 짧은 URL을 생성해야 하고 만료 기능, 트래픽 대시보드 등이 포함될 수 있겠다고 논의했습니다. 비기능적 요구사항에는 DAU 100M, 읽기 100:쓰기 1의 비율, 실사용자 10만, 쓰기 200ms 읽기 50ms로 정의를 했습니다. 비기능적 요구사항을 정의할 때는 네이버 맵을 기준으로 정의할려고 했고 결론적으로 쓰기 QPS 1.2, 읽기 QPS 220 정도가 산출되게 되었습니다.

2. 아키텍처

처음에 저는 Trie 자료구조를 써서 Key가 되는 URL 부분을 압축하면 어떨까? 라는 주장을 했습니다. URL 단축 서비스는 문자열의 접두사 검색(예: 자동 완성)이 필요한 것이 아니라, 고유한 키(단축 URL)로 값을 즉시 찾는 것(O(1))이 중요합니다. 제 주장은 중복되는 URL에 대해서 단축 URL을 생성할 경우, value에 중복이 있는지 없는지를 탐색할 때 Trie가 좀 더 적합하지 않겠냐는 얘기였지만 사용자의 사용 흐름을 볼 때 동일한 URL을 중복처리 하는게 중요한 비즈니스 로직이 아닌 것 같다는 의견이 있었습니다. 어떤 기능이 필수적인 요구사항이고 어떤 기능이 부가적인 요구사항인지를 명확히 구분할 수 있는 판단력을 기를 수 있는 좋은 예시였던 것 같습니다.

그리고 영속성과 성능의 관점에서 DynamoDB vs RDS를 고려했는데 DynamoDB를 메인으로쓰고 통계 데이터를 RDS에 작성하기로 했습니다. DynamoDB는 Key Value Store로써 Short URL로 요청을 했을 때 원본 URL로 Redirect 시키기 위해서 50ms가 걸려야 한다는 제약조건을 만족할 수 있습니다. 또한 URL 만료 작업을 TTL을 활용해서 관리할 수 있습니다.

3. 단축 URL 생성 알고리즘

고유한 6자리의 단축 URL을 생성하는 방식을 논의했습니다. 이 때 주요 논점은 SHA 256 등 Hash 방식을 쓸건지 Base62 or 64를 쓸건지 였습니다. SHA 256을 도입하려 했던 이유는 Hash 충동일 일어날 가능성이 있기 때문이었습니다. 하지만 base62를 통해서 6자리 문자를 생성할 경우 568억개의 경우의 수가 나옵니다. QPS 1.2를 기준으로 31,536,000개의 키가 생성될 수 있기 때문에 Auto Increment + Base62를 사용해서 Key를 생성해도 충돌이 나지 않는다는 결론이 납니다.
정확한 수학적 근거를 기반으로 판단을 해야 한다는 것을 배울 수 있었습니다.

2~3회차: Rate Limiter

배운점

Leaky Bucket as Meter와 Token Bucket은 동치다.
Redis Transaction은 Transaction 내부에서 읽는 값을 반환할 수 없다.
Redis Pipeline과 Redis Transaction의 차이점으로는, Transaction은 Transaction으로 묶인 명령어가 실행되는 동안 다른 명령어는 실행되지 않도록 원자성을 보장하지만 Pipe Line은 원자성을 보장하지 않는다. 이런 이유 때문에 성능적인 관점에서는 Redis Transaction은 Blocking이 걸리기 때문에 연산 속도가 느릴 수 있다.
원자적으로 Read and Write Pattern을 구현해야 한다면 Lua Script를 사용하는게 맞다.