**[Network] DNS의 구조와 동작방식 **

이 글에서 다룰 내용

Email이 도메인 기반으로 전달되는 구조를 중심으로, 주소 구성과 전달 방식이 어떻게 연결되는지 정리함.

이후 DNS가 메일 전달에 어떻게 관여하는지 이해할 수 있도록 기본 구조를 함께 다룸

학습 목표

• Email 주소와 Domain의 관계를 이해할 수 있음
• Domain을 기준으로 메일이 전달되는 구조를 이해할 수 있음
• Email 흐름에서 Domain이 가지는 역할을 파악할 수 있음

Domain과 Email 구조

Email 전송은 사용자 단위가 아니라 Domain 단위로 처리됨. 메일 주소에 포함된 도메인은 전달 경로를 결정하는 기준으로 사용됨

메일은 특정 사용자에게 직접 전달되는 것이 아니라, 먼저 해당 도메인을 담당하는 서버로 전달된 뒤 내부에서 사용자에게 분배되는 구조를 가짐

Email 주소와 Domain

Email 주소는 local-part@domain 형태로 구성됨

• local-part: 사용자 식별자
• domain: 메일을 처리할 서버를 식별하는 정보

예를 들어 user@example.com에서 example.com은 메일을 수신할 서버를 찾기 위한 기준으로 사용됨

메일 전달 과졍에서 경로 결정은 domain을 기준으로 수행되며, 사용자(local-part)는 전달 경로 선택에 사용되지 않음

Domain 기반 전달 구조

메일 전송 흐름은 도메인을 기준으로 구성됨

• 발신 서버는 수신자의 domain을 기준으로 대상 서버를 조회
• 조회된 서버로 메일을 전달
• 수신 서버 내부에서 사용자 계정으로 분배

이 흐름은 MTA 동작과 직접 연결됨 Relay 단계에서 MTA는 수신자의 domain을 기준으로 다음 전달 대상 서버를 선택함

전송 구조는 다음과 같이 정리됨:

• 도메인 단위로 전달 경로 결정
• 서버 단위로 메일 전달 수행
• 사용자 단위로 최종 분배

이후 DNS(MX) 조회와 Email 인증 메커니즘이 동작함

DNS와 Email 전달

Email 전송에서 DNS는 전달 경로를 결정하는 역할을 수행함. 발신 서버는 수신자의 도메인을 기준으로 DNS 조회를 수행하고, 그 결과를 바탕으로 메일을 전달할 대상 서버를 선택함

이 과정은 Relay 단계에서 수행되며, 실제 메일 전달 흐름과 직접 연결됨

MX 레코드 역할

MX 레코드는 특정 도메인의 메일을 처리하는 서버를 지정하는 레코드임

[ DNS Response ]

메일을 전송하려는 서버는 수신자의 도메인에 대해 MX 레코드를 조회하고, 해당 도메인의 메일 서버 목록을 확인함

이대 반환되는 값은 단일 서버가 아니라, 여러 개의 메일 서버일 수 있음. 각 서버는 우선순위와 함께 제공되며, 전달 대상 선택 기준으로 사용됨

MX 레코드는 Email 전송에서 다음 서버를 결정하는 기준이 되며, 일반적인 웹 트래픽에서 사용하는 A 레코드와는 목적이 다름

MX 우선순위

MX 레코드는 우선순위 (priority) 값을 포함함 이 값은 메일 서버 선택 순서를 결정하는 기준으로 사용됨

• 숫자가 낮을수록 높은 우선순위
• 동일 도메인에 여러 MX 레코드 존재 가능

전송 서버는 우선순위가 가장 높은 서버부터 연결을 시도함. 해당 서버가 응답하지 않거나 전달이 실패할 경우, 다음 우선순위 서버로 전달을 시도함

이 구조를 통해 메일 시스템은 장애 상황에서도 전달 경로를 유지할 수 있음

메일 라우팅 흐름

메일 전달 과정에서 DNS 조회는 다음 흐름으로 수행됨

• 수신자의 domain 추출

• 해당 domain의 MX 레코드 조회
• 반환된 MX 목록 중 우선순위 기준 서버 선택
• 선택된 서버로 SMTP 연결 및 메일 전달

이 과정은 MTA에서 수행되며, Email 전송 경로를 결정하는 핵심 단계

메일은 이 흐름을 따라 전달되며, 중간에 여러 MTA를 거치는 경우에도 동일한 방식을 다음 전달 대상이 결정됨

Email 관련 DNS 레코드

Email 전송에서는 DNS는 단순 이름 해석이 아니라, 메일 처리와 인증에 필요한 정보를 함께 제공함. 메일 흐름에서는 특정 레코드만 사용되며, 각각의 역할이 구분되어 동작함

🔸MX 레코드

MX 레코드는 특정 도메인의 메일을 처리할 서버를 지정하는 레코드

메일을 전송하려는 서버는 수신자의 도메인을 기준으로 MX 레코드를 조회하고, 반환된 메일 서버 목록 중 하나를 선택하여 전달을 수행함.

MX 레코드는 여러 개의 레코드가 함께 설정될 수 있으며, 우선 순위 값을 기준으로 전달 대상이 결정됨

MX 레코드에서 확인되는 정보

▪️ 도메인 이름
▪️ 레코드 타입 (MX)
▪️ 우선 순위
▪️ 메일 서버 호스트 이름

메일 서버는 호스트 이름 형태로 반환되며, 실제 연결을 위해서는 해당 호스트에 대한 A 레코드 추가로 조회하게 됨.

🔸TXT 레코드 (SPF/DMARC)

TXT 레코드는 문자열 형태의 데이터를 저장하는 레코드

[ DNS Response ]

Email에서는 발신 검증과 정책 전달에 사용됨

대표적으로

• SPF
  • 해당 도메인에서 메일을 보낼 수 있는 서버 목록을 정의하는 구조
  • 발신 서버의 정당성 확인에 사용
    
    
• DMARC
  • SPF와 DKIM 결과를 기반으로 정책을 적용하는 구조
  • 인증 실패 시 처리 방식과 리포트 수신 정보 포함
    

TXT 레코드는 전달된 메일의 신뢰성을 판단하는 기준으로 사용됨

🔸CNAME 레코드 (DKIM)

CNAME 레코드는 특정 모데인을 다른 도메인으로 매핑하는 레코드

[ DNS Response ]

Email에서는 DKIM 서명 검증을 위한 키 조회에 사용됨

DKIM은 메일에 포함된 서명을 검증하기 위해 공개키를 필요로 하며, 이 키는 DNS를 통해 조회됨. 이때 실제 키는 공급사 도메인에 존재하고, CNAME 레코드를 통해 해당 위치로 연결됨

수신서버는 DKIM 검증 과정에서

• 도메인에서 지정된 selector를 기준으로 DNS 조회 수행
• CNAME을 통해 실제 키가 있는 위치로 이동
• 해당 위치에서 공개키를 조회하여 서명 검증 수행

이 구조를 통해 DKIM 키 관리와 검증이 이뤄짐

Email 인증과 DNS

Email 인증은 도메인을 기준으로 수행됨. 인증에 필요한 정보는 DNS에 저장되며, 수신 서버는 해당 정보를 조회하여 메일의 신뢰성을 판단함

인증은 메일 전송 이후 단계에서 수행되며, 전달된 메시지와 DNS 정보를 비교하는 방식으로 동작함

⭐정리 포인트

• SPF → 발신 서버 검증

• DKIM → 메시지 서명 검증
• DMARC → 정책 및 최종 처리

🔹SPF 구조

SPf: Sender Policy Framework는 발신 서버가 해당 도메인을 대표하여 메일을 보낼 수 있는지 검증하는 방식

수신 서버는 메일을 수신하면서 서버의 IP 주소와 발신 도메인을 확인하고, DNS에서 SPF 정책 (TXT 레코드)을 조회함

이후 해당 IP가 정책에 포함되어 있는지를 비교하여 허용 여부를 판단함

SPF 검증 요소

• 발신 도메인
• 발신 서버 IP
• DNS에 정의된 SPF 정책

SPF는 전송 경로 기준 검증이며, 메일 내용 자체는 검증하지 않음.

🔹DKIM 구조

DKIM: DomainKeys Identified Mail은 메일에 포함된 서명을 기반으로 메시지 무결성과 도메인 책임성을 검증하는 방식

발신서버는 메일에 전자서명을 추가하며, 이 서명은 도메인과 연결된 개인키로 생성됨 수신 서버는 메일을 수신한 뒤 서명을 추출하고, DNS에서 공개키를 조회하여 서명의 유효성을 검증함

이 과정에서 공개키는 DNS TXT 레코드에 저장되며, CNAME을 통해 외부 도메인으로 연결되는 구조를 사용할 수 있음

DKIM 검증 요소

• 메일 서명 (DKIM-Signature)
• selector 및 domain 정보
• DNS에 저장된 공개키

🔹DMARC 구조

DMARC: Domain-based Message Authentication, Reporting and Conformance는 DKIM 결과를 기반으로 정책을 적용하는 구조

수신 서버는 SPF와 DKIM 검증 결과를 확인하고, 발신 도메인과 정렬(alignment)을 평가한 뒤, DNS에 정의된 DMARC 정책에 따라 메일을 처리함

DMARC 레코트에 포함되는 정보

• 정책 (none / quarantine / reject)
• 보고서 수신 주소 (rua)
• 정렬 기준

DMARC는 인증 결과를 조합하여 최종 처리 방식을 결정하는 역할

⭐운영 핵심 포인트

DNS 설정은 Email 전달과 인증에 직접적인 영향을 주기 때문에, 단순 설정이 아니라 운영 기준으로 관리되어야 함. 특히, MX, TXT(SPF,DMARC), CNAME(DKIM)은 서로 연결되어 동작하므로, 전체 흐름을 기준으로 관리하는 것이 중요함

MX 설정

MX 레코드는 메일 전달 경로를 결정하는 핵심 요소이기 때문에 설정 오류가 발생하면 메일이 전달되지 않거나, 예상하지 못한 서버로 전달될 수 있음

확인해야할 항목

• MX 레코드가 실제 메일 서버를 가르키는지 확인
• 여러 MX가 존재할 경우 우선순위 설정이 의도대로 구성되었는지 확인
• MX에 이정된 호스트가 실제로 SMTP 수신이 가능한 상태인지 확인

또한 MX 레코드는 도메인 단위로 적용되므로, 서브도메인이나 별도 도메인을 사용하는 경우 각각 개별 설정이 필요함

SPF 설정

SPF는 발신 서버 검증에 사용되므로, 실제 메일을 발송하는 모든 시스템이 포함되어야 함. 일부 발신 서버가 누락되면 정상 메일도 인증 실패로 처리될 수 있음

확인해야할 항목

• 자사 메일 서버뿐 아니라 외부 서비스 (메일 발송 서비스, CRM 등)가 포함되어 있는지 확인
• include 구문을 통해 외부 서비스 SPF를 정확히 참조하고 있는지 확인
• 정책 (~all, -all)이 운영 단계에 맞게 설정되어 있는지 확인

SPF는 전달 과정에서 변경이 발생할 수 있으므로, 포워딩 환경에서는 인증 결과가 달라질 수 있음

DNS 변경 및 검증

DNS 설정은 변경 이후 즉시 반영되지 않으며, TTL(Time To Live)에 따라 일정 시간 동안 기존 값이 유지될 수 있음

변경 이후 반드시 확인해야할 항목

• DNS 조회를 통해 실제 레코드가 정상적으로 반영되었는지 확인
• 메일 헤더를 통해 SPF / DKIM / DMARC 결과가 기대값과 일치하는지 확인
• 메일 송수신 테스트를 통해 실제 전달 흐름이 정상 동작하는지 확인

DNS는 Email 전송의 기반이 되는 요소이기 때문에, 변경 시에는 반드시 검증 과정을 포함해야 함.

정리

Email 전송에서 DNS는 전달 경로와 인증에 필요한 정보를 제공하며, 수신 버서는 이를 기반으로 메일의 신뢰성을 판단함

메일은 수신자의 도메인을 기준으로 전달 대상 서버를 선택하고, DNS에서 MX 레코드를 조회하여 메일 서버를 확인함. 이후 선택된 서버에 대해 A 레코드를 조회하고, 해당 IP로 SMTP 연결이 수행됨

전달 과정에서 DNS는 메일 처리에 필요한 정보를 함께 제공함. MX는 전달 경로를 정의하고, TXT는 정책과 인증 정보를 제공하며, CNAME은 DKIM키 조회를 위한 연결 역할을 수행함

메일이 수신 서버에 도달하면 DNS에 저장된 정보를 기반으로 인증이 수행됨 SPF는 발신 서버를 검증하고, DKIM은 메시지 서명을 검증하며, DMARC는 이 결과를 기반으로 처리 정책을 결정함

이 구조를 통해 Email은

• 전달 경로는 MX로 결정되고,
• 신뢰 검증은 TXT와 CNAME 기반으로 수행되며,
• 최종 처리는 DMARC 정책에 따라 결정됨

전체 흐름은 다음과 같음

Domain → MX 조회 → Mail Server 선택 → A 조회 → SMTP 전달
                                      ↓
                         SPF / DKIM / DMARC 검증

이 글에서 다룰 내용

이 글에서는 Email이 실제로 어떤 구조를 통해 전달되는지, 전체 아키텍처 관점에서 정리함

단순히 메일이 오가는 과정이 아닌, MUA·MSA·MTA·MDA로 역할이 분리된 구조를 기반으로 Submit과 Relay가 어떻게 나뉘고, DNS(MX)를 통해 전달 경로가 어떻게 결정되는지까지 연결해서 설명함

학습 목표

• Email 전송을 구조와 흐름 기준으로 이해할 수 있음

• MUA·MSA·MTA·MDA의 역할과 책임을 구분할 수 있음
• Sumbit과 Relay의 구조 차이를 이해할 수 있음
• Email Security가 개입되는 위치의 연결 가능 상태를 확보할 수 있음

Email 전송 구조 개요

Email은 여러 구성요소가 역할을 나누어 처리하는 구조를 가짐. 메일은 생성된 이후 하나의 서버를 거치는 것이 안니라, 여러 서버를 순차적으로 통과하여 전달됨.

각 서버는 메일을 수신하면 다음 서버로 바로 전달하기 않고, 내부 Queue에 저장한 뒤 전달 가능한 시점에 전송을 수행함

이 전송 방식이 Sotre & Forward 모델이며, 네트워크 지연이나 수신 서버 상태에 영향을 받은 환경에서 안정적인 전달을 가하게 함. 능 전달 경로는 수신 도메인을 기준으로 결정되며, 도메인에 설정된 MX 레코드를 조회하여 목적지 서버를 선택하고, 해당 서버로 SMTP 연결을 통해 메일을 전달함 이 과정에서 하나 이상의 중간 서버를 거치는 홉 기반 전송이 발생하게 됨

이 구조는 SMTP(RFC 5321)와 Internet Mail Architecture(RFC 5598)에서 정의됨

Email 구성요소

Email 시스템은 역할 단위로 구성되며, 각 구성요소는 전송 흐름 내에서 서로 다른 책임을 가짐

전체 구조

메일은 사용자에게 시작해 사용자로 전달됨

전송 과정은 다음과 같은 흐름으로 구성됨

MUA: Mail User Agent

메일을 생성하고 확인하는 클라이언트 역할

사용자는 이 단계에서 메시지를 작성하고 전송 요청을 발생시킴. 생성된 메시지는 이후 단계에서 전송 처리됨

MSA: Mail Submission Agent

사용자가 생성한 메일을 받아 전송 가능한 상태로 처리하는 서버

이 단계에서 사용자 인증이 수행되며, 인증된 사용자만 메일을 전송할 수 있음

MSA 주요 수행 동작

• STMP AUTH 기반 사용자 인증
• 기본 정책 적용
• 내부 전달 준비

메일은 이 단계에서 발신자 기준으로 신뢰가 부여된 상태로 전환됨

MTA: Mail Transfer Agent

메일 전달을 담당하는 핵심 구성요소

수신 도메인을 기준으로 DNS 조회를 수행하고, MX 레코드를 통해 전달 대상 서버를 결성함

MTA 주요 수행 동작

• MX 조회를 통한 목적지 선택
• SMTP 연결을 통한 메일 전달
• 전송 실패 시 큐 기반 재시도

메일은 이 단계에서 여러 서버를 거쳐 전달되며, 전체 전송 흐름이 유지되게 됨.

MDA: Mail Delivery Agent

메일이 최종적으로 저장되는 단계

전달이 완료된 메일은 Mailbox에 저장되며, 사용자는 이후 클라이언트를 통해 메일을 확인함

Email 전송 흐름

Email 전송은 Submit, Relay, 수신 처리, Delivery 단계로 구분됨. 각 단계를 서로 다른 역할과 처리 기준을 가짐

Submit

사용자가 메일을 전송하는 단계.

사용자 인증이 수행되며, 전송 구간은 TLS 기반으로 보호됨 이 단계에서 메일은 전송 가능한 상태로 처리됨

Relay

메일어 서버 간에 전달되는 단계

MTA는 수신 도메인의 MX 레코드를 조회하여 목적지 서버를 결정하고, SMTP를 통해 메일을 전달함

이 과정에서 내부 릴레이, 외부 게이트웨이, 다중 경유 경로가 포함될 수 있으며, 전송 실패 시 재시도 로직이 적용됨

수신 처리

수신 서버에 도달한 메일은 저장 이전에 검증 단계를 거침

수행되는 동작

• SPF / DKIM / DMARC 기반 도메인 인증
• 스팸 및 악성 콘텐츠 검사
• 정책 기반 필터링

대부분의 Email Security 기능이 이 구간에서 적용됨

Delivery

메일이 Mailbox에 저장되고, 사용자 접근이 가능한 상태로 전환됨.

이 시점에서 전송 과정이 종료 됨

Submit vs Relay

Submit과 Relay는 전송 흐름 내에서 구분되는 두 영역이며, 처리 기준과 신뢰 형성 방식이 다름

Submit

• 사용자 → 서버
• 사용자 인증 기반 처리
• 정책 적용 가능

사용자 신원을 기준으로 처리되느 ㄴ구간

Relay

• 서버 → 서버
• 도메인 및 경로 기반 전달
• 기본적으로 인증 없음

메일이 네트워크를 통해 전달되는 구간

차이

두 구간은 신뢰 형성 기준이 다르게 적용됨

Relay 구간에서는 발신자 신원을 직접 검증하지 않기 때문에, 도메인 인증 및 보안 검증이 필요함. 이 구조가 Email Security 기술의 적용 배경이 됨

운영 핵심 포인트

구간 분리

Submission과 Relay는 포트와 정책 기준으로 구분됨.

• 587 → Submission
• 25 → Relay

추척

메일은 여러 서버를 거치므로 전달 경로 추적이 필요함

• Recived 헤더
• Message-ID

이 정보를 통해 메일의 이동 경로와 처리 상태를 확인할 수 있음

역할 구분

각 구성요소는 역할과 책임이 명확하게 분리되어야 함

• 제출 처리 영역
• 전달 처리 영역
• 저장 영역

이 구분이 운영 및 장애 대응의 기준이 됨

정리

Emila은 역할 기반으로 분리된 구성요소가 협력하여 동작하는 전송 시스템

전체 흐름

• Submit → Relay → Delivery

각 단계는 서로 다른 책임을 가짐

• Submit → 사용자 인증 및 전송 시작
• Relay → 서버 간 전달 및 경로 선택
• Delivery → 최종 저장 및 사용자 접근

전달 구조 핵심

메일은 단일 서버가 아니라 여러 서버를 거치며 전달되며, 각 서버는 메일을 저장한 뒤 다음 서버로 전달하는 Store & Forward 방식으로 동작

경로 결정 방식

• DNS 조회를 통해 수신 도메인의 MX 레코드를 확인
• MX 우선순위에 따라 전달 대상 서버가 선택됨

신뢰 구조

• Submit → 사용자 인증 기반 신뢰
• Relay → 도메인 및 경로 기반 신뢰

Relay 구간에서는 발신자 신원을 직접 확인하지 않기 때문에, 추가적인 인증 및 보안 검증이 필요함

이 글에서 다룰 내용

이 글에서는 VM 리소스 중 vRAM과 Disk 설정값이 실제로 무엇을 의미하는 지 정리함

가상화 환경에서 Memory와 Disk는 8GB RAM, 100GB Disk와 같은 설정값은 단순히 숫자 이상의 의미를 가지며, 그 수치가 어디까지를 보장하고 어디까지를 보장하지 않는지를 구분해서 해석해야 함

이 글에서는 vRAM의 인식 구조, Memory Overcommit, Ballooning, 가상 디스크의 구조, Thin / Thick Procision, I/O 경합 구조를 살펴본 뒤 논리적 보장, 물리적 보장, 성능 보장의 차이를 정리함

즉, 이 글은 vRAM과 Disk 설정값을 "용량"이 아니라 "구조와 보장 범위"의 관점에서 해석하기 위한 단계임

학습 목표

이 글을 통해 다음을 이해하는 것을 목표로 함

• vRAM이 Guest OS 관점에서 어떤 방식으로 인식되는지 설명할 수 있음
• Guest Virtual → Guest Physical → Host Physical 구조를 이해할 수 있음
• Memory Overcommit과 Ballooning이 가능한 이유를 설명할 수 있음
• 가상 디스크가 물리 디스크와 어떻게 다른지 설명할 수 있음
• Thin Provision과 Thick Provision의 차이를 구조적으로 이해할 수 있음
• Disk 용량과 성능 보장이 서로 다른 문제임을 설명할 수 있음
• 논리적, 물리적, 성능 보장의 차이를 구분할 수 있음

vRAM 개념과 보장 범위

가상화 환경에서는 vRAM은 VM에 할당된 메모리를 의미함

Guest OS는 이를 자신의 메모리처럼 인식하지만, 실제 물리 메모리는 Hypervisor가 관리함

Guest OS가 인식하는 메모리 범위와 Hypervisor가 실제로 매핑하는 물리 메모리 구조를 함께봐야하는 Resource 임

vRAM의 인식 및 매핑 구조

vRAM을 이해할 때 가장 먼저 봐야하는 것은 Guest OS가 메모리를 어떻게 인식하고, Hypervisor가 그 메모리를 실제 물리 자원과 어떻게 매핑하는가임

🔹Guest OS 관점의 메모리 모델

Guest OS는 자신에게 할당된 vRAM을 실제 메모리 처럼 인식하기 때문에 평소화 동일하게 동작하게 됨

• 프로세스에 메모리를 할당하며
• 페이지 테이블을 관리하고,
• 캐시를 사용하며,
• 필요 시 스왑 정책을 적용함

하지만 이 인슥은 어디까지나 Guest OS 관점의 논리적 모델으로 실제 물리 메모리와의 연결은 Hypervisor가 별도로 관리함

따라서 Guest OS가 8GB를 인식한다고 하여 항상 물리 메모리가 8GB가 고성으로 독점 보장된다고 볼 수 없음

🔹Guest Virtual→Guest Physical→Host Physical 변환 구조

VM 메모리의 주소 변환은 두 단계로 이루어짐

먼저 Guest OS 내부에서 어플리케이션이 사용하는 주소는

• Guest Virtual Address로 Guest OS는 이룰 자신의 페이즈 테이블을 통해 Guest Physical Address로 변환하게 됨 VM OS의 개입

• 이후 Hypervisor는 이를 실제 서버의 Host Physical Address로 변환함 Hypervisor의 개입

이러한 주소 변환을 기반으로 동적으로 매핑되는 구조 덕분에 Hypervisor는

• 물리 메모리 배치를 유연하게 조정
• 페이지 재배치
• 메모리 회수

과 같은 작업을 수행할 수 있음

메모리 자원 관리 메커니즘

가상화 환경에서는 여러개의 VM이 하나의 물리 서버 메모리를 공유함 따라서 Hypervisor는 메모리 활용률을 높이기 위한 관리 메커니즘을 함께 사용함

🔹Memory Overcommit

Memory Overcommit은 물리 서버의 실제 메모리 총량보다 더 많은 vRAM을 VM에 할당할 수 있는 구조를 의미함

예를 들어

• 물리 서버의 메모리: 32GB
• 여러대를 합친 VM: 48~64GB

와 같이 할당할 수 있음

해당 구조가 가능한 이유는 모든 VM이 항상 자신에메 할당된 최대 메모리를 동시에 사용하는 것이 아니기 때문으로 Hypervisor는 "모든 VM이 동시에 최댓값까지 쓰지는 않을 것" 을 전제로 두고 메모리를 효율적으로 사용함

이 방식은 자원 활용뮬 측면에서는 유리하나 불리한 측면도 가지고 있음

• 여러 VM이 동시에 메모리 사용량을 높이게되면
  • 물리 메모리가 부족해지는 상황이 발생할 수 있으며,
  • 성능 저하와 스왑이 발생할 수 있음

Overcommit은 효율성을 높이는 구조이지만, 그 자체가 메모리 보장을 의미하지는 않음

🔹Ballooning 메커니즘

Ballooning은 Hypervisor가 특정 VM 내부의 메모리를 회수하기 위해 사용하는 대표적인 방법

개념적으로 살펴보자면, Hypervisor는 VM 내부의 Balloon Driver를 통해 일부 메모리를 점유하게 만들어 Guest OS가 실제로 사용할 수 있는 메모리를 줄이게 됨.

Guest OS 입장에서는

• 사용 사능한 메모리가 줄어든 것 처럼 보이고,
• 일부 메모리를 포기하거나 정리해야하는 상황이 생김

Hypervisor 입장에서는

• 그만큼 물리 메모리를 다른 VM에 재할당할 수 있게 됨

이 메커니즘은 물리 메모리 압박 상황에서는 유용하지만 Guest OS의 성능에 영향을 줄 수 있음

메모리 여유가 많지 않은 VM에서 Ballooning이 발생하면 캐시 감소, 페이지 회수 증가, 내부 스왑 가능성 증가 와 같은 현상이 뒤따를 수 있음

즉, Ballooning은 메모리 부족 상황을 조절하는 기술로, Guest OS에 영향을 주지 않을 수는 없음

🔹 vRAM 설정값의 구조적 한계

vRAM의 설정 값은 Guest OS가 자신에게 주어진 메모리 범위를 인식하도록 정의한 값

메모리 범위를 인식하도록 정의했다는 말의 의미는 8GB vRAM은 Guest OS 입장에서 8GB Memory System처럼 동작하게 만드는 설정일 뿐

• 물리 메모리를 8GB를 독점하거나
• 다른 VM과 완전히 분리된 메모리를 사용하거나
• 항상 동일한 메모리 성능을 가질 수는 없음

따라서 VM 메모리를 해석할 때는 _"몇 GB인가"_를 넘어서 _"그 메모리가 어떤 구조 위에서 실제로 운영되는가"_를 살펴봐야함

가상 디스크 구조와 보장 범위

가상화 환경에서는 VM의 Disk는 물리 디스크를 직접 붙여 쓰는 개념과는 다름

Guest OS는 이를 일반적으로 로컬 디스크처럼 인식하지만 실제 구현은 가상 디스크 계층 위에서 이루어짐

VM의 Disk 또한 설정값 자체가 아닌 구조와 동작 방식을 함께 이해해야 해석할 수 있음

가상 디스크 구현 모델

가상 디스크는 일반적으로 파일 또는 논리 볼륨의 형태로 구현됨

대표적인 예시: VMDK, VHD, VHDX

Guest OS는 이를 하나의 독립적인 디스크로 인식함 파일 시스템을 만들고, 데이터를 기록하고, 일반적인 디스크 처럼 읽고 씀

하지만 실제로 이 디스크가 물리 장치에 직접 1:1 대응되는 것이 아닌, Hypervisor와 Host 측 스토리지의 계층을 거쳐 동작함

VM의 Disk는 가상 디스크를 통해 물리 스토리지에 접근하는 구조

🔸파일 기반 디스크 구조

가상 디스크는 Host OS의 파일 시스템 위에 존재하는 하나의 파일로,

*Guest OS 입장에서는 내부 디스크 처럼 *보이지만, *실제 Host의 입장에서는 하나의 방대한 파일 *로 보임

해당 구조는

• VM 복사,
• 스냅 샷 / 백업
• 이동 및 배포

에 용이하여 높은 유연성을 가지게 됨

반대로, 성능 측면에서는 추가 계층의 개입 또한 가지게 됨

Guest OS 의 I/O는 단순히 물리 디스크에 바로 도달하는 것이 아닌 여러 계층을 거치며 처리하게됨

🔸Thin Provision 구조

Thin Provision 은 설정한 디스크 용량 전체를 처음 부터 확보하지 않는 방식으로, 예를 들어 100GB의 디스크를 생성하더라도 실제로는 데이터가 기록된 만큼만 물리 공간을 사용함

이 구조는 실제로 필요한 공간을 나중에 할당하는 구조로 설정값돠 실제 점유 공간이 다를 수 있음

Thin Provision 100GB 는 물리적으로 확보된 공간이 아니며, 실제 기록이 증가할 때 마다

• 새 블록 할당
• 메타데이터 갱신
• 스토리지 풀 공산 소비

가 발생하며,

이러한 구조는 공간의 효율을 높이고, 초기 배치가 유연하며, 스토리지의 활용율을 높일 수 있다는 장점을 가지고 있음

이렇게 공간 효율 측면에서는 유리하긴 하지만, 그 자체가 물리 공간의 완전한 보장을 의미하지는 않음

🔸Thick Provision 구조

Thick Provision은 설정한 디스크 용량을 처음부터 물리적으로 확보하는 방식으로, 예를 들어 100GB의 Disk를 만들면 초기 생성 단계에서 부터 물리 공간을100GB를 확보하게 됨

용량 확보 측면에서는 매우 명확한 방식이지만, 이 방식은 공간을 미리 잡는 것이지, 디스크의 성능을 자동으로 보장하는 방식은 아님

하지만, 이러한 구조로 공간 부족 위험이 감소하고, 스토리지 사용향 예측이 용이하며, Thin 대비 구조가 단순하다는 장점이 있음

스토리지 자원과 성능 특성

Disk를 해석할 때 가장 많이 발생하는 오해는 용량 과 성능을 같은 관점으로 보는 것으로, 둘은 실제로 완전히 다름

100GB Disk라는 말은 저장 가능한 공간의 크기를 말하는 것이지 I/O 성능이나 지연 시간을 보장한다는 뜻이 아님

🔸용량 보장과 성능 보장의 구분

Disk 설정값은 우선 $얼마만큼\ 저장할\ 수\ 있는가$ 를 정의 함

하지만 실제 성능은

• 물리 스토리지 성능
• RAID 구조
• 캐시 상태
• 컨트롤러 성능
• 현재 I/O 부하
• 다른 VM의 스토리지 사용량
  에 의에 결정됨

같은 100GB Disk라도 환경에 따라 체감 성능은 크게 달라질 수 있음

따라서 Disk는 "용량은 설정값으로 보이지만 성능은 환경에 의해 달라지는다" 는 것을 유의해야함

🔸I/O 경합 구조

가상화 환경에서는 여러 VM이 동일한 물리 스토리지를 공유하는 경우가 흔함

VM은 논리적으로 분리되어 있더라도 스토리지의 성능은 공유하기 때문에 각 VM의 I/O 요청은 경국 같은 물리 자원에서 경쟁하게 되어있음

부하가 커지면 다음과 같은 흐름이 발생함.

I/O의 경합은 디스크 성능 저하의 직접적인 원인이 됨

이때 중요한 점은 문제가 VM 내부에만 제한되는 것이 아닌 공유 스토리지 구조 전체에서 발생할 수 있다는 것임

🔸공유 스토리지 환경의 영향

여러 VM이 동일한 스토리지 풀, RAID 그룹, LUN 등을 공유할 경우, 한 VM의 대향 I/O가 다른 VM 성능에 영향을 줄 수 있음

이러한 현상을 Noisy Neighbor라 칭함

즉 내 VM의 Disk 설정 값이 동일하더라도, 다른 VM의 사용 패턴에 따라 내 성능이 달라질 수 있음

때문에 Disk는 특히 논리적 설정값, 실제 물리 구성, 동시 사용 환경을 함께 봐야하는 리소스림

VM Resource 보장 범위 정리

여기 까지 종합하면 VM의 vRAM과 Disk는 숫자만으로 해석할 수 없음

분명 리소스 설정 값은 의미가 있지만, 그 의미가 어떤 종류의 보장에 해당하는 지 나눠서 봐야함

보장의 유형

가상화 환경에서 리소스 해석 시 다음 세 가지 보장을 구분할 필요가 있음

🔹논리적 보장

Guest OS가 인식하는 자원 범위가 유지되는 것

예를 들어 8GB vRAM, 100GB Disk는 Guest OS가 그 범위의 리소스를 가진 것으로 인식하게 만듦

즉, 논리적 보장은 VM 내부에서 보이는 자원 모델의 일관성을 의미함

🔹물리적 보장

실제 물리 자원이 특정 VM을 위해 고정적으로 확보되는 것

예를 들어 메모리 Revservation, 물리 스토리지 공간 사전 확보 같은 방식이 여기에 가까움

하지만 기본적인 VM 설정만으로는 이 수준의 보장이 자동 제공되지 않는 경우가 많음

🔹성능 보장

일정 수준 이상의 처리량, 지연 시간, 응답 속도가 유지되는 것

이는 가장 해석이 까다로운 영역으로 성능은 단일 설정값이 아닌

• Hypervisor 정책
• 공유 자원 상태
• 동시 부하
• 스토리지 구조

에 영향을 받기 때문임

즉 성능 보장은 용량 설정과는 별개의 문제로 봐야함

기본 설정에서 보장되지 않는 영역

기본적은 VM 설정은 다음을 의미하지 않음

• 물리 메모리의 완전한 독점
• 디스크 성능의 고정 보장
• 다른 VM의 영향이 없는 절대적 자원 사용

설정 값은 논리적 범위를 정의하는 값으로 이해해야 함

물리적은 고정와 성능을 보장하는 것은 그 위에 별도의 정책과 구조가 있어야 성립.

정리

vRAM은 Guest OS가 인식하는 메모리 범위를 정의하지만, 실제 동작은 주소 변환 구조와 Hypervisor의 메모리 관리 방식 위에서 이루어짐

또한 가상 디스크는 독립 디스크 처럼 보이지만, 실제로는 파일 기반 구조와 공유 스토리지 환경위에서 동작함

따라서 8GB RAM, 100GB Disk 는 단순한 설정 값(숫자)가 아닌

• 어떤 범위를 논리적으로 보이게 하는가
• 실제 물리 자원은 어떻게 연결되는가
• 성능은 어떤 조건에서 달라지는가

를 함께 봐야 해석할 수 있음

이 글에서 다룰 내용

이 글에서는 VM 리소스 중 vCPU가 실제로 무엇을 의미하는지 분석함.

가상화 환경에서 vCPU는 단순히 물리 CPU 코어를 복제한 것이 아니라 Hypervisor 스케줄러가 관리하는 실행 단위로 동작함.

따라서 vCPU 수가 곧 물리 코어 수를 의미하는 것은 아니며,
실제 실행은 스케줄링 구조와 물리 코어 상태에 의해 결정됨.

이 글에서는 vCPU의 실행 모델과 Run Queue, Ready 상태, Oversubscription 구조 등을 통해 vCPU가 실제로 어떤 범위까지 성능을 의미하는지 구조적으로 설명함.

즉, 이 글은 vCPU 설정값이 실제로 무엇을 의미하는지 해석하기 위한 단계임

학습 목표

이 글을 통해 다음을 이해하는 것을 목표로 함.

• vCPU가 물리 CPU 코어와 어떻게 다른지 설명할 수 있음
• vCPU가 실행 스케줄링 단위라는 의미를 이해할 수 있음
• Run Queue와 Ready 상태가 무엇을 의미하는지 설명할 수 있음
• Oversubscription 환경에서 CPU 경합이 발생하는 이유를 이해할 수 있음
• vCPU 수와 실제 성능 사이의 관계를 설명할 수 있음

vCPU 개념과 실행 모델

가상화 환경에서 vCPU는 VM이 사용하는 가상 CPU 단위를 의미 함 하지만 이 개념을 단순히 vCPU = 물리 CPU 코어 라고 이해하면 실제 구조와 차이가 발생함

vCPU는 물리 CPU 코어를 복제한 것이 아니라

$$ vCPU = Hypervisor가\ 관리하는\ 실행\ 단위 $$

즉 VM이 vCPU를 사용한다는 것은 물리 CPU를 직접 점유하는 것이 아니라 CPU 실행 시간을 스케줄링을 통해 할당받는 구조임.

vCPU의 구조적 의미

VM 내부에서 운영체제는 vCPU를 실제 CPU처럼 인식하게 됨

예를 들면 VM에 vCPU 4개를 할당하면 Guest OS는 CPU 0, CPU 1, CPU 2, CPU 3 과 같이 인식하게 됨

하지만 실제 물리 서버에서는

• 물리 코어 수
• 현재 실행 중인 VM 수
• 스케줄러 정책

에 따라 실행 순서가 결정됨

즉 vCPU는 물리 코어를 복제한 것이 아니라

라고 볼 수 있음.

🔸 실행 스케줄링 단위

vCPU는 Hypervisor 스케줄러가 관리하는 실행 요청 단위임

실행 흐름은 다음과 같이 진행됨

1. VM 내부에서 실행 요청이 발생

2. 해당 vCPU는 먼저 Run Queue에 등록

3. Hypervisor 스케줄러가 물리 CPU 코어가 비는 시점에 해당 vCPU를 실행

따라서

🔸 물리 코어와의 동적 매핑 구조

vCPU는 특정 물리 코어에 고정되어 있지 않기 때문에 다음과 같은 관계가 성립하기 때문에 다음과 같은 관계가 가능함

vCPU 1 ⇒ Core 2
vCPU 1 ⇒ Core 5
vCPU 1 ⇒ Core 1

CPU 자원을 효율적으로 사용하기 위해 Hypervisor가 동적으로 매핑하기 때문에 하나의 vCPU는 실행 시점마다 다른 코어에서 실행될 수 있음

vCPU와 물리 코어는 1:1 대응 관계가 아님❌

🔸 CPU Oversubscription 메커니즘

가상화 환경에서 물리 CPU 코어 수에 비해 vCPU를 보다 많이 할당되는 상황이 발생할 수 있음

[예 시] 물리 CPU 코거 8개 | vCPU 32개

이러한 할당 방식을 CPU Oversubscription이라 함

CPU Oversubscription: 물리 코어보다 많은 vCPU를 할당하는 구조

모든 VM이 항상 CPU를 100% 사용하는 것은 아니기 때문에 가능한 구조 하지만 동시에 많은 VM이 CPU를 요구하면 CPU 경합(CPU Contention)이 발생할 수 있음

vCPU와 성능 관계

vCPU 수가 많다고 해서 항상 성능이 증가하는 것은 아니라, 실제 성능에는

• 물리 CPU 코어 수
• 스케줄링 상태
• CPU 경합 여부
• NUMA 구조

와 같은 요소에 영향을 받음

🔸 동시 스케줄링 제약

멀티 vCPU VM은 동시에 여러 코어가 필요할 수 있음.

• ex : 4 vCPU VM이 실행될 경우, 최소 4개의 물리 코어가 필요

하지만 물리 코어가 부족하면 일부 vCPU는 대기 상태에 들어가게되며 이러한 경우 _VM 내부 작업이 전체적으로 지연_될 수 있음

🔸 Ready 상태와 대기 시간

CPU는 Running → Ready → Running 과 같은 상태 전이가 발생함

Ready 상태는 실행 준비는 되었지만 CPU 코어를 배정받지 못한 상태 를 의미함.

Ready 시간이 길어질수록 CPU 자원 경합이 심한 환경임을 의미하기 때문에 가상화 환경에서는 Ready Time이 중요한 CPU 성능 지표로 사용됨

🔸 NUMA 영향

멀티 CPU 소켓 시스템에서는 NUMA 구조가 존재함.

NUMA: Non-Uniform Memory Access

멀티 프로세서 시스템에서 CPU가 메모리에 접근하는 속도가 데이터 위치에 따라 달라지는 컴퓨터 메모리 설계 방식

• 구 조 : CPU와 로컬 메모리가 한 세트로 묶인 "NUMA 노드"들로 구성

• 속도 차이 : 자신 노드의 로컬 메모리 접근은 빠르지만, 다른 노드의 원격 메모리 접근은 연결된 버스를 통해 이뤄져 속도가 느림
• 목 적 : 과거 모든 CPU가 하나의 공유 메모리에 집중되면 병목 현상을 해소하고, CPU 개수가 많아져도 성능이 확장될 수 있게함

NUMA 환경에서는

$특정\ CPU\ 코어가,\ 특정\ 메모리\ 영역에\ 더\ 가깝게\ 연결됨$

따라서 CPU 스케줄링이 잘못 이루어질 경우 메모리 접근 지연이 증가할 수 있음

즉 CPU 실행 성능은 단순히 코어 수가 아니라

메모리 접근 구조와도 연결됨.

정리

$$ vCPU는\ 물리\ CPU\ 코어를\ 그대로\ 복제한\ 개념이\ 아닌\ Hypervisor가\ 관리하는\ 가상\ 실행\ 단위 $$

VM이 사용하는 CPU는 물리 코어를 직접 점유하는 것이 아니라
스케줄링을 통해 실행 시간을 할당받는 구조로 동작

따라서

• vCPU 수 = 물리 코어 수 ❌
• vCPU 증가 = 성능 증가 ❌

가상화 환경에서 CPU 성능은

• Run Queue
• Ready 상태
• Oversubscription
• NUMA 구조
  와 같은 요소의 영향을 받으며, 이러한 실행 모델을 이해하는 것이
  이후 VM 리소스 설정값을 해석하는 데 중요한 기준이 됨

이 글에서 다룰 내용

이 글에서는 VM 리소스가 어떤 구조 위에서 정의되는지 정리함.

VM은 물리 서버를 그대로 복제한 환경이 아니라 Hypervisor를 통해 CPU · Memory · Storage가 서로 다른 방식으로 매핑되는 구조임.

CPU는 스케줄링 기반으로 실행되고,
Memory는 이중 주소 변환을 거치며,
Storage는 다층 $I/O$ 경로를 통해 처리됨.

또한 Run Queue, Ready 상태, $I/O$ Queue, NUMA 구조 등 실제 자원 경합이 발생하는 지점을 구조적으로 설명함.

이 글은 리소스 설정 값을 해석하기 전,
VM 리소스 모델 자체를 이해하기 위한 단계임

학습 목표

이 글을 통해 다음을 이해하는 것을 목표로 함.

• VM과 물리 서버의 구조적 차이를 설명할 수 있음
• Hypervisor의 CPU · Memory · Storage 매핑 방식을 구분할 수 있음
• Ready 상태와 $I/O$ 경합이 왜 발생하는지 설명할 수 있음
• 격리와 물리적 독점의 차이를 구분할 수 있음

VM 리소스의 구조적 전제

VM 리소스를 정확히 해석하기 위해 먼저 가상화 환경의 기본 구조를 이해해야 함.

공유 자원 기반 가상화 모델

VM은 물리 자원을 직접 소유하는 것이 아니라 Hypervisor가 물리 자원을 관리하고,
각 VM은 그 위에서 가상 하드웨어를 통해 실행됨.

따라서 $``리소스를\ \ 할당했다"$ 라는 표현은 물리 자원을 분리하여 떼어주었다는 의미가 아니라 물리 자원을 사용할 수 있는 논리적 범위를 정의했다 는 의미에 가까움.

이 구조는 자원 활용 효율을 높이지만 동시에 자원 경합 가능성을 내포함.

물리 서버와 VM의 실행 구조 차이

물리 서버에서는 자원 접근 경로가 단일 계층으로 운영체제가 CPU, Memory, Storage를 직접 제어함.

VM 환경에서는 다음과 같은 계층 구조가 존재함:

Guest OS는 CPU와 RAM을 직접 사용하는 것처럼 보이지만 실제 자원 접근은 항상 Hypervisor를 통해 중개됨.

이 차이로 인해 VM 리소스는

• 직접 점유 구조가 아니라
• Hypervisor가 중재하는 접근 권한 구조

로 동작함.

Hypervisor의 자원 매핑 메커니즘

Hypervisor는 CPU, Memory, Storage를 각각 다른 방식으로 중재함.

1️⃣ CPU 매핑 — 스케줄링 기반 실행 제어

vCPU는 실행 단위이며 물리 코어는 실제 실행 자원임.

실행 흐름

Hypervisor 스케줄러는 다음 요소를 고려함.

• 현재 실행 중인 vCPU 수
• 물리 코어 수
• 우선순위 (Share / Reservation / Limit)
• NUMA 구조

핵심 구조

• vCPU는 물리 코어에 고정되지 않음
• 실행은 시간 단위(Time Slice)로 분할됨
• 동시에 실행 가능한 최대 수는 물리 코어 수

                     즉,

$$ vCPU = 물리\ 코어\ 실행\ 시간을\ 분할하는\ 논리\ 단위 $$

CPU Run Queue와 Ready 상태

각 물리 코어에는 Run Queue가 존재함.

상태 전이: Running → Ready → Running

Ready 상태는 실행 가능하지만 코어를 배정받지 못한 상태를 의미함. Ready 시간이 길어질수록 CPU 경합이 심함.

특히 Oversubscription 환경에서는 Ready 비율이 중요한 성능 지표가 됨.

NUMA 영향

멀티 소켓 서버에서는 NUMA (Non-Uniform Memory Access) 구조가 존재함.

이 구조에서는

• 특정 CPU 코어가
• 특정 메모리 뱅크와 더 가까움

따라서 CPU 스케줄링이 잘못 이루어질 경우 메모리 접근 지연이 증가할 수 있음.

즉 CPU 매핑은 단순히 코어 개수 문제만이 아니라 메모리 위치와도 연결된 문제임.

2️⃣ Memory 매핑 — 이중 주소 변환

메모리 접근은 다음 구조를 거침

Guest OS 내부에서도 이미 가상 메모리 체계를 사용함.

Hypervisor는 그 위에 한 단계 더 개입하여 Host Physical Address를 매핑함.

이 구조 덕분에 다음이 가능해짐.

• 메모리 재배치
• 메모리 회수
• Memory Overcommit

즉 VM의 메모리는 단순히 물리 RAM을 나눠 쓰는 것이 아니라 주소 변환을 통해 동적으로 매핑되는 구조임.

3️⃣ Storage 매핑 — 가상 디스크 I/O 경로

가상 디스크는 일반적으로

• VMDK
• VHDX

같은 파일 또는 논리 볼륨 형태로 존재함.

Guest OS는 이를 물리 디스크처럼 인식하지만 실제 $I/O$는 여러 계층을 거쳐 처리됨.

이 구조에서 중요한 특징은 다음과 같음.

1. $I/O$는 여러 계층을 통과함

2. 각 계층마다 Queue가 존재할 수 있음

3. Queue Depth가 증가하면 Latency가 증가함

즉 VM 디스크 성능은 가상 디스크 크기 보다 전체 $I/O$ 경로에서 발생하는 병목 지점에 의해 결정됨.

⭐격리·독점·보장의 개념 구분

가상화 환경에서는 리소스를 해석할 때 반드시 구분해야하는 세 가지 개념이 있음

1️⃣ 격리 (Isolation) 2️⃣ 독점 (Exclusive Use) 3️⃣ 보장 (Guarantee)

이 세 개념은 서로 다른 의미를 가지며, 실제 VM 리소스 해석에서 매우 중요한 기준이 됨. 특히 많은 경우 격리를 독점이나 성능 보장으로 오해하는 경우가 많음.

격리 (Isolation)

격리는 VM 간 실행 환경이 서로 논리적으로 분리되어 있는 상태를 의미함 즉, 하나의 VM이 다른 VM의 _내부 자원에 직접 접근할 수 없도록 하는 구조_임

대표적인 예:

• 메모리 주고 공간 분리
• 가상 디스크 분리
• 가상 네트워크 인터페이스 분리

• 예를 들어 한 VM이 사용하는 메모리 영역은 다른 VM에서 직접 접근할 수 없음
• 또한, VM의 운영체제가 장애가 발생하더라도 다른 VM의 운영체제에는 직접적인 영향을 주지 않음

이처럼 격리는 안정성과 보안 측면에서 매우 중요한역할을 함

하지만 격리는 어디까지나 논리적 분리일 뿐이며, 물리 자원의 사용 자체를 완전히 분리하는 것은 아님

즉 여러 VM이 동일한 물리 CPU나 스토리지를 공윻하는 상황에서도 각 VM은 서로 독립된 환경처럼 동작할 수 있음

독점 (Exclusive Use)

독점은 특정 VM이 물리 자원을 단독으로 사용하는 상태를 의미함

예를 들어 다음과 같은 경우가 이에 해당함

• 특정 CPU 코어를 한 VM에만 할당
• 특정 GPU를 하나의 VM이 독점 사용
• 특정 스토리지 디바이스를 단일 VM 전용으로 사용

이 경우 해당 자원은 다음 VM과 공유되지 않기 때문에 자원 사용이 경쟁 상태에 놓이지 않음

하지만 일반적인 가상화 환경에서는 대부분의 자원이 여러 VM 사이에서 공유됨

예를 들어 하나의 물리 서버에 여러 VM이 존재할 경우, CPU, 메모리, 스토리지는 대부분 공유 자원으로 사용됨

일반적인 VM 환경에서는 물리 자원의 완전한 독점 상태가 보장되지 않는 경우가 많음

보장 (Guarantee)

보장은 특정 자원 또는 성능 수준이 항상 일정하게 확보되는 상태를 의미함

예를 들어 다음과 같은 상황이 보장에 해당함

• 특정 VM에 최소 CPU 사용률 보장
• 일정 수준 이상의 메모리 확보
• 특정 스토리지 IOPS 보장

이러한 보장은 일반적으로 다음과 같은 메커니즘을 통해 구현됨.

• Resource Reservation
• Resource Limit
• QoS 정책

예를 들어 CPU Reservation이 설정된 VM은 다른 VM의 부하와 관계없이 일정 수준의 CPU 자원을 확보할 수 있음

하지만 대부분의 기존 VM 설정에서는 이러한 보장이 자동으로 제공되지 않음 즉, VM 리소스 설정 값이 존재한다고 해서 그 자원이 항상 동일한 성능을 제공하는 것음 아님

세 개념의 차이

가상화 환경에서 기본적으로 제공되는 것은 격리이며, 독점이나 성능 보장은 별도의 설정이 필요함

그러므로 VM의 리소스를 해석할 때는

• $격리 ≠ 독점$
• $격리 ≠ 성능\ 보장$

으로 이해해야 함

이 차이를 이해하는 것이 이후의 vCPU, vRAM, Disk 설정값의 의미를 해석하는 데 중요한 기준이 됨.

정리

VM 리소스를 이해하기 위해서는 먼저 가상화 환경의 구조적 전제를 이해해야 함.

VM은 물리 서버를 그대로 복제한 환경이 아니라 Hypervisor가 물리 자원을 관리하고 그 위에서 가상 하드웨어를 통해 실행되는 구조임.

이 구조에서는 각 리소스가 서로 다른 방식으로 매핑됨.

• CPU → 스케줄링 기반 실행 모델
• Memory → 이중 주소 변환 구조
• Storage → 다층 $I/O$ 경로

따라서 VM 리소스는 물리 자원을 직접 점유하는 것이 아니라 공유 자원 위에서 실행되는 논리적 실행 모델로 이해해야 함.

또한 가상화 환경에서는 다음 세 개념을 구분해야 함.

• 격리 (Isolation) : VM 간 실행 환경의 논리적 분리
• 독점 (Exclusive Use) : 물리 자원을 특정 VM이 단독으로 사용하는 상태
• 보장 (Guarantee) : 일정 수준 이상의 자원 또는 성능 확보

기본 VM 환경에서 Hypervisor가 제공하는 것은 격리이며, 물리 자원의 독점이나 성능 보장은 별도의 설정이 필요한 영역임.

이 글에서 다룰 내용

이 글에서는 PART 2에서 다룬 하드웨어 추상화를 실제로 가능하게 만든 핵심 구성 요소인 Hypervisor가 무럿인지, 그리고 왜 Hypervisor가 Type 1과 Type2로 구분되는지를 다룸

각 타입이 어떤 환경을 전제로 등장했느지에 초첨을 맞춰 설명

학습 목표

아 글을 통해 다음을 이해하는 것을 목표로 함

• Hypervisor의 역할을 구조적으로 설명할 수 있음

• Type 1과 Type 2 Hypervisor의 차이를 "성능"이 아닌 "전제 환경" 관점에서 이해함
• 왜 서버 환경에서는 Type 1이 표준이 되었는지 설명할 수 있음
• 이후 vCPU, vRAM 설명의 기반을 마련함

Hypervisor란 무엇인가

Hypervisor가 필요해진 이유

PART 2에서 살펴본 VM 환경의 핵심은 운영체제가 더 이상 물리 하드웨어를 직접 인식하지 않는다는 점이었음

하나의 물리 서버 위에서 여러 운영체제가 동시에 실행되기 시작하면서, 기존 Bare Metal 환경에서는 전혀 고려하지 않아도 되었던 문제가 발생함

• 여러 운영체제가 동시에 CPU를 사용하려 하고,
• 각 운영체제는 메모리를 전부 소유한 것처럼 동작하며,
• 디스크와 네트워크 접근이 서로 충돌할 수 있음

즉, 여러 운영체제가 하나의 하드웨어를 직접 제어하려는 구조적 충돌이 발생함

이 충돌을 해결하지 않으면 VM은 개념적으로만 존재할 뿐, 안정적인 시스템으로 동작할 수 없음

이 문제를 해결하기 위해 등장한 계층이 바로 Hypervisor임

Hypervisor는 여러 운영체제가 하나의 물리 서버를 공유하더라도 각각이 독립된 서버처럼 동작할 수 있도록 하드웨어 사용의 전제를 바꾸는 역할을 수행함

Hypervisor의 역할

Hypervisor의 역할을 한 문장으로 정리하면 다음과 같음

** 여러 운영체제가 하나의 물리 서버를 공유하더라도, 각 운영체제가 자신만의 서버를 사용하는 것 처럼 동작하도록 만드는 계층**

VM 환경에서 운영 체제는 자신이 단독 서버위에서 실행된다고 가정하고 동작함 Hypervisor는 이 가정을 깨지 않으면서도, 실제 하드웨어 자원은 질서 있게 공유되도록 만듦

그 결과,

• 운영체제는 하드웨어의 존재를 직접 할 필요가 없고,
• 하드에워 자원 사용의 충돌은 Hypervisor 단에서 해결됨

*이 역할은 다음과 같은 자원 영역에서 동시에 수행됨: *

🔹CPU

VM 환경에서 운영체제는 CPU를 독점적으로 사용할 수 있다고 전제하고 동작함

Hypervisor는 이 전제를 깨지 않은 채, 실제 CPU는 여러 VM이 시간 단위로 나누어 사용하도록 관리함

그 결과

• 여러 VM이 동시에 실행될 수 있고,
• 각 VM은 CPU를 끊김 없이 사용하는 것 처럼 동작함

🔹메모리

VM 환경에서 운영체제는 자신에게 할당된 메모리 공간을 완전히 소유하고 있다고 전제함

Hypervisor는 이 전제를 유지한 채, VM마다 접근 가능한 메모리 범위를 분리하여 서로의 메모리를 침범하지 못하도록 강제함

그 결과

• 한 VM에서 발생한 메모리 오류가 다른 VM으로 전파되지 않음

🔹디스크와 네트워크

VM 환경에서 각 VM은 자신만의 디스크와 네트워크 인터페이스가 존재한다고 전제함

Hypervisor는 이 전제를 유지한 채, 각 VM의 I/O 요청을 물리 자원으로 중재하고 결과를 다시 해당 VM에 전달함

그 결과,

• 여러 VM이 하나의 물리 디크스와 NIC를 공유하더라도 각 VM은 독립된 자원을 사용하는 것 처럼 동작함

$$ 즉,\ Hypervisor는 $$ $$ 운영체제가\ 하드웨어를\ 직접\ 통제하지\ 않더라도 $$ $$ 기존과\ 동일한\ 방식으로\ 동작할\ 수\ 있도록 $$ $$ ``하드웨어\ 사용의\ 환상"을\ 유지해주는\ 계층 $$

Hypervisor의 위치가 중요한 이유

Hypervisor는 항상 물리 하드웨어와 VM 사이에 존재함

하지만 어디에 위치하느냐에 따라 전체 가상화 구조의 성격이 완전히 달라짐

이 차이를 기준으로 Hypervisor는 Type 1과 Type 2로 구분됨

Type 1 Hypervisor

구조

Type 1 Hypervisor는 물리 하드웨어 위에직접 설치되는 구조임

이 구조에서는 운영체제가 하드웨어를 직접 제어하지 않음.

하드웨어 자원에 대한 판단과 통제는 Hypervisor가 담당함

구조가 의미하는 것

Type 1 구조의 핵심은 Host OS가 없다는 사실 차제가 아님. 중요한 점은 운영체제의 역할이 바뀌었다는 것

운영체제는 더이상

• CPU 스케줄링의 주체가 아니며,
• 메모리 과리의 기준이 아니고,
• 디스크와 네트워크 제어의 최종 판단자가 아님

  운영체제는 Hypervisor 위에서 실행되는 하나의 실행 단위가 됨

이 구조 덕분에, 여러 운영체제가 동시에 실행되더라도, 하드웨어 자원 사용은 하나의 기준 $[Hypervisor]$으로 조율 됨

왜 서버 환경에 적합한가

서버 환경에서는 다수의 VM을 동시에 운영해야 하고, 장시간 안정적으로 동작해야 하며, 특정 VM의 문제로 전체 시스템이 흔들리면 안 됨

Type 1 구조에서는 하드웨어 자원에 대한 판단이 Hypervisor 기준으로 *일관되게 *이루어지기 때문에,

• 자원 사용 패턴이 예측 가능하고,
• 장애 영향 범위를 VM 단위로 제한할 수 있으며,
• 대규모 VM운영이 가능함

이 때문에 데이터센터와 클라우드 환경에서는 ** $Type\ 1\ Hypervisor$ 구조가 표준으로 사용됨**

Type 2 Hypervisor

구조

Type 2 Hypervisor는 기존 운영체제 위에서 실행되는 소프트웨어 형태의 구조임

이 구조에서는 하드웨어에 대한 최종 제어 권한이 Host OS에 있음

Hypervisor는 Host OS가 제공하는 자원 위에서 동작함

전제 환경

Type 2 구조는 서버 운영을 전제로 설계된 구조가 아님

• 개인 PC나 노트북 환경에서 기존 OS를 유지한 채 VM을 실행하기 위한 목적으로 VM을 운영하기 위한 구조라기보다, 사용하기 위한 구조에 가까움

구조적 한계

Type 2 구조에서는 모든 자원 요청이 Guest OS → Hypervisor → Host OS → 하드웨어 경로를 거치게됨

이로 인해

• 자원 통제 기준이 분산되고,
• 계층 증가로 인한 오버헤드가 발생하며,
• Host OS 장애가 전체 VM에 영향을 미침

이 한계는 구현이 아닌 구조적 위치에서 발생하는 한계임

Type 1과 Type2를 나눠서 이해해야하는 이유

Type 1과 Type 2의 차이는 단순히 "성능이 좋다/나쁘다"의 관점이 아님

차이는 가상화를 어디까지 운영 책임 범위로 보느냐에 있음

• Type 1 → 가상화를 서버 인프라의 일부로 다룸
  
• Type 2 → 가상화를 사용자 환경에서 사용하는 도구로 다움

이 전제 차이가 구조, 안정성, 확장성의 차이로 이어짐

따라서,

$$ 대규모\ 서비스\ 운영\ 환경에서는\ [Type\ 1]이\ 선택되고, $$ $$ 개인\ 개발\ 및\ 테스트\ 환경에서는\ [Type\ 2]가\ 선택됨 $$

정리

• Hypervisor는 여러 운영체제가 하나의 물리 서버를 공유할 수 있도록 실행 환경과 자원 사용을 조율하는 계층

• Hypervisor의 위치에 따라 가상과 구조는 Type 1r과 Type 2로 나뉨

• Type 1: 가상화를 서버 인프라의 일부로 다루기 위한 구조
• Type 2: 가상화를 개인 환경에서 활용하기 위한 구조

이제 다음 글에서는 이러한 Type 1 Hypervisor 구조 위에서 제공되는 vCPU, vRAM, Disk가 실제로 무엇을 보장하는지 살펴봄

이 글에서 다룰 내용 이번 글에서는 PART 1의 연장선으로, VM:Virtual Machine이 무엇인지 그리고 VM이 왜 단순한 "서버 여러 개"가 아니라 하드웨어를 추상화한 결과물이라고 불리는지 다룸

VM이 실제로 무엇을 제공하고, 무엇을 숨기며, OS는 어떤 관점에서 서버를 인식하게 되는지를 중심으로 설명함

학습 목표 이 글을 통해 다음을 이해하는 것을 목표로함

• VM을 단순한 개념 정의가 아니라 구조적으로 설명할 수 있음
• Bare Metal과 VM의 차이를 "추상화" 관점에서 설명할 수 있음
• VM이 제공하는 vCPU, vRAM, 가상 디스크가 무엇인지 감을 잡음
• 이후 Hypervisor, vCPU/vRAM 설명으로 자연스럽게 넘어갈 수 있는 기반을 마련함

VM은 무엇인가

VM을 다시 정의해보면

VM:Virtual Machine은 하나의 물리 서버 위에서, 여러 개의 독립된 서버가 존재하는 것처럼 동작하도록 만든 논리적 서버임

중요한 점은 VM은 단순히 서버를 쪼갠 것이 아니라, 하드웨어를 추상화하여 제공한다는 점임

VM은 실제 하드웨어를 그대로 보여주지 않고, "서버처럼 보이는 환경"을 만들어 OS에게 제공함

Bare Metal과 VM의 출발점 차이

🔹 Bare Metal환경에서는 운영체제(OS)가 물리 하드웨어를 직접 인식함

• 실제 CPU 코어
• 실제 메모리 주소
• 실제 디스크 장치
  그리고 OS는 이 모든 것을 있는 그대로 다룸.

반면,

🔹 VM 환경에서는 OS가 물리 하드웨어를 직접 보지 못하며, OS가 인식하는 것은

• vCPU
• vRAM
• 가상 디스크
• 가상 네트워크 카드

  를 인식하기때문에 OS는 이게 진짜 하드웨어인지 알 수 없으며, 그저 서버 하나가 있다고 믿고 동작할 뿐임

하드웨어 추상화의 의미

하드웨어 추상화란 흔히 물리 자원을 그대로 나눠 쓰는 것으로 오해되지만, 본질은 그보다 한 단계위의 개념임

추상화의 핵심은 다음과 같음

• 실제 구현을 숨기고,
• 일관된 인터페이스만 제공하며,
• 사용하는 쪽(OS)은 내부 구조를 알 필요가 없도록 만드는 것

즉, 하드웨어의 추상화란 물리 자원의 실제 형태와 동작 방식은 감춘 채, OS에게는 항상 같은 방식으로 사용할 수 있는 가짜 하드웨어를 제공하는 개념

VM 환경에서 보면

• *vCPU는 실제 CPU 코어가 아니며, *
• *vRAM은 실제 메모리 칩이 아니고, *
• *가상 디스크는 단일 물리 디스크가 아님 *

하지만 OS는 이를 진짜 CPU, 메모리, 디스크처럼 사용함

VM이 서버처럼 보이는 이유

각 VM은 아래의 요소들을 가지고 있음

• 독립된 운영체제
• 독립된 프로세스 공간
• 독립된 파일 시스템
• 독립된 네트워크 인터페이스

VM 내부에서 보면, 다른 VM의 존재를 알 수 없으며, 물리 서버를 공유하고 있다는 사실도 인식하지 못함

VM은 사용자와 OS 관정에서 완전히 독립된 서버처럼 보이도록 설계된 환경임

VM이 단순 분할이 아닌 이유

*VM을 그저 "CPU와 메모리를 $\frac{1}{N}$ 로 나눈 것" 으로 이해하는것은 타당하지 않음 *

실제로 Hypervisor는 다음과 같은 역할을 수행함

• CPU를 시간 단위로 스케줄링
• 메모리를 동적으로 할당 및 회수
• 디스크 I/O 요청을 중재
• 네트워크 트래픽을 가상 인터페이스로 분리
  

Bare Metal와 VM의 가장 큰 구조적 차이는 하드웨어 자원을 누가, 어떻게 조율하느냐에 있음.

VM 환경에서는 hypervisor가 CPU와 메모리 같은 물리 자원을 직접 중재하고 스케줄링함

그 결과,

• VM 마다 CPU 사용량이 순간적으로 크게 달라지더라도, 물리 서버 전체가 불안정해 지지 않고,
• 하나의 시스템처럼 균형을 유지하며 동작할 수 있음

VM이 Bare Metal의 문제를 어떻게 해결했는가

🔹자원 활용률의 개선

• Bare Metal 환경에서는 서버 한대를 최대 부하를 기준으로 설계할 수 밖에 없었고, 그 결과 대부분의 시간 동안 자원이 유휴 상태로 남는 문제가 있었음.

VM환경에서는 하나의 물리 서버 자원을 여러 VM이 함께 사용하기 때문에

• 특정 VM이 자원을 거의 사용하지 않는 동안 다른 VM이 해당 자원을 사용할 수 있으며,
• 전체 서버 관점에서 자원이 보다 균형있게 사용됨.

이로 인해 서버당 평균 자원 활용률이 크게 개선됨

🔹서버 생성과 확장의 속도

• Bare Metal 환경에서는 서버를 추가하는 것은 곧 물리 장비의 추가를 의미했음.

VM 환경에서는 버서를 물리 장비가 하닌 논리적 개체로 다룸

• 미리 준비된 이미지 기반으로 VM을 생성하고
• 하드웨어 설치 없이 수 분 내에 새로운 서버를 준비할 수 있음

이로써 서버 확장의 시간 단위가 '수 주'에서 '수 분'으로 바뀌게 됨

🔹장애 격리

• Bare Metal 환경에서는 하드웨어 장애가 곧 서버 전체로 이어졌음

VM 환경에서는 장애의 기본 단위가 물리서버가 아닌 VM이기 때문에 하나의 VM에 문제가 발생하더라도 동일 물리 서버위의 다른 VM에는 영향을 최소화할 수 있음

VM환경에서는 장애의 영향 범위를 논리적으로 분리할 수 있게 됨

🔹운영 표준화

VM은 서버를 이미지 기반으로 관리할 수 있음

• 동일한 이미지로 여러 VM을 생성하고,
• 테스트 환경과 운영 환경을 동일하게 맞출 수 있으며,
• 서버 간 환경 편차를 크게 줄일 수 있음

이로 인해 "환경 차이로 발생하는 문제"가 운영 이유의 주요 원인에서 점차 일려나게됨

그렇다면 VM은 완벽한 해답이었는가

결론부터 말하자면 완벽한 해답은 아님

VM은 Bare Metal 환경의 많은 문제를 해결했지만, 새로운 형태의 과제를 함께 가져옴

• Hypervisor 계층으로 인한 성능 오버로드
• VM 단위로 서버를 관리해야 하는 운영 복잡성
• 애플리케이션 단위 확장에는 여전히 무거운 구조로

운영의 기본 단위가 여전히 "서버(VM)"에 머물러 있음

이 점은 서비스와 애플리케이션이 더 작고 빠르게 변화하기 시작하면서 점점 더 부담으로 작용하게 됨

이 한계가 이후 Container와 Kubernetes로 이어지는 또 하나의 전환점을 만듦

정리

VM은

• 서버를 물리 장비가 아닌 추상화된 자원 단위로 다루게 만든 기술로

• 자원 활용률
• 서버 생성 속도
• 장애 격리
• 운영 표준화
  와 같은 문제를 크게 개선함

그러나

• 운영의 기본 단위는 여전히 VM에 머무르며,
• 애플리케이션 중심 운영에는 한계를드러냄

이 글에서 다룰 내용 이번 글에서는 가상 머신(VM)을 이해하기 위한 출발점으로 Bare Metal 서버가 무엇이며, 어떤 한계를 가졌는지를 먼저 살펴봄.

VM은 어느 날 갑자기 등장한 개념이 아니라, 기존 Bare Metal 환경에서 반복적으로 마주친 운영·확장·비용 문제를 해결하기 위한 등장한 결과물임

학습 목표 이글의 목표는 다음과 같음

• Bare Metal 서버의 정확한 의미를 설명할 수 있음

• Bare Metal 환경의 구조적 장점과 한계를 구분할 수 있음
• 왜 서버 운영 방식이 Bare Metal → VM 으로 전환될 수밖에 없었는지 맥락을 이해함

이를 통해 다음 글에서 다룰 "VM은 무엇인가"를 단순 정의가 아닌 필연적 선택으로 이해하는 기반을 마련함

이 글에서 다루는 Bare Metal

Bare Metal이라는 용어는 사용되는 맥락에 따라 서로 다른 의미로 쓰이기도 함.

다만 이 글에서는 가상화 계층 없이 물리 서버 하드웨어에 운영체제(OS)를 직접 설치하여 사용하는 서버를 Bare Metal 환경으로 한정하여 다룸

Bare Metal이란 무엇인가

Bare Metal의 의미 짚고 가기

Bare Metal 서버란 물리 서버 하드웨어에 운영체제(OS)를 직접 설치해서 사용하는 서버를 의미함

• CPU, 메모리, 디스크, 네트워크 같은 하드웨어 자원을 OS가 직접 제어하고 그 위에서 애플리케이션이 바로 동작하는 구조

구조를 단순화 하면 다음과 같음

[물리 서버]
    ∟ [운영 체제]
        ∟ [애플리케이션]

이 구조가 바로 Bare Metal 환경임

Bare Metal 시절의 서버 운영 방식

과거에는 서버 = 물리 장비 라는 인식이 매우 자연스러웠으며,

• 웹 서버 하나가 필요하면 서버 한대,
• DB 서버가 하나 필요하면 또 서버 한 대를 준비하는 방식이었음

하나의 서버에는 하나의 OS 하나의 주요 서비스. 서버 간 격리는 논리적이 아니라 물리적으로만 이루어졌음

이 방식은 단순하고 직관적이었으며, 당시 기준에서는 합리적인 선택이었음

Bare Metal의 분명한 장점

Bare Metal 구조의 가장 큰 장점은 성능과 단순성

성능 측면

• 가상화 계층이 없이 때문에 오버헤드가 거의 없음
• CPU, 메모리, 디스크를 100% 단독으로 사용 가능
• 성능 예측이 매우 쉬움
  

그래서 다음과 같은 워크로드에 적합했음

• 데이터베이스 서버
• 고성능 연산 작업
• 특수 하드웨어와 직접 연동되는 시스템

운영 측면

• 구조가 단순함
• 계층이 적어 장애 원인 추적이 비교적 쉬움
• OS와 애플리케이션 동작이 직관적임

"서버가 느리다 → 이 서버가 문제다" 라는 판단이 가능했음

Bare Metal의 한계

"문제는 서비스 규모와 요구사항이 커지면서부터 였음"

자원 활용율 문제

Bare Metla 환경에서는 서버를 최대 부하 기준으로 설계할 수밖에 없음

• 트래픽이 몰리는 시간을 기준으로 서버를 구매하면
  • 그 외 대부분의 시간에는 CPU 사용률 한 자릿수가 되며,
  • 메모리도 넉넉하게 남아있음

즉, 비싼 서버 자원이 대부분 시간 동안 놀고 있는 상태가 발생함

확장과 변경의 느린속도

새로운 서비스 하나를 추가하려면 다음 과정을 거쳐야 했음

1. 서버 구매
2. 납기 대기
3. 랙 설치
4. OS 설치
5. 서비스 구성

이 과정은 짧아도 수 주 단위 였음

서비스가 빠르게 늘어나는 환경에서는 이 속도를 감당하기 어려워지기 시작함.

장애에 취약한 구조

Bare Metal 서버에서 하드웨어 장애가 발생하면,

• 해당 서버에 올라간 모든 서비스가 중단됨
• 대체 서버가 없으면 복구까지 시간이 오래 걸림

논리적인 격리 단위가 없기 때문에 장애 영향 범위가 매우 큼.

운영 표준화의 어려움

서버가 늘어날수록 다음 문제가 반복됨

• 서버마다 OS 버전이 다름
• 라이브러리, 설정 값이 조금씩 다름
• "이 서버에서는 되는데?" 상황 발생

환경을 동일하게 유지하는 것 자체가 큰 부담이 됨.

서버는 정말 물리 장비여야만 하는가?

실제로 서비스가 필요로 하는 것은 물리 서버 자체가 아니라

• *CPU 자원,메모리, 디스크, 네트워크 *와 같은 컴퓨팅 자원으로

이 자원을 더 잘 나누고, 더 빠르게 만들고, 더 쉽게 복구할 수 없는가? 에 대한 답으로 등장한 개념이 바로

$$ 가상\ 머신\ \ (Virtual\ Machine) $$

정리

bare Metal은 성능, 단순성에 강점을 가진 구조였으나,

• 낮은 자원 활용률
• 느린 확장 속도
• 장애 영향 범위
• 운영 표준화의 한계

로 인해 서버를 '물리 장비'가 아닌 '자원 단위'로 바라보는 사고 전환이 만들어 졌고, 그 결과가 바로 VM: Virtual Machine 이었음

Proxmox에 클러스터링을 진행하기 전에 기본적인 클러스터의 개념과 일반적인 클러스터와 하이퍼바이저 위에서의 클러스터의 차이에 대한 설명을 완료하고자 함

Cluster의 개념

클러스터는 여러 대의 독립적인 컴퓨터 시스템(노드)를 하나의 논리적 집합으로 구성하여, 단일 시스템처럼 동작하는 구조를 말함

핵심 목적

• 가용성(Availability) 향상 : 일부 노드 장애 시에도 서비스 지속

• 성능 확장성(Scalability) 확보 : 노드 추가를 통한 처리 능력 향상

• 부하 분산 (Load Balancing) : 요청을 여러 노드에 분배하여 효율 극대화

• 장애 대응 자동화 (Fault Tolerance) : 장애 감지 및 복구 자동화

아키텍처 유형

HA(High Availability) 클러스터

: 하나의 노드가 장애를 일으켜도 다른 노드가 즉시 서비스를 이어받아 무중단운영을 보장하며 주로 은행, 공공기관 등 서비스 연속성이 중요한 환경에서 사용됨

Load Balancing 클러스터

: 사용자 요청을 여러 노드에 분산해 성능 처리 효율을 높이며 웹 서버, API 서버, 프록시 서버 구조 등에 주로 사용됨

Storage 클러스터

: 여러 저장 장치를 묶어 하나의 논리적 스토리지로 구성하고, 데이터 복제와 확장을 통해 안정성과 확장성을 확보함. 대표적으로 Ceph, GlusterFS 등이 있음

일반 클러스터의 구조

일반적인 클러스터는 물리 서버 간 진적 연결된 환경에서, 운영 체제(OS) 또는 애플리케이션 수준에서 클러스터링 기능을 구성함

각 노드는 네트워크를 통해 서로 통신하며, 특정 자원이나 서비스를 공동으로 운영함

예시

• Kubernetes 클러스터 : 컨테이너 기반 워크로드를 여러 노드에 분산

• MySQL cluster / Oracle RAC : 데이터베이스 복제 및 동기화를 통해 가용성 확보

• Hadoop Cluster : 데이터 연산을 여러 서버에 병렬 분산

구조적 특징

노드 계층

• 물리 서버(노드)로 구성됨
• 각 노드는 CPU, 메모리, 스토리지 등 자체 자원을 가짐
• 노드 간 고속 네트워크로 연결되어 통신 및 데이터 교환 수행

클러스터 계층

• 여러 노드를 논리적으로 묶는 관리 계층
• 노드 상태 감시(Heartbeat), 장애 감지, 자원 스케줄링 등의 역할 수행
• 대표 구성 요소: 클러스터 매니저 (Pacemaker, kubernetes, Controller 등)

서비스 계층

• 실제 사용자 서비스 또는 애플리케이션이 동작하는 영역
• 클러스터 매니저가 서비스의 배포, 상태 모니터링, 장애 복구를 자동화
• 예: 웹서버, DB 서비스, 컨테이너 워크로드 등

하이퍼바이저 기반 클러스터의 구조

하이퍼바이저 기반 클러스터는 가상화 기술을 이용해, 여러 하이퍼바이저 호스트를 하나의 관리 단위로 묶은 구조

주 목적은 가상머신(VM) 단위의 자원 관리, 가용성 확보, 자동화된 복구 및 확장성 제공에 있음

구조적 특징

물리 계층

• 실제 하드웨어 자원(CPU, RAM, NIC, Storage 등)으로 구성됨
• 각 하이퍼바이저 호스트는 동일하거나 유사한 스펙으로 구성되어야 함
• 네트워크와 공유 스토리지를 통해 상호 연결됨

가상화 계층

• 하이퍼바이저(VMware ESXi, KVM, Hyper-V 등)가 물리 자원을 가상화
• VM 생성, 스냅샷, 자원 할당 등 가상화 수행
• 각 VM은 독립된 OS와 애플리케이션을 운영

클러스터 계층

• 여러 하이퍼바이저 호스트를 중앙에서 관리하는 계층
• 자원 풀(Resource Pool) 형성 및 자동 부하 분산 수행
• 대표 도구: VMware vCenter, Proxmox Cluster Manager, SCVMM 등

VM 계층

• 클러스터 상에 배포된 가상머신들이 실제 서비스 수행
• 관리자는 VM 단위로 배포, 백업, 복구, 마이그레이션 가능
• OS, 애플리케이션, 네트워크 설정이 VM 단위로 독립

주요 기능

Live Migration

• 실행 중인 VM을 서비스 중단 없이 다른 호스트로 이동
• 호스트 점검, 부하 분산, 자원 재배치 시 활용

HA 기능

• 호스트 장애 감지 시 해당 VM을 다른 호스트에서 자동 재시작
• 서비스 중단 시간을 최소화하여 가용성 확보

공유 스토리지 통합

• 모든 노드가 동일한 스토리지에 접근 가능
• VM 이미지와 스냅샷이 중앙 저장소에 위치애 Live Migration 및 HA 기능을 지원
• Ex : NFS, iSCSI, vSAN, Ceph Storage 등

구조적 비교

GUI & CLI 활용

Web GUI

Proxmox는 웹 기반 관리 인터페이스를 제공하며, 대부분의 관리 작업을 브라우저에서 처리할 수 있음

• 대시보드 보기 : CPU·메모리·스토리지 자원 현황과 VM/컨테이너 상태를 시각적으로 표시함
• VM/컨테이너 관리 : 생성, 시작, 중지, 마이그레이션 등 주요 작업을 버튼 클릭으로 처리 가능
• 자원 모니터링 : VM·CT 별 CPU, 메모리, 네트워크, 디스크 사용향을 그래프 형태로 제공 → 성능 추세 및 병목 원인 파악에 유용
• 스토리지/네트워크 설정 : GUI 기반으로 ZFS 풀 관리, Ceph 클러스터 구성, 브리지·VLAN 생성 가능

CLI

Proxmox는 GUI와 동일한 기능을 CLI에서도 제공하며, 특히 자동화, 스크립팅, 대량 작업에 유용함

• pm 명령어 (QEMU/KVM VM 관리) : VM 생성, 시작, 중지, 삭제, 리소스 할당 변경 등 VM 관련 모든 작업을 CLI에서 수행 가능함

  qm list            # 현재 VM 목록 확인
  qm start 101        # VM ID 101번 시작
  qm stop 101        # VM ID 101번 중지
  qm create 102 --momory 2048 --cores 2 --net0 virtio,bridge=vmbr0 --ide2 local:iso/debian.iso,media=cdrom

- **pct 명령어 (LXC 컨테이너 관리)** : LXC 기반 컨테이너를 다루는 전용 명령어로, 가볍게 테스트 환경을 운영할 때 유용함

  pct list                    # 현재 컨테이너 목록 확인
  pct start 201                # 컨테이너 ID 201번 시작
  pct exec 201 -- bash        # 컨테이너 내부에서 명령어 실행
  pct shutdown 201            # 컨테이너 종료

사용자·권한 관리

계정 생성

Proxmox VE는 설치 직후 root@pam 계정으로 관리되지만, 운영 환경에서는 별도의 고나리 계정을 추가하는 것이 권장됨

Datacenter → Permissions → Users 메뉴

인증방식 선택

• PAM : Proxmox 서버의 Linux 사용자 계정과 연동
• Proxmox VE Auth : Proxmox의 자체 인증
• LDAP/AD 연동 : 기업 환경에서 중앙 계정 체계와 통합 가능

생성된 계정은 이후 특정 역할(Role)과 리소스(Resource)에 할당하여 세부 권한을 부여할 수 있음

RBAC

Proxmox는 역할 기반 접근 제어 방식을 사용하여, 개별 사용자에게 직접 권한을 주는 대신 역할을 정의하고 이를 사용자·그룹에 할당함

권한 부여는 Datacneter, Node, VM/CT 단위로 나눌 수 있음

Example

• Administrator : 전체 리소스 관리 가능
• PVEVMAdmin : VM 관련 작업 가능, 시스템 전체에는 제한
• PVEUser : VM/CT의 콘솔 접속, 시작·중지 같은 최소 권한만 부여

계층적으로 권한을 설정하면 불필요한 권한 남용을 방지하고, 관리 책임을 분리할 수 있음

시스템 모니터링

로그와 지표

• 로그 확인 : Proxmox는 각 노드의 VM/CT으 이벤트, 작업 이력을 GUI와 CLI모두에서 확인 가능함

  • Web GUI : Datacenter → Node → Syslog
  • CLI : journalctl -xe, /var/log/syslog, /var/log/pve/tasks/active 등
  • VM/CT 단위 로그는 Task History 메뉴에서 확인 가능

• 지표 모니터링

  • GUI 대시보드에서 CPU, 메모리, 디스크, 네트워크 사용량 실시간 확인 가능
  • 장기간 추이를 보기 위해 RRD(Round-Robin Database) 기반 그래프 제공
  • 필요 시 외부 모니터링 시스템(PPrometheus, Grafana) 연동 가능 → 알림·대시보드 확장

• 활용 목적

  • 장애 원인 분석 (ex: VM 다운 → CPU과부하 로그 확인)
  • 자원 추세 분석 (ex: 메모리 사용량 급증 → 증설 필요 판단)
  • 보안 이벤트 감시 (ex: 인증 실패 시도, 권한 없는 접근 시도 기록)

업데이트 및 패치 관리

OS 업데이트

Proxmox는 Debian 기반이므로, 기본 OS 업데이터는 apt 패키지 관리자로 수행

apt update
apt full-upgrade

• GUI : Node → Updates 메뉴에서 업데이트 가능
• 보안 권장 사항
  • 정기적 업데이트 스케줄 수립
  • 커널 업데이트 시 재부팅 필요 여부 확인
  • 변경 전 apt changelog로 업데이트 내역 확인

Proxmox 패치

Proxmox VE 자체 패키지는 별도의 저장소에서 관리됨

저장소 종류

• enterprise (유료) : 안정성과 장기 지원 중심

• no-subscription (무료) : 최신 업데이트는 빠르게 반영되나 안정성 검증 수준은 낮음

• test : 신규 기능 및 패치 조기 배포, 운영 환경에는 권장되지 않음

apt update
apt dist-upgrade

• GUI : Updates 탭에서 설치 가능, 커널 패치 포함 시 재부팅 필요
• 패치 관리 시 고려사항
  • 운영 환경에서는 enterprise 권장
  • 사내 검증 서버에서는 먼저 업데이트 적용 → 문제 없을 경우 운영 서버 반영
  • 보안 패치는 가급적 지체 없이 적용

❎보안 및 운영 고려사항

관리 인터페이스 보안

관리 인터페이스는 외부 공격에 가장 먼저 노출되는 영역이므로, 네트워크·계정·통신 프로토콜 차원에서 다층적 방어가 필요함

네트워크 분리

관리용 트래픽을 서비스망과 격리하여 사용

• Proxmox Web GUI 및 SSH 접속은 서비스 네트워크와 분리된 전용 관리망에서만 접근하도록 구성
• 방화벽 규칙을 통해 허용된 IP 대역만 접속 가능하도록 제한하면 불필요한 접속 시도를 줄일 수 있음

계정 및 인증 관리

root 직접 로그인을 피하고 관리자 전용 계정을 생성한 후 sudo 권한을 부여하는것을 권장함

• TOTP 기반 2FA 활성화 → 계정 탈취 리스크 낮춤
• LDAP/AD 연동 → 기업 단위의 중앙집중현 계정 관리 가능
• 로그인 실패 횟수 제한, Fail2Ban 연동 → 무차별 대입 공격 방지

SSL/TLS 적용

1️⃣기본 제공 인증서

• Proxmox는 설치 시 자체 서명된 SSL 인증서를 생성하여 HTTPS 통신 지원
• 단, 기본 인증서는 브라우저에서 보안 경고 발생

2️⃣신뢰할 수 있는 인증서 적용

• 운영 환경에서는 Let's Encypt 또는 사내 CA 인증서를 적용하여 신뢰성 확보
• GUI : Datacenter → Node → Certificates
• 자동 갱신 기능 제공 (acme.sh 기반)

3️⃣TLS 설정 강화

• 구식 프로토콜(TLS 1.0/1.1) 비활성화, TLS 1.2 이상 권장
• HSTS (HTTP Strict Transport Security) 적용으로 중간자 공격 방지

백업 및 데이터 보호

가상화 환경의 핵심은 데이터 무결성과 복구 가능성 확보로 단순히 백업을 수행하는 것에 그치지 않고, 주기적인 자동화·암호화·검증이 병행되어야 함

자동화와 스케줄링

: PBS:Proxmox Basckup Server를 이용하면 증분 백업, 압축, 중복 제거 기능을 통해 저장 효율성을 높일 수 있음

GUI : Datacenter → Backup

• VM/CT 단위로 스케줄 설정이 가능함
• 일반적으로 "일일 증분 + 주간 풀 백업" 구조가 사용됨
• 성능 저하를 줄이기 위해 비 업무 시간대에 실행하는 것이 적함함

백업 신뢰성 검증

: 저장된 백업은 실제 복구 테스트를 통해 유효성을 확인해야 함

단순히 백업 파일 존재 여부만으로는 복구시 정상 동작 여부를 알 수 없으므로 정기적으로 VM/CT를 복구해 정상 동작 여부를 검증해야함

데이터 암호화

• 전송 구간 : PBS는 기본적으로 TLS 기반 전송 암호화로 보호되며, SSH 터널링을 통해 원격 백업 시 추가 보안 계층 제공이 가능함

• 저장 데이터 : AES-256 기반 암호화 옵션 지원하고, 백업 저장소 탈취 시에도 데이터 보호 가능함   암호화 키는 별도 안전한 위치(HSM, Vault 등)에 보관 필요

장기 보관 및 정책 연계

: 장기 보관용 백업은 오프사이트 스토리지나 WORM (Write Once Read Many) 장치를 사용하는 것이 적절하며 접근 권한을 제한해 관리자가 아닌 운영자가 임의로 접근할 수 없도록 설정해야함

장단점

⭕장점

1. 보안 강화
   • 관리 인터페이스를 전용 VLAN으로 분리하고 방화벽으로 접근을 제한하면 외부 공격 표면이 줄어듦
   • TLS, 2FA 적용, SSH 키 기반 인증 등으로 계정 탈취 및 중간자 공격 위험을 낮출 수 있음
     
     
2. 데이터 안정성 확보
   • PBS를 활용한 증분 백업과 주간 풀 백업 조합으로 데이터 손실 가능성을 최소화 함
   • 정기적인 복구 테스트를 통해 백업 신뢰성을 검증할 수 있음
     
     
3. 운영 효율성 향상
   • 백업 자동화와 스케줄링, 중복 제거·압축 기능으로 스토리지 효율을 높이고, 관리 부담을 줄일 수 있음
     
     
4. 중앙 관리와 권한 제어 용이
   • LDAP/AD 연동으로 계정과 권한을 중앙에서 관리할 수 있음
   • TOTP 2FA와 접근 제한 적용으로 운영자 실수나 외부 공격으로 인한 피해를 줄일 수 있음

❌단점

1. 구축 초기 부담
   • 관리망 분리, TLS 인증서 발급, 백업 스케줄링 등 초기 설정 과정이 복잡하며, 경험이 없는 경우 시행착오가 발생할 수 있음
   • HSM, Vault, 오프사이트 레포지토리 등 보안 장치와 스토리지 확보 시 비용 부담이 증가함
     
     
2. 운영 부담
   • 정기적인 백업 상태 모니터링과 복구 검증이 필요하여 인력 또는 자동화 체계 없이는 관리 부담이 증가함
   • 백업·암호화 처리 시 가상화 환경 성능에 일시적 부하가 발생할 수 있음
     
     
3. 보안 취약 노출 가능성
   • 관리 인터페이스 접근 제한이 미흡하면 외부 공격에 노출될 수 있음
   • BMC나 관리 포트가 외부에 노출되어 있으면 공격자가 시스템에 접근할 수 있어 별도의 보안강화가 필요함

운영 사례

소규모 테스트 환경

• 기본 보안 설정적용 : 관리 인터페이스의 접근 제한, SSH 보안 강화, TLS 적용 등의 기본 보안 설정을 적용하여 데스트 환경의 보안을 강화할 수 있음

개인 연구실/서버 활용

• 백업 및 복구 전략 사용 : 개인 프로젝트나 연구용 서버에 대해 정기적인 백업 및 복구 전략을 적용하여 데이터 손실에 대비할 수 있음

중소규모 프로덕션

• 다층 보안 적용 : 관리 인터페이스 보안, TLS 보호, 백업 전략, 암호화 및 적앱을 통합하여 다층 보안을 적용하는 것이 중요함

• 정기적인 복구 테스트 수행 : 백업의 신뢰성을 확보하기 위해 정기적으로 복구 테스트를 수행하는 것이 권장됨

❎고급 활용

Ceph 분산 스토리지

Ceph는 Proxmox VE와 연동이 가능한 오픈소스 분산 스토리지로, 데이터 가용성과 확장성을 높이는 핵심 구성 요소

• 데이터 복제 및 내결함성 : Ceph OSD(Obejct Storage Demon)는 데이터를 여러 노드에 복제하여, 일부 노드 장애 시에도 데이터 손실 없이 운영이 가능함

• RBD:Black Device 지원 : VM/CT 디스크를 Ceph RBD로 구성하면 스냅샷, 복제, 라이브 마이그레이션이 가능함

• 확장성 : 노드 추가만으로 스토리지 용량과 I/O 성능을 확장할 수 있으며, Proxmox GUI에서 간편하게 클러스터 상태를 모니터링할 수 있음

⚠️ 네트워크 지연(latency)과 Ceph 모니터(MON) 노드 수 부족 시 성능 저하와 데이터 불균형이 발생할 수있음 → 최소 3개의 MON 노드를 권장함

HA 클러스터 운영

HA:High Availability 클러스터는 서비스 연속성을 보장하기 위해 VM/CT를 자동으로 재배치라는 기능을 제공함

• 자동 장애 대응 : 노드 장애 발생 시, 다른 노드로 VM/CT가 자동으로 마이그레이션되어 서비스 중단이 최소화됨

• 리소스 관리 : Proxmox Ve HA 관리자는 각 VM의 우선순위, 리소스 요구량을 고려해 재배치함

• Heartbeat 및 Quorum : 노드 간 상태 확인(Heartbeat)과 Quorum 체계를 통해 클러스터 분리(split-brain) 방지

⚠️ HA를 적용하면 스토리지 및 네트워크 부하가 증가하므로, 충분한 리소스 계획과 네트워크 분리가 필요함

방화벽 및 보안 정책

Proxmox VE 내장 방화벽과 네트워크 보안 정책을 활용하면 관리 인터페이스와 VM/CT 트래픽을 보호할 수 있음

• 노드 및 VM 단위 방화벽 : Proxmox GUI에서 노드, VM, CT 별로 입출력 규칙 설정이 가능함

• 정책 계층화 : Datacenter → Node → VM/CT 순으로 규칙을 상속하고, 우선순위 기반 정책 적용이 가능함

• SSH 및 서비스 보호 : 불필요한 포트는 차단하고 특정 IP만 접근을 허용함, Fail2Ban 연동 등으로 공격 표면 최소화

• 로그와 모니터링 : 방화벽 로그를 수집하여 비정상 트래픽 탐지 알람 체계와 연계 가능

Proxmox VE는 오픈소스 기반의 가상화 플랫폼으로, 가상머신(VM)과 컨테이너를 통합 관리할 수 있는 솔루션 Type 1 Hypervisor 구조를 기반으로 하드웨어 자원을 효율적으로 황용하며, 소규모 테스트 환경부터 기업용 클러스터까지 폭 넑게 활용이 가능함
이번 글에서는 Proxmox VE의 특징, 주요 기능, 아키텍처와 설치 과정까지 단계별로 정리함

❎Proxmox VE

가상화 플랫폼을 평가할 때 중요한 기준은 크게 두 가지로, 비용과 확장성을 결정하는 라이선스 모델, 어떤 혀앹의 가상화 단위를 지원하는가로 Proxmox VE는 이 두 가지 영역에서 차별점을 제공함

오픈 소스 기반으로 자유로운 확장과 검증이 가능하며, VM과 Container를 동시에 지원하여 다양한 운영 시나리오에 대응할 수 있음

오픈소스 가상화 플랫폼

상용 Hypervisor는 기능은 풍부하나 높은 라이선스 비용과 특정 벤더 종속 문제가 있음 Proxmox VE는 GNU AGPL 라이선스 기반으로 소스 코드가 공개된 오픈소스 소프트웨어로 사용자는 코드 검토, 커스터마이징, 기능 확장이 가능하며 라이선스 부담 없이 기업 환경과 연구용 환경 모두에 적용할 수 있으며

보안의 투명성, 비용 절감, 활발한 커뮤니티 기반의 지속적인 발전 및 개선

이라는 강점을 가지고 있음

VM과 Container

Proxmox VE는 가상머신(VM)과 컨테이너(LXC) 두 가지 가상화 방식을 동시에 지원함

• VM는 하드웨어를 완전히 가상화하여 각기 다른 운영체제를 독립적으로 실행할 수 있도록 해주고,
• Container는 호스트 OS 커널을 공유하면서 경량화된 격리 환경에서 애플리케이션을 실행함

이 구조를 통해 Proxmox Ve는 리소스 효율성과 운영 유연성을 높이고, 다양한 워크로드 환경에 맞춘 가상화 전략 구현이 가능함

특징

Type 1 Hypervisor 기반

Proxmox VE는 Type 1 Hypervisor 구조를 선택함

• 하드웨어 위에서 직접 실행되므로 OS 위에서 동작하는 Type 2 Hypervisor 보다 성능과 안정성이 높음
• CPU, Memory, Storage 등 하드웨어 자원을 직접 관리할 수 있어 VM과 Container의 자원 할당 효율이 뛰어남
• Type 1 구조는 클러스터 환경과 HA(High Availability) 구성 시에도 신뢰성과 확장성을 제공함

Storage & Network

Proxmox VE는 Storage과 Network 구성을 다양하고 유연하게 지원함

• Storage : LVM, ZFS, Ceph, NFS 등 다양한 스토리지 백엔드를 통합 관리할 수 있고, 각 스토리지의 특성에 맞춘 VM/Container 배치와 성능 최적화가 가능함
• Network : bridge, VLAN, Bonding, SDN 등 다양한 네트워크 구성을 지원하여 가상 환경의 분리, 보안 확장성을 확보할 수 있음

이러한 기능은 클러스터와 HA 환경 구성, 대규모 배포 시 유연한 리소스 관리를 가능하게 함

❎주요 기능

VM & Container 관리

VM(KVM 기반)과 컨테이너 (LXC 기반)를 통합 관리할 수 있음

• KVM: Kernal-based Virtual Machine : 하드웨어 수준 가상화를 제공하여 완전히 독립된 OS 환경 실행 가능한 VM
• LXC: LinuX Containers : 호스트 OS 커널을 공유하며 경량화된 격리 환경에서 애플 : 호스트 OS 커널을 공유하면서 경량화된 격리 환경에서 애플리케이션을 실행할 수 있는 컨테이너

생성 및 삭제

: GUI 또는 CLI를 통해 가상머신과 컨테이너를 쉽게 생성·삭제 할 수 있으며, CPU, 메모리, 디스크 등 리소스 할당을 세밀하게 조정할 수 있음

스냅샷 및 복제

: 특정 시점의 상태 저장 및 복구가 가능하고 복제 기능으로 동일한 환경을 신속하게 배포하며 데스트, 백업, 장애 복구 효율이 향상됨

Storage 관리

다양한 스토리지 옵션 활용으로 성능과 확장성을 최적화 할 수 있음

LVM/ ZFS 지원

• LVM: Logical Volume Manager : 물리 디스크를 논리 볼륨으로 추상화해 유연한 디스크 관리와 스냅샷 지원

• ZFS: Zettabyte file system : 데이터 무결성 검증, 스냅샷, 중복 제거, 대용량 스토리지 지원

• 로컬 디스크 기반에서 스냅샷, 중복 제거, 데이터 무결성을 확보

Ceph 분산 스토리지

• Ceph : 오픈 소스 분산 스토리지 시스템으로, 데이터를 여러 노드에 분산 저장하고 자동 복제 수행
• 클러스터 환경에서 고가용성(HA)을 보장하며, 대규모 가상 환경에서도 안정적인 데이터 관리 가능

Network 관리

가상 네트워크 구성과 관리 기능이 유연하며, 고급 네트워크 환경을 구축할 수 있음

• 브리지, VLAN, Bonding : 네트워크 분리, 트래픽 관리, 링크 결합으로 대역폭 확장 및 장애 대응

• HA 및 클러스터 네트워크 : 클러스터 환경에서 노드 간 통신과 장애 조치(failover) 지원, 안정적 운영 보장

백업 및 복구

데이터의 보호와 운영 연속성 확보

• vzdump : VM과 컨테이너를 파일 단위로 백업, 압축 및 스토리지 선택 가능

• 스케줄링 자동화 : 정기 백업 스케줄 설정으로 관리 부담 감소, 장애 시 신속 복구 지원

❎아키텍처

Proxmox Ve 아키텍처는 하드웨어 자원 관리, 가상화 기술, 클러스터링 지원 등 다양한 계층으로 구성되어 있음

Hypervisor 구조

Hypervisor는 물리 서버의 하드웨어 자원을 추상화하여 여러 가상 환경에서 공유할 수 있도록 관리하는 소프트웨어 계층

• Type 1 : 하드웨어 위에서 직접 실행되며 성능과 안정성이 우수하여 HA 환경 구성에 적합함

• Type 2 : 기존 OS 위에서 실행되며 설치가 용이하지만 성능이 제한적임

Proxmox VE 의 Type 1 Hypervisor

• 하드웨어 위에서 직접 실행되어 VM과 컨테이너의 성능과 안정성이 높음
  
  
• CPU, 메모리, I/O 장치 등 하드웨어 자원을 직접 제어할 수 있음
  • 직접 제어하게 되면 가상화 오버헤드를 최소화 할 수 있으며, I/O의 처리속도가 향상되고, 고성능 워크로드 및 대규모 가상 환경에서 안정적으로 운영이 가능함
    
    
• 디스크, 네트워크 카드, GPU 등 주요 장치를 직접 매핑할 수 있음
  
  
• Intel VT-x / AMD-V 등 하드웨어 가상화 기술을 지원함

VM & Container

Proxmox VE는 컨테이너를 통합 관리하며, 각 기술은 목적과 특성에 따라 선택이 가능함

KVM

각 VM이 독립 OS 환경으로 실행할 수 있음

하드웨어 가상화와의 결합 → 안정성 및 성능 극대화 스냅샷, 클론, 라이브 마이그레이션 지원

LXC

경량 컨테이너로 자원을 효율적으로 사용함

호스트 OS 커널 공유, 빠른 생성 및 배포 네트워크, 파일시스템, 프로세스 격리로 보안 유지 대규모 컨테이너 환경에서도 관리 효율이 높음

하드웨어 의존성

Proxmox VE는 물리 하드웨어 성능과 설정에 크게 의존하며, 이를 이해해야 최적의 가상 환경 구축이 가능함

UEFI / BIOS 연동

• 부팅 과정에서 하드웨어 초기화와 장치 인식 수행
• UEFI 기반 → GPT 파티션, Secure Boot 지원
• 최신 서버 화경에서 안정적 부팅 및 보안 제공

CPU, 메모리, 디스크 요구사항

• 멀티 코어 CPU, 충분한 메모리, 고속 디스크 필요
• SSD/VNMe 사용시 I/O 성능 극대화
• 클러스터 환경에서는 노드 간 균형 잡힌 리소스 배치 필수

확장성과 호환성

• 다양한 서버 하드웨어 지원
• RAID, Ceph, ZFS 등 스토리지 옵션 연계 가능
• 클러스터 확장 시 병목 최소화, 안정적 가상화 환경 구축

추가 고려사항

• 네트워크 인터페이스 카드(NIC) 수와 대역폭
• GPU 패스스루 활용 시 호환성 확인
• 하드웨어 장애 시 VM/컨테이너 마이그레이션과 HA 동작 검토

❎설치와 초기 설정

Proxmox VE를 안정적으로 운영하기 위해서는 설치 전 시스템 요구 사항을 확인하고, ISO 설치과정을 정확히 이해하며, 설치 후 초기 설정을 통해 기본 환경을 구성해야 함

시스템 요구 사항

CPU : 64비트 프로세서, Inter VT-x 또는 AMD-V 지원 권장 Memory : 최소 2GB, VM/컨테이너 운영 환경에서는 8GB 이상 권장 Disk : 최소 32GB, 운영 환경에서는 SSD/NVMe 사용 권장 Network : 최소 1Gbps NIC 1개, 클러스터 구성 시 여러 NIC 권장 UEFI/BIOS 설정 : 가상화 기능 활성화 필요 (Intel VT-x/AMD-V, VT-d/AMD-Vi)

| 참고 : 클러스터 또는 HA 환경에서는 각 노드의 하드웨어 균형과 스토리지 공유가 필수적임

ISO 설치 과정

1. ISO 다운로드
   • Proxmox VE 공식 사이트에서 최신 ISO 이미지 다운로드
2. 부팅 매체 준비
   • USB 똔ㄴ CD/DVD에 ISO 이미지를 작성하여 부팅 가능 상태로 준비
3. 부팅 및 설치 선택
   • 서버를 ISO 부팅
   • 설치 메뉴에서 Install Proxmox VE 선택
4. 디스크 선택 및 파티션
   • 설치 대상 디스크 선택
   • ZFS, LVM 등 스토리지 옵션 선택 가능
   • RAID 구성 또는 단일 디스크 설치 가능
5. 네트워크 설정
   • IP 주소, 서브넷, 게이트웨이, DNS 등 기본 네트워크 정보 입력
   • 클러스터 환경에서는 각 노드 고성 IP 설정 필수
6. 관리자 계정 및 암호 설정
   • root 계정 비밀번호 설정
   • 관리용 이메일 입력
7. 설치 완료 후 재부팅
   • 설치 완료 후 ISO 제거
   • 서버 재부팅 → 웹 GUI 또는 CLI 접근 가능

초기 설정

1. 웹 GUI 접속
   • 브라우저에서 https://<서버IP>:8006 접속
   • root 계정과 설치 시 설정한 비밀번호로 로그인
2. 스토리지 및 데이터센터 구성
   • 로컬 디스크, LVM, ZFS, Ceph 스토리지 추가
   • 백업 경로 및 정책 설정
3. 네트워크 검증
   • 브리지, VLAN, Bonding 등 필요 네트워크 구성
   • VM/Container 생성 전 연결 테스트
4. 업데이트 및 패지 적용
   • Proxmox VE 패키지 최신 상태 확인 및 업데이트
   • 보안 패치 적용, 방화벽 설정
5. 클러스터 또는 HA 환경 준비 (선택 사항)
   • 다중 노드 환경 구성 시 각 노드 등록
   • HA 및 리소스 스케줄링 확인

설치 후 초기 설정 단계는 VM/Container 생성과 안정적 운영을 위해 필수이며, 하드웨어 및 네트워크 환경에 따라 세부 설정이 달라질 수 있음

클라우드 보안 서비스이자 SSE의 구성요소인 SWG와 FWaaS에 대한 개념 공부와 정리

☁️SWG: Secure Web Gateway

정의와 필요성

Secure Web Gateway는 기업 사용자가 인터넷과 클라우드 애플리케이션에 접근할 대 발생할 수 있는 위협을 탐지하고 차단하는 SaaS 또는 On-prem 보안 솔루션

사용자 단말에서 발생하는 웹 트래픽을 실시간으로 분석하고 제어함으로써, 악성 사이트 접속, 데이터 유출, 피싱 공격 등 다양한 위협으로부터 조직을 보호하는 것이 목적

SWG는 단순 URL 차단이나 방화벽의 기능을 넘어, SaaS 사용 증가, 원격 근무 확산 등 현대 IT 환경에서 발행하는 보안 공백을 메우는 핵심 서비스로 자리잡고 있음

On-prem Proxy/Gateway의 한계

• 기존 On-prem Proxy나 Gateway는 사내 네트워크 경계에 집중된 구조로, 원격 근무자나 모바일 단말에서 발생하는 트래픽까지 일관되게 보호하기 어려움

• 기업 외부에서 클라우드 서비스에 접근하는 트래픽은 대부분 우회되거나 VPN을 통해서만 모니터링이 가능하여 관리의 복잡성과 비용이 증가함

• 하드웨어 장비 중심으로 설계되어 확장성이 낮고, 트래픽 증가 시 성능 저하나 병목 현상이 발생할 수 있음

SaaS·Web 위협 증가

• 클라우드 애플리케이션과 SaaS 사용이 확대되면서 기업의 데이터와 트래픽은 사내 네트워크 외부에서 발생하고 있음

• HTTPS 기반 트래픽이 대부분을 차지하고, 피싱 사이트, 악성코드 배포, 브라우저 취약점 공격 등 웹 계층의 위협이 증가함

• 기존 L3/L4 방화벽이나 IPS만으로는 웹 트래픽 내부의 세밀한 위협 탐지가 어려움

주요 기능

1️⃣ URL/콘텐츠 필터링

SWG는 접근 사이트를 카테고리별로 구분하고, 업무와 관련 없는 콘텐츠를 차단함

• 사이트 카테고리(도박, 성인, 소셜 미디어 등) 기반 접근 제어
• 조직 정책과 규정에 맞지 않는 웹 콘텐츠 실시간 통제
• 최신 위협 사이트 데이터베이스 기반 실시간 탐지

2️⃣ 악성코드 탐지 및 차단

웹 다운로드 파일이나 이메일 첨부 파일을 검사하여 잠재적 위협을 제거함

• 시그니처 기반 Anti-Virus
• 샌드박스 분석 및 CDR 기술
• 엔드포인트 감염 방지와 함께 악성 코드 확산 차단

3️⃣ CASB·DLP 연계

SWG는 클라우드 애플리케이션 사용 가시성을 확보하고 민감 데이터 업로드/다운로드 시 DLP 정책을 적용함

• 비인가 SaaS 탐지 및 제어
• 기업 데이터 유출 위험 감소
• 정책과 규제 준수 요구사항 충족

4️⃣ 암호화된 트래픽 검사 (SSL/TLS)

HTTP 트래픽 복호화를 통해 콘텐츠와 악성코드를 검사함

• HTTPS 트래픽 복호화 후 콘텐츠 검사
• TLS 암호화로 숨겨진 공격 탐지
• 성능 저하 가능성과 개인정보 보호 규제 고려 필요

배포 방식과 정책 적용

배포 방식

SaaS : 클라우드 기반으로 제공되며, 확장성과 유지보수 편의성이 높음

On-prem : 사내 장비 설치형으로 로컬 트래픽 처리 성능이 우수하며, 규제상 데이터를 로컬에 저장해야할 경우 적합함

Hybird : SaaS와 On-prem 기능을 병행, 원격 근무자와 내부 네트워크 모두 보호할 수 있음

정책 적용 범취 및 세분화

사용자 / 그룹 / 지점·지역 단위로 정책을 세순화하여 적용할 수 있고 URL 필터링, 악성코드 검사, DLP 연계 등 각 기능별 정책 설정이 가능함

example

• 특정 부서만 소셜 미디어 접근 허용
• 민감 문서를 외부 클라우드로 업로드할 경우 차단
• 원격 근무자 트래픽은 클라우드 SWG를 통해 검사

효과와 한계

SWG를 도입하면

그 효과는...

• 사용자 단말과 웹/SaaS 접속 간 보안 강화 : 모든 웹 트래픽과 SaaS 접근을 실시간 검사해, 악성 사이트와 위협을 차단할 수 있음

• 원격 근무 환경에서도 정책 일관성 확보 : 위치나 기기에 관계 없이 중앙 정책을 적용할 수 있음

• 위협 탐지와 데이터 보호 동시 제공 : 민감 데이터 유출 방지와 보안 사고에 조기 대응할 수 있음

그 한계점은...

• SSL 복호화로 인한 네트워크 지연 가능 : HTTPS 검사 과정에서 트래픽 처리 속도 저하 가능

• 개인정보 보호 규제 준수 필요 : 일부 데이터는 복호화 과정에서 규제 영향을 받을 수 있음

• 일부 고급 기능은 벤더 종속 : 샌드박스, CDR 등 일부 기능은 벤더별 구현 차이가 있음

☁️FWaaS: Firewall as a Service

정의와 필요성

Firewall as a Service(FWaaS)는 전통적 방화벽 기능을 클라우드 환경에서 제공하는 네트워크 보안 서비스

기업의 지점, 클라우드, 원격 사용자 트래픽을 중앙에서 통제하고, L3~L7 레벨에서의 접근제어와 위협 탐지를 수행함으로써, 복잡한 Multi-Cloud 환경과 글로벌 지사 연결에서도 보안을 일관되게 유지하는것이 목적

FWaaS는 단순 방화벽 장비를 대체하는 것에 그치지 않고, 클라우드 네이티브 아키텍처와 통합된 중앙 관리형 보안 솔루션으로, 지사, 클라우드, 모바일 환경까지 통합적인 보호를 가능하게 함

전통적 방화벽의 한계

• 사내 네트워크 경계 중심으로 설계되어 클라우드와 원격 근무자 트래픽 보홓에 한계가 있음

• 지사별 장비 설치가 필요하여 관리 복잡성과 운용 비용이 증가함

• 트래픽 증가와 글로벌 지사, 원격 근무자 환경 확대로 성능 저하와 확장성 제한이 발생함

• 전톡적 장비 기반 방화벽만으로는 IDS/IPS, 위협 인텔리전스, 세분화된 트래픽 제어 등 현대 보안 요구를 충족하기 어려움

Multi-Cloud·지점 연결 복잡성 증가

• 기업 환경이 Multi-Cloud로 확장되면서 다양한 클라우드 서비스와 SaaS 접속 트래픽 통합 과리가 필요함

• 지사, 원격 근무자, 모바일 사용자의 트래픽까지 중앙에서 일관되게 정책 적용이 어려움

• 네트워크와 애플리케이션 계층을 동시에 보호해야하는 필요성과 요구가 존재함

• 중앙 관리면 FWaaS를 통해 정책 일관성 확보와 위협 탐지, 네트워크 보호가 가능함

주요 기능

1️⃣L3/L4/L7 접근제어

FWaaS는 네트워크 계층과 애플리케이션 계층에서의 접근을 통제함

• L3/L4 : IP, Port 기반 필터칭, NAT, VPN 지원
• L7 : 애플리케이션별 접근 제어, URL 기반 정책 적용
• 원격 사용자와 지사 간 트래픽에 일관성있는 정책 적용 가능

2️⃣Segmentation 및 Traffic 제어

Segmentation 및 traffic 제어는 내부 네트워크와 클라우드 환경에서 트래픽을 논리적으로 분리하고 제어하여 네트워크 안정성을 확보함

• 애플리케이션, 서비스, 부서별 트래픽을 구분하고 제어함
• 과도한 트래픽과 비인가 접근을 제한함

3️⃣IDS/IPS·위협 인텔리전스 통합

IDS/IPS 및 위협 인텔리전스 통합은 침임 탐지와 방지, 최신 공격 탐지, 정책 기반 대응을 가능하게 함

• 침임 탐지/방지 시스템(IDS/IPS)과 통합됨
• 글로벌 위협 인텔리전스 연동으로 최신 공격 탐지 가능함
• 악성 트래픽을 자동으로 차단하고 정책 기반 대응 수행함

4️⃣중앙 관리·글로벌 정책 적용

중앙 관리와 글로벌 정책 적용은 클라우드 콘솔을 통해 지사, 클라우드, 원격 사용자까지 일관된 정책을적용하고 관리함

• 중앙 콘솔 기반으로 정책과 트래픽을 관리함
• 지사, 클라우드, 원격 사용자에 대한 글로벌 정책을 일관되게 적용함
• 정책 변경 시 전 지점에 즉시 동기화됨

배포 방식과 정책 적용

배포 방식

SaaS : 클라우드 기반으로 제공되며, 확장성과 유지보수 편의성이 높음

On-prem : 사내 장비 설치형으로 로컬 트래픽 처리 성능이 우수하며, 규제상 데이터를 로컬에 저장해야할 경우 적합함

Hybird : SaaS와 On-prem 기능을 병행, 원격 근무자와 내부 네트워크 모두 보호할 수 있음

정책 적용 범취 및 세분화

example

• 특정 지사에서 특정 애플리케이션 접근만 허용
• 중요 서버 트래픽은 별도 세그먼트로 분리
• 원격 근무자 VPN 트래픽은 중앙 정책으로 검사

효과와 한계

FWaaS를 도입하면

그 효과는...

• 네트워크 트래픽 및 애플리케이션 접근 통제 강화 : L3~L7 계층에서 세밀한 접근 정책 적용가능, 위협 차단

• Multi-Cloud 및 지사 환경에서 정책 일관성 확보 : 중앙 콘솔 기반 관리로 글로벌 환경에서도 동일한 정책 적용

• 위협 탐지와 대응 효율화 : IDS/IPS와 위협 인텔리전스 통합으로 실시간 탐지 및 대응 가능

그 한계점은...

• 복잡한 정책 설계 시 초기 설정 난이도 존재 : 지사, 사용자, 클라우드 환경까지 고려한 세밀한 정책 필요

• 클라우드 의존성으로 특정 트래픽 처리 지연 가능 : SaaS형 배포 시 클라우드 처리 속도와 네트워크 상태 영향

• 고급 기능은 벤더 종속적 : IDS/IPS, segmantation, 글로벌 정책 동기화 등 벤더별 구현 차이

☁️클라우드 보안 아키텍처안의 역할

SWG의 역할

SWG는 사용자와 클라우드 서비스 사이의 신뢰할 수 있는 관문 역할을 하여 클라우드 환경에서의 안전한 애플리케이션 활용을 보장함

SWG는 사용자의 웹 및 SaaS 애플리케이션 접근 구간에서 보안 게이트웨이 역할

• 웹 트래픽을 실시간으로 분석하여 악성 사이트, 피싱, 악성코드 유입을 차단함

• SaaS 접근 시 데이터 유출을 방지하고, CASB·DLP와 연계하여 민감 정보 보호 강화함

• 네트워크 경계 기반 방어에서 벗어나 사용자 단말과 클라우드 서비스 간 연결을 직접 보호하는 계층으로 작동함

FWaaS의 역할

FWaaS는 기업 네트워크 전체를 보호하는 확장형 방화벽 서비스로, 분산된 IT 인프라 환경에서 네트워크 보안의 기반을 제공함

_FWaaS는 네트워크 전반을 아우르는 방화벽 기능을 클라우드 기반으로 제공하며, 기업의 멀티 클라우드·분산 환경을 보호하는 핵심 인프라 보안 계층

• L3/L4/L7 계층 전반에서 접근 제어와 트래픽 필터링 수행함

• 네트워크 세그멘테이션을 통해 지사, 클라우드, 데이터센터간 트래픽을 구분하고 비인가 접근을 탐지·차단함

• 중앙 관리 콘솔을 기반으로 전 세계 지점과 클라우드 리소스에 일관된 보안 정책을 적용함

언제 어디서든 접근이 가능하기 때문에 업무 효율은 향상되었지만, 동시에 데이터 유출, 악성 코드 감염, Shadow IT 등 새로운 보안 위협이 등장하게 됨

이러한 위협은 기존 On-prem 보안솔루션은 클라우드의 분산 환경과 다수 앱·서비스를 효과적으로 보호하기 어려움

방화벽과 VPN은 클라우드 트래픽 내부를 틀여다 보거나, SaaS 앱 내부의 민감 데이터를 통제 불가능

이러한 문제를 해결하기 위해 등장한 것이 바로 CASB: Cloud Access Security Broker

🔗CASB란?

CASB는 클라우드 서비스 접근 보안 중개자라는 의미로, 기업의 내부 네트워크와 클라우드 서비스 제공자(CSP) 사이에 위치하여 모든 클라우드 트래픽을 모니터링하고 제어하는 보안 솔루션

클라우드 서비스 사용에 대한 가시성을 제공하고, 데이터 유출 방지, 위협 탐지, 규제 준수 등을 지원

사용자가 클라우드 앱에 접근할 때 CASB가 중개자 역할을 수행하고 사전에 설정된 보안 정책을 적용해 데이터와 사용자를 보호함

배경 및 필요성

1. Shadow IT 증가 승인되지 않은 클라우드 앱 사용이 증가하면서 기업의 IT 통제 범위를 벗어난 서비스 사용이 발생

   CASB는 앱 사용 현황을 가시화하고, 위험도가 높은 앱을 통제함으로써 관리자가 보안 정책을 적용할 수 있도록 지원

2. 클라우드 데이터 유출 위험 민감한 데이터가 클라우드에 저장되면서 유출 가능성이 높아짐

   DLP, 암호화, 토큰화 등을 통해 데이터를 보호하고, GDPR, 국내 개인정보 보호법, 정보통신망법 등 관련 규제를 준수할 수 있도록 도움

벤더 및 제품 참고

Microsoft Defender for Cloud Apps : M365 친화적, 실시간 정책 강점

Netskope : API+프록시 하이브리드, 고도화 UEBA 제공

McAfee MVISION : 글로벌 SaaS 지원, 로그 감사 기능 우수

Palo Alto Prisma Cloud : IaaS/PaaS 보안 강점

🔗주요 기능

CASB는 클라우드 환경에서 발생하는 다양한 위협을 다층적으로 방어함 가시성 확보부터 데이터 보호, 위협 탐지, 규제 준수까지 포괄적으로 대응할 수 있음

가시성 확보

조직 내 승인되지 않은 클라우드 앱 사용 현황을 파악하고, 각 앱의 위험도를 평가하여 관리자가 이를 제어할 수 있도록 함

예시

- IT 부서가 모르는 파일 공유 서비스 탐지
- 비인가 앱 사용 경고 발송 및 차단

데이터 보안

DLP: Data Loss Prevention : 클라우드로 유입·유출되는 민감 데이터를 식별 및 차단 Encryption : 데이터가 외부에 노출되더라도 내용을 읽을 수 없도록 변환 Tokenization : 실제 데이터 대신 토큰을 사용하여 민감 정보 보호

예시

- 고객 개인정보가 포함된 문서 업로드 시 자동 암호화
- 외부 공유 링크 접근 제한

위협 방어

클라우드 앱을 통해 유입될 수 있는 악성 코드나 랜섬웨어, 피싱 공격을 탐지 및 차단

UEBA(User and Entity Beehavior Analytics)와 연계, 사용자·엔티티 행동 분석 비정상적인 접근 및 행위를 실시간으로 감지하고 대응

예시

- 평소와 다른 시간대 대향 다운로드 시 경고
- 외부 IP에서 비정상 로그인 시 세션 차단

규제 준수

HIPAA, GDPR, CCPA 와 같은 국내외 규제 및 법규 준수를 돕고 클라우드 서비스 사용 내역에 대한 상세 감사 로그 생성 및 정책 위반 시 자동 알림 및 리포드를 제공해줌

예시

- 감사 대비, 사용자별 접근 기록 저장
- 규제 준수 상태 대시보드 제공

규제/법률대응

🔗배치 방식

CASB는 크게 3가지 방식으로 배치되며 각각의 장단점이 매우 뚜렷함

🔹프록시 기반

사용자 요청을 CASB를 통해 우회 시키는 방식

- Forward Proxy

용자의 웹 브라우저나 클라이언트가 CASB를 거쳐 클라우드 서비스로 접근하게 함 브라우저/클라이언트 → CASB → 클라우드

장점: 실시간 트래픽 제어 가능 단점: 클라이언트 설정 필요, 일부 앱 지원 제한

- Reverse Proxy

클라우드 서비스로 들어오는 트래픽이 CASB를 먼저 거치도록 함 클라우드 → CASB → 브라우저/클라이언트

장점: 클라이언트 설정 불필요, 관리 용이 단점: 서비스별 설정 필요

🔹API 기반

CASB가 CSP의 API를 이용해 클라우드앱에 직접 연결하는 방식

장점: 기존 데이터에 대한 정책 적용 가능, Shadow IT 탐지 단점: 실시간 제어 제한, API 지원 여부에 따라 기능 제한

🔸하이브리드 배치

실제 기업환경에서 많이 사용되는 프록시 기반과 API 기반을 결합하여 사용하는 방식

실시간 정책 적용이 중요한 SaaS 앱은 프록시 방식을 사용하고, 클라우드 스토리지에 저장된 파일 검사와 같은 비실시간 작업에는 API 방식을 활용하는 등 두 방식의 장점을 모두 취할 수 있음

배치 방식 비교

🔗적용 예시

SaaS 앱 보호

: Microsoft 365, Google Workspace, Salesforce 등

• 민감 정보 외부 공유 차단
• 부서별 접근 권한 설정 가능

IaaS/PaaS 보안

: AWS, Azure, GCP

• CSP misconfiguration 자동 탐지
• 외부 접근 가능 스토리지 확인, 악성 코드 유입 방지

원격 근무 환경

• 재택근무자의 클라우드 사용 모니터링
• 보안 정책 일관 적용, 데이터 유출 예방

🔗도입 시 고려사항

CASB는 클라우드 환경 보안을 강화하는 강력한 도구지만, 성급히 도입하면 운영 복잡성이나 성능 저하 문제를 겪을 수 있기 때문에 체계적으로 검토후 진행해야 함

규모와 환경

조직의 규모, 사용하는 클라우드 서비스 유형(SaaS, IaaS, PaaS 등)에 따라 요구 기능이 달라짐 Multi-cloud · hybrid 환경에서는 관리 범위와 복잡서이 급격히 커질 수 있음

체크포인트

✅ 도입 범위와 조직의 클라우드 사용 현황이 일치하는지 확인

정책과 운영

세부 정책 수립·적용 과정이 복잡할 수 있으며, 관리자가 직접 운영할 수 있는 수준인지 고려해야함 과도한 정책은 업무 생산성을 저하시킬 수 있음

체크포인트

✅ 관리 인력 역량 및 자동화·템플릿 지원 여부 확인

성능과 UX

트래픽 경유 방식의 CASB는 지연(Latency)문제를 야기할 수 있으며, 사용자 경험에 직접적인 영향을 줌 성능 저하가 클 경우 현업 반발이 발생할 수 있음

체크포인트

✅ 파일 업로드/다운로드 처리 속도, 사용자 불편 최소화 여부 검증

기존 보안 솔루션 통합

IAM, DLP, SIEM, SWG 등 기존 솔루션과 연동이 매끄럽지 않으면 운영 복잡도가 증가함 CASB 단독 운영보다는 생태계 통합성이 중요함

체크포인트

✅ API·로그 연동, 정책 통합 관리 가능 여부 검토

비용 효율성

구독형 과금 모델이 대부분으로 사용자 수·드래픽 증가에 따라 비용이 크게 늘어날 수 있음 장기적으로 ROI(투자 대비 효과)를 검토해야함

체크포인트

✅ 초기 도입·운영비·확장비용까지 총소유비용(TCO) 분석

이번 글에서는 네트워크와 보안 기능을 클라우드 기반으로 결합한 프레임워크인 SASE와 보안 기능을 담당하는 SSE에 대한정리글을 작성함

☁️SASE 란?

SASE Secure Access Service Edge는 네트워크 기능과 보안 기능을 하나의 클라우드 기반 플랫폼에서 통합하여 제공하는 아키텍처 모델

기존에는 데이터센터 중심의 WAN과 방화벽·VPN·보안 게이트웨이 등 별도의 장비로 분리되어 있었음

→ 그러나 이는 클라우드 확산 + 원격 근무 증가로 인해, 경계 기반 모델은 지연·병목·보안 사각지대 문제를 유발

따라서

SASE는 단순히 기술의 집합이 아니라 네트워크 접근과 보안 정책을 클라우드 기반에서 통합 관리하는 새로운 패러다임

기존의 경계 기반 보안 모델의 한계를 극복하는 보안과 네트워크 성능을 동시에 확보할 수 있는 구조를 제공함

☁️필요한 이유

1) 클라우드 전환 가속화

기업들이 On-prem 데이터센터 대신 SaaS, IaaS, PaaS 등 클라우드 서비스를 적극 도입하면서 트래픽이 분산됨

→ 모든 원격 트래픽을 본사 데이터센터로 다시 보내는 기존의 백홀링(Backhauling) 방식은 지연·병목과 같은 성능 저하 유발 → SASE는 사용자와 클라우드를 직접 연결하여 지연 최소화

2) 원격·모바일환경 확산

사무실 밖에서 접속하는 사용자가 늘어나면서, 기존 VPN 기반 구조는

• 연결 지연
• 확장성 한계
• 사용자 경허 저하

와 같은 문제를 초래함

→ SASE는 모든 접속 지점에서 동일한 정책을 적용하여 보안 일관성을 확보함

3) 복잡성 및 비용 절감

여러 벤더의 분산된 하드웨어 장비를 운영하는 것은 관리와 유지보수에 많은 시간과 비용이 소모됨

→ SASE는 클라우드 기반 단일 플랫폼으로 운영을 단순화 하고 총소유비용(TCO)를 낮춤

4) 보안과 성능 동시 확보

SASE는 단순히 보안을 제공하는 것을 넘어, SD-WAN과 같은 기술을 활용해 트래픽 경로를 최적화하고 애플리케이션 성능을 향상시킴

→ 보안 강화와 사용자 경험 개선을 동시에 달성할 수 있음

☁️구성요소와 기능

SASE는 네트워크 기능(WAN Edge)과 보안 기능(SSE)의 통합 구조로 구성됨 두 요소가 결합되어야만 경계없는 네트워크를 달성할 수 있음

네트워크 기능 (WAN Edge Service)

네트워크 영역은 기존의 단순 연결성 제공을 넘어, 애플리케이션 중심·사용자 경험 중심으로 최적화된 경로를 제공하는 것이 핵심

SD-WAN

• 물리적 네트워크 연결을 추상화하고, 애플리케이션별 요구사항에 따라 최적의 경로를 동적으로 선택
• 지사 및 원격 사용자 트래픽을 데이터센터를 거치지 않고 클라우드로 직접 연결하여 지연(Latency)을 최소화 함
• 정책 기반 트래픽 라우팅과 QoS적용으로 중요한 업무 애플리케이션 성능을 보장함

접속 최적화

• 지연, 패킷 손실, 대역폭 부족 등 네트워크 품질 문제를 실시간으로 모니터링하고 자동 조정
• 트래픽 경로 선택, WAN 가속, 패킷 최적화, 경로 재시도 등의 기능 포함
• 클로벌 클라우드 서비스 접속 시에도 사용자 위치에 관계없이 안정적인 성능을 제공

중앙 집중형관리

• 네트워크 정책과 트래픽 흐름을 단일 관리 콘솔에서 설정, 모니터링이 가능
• 분산된 지사·클라우드 환경에서 일관된 네트워크 정책 적용을 가능하게 함

SSE와의 관계

SSE (Security Service Edge)는 SASE에 네트워크 기능을 제외한 보안 기능의 집합으로 SASE의 보안을 전담하는 구조

SSE의 주요 기능

접근 통제 : ZTNA 웹/클라우드 보호 : SWG, CASB, FWaaS 데이터 보호 : DLP

ZTNA (Zero Trust Network Access)

• 모든 접속을 기본적으로 신뢰하지 않고, 사용자의 신원 단말 위치 등을 검증 후 최소 권한만 허용
• VPN보다 세분화된 접근 제어와 동적 권한 관리 기능
  

CASB (Cloud Access Security Broker)

• 클라우드 애플리케이션 사용 가시화, 데이터 보안 및 규정 준수 적용
• Shadow IT 탐지, 데이터 암호화, 접근 통제 기능 제공
  

SWG (Secure Web Gateway)

• 웹 트래픽을 실시간으로 검사하여 악성코드, 피싱, 멀웨어 등 위협 차단
• URL 필터링, HTTPS 검열, 콘텐츠 검사 기능 포함
• 원격 사용자와 지사 모두 일관된 웹 보안 정책 적용
  

FWaaS (Firewall-as-a-Service)

• 클라우드 기반 방화벽으로 트래픽 필터링 및 악성 활동 차단
• 정책 적용, 로그 수집, 위험 탐지 기능 포함
  

DLP (Data Loss Prevention)

• 민감 데이터 유출 방지 및 정책 위반 시 차단
• 이메일, 파일, 클라우드 애플리케이션 등 다양한 채널에서 데이터 흐름 모니터링

SASE와 SSE의 포함 관계

SSE ⊂ SASE: SSE는 SASE의 보안 기능 집합으로, 네트워크 기능(SD-WAN)을 제외한 보안서비스만 포함

• SSE는 단족으로 클라우드 보안 솔루션에서 활용 가능
  • 단계적 도입 전략에 적합함
• 완전한 SASE 환경에서는 SSE 기능과 네트워크 기능이 통합되어 중앙 관리와 일관된 정책 적용 가능

☁️구현과 운영 관점

도입 전략

• 단계적 도입

  • 현실적으로 모든 네트워크 장비와 보안을 한 번에 교체 불가
  • 기업은 주로 SSE 먼저 도입(ZTNA, SWG 등) → 이후 SD-WAN과 통합

• 클라우드 기반 정책 관리

  • 중앙 집중형 콘솔에서 사용자·앱·데이터 정책 배포
  • 보안 규정 준수, 접근 로그 관리가 쉬워짐

• 벤더 전략

  • 단일 벤더: 통합성, 일관된 관리 장점
  • 멀티 벤더: 특정 기능 최적화 가능, 그러나 통합 난이도 증가

운영 모델

자체 운영(On-Prem Control)

• 장점: 정책 세부 조정 가능, 내부 보안팀 역량 활용
• 단점: 인력·비용 부담, 24/7 운영 난이도

MSP (Managed Service Provider) 활용

• 장점: 전문인력에 의한 운영 효율, SLA 보장
• 단점: 특정 사업자 종속, 맞춤형 정책 제약

하이브리드 모델

• 핵심 인프라는 자체 관리, 일부 영역은 MSP에 위탁
• 글로벌 기업이 주로 채택하는 방식

고려사항 및 도전과제

성능 관리

• 문제점 : 글로벌 PoP(Points of Presence) 위치에 따라 지연 차이가 발생 이는 클라우드 애플리케이션의 성능에 직접적인 영향을 줌
• 보강 : SLA(Service Level Agreement) 확인 필수, 벤더의 글로벌 PoP 분포도, 클라우드 서비스와 피어링 연결 상태를 확힌
  

규제 준수

• 문제점 : 데이터 국외 반출, 개인정보보호법, GDPR 등과 직접 연결되는 것은 법적 리스크를 초래함
• 보강 : SASE가 특정 국가에 내의 데이터 처리 의무를 지원하는지 세분화된 Data Localization 정책 설정 기능을 제공하는지 확인
  

운영 복잡성

• 문제점 : 멀티 클라우드, 멀티 벤더 환경에서 정책 충돌 위험
• 보강 : 통합 관리 콘솔의 기능과 API 연동의 용이성을 평가기준으로 해야함
  

사용자 경험

• 지나친 보안 적용은 UX 저하 → 성능 최적화 기능 병행 필요

☁️트렌드와 전망

가트너는 2025년까지 80% 이상의 기업이 SASE 또는 SSE를 단계적으로 도입할 것으로 전망함.

향후 동향

• 시장 성숙도

  • 초기에는 보안 우선(SSE) → 이후 네트워크 통합(SASE) 단계적 확산

• Zero Trust 연계

  • ZTNA는 사실상 필수 요소 → SSE의 핵심 축으로 자리

• 클라우드 네이티브 지향

  • 멀티 클라우드, 하이브리드 환경에 맞춘 POP 최적화와 글로벌 네트워크 확대

• 보안·네트워크 융합 인력 수요 증가

  • 단순 보안 운영자보다, 네트워크·보안을 동시에 이해하는 엔지니어 중요
  • DevSecOps와 유사하게 NetSecOps 개념이 확산될 가능성 있음

이번 글에서는 요즘 보안 및 접근제어 분야에서 많이 언급되는 용어중 하나인 Zero Trust에 관한 정리 및 설며을을 진행하고자 함

⚡보안의 환경변화와 Zero Trust

경계기반 모델의 한계

개요

1980년대로 초에 등장한 경계기반 모델은 네트워크 보안 아키텍처에서 외부와 내부를 명확히 구분하여 외부의 위협은 차단하고 내부의 사용자는 암묵저으로 신뢰하는 보안 모델로 1990년대부터 2000년대 초반까지 주로 사용됨

큰 특징으로는

• 방화벽 중심 보안 : 물리적, 논리적 경계에 방화벽을 설치하여 외부로부터의 접근을 통제

• 내부 시스템에 대한 신뢰 : 내부로 진입한 사용자는 신뢰할 수 있는 대상으로 간주하여 접근 권한을 부여

• 정적인 보안 정책 : 보안 정책이 네트워크의 경계에만 국한되고, 내부 시스템의 변화나 사용자 화동에 대한 동적 감시 부족

한계

현대로 들어서며 모바일과 클라우드, 그리고 원격근무가 확산됨에 따라 경계기반 모델의 비중은 점점 줄어들고있음

*그 이유로는 *

경계 모호화 : 모바일 클라우드, 원격 근무의 확산으로인해 내부와 외부를 명확히 구분하기 어려워지고 경게 자체가 더 이상 고정되지 않음

내부 위협 취약성 : 내부 사용자가 악의적 행위를 하거나 계정이 탈취되면, 내부는 기본적으로 신뢰된 영역이므로 빠르게 피해가 확산됨

측면 이동 방치 : 외부 공격자가 경계를 우회하여 내부로 들어오며, 네트워크 내에서 자유롭게 이동할 수 있어 주요 자산이 쉽게 노출됨

정적 정책의 한계 : 경계기반 정책은 환경 변화나 사용자 행위에 따라 동적으로 대응하지 못하며, 클라우드와 IoT 환경과 같은 빠른 변화에 취약함

공격 대응 부족 : 알려진 위협 차단에는 효과적이지만, 경계를 통과하는 ZeroDay나 신종공격에 대해서는 방어력이 현저히 떨어짐

실제 침해 사례

공급망 공격

SolarWinds 공급망 공격(2020) | CISA 보고서

네트워크 관리 솔루션 업데이트에 악성코드가 삽입되어 미국 정부기관과 글로벌 기업 수천 곳이 침해당함

• 공급망 공격이 근본 원인으로 보여지지만 내부 진입 후 장기간 탐지되지 않고 자유롭게 측면 이동한 것은 경계기반 모델의 취약성

랜섬웨어

colonial Pipeline 랜섬웨어 (2021) | FBI 발표

VPN 계정 탈취로 내부망에 침투하여 미국 최대 송유관 운영이 중단됨

• VPN 계정이 탈취되자 내부 전체가 신뢰되는 구조로 인한 내부 위협 취약성이 드러난 사례

데이터 유출

Captial One 데이터 유출 (2019) | 미국 법무부

잘못 구성된 클라우드 방화벽을 통해 약 1억 건의 고객 정보가 유츌됨

• 직접적으로 클라우드 환경 설정 오류이지만 클라우드를 전제로 한 동적·세분화 접근제어가 없었던 점은 경계기반 모델의 한계

⚡ZT: Zero Turst

2010년 Forrester가 발표한 "Zero Trust Nerwork Architecture Report"에서 처음 사용된 용어

NIST의 정의 (Sp 800-207)

미국 국립표준기술연구소(NIST:National Institute of Standards and Technology)는 Zero Trust 다음과 같이 정의함

"항상 네트워크가 침해되었다고 가정하고, 보호해야할 자원에 대해 최소 권한만 부여하는 아이디어와 개념의 집합"

이를 통해 알 수 있듯이, Zero Trust는 특정 솔루션이나 기술이 아닌보안 접근 개념이자 전략임

보호 자원 범위

Zero Trust는 네트워크 내부와 외부를 구분하지 않고, 모든 자산과 통신을 보호 대상으로 간주함

핵심 3대 원칙

_Never Trust Always Verify_

1. 지속적 검증, 모니터링

모든 사용자, 디바이스, 애플리케이션이 자원에 접근할 대마다 신원, 디바이스 상태, 위험도를 검증하며 접근할 때 마다 해당 검사를 통과해야하는 원칙으로 세션이 연결되어 있어도 주기적으로 재검증을 진행함

• 동적 정책 기반 접근 : Zero Trust는 위치, 시간, 행위 등 컨텍스트에 따라 정책을 동적으로 조정하고, 지속적인 인증·인가 반복과 모니터링 결과를 기반으로 정책을 개선하려 위협 대응 능력을 강화함

2. 최소 권한 원칙

사용자가 수행하는 작업에 필요한 최소한의 권한만 부여하고 세션 종료 시 자동으로 회수하여 내부와 외부의 위협으로부터 시스템을 보호함

3. 침해 가정 원칙

네트워크의 내부, 외부와 상관없이 항상 침해가 발생했다고 가정하고 모든 접근과 데이터 흐름을 검증하여 공격 확산을 조기에 차단

효과

위 원칙과 구현 방식을 통해 다음과 같은 위협을 최소화할 수 있음

• 내부 침입자 활동 : 내부 사용자의 악의적 행위나 계정 탈취로 인한 피해를 방지함

• 계정 탈취로 인한 권한 남용 : 최소 권한 원칙을 통해 권한 남용을 차단함

• 악성코드의 측면 이동 및 확산 : 지속적인 모니터링과 검증을 통해 악성코드의 확산을 방지함

ZT 접근 방식의 특징

• 보호 자원의 식별 및 분류 : 모든 자원을 식별하고, 중요도에 따라 분류하여 보호함

• 정책 기반 접근 제어 : 사용자와 디바이스의 상태, 위치, 시간 등을 고려하여 동적으로 접근 정책을 적용함

• 지속적인 모니터링 및 분석 : 모든 활동을 실시간으로 모니터링하고, 이상 징루를 분석하여 대응함

• 자동화된 대응 및 회복 : 위협 탐지 시 자동으로 대응하고, 시스템을 신속하게 회복시킴

⚡ZTA: Zero Trust Architecture

Zero Trust Architecture는 Zero Trust 원칙을 조직의 IT 인프라에 적요앟여 실제로 구현한 보안 아키텍처로, 내부와 외부를 불문하고 자원을 보호하고, 정책 시반 접근을 통해 위협을 최소화하는 설계 모델

정의와 특징

네트워크가 이미 침해되었다고 가정하고, 모든 자원 접근에 대해 최소 권한과 지속적 검증을 적용하는 보안 아키텍처

• 마이크로 단위 자원 세분화 : 데이터, 애플리케여신, 클라우드 리소스등 개별 단위로 보호

• 정책 기반 접근 제어 : 접근 요청마다 정책 평가 후 허용 여부 결정

• 중앙 모니터링과 분석 : 모든 접근 및 활동 로그를 실시간 수집·분석

• 내부 횡적 이동(Lateral Movement) : 공격자가 내부로 침투하더라도 자유로운 이동을 차단

구성 요소

1. Policy Engine (PE)

• 접근 요청을 평가하고 허용 여부를 결정하는 핵심 엔진
• 사용자, 디바이스, 애플리케이션 상태, 컨텍스트 정보를 기반으로 판단

2. Policy Administrator (PA)

• PE의 결정을 실행하고, 세션을 생성 및 관리
• 정책 적용과 접근 세션 유지/종료 담당

3. Policy Enforcement Point (PEP)

• 실제 자원 접근을 제어
• 접근 요청을 차단하거나 허용하며, 로그를 수집하여 중앙 모니터링과 연동

4. 지원 데이터 소스

• CDM(Continuous Diagnostics and Mitigation), Threat Intellignece, SIEM 등
• 실시간 위협 정보와 자산 상태 데이터를 제공하여 정책 결정 지원

구현 방식

• ID 기반 접근 제어 : 사용자와 장치 인증 후 최소 권한으로 접근 허용

• micro segmentation : 네트워크와 자원을 세부 단위로 분리하여 내부 이동 제한

• SDN/SDP 기반 동적 정책 적용 : 네트워크 정의 및 소프트웨어 기반 접근 정책으로 동적 제어

도입 절차

KISA의 Zero Trust 가이드라인 2.0

NIST 기준 도입 절차

1. Prepare: 조직과 시스템 환경 분석 및 ZTA 준비

2. Categorize: 보호할 자원과 시스템을 유형화

3. Select: 보안 제어와 정책 선택

4. Implement: 제어를 시스템에 적용

5. Assess: 구현된 제어의 효과성과 적합성 평가

6. Authorize: 시스템 운영 허가 및 승인

7. Monitor: 지속적 모니터링으로 정책과 보안 상태 유지

ZTA는 단순 기술 도입이 아니라 조직 환경과 업무 프로세스에 맞춘 단계적 설계와 정책 기반 통합 보안 적용을 전제로 함

⚡ZTNA: Zero Trust Network Access

ZTA 원칙을 네트워크 접근 제어에 적용하여 구체적 구현된 기술·솔루션

정의

Zero Trust Network Access는 전통적인 VPN 접근 방식과 달리, 네트워크 위치와 관계없이 모든 사용자를 기본적으로 신뢰하지 않고, 각 자원에 대한 접근 권한을 최소 권한 원칙과 지속적인 검증 원칙에 따라 제어하는 접근 제어 방식

ZTNA는 클라우드 환경, 원격 근무, 모바일 기기 등 분산 환경에서 보안성을 강화하고, 내부자 위협과 계정 탈취, 측면 이동 공격 등을 방지하도록 설계됨

핵심 특징

• 사용자와 디바이스가 검증되어야만 자원 접근 허용
• 접근 요청마다 신원, 디바이스 상태, 위치, 시간, 행위 등 컨텍스트기반 검증
• 중앙 정책 서버에서 접근 제어 정책을 실시간 적용
• 전통적인 네트워크 경계와 무관하게 자원 보호

VPN과의 차이

VPN은 네트워크 경계를 중심으로 한 "접속 중심 보안"이고 ZTNA는 "자원 중심 보안"으로 접근 방식과 보안 수준에서 차별화됨

유형

ZTNA는 구현 방식에 따라 크게 두가지로 나뉨

In-line 방식

• 모든 트래픽이 중앙 ZTNA 게이트웨이를 거쳐 전달됨
• 실시간 접근 정책 평가 및 트래픽 검사 기능
• 장단점
  • 장점 : 세밀한 접근제어, 트래픽 모니터링 가능
  • 단점 : 트래픽 지연 발생 가능

Agent-based 방식

• 단말에 ZTNA 에이전트를 설치하여 자원 접근 시 인증/인가 수행
• 네트워크 경로를 직접 변경하기 않고 접근 제어
• 장단점
  • 장점 : 설치 용이. 지연 최소화
  • 단점 : 에이전트 관리 필요, 일부 트래픽 모니터링 제한

: 추가적으로 일부 솔루션은 하이트리드 방식을 제공하여, 인라인과 에이전트를 결합해 유연성과 성능을 동시에 확보하기도 함

활용사례

• 원격 근무 환경 보호 : 재택 근무자 및 모바일 사용자의 기업 애플리케이션 접근 시 자원 단위 인증 적용

• 클라우드 애플리케이션 보안 : SaaS, IaaS 접근 시 사용자 및 디바이스 상태 검증, 최소 권한 적용

• 내부 위협 및 계정 탈취 대응 : 권한 남용 및 측면 이동 공격 방지

• 보안 규제 준수 : 금융, 헬스케어 등 규제 산업에서 접근 로그 , 인증 기록, 정책 적용 증빙 가능

• 멀티 클라우드 환경 통합 : 다양한 클라우드 플랫폼과 SaaS에 대한 일관된 접근 제어 정책 적용

⚡연계 기술 및 도전 과제

연계 기술

SASE: Secure Access Service Edge : 클라우드 기반 보안과 네트워크 서비스를 통합, ZTNA와 결합 시 사용자 위치와 디바이스 상태에 따른 접근 제어를 클라우드 환경 전반에 적용 가능

• 기능 : SD-WAN, 방화벽, CASB, ZTNA 통합
• 장점 : 클라우드 및 원격 환경에서 일관된 정책 적용, 운영 단순화

SDP: Software Defined Perimeter : 네트워크 경계를 소프트웨어 정의하고 접근 권한을 동적으로 제어, ZTNA와 유사하게 자원 단위 접근 제어 제공

• 장점 : 내부 횡적 이동 차단, 접근 요청 시 실시간 인증
• 활용 : 원격 근무자, 클라우드 애플리케이션 보호

구현·운영 고려사항

ZTNA 도입 시 다음과 같은 기술적·운영적 과제를 고려해야 함

정책 관리 복잡성

• 자원 단위, 사용자/디바이스 단위 접근 정책 설계 필요
• 정책 수가 많아질 수록 관리와 모니터링 부담 증가

기존 인프라와의 호환성

• 레거시 시스템이나 구형 애프리케이션과 통합 시 제한 발생 가능

성능 및 사용자 경험

• 지속적 인증, 모니터링으로 지연 발생 가능
• 사용자 인즈 과정이 번거로울 경우 생산성 저하 가능

조직적 과제

• 표준화된 정책 체계 구축
• IAM/IDaaS 통합을 통한 사용자 및 권한 관리
• 로그 수집·분석 및 모니터링 자동화

⚡동향과 전망

정부와 산업

• 미국, 유럽 등 주요 국가에서 ZTNA 및 SASE 가이드라인 발표
• 금융, 헬스케엇 등 규제 산업에서 단계적 ZTNA 도입 증가
• 원격 근무, 클라우드 전환으로 보안 전략의 중심으로 부상

기술적 발전

• 클라우드 네이티크 ZTNA 솔루션 상용화 증가
• AI/ML 기반 접근 분석 및 이상 탐지 기능 통합
• 멀티 클라우드·하이브리드 환경에서 정책 일관성 확보 기술 발전
• 통합 보안 플랫폼 내 ZTNA, SASE, SDP 결합 솔루션 확대

Zero Trust는 기술 자체보다는 전략적 접근이며, 단계적 도입과 기존 인프라와의 연계, 사용자 경험 고려가 성공적 구현의 핵심임

우리가 많이 사용하는 IP:Internet Protocol은 OSI 계층에서 L3 Network 계층에 해당하는 _"인터넷 상에서 데이터를 목적지까지 전달하기 위한 규칙과 주소 체계"_로 우리는 정보를 송신하고 수신하기 위해 IP 주소를 사용함

이러한 IP주소는 크게 고정 IP와 동적 IP로 나누어짐

고정 IP [Static IP]

Static IP는 사용자가 직접 IP, SubnetMask, Gateway, DNS 서버를 설정하는 방식으로 현재는 주로 서버, 네트워크 장비처럼 항상 동일한 IP가 필요한 경우에 사용하고 있음

[장점]

• 예측 가능하고 변하지 않으므로 특정 서비스 (웹 서버, DB 서버 등) 운영에 적합함

[단점]

• 네트워크 규모가 커질수록 수동 관리가 복잡해짐

• 실수로 중복된 IP를 할당할 경우 충돌이 발생함

• 이동 단말이나 임시 연결 장치에서는 비효율적임

동적 IP [Dynamic IP]

DHCP 서버가 자동으로 IP 및 네트워크 정보를 할당하는 방식으로 클라이언트는 부팅 시 별도 설정 없이 자동으로 IP를 할당 받음

[장점]

• 대규모 네트워크에서도 효율적으로 관리 가능

• IP 충돌 가능성 최소화

• 장치 추가 시 별도의 작업 불필요

특징⭐

• 주소는 임대(Lease) 개념으로 제공되며, 만료 시 반환되거나 갱신 가능

• DHCP Reservation 기능을 통해 특정 장치에 항상 동일한 IP를 할당할 수 있음(MAC 기반)

• 일반 사용자 PC나 모바일 단말에서는 주로 동적 IP를 사용하고, 서버급 장비에서는 예약 (Reservation) 또는 Static IP를 사용함

DHCP

네트워크의 초창기에는 소수의 장치만 연결되어 있었기 때문에 Static IP 방식이 주로 사용되었음 그러나 기업 네트워크와 인터넷의 확산으로 인해 단말의 수가 수백~수천 단위로 증가하게 되면서 문제가 발생하게 됨

• 관리자는 모든 단말의 IP를 수동으로 지정해야 했음 → 관리 부담 증가
• 사용자가 이동하거나 새로운 장치를 추가할 때마다 재설정 필요
• 중복 IP로 인한 충돌 문제와 주소 낭비 발생

이러한 문제를 해결하기 위해 RARP: Reverse Address Resolution Protocol가 사용되었음

RARP를 활용한 IP 할당은 장치가 자신의 MAC 주소를 기반으로 RARP 서버에서 IP 주소를 할당받는 방식으로

• IP 주소만 제공하며 SubnetMask, Gateway, DNS 등 추가 네트워크 정보는 설정이 불가능
• IP 회수 및 관리가 비효율 적이고 대규모 네트워크에 부적합

이러한 한계를 가지고 있었음

결국 이러한 한계를 해결하기 위해 IP 자동 할당과 더불어 네트워크 설정 전체를 지원하는 시스템이 필요했고, 이를 위해 등장한 프로토콜이 바로 DHCP: Dynamic Host Configuration Protocol)임

DHCP의 개념과 특징

DHCP: Dynamic Host Configuration Protocol 은 네트워크에 연결된 클라이언트가 자동으로 IP 주소와 네트워크 정보를 할당받도록 지원하는 프로토콜

IP 주소 뿐만 아니라 SubnetMask, Gateway, DNS 서버와 같은 핵심 네트워크 설정을 클라이언트에게 자동으로 전달함

특징

큰 특징으로는...

• 네트워크 관리 자동화 및 효율성 향상

• IP 주소를 임대 개념으로 관리하여 자원 재활용 가능

• 멀티 VLAN 환경에서도 DHCP Relay 기능을 통해 확장 가능

• 불법 DHCP 서버 공격 등 보안 위협 존재 → DHCP Snooping 같은 보안 기능 필요

DHCP의 원리

DHCP는 클라이언트-서버 구조로 동작하며, 임대(Lease) 기반 주소 관리 방식을 가짐

1. 클라이언트가 네트워크에 처음 연결될 때 IP가 없는 상태에서 요청 시작

2. DHCP 서버는 주소 풀(Address Pool)에서 가용 IP를 찾아 클라이언트에게 임시 제공

3. 클라이언트는 해당 주소를 일정 시간(Lease Time) 동안 사용

4. Lease Time이 만료되기 전에 클라이언트는 갱신 요청을 수행함

5. 사용을 종료하거나 다른 네트워크로 이동하면 주소는 회수되어 다른 장치에 재할당 가능

동작 순서 (DORA Process)

DHCP는 4단계의 과정을 통해 주소를 할당함 (= 이를 DORA라고 칭함)

_Discover, Request → 항상 브로드캐스트_ _Offer, Ack → 대부분 브로드캐스트지만, 환경에 따라 유니캐스트 가능_

1. Discover

• 클라이언트가 Broadcast로 DHCP 서버를 탐색
• 클라이언트는 아직 IP가 없으므로 Src=0.0.0.0 사용

  MAC:    Src=Client-MAC, Dst=ff:ff:ff:ff:ff:ff
  IP:        Src=0.0.0.0,     Dst=255.255.255
  UDP:    SrcPort=68,     DstPort=67
  DHCP:    Message Type = DHCP Discover

2. Offer

• 서버가 가용 IP와 SubnetMask, Gateway, DNS, Lease Time을 포함한 제안 메시지 전송
• Dst는 보통 브로드캐스트지만, 일부 환경에서는 새로 할당된 클라이언트 IP로 유니캐스트 전송

  MAC:    Src=Server-MAC, Dst=Client-MAC (or Broadcast)
  IP:        Src=10.0.0.100,    Dst=255.255.255 (or Client-Mac Unicast)
  UDP:    SrcPort=67,     DstPort=68
  DHCP:    Message Type = DHCP Offer
            Your-IP-Address = 10.0.0.10
            Lease-Time = 3600s
            Subnet-Mask = 255.255.255.0
            Router = 10.0.0.1
            DNS = 8.8.8.8

3. Request

• 클라이언트가 특정 서버(Identifier)와 IP를 선택해 요청
• 중복 서버가 있을 경우 원하는 서버를 지정 가능
• 아직 IP 미확정이므로 Src=0.0.0.0 유지

  MAC:    Src=Client-MAC, Dst=ff:ff:ff:ff:ff:ff
  IP:        Src=0.0.0.0,    Dst=255.255.255
  UDP:    SrcPort=68,     DstPort=67
  DHCP:    Message Type = DHCP Request
            Requested-IP-Address = 10.0.0.10
            Server-Identifier = 10.0.0.100

4. Acknowledge

• 서버가 요청 승인 후 최종 임대 확정
• 클라이언트는 해당 IP를 사용해 네트워크 통신 시작
• Dst는 보통 브로드캐스트지만, 일부 환경에서는 새로 할당된 클라이언트 IP로 유니캐스트 전송

  MAC:    Src=Server-MAC, Dst=Client-MAC (or Broadcast)
  IP:        Src=10.0.0.100,    Dst=255.255.255 (or Client-IP 10.0.0.10)
  UDP:    SrcPort=67,     DstPort=68
  DHCP:    Message Type = DHCP ACK
            Your-IP-Address = 10.0.0.10
            Lease-Time = 3600s
            Subnet-Mask = 255.255.255.0
            Router = 10.0.0.1
            DNS = 8.8.8.8

3-Tier Hierarchical Network에서 DHCP 역할

3-Tier 구조(Access, Distribution, Core) 내에서 DHCP는 각 계층에 따라 다음과 같이 동작함

Access Layer

• Client 단말이 DHCP Discover 메시지 송신

• 필요 시 DHCP Relay 기능 설정 가능

• Access Switch 역할 : 직접 DHCP 기능을 수행하지 않고, 클라이언트 요청을 DHCP 서버로 전달 (DHCP Relay 기능 필요)

Distribution Layer

• VLAN 기반으로 네트워크 세그먼트를 분리하는 계층

• DHCP Relay Agent(IP Helper Address) 설정을 통해 Client 요청을 DHCP 서버로 전달

• 옵션 82를 통해 Client 위치 정보를 함께 전달 가능

Core (Backbone) Layer

• 고속 라우팅 및 트래픽 전달 중심 계층

• DHCP 서버는 보통 이 계층에 직접 배치하지 않음

• 단순히 Relay 트래픽을 빠르게 전달하는 역할을 수행

DHCP 서버의 위치

일반적으로 Distribution 또는 Core 인접 서버존에 배치됨

[기능]

• IP, 서브넷, 게이트웨이, DNS 제공

• 주소 풀 관리 및 임대 시간 설정

• 특정 장치에 대한 IP 예약

• 멀티 VLAN 환경 지원

네트워크 구성도 이해를 위한 Access Switch, Distribution Switch, Backbone Switch에 대한 정리 글을 작성함

들어가기 앞서

Access Switch, Distribution Switch, Backbone Switch를 이해하기 위해서는 먼저 계층형 네트워크 설계에 대한 정리를 할 필요가 있음

계층형 네트워크 설계란

네트워크를 역할별 계층으로 구분하여 안정성, 확장성, 효율성을 확보하는 설계방식으로 일반적으로 Access, Distribution, Core 계층으로 나눠짐

3-Tier Hierarchical Design

대규모 엔터프라이즈 네트워크에 적합한 설계 방식

• Access Layer : 단말기가 연결되는 계층

• Distribution Layer : 정책 적용 VLAN 간 라우팅, 보안 제어를 담당하는 계층

• Core Layer : 고속 백본 역할, 대규모 트래픽을 빠르게 전송

2-Tier Hierarchical Design

중소규모 네트워크 환경에 적합한 설계 방식

• Core와 Distribution 계층을 하나로 통합함 (Access Layer는 그대로 존재)

• 설계 단순화와 비용 절감이 가능함

• 대규모 환경에서는 확장성과 유연성이 제한됨

이 중에서 3개의 스위치를 설명할 수 있는 3 Tier-Hierarchical Design에 대해 보다 자세하게 설명하고 진행함

3-Tier Hierarchical Design

네트워크를 Access-Distribution-Core 3계층으로 나눠 역할을 분리하는 구조로 주로 대규모 기업, 캠퍼스 네트워크에서 표준적으로 사용됨

구성 방식

• Access Layer
  • 사용자 단말, 서버, 무선AP 등이 직접 연결되는 계층
  • VLAN, 포트보안, PoE, Broadcast 제어 기능을 수행함
  • 장비 : Access Switch
    
    
• Distribution Layer
  • Core Layer로 전송하기 전 여러 Access Switch의 트래픽을 집계함
  • 안정적인 운영을 위해 라우터 이중화 프로토콜을 사용
  • VLAN간의 라우팅, 정책(ACL,QoS), 로드 밸런싱과 중복성을 제공함
  • 장비 : L3 Distribution Switch, Router
    
    
• Core Layer
  • 네트워크의 Backbone 역할 수행함
  • Distribution Layer로 부터 수신된 모든 트래픽을 집계
  • 빠른 전송과 높은 대역폭(고성능)을 제공하며, 장비 복구를 중심으로 동작함
  • 네트워크 확장이 필요한 경우, 장비를 추가하는 것이 아닌 속도가 빠른 장비로 교체
  • 정책 처리 최소화하고, 고성능 L3 스위칭을 담당함
  • 장비 : Backbone(Core) Switch

필수 장비

• Access Switch (L2/L3 가능)
• Distribution Switch (일반적으로 L3)
• Backbone Switch (고성능 L3, 대규모 백본 전송용)
  _ 경우에 따라 Router, Firewall, Load Balancer 등 추가_

장점 및 한계

• 장점
  1. 확장성 = 계층 분리로 손쉬운 증설 가능
  2. 유연성 = 서비스 추가나 장비 교체 시 전체 네트워크 영향 최소화
  3. 관리 용이성 = 정책·보안 적용을 Distribution 계층에 집중
  4. 성능 최적화 = Core는 단순 고속 전달만 수행
  5. 안정성·복원력 = 중복 경로와 계층적 구조로 장래 격리에 용이
     
• 단점 및 한계
  1. 복잡성 증가 = 3계층으로 분리하면서 설계·운영 관리가 어려워짐
  2. 지연 가능성 = 트래픽이 Access→Distribution→Core를 거치면서 홉 수 증가
  3. 비용 부담 = 각 계층별 전용 장비 필요 → 장비·운영 비용 상승
  4. 중소규모 환경 비효율 = 소규모 조직에는 과도한 구조, 불필요한 계층 발생

Access Switch

Access Switch는 네트워크의 가장 말단에 위치하여 사용자 단말과 네트워크를 직접 연결하는 장치 PC, 노트북, IP 전화기, 프린터, 무선 AP, IoT 센서 등 다양한 장치가 이 스위치를 통해 네트워크에 접속하며, 이 과정에서 VLAN, 포트 보안, 트래픽 제어와 같은 기본 관리 기능을 수행함

• Access Layer에 속하고 Distribution Layer와 연결됨
• 단말과 서버 간 안정적 연결을 보장함
• 네트워크 접근을 통제하고 초기 트래픽을 분산시켜 성능과 보안을 함께 책임짐

단순한 연결 장비를 넘어, 사용자 경험을 좌우하고 네트워크 운영의 안정성을 뒷받침 하는 핵심 축

기능

• L2 스위칭 : MAC 주소 기반으로 프레임을 전달하여 같은 VLAN 내 단말 간 통신을 가능하게 함

• VLAN 분리 : 동일 네트워크 안에서 논리적 구획을 나누어 broadcast 범위를 제한하고 보안성을 높임

• PoE: Power over Ethernet : 무선 AP, IP 전화기, IoT 기기 등 전원 공급이 필요한 장치에 데이터와 전원을 동시에 제공함

• 접속 보안 : 802.1X, 포트 보안, DHCP Snooping과 같은 기술을 통해 단말 인증과 불법 장치 접속 차단을 지원함

• QoS 기본 지원 : 음성·영상과 같은 지연에 민감한 트래픽을 우선 처리할 수 있도록 품질 보장 기능 제공

역할

• 사용자 접속 지점 : 수 많은 단말이 접속하는 최전선으로, 네트워크 전체의 안정성과 보안의 출발점이 됨

• Broadcast 제어 : 단말이 늘어나도 네트워크 혼잡을 최소화하도록 트래픽을 제어하고 상위 계층으로 전달되는 불필요한 패킷을 줄임

• 접근 통제 게이트웨이 : 사용자가 네트워크를 이용하기 전에 반드리 거쳐야 하는 관문으로서, 인증과 권한 검증의 1차 단계 수행

• 문제 격리 : 장애나 오작동이 발생했을 때, 영향 범위를 단말 연결 구간에 제한하여 상위 계층의 안정성을 보장함

존재 이유

효율적 수용 : 기업이나 캠퍼스 환경에서 수백~수천 단말을 효과적으로 수용하기 위한 필수 장비

보안적 전제 : 네트워크의 첫 진입점을 통제하지 않으면, 상위 계층에서 악성 트래픽이나 비인가 장치가 직접 영향을 미치게되므로 Access Switch는 기본적인 보안 통제 기능을 내재해야 함

운영 효율성 : 사용자 단에서 발생하는 빈번한 연결·해제·이동 요청을 로컬에서 처리하여, 상위 Distribution/Core 계층에 불필요한 부하를 주지 않음

서비스 품질 유지 : 음섬 통화, 화상회의, 원격업무 같은 실시간 서비스가 끊김 없이 제공될 수 있도록 접속 단계에서 품질 관리 수행

Distribution Switch

Distribution Switch는 Access Layer와 Core Layer 사이의 중간 계층 스위치로, 여러 Access Switch로부터 들어오는 트래픽을 집계하고 상위 계층으로 전달하는 역할을 함 네트워크 계층 구조에서 L3 스위칭과 정책 처리를 담당하여, VLAN 간 라우팅, 접근 제어, 트래픽 필터링 등 상위 계층 기능을 수행함

네트워크 전체의 정책 적용과 안정성을 책임지는 핵심 계층

기능

• L3 스위칭/라우팅 : VLAN간 트래픽을 라우팅하고, IP 기반 트래픽 전달 최적화함

• 정책 기반 제어 : ACL, QoS, 보안 정책 등을 적용하여 트래픽 흐름을 관리하고 우선순위를 설정함

• 트래픽 집계 : 여러 Access Switch에서 올라오는 데이터를 집계하여 Core Layer로 전달 함

• 중복 경로 지원 : STP, RSTP, MSTP 등 스패닝 트리 프로토콜을 통해 루프를 방지하고 고가용성을 확보함

• 로드 밸런싱 : 다수의 링크를 효율적으로 사용하여 트래픽 혼잡을 최소화함

역할

• Access Layer 집계 : 여러 Access Switch에서 발생하는 트래픽을 모아 상위 Backbone Switch로 전달함

• 정책 적용 허브 : 네트워크 보안과 트래픽 우선순위를 설정하는 중앙 지점으로서, VLAN 간라우팅과 ACL 적용을 수행함

• 장애 격리 : 문제 발생 시 영향을 최소화하고 Access Layer 단위로 트래픽을 분리함

• 고가용성 확보 : 이중화, 다중 경로, 링크 집계 등으로 네트워크 다운타임을 최소화함

존재 이유

효율적 트래픽 관리 : 수 많은 Access Switch에서 발생하는 트래픽을 효율적으로 집계·전달하여 Core Layer의 부하를 최소화

정책 중심 제어 : 보안, QoS, VLAN 간 라우팅 등 상위 계층 정책을 효과적으로 적용하기 위한 필수 계층

확장성과 안정성 보장 : 네트워크 규모 확장 시 Access Layer를 추가하더라도 중앙에서 트래픽과 정책을 일괄 관리 가능

운영 효율성 : 트래픽 흐름과 장애 처리, 네트워크 최적화 기능을 집중시켜 관리 복잡성을 줄임

Backbone(Core) Switch

Backbone Switch는 네트워크 계층 구조에서 최상위(Core) 계층에 위치하며, Distribution Layer에서 집계된 트래픽을 빠르고 안정적으로 전달하는 장치 기업, 캠퍼스, 데이터센터 등 대규모 네트워크에서 핵심 경로(Core Path)역할을 수행하고, 고속 L3 스위칭과 라우팅 기능을 통해 전체 네트워크 성능과 안정성을 좌우 함

네트워크 전체 트래픽을 고속으로 전달하고 정책을 통합 관리하는 핵심 경로 장치

기능

• 고속 L3 스위칭 : VLAN 간, 서브넷 간 트래픽을 초고속으로 처리하여 최적화함

• 라우팅 집계 : 여러 Distribution Switch에서 올라오는 트래픽을 통합하고 최적 경로로 전달함

• 고가용성/중복 경로 지원 : 다중 경로, 이중화, 링크 집계(LACP) 등으로 장애 발생 시에도 트래픽을 유지함

• 정책 전달 허브 : QoS, ACL, 보안 정책 등의 설정을 상위 계층에 적용하고 전체 네트워크로 확산함

• 대용량 처리 : 수백~수천 기가비트 트래픽을 동시에 처리할 수 있는 대규모 포트와 스위칭 용량을 제공함

역할

• 트래픽 허브 : Distribution Layer에서 집계된 트래픽을 Core/Backbone 경로로 전달함

• 네트워크 중심 경로 확보 : 전체 네트워크의 데이터 흐름을 조율하고 병목 발생을 최소화함

• 상위 정책 적용 : 네트워크 전반의 보안, QoS, 라우팅 정책을 일괄 적용하고 배포함

• 장애 격리 및 복구 : 핵심 경로에서 장애 발생 시 백업 경로로 트래픽을 우회시키며 안정성을 유지함

• 확장성 제공 : 기업·캠퍼스 규모 확장 시 추가 Distribution Layer와 Access Layer를 무리 없이 연결 가능

존재 이유

전체 네트워크 성능 보장 : 대규모 트래픽을 안정적·고속으로 처리하여 네트워크 병목과 지연을 최소화함

정책·보안 집중 관리 : 네트워크 전반 정책과 보안 규칙 적용의 중앙 허브 역할을 함

확장성 및 유연성 확보 : 네트워크 구조 확장 시 단말·서비스 증가에도 일관된 성능과 안정성을 유지함

운영 효율화 : 트래픽 흐름, 장애 관리, 라우팅 최적화를 중앙에서 통합 관리 가능

: Content Disarm and Reconstruction

CDR은 모든 입력 파일과 데이터 스트림을 구성 요소 단위로 분해하고, 안전 기준을 만족하지 않는 요소를 제거한 뒤 원본과 유사한 형태로 재구성하며, 모든 파일을 잠재적 위협으로 간주하는 Zero Trust 원칙을 적용하는 기술

• 악성콘텐츠 제거: Disarm
• 안전한 요소 재구성: Reconstruction

CDR의 3가지 Type

CDR도 시간이 지남에 따라 기능이 발전함

Type 1: 파일 평면화 (Flattening / Disarm)

악성 파일 비활성화를 위해 모든 내용 평면화

• PPT 비유: 슬라이드를 그림으로 저장 → 편집, 애니메이션, 링크 등 모든 기능 불가
• CDR 적용 결과: 안전하지만 작동하지 않는 PDF 생성

특징

• 모든 파일 PDF 변환
• 악성 코드 활성화 가능성 제거
• 합법적 매크로, 추적 변경 사항, 레이어 손실
• 사용성 저하 → 조직 생산성 저하 가능

Type 2: 활성 콘텐츠 제거 (Active Content Removal / Sanitization)

원본 형식 유지, 악성 코드 및 활성 콘텐츠만 제거

• PPT 비유: 슬라이드 구조 유지 → 애니메이션, 링크 일부 손실 / 글과 그림 유지
• CDR 적용 결과: 일부 기능 손실, 안전하지 않은 콘텐츠 제거

특징

• 문서 기능 일부 유지, 활성 콘텐츠 제거
• 필수 매크로, 링크, 비즈니스 로직 손실
• 보안 강화, 기본 템플릿 취약점 존재

Type 3: Positive Selection Technology ⭐

파일 유용성 유지, 악성 코드만 제거

• PPT 비유: 안전한 요소만 선별 재구성 → 대부분 기능 그대로 사용 가능
• CDR 적용 결과: 모든 기능 유지, 안전한 템플릿 기반 복사본 생성

특징

• 템플릿 기반 재구성
• 정상 콘텐츠만 복사, 위험 요소 제거
• 원본 기능 완전히 보존

Menlo의 CDR(Votiro)은 Type 3에 해당함

Votiro의 CDR 특징

• Positive Selection Technology: 원본 구조 유지, 안전한 요소만 복사·재구성

• 탐지 기반 파일 솔루션과 달리 각 파일의 안전한 요소만 골라 100% 안전 보장

CDR 유형별 비교

Positive Selection 작동 원리

1단계: Identity the File Format (파일 형식 식별)

이 단계에서는 파일이 어떤 형식이고, 내부 구조가 어떻게 되어 있는지 정확히 알아내는 과정

파일 형식 중요성

• 모든 파일은 고유 규칙과 사양 따름
  _(각 파일 형식은 고유 구조와 데이터 배치 방식, 메타데이터 규칙이 있음)_
• 고유의 구조 벗어나면 프로그램이 파일을 정상적으로 읽지 못하거나 보안 위험이 발생할 수 있음

Positive Selection 기술에서의 처리 방식

• 지능형 지문(Fingerprinting) 방식 사용

• 파일 내부 구조, 데이터 블록 순서, 메타데이터, 포함된 객체 등의 특징을 분석 → 파일 형식과 콘텐츠 유형을 정확히 식별

• 단순 확장자 확인 아닌 파일의 실제 내용과 구조를 확인하여 안전하게 처리할 수 있는 기반을 마련

2단계: Generate a New Version of the File (새 파일 생성)

이 단계에서는 "악성 요소는 제거하고 안전한 요소는 유지하는" 단계로 파일을 재작성하면서 안전성을 확보함

원본 파일에는 사용자에게 필요한 정상 콘텐츠 뿐만 아니라 악성 매크로나 스크립트, 숨겨진 공격 코드가 포함될 수 있으므로 파일을 그대로도 사용하는 것은 매우 위험함

• 과정
  1. 깨끗한 템플릿 생성 파일 공급 업체에서 제공하는 "안전한 원본 템플릿"을 기반으로 새 파일을 만듦
     • ex: Word → 빈 문서, Excel → 표준 워크북
       
  2. 원본에서 안전한 내용만 가져오기 원본 파일에서 정상적인 내용(텍스트, 이미지, 차트)만 새 파일로 복사
     • 악성 매크로, 스크립트, OLE 객체 등 공격 가능 요소는 제외
       
  3. 활성 요소 재생성 필요한 매크로나 스크립트, OLE 객체 등은 안전하게 재구성하고 사용가능한 상태로 새 파이렝 포함
     • 기존 악용 가능성을 제거
       
  4. 사용자 경험 유지 파일의 형식, 레이아웃, 기능은 원본과 동일하게 유지
     • 새 파일 생성 과정은 1초 미만, 사용자에게 보이지 않음

3단계: Use the New File (새 파일 사용)

최종적으로 안전하고 기능이 유지된 새 파일을 사용자에게 제공함

결과

• 모든 악성 코드와 공격 위협 제거
• 안전한 요소 새 파일로 안전 이전
• 원본과 동일한 기능과 형식 유지

사용 가능 상태

• 저장, 편집, 공유, 활용 모두 안전
• 파일 보안과 사용자 경험 모두 확보

Positive Selection 특징

취약점 보호

Positive Selection 기술은 소프트웨어 취약점의 전체 수명 주기 알려지지 않은 취약점 → 제로데이 → 패치 단계에서 발생할 수 있는 파일 기반 취약점 공격을 차단함

1단계 알려지지 않은 취약점 (Undisclosed)

공급 업체나 보안 커뮤니티가 알지 못하는 취약점도 공격자가 악용할 수 있음 Positive Selection은 허용된 안전한 요소만 파일에서 추출 및 재구성 하므로, 취약점의 존재 여부와 상관없이 악성 코드 실행을 차단함

2단계 제로데이 (Zero-Day)

취약점이 발견되고난 후 패치가 존재하지 않고 시그니처 기반 탐지로도 막기 어려운 시점으로 Positive Selection은 탐지에 의존하지 않고 "허용된 무해 요소만 통과" 시키는 방식이므로 제로데이 취약점을 효과적으로 차단함

3단계 패치 (Patched)

패치가 배포되었어도, 미적용 환경에서는 여전히 공격이 가능함 Positive Selection은 최신 패치 적용 여부와 무관하게 파일 재구성 과정을 거치므로, 패치 관리 공백에서 발생하는 위험도 줄여줌

결론적으로 Positive Selection은 취약점이 공개되었는지 여부나 패치 상태와 무관하게, 파일 기반 익스플로잇 공격으로부터 조직을 보호하는 기술

지원 파일 형식

Positive Selection은 문서, 아카이브, 이메일, 오피스, 이미지 등 다양한 파일 형식을 안전하게 처리함

• 암호로 보호된 파일 : 비밀번호가 걸린 파일도 기술적인 도움 없이 안전하게 정리 할 수 있음

• 압축 파일 : ZIP, RAR, 7Z, CAB 등 아카이브와 내부 파일 모두 재귀적으로 분석 후 안전하게 재압축

• 문서 파일 : PDF, RTF, 텍스트 등 문서를 개별 요소로 분해하여 신뢰할 수 있는 요소만 전달

• 이메일 컨테이너 : EML, MSG, PST 지원, 이메일 서버와 연동하여 첨부파일 안전 전달

• Microsoft Office 파일 : Word, Excel, PowerPoint 등 포함 객체(OLE, 이미지 등)까지 세부 요소 분석 후 안전 전달

• 이미지 파일 : JPEG, GIF, BMP, PNG, TIFF, EMF, WMF 등 래스터·벡터 이미지에서 악성 콘텐츠 제거

장점 및 이점

단순히 파일을 안전하게 만드는 것을 넘어, 조직 전체의 보안과 업무 효율성을 동이세 개선할 수 있음

• 모든 공격 경로 차단 : 다양한 소스와 방법으로 들어오는 악성 파일과 멀웨어 및 제로데이 위협을 막음
• 업무 흐름 유지 : 백그라운드에서 자동으로 실행되어, 직원들이 파일을 여는 데 지장을 주지 않음
• 사람 의존 최소화 : 보안 규정 준수나 IT 지원에 의존하지 않고 자동으로 안전하게 처리함
• 파일 그대로 전달 : 원본 파일의 기능과 내용을 그대로 유지하면서 위험만 제거함
• 빠른 통합과 실행 : SaaS는 10분, On-prem은 1시간 미만으로 설치 가능, 별도의 교육도 필요 없음
• 자동화와 편의성 : 파일 차단·격리 과정 없이 안전하게 바로 전달하여 보안 팀의 수동 작업 부담이 감소함
• 유연한 정책 적용 : 덜 제한적인 인터넷 환경에서도 안전하게 콘텐츠 접근이 가능함