allOf은 JSON Schema(및 OpenAPI 등에서 사용하는 스키마 언어)에서 사용하는 조합 키워드로, "모든 서브스키마를 동시에 만족해야 한다"는 의미입니다. 즉 논리적 AND 역할을 합니다. 주요 의미와 동작 - 검증 의미: 인스턴스는 allOf 배열에 있는 모든 서브스키마 각각을 통과해야 한다. (모든 제약의 교집합) - 빈 배열: allOf: [] 는 공집합이 아닌 공집합의 논리적 AND로서 항상 true(모든 인스턴스 허용)로 취급됩니다(공리적 진리). - 단일 요소: allOf에 하나만 있으면 그 요소와 동일합니다. - 객체 병합: 객체형 스키마가 여러 서브스키마로 나뉘어 있으면, properties는 합쳐지고 required는 서브스키마들의 합집합으로 처리되는 식으로 제약이 합쳐집니다. (단, 설명(description), example 등은 벤더/툴마다 병합 방식이 다릅니다.) - 충돌: 서브스키마들 간에 서로 모순되는 제약(예: 같은 속성에 서로 다른 타입 요구)이 있으면 결과적으로 어떤 값도 만족하지 못하는 불가능한 스키마가 될 수 있습니다. 간단한 예 - 문자열 제약 결합: allOf: [ { "type": "string", "minLength": 3 }, { "pattern": "^[A-Z]" } ] → 최소 길이가 3이고 첫 글자가 대문자인 문자열만 허용. - 객체 확장(재사용): allOf: [ { "$ref": " /components/schemas/Base" }, { "type": "object", "properties": { "extra": { "type": "string" } }, "required": ["extra"] } ] → Base 스키마의 제약을 모두 적용하고, 추가로 extra 속성을 요구. 사용 사례 - 스키마 재사용 및 확장(상속처럼 사용) - 여러 제약을 분리해서 선언한 뒤 합치는 경우 - OpenAPI에서 $ref로 정의된 공통 스키마를 가져와서 추가 제약을 붙일 때 주의할 점 - 주석/설명( title, description ), example, default 같은 메타정보는 검증 로직에 영향을 주지 않지만, 이들 필드의 병합 결과는 툴마다 다르므로 문서나 코드 생성에서 기대한 결과와 다를 수 있음. - allOf는 검증 관점에서는 단순한 AND이지만, 코드 생성기/문서화 툴은 이를 상속(extends) 또는 합성(composition)으로 처리할 수 있어 결과물이 달라질 수 있음. - 배열이나 items 제약 등도 각 서브스키마에 대해 모두 적용되므로 결과 제약이 더 엄격해질 수 있음. 비교(간단) - allOf: 모든 서브스키마를 만족해야 함 (AND) - anyOf: 서브스키마 중 하나 이상 만족하면 됨 (OR) - oneOf: 서브스키마 중 정확히 하나만 만족해야 함 (배타적 OR) - not: 특정 스키마를 만족하면 안 됨 (부정) 요약하면, allOf는 여러 스키마 제약을 논리적으로 결합하여 인스턴스가 모두의 요구조건을 충족하도록 하는 키워드이며, 재사용과 확장에 유용하지만 병합 규칙과 툴 동작 차이에 주의해야 합니다.
