AI 데일리 브리핑 — 2026-11-09

기준 시점: 2026-11-09 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-11-08 06:00 ~ 2026-11-09 06:00 KST
추천 글 범위: 2026-11-02 06:00 ~ 2026-11-09 06:00 KST

---

1️⃣ 주요 모델·연구

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

2️⃣ AI 제품·서비스

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

3️⃣ 개발 도구·에이전트

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

4️⃣ 산업·정책·안전

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

📚 추천 글

Inside GitHub’s new Git storage architecture

• 저자: Karthik Raman, Brian Celenza
• 발행: GitHub Engineering Blog
• 게시일: 2026-11-05
• 원문: GitHub — Inside GitHub's new Git storage architecture

---

AI 코딩 에이전트가 발전하면서 소프트웨어 개발의 작업량도 달라지고 있다.

과거에는 개발자가 코드를 작성한 뒤 Git 저장소에 변경사항을 푸시하는 방식이 일반적이었다.

하지만 여러 AI 코딩 에이전트가 동시에 작업하는 환경에서는 상황이 복잡해진다.

예를 들어 하나의 프로젝트에서 에이전트 100개가 서로 다른 기능을 개발한다고 가정해 보자.

각 에이전트는 코드를 수정하고 테스트한 뒤 변경사항을 Git 저장소에 푸시할 수 있다.

또한 다른 에이전트가 작성한 코드를 읽거나 최신 브랜치의 상태를 확인해야 할 수도 있다.

이런 작업이 하루 종일 반복된다면 Git 서버가 처리해야 하는 요청의 수는 크게 증가할 수 있다.

GitHub가 공개한 이번 글은 이러한 변화에 대응하기 위해 Git 저장소의 저장과 읽기, 쓰기 작업을 처리하는 구조를 어떻게 재설계했는지 설명한다.

특히 AI 모델의 추론 성능이 아니라 AI 에이전트가 대규모로 코드를 작성할 때 필요한 기반 인프라에 초점을 맞춘다는 점에서 읽어볼 가치가 있다.

하나의 저장소에 초당 7,200번 푸시

GitHub는 새로운 Git 저장 아키텍처를 내부적으로 시험했다.

공개된 결과에 따르면 하나의 저장소에서 다음 규모의 작업을 처리할 수 있었다.

이는 GitHub의 내부 시험에서 측정한 결과다.

모든 일반 사용자의 저장소가 현재 동일한 처리량을 제공한다는 의미는 아니다.

하지만 새로운 구조가 어떤 문제를 해결하려는지 이해하기에는 충분한 수치다.

GitHub에 따르면 현재 가장 바쁜 저장소에서도 실제 쓰기 작업은 일반적으로 초당 수십 건 수준이다.

그러나 AI 에이전트가 지속적으로 코드를 생성하고 푸시한다면 이런 작업량이 증가할 수 있다.

또한 하나의 푸시가 추가적인 읽기 요청을 발생시킨다.

예를 들어 새로운 커밋이 추가되면 CI 시스템이 해당 코드를 가져올 수 있다.

CI(Continuous Integration)는 코드 변경사항을 자동으로 빌드하고 테스트하는 과정이다.

다른 에이전트도 최신 코드를 가져와 자신의 작업을 계속할 수 있다.

배포 시스템 역시 새로운 버전을 확인할 수 있다.

따라서 쓰기 요청이 증가하면 읽기 요청도 함께 증가할 수 있다.

GitHub는 실제로 가장 바쁜 저장소 가운데 하나에서 일일 요청량이 2026년 3월 약 4,400만 건에서 5월 약 1억8,100만 건으로 증가한 사례를 소개했다.

Git에서 정말 순서를 보장해야 하는 정보는 무엇일까?

새로운 아키텍처의 출발점은 Git 데이터의 특성이다.

Git은 파일의 변경사항과 프로젝트의 이력을 여러 종류의 객체로 저장한다.

대표적인 객체에는 커밋과 트리, 파일의 내용 등이 있다.

중요한 특징은 Git 객체가 불변(Immutable)이라는 점이다.

불변 객체는 한번 만들어지면 기존 내용을 직접 수정하지 않는 데이터다.

예를 들어 특정한 커밋을 생성한 뒤 그 커밋의 내용을 변경하는 것이 아니라 새로운 커밋을 생성하는 방식이다.

따라서 서로 다른 개발자나 에이전트가 새로운 Git 객체를 저장하는 작업은 상당 부분 동시에 수행할 수 있다.

반면 브랜치의 참조 정보(Reference)는 다르다.

예를 들어 main 브랜치가 어떤 커밋을 가리키는지 나타내는 정보는 새로운 푸시가 발생할 때 변경될 수 있다.

두 에이전트가 동시에 main 브랜치를 변경하려 한다면 어느 변경사항을 먼저 적용해야 하는지 결정해야 한다.

이처럼 여러 작업 사이에서 하나의 일관된 순서를 유지하는 것을 동시성 제어(Concurrency Control)라고 한다.

GitHub는 이 차이에 주목했다.

전체 저장소의 쓰기 작업을 하나의 순서로 처리할 필요는 없다.

실제로 순서를 보장해야 하는 부분은 상대적으로 작은 브랜치 참조 정보의 변경이라는 것이다.

Ref-CAS: 브랜치 참조만 조정

GitHub는 이 문제를 해결하기 위해 Ref-CAS라는 구성요소를 도입했다.

CAS는 Compare-and-Swap의 약자다.

기존 값이 예상한 값과 일치할 때만 새로운 값으로 변경하는 연산을 의미한다.

예를 들어 main 브랜치가 커밋 A를 가리키고 있다고 가정해 보자.

에이전트 1은 브랜치를 커밋 B로 변경하려 한다.

에이전트 2는 동시에 커밋 C로 변경하려 한다.

두 에이전트가 모두 기존 값이 A라는 가정으로 변경을 요청했다면 첫 번째 변경이 성공한 뒤 두 번째 변경은 실패하거나 다시 검토해야 한다.

이를 통해 한쪽의 변경사항이 다른 쪽의 작업을 조용히 덮어쓰는 문제를 줄일 수 있다.

Ref-CAS는 이런 참조 변경을 처리한다.

반면 실제 Git 객체의 저장은 별도의 시스템에서 수행할 수 있다.

이렇게 하면 Git 객체를 저장하는 작업과 브랜치 상태를 변경하는 작업이 서로를 불필요하게 기다리는 시간을 줄일 수 있다.

GitHub는 Ref-CAS의 변경 기록에 순서 번호를 부여한다.

이를 LSN(Log Sequence Number)이라고 한다.

LSN은 여러 참조 변경사항의 순서를 추적하는 데 사용된다.

또한 여러 서버가 동일한 변경 기록을 보유하도록 하는 복제 구조를 사용한다.

Azure Blob Storage와 Virtual Replica

새로운 구조에서는 Git 객체를 Azure Blob Storage에 저장한다.

Object Storage(객체 스토리지)는 파일과 데이터를 개별 객체로 저장하고 식별자를 통해 접근하는 저장 방식이다.

GitHub는 이미 대부분의 저장소를 Azure 기반 인프라로 이전하는 작업을 진행해 왔다.

새로운 구조에서는 실제 데이터를 저장하는 시스템과 요청을 처리하는 서버를 분리한다.

이를 Storage-Compute Disaggregation(저장과 계산 자원의 분리)이라고 한다.

기존에는 하나의 서버가 저장소의 데이터를 보유하면서 읽기와 쓰기 요청을 함께 처리할 수 있었다.

하지만 새로운 구조에서는 실제 데이터가 별도의 저장 서비스에 존재한다.

요청을 처리하는 서버는 필요한 데이터와 메타데이터를 불러와 작업을 수행한다.

GitHub는 이런 서버를 Virtual Replica(가상 복제본)라고 부른다.

가상 복제본은 필요에 따라 생성하거나 제거할 수 있다.

따라서 읽기 요청이 급격하게 증가하면 요청을 처리할 서버를 추가하는 방식으로 대응할 수 있다.

저장소 정리 작업도 별도 시스템으로 분리

Git 저장소는 오랫동안 사용하면 많은 객체와 데이터 묶음이 생성된다.

Git은 효율적인 저장을 위해 여러 객체를 Packfile(팩파일)이라는 형태로 묶는다.

하지만 작은 팩파일이 너무 많이 만들어지면 데이터를 읽거나 관리하는 작업이 비효율적일 수 있다.

이를 해결하기 위해 Compaction(압축·통합 작업)이 필요하다.

여러 데이터 묶음을 더 효율적인 형태로 합치는 과정이다.

새로운 GitHub 아키텍처에서는 이런 작업도 읽기와 쓰기 요청을 처리하는 서버에서 분리했다.

별도의 작업자가 데이터 정리와 통합을 수행한다.

이렇게 하면 저장소를 정리하는 작업 때문에 실제 코드 푸시나 가져오기 요청이 불필요하게 지연되는 상황을 줄일 수 있다.

또한 더 이상 참조되지 않는 객체를 정리하는 Garbage Collection(가비지 컬렉션)도 별도로 관리한다.

아직 모든 저장소에 적용된 것은 아니다

GitHub는 이번 아키텍처를 제한된 비공개 프리뷰 형태로 제공하고 있다.

더 넓은 범위의 제공은 2027년 초를 목표로 하고 있다.

따라서 현재 GitHub의 모든 저장소가 새로운 구조를 사용한다고 판단해서는 안 된다.

또한 초당 7,200회의 푸시는 내부 시험 결과이므로 실제 사용자의 네트워크와 저장소 크기, CI 작업 등에 따라 처리 성능이 달라질 수 있다.

이번 글은 AI 코딩 에이전트가 늘어날수록 언어모델의 성능뿐 아니라 Git과 같은 기존 개발 인프라의 구조도 다시 설계해야 할 수 있다는 점을 보여준다.

특히 불변 데이터와 변경 가능한 메타데이터를 분리하고, 실제로 순서가 필요한 작업에만 동시성 제어를 적용하는 설계는 다른 대규모 시스템에도 참고할 수 있다.

---

Formally verifying agent-written full-stack web apps with PDD Kit

• 저자: Alex Lavaee, Matthai Philipose
• 발행: Microsoft Research
• 게시일: 2026-11-05
• 원문: Microsoft Research — Formally verifying agent-written full-stack web apps with PDD Kit

---

AI 코딩 에이전트가 작성한 코드의 정확성을 어떻게 검증해야 할까?

일반적인 소프트웨어 개발에서는 개발자가 코드를 작성하고 테스트를 실행한다.

하지만 AI 에이전트가 짧은 시간 동안 수천 줄의 코드를 생성한다면 모든 줄을 사람이 직접 검토하기 어려울 수 있다.

또한 AI가 작성한 테스트가 통과했다는 사실만으로 실제 요구사항을 모두 만족한다고 판단할 수는 없다.

예를 들어 사용자가 로그인 기능을 만들어 달라고 요청했다고 가정해 보자.

AI는 로그인 API와 비밀번호 검사 코드를 작성한다.

이후 잘못된 비밀번호로 로그인할 수 없는지 테스트할 수 있다.

하지만 테스트에 포함되지 않은 다른 입력에서 문제가 발생할 가능성이 있다.

더 중요한 문제도 존재한다.

AI가 원래 요구사항을 잘못 이해했다면 테스트도 잘못 이해한 내용을 기준으로 작성할 수 있다.

Microsoft Research의 이번 글은 이런 문제를 해결하기 위한 PDD Kit를 소개한다.

PDD는 Proof-Driven Development(증명 기반 개발)의 약자다.

일반적인 테스트에 더해 코드가 특정한 요구사항을 모든 가능한 입력에 대해 만족한다는 사실을 수학적으로 증명하는 개발 방식이다.

테스트가 통과해도 요구사항을 만족하지 않을 수 있다

예를 들어 개발자가 다음과 같은 로그인 규칙을 제시했다고 가정해 보자.

올바른 비밀번호를 입력한 사용자에게만 인증 토큰을 발급한다.

언뜻 보면 명확한 요구사항처럼 보인다.

하지만 수학적으로 표현하면 두 가지 해석이 가능하다.

첫 번째는 인증 토큰이 발급됐다면 비밀번호가 올바르다는 것이다.

두 번째는 비밀번호가 올바르다면 인증 토큰이 반드시 발급된다는 것이다.

두 조건은 서로 다르다.

첫 번째 조건만 적용하면 모든 로그인 요청을 무조건 거부하는 프로그램도 요구사항을 만족할 수 있다.

인증 토큰을 한 번도 발급하지 않으므로 잘못된 비밀번호에 토큰이 발급되는 일도 발생하지 않기 때문이다.

하지만 사용자가 실제로 원하는 기능은 아니다.

정상적인 비밀번호로 로그인한 사용자는 인증 토큰을 받아야 한다.

따라서 두 조건을 함께 명시해야 한다.

이처럼 자연어로 작성한 요구사항에는 여러 해석이 존재할 수 있다.

PDD Kit는 이런 애매한 부분을 실제 구현 이전에 발견하려 한다.

먼저 사람과 AI가 요구사항을 명확하게 정의

PDD Kit는 개발자가 처음부터 수학적 증명을 직접 작성하도록 요구하지 않는다.

먼저 사용자의 자연어 요청을 분석한다.

이후 애매하거나 누락된 조건을 질문한다.

예를 들어 로그인 기능에서는 다음과 같은 조건을 확인할 수 있다.

• 잘못된 비밀번호를 입력하면 토큰을 발급하지 않는가?
• 올바른 비밀번호를 입력하면 항상 토큰을 발급해야 하는가?
• 일반 사용자와 관리자에게 서로 다른 권한이 적용되는가?
• 이미 만료된 계정은 어떻게 처리하는가?

이런 질문을 통해 실제 요구사항을 명확하게 만든다.

이후 사람이 해당 내용을 승인한다.

PDD Kit는 승인된 요구사항 가운데 수학적으로 표현할 수 있는 부분을 Formal Specification(형식 명세)으로 변환한다.

형식 명세는 프로그램이 만족해야 하는 조건을 논리적·수학적으로 표현한 문서다.

중요한 점은 AI가 코드를 작성하기 전에 사람이 실제로 원하는 동작을 확인한다는 것이다.

Verus로 Rust 코드 검증

PDD Kit는 Verus라는 도구를 사용한다.

Verus는 Rust 프로그램이 정해진 수학적 조건을 만족하는지 검증하도록 지원하는 시스템이다.

Rust는 메모리 안전성과 성능에 초점을 맞춘 프로그래밍 언어다.

Microsoft Research는 GitHub Next의 Chopin이라는 개발 환경에서 PDD Kit를 시험했다.

연구팀이 사용한 예제는 Pet Store라는 웹 애플리케이션이다.

이 애플리케이션에는 약 5,000줄의 Rust 코드가 포함돼 있다.

백엔드는 Axum과 SQLite를 사용한다.

프런트엔드는 Leptos를 이용해 작성됐으며 WebAssembly로 실행된다.

WebAssembly는 웹브라우저를 포함한 여러 실행 환경에서 프로그램을 효율적으로 실행하도록 만든 바이너리 형식이다.

연구팀은 이 애플리케이션의 로그인 관련 로직을 검증했다.

PDD Kit는 사람이 승인한 명세를 바탕으로 Verus 증명을 생성했다.

이후 실제 코드가 해당 명세를 만족하는지 검사했다.

그 과정에서 기존 코드의 문제도 발견하고 수정했다.

수학적 증명과 일반적인 테스트의 차이

일반적인 테스트는 특정한 입력에 대해 프로그램을 실행한 뒤 결과를 확인한다.

예를 들어 올바른 비밀번호와 잘못된 비밀번호를 각각 입력해 볼 수 있다.

하지만 실제 입력 가능한 문자열의 수는 매우 많다.

모든 문자열을 실제로 입력해 보는 것은 현실적으로 어렵다.

반면 형식 검증은 프로그램의 동작을 수학적으로 분석한다.

증명이 성공하면 명세에 포함된 속성이 해당 프로그램의 모든 가능한 입력에 대해 성립한다는 근거를 얻을 수 있다.

하지만 이것이 프로그램에 모든 종류의 오류가 없다는 의미는 아니다.

형식 검증은 명세에 작성된 속성에 대해서만 보장한다.

예를 들어 로그인 토큰의 발급 조건을 증명했다고 해도 웹페이지의 디자인이 올바른지까지 증명한 것은 아니다.

또한 외부 데이터베이스와 네트워크, 암호화 라이브러리가 실제로 명세대로 동작하는지는 별도의 문제다.

모든 프로그램을 증명할 수 있는 것은 아니다

PDD Kit는 모든 코드에 형식 검증을 강제하지 않는다.

일부 기능은 실제 실행을 통한 테스트로 검증한다.

예를 들어 브라우저의 화면 동작이나 외부 라이브러리의 실제 실행 결과는 일반적인 테스트가 더 적절할 수 있다.

연구팀은 이를 Trusted Computing Base(TCB)라는 개념으로 설명한다.

TCB는 증명 과정에서 올바르게 동작한다고 가정하는 구성요소의 범위다.

예를 들어 외부 암호화 라이브러리의 동작을 신뢰한다고 가정할 수 있다.

하지만 해당 라이브러리 자체가 잘못 구현됐다면 이를 사용하는 프로그램의 형식 증명만으로 문제를 발견하지 못할 수 있다.

따라서 PDD Kit는 어떤 구성요소를 수학적으로 검증했고 어떤 부분을 일반적인 테스트로 확인했는지 구분한다.

또한 증명에서 신뢰한다고 가정한 외부 구성요소를 명시적으로 기록하도록 한다.

이런 구분은 중요한 의미가 있다.

수학적으로 검증된 부분과 아직 실제 테스트에 의존하는 부분을 명확하게 구분할 수 있기 때문이다.

AI 코딩 에이전트의 시대에 필요한 검증 방식

이번 연구는 코딩 에이전트가 작성한 모든 코드를 사람이 한 줄씩 검토하지 않아도 되는 방법을 탐색한다.

하지만 PDD Kit가 사람의 검토를 완전히 대체한다고 주장하는 것은 아니다.

실제로 어떤 기능을 만들어야 하는지와 어떤 속성이 중요한지는 여전히 사람이 결정해야 한다.

또한 형식 명세가 실제 사용자 요구사항과 일치하는지도 확인해야 한다.

이번 발표는 AI 코딩 에이전트의 능력이 발전할수록 코드를 생성하는 속도뿐 아니라 생성한 코드가 실제 요구사항을 만족하는지 검증하는 능력이 중요해진다는 점을 보여준다.

특히 인증과 접근권한처럼 잘못 구현됐을 때 피해가 큰 기능에서는 이런 접근이 유용할 수 있다.

---

Why We Built Design Creativity Bench: Measuring What AI Coding Benchmarks Miss

• 저자: Mukund Mohan, Sourabh Upreti
• 발행: Kombai / Hugging Face Community
• 게시일: 2026-11-02
• 원문: Hugging Face — Why We Built Design Creativity Bench

---

최근 AI 코딩 에이전트는 웹사이트와 애플리케이션을 매우 빠르게 생성할 수 있다.

예를 들어 사용자가 관리자 페이지를 만들어 달라고 요청하면 AI가 React 컴포넌트와 CSS를 작성할 수 있다.

필요한 버튼과 표, 검색 기능을 구현할 수도 있다.

그런데 실제 결과물을 비교하면 이상한 점이 나타날 수 있다.

서로 다른 AI 모델에 같은 작업을 요청했는데도 비슷한 레이아웃과 색상, 카드 구조를 사용하는 경우가 있다.

또한 같은 모델에 서로 다른 업종의 서비스를 만들어 달라고 요청해도 화면의 전체적인 구조가 크게 달라지지 않을 수 있다.

이번 글은 이런 현상을 평가하기 위한 Design Creativity Bench(DCB)의 개발 과정과 실험 결과를 설명한다.

특히 웹사이트가 정상적으로 작동하는지뿐 아니라 AI가 실제로 얼마나 다양한 디자인을 만들어내는지를 평가한다는 점에서 흥미롭다.

기존 코딩 벤치마크는 디자인의 창의성을 직접 평가하지 않는다

일반적인 코딩 벤치마크에서는 프로그램이 정해진 기능을 구현했는지 확인한다.

예를 들어 로그인 버튼이 실제로 동작하는지 검사할 수 있다.

또는 데이터베이스에서 올바른 정보를 조회하는지 확인할 수 있다.

하지만 두 웹사이트가 모두 정상적으로 작동하더라도 디자인은 다를 수 있다.

한쪽은 사용자의 작업 흐름을 고려해 정보를 배치했을 수 있다.

다른 쪽은 흔히 사용하는 관리자 페이지의 구조를 그대로 반복했을 수 있다.

Kombai는 이런 차이를 분석하기 위해 새로운 평가 기준을 만들었다.

실험에는 15개 프런티어 AI 모델이 참여했다.

연구팀은 80개 UI 작업을 준비했다.

각 작업을 서로 다른 두 종류의 제품 분야에 적용해 총 160개의 디자인 요구사항을 만들었다.

최종적으로 2,400개의 HTML 인터페이스를 생성했다.

또한 같은 요구사항을 바탕으로 사람이 작성한 참고 디자인도 준비했다.

같은 작업이라도 업종에 따라 화면이 달라져야 한다

예를 들어 기술자의 작업 일정을 관리하는 화면을 생각해 보자.

가정용 가전제품을 수리하는 회사에서는 고객의 주소와 방문 시간, 담당 기술자의 연락처가 중요할 수 있다.

반면 대형 건물의 냉난방 설비를 관리하는 회사에서는 여러 명의 기술자가 하나의 작업을 수행할 수 있다.

건물의 출입 제한 시간과 정기 점검 일정도 중요할 수 있다.

두 서비스 모두 기술자의 작업을 배정한다는 점에서는 같다.

하지만 실제로 사용자가 필요로 하는 정보와 작업 흐름은 다르다.

따라서 좋은 디자인이라면 이런 차이를 화면의 구조에 반영해야 한다.

단순히 회사 이름과 색상만 바꾸는 것으로는 충분하지 않을 수 있다.

Kombai는 이런 차이를 평가하기 위해 세 가지 지표를 만들었다.

독창성과 다양성, 요구사항 충족을 분리

평가 기준은 다음과 같다.

Originality(독창성)는 같은 작업을 수행한 다른 모델의 결과물과 얼마나 다른지 평가한다.

Creative Range(창의적 범위)는 같은 모델이 서로 다른 제품 분야에서 얼마나 다양한 디자인을 생성하는지 평가한다.

Appropriateness(적절성)는 실제 요구사항을 얼마나 충족하는지 평가한다.

중요한 점은 세 지표를 구분했다는 사실이다.

예를 들어 모든 요구사항을 만족한 웹사이트라도 다른 모델의 디자인과 거의 같을 수 있다.

반대로 매우 독특한 디자인을 만들었더라도 사용자가 필요한 버튼이나 정보를 누락했다면 좋은 결과라고 보기 어렵다.

따라서 단순히 다른 디자인을 만들었다는 사실만으로 높은 평가를 주지 않는다.

실제 HTML을 브라우저에서 렌더링해 비교

연구팀은 모델이 생성한 HTML 코드를 실제 브라우저에서 렌더링했다.

Rendering(렌더링)은 HTML과 CSS 등의 데이터를 사용자가 볼 수 있는 화면으로 변환하는 과정이다.

이후 화면을 여러 구조적 영역으로 나누어 비교했다.

예를 들어 상단 내비게이션과 사이드바, 표와 카드의 배치 등을 분석할 수 있다.

이 과정에서는 Embedding(임베딩)이 사용됐다.

임베딩은 이미지나 문서의 특징을 여러 숫자로 표현한 것이다.

비슷한 특징을 가진 결과물은 임베딩 공간에서도 가까운 위치에 나타날 수 있다.

Kombai는 디자인의 구조적 유사성에 90%, 색상 체계에 10%의 가중치를 부여했다.

이렇게 하면 단순히 색상만 변경한 디자인이 완전히 새로운 결과물로 평가되는 문제를 줄일 수 있다.

연구팀은 사람이 직접 비교한 평가와 자동 채점기의 결과도 비교했다.

하나의 비교 집합에서는 82.5%의 일치율을 기록했다.

별도의 평가 집합에서는 AUC 0.85를 기록했다.

AUC는 분류 모델이 서로 다른 대상을 얼마나 잘 구분하는지 평가하는 지표다.

하지만 이 수치가 채점기의 모든 판단이 사람의 디자인 평가와 일치한다는 의미는 아니다.

AI는 요구사항을 잘 지키지만 디자인은 비슷했다

공개된 평균 결과는 다음과 같다.

AI 모델들은 요구사항을 상당히 잘 만족했다.

예를 들어 Claude Opus 5.5는 필수 요구사항의 99.2%를 충족했다.

사람이 작성한 참고 디자인의 98.0%보다 높은 수치다.

하지만 디자인의 독창성과 다양성에서는 다른 결과가 나타났다.

같은 요구사항으로 생성한 AI 모델들의 디자인은 서로 상당히 비슷했다.

또한 제품 분야가 달라져도 기존 디자인의 구조를 반복하는 경향이 있었다.

AI가 실제 기능을 잘 구현하는 능력과 새로운 디자인을 탐색하는 능력은 서로 다를 수 있다는 것이다.

창의성 점수가 높다고 반드시 좋은 디자인은 아니다

이번 연구에서 중요한 제한은 독창성과 미적 완성도를 구분해야 한다는 점이다.

예를 들어 어떤 AI가 다른 모델과 완전히 다른 디자인을 만들었다고 가정해 보자.

독창성 점수는 높을 수 있다.

하지만 실제 사용자는 해당 디자인이 불편하다고 느낄 수도 있다.

또한 접근성 기준을 충족하지 못할 가능성도 있다.

Accessibility(접근성)는 장애 여부와 사용 환경에 관계없이 사람들이 제품을 사용할 수 있도록 설계하는 원칙이다.

예를 들어 키보드만으로 화면을 조작할 수 있어야 하거나 글자와 배경 사이의 대비가 충분해야 할 수 있다.

DCB는 이런 모든 품질을 하나의 점수로 평가하는 벤치마크가 아니다.

또한 독창성 점수는 평가에 참여한 다른 모델들과의 비교에 영향을 받는다.

따라서 새로운 모델이 평가에 추가되면 결과가 달라질 수 있다.

Kombai는 전체 2,400개 결과 가운데 일부인 300개 HTML 디자인을 공개했다.

외부 연구자는 공개된 자료를 이용해 디자인의 유사성과 평가 방법을 추가로 검토할 수 있다.

이번 글은 AI가 만든 웹사이트를 평가할 때 기능 구현의 정확성뿐 아니라 실제 서비스의 맥락에 맞는 정보 구조와 디자인의 다양성도 중요하다는 점을 보여준다.

특히 AI 코딩 도구를 이용해 프런트엔드를 개발하는 사람이라면 기능이 완성됐다는 이유만으로 디자인 검토까지 끝났다고 판단해서는 안 된다는 점을 생각해 볼 수 있다.

---

Sand3D: 106,094 3D objects in one code substrate for language models

• 저자: Thibault Neveu
• 발행: Sandflow / Hugging Face Community
• 게시일: 2026-11-05
• 원문: Hugging Face — Sand3D: 106,094 3D objects in one code substrate for language models

---

AI가 텍스트와 이미지를 생성하는 능력은 빠르게 발전하고 있다.

하지만 실제 3D 물체를 생성하거나 수정하는 작업은 여전히 복잡하다.

예를 들어 AI에게 의자 하나를 설계하도록 요청했다고 가정해 보자.

의자에는 다리와 좌판, 등받이가 존재한다.

사용자가 의자의 높이를 변경하고 싶다면 전체 물체를 새로 생성할 필요는 없을 수 있다.

다리의 길이를 변경하면 된다.

또한 등받이의 각도를 조정하거나 특정한 부품을 제거할 수도 있다.

하지만 일반적인 3D 모델이 수많은 삼각형의 좌표로 표현돼 있다면 이런 작업이 어려울 수 있다.

AI가 어떤 삼각형이 의자의 다리에 해당하는지 직접 파악해야 하기 때문이다.

Sandflow의 Sand3D는 이런 문제를 해결하기 위해 개발됐다.

3D 물체를 단순한 표면 좌표가 아니라 이름과 크기, 부품 사이의 관계를 가진 프로그램으로 표현하는 방식이다.

10만6천 개 이상의 3D 물체

이번 공개에는 총 106,094개 3D 물체가 포함됐다.

여러 공개 3D 데이터셋의 자료를 하나의 공통 형식으로 변환했다.

여기에는 가구와 기계 부품, 도구와 생활용품 등이 포함된다.

또한 10,456개는 실제 관절 구조를 가진 물체다.

예를 들어 문이 열리는 캐비닛이나 움직이는 기계 부품을 생각할 수 있다.

이런 물체에서는 각 부품의 형태뿐 아니라 부품이 어떤 방향으로 움직일 수 있는지도 중요하다.

Sand3D는 이런 정보를 구조화된 프로그램으로 표현한다.

일반적인 3D 파일과 무엇이 다른가

일반적인 3D 모델은 Mesh(메시)라는 구조로 표현될 수 있다.

메시는 물체의 표면을 여러 점과 삼각형으로 나눈 데이터다.

예를 들어 의자의 표면을 수천 개의 삼각형으로 표현할 수 있다.

이런 방식은 물체를 화면에 표시하는 데 유용하다.

하지만 실제로 의자의 다리와 좌판이 어떤 관계를 가지는지 명시하지 않을 수 있다.

반면 Sand3D는 물체를 여러 부품으로 구분한다.

각 부품에는 이름이 존재한다.

크기와 위치도 별도의 변수로 표현한다.

또한 어떤 부품이 다른 부품에 연결되는지 구조화한다.

예를 들어 의자의 전체 높이를 변경하려면 관련된 변수의 값을 변경할 수 있다.

이후 프로그램을 다시 실행해 새로운 3D 물체를 생성한다.

이런 방식을 Procedural Modeling(절차적 모델링)이라고 한다.

물체의 표면을 직접 수정하는 대신 프로그램과 규칙을 이용해 형상을 만드는 방식이다.

AI가 이해하기 쉬운 코드 구조

이번 연구에서 흥미로운 부분은 AI가 코드를 작성하는 순서까지 고려해 라이브러리를 설계했다는 점이다.

일반적인 Python 프로그램에서는 여러 상수와 보조 함수를 먼저 정의한 뒤 마지막에 전체 객체를 생성할 수 있다.

하지만 언어모델은 보통 코드를 앞에서부터 순서대로 생성한다.

따라서 실제로 어떤 물체를 만들지 결정하기 전에 세부적인 수치를 먼저 작성해야 하는 상황이 발생할 수 있다.

Sand3D는 이 순서를 바꿨다.

먼저 전체 물체를 구성하는 부품을 목록처럼 선언한다.

이후 각 부품의 세부적인 형상을 정의한다.

예를 들어 운동기구의 무게추 장치를 만든다고 가정해 보자.

먼저 무게추와 가이드 봉, 선택 핀 등이 존재한다는 사실을 정의한다.

이후 각 부품의 실제 크기와 위치를 작성한다.

이렇게 하면 모델이 전체 구조를 먼저 계획하고 필요한 세부사항을 채워 넣을 수 있다.

또한 작업이 완료됐는지 판단하기 쉬워진다.

처음에 정의한 모든 부품의 구현이 끝났다면 전체 물체의 구성이 완료됐다고 판단할 수 있기 때문이다.

기존 Blender Python보다 짧은 코드

Sandflow는 30개의 CAD 부품을 대상으로 간단한 비교도 수행했다.

그 결과 Sand3D로 사람이 작성한 코드는 언어모델이 작성한 Blender Python 코드보다 평균 3.8배 적은 토큰을 사용했다.

토큰(Token)은 언어모델이 텍스트를 처리하는 기본 단위다.

코드가 짧아지면 모델이 처리해야 하는 입력과 출력의 양을 줄일 수 있다.

또한 사람이 프로그램을 읽고 수정하기 쉬워질 수 있다.

하지만 여기에는 중요한 제한이 있다.

비교 대상은 사람이 작성한 Sand3D 코드와 AI가 작성한 Blender 코드였다.

따라서 모든 AI 모델이 Sand3D를 사용하면 항상 3.8배 효율적으로 3D 물체를 생성한다고 판단해서는 안 된다.

실제 AI 모델이 Sand3D를 이용해 얼마나 정확한 물체를 생성하는지는 별도의 학습과 평가가 필요하다.

기존 3D 데이터를 프로그램으로 재구성

Sandflow는 기존 3D 물체를 Sand3D 프로그램으로 변환하기 위해 자동화된 재구성 파이프라인을 사용했다.

Pipeline(파이프라인)은 입력 데이터를 여러 단계로 처리해 원하는 결과물을 생성하는 시스템이다.

각 3D 물체에 대해 원본의 형태를 분석하고 이를 재현하는 프로그램을 생성한다.

이후 생성한 프로그램을 실행해 실제 3D 모델을 다시 만든다.

마지막으로 원본과 새롭게 생성한 모델의 형태가 얼마나 비슷한지 평가한다.

여기에는 F-score라는 지표를 사용했다.

F-score는 원본 표면과 생성된 표면이 얼마나 일치하는지 평가하는 수치다.

Sandflow는 자료의 종류에 따라 최소 허용 기준을 다르게 설정했다.

예를 들어 일반적인 Objaverse 물체에는 0.70 기준을 적용했다.

반면 CAD 부품에는 0.90의 더 높은 기준을 적용했다.

관절을 가진 물체에서는 각 부품의 형태뿐 아니라 관절의 연결 관계도 검사했다.

하지만 F-score가 높은 물체라도 원본의 모든 세부 특징이 완벽하게 유지된다는 의미는 아니다.

예를 들어 작은 나사나 장식 요소가 누락될 수 있다.

실제 제조에 필요한 공차와 재질의 특성까지 자동으로 보장하는 것도 아니다.

로봇과 물리적 AI에 활용할 가능성

이번 데이터셋은 일반적인 3D 디자인뿐 아니라 로봇 AI 연구에서도 활용할 가능성이 있다.

예를 들어 로봇이 특정한 물체의 문을 열어야 한다고 가정해 보자.

실제 물체에는 손잡이와 경첩, 문짝이 존재한다.

각 부품이 어떻게 연결돼 있는지 이해하면 로봇의 행동을 계획하는 데 도움이 될 수 있다.

Sand3D는 이런 물체의 구조를 이름과 관절, 위치 관계로 표현한다.

따라서 AI 모델이 단순한 이미지나 표면 좌표보다 구조화된 정보를 학습하는 데 사용할 수 있다.

하지만 현재 공개된 데이터는 주로 가구와 기계, 도구처럼 단단한 표면을 가진 물체에 초점을 맞췄다.

사람과 동물, 복잡한 유기적 형태는 아직 충분히 지원하지 않는다.

또한 실제 물체의 무게와 마찰력, 재질의 변형까지 모두 표현하는 물리 시뮬레이터는 아니다.

공개 라이선스와 실제 사용 조건

Sand3D 라이브러리는 Apache 2.0 라이선스로 공개됐다.

데이터셋은 CC BY 4.0 조건으로 제공된다.

하지만 각 물체에 적용된 원본 데이터의 라이선스는 별도로 유지된다.

따라서 상업적 제품에서 실제 3D 물체를 사용하려면 해당 물체의 원본 라이선스도 확인해야 한다.

이번 글은 AI가 3D 환경을 이해하고 생성하기 위해 모델 자체의 성능뿐 아니라 데이터를 어떤 구조와 언어로 표현할 것인지가 중요하다는 점을 보여준다.

특히 물체를 수정 가능한 프로그램으로 표현하면 AI와 사람이 같은 자료를 이해하고 반복적으로 개선하기 쉬워질 수 있다는 점에서 흥미로운 접근이다.

---

CyberArena: Benchmarking AI Agents in Live Symmetric Attack-and-Defense Combat

• 저자: Bangya Liu, Yueyang Pan, Hanhong Zhao
• 발행: 2077AI / UC Berkeley RDI / Hugging Face Community
• 게시일: 2026-11-03
• 원문: Hugging Face — CyberArena: Benchmarking AI Agents in Live Symmetric Attack-and-Defense Combat

---

AI 보안 에이전트의 실제 능력을 어떻게 평가해야 할까?

일반적인 사이버보안 벤치마크에서는 AI에게 특정한 취약점이 존재하는 프로그램을 제공한다.

이후 해당 취약점을 발견하거나 문제가 실제로 발생하는지 확인하도록 요청할 수 있다.

하지만 실제 보안 환경은 정적인 문제가 아니다.

방어자는 공격을 발견하면 취약점을 수정할 수 있다.

공격자는 수정된 시스템을 분석해 다른 방법을 찾으려 할 수 있다.

또한 방어자가 보안 문제를 수정하는 과정에서 정상적인 서비스 기능을 중단시키는 상황도 발생할 수 있다.

따라서 단순히 취약점을 한 번 발견하는 능력만으로 실제 보안 업무의 전체적인 능력을 평가하기는 어렵다.

이번 글은 이런 문제를 해결하기 위해 개발된 CyberArena를 소개한다.

CyberArena는 두 AI 에이전트가 동시에 공격과 방어를 수행하는 동적인 보안 평가 환경이다.

고정된 시험 대신 실제로 변화하는 상대와 경쟁

일반적인 보안 평가에서는 공격 대상의 상태가 고정돼 있을 수 있다.

예를 들어 특정한 취약점이 존재하는 웹 애플리케이션을 제공한다.

AI가 해당 취약점을 발견하고 정해진 목표를 달성하면 성공으로 인정한다.

하지만 CyberArena에서는 상대방도 자신의 시스템을 수정할 수 있다.

두 에이전트에게 동일한 취약점을 가진 서비스를 각각 제공한다.

이후 각 에이전트에게 두 가지 목표를 부여한다.

첫 번째는 상대방의 시스템에서 정해진 목표를 달성하는 것이다.

두 번째는 자신의 시스템을 수정해 상대방의 행동을 방어하는 것이다.

모든 작업은 격리된 평가 환경에서 수행된다.

실제 외부 서비스나 승인되지 않은 시스템을 대상으로 공격하는 구조가 아니다.

평가에는 총 세 라운드가 포함된다.

각 라운드는 20분 동안 진행된다.

한 라운드가 끝나면 공격자가 달성해야 할 목표를 변경한다.

하지만 이전 라운드에서 방어자가 수정한 내용은 계속 유지된다.

따라서 방어자의 수정이 실제로 도움이 되는지와 공격자가 변경된 환경에 얼마나 잘 적응하는지 평가할 수 있다.

보안 문제를 해결하면서 정상적인 서비스도 유지해야 한다

이번 벤치마크에서 중요한 부분은 서비스의 정상적인 동작을 별도로 검사한다는 점이다.

예를 들어 웹 애플리케이션의 보안 문제를 수정하려 한다고 가정해 보자.

가장 단순한 방법은 프로그램 전체를 종료하는 것이다.

프로그램이 실행되지 않으면 해당 서비스를 통해 취약점을 악용하기도 어려울 수 있다.

하지만 실제 사용자도 서비스를 이용할 수 없게 된다.

따라서 올바른 보안 수정이라고 보기 어렵다.

CyberArena는 이런 문제를 방지하기 위해 별도의 상태 검사 프로그램을 사용한다.

이를 Health Poller(서비스 상태 검사기)라고 한다.

Health Poller는 웹 애플리케이션의 정상적인 기능이 유지되는지 반복해서 확인한다.

예를 들어 로그인과 데이터 조회 등 기본 기능이 계속 작동하는지 검사할 수 있다.

따라서 에이전트가 취약점을 차단했더라도 정상적인 서비스가 중단됐다면 평가에 불이익이 발생한다.

이런 구조는 실제 보안 업무의 특성을 더 잘 반영한다.

보안성을 높이는 것과 실제 서비스의 가용성을 유지하는 것이 모두 중요하기 때문이다.

466번의 실제 대결 평가

연구팀은 총 466번의 유효한 대결을 분석했다.

평가에는 12개의 고정된 모델·하네스 조합과 40개의 보안 과제가 사용됐다.

Harness(하네스)는 언어모델이 실제 프로그램을 실행하고 파일을 수정하도록 연결하는 소프트웨어 환경이다.

같은 모델을 사용하더라도 어떤 하네스를 연결하는지에 따라 실제 작업의 성공률이 달라질 수 있다.

연구팀이 공개한 대표적인 결과는 다음과 같다.

이번 평가에서는 GPT-5.6 Sol과 Codex를 결합한 구성이 가장 높은 점수를 기록했다.

하지만 두 모델의 점수 차이를 모든 실제 보안 업무에서의 일반적인 능력 차이로 해석해서는 안 된다.

실제 평가에는 특정한 보안 과제와 제한된 실행시간, 고정된 하네스가 사용됐다.

또한 이번 결과는 연구팀이 직접 설계하고 운영한 평가에서 얻어졌다.

모든 조건에서 독립적인 외부 검증이 완료된 것은 아니다.

좋은 공격 능력보다 방어 능력이 순위에 큰 영향

연구팀은 상위 모델들의 공격 목표 달성 비율이 비교적 비슷하다는 점을 발견했다.

하지만 방어 능력에서는 차이가 나타났다.

GPT-5.6 Sol은 약 83%의 라운드에서 자신의 목표물을 지켰다.

Claude Opus 5는 약 81%의 방어 성공률을 기록했다.

반면 다른 모델·하네스 조합들은 약 43~61% 수준이었다.

이는 CyberArena에서 좋은 점수를 얻으려면 취약점을 찾아내는 능력뿐 아니라 자신의 서비스에서 실제 문제를 수정하고 상대방의 행동에 대응하는 능력이 중요하다는 점을 보여준다.

또한 빠르게 수정하는 능력도 중요한 요소였다.

예를 들어 GPT-5.6 Sol의 첫 번째 서비스 재시작 시간 중앙값은 약 2.3분이었다.

다른 모델에서는 3.9~12.3분 수준의 시간이 필요했다.

하지만 빠르게 재시작했다는 사실만으로 실제 보안 문제가 해결됐다고 판단할 수는 없다.

실제 수정 결과를 별도로 검증해야 한다.

에이전트는 수정했다고 주장하지만 실제로는 해결하지 못할 수 있다

이번 연구에서 가장 흥미로운 부분은 실패한 사례에 관한 분석이다.

연구팀은 에이전트의 작업 기록을 검토하면서 여러 종류의 문제를 확인했다.

특히 자주 나타난 실패는 다음과 같다.

첫 번째는 에이전트가 실제로 검증하지 않고 취약점을 수정했다고 판단하는 상황이다.

예를 들어 코드의 일부를 변경한 뒤 테스트를 수행하지 않고 작업이 완료됐다고 설명할 수 있다.

두 번째는 특정한 입력이나 실행 경로에서만 문제를 해결하는 상황이다.

예를 들어 취약점이 발생하는 여러 조건 가운데 하나만 수정할 수 있다.

이런 경우 일부 테스트에서는 정상적으로 보일 수 있다.

하지만 다른 조건에서는 같은 취약점이 여전히 존재할 수 있다.

따라서 에이전트가 작업을 완료했다고 설명한 내용과 실제 시스템에서 확인된 결과를 구분해야 한다.

CyberArena는 이를 위해 에이전트의 최종 답변보다 실제 서비스의 상태와 공격·방어 결과를 기준으로 평가한다.

실제 기업 환경과의 차이

이번 벤치마크는 기존의 정적인 보안 평가보다 실제 공격과 방어의 상호작용을 더 많이 반영한다.

하지만 완전한 실제 기업 환경을 재현하는 것은 아니다.

예를 들어 기업의 네트워크에는 여러 종류의 접근권한과 보안 장비, 모니터링 시스템이 존재한다.

또한 실제 공격자는 평가에서 정해진 시간이나 목표에 반드시 따르지 않는다.

CyberArena에서는 제한된 과제와 격리된 서비스, 정해진 시간 안에서 에이전트의 능력을 비교한다.

따라서 이 벤치마크에서 높은 점수를 기록한 모델이 실제 기업의 모든 보안 업무를 안전하게 자동화할 수 있다는 의미는 아니다.

또한 공격과 방어가 동시에 수행되는 환경에서는 모델의 성능뿐 아니라 하네스의 도구 사용 방식과 작업 실행 전략도 영향을 준다.

이번 글은 AI 보안 에이전트의 능력을 평가할 때 취약점을 발견하는 능력과 실제로 수정하는 능력, 정상적인 서비스를 유지하는 능력을 함께 측정해야 한다는 점을 보여준다.

특히 평가 대상이 고정된 시험에서 벗어나 상대방의 행동에 따라 변화하는 환경으로 확대되고 있다는 점에서 흥미로운 연구다.