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

런타임 인스턴스: Amazon Bedrock AgentCore에서 프로덕션 AI 에이전트를 위한 지속적 컴퓨팅 | Amazon Web Services

Amazon Bedrock AgentCore의 **runtime instances**는 장시간 실행, GPU 사용, 다중 에이전트 협업이 필요한 프로덕션 AI 에이전트를 위한 AWS 관리형 EC2 기반 실행 환경이다. 최대 14일 동안 세션 상태를 유지하고, 여러 에이전트가 같은 호스트와 파일 시스템을 공유할 수 있다. 기존에 직접 구성해야 했던 EC2, 네트워크, 세션 관리, 확장, 모니터링을 AgentCore API·IAM·관측성 체계와 함께 관리해 복잡한 에이전트 워크로드를 단순화한다. ## runtime instances가 해결하는 문제 - 프로토타입 에이전트를 프로덕션으로 전환하면 다음 요구사항이 발생한다. - 수 시간에서 수일 동안 지속되는 워크플로 - 여러 단계에 걸친 상태 유지 - 에이전트 간 협업과 컨텍스트 공유 - GPU 또는 운영체제 수준 접근 - 대용량·지속형 컴퓨팅 환경 - 기존에는 EC2 인스턴스, 네트워크, 세션 관리, 확장, 모니터링을 직접 구축해야 했다. - runtime instances는 이러한 인프라를 AWS가 관리하면서 기존 AgentCore API, 인증 제어, 관측성 기능과 통합한다. ## runtime microVM과 runtime instances의 차이 - **runtime microVM** - 빠른 확장에 적합한 경량 실행 환경 - 개별 호출을 최대 8시간까지 실행 - 관리형 세션 저장소를 통해 상태 기반 워크플로 지원 - **runtime instances** - AWS 관리형 EC2 기반의 지속형 실행 환경 - 공유 세션을 최대 14일까지 유지 - GPU, 직접적인 OS 접근, 장시간 실행 지원 - 여러 에이전트를 하나의 런타임에서 실행 가능 - 유휴 기간에는 세션을 중지하고 나중에 재개해 비용 절감 - 두 환경은 독립적으로 사용하거나 함께 구성할 수 있다. - 예를 들어 microVM의 오케스트레이터가 작업을 분배하고, instances의 워커 에이전트가 코드 컴파일·보안 검사·GUI 자동화 같은 무거운 작업을 수행한다. ## 에이전트 배포와 협업 방식 - CrewAI, LangGraph, LlamaIndex, Strands 등 원하는 프레임워크와 모델을 사용할 수 있다. - 애플리케이션은 `@app.entrypoint` 데코레이터를 사용하며, ZIP 파일 또는 컨테이너 이미지로 패키징한다. - 같은 세션에 속한 에이전트들은 서로를 도구처럼 호출하며 자율적으로 작업을 반복할 수 있다. - 세션이 며칠간 중단되어도 상태를 유지한 채 재개할 수 있다. - 세션을 초월해 보존해야 하는 지식은 다음 서비스와 결합할 수 있다. - Amazon EBS: 지속적인 파일 시스템과 작업 데이터 저장 - AgentCore Memory: 세션·환경을 넘어 유지되는 장기 기억 ## 코드 작성 에이전트와 리뷰 에이전트 예시 - 예제에서는 두 개의 Python 에이전트를 만든다. - **Writer**: 자연어 요구사항을 Python 코드로 변환 - **Reviewer**: 생성된 코드의 버그, 보안 문제, 스타일을 검토 - Writer는 세션 ID를 기반으로 공유 디렉터리를 만든 뒤 `code.py`를 저장한다. - Reviewer는 같은 세션 ID로 해당 파일을 읽어 코드 리뷰를 수행한다. - 두 에이전트가 같은 파일 시스템을 공유하므로 다음이 필요 없다. - 코드 파일을 별도로 업로드하거나 다운로드하는 과정 - 에이전트 간 API를 통한 데이터 전송 - 실제 운영 환경에서는 예외 처리, 파일 접근 권한, 동시성 제어, 세션 ID 검증 등을 추가해야 한다. ## 용량 공급자 설정 - 먼저 에이전트가 실행될 EC2 인프라를 정의하는 **capacity provider**를 생성한다. - 주요 설정 항목은 다음과 같다. - 운영체제: Linux 64-bit ARM - 인스턴스 유형: 예시에서는 `c7g.2xlarge` - 컴퓨팅 자원: 8 vCPU, 16 GiB 메모리 - VPC, 서브넷, 보안 그룹 - gp3 EBS 볼륨 - EC2 관리를 위한 서비스 역할과 인프라 역할 - 생성 후 상태가 `Active`가 되면 런타임에서 사용할 수 있다. - 생성 이후에는 설명 외 설정 변경이 제한되므로 인스턴스 유형, 네트워크, 보안 설정을 처음부터 검토해야 한다. ## 런타임 생성과 에이전트 배포 - Runtime에서 Compute type으로 **Instances**를 선택한다. - 앞서 만든 capacity provider를 연결한다. - 에이전트 소스는 S3에서 가져오며, ZIP 파일을 업로드할 수 있다. - 배포 시 다음 정보를 지정한다. - Python 3.13 등 언어 런타임 - `agent.py`와 같은 엔트리포인트 파일 - 에이전트의 `@app.entrypoint` 함수 - AWS Management Console뿐 아니라 AgentCore CLI, AWS CLI, IaC 도구로도 배포할 수 있다. ## 실용적인 선택 기준 - 빠른 확장과 짧은 호출 중심의 오케스트레이션에는 runtime microVM이 적합하다. - 장시간 실행, GPU, 공유 파일 시스템, 다중 에이전트 협업, OS 접근이 필요하면 runtime instances를 고려하는 것이 좋다. - 일반적으로는 microVM을 오케스트레이터로, runtime instances를 전문 워커 실행 환경으로 조합하는 구조가 효과적이다. - 비용을 줄이려면 작업이 없는 시간에 세션을 중지하고, EBS와 AgentCore Memory를 목적에 맞게 분리해 사용하는 것이 권장된다.

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

Pythonmulti-agent-systemsamazon-bedrock-agentcoreaws-ec2+2

cloudflare·2026년 8월 3일·3분 읽기큐레이션 요약

Workers RPC, 이제 Python과 JavaScript 간에도 작동

Cloudflare Workers의 RPC가 이제 JavaScript/TypeScript와 Python 사이에서도 동작해, 서로 다른 언어로 작성된 Worker가 별도 API 스키마나 의존성 없이 메서드·객체·함수를 주고받을 수 있게 되었습니다. 개발자는 다른 언어의 Worker를 로컬 라이브러리처럼 호출할 수 있으며, 예외·비동기 반환값·콜백도 자연스럽게 전달됩니다. 이를 위해 Pyodide FFI와 사용자 정의 타입 변환 계층을 결합해 두 언어의 타입 체계를 연결했습니다. ## 언어 간 RPC 호출 - TypeScript Worker에서 정의한 `add(a, b)` 메서드를 Python Worker에서 `await rpc.add(42, 144)`처럼 호출할 수 있습니다. - 반대로 Python Worker의 메서드를 JavaScript/TypeScript에서 호출하는 것도 가능합니다. - 별도 패키지나 직렬화 스키마 없이 Service binding만 설정하면 됩니다. ```json { "services": [ { "binding": "RPC", "service": "ts-rpc-server", "entrypoint": "RpcService" } ] } ``` - RPC 대상은 Worker의 엔트리포인트 클래스에 정의된 메서드로 노출됩니다. ## 일반 함수처럼 동작하는 RPC - JavaScript/TypeScript에서는 Promise, Python에서는 Future처럼 비동기 결과를 받습니다. - 원격 메서드에서 발생한 예외는 호출한 쪽의 RPC 호출 지점에서 다시 발생합니다. - Structured Cloneable 타입을 인자와 반환값으로 전달할 수 있습니다. - JavaScript의 `Date`는 Python의 `datetime`으로 변환됩니다. - 숫자, 불리언, 객체, 배열 등 기본 타입도 대응되는 언어의 타입으로 변환됩니다. - 함수를 다른 Worker에 전달하거나 반환할 수 있습니다. - 상대 Worker가 해당 함수를 호출하면 원래 Worker로 역방향 RPC가 발생합니다. - 대부분의 Worker 간 RPC는 네트워크를 거치지 않고 동일한 스레드에서 실행되므로, 같은 Worker 내부 함수 호출에 가까운 성능을 제공합니다. - 구현은 `workerd`와 `workers-runtime-sdk`의 오픈 소스 코드로 제공됩니다. ## JavaScript와 Python의 호출 방식 차이 두 언어는 복잡한 인자를 표현하는 방식이 다릅니다. - JavaScript/TypeScript는 보통 객체를 전달합니다. ```ts myFunction({ key: "myKey", value: true, optional: 1 }); ``` - Python은 위치 인자와 키워드 인자를 사용합니다. ```python my_complex_function("myKey", True, optional=1) ``` - 목표는 호출자가 상대 언어의 내부 표현을 의식하지 않도록 만드는 것입니다. - Python에서 JavaScript 메서드의 옵션 객체를 다음 두 방식으로 모두 전달할 수 있습니다. ```python JSRPC.get("myKey", {"type": "text"}) JSRPC.get("myKey", type="text") ``` - Pyodide FFI가 두 호출을 JavaScript가 기대하는 옵션 객체 형태로 변환합니다. ## Pyodide FFI 기반 타입 변환 Pyodide는 WebAssembly로 컴파일된 CPython이며, Python과 JavaScript 사이의 기본 타입 변환 기능을 제공합니다. | Python 타입 | JavaScript 타입 | |---|---| | `int`, `float` | `Number` | | `bool` | `Boolean` | | `dict` | `Object` | | `list` | `Array` | - 직접 변환하기 어려운 사용자 정의 클래스나 함수는 Proxy 객체로 표현됩니다. - Proxy는 다른 언어의 속성 접근과 메서드 호출을 원격으로 전달합니다. - 이 방식으로 Python 함수를 JavaScript에 콜백으로 넘기는 등의 패턴을 구현할 수 있습니다. ## Cloudflare Workers 객체 처리의 과제 - `Request`, `Response`, `Blob`, `File` 같은 Cloudflare Workers의 Web API 객체는 일반 Python 타입과 달리 Pyodide가 자동 변환하지 못합니다. - 기본 동작에서는 이런 객체를 JavaScript Proxy로 전달합니다. - 기능적으로는 사용할 수 있지만, Python 개발자가 JavaScript 구현 세부사항과 Proxy를 계속 의식해야 하는 문제가 있습니다. - 따라서 언어 간 RPC를 완전히 자연스럽게 만들려면 표준 타입뿐 아니라 Workers 전용 객체에 대한 별도 변환 전략도 필요합니다. ## 실용적인 결론 언어별 강점을 활용해 하나의 Workers 애플리케이션을 구성하려는 경우, 이번 기능은 유용한 선택지입니다. Service binding만으로 TypeScript와 Python Worker를 연결할 수 있으므로, 공통 API 서버나 수동 직렬화 계층을 별도로 만들기보다 RPC를 통해 기능을 라이브러리처럼 분리하는 방식을 고려할 수 있습니다.

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

PythonTypeScriptJavaScriptCloudflare Workers+4

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

DS와 MLE가 함께 일하는 법

토스뱅크는 DS와 MLE 사이의 역할 경계를 사람이나 파일이 아닌 명시적인 인터페이스로 정의하면서 ML 모델 배포 협업을 개선했습니다. 노트북 전달 방식에서 `.py` 파일 공유를 거쳐, 전처리·추론·후처리를 구현한 모델 패키지를 `pip install`로 배포하는 구조로 발전했습니다. 여기에 모노레포, 공통 추상화, CI, AI 코딩 스타일 규칙을 결합해 배포 속도와 일관성을 높였습니다. ## 노트북 전달 방식의 한계 - Phase 0에서는 DS가 주피터 노트북에서 학습과 추론 코드를 모두 작성하고, MLE가 이를 바탕으로 서빙 코드를 처음부터 다시 작성했습니다. - 라이브러리, 설정 파일, 소스 코드가 흩어져 있어 실행 환경을 재현하기 어려웠습니다. - 노트북에서 동작하던 전처리나 설정을 MLE가 다르게 해석하는 문제가 발생했습니다. - 모델 수가 늘어날수록 파일 요청과 커뮤니케이션 비용이 크게 증가했습니다. - 역할의 경계가 코드가 아니라 사람 사이에 있었기 때문에 책임과 작업 범위가 불명확했습니다. ## `.py` 파일로 추론 로직 분리 - Phase 1에서는 DS가 노트북에서 핵심 추론 로직을 별도의 `.py` 파일로 분리했습니다. - 노트북은 학습과 실험에 집중하고, 실제 모델 로직은 코드 파일로 관리했습니다. - MLE 리뷰와 CI 검증을 거치도록 하면서 DS의 의도를 더 정확히 보존할 수 있었습니다. - 그러나 모델마다 함수 이름이 `predict()`, `run()`, `inference()` 등으로 달라 인터페이스가 통일되지 않았습니다. - 서빙 환경으로 코드를 옮길 때 환경 차이로 수정이 필요했고, 로깅·메트릭·에러 처리를 공통으로 적용하기도 어려웠습니다. - 노트북에서 전역 설정을 변경한 코드가 여러 모델이 실행되는 서빙 프로세스에 영향을 주는 문제도 있었습니다. ## 인터페이스를 통한 역할 분리 - Phase 2에서는 `commons-ml-model` 패키지에 모델의 표준 구조를 정의했습니다. - 추상화 클래스가 다음 세 가지 인터페이스를 제공합니다. - `pre_process`: 입력 데이터 전처리 - `inference`: 모델 추론 - `post_process`: 결과 후처리 - DS는 위 메서드의 구현체를 작성하고 모델을 하나의 패키지로 배포합니다. - MLE는 해당 패키지를 설치해 서비스에 연결하므로 코드를 직접 복사하거나 재작성하지 않습니다. - 추상화 클래스가 추론 전후에 공통으로 다음 기능을 처리합니다. - 요청 추적을 위한 `trace_id` - 추론 시작·완료 로그 - 실행 시간 측정 - 메트릭 기록 - 결과적으로 DS는 모델 동작에 집중하고, MLE는 서비스 인프라와 운영 기능을 담당하게 됐습니다. - 공통 관측 기능을 추상화 클래스 한 곳에서 수정하면 모든 모델에 일괄 적용할 수 있습니다. ## 모노레포와 `uv` 워크스페이스 - 여러 모델 패키지와 공통 추상화 패키지를 하나의 저장소에서 관리했습니다. - `uv` 워크스페이스를 사용해 DS와 MLE가 같은 코드베이스에서 작업하고 리뷰할 수 있도록 했습니다. - 공통 인터페이스 변경과 모델 패키지 수정이 하나의 PR에서 함께 이뤄졌습니다. - CI, 버전 관리, 배포 정책을 저장소 단위로 통일할 수 있었습니다. - 공통 패키지 변경이 모든 모델에 영향을 줄 수 있다는 위험도 존재합니다. - 모델과 패키지가 늘면서 빌드가 느려졌고, Poetry에서 `uv`로 전환해 빌드 속도를 약 3~5배 개선했습니다. ## AI 시대의 코드 스타일 통일 - AI가 코드를 작성하면서 같은 기능도 예외 처리, 네이밍, enum 사용 방식 등이 사람마다 달라지는 문제가 생겼습니다. - 인터페이스가 같더라도 코드의 세부적인 작성 방식이 달라 리뷰 비용이 증가했습니다. - 팀 규칙 모음인 `pfmls-stylepack`을 도입해 AI가 코드 작성 단계부터 팀 컨벤션을 따르도록 했습니다. - Hook을 활용해 네이밍, 예외 처리, 고정값과 enum 사용 기준 등을 자동 적용했습니다. - 규칙이 적용된 코드에는 그 이유를 표시해 리뷰어가 변경 의도를 쉽게 파악하도록 했습니다. - 협업 표준을 두 층위로 나눴습니다. - 구조 표준화: 인터페이스로 담당 범위와 코드 형태 통일 - 스타일 표준화: 컨벤션으로 구현 방식과 코드 결 통일 ## 도입 과정에서 얻은 교훈 - 인터페이스는 너무 엄격하면 DS의 모델별 커스터마이징을 막고, 너무 느슨하면 다시 구현 방식이 제각각이 될 수 있습니다. - 초기에는 가이드 문서를 제공하고 DS와 MLE가 첫 모델을 페어로 함께 만드는 방식이 효과적입니다. - 공통 라이브러리는 한 번의 수정으로 전체 모델에 개선을 적용할 수 있지만, 반대로 전체 모델에 장애를 전파할 수도 있습니다. - 기존 모델 패키지를 참고 코드로 제공하면 새로운 구성원의 러닝 커브를 줄일 수 있습니다. - AI 활용이 늘어날수록 기능의 책임뿐 아니라 코드 작성 방식까지 명시적으로 관리해야 합니다. 실무적으로는 모델 배포 과정에서 “누가 무엇을 한다”를 문서로만 정의하기보다, 추상화 클래스와 패키지 구조로 강제하는 것이 효과적입니다. 먼저 전처리·추론·후처리 같은 최소 인터페이스를 정하고, 공통 로깅·메트릭·CI를 그 바깥에 배치하는 방식부터 시작하는 것을 추천합니다.

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

Python머신러닝CI/CDAPI 설계+4

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

버전 업으로 빌드가 깨졌을 때 GitLab이 해결해 줍니다

GitLab의 Dependency Scanning Auto-Remediation은 취약한 의존성을 자동으로 업그레이드하고, 버전 변경으로 빌드가 깨지면 AI가 코드까지 수정하는 기능이다. 수정 사항은 동일한 머지 리퀘스트에서 검토되며, 기존 승인 절차와 감사 기록을 그대로 따른다. 이를 통해 개발자가 보안 취약점 수정에 직접 많은 시간을 쓰지 않고도 컴플라이언스 기한 내에 대응할 수 있다는 것이 글의 결론이다. ## 의존성 보안 백로그가 증가하는 이유 - 취약하거나 오래된 외부 컴포넌트는 OWASP Top 10에 포함되는 대표적인 위험 요소다. - Maven 생태계 조사에 따르면 최신 릴리스에 유입되는 취약점의 약 63%가 직접 의존성이 아닌 전이적 의존성에서 발생했다. - 취약점 수정은 기능 개발과 경쟁하는 수작업이어서, 특히 PCI-DSS와 FedRAMP의 30일 기한을 넘기는 고위험 취약점이 생기기 쉽다. - 의존성 업데이트 8건 중 약 1건은 호환성이 깨지는 변경을 포함하며, “하위 호환”으로 표시된 업데이트도 실제 프로젝트의 빌드를 깨뜨릴 수 있다. - AI를 활용한 익스플로잇 개발과 무기화가 빨라지면서 취약점을 장기간 방치할 위험도 커지고 있다. ## 취약점 발견부터 수정까지 자동화 - SBOM 기반 의존성 스캐닝이 수정 가능한 취약점을 발견하면, GitLab이 가장 가까운 안전 버전으로 올리는 머지 리퀘스트를 자동 생성한다. - 적절한 수정 버전이 없으면 무리하게 변경하지 않고 취약점을 보고서에 유지한다. - 자동 생성된 머지 리퀘스트는 전용 서비스 계정으로 작성되어 변경 주체를 추적할 수 있다. - 취약점의 심각도, 허용할 업데이트 범위(패치·마이너·메이저)를 설정할 수 있다. - 특정 취약점에 대해서는 취약점 보고서에서 사용자가 직접 자동 수정을 실행할 수도 있다. ## AI 기반 breaking change 해결 - 버전 업그레이드 후 파이프라인이 실패하면 GitLab Duo Agent Platform이 자동으로 원인을 분석한다. - 분석 대상에는 다음이 포함된다. - 파이프라인 오류 메시지 - 의존성의 변경 로그 - 프로젝트 코드에서 해당 의존성을 사용하는 방식 - AI는 같은 머지 리퀘스트 안에서 필요한 애플리케이션 코드 수정 커밋을 추가한다. - 수정 후에도 파이프라인이 통과하지 않으면 자동으로 중단하고, 분석 결과를 머지 리퀘스트에 남겨 개발자가 이어서 처리할 수 있게 한다. - 지원 생태계는 Bundler, Maven, Gradle, 주요 Python 및 JavaScript/TypeScript 패키지 관리자이며, Rust와 Go 지원도 예정되어 있다. ## 검토와 감사 절차를 유지하는 자동화 - 자동 수정은 절대로 자체적으로 병합되지 않는다. - 모든 변경은 기존 리뷰어 승인과 브랜치 보호 규칙을 거친다. - 머지 리퀘스트에는 다음 정보가 명시된다. - 어떤 취약점을 해결하는지 - 어떤 버전으로 업데이트하는지 - 빌드를 통과시키기 위해 AI가 제안한 코드 변경 - 변경 내용, 승인자, 승인 과정이 감사 기록으로 남아 보안 및 규제 대응에 활용할 수 있다. - 자동화는 조직 자체의 파이프라인에서 실행되므로 기존 접근 제어와 승인 게이트를 상속한다. ## 자동화 폭주를 막는 안전장치 - 쿨다운 기간을 설정해 모든 파이프라인마다 새로운 수정 작업이 생성되는 것을 방지한다. - 닫힌 머지 리퀘스트는 더 최신 수정 버전이 등장하지 않는 한 다시 만들지 않는다. - 프로젝트 또는 그룹 단위 구성 프로필로 조직의 위험 허용 수준에 맞게 정책을 관리할 수 있다. - 기능은 현재 퍼블릭 베타이며 GitLab.com에서 제공되고, GitLab Self-Managed와 Dedicated에도 순차적으로 적용된다. - 자동 버전 업데이트는 GitLab Ultimate에 추가 비용 없이 포함된다. AI 기반 breaking change 해결은 GitLab Duo Agent Platform의 무료 체험 또는 Ultimate에 포함된 GitLab Credits로 이용할 수 있다. ## 실용적인 적용 권장 사항 - 먼저 패치·마이너 업데이트만 허용해 자동화 범위를 제한하고, 안정화 후 메이저 업데이트로 확대하는 것이 안전하다. - AI가 작성한 코드도 반드시 일반 코드 리뷰와 테스트를 거쳐야 한다. - PCI-DSS나 FedRAMP처럼 기한이 명확한 환경에서는 고위험 취약점과 전이적 의존성을 우선 대상으로 삼는 것이 효과적이다.

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

PythonAICI/CDgitlab+4

meta·2026년 6월 30일·3분 읽기큐레이션 요약

메타의 10년간 파이썬 지원 commitment

Meta는 Python Software Foundation(PSF) 후원을 10년째 이어가며, Python과 오픈소스 생태계의 지속 가능성이 자사 기술 스택의 장기적 안정성과 직결된다고 강조합니다. Python은 Meta의 가장 widely used 언어로, 제품 백엔드·AI 연구·인프라·개발 도구 전반에 활용됩니다. Meta는 PSF 후원을 통해 Python 핵심 개발, PyPI 보안, 교육 및 커뮤니티 행사를 지원하고 다른 기업과 개인의 참여도 촉구합니다. ## Meta에서 Python이 중요한 이유 - Python은 Meta에서 가장 많이 사용되는 프로그래밍 언어입니다. - Instagram과 Threads를 비롯한 제품의 백엔드, 인프라, AI 연구 등 다양한 영역에서 활용됩니다. - Meta 엔지니어들이 Python 핵심 유지보수와 Python Enhancement Proposal(PEP) 작성에 참여하고 있습니다. - Meta에서 시작된 머신러닝 프레임워크 PyTorch는 오픈소스 커뮤니티와 함께 개발된 뒤 독립 재단으로 분리되었습니다. - 빠른 타입 체커이자 언어 서버인 **Pyrefly** 등 Python 개발 생산성과 성능 향상을 위한 오픈소스 도구도 개발하고 있습니다. - AI 투자, 데이터 기반 제품 확장, 대규모 인프라 운영에서 Python의 역할이 계속 커질 것으로 보고 있습니다. ## PSF 후원이 필요한 이유 - 오픈소스를 사용하는 기업은 언어와 생태계의 보안성·건강성·혁신을 유지할 공동 책임이 있습니다. - Python으로 제품을 출시하고 모델을 학습시키는 과정은 개발자 커뮤니티와 PSF의 조직적 지원에 기반합니다. - Meta는 PSF 후원을 자사 기술 스택의 장기적인 안정성을 위한 전략적 투자로 봅니다. - 특정 기업의 필요를 넘어, 전 세계 개발자가 사용하는 공통 기반을 유지하는 데 기여한다는 의미가 있습니다. ## 개발자 상주 프로그램과 핵심 기술 지원 - PSF 후원금은 Python과 생태계 개선에 전념하는 정규 개발자를 고용하는 **Developer-in-Residence** 프로그램에 사용됩니다. - 이 프로그램은 자원봉사자에게만 의존하기 어려운 핵심 작업을 지속적으로 수행할 수 있게 합니다. - Python 패키지 저장소인 **PyPI**의 보안 강화에도 자금이 투입됩니다. - PyPI 보안 개선은 개발자가 패키지를 안전하게 게시하고 설치하도록 지원하며, Meta 내부 개발자에게도 직접적인 이점이 있습니다. ## 교육과 커뮤니티 생태계 지원 - Meta는 PyCon US와 같은 주요 Python 행사를 지원합니다. - 무료 또는 할인 입장권, 워크숍 및 서밋, 커뮤니티 모금 활동 등을 후원합니다. - PyLadies와 같은 그룹에 대한 지원은 다양한 배경의 인재가 Python 커뮤니티에 참여하도록 돕습니다. - 기술 인프라뿐 아니라 교육과 커뮤니티 성장이 Python의 장기적인 지속 가능성에 필수적이라고 설명합니다. ## PSF에 참여하는 방법 - **일회성 기부:** 원하는 금액을 한 번 기부할 수 있습니다. - **PSF 회원 가입:** 후원 수준에 따라 PSF의 방향에 관한 논의와 투표에 참여할 수 있으며, 금전 대신 시간으로 기여하는 방식도 있습니다. - **조직 후원:** 기업은 연간 후원 등급을 선택해 지속적으로 지원할 수 있습니다. - 조직 후원자는 PSF 웹사이트, 연례 보고서, 주요 행사에서 기업명과 로고를 공개할 수 있습니다. - 높은 등급의 후원자는 더 큰 브랜드 노출, 커뮤니티 행사 참여, 발표 및 특별 프로그램 참여 기회를 얻을 수 있습니다. 기업은 자사 제품과 인프라가 의존하는 오픈소스 프로젝트를 단순히 소비하는 데 그치지 말고, 재정 지원·개발 참여·커뮤니티 후원으로 생태계에 환원하는 것이 좋습니다. 개인 개발자 역시 기부, 회원 가입, 행사 참여와 같은 작은 방식으로 Python의 지속 가능성에 기여할 수 있습니다.

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

PythonAI머신러닝오픈 소스+3

discord·2026년 6월 30일·3분 읽기큐레이션 요약

Discord API의 비용 귀속

Discord의 API는 1,700개 이상의 엔드포인트와 약 700개의 백그라운드 작업을 포함한 단일 Python 코드베이스로 운영되며, 수백 개의 Kubernetes 배포에 단계적으로 배포된다. 기존 모니터링은 지연 시간·처리량·오류율은 보여주지만, 메시지 전송이나 스트리밍 같은 제품 기능별 호스팅 비용은 충분히 설명하지 못했다. Discord는 배포 구조를 변경하지 않고 애플리케이션 프로파일링 도구를 확장해, 각 기능의 코드 실행 시간에 따라 배포 비용을 배분하는 방식을 도입했다. ### 대규모 단일 API 코드베이스의 운영 - Discord API는 하나의 Python 코드베이스로 구성되어 있다. - 1,700개 이상의 API 엔드포인트와 약 700개의 백그라운드 작업을 포함한다. - 엔지니어들은 매일 공통 코드에 변경을 가한다. - 변경 사항은 수백 개의 Kubernetes 배포 환경에 단계적 롤아웃 방식으로 지속 배포된다. - 규모가 크고 변경 빈도가 높기 때문에, 매일 발생하는 변화가 사용자나 시스템에 미치는 영향을 추적하기 어렵다. ### 기존 관측성의 범위 - Discord는 다음과 같은 운영 지표를 이미 수집하고 있었다. - 지연 시간 - 처리량 - 오류율 - 이러한 지표는 성능 저하나 오류 증가 같은 회귀(regression)를 감지하는 데 유용하다. - 그러나 특정 제품 기능이 전체 호스팅 비용에서 차지하는 비중은 파악하기 어려웠다. - 예를 들어 다음과 같은 질문에 답하기 어려웠다. - 메시지 송수신 API 운영 비용은 얼마인가? - 스트림 시작 기능에는 얼마가 드는가? - Nitro 선물 전송 비용은 얼마인가? - 특정 코드 변경이 팀의 호스팅 비용을 얼마나 변화시켰는가? ### Kubernetes 배포 단위만으로는 부족한 비용 추적 - 클라우드 제공업체는 일반적으로 Kubernetes 배포별 비용 분류를 제공한다. - 하지만 Discord의 모든 배포에는 동일한 API 코드베이스가 배포된다. - 각 배포는 특정 HTTP 트래픽이나 백그라운드 작업의 일부를 처리하지만, 제품 기능 단위로 깔끔하게 분리되어 있지는 않다. - 비용 추적을 위해 배포를 기능별로 더 세분화하면 운영 복잡성이 지나치게 커진다. - 따라서 기존 배포 토폴로지를 변경하지 않고 비용을 추적할 방법이 필요했다. ### 동시 실행 환경에서의 비용 배분 - 하나의 API 워커 프로세스는 여러 작업을 동시에 처리한다. - 같은 시점에 여러 제품 기능과 관련된 코드를 실행할 수 있다. - 일부 트래픽은 특정 배포로 격리되어 있지만, 기능별 비용 분석에 충분할 정도로 분리된 것은 아니다. - 따라서 단순히 배포 단위의 비용을 특정 기능에 모두 할당할 수 없다. - 정확한 비용 배분을 위해서는 각 배포가 특정 기능의 코드 실행에 얼마나 많은 시간을 사용했는지 측정해야 한다. ### 프로파일링을 활용한 해결책 - Discord는 기존 애플리케이션 프로파일링 도구를 확장했다. - 각 기능과 관련된 코드가 실행된 시간을 측정하고, 이를 기반으로 배포 비용을 배분한다. - 이를 통해 배포 구조를 바꾸지 않고도 다음 단위의 비용을 추정할 수 있다. - 개별 API 엔드포인트 - 여러 엔드포인트로 구성된 제품 기능 - 글에 제시되는 수치와 코드는 실제 운영값이 아닌 설명을 위한 예시다. ### 실용적인 결론 기능별 인프라 비용을 파악하려면 서비스를 물리적으로 기능별 배포로 나누기보다, 공통 실행 환경에서 각 기능이 소비한 컴퓨팅 시간과 리소스를 측정해 비용을 배분하는 방식이 효과적이다. 특히 대규모 단일 코드베이스에서는 기존 관측성에 비용 귀속 정보를 결합하는 것이 운영 구조를 복잡하게 만들지 않는 현실적인 접근이다.

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

Python쿠버네티스옵저버빌리티API 설계+2

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

전체 수명 주기 제어로 격리된 샌드박스 실행하기: AWS Lambda, MicroVM 도입 | Amazon Web Services

AWS Lambda MicroVMs는 사용자나 AI가 생성한 신뢰할 수 없는 코드를 사용자별로 격리된 실행 환경에서 실행하도록 설계된 서버리스 컴퓨팅 기능이다. Firecracker 기반의 VM 수준 격리, 스냅샷을 활용한 빠른 시작·재개, 메모리와 디스크 상태를 유지하는 실행 세션을 제공하면서도 인프라를 직접 운영할 필요가 없다. 특히 AI 코딩 도구, 온라인 개발 환경, 데이터 분석, 취약점 스캐너처럼 사용자별 장기 실행 환경이 필요한 서비스의 기존 격리·성능 trade-off를 줄이는 것이 핵심이다. ## 사용자별 격리 실행 환경이 필요한 이유 - AI 코딩 어시스턴트, 대화형 코드 실행 환경, 데이터 분석 플랫폼, 취약점 스캐너, 사용자 스크립트를 실행하는 게임 서버 등이 주요 대상이다. - 기존 방식에는 각각 한계가 있다. - **가상 머신**: 강력한 격리를 제공하지만 시작에 수분이 걸릴 수 있다. - **컨테이너**: 빠르게 시작되지만 공유 커널 때문에 신뢰할 수 없는 코드를 안전하게 격리하려면 추가적인 보안 강화가 필요하다. - **서버리스 함수**: 이벤트 기반 요청-응답 처리에 적합하지만, 사용자 상호작용 사이에 상태를 유지하는 장기 세션에는 적합하지 않다. - 직접 가상화 인프라를 구축하면 낮은 지연 시간과 강한 격리를 모두 확보할 수 있지만, 상당한 운영·보안 전문성이 필요하다. ## Firecracker 기반 VM 수준 격리 - 각 사용자 또는 세션은 독립된 MicroVM을 할당받는다. - MicroVM 간 커널과 리소스를 공유하지 않으므로 한 사용자가 실행한 신뢰할 수 없는 코드가 다른 사용자 환경이나 호스트 시스템에 접근하는 것을 막는다. - AWS Lambda에서 대규모로 사용되어 온 Firecracker 기술을 기반으로 하므로, 자체 가상화 시스템을 구축하는 대신 AWS의 운영 성숙도를 활용할 수 있다. ## MicroVM Image 생성 과정 - 애플리케이션 코드와 Dockerfile을 ZIP 파일로 패키징해 Amazon S3에 업로드한다. - `public.ecr.aws/lambda/microvms:al2023-minimal` 기반 이미지에서 Python, pip 등을 설치하고 애플리케이션을 구성할 수 있다. - 예시 애플리케이션은 Gunicorn으로 실행되는 Flask API이며, `0.0.0.0:5000` 포트에서 요청을 처리한다. - 다음과 같은 CLI 명령으로 이미지를 생성한다. ```bash aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> \ --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> ``` - Lambda는 ZIP 파일을 가져와 Dockerfile을 빌드하고 애플리케이션을 초기화한다. - 초기화가 끝난 실행 중인 디스크와 메모리 상태를 Firecracker 스냅샷으로 저장한다. - 빌드 로그는 다음 CloudWatch Logs 경로에서 확인할 수 있다. ```text /aws/lambda/microvms/<image-name> ``` ## 스냅샷 기반 빠른 시작과 재개 - MicroVM은 일반적인 콜드 부팅 대신 사전에 초기화된 스냅샷에서 시작한다. - 애플리케이션 프로세스, 설치된 패키지, 메모리 상태 등이 준비된 상태이므로 실행 직후부터 요청을 처리할 수 있다. - 이후 생성되는 MicroVM도 동일한 이미지 스냅샷에서 복원되므로 초기화 시간을 줄일 수 있다. - 대규모 대화형 세션도 사용자 입장에서 즉시 반응하는 수준의 시작·재개 성능을 목표로 한다. ## 상태를 유지하는 세션과 유휴 정책 - 실행 중인 MicroVM은 다음 상태를 세션 동안 유지한다. - 메모리 상태 - 디스크 상태 - 실행 중인 프로세스 - 일정 시간 요청이 없으면 MicroVM을 일시 중지할 수 있다. - 중지 시 메모리와 디스크 상태를 보존하고, 요청이 다시 들어오면 해당 상태에서 자동으로 재개한다. - 예시 설정은 15분 유휴 후 중지하고, 5분 동안 중지 상태를 유지한 뒤 요청이 오면 자동 재개하도록 구성한다. ```bash aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' ``` ## 엔드포인트와 요청 인증 - MicroVM을 실행하면 Lambda가 고유 ID와 전용 엔드포인트 URL을 제공한다. - 별도의 네트워킹 구성을 하지 않아도 애플리케이션에 접근할 수 있다. - CLI로 단기 인증 토큰을 생성한 뒤 HTTPS 요청의 `X-aws-proxy-auth` 헤더에 포함해 요청을 보낸다. - MicroVM이 중지된 뒤 다시 요청해도 애플리케이션 상태가 유지된 채 복원되므로 클라이언트는 중지·재개 과정을 직접 처리할 필요가 없다. ## 실용적인 활용과 추천 Lambda MicroVMs는 단순한 단발성 함수보다 사용자별로 지속되는 안전한 실행 환경이 필요한 서비스에 적합하다. 사용자 코드 실행, AI 에이전트의 도구 호출, 온라인 IDE, 샌드박스형 분석 환경을 구축한다면 컨테이너 직접 격리나 VM 운영을 대체할 수 있는 후보로 검토할 만하다. 다만 실제 도입 전에는 IAM 실행 역할, 인증 토큰 관리, 유휴·재개 정책, 상태 보존 범위와 비용을 서비스의 세션 패턴에 맞게 검증하는 것이 좋다.

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

PythonDocker & 컨테이너amazon-s3flask+3

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

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 AI 시대의 업무 혁신과 역할 전환

PJ One Piece는 생성형 AI 에이전트로 비즈니스 질문, 데이터 분석, 결과 해석, 다음 액션까지 연결해 분석 업무의 단절을 없애려는 프로젝트입니다. 기존에 평균 2주 걸리던 분석을 약 10분 만에 수행할 수 있게 되었고, 사업부 구성원의 절반 이상이 사용하는 플랫폼으로 확산되었습니다. 핵심은 단순한 SQL 자동화가 아니라 도메인 지식, 분석 프로세스, 도구, 로그와 피드백을 결합해 조직의 분석 역량을 지속적으로 축적하는 데 있습니다. ## 프로젝트 출범 배경: 세 가지 단절 - **비즈니스와 데이터의 단절** - DWH와 BI가 있어도 SQL 작성, 테이블·컬럼 선택, KPI 정의, 결과 해석에는 높은 장벽이 남아 있었습니다. - 데이터에 접근할 수 있는 것과 사업 담당자가 필요한 정보를 스스로 얻는 것 사이에 ‘마지막 1마일’이 존재했습니다. - **분석 프로세스 내 단절** - 과제 정의, 분석 설계, 실행, 리뷰, 액션이 담당자와 도구의 차이로 분리되었습니다. - 사업 배경과 의사 결정 목적이 제대로 전달되지 않아 재작업이 발생했고, 단계 사이의 대기 시간으로 리드타임이 길어졌습니다. - 분석 품질이 균일하지 않고 결과가 실제 액션으로 이어지는 속도도 떨어졌습니다. - **도메인 간 단절** - 사업마다 KPI, 테이블 구조, 사용자 행동, 시책 맥락이 달라 분석 지식과 패턴이 특정 도메인에 머물렀습니다. - 시책 평가, 퍼널 분석, 원인 분석처럼 구조가 유사한 분석도 조직 전체에서 재사용하기 어려웠습니다. ## 분석 에이전트로 분석 흐름 연결 - 사용자는 채팅 형태의 화면에서 자연어로 질문을 입력합니다. - 에이전트는 질문의 목적을 해석하고 분석 계획을 세운 뒤 다음 작업을 수행합니다. - 필요한 데이터와 문서 탐색 - SQL·Python 기반 집계 및 분석 - 시각화와 보고서 작성 - 결과 해석과 추가 분석 제안 - 다음 의사 결정과 액션 검토 - 자연어 질문만으로 분석을 시작할 수 있어 사업 담당자가 데이터 사이언티스트에게 요청하고 기다리는 구조를 줄입니다. - 질문 정리, 지표 선택, 비교 축, 리뷰 관점, 추가 분석 판단을 로그로 남겨 분석 지식과 패턴을 재사용 가능한 자산으로 만듭니다. ## 분석 플랫폼을 구성하는 다섯 가지 요소 - 사용자와 상호작용하는 애플리케이션 - 추론과 도구 사용을 담당하는 LLM 기반 에이전트 - SQL·Python 실행, 사내 문서 조사, 시각화 도구 - 도메인 지식, 스킬, 테이블 정보를 제공하는 지식 베이스 - 실행 로그, 사용자 피드백, 모니터링과 평가를 담당하는 측정 시스템 - 지식 영역은 도메인별 플러그인으로 확장할 수 있으며, 사용량이 늘수록 지식과 분석 패턴이 축적됩니다. ## 자연어 질문을 분석 요구 사항으로 변환 - 사용자가 상세한 분석 설계를 직접 작성하도록 요구하지 않고, 에이전트가 부족한 전제 조건만 확인합니다. - 예를 들어 캠페인 효과 분석에는 대상 정책, 기간, KPI, 비교 대상, 분석 단위, 제외 조건 등이 필요합니다. - 서비스 이해, KPI 정의, 집계 주의사항, 정책 탐색 방법, 리뷰 관점은 도메인 지식으로 관리합니다. - 테이블과 컬럼의 의미, 사용 조건, 적절한 활용 상황도 별도로 정비합니다. - 에이전트는 이미 확정 가능한 항목과 사용자 확인이 필요한 모호한 항목을 구분해 불필요한 질문을 줄입니다. ## 필요한 데이터에 안전하게 접근하는 구조 - 대규모 테이블 정보를 한꺼번에 LLM에 제공하지 않고 단계적으로 공개합니다. - 먼저 테이블 목록으로 후보를 좁힘 - 선택한 테이블의 상세 정의 확인 - SQL 작성 전에 컬럼 설명, 샘플, 파티션 조건, 사용상 주의사항 확인 - 원천 테이블을 그대로 사용하지 않고, 분석에 적합한 속성을 결합한 와이드 테이블을 논리적 뷰나 실제 테이블로 제공합니다. - 복잡한 JOIN을 줄여 SQL 생성 난이도와 오류 가능성을 낮춥니다. - SQL 실행 전후에 시스템 차원의 가드레일을 적용합니다. - `SELECT` 중심의 읽기 전용 제한 - 공개된 테이블 정의 및 사용 규칙 검증 - 파티션 조건 확인 - 개인정보·민감 정보 접근 제한 - 결과 행 수 제어 ## 멀티 에이전트로 분석 맥락 유지 - 슈퍼바이저형 멀티 에이전트 구조를 사용합니다. - 메인 에이전트는 사용자 요청, 분석 목적, 확인된 내용, 다음 판단 과제를 계속 관리합니다. - 통계 검정, 시계열 분석, 클러스터링, 리뷰 등 전문 작업은 역할이 제한된 서브 에이전트에 위임합니다. - 전체 분석 설계와 전문 작업을 분리해 긴 시행착오나 전문 분석이 전체 맥락을 압박하지 않도록 합니다. - 장시간 분석 중에는 발견 사항, 분석 설계, 사용 가능·불가능한 데이터, 제약 조건을 공유해 사용자가 중간에 방향을 수정할 수 있게 합니다. ## 로그와 스킬을 통한 조직 자산화 - 실행 로그로 다음 내용을 추적합니다. - 입력과 출력 - 에이전트의 도구 사용 과정 - 전제 조건 확인 방식 - 분석 설계와 생성된 SQL - 오류가 발생한 지점 - 사용자와 분석 담당자의 피드백을 결합해 프롬프트, 도구, 데이터, 스킬 중 개선이 필요한 영역을 백로그로 관리합니다. - 반복되는 분석은 스킬로 일반화합니다. - 범용 스킬: 시계열 분석, 클러스터링 등 - 도메인 특화 스킬: 월간 보고서, 정책 모니터링 등 - 스킬에는 전제 조건, 비교 축, 주의사항, 결과 해석 방법까지 포함해 다른 담당자와 도메인에서도 재사용할 수 있도록 합니다. ## 선행 도입으로 확인한 사업 가치 - 일부 서비스 사업부에 도입한 결과 구성원의 절반 이상이 사용하는 분석 플랫폼으로 성장했습니다. - 데이터 사이언티스트뿐 아니라 프로덕트 오너와 현장 구성원도 일상 업무에서 먼저 질문하는 진입점으로 활용하고 있습니다. - 기존 요청부터 결과 회신까지 평균 약 2주 걸리던 분석을 약 10분 만에 실행할 수 있게 되었습니다. - 월 수백 건의 분석이 실행되며 데이터 활용 인원이 빠르게 증가했습니다. 분석 AI를 도입할 때는 SQL 생성 자동화에만 집중하기보다, 도메인 지식 관리·데이터 접근 통제·분석 맥락 유지·로그 기반 개선까지 함께 설계하는 것이 중요합니다. 특히 반복 분석을 스킬과 조직 자산으로 축적해야 단기적인 생산성 향상을 넘어 지속적으로 성장하는 분석 플랫폼을 만들 수 있습니다.

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

Python대규모 언어 모델AI 에이전트생성형 AI+4

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

AWS에서 제공되는 Anthropic Claude Fable 5: 기본 제공 안전장치를 갖춘 Mythos급 기능 이제 이용 가능 | Amazon Web Services

Claude Fable 5는 Amazon Bedrock과 Claude Platform on AWS에서 제공되는 Mythos급 성능의 모델로, 장시간 실행되는 코딩·지식 작업과 문서·이미지 이해에 강점을 보인다. 동시에 사이버보안·생물학·화학·보건 등 오용 위험이 높은 요청은 Opus 4.8로 전환하는 안전장치를 적용했다. AWS 사용자는 기존 Bedrock 환경에서 Messages, Invoke, Converse API를 통해 모델을 사용할 수 있지만, 이용 전 데이터 공유와 30일 보관에 동의해야 한다. ## Mythos급 성능과 장시간 작업 - 소프트웨어 엔지니어링, 지식 노동, 비전 관련 벤치마크에서 높은 성능을 제공한다. - 이전 모델보다 복잡하고 긴 작업을 중단 없이 오래 수행할 수 있다. - 코딩 및 연구 작업을 비동기적으로 실행해 사용자의 지속적인 개입을 줄인다. - 모델이 작업 중 얻은 학습 내용을 바탕으로 기술을 갱신하고, 자체 테스트 하네스와 평가 방식을 만들 수 있다. ## 고급 비전 기능 - 파일과 PDF 안에 포함된 다이어그램, 차트, 표를 해석한다. - 금융, 법률, 분석, 건축, 게임처럼 시각 자료가 많은 업무에 활용할 수 있다. - 코딩 과정에서 설계 이미지를 분석하고, 구현 결과가 원래 목표와 얼마나 일치하는지 스스로 검토할 수 있다. ## 오용 방지를 위한 안전장치 - Fable 5는 광범위한 사용을 목표로 강력한 안전 제한을 포함한다. - 사이버보안, 생물학, 화학, 보건과 관련된 유해 요청은 Opus 4.8로 대신 처리된다. - 안전장치가 없는 동일 계열 모델인 Claude Mythos 5는 검증된 일부 고객에게만 제공된다. - 높은 수준의 안전장치를 통해 Fable 5의 고성능 기능을 더 많은 고객에게 공개할 수 있다는 것이 Anthropic의 설명이다. ## Amazon Bedrock에서의 접근 방식 - Amazon Bedrock 또는 Claude Platform on AWS에서 사용할 수 있다. - Bedrock에서는 다음 경로를 통해 호출할 수 있다. - Anthropic SDK의 Messages API - `bedrock-mantle` 및 `bedrock-runtime` 엔드포인트 - AWS CLI와 AWS SDK의 Invoke API, Converse API - Bedrock 콘솔의 Playground - 예시 모델 식별자는 Anthropic SDK에서 `anthropic.claude-fable-5`, Converse API에서 `global.anthropic.claude-fable-5`로 제시된다. ## 데이터 공유 및 보관 조건 - 모델 호출 전에 Data Retention API를 사용해 `provider_data_share`를 설정해야 한다. - 출시 시점에는 이 설정을 위한 콘솔 UI가 제공되지 않는다. - `bedrock-mantle`에서는 `/v1/data_retention`, `bedrock-runtime`에서는 `/data-retention` 엔드포인트를 사용한다. - Anthropic은 입력과 출력 데이터를 30일 동안 보관하고 사람에 의한 검토를 요구한다. - 데이터 공유를 활성화하면 추론 데이터가 AWS 외부로 전달될 수 있으므로, 조직의 보안·규정 준수 정책을 먼저 확인해야 한다. ## Python 호출 예시 - Anthropic SDK 사용 시 `anthropic` 패키지를 설치하고 Bedrock Mantle 엔드포인트를 `base_url`로 지정한다. - `client.messages.create()`에 모델명, 최대 토큰 수, 사용자 메시지를 전달해 호출한다. - Boto3의 Converse API를 사용하면 Bedrock의 통합 멀티모델 인터페이스로 Fable 5를 호출할 수 있다. - 예시 작업으로는 여러 지역에서 초당 10만 요청을 처리하는 AWS 분산 아키텍처 설계가 제시됐다. ## 이용 권한과 가격 - 모델 접근 권한은 AWS 계정별로 단계적으로 확대된다. - 아직 접근할 수 없는 계정은 Bedrock 사용량에 따라 추후 활성화되며, 빠른 사용이 필요하면 AWS Support에 문의할 수 있다. - 유해 요청이 Opus 4.8로 라우팅되면 Opus 가격이 적용된다. - 대화 중간에 차단되는 경우 초기 토큰에는 Fable 요금, 이후 토큰에는 Opus 요금이 적용될 수 있다. - Mythos급 모델은 오용 패턴 탐지를 위해 전체 트래픽에 제한적인 데이터 보관이 요구된다. 실제로 도입할 때는 모델 성능뿐 아니라 30일 데이터 보관, 사람의 데이터 검토, AWS 외부 데이터 공유 가능성을 반드시 검토해야 한다. 민감한 업무라면 먼저 Bedrock 권한과 보안 정책을 확인한 뒤 제한된 테스트 환경에서 Messages API나 Converse API로 평가하는 것이 좋다.

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

Python생성형 AIamazon-bedrockaws-cli+4

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 환경에서는 최소 권한 토큰, 짧은 수명의 자격 증명, 네트워크 제한, 패키지 허용 목록을 적용하는 것이 안전하다.

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

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

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

Skill 품질 관리를 위한 Rubric 설계와 시스템 구현

Skill은 코딩 에이전트가 개발 과정에서 호출해 사용하는 문서형 도구이므로, 내용이 좋아도 호출되지 않으면 아무런 가치가 없다. 글은 Skill 품질을 6개 섹션 30개 항목으로 평가하고, 형식처럼 결정적으로 검증할 수 있는 항목은 규칙 기반으로, 호출 적합성처럼 의미 판단이 필요한 항목은 LLM 기반으로 분리해야 한다고 주장한다. 특히 BLOCKER가 하나라도 있으면 F 등급으로 처리해 Merge 차단 여부를 단순하게 판단하는 것이 핵심이다. ## Skill 평가가 어려운 이유 - Skill은 컴파일이나 테스트처럼 명확한 통과·실패 기준이 없다. - 결함이 있어도 호출되지 않거나, 호출돼도 효과가 없는 상태로 조용히 남을 수 있다. - 대표적인 문제는 다음 두 가지다. - **트리거 실패**: 호출 조건을 본문에 작성하고 `description`에는 적지 않아 에이전트가 Skill을 호출하지 못하는 문제 - **형식 위반**: `name`이 kebab-case가 아니거나, `name`과 폴더명이 달라 Skill 자체가 인식되지 않는 문제 ## 규칙 기반 검사와 모델 기반 검사의 분리 - 형식·구조처럼 결과가 명확한 항목은 정규식, 카운트, AST 파싱 등 결정적 도구로 검사한다. - 트리거의 의미나 설명의 충분성처럼 문맥 판단이 필요한 항목은 LLM이 평가한다. - 30개 평가 항목은 다음처럼 나뉜다. - 규칙 검사 17개 - 모델 검사 13개 - 역할을 섞으면 문제가 발생한다. - 결정적 결함을 LLM에 맡기면 애매한 상태를 통과시키는 False Negative가 생긴다. - 의미적 판단을 정규식으로 처리하면 표현의 다양성을 놓쳐 False Positive가 늘어난다. - 규칙 검사는 비용이 거의 없어 모든 PR에서 실행할 수 있고, LLM 검사는 규칙 검사를 통과한 Skill에만 적용해 비용을 줄인다. ## 6개 섹션 30개 항목의 평가 구조 - 각 항목은 `BLOCKER`, `MAJOR`, `MINOR` 심각도를 가진다. - 결과는 S부터 F까지 5단계 등급으로 표시한다. - `BLOCKER`가 하나라도 있으면 무조건 F다. - 세부 등급은 작성자에게 상태를 알려주는 신호로 사용하고, 실제 Merge 차단은 F 여부만으로 결정한다. - 이 방식은 등급의 미세한 차이를 두고 불필요하게 논쟁하는 일을 줄인다. ## 타당성: Skill이 정말 필요한가 - Skill을 만들 만한 가치가 있는지 평가한다. - 핵심 질문은 다음과 같다. - 반복적으로 발생하는 작업인가? - 코딩 에이전트가 일반적인 지시만으로 처리하기 어려운가? - Skill로 만들어 제공할 때 지속적인 이점이 있는가? - 일회성 작업이나 에이전트에게 그대로 시켜도 되는 작업은 Skill로 만들 필요가 없다. - 다른 섹션이 이미 만들어진 Skill의 품질을 점검한다면, 타당성 섹션은 애초에 만들지 말았어야 할 Skill을 걸러내는 역할을 한다. - 이 섹션에는 3개 항목이 있으며 모두 MAJOR 수준이다. ## 구조: 형식 오류를 결정적으로 차단 - 구조 섹션은 8개 항목으로 구성되며, 그중 5개가 BLOCKER다. - 예시로 다음을 검사한다. - frontmatter 존재 여부와 YAML 파싱 가능 여부 - `name`의 kebab-case 준수 여부 - `name`과 폴더명 일치 여부 - `description` 길이가 1~1024자 범위인지 여부 - 본문에 허용되지 않은 XML 태그가 포함됐는지 여부 - 구조 검사는 전부 규칙 기반으로 처리하며 LLM을 사용하지 않는다. - frontmatter 자체가 파싱되지 않는 경우에는 즉시 반환하지만, 그 외 오류는 가능한 한 끝까지 검사한다. - 여러 오류를 한 번에 반환해 PR 작성자가 한 번의 피드백으로 모두 수정할 수 있도록 설계했다. - 형식 검사는 정교함보다 매번 동일한 결과를 내고 누락 없이 동작하는 것이 중요하므로, 단순한 구현을 유지한다. ## 트리거: Description에 WHAT과 WHEN을 함께 작성 - 에이전트는 Skill을 호출할지 결정할 때 이름과 `description`만 본다. - Skill 본문은 호출이 결정된 뒤에 읽힌다. - 따라서 본문에만 다음과 같은 조건을 작성하면 호출되지 않는다. - “언제 사용하는가” - “어떤 상황에서 호출하는가” - `Use when ...` - `description`에는 Skill이 무엇인지뿐 아니라 언제 사용해야 하는지도 포함해야 한다. - 트리거 섹션은 6개 항목으로 구성되며, 본문에만 트리거 조건이 있는 경우 BLOCKER로 처리한다. - 처음에는 `when`, `use when`, “할 때”, “사용 시” 같은 표현을 정규식으로 검사했지만 한계가 있었다. - 한국어 표현을 놓치면 잘못된 BLOCKER가 발생한다. - 이모지, 완곡한 표현, 다양한 문장 구조를 모두 규칙으로 포괄하기 어렵다. - 최종적으로는 “Description이 본문의 트리거 조건을 의미적으로 충분히 포함하는가?”를 LLM이 판단하도록 전환했다. ## 운영 방식과 설계 원칙 - BLOCKER 구조 오류는 LLM 평가 전에 차단해 불필요한 모델 호출을 줄인다. - 구조 검사 결과를 오류 목록으로 한 번에 제공해 수정 비용을 낮춘다. - 복잡한 전략 패턴 같은 확장 설계보다 현재 요구사항에 맞는 단순한 검사 코드를 우선한다. - 규칙 기반과 모델 기반의 책임 영역을 명확히 나누는 것이 Rubric 전체의 핵심 원칙이다. 실무에서는 먼저 frontmatter, 이름 규칙, 폴더 구조 같은 형식 검사를 자동화하고, 이를 통과한 Skill에 대해서만 트리거 적합성과 내용 품질을 LLM으로 평가하는 방식을 권장한다. 특히 `description`에는 Skill의 기능(WHAT)과 사용 시점(WHEN)을 모두 명시해야 하며, BLOCKER 하나만으로도 배포나 Merge를 막도록 운영하면 호출되지 않는 Skill을 조기에 줄일 수 있다.

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

Python대규모 언어 모델yamlcoding-agents+3

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

홍수 회복력의 다음 장: Google의 수문학 프레임워크 오픈 소스 공개

Google Research는 Google Flood Hub에 사용된 홍수 예측 수문 모델의 아키텍처와 학습 파이프라인을 오픈소스로 공개했다. 이를 통해 각국 기상·수문 기관이 자체 데이터와 지역 지식을 활용해 AI 기반 하천 홍수 예측을 구축하고 운영할 수 있게 된다. 연구용 재현뿐 아니라 실제 경보 시스템과의 통합까지 지원해, 전 세계 홍수 대응 역량을 확대하는 것이 공개의 핵심 목적이다. ## 오픈소스 공개의 목적 - 홍수는 예고 없이 발생하고 장기적인 피해를 남기므로, 더 긴 예측 시간과 신속한 경보가 중요하다. - 공개된 프레임워크는 Google Flood Hub의 하천 홍수 예측 모델과 유사한 구조 및 학습 데이터를 활용할 수 있도록 설계됐다. - 연구자는 새로운 모델·데이터·학습 방식을 추가해 실험할 수 있다. - 각국의 운영 예보 기관은 자국의 관측 자료와 지역 전문 지식을 반영해 모델을 조정할 수 있다. - 기관이 데이터를 외부에 넘기지 않고 자체적으로 관리하면서도 최신 AI 예측 기술을 활용할 수 있다. ## 수문 모델의 구성과 작동 방식 - Python 패키지로 제공되며, 오픈소스 딥러닝 프레임워크인 PyTorch를 사용한다. - 입력 데이터에는 다음과 같은 정보가 포함된다. - 기후 및 기상 정보 - 토양 특성 - 지형 - 토지 피복 - 강수량과 기온 등 기상 예보 - 모델은 이러한 자료를 바탕으로 하천의 일일 유량을 예측한다. - 기본 모델 아키텍처로 LSTM(Long Short-Term Memory) 네트워크를 제공한다. - 학습에는 오픈소스 하천 데이터셋인 Caravan을 사용할 수 있다. - 사용자는 자체 유역의 관측 자료를 Caravan에 추가하거나, 이를 이용해 모델을 재학습·미세 조정할 수 있다. - 구현을 돕기 위해 Python 인터랙티브 튜토리얼과 동영상 자료도 제공된다. ## 모델 버전과 예측 성능 개선 - 저장소에는 두 가지 모델 버전이 포함된다. - 2024년 벤치마크 연구에 사용된 초기 모델 - 현재 Flood Hub의 실시간 전 세계 홍수 예측에 사용되는 개선 모델 - 개선된 v2 모델은 여러 기상 입력을 통합하는 ME-LSTM 구조를 사용한다. - 각 기상 데이터 제품을 별도의 네트워크가 임베딩한 뒤, 그 결과를 LSTM에 전달한다. - LSTM은 하천 유량에 대한 확률 분포를 생성해 불확실성까지 반영한다. - 통합되는 주요 기상 자료는 다음과 같다. - Google GraphCast - ECMWF의 IFS - NASA IMERG 위성 강수량 자료 - NOAA CPC 관측 기반 일일 강수량 - 기존 모델과 비교해 신뢰할 수 있는 예측 기간이 다음과 같이 늘었다. - 관측소가 있는 유역: 6일 연장 - 관측소가 없는 유역: 1일 연장 ## 지역 데이터와 현장 지식의 활용 - 세계기상기구(WMO)는 효과적인 재난 경보를 위해 지역 관측 자료와 Indigenous and Local Knowledge(ILK)가 중요하다고 지적한다. - 공개 프레임워크는 지역 예보 담당자가 모델 학습과 운영 과정에 직접 참여할 수 있게 한다. - 전통적인 물리 기반 수문 모델보다 구조가 단순하고 상대적으로 저렴하게 학습할 수 있다. - 지역별 강수 특성, 지형, 유역 반응, 현장 경험 등을 모델에 반영할 수 있다. - 이를 통해 중앙집중형 글로벌 모델을 지역 상황에 맞게 조정할 수 있다. ## CHMI와 Delft-FEWS 통합 사례 - Google은 체코 수문기상연구소(CHMI)와 협력해 모델의 실제 활용 가능성을 검증했다. - CHMI는 AI 모델의 예측 결과가 현지에서 보정된 전통적 개념형 수문 모델과 비슷한 수준임을 확인했다. - 또한 오픈소스 수문 프레임워크를 Delft-FEWS에 연결하는 어댑터를 개발했다. - Delft-FEWS는 국가·지역 수문 기관, NGO, 민간기업 등이 사용하는 운영 홍수 예측 플랫폼이다. - 이 통합 사례는 기존 예보 업무 흐름을 유지하면서 머신러닝 모델을 도입하는 방법을 보여주는 참고 모델이 된다. ## 라이선스와 기대 효과 - 모델 아키텍처, 문서, 학습 자료는 GitHub에 공개됐다. - Apache 2.0 라이선스를 적용해 연구자와 운영 기관이 폭넓게 사용할 수 있다. - 고가의 전통적 예보 인프라를 갖추기 어려운 지역도 고급 홍수 예측 기술에 접근할 수 있다. - 각국 기관이 독립적으로 모델을 개선함으로써 지역 맞춤형 조기경보 체계를 구축할 수 있다. - 장기적으로는 개방형·상호운용 가능한 수문 모델 생태계를 형성해 홍수 대응과 기후 적응 역량을 강화하는 것이 목표다. ## 실용적인 결론 이 프레임워크는 연구용 모델 공개를 넘어, 자체 관측 자료를 보유한 기상·수문 기관이 실제 경보 시스템에 AI를 도입할 수 있도록 만든 실무형 도구다. 도입을 검토하는 기관은 먼저 Caravan과 지역 유량 자료로 모델을 검증한 뒤, Delft-FEWS 같은 기존 운영 플랫폼과 연계하는 방식이 현실적이다.

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

Python머신러닝pytorchflood-forecasting+3

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

Amazon Bedrock에서 OpenAI GPT-5.5, GPT-5.4 모델 및 Codex 시작하기 | Amazon Web Services

OpenAI GPT-5.5·GPT-5.4와 Codex가 Amazon Bedrock에서 정식 제공되어, Responses API를 통해 추론·코딩·에이전트 작업을 수행할 수 있게 되었습니다. GPT-5.5는 최고 난도의 작업에, GPT-5.4는 가격 대비 성능이 중요한 작업에 적합합니다. 모든 처리는 선택한 Bedrock 리전 내에서 수행되며, 좌석 라이선스 없이 토큰 사용량 기준으로 과금됩니다. ## Amazon Bedrock에서 제공되는 모델과 Codex - GPT-5.5와 GPT-5.4는 코딩, 추론, 에이전트 워크플로, 복잡한 전문 업무에 최적화되어 있습니다. - GPT-5.5는 가장 어려운 고객 업무를 위한 고성능 모델입니다. - GPT-5.4는 성능과 비용의 균형을 중시하는 용도에 적합합니다. - OpenAI의 코딩 에이전트인 Codex도 Bedrock에서 사용할 수 있습니다. - 대규모 코드베이스 작성, 리팩터링, 디버깅, 테스트, 검증 지원 - Codex App, CLI, Visual Studio Code·JetBrains·Xcode 통합 제공 - 모든 모델 추론은 Amazon Bedrock의 Responses API를 통해 처리 ## Responses API를 통한 모델 호출 - OpenAI SDK, `curl` 등으로 Bedrock의 `bedrock-mantle` 엔드포인트를 호출할 수 있습니다. - Python SDK 설치: ```bash pip install -U openai ``` - 인증 및 엔드포인트 환경 변수 설정: ```bash export OPENAI_BASE_URL="https://bedrock-mantle.us-east-2.api.aws/openai/v1" export OPENAI_API_KEY="<BEDROCK_API_KEY>" export BEDROCK_OPENAI_MODEL_ID="openai.gpt-5.5" ``` - Python에서는 `client.responses.create()`를 사용합니다. - 요청에 다음과 같은 설정을 지정할 수 있습니다. - `reasoning.effort`: 추론 수준 - `text.verbosity`: 응답의 상세도 - `developer` 메시지: 모델의 역할과 응답 지침 - 예시에서는 AWS 지식이 풍부한 소프트웨어 엔지니어 역할을 부여하고, 여러 리전에 걸친 초당 10만 요청 규모의 AWS 아키텍처를 생성하도록 요청합니다. - `curl`을 사용하면 `/responses` 엔드포인트에 JSON 요청을 직접 전송할 수 있습니다. ## Responses API가 적합한 경우 - 모델이 여러 턴의 대화 상태를 관리해야 할 때 - 호스팅 도구나 함수 도구를 사용해야 할 때 - 여러 도구를 조합하는 복잡한 오케스트레이션이 필요할 때 - 백그라운드 작업이나 장시간 실행되는 작업을 처리할 때 ## Codex를 Bedrock에 연결하는 방법 - Codex CLI, Codex App 또는 VS Code 확장을 설치해 Bedrock을 모델 추론 경로로 사용할 수 있습니다. - 두 가지 인증 방식을 지원합니다. - `AWS_BEARER_TOKEN_BEDROCK`에 Bedrock API 키 설정 - AWS SDK 자격 증명 체인 사용 - `AWS_BEARER_TOKEN_BEDROCK`가 설정되어 있으면 Codex가 이를 우선 사용하고, 없으면 AWS SDK 자격 증명 체인으로 전환합니다. ```bash export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key> ``` - `~/.codex/config.toml`에서 리전과 모델 제공자를 설정합니다. ```toml model = "openai.gpt-5.5" model_provider = "amazon-bedrock" [model_providers.amazon-bedrock.aws] region = "us-east-2" ``` - 사용할 수 있는 모델 ID에는 다음이 포함됩니다. - `openai.gpt-5.5` - `openai.gpt-5.4` - `openai.gpt-oss-120b` - `openai.gpt-oss-20b` - 데스크톱 앱이나 VS Code 확장에서 사용할 환경 변수는 `~/.codex/.env`에 저장할 수 있습니다. - 설정 파일을 변경한 뒤에는 앱이나 확장을 재시작해야 합니다. - Codex CLI에서는 `/status` 명령으로 현재 모델과 연결 상태를 확인할 수 있습니다. ## 지연 시간과 확장성 - 실제 사용자가 느끼는 지연 시간은 모델의 기본 속도뿐 아니라 다음 요소의 영향을 받습니다. - 추론 수준 - 출력 길이 - 도구 호출 횟수 - 백그라운드 실행 여부 - 리전 및 할당량 - 요청 제한(throttling) - 프롬프트 크기 - 캐시 적중 여부 - GPT-5.5는 우선 `reasoning.effort="medium"`으로 시작하는 것이 권장됩니다. - GPT-5.4는 기본값인 `none`에 의존하기보다 애플리케이션 요구사항에 맞춰 추론 수준을 명시하는 것이 좋습니다. - Bedrock의 차세대 추론 엔진은 수요 변화에 맞춰 용량을 빠르게 확보하도록 설계되었습니다. - 수요가 급증하면 요청을 즉시 거부하기보다 큐에 넣어 처리하는 방식으로 안정적인 워크로드 운영을 지원합니다. ## 리전, 데이터 보존, 과금 - 고객이 선택한 Bedrock 리전 내에서 모든 처리가 이루어지므로 데이터 레지던시 요구사항을 충족할 수 있습니다. - 제공 리전은 다음과 같습니다. - GPT-5.5: 미국 동부(오하이오) - GPT-5.4: 미국 동부(오하이오), 미국 서부(오리건) - 향후 지원 리전은 AWS의 전체 리전 목록에서 확인할 수 있습니다. - 개발자 좌석 라이선스나 인원별 약정 없이 토큰 사용량 기준으로 과금됩니다. 실무에서는 먼저 GPT-5.5를 중간 추론 수준으로 테스트하고, 비용과 성능의 균형이 중요하면 GPT-5.4와 명시적인 추론 설정을 비교하는 것이 좋습니다. Codex를 사용할 때는 리전, 인증 방식, 모델 ID를 설정 파일에 고정하고 `/status`로 연결 상태를 확인하면 운영 중 문제를 줄일 수 있습니다.

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

Pythonamazon-bedrockaws-sdkcurl+4

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

GitLab 19.0 | GitLab 문서

GitLab 19.0은 그룹 단위 AI 코드 리뷰 지침, 사용자 정의 작업 항목, Secrets Manager 오픈 베타 등 협업·보안 기능을 확장한 릴리스입니다. 또한 GitLab Duo를 에이전트 중심으로 강화하고, SBOM 기반 의존성 스캔을 정식 제공하며, 사용량 기반 과금과 새로운 모델·트리거를 도입했습니다. 이번 릴리스는 여러 프로젝트를 아우르는 표준화와 에이전트 기반 개발 자동화에 초점을 둡니다. ## 그룹 단위 GitLab Duo 코드 리뷰 지침 - 기존에는 프로젝트별로만 `.gitlab/duo/mr-review-instructions.yaml`을 설정할 수 있었습니다. - 이제 그룹과 하위 그룹 전체에 공통 리뷰 지침을 적용할 수 있습니다. - 그룹 내 특정 프로젝트를 템플릿으로 지정하면, GitLab Duo가 그룹 지침과 개별 프로젝트 지침을 결합해 코드 리뷰를 수행합니다. - Code Review Flow와 GitLab Duo Code Review 모두 지원합니다. - Premium·Ultimate 등급에서 GitLab.com, Self-Managed, Dedicated 환경에 제공됩니다. ## 사용자 정의 작업 항목 유형 - 프로젝트에서 `Issue`, `Task` 외에 `User Story`, `Bug`, `Maintenance` 같은 작업 항목 유형을 직접 생성하거나 이름을 변경할 수 있습니다. - 각 유형은 고유한 이름과 아이콘을 가지며, 사용자 정의 필드와 상태 라이프사이클을 지원합니다. - 저장된 보기와 이슈 보드에서도 유형을 기준으로 작업을 관리할 수 있습니다. - 최상위 그룹 또는 조직에서 설정한 유형 구성이 하위 프로젝트로 전파됩니다. - 프로젝트별로 특정 유형을 활성화하거나 비활성화할 수 있으며, 유형을 비활성화해도 기존 작업 항목에는 영향을 주지 않습니다. ## GitLab Secrets Manager 오픈 베타 - 기존 폐쇄형 베타에서 Premium·Ultimate 고객 대상 오픈 베타로 확대되었습니다. - GitLab.com과 GitLab Self-Managed에서 사용할 수 있습니다. - 프로젝트 및 그룹 Owner가 CI/CD 시크릿을 GitLab에 저장·조회·참조할 수 있습니다. - 시크릿은 프로젝트 또는 그룹 범위로 제한되며, 명시적으로 요청한 파이프라인 작업만 접근할 수 있습니다. - 아직 베타 지원 정책이 적용되므로 운영 환경에 사용하기 전 안정성과 제한 사항을 검토해야 합니다. ## GitLab Duo Developer의 MR 자동화 - 이슈 할당, `Generate MR` 선택, 이슈·MR 토론에서의 `@mention` 등 여러 방식으로 Developer를 실행할 수 있습니다. - 피드백, To-do, 디자인 관련 질문을 코드 변경, 후속 MR, 조사 요약으로 전환할 수 있습니다. - `AGENTS.md`와 `agent-config.yml`을 설정하면 커밋 전에 테스트와 검사를 실행하도록 구성할 수 있습니다. - 최상위 그룹 또는 인스턴스 관리자가 Developer Flow를 활성화하면 대상 프로젝트에 멘션 및 할당 트리거가 자동으로 추가됩니다. ## SBOM 기반 의존성 스캔 정식 제공 - Maven, Gradle, Python 프로젝트에서 직접 선언한 의존성뿐 아니라 전이 의존성까지 분석합니다. - lockfile이나 해석된 의존성 그래프가 없으면 Maven·Gradle·Python 도구를 자동 실행해 전체 그래프를 생성합니다. - v2 Dependency Scanning 템플릿을 포함하는 것 외에 별도 설정이 거의 필요하지 않습니다. - 의존성 해석이 불가능한 경우 `pom.xml`, `requirements.txt`, `build.gradle`, `build.gradle.kts`를 분석하는 매니페스트 스캔으로 대체됩니다. - 매니페스트 스캔은 직접 의존성만 제공하므로, 전이 의존성까지 확인하려면 lockfile·그래프 파일 또는 의존성 해석 기능이 필요합니다. - Ultimate 등급 기능입니다. ## GitLab Duo Core의 사용량 기반 과금 - GitLab Duo Core가 19.0부터 사용량 기반 과금으로 변경됩니다. - Web IDE와 데스크톱 IDE의 Code Suggestions 사용량이 GitLab Credits를 소비합니다. - Duo Chat은 GitLab Duo Agent Platform 기반의 에이전트 방식으로 변경됩니다. - GitLab UI나 데스크톱 IDE에서 Chat을 사용하려면 인스턴스 또는 최상위 그룹에서 Agent Platform을 활성화해야 합니다. ## 코드 검색과 MR 자동화 트리거 - 정확한 코드 검색 결과를 `repo:` 구문으로 특정 저장소에 한정할 수 있습니다. - 예를 들어 `def authenticate repo:my-group/my-project`처럼 검색하면 지정한 저장소의 결과만 확인할 수 있습니다. - 부분 경로나 패턴을 사용해 여러 저장소를 한 번에 검색할 수도 있습니다. - Draft MR이 리뷰 준비 상태로 전환될 때 Flow나 외부 에이전트를 실행하는 `Merge request ready` 이벤트 트리거가 추가되었습니다. - 프로젝트의 `AI > Triggers`에서 설정하며, `merge_request_ready_flow_trigger` 기능 플래그 뒤에 있고 기본값은 비활성화입니다. ## GitLab Duo Agent Platform의 모델 확장 - Claude Opus 4.7을 Agent Platform에서 사용할 수 있습니다. - 복잡한 다단계 작업, 지시 준수, 결과 검증이 필요한 CI/CD, 코드 리뷰, 취약점 수정 플로우에 적합하도록 개선되었습니다. - GitLab Self-Managed용 Duo Agent Platform은 자체 호스팅 Gemini 모델도 지원하기 시작했습니다. - 제공된 글 내용은 Gemini 지원이 여러 플로우를 지원한다는 설명 중간에서 끝나므로, 세부 지원 범위는 공식 문서를 확인해야 합니다. ## 릴리스의 방향 - 여러 프로젝트에 공통 AI 리뷰 정책과 작업 유형을 적용해 그룹 단위 표준화를 강화했습니다. - 에이전트가 이슈와 MR에서 직접 코드를 수정하고 검증하는 개발 흐름을 확대했습니다. - SBOM 및 전이 의존성 분석으로 공급망 보안 가시성을 높였습니다. - Duo 사용량 기반 과금과 Secrets Manager 베타 도입에 따라 비용 및 운영 정책 검토가 중요해졌습니다. 도입 시에는 그룹 공통 리뷰 지침과 작업 유형을 먼저 표준화하고, SBOM 스캔에서 전이 의존성 해석이 실제로 활성화되었는지 확인하는 것이 좋습니다. Secrets Manager와 새로운 Agent Platform 기능은 베타·기능 플래그 상태와 과금 영향을 검증한 뒤 점진적으로 적용하는 것을 권장합니다.

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

PythonCI/CDgitlabgitlab-duo+4

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

ODW #6: Git 자동화 관점에서 본 MCP와 에이전트 스킬의 장단점

AI 에이전트 개발에서는 MCP 서버보다 에이전트 스킬이 구현과 아키텍처 측면에서 간단해지는 추세다. 글은 `skill-creator`를 활용해 Git 릴리스 자동화 스킬을 만들고, 요구사항을 구체화하는 과정을 실무 예제로 설명한다. 핵심은 명확한 프롬프트와 로컬 Python 스크립트를 결합해 반복 작업을 자동화하는 것이다. ## MCP에서 에이전트 스킬로의 전환 - MCP 서버 구축보다 에이전트 스킬이 구현하기 쉽고 구조가 단순하다. - 기본 개념이나 대규모 GitHub 예제는 많지만, 일상 업무에 적용하는 실용적인 안내는 부족하다. - 이 글은 스킬 자체의 개념을 깊게 설명하기보다 실제 예제를 만들며 활용 방법을 보여주는 데 초점을 둔다. ## Git 스마트 릴리스 자동화 스킬 - 현재 디렉터리의 Git 프로젝트를 자동으로 릴리스하는 스킬을 예제로 선택했다. - `skill-creator`를 사용해 스킬 정의와 실행 스크립트를 자동 생성한다. - 핵심 작업 흐름은 다음과 같다. - 가장 최근 태그 이후의 `git log` 분석 - 변경 사항을 요약해 `CHANGELOG.md` 최상단에 추가 - `pyproject.toml`의 버전 변경 - 변경 파일 커밋 - 새 버전 태그 생성 - 스킬은 현재 터미널 경로인 `pwd`를 기준으로 동작하는 로컬 Python 스크립트 형태로 구성한다. ## 명확한 요구사항의 중요성 - 에이전트가 엉뚱한 디렉터리를 수정하거나 과도하게 복잡한 계획을 세우지 않도록 목표와 제약 조건을 프롬프트에 구체적으로 작성해야 한다. - 초기 요구사항에는 다음 내용이 포함된다. - `v0.1.0` 등 최근 태그 이후의 커밋 조회 - `CHANGELOG.md`가 없으면 새로 생성 - 버전을 patch 단위로 증가 - `chore: release v[새 버전]` 형식으로 커밋 - 새 버전의 Git 태그 생성 - 현재 작업 경로에서만 실행 ## 대화형 요구사항 구체화 에이전트는 모호한 부분을 질문하고, 사용자는 답변을 통해 스킬 동작을 확정한다. - 버전 증가 방식 - patch, minor, major 모두 지원 - 사용자가 원하는 릴리스 유형을 선택 - 최초 릴리스 - 기존 태그가 없으면 `v0.1.0`부터 시작 - 변경 로그 - Keep a Changelog 형식을 따름 - 버전, 날짜, `feat`, `fix`, `docs` 등의 변경 분류를 포함 - 원격 저장소 - 로컬 커밋과 태그 생성 후 원격 저장소에도 push - 작업 디렉터리 안전성 - 커밋되지 않은 변경 사항이 있으면 작업을 중단 - 중단 이유를 사용자에게 설명 ## 생성된 스킬의 구조 - `git-smart-release/SKILL.md` - 스킬의 메타데이터와 에이전트가 따라야 할 실행 절차를 담는다. - `git-smart-release/scripts/smart_release.py` - Git 명령 실행, 파일 수정, 버전 변경 등 실제 작업을 수행한다. - `git-smart-release/evals/evals.json` - 스킬 동작을 검증하기 위한 테스트 케이스를 담는다. ## SKILL.md와 실행 스크립트의 역할 - 프런트매터 - YAML 형식의 메타데이터다. - 에이전트가 스킬을 언제 사용할지 판단할 수 있도록 짧은 설명과 검색 정보를 제공한다. - 마크다운 본문 - 스킬 사용이 결정된 뒤 읽히는 실행 매뉴얼이다. - 구체적인 절차와 워크플로를 정의한다. - `smart_release.py` - Git 상태 확인, 로그 분석, 파일 변경, 커밋과 태그 생성 등을 직접 처리한다. - LLM이 모든 파일 내용을 직접 읽고 수정하는 대신 결정된 작업을 코드로 실행해 토큰 사용과 오류를 줄인다. ## 실무 적용 방식 - 사용자는 “릴리스해 줘”처럼 자연어로 요청할 수 있다. - 에이전트는 요청에 맞는 버전 유형을 선택하고 스킬 지침을 따른다. - 스크립트는 먼저 작업 디렉터리가 깨끗한지 확인한다. - 변경 사항이 있으면 안전을 위해 중단하고, 문제가 없을 때만 변경 로그 작성부터 커밋·태그·원격 push까지 진행한다. - 글은 이후 Python 계산기 프로젝트를 대상으로 제작한 스킬을 테스트하는 시나리오로 이어진다. 반복적인 Git 릴리스 업무를 자동화하려면 요구사항, 예외 처리, 실행 범위를 프롬프트에 명확히 적고, 실제 파일·Git 조작은 검증 가능한 스크립트로 분리하는 것이 좋다. 특히 자동 push 기능은 되돌리기 어려우므로 dirty check와 실행 전 확인 절차를 함께 두는 것을 권장한다.

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

Python모델 컨텍스트 프로토콜claude-codeGit+3