Projects
Projects
서비스가 안정적으로 운영되기까지, 클라우드 환경을 설계하고 다듬어온 경험들
Architecture & Build
5 projects
Landing Zone & Platform
3 projects
MSP Operations
10 systems
Cloud Security
4 projects
FinOps
4 projects
한화시스템 · AWS
그룹 공통 외부보안존 설계 및 IaC 표준화
2023.05 – 2023.09
AWS 멀티계정 환경의 인터넷 Inbound/Outbound 트래픽을 중앙 제어하는 그룹 공통 외부보안존을 설계·구축했습니다. 반복 연동 작업은 Terraform·Terragrunt 기반 IaC로 표준화했습니다.
🧭 공통 외부보안존 아키텍처
- 한화그룹 내 여러 계열사와 워크로드 계정이 공통으로 사용할 수 있는 AWS 외부보안존 구조를 설계했습니다.
- 인터넷 Inbound/Outbound 트래픽을 각 계정에서 개별 관리하지 않고, 공통 보안 영역에서 중앙 통제할 수 있도록 구성했습니다.
- Workload Account · Security Account · Shared Egress Account로 역할을 분리하고, Transit Gateway 기반 계정 간 연동 구조를 설계했습니다.
- 신규 서비스 계정이 추가되더라도 공통 외부보안존에 유연하게 연결·분리될 수 있도록 확장 가능한 구조로 구성했습니다.
- GWLB Endpoint, ALB/NLB, Route Table을 활용해 UTM·WAF 등 보안 솔루션을 경유하는 트래픽 흐름을 구현했습니다.
🏗️ Terraform·Terragrunt 기반 IaC 표준화
- 신규 서비스 계정 연동 시 반복되는 TGW 공유·승인, 라우팅 구성, Endpoint 연결 작업을 Terraform 코드로 자동화했습니다.
- 환경별 변수와 공통 모듈을 분리해 서비스 계정별 연동 구성을 재사용 가능한 형태로 표준화했습니다.
- Terragrunt를 활용해 계정·환경별 설정을 분리하고, 반복 배포 시 구성 일관성을 유지할 수 있도록 구조화했습니다.
- GitLab CI/CD 기반 배포 흐름과 Terraform state 관리 구조를 구성해 인프라 변경 작업의 재현성과 운영 효율성을 높였습니다.
⚙️ 성과
- 그룹 AWS 환경의 인터넷 트래픽을 중앙에서 통제할 수 있는 공통 보안 아키텍처를 구축했습니다.
- 서비스 계정별 외부보안존 연동 작업을 표준화해 반복 작업 부담을 줄였습니다.
- 외부보안존 구축 및 IaC 자동화 경험을 신입사원 1주년 프로젝트 HPMP에서 발표해 예선 및 본선 1위를 수상했습니다.
핵심 설계 관점
- 그룹사·계열사·워크로드 계정 확장을 고려한 공통 보안존 구조
- 인터넷 트래픽 중앙 통제 및 보안 솔루션 경유 구조
- 반복 연동 작업의 IaC 표준화
Award
2025 한화시스템
신입사원 1주년 프로젝트 HPMP
최우수상 · 1위 수상
그룹 공통 외부보안존 표준화 및 IaC 기반 반복 작업 개선 성과
한화비전 · Azure
PIM/DAM 플랫폼 클라우드 인프라 구축
2025.03 – 2025.07
Azure App Service 기반 PIM/DAM/Keycloak 서비스를 구성하고, ACR·Storage·Azure SQL·Front Door와 사내 DNS·보안존 연계를 통해 서비스 인프라를 구축했습니다.
🧭 프로젝트 개요
- 한화비전의 제품 정보 관리(PIM) 및 디지털 자산 관리(DAM) 시스템을 Azure 기반 클라우드 환경에 구축한 프로젝트입니다.
- PIM/DAM 서비스와 인증을 위한 Keycloak을 App Service 기반으로 배포하고, ACR, Storage, Azure SQL, Front Door 등 핵심 Azure 리소스를 연동했습니다.
- Azure Front Door와 Custom Domain, 사내 DNS를 연계해 외부 사용자 접근 경로를 구성하고, 내부·외부보안존과 연결되는 네트워크 흐름을 설계했습니다.
🏗️ 클라우드 인프라 설계 및 배포
- PIM Frontend / Backend, DAM Frontend / Backend, Keycloak 서비스를 Azure App Service 기반으로 구성했습니다.
- 서비스별 역할에 따라 App Service를 분리하고, 배포 이미지 관리를 위해 Azure Container Registry(ACR)를 연동했습니다.
- 정적 콘텐츠 및 파일 저장을 위한 Azure Storage, 데이터 관리를 위한 Azure SQL Database를 구성했습니다.
🔐 네트워크 및 서비스 접근 구조 구성
- 외부 사용자의 서비스 접근은 Azure Front Door를 통해 수신되도록 구성하고, HTTPS 기반으로 각 서비스에 전달되도록 라우팅 구조를 설계했습니다.
- App Service 및 Storage에 Custom Domain을 적용하고, 사내 DNS 등록 절차를 함께 진행해 실제 서비스 도메인 기반 접근이 가능하도록 구성했습니다.
- 내부 시스템 연계, DNS 흐름, 서비스별 접근 제어를 고려하여 운영 환경에 적합한 네트워크 구조를 구성했습니다.
⚙️ 성과 및 의미
- Azure 기반 PIM/DAM 플랫폼 인프라를 설계부터 구축까지 직접 수행하며 클라우드 서비스 구축 경험을 확장했습니다.
- App Service, ACR, Storage, Azure SQL, Front Door 등 Azure 주요 서비스를 하나의 서비스 아키텍처로 연계해 실무에 적용했습니다.
- 고객, 개발팀, 클라우드팀 간 요구사항을 조율하며 인프라 설계, 리소스 구성, 도메인 연동, 보안 네트워크 검토까지 프로젝트 전 과정을 수행했습니다.
- 일정 내 인프라 환경을 오픈하며 서비스 구축 품질과 일정 준수 성과를 확보했습니다.
PIM/DAM Azure Service Architecture
내부망, Hybrid Security Zone, Azure Common Landing Zone, PIM/DAM 구독의 PROD·DEV 구성을 포함한 실제 서비스 구성도입니다.
핵심 설계 관점
- App Service · PIM/DAM/Keycloak 서비스 분리
- External Access · Front Door + DNS 경로 구성
- Azure Resources · ACR·Storage·Azure SQL 연계
- Security Zone · 내부·외부보안존 흐름 검토
한화솔루션 큐셀 · Azure / Power BI
연결재무 BI 데이터 플랫폼 인프라 구축
2025.01 – 2025.04
연결재무 업무 자동화와 경영 데이터 시각화를 위해 Azure SQL Database와 Power BI 기반 BI 인프라를 구축하고, RPA → DB → Power BI 데이터 흐름을 설계했습니다.
🧭 프로젝트 개요
- 연결재무 업무의 반복 작업을 자동화하고, 경영 데이터를 시각화하여 의사결정 효율을 높이기 위한 BI 인프라 구축 프로젝트입니다.
- 기존 사내 RPA 시스템에서 생성되는 데이터를 Azure SQL Database에 적재하고, Power BI를 통해 시각화할 수 있도록 RPA → Azure SQL DB → Power BI로 이어지는 엔드 투 엔드 데이터 흐름을 설계했습니다.
- 신규 Azure 구독 내에 Private Endpoint 기반 Azure SQL Database를 구성하고, 내부보안존과 연동하여 보안 정책을 준수하는 데이터 연계 환경을 구현했습니다.
🏗️ 클라우드 인프라 및 보안 연동 설계
- 신규 Azure 구독을 생성하고, 해당 구독 내에 Azure SQL Database를 Private 환경으로 구성했습니다.
- DB 접근은 Public Access를 제한하고, Private Endpoint를 통해 내부 네트워크에서만 접근 가능하도록 설계했습니다.
- NSG, Firewall, RBAC 설정을 적용하여 보안 정책 기반의 DB 접근 제어를 구성하고, 운영 환경에서 필요한 최소 권한과 통신 경로를 함께 검토했습니다.
🔐 내부보안존 기반 멀티 구독 연동
- 기존 RPA 서버가 위치한 Azure 구독과 신규 BI DB 구독은 동일 내부보안존을 공유하는 구조로 설계했습니다.
- 이를 통해 별도 VNet Peering 없이도 내부보안존을 통해 RPA 서버와 신규 DB 간 통신이 가능하도록 구성했습니다.
- 구독 간 역할과 권한은 분리하되, 필요한 통신 경로와 운영 권한은 RBAC 기준으로 정리하여 보안성과 운영 편의성을 함께 확보했습니다.
⚙️ RPA → DB → Power BI 데이터 흐름 구성
- 기존 RPA 서버에서 생성된 데이터를 신규 Azure SQL Database에 적재하고, Power BI가 해당 DB를 조회해 경영 데이터를 시각화할 수 있도록 데이터 흐름을 구성했습니다.
- Power BI는 VNet Data Gateway를 통해 내부 네트워크 상의 Private DB에 접근하도록 설정했습니다.
- Public 경로를 열지 않고도 Power BI 기반 시각화 환경을 구현할 수 있도록 연동 흐름을 설계하고 테스트했습니다.
✅ 성과 및 의미
- RPA → Azure SQL DB → Power BI로 이어지는 엔드 투 엔드 데이터 흐름을 안정적으로 구성했습니다.
- 내부보안존 기반 멀티 구독 연동 구조를 통해 보안 정책을 준수하면서도 유연한 데이터 통신이 가능한 BI 인프라 환경을 구현했습니다.
- Azure SQL Database, Private Endpoint, NSG, RBAC, Power BI VNet Data Gateway를 함께 적용하며 데이터 플랫폼 구축 역량을 확장했습니다.
- Power BI와 내부 DB 연동 설정을 문서화해 팀 내 기술 확산과 유사 프로젝트 대응에 기여했습니다.
Qcells BI Data Flow
온프레미스/IDC, 내부망 구간, Azure SQL 기반 업무·BI 시스템, 외부망 구간 및 Power BI 연계 흐름을 포함한 BI 구성도입니다.
RPA Server
기존 Azure 구독 · 연결재무 업무 자동화 데이터 생성
↓
Azure SQL Database
신규 Azure 구독 · Private Endpoint 기반 데이터 적재
↓
Power BI
VNet Data Gateway를 통한 내부망 DB 조회 및 시각화
Internal Security Zone
동일 내부보안존을 공유하는 멀티 구독 구조로, 별도 Peering 없이 RPA 구독과 BI DB 구독 간 보안 통신 구성
Private Endpoint
Public Access 제한 및 내부망 기반 DB 접근
NSG / Firewall
보안 정책 기반 통신 제어
RBAC
구독 간 권한 분리 및 운영 권한 관리
Manual
Power BI 내부 DB 연동 설정 문서화
핵심 설계 관점
- E2E Data Flow · RPA → Azure SQL → Power BI
- Private Endpoint · Azure SQL DB 접근 통제
- Multi-Subscription · 내부보안존 기반 연동
- VNet Data Gateway · 내부망 DB 조회
한화시스템/방산 · AWS
Secuaider 솔루션 인프라 구축
2025.07 – 2025.10
AWS 기반 솔루션 인프라를 구축하고, VPC·보안그룹·WAF 등 서비스 운영에 필요한 네트워크·보안 구성을 정리했습니다.
🧭 프로젝트 개요
- 한화시스템/방산의 선박보안솔루션 SecuAider 서비스 인프라를 AWS 기반으로 구축한 프로젝트입니다.
- 서비스는 AWS ECS Cluster 위에서 컨테이너 기반으로 운영되도록 구성하고, ALB를 통해 외부 요청을 ECS 서비스로 전달하는 구조를 설계했습니다.
- 서비스 개발 계정과 공통 인프라 계정을 분리해, 서비스 리소스와 공통 네트워크·보안 리소스를 역할에 맞게 관리할 수 있도록 구성했습니다.
🏗️ ECS 기반 서비스 구성
- SecuAider 서비스는 ECS Service와 Task Definition 기준으로 구성하고, 주요 기능이 독립적인 컨테이너 서비스로 운영될 수 있도록 설계했습니다.
- 서비스 내부 연동은 Cloud Map / Route 53 기반 Service Discovery를 활용해 컨테이너 간 API 호출이 안정적으로 이루어지도록 구성했습니다.
- 데이터 저장소는 Aurora Database와 연계해 서비스 운영에 필요한 데이터를 관리하도록 구성했습니다.
⚙️ 배포 및 운영 구조
- 컨테이너 이미지는 Amazon ECR에 저장하고, AWS CodePipeline을 통해 ECS 서비스로 배포되는 흐름을 구성했습니다.
- 이미지 빌드, 배포 승인, ECS 반영 흐름을 정리해 서비스 배포와 운영 기준을 표준화했습니다.
- 외부 접근과 아웃바운드 통신은 보안 장비와 네트워크 통제 구간을 경유하도록 설계해 서비스 운영 환경의 보안성을 강화했습니다.
✅ 성과 및 의미
- ECS, ALB, ECR, CodePipeline, Cloud Map, Route 53, Aurora를 연계해 컨테이너 기반 서비스 인프라를 구축했습니다.
- Service Discovery와 Pipeline 기반 배포 구조를 적용하며, AWS 기반 애플리케이션 운영·배포 아키텍처 설계 경험을 확장했습니다.
- 방산 서비스 환경에 필요한 보안 네트워크 흐름을 고려해, 서비스 실행 구조와 운영 통제 구조를 함께 설계했습니다.
핵심 설계 관점
- ECS Service · 컨테이너 기반 서비스 운영
- ALB Routing · 외부 요청 수신 및 서비스 전달
- Service Discovery · Cloud Map / Route 53 기반 내부 연동
- CI/CD Deploy · ECR / CodePipeline 배포 흐름
- Secure Network Flow · 보안 구간 경유 트래픽 구조
㈜한화 · AWS / MSP Transition
IS 홈페이지 / HATS 솔루션 보안 아키텍처 재구축 및 MSP 이관
2025.09 – 2026.02
외부 MSP에서 운영 중이던 IS 홈페이지와 HATS 솔루션을 한화시스템 MSP 운영 체계로 전환하며, 기존 AWS 환경을 그룹 보안 기준에 맞춰 재구성했습니다. VPC·Subnet·Security Group·Public IP·IP 대역을 정비하고, 외부보안존 기반 표준 아키텍처로 서버와 DB를 단계적으로 이관했습니다.
🧭 프로젝트 개요
- ㈜한화의 IS 홈페이지와 HATS 솔루션은 각각 별도 시스템으로 운영되던 AWS 기반 서비스였습니다.
- 전사 클라우드 보안진단 과정에서 네트워크·보안 구성이 그룹 표준 기준과 맞지 않는 부분이 확인되었고, 운영 주체를 한화시스템 MSP로 전환하면서 아키텍처를 함께 개선했습니다.
- 단순 운영 이관이 아니라, 기존 리소스를 그대로 넘겨받는 대신 그룹 표준 보안 아키텍처 기준으로 재구성한 뒤 단계적으로 이관하는 방식으로 수행했습니다.
🔁 외부 MSP → 한화시스템 MSP 운영 전환
- 기존 외부 MSP 관리 환경에서 한화시스템 MSP 운영 체계로 전환하기 위해 계정, 결제, 비용 정산, 운영 권한 등 이관 항목을 정리했습니다.
- AWS Organizations 및 운영 관리 기준을 한화그룹 표준에 맞게 재정리하고, 기존 운영 환경의 리소스와 비용 구조를 확인했습니다.
- 운영 주체 변경 과정에서 서비스 영향이 발생하지 않도록, 기존 환경과 신규 표준 환경을 비교하며 이관 범위와 순서를 정리했습니다.
🏗️ 그룹 보안 기준 기반 아키텍처 재구성
- 기존 환경의 Public IP 사용, Subnet 분리, Security Group 정책 등을 점검하고 그룹 보안 기준에 맞게 재정비했습니다.
- VPC, Subnet, Security Group, IP 대역, Public IP 사용 기준을 다시 정리하고, 서비스 역할에 맞는 네트워크 영역으로 리소스를 배치했습니다.
- 외부 사용자의 접근은 외부보안존을 경유하도록 구성하고, 서버와 DB는 역할에 따라 분리된 네트워크 영역으로 배치하는 구조를 설계했습니다.
🚚 단계적 리소스 이관
- 서비스 중단 리스크를 줄이기 위해 신규 표준 아키텍처의 기본 구조를 먼저 구성한 뒤, 서버와 DB를 단계적으로 이관했습니다.
- 각 서버의 역할, 통신 경로, 보안그룹 정책, 외부 접근 여부를 확인하며 대상 리소스를 순차적으로 이전했습니다.
- 이관 과정에서 불필요한 Public IP 노출을 줄이고, 서비스별 통신 경로와 접근 제어 기준을 재정리했습니다.
✅ 성과 및 의미
- 외부 MSP에서 운영되던 기존 AWS 환경을 한화시스템 MSP 운영 체계로 안정적으로 전환했습니다.
- 보안진단 결과를 기반으로 VPC, Subnet, Security Group, Public IP, IP 대역을 재정비하고, 그룹 표준 외부보안존 구조에 맞춘 운영 환경으로 개선했습니다.
- 단순 인수인계가 아니라 운영 이관과 보안 아키텍처 재구축을 함께 수행한 프로젝트로, 클라우드 보안진단 결과를 실제 개선 과제로 연결한 경험입니다.
핵심 설계 관점
- MSP Transition · 외부 MSP → 한화시스템 MSP 운영 전환
- Account / Billing · 계정·결제·비용 정산 체계 정리
- Security Re-Architecture · 그룹 표준 보안 구조로 재구성
- Network Segmentation · VPC·Subnet·IP 대역 정비
- Access Control · Public IP·Security Group 기준 개선
- Phased Migration · 서버·DB 단계적 이관
Project Focus
보안진단에서 확인된 개선 필요 사항을 실제 아키텍처 재구축과 MSP 운영 이관 과제로 연결한 사례입니다. 운영 주체 전환, 비용 정산, 계정 관리, 네트워크 재설계, 단계적 리소스 이전을 함께 수행했습니다.
한화그룹 · Cloud Governance
Zero Trust 기반 조직·접근 통제 구조 설계 및 운영
AWS Control Tower 기반 OU 구조와 Azure 구독 운영 구조를 설계하고, 다중 계정 환경의 운영 기준과 접근 통제 체계를 정립했습니다. Okta·CyberArk 기반 SAML SSO PoC와 GCP/Google Workspace 초기 설정을 통해 멀티클라우드 조직·계정 거버넌스 기반을 검토했습니다.
🏢 그룹 클라우드 조직 구조 설계
- 한화그룹의 여러 계열사와 워크로드 계정을 통합 관리하기 위해 AWS Control Tower 기반 그룹 거버넌스 구조를 설계했습니다.
- 분산되어 있던 AWS Organizations 구조를 정리하고, Log & Audit / Shared / 계열사별 OU로 역할을 분리해 그룹 공통 보안·네트워크·운영 기준을 적용할 수 있는 기반을 마련했습니다.
- Shared OU에는 내부보안존, 외부보안존, 공통 운영 계정을 배치해 Direct Connect, Transit Gateway, WAF, Firewall, Backup, Datadog Endpoint, Terraform/Packer, GitLab CI/CD 등 그룹 공통 인프라 운영 기반을 정리했습니다.
- Azure는 OU 개념이 아닌 구독 단위 운영 구조를 기준으로, 보안·네트워크·워크로드 성격에 따라 구독을 분리해 운영할 수 있도록 구조를 정리했습니다.
🔐 Okta·CyberArk 기반 SAML SSO PoC
- MSP 운영 대상의 AWS, Azure, Datadog, Slack, HCMP 등 다양한 클라우드·SaaS 계정을 중앙에서 관리하기 위해 Okta와 CyberArk 기반 SAML 연동 PoC를 수행했습니다.
- AWS IAM Identity Center, Azure, Datadog, Slack, HCMP 등 주요 서비스와의 SAML 연동을 테스트하고, 사용자 인증 흐름, 속성 매핑, 역할 기반 권한 부여 구조를 검증했습니다.
- PoC는 성공적으로 수행했으나, 한화그룹 전체 임직원이 이미 Microsoft 365 및 Entra ID 기반 인증 체계를 사용하고 있어 일부 클라우드 사용자만 별도 IdP로 이관하기 어려운 제약이 있었습니다.
- 이에 따라 별도 IdP 상용화보다는 기존 Microsoft 기반 인증 체계를 고도화하는 방향으로 후속 검토했습니다.
G GCP·Google Workspace 초기 설정
- AI 및 GCP 활용 가능성 검토를 위해 한화그룹 공통 도메인인 @hanwha.com 기준 Google Workspace Super Admin 권한 확보와 초기 설정을 지원했습니다.
- 그룹 내 여러 회사가 동일 도메인을 사용하는 구조를 고려해, 회사별 사용자 관리가 가능하도록 Google Workspace 조직 구조를 초기 구성했습니다.
- GCP 조직 생성을 위한 도메인 검증, 관리자 권한 구조, 사용자 관리 기준을 정리하고, 향후 GCP 사용 확대 시 계열사별 사용자와 프로젝트를 체계적으로 관리할 수 있는 기반을 마련했습니다.
✅ 성과 및 가치
- AWS, Azure, GCP/Google Workspace를 포함한 멀티클라우드 환경에서 그룹 단위 조직·계정 관리 구조를 설계했습니다.
- AWS Control Tower 기반 OU 구조와 Azure 구독 기준 운영 구조를 통해 계열사·워크로드별 클라우드 자산 관리 기반을 마련했습니다.
- Okta·CyberArk 기반 SAML SSO PoC를 통해 클라우드·SaaS 통합 인증 구조를 검증하고, 대규모 그룹사 환경에서 IdP 도입 시 고려해야 할 조직·도메인·기존 인증 체계 제약을 경험했습니다.
- GCP/Google Workspace 초기 설정을 통해 @hanwha.com 단일 도메인 기반 그룹 사용자 관리 구조를 검토했습니다.
Cloud Governance
Multi-Cloud Organization Standard
AWS Control Tower, Azure 구독 운영 구조, GCP/Google Workspace 초기 설정을 함께 검토하며 그룹 단위 클라우드 조직·계정 운영 기준을 정리했습니다.
핵심 설계 관점
AWS Control Tower · 그룹 OU 거버넌스 구조
Shared OU · 보안존·네트워크·공통 운영 계정 분리
Azure Subscription · 보안·네트워크·워크로드 기준 구독 분리
SAML SSO PoC · Okta·CyberArk 기반 통합 인증 검토
Google Workspace · @hanwha.com 단일 도메인 기반 조직 관리
한화그룹 · AI Landing Zone
Private AI 리소스 사용을 위한 클라우드 표준 아키텍처 수립
사내 AI 서비스 테스트와 PoC 수요가 증가하면서, AWS Bedrock과 Azure OpenAI 등 AI 리소스를 퍼블릭 노출 없이 사용할 수 있는 Private AI 표준 아키텍처를 수립했습니다. 클라우드별 사설 접근 구조, 네트워크 대역, 계정·구독, VNet/VPC, Subnet, Private Endpoint/VPC Endpoint 기준을 정리했습니다.
🧭 프로젝트 개요
- 사내 AI 서비스 테스트와 PoC 수요가 증가하면서 AWS Bedrock, Azure OpenAI 등 클라우드 기반 AI 리소스 사용이 확대되었습니다.
- 초기에는 각 팀이 개발·테스트 목적으로 AI 리소스를 개별 구성할 가능성이 있었고, 이 경우 퍼블릭 노출, 네트워크 통제 미흡, 계정·구독 구조 불일치 등의 보안 리스크가 발생할 수 있었습니다.
- 이에 따라 개발·테스트 목적의 AI 리소스라도 표준 네트워크 구조 안에서 안전하게 사용할 수 있도록 Private AI 표준 Landing Zone 아키텍처를 수립했습니다.
🏗️ 표준 아키텍처 구성
- AI 서비스용 네트워크 대역을 정의하고, 클라우드 계정·구독 구성 시 해당 대역과 사내망 연동 기준을 반영할 수 있도록 구조를 정리했습니다.
- Azure 환경에서는 VNet, Subnet, Azure OpenAI, Private Endpoint 구성을 기준으로 사내망에서 프라이빗하게 AI 리소스에 접근할 수 있는 구조를 설계했습니다.
- AWS 환경에서는 VPC, Subnet, Amazon Bedrock, VPC Endpoint/PrivateLink 기반으로 퍼블릭 인터넷을 경유하지 않는 사설 접근 구조를 검토했습니다.
- 각 클라우드에서 AI 리소스가 배치될 네트워크 영역을 분리하고, 개발·테스트 환경에서도 기본적으로 Private Access 구조를 따르도록 표준 운영 기준을 마련했습니다.
🔐 설계 기준
- Public Access 제한 · AI 리소스의 외부 노출 최소화
- Private Access · Private Endpoint / VPC Endpoint 기반 사설 접근
- Network Segmentation · VNet/VPC 및 Subnet 역할 분리
- Hybrid Connectivity · 사내망·전용선 기반 내부 접근 경로 고려
- Multi-Cloud Standard · AWS Bedrock / Azure OpenAI 공통 기준 정리
- AI Governance · 개발·테스트 환경에도 기본 보안 기준 적용
✅ 성과 및 의미
- 팀별로 개별 생성될 수 있는 AI 리소스를 공통 Landing Zone 구조 안에서 사용할 수 있도록 기준을 마련했습니다.
- AWS와 Azure 환경 모두에서 AI 리소스를 퍼블릭 인터넷에 노출하지 않고 사용할 수 있는 Private AI 접근 표준을 정리했습니다.
- 개발·테스트 목적의 AI 서비스라도 네트워크, 계정·구독, Subnet, Private Endpoint/VPC Endpoint 기준을 적용하도록 하여 AI 리소스 사용 확산에 대비한 보안 기반을 마련했습니다.
- 향후 사내 AI 서비스 PoC 및 테스트 환경에 공통 적용 가능한 멀티클라우드 Private AI Landing Zone 기반을 수립했습니다.
Private AI Landing Zone
Multi-Cloud Private AI Standard
AWS Bedrock과 Azure OpenAI를 모두 고려해, 개발·테스트 목적의 AI 리소스도 퍼블릭 노출 없이 사설 접근 경로로 사용할 수 있도록 표준 구조를 정리했습니다.
핵심 설계 관점
Private AI Standard · AWS Bedrock / Azure OpenAI 공통 기준
Private Access · Private Endpoint / VPC Endpoint 기반 접근
Network Segmentation · VNet/VPC 및 Subnet 역할 분리
Hybrid Connectivity · 사내망·전용선 기반 내부 접근
AI Governance · 개발·테스트 환경 보안 기준 적용
Private AI Flow
AI ServiceAWS Bedrock · Azure OpenAI
Network ZoneVPC/VNet · Subnet 역할 분리
Private AccessVPC Endpoint · Private Endpoint
Internal Access사내망·전용선 기반 프라이빗 사용
한화그룹 · Policy Governance
클라우드 보안진단 기준 기반 정책 가드레일 구성
클라우드 보안진단 기준을 AWS SCP·Config 및 Azure Policy로 코드화해 조직 단위 정책 가드레일을 구성했습니다. 위반 항목 감지와 정책 기반 운영의 기준을 마련했습니다.
🧭 보안진단 기준 기반 정책 설계
- 클라우드 보안점검 TF에 참여하며 AWS·Azure 환경에 적용할 클라우드 보안진단 기준을 정리했습니다.
- 수립된 점검 기준을 실제 운영 환경에서 지속적으로 관리하기 위해, CSP별 네이티브 정책 기능을 활용한 정책 가드레일 구성을 검토했습니다.
- 계정·권한·리소스 생성·태그·로깅·네트워크 등 기본 보안 기준을 중심으로 정책 항목을 정의했습니다.
- 단순 수기 점검이 아니라, 클라우드 환경 자체에서 위반 항목을 탐지하고 확인할 수 있는 구조를 목표로 했습니다.
AWS SCP
조직/OU 단위에서 계정·권한·리소스 생성 기준을 제한하거나 관리하는 정책 가드레일
AWS Config
리소스 구성 상태와 보안 기준 위반 여부를 지속적으로 감지·가시화하는 기준
Azure Policy
구독 단위 리소스 생성 기준과 보안 설정 기준을 정책으로 관리하는 구조
💡 설계 포인트 · 별도의 CSPM 솔루션을 도입한 것이 아니라, 클라우드 보안진단 기준을 AWS SCP·Config, Azure Policy 등 CSP 네이티브 정책으로 코드화해 조직 단위 가드레일로 적용했습니다.
⚙️ AWS SCP·Config / Azure Policy 구성
- AWS 환경에서는 Organizations 단위의 SCP와 AWS Config를 활용해 계정 및 리소스 기준 위반 여부를 탐지할 수 있도록 구성했습니다.
- Azure 환경에서는 Azure Policy를 활용해 구독 단위 리소스 생성 기준과 보안 설정 기준을 관리할 수 있도록 구성했습니다.
- 정책은 운영 영향도를 고려해 대부분 차단이나 자동 수정이 아닌 감지 중심으로 적용했습니다.
- 일부 필수 기준에 대해서는 리소스 생성 제한이나 기본 설정 준수 여부를 확인할 수 있도록 정책을 구성했습니다.
- 보안진단 기준을 정책 코드로 관리해, 계정이나 구독이 늘어나더라도 동일한 기준을 반복 적용할 수 있도록 했습니다.
👀 가시성 및 운영 기준 확보
- 각 계정·구독별 보안 기준 위반 항목을 확인할 수 있도록 정책 기반 가시성을 확보했습니다.
- 보안진단 시 확인해야 하는 항목을 CSP 정책 결과와 연결해, 점검 기준과 운영 환경 간의 정합성을 높였습니다.
- 수기 점검 중심의 보안진단을 보완하고, 지속적으로 위반 여부를 확인할 수 있는 운영 기반을 마련했습니다.
- 조직 단위로 동일한 클라우드 보안 기준을 적용할 수 있도록 정책 관리 구조를 표준화했습니다.
✅ 성과
- 클라우드 보안진단 기준을 실제 운영 환경에 적용 가능한 정책 가드레일 형태로 전환했습니다.
- AWS SCP·Config, Azure Policy를 활용해 멀티클라우드 환경의 보안 기준 위반 항목을 감지할 수 있는 구조를 구성했습니다.
- 계정·구독 확장 시에도 동일한 보안 기준을 반복 적용할 수 있는 거버넌스 기반을 마련했습니다.
- 보안점검 기준, 정책 코드, 운영 가시성을 연결해 클라우드 보안진단의 지속 관리 체계를 강화했습니다.
한화컨버전스 · AWS
2022.10 — 2023.12
태양광 모니터링 시스템 운영
태양광 발전 모니터링 시스템의 AWS 인프라를 운영하며, EC2/RDS 기반 운영 환경의 안정성과 리소스 상태를 관리했습니다.
한화시스템 · AWS
2022.12 — 2026.03
블록체인 Kaia 노드 운영
AWS 기반 블록체인 Kaia 노드 인프라를 운영하며, Kaia 운영 주체와 협업해 노드 상태 및 Datadog 메트릭 연동 구성을 관리했습니다.
한화모멘텀 · AWS
2023.03 — 2024.05
ESG 스마트팩토리 (HES)
ESG 스마트팩토리 HES 시스템의 AWS 서버리스 인프라를 구축·운영하고, AWS Code Series 기반 CI/CD 구성을 지원했습니다.
(주)한화 · AWS
2023.08 — 2026.03
DAP 플랫폼 운영
Data Analysis Platform(DAP)의 AWS 인프라를 운영하며, Databricks와 AWS SSO 연동, DAP 계정 및 권한 관리까지 포함한 복합 운영을 수행했습니다.
한화정밀기계 · AWS
2024.12 — 2026.03
CRM 시스템 운영
CRM 시스템의 AWS 인프라를 운영하며, 내·외부보안존과 연계된 복합 네트워크 구조에서 EC2 기반 리소스와 트래픽 흐름을 점검했습니다.
두산건설 · Azure
두산건설 홈페이지 / 위브 홈페이지 운영
2022.11 – 2026.03
Azure 기반 홈페이지 운영 환경을 담당하며, AGW, Web/WAS, DB, Load Balancer 중심의 서비스 운영을 수행했습니다. 두산건설 ISMS 심사 시 클라우드 담당자로 인터뷰와 개선사항 조치를 함께 진행했습니다.
한화비전 · Azure
2022.11 — 2026.03
홈페이지 & InterfaceHub 운영
한화비전 공식 홈페이지 및 InterfaceHub 글로벌 플랫폼의 Azure 인프라를 운영하며, App Service/CDN 기반 서비스 운영을 지원했습니다.
한화비전 · Azure
2025.07 – 2026.03
PIM/DAM 솔루션 운영
PIM/DAM 솔루션의 Azure 인프라를 운영하고, App Service 및 DB 기반 개발·운영 환경과 서비스 변경 대응을 지원했습니다.
대한산업안전협회 · NCP
2024.01 — 2026.03
교육 플랫폼 운영
온라인 교육 플랫폼의 NCP 인프라를 운영하며, CDN 및 Media Service 기반 콘텐츠 서비스 운영을 지원했습니다.
한화금융 7개사 · NCP
2025.03 — 2026.03
新HR 솔루션 클라우드 구축 및 운영
한화금융그룹 7개사 통합 HR 시스템의 NCP 인프라를 구축·운영하고, 금융권 클라우드 이용신고에 필요한 인프라 현황 및 운영 자료를 정리했습니다.
한화그룹 · Cloud Security Assessment
전사 클라우드 보안진단 체계 수립 및 고도화
AWS·Azure·NCP 대상 전사 클라우드 보안진단 기준과 체크리스트를 정리하고, 계열사 현장 실사를 수행했습니다. 이후 경험을 바탕으로 웹 기반 진단 페이지 프로토타입으로 고도화했습니다.
🧭 전사 공통 클라우드 보안 기준 수립
- AWS·Azure·NCP 환경을 대상으로 전사 공통 클라우드 보안진단 기준과 보안 가이드북을 정리했습니다.
- 계정·권한, 네트워크 접근통제, 데이터 암호화, 로그·모니터링, 백업·복구 등 주요 보안 영역을 기준으로 점검 항목을 구성했습니다.
- 당시 점검은 엑셀 기반 체크리스트를 중심으로 진행했으며, 항목별 평가 기준과 운영 증적 기준을 정리했습니다.
- 계열사별 클라우드 운영 환경에 공통 적용할 수 있는 기준을 마련하는 것을 목표로 했습니다.
🏢 계열사 클라우드 보안 실사 수행
- 한화그룹 계열사 클라우드 환경을 대상으로 현장 방문 기반 보안 실사를 수행했습니다.
- 각 회사의 클라우드 콘솔 설정, 계정·권한 구조, 네트워크 구성, 로깅·모니터링, 백업 설정, 운영 증적을 확인했습니다.
- 점검 결과를 기반으로 보안 취약 영역과 개선 필요 항목을 도출했습니다.
- IAM 구조 개편, 보안존 설계, 정책 거버넌스 강화 등 후속 개선 방향을 제시했습니다.
- 일부 MSP 미수행 계열사의 경우, 보안점검 결과를 계기로 후속 클라우드 운영·개선 과제로 연결되는 사례도 있었습니다.
💡 개인 고도화: 웹 기반 진단 페이지 프로토타입
- 퇴사 이후, 기존 엑셀 기반 점검 방식의 한계를 보완하기 위해 보안진단 항목과 평가 방식을 웹 기반 점검 페이지 형태로 개인 고도화했습니다.
- AWS·Azure 기준을 분리해 관리하고, 체크리스트·통계·원문 관리 화면을 통해 점검 현황을 구조적으로 확인할 수 있도록 구성했습니다.
- 이 작업은 회사 산출물이 아니라, 실무 경험을 바탕으로 “이런 방식이면 더 효율적으로 점검할 수 있겠다”는 관점에서 개인적으로 구현한 개선 프로토타입입니다.
✅ 성과 및 의미
- 전사 공통 클라우드 보안 기준을 수립하고, 실제 계열사 보안 실사까지 수행한 경험입니다.
- 보안점검 결과를 단순 보고서로 끝내지 않고, IAM·네트워크·정책 거버넌스 개선 방향으로 연결했습니다.
- 엑셀 기반 점검 경험을 바탕으로 반복 가능한 웹 기반 진단 구조까지 개인적으로 확장하며, 보안진단 체계의 운영성과 가시성을 개선하는 방향을 검토했습니다.
personal-prototype / cloud-security-assessment
🛡 클라우드 보안진단 통합
개요
체크리스트
통계
클라우드관리체계 수준진단
AWS·Azure 기준 분리 · 체크리스트 · 통계 · 원문 관리 구조
SEC-001퍼블릭 액세스 차단Y
IAM-002관리자 계정 MFA 적용Y
LOG-003감사 로그 보관 설정Y
대표 점검 항목 예시
SEC-001
퍼블릭 액세스 차단 여부 점검
확인 방법 · 스토리지, VM, DB 등 주요 리소스의 Public Access 설정 및 외부 노출 여부를 콘솔 설정과 운영 증적으로 확인
평가 기준 · 업무상 승인된 예외를 제외하고 외부 공개 설정이 제한되어 있으며, 접근 통제 근거가 확인되는 경우 양호
IAM-002
관리자 계정 MFA 적용 여부
확인 방법 · 관리자 권한 계정, 루트/최고권한 계정, 콘솔 접근 계정의 MFA 적용 여부와 계정 관리 절차 확인
평가 기준 · 관리자 계정에 MFA가 적용되어 있고, 계정 발급·회수·권한 변경 이력이 관리되는 경우 양호
핵심 설계 관점
전사 공통 클라우드 보안 기준 수립
AWS·Azure·NCP 멀티클라우드 점검 체계화
현장 실사 결과 기반 IAM·보안존·정책 거버넌스 개선 방향 제시
엑셀 기반 점검 경험을 웹 기반 프로토타입으로 개인 고도화
한화그룹 · MSP Observability
Datadog 기반 MSP 모니터링 및 보안 이벤트 체계 구축
MSP 고객사 환경에 Datadog 기반 표준 모니터링 체계를 구축했습니다. 클라우드 계정 Integration, Agent 설치, 대시보드 구성, Monitor 설정, CSPM·Cloud SIEM 초기 세팅까지 직접 수행하며 운영·보안 이벤트를 통합 모니터링할 수 있는 기반을 마련했습니다.
🧭 Datadog 기반 MSP 모니터링 표준화
- MSP 고객사별 AWS·Azure·NCP 환경을 Datadog으로 연동하고, 클라우드 운영 현황을 공통 기준으로 모니터링할 수 있는 구조를 구축했습니다.
- 클라우드 계정 Integration을 통해 리소스 상태, 서비스 이벤트, Health Event 등 운영에 필요한 기본 데이터를 수집하도록 구성했습니다.
- 서버 기반 워크로드에는 Datadog Agent를 직접 설치하고, CPU, Memory, Disk, Process 등 기본 인프라 메트릭 수집 기준을 정리했습니다.
📊 고객사별 대시보드 및 알림 기준 구성
- 고객사별 운영 현황을 한눈에 확인할 수 있도록 Datadog Dashboard를 구성했습니다.
- 서버 상태, 리소스 사용률, 클라우드 이벤트, 주요 서비스 상태를 기준으로 운영 화면을 정리했습니다.
- CPU, Memory, Disk, Health Event, 주요 서비스 상태 변화 등 운영 대응에 필요한 Monitor와 Alert 기준을 설정했습니다.
- 월간 운영 보고와 장애 대응에 활용할 수 있도록 공통 대시보드와 고객사별 대시보드 기준을 함께 정리했습니다.
🔐 CSPM·Cloud SIEM 기반 보안 이벤트 모니터링 확장
- 단순 인프라 모니터링을 넘어, Datadog의 CSPM과 Cloud SIEM 기능을 활용해 보안 이벤트 모니터링 영역까지 확장했습니다.
- 계정 생성·삭제, 권한 변경, 보안 설정 변경, 주요 리소스 구성 변경 등 클라우드 콘솔에서 발생하는 보안성 이벤트를 수집하도록 설정했습니다.
- CloudTrail 등 클라우드 로그를 Datadog으로 연동해 운영 이벤트와 보안 이벤트를 하나의 Observability 플랫폼에서 확인할 수 있도록 구성했습니다.
📚 운영 가이드 및 교육 자료 정리
- MSP 운영자가 고객사별 Datadog 연동, Agent 설치, Dashboard, Monitor 설정을 일관되게 적용할 수 있도록 운영 기준을 정리했습니다.
- Datadog 기본 사용법, 대시보드 확인 방법, 알림 대응 기준, CSPM·Cloud SIEM 확인 방법을 문서화했습니다.
- 신규 운영자와 고객사 설명에 활용할 수 있도록 교육 자료 형태로 정리해 MSP 운영 표준화에 기여했습니다.
✅ 성과 및 의미
- MSP 고객사 클라우드 환경에 대한 Datadog Integration, Agent 설치, Dashboard, Monitor, CSPM·Cloud SIEM 초기 세팅을 직접 수행했습니다.
- 분산되어 있던 클라우드 운영 모니터링을 Datadog 기반 표준 체계로 정리했습니다.
- 인프라 메트릭, 클라우드 이벤트, 보안 이벤트를 통합적으로 확인할 수 있는 운영 기반을 마련했습니다.
- 고객사별 대시보드와 알림 기준을 표준화해 장애 대응과 월간 운영 보고의 일관성을 높였습니다.
Datadog MSP Monitoring Architecture
고객사 클라우드 계정, 서버 워크로드, Datadog Integration·Agent·Dashboard·Alert·CSPM·Cloud SIEM 연계 구조
핵심 설계 관점
Cloud Integration · AWS·Azure·NCP 계정 연동
Agent Setup · 서버 메트릭 수집 구성
Dashboard · 고객사별 운영 화면 구성
Monitor · 임계치·이벤트 알림 설정
CSPM / Cloud SIEM · 보안 이벤트 초기 세팅
한화시스템 · Datadog / AWS
Datadog PrivateLink 기반 프라이빗 메트릭 전송 아키텍처
Datadog Agent 데이터가 퍼블릭 인터넷망을 경유하지 않도록 AWS PrivateLink 기반 사설 전송 구조를 설계했습니다. 온프렘·Azure 트래픽은 AWS 공통 운영 영역으로 집약해 Datadog으로 전달되도록 구성했습니다.
🧭 프로젝트 개요
- AWS·Azure·온프렘 환경의 VM 및 서버에서 Datadog Agent 기반 메트릭·로그 수집을 운영했습니다.
- Datadog Agent의 기본 전송 구조는 수집 데이터를 Datadog으로 전달할 때 퍼블릭 인터넷망을 경유하는 방식이었습니다.
- 운영 서버의 모니터링 데이터 전송 구간을 사설화하기 위해 AWS PrivateLink 기반 전송 아키텍처를 설계했습니다.
- Azure 환경은 Datadog PrivateLink 적용 리전 제약으로 직접 연동이 어려워, 온프렘·Azure 트래픽을 데이터센터 경유로 AWS 공통 운영 영역에 집약하는 구조를 구성했습니다.
- 최종적으로 AWS PrivateLink, VPC Endpoint, NLB/ALB, Route 53 Private Hosted Zone을 활용해 Datadog Agent 데이터의 프라이빗 전송 경로를 구현했습니다.
🔗 PrivateLink 기반 전송 구조 설계
- On-Premise 및 Azure 환경의 Datadog Agent 트래픽이 데이터센터를 거쳐 AWS 공통 운영 영역으로 전달되도록 네트워크 흐름을 설계했습니다.
- AWS 공통 운영 영역에 Datadog VPC Endpoint와 연결되는 PrivateLink 구간을 구성했습니다.
- NLB와 ALB를 조합해 Datadog 서비스별 엔드포인트로 트래픽이 전달되도록 구성했습니다.
- Datadog은 metrics, logs, process, database 등 서비스별 엔드포인트가 분리되어 있어, ALB Host Header 기반 라우팅을 통해 Subdomain 요청을 분기했습니다.
- Route 53 Private Hosted Zone에 Custom Domain을 등록해 내부 Agent가 사설 도메인으로 접근할 수 있도록 DNS 및 VPC 설정을 구성했습니다.
⚙️ Datadog Agent 연동 구성
- Datadog Agent가 기본 Site 설정이 아닌 Custom URL 기반으로 통신하도록 설정했습니다.
- 메트릭, 프로세스, 로그, Database Monitoring 등 데이터 유형별 전송 URL을 분리했습니다.
- datadog.yaml 설정을 수정해 각 요청이 PrivateLink 경로를 통해 전달되도록 구성했습니다.
- Agent 재시작 및 상태 확인을 통해 실제 전송 URL과 통신 상태를 검증했습니다.
Agent Custom URL 구성 예시
dd_url: https://metrics.dd.example.internal:443 process_config: enabled: true process_dd_url: https://process.dd.example.internal:443 logs_config: log_dd_url: https://agentlogs.dd.example.internal:443
🧩 구조 검토 및 설계 판단
- 초기에는 NLB·ALB 구조 외에도 AWS Lattice 기반 구조를 검토했습니다.
- Lattice는 네트워크 토폴로지 단순화와 IAM 기반 서비스 정책 적용 측면에서 장점이 있었습니다.
- 다만 Datadog은 서비스별 엔드포인트가 다수 존재하고, 동일한 443 포트에서 Host 기반 라우팅이 필요했습니다.
- Lattice는 Target Group 수와 Host 기반 라우팅 제약으로 요구 구조를 완전히 대체하기 어려웠습니다.
- 최종적으로 Datadog 서비스별 Subdomain 분기와 PrivateLink 연결을 모두 만족할 수 있는 NLB·ALB·VPC Endpoint 조합을 선택했습니다.
✅ 성과 및 의미
- Datadog Agent 데이터 전송 구간을 퍼블릭 인터넷망이 아닌 사설 경로로 전환할 수 있는 구조를 설계했습니다.
- AWS PrivateLink를 활용해 하이브리드 환경의 모니터링 데이터 전송 보안성을 강화했습니다.
- On-Premise·Azure·AWS가 혼재된 환경에서도 중앙 AWS 경유 방식으로 Datadog PrivateLink를 활용할 수 있는 구조를 마련했습니다.
- Route 53 Private Hosted Zone, NLB/ALB 라우팅, VPC Endpoint를 조합한 프라이빗 전송 패턴을 정립했습니다.
- MSP 운영 대상 환경에 공통 적용 가능한 Datadog 사설 연동 아키텍처를 구성했습니다.
Datadog PrivateLink Architecture
On-Premise · Azure · AWS 환경의 Agent 트래픽을 AWS PrivateLink 기반 사설 경로로 전달하는 구조
핵심 설계 관점
Datadog Agent 데이터의 퍼블릭 인터넷망 경유 제거
On-Premise·Azure 트래픽의 데이터센터 경유 AWS 집약 구조
AWS PrivateLink 기반 Datadog 사설 연동
VPC Endpoint, NLB/ALB, Route 53 Private Hosted Zone 조합
Datadog 서비스별 Subdomain 분기를 위한 Host Header 기반 라우팅
Lattice 대안 검토 후 NLB·ALB 구조 선택
BC카드 · Information Security Operations
금융권 정보보호 운영 및 정기검사 대응
SWG, SSL 인증서, 원격접속자·중요단말기 관리 등 금융권 정보보호 운영 업무를 수행했습니다. 2026.04.20~04.24 사전감사, 2026.05.11~06.09 본검사 기간 동안 담당 보안 운영 영역의 증적 정리와 현장 질의 대응을 지원했습니다.
🧭 프로젝트 개요
- BC카드 정보보호운영팀에서 금융권 정보보호 운영 업무를 수행했습니다.
- SWG, SSL 인증서, 원격접속자, 중요단말기, 외부 전산기기 반출입 등 주요 보안 운영 항목을 담당했습니다.
- 2026년 상반기 금융감독원 정기검사에서 담당 보안 운영 영역의 자료 정리, 증적 제출, 현장 질의 대응을 지원했습니다.
🔐 담당 운영 영역
- 유해·비업무 사이트 차단 시스템 운영
- 스팸메일 차단 시스템 관리
- 대외 서비스 SSL 인증서 현황 및 갱신 관리
- 원격접속자 접속 이력 및 승인 증적 관리
- 중요단말기 현황 및 통제 정책 점검
- 외부 전산기기, 장비 및 물품 반출입 관리
- ADSL 네트워크 운영 현황 관리
📑 금융감독원 정기검사 대응
- 담당 영역별 검사 요청 자료를 정리하고 제출했습니다.
- 운영 대장, 결재 문서, 접속 이력, 정책 적용 현황 등 주요 증적을 취합했습니다.
- 현장 실사 및 인터뷰 과정에서 담당 업무의 운영 절차와 관리 현황을 설명했습니다.
- 추가 확인이 필요한 사항은 관련 부서와 협업해 자료를 보완했습니다.
✅ 성과 및 의미
- 금융권 정보보호 운영 업무가 감독기관 검사에서 어떤 기준으로 확인되는지 경험했습니다.
- 보안 운영 항목을 단순 관리가 아닌 증적, 절차, 현황 중심으로 정리하는 경험을 쌓았습니다.
- 금융권 규제 환경에서 정보보호 운영과 감사 대응이 연결되는 방식을 이해했습니다.
FSS Regular Inspection
금융감독원 정기검사 대응
사전감사
2026.04.20 ~ 2026.04.24
본검사
2026.05.11 ~ 2026.06.09
한화시스템 · FinOps
HCMP 기반 클라우드 비용 이상 탐지 및 운영 기준 개선
테스트 구독의 비정상 비용 급증 사례를 계기로, HCMP 기반 비용 이상 탐지 알림 기능을 개선했습니다. 전일 대비 비용 증가 금액·증가율 기준의 알림 체계를 마련하고, 개발·테스트 구독의 클라우드 운영 기준 강화로 확장했으며, 해당 과제로 2025년 한화시스템 장애예방 개선 과제 최우수상을 수상했습니다.
🧭 프로젝트 개요
- 중앙 Azure Tenant 내 테스트 구독에서 비정상 비용 급증 사례를 조기 발견했습니다.
- 원인 확인 결과, API Key 노출로 인한 비정상 리소스 사용이 발생한 사례였습니다.
- 해당 경험을 계기로 클라우드 비용 데이터를 보안 사고와 운영 리스크를 탐지하는 지표로 바라보게 되었습니다.
- OpsNow HCMP를 활용해 비용 이상 징후를 조기에 감지할 수 있는 알림 기능 개선을 추진했습니다.
⚙️ 개선 내용
- 베스핀글로벌과 협업해 HCMP 비용 알림 기능을 개선했습니다.
- 전일 대비 비용 증가 금액과 증가율을 기준으로 알림 조건을 설정할 수 있도록 기획했습니다.
- 비용 급증 발생 시 운영자가 빠르게 확인하고, 담당 부서와 리소스 사용 목적을 점검할 수 있는 흐름을 마련했습니다.
- 월말 청구 중심의 비용 확인에서, 운영 중 비용 리스크를 조기에 감지하는 방식으로 관리 관점을 확장했습니다.
🛡️ 운영 기준 강화
- 해당 사례 이후 개발·테스트 목적의 구독도 운영 리스크 관리 대상으로 포함했습니다.
- 개발 환경이라도 외부에 노출되는 퍼블릭 리소스 사용은 제한하는 기준을 적용했습니다.
- 기본 모니터링 설정을 필수 적용하도록 운영 기준을 강화했습니다.
- 비용, 보안, 리소스 상태를 함께 확인하는 클라우드 운영 관리 체계로 개선했습니다.
✅ 성과 및 의미
- 클라우드 비용 이상 징후를 조기에 인지할 수 있는 운영 체계를 마련했습니다.
- 비용 데이터를 리소스 오남용, API Key 노출, 비정상 사용량 증가를 발견하는 관리 지표로 활용했습니다.
- 개발·테스트 구독까지 포함한 클라우드 사용 기준과 기본 모니터링 체계를 강화했습니다.
- 해당 개선 과제로 2025년 한화시스템 장애예방 개선 과제 최우수상을 수상했습니다.
Award
2025 한화시스템
장애예방 개선 과제
최우수상 · 1위 수상
클라우드 비용 모니터링 도구 개발을 통한 장애 예방 및 운영 효율 개선 과제
Cost Risk Flow
Detect비용 급증 조기 확인
NotifyHCMP 알림 기준 적용
Check담당 부서·리소스 목적 확인
Prevent운영 기준 및 모니터링 강화
한화시스템 · HCMP
HCMP 기반 클라우드 비용·리소스 관리 운영
HCMP 기반으로 내부 클라우드와 MSP 고객 계정의 비용·리소스 현황을 통합 관리했습니다. 신규 구축 견적 산출과 월별 청구 자료 정리도 함께 수행했습니다.
한화그룹 · FinOps
MSP 대상 클라우드 비용 최적화 전략 수립
MSP 고객사의 월간 비용 보고서를 작성하며 리소스별 비용 증감과 6개월 비용 추이를 분석했습니다. RI/SP, Right-sizing, Graviton 전환, 개발계 Stop/Start 자동화 등 인프라 운영 지표 기반의 비용 최적화 방안을 제안·적용했습니다.
🧭 프로젝트 개요
- MSP 고객사의 월간 비용 보고서를 작성하며 클라우드 비용 현황과 리소스 사용 패턴을 함께 분석했습니다.
- 전월 대비 비용 증감, 최근 6개월 비용 추이, 주요 증감 사유를 정리하고 고객사에 설명했습니다.
- 단순 청구 금액 정리가 아니라, 인프라 구성·사용률·운영 패턴을 함께 검토해 비용 증가 원인을 기술적으로 분석했습니다.
- 고객사의 비용 절감 요구에 대응하기 위해 약정, 리소스 조정, 운영 시간 최적화 등 실행 가능한 절감 방안을 지속적으로 제안했습니다.
📊 비용 분석 및 보고
- 월별 비용 보고서에서 서비스별·리소스별 비용 변화를 정리했습니다.
- 전월 대비 증감 금액과 증감률을 확인하고, 비용 변동이 발생한 리소스와 원인을 분석했습니다.
- 최근 6개월 비용 추이를 기반으로 고객사별 사용 패턴과 비용 흐름을 설명했습니다.
- 신규 리소스 생성, 스펙 변경, 사용량 증가, 트래픽 증가 등 비용 변동 요인을 인프라 운영 관점에서 확인했습니다.
⚙️ 기술 기반 최적화 방안
- 안정적으로 사용되는 리소스는 Reserved Instance 적용 가능성을 검토했습니다.
- 사용량이 유동적인 워크로드는 Savings Plan 적용이 적합한지 검토하고 제안했습니다.
- CPU, Memory, Disk 사용률을 기반으로 VM 및 DB 리소스의 Right-sizing을 제안했습니다.
- Intel 기반 인스턴스는 AWS Graviton 전환 가능성을 검토해 비용 효율 개선 방안을 제시했습니다.
- 개발·검증 환경은 Lambda 기반 Stop/Start 자동화를 적용해 야간 및 비업무 시간 비용을 절감했습니다.
- 장기 연휴 전에는 고객 확인 후 개발계 리소스를 일괄 중지해 불필요한 비용 발생을 줄였습니다.
✅ 성과 및 의미
- MSP 운영 과정에서 기술 운영과 비용 관리를 함께 수행한 FinOps 경험을 쌓았습니다.
- 비용 데이터를 단순 정산 자료가 아니라 리소스 최적화와 운영 효율 개선의 근거로 활용했습니다.
- 고객사별 인프라 구조와 사용 패턴을 기반으로 현실적으로 적용 가능한 비용 절감 방안을 제안했습니다.
- 클라우드 아키텍처, 운영 지표, 비용 구조를 함께 이해하고 개선하는 기술 기반 FinOps 역량을 확보했습니다.
FinOps Practice
기술 기반 비용 최적화
월간 비용 보고, 리소스 사용률 분석, 고객사 운영 패턴을 함께 검토해 현실적으로 적용 가능한 절감 방안을 제안했습니다.
핵심 최적화 관점
월간보고서 기반 비용 추이 분석
리소스별 전월 대비 증감 사유 정리
RI / Savings Plan 적용 검토
CPU·Memory·Disk 사용률 기반 Right-sizing
AWS Graviton 전환을 통한 비용 효율화
개발계 Stop/Start 자동화 및 연휴 전 리소스 중지
Datadog · 파트너십
Datadog 파트너십 체결 및 MSP 서비스 제공 기반 마련
MSP 고객사의 Datadog 사용 확대에 따라, 한화시스템의 Datadog 파트너십 체결을 지원했습니다. 파트너십 신청에 필요한 Sales, Demo, Fundamentals, Public Certification 요건을 단독으로 충족하고, MSP 고객사 대상 Datadog 서비스 제공 기반을 마련했습니다.
🧭 프로젝트 개요
- MSP 고객사의 Datadog 사용이 확대되면서, 기존 리셀러 경유 방식이 아닌 한화시스템 자체 파트너십 기반의 운영 구조가 필요해졌습니다.
- Datadog 파트너십 체결을 위해 요구되는 Sales, Demo, Fundamentals, Public Certification 요건을 검토했습니다.
- 파트너십 신청에 필요한 교육·인증 요건을 단독으로 충족하고, 한화시스템의 Datadog 파트너십 신청을 지원했습니다.
- 최종적으로 Datadog Sales Partner Standard 등급 파트너십 체결이 완료되었습니다.
🎓 파트너십 요건 충족
- Datadog Sales Certification을 취득했습니다.
- Datadog Demo Certification을 취득했습니다.
- Datadog Fundamentals 교육·인증 요건을 충족했습니다.
- Datadog Public Certification 영역의 인증 요건을 충족했습니다.
- 파트너 등급 유지를 위해 필요한 연례 인증 재취득 및 갱신 대응도 수행했습니다.
🤝 파트너십 운영 및 협업
- Datadog 파트너 담당자 및 영업 담당자와 파트너십 신청·운영 관련 미팅을 진행했습니다.
- MSP 고객사 대상 Datadog 모니터링, CSPM, Cloud SIEM 서비스 제공을 위한 파트너 기반을 마련했습니다.
- 기존 리셀러 경유 구조에서 벗어나, 한화시스템이 직접 Datadog 서비스를 제안·운영할 수 있는 구조를 정리했습니다.
- 고객사 클라우드 운영 환경에 Datadog을 표준 모니터링 도구로 확장 적용할 수 있는 기반을 마련했습니다.
✅ 성과 및 의미
- Datadog 파트너십 체결에 필요한 인증 요건을 단독으로 충족했습니다.
- 한화시스템의 Datadog Sales Partner Standard 등급 파트너십 체결을 지원했습니다.
- MSP 고객사 대상 Datadog 서비스 제공 및 재판매 기반을 마련했습니다.
- 클라우드 모니터링 도구 운영 경험을 파트너십, 서비스 제공 구조, MSP 비즈니스 확장 관점으로 연결했습니다.
Partner Enablement
Datadog Sales Partner
Standard 등급 체결 지원MSP 고객사 대상 Datadog 서비스 제공을 위한 파트너십 기반을 마련했습니다.
핵심 기여 포인트
Datadog 파트너십 요건 검토
Sales / Demo / Fundamentals / Public Certification 취득
파트너십 신청 및 담당자 미팅 지원
Sales Partner Standard 등급 체결 지원
MSP 고객사 대상 Datadog 서비스 제공 기반 마련
파트너 등급 유지를 위한 연례 인증 재취득 대응