techlist.io
KREN

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

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 에이전트를 효과적으로 활용하려면 “무엇을 만들어 달라”보다 “입력은 무엇이고, 결과는 어떤 형식이어야 하며, 실패와 보안 문제를 어떻게 처리할지”를 구체적으로 정의하는 것이 좋다. 반복되는 수정과 판단을 스킬이나 문서로 축적하고, 민감정보와 작업 맥락을 안전하게 관리하는 습관을 함께 갖추는 것이 실용적인 출발점이다.

원문 읽기(새 탭에서 열림)
AI 에이전트모델 컨텍스트 프로토콜claude-codewebhooks+3
cloudflare3분 읽기큐레이션 요약

Ensemble AI 출신 인재들과 함께 Cloudflare AI 팀을 확장하기

Cloudflare는 Ensemble AI의 핵심 인력을 영입해 AI 인프라와 추론 효율성 분야를 강화한다. 목표는 대규모·멀티모달 모델을 더 작고 빠르며 저렴하게 실행해, 개발자가 전 세계에서 AI 애플리케이션을 안정적으로 배포하도록 돕는 것이다. 이를 위해 모델 구조 개선, 메모리·연산량 감소, GPU 활용률 향상에 집중한다. ### Ensemble AI의 모델 효율화 기술 - Ensemble AI는 2023년 설립 이후 대규모 모델의 메모리, 연산량, 배포 비용을 줄이는 기술을 개발해왔다. - 단순한 양자화나 하드웨어 최적화가 아니라, 신경망의 구조 자체를 더 작고 효율적으로 만드는 접근을 취한다. - **NdLinear**는 트랜스포머의 표준 선형 계층을 대체하는 기술이다. - 다차원 활성값을 평탄화하지 않고 직접 처리한다. - 어텐션 헤드, 채널, 공간 차원 등 데이터의 의미 있는 구조를 보존한다. - 이를 통해 파라미터 수와 계산량을 줄인다. - **NdLinear-LoRA**는 대규모 모델을 파인튜닝할 때 학습해야 하는 파라미터 수를 줄이는 방식이다. - 양자화, 벡터 양자화와 결합하면 모델의 메모리 사용량과 실행 비용을 더욱 낮출 수 있다. ### Cloudflare Workers AI의 추론 효율 개선 - Workers AI는 Cloudflare의 글로벌 네트워크에서 서버리스 GPU 기반 추론을 제공한다. - AI 애플리케이션이 확산될수록 모델 추론 비용은 확장성을 결정하는 핵심 요소가 된다. - 모델 크기, 메모리 사용량, 처리량, GPU 활용률을 개선하면 개발자의 비용 부담을 줄이고 더 많은 AI 서비스를 운영할 수 있다. - 대상 워크로드는 텍스트 생성뿐 아니라 다음 영역으로 확대되고 있다. - AI 에이전트 - 멀티모달 모델 - 개인화 - 파인튜닝 - 검색 결합 생성(RAG) - 강화학습 - Cloudflare는 기존의 추론 엔진 **Infire**, 텐서 압축 기술 **Unweight**, 대규모 언어 모델 실행 플랫폼을 기반으로 효율화 작업을 강화한다. ### 글로벌 AI 인프라와 모델 압축의 결합 - 개발자는 이제 모델에 접근하는 것만으로는 충분하지 않으며, 모델을 저렴하고 안정적으로 사용자 가까이에서 실행할 인프라가 필요하다. - Cloudflare의 글로벌 네트워크와 서버리스 플랫폼은 AI 실행 환경을 애플리케이션이 이미 배포된 위치에 가깝게 제공할 수 있는 기반이 된다. - Ensemble AI의 모델 압축·효율적 아키텍처 기술을 결합하면 다음 효과를 기대할 수 있다. - 낮은 추론 비용 - 빠른 응답 속도 - 향상된 GPU 활용률 - 대규모 배포의 운영 복잡성 감소 - 다양한 모델 크기와 파인튜닝 방식에 대한 실험 용이성 ### 향후 목표 - Cloudflare는 강력한 AI 모델을 전 세계 규모로 실행하면서도 추론 경제성을 개선하는 것을 목표로 한다. - 새 팀은 대규모 언어 모델과 고급 AI 아키텍처의 서빙 비용을 낮추고, 효율적인 모델 실행과 확장 가능한 배포 방식을 발전시킬 예정이다. - 궁극적으로 개발자가 비용과 운영 부담에 막히지 않고 AI 애플리케이션을 구축·배포할 수 있는 플랫폼을 제공하려는 전략이다. 실용적으로는 AI 서비스를 설계할 때 모델 성능만 비교하기보다 파라미터 수, 메모리 사용량, GPU 활용률, 추론 지연시간, 글로벌 배포 비용을 함께 평가해야 한다. Cloudflare의 방향은 이러한 운영 비용을 모델 구조와 인프라 양쪽에서 동시에 줄이려는 접근으로 볼 수 있다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델머신러닝quantizationcloudflare-workers-ai+4
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는 권한·데이터 보존·운영 자동화 범위를 점검한 뒤 제한된 환경에서 도입하는 것이 적절하다.

원문 읽기(새 탭에서 열림)
AI 에이전트모델 컨텍스트 프로토콜amazon-bedrockamazon-ec2+4
naver1분 읽기큐레이션 요약

AI 에이전트를 위한 Playwright E2E 테스트 하네스 구축하기

이 글은 NAVER D2의 메뉴와 관련 서비스 링크를 나열한 페이지입니다. 기술적 주장이나 구체적인 콘텐츠는 포함되어 있지 않으며, D2 News, NAVER Developers, DEVIEW, OpenSource, D2 STARTUP FACTORY 등의 서비스를 소개합니다. ### NAVER D2 관련 메뉴 - `Hello world` - `D2 News` - `About D2` - `NAVER Developers` - `DEVIEW` - `OpenSource` - `D2 STARTUP FACTORY` ### 저작권 정보 - NAVER Corp.의 저작권이 명시되어 있습니다. - Copyright © NAVER Corp. All Rights Reserved. 별도의 기술 내용이나 실용적인 지침은 제공되지 않는 간단한 포털·내비게이션 페이지입니다.

원문 읽기(새 탭에서 열림)
오픈 소스software-developmentdeveloper-community
grammarly2분 읽기큐레이션 요약

말하고, 텍스트로 변환해 전송하세요

모바일에서 음성 입력은 빠르지만, 받아쓰기 결과에 군더더기와 문법 오류가 많아 수정 작업이 필요하다는 문제가 있습니다. Grammarly Keyboard의 음성-텍스트 기능은 사용자의 말을 자연스럽게 정리하고 문장부호와 문법까지 보완해, 어느 앱에서나 바로 보낼 수 있는 문장을 제공합니다. 음성은 처리 후 삭제되며 저장·계정 연결·모델 학습에 사용되지 않습니다. ## 모바일 음성 입력의 한계 - 스마트폰 기본 받아쓰기는 말한 내용을 거의 그대로 옮깁니다. - 필러 단어, 말더듬기, 중간에 문장을 고친 흔적, 누락된 문장부호가 남습니다. - 결과적으로 음성 입력 후 직접 편집해야 하므로 타이핑만큼이나 시간이 걸릴 수 있습니다. ## Grammarly Keyboard의 정리된 음성 입력 - Grammarly Keyboard의 마이크 아이콘을 누르면 현재 사용 중인 앱에서 바로 받아쓸 수 있습니다. - 음성을 단순히 전사하지 않고 다음 작업을 자동으로 수행합니다. - 불필요한 추임새와 필러 단어 제거 - 말하다가 스스로 수정한 부분 정리 - 문법과 문장부호 보완 - 원래 말투와 의도 유지 - 다양한 언어, 억양, 말하는 속도와 리듬을 지원합니다. - 같은 키보드에서 음성 입력과 타이핑을 자유롭게 전환할 수 있습니다. - 필요하면 내장된 Grammarly AI assistant로 작성한 문장을 추가로 다듬을 수 있습니다. ## 다양한 모바일 상황에 적합 - 회의 사이에 메시지나 초안을 작성하는 직장인에게 유용합니다. - 이동 중 아이디어를 기록하려는 학생이나 창작자도 활용할 수 있습니다. - 작은 키보드로 긴 글을 입력하기 어려운 사용자에게 적합합니다. - 마이크는 탭했을 때만 활성화되며, 작동 중에는 키보드 내 표시와 iOS의 주황색 녹음 표시등이 나타납니다. - 주변 소음을 줄이도록 설계되어 이동 중에도 음성 입력을 사용할 수 있습니다. ## 개인정보 보호와 사용 방식 - 음성이 텍스트로 처리된 뒤 오디오는 삭제됩니다. - 오디오는 계정에 저장되거나 계정과 연결되지 않습니다. - 모델 학습에도 사용되지 않습니다. - 최종적으로 남는 것은 정리된 텍스트이며, 사용자가 원하는 앱에서 바로 전송할 수 있습니다. ## iOS에서 시작하는 방법 - App Store에서 Grammarly Keyboard를 설치합니다. - `설정 → 일반 → 키보드 → 키보드 → 새로운 키보드 추가`로 이동해 Grammarly를 추가합니다. - 안내가 표시되면 전체 접근 권한을 활성화합니다. - 아무 앱에서 텍스트 입력란을 선택한 뒤 Grammarly Keyboard의 마이크 아이콘을 누릅니다. - 말하기를 마치면 커서 위치에 정리된 문장이 자동으로 입력됩니다. 모바일에서 긴 문장을 자주 작성한다면 Grammarly Keyboard의 음성 입력은 기본 받아쓰기보다 편리한 대안입니다. 특히 이동 중 빠르게 초안을 만들거나, 음성 입력 후 문장을 일일이 수정하는 시간을 줄이고 싶은 사용자에게 적합합니다.

원문 읽기(새 탭에서 열림)
AIiOSspeech-to-textmobile-keyboard+2
github3분 읽기큐레이션 요약

GitHub Copilot CLI가 작업 위임을 더 선별적으로 하도록 만든 방법

GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델github-copilot-cliorchestrationab-testing+2
dropbox3분 읽기큐레이션 요약

Dropbox가 MCP와 Dash를 활용해 디자인에서 코드로 이어지는 보안 격차를 해소하는 방법

Dropbox는 보안 위협 모델과 실제 코드 구현 사이의 단절을 MCP, 기초 언어 모델, Dash를 결합해 해결하고자 했다. 시스템은 코드 리뷰 시 관련 위협 모델을 자동으로 검색하고, 문서에 정의된 보안 요구사항이 코드에 반영됐는지 비교한다. 분석 결과 구현 PR의 12%만 원래 보안 검토와 연결되어 있었으며, 보안 지식을 코드 리뷰 시점에 자동으로 제공하는 것이 핵심 해결책으로 제시된다. ## 설계와 코드 사이의 보안 격차 - 보안 검토에서는 잠재적 위험, 공격 가능성, 필요한 보호 조치를 위협 모델에 기록한다. - 그러나 개발이 시작되면 위협 모델은 위키나 문서 시스템에 남고, 구현 코드는 별도의 PR에서 관리된다. - 명시적인 링크가 없으면 코드 리뷰어가 과거의 보안 요구사항을 확인하기 어렵다. - Dropbox의 분석 결과: - 구현 PR 중 원래 설계 검토 및 위협 모델을 연결한 비율은 **12%**에 불과했다. - 검증된 79개 쌍 중 **54%**는 보안 검토 후 한 달이 지나서야 PR이 생성됐다. - 보안 검토부터 PR 생성까지의 중앙값은 약 **5주**였다. - 일부 지연은 **11개월 이상**이었다. - 검토 후 2주 이내에 생성된 PR은 **29%**뿐이었다. ## 기존 보안 도구의 한계 - 정적 분석 도구는 코드에 특정 보안 제어가 존재하는지 확인할 수 있다. - 하지만 해당 제어가 설계 검토에서 합의한 요구사항과 일치하는지는 판단하기 어렵다. - 정적 분석은 코드의 패턴은 검사하지만, 설계 의도와 이전에 결정된 보안 맥락은 알지 못하기 때문이다. - 개발자에게 설계 문서와 PR을 직접 연결하도록 요구하거나 알림 봇을 사용하는 방식도 지속적인 준수에 의존한다. - 설계 검토의 약 **15%**는 코드가 먼저 작성된 뒤 사후적으로 진행됐다. - 따라서 자동화 시스템은 기존 검토와 코드를 연결하는 것뿐 아니라, 보안 검토가 필요할 가능성이 있는 작업을 개발 중 조기에 식별하는 역할도 할 수 있다. ## Dash와 MCP를 활용한 컨텍스트 연결 - Dash는 여러 연결된 애플리케이션의 문서를 색인하므로, 기존 위협 모델과 엔지니어링 문서를 통합적으로 검색할 수 있다. - Dropbox는 코드가 리뷰에 제출될 때 관련 위협 모델을 자동으로 검색하도록 시스템을 구축했다. - MCP(Model Context Protocol)는 AI 에이전트가 Dash가 색인한 문서에 접근하도록 하는 연결 계층이다. - 보안 검토 에이전트는 Dash의 MCP 서버를 통해 위협 모델과 관련 문서를 검색하고 읽는다. - 별도의 소스 시스템별 맞춤 통합 없이 여러 컨텍스트를 하나의 에이전트 세션에 결합할 수 있다. ## 요구사항과 구현 코드의 비교 - 코드 리뷰가 시작되면 에이전트는 관련 위협 모델과 보조 문서를 가져온다. - 기초 언어 모델은 문서에 기록된 보안 요구사항과 변경된 코드를 함께 분석한다. - 예를 들어 위협 모델이 특정 엔드포인트에 인증을 요구한다면, 실제 코드가 인증을 강제하는지 판단할 수 있다. - 기존 정적 분석과 달리 단순히 취약한 코드 패턴을 찾는 것이 아니라, **설계 단계의 보안 결정이 구현에 반영됐는지**를 검토한다. - 결과를 별도의 보안 절차가 아니라 개발자가 이미 사용하는 코드 리뷰 과정에 제공하는 것이 중요한 설계 원칙이다. ## 실용적인 결론 보안 검토 문서를 별도로 잘 작성하는 것만으로는 충분하지 않다. 해당 문서의 요구사항이 코드가 검토되는 시점에 자동으로 노출되고 구현과 비교되어야 하며, 이를 위해 조직의 기존 문서 검색 시스템과 MCP 기반 AI 에이전트를 코드 리뷰 흐름에 통합하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델모델 컨텍스트 프로토콜코드 리뷰static-analysis+2
cloudflare4분 읽기큐레이션 요약

보안 인사이트 확장: 글로벌 스캔 처리 역량을 10배 향상한 방법

Security Insights는 기존 주 1~2회에 그치던 보안 검사를 모든 계정에 더 자주 적용하기 위해 처리량을 초당 10건에서 100건으로 약 10배 높여야 했다. Cloudflare는 Kafka 소비 병렬화, 느린 작업 분리, Postgres 대량 삽입 최적화, 지역 간 네트워크 지연 분석을 통해 스캔 처리량을 10배 이상 향상시켰다. 그 결과 수백만 고객에게 보안 인사이트를 제공하고 전체 고객의 검사 주기를 두 배로 늘릴 수 있었다. ## 기존 보안 검사 구조와 확장 과제 - 스케줄러가 검사 시점이 된 계정과 Zone을 감지한다. - 검사 작업을 Apache Kafka 메시지로 발행하고, 여러 Go 기반 checker 마이크로서비스가 메시지를 나누어 처리한다. - 각 checker는 특정 자산이나 설정을 검사한 뒤 내부 API로 결과를 전송한다. - API는 결과를 Postgres 데이터베이스에 저장한다. - 기존 시스템은 다음 문제를 겪고 있었다. - 검사가 주 1~2회만 수행되어 위험이 최대 2주간 탐지되지 않을 수 있었다. - 많은 무료 요금제 계정에서 자동 검사가 선택 사항이라 검사 자체가 이뤄지지 않았다. - Kafka backlog 증가, API 타임아웃, 프로세스 충돌이 발생했다. - 모든 계정에 자동 검사를 적용하고 검사 빈도를 높이려면 평균 처리량을 초당 10건에서 100건으로 늘려야 했다. ## Kafka 파티션의 병목 - Kafka는 일반적인 큐와 달리 파티션 내 메시지를 순서대로 소비하고 처리한다. - 하나의 consumer group에서는 파티션당 활성 consumer를 하나만 둘 수 있다. - 따라서: - 처리 시간이 긴 메시지 하나가 뒤따르는 메시지의 처리를 막을 수 있다. - checker별 병렬 소비자 수는 Kafka 파티션 수에 제한된다. - 파티션을 추가하면 확장할 수 있지만, 여러 서비스가 공유하는 Kafka 브로커의 자원 사용량이 증가하므로 최후의 수단으로 남겨두었다. ## 배치 기반 병렬 처리 - 메시지를 하나씩 처리하던 checker를 배치 단위로 소비하도록 변경했다. - 배치 안의 각 메시지는 별도의 Go goroutine에서 동시에 처리했다. - 이 방식의 trade-off는 다음과 같다. - 배치 처리 중 프로세스가 중단되면 이미 처리한 작업을 다시 수행해야 할 수 있다. - 동시에 처리하는 작업이 늘어 메모리 사용량이 증가한다. - 검사 시스템에서는 재처리 비용과 메모리 증가가 감당 가능한 수준이었기 때문에 병렬 처리를 선택했다. ## 느린 작업으로 인한 Head-of-Line Blocking 제거 - 일부 계정이나 Zone은 자산 수가 많아 검사에 수초가 아니라 수분 또는 수시간이 걸릴 수 있었다. - 이런 느린 메시지가 일반 메시지 앞에 있으면 Kafka 소비가 멈춰 빠른 작업까지 지연됐다. - 해결책으로 checker와 consumer group을 두 개의 처리 경로로 분리했다. - **Fast lane**: 빠르게 처리할 수 있는 일반 메시지 담당 - **Slow lane**: 처리 시간이 긴 메시지 전담 - 메시지의 예상 처리 시간을 빠르게 판단하고, fast lane이 느린 메시지를 만나면 건너뛰도록 했다. - 그 결과 느린 작업은 전용 자원을 사용하고, 빠른 작업은 지연 없이 계속 처리할 수 있었다. ## Postgres 대량 저장 최적화 - 기존 API는 인사이트 하나마다 별도의 `INSERT ... ON CONFLICT DO UPDATE` 쿼리를 실행했다. - 한 요청에 최대 50만 개의 인사이트가 포함될 수 있어, 최악의 경우 50만 번의 데이터베이스 왕복과 쿼리 실행이 발생했다. - 처음에는 임시 테이블에 `COPY`하는 Postgres 표준 대량 삽입 방식을 시도했지만, Postgres 시스템 테이블의 bloat가 증가하는 문제가 나타났다. - 최종적으로 입력 규모에 따른 하이브리드 방식을 채택했다. - 작은 데이터셋: `UNNEST`를 사용해 빠르게 삽입 - 큰 데이터셋: `COPY`를 사용해 대량 삽입 - 이 방식은 대규모 데이터에는 수초 수준의 처리 시간을, 소규모 데이터에는 밀리초 수준의 빠른 처리를 제공했다. ## 지역 간 지연으로 발생한 API 타임아웃 - 확장 과정에서 다음 현상이 관찰됐다. - 클라이언트 타임아웃 증가 - checker 처리 시간의 20~90%가 단일 API 호출에 소요 - 대량 검사 시 초기 처리량은 높지만 시간이 지나며 감소 - 원인은 API와 데이터베이스 간 네트워크 지연이었다. - 주 데이터베이스는 미국 오리건주 포틀랜드에 위치했다. - API는 포틀랜드와 네덜란드 암스테르담에서 active-active로 운영됐다. - 포틀랜드 API 호출은 평균 10ms였지만, 암스테르담 인스턴스에서는 거의 3초가 걸렸다. - 암스테르담 API가 데이터베이스 연결을 오래 점유하면서 checker의 클라이언트 연결 풀이 고갈됐다. - 연결을 기다리는 요청이 타임아웃되고, 암스테르담 API에 연결된 Kafka 파티션만 지속적으로 지연됐다. - 결국 API의 단순한 지역 분산이 전체 Kafka 소비 처리량의 불균형과 lag를 유발할 수 있음을 확인했다. ## 실용적인 결론 대규모 이벤트 처리 시스템에서는 소비자 수를 늘리는 것만으로 충분하지 않다. Kafka의 파티션 제약을 고려한 병렬 처리, 느린 작업의 별도 격리, 대량 데이터베이스 작업의 배치화, 데이터베이스와 API 간 지역 지연 관리까지 함께 최적화해야 안정적인 처리량 확장이 가능하다. 특히 분산 배포 환경에서는 평균 latency뿐 아니라 연결 풀 점유 시간과 파티션별 처리 편차까지 함께 측정해야 한다.

원문 읽기(새 탭에서 열림)
PostgreSQLApache Kafka분산 시스템API+4
google4분 읽기큐레이션 요약

사용하지 않는 휴대폰으로 만드는 저탄소 컴퓨팅 플랫폼

사용이 끝난 스마트폰의 메인보드를 모아 클러스터로 구성하면, 새 서버 제조를 줄이면서 저비용·저탄소 클라우드 컴퓨팅 플랫폼으로 재활용할 수 있다. UC 샌디에이고와 Google은 2,000대의 Pixel 스마트폰으로 데이터센터를 구축해 교육·연구용 컴퓨팅을 제공할 계획이다. 이 방식은 스마트폰의 제한된 메모리와 코어 수에 맞는 작업을 선별하고, 대규모 배포에서 소비자용 하드웨어의 신뢰성을 검증하는 것을 목표로 한다. ## 컴퓨팅의 탄소 배출과 스마트폰 재활용 - 컴퓨팅의 탄소발자국은 크게 두 가지다. - **운영 탄소**: 기기 사용 중 소비되는 전력에서 발생하는 배출량 - **내재 탄소**: 하드웨어 제조와 원자재 추출 과정에서 발생하는 배출량 - 전력 효율 향상과 재생에너지 사용으로 운영 탄소는 줄일 수 있지만, 제조 과정의 내재 탄소는 해결이 더 어렵다. - 사람들은 평균 4년마다 스마트폰을 교체하지만, 교체된 기기에도 프로세서, 가속기, 메모리, 저장장치 등 핵심 컴퓨팅 기능이 남아 있다. - 기존 스마트폰을 재사용하면 새 하드웨어 생산과 추가적인 원자재 채굴을 피할 수 있다. ## 스마트폰과 서버의 성능 차이 - 2023년형 Pixel Fold의 고성능 코어는 SPEC 벤치마크에서 일부 최신 데이터센터 서버의 단일 코어 성능을 웃돈다. - 다만 스마트폰은 서버보다 다음과 같은 제약이 있다. - 코어 수가 적고 CPU 구성이 이기종임 - 메모리가 약 8~12GB로 제한됨 - 서버처럼 대규모 멀티스레드 처리나 대용량 메모리를 제공하지 못함 - 따라서 하나의 스마트폰에 들어갈 수 있거나, 여러 기기로 분할할 수 있는 작업이 적합하다. - 벤치마크상 약 25~50대의 스마트폰이 현대적인 서버 한 대에 해당하는 성능을 낼 수 있다. ## 스마트폰을 데이터센터 하드웨어로 개조 - 소비자용 스마트폰을 그대로 데이터센터에 배치하면 비효율적이고 위험하다. - 디스플레이, 배터리, 카메라, 케이스 등 서버에 필요 없는 부품이 공간을 차지함 - 특히 배터리는 데이터센터 환경에서 장시간 사용하기에 적합하지 않을 수 있음 - 따라서 메인보드만 분리해 클러스터에 사용한다. - 메인보드는 스마트폰 내재 탄소의 약 50%를 차지하는 가장 중요한 부품이므로, 이를 재사용하는 것이 환경적 효과가 크다. - Android 기반의 모바일 사용자 공간은 범용 Linux 배포판으로 교체한다. - 클라우드 작업에 필요한 프로그래밍 환경을 제공함 - 모바일 기기용 보호 기능을 제거하거나 조정할 수 있음 - 예를 들어 메모리 부족 시 애플리케이션을 종료하는 ‘Low Memory Killer’의 영향을 줄일 수 있음 - 컨테이너화된 애플리케이션을 Kubernetes로 관리해 25~50대 단위의 자기관리형 클러스터를 구성한다. ## 교육·연구용 저탄소 클라우드 - 대학에서 사용하는 Jupyter 환경, 과제 채점 시스템, 병렬 계산 수업용 애플리케이션 상당수는 스마트폰 한 대 또는 소규모 클러스터로 처리할 수 있다. - 일반적인 과제 채점 백엔드는 AWS t3.micro 수준인 2 vCPU·1GB 메모리 인스턴스에서도 실행된다. - 20대 스마트폰 클러스터를 이용한 실험에서: - 75명 이상 수강하는 수업의 최대 과제 제출량을 처리함 - 일반적인 AWS 백엔드보다 낮은 채점 지연 시간을 기록함 - 약 50초가 걸리는 CPU 집약적 행렬 곱셈 과제도 처리 가능했음 - 2,000대 규모의 클러스터는 약 50대의 서버에 해당하는 컴퓨팅 자원을 제공하고, 동시에 약 100개 수업을 지원할 수 있을 것으로 예상된다. - 2026년 가을 전체 시스템 운영을 시작할 계획이다. ## 대규모 운영에서 검증할 과제 - 소비자용 스마트폰 메인보드를 장기간 데이터센터 부하로 사용할 때의 신뢰성을 검증해야 한다. - 다수 기기의 장애를 감지하고 작업을 재분배하는 클러스터 관리가 중요하다. - 제한된 메모리와 이기종 코어 구조에 맞도록 애플리케이션을 설계해야 한다. - 이 프로젝트는 실제 교육·연구 서비스를 제공하는 동시에 스마트폰 기반 컴퓨팅의 확장성과 지속 가능성을 시험하는 테스트베드 역할을 한다. 사용이 끝난 스마트폰은 서버 전체를 대체하기보다는 교육, 과제 채점, 소규모 웹 서비스처럼 자원 요구량이 제한적인 작업에 재활용하는 것이 현실적이다. 특히 메인보드 재사용과 컨테이너·Kubernetes 기반 클러스터 관리를 결합하면 비용 절감과 제조 탄소 감축을 동시에 달성할 가능성이 있다.

원문 읽기(새 탭에서 열림)
쿠버네티스Android분산 시스템클라우드 컴퓨팅+4
google4분 읽기큐레이션 요약

AI가 사용자의 피부 질환 이해를 돕는 방법에 대한 연구

인터넷과 AI가 피부 질환 정보를 찾는 데 도움을 주지만, 정보를 이해하고 적절한 다음 행동을 결정하는 일은 여전히 어렵다. Google Research는 피부 질환 후보를 제시하는 AI가 일반인의 질환명 파악 능력과 검색 만족도를 크게 높인다는 점을 확인했지만, 병원 방문 시점 등 안전한 후속 조치 판단에는 효과가 제한적이라고 밝혔다. 따라서 피부과 AI는 진단 보조뿐 아니라 사용자의 의사결정을 지원하는 인간 중심 설계가 필요하다. ## 피부 건강 정보에서 인간 중심 연구가 필요한 이유 - 성인의 절반 이상이 인터넷으로 건강 정보를 찾고, 약 3분의 1은 AI를 활용한다. - 정보에 접근할 수 있어도 의학 용어를 모르거나 검색 결과를 잘못 해석할 수 있다. - 예: “다리에 빨간 점”이라는 증상을 보고도 실제 검색어인 “촉지성 자반(palpable purpura)”을 알기 어렵다. - 기존 연구에서는 인터넷 검색으로 질환 식별 능력은 향상될 수 있지만, 이후 어떤 행동을 해야 하는지 판단하는 능력은 반드시 좋아지지 않는 것으로 나타났다. - Google Research는 감별진단 AI 모델, 일반화 검증, SCIN 데이터셋 등을 개발해 왔으며, 궁극적으로는 피부 고민이 있는 사람들이 더 나은 결정을 내리도록 돕는 것을 목표로 삼았다. ## 대규모 실험: AI가 질환명 파악에 미치는 영향 JAMA Dermatology에 게재된 연구에서는 2,345명의 참가자에게 이미지와 병력 정보가 포함된 익명 피부 질환 사례를 제시하고, 자신의 사례라고 가정해 조사하도록 했다. - 참가자는 세 집단으로 무작위 배정됐다. - **일반 검색 대조군**: 기존 텍스트 기반 웹 검색 도구 사용 - **AI 집단**: AI가 예측한 3~7개의 질환 후보를 카드 형태로 제시하고, 각 질환의 이미지·증상·치료 정보를 제공 - **‘Wizard of Oz’ 집단**: 동일한 인터페이스를 사용하지만, AI 예측 대신 피부과 전문의 패널이 정한 실제 감별진단을 제시 - AI 도구는 확정 진단을 내리기보다 이미지와 가능한 질환을 연결해 정보를 찾기 쉽게 하는 방식으로 설계됐다. - AI 집단에서는 62% 이상이 질환명을 추측하려 했으며, 일반 검색 집단의 41%보다 높았다. - 질환명 추측 정확도는 다음과 같았다. - 일반 검색 집단: 8% - 일반 AI 집단: 23% - 전문의 감별진단을 제공한 집단: 36% - AI 사용자는 자신의 추측에 더 큰 자신감을 보였고, 검색 결과와 검색에 걸린 시간에 대한 만족도도 높았다. - 다만 전문의 감별진단을 그대로 제공한 경우에도 정확도가 완벽하지 않아, 후보 질환을 보여주는 것만으로 사용자의 이해가 완전해지는 것은 아니었다. ## 질환 식별과 다음 행동 판단은 별개의 문제 연구진은 AI가 지나치게 지시적이거나 진단적인 도구가 되지 않도록 설계했다. - 치료 및 질환 정보는 피부과 전문의가 권위 있는 자료를 바탕으로 작성했다. - 그러나 정보는 해당 질환의 일반적인 설명에 기반했으며, 개별 사례의 심각도에 맞춰 개인화되지는 않았다. - 참가자들은 다음과 같은 판단에서 여전히 어려움을 겪었다. - 집에서 관리해도 되는지 - 일반 진료를 예약해야 하는지 - 긴급하게 병원을 방문해야 하는지 - 다음 행동 판단의 정확도는 전문의 감별진단을 제공한 집단에서만 소폭 높아졌다. - 전문의 감별진단 집단: 63.5% - 일반 검색 대조군: 60% - 일반 AI 집단은 통계적으로 유의미한 개선을 보이지 않았다. - 오히려 일반 AI 집단은 피부과 전문의가 판단한 것보다 덜 긴급한 행동을 제안하는 비율이 다소 높았다. - AI 집단: 30% - 대조군: 27% - 이는 가능한 질환명을 알려주는 것만으로는 안전한 의료 결정을 보장할 수 없으며, 위험 신호와 긴급도를 명확히 안내하는 기능이 필요하다는 점을 보여준다. ## 실제 사용자와 지역사회를 대상으로 한 질적 연구 연구진은 통제된 설문만으로는 사람들이 자신의 피부 문제에 AI를 어떻게 적용하는지 충분히 알기 어렵다고 보고, 실제 피부 고민이 있는 지역사회 구성원을 대상으로 별도의 연구를 진행했다. - ACM CHI 학회에 발표된 연구는 Stanford Healthcare AI Applied Research Team, Santa Clara Family Health Plan과 공동으로 수행됐다. - 연구 대상 지역사회에는 의료 안전망인 Medi-Cal에 의존하는 사람들이 다수 포함됐다. - 참가자들은 실제 피부 고민을 가진 다양한 배경의 사람들로 구성됐다. - AI 피부 애플리케이션을 실제 환경에서 사용하게 하면서 다음을 살폈다. - 사용자가 AI 정보를 어떻게 해석하는지 - 자신의 증상과 AI가 제시한 정보를 어떻게 연결하는지 - 정보가 의료 이용이나 의사결정에 어떤 영향을 주는지 - 참가자들이 주로 사용하는 언어가 네 가지였기 때문에 애플리케이션을 각 언어로 번역했다. - 해당 언어에 능통한 자원봉사자나 직원도 참여해 의사소통을 지원함으로써, 다양한 언어권 사용자에게 적합한 설계를 연구하려 했다. 피부과 AI는 질환 후보를 빠르게 찾고 의학 정보를 이해하는 데 유용하지만, 그 결과를 곧바로 진단이나 치료 결정으로 받아들여서는 안 된다. 실제 서비스에서는 긴급 증상 안내, 불확실성 표시, 개인의 증상과 심각도를 반영한 후속 조치 안내, 의료진 상담 연결 기능을 함께 제공하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
AI머신러닝healthcare-aidifferential-diagnosis+3
github1분 읽기큐레이션 요약

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

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

원문 읽기(새 탭에서 열림)
대규모 언어 모델AI 에이전트cybersecurityai-workflows+1
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는 이러한 통제 장치를 갖춘 상태에서 에이전트가 데이터베이스·결제·호스팅·관측성까지 자동으로 구성하도록 만드는 방향으로 확장되고 있다.

원문 읽기(새 탭에서 열림)
AI 에이전트api-integrationclickhousehermes+4
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 기반 에이전트 테스트를 목표 중심·탐색적 검증에 제한적으로 추가하는 구성이 가장 실용적이다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜claude+3
naver1분 읽기큐레이션 요약

MLXP : Kubernetes LLM Serving 최적화 기술 도입기

이 글은 기술적 내용을 담은 본문이라기보다 NAVER D2 사이트의 기본 메뉴와 저작권 정보를 나열한 페이지입니다. `D2 News`, `About D2`, `NAVER Developers`, `DEVIEW`, `OpenSource`, `D2 STARTUP FACTORY` 등의 항목이 소개되지만, 각 항목에 대한 설명이나 결론은 제공되지 않습니다. ### NAVER D2 사이트 메뉴 - `Hello world` - `D2 News` - `About D2` - `NAVER Developers` - `DEVIEW` - `OpenSource` - `D2 STARTUP FACTORY` ### 저작권 정보 - 저작권자는 NAVER Corp.입니다. - 표기: `Copyright © NAVER Corp. All Rights Reserved.` 별도의 기술적 주장이나 실용적인 지침은 포함되어 있지 않아, 이 글만으로는 특정 기술 주제를 학습하거나 적용하기 어렵습니다.

원문 읽기(새 탭에서 열림)
오픈 소스software-developmentdeveloper-community
gitlab3분 읽기큐레이션 요약

GitLab 패치 릴리스: 19.0.2, 18.11.5, 18.10.8 | GitLab 문서

2026년 6월 10일 GitLab은 CE/EE용 패치 버전 19.0.2, 18.11.5, 18.10.8을 출시했다. 이번 릴리스에는 계정 탈취, XSS, 서비스 거부, SSRF, 권한 우회 등 다수의 보안 취약점이 포함되어 있어 모든 자체 관리형 설치 환경에 즉시 업그레이드가 권고된다. GitLab.com은 이미 패치가 적용됐으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 보안 및 주요 버그를 수정하기 위한 버전이다. - 정기 패치는 매월 둘째·넷째 수요일에 배포되며, 심각도가 높은 취약점에는 비정기 긴급 패치가 제공될 수 있다. - 영향을 받는 버전을 사용하는 모든 설치 유형(Omnibus, 소스 코드, Helm Chart 등)은 가능한 한 빨리 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점의 상세 이슈는 수정 릴리스 후 30일이 지나면 공개된다. ## 계정 탈취와 권한 검증 문제 - **CVE-2026-6552 — Group SAML Identity API** - GitLab EE 대상 취약점이다. - 그룹 Owner 권한의 인증 사용자가 잘못된 권한 검증을 악용해 다른 그룹 구성원의 GitLab 계정을 탈취할 수 있었다. - CVSS **8.7**로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - **CVE-2026-6269 — Merge Requests API** - CE/EE 모두 영향을 받는다. - Developer 권한 사용자가 숨겨진 머지 리퀘스트를 수정할 수 있었다. - CVSS **5.4**다. - **CVE-2026-6277 — Security Inventory** - GitLab EE 대상이다. - Security Manager가 관련 기능이 비활성화된 상태에서도 프로젝트 보안 설정을 변경할 수 있었다. - CVSS **4.3**이다. - **CVE-2026-6976 — Merge Request diff** - 파일명 처리와 권한 검증 문제로 Developer가 머지 리퀘스트 diff에서 변경 사항을 숨길 수 있었다. - CVSS는 **3.7**로 평가됐다. ## XSS 및 HTML 입력값 검증 문제 - **CVE-2026-10087 — Analytics Dashboard** - GitLab EE 대상이다. - Developer 권한 사용자가 입력값 검증 미흡을 이용해 대상 사용자의 권한으로 임의의 클라이언트 측 코드를 실행할 수 있었다. - CVSS **8.7**이며, 사용자의 상호작용이 필요하다. - **CVE-2026-8589 — 그룹 설정 필드** - GitLab EE 대상이다. - 악의적인 입력을 통해 대상 사용자 계정에 승인되지 않은 이메일 주소를 추가할 수 있었다. - CVSS **7.3**이다. - **CVE-2026-10733 — CI/CD Catalog** - CE/EE 모두 영향을 받는다. - 부적절한 입력값 정제로 인해 인증 사용자가 CI/CD Catalog 페이지에서 서비스 거부를 유발할 수 있었다. - CVSS **4.3**이다. ## 서비스 거부 및 리소스 고갈 - **CVE-2026-7250 — Grape API JSON 파싱 미들웨어** - CE/EE의 API 요청 파싱 과정에서 입력값 검증이 부족했다. - 인증하지 않은 공격자가 조작된 요청을 보내 서비스 거부를 일으킬 수 있었다. - CVSS **7.5**로, 외부에 노출된 API 서버에 특히 중요하다. - **CVE-2026-1500 — Group Placeholder Reassignments API** - 특수하게 제작된 파일 업로드를 처리하는 과정에서 리소스가 과도하게 소비될 수 있었다. - 인증된 사용자가 서비스 거부를 유발할 수 있으며, CVSS는 **6.5**다. ## SSRF와 내부 데이터 접근 - **CVE-2026-9204 — Gitaly 저장소 가져오기** - 저장소 가져오기 과정에서 보조 URL 검증이 충분하지 않았다. - 인증된 사용자가 Gitaly 서버의 임의 파일을 읽거나 내부 네트워크 리소스에 접근할 가능성이 있었다. - CVSS **5.3**이며, 서버 측 요청 위조(SSRF) 유형의 취약점이다. ## 적용 대상 버전 - **19.0.2**: GitLab 19.0 계열의 이전 버전 - **18.11.5**: GitLab 18.11 계열의 이전 버전 - **18.10.8**: GitLab 18.10 계열의 이전 버전 - 취약점별로 GitLab 12.10, 13.1.4, 15.x, 17.x 등 다양한 이전 버전이 영향을 받는다. - 취약점에 따라 GitLab EE만 영향을 받거나 CE/EE 모두 영향을 받는다. 자체 관리형 GitLab 운영자는 현재 버전의 지원 브랜치에 맞춰 19.0.2, 18.11.5, 18.10.8 중 해당되는 버전으로 즉시 업그레이드하고, 외부 공개 API와 Gitaly 접근 로그도 함께 점검하는 것이 좋다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabaccess-controlapi-security+3