반응형

https://netflixtechblog.com/native-frame-rate-playback-6c87836a948

 

Native Frame Rate Playback

This article talks about a novel HDMI technology and how it is used within the Netflix Application to improve a user’s experience.

netflixtechblog.com

소개

회원의 몰입도를 극대화하는 것은 Netflix 제품 및 엔지니어링 팀이 회원을 즐겁게 하고 콘텐츠에 완전히 몰입할 수 있도록 하는 중요한 목표입니다. 결함 없는 인앱 전환으로 원활한 재생 경험을 제공하기 위해 성숙한 최신 클라이언트 장치 기술을 적절하게 조합하여 활용하는 것은 이 목표를 달성하기 위한 중요한 단계입니다. 이 기사에서는 소비자 스트리밍 장치의 기능을 활용하여 회원에게 더 나은 시청 경험을 제공하기 위한 여정에 대해 설명합니다.

Roku 셋톱 박스(STB) 또는 Amazon FireTV 스틱과 같은 스트리밍 장치가 TV에 연결되어 있는 경우 장치 디스플레이 설정에서 콘텐츠 프레임 속도와 관련된 옵션을 보았을 수 있습니다. 장치 제조업체는 종종 이 기능을 "콘텐츠 프레임 속도 일치", "디스플레이 재생률 자동 조정" 또는 이와 유사한 이름으로 부릅니다. 이러한 기능이 무엇이며 어떻게 시청 환경을 개선할 수 있는지 궁금한 적이 있다면 계속 읽어보세요. 다음 섹션에서는 이 기능의 기본 사항을 다루고 Netflix 애플리케이션에서 이 기능을 사용하는 방법에 대해 자세히 설명합니다.

문제

Netflix의 콘텐츠 카탈로그는 초당 23.97에서 60 프레임(fps) 범위의 다양한 프레임 속도 중 하나로 캡처 및 인코딩된 비디오로 구성됩니다. 회원이 소스 장치 (예: 셋톱 박스, 스트리밍 스틱, 게임 콘솔 등)에서 영화 또는 TV 프로그램을 보기로 선택하면 콘텐츠가 전달된 다음 프레임인 기본 프레임 속도 로 디코딩됩니다. 디코딩 단계 후 소스 장치는 연결된 싱크 장치(TV, AVR, 모니터 등)의 HDMI 입력 포트 기능을 기반으로 구성된 HDMI 출력 프레임 속도로 변환 합니다 . 일반적으로 HDMI를 통한 출력 프레임 속도는 PAL 지역의 경우 50fps, NTSC 의 경우 60fps로 자동 설정됩니다.지역.

Netflix는 높은 프레임 속도의 콘텐츠(50fps 또는 60fps)를 제한적으로 제공하지만 당사 카탈로그 및 시청 시간의 대부분은 23.97~30fps 콘텐츠를 시청하는 회원이 차지할 수 있습니다. 이는 본질적으로 대부분의 경우 콘텐츠가 프레임을 복제하여 HDMI 출력 프레임 속도와 일치하도록 기본 프레임 속도에서 콘텐츠를 변환하는 소스 장치에서 프레임 속도 변환 (일명 FRC)이라는 프로세스를 거친다는 것을 의미합니다. 그림 1은 24fps 콘텐츠를 60fps로 변환하는 간단한 FRC 알고리즘을 보여줍니다.

그림 1 : 24FPS 콘텐츠를 60FPS로 변환하는 3:2 풀다운 기법

콘텐츠를 변환하고 HDMI를 통해 출력 프레임 속도로 전송하는 것은 논리적이고 간단하게 들립니다. 실제로 FRC는 출력 프레임 속도가 기본 프레임 속도의 정수배(예: 24→48, 25→50, 30→60, 24→120 등)일 때 잘 작동합니다. 반면에 FRC는 정수가 아닌 다중 변환이 필요한 경우(예: 24→60, 25→60 등) Judder 라는 시각적 아티팩트를 도입하며, 이는 아래 그림과 같이 고르지 못한 비디오 재생으로 나타납니다.

반응형
반응형

35 Knowledge base tools for developers in 2023

https://medium.com/promyze/35-knowledge-base-tools-for-developers-in-2023-2584d1ea6bbb

 

35 Knowledge base tools for developers in 2023

In 2023, there should be no debate about the added value of great documentation in software projects. Software engineers should have access…

medium.com

 

  • 엔지니어가 도구의 UI에서 문서를 작성하는 Wiki와 유사한 도구 (예: Notion, Confluence, …)
  • 예 를 들어 코드 분석 및 온보딩 세션(예:프로미즈);
  • 질문/답변 플랫폼과 같은 커뮤니케이션 도구(예: Teams용 StackOverflow, …)
  • 개발자가 일반적으로 마크다운으로 문서를 작성하면 모든 마법이 일어나는 생성된 위키 도구(예: ReadTheDocs, …)

Acreom

Capture notes, break down issues, track your progress, create a knowledge base.

AnswerHub

Empowering developers and teams to learn, share, and succeed through online communities and knowledge sharing.

AppFlowy

Open Source Notion Alternative

Archbee

Build better product documentation — faster

Bit.ai

Next-Gen Document Collaboration Platform for Teams!

BookStack

(Open Source) BookStack is a simple, self-hosted, easy-to-use platform for organizing and storing information.

ClickUp

Save time with the all-in-one productivity platform that brings teams, tasks, and tools together in one place.

Coda

The all-in-one doc for teams.

CodeStream

New Relic CodeStream is a free open-source extension for VS Code, Visual Studio, and JetBrains.

Confluence

Confluence is your remote-friendly team workspace where knowledge and collaboration meet.

Daux.io

(OpenSource) The Easiest Way To Document Your Project.

Developerhub.io

All-in-One Platform for Online Documentation.

Docusaurus

(OpenSource) Build optimized websites quickly, focus on your content.

Flarum

(Open Source) Forums made simple. Modern, fast, and free!

Forem

(Open Source) Forem is an open source platform for building modern, independent, and safe communities.

GitBook

Where software teams break knowledge silos. (We use it at Promyze for our public documentation)

GitHub Pages

Websites for you and your projects.

Hugo

(OpenSource) The world’s fastest framework for building websites.

Jekyll

Transform your plain text into static websites and blogs.

mdBook

Static site generator from Markdown files.

MkDocs

(Open Source) Project documentation with Markdown.

Notion

The all-in-one workspace — for your tasks, notes, wikis, and calendar.

Notaku

Build a full-featured Docs website in minutes, using Notion as CM

Nuclino

A modern, simple, and blazingly fast way to collaborate — bring knowledge, docs, and projects together in one place.

Papyrs

The easiest way to create an online for your company.

Read The Docs

(Open Source) Read the Docs simplifies software documentation by automating building, versioning, and hosting of your docs for you.

SkyDocs

(OpenSource) SkyDocs is a lightweight static documentation builder with MarkDown.

Slab

Build a culture of knowledge-sharing today.

Sphinx

(OpenSource) Sphinx makes it easy to create intelligent and beautiful documentation.

Stack Overflow For Teams

Knowledge sharing and collaboration without distractions.

Swimm

Documentation Platform Built for Engineers.

TechDocs

Spotify’s docs-like-code plugin for Backstage.

Tettra

The best way to organize and share knowledge with your teammates.

Wiki.js

(OpenSource) The most powerful and extensible open source Wiki software

Promyze

Connect Developers’ Knowledge and share best coding practices, fully integrated in developers tools.

That’s all, folks; we hope that post gave you an overview of the current landscape of the knowledge base tools for software developers.

Among the ones quoted above, at Promyze, we use Notion to gather material such as procedures to create new releases of our IDE extensions. We use GitBook to publish the user documentation of our platform. Finally, we use our tool Promyze internally to raise new coding standards continuously. We bring these standards directly in IDEs & during code reviews since we consider this is the moment developers need this knowledge. You don’t code with a Wiki opened in a tab.

For each kind of documentation, you must define who should update it, when, and how other engineers will be notified of this change.

 

반응형
반응형

https://js.wiki/

 

Wiki.js

Install anywhere Works on virtually any platform and is compatible with either PostgreSQL, MySQL, MariaDB, MS SQL Server or SQLite!

js.wiki

가장 강력 하고
확장 가능한 오픈 소스 Wiki 소프트웨어


Wiki.js의 아름답고 직관적인 인터페이스를 사용하여 문서 작성을 즐겁게 만드십시오 !

네이버에 검색해봤더니 ㅋㅋㅋ 

ㅋㅋㅋ

 

반응형
반응형

세계에서 가장 강력한
업무 공간 및 문서 협업 플랫폼

팀과 개인이 전 세계 어디에서나 한 곳에서 모든 지식을 생성, 공동 작업 및 구성할 수 있도록 제작되었습니다. 작업하는 앱 전체에서 통합하면서 빠른 동적 메모, 문서, Wiki, 기술 자료, 프로젝트, 클라이언트 결과물, 기술 문서, 교육 가이드 및 클라이언트 포털을 생성합니다.

 

https://bit.ai/

 

Bit.ai - Document Collaboration for The New Era

Bit is a powerful document collaboration platform to create documents, notes, wikis with advanced design options, robust search, document tracking and much more..

bit.ai

 

https://youtu.be/3KtcKdMw3vs

반응형
반응형

gist 만들기 - gist.github.com

https://docs.github.com/ko/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists

 

gist 만들기 - GitHub Docs

공개 및 비밀의 두 가지 종류의 gist를 만들 수 있습니다. 세상과 아이디어를 공유할 준비가 되었다면 공개 gist를 만들고, 그렇지 않은 경우 비밀 gist를 만듭니다.

docs.github.com

 


gist 만들기
이 문서의 내용
gist 정보
gist 만들기
공개 및 비밀의 두 가지 종류의 gist를 만들 수 있습니다. 세상과 아이디어를 공유할 준비가 되었다면 공개 gist를 만들고, 그렇지 않은 경우 비밀 gist를 만듭니다.

gist 정보
Gists는 코드 조각을 다른 사용자와 공유하는 간단한 방법을 제공합니다. 모든 gist는 Git 리포지토리입니다. 즉, 포크 및 복제할 수 있습니다. GitHub에 로그인해서 gist를 만드는 경우 해당 gist는 계정과 연결되며 gist 홈페이지로 이동할 때 gist 목록에 표시됩니다.

Gist는 공개 또는 비밀일 수 있습니다. 공개 gist는 검색에 표시됩니다. 여기서 사람들은 gist가 만들어질 때 새 gist를 찾아볼 수 있습니다. 이들은 또한 검색이 가능하므로, 자신이 작업한 것을 다른 사람들이 찾아서 보도록 하려는 경우 사용할 수 있습니다.

비밀 gists는 검색에 표시되지 않으며 로그인하고 비밀 요점의 작성자가 아닌 한 검색할 수 없습니다. 비밀 gist는 비공개가 아닙니다. 비밀 gist의 URL을 친구에게 보낼 경우 받은 사람은 이를 볼 수 있습니다. 그러나 자신이 모르는 사람이 해당 URL을 발견할 경우 그들도 gist를 볼 수 있습니다. 다른 사람의 눈에 띄지 않도록 코드를 보호해야 하는 경우 대신 프라이빗 리포지토리를 만들 수 있습니다.

gist를 만든 후에는 이를 퍼블릭에서 비밀로 변환할 수 없습니다.

다음과 같은 경우 알림이 제공됩니다.

내가 gist의 작성자인 경우.
누군가가 gist에서 나를 멘션하는 경우.
Gist 맨 위에 있는 구독을 클릭하여 gist를 구독하는 경우.
다른 사용자가 쉽게 볼 수 있도록 프로필에 gist를 고정할 수 있습니다. 자세한 내용은 "프로필에 항목 고정"을 참조하세요.

gist 홈페이지로 이동하고 모든 Gist를 클릭하면 다른 사람들이 만든 공개 gist를 검색할 수 있습니다. 그러면 만든 시간 또는 업데이트 시간별로 정렬되고 표시되는 모든 gist의 페이지로 이동하게 됩니다. Gist Search을 사용하여 언어별로 gist를 검색할 수도 있습니다.

Gist는 Git 리포지토리이므로 차이(diff)와 함께 전체 커밋 기록을 볼 수 있습니다. Gist를 포크 또는 복제할 수도 있습니다. 자세한 내용은 "Gist 포크 및 복제"을 참조하세요.

Gist 상단에 있는 ZIP 다운로드 단추를 클릭하여 gist의 ZIP 파일을 다운로드할 수 있습니다. 블로그 게시물과 같이 Javascript를 지원하는 텍스트 필드에 gist를 포함할 수 있습니다. 포함 코드를 얻으려면 gist의 Embed URL 옆에 있는 클립보드 아이콘을 클릭합니다. 특정 gist 파일을 포함하려면 ?file=FILENAME과 함께 Embed URL을 추가합니다.

Gist는 GeoJSON 파일 매핑을 지원합니다. 이러한 맵은 포함된 gist에 표시되므로 맵을 쉽게 공유하고 포함할 수 있습니다. 자세한 내용은 "비 코드 파일 사용"을 참조하세요.

gist 만들기
아래 단계에 따라 gist를 만듭니다.

GitHub CLI를 사용하여 gist를 만들 수도 있습니다. 자세한 내용은 GitHub CLI 설명서의 “gh gist create”를 참조하세요.

또는 바탕 화면에서 편집기로 직접 텍스트 파일을 끌어서 놓을 수 있습니다.

GitHub에 로그인합니다.

gist 홈페이지로 이동합니다.

필요에 따라 "Gist description" 필드에 gist에 대한 설명을 입력합니다.

"확장명 포함 파일 이름" 필드에 파일 확장명을 포함하여 gist의 파일 이름을 입력합니다.

파일 내용 필드에 gist의 텍스트를 입력합니다.

필요에 따라, 공개 gist를 만들려면 을 클릭한 다음, 공개 gist 만들기를 클릭합니다.

! [새 요점에 대한 표시 유형 드롭다운 메뉴의 스크린샷 "비밀 요지 만들기"라는 레이블이 지정된 단추 옆에 드롭다운 아이콘이 진한 주황색으로 표시됩니다.] (/assets/images/help/gist/gist-visibility-drop-down.png)

비밀 gist 만들기 또는 공개 gist 만들기를 클릭합니다.

반응형
반응형

GitHub 2023의 상위 10개 최고의 오픈 소스 프로젝트

https://open-data-analytics.medium.com/top-10-best-open-source-projects-on-github-2023-784bf4df2a94

 

Top 10 Best Open Source Projects on GitHub 2023

Open Source Software (OSS) has revolutionized the way software development is done today. With millions of Open Source GitHub projects…

open-data-analytics.medium.com

오픈소스 소프트웨어(OSS)는혁명을 일으켰다오늘날 소프트웨어 개발이 수행되는 방식. 수백만 개의 오픈 소스 GitHub 프로젝트를 사용할 수 있으므로 필요에 맞는 최고의 오픈 소스 프로젝트를 탐색하고 찾는 것이 어려울 수 있습니다.

이 기사에는 알아야 할 가장 빠르게 성장하는 오픈 소스 GitHub 리포지토리 상위 10개가 나열되어 있습니다.

1. RLHF + PaLM: 오픈 소스 ChatGPT 대안

PaLM-rlhf-pytorch: 오픈 소스 ChatGPT 대안

RLHF + PaLM repo는 Reinforcement Learning with Human Feedback(RLHF) 및 PaLM 아키텍처를 결합한 진행 중인 구현입니다. ChatGPT와 유사하지만 PaLM 아키텍처의 이점이 추가된 모델의 오픈 소스 버전을 만드는 것을 목표로 합니다. 안타깝게도 이 솔루션에 대해 사전 학습된 모델이 제공되지 않습니다.

PaLM-rlhf GitHub 스타 기록

깃허브 링크:

2. RATH - 오픈 소스 Tableau 대안

Kanaries(k6s) RATH: Tableau의 오픈 소스 대안

탐색적 데이터 분석에 RATH 사용

신인으로서 RATH는 GitHub에서 가장 빠르게 성장하는 커뮤니티 중 하나입니다. 최첨단 기술과 데이터 분석 및 시각화에 대한 혁신적인 접근 방식을 통해 RATH는 데이터 전문가와 매니아 사이에서 빠르게 인기를 얻었습니다.

RATH GitHub 스타 히스토리

RATH의 커뮤니티는 개발자, 데이터 과학자 및 비즈니스 분석가 모두 개발에 기여하고 잠재력을 극대화하는 방법에 대한 아이디어를 공유하면서 빠르게 성장하고 있습니다. 노련한 데이터 분석가이든 막 시작하든 관계없이 RATH는 데이터 분석 및 시각화 기술을 향상시키려는 모든 사람에게 필수 도구입니다.

카나리아(k6s) RATH GitHub:

RATH에 대한 추가 정보: https://kanaries.net/

3. Gogs — 오픈 소스 GitHub 대안

Gogs: 오픈 소스 GitHub 대안

Gogs는 Git 버전 제어를 위한 사용자 친화적인 인터페이스를 제공하므로 GitHub의 훌륭한 대안이 됩니다. 이슈 추적, 풀 리퀘스트, 위키를 포함한 다양한 기능을 제공합니다. 자체 호스팅 및 사용자 정의가 가능한 Gogs는 Git 협업을 위한 유연하고 안전한 솔루션을 제공합니다.

Gogs GitHub 스타 히스토리

Gogs GitHub:

4. NocoDB — 오픈 소스 AirTable 대안

NocoDB: 오픈 소스 AirTable

NocoDB는 SQL, NoSQL 및 Graph 데이터베이스를 지원하는 유연하고 확장 가능한 데이터 플랫폼을 제공합니다. 데이터베이스 생성 및 관리를 위한 간단하면서도 강력한 인터페이스를 제공하며 실시간 데이터 업데이트를 지원합니다. NocoDB는 데이터에 대한 더 많은 제어 및 사용자 지정이 필요한 사람들을 위한 Airtable의 훌륭한 대안입니다.

Nocodb GitHub:

5. Rocket.Chat — 오픈 소스 슬랙 대안

Rocket.Chat: 오픈 소스 슬랙 대안

Rocket.Chat은 음성 및 화상 통화, 화면 공유, 파일 공유 등 다양한 기능을 통해 실시간 팀 커뮤니케이션을 제공합니다. 고도로 사용자 정의가 가능하며 자체 호스팅하거나 클라우드 기반 솔루션으로 사용할 수 있습니다. 강력한 협업 도구를 갖춘 Rocket.Chat은 Slack의 훌륭한 대안입니다.

Rocket.Chat GitHub 스타 기록

Rocket.Chat GitHub:

6. Airbyte — 오픈 소스 Fivetran 대안

Airbyte: 오픈 소스 데이터 통합

Airbyte는 데이터 통합을 위한 간단하면서도 강력한 인터페이스를 제공합니다. 데이터베이스, SaaS 애플리케이션 및 API를 포함한 광범위한 데이터 소스를 지원합니다. 실시간 데이터 전송 기능과 유연한 데이터 변환 옵션을 통해 Airbyte는 필요한 곳에 데이터를 쉽게 가져올 수 있습니다.

에어바이트 GitHub 스타 히스토리

에어바이트 GitHub:

7. 그럴듯한 분석 — 오픈 소스 Google Analytics 대안

그럴듯한 분석: 오픈 소스 Google Analytics 대안

Plausible Analytics는 개인 데이터를 수집하지 않고 자세한 웹 사이트 활동 보고서를 제공하는 개인 정보 보호 분석 솔루션입니다. 실시간 분석 및 보고 기능을 제공하며 웹사이트 성능을 이해할 수 있는 간단하고 직관적인 인터페이스를 제공합니다.

그럴듯한 분석 GitHub 스타 기록

그럴듯한 분석 GitHub:

8. Supabase — 오픈 소스 Firebase 대안

Supabase는 백엔드 데이터베이스, API 및 실시간 데이터 계층을 통해 웹 애플리케이션을 구축하고 호스팅하기 위한 완벽한 플랫폼을 제공합니다. 애플리케이션 생성 및 관리를 위한 간단하고 직관적인 인터페이스를 제공하며 팀을 위한 강력한 협업 도구를 제공합니다. 다양한 다른 도구와 확장 및 통합할 수 있는 기능을 갖춘 Supabase는 Firebase의 훌륭한 대안입니다.

Supabase: 오픈 소스 Firebase 대안

SupaBase GitHub 스타 히스토리

수파베이스 GitHub:

9. Kdenlive — 오픈 소스 Adobe Premiere 대안

KDenLive는 고품질 비디오 콘텐츠를 생성, 편집 및 생산하기 위한 강력하고 유연한 플랫폼을 제공하는 오픈 소스 비디오 편집 소프트웨어입니다. 다양한 형식을 지원하며 다중 트랙 편집, 색상 보정, 시각 효과와 같은 고급 기능을 포함합니다. 사용자 친화적인 인터페이스와 활발한 커뮤니티를 갖춘 KDenLive는 아마추어 및 전문 비디오 편집자 모두에게 탁월한 선택입니다.

Kdenlive — 오픈 소스 Adobe Premiere 대안

Kdenlive GitHub 스타 기록

Kdenlive GitHub:

10. Mastodon — 오픈 소스 Twitter 대안

Mastodon — 오픈 소스 Twitter 대안

Mastodon은 Twitter와 같은 중앙 집중식 소셜 미디어 플랫폼에 대한 오픈 소스 대안입니다. 사용자가 서로 연결하고 콘텐츠를 공유하며 온라인 커뮤니티에 참여할 수 있도록 하는 분산형 서버 네트워크입니다. 업데이트 게시, 이미지 및 비디오 공유, 좋아요, 댓글 및 재게시를 통해 다른 사용자와 상호 작용하는 기능을 포함하여 기존 소셜 미디어 플랫폼과 동일한 많은 기능을 제공합니다. Mastodon은 개인 정보 보호, 언론의 자유, 온라인 신원에 대한 통제를 강조하므로 이러한 원칙을 중시하는 사용자에게 인기 있는 선택입니다.

마스토돈에 대한 GitHub 스타 히스토리

마스토돈 GitHub:

결론

결론적으로 이 10개의 오픈 소스 GitHub 리포지토리는 활기차고 번성하는 오픈 소스 커뮤니티에 대한 증거입니다. 독점 솔루션에 대한 비용 효율적인 대안을 제공하고 개발자, 데이터 분석가 및 비즈니스 모두에게 유용한 도구를 제공합니다. 오픈 소스의 장점을 활용하여 이 10개 프로젝트는 강력하고 효과적인 솔루션을 개발했으며 확실히 탐색하고 지원할 가치가 있는 중요한 자산입니다.

반응형
반응형

https://www.ciokorea.com/news/23032

 

당신의 회사에 우수 IT인재가 다니지 않는 4가지 이유

IT관리자나 HR 담당자라면 회사가 필요로 하는 기술, 지식, 경험과 기존 인재간의 격차가 존재한다는 사실을 알고 있을 것이다.최

www.ciokorea.com

IT관리자나 HR 담당자라면 회사가 필요로 하는 기술, 지식, 경험과 기존 인재간의 격차가 존재한다는 사실을 알고 있을 것이다.



최근 인재파견 기업인 맨파워(Manpower)가 전 세계 3만 7,000명의 고용주들을 대상으로 실시한 설문조사에 따르면, 응답자 중 36%가 적절한 인재 확보에 어려움을 겪고 있다고 밝혔다. 응답자 중 35%는 고도의 기술력 또는 ‘기술적 숙련도’의 부족을 이유로 꼽았고 25%는 경험의 부족을, 19%는 역량 부족으로 적임자를 찾기가 어렵다고 답했다.

기술 격차가 정말 존재하나?
펜실베니아대학교(University of Pennsylvania) 와튼 스쿨(The Warton School)의 경영학 교수 피터 카펠리는 기술 격차 문제를 연구했는데, 격차가 중요한 게 아니라 기술의 불일치 문제가 더욱 심각한 것으로 나타났다. 고용주가 문제를 방지하기 위해 모집, 고용, 보존 활동을 면밀히 파악한다면 해결할 수 있는 문제라고 카펠리는 말했다.

카펠리는 올 해 초 CEPR(Center for Economic Policy Research)에 실린 기고문에서 자신의 생각을 언급한 바 있다. 실제로 기술 공백을 뒷받침하기 위해 사용된 모든 증거는 고용주가 개인적인 일화, 컨설팅 기업의 독자적인 설문조사, 업계의 협회 등이 제시한 것이라고 카펠리는 전했다.

다시 말해 실제로 어디에 문제가 있는지 정확히 지적하기 위한 충분히 객관적인 데이터는 제공하고 있지 않다는 뜻이다. "설문조사에서는 고용주들이 고용에 어려움을 겪고 있다고 밝히고 있지만, 그 '어려움'이 무엇인지 정의하지도 않고 그 이유도 묻지 않는다. 이런 보고서를 검토하면서 많은 보고서가 실제로는 모순적인 증거를 제시하고 있다는 사실을 발견했다. 놀랍게도 많은 고용주들이 어려움의 원인을 저임금, 교육 부재, 기술 필요성의 예측성 부족 등으로 꼽고 있다"고 카펠리는 지적했다.

IT인재를 찾고 있는 상황에서 다음의 4가지 문제를 안고 있다면, 고용주 자신이 바로 최악의 적일 것이다.

완벽한 사람을 찾으려 한다
구인구직 연계 서비스를 제공하는 포처블(Poachable)의 CEO 이자 창업자인 톰 릉은 저녁 외식에 비유해 설명했다. "훌륭한 바클라바(Baklava)를 제공하고 야외 식사 공간이 있는 3성급 지중해풍 식당을 찾고 있는 상황에서 '음식이 뛰어난 최고급 식당을 원한다'고 말하는 순간 선택권은 훨씬 제한적이게 된다"고 밝혔다.

이 비유는 IT 및 엔지니어링 인재를 찾을 때와도 관련되어 있다. 검색 파라미터가 광범위하면 다이아몬드 원석을 찾아내는데 도움이 될 수 있다.

"IT의 명명법은 심오하지만, 어떤 점이 부족한 지에 대해 제대로 인지하지 못하도록 할 수 있다. 변화가 가능한 기술을 가진 좋은 지원자를 찾기 위해 선택의 폭을 넓히고 싶은가? 아니면 유리구두가 발에 딱 맞는 '신데렐라' 지원자를 찾기 위해 수 개월 동안 수 천 달러의 비용을 지출하면서 생산성 마저 잃고 싶은가?"라고 릉은 반문했다. 많은 경우에 고용 기업은 대기 비용을 간과하며, 적합한 사람이 되도록 교육할 수 있는 훌륭한 지원자를 고려하지 않는다는 게 릉의 지적이다.

릉의 관점에서 중요한 것은 장기적인 관점에서 투자를 결정하는 것이다. "'완벽한' 사람을 찾는데 1년이 걸릴 수 있으며, 찾는다 하더라도 치열한 경쟁을 벌여야 한다. 그렇게 괜찮은 사람이라면 다른 곳에서도 분명 그 사람을 원할 것이다. 또는 배움에 목마른 젊고 경험이 부족한 사람을 찾아 교육하고 다듬어서 수 개월 만에 자신에 원하는 직원으로 변신시킬 수 있다. 어느 쪽에 투자하고 싶나?"라고 릉은 말했다.

교육과 훈련에 초점을 맞추지 않는다
대부분의 고용주들은 고용을 통해 필요한 기술을 얻고자 하며, 이런 기술의 상당부분은 업무 경험에서 얻을 수 있는 것으로 보인다고 카펠리는 주장했다. 이 때문에 지난 수 십 년 동안 훈련과 견습의 기회가 점차 사라지게 되었다.

"미국 내에서 고용주가 제공하는 교육에 관한 신뢰할 수 있는 증거는 최근 더 이상 찾아볼 수 없게 되었다. 데이터에 따르면, 1979년에는 젊은 노동자들이 연 평균 2.5주의 교육을 받았다. 인구조사국에 따르면, 1991년까지 당 해에 공식적인 교육을 받았다고 밝힌 직원은 전체의 17%에 불과했다. 1995년경 고용주들을 대상으로 하는 여러 설문조사에서 고용주의 42~90%가 교육을 제공했으며 (수치가 낮을수록 교육이 계획적이라는 뜻이다) 개인이 받는 교육의 양은 연 평균 11시간 미만인 것으로 나타났다"고 카펠리는 설명했다. 이어서 그는 ILR 검토 (Industry and Labor Relations Review) 를 위해 작성한 근간서류를 위해 축적한 데이터를 공개했다.

이 데이터는 현재 약 20년이나 된 것으로, 여기서 얻을 수 있는 새로운 정보는 거의 존재하지 않았다. "2011년, 액센츄어는 미국의 고용인들을 대상으로 설문조사를 조사하여 지난 5년 동안 고용주가 제공한 공식적인 교육을 받은 직원이 21%에 불과하다는 결과를 얻었다. 다시 말해 약 80%가 5년 동안 교육을 받은 적이 없으며, 그 전에도 교육을 받은 사람이 그리 많지 않았을 것이라 생각한다"고 카펠리는 말했다.

공식적인 내부 교육은 감소세를 보이고 있다. 인재채용 및 파견기업 캐리어글라이더(CareerGlider)의 공동 창업자 선일 사니는 "과거에는 현장 교육의 기회가 많았지만, 기업들이 예산 삭감을 시도하면서 씨가 말랐다"고 밝혔다.

고용주들은 오늘날의 IT 전문가가 상황을 해결해주길 바라고 있다. "요즘의 기업들은 직원들이 필요한 기술을 교육하기 위한 기반시설 없이 이미 이런 기술을 갖추고 입사하기를 원하고 있지만, 현실은 그렇지 못하다"고 사니는 말했다.

독립적인 프로그래밍 교육기관과 전자학습 제공자들은 지원자들이 고용주가 내부적으로 인재를 발전시키고 성장시키기 위한 내부적인 교육 프로그램과 과정에 대한 투자를 고려해야 하는 중요한 기술을 얻을 수 있도록 돕고 있다.

"확보한 인재의 교육과 성장에 투자해야 하며, 이를 통해 고용에만 의존하는 대신에 충분한 결과물을 얻게 될 것이다"고 사니는 전했다.

경쟁력 있는 충분한 임금을 지불하지 않는다
또한 카펠리는 조사를 통해 흥미로운 추세를 발견했다. 예를 들어, 맨파워의 설문조사에서는 적합한 지원자가 부족한 이유를 물었을 때 응답자의 약 20%가 구직자들이 제시하는 임금 수준에 해당 직위를 수용할 의향이 없다고 답한 반면에 오직 5%만이 고용 문제를 해결하기 위해 임금 인상을 계획 중이라고 답했다.

"2008년과는 상황이 다르다. 기업들은 정신을 차리고 필요한 주요 기술을 갖춘 인재를 얻기 위해서는 인상된 시장 가치를 지불해야 한다는 사실을 깨달아야 한다"고 릉은 지적했다. 실리콘밸리에서 파시픽 노스웨스트(Pacific Northwest)와 기타 기술 지향적인 도시들, 소프트웨어 엔지니어, 개발자들은 높은 임금을 요구하고 있으며, 똑똑하고 혁신적인 기업들은 이런 기술에 지불해야 할 프리미엄의 필요성을 인지하고 있기 때문에 그만한 대가를 지불하고 있다. "고임금을 지불할 생각이 없다면 모든 것을 잃게 될 것이다"고 릉은 강조했다.

내부 IT인력으로 기술 공백을 해결하려 노력한다
기업이 필요한 인재를 찾는데 어려움을 겪고 있다면 지원자들을 탓하거나 ‘보이지 않는 시장의 손’이 문제라고 생각하기 십상이다. 하지만 이런 변명은 대부분이 근거 없는 것들이다. 뛰어난 인재를 끌어 들여 보유하고 싶다면 스스로 첫 걸음을 내디뎌야 한다.

반응형
반응형

멀쩡한 앱을 Flutter 앱으로 다시 짠 이유 - 일본 1위 배달 앱, 두 번째 Recode

https://engineering.linecorp.com/ko/blog/demaecan-2nd-recode-kmm-to-flutter

 

멀쩡한 앱을 Flutter 앱으로 다시 짠 이유 - 일본 1위 배달 앱, 두 번째 Recode

안녕하세요, LINE+ ABC Studio에서 앱을 개발하고 있는 김종식, 남상혁입니다. 저희 팀은 현재 일본에서 운영하는 배달 서비스 '데마에칸(Demaecan, 出前館)' 프로덕트를 개발하고 있습니다. '데마에칸(

engineering.linecorp.com

Flutter를 선택한 이유

데마에칸 서비스는 고유한 디자인으로 개발됐기 때문에 모바일 개발자 모두가 공통 UI 코드까지 작성할 수 있는 기술을 고민했습니다. 모바일 멀티 플랫폼 기술 중 온전히 앱 개발이 가능한 기술로는 대표적으로 RN과 Flutter가 있습니다.

Google Trends - Flutter vs React Native(in Japan) 

그 중 두 번째 Recode를 위한 기술로 Flutter를 선택한 이유는 다음과 같습니다.

  • Flutter는 최근 모바일 앱뿐 아니라 PC와 웹 개발도 가능하게 돼 플랫폼 확장성을 확보할 수 있었고, 기술 공개 후 빠르게 발전하고 있어서 필요한 정보를 보다 수월하게 획득할 수 있을 것이라고 판단했습니다.
  • 공통 코드로 UI를 구성할 수 있으며 자유도가 높았습니다. 특히 KMM 개발 당시 Android Compose UI 개발 만족도가 높았던 터라 선언형 UI 패러다임으로 완전히 전환하고자 했던 저희 목적에 부합했습니다.
  • 네이티브 대비 성능 부분에서 위험성이 낮았고, 네이티브 기능을 개발할 때는 MethodChannel을 활용하면 크게 제약 받는 부분이 없었습니다.
  • 통합 개발 환경(IDE) 부분에서 팀 원 모두에게 익숙한 Android Studio를 활용할 수 있었습니다(참고). 


Flutter로 다시 갈아엎자 ㅆ (←웃는 눈 모양입니다)

Flutter는 Dart 언어를 사용합니다. 따라서 Dart 언어에 익숙해지지 못하면 Flutter로 제대로 개발할 수 없습니다. 이때 Dart tour 문서를 참고하면 언어 특징을 빠르게 훑어보기 좋습니다. Dart 언어의 상세한 부분까지 잘 소개한 문서입니다. Dart 언어를 개략적으로 이해한 후에 Flutter Codelab 페이지를 읽어보면 Flutter를 보다 쉽게 이해할 수 있습니다.

Recode는 Dart 언어를 익히고 Flutter에 익숙해지는 것으로 시작해서 시작부터 출시까지 약 3개월 정도 진행했습니다. 제한된 기간 내에 1.0과 3.0 모드를 모두 제공해야 했으므로 공식 문서를 보며 Dart와 Flutter를 학습하면서 동시에 스펙 - 뷰 상태 - 로직을 잘 분리해 나가며 학습과 개발을 동시에 진행했습니다. Recode 시작 당시에는 Flutter SDK 3.0.2이었고, 출시할 즈음에는 Flutter SDK 3.0.5로 개발했습니다.

Flutter는 선언형 UI 개발을 하기 때문에 가장 큰 고민 거리는 UI 상태 관리입니다. 상태 관리와 관련해서 provider bloc, getx 등의 패키지가 있는데요. 처음 Recode를 시작할 때 패키지 학습 비용 및 패키지 의존성으로 인한 부담 때문에 직접 구현하는 형태로 진행했습니다. 상태 변경을 위해서 ChangeNotifier를 활용했고, 상태 집단은 StateModel로 관리했습니다. 제품 개발에 반드시 필요한 패키지(예를 들어 FlutterFire, google_maps_flutter 등)가 아니라면 가급적 직접 구현하는 것을 원칙으로 정했습니다.

 

KMM과 비교해 구현 난이도가 높았던 사례

Flutter로 갈아엎으면서 KMM과 비교해 구현 난이도가 높았던 부분도 있었습니다. 권한 획득이나 푸시 수신 시나리오 같은 경우 각 플랫폼에서 제안하는 개발 가이드라인에 차이가 있는데요. KMM 때는 네이티브 영역을 각각 구현해 코드 복잡도가 높지 않았는데 Flutter로 변환하면서 하나의 코드로 작성하다 보니 플랫폼에 따른 분기 코드가 종종 발생해서 코드 가독성을 저해하는 부분이 있었습니다. 아래는 Flutter로 변환한 후 Android와 iOS 앱 실행 후 흐름입니다. 

  • Android 앱 실행 흐름

  • iOS 앱 실행 흐름

플랫폼별로 SDK나 패키지 작동이 달랐던 사례

플랫폼별로 SDK나 패키지 작동이 기대와는 조금씩 달랐던 경우도 있었습니다. 예를 들어 앱 내 진동 효과를 발생시키는 코드를 플랫폼별로 다르게 구현해야 하는 경우입니다. Android는 Vibration 패키지에서 제공하는 인터페이스를, iOS에서는 Flutter SDK에서 제공하는 인터페이스를 사용하는 것이 요구 사항에 가장 적합하게 작동했습니다. 스펙에는 진동이 300ms, 500ms, 1000ms와 같은 방식으로 정의돼 있었는데 플랫폼별로 작동에 차이가 있어서 이를 구현할 때 분기가 필요했습니다. 

de_theme_effect.dart

void _vibrate300() async {
    if (PlatformUtils.isAndroid) {
        if (await Vibration.hasVibrator() == true) {
            Vibration.vibrate(duration: 300);
        }
    } else if (Platform.isIOS) {
        HapticFeedback.lightImpact();
    }
}
 
void _vibrate500() {
    /// implements
}
 
void _vibrate1000() {
    /// implements
}
Dart

위와 같은 코드는 Recode 출시 후 단계적으로 추상화하며 플랫폼별 구현체로 리팩토링하고 테스트 코드를 작성하면서 보다 가독성이 높고 유지 보수하기 좋은 형태로 변경하고 있습니다. 아래는 위 코드를 개선한 결과입니다.

de_theme_effect.dart

// The interface is reused.
void _vibrate300() => VibrationHelper.vibrate(VibrationEffect.effect300);

...

enum VibrationEffect { effect300, effect500, effect1000 }

class VibrationHelper {
	// vibration only support Android, iOS platform.
	static void vibrate(VibrationEffect effectType) {
		// Note) PlatformUtils also an abstract class of each platform implementations.
		if (PlatformUtils.isAndroid) {
			_vibrateAndroid(effectType);
	    } else if (PlatformUtils.isIOS) {
			_vibrateIOS(effectType);
    	} else {
			log('${effectType.name} vibrate fail, Unsupported platform type');
		}
	}

	static void _vibrateAndroid(VibrationEffect effectType) async {
    	// implementation as a vibration package.
		if (await Vibration.hasVibrator() == true) {
			switch (effectType) {
				case VibrationEffect.effect300:
					Vibration.vibrate(duration: 300);
				break;
				case VibrationEffect.effect500:
					Vibration.vibrate(duration: 500);
          		break;
		        case VibrationEffect.effect1000:
          			Vibration.vibrate(duration: 1000);
		        break;
			}
		}
	}

	static void _vibrateIOS(VibrationEffect effectType) {
		// implementation as a flutter(default) package.
		switch (effectType) {
			case VibrationEffect.effect300:
				HapticFeedback.lightImpact();
			break;
			case VibrationEffect.effect500:
				HapticFeedback.mediumImpact();
			break;
			case VibrationEffect.effect1000:
				HapticFeedback.heavyImpact();
			break;
		}
	}
}
Dart

트러블 슈팅 사례

두 번째 Recode 과정 중에 경험한 주요 트러블 슈팅 사례를 소개하겠습니다. 

Google 지도 관련 이슈

먼저 Google 지도와 관련해서 발생한 두 가지 이슈를 소개하겠습니다.

의존 관계 업데이트 후 사이드 이펙트로 앱 성능 저하

배송원 앱에서는 배송원 위치와 가맹점 위치, 고객 드위치를 지도 위에 마커로 표시합니다. 지도는 Google 지도(google_maps_flutter) 패키지를 사용하고 있고, Google 지도를 사용하기 위해 아래와 같이 pubspec.yaml에 Caret 문법를 활용해 의존 관계를 추가해 놓았습니다. 그런데 어느 순간 앱 성능이 급격히 저하되는 이슈가 발생했고, 확인 결과 google_map_flutter 버전이 올라가면서 각 플랫폼 구현체 의존 관계가 업데이트된 것을 확인할 수 있었습니다. 이슈 발생 전후 pubspec.lock을 비교해 보면 아래와 같습니다. 

정상 작동 시 pubspec.lock

google_maps_flutter:
  dependency: "direct main"
  description:
    name: google_maps_flutter
    url: "https://pub.dartlang.org"
  source: hosted
  version: "2.1.9"
google_maps_flutter_platform_interface:
  dependency: transitive
  description:
    name: google_maps_flutter_platform_interface
    url: "https://pub.dartlang.org"
  source: hosted
  version: "2.2.1"
YAML

성능 이슈 발생 후 pubspec.lock

google_maps_flutter:
  dependency: "direct main"
  description:
    name: google_maps_flutter
    url: "https://pub.dartlang.org"
  source: hosted
  version: "2.2.0"
google_maps_flutter_android:
  dependency: transitive
  description:
    name: google_maps_flutter_android
    url: "https://pub.dartlang.org"
  source: hosted
  version: "2.3.0"
google_maps_flutter_ios:
  dependency: transitive
  description:
    name: google_maps_flutter_ios
    url: "https://pub.dartlang.org"
  source: hosted
  version: "2.1.11"
google_maps_flutter_platform_interface:
  dependency: transitive
  description:
    name: google_maps_flutter_platform_interface
    url: "https://pub.dartlang.org"
  source: hosted
  version: "2.2.2"
YAML

이슈 발생 원인은 google_map_flutter가 2.2.0으로 버전이 올라가면서 google_map_flutter_android 패키지 의존 관계가 업데이트돼 발생한 사이드 이펙트였습니다. 이슈를 해결하기 위해 pubspec.yaml에 선언한 google_maps_flutter 패키지 버전을 caret 문법 대신 고정된 버전을 사용하는 것으로 수정했습니다. 

pubspec.yaml

# AS-IS: Performance degradation due to version-up
dependencies:
	google_maps_flutter: ^2.1.3 // It means '>=2.1.3 <3.0.0'

# TO-BE: Specify as fixed version
dependencies:
	google_maps_flutter: 2.1.9
YAML

네이티브 영역에서 크래시 발생

Google 지도와 관련해 발생한 또 한 가지 이슈가 있습니다. 출시 후 Android 버전에서 crash-free(* 특정 기간 동안 비정상 종료가 발생하지 않은 사용자 비율)가 약 96~97%로 불안정한 상태가 지속됐습니다. Crashlytics 로그에서는 ByteBuffer나 Thread 등 네이티브 영역에서 크래시가 발생한 것으로 나타나 정확한 원인을 파악하기 힘든 상황이었는데요. 크래시 발생 시 생성된 로그를 분석한 결과 강제 로그아웃이 발생해 로그인 화면으로 전환될 때 이런 상황이 발생하는 것을 확인할 수 있었습니다. 배송원 앱은 로그인에 성공하면 Google 지도를 화면에 표시하는데 이때 화면 전환 등으로 지도가 표시되는 화면이 사라질 때 크래시가 발생하는 것으로 예상됐습니다.

이 이슈는 Google MapView의 Rendering 옵션을 LATEST로 사용하면 해결할 수 있는 것으로 알려져 있었습니다(참고). 이를 참고해서 Android 네이티브 소스 코드를 수정해 crash-free를 99% 이상으로 안정화할 수 있었습니다. 현재 google_maps_flutter_android 패키지 2.4.0 버전부터는 LATEST 렌더링 옵션을 제공하도록 개선돼(참고) Flutter 소스 코드에서도 렌더링 옵션을 수정할 수 있도록 업데이트됐습니다(이와 관련해 google_maps_flutter에 등록된 이슈를 참고하시기 바랍니다).

제스처 미작동 이슈

아래 화면은 배송원 앱의 주문 상세 확인 화면입니다. 이 화면에서는 크게 좌우로 스와이프해 페이지 닫기, PageView 내에서 좌우로 스와이프해 탭 화면 이동, Google 지도 내에서 핀치 줌(pinch zoom) 제스처가 가능합니다. 그런데 Android 기기에서 Google 지도 내 핀치 줌이 작동하지 않는 이슈가 발생했습니다.

   

제스처와 관련해 발생하는 문제는 두 가지였습니다.

Gesture Arena에서 여러 제스처가 경쟁해 Google 지도 제스처가 제대로 작동하지 않음

Gesture Arena에서 좌우 페이지 스와이프 제스처, 페이지 백 제스처, 상하 스크롤 제스처, 지도 제스처 등 여러 제스처가 경쟁해 Google 지도 제스처가 제대로 작동하지 않는 경우가 발생했습니다. 이때 Gesture Arena에서 경쟁하지 않고 즉시 모든 터치 이벤트를 받을 수 있게 하려면 gestureRecognizers에 EdgarGestureRecognizer를 추가해야 합니다.

EdgarGestureRecognizer는 일반적으로 AndroidView.gestureRecognizers에서 전달되며 뷰 범위 내 모든 터치 이벤트를 내장된 Android View로 즉시 발송하기 때문에 Gesture Arena에서 경쟁하지 않고 모든 터치 이벤트를 즉시 발송하므로 모든 터치를 전달받을 수 있습니다. Google 지도와 같이 모든 이벤트를 즉시 받아야 하는 뷰의 경우 유용하게 사용할 수 있습니다.

PageView 이동 시 첫 번째 페이지의 Google 지도에서 멀티 터치가 제대로 작동하지 않음

이 문제는 viewportFraction이 기본 값인 1.0인 경우 페이지가 완전히 넘어갔다고 판단하지 않아서 포커스를 완전히 넘겨주지 않아 발생한 문제였습니다. PageView의 allowImplicitScrolling 프로퍼티 true로 설정해서 다음 화면 요소로 이동했다고 판단되면 포커스를 이동하도록 설정해 해결할 수 있었습니다.

텍스트 표시 관련 이슈

일본어 한자가 중국어 번체로 표시됨

iOS 기기 중 특정 기기에서 일부 문자가 일본어가 아닌 중국어(번체)로 표시되는 이슈가 발생했습니다. 예를 들어, '配達設定(배달설정)' 문구에서 일본어 한자('設')가 아닌 중국어 한자('設')로 표시되는 이슈로, 기기나 OS에서 제공하는 폰트마다 이런 이슈가 있을 것으로 예상했습니다. 

배송원 앱 설정 화면 > 중국어 한자 표시 이슈

이 이슈를 해결하기 위해 스타일 프로퍼티(TextStyle)에 locale 프로퍼티를 각 언어에 맞게 잘 설정해 줬지만 해결되지 않았습니다. 이에 iOS 기본 폰트에서 일본어 한자를 제대로 지원하지 않는 경우가 있다고 판단했고, iOS의 fontFamilyFallBack 프로퍼티를 [.AppleSystemUIFont', 'Hiragino Sans']로 설정해 해결할 수 있었습니다. 아래는 코드 실행 결과입니다.

폰트별 '配達設定(배달설정)' 문구 표시 차이

Chinese Japanese
   
...
Column(
	mainAxisAlignment: MainAxisAlignment.start,
    crossAxisAlignment: CrossAxisAlignment.start,
    children: <Widget>[
        Text(
			'配達設定 (배달설정)',
			style: TextStyle(fontSize: 20, fontWeight: FontWeight.bold)
		),
		Text(
            '配達設定 (배달설정)',
            style: TextStyle(fontSize: 20, fontWeight: FontWeight.bold)?.merge(TextStyle(
               fontFamilyFallback: Platform.isIOS ? const ['.AppleSystemUIFont', 'Hiragino Sans'] : null,
               leadingDistribution: TextLeadingDistribution.even,
            )
		),
	),
])
Dart

텍스트 크기를 최소 혹은 최대로 설정하면 화면이 제대로 표시되지 않음

iOS와 Android 앱은 기기 설정에서 디스플레이 및 텍스트 크기를 변경할 수 있습니다. 기기 설정에서 이 옵션을 최소 및 최대로 설정할 경우 화면이 제대로 표시되지 않는 이슈가 발생했습니다. 이를 수정하기 위해 디자인 팀과 논의해 MediaQuery 위젯을 이용해서 textScaleFactor를 0.7~1.4로 제한하고, 필요에 따라 고정된 텍스트 크기로 표시되는 위젯을 만들어 대응했습니다. 

DeWidgetLimitedScaleText

class DeWidgetLimitedScaleText extends StatelessWidget {
  final bool isScalable;
  final Widget child;

  const DeWidgetLimitTextScale({Key? key, this.isScalable = true, required this.child}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final mediaQuery = MediaQuery.of(context);
    return MediaQuery(
      data: mediaQuery.copyWith(textScaleFactor: isScalable ? min(1.4, max(0.7, mediaQuery.textScaleFactor)) : 1.0),
      child: child,
    );
  }
}
Dart

백그라운드 상태에서 FCM(Firebase Cloud Messaging) 수신 시 isolate 관련 이슈 

firebase_messaging 패키지를 이용하면 앱이 백그라운드에 있는 상태에서 FCM 푸시 수신 처리가 가능합니다(참고). 그런데 이때 SharedPreference에 접근할 경우 'When received, an isolation is spawned. Since the handler runs in its own isolate outside your applications context, it is not possible to update application state or execute any UI impacting logic.' 메시지와 함께 오류가 발생합니다. 

Dart 앱은 단일 스레드 프레임워크이며 스레드 대신 isolate에서 작동합니다. Isolate를 새로 만들고 서로 통신할 수는 있지만 각 isolate는 고유한 메모리 힙을 할당받기 때문에 공유하는 메모리는 없습니다. 백그라운드에서의 푸시 콜백은 새로운 isolate에서 전달하는 것이기 때문에 메인 isolate의 메모리 데이터를 사용할 수 없어서 위와 같은 오류가 발생합니다. 이 문제는 앱 디렉터리 하위에 JSON 형식의 파일로 데이터를 저장하고 관리할 수 있는 유틸리티를 만들어서 FCM 수신 시 로컬에 데이터 저장이 필요한 경우에는 이 유틸리티를 사용하는 것으로 해결했습니다. 

기술 변경으로 더욱 돈독해진 팀워크

두 번째 Recode 과정에서는 새로운 기술을 학습하면서 동시에 그 기술을 활용해 제품을 만들어 내는 과정을 진행했습니다. Flutter 기술을 완벽히 이해하고 있지 않아서 여러 가지 우려가 있었지만 결과적으로 긍정적인 피드백이 많았습니다. 두 번째 Recode 프로젝트 회고에서 KMM에서 Flutter로 전환한 결과 가장 좋았던 점으로 모든 분들이 공감해 주신 것은 동일한 소스 코드로 고민과 토론이 가능해졌다는 점이었습니다. 

KMM으로 개발할 때는 Android와 iOS, KMM 각 영역에서 개발자가 본인 업무에 해당하는 영역에서만 개발을 진행하면서 각자의 관심 기술에만 집중했고, 이는 결국 장기적인 관점에서의 협업 측면이나 기술 성장 측면에서 아쉬움을 남겼는데요. Flutter로 전환하면서 Flutter라는 기술과 Dart라는 언어를 이용해 함께 고민하고 학습하며 그 내용을 실제 프로덕트에 반영하는 기회를 얻었고, 그 과정에서 발생한 급박한 상황 역시 생각보다 더 긍정적으로 회고됐습니다. 저희와 같이 소수(3~4명) 인원이 하나의 앱을 개발할 때는 같은 언어로 함께 고민하며 프로젝트를 진행하는 게 성장과 협업 측면에서 더 큰 동기를 부여할 수 있다는 것을 느꼈습니다.

팀 전체 관점에서도 공감대가 넓어졌습니다. 데마에칸 서비스 중 배송원 앱뿐 아니라 가맹점 앱, 리테일 앱 역시 Flutter를 활용하고 있기에 팀 차원에서 기술 교류가 시작됐고, 각 앱에서 공통으로 사용하는 모듈도 개발 가능해져 협업 측면에서도 좋아졌습니다. IDE나 CI/CD 환경 혹은 각 프로젝트의 아키텍처를 공유할 수 있게 됐고, 리팩토링이나 테스트 코드 등도 함께 고민하고 공유할 수 있어서 개인은 물론 팀 전체가 함께 성장하는 데 큰 도움이 되고 있습니다(공통 모듈을 만들어 활용하고 있는 내용은 Flutter 패키지로 공통 모듈 리팩토링하기를 참고하세요).  🙂

마치며

모바일 앱 개발 기술로 Flutter를 고민하고 있다면 아래와 같은 이유로 추천합니다.

  • 한정된 자원으로 멀티 플랫폼 개발을 할 수 있습니다. Android와 iOS뿐 아니라 PC와 웹으로도 개발할 수 있어서 다양한 형태로 제품을 검증할 수 있고 QA 환경 구성에도 유리합니다.
  • 앱 개발자에게 멀티 플랫폼 기술은 네이티브 개발자에게 다음 단계를 도전하기 위한 큰 과제와도 같기 때문에 커리어를 쌓고 채용 시장에서 경쟁력을 높일 수 있는 좋은 기회라고 생각합니다.
  • 개인과 팀 모두 고민하고 성장하기 위한 환경을 고민하고 있다면 좋은 선택이라고 생각합니다. 

배송원 앱은 Recode 후 새로운 버전에서 사용자에게 더 좋은 가치를 안정적으로 제공하기 위해 Flutter로 모듈화하고 테스트 코드를 작성하는 것에 집중하고 있습니다. Flutter 개발자분들과 더 나은 상태 관리 방법과 효율적인 의존 패키지 버전 관리 방법, 보다 빠른 빌드 및 배포 자동화 구성 방법, 그리고 새로운 프로덕트를 더 잘 만드는 방법 등을 고민하고 있습니다(개발자라면 대부분 공감할 부분들이라고 생각합니다 🙂 ). 사용자에게 더 나은 서비스를 제공할 수 있다면 세 번째 Recode를 진행해야 할 상황이 오는 게 조금은 기다려지기도 한다고 생각하며 글을 마치겠습니다. 

반응형

+ Recent posts