들어가면서
이전 포스트와 다른 포스트 등에서도 언급한바가 있지만 나는 진단기기 회사에서 학술 그리고 UIUX관련 기획 및 제작을 담당하고 있는 사람이다. 그러다보니, 이번 신제품 기획을 하면서 있었던 내용을 공유하려고 한다. 라인 및 다른 곳에서 Flutter의 도입에 대한 성공과 실패에 대한 포스팅을 많이 하는 것을 보았으나, 진단기기 관련해서는 그렇게 많은 정보를 찾을 수가 없어서, 적용하지 못했던 이유에 대해 한번 짧게 나마 짚고 넘어 가보려고 한다. 이 글이 크로스플랫폼을 사용하여, 다양한 채널에 사용하고자 하는 사람들에게 조금이 나마 도움이 되면 한다.
Flutter
플러터라고 하는 오픈 소스 프레임워크에 대해서 모르는 사람도 있고 아는 사람도 있을것이다. 이에 대해서 조금 짧게 설명을 해보자면 다음과 같다.
플러터는 구글에서 개발한 오픔 소스 프레임워크로, 모바일 앱과 웹 애플리케이션 빌드를 하기 위한 인터페이스 솔루션이다. 플러터는 하나의 코드베이스를 통해서 AOS와 iOS 용 앱을 만들 수 있기 때문에 개발자에게 시간과 노력을 절약하게 해주며, 이제는 PC 버전의 앱까지 만들수가 있어서 많이 각광을 받고 있는 제품이다. 능숙한 사용자 인터페이스와 성능으로 인해서 다양한 기기 및 화면 크기에 대해 자동으로 최적하가 되기 때문에 그 사용자 추세가 늘어나고 있는 추세다.
플러터 타 플랫폼 대비 장점이라고 하면 다음과 같다.
- 고성능 엔진: Skia 엔진을 사용하여 빠른 렌더링 엔진을 기반으로 하고 있으며, 애니메이션과 그래픽 처리를 효율적으로 수행할 수 있다.
- 화면 크기 및 해상도 대응: 다양한 기기와 화면 크기에 대응하는 용이한 형태이며, 한번의 코드 작성으로 다양한 플랫폼과 기기에 일관된 사용자 인터페이스를 제공한다.
- 위젯 라이브러리: 다양한 사전 제작된 위젯 라이브러리를 통해서 UI를 빠르게 구축할 수 있다.
- 핫리로드: 애플리케이션의 코드를 수정한 후 즉시 결과를 확인할 수 있는 핫리로드 기능을 통해 개발자의 생산성을 높여준다.
- 커뮤니티 지원: 플러트는 생각보다 큰 커뮤니티를 지원하고 있으며, 젊은 개발자의 유입이 활발하게 이루어지 기오 있어 문제 해결 및 새로운 기능에 대한 지원을 받기 쉽다.
그리고 가장 큰 장점이라고 한다면 Flutter의 개발이 구글(Google)이라는 점이다. 구글은 세계적인 IT기업이며, 모바일에서는 AOS (안드로이드)플랫폼을 가지고 있는 기업이다. iOS와 AOS의 양강 체계에서 사용자들은 어쩔 수 없이 AOS에 영향을 받을 수 밖에 없을 뿐더러, 개발자들의 경우에도 이렇게 안드로이드와 관련된 개발 툴등에 대해서 관심을 가질 수가 없다. 조금 더 확장을 하자면 개발자의 경우에는 Flutter로 앱을 만들었을때 사용자가 이용하는 Android에서는 잘 돌아갈 것이라는 확신을 할 수 있을 것이며, 이 때문에 더 많은 초기 개발자 들이 유입이 될 수 있는 상황이다.
진단기기 제품의 플랫폼으로의 검토
진단기기의 특성에 대해서 한번 말을 해보아야 겠다. 진단기기라고 하는 것은 일반적으로 앱내의 정보를 가지고 모든 것을 처리하는 것은 아니다. 일단 환자의 정보를 미리 입력하고 나면 특정한 카트리지에 환자의 혈액을 떨어뜨린 후 일정 시간동안 반응을 일으켜 거기서 발생하는 발광 혹은 형광 (색 변화)에 대한 정도를 파악해서 Calibration에 기반을 한 결과를 수치화 하여 환자의 진단에 도움이 될 수 있는 특정 바이오마커에 대한 수치를 제공하는 방식이다.
일단 크로스 플랫폼으로써의 장점으로써는 성능과 UI 개발편의성 그리고 트렌디 하다는 장점이 있기 때문에 선택을 진행하였고, 하얀 도화지에 그리는 듯 이 만들기 때문에 중간 Bridge가 없어 용이하다고 판단을 하였다. 그러므로써 속도면에서 장점이 있기 때문에 UI 개발에 간편할 것이라는 초기 판단이 있었다. 또한 Flutter가 출시되고 5년이 되어 가는 시점에서도 괜찮은 라이브러리가 많이 만들어 졌다고 판단을 하여서 실제로 도입을 검토해보았다.
또한 크로스 플랫폼으로써의 가장 중요한 점이
- 소형 (3인 미만) 개발팀에는 적합하다고 판단을 하였으며, 네이티브 개발자가 별도로 필요하지 않을 수도 있겠다.
- 앱과의 호환성을 고려하여 기업 측면에서는 새로운 플랫폼으로의 전환도 필요하였다.
- 학술 지원 플랫폼 채널과의 연동성에도 도움이 될 것이라고 판단을 하였다.
- 해당 기술이 현재 신제품에 도입이 되지 못한다고 하더라도, 추후 커뮤니티 앱 혹은 별도의 토이 스케일 앱을 만드는데 있어서 추후 활용가능성이 있다.
라는 점 등이 있었다.
도입하지 못한이유
그런데 왜 도입하지 못하였는가. Flutter를 적용하기 위한 과정 중에 있어서 생각 보다 많은 저항과 추가 검토가 필요했다. 조금 더 쉬운 개발과 빠른 제품 개발 및 시장 도입을 위해서 검토가 되었던 것이였지만 결국 기존의 개발방식으로 돌아오게 된것이다. 왜 그렇게 된것일까?
진단기기에 있어서 가장 중요한 것은 환자 정보의 처리와 환자 정보의 암호화이다. 혹은 다르게 말하자면 얼만큼 외부 공격으로 부터 스스로를 보호할 수 있으며, 업데이트를 하면서도 환자 정보를 잃어버리지 않도록 하는가 이다. 즉, 바코드 리딩 기능, 환자 정보 암호화, LIS 연결 기능 등과 같은 정보의 내부 처리 및 외부로의 송신등에 대한 다양한 라이브러리가 존재를 했어야한다는 것이다. 그게 아니라면 네이티브 코드 혹은 기존의 사용하던 언어와 연결을 하여서 사용할 수 있도록 구현을 해야했다.
즉, 기존에 있는 라이브러리 등을 사용하여 그래프 생성 및 리딩 기능등을 사용할 수 있겠지만 기존의 제품과는 다른 형태의 리딩 방식을 사용해야할 수가 있다. 그렇다면 지금까지 만들었던 제품 들의 기호 입력 방식등을 변경하여야 할 수 있는 상황이 발생할 수도 있었다. 그렇다고 해서 라이브러리를 제공하는 함수나 변수를 자유롭게 변경할 수 있는가? 그것도 그렇지는 않았다. 플러그인이 제공하지 않는다면 결국 내가 혹은 다른 누군가가 만들어야 하는 상황이였다.
회사 측에서 안드로이드에 대한 확장성을 나에게 주문을 했던 이유가 빠른 제품 출시와 더불어서 관리의 용이를 위함 이였는데 이렇게 되면 늘어나는 코드 속에서 플랫폼 의존성이 너무나도 높기 때문에 플러터와 네이티브 코드에 대한 별도의 관리를 진행을 해야 한다는 것이였다. 그렇다는 것은 무엇이다? 1인이 Flutter와 네이티브 코드를 모두 다룰 수 있던지 아니면 별도의 팀이 다시금 생성이 되어야 한다는 것이였다.
그리고 사측의 의견으로는 지금까지의 레거시 코드를 재활용하고 싶었기 때문에 Flutter를 적용할 시에는 호환성 문제로 초기 개발시간이 늦어질 수 있다는 점이였다 (실제로 이때 사측에서 원하는 기획 - 디자인 - 마케팅 - 개발 - MVP - 초기 판매 까지는 투입 인원 1,2인 기준 < 10개월 을 요청하였다). 그리고 이렇게 새롭게 만든 코드가 검증되지 않은 상황에서 기존 제품보다 더 나은 성능을 낼 수 있다는 보장을 할 수 가 없었다.
사용관련된 문제는 없었나?
생각보다 제스처 및 터치감에 관련되어서 진단기기는 좀 자유로운 편이다. 거의 키오스크 수준이라고 보면 된다. 해당 제품의 경우에는 사용자가 계속해서 지켜보고 사용하는 것이 아니다. 온스크린 시간으로 쳤을때 최장 10분이다. 그렇다는 말은 결국 큰 버튼과 쉬운 GUI가 필요하며 화면 전환 및 제스처 등에 대해서는 간결함이 필수라는 것이다. 쉽게 말하자면 클릭 - 다음페이지 이런 수준이라서 제스처에 대한 문제는 크지 않았다.
플랫폼 관련 문제
오히려 이 점이 문제 였다. 사측에서 원하는 것이라고 하면 하드웨어적인 제품에 대해서는 변경은 하지 않으면서도 단지 개발이 용이한 제품을 만들어 달라는 것이였다. 그렇다면 윈도우 베이스란 말인건데 나는 AOS (안드로이드)의 측면은 고려할 수 없이, Embedded 방식의 Flutter 적용 방법을 고민해야 하는 것이였다. 물론 진단기기의 경우에는 장면간의 전환이라던지 데이터 관리 측면에서는 안드로이드 및 아이폰 보다는 그 난이도가 어렵지는 않았지만, 문제는 PC 임베드 상황에서의 개발 Reference라던가 실사례 등을 확인할 수가 없었고, 라이브러리의 경우에도 일반 모바일 대비 너무나도 부족하단 것을 확인할 수 있었다.
그래서 초기에는 Flutter를 한달동안 배우면서 ChatGPT를 쓰는등 코드를 만들어보기도 하고 Flutter Flow 등을 사용하면서 실제 기기에 올려 테스트를 해보려고 노력을 해보았지만, 관련된 오류가 발생하였을때에는 Stackoverflow 및 여타 커뮤니티에서도 Embedded와 관련된 개발자들의 고견을 얻을 수가 없어서 계속하여 다른 방법을 찾는데 시간이 너무 많이 소요하였다. 또한, 기존 장비를 하드웨어적인 면을 유지하고 싶은 사측의 의견을 적극적으로 수용해야하는 상황이였기 때문에, 이에 관련된 새로운 부품 등을 도입할 수도 없었다.
향후 도입의사가 없는가?
무조건 적으로 없다고는 말을 못하겠다. 우연하게 플러터라는 프레임워크에 알게되었고 이를 통해 간단한 앱들을 만들어 보면서 발전가능성이 매우 높은 프레임워크라는 것은 확신하였다. 하지만, PC embedded용으로 진단기기에 도입하기에는 아직 시기 상조라는 생각을 한 것이다. 만약 Flutter를 2년이상 사용해본 경험자가 있었다면 다른 측면에서 접근을 했을 수도 있다.
기획과 디자인 그리고 개발을 테스터 형식으로 진행해야했기 때문에 개발적인 측면에서 문제가 발생하였을때, 이와 관련된 코드를 작성할 수 있을지에 대한 확신이 없었고 사측에서 제시한 프로토타이핑 및 MVP 제작에 대한 리드 타임이 매우 짧았다. 이에 대해 나는 너무나도 짧은 지식과 경험으로써 신제품의 컨셉을 소화할 수 있을 것 같다는 불확실성이 더 큰것이 사실 이였다. 만약 새로운 플랫폼을 도입한다는 것에 대해서 사전지식을 쌓을 시간과 충분한 토이프로젝트로 개발을 진행했다면 어쩌면 윈도우와 안드로이드 버전으로 신제품을 출시 할 수 있었을 지도 모른다.
마치면서
얼마전에 어느 책을 본적이 있었다.
비개발자 전공의 기획 및 UIUX 담당이 새로운 언어의 도입을 했어야 한다는 것도 참 우스운 일이였지만 이 기회를 통해서 왜 이 언어가 적용을 못하는지 그리고 정말 적용이 추후에도 불가능한지에 대해서 자세하게 알아볼 수 있었던 좋은 기회였다. Flutter는 계속해서 진화하고 있다. 지금 실리콘밸리에서 많이 사용하고 있는 언어로써 Dart-flutter가 사용량의 수직상승을 보이고 있는 것을 보면 그 의심은 거두어도 좋을 듯 한다.
이번 프로젝트를 위해서 Flutter라는 새로운 언어를 도입하지 못하였다. 그래서 더 많이 배운것이 있었고 추후에 다시 도입을 하게 된다면 어떤점을 보완해야할지도 이제 알게 되었다. 추후에 기회가 된다면 꼭 다시 한번 도전해보고 싶은 크로스 플랫폼이다.
'PM과 UIUX 이야기' 카테고리의 다른 글
| 의견 차이가 있는 임원과 실무자를 어떻게 설득해야하나? (1편) (0) | 2023.11.09 |
|---|---|
| 절망적인 상황에서 진단기기 기획은 어떻게 진행했을까? (2편) (0) | 2023.11.06 |
| 진단기기 신제품을 어떻게 기획하였나요? (1편) (1) | 2023.11.03 |
| 앱과 진단기기의 UI/UX 기획 하는법이 달라? (1) | 2023.10.27 |
| 진단기기에도 UI/UX가 필요해? (0) | 2023.10.26 |