김전호 · 운영 포트폴리오Jeonho James Kim · Operations Portfolio
Operations Portfolio · 운영 포트폴리오Operations Portfolio

김전호 — 대규모 글로벌 서비스 운영 · CloudOps & AIOps · AI SaaSJeonho James Kim — Large-scale Global Service Operations · CloudOps & AIOps · AI SaaS

IT 21년 / 클라우드·SRE 13년 · 前 삼성전자 삼성클라우드 SRE 리드 · 現 insighta.one AI SaaS 1인 풀스택 · AWS SA – Professional21 years IT / 13 in cloud & SRE · ex-Samsung Cloud SRE lead · now building an AI SaaS solo at insighta.one · AWS SA – Professional
Abstract · 초록Abstract

삼성클라우드에서 5개 리전 멀티클라우드로 MAU 2.4억 글로벌 서비스를 24×7 운영, 4개국 60~70명·상황실 3곳을 리드했다. 운영을 CloudOps 프레임워크(SOF)로 체계화하고 Self-Healing(40%↓)·4,000 WAS 무중단·통합계정(30%↑)·분산SQL(50%↓, 공개근거)을 실증. 이후 Insighta를 1인으로 구축·운영. 각 사례를 문제 → 아키텍처 → 역할·구현 → 정량 성과로 정리한다.Ran a global service (MAU 240M) across 5 multi-cloud regions at Samsung Cloud, leading 60–70 people across 4 countries and 3 NOCs. Systematized it into the CloudOps framework (SOF), proven by Self-Healing (−40%), a zero-downtime 4,000-WAS migration, unified IAM (+30%), a distributed-SQL cutover (−50%, public-sourced). Then built Insighta solo. Each case: problem → architecture → role → quantified result.

Insighta

인사이타Insighta

2025–현재2025–present
1인 풀스택 · 라이브 AI SaaS (web + app 다이얼)Solo full-stack · live AI SaaS (web + Dial app)
주요 고객·파트너Key clients · partners한컴HancomNvidiaNvidia
I서비스 · RAG 파이프라인 · 모델Service · RAG Pipeline · Models

유튜브 학습을 만다라트 9×9 지식그래프(=페르소나)에 축적해 '알고리즘이 아니라 사용자 목표가 콘텐츠를 큐레이션'하는 AI 학습 플랫폼을 기획~AI까지 1인으로 구축·운영한다. 이중 품질 게이트 RAG로 환각·저품질 응답을 구조적으로 차단한다.I built and run — solo, from planning to AI — an AI learning platform where 'the user's goal, not an algorithm, curates content', accumulating YouTube learning into a 9×9 Mandalart knowledge graph (= persona). A double-quality-gate RAG structurally blocks hallucination and low-quality answers.

Insighta · 이중 품질 게이트 RAG in 1 Diagram
Jeonho James Kim — 1인 풀스택 · insighta.one 라이브
5단 RAG 품질 게이트 2개 1인 팀
인프라 React / TS Fastify (Prisma) PostgreSQL + pgvector ‖ Python AI Sidecar (분리) AWS EC2 Terraform GitHub Actions 1인 팀 → 자동화가 곧 가용성
RAG 파이프라인 — 검색에서 학습 경로까지
목표 (Goal) 만다라트 9×9 분해
1 Qwen3-Embedding-8B 4096d dense 벡터 · 다국어
2 pgvector 검색 DB 내 ANN — 별도 저장소 없음
3 Cohere 리랭킹 품질 게이트 1 — 재현율보다 정밀도 GATE 1
4 LLM-as-Judge relevance
groundedness
safety GATE 2 — 3단계 판정
5 Picker (경로 선별) 게이트를 통과한 후보로 학습 경로를 조립
설계 판단 1 pgvector 일원화 = make-or-buy 별도 벡터 스토어 없음 — 하나의 DB, 하나의 백업, 하나의 운영 표면.
설계 판단 2 Python 사이드카 분리 = 경계 설계 독립 배포 · 장애 격리 — AI 경로가 죽어도 앱은 살아있다.
설계 판단 3 대화 원문 미저장 = 아키텍처로 강제한 프라이버시 저장되지 않는 것은 유출될 수 없다 — 정책이 아니라 구조로 강제.
번호 배지 = 파이프라인 순서 · GATE 1 / GATE 2 = 이중 품질 게이트. 두 게이트를 모두 통과한 후보만 학습 경로에 도달. insighta.one 라이브
Insighta · RAG with a Double Quality Gate in 1 Diagram
Jeonho James Kim — solo full-stack, live at insighta.one
5-stage RAG 2 quality gates team of 1
Infra React / TS Fastify (Prisma) PostgreSQL + pgvector ‖ Python AI Sidecar (separate) AWS EC2 Terraform GitHub Actions a team of one → automation is availability
RAG Pipeline — retrieval to learning path
Goal Mandalart 9×9 decomposition
1 Qwen3-Embedding-8B 4096d dense vectors · multilingual
2 pgvector search in-database ANN — no separate store
3 Cohere reranking quality gate #1 — precision over recall GATE 1
4 LLM-as-Judge relevance
groundedness
safety GATE 2 — 3-step verdict
5 Picker assembles the learning path from gated candidates
Design judgment 1 pgvector unification = make-or-buy no separate vector store — one database, one backup, one operational surface.
Design judgment 2 Python sidecar split = boundary design independent deploy, failure isolation — the AI path can crash without taking the app down.
Design judgment 3 Transcripts not stored = privacy by architecture what is never persisted can never leak — privacy enforced by structure, not policy.
Numbered badges = pipeline order · GATE 1 / GATE 2 = the double quality gate. Only candidates that pass both gates reach the learning path. live at insighta.one
그림 I.Fig. I. RAG — pgvector 일원화 + 분리된 Python 사이드카(만다라트→임베딩→검색→리랭킹→LLM-Judge→Picker).RAG — pgvector unification + a separate Python sidecar (Mandalart→embed→search→rerank→LLM-Judge→Picker).
파이프라인 · 모델Pipeline · models
  • React/TS ↔ Fastify(Prisma) ↔ PostgreSQL+pgvector + 분리된 Python AI 사이드카 (AWS EC2·Terraform)React/TS ↔ Fastify(Prisma) ↔ pgvector + separate Python AI sidecar (AWS EC2·Terraform)
  • 챗봇 = Qwen3-30B-A3B MoE(3B active) LoRA(22,744 SFT쌍, loss 1.85→0.62) · vLLM 서빙 · 학습=추론 프롬프트 바이트 동일 불변식Chatbot = Qwen3-30B-A3B MoE (3B active) LoRA (22,744 SFT pairs, loss 1.85→0.62) · vLLM-served · byte-identical train=inference prompt invariant
  • RAG — Qwen3-Embedding-8B 임베딩 → Cohere 리랭킹 → LLM-as-Judge → LLM Picker(Claude Haiku) · 영상 풀은 BGE-M3 별도RAG — Qwen3-Embedding-8B → Cohere reranking → LLM-as-Judge → LLM Picker (Claude Haiku) · BGE-M3 for the video pool
  • 프로덕션 안정성 — throw-free 다중 프로바이더 폴백(단일 실패가 응답을 안 막음)·user_id 테넌트 격리·페르소나로 환각 12%→3%Production reliability — throw-free multi-provider fallback (no single failure blocks a response)·user_id tenant isolation·persona cut hallucination 12%→3%
  • 요약 멀티모델(Qwen3.5-9B 등) 품질 점수·세그먼트 Haiku 스코어러(보간 0)·트랜스크립트 미저장Summary multi-model (incl. Qwen3.5-9B) quality scoring · segment Haiku scorer (interpolation-0) · no transcript storage
12%→3%
환각률(페르소나)hallucination (persona)
이중 게이트Dual gate
환각 구조적 차단hallucination gate
Live
insighta.oneinsighta.one
역량Capability — 기획·인프라·AI까지 1인 풀스택 — LoRA 챗봇(loss 1.85→0.62)·throw-free 다중프로바이더 RAG로 insighta.one 라이브, 페르소나로 환각 12%→3%.Solo full-stack from planning to AI — a LoRA chatbot (loss 1.85→0.62) and throw-free multi-provider RAG run insighta.one live, with persona cutting hallucination 12%→3%.
참고Refsinsighta.oneinsighta.one
I온톨로지 · 지식그래프 (pgvector 그래프DB)Ontology · Knowledge Graph (pgvector graph DB)

학습 조각(카드·영상·노트)들이 어떻게 연결되는지 보여줄 구조가 없었다. 만다라트를 중심축으로 한 서비스 온톨로지를 설계해, 사용자 행동이 스스로 노드-엣지 그래프로 쌓이도록 만들었다.Knowledge fragments (cards, videos, notes) had no way to show how they connect. I designed a Mandalart-centric service ontology so that user actions accumulate themselves into a node–edge graph.

온톨로지 · 지식그래프 in 1 Diagram
Jeonho James Kim — Insighta · 1인 풀스택
12 노드 · 8 엣지 2 도메인 프로덕션 177 노드
스키마 · 딕셔너리 구동
12노드타입 — 사용자 9 · 시스템 3
8엣지타입 — 사용자 5 · 시스템 2 · 공유 1
신규 타입 = 딕셔너리 행 추가 (DDL 0)
사용자 엣지 5종
CONTAINS PLACED_IN DERIVED_FROM REFERENCES TAGGED_WITH
pgvector 일원화그래프 + 벡터 + RLS 단일 스토어. Neo4j 대비 $0 · 재귀 CTE 순회 (100K 노드 전까지).
자가 구축 (Materialize-on-Reference)사용자 행동(카드·만다라·영상)이 섀도 트리거로 노드·구조 엣지를 자동 생성.
서비스 ≠ 시스템 도메인 분리 CHECK + 크로스도메인 엣지 거부 — 사용자 그래프만 노출
CONTAINS
CONTAINS
PLACED_IN
REFERENCES
DERIVED_FROM
TAGGED_WITH
만다라트 셀중심축 · 완료데이터 SSOT
섹터mandala_sector
목표goal
리소스resource
노트note
소스 · 세그먼트source · segment
토픽tagging
만다라트 중심 온톨로지 — 학습 조각(카드·영상·노트)이 타입 노드와 라벨 엣지로 연결·시각화된다.
완료데이터 SSOT = 북인덱스(chapter=만다라 셀 · section=영상) → GraphRAG 기반.
Ontology · Knowledge Graph in 1 Diagram
Jeonho James Kim — Insighta · solo full-stack
12 nodes · 8 edges 2 domains 177 nodes in prod
Schema · dictionary-driven
12node types — user 9 · system 3
8edge types — user 5 · system 2 · shared 1
New type = a dictionary row (0 DDL)
USER EDGES (5)
CONTAINS PLACED_IN DERIVED_FROM REFERENCES TAGGED_WITH
pgvector unifiedGraph + vector + RLS in one store. vs Neo4j: $0 · recursive-CTE traversal (until 100K nodes).
Self-building (Materialize-on-Reference)User actions (cards·mandalas·videos) auto-create nodes & structural edges via shadow triggers.
Service ≠ system domain split CHECK + cross-domain-edge rejection — only the user graph is exposed
CONTAINS
CONTAINS
PLACED_IN
REFERENCES
DERIVED_FROM
TAGGED_WITH
Mandalart cellcentral axis · completed-data SSOT
Sectormandala_sector
Goalgoal
Resourceresource
Notenote
Source · segmentsource · segment
Topictagging
Mandalart-centric ontology — learning fragments (cards·videos·notes) connect and visualize as typed nodes and labeled edges.
Completed-data SSOT = book-index (chapter=Mandalart cell · section=video) → GraphRAG basis.
그림 I.Fig. I. 만다라트 중심 온톨로지 — 12노드·8엣지, 사용자 행동이 섀도 트리거로 자가 구축, pgvector로 그래프·벡터 일원화.Mandalart-centric ontology — 12 nodes·8 edges, self-built via shadow triggers, graph and vectors unified on pgvector.
설계Design
  • 서비스 온톨로지 — 12 노드타입·8 엣지(사용자 9·5 + 시스템 3·2 + 공유 RELATED_TO), 딕셔너리 구동(신규 타입=DDL 없이 행 추가)Service ontology — 12 node types · 8 edge types (user 9·5 + system 3·2 + shared RELATED_TO), dictionary-driven (new type = a row, no DDL)
  • PostgreSQL+pgvector로 그래프·벡터·ACID·RLS 일원화 — Neo4j 대비 트레이드오프($0 vs $65/mo·재귀 CTE 순회, '100K 노드 전까지 단일 스토어')PostgreSQL+pgvector unifies graph·vector·ACID·RLS — a deliberate trade-off vs Neo4j ($0 vs $65/mo, recursive-CTE traversal, 'one store until 100K nodes')
  • 자가 구축 그래프 — 사용자 행동(카드·만다라·영상)이 섀도 트리거로 노드·구조 엣지 자동 생성(Materialize-on-Reference), 프로덕션 177 노드Self-building graph — user actions (cards·mandalas·videos) auto-create nodes & structural edges via shadow triggers (Materialize-on-Reference); 177 nodes in production
  • 서비스≠시스템 도메인 분리(CHECK + 크로스도메인 엣지 거부) · 완료데이터 SSOT=북인덱스(chapter=만다라 셀·section=영상) → GraphRAG 기반service ≠ system domain split (CHECK + cross-domain-edge rejection) · completed-data SSOT = book-index (chapter=Mandalart cell · section=video) → GraphRAG basis
12·812N · 8E
노드·엣지(2 도메인)nodes·edges (2 domains)
pgvector
그래프·벡터 단일 스토어single graph+vector store
177
프로덕션 노드prod nodes
역량Capability — 만다라트를 12노드·8엣지 온톨로지로 정의하고, 사용자 행동이 섀도 트리거로 그래프를 자가 구축, 그래프·벡터·RLS를 pgvector 하나로 일원화(Neo4j 없이).Defined a 12-node, 8-edge ontology in which user actions self-build the graph via shadow triggers, unifying graph, vectors and RLS on a single pgvector store (no Neo4j).
I데이터셋 · 파인튜닝 · 모바일(Dial)Dataset · Fine-tuning · Mobile (Dial)

품질을 데이터로 끌어올리기 위해, 3단계 자동 검증 파이프라인으로 자체 만다라트 데이터셋을 구축하고 파인튜닝·모바일까지 확장했다.To raise quality with data, I built an own Mandalart dataset through a 3-stage automated validation pipeline, extending to fine-tuning and mobile.

데이터셋 · 파인튜닝 in 1 Diagram
Jeonho James Kim — Insighta · 만다라트 V3 데이터셋 파이프라인
3단계 품질 게이트 18,009 임베딩
생성물을 통과 못 하면 재생성하는 3단계 게이트로 걸러, 검증된 데이터셋만 남긴다.
reject
→ 재생성 ≤3회
생성 — 9 도메인 × ~111/언어 (KO + EN)center goal → 8 sub-goals → 64 actions · V1 API → V2 템플릿 → V3 Claude-Code 직생성
Gate 1 · 구조 검증 — 8 서브목표 + 64 액션 완전성빈칸·중복 = 재생성
Gate 2 · 품질점수 ≥ 0.7측정가능성 30% · 카테고리 균형 20% · HIGH 태그 20% · 추상어 페널티 30%
Gate 3 · LLM-as-Judge10건당 1 트렌드 샘플링 → 미달 discard
만다라트 데이터셋 2,001 — KO 1,001 + EN 1,000SFT 학습 1,801 / 검증 200 · Kaggle 공개(insighta-mandala-sft)
실측 · 데이터 품질 엔지니어링
18,009임베딩 (2,001×9, 4096d)
Supabase 0-fail 적재
2.6%EN 실패율 (27/1,027)
전건 근본원인·재생성
9 도메인 균형 (언어별 ~111)
파인튜닝 모델 HuggingFace 공개챗봇 insighta-chatbot-v1(31B) · 만다라트 v13(4B) + Space 데모
4096d > pgvector 2000d 한계 → 정확 검색match_mandalas() RPC로 exact search
V1(Claude API) → V2(템플릿, 무키 대량) → V3(Claude-Code 직생성 + 인라인 검증). 실패는 버리지 않고 근본원인 규명 후 재생성 — 데이터가 품질을 끌어올린다.
Dataset · Fine-tuning in 1 Diagram
Jeonho James Kim — Insighta · Mandalart V3 dataset pipeline
3-stage quality gate 18,009 embeddings
A 3-stage gate that regenerates whatever fails, keeping only the validated dataset.
reject
→ regenerate ≤3×
Generate — 9 domains × ~111/lang (KO + EN)center goal → 8 sub-goals → 64 actions · V1 API → V2 template → V3 Claude-Code direct-gen
Gate 1 · structure — 8 sub-goals + 64 actions completeblank·dup = regenerate
Gate 2 · quality score ≥ 0.7measurability 30% · category balance 20% · HIGH tag 20% · abstract-word penalty 30%
Gate 3 · LLM-as-Judge1-in-10 trend sampling → discard if below
Mandalart dataset 2,001 — KO 1,001 + EN 1,000SFT train 1,801 / val 200 · published on Kaggle (insighta-mandala-sft)
Measured · data-quality engineering
18,009embeddings (2,001×9, 4096d)
Supabase 0-fail load
2.6%EN failure rate (27/1,027)
all root-caused & regenerated
9 domains balanced (~111 per lang)
Fine-tuned models on HuggingFacechatbot insighta-chatbot-v1 (31B) · Mandalart v13 (4B) + Space demo
4096d > pgvector's 2000d limit → exact searchvia match_mandalas() RPC
V1 (Claude API) → V2 (template, keyless bulk) → V3 (Claude-Code direct-gen + inline validation). Failures aren't dropped — root-caused, then regenerated — data drives quality up.
그림 I.Fig. I. 생성 → 3단계 품질 게이트(통과 못하면 재생성) → 검증 데이터셋 2,001 · 임베딩 18,009개.Generate → 3-stage quality gate (regenerate on fail) → validated dataset of 2,001 · 18,009 embeddings.
구성Components
  • 만다라트 V3 데이터셋 자체 구축 — KO 1,001 + EN 1,000(9개 도메인 균형) → 임베딩 18,009개(2,001×9, 4096d) Supabase 0-fail 적재Own Mandalart V3 dataset — KO 1,001 + EN 1,000 (9 domains, balanced) → 18,009 embeddings (2,001×9, 4096d) loaded to Supabase with 0 failures
  • 3단계 자동 품질 게이트 — 구조 검증 → 품질점수 ≥0.7(≤3회 재생성) → LLM-as-Judge 샘플링, EN 실패율 2.6% 전건 근본원인·재생성3-stage automated quality gate — structure → score ≥0.7 (≤3 retries) → LLM-as-Judge sampling; 2.6% EN failure rate, every case root-caused & regenerated
  • 파인튜닝 모델 공개(HuggingFace) — 챗봇 insighta-chatbot-v1(Qwen3-30B LoRA·병합 31B) · 만다라트 insighta-mandala-v13(4B) + Space 데모Fine-tuned models published (HuggingFace) — chatbot insighta-chatbot-v1 (Qwen3-30B LoRA · merged 31B) · Mandalart insighta-mandala-v13 (4B) + a Space demo
  • 요약 파이프라인 멀티모델(Gemini·Qwen3) + 품질 플래그 · AWS Spot(us-west-2)+OpenRouter · 모바일 Dial(insighta.one/dial)Summary pipeline — multi-model (Gemini·Qwen3) + quality flags · AWS Spot(us-west-2)+OpenRouter · mobile Dial (insighta.one/dial)
2,001
만다라트 → 18,009 임베딩mandalas → 18,009 emb
2.6%
EN 실패율 전건 근본원인EN fail, all root-caused
HF · Kaggle
모델·데이터셋 공개models & dataset published
역량Capability — 3단계 자동 검증으로 만다라트 2,001개(18,009 임베딩) 데이터셋을 구축, 파인튜닝 모델(챗봇·만다라트)을 HuggingFace, 데이터셋을 Kaggle에 공개.Built a Mandalart dataset of 2,001 items (18,009 embeddings) via a 3-stage automated gate; published the fine-tuned models (chatbot·Mandalart) on HuggingFace and the dataset on Kaggle.
참고RefsHuggingFace 모델HuggingFace modelsKaggle 데이터셋Kaggle datasetDial 앱Dial app

메가존클라우드MegazoneCloud

2023.12–2025.11
클라우드 엔지니어 · 표준화·거버넌스·PMOCloud engineer · standards · governance · PMO
주요 고객·파트너Key clients · partners현대오토에버아메리카Hyundai AutoEver America아람코Aramco
MWorkOS · AI(RAG) 프로젝트 관리 플랫폼WorkOS · AI(RAG) Project-Management Platform

프로젝트 현황이 여러 소스에 흩어져 커뮤니케이션 비용이 컸다. 내가 발의·기획하고 PM으로 3개월 만에 온버짓 MVP를 론칭 — 소스를 통합하고 RAG 챗봇으로 현황 질의응답을 자동화했다.Project status was scattered across sources, inflating communication cost. I initiated and led it as PM, shipping an on-budget MVP in 3 months — unifying sources and automating status Q&A with a RAG chatbot.

WorkOS · AI(RAG) 프로젝트 관리 플랫폼 in 1 Diagram
Jeonho James Kim — 메가존클라우드 · 발의 → 기획 → PM
3개월 · ₩23M 온버짓 2024–2025
흩어진 4개 소스를 하나의 통합 지식으로 수렴시키고, RAG로 3개 접점에 확산한다.
▸ 배치 구축 (야간 자동 수집)
실시간 서빙 (자연어 질의) ◂
Jira이슈 · 스프린트
Confluence문서 · 회의록
ACP프로젝트 마스터
Sheets영업 · 지표
흩어진 소스 4종 · 현황 파편화
로우코드 통합 n8n · AppSheet 워크플로우 ~10개(핵심 6개) — 수집 · 정제 · 청킹 · 임베딩
통합 지식 · 데이터레이크 흩어진 현황이 하나의 조회 가능한 지식으로.
PostgreSQL + pgVector임베딩 · 유사도 검색 (단일 경로)
BigQuery집계 · 분석
MongoDB Atlas원문 · 메타데이터
RAG 엔진 Gemma-3 12B · 셀프호스팅
Retriever → pgVector top-k
컨텍스트 조립 → Flask 서빙
응답마다 출처 동반 = 환각 차단
RAG 챗봇자연어 현황 Q&A (출처와 함께)
AppsmithRBAC 어드민 콘솔
Looker StudioBI 대시보드
역할별 3개 접점 · 질문 하나 → 근거 있는 답
종료보고서 검증 2025.02–05 MVP · 전담 1명 + 오프쇼어 2명
일정 준수
90%
Task 완료
90%
대시보드
90%
자동화
85%
비즈니스 케이스 ROI 126 / 149 / 178% 1·2·3년차(직접 작성) · 초기 절감 ₩47M/년
커뮤니케이션 −40% 데이터 정합성 4/4
구조 = 수렴(4소스) → 통합 지식(허브) → 확산(3접점) · 좌측 배치 구축 / 우측 실시간 서빙 · 전 구성요소 GCP 셀프호스팅(외부 LLM 의존 0).
WorkOS · AI(RAG) Project-Management Platform in 1 Diagram
Jeonho James Kim — MegazoneCloud · Proposed → Planned → PM
3-month · ₩23M on-budget 2024–2025
Converge 4 scattered sources into one unified knowledge base, then fan it out to 3 surfaces via RAG.
▸ BATCH BUILD (nightly auto-ingest)
REAL-TIME SERVING (natural-language query) ◂
JiraIssues · sprints
ConfluenceDocs · minutes
ACPProject master
SheetsSales · metrics
4 scattered sources · fragmented status
Low-code integration n8n · AppSheet ~10 workflows (6 core) — collect · clean · chunk · embed
Unified Knowledge · Data Lake Scattered status becomes one queryable knowledge base.
PostgreSQL + pgVectorEmbeddings · similarity (single path)
BigQueryAggregate · analytics
MongoDB AtlasSource · metadata
RAG Engine Gemma-3 12B · self-hosted
Retriever → pgVector top-k
Context assembly → Flask serving
Every answer cites sources = no hallucination
RAG chatbotNL status Q&A (with sources)
AppsmithRBAC admin console
Looker StudioBI dashboard
3 role-based surfaces · one question → grounded answer
Report-verified 2025.02–05 MVP · 1 dedicated + 2 offshore
Schedule
90%
Task done
90%
Dashboard
90%
Automation
85%
Business case ROI 126 / 149 / 178% Year 1·2·3 (self-authored) · ₩47M/yr initial savings
Communication −40% Data integrity 4/4
Structure = converge (4 sources) → unified knowledge (hub) → fan-out (3 surfaces) · left batch build / right real-time serving · all components self-hosted on GCP (0 external-LLM dependence).
그림 M.Fig. M. 흩어진 4소스를 통합 지식(데이터레이크)으로 수렴 → RAG로 3접점 확산, 하단은 종료보고서 검증 KPI·ROI.Converge 4 scattered sources into a unified knowledge lake → fan out to 3 surfaces via RAG, with report-verified KPIs·ROI below.
PM · 설계PM · design
  • 2024.08 발의 → 기획 → PM 3개월(2025.02~05) · ₩23M On-budget MVPInitiated 2024.08 → planning → PM 3 months (2025.02–05), ₩23M on-budget MVP
  • n8n(약 10개 워크플로우) + BigQuery/PostgreSQL(pgVector)/MongoDB Atlasn8n (~10 workflows) + BigQuery/PostgreSQL(pgVector)/MongoDB Atlas
  • Gemma-3 12B RAG 챗봇 + Appsmith RBAC 어드민 + Looker Studio BI · GCP 셀프호스팅Gemma-3 12B RAG chatbot + Appsmith RBAC admin + Looker Studio BI · GCP self-hosted
  • 소스 통합 4종(Jira·Confluence·ACP·Sheets)4-source integration (Jira·Confluence·ACP·Sheets)
40%↓
커뮤니케이션 비용communication cost
3개월3 months
온버짓 MVPon-budget MVP
85–90%
KPI 달성KPI met
역량Capability — 발의부터 PM까지, 3개월·₩23M 온버짓 MVP로 커뮤니케이션 비용 40% 절감·KPI 85~90% 달성.From proposal to PM: a 3-month, ₩23M on-budget MVP that cut communication cost 40% and met 85–90% of KPIs.
M전사 표준 SDLC + 대외 마이그레이션 PMOGovernance Transfer · Standard SDLC + PMO

글로벌 확장과 SaaS 포트폴리오 급증으로 개발이 팀마다 제각각이었다. 6개 제품팀을 진단해 7단계 표준 SDLC(ISO 12207·CMMI·SAFe·ITIL v4 종합)를 수립하고, 레이블 정책·거버넌스 바디·단계별 롤아웃까지 설계했다. 별개로 대외 완성차 계열 13개 마이그레이션을 PMO로 정렬했다.Global expansion and a fast-growing SaaS portfolio left each team building its own way. I diagnosed 6 product teams and established a 7-stage standard SDLC (synthesizing ISO 12207 · CMMI · SAFe · ITIL v4) — with a label policy, a governance body and a phased rollout — and separately aligned an external automotive group's 13-project migration under a PMO.

거버넌스 전이 · 표준 SDLC + 13개 프로젝트 PMO in 1 Diagram
Jeonho James Kim — 메가존클라우드 2023–2025
제품팀 6개 13개 프로젝트 12개 게이트
전사 표준 SDLC
제품팀 6개 — 각기 다른 방법 · 도구 · 품질 기준 출발 조건: "완료"의 공유 정의가 없음
7개 카테고리 진단
Leadership OKR VOC 요구사항 Dev 품질 릴리스
하이브리드 표준 SDLC
ISO/IEC 12207 CMMI SAFe ITIL v4
표준 Jira 워크플로 템플릿 제품 Tier 1 / 2 / 3 격주 경영진 거버넌스
주 — 효과 수치는 문서화된 기대치이며, 주장된 성과가 아님.
대외 마이그레이션 PMO
글로벌 자동차 그룹의 IT 서비스 계열사 13개 프로젝트 마이그레이션 포트폴리오 — 계약 · 고객 상세 비공개
12-gate프로젝트 라이프사이클 — 전 프로젝트 동일 게이트
RACI행위자별 책임 — 주인 없는 단계 없음
L1–L5성숙도 모델 — 진행이 측정 가능
AWSControl Tower / Landing Zone 거버넌스
ON-SITE 미국 Irvine 3개월+ 상주 — 영어 업무 환경 · 고객사 현장 딜리버리
SOF와 동일한 무브 둘 다 SOF와 동일한 무브 — 진단 → 분해 → 게이트 → 계층 문서 → 측정 → 피드백 — 한 번은 조직(SDLC)으로, 한 번은 고객 프로젝트(PMO)로 전이.
좌 = 내부 표준화 (6개 팀 → 하나의 SDLC) · 우 = 대외 딜리버리 (13개 프로젝트, 하나의 라이프사이클). 효과 수치 = 문서화된 기대치, 주장된 성과 아님. 2023–2025
Governance Transfer · Standard SDLC + 13-project PMO in 1 Diagram
Jeonho James Kim — MegazoneCloud 2023–2025
6 product teams 13 projects 12 gates
Enterprise Standard SDLC
6 product teams — each a different method, tool, quality bar the starting condition: no shared definition of "done"
7-category diagnosis
Leadership OKR VOC Requirements Dev Quality Release
Hybrid standard SDLC
ISO/IEC 12207 CMMI SAFe ITIL v4
standard Jira workflow templates product Tier 1 / 2 / 3 bi-weekly executive governance
Note — effect figures are documented expectations, not claimed results.
External Migration PMO
A global automotive group's IT-services affiliate 13-project migration portfolio — contract & client details withheld
12-gateproject lifecycle — every project on the same gates
RACIper-actor responsibility — no ownerless step
L1–L5maturity model — progress is measurable
AWSControl Tower / Landing Zone governance
ON-SITE 3+ months in Irvine, CA — English work environment, client-side delivery
SAME MOVE AS SOF Both are the same move as SOF — diagnose → decompose → gate → layer docs → measure → feed back — transferred once to an organization (SDLC) and once to client projects (PMO).
Left = internal standardization (6 teams → one SDLC) · right = external delivery (13 projects on one lifecycle). Effect figures = documented expectations, not claimed results. 2023–2025
그림 M.Fig. M. 거버넌스 전이 — 6팀 → 7단계 표준 SDLC + 13-프로젝트·12관문 PMO.Governance transfer — 6 teams → a 7-stage standard SDLC + a 13-project · 12-gate PMO.
리드Lead
  • 6개 제품팀(PoPs·CPM·MegaHub/IDP·SpaceONE·HyperBilling·GenAI360) 진단 → 7단계 표준 SDLC(ISO 12207·CMMI·SAFe·ITIL v4)Diagnosed 6 product teams (PoPs·CPM·MegaHub/IDP·SpaceONE·HyperBilling·GenAI360) → a 7-stage standard SDLC (ISO 12207·CMMI·SAFe·ITIL v4)
  • 거버넌스 도구·정책 — Jira 6-state 워크플로우·Confluence·Sonarqube + Objective→Initiative→Epic 레이블 정책 v0.1(전 프로젝트 통합 대시보드)Governance tooling/policy — Jira 6-state workflow·Confluence·Sonarqube + an Objective→Initiative→Epic label policy v0.1 (org-wide cross-project dashboard)
  • 제품 Tier(Full/Core/Light)·거버넌스 바디(팀대표+QA+프로세스전문가)·4단계 롤아웃(준비→PoPs·SpaceONE 파일럿→확산→최적화)Product Tier (Full/Core/Light) · a chartered governance body · a 4-phase rollout (prepare→pilot on PoPs·SpaceONE→scale→optimize)
  • 목표 KPI 정의 — 개발 사이클 −30%·치명결함 −70%·산출물 재사용 +60%(문서화된 타깃)Defined target KPIs — dev-cycle −30% · critical defects −70% · deliverable reuse +60% (documented targets)
  • 13-프로젝트 마이그레이션 PMO(현대오토에버 아메리카) · 12관문·RACI·L1–L5 · AWS Control Tower/Landing Zone · 어바인 3개월+ 현지13-project migration PMO (Hyundai AutoEver America) · 12 gates·RACI·L1–L5 · AWS Control Tower/Landing Zone · 3+ months on-site in Irvine
6팀6 teams
→ 7단계 표준 SDLC→ 7-stage SDLC
−30·−70·+60%
사이클·결함·재사용 타깃cycle·defect·reuse targets
13
마이그레이션·12관문 PMOmigration·12-gate PMO
역량Capability — 6개 제품팀을 7단계 표준 SDLC(ISO 12207·CMMI·SAFe·ITIL v4)로, 레이블 정책·거버넌스 바디·4단계 롤아웃까지 설계하고, 13개 대외 마이그레이션을 12관문 PMO로 정렬.Standardized 6 product teams into a 7-stage SDLC (ISO 12207·CMMI·SAFe·ITIL v4) with a label policy, governance body and 4-phase rollout, and aligned a 13-project external migration under a 12-gate PMO.
M아람코 SpaceONE CMP PoC · 수행 PMAramco SpaceONE CMP PoC · Delivery PM

Aramco→Aramco Digital→Nextera→메가존 4단 계약구조에서, 사우디 아람코의 멀티클라우드 관리 플랫폼(SpaceONE) PoC를 수행 PM으로 이끌었다. 부실한 SOW/WBS를 전문가 관점 5범주 14건으로 진단·개선하고, KPI·리스크·문화까지 담은 수행 가이드북 v2.0로 실행 체계를 세웠다.In a 4-tier chain (Aramco→Aramco Digital→Nextera→Megazone) I led the Saudi Aramco multi-cloud CMP (SpaceONE) PoC as delivery PM — diagnosing a weak SOW/WBS into 14 expert-graded issues across 5 categories and standing up the execution system via a delivery guidebook v2.0 spanning KPIs, risk and cultural design.

아람코 SpaceONE CMP PoC in 1 Diagram
Jeonho James Kim — 메가존클라우드 · 수행 PM (사우디 온사이트)
SpaceONE PoC ~$2.55M · 16주 멀티클라우드 CMP
관리 대상 멀티 · 하이브리드 클라우드
AWS Azure GCP Kubernetes VMware On-Prem
데이터센터 + 퍼블릭 CSP + 소버린 클라우드를 하나의 포털로. 과금 API(AWS Billing·Azure Cost·GCP BigQuery) 통합.
SpaceONE · Cloud Management Portal
Asset Inventory멀티클라우드 자산 자동 수집·분류
Cost Explorer비용 시각화·최적화(FinOps)
Alert Manager알림 통합·에스컬레이션
OpsFlow티켓·ITSM 워크플로우 자동화
Cloud Insight보안·성능·비용 진단·권고
Custom Dashboard전 데이터 통합 시각화
CSPM보안 컴플라이언스 — ISMS-P · CIS Benchmark · Prowler/PaloAlto 스캔 → 리포팅
사용자 · 통합
Developer SRE Security
ITSMJira · ServiceNow
NotificationSlack · MS Teams · Email
Provisioning · 계열사 재빌링부서·계열사별 사용량 추적 → Infra 서비스
MZC DPaaS 병행 — 130+ ISV 데이터 파이프라인(13주·$645K)
수행 PM 기여Aramco→Digital→Nextera→메가존 4단 계약
SOW/WBS 진단 14건 · 5범주Critical·Major·Technical·PM·Commercial → 3차 개선 웨이브
가이드북 v2.0KPI ≥90%·보안 100%·주간 CCB·5-actor RACI·문화 설계
NFR 설계가용성 99.9% · RPO 1h/RTO 4h · 자산 100만+ · EKS v1.27+·MongoDB v7
멀티/하이브리드 클라우드를 SpaceONE 6대 모듈로 단일 관리 → 역할별 사용자·ITSM/알림 통합. 수행 PM으로 부실 SOW/WBS를 진단·정상화하고 실행 체계를 세움.
Aramco SpaceONE CMP PoC in 1 Diagram
Jeonho James Kim — MegazoneCloud · delivery PM (Saudi on-site)
SpaceONE PoC ~$2.55M · 16wk multi-cloud CMP
Managed Multi · hybrid cloud
AWS Azure GCP Kubernetes VMware On-Prem
Data centers + public CSPs + sovereign cloud under one portal. Billing-API (AWS Billing·Azure Cost·GCP BigQuery) integrated.
SpaceONE · Cloud Management Portal
Asset Inventorymulti-cloud asset auto-collect·classify
Cost Explorercost viz·optimization (FinOps)
Alert Manageralert consolidation·escalation
OpsFlowticket·ITSM workflow automation
Cloud Insightsecurity·perf·cost diagnosis·recs
Custom Dashboardunified data visualization
CSPMSecurity compliance — ISMS-P · CIS Benchmark · Prowler/PaloAlto scan → reporting
Users · integrations
Developer SRE Security
ITSMJira · ServiceNow
NotificationSlack · MS Teams · Email
Provisioning · affiliate re-billingper-dept/affiliate usage tracking → Infra service
MZC DPaaS in parallel — 130+ ISV data pipeline (13wk·$645K)
Delivery-PM contributionAramco→Digital→Nextera→Megazone 4-tier
SOW/WBS diagnosis — 14 · 5 categoriesCritical·Major·Technical·PM·Commercial → 3 remediation waves
Guidebook v2.0KPI ≥90%·security 100%·weekly CCB·5-actor RACI·cultural design
NFR design99.9% availability · RPO 1h/RTO 4h · 1M+ assets · EKS v1.27+·MongoDB v7
Multi/hybrid cloud unified under SpaceONE's 6 modules → role-based users · ITSM/notification integration. As delivery PM, diagnosed and normalized a weak SOW/WBS and stood up the execution system.
그림 M.Fig. M. SpaceONE CMP 아키텍처 — 멀티/하이브리드 클라우드 → 6대 모듈 → 역할별 사용자·통합. 수행 PM으로 SOW/WBS 14건 진단·가이드북 v2.0.SpaceONE CMP architecture — multi/hybrid cloud → 6 modules → role-based users·integrations. As delivery PM: 14 SOW/WBS fixes and guidebook v2.0.
진단 · 실행 설계Diagnosis · execution design
  • SpaceONE PoC ~$2.55M · 16주(전체 $3.2M · 32주 프로그램의 기술수행) 수행 PMDelivery PM for the ~$2.55M · 16-week SpaceONE PoC (within a $3.2M · 32-week program)
  • SOW/WBS 진단 — Critical·Major·Technical·PM·Commercial 5범주 14건, 즉시→단기→중기 3차 개선 웨이브SOW/WBS diagnosis — 14 issues across 5 categories (Critical·Major·Technical·PM·Commercial), sequenced into 3 remediation waves
  • 수행 가이드북 v2.0 — KPI(요구충족 ≥90%·보안 100%·만족 ≥4.0/5)·주간 CCB·P×I 리스크 매트릭스·5-actor RACI·문서품질 게이트(Grammarly ≥80)Guidebook v2.0 — KPIs (≥90% req · 100% security · ≥4.0/5 sat), weekly CCB, a P×I risk matrix, a 5-actor RACI, a doc-quality gate (Grammarly ≥80)
  • 문화·시간대 설계 — 온사이트 PM 상주 + KSA(UTC+3) 오버랩·기도시간(Dhuhr/Asr) 회피·라마단 반영, 6~7 실가동시간 KPI 반영Cultural/time-zone design — on-site PM + KSA(UTC+3) overlap, prayer-time (Dhuhr/Asr) blocks, a Ramadan window, 6–7 effective-hours modeled into KPIs
  • 아키텍처 NFR — 가용성 99.9%·RPO 1h/RTO 4h·자산 100만+·동시 1,000+ · EKS v1.27+·MongoDB v7·멀티클라우드(AWS/Azure/GCP) 과금 API 통합Architecture NFRs — 99.9% availability · RPO 1h/RTO 4h · 1M+ assets · 1,000+ concurrent · EKS v1.27+ · MongoDB v7 · multi-cloud (AWS/Azure/GCP) billing-API integration
~$2.55M
SpaceONE PoC · $3.2M 프로그램SpaceONE PoC · $3.2M prog
14건14
5범주 SOW/WBS 개선5-cat SOW/WBS fixes
99.9%
가용성·RPO1h/RTO4havailability·RPO1h/RTO4h
역량Capability — 4단 계약구조의 사우디 SpaceONE PoC(~$2.55M·16주)를 수행 PM으로, SOW/WBS 14건을 5범주로 진단·개선하고 KPI·리스크·RACI·문화까지 담은 가이드북 v2.0으로 실행.Delivery PM on the 4-tier Saudi SpaceONE PoC (~$2.55M·16wk): 14 SOW/WBS issues diagnosed across 5 categories and executed via a guidebook v2.0 covering KPIs, risk, RACI and cultural design.
참고RefsMegazone SpaceONEMegazone SpaceONE

삼성전자 · 삼성클라우드Samsung Electronics · Samsung Cloud

2010.10–2023.07
SRE/플랫폼 엔지니어 · CloudOps 운영 리드·설계 (+ 미디어솔루션 결제·빌링)SRE / platform engineer · CloudOps lead (+ Media Solution billing)
주요 고객·파트너Key clients · partnersAWSAWSAzureAzureMariaDBMariaDB
§SOF 운영 프레임워크The SOF Operations Framework

150여 개 서비스가 제각각 운영되어 기술부채·비일관성이 누적됐고, CSP 표준(Landing Zone)만으로는 조직 특수성을 담지 못했다. 초대규모 운영을 하나의 프레임워크로 정의하고, 8개 도메인을 WHY→HOW→WHAT으로 표준화해 운영 성숙도 Defined를 달성했다.~150 services each ran their own way, accruing tech debt; the CSP Landing Zone alone couldn't capture the org's specifics. I defined the whole operation as one framework — standardizing 8 domains as WHY→HOW→WHAT — reaching a Defined maturity.

SOF 운영 프레임워크 in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
8개 도메인 1개 루프 2013–2023
SOF 지속적 개선 루프 DIAGNOSE → PLAN → DESIGN →
EXECUTE → REVIEW → STANDARDIZE
삼성 클라우드 2013–2023
~5,000 VM · 5개 리전 · MAU 2.4억
8개 도메인 × WHY·HOW·WHAT × 3계층 문서
D1 · 장애 & Self-Healing 야간·휴일 대응 40%↓
오판 여지가 없는 유형만 자동 복구. 진단 모호성이 0인 장애 유형만 자동화 대상.
EC2 status 0/2 = host → reallocate
EC2 status 1/2 = guest → reboot
복구 이력은 규칙으로 승격 — 런북은 검증된 복구에서 자란다.
D2 · 모니터링 & 관측성
L1–L5 layer standard — 모든 지표는 계층에 소속되고, 계층마다 대시보드를 갖는다.
Kafka backpressure 가 장애 중 지표 저장소를 보호 — 폭풍 속에서도 관측성이 생존.
시리즈 카디널리티 통제: org 단위 격리 + 신규 시리즈 지표사전 게이트.
D3 · 구축 & 배포
▸ Immutable image + Consul KV — 설정과 아티팩트 분리
▸ Spinnaker single deploy-trace — 모든 릴리스가 단일 이력
▸ EKS on RTO × WorkGroup — 복구 등급 × 격리
▸ Terraform two-reviewer gate — 프로덕션 단독 반영 경로 없음
D4 · 변경관리
500건 변경/월 — 전량 JIRA. 티켓 밖 작업은 존재하지 않는다.
▸ EPIC 위계 의무화 — 모든 티켓에 상위 존재
▸ Power BI 3계층 보드 — EPIC / TASK / SUB-TASK 롤업
▸ 17-item DB 점검 — 정기 수행 · 보고 공유
D5 · 보안 & IAM
Keycloak SAML Federation → 정적 자격증명 0. 전사 AD 단일 신원 원천 · Keypair 전량 제거.
24h 컴플라이언스 점검 — 12개 정책 — 탐지 → 자동 조치 → 주간 리포트.
인프라 작업 효율 30%↑
$D6 · 비용 & FinOps
Inform → Optimize → Operate — 가시화 먼저, 다음 절감, 그리고 상시 운영.
▸ Tag 우선 귀속 — 모든 비용에 소유자 지정
▸ 소유자 직통 예산 알림 — 중앙 중계 없음
D7 · 인하우스 툴링
Cross-CSP = 자체 구축 · 단일 CSP = 구매. 모든 툴링 의사결정의 단일 build/buy 규칙.
▸ 4개 툴 자체 구축 — 모니터링 · API 테스트 · 비용 예측 · 배포
TiDB — PoC 후 기각 · 반례 사례
D8 · 전략 & 거버넌스
▸ Sourcing Out → In → Hybrid — 핵심은 내부, 반복 업무는 복수 벤더
▸ 분기 SLA/KPI 리뷰
▸ 연 1회 R&R 재확정 — 소유권 표류 방지
▸ 운영 리스크 레지스터
중앙 = 지속적 개선 루프, 8개 도메인이 그 주위를 순환. 컬러 배지 = 검증된 정량 성과. 성숙도: Defined.
D1 D2 D3 D4 D5 D6 D7 D8
The SOF Operations Framework in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
8 domains 1 loop 2013–2023
SOF Continuous-Improvement Loop DIAGNOSE → PLAN → DESIGN →
EXECUTE → REVIEW → STANDARDIZE
Samsung Cloud 2013–2023
~5,000 VMs · 5 regions · MAU 240M
8 domains × WHY·HOW·WHAT × 3-layer docs
D1 · Incident & Self-Healing 40%↓ night/holiday response
Auto-recover only misjudgment-free types. Failure classes with zero diagnostic ambiguity are the only ones automated.
EC2 status 0/2 = host → reallocate
EC2 status 1/2 = guest → reboot
Recovery history is promoted into rules — the runbook grows from verified recoveries.
D2 · Monitoring & Observability
L1–L5 layer standard — every metric belongs to a layer; each layer owns its dashboards.
Kafka backpressure shields the metric store mid-incident — observability survives the storm.
Series-cardinality control: org-level isolation + a metric dictionary gate for new series.
D3 · Build & Deploy
▸ Immutable image + Consul KV — config split from artifact
▸ Spinnaker single deploy-trace — one history for every release
▸ EKS on RTO × WorkGroup — recovery class × isolation
▸ Terraform two-reviewer gate — no solo path to prod
D4 · Change Management
500 changes/mo — all in JIRA. No off-ticket work exists.
▸ Mandatory EPIC hierarchy — every ticket has a parent
▸ Power BI 3-tier board — EPIC / TASK / SUB-TASK roll-up
▸ 17-item DB check — periodic, report-shared
D5 · Security & IAM
Keycloak SAML Federation → zero static credentials. Corporate AD is the single identity source; keypairs eliminated.
24h compliance check across 12 policies — detect → auto-remediate → weekly report.
30%↑ infra-work efficiency
$D6 · Cost & FinOps
Inform → Optimize → Operate — visibility first, then savings, then a standing practice.
▸ Tag-first attribution — every cost lands on an owner
▸ Owner-direct budget alerts — no central relay in the loop
D7 · In-house Tooling
Cross-CSP = build · single-CSP = buy. The one build/buy rule for every tooling decision.
▸ 4 tools built in-house — monitoring · API test · cost forecast · deploy
TiDB — rejected after PoC · the counter-case
D8 · Strategy & Governance
▸ Sourcing Out → In → Hybrid — core stays internal, repeatables go multi-vendor
▸ Quarterly SLA/KPI review
▸ Yearly R&R re-ratification — ownership never drifts
▸ Operational risk register
Center = the continuous-improvement loop; the 8 domains revolve around it. Colored badges = verified quantitative results. Maturity: Defined.
D1 D2 D3 D4 D5 D6 D7 D8
그림 1.Fig. 1. SOF 프레임워크 — 8개 도메인 × 지속적 개선 루프 × 3계층 문서.The SOF framework — 8 domains × a continuous-improvement loop × 3-layer docs.
프레임워크 구성Framework structure
  • 8개 운영 도메인 표준화 — 장애·모니터링·구축배포·변경·보안·비용·툴·거버넌스Standardized 8 operating domains
  • 3계층 문서 체계 — General · Service · Technical3-layer doc system — General · Service · Technical
  • 각 도메인 WHY-HOW-WHAT 정의로 운영 지식 자산화Each domain defined as WHY-HOW-WHAT; knowledge as an asset
  • 중심의 지속적 개선 루프로 진단→표준→회고 상시 순환A central continuous-improvement loop
150+
서비스 표준·기술부채 관리services standardized
8 도메인8 domains
× 3계층 문서× 3-layer docs
Defined
운영 성숙도 달성maturity reached
역량Capability — 약 150개 서비스를 8개 도메인·3계층 문서로 표준화하고 운영 성숙도 Defined 달성.~150 services standardized into 8 domains and 3 doc layers, reaching Defined maturity.
참고Refs삼성 클라우드Samsung Cloud
§AIOps Self-Healing — 장애 무인 자동복구AIOps Self-Healing — autonomous recovery

약 5,000대 VM과 미들웨어 클러스터에서 야간·휴일 장애 대응 부담이 컸고, 반복성 장애가 계속 사람 손을 요구했다. 반복 가능한 장애를 사람 개입 없이 자동 탐지·복구하고, 복구 이력을 데이터로 되먹여 자동화 범위를 넓혔다.Across ~5,000 VMs and middleware clusters, night/holiday incident load was heavy. I built a production system that recovers repeatable incidents with no human intervention, feeding recovery history back to widen coverage.

AIOps Self-Healing · 보수적 자동화 in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
5단계 1개 피드백 루프 2020–2023
1 수집 (Collect)
boto API 인프라 이벤트
일반 Telegraf–Kafka 지표 스택과 분리된 전용 경로.
CSP API =
단일 진실 원천
2 저장 (Store)
InfluxDB time-series
이벤트 이력이 여기 적재 — 판정기가 주기적으로 폴링.
이벤트 이력
→ 폴링 대상
3 판정 · 승격 게이트
Lambda 폴링. 신호가 조치를 결정론적으로 함의할 때만 자동화.
EC2 0/2 = host → reallocate EC2 1/2 = guest → reboot disk fault → recover
판단형 유형 (perf/app)
수동 유지 — MANUAL
4 실행 (Execute)
독립 Python 복구 서버
restart · isolate · autoscale
판정과 분리한 이유:
▸ 권한 격리 ▸ Lambda 타임아웃 초과 작업 ▸ 단일 실행 이력 저장소
5 피드백 (Feedback)
모든 복구를 기록
반복적 + 결정론적 유형은 규칙으로 승격.
ChatOps 감시 —
사람이 루프를 관찰
⑤ → ① 모든 복구가 다음 규칙을 만든다
500건 장애 전수조사 · 2020.08–2023.01
주요 현상
Instance Down
120
Connection Timeout
110
주요 원인
EC2 자체
120
앱이 아닌 호스트 — 최다 원인은 인프라
주요 조치
dbms restart
130
자연 해소
80
자동화 1호 = 최다 원인 × 최다 조치 첫 자동화 런북은 최다 원인과 최다 조치의 교차점에 놓인다 — 직관이 아니라 데이터가 대상을 고른다.
실선 = 데이터 흐름 · 점선 곡선 = 피드백 루프 (⑤→①) · 번호 배지 = 파이프라인 순서. 컬러 배지 = 검증된 정량 성과.
야간·휴일 긴급 대응 40%↓ 성숙도: Defined
AIOps Self-Healing · Conservative Automation in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
5 stages 1 feedback loop 2020–2023
1 Collect
Infra events via boto API
A dedicated path, separate from the general Telegraf–Kafka metric stack.
CSP API =
source of truth
2 Store
InfluxDB time-series
Event history lands here — the judge polls it on schedule.
event history
→ poll target
3 Judge · PROMOTION GATE
Lambda polls. Automate only where the signal deterministically implies the action.
EC2 0/2 = host → reallocate EC2 1/2 = guest → reboot disk fault → recover
judgment types (perf/app)
stay MANUAL
4 Execute
Separate Python recovery server
restart · isolate · autoscale
Split from judgment for:
▸ privilege isolation ▸ beyond-Lambda-timeout jobs ▸ single history sink
5 Feedback
Every recovery logged
Recurrent + deterministic types are promoted into rules.
ChatOps oversight —
humans watch the loop
⑤ → ① every recovery feeds the next rule
500-INCIDENT CENSUS · 2020.08–2023.01
TOP SYMPTOMS
Instance Down
120
Connection Timeout
110
TOP CAUSE
EC2 itself
120
the host, not the app — infrastructure was the top offender
TOP ACTIONS
dbms restart
130
self-resolved
80
AUTOMATION #1 = top cause × top action The first automated runbook sits at the intersection of the most frequent cause and the most frequent action — data picks the target, not intuition.
Solid arrows = data flow · dashed curve = feedback loop (⑤→①) · numbered pills = pipeline order. Colored badges = verified quantitative results.
40%↓ night/holiday emergency response Maturity: Defined
그림 2.Fig. 2. Self-Healing 파이프라인 — boto API 수집→판단→Lambda→Python 복구, 복구 로그 피드백 루프.Self-Healing — boto API collect→judge→Lambda→Python recovery, with a feedback loop.
설계·운영Design & operation
  • boto API로 인프라 이벤트 수집 → InfluxDB 시계열Collect infra events via boto API → InfluxDB
  • 결정적 신호만 자동복구 — 보수적 자동화(판단형은 수동)Auto-recover only deterministic signals (conservative)
  • 판단과 실행 분리 — 별도 Python 복구서버(권한 격리)Split judgment from execution — separate Python recovery server
  • 복구 로그 전량 적재 → 탐지 규칙 승격(피드백 루프)Log every recovery → promote into rules
40%↓
야간·휴일 긴급 대응(내부)night/holiday response (internal)
500건500
장애 전수분석incidents analyzed
Defined
성숙도maturity
역량Capability — 약 5,000대 VM에서 반복 장애를 무인 자동복구, 야간·휴일 긴급대응 40% 감소.Unattended recovery of repeatable incidents across ~5,000 VMs, cutting night/holiday response 40%.
§IAM 컴플라이언스 자동 점검·조치 (HLD)IAM Compliance Automation (HLD)

계정·권한이 개별 관리되고 정적 키가 흩어져 보안·운영 리스크가 컸다. IAM 컴플라이언스를 24시간 주기로 자동 점검하고, 상태를 악화시키지 않는 조치만 자동 수행했다.Accounts/permissions were managed piecemeal and static keys were scattered. I built an HLD that auto-checks IAM compliance on a 24h cycle and applies only 'cannot-worsen-state' remediations.

IAM 컴플라이언스 점검 · High-Level Design in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
AWS 네이티브 24H 주기 12개 정책
판정 규칙 카탈로그
R-01MFA 미등록auto
→ MFA 강제 적용
R-02콘솔 사용 이력 Access Keyauto
→ Key 비활성화
R-0390일 미사용 자격증명auto
→ deactivate 처리
R-04정책 위반auto
→ 정책 강제 적용 (+email)
모든 자동 조치는 "상태를 악화시킬 수 없는" 유형만; 판단형 항목은 리포팅으로 — D1과 동일한 승격 규칙.
AWS Cloud
A · Collect & Detect
IAMAWS IAM
사용자 · Access Key · MFA · 정책 상태
1
CFGAWS Config
규칙 기반 구성 스냅샷
2
λ판정 Lambda24H
match R-01–R-04 → COMPLIANT | VIOLATION
B · 자동 조치
3
EVBEventBridge
위반 유형별 라우팅
4
λ조치 Lambda
R-01 → MFA 강제 적용 R-02 → Key 비활성화 R-03 → 미사용 deactivate R-04 → 정책 강제 적용 (+email)
C · 가시화
5 KDF Kinesis Firehose 판정 스트림 무손실 적재
6 S3 Amazon S3 판정 이력 보존
7 QS
QuickSight주간 IAM 리포트 · 조직 공유
92%COMPLIANT
24H판정 주기
4자동 조치
92%Compliant Rate
W-1주간 리포트
인프라 작업 효율 30%↑ 명제 — 자격증명의 수명을 바꾸면 보안과 속도가 함께 좋아진다.
흐름 ①→⑦ = 탐지 → 자동 조치 → 리포트. 컬러 배지 = 검증된 정량 성과. 성숙도: Defined
IAM Compliance Check · High-Level Design in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
AWS-native 24H cycle 12 policies
RULE CATALOG
R-01MFA missingauto
→ enforce MFA
R-02console-used access keyauto
→ disable key
R-0390d-unused credentialauto
→ deactivate
R-04policy violationauto
→ enforce policy (+email)
Every auto-remediation is a "cannot worsen state" action; judgment items go to reporting — the same promotion rule as D1.
AWS Cloud
A · Collect & Detect
IAMAWS IAM
users · access keys · MFA · policy state
1
CFGAWS Config
rule-based config snapshots
2
λJudge Lambda24H
match R-01–R-04 → COMPLIANT | VIOLATION
B · Automation
3
EVBEventBridge
route by violation type
4
λRemediation Lambda
R-01 → enforce MFA R-02 → disable key R-03 → deactivate unused R-04 → enforce policy (+email)
C · Visibility
5 KDF Kinesis Firehose lossless verdict stream
6 S3 Amazon S3 verdict history
7 QS
QuickSightWeekly IAM Report · org-shared
92%COMPLIANT
24Hjudge cycle
4auto actions
92%Compliant Rate
W-1weekly report
30%↑ infra-work efficiency Thesis — change the credential lifetime, and security & speed improve together.
Flow ①→⑦ = detect → auto-remediate → report. Colored badges = verified quantitative results. Maturity: Defined
그림 3.Fig. 3. IAM 컴플라이언스 — AWS IAM·Config→판정 Lambda→EventBridge→조치 Lambda→주간 리포트.IAM compliance — AWS IAM·Config→Judge Lambda→EventBridge→Remediation→weekly report.
설계Design
  • AWS IAM·Config → 판정 Lambda(24H)로 R1~R4 규칙 판정AWS IAM·Config → Judge Lambda (24H), rules R1–R4
  • EventBridge → 조치 Lambda(MFA강제·키 비활성·미사용키 제거·정책강제)EventBridge → Remediation Lambda
  • 판단형(과다권한·크로스어카운트)은 자동조치 금지 → ReportingJudgment items → Reporting (no auto-remediation)
  • Kinesis→S3→QuickSight 주간 IAM 리포트(전사 공유)Kinesis→S3→QuickSight weekly IAM report
30%↑
인프라 작업 효율(내부)infra-work efficiency (internal)
92%
Compliant Ratecompliant rate
24H
점검 주기check cycle
역량Capability — IAM 컴플라이언스를 24시간 주기로 자동 점검·조치, 인프라 작업 효율 30% 향상.IAM compliance auto-checked and remediated on a 24h cycle; infra-work efficiency +30%.
§옵저버빌러티 · L1–L5 계층 표준 · 커스텀 스택Observability · L1–L5 Layered Standard · Custom Stack

서비스마다 '무엇을 측정할지'의 기준이 제각각이었다. L1(CSP·인프라·모니터링에이전트·Prometheus)~L5(플랫폼) 계층별 표준 지표를 정의하고, Telegraf–Kafka–InfluxDB–Grafana 커스텀 스택으로 4개국이 하나의 관측 화면을 공유하게 했다.Each service set its own bar for 'what to measure'. I defined per-layer standard metrics from L1 (CSP·infra·mon-agent·Prometheus) to L5 (platform) and ran a custom Telegraf–Kafka–InfluxDB–Grafana stack so four countries shared one observability view.

관측성 · L1–L5 + Kafka 배압 in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
5계층 2개 경로 상황실 3곳 · 4개국
L1–L5 계층 표준
L1CSP / 인프라Mon Agent · Prometheus
L2OS / JVMTelegraf
L3컴포넌트Kafka
L4애플리케이션 / 모듈고유량
L5플랫폼서비스 성공율 · 지연
새 서비스는 "무엇을 측정할지"를 새로 발명하지 않는다 — 계층별 표준이 최소선이고, 공백은 계층 단위로 점검 가능.
경로 1 · 직결 시스템 지표 (L1 · L2) Telegraf → InfluxDB 직결 — 저유량 · 예측 가능한 속도. agent → TSDB
경로 2 · 완충 고유량 앱 지표 (L4) Kafka 버퍼가 폭주를 흡수, Consumer 가 소화 속도로 적재. BACKPRESSURE
Consumer 소화 속도로 적재
버퍼가 필요한 이유: 장애 중엔 지표가 폭증한다. 폭증이 저장소를 무너뜨리면 조직은 장애 한가운데서 눈이 먼다 — Kafka 배압이 마지막 가시성을 지킨다.
저장 InfluxDB Org 분리 = 소스별 시리즈 카디널리티 통제. org: infra | mw | app
시각화 Grafana 통합 대시보드 24×7 상황실 3곳의 공통 콘솔 — 4개국 (KR · CN · PH · IN) 이 같은 화면을 본다.
KR CN PH IN
계층별 표준 대시보드 (L1–L5)
V2 · 2023 표준 지표 기반 이상 탐지 워크스트림
실선 = 직결 수집 (L1 · L2) · 주황 점선 = Kafka 배압 완충 고유량 경로 (L4). 계층 표준 = 모든 서비스가 노출해야 하는 최소선. 성숙도: Defined
Observability · L1–L5 with Kafka Backpressure in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
5 layers 2 paths 3 NOCs · 4 countries
L1–L5 Layer Standard
L1CSP / InfraMon Agent · Prometheus
L2OS / JVMTelegraf
L3ComponentKafka
L4Application / Modulehigh-volume
L5Platformservice success · latency
A new service never invents "what to measure" — per-layer standards are the minimum, and gaps are checkable per layer.
Path 1 · Direct System metrics (L1 · L2) Telegraf → InfluxDB direct — low volume, predictable rate. agent → TSDB
Path 2 · Buffered High-volume app metrics (L4) Kafka buffer absorbs the surge; a consumer ingests at digest speed. BACKPRESSURE
Consumer ingest at digest speed
Why the buffer: metrics surge during incidents; if the surge topples storage, the org goes blind mid-incident — Kafka backpressure keeps last-mile visibility.
Store InfluxDB Org-separation = series-cardinality control per source. org: infra | mw | app
Visualize Grafana unified dashboard The shared console of 3 NOCs — 4 countries (KR · CN · PH · IN), the same screen.
KR CN PH IN
per-layer standard dashboards (L1–L5)
V2 · 2023 anomaly-detect workstream on the standard metrics
Solid arrows = direct collection (L1 · L2) · dashed orange = buffered high-volume path (L4) with Kafka backpressure. Layer standard = the minimum every service must expose. Maturity: Defined
그림 4.Fig. 4. 옵저버빌러티 — L1~L5 계층 표준, Telegraf–Kafka–InfluxDB–Grafana 커스텀 스택, 통합 대시보드.Observability — L1–L5 layered standard, custom Telegraf–Kafka–InfluxDB–Grafana stack, unified dashboard.
설계Design
  • L1(CSP·Infra·MonAgent·Prometheus)~L5(Platform) 계층별 표준 지표 정의Per-layer standard metrics, L1(CSP·infra·mon-agent·Prometheus)–L5(platform)
  • Telegraf–Kafka–InfluxDB–Grafana 커스텀 스택Custom Telegraf–Kafka–InfluxDB–Grafana stack
  • Kafka(약 300노드)를 지표 파이프라인의 버퍼로 사용Kafka (~300 nodes) as the buffer in the metrics pipeline
  • 상황실(잠실·광저우) — 4개국이 하나의 화면NOCs (Jamsil·Guangzhou) — 4 countries, one screen
L1–L5
계층 관측 표준layer standards
커스텀 스택Custom stack
Telegraf·Kafka·InfluxDB·Grafanacustom stack
4개국4 countries
같은 화면one screen
역량Capability — L1~L5 계층 표준으로 4개국·상황실 3곳이 하나의 관측 화면을 공유.An L1–L5 layer standard lets 4 countries and 3 NOCs share one observability view.
§EKS 표준 · RTO × WorkGroupEKS Standard · RTO × WorkGroup

실시간/비동기 모듈의 복구목표(RTO)가 다른데 획일 배치는 자원 간섭과 폭발 전파를 낳았다. RTO × WorkGroup × AZ 2축으로 표준 배치를 정의하고 불변 이미지로 부팅을 표준화했다.Realtime vs async modules have different RTOs, yet uniform placement caused interference and blast propagation. I defined standard placement on an RTO × WorkGroup × AZ matrix with immutable-image boot.

EKS 표준 · RTO × WorkGroup × AZ in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
5개 리전 연 2회 업그레이드 2-AZ 표준
노드 표준 — 이미지 & 설정
Immutable AMI (Packer) 에이전트 · 보안을 이미지에 내장 — 부팅 후 드리프트 없음
Consul KV — 부팅 시점 설정 설정과 아티팩트 분리 — 하나의 이미지, 환경별 값
배치 매트릭스 — RTO × WorkGroup 모든 셀 = 2-AZ 표준
WorkGroup APP1전용 노드그룹
WorkGroup APP2전용 노드그룹
WorkGroup APP3전용 노드그룹
짧은 RTO 실시간 모듈 AZ 간 HA + 즉시 failover
AZ-A + AZ-B 동시 가동
AZ-A · app1AZ-B · app1'
즉시 failover — 복제본 상시 대기
AZ-A + AZ-B 동시 가동
AZ-A · app2AZ-B · app2'
격리로 자원 간섭 · 장애 전파 차단
AZ-A + AZ-B 동시 가동
AZ-A · app3AZ-B · app3'
격리로 자원 간섭 · 장애 전파 차단
완화된 RTO 비동기 로직 단일 배치 + 재처리
단일 AZ 배치 장애 시 — 재스케줄 · 큐 재처리, 상시 복제본 비용 없음
단일 AZ 배치 장애 시 — 재스케줄 · 큐 재처리, 상시 복제본 비용 없음
단일 AZ 배치 장애 시 — 재스케줄 · 큐 재처리, 상시 복제본 비용 없음
5개 리전중국 포함 동일 표준
연 2회클러스터 업그레이드 — 방치 없음
IaC 게이트 — Terraform Enterprise + 2인 리뷰프로덕션 단독 반영 경로 없음 — 전 변경 리뷰
세로축 = 복구 등급 (RTO) · 가로축 = WorkGroup 격리. 실선 셀 = AZ 간 HA · 점선 셀 = 단일 배치 + 재처리. 성숙도: Defined
EKS Standard · RTO × WorkGroup × AZ in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
5 regions 2 upgrades/yr 2 AZ standard
Node Standard — image & config
Immutable AMI (Packer) agents & security baked into the image — no post-boot drift
Consul KV — boot-time config config split from artifact; one image, per-env values
Placement Matrix — RTO × WorkGroup every cell = 2-AZ standard
WorkGroup APP1dedicated nodegroup
WorkGroup APP2dedicated nodegroup
WorkGroup APP3dedicated nodegroup
SHORT RTO Realtime modules cross-AZ HA + instant failover
AZ-A + AZ-B active
AZ-A · app1AZ-B · app1'
instant failover — replica always warm
AZ-A + AZ-B active
AZ-A · app2AZ-B · app2'
isolation blocks interference & blast
AZ-A + AZ-B active
AZ-A · app3AZ-B · app3'
isolation blocks interference & blast
RELAXED RTO Async logic single placement + reprocess
Single AZ placement on failure — reschedule & reprocess the queue; no warm replica cost
Single AZ placement on failure — reschedule & reprocess the queue; no warm replica cost
Single AZ placement on failure — reschedule & reprocess the queue; no warm replica cost
5 regionsconsistent standard, incl. China
2× / yearcluster upgrades — never stale
IaC gate — Terraform Enterprise + two-reviewerno solo path to production; every change reviewed
Vertical axis = recovery class (RTO) · horizontal axis = WorkGroup isolation. Solid cells = cross-AZ HA · dashed cells = single placement + reprocess. Maturity: Defined
그림 5.Fig. 5. EKS 표준 — RTO × WorkGroup × AZ 매트릭스, Immutable AMI + Consul KV.EKS standard — RTO × WorkGroup × AZ matrix, Immutable AMI + Consul KV.
설계Design
  • RTO축 — 실시간=cross-AZ HA·즉시 failover / 비동기=단일배치·재처리RTO axis — realtime cross-AZ HA / async single-placement
  • WorkGroup축 — APP 격리로 자원 간섭·폭발 전파 차단WorkGroup axis — isolation blocks interference
  • Immutable AMI(Packer) + Consul KV 부팅 설정Immutable AMI (Packer) + Consul KV boot config
  • 5개 리전 일관 · 연2회 업그레이드 · Terraform 2인 리뷰5 regions consistent · Terraform two-reviewer gate
5개 리전5 regions
일관 표준consistent
2-AZ
이중화redundancy
IaC
2인 리뷰 게이트two-reviewer gate
역량Capability — 5개 리전에 RTO×WorkGroup×AZ 표준 배치, 불변 이미지·2인 리뷰 IaC로 일관 운영.RTO×WorkGroup×AZ standard placement across 5 regions, kept consistent by immutable images and two-reviewer IaC.
§무중단 네트워크 재설계 · 4,000 WASZero-downtime Network Re-arch · 4,000 WAS

성장에 따른 IP 고갈·보안그룹 복잡성이 한계에 달했고 라우팅 변경이 서브넷으로 연쇄됐다. 4,000여 대 WAS의 네트워크를 서비스 무중단으로 3년간 표준 정책으로 재편했다.IP exhaustion and SG complexity hit their limit; a route change cascaded across subnets. I re-architected the network for 4,000+ WAS across 5 regions to standard policy over 3 years with zero service impact.

무중단 네트워크 재설계 · 4,000 WAS in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
3년 5개 리전 서비스 영향 0
As-Is · 구조적 한계
IP 대역 고갈 — 증설 여유 없음
Route Table 연쇄 결합 — 변경 1건이 연쇄 파급
방치된 Security Group — 소유자 없는 규칙
사실상 전면 개방 VPC Endpoint — anyopen
Public 경유 Peering — 내부 트래픽 우회
In/Out 트래픽 불명 — 누가 누구를 호출하는지 아무도 모름
SG 1개의 종속성 파악에 반나절이 걸렸다.
프로그램 · 단계적 영향 반경
STAGE 1운영 자원
STAGE 2일부 컴포넌트
STAGE 3전체 모듈
단계마다 정량 검증 + 롤백 기준 — 증거가 있어야만 다음 단계로.
핵심 동력 — 자체 구축 Grafana 트래픽 분석기 iftop + VPC Flow Logs + Athena/S3 In/Out 흐름 · 삭제된 자원 호출 · reject 를 식별 — 인터뷰로는 만들 수 없던 지도.
인터뷰 기반 매핑은 실패했다 주 1회 호출 API 를 놓침 → 실제 장애 발생. 그 실패가 도구를 낳았다.
Terraform + two-reviewer 일 / 주 / 분기 점검
To-Be · 표준 구조
표준 3계층 서브넷 — public / private / closed
표준 SG — 서비스 단위 최소 규칙
표준 연결 — endpoint · peering · route 3종만 허용
휴먼 에러 · 잠재 리스크 — 대폭 감소
신규 모듈 인프라 협의반나절
~2일 계획 · 재작업 0
2020.03
2022.10 3년 · 5개 리전 · 서비스 영향 0
Stateful 계층 (DB · Kafka · Redis) 은 재기동 시점 이관 — 별도 트랙. 3년 = 지연이 아니라 "조직이 얼마나 빨리 탐지하고 롤백할 수 있는가"가 정한 상한.
실선 = 이관 방향 · 점선 프레임 = 레거시 한계. 모든 네트워크 변경은 IaC 2인 리뷰 게이트를 통과. 성숙도: Defined
Zero-downtime Network Re-architecture · 4,000 WAS in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
3 years 5 regions service impact 0
As-Is · the limits
IP-pool exhaustion — no room to grow
Coupled route tables — one change cascades
Unmanaged security groups — rules nobody owns
Effectively-open VPC endpoints — anyopen
Public-routed peering — internal traffic detours
Unknown in/out traffic — nobody can say who calls whom
Tracing one SG's dependencies took half a day.
The Program · staged blast-radius
STAGE 1ops resources
STAGE 2some components
STAGE 3all modules
Quantitative validation + rollback criteria at each stage — a stage advances only on evidence.
Key enabler — self-built Grafana traffic analyzer iftop + VPC Flow Logs + Athena/S3 identifies in/out flows, calls to deleted resources, rejects — the map interviews could not produce.
Interview-based mapping FAILED a once-a-week API was missed → a real outage. The failure bred the tool.
Terraform + two-reviewer day / week / quarter checks
To-Be · the standard
Standard 3-tier subnet — public / private / closed
Standard SG — service-unit minimal rules
Standard connectivity — endpoint · peering · route, 3 patterns only
Human-error & latent risk — sharply down
new-module infra talkshalf a day
~2 days planned, zero rework
2020.03
2022.10 3 years · 5 regions · service impact 0
Stateful tiers (DB · Kafka · Redis) migrated on restart — a separate track. 3 years = a ceiling set by "how fast the org can detect and roll back", not a delay.
Solid arrows = migration direction · dashed frame = legacy limits. Every network change flowed through the IaC two-reviewer gate. Maturity: Defined
그림 6.Fig. 6. 무중단 재설계 — 3단계 blast-radius, 자체 트래픽 분석기, 단계별 검증·롤백.Zero-downtime re-arch — 3-stage blast-radius, self-built traffic analyzer, staged validation/rollback.
프로그램 관리Program management
  • 3단계 blast-radius(ops→일부→전체) · 각 단계 정량검증·롤백3-stage blast-radius with validation/rollback
  • 핵심 enabler = 자체 Grafana 트래픽 분석기(iftop+VPC Flow Logs+Athena)Key enabler = a self-built Grafana traffic analyzer
  • 인터뷰 기반 매핑 실패(주1회 API 누락→실장애)가 도구를 낳음Interview-based mapping failed → the failure bred the tool
  • Terraform 2인 리뷰 게이트Terraform two-reviewer gate
4,000+ WAS
무중단 단계 이전zero-downtime migration
3년3 years
서비스 영향 00 service impact
5개 리전5 regions
전체 재설계re-architected
역량Capability — 5개 리전 4,000여 대 WAS를 3년간 서비스 영향 0으로 재편.Re-architected 4,000+ WAS across 5 regions over 3 years with zero service impact.
§변경관리 · 월 500건 단일 데이터셋Change Management · 500/mo on one dataset

월 500여 건의 변경이 흩어져 추적·책임이 모호했다. 모든 변경을 JIRA 티켓·유형화·EPIC 소속으로 강제해 '어느 EPIC'이 판단이 아니라 조회가 되게 했다.~500 changes/month were scattered, making tracking and ownership fuzzy. I forced every change to be a typed JIRA ticket that must belong to an EPIC — turning 'which EPIC' from a judgment into a lookup.

변경관리 · 월 500건, 하나의 데이터셋 in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
월 500건 변경 10개 EPIC 그룹 60–70명 · 4개국
3계층 보드 · Power BI
EPIC GROUP → EPICDone / Cnt / Rate
고정 10그룹 — 모든 티켓은 반드시 소속
TASKStatus / Elapsed / Due
월 500건 전량 JIRA 티켓 — 티켓 밖 작업 없음
SUB-TASK상위 필수
실행 단위 — 고아 작업이 구조적으로 불가능
"어느 EPIC?"은 판단이 아니라 조회가 된다. 4개국 60–70명이 하나의 작업 데이터셋 위에서 움직이고, 작업 종료 회고가 역량을 문서로 축적한다.
10개 EPIC 그룹 — 고정 분류 체계
01Architecture
02Security
03Cost
04CI/CD
05Monitoring
06Work / MW / DB
07Incident
08Infra
09K8S
10Ops-solution
모든 변경은 JIRA 티켓으로, 유형이 지정되고 EPIC 에 의무 소속 — 과거 작업이 기억이 아니라 그룹으로 조회된다.
17항목 DB 점검 · 리듬
9 성능 항목
8 적격성 / 보안 항목
정기 수행 · 보고 공유 — DB 건강은 의견이 아니라 체크리스트.
점검 리듬
DAILY운영 점검 — 대시보드 · 알림 · 야간 변경
WEEKLY보드 리뷰 — 지연 · 임박 작업 표면화
QUARTERLY심층 점검 — DB 17항목 · 추세 · 용량 리뷰
리듬은 점검을 이벤트가 아닌 상시 습관으로 바꾼다 — 4개국 모두 동일한 주기.
좌 = 모든 티켓이 사는 위계 · 중앙 = 고정 분류 체계 · 우 = 점검 주기. 하나의 데이터셋, 하나의 분류, 하나의 리듬. 성숙도: Defined
Change Management · 500/mo on One Dataset in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
500 changes/mo 10 EPIC groups 60–70 people · 4 countries
3-tier Board · Power BI
EPIC GROUP → EPICDone / Cnt / Rate
10 fixed groups — every ticket must belong to one
TASKStatus / Elapsed / Due
500/mo, all typed JIRA tickets — no off-ticket work
SUB-TASKparent required
execution unit — orphan work is structurally impossible
"Which EPIC?" becomes a lookup, not a judgment. 60–70 people across 4 countries move on one work dataset; end-of-task retros accumulate capability into docs.
10 EPIC Groups — the fixed taxonomy
01Architecture
02Security
03Cost
04CI/CD
05Monitoring
06Work / MW / DB
07Incident
08Infra
09K8S
10Ops-solution
Every change is a JIRA ticket, typed, and must belong to an EPIC — past work becomes queryable by group, not by memory.
17-item DB Check · Rhythm
9 Performance items
8 Qualification / Security items
periodic, report-shared — DB health is a checklist, not an opinion.
INSPECTION RHYTHM
DAILYops checks — dashboards · alerts · overnight changes
WEEKLYboard review — overdue & imminent tasks surfaced
QUARTERLYdeep checks — DB 17-item · trend & capacity review
The rhythm turns inspection from an event into a standing habit — the same cadence in all 4 countries.
Left = the hierarchy every ticket lives in · center = the fixed taxonomy · right = the inspection cadence. One dataset, one taxonomy, one rhythm. Maturity: Defined
그림 7.Fig. 7. 변경관리 — EPIC 3계층 보드, 10 EPIC 그룹, 17-item DB 점검, 점검 리듬.Change management — 3-tier EPIC board, 10 groups, 17-item DB check, cadence.
거버넌스Governance
  • EPIC GROUP→TASK→SUB-TASK 3계층(Power BI 보드)EPIC GROUP→TASK→SUB-TASK 3-tier (Power BI board)
  • 10 EPIC 그룹 · 17-item DB 점검(성능9·자격보안8)10 EPIC groups · 17-item DB check
  • 일/주/분기 점검 리듬daily/weekly/quarterly cadence
  • 4개국 60~70명이 하나의 작업 데이터셋으로 이동60–70 people across 4 countries on one dataset
500건/월500/mo
전건 JIRAall in JIRA
10 그룹10 groups
EPIC 위계EPIC hierarchy
단일Single
작업 데이터셋one dataset
역량Capability — 월 500여 건 변경을 전건 EPIC 소속 JIRA 티켓으로, 4개국 60~70명이 단일 데이터셋으로 운영.~500 changes/month all as EPIC-owned JIRA tickets; 60–70 people across 4 countries on one dataset.
§분산 SQL 전환 · MariaDB XpandDistributed SQL Cutover · MariaDB Xpand

MySQL 4-샤드 구조가 확장·운영의 한계에 달했다. MariaDB Xpand 분산 DB로 서비스 무중단 전환해 확장성을 확보하고 DB 비용을 절반으로 줄였다.A 4-shard MySQL topology hit its scaling and operational ceiling. I cut over to the MariaDB Xpand distributed database with zero downtime — gaining elasticity and halving DB cost.

분산 SQL 전환 · MariaDB Xpand in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
~1,000대 DB 규모 서비스 무중단
무중단 전환Zero-downtime cutover
AS-IS · MySQL 4-샤드
Shard 1MySQL · 수동 분할
Shard 2MySQL · 수동 분할
Shard 3MySQL · 수동 분할
Shard 4MySQL · 수동 분할
한계 — 애플리케이션 레벨 수동 샤딩 · 확장·리샤딩 고통 · 운영 부담. 성장에 따라 천장에 도달.
TO-BE · MariaDB Xpand 분산 SQL
N1 N2 N3 N4 N5 …
▸ 셰어드-나띵 분산 — 앱은 단일 DB로 인식
▸ 노드 추가로 탄력 확장 · 자동 리밸런스
▸ 분산 트랜잭션 · 자동 페일오버
효과 — 약 1,000대 DB 규모에서 서비스 무중단 전환. 수동 샤딩 제거 → 확장성 확보. (제3자 공개 사례: 일 100억+ 요청 인증)
−50%DB 비용 효율
(제3자 공개근거)
~1,000대 DB 규모
전환 수행
0서비스 다운타임
무중단 이관
100억+일 요청 인증
(MariaDB 공개 사례)
Distributed SQL Cutover · MariaDB Xpand in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
~1,000 DB nodes zero downtime
Zero-downtimecutover
AS-IS · MySQL 4-shard
Shard 1MySQL · manual split
Shard 2MySQL · manual split
Shard 3MySQL · manual split
Shard 4MySQL · manual split
Limits — application-level manual sharding · painful scaling/resharding · ops burden. Hit the ceiling as it grew.
TO-BE · MariaDB Xpand distributed SQL
N1 N2 N3 N4 N5 …
▸ Shared-nothing distribution — app sees a single DB
▸ Elastic scale by adding nodes · auto-rebalance
▸ Distributed transactions · auto-failover
Outcome — zero-downtime cutover across ~1,000 DB nodes. Manual sharding removed → elasticity gained. (Third-party public case: 10B+ requests/day authenticated)
−50%DB cost
(third-party public)
~1,000DB nodes
migrated
0service downtime
zero-DT migration
10B+requests/day
(MariaDB public case)
그림 §.Fig. §. AS-IS MySQL 4-샤드 → 무중단 전환 → MariaDB Xpand 분산 SQL(~1,000대) · DB 비용 −50%(제3자 공개근거).AS-IS MySQL 4-shard → zero-downtime cutover → MariaDB Xpand distributed SQL (~1,000 nodes) · DB cost −50% (public-sourced).
전환Cutover
  • MySQL 4-샤드 → Xpand 분산 DB로 서비스 무중단 전환MySQL 4-shard → Xpand distributed DB, zero-downtime cutover
  • 약 1,000대 DB 규모에서 수행Executed across ~1,000 database nodes
  • 전환 효과는 제3자 공개 기사로 근거화Outcome evidenced by a third-party public article
50%↓
DB 비용 효율(공개근거)DB cost (public-sourced)
1,000대1,000 DBs
DB 규모DB nodes
무중단Zero-DT
서비스 영향 0zero downtime
역량Capability — 약 1,000대 DB 규모에서 MySQL 4샤드를 분산 DB로 무중단 이관, DB 비용 50% 절감(공개근거).Zero-downtime cutover from 4-shard MySQL to distributed SQL across ~1,000 DBs, DB cost −50% (public-sourced).
참고RefsMariaDB 고객사례MariaDB Case Study
§Azure 멀티클라우드 도입Azure Multi-cloud Adoption

AWS S3 용량 위기에 대비해 단일 CSP 의존을 낮춰야 했다. Azure Blob 백업 스토리지를 도입하고, 2년간의 기능 협상을 거쳐 중국 포함 5개 리전을 오픈해 크로스클라우드 이중화를 완성했다.An AWS S3 capacity crunch made single-CSP dependence a risk. I introduced Azure Blob backup storage and — over two years of feature negotiation — opened five regions incl. China, completing cross-cloud redundancy.

Azure 멀티클라우드 도입 in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
중국 포함 5개 리전 Azure 5년+
가중치 primary
가중치 backup
Route 53가중치 기반 크로스클라우드 라우팅
AWS · Primary
S3 · 주 스토리지주 서비스 데이터 계층
주 컴퓨트·서비스글로벌 서비스 본체
계기 — AWS S3 용량 위기 → 단일 CSP 의존 리스크 부각
Azure · Backup
Blob · 백업 스토리지크로스클라우드 백업 계층
이중화 대상장애·용량 시 페일오버
협상 — 2년 기능 협상 끝에 중국 포함 5개 리전 오픈
크로스클라우드
이중화
5개 리전 (중국 포함)
리전 1 리전 2 리전 3 리전 4 중국
단일 CSP 의존을 낮추기 위해 Azure Blob 백업 스토리지를 도입하고, 2년 기능 협상을 거쳐 중국 포함 5개 리전을 오픈해 Route 53 가중치 기반 크로스클라우드 HA를 완성. Azure hands-on 5년+.
Azure Multi-cloud Adoption in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
5 regions incl. China 5+ yrs Azure
weighted primary
weighted backup
Route 53weighted cross-cloud routing
AWS · Primary
S3 · primary storageprimary service data tier
Primary compute·servicesglobal service core
Trigger — AWS S3 capacity crunch → single-CSP dependence became a risk
Azure · Backup
Blob · backup storagecross-cloud backup tier
Redundancy targetfailover on incident/capacity
Negotiation — 5 regions incl. China opened after a 2-year feature negotiation
Cross-cloud
redundancy
5 REGIONS (INCL. CHINA)
Region 1 Region 2 Region 3 Region 4 China
To cut single-CSP dependence, introduced Azure Blob backup storage and — over a 2-year feature negotiation — opened 5 regions incl. China, completing Route 53 weighted cross-cloud HA. 5+ years hands-on Azure.
그림 §.Fig. §. Route 53 가중치 라우팅 — AWS(Primary) + Azure Blob(Backup) 크로스클라우드 이중화, 중국 포함 5개 리전.Route 53 weighted routing — AWS (primary) + Azure Blob (backup) cross-cloud redundancy across 5 regions incl. China.
도입Adoption
  • AWS S3 용량 위기 → Azure Blob 백업 스토리지 도입AWS S3 capacity crunch → Azure Blob backup storage
  • 2년 기능 협상 후 중국 포함 5개 리전 오픈5 regions incl. China opened after 2-year feature negotiation
  • Route 53 가중치 기반 크로스클라우드 HARoute 53 weighted cross-cloud HA
  • Azure hands-on 5년+5+ years hands-on Azure
5개 리전5 regions
중국 포함incl. China
2 CSP
크로스클라우드 HAcross-cloud HA
5년+5+ yrs
Azure hands-onhands-on
역량Capability — 2년 협상 끝에 Azure를 도입해 중국 포함 5개 리전 멀티클라우드 이중화 완성(Azure 5년+).Added Azure after a 2-year negotiation, completing multi-cloud redundancy across 5 regions incl. China (5+ yrs Azure).
§FinOps · 비용 거버넌스FinOps · Cost Governance

비용이 모듈 경계 없이 흐르면 누가 무엇을 쓰는지 불투명해진다. 태깅 정책과 모듈별 예산·경보로 비용을 소유화하고, 바이너리 트래픽 존을 분리해 트래픽 비용을 크게 줄였다.When cost flows without module boundaries, ownership blurs. I made cost owned via tagging and per-module budgets/alerts, and split a binary-traffic zone to cut traffic cost sharply.

FinOps · 비용 거버넌스 in 1 Diagram
Jeonho James Kim — 삼성 클라우드 SRE
Inform → Optimize → Operate 비용 소유화
비용이 모듈 경계 없이 흐르면 소유가 불투명해진다 — 태깅으로 귀속하고 팀·모듈이 직접 소유하게 만든다.
1 · Inform — 태깅 태깅 정책 — 모든 리소스 귀속
▸ 팀·모듈·환경 태그 강제 ▸ "누가 무엇을 쓰는가"를 조회 가능하게
2 · Optimize — 예산·경보 모듈별 budget · 일별 추이 · Alert
▸ 모듈별 예산 설정 + 일별 비용 추이 ▸ 임계 초과 시 소유자에게 직접 Alert (중앙 중계 0)
3 · Operate — 소유화 비용을 팀·모듈이 직접 소유
▸ 소유자 직통 예산 알림 — 중앙 중계 없음 ▸ 비용을 상시 운영 지표로 (Operate)
핵심 레버바이너리 트래픽 존 분리
대용량 바이너리 트래픽을 전용 존으로 분리해 데이터 전송 경로·과금을 격리 → 트래픽 비용을 구조적으로 절감. 태깅·예산이 "어디서 새는지"를 보이게 하고, 존 분리가 그걸 실제로 막는다.
−40%트래픽
비용
트래픽 비용 −40% 모듈별 예산·경보 태깅 비용 소유화 비용을 "관리 대상"이 아니라 "팀이 소유하는 운영 지표"로 전환.
FinOps · Cost Governance in 1 Diagram
Jeonho James Kim — Samsung Cloud SRE
Inform → Optimize → Operate cost ownership
When cost flows without module boundaries, ownership blurs — attribute it by tagging and make teams·modules own it.
1 · Inform — tagging Tagging policy — attribute every resource
▸ Enforce team·module·env tags ▸ Make "who uses what" a lookup
2 · Optimize — budget·alerts Per-module budget · daily trend · Alert
▸ Per-module budgets + daily cost trend ▸ Alerts straight to the owner on threshold (no central relay)
3 · Operate — ownership Teams·modules own the cost directly
▸ Owner-direct budget alerts — no central relay ▸ Cost as a standing operational metric (Operate)
Key leverBinary-traffic-zone split
Isolate heavy binary traffic into a dedicated zone, separating transfer path and billing → structurally cut traffic cost. Tagging·budgets show where it leaks; the zone split actually stops it.
−40%traffic
cost
Traffic cost −40% Per-module budget·alerts Tagging cost ownership Turn cost from something "managed" into an operational metric teams own.
그림 §.Fig. §. Inform→Optimize→Operate — 태깅 귀속 → 모듈별 예산·경보 → 팀 소유화, 바이너리 트래픽 존 분리로 트래픽 −40%.Inform→Optimize→Operate — tag-attribution → per-module budgets·alerts → team ownership; a binary-traffic-zone split cut traffic −40%.
운영Operation
  • 태깅 정책 + 모듈별 budget · 일별 비용 추이 · AlertTagging policy + per-module budget · daily trend · alerts
  • 바이너리 트래픽 존 분리로 트래픽 비용 절감Binary-traffic zone split to cut traffic cost
  • 비용을 팀·모듈이 소유하는 구조로 전환Shifted cost ownership to teams/modules
40%↓
트래픽 비용traffic cost
모듈별Per-module
예산·경보budget·alerts
태깅Tagging
비용 소유화cost ownership
역량Capability — 태깅·모듈별 예산·바이너리 트래픽 존 분리로 트래픽 비용 40% 절감.Tagging, per-module budgets and a binary-traffic-zone split cut traffic cost 40%.
§미디어솔루션 결제·빌링 (초기)Media Solution Payment·Billing (early)

삼성 커리어의 시작은 미디어솔루션센터 빌링서비스그룹의 백엔드였다. 결제·빌링 서비스를 개발·운영하며 대규모 트랜잭션 백엔드의 기초를 다졌다.My Samsung career began as a backend engineer in the Media Solution Center billing group — developing and operating payment/billing services and building my foundation in high-volume transactional backends.

개발·운영Dev & Ops
  • 결제·빌링 서비스 백엔드 개발·운영 (2010–2012)Payment/billing service backend dev & ops (2010–2012)
  • 대규모 트랜잭션 처리의 실무 기초Hands-on foundation in high-volume transaction processing
2010–2012
빌링 백엔드billing backend
결제·빌링Billing
개발·운영dev & ops
역량Capability — 미디어솔루션센터에서 결제·빌링 백엔드 개발·운영(2010~2012).Developed and operated payment/billing backends at the Media Solution Center (2010–2012).

티맥스소프트TmaxSoft

2007.07–2010.10
책임 · EAI 미들웨어(AnyLink) 개발·팀리드Principal · EAI middleware (AnyLink) dev · team lead
주요 고객·파트너Key clients · partners기업은행IBK외환은행KEB
UMIT

유미트UMIT

2005.12–2007.07
대리 · EDI개발팀Assistant manager · EDI dev team
주요 고객·파트너Key clients · partnersKFTC
2금융결제원 TrusBill · EDI (초기)KFTC TrusBill · EDI (early)

유미트 기술연구소 EDI개발팀에서 금융결제원 TrusBill(전자세금계산서)과 EDI 시스템을 개발했다. 금융 전자문서 교환을 엔드투엔드로 다뤘다.At Umeat's R&D EDI team I built the KFTC TrusBill (e-tax-invoice) and EDI systems — handling financial electronic-document exchange end to end.

개발Development
  • 금융결제원 TrusBill(전자세금계산서) · EDI 시스템 개발Built the KFTC TrusBill (e-tax-invoice) and EDI systems
  • JAVA · C · MFC · Pro-C로 금융 전자문서 교환 구현Implemented financial e-document exchange in JAVA · C · MFC · Pro-C
2005–2007
EDI 개발EDI dev
금융결제원KFTC
TrusBillTrusBill
역량Capability — 금융결제원 TrusBill(전자세금계산서)·EDI 시스템 개발 (JAVA·C·MFC·Pro-C).Built KFTC TrusBill (e-tax-invoice) and EDI systems (JAVA·C·MFC·Pro-C).

청호ICTChungho ICT

2004.03–2005.11
사원 · 금융개발팀 (ATM/CD 제어)Engineer · finance dev team (ATM/CD control)
주요 고객·파트너Key clients · partners신한Shinhan신협Shinhyup코스콤Koscom
1ATM/CD 제어 · 금융 단말 (초기)ATM/CD Control · Financial Terminals (early)

청호컴넷 기술연구소 금융개발팀에서 은행 ATM/CD 기기 제어와 디바이스 통신·암호화를 개발했다. 금융 단말의 저수준 제어·통신 프로토콜로 커리어를 시작했다.At Chungho's R&D finance team I developed bank ATM/CD device control, device communication and encryption — starting my career on low-level control and comms protocols for financial terminals.

개발Development
  • 은행 ATM/CD 기기 제어 개발 — 디바이스 통신·암호화Bank ATM/CD device control — device comms & encryption
  • 금융 단말의 저수준 제어·통신 프로토콜Low-level control and comms protocols for financial terminals
2004–2005
금융 단말 개발terminal dev
신한은행Shinhan
납품 맥락client context
역량Capability — 은행 ATM/CD 기기의 저수준 제어·디바이스 통신·암호화 개발 (2004~2005).Developed low-level control, device comms and encryption for bank ATM/CD terminals (2004–2005).

주해Notes

본인이 설계·수행한 운영 방법론과 정량 성과 요약. 前 소속사 기밀·내부 문서 미포함, 서비스명·코드네임·내부 재무 제외. 모든 수치는 1차 출처 확인값. 내부 측정치(40·30)와 제3자 공개근거(−50)를 구분·비병합. 주요 고객·파트너는 프로젝트 맥락 표기이며 세부 계약은 비공개.A summary of methodology and quantified results I designed and ran. No confidential documents; service names, code-names, internal financials excluded. All figures primary-source-verified; internal metrics (40, 30) and third-party public evidence (−50) labeled distinctly. Client/partner names denote project context; contract details withheld.