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

샤이훌루드 모방 캠페인, PyPI 타이포스쿼팅으로 파이썬 개발자 노려

2026년 6월, GitLab은 PyPI를 대상으로 한 Shai-Hulud 악성코드 모방 공급망 공격을 발견했다. 공격자는 Flask·Requests·NumPy의 오타 패키지와 정상 프로젝트를 변조한 패키지에 설치 시 자동 실행되는 자격 증명 탈취 웜을 삽입했다. 이 웜은 CI/CD와 클라우드 자격 증명을 훔칠 뿐 아니라 GitHub 저장소와 패키지 레지스트리에 악성 코드를 퍼뜨려 추가 감염을 시도한다. ## 공격 대상 패키지와 위장 방식 - 공격 패키지 5개는 모두 PyPI 계정 `elitexp`에서 배포됐다. - 오타 패키지: - `rlask`, `tlask`: Flask 사칭 - `rsquests`: Requests 사칭 - `nhmpy`: NumPy 사칭 - `mflux-streamlit`은 원래 정상적으로 사용되던 프로젝트였지만, 공격자가 버전 `0.0.3`, `0.0.4`를 악성 버전으로 변조했다. - 공격자는 먼저 실제 최신 버전과 동일한 “탐색용” 정상 패키지를 등록한 뒤, 악성 페이로드가 포함된 후속 버전을 배포했다. - 따라서 단순 오타 입력뿐 아니라, 기존 프로젝트의 정상적인 의존성 업데이트도 감염 경로가 될 수 있다. ## `.pth` 파일을 이용한 설치 시 자동 실행 - npm 기반 Shai-Hulud 변종이 `preinstall` 스크립트를 사용한 것과 달리, 이번 공격은 Python의 `.pth` 메커니즘을 악용했다. - Python은 시작 시 패키지에 포함된 `.pth` 파일을 자동 처리하므로, 사용자가 악성 모듈을 직접 import하거나 함수를 호출하지 않아도 코드가 실행될 수 있다. - 예시 파일은 `rlask-setup.pth`이며, 임시 디렉터리의 `.bun_ran` 마커 파일을 확인한 뒤 다음 작업을 수행한다. - GitHub에서 Bun JavaScript 런타임 다운로드 - 패키지에 포함된 약 5MB 크기의 난독화 JavaScript 실행 - 마커 파일을 이용해 반복 실행 방지 - 초기 `rlask` 버전에는 Python 시작 시 자동 import되는 `sitecustomize.py`도 포함되어 `_index.js`를 실행하는 보조 경로가 있었다. - 이후 버전에서는 `.pth` 실행 방식만 남겨 공격 구조를 단순화했다. ## 다층 난독화와 페이로드 구성 - JavaScript 페이로드는 세 단계로 난독화됐다. - 정수 배열에 ROT-N 문자 치환 적용 - AES-128-GCM으로 두 개의 데이터 블록 암호화 - `_0x` 접두사의 변수명 난독화 - 패키지마다 ROT 값이 달랐다. - `rlask`: ROT-13 - `rsquests`: ROT-17 - `tlask`: ROT-25 - 분석 결과: - 첫 번째 블록 약 907바이트: Bun 런타임 다운로드 코드 - 두 번째 블록 약 772KB: Shai-Hulud 자격 증명 탈취 웜 전체 - 두 번째 페이로드에는 2,538개의 하드코딩된 문자열이 포함돼 있었다. - GitLab 연구팀은 실제 실행 없이 정적 분석만으로 페이로드를 복호화했다. ## 광범위한 자격 증명 탈취 웜은 주요 클라우드, CI/CD, 패키지 저장소와 개발 환경을 폭넓게 탐색한다. - GitHub: - `GITHUB_TOKEN`, 개인·Fine-grained 토큰 - OIDC 토큰, 조직·저장소 시크릿 - Actions 아티팩트와 러너 프로세스 메모리 - AWS: - IAM 액세스 키와 시크릿 키 - 세션 토큰, STS 토큰 - IMDS 주소 `169.254.169.254`의 인스턴스 자격 증명 - Secrets Manager와 SSM 파라미터 - Azure 및 GCP: - 클라이언트 시크릿, 관리형 ID 토큰, Key Vault 시크릿 - 서비스 계정 키와 Application Default Credentials - HashiCorp Vault: - `/var/run/secrets/vault-token`, `/etc/vault/token`, `/root/.vault-token` 등 알려진 경로 - API 및 Kubernetes 인증 정보 - 패키지 저장소: - npm, JFrog/Artifactory, PyPI, RubyGems 토큰 - OIDC 토큰 교환 정보 - 기타: - SSH 개인 키 - Kubernetes 서비스 계정 토큰과 kubeconfig - Sigstore OIDC 토큰 및 Fulcio 서명 인증서 - MongoDB, MySQL, PostgreSQL, Redis 접속 문자열과 비밀번호 ## 자격 증명 탈취를 넘어선 자기 전파 - 이 악성코드는 단순한 정보 탈취기가 아니라 훔친 권한을 이용해 다른 환경으로 확산하는 웜이다. - 접근 가능한 GitHub 저장소에 다음 파일을 커밋한다. - `.github/setup.js` - GitHub Actions 워크플로 파일 - 이를 통해 다른 CI 파이프라인에서 악성 코드가 다시 실행되도록 만든다. - `.github/copilot-instructions.md`를 삽입해 AI 코딩 도구의 동작을 오염시키려 한다. - 훔친 레지스트리 토큰으로 PyPI, npm, RubyGems에 추가 악성 패키지를 배포한다. - 자체 호스팅 CI 러너에서는 `sudoers` 규칙을 삽입해 권한 상승을 시도한다. - StepSecurity의 `harden-runner`가 존재하는지 확인하고 탐지되면 동작을 조정한다. ## 공격자와 정상 프로젝트 변조 - PyPI 계정 `elitexp`는 2024년 11월 생성됐으며, 원래 정상 패키지 `mflux-streamlit`을 보유하고 있었다. - 연결된 GitHub 계정은 13년 이상 된 계정으로, 대학 과제와 Laravel 프로젝트 등 다수의 공개 저장소가 있어 신뢰성을 높이는 데 활용됐을 가능성이 있다. - 모든 패키지의 업로드에는 `Bun/1.3.14` 사용자 에이전트가 사용됐다. - 공격자는 악성코드 실행 과정에서도 동일한 Bun 런타임을 다운로드한다. - `mflux-streamlit`의 `0.0.1`, `0.0.2`는 정상 버전이지만, 이후 `0.0.3`, `0.0.4`에는 동일한 `.pth` 드로퍼와 난독화 페이로드가 포함됐다. - 정상 프로젝트의 기존 사용자까지 일반적인 업데이트 과정에서 감염될 수 있다는 점이 전형적인 typosquatting보다 위험하다. ## 실용적인 대응 권고 - `rlask`, `tlask`, `rsquests`, `nhmpy`, `mflux-streamlit`의 악성 버전 설치 여부를 확인하고 즉시 제거한다. - 해당 패키지가 설치된 환경에서는 CI/CD, 클라우드, 패키지 저장소, SSH 관련 자격 증명을 모두 폐기하고 재발급한다. - GitHub 저장소의 워크플로와 `.github/setup.js`, `.github/copilot-instructions.md` 변경 이력을 점검한다. - Python 패키지 설치 시 패키지명뿐 아니라 유지보수자, 배포 이력, 버전 변화, 해시를 검증한다. - CI 환경에서는 최소 권한 토큰, 짧은 수명의 자격 증명, 네트워크 제한, 패키지 허용 목록을 적용하는 것이 안전하다.

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

쿠버네티스CI/CDPythonsupply-chain-security+2

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

AWS 주간 요약: Amazon RDS for SQL Server의 BYOM, Swift용 AWS IoT Device SDK 등 (2026년 6월 8일) | Amazon Web Services

AWS 이번 주 주요 소식은 Swift 기반 IoT 개발의 본격화와 기업용 AWS 서비스의 안정성·보안·AI 기능 강화에 초점이 맞춰져 있다. AWS IoT Device SDK for Swift가 정식 출시되어 MQTT 5, Device Shadow, Jobs, 플릿 프로비저닝을 macOS·iOS·tvOS·Linux에서 사용할 수 있게 됐다. 또한 RDS for SQL Server의 기존 라이선스 재사용, Cognito 멀티 리전 복제, Bedrock의 OpenAI 모델 지원 등 기업 환경을 겨냥한 기능도 확대됐다. ### Swift 기반 IoT와 엣지 컴퓨팅의 확장 - AWS IoT Device SDK for Swift가 정식 출시됐다. - 다음 기능을 제공한다. - 프로덕션 수준의 MQTT 5 연결 - Device Shadow를 통한 디바이스 상태 동기화 - Jobs를 이용한 원격 작업 및 업데이트 - 플릿 프로비저닝을 통한 대규모 디바이스 등록 - macOS, iOS, tvOS, Linux에서 Swift로 IoT 애플리케이션을 개발할 수 있다. - 서버 측 Swift, IoT, 엣지 컴퓨팅의 결합이 확대되고 있으며, WendyOS처럼 NVIDIA Jetson과 Raspberry Pi에서 Swift 애플리케이션 배포를 지원하는 프로젝트도 등장하고 있다. ### Amazon RDS for SQL Server의 BYOM 지원 - 온프레미스에서 SQL Server 애플리케이션을 이전하는 고객은 기존 Microsoft SQL Server 라이선스를 Amazon RDS에서 재사용할 수 있다. - Microsoft Software Assurance가 포함된 라이선스는 Microsoft License Mobility 프로그램을 통해 적용할 수 있다. - Bring Your Own Media(BYOM)는 AWS License Manager와 통합된다. - 이를 통해 라이선스 사용량을 추적하고 규정 준수 상태를 관리할 수 있다. - 기존 라이선스 투자를 활용할 수 있어 SQL Server 마이그레이션 비용 절감에 도움이 된다. ### Amazon Cognito 멀티 리전 복제 - Cognito 사용자 풀의 사용자 및 머신 ID 데이터를 보조 리전에 거의 실시간으로 동기화할 수 있다. - 복제 대상에는 다음 항목이 포함된다. - 자격 증명 - 사용자 풀 구성 - 연동 및 페더레이션 설정 - 기본 리전에 장애가 발생해도 로그인 상태의 사용자는 재인증 없이 애플리케이션을 계속 이용할 수 있다. - 등록 사용자는 기존 자격 증명으로 보조 리전에서 로그인할 수 있다. - Essentials 또는 Plus 기능 티어에서 애드온으로 제공되며, 16개 리전에서 지원된다. ### Amazon Bedrock의 OpenAI 모델 및 개발 도구 지원 - GPT-5.5, GPT-5.4, Codex가 Amazon Bedrock에서 정식 제공된다. - GPT-5.5는 에이전트 기반 코딩, 데이터 분석, 다단계 자율 작업에 강점을 가진다. - Codex는 다음 환경에서 사용할 수 있다. - Codex App - Codex CLI - Visual Studio Code - JetBrains IDE - Xcode - AWS의 기존 보안, 거버넌스, 운영 관리 체계 안에서 OpenAI 모델을 사용할 수 있다. - 가격은 OpenAI의 직접 제공 가격과 동일하며, 사용량은 기존 AWS 약정에 포함된다. ### Bedrock 관측성·콘솔·보안 기능 개선 - OpenAI 및 Anthropic 호환 API용 `bedrock-mantle` 엔드포인트에 CloudWatch 지표가 추가됐다. - 계정, 프로젝트, 모델, 프로젝트-모델 단위로 다음 정보를 모니터링할 수 있다. - 추론 요청 수 - 입력·출력 토큰 수 - 클라이언트 오류 수 - 호환 API에 최적화된 Bedrock 콘솔이 새롭게 개편됐다. - 모델 카탈로그 - 모델 나란히 비교 - 프로젝트 기반 구성 - 미리 채워진 코드 예제가 포함된 프로젝트별 문서 - Bedrock AgentCore Identity는 기존 AWS Secrets Manager 시크릿 ARN을 직접 참조할 수 있게 됐다. - 고객은 자체 KMS 키, 태깅 전략, 자동 로테이션 등 시크릿 관리 정책을 유지할 수 있다. ### 에이전트와 워크플로 자동화 - AWS Step Functions에 Bedrock AgentCore 기반의 에이전트 추론 단계가 추가됐다. - 워크플로에서 여러 AI 에이전트를 병렬 또는 순차적으로 실행할 수 있다. - 사람의 승인 단계를 삽입할 수 있어 자동화와 통제를 함께 구현할 수 있다. - 각 에이전트의 판단 과정을 추적할 수 있어 감사와 디버깅에 유리하다. ### 컨테이너 및 Kubernetes 기능 업데이트 - Amazon EKS와 EKS Distro가 Kubernetes 1.36을 지원한다. - 주요 변경 사항은 다음과 같다. - User Namespaces 정식 지원 - Mutating Admission Policies - Pod 단위 리소스의 인플레이스 수직 확장 - 리소스 상태 보고 기능 - ECS Managed Instances는 AWS Trainium과 Inferentia를 지원한다. - Inferentia2, Trainium1, Trainium2 인스턴스를 용량 공급자로 구성할 수 있다. - ECS가 워크로드에 필요한 가속기 리소스를 자동으로 할당한다. ### 네트워크 연결·비용 분석·위치 서비스 - Amazon Quick은 VPC를 통해 사설 MCP 서버에 연결할 수 있다. - 내부 애플리케이션과 도구를 인터넷에 노출하지 않고 Amazon Quick에서 사용할 수 있다. - AWS Cost and Usage Report 2.0은 Athena와 Redshift 통합을 지원한다. - 선택한 쿼리 엔진에 맞는 형식으로 비용 데이터를 전달하고, 테이블 정의와 데이터 로딩 지침도 제공한다. - Amazon Location Service Routes API에는 대중교통 및 복합 이동 경로가 추가됐다. - Transit과 Intermodal 모드를 통해 대중교통, 도보, 자동차, 택시, 렌터카를 조합한 경로를 계획할 수 있다. - 해당 기능은 13개 리전에서 제공된다. ### 실용적인 시사점 - SQL Server를 AWS로 이전한다면 기존 라이선스와 Software Assurance를 활용할 수 있는지 확인하는 것이 좋다. - 글로벌 서비스의 인증 연속성이 중요하다면 Cognito 멀티 리전 복제를 검토할 만하다. - Bedrock을 도입하는 팀은 CloudWatch 토큰·오류 지표와 Secrets Manager 연동을 함께 구성해 비용과 보안을 관리하는 것이 바람직하다. - IoT 제품을 Swift 생태계로 개발하거나 Apple 기기와 엣지 하드웨어를 함께 운영하려는 경우 AWS IoT Device SDK for Swift가 유력한 선택지가 될 수 있다.

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

쿠버네티스amazon-bedrockedge-computingamazon-rds+3

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에 동기 복제를 적용하기보다, 실제 페일오버 후보에만 동기 복제를 적용해 성능과 내구성의 균형을 맞추는 접근이 적절하다. 또한 네트워크 지연과 영역 장애를 가정한 게임데이 및 복제 지연 기반의 페일오버 테스트를 정기적으로 수행해야 한다.

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

쿠버네티스PostgreSQLhigh-availabilitydatabase-replication+4

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

ODW #7: 세 가지 방법으로 토큰 소비량 40% 절감! ADK를 이용한 컨텍스트 엔지니어링

LY Corporation의 워크숍은 AI 에이전트의 비용 증가와 응답 정확도 저하를 해결하기 위해 컨텍스트 엔지니어링을 소개한다. 핵심은 LLM에 전달하는 프롬프트, 도구 정의, 대화 이력, 외부 데이터를 무조건 많이 제공하는 것이 아니라 작업에 필요한 고품질 정보만 적절한 형태로 선별하는 것이다. ADK의 구조화 스키마, AgentTool, MCP 도구 필터링을 활용하면 토큰 사용량을 줄이면서도 장시간 실행 에이전트의 정확도를 개선할 수 있다. ## 사내 AI 활용 확대에 따른 문제 - Claude Code, Cline, ADK 등 AI 도구의 사용자가 늘면서 토큰 소비량이 급증했다. - 프롬프트에 명시한 지시를 AI가 무시하거나 중요한 정보를 누락하는 문제가 발생했다. - 대화가 길어질수록 AI가 이전 맥락에 묻혀 엉뚱한 답변을 생성하기도 했다. - 주요 원인은 LLM에 전달되는 컨텍스트를 체계적으로 관리하지 않았기 때문이다. - 토큰 증가 요인에는 다음이 포함된다. - AI 사용 인구 증가 - 원하는 결과를 얻기 위한 반복 작업 - 싱글 에이전트에서 멀티 에이전트로의 확장 - 단발성 작업에서 장시간 실행 작업으로의 변화 - MCP 도구 정의 자체가 차지하는 토큰 - 컨텍스트 최적화 기법의 확산 부족 ## 컨텍스트 부패와 토큰 관리 - LLM 사용 비용은 입력과 출력에 사용된 총 토큰 수를 기준으로 산정된다. - 장시간 실행되는 에이전트에서는 대화 이력과 중간 결과가 계속 축적된다. - 현재 작업과 관계없는 정보가 컨텍스트에 남으면 중요한 신호가 노이즈에 묻힌다. - 이로 인해 컨텍스트 윈도 압박, 관련성 저하, 응답 정확도 하락이 발생한다. - 해결책은 필요한 정보만 추려 LLM에 전달하는 것이다. ## 컨텍스트 엔지니어링의 개념과 원칙 컨텍스트 엔지니어링은 에이전트가 사용하는 모든 문맥 정보를 설계하고 최적화하는 방법이다. - 관리 대상은 세 가지로 나뉜다. - **정적 컨텍스트**: 시스템 프롬프트, 도구 정의 - **동적 컨텍스트**: 사용자 메시지, 대화 이력, RAG 데이터 - **장기 컨텍스트**: 장시간 실행 중 축적되는 정보와 세션 상태 - 핵심 원칙은 “고품질 신호를 가진 최소한의 토큰 집합”을 찾는 것이다. - 정보를 너무 적게 주면 AI가 추측에 의존한다. - 정보를 지나치게 많이 주면 비용이 증가하고 핵심 정보가 묻힌다. - 따라서 작업에 필요한 수준으로 구체적이면서도 불필요한 정보는 제거해야 한다. - 프롬프트 엔지니어링이 지시문 작성에 초점을 둔다면, 컨텍스트 엔지니어링은 프롬프트뿐 아니라 도구, 데이터, 이력, 상태까지 포함해 전체 입력 환경을 최적화한다. ## ADK를 활용하는 이유 Google의 오픈소스 AI 에이전트 프레임워크인 ADK는 컨텍스트 엔지니어링을 팀 단위로 적용하기에 적합하다. - 개인의 CLI 숙련도에 의존하지 않고 팀의 지식을 에이전트 설계에 반영할 수 있다. - UI, API 서버, 평가 기능, 멀티 에이전트 구성을 제공한다. - 에이전트를 조합하고 도구처럼 호출할 수 있어 컨텍스트를 분리하기 쉽다. - 컨텍스트 엔지니어링을 위한 9개 핵심 컴포넌트를 조합해 사용할 수 있다. ## 주요 ADK 컴포넌트 실습에서는 다음 세 가지 기능을 중심으로 설명한다. - **Structuring Data** - 입력과 출력을 특정 JSON 스키마로 강제한다. - 에이전트 간 데이터 전달 형식을 명확히 한다. - 불필요한 자연어 설명을 줄여 토큰 사용량을 절감한다. - **AgentTool** - 다른 에이전트를 함수나 도구처럼 호출한다. - 하위 에이전트의 내부 도구와 중간 컨텍스트를 호출자에게 노출하지 않는다. - 최종 결과만 반환해 상위 에이전트의 컨텍스트 누적을 막는다. - **MCP Toolset의 `tool_filter`** - MCP 서버가 제공하는 도구 중 필요한 도구만 선택한다. - 예를 들어 Jira 티켓 검색에는 `jira_search`, 상세 조회에는 `jira_get_issue`만 허용할 수 있다. - 불필요한 도구 정의를 제거해 토큰 비용과 LLM의 판단 부담을 줄인다. ## Jira 주간 보고서 에이전트: v1의 문제 v1은 하나의 에이전트가 Jira 티켓 검색, 개별 티켓 상세 조회, 분석, 보고서 작성을 모두 수행하는 구조다. - 단일 에이전트에 Jira 관련 도구를 모두 제공한다. - 티켓마다 상세 정보를 가져와 같은 컨텍스트에 계속 축적한다. - 티켓 수가 증가할수록 컨텍스트가 커지고 컨텍스트 부패가 발생한다. - 여러 도구의 정의와 중간 결과가 함께 전달되어 토큰 사용량이 커진다. - 장시간 작업에서 중요한 티켓 정보와 불필요한 이전 정보가 섞일 가능성이 높다. ## Jira 주간 보고서 에이전트: v2의 개선 v2는 역할을 분리한 2-에이전트 구조로 변경했다. - **루트 에이전트** - Jira 티켓 목록을 검색한다. - 개별 티켓 분석 에이전트를 호출한다. - 각 분석 결과를 Markdown 표 형태의 주간 보고서로 집계한다. - **개별 티켓 분석 에이전트** - 하나의 Jira 티켓만 담당한다. - `issue_key`를 입력으로 받고 `report`를 구조화된 출력으로 반환한다. - Jira 상세 조회 도구인 `jira_get_issue`만 사용할 수 있다. - 사실만 포함하고 추측은 금지하도록 지시된다. - `AgentTool`을 통해 하위 에이전트의 내부 처리 과정은 루트 에이전트에 노출하지 않는다. - `input_schema`와 `output_schema`로 에이전트 간 데이터 형식을 제한한다. - `tool_filter`로 각 에이전트가 실제로 필요한 MCP 도구만 사용하게 한다. - 결과적으로 티켓별 상세 분석 컨텍스트가 루트 에이전트에 불필요하게 누적되는 것을 줄인다. AI 에이전트를 설계할 때는 프롬프트를 길게 작성하는 것보다 어떤 정보를 언제, 어떤 형식으로 전달할지 먼저 설계하는 것이 중요하다. 특히 작업을 하위 에이전트로 분리하고, 입력·출력 스키마와 도구 필터를 적용하면 비용과 정확도를 함께 개선할 수 있다.

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

쿠버네티스대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜+3

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

코딩은 더 이상 제약이 아니다: Spotify에서 팀과 에이전트를 위한 개발자 경험 확장 | Spotify Engineering

Spotify는 AI 코딩 에이전트 도입으로 개발 속도가 크게 향상되면서, 이제 코딩 자체보다 의사결정과 개발 경험의 확장성이 새로운 병목이 되었다고 설명합니다. 수년간 구축한 자동화 시스템, 내부 개발자 포털, 표준화된 기술 스택이 AI 에이전트의 성능과 신뢰성을 높이는 기반이 되었습니다. 그 결과 99% 이상의 엔지니어가 매주 AI 코딩 도구를 사용하고, 풀 리퀘스트 생성 빈도도 76% 증가했습니다. ## AI 코딩 도구의 폭발적인 확산 - Spotify 엔지니어의 99% 이상이 매주 AI 코딩 도구를 사용합니다. - 94%는 AI가 생산성을 높였다고 응답했습니다. - 풀 리퀘스트 생성 빈도는 76% 증가했습니다. - 대부분의 PR은 개발자와 AI 에이전트가 협업해 작성합니다. - 특히 Claude Opus 4.5 출시 이후 Claude Code 사용량이 급격히 증가했습니다. - Spotify는 과거에도 내부 생산성 도구를 꾸준히 배포했지만, AI 도구만큼 빠른 채택률은 경험하지 못했습니다. ## 에이전트 이전부터 시작된 자동화 - Spotify의 운영 코드베이스는 엔지니어 수보다 7배 빠르게 증가했습니다. - 개발자들은 기능 개발보다 다음과 같은 유지보수 작업에 더 많은 시간을 쓰게 되었습니다. - 의존성 업그레이드 - API 마이그레이션 - 보안 취약점 패치 - 특히 마이그레이션이 개발자 불만의 가장 큰 원인이었습니다. - 이를 해결하기 위해 여러 팀이 각자 수작업으로 처리하는 대신, 수백~수천 개 컴포넌트를 한꺼번에 변경하는 Fleet Management를 구축했습니다. - Fleetshift는 대상 식별, 작업 예약, 진행 상황 추적 등 전체 변경 작업을 조율합니다. - 지금까지 250만 건 이상의 자동화 유지보수 PR을 병합했으며, 대부분은 사람의 개입 없이 자동 병합되었습니다. ## Honk: 백그라운드 코딩 에이전트 - 단순한 변경에는 결정론적 스크립트가 효과적이었지만, API 교체나 대규모 리팩터링처럼 예외가 많은 작업에서는 한계가 있었습니다. - Spotify는 복잡한 스크립트를 계속 추가하는 대신 LLM이 코드 수정 작업을 수행하도록 했고, 그 결과 Honk를 만들었습니다. - Honk의 구성은 다음과 같습니다. - Claude와 Agent SDK 기반 - Spotify 자체 실행 하네스와 결합 - Kubernetes 파드에서 실행 - 여러 에이전트 세션을 클라우드에서 동시에 스케줄링 - 여러 운영체제에서 CI 빌드를 실행해 변경 사항 검증 - Fleetshift가 전체 작업을 관리하고 Honk가 실제 코드 수정을 담당합니다. - 최근 백엔드 서비스의 Java 마이그레이션은 한 명의 엔지니어가 3일 만에 완료했습니다. - 과거 수백 팀이 수주 또는 수개월에 걸쳐 수행하던 작업을 단일 엔지니어가 며칠 안에 처리할 수 있게 되었습니다. - Honk는 Slack에서도 호출할 수 있어, 대화 중 언급하면 맥락을 바탕으로 작업하고 PR을 생성합니다. - Honk v2에서는 다음 기능을 도입할 예정입니다. - 공유 에이전트 세션 - 팀 프로젝트 - Chirp를 통한 에이전트 오케스트레이션 - 여러 개발자와 에이전트의 협업 ## 에이전트에게도 필요한 개발자 경험 - Spotify는 “세계 최고 수준의 기술 영역을 적게 만들수록 더 빠르게 움직일 수 있다”는 원칙을 오래 유지해 왔습니다. - 제한된 기술 스택과 일관된 설계 패턴을 사용하면 다음 효과가 있습니다. - 팀 간 협업이 쉬워짐 - 기술 선택에 따른 불필요한 의사결정 감소 - 코드베이스에 대한 공통 전문성 향상 - 개발자와 에이전트가 참고할 수 있는 일관된 코드 증가 - Claude는 참고할 코드가 많고 그 구조가 일관될수록 더 나은 결과를 냅니다. - 반대로 코드베이스가 파편화되어 있으면 에이전트 성능도 측정 가능하게 저하됩니다. ## Backstage를 통한 통합과 표준화 - Spotify는 오픈소스 내부 개발자 포털인 Backstage를 개발 경험의 중심으로 사용합니다. - Backstage 이전에는 배포, CI, A/B 테스트 등 기능별로 약 100개의 내부 도구가 분리되어 있었습니다. - Backstage는 이를 하나의 화면으로 통합하고, 소프트웨어 컴포넌트 카탈로그를 중심으로 관리합니다. - 개발자와 에이전트 모두 Backstage에서 다음 정보를 확인할 수 있습니다. - 컴포넌트 소유 팀 - 관련 문서 - 기술 구성 - 담당자와의 커뮤니케이션 경로 - Spotify는 Backstage 기능을 MCP와 CLI 도구로 노출해 Claude도 동일한 정보를 활용하도록 했습니다. - 에이전트는 필요한 컴포넌트의 담당자를 조회하거나 문서를 읽고, Slack으로 책임 팀에 문의할 수 있습니다. ## Golden State와 자동 피드백 - Golden state는 컴포넌트 유형별 권장 기술과 개발 관행을 정의합니다. - Soundcheck는 각 팀이 자신의 컴포넌트가 표준을 얼마나 준수하는지 점검하는 UI를 제공합니다. - 정적 분석과 린팅을 결합하면 표준이 단순한 문서가 아니라 실제 가드레일로 작동합니다. - Claude가 권장되지 않는 기술이나 설계 패턴을 사용하면 린터가 즉시 피드백을 제공합니다. - 에이전트는 이 피드백을 바탕으로 스스로 코드를 수정할 수 있습니다. - 같은 피드백 루프가 개발자와 에이전트 모두에게 적용되므로, 조직 전체의 일관성을 유지하는 효과적인 수단이 됩니다. ## 실용적인 결론 AI 에이전트를 도입하려면 모델 자체보다 먼저 일관된 기술 스택, 중앙화된 컴포넌트 정보, 자동화된 검증 체계를 마련해야 합니다. 표준화된 코드베이스와 즉각적인 린트·CI 피드백이 갖춰질 때 에이전트는 대규모 마이그레이션과 유지보수 작업을 안정적으로 수행할 수 있습니다.

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

쿠버네티스AI 에이전트CI/CDslack+4

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

Kubernetes에서 Gitaly로 GitLab 스택 통합하기

GitLab 18.11부터 Gitaly on Kubernetes가 정식 지원되면서, GitLab의 모든 구성 요소를 Kubernetes에서 운영할 수 있게 되었습니다. 기존의 Kubernetes와 VM을 함께 사용하는 하이브리드 구조를 없애고, 인프라 운영과 모니터링을 단일 Kubernetes 환경으로 통합할 수 있습니다. 다만 현재 Gitaly Cluster(Praefect)는 Kubernetes를 아직 지원하지 않아 완전한 고가용성은 제공되지 않습니다. ### Kubernetes 환경에 맞춘 Gitaly의 변화 - Git 작업은 메모리 사용량이 크고 패턴을 예측하기 어렵습니다. - Gitaly는 Git 프로세스를 별도 cgroup에서 실행해 메모리 초과로 프로세스가 종료되더라도 주 Gitaly 프로세스가 영향을 받지 않도록 합니다. - Kubernetes에서 이 구조를 구현하기 위해 다음 작업이 필요했습니다. - `containerd` 환경에서 cgroupfs에 쓰기 권한을 부여 - init container로 `/sys/fs/cgroup`를 마운트 - 해당 경로를 쓰기 가능하도록 설정 - 이를 통해 Git 프로세스의 OOM(메모리 부족) 종료가 Gitaly 전체 장애로 이어지는 것을 방지합니다. ### Pod 재시작과 서비스 중단 문제 - VM에서는 Omnibus가 Gitaly 바이너리를 교체하고 소켓을 유지한 채 graceful reload를 수행할 수 있습니다. - Kubernetes에서는 Helm 업그레이드, 노드 드레이닝, 설정 변경 등으로 StatefulSet Pod가 교체되면 프로세스가 강제 종료된 뒤 재시작됩니다. - Gitaly Sharded처럼 자체 고가용성을 제공하지 않는 구성에서는 이 방식이 일시적인 중단을 일으킬 수 있습니다. - 이를 보완하기 위해 Rails 등 Gitaly 클라이언트의 요청 재시도 시간을 설정할 수 있게 했습니다. - Gitaly가 재시작되는 동안 요청을 재시도 - 사용자는 짧은 시간 동안 약간 높은 지연을 경험할 수 있음 - 재시작이 완료되면 요청은 최종적으로 성공 ### 업그레이드 중에도 높은 성공률 유지 - VM 기반 Gitaly와 Kubernetes 기반 Gitaly에서 일반적인 Git 작업을 실행한 뒤, 테스트 중간에 업그레이드를 수행하는 벤치마크를 진행했습니다. - 두 환경의 요청 성공률은 거의 동일했습니다. - Kubernetes에서는 Pod 종료 시 프로세스가 즉시 끝나고 소켓도 닫히지만, 클라이언트 재시도 덕분에 대부분의 요청이 성공했습니다. - 모든 작업에서 100% 성공률을 보장하려면 Gitaly Cluster(Praefect)가 필요합니다. - 그러나 Praefect는 현재 Kubernetes를 지원하지 않으며, Kubernetes 지원의 정식 제공을 준비 중입니다. ### 인프라 통합의 효과 - 기존 하이브리드 배포 사용자는 Gitaly를 VM에서 Kubernetes 클러스터로 이전할 수 있습니다. - 별도의 Gitaly VM fleet를 유지·모니터링할 필요가 없어집니다. - GitLab 전체를 Kubernetes가 관리하는 단일 환경으로 통합할 수 있습니다. - Kubernetes를 이미 운영 중인 신규 GitLab 사용자도 Helm chart를 통해 Kubernetes 네이티브 방식으로 GitLab을 배포할 수 있습니다. ### 설치 방법과 배포 형태 - 권장 설치 방법은 GitLab Helm chart를 사용하는 것입니다. - 설치 전 Gitaly on Kubernetes 공식 문서를 확인해 주요 설정과 일반적인 문제를 검토해야 합니다. - Gitaly는 두 가지 형태로 배포할 수 있습니다. - 전체 GitLab 설치의 일부로 배포 - 외부 Gitaly 구성 요소로 별도 배포 - 구체적인 설정 방법과 주의사항은 Gitaly on Kubernetes 문서에서 각 시나리오별로 제공합니다. ### 실용적인 결론 GitLab을 Kubernetes 중심으로 운영하는 팀이라면 Gitaly를 클러스터로 통합하는 것이 운영 복잡성을 줄이는 현실적인 선택입니다. 다만 무중단 고가용성이 반드시 필요한 환경은 Praefect의 Kubernetes 지원 여부를 확인한 뒤 도입을 결정하는 것이 좋습니다.

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

쿠버네티스gitlabGitgitops+4

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

GitLab Duo Agent Platform으로 배포 프로세스 자동화

GitLab Duo Agent Platform의 커스텀 에이전트를 활용하면 새로운 마이크로서비스를 기존 GitOps 배포 흐름에 자동으로 편입할 수 있다. 에이전트는 애플리케이션의 저장소 구조와 매니페스트, 파이프라인, Dockerfile을 분석해 필요한 설정을 생성하고 수정한다. 에이전트와 생성 결과가 GitLab 안에서 버전 관리·권한 통제되므로 자동화 속도와 엔터프라이즈 거버넌스를 함께 확보할 수 있다는 것이 글의 결론이다. ## TanukiBank의 마이크로서비스 온보딩 사례 - 가상의 은행 애플리케이션인 TanukiBank에 `intra-account-transfers` 마이크로서비스를 추가하는 상황을 예로 든다. - 기존 애플리케이션에는 계좌 간 송금 UI가 있지만 이를 처리할 백엔드 서비스가 없어 Transfer 버튼이 동작하지 않는다. - 새 서비스는 기존 GitOps 배포 규칙에 맞게 다음 요소를 모두 구성해야 한다. - Kubernetes 배포 매니페스트 - 컨테이너 이미지 빌드 및 전달 파이프라인 - 이미지 자동 업데이트 설정 - 네임스페이스, 포트, 호스트명 참조 ## TanukiBank의 GitOps 배포 구조 - GitLab 그룹에는 각 마이크로서비스를 담는 `services` 하위 그룹이 있다. - 배포 과정은 두 프로젝트와 Flux 컴포넌트가 연계되는 구조다. - **Tanuki Bank - Delivery**: 환경별 배포 매니페스트와 전달 파이프라인 관리 - **Flux Config**: Flux 관련 매니페스트 관리 - **Flux Image Automation Controller**: 서비스 레지스트리의 새 이미지를 감지하고 Delivery 프로젝트의 매니페스트 갱신 - **Flux CD Controller**: Delivery 프로젝트의 상태를 Kubernetes 클러스터의 실행 상태와 동기화 - 새 서비스가 추가되면 서비스 저장소, Delivery 프로젝트, Flux 설정을 모두 정확히 수정해야 한다. - 수동 작업에서는 특정 파일이나 참조를 빠뜨릴 경우 배포 실패가 발생할 수 있다. ## GitLab Duo를 이용한 시스템 프롬프트 생성 - GitLab Agentic Chat에 TanukiBank 그룹과 하위 그룹의 구조 및 파일을 분석하도록 요청한다. - Duo는 다음 자료를 조사해 커스텀 에이전트용 시스템 프롬프트를 작성한다. - Kubernetes 매니페스트 - 설정 파일 - Dockerfile - 프로젝트 간 의존성 - 기존 GitOps 규칙 - 생성된 프롬프트에는 다음과 같은 내용이 포함된다. - 에이전트가 따라야 할 작업 규칙 - 결과 보고 방식 - 사용할 도구 - 이 프롬프트는 현재 애플리케이션의 GitOps 구조를 반영한 것이므로, 향후 배포 방식이 바뀌면 다시 생성해야 한다. ## 커스텀 에이전트 생성 및 적용 - `application-agents`라는 별도 프로젝트를 만들어 에이전트를 관리한다. - GitLab의 **AI > Agents > Managed** 메뉴에서 `TanukiBank Microservice Onboarder` 에이전트를 생성한다. - 에이전트 생성 시 다음을 설정한다. - 이름과 설명 - 공개 여부 - Duo가 추천한 도구 - 앞서 생성한 시스템 프롬프트 - 이후 에이전트를 GitOps를 담당하는 다음 프로젝트에서 사용할 수 있도록 활성화한다. - `Tanuki Bank - Delivery` - `Flux Config` - 각 프로젝트의 Agentic Chat 에이전트 목록에 해당 에이전트가 표시되면 설정이 완료된 것이다. ## Developer 플로우로 새 서비스 구현 - `services` 그룹에 `intra-account-transfers` 프로젝트를 만든다. - 프로젝트 이슈에 마이크로서비스 요구사항을 작성하고 **Generate MR with Duo**를 실행한다. - Developer foundational flow가 다음 작업을 자동으로 수행한다. - 이슈의 사양 분석 - 서비스 코드 구현 - 브랜치 생성 - Merge Request 생성 - 이슈와 MR 연결 - 로컬에서 `curl` 명령으로 동작을 확인한 뒤 MR을 병합한다. - 파이프라인이 실행되어 새 서비스의 컨테이너 이미지를 서비스 프로젝트의 내장 레지스트리에 업로드한다. ## 커스텀 에이전트를 통한 GitOps 온보딩 - 서비스 자체는 생성됐지만 GitOps 설정에는 아직 등록되지 않은 상태다. - Delivery 프로젝트의 `manifests/dev`에 서비스 매니페스트가 없음 - 전달 파이프라인에 서비스 참조가 없음 - Flux Config의 `image-update-automation.yaml`에 이미지 자동화 항목이 없음 - 새 서비스 프로젝트에서도 `TanukiBank Microservice Onboarder`를 활성화한다. - Delivery 프로젝트의 Agentic Chat에서 커스텀 에이전트를 선택한다. - 서비스 이름과 호스트명을 전달해 온보딩을 요청한다. - 에이전트는 새 서비스의 Dockerfile을 읽어 포트를 확인하고, 이에 맞는 매니페스트와 파이프라인 설정을 생성·수정한다. - 제공된 글은 이 작업이 진행되는 지점에서 끝나므로, 이후 생성된 변경 사항과 실제 Kubernetes 배포 결과는 본문에 포함되어 있지 않다. 새 마이크로서비스 온보딩 절차가 반복적이고 규칙 기반이라면, 프로젝트 구조와 GitOps 규칙을 반영한 커스텀 에이전트를 만들어 자동화하는 것이 효과적이다. 다만 시스템 프롬프트가 현재 배포 구조에 강하게 의존하므로, GitOps workflow 변경 시 프롬프트와 에이전트 동작을 함께 재검토해야 한다.

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

쿠버네티스CI/CDDocker & 컨테이너마이크로서비스+3

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

SSH에서 REST로: Slack EMR 데이터 파이프라인의 보안 주도 현대화

Slack은 700개가 넘는 EMR 데이터 파이프라인을 직접 SSH로 실행하던 구조에서 REST 기반 작업 제출 방식으로 전환했다. SSH는 보안 공격 표면, 키 관리, 장애 복구, 작업 관측성 측면에서 한계가 있었고 Spark on Kubernetes와 AWS 계정 분리 같은 현대화도 가로막았다. Slack은 YARN REST API와 YARN Distributed Shell을 활용해 8개 데이터 리전의 작업을 중단 없이 마이그레이션하고 SSH를 완전히 제거했다. ## SSH 기반 파이프라인의 확산 - 2017년경 Airflow가 EMR 마스터 노드에 SSH로 접속해 명령을 실행하는 방식으로 데이터 파이프라인을 구축했다. - 단순한 `SSHOperator` 패턴이 확산되면서 다음과 같은 작업까지 SSH로 실행됐다. - Spark 및 MapReduce 작업 - AWS CLI 명령 - 사용자 정의 Python 스크립트 - 2024년에는 700개 이상의 운영 작업이 SSH 기반으로 실행되고 있었다. - 검색 인덱싱, 분석, 비즈니스 인텔리전스 등 핵심 데이터 처리도 이 구조에 의존했다. ## SSH의 보안 및 운영상 문제 - **보안 위험** - 오케스트레이션 워커가 EMR 클러스터에 직접 SSH 접속해야 해 공격 표면이 커졌다. - SSH 키를 여러 워커에 배포하고 주기적으로 교체해야 했다. - 세밀한 감사 추적을 위해 여러 시스템의 로그를 상호 연관해야 했다. - 보안 그룹과 사용자 권한 설정이 복잡해졌다. - **운영 장애** - 작업이 EMR 마스터 노드에서 직접 실행되어 리소스 경쟁이 발생했다. - Kubernetes Pod가 재시작되면 SSH 연결이 끊겨 작업이 실패했다. - 연결이 끊긴 뒤에도 작업이 계속 실행되는 ‘좀비 작업’이 남을 수 있었다. - 연결 단절 후 작업의 성공·실패 상태를 안정적으로 확인하기 어려웠다. - **인프라 현대화 차단** - Spark on Kubernetes와 EMR on EKS 도입을 시작할 수 없었다. - 메인 AWS 계정의 EMR 클러스터를 자식 계정으로 이전하는 Whitecastle 프로젝트가 지연됐다. - 신뢰할 수 있는 작업 모니터링과 관측성을 구현하기 어려웠다. ## REST 기반 작업 제출의 장점 - SSH는 클라이언트와 서버 사이의 상태ful 연결을 유지해야 한다. - REST 방식에서는 작업의 생명주기를 서버가 관리한다. - `POST`: 작업을 제출하고 작업 ID를 받음 - `GET`: 작업 ID로 실행·완료·실패 상태를 조회 - `DELETE`: 필요할 때 작업을 취소 - Airflow나 Kubernetes Pod가 재시작되어도 작업 자체는 서버에서 계속 실행될 수 있다. - 클라이언트가 작업 상태를 다시 조회할 수 있어 연결 단절에 강하다. - 작업 취소, 리소스 관리, 로그 확인 등도 실행 엔진의 표준 기능으로 처리할 수 있다. ## YARN Distributed Shell을 활용한 해결책 - Spark는 Livy REST API, Hive는 HiveServer2를 사용할 수 있어 상대적으로 이전이 쉬웠다. - 반면 MapReduce와 `aws s3 sync`, `hadoop distcp` 같은 300개 이상의 임의 CLI 작업은 바로 사용할 REST API가 없었다. - 검토한 대안은 다음과 같았다. - 원격 명령 실행용 커스텀 래퍼 서비스 - Ansible이나 Salt 같은 원격 실행 프레임워크 - YARN에 새로운 작업 유형을 직접 개발 - 이러한 방법은 별도 보안 계층과 운영 인프라를 구축·유지해야 해 복잡도가 높았다. - YARN의 **Distributed Shell**은 임의의 셸 스크립트를 YARN 컨테이너에서 실행할 수 있도록 했다. - 기존 YARN REST API를 그대로 사용 - YARN의 인증·인가 체계 활용 - 별도 보안 서비스 불필요 - 오픈소스 표준 기반 - 컨테이너 리소스와 작업 생명주기 관리 지원 ## Distributed Shell의 실행 흐름 - 실행할 셸 스크립트를 S3에 업로드한다. - 예: `s3://bucket/command.sh` - 스크립트는 `aws s3 sync` 같은 임의 명령을 포함할 수 있다. - YARN REST 요청에 Distributed Shell의 `ApplicationMaster`와 스크립트 위치를 지정한다. - YARN이 컨테이너를 할당하고 S3에서 스크립트를 내려받아 실행한다. - 실행 과정에서 YARN이 다음을 담당한다. - 메모리와 vCore 등 리소스 제한 - 컨테이너 격리 - 재시도와 장애 복구 - 정상적인 작업 취소 - YARN UI를 통한 로그 및 상태 확인 ## 마이그레이션의 의미 - YARN Distributed Shell을 통해 REST API가 없던 CLI·MapReduce 작업까지 동일한 실행 모델로 통합할 수 있었다. - 작업 제출과 실행을 SSH 연결에서 분리해 클라이언트 재시작과 네트워크 단절에 대한 안정성을 높였다. - 700개 이상의 작업을 8개 데이터 리전에 걸쳐 중단 없이 이전하면서 SSH 의존성을 제거했다. - 결과적으로 보안 강화뿐 아니라 Kubernetes 기반 실행 환경, AWS 계정 분리, 표준화된 모니터링으로 나아갈 기반을 마련했다. 실용적으로는 원격 서버에 직접 접속해 명령을 실행하기보다, 작업 ID·상태 조회·취소를 제공하는 서버 측 실행 모델을 사용하는 것이 바람직하다. 특히 기존 작업이 단순 CLI 스크립트라면 복잡한 신규 실행 서비스를 만들기 전에 YARN Distributed Shell처럼 기존 플랫폼의 표준 기능을 우선 검토할 수 있다.

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

쿠버네티스rest-apiapache-sparkapache-airflow+3

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

메일이 (너무 많이) 도착했습니다: 3/25/26 음성 서비스 장애의 이면

Discord의 2026년 3월 25일 음성·영상 장애는 세션 관리 서버의 설정 변경에서 시작되어 여러 시스템을 거친 연쇄 장애로 확대됐다. Kubernetes 마이그레이션 중 세션 서버의 복제본 수를 줄이자 한 가용 영역에서 세션의 상당 부분이 비정상 종료됐고, 재연결·상태 정리 트래픽이 급증했다. 그 결과 사용자는 통화에 참여하지 못하고 “Awaiting Endpoint” 메시지를 보았으며, 장애는 12:13부터 15:30 PDT까지 이어졌다. ## 장애의 규모와 직접적인 증상 - 장애 발생 시점은 3월 25일 12:13 PDT, 복구 시점은 15:30 PDT였다. - Discord의 음성·영상 통화를 시작하거나 참여하기 어려웠다. - 많은 사용자가 통화 상태에서 **“Awaiting Endpoint”** 메시지를 확인했다. - 세션 관리 서버의 약 17%가 동시에 사라지면서 후속 시스템에 대규모 부하가 전달됐다. - 최종적으로 음성·영상 통화를 적절한 서버로 라우팅하는 서비스가 과부하를 겪었다. ## Kubernetes 마이그레이션과 변경 배경 - Discord는 Elixir 기반 실시간 서비스를 Kubernetes 환경으로 이전하고 있었다. - Elixir 서비스는 각 호스트에서 수천 개의 상태를 가진 프로세스를 실행한다. - 길드 - 사용자 presence - 통화 - 사용자 세션 - 서버를 종료할 때는 프로세스의 상태를 다른 노드로 넘긴 뒤 종료해야 서비스 중단을 피할 수 있다. - 배포 시스템은 서버의 엔터티 수가 0이 될 때까지 기다린 후 pod를 종료하도록 설계돼 있었다. - 주말 CPU 사용률이 높아지자 다음과 같은 리소스 조정을 시도했다. - pod당 CPU와 메모리 증가 - 전체 pod 수를 비례적으로 감소 - 스케줄러 사용량이 pod 수에 따른 고정 비용인지 측정 ## 세션 서버의 비정상 종료 - 변경 사항은 먼저 한 가용 영역에 배포됐다. - 복제본 수를 줄이는 과정에서 Kubernetes가 해당 영역의 pod 중 50%를 종료했다. - 서비스는 Kubernetes의 종료 신호를 받으면 프로세스를 다른 노드로 이전하려고 한다. - 그러나 진행 중인 다른 이벤트가 끝날 때까지 기다리는 안전 검사 때문에, Kubernetes의 종료 유예 시간이 먼저 만료됐다. - 결과적으로 프로세스 핸드오프가 시작되기 전에 pod가 종료됐다. - 세 영역이 균등하게 구성돼 있었기 때문에 Discord 전체 세션의 약 17%가 비정상적으로 중단됐다. ## Elixir GenServer와 모니터링 메시지의 폭증 - Discord의 실시간 시스템은 Elixir의 `GenServer` 프로세스를 기반으로 동작한다. - 각 프로세스는 자신의 mailbox에서 한 번에 하나의 메시지만 처리한다. - 단일 메시지 처리 방식은 동시성 문제를 줄인다. - 반대로 짧은 시간에 메시지가 폭증하면 처리 지연이 발생할 수 있다. - Elixir의 `Process.monitor` 또는 Discord의 확장형 `ZenMonitor`는 감시 대상 프로세스가 종료되면 `{:DOWN, ...}` 메시지를 전달한다. - 세션 17%가 동시에 종료되면서 해당 세션을 감시하던 여러 프로세스에 종료 알림이 일제히 전송됐다. - 이 메시지 폭풍은 실시간 시스템 전반으로 전파됐고, 가장 먼저 Gateway 서비스에 영향을 미쳤다. ## 사용자 재연결로 확대된 부하 - Gateway 서비스는 Discord의 모든 WebSocket 트래픽에 대한 입구이자 출구 역할을 한다. - 클라이언트가 연결되면 Gateway는 세션 서비스를 통해 사용자 세션을 만들고, 길드·채널·DM 등의 데이터를 전달한다. - 세션의 갑작스러운 종료는 클라우드 장애, 네트워크 오류, 클라이언트 환경 등에서도 발생할 수 있으므로 Gateway는 이를 감지하고 재연결을 유도한다. - 세션이 끊기면 Gateway는 사용자를 즉시 재연결시키고, 기존 세션을 낙관적으로 복구하려 한다. - 이번 장애에서는 대규모 세션 종료가 동시에 발생하면서 정상적인 복구 절차 자체가 대규모 재연결 부하로 변했다. - 제공된 글 내용은 이 재연결 과정과 이후 음성 라우팅 시스템의 상세한 연쇄 장애를 설명하기 직전에서 끝난다. ## 실용적인 교훈 - 상태를 가진 서비스를 Kubernetes에서 축소할 때는 replica 감소 자체보다 **상태 이전과 종료 유예 시간의 상호작용**을 검증해야 한다. - 장애 복구용 재연결 로직도 대규모 동시 장애에서는 부하 증폭기가 될 수 있으므로 재연결 속도 제한과 단계적 복구가 필요하다. - 한 서비스의 작은 설정 변경이 모니터링 메시지, WebSocket 재연결, 음성 라우팅 등 여러 계층을 거쳐 전혀 다른 병목을 압박할 수 있다. - 분산 시스템 변경은 단일 서비스의 CPU·메모리 지표뿐 아니라 장애 전파 경로와 최악의 동시 부하까지 함께 검증해야 한다.

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

쿠버네티스분산 시스템websocketselixir+2

gitlab·2026년 4월 28일원문

대규모 환경에서 CI/CD 관측성을 구축하는 방법 (새 탭에서 열림)

GitLab 셀프 매니지드 환경에서 CI/CD 가시성을 확보하는 것은 대규모 데브옵스 플랫폼의 성능 최적화와 안정적인 운영을 위한 필수 과제입니다. 이 글은 Prometheus와 Grafana, 그리고 전용 익스포터를 활용하여 원시 파이프라인 데이터를 실시간 대시보드로 변환하고 의사결정에 필요한 핵심 통찰을 얻는 기술적 방법론을 제시합니다. 이를 통해 기업은 인프라 투자 효율성을 높이고 병목 현상을 체계적으로 해결할 수 있는 데이터 기반의 관리 체계를 구축할 수 있습니다. ### 실시간 통찰을 위한 다층적 대시보드 구성 효과적인 CI/CD 옵저버빌리티를 위해 다음과 같은 네 가지 핵심 대시보드를 구성하여 운영 가시성을 확보합니다. * **파이프라인 개요 대시보드:** 전체 실행 횟수, 시간 흐름에 따른 성공/실패율, 평균 소요 시간 추이를 시각화합니다. 상태별 색상 코딩을 통해 플랫폼 팀이 성능 저하를 즉각적으로 감지할 수 있도록 합니다. * **작업(Job) 성능 대시보드:** 개별 작업의 실행 시간 분포(히스토그램)와 가장 느린 상위 10개 작업을 분석합니다. 프로젝트 및 스테이지별 실패 히트맵을 통해 최적화가 필요한 병목 지점을 특정합니다. * **러너 및 인프라 대시보드:** Node Exporter의 호스트 지표(CPU, 메모리, 디스크)와 파이프라인 대기 시간을 결합하여 분석합니다. 인프라 포화도와 작업 지연의 상관관계를 파악하여 러너 스케일링이나 인스턴스 업그레이드 등의 용량 계획 수립에 활용합니다. * **배포 빈도 대시보드:** 환경별 배포 횟수와 소요 시간을 추적하여 DORA 지표를 관리합니다. 엔지니어링 리더십은 이를 통해 릴리스 속도와 메인 브랜치 대비 커밋 지연 상태(Environment Drift)를 점검할 수 있습니다. ### 옵저버빌리티 구현을 위한 핵심 기술 스택 GitLab의 원시 데이터를 수집하고 시각화하기 위해 두 가지 주요 익스포터와 컨테이너 기반 인프라를 사용합니다. * **GitLab CI Pipelines Exporter:** GitLab API를 통해 파이프라인 소요 시간, 작업 상태, 배포 정보 등 CI/CD 관련 핵심 메트릭을 수집합니다. * **Node Exporter:** 러너가 실행되는 호스트의 하드웨어 및 OS 지표를 수집하여 인프라 수준의 통찰을 제공합니다. * **Grafana 파일 기반 프로비저닝:** 모든 대시보드를 코드로 관리하고 자동으로 배포하여 여러 환경에서 일관된 모니터링 환경을 유지합니다. 프로젝트나 브랜치별 필터링을 위한 변수 설정이 가능합니다. ### 엔터프라이즈급 Kubernetes 배포 아키텍처 대규모 환경에서는 확장성과 보안을 위해 Kubernetes 클러스터에 각 컴포넌트를 분리된 Deployment로 배포하는 것이 권장됩니다. * **네임스페이스 및 보안 관리:** `gitlab-observability`와 같은 전용 네임스페이스를 생성하고, GitLab API 접근을 위한 Personal Access Token(`read_api` 권한)을 Kubernetes Secret으로 안전하게 관리합니다. * **익스포터 배포:** `gitlab-ci-pipelines-exporter`를 Deployment로 구성하고, ConfigMap을 통해 수집 대상 프로젝트 및 설정을 주입합니다. * **데몬셋 활용:** `Node Exporter`는 DaemonSet으로 배포하여 클러스터 내 모든 노드의 메트릭을 빠짐없이 수집합니다. * **Prometheus 통합:** 수집된 모든 메트릭은 Prometheus로 집계되며, 이를 Grafana의 데이터 소스로 연결하여 시각화 체계를 완성합니다. 대규모 CI/CD 환경을 운영하는 조직이라면 단순한 로그 확인을 넘어, 이와 같은 통합 옵저버빌리티 스택을 구축할 것을 권장합니다. 특히 인프라 비용 최적화와 개발 생산성 향상을 목표로 한다면, DORA 메트릭과 인프라 지표를 연계한 분석이 병목 현상 해결의 결정적인 열쇠가 될 것입니다. 중간 규모 이하의 환경이나 PoC 단계에서는 Docker Compose를 통해 빠르게 프로토타입을 구축해본 후 Kubernetes로 확장하는 전략이 효과적입니다.

쿠버네티스옵저버빌리티CI/CDgitlab+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의 추론 권장 기능을 적극적으로 활용해 보시기 바랍니다.

쿠버네티스생성형 AIPostgreSQLAWS+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 같은 자동화 도구를 적극 활용하여 레거시 시스템 현대화 속도를 높이고, 강화된 네트워킹 성능을 바탕으로 더 견고한 분산 시스템을 설계할 것을 권장합니다.

쿠버네티스PostgreSQLamazon-bedrockDevOps+4

line·2026년 4월 15일원문

ODW #2: ADK로 싱글/멀티 에이전트를 개발해 사내 시스템과 통합 (새 탭에서 열림)

LY Corporation은 사내 AI 활용의 개인차를 극복하고 업무 생산성을 높이기 위해 'ADK(Agent Development Kit)'를 활용한 싱글 및 멀티 에이전트 개발 워크숍을 진행했습니다. 이 워크숍은 개인 중심의 AI 도구 활용에서 벗어나, 팀 단위로 최적화된 AI 에이전트를 구축하고 MCP(Model Context Protocol)를 통해 사내 시스템과 통합하는 실무 지식을 공유하는 데 중점을 두었습니다. 결과적으로 복잡한 업무를 자동화하는 멀티 에이전트 시스템을 직접 구현함으로써 지식 사일로 현상을 해소하고 조직 차원의 기술 상향 평준화를 목표로 하고 있습니다. **사내 AI 활용의 한계와 워크숍의 필요성** * **지식의 사일로화:** 개인별로 로컬 AI 도구(Cline, Claude Code 등)를 사용하면서 활용 능력에 따른 생산성 격차가 발생하고, 유사한 문제에 대해 각자 프롬프트를 최적화하는 중복 작업이 빈번해졌습니다. * **싱글 에이전트의 한계:** 단일 LLM 기반 에이전트만으로는 복잡한 비즈니스 로직이나 전문적인 대응에 한계가 있으며, 이를 해결할 수 있는 멀티 에이전트 개념에 대한 이해가 부족한 상황이었습니다. * **정보 접근의 어려움:** Jira, Confluence 등 사내 시스템에 파편화된 정보를 검색하고 요약하는 데 많은 시간이 소요되어, 이를 자동화할 수 있는 중앙 집중형 에이전트 호스팅의 필요성이 대두되었습니다. **에이전트 개발 도구: ADK와 MCP** * **ADK (Agent Development Kit):** 에이전트의 동작을 정의하고 멀티 에이전트 시스템을 구현하기 위한 오픈소스 프레임워크입니다. Python 등을 활용해 함수를 정의하면 에이전트가 이를 도구(Tool)로 인식하여 실행할 수 있게 해줍니다. * **MCP (Model Context Protocol):** LLM을 Jira, Confluence와 같은 외부 시스템과 연결하는 표준 프로토콜입니다. 이를 통해 에이전트가 사내 문서나 업무 이력을 능동적으로 탐색하고 활용할 수 있는 환경을 제공합니다. * **컨텍스트 관리:** 너무 많은 도구를 에이전트 하나에 부여하면 정확도가 떨어지므로, 멀티 에이전트 구조를 통해 역할별로 컨텍스트를 분리하여 성능을 최적화합니다. **멀티 에이전트를 활용한 '프로젝트 추적기' 구현** * **순차적 에이전트(Sequential Agent) 구조:** 복잡한 프로젝트 관리 업무를 해결하기 위해 4개의 특화된 에이전트를 순차적으로 연결하는 파이프라인을 구성했습니다. * **단계별 역할 분담:** * 1단계: 진행 중인 작업 분석(Jira 데이터 수집) * 2단계: 할 일(Todo) 목록 분석 및 우선순위 파악 * 3단계: 수집된 정보를 종합하여 마크다운 형식의 리포트 생성 * 4단계: 생성된 리포트를 지정된 언어로 번역 * **실무 적용 효과:** 사용자가 일일이 데이터를 찾고 정리할 필요 없이, 멀티 에이전트 시스템이 사내 시스템에 접속하여 분석부터 번역까지 완료된 종합 보고서를 즉시 제공합니다. 단순히 AI 도구를 도입하는 것을 넘어, 팀의 고유한 도메인 지식과 사내 시스템을 결합한 '팀 전용 에이전트'를 구축하는 것이 중요합니다. ADK와 같은 프레임워크를 활용해 멀티 에이전트 환경을 구축하고 이를 호스팅하여 공유한다면, 개인의 프롬프트 엔지니어링 역량에 의존하지 않고 조직 전체의 업무 효율을 상향 평준화할 수 있습니다.

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

cloudflare·2026년 4월 12일원문

에이전트 위크에 오신 것을 환영합니다 (새 탭에서 열림)

AI 에이전트의 시대가 도래함에 따라 기존의 컨테이너 기반 클라우드 인프라는 확장성과 비용 측면에서 한계에 직면하고 있습니다. 클라우드플레어는 일대다(1:N) 방식의 전통적인 아키텍처 대신, 개별 에이전트마다 독립적인 실행 환경을 즉시 제공할 수 있는 격리(Isolate) 기반의 서버리스 기술이 미래 인터넷의 핵심이 될 것이라고 주장합니다. 에이전트의 대중화를 위해서는 수 밀리초 안에 실행되고 자원 소모가 적은 가벼운 컴퓨팅 환경으로의 전환이 필수적이라는 결론입니다. **기존 클라우드 모델과 에이전트의 충돌** * 스마트폰 시대를 거치며 발전한 현재의 클라우드는 소수의 마이크로서비스 인스턴스가 다수의 사용자를 처리하는 '일대다(One-to-Many)' 모델을 기본으로 합니다. * 반면 AI 에이전트는 한 명의 사용자가 하나의 특정 작업을 수행하기 위해 고유한 실행 환경을 점유하는 '일대일(One-to-One)' 모델을 요구합니다. * 기존 애플리케이션이 정해진 메뉴를 제공하는 '레스토랑'이라면, 에이전트는 작업마다 다른 도구와 재료를 사용하는 '개인 요리사'와 같아서 기존의 컨테이너 방식으로는 이를 효율적으로 수용하기 어렵습니다. **에이전트 대중화를 가로막는 확장성 산식** * 수억 명의 지식 노동자가 동시에 에이전트를 사용할 경우, 기존 컨테이너 방식으로는 수백만 대의 서버 CPU가 필요하며 이는 현재 가용 가능한 컴퓨팅 용량을 수십 배 초과합니다. * 컨테이너는 실행 시 수백 메가바이트의 메모리를 소모하고 시작 속도가 느려, 에이전트 한 대당 운영 비용이 매우 높게 형성됩니다. * 이러한 경제적 한계 때문에 현재 에이전트 도구들은 높은 비용을 정당화할 수 있는 코딩 도구 등 일부 영역에만 국한되어 있습니다. **V8 Isolate 기술을 통한 인프라 혁신** * Cloudflare Workers의 기반인 V8 Isolate 기술은 컨테이너 대비 시작 속도는 약 100배 빠르고(수 밀리초), 메모리 사용량은 100배가량 효율적입니다. * 'Dynamic Workers' 환경을 통해 요청이 들어올 때마다 실시간으로 에이전트 실행 환경을 할당하고 작업 종료 즉시 폐기함으로써 하드웨어 밀도를 극대화할 수 있습니다. * Isolate는 에이전트가 필요로 하는 최소한의 자원만 할당하므로, 전 세계 수십억 명의 사용자를 위한 에이전트 서비스 운영에 필요한 경제적 타당성을 제공합니다. **전환기의 과제와 하이브리드 전략** * 현재는 에이전트가 사람이 사용하던 웹사이트를 탐색하기 위해 헤드리스 브라우저를 사용하는 '말 없는 마차(Horseless Carriage)' 단계에 머물러 있습니다. * 향후에는 에이전트가 직접 서비스를 호출하는 MCP(Model Context Protocol) 표준과 에이전트 전용 인증 방식이 확산될 것으로 보입니다. * 클라우드플레어는 파일 시스템과 바이너리 실행이 필수적인 코딩 에이전트를 위한 '컨테이너 기반 샌드박스'를 정식 출시함과 동시에, 가벼운 작업을 위한 Isolate 기술을 병행 지원하여 구시대와 신시대의 인프라를 연결할 계획입니다. 에이전트 중심의 서비스를 구축하려는 기업은 컨테이너 중심의 무거운 기존 설계에서 벗어나, 실행 밀도가 높고 비용 효율적인 Isolate 기반의 서버리스 아키텍처를 도입하여 대규모 사용자 환경에 대비할 것을 추천합니다.

쿠버네티스데이터베이스 설계대규모 언어 모델Cloudflare Workers+4

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

자율형 SRE 에이전트를 위한 대규모 실세계 평가 플랫폼 구축 방법

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 Leader로 선정되었다는 소식을 전하는 글입니다. 글에 제공된 내용은 Datadog이 인프라·애플리케이션·로그·보안·디지털 경험·소프트웨어 제공·서비스 관리·AI를 아우르는 통합 플랫폼을 제공한다는 점을 강조합니다. 다만 Gartner의 평가 기준이나 Datadog의 구체적인 강점·약점에 대한 본문은 포함되어 있지 않습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner® Magic Quadrant™ for Observability Platforms 2026에서 Leader로 소개되었습니다. - 이는 Datadog이 관측 가능성 플랫폼 시장에서 비전과 실행력을 모두 갖춘 업체로 평가되었음을 의미합니다. - 제공된 발췌문에는 평가 점수, 경쟁사 비교, 선정 근거 등 구체적인 Gartner 분석 내용은 없습니다. ### 통합 인프라 모니터링 - 호스트, 메트릭, 컨테이너, Kubernetes, 네트워크, 서버리스 환경을 모니터링합니다. - 클라우드 비용, 스토리지, GPU까지 관리 범위를 확장합니다. - Cloudcraft를 통해 클라우드 인프라를 시각적으로 구성하고 파악할 수 있습니다. ### 애플리케이션 성능 관측 - APM으로 애플리케이션 성능과 서비스 간 의존성을 분석합니다. - Universal Service Monitoring, Continuous Profiler, Dynamic Instrumentation을 제공합니다. - Agent Observability를 통해 AI 에이전트의 동작과 성능도 관찰할 수 있습니다. ### 로그·데이터·파이프라인 관리 - 로그 관리와 민감 데이터 탐지, 감사 추적 기능을 제공합니다. - Observability Pipelines로 로그와 관측 데이터를 수집·필터링·라우팅할 수 있습니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 작업 실행 상태를 모니터링합니다. ### 보안과 관측성의 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석, IaC 보안을 지원합니다. - 클라우드 보안 상태, 권한, 취약점, 규정 준수를 관리합니다. - Cloud SIEM, 워크로드 보호, 애플리케이션·API 보호 기능도 포함합니다. - 관측 데이터와 보안 데이터를 한 플랫폼에서 연계해 위협 탐지와 대응을 지원하는 방향입니다. ### 디지털 경험과 소프트웨어 제공 - Browser·Mobile RUM으로 실제 사용자 경험을 측정합니다. - Session Replay, Synthetic Monitoring, 오류 추적, 제품 분석 기능을 제공합니다. - CI Visibility, 테스트 최적화, 지속적 테스트, 코드 커버리지로 배포 과정의 품질을 관리합니다. - 내부 개발자 포털, 기능 플래그, IDE 플러그인 등 개발자 생산성 기능도 제공합니다. ### 서비스 관리와 AI 기능 - 이벤트 관리, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화를 지원합니다. - Watchdog과 Bits AI를 활용해 이상 징후 분석, 조사, 자동화된 대응을 수행할 수 있습니다. - AI 에이전트, AI 통합, MCP 서버, AI 기반 조사·보안 분석 기능을 제공하며 AI 운영 환경까지 관측 범위를 넓히고 있습니다. 제공된 내용만 보면 이 글의 핵심은 Datadog이 단순한 모니터링 도구가 아니라 인프라부터 보안, 개발, 사용자 경험, AI 운영까지 포괄하는 통합 관측성 플랫폼으로 자리매김했다는 점입니다. 실제 도입을 검토한다면 Gartner 평가 원문과 함께 데이터 보존 비용, 지원 환경, 기존 도구와의 연동성, 기능별 과금 구조를 별도로 확인하는 것이 좋습니다.

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

쿠버네티스AI옵저버빌리티애플리케이션 성능 모니터링+4