바이브 코딩(Vibe Coding)이 자연어로 코드를 생성하는 것이라면, 바이브옵스(VibeOps)는 자연어로 인프라를 운영하는 것입니다. 이전 글에서 바이브옵스의 기본 개념과 제미나이 CLI, 클로드 코드를 활용한 기본적인 사용법을 다뤘는데, 이번 글에서는 조금 다른 이야기를 해보려고 합니다.

실제로 진행한 대규모 인프라 변경 프로젝트에서 AI 코파일럿인 Claude Code를 열심히 활용하며 발견한 문제들과 이를 해결하기 위해 자연스럽게 만들어진 4계층 문서 체계(Four-Layer Document Architecture)와 Command Guardrails 패턴을 소개할 예정입니다.

이 구조는 처음부터 설계된 것이 아닙니다. AI와 함께 일하면서 부딪힌 한계를 하나씩 보완한 결과물입니다. 따라서 누구나 자신의 환경에서 점진적으로 도입할 수 있다는 것이 핵심입니다.

AI에게 단순히 명령을 시키는 것이 아니라, AI가 올바르게 행동하도록 구조를 설계하는 방법에 대해 말해 보겠습니다.

문제 인식: 제한된 리소스의 제약

앞서도 저는 이와 유사한 프로젝트를 진행한 적이 있습니다. 24시간 무중단으로 운영하는 중요한 플랫폼의 대규모 변경 작업이었습니다. V1에서 V2로 넘어가는 차세대 프로젝트로 예정된 일이었습니다.

여기에 제약 조건까지 있었습니다. 리소스가 제한적이어서 DevOps/SRE 1명이 DEV와 PROD를 동시에 구축할 뿐만 아니라 운영에 필요한 모든 요소의 배포 설정을 진행해야 했습니다.

쿠버네티스 기반의 플랫폼이었기 때문에, 할 일로는 다수의 노드와 수백 개의 파드, 다수의 Helm 릴리스에 Kafka, Redis 같은 데이터 계층의 전환, 옵저버빌리티 스택 전체 재구축, 수십 개의 알림 규칙과 알림 경로까지 포함되어 있었습니다. 단순 복제가 아니라 아키텍처 현대화를 포함하는 전면 재설계 작업이었습니다.

전통적 접근의 한계

전통적인 DevOps/SRE 워크플로우는 Wiki를 읽고, 터미널에서 수작업을 하고, 결과를 다시 Wiki에 기록하는 순서로 진행됩니다. 그런데 여기에는 문제가 있습니다.

IaC(Infrastructure as Code)는 선언적이지만 상황에 따른 판단은 하지 못합니다. 한편 Runbook은 상황마다 달라서 그대로 실행하기 어렵고, 자동화 스크립트는 그 자체의 유지보수가 또 다른 부담이 됩니다. 그래서 이런 질문을 던졌습니다.

만약 runbook을 이해하고, 상황에 맞게 판단하고, 실행까지 하는 동료가 있다면 어떨까?

그에 대한 답으로 Claude Code를 전면에 활용하기로 결정했습니다. 규모가 큰 프로젝트라서 AI를 쓴 것이 아니라 제한된 리소스라는 제약 속에서 AI를 동료로 삼는 방법을 찾아야 한 것입니다.

4계층 문서 체계의 탄생

이러한 협업을 위해 만든 4계층 문서 체계는 처음부터 설계된 것이 아닙니다. 단계마다 AI의 한계를 발견하고, 그 한계를 보완하기 위한 계층을 하나씩 추가하면서 자연스럽게 진화한 결과입니다. 각 계층이 왜 필요해졌는지를 순서대로 살펴보겠습니다.

Layer 1: work-plans, 사람이 읽는 계획서

가장 먼저 만든 것은 사람이 읽고 판단하기 위한 상세 계획서입니다. 한국어로 쓰며, 각 컴포넌트의 Why, How, 트레이드오프를 문서화합니다.

work-plans/
├── 00-main/              # 마스터 플랜 + DEV/PROD 런북
├── 10-infrastructure/    # EKS, 스토리지, AWS 연동
├── 20-platform/          # Prometheus, Loki, Tempo, ArgoCD
├── 30-data/              # Valkey, Kafka, Kafka Streams
├── 40-transition/        # 무중단 전환, Weighted Routing
└── 90-future-projects/

이 문서를 AI에게 그대로 주면 어떻게 될까요? 너무 길고, 맥락이 많고, 한국어와 영어가 섞여 있으니, AI가 핵심을 놓치거나 엉뚱한 부분에 집중하는 현상이 발생했습니다. 사람이 보는 문서와 AI가 보는 문서는 달라야 한다는 것을 깨달았습니다.

Layer 2: claude-context, AI를 위해 증류한 문서

그래서 work-plans의 핵심만을 영어로, 최소한 증류(distill)한 문서를 만들었습니다. AI가 프로젝트 상태를 즉시 파악하는 대시보드 역할을 합니다.

claude-context/
├── 00-project-summary.md     # 프로젝트 1페이지 요약
├── 01-environment-values.md  # 모든 환경 값 (복붙 가능)
├── 02-document-map.md        # 문서 네비게이션 맵
├── 03-current-status.md      # 현재 배포 상태 (라이브)
└── 99-execution-guide.md     # 실행 순서 + 체크리스트

work-plans가 교과서라면 claude-context는 시험 범위 요약노트에 가까운 느낌입니다.

다만 여전히 문제는 있었습니다. AI가 맥락은 이해하는데, 실행할 때 자기 나름대로 명령어를 만들어냈습니다. 예를 들어 “Loki 설치해줘”라고 하면 AI가 helm install 명령을 자체 생성하는데, 버전이 다른데다 values는 누락되고 네임스페이스가 틀리는 일까지 발생했습니다. AI가 이해하는 것과 올바르게 실행하는 것은 다른 문제였습니다.

Layer 3: command-guardrails, AI의 행동 제어

이 계층이 이 글의 핵심인 Command Guardrails 패턴입니다. 각 파일은 단계별 실행 가이드로, 마크다운 안에 bash 블록을 포함하고 있습니다.

command-guardrails/
├── dev/
│   ├── 00-prerequisites/    # KMS, S3, EFS
│   ├── 10-infrastructure/   # EKS, 노드그룹, 애드온
│   ├── 20-platform/         # Helm (Prometheus, Loki...)
│   ├── 30-data/             # Valkey, Kafka
│   ├── 40-transition/       # 알림, 도메인, 트래픽 전환
│   └── 80-rollback/         # 롤백 절차
└── prod/
    └── (동일 구조, PROD 값 + DEV 교훈 반영)

핵심 설계 원칙은 이렇게 잡았습니다. 기존 V1을 보호하며, get, describe, logs만 허용하고, 순서를 00에서 10, 20, 30, 40으로 강제합니다. 즉, AI 시대의 인프라 문서는 사람이 읽는 문서가 아니라, AI가 실행하는 문서라고 정의한 것입니다.

하지만 문제는 하나 더 있었습니다. Guardrail에 helm upgrade prometheus-stack만 적으면 AI가 --set 플래그를 창의적으로 만들어냈습니다. 경우의 수가 폭발하니 재현할 수 없는 배포가 되었습니다.

Layer 4: helm-values, IaC에 가까워진 계층

이 계층은 실제 사고를 2건 겪고 나왔습니다.

사고 1: Mimir 버전 업그레이드

guardrail 문서에 helm upgrade mimir만 적고 --version을 지정하지 않은 일이 있었습니다. AI는 지시를 그대로 실행했고, chart 5.8.0 환경에서 최신 6.0.5로 자동 업그레이드가 됐습니다. Mimir 6.0에는 Kafka 기반 ingest storage 기본 활성화, Nginx 제거 후 Unified Gateway 교체, Rollout-operator 웹훅 기본 활성화라는 세 가지 breaking change가 있어서 기존 5.x의 --set 값들이 6.x 스키마와 맞지 않으면서 ingester, distributor 파드가 전부 CrashLoopBackOff에 빠졌습니다.

이에 맞춰 다시 6.0으로 올리려면 ingest storage 구성, gateway 마이그레이션, CRD 사전 설치까지 한꺼번에 해야 하는데, 1인 DevOps/SRE가 DEV+PROD 동시 구축하는 상황에서 감당할 수준이 아니었습니다.

그래서 helm rollback으로 복구한 다음 5.8.0으로 버전을 고정하고 진행했습니다. 이 사고에서 얻은 교훈이 Layer 4입니다. --version 5.8.0, -f helm-values/mimir.yaml로 버전도 값도 파일로 고정해서 AI에게 해석의 여지를 없앴습니다.

사고 2: 알림 규칙의 false alarm

AI에 “CPU 사용률 80% 넘으면 알림 만들어줘”라고 지시했더니, Grafana alert rule의 relativeTimeRange을 600초(쿼리 범위 10분), for를 5분(조건 지속 시간)으로 설정했습니다. 10분 범위 안에 순간 스파이크가 하나만 찍혀도 조건이 충족되고, 그 스파이크가 윈도우 안에 남아 있는 동안 5분이면 바로 firing이 됩니다.

배포 직후 파드 스케일링 때마다 CPU가 잠깐 튀면서 새벽에도, 배포할 때도 알림이 울렸습니다. 게다가 AI가 같은 패턴으로 알람을 생성했기 때문에, 7개 규칙이 전부 같은 문제를 가지고 있었습니다. 문제를 해결하기 위해 relativeTimeRange을 300초로 줄이고, for를 10분으로 늘리고, 쿼리를 avg_over_time으로 바꿔서 수정했습니다.

여기서 얻은 교훈은, 알림 파라미터도 Guardrail 본문에 쓰면 안 된다는 겁니다. AI는 합리적으로 보이는 값을 만들어내지만, 그게 운영 환경에서 맞는지는 별개 문제이기 때문입니다. 그래서 알림 임계값, 평가 주기, for 기간 같은 파라미터를 전부 helm-values 파일로 빼서 관리하게 됐습니다.

최종적으로 helm 명령어는 다음과 같은 형태가 되었습니다.

helm upgrade loki grafana/loki \
  --version 6.30.0 \        # 버전 고정
  -f helm-values/loki.yaml \ # 값 고정 (IaC)
  -n monitoring \            # 네임스페이스 고정
  --wait --timeout 10m       # 동작 고정

이렇게 4개의 계층이 완성되었습니다. 정리하면 위에서 아래로 갈수록 추상에서 구체로, 자유도는 감소하되 재현성은 증가하는 구조입니다.

Tip. 왜 AI를 위한 문서는 영어로 증류해야 하는가

4계층 체계에서 주목할 점 가운데 하나는 Layer 2(claude-context)가 영어로 작성된다는 것입니다. 이는 단순히 AI가 영어를 더 잘 이해하기 때문만은 아닙니다.

첫째, 토큰 효율성 문제입니다. 한국어는 영어 대비 동일한 내용을 표현하는 데 더 많은 토큰을 소비합니다. Claude Code의 컨텍스트 윈도우는 유한하기 때문에, 같은 정보를 더 적은 토큰으로 전달하는 영어가 효율적입니다.

둘째, 기술 용어의 일관성 문제입니다. 쿠버네티스 생태계의 용어는 대부분 영어 기반입니다. “노드그룹”과 “nodegroup”, “네임스페이스”와 “namespace”가 혼재되면 AI가 매칭에 실패하는 경우가 있습니다. AI가 읽을 문서에서 기술 용어를 영어로 통일하면 이러한 혼선을 방지할 수 있습니다.

셋째, 명령어와의 직접 연결입니다. AI가 context 문서를 읽고 바로 셸 명령어를 생성해야 하는데, 한국어 설명에서 영어 명령어로 전환하는 과정에서 오류가 발생할 확률이 높습니다. 영어로 작성된 context는 명령어 생성까지의 경로를 짧게 만들어 줍니다.

다만 이러한 제약으로, 모든 문서를 영어로 써야 한다는 의미는 아닙니다. Layer 1(work-plans)은 사람이 의사결정을 위해 읽는 문서이므로 한국어가 적합합니다. 즉, “누가 읽느냐”에 따라 언어를 구분하는 것이 핵심입니다.

CLAUDE.md: AI가 가장 먼저 읽는 행동 규칙

4계층 문서 체계 외에 한 가지 더 중요한 요소가 있습니다. 바로 CLAUDE.md 파일입니다. 이 파일은 Claude Code가 프로젝트 디렉터리에 진입했을 때 가장 먼저 읽는 파일로, AI의 행동 규칙(Ground Rules)을 정의합니다.

이전 글에서 제미나이 CLI의 GEMINI.md를 다룬 적이 있는데, CLAUDE.md도 동일한 역할을 합니다. 차이가 있다면 4계층 문서 체계와 결합되어 더 구조적으로 동작한다는 점입니다.

예를 들어, 실제 운영 환경에서 사용되는 CLAUDE.md는 다음과 같은 규칙을 포함합니다.

# Ground Rules

## 허용되는 명령어
- kubectl get / describe / logs 만 허용
- helm list / helm status 만 허용

## 금지되는 명령어
- kubectl delete / apply / patch 금지
- helm install / upgrade / uninstall 금지

## 문서 참조 순서
1. memory/MEMORY.md를 먼저 읽을 것
2. claude-context/에서 현재 상태 파악
3. command-guardrails/에서 실행 가이드 확인
4. guardrail에 없는 명령은 실행하지 말 것

이렇게 적어 두면 AI가 자기 마음대로 명령어를 만들어내는 것을 막을 수 있습니다. 특히 “guardrail에 없는 명령은 실행하지 말 것”이라는 규칙이 중요한데, 이는 AI가 할 수 있는 행동의 범위를 명확하게 제한해 줍니다.

settings.local.json

여기에 더해서 .claude/settings.local.json을 설정하면 V1 보호를 도구 수준에서 강제할 수 있습니다. CLAUDE.md가 자연어로 된 규칙이라면, settings.local.json은 실제로 명령어 실행 자체를 허용하거나 차단하는 설정입니다.

{
  "permissions": {
    "allow": [
      "Bash(kubectl --context=sysnet4admin-v1 get *)",
      "Bash(kubectl --context=sysnet4admin-v1 describe *)",
      "Bash(kubectl --context=sysnet4admin-v1 logs *)",
      "Bash(kubectl --context=sysnet4admin-v2 *)",
      "Bash(helm --kube-context=sysnet4admin-v2 *)",
      "Bash(aws * --profile sysnet4admin *)",
      "Bash(eksctl * --profile sysnet4admin *)"
    ],
    "deny": [
      "Bash(kubectl --context=sysnet4admin-v1 apply *)",
      "Bash(kubectl --context=sysnet4admin-v1 delete *)",
      "Bash(kubectl --context=sysnet4admin-v1 patch *)",
      "Bash(kubectl --context=sysnet4admin-v1 edit *)",
      "Bash(kubectl --context=sysnet4admin-v1 scale *)",
      "Bash(kubectl --context=sysnet4admin-v1 exec *)",
      "Bash(helm --kube-context=sysnet4admin-v1 install *)",
      "Bash(helm --kube-context=sysnet4admin-v1 upgrade *)",
      "Bash(helm --kube-context=sysnet4admin-v1 uninstall *)",
      "Bash(helm --kube-context=sysnet4admin-v1 delete *)"
    ]
  }
}

V1(sysnet4admin-v1)에는 get, describe, logs만 허용하고, apply, delete, patch 같은 변경 명령은 전부 차단합니다. 반면 V2(sysnet4admin-v2)에는 모든 명령을 허용해서 자유롭게 작업할 수 있도록 합니다. 이렇게 하면 CLAUDE.md에서 자연어로 안내하는 규칙을 설정 파일이 실제로 강제하게 되므로, AI가 실수로라도 V1 프로덕션에 변경을 가하는 것을 방지할 수 있습니다.

4계층 문서에 기반한 운영 전략과 도입 방법

이처럼 계층 문서 기반으로 인프라 관리에 접근하다 보니 다양한 변화를 만날 수 있었습니다. AI와 함께 일하며 확장할 수 있는 방향성과 실제 도입 과정에서 느낀 것을 정리했습니다.

1. GitAIOps

이렇게 만들어진 4계층 문서 체계를 Git으로 관리하면 재미있는 부분이 생깁니다. AI를 위해 만든 문서가 동시에 팀 전체의 운영 표준이 되는 것입니다.

이 개념을 GitAIOps라고 부릅니다. GitOps가 선언적 인프라에서 Git을 Single Source of Truth로 삼는 것이라면, GitAIOps는 여기에 AI가 문서를 이해하고 실행하는 계층을 추가한 것입니다. 누가 실행해도 같은 결과가 나오니 일관성이 보장되고, 변경 이력이 남으니 감사 추적이 가능합니다.

2. AI에게 맡기는 것의 경계

4계층 문서 체계를 구축했다고 해서 모든 것을 AI에게 맡길 수 있는 것은 아닙니다. 오히려 이 체계를 운영하면서 AI에게 맡기기 좋은 것과 사람이 판단해야 하는 것의 경계가 더 명확해졌습니다. 무엇보다 AI는 자동 운전이 아니라 운전 보조라는 것을 잊지 말아야 합니다. 핸들은 사람이 잡되, 사각지대를 AI가 잡아준다는 느낌으로 써야 합니다.

3. DEV에서 PROD로: Guardrail 재사용 패턴

4계층 체계가 가장 효과적인 부분은 DEV에서 PROD로 넘어갈 때입니다. DEV에서 검증된 Guardrail을 PROD에 재사용할 때, 단순 복사가 아니라 DEV에서의 교훈을 반영하는 것이 핵심입니다.

실제로 PROD Guardrail에는 DEV 교훈이란 섹션이 자동으로 추가됩니다. 예를 들어 DEV에서 Mimir 버전 사고가 있었다면, PROD Guardrail에는 해당 버전 고정에 대한 경고와 함께 검증된 버전 번호가 명시됩니다. DEV 환경 전체 구축에 약 2일이 걸렸다면, 이 Guardrail을 재사용하는 PROD 환경 구축은 약 1일로 단축됩니다.

이렇게 Guardrail이 축적되면 재사용할수록 구축 속도가 빨라집니다. 그리고 이 패턴은 쿠버네티스에만 적용되는 것이 아닙니다. Terraform, Ansible 등 어떤 IaC 도구를 사용하더라도 동일한 구조를 적용할 수 있습니다.

4. 생산성 변화

직접 AI 기반 운영을 도입하니 아래와 같은 생산성 변화가 일어났습니다. AI가 사람을 대체한 게 아니라, 제한된 리소스의 커버리지를 몇 배로 확장했다는 점을 가장 크게 느꼈습니다.

5. 조직에 적용할 점진적 도입 로드맵

이러한 구조를 우리 조직에 한 번에 도입할 필요는 없습니다. 그보다는 단계적으로 조금씩 접근하는 것이 현실적입니다.

Level 0 (1주):기존 runbook을 구조화된 마크다운 형식의 문서로 정리합니다. 이것만으로도 문서 가독성이 크게 향상됩니다.
Level 1 (2~4주):Claude Code로 DEV 환경에서 실험을 시작합니다. 이전 바이브옵스 글에서 다룬 것처럼, 먼저 DEV에서 충분히 테스트하는 것이 중요합니다.
Level 2 (1~2개월):Context + Guardrails 2계층 체계를 구축합니다. 실제 운영에서 발생하는 문제들을 반영하면서 점진적으로 완성합니다.
Level 3 (지속):DEV에서 PROD로의 패턴이 정착되고, helm-values(IaC)가 추가됩니다. 이 단계에서는 guardrail이 팀의 표준 운영 절차(SOP)가 됩니다.

마치며: DevOps/SRE의 역할 변화

이 글에서 다룬 4계층 문서 체계와 Command Guardrails 패턴을 보면, DevOps 엔지니어와 SRE의 역할이 바뀌고 있다는 것을 알 수 있습니다.

전통적인 DevOps/SRE가 kubectl을 직접 실행하는 사람이었다면, AI-Driven DevOps/SRE는 AI가 실행할 가이드를 설계하는 사람입니다. Runbook을 작성하던 역할은 Guardrails를 설계하는 역할로, 수동으로 감사하던 역할은 AI가 감사한 결과를 검증하는 역할로 바뀝니다. 반복 작업을 수행하는 대신 판단과 의사결정에 집중하게 되고, 혼자 환경 하나만 담당하던 것이 혼자 환경 N개를 커버할 수 있게 됩니다.

AI가 잘하는 것은 최대한 활용하되, 실행에서 틀리지 않도록 구조로 잡아주는 것. 그것이 4계층 문서 체계와 Command Guardrails 패턴이 하는 일이며, 얻어가야 할 교훈입니다.

부록 1: AI의 기억 관리를 위한 Memory 시스템

4계층 문서 체계를 운영하다 보면 자연스럽게 마주치는 문제가 하나 더 있습니다. Claude Code와 긴 대화를 나누다 보면 컨텍스트 압축(compaction)이 발생한다는 것입니다.

예를 들어 35개 알림 규칙을 전수 분석해서 P0/P1/P2로 분류했는데, compaction이 발생하면 원본이 사라지고 “P0/P1/P2 분류 완료”라는 요약만 남습니다. 이 상태에서 “P1 항목이 뭐였지?”라고 물으면 AI는 대답할 수 없게 됩니다.

이 문제를 해결하기 위해 4계층과 동일한 원리를 적용한 memory 시스템을 도입했습니다.

memory/
├── MEMORY.md              # 인덱스 (200줄, 자동 주입)
├── alert-gap-analysis.md  # 토픽 파일 (필요 시 로드)
├── osd-lessons.md         # 토픽 파일 (필요 시 로드)
└── argocd-lessons.md      # 토픽 파일 (필요 시 로드)

시스템이 하는 역할은 크게 4가지입니다. compaction에서 살아남는 맥락 보존, “하지 마라”를 축적한 금지 사항 누적(guardrail 보완), 대화가 끊어져도 이어지는 작업 상태 추적, 그리고 매 세션마다 재탐색 없이 시작하는 콜드 스타트 방지입니다.

여기서 중요한 것은 MEMORY.md의 크기 관리입니다. AI 코딩 에이전트에는 200줄을 초과하면 경고 없이 잘려나가는(hard truncation) 현상이 있고, 오래된 기억은 때로 AI가 잘못된 근거로 판단하는 원인이 됩니다. 실제로 지시 준수율이 200줄 이하에서는 92%인데, 400줄 이상이 되면 71%로 떨어지는 것을 확인했습니다.

따라서 MEMORY.md는 인덱스만 유지하고, 상세 내용은 토픽 파일로 분리합니다. 결국 4계층과 같은 원리입니다. 증류하고, 분리해서, 필요할 때만 로드하기. 이 원칙은 문서 체계뿐 아니라 AI의 기억 관리에도 동일하게 적용됩니다.

부록 2: 옵저버빌리티 감사 데모로 직접 해보기

이 글에서 설명한 구조를 축소해서 직접 체험해볼 수 있는 데모도 준비했습니다. 읽기 전용 감사(Observability Audit)를 수행하는 구성으로, 4계층 중 실행에 해당하는 부분만 뽑아낸 형태입니다.

demo/
├── CLAUDE.md                    # AI 행동 규칙
├── claude-context/
│   └── 00-cluster-summary.md    # 클러스터 맥락
├── command-guardrails/
│   └── observability-audit.md   # 실행 가이드
└── memory/
    └── MEMORY.md                # 누적 기억

데모를 실행하면 CLAUDE.md에서 READ-ONLY만 허용하고, command-guardrails의 9단계 감사 절차를 AI가 순서대로 실행한 다음, 결과를 Audit Report 형식으로 출력합니다. 실제 감사 리포트 결과와 전체 소스는 GitHub에서 확인할 수 있습니다.

작가

조훈(CNCF 앰버서더)

메가존에서 쿠버네티스와 컨테이너 인프라 Tech Evangelist, CoE(Center of Excellence) 역할을 맡고 있다. 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더, ‘IT 인프라 엔지니어 그룹’의 운영진, 오픈소스 컨트리뷰터로도 활동하고 있다. 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하고, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』, 『우아하게 앤서블』, 『시스템/네트워크 관리자를 위한 파이썬 실무 프로그래밍』을 집필하였으며, 요즘IT와 같은 온라인 플랫폼에 글을 기고한다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

글로벌 소셜 플랫폼 기업에서 Site Reliability Engineer로 재직하며, 쿠버네티스 멀티 클러스터 관리와 데이터베이스 플랫폼 운영을 주도하고 있다. 또한 ISMS-P, GDPR, CCPA 등 글로벌 보안 규제에 부합하는 데이터 라이프사이클 파이프라인을 설계·운영한 실무 경험을 가지고 있으며, 쿠버네티스 오픈소스 프로젝트에도 기여하고 있다. 더불어 국내 주요 기업과 국가 기관의 클라우드 전환, 데이터 거버넌스 컨설팅, 보안 컴플라이언스 대응을 지원하고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.