AWS 기술 블로그

Category: AWS Fargate

Amazon ECS 실행 구조와 선택 기준 – 1부: 컴퓨트와 실행 형태

AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch type)이 변경되지 않아 어려움을 […]

Amazon ECS 실행 구조와 선택 기준 – 2부: 배포 전략과 네트워크, 설계 상한

이 글은 Amazon ECS 실행 구조와 선택 기준을 다루는 시리즈의 2부입니다. 1부에서는 launch type은 호환되는 실행 환경을 표시하는 용도로만 사용하고 실제 실행은 용량 공급자(capacity provider)로 구성한다는 원칙을 바탕으로, Fargate와 ECS Managed Instances, EC2에 걸친 컴퓨트 선택과 Express Mode부터 예약 Task까지의 실행 형태를 살펴봤습니다. 2부에서는 남은 선택지를 다룹니다. 6종으로 증가한 배포 전략에서 시작해 네트워크와 스토리지, 플랫폼 […]

실리콘투의 사내 지식 MCP 게이트웨이 구축기

실리콘투는 한국의 뷰티 브랜드를 전 세계 고객에게 유통하는 글로벌 플랫폼 기업입니다. 수많은 브랜드와 상품, 국가별 물류가 실시간으로 맞물려 돌아가고, 이 방대한 흐름을 CMS, WMS, OMS를 비롯한 여러 사내 시스템이 나눠 맡습니다. 사업이 커질수록 업무 규칙도 함께 불어났고, 그 규칙은 저장 프로시저(SP, Stored Procedure. 데이터베이스에 넣어 두고 불러 쓰는 SQL 로직 묶음), 소스 코드, 그리고 여기저기 […]

Amazon Bedrock에서 LLM 게이트웨이의 두 사각지대 메우기: 사라진 호출자와 흐려진 모델 거버넌스

Amazon Bedrock 앞에 LLM 게이트웨이(이하 게이트웨이)를 두면 편의와 통제를 얻지만, 그 대가로 Amazon Bedrock이 보는 호출자 신원과 모델별 관측 지점이 게이트웨이 뒤로 흐려지는 사각지대가 생깁니다. 이 글은 잘 알려진 레퍼런스 아키텍처를 출발점으로, 그 사각지대를 Amazon Bedrock 네이티브 기능으로 보완하는 방법 (호출자 감사 추적과 모델별 관측 및 거버넌스)을 다룹니다. <Claude Code → LLM 게이트웨이 → Amazon Bedrock> […]

에잇퍼센트의 Kiro CLI 기반 Amazon ECS 현대화 여정

이 블로그는 에잇퍼센트와 AWS의 협업으로 작성되었습니다. 현업 운영을 병행하면서 2영업일 만에 레거시 서비스를 Amazon ECS로 전환하고, 월 운영 비용을 약 76% 절감할 수 있을까요? 에잇퍼센트는 AI 코딩 에이전트 Kiro CLI와 오픈소스 AI-Driven Modernization Prompt Sets를 결합해 이를 실현했습니다. 이번 글에서는 에잇퍼센트가 AWS Lift-On 프로그램의 지원을 받아, 소규모 백엔드 팀이 기능 개발과 장애 대응을 병행하면서도 Amazon […]

AWS SaaS Builder Toolkit을 활용한 엔터프라이즈 IdP 솔루션의 SaaS 전환 사례

온프레미스 환경에서 고객사마다 개별 설치·운영하던 IAM/MFA 솔루션을 Software as a Service (SaaS)로 전환하는 것은 단순한 기술 마이그레이션이 아닙니다. 제품을 판매하고 가치를 전달하는 방식 자체를 바꾸는 일입니다. AirCUVE는 AWS SaaS Builder Toolkit(SBT)을 활용해 단 3개월 만에 V-FRONT를 멀티테넌트 SaaS 플랫폼으로 전환하고 AWS Marketplace에 등재했습니다. 이 글에서는 그 기술적 여정과 아키텍처 설계 원칙을 공유합니다. 1. V-FRONT 소개 […]

하네스 엔지니어링으로 본 Deep Insight – 로컬 개발에서 프로덕션 운영까지의 설계 여정

AI에게 단순히 “잘 해봐”라고 시키는 것과, AI가 스스로 만들고 평가하고 개선하는 Agentic 시스템을 설계하는 건 완전히 다른 결과물을 만들어냅니다. AWS Korea SA Team은 Agentic AI 시스템을 개발할 때 마주하는 다양한 기술적 챌린지들을 직접 풀기 위해 ‘Deep Insight’, 사용자가 업로드한 CSV 데이터와 분석 질문을 받아 최종 DOCX 리포트를 생성하는 프로덕션 Multi-Agent 시스템을 개발했고, 세 편의 블로그 […]

Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법

AI 에이전트를 프로덕션 수준으로 개발하는 것과 단순 데모를 만드는 것은 전혀 다른 문제입니다. 간단한 질의응답은 잘 작동하지만, 데이터 분석 후 리포트를 생성하는 것처럼 여러 단계를 거치는 실제 업무는 Context Window 한계, 성능 저하, 비용 증가 등의 벽에 부딪힙니다. 이러한 문제를 해결할 수 있는 방법으로 다양한 Context Engineering 기법들이 제안되고 있지만, 실제로 어떻게 적용해야 하는지는 여전히 […]

프로덕션 Multi-Agent 시스템이 해결해야 할 5가지 문제 – Deep Insight 아키텍처로 배우는 실전 설계

AI Agent를 만드는 것 자체는 이제 어렵지 않습니다. 오픈소스 프레임워크와 클라우드 서비스 덕분에 에이전트 구축 자체는 수일 내에 가능해졌고, 툴 호출 몇 개, 프롬프트 몇 줄이면 그럴듯한 에이전트를 만들 수 있습니다. 그러나 파일럿을 넘어 실제 비즈니스에 적용하려는 순간, 많은 팀들이 비슷한 벽에 부딪힙니다. Agent를 프로덕션에 적용하려다가 막힌 분들이라면 다음 고민들에 공감하실 것입니다. “왜 에이전트가 우리 비즈니스 […]

당근의 AWS 기반 피처 플랫폼 구축 여정, Part 2: 피처 수집

해당 포스트는 당근의 김현호님, 서진형님, 권민재님과 함께 작성했으며, 이전에 AWS 글로벌 블로그에 포스팅한 영문 블로그와 동일한 내용입니다. 이 시리즈의 1부에서는 당근이 개발한 새로운 피처 플랫폼에 대해 다루었습니다. 이 플랫폼은 피처 서빙, 스트림 수집 파이프라인, 배치 수집 파이프라인의 세 가지 주요 구성 요소로 이루어져 있습니다. 또한 요구사항, 솔루션 아키텍처, 다단계 캐시를 활용한 피처 서빙에 대해 설명했습니다. […]