Kiro와 함께 디지털 배지 시스템 구축 (및 Amazon ECS Express Mode)

Source: Dev.to

시작하기

저는 Kiro를 사용하여 앱을 개발합니다. 처음에 필요했던 것은 Amazon ECS Express Mode에 배포하기 위해 프로젝트를 준비하는 방법이었습니다.

1. ECS MCP 서버 추가 – 기억이 흐릿할 때는 보통 문서를 참고하지만, 이제는 AI‑코딩 도구에게 무거운 작업을 맡깁니다. 저는 Kiro 세션에 Amazon ECS MCP Server를 추가했습니다:

{
  "mcpServers": {
    "awslabs.ecs-mcp-server": {
      "command": "uvx",
      "args": ["--from", "awslabs-ecs-mcp-server", "ecs-mcp-server"]
    }
  }
}

애플리케이션‑준비도 평가

다음으로 Kiro에게 준비도 검사를 요청했습니다:

프롬프트: “Amazon ECS MCP Server를 사용해 이 애플리케이션을 Amazon ECS Express 모드에 배포하기 위한 준비도 검사를 제공해 주세요.”

MCP Server 도구를 신뢰한 뒤, Kiro는 간결한 보고서를 반환했습니다. 보고서에는 변경이 필요한 세 가지 발견 사항이 강조되었습니다.

그 후 Kiro는 컨텍스트‑특정 체크리스트(IAM 정책, 서비스 권한 등)를 제공하고 배포 스크립트를 생성했습니다. 스크립트를 검토하면서 잠재적인 문제를 발견했습니다:

앱은 BASE_URL(예: 로컬 개발 시 127.0.0.1:5001)을 기대합니다. 서비스가 ECS Express에서 실행될 때까지 DNS 이름을 알 수 없습니다.

이에 대해 Kiro에게 다음과 같이 물었습니다:

프롬프트: “아직 DNS가 등록되지 않아 BASE_URL을 어떻게 설정해야 할지 모르겠어요. 도와줄 수 있나요?”

Kiro는 코드를 업데이트하고 배포 스크립트를 동적으로 처리하도록 수정했습니다.

Source:

Deploying to Amazon ECS Express

생성된 스크립트를 실행했습니다. 리소스가 프로비저닝되고 서비스가 시작되었지만 배포가 멈춘 것처럼 보였습니다. CloudWatch 로그를 확인해 보니 다음 오류가 나타났습니다:

exec /bin/sh: exec format error

문제는? 내 Mac이 ARM‑based 컨테이너 이미지(aarch64)를 빌드한다는 점이었습니다. 스크립트가 기본값으로 amd64를 사용해 형식이 맞지 않았습니다.

Dockerfile 및 빌드 명령에서 아키텍처를 aarch64로 수정했습니다. 수정 후 서비스가 정상적으로 시작되었습니다.

API 문서를 빠르게 다시 확인해 보니 변경 사항이 맞는 것이 확인되었고, 배포가 최종적으로 성공했습니다.

요약

Amazon ECS Express Mode로 컨테이너화된 앱을 배포하는 것이 이제 Kiro의 AI‑지원 워크플로우 덕분에 반복 가능한 프로세스가 되었습니다. 비슷한 서비스를 구축하고 있다면 Strands Agent와 ECS MCP Server를 한 번 사용해 보세요 – 수많은 수작업을 크게 줄여줄 것입니다.

Amazon ECS Express Mode – 내 경험

그때는 MCP 서버가 이를 잡아낼 수 있었습니다 (현재는).

Amazon ECS Express Mode는 초기 배포를 위해 amd64 인스턴스 유형을 사용합니다. Kiro가 이미 비즈니스를 처리해 주었고, 빌드 스크립트를 업데이트하여 amd64 이미지가 생성되도록 했습니다.

Note! 더 많이 알고 있는 사람들과 이야기를 나눈 결과, Amazon ECS Express Mode에서 aarch64 인스턴스를 사용할 수 있습니다. 서비스를 만든 후에는 작업 정의 파일(컨테이너를 배포하기 위해 필요한 설정을 정의하는 핵심 구성 파일 – task.json)을 수정하여 AWS Graviton 인스턴스 유형을 지원하도록 변경할 수 있습니다. 실제로는 AWS Fargate가 이 작업을 수행하고 있습니다.

스크립트가 완벽하지는 않았습니다

예를 들어, 초기 성공적인 배포 후에 스크립트를 사용해 애플리케이션을 업데이트하려고 했을 때 다음과 같은 오류가 발생했습니다:

An error occurred (InvalidParameterException) when calling the CreateExpressGatewayService operation: 
Unable to Start a service that is still Draining.

Kiro는 배포 스크립트를 빠르게 조정했습니다(스크립트가 매번 update‑service 메서드 대신 동일한 서비스를 새로 만들려고 했기 때문). 모든 코드는 확인할 수 있으며, 레포는 이 글의 마지막에 공유합니다.

내가 배운 것

1. Amazon ECS Express Mode는 의견이 반영된 기본값을 제공하여 컨테이너 워크로드를 빠르게 배포할 수 있게 해 주지만, 여전히 Amazon ECS입니다.
   • 기존 ECS 리소스 집합과 마찬가지로 모든 기능에 접근할 수 있습니다.
   • 맞춤 도메인 및 인증서 구성과 같은 배포 후 작업도 간단합니다 – 고급 커스터마이징 가이드를 참고하세요.
   • 필요하거나 원한다면 여전히 task‑definition JSON 파일을 편집할 수 있습니다.
2. 인스턴스 유형 기본값 – 기본적으로 Express Mode는 amd64를 사용하고 aarch64는 사용하지 않습니다.
   • 많은 워크로드가 AWS Graviton으로 이동하고 있기 때문에, 서비스 생성 API를 사용하거나 배포 후 클러스터를 업데이트하여 Graviton 인스턴스로 전환할 수 있다는 점을 알아두면 유용합니다.
3. Amazon ECS MCP Server는 훌륭합니다 – 이 서버는 Express Mode를 이해하고 작업하는 데 필요한 모든 것을 제공했으며, 해당 기능이 아직 새로웠음에도 큰 도움이 되었습니다.

결론

• 출력을 검토하고 누락된 부분을 찾아보세요.
• 명확성을 얻기 위해 올바른 질문을 (프롬프트를 통해) 하세요.

귀하의 역할은 작동하는 코드를 제공하는 데 있어 여전히 중요합니다.

Amazon ECS Express Mode에 대한 나의 경험은 훌륭했습니다 – 이는 AWS에 애플리케이션을 배포하는 것을 간단하고 빠르게 만들어 줍니다. Kiro와 Amazon ECS MCP Server를 결합하면, 이제 애플리케이션을 구축하고 배포하는 새로운 기본 접근 방식을 갖게 되었습니다.

리소스

• 코드: 전체 예제는 이 GitHub 저장소에 있습니다 – digital‑badge‑vending‑demo.
• 데모 비디오: 프로세스의 짧은 비디오를 여기에서 확인할 수 있습니다.
• 문서: Amazon ECS Express Mode 문서를 확인하세요.
• Kiro CLI: 무료로 시작하세요 – 여기서 다운로드.
• Kiro CLI 워크숍: Kiro가 처음이신가요? 포괄적인 안내를 위해 Kiro CLI 워크숍을 따라해 보세요.
• 피드백: 이 글이 도움이 되었다면, 30초짜리 피드백 양식을 작성해 주세요. 영원히 감사하겠습니다.