크로스 플랫폼 독인가? 약인가?
딜라이트룸 생각은?
작성자 — Jason, Tech Lead @DelightRoom
요즘 어때?
요즘 종종 보는 지인들과 보통의 첫마디가 “요즘 어때?”입니다.
대부분 스타트업에 종사해서, ‘스타트업 한파’를 온몸으로 받아내고 있기 때문에 더욱더 서로의 안위를 많이 물어봅니다.
특히, 경영 악화로 구조조정, 채용 중지, 운영 비용 축소 처럼, 현재 힘든시기를 벗어나려는 노력에 대해서 자주 얘기가 나오곤 합니다.
그중에도 개발 모임(기술 교류 및 자문)에 가면 아무래도 타이트한 리소스에 해내야하는 업무는 많기 때문에, 다양한 생산성 이야기가 나옵니다. 스타트업이 겨울이여도 사용자에게 전달해야하는 가치는 줄지 않기에, 고민이 깊어지기 마련이죠.
그럴때마다 꼭 나오는 이야기가 바로 크로스플랫폼 개발이야기 입니다.
체감상 한국에서도, 2018부터 ReactNative를 주요 개발스택으로 고려하는 움직임들이 있었던것 같습니다.
(이후, 구글에서 출시한 Flutter도 관심이 높아지면서 점점 개발 커뮤니티에서는 크로스플랫폼에 대한 열기가 달아 올랐었습니다.)
크로스플랫폼 어때?
리소스가 부족할때, 가장 쉽게 떠올리는 솔루션으로 크로스플랫폼 개발이 종종 언급됩니다. 궁극적으로는 크로스플랫폼은 생산성 이슈를 해결하는 방법중 하나일텐데요.
아, 크로스플랫폼에 대해 더 들어가기 전에 간단히 소개를 드려보면, 개발 한번으로 iOS와 Android 앱을 모두 만들어내는 것이라고 생각하면 되겠습니다.
(보통, 앱 만들때 ‘iOS 앱개발’과 ‘Android 앱개발’ 이렇게 두번 개발하게 되는데, 이것을 한번의 개발로 줄인다고 생각하시면 되요)
크로스플랫폼에 대한 분명한 기대는 “one source multi use”에 있을것입니다. 그로 인해 궁극적으로 생산성 2배를 기대하며, 제품을 만들어가게 될것입니다.
그런데 사람들이랑 만날때 마다 “진짜 이거 생산성 2배 맞아?”라는 이야기를 자주 하게 됩니다.
왜냐하면 대표적인 크로스플랫폼(ReactNative, Flutter)으로 만든 서비스의 성공사례를 쉽게 듣기 어렵고, 그나마 알려진 회사들은(페북, 인스타, 그랩, 디스코드) 개발자만 이미 100명 넘는 회사인 경우여서,
전체 회사 규모가 100명 이하인 스타트업에서는 또 그것대로 공감하기 어려운 것도 있기 때문이죠.
그렇다면 크로스플랫폼으로 생산성 향상이 가능한지 장단점을 하나씩 뜯어 보면서 알아보려고 합니다.
그전에 한가지 전제가 있는데요. 비즈니스 문제중에는 크로스플랫폼으로 잘 풀수 있는것과 그렇지 않은것이 있다고 생각합니다.
크게 나누어보면 크로스플랫폼으로 ‘구현 가능한 것’과 ‘불가능한것’으로 먼저 나누어 볼수 있구요.
크로스플랫폼으로 구현 가능한것 중에서도 난이도가 ‘높은것’과 ‘낮은것’으로 나누어 볼수있다고 생각했습니다.
위의 전제를 그림으로 도식화해보면 아래와 같습니다.
장점
- 여러 플랫폼에 재사용할수 있는 코드
- 빨라진 개발 속도
- 적은 유지 비용 들어감
- 빠른 마켓 타이밍(iOS, An에 한번에 출시하니까)
단점
- 하드웨어 지원이 필요한 기능에, 추가 개발 리소스가 들어감 (크로스플랫폼에서 바로 지원안되는 경우도 있고, 지원되더라도 구현간 퍼포먼스등의 어려움이 있는 경우가 있음)
- 일반 네이티브 제품보다 퍼포먼스가 느림
- 각 플래폼별로 가이드하는 디자인 원칙을 일관적으로 따를수 없음 (Human Interface Guide, Material Design 을 모두 지키면서 일관성 있는 UX를 만드는게 어려움)
위에서 나열한 장단점은 일반적인 내용이라서, 실제로 의사결정간에 충분한 근거가 되지 않는다고 생각합니다. 그리고 정말 개발속도와 유지비용이 적게 들어가는 것인지 의문이 드는 경우도 있습니다.
먼저 스타트업에서는 크로스플랫폼을 선택하기 전에 정해야 할것은
- 현재 타겟하는 구체적인 사용자는 누구인가? (페르소나)
- 현재 제공하려는 사용자 가치는 무엇인가? (사용자 가치)
- 사용자 가치에 핵심이 되는 기능은 무엇인가? (핵심 기능)
위에 내용을 기반으로 사용자 문제를 정의하고 고객의 만족을 빠르게 줄수 있는 방법으로써, 크로스플랫폼이 가능하다고 충분한 리서치가 되면 의사결정할 수 있다고 생각합니다.
충분히 리서치 할때는 이런 기준들이 있을수 있다고 생각합니다.
- 핵심 기능은 디바이스 서포트가 많이 필요한 것인가?
- 핵심 기능간에 기대되는 최소 퍼포먼스는 어느정도인가?
- 크로스 플랫폼을 개발한다고 했을때, 워크플로우는 충분히 효율적인가?
- 핵심 기능 제공시, UX가 양쪽 플랫폼의 기본 디자인 원칙을 따를수 있는가?
- ….
결국에는 회사가 처한 상황에 맞게 사용하면 된다고 생각하는데요.
검색해보면 알겠지만, 생각보다 크로스플랫폼 사용에 대한 배움? 경험?을 자세하게 공유한 사례가 없긴합니다.
대표적으로는 Airbnb가 ReactNative를 누구보다 열심히 쓰면서, 얻은 교훈과 고민들을 자세하게 나누어 준 내용이 있어서, 그나마 도움이 많이 되었습니다. (내용이 상당히 알차고 꿀잼입니다. 결국 2018년도에 리액트네이티브 접고, 다시 네이티브 선언을 하긴 했지만요)
참고하시면 좋기 때문에 링크를 달아 놓아보아요.
그렇다면 딜라이트룸은 어떻게 크로스플랫폼을 바라보고 있는지 이어서 같이 보려고 하는데요.
그전에 제품 개발 철학에 대한 내용부터 나눠보겠습니다.
확장 가능하지 않은 일을 해라
딜라이트룸 제품 개발 철학 기저에는 “확장 가능하지 않은 일을 해라”가 깔려있는데요.
(대표님인 제이께서, YC를 만드신, 폴그레이엄을 엄청 좋아하시고, 그 분의 에세이를 사랑하시는데요. 그중에서도 “확장 가능하지 않은 일을 해라”는 번역까지 해주셨었죠.)
제가 폴그레이엄의 에세이를 읽고 느꼈던 인상적인 부분은,
고객의 행복을 위해서는 자동화, 스케일, 엔지니어링, 심미적 요소의 탁월함 따위가 중요하지 않고, (특히 초기 사용자에게)
고객의 욕구를 만족시키기 위해서 지금 해줄수 있는 것을 빨리 찾아서 해줘야 한다는 것이였습니다. (비록, 비효율적일지라도..)
고객에게 집착하려는 제품 개발문화가 있는 딜라이트룸에서는, “확장 가능하지 않은 일을 하라”는 멤버들에게 여러 울림을 주었었습니다.
그래서, 확장 가능하지 않은일은 할때,
- 고객의 문제를 훨씬 자세하고 깊게 파악할수 있고
- 그것을 기반으로 더 큰 고객 만족을 줄수 있고
- 그렇게 했을때, 오히려 더 확장 가능한 방법을 찾을수 있다
는 믿음을 가지고 일하고 있습니다.
그렇다면, “’확장 가능하지 않은 일’은 구체적으로 어떤거지?” 궁금할텐데요.
몇가지 구체적인 사례를 들어보도록 하겠습니다.
✅ Stripe 사례
문제: 사용자가 Stripe 설치후, 사용간 생기는 이슈를 알고 싶음
- 확장 가능한 일: 사용자가 웹사이트가서 알아서 설치하고, 사용성 이슈를 온라인으로 리포팅함
- 확장 가능하지 않은 일: Stripe을 한번 사용해본다고 하면, 바로 “컴퓨터 줘봐”하고 바로 서비스 설치해 주고 사용하는 것도 관찰
✅ Airbnb 사례
문제: Airbnb를 사용하는 고객(방을 빌려주는 사람)의 니즈와 욕구에 대한 의견을 받고 싶음
- 확장 가능한 일: 어느 나라의 고객이던 사용간 니즈를 온라인을 통해서 의견을 받음
- 확장 가능하지 않은 일: 뉴욕 고객의 니즈 및 욕구를 구체적으로 듣기 위해서 뉴욕으로 날아감
✅ 딜라이트룸 사례
문제: 알람이 울릴때, 핸드폰을 꺼서 일어나야함을 놓치는 이슈를 방지하고 싶음
- 확장 가능한 일: 양쪽 플랫폼에서 동일한 방법으로 핸드폰 끄는 방법을 방지함
- 확장 가능하지 않은일:
- Android 사용자: 시스템 기능을 이용해서 전원 끄는 화면을 켰을때, 그 위로 알라미 화면이 자꾸 뜨게 만들어 결국 전원을 못끄게 방해함
- iOS 사용자: iOS는 전원끄기 화면을 켰을때 방해 할수 없으므로, 전원 꺼짐을 알아차려서 폰을 켰을때 노티 폭탄 줍니다. 그때라도 알림 노티를 알려주는 것이죠. 한번 알람을 놓칠수 있지만 다음에 핸드폰을 끄려할때, 노티 폭탄에 대한 부담으로 함부로 끄기 어렵게 만드는것이죠.
(위 기능들은 당시 사용자들에게 상당한 만족감을 주었지만, 현재는 OS가 업데이트되고시스템 권한이 엄격해짐에 따라 해당 기능은 없어졌습니다. 다만 다른 방향으로 사용자 니즈를 풀어드리는 기능을 제공하고 있습니다)
사례들을 보면 “확장 가능한 일”은 상당히 이상적인 솔루션 보이지만, 실제로 문제에 직면했을때 사용자 문제를 바로 해결하기 어려운 경우가 종종 있습니다.
딜라이트룸의 사례에서도 만약 확장 가능성을 고려해서 크로스플랫폼을 사용하고 있었다면, 기존의 솔루션을 만드는 것은 거의 불가능했을것이라고 생각합니다.
아마도 집요하게 해당 이슈를 파고들지 못했을 것이고 “사용자가 핸드폰 끄는것은 어쩔수 없지”라고 생각하고 넘겼을것 입니다.
결국 확장가능하지 않더라도 고객의 문제를 각 플랫폼에서 풀어줄수 있는 방법만 있다면, 집요하게 파고들수 있도록 열어놨기 때문에 빠른 고객 문제 해결을 이뤄낼수 있었다고 생각합니다.
돌아보면, 악마는 디테일에 있었던 것이죠. 안될것 같은 고객의 니즈도 플랫폼별로 살짝 다른 솔루션을 통해 작아보이는 만족감까지 챙겨가면서요.
또 한가지 하고 싶은 이야기! 제작자들이 열심히 안씁니다.
개인적으로 제품 제작자가 본인 제품 많이 안써보는 것을 태만하다고 보는데요.
애착있는 제품 제작을 위해서는 이것은 필수라고 생각해요.
그런데 제가 느끼기에는 크로스플랫폼 제작자들 사이에서는 이런 사랑? 애착이, 요즘들어 잘 안느껴지긴 합니다.
특히, 요즘 크로스플랫폼의 양대산맥이 Flutter와 ReactNative인데요. 각각 구글, 메타가 제작자입니다.
그나마 메타는 페북과 인스타그램을 통해, ReactNative를 깊게 사용했었는데이런 솔선수범 덕분에 ReactNative를 사람들이 많이 채택했다고 생각해요.
“아, 페북, 인스타에서도 이정도 성능으로 쓸수 있다면 해볼만 하겠다”하고 써보는 것이죠.
다만, 최근에 메타의 큰 베팅이었던 쓰레드는 네이티브로 만들어졌다고 하는데요.
이부분에서 제작자의 사랑이 식은것 아닌가? 이런 생각이 들었습니다.
그보다 더 심각하다고 생각한건 구글입니다.
구글은 Flutter를 서포트 하고 있지만, 정작 구글의 중추가되는 서비스에서 사용하는 것을 본적이 없기 때문입니다.
(iOS 앱들을 까보면, Flutter를 쓰고 있는지 확인할수가 있는데요. 기본적인 Google Workspace 앱이랑, 유투브, 유투브 뮤직 들은 Flutter를 안쓰고 있는 것을 알수가 있었습니다.)
결국, 크로스플랫폼이란 개발 도구도 제작자들이 적극적으로 써보면서 개선을 시켜야하는데, 이런 식이면 믿음이 점점 떨어질수 밖에 없다고 생각이 들었습니다.
결론
정리해보면, 크로스플랫폼이 독이 될지, 약이 될지는 그 자체에 있다고 생각하지 않습니다.
더 중요한것은, ‘고객을 어떻게든 빠르게 만족시킬수 있어야함’을 아는 것이라고 생각합니다.
그런 측면에서, “확장 가능하지 않은 일을 하라”에세이를 꼭 읽어보시는 것을 강력 추천합니다.
그리고나서 현재 풀고 있는 문제들을 자세하게 이해하는 것이 중요하다고 볼수 있겠습니다.
우리가 풀고 있는 문제들은 어떤 도메인에 속하는지, 이미 풀어낸 문제들은 어떤 속성을 가지고 있는지 등등 말이죠. 특히, 개발팀을 이끌고 계신 팀장님들께서 이런 부분을 자세하게 숙지하고 있어야, 그에 맞는 적정기술을 쓸수 있다고 생각합니다.
그렇게 하면, 가끔 경영진에서 얘기하는 “크로스플랫폼을 쓰면, 훨씬 개발 속도 빨라지는것 아냐?”라는 질문에 동공지진 일어나지 않게 되겠죠.
이렇게 자세하게 이해하면, 각 팀이 속한 상황에서, 크로스플랫폼이 독인지, 아니면 약인지 알수있게 되겠죠.
약도 남용, 오용하면 안되는 것처럼 적절하게 써야하는 것이죠.
문제에 따라 다르긴 하겠지만, 개인적으로는 네이티브로 좁은 타겟과 뾰족한 문제로 시작해보는것도 방법이라고 생각합니다.
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다
🙌딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!
- 지금 바로 미디엄 팔로우하고 다음 아티클도 빠르게 만나보세요!
- 딜라이트룸 소식을 가장 빠르게! 딜라이트룸 링크드인 🔗
- 높은 평점으로 난리난 딜라이트룸 잡플래닛 ✅
- 딜라이트룸 일상을 엿볼 수 있는 인스타그램 📸
