techlist.io
KREN

Techlist.io - 한국 테크 블로그 큐레이터

github4분 읽기큐레이션 요약

거대한 AI 생성 풀 리퀘스트 하나를 검토 가능한 스택으로 바꾸기

AI 코딩 에이전트는 짧은 시간에 대규모 기능을 구현하지만, 모든 변경을 하나의 거대한 PR에 담는 방식은 리뷰 품질과 병합 속도를 떨어뜨린다. 이 글은 기능을 데이터·API·애플리케이션 연결·UI처럼 논리적 계층으로 나누고, 각 계층을 작은 PR로 쌓는 “스택드 풀 리퀘스트(stacked pull requests)”를 대안으로 제시한다. 이를 통해 에이전트의 생산성은 유지하면서도 각 변경을 독립적으로 검토하고 관리할 수 있다. ## AI가 만든 대규모 PR의 문제 - 쇼핑 어시스턴트에 상품 검색 기능을 추가하면 다음 변경이 한 PR에 함께 들어가기 쉽다. - 새 데이터 모델과 시드 데이터 - API 라우트와 입력 검증 - 클라이언트 연결 - UI 및 빈 상태·오류 상태·대체 상태 - 결과적으로 1,000~1,700줄 이상의 큰 diff가 만들어질 수 있다. - 리뷰어는 변경 내용을 한 번에 이해하기 어렵고, PR 설명이 길지만 구체적이지 않으면 검토를 뒤로 미루게 된다. - 리뷰가 늦어지면서 문맥이 사라지고 피드백 품질이 낮아지며, 충돌과 수동 동기화가 늘어난다. - 결국 기능이 충분히 검토되지 않은 채 병합될 위험이 커진다. ## 스택드 풀 리퀘스트의 기본 원리 - 하나의 대형 PR 대신 기능을 논리적으로 분해해 여러 개의 작은 PR로 만든다. - 각 PR은 하나의 관심사만 다루며, 리뷰어가 한 번에 이해할 수 있는 크기로 제한한다. - PR은 의존성 순서에 따라 연결된다. - 하위 계층이 먼저 구현되고, 상위 계층은 그 변경을 기반으로 작업한다. - 이전 계층에서 얻은 문맥은 다음 계층으로 자연스럽게 이어지므로, 전체 기능을 매번 처음부터 읽을 필요가 없다. - 데이터 담당자, 백엔드 담당자, UI 담당자처럼 변경 영역에 맞는 리뷰어를 배정할 수 있다. ## 상품 검색 기능의 스택 구조 | 계층 | 브랜치 | 작업 내용 | 의존 대상 | |---|---|---|---| | L1 | `feat/catalog-data` | 타입이 지정된 카탈로그, 시드 데이터, 검증, 데이터 접근 모듈 | `main` | | L2 | `feat/search-api` | 검증을 포함한 `/api/products/search` 엔드포인트 | L1 | | L3 | `feat/chat-grounding` | 채팅이 API를 호출하고 실제 상품 데이터에 기반해 응답 | L2 | | L4 | `feat/grounded-ui` | 상품 인용 카드와 UI 상태 처리 | L3 | - 데이터, API, 애플리케이션 연결, UX가 각각 독립된 작업 단위가 된다. - 각 계층은 자체적으로 리뷰할 수 있지만, 전체 기능은 계층 간 의존성을 통해 완성된다. - 가장 기반이 되는 작업을 스택의 아래쪽에 배치하고, 그 위에 이를 사용하는 작업을 쌓는다. ## GitHub 도구와 초기 설정 - GitHub는 PR 화면뿐 아니라 터미널에서도 스택드 PR을 관리할 수 있다. - `gh-stack` CLI 확장 설치: ```bash gh extension install github/gh-stack ``` - 코딩 에이전트가 스택 구조를 이해하고 생성·관리하도록 관련 스킬을 설치할 수 있다. ```bash gh skill install github/gh-stack ``` 또는: ```bash npx skills add github/gh-stack ``` - 스택을 시작하기 전에 스택의 기준 브랜치(stack base)를 정해야 한다. - 일반적으로 `main`이 기준이 된다. - CI 검사와 병합 규칙이 전체 스택에서 이 기준을 바탕으로 평가된다. - 모든 계층에 CI가 존재하는지 확인해야 한다. - 각 PR 계층마다 CI 검사가 실행된다. - 따라서 작은 PR이라도 테스트와 규칙 검증을 통과해야 한다. ## 에이전트별 작업 분담 - 에이전트에게 전체 기능을 한 번에 맡기기보다, 계층별로 역할과 범위를 지정한다. - 예시 구성: - L1: 데이터 모델러 에이전트 - L2: 백엔드 에이전트 - L3: 프론트엔드 에이전트 - L4: 프론트엔드 에이전트 - 각 에이전트는 하나의 작업 스트림과 엄격한 범위를 따르도록 구성한다. - 이런 방식은 에이전트가 자동화 루프에서 작업하더라도 결과물이 지나치게 커지는 것을 방지한다. - 작업 순서는 데이터 기반을 먼저 만들고, API, 채팅 연결, UI 순으로 진행한다. ## 실용적인 적용 방법 - 기능을 시작할 때 먼저 데이터·도메인 모델·API·애플리케이션 연결·UI로 나눈다. - 각 PR이 단일 관심사만 포함하는지 확인한다. - 기반 브랜치를 먼저 만들고, 각 후속 브랜치를 바로 이전 계층에서 파생한다. - 계층별로 적절한 리뷰어를 배정하고, 각 PR에 해당 계층의 목적과 검증 방법을 명확히 작성한다. - AI 에이전트에는 “전체 기능 구현”이 아니라 특정 스택 계층과 변경 범위를 명시하는 것이 좋다. - 스택드 PR은 리뷰 부담을 줄이는 대신 브랜치 의존성을 관리해야 하므로, CLI와 자동화 도구를 함께 사용하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
CI/CDgithubAPI 설계coding-agents+2
cloudflare4분 읽기큐레이션 요약

에이전트 개발 수명주기가 Cloudflare에 도래했습니다

AI는 소프트웨어 구현을 가장 빠르고 저렴한 단계로 만들었지만, 그 결과 테스트·배포·운영·유지보수 단계가 감당하기 어려운 속도로 몰려들고 있다. 글은 인간 중심의 SDLC만으로는 에이전트가 생산하는 코드와 변경량을 처리할 수 없다고 주장하며, 전체 개발 과정을 에이전트 중심의 ADLC(Agent Development Lifecycle)로 재설계해야 한다고 제안한다. 이를 위해서는 에이전트가 코드 작성뿐 아니라 검증, 배포, 관측, 장애 대응, 개선까지 수행할 수 있는 소프트웨어 팩토리와 전용 플랫폼이 필요하다. ## AI가 바꾼 소프트웨어 개발 생태계 - 전통적인 SDLC는 다음 단계로 구성된다. - 계획(Plan) - 설계(Design) - 구현(Implement) - 테스트(Test) - 배포(Deploy) - 유지보수(Maintain) - 폐기(Retire) - AI는 기존에 가장 느리고 비용이 많이 들던 구현 단계를 급격히 빠르고 저렴하게 만들었다. - 그러나 구현 이후의 단계는 같은 속도로 자동화되지 않아 다음과 같은 병목이 발생한다. - 오픈소스 프로젝트에 쏟아지는 풀 리퀘스트와 이슈 - 급증한 배포량을 처리해야 하는 운영 엔지니어 - 검토·병합·배포·장애 대응을 담당하는 사람들의 과부하 - 현재 많은 조직은 에이전트에게 코드 작성만 맡기고, 검증과 운영은 사람이 담당하는 불균형한 구조를 사용하고 있다. ## SDLC에서 ADLC로의 전환 - 글은 인간 중심의 SDLC를 에이전트 중심의 ADLC로 대체해야 한다고 주장한다. - ADLC의 목표는 에이전트가 단일 작업이 아니라 다음 전체 흐름을 자율적으로 처리하는 것이다. - 버그 리포트나 고객 요청 수집 - 문제 재현과 원인 분석 - 코드 수정 - 테스트와 검증 - 리뷰 및 병합 - 배포와 모니터링 - 운영 중 발생한 문제의 자동 triage와 수정 - 현재는 사람이 각 SDLC 단계에서 에이전트를 지시하고 결과를 확인하는 방식이 대부분이다. - 소프트웨어 팩토리는 이러한 사람의 개입을 줄이고, 인간이 창의성·판단·고객 이해가 필요한 업무에 집중하도록 만드는 시스템이다. ## 소프트웨어 팩토리에 필요한 플랫폼 특성 에이전트가 전체 개발 프로세스를 운전하려면 기존의 인간용 개발 환경을 그대로 사용할 수 없으며, 각 작업이 다음 특성을 가져야 한다. - **프로그램화 가능성** - ClickOps처럼 사람이 화면을 클릭해야 하는 작업은 에이전트에 적합하지 않다. - 모든 작업이 호출·디버깅·자동화 가능한 API를 제공해야 한다. - **수평 확장성** - 여러 에이전트가 동시에 작업할 수 있어야 한다. - 각 에이전트가 운영 환경과 일치하는 독립적인 프리뷰 환경을 가져야 한다. - **재현 가능성** - 특정 기기, 네트워크 상태, 국가별 IP 등 복잡한 조건에서 발생하는 버그도 재현할 수 있어야 한다. - 단순한 단위 테스트와 통합 테스트만으로는 부족하다. - **실시간·푸시 기반 동작** - 사람이 대시보드를 확인하기를 기다리는 방식은 에이전트에 맞지 않는다. - 장애나 상태 변화가 발생하면 이벤트가 에이전트를 자동으로 호출해야 한다. - **원자성** - 각각의 변경은 독립적으로 테스트·배포·관측·롤백 가능해야 한다. - 한 변경이 관련 없는 동작에 영향을 주지 않아야 한다. - **권한 관리** - 에이전트에 운영 환경의 무제한 권한을 제공할 수는 없다. - 작업에 필요한 권한을 명확히 제한하면서도, 안전한 절차를 통해 추가 권한을 요청하거나 상승시킬 수 있어야 한다. - **자기 개선** - 에이전트도 과거 작업과 운영 경험으로부터 학습해야 한다. - 반복되는 작업에서 점점 더 빠르고 정확하게 동작할 수 있는 피드백 체계가 필요하다. ## Cloudflare가 제시한 구현 사례 Cloudflare는 에이전트를 단순한 코드 생성기가 아니라 API를 통해 전체 시스템을 조작하는 고객으로 취급한다. 이를 바탕으로 다음과 같은 도구와 사례를 소개한다. - `@cloudflare/ci` - 수백만 개 저장소에서 CI/CD를 실행하기 위한 시스템 - Cloudflare Workflows를 기반으로 동작 - 실패를 스스로 복구하고, 복잡한 작업을 수행할 에이전트를 생성할 수 있음 - 로컬 개발 환경의 OpenTelemetry 트레이스 - 운영 환경에서 사용하는 수준의 관측성을 로컬 개발에도 제공 - Wrangler와 Cloudflare Vite 플러그인에 통합 - Cloudflare Agents와 Agent Traces - 에이전트의 실행을 관찰하고 유지보수하며 개선하기 위한 공간 - 에이전트 활동을 OpenTelemetry 트레이스로 추적 - AI 기반 엔지니어링 표준 적용 - 여러 제품과 시스템 저장소에 공통 개발 원칙과 표준을 자동으로 적용 - Astro 소프트웨어 팩토리 - GitHub 이슈를 자동으로 분류하고, 재현하고, 검증하고, 수정 - 규모가 커지는 오픈소스 프로젝트의 이슈 수를 0에 가깝게 줄이는 것을 목표로 함 ## 자율 시스템에 필요한 신뢰성 - 소프트웨어 팩토리는 자율주행차와 비슷한 문제를 가진다. - 단순히 80% 정도 성공하는 수준은 충분하지 않다. - 실제 운영 소프트웨어를 맡기려면 99%를 넘어 여러 개의 9가 붙는 수준의 안정성과 안전성이 필요하다. - 자율주행차가 카메라, 라이다, 고성능 연산 장치, 원격 제어 체계를 갖추는 것처럼, 자율적으로 개발하는 에이전트에도 인간 개발자를 위해 설계된 기존 도구 이상의 장치가 필요하다. - 에이전트가 PR을 자동 승인하고 운영 서비스에 병합하지 못하는 이유는 테스트 실패뿐 아니라 다음과 같은 복합적인 위험 때문이다. - 고객 요구를 잘못 해석할 가능성 - 여러 팀과 전문 영역에 걸친 변경 - 주관적인 품질 판단 - 대시보드나 사용자 경험처럼 자동 테스트가 어려운 변화 - 운영 중 발생할 수 있는 예측하기 어려운 부작용 ## 실용적인 결론 에이전트 도입의 핵심은 코드 생성량을 늘리는 데 있지 않고, 생성된 변경을 안전하게 검증하고 배포하고 운영하는 전체 체계를 함께 자동화하는 데 있다. 따라서 조직은 에이전트에 단순한 코딩 권한만 주기보다, 재현 가능한 환경·세밀한 권한·실시간 관측·원자적 배포·자동 롤백과 같은 ADLC 기반 인프라부터 구축해야 한다.

원문 읽기(새 탭에서 열림)
AI 에이전트CI/CDcloudflareGitHub Actions+3
cloudflare4분 읽기큐레이션 요약

수백만 개 리포지토리의 CI/CD를 실행하세요 — 여러분의 플랫폼에서, Cloudflare에서

Cloudflare는 코드 저장소인 Artifacts를 기반으로 빌드·테스트·배포까지 전 과정을 Cloudflare에서 실행하는 CI/CD 환경을 구축하고 있다. 새 CI SDK는 Cloudflare Workflows와 Sandbox SDK를 결합해 CI 파이프라인을 TypeScript로 정의하고, 코드가 Artifacts에 push될 때 자동으로 실행할 수 있게 한다. 각 단계의 재시도·타임아웃·캐싱·병렬 실행을 지원하며, 성공한 경우에만 자동 배포하거나 AI 에이전트를 통한 자동 수정도 가능하다. ## Cloudflare에서 완성되는 코드 개발 생태계 - Cloudflare는 다음 과정을 하나의 플랫폼으로 통합하려 한다. - 코드 저장: Artifacts - 빌드 및 테스트: CI SDK와 Workflows - 배포: `wrangler deploy` - Artifacts는 수백만 개의 저장소를 저장하고 버전을 관리할 수 있는 코드 저장소다. - `wrangler` 설정의 새로운 `events` 필드를 이용하면 Artifacts의 `push` 이벤트를 Workflow 실행으로 직접 연결할 수 있다. - 별도의 이벤트 구독, 큐, 큐 컨슈머를 구성하지 않아도 코드 push를 CI 작업의 시작점으로 사용할 수 있다. ## CI/CD 파이프라인은 하나의 Workflow - CI/CD는 정해진 순서로 여러 단계를 실행하고, 하나라도 실패하면 이후 단계를 중단하는 프로세스다. - Cloudflare는 이를 본질적으로 Workflow와 동일한 구조로 본다. - 기존 YAML 기반 도구 대신 TypeScript의 `step.do()`와 CI SDK를 사용해 파이프라인을 정의할 수 있다. - TypeScript를 사용하면 YAML보다 다음과 같은 장점이 있다. - 조건문과 동적 설정을 쉽게 적용 - 플랫폼별·저장소별 파이프라인 커스터마이징 - 일반 코드와 동일한 방식의 재사용 및 유지보수 ## 격리된 환경에서 실행되는 CI 단계 - CI SDK는 각 명령을 독립적인 Sandbox 환경에서 실행한다. - 대표적인 단계는 다음과 같다. - 의존성 설치 - 코드 빌드 - 린트 실행 - 타입 검사 - 단위 테스트 - 조건부 배포 - 각 Sandbox 명령은 Workflow의 단계로 실행되므로 Cloudflare Workflows가 제공하는 재시도와 타임아웃 기능을 활용할 수 있다. - 기존에는 Sandbox API를 직접 호출하고 단계 간 상태를 별도로 관리해야 했지만, CI SDK가 이 과정을 추상화한다. ## 의존성 캐싱과 병렬 실행 - `bun install --frozen-lockfile` 같은 설치 단계를 먼저 정의하고, `package.json`과 `bun.lock`을 캐시 입력으로 지정할 수 있다. - 의존성 캐시는 계정의 R2 버킷에 Sandbox 스냅샷 형태로 저장된다. - 이후 린트·테스트·타입 검사·빌드 단계는 의존성 설치를 반복하지 않는다. - 독립적인 단계는 `Promise.all()`로 병렬 실행할 수 있어 전체 CI 시간을 줄인다. - 배포 단계는 모든 검사가 성공한 뒤 실행되도록 마지막에 배치한다. ```ts const deps = await ci.runner({ name: "install", command: "bun install --frozen-lockfile", cache: { inputs: ["package.json", "bun.lock"] }, }); await Promise.all([ deps.runner({ name: "lint", command: "bun run lint" }), deps.runner({ name: "test", command: "bun run test" }), deps.runner({ name: "typecheck", command: "bun run typecheck" }), deps.runner({ name: "build", command: "bun run build" }), ]); await deps.runner({ name: "deploy", command: "bun wrangler deploy", cloudflareCredentials: { accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID, }, }); ``` ## 플랫폼 관리 CI와 사용자 정의 CI - 플랫폼 사업자는 고객 애플리케이션을 대신해 CI/CD 파이프라인을 관리할 수 있다. - 하나의 Workflow를 여러 고객 애플리케이션에 공유하면 고객마다 CI 환경을 직접 운영할 필요가 없다. - 반대로 특정 고객이 자체적인 빌드·테스트 규칙을 원한다면 Dynamic Workflows를 이용해 전용 CI를 정의할 수 있다. - 플랫폼이 관리하는 CI와 고객이 직접 작성한 CI는 동일한 namespace 안에서 동시에 실행할 수 있다. - 따라서 모든 고객에게 동일한 파이프라인을 강제하지 않고, 공통 규칙과 개별 요구사항을 함께 지원한다. ## AI 기반 셀프 힐링 CI - CI Workflow에 AI 리뷰 에이전트를 통합할 수 있다. - 빌드 단계가 실패하면 에이전트가 오류를 분석하고 수정 코드를 생성할 수 있다. - 수정 사항을 커밋으로 push해 사람이 검토하고 승인하는 흐름도 구성할 수 있다. - Cloudflare는 이러한 예제를 Project Think의 self-healing CI Workflow로 제공한다. ## 직접 CI Workflow 작성하기 - `@cloudflare/ci`의 `CIWorkflow`를 import해 자체 파이프라인을 작성한다. - 설치 단계에서 Vite, React, esbuild, ESLint, Vitest 등 필요한 패키지와 도구를 설치한다. - lockfile을 지정해 의존성 변경 여부를 검증한다. - 설치 결과를 캐시한 뒤 빌드와 각종 검사를 별도의 격리된 단계에서 실행한다. - 기본적으로 Workflow 단계는 독립적으로 실행되므로 병렬 처리가 가능하다. - 배포 전에 모든 검사가 끝나야 한다면 `Promise.all()`로 여러 검사를 묶어 완료를 기다린다. ## 실용적인 결론 Cloudflare 기반 플랫폼을 운영하거나 고객별 코드를 관리한다면, CI SDK와 Workflows를 이용해 공통 파이프라인을 먼저 만들고 저장소별 예외만 동적으로 추가하는 방식이 적합하다. 설치 단계의 캐싱과 독립 검사의 병렬 실행을 적용하면 CI 지연 시간을 줄일 수 있으며, 배포는 모든 검증 단계가 성공한 뒤에만 실행하도록 구성하는 것이 안전하다.

원문 읽기(새 탭에서 열림)
CI/CDcloudflareTypeScriptwrangler+3
cloudflare4분 읽기큐레이션 요약

이제 에이전트가 로컬 트레이싱으로 Workers를 디버깅할 수 있습니다

`wrangler dev`와 `vite dev`가 로컬 Worker 실행 중 OpenTelemetry 트레이스를 자동 수집해, 코딩 에이전트가 배포 전 오류 원인을 직접 분석하고 수정 결과를 검증할 수 있게 되었습니다. 별도의 SDK 설치, 트레이싱 설정, 에이전트 구성 없이도 에이전트 세션이 감지되면 Local Explorer API가 자동으로 안내됩니다. 에이전트는 트레이스와 로그뿐 아니라 로컬 바인딩 및 데이터 상태까지 조회해 디버깅할 수 있습니다. ## 로컬 Worker 실행 시 자동 트레이싱 - `wrangler dev` 또는 `vite dev`로 실행한 Worker 호출이 자동으로 OpenTelemetry 트레이스로 기록됩니다. - 별도의 SDK나 애플리케이션 코드 수정, 관측성 활성화 설정이 필요하지 않습니다. - Wrangler와 Cloudflare Vite 플러그인은 Miniflare를 통해 Worker를 로컬에서 실행하므로, 실제 Worker 런타임에 내장된 계측 기능을 로컬에서도 사용할 수 있습니다. - 에이전트 세션이 감지되면 개발 서버가 Local Explorer API 주소와 트레이스 조회 엔드포인트를 출력합니다. ## 에이전트가 자동으로 발견하는 Local Explorer API - Local Explorer는 로컬 리소스 데이터와 관측성 데이터를 확인할 수 있는 브라우저 UI이자 REST API입니다. - API 루트에서 OpenAPI 스키마를 제공하므로, 에이전트가 사전에 하드코딩된 지침 없이 실행 중 사용 가능한 엔드포인트를 탐색할 수 있습니다. - 트레이스와 연결된 콘솔 로그는 다음과 같은 읽기 전용 엔드포인트로 조회할 수 있습니다. ```text POST /cdn-cgi/explorer/api/local/observability/query ``` - 에이전트는 트레이스 조회 후 KV, D1, R2, Durable Objects, Workflows 등 로컬 바인딩과 저장 상태도 함께 검사할 수 있습니다. - Local Explorer는 Cloudflare 대시보드가 아니라 Worker와 같은 localhost에서 실행됩니다. - Wrangler에서 `e` 키 입력 - 또는 `/cdn-cgi/explorer` 접속 ## 트레이스로 오류 원인 식별 및 검증 예를 들어 `POST /api/orders`가 다음 작업을 수행한다고 가정합니다. - KV에서 활성 장바구니 조회 - D1에 결제 정보 저장 - Queue에 주문 처리 메시지 전송 스키마 변경 이후 요청이 500 오류를 반환하면 다음과 같이 분석할 수 있습니다. - 트레이스가 없을 때 - 500 응답만으로는 KV, D1, Queue 중 어디서 실패했는지 알기 어렵습니다. - 에이전트가 각 작업 전후에 임시 로그를 추가하고 요청을 반복 실행해야 합니다. - 로그 확인과 코드 수정이 반복되어 시간과 토큰이 소모됩니다. - 트레이스가 있을 때 - KV 조회는 성공했고, D1 삽입 단계에서 `no such column: delivery_window` 오류가 발생했다는 사실을 확인합니다. - D1 작업이 실패했기 때문에 Queue 호출까지 도달하지 않았다는 흐름도 파악할 수 있습니다. - 에이전트가 로컬 D1 스키마를 검사해 저장소에 존재하지만 아직 적용되지 않은 마이그레이션을 발견합니다. - 마이그레이션을 적용한 뒤 요청을 다시 보내고, 새 트레이스에서 성공 여부를 검증합니다. 이 과정은 임시 로그를 추가하거나 배포하지 않고도 오류 위치 확인, 환경 수정, 재검증을 한 번의 로컬 디버깅 루프에서 수행하게 해줍니다. ## 자동으로 기록되는 트레이스 범위 Worker 런타임인 `workerd`에 계측 기능이 내장되어 있어 다음 작업이 자동 기록됩니다. - **Fetch 호출** - 외부 HTTP 요청의 실행 시간 - 상태 코드 - 요청 관련 메타데이터 - **바인딩 호출** - KV, R2, D1, Durable Objects, Queues 등 Cloudflare 바인딩과의 상호작용 - **핸들러 호출** - `fetch`, `scheduled`, Queue 핸들러 등 호출 전체 생명주기 - 애플리케이션이 직접 생성한 커스텀 span도 자동 트레이스에 포함됩니다. - Miniflare는 런타임 이벤트와 콘솔 출력을 수집해 OpenTelemetry 트레이스 및 연결된 로그로 구성합니다. - 수집된 데이터는 내부 SQLite 기반 Durable Object에 저장되고, Local Explorer API를 통해 제공됩니다. ## 사람이 확인하는 Local Explorer - 에이전트는 REST API로 데이터를 조회하지만, 개발자는 브라우저 UI에서 동일한 정보를 시각적으로 확인할 수 있습니다. - 특정 요청을 선택하면 다음 정보를 볼 수 있습니다. - 전체 span 구조 - 각 작업의 실행 시간 - 속성 및 메타데이터 - 오류 정보 - 관련 콘솔 로그 - 로컬 바인딩 상태를 탐색하면서 요청 처리 흐름과 데이터 상태를 함께 점검할 수 있습니다. ## 사용 방법 - Wrangler 기반 프로젝트: ```bash npm install --save-dev wrangler@latest ``` - Cloudflare Vite 플러그인 기반 프로젝트: ```bash npm install --save-dev @cloudflare/vite-plugin@latest ``` 업데이트 후 평소처럼 `wrangler dev` 또는 `vite dev`를 실행하고, 에이전트에게 로컬에서 오류를 재현하고 수정한 뒤 검증하도록 요청하면 됩니다. 로컬 트레이스를 활용하면 배포 전에 실패한 바인딩 호출과 환경 문제를 빠르게 찾아 수정할 수 있으므로, Cloudflare Worker 프로젝트의 에이전트 기반 디버깅에서는 최신 Wrangler 또는 Vite 플러그인 사용을 권장합니다.

원문 읽기(새 탭에서 열림)
옵저버빌리티Cloudflare Workersdurable-objectssqlite+4
cloudflare4분 읽기큐레이션 요약

소개: Cloudflare Agents

Cloudflare는 에이전트를 배포·관찰·개선할 수 있는 통합 관리 환경인 Cloudflare Agents를 공개했으며, 첫 기능으로 에이전트 트레이싱을 제공한다. 이 기능은 모델 호출, 도구 실행, 토큰 사용량, 승인 대기, 서브에이전트 작업과 Workers 인프라 동작을 하나의 추적으로 연결해 에이전트의 실제 동작과 비용을 파악하게 한다. 이를 통해 단순한 요청 성공 여부를 넘어 잘못된 도구 선택, 재시도 루프, 오래된 컨텍스트 전달 같은 문제를 분석하고 지속적으로 개선할 수 있다. ## 에이전트 관찰 가능성이 필요한 이유 - 에이전트는 HTTP 200을 반환하더라도 잘못된 도구를 선택하거나, 서브에이전트에 오래된 컨텍스트를 전달하거나, 토큰을 재시도 루프에서 낭비할 수 있다. - 기존 애플리케이션 텔레메트리는 API 요청이나 데이터베이스 쿼리는 보여주지만, 그 동작을 유발한 에이전트의 판단 과정은 보여주지 못한다. - 에이전트 수준의 텔레메트리는 다음 질문에 답해야 한다. - 지연 시간은 모델, 도구, 인프라 중 어디에서 발생했는가? - 승인 대기로 턴이 중단되었는가? - 어떤 모델을 호출했고 토큰을 얼마나 사용했는가? - 올바른 도구를 선택했는가? - 외부 API가 성공했는가, 타임아웃되었는가? - 어떤 서브에이전트가 작업했고 최종 응답에 어떤 영향을 주었는가? ## 에이전트 트레이싱의 범위 - 기존 Workers 트레이싱은 `fetch`, KV, D1 등 인프라 계층의 동작을 기록했다. - 새 에이전트 트레이싱은 여기에 다음과 같은 에이전트 전용 span을 추가한다. - 에이전트 호출 - 모델 호출 - 도구 실행 - 승인 이벤트 - 지원되는 서브에이전트 호출 - 모델명과 토큰 사용량 같은 정보도 메타데이터로 연결된다. - Think, Flue, AI SDK로 만든 에이전트는 Cloudflare 대시보드에서 추적을 확인하거나 OpenTelemetry 호환 대상에 내보낼 수 있다. ## 세션 리플레이로 판단 과정 확인 - Agents 대시보드의 Messages 탭에서는 특정 턴의 전체 대화를 재구성한다. - 시스템 지침 - 사용자 메시지 - 모델의 사고 과정 - 도구 호출 인자와 결과 - 최종 응답 - 이는 에이전트를 다시 실행하는 것이 아니라 기록된 데이터를 재생하는 기능이다. - 잘못된 도구 인자, 도구 선택 당시의 컨텍스트, 서브에이전트 핸드오프, 이전 턴이 이후 결과에 미친 영향을 분석할 수 있다. - Think, Flue, AI SDK에서는 `storeMessages`와 `storeTools` 설정으로 메시지 및 도구 payload 저장 여부를 제어한다. - 개인정보, 비밀값, 민감한 데이터가 포함될 수 있다면 payload 기록을 끄는 것이 권장된다. ## 실행 워터폴과 서브에이전트 추적 - Traces 탭은 각 턴의 실행 과정을 시간순 워터폴로 보여준다. - 부모 에이전트에서 서브에이전트, 모델, 도구, 데이터 저장소까지 하나의 흐름으로 연결된다. - 예시에서는 다음 작업을 한 화면에서 확인할 수 있다. - `TravelPlanner` 부모 에이전트 호출 - `itinerary_builder` 서브에이전트 호출 - `@cf/zai-org/glm-4.7-flash` 모델 호출과 토큰 사용량 - `record_itinerary_builder_execution` 도구 실행 - D1 쿼리 실행 - `record_respond_ready` 도구 실행 - KV 쓰기 - 부모 에이전트와 서브에이전트에는 에이전트 클래스, 대화, Durable Object 식별자가 연결되어 추적 간 상관관계를 파악할 수 있다. - KV, D1, Durable Object, 서비스 바인딩, `fetch` 등 Workers 리소스는 이를 호출한 에이전트 작업 아래에 중첩되어 표시된다. ## 트레이싱 활성화 방법 - 먼저 `wrangler.jsonc`에서 Workers 관찰 기능을 활성화한다. ```json { "observability": { "traces": { "enabled": true } } } ``` - 사용하는 에이전트 스택에 따라 추가 설정이 필요하다. - Think·Flue: 자체 트레이싱 통합 기능으로 에이전트, 대화, 턴, 모델, 도구 텔레메트리 전송 - AI SDK: Cloudflare의 `wrapAISDK()` 어댑터로 SDK 감싸기 - 사용자 정의 하네스: 커스텀 span API와 OpenTelemetry Generative AI 의미 규약 사용 ## OpenTelemetry 기반 확장과 외부 전송 - Cloudflare는 향후 Workers 내부에서 OpenTelemetry API를 직접 지원할 예정이다. - 표준 OpenTelemetry Generative AI span을 생성하는 프레임워크는 Cloudflare 전용 어댑터 없이 Agents 화면에서 시각화될 수 있다. - 표준 에이전트 및 대화 식별자가 포함되면 Cloudflare의 내장 통합처럼 에이전트와 세션 단위로 그룹화할 수 있다. - 추적 데이터는 Cloudflare에 종속되지 않으며, Wrangler 설정에서 OTLP 호환 제공자를 지정해 외부 관찰성 플랫폼으로 내보낼 수 있다. 에이전트 운영을 시작한다면 먼저 트레이싱을 활성화하고 메시지·도구 payload 저장 시 개인정보 노출 여부를 검토하는 것이 좋다. 이후 세션 리플레이로 판단 오류를 찾고, 워터폴 추적으로 모델·도구·인프라별 지연 시간과 비용을 분석하면 안정성과 효율을 체계적으로 개선할 수 있다.

원문 읽기(새 탭에서 열림)
Cloudflare Workersdurable-objectsopentelemetrywrangler+4
cloudflare4분 읽기큐레이션 요약

Astro의 GitHub 이슈를 0개로 만들기 위해 소프트웨어 팩토리를 구축한 방법

AI 에이전트를 소프트웨어 생산 파이프라인처럼 조합하면 오픈소스 이슈 triage를 상당 부분 자동화할 수 있다는 글이다. Astro는 GitHub Actions 안에서 격리된 에이전트들이 이슈 재현·원인 분석·수정·검증을 수행하도록 구성해 열린 이슈를 200개 이상에서 약 30개까지 줄였다. 이 경험은 특정 플랫폼에 종속되지 않는 에이전트 워크플로 프레임워크인 Flue와 재사용 가능한 GitHub Action으로 발전했다. ## 오픈소스 유지보수와 이슈 폭증 - AI 때문에 이슈, pull request, 보안 보고서를 생성하는 비용은 크게 낮아졌다. - 반면 유지보수자가 각 보고서를 읽고 재현하고 검토하는 비용은 증가했다. - 기존의 수동 triage 방식만으로는 늘어나는 입력량을 감당하기 어려워졌다. - Astro 팀은 이슈를 자동으로 닫거나 “issue bankruptcy”를 선언하지 않고, 실제 문제를 해결하는 방향을 택했다. ## 에이전트 스킬로 시작한 자동화 - 첫 자동화 대상은 개발 과정 중 시간이 많이 들고 보상이 적은 이슈 triage였다. - 유지보수자는 로컬 코딩 하네스에서 에이전트 스킬을 개발·테스트한 뒤, 동일한 워크플로를 GitHub Actions에서 실행했다. - 수동 이슈 처리 절차를 다음 단계로 분리했다. - **재현:** 제보자가 제공한 재현용 저장소를 복제하고 문제 발생 여부 확인 - **진단:** 코드에 로깅과 계측을 추가해 근본 원인 파악 - **검증:** 테스트, 주석, 문서를 검토해 실제 버그인지 의도된 동작인지 판단 - **수정:** 재현 사례를 실패하는 단위 테스트로 변환하고 적절한 수정안을 구현 - 각 단계는 서로 격리된 서브에이전트가 담당한다. - 에이전트 간 정보는 `report.md`에 기록해 순차적으로 전달한다. - 단계별 격리는 LLM이 실제 버그가 아닌데도 해결책을 억지로 만들려는 편향을 줄인다. ## GitHub 이슈 라벨 기반 상태 머신 - 자동화 파이프라인은 사실상 이슈 라벨로 구동되는 상태 머신이다. - 새 이슈에는 `triage needed` 라벨이 붙고, 사용자가 수정 사항을 확인하면 `fix verified`로 이동한다. - 별도의 복잡한 내부 상태 저장소 없이, 이슈의 라벨과 기존 댓글을 읽어 현재 상태와 다음 작업을 판단한다. - 수정이 완료되면 다음 작업을 자동 수행한다. - `pkg.pr.new`를 이용해 프리뷰 릴리스 생성 - 분석 결과와 전체 로그를 이슈에 게시 - 제보자가 자신의 프로젝트에서 프리뷰 패치를 설치하도록 안내 - 제보자가 수정 사항을 확인하면 관련 pull request 생성 ## Flue로의 일반화 - 초기에는 GitHub 이슈에 맞춘 시스템처럼 보였지만, 핵심 구조는 플랫폼과 무관한 워크플로였다. - 이벤트를 받고, 격리된 서브에이전트를 순차 실행하며, 추론과 실제 실행 권한을 분리하는 방식은 Slack, cron, webhook 등에도 적용할 수 있다. - 이 구조를 특정 플랫폼이나 모델에 종속되지 않는 런타임으로 확장한 결과가 오픈 프레임워크 **Flue**다. - Flue는 지속적으로 실행 가능한 에이전트와 워크플로를 구축하기 위한 프레임워크를 지향한다. ## 자동화가 커뮤니티에 미친 영향 - 팀은 자동화된 봇 응답이 유지보수자와 사용자 사이를 더 멀어지게 만들 수 있다고 우려했다. - 실제로는 반복적인 이슈 처리에 쓰는 시간이 줄면서 더 가치 있는 커뮤니티 활동에 참여할 수 있었다. - Discord에서 사용자와 직접 소통 - RFC 논의와 신규 기능 요청 검토 - 기여자와 협업해 아이디어를 프레임워크에 통합 - 자동화가 사람과의 소통을 없앤 것이 아니라, 소통의 초점을 더 유용한 논의로 옮겼다는 설명이다. ## 에이전트 실패를 코드베이스 개선 신호로 활용 - 에이전트가 문제를 해결하지 못하면 단순히 모델의 실패로 보지 않고 코드베이스의 결함을 점검한다. - 주요 원인은 다음 세 가지다. - **불투명한 추상화:** 컴포넌트 간 경계가 불명확함 - **부족한 문서화:** 구현 이유와 핵심 로직을 설명하는 주석이 없음 - **불충분한 테스트:** 특히 특정 조건과 회귀 사례를 검증하는 단위 테스트 부족 - HMR 버그 사례에서 에이전트는 특정 `if` 조건을 반복 수정했지만, 다른 곳에 회귀를 일으켰다. - 해당 조건의 의미를 설명하는 주석과 테스트를 추가하자 에이전트는 올바른 설계 의도를 이해하고 잘못된 수정을 반복하지 않게 됐다. - 따라서 에이전트 자동화는 코드 구조, 문서, 테스트 품질을 개선하는 피드백 루프로도 작동한다. ## 독립적인 GitHub Action으로 분리 - 초기 triage 로직은 Astro 모노레포 내부에 직접 들어 있어 변경과 Flue 업그레이드가 어려웠다. - 팀은 이를 `triagebot-action`이라는 독립 저장소로 분리했다. - 분리 후 다음이 가능해졌다. - 자동화 로직의 독립적인 테스트 - 기존 코드베이스에 영향을 주지 않는 안정성 검증 - 여러 프로젝트에서 재사용 - 다른 팀이 그대로 사용하거나 포크해 자체 자동화 공장을 구축 - Astro에서 시작한 이 Action은 다른 팀으로도 확산되고 있다. 실용적으로는 처음부터 모든 개발 과정을 자동화하기보다, 재현·진단·검증처럼 절차가 명확한 좁은 영역부터 시작하는 것이 적절하다. 또한 에이전트의 실패를 숨기기보다 테스트, 문서, 추상화 경계를 개선하는 신호로 활용해야 자동화 품질과 사람 개발자의 생산성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)
AI 에이전트오픈 소스GitHub Actionsastro+4
cloudflare3분 읽기큐레이션 요약

Cloudflare Wallets 출시: 에이전트 기반 인터넷을 위한 프로그래밍 가능한 지갑

AI 에이전트는 현재 인간용 로그인, 결제수단 등록, API 키 발급 절차 때문에 새로운 API를 탐색하고 비교하기 어렵다. Cloudflare Wallets는 계정 지갑과 에이전트용 가상 지갑을 제공해, 에이전트가 x402 기반 스테이블코인 소액결제로 API·콘텐츠·MCP 도구를 직접 구매하도록 한다. 예산 한도와 허용 목록 같은 통제 장치를 통해 자율적인 탐색과 안전한 지출을 동시에实现하는 것이 핵심이다. ## 에이전트 온보딩의 문제 - 에이전트는 서비스 가입에 사용할 안정적인 식별자가 없다. - 인간 중심의 로그인·결제·API 키 발급 과정을 스스로 처리하기 어렵다. - 결제수단 등록이나 가입 승인을 인간에게 요청해야 하므로, 여러 API를 빠르게 시험하고 비교하기 어렵다. - 이러한 마찰은 에이전트가 서비스를 구매·활용하는 에이전틱 커머스의 성장을 제한한다. ## Cloudflare Wallets와 x402 결제 - 사용자는 Cloudflare 계정에 연결된 고유한 Wallet 핸들을 만들 수 있다. - 지갑에는 스테이블코인을 보관하고 웹 전반의 서비스 구매 및 자금 수령에 사용할 수 있다. - Cloudflare의 Monetization Gateway는 웹사이트와 애플리케이션이 x402 프로토콜 기반 소액결제를 받을 수 있도록 한다. - x402는 HTTP 요청에 결제를 연결해 API 호출, AI 추론, 데이터, 콘텐츠 사용량 등에 따라 자동 결제할 수 있게 한다. - x402 호환 서비스를 구매하거나 판매하려면 지갑이 필요하다. ## 계정 지갑과 가상 지갑 - **Account Wallet** - 사람이 소유하고 관리하는 기본 지갑이다. - 자금을 충전하고, 에이전트에게 지출 권한을 위임한다. - 필요할 때 자금을 회수하거나 지출 정책을 변경할 수 있다. - **Virtual Wallet** - 에이전트 전용 지갑으로 API 키를 통해 작동한다. - 에이전트는 허용된 범위 안에서 API, MCP 도구, 콘텐츠 등을 구매할 수 있다. - 지출 한도는 Account Wallet 소유자가 설정한 상한을 넘을 수 없다. - 인간의 매번 승인을 요구하지 않으면서도 과도한 지출을 방지한다. ## 제한된 예산이 제공하는 자율성 - 에이전트는 적은 비용으로 수십~수백 개의 서비스를 직접 시험하고 용도에 맞는 API를 선택할 수 있다. - 예를 들어 API 호출 비용이 몇 센트라면, 10달러의 예산만으로도 다양한 후보를 충분히 평가할 수 있다. - Virtual Wallet에 다음과 같은 정책을 설정할 수 있다. - 총 허용량 - 서비스 허용 목록 - 거래당 최대 금액 - 주간 또는 사용자별 예산 - 예산 초과 시 승인된 관리자가 수동으로 한도를 늘리거나 일회성 자금을 추가할 수 있다. - 비정상적으로 빠른 지출이 발생하면 관리자가 검토할 수 있으며, 의도된 지출이면 승인하고 그렇지 않으면 정책의 제한으로 손실을 줄인다. - 초기에는 지원 지역에서 법정화폐 기반 입출금을 제공하고, 일부 사용자는 스테이블코인으로 직접 자금을 충전할 수 있다. ## 에이전트 정체성과 귀속 - 결제 권한을 위임해도 상점은 해당 에이전트가 어떤 개인이나 조직을 대신하는지 알기 어려울 수 있다. - 이 때문에 무료 체험, 가입 크레딧, 조직별 혜택을 에이전트에게 적용하기 어렵다. - Cloudflare는 지갑을 Cloudflare 계정과 연결하고 `cloudflare.pay` 식별자를 제공하려 한다. - 예를 들어 `research.example.cloudflare.pay`처럼 특정 조직에 속한 연구 에이전트임을 나타낼 수 있다. - 식별자 공개는 선택 사항이며, 상점은 알려진 에이전트와의 거래를 우선할지 결정할 수 있다. ## 사람이 읽을 수 있는 에이전트 식별자 - 식별되지 않은 에이전트가 본질적으로 신뢰할 수 없는 것은 아니지만, 추가적인 검증이 필요할 수 있다. - Cloudflare의 Web Bot Auth는 키 쌍을 이용해 에이전트 정체성을 등록하는 기반을 제공한다. - Cloudflare Wallet 식별자는 사람이 읽기 어려운 키 쌍에 기억하기 쉬운 이름을 연결하는 역할을 한다. - 이는 DNS가 사람이 읽는 도메인 이름과 기계적인 IP 주소를 연결하는 방식과 유사하다. - 빠르게 변하는 에이전트 신원 표준에 대응하기 위해, Cloudflare는 복잡한 스키마나 검증 체계를 새로 정의하기보다 단순하고 기억하기 쉬운 식별자 제공에 초점을 둔다. 에이전트가 다양한 서비스를 자율적으로 탐색하게 하려면 결제와 신원 확인이 기계 친화적으로 바뀌어야 한다. 따라서 서비스 제공자는 x402와 Monetization Gateway를 활용하고, 사용자는 Virtual Wallet에 명확한 예산·허용 목록·거래 한도를 설정하는 방식이 현실적인 도입 전략이다.

원문 읽기(새 탭에서 열림)
AI 에이전트agentic-commercestablecoinsx402+4
cloudflare4분 읽기큐레이션 요약

Cloudflare가 AI를 활용해 엔지니어링 표준을 시행하는 방법

Cloudflare는 흩어져 있던 엔지니어링 지침을 통합·관리하는 표준 저장소인 **Cloudflare Codex**를 구축했다. Codex는 RFC 형식의 표준을 사람과 AI 에이전트가 작업 시점에 검색하고 적용할 수 있게 하며, 코드 리뷰·기술 설계 검토·사고 보고서 검토 등에 공통으로 활용된다. 도입 후 AI 코드 리뷰어는 약 23만 건의 위반을 발견했고, 그중 약 1만 6천 건의 병합을 차단했다. ## Codex가 필요했던 이유 - Cloudflare의 기존 지침은 공식 문서, 저장소 파일, 채팅 기록, 개인의 경험 등 여러 위치에 분산돼 있었다. - 개발자는 문제 해결보다 관련 지침을 찾는 데 많은 시간을 써야 했다. - 지침을 찾더라도 최신 정보인지, 권위 있는 기준인지, 현재 상황에 적용 가능한지 판단하기 어려웠다. - 조직이 커지면서 모든 표준을 읽고 모든 요구사항을 검토하는 것이 불가능해졌다. - 팀 이동이나 인력 변화로 조직의 지식이 유실되기 쉬웠고, 지침이 일관되게 노출·강제되지 않아 프로젝트 간 품질 편차가 발생했다. ## 도메인과 RFC 기반 거버넌스 - Codex는 아키텍처, 프런트엔드, 컨트롤 플레인, 보안, 신뢰성, TypeScript, Rust 등 여러 도메인으로 나뉜다. - 각 도메인에는 담당자가 있어 문서의 내용·일관성·품질을 관리한다. - 표준은 RFC 2119의 의미에 따라 `SHOULD`와 `MUST` 키워드를 사용한다. - `SHOULD`: 특별한 이유가 없다면 따라야 하는 권고 - `MUST`: 반드시 지켜야 하는 필수 요구사항 - RFC에는 도메인과 상태 같은 메타데이터를 담은 front matter가 포함된다. - 도메인 역량과 관심이 있는 직원은 정해진 형식의 merge request로 RFC를 제안할 수 있다. - 제안서는 점점 더 넓은 범위의 리뷰를 거치며, 도메인 담당자가 최종 승인하면 Codex에 편입되고 Astro 기반 내부 사이트에 게시된다. ## 승인과 강제를 분리한 표준 수명주기 - 승인된 RFC는 Codex 클라이언트와 에이전트가 즉시 읽고 코드·설정·문서의 위반을 탐지하는 데 사용할 수 있다. - 다만 승인 직후부터 병합을 차단하지는 않는다. - RFC가 `approved`에서 `enforced` 상태로 승격된 뒤에야 관련 요구사항이 차단 근거가 된다. - 이 단계 분리를 통해 팀이 새로운 요구사항을 받아들일 시간을 확보하고, 자동화나 예외 처리 등 강제에 필요한 준비도 마칠 수 있다. - 승인된 RFC의 위반은 일반적으로 비차단 권고로 처리되며, 강제 상태 RFC의 `MUST` 위반은 심각도에 따라 승인 보류 또는 병합 차단으로 이어진다. ## LLM을 위한 구조화와 점진적 공개 - 60개가 넘는 RFC 전체를 매번 LLM에 제공하면 컨텍스트 윈도우 부담이 커지고 결과 품질이 떨어질 수 있다. - 이를 해결하기 위해 별도의 에이전트가 RFC에서 `SHOULD`와 `MUST` 문장을 추출해 JSON 구조로 압축한다. - 각 표준 문장에는 다음 정보가 포함된다. - RFC 번호와 제목 - RFC 상태와 도메인 - 적용 수준(`SHOULD` 또는 `MUST`) - 문장이 속한 섹션 - 원문으로 연결되는 링크 - 안정적인 `slug` 식별자 - 에이전트는 우선 관련 표준 문장만 검색하고, 추가 설명이 필요할 때만 RFC 전체 내용을 불러온다. - 안정적인 slug는 RFC가 수정돼도 같은 요구사항을 추적할 수 있게 해 모니터링, 분석, 예외 처리에 활용된다. - 초기에는 간결한 Markdown을 사용했지만, 더 정확한 필터링을 위해 구조화된 JSON으로 전환했다. - 향후에는 설계·구현·런타임 등 소프트웨어 개발 생명주기 단계별 적용 범위도 메타데이터에 포함할 계획이다. ## AI 코드 리뷰 적용 - AI 코드 리뷰어는 merge request를 여러 기준으로 검사하며 Codex 준수 여부도 평가한다. - 리뷰마다 관련 RFC와 추출된 표준 문장을 검색하고, 필요한 경우에만 RFC 본문을 추가로 읽는다. - 대부분의 위반은 압축된 표준 문장만으로도 문제와 근거를 설명할 수 있다. - Codex 도입 이후 약 23만 건의 위반을 발견했다. - 이 중 약 1만 6천 건은 강제 상태 RFC의 `MUST` 요구사항 위반으로 승인 보류를 발생시켰다. ## AI 리뷰를 보완하는 빠른 린터 - AI 리뷰는 코디네이터와 여러 하위 에이전트를 실행하므로 보통 수 분이 걸린다. - 수정 후 다시 리뷰를 받아야 하는 추가 왕복과 대기 시간이 개발자 경험을 저하시킬 수 있다. - Cloudflare는 기계적으로 검증 가능한 언어별 요구사항을 별도 린터 설정 패키지로 제공하는 방식을 마련했다. - 이 린터는 Codex 표준과 정렬되며 문제를 밀리초 단위로 표시할 수 있다. - TypeScript가 첫 번째 대상 언어였고, 동시에 `oxlint`를 표준화하는 방향으로 진행됐다. ## 여러 엔지니어링 단계로의 확장 - Codex는 코드 리뷰에만 한정되지 않는다. - 기술 설계가 구현되기 전에 표준을 검토하는 spec reviewer가 이미 약 600개의 설계를 평가했다. - incident report reviewer 등 사고 분석과 운영 프로세스에도 같은 기준을 적용할 수 있다. - 하나의 관리된 표준 원천을 여러 에이전트가 공유함으로써 설계부터 구현, 운영까지 일관된 엔지니어링 기준을 적용할 수 있다. 새로운 표준은 먼저 `approved` 상태로 도입해 팀의 적응과 자동화 준비 시간을 확보한 뒤, 충분히 검증되면 `enforced`로 승격하는 방식이 실용적이다. 또한 LLM에는 전체 문서를 무작정 제공하기보다, 안정적인 식별자와 메타데이터를 갖춘 핵심 규칙을 먼저 검색하게 하고 필요할 때만 원문을 공개하는 구조가 효과적이다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델TypeScriptRustastro+4
discord3분 읽기큐레이션 요약

스퀴클, 스타일, 간격: 여러분의 피드백이 모바일 환경 개선에 어떻게 도움이 되고 있는가

Discord는 데스크톱과 모바일의 디자인 경험을 통일하기 위해 모바일 앱의 테마, 형태, 간격과 채팅 입력창을 개선했습니다. 데스크톱의 네 가지 기본 테마를 모바일에 도입하고, 사람은 원형·사물은 스퀘어클이라는 형태 규칙을 적용했습니다. 또한 채팅 바를 정리해 메시지 작성 공간을 넓히고, 자주 쓰는 기능에 더 쉽게 접근할 수 있도록 조정했습니다. ## 데스크톱과 모바일의 테마 통일 - 모바일에서도 데스크톱의 네 가지 기본 테마를 사용할 수 있습니다. - Light - Ash - Dark - Onyx - **Ash**는 기존 Discord의 클래식 다크 테마를 계승하면서 현대적인 접근성 기준에 맞게 대비를 개선했습니다. - **Onyx**는 단순히 어두운 회색이 아니라 완전한 검정색 배경을 사용하는 AMOLED 테마입니다. - OLED 화면에서 검정색 픽셀을 끌 수 있어 배터리 절약에 도움이 될 수 있습니다. - 모바일과 데스크톱에서 동일한 테마로 제공됩니다. - 접근성 설정에서 화면의 대비와 채도를 세부적으로 조절할 수 있습니다. ## 기기 설정에 맞춘 테마 자동 전환 - 사용자가 지정한 Light 테마와 Dark 테마를 기기의 시스템 모드에 맞춰 자동으로 전환할 수 있습니다. - Appearance 설정에서 **“Same as Device Theme”**를 활성화하면 됩니다. - 이 설정은 **Sync Across Devices**보다 우선 적용됩니다. - 모바일뿐 아니라 데스크톱에서도 지원됩니다. - Nitro 사용자는 프로필 테마의 색상에 맞춰 음성·영상 통화 타일의 배경도 변경할 수 있습니다. ## 사람은 원형, 사물은 스퀘어클 - 모바일과 데스크톱 전반에 일관된 형태 규칙이 적용됩니다. - 사용자, 친구, DM의 봇: 원형 - 서버, 앱 등 사물: 모서리가 둥근 사각형인 스퀘어클 - 서버 목록의 아이콘이 스퀘어클 형태로 바뀌어 사람과 서버를 빠르게 구분할 수 있습니다. - 버튼, 입력창, 컨테이너 등 다른 UI 요소의 둥근 모서리도 같은 기준에 맞춰 정리했습니다. - 개인 DM과 그룹 DM은 ‘친구 관계’를 나타내기 때문에 기존처럼 원형을 유지합니다. ## 메시지 입력창과 빠른 작업 메뉴 개편 - 채팅 바가 지나치게 복잡해진 문제를 해결하기 위해 메시지 작성 공간을 넓혔습니다. - 채팅 바 오른쪽에는 다음 기능이 계속 유지됩니다. - 이모지 - 선물 - 음성 메시지 - 자주 사용하는 빠른 작업 - 다음 기능은 **+ 메뉴** 안으로 이동했습니다. - 스레드 - 앱 사용 - **+ 버튼을 길게 누르면** 전체 메뉴를 열지 않고 원하는 작업으로 바로 이동할 수 있습니다. - 스레드나 앱을 자주 사용하는 사용자는 이전보다 한 단계 더 거쳐야 하지만, 길게 누르기 단축 동작으로 기존 접근 속도에 가깝게 사용할 수 있도록 했습니다. ## 플랫폼 간 일관성을 높인 모바일 업데이트 - 이번 업데이트의 목표는 모바일과 데스크톱을 서로 다른 앱처럼 느끼지 않도록 만드는 것입니다. - 동일한 테마 체계, 형태 규칙, UI 간격을 적용해 플랫폼을 바꿔도 익숙한 사용 경험을 제공하려 했습니다. - 변경 사항은 사용자 피드백을 바탕으로 모바일의 시각적 일관성과 사용성을 함께 개선하는 데 초점을 맞췄습니다. 모바일에서 클래식한 분위기를 원한다면 **Ash**, 배터리 효율과 완전한 검정 배경을 원한다면 **Onyx**를 선택하는 것이 적합합니다. 스레드나 앱을 자주 사용한다면 + 버튼 길게 누르기 동작을 익혀 새 채팅 바에 적응하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
디자인 시스템discord접근성dark-mode+3
meta5분 읽기큐레이션 요약

GEM 트레이닝: Meta가 LLM 규모의 광고 파운데이션 모델 효율성을 두 배로 높인 방법

Meta의 GEM은 Instagram과 Facebook 광고 추천을 담당하는 기반 모델로, 최신 GPU 수천 장을 활용해 LLM 규모로 학습된다. Meta는 추천 시스템에 특화된 커널·초저정밀도·병렬화·네트워크·메모리를 함께 설계해 12개월 동안 학습 FLOPs를 4배 늘리면서 E2E 학습 효율을 20~25% MFU까지, 기존 대비 2배 향상했다. 핵심 결론은 LLM용 인프라를 그대로 적용하는 것만으로는 부족하며, 추천 모델의 데이터와 구조에 맞춘 하드웨어·소프트웨어 공동 설계가 필요하다는 것이다. ## GEM의 하이브리드 구조와 추천 데이터의 특성 - GEM은 Meta 광고 시스템의 중앙 추천 파운데이션 모델이다. - 수조 개의 희소 임베딩 파라미터와 수십억 개의 밀집 파라미터를 함께 사용한다. - 입력 데이터는 크게 두 종류다. - **시퀀스 특징**: 사용자의 활동 이력처럼 순서가 있는 데이터 - **비시퀀스 특징**: 사용자 위치, 광고 크리에이티브 표현 등 - 각 특징 그룹에는 별도의 어텐션 메커니즘을 적용하면서도, 서로 다른 특징 간 상호작용을 학습한다. - 이처럼 LLM과 추천 시스템의 구조가 결합되어 있어 일반적인 LLM 학습보다 GPU 활용과 분산 확장이 어렵다. ## 추천 모델에서 높은 GPU 활용률이 어려운 이유 - **가변적인 시퀀스 길이** - 사용자 활동 이력의 길이가 샘플마다 크게 다르다. - 모든 입력을 최대 길이에 맞춰 패딩하면 최대 50%의 연산이 낭비될 수 있다. - **비대칭적인 어텐션 형태** - 긴 활동 이력에 대해 긴 시퀀스와 짧은 어텐션 윈도우를 사용하는 self-attention - 긴 쿼리와 짧은 key/value를 사용하는 사용자-광고 cross-attention - 사용자 이력을 압축해 짧은 쿼리와 긴 key/value를 만드는 PMA - 이런 다양한 행렬 형태는 GPU 내부 파이프라이닝과 연산 유닛 포화를 어렵게 만든다. - **메모리 대역폭 중심 연산** - 작은 임베딩 차원의 MLP와 여러 정규화 연산은 계산량보다 메모리 접근의 영향을 크게 받는다. - 따라서 Tensor Core 등 GPU 연산 자원이 충분히 활용되지 않을 수 있다. - **정밀도 변화에 대한 민감성** - CTR·CVR 예측은 수치 변화에 민감하다. - 단순히 낮은 정밀도를 적용하면 모델 품질이 저하될 수 있어, 연산별로 정밀도를 신중하게 선택해야 한다. ## 수천 개 GPU로 확장할 때의 병목 - GEM의 학습 단계 지연 시간은 다음과 같이 결정된다. `E2E 지연 시간 = 각 GPU rank에서의 max(로컬 연산 시간, 통신 시간)` - 선형에 가까운 확장을 위해서는 다음 조건이 필요하다. - 전체 연산 시간이 통신 시간보다 충분히 커야 한다. - 통신을 연산 뒤에 숨기되 두 작업이 자원을 놓고 경쟁하지 않아야 한다. - 메모리 부족으로 인한 activation recomputation을 최소화해야 한다. - GPU rank 간 부하가 균등해야 한다. - GEM에서는 다음 문제가 이를 방해한다. - 수조 개 희소 파라미터와 수십억 개 밀집 파라미터가 큰 통신량을 만든다. - 레이어별 구조가 달라 연산과 통신을 겹칠 수 있는 시간이 일정하지 않다. - 긴 시퀀스와 큰 activation 때문에 메모리가 부족해 재계산이 발생한다. - 가변 시퀀스 길이로 인해 GPU마다 처리량이 달라지는 부하 불균형과 straggler가 생긴다. ## E2E MFU를 연산 효율과 확장 효율로 분해 - 전체 학습 효율은 다음 두 요소의 곱으로 정의한다. `E2E MFU = Local MFU × Scaling Ratio` - **Local MFU** - 단일 GPU의 연산 유닛을 얼마나 잘 활용하는지를 나타낸다. - 커널 설계, 수치 정밀도, 시퀀스 길이와 데이터 차원이 GPU 구조에 얼마나 잘 맞는지에 좌우된다. - **Scaling Ratio** - 단일 GPU 성능이 수천 개 GPU로 확장된 뒤 얼마나 유지되는지를 의미한다. - 1.0이면 완전한 선형 확장이지만, 실제로는 통신 오버헤드·부하 불균형·straggler·activation 재계산 때문에 낮아진다. - Meta는 레이어를 단일 GPU에서 개별 실행해 Local MFU를 측정하고, 통신과 activation 재계산의 영향을 제외한 기준 성능을 산출했다. - 이후 Local MFU와 E2E MFU의 비율을 통해 Scaling Ratio를 계산해 연산 병목과 분산 시스템 병목을 분리했다. ## GPU 연산 효율을 높인 맞춤형 커널과 정밀도 - 추천 모델의 비정형적인 입력과 어텐션 패턴에 맞춰 자체 추천용 커널 라이브러리를 개발했다. - 주요 커널은 다음과 같다. - **Jagged Flash Attention(JFA)**: 가변 길이 시퀀스를 패딩 낭비 없이 처리 - **Generalized Dot-Product Attention(GDPA)**: 추천 모델의 다양한 어텐션 형태에 대응 - **BlockAttention**: 블록 단위 연산으로 메모리 접근과 GPU 활용을 최적화 - 최신 GPU 아키텍처를 직접 활용하도록 커널을 설계해 추천 워크로드의 낮은 활용률을 개선했다. - 어텐션과 MLP에는 **MXFP8**을 포함한 혼합 초저정밀도 학습을 적용했다. - 모든 연산을 무조건 낮은 정밀도로 처리하지 않고, 광고 예측 품질에 민감한 특성을 고려해 연산별로 정밀도와 안정성을 조정했다. ## 네트워크와 결합한 5차원 병렬화 - 대규모 학습에서는 병렬화 방식 자체뿐 아니라 GPU와 네트워크 토폴로지의 매핑이 중요하다. - GEM은 네트워크 계층 구조를 고려한 **토폴로지 인지형 5D 병렬화**를 적용했다. - 밀집 파라미터에는 다음 조합을 사용했다. - 2D FSDP - Expert Parallelism - 희소 파라미터에는 **Fully Sharded 2D Model Parallelism**을 적용했다. - 통신 집단 연산은 GPU의 Streaming Multiprocessor(SM)를 점유하지 않는 방식으로 설계했다. - 통신이 연산 자원을 직접 빼앗지 않도록 해 연산과 통신의 충돌을 줄인다. - Meta의 다계층 네트워크 구조와 병렬화 전략을 함께 설계해 통신량과 통신 노출 시간을 줄였다. ## 성과와 설계 원칙 - 12개월 동안 총 학습 FLOPs를 4배로 확대했다. - 동시에 E2E 학습 효율을 2배 높여 20~25% MFU를 달성했다. - 성능 개선은 단일 기법이 아니라 다음 요소들의 결합으로 이루어졌다. - 추천 특화 커널 - 혼합 초저정밀도 - 희소·밀집 파라미터별 병렬화 - 네트워크 토폴로지 최적화 - SM 비점유 통신 - 메모리와 부하 균형 관리 추천 모델을 LLM 규모로 확장하려면 LLM 인프라를 그대로 복사하기보다, 가변 길이·희소 임베딩·비대칭 어텐션·정밀도 민감성 같은 도메인 특성을 먼저 분석해야 한다. 특히 단일 GPU의 커널 효율과 수천 GPU의 통신·메모리 효율을 별도의 문제로 측정하고 동시에 최적화하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델recommendation-systemsdistributed-traininggpu-optimization+3
aws3분 읽기큐레이션 요약

AWS 주간 요약: Bedrock의 GPT 모델 가격 인하, Prometheus 지표를 위한 CloudWatch 관리형 수집기 및 기타 소식 (2026년 8월 3일) | Amazon Web Services

AWS의 이번 주 업데이트는 AI 비용 절감, 관측성 관리 간소화, 멀티클라우드 연결성 강화, 데이터 레이크 기능 확장에 초점을 맞춘다. Amazon Bedrock의 GPT-5.6 모델 가격이 최대 80% 인하됐고, CloudWatch는 관리형 Prometheus 수집기를 제공해 별도 에이전트 운영 부담을 줄인다. 또한 Oracle Cloud와의 전용 연결, IAM Identity Center의 멀티 리전 복제, Apache Iceberg V3의 Variant 데이터 타입 지원도 정식 또는 신규 기능으로 소개됐다. ### Amazon Bedrock GPT-5.6 가격 인하 - 2026년 7월 30일부터 OpenAI GPT-5.6 모델의 온디맨드 추론 가격이 자동으로 인하됐다. - GPT-5.6 Luna: - 입력 토큰 100만 개당 **0.20달러** - 출력 토큰 100만 개당 **1.20달러** - 기존 대비 최대 **80% 인하** - GPT-5.6 Terra는 가격이 **20% 인하**됐다. - 사용자가 별도 설정을 변경하거나 신청할 필요 없이 자동 적용된다. ### CloudWatch 관리형 Prometheus 수집기 - Amazon CloudWatch가 AWS 인프라에서 Prometheus 메트릭을 수집하는 완전 관리형 수집기를 지원한다. - 다음 서비스의 워크로드를 별도 에이전트 관리 없이 모니터링할 수 있다. - Amazon EKS - Amazon EC2 - Amazon ECS - Amazon MSK - Amazon OpenSearch Service - 직접 Prometheus 스크레이핑 인프라를 배포하고 유지하던 조직은 운영 및 업그레이드 부담을 줄일 수 있다. ### AWS와 Oracle Cloud 간 멀티클라우드 연결 - AWS Interconnect와 Oracle Cloud Infrastructure(OCI) 간 연결 기능이 정식 출시됐다. - 퍼블릭 인터넷을 거치지 않고 AWS와 OCI 사이에 전용 프라이빗 연결을 구성할 수 있다. - 멀티클라우드 환경에서 다음 요구사항을 충족하는 데 유리하다. - 네트워크 보안 강화 - 안정적이고 확장 가능한 연결 - 클라우드 간 애플리케이션 연동 - 지연 시간과 네트워크 성능 관리 ### IAM Identity Center 멀티 리전 지원 확대 - IAM Identity Center 디렉터리를 기본 자격 증명 소스로 사용하는 경우에도 멀티 리전 복제가 가능해졌다. - 기본 리전에 장애가 발생하면 추가 리전에 복제된 디렉터리와 권한 정보를 활용해 사용자가 AWS 계정에 계속 접근할 수 있다. - 기존에는 외부 자격 증명 공급자와 연결된 인스턴스에만 제공되던 기능이었다. - 리전 장애에 대비한 인증 가용성과 재해 복구 설계를 강화할 수 있다. ### Apache Iceberg V3의 Variant 데이터 타입 지원 - Amazon S3 Tables가 Apache Iceberg V3에서 도입된 **Variant** 데이터 타입을 지원한다. - Variant는 고정된 스키마를 적용하기 어려운 반정형 데이터를 JSON 블롭보다 효율적으로 저장하고 처리할 수 있도록 설계됐다. - 적용 사례: - IoT 센서 데이터 - 애플리케이션 로그 - 스키마가 자주 바뀌는 이벤트 페이로드 - 데이터 레이크에서 스키마 유연성을 확보하면서도 네이티브 처리 성능을 활용할 수 있다. ### 추가로 소개된 AWS 소식 - AWS CLI를 여러 플랫폼에서 한 줄 명령으로 설치하고 업데이트하는 방법이 공개됐다. - Moonshot AI의 Kimi K3를 SageMaker HyperPod와 Amazon EKS에 배포하는 단계별 가이드가 제공됐다. - Amazon MSK Express 브로커에서 Apache Iceberg 및 Amazon S3 Tables로 Kafka 데이터를 스트리밍하는 방법이 소개됐다. - 해당 데이터 전달 방식은 최대 **초당 10GB** 처리량을 지원한다. ### 예정된 AWS 행사 - AWS Summits가 2026년 하반기에도 개최되며, 클라우드와 AI 관련 기술 세션 및 커뮤니티 교류 기회를 제공한다. - AWS Community Days는 커뮤니티 리더가 콘텐츠를 기획하고 운영하는 지역 행사다. - AWS Builder Center에서는 개발자용 콘텐츠, 솔루션 공유, 온·오프라인 행사 정보를 확인할 수 있다. 실무적으로는 Bedrock 사용 조직이라면 모델 비용 절감 효과를 즉시 검토하고, Prometheus 운영 부담이 큰 팀은 CloudWatch 관리형 수집기로의 전환을 고려할 만하다. 멀티클라우드나 리전 장애 대응이 중요한 환경에서는 AWS Interconnect와 IAM Identity Center 멀티 리전 기능을 재해 복구 설계에 반영하는 것이 유용하다.

원문 읽기(새 탭에서 열림)
amazon-bedrockApache Kafkaapache-icebergamazon-cloudwatch+4
kakao1분 읽기큐레이션 요약

말을 잘하는 AI를 넘어: 사용자가 원하는 방식으로 말하는 Kanana-o 만들기

제공된 내용에는 본문이 포함되어 있지 않고, 제목·작성자 정보·페이지 내비게이션만 있습니다. 따라서 Kanana-o 음성 생성 고도화 과정의 핵심 주장이나 기술적 세부 사항을 정확히 요약할 수 없습니다. ### 확인 가능한 정보 - 글 제목: **Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want** - 관련 한국어 제목: **잘 말하는 AI를 넘어, 원하는 대로 말하는 AI로: Kanana-o 음성 생성 고도화 과정** - 작성자: martin.gale, abigail.r, edwin.ai - 본문 대신 다음·이전 글 링크와 검색 메뉴만 제공됨 본문 내용을 추가로 보내주시면 요청하신 형식에 맞춰 섹션별로 한국어 요약을 작성하겠습니다.

원문 읽기(새 탭에서 열림)
AI머신러닝kanana-ospeech-synthesis
kakao4분 읽기큐레이션 요약

잘 말하는 AI를 넘어, 원하는 대로 말하는 AI로: Kanana-o 음성 생성 고도화 과정

Kanana-o는 단순히 자연스럽게 말하는 것을 넘어, 사용자가 지정한 속도·음량·억양·감정 등에 맞춰 말하는 음성 생성을 목표로 고도화됐다. 이를 위해 음성을 의미 정보와 음향 정보로 나누어 표현하는 LM-SPT 음성 토크나이저와 온라인 강화학습을 적용했다. LM-SPT는 토큰 시퀀스를 절반으로 줄이고 waveform을 직접 복원해 생성 효율을 높이는 동시에, 음성 특성을 세밀하게 제어할 기반을 마련했다. ## Kanana-o 음성 생성 구조 - 기존 Kanana-o는 음성을 초당 25개의 이산 토큰으로 표현했다. - Voice Token LM이 대화 문맥과 텍스트 답변을 바탕으로 음성 토큰을 순차적으로 생성한다. - 생성된 토큰은 다음 두 단계를 거쳐 음성으로 변환된다. - **Token-to-Mel**: 음성 토큰을 mel-spectrogram으로 변환 - **Mel-to-Waveform**: mel-spectrogram을 waveform으로 복원 ## 기존 음성 토크나이저의 한계 ### 음향 특성 제어의 어려움 - 기존 토크나이저는 발화 내용과 의미를 안정적으로 표현하는 데 강점이 있었다. - 반면 음색, 높낮이, 억양, 속도, 감정 같은 세부 음향 정보는 충분히 구조화하지 못했다. - 따라서 “더 빠르게”, “낮은 목소리로”, “속삭이듯이” 같은 지시를 토큰 수준에서 직접 제어하기 어려웠다. - 같은 문장이라도 화자나 억양에 따라 토큰 표현이 달라지면, 언어모델이 내용과 음향 특성을 독립적으로 학습하기도 어려워진다. ### 긴 시퀀스와 복잡한 디코딩 - 초당 25프레임의 토큰은 발화가 길어질수록 생성해야 할 토큰 수와 연산량을 증가시킨다. - Token-to-Mel 단계에서 Diffusion이나 Flow-matching 기반의 반복 추론이 필요할 수 있다. - 이후 Mel-to-Waveform까지 수행해야 하므로 총 2단계 디코딩 구조가 된다. - 이로 인해 실시간 음성 대화에 필요한 응답 속도와 효율을 확보하기 어렵다. ## LM-SPT의 의미·음향 분리 구조 - LM-SPT는 **LM-aligned SPeech Tokenizer**의 약자로, 언어모델과의 결합을 고려해 설계됐다. - 음성을 기존의 절반인 **초당 12.5프레임**으로 압축한다. - 음성 정보를 다음 두 종류의 토큰으로 분리한다. - **의미 토큰**: 텍스트와 대화 문맥에 대응하는 발화 내용 - **음향 토큰**: 음색, 억양, 높낮이, 발화 속도 등 실제 목소리의 세부 특성 - 두 개의 인코더와 하나의 의미 코드북, 여러 개의 음향 코드북으로 구성된 **Split RVQ** 구조를 사용한다. - 의미 코드북이 발화의 핵심 내용을 표현하고, 여러 음향 코드북이 의미 토큰에서 빠진 음향 정보를 단계적으로 보완한다. ## 의미 음성-재합성 기반 증류 - 단순히 음성을 잘 복원하도록 학습하면 의미 토큰에 음향 정보가 섞이거나, 발화 내용이 음향 토큰에 분산될 수 있다. - 기존 방식은 HuBERT나 WavLM 같은 자기지도학습 음성 모델의 표현을 의미 토큰과 시간 단위로 맞추는 증류를 사용했다. - 그러나 다음과 같은 문제가 있다. - teacher 모델의 표현이 음소·발음 중심이어서 언어모델의 고수준 의미와 완전히 일치하지 않을 수 있다. - 서로 다른 frame rate를 맞추는 과정에서 표현을 평균·축약하면 의미 정보가 희석될 수 있다. - LM-SPT는 Whisper처럼 언어모델과 연계하기 좋은 음성 인코더를 활용한다. - 의미 토큰만으로 원본 음성을 재합성한 뒤, 원본과 재합성 음성의 의미 표현이 유사해지도록 학습한다. - 특정 시간 구간의 teacher 표현을 그대로 모방하지 않고, 압축된 의미 토큰만으로 원본의 발화 내용을 보존하도록 유도한다. - 이 방식은 frame rate가 달라도 인위적인 시간 정렬 없이 의미 정보를 학습할 수 있다는 장점이 있다. ## 효율적인 음성 복원 - 최종 복원 과정에서는 의미 토큰과 음향 토큰을 함께 사용한다. - mel-spectrogram이라는 중간 표현을 거치지 않고 waveform을 직접 생성한다. - 무거운 사전학습 음성 인코더 없이 가벼운 음성 인코더를 사용할 수 있다. - 12.5Hz의 낮은 frame rate로 Voice Token LM의 생성 시간 스텝을 기존 대비 절반으로 줄였다. - 단일 디코더로 waveform을 복원해 기존의 2-stage decoding보다 간결한 구조를 구현했다. ## 온라인 강화학습을 통한 지시 이행 - LM-SPT가 음성의 의미와 음향 특성을 표현할 기반을 제공한다면, 온라인 강화학습은 사용자의 발화 지시를 실제 출력에 반영하도록 모델을 조정한다. - 목표는 음질의 자연스러움을 유지하면서도 다음과 같은 요구를 충실히 따르는 것이다. - 말하기 속도 - 음량 - 음높이와 억양 - 감정과 말투 - 속삭임 등 특정 발화 스타일 - 이를 통해 Kanana-o는 “사람처럼 자연스럽게 말하기”에서 나아가 “사용자가 원하는 방식으로 말하기”를 지향한다. ## 실용적인 결론 음성 AI를 실제 서비스에 적용하려면 음질뿐 아니라 지연시간, 연산량, 제어 가능성을 함께 고려해야 한다. Kanana-o의 접근법처럼 의미·음향 정보를 분리한 저주파 토큰과 직접 waveform을 복원하는 디코더를 사용하고, 온라인 강화학습으로 지시 이행 능력을 보완하는 방식은 실시간·개인화 음성 서비스에 적합한 설계 방향이다.

원문 읽기(새 탭에서 열림)
multimodalkanana-ospeech-synthesislm-spt+3
cloudflare4분 읽기큐레이션 요약

에이전트에게 필요한 건 컨테이너가 아니라 컴퓨터입니다 — @cloudflare/computer 소개

가장 뛰어난 에이전트는 자체 컴퓨터처럼 사용할 수 있는 파일시스템, 셸, 도구, 실행 환경을 제공받는다는 것이 글의 핵심 주장입니다. Cloudflare는 이를 위해 `@cloudflare/computer`라는 에이전트 런타임을 공개 프리뷰로 제공하며, 격리 실행 환경(isolate)과 컨테이너를 하나의 공유 파일시스템 아래 결합합니다. 이를 통해 컨테이너만 사용하는 방식보다 비용과 확장성 문제를 줄이고, 수억~수십억 개의 동시 에이전트까지 확장하는 것을 목표로 합니다. ## 에이전트마다 컴퓨터를 제공하는 방식 - 코딩 에이전트는 파일시스템, 셸, 패키지, 실행 도구를 직접 사용하면서 환경을 조사하고 코드를 수정·실행·검증한다. - 이런 “컴퓨터”가 모델이 현실의 작업을 수행하는 익숙한 인터페이스가 된다. - `@cloudflare/computer`는 코드가 isolate, 컨테이너, 웹 브라우저 중 어디에서 실행되는지에 대한 세부 사항을 플랫폼이 처리하는 런타임이다. - 각 에이전트에 작업 공간과 실행 환경을 제공하면서 효율성과 확장성을 최적화한다. ## 컨테이너 중심 구조의 확장성 문제 - 초기에는 에이전트 전체를 컨테이너 안에서 실행하는 방식이 일반적이었다. - 최근에는 에이전트의 판단 루프와 실제 코드 실행 환경을 분리하고, 샌드박스를 도구로 호출하는 구조가 확산되고 있다. - 그러나 사용자마다 에이전트 전용 컨테이너를 제공하면 수억, 수십억 개의 동시 에이전트를 감당할 컴퓨팅 자원이 부족하다. - 이 때문에 에이전트 시스템에는 GPU뿐 아니라 막대한 양의 CPU 컴퓨팅 자원도 필요하다. ## Isolate와 컨테이너의 결합 - Cloudflare는 수년 전부터 빠르게 생성·삭제할 수 있고 수평 확장에 적합한 isolate를 핵심 컴퓨팅 단위로 개발해 왔다. - isolate는 다음과 같은 특성을 가진다. - 매우 빠른 시작과 종료 - 유휴 상태에서의 휴면 - 에이전트 상태 저장 - 신뢰할 수 없는 코드를 실행하기 위한 추가 isolate 생성 - 대규모 수평 확장 - Cloudflare의 기존 구조에서는 Durable Object 안에서 에이전트 루프를 isolate로 실행하고, 무거운 작업이 필요할 때만 연결된 컨테이너를 도구로 호출한다. - 즉, 가벼운 작업은 isolate에서 처리하고 Linux, npm, 네이티브 바이너리 등이 필요한 작업만 컨테이너에서 실행해 성능과 비용을 조절한다. - `@cloudflare/computer`는 개발자가 이 여러 컴퓨팅 요소를 직접 조합하지 않아도 되도록 더 단순한 추상화를 제공하려는 실험이다. ## 공유 파일시스템 기반 작업 공간 - 에이전트에게 작업에 필요한 파일과 실행 환경이 미리 준비된 내구성 있는 파일시스템을 제공한다. - 에이전트는 작업 성격에 따라 실행 환경을 선택할 수 있다. - 파일 조작, 데이터 처리, Git 저장소 관리는 isolate에서 실행 - Linux 명령, npm, 네이티브 바이너리가 필요한 작업은 컨테이너에서 실행 - isolate와 컨테이너는 동일한 파일을 사용하며, 변경 사항은 원본 파일시스템과 동기화된다. - 파일시스템은 Git 저장소, 스토리지 버킷, 임의의 파일을 대상으로 사용할 수 있다. - 파일 읽기·쓰기·수정은 Code Mode나 Bash 명령으로 수행할 수 있다. - 모든 작업은 다음 방식으로 관리된다. - 권한 제어 - 감사(audit) - 관찰 및 추적(observability) - 따라서 에이전트가 수행할 수 있는 변경 범위를 세밀하게 제한하고, 어떤 작업을 했는지 기록으로 남길 수 있다. ## 사용 방법과 에이전트 통합 - 패키지는 npm으로 설치한다. ```bash npm install @cloudflare/computer ``` - Durable Object에 `Workspace`를 생성해 가상 파일시스템과 실행 런타임을 연결한다. - `Workspace`는 Durable Object의 저장소를 이용해 에이전트별 상태와 파일을 지속적으로 보관한다. - 예시에서는 `@cloudflare/think` 기반 에이전트가 버그 트리아지를 수행하도록 구성한다. - 시스템 프롬프트를 통해 에이전트가 다음 작업을 수행하게 할 수 있다. - `/workspace/repo`의 프로젝트 조사 - 버그 재현 - 안전한 경우 집중적인 수정 - 검증 명령 실행 - 변경 내용과 실행한 명령, 검증 결과 보고 - `@cloudflare/computer`는 기본 실행 백엔드 외에도 개발자가 직접 백엔드를 작성할 수 있다. - 제공된 `CloudflareContainerBackend`를 사용하면 Workspace를 Cloudflare Container와 연결할 수 있다. - `withWorkspaceContainer` 같은 헬퍼를 통해 에이전트 Durable Object와 컨테이너를 결합한다. ## 실용적인 의미 - 가벼운 작업은 isolate로 처리하고 무거운 작업만 컨테이너로 넘기는 구조가 대규모 에이전트 서비스에 적합하다. - 에이전트별 전용 컨테이너를 항상 실행하는 방식보다 자원 사용량과 비용을 줄일 가능성이 크다. - 파일 변경 권한과 실행 기록을 통제할 수 있어 코드 수정 에이전트, 버그 트리아지, 자동화된 개발 작업에 유용하다. - 현재는 초기 공개 프리뷰이므로, 실제 도입 시 지원되는 백엔드와 API 안정성, 작업 격리 수준, 비용 구조를 확인하는 것이 좋다.

원문 읽기(새 탭에서 열림)
TypeScriptCloudflare Workersdurable-objectsisolates+3
cloudflare3분 읽기큐레이션 요약

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를 통해 기능을 라이브러리처럼 분리하는 방식을 고려할 수 있습니다.

원문 읽기(새 탭에서 열림)
TypeScriptPythonJavaScriptCloudflare Workers+4