안녕하세요! 그로스로그 입니다!😊 🌱
서버 한 대를 키우는 대신 여러 대로 나누는 판단, 그리고 2차 행렬이든 4차 행렬이든 같은 절차로 밀고 나가는 손풀이. 4기 5회차 두 편입니다.
4기 5회차는 2025년 11월 중순입니다. 이번 회차는 큐레이션 두 편이에요. 회차마다 글의 수는 달라지지만, 한 편이든 세 편이든 기록은 이어집니다.
두 글이 다루는 대상은 완전히 다른데, 규모가 커질 때 무엇이 무너지는가를 나란히 보고 있습니다.
01
🏗️ 시스템 디자인(1): 확장성
박나은 님
시스템 설계를 공부하며 정리한 첫 글입니다. 책 한 권과 강의 하나를 같이 보며 정리했다고 밝혔어요.
설계에서 볼 속성을 여덟 가지로 먼저 나열합니다. 가용성·신뢰성·일관성·확장성·유지보수성·결함 감내성·지연 시간·처리량이요.
그중 확장성 하나만 골라 이번 편에서 다룹니다.
수직 확장과 수평 확장을 나누고, 수평 확장을 다시 네 범주로 쪼갰습니다.
2회차에서 Celery 글로 만났던 분입니다. 그때는 이미 쓰던 도구를 정리한 글이었는데, 이번에는 아직 안 배운 것을 배우러 간 기록이에요.
시작하는 문장이 정직합니다. 학교 다닐 때는 들을 이유를 못 느꼈고 시간도 없어서 안 들었는데, 일하다 설계 쪽을 건드릴 일이 생겨 필요성을 느꼈다고요. 필요가 먼저 오고 공부가 뒤따라온 순서입니다.
조금 더 들어가 보면
📋 여덟 개를 먼저 늘어놓은 것의 의미
이 글이 잘한 첫 번째가 범위를 그은 것입니다.
시스템 설계에서 볼 속성 여덟 개를 먼저 다 적어놓고, "이번 포스트에서는 확장성만"이라고 선언했어요. 이게 왜 좋으냐면, 지금 다루는 것이 전체 중 어디쯤인지가 보이기 때문입니다.
그리고 이 여덟 개는 서로 독립적이지 않습니다. 하나를 올리면 다른 하나가 내려가는 관계가 많아요.
· 일관성과 가용성 — 분산 시스템에서 네트워크가 끊겼을 때 둘 다 지킬 수는 없습니다. 최신 데이터를 보장하려면 응답을 거절해야 하고, 응답하려면 옛날 데이터를 줘야 합니다
· 지연 시간과 처리량 — 요청을 모아서 한 번에 처리하면 전체 처리량은 오르는데 개별 응답은 늦어집니다
· 확장성과 유지보수성 — 잘게 나눠 독립적으로 늘릴 수 있게 만들수록, 전체를 파악하기는 어려워집니다
그래서 설계는 여덟 개를 다 높이는 일이 아니라 무엇을 포기할지 정하는 일입니다. 저자가 여덟 개를 나란히 놓고 시작한 게 그 판단의 바탕을 미리 깔아둔 셈이에요.
⬆️ 수직 확장이 진짜로 위험한 지점
수직 확장의 단점으로 저자가 두 가지를 적었습니다. 자원을 무한히 늘릴 수 없다는 것, 그리고 장애 시 자동 복구나 다중화 방안이 없다는 것이요.
첫 번째보다 두 번째가 훨씬 중요합니다.
서버 성능을 두 배로 올리는 건 대개 가능합니다. 돈이 들 뿐이죠. 그런데 아무리 좋은 서버여도 한 대는 한 대입니다. 그 한 대가 죽으면 서비스 전체가 죽어요. 성능 문제가 아니라 단일 장애점 문제입니다.
그리고 이 문제는 트래픽이 적을 때는 아예 안 보입니다. 잘 돌아가고 있으니까요. 드러나는 순간이 곧 사고인 구조예요.
저자가 "실제 서비스에서는 사용하지 않는다"고 단정한 게 그래서 맞습니다. 규모 때문이 아니라 한 대가 죽으면 끝나는 구조를 쓸 수 없기 때문입니다.
수평 확장의 진짜 이득도 여기서 나옵니다. 처리량이 늘어나는 건 부수적이고, 한 대가 죽어도 나머지가 받아준다는 것이 본질이에요.
🧊 무상태가 왜 확장의 전제인가
네 범주 중 첫 번째에 나온 "무상태 웹 계층 유지" 가 이 글에서 가장 실무적인 항목입니다.
서버를 여러 대로 늘리면 사용자의 요청이 매번 다른 서버로 갈 수 있습니다. 그런데 로그인 정보를 서버 메모리에 들고 있으면, 1번 서버에서 로그인한 사람이 2번 서버로 가는 순간 로그인이 풀립니다.
이걸 대충 넘기는 방법이 있긴 합니다. 같은 사용자를 늘 같은 서버로 보내는 것이요. 그런데 이러면 문제가 생깁니다.
· 그 서버가 죽으면 거기 붙어 있던 사용자들의 상태가 통째로 사라집니다
· 서버를 늘려도 이미 붙어 있는 사용자는 안 옮겨가서 부하가 안 고르게 됩니다
· 배포할 때마다 누군가는 로그아웃됩니다
그래서 상태를 서버 밖으로 빼는 게 정답입니다. 저자가 쓴 "영구 저장소에 저장함으로써 필요에 따라 웹 서버를 쉽게 추가하거나 제거할 수 있다"가 그 이야기고요.
서버를 아무 때나 죽이고 새로 띄울 수 있게 만드는 것. 이게 수평 확장의 실제 조건입니다. 그리고 이 조건이 갖춰지면 자동 확장, 무중단 배포, 장애 복구가 전부 따라옵니다. 하나를 풀면 셋이 풀리는 자리예요.
🎯 안정 해시가 푸는 문제
두 번째 범주에서 저자가 짚은 안정 해시는 조금 덜 알려진 개념인데, 왜 필요한지 알면 확장 이야기의 핵심이 보입니다.
데이터를 서버 여러 대에 나눠 담을 때 가장 단순한 방법은 나머지 연산입니다. 키를 숫자로 바꿔서 서버 대수로 나눈 나머지가 가리키는 서버에 넣는 것이죠. 세 대면 키 % 3요.
문제는 서버를 한 대 늘리는 순간 생깁니다. % 3이 % 4가 되면 거의 모든 키의 자리가 바뀝니다. 캐시라면 전부 무효가 되고, 저장소라면 데이터를 거의 다 옮겨야 해요.
한 대를 늘렸을 뿐인데 전체가 흔들리는 것이죠.
안정 해시는 서버와 키를 같은 원 위에 올려두고 "시계 방향으로 가장 가까운 서버"에 배정하는 방식으로 이걸 풉니다. 서버가 하나 늘면 그 서버가 맡게 될 구간만 옮겨가고 나머지는 그대로예요.
저자가 적은 "재분배되는 키의 수를 최소화하여 효율적인 확장을 지원한다" 가 정확히 이 이야기입니다.
그리고 이게 이번 회차의 주제와 닿습니다. 좋은 확장 구조란 규모가 바뀔 때 방법이 바뀌지 않는 구조예요. 한 대를 더 붙이는 일이 전체를 다시 짜는 일이 되면, 그건 확장이 아니라 재구축입니다.
📝 원문에서는 이렇게 나눕니다
수평 확장을 네 범주로 정리하고 각각에 기술 요소를 붙였습니다.
2. 데이터 계층 및 저장소 확장 — 데이터 샤딩, 안정 해시, 데이터 복제, 캐싱
3. 비동기 처리 및 시스템 구성 요소의 분리
4. 콘텐츠 전송 효율화
세 번째가 이분의 2회차 글과 이어집니다. 그때 다룬 작업 큐가 바로 "비동기 처리 및 구성 요소의 분리"에 해당하거든요. 도구를 먼저 쓰고 나서 그 도구가 전체 지도의 어디에 있는지 나중에 확인한 셈입니다.
🚚 마지막 범주 — 안 보내는 게 가장 빠릅니다
네 번째 범주인 콘텐츠 전송 효율화는 앞의 셋과 성격이 다릅니다. 앞의 셋이 "일을 나눠서 더 많이 처리하자"라면, 이건 "애초에 그 일을 하지 말자" 쪽이에요.
같은 이미지를 만 명이 요청한다면, 서버가 만 번 응답하는 대신 사용자와 가까운 곳에 한 번 갖다 두면 됩니다. 그러면 서버는 그 만 번을 아예 안 받아요. 저자가 앞서 캐싱을 두고 적은 "데이터베이스의 부하를 줄이고 요청 처리의 지연 시간을 줄여" 가 같은 원리입니다.
확장 이야기에서 순서를 정할 때 이게 먼저입니다.
· 안 하게 만들기 — 캐시, 콘텐츠 전송망, 불필요한 요청 제거
· 미루기 — 지금 안 해도 되는 일을 큐로 보내기
· 나누기 — 그래도 남은 것을 여러 대에 분산
위에서부터 시도하는 게 싸고, 아래로 갈수록 구조가 복잡해집니다. 서버를 늘리는 건 마지막 수단이지 첫 수단이 아니에요. 캐시 한 겹으로 해결될 일에 샤딩을 도입하면 복잡성만 남습니다.
2회차에서 이분이 "단점은 하나다, 구조가 복잡해진다"고 적었던 것과 같은 감각입니다. 확장 기법은 전부 복잡성을 대가로 받아 갑니다.
📖 읽기와 쓰기는 확장 방법이 다릅니다
저자가 두 번째 범주에 데이터 복제를 넣어둔 게 이 이야기의 입구입니다. 조금 풀어보면 실무에서 가장 자주 쓰는 판단이 나와요.
대부분의 서비스는 읽기가 쓰기보다 훨씬 많습니다. 글 하나를 쓰면 수백 명이 읽고, 상품 하나를 등록하면 수천 번 조회되죠. 그래서 읽기와 쓰기를 같은 방법으로 늘리면 낭비가 생깁니다.
· 읽기를 늘리는 방법 — 복제본을 여러 개 두고 조회를 나눠 보냅니다. 대수를 늘리면 그만큼 늘어나요
· 쓰기를 늘리는 방법 — 복제로는 안 됩니다. 어느 복제본에 써야 할지 정해야 하고, 여러 곳에 쓰면 서로 어긋나니까요. 그래서 데이터를 쪼개는 쪽으로 갑니다
읽기 확장은 쉽고 쓰기 확장은 어렵다는 게 이 분야의 기본 사실입니다. 그리고 저자가 나열한 기술 요소가 정확히 그 순서예요. 복제와 캐싱(읽기)이 먼저 나오고, 샤딩과 안정 해시(쓰기)가 그 옆에 붙습니다.
여기서 대가도 같이 붙습니다. 복제본은 원본보다 조금 늦습니다. 방금 쓴 글을 바로 조회했는데 안 나오는 상황이 그래서 생겨요. 앞에서 이야기한 일관성과 가용성의 맞교환이 실제로 나타나는 자리입니다.
그래서 실무에서는 "방금 내가 쓴 것"만 원본에서 읽고 나머지는 복제본에서 읽는 식으로 절충합니다. 전부 최신을 보장하는 대신, 사용자가 어색함을 느끼는 자리만 막는 것이죠.
필요한 만큼만 보장하고 나머지는 놓아주는 것. 확장 설계가 계속 하는 일입니다.
큐레이터 노트
필요를 먼저 만나고 나서 공부하러 간 기록이라 뽑았습니다. 학교에서 안 들은 과목을 일하다 필요해져서 책과 강의를 함께 보며 정리했다는 시작이 정직해요.
구성도 좋았습니다. 볼 속성 여덟 개를 먼저 늘어놓고 그중 하나만 다루겠다고 범위를 그은 것, 그리고 수평 확장을 네 범주로 나눠 기술 요소를 배치한 것이요. 개념 지도를 먼저 그리고 채워 넣는 방식이라 다음 편이 어디에 들어갈지도 보입니다.
이분은 2회차와 7회차에도 나옵니다. 필요 → 정리 → 지도 순서로 이어지는 궤적이에요.
02
📐 선형대수 4장 연습문제 풀이
최태형 님
선형대수 교재의 4장 연습문제를 손으로 전부 푼 기록입니다. 이번 회차 분량만 3만 자가 넘어요.
주제는 정칙행렬과 역행렬입니다. 2차부터 4차까지 행렬을 놓고 역행렬이 있는지, 있으면 무엇인지 구합니다.
풀이가 한 줄도 건너뛰지 않습니다. 어떤 행연산을 했는지 화살표 위에 전부 적어뒀어요.
그리고 이건 1회차부터 10회차까지 이어지는 연재의 다섯 번째입니다. 1장부터 8장까지 갑니다.
이번 큐레이션에서 가장 설명하기 어려운 글이 이겁니다. 인용할 문장이 없거든요. 처음부터 끝까지 수식입니다.
그런데 회차를 나란히 놓고 보면 이 기록의 성격이 분명해집니다. 1회차부터 10회차까지 한 번도 빠지지 않고, 같은 교재를 1장에서 8장까지 진도대로 밀고 나간 기록이에요.
조금 더 들어가 보면
🧮 이 장이 실제로 하는 일
4장의 주제인 정칙행렬과 역행렬이 무엇인지부터 짚어두겠습니다.
행렬은 입력을 받아 출력을 내놓는 변환으로 볼 수 있습니다. 좌표를 넣으면 돌려주거나, 늘리거나, 찌그러뜨린 좌표가 나오는 식이죠. 역행렬은 그 변환을 되돌리는 변환입니다.
그런데 모든 변환이 되돌려지지는 않습니다. 서로 다른 두 입력이 같은 출력으로 뭉개져 버리면, 출력만 보고는 원래 무엇이었는지 알 수 없거든요. 정보가 사라진 것입니다.
저자가 푼 문제들에서 "정칙행렬이 아니다"라고 판정된 것들이 정확히 그런 경우입니다. 예를 들어 두 번째 문제의 행렬은 두 행이 서로 정반대라 소거하면 한 행이 통째로 0이 됩니다. 두 줄이 사실은 같은 정보였다는 뜻이에요.
그래서 이 장에서 반복되는 판정 규칙이 이렇게 읽힙니다. 소거해서 0인 행이 나오면 되돌릴 수 없다. 겹치는 정보가 있었다는 것이니까요.
⚙️ 절차가 차수를 가리지 않습니다
이 글에서 가장 눈에 띄는 건 2차 행렬을 풀 때와 4차 행렬을 풀 때 방법이 똑같다는 점입니다.
원래 행렬 옆에 단위행렬을 나란히 붙여놓고, 왼쪽이 단위행렬이 될 때까지 행연산을 반복합니다. 그러면 오른쪽에 역행렬이 남아요. 2차든 3차든 4차든 같은 절차를 더 여러 번 할 뿐입니다.
이게 이번 회차의 주제와 정확히 겹칩니다.
역행렬을 구하는 방법으로 다른 것도 있습니다. 여인수를 이용한 공식인데, 2차 행렬에서는 아주 간단해요. 그런데 차수가 올라가면 계산량이 폭발합니다. n차에서 필요한 항의 수가 n의 계승만큼 늘어나거든요. 4차만 돼도 사람이 손으로 하기 버겁고, 10차는 사실상 불가능합니다.
반면 소거법은 대략 n³ 정도로 늘어납니다. 컴퓨터가 큰 행렬을 다룰 때 쓰는 방법이 이쪽인 이유예요.
같은 답을 주는 두 방법인데, 하나는 커지면 못 쓰고 하나는 커져도 쓸 수 있습니다. 앞의 글에서 본 수직 확장과 수평 확장의 관계와 형태가 같습니다.
✍️ 왜 손으로 푸는가
지금은 행렬 계산을 시키면 즉시 답이 나옵니다. 그런데도 손으로 푸는 데는 이유가 있습니다.
절차를 손으로 한 번 통과해야 어디가 위험한지 알게 됩니다.
소거법에는 실제로 위험한 자리가 있습니다. 기준이 되는 자리의 값이 0이면 그 행으로 나눌 수 없어서 다른 행과 자리를 바꿔야 해요. 저자의 풀이에도 행을 맞바꾸는 연산이 계속 나옵니다.
이게 컴퓨터에서는 더 미묘한 문제가 됩니다. 값이 정확히 0이 아니라 0에 아주 가까울 때요. 나눗셈이 되긴 되는데 결과가 엄청나게 커지고, 그 뒤로 오차가 눈덩이처럼 불어납니다. 그래서 실제 수치 계산 라이브러리들은 매 단계에서 절댓값이 가장 큰 행을 골라 위로 올린 다음 나눕니다.
손으로 풀면서 "여기서 0이면 곤란하네"를 겪은 사람만 이 이야기를 이해할 수 있습니다. 답을 얻는 게 목적이 아니라 절차의 약한 지점을 몸으로 아는 게 목적인 것이죠.
🔗 5회차 ①과 이어집니다
같은 회차의 1차 큐레이션에 「선형대수와 AI」가 있었습니다. 벡터와 행렬이 AI에서 어떻게 쓰이는지 다룬 글이었어요.
두 글을 나란히 놓으면 재미있습니다. 한 사람은 선형대수가 어디에 쓰이는지를 보고, 한 사람은 그 도구 자체를 손으로 익히고 있습니다.
그리고 이 장의 내용이 실제로 그쪽과 닿아 있어요. 역행렬은 연립방정식을 한 번에 푸는 도구인데, 데이터로 직선을 맞추는 계산이 결국 연립방정식을 푸는 일이거든요. 그 계산식 안에 역행렬이 그대로 들어 있습니다.
거기서 방금 이야기한 문제가 다시 나타납니다. 역행렬이 없거나, 있어도 아슬아슬한 경우요. 데이터의 두 변수가 거의 같은 정보를 담고 있으면 행렬이 뭉개져서 계산이 불안정해집니다. 통계에서 다중공선성이라고 부르는 현상이고, 실무에서는 대각선에 작은 값을 더해 억지로 되돌릴 수 있게 만드는 방법을 씁니다.
"소거했더니 0인 행이 나왔다"가 데이터 분석에서는 "변수가 겹친다"로 나타나는 것이죠. 교재 4장이 그 자리에 있습니다.
📅 진도가 정해져 있다는 것의 이점
기록을 이어가는 일에서 가장 흔한 실패가 "다음에 뭘 쓰지"에서 멈추는 것입니다. 1회차에서 홍범영 님이 목차 열 개를 미리 걸어 그 문제를 없앤 것도 같은 맥락이었어요.
이 기록은 그 문제를 아예 다른 방식으로 풉니다. 교재의 진도를 그대로 따르는 것이요.
이 방식에는 분명한 이점이 있습니다.
· 다음에 무엇을 할지 고민할 일이 없습니다 — 4장 다음은 5장입니다
· 분량이 저절로 정해집니다 — 한 회차에 한 장씩이면 2주에 한 장이 됩니다
· 끝이 보입니다 — 8장까지라는 게 처음부터 정해져 있으니 진행률이 계산됩니다
성장일지처럼 2주에 한 번이라는 리듬이 정해진 활동에는 이 방식이 특히 잘 맞습니다. 매번 소재를 새로 찾아야 하는 형태는 바쁜 회차에서 무너지기 쉬운데, 진도가 정해져 있으면 바쁜 주에도 "일단 다음 장"이 있으니까요.
기록을 이어가는 방법이 하나가 아니라는 것도 4기 열 회차를 보면 알 수 있습니다. 홍범영 님은 목차를 걸었고, 노현주 님은 그때그때 겪은 것을 남겼고, 최태형 님은 교재를 따라갔어요. 셋 다 끝까지 갔습니다.
🎓 그리고 이건 시험 대비이기도 합니다
한 가지 실용적인 이야기를 덧붙이면, 이 형태의 기록은 나중에 그대로 복습 자료가 됩니다.
연습문제 풀이를 손으로 적어두면, 시험 전에 다시 볼 때 답만 있는 해설지보다 훨씬 낫습니다. 자기가 어느 단계에서 헤맸는지가 그 풀이의 길이와 순서에 남아 있기 때문이에요. 남의 해설은 가장 깔끔한 경로만 보여주는데, 실제로 필요한 건 "내가 여기서 막혔다"는 정보거든요.
같은 과목을 듣는 사람에게도 쓸모가 있습니다. 교재 연습문제의 전 과정 풀이는 검색해도 잘 안 나오는 자료라서요. 「자료가 드문 영역이다」에 해당하는 자리이기도 합니다.
🖨️ 수식을 웹에 올린다는 것
기술적으로 하나 짚어둘 게 있습니다. 이 기록을 블로그에 남기는 일 자체가 만만치 않습니다.
행렬은 줄과 칸이 있는 구조라 평범한 글자로는 표현이 안 됩니다. 그래서 수식을 적는 별도 표기법을 쓰고, 그걸 브라우저에서 그려주는 도구를 붙여야 해요. 저자의 풀이에 보이는 세로 막대와 화살표 표기가 전부 그 방식으로 적힌 것들입니다.
그래서 이 기록에는 눈에 안 보이는 작업이 한 겹 더 들어가 있습니다. 손으로 푼 것을 그대로 옮기는 게 아니라, 각 단계를 표기법으로 다시 적어야 하거든요. 행연산 표기를 화살표 위에 올리는 것도 하나하나 지정해야 나옵니다.
캡처해서 이미지로 올리는 쪽이 훨씬 쉽습니다. 그런데 그러면 검색이 안 되고, 복사가 안 되고, 확대하면 깨집니다. 글자로 남겨두면 나중에 찾아지고 다른 곳에 옮겨 쓸 수도 있어요.
어느 쪽이든 되는데 어려운 쪽을 골랐고, 열 회차 내내 그 방식을 유지했습니다. 형식을 지킨다는 게 이런 것들까지 포함하는 일이라, 기록의 성실함이 여기서도 드러납니다.
📝 원문에서는 이렇게 씁니다
첫 문제의 풀이가 이 기록의 성격을 다 보여줍니다.
그다음 화살표마다 무슨 연산을 했는지 적습니다. 첫 행에 3분의 1을 곱하고, 첫 행의 2배를 둘째 행에 더하고, 둘째 행의 7배를 첫 행에 더하고, 마지막에 둘째 행에 3을 곱합니다.
네 번의 연산으로 왼쪽이 단위행렬이 되고, 오른쪽에 역행렬이 남습니다.
그리고 판정을 문장으로 적어둡니다.
"소거행제형으로 변환하였는데 영행이 존재하므로, 정칙행렬이 아니다."
계산만 있고 결론이 없는 풀이가 아닙니다. 매번 무엇을 근거로 그렇게 판정했는지 한 줄씩 붙였어요. 그래서 나중에 자기가 다시 봐도, 남이 봐도 따라갈 수 있습니다.
큐레이터 노트
열 회차를 한 번도 빠지지 않고 같은 교재로 채운 기록이라 뽑았습니다.
인용할 문장이 없고 화려한 결론도 없습니다. 그런데 「시리즈로 이어진다」는 선정 신호가 이보다 선명한 자리는 드물어요. 한 편만 보면 연습문제 풀이인데, 열 편을 놓고 보면 한 권을 끝까지 통과한 기록입니다.
풀이를 한 줄도 건너뛰지 않은 것도 그렇습니다. 자기만 볼 메모라면 중간을 생략했을 텐데, 어떤 행연산을 했는지 화살표마다 적어둔 건 나중에 다시 볼 사람을 염두에 둔 형태예요. 6·8·9·10회차에서 계속 만나게 됩니다.
💡 두 편을 겹쳐 읽으며
커지면 못 쓰게 되는 방법이 있습니다
두 글이 같은 형태의 문제를 봅니다.
박나은 님의 글에서 수직 확장은 작을 때는 가장 간단한 방법입니다. 서버 하나 키우면 되니까요. 그런데 어느 지점을 넘으면 더 키울 수가 없고, 그때는 방법 자체를 바꿔야 합니다.
최태형 님이 푼 소거법도 마찬가지 자리에 있습니다. 2차 행렬이라면 공식 하나로 끝나는데, 차수가 커지면 그 공식은 못 씁니다. 소거법은 느려 보여도 차수가 커져도 같은 절차예요.
작을 때 가장 편한 방법과 커져도 버티는 방법이 다르다는 것. 두 글이 각자의 자리에서 같은 이야기를 합니다.
되돌릴 수 있게 만들어두기
또 하나 겹치는 게 있습니다. 되돌릴 수 있는가요.
역행렬은 말 그대로 되돌리는 변환입니다. 정보가 뭉개지지 않았을 때만 존재하고요.
시스템 쪽에도 같은 개념이 있습니다. 무상태 웹 계층이 그렇습니다. 서버에 상태를 안 들고 있으면 아무 때나 죽이고 새로 띄울 수 있어요. 되돌릴 수 있는 구조인 것이죠. 반대로 서버 메모리에 사용자 상태가 쌓여 있으면 그 서버는 함부로 못 내립니다.
되돌릴 수 있게 만들어두면 나중에 선택지가 남습니다. 5회차 두 편이 각각 그 이야기를 하고 있어요.
이번 회차에서 가져갈 것
1. 수직 확장의 진짜 문제는 성능이 아니라 한 대라는 것.
서버를 키우는 건 대개 가능합니다. 문제는 그 한 대가 죽으면 전부 죽는다는 것이고, 이건 트래픽이 적을 때는 안 보입니다.
2. 상태를 서버 밖으로 빼는 것부터.
세션을 메모리에 들고 있으면 서버를 늘려도 제대로 안 늘어납니다. 상태를 밖에 두면 자동 확장·무중단 배포·장애 복구가 한꺼번에 가능해집니다.
3. 데이터를 나눌 때 "한 대 늘리면 얼마나 옮겨야 하나"를 먼저 계산하기.
나머지 연산으로 나누면 서버 한 대를 추가할 때 거의 전부가 이동합니다. 늘리는 일이 재구축이 되면 그건 확장 구조가 아닙니다.
4. 설계 속성은 다 높이는 게 아니라 고르는 것.
일관성과 가용성, 지연 시간과 처리량은 서로 당깁니다. 무엇을 포기할지 정하지 않으면 결정이 안 됩니다.
5. 절차는 한 번 손으로 통과해보기.
답은 도구가 즉시 줍니다. 그런데 어디서 나눗셈이 위험해지는지, 어디서 오차가 커지는지는 손으로 해봐야 감이 옵니다.
4기 5회차는 2025년 11월 중순이었습니다.
시스템 설계 공부와 전공 교재 풀이라는 아주 다른 자리에서, 두 분이 나란히 규모가 커져도 버티는 방법에 대해 썼습니다. 한 분은 서버를 나누는 이야기로, 한 분은 차수가 올라가도 변하지 않는 절차로요.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
좋은 글 남겨주신 박나은 님, 최태형 님께 감사드립니다. 그리고 4기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.