Executive Summary

주요 수치

출처: arXiv:2609.19640, "A Policy Profile for Croissant" (2026-09-17)

데이터 카드에 이 데이터는 상업적 목적으로 쓰지 마시오라고 적어 두는 일은 오래된 관행이다. 라이선스 문서도, 데이터 이용 약관도, 동의서에 붙은 제한 문구도 결국 사람이 읽고 사람이 지키는 문장이었다. 기계는 그 문장을 파일에 실어 나를 수는 있었지만, 그 문장을 근거로 작업을 멈추지는 않았다.

Croissant는 그 문장을 기계가 읽을 수 있는 자리에 옮겨 놓은 표준이다. schema.org 위에 JSON-LD로 쓰는 데이터셋 기술서이고, 허깅페이스와 캐글, OpenML이 이 형식으로 데이터셋을 내보내며 구글 데이터셋 검색이 읽어 간다. 1.1판은 여기에 책임 있는 AI와 거버넌스 항목을 더해, 이용 제한을 sc:usageInfo 자리에 싣게 했다. 간단한 조건에는 생명정보 분야에서 쓰이던 동의 어휘 DUO를, 세밀한 권한에는 W3C 표준인 ODRL을 권한다. 표준 문서는 기계가 읽을 수 있는 이용 제한이 규정 준수 검사 자동화를 뒷받침할 수 있다고 말한다. 여기에 흐름이 하나 더 붙었다. 에이전트가 데이터셋을 찾고 내려받고 불러오는 통로를 이 기술서 위에 얹는 작업이다. 데이터를 설명하는 일과 그 설명으로 에이전트를 움직이는 일이 나란히 들어섰다. 둘 다 요청을 거절하지는 않는다.

논문이 파고드는 지점은 그 문장의 빈자리다. 어떻게 뒷받침하는지를 표준이 말하지 않는다. 조건을 쓸 수 있는 어휘가 있다는 것과, 요청 하나를 놓고 통과시킬지 막을지 정하는 절차가 있다는 것은 다른 문제다. 논문은 그 차이를 다섯 항목으로 나눈다.

• 판정 절차가 없다. 조건을 요청과 맞대 본다는 것이 무슨 뜻인지 표준도, 표준이 추천한 두 어휘도 정하지 않는다. 같은 문서를 읽은 두 구현이 서로 다른 결론을 내도 어느 쪽이 틀렸다고 말할 근거가 없다.
• 비용의 상한이 없다. 조건 하나를 검사하는 데 얼마가 드는지를 제약하는 문장이 없다. 접근할 때마다 도는 검사에서는 이것이 곧 성능 문제가 된다.
• 판정 못 하는 조건의 처리가 없다. 구현이 이해하지 못하는 조건을 만나면 요청을 막을지 그 조건을 건너뛸지가 정해져 있지 않다. 이 선택이 게이트와 권고를 가른다.
• 기록이 없다. 무슨 조건을 어떤 관측값으로 검사했는지 남지 않으면 사후 감사도, 나중에 바뀐 정책으로 다시 판정하는 일도 불가능하다.
• 호출자 권한과의 결합이 없다. 데이터에 붙은 조건과 요청한 쪽을 통제하는 권한은 같은 요청 하나를 놓고 부딪히는데, 표준은 둘의 관계를 다루지 않는다.

이 논문이 제안한 프로파일은 Croissant의 데이터셋 노드에 정책 하나를 매단다. 정책에는 데이터의 상태가 들어간다. 판정할 수 없을 때 거절한다는 뜻의 failClosed 항목도 필수다. 허용하려는 동작과 그 동작에 붙는 조건 목록도 함께 들어간다. 조건에 쓸 수 있는 연산자는 다섯 개뿐이고, 그 다섯 개가 언어의 전부다.

이 표는 같은 잘못을 두 갈래로 나눈다. 조건값은 문서에 미리 적혀 있고 관측값은 요청과 함께 도착한다. 관측값의 자료형이 틀렸다면 그것은 평범한 조건 위반이라 그 즉시 거절되고, 조건값의 자료형이 틀렸다면 그것은 정책 문서 자체의 결함이라 비교를 시도하기 전에 번역 단계에서 거절된다. 값을 비교하는 방식도 프로파일이 직접 정한다. 숫자는 값으로 비교하므로 1과 1.0은 같고, 불리언은 불리언과만 같으므로 참은 1이 아니다.

이 설계의 이득은 연산자를 다섯 개로 닫은 데서 나온다. 조건마다 판정 절차가 명시돼 있으니 판정 기록이 무엇과 무엇을 비교했는지 한 줄로 말할 수 있고, 한 판정의 비용은 검사한 조건 수에 비례한다. 논문은 상수 시간이라고 주장하지 않는다. 감사하는 사람이 판정이 항상 빠르기를 바라는 것은 아니다. 문서만 읽어도 판정에 드는 일의 양을 셀 수 있으면 된다. 여섯 번째 연산자가 문서에 몰래 들어오면 판정은 허용에서 거절로 바뀌지, 검사를 건너뛴 통과로 바뀌지는 않는다.

닫아 둔 덕에 딸려 오는 것이 표의 마지막 열이다. 다섯 연산자에는 저마다 대응하는 스키마 표현이 있다. 허용하려는 동작 하나는 에이전트가 부를 수 있는 도구 하나로 투영된다. 도구의 입력 스키마에는 조건마다 속성이 하나씩 생기고, min은 최솟값으로 in은 선택지 목록으로 옮겨 간다. 호출자는 거절당한 뒤에 조건을 알게 되는 대신 부르기 전에 읽는다. 바깥에 내건 스키마와 게이트가 집행하는 조건은 같은 노드에서 생성된다. 문서에서 기준값 하나를 고치면 둘이 같은 편집으로 함께 바뀌므로, 사람이 숫자 하나를 옮겨 적다가 어긋나는 종류의 차이가 사라진다. 다만 투영이 검사를 대신하지는 않는다. 데이터의 상태는 스키마에 실을 수 없어서, 내걸린 제약을 전부 만족한 요청도 상태가 맞지 않으면 거절된다.

이 프로파일은 새 판정 엔진을 만들지 않는다. 문서를 이미 존재하던 게이트의 내부 모형으로 번역해 그 게이트를 부른다. 판정 의미론은 프로파일의 것이고 엔진은 빌려 쓴 것이다. 그래서 알 수 없는 연산자, 빠진 항목, 이름이 겹치는 조건, failClosed를 선언하지 않은 정책 같은 결함이 전부 게이트가 이미 거절할 줄 아는 한 가지 조건으로 옮겨진다. 번역이 실패하면 구멍이 아니라 거절이 나온다는 뜻이다.

그렇다면 ODRL로 프로파일을 만들면 되지 않느냐는 물음이 남는다. 논문은 그 물음을 표현력 싸움으로 받지 않는다. ODRL에도 프로파일 장치가 있어 여기 필요한 조건은 전부 표현된다고 먼저 인정한다. 걸리는 곳은 다른 데다. 새 연산자를 프로파일로 만들어도 주소와 설명만 생기고 판정 절차는 생기지 않는다. 같은 ODRL 표준 위에 서로 다른 연구 그룹이 각자 판정 절차를 붙여 온 일이 그 증거다. 한 그룹은 정책을 논리 프로그램으로 옮겨 규정 준수를 검사하게 했고, 다른 그룹은 제약마다 실행 가능한 함수를 매달았다. 표준이 비워 둔 자리가 어디인지는 그 두 결과가 가리킨다.

검증은 두 벌로 나뉜다. 둘을 섞지 않은 이유도 논문이 앞에서 먼저 밝힌다. 하나는 실제로 돌아간 공정을 통제한 기술서 3건이다. 진짜 실행 앞에서 작동했다는 증거이고, 이 글에 나오는 시간 수치는 전부 여기서 나온다. 나머지 하나는 프로파일의 문법으로 생성한 문서 묶음이다. 명세가 정의한 모든 기능을 훑지만 시간은 한 건도 재지 않았다. 진짜 문서 세 건으로는 기능 공간을 다 훑지 못하고, 지어낸 문서는 실제 운영에 대해서는 증거가 아니다.

3.1작업이 시작되기 전에 걸리는 게이트

대상은 nf-core/demo 1.0.1이다. 유전체 서열 데이터의 품질 검사와 다듬기, 보고서 생성으로 이어지는 세 단계짜리 생명정보 공정이다. 이 논문을 위해 만든 예제가 아니라 공개된 테스트 데이터 위에서 실제로 실행되는 작업이다. 게이트는 Nextflow가 각 작업 앞에 두는 훅에 걸린다. 종료 코드가 0이 아니면 그 작업의 스크립트는 시작되지 않는다. 사후에 기록을 훑어보는 감사가 아니라 실행 전에 막는 구조다.

비교 방식이 이 절의 핵심이다. 요청 목록은 사람이 손으로 적은 것이 아니라 기술서에서 생성된다. 조건을 전부 만족하는 맥락, 빈 맥락, 상관없는 키만 든 맥락, 조건마다 하나씩 만든 위반, 숫자 자리에 넣은 비숫자, 선언되지 않은 동작 이름 두 개가 들어간다. 각 요청은 두 번 판정된다. 한 번은 기존 기술서로, 다른 한 번은 새로 뽑아낸 프로파일 문서로 내린다. 그리고 대조하는 것은 허용인지 거절인지가 아니라 판정 기록 전체다. 두 판정기가 결론은 같은데 거절 등급이나 사유, 검사했다고 주장하는 조건 목록이 다르다면 감사하는 사람이 같다고 인정할 리 없기 때문이다. 기록은 전부 일치했다.

다만 이 결과가 보장하는 범위는 좁다. 두 판정을 모두 같은 게이트가 내렸다. 판정기를 둘로 나누면 불일치가 문서에서 온 것인지 판정기에서 온 것인지 가릴 수 없기 때문에 일부러 그렇게 설계했다는 것이다. 그래서 이 실험이 보장하는 것은 Croissant 문서를 내부 모형으로 옮기는 번역의 충실성이다. 게이트 자신의 권한 판단이 옳은지는 이 논문의 범위 밖이다.

3.2명세의 구석까지 훑는 문서 57건

두 번째 묶음은 명세가 이름 붙인 것들을 전부 훑도록 만들어졌다. 연산자 다섯 개, 거절 등급 세 가지, 적합성 조항 다섯 개, 표기 두 가지, 그리고 몇 가지 구조적 형태다. 유효한 사례 22건과 결함 사례 13건으로 이뤄진다. 유효한 사례는 두 표기로 각각 저장되므로 문서 수로는 44건이고, 결함 사례 13건을 더해 모두 57건이다. 논문은 이 숫자들이 재현을 위한 정보일 뿐 결과가 아니라고 못 박는다. 큰 코퍼스가 작은 코퍼스보다 적은 기능을 훑을 수도 있고, 크기에서 보이는 것은 크기뿐이기 때문이다.

세 갈래 일치는 그 안에서도 유효한 사례에만 걸리는 주장이다. 사례마다 기존 기술서와 프로파일 표기, 그리고 Croissant 1.1이 이용 조건을 두라고 지정한 자리에 넣은 ODRL 정책, 이렇게 세 가지로 만들고 각각에 생성된 요청 목록을 걸었다. 표기당 요청 184건, 판정 기록 552건이 세 갈래로 전부 일치했다. 결과의 분포도 함께 실려 있다. 허용 20건, 조건 위반 83건, 선언되지 않은 동작 44건, 상태 때문에 거절된 것 37건이다. 거절만 잔뜩 모아 놓고 일치했다고 말하는 상황이 아니라는 뜻이다.

이런 비교에서는 시험이 실패할 수 있는지부터 확인해야 한다. 연산자 표에서 한 줄을 일부러 뒤집어 min을 ODRL의 이하 연산자에 잘못 대응시키자 비교 19건이 깨졌다. 두 표기는 정책 노드 바깥에서는 글자까지 같게 맞춰 두었다. 남는 차이는 표기 자체에서만 온다. 결함 사례 쪽 기록도 함께 남아 있다. 결함 문서 13건에 들어간 요청 91건이 전부 거절됐고, ODRL 표기가 있는 11건에 들어간 77건도 마찬가지다. 번역이 실패하면 거절이 나온다는 설계가 문서 단위로 확인된 결과다.

이 묶음을 만들어 얻은 것은 결함 다섯 건이다. 세 건짜리 실제 기술서로는 닿을 수 없던 것들이다. 그중 둘은 문서도 코드도 멀쩡해 보인다.

• 배열을 적어야 할 자리에 문자열을 적은 정책이 부분 문자열 대조로 흘러갔다. in에 "illumina"라고 쓴 문서가 "illu"를 조용히 허용했다. 배열 괄호를 빠뜨리는 것은 흔한 실수이고, 어떤 검증기도 이 문서를 문제 삼지 않았다.
• 파이썬에서 불리언이 정수의 하위형이라 참과 1이 같게 비교됐다. equals로 참을 요구한 정책이 관측값 1에 만족됐고, 1과 2 중 하나를 요구한 조건이 참을 받아들였다. 코드만 보면 멀쩡해 보여서 가장 늦게 발견됐다.

둘 다 정책이 쓴 것보다 넓게 허용하는 결함이다. 저자는 이것이 바로 이 프로파일이 막으려던 실패라고 적는다. 판정 절차를 논문 안에 글로 적어 두는 일이 구현이 다른 절차를 따르고 있었다는 사실을 드러내는 좋은 방법이더라는 문장이 뒤따른다. 그 밖에 in에 숫자를 적은 문서가 거절되는 대신 판정기를 멈춰 세운 결함, ODRL 표기가 거절 대신 예외를 던진 결함, 프로파일을 선언하지 않은 문서도 그냥 판정해 주던 결함이 함께 고쳐졌다. 고친 비교 규칙으로 실제 공정 기록을 다시 돌렸을 때 46건의 판정은 하나도 바뀌지 않았다. 실제 기술서 3건에 불리언 조건이 없었기 때문이다.

적합성 검사를 SHACL 형태로 쓰다가 Croissant 자체의 결함도 하나 나왔다. Croissant의 문맥 파일이 conformsTo를 IRI로 선언하지 않고 전역 언어 태그를 걸어 두는 바람에, 어떤 프로파일을 따르는지 밝히는 바로 그 항목의 값이 주소가 아니라 언어가 붙은 문자열로 펼쳐진다. 문서는 주소가 가리키는 프로파일이 아니라 그 주소를 적은 글자에 적합하다고 주장하는 셈이다. 저자는 이를 MLCommons에 이슈 1047로 신고했고, 논문을 쓰던 9월 16일까지 답을 받지 못했다.

비용은 기술서 3건에 대해 경우마다 5,000번씩 돌려서 쟀다. 문서를 한 번 번역해 두고 재사용하는 경우에는 기존 기술서도 프로파일 문서도 1.8µs로 같다. 같은 객체에 같은 함수를 부르는 것이니 추가분이 0인 것은 당연하다. 판정할 때마다 문서를 새로 읽는 경우에는 8.5µs가 20.2µs가 되어 11.7µs가 붙는다. 이 추가분의 대부분도 프로파일 때문이 아니다. 11.7µs 중 9.7µs가 JSON 파싱이고, 프로파일 고유의 번역 비용은 2µs 정도다. Croissant 문서가 문맥까지 합쳐 3.1KB이고 내부 기술서가 754B라서 생긴 차이다.

여기까지가 초록에 실린 숫자다. 119µs짜리 판정에 11.7µs가 붙으니 거의 공짜라고 읽기 쉽다. 논문은 바로 다음 문단에서 그 독법을 스스로 막는다. 같은 실험 장치로 답할 수 있는 질문인데 답이 편하지 않다.

게이트를 건 팔과 걸지 않은 팔을 각각 30번씩 돌려 반복 단위로 짝지어 비교하면, 작업 하나당 끝에서 끝까지의 비용은 25.7밀리초 늘어난다. 95% 신뢰구간은 3.3에서 48.2밀리초다. 이 증가분은 정책 때문이 아니다. 작업마다 파이썬 인터프리터를 하나씩 새로 띄우기 때문이고, 그 기동 비용만 따로 재면 30.2밀리초다. 아무것도 하지 않는 인터프리터를 띄우는 데도 9.6밀리초가 든다.

그래서 논문이 내놓는 정직한 문장은 없음이 아니라 비율이다. 판정은 119µs인데 그 판정을 배달하는 장치가 30밀리초를 쓴다. 대략 250배다. 정책을 표준 기술서로 표현하는 비용은 프로세스 기동이 지배하는 작업당 비용 안에서는 보이지 않는다는 결론이 여기서 나온다. 상주하는 게이트로 바꿔 기동 비용을 없애도 여전히 작을 것이라는 말도 덧붙는다.

데이터가 스스로 조건을 판정한다는 말을 데이터가 접근 권한까지 안다는 뜻으로 읽으면 논문을 거꾸로 읽는 것이 된다. 이 프로파일에는 신원 모형이 아예 없다. 누가 요청했는지, 그 요청자가 자격을 갖췄는지는 범위 밖이라고 6절에 적혀 있다. 요청자를 판정하는 일은 에이전트의 행동을 실행 전에 검사하는 제어 평면이나 자원 접근 제어처럼, 호출자에 정책을 묶는 쪽의 몫이다.

논문은 두 쪽의 관계를 의견이 아니라 정리로 다룬다. 호출자 쪽이 허용하는 요청의 집합과 데이터 쪽이 허용하는 요청의 집합은 어느 쪽도 다른 쪽을 포함하지 않는다. 둘이 서로 겹치지 않는 상태 공간 위에서 움직이기 때문이다. 데이터가 검사를 통과했는지, 대기 중인지, 철회됐는지는 그 순간 데이터의 성질이라 호출자 신원에서 끌어낼 수 없고, 호출자의 인증이 만료됐는지는 호출자의 성질이라 기술서에서 끌어낼 수 없다. 서로가 표현할 수 없는 규칙을 하나씩 쥐고 있으면 둘은 반드시 갈린다.

정리를 증명한 뒤에는 실측이 이어진다. 호출자 쪽 시나리오 네 개에 기술서 3건, 거기에 생성된 요청 목록을 곱해 184건을 판정했다. 둘 다 허용한 것이 12건, 둘 다 거절한 것이 137건, 데이터 쪽만 거절한 것이 23건, 호출자 쪽만 거절한 것이 12건이다. 엇갈린 35건이 전체의 19%다.

총계보다 구조가 중요하다. 데이터 쪽만 거절한 23건 가운데 20건은 호출자가 아예 들고 있지 않은 조건을 위반했고, 3건은 데이터의 상태에 걸렸다. 상태는 호출자 정책이 원리적으로 표현할 수 없는 종류의 규칙이다. 호출자 쪽만 거절한 12건은 거울상이다. 6건은 호출자 자신의 인증 만료, 4건은 갖고 있지 않은 권한 때문인데 이것들은 기술서로 표현할 수 없다.

이 수치가 무엇이 아닌지는 논문에 두 번 나온다. 요청 목록이 위반이 많도록 일부러 기울어 있으므로 19%를 실제 트래픽의 불일치율로 읽으면 안 된다. 그리고 호출자 쪽 시나리오 네 개는 저자가 제품 설명을 보고 지어낸 모형이다. 다른 시나리오를 쓰면 다른 숫자가 나온다는 것도 저자가 먼저 말한다. 다만 어떤 시나리오를 쓰더라도 데이터의 상태를 조건으로 삼는 호출자 정책이나 호출자의 인증을 조건으로 삼는 기술서는 만들어지지 않는다. 논문이 남은 가장 큰 구멍으로 꼽는 것도 이 대목이다. 모형 대신 실제 제품을 붙여 다시 재는 일이다.

두 권한을 함께 돌리는 비용은 거의 들지 않는다. 두 기술서를 메모리에 올려 두면 하나만 볼 때 2.5µs이던 것이 둘을 모두 볼 때 5.7µs가 된다. 판정마다 두 문서를 다시 번역해도 17.6µs다. 대신 기록이 하나로 남는다. 합동 기록에는 두 판정과 두 거절 등급, 두 사유 목록이 들어가고, 허용한 쪽이 통과시킨 조건도 빠지지 않는다. 합동 기록은 다섯 가지 우선 규칙 각각이 같은 요청에 어떤 결론을 냈을지까지 판정 시점에 함께 담는다. 나중에 이 기록을 읽는 사람은 정책 문서를 다시 구하지 않고도 그 결론이 정책 때문이었는지 우선 규칙 설정 때문이었는지 가릴 수 있다.

페블러스가 오래 붙들어 온 물음은 어떤 값이 어디서 와서 무엇을 거쳐 지금 모습이 됐는가다. 데이터에 붙은 사용 조건은 그 물음의 반대편 끝에 있다. 어디서 왔는지가 과거를 향한 질문이라면, 무엇에 쓸 수 있는지는 앞을 향한 질문이다. 두 질문 모두 데이터 자신이 답할 수 있어야 한다는 점에서는 같다.

AI-Ready Data를 깨끗한 데이터로만 좁혀 보면 이 논문은 남의 동네 이야기로 읽힌다. 결측이 없고 라벨이 고르고 스키마가 맞는 데이터가 준비된 데이터라는 정의에서는, 쓰지 말라는 문장은 데이터 바깥의 행정 사항이다. 그런데 에이전트가 데이터셋을 직접 찾아 내려받아 돌리기 시작하면 그 구분이 무너진다. 조건을 읽을 사람이 중간에 없기 때문이다. 이 논문이 좁은 범위를 골라 증명한 것도 딱 그 지점이다. 데이터셋이 자기 이용 조건을 표준 기술서에 싣고 다니면 게이트가 그 문서만 보고 판정할 수 있다는 것, 그 이상은 아무것도 얻지 않는다는 것이다.

우리가 이 구조에서 가장 오래 들여다본 것은 판정 자체보다 기록이다. 무엇을 검사했고 관측값이 얼마였는지가 판정마다 남으면, 그 기록은 나중에 바뀐 정책으로 다시 판정할 수 있는 자산이 된다. 논문에는 보관된 판정 기록을 원본 데이터도 원래 공정도 없이 새 정책으로 다시 돌려 보고, 판정할 수 없는 기록의 비율을 추측 대신 보고하는 도구가 딸려 있다. 데이터 품질 진단을 하는 사람이 보면 이것은 낯익은 구조다. 점수 하나를 남기는 것과 그 점수가 어떤 검사에서 나왔는지를 남기는 것의 차이다. 앞의 것은 기준이 바뀌면 버려지고, 뒤의 것은 다시 계산된다.

4절에서 본 철회도 한 번으로 그치지 않는다. 식별자 주소가 아직 열리지 않는다고 적었던 이전 판본의 문장은 등록이 반영된 뒤 응답을 직접 확인하고 갱신했고, 적합성 시험을 쓰다가 명세 문장 하나를 고친 일도 있다. 정책 항목을 지운 문서가 여전히 그 프로파일을 따른다고 주장하는 구멍이 시험을 쓰는 동안 드러났기 때문이다. 판정마다 무엇을 검사했는지 남기라는 요구를 저자가 자기 원고에도 걸어 둔 셈이다.

조건을 스스로 말하고 증명하는 데이터라는 관점을 자기 조직에 걸어 보려는 팀이라면 네 가지를 확인해 볼 만하다.

• 우리 데이터셋의 이용 제한이 지금 어디에 적혀 있는가. 계약서와 위키에만 있다면 기계가 읽을 자리로 옮기는 것이 첫 단계다.
• 그 제한을 판정하는 절차가 글로 적혀 있는가. 구현 코드만 있고 절차가 글로 없다면, 구현이 다른 규칙을 따르고 있어도 아무도 모른다. 이 논문에서 결함 세 건이 바로 그렇게 드러났다.
• 판정할 수 없는 조건을 만났을 때 우리 시스템은 막는가 건너뛰는가. 이 선택이 게이트와 권고를 가른다.
• 거절한 기록에 무엇을 검사했는지가 남는가. 남지 않으면 그 거절은 나중에 버그와 구별되지 않는다.

한 가지는 분명히 해 두는 편이 좋다. 이 논문은 동료평가 전 프리프린트이고, 실제 실행 증거는 기술서 3건이며, 호출자 쪽 절반은 모형이다. 저자 본인이 그렇게 적어 두었다. 여기서 데이터 거버넌스가 자동화 단계에 들어섰다는 결론을 끌어내는 것은 이 글의 해석이 아니라 과장이다. 우리가 읽은 것은 더 작다. 조건을 적을 자리가 생긴 다음에 무엇이 더 있어야 그 문장이 실제로 요청을 막는지를, 한 사람이 최소 구성으로 만들어 재 본 기록이다.

여기까지 읽어 주셔서 감사하다. 이 글이 인용한 수치와 인용문은 arXiv:2609.19640 원문에서 누구나 확인할 수 있다. 여러분의 조직에서는 데이터에 붙은 이용 조건을 어떤 형식으로 들고 계신지, 그 조건을 실제로 검사하는 자리가 어디에 있는지 나눠 주시면 좋겠다.

학술 논문

• 1.Chernov, A. (2026). "A Policy Profile for Croissant: Refusal as a Property of the Dataset." arXiv:2609.19640.
• 2.Chernov, A. (2026). "Dataset Descriptors for Autonomous and Observable Biomedical Data Pipelines." IEEE EMBC 2026, Toronto.

표준·명세

• 3.MLCommons. (2026). "What's New in Croissant 1.1: Extensible, Agent-Ready ML Dataset Standard."
• 4.MLCommons. "Croissant Format Specification 1.1."

참조 구현

• 5.doytsujin. "ok-nfcore-admission-gate." GitHub. 저자 계열의 동료 심사 전 공개 저장소 — 게이트 기동 비용 재검증.
• 6.doytsujin. "ok-croissant-policy-profile." GitHub. 저자 계열의 동료 심사 전 공개 저장소 — 정책 프로파일 참조 구현.