Huawei, 성능과 배터리 수명을 보호하기 위해 HarmonyOS 7 Immersive Light 규칙 강화
- Olivia Johnson

- 3시간 전
- 13분 분량
Huawei는 Immersive Light를 새 인터페이스 디자인의 핵심 요소로 홍보해 왔지만, HarmonyOS 7의 대표적인 시각 기능에 제한을 도입했다.
이 변경 사항은 2026년 9월 3일 Huawei의 플랫폼 동작 문서에 나타났다. 애플리케이션이 SDK 버전 26.0.0 이상을 대상으로 할 경우 개발자가 이 머티리얼 효과를 적용할 수 있는 위치를 제한한다.
Immersive Light는 반투명 표면, 반사색, 깊이감, 반응형 조명을 위한 Huawei의 시스템 머티리얼이다. 이를 사용하면 컨트롤이 평면 화면 위에 그려진 요소가 아니라 콘텐츠 위에 떠 있는 것처럼 보일 수 있다.
새 규칙이 이 시각 언어 자체를 없애는 것은 아니다. 대신 내비게이션, 대화상자, 메뉴 및 일부 컨트롤 주변으로 효과를 집중한다.
이 구분은 중요하다. Coolapk를 통해 유통된 한 보도는 이번 변경을 성능과 전력 소비를 보호하기 위한 HarmonyOS 7의 기능 “강화”로 묘사했다. 근본적인 사건 자체는 사실이지만, 해당 집계 사이트는 게시 시점을 입증하지 못했다.
확인된 업데이트 날짜는 9월 3일이다. Huawei는 이 제한이 최상의 성능 및 전력 경험을 제공하는 동시에 컴포넌트 사용을 표준화하기 위한 것이라고 설명한다.
그 결과는 흥미로운 절충안이다. Huawei는 Immersive Light가 운영체제를 식별하는 요소가 되길 원하지만, 모든 개발자가 어디서나 이 효과를 사용하길 바라지는 않는다.
Apple은 Liquid Glass를 컨트롤, 내비게이션, 아이콘, 위젯, 여러 운영체제로 확장하는 더 폭넓은 방식을 택했다. Huawei는 표현력이 강한 표면과 일반적인 애플리케이션 콘텐츠 사이에 더 명확한 경계를 긋고 있다.
개발자에게 이는 단순한 장식적 각주가 아니다. 기존 코드는 계속 컴파일될 수 있지만, 대상 SDK가 변경된 뒤에는 눈에 띄게 달라진 인터페이스를 만들 수 있다.
사용자에게 즉각적인 변화는 더 미묘할 가능성이 크다. 일부 서드파티 애플리케이션은 개발자가 원래의 머티리얼 설정을 그대로 두더라도 승인된 위치 밖에서는 유리 같은 표면을 잃게 된다.
따라서 더 큰 이야기는 HarmonyOS가 시각적 야심을 포기한다는 데 있지 않다. Huawei가 시각 효과를 무제한 스타일링 도구가 아니라 관리되는 시스템 리소스로 취급하고 있다는 점이다.
Huawei가 HarmonyOS 7에서 변경한 사항
이번 업데이트는 Immersive Light를 폭넓게 적용 가능한 머티리얼에서 위치 의존형 인터페이스 기능으로 전환한다.
변경 전에는 개발자가 관련 시스템 머티리얼을 활성화하면 지원되는 컴포넌트에서 효과를 표시할 수 있었다. 페이지 내 컴포넌트의 위치는 지금과 같은 제한을 부과하지 않았다.
변경 후에도 대화상자와 여러 인터랙티브 컨트롤은 폭넓은 접근 권한을 유지한다. 그 외 컴포넌트는 승인된 내비게이션 영역 안에서만 머티리얼을 표시한다.
제한 없이 사용할 수 있는 그룹에는 알림 대화상자, 액션 시트, 사용자 지정 대화상자, 날짜 및 시간 선택기, 선택 메뉴, 팝업, 팁, 반모달 전환이 포함된다. 슬라이더, 토글, 선택 컨트롤도 페이지 전체에서 계속 사용할 수 있다.
대부분의 다른 ArkUI 컴포넌트에는 이제 더 좁은 규칙이 적용된다. 이들의 Immersive Light 효과는 Navigation 또는 NavDestination 제목 표시줄 안에서 작동한다.
탭 표시줄이 하단에 배치된 수평 Tabs 컴포넌트 내에서도 작동한다. Huawei는 이 배치를 BarPosition.End 설정으로 식별한다.
이 영역 밖에서는 머티리얼을 설정해도 더 이상 표시 결과가 보장되지 않는다. Huawei의 예시는 자식을 수직으로 배치하는 기본 ArkUI 레이아웃인 Column 컨테이너를 사용한다.
이전에는 동일한 Column에서 동작 업데이트 전 머티리얼이 표시됐다. 새 규칙 아래에서는 승인된 내비게이션 영역 밖에 배치될 경우 효과가 사라진다.
보도된 컴포넌트 목록은 적용 범위를 유난히 구체적으로 보여 준다. 이는 단순히 개발자에게 시각적 절제를 권고하는 지침이 아니다.
이는 플랫폼 차원에서 강제되는 동작이다. 운영체제가 컴포넌트 유형, 위치, 애플리케이션 대상 조건에 따라 요청된 효과의 표시 여부를 결정한다.
대상 SDK 조건은 즉각적인 영향 범위를 제한한다. Huawei는 이 제한이 targetSdkVersion 26.0.0 이상일 때 적용된다고 설명한다.
영향을 받는 인터페이스가 26.0.0 베타와 함께 도입됐기 때문에 이 버전 경계는 중요하다. 이전 SDK를 대상으로 하는 애플리케이션은 공지에 설명된 새 동작으로 자동 전환되지 않는다.
그러나 대상 업데이트를 미루는 것은 일시적인 호환성 전략일 뿐이다. 개발자는 새 기능, 테스트 기대치, 배포 요건을 위해 결국 최신 플랫폼 대상을 사용해야 한다.
따라서 애플리케이션은 난처한 전환을 겪을 수 있다. 이전 대상에서는 인터페이스가 정상적으로 보이지만, 일반적인 SDK 마이그레이션 이후 효과를 잃을 수 있다.
코드 자체가 실패하지 않을 수도 있다. 머티리얼 객체는 남아 있어도 시스템이 해당 위치에서 렌더링을 거부할 수 있다.
이 때문에 시각적 회귀 테스트가 필수적이다. 팀은 빌드 성공이나 API 호출 완료 여부를 확인하는 자동 검사에만 의존할 수 없다.
Huawei의 컴포넌트 적응 가이드는 이제 지원되는 사용 사례를 내비게이션, 대화상자, 메뉴, 버튼, 선택 컴포넌트 중심으로 구성한다. 이 구조는 새 경계를 더욱 분명히 한다.
의도된 패턴은 명확해지고 있다. Immersive Light는 개발자가 꾸미고 싶은 모든 컨테이너가 아니라 콘텐츠 위에 놓이는 인터랙티브 표면에 적용돼야 한다.
이 패턴은 기능의 정체성을 상당 부분 유지한다. 제목 표시줄, 플로팅 탭 표시줄, 대화상자, 컨트롤은 사용자가 가장 자주 터치하는 위치이기도 하다.
하지만 창의적 자유도는 줄어든다. 개발자는 더 이상 이 머티리얼을 임의의 카드, 열, 장식 레이어를 위한 일반 배경 효과로 사용할 수 없다.
이 변경은 이 글의 핵심 긴장을 만든다. Huawei는 공간적 디자인 언어를 확장하면서도 외부 개발자가 이를 표현할 수 있는 위치는 줄이고 있다.
성능과 배터리 수명이 우선된 이유
Huawei는 서드파티 애플리케이션 전반의 제한 없는 시각적 일관성보다 예측 가능한 렌더링 비용을 선택하고 있다.
Immersive 머티리얼에는 투명 색상 이상의 요소가 필요하다. 블러, 굴절과 유사한 동작, 그림자, 배경 샘플링, 레이어형 투명도, 주변 콘텐츠에 대한 반응이 결합될 수 있다.
콘텐츠가 스크롤되거나 컨트롤이 이동하거나 배경이 바뀔 때 이러한 연산은 다시 계산돼야 한다. 겹치는 표면이 많아질수록 그래픽 작업과 메모리 압박도 커질 수 있다.
정확한 비용은 기기, 장면, 머티리얼 수준, 구현 방식에 따라 달라진다. Huawei는 이번 제한으로 배터리 수명이 얼마나 절약되는지 보여 주는 벤치마크 결과를 공개하지 않았다.
또한 결정을 촉발한 기준치도 공개하지 않았다. 독자는 이번 발표를 측정된 비율의 개선을 입증하는 자료로 해석해서는 안 된다.
회사가 제시한 근거는 더 제한적이다. Huawei는 이번 변경이 Immersive Light 컴포넌트 사용을 표준화하면서 최적의 성능 및 전력 경험을 보장한다고 설명한다.
이 표현은 두 가지 우려를 결합한다. 하나는 연산 비용이고, 다른 하나는 디자인 거버넌스다.
폭넓은 하드웨어 포트폴리오를 고려하면 성능 측면은 더 쉽게 이해할 수 있다. 플래그십 기기에서 무리 없이 작동하는 머티리얼도 구형 휴대폰이나 저전력 태블릿에서는 다르게 동작할 수 있다.
Huawei의 소비자 문서에는 이미 기기 의존적 동작이 반영돼 있다. 지원 기기 목록에는 구체적인 Mate, Pura, nova, Pocket, MatePad 모델이 나열돼 있다.
같은 지원 페이지는 기기마다 서로 다른 시각 처리가 적용된다고 밝힌다. 또한 기본 머티리얼 지원과 더 많은 리소스를 요구하는 파티클 애니메이션을 구분한다.
이러한 차이는 범용 개발자 스위치를 관리하기 어려워지는 이유를 보여 준다. 애플리케이션은 프로세서, 그래픽 성능, 열 상태, 디스플레이, 시스템 설정의 전체 조합을 제어하지 못한다.
개발자는 한 프리미엄 휴대폰에서 레이어형 인터페이스를 테스트하고 부드러운 애니메이션을 볼 수 있다. 다른 지원 모델의 사용자는 더 약한 효과, 추가 발열 또는 일관되지 않은 프레임 제공을 경험할 수 있다.
배터리 비용 역시 반복 사용을 통해 누적될 수 있다. 반투명 컴포넌트 하나는 부담이 적을 수 있지만, 여러 애니메이션 레이어가 스크롤이나 내비게이션 중 계속 활성화된 상태로 남을 수 있다.
위치별 기능 제한은 이 위험 프로필을 바꾼다. 제목 표시줄과 하단 탭 표시줄은 예측 가능한 기하 구조를 가진 제한된 영역을 차지한다.
대화상자와 메뉴는 일시적인 표면이다. 슬라이더와 토글은 명확한 상호작용 역할을 가진 비교적 작은 컴포넌트다.
임의의 페이지 컨테이너에는 이 같은 자연스러운 한계가 없다. 화면 전체를 덮거나, 애니메이션 콘텐츠를 포함하거나, 다른 머티리얼과 겹치거나, 긴 세션 내내 표시될 수 있다.
따라서 이 제한은 수치 예산을 공개하지 않는 렌더링 예산처럼 작동한다. 개발자는 성능 공식 대신 허용된 컨텍스트 목록을 받는다.
이 방식은 유연성을 희생하지만 예측 가능성을 높인다. Huawei는 알려진 인터페이스 영역을 기기와 시스템 버전 전반에서 최적화할 수 있다.
이러한 영역을 중앙에서 조정할 수도 있다. 머티리얼 알고리즘이 바뀌면, 회사는 가장 무거운 서드파티 사용이 발생할 위치를 알고 있다.
디자인 거버넌스 논점도 그만큼 중요하다. Huawei는 Immersive Light를 광학적 동작, 공간적 특성, 인터랙티브 반응을 결합한 머티리얼로 설명한다.
Huawei의 HarmonyOS 디자인 가이드는 이 머티리얼을 핵심 인터랙티브 영역에 배치한다. 이 효과를 평면 배경의 보편적인 대체재로 제시하지는 않는다.
제한 없는 도입은 이 위계를 약화시킬 수 있다. 모든 카드, 콘텐츠 패널, 컨테이너가 반투명해지면 사용자는 내비게이션과 정보의 구분을 잃는다.
전경 색상이 변화하는 이미지와 만날 때는 텍스트 가독성도 저하될 수 있다. 여러 반사 표면은 구조를 명확히 하기보다 서로 주의를 끌기 위해 경쟁할 수 있다.
머티리얼을 시스템과 유사한 컨트롤로 제한하면 그 의미가 더 일관돼진다. 떠 있고 반응하는 표면은 사용자가 무언가를 탐색, 선택 또는 닫을 수 있음을 알린다.
이 때문에 이번 결정은 단순한 기술적 후퇴가 아니다. 절제가 시각 언어를 더 쉽게 알아볼 수 있게 만들 것이라는 판단이다.
위험은 이미 광범위한 머티리얼 적용을 중심으로 구축된 애플리케이션 디자인이 마이그레이션 후 불완전하게 느껴질 수 있다는 점이다. Huawei는 개발자에게 적응 작업을 이전하는 방식으로 연산 불확실성을 줄였다.
Huawei HarmonyOS 7, 개발자에게 압박 가해
새 정책은 애플리케이션 팀이 단순히 지원 중단된 API 호출 하나를 교체하는 것이 아니라 영향을 받는 표면을 다시 설계하도록 요구한다.
개발자는 먼저 immersive 시스템 머티리얼을 사용하는 모든 컴포넌트를 식별해야 한다. 이 목록에는 공유 디자인 컴포넌트, 사용자 지정 컨테이너, 런타임에 생성되는 표면이 포함돼야 한다.
다음 단계는 맥락을 살피는 일이다. 팀은 각 컴포넌트가 허용된 제목 표시줄, 하단 탭 표시줄, 대화상자, 팝업, 메뉴 또는 적격 컨트롤 안에 있는지 판단해야 한다.
이 영역 밖의 컴포넌트에는 다른 처리가 필요하다. 팀은 단색 채우기, 일반적인 투명도, 색상 그라데이션, 테두리 또는 다른 인터페이스 경로에서 지원되는 더 단순한 블러를 사용할 수 있다.
적절한 대체 방식은 컴포넌트의 목적에 따라 달라진다. 장식용 카드를 머티리얼 효과를 유지하기 위해 내비게이션 표시줄로 옮겨서는 안 된다.
마찬가지로 개발자는 외관에 맞춰 정보 아키텍처를 재구성해서는 안 된다. 내비게이션 컨테이너는 의미론적으로 적절하고 접근 가능해야 한다.
Huawei는 해당 효과가 필요한 경우 구성 요소를 Navigation 또는 NavDestination 제목 표시줄에 배치하라고 명시적으로 권고한다. 하단 Tabs 표시줄도 또 다른 주요 경로를 제공한다.
이 권고는 내비게이션 요소에는 유효하다. 그러나 Immersive Light를 구성의 핵심 시각적 은유로 사용해 온 광범위한 페이지 구성 문제까지 해결해 주지는 않는다.
이러한 화면은 재설계가 필요하다. 그렇지 않으면 일부 표면은 깊이감을 유지하는 반면 인접한 표면은 갑자기 평면적으로 보이는 혼합형 인터페이스가 될 위험이 있다.
테스트 역시 한 대의 기기에만 국한해서는 안 된다. 공식 지원 자료에 따르면 시각적 강도와 파티클 동작은 제품 및 소프트웨어 릴리스에 따라 달라진다.
팀은 플래그십 제품과 이전 세대의 지원 하드웨어를 비교해야 한다. 또한 라이트 및 다크 테마, 애니메이션 배경, 스크롤, 큰 텍스트, 접근성 설정도 테스트해야 한다.
성공적인 검증은 여러 질문에 답할 수 있어야 한다. 머티리얼이 의도한 모든 위치에 표시되는가?
배경이 변해도 콘텐츠의 가독성이 유지되는가? 내비게이션 중에도 애니메이션의 반응성이 유지되는가?
효과가 없을 때 대체 디자인이 계층 구조를 보존하는가? 장시간 상호작용 중에도 배터리 사용량이 합리적인 수준인가?
이 질문들은 API가 오류를 반환하는지 확인하는 것보다 더 유용하다. 새로운 동작에서는 아무런 표시 없이 효과가 나타나지 않는 것 자체가 예상 가능한 결과다.
애플리케이션 디자이너 역시 엔지니어와 더 긴밀히 협업해야 한다. 정적 목업에서는 어디에나 반투명 카드를 배치할 수 있지만, 이제 런타임 플랫폼이 해당 카드에 공식 머티리얼이 적용될지 결정한다.
따라서 디자인 시스템은 허용되는 컨텍스트를 명시해야 한다. 재사용 가능한 구성 요소는 배치 위치가 플랫폼 규칙을 충족할 때만 Immersive Light를 노출할 수 있다.
린팅 또는 내부 검토를 통해 기기 테스트 전에 지원되지 않는 사용을 포착할 수 있다. 팀은 각 머티리얼 토큰 옆에 승인된 대체 디자인도 문서화할 수 있다.
대상 SDK 업데이트에는 서로 관련 없는 많은 변경 사항이 함께 포함되므로, 마이그레이션은 일정 압박을 유발한다. 시각적 재설계가 권한 작업, 호환성 테스트, 새로운 플랫폼 기능과 동시에 발생할 수 있다.
작은 팀이 가장 큰 부담을 안는다. 전담 그래픽 엔지니어나 완비된 기기 테스트 랩이 없을 수 있기 때문이다.
대규모 애플리케이션은 다른 문제에 직면한다. 광범위한 구성 요소 라이브러리는 동작이 변경됐다는 사실을 누구도 알아차리기 전에 기존 가정을 여러 화면으로 확산시킬 수 있다.
바로 이 지점에서 26.0.0 경계는 오해를 부를 수 있다. 시간을 벌어 주지만, 대상 마이그레이션이 거의 끝날 때까지 문제 발견을 미룰 수도 있다.
개발자는 별도 빌드에서 새로운 대상을 조기에 테스트해야 한다. 대표적인 워크플로의 스크린샷은 출시 준비가 시작되기 전에 누락된 머티리얼을 드러낼 수 있다.
Huawei는 더 풍부한 마이그레이션 도구를 제공해 불확실성을 줄일 수 있다. 무시된 머티리얼 요청에 대한 경고는 조용한 성능 저하보다 더 유용할 것이다.
DevEco Studio 역시 승인된 영역 밖에서 효과를 요청하는 구성 요소를 식별할 수 있다. 이 기사를 위해 검토한 공개 공지에서는 그러한 자동화된 보장이 마련됐다는 내용은 확인되지 않았다.
문서 날짜에도 주의를 기울일 필요가 있다. 핵심 동작 업데이트는 확인됐지만, 제3자 보도와 인기 목록 항목은 맥락을 생략하거나 범위를 축소할 수 있다.
이 제한은 HarmonyOS 7 전반에서 기능을 비활성화하지 않는다. 모든 구성 요소, 모든 애플리케이션 대상, 모든 화면에 영향을 주는 것도 아니다.
“Huawei가 Immersive Light를 제한한다”는 표현은 기능 제거를 의미하는 듯한 인상을 줄 수 있으므로 신중한 표현이 중요하다. 실제 변경 사항은 새 SDK를 대상으로 하는 애플리케이션에 적용되는 위치 및 구성 요소 정책이다.
제품 관리자에게 실질적인 질문은 시각적 기능이 살아남았는지가 아니다. 26.0.0을 채택하기 전에 애플리케이션에 얼마나 많은 재설계가 필요한지다.
Immersive Light와 Apple의 Liquid Glass 전략의 만남
핵심 경쟁은 시각적 취향을 둘러싼 Huawei와 Apple의 대결이 아니라, 통제된 배포와 폭넓은 머티리얼 제공의 대립이다.
Apple은 2025년 6월 iOS, iPadOS, macOS, watchOS, tvOS 전반에 공통으로 적용되는 디자인 머티리얼로 Liquid Glass를 도입했다. 이는 주변 콘텐츠를 반영하고 움직임에 반응한다.
Apple은 이 디자인을 컨트롤, 내비게이션, 아이콘, 위젯, 알림, 사이드바, 시스템 표면으로 확장했다. 업데이트된 API는 타사 개발자도 해당 머티리얼과 구성 요소를 채택할 수 있도록 한다.
Liquid Glass framework는 두 회사 모두 반투명 표면을 깊이, 빛, 반응형 상호작용과 연결한다는 점에서 유용한 참고 사례다.
두 시스템은 기술적으로 동일하지 않다. 렌더링 아키텍처, 구성 요소 모델, 지원 기기, 디자인 규칙이 서로 다르다.
그럼에도 이들은 같은 업계 흐름을 반영한다. 모바일 운영체제는 비교적 평면적인 인터페이스 디자인이 이어진 수년 후, 동적 머티리얼을 활용해 계층 구조를 만들고 있다.
Apple은 Liquid Glass를 하드웨어, 실리콘, 그래픽 기술의 발전과 공개적으로 연결했다. 이러한 설명은 실시간 렌더링을 시스템 전반의 역량으로 제시한다.
Huawei는 이제 이에 상응하는 시각적 개념이 어디에서 작동해야 하는지를 강조하고 있다. 회사는 운영체제를 머티리얼 배치의 능동적인 관리자로 만들고 있다.
Apple 역시 개발자에게 표준 컨트롤과 내비게이션 구조를 사용하도록 안내한다. 하지만 Huawei의 최근 변경이 주목받는 이유는 지원되지 않는 위치에서는 요청된 머티리얼이 더 이상 나타나지 않을 수 있기 때문이다.
이는 스타일에 관한 권고보다 더 강력한 집행 방식이다. 시각적 계층 구조를 플랫폼 동작으로 바꾼다.
통제된 모델에는 분명한 장점이 있다. 사용자는 더 일관된 배치를 경험하고, 운영체제는 다양한 기기 기반 전반에서 성능을 보호할 수 있다.
또한 시각적 과잉을 막을 수 있다. 반투명 머티리얼은 사용 가능한 모든 표면을 덮을 때 의미를 잃는다.
폭넓은 모델은 또 다른 장점을 제공한다. 개발자는 플랫폼 디자이너가 예상하지 못한 인터페이스를 고안할 여지를 얻는다.
타사 애플리케이션은 디자인 언어를 특화된 워크플로까지 확장할 수 있다. 창작 도구, 미디어 애플리케이션, 대시보드는 표준 내비게이션 구성 요소보다 더 풍부한 레이어링이 필요한 경우가 있다.
Huawei의 결정은 이러한 이점이 현재의 위험보다 크지 않다는 점을 시사한다. 적어도 영향을 받는 베타 단계 인터페이스에서는 회사가 공식 머티리얼을 제한된 상호작용 영역에 집중시키려 한다.
Google의 Material 디자인은 다른 경로를 택한다. 그 표현적 가이드는 하나의 광학적 머티리얼을 전체 정체성으로 삼기보다, 적응형 레이아웃, 모션, 형태, 색상, 구성 요소 계층을 활용한다.
표현적 디자인 수준은 팀이 기본 구성 요소에서 제품별 순간까지 표현의 강도를 조절하도록 장려한다. 이 모델은 시각적 강도를 디자인 시스템의 선택으로 다룬다.
이러한 전략은 서로 다른 형태의 압박을 만든다. Apple은 개발자에게 시스템 전반의 머티리얼을 중심으로 현대화할 것을 권장한다.
Google은 표현을 위한 더 넓은 어휘를 제공한다. Huawei는 개발자에게 더 엄격한 공간적 경계 안에서 현대화할 것을 요구한다.
사용자는 정책이 아니라 결과를 평가할 것이다. 절제된 HarmonyOS 애플리케이션은 동적 투명성으로 가득 찬 인터페이스보다 더 명확하게 느껴지고 더 일관되게 실행될 수 있다.
반대로 제대로 적응하지 못한 애플리케이션은 단편적으로 보일 수 있다. 내비게이션 요소는 깊이감을 유지하는 반면 콘텐츠 표면은 디자이너가 처음 의도한 시각적 관계를 잃을 수 있다.
이 비교는 해결되지 않은 문제도 드러낸다. Huawei는 위치 집행이 특정 성능 또는 배터리 이득을 낳는다는 공개 측정치를 제공하지 않았다.
그 수치가 없으면 그 절충안은 그럴듯하지만 정량화되지 않은 상태로 남는다. 회사의 설명은 독립적으로 입증된 결과가 아니라 플랫폼의 주장으로 다뤄야 한다.
이러한 불확실성이 제한을 자의적으로 만들지는 않는다. 실시간 블러, 그림자, 배경 샘플링, 애니메이션은 자원을 소모한다.
다만 외부 관찰자는 이 규칙이 정밀하게 조정됐는지 평가할 수 없다는 의미다. 더 작은 제한이나 기기별 예산으로도 더 큰 유연성을 유지하면서 유사한 이점을 제공했을 수 있다.
가장 강력한 증거는 홍보용 시연이 아니라 애플리케이션에서 나올 것이다. 프레임 안정성, 발열 동작, 시각적 일관성, 재설계 노력은 Huawei가 올바른 경계를 선택했는지 보여 줄 것이다.
성능 주장이 입증하지 못하는 것
합리적인 엔지니어링 동기가 모든 제한된 사용이 낭비적이거나 유해했다는 사실을 자동으로 입증하지는 않는다.
Huawei의 설명에는 공개된 벤치마크 방법론이 없다. 테스트한 기기, 애플리케이션 장면, 머티리얼 조합, 온도, 배터리 조건도 식별하지 않는다.
프레임 시간, 그래픽 사용률, 에너지 사용량에 대한 전후 수치도 없다. 개발자는 특정 화면을 재설계했을 때 예상되는 효과를 계산할 수 없다.
이러한 증거 공백은 강한 결론을 제한한다. 변경 사항은 관측된 성능 문제, 예방적 위험, 시각적 불일치 또는 이 세 가지 모두를 해결하려는 것일 수 있다.
공개된 문구는 성능, 전력 소비, 표준화된 구성 요소 사용을 함께 언급한다. 다만 이 동기들의 우선순위를 매기지는 않는다.
제한 이전에 애플리케이션 성능이 양호했던 개발자는 보편적인 규칙에 의문을 제기할 수 있다. 로컬 프로파일링은 신중하게 설계된 표면이 허용 가능한 예산 내에 머물렀음을 보여 줄 수 있다.
그러나 플랫폼 공급업체는 이상적인 구현만 관리하는 경우가 드물다. 머티리얼을 여러 겹으로 쌓거나, 넓은 영역에 애니메이션을 적용하거나, 성능이 낮은 하드웨어에서 테스트를 생략하는 애플리케이션까지 고려해야 한다.
위치 규칙은 동적 예산보다 집행하기 쉽다. 또한 독립적인 개발 팀 전반에서 더 일관된 결과를 만든다.
그 대가는 획일성이다. 가벼운 맞춤형 카드와 비용이 큰 전체 화면 구성은 모두 승인된 영역 밖에 놓이면 같은 처우를 받을 수 있다.
기기 차이는 또 다른 질문을 만든다. Huawei는 이미 모델에 따라 시각적 동작을 조정하고 있으며, 이는 시스템이 역량을 구분할 수 있음을 시사한다.
따라서 고사양 기기에 성능이 낮은 제품과 정확히 같은 구성 요소 경계가 필요한지 묻는 것은 타당하다. 현재 공지는 공개적인 성능 등급 매트릭스가 아니라 대상 기반 동작을 설명한다.
그 반론은 파편화일 것이다. 모든 기기가 서로 다른 애플리케이션 표면을 렌더링한다면, 디자이너는 사용자가 무엇을 보게 될지 예측할 수 없다.
단일 규칙은 일부 하드웨어가 기술적으로 더 많은 것을 처리할 수 있더라도 적응을 단순화한다. 일관성은 성능 정책의 일부가 된다.
접근성 역시 시각적 풍부함이 많을수록 항상 더 낫다는 생각을 복잡하게 만든다. 반투명성과 동적 배경은 특정 콘텐츠 조건에서 대비를 낮출 수 있다.
Huawei의 지원 가이드는 시스템 설정으로 효과 수준을 조정할 수 있다고 설명한다. 또한 접근성과 관련된 설정이 머티리얼 표시 방식을 바꿀 수 있다고 언급한다.
제한된 표면 영역은 개발자가 이러한 상호작용을 관리해야 하는 위치의 수를 줄인다. 그러나 제한만으로 읽기 쉬운 텍스트나 이해 가능한 계층 구조가 보장되지는 않는다.
팀은 여전히 대비, 포커스, 모션, 대체 상태를 테스트해야 한다. 단색이지만 잘못 선택된 배경은 신중하게 구현된 머티리얼보다 접근성이 낮을 수 있다.
커뮤니케이션 위험도 있다. 변경된 애플리케이션을 보는 사용자는 불완전한 재설계의 책임을 개발자에게 돌릴 수 있다.
개발자는 오류도 발생시키지 않고 인터페이스를 깨뜨렸다는 이유로 플랫폼을 탓할 수 있다. Huawei는 그런 혼란을 막기 위해 명확한 마이그레이션 메시지를 제공해야 한다.
9월 3일 업데이트는 초기 계약 수정으로 이해하는 편이 낫다. 영향을 받는 API는 26.0.0 베타와 함께 도입됐으며, 이는 개발자가 이를 영구적인 것으로 간주하기 전에 Huawei가 동작을 수정할 여지를 제공했다.
베타 상태는 실험이 예상된다는 점에서 중요하다. 그렇다고 인터페이스를 일찍 채택한 팀의 마이그레이션 작업이 사라지는 것은 아니다.
이 초기 채택자들은 새로운 시각 시스템을 테스트하는 데 기여했다. 이제 이들은 더 엄격해진 최종 계약으로 인해 발생한 비용을 더 많이 부담하게 됐다.
가장 방어 가능한 결론은 제한적이다. Huawei는 제한 없는 머티리얼 배치가 성능, 전력 효율 또는 일관성에 위험이 될 수 있다고 판단했고, 이를 집행 가능한 경계로 제한했다.
현재 확보된 증거만으로는 그 위험의 규모를 입증할 수 없다. 또한 이 제한이 실제 배터리 사용 시간을 얼마나 개선하는지도 보여주지 않는다.
그보다 강한 주장은 프로파일링 데이터, 독립적인 테스트 또는 확대된 기술 문서가 나올 때까지 기다려야 한다.
다음으로 주목할 세 가지 신호
다음 단계는 이 제한이 안정적인 설계 규칙이 될지, 일시적인 베타 수정에 그칠지, 혹은 더 광범위한 제어를 향한 첫걸음이 될지를 보여줄 것이다.
첫 번째 신호는 Huawei의 최종 SDK 26 문서다. 개발자는 동일한 컴포넌트 및 위치 규칙이 베타 인터페이스 이후에도 유지되는지 지켜봐야 한다.
안정적인 규칙은 Immersive Light가 주로 내비게이션과 일시적 컨트롤을 위해 설계됐음을 확인해 줄 것이다. 규칙이 완화된다면 Huawei가 더 선택적인 보호 장치를 찾았다는 의미일 수 있다.
문서는 폴백 동작도 명확히 해야 한다. 개발자는 무시된 머티리얼 요청이 로그, 경고 또는 검사 데이터를 생성하는지 알아야 한다.
진단 지원은 Huawei의 주장을 강화할 것이다. 잠재적으로 혼란스러운 시각적 회귀를 관찰 가능한 호환성 문제로 전환할 수 있기 때문이다.
두 번째 신호는 애플리케이션 도입이다. 주요 HarmonyOS 앱은 팀이 승인된 영역 내에서 시각적 일관성을 유지할 수 있는지 보여줄 것이다.
미디어 플레이어, 쇼핑 서비스, 금융 도구, 생산성 소프트웨어처럼 인터페이스가 밀집된 애플리케이션을 살펴봐야 한다. 이들의 화면은 흔히 내비게이션, 카드, 모달 레이어, 변화하는 이미지를 함께 사용한다.
이러한 애플리케이션이 명확한 위계와 부드러운 애니메이션을 유지한다면, 통제된 머티리얼 전략의 신뢰도는 높아진다. 반대로 디자인이 시각적으로 파편화된다면 이 규칙은 지나치게 제한적으로 보일 것이다.
기기 범위도 중요하다. 개발자 자유를 제한할 정당성을 확보하려면 Mate, Pura, nova, Pocket, MatePad 제품 전반에서 효과가 충분히 일관되게 유지돼야 한다.
세 번째 신호는 측정된 성능이다. 독립 테스트는 대상 SDK 마이그레이션 전후의 프레임 페이싱, 열 동작, 배터리 소비를 비교해야 한다.
가장 좋은 테스트는 동일한 애플리케이션, 기기, 밝기, 콘텐츠, 상호작용 순서를 사용한다. 관련 없는 소프트웨어 빌드를 비교하기보다 머티리얼 배치 자체를 분리해 검증해야 한다.
Huawei는 자체 방법론을 공개해 신뢰 형성을 앞당길 수 있다. 대표적인 범위만 제시해도 개발자가 어떤 장면에서 렌더링 비용이 가장 커지는지 이해하는 데 도움이 된다.
그런 데이터가 없다면 팀은 DevEco 프로파일링 도구와 실제 하드웨어를 활용해야 한다. 스크롤, 모달 전환, 탭 변경 중 시각적 출력과 지속 성능을 모두 기록해야 한다.
Apple과의 더 큰 경쟁 구도도 계속 눈에 띌 것이다. Apple의 developer APIs는 앱 제작자가 지원되는 플랫폼 전반에 Liquid Glass를 적용하도록 장려한다.
향후 Apple이 머티리얼 사용을 제한하거나 더 강력한 자동 제한을 추가한다면 Huawei의 신중함은 선견지명이 있었던 것으로 보일 것이다. Apple이 눈에 띄는 불이익 없이 폭넓은 배포를 유지한다면 개발자들은 Huawei의 더 엄격한 경계에 의문을 제기할 것이다.
현재로서는 이 사안이 실용적인 메시지를 전한다. 시각적 머티리얼은 일반적인 색상이 아니며, 플랫폼 소유자는 이를 점점 시스템 동작의 일부로 취급하고 있다.
HarmonyOS 7을 도입하는 개발자는 SDK 26으로 전환하기 전에 모든 Immersive Light 요청을 점검해야 한다. 지원되지 않는 위치를 테스트하고, 의도적인 폴백을 정의하며, 여러 기기 등급을 비교해야 한다.
사용자는 타사 애플리케이션이 더 차분하고 일관되게 변하는지, 아니면 단순히 표현력이 줄어드는지 지켜봐야 한다. 그 결과가 제한 문구 자체보다 더 중요하다.
Huawei는 자사의 시그니처 머티리얼이 표시되는 위치를 제한해 성능과 배터리 사용 시간을 보호하기로 했다. 다음 출시작들은 그 통제가 잃어버린 자유를 정당화할 만큼 경험을 개선하는지 보여줘야 한다.


