메일 화면에는 From: cookie01@example.com 처럼 보낸 사람이 표시되지만, 이 값은 메일 본문 헤더에 포함되는 문자열에 가까움 즉, SMTP 자체만 놓고 보면 사용자가 보는 발신자 주소가 실제 그 도메인의 권한있는 발신자인지 보장하기 어려움

그래서 Email 보안에서는 단순히 메일이 도착했는지가 아니라, 다음 질문을 확인해야 함

이 메일은 정말 해당 도메인을 사용할 권한이 있는 발신 경로에서 온 것인가?

이 질문에 대응하기 위한 대표적인 인증 기술이 SPF, DKIM, DMARC임

SPF는 발송 서버의 권한을 확인하고 DKIM은 메일에 포함된 서명을 검증하며, DMRAC는 사용자가 보는 From 도메인을 기준으로 SPF/DKIM 결과를 정책과 연결함

이 글에서 다룰 내용

이 글에서는 Email 인증 구조를 SPF, DKIM, DMARC 중심으로 정리함

단순히 각 기술의 정의를 나열하는 것이 아닌, Email 전달 구조에서 왜 인증이 필요한지, 각 인증 기술이 무엇을 검증하는지, 그리고 인증 결과를 보안 관점에서 어떻게 해석해야 하는지 설명함

주요 내용은 다음과 같음:

• Email에서 발신자 위조가 가능한 이유

• SMTP Envelope와 Header From의 차이
• SPF의 발송 서버 권한 검증 구조
• DKIM의 서명 기반 검증 구조
• DMARC의 From 도메인 기준 정책 검증 구조
• SPF, DKIM, DMARC의 관계와 한계
• 인증 성공이 곧 안전한 메일을 의미하지 않는 이유

학습 목표

이 글을 읽고 나면 다음 내용을 이해할 수 있음

• Email 인증이 필요한 이유를 설명할 수 있음
• SFP, DKIM, DMARC가 각각 무엇을 검증하는지 구분할 수 있음
• SPF와 DKIM이 단독으로는 부족한 이유를 이해할 수 있음
• DMARC Alignment의 의미를 이해할 수 있음
• 메일 인증 결과를 보안 탐지 결과와 구분해서 해석할 수 있음

⁎ Email 인증의 기본 개념

⁑ Email 인증이 필요한 이유

Email은 오래된 인터넷 프로토콜 구조 위에서 동작함.

SMTP는 기본적으로 메일을 전달하기 위한 프로토콜이지, 강력한 신원 검증을 전제로 설계된 보안 프로토콜은 아님 메일 서버는 상대 서버와 SMTP 세션을 맺고, 발신자와 수신자 정보를 주고받은 뒤, 메일 데이터를 전달함

문제는 이 과정에서 "보낸 사람 주소" 처럼 보이는 값이 여러 계층에 나뉘어 존재한다는 점임

예를 들어 하나의 메일에는 다음과 같은 발시자 관련 값이 존재할 수 있음

SMTP MAIL FROM: bounce@example.com
Header From: security@example.com
DKIM d=example.com
Return-Path:  bounce@example.com

사용자가 메일 클라이언트에서 주로 보는 값은 Header From임 반면 SMTP 서버가 전송 과정에서 사용하는 값은 MAIL FROM, HELO/EHLO, Return-Path 같은 값임

이 값들이 항상 같다고 볼 수 없음.

공격자는 사용자가 보는 Header From 을 신뢰할 만한 조직처럼 꾸밀 수 있기 때문에 수신 측에서는 단순히 From 문자열만 보는 것이 아니라, DNS에 게시된 인증 정보를 기반으로 해당 도메인이 허용한 발송 경로인지 확인해야 함

$$ Email \ 인증은 \ 이 \ 문제를 \ 해결하기 \ 위한 \ 구조 $$

⁑ Email에서 말하는 “인증”의 의미

Email에서 말하는 인증은

특정 도메인을 사용한 메일이 그 도메인 소유자가 허용한 방식으로 발송되었는지 확인하는 과정

즉, Email 인증은 도메인 사용 권한을 검증하는 구조

여기서 중요한 기준은 "도메인" SPF, DKIM, DMARC는 모두 개인 사용자 한 명의 실제 신원을 증명하는 기술이 아니라, 특정 도메인이 메일 발송에 어떻게 사용되었는지를 확인하는 기술임

따라서 다음 사항을 구분할 수 있어야 함

• 인증 성공 = 해당 도메인을 사용할 권한이 있는 경로로 발송되었을 가능성이 높음
• 안전한 메일 = 악성 URL, 악성 첨부파일, 피싱 의도, 계정 탈취 정황 등이 없음

두 개념은 서로 다른 개념임

정상 도메인의 계정이 탈취되어 발송된 메일은 SPF, DKIM, DMARC를 올바르게 설정해도 인증은 통과할 수 있음

따라서 Email 인증은 보안의 출발점이지, 최종 판단 기준은 아님

⁎ SPF: 발송 서버 권한 검증

⁑ SPF 개요

SPF: Sender Policy Framework

이 IP 주소의 메일 서버가 이 도메인을 사용해서 메일을 보낼 권한이 있는가?

도메인 소유자는 DNS TXT 레코드에 자신의 도메인으로 메일을 보낼 수 있는 서버 정보를 게시함 수신 메일 서버는 메일을 받은 뒤, 발송 서버의 IP 주소가 해당 도메인의 SPF 레코드에 포함되어 있는지 확인함

⁂ SPF가 확인하는 대상

SPF는 주로 SMTP Envelope 영역을 확인함

_* SMTP Envelope : 메일 서버가 실제 배달을 위해 사용하는 전송용 정보. 사용자가 보는 Header From과 별개로, MTA 간 SMTP 통신에서 발신자와 수신자를 판단하는 데 사용_

대표적으로 다음 값이 관련됨

• SMTP MAIL FROM
• HELO / EHLO
• Return-Path

SPF는 기본적으로 이 Envelope 기반 도메인을 보고 발송 서버 권한을 확인함. 따라서 SPF만으로는 사용자가 보는 From 도메인이 진짜인지 충분히 확인하기는 어려움

⁂ SPF 동작 흐름

1. 외부 메일 서버가 수신 서버로 메일 전송
2. 수신 서버가 연결된 발송 서버 IP 확인
3. SMTP MAIL FROM 또는 HELO 도메인 확인
4. 해당 도메인의 SPF TXT 레코드 DNS 조회
5. SPF 레코드에 발송 서버 IP가 포함되어 있는지 확인
6. 결과에 따라 pass, fail, softfail, neutral 등으로 판단

⁂ SPF 레코드 예시

SPF 레코드는 DNS TXT 레코드로 게시됨

Example

example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"

• 의미

  • v=spf1 : SPF 버전 표시

  • ip4:203.0.113.0 : 203.0.113.10 IP는 example.com 도메인으로 메일 발송 가능

  • include:_spf.example.net : _spf.example.net에 정의된 발송 서버도 허용

  • -all : 위 조건에 맞지 않으면 실패로 판단

SPF 결과 해석

결 과	의 미
pass	발송 서버가 SPF 정책에 부합함
fail	발송 서버가 SPF 정책에 부합하지 않음
softfail	부합하지 않지만 강한 차단보다는 의심 수준으로 처리
neutral	도메인 소유자가 명확한 판단을 제공하지 않음
temperror	일시적인 DNS 오류 등으로 검증 실패
permerror	SPF 레코드 문법 오류 등 영구 오류

⁂ SPF의 한계

SPF는 발송 서버 권한을 확인하는데 유용하지만 한계가 있음

첫째, 사용자가 보는 Header From을 직접 검증하지 않음 SPF가 pass여도 메일 화면에 보이는 From 도메인이 SPF 검증 도메인과 다를 수 있음

둘째, 메일 포워딩 환경에서 실패할 수 있음 메일이 중간 서버를 거쳐 전달되면 최종 수신 서버 입장에서는 원래 발송 서버가 아니라 포워딩 서버의 IP를 보게되기 때문에 원래 도메인의 SPF 레코드에 포워딩 서버 IP가 없으면 SPF fail이 발생할 수 있음

셋째, SPF 레코드를 너무 넓게 설정하면 실효성이 떨어짐 예를 들어 너무 많은 외부 서비스를 include 하거나 +all 처럼 모든 발송자를 허용하는 정책을 사용하면 SPF는 사실상 보소 기능을 하지 못함

넷째, DNS 조회 제한 문제가 있음 SPF는 include, a, mx 등의 메커니즘을 처리하면서 DNS 조회를 수행하는데, 조회가 과도하게 많아지면 permerror가 발생할 수 있음

⁎ DKIM: 메일 내용과 서명 검증

⁑ DKIM 개요

DKIM: DomainKeys Identified Mail 이 메일은 특정 도메인이 서명한 메일이며, 서명된 이후 주요 내용이 변경되지 않았는가?

SPF가 발송 서버 IP를 확인한다면, DKIM은 메일에 포함된 디지털 서명을 검증함

DKIM는 공개 키 기반 구조를 사용함

발송 측은 메일을 보낼 때 개인키로 메일에 서명하고, 수신 측은 DNS에 게시된 공개키를 조회해서 서명을 검증함

⁂ DKIM이 확인하는 대상

DKIM은 메일의 특정 Header와 Body를 대상으로 서명을 생성함

발송 서버는 메일을 보낼 때 DKIM-Signature 헤더를 추가함 이 헤더에는 서명 도메인, 셀렉터, 서명 알고리즘, 서명 대상 헤더 목록, 본문 해시, 실제 서명값 등이 포함됨

Example

DKIM-Signature:
  v=1;
  a=rsa-sha256'
  d=example.com;
  s=selector1;
  h=from:to:subject:date;
  bh=...;
  b=...

주요 값은 다음과 같음

⁂ DKIM 동작 흐름

1. 발송 도메인이 DKIM 키 쌍 생성
2. 공개키는 DNS TXT 레코드에 게시
3. 개인키는 발송 메일 서버에 보관
4. 메일 발송 시 개인키로 메일 Header/Body 일부에 서명
5. 수신 서버가 DKIM-Signature 헤더 확인
6. d= 도메인과 s= 셀렉터를 이용해 DNS에서 공개키 조회
7. 공개키로 서명 검증
8. 서명이 유효하면 d= 도메인 기준 pass

DKIM은 발송 서버 IP에만 의존하지않음.

SPF는 발송 서버 IP를 기준으로 검증하기 때문에 포워딩 환경에서 실패할 수 있음. 반면 DKIM은 메일 자체에 서명이 포함되어있기 때문에 중간에 메일이 다른 서버를 거쳐 전달되더라도, 서명된 Header와 Body가 크게 변경되지 않으면 DKIM 검증은 유지될 수 있음

또한 DKIM은 메일이 발송된 이후 주요 내용이 변경되었는지(무결성) 확인하는 데 도움을 줌. 메일 본문이나 서명 대상 헤더가 변조되면 서명 검증에 실패할 수 있음

⁂ DKIM-Signature와 공개키 조회

DKIM에서 가장 중요한 값은 d=와 s=임

// 서명한 도메인
d=example.com

// 공개키를 찾기 위한 셀렉터
s=selector1

수신 서버는 이 값을 조합해서 DNS에 공개키를 조회함

selector1._domainkey.example.com

해당 DNS TXT 레코드에 공개키가 게시되어 있고, 이 공개키로 서명을 검증할 수 있으면 DKIM 검증이 통과함.

즉 DKIM는 메일 안의 서명값만 보는 것이 아니라, DNS에 게시된 공개키와 메일에 포함된 서명을 함께 비교하는 방식임

⁂ DKIM의 한계

DKIM도 단독으로는 충분하지 않음

첫째, 사용자가 보는 From 도메인이 반드시 해당 도메인은 아님 DKIM은 서명 도메인이 메일을 책임을 가진다는 의미임 예를 들어 d=mailer.example.net 으로 DKIM을 통과했더라도, 사용자가 보는 From이 example.com 일 수 있음

둘째, 공격자가 자신이 소유한 도메인으로 DKIM을 정상 설정하면 DKIM은 pass될 수 있음 DKIM pass는 "서명 검증 성공"으로 "안전한 발신자"를 의미하지 않음

셋째, 메일링 리스트나 일부 보안 솔루션이 메일 본문이나 헤더를 수정하면 DKIM 서명이 깨질 수 있음 예를 들어 제목에 태그를 추가하거나, 본문 하단에 안내 문구를 삽입하거나, 첨부파일 처리 과정에서 구조가 바뀌면 DKIM fail이 발생할 수 있음

넷째, 발송 도메인이 개인키가 유출되면 공격자가 정상 DKIM 서명을 생성할 수 있음 따라서 DKIM 키 관리의 주기적인 키 교체도 중요함

⁎ DMARC: From 도메인 기준 정책 검증

⁑ DMARC 개요

DMARC: Domain-based Message Authentication, Reporting, and Conformance SPF 또는 DKIM이 통과했는가? 그리고 통과한 인증 도메인이 사용자가 보는 From 도메인과 일치하거나 같은 조직 도메인인가? 실패했다면 도메인 소유자가 요청한 정책은 무엇인가?

SPF와 DKIM은 각각 유용하지만, 단독으로는 사용자가 보는 Header From 도메인을 충분히 보호하기 어려움

SPF는 Envelope 도메인을, DKIM은 서명 도메인을 검증하지만 사용자가 실제로 보는 것은 Header From 도메인임

DMARC은 이 간극을 연결함. SPF와 DKIM을 기반으로 하되, 최종 기준을 Header From 도메인에 맞추는 정책 구조임

⁂ DMARC가 필요한 이유

Header From: security@example.com
MAIL FROM: bounce@sender.example.net
DKIM d=sender.example.net

위와 같은 메일일때 SPF가 sender.example.net 기준으로 pass될 수 있으며, DKIM도 sender.example.net 기준으로 pass 될 수 있지만 사용자가 보는 From은 example.com임

그렇다면 sender.example.net의 인증 성공을 example.com의 인증 성공으로 볼 수 있는가?

DMARC는 이 문제를 Alignment로 판단함

⁂ SPF/DKIM Alignment

Alignment는 SPFG 또는 DKIM에서 인증된 도메인이 Header From 도메인과 정렬되어 있는지 확인하는 개념

DMARC에서 중요한 도메인

1. Heacer From domain: 사용자가 보는 From 도메인
2. SPF domain: SMTP MAIL FROM 기반 SPF 검증 도메인
3. DKIM d= domain: DKIM 서명 도메인

DMARC가 pass 되려면 다음 조건 중 하나가 만족되어야 함

SPF pass + SPF domain이 Header From domain과 Alignment

    OR

DKIM pass + DKIM d= domain이 Header From doamin과 Alignment

둘중 하나만 만족해도 DMARC는 pass 될 수 있음

DMARC Alignment의 주요 조건 두가지

• Relaxed Alignment : 조직 도메인이 같으면 정렬된 것으로 판단

• Strict Alignment : 도메인이 정확히 동일해야 정렬된 것으로 판단

Example

From: user@example.com
d=mail.example.com

• Relaxed Alignment pass = example.com이라는 조직 도메인이 같기 때문

⁂ DMARC 정책

도메인 소쥬자는 DNS에 DMARC 정책을 게시할 수 있음

DMARC 레코드는 일반적으로 다음 위치에 TXT 레코드로 게시됨

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.com

주요 값은 다음과 같음

• 핵심 정책 값

  • p=none : 인증 결과를 모니터링하지만 별도 처리 요청은 하지 않음

  • p=quarantine : DMARC 실패 메일을 스팸함 등으로 격리하도록 요청

  • p=reject : DMARC 실패 메일을 거부하도록 요청
    _다만 DMARC 정책은 도메인 소유자의 요청 정책에 가까움 최종적으로 메일을 어떻게 처리할지는 수신 측 메일 시스템의 정책에 따라 달라질 수 있음
    예를 들어 도메인 소유자가 p=reject를 게시했더라도, 수신 측은 자체 정책과 평판, 예외 조건, 사용자 설정 등을 함께 고려할 수 있음._

• DMARC 보고서

  • rua 태그를 사용하면 수신 측 메일 시스템이 Aggregate Report를 보낼 수 있음 이 보고서는 특정 도메인을 사용한 메일이 어느 IP에서 발송되었는지, SPF/DKIM/DMARC 결과가 어땠는지 확인하는데 사용됨

• ex: rua=mailto:dmarc-report@example.com*
  
  

  • 확인 가능 사항
    • 정상 발송 시스템이 SPF/DKIM/DMARC를 통과하는지
    • 외부 SaaS 발송 시스템이 누락되어 있는지
    • 알 수 없는 IP에서 도메인을 사칭하고 있는지
    • DMARC 정책을 none에서 quarantine, reject로 강화해도 되는지

⁂ DMARC의 한계

DMARC는 SPF와 DKIM의 한계를 보완하지만, 모든 메일 위협을 막는 기술은 아님

첫째, DMARC는 도메인 사용 권한을 검증함 메일 본문의 URL이 악성인지, 첨부파일이 위험한지, 문장이 피싱인지까지 판단하는 기술은 아님

둘째, 정상 도메인의 계정이 탈취된 경우 DMARC가 통과할 수 있음 공격자가 실제 조직 계정으로 메일을 발송하면 SPF, DKIM, DMARC가 모두 정상일 수 있음

셋째, 공격자가 유사 도메인을 등록해 SPF, DKIM, DMARC를 정상 설정할 수 있음 예를 들어 example.com이 아니라 examp1e.com 같은 도메인을 사용하면 인증은 통과할 수 있음

넷째, Display Name 공격은 별도 문제 예를 들어 From 표시 이름을 Microsoft Support 처럼 설정하고, 실제 수조는 전혀 다른 도메인을 사용하는 방식

From: Microsoft Support <notice@attacker-domain.com>

이 경우 공격자 도메인에 대한 인증은 정상일 수 있으나 사용자는 표시 이름만 보고 신뢰할 수 있음

따라서 DMARC는 강력한 도메인 인증 정책이지만, 피싱·악성 URL·첨부파일·계정 탈취 탐지와 함께 사용해야함

⁎ Email 인증 결과의 해석

⁑ SPF, DKIM, DMARC 비교

SPF, DKIM, DMARC는 서로 대체 관계가 아닌 보완 관계

세 기술의 관계를 한 문장으로 정리하면 다음과 같음

• SPF는 어디서 보냈는지 확인하고,
• DKIM은 누가 서명했는지 확인하며,
• DMARC는 그 결과가 사용자가 보는 From 도메인과 맞는지 확인함

⁑ 인증 결과를 어떻게 해석해야 하는가

수신 메일 서버나 보안 게이트웨이는 SPF, DKIM, DMARC 검증 결과를 메일 헤더에 기록할 수 있음.

대표적으로 Authentication-Results 헤더가 사용됨.

Example

Authentication-Results: mx.example.com;
 spf=pass smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

이 결과는 다음처럼 해석할 수 있음.

//SPF 검증 통과
spf=pass

//SPF 검증에 사용된 MAIL FROM 도메인
smtp.mailfrom=example.com

//DKIM 서명 검증 통과
dkim=pass

//DKIM 서명 도메인
header.d=example.com

//DMARC 검증 통과
dmarc=pass

//DMARC 기준이 된 Header From 도메인
header.from=example.com

보안 분석 시에는 단순히 spf=pass, dkim=pass, dmarc=pass만 볼 것이 아니라, 어떤 도메인을 기준으로 pass되었는지 확인해야 함.

특히 다음을 구분해야 함.

• SPF가 pass된 도메인
• DKIM이 pass된 도메인
• 사용자가 보는 Header From 도메인
• DMARC Alignment 결과

이 네 가지가 맞물려야 발신 도메인 인증 결과를 제대로 해석할 수 있음.

⁑ 운영 관점에서의 점검 포인트

Email 인증은 단순히 DNS 레코드 하나를 추가하는 것으로 끝나지 않음. 실제 운영 환경에서는 메일을 발송하는 시스템이 여러 개일 수 있음.

예를 들어 다음과 같은 발송원이 존재할 수 있음

• 사내 Mail Server
• Cloud Mail
• Marketing SaaS
• CRM
• 고객지원 시스템
• 알림 발송 시스템
• 그룹웨어
• 보안 솔루션
• 외부 위탁 발송 서비스

이 발송원들이 SPF, DKIM, DMARC 구조에 제대로 반영되어야 함

1. 발송원 목록 식별

가장 먼저 해야 할 일은 우리 도메인으로 메일을 보내는 시스템을 식별하는 것임. 정상 발송원을 모르고 DMARC 정책을 강하게 적용하면 정상 메일이 차단될 수 있음.

따라서 다음을 먼저 정리해야 함.

• 어떤 시스템이 우리 도메인으로 메일을 보내는가?
• 어떤 IP 또는 서비스가 사용되는가?
• SPF include가 필요한가?
• DKIM 서명은 어느 도메인으로 되는가?
• Header From 도메인과 Alignment가 맞는가?

2. SPF 레코드 과도 확장 방지

SPF 레코드에 include를 계속 추가하면 구조가 복잡해지기 때문에 필요한 발송원만 허용해야 함 불필요한 include가 많아지면 허용 범위가 넓어지고, DNS 조회 제한 문제도 발생할 수 있음.

피해야 할 설정 예시: v=spf1 +all

이 설정은 사실상 모든 발송자를 허용하는 의미이므로 보호 효과가 없음.

3. DKIM 키 관리

DKIM은 개인키가 중요함. 개인키가 유출되면 공격자가 정상 DKIM 서명을 생성할 수 있기 때문에 DKIM 키는 안전하게 보관하고, 필요 시 주기적으로 교체해야 함.

또한 여러 발송 시스템을 사용하는 경우 각 시스템의 DKIM 서명 도메인과 selector를 관리해야 함

4. DMARC는 단계적으로 강화

DMARC는 일반적으로 다음 흐름으로 적용하는 것이 안정적임

p=none
모니터링

↓ 보고서 분석

p=quarantine
의심 메일 격리 요청

↓ 정상 발송원 정리

p=reject
실패 메일 거부 요청

처음부터 p=reject를 적용하면 정상 발송 시스템 중 일부가 인증 구조에 반영되지 않았을 때 업무 메일이 차단될 수 있음

따라서 DMARC 보고서를 기반으로 정상 발송원을 정리한 뒤 정책을 강화하는 방식이 적절함.

5. 인증 결과와 보안 정책 연결

SPF, DKIM, DMARC 결과는 보안 정책의 중요한 입력값이지만 인증 결과만으로 최종 허용/차단을 결정하기보다는 다른 보안 신호와 함께 판단해야 함

*예시 조합: *

• DMARC fail + 신규 도메인 + 의심 URL → 차단 또는 격리

• DMARC pass + 정상 도메인 + 악성 첨부 탐지 → 차단

• DMARC pass + 정상 거래처 + 평소와 다른 송금 요청 → 추가 검증 또는 경고

• SPF fail + DKIM pass + DMARC pass → 포워딩 또는 중간 경로 가능성 검토

즉, 인증 결과는 중요한 신뢰 신호지만, 단독 판단 기준은 아님.

⁎ 정리

Email 인증은 메일이 실제로 해당 도메인을 사용할 권한이 있는 방식으로 발송되었는지 확인하기 위한 구조

SPF, DKIM, DMARC의 역할

• SPF: 발송 서버 IP가 허용된 서버인지 확인
• DKIM: 메일에 포함된 도메인 서명과 무결성 확인
• DMARC: SPF/DKIM 결과가 사용자가 보는 From 도메인과 정렬되는지 확인하고 정책 적용

SPF는 발송 서버 권한을 확인하지만 Header From을 직접 검증하지 않음. DKIM은 메일 서명을 검증하지만 서명 도메인과 사용자가 보는 From 도메인이 다를 수 있음. DMARC는 이 둘을 From 도메인 기준으로 연결해 도메인 사칭 방어를 강화함.

다만 인증 성공이 곧 안전한 메일을 의미하지는 않음

정상 계정이 탈취될 수 있고, 공격자도 자신이 소유한 도메인에 SPF, DKIM, DMARC를 정상 설정할 수 있음. 또한 악성 URL, 첨부파일, 사회공학적 문구는 인증 기술만으로 판단할 수 없음.

따라서 Email 보안에서는 인증을 다음처럼 이해해야 함.

• Email 인증 = 도메인 사용 권한 검증

• Email 보안 = 인증 결과 + 콘텐츠 분석 + 평판 + 행위 분석 + 정책 판단

이 글에서 다룰 내용

Email 인프라를 구성하는 주요 요소와 실제 배치 구조를 정리하고, [PART 1]에서 MUA · MSA · MTA · MDA의 논리적 역할을 기반으로, 실제 운영 환경에서 MTA · MDA · Gateway가 어떻게 배치되고 Inbound / Outbound 메일 흐름에서 각각 어떤 책임을 가지는지 설명함.

즉, 단순히 “메일이 전송된다”는 흐름이 아니라, Client, Mail Server, Gateway, Mailbox 같은 구성 요소들이 어떤 위치에서 어떤 책임을 가지는지 정리하는 글

학습 목표

• Email 인프라를 구성하는 주요 요소 이해

• MTA, MDA, Gateway의 역할과 배치 구조 구분
• Inbound / Outbound 메일 흐름에서 각 구성요소의 위치 파악
• Email Security가 인프라 구조 안에서 개입되는 위치 이해

⁎ Email 인프라 개요

Email 전송은 여러 역할이 협력하여 동작하지만, 실제 운영 환경에서는 이러한 역할이 다양한 형태로 배치됨.

PART 1에서 Email의 논리 구조(MUA, MSA, MTA, MDA)를 살펴봤다면, 이번 파트에서는 실제 운영 환경에서 메일 시스템이 어떤 형태로 구성되는지 살펴봄.

조직 규모와 운영 방식에 따라 단일 Mail Server를 사용할 수도 있고, Gateway를 포함한 구조나 Cloud Mail 구조를 사용할 수도 있음.

Email 인프라는 단순히 메일 서버 하나를 의미하지 않음. 메일을 보내는 사용자 영역, 메일을 전달하는 서버 영역, 메일을 저장하는 Mailbox 영역, 외부 메일을 검사하는 보안 영역이 함께 구성된 구조임

따라서 Email 인프라를 볼 때는 "메일이 전송된다" 는 결과보다 메일이 어떤 구성요소를 거치고 각 지점에서 어떤 처리가 이뤄지는지를 보는 것이 중요함

⁑ 논리 구조와 물리 구조

Email 시스템은 논리 구조와 물리 구조를 구분해서 이해해야 함

논리 구조 (역할 기반)👇

MUA → MSA → MTA → MDA

메일이 어떤 역할을 거쳐 전달되는지를 설명하는 구조



#### 물리 구조 (시스템 기반)👇
>```
Client → Gateway → Mail Server → Mailbox

실제 운영 환경에 배치된 시스템 구조

논리 구조는 메일 처리 과정을 역할 단위로 나눈 것이고, 물리 구조는 그 역할이 실제 시스템에서 어떻게 배치되는지를 보여주는 구조임

예를 들어 MTA와 MDA는 역할 이름이지만, 실제 환경에서는 하나의 Mail Server 안에서 함께 동작할 수도 있음. 반대로 보안이나 운영 목적에 따랄 Gateway, Mail Server, Mailbox가 별도 시스템으로 분리될 수도 있음

*즉, 논리구조는 "무슨 역할을 하는가" 를 이해하기 위한 기준이고, 물리구조는 "그 역할이 실제 어디에 배치되는가" 를 이해하기 위한 기준 *

$$ 동일한 \ Mail \ Server가 \ 여러 \ 역할을 \ 동시에 \ 수행할 \ 수도 \ 있고, $$ $$ 역할별로 \ 별도 \ 시스템에 \ 분리되어 \ 운영될 \ 수도 \ 있음. $$

⁎ 인프라 배치 구조

Email 인프라는 조직 규모, 보안 요구사항, 운영 방식에 따라 여러 형태로 배치될 수 있음

• 소규모 환경 🏡 : 하나의 Mail Server가 역할을 함께 수행 구조 등

• 기업 환경 🏘️ : Gateway를 앞단에 배치해 메일일을 먼저 검사하는 구조 등

• 서비스 환경 🌐 : Microsoft 365, Google Workspace와 같은 Cloud Mail, 내부 시스템과 Cloud를 함께 사용하는 Hybrid 구조 등

⁑ 기본 메일 구조

Email 인프라를 가장 단순하게 이해하기 위한 형태

이 구조에서는 사용자가 Mail Server를 통해 메일을 보내고, 수신된 메일은 Mailbox에 저장됨, 다만 실제 기업 환경에서는 보안 검사, 정책 적용, 외부 위협 차단이 필요하기 때문에 기본 구조에 Gateway나 별로 보안 솔루션이 추가되는 경우가 많음

⁂ 단일 Mail Server 구조

단일 Mail Server 구조는 메일 제출, 전달, 저장 역할이 하나의 시스템에 모여 있는 형태

구조가 단순하기 때문에 이해하기 쉽고 관리 지점도 적지만, 모든 역할이 하나의 서버에 집중되기 때문에 해당 서버에 장애가 발생하면 메일 송수신, 저장 기능이 함께 영향을 받을 수 있음

특징 👇

• **구성 단순 ** : 구성이 간단하여 관리가 용이함

• **구축 비용 낮음 ** : 별도의 서버나 장비가 필요하지 않아 비용이 절감됨

• **소규모 조직에서 사용 ** : 사용자 수가 적은 환경에 적합함

• **장애 발생 시 전체 영향 ** : 서버 장애 시 메일 서비스 전체에 영향을 줌

⁂ 역할 통합 구조

역할 통합 구조는 물리적으로는 하나의 시스템이지만, 내부적으로는 여러 메일 기능을 함께 제공하는 형태

예를 들어 사용자는 Webmail을 통해 메일에 접근하고, 같은 시스템 내부에서는 SMTP 전송, Mailbox 저장, 사용자 인증 등이 함께 처리될 수 있음

_즉 하나의 제품처럼 보이더라도 내부적으로는 여러 논리적 역할이 결합되어 동작하는 구조 _

특징

• **SMTP, Mailbox, Webmail 기능 통합 ** : 메일 전송, 저장, 웹 접속 기능을 하나의 시스템에서 제공

• **Exchange, Zimbra 등 ** : 대표적인 통합 메일 솔루션에서 일반적으로 사용

• **물리적으로는 하나, 논리적으로는 여러 역할 ** : 하나의 서버 / 시스템이지만 내부적으로 여러 역할을 수행

⁑ Gateway 포함 구조

외부와 내부 Mail Server 사이에 별도의 검사 지점을 두는 방식

Gateway는 메일을 단순히 전달하는 장비라기보다, 메일이 내부 Mail Server나 외부 수신자에게 전달되기 전에 보안 정책을 적용하는 통제 지점에 가까움

이 위치에서 스팸, 악성 첨부파일, 피싱 URL, 발신자 위조 여부, 정보 유출 가능성 등을 확인할 수 있음

⁂ Inbound 구조

외부에서 내부로 들어오는 메일 흐름

이 구조의 핵심은 외부에서 들어온 메일을 내부 사용자에게 전달하기 전에 검증하는 것

외부 메일은 기본적으로 조직이 직접 통제할 수 없는 영역에서 들어오기 때문에, 발신 도메인 검증, 첨부 파일 검사, URL 검사, 스팸 필터링 같은 보안 처리가 중요

이 과정을 거진 뒤 정상 메일만 내부 Mail Server와 Mailbox로 전달되도록 구성함

Gateway 처리 영역

• SPF / DKIM / DMARC 검증
• 스팸 필터링
• URL 검사
• 첨부파일 검사

특징

• 외부 위협 차단
• 내부 Mailbox 보호
• 가장 일반적인 기업 구조

⁂ Outbound 구조

내부 사용자가 외부로 메일을 발송하는 흐름

이 구조의 핵심은 내부에서 외부로 나가는 메일이 조직 정책에 맞게 발송되었는지 확인하는 것

외부 위협을 막는 Inbound와 달리, Outbound에서는 내부 정보 유출, 잘못된 수신자 전송, 민감정보 포함 여부, 첨부파일 정책 위반 여부가 중요

따라서 Outbound Gateway는 발신 메일을 통제하고 조직의 보안 정책을 적용하는 역할을 수행함

Gateway 처리 영역

• 발신 정책 적용
• DLP
• 첨부파일 정책
• 외부 발송 통제

특징

• 내부 정보 유출 방지
• 조직 정책 적용
• 발신 메일 통제

⁑ Cloud / On-prem 구조

Email 인프라는 어디에 Mail Server와 Mailbox를 두는지에 따라 Cloud, On-prem, Hybrid 구조로 나눌 수 있음

이 구분은 단순히 서버 위치만의 차이가 아닌, 운영 책임을 누가 가지며 보안 정책을 어디에서 적용하는지, 메일 데이터가 어디에 저장되는지, 기존 내부 시스템과 어떻게 연동되는지가 달라짐

⁂ Cloud Mail

Cloud Mail은 Mail Server와 Mailbox 기능을 Cloud 서비스가 제공하는 구조 [ex: Microsoft 365, Google Workspace]

• 장점: 조직이 직접 Mail Server를 구축하거나 운영하지 않아도 되기 때문에 운영 부담을 줄일 수 있음.

계정 탈취, 피싱 메일, 악성 URL, 외부 공유, 민감정보 유출 위험은 여전히 존재하기 때문에 별도 보안 정책과 접근 통제가 필요함

특징

• Mailbox와 MTA 기능을 Cloud 제공
• 운영 부담 감소
• 확장성과 가용성 우수
• 현재 가장 일반적인 형태

⁂ On-prem Mail

On-prem Mail은 조직이 직접 Mail Server와 Mailbox를 구축하고 관리하는 구조

• 장점: 메일 데이터 위치, 서버 구성, 보안 정책, 외부 연동 방식을 직접 통제할 수 있음
• 단점: 서버 운영, 장애 대응, 백업, 보안 패치, 스팸 대응까지 조직이 직접 관리해야 함

특징

• 높은 통제 수준
• 내부 정책 적용 용이
• 유지보수 부담 존재

⁂ Hybrid Mail

Cloud Mail과 On-prem 환경을 함께 사용하는 구조

일부 사용자는 Cloud Mail을 사용하고, 기존 내부 시스템이나 일부 메일 흐름은 On-prem 환경에 남겨둘 수 있음

단계적으로 Cloud 전환에는 유리하지만, 메일 라우팅 경로와 보안 정책 적용 위치를 명확하게 설계하지 않으면 운영 복잡도가 높아질 수 있음

특징

• Cloud와 On-prem 장점 결합
• 단계적 Cloud 전환 가능
• 기존 시스템 연동 가능
• 대기업 환경에서 자주 사용

⁎ 운영 관점

메일 장애나 보안 사고가 발생했을 때 어떤 구성 요소에서 문제가 발생했는지 확인하려면 역할 분리, 로그 추적, 우회 경로 관리가 필요함

특히 Gateway가 포함된 환경에서는 메일이 실제로 Gateway를 통과했는지 확인하는 것이 중요함

⁑ 역할 분리

역할 분리는 각 구성 요소가 어떤 책임을 가지는지 명확히 나누는 것

• MTA: 메일 전달
• MDA: Mailbox에 저장
• Gateway: 보안 검사와 정책 적용
• Mailbox: 사용자 메일 보관
  

역할이 명확해야 장애 분석과 보안 정책 적용 지점도 명확해짐

⁑ 로그 추적

메일이 어떤 경로를 거쳤는지 확인하기 위한 운영 기준

• MTA 로그: 메일 전달 여부와 오류 상태 확인
• Gateway 로그: 스팸 탐지, URL 검사, 첨부파일 검사, 정책 적용 결과 확인
• Mailbox 로그: 사용자의 접근이나 수신 상태 확인

⁑ 우회 경로 관리

Gateway를 사용하는 환경에서는 메일이 반드시 Gateway를 통과하도록 설계해야 함

Gateway를 사용하는 환경에서도 메일이 Gateway를 우회해 Mail Server로 직접 들어오면 보안 검사가 적용되지 않을 수 있음

따라서 아래의 항목에 대한 확인이 필요함

확인 항목:

• MX 설정
• Relay 정책
• 방화벽 정책
• 허용 IP 관리

⁎ 정리

Email 인프라는 단순히 메일 서버 하나로 구성되지 않음. 실제 환경에서는 Mail Server, Gateway, Mailbox가 역할을 나누어 동작하며, 조직 규모와 운영 방식에 따라 단일 구조, Gateway 구조, Cloud / On-prem / Hybird 구조로 구성될 수 있음

MTA, MDA는 메일 처리 역할이고, Mail Server, Gateway, Mailbox는 실제 운영 환경에서 배치되는 구성 요소임. 또한 Inbound와 Outbound는 방향만 다른 것이 아니라, 각각 외부 위협 차단과 내부 정보 유출 통제라는 다른 목적을 가짐.

따라서 Email Security를 이해하려면 메일이 이동하는 경로뿐 아니라, 각 지점에서 어떤 검사와 정책이 적용되는지 함께 확인해야 함.

이 글에서 다룰 내용

Email 전송 과정에서 발생하는 지연 구조를 구간별로 정리하고, 각 구간에서 지연이 발생하는 원인을 함께 설명함

Store & Forward 메커니즘이 이러한 지연 구조와 어떻게 연결되는지 실제 동작 흐름을 기준으로 설명함

학습 목표

• Email 전송 지연이 발생하는 위치를 구간 기준으로 이해할 수 있음
• 지연이 발생하는 원인을 구조적으로 파악할 수 있음
• Store & Forward 메커니즘의 실제 동작 방식을 이해할 수 있음
• 상태 코드와 재시도 구조가 전송 흐름에 미치는 영향을 이해할 수 있음

⁎ Email 지연 구조

Email 전송은 단계적으로 이루어지며, 각 단계 사이에서 지연이 발생할 수 있음. 메일은 하나의 경로로 즉시 전달되지 않고, 여러 서버를 거치며 이동함

지연은 특정 지점 하나에서 발생하는 것이 아니라, 전송 흐름 내 여러 구간에서 독립적으로 발생함. 따라서 문제를 분석할 때는 전체 흐름을 기준으로 지연 위치를 구분해야 함.

⁂ 지연 발생 구간

Email 전송 흐름은 다음과 같은 구간으로 나눌 수 있음

• 제출 구간 (MUA → MSA)
• 발신 서버 구간 (MSA → Outbound MTA)
• 전송 구간 (MTA → MTA)
• 수신 처리 구간 (Inbound MTA)
• 배달 구간 (MDA → Mailbox)

⁂ 지연 발생 원인

⁂ 지연 판단 기준

SMTP는 상태 코드 기반으로 전송 상태를 판단함 지연은 주로 4xx 응답에서 발생하며, 메일은 큐에 저장된 상태로 재전송이 반복됨

• 2xx → 즉시 전달
• 4xx → 일시적 실패 → 지연 후 재시도
• 5xx → 영구적 실패 → 전달 중단

⁎ Store & Forward 메커니즘

Store & Forward는 Email 전송에서 사용하는 기본 전달 방식으로, 메일을 중간 서버에 저장한 뒤 다음 서버로 전달하는 구조

⁂ 동작 구조

메일은 각 서버를 거치면서 다음과 같은 흐름으로 처리됨

1. 메일 수신
2. 큐(Queue) 저장
3. 다음 서버로 전송 시도
4. 성공 시 제거
5. 실패 시 재시도

⁑ Queue 기반 처리

메일은 수신 이후 즉시 전달되지 않고 Queue에 저장됨

Queue는 전송 대시 상태의 메일을 관리하며, 다음 조건에서 전송이 수행됨

⁂ 재시도 구조

전송 실패 시 메일은 삭제되지 않고 재전송이 수행됨 재시도는 일정 시간 간격으로 반복되며, 일정 횟수 또는 시간 초과 시 실패로 처리됨

• 상태 코드 4xx
• 수신 서버 응답 없음
• 일시적 네트워크 장애

재시도는 일정 시간 간격으로 반복되며, 일정 횟수 또는 시간 초과 시 실패로 처리됨

⁂ 동작 특징

• 비동기 전송 구조
• 즉시 실패하지 않음
• 여러 서버를 거치며 단계적으로 전달됨

이 구조를 통해 Email은 일부 장애 상황에서도 전송을 유지할 수 있음

⁎ 핵심 정리

Email 전송은 단계적으로 이루어지며, 각 구간에서 독립적으로 지연이 발생할 수 있음. 지연은 전송 흐름의 일부이며, 특정 구간의 상태에 따라 전체 전달 시간이 결정됨.

SMTP는 이러한 지연을 즉시 실패로 처리하지 않고, Store & Forward 구조를 통해 메일 큐에 저장한 뒤 재시도를 수행함

• 이 구조를 통해 Email은 : 전달 경로 중 일부 구간에 문제가 발생하더라도 전송을 유지하고, 최종적으로 수신 서버까지 전달 될 수 있도록 동작함

이 글에서 다룰 내용

SMTP가 Email 전송 과정에서 어떤 역할을 수행하는지 정리하고, 서버 간 메일 전달이 어떤 구조와 흐름으로 이루어지는지 프로토콜 관점에서 설명함

또한, SMTP가 단순 데이터 전송이 아닌, 명령과 응답을 기반으로 동작하는 구조임을 정리하고, 세션 단위 통신과 전송 모델 Store & Forward 이 어떻게 연결되는지 함께 다움

이후 실제 메일 전송 과정에서 사용되는 명령 흐름과 상태 코드 구조까지 이어서 설명함

학습 목표

• SMTP: Simple Mail Transfer Protocol의 역할을 이해할 수 있음
• 서버 간 메일 전달이 이루어지는 방식과 구조를 파악할 수 있음
• 명령 기반 전송 흐름과 상태 코드 개념을 이해할 수 있음
• 이후 확장 기능 및 보안 구조로 이어지는 기반을 확보할 수 있음

SMTP 개요

SMTP: Simple Mail Transfer Protocol 서버 간 Email 전달을 위한 표준 프로토콜

SMTP는 Email 전송 과정에서 서버 간 메시지를 전달하는 역할을 수행함 메일은 클라이언트에서 생성된 이후 여러 서버를 거쳐 이동하며, 이 전달 과정은 SMTP를 통해 이루어짐

Email 전송 흐름 기준

• 구조 → MUA / MSA / MTA / MDA
• 경로 결정 → DNS / MX
• 실제 전달 → SMTP

즉, SMTP는 결정된 경로를 따라 메일을 실제로 전달하는 프로토콜

SMTP는 텍스트 기반 프로콜이며, 사람이 읽을 수 있는 명령을 사용함. 발신 서버는 명령을 전송하고, 수신 서버는 상태 코드를 포함한 응답을 반환한. 이 명령/응답 구조를 통해 전송이 단계적으로 진행됨

이 프토토콜은 RFC 5321에서 정의되어 있으며, Email 전송의 핵심 동작을 담당함

SMTP 정의

SMTP는 서버간 Email 전달을 위한 프로토콜이며, 명령과 응답을 기반으로 동작하는 통신 구조를 가짐.

통신은 요청-응답 방식으로 이루어지며, 발신 서버가 명령을 전송하면 수신 서버는 상태 코드로 처리 결과를 반환함. 각 단계는 이전 단계의 성공 여부를 기준으로 다음 단계로 진행됨

SMTP는 연결 기반 프로토콜로 동작함. 하나의 TCP 연결 안에서 여러 명령이 순차적으로 처리되며, 이 연결 단위를 세션이라고 함. 메일 전송은 이 세션 단위로 이루어짐

이 프로토콜은 데이터 전송 자체보다, 전달 절차와 통신 흐름을 정의하는 데 초럼이 맞춰져 있음

SMTP 역할

SMTP는 Email 전송 흐름에서 Relay 단계에 해당하는 동작을 수행함. 발신 서버는 수신 도메인을 기준으로 대상 서버를 선택한 뒤, SMTP를 통해 새항 서버로 메일을 전달함

Relay 및 전송 역할

메일은 여러 서버를 거치며 단계적으로 전달됨

전송 과정에서 SMTP는

• 다음 서버로 메시지 전달
• 수신 서버와 통신 상태 확인
• 응답 코드 기반으로 전송 성공 여부 판단

을 수행함

메일 전달은 단일 서버에서 끝나지 않으며, Relay 구조를 따라 반복적으로 수행됨. 이 과정에서 SMTP는 각 서버 간 전달을 연결하는 역할을 가짐

한계

SMTP는 전달을 위한 프로토콜로, 메시지 생성이나 저장 기능은 포함하지 않음. 메시지는 상위 계층에서 생성되며, 최종 저장은 수신 서버에서 수행됨

또한 기본 SMTP는 암호화와 인증 기능을 포함하지 않음. 전송 구간은 기본적으로 평문으로 동작하며, 보안 기능은 STARTTLS, SMTP AUTH와 같은 확장 기능을 통해 별도로 적용됨

전송 모델 (Store & Forward)

SMTP 전송은 Store & Forward 모델을 기반으로 동작함

메일은 하나의 경로로 즉시 전달되지 않고, 중간 서버를 거치며 단계적으로 전달됨. 각 서버는 메일을 수신하면 내부 큐에 저장한 뒤, 다음 서버로 전송 가능한 시점에 전달을 수행함

이 구조는 네트워크 환경의 불안정성을 고려한 방식으로, 수신 서버가 일시적으로 응답하지 않는 경우에도 메일을 유지하고 재전송할 수 있도록 설계됨

메일 전달 구조

Sender → MTA → Queue → MTA → Queue → Receiver

이 과정에서 각 서버는 전달 책임을 가지며, 다음 서버로의 전송이 완료될 때까지 메일을 보관함

이 모델을 통해 Email은 실시간 통신이 아닌 비동기 방식으로 동작하며, 안정적인 전달이 가능해짐

SMTP 동작 구조

SMTP는 세션 시간으로 동작하며, 명령과 응답의 흐름을 통해 메일 전송이 이루어짐 하나의 연결안에서 전송 과정이 단계적으로 진행되며, 각 단계는 상태 코드로 제어됨

SMTP 세션

SMTP 통신은 TCP 연결을 기반으로 이루어지며, 이 연결 단위는 세션이라고 함. 하나의 세션 안에서 명령과 응답이 순차적으로 교환되면 하나의 전송이 끝남

연결 수립

SMTP 세션은 발신 서버가 수신 서버에 TCP 연결을 생성하면서 시작됨

• Default Port: 25 (Relay)
• Submission: 587

연결이 수립되면 수신 서버는 초기 응답을 반환함. 이 응답은 서버가 요청을 수용할 준비가 되었음을 나타냄. 이후 발신 서버는 자신의 도메인을 식별하기 위한 명령을 전송하면서 세션이 진행됨

명령 / 응답 구조

SMTP 통신은 명령과 응답 구조 위에서 진행됨. 각 명령은 상태 코드 응답을 통해 다음 단계로 이어지게됨

기본적인 흐름 예시

C: EHLO mail.here.com
S: 250-mail.there.com

C: MAIL FROM:<bob@here.com>
S: 250 OK

C: RCPT TO:<alice@there.com>
S: 250 OK

이 구조에서

• 모든 명령은 순차적으로 처리
• 각 명령에 대해 반드시 응답 반환
• 응답 코드로 다음 단계의 진행 여부 결정

세션 종료

메일 전송이 완료되면 발신 서버는 QUIT 명령을 전송하고, 수신서버는 이에 대한 응답을 반환한 뒤 연결이 종료됨

세션이 종료되면 해당 연결에서의 전송 과정이 완전히 끝나며, 이후 메일 전송은 새로운 세션에서 다시 수행됨

SMTP 전송 흐름

SMTP 전송은 정해진 명령 순서를 따라 진행됨. 각 단계는 독립적인 의미를 가지며, 특정 단계에서 실패가 발생하면 이후 단계는 진행되지 않음

기본 전송 과정

SMTP 전송은 다음 순서로 이루어짐

1. 연결 수립
2. 발신자 지정 (MAIL FROM)
3. 수신자 지정 (RCPT TO)
4. 메시지 전송 (DATA)
5. 세션 종료 (QUIT)

이 흐름은 모든 SMTP 전송에 공통적으로 적용됨

주요 명령

SMTP 전송에서 사용되는 핵심 명령은 다음과 같음

• EHLO / HELO: 서버 식별 및 기능 협상
• MAIL FROM: 발신자 지정
• RCPT TO: 수신자 지정
• DATA: 메시지 전송

각 명령은 정송 흐름에서 특정 역할을 가지며, 순서가 유지되어야 정상적인 전송이 이루어짐

메시지 전달 구조

SMTP에서 실제 메시지는 DATA명령 이후에 전송됨. 메시지는 헤더와 본문을 포함한 전체 데이터 형태로 전달됨

전송 구조

EHLO
MAIL FROM:<sender@example.com>
RCPT TO:<recipient@example.com>
DATA
Subject: Example

Messagge Body
.
QUIT

구조 특징

• 헤더 + 본문 형태
• . : 메시지 종료 표시
• 전체 메시지가 하나의 단위로 전달됨

상태 코드

SMTP는 상태 코드 기반으로 동작하며, 각 단계의 처리 결과는 응답 코드로 표현됨. 이 코드를 통해 전송 성공 여부와 실패 유형을 판단할 수 있음

코드 구조

상태 코드는 세 자리 숫자로 구성됨

• 2xx: 성공
• 4xx: 일시적 실패
• 5xx: 영구적 실패

예시

250 OK
421 Service not available
550 User unknown

응탑 코드는 각 명령잏후 반환되며, 다음 단계로 진행할 수 있는지를 결정하는 기준이 됨/

실패 유형

SMTP에서는 실패를 두 가지 유형으로 구분하며, 메일 전송 시스템에서 재시도 여부와 처리 방식을 결정하는 기준으로 사용됨

일시적 실패 (Temporary Failure) : 일정 시간 이후 재시도 가능

영구적 실패 (Permanent Failure) : 설정 오류 또는 정책 문제로 재시도 불가

SMTP 확장 및 제어

SMTP는 기본 전송 기능 회에도 확장 기능을 통해 보안과 인증을 지원함. 이러한 확장은 ESMTP를 통해 제공되며, 서버 간 협상을 통해 사용 여부가 결정됨

확장 기능

SMTP는 기본 명령만으로 동작할 수 있지만, 실제 확경에서는 다양한 확장 기능이 함계 사용됨. 이러한 확장은 서버가 지원하는 기능을 기반으로 선택적으로 적용됨

ESTMP

ESMTP: Extended Simple Mail Transfer Protocol

ESMTP는 SMTP의 확장 기능을 지원하는 구조로, 기존 SMTP에서 사용되던 HELO 명령 대신 EHLO를 사용하여 서버가 지원하는 기능 목록을 교환함

EHLO 명령에 대한 응답에는 서버가 지원하는 확장 기능이 나열되며, 이후의 전송 과정에서 해당 기능을 선택적으로 사용할 수 있음

대표적인 확장 기능

• STARTTLS: 암호화 지원
• AUTH: 사용자 인증
• SIZE: 메시지 크기 제한
• 8BITMIME: 확장된 문자 인코딩 지원

ESMTP는 기능 협상 기반으로 동작하며, 서버 간 지원 여부에 따라 실제 사용 기능이 결정됨

STARTTLS

STARTTLS는 SMTP 통신을 암호화하기 위한 확장 기능 SMTP 연결은 기본적으로 평문으로 시작되며, STARTTLS 명령을 통해 TLS 기반 암호화로 전환됨

동작 흐름

EHLO
→ STARTTLS
→ TLS Handshake
→ 암호화된 SMTP 통신

암호화가 적용되면 이후 전송되는 명령과 데이터는 보호된 상태로 전달됨.

STARTTLS는 선택적(opportunistic) 방식으로 동작하며, 상대 서버가 지원하지 않을 경우 평문 통신이 유지될 수 있음

SMTP AUTH

AUTH는 발신 서버 또는 클라이언트의 인증을 수행하기 위한 확장 기능

주로 Submission 구간에서 사용되며, 인증된 사용자만 메일을 전송할 수 있도록 제한함

인증 방식

• LOGIN
• RLAIN
• CRAM-MD5

SMTP AUTH는 무단 메일 발송을 방지하고, 발신자의 신원을 확인하는 역할을 수행함

보안 / 인증

SMTP는 기본적으로 암호화와 인증 기능을 포함하지 않기 때문에, 위와 같은 확장 기능을 통해 보안이 적용됨

주요 보안 요소

• 전송 구간 암호화 STARTTLS
• 사용자 인증 AUTH

Relay 구간에서는 별도의 인증이 없기 때문에, IP 기반 정책이나 메일 흐름 정책을 통해 접근을 제어함

SMTP 보안은 단일 기능이 아니라, 여러 요소가 결합되어 적용되는 구조를 가짐

운영 관점

SMTP는 전송 자체보다 문제 식별과 흐름 추적이 중요한 프로토콜 메일은 여러 서버를 거치며 전달되기 때문에, 개별 단계가 아닌 전체 흐름을 기준으로 상태를 확인해야 함

로그

메일 전송 과정에서 발생하는 로그는 SMTP 동작을 확인하는 가장 기본적인 정보 각 서버는 명령과 응답, 상태코드를 포함한 로그를 기록하며 이를 통해 전송 흐름을 추적할 수 있음

확인 기준

• 발신 서버 : 전송 시도 여부
• 중간 서버 (MTA) : Relay cjfl tkdxo
• 수신 서버 : 수신 및 저장 여부

로그에서는 SMTP 명령과 상태 코드가 함께 포함되며, 특정 단계에서 전송이 중단되었는지 확인할 수 있음

메일 문제 분석은 단일 서버 로그만으로 부족하며, 전송 경로 전체를 기준으로 추척해야 정확한 원인을 파악할 수 있음

오류 분석

SMTP는 상태 코드 기반으로 동작하기 때문에, 오류 본석은 응답 코드 해석에서 시작됨

문제 발생 시 확인 순서

1. 상태 코드 확인
2. 실패 유형 판단 (4xx /5xx)
3. 발생 위치 확인 (어느 서버 단계인지)
   

예시

4xx → 일시적 문제 → 재시도 대상
5xx → 설정 또는 정책 문제 → 즉시 확인 필요

상태 코드를 기준으로 문제를 분류하면, 불필요한 재시도를 줄이고 원인 파악 속도를 높일 수 있음

보안

SMTP는 기본적으로 평문 통신을 사용하기 때문에, 보안 설정이 함께 적용되어야 함

• STARTTLS 적용 → 전송 구간 암호화
• SMTP AUTH → 발신자 인증
• Open Relay 차단 → 무단 전송 방지

Open Relay는 인증 없이 메일을 전달할 수 있는 상태를 의미하며, 스팸 발송에 악용될 수 있음 Relay 정책과 인증 설정을 통해 이를 제한해야 함

또한 암호화가 적용되지 않은 경우 메일 내용과 정보가 노출될 수 있으므로, TLS 적용이 기본적으로 요구됨

정리

SMTP는 서버 간 Email 전달을 수행하는 프로토콜로, 명령과 응답을 기반으로 동작하는 세션 단위 통신 구조를 가짐.

메일 전송은 하나의 연결 안에서 순차적으로 진행되며, 각 단계는 상태 코드를 통해 제어됨. 이 구조를 통해 전송 과정이 단계적으로 처리됨.

전송 구조

• SMTP 전송은 세션 단위로 수행됨
• 하나의 세션 안에서 명령과 응답이 반복됨
• 전송은 정해진 명령 순서를 따라 진행됨
  

전체 흐름

연결 → EHLO → MAIL FROM → RCPT TO → DATA → QUIT

각 단계는 이전 단계의 성공 여부에 따라 다음 단계로 진행됨

동작 모델

SMTP는 Store & Forward 모델을 기반으로 동작함

• 메일은 즉시 전달되지 않고 큐에 저장됨
• 다음 서버로 전달 가능한 시점에 전송 수행
• 여러 서버를 거치며 단계적으로 전달됨

통신 구조

• 텍스트 기반 명령 / 응답 구조
• 서버 간 요청-응답 방식으로 통신
• 상태 코드로 처리 결과 판단
  • 상태 코드 기준 2xx → 성공 4xx → 일시적 실패 (재시도) 5xx → 영구적 실패

확장 및 보안

• ESMTP → 확장 기능 협상 구조
• STARTTLS → 전송 구간 암호화
• SMTP AUTH → 발신자 인증

기본 SMTP는 평문 프로토콜이며, 보안 기능은 확장을 통해 적용됨

운영 관점

• 로그 기반으로 전송 흐름 추적 필요
• 상태 코드를 통해 문제 위치와 유형 판단
• Open Relay 차단 및 인증 설정 필수

**[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 개념이 확산될 가능성 있음