Tech-Brief

오늘의 기술 토픽 Platform Engineering 이번 브리프는 최근 클라우드 네이티브 생태계에서 핵심 화두로 떠오른 Platform Engineering을 중심으로 정리한 내용이다. 개발자가 인프라 세부사항을 몰라도 셀프서비스로 필요한 리소스를 프로비저닝할 수 있게 만드는 것이 핵심 목표이며, 이를 위해 Internal Developer Platform(IDP), GitOps, Kubernetes 기반 추상화 도구들이 함께 언급된다. 실제 밋업 발표는 없었으나, 관련 기술들을 초심자 관점에서 소개하고 학습 방향을 제시한다. 🔑 핵심 요점 Platform Engineering은 개발자 생산성을 높이기 위해 인프라를 ‘제품’처럼 설계하고 운영하는 접근 방식이다. 핵심 목표는 개발자가 티켓을 넣지 않고도 셀프서비스로 환경과 리소스를 얻을 수 있게 하는 것이다. Backstage 같은 IDP 툴은 서비스 카탈로그와 셀프서비스 포털 역할을 한다. Kubernetes는 플랫폼 엔지니어링의 사실상 표준 실행 기반으로 자리잡았다. Crossplane 같은 도구는 클라우드 리소스를 Kubernetes API로 추상화해 셀프서비스 프로비저닝을 가능하게 한다. GitOps는 플랫폼 변경 사항을 코드로 관리하고 자동 배포하는 표준 운영 방식으로 자리잡고 있다. 🛠 핵심 기술 쉽게 이해하기 Platform Engineering Platform Engineering은 조직 내부의 개발자들이 애플리케이션을 더 빠르고 안전하게 배포할 수 있도록 인프라와 툴체인을 ‘내부 제품’처럼 설계하고 운영하는 분야다. 단순히 인프라를 관리하는 것을 넘어, 개발자 경험(Developer Experience)을 최우선으로 고려한다. ...

오늘의 기술 토픽 Zero Trust Networking 이번 밋업에서는 별도의 발표 녹취록이 없어, Zero Trust Networking을 중심으로 클라우드 네이티브 환경에서 이 개념이 왜 중요한지, 그리고 이를 구현하는 데 함께 쓰이는 기술들을 정리했다. Zero Trust는 네트워크 위치가 아니라 신원(identity)을 기준으로 모든 통신을 검증하는 보안 모델이다. Cilium, Istio, SPIFFE/SPIRE 같은 도구들이 이 모델을 실제 클러스터 환경에 구현하는 데 사용된다. 🔑 핵심 요점 Zero Trust Networking은 ‘내부 네트워크는 안전하다’는 전제를 버리고 모든 요청을 매번 인증·인가하는 보안 모델이다. 전통적인 perimeter 기반 방화벽 대신, 서비스나 워크로드 단위의 신원(identity)을 기준으로 접근을 통제한다. Kubernetes 환경에서는 서비스 메시나 eBPF 기반 네트워킹 도구를 통해 Zero Trust를 실현하는 경우가 많다. mTLS(mutual TLS)는 Zero Trust 구현의 핵심 요소로, 통신 양쪽 모두의 신원을 암호학적으로 검증한다. SPIFFE/SPIRE 같은 워크로드 신원 표준은 여러 클러스터·클라우드에 걸쳐 일관된 identity 체계를 제공한다. 인증서 발급과 갱신을 자동화하는 것이 Zero Trust 운영의 실질적인 부담을 줄이는 핵심이다. 🛠 핵심 기술 쉽게 이해하기 Zero Trust Networking 네트워크 안에 있다는 이유만으로 신뢰하지 않고, 모든 접근 요청을 매번 검증하는 보안 아키텍처 원칙이다. 사용자, 서비스, 디바이스 모두 신원을 증명해야 통신이 허용된다. ...

오늘의 기술 토픽 Infrastructure as Code with Crossplane 이번 브리프는 Kubernetes 위에서 클라우드 인프라를 선언적으로 관리하는 Crossplane을 중심으로 정리했다. Terraform과 달리 Crossplane은 클라우드 리소스를 Kubernetes API의 커스텀 리소스(CRD)로 다루어, 애플리케이션과 인프라를 동일한 API 서버와 GitOps 워크플로우로 관리할 수 있게 해준다. Argo CD 같은 GitOps 도구와 결합하면 인프라 변경도 Git 커밋 하나로 배포·감사할 수 있어, 플랫폼 엔지니어링 흐름과 자연스럽게 맞물린다. 초보자는 먼저 로컬 클러스터에서 Crossplane과 provider를 설치해보며 개념을 익히는 것이 좋다. ...

오늘의 기술 토픽 Policy as Code Policy as Code는 조직의 보안, 컴플라이언스, 운영 규칙을 코드로 작성해 시스템에 자동으로 강제하는 접근 방식이다. Kubernetes 생태계에서는 Kyverno와 Open Policy Agent(OPA)/Gatekeeper가 대표적인 구현체로 자리잡았으며, admission controller를 통해 리소스가 클러스터에 배포되기 전에 정책 위반 여부를 검사한다. CI/CD 파이프라인에 정책 검사를 포함시키는 shift-left 흐름과 맞물려, 배포 이후가 아니라 배포 이전 단계에서 문제를 걸러내는 방향으로 발전하고 있다. GitOps 도구인 Argo CD, 인프라 프로비저닝 도구인 Crossplane과 결합해 선언적 인프라 전체에 정책을 일관되게 적용하려는 시도도 늘고 있다. ...

오늘의 기술 토픽 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)는 리눅스 커널 안에서 안전하게 커스텀 프로그램을 실행할 수 있게 해주는 기술입니다. 커널을 재컴파일하거나 별도 모듈을 로드하지 않고도 패킷 처리, 시스템 콜 추적 같은 저수준 동작에 개입할 수 있습니다. ...

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

오늘의 기술 토픽 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를 만들 수 있다. ...

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

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

오늘의 기술 토픽 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은 개발팀이 애플리케이션을 더 쉽고 빠르게 만들고 배포할 수 있도록, 별도의 플랫폼팀이 셀프서비스 도구와 표준 워크플로우를 설계하는 조직적/기술적 접근입니다. 단순히 인프라를 자동화하는 것을 넘어, 플랫폼 자체를 하나의 내부 제품처럼 관리한다는 점이 특징입니다. ...