2026-08-28 Platform Engineering 입문 브리프

오늘의 기술 토픽 Platform Engineering 이번 자료는 특정 밋업 발표가 아니라 Platform Engineering이라는 주제를 중심으로 정리한 기술 브리프이다. 개발자가 인프라를 직접 다루지 않고도 애플리케이션을 배포하고 운영할 수 있도록 돕는 내부 개발자 플랫폼(IDP)의 개념과 관련 생태계를 소개한다. Crossplane, Argo CD, Backstage 같은 도구들이 어떻게 이 흐름을 뒷받침하는지 설명하고, 셀프서비스와 플랫폼을 제품처럼 다루는 최근 트렌드를 정리한다. 🔑 핵심 요점 Platform Engineering은 개발자 생산성을 높이기 위해 내부 개발자 플랫폼(IDP)을 구축하는 활동이다. 핵심 목표는 개발자가 인프라 세부사항을 몰라도 셀프서비스로 리소스를 만들고 배포할 수 있게 하는 것이다. Crossplane 같은 도구는 클라우드 리소스를 쿠버네티스 API 방식으로 선언적으로 관리할 수 있게 해준다. Argo CD는 GitOps 방식으로 애플리케이션 배포를 자동화하는 데 널리 쓰인다. Backstage는 개발자 포털을 만들어 여러 도구와 서비스 카탈로그를 한 곳에서 관리하게 해준다. 플랫폼을 하나의 제품처럼 취급하고 내부 개발자를 고객으로 대하는 관점이 이 생태계의 핵심 방향이다. 🛠 핵심 기술 쉽게 이해하기 Platform Engineering Platform Engineering은 개발자가 애플리케이션을 더 빠르고 안전하게 만들고 배포할 수 있도록 내부 플랫폼을 설계하고 운영하는 분야이다. 이 플랫폼은 보통 쿠버네티스, CI/CD, 모니터링 등의 도구를 조합해서 만들어진다. ...

August 28, 2026 · 3 min · 538 words · jeonck

2026-08-28 AI 시대의 데이터 파이프라인: PostgreSQL, Iceberg, CDC로 페르소나별 아키텍처 만들기

📋 밋업 한눈에 보기 발표자는 그동안 AI 학습에 투입해 온 값비싼 인프라와 경험을 운영 환경에서 재활용하기 위해, 분석가·데이터 사이언티스트·ML 엔지니어 등 사용자 유형(페르소나)별로 서로 다른 3개의 데이터 파이프라인을 구축한 경험을 공유했다. PostgreSQL을 트랜잭션과 분석을 함께 처리하는 중심 데이터베이스로 삼고, CDC로 변경 데이터를 캡처해 자연어 인터페이스에 연결하거나 Apache Iceberg 기반 lakehouse로 모으는 구조를 소개했다. 발표 후반에는 Kafka를 Kubernetes 오퍼레이터로 운영하는 방식과 KRaft로의 전환, 그리고 AI 에이전트가 DB에 접근할 때 필요한 보안(시크릿 관리, SELECT 전용 권한) 이야기가 이어졌다. 전반적으로 오픈소스와 CNCF 커뮤니티에 경험을 되돌려주고 싶다는 메시지가 강조됐다. ...

August 28, 2026 · 4 min · 709 words · jeonck

2026-08-28 Flink 데이터 플랫폼과 Kubernetes 유지보수 시대응 Job 스케줄러

📋 밋업 한눈에 보기 인도에서 온 발표자가 자신의 팀이 스트리밍 데이터 처리에 Apache Flink를 어떻게 활용하는지 소개하며 발표를 시작했다. 이어서 Kubernetes 클러스터를 여러 zone으로 나누어 한 번에 일부씩 순차적으로 점검하는 rolling 유지보수 방식과, 그 과정에서 몇 시간에서 며칠씩 실행되는 외부(external) job이 갑자기 끊기지 않도록 보호하는 자체 스케줄러/컨트롤러 설계를 설명했다. Kubernetes custom resource와 leader election, checkpoint를 활용해 job 상태를 추적하고 중단 시 재개할 수 있도록 만든 구조가 핵심 내용이었다. Apache Airflow와 유사한 스케줄링 개념도 함께 언급되었다. ...

August 28, 2026 · 3 min · 553 words · jeonck

2026-08-28 AI 에이전트의 State와 Memory: MongoDB로 구현하기

📋 밋업 한눈에 보기 이번 밋업은 CNCF 및 스폰서 소개, 참석자 자기소개 등 네트워킹 시간으로 시작한 뒤, MongoDB 발표자가 AI 에이전트를 만들 때 필요한 state와 memory 개념을 설명하는 발표로 이어졌다. 발표자는 LLM 자체는 상태가 없다는 점을 지적하며, 안정적인 에이전트를 만들려면 작업 상태(state)와 사용자 관련 정보(memory)를 구분해서 저장해야 한다고 강조했다. 이어서 동시성 문제 해결을 위한 findOneAndUpdate, hybrid search를 위한 rank fusion, 그리고 mongod/mongot 프로세스 아키텍처 등 MongoDB의 구체적인 기능들을 예시와 함께 소개했다. ...

August 28, 2026 · 4 min · 722 words · jeonck

2026-08-27 AIOps: AI 에이전트로 운영을 자동화하기

오늘의 기술 토픽 AI Agents for Operations (AIOps) AIOps는 AI 에이전트를 시스템 운영(Operations)에 도입해 장애 탐지, 원인 분석, 대응까지 자동화하려는 접근입니다. 기존 모니터링/알림 체계에 LLM 기반 에이전트를 결합해 사람이 하던 반복적인 운영 판단을 에이전트가 대신 수행하도록 만드는 것이 핵심 아이디어입니다. Kubernetes 생태계에서는 kagent 같은 프로젝트가 이런 흐름을 구체화하고 있으며, Prometheus·GitOps 도구와 연계해 관측(observability)부터 조치(remediation)까지 자동화 파이프라인을 구성하려는 시도가 늘고 있습니다. 🔑 핵심 요점 AIOps는 AI 에이전트가 장애 탐지, 원인 분석, 대응 조치까지 수행하도록 운영 워크플로우를 자동화하는 개념입니다. 기존 모니터링 스택(Prometheus, 로그 시스템)이 에이전트의 ‘눈’ 역할을 하고, LLM이 상황을 해석해 다음 행동을 결정합니다. kagent처럼 Kubernetes 네이티브 환경에서 동작하는 AI 에이전트 프레임워크가 실제 운영 자동화 도구로 주목받고 있습니다. GitOps 도구와 연계하면 에이전트가 제안한 변경 사항을 사람이 검토 후 승인하는 안전한 자동화 루프를 만들 수 있습니다. AIOps는 완전 자율 운영보다는, 사람의 판단을 보조하는 ‘반자율(semi-autonomous)’ 단계부터 도입하는 것이 현실적인 시작점입니다. 🛠 핵심 기술 쉽게 이해하기 AIOps (AI Agents for Operations) AIOps는 인공지능, 특히 LLM 기반 에이전트를 활용해 IT 시스템 운영 업무(모니터링, 장애 진단, 대응)를 자동화하려는 접근 방식입니다. 사람이 로그와 지표를 보고 판단하던 과정을 에이전트가 대신 수행하도록 만드는 것이 목표입니다. ...

August 27, 2026 · 3 min · 582 words · jeonck

2026-08-26 Zero Trust Networking으로 가는 클라우드 네이티브 보안

오늘의 기술 토픽 Zero Trust Networking 이번 브리핑은 별도 밋업 발표 없이 Zero Trust Networking을 주제로 정리한 내용이다. Zero Trust는 네트워크 내부와 외부를 신뢰하지 않고 모든 요청을 검증하는 보안 모델로, 클라우드 네이티브 환경에서 Cilium, Istio 같은 서비스 메시/네트워킹 기술과 함께 논의된다. 최근 생태계는 IP 기반 방화벽 대신 신원(Identity) 기반 인증과 세밀한 정책 제어로 이동하고 있다. 이 브리핑은 관련 기술을 소개하고 학습을 시작할 수 있는 방향을 제시한다. 🔑 핵심 요점 Zero Trust는 ‘아무도 기본적으로 신뢰하지 않는다’는 원칙으로 모든 트래픽을 검증하는 보안 모델이다. 전통적인 경계(perimeter) 기반 보안은 클라우드 네이티브 환경에서 한계가 있다. Cilium, Istio 같은 서비스 메시/eBPF 기술이 Zero Trust 구현의 핵심 도구로 쓰인다. mTLS와 워크로드 identity 기반 인증이 Zero Trust Networking의 기본 요소다. 정책은 코드로 관리되며 세밀한 접근 제어(RBAC, NetworkPolicy 등)와 결합된다. Kubernetes 환경에서는 Kyverno 같은 정책 엔진으로 Zero Trust 원칙을 강제할 수 있다. 🛠 핵심 기술 쉽게 이해하기 Zero Trust Networking 네트워크 안에 있다는 이유만으로 신뢰하지 않고, 모든 사용자와 서비스의 요청을 매번 검증하는 보안 아키텍처 개념이다. ‘신뢰하지 말고 항상 검증하라(Never trust, always verify)‘는 원칙을 따른다. ...

August 26, 2026 · 3 min · 536 words · jeonck

2026-08-26 AWS Agentic AI 시스템, POC에서 프로덕션까지

📋 밋업 한눈에 보기 이 웨비나는 AWS 기반 agentic AI 시스템을 데모/POC 수준에서 프로덕션 등급으로 끌어올리는 방법을 다뤘다. 발표자는 deterministic 오케스트레이션(Step Functions)과 이벤트 기반 오케스트레이션(EventBridge, SQS, Lambda)을 비교하고, 신뢰성·관측성·보안·비용·거버넌스라는 프로덕션 핵심 축을 차례로 설명했다. 마지막으로 고객 지원 triage agent 예시와 단계별 배포 전략(phase 1~4)으로 이론을 구체화했고, Q&A에서는 멀티 에이전트 사용 시점, 비결정적 시스템 테스트, 프롬프트 인젝션 방어, 관리형 vs 커스텀 구축 등 실무 질문에 답했다. 🔑 핵심 요점 데모/POC 수준 agentic 시스템과 프로덕션 수준 시스템은 완전히 다르며, 신뢰성·관측성·거버넌스·보안이 추가로 필요하다. 흐름이 고정돼 있으면 Step Functions 같은 deterministic 방식을, 판단이 필요하면 이벤트 기반 agent 방식을 쓰되, 실무에서는 이 둘을 섞은 하이브리드가 가장 성숙한 형태다. Agent는 stochastic(같은 질문에도 다른 답)하고 autonomous하며 distributed하므로 idempotency, fallback, timeout/circuit breaker 설계가 필수다. 관측성은 tracing(X-Ray)과 evaluation(LLM-as-judge 등) 두 축으로 이뤄지며, 토큰 비용도 관측 대상이다 — 너무 싸도 이상 신호일 수 있다. 보안은 defense in depth로 접근해야 하며 guardrails, agent별 identity(least privilege), bounded autonomy, audit/traceability를 층층이 쌓아야 한다. 비용은 요청 수가 아니라 토큰 소비(추론 루프 등)에 좌우되므로 iteration cap, 모델 사이즈 조정, prompt caching, agent/tenant별 비용 귀속이 필요하다. POC에서 프로덕션으로 갈 때는 단일 agent 검증 → tracing/guardrails 추가 → multi-agent 확장 → 운영/거버넌스 성숙 순으로 단계적(phase)으로 확장해야 하며, 프롬프트와 tool 정의도 코드처럼 버전 관리하고 evaluation gate를 거쳐 점진적으로 배포해야 한다. 🛠 핵심 기술 쉽게 이해하기 AWS Step Functions 정해진 순서대로 실행되는 workflow(상태 머신)를 관리형으로 구성할 수 있는 AWS 서비스로, 여러 단계 호출, 재시도, 사람의 승인 대기 등을 코드가 아니라 정의된 flow로 처리한다. ...

August 26, 2026 · 6 min · 1098 words · jeonck

2026-08-26 AWS Bedrock 기반 Agentic AI 아키텍처 설계

📋 밋업 한눈에 보기 이번 세션은 AWS Bedrock을 중심으로 엔터프라이즈급 agentic AI 시스템을 어떻게 설계하는지를 다뤘다. 발표자는 시스템을 experience layer, orchestration layer, agent runtime layer, tools/memory/data layer의 4개 계층과 IAM·CloudWatch 같은 crosscutting 서비스로 나누어 설명했다. Bedrock의 supervisor-collaborator 멀티에이전트 구조, Lambda를 통한 tool 실행, 단기·장기 메모리 관리, least privilege 기반 보안 모델이 핵심 주제였다. 전체적으로 stateless, 서버리스 우선, 최소 권한 원칙에 기반한 프로덕션급 agentic 아키텍처 구축 가이드를 제시했다. 🔑 핵심 요점 Agentic AI 시스템은 experience, orchestration, agent runtime, tools/memory/data의 4개 계층 구조로 설계하는 것이 권장된다. Amazon Bedrock의 supervisor agent는 복잡한 작업을 여러 specialist collaborator agent로 분해하고 결과를 다시 하나의 응답으로 통합한다. Lambda 함수는 stateless하고 최대 15분만 실행되므로, 세션을 넘어 유지해야 할 데이터는 DynamoDB 같은 외부 저장소에 보관해야 한다. 메모리는 단기(세션 내 대화)와 장기(세션 간 semantic search로 검색되는 지식)로 나뉘며, 각각 관리 방식이 다르다. 보안은 least privilege 원칙을 기반으로 하며, 각 tool과 agent에게 필요한 최소 권한만 부여해야 blast radius를 줄일 수 있다. MCP(Model Context Protocol)는 agent와 tool 간 표준 통신 프로토콜로, 이를 통해 다양한 tool을 plug-and-play로 연결할 수 있다. 모든 tool 호출은 로깅되어 누가 어떤 행동을 대신 수행했는지 추적 가능해야 하며, 이는 침해 발생 시 포렌식 분석에 필수적이다. 🛠 핵심 기술 쉽게 이해하기 Amazon Bedrock Bedrock은 여러 파운데이션 모델(FM)을 한곳에 모아 선택해서 쓸 수 있게 해주는 AWS 서비스다. AWS 자체 모델뿐 아니라 서드파티 모델, 직접 만든 모델도 포함할 수 있다. ...

August 26, 2026 · 4 min · 811 words · jeonck

2026-08-25 Crossplane으로 시작하는 Infrastructure as Code

오늘의 기술 토픽 Infrastructure as Code with Crossplane 이번 브리핑은 별도 밋업 발표 없이, Crossplane을 중심으로 한 Kubernetes 기반 Infrastructure as Code(IaC) 흐름을 정리한 자료입니다. Crossplane은 Kubernetes API를 확장해 클라우드 리소스를 선언적으로 관리할 수 있게 해주는 프로젝트로, Terraform 같은 기존 IaC 도구와 비교되며 최근 플랫폼 엔지니어링 생태계에서 주목받고 있습니다. 이 브리핑에서는 Crossplane과 함께 자주 언급되는 연관 기술들을 소개하고, 생태계가 나아가는 방향과 학습을 시작하는 방법을 정리했습니다. 🔑 핵심 요점 Crossplane은 Kubernetes API를 확장해 클라우드 리소스(DB, 네트워크, 스토리지 등)를 Kubernetes 오브젝트처럼 선언적으로 관리한다. Crossplane은 Provider를 통해 AWS, GCP, Azure 등 다양한 클라우드와 SaaS 리소스를 하나의 컨트롤 플레인에서 다룰 수 있게 해준다. Composition 기능을 사용하면 여러 리소스를 조합한 커스텀 API(예: ‘데이터베이스 하나 주세요’)를 팀 내부에 제공할 수 있다. GitOps 도구인 Argo CD와 Crossplane을 함께 쓰면 애플리케이션 배포와 인프라 프로비저닝을 동일한 파이프라인에서 관리할 수 있다. 정책 관리 도구인 Kyverno를 결합하면 Crossplane으로 생성되는 리소스에 대한 거버넌스 규칙을 강제할 수 있다. 이러한 흐름은 개발자에게 셀프서비스 인프라를 제공하는 ‘플랫폼 엔지니어링’ 트렌드와 맞닿아 있다. 🛠 핵심 기술 쉽게 이해하기 Crossplane Crossplane은 Kubernetes API를 확장하여 클라우드 프로바이더의 리소스(가상머신, 데이터베이스, 네트워크 등)를 Kubernetes 커스텀 리소스로 정의하고 관리할 수 있게 해주는 오픈소스 프로젝트입니다. kubectl이나 GitOps 도구로 인프라를 코드처럼 다룰 수 있습니다. ...

August 25, 2026 · 3 min · 598 words · jeonck

2026-08-24 Policy as Code로 시작하는 클라우드 네이티브 거버넌스

오늘의 기술 토픽 Policy as Code 이번 브리핑은 실제 밋업 발표가 아니라 Policy as Code라는 주제를 중심으로 정리한 기술 브리프다. 쿠버네티스 환경에서 정책을 코드로 관리하는 접근 방식과 이를 뒷받침하는 대표 도구들을 함께 살펴본다. Kyverno, OPA/Gatekeeper, Conftest 같은 도구들이 어떻게 정책 검증을 자동화하는지, 그리고 이러한 흐름이 플랫폼 엔지니어링과 어떻게 맞닿아 있는지 정리했다. 초심자도 어떤 도구부터 시작하면 좋을지 감을 잡을 수 있도록 구성했다. 🔑 핵심 요점 Policy as Code는 조직의 규칙과 보안 요구사항을 사람이 수동으로 검토하는 대신 코드로 작성해 자동 검증하는 방식이다. 쿠버네티스 클러스터에서는 Admission Controller를 통해 리소스가 생성되기 전에 정책을 강제할 수 있다. Kyverno는 YAML만으로 정책을 작성할 수 있어 쿠버네티스 사용자에게 진입장벽이 낮은 편이다. OPA(Open Policy Agent)와 Rego 언어는 쿠버네티스뿐 아니라 다양한 시스템에 범용적으로 적용 가능한 정책 엔진이다. CI/CD 파이프라인 단계에서 정책을 미리 검증하는 shift-left 접근이 점점 중요해지고 있다. Policy as Code는 GitOps 워크플로우와 결합될 때 정책 변경 이력 추적과 감사가 쉬워진다는 장점이 있다. 🛠 핵심 기술 쉽게 이해하기 Kyverno 쿠버네티스 전용으로 설계된 정책 엔진으로, 별도의 새로운 언어를 배우지 않고 익숙한 YAML 형식으로 정책을 작성할 수 있다. 리소스 검증, 변형(mutation), 생성(generation) 등 다양한 기능을 지원한다. ...

August 24, 2026 · 3 min · 538 words · jeonck