[플랫폼설계] DevOps에서 Platform Engineering으로: kt cloud의 여정

 

kt cloud Platform엔지니어링팀 이지은 님

 

📝 요약 SUMMARY

이 글에서는 DevOps에서 Platform Engineering으로 전환하며 개발자의 인지 부담을 줄이기 위해
Platform Portal과 골든 패스를 설계하는 과정을 다룹니다.
셀프서비스·GitOps·정책 자동화와 RAG 기반 AI 에이전트로 개발자 경험을 개선하는 방향을 정리합니다.

#PlatformEngineering #PlatformPortal #GoldenPath #GitOps #DeveloperExperience

---

"이 YAML은 누가 작성하나요?"

kt cloud에서 NEXT 프로젝트를 진행하던 시절, 회의에서 심심치 않게 오가던 질문입니다. 배포 파이프라인을 작성하고 수정하는 건 개발자 몫이었고, Kubernetes 매니페스트를 손보는 것도, CI 스크립트가 실패하면 원인을 추적하는 것도 결국 개발자에게 돌아왔습니다.

 

당시 조직 이름은 CICD 였습니다. 이름 그대로, 지속적 통합과 배포 자동화가 핵심 미션이었습니다. DevOps 철학이 퍼지던 시대의 흐름을 잘 반영한 이름이기도 했습니다. "만든 사람이 운영도 한다(You build it, you run it)"는 원칙 아래, 개발자들은 기능 개발과 배포 운영을 동시에 책임졌습니다.

 

그런데 클라우드 네이티브 생태계가 생각보다 훨씬 빠르게, 훨씬 복잡하게 성장하면서 문제가 발생했습니다.

---

인지 부담이라는 현실

개발자 한 명이 하루 동안 마주하는 것들을 나열해보면 이렇습니다.

• 기능 개발을 위한 비즈니스 로직 구현
• ArgoCD SyncPolicy 조정, App yaml 작성
• Kyverno 정책 위반으로 인한 배포 실패 원인 추적
• Harbor 이미지 레지스트리 Push, Pull, Tagging 설정
• Image CVE 취약점 조치
• GitHub Actions 워크플로우 디버깅

비즈니스 가치를 만들어내는 행위는 첫 번째뿐입니다. 나머지는 인프라 복잡성이 만들어낸 부수적 업무입니다. 이것을 인지 부담(Cognitive Tax)이라 부릅니다. 개발자가 핵심 업무에 쓸 수 있는 두뇌 자원을 인프라 운영이 잠식하는 현상입니다.

 

DevOps는 본래 사일로를 제거하자는 철학이었습니다. 하지만 많은 조직에서 이 철학은 "개발자가 운영까지 다 하면 된다"는 방식으로 실천됐고, 결과적으로 모든 팀원이 전문적인 인프라 지식을 갖춰야 한다는 암묵적인 요구로 이어졌습니다.

 

실제로 NEXT 프로젝트 시절을 돌이켜보면, 각 서비스 팀이 비슷한 배포 파이프라인을 각자 조금씩 다른 방식으로 작성하고 있었습니다. GitHub Actions 워크플로우, Helm values 파일 구조도 제각각이었습니다. 동일한 문제를 열 팀이 열 번 푸는 구조였고, 각자 조금씩 다른 버그를 품고 있었습니다.

 

아래 다이어그램은 이 변화의 흐름을 잘 보여줍니다.

Image: AI-Generated Content

---

조직의 이름이 바뀌었다는 것

2026년, CICD에서 Platform엔지니어링팀으로 조직 이름이 바뀌었습니다.

 

단순한 명칭 변경이 아니었습니다. 업무의 철학이 달라졌습니다. 배포 자동화 도구를 만들고 관리하는 것에서, 개발자가 더 잘 개발할 수 있는 환경 자체를 설계하는 것으로 미션이 바뀐 것입니다. kt cloud의 플랫폼 엔지니어링 여정이 본격적으로 시작된 시점이었습니다.

 

이 전환을 촉발한 질문은 세 가지였습니다.

 

첫째, 개발자가 새 서비스를 시작할 때 왜 이렇게 많은 것을 직접 설정해야 하는가?

 

둘째, 보안 정책과 표준을 지키면서도 속도를 낼 수 있는 방법은 무엇인가?

 

셋째, AI가 발전하고 있는 지금, 플랫폼이 더 지능적으로 개발자를 도울 수 있지 않을까?

업무 방식이 달라졌다

명칭 변경과 함께 실제 업무 프로세스도 달라지기 시작했습니다. 가장 큰 변화는 티켓 기반 요청에서 셀프서비스로의 전환입니다.

 

이전에는 개발팀이 새로운 서비스 생성이 필요하면 CICD팀에 Slack 메시지를 보내거나 Jira 티켓을 등록해야 했습니다. ArgoCD 프로젝트 생성, Harbor 프로젝트 할당, Vault 시크릿 경로 구성 같은 작업들이 모두 요청-처리 사이클을 거쳤습니다. 빠르면 하루, 늦으면 며칠이 걸렸습니다.

 

Platform엔지니어링팀으로 전환하면서 목표는 이 과정을 개발자가 직접 처리할 수 있는 구조로 바꾸는 것입니다. "우리 팀에 요청하세요"가 아니라 "플랫폼이 알아서 해줍니다"가 되는 것입니다. 그리고 그 플랫폼을 만드는 것이 지금 우리 팀의 미션입니다.

---

Platform Engineering: "쉬운 길을 올바른 길로"

Platform Engineering의 핵심 아이디어는 간단합니다. 모든 개발자가 인프라 전문가가 되길 요구하는 대신, 전담 팀이 잘 닦인 길을 만드는 것입니다. 이를 골든 패스(Golden Path)라 부릅니다.

 

골든 패스를 선택한 개발자는 보안, 확장성, 모니터링이 기본으로 내장된 환경에서 서비스를 배포할 수 있습니다.

 

반면 특수한 요구가 있어 표준 경로를 벗어나는 정글 패스를 택한다면, 그에 따른 책임 역시 개발자가 집니다. 강제가 아닌 인센티브 구조로 자연스럽게 표준화를 이끄는 방식입니다.

 

Platform엔지니어링팀은 지금 이 골든 패스를 구현하는 Platform Portal을 개발 중입니다. 하나의 플랫폼에서 개발자가 필요로 하는 모든 것, 즉 서비스 배포, 파이프라인 실행, 정책 확인, 인프라 프로비저닝을 처리할 수 있도록 설계하고 있습니다.

---

골든 패스가 실제로 어떻게 작동하나

kt cloud 환경에서 골든 패스는 다음과 같은 흐름으로 동작하도록 설계하고 있습니다.

개발자가 서비스 카탈로그에서 템플릿 선택
        ↓
Platform Portal이 Github/Gitea에 표준 구조의 레포지토리 자동 생성
        ↓
ArgoCD AppProject 및 Application 리소스 자동 프로비저닝
        ↓
Kyverno 정책이 자동으로 적용된 네임스페이스 구성
        ↓
Harbor 프로젝트 생성 및 이미지 푸시 권한 설정
        ↓
GitHub Actions 워크플로우로 빌드-서명-배포 파이프라인 구성
        ↓
Prometheus + Grafana 기반 기본 모니터링 대시보드 자동 생성

 

개발자는 서비스 이름과 몇 가지 설정값만 입력하면 됩니다. Kubernetes 매니페스트 구조를 알 필요도 없고, ArgoCD SyncPolicy 옵션을 검색할 필요도 없습니다. 보안 정책(Kyverno), 이미지 서명(Cosign), 시크릿 관리(Vault + External Secrets Operator)가 기본으로 내장됩니다.

 

이것이 골든 패스가 "쉬운 길을 올바른 길로" 만드는 방식입니다.

---

Platform Portal - 골든 패스를 구현하는 플랫폼

Platform엔지니어링팀은 지금 이 골든 패스를 구현하는 Platform Portal을 개발 중입니다. 하나의 플랫폼에서 개발자가 필요로 하는 모든 것, 즉 서비스 배포, 파이프라인 실행, 정책 확인, 인프라 프로비저닝을 처리할 수 있도록 설계하고 있습니다.

Platform Portal을 구성하는 주요 컴포넌트

서비스 카탈로그

 

Platform Portal의 프론트엔드 역할을 합니다. 개발자는 Platform Portal에서 제공하는 Template을 통해 새 서비스를 시작하고, 기존 서비스들의 의존 관계와 소유자 정보를 한 곳에서 확인합니다. "어떤 서비스가 존재하고, 누가 소유하며, 어떤 인프라 위에서 돌아가는가"에 대한 단일 진실 원천(Single Source of Truth)이 됩니다.

 

GitOps 엔진 (ArgoCD + FluxCD)

 

Platform Portal에서 선언된 서비스 상태가 실제 클러스터에 반영되는 경로입니다. ArgoCD는 애플리케이션 배포를 담당하고, FluxCD는 플랫폼 인프라 컴포넌트(Helm으로 배포되는 플랫폼 Apps)의 생명주기를 관리합니다. 두 도구를 용도에 따라 나눠 운영하는 것이 현재 kt cloud의 구조입니다.

 

정책 엔진 (Kyverno)

 

모든 배포에 자동으로 적용되는 가드레일입니다. 이미지 서명 검증, 리소스 제한 강제, 레이블 표준화 등이 정책으로 정의되어 있어, 개발자가 신경 쓰지 않아도 보안 기준이 지켜집니다.

 

이미지 레지스트리 (Harbor)

 

에어갭/사내 환경에서 컨테이너 이미지를 안전하게 관리하는 허브입니다. Tag Immutability, 이미지 스캔, GC, 복제(Replication) 기능을 통해 이미지 공급망 보안을 담당합니다.

 

시크릿 관리 (Vault + External Secrets Operator)

 

애플리케이션이 필요로 하는 시크릿을 Kubernetes Secret으로 자동 동기화합니다. 개발자는 Vault 경로만 지정하면 되고, 시크릿 로테이션과 접근 제어는 플랫폼이 처리합니다.

 

이 컴포넌트들이 유기적으로 연결되어 골든 패스를 구성합니다. 개발자가 Platform Portal에서 템플릿을 선택하면, 나머지 컴포넌트들이 순서에 따라 자동으로 작동합니다.

---

2026년, AI가 더하는 가능성

Platform Portal을 설계하면서 빠질 수 없는 화두가 AI입니다. 단순 자동화를 넘어, AI 에이전트가 플랫폼의 두뇌 역할을 하는 방향으로 발전하고 있습니다.

개발자가 "Kyverno 정책 위반 났을 때 어떻게 해요?"라고 물으면, AI가 Confluence와 Jira, GitHub Wiki에 흩어진 런북을 직접 찾아 답해주는 세계입니다.

문서가 어디 있는지 뒤지거나, 플랫폼팀에 Slack으로 물어보는 과정 없이 말입니다.

RAG 기반 플랫폼 도우미

현재 구상 중인 AI 에이전트의 핵심은 RAG(Retrieval-Augmented Generation) 입니다. 단순히 LLM을 붙이는 것으로는 부족합니다.

 

kt cloud 내부의 맥락, 즉 우리 팀이 작성한 런북, ArgoCD App 구성 예시, Kyverno 정책 설명, Harbor 운영 가이드 같은 내부 문서를 LLM이 참조할 수 있어야 합니다.

 

구체적인 구조는 다음과 같습니다.

개발자 질문: "ArgoCD sync가 계속 실패하는데, OutOfSync 상태가 안 풀려요"
        ↓
벡터 DB에서 관련 런북 검색
(Confluence/Jira 페이지, GitHub Wiki, 이전 인시던트 기록)
        ↓
LLM이 검색된 내부 문서 + 현재 클러스터 상태를 조합해 답변 생성
        ↓
"Hard Refresh를 시도해보세요. ArgoCD CLI로는 `argocd app get <앱명> --hard-refresh`
 명령을 사용하면 됩니다. 이전에 동일한 증상이 있었던 경우 캐시 문제일 가능성이 높습니다."

이 구조가 작동하려면 내부 문서의 품질과 벡터 인덱싱이 잘 관리되어야 합니다. "AI가 틀린 답을 자신 있게 말하는" 상황을 방지하려면, 참조하는 지식 베이스 자체가 정확하고 최신 상태여야 합니다.

 

이것이 Platform Portal에서 문서화와 런북 관리가 단순한 부가 업무가 아닌 핵심 인프라가 되는 이유입니다.

 

Platform엔지니어링팀이 구상하는 Platform Portal는 이 방향을 바라보고 있습니다. AI를 통해 플랫폼이 맥락을 이해하고, 개발자의 의도를 인프라로 번역해주는 인터페이스를 만드는 것이 장기 목표 중 하나입니다.

---

DevOps는 죽지 않았습니다, 진화했습니다

"DevOps는 죽었다"는 말이 회자되지만, 정확한 표현은 아닙니다. DevOps가 가져온 자동화, 협업, 지속적 개선의 철학은 여전히 유효합니다. 달라진 것은 그 철학을 실현하는 방식입니다.

 

DevOps가 "왜"를 답했다면, Platform Engineering은 "어떻게"를 답합니다. 사일로를 허물고 속도를 높이자는 DevOps의 목표를, 대규모 조직에서 지속 가능하게 실현하는 구조적 접근이 Platform Engineering입니다.

 

한 가지 오해를 짚고 싶습니다. Platform Engineering이 개발자에게서 운영 책임을 완전히 가져오는 것은 아닙니다.

 

오히려 개발자가 자신의 서비스를 운영하기 위해 필요한 좋은 도구를 만드는 것입니다.

 

골든 패스를 걷는 개발자는 Kubernetes를 직접 다루지 않아도 되지만, 자신의 서비스가 어떤 상태인지는 여전히 책임집니다. 플랫폼이 그 책임을 더 쉽게 질 수 있도록 도구를 제공하는 것입니다.

앞으로의 여정

kt cloud의 Platform엔지니어링팀은 지금 그 여정 위에 있습니다. CICD 자동화에서 시작해, 이제는 개발자 경험 전체를 설계하는 팀으로 성장하고 있습니다.

 

솔직히 말하면 아직 갈 길이 멉니다. 서비스 카탈로그는 초기 구축 단계이고, AI 에이전트는 아직 구상과 PoC 수준입니다. 멀티 클러스터 환경에서 골든 패스를 일관되게 유지하는 것도 여전히 도전 과제입니다.

 

하지만 방향은 분명합니다. 개발자가 인프라 복잡성이 아닌 비즈니스 문제에 집중할 수 있는 환경, 그리고 그 환경이 보안과 표준을 자연스럽게 내장하는 구조를 만드는 것입니다.

 

개발자를 위한 Platform Portal이 완성될 때, 회의실에서 "이 YAML은 누가 작성하나요?"라는 질문이 사라질 것입니다. 그 질문 자체가 필요 없어지는 것이 목표입니다.

 

---

❔자주 묻는 질문 FAQ

Q Platform Engineering을 도입하면 개발자의 자율성이 줄어드는 것 아닌가요?

A 반대입니다. 골든 패스는 강제가 아닌 선택입니다. 표준 경로를 따르면 플랫폼팀이 운영 책임을 함께 지고, 특수한 요구가 있으면 정글 패스로 완전한 자유를 가질 수 있습니다. 오히려 개발자가 인프라 복잡성에 시간을 쏟지 않아도 되기 때문에, 제품 개발에 쓸 수 있는 자유 시간이 늘어납니다.

Q Platform Portal 구축이 복잡하고 비용이 많이 드는데, 작은 조직에도 필요한가요?

A 팀 규모와 무관하게, 인프라 설정에 반복적으로 시간을 소비하고 있다면 Platform Portal의 필요성을 느끼게 됩니다. 처음부터 완성된 Platform Portal을 만들 필요는 없습니다. 가장 반복적인 작업 하나를 셀프서비스화하는 것부터 시작해, 점진적으로 확장하는 방식이 현실적입니다. 우리 팀도 그 과정을 걷고 있습니다.

Q 기존 DevOps 담당자 역할은 어떻게 달라지나요?

A DevOps 엔지니어가 사라지는 게 아니라, 역할이 바뀝니다. 개별 팀의 CI/CD 파이프라인을 직접 관리하는 역할에서, 모든 팀이 쓸 수 있는 플랫폼을 만드는 역할로 전환됩니다. 영향력의 범위가 한 팀에서 전체 조직으로 넓어지는 것입니다.

---