인쇄용 PDF가 따로 있습니다
이 화면은 인쇄에 맞지 않습니다. 인쇄용으로 만든 PDF를 받아 주세요.
PDF 버전: https://hannctl.com/KimJunHyun_Portfolio_KO.pdf
https://hannctl.com/print
terraform plan -target=module.career
✓ 3 companies · 20 projects · since 2020
사람의 기억에 기대던 인프라와 보안을, 코드가 지키는 구조로 바꿉니다
PROFILE2020 — 2026.10
Public Cloud Infrastructure & Security Engineer
IaC 자동화 · 멀티클라우드 운영 · 클라우드 보안 · 운영 자동화 · AI 에이전트
막대 = 회사별 근무 개월 (2020.08 – 2026.10)
게임 서비스부터 금융권까지 AWS·GCP·Azure·Tencent 4개 클라우드(CSP)에서 최대 서버 3,500대·DB 650개 규모의 인프라를 운영했습니다. Terragrunt 전환으로 배포 시간을 40% 줄였고, CSPM(클라우드 보안 설정 점검) 조치율을 60%에서 85% 이상으로 올렸던 경험을 가지고 있습니다.
CAREER.LOG / 3 companies
스크롤하거나 화살표 키·버튼으로 회사를 넘깁니다.
$ open career/01_cnthoth --since 2020.08
사원~대리 · Cloud Engineer (Azure MSP) · Cloud 서비스팀
30 개월 · 프로젝트 5건 · Azure
고객의 대규모 게임을 지키다
$ open career/02_com2us --since 2023.02
대리 · Cloud Engineer · 클라우드본부 인프라기술실
36 개월 · 프로젝트 14건 · GCP / Tencent / AWS / Azure
4개 클라우드를 직접 운영하고 옮기다
$ open career/03_woorifis --since 2026.02
대리 · Cloud Security Engineer · 정보보안부
8 개월 · 프로젝트 1건 · AWS
규제 환경에서 처음부터 설계하다
PROJECTS / 12 case studies · 20 services
케이스 스터디는 과제·수행·성과로, 나머지 서비스 프로젝트는 한 줄씩 정리했습니다.
대리 · Cloud Security Engineer
다중 AWS 계정의 망분리 요건을 서브넷과 방화벽 구조로 옮기고, 보안 구성을 Terraform 코드 한 벌로 표준화했습니다.
[01] 과제
그룹사들이 퍼블릭 클라우드를 처음 도입하는 단계에 Terraform이 없었고, 계정마다 담당자에 따라 보안 설정이 달랐습니다. 망분리 규정을 문서로만 지키기도 어려웠습니다.
[02] 수행 내용
망분리(중요도가 다른 네트워크를 나눠 외부 위협이 내부로 바로 들어오지 못하게 하는 금융권 통제) 요건을 DMZ·Private 서브넷 분리, 백엔드 공인 IP 금지, 허용된 대상으로만 아웃바운드라는 세 원칙으로 옮겼습니다. WAF, Network Firewall, Shield Standard 구성을 Terraform으로 정의해 모든 계정에 같은 코드를 적용하고, GuardDuty와 Security Hub까지 Splunk SIEM/SOAR로 연동했습니다.
[03] 성과
계정이 늘어나도 같은 보안 기준이 코드로 반복되어 담당자별 정책 편차가 사라졌습니다. 다중 AWS 계정의 통신 구성은 Python 파이프라인으로 자동 수집·분석해 반복 가능한 점검이 됐습니다. IAM 권한도 Terraform으로 정의해 과도한 권한을 구조적으로 막았습니다.
배운 점 보안 구성이 코드가 되면 계정별 차이가 곧 코드 차이로 보인다는 점이 가장 큰 배움이었습니다. 담당자마다 콘솔에서 설정하던 때에는 어느 계정이 다른지 일일이 비교해야 했지만, 같은 Terraform 코드를 모든 계정에 적용하니 다른 부분은 코드에서 바로 드러났습니다. 망분리처럼 문서로만 존재하던 규정도 서브넷 분리, 백엔드 공인 IP 금지, 허용된 대상으로만 아웃바운드라는 세 원칙으로 바꾸고 나서야 구조로 지킬 수 있었습니다. 동시에 코드로 정의한 기준은 각 계정에서 실제로 지켜지는지 확인할 때 비로소 완성된다는 것도 알게 됐고, 통신 구성을 자동으로 수집·분석하는 파이프라인을 만든 것도 그 확인을 사람의 기억이 아닌 반복 가능한 점검으로 만들기 위해서였습니다.
기술 TerraformAWS Network FirewallAWS WAFAWS Shield StandardGuardDutySecurity HubSplunkPython Control Plane에서 전체 보기 ↗
계열사의 다중 AWS 계정에 Network Firewall·WAF·Shield 보안 인프라를 Terraform으로 처음 도입하고, 그룹의 클라우드 보안 정책 정의서를 설계해 배포
대리 · Cloud Engineer
서머너즈워: 크로니클의 서버 80대·DB 20개를 약 1주일 만에 서비스 중단 없이 GCP에서 Tencent Cloud로 옮긴 프로젝트입니다.
[01] 과제
라이브 게임의 인프라를 클라우드 간에 옮기면서 서비스를 멈출 수 없었고, 옮기는 과정에서 방화벽 정책이 다르게 적용되면 안 됐습니다.
[02] 수행 내용
네트워크와 방화벽 규칙을 Tencent에 GCP와 동일하게 먼저 구성했습니다. 서버는 Online Migration 도구로 옮기고 같은 인프라를 구성한 뒤, 비공개로 운영하며 개발팀과 이슈를 확인하고 트래픽을 단계적으로 전환했습니다. 전 과정은 GCP Terraform 코드를 Tencent Terraform 코드로 옮기는 방식으로 진행했습니다.
[03] 성과
약 1주일 만에 서비스 중단 없이 이관을 끝냈습니다. 일부는 GCP에 남기고 대부분의 게임 서버와 DB를 Tencent로 옮겼으며, 방화벽 정책은 전부 검토해 다시 세운 상태로 운영했습니다.
배운 점 클라우드 간 이관에서 가장 먼저 할 일은 서버를 옮기는 것이 아니라 두 클라우드의 리소스를 역할별로 짝지어 보는 일이었습니다. 네트워크, 서브넷, 방화벽, 서버의 대응표를 먼저 정리하니 GCP Terraform 코드를 Tencent Terraform 코드로 옮기는 작업이 단순해졌고, 방화벽 정책도 옮기는 김에 전부 검토해 다시 세울 수 있었습니다. 서비스를 멈추지 않는 비결도 한 번에 바꾸지 않는 데 있었습니다. 같은 인프라를 먼저 구성해 비공개로 운영하며 개발팀과 이슈를 확인하고, 트래픽은 단계적으로 넘겼습니다. 인프라는 코드로 남았지만 트래픽 전환 절차까지 코드와 런북으로 남겨야 다음 이관에서도 같은 결과를 재현할 수 있다는 점을 배웠습니다.
기술 TerraformGCPTencent CloudOnline Migration Control Plane에서 전체 보기 ↗
GCP와 Tencent Cloud에 걸친 서버 600대·DB 70개 환경의 방화벽 정책을 전수 재설계하고, 무점검 원칙으로 운영한 대규모 게임 인프라입니다.
[01] 과제
회사에서 가장 큰 프로젝트로, 중국 서비스를 위해 Tencent를 함께 운영했습니다. 두 클라우드의 방화벽 정책이 오래 쌓여 중복되고 복잡해졌고, 여러 리전으로 커진 코드는 Terraform만으로 다루기 어려워졌습니다.
[02] 수행 내용
클라우드 간 방화벽 정책을 전수 분석해 중복과 불필요한 규칙을 제거하고 웹, 게임, DB, 관리 역할 기준으로 다시 묶었습니다. Terraform을 Terragrunt 구조로 옮겨 코드 중복을 걷어 냈습니다. 대부분의 서버를 로드밸런서 백엔드로 두어 서버를 하나씩 빼고 넣는 방식으로 무점검 패치를 했습니다.
[03] 성과
방화벽 정책이 단순해져 검토와 변경이 쉬워지고 공격에 노출되는 범위가 줄었습니다. Terragrunt 전환으로 배포 시간을 40% 줄였고, GCP Cloud Armor로 DDoS 방어를 운영했습니다.
배운 점 방화벽 정책은 규칙을 추가만 하면 금방 아무도 읽을 수 없게 된다는 점을 크게 배웠습니다. 오래 쌓인 규칙을 웹, 게임, DB, 관리 역할 기준으로 다시 묶고 나니 변경할 때 어디를 봐야 하는지 바로 보였고, 공격에 노출되는 범위도 함께 줄었습니다. 규모가 커질수록 코드도 같은 문제를 겪어서, 여러 리전으로 늘어난 Terraform 코드를 Terragrunt 구조로 옮겨 중복을 걷어 내야 했습니다. 무점검 운영은 특별한 기술보다 서버를 로드밸런서 뒤에 두고 하나씩 빼고 넣을 수 있게 만든 구조에서 나왔습니다. 그리고 한 번의 전수 분석으로 정리한 정책도 시간이 지나면 다시 쌓이므로, 정리는 일회성 작업이 아니라 주기적으로 돌아가야 하는 점검이라는 것을 배웠습니다.
기술 GCPTencent CloudTerraformTerragruntCloud Armor Control Plane에서 전체 보기 ↗
매출 지표와 인프라 비용을 연동해 모니터링하고 Python으로 불필요 리소스를 매일 자동 탐지해 인프라 비용을 최대 62% 줄였습니다.
[01] 과제
게임 매출 대비 인프라 비용 비율이 높아 수익성에 문제가 있었습니다.
[02] 수행 내용
매출 지표와 인프라 비용을 연동해 함께 모니터링했습니다. Python으로 전 CSP의 불필요 리소스를 매일 자동 탐지했습니다.
[03] 성과
인프라 비용을 최대 62% 절감했습니다.
배운 점 비용은 금액만 볼 때보다 매출과 같은 기준에서 볼 때 판단이 쉬워진다는 점을 배웠습니다. 인프라 비용을 매출 지표와 나란히 두니, 어떤 리소스가 수익성에 영향을 주는지와 무엇을 먼저 줄여야 하는지가 분명해졌습니다. 또 비용 누수는 한 번 정리한다고 끝나지 않아서, 불필요한 리소스를 사람이 가끔 찾는 대신 Python으로 매일 자동 탐지하는 것이 절감 효과를 유지하는 방법이었습니다. 다만 탐지만으로는 비용이 줄지 않고 실제 정리까지 이어져야 하므로, 탐지 결과가 정리 승인과 실행으로 빠르게 연결되는 흐름이 비용 관리의 다음 단계라는 점도 알게 됐습니다.
기술 AzurePythonBilling monitoring Control Plane에서 전체 보기 ↗
회사 최대 프로젝트. "무점검" 원칙의 멀티클라우드 운영과 방화벽 전수 재설계
GCP → Tencent 무중단 이관. 이관하며 방화벽 정책을 전부 재수립
GCP에서 GKE를 처음 도입한 게임 중 하나
Tencent Cloud 기반 게임 인프라 운영
GCP 기반 게임 인프라 운영
EKS 중심 운영. Terraform을 Terragrunt로 옮겨 배포 시간 40% 단축
GKE 중심, 오토스케일링으로 부하 관리
매출과 비용을 연동해 인프라 비용 최대 62% 절감
GCP 기반 게임 인프라 운영
GCP 기반 게임 인프라 운영
Tencent Cloud 기반 게임 인프라 운영
Azure 기반 게임 인프라 운영
GCP에서 Tencent로 이관을 거친 프로젝트
과거 게임 부활 프로젝트. 비용 문제로 Tencent 이전을 검토 후 GCP 유지
사원~대리 · Cloud Engineer (Azure MSP)
서버 3,500대·DB 650개 규모의 글로벌 게임을 Azure에서 전담 운영하고, DDoS 공격 IP를 로그에서 찾아 NSG에 자동으로 등록하는 구조를 만들었습니다.
[01] 과제
규모가 커서 물리 장애와 공격의 영향이 전 세계 서비스로 번질 수 있었고, 야간과 주말의 DDoS 공격은 사람 손으로 막는 동안 대응이 늦어졌습니다.
[02] 수행 내용
설계 초기부터 참여해 Azure Dedicated Host 기반 고가용성 구조를 함께 잡았습니다. Azure DDoS 방어가 남기는 완화 흐름 로그를 Log Analytics에서 주기적으로 조회해 비정상 TCP SYN 출발지를 찾고, PowerShell이 해당 IP를 NSG Deny 규칙에 등록합니다.
[03] 성과
탐지부터 차단까지 사람 개입 없이 이어져 야간과 주말의 대응 지연을 없앴습니다. 리소스 배포, 장애 자동 조치, 자산 수집도 PowerShell로 자동화하며 전담 운영했습니다.
배운 점 물리 서버 한 대가 멈춰도 서비스 전체가 멈추지 않으려면, 전용 호스트를 서로 다른 장애 구역에 나눠 두는 구성이 기본이라는 것을 배웠습니다. 규모가 클수록 장애와 공격의 영향이 전 세계 서비스로 번지기 때문에, 이런 결정은 운영 중에 덧붙이기보다 설계 초기부터 함께 잡아야 했습니다. DDoS 대응에서는 사람이 깨어 있는 시간에 대응 속도가 묶이지 않도록, 로그에서 비정상 출발지를 찾는 일부터 NSG 차단 등록까지를 하나의 자동 흐름으로 이었습니다. 그리고 자동으로 막을수록 왜 막았는지를 남겨야 나중에 사람이 그 판단을 검토할 수 있다는 점도 배웠습니다.
기술 AzureDedicated HostPowerShellLog AnalyticsNSG Control Plane에서 전체 보기 ↗
첫 메인 엔지니어이자 경험한 최대 규모. 고객사 상주 자문과 PowerShell 자동화
ISMS·CSPM 대응을 포함한 대형 게임 인프라 운영
PowerShell 배포 자동화로 배포 속도 80% 개선, 국내 DDoS 탐지·방어
ISMS·CSPM 대응을 포함한 게임 인프라 운영
첫 비(非)게임 프로젝트. 스토리지 관리, ISMS·CSPM 대응
공개 레포 · 개인 프로젝트
리전별 locals 맵 하나를 고치면 16개 AWS 리전에 같은 인프라가 만들어지는 Terraform 모듈 모음입니다.
[01] 과제
같은 형태의 리소스를 여러 리전에 만들어야 했습니다. 리전이 늘수록 복사한 코드가 늘고 리전마다 설정이 달라질 위험이 커졌습니다.
[02] 수행 내용
리전별 locals 맵에 원하는 상태를 선언하고 module과 for_each로 일괄 생성합니다. provider는 리전마다 별칭을 두고 같은 role을 assume합니다. for_each가 provider를 동적으로 고를 수 없어 리전별 module 블록은 반복합니다.
[03] 성과
변경은 맵 항목 하나로 끝나고, 키가 고정이라 순서를 바꿔도 리소스가 다시 생성되지 않습니다. 모듈 24종에 암호화, IMDSv2, 비공개 S3 같은 기본값을 넣었고 EKS와 알림 예제까지 3종을 공개했습니다.
배운 점 반복을 줄이는 것만큼 리소스를 가리키는 키를 고정하는 것이 중요했습니다. count는 목록의 위치로 리소스를 구분해 항목을 끼워 넣거나 순서를 바꾸면 뒤쪽 리소스가 다시 만들어질 수 있지만, for_each는 맵의 키로 구분하므로 순서와 상관없이 같은 리소스를 가리킵니다. provider를 for_each로 고를 수 없다는 Terraform의 제약은 억지로 감추지 않고 리전별 module 블록을 반복해 드러냈고, 그 편이 읽고 고치기 쉬웠습니다. 이후로는 같은 구조를 여러 곳에 만들 때 데이터(맵)와 코드(모듈)를 먼저 나누고, 변경이 맵 항목 하나로 끝나는지를 설계의 기준으로 삼습니다.
기술 TerraformAWSEKSCloudWatchAWS Chatbot pf-01-aws-terraform-multi-region ↗ Control Plane에서 전체 보기 ↗
노드 풀 업그레이드 중에도 용량을 유지하는 SURGE 설정과, VPN 대역만 허용하는 방화벽 기본선을 코드로 담은 모듈 모음입니다.
[01] 과제
GKE 노드를 업그레이드하는 동안 서비스 용량이 줄면 안 됐고, 관리 포트는 VPN 대역에서만 열려야 했습니다.
[02] 수행 내용
노드 풀 업그레이드 전략을 SURGE로 두어 새 노드 5대를 먼저 올리고 사용 불가 노드를 0으로 유지합니다. c2sfirewall 모듈은 우선순위 1000으로 VPN의 관리 포트만 열고, 우선순위 65534로 그 외 tcp와 udp 아웃바운드를 막습니다.
[03] 성과
새 노드가 준비된 뒤에야 기존 노드가 빠집니다. 호스트 장애는 hostError 감사 로그에서 로그 기반 지표, 알림 정책, Slack 채널 순으로 이어지도록 구성했습니다.
배운 점 설정 이름만 보고 동작을 판단하면 틀릴 수 있다는 점을 배웠습니다. soak 시간처럼 이름만 보면 모든 업그레이드에 적용될 것 같은 값도 실제로는 BLUE_GREEN 전략에서만 읽히기 때문에, SURGE 예제에서는 이 값이 동작하지 않는다는 사실을 주석으로 분명히 남겼습니다. 업그레이드 중 용량을 지키는 것도 "새 노드를 먼저 올리고(max_surge 5), 빠지는 노드는 0으로 둔다"처럼 의도를 숫자로 고정해야 운영자가 바뀌어도 같은 결과가 나옵니다. 방화벽 역시 필요한 관리 포트만 우선순위 1000으로 열고 나머지를 65534에서 막는 기본선을 모듈에 넣어, 새 환경이 처음부터 같은 규칙으로 시작하게 했습니다.
기술 TerraformGCPGKECloud LoggingCloud Monitoring pf-02-gcp-terraform-gke-platform ↗ Control Plane에서 전체 보기 ↗
CloudAudit 추적을 서비스별로 코드에 정의해 위험한 변경을 COS 버킷에 남기는 Tencent Cloud 모듈 모음입니다.
[01] 과제
Tencent Cloud에서 누가 무엇을 바꿨는지 서비스별로 남겨야 했습니다. 또 provider 릴리스 주기가 불규칙해 버전이 바뀌면 코드 변경 없이도 plan이 달라질 수 있었습니다.
[02] 수행 내용
CloudAudit 추적을 CAM, CVM, CBS, VPC 서비스별로 코드에 정의하고 COS 버킷의 서비스별 prefix에 저장합니다. provider는 모든 모듈에서 = 1.81.163으로 고정합니다.
[03] 성과
권한, 서버, 디스크, 보안그룹 변경 이벤트가 코드로 정의한 추적에 따라 COS에 남습니다. CreateApiKey와 AttachUserPolicy 같은 위험 이벤트도 포함합니다.
배운 점 감사 로그는 남기는 것보다 나중에 읽을 수 있게 나누는 것이 더 중요했습니다. 여러 이벤트를 한 트랙에 섞지 않고 CAM, CVM, CBS, VPC 서비스별 트랙과 COS prefix로 나누면, 검토하는 사람이 권한 변경이나 서버 변경처럼 한 종류씩 읽을 수 있고 보관 기간도 종류별로 따로 정할 수 있습니다. 또 provider를 정확한 버전으로 고정하는 일은 단순한 습관이 아니라, 코드가 그대로인데 plan이 바뀌는 일을 막는 감사 대비 장치라는 것을 알게 됐습니다. 검사 도구를 통과했다는 사실도 그 도구가 얼마나 많은 규칙을 갖고 있느냐에 따라 의미가 달라서, Tencent Cloud처럼 규칙이 적은 환경에서는 무엇을 직접 코드로 기록할지 스스로 정해야 한다는 점을 배웠습니다.
기술 TerraformTencent CloudCloudAuditCOSCAMCLB pf-03-tencent-terraform-audit-ready ↗ Control Plane에서 전체 보기 ↗
Terraform 모듈 16개를 루트 설정 하나로 묶고, Terragrunt가 의존성 그래프를 읽어 순서대로 실행하게 한 구조입니다.
[01] 과제
Terraform 루트마다 backend와 provider 블록을 반복해서 썼고, 루트 사이의 실행 순서는 사람이 기억해야 했습니다.
[02] 수행 내용
모듈은 일반 Terraform으로 두고 Terragrunt로 감쌌습니다. backend, provider, 공통 inputs는 live/root.hcl 한 곳에서 생성합니다. _envcommon이 모듈 source와 dependency를 맡고, 각 유닛은 자기 inputs만 적습니다. dependency 블록으로 그래프를 만들고 mock_outputs로 클라우드 없이 전체를 검증합니다.
[03] 성과
이 레포는 모듈 16개와 유닛 16개를 의존성 4단계로 묶고, 클라우드 자격증명 없이 전체를 검증합니다. 배포 시간 40% 단축은 실제 운영 환경을 이 패턴으로 옮겼을 때 얻은 결과입니다.
배운 점 Terragrunt는 Terraform을 대체하는 도구가 아니라 코드를 어디에 둘지 정리하는 도구라는 점이 핵심이었습니다. 모듈은 일반 Terraform으로 남기고 backend, provider, 공통 inputs는 루트 한 곳에서 만들게 하니, 같은 설정을 16번 복사하던 구조가 설정 하나를 고치면 전체에 반영되는 구조로 바뀌었습니다. 실행 순서도 dependency 블록으로 코드에 적어 두면 사람의 기억에서 그래프로 옮겨 가고, mock_outputs 덕분에 클라우드 자격증명 없이도 전체 연결을 검증할 수 있습니다. 데모에서는 state를 로컬에 두었지만 여러 사람이 함께 쓰는 환경이라면 state 위치부터 정해야 한다는 것도, 구조를 설계할 때 처음부터 고려할 부분으로 배웠습니다.
기술 TerragruntTerraformAWS pf-04-aws-terragrunt-dry-iac ↗ Control Plane에서 전체 보기 ↗
AWS, GCP, Tencent Cloud의 자산·권한·감사 로그를 공통 스키마로 모으고, 위험 이벤트가 생기면 바로 알리는 Python 도구입니다.
[01] 과제
세 클라우드는 같은 개념을 서로 다른 형태로 돌려줍니다. 권한이나 방화벽을 비교하려면 사람이 세 형식을 맞춰 읽어야 했습니다.
[02] 수행 내용
계정별로 STS AssumeRole 등 교차 계정 역할로 접근하고, 자원 종류별 수집기 7개로 모은 결과를 자원별 데이터 클래스 하나로 정규화합니다. Google Sheets와 CSV로 내보내고, 위험 이벤트 16종은 critical_events.yaml 기준으로 Slack과 Telegram에 바로 보냅니다.
[03] 성과
바탕이 된 실무 도구는 Azure를 포함한 4개 클라우드를 매일 새벽에 점검해 월말 며칠의 수동 점검을 없앴고, Terraform 기본값과 CI 관문과 함께 보안 지적 조치율을 60%에서 85% 이상으로 올리는 데 기여했습니다.
배운 점 여러 클라우드를 함께 운영할 때 가장 큰 비용은 데이터를 모으는 일이 아니라 서로 다른 형식을 사람이 맞춰 읽는 일이었습니다. 수집 방식은 클라우드마다 달라도 결과를 자원별 데이터 클래스 하나로 정규화하면, 권한이나 방화벽을 같은 열에서 비교할 수 있고 새 클라우드를 붙일 때도 수집기만 추가하면 됩니다. 위험 이벤트 목록을 코드가 아니라 데이터(critical_events.yaml)로 둔 것도 중요했습니다. 보안 담당자가 Python을 읽지 않고도 규칙을 검토하고 고칠 수 있고, 규칙 변경과 코드 변경이 섞이지 않습니다. 다만 일부 경로는 실제 계정이 아닌 mock으로만 검증했기 때문에, 자동화를 믿을 수 있는 범위는 어디까지 실제로 확인했느냐로 정해진다는 점도 함께 배웠습니다.
기술 Pythonboto3Google Cloud SDKTencent Cloud SDKGoogle SheetsSlackTelegram pf-05-multicloud-asset-audit-automation ↗ Control Plane에서 전체 보기 ↗
직접 만든 오케스트레이터로 AI 직원 11명의 업무 배정, 모델 선택, 비용 추적을 구현한 가상 회사입니다. 에이전트 작업은 시뮬레이션이며 언어 모델 API는 호출하지 않습니다.
[01] 과제
여러 AI 직원이 역할별로 일을 나눠 맡으면 누가 어떤 모델을 쓰는지, 비용이 어디까지 갔는지, 외부 시스템에 무엇을 쓸 수 있는지 코드로 통제해야 합니다.
[02] 수행 내용
CEO 지시를 비서(경영기획실장)가 받아 계획을 쓰고 역할별 Task로 나눕니다. 직원별로 Anthropic, OpenAI, Google, DeepSeek 모델의 우선순위를 두고 실패하면 다음 모델로 전환합니다. 예상 비용을 쌓아 80%와 95%에서 경고하고 100%에서 작업을 막습니다. 외부 쓰기는 기본 차단, 파일 접근은 프로젝트 루트로 제한합니다.
[03] 성과
FastAPI 웹 대시보드 8페이지에서 조직도, 비용, 로그, 픽셀 오피스 CCTV를 봅니다. API 키 없이 실행되고 언어 모델은 호출하지 않으므로 실제 작업 결과물은 나오지 않습니다. Slack, Jira, GitHub 클라이언트는 실제 코드이며 INTEGRATIONS_LIVE_WRITE를 켤 때만 동작합니다.
배운 점 실제로 에이전트끼리 일을 넘기게 해 보니, 한 에이전트의 잘못된 결과를 다음 에이전트가 검증 없이 그대로 믿었습니다. 그때 신뢰 경계와 권한 범위는 프롬프트의 당부가 아니라 코드 안에 있어야 한다는 것을 체감했습니다. 그래서 이 프로젝트에서는 모델 선택, 예산 차단, 외부 쓰기, 파일 접근 범위처럼 위험이 생길 수 있는 지점을 모두 코드의 규칙으로 두었습니다. 외부 쓰기는 기본으로 막고 설정을 켤 때만 허용하며, 예산은 80%와 95%에서 경고하고 100%에서 멈춥니다. AI가 많은 일을 맡을수록 사람이 정해야 하는 것은 무엇을 시킬지보다 어디까지 허용할지라는 점을 배웠습니다.
기술 PythonFastAPIWebSocketpytestSlackJiraGitHub pf-06-aethercrew-ai-company ↗ Control Plane에서 전체 보기 ↗
방화벽 요청이 이미 열려 있는지 먼저 확인하고, 막힌 것만 미리보기 뒤 적용하며, 실제 트래픽으로 검증하는 CLI입니다.
[01] 과제
방화벽 요청은 이미 열린 통신을 다시 여는 경우가 많아 중복 규칙이 쌓였고, 어떤 리소스와 규칙이 걸리는지 계정마다 콘솔에서 찾아야 했습니다.
[02] 수행 내용
netops confirm이 주소를 AWS 리소스로 식별하고 보안그룹 규칙과 라우트를 평가합니다. 막힌 통신만 modify로 넘겨 계획을 먼저 출력합니다. flowlog는 CloudWatch Logs나 Athena에서 실제 트래픽을 찾습니다.
[03] 성과
기본 실행은 아무것도 바꾸지 않습니다. 규칙 추가에는 --apply와 apply 입력이 필요하고, 규칙은 추가만 가능하며, 슬롯이 없는 보안그룹은 고르지 않습니다.
배운 점 변경 도구에서는 안전한 동작이 플래그 없이 되는 기본값이어야 한다는 점을 배웠습니다. --dry-run 방식은 누군가 한 번 깜빡하면 바로 실제 변경이 일어나지만, 기본 실행이 아무것도 바꾸지 않고 --apply와 apply 입력이 둘 다 있어야 적용되면 실수가 변경으로 이어지지 않습니다. 변경 범위를 규칙 추가로만 좁힌 것도 같은 이유입니다. 할 수 있는 일을 줄이면 잘못됐을 때의 피해도 줄어듭니다. 또 요청을 받자마자 규칙을 여는 대신 이미 열려 있는지부터 확인하고, 막혔다면 규칙 때문인지 경로 때문인지 이유를 나눠 남기니, 중복 규칙이 쌓이지 않고 실제로 필요한 조치만 남았습니다.
기술 Pythonboto3AWSCloudWatch LogsAthenaExcel pf-09-aws-netops-firewall-automation ↗ Control Plane에서 전체 보기 ↗
그 외 참여 프로젝트 버디크러시: 판타지 골프 · 워너비챌린지 · 사커스피리츠
field-notes.log / 24 notes
일하며 마주친 문제를 문제·판단·실행·결과로 남긴 기록입니다.
탐지 → 차단 자동화 · 사람 개입 0
이미 쌓이던 Azure 로그를 연결해, DDoS 공격의 탐지부터 차단까지 사람의 개입 없이 이어지게 만들었습니다.
월 1회 → 매일 · 4 Clouds
월말에 며칠씩 수동으로 하던 4개 클라우드 보안 점검을, 위험 행위를 발생 당일 알아차리는 매일 자동 점검으로 바꿨습니다.
1 Week · 0 Downtime · 80 Servers / 20 DBs
서머너즈워 크로니클의 GCP 인프라(서버 80대, DB 20개)를 서비스 중단 없이 약 1주일 만에 Tencent Cloud로 옮겼습니다.
IaC 0 → Terraform 표준화
망분리 규정을 문서로 두지 않고 구조와 코드로 옮겨, 계정이 늘어나도 같은 보안 기준이 반복되게 했습니다.
3,500 Servers · 650 DBs
서버 3,500대, DB 650개 규모 글로벌 MMORPG의 전담 엔지니어로 Azure 운영과 기술 자문을 맡았습니다.
Azure대규모 운영고객 대응 전체 기록 보기 ↗
80% 개선 · 500 Servers / 100 DBs
사람이 서버 묶음마다 반복하던 배포 단계를 PowerShell 스크립트로 묶어 배포 속도를 80% 개선했습니다.
AzurePowerShell배포 자동화 전체 기록 보기 ↗
Telegraf, InfluxDB, Grafana로 실시간 대시보드를 만들고 Zabbix와 Grafana로 모니터링을 운영했습니다.
MonitoringGrafana 전체 기록 보기 ↗
60% → 85%+
보안 지적을 서비스 영향도로 나누고 보완 통제로 합의하며, 반복 지적은 코드 기본값으로 막아 감사 조치율을 60%에서 85% 이상으로 올렸습니다.
CSPMTerraformGitLab CI/CDJenkins협업 전체 기록 보기 ↗
-40% 배포 시간
운영 중인 인프라를 코드로 옮기고 환경마다 복사하던 Terraform 코드를 Terragrunt 공통 구조로 묶어 배포 시간을 40% 줄였습니다.
TerraformTerragruntIaCAWSGCP 전체 기록 보기 ↗
600 Servers / 70 DBs
Tencent Cloud와 GCP에 걸친 서버 600대, DB 70개 규모의 방화벽 규칙을 전수 분석해 역할 기준으로 재설계했습니다.
FirewallTencent CloudGCPNetwork Security 전체 기록 보기 ↗
서버 600대 규모 게임의 DDoS 탐지와 방어를 Tencent Cloud와 GCP에서 운영했습니다.
DDoSCloud ArmorTencent CloudGCP 전체 기록 보기 ↗
서버·DB 지표를 Zabbix와 Grafana로 보고, 이상이 생기면 Slack과 Telegram 알림으로 대응했으며, 월별 비용도 분석했습니다.
ZabbixGrafanaFinOps 전체 기록 보기 ↗
로컬 LLM과 벡터 DB로 인프라 코드 생성 프로토타입을 만들어 팀에 시연했고, 검증에서 한계를 찾아 다음 설계까지 정리했습니다. 실무 정착까지는 이어가지 못했습니다.
AILLMRAGOllamaChromaDockerTerraform 전체 기록 보기 ↗
서비스 계정과 역할별 권한을 Terraform으로 정의해, 과도한 권한 부여가 구조적으로 어렵도록 만들었습니다.
IAMZero TrustTerraform 전체 기록 보기 ↗
GuardDuty, Security Hub, Splunk SIEM을 연동해 다중 AWS 계정 전반의 보안 이벤트를 한곳에서 모니터링했습니다.
GuardDutySecurity HubSplunkSIEM 전체 기록 보기 ↗
CDN + 로드밸런서 구조에서 해외 접속 차단 정책이 우회될 수 있는 지점을 찾아 고치고, 차단 결과를 로그로 증명했습니다. 이미 수정된 사례입니다.
WAFCloudFrontAthenaLog Analysis 전체 기록 보기 ↗
도구 4종 · Python 패키지 31종 오프라인 번들
인터넷이 막힌 업무 PC에서 돌아가는 오프라인 개발 환경과 Python 도구 4종을 만들어, 반복되던 통신 요청 처리를 표준 절차로 바꿨습니다.
Pythonboto3AWS자동화폐쇄망 전체 기록 보기 ↗
보안그룹 정책을 담당자들이 익숙한 물리 방화벽 정책서 구조로 문서화해, AWS가 처음인 담당자도 바로 업무를 시작할 수 있게 했습니다.
DocumentationSecurity Group온보딩 전체 기록 보기 ↗
FortiGate 패킷 캡처 명령 구성과 pcapng 파일 변환을 Python으로 자동화해 분석 준비 시간을 줄였습니다.
FortiGatePacket CapturePython 전체 기록 보기 ↗
방화벽과 WAF, WIPS를 운영하며 매월 정기 점검 보고서를 작성했고, 퇴사할 때 이 업무를 인수인계서로 정리해 넘겼습니다.
FortinetWAFWIPS정기 점검 전체 기록 보기 ↗
신규 가상화 인프라 도입 심의의 보안 부문을 맡아, 요건을 정리하고 수치로 검증한 뒤 통신 방향별 역할 분담을 제안했습니다.
보안성 검토망분리마이크로세그멘테이션 전체 기록 보기 ↗
11 Agents · 3 Divisions
직접 설계한 오케스트레이터로 AI 직원 11명의 가상 회사를 만들며, 에이전트가 서로를 검증 없이 믿는 신뢰 경계 문제를 체감했습니다.
AIMulti-AgentSlack 전체 기록 보기 ↗
콘솔에서 하나씩 따라가며 확인하던 AWS 통신 경로를, 다이어그램에서 두 리소스만 고르면 판정하는 서비스로 만들고 있습니다.
AWSVisualizationSaaSBYOCCloudFormationAI 전체 기록 보기 ↗
기존 GitHub 실습·도구 저장소를 번호 붙인 공개 저장소로 재구성하고, 각 경험과 연결하고 있습니다.
GitHubTerraformTerragrunt 전체 기록 보기 ↗
STACK
막대 = 케이스 스터디 12개 중 그 기술을 쓴 사례 수
TerraformTerragruntAWSGCPAzureTencent CloudPythonPowerShellBashGitLab CI/CDJenkinsZabbixGrafanaSplunkDocker
RECORD
병역 기간 포함
정보통신학과 학위 수여
6개월 / 800시간. 가상의 고객사를 AWS로 이전하는 프로젝트 수행
통신병(교환병)
유효
유효
유효
유효
유효
유효
만료
만료
만료
만료
만료
만료
만료
만료
만료
"소중한 날개2"(서울시립 망우청소년수련관)로 현지 학교의 시설 보강을 도왔고, 체육대회 진행도 함께했습니다.
README
사람의 기억에 기대던 인프라와 보안을, 코드가 지키는 구조로 바꿉니다
게임 서비스부터 금융권까지 AWS·GCP·Azure·Tencent 4개 클라우드(CSP)에서 최대 서버 3,500대·DB 650개 규모의 인프라를 운영했습니다. Terragrunt 전환으로 배포 시간을 40% 줄였고, CSPM(클라우드 보안 설정 점검) 조치율을 60%에서 85% 이상으로 올렸던 경험을 가지고 있습니다.
씨앤토트 — 고객의 대규모 게임을 지키다. Azure 매니지드 서비스(MSP) 기업에서 게임사 고객을 전담한 메인 엔지니어로 설계·구축·운영·보안 감사·배포 자동화를 맡았습니다.
컴투스플랫폼 — 4개 클라우드를 직접 운영하고 옮기다. 게임 서비스를 위한 AWS·GCP·Azure·Tencent 4개 CSP 멀티클라우드 인프라의 설계·구축·운영·장애 대응을 총괄한 메인 엔지니어입니다.
우리FIS — 규제 환경에서 처음부터 설계하다. 우리은행·우리카드·우리금융지주 등 계열사의 하이브리드 환경(퍼블릭·프라이빗 클라우드, 온프레미스)에서 클라우드 보안 아키텍처를 설계·구축·운영했습니다.
클라우드 인프라·보안 포지션에서 함께할 팀을 찾고 있습니다.