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

Decagon이 AI를 활용해 디자인 시스템을 포화시키는 방법 | Figma 블로그

Decagon은 빠르게 성장하는 AI 고객지원 플랫폼의 품질과 개발 속도를 함께 확보하기 위해 Deco라는 디자인 시스템을 구축했다. Figma 라이브러리, Storybook, 코딩 에이전트, Figma MCP를 연결해 디자인과 코드가 지속적으로 일치하도록 만들었고, 그 결과 반복적인 해석과 수정 작업을 줄였다. 핵심은 디자인 시스템을 단순한 컴포넌트 모음이 아니라 사람과 AI 에이전트가 함께 사용하는 공통 언어로 만든 데 있다. ## 빠른 성장에 대응하는 디자인 시스템 구축 - Decagon은 초기에는 디자인 시스템 없이 빠르게 제품을 개발했지만, 플랫폼과 팀이 커지면서 화면 간 불일치와 완성도 저하가 나타났다. - 기업 고객을 대상으로 제품을 제공하기 위해서는 일관된 UI와 높은 품질이 필요했으며, 디자인과 개발 사이의 반복적인 수정 작업도 줄여야 했다. - 디자이너와 엔지니어가 처음부터 함께 Deco를 설계해 다음과 같은 세부 사항을 미리 정의했다. - 포커스 상태 - 비활성화, 읽기 전용, 오류, 경고 상태 - 플레이스홀더 사용 여부 - 기존 코드에 이미 존재하는 컴포넌트와의 관계 - 현재 Deco는 수백 개의 컴포넌트·스타일·변수를 포함하며, 여러 팀과 제품 영역의 대부분의 사용 사례를 다룬다. - Figma 라이브러리에서 30일 동안 수만 건의 컴포넌트 삽입이 발생해 조직 전반에서 실제로 활용되고 있음을 확인했다. ## 디자인 시스템이 만든 공통 언어 - 디자이너는 기존 컴포넌트로 화면을 조합할 수 있어 매번 UI를 처음부터 만들 필요가 없어졌다. - 개발자는 어떤 버튼이나 테이블을 사용해야 하는지 명확히 알 수 있어 구현상의 판단과 논쟁이 줄었다. - 디자인과 코드가 동일한 프리미티브를 기준으로 소통하면서 제품 흐름과 요구사항을 설명하기 쉬워졌다. - Deco는 조직 전체에 공개된 단일 진실 공급원(single source of truth)으로 작동해 빠른 출시와 일관된 디자인을 동시에 지원한다. ## 디자인과 코드 사이의 반복 작업 줄이기 - 기존 방식에서는 디자이너가 명세를 전달하면 개발자가 해석하고, 리뷰 단계에서 불일치를 발견한 뒤 다시 수정하는 과정이 반복됐다. - 코딩 에이전트는 개발자처럼 암묵적인 의도를 추론하지 않고 제공된 정보만 바탕으로 작업하므로, 디자인 파일과 명세가 불명확하거나 일관되지 않으면 결과물도 부정확해진다. - Decagon은 디자인 시스템 컴포넌트를 Storybook으로 옮겨 코드에서도 동일한 컴포넌트를 확인할 수 있게 했다. - 코딩 에이전트가 구현할 때 정확한 Deco 컴포넌트를 사용하도록 별도의 skill을 만들었다. - 디자이너가 새로운 컴포넌트를 추가할 때 사용하는 skill도 구축해 Figma와 코드의 동기화를 유지했다. ## Figma MCP를 통한 에이전트 활용 - Figma MCP를 사용하면 코딩 에이전트가 Figma의 디자인 문맥과 명세를 직접 읽을 수 있다. - 디자이너는 Figma 링크를 코딩 에이전트에 전달하는 것만으로 다음 작업을 수행할 수 있다. - 디자인의 구조와 세부 명세 파악 - Deco의 적합한 컴포넌트와 매핑 - 디자인에 가까운 고충실도 구현 생성 - 디자인 캔버스, 코드, 컴포넌트 명세가 하나의 작업 흐름으로 연결되어 파일을 내보내고 다시 해석하는 수동 왕복이 줄었다. - 에이전트가 기존 디자인 시스템을 활용하므로 빠른 프로토타이핑과 반복 수정이 가능하면서도 브랜드와 UI 일관성을 유지할 수 있다. ## 실용적인 결론 AI 코딩 도구를 도입할 때는 에이전트의 성능만 높이기보다, 먼저 재사용 가능한 디자인 시스템과 명확한 컴포넌트 문맥을 마련해야 한다. Figma와 Storybook을 연결하고, MCP와 에이전트 skill을 통해 동일한 컴포넌트를 사용하게 하면 디자인-개발 간 불일치를 줄이면서 빠른 개발 속도와 품질을 함께 확보할 수 있다.

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

AI 에이전트Figma디자인 시스템design-to-code+2

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

GitHub 에이전틱 워크플로로 리포지토리 간 문서화 자동화

Aspire 팀은 GitHub Agentic Workflows를 활용해 제품 코드 저장소와 문서 저장소가 분리된 환경에서도 기능 변경 직후 문서 PR을 자동 생성하는 시스템을 구축했다. 에이전트가 변경 사항과 이슈를 분석해 문서를 작성하지만, 실제 쓰기 작업은 제한된 별도 핸들러가 수행하도록 분리해 보안을 확보했다. 그 결과 Aspire 13.3·13.4에서 82개의 문서 PR이 제품 PR 병합 후 중앙값 44.8시간 내 생성됐고, 모두 해당 기능을 구현한 엔지니어의 검토를 받았다. ## 교차 저장소 문서화가 어려운 이유 - 제품 코드는 `microsoft/aspire`, 문서 사이트는 `microsoft/aspire.dev`에 있어 저장소와 배포 대상, 리뷰 절차가 분리되어 있다. - 기존 방식은 문서 작성자가 몇 주 뒤 닫힌 PR을 찾아 변경 내용을 역추적하는 구조였다. - 기능 작성자는 이미 다음 작업으로 넘어간 상태라 문서 작성에 필요한 맥락을 충분히 제공하기 어려웠다. - 저장소 전체에 쓰기 권한을 가진 광범위한 토큰은 보안상 부적절하므로, 단순한 크로스 리포지토리 자동화도 권한 설계가 병목이 된다. ## GitHub Agentic Workflows의 구조 - 워크플로를 YAML 대신 하나의 Markdown 파일로 작성한다. - YAML 형식의 frontmatter에 설정을 작성한다. - 아래에는 에이전트가 수행할 작업을 자연어 프롬프트로 작성한다. - 컴파일하면 일반 GitHub Actions 워크플로인 `.lock.yml` 파일이 생성된다. - 실행 시 에이전트는 제한된 도구와 프롬프트를 바탕으로 변경 사항을 분석한다. - 에이전트가 GitHub에 직접 쓰지 않는 점이 핵심이다. - 에이전트는 생성하려는 PR, 이슈, 댓글을 JSON 형태의 의도로 출력한다. - 별도의 `safe-outputs handler`가 허용된 작업만 실제로 실행한다. - 저장소와 작업 종류를 명시적으로 제한할 수 있어 보안 검토와 자동화의 균형을 맞춘다. ## 기능 PR에서 문서 PR로 이어지는 자동화 흐름 - `microsoft/aspire`의 `main` 또는 `release/*` 브랜치에 병합된 PR을 `pull_request: closed` 이벤트로 감지한다. - `merged == true` 조건을 적용해 실제 병합된 PR만 처리한다. - 에이전트가 실행되기 전에 Bash 기반의 결정론적 로직으로 문서 대상 브랜치를 결정한다. 1. 제품 PR의 마일스톤 제목을 확인한다. 예를 들어 `13.4`는 문서 저장소의 `release/13.4`로 매핑된다. 2. PR 본문에서 `Fixes`, `Closes`, `Resolves`로 연결된 이슈를 찾고, 해당 이슈의 첫 번째 비어 있지 않은 마일스톤을 확인한다. 3. PR의 base ref가 `release/X.Y` 또는 `release/X.Y.Z` 형식이면 이를 사용한다. 4. 어느 조건에도 해당하지 않으면 `main`을 사용한다. - 마일스톤과 문서 브랜치를 명확히 매핑해 에이전트가 대상 브랜치를 추측하지 않도록 한다. - 에이전트는 제품 diff와 연결된 이슈를 읽고 문서화가 필요한 변경인지 판단한다. - 문서가 필요하면 체크아웃된 `microsoft/aspire.dev` 작업 공간에 기존 문서 작성 규칙에 맞춰 초안을 작성한다. - 문서의 문체 - MDX 규칙 - Astro Starlight 컴포넌트 사용법 - 이후 `create_pull_request` safe output을 생성해 문서 PR 생성을 요청한다. ## 제한된 권한으로 PR 생성하기 - safe-outputs 핸들러는 실제 PR 생성 시 다음 제약을 적용한다. - PR 제목에 `[docs]` 접두사 사용 - `docs-from-code` 라벨 부착 - 자동 병합 없이 항상 draft PR로 생성 - base 브랜치는 `main` 또는 `release/*`로 제한 - 대상 저장소는 `microsoft/aspire.dev`로 고정 - 제품 PR의 리뷰 기록에서 해당 기능을 승인한 SME를 찾아 문서 PR 리뷰어로 요청한다. - 문서 리뷰가 기능 구현자의 맥락과 분리되지 않도록, 실제 기능을 승인한 사람이 문서도 검토하게 한다. - 별도 작업은 원본 제품 PR에 문서 PR 링크를 댓글로 남긴다. - 재실행 시 이전 `pr-docs-check` 댓글을 최소화해 중복 알림을 줄인다. - 기능을 병합한 엔지니어는 몇 분 안에 문서 초안을 확인할 수 있다. ## 보안 설계와 safe-outputs 계약 - GitHub 도구 세트를 `repos`, `issues`, `pull_requests` 등 필요한 범위로 제한한다. - `min-integrity: approved` 설정으로 무결성이 검증된 작업만 실행하도록 한다. - 허용 저장소를 `microsoft/*`처럼 제한할 수 있다. - 전용 GitHub App의 App ID와 private key를 사용해 일반적인 광범위 토큰 대신 작업별 권한을 부여한다. - App이 접근할 수 있는 저장소도 `aspire.dev`, `aspire`로 한정한다. - 에이전트의 분석 권한과 실제 변경 권한을 분리해, 에이전트가 임의로 저장소에 쓰거나 병합하지 못하게 한다. - 최종 문서 반영은 여전히 draft PR과 사람의 리뷰를 거친다. ## 측정된 결과 - Aspire 13.3과 13.4에서 문서 기능 PR 82개가 병합됐다. - 문서 PR은 제품 PR 병합 후 중앙값 44.8시간 뒤에 생성됐다. - 모든 문서 PR을 해당 기능을 구현한 엔지니어가 검토했다. - 별도의 인력 충원이나 새로운 프로세스 교육 없이 운영됐다. - 문서 작성 시점이 기능 출시 후 수 주가 아니라 기능 병합 직후로 앞당겨졌다. 기능 저장소와 문서 저장소가 분리되어 있다면, 에이전트에게 광범위한 쓰기 권한을 주기보다 **결정론적인 브랜치 선택 로직, 제한된 safe outputs, 초안 PR, 담당 엔지니어 리뷰**를 결합하는 방식이 실용적이다. AI가 문서를 작성하더라도 최종 병합은 사람이 담당하도록 설계하는 것이 안전성과 문서 품질을 함께 확보하는 방법이다.

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

AI 에이전트GitHub Actionsastrogithub-agentic-workflows+3

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

AI 에이전트를 활용해 GitLab의 레이트 리미팅을 마이그레이션한 방법

GitLab은 3명의 엔지니어와 AI 에이전트를 활용해 레거시 애플리케이션·Rack 기반 레이트 리미팅을 `labkit-ruby` 단일 구현으로 통합했다. 에이전트는 코드 탐색, 사양 작성, 반복적인 구현과 테스트에는 효과적이었지만, 아키텍처 결정·점진적 롤아웃·관측성 설계·최종 판단은 여전히 사람의 책임이었다. 프로젝트의 성공을 결정한 것은 에이전트 자체보다 명확한 작업 루프, 작은 변경 단위, 점진적 배포, 그리고 실패를 되돌릴 수 있는 운영 체계였다. ## 레거시 레이트 리미팅 통합의 목표 - GitLab에는 다음 두 가지 레이트 리미팅 경로가 수년간 공존했다. - 애플리케이션 수준의 `Gitlab::ApplicationRateLimiter` - Rack 수준의 별도 레이트 리미터 - 목표는 두 시스템을 `labkit-ruby`의 단일 구현으로 통합하는 것이었다. - 새로운 구현은 다음 조건을 만족해야 했다. - 모든 요청에 적용될 만큼 안정적일 것 - 동작을 관측하고 테스트할 수 있을 것 - 장애 발생 시 되돌릴 수 있을 것 - 모놀리스와 다른 환경에서 동일하게 운영할 수 있을 것 - 기존 시스템에는 121개의 레이트 리미팅 키가 존재했다. ## 3명으로 구성된 포드와 AI 에이전트의 역할 - 포드는 세 명의 GitLab 엔지니어를 중심으로 구성됐다. - 모놀리스 측 구현과 롤아웃 담당 - `labkit-ruby`와 아키텍처 담당 - 범위 관리와 초기 gem 코드 작성 담당 - AI 에이전트는 다음 작업을 수행했다. - 코드와 기존 맥락 분석 - 기술 사양 초안 작성 - 범위가 제한된 변경 구현 - 테스트 작성 - 머지 리퀘스트 사전 검토 - GitLab Duo Code Review도 머지 리퀘스트의 품질 검토에 활용됐다. - 사람은 다음을 직접 맡았다. - 작업 범위 결정 - 아키텍처 설계 - 배포 및 롤아웃 판단 - 최종 리뷰와 승인 ## 사양-구현-검증 반복 루프 - 팀은 다음과 같은 엄격한 순서를 적용했다. 1. 에픽과 기존 코드 읽기 2. 사양 작성 3. 적대적 리뷰로 사양의 문제점 검토 4. 차단 이슈가 해결된 뒤 구현 5. 명시적인 증거를 바탕으로 검증 6. 머지 리퀘스트에 대한 적대적 리뷰 7. 필요 시 사람에게 에스컬레이션 8. 머지 - 적대적 리뷰는 최대 두 번의 해결 라운드까지만 허용하고, 이후에는 사람의 판단을 받도록 했다. - 프로젝트에서는 14개의 번호가 매겨진 사양과 30개가 넘는 `labkit-ruby` 머지 리퀘스트가 만들어졌다. - 레거시 코드처럼 맥락 파악과 반복 검증이 중요한 작업에서는 이처럼 제한된 루프가 에이전트 활용에 적합했다. ## 단계적 롤아웃과 에이전트가 잘한 작업 - 첫 번째 코호트에서는 트래픽이 많은 5개 키를 다뤘다. - `pipelines_create` - `notes_create` - `user_sign_in` - 그 외 주요 키 - 트래픽 비율을 `1% → 10% → 50% → 100%`로 단계적으로 높였고, 2026년 5월 5일 100% 배포를 완료했다. - 기존 `ApplicationRateLimiter`와 새 구현의 결과가 일치하는지 확인했지만, 단순히 불일치가 없다는 사실만으로 성공을 판단하지 않았다. - 실제로 제한에 걸릴 정도의 트래픽이 발생하지 않았을 가능성도 있기 때문이다. - 두 번째 코호트에서는 모놀리스 83개와 EE 12개를 포함한 95개 호출 지점을 두 개의 기능 플래그로 통합했다. - 이 작업을 수작업으로 했다면 약 95개의 플래그 변경과 190개의 YAML 수정이 필요했을 수 있지만, 에이전트는 이런 반복적인 코드베이스 전반의 변경에 특히 강했다. ## 관측성은 있었지만 실패 유형을 구분하지 못함 - 두 번째 코호트는 며칠간 섀도 모드에서 기존 구현과 비교되었고, 대체로 일치했다. - 그러나 강제 적용 모드로 전환한 뒤 인증되지 않은 일부 경로에서 식별자가 조용히 유실되는 문제가 발생했다. - 원인은 세 개의 `String` 값이 두 개의 원시 슬롯에 압축되면서 잘못된 값이 식별자를 덮어쓴 구조적 충돌이었다. - 일부 사용자는 짧은 시간 동안 일반적인 오류 메시지를 받았다. - 비교 시스템은 해당 키의 불일치를 이미 감지했지만, 대시보드가 다음을 구분하지 못했다. - 정상적인 동작 차이 - 데이터 구조 충돌 - 사용자에게 영향을 줄 수 있는 치명적 불일치 - 팀은 즉시 강제 적용 플래그를 끄고, 이틀 뒤 긴급 수정 사항을 배포했다. - 문제는 사양, 적대적 리뷰, 구현, 코드 리뷰, 점진적 롤아웃을 모두 통과했으므로, 단순히 “에이전트가 위험하다”기보다는 관측성이 충분히 세분화되지 않았던 것이 핵심 교훈이었다. ## 전체 키 인벤토리 관리의 실패 - 처음에는 다섯 개 코호트로 마이그레이션을 끝낼 계획이었다. - 마스터 브랜치 감사 과정에서 누락된 항목이 발견되어 여섯 번째 코호트를 추가했다. - Claude가 놓친 항목에는 다음이 포함됐다. - EE 전용 `notification_emails` - 일부 EE 레지스트리 항목 - 웹훅 관련 키 3개 - 1초 미만 주기의 `partner_*` 키 3개 - 고립된 어댑터 행 - 총 121개 키 중 17개가 초기 코호트에서 빠져 있었다. - 각 항목이 특정 코호트에 쉽게 들어가지 않는 이유는 있었지만, 목록에서 보이지 않아도 될 이유는 없었다. - 근본적인 실수는 에이전트와 사람이 전체 키 인벤토리 대비 진행 상황을 지속적으로 집계하도록 요구하지 않았다는 점이다. ## Redis 인프라 병목과 운영 판단 - `redis-cluster-ratelimiting`은 4개 샤드 클러스터로 운영됐다. - 마이그레이션으로 사용량이 증가하면서 기존에 알려져 있던 인프라 병목이 다시 나타났다. - 팀은 `maxclients`를 단계적으로 높였지만, 연결 수를 100,000까지 밀어붙이지 않고 75,000에서 중단했다. - 더 많은 연결을 허용하면 각 프라이머리의 CPU가 포화될 수 있었기 때문이다. - 각 샤드는 명령 실행에 하나의 코어를 사용했고, 수직 확장으로 해결할 여지도 제한적이었다. - 따라서 에이전트가 코드를 생성하더라도, 실제 배포 속도와 범위는 인프라 용량과 운영자의 판단에 의해 결정됐다. ## AI 에이전트가 바꾼 병목 - 에이전트 덕분에 코드 작성 자체는 더 이상 가장 느린 단계가 아니었다. - 대신 병목이 다음 영역으로 이동했다. - 사람의 리뷰 처리 용량 - 롤아웃 시점과 범위에 대한 판단 - 운영 중인 시스템을 주의 깊게 관찰하는 능력 - 에이전트는 요청하면 95개의 기능 플래그 같은 반복 작업도 만들어내지만, 그런 설계가 실제로 필요한지는 판단하지 못한다. - 예를 들어 코호트 1 이후 팀은 레이트 리미트마다 별도 기능 플래그를 두는 방식이 과도하다고 판단해 이후 마이그레이션에서는 적용하지 않기로 했다. - 에이전트와 협업하는 방법 자체도 학습이 필요했으며, 때로는 에이전트와 반복적으로 막혀 직접 처리하는 편이 빠르다고 느끼는 순간도 있었다. ## 최종 상태와 실용적인 교훈 - 2026년 6월 중순 기준으로 여섯 개 코호트가 모두 100% 롤아웃됐다. - `ApplicationRateLimiter`의 121개 키가 새 프레임워크를 통해 동작하게 되었고, 감사로 결과를 확인했다. - 이 사례에서 권장할 만한 방식은 다음과 같다. - 에이전트에는 반복적이고 범위가 명확한 변경을 맡긴다. - 아키텍처, 위험 허용 수준, 배포 중단 기준은 사람이 결정한다. - 전체 마이그레이션 대상을 인벤토리로 관리하고 누락 여부를 자동 검증한다. - 단순한 불일치 감지를 넘어 실패 원인과 심각도를 구분하는 관측성을 구축한다. - 기능 플래그와 점진적 롤아웃으로 즉시 되돌릴 수 있게 한다. - 코드 생성 속도가 빨라져도 리뷰와 운영 관찰에 필요한 사람의 시간을 충분히 확보한다.

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

AI 에이전트옵저버빌리티gitlab-duo-agent-platformredis+4

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

수익화 게이트웨이 출시: x402를 통해 Cloudflare 뒤의 모든 리소스에 요금 부과

Cloudflare는 웹 페이지·데이터셋·API·MCP 도구 등 Cloudflare 뒤의 모든 리소스에 사용량 기반 요금을 부과할 수 있는 Monetization Gateway를 발표했다. 이 게이트웨이는 결제 규칙, 결제 검증, 접근 제어를 엣지에서 처리하며, 출시 시 x402와 스테이블코인을 사용한다. 이를 통해 에이전트가 계정이나 구독 없이 요청 단위로 소액 결제하고, 서비스 제공자는 별도의 결제·정산 시스템 없이 리소스를 수익화할 수 있다. ## 에이전트 중심으로 바뀌는 웹의 수익 모델 - 기존 웹은 콘텐츠를 인간의 관심과 교환하고, 광고·구독·전자상거래로 수익을 창출했다. - AI 에이전트는 광고를 보거나 장기 구독을 유지하기보다, 필요한 페이지·데이터·도구를 한 번 사용하고 이동한다. - AI 크롤러는 방문자를 보내는 횟수보다 훨씬 많은 요청을 발생시킬 수 있어, 기존 광고 모델과 맞지 않는다. - 에이전트 경제에서는 다음과 같은 사용량 기반 과금이 적합하다. - 검색 1회당 수 센트 - 업로드 기본 요금 0.001달러와 MB당 0.01달러 - 성공적으로 해결된 지원 요청 1건당 0.99달러 - 소프트웨어의 자연스러운 과금 단위는 사용자 좌석이나 월 구독이 아니라 요청, 토큰, 작업 결과가 된다. ## 기존 사용량 과금의 한계 - 클라우드와 API는 호출량·사용 시간 기준으로 판매되어 왔지만, 일반적으로 사전에 등록한 고객과 API 키가 필요했다. - 콘텐츠 서비스는 주로 광고에 의존했기 때문에, 신원 확인이 되지 않은 구매자의 초소액 결제를 처리하기 어려웠다. - 결제 수수료와 정산 지연 때문에 결제 금액이 너무 작으면 결제 자체가 더 비싸지는 문제가 있었다. - 사업자는 사용량을 정확하고 감사 가능하게 기록하기 위해 자체 회계·청구 시스템을 구축해야 했다. - 이러한 복잡성 때문에 많은 기업이 구현하기 쉬운 좌석 기반 가격제를 선택했다. ## 스테이블코인과 에이전트 결제 - 에이전트는 한 사람이 처리할 수 없는 수준으로 지속적으로 작업하며, 수천 건의 소액 결제를 자동으로 수행할 수 있다. - 사람이 각 결제를 승인해야 하는 기존 방식은 에이전트 사용 패턴과 맞지 않는다. - Open USD, USDC 같은 스테이블코인은 매우 작은 금액을 낮은 수수료로 전송하고, 1초 이내에 정산할 수 있다. - 따라서 에이전트 환경에서는 소액·고빈도 결제와 사용량 기반 가격제가 적합하다. ## x402의 HTTP 기반 결제 흐름 - x402는 HTTP 상태 코드 `402 Payment Required`를 활용하는 개방형 결제 프로토콜이다. - 기본 흐름은 다음과 같다. - 클라이언트가 결제 보호 리소스를 요청한다. - 서버가 `402` 응답과 함께 가격, 허용 자산, 결제 주소를 전달한다. - 클라이언트가 결제한 뒤 결제 증명을 포함해 요청을 재전송한다. - 퍼실리테이터가 결제를 검증하면 서버가 리소스를 반환한다. - 결제는 별도의 결제 페이지나 API 호출 없이 일반적인 HTTP 요청·응답 안에서 처리된다. - 구매자의 결제 금액은 판매자의 지갑으로 직접 정산되는 P2P 구조다. - 판매자 계정이 없어도 결제 자체가 접근 자격 증명이 되므로, 구매자 온보딩이 필요 없다. - 프로토콜 오버헤드가 작아 1센트 미만의 결제도 가능하며, 스테이블코인과 결합하면 낮은 수수료와 빠른 정산을 기대할 수 있다. ## Monetization Gateway의 역할 - Cloudflare는 결제 정책과 접근 제어를 하나의 컨트롤 플레인에서 관리하도록 지원한다. - 서비스 제공자는 어떤 요청에 결제를 요구할지 Cloudflare 규칙 표현식으로 정의할 수 있다. - 토큰, API, MCP 호출, 데이터 등 기존 Cloudflare 경로를 통과하는 트래픽에 대해 선택적으로 과금할 수 있다. - 결제 검증과 집행은 원본 서버가 아니라 Cloudflare 엣지에서 처리된다. - Cloudflare의 330개 이상 도시에 분산된 네트워크에서 x402 핸드셰이크가 수행되므로 구매자와 가까운 위치에서 처리할 수 있고, 원본 서버의 부하와 지연도 줄일 수 있다. - 계획된 기능에는 다음이 포함된다. - 특정 REST 경로와 HTTP 메서드별 과금 - 예를 들어 `/api/premium/*`의 GET·POST 요청마다 0.01달러 부과 - 작업의 특성에 따른 변동 가격 설정 ## 서비스 제공자에게 주는 이점 - 제공자가 직접 구매자를 등록하거나 API 키·청구 시스템을 운영할 필요가 없다. - 사용량 측정, 결제 교환, 정산이 원본 서버에서 분리된다. - 제공자는 가격, 결제 조건, 접근 규칙, 수익에 집중할 수 있다. - Cloudflare는 기존에 자체 청구 및 고객 분석을 위해 구축한 사용량 회계 역량을 웹 리소스에 적용하려 한다. 실용적으로는 API·데이터·MCP 도구처럼 요청 단위 가치가 분명한 리소스부터 x402 기반 과금을 적용하는 방식이 적합하다. 다만 실제 도입 시에는 스테이블코인 지원 범위, 환불·분쟁 처리, 가격 변동성, 규제 및 회계 처리를 별도로 검토해야 한다.

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

AI 에이전트모델 컨텍스트 프로토콜cloudflareAPI+4

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

내 사이트, 내 규칙: 모든 고객을 위한 새로운 AI 트래픽 옵션

AI 트래픽은 더 이상 “차단할 것인가, 허용할 것인가”의 단순한 문제가 아니며, 웹사이트 운영자는 봇의 목적에 따라 접근을 세분화해 관리해야 한다는 글입니다. Cloudflare는 AI 트래픽을 **검색(Search), 에이전트(Agent), 학습(Training)**으로 분류하고, 각 유형을 개별적으로 허용하거나 차단할 수 있는 기능을 모든 고객에게 제공합니다. 특히 광고가 표시되는 페이지에서는 2026년 9월 15일부터 학습·에이전트 봇은 기본 차단하고, 검색 봇은 기본 허용할 예정입니다. ## AI 봇을 일괄 차단하기 어려운 이유 - 기존에는 AI 기업이 콘텐츠를 학습에 사용하면서도 웹사이트에 방문자나 보상을 돌려주지 않는 문제가 컸습니다. - 이에 Cloudflare는 2025년부터 다음과 같은 대응책을 제공했습니다. - 한 번의 설정으로 AI 봇을 차단하는 **“Block AI Bots”** - 크롤링 건별로 콘텐츠 사용료를 받는 **Pay-Per-Crawl** 마켓플레이스 - 그러나 모든 자동화 트래픽을 차단하면 소규모 사이트는 검색 결과에서 발견될 기회까지 잃을 수 있습니다. - 검색 노출을 얻기 위해 AI 학습까지 허용해야 하는 상황은 대형 검색 사업자에게 유리한 구조를 만들고, 신규 사업자가 봇의 정체를 숨기도록 유도할 수 있습니다. ## AI 대신 봇의 행동을 기준으로 분류 - AI 기술의 범위는 빠르게 변하므로, 봇을 단순히 “AI 봇”인지 아닌지로 구분하는 방식은 오래 유지되기 어렵습니다. - 대신 다음 질문을 기준으로 봇을 평가합니다. - 사이트에서 무엇을 하는가? - 콘텐츠를 어디에 저장하는가? - 나중에 콘텐츠를 어떻게 재공유하는가? - 하나의 봇이 여러 목적을 수행한다면 대표 목적 하나만 기록하지 않고, **모든 목적을 함께 추적**하는 방향을 채택합니다. ## 검색·에이전트·학습의 3가지 분류 ### 검색(Search) - 사이트 콘텐츠를 수집하거나 색인해 나중에 질문에 답하는 데 사용하는 자동화입니다. - 검색 엔진이나 AI 답변 엔진이 사이트 데이터를 미리 데이터베이스화하는 행위가 해당됩니다. - 사이트 운영자는 검색 유입이나 그에 상응하는 보상을 기대할 수 있습니다. - Google 검색처럼 결과 페이지에서 직접 답변을 제공하는 서비스도 이 범주와 관련됩니다. ### 에이전트(Agent) - 사용자를 대신해 실시간으로 작업을 수행하는 자동화입니다. - 예시: - ChatGPT-User 같은 채팅 기반 가져오기 봇 - Gemini 또는 Claude가 브라우저를 조작하는 브라우저 에이전트 - 일반적으로 사람이 요청한 작업을 완료하기 위해 웹 애플리케이션을 방문합니다. - 콘텐츠를 장기적으로 학습하기보다는 특정 시점에 필요한 정보를 조회하거나 거래를 수행하는 것이 핵심입니다. ### 학습(Training) - 콘텐츠를 모델 학습이나 파인튜닝에 사용하기 위해 수집하는 크롤러입니다. - 사이트 데이터가 AI 모델의 내부 구조에 영구적으로 흡수되어 모델의 능력을 개선하는 것이 특징입니다. - 검색처럼 방문자를 되돌려 보내는 목적이 명확하지 않기 때문에, 사이트 운영자가 별도로 차단하거나 보상을 요구할 수 있어야 합니다. ## 목적별로 분리된 크롤러의 필요성 - 하나의 기업이 검색 색인 구축, 사용자 대신 작업 수행, 모델 학습을 모두 한다면 각 목적에 맞는 크롤러를 분리하는 것이 권장됩니다. - 크롤러를 분리하면 사이트 운영자가 다음을 더 명확히 파악할 수 있습니다. - 어떤 이유로 방문했는지 - 어떤 콘텐츠 접근 권한이 필요한지 - 검색은 허용하면서 학습은 차단할 수 있는지 - 일부 크롤러는 여러 목적을 동시에 수행할 수 있으며, Googlebot·Applebot·BingBot처럼 검색과 학습 목적이 결합된 봇이 그 예입니다. ## Cloudflare의 새로운 AI 트래픽 관리 옵션 - Cloudflare는 기존의 일괄적인 **“Block AI Bots”** 설정을 세분화합니다. - 모든 요금제, 무료 요금제를 포함한 고객이 다음 유형을 각각 관리할 수 있습니다. - Search 크롤러 - Agent 크롤러 - Training 크롤러 - 이를 통해 사이트 운영자는 다음과 같은 정책을 설정할 수 있습니다. - 검색 봇은 허용하고 학습 봇은 차단 - 에이전트 접근은 허용하되 특정 콘텐츠에서는 제한 - 모든 유형을 허용하거나 차단 - Cloudflare는 광고 검증, 피드 수집, 에이전트 기반 거래 등 다른 자동화 유형도 분류하고 있지만, 이번 변경의 중심은 세 가지 AI 사용 사례입니다. ## 2026년 9월 15일부터 적용되는 기본값 - 새로 Cloudflare에 등록되는 도메인의 광고 표시 페이지에는 다음 기본 정책이 적용됩니다. - **Training:** 기본 차단 - **Agent:** 기본 차단 - **Search:** 기본 허용 - 광고는 사람이 페이지를 방문해 콘텐츠를 보고 관심을 갖는 것을 전제로 하는 수익 신호입니다. - 따라서 광고 페이지에서는 사람의 관심을 방해하거나 콘텐츠를 재사용할 수 있는 학습·에이전트 봇을 차단하고, 방문자를 유도할 가능성이 높은 검색 봇은 허용한다는 논리입니다. - 여러 목적을 가진 크롤러는 모든 목적에 대한 규칙을 적용받으며, 가장 제한적인 규칙이 우선합니다. - 따라서 Training을 차단한 고객은 검색과 학습을 함께 수행하는 Googlebot, Applebot, BingBot도 차단될 수 있습니다. - 운영자는 9월 15일 이전에 Cloudflare 보안 설정에서 새 기본값을 적용하지 않도록 선택할 수 있습니다. 사이트 운영자는 모든 AI 자동화를 일괄 차단하기보다 검색·에이전트·학습 목적을 구분해 정책을 설정하는 것이 좋습니다. 특히 검색 유입이 중요한 사이트는 Search를 허용하되 Training과 Agent를 별도로 차단하고, Googlebot처럼 다목적 봇이 어떤 규칙을 적용받는지 사전에 점검해야 합니다.

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

AI 에이전트cloudflarebot-managementweb-crawlers+3

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

스킬이 있으신가요? Figma Agent를 더 나은 협업자로 만들기 | Figma 블로그

Figma의 “스킬”은 팀의 업무 방식과 전문 지식을 자연어 지침으로 저장해 두고, `/` 명령으로 Figma 에이전트에서 반복 사용할 수 있게 하는 기능이다. 디자인 시스템이 컴포넌트와 UI 패턴을 제공한다면, 스킬은 브랜드 문체·접근성·리뷰 절차·개인별 피드백 방식 같은 조직의 맥락을 더한다. Figma는 이를 통해 에이전트를 단순한 생성 도구가 아니라 팀의 작업 방식을 이해하고 협업하는 파트너로 활용할 수 있다고 설명한다. ## 스킬과 디자인 시스템의 역할 구분 - 디자인 시스템은 에이전트가 사용할 컴포넌트, 패턴, UI 요소를 제공한다. - 스킬은 그 위에 팀의 전문 지식과 업무 규칙을 적용한다. - 적용할 수 있는 예시는 다음과 같다. - 브랜드 보이스와 UX 라이팅 규칙 - 컴플라이언스 및 접근성 기준 - 디자인 리뷰 절차 - 제품 원칙과 의사결정 기준 - 디자인 시스템을 특정 업무 흐름 안에서 호출하는 방법 - 한 번 만든 스킬은 팀이나 조직에 게시해 여러 사람이 반복 사용할 수 있다. ## 필요할 때 받는 두 번째 의견 스킬은 특정 관점으로 디자인이나 문구를 검토해 아이디어의 약점을 찾고 더 나은 질문을 하도록 돕는다. - **이해관계자의 피드백 방식 모사** - 공개 코멘트, 과거 크리틱, 파일에 남은 메모 등을 예시로 제공한다. - 에이전트가 특정 인물의 피드백 스타일을 적용하도록 만들 수 있다. - Figma는 CEO Dylan의 코멘트 방식을 반영해, 공식 리뷰 전에 작업을 점검하는 스킬을 만들었다. - **UX 라이팅 기준 적용** - 스타일 가이드에 따라 대문자 사용, 구두점 등 문구의 일관성을 1차 검토한다. - 작성자는 단순한 형식 오류보다 더 중요한 내용과 메시지에 집중할 수 있다. - **처음 사용하는 사람의 관점 제공** - 제품을 잘 아는 디자이너가 놓치기 쉬운 마찰 지점과 부족한 설명을 찾는다. - 신규 사용자가 경험을 이해할 수 있는지 점검하는 데 유용하다. ## 한 번 만들고 반복해서 사용하는 업무 팀이 매번 비슷한 방식으로 수행하는 의식이나 절차는 스킬로 만들 가치가 있다. - **`/catch-me-up`** - 파일이나 프로젝트의 최근 활동을 요약한다. - 한동안 자리를 비운 사람이 댓글과 변경 내역을 직접 추적하지 않고 빠르게 상황을 파악할 수 있다. - **크리틱 준비 체크리스트** - 에이전트가 페르소나, 작업 범위, 크리틱 참석자 등 프로젝트 맥락을 질문한다. - 수집한 정보를 바탕으로 크리틱 페이지와 토론용 질문을 만든다. - Figma의 스킬은 Nielsen Norman Group의 모범 사례를 참고해 더 깊은 논의를 유도하는 질문을 구성한다. - **크리틱 회고** - 회의에서 나온 피드백을 주제별로 정리한다. - 결정 사항, 후속 작업, 보류된 항목을 구분해 실행 계획으로 만든다. - 결과를 캔버스의 recap 카드나 Slack 스레드에 공유할 수 있어 회의 후 정보가 유실되는 것을 줄인다. ## 팀의 암묵지를 재사용 가능한 지침으로 전환 - 팀만 알고 있던 업무 방식이나 반복 프롬프트를 자연어 지침으로 문서화한다. - 매번 같은 설명을 다시 입력하지 않고 `/스킬이름`으로 호출한다. - 개인의 머릿속에 머물던 리뷰 기준과 작업 절차를 조직 전체가 사용할 수 있는 자산으로 바꾼다. - 스킬을 만들 때는 실제 피드백, 스타일 가이드, 기존 산출물처럼 구체적인 사례를 함께 제공할수록 팀의 방식에 가까운 결과를 얻을 수 있다. 팀에서 반복되는 작업이나 동일한 검토 기준이 있다면, 이를 먼저 작은 스킬로 만들어 테스트하는 것이 좋다. 특히 온보딩, 크리틱 준비·회고, 문구 검수처럼 입력과 결과가 비교적 명확한 업무부터 시작하면 효과를 확인하기 쉽다.

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

AI 에이전트Figma디자인 시스템접근성+2

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

GitLab의 Claude Sonnet 5: 더욱 안정적이고 효율적으로

Claude Sonnet 5가 GitLab Duo Agent Platform에 모든 요금제와 배포 모델로 제공된다. GitLab 평가 제품군의 모든 벤치마크 작업을 완료한 첫 모델로, 이전 모델인 Sonnet 4.6의 93.8%보다 높은 안정성과 8.8% 더 많은 이슈 해결 성과를 보였다. GitLab은 이를 다단계 코딩 작업의 완주율과 결과 품질을 높이면서도 대규모 운영 비용을 낮출 수 있는 모델로 소개한다. ## GitLab Duo Agent Platform에 Claude Sonnet 5 출시 - Anthropic의 Claude Sonnet 5가 GitLab AI Gateway를 통해 GitLab Duo Agent Platform에 통합됐다. - 모든 GitLab 요금제와 배포 모델에서 사용할 수 있다. - 주요 대상은 다음과 같은 소프트웨어 개발 업무다. - 다단계 에이전트 작업 - 코드 생성 및 리뷰 대응 - 테스트 생성 - 보안 조사 - 저장소 이력 분석 - 파이프라인 장애 조사 ## 모든 에이전트 실행을 완료하는 안정성 - Sonnet 5는 GitLab 평가 제품군의 모든 벤치마크 작업을 완료한 첫 모델이다. - 이전 모델인 Sonnet 4.6은 벤치마크의 93.8%를 완료했다. - 에이전트가 작업 중간에 멈추면 재실행, 재프롬프트, 부분 결과 검증에 추가 비용이 발생한다. - Sonnet 5는 다음과 같은 작업에서 중단 가능성을 줄이는 것을 목표로 한다. - 여러 파일을 수정하는 리팩터링 - 실제로 활용 가능한 테스트 커버리지 생성 - 저장소 이력을 추적하는 보안 조사 - 장시간 실행되는 파이프라인 장애 분석 - 단순히 결과를 반환하는 데 그치지 않고, 8.8% 더 많은 이슈를 해결해 검토 가능한 결과를 제공하는 데 초점을 둔다. ## 효율성과 운영 비용 - 에이전트가 더 많은 작업을 완료하고 작업 과정에서 자원을 적게 사용할수록 실제 완료 작업당 비용이 낮아진다. - GitLab Duo Agent Platform의 모델마다 GitLab Credits 소비율이 다르다. - 팀은 작업 난이도와 모델의 비용 특성을 고려해 일상적인 개발 작업에 적절한 모델을 선택해야 한다. - GitLab은 모델별 크레딧 소비량을 GitLab Credits 문서에서 제공한다. ## 작업에 맞는 모델 선택 - Sonnet 5가 모든 작업에 적합하다는 의미는 아니다. - 일반적인 개발 업무에서는 품질, 속도, 비용의 균형을 제공하는 안정적인 기본 모델로 활용할 수 있다. - 더 복잡하고 긴 추론이 필요한 장기 에이전트 작업에는 Claude Opus 4.8을 선택할 수 있다. - GitLab 인스턴스의 모델 선택 기능에서 작업별로 사용할 모델을 지정할 수 있다. ## 이용 방법 - Claude Sonnet 5는 GitLab AI Gateway를 통해 즉시 사용할 수 있다. - 다른 모델과 마찬가지로 GitLab Credits를 사용한다. - 신규 사용자는 GitLab Duo Agent Platform 무료 체험 또는 GitLab Free 등급에서 시작할 수 있다. - 기존 GitLab Premium 및 Ultimate 구독자는 구독에 포함된 GitLab Credits를 이용할 수 있다. 실무에서는 반복적인 리팩터링, 테스트 생성, 장애 분석처럼 빈번한 개발 작업에 Sonnet 5를 기본 모델로 사용하고, 높은 추론 능력이 필요한 장기 작업에만 Opus 4.8을 선택하는 방식이 비용과 품질의 균형을 맞추는 방법이다.

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

AI 에이전트DevSecOpsgitlab-duo-agent-platformai-gateway+2

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

모델과 작업별 GitHub Copilot 에이전틱 하니스의 성능 및 효율성 평가

GitHub은 모델 자체의 지능뿐 아니라 도구·컨텍스트·작업 흐름을 조율하는 에이전틱 하니스(harness)가 실제 성능을 좌우한다고 주장합니다. 동일한 모델과 작업을 기준으로 비교한 결과, GitHub Copilot 하니스는 모델 제공업체의 하니스와 비슷한 작업 해결률을 유지하면서 대부분 더 적은 토큰을 사용하는 것으로 나타났습니다. 따라서 하나의 하니스를 개선하면 Copilot CLI, 앱, 코드 리뷰, IDE 등 여러 제품 경험이 함께 향상된다는 결론입니다. ## 에이전틱 하니스의 역할 - 모델은 기본적인 추론 능력을 제공하지만, 하니스가 그 능력을 실제 작업에 적용하는 방식을 결정합니다. - 하니스는 다음 요소를 조율합니다. - 사용할 도구 - 모델에 제공할 컨텍스트 - 작업 실행 순서와 워크플로 - 메모리 및 MCP 서버 활용 - GitHub Copilot의 하니스는 Copilot SDK의 공통 구성 요소입니다. - Copilot CLI, Copilot 앱, Copilot 코드 리뷰, VS Code·Xcode 등 다양한 GitHub 및 Microsoft 경험에서 공유됩니다. - GitHub은 좋은 하니스의 조건으로 빠른 속도, 낮은 토큰 사용량, 예측 가능성을 제시합니다. ## 벤치마크 비교 방법 - 공개 벤치마크와 GitHub·Microsoft 대규모 코드베이스에서 도출한 내부 벤치마크를 함께 사용합니다. - 통제된 실험 결과를 실제 사용 지표와 온라인 실험으로 보완합니다. - 비교 시 다음 조건을 동일하게 맞췄습니다. - 같은 모델 - 같은 벤치마크 작업 - 동일하게 정규화한 컨텍스트 윈도우 - 동일한 추론 수준 - 동일한 도구 선택 및 MCP 서버 - 비교 대상은 다음과 같습니다. - GitHub Copilot CLI - Claude 모델의 기본 하니스인 Claude Code - GPT 모델의 기본 하니스인 Codex CLI - 평가 모델은 Claude Sonnet 4.6, Claude Opus 4.7, GPT-5.4, GPT-5.5입니다. ## 사용한 벤치마크 - **SWE-bench Verified** - 오픈소스 Python 저장소의 사람이 검증한 버그 수정 500개 - 코딩 에이전트의 대표적인 산업 표준 벤치마크 - **SWE-bench Pro** - 여러 단계의 추론과 광범위한 코드 변경이 필요한 어려운 작업 - 실제 소프트웨어 엔지니어링에 가까운 복잡한 문제를 평가 - **SkillsBench** - 에이전트가 스킬을 얼마나 효과적으로 사용하고 호출하는지 평가 - **TerminalBench** - 개발자가 사용하는 명령줄·터미널 기반 작업 수행 능력 측정 - **Win-Hill** - Windows 컨테이너에서 실행되는 내부 벤치마크 - 운영체제와 실행 환경이 달라져도 성능이 유지되는지 검증 ## 토큰 효율 - 동일한 모델과 작업을 사용했을 때 Copilot 하니스는 대부분의 설정에서 더 적은 토큰을 소비했습니다. - 토큰 사용량이 줄었음에도 전반적인 작업 완료율은 다른 모델 제공업체 하니스와 비슷한 수준이었습니다. - Claude Sonnet 4.6과 Opus 4.7에서는 Copilot CLI가 비교된 모든 사례에서 더 나은 결과를 보였습니다. - GPT-5.4와 GPT-5.5에서도 대부분 Copilot CLI가 우세했지만, SWE-bench Verified에서는 각각 7%, 4% 낮은 성능을 기록했습니다. - 단순히 비용을 줄이는 것이 아니라, 작업 해결 능력을 유지하면서 토큰 소비를 낮추는 것이 핵심입니다. ## 작업 해결률 - 전체적으로 Copilot 하니스의 작업 해결률은 모델 제공업체 하니스와 대등했습니다. - SWE-bench Verified에서는: - Sonnet 4.6과 Opus 4.7에서 Copilot CLI가 더 높은 해결률을 보였습니다. - GPT-5.4와 GPT-5.5에서는 더 낮았습니다. - SWE-bench Pro에서는: - Sonnet 4.6에서만 Copilot CLI가 소폭 낮았습니다. - 나머지 모델에서는 더 나은 성능을 보였습니다. - SkillsBench에서는 Claude 모델에서 낮았지만 GPT 모델에서는 더 높았습니다. - Win-Hill에서는 모든 모델에서 같거나 더 나은 결과를 기록했습니다. - TerminalBench 2에서는: - Sonnet 4.6과 Opus 4.7에서 더 높았습니다. - GPT-5.5에서는 동률이었습니다. - GPT-5.4에서는 더 낮았습니다. - 저자들은 모델의 확률적 특성으로 인한 실행별 변동을 고려하면 이러한 차이는 실질적으로 “동등한 수준”이라고 해석합니다. ## 실행별 변동성과 비용 분석 - TerminalBench 2.0을 사용해 작업 해결률뿐 아니라 작업당 비용과 실행별 변동도 분석했습니다. - 벤치마크 결과는 한 번의 실행만으로 하니스 성능을 판단하기 어렵다는 점을 보여줍니다. - 같은 에이전트와 모델 조합도 실행마다 결과가 달라질 수 있습니다. - 평가에서는 더 많은 작업을 해결하면서 비용을 적게 쓰는 구성이 더 좋은 것으로 간주합니다. - Copilot CLI는 이러한 분석에서 모델 제공업체 하니스와 비교해 같거나 더 나은 해결률·토큰 효율을 보였습니다. ## 실용적인 의미 - 모델을 선택할 때 모델의 벤치마크 점수만 보지 말고 하니스의 도구 사용, 컨텍스트 관리, 토큰 효율도 함께 평가해야 합니다. - 여러 모델을 한 제품에서 사용해야 한다면, 특정 모델에 종속되지 않으면서 성능을 유지하는 공통 하니스가 유리합니다. - 실제 도입 전에는 SWE-bench 같은 표준 평가뿐 아니라 조직의 코드베이스와 터미널 작업을 반영한 내부 벤치마크를 반복 실행하는 것이 좋습니다. - 단일 실행 결과보다 해결률, 비용, 토큰 사용량, 실행 간 변동을 함께 비교해야 신뢰할 수 있는 판단을 내릴 수 있습니다.

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

AI 에이전트대규모 언어 모델모델 컨텍스트 프로토콜github-copilot+3

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

DSPy를 활용해 Dash 채팅에서 AI 평가를 더 나은 응답으로 전환한 방법

Dropbox는 Dash chat 에이전트의 최종 답변만 평가하지 않고, 의도 파악·검색·도구 사용·근거 선택·다중 턴 대응까지 전체 실행 과정을 평가했습니다. 이후 사람의 평가 데이터를 활용해 LLM 평가자(judge)를 보정하고, DSPy의 GEPA·MIPROv2로 평가자와 에이전트 시스템 프롬프트를 최적화했습니다. 그 결과 불완전한 답변을 줄이고 토큰 사용량도 낮추면서 답변 품질을 유지할 수 있었습니다. ## 에이전트 평가가 어려운 이유 - 전통적인 검색 평가는 단일 결과의 관련성을 주로 측정하지만, 에이전트는 여러 단계의 의사결정을 수행합니다. - 평가 대상에는 다음 과정이 모두 포함됩니다. - 사용자의 의도 해석 - 문서·메시지·회의 기록 등 적절한 컨텍스트 수집 - 검색 및 문서 읽기 같은 도구 사용 - 여러 출처의 정보 종합 - 직접 답변, 추가 검색, 요약, 명확화 질문 중 적절한 선택 - 대화가 여러 턴에 걸쳐 진행될 수 있으므로 최종 답변뿐 아니라 피드백 반영과 재검색 과정도 평가해야 합니다. - 따라서 답변 품질, 의도 이해, 컨텍스트 선택, 도구 사용, 근거성, 지시 준수, 과업 완료 여부를 পৃথ도로 분석해야 실패 원인을 찾을 수 있습니다. ## 사람의 평가로 LLM judge 보정 - 내부 채팅 샘플과 에이전트 trace 로그를 수집하고, 사람이 다음 다섯 가지 차원을 평가했습니다. - 사용자 의도 추종 - 의미적 관련성 - 도구 호출 품질 - 지시사항 준수 - 컨텍스트 선택 - 평가자는 먼저 의도와 컨텍스트가 적절했는지 확인한 뒤 검색·검색 결과 활용·도구 행동을 검토했습니다. - 이후 최종 답변이 선택된 근거에 의해 뒷받침되는지, 관련성·근거성·완전성·지시 준수 여부를 평가했습니다. - 일부 지표는 1~5점으로 점수화하고, 함께 다음 정보를 기록했습니다. - 점수의 근거가 되는 reasoning note - 오래된 근거, 누락된 컨텍스트, 근거 없는 주장, 불완전한 답변, 개인화 실패 등의 failure code - 점수는 결과를 요약하지만, 평가 메모와 실패 코드는 문제가 발생한 위치와 원인을 보여줍니다. - 이 데이터는 judge 프롬프트 보정뿐 아니라 디버깅, 오류 분석, 개선 로드맵 수립, 우선순위 결정에도 활용됐습니다. ## DSPy를 이용한 평가자 개선 - 목표는 LLM judge의 점수가 사람의 판단과 더 일치하도록 만드는 것이었습니다. - judge는 단순히 답변에 점수를 매기는 것이 아니라 다음과 같은 정해진 절차를 따라야 했습니다. - 사용자의 의도 추론 - 대화 내용 검토 - 에이전트 trace와 지원 근거 확인 - 컨텍스트 선택과 도구 사용 분석 - 점수·실패 코드·평가 메모 작성 - DSPy를 최적화 도구로 사용하고, GEPA와 MIPROv2를 알고리즘으로 활용했습니다. - 알고리즘은 사람의 라벨이 있는 예제에서 프롬프트 변경안을 자동으로 제안하고 테스트했습니다. - 지원한 최적화 방식에는 다음이 포함됩니다. - judge 지침을 처음부터 새로 작성 - 기존 평가 행동을 유지하면서 다른 기반 모델에 맞게 조정 - 특정 실패 유형을 집중적으로 수정하는 타깃 최적화 - 이렇게 최적화된 judge는 이후 채팅 에이전트 자체의 시스템 프롬프트를 개선하는 평가 신호로 사용됐습니다. ## 평가에서 에이전트 개선으로 이어지는 피드백 루프 - 전체 과정은 다음 순환 구조로 구성됩니다. - 사람의 라벨이 judge를 보정 - 개선된 judge가 대규모 평가 신호 생성 - 평가 신호가 에이전트 프롬프트와 행동 개선에 사용 - 이 구조를 통해 사람의 평가를 모든 대화에 직접 적용하지 않고도 에이전트를 반복적으로 최적화할 수 있었습니다. - 최종적으로 불완전한 답변이 크게 줄었고, 답변 품질을 떨어뜨리지 않으면서 토큰 사용량도 절감했습니다. 실무적으로는 에이전트 개선 전에 평가자의 신뢰성을 먼저 검증해야 합니다. 최종 점수만 수집하기보다 trace, 평가 이유, 실패 유형을 함께 기록하고, 사람의 라벨과 DSPy 같은 자동 최적화 도구를 결합하면 평가를 지속적인 품질 개선 시스템으로 전환할 수 있습니다.

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

AI 에이전트대규모 언어 모델dspyprompt-optimization+4

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

AI 에이전트끼리 토론한다면? 멀티 에이전트 협업으로 재설계하는 개발 프로세스

AI 코딩의 병목은 코드 생성 속도가 아니라 의도 정의, 가정 검증, 구현 확인, 리뷰 준비를 사람이 직접 조율하는 데 있다. LY Corporation은 이를 해결하기 위해 제안자와 도전자 AI 팀이 스펙·빌드·전달의 세 단계에서 토론하고, 조율자가 수정·상위 보고·진행 여부를 결정하는 파이프라인을 설계했다. 목표는 사람의 판단을 없애는 것이 아니라, 사람이 검토하기 전에 AI가 자신의 작업을 근거와 함께 입증하도록 만드는 것이다. ## 사람이 조율하는 AI 보조 방식의 한계 - 기존 방식에서는 AI가 스펙 작성, 코드 생성, 테스트, PR 설명 등을 빠르게 수행한다. - 그러나 각 단계 사이에서 사람이 다음 작업을 요청하고, 실패 결과를 전달하고, diff와 PR을 검토해야 한다. - 따라서 개별 작업은 빨라져도 의도·구현·검증·리뷰·전달 사이의 조율 비용은 그대로 남는다. - 진정한 생산성 향상은 각 단계를 단순히 가속하는 것이 아니라, 수동 인수인계를 프로세스에서 제거하는 데 있다. ## 제안자와 도전자로 나뉜 AI 협업 - 제안자는 산출물을 작성하고 단계가 진행될수록 이를 발전시킨다. - 도전자는 제안자의 결과를 검증하며, 단계별로 서로 다른 관점에서 문제를 제기한다. - 스펙 단계: 소크라테스식 질문으로 모호성·누락을 찾는다. - 빌드 단계: 테스트와 실행 결과 등 근거를 바탕으로 반론한다. - 전달 단계: 구현과 PR이 최종 리뷰에 충분한지 점검한다. - 역할을 분리하면 하나의 AI가 스펙, 구현, 검증, 리뷰를 모두 낙관적으로 처리하는 문제를 줄일 수 있다. - 사람은 시작 시 의도를 정의하고, 결과를 승인하거나, 해결하기 어려운 문제가 상위 보고될 때 주로 개입한다. ## 스펙·빌드·전달 파이프라인 ### 스펙: 이후 작업의 계약 정의 - 스펙은 다음 내용을 포함한다. - 목표와 제약 조건 - 해석된 요구 사항 - 명시적 가정 - 미해결 질문 - 제안된 접근 방식 - 완료 정의 - 빌드 에이전트는 “합리적으로 보이는” 구현을 임의로 선택하지 않고, 승인된 스펙에서 테스트와 검증 계획을 도출한다. - 스펙이 부실하면 이후 구현과 리뷰의 기준도 불명확해지므로 전체 파이프라인이 약해진다. - 기존 API, 테스트, 의존성, 코딩 관습, Jira·Confluence·설계 문서 등을 조사해 질문과 가정을 구체화한다. ### 빌드: 테스트 우선 구현과 반론 - 제안자는 코드를 수정하기 전에 스펙을 다음 항목으로 변환한다. - 예상 동작 - 에지 케이스 - 추가·수정할 테스트 - 실행 명령 - 도전자는 구현 전이나 구현 중에 검증 설계 자체를 문제 삼을 수 있다. - 제안자가 도전자의 이의를 거부하려면 실행 경로, 컴파일·린트 출력, 실패 테스트 등 구체적인 증거를 제시해야 한다. - 단순히 테스트가 녹색이라는 사실만으로 검증 누락을 숨길 수 없도록 설계됐다. ### 전달: 리뷰 가능한 PR 패키지 - 최종 산출물은 코드뿐 아니라 리뷰어가 신뢰할 수 있는 PR 패키지다. - 패키지에는 다음 정보가 포함된다. - 무엇이 변경되었는가 - 어떤 파일과 영역을 먼저 봐야 하는가 - 어떤 검사와 테스트를 통과했는가 - 남은 위험과 불확실성은 무엇인가 - 도전자가 어떤 문제를 제기했고 어떻게 처리했는가 - 전달 단계의 조율자는 중재자라기보다 출시 가능성을 판단하는 심사위원 역할을 한다. ## 조율자와 구조화된 토론 프로토콜 - 조율자는 제안자와 도전자 사이에서 토론을 관리한다. - 주요 책임은 다음과 같다. - 논의가 주제에서 벗어나면 방향 수정 - 교착 상태 해소 - 산출물 수정 요청 - 안전하지 않은 불확실성의 상위 보고 - 다음 단계 진행 여부 결정 - 스펙과 빌드에서는 수렴을 이끄는 중재자 역할을 하고, 전달 단계에서는 근거가 충분한지 판정한다. - 각 에이전트는 제한된 프롬프트와 자체 컨텍스트를 사용하며, 공통으로 접근하는 것은 워크스페이스·산출물·조율자가 누적한 기록이다. - 에이전트 간 실시간 공동 컨텍스트 대신 구조화된 산출물과 transcript를 통해 협업한다. ## JSON 기반 상태 머신 - 각 토론 라운드는 제안자와 도전자의 교환 및 조율자의 결정을 포함한다. - 에이전트는 긴 에세이가 아니라 조율자가 파싱할 수 있는 엄격한 JSON을 반환한다. - JSON에는 상태, 요약, 전문가 의견, 판단 근거, 요구 사항, 제약, 완료 정의, 가정, 질문 등이 담긴다. - 예를 들어 `/api/search`만 변경할지 인접한 검색 엔드포인트까지 포함할지 불명확하면, 도전자는 범위 경계를 명시적인 질문으로 제기한다. - 모호성이 작고 기존 근거로 안전하게 판단할 수 있으면 제안자가 가정으로 기록하고 진행한다. - 반대로 답이 없으면 위험하거나 파괴적이거나 되돌리기 어려운 문제라면 추측하지 않고 사람에게 상위 보고한다. ## 전문 역할과 근거 중심 검증 - 각 단계에는 목적에 맞는 전문 역할이 배정된다. - `requirements-synthesizer`: 요구 사항 정리 - `security-analyst`: 보안 위험 분석 - `test-coverage-reviewer`: 테스트 범위 검토 - `technical-writer`: 전달 문서 작성 - `evidence-verifier`: 구현과 검증 근거 확인 - 중요한 판단은 직감이 아니라 코드, 테스트, 문서, 실행 결과 같은 근거에 기반한다. - 핵심은 여러 AI를 단순히 병렬 실행하는 것이 아니라, 서로 다른 책임과 관점을 부여해 주장과 반론을 구조화하는 데 있다. ## 실용적인 결론 AI 코딩 시스템을 설계할 때는 코드 생성 에이전트 하나를 더 빠르게 만드는 것보다, 스펙부터 PR 전달까지의 인수인계를 자동화하는 것이 더 큰 효과를 낼 수 있다. 특히 스펙을 계약으로 명확히 만들고, 단계별 도전과 근거 제출을 강제하며, 위험한 가정은 사람에게 상위 보고하도록 구성하는 것이 핵심이다.

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

AI 에이전트CI/CD코드 리뷰json+3

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

시멘틱 컨텍스트 OS 설계: 에이전트 시스템의 토큰 스터핑을 넘어

LLM의 컨텍스트 창이 커져도 입력을 무작정 늘리는 ‘토큰 스터핑’만으로는 소프트웨어 에이전트의 추론 성능을 보장할 수 없다는 것이 글의 핵심 주장입니다. 긴 컨텍스트에서는 어텐션 희석과 컨텍스트 부패가 발생해 검색 정확도와 논리 일관성이 떨어질 수 있으므로, 컨텍스트를 텍스트가 아닌 관리 가능한 시스템 자원으로 다뤄야 합니다. 이를 위해 글은 로컬 루프백 프록시 형태의 ‘시맨틱 컨텍스트 OS’와 VFS, AST 기반 가지치기, 동적 토큰 관리 구조를 제안합니다. ## 컨텍스트 창은 전통적인 RAM과 다르다 - Karpathy의 은유에 따르면: - LLM은 사전 학습된 가중치를 바탕으로 추론을 수행하는 CPU와 유사합니다. - 컨텍스트 창은 현재 상태와 실행 데이터를 담는 휘발성 RAM과 유사합니다. - 그러나 전통적인 RAM과 달리 LLM의 컨텍스트 검색은 결정론적인 주소 조회가 아닙니다. - 특정 메모리 주소에서 데이터를 정확히 읽는 방식이 아니라, Q·K·V 행렬과 어텐션 점수에 기반한 확률적 검색입니다. - 컨텍스트가 32K에서 1M 또는 2M 토큰으로 커져도 정보 접근 정밀도가 선형적으로 증가하지 않습니다. - 입력이 커질수록 계산 표면적과 구조적 잡음이 증가해 오히려 추론 성능이 저하될 수 있습니다. ## 어텐션 희석과 ‘중간 정보 유실’ - 긴 코드베이스나 시스템 로그에는 다음과 같은 불필요한 정보가 포함됩니다. - 보일러플레이트 정의 - 참조되지 않는 import - 중복된 구문과 유틸리티 - 관련 없는 로그와 실행 데이터 - 이런 정보가 키 행렬에 많이 포함되면 쿼리와 키 사이의 의미 차이가 작아지고, 어텐션 로짓이 균일해집니다. - 그 결과 중요한 정보에 집중하던 날카로운 어텐션 피크가 넓게 분산되어, 정확한 사실 검색이 어려워집니다. - 글은 이를 Stanford 연구에서 제시한 ‘Lost in the Middle’ 현상과 연결합니다. - 컨텍스트의 시작과 끝에 있는 정보는 비교적 잘 검색됩니다. - 중간 영역, 특히 중간 70% 부근의 정보는 검색 정확도가 크게 낮아집니다. - 수만 줄의 코드나 복잡한 서비스 의존성을 다루는 에이전트에게 이러한 검색 편향은 심각한 논리적 오류로 이어질 수 있습니다. ## 장기 작업에서 발생하는 컨텍스트 부패 글은 자동 리팩토링, 레거시 마이그레이션, API 계약 검증처럼 여러 단계가 필요한 작업에서 컨텍스트가 시간이 지나며 악화되는 현상을 ‘컨텍스트 부패’라고 설명합니다. - **컨텍스트 오염** - 과거 실행 로그, 터미널 오류, 원시 데이터를 계속 누적합니다. - 모델이 일시적인 과거 오류를 현재 작업의 영구적인 제약으로 잘못 해석할 수 있습니다. - **컨텍스트 산만** - 모노레포의 동일한 이름, 오버로드된 메서드, 중복 유틸리티가 검색 결과에 함께 들어옵니다. - 구조적으로 비슷하지만 논리적으로 무관한 코드가 핵심 실행 경로를 가립니다. - **컨텍스트 충돌** - 이전 단계의 지시사항을 제거하거나 갱신하지 않으면 서로 모순되는 명령이 남습니다. - 에이전트가 논리적으로 마비되거나 무한 추론, 타임아웃, 환각을 일으킬 수 있습니다. - 글은 능동적인 관리 계층이 없을 경우 컨텍스트 깊이가 커질수록 실패율이 비선형적으로 증가하고, 깊은 코드 구조에서는 실패율이 약 40%에 이를 수 있다고 주장합니다. ## 수동적 프롬프트에서 능동적 거버넌스로 - 일반적인 구현은 문자열을 계속 이어 붙여 다음 LLM 호출에 전달하는 방식입니다. - 이 방식은 메모리 관리, 토큰 최적화, 노이즈 제거를 LLM의 내부 어텐션에 맡깁니다. - 시맨틱 컨텍스트 OS는 애플리케이션 로직과 파운데이션 모델 API 사이에 위치하는 AI 전용 커널로 제시됩니다. - 로컬 `localhost:8080` 루프백 프록시로 동작하며 다음 작업을 담당합니다. - 컨텍스트 상태와 접근 경로 관리 - 토큰 생명 주기 모니터링 - 전송 전 데이터 격리와 정책 적용 - 모델별 하드웨어 토큰 한계와 의미론적 컨텍스트 거버넌스의 분리 ## MVC(Minimum Viable Context) 파이프라인 MVC의 목표는 거대한 텍스트 덤프가 아니라 현재 추론 단계에 필요한 최소한의 고밀도 정보만 모델에 제공하는 것입니다. - **수집 및 토큰 매핑** - 소스 파일, 의존성 트리, 런타임 로그를 수집합니다. - `cl100k_base`, `o200k_base` 등 실제 모델 토크나이저를 사용해 정확한 토큰 수를 계산합니다. - **구조 가지치기** - 정적 코드 분석과 구조 규칙으로 불필요한 정보를 제거합니다. - 컴파일러 주석, 미사용 import, 관계없는 유틸리티 코드 등이 대상입니다. - 글에서 제시한 전체 아키텍처는 이후 단계에서 의미적 정제와 실행 중 토큰 최적화를 수행하도록 설계됩니다. ## 시맨틱 컨텍스트 OS의 구성 요소 - **POSIX 유사 VFS** - 컨텍스트와 에이전트 상태를 가상 파일 시스템처럼 구조화합니다. - 상태 토폴로지와 접근 경계를 명시적으로 관리합니다. - **PathAlign** - AST를 활용해 코드의 구조적 경로를 분석합니다. - 현재 작업과 관련된 가지를 남기고 무관한 코드 트리를 제거합니다. - **비동기 톱니(sawtooth) 메모리 모델** - 실행 중 컨텍스트를 계속 축소·갱신하는 방식으로 토큰 사용량을 최적화합니다. - 장기 실행 루프에서 오래된 상태와 불필요한 데이터를 누적하지 않도록 합니다. - **보안 및 격리** - 모델에 전달되는 데이터의 범위를 제한합니다. - 기업 코드와 로그 등 지적 재산이 불필요하게 외부 추론 엔진으로 유출되는 위험을 줄이는 것을 목표로 합니다. 시맨틱 컨텍스트 OS의 실질적인 메시지는 “큰 컨텍스트 창”보다 “잘 선별되고 지속적으로 관리되는 컨텍스트”가 중요하다는 것입니다. 엔터프라이즈 에이전트를 구축할 때는 토큰 예산을 명시적으로 계산하고, AST·의존성·의미 기반 필터링을 적용하며, 오래된 지시와 로그를 정리하는 런타임 거버넌스 계층을 두는 것이 권장됩니다. 단, 글의 실패율과 성능 개선 수치는 제안된 아키텍처의 주장으로 보아 실제 환경에서 별도의 벤치마크 검증이 필요합니다.

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

AI 에이전트대규모 언어 모델transformerabstract-syntax-tree+4

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

피그마 캔버스에서 코딩하기 | 피그마 블로그

Figma는 코드 레이어를 통해 실행 가능한 코드를 디자인 캔버스 안에서 생성·비교·수정할 수 있도록 한다. 디자이너와 개발자는 코드와 디자인을 오가는 대신 같은 Figma 파일에서 아이디어를 함께 탐색하고, 팀의 피드백을 반영하며, 최종 코드를 저장소에 반영할 수 있다. 코드 레이어는 디자인과 개발의 경계를 좁혀 협업 중심의 프로토타이핑을 가능하게 하는 기능이다. ## 캔버스에서 코드 시작하기 - Figma Design의 툴바에서 코드 레이어를 추가하거나, 기존 프레임을 코드로 변환할 수 있다. - Figma Agent에게 원하는 결과를 설명해 코드를 생성할 수도 있다. - 템플릿에서 시작하거나 직접 만들고 싶은 내용을 프롬프트로 입력할 수 있다. - GitHub 저장소를 가져오거나 로컬 폴더를 업로드해 기존 코드베이스를 불러올 수 있다. - Figma Make에서 생성·수정한 코드도 캔버스의 코드 레이어로 가져와 팀과 공유할 수 있다. ## 여러 대안을 나란히 비교하기 - 기존 프레임을 복제해 여러 디자인 방향을 시험하듯 코드 레이어도 복제해 대안을 만들 수 있다. - 실제로 작동하는 화면을 캔버스에서 비교하므로 정적인 시안만 볼 때보다 사용 경험을 구체적으로 평가할 수 있다. - 요소를 이동·조정·리사이즈하면 코드에 즉시 반영된다. - 프롬프트로 새 버전을 생성하면서도 기존 버전은 보존할 수 있다. - 팀원은 공유 파일 안에서 댓글을 남기거나 동일한 코드 레이어를 대상으로 Agent에 추가 작업을 요청할 수 있다. ## 코드와 디자인 레이어 오가기 - `Extract designs` 기능을 사용하면 코드의 현재 상태를 편집 가능한 Figma 레이어로 변환할 수 있다. - 전체 화면뿐 아니라 특정 화면, 상태, 사용자 플로우만 선택해 캔버스로 가져올 수 있다. - 코드로 구현된 인터랙션과 상태를 시각적으로 분석하고, 일반적인 Figma 디자인 요소처럼 편집할 수 있다. - 캔버스에서 수정한 내용은 한 번의 클릭으로 코드 레이어에 업데이트할 수 있어 디자인과 구현 사이의 반복 작업이 짧아진다. ## 코드 편집과 저장소 반영 - 코드 에디터에서 원하는 변경 사항을 주석이나 설명으로 작성하고 Agent에게 수정을 요청할 수 있다. - 필요하면 개발자가 직접 코드를 편집할 수도 있다. - 수정 결과를 다시 코드 레이어로 변환해 팀에 공유할 수 있다. - 최종적으로 확정한 변경 사항은 저장소에 push해 실제 소스 코드에 반영할 수 있다. - 따라서 Figma 캔버스는 단순한 시각화 공간이 아니라, 아이디어 탐색부터 코드 변경 및 공유까지 이어지는 협업 환경이 된다. ## 출시 계획 - 코드 레이어는 2026년 6월 기준 향후 몇 주 동안 비공개 베타로 제공될 예정이다. - 초기 접근 권한은 Figma의 베타 신청 페이지를 통해 요청할 수 있다. - 기능 세부 사항과 Config에서 발표된 다른 업데이트는 Figma Help Center와 Figma Learn에서 확인할 수 있다. 실무에서는 코드 레이어를 최종 구현을 자동화하는 도구라기보다, 디자인·개발팀이 여러 구현안을 빠르게 실험하고 합의하는 공동 프로토타이핑 환경으로 활용하는 것이 적합하다. 특히 기존 코드베이스를 불러와 실제 동작을 검토한 뒤 디자인과 코드를 반복적으로 조정하는 워크플로에 유용하다.

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

AI 에이전트FigmaReactgithub+2

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

Figma의 디자인 에이전트, 이제 맞춤형 도구와 더욱 풍부한 컨텍스트 지원 | Figma 블로그

Figma의 디자인 에이전트가 오픈 베타에서 더 많은 사용자에게 제공되며, 단순한 프롬프트를 넘어 사용자 정의 도구와 팀의 작업 맥락을 활용할 수 있게 됐다. 사용자는 에이전트에게 재사용 가능한 플러그인과 셰이더를 만들도록 요청해 Figma 캔버스 안에서 자신만의 디자인 워크플로를 구축할 수 있다. 이를 통해 에이전트는 결과물을 생성하는 도구를 넘어 사용자의 작업 방식을 이해하고 협업하는 파트너에 가까워진다. ## Figma 디자인 에이전트의 확장 - 에이전트는 Figma 캔버스에서 직접 작동하며, 디자인 작업의 유연성·정밀도·창작 제어력을 높인다. - 팀의 작업 방식과 실제 디자인 맥락을 이해할수록 단순히 결과물을 만드는 것을 넘어 협업할 수 있다는 점을 강조한다. - Figma는 에이전트와 사용자 정의 도구를 직접 시험할 수 있는 커뮤니티 플레이그라운드 파일도 제공한다. - 사용자의 요구를 자연어로 설명하면 에이전트가 도구 제작과 문제 해결 방법까지 제안한다. ## 프롬프트로 만드는 생성형 플러그인 - 기존에는 플러그인을 만들려면 개발 지식과 별도의 개발 환경이 필요했지만, 이제 에이전트에게 재사용 가능한 플러그인 제작을 요청할 수 있다. - 생성형 플러그인은 다음과 같은 작업에 활용될 수 있다. - HTML을 Figma 캔버스로 가져오기 - 대시보드 레이아웃 생성 - 데이터를 시각화하기 - 이미지 자산 자동 배치 - `PropsKit`을 사용하기 때문에 Figma의 기본 기능처럼 자연스럽게 동작한다. - 캔버스 안에서 직접 결과를 확인하고 반복 수정할 수 있어, 외부 도구를 오가는 번거로움이 줄어든다. - Figma 밖의 AI 서비스나 서드파티 API와 연동해야 하는 경우에는 기존 방식의 클래식 플러그인을 사용해야 한다. - 플러그인이나 셰이더 자체는 제작자, 팀원, 커뮤니티 사용자 모두 무료로 사용할 수 있지만, 에이전트에게 제작을 요청하는 기능은 일반 출시 후 AI 크레딧을 사용하게 된다. ## WebGPU 기반 셰이더 효과 - 에이전트는 픽셀이 렌더링되는 방식을 정의하는 작은 프로그램인 셰이더도 생성할 수 있다. - Figma의 WebGPU 기반 렌더러를 활용해 다음과 같은 시각 효과를 만들 수 있다. - 디더링 - 리퀴드 메탈 - 프랙털 노이즈 - 렌즈 왜곡 - 입자 늘이기 - 색상 외곽선 - 셰이더 효과는 네이티브 Figma 효과처럼 쌓아 사용할 수 있으며, 속성을 조절하거나 기본 효과와 결합할 수 있다. ## 셰이더 효과와 셰이더 필 - **셰이더 효과** - 레이어에 적용되는 사용자 정의 시각 효과다. - 입자 효과, 렌즈 왜곡, 컬러 아웃라인 등 다양한 효과를 만들 수 있다. - 여러 효과를 조합해 복합적인 결과를 만들 수 있다. - **셰이더 필** - 단색이나 일반 그라디언트를 넘어서는 동적·생성형 채우기다. - 수채화, 모아레, 패턴 그리드 등을 표현할 수 있다. - 디더 웨이브, 유체 하프톤, 파티클 웹, 마그네틱 필드 같은 프리셋으로 활용할 수 있다. - 사용자는 셰이더의 기능을 정의하고, 에이전트와 대화하며 UI와 조정 가능한 매개변수를 발전시킬 수 있다. - 사진에 콜라주, 마블링, 빛샘, 금속 엠보싱, 프리즘 효과를 적용하는 등 개인의 시각적 스타일을 재사용 가능한 워크플로로 만들 수 있다. ## 디자이너와 에이전트의 협업 방식 - 제품 디자이너 Edward Chechique는 과거 개발자 지원이나 여러 외부 도구가 필요했던 생성형 플러그인 제작을 Figma 안에서 직접 처리할 수 있게 됐다고 설명한다. - 크리에이티브 테크놀로지스트 Anna Zhang은 에이전트와 기능과 UI를 주고받는 과정을 “협상”에 비유한다. - 에이전트가 제안한 해결책과 생성 결과가 다음에 추가할 매개변수와 기능에 영향을 주면서, 일회성 생성보다 반복적인 공동 설계가 가능해진다. 자신만의 레이아웃·효과·데이터 시각화 도구가 필요하다면 에이전트로 생성형 플러그인이나 셰이더를 만들어 보는 것이 유용하다. 다만 외부 API 연동은 클래식 플러그인을 사용해야 하며, 에이전트 기반 제작 기능은 AI 크레딧 비용과 지원 범위를 확인하는 것이 좋다.

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

AI 에이전트FigmaHTMLshaders+2

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

HITEC 2026에서 본 여행 및 호스피탈리티 트렌드 네 가지

호텔 업계의 AI 투자는 빠르게 확대되고 있지만, 실제로 핵심 운영에 AI를 통합하고 투자수익률을 입증한 기업은 10% 미만이다. 성공의 걸림돌은 모델 성능보다 데이터 단절, 낡은 결제 인프라, 실제 업무 흐름과 연결되지 않은 기술에 있다. 앞으로는 검색 최적화보다 AI 답변에 노출되는 구조화된 데이터, 원활한 결제, 눈에 띄지 않게 작동하는 개인화 기술이 경쟁력을 좌우할 전망이다. ## AI 시대의 직접 예약 경쟁 - 기존 호텔 업계는 SEO와 검색 순위 개선을 통해 Expedia, Booking.com 같은 OTA를 거치지 않고 직접 예약을 유도했다. - 그러나 AI Overview가 포함된 Google 검색의 65%는 사용자가 웹사이트를 클릭하지 않고 종료되며, 모바일에서는 이 비율이 78%까지 높아진다. - 업계의 전통적인 검색 트래픽은 약 25% 감소하고 있어, 키워드와 백링크 중심의 SEO만으로는 충분하지 않다. - AI 모델에 노출되려면 다음 정보가 정확하고 기계가 읽기 쉬운 형태로 제공되어야 한다. - 객실 유형과 세부 조건 - 편의시설 - 취소 및 환불 정책 - 주변 지역 정보 - 실시간 재고와 요금 - 숙박업체 사이트의 90% 이상이 아직 AI 모델에 제대로 탐지되지 않는다. - 여행자의 56%가 최근 1년 동안 여행 계획, 예약 또는 현지 지원에 AI를 사용했다. - 따라서 대규모 AI 투자보다 먼저, 주요 AI 서비스가 자사 호텔을 정확히 설명하고 있는지 데이터 감사를 수행해야 한다. - AI 검색 노출만으로는 부족하며, 현지 결제수단·통화, 원클릭 결제, 사기 방지 기능을 갖춘 결제 과정까지 연결해야 예약 전환이 가능하다. ## 호텔 AI의 병목은 모델보다 데이터 연결성 - 많은 호텔이 AI 기능을 도입하고 있지만, 전략과 데이터 기반, 운영 아키텍처가 부족해 안정적으로 확장하지 못하고 있다. - 주요 시스템이 분리되어 있어 동일 고객에 대한 정보가 여러 곳에 흩어진다. - PMS(호텔 운영 시스템) - CRM - 멤버십·로열티 시스템 - 식음료 시스템 - 결제 시스템 - 이로 인해 AI 개인화가 부정확해지고, 재무팀의 대사 업무가 늘며, 고객 프로필이 불완전해지고, 고객 경험에도 마찰이 발생한다. - 중요한 것은 AI를 만드는 것보다 실제 운영 환경에서 안정적으로 실행하는 ‘AI 운영화’다. - 효과적인 기업은 정제되고 연결된 데이터를 업무 흐름 안에 제공해 직원이 적시에 행동하도록 만든다. - 예를 들어: - Delta Air Lines는 고객 프로필과 운영 데이터를 활용한 AI 컨시어지를 모바일 앱의 고객 지원 과정에 통합했다. - Wynn Las Vegas는 목표 대비 실적이 하락할 때 수익 관리자에게 예측 알림과 구체적인 대응 방안을 함께 제공한다. - 즉, 대부분의 여행 기업에서 우선 해결해야 할 문제는 더 좋은 AI 모델이 아니라 데이터의 통합과 업무 시스템 연결이다. ## 결제 인프라가 예약과 고객 경험을 좌우한다 - 호텔 업계는 결제를 단순한 비용과 운영 기능으로 취급해왔지만, 이제 결제 방식 자체가 성장과 경쟁력의 요소가 되고 있다. - 호텔 경영진 설문에서: - 90%는 결제가 성장에 중요하다고 답했다. - 37%는 결제수단 부족이 고객 경험을 가장 크게 해치는 요인이라고 답했다. - 58%는 사기 방지 시스템이 정상 거래까지 차단한다고 답했다. - 74%는 결제 시스템 분절로 대사 업무에 과도한 시간이 든다고 답했다. - 특정 국가에서 널리 쓰이는 결제수단을 지원하지 않으면 고객은 결제가 가능한 OTA나 다른 플랫폼으로 이동한다. - 대형 OTA는 결제 전문 인력을 대규모로 운영할 수 있지만, 독립 호텔이나 소규모 사업자는 같은 방식으로 투자하기 어렵다. - 대신 적절한 결제 인프라를 사용하면 적은 인력으로도 여러 국가의 결제수단, 통화, 사기 방지 기능을 운영할 수 있다. - 결제 범위의 작은 차이가 직접 예약을 잃고 OTA에 고객을 빼앗기는 결과로 이어질 수 있다. ## 성공적인 기술은 고객에게 보이지 않는다 - 고객은 작동하지 않는 기술에 큰 불만을 느끼며, 반드시 항의하지 않더라도 재방문하지 않을 수 있다. - 기술의 성공 기준은 고객이 기술의 존재를 인식하지 못할 정도로 자연스럽게 작동하는 것이다. - 이상적인 개인화 경험의 예시는 다음과 같다. - 고객이 도착하기 전에 객실 온도가 선호 수준으로 설정됨 - TV에 선호 채널이 표시됨 - 선호하는 베개가 준비됨 - 고객이 매번 자신의 취향을 직접 입력하지 않아도, 과거 투숙·멤버십·운영 데이터를 바탕으로 필요한 서비스를 예측해야 한다. - 다만 개인화는 “AI가 무엇을 했는지”를 과시하는 방식보다, 자연스럽고 방해 없이 서비스에 녹아드는 방식이 효과적이다. ## 실무적인 시사점 호텔과 여행 기업은 유행하는 AI 기능을 무작정 추가하기보다, 먼저 고객·객실·재고·결제 데이터를 통합해야 한다. 이후 AI 검색에서 자사 정보가 정확히 노출되는지 점검하고, 선호 결제수단을 지원하며, 예측 결과가 실제 직원 업무와 자동화된 조치로 이어지는지 확인하는 것이 우선이다. საბოლო적으로 경쟁력 있는 기술은 가장 화려한 기술이 아니라 예약을 늘리고 운영을 단순화하면서 고객이 불편을 느끼지 않게 하는 기술이다.

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

AI 에이전트AI대규모 언어 모델seo+4

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

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

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

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

AI 에이전트생성형 AIPostgreSQLTypeScript+4