career.tf ✓ DONE

terraform plan -target=module.career

✓ 3 companies · 20 projects · since 2020

Kim JunHyun.

I turn infrastructure and security that relied on people's memory into structures that code protects.

PROFILE2020 — 2026.10

Public Cloud Infrastructure & Security Engineer

IaC automation · Multi-cloud operations · Cloud security · Operations automation · AI agents

Woori FIS 8 mo
Com2us Platform 36 mo
C&Thoth 30 mo

Bars = months at each company (Aug 2020 – Oct 2026)

Woori FIS: Period Feb 2026 – Oct 2026; Role Assistant Manager · Cloud Security Engineer; Projects 1 projects

Pillar height = months at each company. Click a pillar to switch company.

From live games to financial services, running infrastructure across 4 clouds (AWS, GCP, Azure, and Tencent), at up to 3,500 servers and 650 databases. I have experience cutting deployment time by 40% by moving to Terragrunt and raising CSPM (cloud security posture checks) remediation from 60% to 85% or higher.

Email: kimjhtlzk@naver.com
Since: Aug 2020
Education: Kyungmin University, Department of Information and Communication
Service: Military service (Republic of Korea Army, honorably discharged)

IaC automation Define infrastructure as code with Terraform and Terragrunt
Multi-cloud operations Design and operate 4 cloud providers together
Cloud security Detection and response, least privilege, and audit response

CAREER.LOG / 3 companies

Career

Scroll, or use the arrow keys and buttons, to move between companies.

$ open career/01_cnthoth --since 2020.08

01 / 03 · Aug 2020 – Feb 2023

C&Thoth

Associate to Assistant Manager · Cloud Engineer (Azure MSP) · Cloud Service Team

30 months · 5 projects · Azure

Protecting a client's large game

Ran Azure infrastructure for many game services in Korea and worldwide, including dedicated operations for MIR4 Global (3,500 servers and 650 databases)
Automated DDoS detection and blocking with Azure Log Analytics and PowerShell
Improved deployment speed by 80% with PowerShell deployment automation (MIR4 Korea)

See 5 projects

MIR4 Global

$ open career/02_com2us --since 2023.02

02 / 03 · Feb 2023 – Feb 2026

Com2us Platform

Assistant Manager · Cloud Engineer · Infrastructure Technology Office, Cloud Division

36 months · 14 projects · GCP / Tencent / AWS / Azure

Running and moving four clouds

Cut deployment time by 40% by moving from Terraform to Terragrunt
Migrated from GCP to Tencent Cloud with zero downtime (80 servers and 20 databases, completed within one week)
Raised CSPM (cloud security posture check) remediation from 60% to 85% or higher
Cut DragonSky infrastructure costs by up to 62%

See 14 projects

Summoners War: Sky Arena · Summoners War: Chronicles · Starseed: Asnia Trigger · DragonSky: Idle & Merge

$ open career/03_woorifis --since 2026.02

03 / 03 · Feb 2026 – Oct 2026

Woori FIS

Assistant Manager · Cloud Security Engineer · Information Security Department

8 months · 1 projects · AWS

Designing from zero under regulation

Designed and completed Woori Financial Group's first cloud security policy definition after joining, and distributed it to the group's affiliates
Brought AWS Network Firewall, WAF, and Shield security infrastructure under code for the first time, in an environment with no Terraform
Built a Python pipeline that automatically collects and analyzes network communication settings across multiple AWS accounts
Integrated GuardDuty, Security Hub, WAF, Network Firewall, and Shield with a Splunk-based SIEM/SOAR

See 1 projects

Woori Financial Group AWS cloud security

PROJECTS / 12 case studies · 20 services

Career description

Case studies are written as task, action and outcome; the other services get one line each.

Feb 2026 – Oct 2026 · Information Security Department

Woori FIS

Assistant Manager · Cloud Security Engineer

PROJECT 01 / 12 ● Case study

Woori Financial Group AWS security architecture

Role Cloud Security Engineer · Information Security Department · Feb 2026 – Oct 2026 · Multiple AWS accounts

The résumé line

Moved network separation requirements across multiple AWS accounts into subnet and firewall structure, and standardized security settings as one set of Terraform code.

[01] Task

Group companies were adopting public cloud for the first time, with no Terraform in place, and security settings varied by account and by person. Network separation rules were hard to hold in documents alone.

[02] What I did

Network separation (a Korean financial regulation) became three design principles: separate DMZ and Private subnets, no public IP on backends, and outbound only to allowed destinations. WAF, Network Firewall, and Shield Standard are defined in Terraform and applied through the same code to every account, with GuardDuty and Security Hub connected to Splunk SIEM/SOAR.

[03] Outcome

The same security standard repeats through code as accounts grow, and per-person differences are gone. A Python pipeline now collects and analyzes network configuration across multiple AWS accounts, so review is repeatable. IAM permissions are defined in Terraform as well, which structurally blocks excessive grants.

What I learned The biggest lesson was that once security settings become code, differences between accounts show up as differences in code. When each person configured accounts in the console, finding which account differed meant comparing settings one by one; applying the same Terraform code to every account made any difference visible right in the code. Rules that existed only on paper, such as network separation, could be enforced by structure only after they were turned into three principles: separate subnets, no public IPs on the backend, and outbound only to allowed destinations. I also learned that a standard defined in code is complete only when it is confirmed to hold in each account, and the pipeline that collects and analyzes network configuration was built to make that confirmation a repeatable check rather than something people remember.

TaskWhat I didOutcome

One set of Terraform code applies this design the same way across multiple AWS accounts.

5 Security services connected to Splunk SIEM/SOAR
3 Design principles from network separation
1 Set of Terraform code across multiple AWS accounts

Tech TerraformAWS Network FirewallAWS WAFAWS Shield StandardGuardDutySecurity HubSplunkPython Read it in Control Plane ↗

Services I ran · 1 projects

Feb 2026 – Oct 2026
Woori Financial Group AWS cloud security
AWS

Brought Network Firewall, WAF, and Shield security infrastructure to the affiliates' multiple AWS accounts with Terraform for the first time, and designed and distributed the group's cloud security policy definition.

→

Feb 2023 – Feb 2026 · Infrastructure Technology Office, Cloud Division

Com2us Platform

Assistant Manager · Cloud Engineer

PROJECT 02 / 12 ● Case study

Zero-downtime migration from GCP to Tencent Cloud

Role Cloud Engineer · Main engineer · Feb 2023 – Feb 2026 · 80 servers · 20 databases

The résumé line

Moved 80 servers and 20 databases of Summoners War: Chronicles from GCP to Tencent Cloud in about one week with no downtime.

[01] Task

A live game had to move between clouds without stopping, and the firewall policy could not drift during the move.

[02] What I did

Network and firewall rules were built on Tencent to match GCP first. Servers moved with the Online Migration tool and the same infrastructure was built. It then ran privately while the dev team checked for issues, and traffic moved in stages. The whole effort moved GCP Terraform code to Tencent Terraform code.

[03] Outcome

The migration finished in about one week with no downtime. Some systems stayed on GCP while most game servers and databases moved to Tencent, and the firewall policy was fully reviewed and rebuilt along the way.

What I learned The first step in moving between clouds was not moving servers but pairing the two clouds' resources by role. Mapping network, subnet, firewall, and server first made it simple to turn GCP Terraform code into Tencent Terraform code, and the firewall policy could be fully reviewed and rebuilt along the way. Avoiding downtime came from not switching everything at once: the same infrastructure was built first and run privately while issues were checked with the dev team, and traffic moved in stages. The infrastructure ended up as code, but I learned that the traffic cutover steps also need to live as code and a runbook for the next migration to repeat the same result.

TaskWhat I didOutcome

It finishes in about one week with zero downtime, and the whole move is recorded from GCP Terraform code to Tencent Terraform code.

80 Servers migrated
20 Databases migrated
0 Downtime

Tech TerraformGCPTencent CloudOnline Migration Read it in Control Plane ↗

PROJECT 03 / 12 ● Case study

Summoners War: Sky Arena multi-cloud and firewall redesign

Role Cloud Engineer · Main engineer · Feb 2023 – Feb 2026 · 600 servers · 70 databases · Massive

The résumé line

A massive game platform across GCP and Tencent Cloud, with 600 servers and 70 databases, a full firewall policy redesign, and patching with no maintenance window.

[01] Task

This was the company's largest project, with Tencent added for service in China. Firewall policies across the two clouds had grown duplicated and complex, and code spread across many regions had become hard to manage with Terraform alone.

[02] What I did

A full analysis of cross-cloud firewall policies removed duplicate and unneeded rules and regrouped the rest by role: web, game, database, and admin. Terraform moved to a Terragrunt structure to remove code duplication. Most servers sat behind load balancers, so patches rolled through by taking servers out and back one at a time.

[03] Outcome

Simpler firewall policies were easier to review and change, with a smaller exposed surface. Moving to Terragrunt cut deployment time by 40%, and GCP Cloud Armor provided DDoS protection.

What I learned The big lesson was that a firewall policy that only ever gains rules soon becomes unreadable. Regrouping long-accumulated rules by role, web, game, DB, and management, made it obvious where to look for any change and shrank the exposed surface along with it. Code hit the same problem at scale, so Terraform that had grown across many regions had to move to a Terragrunt structure to strip out the duplication. Running without maintenance windows came less from any special technique than from a structure where servers sit behind load balancers and can be taken out and put back one at a time. And because a policy cleaned up by one full analysis piles up again over time, I learned that cleanup has to be a recurring check, not a one-time job.

TaskWhat I didOutcome

What remains is regrouped by server role, which makes rules easier to review and change.

600 Servers
70 Databases
-40% Deployment time after moving to Terragrunt

Tech GCPTencent CloudTerraformTerragruntCloud Armor Read it in Control Plane ↗

PROJECT 04 / 12 ● Case study

Dragon Sky FinOps: 62% lower infrastructure cost

Role Cloud Engineer · Main engineer · Feb 2023 – Feb 2026 · 10 servers · 5 databases

The résumé line

Linked revenue metrics with infrastructure cost and found unused resources automatically every day with Python, cutting infrastructure cost by up to 62%.

[01] Task

Infrastructure cost was high relative to game revenue, which hurt profitability.

[02] What I did

Revenue metrics and infrastructure cost were monitored together. Python found unused resources across every cloud automatically each day.

[03] Outcome

Infrastructure cost fell by up to 62%.

What I learned I learned that cost is easier to judge against revenue than as an amount on its own. Putting infrastructure cost next to revenue metrics made it clear which resources affect profitability and what to cut first. Cost leaks also do not end after one cleanup, so detecting unused resources every day in Python, instead of someone looking now and then, was what kept the savings in place. Detection alone saves nothing until resources are actually removed, which showed me that the next step in cost management is a flow that takes each finding quickly to cleanup approval and action.

TaskWhat I didOutcome

Infrastructure cost fell by up to 62%.

-62% Maximum infrastructure cost reduction
10 Servers
5 Databases

Tech AzurePythonBilling monitoring Read it in Control Plane ↗

Services I ran · 14 projects

Feb 2023 – Feb 2026
Summoners War: Sky Arena
GCP / Tencent · servers 600 · DB 70 · Main Engineer

The company's largest project. Multi-cloud operations under a "no maintenance downtime" principle, plus a full firewall redesign.

→
Feb 2023 – Feb 2026
Summoners War: Chronicles
GCP / Tencent · servers 80 · DB 20 · Main Engineer

Zero-downtime migration from GCP to Tencent. Rebuilt every firewall policy during the migration.

→
Feb 2023 – Feb 2026
Com2uS Pro Baseball V25
GCP · servers 90 · DB 8 · Main Engineer

One of the first games to adopt GKE on GCP.
Mar 2024 – Feb 2026
Summoners War: Rush
Tencent · servers 76 · DB 11 · Main Engineer

Game infrastructure operations on Tencent Cloud.
Jul 2024 – Feb 2026
Gods & Demons
GCP · servers 66 · DB 12 · Main Engineer

Game infrastructure operations on GCP.
Sep 2023 – Feb 2026
Starseed: Asnia Trigger
AWS · servers 50 · DB 20 · Main Engineer

Centered on EKS. Moved Terraform to Terragrunt and cut deployment time by 40%.

→
Mar 2023 – Feb 2026
MLB Rivals
GCP · servers 23 · DB 5 · Main Engineer

Centered on GKE, with autoscaling to manage load.
Feb 2023 – Feb 2026
DragonSky: Idle & Merge
Azure · servers 10 · DB 5 · Main Engineer

Linked revenue to costs and cut infrastructure costs by up to 62%.

→
Feb 2023 – Feb 2026
Summoners War: Lost Centuria
GCP · servers 8 · DB 2 · Main Engineer

Game infrastructure operations on GCP.
Feb 2023 – Feb 2026
Golf Star
GCP · servers 6 · DB 2 · Main Engineer

Game infrastructure operations on GCP.
Feb 2023 – Feb 2026
Ace Fishing: Crew
Tencent · servers 4 · DB 2 · Main Engineer

Game infrastructure operations on Tencent Cloud.
Oct 2023 – Feb 2026
Idle Strikers 1945
Azure · servers 4 · DB 1 · Main Engineer

Game infrastructure operations on Azure.
Jun 2023 – Feb 2026
Strikers1945: RE
Tencent · servers 3 · DB 2 · Main Engineer

A project that went through a migration from GCP to Tencent.
Mar 2024 – Feb 2026
Minigame Party: Pocket Edition
GCP · servers 3 · DB 4 · Main Engineer

Revival of a classic game. Evaluated moving to Tencent over cost, then stayed on GCP.

Aug 2020 – Feb 2023 · Cloud Service Team

C&Thoth

Associate to Assistant Manager · Cloud Engineer (Azure MSP)

PROJECT 05 / 12 ● Case study

MIR4 Global: massive Azure infrastructure and automated DDoS blocking

Role Cloud Engineer · Main engineer (client: WEMADE) · Jul 2021 – Feb 2023 · 3,500 servers · 650 databases · Massive

The résumé line

Dedicated operation of a global game with 3,500 servers and 650 databases on Azure, plus a pipeline that finds DDoS sources in logs and adds them to an NSG automatically.

[01] Task

At this scale, a physical failure or an attack could spread across the global service. Night and weekend DDoS attacks were slow to answer when a person had to block them by hand.

[02] What I did

Involved from the first design stage, I helped set a high-availability layout on Azure Dedicated Host. Mitigation flow logs from Azure DDoS protection are queried on a schedule in Log Analytics to find abnormal TCP SYN sources, and PowerShell adds those IPs to an NSG deny rule.

[03] Outcome

Detection to block runs with no human step, which removed the delay at night and on weekends. Resource deployment, automated incident fixes, and asset collection were also automated in PowerShell.

What I learned I learned that for the service to survive one physical host failing, spreading dedicated hosts across separate fault zones is the baseline. At this scale, failures and attacks spread across the global service, so such decisions had to be made from the first design stage rather than added during operation. For DDoS, so that response speed was not tied to when someone was awake, finding abnormal sources in the logs and adding them to the NSG block became one automated flow. And the more blocking is automatic, the more each block needs its reason recorded, so a person can review the decision later.

TaskWhat I didOutcome

As main engineer, the work covered design advice, incident response, and security audits.

3,500 Servers
650 Databases
0 Human steps from detection to block

Tech AzureDedicated HostPowerShellLog AnalyticsNSG Read it in Control Plane ↗

Services I ran · 5 projects

Jul 2021 – Feb 2023
MIR4 Global · WEMADE
Azure · servers 3,500 · DB 650 · Main Engineer

My first main engineer role and the largest scale I have worked on. On-site advisory at the client and PowerShell automation.

→
Feb 2022 – Feb 2023
MIR M Korea · WEMADE
Azure · servers 700 · DB 150 · Main Engineer

Large game infrastructure operations, including ISMS and CSPM response.
Dec 2020 – Feb 2023
MIR4 Korea · WEMADE
Azure · servers 500 · DB 100 · Sub Engineer

Improved deployment speed by 80% with PowerShell deployment automation. DDoS detection and defense in Korea.
Dec 2020 – Feb 2023
The Legend of Mir 2/3 Korea · WEMADE
Azure · servers 200 · DB 40 · Sub Engineer

Game infrastructure operations, including ISMS and CSPM response.
Mar 2021 – Feb 2023
ADT-CAPS (SK Shieldus)
Azure · servers 10 · DB 2

First non-game project. Storage management and ISMS and CSPM response.

pf-01 · pf-02 · pf-03 · pf-04 · pf-05 · pf-06 · pf-09

GitHub Lab

Public repos · personal projects

PROJECT 06 / 12 ● Case study

AWS multi-region Terraform

Role Design and implementation · Personal project · released Nov 2026 · 16 regions · 24 modules · 3 examples

The résumé line

A Terraform module set that builds the same infrastructure in 16 AWS regions from one locals map per region.

[01] Task

The same resources had to exist in many regions. More regions meant more copied code and a higher risk that regions drift apart.

[02] What I did

A locals map per region declares the wanted state, and module plus for_each creates it all. Each region has a provider alias that assumes the same role. Terraform cannot choose a provider dynamically inside for_each, so the module block repeats per region.

[03] Outcome

A change is one map entry, and stable keys mean reordering never recreates anything. The 24 modules carry defaults for encryption, IMDSv2, and private S3, and three examples cover networks, EKS, and alerting.

What I learned Stable keys mattered as much as less repetition. count identifies resources by their position in a list, so inserting or reordering an entry can recreate everything after it, while for_each identifies them by map key, so the same resource is addressed whatever the order. Terraform cannot pick a provider inside for_each, and instead of hiding that limit, I repeated the module block per region in plain sight, which turned out easier to read and change. Since then, when the same structure has to exist in many places, I separate data (the map) from code (the module) first, and I judge the design by whether a change ends at one map entry.

TaskWhat I didOutcome

Adding a region means one more locals entry and one more module block.

16 Regional provider aliases
24 Terraform modules
3 Validated examples

Tech TerraformAWSEKSCloudWatchAWS Chatbot pf-01-aws-terraform-multi-region ↗ Read it in Control Plane ↗

PROJECT 07 / 12 ● Case study

GCP Terraform GKE platform

Role Design and implementation · Personal project · released Nov 2026 · 22 modules · 3 examples

The résumé line

A module set that keeps capacity during GKE node pool upgrades with SURGE, and opens only what a VPN needs through a firewall baseline, all as code.

[01] Task

A GKE node upgrade must not reduce serving capacity, and management ports should open only from a VPN.

[02] What I did

The node pool upgrades with SURGE: five new nodes come up first and unavailable stays at zero. The c2sfirewall module opens management ports from the VPN at priority 1000 and denies other tcp and udp outbound at priority 65534.

[03] Outcome

Old nodes leave only after replacements are ready. Host errors flow from the hostError audit log to a log-based metric, an alert policy, and a Slack channel.

What I learned I learned that judging behavior from a setting's name can be wrong. A value like soak time sounds as if it applies to every upgrade, but it is read only under the BLUE_GREEN strategy, so the SURGE example states in a comment that the value has no effect there. Protecting capacity during upgrades also works only when the intent is pinned in numbers, such as bring five new nodes up first (max_surge 5) and take none away (max_unavailable 0), so the result stays the same whoever runs it. The firewall follows the same idea: the module ships a baseline that opens only management ports at priority 1000 and blocks the rest at 65534, so every new environment starts from the same rules.

TaskWhat I didOutcome

The swap finishes. The 3600s soak value is read only under BLUE_GREEN.

22 Terraform modules
5 Extra nodes first (max_surge)
0 Nodes down at once (max_unavailable)

Tech TerraformGCPGKECloud LoggingCloud Monitoring pf-02-gcp-terraform-gke-platform ↗ Read it in Control Plane ↗

PROJECT 08 / 12 ● Case study

Tencent Cloud audit-ready Terraform

Role Design and implementation · Personal project · released Nov 2026 · 18 modules · 3 examples

The résumé line

Tencent Cloud modules that define CloudAudit tracks per service, so risky changes land in a COS bucket.

[01] Task

Changes on Tencent Cloud needed a per-service record of who did what. The provider also ships on an irregular cycle, so a new version could change a plan without any code change.

[02] What I did

CloudAudit tracks are defined per service in code for CAM, CVM, CBS, and VPC, and each stores to its own COS prefix. Every module pins the provider to = 1.81.163.

[03] Outcome

Permission, server, disk, and security group changes reach COS through the tracks defined in code, including risky events such as CreateApiKey and AttachUserPolicy.

What I learned With audit logs, making them readable later mattered more than keeping them at all. Instead of mixing events into one stream, separate tracks and COS prefixes for CAM, CVM, CBS, and VPC let a reviewer read one kind of change at a time, such as permissions or servers, and set retention per kind. I also learned that pinning the provider to an exact version is not just habit but an audit safeguard: it keeps a plan from changing while the code stays the same. And a passing scan means only as much as the rules behind it, so on Tencent Cloud, where scanners have few rules, I had to decide for myself what to record in code.

TaskWhat I didOutcome

Who changed what piles up in COS by service, ready to be read one kind at a time.

18 Terraform modules
4 Audit tracks by service
19 Audit events tracked in code

Tech TerraformTencent CloudCloudAuditCOSCAMCLB pf-03-tencent-terraform-audit-ready ↗ Read it in Control Plane ↗

PROJECT 09 / 12 ● Case study

AWS Terragrunt DRY IaC

Role Design and implementation · Personal project · released Nov 2026 · 16 modules · 16 units · 4 dependency levels

The résumé line

Sixteen Terraform modules behind one root config, with Terragrunt running them in order from their dependency graph.

[01] Task

Each Terraform root repeated its backend and provider blocks, and the order between roots lived in people's heads.

[02] What I did

Modules stay plain Terraform and Terragrunt wraps them. The backend, provider, and common inputs are generated once from live/root.hcl. _envcommon holds module sources and dependencies, and each unit states only its inputs. dependency blocks build the graph, and mock_outputs let the whole stack validate without a cloud account.

[03] Outcome

This repository groups 16 modules and 16 units into four dependency levels and validates them without cloud credentials. The 40% shorter deployment time came from moving a live production estate to this pattern.

What I learned The key point was that Terragrunt does not replace Terraform; it decides where code lives. Modules stay plain Terraform while the backend, provider, and common inputs are generated from one root, so a structure that copied the same settings 16 times became one where a single edit reaches everything. Writing run order as dependency blocks moves it from people's memory into a graph, and mock_outputs let the whole stack validate without cloud credentials. The demo keeps state local, but where several people share an environment, where state lives has to be settled first, and I now treat that as part of the design from day one.

TaskWhat I didOutcome

16 Terraform modules and units
1 Root config replacing 16 copies
-40% Deployment time (production result)

Tech TerragruntTerraformAWS pf-04-aws-terragrunt-dry-iac ↗ Read it in Control Plane ↗

PROJECT 10 / 12 ● Case study

Multi-cloud asset and audit automation

Role Design and implementation · Personal project · released Nov 2026 · 3 clouds · 7 collectors · 49 audit actions

The résumé line

A Python tool that collects assets, permissions, and audit logs from AWS, GCP, and Tencent Cloud into one schema, and alerts on risky events.

[01] Task

Each cloud returns the same concept in a different shape. Comparing permissions or firewalls meant reading three formats by hand.

[02] What I did

Each account is reached through a cross-account role such as STS AssumeRole. Seven collectors, one per resource type, feed a single data class per resource. Output goes to Google Sheets and CSV, and 16 critical events alert Slack and Telegram immediately based on critical_events.yaml.

[03] Outcome

The production tool behind this code checked four clouds including Azure every day before dawn, removed several days of manual month-end review, and together with Terraform defaults and CI gates helped raise the remediation rate from 60% to over 85%.

What I learned When running several clouds together, the biggest cost was not collecting data but people lining up different formats by hand. Collection differs per cloud, but normalizing the results into one data class per resource lets permissions or firewalls be compared in the same columns, and adding a cloud means adding a collector. Keeping the critical event list as data (critical_events.yaml) instead of code mattered too: a security reviewer can read and change the rules without reading Python, and rule changes never mix with code changes. Some paths were verified only with mocks, not live accounts, which taught me that how far automation can be trusted is set by how much of it was actually checked.

TaskWhat I didOutcome

Audit sheets are copied to CSV once a month into year and month folders.

3 Clouds covered by the public code
7 Collectors by resource type
49 Audit actions tracked (16 alert immediately)

Tech Pythonboto3Google Cloud SDKTencent Cloud SDKGoogle SheetsSlackTelegram pf-05-multicloud-asset-audit-automation ↗ Read it in Control Plane ↗

PROJECT 11 / 12 ● Case study

AetherCrew: a virtual company of 11 AI employees

Role Design and implementation · Personal project · released Nov 2026 · 11 AI employees · 3 divisions · 8 dashboard pages

The résumé line

A hand-built orchestrator that assigns work, picks models, and tracks cost for 11 AI employees in a virtual company. Agent work is simulated and no language model API is called.

[01] Task

When AI employees split work by role, code must control which model each one uses, how much has been spent, and what can be written to outside systems.

[02] What I did

The chief of staff takes a CEO directive, writes a plan, and splits it into tasks by role. Each employee has a priority list of Anthropic, OpenAI, Google, and DeepSeek models and moves to the next on failure. Estimated costs add up, with warnings at 80% and 95% and work stopped at 100%. External writes are off by default, and file access stays inside the project root.

[03] Outcome

Eight FastAPI dashboard pages show the org chart, cost, logs, and a pixel-art CCTV office. It runs with no API keys and calls no language model, so it produces no real work output. The Slack, Jira, and GitHub clients are real code and run only when INTEGRATIONS_LIVE_WRITE is on.

What I learned When I let agents hand work to each other, a wrong result from one agent was trusted as-is by the next, with no check in between. That is when I felt that trust boundaries and permission scope must live in code, not in a polite request inside a prompt. So in this project, every point where risk can arise, such as model choice, budget stops, external writes, and file access, is a rule in code. External writes are blocked by default and allowed only when a setting is turned on, and the budget warns at 80% and 95% and stops at 100%. The more work AI takes on, the more the human decision shifts from what to ask for to how far to allow it.

TaskWhat I didOutcome

In the public code, agent work is simulated and no language model API is called.

11 AI employees
3 Divisions
8 Dashboard pages

Tech PythonFastAPIWebSocketpytestSlackJiraGitHub pf-06-aethercrew-ai-company ↗ Read it in Control Plane ↗

PROJECT 12 / 12 ● Case study

AWS firewall request automation

Role Design and implementation · Personal project · released Nov 2026 · 3-step CLI · 4 input formats · 4 resource types

The résumé line

A CLI that checks whether a firewall request is already open, previews changes only for what is blocked, and verifies the real traffic.

[01] Task

Firewall requests often asked for flows that were already open, which added duplicate rules, and finding the related resources and rules meant searching the console account by account.

[02] What I did

netops confirm resolves addresses to AWS resources and evaluates security group rules and routes. Only blocked flows go to modify, which prints a plan first. flowlog searches CloudWatch Logs or Athena for the actual traffic.

[03] Outcome

By default nothing changes. Adding a rule needs --apply and a typed apply, rules can only be added, and a security group without free slots is never chosen.

What I learned In a change tool, the safe action has to be the default that needs no flag. With --dry-run, one forgotten flag means a real change, but when the default run changes nothing and applying needs both --apply and a typed apply, a mistake never becomes a change. Narrowing changes to adding rules only follows the same idea: the less a tool can do, the less harm it can cause when it is wrong. And instead of opening a rule as soon as a request arrives, checking first whether the path is already open, and recording whether a block comes from a rule or a route, stopped duplicate rules from piling up and left only the changes that were really needed.

TaskWhat I didOutcome

flowlog searches CloudWatch Logs or Athena for the actual traffic.

3 Steps: confirm, modify, flowlog
4 Input formats
4 Resource types identified

Tech Pythonboto3AWSCloudWatch LogsAthenaExcel pf-09-aws-netops-firewall-automation ↗ Read it in Control Plane ↗

Other projects Birdie Crush: Fantasy Golf · Wannabe Challenge · Soccer Spirits

field-notes.log / 24 notes

Field notes

Problems met at work, recorded as problem, decision, execution and result.

E2 · C&Thoth · Aug 2020 – Feb 2023

Stopping 3 a.m. DDoS attacks with no one on the keyboard

Detect → block automated · 0 human steps

Connected Azure logs that already existed so DDoS detection through blocking runs with no human steps.
- Attacks clustered at night and on weekends, when response was slowest
- Solved at no added cost by reusing existing logs
- Detection results feed firewall rules automatically
Read the full record ↗
E5 · Com2us Platform · Feb 2023 – Feb 2026

From a monthly security review to a daily automatic one

Monthly → Daily · 4 Clouds

Replaced a multi-day manual month-end review of four clouds with a daily automatic one that surfaces risky actions the same day.
- Found the gap myself, with no one asking
- One standard across four different cloud log formats
- Only critical actions trigger an alert and follow-up
Read the full record ↗
E8 · Com2us Platform · Feb 2023 – Feb 2026

Moving a live game between clouds without stopping it

1 Week · 0 Downtime · 80 Servers / 20 DBs

Moved the GCP infrastructure of Summoners War: Chronicles (80 servers, 20 databases) to Tencent Cloud in about one week with zero downtime.
- Decided to move firewalls before servers
- Migration tool plus private validation
- The entire migration captured in Terraform code
Read the full record ↗
E13 · Woori FIS · Feb 2026 – Oct 2026

Setting a security baseline for a financial cloud that had none

IaC 0 → Terraform standard

I moved network separation rules out of documents and into structure and code, so every new account gets the same security baseline.
- Financial network separation turned into design principles
- Network Firewall and WAF standardized as code
- The same baseline as accounts are added
Read the full record ↗

[E1] Dedicated engineer for a 3,500-server global game C&Thoth · Aug 2020 – Feb 2023
3,500 Servers · 650 DBs

Dedicated engineer for a global MMORPG with 3,500 servers and 650 databases, covering Azure operations and technical advice.
- Lead technical contact for the client
- High-availability architecture advice
- Incident response, security audit, and cost analysis support
AzureLarge-scale operationsClient-facing Read the full record ↗
[E3] Deploying to 500 servers, 80% faster C&Thoth · Aug 2020 – Feb 2023
80% faster · 500 Servers / 100 DBs

Bundled deployment steps people repeated for every server group into PowerShell scripts, making deployments 80% faster.
- Manual steps repeated for every server group
- Steps bundled into a script that runs automatically
- One procedure instead of one per engineer
AzurePowerShellDeployment automation Read the full record ↗
[E4] Infrastructure status at a glance, in real time C&Thoth · Aug 2020 – Feb 2023
Built real-time dashboards with Telegraf, InfluxDB, and Grafana, and ran monitoring with Zabbix and Grafana.
- Real-time dashboards with Telegraf, InfluxDB, and Grafana
- Monitoring operations with Zabbix and Grafana
MonitoringGrafana Read the full record ↗
[E6] Making sure the same finding never comes back Com2us Platform · Feb 2023 – Feb 2026
60% → 85%+

Sorted security findings by service impact, agreed on compensating controls, and turned repeated findings into code defaults, raising the audit remediation rate from 60% to over 85%.
- Sorted by service impact instead of blocking everything
- Agreed on compensating controls when blocking was not possible
- Repeated findings became Terraform defaults and deployment gates
CSPMTerraformGitLab CI/CDJenkinsCollaboration Read the full record ↗
[E7] One codebase instead of copied infrastructure code Com2us Platform · Feb 2023 – Feb 2026
-40% deploy time

Moved live infrastructure into code and replaced copied Terraform with a shared Terragrunt structure, cutting deployment time 40%.
- Moved running infrastructure into code
- Replaced per-environment and per-game copies with a shared structure
- Security defaults apply to every environment at once
TerraformTerragruntIaCAWSGCP Read the full record ↗
[E9] Redesigning a tangle of firewall rules Com2us Platform · Feb 2023 – Feb 2026
600 Servers / 70 DBs

Reviewed every firewall rule across Tencent Cloud and GCP for 600 servers and 70 databases, then redesigned them around server roles.
- Reviewed every long-accumulated rule
- Removed duplicate and unnecessary rules
- Redesigned around server roles
FirewallTencent CloudGCPNetwork Security Read the full record ↗
[E10] Stopping attacks on game servers Com2us Platform · Feb 2023 – Feb 2026
Ran DDoS detection and defense for a 600-server game on Tencent Cloud and GCP.
- Ran DDoS detection and defense for a 600-server game
- Used Cloud Armor for DDoS protection on GCP
DDoSCloud ArmorTencent CloudGCP Read the full record ↗
[E11] Knowing first when something goes wrong Com2us Platform · Feb 2023 – Feb 2026
Watched server and database metrics with Zabbix and Grafana, responded to Slack and Telegram alerts, and analyzed monthly costs.
- Monitoring with Zabbix and Grafana
- Alerts through Slack and Telegram
- Monthly cost analysis (FinOps)
ZabbixGrafanaFinOps Read the full record ↗
[E12] An AI that writes infrastructure code from a plain request Com2us Platform · Feb 2023 – Feb 2026
Built an infrastructure code generation prototype with a local LLM and a vector database, demoed it to the team, and found its limits in testing. It did not reach day-to-day use.
- RAG structure using production modules as reference material
- Taken as far as a team demo
- Diagnosed the limits myself and drew up the next design
AILLMRAGOllamaChromaDockerTerraform Read the full record ↗
[E14] Only the access you need, recorded in code Woori FIS · Feb 2026 – Oct 2026
I defined service account and role permissions in Terraform, so that granting too much access became structurally difficult.
- Zero Trust principle
- Service account and role permissions in Terraform
- New permissions must pass code review
IAMZero TrustTerraform Read the full record ↗
[E15] Alerts from many accounts on one screen Woori FIS · Feb 2026 – Oct 2026
I connected GuardDuty, Security Hub, and Splunk SIEM to monitor security events across multiple AWS accounts in one place.
- GuardDuty and Security Hub connected to Splunk SIEM
GuardDutySecurity HubSplunkSIEM Read the full record ↗
[E16] "Turned on" and "actually blocking" are different things
In a CDN and load balancer setup, I found where a geo-block policy could be bypassed, fixed it, and proved the block with logs. This case is already fixed.
- Found the bypass by tracing the architecture
- Fixed it by moving the check to the outer edge
- Verified the block through log analysis
WAFCloudFrontAthenaLog Analysis Read the full record ↗
[E17] Operations tools that run on a PC with no internet Woori FIS · Feb 2026 – Oct 2026
4 tools · 31 Python packages, bundled offline

I built an offline development environment and four Python tools for work PCs with no internet, turning repeated traffic requests into a standard process.
- Offline Windows development environment bundle
- Reachability checks that name the cause
- Excel request forms applied as real security group rules
Pythonboto3AWSAutomationClosed network Read the full record ↗
[E18] Explaining in the language the other person already knows Woori FIS · Feb 2026 – Oct 2026
I documented security group policies in the physical firewall format the team already knew, so engineers new to AWS could start work right away.
- Security group policies documented in the physical firewall policy format
- An access and operations guide for engineers new to AWS
DocumentationSecurity GroupOnboarding Read the full record ↗
[E19] Less time spent capturing packets Woori FIS · Feb 2026 – Oct 2026
I automated FortiGate capture commands and pcapng file conversion with Python, which shortened the time needed to prepare an analysis.
- FortiGate packet capture commands built automatically
- pcapng files converted in one pass
FortiGatePacket CapturePython Read the full record ↗
[E20] Owning the security checks that repeat every month Woori FIS · Feb 2026 – Oct 2026
I operated firewalls, WAF, and WIPS, wrote the regular monthly review reports, and documented that work in handover notes when I left.
- Operated FortiGate, FortiManager, FortiAnalyzer, WAF, and WIPS
- Monthly firewall policy adequacy reviews
- Handed the work over with written handover notes
FortinetWAFWIPSRegular reviews Read the full record ↗
[E21] A security review that tested requirements with numbers Woori FIS · Feb 2026 – Oct 2026
I handled the security part of a review for adopting a new virtualization platform. I organized the requirements, tested them with numbers, and proposed a split of duties by traffic direction.
- Security requirements organized into common, physical, and logical
- Platform capacity compared with the required level, in figures
- Proposed a split of duties for north-south and east-west traffic
Security reviewNetwork separationMicrosegmentation Read the full record ↗
[P1] A virtual company staffed by 11 AI employees Personal projects
11 Agents · 3 Divisions

I built a virtual company of 11 AI employees on a hand-built orchestrator, and saw firsthand the trust boundary problem when agents accept each other's work without checks.
- Role-based assignment, model priority with fallback, and cost tracking
- Slack, Jira, and GitHub connections, plus a pixel-art office dashboard
- Firsthand experience of agents trusting each other without checks
AIMulti-AgentSlack Read the full record ↗
[P2] A service that answers "can these two talk?" in two clicks Personal projects
I am turning the manual work of tracing AWS traffic paths in the console into a service where you pick two resources on a diagram and get an answer.
- AWS resources across accounts and regions in one diagram
- Reachability between two resources, with the policy behind it
- Installed in the customer's own environment (BYOC)
AWSVisualizationSaaSBYOCCloudFormationAI Read the full record ↗
[P3] A public repository series for this portfolio Personal projects
I am rebuilding my existing GitHub practice and tool repositories as numbered public repositories and linking them to each experience.
- Rebuilt as numbered public repositories
- Keys and sensitive values masked or replaced with examples
- Each repository linked to the related experience
GitHubTerraformTerragrunt Read the full record ↗

STACK

Strengths and skills

Core strengths

IaC automation Define infrastructure as code with Terraform and Terragrunt
Multi-cloud operations Design and operate 4 cloud providers together
Cloud security Detection and response, least privilege, and audit response
Operations automation Remove repetitive work with Python and PowerShell
AI agents Build multi-agent systems with defined roles and permissions

My skills

Bars = case studies (out of 12) that used the tool

Terraform 7 / 12 cases
Python 5 / 12 cases
AWS 3 / 12 cases
GCP 3 / 12 cases
Tencent Cloud 3 / 12 cases
Terragrunt 2 / 12 cases
boto3 2 / 12 cases
Slack 2 / 12 cases
Azure 2 / 12 cases

Tools I use

TerraformTerragruntAWSGCPAzureTencent CloudPythonPowerShellBashGitLab CI/CDJenkinsZabbixGrafanaSplunkDocker

RECORD

Education & certifications

Education · training · service

Mar 2015 – Feb 2020
Kyungmin University, Department of Information and Communication
Includes the military service period
Dec 2019 – Aug 2020
Bachelor's degree, Academic Credit Bank System (National Institute for Lifelong Education)
Degree conferred in Information and Communication
Feb 2020 – Jul 2020
KG ITBANK: AWS Architecture Design Specialist Training Program
6 months, 800 hours. Project: migrating a fictional client to AWS
Dec 2016 – Sep 2018
Military service (Republic of Korea Army, honorably discharged)
Sergeant. Signal soldier (switchboard operator)

Certifications

2021.08.18
NCP — Naver Cloud Platform Certified Professional
Valid
2021.07.07
NCA — Naver Cloud Platform Certified Associate
Valid
2021.06.02
Engineer Information Processing (Korean national certification)
Valid
2020.10.22
Microsoft Azure Fundamentals (AZ-900)
Valid
2019.10.11
Linux Master Level 2
Valid
2019.07.09
Network Administrator Level 2
Valid
2022.12.18
HashiCorp Certified: Terraform Associate
Expired
2022.12.16
CKA — Certified Kubernetes Administrator
Expired
2022.06.09
Microsoft Azure Database Administrator Associate
Expired
2022.06.08
Microsoft Azure Solutions Architect Expert
Expired
2022.06.07
Microsoft Azure Administrator Associate
Expired
2022.05.29
AWS Certified Solutions Architect – Professional
Expired
2021.07.01
Microsoft Azure Architect Technologies
Expired
2021.06.18
Microsoft Azure Security Engineer Associate
Expired
2020.06.23
AWS Certified Solutions Architect – Associate
Expired

Activity

2013
Volunteer work in Nepal
Joined "Precious Wings 2" (Seoul Metropolitan Mangwoo Youth Center) to help reinforce facilities at a local school, and also helped run its sports day.

README

About me

I turn infrastructure and security that relied on people's memory into structures that code protects.

C&Thoth — Protecting a client's large game. Main engineer dedicated to game company clients at an Azure managed service provider (MSP), covering design, build, operations, security audits, and deployment automation.

Com2us Platform — Running and moving four clouds. Main engineer in charge of design, build, operations, and incident response for multi-cloud game service infrastructure across 4 cloud service providers (CSPs): AWS, GCP, Azure, and Tencent.

Woori FIS — Designing from zero under regulation. Designed, built, and operated cloud security architecture for affiliates including Woori Bank, Woori Card, and Woori Financial Group, across a hybrid environment of public cloud, private cloud, and on-premises.

Principles from the work

Before adding a tool, see what the logs you already have can do.
Stop at "no" and the conversation ends. Bring an alternative and things get fixed.
Put the rule in structure and code, and every deployment meets the same bar.
AI supports the judgment. A person approves the action.

Looking for a team to join in a cloud infrastructure or security role.

kimjhtlzk@naver.com Download PDF ↓

Kim JunHyun.

Career

C&Thoth

Com2us Platform

Woori FIS

Career description

Woori FIS

Woori Financial Group AWS security architecture

Services I ran · 1 projects

Com2us Platform

Zero-downtime migration from GCP to Tencent Cloud

Summoners War: Sky Arena multi-cloud and firewall redesign

Dragon Sky FinOps: 62% lower infrastructure cost

Services I ran · 14 projects

C&Thoth

MIR4 Global: massive Azure infrastructure and automated DDoS blocking

Services I ran · 5 projects

GitHub Lab

AWS multi-region Terraform

GCP Terraform GKE platform

Tencent Cloud audit-ready Terraform

AWS Terragrunt DRY IaC

Multi-cloud asset and audit automation

AetherCrew: a virtual company of 11 AI employees

AWS firewall request automation

Field notes

Stopping 3 a.m. DDoS attacks with no one on the keyboard

From a monthly security review to a daily automatic one

Moving a live game between clouds without stopping it

Setting a security baseline for a financial cloud that had none

Strengths and skills

Core strengths

My skills

Tools I use

Education & certifications

Education · training · service

Certifications

Activity

About me

Principles from the work