각주

[카테고리:] 기술

  • 웹 포인터 입력 표준, 7년 만에 개정 — Pointer Events Level 3가 W3C 권고안이 됐다

    2026년 6월 30일, W3C는 Pointer Events Level 3를 정식 권고안(Recommendation)으로 발행하면서 2019년 4월 4일자 권고안이던 Pointer Events 2를 대체(supersede)했다. 마우스·펜·터치스크린을 하나의 이벤트 체계로 다루는 웹 표준이 7년 2개월 만에 바뀐 것이다. 이번 판의 핵심은 펜의 기울기를 각도로 읽는 속성, 화면 주사율보다 빠른 입력을 다루는 새 이벤트, 그리고 지연을 줄이기 위한 예측 이벤트다. 원문 권고안과 이전 판 문서를 직접 열어 무엇이 달라졌는지 확인했다.

    항목

    내용

    자료

    Pointer Events Level 3 (W3C Recommendation)

    발행

    W3C Pointer Events Working Group, 2026년 6월 30일

    지위

    W3C 권고안(웹 기술 표준). 이전 판 Pointer Events 2(2019년 4월 4일 권고)를 대체

    대상

    웹 브라우저의 포인터 입력(마우스·펜·터치) 이벤트와 인터페이스

    기간

    이전 권고안(2019.4.4) 이후 약 7년 2개월 만의 개정판

    방법

    W3C 권고 트랙 표준화 절차. WPT 테스트 스위트와 구현 보고서(2026년 5월 6일자)를 근거로 진행

    무엇을 대체했나

    권고안의 상태(Status of This Document) 절은 이 문서가 Pointer Events 2의 개정판이며 그것을 대체한다고 명시한다("This revision of Pointer Events supersedes Pointer Events 2"). 실제로 이전 판 문서를 열어 보면 상단에 "권고안 2019년 4월 4일, 2026년 6월 30일 대체됨(Recommendation 4 April 2019, superseded 30 June 2026)"이라는 표시와 함께, 새 구현은 최신 판을 따르라는 안내가 붙어 있다. 편집자는 Patrick H. Lauke(TetraLogical)와 Robert Flack(Google)이다. W3C는 이 명세를 웹 표준으로 널리 배포할 것을 권고한다("W3C recommends the wide deployment of this specification as a standard for the Web")고 적었다.

    펜의 기울기를 각도로 읽는다

    새로 들어온 altitudeAngle(고도각)과 azimuthAngle(방위각) 속성은 스타일러스 펜이 화면에 대해 얼마나, 어느 방향으로 기울어 있는지를 라디안 값으로 알려준다. 속성 정의에 따르면 고도각의 범위는 0에서 π/2까지로, 0이면 펜이 화면과 평행하고 π/2면 수직이다. 방위각은 0에서 2π까지이며 시계 방향으로 증가한다. 기울기를 보고하지 않는 하드웨어에서는 고도각을 π/2, 방위각을 0으로 두도록 요구된다(MUST). 필기·드로잉 앱이 펜의 자세를 표준 API만으로 읽을 수 있게 된 것이다.

    초당 수백 번의 입력을 다루는 두 가지 장치

    디지타이저는 화면이 갱신되는 것보다 훨씬 자주 좌표를 보고한다. Level 3는 이를 두 방향에서 다룬다. 하나는 pointerrawupdate 이벤트다. 명세는 이 이벤트를 보안 컨텍스트(secure context) 안에서만 발생시키도록 하고, pointermove와 달리 "가능한 한 빨리, 자바스크립트가 처리할 수 있는 한 자주" 전달하도록 했다. 대신 경고도 명시돼 있다. "pointerrawupdate 리스너를 추가하면 페이지 성능에 부정적 영향을 줄 수 있다. 대부분의 용례에는 다른 포인터 이벤트로 충분하다(Adding listeners for the pointerrawupdate event might negatively impact the performance of the web page… For most use cases the other pointerevent types should suffice)."

    다른 하나는 병합·예측 이벤트다. 브라우저는 성능을 위해 여러 번의 이동을 하나의 pointermove로 합쳐 전달할 수 있는데, getCoalescedEvents()는 그렇게 합쳐진 원본 이동 목록을, getPredictedEvents()는 브라우저가 추정한 미래 좌표 목록을 돌려준다. 전자는 필기 궤적의 정밀도를, 후자는 체감 지연 축소를 겨냥한 장치다.

    click도 이제 PointerEvent다

    이번 판은 click, auxclick, contextmenu 이벤트의 타입을 PointerEvent로 규정했다(MUST). 포인팅 기기가 만든 경우에는 해당 포인터의 pointerId와 pointerType을 물려받고, 키보드처럼 포인터가 아닌 입력이 만든 경우에는 pointerId를 -1로, pointerType을 빈 값으로 둔다. 클릭이 어떤 종류의 입력에서 왔는지를 이벤트 객체만으로 구분할 수 있게 된다.

    이 자료가 말하지 않는 것

    표준 문서는 브라우저가 실제로 무엇을 구현했는지를 보증하지 않는다. 상태 절이 구현 보고서와 테스트 스위트(wpt.fyi)를 링크하고 있지만, 이번 확인에서 브라우저별 구현 현황 수치까지 열어 보지는 않았다. 예측 이벤트가 얼마나 정확한지는 명세가 아니라 각 브라우저의 구현에 달린 문제다. 또한 터치 스크롤 제어에 쓰이는 touch-action 속성 절(8장)의 세부 값 변화는 이번에 본문까지 확인하지 못했으므로 이 글에서 다루지 않았다.

    정리하면

    • 2026년 6월 30일 Pointer Events Level 3가 W3C 권고안이 됐고, 2019년 4월 4일자 Pointer Events 2는 같은 날 대체됨 표시가 붙었다.
    • altitudeAngle(0에서 π/2)과 azimuthAngle(0에서 2π) 속성으로 펜의 기울기와 방향을 표준 API로 읽을 수 있다.
    • pointerrawupdate는 보안 컨텍스트에서만 발생하며, 명세 자체가 성능 부담을 경고하고 있다.
    • getCoalescedEvents()와 getPredictedEvents()는 각각 병합된 원본 이동과 예측 좌표 목록을 돌려준다.
    • click·auxclick·contextmenu는 PointerEvent 타입이어야 하며, 비포인터 입력이면 pointerId가 -1이다.

    출처와 확인 범위

  • X.509 인증서에 MAC 주소를 담는 형식이 RFC로 나왔다 — RFC 10031, otherName 12번째 항목

    공개 키 인증서의 주체 대체 이름(SAN)에 IEEE MAC 주소를 옥텟 문자열로 담는 방법이 2026년 8월 RFC 10031로 발행됐다. 표준화 트랙의 Proposed Standard 단계다. 이 규격이 정의한 otherName 형식은 OID 1.3.6.1.5.5.7.8.12를 받아 IANA 레지스트리에 12번째 항목으로 등록됐다. 용도로는 사물인터넷과 차량 네트워크의 계층 2 인증을 든다. 정작 규격 자신은 보안 절에서 MAC 주소가 위조될 수 있다고 적어 둔다.

    원자료 제원

    항목

    내용

    자료

    RFC 10031 "Media Access Control (MAC) Addresses in X.509 Certificates"

    발행

    IETF / RFC Editor, 2026년 8월

    지위

    기술 규격 — 표준화 트랙의 Proposed Standard, IETF 스트림, LAMPS 워킹그룹 산출물. 원 초안 draft-ietf-lamps-macaddress-on-07

    대상

    본문 8개 장, 저자 5인, 새 OID 2개(이름 형식·ASN.1 모듈 식별자), 정규 참조 5건·참고 참조 2건

    기간

    해당 없음 — 기술 규격이라 자료가 다루는 기간 개념이 없다

    방법

    초록과 1장, 3장(3.4.2절 경로 검증 처리 제외), 4~8장, ASN.1 모듈을 읽고, 요구된 IANA 등록 두 건을 레지스트리 원본과 대조

    정확히 무엇을 정의했나

    X.509 인증서는 주체 대체 이름(SAN) 확장에 도메인 이름, 이메일 주소, IP 주소 등을 담는다. RFC 5280은 이 목록을 확장할 통로로 otherName을 열어 두었고, RFC 10031은 그 통로에 MAC 주소용 칸을 만들었다. 인코딩은 단순하다. EUI-48은 6옥텟, EUI-64는 8옥텟의 OCTET STRING으로 넣고 최상위 옥텟을 먼저 쓴다. 7.1절 예시 00-24-98-7B-19-02는 '0024987B1902'H가, 7.2절 AC-DE-48-00-11-22-33-44는 'ACDE480011223344'H가 된다. 구분 기호나 대소문자 규칙이 개입할 여지가 없다. 3.3절은 검증자가 옥텟 단위로 그대로 비교하도록 하고, 와일드카드는 지원하지 않는다고 못 박는다.

    6·8이 아닌 12·16옥텟이 함께 있는 이유

    ASN.1 타입은 MACAddress ::= OCTET STRING (SIZE (6 | 8 | 12 | 16))이다. 길이가 네 종류인 것은 같은 타입이 이름과 제약 조건 양쪽에 쓰이기 때문이다.

    길이

    쓰임

    구성

    6옥텟

    EUI-48 이름

    주소값

    8옥텟

    EUI-64 이름

    주소값

    12옥텟

    EUI-48 제약

    값 6 + 마스크 6

    16옥텟

    EUI-64 제약

    값 8 + 마스크 8

    매칭 규칙은 3.4.1절에 있다. 이름과 값 패턴을 배타적 논리합(XOR)한 뒤 마스크와 비트별 논리곱(AND)을 해서, 결과가 전부 0이면 통과다. 길이가 어긋나면 계산 전에 불일치로 끝난다.

    7.3절 예시가 이 구조를 보여준다. 값 패턴은 전부 0, 마스크는 030000000000이고, 규격은 이 제약이 전역(universal)이고 유니캐스트인 값만 통과시킨다고 설명한다. 마스크 0x03이 검사하는 자리는 첫 옥텟의 하위 두 비트다. 7.3절은 그 비트 위치를 직접 풀어 쓴다. 비트 0(마스크 0x01)은 개별/그룹(I/G) 비트로 0이면 유니캐스트, 1이면 멀티캐스트다. 비트 1(마스크 0x02)은 전역/로컬(U/L) 비트로 0이면 IEEE가 할당한 전역 주소, 1이면 로컬 할당이다. 이 둘을 함께 묶은 값이 0x03이다.

    레지스트리에서 대조한 것

    • otherName 형식 레지스트리(1.3.6.1.5.5.7.8)는 12개 항목이고 12번이 id-on-MACAddress다. 다만 1번과 2번은 "Reserved and Obsolete"로 표시돼 있어 살아 있는 형식은 10개다.
    • ASN.1 모듈 식별자 레지스트리(1.3.6.1.5.5.7.0)는 128개 항목이며 126번이 id-mod-mac-address-other-name-2025다. 모듈 이름의 연도는 2025인데 RFC 발행은 2026년 8월이다.
    • 규격 5장의 IANA 등록 요청 표는 참조를 RFC 10031로 적어 두었지만, 두 레지스트리 모두 참조란이 아직 RFC 번호가 아니라 초안 이름([RFC-ietf-lamps-macaddress-on-07])으로 남아 있다. 레지스트리 페이지에 적힌 마지막 갱신일은 2026년 7월 20일로 RFC 발행 이전이다.

    규격이 스스로 붙인 단서

    4장은 이 이름 형식의 신뢰도가 전적으로 CA의 검증 절차에 달렸다고 적는다. CA는 신청자가 해당 주소를 실제로 보유·통제하는지 확인해야 하고, 그 과정에서 주소가 위조될 수 있음을 고려해야 한다. 주소를 동적으로 할당하거나 공유하는 운용 방식은 이 이름 형식이 노리는 유일성과 책임 추적을 약화시킬 수 있다고도 적는다. MAC 주소는 통상 계층 3 경계를 넘어 라우팅되지 않으므로, 검증자는 주소가 망 경계를 넘어서도 안정적이라고 볼 근거가 따로 없는 한 로컬 네트워크 밖에서까지 유일하다고 가정해서는 안 된다. 같은 주소를 서로 다른 기기의 인증서에 넣지 못하게 하는 조항은 4장이 아니라 3.3절에 있다(계층 2 인터페이스를 공유하는 경우는 예외).

    4.1절은 프라이버시를 따로 다룬다. 바뀌지 않는 주소가 담긴 인증서는 기기와 사용자의 장기 추적을 쉽게 만든다고 지적하며 주소 교체, 단명 인증서, 무작위화를 권고한다. 긴장이 남는 지점이다. 안정적 식별자여서 인증서에 넣을 값어치가 생기는데 프라이버시 절은 그 안정성을 줄이라고 권한다. 반대로 볼 여지도 있다. 관리 주체가 하나인 폐쇄망이라면 추적 위험이 크지 않아 실무에서 거의 문제되지 않을 수도 있다.

    이 자료가 말하지 않는 것

    • 채택 현황이 없다. 어떤 CA가 이 형식을 발급하고 어떤 검증 라이브러리가 처리하는지는 문서 밖의 일이다.
    • 서론이 든 용도는 "사물인터넷과 차량 네트워크"라는 넓은 범주다. 계층 2 인증과 함께 흔히 거론되는 개별 프로토콜 이름은 서론에 없었다.
    • 상호운용 시험 결과나 성능 수치가 없다. 기존 구현이 새 규칙을 어떻게 다루는지는 규격 범위 밖이다.
    • RFC 5280 4.2.1.10절은 구현이 반드시(MUST) 이름 제약을 처리해야 하는 형식으로 directoryName 하나만 들고, rfc822Name·uniformResourceIdentifier·dNSName·iPAddress는 처리하는 것이 바람직하다(SHOULD)고 한다. 새 형식은 어느 쪽 목록에도 들어가지 않는다.

    정리하면

    • RFC 10031(2026년 8월, 표준화 트랙 Proposed Standard)은 MAC 주소용 otherName 형식을 OID 1.3.6.1.5.5.7.8.12로 정의했다.
    • EUI-48은 6옥텟, EUI-64는 8옥텟으로 최상위 옥텟 우선 인코딩하며 와일드카드는 지원하지 않는다.
    • 12·16옥텟은 이름이 아니라 제약이며, 값 패턴과 마스크를 이어 붙여 XOR 후 AND 결과가 0이면 통과한다.
    • IANA otherName 레지스트리 12개 항목 중 12번이 이 형식이고, 1·2번은 폐기 표시가 붙어 유효 항목은 10개다.
    • 규격 스스로 위조 가능성, 로컬 네트워크 밖 유일성 미보장, 장기 추적 위험을 명시했다.

    출처와 확인 범위

  • TLS 1.3에 포스트양자 하이브리드 키 교환 3종이 추가됐다 — 표준화 트랙 RFC 10024

    2026년 8월 10일 IETF가 RFC 10024를 발행했다. 통신을 시작할 때 양쪽이 암호 열쇠를 나눠 갖는 절차를 규정한 TLS 1.3에서, 기존 타원곡선 방식과 포스트양자 알고리즘 ML-KEM을 함께 쓰는 조합 세 가지를 정한 문서다. 이 문서는 그전까지 등록돼 있던 표준화 이전 임시 항목을 폐기하고 그 자리를 대신한다.

    무엇이 발행됐나

    문서의 정식 제목은 "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3"이다. 저자는 K. Kwiatkowski, P. Kampanakis, B. E. Westerbaan, D. Stebila 네 사람이고, IETF 스트림에서 나왔다. RFC Editor의 정보 페이지는 이 문서의 상태를 "This is an Internet Standards Track document."라고 적고 있다. 즉 표준화 트랙 문서다.

    1장 도입에 따르면 ML-KEM은 미국 NIST가 FIPS 203으로 규정한 키 캡슐화 메커니즘이고, 전통 키 교환과 차세대 키 교환을 결합하는 일반적인 틀은 RFC 9954가 제공한다. RFC 10024는 그 틀을 ML-KEM에 적용하고, 결합된 그룹에 쓸 코드포인트를 지정하는 역할을 맡는다. RFC 9954는 2026년 7월 15일 발행된 정보성(Informational) 문서이며, 정보 페이지에는 이 문서를 폐기하거나 갱신한 후속 RFC가 표시돼 있지 않다.

    '하이브리드'가 뜻하는 것

    3장 용어 정의는 세 단어를 구분한다. '전통(traditional)' 알고리즘은 이미 널리 쓰이는 것으로, Curve25519·P-256·P-384를 쓰는 ECDHE가 여기 속한다. '차세대(next-generation)'는 아직 널리 채택되지 않은 것으로, ML-KEM이 여기 속한다. '하이브리드'는 여러 알고리즘을 동시에 쓰고 그 결과를 결합해, 적어도 하나가 안전하게 남아 있으면 전체가 안전하도록 만드는 방식을 가리킨다.

    결합 방법 자체는 단순하다. 4.1~4.3절이 규정하는 대로, 클라이언트가 보내는 값은 ML-KEM 캡슐화 키와 타원곡선 임시 공개값을 이어붙인 것이고, 서버가 보내는 값은 ML-KEM 암호문과 서버 쪽 임시 공개값을 이어붙인 것이다. 최종 공유 비밀도 두 알고리즘이 각각 만든 공유 비밀을 이어붙여 만든다.

    세 가지 조합과 전송되는 크기

    7장 IANA 고려사항이 지정한 코드포인트와 4.1~4.3절이 밝힌 바이트 크기는 다음과 같다.

    이름

    코드포인트

    클라이언트 값

    서버 값

    공유 비밀

    X25519MLKEM768

    4588 (0x11EC)

    1216바이트

    1120바이트

    64바이트

    SecP256r1MLKEM768

    4587 (0x11EB)

    1249바이트

    1153바이트

    64바이트

    SecP384r1MLKEM1024

    4589 (0x11ED)

    1665바이트

    1665바이트

    80바이트

    2장은 세 조합의 쓰임새를 나눠 설명한다. X25519MLKEM768은 널리 배포된 X25519를 쓰기 때문에 가장 실용적인 선택으로 제시된다. SecP256r1MLKEM768은 두 공유 비밀이 모두 FIPS 승인 방식으로 만들어져야 하는 경우를 위한 것이다. SecP384r1MLKEM1024는 보안 여유를 더 두려는 고보안 환경을 겨냥한다.

    IANA의 TLS Supported Groups 등록부(2026년 8월 10일 갱신 표시)에서 확인하면, 세 항목 모두 DTLS 사용이 가능(Y)으로 표시돼 있고 Recommended 열은 X25519MLKEM768만 Y, 나머지 둘은 N이다. 같은 등록부에서 25497번 X25519Kyber768Draft00과 25498번 SecP256r1Kyber768Draft00은 이름 뒤에 (OBSOLETE)가 붙고, 비고란에 "표준화 이전 판인 Kyber768"이며 RFC 10024가 이를 폐기했다고 적혀 있다.

    규제 맥락과 보안상 단서

    5장은 '규제 맥락(Regulatory Context)'이라는 제목으로, 결합 방식이 NIST 지침과 어떻게 맞물리는지를 다룬다. NIST SP 800-56C 개정2판과 SP 800-227을 인용하며, 두 공유 비밀을 이어붙일 때의 순서가 그룹마다 다른 이유를 어느 쪽 구현이 인증 대상이 되는지와 연결해 설명한다. 실제로 4.1~4.3절을 보면 X25519 계열은 ML-KEM 값이 앞에 오고, secp256r1·secp384r1 계열은 타원곡선 값이 앞에 온다.

    6장 보안 고려사항은 RFC 9954의 보안 고려사항이 이 문서의 방식에도 그대로 적용된다고 밝힌다. 그중 한 가지로, ML-KEM에서는 캡슐화에 쓴 난수가 복호 과정에서 다시 드러나기 때문에 난수 생성기의 상태가 능동적 공격자에게 노출될 여지가 있다는 점을 지적한다. 부채널 공격에 대한 저항, 특히 원격 공격자가 이용할 수 있는 경로에 대한 저항을 구현에서 우선하라고 권고한다.

    이 글이 말하지 않는 것

    이 글은 규격 문서의 내용만 다룬다. 실제로 이 조합들이 인터넷 트래픽에서 얼마나 쓰이고 있는지, 접속 지연이나 서버 부하가 얼마나 늘어나는지는 RFC 10024가 다루는 범위가 아니며 이 글도 수치를 제시하지 않는다. IANA 등록부의 Recommended 열이 정확히 어떤 절차와 기준으로 정해지는지도 다루지 않았다.

    표준화 트랙 문서로 발행됐다는 사실이 안전성 증명은 아니다. NIST의 FIPS 203 발행 페이지에 실린 초록은 ML-KEM의 안전성이 Module Learning with Errors 문제의 계산적 난이도에 연결돼 있으며 양자컴퓨터를 가진 공격자에 대해서도 안전하다고 '믿어진다'고 서술한다. 증명이 아니라 가정에 근거한 서술이다. 또한 같은 페이지에는 2025년 11월 17일자 안내문이 붙어 있는데, 향후 개정판에서 바로잡을 사안이 있다고 알리고 있다. 해당 안내문은 구체적 내용을 별도의 정오표 문서로 안내한다.

    출처

  • AI가 원고를 36편 완성했다, 그런데 점수는 10점 만점에 6.3점

    "AI가 스스로 연구하고 논문을 쓴다"는 이야기는 몇 년째 나오고 있다. 문제는 그 주장이 대체로 가설을 세우고, 코드를 돌리고, 원고를 쓰는 절차를 끝까지 밟았다는 뜻일 뿐, 결과물이 쓸 만한지는 별개라는 점이다.

    2026년 8월 13일 arXiv에 올라온 「OmniScientist」 원고는 이 지점을 정면으로 다룬다. 그리고 자신들의 점수를 10점 만점에 6.3점으로 공개했다.

    전제 하나. 이 글이 다루는 원고는 동료심사를 거치지 않은 arXiv 프리프린트다. 아래의 성능 수치는 연구진이 스스로 보고한 것이며, 제3자가 재현하거나 심사한 결과가 아니다. 특히 시스템을 만든 팀이 그 시스템을 평가했다는 점을 감안하고 읽어야 한다.

    기존 AI 과학자의 맹점: 원본을 못 본다

    원고가 지적하는 핵심 문제는 이렇다. 지금까지의 AI 연구 시스템들은 텍스트, 코드, 라벨, 또는 미리 계산된 요약값을 놓고 추론한다.

    무슨 뜻이냐면, 현미경 사진 자체를 보는 게 아니라 "세포 수 1,240개, 평균 크기 12μm"라는 표를 받아서 판단한다는 것이다. 이 방식에서는 사진 속에서 세포들이 어떻게 뭉쳐 있는지, 신호가 시간에 따라 어떻게 변하는지 같은 정보가 사라진다. 원고의 표현으로는 "과학적으로 결정적인 공간적, 시간적, 채널 간, 절차적 관계"가 에이전트에게 도달하지 않는다.

    사람 연구자가 데이터를 들여다보다 "어, 이거 이상한데?" 하고 방향을 트는 순간이 있는데, 요약값만 받는 시스템에는 그 순간이 존재하지 않는 셈이다.

    무엇을 바꿨나

    연구진(Bobo Li, Hao Fei, Tianjie Ju, Mong-Li Lee, Wynne Hsu)이 만든 시스템은 가공되지 않은 원본 데이터를 직접 지각하는 층을 앞에 두고, 그 뒤에 아이디어 생성 · 실험 · 원고 작성을 맡는 3개의 자율 에이전트를 붙였다.

    초록이 예로 든 데이터 형식은 이미지, 신호, 오디오, 영상, 3차원 구조, 궤적, 표, 수식, 그래프다.

    여기에 더해 눈여겨볼 부분은 검증을 코드로 강제했다는 점이다.

    • 참신성 스크리닝 (이미 나온 아이디어인지)
    • 통계적 타당성 (분석이 통계적으로 말이 되는지)
    • 실행 출처 추적 (이 결과가 어떤 실행에서 나왔는지)
    • 수치 추적성 (원고 속 숫자가 어느 계산에서 왔는지)

    AI가 그럴듯한 문장으로 결론을 지어내는 걸 막으려면, 원고에 적힌 숫자가 실제로 돌아간 코드까지 거슬러 올라가야 한다. 이 시스템은 그걸 파이프라인 안에 못 박아뒀다.

    숫자를 어떻게 읽을 것인가

    5개 학문 분야, 4종류의 과학적 증거를 아우르는 실제 데이터 36건에 대해 시스템은 원자료에서 완성된 원고까지 36건 모두 완주했다. 평균 점수는 6.3점(기준 추론 백본을 썼을 때)이었다. 채점은 타당성·중요도·사실 정확성 등의 항목에 대해 0~10점 척도로 이뤄졌다.

    가장 흥미로운 건 대조 실험이다. 연구진은 같은 시스템에 원본 대신 미리 계산된 요약값만 주는 '눈 가린' 버전을 만들어 1:1로 비교했다. 원본을 직접 보는 쪽이 7개 평가 항목 전부에서 우세했고, 맞대결에서 85%를 이겼다.

    여기서부터는 필자의 읽기다. 이 대조 실험은 "모델을 더 크게"가 아니라 "증거를 더 많이"가 성능을 가른다는 쪽을 가리킨다. 다만 이 비교는 같은 팀이 설계한 평가 체계 안에서의 결과이고, 6.3점 역시 어떤 기준으로 매겼는지에 따라 의미가 달라진다. 다른 팀이 다른 기준으로 채점하면 숫자는 얼마든지 달라질 수 있다.

    정리하면

    • 기존 AI 연구 시스템은 요약된 데이터만 보기 때문에 원자료에만 있는 정보를 놓친다.
    • OmniScientist는 원본을 직접 지각하고, 참신성·통계·추적성 검증을 코드로 강제한다.
    • 36건 전부 완주했지만 자체 평가 점수는 0~10점 척도에서 6.3점. 끝까지 쓴다는 것과 잘 쓴다는 건 다르다.
    • 원본 접근만으로 7개 항목이 모두 개선되고 85% 승률이 나왔다는 결과는 방향을 시사하지만, 자체 평가라는 한계가 있다.
    • 동료심사 전 프리프린트다.

    'AI가 과학자를 대체한다'는 기사 제목을 볼 때마다, 만든 사람들이 스스로 매긴 6.3점을 같이 떠올리면 좋겠다.

    출처와 확인 범위

    • Li, B., Fei, H., Ju, T., Lee, M.-L., & Hsu, W. (2026). OmniScientist: An Omni-Modal Omni-Discipline AI Scientist. arXiv:2608.13558 (2026. 8. 13. 제출, 동료심사 전). 원문

    확인 범위 — 초록과 본문의 평가 척도 서술(0~10점, 타당성·중요도·사실 정확성 등)까지 확인했다. 항목별 채점 세부 기준과 평가자 구성은 확인하지 못했다. 인용 부호로 묶인 문장은 초록의 번역이다.