AWS 기술 블로그
채널코퍼레이션의 Amazon DynamoDB와 함께한 아키텍처 현대화 여정 – 3부
이 블로그는 Channel Corporation의 이해빈님, 박진영님과 함께 작성되었습니다. 채널코퍼레이션은 올인원 AI 메신저 ‘채널톡’을 운영하는 B2B SaaS 스타트업으로 Amazon DynamoDB의 수평 확장성, ACID 트랜잭션과 같은 특징을 활용해 빠르게 성장하는 비즈니스를 문제없이 수행하고 있습니다. 이 시리즈의 1부에서는 채널코퍼레이션이 Amazon DynamoDB를 선택한 이유와 Amazon DynamoDB에서 트랜잭션을 처리한 방법을 살펴보았습니다. 2부에서는 채널코퍼레이션이 두 가지 유형의 DynamoDB 스트림을 사용하여 이벤트 […]
가격 예측부터 입찰 전략까지, LG에너지솔루션의 Amazon Bedrock AgentCore 기반 ERCOT 분석 에이전트 구축기
– 박경수(AWS Solutions Architect), 장현태(AWS Solutions Architect), 백승연 (LG에너지솔루션, Product Owner), 최수아 (LG에너지솔루션, Data Scientist) “실시간으로 가격이 바뀌는 전력시장에서 최대 수익을 내려면 얼마에 입찰해야 할까? 그 가격을 예측하고 입찰 전략까지 분석해주는 에이전트가 있다면?” LG에너지솔루션 전력거래솔루션은 이 한 문장에서 출발했습니다. LG에너지솔루션은 배터리 셀부터 ESS(Energy Storage System)까지 아우르는 글로벌 배터리 기업입니다. 하지만 배터리의 가치는 배터리를 만드는 것에서 […]
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종으로 증가한 배포 전략에서 시작해 네트워크와 스토리지, 플랫폼 […]
삼성 계정 AIOps: AgentCore기반 AlOps의 실전 활용과 자율성 확장
지난 1부에서는 삼성계정 서비스의 멀티 에이전트 AIOps 시스템을 어떤 구조로 설계했고, 그 구조를 안정적으로 운영하기 위해 무엇을 뒷받침했는지, 그리고 그 위에서 자율성을 어떻게 조금씩 넓혀왔는지를 다뤘습니다. 이 글에서는 그 시스템이 실제 운영 현장에서 어떻게 쓰이고 있는지, 도입 전후로 업무가 어떻게 달라졌는지, 그리고 더 높은 수준의 자율운영으로 나아가기 위해 무엇을 준비하고 있는지를 다룹니다. 이 글은 2부작으로 […]
삼성 계정 AIOps: AgentCore기반 멀티 에이전트 운영 자동화 여정
삼성계정(Samsung Account)은 전 세계 약 21억 사용자에게 삼성 디바이스와 서비스를 연결하는 통합 인증 시스템입니다. Samsung Wallet, Bixby, SmartThings, Samsung Health를 비롯한 수많은 서비스가 삼성계정으로 사용자와 연결되며, 글로벌 대규모 트래픽을 365일 24시간 무중단으로 처리합니다. 이런 초대규모 서비스를 운영한다는 것은, 그만큼 방대한 인프라와 끊임없는 운영 업무를 동반한다는 뜻입니다. 멀티 리전·다계정 환경에 걸친 수많은 마이크로서비스, 매일 쏟아지는 모니터링 […]
Amazon EC2 Nitro V6의 Connection Tracking 유휴 타임아웃 변경 대응하기
주말 내내 트래픽이 없던 서비스에서 월요일 아침 첫 요청들만 유독 타임아웃으로 실패합니다. Karpenter가 노드를 교체한 뒤부터는 원인을 알 수 없는 연결 오류가 늘었는데, 부하 테스트를 아무리 돌려도 재현되지 않습니다. 최근 이런 증상을 겪었다면 애플리케이션 코드보다 먼저 확인할 것이 있습니다. 워크로드를 실행 중인 인스턴스 타입의 세대와 Nitro 버전입니다. 2025년 6월부터 출시되고 있는 Nitro V6 기반 인스턴스(m8i, […]
Amazon Quick으로 FinOps 업무 자동화하기
1. 클라우드 비용 가시성의 출발점 Cloud Intelligence Dashboards(CID)는 AWS Cost and Usage Report(CUR) 데이터를 Amazon Quick 위에 시각화하는 오픈소스 대시보드 프레임워크입니다. 그 핵심인 CUDOS(Cost and Usage Dashboards Operations Solution) 대시보드는 서비스·계정·리전·태그 등 다양한 차원에서 리소스 레벨까지의 세부 비용과 사용량을 한눈에 보여줍니다. CUDOS는 CUR 데이터를 Amazon S3에 저장하고 AWS Glue와 Amazon Athena로 변환한 뒤 Quick Sight의 […]
Claude Code 토큰 비용 최적화하기 – 2부: 캐시 경제학과 Amazon Bedrock 조직 비용 관리
Claude Code를 조직에 도입하면 개인의 습관만으로는 답할 수 없는 질문이 남습니다. 자리를 비웠다 돌아오면 첫 응답이 왜 유난히 느리고 비싼지, Amazon Bedrock으로 사용하는 조직에서는 누가 얼마나 쓰는지를 어디서 확인할 수 있는지 같은 질문입니다. 이 글은 Claude Code 토큰 비용 최적화 시리즈의 2부입니다. 1부(비용 구조와 세션 습관)에서는 비용이 컨텍스트 크기에 비례하고 실제 지불 단가는 프롬프트 캐싱(prompt […]
Claude Code 토큰 비용 최적화하기 – 1부: 비용 구조와 세션 습관
Claude Code를 팀에 도입하고 나면 비슷한 질문들이 찾아옵니다. 짧은 한 문장의 질문만 했는데 토큰 사용량이 왜 이렇게 높은지, 하루가 끝날 때쯤이면 세션이 왜 이렇게 무거워져 있는지 같은 의문입니다. Claude Code는 메시지를 보낼 때마다 시스템 프롬프트, 프로젝트 컨텍스트, 지금까지의 전체 대화 이력을 다시 전송하고, 비용은 그 컨텍스트 크기에 비례합니다. 그리고 실제로 지불하는 토큰 단가는 프롬프트 캐싱(prompt […]








