[케클러 인터뷰 시리즈] #3 개발자가 본질에 집중하도록: kt cloud 플랫폼 엔지니어링 이야기

 

 

[ kt cloud 마케팅커뮤니케이션팀]

📋 요약

‘기술이 장르가 되는 곳, kt cloud의 케클러 인터뷰 시리즈’는 케클러들의 목소리를 통해 고객의 다음 문제를 먼저 고민하는 kt cloud의 기술적 지향점과 해법을 전합니다.

세 번째 호에서는 개발자가 본질에 집중할 수 있도록, 인프라와 운영의 복잡성을 줄여가는 김정남 팀장의 Self-Service 기반 플랫폼 엔지니어링 이야기를 소개합니다.

#ktcloud #플랫폼엔지니어링 #DevOps #개발자경험 #인프라자동화

---

kt cloud Platform엔지니어링팀 김정남 팀장이 소개하는 Self-Service 기반 개발 환경 구축 이야기

 

안녕하세요. kt cloud 마케팅커뮤니케이션팀입니다.

 

빠르게 변화하는 클라우드 환경에서 중요한 것은 새로운 서비스를 얼마나 빠르게 개발하고, 안정적으로 배포할 수 있는가입니다. 이를 위해서는 개발자 개인의 역량뿐 아니라, 개발자가 필요한 환경을 빠르게 구성하고 반복적인 준비 과정을 줄일 수 있는 엔지니어링 체계가 함께 뒷받침되어야 합니다.

 

새로운 서비스를 준비할 때, 개발자는 얼마나 많은 시간을 실제 개발이 아닌 ‘준비 과정’에 쓰고 있을까요?

GitHub 리포지토리를 만들고, CI/CD 파이프라인을 구성하고, 권한을 요청하고, 배포 환경이 마련되기를 기다리는 과정은 많은 개발자에게 익숙한 일입니다. 때로는 서비스 로직을 구현하는 시간보다 YAML 파일을 수정하고 환경 설정을 맞추는 데 더 많은 시간이 들기도 합니다.

 

반복적인 환경 설정과 배포 준비를 줄이고, 개발자가 필요한 환경을 스스로 구성할 수 있도록 돕는 것. 이것이 플랫폼 엔지니어링이 주목받는 이유입니다.

 

이번 케클러 인터뷰에서는 kt cloud Platform엔지니어링팀 김정남 팀장을 만나 Self-Service 기반 엔지니어링 체계가 왜 필요한지, 그리고 개발자가 본질적인 개발 업무에 더 집중할 수 있는 환경은 어떻게 만들어지고 있는지 들어보았습니다.

 

💡이야기를 시작하며

김정남 팀장 | kt cloud Platform엔지니어링팀

개발 시스템 아키텍처와 코드 분석을 시작으로 풀스택 및 인프라 운영 서비스 개발, InfraOps 엔지니어까지 다양한 영역을 경험했습니다. 현재 kt cloud에서 Platform엔지니어링팀을 이끌며, 개발자와 운영자가 서비스 본질에 집중할 수 있는 엔지니어링 환경을 만들어가고 있습니다.

Platform엔지니어링팀 소개

인프라와 플랫폼 환경을 표준화 및 자동화해 개발부터 운영까지 전 과정을 효율화하는 조직입니다. 복잡한 환경 설정은 플랫폼이 흡수하고, kt cloud의 개발자와 운영자는 서비스 개발과 운영에만 집중할 수 있도록 Self-Service 기반의 플랫폼을 구축하고 있습니다.

이번 인터뷰의 주인공이 꼽은 ‘이 글이 필요한 분들’

↳ 개발자가 본질적인 개발 업무에 더 집중할 수 있는 Self-Service 개발 환경을 고민하는 기술 리더 ↳ 대규모 인프라 리소스의 표준화·자동화 운영 전략이 궁금한 InfraOps·플랫폼 엔지니어 ↳ DevOps를 넘어 플랫폼 엔지니어링 기반의 조직 혁신을 고민하는 기업 IT 담당자

---

Part 1. 개발자가 개발보다 환경 설정에 시간을 쓰고 있었다

복잡한 개발 환경을 표준화하는 kt cloud Platform Engineering 구조

 

Cloud Native 환경에서는 서비스 수와 배포 빈도가 빠르게 증가합니다. 문제는 서비스가 많아질수록 개발자가 이해하고 다뤄야 할 기반 시스템도 함께 늘어난다는 점입니다.

새로운 서비스를 시작하기 위해서는 GitHub, *Harbor, *ArgoCD, *Kubernetes, *Vault, *CI/CD Pipeline, 권한 체계 등 다양한 시스템을 먼저 파악해야 합니다. 각각은 안정적인 개발과 운영을 위해 꼭 필요한 기술이지만, 개발자 입장에서는 실제 기능을 구현하기 전부터 넘어야 할 진입 장벽이 되기도 합니다.

 

김정남 팀장은 바로 이 지점에서 플랫폼 엔지니어링의 필요성을 발견했습니다.

 

“

가장 먼저 제거하고 싶었던 복잡성은, 개발을 시작하기 전까지 개발자가 알아야 하는 것들이 너무 많다는 점이었습니다.

”

 

그가 지향하는 플랫폼 엔지니어링의 목표는 명확합니다. 개발자가 인프라와 운영 절차를 모두 직접 짊어지는 것이 아니라, 플랫폼이 그 복잡성을 흡수하고 개발자가 본질적인 개발 업무에 더 집중할 수 있도록 엔지니어링 체계를 구축하는 것입니다.

 

이를 위해 kt cloud Platform엔지니어링팀은 표준 아키텍처와 개발 템플릿, CI/CD 파이프라인, 운영 자동화 체계, *CMDB, 운영 포털 등을 단계적으로 구축해 나가고 있습니다.

---

Part 2. “누군가 해줘야 시작되는 개발”에서 “스스로 시작하는 개발”로

Self-Service 기반으로 개발자가 직접 개발 환경을 구성하는 플랫폼 구조

 

기존 개발 환경에서는 새로운 서비스를 만들 때 반복되는 준비 과정이 많았습니다. 개발자는 필요한 환경을 요청하고, 권한 설정과 배포 환경 구성이 끝날 때까지 기다린 뒤에야 본격적인 개발에 착수할 수 있었습니다.

 

Platform엔지니어링팀은 이러한 대기 구조를 “Self-Service 기반 개발 환경”으로 바꾸는 데 집중하고 있습니다.

하지만 Self-Service는 단순히 포털 화면에 기능을 제공하는 것만으로 완성되지 않습니다. 개발자가 필요한 환경을 직접 선택하고 사용할 수 있으려면, 그 전에 아키텍처, 권한, 배포 절차, 운영 기준 등 보이지 않는 영역이 먼저 표준화되어 있어야 합니다.

 

💡개발자가 서비스를 직접 시작하고 운영할 수 있는 Self-Service 구축 단계

1️⃣ 표준 서비스 템플릿 구성 2️⃣ CI/CD 파이프라인 표준화 3️⃣ 인증·권한 체계 정리 4️⃣ 자산 및 구성 정보 통합 5️⃣ *운영 지원 시스템(OSS) 기반 Self-Service 구현

 

Self-Service의 핵심은 개발자가 매번 인프라 설정 방법을 찾아 헤매지 않아도 된다는 데 있습니다. 플랫폼이 미리 검증된 표준 경로를 제공하면, 개발자는 필요한 환경을 직접 선택하고 더 빠르게 서비스를 시작할 수 있습니다.

 

Self-Service가 현장에서 제대로 작동하려면 표준 서비스 템플릿, CI/CD 파이프라인, 인증·권한 체계, 구성 정보 관리, 운영 지원 시스템이 유기적으로 연결되어야 합니다. 개발자는 검증된 표준 절차 안에서 필요한 환경을 직접 선택하고 개발과 배포를 시작할 수 있습니다.

---

Part 3. Sandbox, 개발자가 기다리지 않고 검증하는 공간

Kubernetes와 ArgoCD 기반 개발자 Sandbox 테스트 환경

 

새로운 기능을 검증하고 싶은데 인프라나 배포 환경이 준비될 때까지 기다려본 경험 있으신가요?

실제 개발 현장에서는 로컬 개발 환경과 운영 환경의 차이로 인해, 배포 직전에야 예상하지 못한 오류를 마주하는 경우도 있습니다. 개발자가 빠르게 시도하고 안정적으로 서비스를 준비하기 위해서는 실제 환경에 가까운 조건에서 직접 배포하고 검증할 수 있는 공간이 필요합니다.

 

이를 위해 Platform엔지니어링팀은 개발자용 *Sandbox 환경을 새롭게 제공하고 있습니다.

Sandbox는 사전 검증된 VM 이미지와 운영 환경에 가까운 Kubernetes, ArgoCD 환경을 활용해 개발자가 직접 서비스를 배포하고 테스트할 수 있는 공간입니다.

이 환경에서 kt cloud 개발자들은 필요한 검증을 직접 진행할 수 있습니다.

 

Platform엔지니어링팀은 Sandbox의 의미를 이렇게 설명합니다.

 

“

Sandbox가 해결하려는 문제는 단순 테스트 서버 제공이 아니라,

환경이 준비될 때까지 기다리는 시간과 실제 환경 차이로 인해 발생하는 시행착오를 줄이는 데 있습니다.

”

---

Part 4. 빠른 배포보다 중요한 것, 예측 가능한 배포

CI/CD 파이프라인과 DevSecOps를 통한 안정적인 배포 자동화 과정

 

CI/CD 파이프라인은 흔히 '배포 자동화 도구'라고 이해됩니다. 하지만 김정남 팀장이 바라보는 CI/CD 파이프라인의 역할은 조금 다릅니다.

그에게 CI/CD 파이프라인은 개발자가 배포 과정을 예측하고 신뢰할 수 있도록 만드는 운영 기준에 가깝습니다.

 

개발자는 자신이 작성한 코드가 현재 어느 단계에 있는지, 어떤 검증을 거쳐 운영 환경으로 넘어가는지 확인할 수 있어야 합니다.

이를 위해 김정남 팀장은 배포 환경을 DEV(통합 테스트), QA(기능 검증), STG(최종 검증), PRD(실제 운영) 단계로 구분하고 각 단계의 역할을 명확히 정의했습니다.

 

개발 단계에서는 개발자가 빠른 피드백을 받을 수 있도록 지원하고, 운영 단계로 갈수록 플랫폼이 더 엄격한 품질 기준을 적용하는 방식인데요.

예를 들어 운영 배포 직전 단계에서는 별도의 수작업 절차에 의존하기보다, 파이프라인 안에서 DevSecOps 절차가 기본적으로 수행되도록 구성했습니다.

 

💡DevSecOps란?

DevSecOps는 개발과 운영 과정에 보안 검증을 함께 통합하는 방식입니다. CI/CD 파이프라인 전 단계에서 Secret 탐지, 정적 분석, 이미지 취약점 스캔, 서명 검증 등을 수행해 배포 과정에서 보안 리스크를 최소화하는 데 목적이 있습니다.

 

kt cloud가 지향하는 개발 문화는 단순히 배포 속도를 높이는 것이 아닙니다. 개발자가 배포 과정을 예측할 수 있고, 정해진 기준 안에서 안정적으로 변경을 적용할 수 있는 구조를 만드는 것입니다.

---

Part 5. 좋은 코드를 만드는 좋은 개발 환경

개발·배포·운영 프로세스를 연결하는 kt cloud 운영 지원 시스템(OSS) 구조

 

플랫폼 엔지니어링에서 어려운 것은 기술 구현만이 아닙니다. 김정남 팀장은 오히려 “일하는 방식을 바꾸는 과정”이 더 어려웠다고 말합니다.

 

서비스마다 이미 익숙하게 사용해온 브랜치 전략, 배포 방식, 운영 프로세스가 있습니다. 이를 하나의 표준 흐름으로 맞추는 일은 기술만으로 해결하기 어렵습니다. 개발자들 입장에서도 새로운 플랫폼이나 파이프라인 도입이 편리함보다 ‘또 새롭게 배워야 하는 일’로 느껴질 수도 있습니다.

 

하지만 Platform엔지니어링팀이 추진한 표준화는 모든 방식을 하나로 강제하는 것이 아니었습니다.

각 서비스의 특성을 이해하고, 반복되는 작업과 공통으로 필요한 영역을 찾아 개발자가 매번 같은 고민을 반복하지 않도록 만드는 데 초점을 맞췄습니다.

 

이를 위해 개발·배포·운영 과정에 공통으로 적용되는 기준은 표준화하고, 서비스별 특성이 반영되어야 하는 영역은 유연하게 운영할 수 있도록 구조를 설계했습니다.

결국 플랫폼 엔지니어링은 개발자를 통제하기 위한 구조가 아닙니다. 복잡한 선택지를 줄이고 검증된 개발 방식을 제공해, 개발자가 더 적은 시행착오로 더 나은 결정을 할 수 있도록 돕는 하나의 시스템입니다.

---

Part 6. 개발자가 더 중요한 문제에 집중하는 환경

kt cloud가 그리는 Self-Service 기반 플랫폼 엔지니어링의 미래 방향

 

Self-Service와 자동화가 고도화될수록 개발자가 집중해야 할 영역도 달라집니다.

환경을 어떻게 설정할지, 어떤 절차를 거쳐 배포해야 할지에 대한 고민이 줄어들면 개발자는 고객 경험 개선, 아키텍처 고도화, AI 도입과 같은 더 중요한 과제에 시간을 쓸 수 있습니다.

 

김정남 팀장이 바라보는 플랫폼 엔지니어링의 방향은 분명합니다. 개발자가 기다리거나 헤매지 않고 안전하게 시작할 수 있는 환경을 만들고, 개발·배포·운영 과정이 자연스럽게 이어지도록 만드는 것입니다.

이러한 변화는 내부 개발자 경험에만 머무르지 않습니다. 개발자와 운영자가 더 빠르고 안정적으로 일할 수 있는 환경은 결국 kt cloud가 제공하는 클라우드 서비스의 품질과 속도로 이어집니다.

 

훌륭한 개발 방식과 안정적인 운영 체계가 개인의 역량에만 의존하지 않고, 조직의 일하는 방식으로 자리 잡는 것.

kt cloud Platform엔지니어링팀은 개발자가 더 쉽게 시작하고 안정적으로 운영할 수 있는 환경을 만들어가고 있습니다.

 

 

 

---

📚 관련 용어 설명

· 플랫폼 엔지니어링(Platform Engineering): 개발자가 인프라나 운영의 복잡성에 얽매이지 않고 애플리케이션 개발에만 집중할 수 있도록, 도구와 프로세스를 통합해 '셀프 서비스(Self-Service)' 기반의 내부 개발자 플랫폼을 구축하고 제공하는 기술적 접근 방식입니다. ·  Harbor: 컨테이너 이미지를 저장·관리하고 보안 검증 기능을 제공하는 오픈소스 이미지 저장소입니다. ·  ArgoCD: Git에 저장된 설정 정보를 기반으로 Kubernetes 환경의 애플리케이션 배포와 변경 관리를 자동화하는 도구입니다. ·  Kubernetes(쿠버네티스): 컨테이너 기반 애플리케이션의 배포, 확장, 운영을 자동화하는 오픈소스 플랫폼입니다. ·  Vault: 애플리케이션에서 사용하는 비밀번호, 인증키 등 중요 정보를 안전하게 관리하는 보안 도구입니다. ·  CI/CD(Continuous Integration / Continuous Deployment): 지속적 통합(CI)과 지속적 배포(CD)를 의미합니다. 개발자가 작성한 코드를 자동으로 빌드, 테스트하고 운영 환경까지 배포하는 과정을 자동화한 파이프라인으로, 배포의 속도와 안정성을 동시에 높여줍니다. ·  CMDB(Configuration Management Database, 구성 관리 데이터베이스): IT 인프라 환경을 구성하는 모든 자산(서버, 네트워크, 소프트웨어 등)의 구성 정보와 그들 간의 관계를 한곳에 저장하고 통합 관리하는 데이터베이스입니다. ·  OSS(Operation Support System, 운영 지원 시스템): 인프라와 서비스를 관리하고 제어하기 위한 시스템입니다. kt cloud에서는 이를 개발부터 배포, 운영까지 하나의 끊김 없는 흐름으로 연결하여, 개발자와 운영자가 서비스 상태와 변경 이력을 투명하게 관리할 수 있는 기반으로 활용합니다. ·  샌드박스(Sandbox): 아이들이 안전한 공간에서 자유롭게 놀 수 있도록 만든 모래놀이 공간에서 유래한 용어입니다. 실제 운영 환경과 분리된 테스트 환경을 의미하며, 개발자가 운영 서비스에 영향을 주지 않고 새로운 코드나 기능을 배포하고 검증할 수 있는 공간을 말합니다.