kakao·2026년 8월 6일·4분 읽기큐레이션 요약

개인화된 Airflow 테스트 환경 구축 및 운영 경험

수천 개의 Airflow DAG를 운영하는 카카오 데이터서비스 조직은 테스트 과정의 반복 작업과 환경 간 차이, 리소스 충돌 문제를 해결하기 위해 PR 단위의 개인 Airflow 환경인 AirZone을 구축했습니다. AirZone은 GitHub PR 코멘트에서 생성·삭제를 요청하면 Kubernetes Job과 전용 Helm 차트로 격리된 Airflow를 배포합니다. 사용자는 인프라를 직접 구성하지 않고 실제 운영 환경과 유사한 하둡·인증 환경에서 DAG를 테스트할 수 있습니다. ## 기존 테스트 방식의 한계 - **로컬 Airflow** - Airflow뿐 아니라 하둡 인증, 연결 설정, Docker 환경까지 직접 구성해야 합니다. - 초기 구축 비용이 크고, 로컬 환경과 운영 환경의 차이로 인해 실제 배포 후 실패할 수 있습니다. - **개발용 Airflow** - 코드를 커밋하고 푸시한 뒤 GitHub webhook, submodule 업데이트, DAG 파일 처리 과정을 기다려야 합니다. - DAG를 수정할 때마다 동기화 지연이 반복되어 개발 속도를 떨어뜨렸습니다. - **테스트용 Airflow** - SSH 컨테이너에 로컬 파일을 복사해야 하므로 코드 수정 때마다 추가 작업이 필요합니다. - 실제 데이터와 하둡에 접근하려면 prod VPN을 연결해야 하는 불편도 있었습니다. - **Production Airflow에서의 테스트** - 테스트 DAG가 스케줄러와 워커 자원을 점유해 다른 프로젝트의 실행을 지연시킬 수 있습니다. - 과도한 리소스 사용으로 노드 장애가 발생하면 같은 노드의 다른 태스크까지 중단될 위험이 있습니다. ## AirZone의 핵심 요구사항 - Kubernetes나 Helm을 몰라도 브라우저에서 Airflow 환경을 생성하고 삭제할 수 있어야 합니다. - 사용자는 DAG 검증에만 집중하고, 인프라 구성은 AirZone이 담당해야 합니다. - Jupyter Notebook을 제공해 별도 로컬 환경 없이 코드를 수정할 수 있어야 합니다. - 운영 환경과 유사한 DAG 실행 환경과 하둡 인증 방식을 제공해야 합니다. - PR마다 독립된 Airflow를 생성해 사용자와 테스트 작업을 서로 격리해야 합니다. ## PR 단위의 격리된 환경 - 레포지터리명과 PR 번호를 조합해 Kubernetes 네임스페이스를 생성합니다. - Airflow 웹 서버, 스케줄러, PostgreSQL, Jupyter, DAG PVC, 로그가 PR별로 분리됩니다. - 한 PR의 테스트가 다른 프로젝트의 스케줄러·워커 자원을 침범하지 않습니다. - 리뷰어는 PR에 남은 링크로 특정 코드 상태의 실행 결과를 직접 확인할 수 있습니다. - PR이 종료되면 네임스페이스를 기준으로 관련 리소스를 쉽게 정리할 수 있습니다. ## 요청 처리와 배포 작업의 분리 - `airzone-api`는 PR 존재 여부, PR이 열려 있는지, 네임스페이스 중복 여부 등 요청의 유효성만 검증합니다. - 실제 Helm 설치와 헬스체크는 별도의 Kubernetes Job이 수행합니다. - API가 수 분이 걸리는 배포 작업을 직접 기다리지 않으므로 빠르게 응답할 수 있습니다. - Job별로 상태와 로그가 독립적으로 남아 실패 단계와 원인을 추적하기 쉽습니다. - 실패한 Job을 삭제한 뒤 새 Job을 생성하는 방식으로 배포를 재시도할 수 있습니다. - 생성 요청은 `create-airzone-{namespace}`, 삭제 요청은 `delete-airzone-{namespace}` 형식의 Job 이름을 사용합니다. ## GitHub PR 코멘트를 사용자 인터페이스로 활용 - PR 생성 이벤트를 webhook으로 받아 저장소, 브랜치, PR 번호, 요청자 정보를 확인합니다. - 사용자가 선택할 수 있도록 하둡 환경별 AirZone 생성 링크를 PR 코멘트에 남깁니다. - 생성 완료 결과와 접속 정보도 PR에 표시해 별도 플랫폼 없이 테스트를 시작할 수 있습니다. - 다만 Jupyter 토큰과 Kubernetes 네임스페이스 토큰처럼 민감한 정보는 공개 범위가 넓은 PR 대신 카카오워크로 전달합니다. - 요청 접수와 배포 완료 시점에 카카오워크 알림을 보내 진행 상태를 알립니다. ## 전용 Helm 차트로 구성한 Airflow 기존 운영용 Airflow 차트가 아닌 AirZone 전용 Helm 차트를 만들어 테스트 환경에 필요한 구성만 묶었습니다. - **Airflow 구성** - 웹 서버와 스케줄러를 배포합니다. - `KubernetesExecutor`, DAG 스캔 주기, 로그 설정, 하둡 관련 변수를 테스트 환경에 맞게 설정합니다. - **데이터베이스와 저장소** - 개인 환경용 PostgreSQL을 함께 배포합니다. - scheduler와 Jupyter가 같은 DAG 작업 디렉터리를 사용하도록 DAG PVC를 공유합니다. - **DAG 동기화** - PR의 head repository와 branch 정보를 받아 해당 코드만 동기화합니다. - Git 초기화 컨테이너 등을 통해 배포 환경에 테스트 대상 DAG를 준비합니다. - **인증과 보안** - 사용자·공용 principal, 키탭, Jupyter 토큰을 환경에 주입합니다. - 하둡 접근에 필요한 Kerberos 인증을 운영 환경과 유사하게 구성합니다. - dkos에서 제공하는 TLS 인증서도 테스트 환경에 반영합니다. - **운영 연동** - 여유 있는 노드 그룹과 같은 리전의 `storageClass`를 선택합니다. - Airflow 로그를 Elasticsearch와 Kibana에서 확인할 수 있도록 연결 정보를 주입합니다. - Jupyter를 함께 제공해 브라우저에서 DAG와 관련 코드를 수정할 수 있게 합니다. ## 자동 정리와 운영 구조 - 생성·삭제 요청은 Kubernetes Job으로 처리합니다. - PR 종료 후 남아 있는 AirZone은 매일 실행되는 CronJob이 자동으로 회수합니다. - 사용자에게는 “PR 코멘트의 링크를 누르는 기능”으로 단순하게 보이지만, 운영자는 요청·설치·헬스체크·알림·정리 단계를 각각 추적할 수 있습니다. - 운영 환경에서 불필요한 PGBouncer나 외부 DB 연결 등은 제외해 개인 테스트 환경의 복잡도와 비용을 줄였습니다. AirZone과 같은 구조를 도입할 때는 테스트 환경을 운영 환경과 최대한 유사하게 유지하되, PR 또는 브랜치 단위로 리소스를 격리하는 것이 중요합니다. 또한 긴 배포 작업은 API 요청과 분리하고, Kubernetes Job의 상태·로그·재시도 기능을 활용하면 장애 대응과 운영 추적이 훨씬 쉬워집니다.

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

PostgreSQL쿠버네티스apache-sparkhelm+3

aws·2026년 7월 13일·5분 읽기큐레이션 요약

AWS 주간 정리: 1주년을 맞은 AWS Builder Center, Security Hub의 네트워크 스캐닝, AWS용 Loom 등 (2026년 7월 13일) | Amazon Web Services

AWS Builder Center가 출범 1주년을 맞아 샌드박스, 워크숍, 커뮤니티 기능을 갖춘 AWS 학습·개발 생태계로 확장됐다. 동시에 AWS Security Hub의 네트워크 스캐닝 및 Azure 지원, SageMaker와 Hugging Face 통합, GPU 관리 비용 인하, Aurora DSQL CDC 정식 출시 등 주요 서비스 업데이트가 발표됐다. AWS는 보안·AI 에이전트·멀티클라우드 관리 기능을 통합해 개발 편의성과 운영 자동화를 강화하는 방향을 보이고 있다. ## AWS Builder Center의 1년 성장 - 2025년 7월 9일 출시 이후 커뮤니티 허브에서 종합 개발자 생태계로 확장됐다. - 주요 기능: - AWS 리전별 서비스 현황 - 커뮤니티가 직접 만드는 Spaces - 카테고리·난이도별 워크숍 - 배지와 연속 활동 기록 - 아티클 시리즈, 조회 수, 저장 항목 - 학생 상태 및 서비스 출시 알림 - GitHub·Amazon 계정 로그인 - 무료 샌드박스 환경 - 5,548명의 작성자가 6,448개 아티클을 게시했으며, 누적 조회 수는 1,040만 회를 넘었다. - 2026년 3월 배지 시스템 출시 후 약 99,226개의 배지가 발급됐다. - 사용자 요청 565건 중 10건이 실제 출시됐고, 20건은 단기 로드맵에 포함됐다. - 인기 글: - MCP와 Strands Agents SDK 기반 AWS Study Buddy: 5만 회 이상 - Kiro를 활용한 EOL Linux 서버 AWS 이전: 4만 5천 회 이상 - 신경 질환 조기 검사를 위한 멀티모달 AI: 3만 8천 회 이상 ## 8시간짜리 무료 AWS 샌드박스 - 워크숍 실습을 위해 사전 구성된 무료 AWS 계정을 제공한다. - 개인 AWS 계정, 신용카드, 수동 리소스 정리가 필요 없다. - 환경은 최대 8시간 동안 활성화되며 이후 계정과 리소스가 자동으로 제거된다. - 한 번에 하나의 샌드박스만 사용할 수 있고, 주 1회 신청할 수 있다. - AWS 서비스를 안전하게 실습하거나 교육용 워크숍을 진행하는 데 적합하다. ## Security Hub의 네트워크 및 멀티클라우드 보안 - **Network Scanning**은 실제 인터넷에서 리소스에 접근 가능한지를 직접 확인한다. - AWS와 Azure 환경에서 다음 리소스를 탐색한다. - 공용 IP 주소 - 가상 머신 - 로드 밸런서 - 접근 가능한 포트와 해당 포트에서 실행 중인 서비스를 식별한다. - 접근 가능한 포트마다 발견 근거와 함께 Security Hub finding을 생성한다. - 기존 네트워크 도달 가능성 분석이 “도달 가능하게 만들 수 있는 구성”을 찾는다면, Network Scanning은 실제 인터넷 도달 여부를 검증한다. - Security Hub Exposures가 관련 설정 및 보안 결과를 결합해 전체적인 위험도를 계산한다. - 신규 고객에게는 기본 활성화되며, 기존 고객은 계정·리전별 또는 조직 정책으로 활성화할 수 있다. - Security Hub Essentials에 추가 비용 없이 포함된다. - Azure 리소스도 자동 검색해 다음 항목을 통합 관리한다. - VM, 컨테이너 이미지, Function Apps, ID - 설정 오류, 인터넷 노출, 소프트웨어 취약점 - AWS와 Azure의 보안 결과를 동일한 형식과 자동화 흐름으로 한 화면에서 관리할 수 있다. ## SageMaker Studio와 Hugging Face 통합 - Hugging Face에서 모델을 선택한 뒤 한 번의 클릭으로 SageMaker Studio에서 커스터마이즈하거나 배포할 수 있다. - 지원 모델에는 다음 작업 흐름이 제공된다. - SageMaker에서 모델 커스터마이즈 - SageMaker 또는 Bedrock 엔드포인트 배포 - 모델 평가 - 사용자 정의 보상 함수를 활용한 강화학습 파인튜닝 - 신규 고객은 사전 구성된 권한과 환경을 갖춘 Studio를 빠르게 생성할 수 있다. - 검증된 고객은 별도 쿼터 증액 요청 없이 G5, G6, G4dn GPU 인스턴스에 기본 접근할 수 있다. - Studio 내부에서 GPU 쿼터 사용량도 확인할 수 있다. ## GPU 관리 비용 인하 - 2026년 7월 1일부터 EKS Auto Mode와 ECS Managed Instances의 가속 인스턴스 관리 비용이 자동으로 인하된다. - 인하 폭: - G 계열: 35% - P 계열 및 AWS Trainium: 60% - 기존 클러스터에도 자동 적용되며 별도 작업이 필요 없다. - EKS Auto Mode: - GPU 인스턴스의 병렬 이미지 풀링 - 로컬 NVMe 기반 가속 워크로드 지원 - 가속기 상태를 인식한 노드 복구 - ECS Managed Instances: - CloudWatch Container Insights 기반 GPU 메트릭 - GPU 하드웨어 장애 자동 모니터링 ## Aurora DSQL의 변경 데이터 캡처 - Aurora DSQL CDC가 정식 출시됐다. - INSERT, UPDATE, DELETE 결과를 변경 이벤트로 만들어 Amazon Kinesis Data Streams에 전송한다. - 활용 사례: - 마이크로서비스 간 데이터 동기화 - Lambda 함수 트리거 - Firehose를 통한 S3, Redshift, OpenSearch Service 전달 - 데이터베이스 워크로드 성능에 영향을 주지 않도록 설계됐다. - CDC 인프라를 별도로 구축하거나 운영할 필요가 없다. ## AWS용 Loom과 안전한 AI 에이전트 운영 - Loom은 AWS Strands Agents와 Amazon Bedrock AgentCore Runtime 기반 에이전트를 구축·배포하는 오픈소스 엔터프라이즈 플랫폼이다. - 제공 기능: - 통합 관리 UI와 백엔드 API - ID 공급자 연동 - 범위 기반 권한 제어 - 멀티 페르소나 탐색 - 에이전트, 메모리, MCP 서버, 에이전트 간 연동의 전체 수명주기 관리 - 멀티테넌트 환경을 위해 RBAC와 ABAC를 지원한다. - 리소스 태깅을 자동화해 비용을 사용자·팀별로 추적할 수 있다. - 표준화된 배포 블루프린트, AWS Agent Registry 연동, 민감한 작업 전 사람의 검토 절차도 제공한다. - AWS Labs GitHub에서 프로젝트를 확인할 수 있다. ## Claude 애플리케이션 접근 제어 - Claude Code와 Claude Desktop에 대한 접근, 비용, 정책을 중앙에서 관리하는 자체 호스팅 게이트웨이가 소개됐다. - OIDC 호환 ID 공급자와 연동하며, 모든 요청에 관리형 설정을 적용한다. - Amazon Bedrock 또는 AWS 기반 Claude Platform으로 추론 요청을 라우팅할 수 있다. - 사용자·그룹별 지출 한도를 설정할 수 있다. - 프라이빗 네트워크의 무상태 컨테이너로 실행되며, PostgreSQL은 단기 로그인 상태만 저장한다. - 개발자 장비에 장기 보안 키를 저장하지 않는 방식으로 보안을 강화한다. ## AWS MCP Server의 OAuth 지원 - AWS Console이나 CLI와 동일한 자격 증명을 사용해 브라우저 기반 OAuth로 AWS MCP Server에 연결할 수 있다. - IAM Federation, AWS IAM Identity Center, 루트 사용자 및 IAM 사용자를 지원한다. - AWS Sign-In이 단기 액세스·리프레시 토큰을 발급하고 토큰 갱신을 자동 처리한다. - 개발자는 재시작 후에도 반복 로그인 없이 에이전트를 인증 상태로 유지할 수 있다. AWS를 학습하거나 실험하려는 경우 Builder Center의 샌드박스와 워크숍을 활용하면 비용과 정리 부담을 줄일 수 있다. 운영 환경에서는 Security Hub의 실제 인터넷 도달성 검사와 Azure 통합을 우선 검토하고, AI 에이전트 도입 시에는 Loom·OAuth·중앙 정책 관리 기능을 통해 권한, 비용, 감사 체계를 함께 설계하는 것이 바람직하다.

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

PostgreSQL쿠버네티스모델 컨텍스트 프로토콜AWS+4

line·2026년 6월 25일·5분 읽기큐레이션 요약

AI 시대의 개발 능력은 검증력으로 결정된다, Flava API Gateway 개발 중 배운 빠른 검증과 로컬 환경 구성 전략

코딩 에이전트는 빠르게 코드를 생성하지만, 설계 불명확성·출력 비결정성·검증 지연 때문에 신뢰할 수 없는 결과를 만들 수 있다. LY Corporation의 Flava API Gateway 팀은 이를 해결하기 위해 **스펙 주도 개발, 검증 자동화, 빠르고 독립적인 로컬 환경**을 구축했다. 결론적으로 AI의 생산성을 활용하려면 개발자의 전문성과 테스트·린터·사전 설계를 오히려 더 강화해야 한다. ## 코딩 에이전트가 만드는 개발 병목 - 에이전트의 코드 생성 속도에 비해 CI 대기, 환경 프로비저닝, 원격 테스트 같은 단계는 느리다. - 에이전트는 다음과 같은 오류를 반복적으로 만들 수 있다. - 컴파일되지 않는 코드 - 존재하지 않는 API 참조 - 명시되지 않은 설계 결정을 임의로 선택 - 동일한 프롬프트라도 실행마다 결과가 달라질 수 있어 출력의 일관성과 역량을 일반화하기 어렵다. - AI가 개발자의 리뷰 속도보다 빠르게 코드를 생성하면, 검토되지 않은 코드가 누적될 위험이 있다. - 따라서 AI 활용의 핵심은 단순한 생성 속도가 아니라, 잘못된 결과를 빠르게 발견하고 수정하는 개발 시스템이다. ## Flava API Gateway와 세 가지 대응책 - Flava API Gateway는 LY Corporation의 사내 프라이빗 클라우드 Flava에서 API를 생성·배포·모니터링하는 제품이다. - Kong이 데이터 플레인을 담당하고, 컨트롤 플레인은 각 팀이 독립적으로 API를 관리할 수 있는 다중 테넌트 REST API를 제공한다. - 팀은 다음 세 가지 원칙을 채택했다. - 코드 작성 전 설계와 요구사항을 확정하는 **스펙 주도 개발** - 테스트와 린터로 에이전트가 스스로 오류를 찾도록 하는 **검증 자동화** - CI를 기다리지 않고 전체 검증 루프를 돌리는 **빠른 로컬 환경** ## 스펙 주도 개발로 구현 방향 고정 - 에이전트가 설계가 정해지기 전에 구현을 시작하면, 에이전트가 임의로 설계 결정을 내리면서 비결정성이 커진다. - Flava 팀은 먼저 OpenAPI 스펙으로 컨트롤 플레인의 전체 설계를 정의했다. - OpenAPI 스펙은 다음 역할을 한다. - 에이전트가 따라야 할 명시적 기준 - 구현 결과가 설계에서 벗어났는지 판단하는 검증 기준 - API 동작 계약의 문서화 - 이후 기능을 작은 단위로 나누고 OpenSpec을 사용해 각 기능을 구현했다. ## Nickel을 활용한 OpenAPI 관리 - 원본 OpenAPI YAML은 반복적이고 장황해 수작업 유지보수가 어렵다. - 스펙과 실제 구현이 어긋나면 에이전트를 통제하는 기준으로서의 가치가 떨어진다. - 팀은 Nickel을 사용해 API 리소스를 선언적으로 정의하고, 이를 전체 CRUD 엔드포인트 스펙으로 변환했다. - 예를 들어 리소스 정의만으로 다음 요소를 일관되게 생성할 수 있다. - 목록·생성·조회·삭제 엔드포인트 - 페이지네이션과 정렬 - 정확히 일치하는 필터와 부분 문자열 필터 - ETag 기반 낙관적 잠금 - 공통 오류 응답 - 이 방식은 반복적인 YAML 작성량을 줄이고, API 설계 규칙을 생성기에 집중시킨다. ## OpenSpec 기반의 협업 워크플로 OpenSpec은 에이전트가 구현 전에 행동 계약에 합의하도록 다음 네 가지 산출물을 요구한다. - **제안(Proposal)**: 무엇을, 왜 변경하는지 설명 - **설계(Design)**: 기술적 결정과 트레이드오프 정리 - **델타 스펙(Delta Specs)**: 변경되는 요구사항을 Given-When-Then 시나리오로 정의 - **작업 목록(Task List)**: 구현 단계를 체크리스트로 분해 워크플로는 다음 순서로 진행된다. - 개발자와 에이전트가 기능, 세부사항, 에지 케이스를 함께 검토한다. - 에이전트가 네 가지 산출물을 작성한다. - 에이전트가 작업 목록을 단계적으로 실행하며 구현한다. - 완료 후 변경 사항을 아카이브하고 델타 스펙을 메인 스펙에 병합한다. - 축적된 델타 스펙은 시간이 지나면서 시스템 전체의 “살아 있는 스펙”이 된다. ## 검증 자동화로 에이전트의 오류 수정 유도 - 프롬프트에 주의사항을 계속 추가하는 방식은 효과가 제한적이며, 제약이 많아질수록 출력 품질이 낮아질 가능성도 있다. - 대신 테스트와 린터가 오류를 구체적으로 드러내도록 구성했다. - 에이전트는 다음과 같은 반복 루프를 수행한다. - 코드를 작성한다. - 테스트·린터·포매터를 실행한다. - 실패 원인을 확인한다. - 코드를 수정한다. - 다시 검증하고 다음 오류로 넘어간다. - 모든 요구사항을 처음부터 프롬프트에 주입하는 대신, 필요한 제약을 실패 시점에 점진적으로 제공하는 방식이다. - 프로젝트별 스킬에 테스트, 린터, 포매터를 묶고 `AGENTS.md`를 통해 언제 해당 스킬을 사용할지 안내했다. - 검사 지침을 매 턴마다 전달하지 않고 필요할 때만 로드해 에이전트의 불필요한 컨텍스트 부담도 줄였다. ## 세 계층 테스트와 완전한 로컬 검증 전체 테스트 모음은 2,754개이며 다음 세 계층으로 구성된다. - **단위 테스트** - 비즈니스 로직을 분리해 검증 - **통합 테스트** - 실제 PostgreSQL 사용 - 제약 조건, 트리거, 소프트 삭제 연쇄, 트랜잭션 검증 - 전체 인프로세스 HTTP 스택 검증 - 모든 응답의 OpenAPI 준수 여부 확인 - **E2E 테스트** - 실제 Athenz 인증 - Kong 데이터 플레인 - API 키 적용 - 멀티 테넌트 격리 - 전체 시스템 동작 검증 ## CI 의존성을 줄인 빠른 개발 환경 - 개발자가 직접 작성할 때는 CI 왕복을 줄이기 위해 어느 정도 완성된 코드를 먼저 제출할 수 있지만, 에이전트는 짧은 간격으로 수많은 시도를 반복한다. - 모든 시도를 원격 CI로 보내면 다음 문제가 생긴다. - 긴 대기 시간 - 반복 과정에서 에이전트가 컨텍스트를 잃을 가능성 - 원격 환경의 로그와 상태를 조사하기 어려움 - 완전한 로컬 환경을 구축하면 에이전트가 즉각적인 피드백을 받고 현재 작업 흐름을 유지할 수 있다. - 로컬 의존성의 로그와 상태를 직접 확인할 수 있어 실패 원인 분석도 쉬워진다. - 전체 테스트는 개발자 기기에서 약 15초 안에 실행되도록 최적화했다. - 이를 위해 테스트를 병렬화하고 테스트 간 격리를 강화했다. 공유 테이블을 매번 삭제하는 방식보다 각 테스트 패키지가 독립적으로 생성한 데이터를 사용해 실행 간 충돌을 줄이는 방향을 택했다. ## 실용적인 적용 권장사항 AI 코딩 에이전트를 도입할 때는 프롬프트를 복잡하게 만드는 것보다 먼저 API·행동 스펙을 문서화하고, 테스트·린터·포매터를 자동 실행하며, 핵심 검증을 로컬에서 빠르게 끝낼 수 있게 만드는 것이 효과적이다. 에이전트의 성능을 높이는 가장 현실적인 방법은 더 많은 일을 맡기는 것이 아니라, 실패를 즉시 알려 주고 스스로 수정할 수 있는 짧은 피드백 루프를 구축하는 것이다.

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

PostgreSQLcoding-agentsautomated-testingopenapi+4

datadog·2026년 6월 23일·4분 읽기큐레이션 요약

AI 지원 리팩토링을 활용해 실시간 라우팅 시스템을 마이그레이션한 방법

Datadog은 Stream Router의 기존 FoundationDB 기반 KV 모델이 트랜잭션 크기와 데이터 증가에 따른 한계에 도달하자, 운영 중단 없이 PostgreSQL·DuckDB 기반의 관계형 구조로 전환했습니다. 이 과정에서 Claude와 Cursor를 활용했지만, AI가 자율적으로 코드를 작성한 것이 아니라 사람이 새 스키마와 기존 구현, 실패 테스트를 제공하고 테스트 결과로 검증하는 방식으로 사용했습니다. 핵심 결론은 AI가 대규모 마이그레이션을 크게 가속할 수 있지만, 데이터 모델 설계와 안전성 판단은 여전히 사람의 전문성이 필요하다는 것입니다. ## Stream Router의 역할과 기존 아키텍처 - Datadog은 하루 100조 개가 넘는 이벤트를 처리하며, 각 메트릭 데이터를 올바른 Kafka 클러스터·토픽·파티션으로 라우팅해야 합니다. - Stream Router는 Kafka 메시지를 직접 생산하거나 소비하지 않고, 다른 서비스가 사용할 라우팅 결정을 관리하는 제어 평면 서비스입니다. - 라우팅 정보는 다음과 같은 용도로 사용됩니다. - Producer가 데이터를 기록할 위치 결정 - Querier가 데이터를 읽을 위치 결정 - 시간에 따른 데이터 위치 이력 관리 - 기존 구조는 쓰기와 읽기를 분리한 Eventually Consistent 아키텍처였습니다. - 쓰기 경로: FoundationDB의 키-값 모델 사용 - 읽기 경로: 주기적으로 생성된 스냅샷을 RocksDB와 메모리 데이터베이스에 적재 - Producer와 Querier는 쓰기 경로에 직접 접근하지 않음 ## 설정 파일에서 중앙 제어 평면으로의 발전 - 2016년에는 몇 줄짜리 설정 파일을 모든 서비스에 배포해 라우팅을 관리했습니다. - 인프라와 고객 규모가 커지면서 설정 파일이 수천 줄로 증가했고, 수동 편집과 배포가 운영 부담이 되었습니다. - Stream Router 도입 후에는 다음과 같이 개선되었습니다. - 설정 파일 대신 gRPC API로 라우팅 변경 - 자동화된 오케스트레이션 - 점진적이고 자동화된 롤아웃 - 고가용성과 장애 내성을 고려한 읽기·쓰기 분리 ## KV 모델의 확장 한계 - 라우팅 데이터는 단순한 키-값 목록이 아니라 서로 연결된 관계형 데이터였습니다. - Route는 특정 Kafka Stream을 참조 - Route는 Sharding Strategy를 참조 - Rule은 Route를 참조하고 활성화 시점과 적용 방식을 결정 - 기존 KV 구조에서는 데이터베이스가 제공해야 할 관계 검증을 애플리케이션이 직접 수행해야 했습니다. - 수만 개의 레코드를 Pod 프로세스로 가져옴 - 애플리케이션 내부에서 관계형 데이터베이스처럼 조인과 일관성 검사를 수행 - 데이터와 변경 규모가 커지면서 FoundationDB 트랜잭션 크기 제한에 걸리는 작업이 발생했습니다. - FoundationDB를 PostgreSQL로 단순 교체하는 방안도 해결책이 되지 못했습니다. - 기존 KV 접근 패턴을 그대로 유지하면 수천 번의 순차적인 데이터베이스 왕복이 필요 - 일부 작업은 약 45분이 걸릴 것으로 예상 - 따라서 병목의 원인은 특정 데이터베이스가 아니라, KV에 맞춰진 데이터 모델과 애플리케이션 로직 자체였습니다. ## 관계형 스키마로 재설계 - 팀은 AI를 사용하기 전에 도메인 관계를 직접 분석하고 새 스키마를 설계했습니다. - 관계형 구조에서는 다음 관계를 외래 키로 명시합니다. - Streams와 Sharding Strategies → Routes - Routes → Rules - 기존 애플리케이션 코드가 수동으로 복원하던 관계를 데이터베이스가 직접 표현하고 검증할 수 있게 되었습니다. - 쓰기 경로에는 PostgreSQL을 선택했습니다. - 관계형 의미론 지원 - 트랜잭션 처리 - Datadog의 자체 관리형 PostgreSQL 플랫폼 활용 가능 - 읽기 경로에는 DuckDB를 선택했습니다. - 스냅샷 기반 읽기 계층에 적합한 임베디드 데이터베이스 - 배열 컬럼을 기본 지원 - PostgreSQL과 유사한 SQL 문법 - PostgreSQL과 DuckDB 사이에서 쿼리 로직을 공유할 수 있음 - SQLite도 검토했지만 배열 컬럼을 기본 지원하지 않아 적합하지 않았습니다. ## AI를 활용한 테스트 중심 리팩터링 - Claude와 Cursor는 코드를 독립적으로 생성하도록 맡기지 않았습니다. - 각 메서드마다 사람이 다음 정보를 제공했습니다. - 기존 구현 - 새 데이터베이스 스키마 - 현재 실패하는 테스트 - AI는 이를 바탕으로 첫 번째 구현을 만들었고, 테스트가 코드의 정확성을 검증했습니다. - 이 방식의 장점은 다음과 같습니다. - 전체 마이그레이션을 한 번에 생성하지 않고 메서드 단위로 분할 - 실패 테스트가 요구사항과 오류를 구체적으로 제시 - 생성 코드가 실제 동작과 데이터 관계를 만족하는지 즉시 확인 - 사람이 설계와 판단을 담당하고 AI는 반복적인 변환 작업을 가속 ## 안전한 마이그레이션을 가능하게 한 조건 - 마이그레이션이 성공할 수 있었던 기반은 AI보다 기존 시스템의 구조와 개발 프로세스였습니다. - 특히 저장소 계층이 `Controller`라는 내부 인터페이스 뒤에 모듈화되어 있었습니다. - 이러한 추상화 덕분에 저장 엔진과 구현을 교체하더라도 상위 계층의 변경 범위를 줄일 수 있었습니다. - 글의 제공된 부분은 안전성을 뒷받침한 요소를 설명하는 도중 끝나므로, 이후 테스트 전략이나 실제 전환 절차의 상세 내용은 포함되어 있지 않습니다. 결국 AI는 관계형 스키마를 설계하거나 운영 위험을 판단하는 도구라기보다, 명확한 설계와 테스트가 준비된 상태에서 반복적인 코드 변환을 빠르게 수행하는 도구로 활용하는 것이 적절합니다. 대규모 운영 시스템에서는 먼저 데이터 모델과 인터페이스를 사람이 설계하고, 작은 단위의 실패 테스트를 기준으로 AI 생성 코드를 검증하는 방식을 추천할 수 있습니다.

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

PostgreSQL데이터베이스 설계Apache Kafkagrpc+4

aws·2026년 6월 22일·4분 읽기큐레이션 요약

AWS 주간 요약: 뉴욕 서밋 결산, 하노이 로컬 존, Bedrock의 Grok 4.3, 가격 인하 등 (2026년 6월 22일) | Amazon Web Services

AWS는 뉴욕 서밋에서 장기적으로 가치를 축적하는 AI 에이전트를 중심으로 업무, 보안, 개발, 고객용 애플리케이션 전반의 기능을 확장했다. 동시에 하노이 Local Zone, Grok 4.3, S3 annotations, ECS 오토 스케일링 개선 등 인프라와 생성형 AI 관련 기능도 공개했다. S3 벡터 검색, GameLift 네트워크 대역폭, AWS Marketplace 서비스 등록 수수료 인하를 통해 비용 절감도 추진했다. ## 뉴욕 AWS 서밋: 장기적으로 가치를 만드는 에이전트 - **업무용 에이전트** - Amazon Quick에서 데스크톱 앱을 통해 다단계 자율 에이전트를 생성하고 실행할 수 있다. - 이메일, Slack, 캘린더, 작업을 하나의 우선순위 기반 피드로 통합한다. - 사용자가 설정한 개인화 규칙에 따라 업무를 정리한다. - **보안용 에이전트** - AWS Continuum은 코드 취약점 전 생명주기를 분석·검증·조치하는 AI 기반 보안 서비스다. - AWS Security Agent에 위협 모델링, 주요 Git 플랫폼용 PR 코드 스캔 및 수정 기능이 추가됐다. - Kiro, Claude Code 플러그인, MCP를 통한 IDE 통합도 지원한다. - **개발 및 현대화 에이전트** - Kiro는 네이티브 iOS 앱을 제공한다. - AWS DevOps Agent는 배포 전에 코드 변경 사항을 평가하는 릴리스 관리 기능을 추가했다. - AWS Transform은 기술 부채를 지속적으로 줄이는 자동 현대화를 지원한다. - **고객이 만드는 에이전트** - Amazon Bedrock AgentCore에 인프라·오케스트레이션용 GA 하네스가 추가됐다. - Web Search, Managed Knowledge Base, Guardrails 정책 통합을 제공한다. - AWS Context 서비스는 조직 데이터 간 관계를 매핑해 에이전트의 맥락 이해를 돕는다. ## 하노이 Local Zone과 데이터 주권 - 베트남 하노이에 `ap-southeast-1-han-1a` Local Zone이 추가됐다. - Amazon S3와 Amazon EBS Local Snapshots를 지원한다. - 데이터를 현지에 저장하고 백업할 수 있어 데이터 레지던시 요구사항을 충족하는 데 유리하다. - AWS Global View의 Regions and Zones 탭 또는 `ModifyAvailabilityZoneGroup` API로 활성화할 수 있다. ## AWS Blocks와 개발 환경 단순화 - AWS Blocks는 애플리케이션 개발자를 위한 오픈 소스 TypeScript 프레임워크다. - AWS 계정 없이도 Postgres, 인증, 실시간 메시징을 포함한 로컬 실행 환경을 제공한다. - 배포 시 동일한 코드를 변경 없이 AWS 프로덕션 서비스에서 실행할 수 있다. - 필요할 때 AWS CDK로 전환해 클라우드 리소스를 직접 구성할 수 있다. ## Bedrock, S3, 에이전트 기능 확장 - **Grok 4.3** - xAI의 Grok 4.3을 Amazon Bedrock에서 사용할 수 있다. - 추론, 에이전트 워크플로, 엔터프라이즈 애플리케이션을 지원한다. - 도구 호출, 구조화된 출력, 응답 스트리밍을 제공한다. - **S3 annotations** - S3 객체에 최대 1GB의 풍부하고 변경 가능한 컨텍스트를 직접 연결할 수 있다. - 해당 컨텍스트는 조회 가능하며, AI 에이전트가 데이터를 탐색·이해·처리하는 데 활용된다. - 별도의 메타데이터 시스템을 유지하지 않고도 대규모 AI 및 자동화 워크플로를 구성할 수 있다. - **Strands Agents** - 오픈 소스 에이전트 개발 도구인 Strands에 컨텍스트 관리 기능이 강화됐다. - Strands Shell은 격리된 실행 환경을 제공한다. - Strands Evals에는 장애 주입 테스트와 레드팀 테스트 기능이 추가됐다. ## 성능과 운영 기능 개선 - **ECS 서비스 오토 스케일링** - 20초 단위 고해상도 지표와 지표 게시 최적화를 지원한다. - 테스트에서 스케일 아웃 트리거 시간이 363초에서 86초로 76% 단축됐다. - 확장 및 신규 태스크 프로비저닝까지의 전체 시간은 386초에서 109초로 72% 줄었다. - **EC2 G7** - NVIDIA RTX PRO 4500 Blackwell Server Edition GPU와 6세대 Intel Xeon 프로세서를 탑재한다. - G6 대비 AI 추론 성능은 최대 4.6배, 그래픽 성능은 최대 2.1배 향상됐다. - **Management Console Private Access** - 인터넷 연결 없이 VPC에서 AWS Management Console에 접근할 수 있다. - 에어갭 환경에서도 엄격한 네트워크 보안 정책을 유지하며 인프라를 관리할 수 있다. ## 보안 및 마켓플레이스 - Palo Alto Networks Advanced DNS Security를 Route 53 Resolver DNS Firewall에 직접 적용할 수 있다. - 별도 방화벽을 배포하거나 VPC 구성을 변경하지 않고 DNS 위협 방어 기능을 사용할 수 있다. - AWS Marketplace Storefront가 정식 출시되어 파트너가 자체 브랜드 카탈로그를 웹사이트나 애플리케이션에 구축할 수 있다. - 고객은 AWS Marketplace를 통해 파트너 솔루션을 검색하고 구매할 수 있다. ## 가격 인하 - **Amazon S3 Vectors** - 대규모 벡터 인덱스의 유사도 검색 쿼리 요금을 최대 80% 인하했다. - 기존 애플리케이션 변경 없이 자동 적용된다. - AI, RAG, 시맨틱 검색 비용 절감에 직접적인 효과가 있다. - **Amazon GameLift Servers** - 6세대 이상 인스턴스의 AWS 내 네트워크 송수신 대역폭을 무료화했다. - On-Demand와 Spot 모두 적용되며, 사용자는 인스턴스 시간만 지불한다. - **AWS Marketplace 전문 서비스** - 등록 수수료를 기존 2.5%에서 0.5%로 낮췄다. - 컨설팅 업체, 시스템 통합 사업자, 관리형 서비스 제공업체의 거래 비용을 줄인다. 이번 발표의 방향은 AI 에이전트를 실제 업무와 운영에 통합하는 동시에, 데이터 주권·보안·성능·비용 문제를 함께 개선하는 것이다. 에이전트 기반 애플리케이션을 구축하려는 팀은 Bedrock AgentCore와 S3 annotations를 검토하고, 대규모 검색·게임·서비스 운영 환경은 이번 가격 및 성능 개선의 적용 여부를 확인하는 것이 좋다.

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

PostgreSQLAI 에이전트생성형 AITypeScript+4

cloudflare·2026년 6월 12일·4분 읽기큐레이션 요약

보안 인사이트 확장: 글로벌 스캔 처리 역량을 10배 향상한 방법

Security Insights는 기존 주 1~2회에 그치던 보안 검사를 모든 계정에 더 자주 적용하기 위해 처리량을 초당 10건에서 100건으로 약 10배 높여야 했다. Cloudflare는 Kafka 소비 병렬화, 느린 작업 분리, Postgres 대량 삽입 최적화, 지역 간 네트워크 지연 분석을 통해 스캔 처리량을 10배 이상 향상시켰다. 그 결과 수백만 고객에게 보안 인사이트를 제공하고 전체 고객의 검사 주기를 두 배로 늘릴 수 있었다. ## 기존 보안 검사 구조와 확장 과제 - 스케줄러가 검사 시점이 된 계정과 Zone을 감지한다. - 검사 작업을 Apache Kafka 메시지로 발행하고, 여러 Go 기반 checker 마이크로서비스가 메시지를 나누어 처리한다. - 각 checker는 특정 자산이나 설정을 검사한 뒤 내부 API로 결과를 전송한다. - API는 결과를 Postgres 데이터베이스에 저장한다. - 기존 시스템은 다음 문제를 겪고 있었다. - 검사가 주 1~2회만 수행되어 위험이 최대 2주간 탐지되지 않을 수 있었다. - 많은 무료 요금제 계정에서 자동 검사가 선택 사항이라 검사 자체가 이뤄지지 않았다. - Kafka backlog 증가, API 타임아웃, 프로세스 충돌이 발생했다. - 모든 계정에 자동 검사를 적용하고 검사 빈도를 높이려면 평균 처리량을 초당 10건에서 100건으로 늘려야 했다. ## Kafka 파티션의 병목 - Kafka는 일반적인 큐와 달리 파티션 내 메시지를 순서대로 소비하고 처리한다. - 하나의 consumer group에서는 파티션당 활성 consumer를 하나만 둘 수 있다. - 따라서: - 처리 시간이 긴 메시지 하나가 뒤따르는 메시지의 처리를 막을 수 있다. - checker별 병렬 소비자 수는 Kafka 파티션 수에 제한된다. - 파티션을 추가하면 확장할 수 있지만, 여러 서비스가 공유하는 Kafka 브로커의 자원 사용량이 증가하므로 최후의 수단으로 남겨두었다. ## 배치 기반 병렬 처리 - 메시지를 하나씩 처리하던 checker를 배치 단위로 소비하도록 변경했다. - 배치 안의 각 메시지는 별도의 Go goroutine에서 동시에 처리했다. - 이 방식의 trade-off는 다음과 같다. - 배치 처리 중 프로세스가 중단되면 이미 처리한 작업을 다시 수행해야 할 수 있다. - 동시에 처리하는 작업이 늘어 메모리 사용량이 증가한다. - 검사 시스템에서는 재처리 비용과 메모리 증가가 감당 가능한 수준이었기 때문에 병렬 처리를 선택했다. ## 느린 작업으로 인한 Head-of-Line Blocking 제거 - 일부 계정이나 Zone은 자산 수가 많아 검사에 수초가 아니라 수분 또는 수시간이 걸릴 수 있었다. - 이런 느린 메시지가 일반 메시지 앞에 있으면 Kafka 소비가 멈춰 빠른 작업까지 지연됐다. - 해결책으로 checker와 consumer group을 두 개의 처리 경로로 분리했다. - **Fast lane**: 빠르게 처리할 수 있는 일반 메시지 담당 - **Slow lane**: 처리 시간이 긴 메시지 전담 - 메시지의 예상 처리 시간을 빠르게 판단하고, fast lane이 느린 메시지를 만나면 건너뛰도록 했다. - 그 결과 느린 작업은 전용 자원을 사용하고, 빠른 작업은 지연 없이 계속 처리할 수 있었다. ## Postgres 대량 저장 최적화 - 기존 API는 인사이트 하나마다 별도의 `INSERT ... ON CONFLICT DO UPDATE` 쿼리를 실행했다. - 한 요청에 최대 50만 개의 인사이트가 포함될 수 있어, 최악의 경우 50만 번의 데이터베이스 왕복과 쿼리 실행이 발생했다. - 처음에는 임시 테이블에 `COPY`하는 Postgres 표준 대량 삽입 방식을 시도했지만, Postgres 시스템 테이블의 bloat가 증가하는 문제가 나타났다. - 최종적으로 입력 규모에 따른 하이브리드 방식을 채택했다. - 작은 데이터셋: `UNNEST`를 사용해 빠르게 삽입 - 큰 데이터셋: `COPY`를 사용해 대량 삽입 - 이 방식은 대규모 데이터에는 수초 수준의 처리 시간을, 소규모 데이터에는 밀리초 수준의 빠른 처리를 제공했다. ## 지역 간 지연으로 발생한 API 타임아웃 - 확장 과정에서 다음 현상이 관찰됐다. - 클라이언트 타임아웃 증가 - checker 처리 시간의 20~90%가 단일 API 호출에 소요 - 대량 검사 시 초기 처리량은 높지만 시간이 지나며 감소 - 원인은 API와 데이터베이스 간 네트워크 지연이었다. - 주 데이터베이스는 미국 오리건주 포틀랜드에 위치했다. - API는 포틀랜드와 네덜란드 암스테르담에서 active-active로 운영됐다. - 포틀랜드 API 호출은 평균 10ms였지만, 암스테르담 인스턴스에서는 거의 3초가 걸렸다. - 암스테르담 API가 데이터베이스 연결을 오래 점유하면서 checker의 클라이언트 연결 풀이 고갈됐다. - 연결을 기다리는 요청이 타임아웃되고, 암스테르담 API에 연결된 Kafka 파티션만 지속적으로 지연됐다. - 결국 API의 단순한 지역 분산이 전체 Kafka 소비 처리량의 불균형과 lag를 유발할 수 있음을 확인했다. ## 실용적인 결론 대규모 이벤트 처리 시스템에서는 소비자 수를 늘리는 것만으로 충분하지 않다. Kafka의 파티션 제약을 고려한 병렬 처리, 느린 작업의 별도 격리, 대량 데이터베이스 작업의 배치화, 데이터베이스와 API 간 지역 지연 관리까지 함께 최적화해야 안정적인 처리량 확장이 가능하다. 특히 분산 배포 환경에서는 평균 latency뿐 아니라 연결 풀 점유 시간과 파티션별 처리 편차까지 함께 측정해야 한다.

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

PostgreSQLApache Kafka분산 시스템API+4

datadog·2026년 6월 4일·4분 읽기큐레이션 요약

페일오버가 안전하지 않을 때: Kubernetes에서 고가용성 PostgreSQL 구축하기

Datadog은 게임데이를 통해 PostgreSQL 클러스터가 특정 가용 영역의 네트워크 장애에서 안전하게 페일오버하지 못하는 문제를 발견했다. 비동기 복제 환경에서는 장애가 발생한 리더가 계속 쓰기를 처리하는 동안 복제 지연이 커졌고, 모든 스탠바이가 안전한 승격 기준을 충족하지 못했다. 이를 해결하기 위해 Patroni가 관리하는 동기 복제 기반의 페일오버 후보를 도입해 내구성과 자동 복구 가능성을 높이려 했다. ## 게임데이로 드러난 가용 영역 장애 - 스테이징 환경에서 특정 가용 영역에 네트워크 지연을 의도적으로 유발했다. - 해당 영역에 PostgreSQL의 primary 또는 writer 노드가 위치해 있었다. - primary와 replica 간 통신이 불안정해지면서: - 복제 지연(replication lag)이 빠르게 증가 - 쓰기 작업이 멈추거나 지연 - 애플리케이션이 오래된 데이터를 조회 - 모든 replica가 primary의 최신 상태를 충분히 반영하지 못해 안전한 승격 대상이 사라졌다. - 결과적으로 지연이 해소되고 replica가 따라잡을 때까지 기다리는 것 외에는 복구 방법이 없었다. ## Kubernetes 기반 PostgreSQL 아키텍처 - 클러스터는 **leader pool**과 **read replica pool**로 분리된다. - Leader pool: - 하나의 active writer가 모든 쓰기를 처리 - 두 개의 standby 노드는 애플리케이션 읽기 트래픽에는 사용되지 않음 - leader 장애 시 standby가 승격될 수 있음 - Read replica pool: - 읽기 전용 트래픽 처리 - 읽기 확장과 쿼리 격리를 담당 - 페일오버 후보에서는 제외 - 이 구조는 읽기 용량을 독립적으로 확장하고 writer의 쓰기 지연을 안정적으로 유지하는 데 유리하다. - 그러나 장애 시 실제로 승격 가능한 노드 수가 제한되므로, 해당 후보들의 복제 상태가 중요하다. ## Patroni와 ZooKeeper의 역할 - Patroni는 PostgreSQL의 복제, 리더 선출, 페일오버를 관리한다. - ZooKeeper는 분산 구성 저장소(DCS)로 사용되며 다음 정보를 저장한다. - 현재 leader 키와 락 - 클러스터 설정 - 각 노드의 복제 상태와 최신 LSN - 새 노드는 ZooKeeper에 leader가 있는지 확인한다. - leader가 없으면 ephemeral znode를 생성해 leader 락 획득을 시도 - ZooKeeper의 단일 획득 보장으로 다중 primary(split-brain)를 방지 - leader가 이미 있으면 새 노드는 replica로 동작하며 스트리밍 복제를 시작 - 네트워크 파티션 상황에서는 상태를 확신할 수 없는 노드의 승격을 보수적으로 제한한다. - leader가 ZooKeeper와 통신하지 못하면, 적격 standby만 leader 락을 획득하도록 조정한다. - 기존 leader가 복구 후 leader 락을 다시 획득하지 못하면 스스로 강등되어 단일 leader 원칙을 유지한다. ## 비동기 복제의 한계 - 기존 환경은 PostgreSQL의 기본 복제 방식인 비동기 복제를 사용했다. - primary는 replica의 WAL 수신 확인을 기다리지 않고 트랜잭션을 커밋한다. - 장점: - 쓰기 지연이 낮음 - 높은 처리량 유지 - 단점: - primary 장애 시 아직 replica에 전달되지 않은 커밋 데이터가 유실될 수 있음 - 네트워크 지연이 커지면 replica가 primary보다 크게 뒤처질 수 있음 - 게임데이에서는 primary가 복제 지연 중에도 계속 쓰기를 수락했다. - 그 결과 모든 standby가 안전한 페일오버 기준을 초과했고, 장애 시 복구 가능한 후보가 남지 않았다. ## `maximum_lag_on_failover`와 안전한 승격 - Patroni는 standby를 승격하기 전에 복제 지연이 허용 범위 안에 있는지 검사한다. - 이 기준은 `maximum_lag_on_failover` 파라미터로 설정된다. - standby가 이 기준보다 많이 뒤처진 상태에서 승격되면 데이터 손실이나 불일치가 발생할 수 있다. - 따라서 Patroni가 승격을 거부한 것은 오작동이 아니라 데이터 일관성을 지키기 위한 정상적인 동작이었다. - 문제의 본질은 Patroni가 아니라, 장애 시 기준을 충족하는 standby가 하나도 없었다는 점이다. ## 동기 복제를 통한 개선 방향 - 동기 복제에서는 primary가 최소 한 replica의 확인 응답을 받은 뒤 클라이언트에 트랜잭션 성공을 반환한다. - 이를 통해 최소 한 replica에 커밋 데이터가 반영되었음을 보장할 수 있다. - 비동기 복제보다 쓰기 지연과 성능 비용이 발생하지만, primary 장애 시 데이터 유실 위험은 크게 줄어든다. - Datadog은 페일오버 후보에 동기 복제를 적용하고 Patroni가 이를 조정하도록 아키텍처를 재설계했다. - 목표는 성능 특성을 과도하게 훼손하지 않으면서 자동적이고 안전한 페일오버를 구현하는 것이었다. 실무적으로는 모든 읽기 replica에 동기 복제를 적용하기보다, 실제 페일오버 후보에만 동기 복제를 적용해 성능과 내구성의 균형을 맞추는 접근이 적절하다. 또한 네트워크 지연과 영역 장애를 가정한 게임데이 및 복제 지연 기반의 페일오버 테스트를 정기적으로 수행해야 한다.

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

PostgreSQL쿠버네티스high-availabilitydatabase-replication+4

discord·2026년 5월 8일·4분 읽기큐레이션 요약

Discord가 대규모로 ScyllaDB 클러스터를 자동화하는 방법

Discord는 수백 개의 ScyllaDB 노드를 소수의 인원이 운영하기 위해, 취약한 스크립트 모음 대신 Scylla Control Plane(SCP)을 구축했다. SCP는 실제 트래픽을 복제하는 shadow cluster를 자동으로 생성·검증해 ScyllaDB 업그레이드와 인프라 변경을 운영 환경에 적용하기 전에 안전하게 테스트한다. 작업을 태스크와 워크플로로 구조화하고, 사전 조건·재시도·상태 저장·병렬성 제어를 제공함으로써 클러스터 구축 시간을 크게 줄이고 실패 시 처음부터 다시 시작해야 하는 문제를 해결하는 것이 핵심이다. ## 대규모 ScyllaDB 운영의 어려움 - Discord의 Persistence Infrastructure 팀은 7명으로 Elasticsearch, Postgres, ScyllaDB 클러스터를 운영한다. - ScyllaDB는 메시지, 채널, 서버, 사용자 데이터 대부분을 저장하며, 수십 개 클러스터와 수백 개 노드로 구성된다. - 주요 운영 작업에는 다음이 포함된다. - 설정 변경 후 롤링 재시작 - 트래픽 증가에 따른 클러스터 확장 - 무중단 운영을 유지한 운영체제 업그레이드 - 새 ScyllaDB 버전을 검증하기 위한 신규 클러스터 생성 - 작업 간 순서와 검증이 중요하기 때문에 단순한 일회성 자동화만으로는 부족하다. ## 기존 스크립트의 한계 - Python과 Bash 스크립트를 점진적으로 추가해 왔지만, 운영 규모가 커지면서 도구가 취약해졌다. - 스크립트가 제공하던 문제점은 다음과 같다. - **안전하지 않음:** 잘못된 순서나 대상 노드에 실행할 수 있고, 실행 전 조건 확인이 부족했다. - **복구 불가능:** 여러 단계 중간에 실패하면 완료한 작업까지 되돌리거나 전체 작업을 처음부터 다시 해야 했다. - **확장하기 어려움:** 새 작업을 추가할 때 기존 스크립트를 복사하고 수정하는 방식이 필요했다. - 운영에 필요한 절차와 노하우가 개별 엔지니어의 경험에 의존했다. ## Shadow Cluster를 통한 안전한 업그레이드 검증 - Shadow cluster는 운영 클러스터의 전체 복제본으로, 짧은 기간 동안 실제 운영 트래픽의 읽기와 쓰기를 함께 처리한다. - 운영 환경에 영향을 주기 전에 다음과 같은 문제를 실제 부하에서 발견할 수 있다. - 특정 ScyllaDB 버전의 예외적인 동작 - 대규모 클러스터에서만 발생하는 버그 - 모든 노드 업그레이드 후에야 나타나는 문제 - 신규 shadow cluster를 수동으로 만들려면 다음 절차를 반복해야 했다. - 노드 프로비저닝 및 설정 - 노드를 클러스터에 순차적으로 조인 - 복제 상태 검증 - dual-write 파이프라인 구성 - 테스트 후 리소스 제거 - Discord는 ScyllaDB 버전뿐 아니라 운영체제와 하드웨어 변경 전에도 shadow cluster를 표준 검증 절차로 활용한다. ## SCP 설계 목표 SCP는 기존 운영 경험에서 얻은 문제를 바탕으로 다음 네 가지 목표를 세웠다. - **확장 가능한 태스크 프레임워크** - 작업의 입력과 실행 로직만 정의하면 기존 오케스트레이션 환경에서 동작하도록 설계한다. - 새로운 개발자가 내부 실행 구조를 모두 이해하지 않아도 새 작업을 추가할 수 있어야 한다. - **설정 가능한 병렬성** - 여러 노드에서 동시에 실행해도 되는 작업과 순차 실행이 필요한 작업을 구분한다. - 예를 들어 서로 다른 availability zone의 노드에서 특정 작업을 동시에 실행하지 않도록 제약을 표현할 수 있다. - **기본적으로 안전한 실행** - 태스크가 실행 전제 조건을 직접 선언한다. - 일시적 오류는 자동으로 재시도한다. - 실행 상태를 저장해 중단된 작업을 완료 지점부터 재개한다. - **점진적 개발과 배포** - 처음부터 거대한 시스템을 만들기보다 사용할 수 있는 기능부터 배포한다. - 실제 클러스터에서 사용하며 온보딩과 사용성 문제를 조기에 발견하고 개선한다. - 사용되지 않는 복잡한 프레임워크를 만드는 일을 피한다. ## SCP의 기본 구조 SCP는 **태스크(task)**, **워크플로(workflow)**, **잡(job)**이라는 계층적 개념을 중심으로 구성된다. - **태스크** - 하나의 구체적인 작업 단위다. - 예: 노드 drain, repair 상태 확인, 정리 작업 실행 - 단일 노드에서 실행되는 **노드 태스크**와 클러스터 전체를 조정하는 **클러스터 태스크**로 나뉜다. - 클러스터 태스크는 여러 노드에서 노드 태스크를 실행하는 역할도 담당한다. - **조건(condition)** - 다음 태스크로 넘어가기 전에 클러스터가 특정 상태에 도달했는지 확인하는 특수한 태스크다. - Scylla API나 Prometheus 메트릭을 주기적으로 조회한다. - 조건이 충족되면 진행하고, 제한 시간 안에 충족되지 않으면 오류를 발생시킨다. - **명시적인 상태 대기** - 노드 재시작 후에는 compaction이 안정될 때까지 기다려야 한다. - 고정된 `sleep`만 사용하면 대기 시간이 너무 짧아 장애를 일으키거나, 너무 길어 전체 롤링 재시작이 불필요하게 느려질 수 있다. - 조건 태스크는 대기 과정을 관찰 가능하고 조정 가능하게 만든다. ## 실용적인 결론 대규모 데이터베이스 운영에서는 개별 스크립트를 계속 늘리기보다, 작업의 선행 조건·재시도·상태 저장·병렬 실행 규칙을 표준화한 오케스트레이션 계층이 필요하다. 특히 운영 트래픽을 재현하는 shadow cluster와 재개 가능한 태스크 프레임워크를 결합하면, 위험한 업그레이드를 자동화하면서도 실패 복구 비용을 크게 줄일 수 있다.

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

PostgreSQLRustelasticsearchprometheus+3

figma·2026년 5월 4일·3분 읽기큐레이션 요약

PGKeeper: Postgres에 꼭 필요했던 보안관 만들기 | Figma 블로그

Figma는 데이터베이스 트래픽과 제품 규모가 커지면서 기존 PgBouncer의 확장성·부하 제어·연결 관리 한계에 부딪혔고, 이를 대체할 자체 서비스 PGKeeper를 구축했다. PGKeeper는 DBProxy와 PostgreSQL 사이에서 연결 풀링과 트래픽 관리를 담당하며, 과부하로부터 데이터베이스와 연결을 보호하는 것을 목표로 한다. 글은 Figma의 데이터베이스 구조와 PgBouncer를 교체하게 된 이유, 그리고 PGKeeper를 직접 개발한 배경을 설명한다. ## Figma의 PostgreSQL 데이터베이스 구조 - PostgreSQL은 Figma의 OLTP 시스템 기반이다. - 데이터 증가에 대응하기 위해 데이터베이스를 수평·수직으로 확장하고 여러 PostgreSQL 인스턴스를 운영했다. - 애플리케이션이 샤딩 구조를 직접 알 필요 없도록 **DBProxy**라는 요청 라우팅 계층을 구축했다. - DBProxy는 쿼리를 분석해 적절한 PostgreSQL 인스턴스를 선택하고, 필요하면 여러 인스턴스를 대상으로 쿼리를 재작성한다. - DBProxy와 PostgreSQL 사이에는 연결 풀러가 위치한다. - 각 PostgreSQL 머신에는 전용 연결 풀러 복제본 그룹이 배치되어, 여러 풀러가 하나의 데이터베이스에 연결되는 n-to-1 구조를 이룬다. ## PgBouncer가 한계에 도달한 이유 - **확장성 부족** - PgBouncer는 단일 스레드 아키텍처라 수직 확장에 한계가 있었다. - 복제본을 늘려 수평 확장했지만 트래픽 분배가 치우치면서 성능 저하가 발생했다. - **정교한 부하 관리 부재** - 중요한 트래픽을 낮은 우선순위의 문제성 트래픽보다 먼저 처리할 수 없었다. - 백프레셔가 없어 급격한 트래픽 증가를 우아하게 제어하기 어려웠다. - 대기 시간에 기반해 작업을 버리는 CoDel(Controlled Delay) 같은 부하 완화 알고리즘도 지원하지 않았다. - **연결 폭증과 연결 churn 위험** - PostgreSQL 연결은 많은 자원을 사용한다. - 연결이 빠르게 생성되거나 과도하게 재생성되면 데이터베이스 안정성이 크게 떨어진다. - 장애 이후 무제한으로 연결을 다시 만들면 복구 과정 자체가 PostgreSQL을 압박할 수 있다. - 이로 인해 연결 churn과 연쇄적인 과부하가 장시간 지속될 수 있다. - **확장성과 운영 제어의 한계** - 트래픽 유형별 admission control, 공정한 자원 분배 등 세밀한 정책이 필요했다. - 심층적인 관측성, 기능 플래그 기반의 안전한 롤아웃도 요구됐다. - PgBouncer에 작은 수정 사항을 유지하는 것만으로도 부담이 컸기 때문에, 대규모 확장은 장기적인 유지보수 비용을 초래할 가능성이 컸다. ## DBProxy에 연결 풀링을 통합하지 않은 이유 - PostgreSQL 인스턴스 하나의 연결 풀은 대략 100개 규모로 운영됐다. - 반면 DBProxy는 수백 개의 상태 비저장 복제본으로 구성됐다. - 각 DBProxy가 독립적으로 연결 풀을 관리하면: - 전체 PostgreSQL 연결 제한을 초과할 수 있고, - 복제본 간 복잡한 조정이 필요하며, - 고정된 소규모 연결 풀을 수백 개 인스턴스에 분산하기 어렵다. - 따라서 연결 풀링은 DBProxy 내부가 아니라 별도의 중앙화된 계층에서 담당해야 했다. ## PGCat 대신 자체 서비스를 만든 배경 - Figma는 PgBouncer의 단일 스레드 한계를 해결하기 위해 멀티스레드 PostgreSQL 프록시인 PGCat도 검토했다. - 그러나 필요한 기능을 추가하려면 PGCat의 핵심 실행 경로를 크게 수정해야 했다. - 관측성, 기능 플래그, admission control을 upstream에 반영하기도 쉽지 않았다. - 결국 PGCat을 포크해 장기적으로 유지해야 할 가능성이 높았으므로, Figma는 요구사항에 맞는 Go 기반 자체 서비스 **PGKeeper**를 개발했다. ## PGKeeper의 역할 - PGKeeper는 DBProxy와 PostgreSQL 사이에 위치하는 Go 서비스다. - 주요 목적은 다음과 같다. - 데이터베이스를 과도하거나 잘못된 트래픽으로부터 보호 - PostgreSQL 연결의 급격한 생성과 churn 방지 - 트래픽 우선순위와 자원 사용을 세밀하게 제어 - 대규모 환경에 맞는 확장성과 운영 도구 제공 - 이름은 골키퍼처럼 위험한 트래픽이 시스템을 압도하지 못하도록 막고, 연결 자체도 보호한다는 의미에서 붙여졌다. Figma의 사례는 단순히 연결 풀러를 교체한 것이 아니라, 데이터베이스 앞단에서 트래픽을 선별하고 과부하를 제어하는 별도 인프라 계층이 필요해졌음을 보여준다. PostgreSQL 연결 수가 제한적이고 프록시 복제본이 많은 환경에서는 풀링을 애플리케이션 프록시에 분산하기보다, 독립적인 계층으로 관리하는 편이 적합하다.

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

PostgreSQLGodatabase-shardingload-balancing+3

netflix·2026년 5월 1일원문

모델 서빙의 라우팅 현황 (새 탭에서 열림)

넷플릭스는 대규모 개인화 경험을 제공하기 위해 수백 개의 모델과 초당 100만 건의 요청을 처리하는 중앙 집중식 머신러닝(ML) 모델 서빙 플랫폼을 운영하고 있습니다. 이 플랫폼은 'Switchboard'라는 라우팅 계층을 통해 클라이언트 마이크로서비스와 복잡한 ML 모델 인프라를 분리하여, 클라이언트의 수정 없이도 새로운 모델을 신속하게 실험하고 배포할 수 있는 환경을 구축했습니다. 이를 통해 넷플릭스는 모델 추론뿐만 아니라 데이터 전처리 및 특징 추출을 포함한 전체 워크플로우를 표준화된 API로 추상화하여 혁신의 속도를 높이고 있습니다. ### 넷플릭스의 워크플로우 중심 모델 정의 * 넷플릭스에서 모델은 단순한 추론 함수(`score(features)`)를 넘어, 입력 데이터 변환, 특징(feature) 계산, 추론, 후처리를 모두 포함하는 독립적인 '워크플로우'로 정의됩니다. * 클라이언트는 사용자 ID나 국가와 같은 최소한의 컨텍스트만 제공하며, 모델 서빙 플랫폼이 필요한 데이터를 다른 마이크로서비스에서 가져와 직접 특징을 계산합니다. * 이러한 구조 덕분에 클라이언트는 모델의 내부 로직이나 데이터 의존성을 알 필요가 없으며, 모델의 아키텍처가 변하더라도 클라이언트 코드를 수정할 필요가 없습니다. ### 중앙 집중형 라우팅 엔진, Switchboard * 넷플릭스는 표준 API 게이트웨이나 서비스 메시가 제공하지 못하는 실험 플랫폼과의 통합, gRPC 지원, 도메인 특화 라우팅을 구현하기 위해 자체 프록시 서비스인 'Switchboard'를 개발했습니다. * Switchboard는 클라이언트 요청을 적절한 모델 인스턴스와 클러스터 샤드로 전달하는 역할을 수행하며, 초당 100만 건 이상의 요청을 처리하면서도 높은 가용성을 유지합니다. * 모델 배포 시 섀도 모드(Shadow mode), 카나리 배포(Canary), 롤백 등을 클라이언트 모르게 수행할 수 있어 안전한 운영이 가능합니다. ### 인프라 복잡성을 감추는 모델 샤딩 분리 * 모델은 트래픽 패턴, SLA, CPU/메모리 요구사항에 따라 여러 연산 클러스터 샤드(VIP 주소)에 분산 배치됩니다. * 서빙 플랫폼은 이러한 물리적 배치 상태를 클라이언트로부터 은폐하여, 인프라의 변경이나 모델의 샤드 이동이 클라이언트 서비스에 영향을 주지 않도록 설계되었습니다. * 이를 통해 ML 연구자는 인프라 제약 없이 자유롭게 실험을 설계하고 모델을 배포할 수 있습니다. ### 'Objective' 기반의 추상화 계층 * 플랫폼은 'Objective'라는 열거형(Enum) 단위를 통해 모든 요청을 관리하며, 이는 비즈니스 목적(예: 콘텐츠 추천, 결제 사기 탐지)을 나타냅니다. * Objective는 요청이 전달될 특정 서빙 클러스터와 모델 유형/버전을 결정하는 기준이 됩니다. * 또한, 각 Objective는 고유한 API 규격을 정의하여 서로 다른 도메인의 클라이언트가 동일한 방식으로 플랫폼과 통신할 수 있도록 표준화합니다. 성공적인 대규모 ML 시스템을 구축하려면 모델의 생명주기를 클라이언트 애플리케이션으로부터 완전히 격리해야 합니다. 넷플릭스의 사례처럼 워크플로우 단위의 모델 정의와 'Objective' 중심의 라우팅 추상화를 도입함으로써, 인프라의 복잡성을 관리하면서도 머신러닝 혁신의 속도를 극대화할 수 있습니다.

PostgreSQL데이터베이스 설계머신러닝마이크로서비스+4

aws·2026년 4월 27일원문

AWS 주간 정리: Anthropic과 Meta의 파트너십, AWS Lambda S3 파일, Amazon Bedrock AgentCore CLI 등 (2026년 4월 27일) | Amazon Web Services (새 탭에서 열림)

이번 AWS 주간 소식은 Anthropic 및 Meta와의 전략적 파트너십 강화와 생성형 AI 에이전트 개발을 가속화하는 기술적 진보에 초점을 맞추고 있습니다. AWS는 실리콘 레벨에서의 최적화와 서버리스 기술의 고도화를 통해 복잡한 AI 워크로드를 더 효율적으로 처리할 수 있는 환경을 구축하고 있습니다. 결과적으로 개발자들은 하 인프라의 복잡성에서 벗어나 더 정교하고 협업 중심적인 AI 애플리케이션 구축에 집중할 수 있게 되었습니다. **Anthropic 및 Meta와의 전략적 파트너십 확대** - Anthropic은 AWS Trainium 및 Graviton 인프라를 활용해 최신 파운데이션 모델을 학습시키며, 하드웨어와 소프트웨어 스택 전반의 효율성을 극대화하기 위해 Annapurna Labs와 협력합니다. - Amazon Bedrock 내에서 'Claude Cowork'가 출시되어, 기업 고객들은 AWS의 보안 환경을 유지하면서 팀 단위의 협업 AI 워크플로우를 직접 배포할 수 있습니다. - Meta는 추론, 코드 생성, 다단계 작업 오케스트레이션 등 CPU 집약적인 에이전트 중심 AI 워크로드를 위해 수천만 개의 AWS Graviton 코어를 도입하기로 합의했습니다. **Lambda 및 Aurora의 서버리스 기능 강화** - **Lambda S3 Files:** Amazon EFS를 기반으로 구축된 이 기능을 통해 Lambda 함수가 S3 버킷을 파일 시스템으로 마운트할 수 있으며, 데이터 다운로드 없이 표준 파일 작업을 수행할 수 있어 AI 모델의 메모리 유지 및 상태 공유가 용이해졌습니다. - **Aurora Serverless 성능 향상:** 새로운 플랫폼 버전 4에서는 이전보다 최대 30% 향상된 성능과 스마트 스케일링 알고리즘을 제공하며, 사용하지 않을 때는 비용이 발생하지 않는 'Scale to zero' 기능을 유지합니다. - **EKS Hybrid Nodes 게이트웨이:** 온프레미스와 클라우드 간의 복잡한 네트워크 인프라 변경 없이도 하이브리드 Kubernetes 환경의 네트워킹을 자동화하여 포드 간 통신을 간소화합니다. **AI 에이전트 개발 및 운영 효율화 도구** - **Bedrock AgentCore:** 새로운 CLI와 관리형 하네스(Managed Harness)를 도입하여 오케스트레이션 코드 없이도 모델, 프롬프트, 도구를 정의해 즉시 에이전트 프로토타입을 실행하고 이를 IaC(AWS CDK 등)로 내보낼 수 있습니다. - **세분화된 비용 할당:** Amazon Bedrock 사용량을 태그 기반으로 상세하게 추적할 수 있게 되어, 여러 팀이나 프로젝트를 운영하는 조직에서 정밀한 비용 가시성과 비용 재청구(Chargeback)가 가능해졌습니다. - **SageMaker 추론 최적화 권장:** 생성형 AI 모델 배포 시 최적의 인스턴스 타입, 컨테이너, 추론 파라미터를 자동으로 식별하여 비용을 절감하고 응답 속도를 개선합니다. **실무자를 위한 교육 및 이벤트 정보** - **무료 마이크로디그리(Microcredentials):** AWS Skill Builder를 통해 실제 라이브 환경에서 구성, 트러블슈팅, 최적화 기술을 검증하는 실무형 인증 과정을 무료로 이용할 수 있습니다. - **AWS Summit Seoul:** 오는 5월 20일 서울에서 개최되는 서밋을 포함하여 전 세계 주요 도시에서 최신 클라우드 및 AI 혁신 사례를 공유하는 오프라인 행사가 진행될 예정입니다. 생성형 AI를 실제 서비스에 적용하려는 개발자라면 Bedrock AgentCore를 통한 신속한 프로토타이핑을 시도해보고, 비용 최적화를 위해 Graviton 기반 인스턴스와 SageMaker의 추론 권장 기능을 적극적으로 활용해 보시기 바랍니다.

PostgreSQL쿠버네티스생성형 AIAWS+4

gitlab·2026년 4월 22일원문

GitLab AI 해커톤 2026: 수상자를 만나보세요 (새 탭에서 열림)

GitLab AI 해커톤 2026은 단순한 코드 생성을 넘어 보안, 컴플라이언스, 배포 등 소프트웨어 개발 전 과정을 자율적으로 수행하는 600개 이상의 AI 에이전트 생태계를 확인한 자리였습니다. 구글 클라우드 및 앤스로픽(Anthropic)과 협업한 이번 행사에는 약 7,000명의 개발자가 참여하여, 실질적인 워크플로우에 통합되어 팀을 대신해 행동하는 혁신적인 솔루션들을 대거 선보였습니다. 이는 AI가 챗봇 형태를 벗어나 복잡한 엔지니어링 문제를 해결하는 능동적인 에이전트로 진화했음을 입증하는 결과입니다. ### 조직 지식 보존과 시스템 이해: LORE 및 GraphDev * **대상(Grand Prize) 수상작 'LORE'**: 8개의 에이전트와 라우터를 활용해 엔지니어의 머릿속에만 있던 '암묵적 지식'을 기록하고 관리합니다. 지식 그래프의 순환 루프 방지 로직과 탄소 추적 기능을 갖췄으며, 해커톤 프로젝트임에도 43개의 테스트 코드를 포함할 정도로 완성도가 높습니다. * **Anthropic 부문 우승작 'GraphDev'**: 코드 간의 연결 고리를 매핑하여 시스템이 시간에 따라 어떻게 변하는지 보여줍니다. 코드 변경 시 미칠 영향을 사전에 시각화하여 복잡한 시스템의 진화 과정을 쉽게 파악할 수 있도록 돕습니다. * **RepoWarden**: 코드의 기능뿐만 아니라 '왜' 그렇게 작성되었는지를 캡처하는 '리빙 스펙 엔진(Living Specification Engine)' 역할을 수행합니다. ### 보안 및 컴플라이언스 자동화 * **보안 자동화 솔루션**: 구글 클라우드 부문 우승작 'Gitdefender'는 코드 리뷰 중 보안 문제를 발견하면 즉시 수정 코드를 작성하고 리뷰를 생성합니다. 'RedAgent'는 AI가 생성한 보안 보고서를 재검증하여 AI 진단 결과에 대한 신뢰 격차를 해소합니다. * **컴플라이언스 관리**: 'Compliance Sentinel'은 머지 요청(MR)의 리스크를 점검해 위반 사항이 있으면 차단하며, 'MR Compliance Auditor'는 증거 자료를 수집해 SOC 2 통제 항목과 매핑한 후 실시간 대시보드로 송출합니다. * **SecurityMonkey**: 테스트 브랜치에 알려진 취약점을 주입하여 현재 보안 스캐너가 이를 얼마나 잘 잡아내는지 점검하는 독특한 접근 방식을 선보였습니다. ### 기술적 완성도와 운영 효율화 * **안전한 마이그레이션**: 'Time-Traveler'는 운영 환경의 복제본을 생성하여 데이터베이스 마이그레이션을 선제적으로 실행해 봄으로써 배포 실패를 방지합니다. 5개의 에이전트가 브릿지로 연결되어 실제 PostgreSQL 환경에서 작동합니다. * **모바일 기반 워크플로우**: 'stregent'는 개발자가 노트북 없이도 WhatsApp을 통해 CI/CD 파이프라인을 모니터링하고 수정 사항을 머지할 수 있는 모바일 우선 경험을 제공합니다. * **문서화 에이전트 'DocSync'**: 감지(Detector), 작성(Writer), 검토(Reviewer)라는 세 단계 에이전트 체계를 통해 문서화 작업을 자동화하며, 신뢰도가 낮을 경우 사람에게 이슈를 생성해 검토를 요청합니다. ### 지속가능성을 고려한 그린 에이전트(Green Agent) * **탄소 배출 최적화**: 'GreenPipe'와 'CarbonLint' 등은 CI/CD 파이프라인과 LLM 실행에 따른 탄소 발자국을 측정하고 보고서를 생성합니다. * **운영 비용 절감**: 일부 프로젝트는 모델 최적화와 에너지 효율적인 아키텍처 설계를 통해 운영 비용을 월 $556에서 $18로 약 96% 절감하는 성과를 거두었습니다. * **실시간 최적화 팁**: 'Carbon Tracker'는 각 파이프라인 작업의 탄소 배출량을 계산하여 머지 요청 시 최적화 팁을 자동으로 댓글로 남겨줍니다. 이제 AI 에이전트는 단순한 도구를 넘어 로컬 지식 그래프와 결합하여 코드의 맥락과 역사를 이해하는 방향으로 발전하고 있습니다. 기업들은 GitLab Duo Agent Platform과 같은 환경을 통해 보안 점검, 데이터베이스 마이그레이션, 컴플라이언스 준수와 같은 고난도 수동 작업을 자동화함으로써 엔지니어링 생산성을 획기적으로 높일 수 있을 것입니다.

PostgreSQL데이터베이스 설계머신러닝CI/CD+4

google·2026년 4월 21일원문

ReasoningBank: 에이전트가 경험을 통해 학습할 수 있도록 하기 (새 탭에서 열림)

ReasoningBank는 에이전트가 배포된 이후에도 성공과 실패의 경험으로부터 일반화된 추론 전략을 추출하여 스스로 진화할 수 있게 돕는 새로운 메모리 프레임워크입니다. 기존 방식이 단순히 실행 기록을 저장하거나 성공 사례만 수집했던 것과 달리, ReasoningBank는 고차원의 전략적 통찰을 구조화하여 저장함으로써 에이전트의 성공률과 작업 효율성을 동시에 개선합니다. 이는 에이전트가 반복적인 실수를 방지하고 복잡한 환경에서 지속적으로 학습하는 '지속적 학습자(Continuous Learner)'로 거듭나게 하는 핵심 기술입니다. **전략적 통찰의 구조화와 추출** - ReasoningBank는 단순히 과거의 행동을 기록하는 것이 아니라, 제목(Title), 설명(Description), 내용(Content)으로 구성된 고차원의 구조화된 메모리 항목을 생성합니다. - '검색-추출-통합'의 연속적인 폐쇄 루프(Closed-loop)를 통해 작동하며, LLM-as-a-judge 기능을 활용해 에이전트의 궤적을 스스로 평가하고 통찰을 도출합니다. - 특히 실패한 경험에서 '반사실적 신호(Counterfactual signals)'를 분석하여, "무한 스크롤 함정에 빠지지 않기 위해 현재 페이지 식별자를 먼저 확인하라"와 같은 예방적 가드레일을 구축하는 데 탁월합니다. **메모리 기반 테스트 시간 확장(MaTTS)** - 추론 시점의 컴퓨팅 자원 확장(Test-time scaling)을 메모리와 결합하여 학습 신호를 극대화하는 MaTTS 기법을 도입했습니다. - **병렬 확장(Parallel scaling):** 동일한 쿼리에 대해 여러 경로를 생성하고 이를 상호 비교함으로써 더 견고한 전략을 합성하고 고품질의 메모리를 생성합니다. - **순차 확장(Sequential scaling):** 단일 작업 내에서 추론을 반복적으로 정제하며, 시행착오 과정에서 발생하는 중간 단계의 통찰을 메모리에 기록합니다. - 이 과정에서 고품질 메모리는 확산된 탐색을 유망한 전략으로 안내하고, 확장된 상호작용은 다시 메모리를 풍부하게 만드는 시너지 효과를 냅니다. **성능 향상 및 전략적 성숙도의 발현** - WebArena 및 SWE-Bench-Verified 벤치마크 평가 결과, 메모리가 없는 기본 모델 대비 성공률이 최대 8.3% 향상되었으며, 작업당 실행 단계는 평균 3단계 가량 단축되었습니다. - 에이전트가 축적된 지식을 바탕으로 점진적으로 발전하는 '전략적 성숙도'가 관찰되었습니다. 초기의 단순한 절차적 체크리스트가 시간이 흐름에 따라 복잡한 조건부 논리 구조를 가진 고급 메모리로 진화했습니다. - 실험 결과 ReasoningBank는 자기 평가 과정의 일부 노이즈에도 강건하게 작동하며, 확장(Scaling)과 결합했을 때 효율성이 더욱 극대화됨이 증명되었습니다. 단순히 성공한 워크플로우를 저장하는 것을 넘어, 실패로부터 배우고 추론 과정을 일반화하는 ReasoningBank의 접근법은 자율형 에이전트의 실용성을 높이는 강력한 도구입니다. 복잡한 소프트웨어 엔지니어링이나 동적인 웹 환경에서 작동하는 에이전트를 설계한다면, 실행 시간의 연산량을 메모리 업데이트로 전환하는 MaTTS 방식의 도입을 적극 고려해 볼 수 있습니다.

PostgreSQL데이터베이스 설계대규모 언어 모델contrastive-learning+4

aws·2026년 4월 20일원문

AWS 주간 요약: Amazon Bedrock의 Claude Opus 4.7, AWS Interconnect 정식 출시 등 (2026년 4월 20일) | Amazon Web Services (새 탭에서 열림)

AWS는 이번 발표를 통해 Anthropic의 가장 강력한 모델인 Claude Opus 4.7의 Amazon Bedrock 출시와 새로운 하이브리드 네트워킹 서비스인 AWS Interconnect의 정식 출시를 알렸습니다. AI 시대의 개발자는 도구에 대체되는 것이 아니라, 시스템 사고와 정교한 통신 역량을 바탕으로 더 높은 수준의 가치를 창출해야 한다는 비전을 제시합니다. 아울러 양자 내성 보안부터 고성능 컴퓨팅 인스턴스에 이르기까지 클라우드 전반의 성능과 보안을 강화하는 다채로운 업데이트가 포함되었습니다. **Claude Opus 4.7 및 Amazon Bedrock 고도화** * Anthropic의 최신 모델인 Claude Opus 4.7이 Bedrock에 출시되어 코딩, 장기 실행 에이전트, 전문 지식 업무에서 향상된 성능을 제공하며, 특히 SWE-bench Pro에서 64.3%의 높은 점수를 기록했습니다. * 요청의 복잡도에 따라 사고 토큰 예산을 동적으로 할당하는 '적응형 사고(Adaptive thinking)' 기능과 100만 토큰의 방대한 컨텍스트 윈도우를 지원합니다. * 고해상도 이미지 지원 기능이 추가되어 복잡한 차트, 밀집된 문서, 스크린 UI에 대한 분석 정확도가 크게 개선되었습니다. **멀티클라우드 및 라스트 마일 연결성 강화 (AWS Interconnect)** * 'AWS Interconnect - Multicloud'를 통해 AWS VPC와 타사 클라우드(Google Cloud 등) 간의 Layer 3 프라이빗 연결을 지원하며, 트래픽은 공용 인터넷을 거치지 않고 전용 백본망을 통해 전송됩니다. * 'AWS Interconnect - Last Mile'은 지사나 데이터 센터에서 AWS로의 고속 프라이빗 연결을 단순화하며, 최대 100Gbps 대역폭과 MACsec 암호화를 기본으로 제공합니다. * AWS는 관련 사양을 GitHub에 오픈 소스로 공개하여 다른 클라우드 제공업체들도 Interconnect 파트너가 될 수 있는 개방형 생태계를 구축했습니다. **개발 및 보안 운영의 자동화와 최적화** * **현대화 도구:** AI 에이전트 기반 마이그레이션 서비스인 'AWS Transform'이 VS Code 확장으로 제공되어, Java/Python 버전 업그레이드나 VB6 레거시 앱의 .NET Core 전환 작업을 IDE 내에서 직접 수행할 수 있습니다. * **보안 강화:** AWS Secrets Manager가 ML-KEM 기반의 하이브리드 양자 내성 TLS를 지원하기 시작하여 미래의 양자 컴퓨팅 위협으로부터 기밀 정보를 보호합니다. * **데이터 관리:** Amazon ECR의 풀스루 캐시가 OCI 참조(이미지 서명, SBOM 등) 동기화를 지원하여 컨테이너 보안 검증 워크플로우를 간소화했습니다. * **고성능 컴퓨팅:** 6세대 인텔 제온 프로세서 기반의 EC2 C8in/C8ib 인스턴스가 정식 출시되어, 이전 세대 대비 최대 43% 향상된 성능과 최대 600Gbps의 네트워크 대역폭을 제공합니다. **비용 관리 및 서버리스 고도화** * Amazon Bedrock에 IAM 주체별 세부 비용 속성 기능이 추가되어, 팀이나 프로젝트 단위로 AI 추론 비용을 정확하게 정산하고 관리할 수 있게 되었습니다. * Aurora DSQL은 PHP 전용 커넥터를 출시하여 IAM 토큰 생성, SSL 설정, 커넥션 풀링 등의 작업을 자동화함으로써 서버리스 데이터베이스 활용도를 높였습니다. 이번 업데이트는 AI 에이전트의 자율성을 극대화하고 멀티클라우드 환경의 네트워킹 장벽을 낮추는 데 중점을 두고 있습니다. 개발자들은 Claude Opus 4.7의 강화된 추론 능력과 AWS Transform 같은 자동화 도구를 적극 활용하여 레거시 시스템 현대화 속도를 높이고, 강화된 네트워킹 성능을 바탕으로 더 견고한 분산 시스템을 설계할 것을 권장합니다.

PostgreSQL쿠버네티스amazon-bedrockDevOps+4

cloudflare·2026년 4월 20일원문

우리가 배포하는 플랫폼 위에 내부적으로 구축한 AI 엔지니어링 스택 (새 탭에서 열림)

Cloudflare는 자사 플랫폼의 기술력을 집약한 내부 AI 엔지니어링 스택을 구축하여 전체 R&D 인력의 93%가 AI 도구를 일상적으로 사용하는 환경을 조성했으며, 그 결과 주간 머지 리퀘스트(Merge Request) 수를 약 두 배 가까이 증가시키는 생산성 혁신을 이뤄냈습니다. 이들은 단순한 도구 도입을 넘어 MCP(Model Context Protocol), AI Gateway, Workers AI 등을 결합한 포괄적인 아키텍처를 통해 보안과 운영 효율성을 동시에 확보했습니다. 특히 이번 프로젝트는 실제 고객에게 제공되는 상용 제품들을 내부 워크플로우에 직접 적용하여 그 실효성을 검증했다는 점에서 중요한 기술적 이정표를 제시합니다. ### 통합 플랫폼 및 보안 계층 * **보안 및 인증 관리**: Cloudflare Access를 통한 제로 트러스트 인증으로 보안을 강화하고, 모든 LLM 요청을 AI Gateway로 라우팅하여 중앙 집중식 키 관리, 비용 추적 및 데이터 보존 정책을 적용합니다. * **Workers AI 활용**: 프론티어 모델(OpenAI, Anthropic 등)뿐만 아니라 Workers AI를 통해 Kimi K2.5와 같은 오픈 소스 모델을 병행 운용하며, 특히 보안 에이전트 등의 작업에서 상용 모델 대비 약 77%의 비용 절감 효과를 거두고 있습니다. * **프록시 워커 패턴**: 모든 클라이언트 요청을 단일 프록시 워커를 통해 처리함으로써 클라이언트 설정 변경 없이도 사용자별 권한 부여 및 모델 카탈로그 관리가 가능한 제어 평면(Control Plane)을 구축했습니다. ### 에이전트 기반 인프라와 MCP * **원스톱 온보딩**: `opencode auth login` 명령 하나로 MCP 서버, 에이전트, 명령 및 권한 설정을 자동으로 구성하여 엔지니어가 설정 파일에 손대지 않고도 즉시 AI 도구를 사용할 수 있게 했습니다. * **상태 유지 및 격리 실행**: Durable Objects 기반의 Agents SDK를 사용해 장기 실행되는 에이전트 세션을 관리하며, Sandbox SDK를 통해 에이전트가 생성한 코드를 안전한 격리 환경에서 빌드하고 테스트합니다. * **워크플로우 자동화**: 복잡한 다단계 엔지니어링 작업은 Workflows 기능을 통해 자동화하며, 이는 대규모 리포지토리 전반에 걸친 변경 사항 전파를 효율적으로 지원합니다. ### 지식 체계와 품질 관리 * **기술 지식 그래프**: 오픈소스인 Backstage를 활용해 16,000개 이상의 엔티티를 포함한 지식 그래프를 구축함으로써 에이전트가 조직 내 복잡한 시스템 구조를 정확히 이해할 수 있도록 지원합니다. * **AGENTS.md와 코드 리뷰**: 각 저장소의 컨텍스트를 담은 `AGENTS.md` 파일을 생성하여 에이전트의 정확도를 높이고, CI 파이프라인에 통합된 AI 코드 리뷰어를 통해 급증하는 코드 생산량 속에서도 품질을 유지합니다. Cloudflare의 사례는 AI 도입을 고민하는 기업들에게 '플랫폼 중심 접근법'의 중요성을 시사합니다. 단순한 챗봇 도입이 아니라, 중앙 집중식 게이트웨이를 통한 가시성 확보, 격리된 샌드박스 실행 환경 구축, 그리고 내부 지식 시스템(Backstage 등)과의 결합이 뒷받침될 때 비로소 실제적인 엔지니어링 생산성 향상을 기대할 수 있습니다.

PostgreSQL데이터베이스 설계CI/CD오픈 소스+4