SHACL 필드 비교 검수: 비교값이 비어도 통과하는 이유

SHACL 2017의 sh:lessThan은 비교값 누락을 막지 않습니다. 2026-11-06 기준, 필수·개수·자료형은 별도 제약입니다.

하한과 상한을 비교하는 규칙을 추가했는데 상한을 비운 설정도 통과하면 검증 결과를 믿기 어렵습니다. 비교할 값이 없는 상황과 잘못된 값 쌍이 있는 상황을 나누면 원인을 설명할 수 있습니다. 입력 완료까지 검수하려면 두 필드의 존재와 개수도 명시해야 합니다.

비교값이 비어 있는데 왜 위반이 없나요?#

sh:lessThan과 sh:lessThanOrEquals는 두 속성에서 찾은 값 쌍을 비교합니다. 어느 쪽도 비교 쌍을 만들지 못한 상황을 필수 입력 오류로 바꿔 주지는 않습니다. 양쪽 값이 필요하다면 각 경로에 sh:minCount를 둡니다.

이 글의 가상 설정은 같은 단위의 정수형 하한 lower와 상한 upper입니다. 하한 2만 있고 상한이 없을 때, ≤ 비교 제약만 둔 모양은 통과했습니다. 필수·단일 정수 조건을 양쪽에 추가한 모양은 누락을 위반으로 보고했습니다. 고객 자료가 아닌 합성 재현 결과입니다.

W3C SHACL 2017 권고안은 각 값 쌍에서 비교가 거짓이거나 비교할 수 없으면 위반 결과를 내도록 정의합니다. 공식 필드 비교 정의의 발표일은 2017-07-20, 확인일은 2026-11-06입니다. 데이터 책임자는 필수 여부를, 개발 담당자는 비교와 개수 제약을 나눠 인수표에 적습니다.

필수·개수·자료형과 값 순서를 어떻게 나누나요?#

각 필드에 값이 하나씩 필요한 계약이라면 최소 개수와 최대 개수를 각각 1로 정합니다. 정수로 비교하기로 했다면 양쪽 자료형도 정수로 제한합니다. 그 위에 하한≤상한을 적용하는 방식입니다.

다음은 2017 문법의 설계 예시입니다. lower와 upper의 필수·단일 정수 조건을 모두 선언합니다. 같은 값을 허용하는 가상 계약이므로 sh:lessThanOrEquals를 썼습니다.

@prefix ex: <https://example.org/range/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:RangeShape a sh:NodeShape ;
  sh:targetNode ex:sample ;
  sh:property [
    sh:path ex:lower ;
    sh:minCount 1 ; sh:maxCount 1 ;
    sh:datatype xsd:integer ;
    sh:lessThanOrEquals ex:upper
  ] ;
  sh:property [
    sh:path ex:upper ;
    sh:minCount 1 ; sh:maxCount 1 ;
    sh:datatype xsd:integer
  ] .

minCount만 추가하면 복수 값이 들어오는 조건이 남습니다. 자료형만 정해도 값 누락은 해결되지 않습니다. W3C 최소 개수 제약, 최대 개수 제약, 자료형 제약을 같은 입력으로 대조해야 하는 이유입니다. 확인일은 2026-11-06입니다.

상한과 같은 하한을 허용하지 않으려면 비교를 sh:lessThan으로 바꿉니다. 가상 입력 3과 3은 < 비교에서 위반, ≤ 비교에서 통과했습니다. 어느 쪽이 업무 규칙인지는 데이터 책임자가 정합니다.

누락·복수 값을 어떤 표본으로 검수하나요?#

정상·동일값·역전·양쪽 누락과 복수값을 같은 모양 버전에서 대조합니다. 다음 표의 ‘비교만’은 lower≤upper만 적용한 결과이며, ‘필수·단일 정수 추가’는 위 코드의 결과입니다. 입력은 모두 같은 단위의 가상 값입니다.

복수 값에서는 한 쌍만 맞는 것으로 충분하지 않습니다. lower의 각 값이 upper의 모든 값과 관계를 만족해야 합니다. 위 표의 하한 1·4와 상한 3·5에는 맞는 쌍이 있어도 4와 3이 충돌합니다. 반대로 모든 쌍이 맞아도 한 값만 받기로 했다면 maxCount 위반을 따로 확인합니다.

보고서에서는 누락·개수·자료형·비교 중 어느 제약이 위반을 냈는지 확인합니다. ‘통과’와 ‘위반’만 적기보다 입력 버전·모양 버전·적용 대상·기대 결과와 위반 성분을 함께 남기면 규칙 변경 뒤에도 결과를 대조할 수 있습니다. 자동 반영 보류와 담당자 수정 절차는 이 글의 설계 제안입니다.

최신 SHACL 1.2 초안을 바로 적용해도 되나요?#

2026-11-06 확인한 SHACL 1.2 Core 문서는 2026-11-02 공개된 Working Draft입니다. 확정 권고안으로 취급하지 않습니다. 이 초안은 비교 파라미터를 속성 경로로 기술하지만, 위 코드는 2017 권고안의 단일 속성 IRI를 사용합니다.

초안의 문법 범위와 실제 검증 엔진의 지원 범위는 따로 확인해야 합니다. 이번 합성 시험은 2017 방식의 값 비교에 한정했으며, 복합 비교 경로나 전체 1.2 적합성을 입증하지 않습니다. 코드의 통과가 단위 일치·허용 업무 범위·원천 최신성까지 보장하는 것도 아닙니다.

검사할 대상 자체가 빠졌다면 SHACL 검증 대상 누락 검수에서, 조건에 맞는 연결값의 개수를 세려면 SHACL 조건부 개수 검수에서 확인할 수 있습니다. 클래스가 동시에 성립하는 문제는 온톨로지 배타 클래스 검수에서 다룹니다. 여기서는 같은 대상의 두 속성을 비교하는 입력 조건에 집중합니다.

알파카랩스는 온톨로지 구축 서비스에서 개념·관계·제약 정의, 원천 매핑과 AI·MCP 조회의 인수 범위를 협의한다고 공개합니다. 자사 제공 방식에 대한 자기표기이며 이 글의 합성 결과를 납품 실적이나 성과 보장으로 쓰지 않습니다. 다음 검토는 2026-12-06 또는 규격 지위·엔진·실제 모양 변경 시 진행합니다.

SHACL 필드 비교 검수 FAQ#

sh:lessThan을 쓰면 양쪽 필드가 필수가 되나요?

두 필드의 필수 입력은 별도 제약입니다. 비교할 값 쌍이 없으면 비교 제약만으로 누락을 위반 처리하지 않습니다. 양쪽 경로 각각에 필요한 minCount를 정합니다.

같은 값도 허용하려면 어떤 제약을 쓰나요?

sh:lessThanOrEquals는 같은 값을 허용하고 sh:lessThan은 허용하지 않습니다. 가상 하한·상한이 3과 3일 때 결과가 갈립니다. 같은 값의 업무상 허용 여부를 먼저 확정합니다.

비교할 값이 여러 개면 어느 값을 쓰나요?

각 값과 상대 속성의 모든 값을 비교합니다. 맞는 쌍이 하나 있다고 통과하지 않습니다. 한 값만 허용하는 계약이면 양쪽 maxCount도 별도로 선언합니다.

자료형이 달라 비교할 수 없으면 통과하나요?

비교할 값 쌍이 있지만 서로 비교할 수 없으면 비교 제약의 위반 대상입니다. 누락 때문에 비교 쌍 자체가 없는 경우와 다릅니다. 자료형 제약도 두어 입력 오류의 원인을 구분할 수 있습니다.

SHACL 1.2 초안에 나온 문법을 그대로 써도 되나요?

2026-11-02 문서는 Working Draft이며 실제 엔진의 지원과 검증 결과를 확인해야 합니다. 이 글의 코드는 2017 권고안 방식의 단일 속성 비교입니다. 1.2 전체 기능을 시험했다는 뜻은 아닙니다.

필드 비교 인수표 협의#

민감정보를 제거한 하한·상한 표본과 현재 모양을 기준으로 필수·개수·자료형·비교의 기대 결과를 정할 수 있습니다. 산출물은 입력별 필드 비교 인수표 초안이며, 소요 시간은 자료와 규칙 범위를 확인한 뒤 정합니다.