AI 에이전트 | Techlist.io

aws2026년 5월 5일3분 읽기큐레이션 요약

워크플로 현대화: Amazon WorkSpaces, 이제 AI 에이전트에 자체 데스크톱 제공(미리 보기) | Amazon Web Services

Amazon WorkSpaces는 레거시 애플리케이션을 API로 현대화하지 않아도 AI 에이전트가 데스크톱 환경에서 직접 조작할 수 있도록 지원한다. 에이전트는 직원과 동일한 관리형 가상 데스크톱에서 애플리케이션을 사용하며, IAM 인증과 CloudTrail·CloudWatch 감사 추적을 적용받는다. 이를 통해 기업은 대규모 마이그레이션 없이 기존 업무 시스템에 AI 자동화를 도입할 수 있다. ## 레거시 애플리케이션의 AI 접근성 문제 - 2024년 Gartner 보고서에 따르면 조직의 75%가 현대적인 API가 없는 레거시 애플리케이션을 운영한다. - Fortune 500 기업의 71%는 프로그래밍 방식 접근이 부족한 메인프레임에서 핵심 업무를 처리한다. - 기업은 AI 도입을 미루거나, 비용과 위험이 큰 애플리케이션 현대화 프로젝트를 진행해야 했다. - WorkSpaces는 애플리케이션을 재개발하거나 API를 새로 구축하지 않고도 이 문제를 해결한다. ## AI 에이전트를 위한 보안 데스크톱 - AI 에이전트는 관리형 WorkSpaces 환경 내부에서 데스크톱 애플리케이션을 실행한다. - AWS IAM을 통해 에이전트를 인증하고, 에이전트별 자격 증명과 권한을 적용한다. - AWS CloudTrail과 Amazon CloudWatch를 이용해 세션과 작업을 감사·모니터링할 수 있다. - 로컬 컴퓨터가 아닌 격리된 클라우드 데스크톱에서 동작하므로 기존 보안 정책과 컴플라이언스 통제를 유지할 수 있다. - 직원용으로 사용하던 WorkSpaces 인프라를 AI 에이전트용 실행 환경으로 확장할 수 있다. ## MCP 기반 에이전트 연동 - WorkSpaces는 업계 표준인 Model Context Protocol(MCP)을 지원한다. - MCP 엔드포인트를 통해 에이전트 프레임워크와 WorkSpaces를 연결할 수 있다. - LangChain, CrewAI, Strands Agents 등 다양한 프레임워크와 함께 사용할 수 있다. - 별도의 애플리케이션별 API 통합 없이 에이전트가 데스크톱의 사용자 인터페이스를 조작한다. ## 에이전트 접근 환경 설정 - WorkSpaces Applications 스택을 생성해 에이전트의 연결 방식과 권한을 정의한다. - 스택 설정에서 기본값인 `No AI agent access` 대신 `Add AI Agents`를 선택하면 에이전트 접속을 활성화할 수 있다. - 주요 에이전트 기능은 다음과 같다. - **Computer input**: 클릭, 입력, 스크롤 수행 - **Computer vision**: 화면을 캡처해 애플리케이션 상태 인식 - **Screenshot storage**: 감사 및 디버깅을 위한 세션 스크린샷 저장 - 화면 해상도와 이미지 형식도 지정할 수 있다. - 예시 설정: 1280×720 해상도, PNG 형식 - 복잡하고 조밀한 UI는 더 높은 해상도가 유리할 수 있다. - 터미널 중심 인터페이스는 720p 수준으로도 충분할 수 있다. ## API 없이 기존 업무 애플리케이션 자동화 - Strands Agent SDK와 Amazon Bedrock으로 구현한 에이전트가 샘플 약국 시스템에서 처방전 리필 업무를 수행했다. - 에이전트는 환자 기록 조회, 약품 검색, 주문, 처방전 갱신 확인을 모두 화면 조작으로 처리했다. - 해당 애플리케이션은 에이전트가 사용 중이라는 사실을 인식하지 못한다. - 애플리케이션 수정, 재빌드, API 통합 없이 현재 상태 그대로 사용할 수 있다는 점이 핵심이다. ## 제공 범위와 도입 방법 - 현재 퍼블릭 프리뷰로 제공되며 추가 비용은 없다. - 지원 리전에는 미국 동부·서부, 캐나다, 유럽 주요 리전, 도쿄·뭄바이·시드니·서울·싱가포르 등이 포함된다. - AWS Management Console에서 WorkSpaces Applications 스택을 생성하고 AI 에이전트 접근을 활성화한 뒤, MCP 엔드포인트와 IAM 인증 정보를 에이전트 프레임워크에 설정한다. - AWS GitHub 저장소와 WorkSpaces 공식 페이지를 통해 구현을 시작할 수 있다. 기존 데스크톱 애플리케이션을 빠르게 자동화하려는 기업에는 유용한 접근 방식이다. 다만 퍼블릭 프리뷰 단계이므로 실제 도입 전 권한 범위, 화면 캡처의 민감정보 처리, 감사 로그 보존 정책을 충분히 검토하는 것이 좋다.

원문 읽기

AI 에이전트 모델 컨텍스트 프로토콜 amazon-bedrock amazon-cloudwatch+4

gitlab2026년 5월 5일4분 읽기큐레이션 요약

팀 협업을 재편하는 8가지 에이전틱 AI 패턴

17개 에이전틱 AI 플랫폼을 분석한 결과, 팀 협업을 혁신하는 핵심은 개별 에이전트의 성능보다 팀 전체의 업무 흐름을 얼마나 일관되게 연결하느냐에 있다. 특히 에이전트는 진행 상황 공유, 업무 배정, 커뮤니케이션, 권한 관리, 개발·배포 거버넌스를 지원하며 팀의 속도와 판단력을 높이고 통제력을 유지하게 한다. 글은 이러한 기능을 8가지 패턴으로 정리하고, 소프트웨어 개발 생명주기 전체가 하나의 플랫폼에 통합된 GitLab이 에이전트 협업에 구조적 강점을 가진다고 주장한다. ## 1. 진행 상황 자동 공유 - 에이전트가 실시간 작업 데이터를 바탕으로 진행 상황과 상태 보고서를 자동 생성한다. - 일정 지연, 차단 요소, 위험 요소를 사전에 감지해 관련 담당자에게 전달한다. - 정기 상태 회의나 수동 확인 절차를 줄이고, 필요한 사람에게 필요한 정보만 제공한다. - 팀이 더 빠르게 움직이고, 업무 상황을 더 정확하게 파악할 수 있다. ## 2. 사람 간 업무 라우팅 - 대기열에 쌓인 업무를 담당자의 기술, 현재 업무량, 프로젝트 맥락에 따라 자동 배정한다. - 계획 수립 시점에만 업무를 조정하는 것이 아니라, 프로젝트 진행 중에도 지속적으로 부하를 균형 조정한다. - 에이전트가 왜 특정 담당자에게 업무를 배정했는지 근거를 공개한다. - 사람이 최종 배정 전에 개입하고 수정할 수 있어 자동화와 통제력을 함께 확보한다. ## 3. 팀 커뮤니케이션 지원 - 채널, 메시지 스레드, 회의 녹화 내용을 요약해 핵심 결정과 논점을 전달한다. - 새로 참여한 구성원도 전체 대화 기록을 직접 읽지 않고 업무 맥락을 파악할 수 있다. - 반복 질문과 역할 간 재설명을 줄이고, 동기식 회의 대신 비동기 요약을 활용한다. - 정보 공유 속도와 의사결정 효율을 높인다. ## 4. 채팅 안의 역할별 에이전트 - 팀이 이미 사용하는 Slack 등의 커뮤니케이션 도구 안에 전문 에이전트를 배치한다. - 온보딩 질문, IT 장애 처리, 영업 브리핑 등 역할별 업무를 대화 흐름에서 바로 수행한다. - 예를 들어 메시지에 이모지 반응을 추가하는 것만으로 추적 티켓을 생성할 수 있다. - 별도 포털이나 도구로 이동하지 않아도 대화가 곧 업무 실행의 출발점이 된다. ## 5. 공유되는 대화 맥락 - 에이전트가 여러 사람이 참여한 대화의 스레드와 파일을 지속적으로 인식한다. - 한 사람이 에이전트에게 제공한 정보와 지식이 팀 전체에 공유된다. - 새 구성원이나 다른 에이전트도 이전 작업이 끝난 지점에서 바로 이어서 작업할 수 있다. - 구성원마다 같은 문제를 반복해서 설명하거나 중복 프롬프트를 작성하는 일을 줄인다. ## 6. 역할 기반 접근 제어(RBAC) - 에이전트가 부여받은 역할에 허용된 데이터와 기능만 접근하도록 제한한다. - 권한은 단순한 시스템 단위가 아니라 필드 수준까지 세밀하게 적용될 수 있다. - 권한이 없는 데이터는 에이전트가 읽거나 추론하거나 조작할 수 없다. - 모든 에이전트의 작업을 기록해 규정 준수와 감사에 필요한 추적성을 제공한다. ## 7. 통제된 에이전트 실행 환경 - 에이전트를 코드와 마찬가지로 개발·테스트·운영 환경을 거쳐 배포한다. - 초기 개발 단계에서는 격리된 샌드박스를 사용해 에이전트 간 충돌을 방지한다. - 관리형 승격 파이프라인을 통해 검증되지 않은 에이전트가 운영 환경에 진입하지 않도록 한다. - 운영 중인 에이전트에 대한 무분별한 업데이트가 실제 업무를 중단시키는 위험도 줄인다. ## 8. 에이전트 공동 개발 - 여러 구성원이 에이전트를 공동 소유하고 수정·유지보수할 수 있다. - 역할별 권한을 부여하고, 공유 개발 공간에서 실시간으로 에이전트를 디버깅한다. - 표준화된 프로토콜을 사용해 서로 다른 사람이 만든 에이전트의 호환성을 유지한다. - 에이전트 개발을 개인 작업이 아니라 버전 관리와 협업이 필요한 팀 활동으로 만든다. ## 경쟁 환경에서 드러난 흐름 - 에이전트는 별도 애플리케이션보다 팀이 이미 일하는 채팅 도구 안으로 이동하고 있다. - 조직 규모가 커질수록 권한, 감사 로그, 배포 통제 같은 거버넌스가 필수 요소가 된다. - 에이전트 제작 역시 공동 소유, 협업 수정, 감사 가능한 버전 관리가 기본 기능이 되고 있다. - 상태 회의, 수동 확인, 역할 간 반복 설명 같은 ‘조정 비용’을 에이전트가 줄이기 시작했다. - 경쟁력은 가장 강력한 단일 에이전트보다 여러 에이전트와 사람을 일관된 팀 경험으로 연결하는 데서 나온다. ## 아직 부족한 통합형 거버넌스 - 분석된 플랫폼에서 가장 드문 기능은 다음 요소를 하나로 연결하는 통합 환경이다. - 실행 환경 그룹화 - 에이전트 카탈로그 공유 - 관리형 배포·승격 파이프라인 - 대부분의 플랫폼은 권한 관리나 배포 관리 등 거버넌스의 일부만 해결한다. - 개발부터 운영까지 에이전트를 안전하게 만들고 공유하고 배포하는 전체 흐름을 연결한 사례는 많지 않다. ## GitLab에 대한 시사점 - GitLab은 소프트웨어 개발과 배포 전 과정이 하나의 플랫폼에 있어 에이전트를 외부에서 덧붙일 필요가 적다. - GitLab Duo Agent Platform은 기존 워크플로를 규칙으로 활용하고, 조직의 맥락과 지식을 공유하며, 가드레일로 실행을 통제하는 방향을 취한다. - 따라서 코드 작성뿐 아니라 계획, 개발, 테스트, 보안, 배포 등 전체 DevSecOps 생명주기에서 에이전트를 조율할 수 있다는 것이 글의 결론이다. 팀에 에이전트를 도입할 때는 개별 자동화 기능보다 공유 맥락, 투명한 업무 배정, 세밀한 권한, 테스트·승격 파이프라인, 공동 유지보수 체계를 먼저 설계하는 것이 바람직하다. 그래야 속도 향상뿐 아니라 보안과 책임성까지 확보할 수 있다.

원문 읽기

AI 에이전트 gitlab DevSecOps governance+3

aws2026년 5월 4일5분 읽기큐레이션 요약

AWS 주간 요약: AWS 2026의 향후 계획, Amazon Quick, OpenAI 파트너십 등 (2026년 5월 4일) | Amazon Web Services

AWS는 2026년 들어 생성형 AI와 에이전트 중심으로 서비스를 빠르게 확장하고 있다. Amazon Quick은 업무 자동화와 콘텐츠 생성을 강화했고, Amazon Connect는 공급망·채용·고객지원·의료를 아우르는 4개 에이전트 솔루션으로 확대됐다. 또한 AWS와 OpenAI는 Bedrock을 통해 OpenAI 모델과 Codex를 AWS 환경에서 사용할 수 있도록 협력을 강화했다. ## Amazon Quick의 업무 자동화 확대 - Amazon Quick은 앱과 연결해 사용자의 업무 맥락을 파악하고 대신 작업을 수행하는 AI 비서다. - 브라우저 없이 로컬 파일, 캘린더, 커뮤니케이션에 접근할 수 있는 데스크톱 앱을 프리뷰로 제공한다. - AWS 계정 없이 개인 이메일이나 Google, Apple, GitHub, Amazon 계정으로 가입할 수 있다. - 채팅 인터페이스에서 다음 콘텐츠를 직접 생성할 수 있다. - 문서 - 프레젠테이션 - 인포그래픽 - 이미지 - Google Workspace, Zoom, Airtable, Dropbox, Microsoft Teams와의 네이티브 통합이 추가됐다. - 자연어로 지시해 비즈니스 데이터와 연결된 앱, 대시보드, 웹 페이지를 만드는 기능도 프리뷰로 제공된다. ## Amazon Connect의 에이전트 AI 사업 확장 Amazon Connect는 고객센터 제품을 넘어 네 가지 업무 영역별 에이전트 AI 솔루션으로 확대됐다. - **Amazon Connect Decisions** - 공급망 계획 및 인텔리전스 솔루션이다. - Amazon의 30년 운영 노하우와 25개 이상의 공급망 도구를 결합한다. - 문제가 발생한 뒤 대응하는 방식에서 벗어나 선제적 계획 수립을 지원한다. - **Amazon Connect Talent** - 대규모 채용을 위한 에이전트형 AI 채용 솔루션이다. - AI 주도 인터뷰, 과학 기반 평가, 일관된 지원자 평가를 제공한다. - 현재 프리뷰로 제공된다. - **Amazon Connect Customer** - 기존 Amazon Connect를 확장한 고객경험 솔루션이다. - 음성, 채팅, 디지털 채널에서 개인화된 고객 응대를 지원한다. - 대화형 AI를 수개월이 아니라 수주 내 구성할 수 있도록 설정 기능을 강화했다. - **Amazon Connect Health** - 환자 확인, 예약 관리, 환자 인사이트, 주변 대화 기반 문서화, 의료 코딩을 자동화한다. - 환자는 더 빠르게 진료를 받고, 의료진은 문서 작업보다 진료에 집중할 수 있도록 설계됐다. ## AWS와 OpenAI의 Bedrock 협력 - AWS와 OpenAI는 최신 OpenAI 모델을 Amazon Bedrock에서 사용할 수 있도록 제한적 프리뷰를 시작했다. - GPT-5.5와 GPT-5.4 등을 기존 Bedrock API를 통해 사용할 수 있다. - 사용자는 별도 인프라나 새로운 보안 모델을 익히지 않고 Bedrock의 보안, 거버넌스, 비용 관리 체계를 그대로 활용할 수 있다. - **Codex on Amazon Bedrock** - OpenAI의 코딩 에이전트를 기존 AWS 환경에서 실행한다. - AWS 자격 증명으로 인증하고, 추론은 Bedrock을 통해 처리한다. - Codex 사용량을 AWS 클라우드 약정에 반영할 수 있다. - Codex CLI, 데스크톱 앱, Visual Studio Code 확장에서 사용할 수 있다. - **Amazon Bedrock Managed Agents** - OpenAI 모델과 AWS 인프라를 결합해 운영 환경용 에이전트를 구축한다. - OpenAI 하니스를 사용해 장시간 작업의 실행력, 추론, 제어 안정성을 높이는 것을 목표로 한다. ## 고성능 EC2 인스턴스 출시 - **M8in·M8ib** - 6세대 Intel Xeon Scalable 프로세서와 6세대 AWS Nitro 카드를 사용한다. - M6in·M6ib보다 최대 43% 높은 성능을 제공한다. - M8in은 최대 600Gbps 네트워크 대역폭, M8ib는 최대 300Gbps EBS 대역폭을 지원한다. - **R8in·R8ib** - 메모리 최적화 인스턴스다. - 대규모 상용 데이터베이스, 데이터 레이크, SAP HANA 같은 인메모리 데이터베이스에 적합하다. - 최대 600Gbps 네트워크와 300Gbps EBS 대역폭을 제공한다. - **C8ine·M8ine** - 네트워크 최적화 인스턴스다. - C6in·M6in 대비 vCPU당 패킷 처리 성능이 최대 2.5배, 인터넷 게이트웨이 경유 네트워크 처리량이 최대 2배 향상됐다. - 가상 방화벽, 로드 밸런서, 5G UPF 등 보안·네트워크 가상 어플라이언스에 적합하다. ## Bedrock AgentCore의 운영 최적화 - Bedrock AgentCore 프리뷰에 에이전트 개선 기능이 추가됐다. - 운영 환경의 추적 데이터와 평가 결과를 분석해 시스템 프롬프트와 도구 설명 개선안을 추천한다. - 추천 결과는 다음 방식으로 검증할 수 있다. - 사전 정의된 테스트 케이스를 활용한 일괄 평가 - 실제 트래픽을 대상으로 한 A/B 테스트 - 모든 추천 사항은 사용자가 승인해야 운영 환경에 반영된다. - 관찰, 평가, 개선의 반복 과정을 자동화해 운영 중인 에이전트의 품질을 높이는 구조다. ## AWS Lambda와 Ruby 4.0 지원 - AWS Lambda가 최신 LTS 버전인 Ruby 4.0을 관리형 런타임과 컨테이너 기본 이미지로 지원한다. - 고급 로깅 기능을 사용할 수 있다. - JSON 구조화 로그 - 로그 레벨 설정 - 대상 CloudWatch 로그 그룹 지정 - 중국 리전과 AWS GovCloud를 포함한 모든 AWS 리전에서 제공된다. ## Amazon Q Developer에서 Kiro로의 전환 - Amazon Q Developer IDE 플러그인과 유료 구독은 2027년 4월 30일 지원 종료 예정이다. - 신규 가입은 2026년 5월 15일부터 차단된다. - 기존 구독자는 계속 사용자를 추가할 수 있지만, 2026년 5월 29일부터 Q Developer Pro에서 Opus 4.6은 사용할 수 없다. - Opus 4.5 및 기존 모델은 유지되며, 최신 코딩 모델인 Opus 4.7 등은 Kiro에서만 제공된다. - AWS 관리 콘솔의 Amazon Q Developer와 문서, 모바일 앱, Slack, Microsoft Teams 등 AWS의 퍼스트파티 경험은 이번 종료 대상이 아니다. ## 실용적인 시사점 - 기업은 Bedrock을 중심으로 OpenAI 모델과 AWS의 보안·거버넌스·비용 관리 체계를 함께 활용할 수 있게 됐다. - 업무 자동화 도입을 검토한다면 Quick은 문서 생성과 사내 도구 연결에, Connect는 고객지원·채용·공급망·의료 프로세스에 적합하다. - 대규모 데이터베이스나 네트워크 집약적 워크로드는 새 M8·R8·C8 계열의 대역폭과 패킷 처리 성능을 기존 인스턴스와 비교해 검토할 만하다. - Amazon Q Developer 사용 조직은 지원 종료 일정과 Kiro 전환 계획을 미리 점검해야 한다.

원문 읽기

AI 에이전트 AWS amazon-bedrock amazon-ec2+3

figma2026년 4월 30일3분 읽기큐레이션 요약

워크플로우 랩: Figma MCP로 캔버스 확장하기 | 피그마 블로그

빠르게 코드를 작성하는 팀에서는 구현 과정에서 새로운 상태와 예외가 생기며 디자인과 실제 제품 사이의 간극이 커질 수 있다. 이 글은 Figma MCP를 사용해 코드에만 존재하던 제품 상태를 Figma 캔버스로 가져오고, 디자이너가 이를 직접 검토·수정하는 워크플로를 소개한다. 결과적으로 캔버스가 초기 화면을 넘어 실제 제품 전체의 상태와 구현 결과를 다루는 공간으로 확장된다. ## 빠른 개발이 만드는 디자인 사각지대 - Astra라는 가상의 AI 영상 제작 플랫폼은 에이전트 코딩 도구를 활용해 매주 기능을 출시한다. - 초기 영상 내보내기 플로우는 다음 네 단계로 시작한다. - 시퀀스 선택 - 포맷 선택 - 설정 확인 - 영상 내보내기 - 실제 코드와 데이터에 연결되면서 다음과 같은 상태가 추가된다. - 인코딩 오류 - 렌더링 진행 중 상태 - 선택 항목이 없는 상태 - 지원하지 않는 포맷 - 이러한 상태는 디자이너가 초기 설계에서 누락한 것이 아니라, 기능이 실제 구현되는 과정에서 새롭게 드러난 디자인 결정 사항이다. - 캔버스가 초기 플로우만 담고 있으면 디자이너 역시 제품의 일부만 보고 작업하게 된다. ## Figma MCP로 캔버스 확장 - Figma MCP를 통해 에이전트가 코드를 읽고 Figma 캔버스에 결과를 작성할 수 있다. - 에이전트는 구현된 내보내기 플로우를 분석해 개발자가 처리한 모든 상태를 식별한다. - 각 상태를 Figma의 편집 가능한 프레임으로 생성하고, Astra의 디자인 시스템 컴포넌트를 적용한다. - 초기에는 4개였던 프레임이 구현된 전체 상태를 반영하며 14개로 늘어난다. - 사용된 주요 도구는 다음과 같다. - Figma Design - Dev Mode - Figma MCP server - `use_figma` - `generate_figma_design` - `/sync-figma-token` 스킬 ## 코드에 드러난 상태를 디자인으로 발전시키기 - 인코딩 오류 화면에는 단순한 빨간색 오류 메시지만 있었지만, 디자이너가 다음 내용을 추가한다. - 오류 원인 - 사용자가 시도할 수 있는 해결 방법 - 이전 단계로 돌아가는 방법 - 렌더링 중 화면에는 스피너만 있었지만, 디자이너가 진행률과 예상 소요 시간을 추가한다. - 선택 항목이 없는 화면은 비어 있었지만, 기능 사용을 유도할 수 있는 안내 문구와 개성을 부여한다. - 이 방식은 작업 티켓이나 요구사항 문서 중심의 피드백보다, 코드와 디자인이 캔버스에서 직접 대화하는 형태에 가깝다. - 구현 후 발견된 예외 상태를 별도의 긴 탐색 세션을 거치지 않고 바로 디자인 대상으로 전환할 수 있다. ## 디자인과 구현 결과 비교 - Figma 캔버스에서 원본 디자인과 코드로 구현된 화면을 나란히 비교할 수 있다. - 시각적 차이를 찾아내는 비교 결과에는 심각도별 불일치가 표시된다. - 예시로 다음과 같은 차이가 발견된다. - 모달 제목 크기 차이 - 구현본에만 추가된 “Post share link” 버튼 - 설정 패널의 배경 또는 표면 스타일 제거 - 설정 헤더의 시각적 우선순위 하락 - 이를 통해 디자인 검토가 “의도한 화면이 구현되었는가”뿐 아니라, 실제 구현 과정에서 추가·변경된 요소까지 포함하도록 확장된다. ## 실용적인 결론 Figma MCP는 코드를 디자인으로 자동 변환하는 도구라기보다, 구현 중 발생한 모든 제품 상태를 디자인 의사결정의 영역으로 되돌리는 연결 장치다. 빠르게 개발하는 팀이라면 에이전트로 코드의 상태를 캔버스에 동기화한 뒤, 디자이너가 오류·로딩·빈 상태·시각적 불일치를 직접 검토하는 절차를 구축하는 것이 유용하다.

원문 읽기

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

figma2026년 4월 28일3분 읽기큐레이션 요약

이제 FigJam은 코딩 에이전트의 화이트보드이기도 합니다 | Figma 블로그

FigJam이 코딩 에이전트의 작업을 시각화하고 팀과 함께 검토하는 협업 공간으로 확장된다. Figma는 `figma-use-figjam`, 확장된 `generate_diagram`, `get_figjam` 등의 MCP 도구와 스킬을 통해 에이전트가 코드베이스와 문서를 분석하고, FigJam에 아키텍처를 작성하며, 팀 피드백을 다시 구현 단계로 전달하도록 한다. 이를 통해 빠른 에이전트 개발로 발생하는 숨은 복잡성을 줄이고, 코딩 전에 설계를 검토할 수 있다는 것이 글의 결론이다. ## 에이전트 개발 속도와 코드 복잡성의 간극 - 에이전트 덕분에 과거 몇 분기 걸리던 기능을 몇 주 만에 구현할 수 있다. - 그러나 사람이 충분히 검토하지 않은 에이전트 생성 PR이 쌓이면 코드베이스에 다음 문제가 생긴다. - 숨은 복잡성 증가 - 기존 구조와 새로운 구현 간의 불일치 - 팀원이 전체 시스템 변화를 파악하기 어려움 - 글의 저자는 이러한 문제를 한눈에 파악하고 논의하기 위해 텍스트 문서보다 시각적인 시스템 표현이 필요하다고 설명한다. ## FigJam과 MCP 도구의 결합 - 기존 `use_figma` MCP 도구는 AI 에이전트가 실제 Figma 컴포넌트를 사용해 디자인을 생성하거나 수정하도록 한다. - `create_new_file`은 에이전트가 새 Figma 파일 안에 디자인을 생성할 수 있게 한다. - 새롭게 확장된 `generate_diagram`은 단순한 다이어그램을 넘어 다음과 같은 복잡한 시각 자료를 생성한다. - 시스템 아키텍처 다이어그램 - ERD(Entity Relationship Diagram) - 서비스 및 데이터 관계 구조 - `figma-use-figjam` MCP 스킬은 에이전트가 FigJam 보드를 직접 읽고 쓸 수 있도록 한다. - `generate-project-plan` 같은 워크플로 스킬은 문서, 코드베이스, 대화 내용을 시각적인 프로젝트 계획으로 변환한다. ## 1단계: 조사와 계획을 시각화 - 먼저 코딩 에이전트가 새 기능에 필요한 맥락을 수집한다. - 관련 MCP 서버 문서 - 코드베이스 구조 - 기존 구현 패턴 - 영향을 받는 서비스와 파일 - 에이전트는 가능한 구현 방안과 트레이드오프를 조사한다. - 이후 작업을 여러 개의 stacked PR로 나누고 테스트 전략을 세운다. - 기존에는 이 결과가 긴 Markdown 문서로 남았지만, 이제 FigJam 보드로 변환할 수 있다. - 보드에는 다음 자료를 함께 배치할 수 있다. - `generate_diagram`으로 생성한 아키텍처 및 ER 다이어그램 - `figma-use-figjam`으로 작성한 노트 - 코드 블록 - 주석과 설계 근거 - 텍스트 중심의 계획보다 팀원이 구조와 대안을 빠르게 비교하고, 적절한 아키텍처를 논의하기 쉬워진다. ## 2단계: 코드 작성 전 협업 - 생성된 FigJam 보드를 팀에 공유해 구현 전에 기술적 피드백을 받는다. - 팀원은 다이어그램 위에서 질문과 결정을 직접 남길 수 있다. - 특정 도구가 디자인 파일 외에 여러 파일 형식을 지원해야 하는가? - `folderId`를 입력받을 것인가? - 새 파일은 사용자의 Drafts 폴더에 생성할 것인가? - 원격 팀도 회의실에서 화이트보드를 사용하는 것처럼 기술 맥락을 공유하고 논의할 수 있다. - 에이전트가 만든 다이어그램도 사람이 검토하는 협업 산출물로 활용된다. ## 3단계: FigJam의 결정을 구현으로 전달 - 리뷰가 끝나면 에이전트가 보드의 결과를 다시 읽어 구현 계획을 갱신한다. - `get_figjam` 도구를 사용하면 다음 정보를 코딩 환경으로 가져올 수 있다. - 아키텍처 다이어그램 - 팀의 결정 사항 - 보드의 주석과 논의 내용 - 과거처럼 다이어그램을 캡처하고 댓글을 수동으로 요약해 에이전트에게 설명할 필요가 줄어든다. - 최종 PR에는 FigJam 보드 링크를 함께 연결해 설계 맥락을 보존할 수 있다. - 아키텍처가 코드 작성 전에 이미 검토되므로 PR 리뷰와 병합이 더 수월해진다. 에이전트에게 구현을 맡기더라도 계획·아키텍처·팀 의사결정은 사람이 먼저 검토하는 흐름을 만드는 것이 중요하다. FigJam과 MCP 도구를 함께 사용하면 에이전트의 빠른 실행력과 팀의 설계 검토를 연결해, 코드 품질과 협업 가시성을 높일 수 있다.

원문 읽기

AI 에이전트 Figma figjam 모델 컨텍스트 프로토콜+3

kakao2026년 4월 21일3분 읽기큐레이션 요약

카나나 스칼라 1회 세미나 현장 스케치

카카오의 ‘카나나 스칼라’ 1회 세미나는 카나나 파운데이션 모델의 기술 성과와 향후 AI 전략을 학계와 공유한 자리였다. 카카오는 적은 학습 토큰으로 높은 성능을 달성한 효율성과 한국어·다중모달 처리 능력을 강조했으며, 기술 주권과 서비스 최적화를 위해 자체 모델 개발을 지속하겠다는 방향을 밝혔다. 또한 초개인화 에이전트, 디지털 월드모델, 실전형 실행 능력, 산학 협력을 중심으로 AI 생태계를 확장할 계획을 제시했다. ## 카나나 파운데이션 모델의 성과 - 카카오는 외부 모델을 활용하는 대신, 처음부터 직접 개발하는 ‘카나나’ 파운데이션 모델 라인업을 구축하고 있다. - 유사한 규모의 글로벌 모델이 23조 개의 학습 토큰을 사용한 데 비해, 카나나는 약 11조 개의 토큰만으로도 뛰어난 성능을 달성했다고 설명했다. - 이는 학습 데이터의 정제 수준과 품질이 모델 효율성에 크게 기여했다는 의미로 소개됐다. - 텍스트와 이미지뿐 아니라 오디오까지 실시간 처리하는 옴니 모델 **Kanana-o**도 시연했다. - Kanana-o는 감정을 담은 음성 표현과 다화자 대화 처리를 선보였으며, 현장에서는 한국어 구사 능력이 뛰어나다는 평가를 받았다. ## 자체 모델 개발과 기술 주권 - 외부 AI 모델에 의존할 경우 라이선스 정책 변경이나 기술 공개 제한 등 외부 변수에 영향을 받을 수 있다. - 카카오는 독자 모델을 통해 서비스 환경에 맞는 고효율·맞춤형 AI를 운영하고, 실질적인 비즈니스 성과를 창출하려 한다. - 교수진은 한국의 문화적 맥락과 사회적 이슈를 독자적으로 통제하려면 자체 모델이 필요하다고 평가했다. - 독자적인 모델 역량은 서비스 안정성과 기술 주권을 확보하는 전략적 자산으로 논의됐다. ## 디지털 월드모델과 초개인화 에이전트 - 카카오는 카카오톡 플랫폼에서 발생하는 사용자의 행동과 대화 맥락을 이해하는 ‘상황 이해 지능’에 주목하고 있다. - 온디바이스 기술을 활용하면 대화 내용이 외부로 유출되지 않도록 보호하면서도 사용자의 요청을 즉시 처리할 수 있다. - 이를 바탕으로 사용자의 일상과 맥락에 맞춰 행동하는 초개인화 에이전트를 구현하려 한다. - 교수진은 디지털 월드모델을 로봇이나 물리적 환경에만 한정하지 말고, 플랫폼 내 상호작용과 인과관계를 예측하는 모델로 확장하자고 제안했다. - 카카오톡의 방대한 서비스·사용자 상호작용은 카카오만의 차별화된 디지털 월드모델을 구축할 기반으로 평가됐다. ## 생성 능력보다 중요한 실전형 실행력 - 카카오는 단순히 문장을 생성하는 능력보다, AI가 작업을 계획하고 필요한 기능을 호출해 최종 과업을 완료하는 능력을 중시한다. - 자체 ‘오케스트레이션 벤치마크’를 개발해 복합적인 실제 문제 해결 능력을 평가할 계획이다. - 이는 여러 단계의 추론과 도구 사용이 필요한 서비스 환경에서 AI의 실질적인 유용성을 검증하기 위한 접근이다. - 교수진은 사용자가 느끼는 지능은 벤치마크 점수보다 복잡한 요구를 끝까지 해결하는 능력에서 드러난다고 강조했다. - 글로벌 모델과 단순 생성 품질 경쟁을 하기보다, 카카오 서비스 안에서의 실행력에 집중하는 전략이 효과적일 수 있다는 의견이 제시됐다. ## 학계와 산업계의 AI 인재 협력 - 카카오는 세미나를 계기로 대학 연구실과 학부 AI 동아리에 GPU 자원을 지원하는 방안을 검토하고 있다. - 지원 방식으로는 GPU 크레딧 제공이나 공동 과제 형태 등이 논의됐다. - 이러한 협력은 연구자와 학생들이 실제 AI 모델 개발과 실험을 수행할 수 있도록 돕고, 국내 AI 인재 생태계를 강화하는 데 목적이 있다. - 카나나 스칼라는 기술 논의뿐 아니라 지속적인 산학 협력의 출발점으로 추진될 예정이다. 카카오는 카나나를 단순한 대규모 언어 모델이 아니라, 한국어와 국내 서비스 맥락을 이해하고 실제 작업까지 수행하는 플랫폼형 AI로 발전시키려 한다. 향후에는 모델 성능 자체보다 개인정보 보호, 카카오 서비스와의 결합도, 복합 과업 실행력, 그리고 산학 협력을 통한 생태계 확장이 중요한 경쟁력이 될 것으로 보인다.

원문 읽기

AI 에이전트 AI 멀티모달 AI orchestration+4

cloudflare2026년 4월 21일원문

봇 대 인간을 넘어서 (새 탭에서 열림)

웹 트래픽을 단순히 '인간'과 '봇'으로 이분법적으로 구분하던 시대는 지나갔으며, 이제는 사용자의 **의도(Intent)와 행동(Behavior)**을 파악하는 방향으로 웹 보호 전략이 진화해야 합니다. AI 에이전트의 등장과 자동화 도구의 일상화로 인해 인간과 봇의 경계가 모호해졌으며, 단순한 차단보다는 자원 보호와 데이터 관리라는 본질적인 목적에 집중해야 합니다. 따라서 미래의 웹 보안 시스템은 기술적 신호뿐만 아니라 맥락적인 비즈니스 로직을 결합하여 복합적인 위협에 대응할 수 있는 구조를 갖추어야 합니다. ### 웹 생태계의 암묵적 합의와 붕괴 * **브라우저의 중재 역할:** 과거의 웹 브라우저는 사용자의 이익(개인정보 보호, 가독성)과 웹사이트 소유자의 이익(콘텐츠 렌더링, 광고 노출) 사이에서 균형을 맞추는 '사용자 에이전트' 역할을 수행해 왔습니다. * **AI 에이전트의 파괴적 영향:** 최신 AI 에이전트들은 브라우저를 통한 표준 렌더링 과정을 생략하고 원시 데이터만 수집합니다. 이는 웹사이트 운영자가 콘텐츠의 가치를 실현(수익화)하거나 사용자의 의도를 파악하는 경로를 차단하여 기존의 웹 운영 모델을 위협합니다. * **투명성 상실:** AI가 데이터를 수집할 때 이것이 단일 사용자를 위한 요약용인지, 아니면 수백만 명을 위한 모델 학습용인지 구분할 수 없게 되면서 웹사이트 소유자의 통제권이 약화되고 있습니다. ### 기존 봇 관리 방식의 한계 * **단순 속도 제한(Rate Limiting):** 특정 IP의 요청 횟수를 제한하는 방식은 VPN이나 공용 프록시를 사용하는 다수의 선량한 사용자를 오인 차단할 위험이 큽니다. * **인간 증명(CAPTCHA)의 유효성 저하:** 캡차는 '인간성'을 확인하지만 '악의적인 인간'의 행동은 막지 못하며, AI 기술의 발달로 인해 자동화된 도구가 캡차를 통과하는 것이 점점 더 쉬워지고 있습니다. * **신호의 불확실성:** 장치 성능(CPU/GPU)이나 브라우저 지문(Fingerprinting)을 활용한 감지는 기기마다 사양이 다르고 개인정보 보호 강화로 인해 점차 정확도가 떨어지고 있습니다. ### 의도 중심의 새로운 보호 모델 * **행동 분석으로의 전환:** 접속자가 누구인지보다 "이 요청이 광고 사기에 연루되었는가?", "크롤러의 부하가 유입 트래픽에 비해 적정한가?"와 같은 실질적인 질문에 집중해야 합니다. * **봇 인증 및 신뢰 구축:** 익명성을 유지하면서도 신뢰를 증명하기 위해 HTTP 메시지 서명(Message Signatures)을 통한 크롤러 인증이나, 개인정보를 보호하는 증명 방식(Privacy Pass) 도입이 필요합니다. * **맥락적 제어:** 알려진 봇(검색 엔진 등)은 허용하되, 데이터 추출만 목적으로 하는 원하지 않는 자동화 도구는 의도와 행동 패턴에 따라 차별적으로 대응하는 유연한 정책이 요구됩니다. ### 향후 대응을 위한 제언 웹 보안을 설계할 때 더 이상 '봇 차단' 자체를 최종 목표로 삼아서는 안 됩니다. 대신 자신의 서비스에 유익한 자동화(예: 뉴스 요약 AI)와 해로운 자동화(예: 무단 데이터 크롤링)를 구분할 수 있는 세분화된 가시성을 확보해야 합니다. 이를 위해 클라이언트의 무결성을 증명할 수 있는 기술적 수단을 도입하고, 변화하는 웹 클라이언트의 특성에 맞춰 보안 정책을 지속적으로 업데이트하는 것이 중요합니다.

AI 에이전트 bot-management web-browsers zero-trust-security+4

figma2026년 4월 21일3분 읽기큐레이션 요약

AI 리더들이 디자인 플레이북을 활용하는 방법 | Figma 블로그

AI 전환을 성공시키는 리더는 단순히 새로운 도구를 도입하는 기술자가 아니라, 디자인 원칙에 따라 일하는 방식을 재설계하는 사람이다. 이들은 AI를 직접 사용해 특성을 익히고, 조직 구성원의 실제 업무 흐름을 관찰하며, 아이디어를 프로토타입으로 구체화한다. 중요한 것은 도구 도입 자체가 아니라 팀의 행동과 시스템을 실질적으로 변화시키는 것이다. ## AI 리더의 역할과 ‘보여주기식 진전’의 함정 - AI 혁신·가속화 역할은 다음과 같은 일을 담당한다. - 업무 흐름을 빠르게 개선 - AI 기반 기능 출시 촉진 - 조직 전반의 도구 도입 지원 - 제품, 고객 지원, 내부 업무에 AI를 적용하는 방향 조율 - AI 도입이 확산되면서 워크플로와 시스템뿐 아니라 이를 사용하는 팀 자체도 변화시켜야 한다. - 새로운 도구를 도입했다는 사실만으로 성과를 증명하려는 **‘보여주기식 진전(performative progress)’**에 빠질 수 있다. - 효과적인 리더는 도구를 추가하는 데 그치지 않고, AI 시대에 맞는 새로운 업무 방식을 설계한다. ## 직접 사용하며 AI라는 재료 익히기 - 디자인의 기본 원칙은 다루는 재료를 직접 사용해 깊이 이해하는 것이다. - AI 리더도 전략적 관점에만 머물지 말고 직접 프롬프트를 작성하고 에이전트를 만들어야 한다. - 여러 AI 도구를 실제로 사용하면 다음을 파악할 수 있다. - 도구의 장점과 한계 - 확률적 결과가 만들어내는 불확실성 - 실제 업무에서 발생하는 트레이드오프 - 도입 과정에서 사용자가 겪는 마찰 - 업무 외 영역에서 AI를 실험하는 것도 유용하다. - 여행 계획 - 집 꾸미기 - 생일 파티 준비 - 봉사활동 관리 - 이런 경험은 단순한 호기심 충족이 아니라, AI의 동작 방식을 체득하는 **AI 활용 역량**의 일부다. ## 관찰을 통해 실제 업무 흐름 이해하기 - 리더가 AI를 직접 사용하는 것만으로는 부족하며, 조직의 여러 팀이 AI를 어떻게 활용하는지도 관찰해야 한다. - 도구의 기능이나 최종 산출물보다 중요한 것은 업무 과정에서 다음이 어디서 발생하는지 파악하는 것이다. - 병목 - 반복 작업 - 사용자의 불편 - 문제 해결을 촉진하는 지점 - 관찰 대상이 될 수 있는 신호는 다양하다. - Slack 대화 - 설문 응답 - 도구 사용 패턴 - 구성원의 기대와 불만 - 팀이 업무를 우회하거나 자체 해결책을 만드는 방식 - 문서상으로 완벽한 AI 자동화도 복잡한 기존 업무 흐름에 마찰을 추가하면 사용률이 정체될 수 있다. - 따라서 낮은 도입률을 단순히 사용자의 저항으로 해석하지 말고, 기존 프로세스와의 연결 방식에 문제가 없는지 확인해야 한다. ## 아이디어를 프로토타입으로 구체화하기 - 디자인은 관찰과 실행을 함께 요구한다. - AI 관련 아이디어는 나빠서 실패하는 것이 아니라, 팀이 아이디어를 구체적으로 상상하거나 검토하지 못해서 실패할 수 있다. - 초기 개념을 실제로 볼 수 있는 프로토타입으로 만들면 다음이 가능해진다. - 추상적인 아이디어를 시각화 - 팀 간 이해 차이 축소 - 빠른 피드백 수집 - 실행 가능성과 문제점 조기 검증 - 글에서는 Figma Make를 활용해 AI 아이디어를 유형화하고 실제 형태로 발전시키는 방법을 소개하려 한다. 제공된 본문은 이 섹션의 도입부에서 끝나므로 구체적인 사례와 후속 원칙은 포함되어 있지 않다. AI 전환을 추진할 때는 도구 도입 건수보다 실제 사용 경험과 업무 변화에 집중하는 것이 좋다. 리더가 직접 AI를 실험하고, 구성원의 업무를 관찰하며, 작은 프로토타입으로 아이디어를 검증하는 순환을 구축해야 한다.

원문 읽기

AI 에이전트 AI 프로토타이핑 자동화+2

cloudflare2026년 4월 17일원문

Agent Readiness 점수를 소개합니다. 내 사이트가 에이전트 대응 준비가 되었는지 확인해 보세요. (새 탭에서 열림)

웹 환경이 브라우저와 검색 엔진을 넘어 AI 에이전트 중심으로 진화함에 따라, 사이트가 AI 모델에 얼마나 최적화되어 있는지를 평가하는 새로운 기준이 필요해졌습니다. Cloudflare는 웹사이트의 AI 에이전트 대응 수준을 측정하고 개선 가이드를 제공하는 도구인 'isitagentready.com'과 관련 데이터셋을 공개했습니다. 이를 통해 사이트 소유자는 에이전트 전용 콘텐츠 제공 및 권한 제어 표준을 도입함으로써 AI 도구가 더 빠르고 저렴하게 정보를 처리할 수 있도록 최적화할 수 있습니다. **웹 사이트의 AI 에이전트 표준 도입 현황** * 전 세계 상위 20만 개 도메인을 분석한 결과, 대다수의 사이트가 여전히 전통적인 검색 엔진 크롤러 방식에 머물러 있어 에이전트 준비도가 낮은 것으로 나타났습니다. * `robots.txt`는 78%의 사이트가 보유하고 있으나, AI 에이전트 전용 규칙이나 AI 사용 선호도(Content Signals)를 명시한 곳은 4%에 불과합니다. * 에이전트가 HTML 대신 효율적인 마크다운 형식을 요청하는 '마크다운 콘텐츠 협상(Markdown content negotiation)' 도입률은 3.9% 수준입니다. * MCP(Model Context Protocol) 서버 카드나 API 카탈로그(RFC 9727)와 같은 최신 에이전트 상호작용 표준은 현재 도입 초기 단계로, 이를 선제적으로 도입하면 AI 에이전트 생태계에서 두각을 나타낼 수 있습니다. **에이전트 준비도 점수 측정 항목** * **발견 가능성(Discoverability):** `robots.txt`와 `sitemap.xml`은 물론, 에이전트가 HTML을 파싱하지 않고도 리소스를 즉시 찾을 수 있도록 HTTP 응답 헤더의 `Link` 헤더(RFC 8288) 활용 여부를 평가합니다. * **콘텐츠 접근성(Content Accessibility):** LLM이 읽기 쉬운 구조로 사이트 맵을 제공하는 `llms.txt`와 텍스트 기반의 마크다운 제공 여부를 확인합니다. 마크다운은 HTML 대비 토큰 사용량을 최대 80%까지 줄여 비용 절감과 응답 속도 향상에 기여합니다. * **봇 제어 및 권한(Bot Access Control):** AI 봇 전용 접근 규칙과 웹 봇 인증 방식이 올바르게 설정되어 있는지 체크합니다. * **에이전트 역량(Capabilities):** API 카탈로그, OAuth 서버 검색(RFC 8414), MCP 서버 카드 등 에이전트가 사이트의 기능을 직접 수행하는 데 필요한 기술 표준 준수 여부를 측정합니다. **실무적인 최적화 지원 및 도구 활용** * `isitagentready.com`은 구글 라이트하우스(Lighthouse)처럼 동작하며, 진단 결과에서 통과하지 못한 항목에 대해 코딩 에이전트에게 바로 입력할 수 있는 구현용 프롬프트를 제공합니다. * 이 도구 자체도 MCP 서버를 노출하고 있어, 사용자는 웹 인터페이스 없이도 에이전트를 통해 프로그래밍 방식으로 사이트 스캔을 수행할 수 있습니다. * Cloudflare는 자사 개발자 문서를 에이전트 친화적으로 개편하여 AI 도구가 문서를 참조할 때 발생하는 비용을 대폭 절감하고 답변의 정확도를 높이는 사례를 직접 증명하고 있습니다. 웹 사이트 운영자는 `isitagentready.com`을 통해 현재 사이트의 상태를 점검하고, 특히 토큰 비용 효율성이 높은 **마크다운 콘텐츠 협상**과 **API 카탈로그** 표준을 우선적으로 도입하는 것을 권장합니다. 이는 AI 에이전트가 사이트 정보를 더 정확하게 이해하고 사용자에게 전달하도록 만드는 가장 효과적인 방법입니다.

AI 에이전트 데이터베이스 설계 cloudflare markdown+4

cloudflare2026년 4월 15일원문

Browser Run: 에이전트에게 브라우저를 제공하세요 (새 탭에서 열림)

Cloudflare는 기존의 'Browser Rendering' 서비스를 'Browser Run'으로 재브랜딩하며 AI 에이전트가 웹과 상호작용하는 데 최적화된 강력한 브라우징 인프라를 공개했습니다. 이 서비스는 Cloudflare의 글로벌 네트워크에서 전체 브라우저 세션을 실행하고, 에이전트가 사이트 탐색, 데이터 추출, 폼 작성 등을 대규모로 수행할 수 있도록 지원합니다. 결과적으로 개발자는 인프라 관리 부담 없이 AI 에이전트에게 실시간 모니터링, 인간 개입, 세밀한 제어 기능을 갖춘 브라우저를 제공할 수 있게 되었습니다. **에이전트 중심의 확장된 브라우저 인프라** * **온디맨드 인스턴스 실행:** Cloudflare 글로벌 네트워크를 통해 헤드리스 크롬(Chrome) 인스턴스를 즉시 생성하며, 버전 관리나 서버 유지보수 없이 저지연 환경에서 브라우징 세션을 운영할 수 있습니다. * **대규모 동시성 지원:** 동시 실행 가능한 브라우저 한도를 기존 30개에서 120개로 대폭 늘려, 대량의 작업을 동시에 처리해야 하는 에이전트의 요구사항을 충족합니다. * **에이전트 SDK 결합:** Agents SDK와 연동하여 웹을 탐색하고 정보를 기억하며 자율적으로 행동하는 장기 실행(Long-running) 에이전트 구축이 가능합니다. **CDP 엔드포인트를 통한 정밀한 제어** * **직접적인 프로토콜 노출:** Chrome DevTools Protocol(CDP) 엔드포인트를 직접 노출하여 에이전트가 브라우저에 대해 최대 수준의 제어권을 가질 수 있게 합니다. * **효율적인 모델 통신:** Puppeteer나 Playwright 같은 고수준 라이브러리를 거치지 않고 원시 CDP 메시지를 모델에 직접 전달할 수 있어, 토큰 효율적인 브라우저 제어가 가능합니다. * **간편한 이관:** 기존에 자체 호스팅 크롬에서 실행하던 CDP 기반 자동화 스크립트를 코드 한 줄의 설정 변경(WebSocket URL 교체)만으로 Browser Run에서 실행할 수 있습니다. **실시간 모니터링과 인간 협업 기능** * **Live View:** 에이전트가 현재 무엇을 보고 어떤 동작을 하는지 실시간으로 확인하며, 작업 실패 시 원인을 즉각 파악할 수 있습니다. * **Human in the Loop:** 로그인이나 예상치 못한 예외 상황 발생 시 에이전트가 작업을 중단하는 대신 인간에게 제어권을 넘기고, 문제가 해결되면 다시 제어권을 받아 작업을 이어가는 워크플로우를 지원합니다. * **세션 녹화(Session Recordings):** DOM 변경, 사용자 상호작용, 페이지 탐색을 포함한 모든 세션을 녹화하여 사후 디버깅 및 분석에 활용할 수 있습니다. **생태계 확장 및 차세대 웹 표준 지원** * **MCP(Model Context Protocol) 지원:** Claude Desktop, Cursor, OpenCode와 같은 AI 코딩 에이전트들이 Browser Run을 원격 브라우저로 사용할 수 있도록 지원합니다. * **WebMCP 도입:** 웹사이트가 에이전트가 수행 가능한 액션을 직접 선언하게 함으로써, 인간 중심의 웹 구조에서 발생하던 에이전트의 탐색 오류를 줄이고 신뢰성을 높입니다. Cloudflare Browser Run은 단순한 브라우저 자동화 도구를 넘어 AI 에이전트의 '눈'과 '손' 역할을 하는 필수 인프라로 자리 잡고 있습니다. 특히 복잡한 로그인 처리나 실시간 디버깅이 필요한 에이전트 환경을 구축하려는 개발자에게 CDP 직접 노출과 Human-in-the-loop 기능은 매우 강력한 이점을 제공할 것입니다.

AI 에이전트 cloudflare human-in-the-loop puppeteer+4

figma2026년 4월 15일3분 읽기큐레이션 요약

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 생성 과정에 연결해 주는 기술로 활용해야 한다.

원문 읽기

AI 에이전트 Figma AI 디자인 시스템+3

github2026년 4월 14일4분 읽기큐레이션 요약

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 같은 공격·방어 실습을 통해 실제 시스템의 실패 가능성을 사전에 경험하는 것이 효과적인 준비 방법이다.

원문 읽기

AI 에이전트 모델 컨텍스트 프로토콜 ai-security prompt-injection+2

slack2026년 4월 13일4분 읽기큐레이션 요약

장기 실행 에이전트 애플리케이션의 컨텍스트 관리

장시간 실행되는 멀티 에이전트 시스템은 모든 대화 기록을 그대로 누적하면 컨텍스트 윈도우 한계와 응답 품질 저하에 직면한다. Slack은 이를 해결하기 위해 Director의 구조화된 Journal, Critic의 신뢰도 주석 Review, 시간순 Timeline이라는 세 가지 컨텍스트 채널을 분리해 사용한다. 각 에이전트에 필요한 맥락만 제공함으로써 팀 전체의 일관성을 유지하면서도 과도한 정보 공유로 인한 창의성 저하와 확증편향을 줄이는 것이 핵심이다. ## 장시간 에이전트 시스템의 컨텍스트 문제 - 언어 모델 API는 상태가 없으므로, 호출 간 연속성을 유지하려면 전체 메시지 이력을 매번 전달해야 한다. - 에이전트 프레임워크는 일반적으로 메시지 기록을 누적하지만, 기록이 길어질수록 컨텍스트 윈도우가 빠르게 소진된다. - 컨텍스트 한도에 도달하기 전부터 응답 품질과 추론 능력이 저하될 수 있다. - 보안 조사처럼 수백 번의 추론 요청과 수 MB의 결과를 생성하는 작업에서는 단순한 대화 기록 누적만으로는 부족하다. - 멀티 에이전트 환경에서는 모든 정보를 공유하면: - 각 에이전트의 역할과 집중력이 흐려지고 - 기존 결론에 끌리는 확증편향이 커지며 - 독립적인 탐색과 창의적 추론이 억제될 수 있다. - 반대로 공유 정보가 너무 적으면 각 에이전트가 전체 조사 방향을 이해하지 못해 결과가 단절된다. ## 세 가지 컨텍스트 채널 Slack의 보안 조사 시스템은 Director가 조사 전체를 조율하고, 여러 Expert가 증거를 수집하며, Critic이 결과를 검토하는 구조다. - **Director’s Journal** - Director의 구조화된 작업 메모이자 장기 기억이다. - 조사 중 결정, 관찰, 사실, 가설, 미해결 질문 등을 기록한다. - **Critic’s Review** - Expert의 발견 사항을 검토하고 주석을 추가한 보고서다. - 각 결과의 신뢰도 점수를 포함해 어떤 증거를 얼마나 믿을지 판단하게 한다. - **Critic’s Timeline** - 여러 결과를 시간순으로 통합한 기록이다. - 사건의 진행 순서와 인과관계를 파악하도록 돕고, 신뢰도 점수도 함께 제공한다. - 세 채널은 서로 다른 목적을 가지며, 에이전트가 전체 메시지 이력 대신 역할에 맞는 맥락을 사용하도록 한다. ## Director’s Journal의 역할 Director는 어떤 질문을 던질지, 어떤 Expert를 호출할지, 언제 조사를 종료할지를 결정한다. 여러 단계와 라운드에 걸쳐 일관된 결정을 내리려면 이전에 무엇을 발견하고 판단했는지 기억해야 한다. - Journal은 Director가 사용하는 전용 journaling tool을 통해 업데이트된다. - 시스템 프롬프트는 Director가 Journal을 자주 갱신하고 짧은 메모 형태로 기록하도록 유도한다. - 기록의 목적은 완성된 보고서를 작성하는 것이 아니라, Director의 현재 사고 과정과 조사 상태를 유지하는 것이다. - 모든 에이전트는 현재 Journal 내용을 시간순으로 프롬프트에서 전달받는다. - 각 에이전트의 시스템 프롬프트에는 다음 내용이 설명된다. - Director의 역할 - 자신과 Director의 관계 - Journal의 목적 - Journal에 기록된 내용을 해석하는 방법 ## Journal의 기록 유형 Journal은 메모를 여섯 가지 유형으로 구분한다. - **decision**: 전략적 선택 - 예: 네트워크 활동보다 인증 이상 징후에 집중하기로 결정 - **observation**: 관찰된 패턴 - 예: 성공적인 인증 전에 여러 번의 로그인 실패가 발생 - **finding**: 확인된 사실 - 예: 사용자가 기존 이력에 없는 IP에서 인증 - **question**: 아직 해결되지 않은 질문 - 예: 의심스러운 활동 전후 중 언제 VPN 연결이 성립했는가 - **action**: 수행했거나 수행할 조치 - 예: Cloud Expert에게 EC2 인스턴스 활동 조사 요청 - **hypothesis**: 현재 검토 중인 가설 - 예: 계정 탈취보다 자격 증명 대입 공격에 가까운 패턴 추가로 각 항목에는 다음 정보를 포함할 수 있다. - 우선순위 - 후속 조치 목록 - 관련 증거 자료에 대한 인용 또는 참조 - 조사 단계(phase) - 라운드 번호 - 기록 시각 Journaling tool 자체는 복잡한 추론을 수행하지 않고 항목을 누적하는 역할만 담당한다. ## Journal을 통한 팀 정렬 Journal은 Director가 조사 방향을 유지하고 필요할 때 전략을 수정하도록 돕는다. - 조사 진행 상황을 관찰하고 측정할 수 있다. - 더 이상 유용하지 않은 조사 경로나 막다른 길을 식별할 수 있다. - 새 증거에 따라 가설과 조사 우선순위를 수정할 수 있다. - 다른 에이전트에게 공통된 조사 서사를 제공해 각자의 결과가 전체 조사와 연결되게 한다. - Director가 내린 결정과 아직 남은 질문을 명시적으로 전달해, Expert들이 중복되거나 무관한 작업을 수행하는 것을 줄인다. ## 실제 Journal 기록의 특징 글의 예시에서는 커널 모듈 로딩으로 탐지된 보안 알림을 조사한다. 실제로는 개발자가 개발 환경에서 패키지를 설치하던 중 발생한 오탐이었다. - 이벤트가 직접적인 `modprobe` 실행이 아니라 패키지 설치 과정의 스크립트였다는 점을 기록한다. - 관련 Expert 영역으로 엔드포인트 텔레메트리, 사용자 권한, 호스트 설정, 사용자 행동 패턴을 지정한다. - 개인 개발자 워크스테이션과 사용자 세션으로 보이는 단서를 정리한다. - 탐지 규칙이 실제 모듈 로딩이 아니라 스크립트 경로의 `"kmod"` 문자열에 반응했을 가능성을 제시한다. - 개발 환경에서 root 권한이 의도적으로 허용된다는 사실을 확인한다. - 프로세스 부모 관계, 엔드포인트 쿼리, SSH 인증서 로그 등을 추가로 검증할 대상으로 남긴다. - 조사 중간 결론으로 해당 이벤트가 정상적인 시스템 관리 활동에 의한 오탐일 가능성을 기록한다. 실무적으로는 전체 대화 로그를 무제한 보존하기보다, 역할별로 필요한 정보를 구조화하고 요약하는 방식이 적합하다. 특히 Director의 Journal에는 결정·근거·미해결 질문을 명시하고, Critic의 결과에는 신뢰도와 시간 순서를 함께 관리하면 장기 실행 에이전트의 일관성과 독립적인 탐색을 동시에 확보할 수 있다.

원문 읽기

AI 에이전트 대규모 언어 모델 multi-agent-systems context-management+2

gitlab2026년 4월 13일원문

GitLab, 2026년 옴디아 유니버스 리더로 선정 (새 탭에서 열림)

GitLab이 2026년 옴디아 유니버스(Omdia Universe) AI 지원 소프트웨어 개발 부문에서 리더로 선정되며, 전체 소프트웨어 개발 수명 주기(SDLC)를 아우르는 독보적인 기술력을 입증했습니다. 이번 평가는 단순한 코드 생성을 넘어 테스트, 보안, 배포 및 오케스트레이션 능력을 중점적으로 다뤘으며, GitLab은 솔루션 광범위성(100%)과 전략적 혁신성(88%) 등 주요 항목에서 최고 점수를 기록했습니다. 결과적으로 GitLab은 AI 도입이 단순한 개발 속도 향상을 넘어 실제 비즈니스 가치 창출과 운영 효율성으로 이어질 수 있음을 보여주었습니다. ### SDLC 전반을 아우르는 솔루션의 확장성 * GitLab은 '솔루션 광범위성' 항목에서 100% 점수를 획득하며, 계획 및 요구사항 관리부터 배포 및 이슈 해결까지 SDLC 전 단계를 단일 플랫폼에서 지원합니다. * 플래너 에이전트(Planner Agent)와 보안 분석 에이전트(Security Analyst Agent)를 통해 개발 지연이 빈번한 스프린트 계획 및 취약점 분석 단계까지 AI 지원을 확장했습니다. * 단순 코드 생성을 넘어 테스트, 보안 검토, 배포 단계를 통합함으로써 코딩 단계의 가속화가 병목 현상 없이 전체 인도 속도 향상으로 이어지도록 설계되었습니다. ### 에이전트 기반 AI와 전략적 혁신 * Anthropic, Google, AWS와의 파트너십을 통한 멀티 모델 지원을 제공하여, 사용자가 워크로드와 데이터 요구사항에 최적화된 모델을 선택할 수 있습니다. * 에이전트가 이슈, 머지 리퀘스트(MR), 파이프라인, 보안 결과물 간의 문맥을 잃지 않고 협업하는 '통합 문맥(Unified Context)' 아키텍처를 구축했습니다. * 2026년 평가의 핵심 지표인 '에이전틱 AI(Agentic AI)' 역량에서 자율적인 작업 조정 및 전문 에이전트 간의 핸드오프 오케스트레이션 능력을 인정받았습니다. ### 엔터프라이즈 환경을 위한 보안 및 실행력 * 고객의 비공개 데이터를 학습에 사용하지 않는 프라이버시 우선 아키텍처를 통해 엔터프라이즈 급 보안을 보장합니다. * SOC 2, ISO 27001 인증 및 폐쇄망(Air-gapped) 환경 지원, 자체 호스팅 AI 모델 지원 등을 통해 규제가 엄격한 산업군의 요구사항을 충족합니다. * AI 영향력 대시보드(AI Impact Dashboard)를 통해 사이클 타임, 배포 빈도 등 AI가 실제 생산성에 미치는 영향을 지표로 시각화하여 제공합니다. ### 개발자와 AI 에이전트의 역할 변화 * 개발팀의 역할은 이제 직접 코드를 작성하는 것에서 AI 에이전트를 감독하고 기술적 요구사항 및 보안 가드레일을 적용하는 방향으로 진화하고 있습니다. * 단순히 코드 생성 속도에만 집중하는 조직은 배포와 테스트 단계에서 병목 현상을 겪게 되므로, 전체 수명 주기를 관리할 수 있는 플랫폼 도입이 필수적입니다. * GitLab은 보안과 운영이 통합된 환경을 제공함으로써, AI가 생성한 코드가 고품질과 성능을 유지하며 즉시 생산 환경에 반영될 수 있는 혁신 속도를 지원합니다.

AI 에이전트 데이터베이스 설계 CI/CD gitlab+4

github2026년 4월 6일4분 읽기큐레이션 요약

GitHub Copilot CLI, 세컨드 오피니언을 위해 여러 모델 제품군 결합

GitHub Copilot CLI가 주 모델과 다른 AI 계열의 모델을 활용해 작업을 검토하는 실험 기능 **Rubber Duck**을 공개했습니다. Rubber Duck은 계획 수립, 복잡한 구현, 테스트 작성 후처럼 오류를 조기에 발견하기 좋은 시점에 독립적인 피드백을 제공합니다. 평가 결과 Claude Sonnet과 GPT-5.4 기반 Rubber Duck 조합은 Sonnet과 Opus 단독 실행 성능 차이의 74.7%를 줄였습니다. ## 자신감 있는 실수가 누적되는 문제 - 코딩 에이전트는 일반적으로 다음 순서로 작업합니다. - 요구사항 분석 - 계획 수립 - 구현 - 테스트 - 문제 발생 시 반복 수정 - 초기 계획의 잘못된 가정이나 비효율은 이후 구현의 기반이 되어 오류를 연쇄적으로 키울 수 있습니다. - 에이전트가 자신의 결과를 스스로 검토하는 방식도 도움이 되지만, 동일한 모델은 같은 학습 데이터와 편향, 맹점을 공유합니다. - 따라서 자기 검토만으로는 발견하기 어려운 문제를 찾기 위해 다른 모델 계열의 관점이 필요합니다. ## 다른 모델 계열을 활용하는 Rubber Duck - Rubber Duck은 주 에이전트의 계획과 작업을 검토하는 전문 리뷰 에이전트입니다. - 현재 Claude 모델을 주 오케스트레이터로 선택하면 Rubber Duck은 GPT-5.4를 사용합니다. - 검토 결과는 다음과 같은 고가치 우려 사항을 짧고 집중적으로 제시합니다. - 주 에이전트가 놓친 세부 사항 - 다시 검토해야 할 가정 - 잠재적인 엣지 케이스 - 현재 Claude Opus, Sonnet, Haiku를 주 모델로 사용할 때 활성화할 수 있으며, 향후 다른 모델 조합도 실험할 예정입니다. ## 복잡한 작업에서의 효과 - SWE-Bench Pro의 실제 오픈소스 프로젝트 기반 대형 코딩 문제로 평가했습니다. - Claude Sonnet 4.6과 GPT-5.4 Rubber Duck 조합은 Claude Opus 4.6 단독 실행과 유사한 해결률을 기록했습니다. - Sonnet과 Opus의 성능 차이 중 74.7%를 줄였습니다. - 특히 다음 조건의 작업에서 효과가 컸습니다. - 3개 이상의 파일을 수정하는 작업 - 70단계 이상이 필요한 장기 작업 - 복잡한 리팩터링과 아키텍처 변경 - 성능 개선 폭은 일반적으로 Sonnet 기준 3.8%, 가장 어려운 문제에서는 4.8%였습니다. ## Rubber Duck이 발견한 오류 사례 - **스케줄러의 구조적 오류** - 스케줄러가 시작 직후 종료되어 작업을 하나도 실행하지 못하는 문제를 발견했습니다. - 수정하더라도 내부 작업 중 하나가 무한 루프라는 추가 문제도 확인했습니다. - **반복문으로 인한 데이터 손실** - 반복문이 매번 같은 `dict` 키를 덮어쓰는 버그를 찾았습니다. - 그 결과 Solr 검색 요청에서 네 개의 facet 범주 중 세 개가 조용히 사라졌습니다. - **파일 간 데이터 흐름 단절** - 여러 파일이 Redis 키를 읽지만 새 코드가 해당 키를 더 이상 기록하지 않는 문제를 발견했습니다. - 배포 후 이메일 확인 UI와 정리 작업이 조용히 고장 날 수 있는 상황이었습니다. ## 검토가 실행되는 시점 Rubber Duck은 필요성이 높은 체크포인트에서 자동으로 호출되거나 사용자가 직접 요청할 수 있습니다. - **계획 작성 후** - 잘못된 설계 결정을 구현 전에 발견해 후속 오류의 누적을 막습니다. - **복잡한 구현 후** - 여러 파일에 걸친 코드의 엣지 케이스와 구조적 문제를 점검합니다. - **테스트 작성 후, 실행 전** - 테스트 커버리지의 공백이나 잘못된 단정을 찾아냅니다. - **에이전트가 작업 루프에 빠졌을 때** - 진전이 없는 상황에서 새로운 관점을 제공해 막힌 지점을 해결합니다. - **사용자 요청 시** - 사용자가 언제든 작업을 비판적으로 검토하도록 요청할 수 있습니다. - Copilot은 피드백을 반영한 뒤 무엇이 어떻게 바뀌었는지 보여줍니다. ## 사용 방법과 적합한 활용 사례 - GitHub Copilot CLI를 설치한 뒤 `/experimental` 명령으로 실험 기능을 활성화합니다. - 모델 선택기에서 Claude 모델을 선택하고 GPT-5.4 사용 권한이 있어야 합니다. - Rubber Duck은 자동으로 호출되거나 “작업을 검토해 달라”고 요청해 수동 실행할 수 있습니다. - 특히 다음 작업에 적합합니다. - 복잡한 리팩터링 - 아키텍처 변경 - 실패 비용이 큰 고위험 작업 - 테스트 커버리지 검증 - 구현 전 계획에 대한 독립적인 의견 확인 Rubber Duck은 코딩 에이전트를 단순히 더 오래 실행하는 대신, 서로 다른 모델 계열의 관점으로 중요한 의사결정을 교차 검증하려는 접근입니다. 복잡하거나 영향 범위가 큰 작업에서는 계획 단계와 테스트 실행 전에 검토를 요청하는 것이 실용적인 활용법입니다.

원문 읽기

AI 에이전트 코드 리뷰 github-copilot-cli claude+3