2026-08-03 eBPF 기반 네트워킹 기술 브리프

오늘의 기술 토픽 eBPF Networking 이 글은 특정 밋업 발표 대신, 최근 클라우드 네이티브 생태계에서 주목받고 있는 eBPF 네트워킹 기술을 정리한 브리프입니다. eBPF는 커널을 재컴파일하거나 커널 모듈을 추가하지 않고도 커널 내부에서 코드를 안전하게 실행할 수 있게 해주는 기술로, 네트워킹, 보안, 관측성 영역에서 빠르게 표준으로 자리잡고 있습니다. Cilium과 Hubble 같은 프로젝트들이 이 기술을 기반으로 쿠버네티스 네트워킹과 관측성을 재정의하고 있으며, 사이드카 없는 서비스 메시로의 전환도 활발히 논의되고 있습니다. 🔑 핵심 요점 eBPF는 커널 모듈 없이 커널 내부에서 샌드박스된 코드를 실행할 수 있게 해주는 리눅스 커널 기술이다. 쿠버네티스 네트워킹에서 iptables 기반 방식의 성능 한계를 eBPF가 대체하고 있다. Cilium은 eBPF를 활용해 네트워킹, 로드밸런싱, 네트워크 정책을 커널 레벨에서 처리하는 CNI다. Hubble은 eBPF 데이터를 기반으로 클러스터 트래픽을 실시간으로 시각화하는 관측성 도구다. eBPF 기반 사이드카 없는 서비스 메시가 기존 Istio류 사이드카 모델의 대안으로 떠오르고 있다. eBPF는 네트워킹뿐 아니라 보안(Falco, Tetragon)과 성능 프로파일링 영역까지 활용 범위가 넓어지고 있다. 🛠 핵심 기술 쉽게 이해하기 eBPF eBPF(extended Berkeley Packet Filter)는 리눅스 커널 안에서 안전하게 커스텀 프로그램을 실행할 수 있게 해주는 기술입니다. 커널을 재컴파일하거나 별도 모듈을 로드하지 않고도 패킷 처리, 시스템 콜 추적 같은 저수준 동작에 개입할 수 있습니다. ...

August 3, 2026 · 3 min · 533 words · jeonck

2026-08-02 Service Mesh 입문: 개념부터 생태계 흐름까지

오늘의 기술 토픽 Service Mesh 이번 자료는 실제 밋업 발표가 아니라 Service Mesh라는 주제를 중심으로 정리한 기술 브리프입니다. 마이크로서비스 환경에서 서비스 간 통신을 어떻게 안전하고 관측 가능하게 관리할지에 초점을 맞추고, Istio, Envoy, Cilium 등 관련 기술이 어떤 역할을 하는지 정리했습니다. 최근에는 사이드카 방식의 무거움을 줄이려는 sidecar-less, eBPF 기반 접근으로 생태계가 이동하고 있습니다. 실습 진입 장벽을 낮추기 위한 학습 경로와 공식 문서 링크도 함께 제공합니다. 🔑 핵심 요점 Service Mesh는 마이크로서비스 간 통신을 애플리케이션 코드 밖에서 제어하는 인프라 계층이다. 트래픽 라우팅, mTLS 암호화, 재시도/서킷브레이커, 관측성(observability)을 코드 수정 없이 제공하는 것이 핵심 가치다. Istio는 Envoy를 데이터 플레인으로 사용하는 대표적인 Service Mesh 구현체다. 전통적인 사이드카 프록시 방식은 리소스 오버헤드와 운영 복잡도라는 단점이 있다. Cilium 같은 eBPF 기반 기술은 사이드카 없이 커널 레벨에서 네트워킹과 보안을 처리하는 방향으로 발전하고 있다. Service Mesh 도입은 클러스터 규모와 팀의 운영 역량을 고려해 단계적으로 접근하는 것이 바람직하다. 🛠 핵심 기술 쉽게 이해하기 Service Mesh 여러 개의 작은 서비스(마이크로서비스)들이 서로 통신할 때 필요한 기능들, 예를 들어 트래픽 라우팅, 암호화, 재시도, 모니터링 등을 애플리케이션 코드와 분리해서 처리해주는 인프라 계층입니다. 보통 각 서비스 옆에 프록시(사이드카)를 붙여서 모든 네트워크 트래픽이 이 프록시를 거치도록 만듭니다. ...

August 2, 2026 · 3 min · 638 words · jeonck

2026-08-01 Kubernetes Operators와 CRD로 이해하는 확장형 클러스터 운영

오늘의 기술 토픽 Kubernetes Operators & CRDs 이번 글은 별도의 밋업 발표 없이 Kubernetes Operators와 CRD(Custom Resource Definition)를 중심으로 정리한 기술 브리프입니다. Kubernetes가 왜 CRD와 Operator 패턴을 통해 API를 확장 가능하게 설계했는지, 그리고 이 패턴이 어떻게 인프라 자동화 생태계 전반으로 퍼져나갔는지를 다룹니다. Kubebuilder, Crossplane 같은 관련 도구들이 이 패턴을 어떻게 구체화하는지도 함께 살펴봅니다. 🔑 핵심 요점 CRD는 Kubernetes API에 사용자 정의 리소스 타입을 추가하는 확장 메커니즘이다. Operator는 CRD로 정의한 커스텀 리소스를 지속적으로 관찰하고 원하는 상태(desired state)로 수렴시키는 컨트롤러다. Operator 패턴 덕분에 데이터베이스, 메시지 큐 같은 복잡한 애플리케이션의 운영 지식을 코드로 캡슐화할 수 있다. Kubebuilder와 Operator SDK는 Go 기반으로 Operator를 빠르게 만들 수 있게 해주는 프레임워크다. Crossplane은 Operator 패턴을 클라우드 인프라 프로비저닝까지 확장한 사례다. reconcile loop 개념을 이해하면 Kubernetes 생태계의 대부분의 컨트롤러 동작 원리를 파악할 수 있다. 🛠 핵심 기술 쉽게 이해하기 Kubernetes Operators & CRDs CRD는 Kubernetes API에 새로운 리소스 종류를 등록하는 방법이고, Operator는 이 커스텀 리소스를 감시하며 실제 상태를 원하는 상태로 맞춰주는 컨트롤러 프로그램이다. 둘을 합치면 Kubernetes 자체의 기본 오브젝트(Pod, Deployment 등)처럼 동작하는 새로운 도메인 전용 API를 만들 수 있다. ...

August 1, 2026 · 3 min · 555 words · jeonck

2026-07-31 Internal Developer Platform(IDP) 입문 브리프

오늘의 기술 토픽 Internal Developer Platform (IDP) Internal Developer Platform(IDP)은 개발자가 인프라 세부사항을 몰라도 셀프서비스로 애플리케이션을 배포하고 운영할 수 있도록 플랫폼 엔지니어링 팀이 제공하는 통합 도구 모음입니다. 쿠버네티스와 클라우드 인프라가 복잡해지면서 개발자의 인지 부하를 줄이고 배포 속도를 높이기 위한 목적으로 등장했습니다. Backstage 같은 개발자 포털, Crossplane 같은 인프라 추상화 도구, Argo CD 같은 GitOps 배포 도구가 IDP의 핵심 구성 요소로 자주 함께 언급됩니다. 최근에는 플랫폼을 하나의 내부 ‘제품’으로 취급하며 개발자 경험(DX)을 개선하는 방향으로 발전하고 있습니다. ...

July 31, 2026 · 3 min · 570 words · jeonck

2026-07-30 GitOps로 시작하는 선언적 배포 관리

오늘의 기술 토픽 GitOps 이번 브리핑은 별도의 밋업 발표 없이 GitOps라는 주제를 중심으로 관련 생태계를 정리한 내용이다. GitOps는 Git 저장소를 단일 진실 공급원(Single Source of Truth)으로 삼아 인프라와 애플리케이션 배포 상태를 선언적으로 관리하는 방법론이다. Argo CD, Flux CD 같은 컨트롤러가 Git의 상태와 실제 클러스터 상태를 지속적으로 동기화하며, 이 흐름 위에서 Kustomize, Helm 같은 매니페스트 관리 도구가 함께 쓰인다. 최근 클라우드 네이티브 커뮤니티는 이를 플랫폼 엔지니어링과 셀프서비스 배포의 기반 기술로 확장하고 있다. ...

July 30, 2026 · 3 min · 590 words · jeonck

2026-07-29 Platform Engineering 입문 브리프

오늘의 기술 토픽 Platform Engineering 이번 자료는 실제 밋업 발표 대신, 최근 개발자 커뮤니티에서 화두인 Platform Engineering을 중심으로 정리한 압축 브리프입니다. Platform Engineering은 개발자가 인프라나 배포 과정을 직접 신경 쓰지 않고도 빠르게 서비스를 만들 수 있도록, 셀프서비스 플랫폼을 구축하는 접근 방식을 말합니다. Backstage, Crossplane, Kubernetes 같은 도구들이 이 플랫폼을 구성하는 대표적인 조각으로 함께 다뤄집니다. 전체 흐름은 ‘플랫폼을 하나의 제품처럼 만들어 내부 개발자에게 제공한다’는 방향으로 수렴합니다. 🔑 핵심 요점 Platform Engineering은 개발자 경험(DevEx)을 개선하기 위해 내부 플랫폼을 하나의 제품처럼 설계하고 운영하는 접근이다. 핵심 목표는 개발자가 인프라 복잡도를 직접 다루지 않고도 셀프서비스로 배포/운영할 수 있게 만드는 것이다. Backstage 같은 개발자 포털은 여러 도구와 문서를 한곳에 모아 플랫폼 사용성을 높이는 역할을 한다. Crossplane은 클라우드 리소스를 Kubernetes API로 선언적으로 관리해 플랫폼 자동화의 기반이 된다. Kubernetes는 대부분의 Platform Engineering 사례에서 표준 실행 환경으로 자리잡고 있다. 골든 패스(golden path)를 제공해 팀마다 다른 방식으로 인프라를 다루는 혼란을 줄이는 것이 중요한 흐름이다. 🛠 핵심 기술 쉽게 이해하기 Platform Engineering Platform Engineering은 개발팀이 애플리케이션을 더 쉽고 빠르게 만들고 배포할 수 있도록, 별도의 플랫폼팀이 셀프서비스 도구와 표준 워크플로우를 설계하는 조직적/기술적 접근입니다. 단순히 인프라를 자동화하는 것을 넘어, 플랫폼 자체를 하나의 내부 제품처럼 관리한다는 점이 특징입니다. ...

July 29, 2026 · 3 min · 610 words · jeonck

2026-07-28 AIOps: AI 에이전트로 운영을 자동화하는 흐름

오늘의 기술 토픽 AI Agents for Operations (AIOps) AIOps(AI Agents for Operations)는 장애 탐지, 원인 분석, 조치 실행 같은 운영 업무를 LLM 기반 에이전트가 사람과 함께 수행하도록 만드는 접근이다. 기존 모니터링·알림 체계가 사람에게 신호만 전달했다면, AIOps는 관측 데이터를 바탕으로 에이전트가 직접 진단하고 제안하거나 승인 하에 조치까지 실행하는 것을 목표로 한다. Kubernetes 생태계에서는 kagent 같은 프로젝트가 이 흐름을 클러스터 운영에 적용하는 대표적인 시도로 꼽힌다. 이 브리프는 AIOps의 개념과 관련 기술, 그리고 학습을 시작하는 방법을 정리한다. ...

July 28, 2026 · 3 min · 564 words · jeonck

2026-07-27 Zero Trust Networking 입문 브리프

오늘의 기술 토픽 Zero Trust Networking 이 브리프는 별도의 밋업 발표 없이 Zero Trust Networking이라는 주제를 중심으로 관련 생태계를 정리한 자료다. Zero Trust는 네트워크 위치나 IP 대역을 신뢰의 근거로 삼지 않고, 모든 요청을 매번 검증하는 보안 모델을 말한다. Kubernetes 환경에서는 Cilium, Istio, SPIFFE/SPIRE 같은 도구들이 이 모델을 실제로 구현하는 데 쓰인다. 이 글은 각 도구가 Zero Trust 구현에서 맡는 역할과, 이 방향으로 생태계가 어떻게 움직이고 있는지를 초심자 눈높이에서 설명한다. 🔑 핵심 요점 Zero Trust Networking은 ‘내부망이니까 안전하다’는 가정을 버리고 모든 트래픽을 매번 인증·인가하는 보안 원칙이다. Kubernetes 환경에서는 서비스 간 통신에 mTLS를 강제하는 것이 Zero Trust 구현의 핵심 출발점이다. Cilium은 eBPF 기반으로 네트워크 계층에서 아이덴티티 기반 정책과 암호화를 적용할 수 있게 해준다. Istio 같은 서비스 메시는 애플리케이션 코드를 건드리지 않고도 서비스 간 mTLS와 세밀한 접근 정책을 적용한다. SPIFFE/SPIRE는 워크로드에 고유한 아이덴티티(SVID)를 부여해 ‘이 서비스가 진짜 이 서비스인지’를 증명하는 표준을 제공한다. Zero Trust는 특정 제품이 아니라 여러 도구를 조합해 점진적으로 도달하는 아키텍처 방향에 가깝다. 🛠 핵심 기술 쉽게 이해하기 Zero Trust Networking 네트워크 안이든 밖이든 모든 요청을 잠재적으로 신뢰할 수 없다고 가정하고, 매 요청마다 신원 확인과 권한 검증을 거치게 하는 보안 아키텍처 원칙이다. ...

July 27, 2026 · 3 min · 583 words · jeonck

2026-07-26 Crossplane으로 시작하는 Infrastructure as Code

오늘의 기술 토픽 Infrastructure as Code with Crossplane 이번 글에서는 실제 밋업 발표 대신, Crossplane을 중심으로 한 Infrastructure as Code(IaC) 생태계를 정리한다. Crossplane은 Kubernetes API를 확장해 클라우드 리소스를 선언적으로 관리할 수 있게 해주는 도구로, Terraform과 같은 전통적 IaC 도구와 비교되며 최근 플랫폼 엔지니어링 진영에서 주목받고 있다. Crossplane과 함께 자주 언급되는 Argo CD, Terraform, Kubernetes Operator 패턴을 함께 살펴보고, 이 생태계가 어디로 향하고 있는지 정리한다. 🔑 핵심 요점 Crossplane은 Kubernetes Custom Resource와 Controller 패턴을 이용해 클라우드 인프라를 코드로 관리하는 오픈소스 프로젝트다. 기존 Terraform이 CLI와 상태 파일 기반이라면, Crossplane은 Kubernetes API 서버를 통해 리소스를 선언적으로 관리한다는 차이가 있다. Crossplane의 Composition 기능을 사용하면 여러 클라우드 리소스를 하나의 커스텀 API로 추상화해 팀 내부에 제공할 수 있다. Argo CD와 결합하면 GitOps 방식으로 인프라 변경 사항을 자동 배포할 수 있다. 플랫폼 엔지니어링 트렌드에서 Crossplane은 ‘내부 개발자 플랫폼(IDP)‘을 만드는 핵심 빌딩 블록으로 자리잡고 있다. 처음 시작할 때는 Provider 설치와 간단한 Managed Resource 생성부터 연습하는 것이 좋다. 🛠 핵심 기술 쉽게 이해하기 Crossplane Crossplane은 Kubernetes API를 확장하여 AWS, GCP, Azure 같은 클라우드 리소스를 Kubernetes 커스텀 리소스처럼 선언적으로 정의하고 관리할 수 있게 해주는 오픈소스 프로젝트다. Kubernetes를 다뤄본 사람이라면 익숙한 YAML 매니페스트로 인프라를 표현할 수 있다. ...

July 26, 2026 · 3 min · 568 words · jeonck

2026-07-25 Policy as Code로 시작하는 정책 자동화

오늘의 기술 토픽 Policy as Code Policy as Code는 인프라와 애플리케이션에 적용할 규칙을 코드로 작성해 버전 관리하고 자동으로 검증하는 접근 방식입니다. Kubernetes 생태계에서는 Open Policy Agent(OPA)와 Kyverno 같은 도구를 통해 리소스가 클러스터에 배포되기 전에 보안·컴플라이언스 규칙을 자동으로 검사하는 형태로 널리 쓰이고 있습니다. 수동 코드 리뷰나 문서화된 가이드라인에 의존하던 방식에서 벗어나, 정책 자체를 테스트 가능하고 재사용 가능한 코드로 관리하는 흐름으로 이동하고 있습니다. 🔑 핵심 요점 Policy as Code는 조직의 규칙(보안, 비용, 네이밍 컨벤션 등)을 코드로 작성해 자동 검증하는 방법론입니다. Kubernetes에서는 Admission Controller를 통해 리소스가 클러스터에 생성되기 전에 정책을 적용할 수 있습니다. Open Policy Agent(OPA)는 범용 정책 엔진이며, Rego라는 전용 언어로 정책을 작성합니다. Kyverno는 YAML 기반으로 정책을 작성할 수 있어 Kubernetes 사용자에게 진입장벽이 낮은 대안입니다. 정책을 코드로 관리하면 Git을 통한 버전 관리, 리뷰, CI 테스트가 가능해집니다. GitOps 파이프라인과 결합하면 배포 이전 단계에서부터 정책 위반을 걸러낼 수 있습니다. 🛠 핵심 기술 쉽게 이해하기 Policy as Code 조직이 지켜야 할 규칙(예: ‘모든 컨테이너는 root로 실행 금지’, ‘퍼블릭 S3 버킷 금지’)을 코드 형태로 작성하고, 이를 자동화된 도구로 검증하는 접근 방식입니다. 규칙이 문서가 아니라 코드이기 때문에 테스트하고 버전을 관리할 수 있습니다. ...

July 25, 2026 · 3 min · 555 words · jeonck