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

유튜브 학습을 만다라트 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.

• React/TS ↔ Fastify(Prisma) ↔ PostgreSQL+pgvector + 분리된 Python AI 사이드카 (AWS EC2·Terraform)React/TS ↔ Fastify(Prisma) ↔ pgvector + separate Python AI sidecar (AWS EC2·Terraform)
• RAG — BGE-M3 임베딩 → 리랭킹 → LLM-as-Judge(3단) → LLM Picker(Claude Haiku)RAG — BGE-M3 embedding → reranking → LLM-as-Judge (3-stage) → LLM Picker (Claude Haiku)
• 요약 품질 — Qwen3.5-9B 등 멀티모델 + 품질 점수 비교(비용보다 일관성 우선)Summary quality — multi-model incl. Qwen3.5-9B + quality scoring (consistency over cost)
• 세그먼트 관련도 Haiku 스코어러(보간 0) · 트랜스크립트 미저장Segment-relevance Haiku scorer (interpolation-0) · no transcript storage

학습 조각(카드·영상·노트)들이 어떻게 연결되는지 보여줄 구조가 없었다. 만다라트를 중심축으로 한 서비스 온톨로지를 설계해 지식을 노드-엣지 그래프로 축적·시각화한다.Knowledge fragments (cards, videos, notes) had no way to show how they connect. I designed a Mandalart-centric service ontology that accumulates and visualizes knowledge as a node–edge graph.

• 서비스 온톨로지 — 9개 노드타입 · 5개 엣지(CONTAINS·PLACED_IN·DERIVED_FROM·REFERENCES·TAGGED_WITH)Service ontology — 9 node types · 5 edge types
• PostgreSQL + pgvector로 그래프·임베딩 일원화(별도 그래프DB 없이)Graph + embeddings unified on PostgreSQL + pgvector (no separate graph DB)
• 서비스≠시스템 도메인 분리 — 사용자 온톨로지만 그래프뷰에 노출service ≠ system domain split — only the user ontology is exposed
• 완료데이터 SSOT=북인덱스(chapter=만다라트 셀, section=영상) → GraphRAG 기반Completed-data SSOT = book-index → basis for GraphRAG

품질을 데이터로 끌어올리기 위해 자체 데이터셋을 만들고, 웹을 넘어 모바일까지 접점을 넓혔다.To raise quality with data, I built an own dataset and extended the product beyond web to mobile.

• 만다라트 V3 데이터셋(KO 3K + EN 3K) 자체 구축Own Mandalart V3 dataset (KO 3K + EN 3K)
• Qwen LoRA 파인튜닝(Unsloth) — 예정Qwen LoRA fine-tuning (Unsloth) — planned
• 모바일 앱 Dial (insighta.one/dial)Mobile app Dial (insighta.one/dial)
• 요약 파이프라인 AWS Spot + OpenRouter 병행 운영Summary pipeline on AWS Spot + OpenRouter

프로젝트 현황이 여러 소스에 흩어져 커뮤니케이션 비용이 컸다. 내가 발의·기획하고 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.

• 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·Sheets/SFDC·PMS)4-source integration (Jira·Confluence·Sheets/SFDC·PMS)

삼성 이후 클라우드 컨설팅에서 프로그램·프로세스 거버넌스를 총괄했다. 6팀의 상이한 개발을 표준 SDLC로, 글로벌 완성차 계열 13개 마이그레이션을 PMO로 정렬했다.After Samsung, I led program and process governance in cloud consulting — aligning 6 teams' divergent development into a standard SDLC, and a global automotive group's 13-project migration under a PMO.

• 6팀 7영역 진단 → 하이브리드 표준 SDLC(ISO 12207·CMMI·SAFe·ITIL v4)6 teams, 7-category diagnosis → hybrid standard SDLC
• Jira 표준 워크플로우 · 제품 Tier · 경영진 바이위클리 거버넌스Jira templates · product Tier · bi-weekly governance
• 13-프로젝트 마이그레이션 PMO · 12관문 · RACI · L1–L513-project migration PMO · 12 gates · RACI · L1–L5
• AWS Control Tower/Landing Zone · 미국 어바인 3개월+ 현지(영어)AWS Control Tower/Landing Zone · 3+ months on-site in Irvine

사우디 아람코 디지털의 클라우드 관리 플랫폼 PoC를 수행 PM으로 이끌었다. SOW/WBS 문제 14건을 진단·개선하고 비기능 요건과 사우디 수행 가이드북을 설계했다.I led the CMP PoC for Aramco Digital (Saudi) as delivery PM — diagnosing and remediating 14 SOW/WBS issues and designing the non-functional requirements and a Saudi delivery guidebook.

• USD 약 2M · 16주 글로벌(사우디) 컨설팅 수행 PMDelivery PM for a ~USD 2M · 16-week global (Saudi) engagement
• SOW/WBS 문제 14건 진단·개선Diagnosed and remediated 14 SOW/WBS issues
• 비기능 요건(가용성 99.9% · RPO/RTO · 100만+ 자산) 설계Designed NFRs (99.9% availability · RPO/RTO · 1M+ assets)
• 사우디 수행 가이드북 v2.0Saudi delivery guidebook v2.0

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.

• 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

약 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.

• 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

계정·권한이 개별 관리되고 정적 키가 흩어져 보안·운영 리스크가 컸다. 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.

• 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

서비스마다 '무엇을 측정할지'의 기준이 제각각이었다. 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(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

실시간/비동기 모듈의 복구목표(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.

• 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

성장에 따른 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.

• 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

월 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.

• 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

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.

• 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

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.

• 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

비용이 모듈 경계 없이 흐르면 누가 무엇을 쓰는지 불투명해진다. 태깅 정책과 모듈별 예산·경보로 비용을 소유화하고, 바이너리 트래픽 존을 분리해 트래픽 비용을 크게 줄였다.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.

• 태깅 정책 + 모듈별 budget · 일별 비용 추이 · AlertTagging policy + per-module budget · daily trend · alerts
• 바이너리 트래픽 존 분리로 트래픽 비용 절감Binary-traffic zone split to cut traffic cost
• 비용을 팀·모듈이 소유하는 구조로 전환Shifted cost ownership to teams/modules

삼성 커리어의 시작은 미디어솔루션센터 빌링서비스그룹의 백엔드였다. 결제·빌링 서비스를 개발·운영하며 대규모 트랜잭션 백엔드의 기초를 다졌다.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.

• 결제·빌링 서비스 백엔드 개발·운영 (2010–2012)Payment/billing service backend dev & ops (2010–2012)
• 대규모 트랜잭션 처리의 실무 기초Hands-on foundation in high-volume transaction processing

EAI 미들웨어 AnyLink 개발과 금융 시스템 SW로 커리어의 기초를 다졌다. 이기종 시스템 연계와 대량 트랜잭션 처리를 엔진 레벨로 다뤘다.Built my foundation on the EAI middleware AnyLink and finance/system software — handling heterogeneous system integration and high-throughput transactions at the engine level.

• 인터페이스 유형(MCI·FEP·EAI)을 엔진 레벨로 통합Unify interface types (MCI·FEP·EAI) at the engine level
• Adapter · Mapping · Service Flow Engine 엔진 코어Adapter · Mapping · Service Flow Engine core
• 상용 WAS 기반 무중단(클러스터링·Fail-Over·Hot Deploy)Commercial-WAS zero-downtime (clustering·Fail-Over·Hot Deploy)
• 국내 주요 금융권 다수 도입(제품 실적, 개인 성과 아님)Adopted across major domestic financial firms (product references, not personal results)

유미트 기술연구소 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.

• 금융결제원 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

청호컴넷 기술연구소 금융개발팀에서 은행 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.

• 은행 ATM/CD 기기 제어 개발 — 디바이스 통신·암호화Bank ATM/CD device control — device comms & encryption
• 금융 단말의 저수준 제어·통신 프로토콜Low-level control and comms protocols for financial terminals