
플랫폼은 왜 계속 다시 설계되어야 할까 - Server Platform Team 이야기
서버 플랫폼 팀이 조직 성장에 맞춰 플랫폼을 계속 재설계하는 이유를 소개했습니다. AI 시대의 분석·개발·운영 변화와 그에 따른 가드레일까지 함께 다뤘습니다.

서버 플랫폼 팀이 조직 성장에 맞춰 플랫폼을 계속 재설계하는 이유를 소개했습니다. AI 시대의 분석·개발·운영 변화와 그에 따른 가드레일까지 함께 다뤘습니다.


라포랩스가 AWS AI-DLC로 사내 배포 플랫폼 Raploy를 구축한 사례를 공유했습니다. 비개발 직군도 AI와 플랫폼을 통해 배포·운영할 수 있도록 자동화와 관측성을 함께 강화했습니다.
![[코드가 환경을 모르는 구조 2/7] 배포 코드가 환경을 모르는 구조](https://cdn.sanity.io/images/v31psllp/production/58ae2e178769ca25361200fed07c9ecb06c62d2a-1684x1030.png)

배포 코드를 환경별로 갈라 쓰지 않고, 템플릿과 값의 층을 분리해 환경을 외부에서 주입하는 구조를 설명했습니다. GitOps와 Jenkinsfile에도 같은 규율을 적용해 배포 이력을 Git에 남기는 방법을 다뤘습니다.

Kubernetes StatefulSet의 Immutable 제약을 우회해 PVC를 먼저 확장하고 Non-cascade로 컨트롤러만 교체하는 절차를 정리했습니다. 서비스 중단 없이 스토리지를 늘리는 실무 트러블슈팅 방법을 설명했습니다.
![[미래를 담아낸 뼈대 5/7] 코드가 환경을 모르는 구조](https://flex.team/blog/og/main.jpg)

코드와 환경을 분리하는 Hexagonal 원칙을 배포, 인프라, 디버깅, 테스트까지 확장한 사례를 다뤘습니다. 부분 교체와 외부 주입으로 이터레이션 속도를 높이는 방법을 설명했습니다.
![[미래를 담아낸 뼈대 5/7] 코드가 환경을 모르는 구조](https://cdn.sanity.io/images/v31psllp/production/626db41a03292c4b57863b75c7bc5e755e395184-1684x1030.png)

애플리케이션과 인프라 전반에 Hexagonal 원칙을 적용해 환경 의존성을 분리하는 방법을 설명했습니다. 부분 교체와 주입으로 빠른 검증과 이터레이션을 가능하게 만든 사례를 다뤘습니다.
정산을 사람의 기억이 아닌 시스템의 책임으로 옮기기 위한 MASS 설계 원칙을 다뤘습니다. 멱등성, 결정적 계산, 고정 반올림으로 재처리와 재계산에도 동일한 결과를 보장했습니다.


기존 ECS 기반 인프라의 확장성과 운영 복잡도 문제를 해결하기 위해 Amazon EKS로 전환했습니다.\nGitOps, Binpacking, Spot 대응 체계를 도입해 비용과 안정성을 함께 개선했습니다.


Argo CD Image Updater로 이미지 태그 갱신과 배포 연결을 자동화하는 방법을 정리했습니다. Jenkins 중심 파이프라인을 GitOps 기반으로 경량화한 구성도 함께 설명했습니다.


여기어때는 파편화된 CI/CD와 Helm Chart를 표준화해 문제를 줄였습니다. 개발자 숙련도와 무관한 동일한 배포 경험을 만들기 위해 입력 방식과 재사용 구조를 개선했습니다.