aws-cdk

3 개의 포스트

aws3분 읽기큐레이션 요약

AWS CloudFormation Express 모드로 인프라 배포를 최대 4배 가속화하세요 | Amazon Web Services

AWS CloudFormation Express mode는 리소스가 완전히 안정화될 때까지 기다리지 않고 설정 적용이 확인되는 즉시 배포를 완료해, 반복적인 인프라 개발 속도를 최대 4배 높이는 기능이다. 리소스 안정화는 백그라운드에서 계속 진행되며, 일시적인 프로비저닝 실패는 CloudFormation이 자동 재시도한다. 다만 트래픽 전환이나 테스트 전에 리소스의 완전한 운영 가능 상태가 필요하다면 기존 Standard 모드를 사용해야 한다. ## Express mode의 동작 방식 - Standard 모드는 리소스 설정 적용 후 안정화 검사를 수행한 뒤 배포를 완료한다. - Express mode는 설정이 적용되었다고 CloudFormation이 확인하면 안정화 검사를 기다리지 않고 배포를 완료한다. - 배포 완료 이후에도 리소스는 백그라운드에서 계속 운영 상태로 전환된다. - 의존 리소스에서 일시적인 오류가 발생하면 동일 스택 내에서 CloudFormation이 자동으로 재시도한다. - 리소스 프로비저닝 방식 자체를 바꾸는 것이 아니라, CloudFormation이 배포 완료를 보고하는 시점만 앞당긴다. ## 적합한 사용 사례 - 인프라 설정을 반복적으로 수정하는 개발 및 실험 workflow - 애플리케이션의 개별 구성 요소를 빠르게 테스트하는 경우 - AI 도구를 활용한 인프라 개발처럼 1분 이내의 피드백이 필요한 경우 - 리소스가 완전히 안정화되기 전에 다음 개발 작업을 진행해도 되는 프로덕션 환경 ## 배포 시간 단축 사례 - SQS 큐와 DLQ 생성: - Standard mode: 약 64초 - Express mode: 최대 약 10초 - 네트워크 인터페이스가 연결된 Lambda 함수 삭제: - Standard mode: 약 20~30분 - Express mode: 벤치마크 기준 최대 약 10초 실제 시간은 리소스 종류와 환경에 따라 달라질 수 있지만, 안정화 대기 시간이 긴 작업일수록 효과가 크다. ## 활성화 방법과 롤백 설정 - 콘솔에서 스택 생성 시 **Stack deployment options → Express mode → Enable**을 선택한다. - AWS CLI, SDK, CDK, Kiro 같은 AI 도구에서도 사용할 수 있다. - CLI에서는 `--deployment-config`에 `EXPRESS` 모드를 지정한다. ```bash aws cloudformation create-stack \ --stack-name my-app \ --template-body file://template.yaml \ --deployment-config '{"mode": "EXPRESS", "disableRollback": true}' ``` - Express mode는 빠른 반복 작업을 위해 기본적으로 롤백이 비활성화된다. - 프로덕션 환경에서 롤백을 사용하려면 `disableRollback: false`로 설정한다. - 롤백을 비활성화할 경우 실패한 배포에 대한 모니터링과 정리 절차를 별도로 마련해야 한다. ## 점진적 인프라 개발 Express mode는 리소스를 하나씩 추가하는 방식의 개발에 적합하다. - 1단계: IAM 역할 배포 - 2단계: Lambda 함수 추가 - 3단계: SQS 큐와 이벤트 소스 매핑 추가 - 각 단계에서 `create-stack` 또는 `update-stack`과 함께 Express mode를 사용할 수 있다. - IAM 역할 템플릿은 최소 권한 원칙을 따라야 한다. ## CDK 및 CloudFormation 호환성 - AWS CDK에서는 다음 명령으로 활성화한다. ```bash cdk deploy --express ``` - 기존 CloudFormation 템플릿을 수정하지 않아도 된다. - 변경 세트, 중첩 스택 등 기존 CloudFormation 기능을 지원한다. - 부모 스택에서 Express mode를 활성화하면 중첩 스택에도 적용된다. - 리소스가 완전히 운영 가능해진 뒤 트래픽을 전환하거나 테스트해야 한다면 Standard 모드를 유지해야 한다. ## 제공 범위 - 모든 AWS 상용 리전에서 추가 비용 없이 제공된다. - 리전별 지원 현황과 향후 계획은 AWS 리전별 기능 문서에서 확인할 수 있다. 개발 중 빠른 피드백이 중요하다면 Express mode를 우선 사용하되, 롤백 비활성화에 따른 정리 및 모니터링 체계를 준비하는 것이 좋다. 운영 트래픽이나 테스트가 리소스의 완전한 안정화에 의존한다면 기존 Standard 모드가 더 안전하다.

원문 읽기(새 탭에서 열림)
aws4분 읽기큐레이션 요약

AWS MCP 서버가 정식 출시되었습니다 | Amazon Web Services

AWS MCP Server는 AI 에이전트가 기존 IAM 자격 증명을 사용해 AWS 서비스에 안전하게 접근하도록 해 주는 관리형 원격 MCP 서버다. 최신 AWS 문서 검색, 15,000개 이상의 API 호출, 샌드박스 스크립트 실행을 제공해 에이전트가 오래된 학습 데이터나 과도한 권한 정책에 의존하는 문제를 줄인다. 특히 IAM 기반 권한 통제, CloudWatch·CloudTrail 감사, AWS 서비스별 Skills를 통해 프로덕션 환경에 적합한 AWS 자동화를 지원한다. ## AI 에이전트가 AWS에서 겪는 문제 - 모델의 학습 데이터가 오래되면 최신 서비스와 기능을 알지 못한다. - 예를 들어 2025년에 출시된 Amazon S3 Vectors를 학습하지 못한 모델은 S3에 임베딩을 저장하는 일반적인 방법만 제시할 수 있다. - 인프라를 구성할 때 AWS CDK나 CloudFormation보다 AWS CLI 명령을 우선적으로 생성하는 경향이 있다. - 필요 이상으로 광범위한 IAM 정책을 만들어 보안 위험을 키울 수 있다. - 데모 수준에서는 동작하더라도 최신 정보, 최소 권한, 운영 표준을 반영하지 못해 프로덕션 배포에는 부적합할 수 있다. ## AWS MCP Server의 핵심 도구 - `call_aws` - 기존 IAM 자격 증명을 사용해 15,000개 이상의 AWS API 작업을 실행한다. - 새 AWS API가 출시되면 며칠 내에 지원될 예정이다. - `search_documentation` - 실행 시점에 최신 AWS 공식 문서와 모범 사례를 검색한다. - `read_documentation` - 검색된 문서의 구체적인 내용을 읽어 에이전트가 최신 정보를 바탕으로 답변하도록 한다. - 이 도구들은 개별 AWS 서비스를 수천 개의 도구로 노출하지 않고 소수의 고정된 인터페이스로 제공해 모델 컨텍스트 사용량과 환각을 줄인다. ## GA 버전의 보안·효율성 개선 - IAM 컨텍스트 키를 지원해 별도의 MCP 서버용 IAM 권한 없이 표준 IAM 정책으로 세밀한 접근 제어를 설정할 수 있다. - 문서 검색은 인증 없이 사용할 수 있다. - 상호작용당 필요한 토큰 수를 줄여 복잡한 다단계 작업의 비용과 컨텍스트 부담을 낮췄다. - 에이전트 권한은 IAM 정책이나 SCP(Service Control Policy)로 제한할 수 있다. - 예를 들어 사용자는 리소스를 변경할 수 있지만 MCP 서버는 읽기 전용 작업만 수행하도록 분리할 수 있다. - `AWS-MCP` 네임스페이스의 CloudWatch 지표로 에이전트 호출을 사람의 직접 호출과 구분해 관찰할 수 있다. - CloudTrail은 실제 AWS API 호출에 대한 전체 감사 기록을 제공한다. ## 샌드박스 기반 `run_script` - 에이전트가 짧은 Python 스크립트를 작성해 AWS 서버 측 샌드박스에서 실행할 수 있다. - 샌드박스는 IAM 권한을 상속하지만 네트워크 접근과 로컬 파일 시스템·셸 접근은 차단된다. - 여러 AWS API를 순차적으로 호출하고 결과를 필터링·계산하는 작업을 한 번의 왕복으로 처리할 수 있다. - 그 결과 API 호출 지연과 모델 컨텍스트 사용량을 줄일 수 있다. - 로컬 환경 전체에 대한 접근 권한을 주지 않고도 데이터 처리 능력을 제공한다. ## Agent SOP에서 Skills로의 전환 - Skills는 에이전트가 자주 실수하는 작업에 대해 AWS 서비스 팀이 관리하는 검증된 지침과 모범 사례를 제공한다. - 에이전트가 더 적은 토큰으로 빠르고 일관되게 작업하도록 돕는다. - AWS 서비스별 지침을 별도 도구로 무분별하게 늘리지 않고 큐레이션된 지식으로 제공한다. - 짧고 예측 가능한 도구 목록을 유지해 환각을 줄이고 에이전트의 작업 집중도를 높인다. ## 최신 문서 검색을 통한 실제 효과 - 모델만 사용하면 Amazon S3 Vectors가 학습 데이터 이후에 출시되었기 때문에 해당 기능을 제안하지 못한다. - AWS MCP Server를 연결하면 `search_documentation`이 최신 AWS 문서를 조회한다. - 동일한 질문에 대해 Amazon S3 Vectors가 임베딩 저장을 위한 전용 서비스라는 정확한 답변을 얻을 수 있다. - 즉, 모델 자체를 재학습하지 않고도 실행 시점의 AWS 지식으로 최신 서비스와 API를 활용할 수 있다. ## 인증과 클라이언트 연동 - AWS MCP Server는 IAM과 IAM SigV4 인증을 사용한다. - MCP 클라이언트가 OAuth 2.1만 지원하는 경우 오픈 소스 `mcp-proxy-for-aws` 프록시를 사용해 로컬 AWS 자격 증명과 MCP를 연결할 수 있다. - 예시 설정은 Claude Code에서 다음과 같이 등록한다. ```bash claude mcp add-json aws-mcp --scope user \ '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}' ``` - `--scope user`는 노트북의 모든 프로젝트에서 서버를 사용할 수 있게 한다. - 엔드포인트는 미국 동부 또는 유럽 리전에 위치하지만, API 호출 자체는 모든 AWS 리전에 수행할 수 있다. - Claude Code, Kiro, Cursor, Codex 등 MCP 호환 클라이언트에서 사용할 수 있다. ## 요금과 제공 리전 - AWS MCP Server 자체에는 추가 요금이 없다. - 사용자가 부담하는 비용은 생성한 AWS 리소스 비용과 해당 데이터 전송 비용이다. - 서비스 엔드포인트는 현재 미국 동부(버지니아 북부)와 유럽(프랑크푸르트) 리전에서 제공된다. 에이전트에 AWS 접근 권한을 부여할 때는 관리자 권한 대신 읽기 전용 또는 작업별 최소 권한 IAM 정책부터 적용하는 것이 좋다. 최신 문서 검색과 `run_script`를 활용하면 에이전트의 정확성과 효율성을 높이면서도 로컬 시스템과 AWS 리소스에 대한 접근 범위를 분리할 수 있다.

원문 읽기(새 탭에서 열림)
toss원문

쓰기 쉬운 Toss Front SDK (새 탭에서 열림)

좋은 SDK는 단순히 기능을 제공하는 것을 넘어, 사용자가 올바른 방법으로만 사용하도록 유도하고 휴먼 에러를 구조적으로 방지해야 합니다. 이를 위해 복잡한 내부 로직을 사용자의 ‘의도’를 중심으로 추상화하는 퍼사드(Facade) 패턴을 적용하여, 사용자가 최소한의 코드로도 안정적인 결과물을 만들 수 있는 환경을 구축해야 합니다. 고수준 인터페이스를 통해 대다수의 유즈케이스를 해결하면서도, 특수한 상황을 위한 저수준 인터페이스라는 ‘탈출구’를 마련하는 것이 설계의 핵심입니다. ### 의도 기반의 퍼사드(Facade) 패턴 재정의 - 퍼사드 패턴의 본질은 단순히 복잡한 기능을 숨기는 것이 아니라, 내부 구현을 ‘사용자의 의도(Intent)’를 기준으로 재구성하는 데 있습니다. - "서버를 열고, 핸들러를 등록하고, 에러를 처리한다"는 개별적인 절차를 "서버를 시작한다"는 하나의 자연스러운 목적으로 통합합니다. - 인증, 재시도 로직, 상태 관리, 클린업(Cleanup) 등 인지 부하를 일으키는 요소들을 SDK 내부로 은닉하여 사용자 측의 실수를 원천 차단합니다. ### AWS CDK 사례를 통한 추상화 계층의 이해 - AWS CDK의 L1 구문은 리소스의 모든 속성을 제어하는 저수준(low-level) 인터페이스인 반면, L2 구문은 직관적인 의도 기반의 고수준(high-level) 추상화를 제공합니다. - S3 버킷 생성 시 L1은 모든 세부 설정을 직접 챙겨야 하지만, L2는 자주 쓰이는 옵션을 간단한 프로퍼티로 제공하고 내부적인 변환은 SDK가 담당합니다. - SDK 설계 시에도 이와 같이 복잡한 주변 구성을 자연스러운 API 흐름으로 이어 붙일 수 있도록 설계해야 합니다. ### 파레토 법칙을 적용한 인터페이스 설계 - 전체 사용 사례의 80%에 해당하는 공통 유즈케이스는 고수준 인터페이스(Facade)를 통해 워크플로우를 자동화하여 제공합니다. - 나머지 20%의 특수한 요구사항이나 세밀한 제어가 필요한 상황을 위해 저수준 API인 ‘탈출구(Escape Hatch)’를 함께 유지합니다. - 이러한 이중 구조는 단기적인 개발자 경험(DX) 향상뿐만 아니라, SDK의 장기적인 호환성과 확장성을 보장하는 핵심 전략이 됩니다. ### 편의성과 유연성 사이의 트레이드오프 관리 - 추상화 수준이 높아지면 사용자는 편리해지지만, SDK 내부에서는 더 정교한 오케스트레이션 로직을 관리해야 하는 유지보수 비용이 발생합니다. - 세밀한 제어가 차단될 경우 특정 상황에서 제약이 될 수 있으므로, 고수준 인터페이스에만 의존하지 않고 저수준 조작이 가능한 균형점을 찾는 것이 중요합니다. - 결과적으로 잘 설계된 인터페이스는 사용자가 별도의 가이드 없이도 올바른 패턴을 유지하며 메모리 누수와 같은 장애 상황을 방지하게 합니다. 단순히 "동작하는" SDK를 만드는 단계를 넘어, 사용자가 직관적으로 이해하고 안전하게 사용할 수 있는 "쓰기 쉬운" SDK를 지향해야 합니다. 이를 위해 사용자의 의도를 최우선으로 고려한 추상화 계층을 설계하고, 대다수의 편의성과 소수의 유연성을 동시에 잡을 수 있는 다층적 구조를 도입할 것을 권장합니다.