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

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

이번 블로그 포스트에서는 플랫폼 전환 이후 고도화 하는 과정에서 Kiro를 활용해 DevOps엔지니어 2명이 Internal Developer Platform(IDP) 구축한 사례를 소개하고자 합니다.

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

Kiro 기반 GenAI 혁신

Amazon EKS로 전환 후 안정성과 비용효율성이 큰 폭으로 상승하며 기존보다 안정적인 운영이 가능해 졌습니다. 그러나 운영의 현실은 여전히 복잡했습니다. Amazon EC2 인스턴스, 컨테이너 워크로드, 데이터베이스, AWS Lambda와 각종 서비스를 통틀어 약 2,200개의 리소스를 소수 DevOps팀에서 직접 운영하고 있었고 인프라의 규모는 매우 빠르게 커지고 있었습니다.

매일 수십 건의 배포와 변경이 이루어지며, toil(반복적이고 자동화되지 않은 운영 업무)이 점점 누적되었습니다. 서버 스케줄링, Parameter Store 생성 및 수정, 단순 DB 조회나 상태 확인 쿼리처럼 사람이 직접 손을 대야 하는 작업들이 매일 이어졌습니다.

마이다스인 DevOps팀은 방대한 양의 리소스를 수동으로 관리하는 대신 좀 더 효율적으로 관리하기 위해 Kiro를 도입해 해결하는 방향으로 접근 방식을 전환했습니다. 먼저 요구사항을 명확히 정리하면, Kiro가 그에 맞는 작업 계획과 체크리스트 초안을 제안했습니다. 엔지니어는 그 결과를 검토·보완하며 실제 구현에 집중했습니다.

Spec-Driven 운영 프로세스

마이다스인 DevOps팀은 Kiro와 함께 일하는 표준 프로세스를 정의했습니다. 모든 작업은 ‘코드부터 시작하지 않는다’는 원칙 아래, Spec → Plan → Checklist → Build 순서로 진행되었습니다.

1단계: Spec — 요구사항을 하나의 문서로 정의

먼저 무엇을, 왜 지금 해야 하는지를 하나의 문서로 명확히 정리합니다. 기술적 목표뿐 아니라 범위(Scope)·제약(Constraints)·성공 기준까지 문서화 하여 Kiro가 이해할 수 있는 컨텍스트를 제공합니다.

예를 들어, 파라미터 생성/수정 시 데이터 정합성 보장을 위한 토큰 기반 검증 기능의 API와 흐름을 정의할 때는 다음과 같은 형태로 Spec을 작성했습니다.

# spec/token-management.md

## Context
- 파라미터 생성/수정 시 중복 요청, 무효 요청 발생 가능
- 검증 없이 바로 처리 시 데이터 정합성 문제

## Goal
- 토큰 기반 2단계 검증 (발급 → 사용)
- 무효/만료 토큰 요청 차단

## Scope
- Spring API: 토큰 발급/검증/소비 서비스
- React: 토큰 기반 API 호출 흐름

## Constraints
- 토큰 TTL 10분
- Redis 기반 저장

Kiro의 역할:

이렇게 요구사항을 문서화 하여 제공하면 Kiro에게 Context로 제공하면 단순한 코드 초안이 아닌 다음과 같은 결과물을 제안했습니다:

• 규칙 정의 스키마 자동 생성
• 검증 로직 초안 제안
• 적용 순서 및 의존성 분석

2단계: Plan — AI가 설계안 제시

Kiro는 Spec을 문서로 정의하여 Context로 제공 할 때 추가로 “무엇을 우선 구현할지, 어떤 순서로 접근할지”를 정리해서 제공합니다. 이것은 단순히 할 일 목록을 나열하는 게 아니라, Why → How → Risk 구조로 작업 방향을 정리하고, 우선순위·의존성·검증 포인트를 담은 Rule을 함께 제공해 Kiro가 Plan을 생성하는 기준으로 작동합니다.

# plan/token-management.plan.md

## Why → How
- Why: 검증 없는 요청으로 데이터 정합성 문제 발생
- How: 토큰 기반 2단계 처리 (발급 → 검증 → 소비)

## Priorities
- P0: 토큰 발급/검증/소비 API + Controller 연동
- P1: 만료/무효 예외 처리, 재발급 로직
- P2: 재시도 토큰, 대기열 관리

## Risks / Deps
- Redis 장애 시 토큰 검증 불가 → fallback 처리 필요
- 토큰 TTL 만료 시 UX 저하 → 프론트 만료 안내 필요

Kiro의 역할:

• 우선순위 기반 작업 흐름 초안 자동 구성
• 리스크 식별 및 완화 방안 제안
• 의존성 분석 및 병렬 작업 가능 영역 식별

3단계: Checklist — 실행 조건과 완료 기준 명시

Kiro가 Spec과 Rule을 기반으로 생성한 Plan을 바탕으로, 엔지니어는 실제 작업 전 준비조건(DoR, Definition of Ready)과 완료조건(DoD, Definition of Done)을 구체화했습니다. 이 단계에서는 작업 범위와 성공 기준을 명확히 합의하고, 검증 가능한 기준으로 마무리를 정의합니다.

# checklist.md
## P0 (필수)
### Backend
- [ ] Redis 연결 설정
- [ ] 토큰 서비스 (발급/검증/소비)
java
public String generateValidationToken() {
   String token = UUID.randomUUID().toString();
   redisTemplate.opsForValue().set("parameta:validation:" + token, "validated", Duration.ofMinutes(10));
   return token;
}
- [ ] Controller 연동
- [ ] 만료/무효 예외 처리
- [ ] 통합 테스트

### Frontend
- [ ] API 타입 정의
- [ ] 토큰 기반 호출 훅
typescript
const { data: { validationToken } } = await apiClient.post('/validate', params);
await apiClient.post('/parameters', { ...params, validationToken });
- [ ] 만료 시 재발급 처리
- [ ] E2E 테스트

## 완료 기준
- [ ] 기능: P0 100% 통과
- [ ] 타입: TS 에러 0개
- [ ] 테스트: 통합 + E2E 성공
- [ ] 성능: < 500ms

이렇게 Checklist를 정리함으로써 “무엇을 끝내야 완료라 할 수 있는가”를 팀이 명확히 공유할 수 있습니다. 또한 각 항목이 문서로 자동 기록되기 때문에, 작업이 중간에 끊겨도 다음 담당자가 그 시점부터 바로 이어서 진행할 수 있습니다.

4단계: Build — 구현·테스트·배포

Build 단계에서는 Kiro가 생성한 코드 초안을 기반으로 구현을 진행했습니다. 기존 코드베이스를 분석해 재사용 가능한 컴포넌트를 식별하고, 신규 로직의 조건 분기와 예외 처리 구조를 Q Developer의 제안을 참고해 작성했습니다.

테스트 단계에서는 단위 테스트 케이스 자동 생성과 엣지 케이스 시나리오 제안을 활용했습니다.

배포 후에는 애플리케이션 부팅 로그를 Q Developer로 분석해 병목 구간을 식별하고, Probe 설정 최적화와 부팅 시간 단축을 위한 개선 포인트를 도출했습니다.

구현 전 과정에서 기존 레포지토리의 설계 원칙과 컨벤션을 유지하며, Q Developer의 제안을 검토 후 선택적으로 반영했습니다.

Kiro의 역할:

– 기존 코드베이스 분석을 통해 재사용 가능한 컴포넌트와 신규 구현 영역 식별
– 단위 테스트 케이스 및 엣지 케이스 시나리오 자동 생성
– 애플리케이션 부팅 로그 분석을 통한 성능 병목 구간 식별 및 최적화 방안 제안

Internal Developer Platform: MUIN

표준화된 AWS 인프라를 기반으로, 단 두 명의 DevOps 엔지니어가 셀프서비스 플랫폼 MUIN을 직접 설계했습니다.

MUIN은 단순한 인프라 관리도구가 아닌 AI 코드 어시스턴트 Kiro를 활용해, 개발자가 스스로 개발 및 운영을 위한 인프라스트럭처를 구성하고 리소스를 관리할 수 있는 Internal Developer Platform(IDP)으로 설계되었습니다.

이 플랫폼의 개발은 앞서 설명한 Spec → Plan → Checklist → Build 구조를 그대로 적용했습니다. 요구사항을 문서로 정의하고, AI가 생성한 초안을 검토·보완한 뒤 빌드하는 과정을 반복하면서 기획–개발–검증이 하루 안에 순환되는 개발 리듬이 자리 잡았습니다.

참고: Kiro는 개발자의 코드를 대신 작성하지 않았습니다. 대신 표준화된 스펙을 이해하고, 다음 단계의 작업 계획·검증 포인트·체크리스트 초안을 빠르게 제시하는 조력자 역할을 수행했습니다. 덕분에 단 두 명의 엔지니어로도 완전한 플랫폼 개발 사이클을 안정적으로 반복할 수 있었습니다.

MUIN이 해결한 Pain Point

플랫폼 구축 전, 개발자들은 단순한 운영 요청조차 DevOps 팀에 직접 티켓을 등록하고 대기해야 했습니다.

– 환경별 파라미터 수정 요청 처리에 평균 30분 이상 소요
– 테스트 서버 스케줄링 요청으로 하루 수십 건의 Slack 메시지 발생
– 변경 이력 관리가 사람 중심의 수동 기록에 의존

MUIN을 통해 이러한 업무가 플랫폼 내부 기능으로 자동화되었습니다.

이로써 개발자는 버튼 한 번으로 서버를 제어하고, Parameter Store 변경은 승인·감사 로그가 자동 기록됩니다.

기술 변화에서 문화 혁신으로

Amazon EKS 전환과 Kiro 기반 IDP 구축은 단순한 기술 개선이 아니었습니다. 이 경험은 팀의 일하는 방식, 협업 구조, 그리고 ‘개발자가 일하는 문화’ 자체를 변화시켰습니다.

작업 방식의 변화

Lean Ops 성과

조직 전반으로의 확산

이러한 변화는 DevOps 팀의 혁신을 넘어, 조직 전체가 더 빠르고 유연하게 움직일 수 있는 문화적 전환으로 이어졌습니다.

미래 로드맵

MUIN은 앞으로 애플리케이션 환경 변수 관리, 인증, 스케일링 모듈을 고도화하고 보안과 거버넌스를 내재화해 그룹 전체의 DevEx(Developer Experience) 표준 플랫폼으로 확장할 예정입니다. 이를 통해 단일 서비스 개선을 넘어 전사적 개발자 경험 혁신과 운영 성숙도 향상을 동시에 달성하겠습니다.

결론

마이다스인의 Amazon EKS전환과 MUIN 플랫폼 구축 여정은 단순한 기술 마이그레이션이 아니었습니다. Kiro를 활용한 Spec-driven 작업 및 운영 프로세스를 통해, 작은 팀이 큰 임팩트를 낼 수 있는 구조를 만들었습니다.

AWS CEO Matt Garman은 AI의 핵심 가치에 대해 이렇게 말했습니다:

"A key appeal of AI lies in taking away the 'toil' … Equipping developers with the technology will enable them to focus on the things that they're excited about."— ITPro, 2024

AI는 개발자를 대체하는 존재가 아니라, 반복적이고 가치가 낮은 작업을 덜어내어 사람이 진짜 집중해야 할 일에 에너지를 쓰게 하는 기술입니다. 마이다스인은 이 철학을 증명하기 위해 앞으로 계속 노력할 것입니다.