Azure SQL Database Hands-on - 데이터베이스 인증 및 권한 부여 구성

Microsoft DP-300 기반 Azure SQL Database 인증 및 권한 관리 실습 정리
Azure SQL Database에서 Microsoft Entra ID 기반 인증과 사용자·역할·권한 관리를 실습한다.

---

1. 실습 개요

시나리오

AdventureWorks 환경의 보안을 담당하는 DBA 역할로, Azure SQL Database에 Microsoft Entra ID 기반 인증을 구성하고 최소 권한 원칙(Least Privilege)을 적용한다.

• Azure SQL Database에 Entra Admin 지정
• Microsoft Entra MFA 인증으로 SSMS 접속
• Contained User 생성
• 사용자 정의 Role 생성
• Stored Procedure 실행 권한 부여
• EXECUTE AS USER를 이용한 권한 테스트

---

2. 핵심 개념 정리

Microsoft Entra ID

기존 Azure AD(Azure Active Directory)의 새로운 이름이다.
Azure SQL Database의 인증 백엔드로 사용할 수 있으며 MFA, 조건부 액세스 등을 적용할 수 있다.

Entra Admin

Azure SQL Logical Server 단위로 지정되는 관리자 계정이다.
해당 사용자는 서버 내 데이터베이스에 대한 최고 수준 권한을 가진다.

Contained User

Master DB 로그인 없이 특정 데이터베이스 내부에서만 인증되는 사용자이다.

CREATE USER [username] WITH PASSWORD = 'password';

이 방식은 데이터베이스 이동성을 높인다.

Database Role

권한을 묶어서 관리하기 위한 역할(Role)이다.

CREATE ROLE RoleName;
ALTER ROLE RoleName ADD MEMBER UserName;

EXECUTE AS USER

현재 세션의 실행 컨텍스트를 특정 사용자로 변경하여 권한을 테스트한다.

EXECUTE AS USER = 'UserName'

원래 권한으로 돌아갈 때는 다음을 사용한다.

REVERT;

---

3. 실습 환경 준비

준비물

• Azure SQL Logical Server
• AdventureWorksLT 샘플 데이터베이스
• SSMS 또는 Azure Data Studio
• Microsoft Entra 계정

AdventureWorksLT 샘플 DB 생성 시:

• 워크로드 환경: 개발
• 샘플 데이터 사용: AdventureWorksLT

선택하여 생성한다.

---

4. Microsoft Entra Admin 구성

Azure Portal에서 관리자 지정

절차

1. Azure Portal 접속
2. All resources 선택
3. SQL Server 선택
4. 구성되지 않음 클릭
5. Microsoft Entra ID 사용자 검색
6. 사용자 선택 후 Save

이 과정을 통해 해당 계정이 Azure SQL Server의 Entra Admin이 된다.

---

5. SSMS에서 Microsoft Entra MFA 인증 연결

서버 이름 복사

Azure Portal → SQL Server → Overview 에서 서버 이름 복사

예시:

myserver.database.windows.net

---

SSMS 연결

인증 방식 설정

SSMS에서:

• Connect → Database Engine

• Server name 입력

• Authentication:

  • Microsoft Entra MFA
  • 또는 Azure Active Directory - Universal with MFA

선택

---

방화벽 이슈

처음 접속 시 클라이언트 IP를 방화벽에 추가해야 할 수 있다.

SSMS가 자동으로 추가 기능을 제공하기도 한다.

---

6. 데이터베이스 사용자 생성

AdventureWorksLT 데이터베이스에서 새 쿼리를 생성한다.

사용자 생성

CREATE USER [DP300User1] WITH PASSWORD = 'Azur3Pa$$';
GO

CREATE USER [DP300User2] WITH PASSWORD = 'Azur3Pa$$';
GO

이 사용자들은 AdventureWorksLT 데이터베이스 범위(scope) 안에서만 동작한다.

---

7. 사용자 정의 Role 생성

Role 생성

CREATE ROLE [SalesReader];
GO

사용자 추가

ALTER ROLE [SalesReader] ADD MEMBER [DP300User1];
GO

ALTER ROLE [SalesReader] ADD MEMBER [DP300User2];
GO

---

8. Stored Procedure 생성

DemoProc 생성

CREATE OR ALTER PROCEDURE SalesLT.DemoProc
AS
SELECT
    P.Name,
    SUM(SOD.LineTotal) AS TotalSales,
    SOH.OrderDate
FROM SalesLT.Product P
INNER JOIN SalesLT.SalesOrderDetail SOD
    ON SOD.ProductID = P.ProductID
INNER JOIN SalesLT.SalesOrderHeader SOH
    ON SOH.SalesOrderID = SOD.SalesOrderID
GROUP BY P.Name, SOH.OrderDate
ORDER BY TotalSales DESC
GO

이 프로시저는 상품별 매출 데이터를 조회한다.

---

9. 권한 테스트

EXECUTE AS USER 실행

EXECUTE AS USER = 'DP300User1'
EXECUTE SalesLT.DemoProc

실행 시 권한 오류가 발생한다.

The EXECUTE permission was denied on the object 'DemoProc'

왜냐하면 SalesReader 역할에는 아직 아무 권한도 없기 때문이다.

---

10. EXECUTE 권한 부여

권한 추가

REVERT;

GRANT EXECUTE ON SCHEMA::SalesLT TO [SalesReader];
GO

• REVERT

  • 원래 권한 컨텍스트로 복귀

• GRANT EXECUTE

  • SalesLT 스키마 내 프로시저 실행 권한 부여

---

11. 다시 실행

EXECUTE AS USER = 'DP300User1'
EXECUTE SalesLT.DemoProc

이번에는 정상적으로 결과가 반환된다.

---

12. 핵심 심화 개념 - Ownership Chain

이번 실습에서 가장 중요한 개념이다.

왜 EXECUTE 권한만 줬는데 SELECT가 되었을까?

DP300User1에게는 다음 테이블에 대한 SELECT 권한이 없다.

• SalesLT.Product
• SalesLT.SalesOrderDetail
• SalesLT.SalesOrderHeader

그런데도 Stored Procedure는 정상 동작했다.

이유는 SQL Server의 Ownership Chain(소유권 체인) 때문이다.

---

Ownership Chain 원리

SQL Server는 Stored Procedure 실행 시:

1. 프로시저 자체의 EXECUTE 권한만 검사
2. 내부 객체들이 동일한 owner이면
3. 내부 SELECT 권한 검사를 생략

즉:

사용자
→ 프로시저 실행 권한 검사
→ 내부 테이블 권한 검사 생략
→ 실행 성공

---

이번 실습에서 체인이 유지된 이유

다음 객체들의 owner가 모두 dbo이다.

• SalesLT.DemoProc
• SalesLT.Product
• SalesLT.SalesOrderDetail
• SalesLT.SalesOrderHeader

따라서 Ownership Chain이 끊기지 않는다.

---

13. 운영 관점에서 중요한 점

Ownership Chain은 운영 환경에서 매우 많이 사용된다.

대표 패턴:

사용자에게 테이블 직접 권한은 주지 않음
↓
Stored Procedure 실행만 허용
↓
프로시저 내부에서 데이터 접근

이 방식의 장점:

• 최소 권한 원칙 적용 가능
• 테이블 직접 접근 차단 가능
• API 형태의 DB 접근 구조 구현 가능

---

하지만 주의할 점

권한이 강력한 만큼 위험성도 존재한다.

특히:

• 프로시저 내부에서 민감 컬럼 노출 가능
• 동적 SQL 사용 시 Ownership Chain 깨질 수 있음

운영 환경 권장 사항:

• 스키마 owner 표준화
• WITH EXECUTE AS OWNER 사용
• 정기 권한 감사 수행

---

14. 실습 검증 체크리스트

다음 항목이 모두 성공하면 실습 완료이다.

• Entra ID 관리자가 서버에 지정됨
• DP300User1 / DP300User2 생성 완료
• SalesReader Role 생성 완료
• 권한 부여 전 EXECUTE 실패 확인
• GRANT EXECUTE 후 실행 성공 확인

---

15. 정리(Clean-up)

실습 종료 후 삭제 가능:

DROP USER DP300User1;
DROP USER DP300User2;
DROP ROLE SalesReader;

운영 환경에서는 Entra Admin을 개인 계정보다는 보안 그룹 기반으로 관리하는 것이 일반적이다.

---

마무리

• Microsoft Entra ID 인증
• MFA 기반 SSMS 연결
• Contained User 생성
• Database Role 기반 권한 관리
• Stored Procedure 실행 권한
• EXECUTE AS USER 권한 테스트
• Ownership Chain 동작 원리

---

Azure SQL Database Hands-on - Microsoft Defender for SQL 활성화 및 데이터 분류

Azure SQL Database에서 Microsoft Defender for SQL을 활성화하고, 데이터 분류(Data Discovery & Classification), 취약성 평가(VA), Threat Detection, Auditing, Dynamic Data Masking까지 실습한다.

---

1. 실습 개요

시나리오

• Microsoft Defender for SQL 활성화
• 민감 정보 자동 분류
• Vulnerability Assessment(VA)
• Threat Detection 알림
• SQL Auditing
• Dynamic Data Masking(DDM)

발견 → 경고 → 추적 → 보호

---

2. 핵심 개념 정리

Microsoft Defender for SQL

Azure SQL Database의 보안 기능이다.

주요 기능:

• SQL Injection 탐지
• 이상 로그인 탐지
• Brute-force 탐지
• Vulnerability Assessment(VA)
• Threat Detection

등을 제공한다.

---

Data Discovery & Classification

DB 내부 컬럼을 스캔하여:

• 이메일
• 전화번호
• 개인정보
• 금융정보

같은 민감 데이터를 자동 식별하고 분류(Label)를 부여한다.

---

Vulnerability Assessment(VA)

보안 취약점을 자동 분석하는 기능이다.

예시:

• 과도한 권한
• 위험한 설정
• 오래된 구성
• 감사 미설정

등을 탐지한다.

---

SQL Auditing

데이터베이스 내부 이벤트를 기록하는 기능이다.

저장 위치:

• Storage Account
• Log Analytics
• Event Hub

등으로 전송 가능하다.

---

Dynamic Data Masking(DDM)

실제 데이터를 변경하지 않고:

조회 결과만 가려서 표시

하는 기능이다.

예시:

test@example.com
↓
tXXX@XXXX.com

---

3. Microsoft Defender for SQL 활성화

Azure Portal 접속

1. Azure Portal 접속
2. SQL servers 검색
3. 대상 SQL Server 선택

---

Defender 활성화

경로:

SQL Server
→ Security
→ Microsoft Defender for Cloud

이후:

사용(Enable)

클릭

---

토글 확인

Configure 진입 후:

MICROSOFT DEFENDER FOR SQL = ON

상태인지 확인한다.

---

4. Data Discovery & Classification

데이터 분류 기능 진입

경로:

AdventureWorksLT
→ Security
→ Data Discovery & Classification

---

자동 분류 추천 수락

포털에서 다음 메시지가 표시된다.

15개의 열에서 민감 정보 발견

이후:

• Select All
• Accept selected recommendations
• Save

를 실행한다.

---

결과

총:

• 5개 테이블
• 15개 컬럼

이 자동 분류된다.

---

5. Vulnerability Assessment(VA)

목적

보안 취약점을 자동 스캔한다.

예시:

• 약한 설정
• 과도 권한
• 감사 미설정
• 공개 접근

등을 탐지한다.

---

실습 흐름

1. Defender for SQL 활성화
2. VA 실행
3. Findings 확인
4. 일부 Remediation 수행
5. Passed 상태 확인

---

6. Threat Detection 알림 시뮬레이션

목적

실제 보안 알림 흐름을 테스트한다.

---

이메일 알림 설정

Defender for Cloud 설정에서:

• 이메일 주소 등록
• 알림 유형 선택

후 저장한다.

---

Brute-force 시뮬레이션

SSMS에서:

잘못된 비밀번호로 4~5회 로그인

시도

---

SQL Injection 패턴 시뮬레이션

EXEC sp_executesql
N'SELECT * FROM sys.databases WHERE name = ''anything'' OR 1=1';
GO

또는:

DECLARE @sql NVARCHAR(MAX) =
N'SELECT * FROM sys.tables WHERE name LIKE ''%'' OR 1=1';

EXEC (@sql);

이후 Defender for Cloud의:

Security alerts

에서 알림을 확인한다.

예시:

• Brute force attack
• Potential SQL injection

---

7. 민감도 분류 메타데이터 확인

시스템 카탈로그 조회

분류 정보는:

sys.sensitivity_classifications

에 저장된다.

---

조회 쿼리

SELECT 
    SCHEMA_NAME(o.schema_id) AS [schema],
    o.name AS [table],
    c.name AS [column],
    sc.label,
    sc.information_type,
    sc.rank_desc
FROM sys.sensitivity_classifications sc
INNER JOIN sys.objects o
    ON sc.major_id = o.object_id
INNER JOIN sys.columns c
    ON sc.major_id = c.object_id
   AND sc.minor_id = c.column_id
ORDER BY [schema], [table], [column];

---

수동 분류 추가

ADD SENSITIVITY CLASSIFICATION TO
    SalesLT.Customer.MiddleName
WITH (
    LABEL = 'Confidential',
    LABEL_ID = '332211aa-bbcc-ddee-ff00-112233445566',
    INFORMATION_TYPE = 'Name',
    INFORMATION_TYPE_ID = '5b56518b-5a91-490b-9300-983344497a82',
    RANK = MEDIUM
);

---

결과 확인

기존:

15개 컬럼

↓

추가 후:

16개 컬럼

으로 증가한다.

---

8. SQL Auditing + Log Analytics

목적

민감 데이터 접근 이력을 추적한다.

---

Auditing 활성화

경로:

AdventureWorksLT
→ Auditing
→ Enable Azure SQL Auditing

이후:

• Log Analytics 연결
• Diagnostic Settings 추가

를 수행한다.

---

감사 이벤트 발생

SELECT TOP 10
    EmailAddress,
    FirstName,
    LastName
FROM SalesLT.Customer;
GO

---

KQL 조회

AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| take 10

---

핵심 포인트

감사 로그 내부에:

data_sensitivity_information_s

필드가 자동 포함된다.

즉:

누가 민감 데이터를 조회했는가

를 추적할 수 있다.

---

9. Dynamic Data Masking(DDM)

목적

민감 데이터를 일반 사용자에게 숨긴다.

---

마스킹 규칙 추가

Email 마스킹

ALTER TABLE SalesLT.Customer
    ALTER COLUMN EmailAddress
    ADD MASKED WITH (FUNCTION = 'email()');
GO

---

Phone 마스킹

ALTER TABLE SalesLT.Customer
    ALTER COLUMN Phone
    ADD MASKED WITH (
        FUNCTION = 'partial(0,"XXX-XXX-",4)'
    );
GO

---

10. 일반 사용자 관점 테스트

EXECUTE AS USER

EXECUTE AS USER = 'DP300User1';

SELECT TOP 5
    FirstName,
    LastName,
    EmailAddress,
    Phone
FROM SalesLT.Customer;

REVERT;

---

결과

일반 사용자는:

aXXX@XXXX.com
XXX-XXX-1234

형태로 보인다.

---

11. UNMASK 권한 부여

권한 추가

GRANT UNMASK TO DP300User1;

---

다시 조회

EXECUTE AS USER = 'DP300User1';

SELECT TOP 5
    EmailAddress,
    Phone
FROM SalesLT.Customer;

REVERT;

이번에는 실제 원본 데이터가 보인다.

---

원상 복구

REVOKE UNMASK FROM DP300User1;

ALTER TABLE SalesLT.Customer
    ALTER COLUMN EmailAddress DROP MASKED;

ALTER TABLE SalesLT.Customer
    ALTER COLUMN Phone DROP MASKED;

---

12. 실무적으로 중요한 포인트

DDM의 한계

DDM은:

표시값만 가리는 기능

이다.

즉:

• 실제 데이터는 그대로 존재
• 관리자 권한자는 원본 조회 가능

하다.

---

실제 운영에서는

다음 조합으로 다층 방어를 구성한다.

Classification
→ DDM
→ TDE / Always Encrypted
→ RLS(Row-Level Security)

---

13. 실습 검증 체크리스트

다음 항목이 모두 성공하면 실습 완료이다.

• Defender for SQL 활성화
• 15개 컬럼 자동 분류
• VA Findings 확인
• Threat Detection 알림 확인
• sys.sensitivity_classifications 증가 확인
• SQLSecurityAuditEvents 수집 확인
• DDM 마스킹 동작 확인
• UNMASK 후 원본 노출 확인

---

14. 정리(Clean-up)

실습 종료 후:

• DROP MASKED
• REVOKE UNMASK
• 추가 분류 제거
• Log Analytics 삭제
• VA Storage 삭제

등을 수행할 수 있다.

---

마무리

이번 실습에서는 Azure SQL Database 보안 기능 전반을 실습했다.

Defender 활성화
→ 민감 데이터 발견
→ Threat Detection
→ 감사 로그 수집
→ Dynamic Data Masking 보호

발견 → 탐지 → 감사 → 보호

---

Azure SQL Database Hands-on - CPU 사용률 식별 및 경고

Azure Monitor를 활용하여 Azure SQL Database의 CPU 사용률을 모니터링하고, 평균 CPU 사용량이 80%를 초과할 경우 이메일 알림을 전송하는 Alert Rule을 구성한다.

---

1. 실습 개요

시나리오

AdventureWorksLT 데이터베이스의 평균 CPU 사용률이 80%를 초과하면 자동으로 이메일 경고를 전송하도록 Azure Monitor Alert를 구성한다.

이번 실습에서는:

• CPU percentage 메트릭 기반 경고 생성
• Alert Rule 구성
• Action Group 생성
• 이메일 알림 설정
• 실제 CPU 부하 테스트

까지 수행한다.

---

2. 핵심 개념 정리

Azure Monitor Alert Rule

Azure 리소스의 메트릭 또는 로그를 주기적으로 평가하여:

조건 충족 시 자동 작업(Action) 실행

하는 기능이다.

구성 요소:

• Signal
• Condition
• Action Group

으로 이루어진다.

---

CPU percentage

Azure SQL Database의 평균 CPU 사용률 메트릭이다.

기본적으로:

1분 단위 집계

가 사용된다.

---

Aggregation Type

메트릭 집계 방식이다.

대표 유형:

• Average
• Minimum
• Maximum
• Total

이번 실습에서는:

Average

를 사용한다.

---

Action Group

경고 발생 시 수행할 작업 묶음이다.

예시:

• Email
• SMS
• Push
• Voice
• Webhook
• Azure Function

등을 연결할 수 있다.

---

3. 실습 환경 준비

준비물

• AdventureWorksLT 데이터베이스
• Azure Portal 접근 권한
• 이메일 수신 가능 계정

---

4. Azure Monitor Alert 생성

Alerts 메뉴 진입

경로:

AdventureWorksLT
→ Monitoring
→ Alerts

이후:

+ Create alert rule

선택

---

5. CPU Signal 설정

Signal 선택

CPU percentage

선택

---

조건 설정

다음과 같이 설정한다.

항목	값
Threshold Type	Static
Aggregation Type	Average
Operator	Greater than
Threshold Value	80

즉:

평균 CPU 사용률 > 80%

조건이 되면 경고가 발생한다.

---

6. Action Group 생성

Actions 탭 이동

Alert Rule 생성 화면에서:

Actions
→ Create action group

선택

---

기본 정보 입력

항목	값
Action group name	emailgroup
Display name	emailgroup

입력 후:

Next: Notifications

선택

---

7. 이메일 알림 설정

Notifications 설정

다음과 같이 입력한다.

항목	값
Notification type	Email/SMS message/Push/Voice
Name	DemoLab

이후 이메일 주소 입력

---

생성 완료

Review + create
→ Create

를 눌러 Alert Rule과 Action Group을 생성한다.

---

8. 이메일 알림 확인

구성이 완료되면:

You've been added to an Azure Monitor action group

형태의 이메일을 수신할 수 있다.

이후 실제 CPU 사용량이 80%를 초과하면 Azure Monitor Alert 메일이 전송된다.

---

9. 실제 CPU 부하 발생 테스트

실습 문서에서는 CPU 부하를 강제로 발생시키기 위한 쿼리를 제공한다.

---

대량 카테시안 곱 쿼리

SELECT
    COUNT(*) AS TotalCount,
    SUM(CAST(ABS(CHECKSUM(NEWID())) AS FLOAT)) AS RandomSum
FROM SalesLT.SalesOrderDetail a
CROSS JOIN SalesLT.SalesOrderDetail b
CROSS JOIN SalesLT.SalesOrderDetail c
WHERE
    SQRT(POWER(a.UnitPrice, 2) + POWER(b.UnitPrice, 2)) > 100
    AND a.OrderQty * b.OrderQty * c.OrderQty > 0;

---

왜 CPU 사용률이 높아질까?

이 쿼리는:

• CROSS JOIN
• 수학 연산
• 문자열/랜덤 함수

를 동시에 수행한다.

특히:

N × N × N

형태의 카테시안 곱이 발생하므로 CPU 부하가 매우 커진다.

---

10. CPU 지속 사용 루프

루프 기반 CPU 사용

DECLARE @StartTime DATETIME = GETDATE();
DECLARE @EndTime DATETIME = DATEADD(SECOND, 60, @StartTime);
DECLARE @Dummy FLOAT;

WHILE GETDATE() < @EndTime
BEGIN
    SET @Dummy =
        SQRT(PI() * RAND()) * POWER(RAND(), 2);
END;

---

특징

약 1분 동안 지속적으로 CPU를 사용한다.

특징:

• 반복 수학 연산
• 랜덤 함수 호출
• 지속 루프 실행

으로 인해 CPU 사용률을 강제로 상승시킨다.

---

11. 실습 검증

다음 항목이 모두 성공하면 실습 완료이다.

• AdventureWorksLT > Alerts에 새 규칙 생성
• Action Group(emailgroup) 생성
• Notification(DemoLab) 생성
• 이메일 수신 확인

---

12. 운영 관점에서 중요한 포인트

Evaluation Frequency

경고 평가 주기이다.

예시:

• 1분
• 5분

주기를 사용할 수 있다.

짧을수록 민감하지만 비용과 false positive가 증가한다.

---

Static vs Dynamic Threshold

Static

CPU > 80%

처럼 고정값 사용

---

Dynamic

Azure가 과거 패턴을 학습하여 자동 임계값을 계산한다.

트래픽 변동성이 큰 시스템에서는 Dynamic Threshold가 false positive를 줄여준다.

---

13. 실무에서 자주 사용하는 패턴

운영 환경에서는 보통:

Severity	용도
Sev0	장애 수준
Sev1	긴급
Sev2	일반 경고

형태로 Action Group을 분리해 관리한다.

예시:

cpu-sev0-email
cpu-sev1-teams
cpu-sev2-monitoring

같은 형태로 표준화한다.

---

14. 정리(Clean-up)

실습 종료 후 비용 절약을 위해:

• Alert Rule 삭제
• Action Group 삭제

를 수행할 수 있다.

---

마무리

이번 실습에서는 Azure SQL Database의 CPU 사용률을 기준으로 Azure Monitor Alert를 구성했다.

핵심 흐름은 다음과 같다.

CPU percentage 메트릭 선택
→ 임계값 설정
→ Action Group 생성
→ 이메일 알림 연결
→ 실제 CPU 부하 테스트

Azure Monitor Alert는 단순 이메일 기능이 아니라:

• 운영 자동화
• 장애 탐지
• 비용 감시
• 성능 이상 탐지

등 Azure 운영 전반의 핵심 기능으로 활용된다.

---

Azure Architecture Seminar 정리

Azure 아키텍처를 단순 서비스 나열이 아니라 프레임워크 기반으로 설계하는 방법을 다룬 세미나 자료 정리
핵심 주제는 CAF(Cloud Adoption Framework), WAF(Well-Architected Framework), 그리고 Azure Reference Architecture이다.

---

1. 세미나 핵심 목표

프레임워크 기반으로 아키텍처를 평가하고 설계하는 사고방식

1. WAF·CAF 기반으로 설계 평가
2. 안티패턴 ↔ 대응패턴 구분
3. 실제 Azure Reference Architecture 분석

---

2. 온프렘과 클라우드의 결정적 차이

세미나에서는 클라우드 아키텍처 사고방식이 온프렘과 근본적으로 다르다고 설명한다.

---

1) 장애를 가정하고 설계

온프렘

장애가 안 나도록 비싸게 설계

Azure

장애는 반드시 발생한다고 가정

따라서:

• Availability Zone
• Region 분산
• Backup
• Site Recovery

기반으로 설계한다.

---

2) 비용은 운영 행위

온프렘은:

CapEx

중심

클라우드는:

OpEx

중심이다.

즉:

• 어떤 SKU를 쓰는가
• 언제 끄는가
• 얼마나 자동화하는가

자체가 비용 설계가 된다.

---

3) 보안은 경계가 아니라 신원

온프렘:

방화벽 중심

Azure:

Zero Trust

즉:

• 누가
• 어떤 신원으로
• 어디서 접근했는가

가 핵심 기준이 된다.

---

3. CAF vs WAF

이번 세미나의 핵심이다.

---

CAF (Cloud Adoption Framework)

조직 차원의 프레임워크

CAF는:

회사가 클라우드를 어떻게 도입하는가

를 다룬다.

구성 단계:

1. 전략
2. 계획
3. 준비
4. 도입
5. 거버넌스
6. 관리

즉:

회사 전체의 클라우드 여정

을 정의한다.

---

WAF (Well-Architected Framework)

워크로드 차원의 프레임워크

WAF는:

이 시스템 하나를 어떻게 잘 만들 것인가

를 평가한다.

즉:

• 웹앱
• 데이터 파이프라인
• AI 서비스

각 워크로드마다 적용된다.

---

4. WAF 5+1 기둥

Azure WAF는 총 6개 관점으로 시스템을 평가한다.

기둥	핵심 질문
Reliability	장애가 나도 돌아가는가
Security	신원·데이터를 어떻게 보호하는가
Cost Optimization	필요한 만큼만 쓰는가
Operational Excellence	변경·관측이 자동화되어 있는가
Performance Efficiency	부하 변화에 맞게 확장되는가
Sustainability	자원·탄소를 줄이고 있는가

---

5. 왜 프레임워크가 필요한가

프레임워크 없이 설계하면:

• 사람마다 기준이 다름
• 비용·보안·성능 트레이드오프 추적 불가
• 시간이 지나면 왜 그렇게 설계했는지 잊어버림

반대로 프레임워크를 사용하면:

• 공통 언어 생성
• 체크리스트 기반 리뷰 가능
• 트레이드오프 기록 가능
• 자기 진단 가능

해진다.

---

6. WAF 기둥별 핵심 패턴

---

Reliability (신뢰성)

안티패턴

• 단일 리전
• 단일 VM
• 복구 테스트 없음
• 단일 Load Balancer

---

대응 패턴

• Availability Zone 분산
• Geo-redundant
• Backup + ASR
• Front Door 멀티리전

---

관련 Azure 서비스

• Azure Backup
• Site Recovery
• Front Door
• SQL Geo-replication

---

Security (보안)

안티패턴

• IP 기반 신뢰
• Secret 하드코딩
• Owner 권한 남발

---

대응 패턴

• Zero Trust
• Managed Identity
• Key Vault
• RBAC 최소 권한
• PIM

---

관련 Azure 서비스

• Entra ID
• Managed Identity
• Key Vault
• Defender for Cloud
• Private Endpoint

---

Cost Optimization (비용 최적화)

안티패턴

• 모든 리소스 Pay-as-you-go
• Dev/Test 24시간 켜둠
• 과도한 SKU

---

대응 패턴

• Reservation
• Savings Plan
• Spot VM
• Auto-shutdown
• Cost Alert

---

Operational Excellence (운영 우수성)

안티패턴

• 포털 클릭 기반 운영
• 수동 배포
• 로그 분산

---

대응 패턴

• Terraform / Bicep IaC
• GitHub Actions
• Canary / Blue-Green 배포
• Log Analytics 중앙화

---

Performance Efficiency (성능 효율성)

안티패턴

• 모든 요청이 DB로 직행
• 수직 확장만 사용
• 앱 서버가 정적 자산 직접 제공

---

대응 패턴

• Redis Cache
• Read Replica
• Autoscale
• CDN
• Front Door

---

Sustainability (지속가능성)

안티패턴

• 탄소 효율 고려 없는 리전 선택
• 낮은 사용률 VM 유지
• 피크 시간대 배치

---

대응 패턴

• Right-sizing
• 유휴 리소스 자동 정리
• 탄소 인지 스케줄링

---

7. 가장 중요한 개념 — 트레이드오프

세미나에서 가장 강조하는 부분이다.

모든 기둥을 동시에 완벽하게 만족하는 아키텍처는 없다

예시:

충돌	이유
신뢰성 ↔ 비용	멀티리전은 비쌈
보안 ↔ 성능	Private Endpoint는 홉 증가
성능 ↔ 비용	Premium SKU 비용 증가
운영 ↔ 성능	관측 시스템 자체 부하

즉:

좋은 아키텍처란
어떤 기둥을 왜 양보했는지 설명할 수 있는 아키텍처

이다.

---

8. 레퍼런스 아키텍처 1 — 표준 웹 애플리케이션

구조

Front Door
→ App Service
→ Azure SQL

보조 구성:

• Key Vault
• Managed Identity
• App Insights
• Blob + CDN

---

핵심 의사결정

App Service vs AKS

• 단순 웹앱 → App Service
• 복잡한 컨테이너 운영 → AKS

---

Active-Active vs Active-Passive

• 낮은 RTO/RPO → Active-Active
• 비용 절감 → Active-Passive

---

SQL vs Cosmos DB

• 트랜잭션 중심 → Azure SQL
• 글로벌 분산 중심 → Cosmos DB

---

9. 레퍼런스 아키텍처 2 — 데이터 파이프라인

Medallion Architecture

구조:

Bronze
→ Silver
→ Gold

흐름:

Event Hubs
→ ADLS Gen2
→ Databricks
→ Synapse
→ Power BI

---

핵심 개념

Bronze

원본 보존

Silver

정제·검증

Gold

비즈니스 집계

---

왜 Medallion을 쓰는가

• 원본 보존 가능
• 재처리 용이
• 데이터 품질 추적 가능
• 계층별 책임 분리

---

10. 레퍼런스 아키텍처 3 — AI 추론 / RAG

구조

Container Apps
→ Azure OpenAI
→ AI Search
→ Cosmos DB

보조 서비스:

• Front Door
• Content Safety
• Blob Storage
• App Insights

---

RAG 흐름

1. 질문 임베딩
2. AI Search 벡터 검색
3. 관련 문서 검색
4. GPT 응답 생성
5. Content Safety 필터링
6. 대화 저장

---

11. AI 아키텍처 핵심 의사결정

PTU vs PAYG

PTU

• 일정한 트래픽
• 낮은 지연 요구

PAYG

• 초기 구축
• 변동 트래픽

---

Container Apps vs AKS

Container Apps

• 서버리스
• 빠른 자동 스케일

AKS

• 복잡한 운영
• 세밀한 네트워크 제어

---

AI Search vs Cosmos vs PostgreSQL

서비스	특징
AI Search	하이브리드 검색
Cosmos DB	글로벌 분산
PostgreSQL + pgvector	비용 효율

---

12. 세 가지 아키텍처 비교

워크로드	주요 우선순위
표준 웹앱	신뢰성·보안
데이터 파이프라인	비용·성능
AI 추론(RAG)	보안·운영

---

가장 큰 위험 요소

워크로드	위험
웹앱	DR 미검증
데이터	데이터 품질
AI	프롬프트 주입·비용 폭주

---

13. WAF 자체 평가 체크리스트

세미나 마지막에는 자신의 시스템을 WAF 기준으로 평가한다.

기둥	체크 항목
신뢰성	DR / AZ / RPO / RTO
보안	Managed Identity / Key Vault
비용	Reservation / 자동 종료
운영	IaC / 중앙 로그
성능	캐시 / Autoscale
지속가능성	Right-sizing

---

14. 핵심 결론

이번 세미나의 핵심 메시지는 다음 한 문장으로 정리된다.

좋은 아키텍처는
완벽한 아키텍처가 아니라,
어떤 기둥을 왜 양보했는지 설명할 수 있는 아키텍처

그리고 WAF는:

서비스를 외우기 위한 프레임워크가 아니라,
좋은 질문을 하기 위한 프레임워크

이다.