[📚정보] UniRx를 배워야할까?(+UniRx 개발자 블로그 기사 인용)

[익명(203.253)]

뭔가 갤 보고 있으면 'UniRx를 공부해야하나?' 생각하는 사람들과
무지성 UniRX 신봉자들이 꽤 있는거 같아서 제대로 정보를 주기 위해 글씀.
결론만 볼 사람은 맨 아래 결론만 보셈.

https://neuecc.medium.com/r3-a-new-modern-reimplementation-of-reactive-extensions-for-c-cf29abcc5826
UniRX, UniTask, R3 개발자인 카와이 요시후미의 블로그 기사 인용

참고로 요시후미는 Cysharp.Inc의 대표로 사이게임즈 자회사고,
이 회사는 게임 개발용 오픈 소스 C# 라이브러리 전문 개발사로 C#을 개발 언어의 표준으로 만드는게 목표임.
C#에 미친 사람이라고 보면 됨.

───

"Rx를 사용하고 있습니까? .NET이나 Unity뿐만 아니라 Java, Swift, Kotlin에서도 “아니요”라고 대답하는 사람들의 수가 늘어나고 있습니다. 그 존재감이 확연히 줄어들고 있습니다. 왜? 대답은 간단합니다, async/await의 출현입니다."

"async/await가 널리 채택되면서 비동기 처리만을 위한 Rx의 필요성이 줄어들고 채택률도 감소했습니다. Unity의 Rx 표준인 UniRx의 개발자로서 저는 게임 엔진(Unity)에 맞는 async/await 런타임의 필요성을 빠르게 인식하고 Unity에서 필요한 조건(C# 7.0)이 충족되자마자 UniTask를 개발했습니다."

이게 무슨 소리냐? Rx는 비동기 처리와 이벤트 기반 LINQ, 두 가지 부분에서 강점이 있었는데, async/await이 출현하면서 비동기 처리 부분에서의 강점을 잃어버리자 사람들이 바로 Rx를 버렸다는 얘기임.

이상하지? 같은 비동기 처리의 개념이면 쓰던 Rx를 계속 쓰지 왜 Rx를 버려버릴까?

답은 간단하다.

좋다고 믿은게 쓰다보니까 불편하기 때문임.

스트림이란 개념이 디버깅을 힘들게 만들고 코드의 가독성을 떨어뜨리거든.
특히 프로젝트 규모가 크면 클수록 Rx는 기하급수적으로 디버깅을 힘들게 만듬.
스트림들이 어떻게 엮여있는지 알기 힘드니까.
개발 기간의 많은 비율을 디버깅 하는데 보내는데 그걸 힘들게 만든다? 엄청난 디메리트지.

그나마 비동기 처리 쪽은 대안이 없으니까 쓰고 있었는데 대안이 나왔다? 계속 쓰고 있을 이유가 없음.

이벤트 기반 LINQ,쪽으로는 어때?
비동기 처리 부분을 뺀 Rx는 프레임워크 상에서 쓰일 부분이 극히 적음.

구글에 UniRx나 Rx를 검색하면 다양한 소개 블로그들이 나오고 이것저것 Before, After 예시 코드를 보여주면서 "Rx는 이렇게 훌륭하다!"라고 얘기함.

문제는 걔네가 작성한 Before 예시 코드를 보면 로직이 매우 단순하거나 저런 식으로 코드를 작성하면 안된다의 표본적인 코드라는거임.

"HP가 0이 될 때를 감시하다가 0이 되면 OnDead 함수를 실행해요"
=> HP에 event를 등록해두고 HP 계산 중에 0이 됐을 때 통보를 받지 누가 멍청하게 HP가 0인지 아닌지를 계속 감시하고 있음?

"Buffer를 이용해서 더블 클릭을 쉽게 만들 수 있어요!"
=> 실시간으로 더블 클릭 간격이나 클릭 횟수를 바꾸고 싶으면 그때마다 스트림을 새로 구성해야하잖아? 이게 좋은거 맞냐?

사실상 검색으로 나오는 정보들은 그냥 진짜 뭐가 좋은지 모르는 Rx 좋음 호소인들의 호소라고 봐야한다.
다만 말했듯이 쓰일 부분이 아예 없는게 아니다, 적은거지.

단독으로 동작하는 경우가 많은 UI 부분에선 분명 유용하게 활용할 곳이 많음.

"- Use UniRx as well, if your game architecture relies heavily on event handling. I'm working on a mobile multiplayer RPG with real-time combat. We use ECS for the core gameplay loop, but everything else (UI, resource management, meta) is built using traditional event-based approach. So for gameplay events we have special IComponentData and separate systems to handle those, but for non-gameplay stuff I'd still use IObservable as it's the interface to describe push-based streams (as opposed to pull-based async IEnumerable)"

멀티플레이어 RPG 게임을 만드는 한 개발자는 게임 플레이 부분은 전통적인 이벤트 기반 구조로 작성되어 있어 안쓰지만, 게임 플레이 외적인 부분에선 사용한다고 함.

문제는 아주 한정된 곳에 부분적으로 사용하려고 Rx 프레임워크를 프로젝트에 얹어야하냐는거임.
부분적으로 활용하기 위해 Rx 프레임워크를 프로젝트에 얹음으로써 생길 수 있는 여러 문제를 감당할 것인가?
많은 개발자들이 여기에 'No'라고 답했고 그래서 버려진 것임.

요시후미는 기사에 아직 Kotlin이랑 Swift에서 Rx가 활발히 쓰인다고 얘기하지만, 찾아보니까 저쪽도 분위기는 같더라.

여기도 디버깅과 가독성 문제 때문에 async/await으로 넘어갈려고하고, UI 쪽에는 유용하니까 그 부분에서 한정해서 사용하려고 함.

Kotlin과 Swift는 자체적으로 Rx 프레임워크를 가지고 있는데다 UI쪽과 호환성이 좋기 때문에 개발자들이 굳이 꼭 버려야할 이유는 없음.

하지만 유니티는 아니지.

그럼 요시후미는 새로운 C# Rx 프레임워크인 R3를 왜 만들었냐?

"그렇다면 Rx의 가치는 어디에 있을까요? 저는 'LINQ와 LINQ to Events를 이용한 메모리 내 메세지를 처리'라는 근본으로 돌아간다고 믿습니다."

"게임 엔진(Unity)에 사용되는 UniRx 개발자로서 복잡하고 Event가 많은 게임 어플리케이션에도 저는 Rx가 매우 유익하다고 생각합니다. 관찰자(Observer) 패턴과 Event의 중요성은 부인할 수 없으며, "더 나은 Event"로서의 Rx의 역할 또는 궁극적인 관찰자 패턴은 변하지 않습니다.

"저는 Rx의 가치를 되살리고 싶었습니다. 그리고 Rx를 재건하는건 저만이 할 수 있다고 믿었습니다."

// Rx가 자기 커리어에 많은 영향을 끼쳐서 이런 말을 하는거임

요약하면 "Rx 존나 좋은데 왜 안쓰냐? 내가 새로 만들었으니 써줘."임
참 트루 Rx 좋음 호소인이라고 할 수 있음.

───

결론
UniRx 배워야하나? 진지하게 고민할 필요 전혀 없음.
배우고 싶으면 배워서 써, 편한 사람한테는 분명 편하겠지.
하지만 Rx가 혁신도 아니고, 미래를 지배할 패러다임도 아니며, 신봉할 이유도 없다.
써보니까 별로 같아? 쓰지마. 현재로썬 그저 가라앉고 있는 배일 뿐임.

"이 좋은걸 왜 안쓰지? 왜 이렇게 정보가 없어? 역시 한국 개발자 새끼들은 베낄줄만 알지 실력이 없어"

좋은걸 왜 안쓰겠냐? 안좋으니까 안쓰는거임.
기술을 옛날 정보로 판단하지말고 최근 정보로 판단해라.

아 그리고 UniRx를 쓰면 퍼포먼스에 좋다느니 이상한 소리를 하는 애들이 있는데,

Observing 방식이 절때 퍼포먼스에 좋을 수가 없다. 물론 제대로 사용하면 퍼포먼스가 더 나빠질 것도 크게 없음.
평소에 코드를 개떡같이 짰으면, Rx에 맞춰짜면서 코드가 정리가 되니까 상대적으로 퍼포먼스가 올라갈 순 있음.

[ㅇㅇ 1(61.75)]

unirx 쓰면 멀티쓰레드 되는 기능들이 있어서 퍼포먼스는 나아지는거 아니야? 잘 모름

[ㅇㅇ 2(121.130)]

super 이끌림

[태보미(taebomi)]

나도 공감해서 unirx는 사용안하고 unitask만 사용중.
저분 정말 무시무시한 분이더라.
unitask 정보 찾아보느라 본진 블로그도 가봤는데
나도 커서 저런 사람이 되고 싶어!
https://neue.cc/

[불타는키보드(1bnmaker)]

뭔가뭔가 애매해보여서 소규모로만 사용중인데 이 글을 읽으니까 명확해지네요 ㄳㄳ

[호시타(posita)]

그래도 간단하게 사용하기엔 좋다고 생각함 너무 편해

[ㅇㅇ 3(125.132)]

내말이 이거임 UniRX로 호출하는 함수에 브레이크포인트 한번만 찍어보고 콜스택 보면 존~나긴게나오는데 디버깅이야 뭐 Rx고수가되면 할수있다 치고 이게 퍼포먼스가 좋을거다라는 생각은 할수가 없는데 말이지

[익명(shorten5221)]

요약: 1. UniRx를 배워야 할 필요는 없음. 2. Rx는 현재로서는 혁신적이거나 미래를 지배할 패러다임은 아님. 3. Rx를 사용하는 경우, 개발자의 편의와 유용성을 우선 고려해야 함. 4. Rx의 퍼포먼스 우월성 주장은 사실이 아님. 5. UI 등 특정 부분에서 Rx를 활용하는 것은 적합할 수 있음. 6. 최신 정보를 기반으로 기술을 판단하고 결정하는 것이 중요함.

[익명(shorten5221)]

난 unitask는 쓰고있음

[ㅇㅇ 4(39.123)]

throttle이나 merge 사용하는 부분은 어떻게 생각함?? 나는 이거를 대체할수 있으면 하고싶은데 아직 잘 모르겠음...

[글쓴 ㅇㅇ(203.253)]

니가 그걸 왜 꼭 필요로 하는지 모르니까 대답해줄 수 있는 부분이 아님. 하지만 보통의 경우 UniTask로 전환이 가능함. 쓰지 말라는 얘기가 아니기 때문에 편하면 그대로 써. 난 좋은데 굳이 갖다버릴려고 할 필요 없음.

[ㅇㅇ 4(39.123)]

_subscription = _targetProvider.OnTargetChanged .Merge(_targetProvider.OnTargetStateChanged) .Merge(_goalSelector.OnGoalChanged) .Merge(_onExecuteDone) .Throttle(TimeSpan.FromSeconds(0.2f)) .Subscribe(OnNext); 이런식으로 쓰는 부분이 하나 있음. 이벤트로 표현하자면 표현가능한 3가지의 이벤트가 있고 이 세가지 신호를 merge하고 throttle해서 받고 있음.