모델 컨텍스트 프로토콜

97 개의 포스트

figma3분 읽기큐레이션 요약

MCP 핵심 요약: 컨텍스트의 중요성과 활용 방법 | Figma 블로그

MCP(Model Context Protocol)는 AI가 Figma의 디자인 파일과 컴포넌트, 토큰, 레이아웃 결정 같은 맥락을 코드 작성 도구에서 활용하도록 연결한다. 이를 통해 AI가 단순히 화면을 모방하는 대신 디자인 시스템에 맞는 코드를 생성하고, 코드와 캔버스를 오가며 제품을 반복적으로 개선할 수 있다. 글의 결론은 MCP의 효과가 기술 자체뿐 아니라 팀이 얼마나 구조적이고 일관된 디자인 맥락을 구축했는지에 달려 있다는 것이다. ## MCP가 제품 개발에 필요한 이유 - MCP는 AI 도구가 팀이 사용하는 도구와 데이터에서 맥락을 가져올 수 있도록 하는 표준화된 연결 방식이다. - 기존 제품 개발의 선형적인 흐름은 디자인 → 개발 순서로만 진행되지 않는다. - 팀은 필요에 따라 어느 단계에서든 시작한다. - 개발 중 디자인으로 돌아가거나, 완성된 UI를 다시 캔버스에서 검토할 수 있다. - Figma MCP 서버는 디자인 정보를 개발자의 코드 작성 환경으로 전달한다. - 반대로 코드로 구현된 실제 UI를 Figma 캔버스로 가져와 탐색·수정하고, 다시 개발 환경으로 돌려보낼 수도 있다. ## 스크린샷만 보는 AI의 한계 - AI 코딩 도구가 Figma 화면만 참고하면 최종 결과의 시각적 형태만 파악하고, 그 결과를 만든 설계 의도는 알기 어렵다. - 예를 들어 AI는 다음과 같은 문제를 일으킬 수 있다. - 브랜드 색상과 비슷하지만 실제 토큰에 연결되지 않은 색상을 선택한다. - 팀이 반복적으로 사용한 기존 카드 컴포넌트 대신 새 카드를 처음부터 만든다. - 여러 중첩 컴포넌트로 구성된 폼을 하나의 단순한 요소로 평탄화한다. - 결과물은 겉보기에는 비슷해도 디자인 시스템에서 벗어난 코드가 되고, 화면과 컴포넌트가 늘어날수록 불일치가 누적된다. - MCP는 컴포넌트, 디자인 토큰, 레이아웃 구조 등 Figma 파일의 구조화된 정보를 AI에 제공해 이러한 번역 오류를 줄인다. ## 디자이너에게 달라지는 점 - 디자인 시스템은 제품의 시각적 일관성을 유지하는 수단을 넘어, AI가 생성하는 코드의 품질과 방향을 결정하는 입력값이 된다. - 파일의 구조와 명명, 컴포넌트 재사용성, 토큰의 일관성이 AI 생성 결과에 직접 영향을 준다. - AI가 대규모로 코드를 생성하기 때문에 작은 파일 정리 문제도 여러 화면에 반복될 수 있다. - 과거에는 개발자가 구현 과정에서 한 번 수정하면 끝날 문제가 될 수 있었다. - 이제는 하나의 불일치가 AI를 통해 여러 곳에 복제될 수 있다. - MCP를 사용하면 개발자가 코드로 구현한 결과를 디자이너가 다시 캔버스에서 확인할 수 있다. - 디자이너는 누락된 상태를 추가하고 세부 사항을 다듬어, 기존 구현을 다시 만드는 대신 제품을 완성도 있게 개선할 수 있다. ## 개발자에게 달라지는 점 - AI 코딩 도구는 개발 속도를 높이지만, 디자인 맥락이 없으면 개발자가 디자인 의도를 코드로 번역하는 작업을 여전히 직접 해야 한다. - MCP는 개발 도구 안에서 다음 정보를 활용할 수 있게 한다. - 재사용해야 할 컴포넌트 - 색상·간격·타이포그래피 등의 디자인 토큰 - 레이아웃과 계층 구조 - 디자인 시스템에 포함된 구성 방식 - 따라서 개발자는 화면을 추측하거나 비슷하게 재현하는 데 쓰는 시간을 줄이고, 실제 기능 구현과 제품 완성도 향상에 집중할 수 있다. - 디자인과 코드가 연결된 상태로 유지되므로 구현 과정에서 발생한 차이를 더 빠르게 발견하고 수정할 수 있다. ## 디자인 시스템이 AI 품질을 좌우한다 - MCP의 성능은 연결 방식만으로 결정되지 않고, AI가 읽는 디자인 파일의 품질에 크게 의존한다. - 명확하게 정리된 컴포넌트와 토큰은 AI가 일관된 결과를 생성하도록 돕는다. - 반대로 중복 컴포넌트, 불명확한 이름, 임의의 스타일 값이 많으면 AI가 잘못된 패턴을 학습하고 이를 여러 곳에 확산시킬 수 있다. - 디자인 시스템은 AI 기반 워크플로에서 생산성을 높이는 기준점이자, 생성 결과가 브랜드와 제품 규칙에 맞도록 제한하는 장치가 된다. 실무적으로는 Figma 파일을 AI가 읽기 쉬운 구조로 정리하고, 컴포넌트·토큰·상태를 명확히 관리하는 것이 우선이다. MCP는 디자인 시스템을 대체하는 기술이 아니라, 잘 구축된 디자인 시스템을 개발과 AI 생성 과정에 연결해 주는 기술로 활용해야 한다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

AI 에이전트 해킹: GitHub Secure Code Game으로 에이전틱 AI 보안 기술 강화하기

에이전트형 AI는 파일 접근, 웹 검색, API 호출, 셸 명령, 다른 에이전트와의 협업까지 수행하므로 기존 LLM보다 훨씬 넓은 공격면을 가진다. GitHub Secure Code Game 시즌 4는 의도적으로 취약하게 만든 AI 비서 ‘ProdBot’을 통해 사용자가 공격자 관점에서 에이전트 보안 문제를 체험하도록 설계됐다. 핵심 목표는 단순히 특정 취약점을 외우는 것이 아니라, 실제 에이전트 시스템에서 위험한 설계와 공격 패턴을 발견하는 감각을 기르는 것이다. ## 에이전트형 AI의 등장과 보안 우려 - OpenClaw와 같은 개인용 AI 비서는 다음과 같은 작업을 수행한다. - 이메일과 일정 관리 - 웹 검색 및 브라우징 - 셸 명령 실행 - 플러그인 작성 - WhatsApp·Telegram 등을 통한 사용자 명령 처리 - 이러한 자율성과 편의성은 악성 입력과 결합될 경우 심각한 위험으로 이어질 수 있다. - 에이전트가 접근해서는 안 되는 파일을 읽도록 유도 - 악성 웹 페이지가 에이전트의 지시사항을 덮어씀 - 다중 에이전트 환경에서 한 에이전트의 오염된 데이터를 다른 에이전트가 신뢰 - 에이전트는 단순히 텍스트를 생성하는 모델이 아니라 실제 시스템과 상호작용하므로, 공격 결과가 데이터 유출이나 원격 코드 실행으로 확대될 수 있다. ## Secure Code Game의 발전 - Secure Code Game은 개발자가 의도적으로 취약한 코드를 공격하고 수정하면서 보안을 학습하는 무료 오픈소스 에디터 과정이다. - 시즌별 주제는 AI와 개발 환경의 변화에 맞춰 확장됐다. - 시즌 1: 일반적인 보안 코딩 - 시즌 2: JavaScript, Python, Go, GitHub Actions 등 여러 기술 스택 - 시즌 3: 악성 프롬프트와 LLM 보안 - 시즌 4: 자율적으로 행동하는 AI 에이전트 보안 - 지금까지 업계, 오픈소스, 학계에서 10,000명 이상의 개발자가 참여했다. - 시즌 4는 웹 브라우징, API 호출, 도구 사용, 에이전트 간 협업 등 에이전트의 실제 기능을 보안 학습에 반영한다. ## 에이전트 보안이 중요한 이유 - OWASP의 2026년 에이전트 애플리케이션 주요 위험에는 다음 문제가 포함된다. - 에이전트 목표 탈취 - 도구 오용 - 신원 및 권한 악용 - 영구 메모리 오염 - Dark Reading 설문에서는 사이버보안 전문가의 48%가 2026년 말까지 에이전트형 AI를 가장 큰 공격 벡터로 예상했다. - Cisco 보고서에 따르면 조직의 83%가 에이전트형 AI 도입을 계획했지만, 안전하게 배포할 준비가 됐다고 답한 비율은 29%에 불과했다. - 빠른 도입 속도와 낮은 보안 준비도의 격차가 새로운 취약점이 발생하는 환경을 만든다. - 따라서 방어 설계뿐 아니라 공격자가 어떤 방식으로 시스템을 악용하는지 직접 이해하는 것이 중요하다. ## ProdBot: 의도적으로 취약한 AI 비서 - 시즌 4의 실습 대상인 ProdBot은 터미널에서 실행되는 생산성 AI 비서다. - 다음 기능을 단계적으로 제공한다. - 자연어를 bash 명령으로 변환하고 실행 - 가상 웹 환경 탐색 - MCP 서버 연결 - 조직 승인 스킬 실행 - 세션 간 지속 메모리 저장 - 여러 전문 에이전트의 작업 조정 - 사용자의 최종 목표는 ProdBot이 노출해서는 안 되는 `password.txt`의 내용을 읽도록 만드는 것이다. - 모든 상호작용은 CLI에서 자연어로 진행되므로 별도의 AI나 프로그래밍 경험 없이도 실험할 수 있다. ## 다섯 단계로 확장되는 공격면 - **Level 1 — 셸 명령과 샌드박스** - ProdBot이 샌드박스 내부에서 bash 명령을 생성·실행한다. - 핵심 과제는 샌드박스 탈출 가능성을 찾는 것이다. - **Level 2 — 웹 접근** - 뉴스, 금융, 스포츠, 쇼핑 사이트로 구성된 가상 인터넷을 탐색한다. - 신뢰할 수 없는 웹 콘텐츠가 에이전트의 행동이나 지시를 오염시킬 수 있다. - **Level 3 — MCP 서버** - 주식 시세, 웹 브라우징, 클라우드 백업 등의 외부 도구 제공자와 연결된다. - 기능이 늘어나는 만큼 외부 도구의 권한과 입력 검증 문제가 새로운 진입점이 된다. - **Level 4 — 승인된 스킬과 지속 메모리** - 사전 제작된 자동화 플러그인을 실행하고 사용자 선호를 세션 간 기억한다. - 조직의 승인이나 기존 신뢰가 실제로 안전성을 보장하는지 검증해야 한다. - **Level 5 — 다중 에이전트 통합** - 6개의 전문 에이전트, 3개의 MCP 서버, 3개의 스킬, 가상의 오픈소스 프로젝트 웹이 결합된다. - 모든 에이전트가 샌드박스 처리되고 데이터가 사전 검증됐다는 가정을 공격 관점에서 시험한다. ## 실제 위협과 학습 목표 - 각 단계의 취약점은 에이전트 시스템이 기능을 추가하며 실제로 마주할 수 있는 공격 패턴을 반영한다. - 예로 언급된 `CVE-2026-25253`(CVSS 8.8, High, “ClawBleed”)는 악성 링크를 통해 인증 토큰을 탈취하고 OpenClaw 인스턴스를 완전히 장악할 수 있었던 원격 코드 실행 취약점이다. - 게임의 목적은 특정 익스플로잇 하나를 암기하는 것이 아니다. - 에이전트 아키텍처 검토 - 도구 통합 감사 - 외부 콘텐츠와 메모리의 신뢰성 평가 - 에이전트 간 데이터 전달 검증 - 이런 과정을 통해 실제 운영 환경에서 목표 탈취, 권한 남용, 프롬프트 오염, 도구 악용과 같은 패턴을 빠르게 식별하는 보안 감각을 기를 수 있다. 에이전트형 AI를 도입할 때는 기능 구현보다 먼저 도구 권한, 샌드박스 경계, 외부 입력 검증, 메모리 격리, 에이전트 간 신뢰 모델을 점검해야 한다. ProdBot 같은 공격·방어 실습을 통해 실제 시스템의 실패 가능성을 사전에 경험하는 것이 효과적인 준비 방법이다.

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

MCP 도입 확대: 더 단순하고 안전하며 비용 효율적인 기업용 MCP 배포를 위한 참조 아키텍처 (새 탭에서 열림)

Cloudflare는 기업 전반에 걸친 모델 컨텍스트 프로토콜(MCP) 도입을 안전하고 효율적으로 확장하기 위해, 자사의 보안 플랫폼(Cloudflare One)과 개발자 플랫폼을 결합한 참조 아키텍처를 구축했습니다. 이 아키텍처는 로컬 MCP 서버의 보안 취약성을 해결하기 위해 중앙 집중식 원격 MCP 서버 모델을 채택하고, 인증 및 데이터 유출 방지(DLP) 기능을 통합하여 거버넌스를 강화했습니다. 이를 통해 기업은 권한 확산이나 프롬프트 인젝션과 같은 위험을 관리하는 동시에, 토큰 비용을 절감하고 생산성을 높이는 에이전트 워크플로우를 구현할 수 있습니다. **원격 MCP 서버를 통한 가시성과 제어권 확보** - 로컬에서 호스팅되는 MCP 서버는 검증되지 않은 소프트웨어 사용과 공급망 공격의 위험이 크며, IT 관리자의 중앙 통제가 불가능하다는 단점이 있습니다. - Cloudflare는 사내 모노레포(Monorepo) 내에 중앙 관리형 MCP 플랫폼을 구축하여, 직원이 템플릿을 통해 승인된 인프라 위에서 원격 MCP 서버를 신속하게 배포할 수 있도록 지원합니다. - 모든 원격 MCP 서버는 Cloudflare의 글로벌 네트워크를 통해 배포되므로 전 세계 어디서든 낮은 지연 시간으로 접근이 가능하며, 관리자는 모든 사용 내역에 대한 가시성을 가집니다. **Cloudflare Access 기반의 강력한 인증** - 내부 자산에 접근하는 MCP 서버를 보호하기 위해 Cloudflare Access를 OAuth 제공자로 통합하여 권한이 부여된 직원만 접근할 수 있도록 제한합니다. - 단일 로그인(SSO), 다요소 인증(MFA)뿐만 아니라 IP 주소, 위치, 기기 인증서와 같은 컨텍스트 기반의 속성을 검증하여 보안 수준을 높입니다. - 공개된 리소스(문서, 레이더 등)와 내부 프라이빗 리소스에 대한 접근 권한을 명확히 분리하여 운영합니다. **MCP 서버 포털을 통한 중앙 집중식 거버넌스** - 직원이 사용 가능한 모든 MCP 서버를 쉽게 찾을 수 있도록 'MCP 서버 포털'을 제공하여 검색성(Discovery) 문제를 해결합니다. - 포털 내에서 중앙 집중식 로깅과 데이터 유출 방지(DLP) 규칙을 적용하여 개인정보(PII) 등의 민감 데이터가 외부로 유출되는 것을 차단합니다. - 사용자 역할에 따라 도구 노출 범위를 다르게 설정하는 정책을 시행할 수 있습니다. (예: 재무팀은 읽기 전용 도구만, 엔지니어링팀은 읽기/쓰기 도구 모두 노출) **비용 절감과 보안 감지 기술** - 모든 API 엔드포인트를 개별 도구로 정의할 때 발생하는 토큰 비용 문제를 해결하기 위해, 에이전트가 코드를 생성하여 API와 상호작용하는 '코드 모드(Code Mode)'를 도입하여 컨텍스트 창 최적화를 달성했습니다. - Cloudflare Gateway를 활용한 '섀도우 MCP(Shadow MCP)' 감지 기능을 통해 조직 내에서 승인되지 않은 원격 MCP 서버가 사용되는 것을 식별하고 통제합니다. - 포털, 원격 서버, 인증 시스템이 모두 Cloudflare의 동일한 물리적 네트워크 노드 내에서 작동하므로 보안 검사 과정에서 발생하는 네트워크 지연을 최소화합니다. 기업이 MCP를 성공적으로 도입하려면 개별 사용자의 로컬 실행에 의존하기보다는, 인증과 거버넌스가 결합된 중앙 관리형 원격 아키텍처를 구축하는 것이 필수적입니다. 이를 통해 보안 리스크를 관리하는 동시에 AI 에이전트 운영에 드는 비용 효율성까지 확보할 수 있습니다.

cloudflare원문

Access를 위한 관리형 OAuth: 클릭 한 번으로 내부 앱을 에이전트 대응 가능하게 만들기 (새 탭에서 열림)

Cloudflare는 내부 애플리케이션을 보호하는 'Cloudflare Access'에 클릭 한 번으로 활성화 가능한 'Managed OAuth' 기능을 도입하여 AI 에이전트의 접근성 문제를 해결했습니다. 기존에는 에이전트가 인증 페이지의 리다이렉션을 처리하지 못해 내부 데이터에 접근할 수 없었으나, 이제 OAuth 2.0 표준을 통해 에이전트가 사용자 대신 안전하게 인증을 수행하고 권한을 위임받을 수 있습니다. 이를 통해 기업은 수많은 레거시 앱의 코드를 수정하지 않고도 AI 에이전트가 즉시 활용할 수 있는 환경을 구축할 수 있게 되었습니다. **Managed OAuth의 작동 원리와 기술 표준** * Cloudflare Access가 직접 권한 부여 서버(Authorization Server) 역할을 수행하여 인증되지 않은 에이전트에게 `www-authenticate` 헤더를 반환합니다. * 에이전트는 RFC 9728 표준에 따라 `/.well-known/oauth-authorization-server` 경로에서 인증 서버 정보를 자동으로 탐색합니다. * RFC 7591(동적 클라이언트 등록)을 통해 에이전트가 자신을 클라이언트로 등록하고, RFC 7636(PKCE) 기반의 인증 흐름을 통해 보안성을 확보합니다. * 사용자가 인증을 승인하면 에이전트는 사용자 ID가 포함된 JWT(JSON Web Token)를 발급받아 이후 요청에 활용합니다. **레거시 앱의 즉각적인 AI 대응 환경 구축** * 수많은 내부 앱과 위키, REST API 등을 AI 에이전트가 읽을 수 있도록 개별적으로 코드를 수정하거나 별도의 MCP(Model Context Protocol) 서버를 구축할 필요가 없습니다. * Cloudflare Access 전면에 Managed OAuth를 활성화하는 것만으로 기존 앱들을 에이전트 친화적인 환경으로 즉시 업그레이드할 수 있습니다. * 특히 내부 위키와 같은 서비스의 경우 'Markdown for Agents' 기능과 Managed OAuth를 결합하여 에이전트가 보호된 콘텐츠를 원활하게 소비하도록 지원합니다. **서비스 계정 방식의 보안 한계 극복** * 정적 자격 증명을 사용하는 서비스 계정(Service Account) 방식은 감사 로그에서 실제 행위자를 파악하기 어렵고 '혼동된 대리인(Confused Deputy)' 문제에 취약합니다. * Managed OAuth는 모든 에이전트의 작업을 실제 사용자의 ID와 연결하므로, 사용자가 가진 권한 범위 내에서만 에이전트가 동작하도록 엄격히 제어합니다. * 이를 통해 기업은 보안 정책을 유지하면서도 어떤 사용자의 에이전트가 어떤 데이터에 접근했는지 명확한 감사 추적(Audit Log)을 남길 수 있습니다. **에이전트 도구의 표준 채택 권고** * 현재 대부분의 에이전트용 'web fetch' 도구는 HTTP 응답의 `www-authenticate` 헤더를 처리하지 못하는 한계가 있습니다. * Cloudflare는 에이전트가 MCP 서버뿐만 아니라 일반적인 웹 페이지나 API에 접근할 때도 RFC 9728 표준을 준수하여 자동으로 OAuth 흐름을 수행할 것을 제안합니다. * 이를 위해 오픈소스 프로젝트인 OpenCode의 web fetch 도구에 해당 표준을 적용하는 예시를 제시하며 에이전트 생태계의 표준화를 촉구하고 있습니다. 내부 인프라의 보안을 유지하면서 AI 에이전트의 활용도를 높이고 싶다면, 정적 토큰이나 서비스 계정 대신 Managed OAuth를 활성화하여 사용자 중심의 권한 위임 체계를 구축하는 것이 권장됩니다. 이는 보안 감사 가시성을 확보하는 동시에 가장 빠르고 효율적으로 내부 앱을 AI 시대에 맞게 현대화하는 방법입니다.

github3분 읽기큐레이션 요약

입문자를 위한 GitHub Copilot CLI: GitHub Copilot CLI 시작하기

GitHub Copilot CLI는 에이전트형 AI를 터미널에 통합해 코드 작성, 테스트 실행, 오류 수정 등을 지원하는 도구다. 이 글은 npm을 통한 설치부터 GitHub 인증, 폴더 권한 설정, 첫 프롬프트 실행까지의 시작 과정을 소개한다. 또한 프로젝트 분석, 엔드포인트 생성, Copilot Cloud Agent로 작업 위임 같은 활용 사례를 설명한다. ## GitHub Copilot CLI란? - Copilot의 에이전트 기능을 명령줄 환경에서 사용할 수 있게 해주는 도구다. - 저장소 전체 맥락을 바탕으로 파일을 탐색하고 코드를 작성할 수 있다. - 코드 빌드와 테스트 실행을 자율적으로 수행하며, 오류를 발견하면 스스로 수정할 수 있다. - 사용자는 작업을 요청한 뒤 결과를 검토하고 추가 변경을 지시할 수 있어, 다른 도구로 전환하지 않고 개발 흐름을 유지할 수 있다. - CLI에서 Copilot Cloud Agent에 작업을 위임하는 것도 가능하다. ## 설치 방법 Node.js가 설치되어 있다면 npm으로 전역 설치할 수 있다. ```bash npm install -g @github/copilot ``` - Windows에서는 WinGet, macOS에서는 Homebrew 등 패키지 관리자를 사용할 수도 있다. - 패키지 관리자별 정확한 설치 명령은 해당 도구의 문서를 확인해야 한다. ## 최초 실행과 인증 설치가 끝나면 터미널에서 `Copilot` 명령으로 실행한다. ```plaintext Copilot ``` 처음 사용하는 경우 `/login` 명령으로 GitHub 계정에 로그인한다. ```plaintext /login ``` 로그인 과정에서 다음 작업이 수행된다. - Copilot 클라이언트와 GitHub Copilot 계정을 연결한다. - GitHub 리소스에 접근할 수 있도록 읽기 전용 GitHub MCP 서버를 연결한다. ## 폴더 권한 설정 Copilot이 프로젝트를 분석하거나 파일을 수정하려면 해당 폴더에 대한 접근 권한을 부여해야 한다. - 현재 세션에서만 권한을 허용할 수 있다. - 같은 프로젝트에서 반복적으로 사용할 경우 권한 설정을 저장할 수 있다. - 파일을 생성하거나 수정하는 작업에서는 Copilot이 별도로 사용자 승인을 요청할 수 있다. - 권한을 부여한 뒤 자연어로 프로젝트 분석, 코드 작성, 테스트 등의 작업을 요청할 수 있다. ## 프로젝트 분석과 코드 생성 Copilot CLI는 저장소의 파일과 문서를 직접 탐색해 프로젝트 구조와 개발 관례를 파악한다. 예를 들어 다음과 같이 요청할 수 있다. ```plaintext Give me an overview of this project ``` - 주요 파일과 프로젝트 구성을 확인한 뒤 개요를 제공한다. - 새 기능을 요청하면 기존 문서와 코드 예제를 참고해 프로젝트 스타일에 맞추려 한다. - 예를 들어 카테고리 전체를 반환하는 새 엔드포인트를 추가하도록 요청할 수 있다. ```plaintext Let’s add a new endpoint to return all categories ``` - 파일 생성이나 변경 전에는 필요한 권한을 요청한다. ## Copilot Cloud Agent로 작업 위임 명확하게 정의된 작업은 CLI에서 Copilot Cloud Agent에 넘길 수 있다. ```plaintext /delegate Let’s deal with issue #14 to add the rest of the CRUD endpoints to games ``` 위임하면 Copilot이 다음 작업을 수행한다. - 현재 CLI 세션의 컨텍스트를 유지한다. - 새 브랜치를 생성한다. - 초안 상태의 Pull Request를 연다. - 백그라운드에서 요청된 변경 작업을 진행한다. - 작업 완료 후 사용자가 결과를 검토하도록 한다. ## 이후 학습할 기능 이 글은 입문 시리즈의 첫 번째 내용으로, 다음 주제들이 후속 글에서 다뤄질 예정이라고 안내한다. - 대화형 모드와 비대화형 모드 비교 - `-p` 플래그를 이용한 빠른 요약 - Copilot CLI의 슬래시 명령 - MCP 서버 연동 - CLI 사용법과 모범 사례 Copilot CLI는 터미널을 떠나지 않고 프로젝트를 이해하고 코드를 수정할 수 있게 해주는 도구다. 처음에는 작은 프로젝트 개요나 단순한 기능 추가부터 사용하고, 파일 변경과 권한 요청 결과를 직접 검토하면서 점차 작업 위임 범위를 넓히는 것이 좋다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

Copilot Applied Science의 에이전트 주도 개발

GitHub Copilot Applied Science 팀의 Tyler McGoffin은 코딩 에이전트를 활용해 벤치마크 결과 분석에 필요한 지적 반복 작업을 자동화한 프로젝트 `eval-agents`를 만들었다. 핵심은 에이전트를 단순한 코드 생성기가 아니라 계획·구현·검증에 참여하는 협업자로 활용하고, 에이전트가 기여하기 쉬운 저장소 구조를 만드는 것이다. 그 결과 3일도 안 되어 5명이 11개 에이전트와 4개 스킬을 추가하고, 345개 파일에 걸쳐 약 2만 8천 줄의 변경을 만들어냈다. ## 반복적인 벤치마크 분석에서 `eval-agents` 탄생 - 연구자는 TerminalBench2, SWEBench-Pro 같은 코딩 에이전트 평가 벤치마크를 분석한다. - 각 평가 작업은 에이전트의 사고 과정과 행동을 담은 trajectory로 기록되며, 대개 수백 줄의 `.json` 파일로 저장된다. - 수십 개 작업과 여러 번의 벤치마크 실행을 합치면 분석 대상이 수십만 줄에 달한다. - 기존에는 Copilot으로 trajectory에서 패턴을 먼저 찾은 뒤 사람이 직접 조사해 읽어야 할 분량을 수백 줄로 줄였다. - 이 반복 과정을 에이전트가 자동 수행하도록 만든 도구가 `eval-agents`다. ## 프로젝트 설계 목표 - 에이전트를 쉽게 공유하고 사용할 수 있도록 구성한다. - 새로운 에이전트를 쉽게 작성할 수 있도록 한다. - 사람보다 코딩 에이전트가 프로젝트 기여의 주요 수단이 되도록 설계한다. - 특히 세 번째 목표를 적용하자 프로젝트 자체의 사용성과 협업성도 함께 좋아졌다. - 과학자와 엔지니어가 각자의 필요에 맞는 에이전트와 기능을 직접 추가할 수 있는 기반이 마련됐다. ## 코딩 에이전트를 중심으로 한 개발 환경 - 코딩 에이전트: Copilot CLI - 사용 모델: Claude Opus 4.6 - IDE: VS Code - Copilot SDK를 사용해 Copilot CLI의 도구, MCP 서버, 사용자 정의 도구와 스킬 등록 기능을 재활용했다. - 에이전트 실행 기반을 직접 처음부터 만들지 않아도 되어 에이전트 생성 속도를 높일 수 있었다. ## 효과적인 프롬프트 전략 - 에이전트는 범위가 명확한 작업에는 강하지만, 복잡하고 고차원적인 문제에는 충분한 안내가 필요하다. - 짧은 요구사항보다 문제를 고민하는 과정, 전제, 우려 사항을 자세히 설명하는 대화형 프롬프트가 효과적이다. - 바로 구현을 지시하기보다 계획 모드에서 조사와 설계를 먼저 진행하게 하는 것이 좋다. - 예를 들어 테스트가 에이전트의 변경에 맞춰 부적절하게 수정되는 문제를 해결하기 위해, 계획 모드에서 에이전트가 건드릴 수 없는 보호된 테스트 영역을 설계하도록 했다. - 그 대화의 결과로 사람이 승인해야만 수정할 수 있는 계약 테스트와 유사한 회귀 방지 장치가 만들어졌다. - 결론적으로 효과적인 인간 엔지니어에게 필요한 설명, 사고 유도, 검토 과정이 에이전트에도 동일하게 중요하다. ## 에이전트 우선 저장소를 위한 아키텍처 전략 - 에이전트 중심 프로젝트에서는 새 기능보다 코드 구조 개선, 리팩터링, 문서화, 테스트 작성이 더 중요한 기반 작업이 된다. - 명확한 이름과 파일 구조는 에이전트가 코드를 탐색하고 변경하기 쉽게 만든다. - 기능과 패턴을 문서화하면 에이전트가 프로젝트의 규칙과 설계 의도를 더 잘 따를 수 있다. - 발견된 문제를 테스트 케이스로 남기면 이후 에이전트의 변경으로 인한 회귀를 방지할 수 있다. - 에이전트가 기능을 빠르게 추가할수록 사람이 죽은 코드와 불필요한 복잡성을 정리하는 작업도 병행해야 한다. - 잘 관리된 저장소에서는 Copilot을 통한 기능 전달이 쉬워지므로, 과거에 미뤄두었던 유지보수 작업이 개발 생산성의 핵심 요소가 된다. ## 짧은 기간에 이루어진 협업 성과 - 처음 참여한 팀원 5명이 3일 이내에 프로젝트에 기여했다. - 새로 추가된 항목: - 에이전트 11개 - 스킬 4개 - 과학자의 추론 흐름을 표현하는 `eval-agent workflows` - 전체 변경 규모는 345개 파일에서 `+28,858/-2,884`줄이었다. - 이는 에이전트에게 적절한 개발 환경과 구조를 제공하면 새로운 기능과 협업을 매우 빠르게 확장할 수 있음을 보여준다. 에이전트를 효과적으로 활용하려면 좋은 프롬프트만으로는 부족하다. 계획 모드와 상세한 대화를 적극 활용하고, 문서·테스트·리팩터링을 지속해 에이전트가 이해하기 쉬운 저장소를 유지하는 것이 실용적인 출발점이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

에이전트, Figma 캔버스를 만나다 | Figma 블로그

Figma는 이제 AI 에이전트가 디자인 캔버스에서 직접 파일과 컴포넌트를 생성·수정할 수 있도록 지원한다. MCP 서버의 `use_figma` 도구와 Markdown 기반 스킬을 통해 에이전트가 팀의 디자인 시스템, 컴포넌트, 변수, 작업 규칙을 활용하게 되며, 결과적으로 코드와 디자인 사이의 단절을 줄이는 것이 목표다. 이 기능은 현재 베타 기간 동안 무료로 제공되지만 향후 사용량 기반 유료 기능으로 전환될 예정이다. ## AI 에이전트가 Figma 캔버스에서 작업 - Claude Code, Codex 등 MCP 클라이언트가 `use_figma` 도구를 통해 Figma 파일과 컴포넌트를 직접 생성하고 수정할 수 있다. - 에이전트는 색상, 버튼 패딩, 타이포그래피, 인터랙션 같은 팀의 디자인 결정을 Figma 안에서 참조한다. - 기존처럼 AI가 일반적이고 브랜드와 동떨어진 디자인을 만드는 대신, 조직의 디자인 시스템에 연결된 결과물을 생성할 수 있다. - 코드에서 시작한 작업도 Figma에서 검토·수정할 수 있고, Figma에서 결정한 내용을 다시 개발 과정에 반영할 수 있다. ## `generate_figma_design`과 `use_figma`의 역할 분담 - `generate_figma_design` - 실제 웹사이트나 애플리케이션의 HTML을 Figma 레이어로 변환한다. - 코드와 디자인이 달라졌을 때 최신 UI를 Figma로 가져오는 데 사용된다. - `use_figma` - Figma 캔버스에서 기존 디자인을 수정하거나 새로운 디자인 자산을 생성한다. - 팀의 컴포넌트, 변수, 자동 레이아웃 등 실제 디자인 시스템을 활용한다. - 두 도구를 함께 사용하면 코드의 최신 상태를 Figma로 가져온 뒤, 에이전트가 디자인 시스템에 맞춰 재구성하고 개선할 수 있다. ## Markdown으로 정의하는 Figma 스킬 - 스킬은 에이전트가 Figma에서 작업하는 방법을 설명하는 Markdown 파일 기반 지침이다. - 특정 작업의 순서, 적용해야 할 규칙, 팀의 디자인 관례와 품질 기준을 명시할 수 있다. - 플러그인을 개발하거나 별도의 코드를 작성하지 않아도 누구나 스킬을 만들 수 있다. - 기본 스킬인 `/figma-use`는 Figma의 구조와 핵심 원칙을 에이전트에게 알려주며, 팀은 이를 확장해 자체 업무 방식에 맞출 수 있다. - 스킬은 단순한 문서가 아니라 에이전트가 실제 작업 중 따라야 하는 실행 규칙으로 작동한다. ## 제공되는 스킬 사례 - `/figma-generate-library`: 코드베이스에서 Figma 컴포넌트 라이브러리 생성 - `/figma-generate-design`: 기존 컴포넌트와 변수를 사용해 새로운 디자인 생성 - `/create-voice`: UI 명세에서 VoiceOver, TalkBack, ARIA용 스크린 리더 사양 생성 - `/apply-design-system`: 기존 디자인을 디자인 시스템 컴포넌트와 연결 - `/rad-spacing`: 변수와 폴백을 사용해 계층적인 간격 적용 - `/sync-figma-token`: 코드와 Figma 변수 사이의 디자인 토큰 동기화 및 변경 감지 - `/multi-agent`: 여러 에이전트가 디자인 구현 작업을 병렬로 수행 - 커뮤니티 실무자가 만든 JSON 기반 컴포넌트 생성, 디자인 워크플로 오케스트레이션 등의 스킬도 제공된다. ## 구조 기반의 자기 수정 - 에이전트는 화면을 생성한 뒤 스크린샷을 찍고, 결과가 목표와 다른 부분을 확인해 반복적으로 수정할 수 있다. - 수정 대상이 단순한 픽셀이 아니라 실제 컴포넌트, 변수, 자동 레이아웃, 레이어 구조이므로 디자인 시스템과 상호작용하며 개선된다. - AI 모델의 비결정성 때문에 같은 프롬프트라도 결과가 달라질 수 있지만, 스킬이 작업 순서와 기준을 고정해 결과를 더 예측 가능하게 만든다. - 기존의 디자인 규칙과 팀 관례가 정적인 문서에 머무르지 않고, 에이전트가 작업 중 실제로 적용하는 규칙이 된다. ## 실용적인 의미 팀은 `use_figma`와 `/figma-use`를 기반으로 자체 디자인 스킬을 만들고, 컴포넌트·변수·토큰 사용 규칙을 명시하는 것이 좋다. 특히 코드와 Figma가 자주 어긋나는 조직이라면 `generate_figma_design`으로 최신 UI를 동기화한 뒤, `use_figma`와 스킬을 이용해 브랜드와 디자인 시스템에 맞게 다듬는 워크플로가 효과적이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

제15호: 디자인의 현주소 | 피그마 블로그

AI 도구와 워크플로가 디자인 방식을 근본적으로 바꾸면서, 디자인은 더 이상 특정 매체나 툴에 한정되지 않고 코드와 캔버스를 오가는 활동이 되고 있다. Figma의 조사에 따르면 디자이너의 91%가 AI가 업무 수준을 높인다고 답했으며, 채용 담당자의 82%는 디자이너 수요가 유지되거나 증가했다고 응답했다. 따라서 AI 시대의 디자이너에게는 전통적인 디자인 역량과 함께 문제 해결, 협업, AI 활용 능력이 중요해지고 있다. ## AI가 바꾸는 디자이너의 역할 - AI 도구는 디자이너의 작업 방식을 변화시키고 있으며, 단순한 제작 자동화를 넘어 아이디어 발상과 문제 해결에도 활용된다. - 디자이너가 무엇을 통해 가치를 만드는지는 사람마다 다르다. - 시각적 완성도 향상 - 복잡한 문제에 대한 사고 - 직관적인 사용자 경험 설계 - 이러한 가치 기준은 디자이너의 직무 만족도와 업무 경험에도 직접적인 영향을 준다. - 디자인 업무는 특정 매체에 고정되지 않고, 코드와 시각적 캔버스 사이를 자유롭게 오가는 방향으로 확장되고 있다. ## 디자인 채용 수요는 여전히 증가 - AI의 확산이 디자인 채용을 줄일 것이라는 전망과 달리, 조사 결과 기업의 디자이너 수요는 안정적이거나 증가하고 있다. - 전 세계 채용 담당자의 82%가 디자이너 채용 수요가 유지되거나 늘었다고 답했다. - 수요 증가는 기술 기업에만 국한되지 않고 다양한 산업으로 확산되고 있다. - AI가 제품 개발 속도를 높일수록 다음과 같은 역할이 더 중요해진다. - 사용자 문제를 정의하는 능력 - 제품 방향성을 시각화하는 능력 - 기술과 비즈니스 요구를 사용자 경험으로 연결하는 능력 - AI가 결과물을 생성하더라도, 어떤 문제를 풀고 무엇을 만들어야 하는지 판단하는 일은 여전히 사람의 역할이다. ## AI 시대에 요구되는 역량 - 프롬프트 작성 능력과 MCP 같은 AI 연동 기술을 이해하는 역량이 새로운 경쟁력으로 부상하고 있다. - AI 워크플로를 실제 디자인·개발 과정에 연결하고 자동화하는 능력이 중요하다. - 서로 다른 직군 사이에서 정보를 번역하고 협업을 이끄는 능력도 높은 가치를 갖는다. - 디자이너와 개발자 간 커뮤니케이션 - 제품 관리자와 디자인팀 간 요구사항 조율 - 기술적 제약과 사용자 요구의 연결 - 새로운 도구를 익히는 것만으로는 충분하지 않으며, 디자인의 기본기 역시 계속 중요하다. - 사용자 중심 사고 - 시각적 계층 구조 - 인터랙션 설계 - 문제 정의와 검증 - 결국 AI 활용 능력은 기존 디자인 역량을 대체하기보다 이를 확장하는 방향으로 작동한다. ## 프로토타이핑과 제품 의사결정의 변화 - Figma Make를 활용하면 제품 관리자도 아이디어를 빠르게 프로토타입으로 구현할 수 있다. - 프로토타입은 단순한 시각 자료를 넘어 제품의 복잡한 동작과 가능성을 검증하는 수단이 된다. - ServiceNow, Ticketmaster, Affirm 등의 제품팀은 프로토타이핑을 통해 다음을 수행하고 있다. - 복잡한 동작을 구체적으로 전달 - 아이디어의 한계를 빠르게 실험 - 제품 로드맵의 다음 방향에 대한 확신 확보 - 아이디어가 디자인팀에서만 시작되는 것이 아니라 제품, 개발, 기획 등 어느 직군에서든 시작될 수 있는 환경이 만들어지고 있다. ## 코드와 캔버스가 결합하는 미래 - 디자인의 미래는 코드와 시각적 캔버스가 서로 분리된 영역으로 남는 것이 아니라, 두 환경이 유기적으로 연결되는 방향으로 제시된다. - 아이디어는 코드로 구현되거나 캔버스에서 시각화된 뒤, 다시 서로 다른 형태로 발전할 수 있다. - 이 변화는 디자이너가 코드를 반드시 전문적으로 작성해야 한다는 의미라기보다, 구현 가능성과 기술적 구조를 이해해야 한다는 뜻에 가깝다. - 디자인 도구는 특정 직군만 사용하는 제작 프로그램에서, 여러 직군이 함께 사고하고 검증하는 협업 환경으로 확장되고 있다. AI 시대에는 새로운 도구를 많이 아는 것보다, AI를 활용해 더 나은 문제를 정의하고 빠르게 검증하며 다양한 직군을 연결하는 능력이 중요하다. 디자이너는 프롬프트와 자동화 기술을 익히되 사용자 중심 사고와 디자인 기본기를 함께 강화하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

‘텍스트로서의 AI’ 시대는 끝났다. 실행이 새로운 인터페이스다.

이 글은 AI가 단순히 텍스트를 주고받는 도구를 넘어, 계획을 세우고 도구를 호출하며 실제 작업을 수행하는 실행 계층으로 발전하고 있다고 주장합니다. GitHub Copilot SDK를 사용하면 애플리케이션에 Copilot CLI의 검증된 계획·실행 엔진을 직접 내장할 수 있습니다. 이를 통해 개발자는 고정된 자동화 스크립트나 자체 오케스트레이션 계층을 만들지 않고도, 제약 조건 안에서 적응적으로 동작하는 에이전트형 시스템을 구축할 수 있습니다. ## 텍스트 기반 AI에서 실행 기반 AI로 - 기존 AI 사용 방식은 텍스트를 입력하고 텍스트를 받은 뒤, 사용자가 다음 행동을 직접 결정하는 구조였습니다. - 실제 운영 소프트웨어는 다음과 같은 실행 루프를 필요로 합니다. - 작업 계획 수립 - 도구 호출 - 파일 및 시스템 변경 - 명령 실행 - 오류 복구 - 실행 중 상황 변화에 따른 대응 - 따라서 AI의 핵심 인터페이스가 텍스트가 아니라, 제약 조건과 관찰 가능성을 갖춘 실행으로 바뀌고 있습니다. ## 여러 단계 작업을 에이전트에 위임 - 기존 스크립트는 작업 단계가 고정되어 있을 때는 유용하지만, 상황에 따라 흐름이 바뀌거나 오류 복구가 필요하면 취약해집니다. - Copilot SDK를 사용하면 애플리케이션이 구체적인 절차 대신 작업의 의도와 제약 조건을 전달할 수 있습니다. - 예를 들어 “이 저장소를 릴리스 준비 상태로 만들어라”라고 요청하면 에이전트가 다음을 수행할 수 있습니다. - 저장소 구조 탐색 - 필요한 작업 계획 수립 - 파일 수정 - 명령 실행 - 실패 발생 시 대안 적용 및 복구 - 고정된 예외 처리를 직접 작성하지 않고도, 규모가 커지는 업무 흐름에 적응하는 자동화를 구현할 수 있다는 점이 핵심입니다. ## 구조화된 런타임 컨텍스트 활용 - 시스템 로직을 프롬프트에 계속 추가하면 프롬프트가 복잡하고 취약해지며, 테스트와 유지보수가 어려워집니다. - Copilot SDK는 컨텍스트를 텍스트가 아닌 구조화되고 조합 가능한 도구와 데이터로 제공합니다. - 애플리케이션은 다음과 같은 방식으로 실행 환경을 확장할 수 있습니다. - 도메인 전용 도구 및 에이전트 스킬 정의 - Model Context Protocol(MCP)을 통한 도구 연결 - 실행 시점에 필요한 컨텍스트 검색 - 예를 들어 에이전트가 직접 다음 정보를 조회할 수 있습니다. - 서비스 소유 팀 - 과거 의사결정 기록 - 의존성 그래프 - 내부 API 스키마 - 권한과 안전 제약 조건 - MCP는 에이전트가 실제 시스템과 권한이 부여된 데이터에 근거해 행동하도록 연결하는 기반 역할을 합니다. ## IDE 밖에 실행 기능 내장 - AI 기능은 더 이상 IDE나 터미널 안에서만 제공될 필요가 없습니다. - Copilot SDK를 활용하면 다음과 같은 애플리케이션에 에이전트 실행을 통합할 수 있습니다. - 데스크톱 애플리케이션 - 사내 운영 도구 - 백그라운드 서비스 - SaaS 플랫폼 - 이벤트 기반 시스템 - 파일 변경, 배포 이벤트, 사용자 동작 등을 감지한 뒤 애플리케이션에서 Copilot을 프로그래밍 방식으로 호출할 수 있습니다. - 결과적으로 AI는 별도의 보조 창이 아니라 제품 내부에서 실행되는 인프라가 됩니다. ## 애플리케이션 아키텍처의 변화 - Copilot SDK는 Copilot CLI를 구동하는 계획·실행 엔진을 애플리케이션의 프로그래밍 가능한 계층으로 제공합니다. - 개발자는 매번 오케스트레이션 로직을 새로 구축하기보다, 애플리케이션이 달성해야 할 목표와 실행 가능한 범위를 정의하는 데 집중할 수 있습니다. - 다만 실제 운영 환경에서는 도구 권한, 안전 제약, 실행 결과 관찰, 오류 처리 등을 명확히 설계해야 합니다. Copilot SDK는 AI를 “답변을 생성하는 기능”에서 “실제 업무를 수행하는 시스템 구성 요소”로 확장하려는 접근입니다. 반복 작업이나 복잡한 운영 흐름에 적용할 때는 의도 중심의 에이전트 실행, MCP 기반의 구조화된 컨텍스트, 명확한 권한·안전 제약을 함께 설계하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

내부 살펴보기: GitHub

GitHub Agentic Workflows는 에이전트를 기존 CI/CD에 통합하되, 에이전트의 비결정성과 프롬프트 인젝션 위험을 전제로 설계된 보안 아키텍처를 사용합니다. 핵심은 자유로운 에이전트 작성과 통제된 실행을 분리하고, 워크플로를 명시적인 권한·출력·네트워크·감사 제약이 있는 GitHub Actions로 컴파일하는 것입니다. 특히 에이전트에 비밀을 직접 제공하지 않고, 계층적 격리와 단계적 쓰기 검증으로 피해 범위를 제한합니다. ## 에이전트 자동화가 만드는 새로운 위협 - 에이전트는 저장소 상태와 외부 입력을 해석해 런타임에 자율적으로 결정을 내리므로 기본적으로 신뢰할 수 없습니다. - GitHub Actions는 구성 요소들이 하나의 신뢰 도메인에서 실행되는 비교적 개방적인 환경입니다. - 에이전트가 손상되면 다음과 같은 행동이 가능해질 수 있습니다. - MCP 서버와 상호작용 - 인증 토큰과 환경 변수 접근 - 임의의 인터넷 호스트로 네트워크 요청 - 악성 이슈·웹 페이지를 통한 프롬프트 인젝션 실행 - 원치 않는 커밋, 댓글, 이슈 생성 - 따라서 기본 보안 모드는 에이전트가 읽거나 쓰면 안 되는 상태에 접근하고, 허가되지 않은 통신 채널을 악용한다고 가정합니다. ## 다층 방어 구조 GitHub Agentic Workflows는 **기반 인프라(substrate)**, **구성(configuration)**, **계획(planning)**의 세 계층으로 방어합니다. - **기반 인프라 계층** - GitHub Actions 러너 VM과 신뢰된 컨테이너를 사용합니다. - 컨테이너 격리, 커널 수준 통신 경계, 권한 있는 작업과 시스템 호출 중재를 제공합니다. - 사용자 수준 구성 요소가 손상되어 컨테이너 내부에서 임의 코드를 실행하더라도 격리 경계를 넘는 피해를 제한합니다. - **구성 계층** - 어떤 구성 요소를 실행하고 서로 어떻게 연결할지 선언적으로 정의합니다. - 허용되는 통신 채널과 각 구성 요소의 권한을 결정합니다. - 에이전트 API 키와 GitHub 토큰 같은 외부 자격 증명을 어떤 컨테이너에 주입할지 통제합니다. - 컴파일러, 방화벽 정책, MCP 설정 등이 이 계층에 포함됩니다. - **계획 계층** - 구성 계층이 정한 구성 요소들을 언제, 어떤 순서로 실행할지 결정합니다. - 구성 요소 간 데이터 교환을 명시한 단계적 워크플로를 생성합니다. - 안전한 출력 시스템을 통해 쓰기 작업을 검증하고 제한하는 역할을 담당합니다. ## 에이전트에 비밀을 제공하지 않는 설계 - 일반적인 GitHub Actions 환경에서는 여러 프로세스가 환경 변수와 설정 파일에 저장된 토큰을 볼 수 있습니다. - 프롬프트 인젝션을 받은 에이전트는 셸 도구를 이용해 다음 정보에 접근할 수 있습니다. - 설정 파일 - SSH 키 - Linux `/proc` 상태 - 워크플로 로그 - 탈취한 자격 증명은 외부 웹사이트로 전송하거나 공개 이슈·풀 리퀘스트·댓글에 삽입할 수 있습니다. - 이를 막기 위해 에이전트를 별도 컨테이너에서 실행하고 네트워크 경로를 제한합니다. - 인터넷 접속은 방화벽을 통해 통제 - MCP 호출은 신뢰된 MCP 게이트웨이를 통해서만 허용 - LLM 호출은 API 프록시를 통해 중계 - MCP 게이트웨이는 별도의 신뢰 컨테이너에서 MCP 서버를 실행하며, MCP 인증 정보에 독점적으로 접근합니다. - 에이전트 컨테이너는 LLM 인증 토큰을 직접 보지 않고, 격리된 API 프록시가 인증을 대신 처리하는 구조를 사용합니다. ## 네트워크와 권한의 제한 - 에이전트와 방화벽 사이에 전용 사설 네트워크를 구성해 인터넷 연결을 통제합니다. - 허용 목록 기반 방화벽 정책으로 에이전트가 통신할 수 있는 대상과 채널을 제한합니다. - MCP 서버와 LLM API를 직접 노출하지 않고 각각 게이트웨이와 프록시 뒤에 배치합니다. - 이 구조는 에이전트가 손상되더라도 임의의 외부 호스트로 데이터를 반출하거나 인증 서비스를 직접 악용하는 가능성을 줄입니다. ## 안전한 쓰기와 감사 가능성 - 에이전트가 저장소나 GitHub 객체에 직접 자유롭게 쓰지 못하도록 출력 단계를 별도로 통제합니다. - 계획 계층의 안전한 출력 시스템은 다음을 담당하도록 설계됩니다. - GitHub 쓰기 작업의 허용 여부 결정 - 호출 가능한 기능과 호출 횟수 제한 - 출력에서 비밀 정보 제거 - 부적절하거나 원치 않는 내용 조정 - 에이전트의 실행 결과와 외부 효과를 추적할 수 있도록 모든 작업을 기록하는 원칙을 적용합니다. - 결과적으로 에이전트의 자유로운 추론 능력은 유지하되, 실제 커밋·댓글·이슈 생성 같은 효과는 검증된 단계와 명시적 정책을 거쳐야 합니다. ## 실용적인 결론 에이전트 기반 CI/CD를 도입할 때는 에이전트를 일반 스크립트처럼 신뢰하지 말고, 처음부터 침해 가능성을 전제로 설계해야 합니다. 별도 컨테이너 격리, 비밀의 프록시 위임, 허용 목록 네트워크, 단계적 쓰기 검증, 전체 감사 로그를 함께 적용하는 것이 안전한 기본값입니다.

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

GitLab Duo 에이전 (새 탭에서 열림)

GitLab Duo Agent Platform이 MCP(Model Context Protocol)를 지원함에 따라, 이제 개발자들은 Jira와 같은 외부 도구를 AI 개발 환경에 직접 연결하여 사용할 수 있게 되었습니다. 이를 통해 IDE를 벗어나지 않고도 자연어 대화만으로 Jira 이슈를 조회, 생성 및 업데이트하며 프로젝트 관리와 코드 작성을 통합할 수 있습니다. 결과적으로 도구 간의 빈번한 맥락 전환(Context Switching)을 줄여 개발 생산성을 극대화하고 워크플로우를 단순화할 수 있는 강력한 환경을 제공합니다. ### MCP 연동 아키텍처 및 보안 설정 * GitLab Duo Agent Platform은 MCP 클라이언트 역할을 수행하며, Atlassian MCP 서버와 통신하여 Jira 데이터에 접근합니다. * 보안 인증을 위해 Atlassian 개발자 콘솔에서 OAuth 2.0 애플리케이션을 생성해야 하며, `read:jira-work`, `write:jira-work`, `read:jira-user`와 같은 구체적인 API 권한(Scope) 설정이 필요합니다. * 인증 과정에서 콜백 URL(`https://gitlab.com/oauth/callback`)을 등록하고 발급된 Client ID와 Secret을 안전하게 관리해야 합니다. ### GitLab Duo MCP 클라이언트 구성 및 검증 * 프로젝트의 `.gitlab/duo/mcp.json` 경로에 MCP 서버 설정 파일을 생성합니다. 이 파일에는 서버 URL과 앞서 발급받은 OAuth 인증 정보가 포함됩니다. * GitLab 그룹 설정의 'GitLab Duo' 메뉴에서 외부 MCP 도구 허용 옵션(`Allow external MCP tools`)을 활성화해야 정상적으로 작동합니다. * VS Code 내 'GitLab: Show MCP Dashboard' 기능을 통해 연결 상태를 모니터링할 수 있으며, `jira_get_issue`, `jira_create_issue` 등 사용 가능한 도구 목록과 실시간 서버 로그를 확인할 수 있습니다. ### 실무 적용을 위한 주요 활용 사례 * **기획 및 관리 보조:** "할당되지 않은 이슈 목록 보여줘", "우선순위가 높은 이슈 2개를 요약하고 나에게 할당해줘"와 같은 프롬프트를 통해 스프린트 계획을 IDE 내에서 즉시 처리할 수 있습니다. * **코드 맥락 기반 이슈 생성:** 코드 리뷰 중 버그를 발견했을 때, 별도의 브라우저 실행 없이 현재 코드의 맥락을 포함하여 Jira 티켓을 즉시 생성하고 관련 브랜치와 연결할 수 있습니다. * **워크플로우 자동화:** 자연어 요청을 통해 Jira의 복잡한 필드를 자동으로 채우거나, 코드 분석 결과에 따라 관련 블로커(Blocker)를 검색하는 등 지능적인 협업이 가능해집니다. 개발팀은 MCP를 활용해 Jira뿐만 아니라 MCP 규격을 지원하는 다양한 외부 도구를 GitLab Duo에 통합함으로써 커스텀 AI 에이전트 환경을 구축할 수 있습니다. 툴 간 전환 비용을 줄이고 개발 집중도를 높이고 싶다면, 가이드에 따라 `.gitlab/duo/mcp.json` 설정을 완료하고 첫 번째 MCP 워크플로우를 시작해 보시기 바랍니다.

figma3분 읽기큐레이션 요약

Codex와 Figma로 프론트

Codex와 Figma MCP 서버를 연결하면 디자인과 실행 중인 프론트엔드 UI를 양방향으로 오갈 수 있다. Figma의 디자인 정보를 Codex에 전달해 코드를 생성하고, 구현된 UI를 다시 편집 가능한 Figma 프레임으로 가져와 검토·협업·개선한 뒤 변경 사항을 코드에 반영하는 방식이다. 이를 통해 초기 디자인이나 코드에 고정되지 않고, 탐색과 구현을 반복하며 더 나은 제품을 만들 수 있다. ## Figma 디자인에서 앱 시작하기 - Figma MCP 서버는 **Figma Design, Figma Make, FigJam** 파일의 정보를 Codex에 전달한다. - 구현할 Figma 파일에서 원하는 프레임이나 노드를 우클릭한 뒤 **“Copy as → Copy link to selection”**을 선택한다. - 복사한 선택 URL은 단일 요소, 컴포넌트 묶음 등 특정 캔버스 영역을 가리키며, 에이전트가 코드 생성에 사용할 원본 데이터가 된다. - Codex에서 새 프로젝트나 기존 프로젝트를 선택하고 다음과 같은 방식으로 요청한다. - “이 Figma 디자인을 코드로 구현하고, 기존 디자인 시스템 컴포넌트를 최대한 활용해줘.” - Codex는 Figma MCP 서버의 `get_design_context` 도구를 호출해 다음 정보를 추출한다. - 레이아웃 구조 - 스타일 - 컴포넌트 정보 - 기타 디자인 관련 컨텍스트 - 이 정보를 바탕으로 Codex가 디자인에 맞는 UI 코드를 생성한다. ## 코드에서 Figma 캔버스로 가져오기 - 코드에서 UI를 구현하고 반복 수정한 뒤, 실행 중인 화면을 Figma로 가져와 시각적으로 비교하고 대안을 탐색할 수 있다. - 앱은 로컬 환경이나 공개 웹 서버에서 렌더링할 수 있다. - Codex에 새 Figma Design 파일을 생성하도록 요청하면 다음 과정을 안내한다. 1. 새 파일 또는 기존 파일 선택 2. 파일을 저장할 워크스페이스 선택 3. UI 캡처를 위한 애플리케이션 설정 4. 브라우저에서 앱 세션 열기 - Figma MCP 서버의 `generate_figma_design` 도구는 실행 중인 인터페이스를 편집 가능한 Figma 프레임으로 변환한다. ## UI 캡처 기능 앱이 다시 로드되면 화면 상단에 캡처 도구 모음이 표시된다. - **Entire screen**: 현재 표시된 전체 화면을 Figma 파일로 캡처 - **Select element**: 페이지에서 특정 컴포넌트나 요소만 선택해 캡처 - **Open file**: 생성된 디자인 레이어를 Figma에서 확인 캡처가 끝나면 Figma 파일을 바로 열거나 Codex로 돌아갈 수 있으며, Codex에는 해당 Figma 파일 URL이 전달된다. ## 캔버스에서 UI 개선하기 Figma로 가져온 실행 UI는 단순 이미지가 아니라 추가 편집과 협업이 가능한 디자인 자료로 활용된다. - 디자인 시스템 컴포넌트 추가 - 스타일, 글꼴, 색상을 변수로 전환 - 레이아웃 조정 및 주석 작성 - 인터랙션과 빈 상태 화면 설계 - 여러 UI 변형안과 탐색안 비교 - 팀원과 캔버스에서 공동 검토 수정이 끝나면 처음과 동일하게 프레임 또는 노드의 선택 URL을 복사해 Codex에 전달하고, Figma MCP 서버를 통해 변경된 디자인을 애플리케이션 코드에 반영할 수 있다. ## 디자인과 코드의 왕복 workflow - 디자인에서 시작해 Codex로 구현한다. - 실행 중인 UI를 Figma로 가져와 실제 결과를 검토한다. - Figma 캔버스에서 스타일, 컴포넌트, 레이아웃, 상태를 개선한다. - 변경된 디자인 컨텍스트를 다시 Codex로 보내 코드에 반영한다. - 이 과정을 반복하면서 속도를 유지한 채 프로토타입부터 실제 서비스 UI까지 발전시킬 수 있다. 실무에서는 먼저 Figma에 디자인 시스템과 핵심 화면을 정리한 뒤 Codex에 전달하고, 생성된 UI를 `generate_figma_design`으로 다시 캔버스에 가져와 시각적 차이를 검토하는 방식을 추천한다. 이를 통해 코드 구현과 디자인 의사결정을 분리하지 않고 하나의 반복 가능한 작업 흐름으로 통합할 수 있다.

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

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 (새 탭에서 열림)

현재 많은 개발팀이 LLM을 도입하고 있지만, 실제 생산성은 엔지니어 개개인의 'LLM 리터러시'에 따라 극심한 격차를 보이고 있습니다. 이러한 '각자도생'의 한계를 극복하기 위해서는 LLM을 개인의 도구가 아닌 팀 차원의 시스템으로 편입시켜 전체적인 생산성의 저점(Floor)을 높이는 전략이 필요합니다. Claude Code와 같은 생태계를 활용해 팀의 노하우를 '실행 가능한 지식(Executable SSOT)'으로 자산화하는 것이 Software 3.0 시대의 핵심 경쟁력이 될 것입니다. **컨텍스트 엔지니어링과 LLM 리터러시의 격차** * 단순 질문을 반복하는 방식과 작업 전 팀의 가이드라인, 린트 규칙, 코드 패턴 등 '컨텍스트'를 먼저 주입하는 방식은 결과물에서 큰 차이를 만듭니다. * 이러한 생산성 격차는 코딩 실력이 아닌 LLM을 제어하는 노하우의 차이이며, 이를 개인의 센스에만 맡기는 것은 조직적 손실입니다. * 팀 전체의 역량을 상향 평준화하기 위해서는 누구나 최적의 맥락 위에서 작업할 수 있도록 돕는 시스템적 장치(Harness)가 필요합니다. **Claude Code와 마찰 없는 워크플로우 이식** * 브라우저 기반 챗봇으로 코드를 복사·붙여넣기 하는 과정에서 발생하는 문맥 교환(Context Switching) 비용을 최소화해야 합니다. * Claude Code가 제공하는 TUI(Terminal User Interface) 환경은 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 매끄러운 경험을 제공합니다. * 이러한 낮은 진입 장벽은 설계된 AI 워크플로우를 팀원들에게 저항감 없이 전파할 수 있는 기반이 됩니다. **실행 가능한 진실의 원천(Executable SSOT)** * 기존의 위키나 노션 문서는 작성 즉시 낡은 정보가 되지만, 플러그인 형태의 지식은 사람이 읽는 매뉴얼인 동시에 LLM이 즉시 실행하는 시스템 프롬프트가 됩니다. * RAG(검색 증강 생성) 방식은 내부 로직의 불투명성으로 인해 어떤 컨텍스트가 주입될지 예측하기 어렵다는 단점이 있습니다. * 반면 플러그인 방식은 명시적인 코드로서 개발자가 주입되는 맥락을 100% 통제할 수 있어 높은 예측 가능성과 신뢰성을 제공합니다. **계층화된 아키텍처를 통한 거버넌스와 전파** * 지식을 전사 공통(Global), 팀/비즈니스 도메인(Domain), 특정 프로젝트(Local)의 3단계 레이어로 계층화하여 관리함으로써 지식의 파편화를 방지합니다. * `/new-feature`와 같은 슬래시 커맨드를 통해 숙련된 엔지니어의 노하우(이슈 발급, 브랜치 생성, 구현 계획 수립 등)를 모든 팀원에게 즉시 배포할 수 있습니다. * 단순한 린터를 넘어, 메인 브랜치 커밋 시도를 감지하고 정책에 맞는 브랜치 생성을 가이드하는 등 AI 에이전트 기반의 강력한 거버넌스 구현이 가능합니다. **엔지니어링의 본질: 플랫폼 엔지니어링과 데이터 플라이휠** * Software 1.0 시대에 공통 라이브러리로 중복 작업을 줄였듯, Software 3.0에서는 AI 워크플로우 플러그인을 통해 팀의 생산성을 최적화해야 합니다. * 규격화된 플러그인을 통해 축적된 양질의 데이터는 향후 도메인 특화 모델(sLLM)을 파인튜닝하고 평가하는 기반이 됩니다. * 사용자가 많아질수록 데이터가 쌓이고 모델이 정교해지는 '데이터 플라이휠' 구조를 구축하는 것이 AI-Native 조직의 최종 목표입니다. 이제 LLM 활용 능력은 개인의 역량을 넘어 팀이 설계하고 배포해야 할 시스템의 영역입니다. Claude Code의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.

github3분 읽기큐레이션 요약

멀티 에이전트 워크

멀티 에이전트 워크플로는 에이전트들이 상태, 실행 순서, 검증 방식에 대해 암묵적으로 가정하기 때문에 쉽게 실패한다. 이를 안정적으로 운영하려면 에이전트를 대화형 인터페이스가 아니라 분산 시스템의 구성 요소처럼 다뤄야 하며, 타입 스키마·명시적 액션·강제된 인터페이스가 필요하다. 특히 MCP(Model Context Protocol)는 이러한 계약을 실행 전에 검증해 잘못된 상태가 시스템에 전파되는 것을 막는다. ## 멀티 에이전트 시스템이 실패하는 이유 - 이슈 분류, 변경 제안, 테스트 실행, 풀 리퀘스트 생성처럼 관련 작업을 여러 에이전트가 나눠 처리하면 상태와 순서에 대한 암묵적 가정이 생긴다. - 한 에이전트가 이슈를 열자마자 다른 에이전트가 이를 닫거나, 후속 검사를 알지 못한 채 변경 사항을 배포하는 문제가 발생할 수 있다. - 자연어와 일관되지 않은 JSON만으로 통신하면 필드명, 자료형, 형식이 쉽게 달라져 자동화가 불안정해진다. ## 타입 스키마로 데이터 계약 정의 - 에이전트 간 데이터 교환에는 기계적으로 검증 가능한 타입과 엄격한 스키마를 사용해야 한다. - 예를 들어 사용자 프로필을 다음처럼 정의할 수 있다. - `id`: 숫자 - `email`: 문자열 - `plan`: `free`, `pro`, `enterprise` 중 하나 - 잘못된 메시지는 다음 단계로 전달하기 전에 실패시켜야 한다. - 재시도 - 메시지 수정 - 사람에게 에스컬레이션 - 디버깅도 로그를 해석하는 방식에서 “어떤 스키마 계약을 위반했는가”를 확인하는 방식으로 바뀐다. ## 액션 스키마로 의도 명확히 하기 - 데이터 형식이 올바르더라도 “분석하고 팀이 행동하도록 돕는다”처럼 지시가 모호하면 에이전트마다 다른 결정을 내릴 수 있다. - 가능한 결과를 제한된 액션 집합으로 정의하면 자동화 가능한 결과만 반환하게 만들 수 있다. - 예시 액션: - 추가 정보 요청: 필요한 정보 목록 포함 - 담당자 지정: 담당자 식별자 포함 - 중복 이슈로 종료: 원본 이슈 번호 포함 - 조치 없음 - 에이전트는 반드시 하나의 유효한 액션을 반환해야 하며, 그 외 결과는 검증 실패로 처리해 재시도하거나 에스컬레이션한다. - 글은 멀티 에이전트 장애의 상당수가 데이터 자체보다 “잘못된 행동 선택”에서 발생한다고 설명한다. ## MCP로 인터페이스 강제 - 스키마와 액션 규칙을 문서로만 정해두면 관례에 불과하며, 모든 에이전트가 이를 지킨다는 보장이 없다. - MCP는 각 도구와 리소스에 명시적인 입력·출력 스키마를 제공하고, 도구 호출 전에 이를 검증한다. - 예를 들어 `create_issue` 도구에 입력 스키마와 출력 스키마를 함께 정의할 수 있다. - MCP를 사용하면 에이전트가 다음과 같은 오류를 일으키기 어렵다. - 존재하지 않는 필드 생성 - 필수 입력 누락 - 에이전트 간 인터페이스 형식 변경 - 실행 전에 검증하므로 잘못된 호출이 운영 시스템에 영향을 주기 전에 차단된다. ## 실용적인 적용 방향 - 에이전트 간 모든 경계에 타입 스키마를 적용한다. - 자연어 지시의 최종 결과는 제한된 액션 스키마로 변환한다. - 도구 호출과 데이터 교환에는 MCP 같은 검증 계층을 둔다. - 스키마 위반을 자동 재시도, 수정, 에스컬레이션 대상으로 명시한다. - 멀티 에이전트 시스템을 챗봇이 아니라 계약과 인터페이스를 갖춘 소프트웨어 컴포넌트로 설계하는 것이 핵심이다.

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

코드 모드: 1 (새 탭에서 열림)

Cloudflare에서 발표한 '코드 모드(Code Mode)'는 AI 에이전트가 방대한 API를 사용할 때 발생하는 컨텍스트 윈도우 낭비 문제를 해결하기 위한 혁신적인 접근 방식입니다. 개별 API 엔드포인트를 수천 개의 도구로 정의하는 대신, 에이전트가 직접 코드를 작성하고 실행하게 함으로써 단 1,000개의 토큰만으로 전체 Cloudflare API를 제어할 수 있게 합니다. 이 기술은 모델의 기억 공간을 보존하면서도 복잡한 연쇄 작업을 효율적으로 수행할 수 있는 높은 유연성을 제공합니다. ### 기존 MCP 방식의 한계와 코드 모드의 등장 * **컨텍스트 윈도우 포화 문제**: 모델 지시 프로토콜(MCP)에서 에이전트에게 너무 많은 도구를 제공하면 컨텍스트 윈도우가 가득 차서 실제 작업 수행에 필요한 공간이 부족해집니다. * **방대한 API의 비효율성**: Cloudflare API처럼 엔드포인트가 2,500개가 넘는 경우, 이를 모두 도구로 등록하려면 약 117만 개의 토큰이 필요하며 이는 최신 모델의 한계를 초과하는 수치입니다. * **코드 모드의 해결책**: 도구의 명세(Description)를 줄이는 대신, 에이전트가 SDK를 대상으로 코드를 작성하고 이를 안전한 샌드박스에서 실행하는 방식을 채택하여 토큰 사용량을 99.9% 절감했습니다. ### 핵심 인터페이스: search()와 execute() * **search() 도구**: 전체 OpenAPI 명세를 모델에 주입하는 대신, 모델이 자바스크립트 코드를 작성하여 명세 내에서 필요한 엔드포인트를 스스로 검색하게 합니다. 이를 통해 모델은 수천 개의 엔드포인트 중 당장 필요한 것만 식별할 수 있습니다. * **execute() 도구**: 에이전트가 실제 API 요청을 수행하는 자바스크립트 코드를 작성하여 실행합니다. 단순 호출뿐만 아니라 페이지네이션 처리, 응답 확인, 여러 작업을 하나로 묶는 체이닝(Chaining)이 가능합니다. * **고정된 토큰 비용**: API의 규모가 아무리 커져도 모델이 학습해야 할 도구는 이 두 가지뿐이므로, 약 1,000토큰의 고정된 비용만 발생합니다. ### 보안 및 실행 환경 (Dynamic Worker) * **V8 샌드박스 격리**: 에이전트가 작성한 코드는 파일 시스템 접근이나 환경 변수 유출이 불가능한 경량 V8 샌드박스인 'Dynamic Worker' 내부에서 실행됩니다. * **제한된 네트워크 접근**: 외부 호출(Fetch)은 기본적으로 비활성화되어 있으며, 필요에 따라 명시적으로 제어된 핸들러를 통해서만 외부와 통신할 수 있어 프롬프트 주입 공격으로부터 안전합니다. * **안전한 실행 흐름**: 모델이 직접 API 키를 다루지 않고 서버 측에서 정의된 안전한 환경에서 로직만 실행하므로 보안성이 높습니다. ### 실무 적용 사례: DDoS 방어 설정 * **엔드포인트 탐색**: 에이전트가 "DDoS 공격으로부터 내 사이트를 보호해줘"라는 요청을 받으면, `search()`를 통해 WAF 및 규칙 설정 관련 API 엔드포인트를 필터링합니다. * **복합 작업 수행**: 필터링된 엔드포인트 정보를 바탕으로 `execute()`를 호출하여 방화벽 규칙을 생성하고, 패키지를 업데이트하며, 설정을 확인하는 일련의 과정을 단 한 번의 도구 호출로 처리할 수 있습니다. 방대한 API를 다루는 서비스를 운영 중이라면 Cloudflare가 오픈소스로 공개한 **Code Mode SDK**를 활용해 보시기 바랍니다. 이를 통해 에이전트의 응답 속도를 높이고 운영 비용(토큰 사용량)을 획기적으로 줄이면서도 에이전트에게 서비스 전체에 대한 강력한 제어권을 부여할 수 있습니다.