PROJECT 01 / CLOUD INFRASTRUCTURE & SECURITY
AWS 기반 게임 서비스 클라우드 인프라 구축
PlayBiscuit | AWS Cloud Infrastructure & Security
글로벌 멀티플레이 게임 서비스의 요구사항에 맞춰 AWS 인프라를 공동 설계하고, 클라우드 보안 영역을 구축한 프로젝트
| 항목 | 내용 |
|---|---|
| 기간 | 2025.11.18 ~ 2025.12.22 |
| 유형 | AI 클라우드 엔지니어 양성과정 팀 프로젝트 |
| 고객 시나리오 | 가상의 게임사 PlayBiscuit |
| 담당 | AWS 클라우드 보안 설계 및 구축 |
| 주요 기술 | AWS IAM, WAF, GuardDuty, Inspector, EventBridge, Lambda, KMS, S3, CloudTrail |
| 전체 인프라 | VPC, CloudFront, ALB/NLB, EKS, EC2 MySQL, DynamoDB, CloudWatch, AMP, Grafana |
01. 프로젝트 개요
PlayBiscuit는 글로벌 시장 진출을 준비하는 가상의 멀티플레이 온라인 액션 게임사입니다. 저지연 통신, 고가용성, 사용자 증가에 따른 확장, 보안과 데이터 보호, 게임 로그 모니터링을 지원하는 클라우드 환경이 필요했습니다.
팀원들과 고객 요구사항을 분석하고 AWS 전체 아키텍처를 공동 설계했습니다. 이후 인프라, WAS·DB, CI/CD, 로그·모니터링, 보안 영역으로 역할을 나눠 구축을 진행했습니다.
저는 보안을 맡아 IAM 권한 분리, WAF 규칙, GuardDuty 및 Inspector 탐지, Slack 알림, 로그 암호화와 백업 데이터 보호를 구성했습니다.
02. 요구사항과 설계
| 고객 요구사항 | 적용 방향 |
|---|---|
| 고가용성 | 서울 리전의 Multi-AZ 구성 |
| 저지연 | CloudFront를 통한 콘텐츠 배포, 트래픽 성격에 따른 로드 밸런서 활용 |
| 확장성 | Amazon EKS 기반 컨테이너 환경과 자동 확장 고려 |
| 데이터 처리 | 관계형 데이터는 EC2 기반 MySQL, 세션·랭킹 등은 DynamoDB 활용 |
| 관측성 | Grafana, Amazon Managed Service for Prometheus(AMP), CloudWatch 활용 |
| 보안 | IAM, WAF, Shield Advanced, GuardDuty, Inspector 적용 |
| 데이터 보호 | KMS 암호화, S3 보관, 별도 버킷 복제 및 접근 권한 분리 |
실제 구축에서는 교육 환경의 비용과 구현 시간을 고려해 초기 요구사항에 제시된 서비스 구성을 검토·조정했습니다. 예를 들어 데이터베이스는 RDS 대신 EC2 기반 MySQL을 사용했습니다. 전체 아키텍처는 팀 공동 산출물이며, 아래 보안 항목은 제가 담당한 영역입니다.
03. 전체 시스템 아키텍처
AWS 서울 리전(ap-northeast-2)에서 VPC를 구성하고 Public·Private Subnet과 Web·WAS·DB 영역을 분리했습니다. CloudFront와 ALB/NLB를 서비스 진입 경로에 배치했으며, 애플리케이션은 EKS 기반으로 구성했습니다.
관계형 데이터와 게임성 데이터를 MySQL과 DynamoDB로 구분하고, CloudWatch·AMP·Grafana를 활용해 인프라와 서비스 상태를 관찰하도록 구성했습니다. 보안 영역에서는 웹 요청 보호부터 계정 권한 관리, 탐지 이벤트 전파, 데이터 보관까지 고려했습니다.
04. 담당 업무 — 클라우드 보안
4.1 IAM 접근 제어와 권한 관리
프로젝트의 담당 영역에 따라 인프라, DB, 로그·모니터링, CI/CD, 보안 사용자 그룹을 구분했습니다. 주·부 담당자의 역할과 공통 작업 범위를 고려해 정책을 분리했으며, MFA 사용 강제와 Access Key 발급 제한 정책도 적용했습니다.
권한을 AWS 서비스 단위로만 구분했을 때 실제 업무가 막히는 문제가 있었습니다. DB 담당자는 MySQL을 설치·관리해야 했고, 모니터링 담당자는 Prometheus를 설치·관리해야 했습니다. 두 작업 모두 EC2 내부 접근이 필요했습니다.
이에 담당자의 EC2 내부 관리 작업을 위한 접근을 허용하고 인스턴스 유형 변경 및 종료 권한은 제한했습니다. 사용하지 않는 인스턴스를 중지할 수 있는 권한은 허용했습니다. 프로젝트 예산이 한정되어 있어 불필요한 EC2 컴퓨팅 비용을 줄이기 위한 결정이었습니다.
기본 권한으로 작업하기 어려운 경우에는 요청 사유와 필요한 권한을 확인해 수동으로 추가했습니다. 작업 완료 통보를 받으면 추가로 부여한 권한을 회수했습니다.
4.2 AWS WAF를 활용한 웹 서비스 보호
CloudFront에 AWS WAF를 연결해 요청이 애플리케이션으로 전달되기 전에 보안 규칙을 적용하도록 구성했습니다. AWS 관리형 규칙으로 일반적인 웹 취약점 및 악성 트래픽에 대응하고, 커스텀 규칙으로 무차별 대입 공격과 관리 도구 접근을 통제했습니다.
4.3 GuardDuty를 활용한 위협 탐지
GuardDuty를 활용해 AWS 환경에서 발생할 수 있는 악의적 활동을 탐지하도록 구성했습니다. 탐지 결과는 EventBridge와 Lambda를 거쳐 Slack으로 전달했습니다. 이를 통해 담당자가 AWS 콘솔 외부에서도 위협 탐지 알림을 확인할 수 있도록 했습니다.
이벤트 흐름: GuardDuty → EventBridge → Lambda → Slack
4.4 Inspector를 활용한 취약점 탐지
Inspector로 AWS 리소스의 소프트웨어 취약점을 탐지하고, 관련 리소스와 취약점 정보를 확인할 수 있도록 했습니다. 탐지 이벤트는 EventBridge와 Lambda를 통해 Slack으로 전달했습니다.
버전 업데이트로 보안 탐지 항목을 조치한 경험도 있으나 대상 이미지와 CVE, 업데이트 버전의 정확한 기록이 없어 별도의 해결 사례로 기재하지 않았습니다.
이벤트 흐름: Inspector → EventBridge → Lambda → Slack
4.5 로그 암호화와 백업 데이터 보호
보안 관련 데이터는 AWS KMS로 암호화하여 S3에 보관하도록 구성하고, CloudTrail을 활용해 감사 로그를 관리했습니다.
EC2 침해 시 백업 데이터까지 영향을 받을 위험을 고려하여 DB 백업을 별도 S3 버킷에 보관하고 접근 권한을 분리했습니다. 이를 통해 원본 인스턴스가 침해되더라도 복제된 백업 데이터로 피해가 확산될 가능성을 낮추고자 했습니다.
S3 복제는 별도 사본을 유지하기 위한 구성입니다. 객체 변경 전체가 차단되거나 백업의 무결성이 완전히 보장된다는 의미로 설명하지 않습니다.
05. Troubleshooting — IAM 권한 설계와 구축 업무 간 충돌
문제 상황
초기 IAM 설계에서는 각 담당자가 맡은 AWS 서비스와 리소스에만 접근하도록 권한을 분리했습니다. 그러나 실제 인프라 구축 과정에서는 하나의 서비스를 여러 담당자가 다른 목적으로 사용했습니다.
모니터링 담당자는 Prometheus 설치를 위해 EC2 내부에 접근해야 했고, DB 담당자도 MySQL 설치와 설정을 위해 동일한 유형의 권한이 필요했습니다. 초기 정책으로는 일부 구축 작업을 진행하기 어려웠습니다.
원인
업무 담당 영역과 AWS 서비스의 소유 관계를 중심으로 권한을 나누면서 실제 작업에 필요한 접근 방식을 충분히 반영하지 못했습니다. EC2 내부에서 소프트웨어를 관리하는 작업과 EC2 인스턴스 자체를 변경하거나 종료하는 작업도 명확히 구분할 필요가 있었습니다.
해결 과정
- DB 및 로그·모니터링 담당자가 지속적으로 수행할 EC2 내부 설치·관리 작업을 기본 접근 범위에 반영했습니다.
- 인스턴스 유형 변경과 종료 권한을 제한했습니다. 예산 관리를 위해 사용하지 않는 인스턴스를 중지하는 권한은 허용했습니다.
- 기본 권한으로 진행할 수 없는 작업은 요청 사유와 필요한 권한을 확인한 뒤 수동으로 추가했습니다.
- 팀원별 작업 완료 시점을 예측하기 어려워 고정 만료 시각을 설정하지 않았습니다. 작업 완료 통보를 받으면 부여한 추가 권한을 수동으로 회수했습니다.
결과
DB와 모니터링 담당자는 필요한 EC2 내부 작업을 진행할 수 있었고, 기본적인 업무별 권한 분리도 유지했습니다. 프로젝트 예산을 고려한 인스턴스 중지 권한과 고위험 인프라 변경 권한을 구분하여 운영했습니다.
배운 점과 개선 방향
IAM 권한은 서비스 이름이나 담당 영역만을 기준으로 나누기보다 실제 작업 단위와 위험도를 고려해 설계해야 한다는 점을 배웠습니다.
수동 권한 회수는 완료 통보가 누락되면 권한이 오래 남을 수 있다는 한계가 있습니다. 향후에는 역할 기반 임시 권한 전환, 승인 기록, 자동 만료, 정기적인 권한 검토를 적용하고자 합니다.
06. 구현 결과
| 담당 영역 | 확인 가능한 결과 |
|---|---|
| IAM | 업무별 사용자 그룹 구성, 공통 정책 분리, MFA 및 Access Key 제한 정책 |
| 권한 운영 | EC2 내부 관리 권한과 인프라 변경 권한 구분, 추가 권한 수동 부여·회수 |
| WAF | 관리형 규칙 및 커스텀 규칙을 적용한 Web ACL 구성 |
| GuardDuty | 위협 탐지 및 Slack 알림 연동 |
| Inspector | 취약점 탐지 및 Slack 알림 연동 |
| KMS·S3 | 보안 데이터 암호화 및 보관, DB 백업의 별도 버킷 복제와 접근 권한 분리 |
| CloudTrail | 감사 로그 관리 |
본 프로젝트는 가상의 고객 시나리오를 활용한 교육 프로젝트입니다. 실제 상용 서비스의 가용성이나 보안 대응 성과로 해석할 수 있는 수치, 측정하지 않은 개선율은 기재하지 않았습니다.
07. 회고
이번 프로젝트에서는 고객 요구사항에 맞게 여러 AWS 서비스를 연결하고, 실제로 구축하면서 설계상의 제약을 확인할 수 있었습니다. 보안 영역을 담당하며 접근 제어, 웹 서비스 보호, 위협 탐지, 취약점 관리, 알림, 백업 보호가 전체 인프라 운영과 연결된다는 점을 경험했습니다.
가장 의미 있었던 경험은 IAM 권한 정책을 실제 업무 흐름에 맞게 조정한 과정입니다. 담당 영역별로 권한을 분리한 뒤 발생한 작업 제약을 확인하고, 지속적으로 필요한 권한과 일시적인 권한을 구분해 관리했습니다. 비용이 한정된 프로젝트 특성도 권한 설계에 반영했습니다.
앞으로는 권한 관리 절차를 자동화하고, 보안 이벤트 확인부터 후속 조치까지 담당자의 승인과 기록을 남길 수 있는 운영 체계를 설계하고 싶습니다.