총 241개 글 · 원본 블로그 방문 →
AWS 클라우드 아키텍처와 서비스 소식을 한국어로 전하는 공식 블로그
이 글은 AWS Database Blog에 게시된 Running pgvector in production on Amazon Aurora PostgreSQL by Stefan Aichholzer 을 한국어 번역 및 편집하였습니다. Amazon Aurora PostgreSQL-Compatible Edition에서 pgvector를 실행하면 이미 익숙한 데이터베이스 위에 프로덕션 수준의 벡터 스토어를 구축할 수 있으며, Amazon Aurora의 운
소개 클라우드 전환을 가속화하는 조직들은 공통된 병목에 직면합니다. 바로 핵심 비즈니스를 지탱하는 레거시 시스템의 현대화(Modernization)입니다. 기업이 Oracle에서 Amazon Aurora PostgreSQL-Compatible Edition으로 마이그레이션할 때, 테이블, 인덱스, 뷰 같은 스키마 객체는 AWS Schema Conversion Tool(SCT)과 AWS DMS Schema Conversion으로 안정적으로 변환할
1부에서는 Amazon EKS의 GPU 노드에서 Gemma 4 31B를 vLLM으로 서빙할 때의 콜드 스타트를 다뤘습니다. 파드가 Ready가 되기까지의 시간을 428초에서 226초로 줄인 과정입니다. 스트리밍 로더로 가중치를 S3에서 직접 읽고 컴파일 캐시를 hostPath와 S3에 남기고 유휴 상태는 sleep/wake로 전환하는 구성이었습니다. 모델은 NVIDIA가 공개한 NVFP4 체크포인트 nvidia/Gemma-4-31B-IT-NVF
Gemma 4는 Google이 공개한 오픈 웨이트 모델 패밀리로, E2B부터 31B까지 5가지 크기에 텍스트와 이미지 입력(E2B, E4B, 12B는 오디오도 지원), 최대 256K 토큰 컨텍스트(E2B, E4B는 128K), 추론(thinking) 모드를 제공합니다. 그중 31B는 밀집(dense) 구조의 최상위 모델로, NVFP4(4비트 부동소수점)로 양자화한 가중치 약 31GiB가 96GB GPU 1개에 올라가는 대신 시작할 때마다 수십
이 글은 2026년 8월 19일 AWS Japan 블로그에 게재된 ‘株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon DynamoDB / Amazon ElastiCache Serverless for Valkey 活用事例’를 번역한 글입니다. 서론 주식회사 SEGA는 가정용 게임기, PC, 스마트폰용 게임의 기획, 개발, 판매, 운영을 중심으로, 다양한 콘텐츠와 상품을 전 세계에 제공하고 있습니다. SE
이 블로그는 GS리테일과 AWS의 협업으로 작성되었습니다. 이 글은 GS리테일의 전사 AI Gateway 구축 사례 1부: 인증·라우팅·계정 자동화 설계에 이어지는 두 번째 글입니다. 1부를 아직 보지 않으셨다면 먼저 읽어보시길 권해드립니다. 1부에서는 GS리테일 클라우드인프라팀이 사내 AI 도구 수요를 조직 차원에서 안전하게 받아내기 위해, 모든 AI 호출을 하나의 관문으로 모으는 전사 AI Gateway를 구축한 과정을 다뤘습니다. Clau
이 블로그는 GS리테일과 AWS의 협업으로 작성되었습니다. 다양한 AI 서비스를 안전하게 활용하기 위한 단일 운영 플랫폼 구축 수백 개 팀 계정의 AI 호출을 하나의 관문에서 인증·비용·쿼터 단위로 통제할 수 있을까요? 생성형 AI는 이제 기업의 업무 환경에 빠르게 자리 잡고 있습니다. 개발자는 코드 작성을 위해 AI를 활용하고, 기획자는 문서 작성과 아이디어 발굴에 AI를 사용하며, 데이터 분석가는 AI를 […]
Rerank와 Weight 튜닝, 그리고 예상과 다른 결과들 1부에서는 Amazon OpenSearch Service와 Amazon Bedrock으로 검색 품질을 측정하는 시스템을 만들었습니다. 이제 측정할 수 있게 됐으니, 고객들은 자연스럽게 “그래서 어떻게 개선하지?” 를 묻게 됩니다. 이번 글에서는 측정 결과를 바탕으로 검색 품질을 실제로 끌어올리는 방법을 다룹니다. 사실 저는 이 테스트를 시작할 때 “검색 성능은 Rerank를 붙이면 당
이 블로그는 Channel Corporation의 이해빈님, 박진영님과 함께 작성되었습니다. 채널코퍼레이션은 올인원 AI 메신저 ‘채널톡’을 운영하는 B2B SaaS 스타트업으로 Amazon DynamoDB의 수평 확장성, ACID 트랜잭션과 같은 특징을 활용해 빠르게 성장하는 비즈니스를 문제없이 수행하고 있습니다. 이 시리즈의 1부에서는 채널코퍼레이션이 Amazon DynamoDB를 선택한 이유와 Amazon DynamoDB에서 트랜잭션을 처
– 박경수(AWS Solutions Architect), 장현태(AWS Solutions Architect),, 백승연 (LG에너지솔루션, Product Owner) · 최수아 (LG에너지솔루션, Data Scientist “실시간으로 가격이 바뀌는 전력시장에서 최대 수익을 내려면 얼마에 입찰해야 할까? 그 가격을 예측하고 입찰 전략까지 분석해주는 에이전트가 있다면?” LG에너지솔루션 전력거래솔루션은 이 한 문장에서 출발했습니다. LG에너지솔루
AI 시대로 전환이 가속화되면서 Amazon ECS가 다시 주목받고 있습니다. 모델 추론 서버부터 AI 에이전트와 에이전트가 호출하는 도구까지 컨테이너로 배포되는 워크로드가 증가했고, GPU 컴퓨트와 급격한 트래픽 변화를 감당하는 일들이 컨테이너 운영의 일상이 되었기 때문입니다. 하지만 ECS로 컨테이너 워크로드를 운영하다 보면 비슷한 고민과 마주치게 됩니다. EC2에서 제공되던 서비스를 Fargate로 이전할 때 시작 유형(launch typ
이 글은 Amazon ECS 실행 구조와 선택 기준을 다루는 시리즈의 2부입니다. 1부에서는 launch type은 호환되는 실행 환경을 표시하는 용도로만 사용하고 실제 실행은 용량 공급자(capacity provider)로 구성한다는 원칙을 바탕으로, Fargate와 ECS Managed Instances, EC2에 걸친 컴퓨트 선택과 Express Mode부터 예약 Task까지의 실행 형태를 살펴봤습니다. 2부에서는 남은 선택지를 다룹니다.
지난 1부에서는 삼성계정 서비스의 멀티 에이전트 AIOps 시스템을 어떤 구조로 설계했고, 그 구조를 안정적으로 운영하기 위해 무엇을 뒷받침했는지, 그리고 그 위에서 자율성을 어떻게 조금씩 넓혀왔는지를 다뤘습니다. 이 글에서는 그 시스템이 실제 운영 현장에서 어떻게 쓰이고 있는지, 도입 전후로 업무가 어떻게 달라졌는지, 그리고 더 높은 수준의 자율운영으로 나아가기 위해 무엇을 준비하고 있는지를 다룹니다. 이 글은 2부작으로 […]
삼성계정(Samsung Account)은 전 세계 약 21억 사용자에게 삼성 디바이스와 서비스를 연결하는 통합 인증 시스템입니다. Samsung Wallet, Bixby, SmartThings, Samsung Health를 비롯한 수많은 서비스가 삼성계정으로 사용자와 연결되며, 글로벌 대규모 트래픽을 365일 24시간 무중단으로 처리합니다. 이런 초대규모 서비스를 운영한다는 것은, 그만큼 방대한 인프라와 끊임없는 운영 업무를 동반한다는 뜻입니다
주말 내내 트래픽이 없던 서비스에서 월요일 아침 첫 요청들만 유독 타임아웃으로 실패합니다. Karpenter가 노드를 교체한 뒤부터는 원인을 알 수 없는 연결 오류가 늘었는데, 부하 테스트를 아무리 돌려도 재현되지 않습니다. 최근 이런 증상을 겪었다면 애플리케이션 코드보다 먼저 확인할 것이 있습니다. 워크로드를 실행 중인 인스턴스 타입의 세대와 Nitro 버전입니다. 2025년 6월부터 출시되고 있는 Nitro V6 기반 인스턴스(m8i, […
1. 클라우드 비용 가시성의 출발점 Cloud Intelligence Dashboards(CID)는 AWS Cost and Usage Report(CUR) 데이터를 Amazon Quick 위에 시각화하는 오픈소스 대시보드 프레임워크입니다. 그 핵심인 CUDOS(Cost and Usage Dashboards Operations Solution) 대시보드는 서비스·계정·리전·태그 등 다양한 차원에서 리소스 레벨까지의 세부 비용과 사용량을 한눈에 보
Claude Code를 조직에 도입하면 개인의 습관만으로는 답할 수 없는 질문이 남습니다. 자리를 비웠다 돌아오면 첫 응답이 왜 유난히 느리고 비싼지, Amazon Bedrock으로 사용하는 조직에서는 누가 얼마나 쓰는지를 어디서 확인할 수 있는지 같은 질문입니다. 이 글은 Claude Code 토큰 비용 최적화 시리즈의 2부입니다. 1부(비용 구조와 세션 습관)에서는 비용이 컨텍스트 크기에 비례하고 실제 지불 단가는 프롬프트 캐싱(prompt
Claude Code를 팀에 도입하고 나면 비슷한 질문들이 찾아옵니다. 짧은 한 문장의 질문만 했는데 토큰 사용량이 왜 이렇게 높은지, 하루가 끝날 때쯤이면 세션이 왜 이렇게 무거워져 있는지 같은 의문입니다. Claude Code는 메시지를 보낼 때마다 시스템 프롬프트, 프로젝트 컨텍스트, 지금까지의 전체 대화 이력을 다시 전송하고, 비용은 그 컨텍스트 크기에 비례합니다. 그리고 실제로 지불하는 토큰 단가는 프롬프트 캐싱(prompt […]
페이지 2 / 14 (총 241개)
