플랫폼 엔지니어링 PoC의 여정

LG U+ 데브옵스팀이 서비스 운영 규모 증가에 대응하기 위해 플랫폼 엔지니어링 도입 가능성을 검증한 PoC 경험을 정리한 글이다. 헬스체커(Vitalsign), UI 플랫폼(Castle/Gatehouse), 서비스 카탈로그(Backstage), IaC 자동화(Portico) 4가지 컴포넌트를 개별 구현·검증했고, 최종적으로 플랫폼 엔지니어링이 효과적이려면 반복 작업 규모·사용자 수·유지 인력이 충분해야 한다는 결론을 얻었다.

핵심 포인트

Vitalsign 헬스체커를 TypeScript 기반 시나리오에서 YAML 기반으로 전환해 비개발자도 시나리오를 직접 작성할 수 있게 했다.
UI 플랫폼 Castle은 Django+Uvicorn+Ninja 백엔드, Next.js+Vercel 프론트로 셀프서비스 도구를 제공했지만 운영·유지보수 인력 부담이 컸다.
Backstage로 분산된 서비스 메타데이터 중앙화를 시도했으나 공식 문서 부족으로 소스 코드 직접 분석이 필요했고 수동 서비스 등록 공수도 문제였다.
IaC 자동화(Portico)는 투자 대비 기대 효과가 낮아 중단했는데, 이후 AI 발전으로 당시 목표 대부분이 충족돼 합리적 결정이었다고 회고했다.
플랫폼 엔지니어링은 그 자체가 목적이 되면 안 되며, '잘 만들었는가'보다 '현재 조직에 적합한가'가 핵심이다.

상세 정리

배경: 2023~2024년 서비스 현대화·기술 내재화 작업이 증가하면서 운영 규모와 안정성을 체계적으로 관리할 필요가 생겼고, 플랫폼 엔지니어링 트렌드와 맞물려 PoC를 시작했다.
요구 기능 정의: 24/7 서비스 안정성 체크, 서비스 개발·이용 UI 플랫폼, 반복 작업 자동화 등 3가지 범주로 정의하고 각각 Vitalsign·Castle·Portico 코드네임을 붙였다.
Vitalsign YAML 전환: 기존 TypeScript 시나리오는 유연하지만 개발자만 작성 가능하고 의도가 코드에 가려졌다. YAML로 전환하자 비개발자 접근성과 스텝 간 의존성·파라미터·타임아웃 가시성이 좋아졌지만 파서와 검증 로직 유지 비용이 새로 생겼다.
Vitalsign 기술 선택: 가용성을 위해 AWS 매니지드/서버리스 서비스를 최대 활용했고, TypeScript+Zod로 런타임 오류를 최소화했으며 ODM으로 Dynamoose를 사용했다.
Castle & Gatehouse: Okta SAML 기반 인증에 VPN·방화벽 접근 제어를 더했고, 백엔드는 Django+Uvicorn+Ninja, 프론트는 Next.js+Vercel로 구성했다. 시범 서비스는 Nginx Proxy 설정 셀프서비스와 비밀번호 초기화 셀프서비스 2종이었다.
Castle 트레이드오프: 서비스를 UI로 가시적으로 제공하고 신규 서비스를 플랫폼에 붙이기 쉬운 장점이 있었지만, 운영·유지보수 비용과 추가 개발 인력 요구가 단점이었다.
Backstage PoC: 분산된 서비스 메타데이터를 중앙 관리하기 위해 동명의 오픈소스를 도입했다. 커스텀 권한 플러그인을 직접 개발했고, 서비스 카탈로그 설정을 각 레포 분산에서 Backstage 레포 단일 집중 방식으로 변경했다.
Backstage 단점: 공식 문서가 부족해 소스 코드를 직접 분석해야 했고, 서비스를 수동으로 등록해야 해서 서비스 변경이 잦으면 최신 상태 유지가 어려웠다.
Portico 중단: PyYAML·pyhcl로 IaC 반복 작업과 포매팅 자동화를 시험했으나 필요한 투자 대비 기대 효과가 낮다고 판단해 중단했다. 이후 AI 발전으로 당시 목표 대부분이 해소됐다.
PoC 결론: 플랫폼 엔지니어링은 반복 작업이 충분히 많고, 사용자 수가 일정 규모 이상이고, 플랫폼 유지 인력이 확보된 경우에만 효과적이다. 이 조건이 안 갖춰지면 플랫폼 자체가 더 큰 운영 부담이 된다.