📚 지식 노트

설계 질문을 푸는 네 단계

"채팅 서비스를 설계해 보라"는 질문에는 정답이 없다. 사용자가 백 명인지 십억 명인지, 메시지를 영원히 남기는지, 단체방이 있는지에 따라 전혀 다른 시스템이 된다. 그래서 설계 면접이든 실제 설계 회의든, 막연한 질문을 범위가 정해진 문제로 바꾸는 것이 첫 일이다. 진행은 대략 네 단계로 나눌 수 있다.

1. 범위 정하기: 바로 그리기 시작하지 않는다. 핵심 기능 두세 개, 사용자 수와 증가 속도, 읽기와 쓰기의 비율, 지연과 일관성 중 무엇이 더 중요한지 묻는다. 답이 없으면 스스로 가정을 세우고 말로 확인받는다. 이 가정이 다음 절들의 개략 추정에 들어간다.
2. 큰 그림: 클라이언트부터 저장소까지 부품을 상자로 그리고 요청 하나가 지나가는 길을 따라가 본다. 주요 API와 데이터 모양(무엇을 어디에 저장하나)도 이때 정한다. 아직 세부는 비워 둔다.
3. 깊이 파기: 전체를 고르게 다듬기보다 이 시스템에서 가장 어려운 한두 곳을 고른다. 쓰기가 몰리는 곳, 일관성이 깨지기 쉬운 곳, 데이터가 가장 큰 곳이다. 대안을 두세 개 놓고 무엇을 얻고 무엇을 잃는지 견준다.
4. 마무리: 설계의 약점을 스스로 짚는다. 어느 부품이 죽으면 어떻게 되는지, 규모가 열 배가 되면 무엇이 먼저 막히는지, 무엇을 재고 경보할지 말한다.

어느 단계에서든 핵심은 결정마다 이유를 말하는 것이다. "캐시를 쓴다"보다 "읽기가 쓰기의 50배라 캐시를 두고, 몇 초 늦은 값은 괜찮다고 했으니 TTL로 무효화한다"가 설계다. 다음 절들은 이런 판단에 숫자를 붙이는 도구다.

2의 거듭제곱과 단위

컴퓨터의 크기는 2의 거듭제곱으로 늘지만 사람은 10의 거듭제곱으로 센다. 개략 추정에서는 2¹⁰ = 1,024를 천으로, 2²⁰을 백만으로 어림한다. 2¹⁰마다 오차가 2.4%씩 곱해져 쌓이므로 페타바이트쯤에서 12% 남짓 벌어지지만, 자릿수를 맞히는 것이 목적인 추정에서는 충분하다.

그래서 단위 이름도 둘로 나뉜다. 국제 표준(IEC)은 2의 거듭제곱 단위에 KiB·MiB·GiB 같은 이름을 따로 붙였고, KB·MB·GB는 10의 거듭제곱에 남겼다(NIST의 이진 접두어 설명). 현실에서는 둘이 섞여 쓰이므로, 추정할 때는 어느 쪽인지 정해 두고 끝까지 같은 쪽으로 계산한다. 이 노트의 예제는 10진 단위를 쓴다.

지연 시간 숫자

설계 판단의 상당 부분은 "무엇이 무엇보다 몇 배 느린가"에 달려 있다. 메모리 참조와 데이터센터 안 왕복, 대륙 간 왕복은 각각 자릿수가 몇 개씩 다르다. 이 차이를 머리에 넣어 두려고 많이 인용하는 목록이 있다. Peter Norvig의 글 Teach Yourself Programming in Ten Years에 실린 PC의 대략적인 연산 시간 표가 출발점이고, Jeff Dean이 2009년 LADIS 기조연설 Designs, Lessons and Advice from Building Large Distributed Systems에서 "Numbers Everyone Should Know"라는 이름으로 퍼뜨렸다. 지금 가장 많이 보는 판은 Jonas Bonér가 정리한 Latency Numbers Every Programmer Should Know gist다.

• 값은 낡았다: gist 스스로 2012년 무렵 숫자라고 밝힌다. 요즘 NVMe SSD의 4KB 무작위 읽기는 수십~100µs, 데이터센터 네트워크는 25~100Gbps가 흔하다. Colin Scott의 연도별 지연 시간 그림은 하드웨어 추세로 값이 어떻게 변해 왔는지 어림해 보여 준다. 다만 이것도 추세를 이어 그린 추정이다.
• 그래도 순서는 같다: 메모리는 SSD보다, SSD는 네트워크 왕복보다, 같은 건물 안 왕복은 대륙 간 왕복보다 여전히 자릿수가 다르게 빠르다. 대륙 간 왕복은 빛의 속도가 바닥이라 앞으로도 크게 줄지 않는다.
• 그래서 나오는 원칙: 디스크 탐색과 대륙 간 왕복을 피한다. 자주 읽는 것은 메모리에 두고, 보내기 전에 압축하고, 사용자 가까이에 데이터센터와 CDN을 둔다.

덧붙여, 2026년의 gist에는 LLM이 토큰 하나를 만들거나 첫 토큰을 내기까지 걸리는 시간 같은 새 줄이 더해졌다. 숫자 목록이 시대에 따라 계속 고쳐 쓰인다는 것 자체가 이 숫자들을 외우기보다 그때그때 재 봐야 하는 이유다.

가용성과 9의 개수

가용성은 시스템이 제대로 답한 시간(또는 요청)의 비율이다. 흔히 9의 개수로 말한다. 99.9%는 "9 세 개", 99.99%는 "9 네 개"다. 9가 하나 늘 때마다 허용되는 중단 시간은 10분의 1로 줄고, 만드는 비용은 크게 는다. 1년을 365일로 두고 직접 계산하면 아래와 같다.

• SLA·SLO·SLI: 재는 값이 SLI(예: 성공한 요청의 비율), 팀이 정한 목표가 SLO(예: 30일 동안 99.9%), 고객과 맺은 약속과 위반 시 보상이 SLA다. 보통 SLO를 SLA보다 엄격하게 잡아 여유를 둔다.
• 직렬 부품은 곱해진다: 요청이 99.9%짜리 부품 두 개를 차례로 거치면 전체는 0.999 × 0.999 ≈ 99.8%다. 부품이 늘수록 각 부품은 목표보다 더 높아야 한다. 반대로 같은 부품을 여럿 두고 하나만 살아 있으면 되게 만들면(병렬) 가용성이 오른다.
• 100%는 목표가 아니다: 사용자의 휴대폰 회선이나 와이파이가 이미 그보다 덜 믿음직하다. Google SRE 책의 Embracing Risk 장은 목표에서 남는 몫을 "오류 예산"으로 삼아 새 기능 배포의 속도를 정하는 방식을 설명한다. 같은 책 부록의 Availability Table에 9의 개수별 허용 중단 시간이 정리되어 있다.

개략 추정: 예제 하나

개략 추정(back-of-the-envelope estimation)은 봉투 뒷면에 적을 만큼 짧은 계산으로 규모를 어림하는 것이다. 목적은 정확한 값이 아니라 설계를 가르는 질문에 답하는 것이다. 서버 한 대로 되나, 백 대가 필요한가? 저장소가 테라바이트인가, 페타바이트인가? 사진을 올리는 글 공유 서비스를 예로 들어 보자.

결과에서 읽어 낼 것은 이렇다. 쓰기 QPS는 수백이라 쓰기 경로는 크게 걱정할 일이 아니다. 읽기는 쓰기의 25배이고 피크에 1만을 넘으니 캐시와 읽기 복제본이 필요하다. 저장량의 거의 전부는 사진이라 글 본문은 데이터베이스에, 사진은 객체 저장소에 두는 설계가 자연스럽다. 5년이면 복제까지 수십 PB라, 오래된 사진을 싼 저장 계층으로 옮기는 정책도 생각해야 한다.

• 어림해서 셈한다: 하루는 86,400초지만 약 10⁵초로 쳐도 된다. 그러면 하루 2천만 건은 초당 200건쯤이다. 정확한 값은 231이지만 결론은 같다.
• 단위를 적는다: 바이트와 비트(네트워크 대역폭은 보통 비트로 센다), KB와 KiB, 초당과 하루당을 섞으면 자릿수가 틀린다. 숫자마다 단위를 붙여 쓴다.
• 가정을 드러낸다: 평균이 아니라 피크로 설계하고, 피크 배수와 증가율을 가정으로 적는다. 가정이 바뀌면 계산 전체를 다시 할 수 있게 한다.
• 가장 큰 항만 본다: 위 예에서 글 본문 20GB는 사진 8TB 옆에서 무시해도 된다. 큰 항을 찾으면 설계를 어디에 집중할지가 보인다.
• QPS에서 서버 수로: 서버 한 대가 초당 처리할 요청 수를 가정하면(부하 시험으로 재는 것이 가장 좋다) 필요한 대수가 나온다. 한 대가 빠져도 견디게 하나 더 둔다(규모 확장의 단계 노트).