마이다스인의 플랫폼 혁신 여정, Part1: Amazon EKS 전환

마이다스인은 2,100여 고객사에 AI 기반 채용 플랫폼을 제공하는 대한민국 대표 HR 테크 기업입니다. AI 관련된 기능 추가와 더불어 복잡해지는 서비스 구조와 더불어 매년 수십만 명이 동시 접속하는 대규모 채용 시즌마다 증가하는 트래픽을 효과적으로 처리하기 위해 기존 Amazon ECS 기반의 인프라를 고도화 해야 하는 도전에 직면했습니다.

앞으로 2회에 걸친 블로그 포스트를 통해 마이다스인이 AWS와 협력하여 Amazon EKS로의 전환과 Kiro를 활용해 DevOps엔지니어 2명이 Internal Developer Platform(IDP) 구축한 사례를 소개하고자 합니다.

마이다스인의 플랫폼 혁신 여정, Part1: Amazon EKS 전환
마이다스인의 플랫폼 혁신 여정, Part2: Kiro를 활용한 IDP 구축

Amazon EKS로의 전환 배경

마이다스인의 서비스를 책임지던 Amazon ECS 환경은 서비스 성장 초기 단계에서 안정적인 워크로드를 제공했습니다. 그러나 서비스가 고도화되면서 신규 서비스 요청, 환경 생성, 커스터마이즈 요구에 대응하기 어려워졌습니다. 특히 빠르게 변화하는 채용 시즌 트래픽과 다양한 요구사항을 만족시키기 위해서는 더 유연한 오케스트레이션 플랫폼이 필요했습니다.

마이다스인 DevOps팀은 Amazon EKS로 플랫폼 전환을 결정하며 다음과 같은 목표를 수립했습니다:

GitOps 기반 단일 레이어 관리
환경별 유연한 확장
GenAI 통합에 최적화된 생태계 구축

이는 단순히 컨테이너를 옮기는 수준이 아니라, 운영 성숙도와 DevOps 모델 고도화를 위한 전략적 전환이었습니다.

설계 및 마이그레이션

GitOps

Amazon EKS로 전환하며, 모든 애플리케이션은 GitOps(Argo CD + Helm 차트) 기반 파이프라인에서 관리되었습니다. 기존에 서비스별로 달랐던 배포 과정을 일원화하여 반드시 Pull Request가 생성되면 Amazon Bedrock으로 구현한 Code Review Bot을 트리거해 변경된 파일간의 상관관계를 검토 및 분석하고, 서비스별 고려사항(제약사항, 특이사항 등)을 반영한 자동화된 리뷰를 거쳐 발생할 수 있는 문제들을 사전에 검토하여 승인된 경우에만 반영되도록 했습니다. 어플리케이션 코드와 더불어 인프라를 구성하는 코드도 같은 과정을 거치도록 해 Infrastructure as Code로 정의한 인프라와 실제 배포된 인프라 사이의 Drift를 최소화 했습니다.

자원 활용 최적화

Amazon EKS전환 이후 가장 중점적으로 진행한 과제는 노드 자원 활용 효율성이었습니다. 채용 서비스 특성상 트래픽은 기업과 시즌에 따라 급격히 증가했다가 빠르게 감소하는 패턴을 보였습니다. 이를 대응하기 위해 적극적 Binpacking 전략을 도입했습니다.

단순히 파드를 균등 분산하지 않고, 애플리케이션별 처리 한계치를 정량적으로 분석했습니다. 예를 들어, 서버 한 대에서 동시에 감당 가능한 응시자 수를 기준으로 Pod 단위 CPU·메모리 리소스를 최적화했습니다. 이렇게 산출된 데이터를 기반으로 대형 노드에 파드를 밀집 배치하여 리소스 파편화를 최소화했습니다.

추가로, 단순 측정에 그치지 않고 Datadog 기반 장기 메트릭(Long-term Metrics) 분석을 통해 requests/limits 값을 재산정했습니다.

공채 시즌과 비공채 시즌을 구분하여 장기 데이터 기반 Right Sizing 수행
Quality of Service 클래스 구분: 실시간 트래픽 서비스는 Burstable, 배치 워크로드는 Guaranteed로 설정
JVM 워크로드: Heap / Non-Heap 메모리 특성을 반영해 안정적 limit 설정

이 과정을 통해 오버프로비저닝을 제거하고 노드의 파편화를 줄이는 동시에, 워크로드 안정성을 보장했습니다. 시스템 안정성을 최우선으로 고려해, CoreDNS, Karpenter, ALB Controller 등 핵심 인프라 컴포넌트는 다른 워크로드와 자원을 경쟁하지 않도록 AWS Fargate 기반으로 분리 운영했습니다.

마지막으로, 인스턴스 타입 역시 반복 측정을 통한 정량적인 분석을 진행해 최적화했습니다. 다양한 인스턴스 타입들을 비교 검증해 “한 인스턴스에 8개 서비스까지 안정적으로 수용하되 15~20% 여유를 남기는” 최적의 조합을 찾아 비용과 안정성의 균형을 확보했습니다.

비용 최적화: Spot 인스턴스 전략

Amazon EKS전환 이후 비용 최적화를 위해 개발·테스트 환경에는 Spot Instances를 100% 활용하는 구성을 적용했습니다.

Spot Instance는 On-Demand 대비 최대 70~80% 비용 절감 효과를 제공합니다. 하지만 이러한 절감에는 항상 Instance가 언제든지 회수 될 수 있다는 위험이 동반됩니다. 마이다스인은 Spot Instance의 중단 알림(Interruption Notice)이 발생할 경우 주어지는 2분의 유예시간을 활용해 안전한 셧다운과 새로운 Spot Instance 확보가 가능하도록 다음과 같은 Spot Instance 회수 대응 체계를 설계했습니다.

Spot Interruption 대응 플로우:

중단 알림(Interruption Notice)을 Amazon SQS로 수집
Karpenter가 신규 노드 사전 프로비저닝(Pre-provisioning)
기존 파드는 preStop Hook + TerminationGracePeriodSeconds로 세션 종료 보장
-aws-verify-target-group로 TargetGroup이 새 파드 IP와 완전히 동기화될 때까지 롤아웃을 일시 정지해 502 오류 방지
ReplicaCount=2 + PDB(minAvailable=1)로 최소 가용성 유지
노드는 가용 영역(Topology Spread) 기반으로 분산 배치

이 전략을 통해 두 Spot Instance가 동시에 회수될 가능성을 0.1% 미만으로 줄일 수 있었고 실제로 지난 6개월 동안 수백 차례의 Spot Instance회수 알림을 관찰했지만, 두 노드가 동시에 회수된 사례는 단 한 번도 발생하지 않았습니다. 모든 회수 이벤트는 수십 초 이내 자동 복구로 안정적으로 처리되었습니다. 결과적으로, 안정성을 유지하면서도 평균 약 25%의 비용 절감 효과를 달성했으며, 이는 전체 AWS 사용비용을 연간 약 15% 수준의 추가 절감 효과에 해당합니다.

인프라 전환 성과

Amazon EKS전환을 통해 달성한 주요 성과는 다음과 같습니다.

항목	이전	이후
자원 활용률	평균 40%	70% 이상
환경 생성 시간	Terraform 기반 4시간	Amazon EKS 템플릿 기반 5분 (≈50배 단축)
비용	기준값	Spot + Binpacking으로 최대 25% 절감
네트워크 안정성	–	NLB + ALB + IPAM으로 고정 IP·보안 요구 충족

Amazon EKS 기반 인프라로의 전환을 통해 자원 활용률을 대폭 개선하고, 환경 프로비저닝 시간을 획기적으로 단축했으며, 클라우드 비용을 효과적으로 절감했습니다. 엔터프라이즈급 네트워크 아키텍처 구축으로 보안과 안정성을 강화하여, 이후 GenAI를 활용한 자동화 전략의 안전한 실험 및 도입을 가능하게 한 기반이 되었습니다

AWS 기술 블로그