사내 인프라 플랫폼 배럭 구축기
인프라 티켓 반복 업무를 신청·승인·배포 포털로 전환한 배럭 구축 사례를 소개했습니다. 기존 ArgoCD·Terraform 파이프라인을 재사용하며 안전한 셀프서비스를 구현했습니다.

ArgoCD 태그가 달린 국내 IT 기업 기술 블로그 글을 최신순으로 모았습니다.
20개 표시
인프라 티켓 반복 업무를 신청·승인·배포 포털로 전환한 배럭 구축 사례를 소개했습니다. 기존 ArgoCD·Terraform 파이프라인을 재사용하며 안전한 셀프서비스를 구현했습니다.

개발자의 인지 부담을 줄이기 위해 골든 패스와 Platform Portal 설계 방향을 정리했습니다.\nGitOps·정책 자동화와 RAG 기반 AI 도우미로 개발자 경험을 개선합니다.
MCP로 DevOps 도구와 AI를 연결해 배포 실패 원인 분석과 운영 트러블슈팅을 자동화하는 사례를 다뤘습니다. kt cloud PLATFORM에서는 망 분리와 Read-Only 원칙을 전제로 단계적 도입 방안을 검토했습니다.
홈랩 Kubernetes에서 ArgoCD와 GitLab Self-Managed를 연동해 GitOps를 구축하는 과정을 실습했습니다. 접속, 인증, 저장소 등록, Kustomize 전환에서 막히는 지점과 해결책도 정리했습니다.

개발과 운영 전반에 AI를 적용하는 kt cloud의 사례를 소개했습니다. Observability, 개발환경 자동화, PR 리뷰 자동화와 장애 대응 전략을 함께 다뤘습니다.
LLM 서빙에서는 단순히 모델을 띄우는 것보다, 지표를 잘 설계하고 원인을 빠르게 추적하는 운영이 중요했습니다. Prefix Cache, finish_reason, KV Cache 같은 신호를 활용해 타임아웃과 처리량 문제를 해결했습니다.

ALB 한도와 ECS Target Group 제한을 넘기 위해 Kong과 VPC Lattice로 서비스 네트워크를 재설계했습니다.\n서비스 통합과 GitOps 제어로 고정비를 82% 줄이고, 이관과 배포 편입도 무중단으로 유지했습니다.

OpenStack 샌드박스 이미지에서 발생한 IP 변경과 시크릿 노출 문제를 자동 복구와 GitOps, Vault·ESO 조합으로 정리했습니다. 수동 배포를 줄이고 운영 재현성과 보안을 함께 높인 사례를 소개했습니다.
Showcase가 자기 자신을 배포 대상으로 삼는 구조에서 발생하는 정합성 문제를 상태 머신과 이벤트 분할로 해결했습니다. 재기동 후 버전 검증과 멱등 발행, GID 기반 식별로 분산 배포의 일관성을 확보했습니다.

GitOps에서 PR 단계에 배포 결과 diff를 미리 보여주는 방법을 소개했습니다. 또한 Helm 렌더와 values 출처 추적으로 리뷰 화면에서 변경 영향을 바로 확인하도록 했습니다.

13년간 쌓인 운영 흔적을 분리해 검증 가능한 stage 환경을 구축했습니다. 운영에 가까운 조건에서 배포와 변경을 안전하게 확인하도록 재구성했습니다.

terraform plan만으로는 인프라의 실제 동작을 확인할 수 없다는 문제를 다뤘습니다. 로컬 클러스터 검증과 재현 가능한 선언으로 apply 전 신뢰도를 높이는 방법을 소개했습니다.
![[인프라를 소프트웨어처럼 4/5] plan은 동작을 모른다: 인프라를 테스트·재현한다는 것](https://static.flex.team/v2/landing-2024/og/main.jpg)
공유 dev 병목을 없애기 위해 브랜치 하나로 격리 환경을 만드는 Environment Variant 설계를 소개했습니다. ArgoCD ApplicationSet으로 생성과 회수를 자동화해 환경 생명주기를 git과 연결했습니다.
OpenStack 기반 개인용 샌드박스 이미지를 단일 VM에 GitOps 방식으로 구성했습니다.부팅 후 ArgoCD와 Flux가 Git 변경을 반영해 git push만으로 업데이트되도록 실험했습니다.
ArgoCD 배포를 정적 YAML 대신 HelmRelease와 FluxCD로 전환하는 방법을 정리했습니다. values 분리, 순서 보장, 에어갭 배포까지 운영 포인트를 함께 다뤘습니다.
서버 플랫폼 팀이 조직 성장에 맞춰 플랫폼을 계속 재설계하는 이유를 소개했습니다. AI 시대의 분석·개발·운영 변화와 그에 따른 가드레일까지 함께 다뤘습니다.
라포랩스가 AWS AI-DLC로 사내 배포 플랫폼 Raploy를 구축한 사례를 공유했습니다. 비개발 직군도 AI와 플랫폼을 통해 배포·운영할 수 있도록 자동화와 관측성을 함께 강화했습니다.

배포 코드가 환경 이름을 직접 읽지 않도록 Helm values와 GitOps 규율로 분리한 구조를 설명했습니다. Jenkinsfile까지 같은 원칙을 적용해 배포 이력을 Git으로 남기는 방법을 다뤘습니다.
![[코드가 환경을 모르는 구조 2/7] 배포 코드가 환경을 모르는 구조](https://flex.team/blog/og/main.jpg)
배포 코드를 환경별로 갈라 쓰지 않고, 템플릿과 값의 층을 분리해 환경을 외부에서 주입하는 구조를 설명했습니다. GitOps와 Jenkinsfile에도 같은 규율을 적용해 배포 이력을 Git에 남기는 방법을 다뤘습니다.
![[코드가 환경을 모르는 구조 2/7] 배포 코드가 환경을 모르는 구조](https://cdn.sanity.io/images/v31psllp/production/58ae2e178769ca25361200fed07c9ecb06c62d2a-1684x1030.png)
EKS + ALB 환경에서 Blue/Green과 기본 Canary의 Promote 시 503이 발생하는 원인을 분석했습니다. Argo Rollouts Canary PingPong으로 selector 변경 없이 weight만 교대해 문제를 해결했습니다.