Databricks의 Spark Declarative Pipelines 벤치마크가 더 저렴한 에이전트 실수의 필요성을 보여주는 이유

Databricks는 10월 23일 Spark Declarative Pipelines 벤치마크를 공개하며, 선언형 방식으로 에이전트가 빌드할 때 executor 시간이 약 34배 적게 든다고 보고했다. 이 비교는 원본 레코드를 활용 가능한 데이터세트로 변환하는 프로그램인 데이터 파이프라인을 다룬다. 핵심 주장은 실수가 언제 비용으로 이어지는지, 즉 검증 단계인지 실행이 시작된 이후인지에 관한 것이다.

선언형 프로그래밍은 원하는 결과를 설명하고 실행 세부 사항은 프레임워크에 맡긴다. 절차형 프로그래밍은 각 단계를 직접 지정한다. Databricks는 AI 에이전트가 코드를 생성할 때 이 구분에 더 많은 관심을 기울여야 한다고 주장한다. 당장의 부담은 해당 에이전트가 프로덕션 작업을 빌드하고 수정하는 방식을 선택하는 엔지니어링 팀에 돌아간다.

관련 비교는 Spark 문법을 넘어선다. Apache Airflow는 워크플로를 구성하고, dbt는 변환 및 테스트 도구를 제공한다. 어느 쪽도 모든 Spark 워크로드를 직접 대체하지는 않는다. 그러나 함께 보면 유용한 기준점이 된다. 팀은 이미 작성자, 검증자, 스케줄러, 검토자 사이에 책임을 분산하고 있다. 에이전트 도입은 이 경계를 실질적인 구매 및 아키텍처 문제로 만든다.

Spark Declarative Pipelines 벤치마크가 실제로 측정하는 것

Databricks는 최종 답변 정확도의 결정적인 향상보다 반복 비용에 관한 주장을 제시하고 있다.

회사의 파이프라인 작성 벤치마크는 22개 작업에서 총 528개의 빌드를 다뤘으며, 작업별로 12개 입력 데이터세트와 두 가지 프로그래밍 방식을 사용했다. 보고서에 따르면 절차형 빌드에는 596 executor-seconds가, 선언형 빌드에는 17초가 사용됐다. Executor-seconds는 경과 시간이나 전체 인프라 청구액이 아니라 누적된 워커 실행 시간을 측정한다.

완료된 빌드 가운데 코드 길이의 중앙값은 절차형이 131줄, 선언형이 64줄이었다. 선언형 작성 방식은 언어 모델이 처리하는 단위인 모델 토큰을 약 2.3배 더 사용했다. 이 수치는 테스트된 설정을 설명할 뿐이며, 프로덕션 시스템 전반에서 보편적인 절감 효과를 입증하지는 않는다.

이 구분은 벤치마크가 엔지니어링 게시물에서 구매 논의로 옮겨갈 때 중요하다. 워커 시간 측정은 총 운영 비용보다 더 좁은 질문에 답한다. 구매자는 개발 환경, 플랫폼 서비스, 모델 사용량, 유지보수, 그리고 사람의 주의력도 고려해야 한다.

마찬가지로 누적 실행 시간은 엔지니어가 수용 가능한 결과를 얻기까지 얼마나 기다렸는지는 알려주지 않는다. 평가는 적은 워커 시간을 소비하면서도 에이전트와의 긴 대화를 요구할 수 있다. 다른 평가는 더 많은 병렬 리소스를 사용하면서도 빠르게 끝날 수 있다. 이러한 결과는 별도로 측정할 가치가 있다.

코드 길이 결과는 또 다른 질문을 제기한다. 더 짧은 제출물은 검토자가 살펴볼 텍스트를 줄여 주지만, 줄 수가 적다고 해서 추론이 자동으로 단순해지는 것은 아니다. 간결한 변환도 고객, 날짜 또는 거래 상태에 관한 잘못된 가정을 숨길 수 있다.

따라서 엔지니어링 관리자에게 유용한 해석은 조건부다. 프레임워크가 반복적인 실행 코드를 제거한다면 검토자는 남은 비즈니스 의사결정에 더 많은 주의를 기울일 수 있다. 실제로 그렇게 되는지는 검토 프로세스와 프레임워크 동작의 가시성에 달려 있다.

선언형 파이프라인과 절차형 파이프라인의 비교에도 명확한 기준선이 필요하다. 신중하게 설계된 검사를 갖춘 절차형 구현은 제한 없는 스크립트와 다르다. 팀은 결과를 아키텍처의 판정으로 받아들이기 전에 각 구현에 어떤 보호 장치가 적용됐는지 물어야 한다.

이 발표는 설계 가설의 근거로 읽는 편이 가장 적절하다. 즉, 더 이른 피드백은 성공하지 못한 시도가 소비하는 리소스를 줄일 수 있다. 이는 생성된 결과물과 함께 에이전트의 작업 환경도 살펴봐야 하는 이유다.

이러한 틀은 공급업체의 실험을 모든 배포 환경에 대한 약속으로 바꾸지 않으면서도 뉴스를 유용하게 만든다. 운영상의 질문은 구체적이다. 어떤 실패를 플랫폼이 값비싼 리소스를 소비하기 전에 거부할 수 있는가?

에이전트 도입은 검증 경계에 압력을 가한다

압박을 받는 팀은 플랫폼이 검증할 수 있는 범위를 정하기 전에 생성된 코드가 실행에 도달하도록 허용하는 팀이다.

Databricks는 현재 자사 플랫폼에서 에이전트가 SDP 파이프라인의 70% 이상을 생성한다고 말한다. 이 발언은 모든 엔터프라이즈 파이프라인이 아니라 특정 제품 집단에 관한 것이다.

중요한 조직적 함의는 책임에 관한 것이다. 사람이 변경 사항을 작성할 때 동료들은 왜 특정 실행 전략을 선택했는지 물을 수 있다. 생성된 코드의 경우에도 조직에는 해당 전략을 설명하고 승인할 책임 있는 소유자가 필요하다.

에이전트 파이프라인 검증은 이러한 소유권 모델의 일부가 된다. 시스템이 자동으로 확인하는 속성과 검토자에게 남겨지는 의사결정을 정의한다. 작동하는 코드를 생성하라는 모호한 지시는 이 구분을 해결하지 못한다.

가령 예시적인 판매 보고 파이프라인을 생각해 보자. 에이전트는 주문을 고객 레코드와 결합하고 지역별 매출을 요약하라는 요청을 받는다. 작업은 단순해 보이지만 승인 기준에는 여러 독립적인 결정이 포함된다.

엔지니어링 팀은 취소된 주문을 포함할지, 어떤 고객 주소로 지역을 정의할지, 환불이 매출에 어떤 영향을 주는지를 결정해야 한다. 에이전트가 코드를 얼마나 유창하게 작성하든 이 결정은 여전히 필요하다.

플랫폼은 참조된 객체가 존재하는지 확인하는 데 도움을 줄 수 있다. 그러나 매출이라는 표현으로 판매 조직이 무엇을 의도했는지는 독립적으로 결정할 수 없다. 두 질문을 하나의 승인 단계로 취급하면 성공적인 실행이 실제보다 더 결정적인 것처럼 보이게 된다.

압력은 플랫폼 구매자에게도 미친다. 그럴듯한 데이터세트를 생성하는 데모는 이해하기 쉽다. 불완전한 요구사항, 잘못된 참조, 거부된 변경에 시스템이 어떻게 대응하는지를 평가하려면 더 엄격한 시연이 필요하다.

따라서 구매자는 공급업체에 실패한 시도를 보여 달라고 요구해야 한다. 관련 근거에는 에이전트에 반환되는 피드백, 소비된 리소스, 수정 과정에서 허용되는 권한이 포함된다. 다듬어진 최종 결과는 이러한 운영 세부 사항을 보이지 않게 만든다.

이는 효과적인 평가의 모습을 바꾼다. 에이전트의 첫 번째 답변은 여전히 중요하지만, 잘못된 시도에서 승인된 산출물까지 이르는 과정도 중요하다. 주변 시스템은 그 과정이 무엇을 건드릴 수 있는지를 결정한다.

검토 역량도 똑같이 주목할 필요가 있다. 생성된 변경 사항이 검토자가 평가할 수 있는 속도보다 빠르게 도착한다면, 더 짧은 제출물은 부분적인 완화책일 뿐이다. 팀에는 여전히 명확한 승인 기준, 소유권, 그리고 각 변경 뒤의 가정에 대한 기록이 필요하다.

이러한 이유로 아키텍처 논의는 데이터 엔지니어링 전문가를 넘어선다. 분석가와 비즈니스 소유자도 올바른 결과가 무엇을 의미하는지 정의함으로써 참여한다. 이들의 결정은 배포 후의 비공식적인 설명이 아니라 검증의 입력값이 된다.

실질적인 대응은 에이전트 접근 권한을 확대하기 전에 이러한 책임을 명시하는 것이다. 그렇지 않으면 자동화는 제출 속도만 높이고 조직의 승인 프로세스는 그대로 둔다.

더 이른 거부는 재시도의 경제성을 바꾼다

기술적 이점은 전체 데이터 작업을 수행하기 전에 제약된 설명을 검사하는 데서 나온다.

Apache Spark의 선언형 파이프라인 가이드는 파이프라인 데이터를 읽거나 쓰지 않는 검증 실행인 dry run을 문서화한다. 이는 잘못된 문법, 확인할 수 없는 테이블 또는 열, 순환 종속성 등의 문제를 검사한다. 프레임워크는 또한 데이터세트 종속성을 분석해 실행 순서를 구성한다.

문서화된 이 동작은 아키텍처 주장의 구체적인 기반을 제공한다. 파이프라인 설명은 프레임워크가 결과를 생성하기 전에 검사할 수 있는 정보를 드러낸다. 에이전트는 그 설명에 대한 피드백을 받고 전체 실행을 요청하기 전에 수정할 수 있다.

경제적 질문은 각 피드백 범주를 어디에 배치할 것인가다. 선언된 관계에서 문제를 식별할 수 있다면, 더 큰 실행을 통해 이를 발견하는 것은 피할 수 있는 작업을 추가한다. 작성자가 사람이더라도 같은 논리가 적용된다.

에이전트는 수정이 워크플로의 일부이기 때문에 이러한 설계 선택을 특히 중요하게 만든다. 요청은 후보안을 만들고, 검증기는 이를 거부하며, 에이전트는 대체안을 제출할 수 있다. 이 교환의 비용은 관련 도구에 따라 달라진다.

조직은 저렴한 거부와 무료 거부를 구분해야 한다. 검증에도 소프트웨어 실행, 메타데이터, 지원 인프라가 필요하다. 피드백을 해석하는 데도 시간이 든다. 이러한 비용은 전체 실행보다 작더라도 평가에 포함돼야 한다.

유용한 비교 기준은 실행 가능한 정보를 얻기 위해 필요한 리소스 투입이다. 잘못된 참조를 식별하는 정확한 거부는 범위가 좁은 수정을 유도할 수 있다. 반면 일반적인 실패 메시지는 에이전트가 무엇을 바꿔야 하는지 추측하게 만들 수 있다.

이는 오류 품질을 아키텍처 기능으로 만든다. 문제를 감지하지만 설명이 부실한 플랫폼도 불필요한 수정을 유도할 수 있다. 에이전트 파이프라인 검증을 평가하는 팀은 최종 성공률과 함께 피드백 자체를 살펴봐야 한다.

재현성에 관한 질문도 있다. 검증과 실행이 서로 다른 가정을 사용한다면, 승인된 설명이 이전 검사가 고려하지 못한 이유로 나중에 실패할 수 있다. 구매자는 각 단계가 어떤 환경 세부 사항을 공유하는지 물어야 한다.

따라서 선언형 파이프라인과 절차형 파이프라인 논의에는 더 정확한 어휘가 도움이 된다. 관련 속성은 검사 가능한 의도, 유용한 피드백, 통제된 실행, 그리고 명확히 명시된 한계다. 프로그래밍 방식의 명칭만으로는 이 모든 것을 입증할 수 없다.

프레임워크 제약은 허용 가능한 작업의 범위를 좁힘으로써 도움이 될 수 있다. 그러나 제약은 어떤 워크로드가 자연스럽게 맞는지도 결정한다. 특이한 실행 요구사항이 있는 팀은 기존의 모든 스크립트가 깔끔하게 매핑된다고 가정하지 말고, 그에 따른 절충안을 평가해야 한다.

Spark Declarative Pipelines 벤치마크를 가장 강하게 해석하면 작성 아키텍처 자체가 별도의 평가를 받을 가치가 있다는 것이다. 에이전트를 선택한 뒤 실행 환경을 부차적인 세부 사항으로 취급하면 중요한 비용 요인을 검토하지 못하게 된다.

이는 완료된 작업만큼 재시도도 신중하게 측정해야 한다는 실질적인 주장이다. 제출과 승인 사이에서 소비되는 리소스는 제품 동작의 일부를 이룬다.

dbt와 Airflow가 레이블을 신중하게 다뤄야 하는 이유를 보여준다

경쟁 접근 방식은 단순한 선언형 승자와 절차형 패자 순위에 넣기보다 책임과 적용 범위에 따라 비교해야 한다.

Airflow의 워크플로 종속성 모델은 일정, 작업, 실행 종속성 및 운영 동작을 설명한다. 해당 문서는 이러한 오케스트레이션을 개별 작업 안에서 수행되는 작업과 명시적으로 구분한다. 오케스트레이션은 작업이 언제, 어떤 조건에서 실행되는지를 조정하는 것을 의미한다.

그 구분은 여기서 중요합니다. 조직은 더 광범위한 워크플로 조정 체계를 유지하면서도 변환 작성 방식을 개선할 수 있습니다. 변환 코드에만 국한된 비교만으로는 주변 스케줄링 시스템이 불필요해졌다고 결론지을 수 없습니다.

이 점은 흔히 발생하는 범주 오류를 막아줍니다. 파이프라인에는 다른 도구로 정의된 워크플로 안에서 선언형 변환이 포함될 수 있습니다. 동일한 프로덕션 프로세스의 서로 다른 부분을 서로 다른 구성 요소가 담당할 수 있습니다.

구매자에게 중요한 질문은 어떤 구성 요소가 어떤 속성을 검증하는가입니다. 스케줄러가 작업 순서를 인식한다고 해서 생성된 레코드의 정확성이 자동으로 보장되지는 않습니다. 반대로 유효한 변환이라고 해서 제공 과정 전반의 모든 운영 종속성이 해결되는 것도 아닙니다.

dbt는 데이터 테스트 어설션을 통해 또 다른 유용한 기준점을 제공합니다. 이러한 검사는 고유성, 누락 값, 허용 값, 레코드 간 관계 등의 속성을 평가합니다. 팀은 실패한 행을 식별하는 쿼리를 통해 조직별 어설션도 표현할 수 있습니다.

이러한 기능은 플랫폼이 파이프라인을 검사한다는 포괄적인 주장보다 검증 범위가 더 주목받아야 하는 이유를 보여줍니다. 서로 다른 검사는 서로 다른 질문에 답합니다. 구조 검증과 출력 어설션은 별개의 속성을 살피면서도 모두 성공할 수 있습니다.

예시 판매 데이터세트에서 모든 주문이 알려진 고객을 참조해야 한다고 가정해 보겠습니다. 관계 어설션은 이 요구사항을 다룹니다. 그러나 선택된 고객 레코드가 해당 판매 시점의 올바른 과거 상태를 나타내는지는 여전히 미해결로 남습니다.

바로 이 지점에서 제품 비교가 실무자에게 유용해집니다. 하나의 프레임워크가 판단을 없앤다고 암시하기보다, 남아 있는 의사결정을 드러냅니다. 그러면 구매자는 자체 요구사항에 얼마나 많은 추가 엔지니어링이 필요한지 평가할 수 있습니다.

따라서 관련 경쟁 압력은 구체적입니다. 공급업체는 생성된 작업이 구조 검사, 비즈니스 검사, 운영 통제를 어떻게 통과하는지 설명해야 합니다. 작성이 쉬워진다는 일반적인 약속만으로는 이러한 질문에 답할 수 없습니다.

기존 팀은 관련된 마이그레이션 결정을 마주합니다. 익숙한 코드를 대체하면 검토, 교육, 운영 작업도 새로 발생합니다. 예상되는 절감 효과는 독립적으로 제시하기보다 이 전환 비용과 비교해 평가해야 합니다.

모든 구성 요소에 단 하나의 프로그래밍 스타일을 선택해야 할 필요는 없습니다. 더 방어 가능한 접근법은 각 책임을 팀이 동작을 이해하고 점검할 수 있는 시스템에 할당하는 것입니다.

이것은 공급업체 포지셔닝도 적정한 수준으로 유지합니다. 이 벤치마크는 특정 작성 방식의 비교를 다룹니다. 모든 경쟁 플랫폼, 모든 도구 조합, 또는 기존 데이터 스택을 바꾸는 전체 비용을 측정하지는 않습니다.

구조적 유효성만으로는 비즈니스 로직과 접근 결정이 해결되지 않는다

파이프라인은 프레임워크의 구조 규칙을 충족하면서도 잘못된 비즈니스 답을 산출할 수 있습니다.

Databricks는 각 접근 방식당 264개 중 절차형 빌드에서 73건, 선언형 빌드에서 85건의 무음 오류가 발생했다고 보고합니다. 이는 실패 없이 잘못된 출력을 반환한 실행입니다. 회사는 선언형 작성을 이 범주의 해결책으로 제시하지 않습니다.

이러한 한계는 배포 결정을 좌우해야 합니다. 검사가 성공했다는 것은 제출된 작업이 해당 검사가 살핀 조건을 충족했다는 뜻입니다. 이것이 조직의 요구사항이 충족되었다는 더 넓은 의미를 암묵적으로 갖게 해서는 안 됩니다.

dbt의 SQL 단위 테스트는 적절한 비교 대상입니다. 전체 프로덕션 모델이 빌드되기 전에 작고 미리 정의된 입력을 바탕으로 변환 로직을 평가합니다. 이러한 예시는 경계 사례와 예상 결과를 검증할 수 있지만, 적용 범위는 테스트 작성자가 무엇을 지정하는지에 달려 있습니다.

독립적인 명세는 필수적입니다. 동일한 잘못된 가정이 생성된 코드와 생성된 테스트 모두에 반영되면, 둘 사이의 일치는 제한적인 안심만 제공합니다. 검토자에게는 예상 결과를 판단할 외부 근거가 필요합니다.

판매 보고 예시로 돌아가 보겠습니다. 테스트는 환불된 주문을 의도적으로 포함하고, 그 주문이 매출에 기여해야 하는 기대값을 정의할 수 있습니다. 그 가치는 일반적인 관행에 관한 에이전트의 확신이 아니라 승인된 회계 규칙에서 나옵니다.

날짜도 마찬가지입니다. 변환은 유효한 타임스탬프 필드를 사용하면서도 거래를 잘못된 보고 기간에 배정할 수 있습니다. 기간 경계에 대한 명시적 예시는 검토자가 평가할 구체적인 기준을 제공합니다.

이는 벤치마크에서 보고된 실패 사례가 아니라 예시 사례입니다. 구조적 정확성과 비즈니스 정확성에 별도의 승인 기준이 필요한 이유를 보여줍니다. 이를 하나의 녹색 상태 아래 결합하면 그 차이가 가려집니다.

접근 결정에는 또 다른 경계가 필요합니다. Apache Spark의 배포 보안 가이드는 보안이 구성과 배포 맥락에 따라 달라진다고 설명합니다. 인증과 기타 보호 기능이 기본적으로 항상 활성화되는 것은 아니라고 경고합니다. 이러한 설명은 Databricks의 관리형 서비스에 관한 결과가 아니라 일반적인 Spark 배포에 관한 것입니다.

에이전트 도입에서 시사점은 분명합니다. 검증 기능이 전체 보안 모델을 정의하지는 않습니다. 조직은 여전히 어떤 ID가 작업을 제출하고, 메타데이터를 점검하며, 변경을 실행하고, 결과를 게시할 수 있는지 결정해야 합니다.

이 책임은 파일럿 기간에도 분명히 유지되어야 합니다. 에이전트의 운영 범위를 제한하면 팀은 작성 능력과 광범위한 프로덕션 권한을 혼동하지 않고 그 동작을 평가할 수 있습니다. 적절한 범위는 배포 환경에 따라 달라집니다.

인적 검토에도 지속 가능한 근거가 필요합니다. 요구사항, 알려진 예외, 이전 결정은 검토자가 코드와 함께 참고할 수 있는 검색 가능한 지식 기반에 속해야 합니다. 문서는 결과가 기대되는 이유를 설명하는 데 도움이 되며, 테스트는 정의된 기대값이 충족되는지를 판정합니다.

미해결 질문은 완전한 워크플로가 얼마나 많은 보증을 제공하는가입니다. 조기 거부는 의미 있는 실패 범주를 다루지만, 성공적인 실행을 둘러싼 요구사항과 권한에 대한 책임은 조직에 남아 있습니다.

재현, 프로덕션 회계, 검토 결과를 주시하라

다음으로 유용한 증거는 아키텍처상의 이점이 더 폭넓은 워크로드에서도 유지되고 승인 프로세스를 개선하는지를 보여줘야 합니다.

향후 몇 달 동안 가장 먼저 주목할 신호는 독립적 재현입니다. 평가자는 작업 정의, 에이전트 지침, 검증 규칙, 종료 조건을 공개해야 합니다. 이러한 세부 정보가 없으면 겉보기에는 유사한 비교도 서로 다른 작업 환경을 측정할 수 있습니다.

다양한 작업에서 이점을 유지하는 재현 결과는 더 이른 구조 피드백의 근거를 강화할 것입니다. 절차형 기준선에 따라 결과가 크게 달라진다면 결론의 범위는 좁아지고, 어떤 보호 장치가 가장 중요했는지도 드러날 것입니다.

두 번째 신호는 프로덕션 회계입니다. 팀은 초기 요청부터 승인된 변경까지의 경로를 포괄하는 측정값이 필요합니다. 이는 모델 사용량, 검증 활동, 실행 리소스, 경과 시간, 후속 수정 작업을 별도 범주로 기록한다는 뜻입니다.

전반적인 작업량이 더 적다는 증거는 단일 리소스 비율보다 도입을 더 직접적으로 뒷받침합니다. 통합 및 검토 비용을 포함한 뒤 절감 효과가 사라진다면, 이점의 범위는 더 제한적입니다. 어느 결과든 구매자가 더 정확한 결정을 내리는 데 도움이 됩니다.

세 번째 신호는 배포 후 검토 품질입니다. 조직은 검토자가 릴리스 전에 잘못된 가정을 식별하는지, 승인된 파이프라인이 나중에 의미론적 수정을 필요로 하는지를 추적해야 합니다. 의미론적 수정은 단순히 실행을 복구하는 것이 아니라 의미를 바꿉니다.

개선된 검토 결과는 제약된 작성 형식이 팀의 생성 작업 관리를 돕는다는 주장을 강화할 것입니다. 오류 결과가 변하지 않는다면 효율성의 근거는 유지되지만 신뢰성에 대한 주장은 제한됩니다. 이는 발표된 출시 일정이 아니라 관찰 기준입니다.

이 구분은 중요합니다. 그렇지 않으면 공급업체와 구매자가 서로 다른 이야기를 할 수 있기 때문입니다. 공급업체는 실행 낭비 감소를 설명하는 반면, 구매자는 비즈니스 위험 감소를 가정할 수 있습니다. 양측 모두 어떤 결과를 평가하는지 명시해야 합니다.

Spark Declarative Pipelines 벤치마크는 팀이 이 격차를 살펴볼 구체적인 이유를 제공합니다. 더 넓은 관련성은 실행 시스템이 제안된 작업을 수신하고, 검사하고, 승인하는 방식에 있습니다. 에이전트가 구현에 더 많이 관여할수록 이러한 설계 선택은 계속 중요합니다.

엔지니어링 리더에게 다음 결정은 실제 요구사항과 연결된 범위가 제한된 평가여야 합니다. 비즈니스가 이미 기대 출력을 이해하는 작업을 선택하십시오. 각 접근 방식이 요구하는 리소스와 주의를 살피는 동안 승인 규칙은 안정적으로 유지하십시오.

실패한 시도도 성공적인 제출과 함께 증거로 보존하십시오. 각 검증기가 무엇을 검사했는지, 검토자가 여전히 무엇을 결정해야 했는지, 어떤 가정에 설명이 필요했는지를 기록하십시오. 이 기록은 더 빠른 반복이 승인도 더 쉽게 만드는지 보여줄 것입니다.

에이전트 접근 권한을 확대하기 전에, 승인된 파이프라인의 정확한 의미를 팀이 식별하도록 하십시오. 승인은 구조, 비즈니스 결과, 권한 또는 일부만을 포괄합니까? 그 답을 활용해 기존 워크플로와 비교하여 Spark Declarative Pipelines를 평가하고, 더 광범위한 모든 주장에는 근거를 요구하십시오.