Microsoft Copilot 합성 데이터, 기업 평가의 프라이버시 공백 겨냥

Microsoft는 2026년 10월 30일 고객 데이터를 사용하지 않고 시뮬레이션된 조직을 대상으로 Copilot을 시험하는 기업용 평가 플랫폼을 공개했다. Microsoft Copilot 합성 데이터는 어려운 충돌을 다룬다. 업무용 어시스턴트에는 현실적인 테스트가 필요하지만, 기밀 비즈니스 기록이 제한 없는 연구 자료가 되어서는 안 된다는 문제다.

이 접근법은 고립된 질문과 잘 다듬어진 데모로 업무용 AI를 평가해 온 익숙한 지름길에 압박을 가한다. 어시스턴트는 깔끔한 문서를 정확히 요약할 수 있지만, 상충하는 메시지 곳곳에 흩어진 의사결정은 잘못 이해할 수 있다. 직원들이 답변에 의존하기 전에 기업의 신뢰는 이 두 상황을 구별하는 데 달려 있다.

Salesforce의 CRMArena 연구는 유용한 기준점이다. 두 접근법 모두 시뮬레이션된 비즈니스 환경을 평가 인프라로 본다. 핵심 긴장은 현실성과 프라이버시 사이에 있다. 개발자는 보호해야 할 민감한 정보를 가져오지 않고 조직의 복잡성을 어디까지 재현할 수 있을까?

Microsoft Copilot 합성 데이터, 평가를 시뮬레이션 조직으로 확장

Microsoft는 이 시스템을 Industry Evaluation Data Generation Platform이라고 부른다. 이 enterprise evaluation platform은 Copilot 테스트를 위한 조직 환경과 질문을 생성한다. 회사는 이를 공개 인증이 아니라 내부 공통 기준선으로 설명한다.

Microsoft는 수백 명의 시뮬레이션 사용자가 포함된 제약, 자본시장, 소프트웨어 분야 환경을 다룬다고 밝혔다. 공개 직업 정보, 채용 공고, 기업 공시가 이러한 환경 구성에 활용된다. 생성된 커뮤니케이션과 업무 이력은 평가 질문의 맥락을 제공한다.

이 변화는 새롭게 확립된 업무 신뢰성 척도라기보다 더 폭넓은 테스트 환경이다.

이 구분은 유용한 테스트가 단순히 그럴듯해 보이는 문장을 만들어내는 데 그치지 않고 정보 간 관계를 재현해야 한다는 점에서 중요하다. 회의 요약은 신뢰할 만하게 들리면서도 책임을 잘못된 사람에게 배정할 수 있다. 답변은 실제 문서를 인용하면서도 이를 대체한 후속 논의를 놓칠 수 있다.

가상의 제품 출시 사례를 생각해 보자. 초기 계획 문서는 출시일을 명시한다. 이후 회의에서는 의존성이 추가된다. 나중에 이메일은 수정된 약속을 기록한다. 각 자료는 개별적으로 이해할 수 있지만, 현재 마감일에 관한 질문에 답하려면 이들 간의 관계를 연결해야 한다.

계획 문서만 담긴 테스트는 완전한 가상 이력이 포함된 테스트와 같은 실패를 드러낼 수 없다. 차이는 최종 문단이 얼마나 매끄러운지가 아니라, 어시스턴트가 무엇을 판단해야 하는지에 있다.

이 때문에 익숙한 질의응답 형식으로 기업용 어시스턴트를 평가하면 중요한 행동이 검증되지 않을 수 있다. 정확성은 때로 사실을 확인하는 것을 뜻한다. 다른 경우에는 이전 사실이 더 이상 해당 의사결정을 좌우하지 않는다는 점을 인식하는 것을 뜻한다.

시뮬레이션 조직은 통제된 비교 기회도 만든다. 평가자는 기본 상황을 동일하게 유지하면서 어시스턴트만 바꿀 수 있다. 따라서 수정된 시스템이 이전에 문제가 되었던 사례를 더 정확히 처리하는지 조사하기 쉬워진다.

그러나 반복 가능성과 현실성은 서로 다른 질문에 답한다. 반복 가능한 테스트는 일관된 비교를 확립한다. 현실적인 테스트는 그 비교가 사람들이 실제로 필요로 하는 행동에 관한 것임을 보여준다. 평가 프로그램의 결과가 설득력을 가지려면 두 특성이 모두 필요하다.

따라서 이 뉴스는 인프라 범주에 속한다. 그 중요성은 혼란스러운 모든 답변을 고립된 사건으로 취급하는 대신, 기업 환경의 행동을 체계적으로 점검할 가능성에 있다.

독자가 취해야 할 해석은 구체적이다. Microsoft는 더 풍부한 테스트를 구성하는 방법을 설명했다. 이 설명만으로 Copilot이 특정 기업의 의사결정, 용어 또는 문서 이력을 얼마나 신뢰성 있게 처리하는지는 입증되지 않는다.

기업 구매자는 업무에 부합하는 증거가 필요하다

당장의 압박은 업무용 AI 승인 책임이 있는 팀에 가해진다. 설득력 있는 데모만으로는 수용 가능한 실패율을 정의할 수 없기 때문이다.

조달팀은 제품 약속을 평가한다. 직원들은 개별 답변을 마주한다. 그 사이에는 실용적인 질문이 있다. 어떤 오류는 배포를 막아야 하며, 어떤 오류는 기존 검토 절차로 잡아낼 수 있는가?

가상의 제약 검토 사례를 상상해 보자. 요약은 논의를 정확히 포착하지만, 해결되지 않은 안전 우려를 빠뜨린다. 이는 반드시 날조된 정보의 문제는 아니다. 독자가 팀이 무엇을 결론 내렸는지에 대해 믿는 내용을 바꾸는 누락이다.

일반적인 글쓰기 점수로는 이 차이를 표현하기 어렵다. 명확한 언어, 간결한 형식, 정확한 용어는 중대한 오해와 공존할 수 있다. 평가는 단지 문장의 품질이 아니라 과업에 수반되는 의무를 인식해야 한다.

같은 구분은 일상적인 사무 업무에도 적용된다. 어시스턴트는 제안을 정확히 설명하면서도 경영진이 이를 거부했다는 사실을 언급하지 못할 수 있다. 최신 결정을 묻는 직원에게는 제안서에 더 많은 세부 내용이 있더라도 거부 사실이 필요하다.

이 사례들은 기업용 AI 평가가 판매업체뿐 아니라 구매자에게도 압박을 만드는 이유를 보여준다. 구매자는 워크플로 내에서 성공적인 행동이 무엇인지 명확히 해야 한다. 판매업체는 편의적인 근사치가 아니라 그러한 기대에 부합하는 증거를 제시해야 한다.

따라서 관련 비교 대상은 평가 과업과 의도된 사용 사례다. 문서 초안 작성 결과가 회의 분석에 관한 주장을 자동으로 뒷받침하지는 않는다. 성공적인 정보 검색이 상충하는 증거에 대한 건전한 판단을 자동으로 입증하지도 않는다.

개발자에게 이는 실패를 조사하는 방식의 변화를 뜻한다. 잘못된 답변은 문서 선택, 해석 또는 최종 요약에서 비롯될 수 있다. 모든 실패를 언어 모델 문제로 취급하면 주의가 필요한 구성 요소를 가릴 수 있다.

지식 근로자에게 실질적인 쟁점은 추적 가능성이다. 즉, 답변을 뒷받침하는 자료까지 거슬러 올라갈 수 있는 능력이다. 읽기 쉬운 인용은 도움이 되지만, 인용된 구절이 실제로 결론을 뒷받침해야 한다. 그렇지 않으면 증거가 있다는 인상 자체가 또 다른 잘못된 신뢰의 원인이 된다.

이 우려는 personal and team knowledge의 구분에서도 나타난다. 어떤 어시스턴트가 개입하든, 정보 접근과 정보의 신뢰할 수 있는 해석은 별개의 책임으로 남는다.

Microsoft Copilot 합성 데이터는 평가 환경 자체를 논의의 일부로 만든다는 점에서 기업 구매와 관련이 있다. 구매자는 연구자에게 제한 없는 내부 기록의 검토를 요청하지 않고도 테스트가 자신의 업무와 유사한지 물을 수 있다.

그에 따른 의무는 구체적이다. 배포 근거는 검토한 과업, 집계한 오류, 제외한 상황을 밝혀야 한다. 이러한 범위가 없으면 신뢰는 제품명에 붙은 일반적인 인상에 그친다.

Salesforce는 비즈니스 시뮬레이션에 까다로운 과업이 필요한 이유를 보여준다

Salesforce는 고객 기록과 관련 비즈니스 활동을 정리하는 소프트웨어인 고객 관계 관리에 연구의 초점을 맞추고 있어 유용한 비교 대상이다. 이 환경은 연결된 기록과 운영 과업을 강조한다.

공개된 CRMArena benchmark에서 연구진은 서비스 에이전트, 분석가, 관리자 역할 전반에 걸쳐 9개의 고객 서비스 과업을 설계했다. 환경에는 계정, 주문, 사례 등 서로 연결된 16개의 비즈니스 객체가 포함됐다.

논문의 초록은 한 프롬프팅 접근법에서 과업 성공률이 58% 미만이었고, 함수 호출 기능을 사용했을 때도 65% 미만이었다고 보고한다. 함수 호출은 모델이 사전 정의된 소프트웨어 작업을 요청할 수 있게 한다.

이 결과는 연구의 시스템과 조건에 관한 것이지 현재 Copilot 성능에 관한 것은 아니다. 그럼에도 현실적인 비즈니스 과업이 별도의 평가를 받아야 하는 이유를 보여준다. 그럴듯한 언어 생성만으로 어시스턴트가 운영 규칙을 따를 수 있는지는 판단할 수 없다.

유용한 비교는 어느 판매업체가 가장 큰 점수를 부여하는지가 아니라, 환경이 무엇을 테스트하는지에 관한 것이다.

Salesforce의 후속 organization data generator는 Salesforce 환경을 위한 합성 기록과 평가 질문 생성을 설명한다. 이 접근법은 기록, 필드 및 그 관계를 정의하는 구조인 제공된 스키마를 사용한다.

이 강조점은 유익한 대조를 만든다. 고객 서비스 테스트는 어시스턴트가 고객 불만을 적절한 주문 및 계정과 연결하는지 물을 수 있다. 업무 지식 테스트는 어시스턴트가 의사결정을 이를 확립한 커뮤니케이션과 연결하는지 물을 수 있다.

이는 관련된 과제이지만 성공 기준은 다르다. 기록 찾기, 논의 해석, 비즈니스 시스템 변경에는 서로 다른 의무가 따른다. 한 범주를 잘 처리하는 벤치마크가 다른 범주를 자동으로 대신할 수는 없다.

가상의 지원 사례는 이 차이를 분명히 한다. 고객이 배송 지연에 대해 문의한다. 어시스턴트는 올바른 주문을 찾지만 다른 고객 범주에 적용되는 환불 규칙을 적용한다. 검색은 성공했지만 비즈니스 과업은 실패했다.

이제 가상의 회의 질문과 비교해 보자. 어시스턴트는 올바른 논의를 찾지만 잠정적 제안을 승인된 조치로 간주한다. 이 경우에도 관련 정보를 찾는 것만으로는 충분하지 않다. 오류는 증거의 의미에 관한 것이다.

두 시나리오는 같은 평가 원칙을 뒷받침한다. 어려운 사례는 부분적 진전과 완료된 업무를 구별해야 한다. 그렇지 않으면 시스템은 정보에 도달했지만 그에 따른 의무를 놓친 경우에도 점수를 얻게 된다.

경쟁 측면에서의 의미는 동일한 벤치마크보다는 입증 책임에 더 가깝다. 기업용 어시스턴트를 설명하는 판매업체는 워크플로 행동에 관한 점점 더 구체적인 질문에 직면한다. 일반 지능 점수로는 이 모든 질문에 답할 수 없다.

판매업체 간 비교에도 신중함이 필요하다. 서로 다른 환경, 과업, 도구, 채점 규칙은 서로 다른 능력을 측정하면서도 비교 가능한 것처럼 보이는 수치를 만들 수 있다. 의미 있는 비교를 하려면 시스템 순위를 매기기 전에 이러한 조건을 정렬해야 한다.

구매자에게 교훈은 점수 뒤의 과업을 살펴보는 것이다. 개발자에게는 수정할 가치가 있는 오류를 드러내는 테스트를 구성하는 일이다. Microsoft에 있어 Salesforce의 작업은 직접적인 성능 경쟁을 확립하지 않으면서도 관련 맥락을 제공한다.

현실적인 데이터도 오해를 부르는 신뢰를 만들 수 있다

Microsoft는 합성 데이터 품질의 내부 복합 척도가 39% 개선됐다고 보고했다. 이 수치는 Copilot 답변 정확도의 측정된 개선이 아니라 생성된 환경에 관한 것이다.

더 나은 테스트 자료는 그 개선이 테스트 밖에서 중요한 행동을 드러낼 때에만 평가를 강화한다.

종합 지표는 여러 평가를 하나의 전체 결과로 결합한다. 이는 진행 상황을 추적하는 데 도움이 될 수 있지만, 해석은 구성 요소에 따라 달라진다. 총점이 높다고 해서 어떤 약점이 남아 있는지, 또는 그것이 의도한 작업에 어떤 영향을 미치는지는 설명하지 못한다.

가령 예시 생성기가 더 그럴듯한 직함과 더 명확한 보고 체계를 만들어 낸다고 가정해 보자. 이러한 변화는 가상의 조직을 개선한다. 그러나 반드시 질문을 더 어렵게 만들거나, 추가적인 어시스턴트 실패 사례를 드러내거나, 업무 성과에 대한 예측을 개선하는 것은 아니다.

반대로 의도적으로 어색한 자료는 피상적인 현실성 평가는 낮출 수 있지만, 평가 자체는 더 유익하게 만들 수 있다. 일관되지 않은 용어, 불완전한 대화, 해결되지 않은 이견은 바로 어시스턴트가 신중하게 처리해야 하는 상황을 만들 수 있다.

분석적 질문은 현실성 측정이 유용한 난이도에 보상을 주는지 여부다. 깔끔한 가상 기업은 내부적으로 일관될 수 있지만, 실제 업무를 까다롭게 만드는 모호함은 빠뜨릴 수 있다.

이 지점에서 평가자 독립성도 중요하다. 생성 과정이 상황과 기대 답변을 모두 만들면, 공통된 가정이 보이지 않은 채 남을 수 있다. 답변은 작성자와 일치하면서도 인간 독자라면 합리적이라고 볼 해석을 놓칠 수 있다.

이 가능성은 Microsoft 플랫폼의 확인된 결함이 아니라 일반적인 방법론적 위험이다. 이는 생성형 벤치마크를 더 설득력 있게 만들 증거, 즉 외부 검토, 까다로운 반례, 논쟁이 있는 답변에 대한 명확한 처리를 제시한다.

관련된 또 다른 문제는 불확실성이다. 일부 엔터프라이즈 질문은 단정적인 답변을 내놓아서는 안 된다. 이용 가능한 자료는 이견, 누락된 승인 또는 불충분한 증거를 보여줄 수 있다. 언제나 명확한 결론을 기대하는 평가는 정당화되지 않은 확신에 보상을 줄 수 있다.

지연된 프로젝트의 책임자가 누구인지 묻는 예시 요청을 생각해 보자. 서로 다른 문서가 서로 다른 사람을 지목하고, 최종 인계 기록은 나타나지 않는다. 유용한 어시스턴트라면 이 공백을 식별해야 한다. 가장 자주 언급된 사람을 고르면 책임 소재를 해결하지 못한 채 겉보기 명확성만 만들어 낸다.

이 때문에 Microsoft Copilot synthetic data는 점수와 함께 해석할 필요가 있다. 더 풍부한 환경은 더 나은 질문을 뒷받침할 수 있지만, 어떤 행동이 인정받는지는 여전히 채점 규칙이 결정한다.

따라서 독자는 데이터세트 품질, 어시스턴트 성능, 업무 성과를 구분해야 한다. 이는 서로 연결된 증거의 층위이며, 각각 별도의 평가가 필요하다. 앞선 층위의 개선은 다음 층위를 테스트하기 위한 더 강한 기반을 제공한다.

가장 강력한 평가 주장은 이러한 연결을 명시적으로 설명할 것이다. 어떤 까다로운 사례가 개선됐는지, 어떤 실패가 지속됐는지, 그리고 그 결과가 배포 결정에 어떤 영향을 주었는지를 보여줄 것이다. 전체 현실성 점수만으로는 이 논거를 뒷받침할 수 없다.

개인정보 보호는 데이터의 출처와 보호 조치에 달려 있다

Microsoft는 자사 파이프라인이 고객 데이터를 제외하고 콘텐츠 안전성 검사를 적용한다고 말한다. 이 설계 선택은 중요하지만, 인위적으로 생성된 기록을 뜻하는 synthetic data는 개인정보 보호 특성이 서로 다른 광범위한 범주다.

개인정보 보호 평가는 “synthetic”이라는 표현을 완전한 보장으로 받아들이기보다 데이터가 어떻게 생성됐는지 검토해야 한다.

Theresa Stadler, Bristena Oprisanu, Carmela Troncoso의 연구는 synthetic data privacy에 관한 중요한 주의를 제공한다. 이들의 연구는 생성 방식 전반에서 개인정보 보호와 유용성을 검토했으며, 그 상충 관계를 예측하기 어려울 수 있음을 발견했다.

이 관련성에는 경계가 필요하다. 이들의 연구 결과는 Microsoft 플랫폼의 취약점을 입증하지 않는다. 고객 입력 없이 가상 조직을 생성하는 것은 민감한 원본 데이터세트에서 대체 기록을 생성하는 것과 다르다.

이 구분은 평가자가 물어야 할 질문을 바꾼다. 민감한 기록이 생성기에 들어가면 검토자는 출력물이 어떤 정보를 보존하는지 살펴봐야 한다. 공개 정보가 출발점을 제공할 경우에는 그 정보가 어디서 비롯됐고 어떻게 사용됐는지를 뜻하는 출처를 검토해야 한다.

이름이 가상으로 보이는지 확인하는 것만으로는 어느 쪽 질문에도 답할 수 없다. 생성된 기록은 직접적인 식별을 피하면서도 드문 속성 조합을 보존할 수 있다. 반대로 가상 콘텐츠는 비공개 고객 기록에서 유래하지 않았더라도 우연히 실제 개인과 닮을 수 있다.

이러한 가능성은 일률적인 의심이 아니라 신중한 해석을 요구한다. 생성 방식에 따라 노출 경로도 다르다. 개인정보 보호 주장은 입력, 변환, 검사, 허용된 사용을 식별할 때 유용해진다.

NIST의 differential privacy guidelines는 구체성의 필요성을 더욱 강조한다. differential privacy는 개인의 정보가 분석에 미치는 영향을 제한하는 수학적 프레임워크다.

이 지침은 공식적인 개인정보 보호 장치를 갖춘 synthetic 기법과 비공식적 보증을 제공하는 기법을 구분한다. 또한 생성 데이터가 불확실성을 초래하거나 특정 집단에 대한 유용성을 낮출 수 있다고 설명한다.

이는 모든 가상 비즈니스 환경이 동일한 통계적 방법을 채택해야 한다는 뜻은 아니다. 주장이 메커니즘과 일치해야 한다는 뜻이다. 기밀 원본 기록의 제외, 생성 콘텐츠의 선별, 공식적인 개인정보 보호 보장의 제공은 서로 다른 보호 조치다.

NIST의 synthetic data assessment 도구 역시 개인정보 보호와 효용성을 별도로 평가한다. 효용성이란 데이터세트가 의도된 분석에 얼마나 유용하게 남아 있는지를 뜻한다. 이 도구의 존재는 데이터 품질에 단일한 설명적 레이블 이상이 필요함을 보여준다.

엔터프라이즈 의사결정자에게 시사점은 실질적이다. 재사용 가능한 테스트 환경은 기밀 자료에 대한 노출을 줄이면서도 문서화된 보호 조치를 여전히 요구할 수 있다. 개인정보 보호와 평가 품질은 각각 이를 뒷받침하는 증거를 갖춰야 한다.

더 넓은 의미에서 중요한 것은 테스트 과정 자체에 대한 신뢰다. 직원들은 더 나은 제품 평가를 위해 자신의 커뮤니케이션 기밀성을 포기할 필요가 없어야 한다. 마찬가지로 그러한 커뮤니케이션을 보호하는 일이 제품 행동에 관한 약한 증거를 받아들이는 이유가 되어서는 안 된다.

독립적 테스트, 측정된 실패, 행동 수준의 증거를 주시하라

Microsoft는 장기 상호작용과 행동을 수행하는 시스템을 향후 평가 과제로 지목한다. 여러 단계를 거쳐 작업을 수행하는 소프트웨어인 agentic systems는 불완전한 평가의 결과를 더 뚜렷하게 만든다.

다음으로 유용한 증거는 더 풍부한 테스트를 관찰 가능한 행동과 연결하고, 결과가 무엇을 입증하는지에 대한 명확한 한계를 제시할 것이다.

앞으로 수개월 동안 주시할 첫 번째 신호는 독립적 검토다. 외부에서 검토할 수 있는 평가 패키지, 상세한 방법론 또는 문서화된 외부 평가는 테스트 접근법에 대한 신뢰를 강화할 것이다. 이런 것이 없다면 외부인은 내부 설명에 더 크게 의존하게 된다.

독립적 검토가 민감한 비즈니스 정보의 공개를 요구할 필요는 없다. 가상 환경은 까다로운 사례, 기대 답변, 채점 논리를 공유할 기회를 만든다. 중요한 질문은 다른 평가자가 답변이 왜 통과하거나 실패하는지 이해할 수 있는지다.

외부 검토자가 의미 있는 오류를 일관되게 식별할 수 있다면, 이 신호는 재사용 가능한 엔터프라이즈 테스트의 근거를 강화할 것이다. 특히 모호한 질문이나 근거 없는 기대 답변을 드러낸다면, 이견 역시 유익한 정보가 될 수 있다.

두 번째 신호는 제품 변화 전반에 걸친 작업 수준의 증거다. 설득력 있는 업데이트는 검토한 행동을 식별하고 수정된 어시스턴트가 이를 더 잘 처리했는지 설명할 것이다. 이는 또 하나의 현실성 점수보다 평가 인프라를 제품 품질과 더 직접적으로 연결할 것이다.

평균과 중대한 실패의 구분은 주목할 가치가 있다. 어시스턴트는 일상적인 요약에서는 개선될 수 있지만 해결되지 않은 결정을 계속 놓칠 수 있다. 이러한 범주를 별도로 보고하면 독자가 전체 개선이 실제로 무엇을 의미하는지 이해하는 데 도움이 된다.

더 풍부한 평가가 단순한 테스트가 놓친 실패를 드러낸다면 이 신호는 논거를 강화할 것이다. 보고된 개선이 생성 자료의 외관이나 내부 일관성에만 국한된다면 논거는 약화될 것이다.

세 번째 신호는 답변만이 아니라 행동에 관한 증거다. 잘못된 요약은 독자에게 부정확한 정보를 남긴다. 기록을 업데이트하거나 워크플로를 시작하는 어시스턴트는 누구든 그 추론을 검토하기 전에 업무 환경을 바꿀 수 있다.

예시 행동 테스트는 어시스턴트가 진행하기 전에 누락된 승인을 인식하는지 살펴볼 수 있다. 또 다른 테스트는 권한이 서로 다른 문서에서 상충하는 지시를 받았을 때 중단하는지 살펴볼 수 있다. 이 예시는 발표된 Microsoft 기능이 아니라 유용한 평가 대상을 설명한다.

따라서 관련된 결과는 성공적인 완료보다 더 광범위하다. 평가자는 요청된 행동에 근거가 없을 때 자제, 복구, 명확한 소통도 검토해야 한다. 근거 없는 단계를 거부하는 시스템은 모든 요청을 완료하는 시스템보다 더 신뢰성 있게 행동할 수 있다.

엔터프라이즈 구매자에게 Microsoft Copilot synthetic data는 더 구체적인 증거 요청을 제기해야 한다. 어떤 워크플로가 테스트됐는지, 무엇을 실패로 간주했는지, 모호한 상황에서 어시스턴트가 불확실성을 인정해야 했는지 물어야 한다. 이 범위를 직원들이 실제로 위임할 업무와 비교해야 한다. 기밀성 요구 사항을 명시적으로 유지하고, 공급업체가 보고한 결과와 독립적으로 검토된 결과를 구분해야 한다. 현실적인 가상 조직은 테스트를 더 유익하게 만들 수 있지만, 배포 결정에는 여전히 의도된 사용과 연결된 증거가 필요하다. 더 광범위한 의존을 승인하기 전에 조직이 어시스턴트가 가장 피해야 할 잘못된 결정을 식별하고, 평가가 이를 포착할 수 있는지 물어야 한다.