웹은 사실상 모든 기기를 통해 전 세계 사용자에게 도달할 수 있는 놀라운 플랫폼입니다. 손쉬운 사용과 공유가 가능합니다. 설치할 것이 없습니다. 하지만 무엇보다도 Google은 누구나 사용하거나 구축할 수 있는 개방형 생태계입니다.
현재 오픈 웹에서 빌드하고 제공할 수 없는 앱도 있습니다. 이를 앱 갭이라고 합니다. 웹상의 가능성과 기본형의 가능성 격차를 비교합니다 이 격차를 좁히고자 합니다. Google은 웹 앱은 네이티브 앱이 할 수 있는 모든 작업을 할 수 있어야 한다고 생각합니다.
에서 확인하세요.새로운 기능은 어떻게 설계하고 구현하나요?
![기능 프로세스 다이어그램](https://developer.chrome.com/static/blog/capabilities/image/capabilities-process-diag-c1802cf1209bb.jpg?authuser=19&hl=ko)
Google은 개방적이고 무엇보다도 기존 표준 프로세스 내에서 개발자의 요구를 빠르게 충족하는 새로운 웹 플랫폼 기능을 설계하고 개발할 수 있도록 이 프로세스를 개발했습니다. 이는 Google이 다른 모든 웹 플랫폼 기능을 개발하는 방식과 다르지 않지만 개발자의 의견을 중시합니다.
개발자 의견은 올바른 기능을 제공하는 데 중요하지만, 프로세스의 후반에 이르면 과정을 변경하기 어려울 수 있습니다. 그렇기 때문에 더 일찍 의견을 구하고자 합니다. 실행 가능한 기술 및 사용 사례 의견을 초기에 받으면 잘못된 판단을 내리거나 잘못 구현된 기능을 제공하지 않고도 올바른 방향으로 안내하거나 개발을 중단할 수 있습니다. WICG에서 개발 중인 특성은 확정된 것이 아니며, 개발자의 의견에 따라 기능이 발전하는 방식이 크게 달라질 수 있습니다.
많은 아이디어는 설명 또는 오리진 트라이얼 단계를 통과하지 못합니다. 프로세스의 목표는 적합한 기능을 출시하는 것입니다. 즉, 빠르게 배우고 반복해야 합니다. 개발자의 요구를 해결할 수 없어 기능을 제공하지 않는 것은 괜찮습니다. 이러한 학습을 지원하기 위해 Google에서는 다음과 같은 프로세스를 채택했습니다 (단, 피드백으로 인해 이후 단계의 순서가 변경되는 경우가 많음).
개발자 요구사항 파악
첫 번째 단계는 개발자의 요구사항을 파악하고 이해하는 것입니다. 개발자가 달성하고자 하는 것은 무엇인가요? 누가 사용하나요? 지금은 어떻게 하고 있나요? 새로운 기능으로 해결되는 문제나 불만도 파악할 수 있습니다. 일반적으로 이러한 버그는 bugs.chromium.org에 신고된 버그를 통해 개발자의 기능 요청으로 접수됩니다.
설명 만들기
새로운 기능의 필요성을 파악한 후에는 API 작동 방식을 보여주는 샘플 코드와 함께 문제를 설명하기 위한 디자인 문서인 설명서를 작성합니다. 이 설명은 새로운 기능이 발전함에 따라 계속 반복되며 살아 있는 디자인 문서입니다.
의견을 받고 설명 내용을 반복하세요.
설명의 명확성이 어느 정도 명확해졌다면 이제 이를 공개하고 의견을 구하고 디자인을 반복해야 합니다. 이는 새로운 기능이 개발자의 요구사항을 충족하고 개발자가 기대하는 방식으로 작동하는지 확인할 수 있는 기회입니다. 또한 대중의 지원을 받고 이 기능이 실제로 필요한지 확인할 수 있는 기회이기도 합니다.
디자인을 사양으로 이동하고 반복하기
설명의 상태가 정상이 되면 디자인 작업이 공식 사양으로 전환되고 개발자 및 다른 브라우저 공급업체와 협력하여 디자인을 반복하고 개선합니다.
그런 다음 설계가 안정화되기 시작하면 일반적으로 오리진 트라이얼을 사용하여 구현을 실험합니다. 오리진 트라이얼을 통해 실제 사용자를 대상으로 새로운 기능을 사용해 보고 구현에 관한 의견을 제공할 수 있습니다. 이러한 실제 피드백은 설계의 형성과 검증에 도움이 되므로, 표준이 되기 전에 올바른 결정을 내릴 수 있습니다.
배송하기
마지막으로 오리진 트라이얼이 완료되고 사양이 확정되고 다른 모든 출시 단계가 완료되었으면 이제 안정화 버전으로 출시할 차례입니다.
사용자 보안, 개인 정보 보호, 신뢰를 고려한 설계
이러한 기능 중 일부는 특히 네이티브에서 구현되는 방식을 고려할 때 처음에는 복잡해 보일 수 있습니다. 하지만 웹은 본질적으로 네이티브보다 안전하므로 웹페이지를 여는 것이 두렵지 않아야 합니다.
기본적으로 액세스 권한을 부여받으면 안 됩니다. 대신 사용자에게 완전한 제어 권한을 부여하고 쉽게 취소할 수 있는 권한 모델을 사용합니다. 이러한 API가 언제 어떻게 사용되는지 명확히 나타내야 합니다. 강력한 웹 플랫폼 기능에 대한 액세스 제어에 Google의 사고 과정 중 일부를 간략히 정리했습니다.