• 목록

서비스 이용자가 늘면 서버를 더 큰 사양으로 바꿀지, 같은 역할의 서버를 여러 개 둘지 고민하게 됩니다. 전자는 수직 확장, 후자는 수평 확장으로 설명할 수 있습니다.

두 방식은 자원을 늘리는 방향이 다르며 실제 효과는 병목과 애플리케이션 구조에 따라 달라집니다. 여기서는 작은 웹 서비스를 가정해 용어와 확인 순서를 정리합니다.

AI 생성 삽화 · 더 큰 서버 한 대와 여러 서버를 비교하는 개념 삽화입니다. 실제 장비 성능이나 권장 구성을 나타내지는 않습니다.

핵심 정리
수직 확장은 자원 한 개의 용량을 바꾸고, 수평 확장은 같은 역할의 인스턴스 수를 바꿉니다. 확장 방향과 자동화 여부는 별개이며, 서버 수만큼 처리량이 늘어난다고 가정하지 않고 병목과 상태 공유를 확인해야 합니다.

1. 수직 확장은 한 자원의 크기를 바꾸는 방식입니다

수직 확장은 서버 한 대에 제공하는 CPU나 메모리 등 자원 용량을 늘리거나 줄이는 방향입니다. 더 큰 가상 머신 사양으로 변경하는 상황이 대표적인 예입니다.

Microsoft의 자동 확장 안내도 자원 용량 변경을 수직 확장으로 구분합니다. 다만 사양 변경 과정에서 재시작이나 재배치가 필요한지는 사용하는 서비스와 구성에 따라 확인해야 합니다.

‘더 큰 서버로 바꾸면 중단이 없다’고 일반화할 수는 없습니다. 가상의 이미지 변환 프로그램이 메모리 부족으로 작업을 마치지 못한다면 메모리를 늘리는 실험을 검토할 수 있습니다.

이때 CPU까지 함께 늘어나는 상품인지와 실제 부족한 자원이 무엇인지 구분해 기록합니다. 사양 이름이 높아졌다는 사실보다 실패하던 작업이 완료되는지와 처리 시간이 어떻게 바뀌는지가 확인할 결과입니다.

2. 수평 확장은 같은 역할을 나누어 수행하게 합니다

수평 확장은 같은 역할의 인스턴스를 추가하거나 제거하는 방향입니다. 웹 요청을 받는 서버를 한 대에서 여러 대로 늘리고 요청을 나누는 구성을 생각해볼 수 있습니다.

새 서버를 띄우는 일과 실제 요청을 받을 준비가 되는 일은 구분해야 합니다. 애플리케이션이 시작되었는지, 필요한 설정을 읽었는지, 요청을 정상 처리하는지 확인한 뒤 트래픽을 보내는 흐름이 필요합니다.

가상의 상품 목록 서비스에서 서버 A와 B가 같은 목록 조회 기능을 제공한다면 사용자의 요청을 둘로 나눌 수 있습니다. 그러나 한쪽에만 최신 프로그램이 있거나 서로 다른 설정을 읽는다면 응답이 달라질 수 있습니다.

수평 확장을 단순 복사 작업으로 보기보다 같은 역할을 여러 실행 단위가 일관되게 수행하는 구조로 이해하면 운영 항목이 더 잘 보입니다.

3. 병목이 다른 곳에 있으면 확장 효과가 제한됩니다

웹 서버를 늘렸는데 응답 시간이 거의 줄지 않는 상황을 가정해봅니다. 요청 대부분이 공통 데이터베이스의 느린 조회를 기다리고 있다면 웹 서버 수만 바꾸어서는 기다리는 원인이 그대로일 수 있습니다.

반대로 계산 작업이 웹 서버 CPU를 오래 점유하고 있고 요청을 나누기 쉬운 구조라면 다른 결과가 나올 수 있습니다. 요청이 들어온 시간, 애플리케이션 처리 시간, 외부 서비스 대기 시간처럼 구간을 나누어 보면 자원을 바꿀 위치를 좁힐 수 있습니다.

가상 실험 노트에는 ‘서버 두 대로 변경 후 전체 처리량, 오류 수, 데이터베이스 대기 시간을 비교한다’고 적을 수 있습니다. 서버 수가 두 배가 되었다는 이유로 결과도 두 배라고 미리 쓰지 않습니다.

공유 자원과 요청 분배, 네트워크 조건 등이 실제 결과에 영향을 줍니다. 확장 성공 여부는 장비 목록보다 사용자가 요청을 완료하는 과정이 목표에 맞게 바뀌었는지로 판단할 수 있습니다.

4. 여러 서버가 함께 사용할 상태를 확인합니다

서버 한 대의 메모리에만 사용자 상태를 보관한 서비스를 여러 대로 늘리면 다음 요청이 다른 서버에 도착했을 때 이전 상태를 찾지 못할 수 있습니다. Twelve-Factor의 프로세스 원칙은 상태 없는 프로세스와 외부 저장소에 두는 지속 데이터를 설명합니다.

이는 수평 확장을 생각할 때 참고할 설계 원칙이며 모든 프로그램이 자동으로 이 구조를 갖추었다는 뜻은 아닙니다. 가상의 견적 작성 화면에서 입력 중인 내용을 서버 A 메모리에만 두었다면 서버 B가 그 내용을 어떻게 찾을지 질문해볼 수 있습니다.

업로드 파일이 한 서버의 로컬 폴더에만 있는 경우도 비슷한 질문이 생깁니다. 어떤 상태를 공유해야 하는지, 어디에 저장하는지, 동시에 수정하면 어떻게 처리하는지를 구분합니다.

외부 저장소를 도입하는 것만으로 모든 문제가 끝나지는 않으므로 데이터 접근과 실패 시 동작도 확인합니다.

5. 자동 확장은 방향이 아니라 운영 방식입니다

수평과 수직은 무엇을 바꾸는지에 관한 구분이고, 자동과 수동은 누가 어떤 기준으로 변경하는지에 관한 구분입니다. 운영자가 직접 서버 수를 늘려도 수평 확장이며, 서비스가 지표에 따라 용량을 조정하는 기능을 제공할 수도 있습니다.

Microsoft 문서는 자동 확장 구성 요소로 지표 수집, 판단 로직, 실제 확장 동작과 검증을 설명합니다. 어떤 지표를 볼지와 어느 상태에서 늘리거나 줄일지를 정해야 합니다.

가상 예약 서비스라면 요청 수가 적어도 특정 작업이 오래 걸릴 수 있으므로 요청 개수만으로 충분한지 실험할 수 있습니다. 자원을 늘리는 데 걸리는 시간과 감소 시 진행 중인 요청을 처리하는 방식도 살펴봅니다.

조건을 너무 단순하게 잡으면 필요한 시점에 늦게 늘거나 불필요하게 변동할 수 있으므로, 실제 기록을 보고 설정을 조정할 수 있게 준비합니다.

6. 비교 실험에서는 입력 부하와 성공 기준을 맞춥니다

두 확장 방식을 비교하려면 실험에 들어오는 요청의 종류와 양이 비슷해야 합니다. 첫 실험은 가벼운 목록 조회이고 두 번째는 큰 파일 변환이라면 장비 차이만 비교했다고 말하기 어렵습니다.

가상의 실험 계획에는 조회 요청과 변환 요청의 비율, 동시에 실행할 수, 시험 시간을 적습니다. 결과에는 평균 응답 시간만이 아니라 느린 요청의 분포와 오류, 완료한 작업 수를 함께 남길 수 있습니다.

특정 요청 몇 개가 오래 걸리는 문제는 평균만으로 잘 드러나지 않을 수 있기 때문입니다. 실험 중 프로그램 버전을 바꾸거나 캐시 상태가 크게 달라졌다면 그 변경도 적습니다.

비용을 비교할 때에는 사양의 표시 가격뿐 아니라 사용 시간과 함께 필요한 저장소, 전송 등의 조건을 확인해야 하며 실제 견적 자료를 기준으로 계산합니다.

7. 작은 서비스에서는 현재 제약부터 문장으로 적습니다

처음부터 복잡한 분산 구조를 결정하기보다 현재 무엇이 부족한지 설명해보는 편이 좋습니다. ‘파일 한 개를 처리할 메모리가 부족하다’, ‘동시에 들어오는 독립 요청이 많다’, ‘데이터베이스 조회를 오래 기다린다’는 서로 다른 문제입니다.

각각 자원 용량, 작업 분배, 공통 의존성이라는 다른 확인 지점으로 이어집니다. 가상 설계 메모에는 문제 관찰, 확장 후보, 필요한 구조 변경, 실험 방법, 되돌릴 기준을 차례로 적을 수 있습니다.

수직 확장과 수평 확장은 반드시 둘 중 하나만 영구적으로 선택해야 하는 관계도 아닙니다. 실제 구성에서 두 방향을 함께 사용할 수 있지만 각 변경의 효과를 따로 확인해야 합니다.

용어를 외우는 데서 끝내지 않고 현재 병목과 연결해 설명할 수 있다면 확장 논의를 더 구체적으로 시작할 수 있습니다.

8. 자주 묻는 질문

Q1. 수평 확장과 자동 확장은 같은 말인가요?

수평 확장은 인스턴스 수를 바꾸는 방향이고 자동 확장은 조건에 따라 변경을 수행하는 방식입니다. 사람이 직접 서버 수를 늘리는 것도 수평 확장입니다.

Q2. 서버를 두 배로 늘리면 성능도 두 배인가요?

그렇게 보장할 수 없습니다. 공통 데이터베이스나 외부 서비스의 병목, 요청 분배와 상태 관리 조건을 함께 측정해야 합니다.

Q3. 수직 확장은 항상 서비스가 중단되나요?

필요한 재시작이나 재배치 여부는 자원 종류와 서비스에 따라 다릅니다. 사용하는 제품의 변경 절차와 실제 운영 구성을 확인해야 합니다.

Q4. 초기 프로젝트는 무엇부터 살펴보면 좋나요?

느린 요청이 어느 구간에서 시간을 쓰는지와 부족한 자원을 먼저 확인합니다. 그 결과를 바탕으로 한 가지 변경을 시험하고 효과를 비교합니다.

참고 자료

• Microsoft Azure Architecture Center: Autoscaling
• The Twelve-Factor App: Processes