AI 뉴스

마이크로소프트, 스마트 TV의 Copilot 기능 지원 종료

마이크로소프트가 올해 모든 TV에서 Copilot 기능 지원을 종료한다고 Windows Central 보도가 전했다. LG와 삼성은 CES 2025에서 최신 스마트 TV에 Copilot 접근을 포함한다고 발표했던 바 있다. 이 소식은 LG, 삼성, 마이크로소프트의 공식 발표가 아니라 Windows Central의 Zac Bowden이 webOS 기반 LG TV에서 본 화면 알림을 통해 알려졌다. 알림에는 마이크로소프트가 LG TV의 Copilot 기능을 포함해 모든 TV에서 Copilot 기능 지원을 종료하기로 했다는 내용이 적혀 있었다.

Amazon Bedrock AgentCore 기반 엔터프라이즈 Agentic AI 플랫폼 구축 아키텍처

AWS Machine Learning Blog는 Amazon Bedrock과 Amazon Bedrock AgentCore 위에서 여러 팀이 에이전트를 운영할 수 있는 엔터프라이즈 Agentic AI 플랫폼의 아키텍처와 참조 구현을 공개했다. 에이전트를 실제 운영에 올리는 병목은 모델과 도구 사용보다 보안 환경, 팀별 소유권, AgentOps, 비용 가시성 같은 주변 요소에 있다는 점을 짚었다. 기사는 Platform 팀이 플랫폼을 관리하고 Workstream 팀이 그 위에서 에이전트를 만드는 구조를 제시한다. 각 Workstream에는 승인된 모델과 도구, 단기 수명의 워크로드 아이덴티티, 격리된 런타임과 메모리, 자동 평가, 롤백, 텔레메트리, 비용 귀속이 기본 경로로 제공된다. 추론 게이트웨이는 Amazon Bedrock Guardrails 등 조직의 가드레일을 적용하고 Workstream별 요청 한도와 토큰 쿼터, 예산을 강제한다. 도구 접근은 인증된 MCP 게이트웨이를 통해 최소 권한 실행 역할로 제어된다. 이 설계는 멀티 계정 운영 모델, 반복 가능한 Workstream별 배포 패턴, 프로덕션 승격 전 에이전트를 게이팅하는 평가 파이프라인을 포함한다. 기사는 이를 배포 가능한 인프라 코드로 제공되는 Enterprise Agentic AI Platform Blueprint로 묶어 공개했다.

AWS 샘플 리포지토리의 enterprise-agentic-ai-platform-blueprint와 AgentCore의 runtime, gateway, identity, memory, policy, evaluations 모듈을 활용해 Workstream별 게이트웨이 분리, 쿼터 설정, 평가 게이팅을 구성하는 참조 구조로 쓸 수 있다.

Ray Train DLC와 EFA로 EKS에서 분산 학습 구성하기

AWS가 CUDA, NCCL, EFA 스택과 Ray를 미리 묶어 배포하는 Ray Train Deep Learning Container(DLC)를 사용해, 이미지를 직접 빌드하지 않고 EKS에서 PyTorch 분산 학습 클러스터를 띄우는 방법을 소개한다. 학습 코드와 클러스터 매니페스트만으로 두 인스턴스 간 노드 통신을 EFA로 처리할 수 있다는 점이 핵심이다. 기사는 Qwen2.5-1.5B를 PyTorch Fully Sharded Data Parallel(FSDP)으로 미세 조정하는 예제를 다룬다. 구성은 g6.12xlarge 인스턴스 2대에 NVIDIA L4 GPU 8개이며, 제어 노드(m7i.xlarge)에서 KubeRay 오퍼레이터와 Ray head가 돌고 GPU 워커 노드 2대가 같은 가용 영역에 놓인다. KubeRay는 하나의 RayCluster 매니페스트에서 head 그룹과 worker 그룹을 만들고, 각 GPU마다 워커 하나씩 총 8개의 워커를 배치한다. 사용 이미지는 public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1 태그로, Ray 2.58.0, PyTorch 2.13.0, CUDA 13.0.2, NCCL 2.29.7, EFA 최신 버전과 AWS OFI NCCL 플러그인이 포함되어 있다. 인스턴스 간 집합 통신은 파드가 EFA를 요청하는 순간부터 EFA 경로로 흐른다. 기사는 같은 이미지가 KubeRay로 EKS에서 실행되든, EC2에서 직접 시작되든 동일하게 head와 worker 역할을 맡는다고 설명한다. 사용자가 추가하는 것은 인스턴스 종류, 파드당 GPU 수, NCCL이 쓸 네트워크 전송 방식, 작업에 필요한 Python 패키지 같은 설정뿐이며 모두 이미지 외부에서 지정한다. 샘플 저장소와 함께, 같은 KubeRay-on-EKS 기반을 쓰는 다중 노드 Ray Serve 예제도 링크되어 있다.

g6.12xlarge 2대와 L4 GPU 8개 구성에서 ray:train-ml-cuda-v1.1 태그와 EFA 요청만으로 인스턴스 간 NCCL 통신을 구성할 수 있어, CUDA·NCCL·aws-ofi-nccl 버전을 직접 맞추는 빌드 작업을 생략할 수 있다.

Amazon Nova Act 기반 QA Studio에 애플리케이션 단위 테스트 관리와 팀 기반 사용자 권한 기능 추가

AWS Machine Learning Blog의 Part 3 글은 QA Studio에 applications 기능과 팀 기반 사용자 관리 기능을 더해 여러 팀이 테스트를 함께 운영하는 방법을 설명한다. 테스트가 늘어나면 테스트 작성보다 조직화와 접근 제어가 병목이 된다는 문제를 다룬다. QA Studio의 application은 테스트 대상 시스템(웹사이트, 웹 앱, 서비스 프런트엔드)을 나타내며, 이름·기본 URL·선택적 환경(development, staging, production)으로 생성한다. 사용 사례(use case)와 테스트 스위트는 애플리케이션에 속하고 그 소유권을 상속하므로, 팀은 전체 테스트 목록 대신 자신이 소유한 애플리케이션 안에서 작업한다. 테스트 실행 결과는 Amazon CloudWatch 커스텀 메트릭으로 기록되며 애플리케이션과 환경 차원으로 구분된다. 애플리케이션 페이지에는 선택 기간의 통과율, 총 실행 수, 현재 실패 수와 함께 0~100 사이의 건강 점수가 표시되며, 이 점수는 통과율에서 플래키(flaky) 테스트에 대한 감점을 뺀 값이다. 추이 탭은 7일(시간 단위)과 30일(일 단위) 구간을 제공하고, 플래키 테스트 보기는 최근 7일간 통과와 실패를 오간 횟수로 사용 사례를 순위화한다. 최근 실패 목록의 각 항목은 Part 1에서 설명한 Amazon Nova Act 트래젝터리 로그와 세션 녹화로 바로 연결된다. 기사는 팀 기반 사용자 관리를 통해 누가 무엇을 보고 변경할 수 있는지 제어한다고 밝히고 있으나, 세부 권한 모델은 이 요약의 근거 범위 밖이다.

CloudWatch 커스텀 메트릭으로 기록되는 애플리케이션·환경별 통과율과 0~100 건강 점수, 그리고 최근 7일 플래키 테스트 순위를 활용하면 여러 팀의 테스트 상태를 한 화면에서 비교하고 불안정한 테스트를 우선 점검할 수 있다.

AI 시대의 시스템 사고: 엔지니어의 역할은 기술 수행에서 전문가 협업 조율로 확장된다

기사는 엔지니어가 AI 도구로 연구 검색, 설계안 생성, 시뮬레이션 테스트를 수행한 뒤 결과를 전문가에게 넘기는 협업 방식을 제시한다. 최종 판단과 책임은 여전히 사람에게 있으며, 엔지니어의 역할이 각 기술 단계 수행에서 사람·기계·전문가 지식의 결합 방식을 결정하는 쪽으로 넓어진다고 설명한다. 기사는 의료 기기 사례를 들어 설명한다. AI가 여러 센서 설계안을 만들고 각 설계의 성능을 예측하면, 엔지니어는 예측을 검증해 기술 요건을 어기는 설계를 제외한다. 이후 임상의가 실제 사용 가능성을 판단하고, 환자와 실무자가 엔지니어나 개발자가 놓친 문제를 드러낼 수 있다고 본다. 기사는 AI가 설득력 있는 답을 내놓아도 가정이 약하거나, 한 테스트에서만 동작하는 코드를 만들거나, 잘못된 목표로 설계를 최적화할 수 있다고 지적하며 사람의 전문성이 더 중요해진다고 강조한다. 기사는 IEEE가 여러 분야 전문가를 묶는 커뮤니티를 만들고, 임상 AI·복원력 있는 인프라·자율 시스템 같은 문제 중심 협업을 지원할 수 있다고 제안한다. 또한 AI 생성 결과를 언제 검증해야 하는지, 불확실성을 어떻게 기록하는지, 사람의 판단과 기계의 출력이 섞인 시스템에서 책임 주체가 누구인지에 대한 실무 표준이 필요하다고 덧붙인다.

AI가 생성한 설계안과 코드는 시뮬레이션이나 단일 테스트로 검증하고, 임상 적용처럼 전문가 판단이 필요한 단계는 사람이 결정하도록 워크플로를 설계할 필요가 있다.

Google AI Mode, 2020·2024 미국 대선 승자 질문에 직접 답하지 않고 FEC 공식 보고서 확인을 안내

Ars Technica의 테스트에 따르면 Google AI Mode는 '2020년 미국 대선 승자는 누구인가?'라는 질문에 직접 답하지 않았다. 대신 연방선거위원회(FEC)가 작성한 공식 보고서를 확인하라는 응답을 내놓았다. 2024년 대선 질문에도 같은 방식으로 답했다. 2012년 대선 질문에는 직접 답 대신 The American Presidency Project의 2012 Data Center 링크가 제시됐다. 반면 2000년 이후 다른 모든 대선의 승자에 대해서는 AI Mode가 상세하고 정확한 답을 제공했다.

GitHub Octoverse 2026: 월간 병합 PR 2억 2천만 건, 커밋 73억 8천만 건으로 신고점

GitHub가 Octoverse 2026 보고서를 발표하며 2026년 월간 병합 풀 리퀘스트(PR)가 2억 2천만 건으로 1년도 안 돼 세 배가 됐다고 밝혔다. 월간 커밋은 73억 8천만 건으로 세 배 이상 늘었고, 대부분의 증가가 올해 하반기에 집중됐다. 보고서에 따르면 월간 신규 저장소 생성 속도는 올해 두 배로 늘어 월 3,030만 건에 이르렀다. 기사는 이 수치들이 에이전트 기반 엔지니어링이 GitHub에 미친 영향을 보여준다고 서술했다. 보고서는 산업별 수치도 새로 포함했으며, 공개 저장소의 이름·설명·토픽·README를 다국어 임베딩 모델로 분류해 NAICS 산업 분류에 배정했다. 또한 '상호운용성 또는 리버스 엔지니어링'을 언급하는 저장소 수를 별도로 집계했는데, 이는 클린룸 구현, 드롭인 대체, 프로토콜 재구현 같은 용어가 포함된 경우를 포함한다. 국가별 집계는 공개 저장소에 대한 푸시를 기준으로 하며, VPN 사용에 따른 편향을 보정하기 위해 프로필 위치 정보에서 LLM으로 ISO 3166-1 alpha-2 국가 코드를 추출했다고 방법론 섹션에 적혀 있다.

보고서의 월간 병합 PR 2억 2천만 건과 커밋 73억 8천만 건은 에이전트 기반 개발의 규모를 가늠할 수 있는 기준치이며, 팀의 PR 리뷰 및 CI 부하 계획에 직접 참고할 수 있다.

Microsoft Foundry Agent Service에 Copilot harness 퍼블릭 프리뷰 공개, 호스팅 에이전트 장기 실행 복원력 GA

Microsoft가 Foundry Agent Service에서 Microsoft Copilot harness를 퍼블릭 프리뷰로 공개했고, 호스팅 에이전트의 장기 실행 복원력(long-running resilience)은 일반 제공(GA)으로 전환됐다고 발표했다. 에이전트 루프와 샌드박스를 Microsoft가 관리해 복잡하고 오래 걸리는 작업을 개발자가 인프라 구성 없이 구현할 수 있게 한다는 것이 핵심이다. Copilot harness는 에이전트를 선언형으로 정의하면 모델과 도구 호출 조정, 작업 컨텍스트 유지, 파일 관리, 다단계 작업의 진행 방식 결정을 Microsoft가 실행하는 구조다. 개발자는 지식, 절차, 도구를 제공한다. 프리뷰는 네 가지 구성요소로 이루어진다. 지침·스크립트·참고 자료를 묶은 재사용 가능한 skills, 인증과 승인을 명시적으로 설정하는 Foundry 및 Model Context Protocol(MCP) 도구 연결, 파일과 코드를 다루고 하위 작업을 내장 subagent에 위임하는 실행 및 위임 기능, 그리고 Foundry에서 만들거나 애플리케이션 코드와 함께 소스 관리하는 에이전트 정의다. 예시로 제시된 azure.yaml에서는 harness type을 microsoft_copilot_preview로 지정하고 web_search, code_interpreter 도구와 research-brief 스킬을 연결했으며, azd deploy --all과 azd ai agent invoke 명령으로 배포하고 호출한다. 기사는 Confluence Technologies가 1주일 안에 솔루션을 가동했다고 밝혔고, Fashable은 소싱 과정을 관리되고 측정 가능한 에이전트 워크플로로 바꾸는 기반으로 사용한다고 설명했다. 기사에 명시된 한계나 비교 수치는 없다.

azure.yaml에서 harness type을 microsoft_copilot_preview로 지정하고 skills와 web_search, code_interpreter 도구를 연결하는 방식으로, 실행 루프를 직접 구현하지 않고 에이전트를 배포할 수 있다.

GitHub Universe 2026, GitHub Copilot app·Copilot projects·Copilot Fusion 등 에이전트 기반 소프트웨어 전달 체계 공개

GitHub는 GitHub Universe 2026에서 에이전트 중심 소프트웨어 전달 체계를 소개하며 GitHub Copilot app, Copilot Fusion, Copilot projects, Copilot code review Max 등 새 제품과 기능을 공개했다. 개발자가 이슈에서 병합까지의 작업을 하나의 흐름에서 다루도록 설계됐다는 점이 핵심이다. GitHub Copilot app은 여러 프로젝트에 걸쳐 에이전트와 도구를 연결해 이슈에서 병합까지를 한 앱에서 처리하며, 코드 작성뿐 아니라 스펙 작성, 설계 논의, 텔레메트리 분석도 같은 화면에서 할 수 있다고 한다. Copilot Fusion은 추론, 코드 생성, 디버깅, 도구 사용 등 작업 요구사항을 평가해 하나 이상의 모델로 실행을 분배하며, Artificial Analysis Coding Agent Index에서 Fusion Max는 Opus 5.5 Max와 2점 이내의 점수를 기록하면서 비용은 절반, 작업당 시간은 40% 적었다고 밝혔다. Copilot projects는 여러 저장소에 걸친 에이전트 작업을 관리형 병렬 세션으로 실행하고, Copilot code review Max는 ReviewBench에서 고심각도 이슈에 대해 가장 높은 F1 점수를 기록했다고 소개했다. 세션 연속성 기능으로 GitHub 앱, VS Code, CLI, 웹에서 같은 클라우드 에이전트 세션을 이어갈 수 있으며, GitHub Enterprise 고객은 별도 구독 없이 Copilot 기능을 사용하고 사용한 AI 크레딧만 지불하게 된다. 인프라 측면에서는 올해 4백만 CPU 코어, 160PB 고속 스토리지, 50Tb/s 네트워크 용량을 추가했고 Azure로의 다중 리전 마이그레이션을 내년 초 완료할 계획이라고 밝혔다.

GitHub Enterprise 고객은 Copilot app, code review, automations를 별도 구독 없이 사용하고 사용한 AI 크레딧만 지불하며, Copilot code review Max는 깊은 리뷰가 필요한 변경에 적용하는 옵션으로 제공된다.

GitHub Octoverse 2026: 에이전트 도입 확산과 17.9억 회 푸시 기록

GitHub는 지난 12개월간 개발자들이 17.9억 회 코드를 푸시했고, 이는 2024년과 2025년을 합친 것보다 많다고 밝혔다. 에이전트 활용이 늘면서 전체 활동이 급증한 흐름이 이 보고서의 핵심이다. 에이전트 설정 파일이 있는 신규 저장소는 그렇지 않은 저장소보다 커밋 수가 평균 8배 많았다. 9월 기준 개발자가 시작하는 풀 리퀘스트의 40% 이상이 에이전트로 시작됐으며, 3월에는 17%였다. 9월에 GitHub Copilot 사용자의 61%가 한 개 이상의 모델을 사용했고, 요청은 범용, 심층 추론·계획, 빠르고 가벼운 모델에 걸쳐 분산됐다. GitHub Actions는 올해 초당 1,440회 작업을 실행했고, Dependabot 풀 리퀘스트는 3,000만 건 이상 병합되어 2025년 속도의 약 두 배였다. 기사는 전체 커밋 수가 340억 건으로 2년 전보다 3배 이상 늘었고, 병합된 풀 리퀘스트는 13억 건으로 3배 이상 증가했다고 전한다. 공개 기여는 25억 건으로 작년 11.2억 건의 두 배를 넘었다. 개발자 수는 2억 2,500만 명을 넘었으며 미국(3,830만 명)과 인도(3,200만 명)가 가장 큰 커뮤니티다.

에이전트 설정 파일이 있는 신규 저장소의 커밋 수가 평균 8배 많았다는 수치는 Copilot 등 에이전트 도구를 저장소 초기 설정 단계부터 도입하는 것이 작업 속도에 직접 영향을 준다는 근거가 된다.

GitHub Copilot Fusion 정식 출시, 작업별 모델 선택 대신 자동 라우팅·오케스트레이션

GitHub Copilot Fusion이 일반 제공(GA)되었다. 개발자가 작업마다 모델을 고르는 대신 Copilot이 사용할 모델과 조합 방식을 자동으로 결정하며, Standard·High·Max 세 가지 effort 수준으로 성능과 비용의 균형을 맞춘다. Copilot Fusion은 Project HydraFusion의 다중 모델 오케스트레이션과 Copilot auto 모델 선택의 미세 조정된 모델 선택 기능을 결합한 것이다. 워크플로는 하나의 모델이 직접 해결하는 Single, 효율적인 모델이 초안을 만들고 품질 검사 후 필요하면 더 강한 모델로 넘기는 Cascade, 한 모델이 초안을 쓰고 다른 모델이 검토하면 원래 모델이 수정하는 Critique 세 가지다. 기사에 따르면 Artificial Analysis Coding Agent Index에서 Copilot Fusion Max는 60점을 얻어 Claude Code with Opus 5.5 Max와 2점 차이였으며, 작업당 평균 API 비용은 약 절반, 사용 토큰은 약 절반, 작업당 소요 시간은 약 40% 적었다고 밝혔다. 관리자는 엔터프라이즈·조직 모델 정책으로 Copilot Fusion이 사용할 모델을 통제하고 기본 모델로 지정할 수 있다. 요금은 사용하는 각 모델의 표준 요율로 청구되며, 유료 Copilot 플랜 사용자는 제한된 기간 동안 Copilot Fusion 사용 시 모델 비용에 30% 할인을 받는다. Visual Studio Code, GitHub Copilot 앱, GitHub Copilot CLI, JetBrains IDE에서 모든 Copilot 플랜으로 이용할 수 있고, 다른 클라이언트 지원은 추후 제공될 예정이다. 기존 리서치 프리뷰 참여자의 auto, HydraFusion, HydraFusion Max 선택은 대응하는 Copilot Fusion effort 수준으로 자동 전환된다.

Copilot Fusion Max가 Claude Code with Opus 5.5 Max와 2점 차이로 근접한 점수를 보이면서 작업당 API 비용이 약 절반으로 줄었다는 수치는 팀 단위 AI 코딩 도구 비용 산정에 직접 참고할 만하다.

GitHub Copilot 앱에 Projects 공개 프리뷰 추가, 데스크톱 앱 제어(Computer Use)도 프리뷰로 공개

GitHub Copilot 앱에 여러 저장소와 자료를 한곳에 묶는 Projects가 공개 프리뷰로 나왔다. Copilot은 목표를 받아 백그라운드에서 여러 에이전트를 돌리고, 결과를 풀 리퀘스트 형태로 가져와 검토를 요청한다. Projects에서는 Slack 스레드, Figma 디자인, 설계 회의 메모 같은 맥락을 함께 넣을 수 있고, 작업에 맞는 모델과 도구를 골라 쓸 수 있다. 기능이 추가될 때마다 홍보 영상을 만드는 식의 반복 작업은 project automations로 자동화할 수 있다. 단일 저장소 안의 작업은 기존처럼 해당 저장소에서 세션을 바로 시작하면 된다. Computer Use는 macOS와 Windows에서 공개 프리뷰로 제공되며, API나 CLI, MCP 연동이 없는 데스크톱 앱에서도 화면 내용을 읽고 버튼을 클릭하고 텍스트를 입력할 수 있다. 앱을 제어하기 전에는 사용자의 승인을 요청하며, 조직은 관리 설정에서 이 기능을 끌 수 있다. macOS에서는 손쉬운 사용과 화면 기록 권한을 부여해야 한다.

Computer Use는 API가 없는 데스크톱 앱까지 Copilot이 직접 다룰 수 있게 하므로, 조직은 managed settings로 기능을 끄는 방식으로 통제 범위를 정해야 한다.

NVIDIA RTX Spark 노트북에 Nemotron 3.5 Transcribe·LFM3 모델과 GPU 자원 관리 기능 추가

NVIDIA RTX Spark 기반 얇고 가벼운 Windows 노트북이 ASUS, Dell, HP, Lenovo, Microsoft, MSI에서 출시됐고, 음성 모델 Nemotron 3.5 Transcribe, Liquid AI의 LFM3 모델군, NVIDIA App의 GPU 자원 관리 기능이 함께 발표됐다. 이 노트북은 최대 128GB 통합 메모리와 FP4 기준 최대 1 petaflop의 AI 성능을 갖췄다. Nemotron 3.5 Transcribe는 녹음된 대화를 전사하고 화자를 구분하며 번역하는 오픈 웨이트 음성 모델로, 하나의 프롬프트 가능한 모델이 세 가지 작업을 모두 처리한다. 40개 언어를 지원하며 힌디어 등 인도계 언어 7종을 포함한다. 활성 파라미터는 약 43억 개이고 Hugging Face Open ASR 1위, Artificial Analysis 오픈 웨이트 모델 2위이며, BF16·FP8·NVFP4 형식으로 Hugging Face에서 제공되고 NeMo-Speech.cpp나 vLLM으로 배포할 수 있다. NVIDIA App의 자원 관리 기능은 System > Advanced에서 전경 앱과 백그라운드 에이전트 사이의 GPU 자원 배분을 고를 수 있게 하며, Windows에서 하드웨어 가속 GPU 스케줄링이 켜져 있어야 한다. LFM3는 텍스트·비전·오디오·옴니·의사결정 모델이 하나의 백본을 공유하는 오픈 웨이트 모델군이며, RTX Spark에서 llama.cpp와 vLLM으로 바로 실행하고 로컬에서 미세 조정할 수 있다고 기사는 밝혔다. 게임 쪽에서는 Phantom Blade Zero가 10월 28일 Steam과 Epic Games Store에 출시되며 레이 트레이싱과 DLSS 4.5를 지원하고, RTX Remix 1.6으로 Minecraft Java Edition 1.21.1에 경로 추적을 적용할 수 있게 됐다.

Nemotron 3.5 Transcribe의 활성 파라미터 약 43억 개와 NVFP4 배포 옵션은 노트북 등 로컬 하드웨어에서 음성 전사·번역 파이프라인을 직접 구성하려는 개발자에게 직접 참고가 된다.

Nautilo 개발자 Dan Jeffries가 말하는 agentic 제품 구축의 현실: 지속 메모리·사람과 에이전트의 협업·결정론적 도구 설계

TWIML AI Podcast 제 782화에서 Nautilo 창업자 Dan Jeffries는 개인용 및 협업용 AI 에이전트 플랫폼을 만들며 얻은 경험을 이야기했다. 범용 에이전트가 기본으로 제공되는 상황에서 차별화는 아키텍처 결정과 특화된 경험에서 나온다는 것이 핵심 논지다. 기사는 지속적 메모리, 사람과 에이전트 사이의 작업 조율, 개인 컨텍스트 관리, LLM 기능을 보완하는 결정론적 도구 설계를 다룬다. 또한 멀티 에이전트 아키텍처, 컴퓨터 사용(computer use), 로컬 모델과 클라우드 모델 사이의 트레이드오프에 대한 Jeffries의 견해를 함께 소개한다. 에이전트가 더 유능하고 접근하기 쉬워질수록 차별화는 어려워진다는 점을 실무자 관점에서 짚는다.

Nautilo의 지속 메모리와 결정론적 도구 설계는 LLM 기능을 보완하는 아키텍처를 직접 짜야 한다는 실무 기준을 보여준다.

Claude Opus 5.5로 만든 바이브 코딩 게임: Tree Appreciator·Emberwick·Battle Drones 등 재미있는 브라우저 게임 4편

Simon Willison은 2026년 10월을 바이브 코딩(vibe coding)으로 컴퓨터 게임을 만드는 새로운 전환점으로 보고, Claude Opus 5.5로 만든 HTML·JavaScript 기반 브라우저 게임 네 편을 소개했다. 그는 모델이 게임 디자인 능력을 갖춰 재미있는 게임을 짧은 지시만으로 만들 수 있게 됐다고 평가했다. Willison은 Opus 5.5가 3D 모델링, 음악 생성, 게임 디자인에서 의미 있는 개선을 보였다고 적었다. 과거에는 모델이 게임처럼 보이는 결과물을 만들 수 있었지만 실제로 재미있는 게임을 만드는 것이 과제였다고 설명했다. 그는 Tree Appreciator를 일반 Claude 채팅 인터페이스에서 'three js game' 한 번의 프롬프트로 만들었고 후속 수정 없이 완성됐다고 밝혔다. 또 Battle Drones는 'Make it a LOT more fun'이라는 지시로 개선됐다고 소개했다. 반면 Willison은 GPT-6 Astra가 게임은 만들 수 있지만 재미의 감각은 아직 Opus 5.5에 미치지 못한다고 평가하며, OpenAI가 올해 말까지 따라올 것으로 예상했다.

Claude Opus 5.5가 three.js 기반 게임을 단 한 번의 프롬프트로 만들어냈다는 점은, 브라우저 게임 프로토타이핑에서 프롬프트 설계와 게임 컨셉 발굴이 핵심 역량이 되고 있음을 보여준다.

Artificial Analysis Intelligence Index v5 개편과 독립 벤치마크의 한계

Artificial Analysis가 Intelligence Index v5를 발표했으며, 지식 노동·코딩·과학·일반 영역을 각 25%씩 가중합한 단일 점수로 최신 프런티어 모델을 순위화한다. 이 단일 지표가 모델 경쟁의 승패를 좌우하는 만큼 평가 방식 자체가 업계에 큰 영향을 준다. v5의 가중치는 지식 노동 25%(AA-Briefcase 15%, AutomationBench-AA 5%, GDP.pdf 5%), 코딩 25%(FrontierCode 2.0 15%, Terminal-Bench 4.0 10%), 과학 25%(Terminal-Bench-Science 15%, CritPt v2 hard subset 10%), 일반 25%(AA-Omniscience v1.1 15%, 그중 정확도 10%·비환각 5%, HLE-Diamond 10%)로 구성된다. 기사에 따르면 이 지수에서 GPT 6.1 Terra가 Claude Fable 5.1을 앞섰고, 8개의 폐쇄형 모델이 최고의 오픈 웨이트 모델인 Kimi K3.1 Pro를 앞섰다. 기사는 이 지수가 실제 사용 패턴을 반영하려 하지만 현실의 모델 능력이 들쭉날쭉해 집계 점수에 긴장과 혼선이 드러난다고 지적한다. 또한 오픈 모델은 코딩에서 경쟁력이 높은 반면 지식 노동에서는 확신이 낮고, 과학 평가에서 특히 뒤처진다고 분석한다. 저자는 이전 지수가 오픈 모델을 지나치게 유리하게 보여 줬다고 보며, 다음 세대 모델(GLM 6, Kimi 3.5 등) 출시 때 오픈 모델이 이 지수에서 상당한 진전을 보일 것으로 예상한다.

코딩 비중 25%와 Terminal-Bench 4.0(10%) 점수가 모델 선택 기준으로 쓰이는 만큼, 도입 시 해당 가중치와 개별 벤치마크 점수를 직접 확인하는 것이 필요하다.

Qwen3.5-4B 모델 가중치 안에 32비트 RISC-V CPU를 구현한 Qwenputer 프로젝트

r/LocalLLaMA에 올라온 글에 따르면, 한 개발자가 Qwen3.5-4B 모델의 가중치 안에 32비트 RISC-V CPU를 직접 구현해 모델이 명령어를 내부적으로 실행할 수 있게 만든 'Qwenputer' 프로젝트를 공개했다. 작성자는 이것이 도구 호출(tool calling)과 컴퓨터 사용(computer use)에 함의를 가질 수 있다고 언급했다. 프로젝트는 설명 글(divagr.com/blog/qwenputer), Hugging Face 모델 저장소(divagr1925/Qwen3.5-4B-Qwenputer), ModelScope 라이브 데모로 함께 공개되었다. 글의 제목과 작성자 설명은 RISC-V 명령어를 모델 내부에서 실행한다는 점에 초점을 맞춘다.

Hugging Face에 공개된 Qwen3.5-4B-Qwenputer 가중치를 직접 내려받아 RISC-V 명령어 실행 동작을 검증해볼 수 있다.

Anthropic, 기업공개(S-1) 서류 제출 - 3분기 매출 168억 달러와 지배구조 공개

Anthropic이 상장 신청서(S-1)의 전문을 공개했으며, 기사 작성자 Zvi Mowshowitz는 이를 주요 재무·지배구조 내용 중심으로 정리했다. 서류에 따르면 3분기 매출은 168억 달러(조정 영업이익률 11%)로, 3개월 기준 45% 성장에 그쳤다. 서류상 Anthropic은 조달 자금 1,410억 달러 중 1,310억 달러를 보유하고 있으며, 상반기 현금흐름은 +39억 달러로 기록됐다. 기사는 자금 조달 과정에서 발생한 약 720억 달러의 '공정가치 변동' 손실이 주가 상승에 따른 회계상 재평가이며, 해당 전환사채가 사실상 이미 주식으로 전환된 상태라고 설명한다. 컴퓨팅 약정 규모는 약 8,000억 달러로 추정된다. 창업자들은 Class F 주식을 통해 장기간 경영권을 유지하고, 직원과 함께 장기이익신탁(LTBT)의 결정을 뒤집을 수 있는 구조다. 기사는 3분기 성장 둔화의 배경으로 Fable의 데이터 보존 문제, Opus 4.7·4.8·5 모델에 대한 부정적 평가, 경쟁 모델 Astra의 강세, 3분기 소비 계절성 등을 든다. 다만 Opus 5.5 출시 이후 4분기 실적 회복을 기대하는 전망도 함께 제시된다.

직원 1인당 연간 환산 매출 660만 달러(2026년 9월 30일 기준, 직원 약 5,300명, 과거 12개월 매출 350억 달러)라는 수치는 AI 기업의 인력 생산성을 가늠하는 참고 지표다.

27년 된 리팩터링 책을 AI 코딩 시대에 다시 읽어야 하는 이유: 변경이 쉬운 코드와 응집성·결합도

1999년 출간된 마틴 파울러의 『리팩터링』은 2018년 2판이 나왔고, 기사 필자는 AI 코딩 에이전트가 보편화된 지금도 동작하는 코드를 고치며 배우는 일이 중요하다고 주장한다. 좋은 코드의 기준을 ‘변경이 쉬운 코드’로 보고, 높은 응집성과 느슨한 결합도를 그 목표로 제시한다. 기사는 좋은 코드를 가늠하는 확실한 방법이 ‘수정하기 쉬운 정도’라는 『리팩터링』의 관점을 소개한다. 코드 베이스가 커지면 사람이 전체를 인지하기 어려워 복잡성이 생기고, 이를 다루기 위해 함수·클래스·패키지 단위로 코드를 덩이 짓고 이름을 붙여 덩이 안의 상호작용은 늘리고 덩이 사이의 상호작용은 줄이는 방식을 설명한다. 이것이 곧 높은 응집성과 느슨한 결합도다. 필자는 AI 코딩 에이전트에 “높은 응집성과 느슨한 결합도로 만들어줘”라고 지시하는 것만으로는 충분하지 않다고 본다. 생성된 코드의 응집성과 결합도를 검증하려면 개발자 자신이 그 차이를 구분할 지식을 갖춰야 하며, 그렇지 않으면 초보자가 전문가를 이끄는 역전된 학습과 인지적 부채만 쌓인다고 지적한다. 기사는 SI 프로젝트에서 이전 코드를 다시 작성하며 배우는 개발자의 사례와 『리팩터링』·켄트 벡의 『Tidy First?』가 구체적인 코드 개선 예시로 가득하다는 점을 들어, 이런 역량은 추상적 설명이 아니라 직접 코드를 고치는 경험에서 생긴다고 정리한다.

AI 코딩 에이전트가 생성한 코드를 검토하려면 『리팩터링』이 제시한 응집성과 결합도의 기준을 직접 적용할 수 있어야 한다.

AI에게 처음부터 끝까지 개발을 맡긴 과정과 누락 기능을 잡아낸 방법

Jest 테스트가 전부 통과했음에도 요구사항 명세 40개 중 25개만 구현된 결과가 나왔고, 빠진 항목은 검색 필터와 정책 분기처럼 기능의 의미를 정하는 15개였다. 필자는 이후 요구사항 추적표와 단계별 원인 분석으로 누락을 잡는 과정을 기록했다. 필자는 Figma나 티켓을 AI가 분석해 plan.md에 요구사항과 기능 명세를 정리하고, /start가 이를 기준으로 구현하며, /generate-test와 /e2e가 같은 명세에서 BDD 시나리오와 테스트 코드를 만드는 파이프라인을 썼다. 긴 작업은 /handoff로 progress.md에 끝낸 일과 남은 일, 미결 질문을 적어 다음 세션으로 넘겼다. 보고서에는 P0 미완 항목 세 개(카테고리 옵션, 담당자 표시, 저장 확인)가 이미 적혀 있었지만, 파이프라인은 작성된 테스트의 통과 여부만 완료 조건으로 검사해 작업이 계속 진행됐다. mock 문제도 있었다. 프론트엔드와 mock은 id, category, state, businessKeyId를 썼으나 실제 API는 propertyId, propertyType, propertyStatus, affiliateId를 내려주었고, 이 차이로 실제 서버 연결 시 모든 행의 id가 비어 한 행을 선택하면 전체가 선택되었다. 이후 개발 서버의 실제 응답을 먼저 캡처해 타입과 fixture, mock을 만드는 순서로 바꾸었다.

테스트 통과만으로 완료를 판단하면 빠진 요구사항(예: 검색 필터, 정책 분기)이 드러나지 않으므로, 명세 항목을 수용 조건·시나리오·테스트·코드에 한 줄씩 연결한 요구사항 추적표로 누락을 확인해야 한다.

비개발자가 Claude Code와 외부 서비스를 CLI로 연동해 바이브 코딩하는 방법

요즘IT 기고는 비개발자가 Claude Code를 활용해 Supabase, GitHub 같은 외부 서비스와 CLI로 연동하고 작업을 자동화하는 방법을 정리했다. 이 연동으로 DB 설계와 테이블 생성 같은 작업을 사용자가 직접 하지 않고 Claude Code에 위임할 수 있다고 설명한다. 기사에서 소개한 저자의 서비스는 카카오톡 로그인, Render 호스팅, Supabase DB, GitHub 저장소를 사용한다. 사용자 테이블, 인증 테이블, 콘텐츠 테이블 생성을 Claude Code에 맡기면 되고, 각 서비스의 인증 키(Secret Key)만 전달하면 이후 작업을 위임할 수 있다고 한다. 저자는 Claude Code에 '직접 진행해줘'라고 요청하는 방식을 제안한다. Claude Code가 이해하기 어려운 개발 용어로 선택지를 제시할 때는 '비 개발자도 이해할 수 있도록 쉽게 설명해줘'라고 요청하는 방법을 권했다. 복잡한 이슈는 HTML 문서로, 화면 설계는 PNG 파일로 추출해 확인하는 방식도 함께 소개했다.

Supabase 테이블 설계를 Claude Code에 CLI로 위임하고 인증 키만 전달하는 방식은 개발 지식이 적은 기획자나 디자이너도 프로토타입 DB 구성을 직접 진행할 수 있는 실무 절차다.

마크 큐반, 의료비 투명성과 AI 활용 방안을 말하다 - Cost Plus Drugs 경험 기반

마크 큐반은 AI가 의료를 바꿀 수 있지만 불투명한 가격과 잘못된 인센티브는 AI만으로 해결되지 않는다고 말한다. 그는 고용주에게 모든 복리후생 계약을 AI에 넣어 어디서 과다 청구를 당하는지 물어보라고 권한다. a16z의 Julie Yoo, Erik Torenberg와 나눈 대담에서 큐반은 Cost Plus Drugs를 만들며 배운 점과 신뢰가 이 회사의 핵심 제품인 이유를 설명한다. 투명성이 높아지면 의료비에 압력이 가해질 수 있다고 본다. 이 밖에 AI가 도움을 줄 수 있는 영역, 개인 맞춤형 의학의 모습, 의사의 역할이 바뀔 가능성도 다룬다. 또한 창업자는 AI를 생각을 멈추는 핑계가 아니라 배우는 도구로 써야 한다는 입장을 밝힌다.

복리후생 계약 데이터를 AI로 분석해 과다 청구 항목을 찾는다는 접근은 Cost Plus Drugs와 Cost Plus Wellness가 공개하는 가격 투명성 모델과 맞물려 의료 데이터 기반 개발 아이디어로 참고할 만하다.

Claude를 투자 및 주식 리서치에 활용하는 방법

Asian Century Stocks의 Michael Fritzell이 정리한, Claude로 투자 및 주식 리서치를 수행하는 실무 가이드다. 기사는 Anthropic의 상장 전망과 Claude 도구들의 금융 분야 적용을 함께 다룬다. 기사는 실사용 예시로 어닝콜 및 실적 발표 기록 분석을 제시한다. 50페이지 분량의 10-K, 10-Q 보고서나 어닝콜 트랜스크립트를 Claude에 넣는 방식이다. 또 같은 섹터의 경쟁사 두세 곳의 재무제표를 올려 매출 성장률, 매출총이익률, R&D 지출, 현금 전환 주기를 비교표로 구조화하도록 요청하는 경적(Comps) 벤치마킹을 소개한다. 이 밖에 투자 메모 초안 작성도 언급된다. 기사는 Anthropic의 S-1 자료와 IPO 일정(11월 19일로 예상)을 다루지만, 이 글 자체가 Anthropic 주식 매수를 권하는 것은 아니라고 명시한다. 또한 Opus 5.5 출시 이후 OpenRouter 기준 일일 토큰 트래픽이 여름 기준 약 0.6조 토큰에서 10월 7일 약 2.2조 토큰으로 늘었다는 수치를 제시한다.

재무 보고서(10-K, 10-Q)와 어닝콜 트랜스크립트를 Claude에 입력해 경쟁사 간 매출총이익률, R&D 지출, 현금 전환 주기를 비교표로 구조화하는 방식은 리서치 초안 작업에 바로 적용할 수 있다.

OpenAI 에이전트가 찾은 PHP·Brotli 취약점과 'Black October' 사이버 위협의 실제 전개

AI가 웹 기반 코드의 치명적 취약점(PHP, Brotli)을 찾아내면서 자동화 공격 우려가 커졌지만, 지난 한 주 수백만 건의 공격 시도 중 성공한 사례는 드물었다. 보안 업계는 이 상황을 Y2K 사태에 빗대며, AI 기반 해킹이 여전히 심각한 위협이라고 경고하고 있다. 보안 연구자들에 따르면 PHP 취약점은 작동하는 공격 코드를 만드는 것이 이례적으로 어려워 실제 공격으로 이어지지 않았다. 기사에 따르면 PHP는 전체 웹사이트의 약 70%가 사용하는 소프트웨어이며, OpenAI의 에이전트가 PHP와 널리 쓰이는 데이터 압축 라이브러리 Brotli에서 치명적 결함을 발견했다. 한편 AI 코딩 에이전트 OpenCode, 개발자 플랫폼 Railway, AI 게이트웨이 LiteLLM에서 발생한 침해로 고객의 API 키와 기타 자격 증명이 위험에 노출되었다. 기사는 AI가 발견한 버그의 양이 많아 앞으로 사이버 보안은 탐지·격리·복구 속도가 중심이 될 것이라고 전한다. Rubrik CEO Bipul Sinha는 누구도 100% 안전하지 않다고 경고했고, GuidePoint Security의 Justin Timothy는 다요소 인증 같은 기본 원칙을 강화할 것을 권했다. Armadin의 Samantha Lewis는 다음 취약점 공개 전에 자체 시스템을 선제적으로 점검하라고 조언했으며, 기사 속 Rob Joyce는 'vulpocalypse에서 breachpocalypse로의 전환'이 이미 시작되었다고 밝혔다.

PHP(웹사이트 약 70% 사용)와 Brotli 취약점, 그리고 LiteLLM의 API 키 노출 사례를 기준으로 자사 서비스의 의존성과 자격 증명 관리 상태를 점검할 필요가 있다.