AI 에이전트

171 개의 포스트

kakao4분 읽기큐레이션 요약

Vibe Coding하는 비개발자는 개발자인가(3)

AI 에이전트는 비개발자에게 단순히 코드를 생성해주는 도구를 넘어, 업무를 실행 가능한 구조로 재정의하게 만드는 동반자다. 글쓴이는 로컬 HTML 도구를 공유 서비스로 확장하고, 스프레드시트·웹훅·환경변수·스킬·MCP 등을 활용하며 입력과 출력, 권한, 보안, 검증 조건을 자연스럽게 고민하게 되었다고 말한다. 결국 중요한 것은 코딩 능력 자체보다 자신의 업무를 AI가 수행할 수 있는 단위와 규칙으로 구조화하는 능력이다. ## 로컬 HTML에서 공유 데이터 도구로 - 초기 도구는 브라우저에서 실행하는 단일 HTML 파일이었다. - 서버와 데이터베이스가 필요 없고 혼자 사용하기에 충분했다. - 다른 사람과 공유하려면 배포 주소, 최신 버전 반영, 데이터 저장 문제가 생겼다. - 정적인 화면을 넘어 다음 요구사항이 발생했다. - 과거 입력값 조회 - 여러 사용자의 데이터 공유 - 상태 변경에 따른 화면 갱신 - 사용자별 조회·수정 권한 관리 - 잘못된 수정의 복구와 데이터 백업 - 정식 데이터베이스는 접근 권한 설계와 운영·보안 부담이 컸다. - 대신 구글 스프레드시트를 공유 데이터 저장소로 활용했다. - 기존 협업 UI와 권한 관리 기능을 이용할 수 있었다. - 수정 이력과 공유 기능도 이미 제공됐다. - Apps Script 코드를 직접 붙여넣는 방식에서 시작해, 이후 `clasp`를 이용한 Apps Script API 기반 배포·실행 방식으로 발전했다. - 핵심 변화는 코드를 많이 작성한 것이 아니라, 데이터 위치·공유 방식·권한·변경 이력을 설계하기 시작했다는 점이다. ## 웹훅 연동과 보안 습관 - AI 에이전트의 도움으로 업무 환경과 연결되는 웹훅 봇을 구현할 수 있게 되었다. - 웹훅 URL과 토큰을 다루면서 다음 보안 원칙을 익히게 됐다. - 비밀값을 코드나 프롬프트에 직접 입력하지 않기 - `.env` 파일에서 환경변수로 읽기 - `.gitignore`로 저장소에 비밀값이 올라가지 않도록 하기 - 로그에 토큰 등 민감정보를 출력하지 않기 - 실제 비밀값 대신 placeholder 사용하기 - 작은 자동화라도 외부 시스템과 연결되는 순간 실행 환경과 접근 권한, 비밀값 관리가 함께 고려되어야 한다. - 보안은 별도의 전문 작업이 아니라 AI에게 코드를 요청할 때마다 반복하는 작업 습관이 되었다. ## 손작업을 명세와 파이프라인으로 바꾸기 - 파일 복사·정리, 문서 변환, 영상 편집, 음성 추출, 요약 등 기존의 수작업도 AI 에이전트에게 맡기기 시작했다. - 사람이 직접 할 때는 감으로 처리하던 작업도 에이전트에게 맡기려면 구체적인 명세가 필요했다. - 대상 입력 파일 - 결과 파일명과 저장 위치 - 기존 파일 덮어쓰기 여부 - 실패 시 중단 조건 - 결과의 정상 여부를 판단하는 검증 기준 - 이 과정에서 반복 업무가 다음과 같은 업무 단위로 분해됐다. - 입력 - 처리 단계 - 출력 - 예외 상황 - 검증 조건 - 자동화의 핵심은 명령어를 아는 것이 아니라, 한 단계가 완료되었다고 판단할 기준과 입력·출력 형식을 정의하는 데 있다. ## 회의록 스킬과 반복 판단의 축적 - 매주 반복되는 회의록 작성 과정에서 일정한 수정 패턴이 발견됐다. - 글쓴이는 Codex와 Claude의 `skill`을 만들어 회의 유형별 규칙을 저장했다. - 회의록의 출력 형식 - 결정사항과 액션 아이템 추출 방식 - PMO 관점에서 확인할 신호 - AI가 독단적으로 결론 내리지 않고 사용자에게 질문해야 하는 경우 - 스킬은 단순한 프롬프트 모음이 아니라 반복되는 판단 기준과 업무 규칙을 저장하는 장치였다. - AI가 초안을 작성하면 최종본과 비교해 개선점을 찾고, 그 결과를 다시 스킬에 반영하는 순환 구조를 만들었다. - 내부 데이터를 정리하다가 대화 기록을 잃어버린 사례도 있었다. - 스킬 파일은 남았지만 대화에 포함된 맥락이 사라져 성능이 일시적으로 저하됐다. - 반복 업무에서는 규칙뿐 아니라 맥락과 사례를 보존하는 것도 중요하다는 점을 보여준다. ## MCP와 스킬을 이용한 GA 리포트 자동화 - 기존에는 구글 애널리틱스(GA) 데이터를 확인하고 여러 대시보드를 만들어 인사이트를 도출하는 과정이 번거로웠다. - GA MCP를 통해 API로 데이터를 가져오고, 스킬로 월간 리포트 형식을 유지했다. - 지난달과 이번 달의 차이를 비교해 변화가 의미 있는지 판단하는 방식으로 리포트가 개선됐다. - MCP는 데이터를 가져오는 통로이고, 스킬은 반복되는 리포트 구조를 유지하는 장치다. - 중요한 것은 단순히 숫자를 요약하는 것이 아니라 다음을 판단하는 것이다. - 어떤 변화가 발생했는가 - 그 변화가 설명할 가치가 있는가 - 추가 조사가 필요한 신호인가 - AI의 분석 결과에 사용자의 업무 맥락을 결합하면 이전에는 발견하기 어려웠던 변화를 준실시간으로 탐지할 수 있다. ## 개발의 경계가 넓어지는 방식 - 변화의 본질은 AI 도구의 개수가 늘어난 것이 아니라, 기존 업무를 다른 구조로 바라보게 된 데 있다. - AI가 만든 결과물 자체보다 AI가 수행할 수 있도록 업무를 설명하는 방식이 중요해졌다. - 앞으로 더 많은 사람이 다음 요소를 일상적으로 고민하게 될 것으로 전망한다. - 입력과 출력 - 권한과 보안 - 반복 작업과 파이프라인 - 완료 조건과 검증 방법 - 이는 모든 사람이 전통적인 개발자가 된다는 뜻은 아니다. - 다만 비개발자의 업무도 점차 쪼개지고, 자동화되고, 실행 가능한 형태로 재정의될 수 있다. AI 에이전트를 효과적으로 활용하려면 “무엇을 만들어 달라”보다 “입력은 무엇이고, 결과는 어떤 형식이어야 하며, 실패와 보안 문제를 어떻게 처리할지”를 구체적으로 정의하는 것이 좋다. 반복되는 수정과 판단을 스킬이나 문서로 축적하고, 민감정보와 작업 맥락을 안전하게 관리하는 습관을 함께 갖추는 것이 실용적인 출발점이다.

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

AWS 주간 요약: 프리뷰로 공개된 AWS FinOps 에이전트, Bedrock의 Gemma 4, Kiro Pro Max 등 (2026년 6월 15일) | Amazon Web Services

이번 주 AWS 소식은 AI 기반 개발 방식의 생산성 향상, 비용 최적화 자동화, 차세대 인프라와 모델 출시를 중심으로 전개됐다. AWS FinOps Agent는 비용 분석과 최적화 작업을 자동화하고, Graviton5 기반 EC2 M9g는 성능과 격리 보안을 강화했다. 또한 Gemma 4와 OpenSearch MCP Apps를 통해 생성형 AI와 에이전트 기반 운영 환경이 확대되고 있다. ## AI 네이티브 개발팀의 운영 방식 - Amazon의 수백 개 엔지니어링 팀 실험 결과, 구조화된 AI 개발 방식을 적용하면 생산성이 크게 향상됐다. - 6명의 엔지니어가 30명 투입 및 12~18개월이 예상되던 Amazon Bedrock 추론 엔진을 76일 만에 재구축했다. - Amazon Stores의 구조화된 파일럿에서는 배포 속도 중앙값이 4.5배 향상됐고, 일부 팀은 10배 이상 개선됐다. - Perfect Order Experience는 기능 출시 주기가 2주에서 반나절로 단축됐으며, WW Grocery는 설계 문서 작성 시간을 5일에서 몇 시간으로 줄였다. - 프런티어 팀을 위한 주요 실천법은 다음과 같다. - 코딩 규칙, 에이전트 지침, 구조화된 저장소 등 에이전트 컨텍스트를 먼저 구축한다. - 초기에는 생산성이 떨어질 수 있지만 새로운 워크플로가 정착될 때까지 지속한다. - 에이전트가 병렬로 처리할 수 있도록 범위가 명확한 작업 백로그를 유지한다. - 코드 생성 전에 명세와 의도를 구체적으로 정의한다. - 테스트를 개발 초기 단계로 앞당겨 에이전트가 스스로 오류를 수정하도록 한다. - 단순한 커밋 수만으로 생산성을 판단해서는 안 되며, 향후 릴리스 관리·운영·보안·EOL 업그레이드에 대한 후속 내용이 예고됐다. ## AWS FinOps Agent 기반 비용 최적화 - AWS FinOps Agent가 프리뷰로 공개됐다. - AWS 비용에 관한 질의에 답하고, 비용 보고서를 생성하며, 최적화 기회를 탐색한다. - Cost Optimization Hub와 Compute Optimizer를 활용해 다음 항목을 추천한다. - 리소스 라이트사이징 - 유휴 리소스 제거 - Savings Plans 도입 - 추천 결과를 바탕으로 Jira 티켓을 자동 생성할 수 있다. - 비용 이상 징후가 발견되면 원인을 자동 조사하고 결과를 Slack 채널에 게시할 수 있다. - 정기적인 FinOps 작업을 일정에 따라 실행할 수 있어 재무팀과 엔지니어링팀의 비용 관리 자동화에 적합하다. ## EC2 M9g·M9gd와 Graviton5 - EC2 M9g와 M9gd 인스턴스가 정식 출시됐다. - AWS Graviton5와 6세대 Nitro System을 기반으로 한다. - Graviton4 대비 최대 성능 향상: - 일반 컴퓨팅: 최대 25% - 웹 애플리케이션: 최대 35% - 머신러닝 추론: 최대 35% - 데이터베이스: 최대 30% - Graviton5는 AWS 프로세서 최초로 PCIe Gen6와 DDR5-8800 메모리를 지원한다. - 이전 세대보다 L3 캐시가 5배 커졌다. - M8g 대비 평균 네트워크 대역폭은 최대 15%, EBS 대역폭은 최대 20% 향상됐다. - Nitro Isolation Engine은 형식 검증을 활용해 가상 머신 간 격리를 수학적으로 증명한다. - M9gd는 최대 11.4TB의 NVMe SSD 로컬 스토리지와 M8gd 대비 30% 높은 IOPS를 제공한다. - Instance Bandwidth Configuration을 사용하면 EBS와 VPC 네트워크 간 대역폭 배분을 최대 25%까지 조정할 수 있다. ## Bedrock 모델 업데이트와 접근 제한 - Google DeepMind의 Gemma 4 제품군이 Amazon Bedrock에 추가됐다. - 제공 모델은 다음과 같다. - Gemma 4 31B: 256K 토큰 컨텍스트를 지원하며 추론·코딩에 적합 - Gemma 4 26B-A4B: MoE 구조로 비용과 지연 시간에 민감한 작업에 적합 - Gemma 4 E2B: 저지연 대화형 사용 사례를 위한 소형 모델 - 세 모델 모두 함수 호출, 구조화된 출력, 추론, 스트리밍 응답을 지원한다. - 텍스트·이미지·비디오·오디오 입력과 35개 이상의 언어를 지원한다. - Claude Fable 5는 비동기 장기 작업, 다이어그램·차트·PDF 비전 처리, 자체 검증 기능을 제공했다. - 다만 6월 12일 Anthropic이 미국 정부 수출통제 지침 준수를 위해 Claude Fable 5와 Claude Mythos 5의 접근 권한 철회를 AWS에 요청했다. - 해당 모델 사용에는 Data Retention API를 통한 데이터 공유 동의가 필요했으며, Mythos 계열은 입력·출력을 30일간 보관해야 했다. ## OpenSearch MCP Apps와 에이전트형 옵저버빌리티 - Amazon OpenSearch Service가 MCP Apps를 지원한다. - Claude Desktop, VS Code 등 호환되는 에이전트형 IDE에서 OpenSearch 기반 운영 데이터를 직접 조사할 수 있다. - 에이전트는 로그, 트레이스, 메트릭, 알림과 Amazon Managed Service for Prometheus 데이터를 활용해 장애를 분석한다. - 각 MCP 도구 호출은 두 가지 결과를 반환한다. - 에이전트 추론을 위한 텍스트 요약 - 대화 화면에 표시되는 인터랙티브 시각화 - 제공되는 분석 기능에는 로그·메트릭·트레이스 조사, 서비스 성능, 토폴로지, 동적 시각화, 에이전트 상태, 클러스터 상태, 계측 점수 등이 포함된다. ## AWS CLI와 자격 증명 관리 - AWS CLI v1이 유지보수 모드에 들어간다. - botocore와 s3transfer가 별도 패키지가 아니라 CLI v1 코드에 직접 포함된다. - 따라서 CLI v1 업그레이드가 독립적으로 설치된 해당 패키지 버전을 갱신하지 않는다. - CLI v1의 신규 릴리스는 치명적 버그와 보안 문제 수정에 한정된다. - AWS는 AWS CLI v2로의 마이그레이션을 권장한다. - AWS Workload Credentials Provider도 공개됐다. - AWS 외부 또는 온프레미스에서 실행되는 애플리케이션이 장기 액세스 키 없이 단기 자격 증명을 발급받을 수 있다. - 이를 통해 워크로드별 최소 권한 원칙과 자격 증명 보안을 강화할 수 있다. ## Kiro Pro Max - Kiro에 Pro Max 요금제가 추가됐다. - 더 높은 사용량 한도, 최신 프런티어 모델 접근 권한, 추가 에이전트 기능을 제공한다. - 지속적으로 AI 개발 기능을 사용하는 전문 개발팀을 주요 대상으로 한다. - 원문은 이 항목에서 일부가 잘려 있어 세부 기능과 가격 정보는 확인할 수 없다. 이번 발표들은 AWS가 단순한 클라우드 인프라 제공을 넘어, 비용 관리·소프트웨어 개발·운영 관측성까지 에이전트가 자동화하는 방향으로 확장하고 있음을 보여준다. 실무에서는 AWS CLI v2 마이그레이션을 우선 검토하고, FinOps Agent와 MCP Apps는 권한·데이터 보존·운영 자동화 범위를 점검한 뒤 제한된 환경에서 도입하는 것이 적절하다.

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

비밀 스캔의 신뢰성 향상: 대규모 환경에서 오탐 줄이기

Mariko는 Microsoft의 Principal Applied Scientist로서 사이버보안 운영을 위한 에이전트형 AI 워크플로 개발을 이끌고 있습니다. 특히 LLM 기반 시스템과 에이전트 워크플로를 연구하며, 최신 AI 연구를 실제 제품과 운영 환경에 적용하는 데 집중합니다. ### Microsoft에서의 역할 - Microsoft의 Principal Applied Scientist로 활동 - 사이버보안 운영을 위한 에이전트형 AI 워크플로 개발 주도 - AI를 실제 보안 업무와 운영 프로세스에 통합하는 역할 수행 ### 주요 연구 관심사 - LLM 기반 시스템 - 여러 단계의 작업을 자율적으로 수행하는 에이전트형 워크플로 - 최신 AI 연구를 현실적인 제품과 운영 환경에 적용하는 방법 ### 실무적 의미 - AI 에이전트가 사이버보안 운영을 자동화하거나 지원할 가능성을 보여줌 - 연구 성과를 실제 제품과 보안 업무에 연결하는 응용 중심의 접근을 강조함

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

Stripe Projects, 새로운 에이전트 통합·더 많은 제공업체·맞춤형 개발자 제어 기능 추가

에이전트 트래픽이 처음으로 인간 트래픽을 넘어섰으며, 그 주요 원인은 에이전트가 직접 소프트웨어를 구축하기 시작했기 때문이다. Stripe는 에이전트가 코드 작성과 API 연동은 수행할 수 있지만, 인프라 프로비저닝·자격 증명 관리·서비스 연결 같은 주변 작업에는 여전히 제약이 있다고 분석한다. 이에 Stripe Projects를 확장해 에이전트가 인프라를 안전하게 구축·관리할 수 있도록 지원한다. ## 에이전트 중심의 개발 환경 확대 - 2025년 Stripe 문서에 대한 에이전트 트래픽은 10배 이상 증가했다. - 현재 Stripe 문서 트래픽의 약 40%가 에이전트에서 발생한다. - Stripe CLI의 신규 사용자도 급증했으며, API 리소스 관련 CLI 요청의 약 70%를 에이전트가 생성한다. - 에이전트는 독립적으로 코드를 작성하고 Stripe 같은 API와 통합할 수 있는 수준에 도달했다. - 반면 인프라 생성, 계정 설정, 인증 정보 관리, 여러 서비스 연결은 여전히 에이전트가 수행하기 어려운 영역이다. ## Hermes·Factory Droids·Warp와의 통합 - Stripe Projects가 Hermes의 “스킬”로 제공된다. - 스킬은 에이전트가 작업을 수행하는 데 필요한 구조화된 지침과 맥락이다. - Hermes는 세션 간 맥락을 유지하므로, 며칠 또는 몇 주에 걸친 복잡한 프로젝트에서도 지속적인 협업이 가능하다. - Factory Droids와 Warp 같은 모델 독립적인 코딩 에이전트도 Projects와 통합됐다. - 개발자는 자신이 선호하는 에이전트 환경에서 Projects CLI를 직접 사용할 수 있다. - 에이전트가 코드 작성뿐 아니라 인프라 프로비저닝과 관리까지 하나의 흐름에서 처리할 수 있다. ## 49개 프로바이더를 통한 인프라 구축 - Stripe Projects는 기존 연결 대상에 16개 프로바이더를 추가해 총 49개 프로바이더를 지원한다. - 주요 추가 서비스는 다음과 같다. - **Metronome**: 사용량 기반 과금 - **Wix**: 외부 공개용 스토어프론트 - **ClickHouse**: LLM 관측성 - 에이전트는 대시보드에서 사람이 직접 설정하지 않아도 다음 과정을 자동화할 수 있다. - 실행 가능한 AI 제품 구축 - 사용자 결제 기능 연결 - 모델 비용·지연 시간·품질 모니터링 - 첫 API 호출부터 과금과 관측성을 포함한 운영 환경을 구성할 수 있다는 점이 핵심이다. ## 프로젝트 비용 통합 관리 - 여러 프로바이더의 현재 비용과 과거 비용을 프로젝트 단위로 한곳에서 확인할 수 있다. - 특정 프로젝트가 실제로 운영되는 데 얼마가 드는지 파악할 수 있다. - 에이전트가 여러 서비스를 자동으로 생성하더라도 전체 비용을 추적하기 쉬워진다. ## 프로바이더별 지출 한도 - 서비스마다 서로 다른 지출 상한을 설정할 수 있다. - 예를 들어: - AI 모델 프로바이더에는 낮은 한도 설정 - 프로덕션 호스팅과 데이터베이스에는 상대적으로 높은 한도 설정 - 특정 프로바이더에서 에이전트가 오류나 잘못된 판단으로 예산 전체를 소진하는 위험을 줄인다. - 에이전트의 인프라 작업에도 구매 에이전트와 유사한 비용 통제가 필요하다는 점을 강조한다. ## 이름이 지정된 환경으로 운영 격리 - 개발, 스테이징, 프로덕션 또는 사용자 정의 환경별로 격리된 자격 증명을 만들 수 있다. - 필요할 경우 환경 간 리소스를 공유해 설정의 일관성을 유지할 수 있다. - 에이전트는 기본적으로 개발 환경에서 작업한다. - 에이전트가 예상과 다르게 동작하더라도 프로덕션 리소스에 접근하거나 영향을 주는 것을 방지한다. ## 플랫폼을 통한 서비스 위임 프로비저닝 - 플랫폼은 위임된 권한과 화이트라벨링을 활용해 사용자를 대신해 인프라를 생성할 수 있다. - 플랫폼이 범위가 제한된 자격 증명을 발급하고 필요한 서비스를 자동으로 설정한다. - 개발자는 별도의 대시보드로 이동하지 않고도 자신의 플랫폼 안에서 코드 작성부터 실행까지 진행할 수 있다. ## 향후 계획 - Stripe는 에이전트가 만든 소프트웨어의 전체 생명주기를 Projects에서 지원할 계획이다. - 최초 인프라 생성 - 지속적인 운영 - 보안 관리 - 자율적으로 동작하는 에이전트를 위한 보안 기능을 강화할 예정이다. - 프로바이더가 자신들의 서비스를 기반으로 구축된 에이전트 소프트웨어를 측정하고 과금할 수 있도록 데이터 계층도 추가할 계획이다. 에이전트를 실제 개발에 활용하려면 코드 생성 능력뿐 아니라 비용 한도, 환경 격리, 범위가 제한된 인증 정보를 함께 설계해야 한다. Stripe Projects는 이러한 통제 장치를 갖춘 상태에서 에이전트가 데이터베이스·결제·호스팅·관측성까지 자동으로 구성하도록 만드는 방향으로 확장되고 있다.

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

에이전트 기반 테스트: E2E 테스트 스택에서 에이전트가 적합한 위치

에이전트 기반 E2E 테스트는 기존의 결정적 테스트를 대체하기보다, 사용자의 목표 달성 여부를 탐색적으로 검증하는 별도의 계층으로 활용해야 한다. 200회 이상 실험한 결과 Playwright MCP 기반 에이전트가 복잡한 흐름에서도 가장 안정적이었고, 생성된 Playwright 테스트는 단순한 흐름에서는 빠르지만 복잡도가 높아질수록 실패율이 크게 증가했다. 따라서 전통적 테스트는 핵심 회귀 검증에, 에이전트 테스트는 유연한 탐색과 목표 중심 검증에 배치하는 것이 적절하다. ## 여정 검증에서 목표 검증으로 - 전통적인 E2E 테스트는 `클릭 → 클릭 → 입력 → 검증`처럼 미리 정해진 UI 경로를 검증한다. - 에이전트 기반 테스트는 “스레드 메시지를 보내라”처럼 목표를 제시하고, 에이전트가 현재 UI 상태에 따라 경로를 선택하게 한다. - 동일한 결과에 도달하더라도 다음과 같은 차이가 발생했다. - 검색 제안 클릭 또는 Enter 키 사용 - 검색 화면을 다시 열거나 기존 상태 재사용 - 중간 클릭, 스냅샷 확인 등의 추가·생략 - 에이전트는 중간 단계도 검증할 수 있지만, 경로의 유연성 때문에 실행 시간·비용·신뢰성 관리가 필요하다. ## 실험 구성과 비교 대상 - 200회 이상의 자동 실행으로 신뢰성, 속도, 비용을 비교했다. - 비교한 실행 방식은 세 가지다. - **에이전트 + Playwright MCP**: 브라우저 액션과 DOM 상태·로그를 지속적인 컨텍스트로 사용 - **에이전트 + Playwright CLI**: 셸에서 명령을 한 단계씩 실행하고 매번 UI 상태를 바탕으로 다음 행동 결정 - **생성된 Playwright 테스트**: 자연어 설명으로 결정적 테스트 코드를 생성한 뒤 실행·수정 - Claude Sonnet 4.5와 Opus 4.6을 사용했으며, 비운영 데이터가 있는 테스트 워크스페이스에서 실행했다. - 입력 형식은 다음 두 가지였다. - 자연어 지시: 사람이 읽기 쉬운 단계별 설명 - 구조화된 YAML: 단계, 액션, 대상, 기대 결과를 명시 - 각 설정은 20회씩 실행했다. ## 테스트한 사용자 흐름 - **Thread Reply** - 약 15~20단계의 단순한 흐름 - 채널 생성, 메시지 전송, 스레드 답글 작성, 스레드 상태 확인 - **Search Discovery** - 약 25~30단계의 중간 복잡도 흐름 - 검색어 입력, 검색 결과 탐색, 채널·스레드·검색 화면 간 이동, 결과 검증 ## 측정 결과 | 방식 | Thread Reply 실패율 | Search Discovery 실패율 | 평균 실행 시간 | |---|---:|---:|---:| | 에이전트 + Playwright MCP | 0% | 약 12% | 약 5~8분 | | 에이전트 + Playwright CLI | 약 12% | 약 20% | 약 9~11분 | | 생성된 Playwright 테스트 | 약 8% | 약 48% | 약 3분 | - 에이전트 테스트는 실행당 15~30달러가 들고 10분 이상 걸릴 수 있어, 일반적인 빠른 회귀 테스트를 그대로 대체하기에는 부담이 있다. - 그러나 전통적 테스트와 목적이 다르므로 단순한 실패율만으로 비교해서는 안 된다. ## 복잡도가 높아질수록 벌어지는 신뢰성 차이 - Playwright MCP는 단순한 시나리오에서 거의 실패하지 않았고, 복잡한 흐름에서도 실패율이 0~12% 수준이었다. - Playwright CLI는 인증 처리, 탐색 타이밍, 세션 불안정 등 실행 환경 문제로 약 12~20%의 실패율을 보였다. - 생성된 Playwright 테스트는 단순한 흐름에서는 약 8% 실패했지만, 복잡한 검색 흐름에서는 약 48%까지 악화됐다. - 생성 테스트는 대체로 전체 흐름의 70~80%까지 진행한 뒤 마지막 상호작용이나 assertion에서 실패했다. - 주요 원인은 다음과 같다. - UI 상태의 변동성 - 자연어 명세와 실제 요소 선택 간의 추상화 불일치 - 기존 Page Object 추상화가 복잡한 상황에서 정확한 요소 지정을 방해 - MCP는 애플리케이션의 실시간 상태를 안정적으로 유지하는 반면, CLI는 단계마다 스냅샷을 다시 구성한다. - 긴 흐름에서는 상태 해석과 타이밍의 작은 차이가 누적되어 CLI 방식의 실패 가능성이 커질 수 있다. ## 테스트 스택에서의 적절한 역할 - 전통적인 결정적 Playwright 테스트는 빠르고 반복 가능하므로 핵심 회귀 테스트와 CI의 기본 검증에 적합하다. - 에이전트 기반 테스트는 특정 클릭 순서가 아니라 “사용자가 목표를 달성할 수 있는가”를 검증하는 데 적합하다. - 특히 다음 영역에서 활용 가치가 있다. - 다양한 UI 경로를 허용해야 하는 사용자 여정 - 사전에 모든 경로를 코드로 작성하기 어려운 탐색적 테스트 - 복잡한 화면 상태와 실제 사용자 행동에 가까운 검증 - 에이전트 방식 중에서는 실시간 브라우저 컨텍스트를 유지하는 Playwright MCP가 복잡한 시나리오에 더 적합한 것으로 나타났다. - 다만 높은 비용과 긴 실행 시간을 고려해 모든 커밋에서 실행하기보다는, 야간 테스트나 릴리스 전 검증 등 별도 계층에 배치하는 것이 현실적이다. 에이전트 기반 E2E 테스트는 결정적 테스트의 대체재가 아니라 보완재로 도입하는 것이 좋다. 빠르고 안정적인 핵심 회귀 검증은 기존 Playwright 테스트로 유지하고, MCP 기반 에이전트 테스트를 목표 중심·탐색적 검증에 제한적으로 추가하는 구성이 가장 실용적이다.

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

이제 사용 가능: 새로운 AWS Graviton5 프로세서로 구동되는 Amazon EC2 M9g 및 M9gd 인스턴스 | Amazon Web Services

AWS가 자체 설계한 Graviton5 프로세서 기반 EC2 M9g와 M9gd 인스턴스를 정식 출시했다. Graviton4 대비 최대 25% 높은 컴퓨팅 성능, 더 큰 캐시와 높은 메모리·네트워크·스토리지 대역폭을 제공하며, M9gd는 최대 11.4TB의 로컬 NVMe SSD를 추가한다. 특히 에이전트형 AI, 데이터베이스, 웹 애플리케이션처럼 CPU와 I/O를 동시에 많이 사용하는 워크로드의 성능과 에너지 효율 향상을 목표로 한다. ## Graviton5의 성능 및 설계 개선 - Graviton5는 AWS의 다섯 번째 자체 설계 Arm 프로세서다. - 최대 192개의 코어를 제공하며, 이전 세대보다 L3 캐시가 5배 커졌다. - 코어 간 지연 시간은 최대 33% 감소해 병렬 처리와 다수의 동시 작업에 유리하다. - DDR5-8800 메모리와 PCIe Gen6를 지원해 AWS 인스턴스 중 가장 빠른 메모리 성능을 제공한다. - Graviton4 대비 성능 향상 폭은 다음과 같다. - 전체 컴퓨팅 성능: 최대 25% - 웹 애플리케이션: 최대 35% - 머신러닝 추론: 최대 35% - 데이터베이스: 최대 30% - 성능 향상과 함께 에너지 효율도 개선해 비용 및 지속 가능성 목표 달성에 도움을 준다. ## 에이전트형 AI와 CPU 수요 대응 - AI가 단순 질의응답을 넘어 코드 실행, 도구 호출, 결과 평가, 다단계 작업 조율을 수행하면서 CPU 처리량의 중요성이 커지고 있다. - Graviton5는 다음 특성으로 에이전트형 AI에 적합하다. - 높은 코어 수로 다수의 실행 환경을 동시에 처리 - 대형 L3 캐시로 CPU 대기 시간 감소 - 높은 메모리 대역폭으로 데이터 처리량 향상 - 가속기가 CPU 작업을 기다리는 시간을 단축 - Meta는 실시간 추론, 코드 생성, 다단계 작업 조율을 위해 수천만 개 규모의 Graviton 코어를 배포할 계획이라고 밝혔다. - Honeycomb은 6개월간의 실제 운영 A/B 테스트에서 Graviton4 대비 코어당 처리량이 36% 향상됐다고 보고했다. ## M9g와 M9gd의 차이 ### M9g: 범용 컴퓨팅 중심 - vCPU 1개당 4GiB 메모리를 제공한다. - 다음과 같은 범용 워크로드에 적합하다. - 애플리케이션 서버와 마이크로서비스 - 중간 규모 데이터 저장소 - 게임 서버와 캐시 클러스터 - 컨테이너 애플리케이션 - 대규모 Java 애플리케이션 - 코드 저장소와 웹 애플리케이션 - 에이전트형 AI ### M9gd: 로컬 NVMe 스토리지 추가 - 최대 11.4TB의 로컬 NVMe SSD를 제공한다. - Graviton4 기반 M8gd보다 IOPS 및 스토리지 성능이 30% 향상됐다. - 낮은 지연 시간의 임시 또는 로컬 스토리지가 필요한 작업에 적합하다. - 캐시와 스크래치 파일 - 데이터 로깅 - 미디어 처리 - 배치 및 로그 처리 - 키-값 데이터 저장소 - 게임 서버와 마이크로서비스 - 컴퓨팅, 메모리, 네트워크, EBS 대역폭 사양은 동일한 크기의 M9g와 같다. ## 네트워크와 스토리지 대역폭 개선 - M9g와 M9gd는 이전 세대 대비 평균적으로 다음 대역폭을 제공한다. - 네트워크 대역폭: 최대 15% 증가 - EBS 대역폭: 최대 20% 증가 - 가장 큰 인스턴스 크기: 네트워크 대역폭 최대 2배 - Instance Bandwidth Configuration(IBC)을 지원한다. - EBS와 VPC 네트워크 사이의 대역폭 할당을 최대 25% 조정할 수 있다. - 데이터베이스 읽기·쓰기, 쿼리 처리, 로깅처럼 특정 I/O 비중이 큰 워크로드에 유용하다. - 컴퓨팅 성능 증가에 맞춰 데이터 이동과 저장장치 처리량도 함께 확장한 것이 특징이다. ## Nitro Isolation Engine을 통한 보안 강화 - M9g와 M9gd는 6세대 AWS Nitro System을 기반으로 한다. - 새롭게 도입된 Nitro Isolation Engine은 가상 머신 간 격리를 담당한다. - 메모리, CPU 레지스터 상태, I/O 장치 접근을 최소한의 API를 통해 제어한다. - 정형 검증(formal verification)을 사용해 특정 테스트 사례가 아니라 수학적으로 격리 동작을 검증한다. - AWS는 이를 통해 Nitro를 공식적으로 검증된 클라우드 하이퍼바이저로 발전시키고, 가상 머신 간 보안 격리에 대한 신뢰성을 높였다고 설명한다. ## 실제 고객 성과 - ClickHouse: 코드 변경 없이 M8g 대비 성능 36% 향상 - Honeycomb: Graviton4 대비 코어당 처리량 36% 향상 - HubSpot: MySQL 쿼리 수행 시간이 최대 60% 감소 - 이러한 사례는 데이터베이스, 분석, 관측성 등 다양한 운영 환경에서의 효과를 보여준다. ## 출시 지역과 구매 방식 - 현재 제공 지역: - 미국 동부 버지니아 - 미국 동부 오하이오 - 미국 서부 오리건 - 유럽 프랑크푸르트 - 구매 방식: - Savings Plans - On-Demand - Spot Instances - Dedicated Instances - Dedicated Hosts 기존 Arm 호환 애플리케이션이라면 M9g부터 성능을 검증하고, 로컬 SSD가 필요하면 M9gd를 선택하는 것이 적절하다. x86 기반 Java 애플리케이션은 AWS Transform을 활용해 호환성 분석, 재컴파일, 의존성 수정, 검증 과정을 자동화할 수 있으며, 도입 전에는 Graviton Savings Dashboard로 비용 절감 효과를 비교하는 것이 좋다.

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

GitLab Orbit 소개

GitLab Orbit은 코드뿐 아니라 머지 리퀘스트, 파이프라인, 배포, 취약점, 소유권까지 연결한 실시간 그래프를 제공해 AI 에이전트가 시스템 전체 맥락을 한 번에 이해하도록 하는 서비스다. 이를 통해 에이전트는 파일을 반복 탐색하는 대신 관계형 질의를 수행하며, 최대 11배 빠르고 토큰 사용량은 4.5배 적어질 수 있다. GitLab은 Orbit이 코드 리뷰와 장애 대응, 보안, 마이그레이션처럼 여러 시스템을 함께 봐야 하는 작업의 정확성과 처리 속도를 높인다고 설명한다. ## 기존 AI 코딩 에이전트의 한계 - AI 에이전트는 코드 작성에는 강하지만 다음 정보를 찾는 데는 취약하다. - 관련 코드와 의존성 - 해당 코드를 실행하는 테스트와 파이프라인 - 실제 배포 환경 - 변경을 요청한 작업 항목 - 관련 팀과 담당자 - 대규모 모노레포에서는 에이전트가 파일을 탐색하는 데 토큰과 시간을 많이 사용한다. - 저장소가 여러 개로 나뉘면 컨텍스트가 부족해져 의존성을 놓치거나, 코드가 겉보기에는 맞지만 실제로는 되돌려지는 결과를 만들 수 있다. - 단순한 검색이나 RAG 방식만으로는 코드와 개발 lifecycle 데이터 사이의 관계를 충분히 복원하기 어렵다. ## 실제 머지 리퀘스트에서의 검증 - 영국 가격 비교 플랫폼 Compare the Market은 79개의 실제 머지 리퀘스트를 대상으로 AI 코드 리뷰의 컨텍스트 검색 방식을 비교했다. - Orbit을 사용한 리뷰어의 정확한 인라인 댓글 비율은 약 70%였다. - RAG 방식은 약 58%에 그쳤다. - 변경 사항 요약에서 핵심 변경을 포착한 비율도 Orbit이 68%, RAG가 66%였다. - RAG는 컨텍스트를 사용하지 않은 방식보다도 낮은 성능을 보였다. - 테스트 결과 Orbit은 단순히 현재 diff를 읽는 것이 아니라 코드베이스의 구조와 변경의 주변 영향을 이해하는 데 효과적이었다. ## 코딩 에이전트의 탐색 비용 감소 - Claude Code 같은 외부 에이전트를 MCP(Model Context Protocol)로 Orbit에 연결할 수 있다. - 에이전트는 다음 질문을 파일을 반복해서 읽으며 추론하지 않고 그래프에 직접 질의한다. - 특정 코드가 어디에 있는가? - 어떤 코드가 이를 의존하는가? - 어떤 테스트와 파이프라인이 이를 검증하는가? - 같은 모델과 같은 작업을 비교했을 때 다음과 같은 개선이 제시됐다. - 최대 11배 빠른 작업 수행 - 최대 4.5배 적은 토큰 사용 - 최대 45배 적은 환각 생성 - 결과적으로 에이전트가 실제 구현 작업을 시작하기 전에 소모하는 탐색 시간이 줄어든다. ## 파이프라인 장애의 전체 영향 추적 - 기존 에이전트는 실패한 파이프라인의 개별 job만 보고 원인을 고립된 문제로 판단하기 쉽다. - Orbit은 실패한 job에서 관련 파이프라인, 머지 리퀘스트, 프로젝트까지 연결해 추적한다. - 예시 질의는 실패한 CI job과 연결된 최근 머지 리퀘스트를 프로젝트별로 조회한다. ```cypher MATCH (job:CiJob {status: "failed", name: $job_name}) -[:RAN_IN]->(pipeline)-[:FOR]->(mr:MergeRequest) RETURN mr.title, mr.author, pipeline.started_at, mr.project_id ORDER BY pipeline.started_at DESC LIMIT 20 ``` - 이 방식으로 여러 프로젝트에서 동일한 장애를 만날 진행 중인 MR을 한 번에 찾을 수 있다. - 여러 팀이 같은 원인을 따로 해결하는 대신, 한 번의 대응으로 문제를 확산시키는 변경까지 파악할 수 있다. ## 취약점의 영향 범위와 담당자 파악 - 취약한 코드 자체를 찾는 것보다, 해당 코드가 시스템 어디까지 퍼졌는지를 확인하는 일이 더 어렵다. - Orbit은 다음 정보를 연결해 보여준다. - 취약한 컴포넌트를 포함한 서비스 - 해당 서비스를 빌드하는 파이프라인 - 실행되는 환경 - 각 구성 요소의 소유 팀 - 보안팀은 CVE가 공개된 직후 영향을 받는 구성 요소와 담당자를 포함한 remediation 계획을 만들 수 있다. - 수작업으로 여러 도구를 조사하는 데 걸리던 시간을 줄여 대응 속도를 높이는 것이 목표다. ## 조직 전반의 질의와 마이그레이션 계획 - Orbit은 고정된 대시보드에 없는 복합적인 질문에도 활용된다. - 예를 들어 팀별 cycle time을 파이프라인 실패율, 배포 빈도와 결합해 조회할 수 있다. - 공용 컴포넌트 마이그레이션에서는 다음 의존성을 한 번에 확인할 수 있다. - 종속 서비스 - 관련 job - 배포 환경 - 담당 소유자 - 숨은 downstream 의존성을 놓쳐 일정이 지연되는 위험을 줄이고, 마이그레이션 범위와 책임자를 구체화할 수 있다. ## Orbit의 기술 구조 - 소프트웨어 개발 lifecycle 데이터를 CDC(Change Data Capture) 방식으로 수집해 ClickHouse에 저장한다. - Rails 내부 API를 통해 12개 언어의 코드를 분석한다. - Ruby, Java, Kotlin, Python, TypeScript, JavaScript - Rust, Go, C#, C, C++, PHP - Cypher와 유사한 DSL, MCP, REST, GitLab CLI를 통해 그래프를 조회한다. - GitLab 자체 환경에서는 4만 개 이상의 프로젝트, 5억 개 노드, 20억 개 엣지를 45분 이내에 인덱싱한다고 설명한다. - 이벤트 기반 엔진이 변경 사항을 즉시 반영해 그래프를 최신 상태로 유지한다. - 인덱싱은 별도 서비스에서 수행되므로 쿼리 트래픽이 GitLab 인스턴스에 직접 부담을 주지 않는다. - GitLab 권한을 그대로 반영하므로 에이전트는 사용자가 UI에서 볼 수 있는 데이터만 조회한다. - 쿼리는 데이터베이스에 실행되기 전에 검증, 실행 계획 수립, 최적화, 보안 검사를 거친다. ## 다양한 사용 방식과 Data Explorer - GitLab Duo Agent Platform의 에이전트는 Orbit을 기본적으로 질의할 수 있다. - Claude Code, Codex, OpenCode 같은 외부 에이전트는 MCP와 GitLab CLI를 통해 연결한다. - 사내 도구나 맞춤형 에이전트는 REST API를 사용할 수 있다. - Data Explorer에서는 에이전트 없이 엔지니어가 같은 그래프를 직접 조회한다. - 장애 조사, 의존성 전파 추적, 반복적인 CI 실패 원인 분석처럼 정해진 프롬프트에 맞지 않는 작업에도 활용할 수 있다. Orbit은 코드 검색 도구라기보다 코드와 개발 lifecycle 전체를 연결하는 지식 그래프에 가깝다. 여러 저장소와 시스템에 걸친 의존성, 장애 영향, 보안 노출, 소유권을 자주 추적해야 하는 대규모 조직이라면 특히 효과가 크며, 도입 시에는 실제 MR 리뷰나 장애 대응 업무를 대상으로 기존 검색·RAG 방식과 정확도 및 비용을 비교해 검증하는 것이 좋다.

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

GitLab: 에이전틱 엔지니어링 시대를 위해 설계되다

GitLab은 AI 코딩의 속도를 늦추기보다, 에이전트가 대규모로 활동해도 통제와 보안을 유지할 수 있는 통합 인프라가 필요하다고 주장합니다. 이를 위해 에이전트 규모의 소스 코드 관리, 전체 SDLC를 이해하는 컨텍스트 그래프, 보안·거버넌스, 작업 오케스트레이션, 유연한 구매 모델을 제공하겠다고 발표했습니다. 결론적으로 GitLab은 인간과 에이전트가 동일한 플랫폼에서 계획·개발·배포·감사를 수행하는 “에이전틱 엔지니어링” 플랫폼을 지향합니다. ## AI 코딩의 확산과 관리되지 않은 혼란 - 조사 대상 1,500명 이상의 개발자와 기술 리더 중: - 조직의 91%가 AI 코딩 도구를 2개 이상 사용 - 54%는 3개 이상 사용 - 일부 고객의 코드베이스는 1년 만에 최대 5배 성장 - 그러나 기존 소프트웨어 생명주기는 인간의 작업 속도를 전제로 설계되어 에이전트 규모의 병렬 작업을 감당하기 어렵습니다. - 주요 문제: - 에이전트가 코드만 알고 전체 SDLC 맥락은 이해하지 못함 - 대규모 모노레포나 여러 저장소에서 컨텍스트가 부족해 작업이 중단됨 - 코드·의존성·배포 변경 속도가 거버넌스보다 빨라짐 - 좌석 수와 크레딧을 미리 구매해야 하는 고정형 계약이 AI 사용량 변동에 맞지 않음 - 응답자의 73%는 코드 유지보수를 걱정했으며, 전체 SDLC에서 생산성 향상을 체감한 비율은 21%에 불과했습니다. ## GitLab의 에이전틱 인프라 구조 GitLab은 소스 코드 관리, CI/CD, 거버넌스, 배포를 하나의 플랫폼에서 제공하며, 현재 5,000만 명 이상의 사용자와 10만 개 조직이 사용한다고 설명합니다. - **모터 시스템**: 소스 코드 관리, 파이프라인, 배포 등 실제 실행 담당 - **신경 시스템**: 에이전트와 개발자가 올바른 판단을 내리도록 전체 맥락 제공 - **면역 시스템**: 모든 작업에 보안과 거버넌스 적용 - **오케스트레이션 시스템**: 전체 생명주기의 작업을 계획하고 조율 - 이 네 요소는 사람이 작업하든 에이전트가 작업하든 동일하게 작동하도록 설계됩니다. ## 차세대 SCM과 에이전트 규모의 동시성 기존 Git은 수백 명의 개발자가 병렬로 작업하는 환경에는 적합하지만, 각 개발자가 수백 개의 에이전트를 실행하는 상황에서는 한계가 발생합니다. - **클론 비용**: 에이전트가 파일 하나를 읽기 위해 저장소 전체를 복제하며, 재시도마다 비용이 반복됨 - **동시성 붕괴**: 수천 개의 세션이 인간 중심으로 설계된 백엔드에 몰려 병목과 불안정성이 발생 - **격리 부족**: 에이전트가 계정과 브랜치 공간을 공유해 작업이 섞이고, 폐기나 추적이 어려움 - GitLab은 Git 프로토콜과의 호환성 및 감사 가능성은 유지하면서, 에이전트 전용 백엔드와 인터페이스를 갖춘 차세대 SCM을 비공개 베타로 공개했습니다. - 초기 내부 테스트 결과: - 토큰 사용량 최대 2배 감소 - 실제 실행 시간 최대 50배 단축 - 네트워크 트래픽 최대 1,000배 감소 ## GitLab Orbit: 전체 SDLC를 연결하는 컨텍스트 그래프 에이전트는 코드를 작성하는 능력에 비해 코드 주변의 시스템과 생명주기를 파악하는 능력이 부족합니다. 이로 인해 잘못된 작업을 반복하거나, 겉보기에는 올바르지만 나중에 되돌려야 하는 결과를 만들 수 있습니다. - **GitLab Orbit**은 코드, 작업 항목, 파이프라인, 배포, 운영 신호를 하나의 실시간 그래프로 연결합니다. - 에이전트는 분산된 정보가 아니라 GitLab의 원천 데이터를 기반으로 추론할 수 있습니다. - 개발자는 Data Explorer를 통해 동일한 그래프를 조회하고 변경 사항이나 장애 원인을 추적할 수 있습니다. - 초기 내부 테스트에서 Orbit을 사용한 에이전트는: - 응답 속도 최대 11배 향상 - 비용 효율 최대 4.5배 향상 - 환각 최대 45배 감소 - Compare the Market의 A/B 테스트에서는 그래프 기반 에이전트가 코드 리뷰 댓글의 정확한 위치를: - 70%의 확률로 지정 - RAG 방식은 58% - 이 테스트는 실제 머지 리퀘스트 79건을 대상으로 진행됐으며, 그래프 기반 컨텍스트가 일반적인 검색 기반 방식보다 높은 정확도를 보였습니다. - Orbit은 현재 공개 베타 단계입니다. ## 에이전트 보안과 거버넌스 GitLab은 에이전트가 코드와 운영 환경에 직접 영향을 미치는 상황을 고려해, 에이전트 자체를 관리하는 기능도 발표했습니다. - 에이전트의 신원과 권한을 관리 - 정책을 적용해 허용 가능한 행동 범위 제한 - 모든 에이전트 작업을 감사 로그로 추적 - 위험한 작업에 승인 절차 적용 - 에이전트용 보안 및 거버넌스 기능은 비공개 베타로 제공될 예정입니다. ## GitLab Duo Agent Platform의 오케스트레이션 - GitLab Duo Agent Platform은 에이전트가 개발자의 작업 흐름을 중단하지 않고 다음 작업을 수행하도록 조율합니다. - 이슈 처리 - 코드 리뷰 - CI/CD 파이프라인 문제 수정 - 플랫폼은 소스 코드, 컨텍스트, 보안 정책을 연결해 단순 코드 생성이 아닌 전체 개발 생명주기 자동화를 목표로 합니다. - 해당 플랫폼은 2026년 1월부터 정식 제공되고 있습니다. ## GitLab Flex와 새로운 구매 방식 - AI 도입 속도와 사용량은 조직마다 크게 달라 기존의 고정된 좌석·크레딧 계약으로 예측하기 어렵습니다. - GitLab Flex는 실제 AI 도입 방식과 사용 패턴에 맞춰 구매할 수 있는 유연한 라이선스 모델입니다. - 현재 주문을 받고 있습니다. ## 실용적인 결론 AI 코딩 도구를 도입하는 것만으로는 에이전틱 엔지니어링의 생산성을 확보하기 어렵습니다. 대규모 동시성을 처리하는 SCM, 전체 SDLC 컨텍스트, 세밀한 권한·감사·승인 체계, 작업 오케스트레이션을 함께 구축해야 하며, GitLab은 이를 하나의 통합 플랫폼으로 제공하려는 전략을 제시하고 있습니다.

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

미토스급 Claude Fable 5, GitLab Duo Agent Platform에 출시

Anthropic의 Claude Fable 5가 GitLab Duo Agent Platform에 추가되어 복잡한 작업을 장시간 자율적으로 수행하고, 첫 시도에서 더 정확한 결과를 내도록 지원한다. 멀티파일 리팩터링, 장애 분석, 인프라 코드 작성, 코드 리뷰 등에서 반복 작업과 사람의 감독 부담을 줄이는 것이 핵심이다. 이 모델은 2026년 6월 9일부터 모든 GitLab 요금제와 배포 방식에서 AI Gateway를 통해 제공된다. ## 첫 시도 정확도 향상 - 복잡하고 요구사항이 명확한 문제에서 한 번에 작동하는 구현을 완성할 가능성이 높아졌다. - GitLab Duo Agentic Chat에서 사용자와 모델 사이의 재질문·수정 횟수를 줄인다. - 특히 다음과 같은 반복 비용이 큰 작업에 효과적이다. - 여러 파일에 걸친 대규모 리팩터링 - 장애 및 인시던트 조사 - Infrastructure as Code 정의 - 기술 이미지, 웹 애플리케이션, 상세한 스크린샷을 이전 모델보다 정확하게 해석하며 더 적은 출력 토큰을 사용하는 경우도 있다. ## 장시간 자율 에이전트 실행 - Claude Fable 5의 가장 큰 변화는 장기 목표를 유지하는 자율성이다. - 수백만 토큰에 걸친 작업에서도 지시를 따르며, 여러 날 동안 진행되는 복합 작업을 수행할 수 있다. - 자체 검증 루프를 통해 오류를 찾아 수정하고, 작업이 제대로 진행되는지 확인한다. - 여러 저장소나 서비스로 나뉘는 병렬 작업에서 하위 에이전트를 안정적으로 실행하고 유지한다. - 기존에 사람이 중간 점검하거나 프롬프트를 다시 입력해야 했던 Duo 에이전트 작업을 끝까지 진행할 수 있다. - 결과적으로 팀은 에이전트 실행마다 투입해야 하는 감독 비용을 줄이고, 비동기적으로 결과를 검토할 수 있다. ## 코드 리뷰와 장애 대응 개선 - 버그 탐지 재현율이 향상되어 이전 모델이 놓치던 문제를 더 많이 발견한다. - 코드 경로를 더 깊게 분석하고, 예외 상황과 엣지 케이스를 일관되게 식별한다. - GitLab Merge Request 리뷰에서 일반적인 지적보다 실행 가능한 코드 리뷰 의견을 제공한다. - CI/CD를 운영하는 플랫폼 엔지니어에게는 다음과 같은 효과가 기대된다. - 결함이 운영 환경에 배포되기 전 발견 - 장애 원인 분석 시간 단축 - 평균 복구 시간(MTTR) 감소 - 저장소 이력과 변경 맥락을 활용한 정밀한 인시던트 조사 ## 어려운 문제에 활용하는 전략 - 단순 반복 업무만 테스트하면 모델의 장기 자율성과 문제 해결 능력을 충분히 확인하기 어렵다. - 이전 AI 모델로는 처리하기 어렵다고 판단했던 문제를 맡기는 것이 권장된다. - 에이전트가 작업 범위를 정하고, 필요한 경우 명확화 질문을 한 뒤 실행하도록 할 수 있다. - 활용 사례로는 다음이 제시된다. - 복잡한 멀티파일 리팩터링 - 저장소 이력을 포함한 운영 장애 조사 - AI가 정확히 처리할지 확신하기 어려워 직접 작성하던 기능 구현 ## 제공 범위 - Claude Fable 5는 2026년 6월 9일부터 GitLab Duo Agent Platform에서 제공된다. - 모든 GitLab 요금제와 배포 모델에서 GitLab AI Gateway를 통해 사용할 수 있다. - 무료 사용자는 Duo Agent Platform 무료 체험을 시작할 수 있다. - GitLab Premium 또는 Ultimate 가입자는 포함된 GitLab Credits를 사용해 Duo Agent Platform을 활성화할 수 있다. 실제로 도입할 때는 단순 코드 생성보다 장애 분석, 대규모 리팩터링, 복잡한 CI/CD 개선처럼 장시간 추론과 여러 단계의 검증이 필요한 업무부터 시험하는 것이 효과적이다. પરિણામ물은 비동기 검토가 가능하더라도 운영 배포 전에는 기존 코드 리뷰와 테스트 절차를 유지하는 것이 바람직하다.

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

에이전틱 AI 생태계의 주인공들, MCP Player 10 성료와 Next!

카카오의 MCP 기반 개방형 플랫폼 PlayMCP에서 열린 ‘MCP Player 10’ 공모전이 약 150개 팀의 참여 속에 마무리됐다. 수상작들은 보육 행정, 창업 지원사업, 육아, 법률, 문화생활, 게임, 보안 등 일상과 전문 영역의 문제를 AI 에이전트로 해결했다. 카카오는 PlayMCP를 개발자 중심 플랫폼으로 발전시키고, Kakao Tools 및 카카오톡과 연계해 MCP 서비스의 대중화를 추진할 계획이다. ## 60일간 진행된 MCP 공모전 - 공모전은 2025년 12월 19일부터 2026년 1월 18일까지 진행됐다. - 카카오의 MCP 기반 플랫폼 **PlayMCP**를 활용해 실용적인 MCP 서버를 개발하는 방식이었다. - 약 150개 팀이 참여했으며, 창의성·사용 편의성·기술적 안정성을 기준으로 최종 10팀을 선정했다. - 단순한 기술 시연보다 실제 생활 속 불편을 해결하고 서비스로 발전할 가능성이 중요한 평가 기준으로 소개됐다. ## 대상: 어린이집 행정을 돕는 ‘어린이ZIP’ - 현직 교사의 행정 업무 부담을 줄이는 AI 보육 조수다. - 활동 사진을 분석해 알림장과 보육일지 초안을 자동 생성한다. - 아이별 알레르기, 하원 방법 등 개별 특이사항을 기억해 맞춤형 답변을 제공한다. - 보육 현장에 적합한 따뜻한 문체와 전문가의 톤앤매너를 반영한다. - “사진으로 오늘 보육일지 작성”, “아이의 알레르기 정보 확인”과 같은 자연어 명령으로 사용할 수 있다. ## 최우수상: 창업 지원사업을 분석하는 ‘SeedUp’ - 정부 창업 지원사업 공고를 수집하고 분석하는 창업 지원 MCP다. - 여러 기관에 흩어진 공고와 첨부 파일을 한곳에서 검색·요약한다. - 지원 자격과 주요 조건을 확인하고, 지원사업별 합격 전략까지 안내한다. - 창업자가 “이번 주 주요 공고”, “AI 스타트업 관련 사업” 등을 자연어로 검색할 수 있다. ## 다양한 생활 문제를 해결한 수상작 - **공유 비밀의 방** - 익명성을 보장하는 디지털 소통 플랫폼이다. - AI와 나눈 고민이나 대화를 익명으로 공유하고 다른 사람의 이야기에 공감할 수 있다. - **바우만 16 안티에이징솔루션** - 바우만 피부 유형 16가지 분류법을 AI에 적용했다. - 화장품 성분과 피부 특성을 분석해 개인별 스킨케어 루틴과 제품을 추천한다. - **아라드도우미** - 던전앤파이터 이용자를 위한 게임 전문 AI 비서다. - RAG와 Vision AI를 활용해 패치 노트, 아이템 메타, 직업별 빌드를 분석한다. - **키즈허브** - 육아 정보와 공공데이터를 통합한 서비스다. - 응급실 현황, 성장 단계, 어린이집 대기 정보 등을 제공하고 가족 단톡방 공유도 지원한다. - **택배추적기** - 배송 조회뿐 아니라 택배 사칭 스미싱 URL도 탐지한다. - 배송 관련 문자 속 위험 링크를 분석해 개인정보와 금융 피해를 예방한다. - **ArtBridge** - 약 20만 건의 공연·전시 데이터를 활용하는 문화생활 추천 서비스다. - 위치, 예산, 취향을 바탕으로 연극·뮤지컬·클래식 등 9개 장르의 콘텐츠와 예매 정보를 추천한다. - **KidSafe** - 어린이와 청소년의 AI 대화를 보호하는 안전 MCP다. - 유해 표현과 정서적 위기 신호를 감지하고, 필요하면 보호자나 전문 상담 자원과 연결한다. - **LexiLink_ko** - 법령, 판례, 행정 해석례를 자연어로 검색하는 법률 리서치 도구다. - 복잡한 법적 쟁점을 통합 검색하고 이해하기 쉽게 정리한다. ## PlayMCP의 향후 발전 방향 - PlayMCP는 개발자가 MCP 서버를 만들고 공유하는 전문 공간으로 운영된다. - 일반 사용자가 MCP를 경험하는 공간은 카카오톡의 **Kakao Tools**가 담당하며, 두 서비스는 긴밀하게 연결될 예정이다. - 현재는 개발자가 MCP 서버의 엔드포인트와 운영을 직접 관리해야 한다. - 향후 카카오 클라우드 기반 서버 지원과 배포 자동화 등 매니지드 서비스 도입을 검토하고 있다. - 카카오톡 안에서 MCP가 JSON 기반 위젯 등 자체 UI를 렌더링하도록 지원하는 방안도 검토 중이다. ## 다음 공모전: Agentic Player 10 - 카카오는 2회 공모전인 **Agentic Player 10**을 예고했다. - 이번에는 Kakao Tools와 연계해 개발자가 만든 에이전트를 더 많은 사용자에게 직접 선보이고 검증할 기회를 제공한다. - 특히 스타트업과 예비 창업팀이 실제 사용자 접점을 확보하고 서비스 성장을 실험하는 장으로 활용할 수 있도록 설계될 예정이다. - MCP 서버가 카카오톡 안에서 대중적인 AI 에이전트로 발전하는 것이 주요 목표다. 수상작들은 MCP가 단순한 개발자용 연동 기술을 넘어, 특정 업무와 사용자 문제를 해결하는 실용적인 AI 서비스로 발전할 수 있음을 보여준다. MCP 서비스를 개발한다면 명확한 사용자 문제를 정하고, 신뢰할 수 있는 데이터와 안전장치, 자연어 기반 사용성을 함께 설계하는 것이 중요하다.

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

Anthropic 및 OpenAI 호환 API에 최적화된 Amazon Bedrock의 새로운 콘솔 환경을 사용해 보세요 | Amazon Web Services

Amazon Bedrock이 Anthropic 및 OpenAI 호환 API에 최적화된 새로운 콘솔 환경을 공개했습니다. `bedrock-mantle` 엔드포인트를 기반으로 GPT, Claude, 오픈 웨이트 모델을 쉽게 비교·평가하고, 프로젝트 단위로 사용량을 분석하며 애플리케이션 개발까지 이어갈 수 있습니다. 모델 선택부터 SDK 코드 생성, AI 코딩 에이전트 연결까지 하나의 워크플로에서 처리하는 것이 핵심입니다. ## `bedrock-mantle` 기반의 새로운 콘솔 - 최신 GPT, Claude, 오픈 웨이트 모델을 지원합니다. - 다음 API 프로토콜과 호환됩니다. - OpenAI Responses API - OpenAI Chat Completions API - Anthropic Messages API - 고성능, 안정성, 보안을 목표로 하는 차세대 추론 엔진을 사용합니다. - 기존 Bedrock 콘솔은 계속 사용할 수 있으며, Agents, Knowledge Bases, Guardrails, 파인튜닝, `InvokeModel` 및 `Converse` API는 `bedrock-runtime`에서 관리합니다. ## 모델 카탈로그와 비교 기능 - 전체 모델 카탈로그를 한 화면에서 확인할 수 있습니다. - 모델별로 다음 정보를 비교할 수 있습니다. - 지원 기능과 모달리티 - 컨텍스트 윈도우 - 토큰 및 입출력 관련 정보 - 가격 - 서비스 할당량 - 리전별 제공 여부 - 최대 3개 모델을 선택해 동일한 프롬프트의 응답을 나란히 비교할 수 있습니다. - 문서와 별도의 한도 계산기를 오갈 필요 없이 모델 평가에 필요한 정보를 통합해서 볼 수 있습니다. ## 프로젝트 기반 개발 및 평가 - 프로젝트를 생성하고 사용할 모델을 지정한 뒤 API 키를 구성할 수 있습니다. - 프로젝트 대시보드에서 다음 지표를 확인할 수 있습니다. - 최근 기간별 추론 요청 수와 오류 - 총 토큰 사용량 - 분당 토큰 사용량 - 분당 추론 요청 수 - 추론 요청당 토큰 수 - 최근 사용 모델 - 이러한 지표를 활용해 모델 선택, 프롬프트 최적화, 워크로드의 일관성을 검토할 수 있습니다. - 모델 평가에서 애플리케이션 구축까지 이어지는 실제 개발 생명주기에 맞춘 구성을 제공합니다. ## 프로젝트 변수와 연동되는 실시간 문서 - 프로젝트에서 선택한 모델 ID, 리전, `bedrock-mantle` 엔드포인트 URL, API 키 참조가 문서와 코드 예제에 자동으로 반영됩니다. - Anthropic 또는 OpenAI SDK와 원하는 프로그래밍 언어, 인증 방식을 선택할 수 있습니다. - 터미널에서 바로 실행할 환경 변수 명령과 `.env` 파일에 저장할 설정을 제공합니다. - 생성된 샘플 코드를 수정하지 않고 애플리케이션에 복사해 빠르게 첫 요청을 테스트할 수 있습니다. - 모델이나 설정을 변경하면 API 레퍼런스와 코드 예제도 프로젝트 설정에 맞게 자동 갱신됩니다. ## AI 코딩 에이전트 연결 - 다음과 같은 AI 코딩 에이전트를 Bedrock을 통해 연결할 수 있습니다. - Claude Code - Cline - Codex - Cursor - OpenCode - 각 에이전트별 설치 방법과 설정 방법을 안내합니다. - AWS IAM 자격 증명 또는 Bedrock API 키를 사용할 수 있습니다. - 필요한 환경 변수를 설정해 에이전트의 요청을 `bedrock-mantle` 엔진으로 라우팅할 수 있습니다. ## 제공 리전과 시작 방법 - Amazon Bedrock 콘솔에서 **Try the Bedrock Mantle Console**을 선택하거나 새 콘솔 링크를 통해 사용할 수 있습니다. - 제공 리전에는 미국, 아시아 태평양, 유럽, 남아메리카 주요 리전이 포함됩니다. - 미국 동부: 버지니아 북부, 오하이오 - 미국 서부: 오리건 - 아시아 태평양: 자카르타, 뭄바이, 시드니, 도쿄 - 유럽: 프랑크푸르트, 아일랜드, 런던, 밀라노, 스톡홀름 - 남아메리카: 상파울루 - 실제 제공 범위는 `bedrock-mantle` 엔드포인트의 리전 목록에서 확인해야 합니다. 새 콘솔은 여러 모델을 빠르게 비교하고, 프로젝트별 사용량을 관찰하며, OpenAI·Anthropic SDK 기반 애플리케이션을 개발하려는 팀에 적합합니다. 반면 Bedrock의 관리형 기능이나 기존 `bedrock-runtime` API를 사용하는 경우에는 기존 콘솔을 계속 활용하면 됩니다.

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

토스팀이 AI 파도를 마주하는 방법: AI Surf Day

토스는 빠르게 변하는 AI를 따라잡기 위해 개인의 학습에만 의존하지 않고, 업무 시간과 조직 문화를 재설계하는 ‘AI Surf Day’를 운영했다. 매주 금요일을 AI 실험과 공유의 시간으로 정해 직군과 숙련도에 관계없이 누구나 AI를 업무에 적용하도록 지원했다. 이 경험은 특정 프로그램보다 자유롭게 시도하고 실패와 성과를 공유하는 문화, 그리고 이를 이끄는 사람들이 AI 전환의 핵심임을 보여준다. ## AI Surf Day의 배경과 목적 - AI 기술이 빠르게 발전하면서 개발자뿐 아니라 PO, 디자이너, 스태프 등 모든 직군에서 AI 활용에 대한 관심이 커졌다. - 반면 비개발 직군을 중심으로 다음과 같은 어려움도 나타났다. - 수많은 AI 정보 중 실제 업무에 유용한 것을 선별하기 어려움 - 새로운 기술을 학습할 별도 시간을 내기 어려움 - AI를 잘 활용하는 사람과 그렇지 못한 사람 사이의 격차와 불안 - 토스는 월요일부터 목요일까지 본업에 집중하고, 매주 금요일은 AI를 실험하고 업무에 적용하는 ‘AI Surf Day’로 운영했다. - 목표는 단순히 AI 도구 사용법을 익히는 것이 아니라, 토스 전체가 AI 기반으로 일하는 문화를 만드는 것이었다. - “파도를 멈출 수는 없지만 서핑하는 방법은 배울 수 있다”는 비유처럼, 예측하기 어려운 AI 변화에 조직적으로 대응하려는 취지를 담았다. ## AI Surf Club: 자율적인 실험과 학습 - 팀원 누구나 AI 관련 주제로 모임을 만들고 참여할 수 있는 핵심 프로그램이다. - 시작과 함께 약 200개의 클럽이 만들어질 만큼 높은 참여가 나타났다. - 대표적인 사례는 다음과 같다. - **AI 안티패턴 스터디** - AI 활용이 잘되지 않았던 시행착오와 실패 사례를 공유했다. - 프로젝트 방향을 잡고 실수를 줄이는 데 도움이 되는 ‘시행착오 방지 가이드’로 내용을 정리했다. - **LLM Wiki 활용법** - 업무 지식이 여러 곳에 흩어진 문제를 해결하기 위해 조직 공동의 지식 자산 구축을 논의했다. - 데이터 엔지니어, 머신러닝 엔지니어, 비즈니스 담당자 등 다양한 직군이 참여해 관점을 넓혔다. - **터미널 초보자를 위한 0단계 모임** - 에이전트 도구 설치나 터미널 사용처럼 기본적인 기술 장벽을 해결했다. - 초보적인 질문도 부담 없이 할 수 있는 안전한 학습 공간을 제공했다. - **금융소비자보호 업무의 AI 전환** - “상담 과정에서 미리 민원을 발견하고 싶다”는 요구에서 출발해 한 달 만에 대외민원 모니터링 포털을 개발했다. - 민원 회신문 초안 작성과 민원 분류 자동화 등 추가 결과물도 만들어냈다. - 가장 큰 성과는 구성원들이 “우리도 AI로 해볼 수 있다”는 자신감을 얻은 점이었다. - **비즈니스 마케팅 팀의 AI 워크숍** - Builder, Curator, Operator, Scouter로 역할을 나누어 AI 도구, 사례, 자동화 결과물을 만들고 공유했다. - 개인의 실험을 다른 팀원이 복제하거나 업무에 적용할 수 있는 자산으로 남기는 데 초점을 맞췄다. ## AI Surf Weekly: 사례와 아이디어의 확산 - 사내 AI 활용 우수 사례, 레슨런, 최신 AI 인사이트를 공유하는 시간이다. - 구체적인 도구 사용법을 일방적으로 교육하기보다, 실제 사례를 보여주고 새로운 아이디어를 떠올리게 하는 방식을 택했다. - 서로 다른 조직의 유사한 문제를 가진 구성원을 연결해 단시간에 결과물을 만들도록 돕기도 했다. - 영업팀의 요구와 유사한 도구를 만든 인사팀 구성원을 연결해 빠르게 업무 도구를 개발했다. - 디자인 자동화에 어려움을 겪던 마케팅 담당자를 디자인 조직의 경험자와 연결해 하루 만에 문제를 해결했다. - 잘 쓰는 사람과 실제 결과물을 공유하면, 구성원들이 자신의 업무에 맞게 응용하면서 새로운 활용 사례가 파생된다는 점을 확인했다. ## AI Surf Evangelist: 현업 중심의 전파 체계 - 조직에서 AI를 잘 활용한다는 것은 개인이 도구를 능숙하게 쓰는 것이 아니라, 기존 업무 흐름을 AI 기반으로 재설계하는 것이다. - 이를 가장 잘 이끌 사람은 실제 업무와 팀의 문제를 잘 아는 현업 구성원이라고 판단했다. - 토스는 AI 기술 전문가보다 다음과 같은 구성원을 에반젤리스트로 선발했다. - 유용한 정보를 발견하면 팀에 공유하는 사람 - 동료가 AI 활용 중 막혔을 때 함께 해결하는 사람 - AI 도입과 전파에 적극적인 사람 - 공개 추천을 통해 이미 비공식적으로 이런 역할을 수행하던 사람을 발굴했고, 총 142명이 선정됐다. - 주요 미션은 다음과 같다. - 3개월 동안 조직 내 AI 활용 사례를 공유 채널에 제보 - 팀 대상 밋업이나 워크숍을 최소 1회 개최 - 유용한 사례와 인사이트를 조직에 전파 - 문화팀은 워크숍 템플릿과 퍼실리테이션을 지원해 각 팀이 ‘업무를 AI 기반으로 재설계한다면?’을 주제로 실험하도록 도왔다. ## OpenAI 협업과 에이전틱 워크플로우 - 5월에는 OpenAI와 협업해 개발자용 Codex 세션, 비개발자용 ChatGPT Agent 자동화 세션, 미니 해커톤을 진행했다. - **iOS Simulator 자동 검증 에이전트** - Codex가 기능 구현, 빌드, 로그인, 입력, 테스트, 수정 과정을 직접 수행했다. - 계획부터 검증 영상 생성까지의 전체 루프를 자동화했다. - **토스플레이스 메뉴 분류 어드민** - AI 에이전트가 매일 상품 데이터를 조회하고 사전 정의된 기준에 따라 1차 분류한다. - 담당자는 알림 링크를 통해 결과를 확인하고 확정 또는 반려한다. - 단순 반복 업무를 재사용 가능한 Agentic Workflow로 전환한 사례다. ## 프로그램보다 중요한 문화와 사람 - AI Surf Day는 6월까지 운영될 예정이지만, 이후 동일한 형식으로 지속될지는 정해지지 않았다. - 글에서 중요하게 본 성과는 특정 프로그램 자체가 아니라 다음과 같은 변화다. - AI를 실험할 수 있도록 공식적인 시간대를 마련함 - 성공뿐 아니라 실패와 시행착오도 공유함 - 서로 다른 팀의 사례와 사람을 연결함 - 워크숍과 결과물이 실제 업무 방식의 변화로 이어짐 - AI 전환을 추진하는 조직이라면 별도 학습 시간을 보장하고, 현업의 자발적 실험을 지원하며, 결과물을 조직 자산으로 공유하는 구조부터 만드는 것이 효과적이다.

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

단일 풀 리퀘스트부터 전체 소프트웨어 패키지까지: 대규모 악성 코드 탐지

BewAIre는 LLM을 활용한 악성 코드 탐지 시스템으로, 기존의 풀 리퀘스트 분석에서 전체 의존성 패키지와 패키지 레지스트리 스캔으로 범위를 확장했다. 저비용 필터 단계와 고성능 에이전트 조사 단계를 결합해 비용과 지연 시간을 줄이면서도 정확도를 97.4%에서 99.86%로 높였고, 오탐을 17건에서 0건으로 낮췄다. 또한 LLM만으로 판단하지 않고 도메인·의존성 검증 같은 정적 검사를 함께 사용해 공급망 공격 탐지의 안정성을 강화했다. ## 풀 리퀘스트 분석만으로는 부족한 이유 - 공격자는 axios, LiteLLM, Mistral 같은 널리 사용되는 의존성 패키지를 침해해 악성 코드를 downstream 사용자에게 확산시킬 수 있다. - 기존 BewAIre는 풀 리퀘스트의 diff를 분석해 침투 테스트, 버그 바운티 활동, 실제 공격을 식별했다. - 그러나 공격 표면은 풀 리퀘스트에 한정되지 않으므로, 전체 패키지와 upstream 레지스트리까지 검사할 필요가 생겼다. - 단순히 더 강력한 추론 모델을 사용하면 정확도는 높아지지만 비용이 증가하고, 대규모 diff는 컨텍스트 윈도우 제한에 부딪힌다. ## 2단계 LLM 평가 구조 - **필터 단계** - 모든 변경 사항을 저렴하고 빠른 모델로 1차 검사한다. - 대규모 diff에는 diff 청크 분할 전략을 적용한다. - 판단은 “의심스러움” 또는 “정상”의 이진 결과다. - 정상으로 판정되면 즉시 종료해 고비용 분석을 피한다. - **조사 단계** - 필터가 의심 신호를 감지한 경우에만 고성능 추론 모델을 호출한다. - 단순히 diff를 읽는 것이 아니라 도구를 사용해 추가 정보를 수집한다. - GitHub API로 커밋 목록, 파일 내용, 기여자 이력, 의존성 메타데이터, 커밋 범위를 조사할 수 있다. - 의심스러운 커밋이 최종 diff에서 사라지도록 되돌려졌는지, 의존성이 typosquatting인지, 작성자의 계정과 소속이 정상적인지 확인한다. - 의존성은 osv.dev와 Datadog SCA 같은 외부 리소스로 검증한다. ## 스택형 LLM 호출이 오탐을 줄인 방식 - 대표 테스트 데이터 690개 diff에서 정확도가 **97.4%에서 99.86%**로 향상됐다. - 오탐은 **17건에서 0건**으로 감소했다. - 대부분의 정상 변경은 필터 단계에서 빠르게 종료되므로 전체 지연 시간도 줄었다. - 의심스러운 변경에 대해서는 더 많은 문맥과 도구를 활용해 정밀한 분석을 수행한다. - 필터 단계와 조사 단계의 역할을 분리함으로써 비용, 속도, 탐지 품질을 동시에 관리했다. ## 에이전트 기반 조사 사례: 파일명에 숨은 명령어 주입 - 공격자는 다음과 같은 형태의 파일명을 사용했다. ```text m$(echo${IFS}...|base64 -d|bash).md ``` - 파일명에 셸 명령 치환을 삽입하고, Base64로 인코딩한 명령을 디코딩해 실행하도록 구성했다. - 실제 페이로드는 외부 서버에서 코드를 내려받아 `bash`로 실행하는 `curl ... | bash` 형태였다. - `${IFS}`를 사용해 공백을 우회하고 보안 필터를 피하려 했다. - 조사 에이전트는 다음과 같은 추가 정황도 확인했다. - 작성자 계정이 생성된 지 7일밖에 되지 않음 - 프로필 정보와 팔로워가 없음 - 리뷰나 승인이 없음 - diff 자체의 악성 명령뿐 아니라 계정 이력과 PR 상태까지 결합해 공격 가능성을 판정했다. ## LLM과 정적 검사의 결합 - 필터 단계는 빠르고 저렴하지만 외부 정보를 직접 탐색하지 못해 일부 공격을 정상으로 판단할 수 있다. - 대표적인 사례가 Datadog과 유사한 도메인을 사용하는 typosquatting 공격이다. - 이를 보완하기 위해 전처리 파이프라인에서 입력에 포함된 모든 도메인을 추출한다. - 정상적인 Datadog 도메인 목록을 바탕으로 생성한 typosquatting 변형 목록과 비교한다. - 이 정적 검사는 LLM에게 의심스러운 Datadog 인접 도메인이라는 명확한 신호를 제공한다. - 비결정적이고 비용이 높은 LLM 판단과 결정적이고 저렴한 정적 검사를 조합해 정확도와 비용 효율을 함께 확보했다. ## 실용적인 결론 대규모 공급망 보안에서는 모든 변경을 고성능 LLM으로 분석하기보다, 저비용 필터와 선택적 심층 조사를 결합하는 방식이 효과적이다. 특히 계정 이력·커밋 상태·도메인·의존성 데이터 같은 외부 문맥과 정적 규칙을 함께 사용해야 LLM의 오탐과 누락을 줄일 수 있다.

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

AWS 주간 정리: AWS의 Claude Opus 4.8, Kiro Powers를 지원하는 Aurora MySQL 등 (2026년 6월 1일) | Amazon Web Services

AI와 클라우드 서비스의 결합이 소프트웨어 개발과 AWS 고객 지원 방식을 빠르게 바꾸고 있다는 내용이다. 특히 Anthropic의 Claude Opus 4.8이 Amazon Bedrock과 Claude Platform on AWS에서 제공되면서 장시간 자율 작업과 에이전트형 코딩이 한층 강화됐다. AWS는 이와 함께 복원력 관리, 에이전트용 검색, 마이그레이션 분석, 자연어 기반 Aurora 운영 등 AI 중심 기능을 대거 공개했다. ## AI 기반 개발 방식의 확산 - AI-Driven Development Lifecycle(AI-DLC) 워크숍에서 17개 팀이 이틀 동안 약 20개의 사용 사례를 구현했다. - Claude Code on Amazon Bedrock 같은 도구를 활용하면 개발 작업의 속도가 크게 향상된다. - 기존의 세분화된 소프트웨어 개발 직무가 AI를 활용하는 소규모 팀 중심으로 재편되고 있다. - AWS의 솔루션 아키텍트와 기술 담당자도 설계 문서를 전달하는 방식에서 벗어나, 고객과 실시간으로 함께 구축하는 방식으로 협업하고 있다. ## AWS의 Claude Opus 4.8 지원 - Anthropic의 최신 범용 모델인 Claude Opus 4.8을 다음 두 경로로 사용할 수 있다. - **Amazon Bedrock**: Guardrails, Knowledge Bases, 데이터 레지던시 등 AWS 관리 기능 제공 - **Claude Platform on AWS**: Anthropic 네이티브 API와 AWS 청구 체계 통합 - 에이전트형 코딩, 지식 노동, 장시간 자율 작업에 최적화됐다. - 긴 세션에서 문맥을 유지하고, 오류를 복구하며, 방대한 문서의 정보를 종합할 수 있다. - 코드베이스를 엔지니어처럼 분석하고 수정 전에 계획을 수립하는 코딩 워크플로를 지원한다. ## 차세대 AWS Resilience Hub - SRE와 개발자가 조직 전체 애플리케이션의 복원력 기준을 정의하고 평가하는 통합 프레임워크를 제공한다. - 복원력 정책을 모듈식으로 구성할 수 있다. - 서비스 수준 목표(SLO) - 멀티 AZ·멀티 리전 재해 복구 - 데이터 복구 기준 - 비즈니스 관점의 애플리케이션 모델링을 지원한다. - 생성형 AI가 Well-Architected Framework와 Resilience Analysis Framework를 기준으로 복원력을 평가한다. - DNS 쿼리 로그를 분석해 애플리케이션 의존성을 자동으로 탐색한다. - AWS Organizations와 연동하면 위임된 관리자 계정 하나에서 조직 전체의 복원력을 관리할 수 있다. ## 에이전트형 AI를 위한 OpenSearch Serverless - Amazon OpenSearch Serverless가 검색 엔진과 벡터 엔진을 결합한 에이전트 애플리케이션용 관리형 서비스로 확장됐다. - 요청량이 0에서 초당 수천 건까지 자동 확장되며, 이전 세대보다 약 20배 빠르다. - 피크 용량을 기준으로 클러스터를 프로비저닝하는 방식보다 최대 60%의 비용 절감이 가능하다. - GPU 가속과 `SEARCH`, `VECTORSEARCH` 컬렉션 유형을 새로 지원한다. - OpenSearch Agent Skills를 통해 Vercel, Kiro, Claude Code, Cursor와 통합할 수 있다. ## AWS Transform의 마이그레이션·현대화 분석 - AWS 이전 전에 비즈니스 케이스와 총소유비용(TCO)을 검토할 수 있는 기능이 추가됐다. - 다음과 같은 다양한 데이터 소스를 수집할 수 있다. - RVTools 내보내기 파일 - CMDB 데이터 - AWS Transform 검색 도구 - 서드파티 검색 도구 - 리전, 사용률, 서비스 매핑을 바꿔 가며 가상 시나리오를 실행할 수 있다. - EC2, FSx, S3, EC2의 SQL Server, 가상 데스크톱 환경을 분석한다. - **Agentic Readiness Analysis(ARA)**와 **Modernization Analysis(MODA)**가 코드 저장소를 약 5~30분 안에 분석한다. - 결과에는 심각도, 파일 단위 근거, AWS 서비스에 매핑된 개선 지침이 포함된다. ## Kiro Powers를 활용한 Aurora MySQL 운영 - Aurora MySQL이 Kiro Powers와 통합되어 사전 검증된 MCP 서버, steering 파일, hooks를 활용할 수 있다. - 개발자는 자연어로 다음 작업을 수행할 수 있다. - 데이터 플레인: SQL 쿼리, 스키마 관리 - 컨트롤 플레인: 클러스터 관리 - Aurora Serverless 확장, RDS에서 Aurora로의 마이그레이션, 복제 구성 등에 대한 동적 안내를 제공한다. - 에이전트가 생성한 API 호출, SQL, 설정을 사용자가 검토한 뒤 실행할 수 있다. - Kiro IDE나 웹페이지에서 원클릭 설치가 가능하다. ## WorkSpaces Applications의 Windows Desktop 지원 - Amazon WorkSpaces Applications에서 자체 Windows Desktop 라이선스를 가져오는 BYOL 방식을 지원한다. - OS 라이선스 비용 없이 컴퓨팅 및 스트리밍 인프라 비용만 부담할 수 있다. - 적격 Microsoft 365 Apps for enterprise도 지원한다. - 로컬 PC와 원격 환경에서 동일한 단축키, 작업 흐름, 탐색 경험을 제공한다. ## 추가 AWS 소식 - 2026년 5월 AWS Heroes 신규 선정자를 소개했다. - Vercel 대시보드나 v0에서 Aurora PostgreSQL, DynamoDB, Aurora DSQL을 직접 프로비저닝하는 AWS 데이터베이스 통합이 공개됐다. - 해당 기술 조합을 활용하는 H0 해커톤에서 총 16만 달러의 상금을 제공한다. - AWS GovCloud(US) 고객의 기술 지원 요청이 미국 내 미국 시민 엔지니어에게 24시간 자동 라우팅된다. ## 실용적인 결론 AWS 환경에서 AI 에이전트를 도입하려면 Claude Opus 4.8을 Bedrock의 보안·거버넌스 기능과 함께 검토하고, OpenSearch Serverless를 검색·벡터 검색 계층으로 활용할 수 있다. 또한 Aurora MySQL 운영 자동화, AWS Transform의 사전 마이그레이션 분석, Resilience Hub의 조직 단위 복원력 평가를 결합하면 개발 속도뿐 아니라 운영 안정성과 비용 예측 가능성도 높일 수 있다.

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

에이전트형 AI 애플리케이션 구축을 위한 차세대 Amazon OpenSearch Serverless 소개 | Amazon Web Services

Amazon OpenSearch Serverless 차세대 버전은 AI 에이전트용 검색·벡터 백엔드로, 트래픽이 없을 때는 0까지 축소되고 필요할 때 초당 수천 건까지 확장됩니다. 기존 피크 용량 기준 클러스터 대비 최대 60% 비용을 절감할 수 있으며, 리소스 생성과 용량 확장이 이전 세대보다 크게 빨라졌습니다. Vercel, Kiro, Claude Code, Cursor 등과의 통합으로 인프라 관리 없이 몇 분 안에 프로덕션 수준의 검색 시스템을 구축할 수 있습니다. ## 서버리스 확장성과 비용 최적화 - 트래픽에 따라 용량을 0에서 수천 RPS 수준까지 자동 확장하고, 유휴 상태에서는 다시 0으로 축소합니다. - 기존 OpenSearch Service 클러스터를 피크 트래픽에 맞춰 프로비저닝하는 방식보다 최대 60% 비용을 절감할 수 있습니다. - 리소스 생성 시간은 수초이며, 이전 세대보다 용량 확장 속도가 최대 20배 빠릅니다. - 인덱싱, 검색, GPU 가속에 사용한 OpenSearch Compute Unit(OCU) 기준으로 컴퓨팅 비용이 부과됩니다. - 스토리지는 GB-month 기준으로 별도 과금됩니다. ## 차세대 컬렉션 생성 - AWS Management Console의 **Serverless → Create collection**에서 차세대 OpenSearch Serverless 컬렉션을 생성할 수 있습니다. - 출시 시 지원되는 컬렉션 유형은 다음 두 가지입니다. - `SEARCH`: 전문 검색 - `VECTORSEARCH`: 벡터 검색 - **Express create**를 사용하면 별도 설정 없이 기본값과 보안 정책이 자동 적용됩니다. - 일부 설정은 컬렉션 생성 후에도 변경할 수 있습니다. - 기존 OpenSearch Serverless 인프라를 사용하려면 **Switch to Classic**을 선택해야 합니다. ## 컬렉션 그룹과 용량 설정 - AWS CLI 또는 SDK를 이용해 컬렉션 그룹과 컬렉션을 생성할 수 있습니다. - 컬렉션 그룹에서 차세대 세대(`NEXTGEN`), 대기 복제본, 인덱싱·검색 용량 한도를 설정합니다. - 예시에서는 인덱싱과 검색 용량을 다음과 같이 설정합니다. - 최대 용량: 각각 96 OCU - 최소 용량: 각각 0 OCU - 컬렉션은 상위 컬렉션 그룹의 세대 설정을 상속합니다. - 컬렉션 그룹 생성 시 `standby-replicas ENABLED`를 지정해 대기 복제본을 활성화할 수 있습니다. - 제공된 CLI 예시는 글에서 같은 명령이 중복 제시되어 있으며, 2026년 5월 업데이트에서 최대 인덱싱·검색 용량 기본값이 96으로 수정되었습니다. ## AI 에이전트 개발 플랫폼 통합 - Vercel 콘솔에서 새 OpenSearch 컬렉션을 생성하거나 기존 OpenSearch Serverless 컬렉션을 연결할 수 있습니다. - 애플리케이션 성장에 맞춰 검색 기능을 단계적으로 추가할 수 있습니다. - Claude Code, Cursor, Kiro를 사용하면 아이디어에서 작동하는 프로토타입까지 빠르게 구현할 수 있습니다. - OpenSearch Agent Skills는 검색 도메인 지식, 모범 사례, 다단계 실행 로직을 에이전트에 제공합니다. - Kiro Powers의 OpenSearch Launchpad는 검색 애플리케이션의 아키텍처를 계획하고 구현하는 과정을 안내합니다. ## 제공 범위와 사용 시작 방법 - 차세대 OpenSearch Serverless는 정식 출시되었으며, 기존 OpenSearch Serverless가 제공되는 모든 AWS 상용 리전에서 사용할 수 있습니다. - 콘솔, AWS CLI, AWS SDK를 통해 컬렉션을 생성할 수 있습니다. - 자세한 관리 방법과 가격은 Amazon OpenSearch Service 공식 문서와 가격 페이지에서 확인할 수 있습니다. AI 에이전트의 검색·벡터 기능을 구축한다면, 트래픽 변동이 크거나 초기 인프라 운영 부담을 줄이고 싶은 경우 차세대 OpenSearch Serverless가 적합합니다. 특히 Vercel이나 Kiro를 사용하는 팀은 Express create와 기본 통합 기능을 활용해 빠르게 시작한 뒤, 필요에 따라 OCU 한도와 검색 기능을 확장하는 방식을 추천합니다.

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