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

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

AI 에이전트를 위한 임시 Cloudflare 계정

Cloudflare는 AI 에이전트가 사람의 개입 없이 코드를 배포할 수 있도록 ‘임시 계정’을 출시했다. 에이전트는 `wrangler deploy --temporary`를 실행해 별도 회원가입이나 OAuth, API 토큰 입력 없이 Worker를 배포하고, 60분 동안 결과를 테스트할 수 있다. 사용자가 그 안에 계정을 클레임하면 영구 계정이 되며, 클레임하지 않으면 자동 삭제된다. ## AI 에이전트 배포에서 인증이 걸림돌이 되는 이유 - 기존 클라우드 서비스 가입 과정은 브라우저 OAuth, 대시보드 조작, API 토큰 복사, MFA 입력 등 사람을 전제로 한다. - 백그라운드에서 실행되는 AI 에이전트는 브라우저를 열거나 사용자의 즉각적인 확인을 기다리기 어렵다. - 인증 단계에서 멈추면 에이전트가 다른 배포 서비스를 선택할 가능성도 있다. - 에이전트는 코드를 작성하고 배포한 뒤 직접 요청을 보내 검증하는 반복 작업이 중요하므로, 빠르고 저렴한 임시 배포 환경이 필요하다. ## `wrangler deploy --temporary`를 통한 배포 - 최신 Wrangler CLI에서 다음 명령으로 임시 계정에 Worker를 배포할 수 있다. ```bash wrangler deploy --temporary ``` - 사용자가 Cloudflare에 로그인하지 않은 상태에서 배포를 시도하면 Wrangler가 `--temporary` 옵션을 안내한다. - 에이전트가 해당 옵션으로 다시 배포하면 Cloudflare가 자동으로: - 임시 Cloudflare 계정을 생성하고 - Wrangler가 사용할 API 토큰을 발급하며 - 사용자가 계정을 인수할 수 있는 클레임 URL을 제공한다. - 에이전트는 별도의 사람 확인 없이 코드를 작성하고 즉시 배포할 수 있다. ## 작성·배포·검증의 반복 루프 - 에이전트는 TypeScript Worker를 생성한 뒤 배포 결과로 받은 미리보기 URL에 `curl` 등을 실행해 동작을 검증한다. - 예를 들어 “hello world” Worker를 배포한 뒤 응답이 코드와 일치하는지 확인할 수 있다. - 이후 소스 코드를 수정하고 같은 임시 계정을 재사용해 여러 번 재배포할 수 있다. - 임시 계정은 60분의 클레임 기간 동안 유지되므로, 에이전트가 여러 차례 수정·테스트하는 데 적합하다. ## 임시 계정의 클레임과 자동 삭제 - 사용자는 에이전트가 제공한 클레임 링크를 클릭해 Cloudflare에 가입하거나 로그인할 수 있다. - 계정을 클레임하면 임시 계정이 영구적으로 사용자의 계정이 된다. - Worker뿐 아니라 데이터베이스와 기타 바인딩 리소스도 함께 인수할 수 있다. - 60분 이내에 클레임하지 않으면 임시 계정과 배포된 리소스가 자동으로 삭제된다. ## 더 넓은 에이전트용 인프라 - Cloudflare는 Stripe와 협력해 에이전트가 사용자를 대신해 계정 생성, 구독 시작, 도메인 등록, API 토큰 발급까지 수행할 수 있는 프로토콜도 개발하고 있다. - WorkOS와는 기존 OAuth 표준을 활용해 에이전트가 계정을 생성할 수 있도록 하는 `auth.md` 프로젝트를 추진했다. - 임시 계정은 이러한 ‘에이전트 친화적 배포’ 전략의 한 단계로 소개된다. - 기능과 제한 사항은 변경될 수 있으므로 실제 사용 전 Cloudflare 개발자 문서를 확인해야 한다. 에이전트가 짧은 실험이나 프로토타입을 자동으로 배포·검증해야 한다면 `wrangler deploy --temporary`가 유용하다. 다만 60분 내에 클레임하지 않으면 리소스가 삭제되므로, 장기 운영 서비스는 반드시 계정을 클레임하고 정식 인증·관리 체계로 전환해야 한다.

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

AI 에이전트TypeScriptCloudflare Workersstripe+4

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

세상에 없던 직무를 만들어가기

토스의 Technical Writing Chapter는 문서를 작성하는 역할을 넘어 조직의 지식 시스템을 설계하는 조직으로 확장되었습니다. 코드만으로는 설명할 수 없는 의사결정의 맥락과 암묵지를 문서화하고, 이를 사람과 AI가 업무 중 바로 활용할 수 있게 만드는 것이 핵심입니다. 궁극적으로는 문서 작성 자체를 자동화해 TW가 없어도 조직 안에서 지식이 지속적으로 쌓이는 구조를 만드는 것을 목표로 합니다. ### 코드만으로는 완성되지 않는 SSoT - 코드는 시스템이 무엇을 하는지는 보여주지만, 왜 그렇게 설계했는지와 어떤 의사결정을 거쳤는지는 담기 어렵습니다. - 담당자가 자리를 비우거나 퇴사하면 과거 메신저 대화와 개인의 기억에 의존해 맥락을 찾아야 합니다. - AI 역시 일반적인 지식은 잘 활용하지만 조직 고유의 역사와 의사결정 맥락은 알 수 없습니다. - 따라서 진정한 Single Source of Truth는 코드뿐 아니라 코드 주변의 맥락과 히스토리까지 포함해야 합니다. - AI에게 업무를 맡기려면 조직 구성원이 알고 있는 내용을 먼저 구조화해 남겨야 합니다. ### 문서를 쓰는 일에서 지식이 찾아가게 만드는 일로 - 초기에는 프론트엔드 챕터의 온보딩 문서처럼 필요한 내용을 정리하는 데 집중했습니다. - 그러나 좋은 문서도 사람들이 처음부터 읽지 않으며, 필요한 부분만 찾아보는 경우가 많다는 한계가 있었습니다. - 문서 링크를 전달하는 대신, 사람들이 실제로 일하는 메신저와 IDE 안에서 문서 내용을 활용하도록 챗봇 ‘박씨’를 만들었습니다. - 박씨는 기존 문서를 근거로 답변하고 출처까지 제시해, 사용자가 직접 문서를 검색하지 않아도 필요한 지식에 접근하게 했습니다. - 이 시스템을 계기로 문서에 관심이 없던 팀들도 반복 질문을 줄이고 암묵지를 시스템화하기 위해 지식 시스템을 요구하기 시작했습니다. ### 문서에서 지식 시스템으로 - TW의 역할은 문서를 잘 쓰는 사람에서 조직에 맞는 지식 시스템을 설계하는 사람으로 확장되었습니다. - 지식은 특정 맥락에서 문제를 이해하고 더 나은 결정을 내리도록 돕는, 검증된 정보입니다. - 지식 시스템은 코드·대화·배포 기록 등에 흩어진 지식을 한곳에 모으고, 사람이 읽거나 AI가 이해할 수 있는 형태로 구조화합니다. - 이렇게 축적된 지식은 검색뿐 아니라 질문 응답과 업무 자동화에도 활용됩니다. - 조직이 커질수록 반복 질문과 커뮤니케이션 비용이 증가하므로, 지식 시스템은 생산성과 온보딩을 지원하는 조직 인프라가 됩니다. ### Technical Writing Chapter가 하는 네 가지 일 - **지식 플랫폼 개발** - 사내 지식 관리 플랫폼 ‘토독’을 직접 만들고 운영합니다. - **조직별 문서화 주도** - 각 조직의 업무 방식과 필요한 지식에 맞춰 흩어진 정보를 수집하고 활용 구조를 설계합니다. - **문서 작성의 자동화** - AI 워크플로와 자동화를 활용해 구성원이 비슷한 품질의 문서를 작성하고 리뷰받도록 합니다. - 장기적으로 사람이 직접 수행하는 Technical Writing을 줄이는 것이 목표입니다. - **문서화 문화 조성** - AI가 잘 읽을 수 있는 문서 작성법 등을 주제로 전사 세션을 진행합니다. - 조직별 문서화 길드와 지식 커미티를 운영해 지식을 생산하고 관리하는 방식을 바꿉니다. ### 궁극적인 목표: Technical Writer의 소멸 - 올해 목표는 사람이 직접 문서를 작성하지 않아도 조직의 지식이 축적되는 구조를 만드는 것입니다. - TW가 모든 문서를 대신 작성하는 것이 아니라, 조직 구성원과 AI가 지속적으로 지식을 생산·관리하도록 시스템과 문화를 구축합니다. - 최종적으로는 Technical Writing Chapter가 없어도 각 조직이 스스로 지식 시스템을 운영할 수 있도록 만드는 것을 지향합니다. - 이는 직무가 사라진다는 의미보다, 특정 직무에 의존하지 않는 지식 생산 구조를 만든다는 의미에 가깝습니다. ### 다른 직무에도 적용되는 확장 방식 - 이 사례는 정해진 직무를 수행한 결과가 아니라, 조직의 문제를 해결하는 과정에서 직무의 범위를 새롭게 정의한 사례입니다. - AI가 업무 방식을 바꾸는 상황에서는 기존 직무 설명에 머무르기보다 반복되는 문제와 조직의 필요를 따라 역할을 확장할 수 있습니다. - Technical Writer의 전문성은 글쓰기 자체뿐 아니라 지식을 발견하고, 구조화하고, 전달하며, 자동화하는 능력으로 넓어지고 있습니다. 조직의 지식을 개인의 기억이나 메신저 기록에만 남겨두지 않으려면 코드와 맥락을 함께 관리해야 합니다. 문서를 단순한 참고 자료가 아니라 업무 흐름 속에서 바로 활용되는 시스템으로 설계하고, 반복적인 작성과 관리를 자동화하는 방향이 실용적인 접근입니다.

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

knowledge-managementtechnical-writingchatbotdocumentation+3

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

Spark Connect on Kubernetes #1: 견고한 Spark Connect 만들기

토스증권은 여러 사용자가 안정적으로 사용할 수 있는 Production급 Spark Connect를 Kubernetes에서 운영하고 있습니다. Spark Connect는 Driver를 애플리케이션마다 실행하는 대신 장기 실행 서버로 분리해 가벼운 클라이언트와 빠른 세션 생성을 제공하지만, 여러 세션이 하나의 SparkContext를 공유하면서 장애 전파와 리소스 경합 문제가 발생합니다. 이를 해결하기 위해 글로벌 장애 카운터를 사실상 비활성화하고, 결과 크기를 제한하며, 여러 Replica로 Driver와 SparkContext를 분리하는 전략을 사용합니다. ## Classic Spark의 구조와 Spark Connect의 등장 - Spark는 작업을 계획·지휘하는 **Driver**와 실제 연산을 수행하는 **Executor**로 구성됩니다. - Classic Spark의 배포 방식은 다음과 같습니다. - **Client mode**: 클라이언트 프로세스가 Driver 역할을 수행합니다. - **Cluster mode**: 작업 제출 시 클러스터에 Driver가 생성되고 작업 종료 후 사라집니다. - 두 방식 모두 애플리케이션마다 Driver가 하나씩 생성되고, 애플리케이션의 수명과 함께 종료됩니다. - Spark Connect는 Spark 3.4부터 도입됐으며, 4.0에서는 기존 Dataset/DataFrame API와 거의 동등한 수준에 도달했습니다. - 글의 구현과 설정은 Spark 4.1을 기준으로 합니다. ## Spark Connect의 동작 방식 - Spark Connect에서는 Driver를 애플리케이션별 프로세스가 아니라 **미리 실행해 둔 서버**로 운영합니다. - 클라이언트는 Spark 라이브러리와 JVM을 직접 포함하지 않는 Thin Client입니다. - 클라이언트의 DataFrame·SQL 연산은 다음 과정으로 처리됩니다. - 연산을 Unresolved Logical Plan으로 변환 - Protocol Buffer로 인코딩 - gRPC를 통해 서버로 전송 - 서버가 분석, 최적화, 스케줄링, 실행 수행 - 결과를 Arrow 기반으로 클라이언트에 스트리밍 - 구조적으로는 JDBC 클라이언트가 데이터베이스 서버에 질의하는 모델과 유사합니다. ## Spark Connect의 장점 - 클라이언트에 무거운 Spark 의존성이나 JVM이 없어도 됩니다. - Python, SQL, 노트북, BI 도구 등 다양한 클라이언트가 같은 서버에 접속할 수 있습니다. - Driver가 이미 실행 중이므로 매번 프로세스를 생성하고 리소스를 협상할 필요가 없습니다. - 클라이언트가 종료되거나 네트워크가 끊겨도 서버에서 실행 중인 작업은 보호할 수 있습니다. - 반면 하나의 장기 실행 서버에 여러 사용자가 접속하면서, Spark의 기존 “애플리케이션 하나에 워크로드 하나”라는 전제가 깨집니다. ## 공유 Driver가 만드는 단일 장애점 - 여러 세션이 하나의 SparkContext와 Driver JVM을 공유합니다. - Driver가 장애를 일으키면 해당 서버의 모든 세션, 실행 중인 Job, 캐시가 함께 사라집니다. - `spark.executor.maxNumFailures`는 Executor 실패를 애플리케이션 전체 단위로 누적합니다. - 기본 임계값은 `max(3, 2 × executor 수)`입니다. - 임계값을 초과하면 `stopApplication()`이 호출되고, 결과적으로 `sys.exit(11)`로 서버 전체가 종료됩니다. - 이 카운터는 다음 이유로 멀티세션 환경에서 위험합니다. - 개별 쿼리의 Task 실패가 아니라 Executor 실패를 전역적으로 집계합니다. - 시간이 지나도 실패 기록이 계속 누적됩니다. - 서로 다른 사용자의 실패가 합산됩니다. - 문제가 없는 세션도 장애를 함께 겪게 됩니다. ## 세션 격리와 리소스 경합의 한계 - `newSession()`은 SQL 네임스페이스 등 세션 상태만 분리합니다. - CPU, 메모리, Executor, Task 슬롯은 모든 세션이 공유합니다. - 한 사용자가 대규모 Job을 제출하면 다른 사용자의 쿼리 응답도 느려질 수 있습니다. - 기본 FIFO 스케줄링에서는 먼저 제출된 작업이 우선하며, 선점이 없어 이미 실행 중인 Task를 중단할 수 없습니다. - Fair Scheduler를 사용해도 Task 슬롯을 배분하는 순서만 조정할 뿐, 사용자별 CPU·메모리 격리는 제공하지 않습니다. - Spark Connect에서는 `spark.scheduler.pool`이 기본적으로 제대로 전파되지 않아 모든 쿼리가 Default Pool에 들어갑니다. - Classic Spark에서는 `setLocalProperty()`가 Driver 스레드에 직접 적용됩니다. - Spark Connect에서는 클라이언트와 Driver가 분리되어 서버의 요청 처리 스레드에 값을 별도로 설정해야 합니다. - 토스증권은 서버 스레드에 사용자별 Pool을 직접 설정하는 방식으로 이 문제를 보완했습니다. - 사용자별 Pool을 적용하려면 먼저 요청의 사용자를 식별해야 하며, 인증·인가와 연결됩니다. - 궁극적인 CPU·메모리 격리는 Spark 스케줄러가 아니라 Spark 외부의 리소스 관리 계층에서 해결해야 합니다. ## 고정된 서버 스케일 문제 - Spark Connect 서버는 이미지, Driver·Executor 리소스, Spark 설정이 고정된 상태로 실행됩니다. - Dynamic Resource Allocation으로 Executor 수는 조절할 수 있지만, 서버 자체의 기본 스펙은 실행 중 바뀌지 않습니다. - 서버를 필요에 따라 생성·교체하거나 팀 단위로 격리하는 문제는 후속 글에서 다룹니다. ## 글로벌 장애 카운터 비활성화 - 서버 전체를 종료시키는 Executor 실패 경로를 차단하기 위해 다음과 같이 설정합니다. - `spark.executor.maxNumFailures`: 사실상 무한대로 설정해 글로벌 종료 조건을 비활성화 - `spark.executor.failuresValidityInterval`: 오래된 실패 기록을 주기적으로 제거 - `spark.task.maxFailures`: 동일 Task의 반복 실패를 제한 - `spark.stage.maxConsecutiveAttempts`: Shuffle Fetch 실패로 Stage가 반복 실행되는 상황을 제한 - `task.maxFailures`는 OOM이나 예외처럼 동일 Task가 반복 실패하는 경우를 담당합니다. - `stage.maxConsecutiveAttempts`는 Shuffle Fetch 실패로 Stage 전체가 반복되는 경우를 담당합니다. - 이 방식으로 문제가 있는 쿼리만 실패시키고 서버와 다른 사용자의 세션은 유지할 수 있습니다. - 다만 실패 허용 횟수를 지나치게 낮추면 일시적인 장애에도 정상 쿼리가 실패할 수 있으므로 워크로드에 맞춰 여유를 둬야 합니다. ## Driver 메모리 보호와 결과 크기 제한 - Spark Connect에서는 쿼리 결과가 Driver를 거쳐 클라이언트로 스트리밍됩니다. - 사용자가 대규모 테이블을 `collect`하면 Driver 메모리가 고갈될 수 있습니다. - `spark.driver.maxResultSize`는 한 액션에서 반환되는 Task 결과의 누적 크기를 제한합니다. - 제한을 초과하면 Driver가 결과를 모두 가져오기 전에 Job을 중단하므로, 대규모 결과가 Driver 메모리에 유입되는 것을 막을 수 있습니다. - 기본값인 1GB는 애플리케이션 하나만 실행하는 환경의 값이므로, 여러 세션이 동시에 결과를 가져가는 멀티세션 서버에서는 더 보수적으로 설정해야 합니다. - 이 설정만으로 Driver OOM이나 노드 장애까지 막을 수는 없습니다. ## 여러 Replica를 통한 장애 영향 축소 - Driver 자체의 OOM이나 노드 소실처럼 설정으로 막을 수 없는 장애에 대비해 Spark Connect 서버를 여러 Replica로 구성합니다. - 각 Replica는 독립적인 다음 요소를 갖습니다. - SparkContext - Driver - Executor - 한 Replica가 장애로 종료되어도 장애 범위가 해당 Replica에 한정되고, 다른 Replica가 새로운 세션 요청을 처리할 수 있습니다. - 단일 서버의 장애가 Spark Connect 전체로 확산되는 구조를 여러 독립 실행 단위로 나누는 것이 핵심입니다. ## 실용적인 운영 방향 - 멀티세션 Spark Connect에서는 전역 장애 카운터를 그대로 두지 말고, Task·Stage·Job 단위의 실패 제한으로 문제 쿼리를 격리하는 것이 안전합니다. - `spark.driver.maxResultSize`를 동시 세션 수와 쿼리 특성에 맞게 보수적으로 설정해야 합니다. - 스케줄러 Pool만으로는 CPU·메모리 격리가 불가능하므로, 강한 격리가 필요하면 Replica나 Kubernetes 리소스 정책을 활용해야 합니다. - 단일 Driver를 그대로 공유하기보다 여러 Replica를 운영해 장애의 영향 범위를 줄이는 것이 Production 환경에 적합합니다.

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

쿠버네티스apache-sparkgrpcfault-tolerance+4

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

전문성 밖으로 나아가기

Technical Writer(TW)는 문서를 작성·관리하는 역할을 넘어, 지식이 축적되고 활용되는 제품과 시스템을 만드는 제품 오너로 확장되고 있다. 토스의 문서 플랫폼 ‘토독’은 누구나 쉽게 문서를 작성하고, 조직의 지식을 한곳에 모으며, AI가 활용할 수 있도록 하는 것을 목표로 한다. 궁극적으로는 문서화가 별도 업무가 아니라 실제 업무 과정에서 자동으로 발생하고, 지식의 최신성과 품질까지 시스템이 관리하는 구조를 지향한다. ## TW가 제품을 만드는 이유 - TW는 어떤 문서가 읽기 어려운지, 좋은 문서의 조건이 무엇인지, AI가 잘 활용할 수 있는 문서 구조가 무엇인지 깊이 고민해 온 직무다. - 이러한 전문성을 문서 작성에만 적용하지 않고, 문서와 지식 관리 제품의 설계 원칙으로 확장한다. - 제품 오너로서 사용자 인터뷰, 제품 방향 설정, 로드맵·우선순위 결정, 기능 기획과 구현까지 직접 수행한다. - 문서 요구사항을 개발팀에 전달하는 역할이 아니라, 제품의 문제를 정의하고 해결책을 만드는 메이커로 일한다. ## 기존 내부 문서의 문제점 - **높은 작성 장벽** - 정적 사이트 생성기 기반 문서는 저장소 클론, 마크다운 작성, PR 생성과 리뷰 과정을 거쳐야 했다. - 개발자에게는 익숙하지만 디자이너나 PM에게는 문서 작성 자체를 포기하게 만드는 장벽이 됐다. - **낡고 불필요한 지식의 누적** - 작성자와 작성 이유를 알 수 없는 메모, 변경된 정책을 설명하는 문서, 미완성 초안 등이 쌓였다. - 문서의 양이 많아질수록 실제로 신뢰할 수 있는 지식을 판별하기 어려워졌다. - **지식의 파편화** - 문서가 SSG, 문서 도구, 코드, 메신저 대화, 개인의 기억 등에 흩어져 있었다. - 지식이 한곳에 모이지 않으면 조직 차원의 축적과 재활용이 어려웠다. ## 토독의 핵심 가치 - **누구나 쉽게 문서 작성** - 별도의 개발 과정 없이 문서를 만들고 수정할 수 있다. - GitHub, 기존 문서 도구, 사내 메신저 등 다양한 출발점의 지식을 토독으로 연결할 수 있다. - **AI를 통한 지식 활용** - 토독의 문서를 팀별 봇과 연결할 수 있다. - API, CLI, MCP를 제공해 요청 봇, 제품 스펙 관리 등 다양한 방식으로 활용할 수 있다. - **단일 진실 공급원(SSoT)** - 여러 곳에 흩어진 정보를 모아 완결된 문서로 구성한다. - 어떤 지식이 최신이고 유효한지 한곳에서 확인할 수 있게 한다. - **확장 가능한 플랫폼** - 조직이나 팀마다 별도 도구를 선택하고 인프라를 구축할 필요가 없다. - 하나의 플랫폼 안에서 각 팀이 독립적인 문서 공간을 운영할 수 있으며, 계열사로도 확장할 수 있다. ## 문서 품질을 자동으로 관리하기 - 문서 작성 장벽을 낮추면 문서 수는 늘지만 품질이 떨어질 수 있다. - 기존에는 TW가 직접 문서를 리뷰하고 낡은 문서를 찾아 수정했다. - 토독은 TW가 정의한 ‘좋은 문서’의 기준을 다음 기능으로 전환하고 있다. - AI 교정 기능 - 문서 봇을 통한 초안 작성 - 자동 리뷰와 개선점 제안 - 다만 사용자가 직접 문서를 작성해야 한다는 전제만으로는 충분하지 않다고 판단했다. ## 업무 과정에서 자동으로 생성되는 문서 - 문서화를 별도의 업무로 요구하기보다, 일하는 과정에서 자연스럽게 문서가 생성되도록 한다. - 사내 메신저의 의사결정과 논의, 코드 변경 내역 등을 자동으로 문서화한다. - 코드 변경이나 의사결정 이후의 논의를 모니터링해 문서가 계속 갱신되도록 설계한다. - 단순히 정보를 수집하는 데 그치지 않고 다음을 판단하는 것이 목표다. - 정책과 실제 코드가 일치하는가 - 해당 지식이 실제 업무에서 사용되고 있는가 - 문서가 얼마나 최신 상태인가 - 현재도 유효한 지식인가 ## TW 전문성의 시스템화 - 좋은 문서를 직접 쓰는 능력에서, 좋은 문서가 반복해서 생산되도록 시스템을 설계하는 능력으로 중심이 이동한다. - 문서가 읽히지 않는 이유에 대한 경험은 누구나 쉽게 쓰고 AI도 잘 읽는 문서 기준으로 전환된다. - 좋은 문서에 대한 판단은 AI 교정과 자동 리뷰의 기준이 된다. - 낡은 문서를 식별하고 유효성을 판단하는 역량은 지식 신선도와 신뢰도를 관리하는 시스템으로 구현된다. - TW의 역할은 다음과 같이 정리된다. - 흩어진 지식이 모일 장소를 만든다. - 좋은 문서의 기준을 정의한다. - 사람의 판단을 시스템에 반영한다. - 업무 과정에서 문서가 자연스럽게 만들어지게 한다. - 축적된 지식이 스스로 갱신되도록 한다. ## 지향하는 업무 환경 - 시스템이 오래된 문서를 감지해 담당자에게 알리고 개선안을 제안한다. - 프로젝트 관리 도구를 별도로 갱신하지 않아도 업무 과정의 기록이 자동으로 정리된다. - 릴리즈 공지와 반복적인 문의 답변이 지식으로 남아 신규 구성원의 학습 비용을 줄인다. - 한 번의 업무가 조직 전체에서 재사용 가능한 흔적으로 남아 실행 시간을 단축한다. - TW는 반복적인 문서 관리보다 제품의 방향과 지식 거버넌스 설계에 집중한다. 결국 토독의 목표는 문서를 잘 쓰게 만드는 데서 끝나지 않는다. 조직의 업무 흐름 자체가 신뢰할 수 있는 지식을 만들고 갱신하도록 설계하는 것이 핵심이며, 이는 TW의 전문성을 조직 전체의 시스템으로 확장하는 방식이다.

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

AI모델 컨텍스트 프로토콜githubAPI+4

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

디자이너에게 AI로 뭐든 만들어보라고 한다면

토스 디자인 챕터의 AI Contest는 AI로 무엇이든 만들어보는 한 달간의 실험으로, 총 122개의 결과물이 모였습니다. 사례를 보면 AI는 완전히 새로운 업무보다 반복 작업 자동화, 지식 공유, 인터랙션 설계, 짧은 시간 안의 품질 향상에 특히 효과적이었습니다. 핵심은 AI를 직접 활용해 자신의 문제를 빠르게 실험하고 해결하는 데 있습니다. ## 반복 업무를 자동화하다 - 이미지를 입력하면 UI에 적합한 색상을 자동으로 추출하고 보정하는 로직을 개발했습니다. - 사진마다 색상 결과가 달라 수년간 해결하지 못했던 문제를 AI와 함께 코드 초안으로 만들었습니다. - 샘플 이미지를 반복해서 입력하고 결과를 검증·수정하며 로직을 개선했습니다. - 완성된 로직은 실제 토스 쇼핑 상품 카드의 색상에 적용됐습니다. ## 개인 지식으로 협업 비용을 줄이다 - 과거 슬랙 대화와 정리된 참고 자료를 학습한 메신저 봇을 만들었습니다. - 팀원의 디자인·요건 질문에 대해 과거 논의를 근거로 답변 초안을 생성합니다. - 담당자는 초안을 그대로 보내거나 수정해 전달할 수 있습니다. - 사람이 수정한 답변 방향도 다시 반영해 유사한 질문에 더 정확히 답하도록 개선됩니다. - 반복적인 질문 대응 시간이 줄어들면서 “내가 1.5명으로 늘어난 느낌”이라는 효과를 얻었고, 다른 디자이너들도 각자의 봇을 만들기 시작했습니다. ## 말보다 동작하는 프로토타입으로 설득하다 - 주식 거래용 증권 PC 화면을 정적인 시안이 아닌 실제로 조작 가능한 프로토타입으로 구현했습니다. - 패널을 끌어 위치를 바꾸거나 창 크기를 조절하면 화면이 반응하도록 제품 코드를 직접 활용했습니다. - 말이나 영상으로 설명해야 했던 인터랙션을 직접 움직여 보여주면서 디자인 의도가 개발 과정에서 흐려지는 문제를 줄였습니다. - 개발자와 PO가 결과를 즉시 이해할 수 있어 커뮤니케이션과 설득력이 높아졌습니다. ## 제한된 시간에 완성도를 높이다 - 토스뱅크 공채 웹페이지의 직군별 키비주얼에 사용할 모션그래픽을 AI로 제작했습니다. - 모션의 기본 이미지와 시작·끝 프레임은 사람이 직접 만들고, 중간 결과 생성은 Kling을 활용했습니다. - 원하는 결과가 나올 때까지 프롬프트를 반복적으로 수정했습니다. - 촉박한 일정 속에서도 직군별 모션을 단 하루 만에 완성했습니다. ## AI 활용을 시작하는 네 가지 방향 - **효율:** 매일 반복하는 일 중 가장 번거로운 작업 하나를 자동화합니다. - **분신:** 반복해서 답하는 질문을 대신 처리할 개인 지식 봇을 만듭니다. - **설득:** 말로 설명하던 디자인을 직접 작동하는 프로토타입으로 보여줍니다. - **퀄리티:** 짧은 시간 안에 더 높은 완성도에 도달할 수 있도록 AI를 제작 과정에 활용합니다. AI를 도입할 때는 거창한 신규 프로젝트보다 현재 업무에서 반복되거나 설명하기 어렵고 시간이 부족한 문제 하나를 골라 작게 실험하는 것이 효과적입니다.

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

AI프로토타이핑slack프롬프트 엔지니어링+3

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

NVIDIA RTX PRO 4500 Blackwell 서버 에디션 GPU로 가속되는 Amazon EC2 G7 인스턴스 발표 | Amazon Web Services

Amazon EC2 G7은 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU와 6세대 Intel Xeon 프로세서를 결합한 GPU 인스턴스다. G6 대비 AI 추론 성능은 최대 4.6배, 그래픽 성능은 최대 2.1배 향상됐으며, 네트워크·스토리지·영상 처리 성능도 크게 개선됐다. AI 추론, 그래픽 렌더링, 영상 변환, VDI, 공간 컴퓨팅, 데이터 분석 등에 적합하다. ## NVIDIA Blackwell GPU 기반 성능 향상 - AWS 최초로 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU를 지원한다. - GPU당 32GB 메모리를 제공하며, 인스턴스당 최대 8개 GPU와 총 256GB GPU 메모리를 구성할 수 있다. - G6 대비 GPU 메모리 용량은 1.33배, 메모리 대역폭은 2.45배 향상됐다. - 5세대 Tensor Core와 4세대 RT Core를 탑재해 AI 추론과 실시간 그래픽 처리를 가속한다. - G6 대비 AI 추론 성능은 최대 4.6배, 그래픽 성능은 최대 2.1배 높다. ## 네트워크와 로컬 스토리지 개선 - EFA(Elastic Fabric Adapter)를 지원하는 최대 700Gbps 네트워크 대역폭을 제공한다. - G6 대비 네트워크 처리량이 7배 증가해 다중 GPU·다중 노드 AI 및 분석 작업에 유리하다. - 최대 7.6TB의 로컬 NVMe SSD를 사용할 수 있다. - 대규모 모델과 데이터셋을 컴퓨팅 자원 가까이에 저장해 데이터 전송 지연과 처리 오버헤드를 줄인다. - 다중 GPU 환경에서는 NVIDIA GPUDirect P2P를, GPU와 네트워크·스토리지 간 통신에는 GPUDirect RDMA와 EFA를 지원한다. ## 영상 인코딩·디코딩 성능 - 9세대 NVENC와 6세대 NVDEC 엔진을 탑재했다. - 고해상도 영상 작업에 필요한 4:2:2 인코딩과 디코딩을 지원한다. - 동시 처리 가능한 영상 스트림 수가 G6 대비 1.5배 증가했다. - 영상 트랜스코딩, 스트리밍, 미디어 분석과 같은 작업에 적합하다. ## 인스턴스 구성 - 총 7개 크기로 제공된다. - 최대 사양: - NVIDIA RTX PRO 4500 GPU 8개 - GPU 메모리 256GB - vCPU 192개 - 시스템 메모리 768GiB - 네트워크 대역폭 700Gbps - 로컬 NVMe SSD 7.6TB - 12xlarge, 24xlarge, 48xlarge 크기는 Dedicated Instances도 지원한다. ## 지원 소프트웨어와 운영 환경 - AWS Deep Learning AMI와 NVIDIA Workstation AMI를 통해 사전 구성된 GPU 드라이버를 사용할 수 있다. - Amazon EKS에서 사용하려면 NVIDIA 드라이버 R595와 EKS 자동화 기능을 이용해 AMI를 구성해야 한다. - Amazon Linux, Ubuntu, RHEL, Windows Server를 지원한다. - DirectX, Vulkan, OpenGL 등 주요 그래픽 라이브러리와 호환된다. - Amazon EMR on EKS에서 GPU 가속 데이터 분석에도 활용할 수 있다. ## 제공 지역과 구매 방식 - 발표 시점에는 미국 동부 오하이오와 미국 서부 오리건 리전에서 사용할 수 있다. - 향후 리전 확대 여부는 AWS Capabilities by Region 페이지에서 확인할 수 있다. - On-Demand, Savings Plans, Spot Instances 방식으로 구매 가능하다. - 자세한 요금은 Amazon EC2 요금 페이지에서 확인해야 한다. G7은 GPU 메모리와 네트워크 대역폭이 중요한 AI 추론, 대규모 그래픽 처리, 영상 처리 및 분산 분석 작업에 특히 적합하다. 기존 G6에서 GPU·네트워크 병목을 겪고 있다면, 사용 리전과 실제 워크로드별 비용 대비 성능을 비교한 뒤 G7으로 이전하는 것이 좋다.

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

쿠버네티스AWSamazon-ec2gpu-acceleration+4

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

Amazon ECS, 더 빠른 서비스 자동 조정을 위한 새로운 고해상도 지표 도입 | Amazon Web Services

Amazon ECS가 20초 단위 고해상도 CloudWatch 지표를 지원해 서비스 자동 조 scaling 반응 속도를 크게 높였다. AWS 벤치마크에서 스케일 아웃 시작까지의 시간이 363초에서 86초로 76% 단축됐고, 새 태스크 프로비저닝 완료까지도 386초에서 109초로 줄었다. 이를 통해 트래픽 급증에 더 빠르게 대응하면서도 사전 확보 태스크 수와 비용을 줄일 수 있다. ## ECS 서비스 자동 조정 방식 - ECS 서비스 자동 조정은 수요에 맞춰 실행 중인 태스크 수를 자동으로 조절한다. - 지원되는 주요 방식은 다음과 같다. - **예측 조정**: 머신러닝으로 반복적인 트래픽 패턴을 예측해 선제적으로 확장 - **예약 조정**: 계획된 이벤트에 맞춰 사용자가 지정한 일정으로 조정 - **Target Tracking**: CPU, 메모리, 요청 수, 큐 깊이 등 실시간 지표가 목표값을 유지하도록 조정 - 고해상도 지표는 특히 Target Tracking 방식에서 빠른 반응을 제공한다. ## 20초 고해상도 지표의 효과 - 기존 표준 지표는 60초 단위였지만, 새 지표는 20초 간격으로 스케일링 결정을 평가한다. - AWS 테스트 결과: - 스케일 아웃 시작: **363초 → 86초**, 76% 단축 - 태스크 확장 및 프로비저닝 완료: **386초 → 109초**, 72% 단축 - 기대 효과: - 트래픽 급증 시 지연 시간과 장애 가능성 감소 - 급증에 대비한 과도한 기본 태스크 수를 줄여 비용 절감 - 복잡한 Step Scaling 정책 없이 Target Tracking만으로 공격적인 확장 가능 ## 설정 방법 - ECS 서비스 생성 또는 업데이트 시 Monitoring 설정에서 **20초 해상도 지표**를 활성화한다. - Service auto scaling에서 다음을 설정한다. - 자동 조정 활성화 - 정책 유형으로 **Target Tracking** 선택 - 다음 고해상도 지표 중 하나 선택 - `ECSServiceAverageCPUUtilizationHighResolution` - `ECSServiceAverageMemoryUtilizationHighResolution` - 기존 서비스는 먼저 `Update Service`로 고해상도 지표를 활성화하고 배포가 완료된 뒤, 서비스의 자동 조정 정책을 고해상도 지표 기반으로 변경해야 한다. - 콘솔뿐 아니라 AWS SDK, AWS CloudFormation, Application Auto Scaling을 통한 AWS CLI로도 설정할 수 있다. ## 지원 범위와 비용 - AWS Fargate, ECS Managed Instances, Amazon EC2 기반 ECS 서비스에서 사용할 수 있다. - ECS의 고속 자동 조정 기능 자체에는 별도 비용이 없지만, 20초 단위 고해상도 CloudWatch 지표에는 추가 요금이 발생한다. - 표준 60초 지표는 무료이며, 실제 비용은 CloudWatch 요금 정책을 확인해야 한다. 트래픽 변동이 크고 급격한 부하 증가에 민감한 ECS 서비스라면 고해상도 CPU 또는 메모리 지표와 Target Tracking을 함께 사용하는 것이 권장된다. 다만 지표 비용과 실제 확장 효과를 함께 검토해, 모든 서비스에 일괄 적용하기보다는 스케일 아웃 지연이 문제가 되는 워크로드부터 적용하는 것이 적절하다.

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

amazon-ec2aws-cliamazon-ecsaws-cloudformation+4

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

나만의 취약점 테스트 하네스 구축하기

프론티어 모델 하나에 의존하는 대신, 모델을 교체할 수 있는 취약점 분석 하니스(harness)를 구축해야 한다는 글입니다. 하니스는 정찰·탐색·검증·중복 제거·재검증·트리아지를 지속적으로 수행하며, 수천 개의 후보를 실행 가능한 취약점 목록으로 줄입니다. 핵심은 LLM을 상태를 보존하지 않는 계산 엔진으로 취급하고, 분석 상태와 결과를 데이터베이스 및 파이프라인에 외부화하는 것입니다. ## 단일 에이전트 방식의 한계 - 일반적인 코딩 에이전트는 한 번에 하나의 가설만 유지하므로 대규모 저장소의 여러 공격 경로를 동시에 분석하기 어렵습니다. - 컨텍스트 창이 가득 차면 컨텍스트 압축 과정에서 이전에 발견한 버그나 분석 근거를 잃을 수 있습니다. - 단일 저장소만 분석하면 다른 애플리케이션·라이브러리·서비스와의 연결에서 발생하는 취약점을 놓칩니다. - 한 번 실행한 결과는 전체 버그의 약 절반 정도만 찾으며, 비교적 단순한 취약점에 편향되는 경향이 있습니다. - 분석을 여러 번 실행한 뒤 결과를 사람이 직접 비교해야 한다면, 이미 전용 하니스가 필요한 단계에 도달한 것입니다. ## 모델에 독립적인 하니스가 필요한 이유 - 특정 모델에 시스템을 맞추면 해당 모델이 코드를 바라보는 방식에 분석 범위가 고정됩니다. - 서로 다른 모델을 같은 코드에 적용하면 각 모델이 서로 다른 취약점을 발견할 수 있습니다. - 예를 들어 한 모델은 초기 탐색을 담당하고, 다른 모델은 발견된 취약점의 재현 가능성과 타당성을 검증하도록 구성할 수 있습니다. - 모델이 교체되거나 더 뛰어난 모델이 등장해도 하니스의 상태 관리·오케스트레이션·트리아지 구조는 그대로 유지할 수 있습니다. - 따라서 장기적으로 중요한 자산은 특정 프롬프트나 모델보다 모델을 연결하고 결과를 관리하는 하니스입니다. ## 초기 보안 감사 스킬 처음에는 약 450줄 규모의 `security-audit` 스킬을 단일 저장소에서 실행하며 프롬프트를 조정했습니다. 이후 이 스킬의 단계가 전체 하니스의 기본 구조로 확장되었습니다. - **정찰(Recon)** - 세 개의 병렬 연구 에이전트가 저장소 구조와 아키텍처를 조사합니다. - 결과를 `architecture.md`에 기록합니다. - **공격 탐색(Hunt)** - 공격 클래스별로 Hunter 에이전트를 실행합니다. - 코드를 검토하는 데 그치지 않고 실제로 깨뜨리는 시도를 합니다. - **검증(Validate)** - 적대적 검증 에이전트가 각 발견을 반박하려고 시도합니다. - 재현되지 않거나 근거가 약한 후보를 제거합니다. - **보고서 작성(Report)** - 살아남은 취약점을 사람이 읽을 수 있는 보고서로 정리합니다. - **기계적 검증** - `findings.json`을 정해진 스키마에 맞춰 생성합니다. - 파일 형식뿐 아니라 취약점에 언급된 함수와 줄 번호가 실제 소스에 존재하는지도 검사합니다. - **독립 재검증** - 별도의 새로운 에이전트가 소스를 기준으로 모든 발견을 다시 확인합니다. - 최종 생존 항목만 수집 API로 제출합니다. ## 파이프라인으로의 확장 초기 스킬의 단계는 다음과 같이 하니스의 파이프라인으로 대응됩니다. - `architecture.md`를 생성하는 연구 에이전트 → **Recon** - 공격 유형별 Hunter → **Hunt** - 발견을 반박하는 Validator → **Validate** - 검증된 항목의 보고서화 → **Report** - `findings.json`의 스키마 및 소스 위치 검사 → **기계적 검증** - 새로운 에이전트의 최종 확인 → **독립 검증** 이 구조는 한 번의 긴 세션에 모든 작업을 몰아넣지 않고, 각 작업을 독립적으로 실행·저장·재시작할 수 있게 합니다. ## 상태를 외부화해야 하는 이유 - **컨텍스트 고갈** - 장시간 실행하면 모델이 기존 분석 내용을 잊습니다. - 분석 상태, 가설, 조사 결과, 발견 사항을 데이터베이스 등에 저장해 모델의 기억에 의존하지 않도록 해야 합니다. - LLM은 상태를 가진 작업자라기보다 필요할 때 호출되는 계산 엔진으로 취급합니다. - **지속성 부족** - 네트워크 오류, API 제한, 프로세스 충돌이 발생해도 처음부터 다시 시작해서는 안 됩니다. - 각 단계의 진행 상황과 결과를 저장하면 중단된 지점부터 재개할 수 있습니다. - **재범위 지정과 교차 참조** - 독립적인 조사 결과를 나중에 다시 불러오고, 다른 발견이나 저장소와 연결할 수 있어야 합니다. - 수백 개의 조사를 별도의 실행 단위로 유지해야 중복 제거와 후속 검증이 가능합니다. ## 대규모 트리아지와 교차 저장소 분석 - 엔터프라이즈 환경에서는 원시 취약점 후보가 수천 개 생성될 수 있습니다. - 하니스는 후보를 수집하는 것에서 끝나지 않고, 검증·중복 제거·우선순위 지정 과정을 거쳐 신뢰할 수 있는 수정 큐로 줄여야 합니다. - 단일 저장소 분석만으로는 해당 저장소를 사용하는 애플리케이션과의 인터페이스 문제를 볼 수 없습니다. - 여러 저장소 간 의존성과 데이터 흐름을 추적하면 구성 요소 사이에서만 드러나는 취약점을 찾을 수 있습니다. - 다만 교차 저장소 추적은 초기 구현부터 넣기보다, 실제로 중요한 저장소가 여러 개일 때 도입하는 것이 권장됩니다. ## 단계적으로 구축하는 방법 - 최소한의 하니스는 데이터베이스에 상태를 저장하는 **Recon, Hunt, Validate** 세 단계로 시작할 수 있습니다. - 자기 자신이 발견 사항을 제출하지 못하는 별도의 Validator를 두어 검증 편향을 줄입니다. - 먼저 개발 환경에서 단일 스킬로 프롬프트와 공격 시나리오를 충분히 다듬습니다. - 다음 기능은 현재의 병목이 명확해졌을 때만 추가합니다. - 중단 후 재개가 문제라면 영속성 추가 - 결과가 너무 많으면 중복 제거 에이전트 추가 - 여러 저장소가 실제 분석 대상이 되면 교차 저장소 추적 추가 - 초기부터 전부 자동화하기보다, 현재 작업을 가장 느리게 만드는 문제를 해결하는 방향으로 하니스를 확장해야 합니다. 실용적으로는 특정 모델이나 프롬프트에 시스템을 종속시키지 말고, 분석 상태·발견 사항·검증 결과를 저장하는 모델 독립적 파이프라인부터 구축하는 것이 좋습니다.

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

AI 에이전트vulnerability-scanningsecurity-auditllm-orchestration+3

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

프로젝트 갈릴레오 12주년 기념

Cloudflare의 Project Galileo는 표현의 자유와 민주주의를 지키는 시민사회 조직이 권력이나 공격 때문에 온라인에서 퇴출되지 않도록 무료 보안 서비스를 제공하는 프로그램이다. 출범 12년째인 2026년에는 120개국 3,400개 이상의 웹사이트를 지원하며, 시민사회 대상 사이버공격이 일반 인터넷 사용자보다 더 빈번하고 강도 높다는 연례 보고서를 처음 발표했다. Cloudflare는 저렴하고 단순한 보안 접근성, 공격과 인터넷 차단에 대한 투명성, AI 및 포스트퀀텀 보안의 기본 적용을 앞으로의 과제로 제시했다. ## Project Galileo의 역할과 성장 - Cloudflare가 12년 전 시작한 공익 프로그램으로, 언론인·인권 옹호자·비영리단체 등에 무료 사이버보안 서비스를 제공한다. - 현재 120개국 3,400개 이상의 웹사이트가 참여하고 있다. - Cloudflare 네트워크는 125개국 335개 이상의 도시에 분포하며, 전체 웹의 20% 이상을 처리한다. - 이 광범위한 네트워크 덕분에 시민사회 조직에 대한 공격과 일반 고객 대상 공격을 비교할 수 있었다. - 프로그램 참여 신청은 59개 시민사회 파트너가 심사·승인하며, 파트너들은 하루에도 여러 건의 신청을 검토한다. ## 시민사회 대상 사이버공격의 주요 추세 - **DDoS 공격** - 시민사회 조직에 가장 흔한 위협이었다. - 단시간 공격보다 지속 시간이 긴 것이 특징이며, 일부 공격은 며칠 또는 몇 주간 이어졌다. - **웹사이트 취약점 공격** - 시민사회 단체를 대상으로 한 취약점 악용 시도가 일반 Cloudflare 고객보다 7배 이상 많았다. - 특히 미디어 조직이 불균형적으로 큰 피해를 입었다. - **망명 중인 언론인에 대한 악성 트래픽** - 망명 상태에서 활동하는 언론인은 전체 언론 조직보다 거의 4배 높은 악성 트래픽에 노출됐다. - **피싱 이메일** - Cloudflare가 시민사회 조직을 대상으로 처리한 이메일 중 거의 10%에 잠재적인 피싱 콘텐츠가 포함됐다. - 공격은 탐사보도 발표나 공개 캠페인처럼 조직의 활동이 중요한 시점에 집중되는 경향을 보였다. ## 연례 위협 보고서와 사례 연구 - Cloudflare는 시민사회 대상 사이버공격을 다루는 종합 보고서를 처음 공개했다. - 앞으로 매년 보고서를 발간해 공격 유형과 강도의 변화를 장기적으로 비교할 계획이다. - 보고서는 시민사회 단체뿐 아니라 정책 입안자와 일반 대중이 사이버공격을 이해하고 대응하는 자료로 활용되도록 작성됐다. - 정량 데이터에 더해 16개 Project Galileo 참여 조직의 보안 요구를 다룬 사례 연구도 공개했다. - 사례 연구 대상에는 다음과 같은 조직이 포함된다. - 디지털 권리·표현의 자유 단체인 SHARE Foundation - 실종·유실 반려동물 플랫폼 Hledaczvirat - 핵무기와 비확산 문제를 연구하는 Iran Watch - 핵 위험·기후변화·기술을 다루는 Bulletin of Atomic Scientists - 전쟁범죄 증거를 보존하는 Ukraine War Archive - 빈곤·보건·기후 데이터를 제공하는 Our World in Data - 탐사보도 네트워크 OCCRP - 중국의 검열과 인권을 다루는 China Digital Times - 해양 생태계를 보호하는 Sea Shepherd Brazil 등 ## 보안 접근성을 높이기 위한 과제 - 모든 사람이 이용할 수 있는 단순하고 저렴한 사이버보안 도구가 필요하다고 강조했다. - 사이버공격과 인터넷 차단에 대한 투명성을 확대해야 한다고 제안했다. - AI 기반 위협과 포스트퀀텀 환경에 대비한 보호 기능을 보안 도구에 기본값으로 포함해야 한다고 밝혔다. - 시민사회 조직은 공익 활동의 특성상 공격 시점과 목적이 명확한 경우가 많으므로, 일반적인 보안 도구뿐 아니라 지속적인 모니터링과 대응 체계가 필요하다. ## 지역 파트너십 확대 - Project Galileo는 파트너 조직을 통해 각 지역의 시민사회 단체를 발굴하고 신청을 심사한다. - 기존 협력은 이메일 보안과 공공학교 인터넷 측정 같은 새로운 사업으로 확장됐다. - Protect.ngo와는 시민사회 조직을 위한 이메일 보안 사업을 진행했다. - UNICEF의 Giga 프로젝트와는 공립학교의 인터넷 연결 상태 측정을 지원했다. - 북미와 유럽 이외 지역의 조직을 더 많이 지원하기 위해 Costa Rica·Taiwan RightsCon 등 지역 행사에도 참여했다. - 아시아·태평양 지역에서는 EngageMedia와 OpenCulture Foundation을 새 파트너로 맞이했다. - 올해는 AI 크롤러로부터 지역 언론 콘텐츠를 보호하는 신규 서비스와 연계해 언론인 지원 조직에 초점을 맞췄다. - 새 파트너로 International Center for Journalists와 Media Cluster Norway 등이 소개됐다. 제공된 글은 세 번째 파트너 설명이 끝나기 전에 중단되어 있다. Project Galileo의 사례는 시민사회 조직의 보안이 단순한 기술 문제가 아니라 표현의 자유와 공공 참여를 유지하기 위한 기반임을 보여준다. 특히 언론·인권 단체는 공격이 집중되는 시점과 장기화되는 DDoS에 대비해 웹 방화벽, DDoS 방어, 이메일 피싱 대응, 취약점 관리 체계를 기본적으로 갖추는 것이 바람직하다.

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

AIpost-quantum-cryptographycybersecurityddos+3

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

스펙만 바꾸면 프롬프트가 따라옵니다 - 답변 생성 모델 자동화 파이프라인

제공된 내용은 기술 블로그 글이 아니라 NAVER D2 사이트의 메뉴와 저작권 표시로 구성되어 있습니다. 따라서 특정 기술 주제에 대한 주장, 설명, 결론 또는 기술적 세부사항은 포함되어 있지 않습니다. ### 사이트 구성 - **Hello world**: 초기 또는 기본 게시물로 보이는 항목입니다. - **D2 News**: NAVER D2 관련 소식과 공지를 다루는 메뉴입니다. - **About D2**: D2 서비스나 조직에 대한 소개 영역입니다. - **NAVER Developers**: 네이버 개발자 관련 콘텐츠로 연결되는 메뉴입니다. - **DEVIEW**: 네이버 개발자 콘퍼런스 관련 항목입니다. - **OpenSource**: 오픈소스 프로젝트나 관련 자료를 다루는 영역입니다. - **D2 STARTUP FACTORY**: 스타트업 지원 프로그램 또는 투자·육성 관련 메뉴입니다. ### 저작권 정보 - 저작권자는 **NAVER Corp.**로 표시되어 있습니다. - 표기 문구는 “Copyright © NAVER Corp. All Rights Reserved.”입니다. 실제 기술 글의 본문이 누락된 것으로 보이므로, 원문 내용을 추가로 제공해야 기술 주제와 결론을 정확히 요약할 수 있습니다.

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

오픈 소스software-developmentdeveloper-community

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

링크 데이터가 AI 지출에 대해 말해주는 것

Stripe의 디지털 지갑 Link 사용자들은 AI 제품과 서비스에 대한 지출을 빠르게 늘리고 있다. 특히 AI 앱 빌더 플랫폼에 대한 투자가 두드러지며, 이는 AI를 단순히 사용하는 단계를 넘어 직접 구축하려는 수요가 커지고 있음을 보여준다. Stripe는 이러한 에이전트 중심 소비 흐름에 대응해, 사용자가 지출 한도를 설정하고 AI 에이전트가 대신 결제할 수 있는 Link 지갑을 개발했다. ### AI 제품에 대한 지출 증가 - Stripe는 Link 사용자 2억 5천만 명의 결제 데이터를 분석해 AI 관련 소비 패턴을 조사했다. - AI 제품 지출 상위 10% 고객의 월평균 지출은 다음과 같이 증가했다. - 2025년 12월: 183달러 - 2026년 3월: 359달러 - 183달러에서 359달러로 증가하는 데 걸린 기간은 단 3개월로, 한 분기 만에 거의 두 배가 됐다. - 같은 고객군이 월 지출을 84달러에서 183달러로 늘리는 데는 22개월이 걸렸다는 점에서 최근 성장 속도가 크게 빨라졌다. - 중간 수준인 50백분위 고객의 월평균 지출도 같은 기간 60달러에서 72달러로 증가했다. ### AI 앱 빌더 플랫폼의 가파른 성장 - Replit, Lovable, Bolt와 같은 AI 기반 앱 빌더 플랫폼에서 지출 증가폭이 특히 크게 나타났다. - AI 제품 지출 상위 10% 고객은 2025년 1월과 비교해 해당 플랫폼에 매달 약 5배 더 많이 지출하고 있다. - 이는 소비자와 개발자가 AI 서비스를 단순 이용하는 것을 넘어, AI를 활용해 애플리케이션과 제품을 직접 만들려는 흐름이 강해졌음을 의미한다. ### 채팅형 에이전트와 쇼핑 행동 - Stripe가 394명의 Link 고객을 대상으로 조사한 결과: - 80%는 최근 한 달 동안 채팅형 에이전트를 사용했다. - 절반은 적어도 매달 한 번 AI를 쇼핑 조사에 활용했다. - AI 에이전트가 상품을 검색하고 비교하는 수준을 넘어 실제 구매까지 수행하려면 결제 권한과 안전장치가 필요하다. - 따라서 AI 사용 증가는 향후 에이전트가 소비자의 구매 과정에 직접 참여하는 방향으로 이어질 가능성이 있다. ### 에이전트 결제를 위한 Link 지갑 - Stripe는 AI 에이전트가 사용자를 대신해 결제할 수 있도록 ‘Link’s wallet for agents’를 구축했다. - 주요 기능은 다음과 같다. - 사용자가 에이전트의 결제 권한을 직접 승인 - 사용자가 설정한 지출 한도와 통제 조건 적용 - Stripe를 사용하는 모든 판매자에게 폭넓게 구매 가능 - 사업자는 복잡한 별도 연동 없이 검증된 거래를 수신 - 이를 통해 AI 에이전트의 자율적인 구매와 사용자의 통제 사이의 균형을 맞추려 한다. ### 실용적인 시사점 - AI 서비스 기업은 단순한 챗봇 기능보다 실제 작업 수행과 결제까지 연결되는 에이전트 경험을 고려할 필요가 있다. - 앱 빌더 플랫폼과 개발 도구 분야는 AI 투자 확대의 직접적인 수혜 영역으로 볼 수 있다. - 에이전트 결제를 도입할 때는 지출 한도, 사용자 승인, 거래 검증 등 통제 기능을 핵심 설계 요소로 삼아야 한다.

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

AI 에이전트stripeagentic-commercereplit+4

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

거버넌스 및 운영을 위한 AI 카탈로그 업데이트

GitLab 19.1은 Duo Flows를 실제 GitLab 이벤트에 따라 자동 실행할 수 있게 하며, AI 자동화를 지속적이고 무인으로 운영할 기반을 제공합니다. 동시에 관리자용 에이전트·플로우 통제, 설정 사전 검증, 승인된 AI 모델 목록 관리 기능을 추가해 엔터프라이즈 환경의 보안성과 신뢰성을 강화합니다. 결과적으로 개발자는 반복적인 수동 실행에서 벗어나고, 관리자는 조직에서 실행되는 AI를 통제할 수 있습니다. ## 이벤트 기반 Duo Flows 자동 실행 - 기존 Duo Flow는 사용자가 GitLab UI에서 멘션, 할당, 리뷰어 지정 등을 직접 수행해야 실행할 수 있었습니다. - GitLab 19.1에서는 다음 이벤트를 트리거로 사용할 수 있습니다. - **머지 리퀘스트 코드 충돌 감지**: 충돌 발생 즉시 요약과 해결 제안 실행 - **Draft에서 Ready for review로 변경**: 자동 컴플라이언스 검사나 사전 병합 체크 실행 - **머지 리퀘스트 승인**: 배포 준비 상태 확인, 컴플라이언스 기록, 인수인계 알림 실행 - **Work item 생성**: 자동 분류, 라벨 지정, 담당 팀 라우팅 실행 - 파이프라인 이벤트는 성공, 실패, 취소 등 특정 상태만 필터링할 수 있습니다. - 실패 시 인시던트 생성 - 성공 시 아티팩트 승격 - 취소 시 별도 후속 처리 - 코드 충돌 감지와 Draft→Ready for review 트리거는 기본 활성화됩니다. - 로컬에서 에이전트를 사용할 때는 패턴 기반 승인 기능을 통해 세션 동안 특정 도구 사용을 일괄 승인할 수 있어, 반복적인 파일 수정이나 `npm install` 과정에서 재승인할 필요가 줄어듭니다. ## 승인되지 않은 에이전트와 플로우 차단 - 인스턴스 관리자와 최상위 그룹 소유자는 조직에서 실행 가능한 AI 콘텐츠의 범위를 제한할 수 있습니다. - **Disable custom agents and flows** - 사용자가 사용자 정의 에이전트와 플로우를 생성하거나 활성화하지 못하게 합니다. - 검토된 기본 제공 콘텐츠 중심으로 사용을 제한합니다. - **Restrict the AI catalog to your group hierarchy** - 자신의 네임스페이스 외부에서 제공되는 AI Catalog 항목을 활성화하지 못하게 합니다. - 커뮤니티 및 서드파티 플로우가 보안 검토 없이 도입되는 것을 방지합니다. - 두 설정을 함께 사용하면 AI 활용은 허용하면서도 검증되지 않은 에이전트가 운영 환경에 확산되는 문제를 통제할 수 있습니다. ## 저장 전에 플로우 설정 검증 - 사용자가 AI Catalog의 플로우를 저장하거나 수정하면 GitLab이 Duo Workflow Service를 통해 설정을 검증합니다. - 누락된 입력값이나 알 수 없는 도구 파라미터 같은 오류가 저장 전에 구조화된 형태로 UI에 표시됩니다. - 잘못된 플로우가 운영 중 처음 발견되는 대신, 설정 단계에서 즉시 수정할 수 있습니다. - 자동 트리거는 잘못 구성될 경우 반복 실행과 불필요한 알림을 일으킬 수 있으므로 사전 검증의 중요성이 큽니다. ## 승인된 AI 모델만 사용하도록 제한 - 공개 베타 기능으로 관리자는 조직에서 사용할 수 있는 AI 모델의 allowlist를 설정할 수 있습니다. - 조직 전체의 기본 모델도 지정할 수 있으며, 사용자는 허용된 범위 안에서 모델을 선택할 수 있습니다. - 데이터 레지던시 요건이나 사내 승인 절차를 통과한 제공업체만 사용하도록 제한할 수 있습니다. - 초기 적용 범위는 GitLab Duo Agentic Chat이며, 향후 다른 기능 영역으로 확대될 예정입니다. ## 운영 환경을 위한 AI 자동화 기반 - 이벤트 기반 실행으로 사람이 버튼을 누르지 않아도 반복적인 검토, 분류, 알림, 배포 후속 작업을 수행할 수 있습니다. - 관리자는 실행 가능한 에이전트·플로우·모델을 통제하고, 개발자는 자동화 설정 오류를 운영 장애 전에 발견할 수 있습니다. - 도입 시에는 먼저 승인된 모델과 콘텐츠 범위를 정한 뒤, 실패 파이프라인이나 머지 리퀘스트 준비 완료 같은 명확한 이벤트부터 플로우를 단계적으로 적용하는 것이 좋습니다.

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

AI 에이전트CI/CDgitlabDevSecOps+3

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

취약점 통합 관점: 스캐너 커버리지에서 AI 거버넌스까지

GitLab 19.1은 여러 보안 스캐너의 결과와 적용 범위를 하나의 취약점 화면에서 관리하고, 프로젝트 전체에 스캐너 정책을 강제할 수 있도록 한다. 또한 시크릿 탐지 정확도를 높이고, AI 에이전트의 도구 사용을 승인 절차와 감사 로그로 통제해 자동화와 보안을 함께 확보하는 것이 글의 핵심이다. 궁극적으로 목표는 검증 가능한 스캐너 적용 범위와 통제된 AI 에이전트 자율성이다. ## 서드파티 스캐너 적용 범위의 중앙 관리 - 기업에서는 프로젝트마다 서로 다른 보안 스캐너를 설정하는 경우가 많아, 어떤 프로젝트가 실제로 검사되고 있는지 파악하기 어렵다. - 신규 프로젝트가 스캐너 설정에서 빠지면 몇 주 동안 검사되지 않은 코드가 배포될 수 있다. - GitLab 19.1에서는 **SARIF 형식으로 결과를 출력하는 서드파티 스캐너**를 GitLab 정책에 따라 모든 프로젝트에 적용할 수 있다. - 각 스캐너의 결과는 GitLab의 단일 취약점 화면으로 통합되며, 동일한 정책과 규칙으로 관리된다. - 이를 통해 스캐너 적용 범위를 추정하는 대신 감사나 보고에서 입증할 수 있다. ## 서드파티 취약점의 자동 remediation - 서드파티 스캐너에서 발견한 취약점도 GitLab 네이티브 스캐너 결과와 동일한 자동화 흐름에 포함된다. - **SAST False Positive Detection**이 오탐 가능성을 분류해 실제 위험이 높은 이슈를 우선 처리한다. - **Agentic SAST Vulnerability Resolution**은 수정안을 생성하고 바로 병합할 수 있는 머지 리퀘스트를 자동으로 연다. - 결과적으로 취약점이 프로덕션에 도달하기 전에 자동 수정할 가능성이 높아진다. ## 시크릿 탐지 범위 확대와 오탐 감소 - 기존에는 새 브랜치에서 최신 커밋만 검사했기 때문에, 이전 커밋에 포함된 비밀 정보가 탐지되지 않을 수 있었다. - 이제 새 브랜치의 **모든 커밋을 검사**해 시크릿이 처음 도입된 지점을 놓칠 가능성을 줄인다. - 정식 출시된 **Secret False Positive Detection**은 각 탐지 결과에 신뢰도 점수와 설명을 제공한다. - 테스트용 자격 증명, 예시 토큰, 플레이스홀더 값과 실제 유출된 비밀 정보를 구분하는 데 도움을 준다. - 개발자는 오탐을 정리하는 데 쓰는 시간을 줄이고 실제 자격 증명 노출에 집중할 수 있다. ## AI 에이전트의 도구 사용 통제 - 코딩 에이전트는 머지 리퀘스트 생성, 도구 호출, 코드 커밋 등을 수행할 수 있지만, 승인 후에는 파일 작성·삭제·푸시까지 자동으로 실행할 위험이 있다. - 조직은 에이전트가 행동하기 전에 허용 범위를 정하고, 행동 이후에는 무엇을 했는지 증명할 수 있어야 한다. - 베타 기능인 **Agent tool approval guardrails**를 사용하면 관리자마다 에이전트 도구를 다음처럼 설정할 수 있다. - 자동 실행 - 사람의 승인 후 실행 - 실행 차단 - 파일 작성이나 리소스 삭제처럼 민감한 작업은 담당자의 승인 전까지 보류할 수 있다. ## AI 감사 이벤트와 책임 추적 - 베타 기능인 **AI audit event streaming**은 에이전트의 모든 활동을 감사 이벤트로 기록하고 기존 감사 로그 저장소로 스트리밍한다. - 사람이 승인하거나 거부한 결정도 감사 이벤트로 남는다. - 사고 대응이나 감사 시 에이전트가 언제 어떤 도구를 사용했고, 어떤 변경을 수행했는지 확인할 수 있다. - 이를 통해 에이전트가 완전히 제한되는 것이 아니라, 사전에 정한 경계 안에서 자율적으로 작업하는 **통제된 자율성(governed autonomy)**을 구현한다. ## 실용적인 적용 방향 조직은 먼저 모든 프로젝트에 SARIF 기반 스캐너 정책을 강제해 보안 검사 공백을 제거하고, 통합 취약점 화면에서 결과를 관리하는 것이 좋다. 이후 시크릿 탐지와 오탐 분류를 활성화하고, AI 에이전트에는 파일 삭제·코드 푸시 등 고위험 작업에 사람 승인과 감사 로그를 적용하는 방식이 적절하다.

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

gitlabDevSecOpsvulnerability-managementsast+4

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

GitLab 19.1 릴리스 노트 | GitLab Docs

GitLab 19.1은 GitLab Duo의 보안·거버넌스를 강화하고, 시크릿 탐지와 코드 리뷰 자동화를 개선한 릴리스다. 특히 AI가 시크릿 탐지의 오탐 가능성을 분석하고, 관리자가 Duo 사용과 에이전트 도구 실행을 중앙에서 통제할 수 있게 됐다. 또한 규정 준수 템플릿, Code Owner 자동 리뷰어 지정, 기능 브랜치의 전체 커밋 대상 시크릿 검사 등이 추가됐다. ## GitLab Duo 기반 시크릿 오탐 탐지 - GitLab Duo Agent Platform에서 시크릿 탐지 결과의 오탐 여부를 자동 분석하는 기능이 정식 출시됐다. - 보안 스캔 후 각 **Critical·High 심각도** 시크릿 취약점을 자동으로 분석한다. - 취약점 상세 화면에서 개별 항목을 수동으로 분석할 수도 있다. - 분석 결과는 취약점 리포트에 기존 심각도, 상태, 수정 정보와 함께 표시된다. - 코드 문맥과 취약점 특성을 기반으로 실제 시크릿일 가능성에 대한 AI 설명을 제공한다. - 신뢰도 점수를 통해 보안팀이 검토 우선순위를 정할 수 있다. - 오탐 조사에 드는 시간을 줄이고, 실제 보안 위험에 집중하도록 돕는다. - GitLab Ultimate에서 제공된다. ## GitLab Duo 항상 켜기 설정 - 관리자가 인스턴스 전체 또는 최상위 그룹에서 GitLab Duo를 **Always on**으로 설정할 수 있다. - 항상 켜짐 상태에서는 그룹·하위 그룹·프로젝트 소유자가 Duo를 비활성화할 수 없다. - 기존의 **Always off** 설정과 대칭적인 기능으로, 조직 차원의 AI 사용 정책을 일관되게 적용할 수 있다. - 규제 산업이나 여러 자회사·사업부에서 공통 AI 도구 사용을 보장해야 하는 경우 유용하다. - 인스턴스 또는 최상위 그룹의 GitLab Duo 설정에서 가용성을 Always on으로 지정한다. - Premium 및 Ultimate에서 제공된다. ## Code Owner 자동 리뷰어 지정 - 기존에는 CODEOWNERS 파일이 있어도 머지 리퀘스트마다 리뷰어를 수동 지정해야 했다. - 이제 변경된 파일과 일치하는 모든 Code Owner를 리뷰어로 자동 지정할 수 있다. - 머지 리퀘스트가 준비 상태로 생성되거나, Draft에서 Ready 상태로 전환될 때 동작한다. - 사용자가 이미 리뷰어를 지정했다면 자동 지정은 건너뛰고 기존 선택을 유지한다. - `Settings > Merge requests > Automatic reviewer assignment`에서 활성화할 수 있다. - Premium 및 Ultimate에서 제공된다. ## 규정 준수 프레임워크 템플릿 - Compliance Center에서 사전 정의된 템플릿으로 규정 준수 프레임워크를 생성할 수 있다. - 요구사항과 통제 항목을 일일이 수동 작성하지 않아도 된다. - 템플릿을 미리 보고 이름, 설명, 색상을 수정한 뒤 그룹에 적용할 수 있다. - ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX 등 총 19개 템플릿이 제공된다. - 베타 기능이며 GitLab Ultimate에서 제공된다. ## 기능 브랜치 시크릿 탐지 범위 개선 - 이전 버전에서는 새 브랜치의 최신 커밋만, 기존 브랜치는 가장 최근 푸시만 검사했다. - 과거 커밋에 포함된 자격 증명이 탐지되지 않은 채 공유 브랜치나 운영 환경으로 유입될 수 있었다. - GitLab 19.1부터는 기능 브랜치가 기본 브랜치에서 분기된 시점부터 최신 커밋까지 모든 커밋을 검사한다. - 시크릿이 개발 초기 단계에서 발견되므로 자격 증명 교체와 사고 대응 비용을 줄일 수 있다. - Free, Premium, Ultimate 모든 등급에서 제공된다. ## GitLab Duo 에이전트 도구 승인 가드레일 - 관리자가 Duo 에이전트의 도구별 실행 정책을 설정할 수 있다. - 각 도구에 다음 세 가지 모드 중 하나를 지정한다. - **Allow**: 승인 없이 실행 - **Ask**: 실행 직전에 사용자 승인 필요 - **Deny**: 실행 차단 - 이전에는 프로젝트에서 AI 에이전트를 승인하면 쓰기 작업이나 삭제 같은 민감한 도구도 추가 검토 없이 실행될 수 있었다. - `Ask` 도구가 호출되면 인라인 승인 카드가 표시되고, 사용자가 승인해야 실행된다. - Agentic Chat, IDE, Flows에 적용된다. - 모든 승인·거부 결정은 감사 이벤트로 기록된다. - 베타 기능이며 Premium 및 Ultimate에서 제공된다. ## 사용자 지정 AI 에이전트와 외부 기능 제어 - 관리자와 최상위 그룹 소유자가 조직 내에서 사용할 수 있는 AI 에이전트와 플로우를 통제할 수 있다. - 사용자가 사용자 지정 에이전트와 플로우를 생성하거나 활성화하지 못하도록 제한할 수 있다. - 그룹 계층 외부 프로젝트가 소유한 에이전트와 플로우의 활성화도 차단할 수 있다. - 중앙에서 승인한 AI 자동화만 사용하도록 정책을 적용하고, 신뢰할 수 없는 외부 콘텐츠 노출을 줄일 수 있다. - Premium 및 Ultimate에서 제공된다. ## 사용자 지정 플로우 YAML 사전 검증 - AI Catalog가 사용자 지정 플로우의 YAML 설정을 저장하거나 실행하기 전에 검증한다. - 누락된 입력값, 알 수 없는 도구 매개변수, 문법 오류 등을 UI에서 즉시 확인할 수 있다. - 이전에는 CI 작업이 시작된 뒤 런타임에서 오류가 발생해 디버깅이 늦어질 수 있었다. - 유효한 플로우는 기존처럼 저장하고 실행할 수 있다. - Premium 및 Ultimate에서 제공된다. ## Agentic Chat의 패턴 기반 도구 승인 - 릴리스 노트 후반부에서는 Agentic Chat을 위한 패턴 기반 도구 승인 기능도 소개되기 시작한다. - 제공된 내용에서는 기능의 세부 동작과 정책 설정 방식이 생략되어 있어, 구체적인 요건은 전체 릴리스 노트를 확인해야 한다. 이번 릴리스는 AI 기능을 단순히 확대하는 데 그치지 않고, 조직 차원의 사용 강제, 도구별 승인, 외부 에이전트 제한, 감사 기록을 통해 통제 가능한 AI 운영을 강화한 것이 특징이다. 동시에 기능 브랜치 전체 커밋 검사와 자동 Code Owner 리뷰어 지정으로 개발·보안 workflow의 누락도 줄였으므로, GitLab Duo와 보안 스캔을 사용하는 조직이라면 관련 설정을 검토할 만하다.

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

AI 에이전트CI/CDgitlabyaml+4

figma·2026년 6월 18일·2분 읽기큐레이션 요약

Figma Weave의 Runway Aleph 2.0으로 모든 프레임을 직접 제어하세요 | Figma 블로그

Runway Aleph 2.0이 Figma Weave에 통합되어 영상의 개별 프레임과 장면을 더 정밀하게 지시하고 수정할 수 있게 됐다. 최대 30초 영상에 참조 이미지를 적용하고, 특정 요소만 바꾸면서 나머지는 유지할 수 있다. 사용자는 여러 편집을 단계적으로 조합해 재촬영 없이 새로운 영상 방향을 탐색할 수 있다. ## 프레임 단위의 정밀한 영상 제어 - Aleph 2.0은 영상 전체가 아니라 장면 속 요소와 프레임별 변화를 구체적으로 지시하는 데 초점을 둔다. - 최대 30초 길이의 영상 클립을 지원해 짧은 컷을 넘어 하나의 완결된 장면을 다룰 수 있다. - 참조 이미지를 입력하면 원하는 시각적 스타일이나 분위기를 영상 전반에 적용한다. - 사용자가 변경을 요청하지 않은 배경, 인물, 장면 요소는 최대한 보존한다. - 키프레임 편집은 해당 대상이 등장하는 모든 프레임에 이어져, 움직이는 피사체에도 일관되게 적용된다. ## 단계적으로 구성하는 Weave 워크플로 - Figma Weave의 Aleph 2.0 노드를 사용하면 영상 편집을 하나의 프롬프트가 아닌 여러 결정의 연속으로 구성할 수 있다. - 노드를 연결해 편집 단계를 순차적으로 쌓고, 각 단계의 결과를 미리 확인할 수 있다. - 결과를 확인한 뒤 프롬프트나 편집 방향을 수정하는 반복 작업이 가능하다. - 이는 영상 제작 과정을 Figma에서 디자인 프로젝트를 발전시키는 방식과 유사하게 만든다. - 한 번에 최종 결과를 생성하기보다, 여러 편집을 조합하며 점진적으로 결과물을 완성하는 접근이다. ## 재촬영 없이 장면 확장 - 기존에 촬영한 영상의 한계를 넘어 새로운 연출을 시험할 수 있다. - 카메라 앵글을 변경하거나 새로운 캐릭터를 추가할 수 있다. - 배경이나 환경 전체를 다른 모습으로 변환할 수도 있다. - 동일한 원본에서 여러 방향의 결과물을 나란히 비교하며 아이디어를 발전시킬 수 있다. - 촬영 조건을 다시 마련하지 않고도 모델이 원본 영상을 새로운 장면으로 확장한다. ## 이용 및 비용 관련 안내 - Aleph 2.0은 Figma Weave에서 사용할 수 있다. - 가격은 입력 영상 길이에 따라 조정될 예정이며, 짧은 입력을 사용하는 일부 작업에서는 비용이 낮아질 수 있다. - 시작 방법과 실제 워크플로는 Figma 도움말 센터, 커뮤니티 템플릿 라이브러리, Weavy 지식 센터에서 확인할 수 있다. 실무에서는 원본 영상을 보존한 뒤, 참조 이미지와 편집 목적을 단계별로 나누어 Weave 노드에 구성하는 방식이 효율적이다. 특히 인물·카메라·환경 변경을 각각 분리해 테스트하면 결과를 비교하기 쉽고, 재촬영 전 다양한 연출 가능성을 저비용으로 검증할 수 있다.

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

AIfigma-weavevideo-editingcreative-workflows+2