ABOUT ME

-

오늘
-
어제
-
-
  • 구글 웹 테크(I/O Extended 2019 WebTech) 2019 후기
    Conference 2020. 6. 30. 19:59

    구글 웹 테크를 가게된 이유

    2019 I/O Extended 2019 WebTech가 2019. 7. 13(토)에 삼성역 구글 스타트업 캠퍼스에서 진행되었습니다!
    웹 개발자로서 언어나 프레임워크, 라이브러리를 다루는 것도 중요하지만 새로운 정보들은 습득하고 흐름을 따라가는 것 또한 매우 중요하다고 생각합니다. (물론 흐름 따라갈만한 실력은 없지만…😭)

    2주 전에 표를 예매하고 당일 제가 행사 시작 시간을 잘못 알고 2시간 먼저 도착하는 바람에 시간이 붕뜨는 사건이 있기도 했습니다.😅

    최종적으론 제 회사 동료분과 구글 행사의 도우미인 지인까지 총 3명과 함께 참석하게 되었습니다.

    images

    도착 후 시작 전 현장사진..

    Google I/O Extended 2019 WebTech란?

    I/O Extended는 전세계 각 지역에서 올해 Google I/O에서의 경험과 새로 공개된 정보들을 공유하는 행사입니다. 미국 샌프란시스코에서 올해 5월에 성황리에 행사를 마쳤고 구글에서는 이러한 관련된 행사를 매년 진행하고 있습니다.

    매년 주제가 다르고 최근 구글에서 주목하고 있는 기술, 앞으로의 기술 등을 소개하며 어떠한 방향으로 나아갈지 알 수 있습니다.
    저도 나중에 보다 멋진 개발자가 되면 GDG Korea의 일원이 되어 구글 본사에서 직접 행사 참석을 해보고 싶은 목표가 생겼습니다.🔥

    연사 주제

    Puppetter: Getting Started

    구글에서 Chrome API를 컨트롤 할 수 있는 라이브러리 입니다.
    Chrome에서 할 수 있는 일들을 자동화 할 때 사용하면 매우 유용합니다. 대표적으로 아래에 해당되는 부분에 활용 가능합니다.

    • e2e Testing
    • SPA Prerendering
    • Web Site Crawling
    • Generating PDF

     

    예시 코드를 보면서 사용 방법에 대해 간단히 소개하였고 e2e 같은 경우 라이브 코딩을 하면서 실습해 보았는데
    실습 도중 로그인 버튼이 활성화가 안되는 사고가 발생하여 당황한 연사자분과 덕분에 행사장 분위기가 풀리기도 하였습니다.

    특히 크롤링을 하는 부분에 있어서 진가를 느낄 수 있었습니다.
    짧은 개발 지식으로는 크롤링이라 함은 파이썬의 전유물인줄만 알았던 우물안 개구리였는데,
    Puppetter를 통해 자동으로 입력되는 값을 보며 테스트에서도 활용도가 높을 것이라 생각했습니다.
    나중에 기회가 된다면 꼭 사용해보고싶은 라이브러리입니다. :)

    공식 홈페이지 : https://developers.google.com/web/tools/puppeteer/
    연사 자료(HyunSeob) : https://github.com/HyunSeob/puppeteer-getting-started

    Hands on Portals

    위 주제는 웹개발에 있어서 분리하는 방법에 대한 방법과 그에 맞는 프론트 기술에 대한 연사였습니다.
    웹을 개발할 때 많은 이슈들이 있지만 가장 큰 문제는 역시 각 개발의 결과물을 합칠 때 벌어지게 됩니다.

    가령 프론트에서 어떤 페이지는 vue로 개발을 하고 또 다른 페이지는 React로 개발을 하거나, 또 어떤 페이지는 Angular로 개발을 했을 때 이러한 지옥과 같은 상황에서 어떻게 극복할 것인지에 대한 방법은 정말 어렵습니다.
    Front와 Back의 개발의 경계가 가면 갈수록 분리되고 있는 시점에서 이 이슈는 끊임없이 지속될 것이고 해결을 해야만 할 것입니다.(미래의 저도 마찬가지..🚑)

    그래서 우리의 해결방법은 Micro Frontends를 통해 하나의 기능에는 하나의 팀을 구성해 구현하고 이를 도메인을 완전히 분리하는 방법을 소개해 주셨습니다.

    사실 저는 아직 프로젝트 실무에 투입하지 않아서 위와 같은 개념이 잘 이해는 가지 않았지만, 위 큰 이슈를 통해 이러한 방법으로 해결해 나가고 생각을 확장할 수 있는 기회가 되었습니다.

    그리고 본격적으로 Portal에 대해 설명해 주셨는데 Portal을 활용하면 현재 페이지에서 또 다른 페이지로 넘어갈 때(페이지 전환) 이질적으로 넘어가는 방식이 아닌 자연스럽게 넘어가는 방식을 구현할 수 있습니다. 만약 Portal가 지원되지 않는다면 Iframe을 사용하여 구현할 수도 있다고 합니다.
    글로써 설명하는 것 보다는 직접 영상으로 보면 훨씬 이해가 빠를 거라 생각되어 공식 홈페이지를 참고해 주시면 됩니다.

    사실 페이지를 이동하는데에 급급한 저로써는 아직 머나먼 얘기일지 모르겠지만, 언젠가 제가 직접 페이지 이동을 구현해야할 때가 온다면 활용해보고싶다는 생각이 들었습니다.

    공식 홈페이지 : https://web.dev/hands-on-portals

    New Capabilities for the Web

    이번 주제는 네이티브 앱에 대한 주제를 다루었습니다.
    사실 저는 웹개발자로서 네이티브에 대한 단어의 정의를 모르고 있었습니다.
    현재 재직중인 회사에서 React Native를 사용하여 앱을 구축했다는 것은 알고 있으나 React Native가 정확히 어떤 역할을 하는지, 그리고 React와는 무슨 차이가 있는지에 대해서는 알지 못하고 있었는데 이번 연사를 계기로 네이티브 앱에 대한 정의를 공부하게 되었습니다.

    혹시 네이티브 앱에 대해 궁금하신 분이 계시다면 ITWorld 용어풀이 | 네이티브 앱에서 궁금증을 해결하시면 좋을 것 같습니다. :)

    본론으로 가보면 네이티브 앱은 차이점이 있다는 것을 눈치 채셨을 것입니다.
    이러한 차이점을 App Gap이라고 부릅니다.
    풀어서 설명드리면 "웹과 네이티브 앱간 서로 할 수 있는 것을 상대방은 못한다" 입니다.

    그래서 이런 차이를 극복하기 위해 노력하는 분들이 계십니다.(그들은 대체…)
    그 프로젝트는 바로 Project Fugu라는 프로젝트입니다.
    이 프로젝트를 진행하고 있는 개발자들은 "네이티브 앱이 할 수 있는 것을 웹에서도 가능하게 할 수 있도록" 하는 것을 목표로 Fugu(복어)라는 표현을 사용해 비유하고 있습니다.

    그리고 자주 사용되거나 앞으로 추가될 API들을 살펴보자면

    • Web Share Target API
    • Media Session API
    • Shape Detection API
    • Face Detector
    • Barcode Detector
    • Text Detector
    • Keep Wake Lock
    • System Wake Lock
    • Screen Wake Lock
    • Badge API

     

    위와 같은 API들이 있으며 모두가 흥미로운 기능들이었습니다.
    추후에 적용할만한 API들을 점찍어 두고 필요할 때 사용하고 싶습니다. :)

    WebAssembly 101

    이번엔 WebAssembly에 대한 주제였습니다.
    WebAssembly의 생성 배경은 성능에 대한 집착기술 성숙도 입니다.
    WebAssembly를 통해 개발을 하게 되면 Native에 준한 속도로 매우 빠르며, C계열 언어의 전유물이었던 Gaming 개발을 할 수 있으며,
    추가적으로 기존에 사용하던 C/C++의 코드 베이스를 재사용이 가능합니다.
    이런 코드들을 Javascript로 컴파일 하게 도와주며 최적화된 컴파일을 제공하게 됩니다.

    하지만 이런 장점에도 불구하고 단점이 존재하기 마련입니다..
    고급 언어의 전유물이었던 요소들을 사용하기 못하며, 언어 그대로의 문법의 내부 부분들이 조금씩 바뀌고, 사용한다고 해서 꼭 효율적이거나 빠르지 않다는 것입니다.
    그래서 때에 맞춰 활용해야 효율적으로 사용할 수 있습니다.

    아직은 안정성이 확보되어 있지 않은 상태고 모든 언어에 적용되는 부분이 아니기 때문에 추후 조금 더 보완되고 안정성이 보장 된다면 충분히 활용할만한 기술이라고 생각됩니다. :)

    Going BIG - PWA(Progressive Web Application)

    구글에서 팍팍! 밀어주고 있는 PWA를 주제로 진행하였습니다.
    PWA는 웹과 네이티브 앱의 좋은 점을 가져온 것입니다.
    네이티브 앱과 웹을 비교했을 때 네이티브의 장점이라고 한다면 크게 3가지를 들 수 있습니다.

    • UI 편의성
    • 시스템의 편리성
    • 아이콘의 활용성

     

    위 세가지의 차이 때문에 앱을 개발할 때 네이티브를 사용하게 되는데, PWA를 활용하면 이런 장점을 가지고 있어 구축된 Web을 PWA로 만들어 배포하면 단점이 보완되는 효과를 누릴 수 있습니다.

    또한 PWA를 활용함에 있어 중요한 개념 Web app Manifest, Service Worker에 대한 설명이 이어졌고 저는 보란듯이 이해를 하지 못했습니다. 😭

    하지만 PWA의 중요성과 공부의 필요성을 느꼈고 웹개발자로서 배포할 때 충분히 고려해봐야겠다고 느꼈습니다.

    공식 홈페이지 : https://developers.google.com/web/fundamentals/codelabs/your-first-pwapp/

    Deep in Lighthouse Audits

    마지막 주제로는 구글팀에서 만든 개발자 도구입니다.
    이는 개발자를 위한 도구로서 Chrome 확장프로그램을 통해 사용이 가능합니다.
    Lighthouse를 사용하면 내가 현재 사용하고 있는 브라우저, 혹은 지금 구현 중인 프로젝트의 브라우저를 판단하여 성능을 측정하게 됩니다.

    여기서 여러가지를 측정하지만 대표적으로 Accessibility, Performance을 중점으로 보는 것이 개발자들에게 있어서 가장 중요할 것이라고 합니다.
    이유는 시간이 많은 개발자면 상관이 없지만 대부분 혹은 전부(…?)가 시간이 없기 때문에 브라우저에 대한 성능을 전부 끌어 올리기는 사실상 힘들다고 보기 때문입니다.

    그리고 측정시 주의사항은 컴퓨터의 사양을 최대한 낮게 설정하여 측정해야만 성능에 대한 이슈를 캐치할 수 있습니다.
    왜냐하면 개발자들은 상대적으로 사양이 좋은 컴퓨터를 사용하고 있으나 그에 반해 비개발자는 대부분 성능이 떨어지기 때문입니다.

    앞으로 프로젝트를 진행하면서 꼭 사용해봐야할 도구라고 생각합니다.

    마무리

    넓게는 Google WebTech를 통해 구글에서 Web을 어떻게 대하고 있으며 앞으로의 방향성을 볼 수 있었고
    좁게는 JavaScript의 필요성과 유연함 대해 절실히 느끼게 되었습니다.
    앞으로 이런 기술들을 습득하고 직접 활용하기 위해서 열심히 노력하고 영역을 넓혀야 겠다는 생각을 하게 되었습니다.🔥💻🔥

    댓글