[💬] 유니티 DOTS가 문제인 이유는 유니티 자체에 대한 안티패턴이기 때문

[익명(223.62)]

그냥 개인감상같은 뻘글이고 딱히 주제는 없음.

유니티가 상용 엔진 급은 지켜주면서 쓰기 쉽다는 평을 받게된데에는 메인 루프 관리를 하지 않고 각 개체별로 '스크립트' 를 붙여서 돌아갈수있게 한 철저한 객체위주의 구조로 설계된게 큰 덕을 봤다고 봄.

내부구조야 사용자들이 알빠노겠지만 만약 유니티 프로젝트를 열었을때 중간에 main() 코드 편집창이 있었다면 비전공자 비롯해 입문자 탈락률이 몇배는 더 높았을거다.


근데 유니티가 지금까지 십수년간 쌓은 접근방식과 설계를 내다버리고

'사실 씬 오브젝트 트리순회하면서 Monobehaviour 호출하는건 좆같은거였음. DOTS 이게 더 좋은듯' 을 사용자에게 떠멕이면 나올 수 있는 입장이 크게 두가진데
1. 와와 당신말이 맞다 사용자 UI 플로우 다뿌쇼 게임오브젝트 다뿌쇼

2. 근데 사실상 turbo-c시절 설계방식인데 굳이 유니티써서 기존방식에 맞추느라 몸비틀어야함? 딴 프레임웍이나 엔진도 좋은거 많은데?
문제는 유니티에서 제공하는 근본적인 구조자체가 DoD적 접근법과 완전 반대편이라는거임.

개인적인 입장으로 데이터지향개발이란거의 sw design에서의 위치는

잘쳐줬을때 패러다임급이고 현실적으로는 고전 절차지향을 되돌아보는 디자인 패턴정도 급이라고 보는데

그걸 극OOP구조인 툴에서 존나 카와이하게 지원하겠다고 욕심을 부리니까 '이 아키타입에 담긴 철학을 알겠어요?' 가 난무하면서 API로 채찍질하는 고답적인 하이-테크닉이 되어버림. 뭐 좀 이쁘게하겠다고 ECS중에서도 심플한 희소셋 구조가 아니라 욕심부리느라 뭐 해주는게 많은 아키타입구조를 박아놔서 이해해야하는 개념이 더욱 많아진건 덤이고.
개인적으로는 터보c, CDX, OGRE,  irrlicht 쓰던 틀딱시절 개발경험자라서 절차적 접근이나 데이터 오리엔티드 설계가 오히려 손에 익음. 옛날 순수c 시절엔 v테이블은 성능의 절대악이라면서 c++ 척화비세우거나, 가변길이 자료구조 퍼포먼스 ㅈ같다고 고정길이 깡배열만 쓰던사람들 널려있던 광기의 시절이었으니까 뭐...

내가 유니티 처음봤을때도 '와 기능 넣고빼고 하는거 이쁘게만들었네. 근데 이거 씬구석 외딴 오브젝트에 스크립트 처박혀있으면 실행을 어떻게 추적하지?' 라는 생각이 먼저 들었음.
하지만 내 개인적 취향은 취향이고, 유니티는 그런 철저한 객체구조를 가지고 어필해서 뜬거고, 많은 개발자들에게 그 구조는 장점으로 받아들여질거라고 생각함. 어디까지나 본인이 쓰기 좋은 구조가 가장 좋은 거라고 생각하니까.
이런 엔진에다가 DoD 개념을 지원하려면, 기존 엔진구조와 최대한 충돌이 적은 경량급 프레임웍을 추가해주거나 span<> 같은걸 메시 드로잉에 지원해주는 식으로 부담이 낮은 방식으로 접근을 시작해야 했음.
그대신 이 ㅂㅅ들은 엔진 내부 코어에 중2병건담마냥 '내가 생각한 최강의 ECS' 를 탑재한 다음에 그 API 연결선을 주렁주렁 만들기 시작했음. IL2CPP랑 burst 컴파일러 전부 내부개발하니까 엔진내부 c++단에서 존나 잘만들면 최강아님? 하는 생각이었을듯한데 그 결과가 pure냐 hybrid냐 또 api deprecated됐냐 등등

엔진 내부 변경의 여파를 최상단 디자인이 직격으로 쳐맞는 유선조종 프랑켄슈타인이 되었음.

마지막에 다 잘될거라고 좋게 봐줘도 이건 유니티의 지금까지의 철학과 너무 다른 접근방식인게 이질적임. 아예 유니티를 싹 갈아엎어서 OGRE마냥 메인루프랑 씬그래프부터 만들게할것도 아니라면 최소한 일관성 있는 접근법을 제공해야 하는데 대충 두 대륙 사이에 다리 놓아주고 '건너다닐 수는 있잖아' 라고 하는 것 같다.
과연 라이트한 개발자는 지금까지처럼 레고놀이를 하고, 고급개발자들은 현란하게 DOTS를 쓰는 두마리 토끼 잡기가 성공할까? 오히려 비 DOTS는 기능 업데이트에서 항상 소외되는 2등시민취급이라고 느끼고, DOTS개발자는 매번 오브젝트와 엔티티를 상호변환해야하는 똥개훈련에 시달리게 만드는게 아닐까?
오래된 생각이다.

[익명(124.57)]

밑에 DOTS 뭐가 좋냐고 물어본 사람인데, 이 글의 80퍼센트는 이해하지 못했지만 DOTS가 고인물용이라는건 확실히 이해함!

[아이스말차라떼(icedmatchalatte)]

인디 개발자가 dod하려면 뭐가 제일 나음?

[익명(221.146)]

사용이 쉬운걸 떠나서 구조적으로 그게 더 좋은 방향이니까 그렇게 바꿔나가는건 틀리지 않았다고 봄 그리고 리팩토링이란게 원래 기존거를 어느정도 부수면서 개량 하는 거라 어쩔 수 없음 예전의 유니티처럼 계속 쓰고 싶으면 그냥 구버전 쓰면 해결될 문제임 단지 앞으로 변화될 유니티를 쓰고 싶으면 새로운 거에 적응해야 되는거고 당연히 변화에 과도기가 없을수는 없는거고 난 닥히 부정적으로 보진 않음 그리고 개량하면서 기존것과 이질감 생기는건 언리얼도 마찬가지임

[익명(223.62)]

좋은 의견인데 내가 보기엔 1. 지금 유니티가 나아가려는 방향이 '미래의 지향점'으로서 그쪽이 말한 '변화'에 적절한가 에 대한 의문이 좀 있고 2. 현재 충돌나는 부분은 레거시 vs 차세대가 아니라 근간과 접붙이기 성격이 더 강하다고 느껴짐.

[익명(223.62)]

3. 그래서 자연적으로 현재 '불필요한(?) 마찰' 이 발생하는 부분 상당수가 '구 버전' 으로 버려질 것이 아니라 정책적 드랍이라 보기 때문에 '정 그럴거면 레거시' 같은 일이 생기는 것은 충분히 막을수 있었을것

[익명(14.42)]

사용이 쉬운걸 떠나서 라는부분도 말꼬리잡기가 아니라 정말 큰 문제임. 유니티의 강점을 포기하는것이기도하고, 사용이 쉽다 어렵다 자체도 구조적으로 좋다 나쁘다의 기준이 될 수 있는 요소임. 누가 실력이 있네 없네의 문제가아님

[익명(223.62)]

원래 유니티 에디터의 철학을 부정하지 않으면서 DOD의 수혜를 볼 수 있는 방법이 충분히 있었다고 보기 때문에 회사의 feature 과욕 때문에 없어도됐을 혼선이 생긴건 아닐까.

[익명(223.62)]

14.42 말 보고 떠오른거지만 본문에서 말한것처럼 개인적으로 데이터 오리엔티드는 'OOP hell의 뇌절을 견제하기 위해 옛것에서 다시 배우는 교훈' 이 크다고 생각하기 때문에 변혁을 요하는 새로운 지향점까지는 아니라고 생각함

[익명(14.42)]

좋은글이라 생각하는데 왜 비추가 2개일까?

[익명(milnahwes)]

이해 못 해서

[익명(14.42)]

내 윗댓글은 구조적으로 그게 더 좋은 방향이니 그렇게 바꿔나가는게 틀리지않다고 얘기하지만 그게 좋지 않은 방향인 이유가 더 많은거같다고 생각함 나한태 누가 그거 어때라고 물어보면 게임출시생각없고 게임만들기 놀이하고싶은거 아니면 건들지말라하고싶음

[익명(14.42)]

비단 DOTS뿐만아님. 다른 결정들도 공감하기 어려운 이유를 토대로 대공사 갈아엎고 제대로 완성되지도 못한 채 새로운 다른 방식으로 바뀌는경우가 허다함

[익명(223.62)]

패키지 관리방식 오락가락하다가 나중에 '저장소에 남기고 왔으니 원한다면 주도록 하지 json 편집해라( changelog에 한줄) ' 라는 해적왕식 해결법으로 끝난 몇개는 빼도박도 못하게 회사잘못 같다....

[익명(14.42)]

렌더파이프라인의 변화, UI시스템의 변화, DOTS, Visual Scripting 뭐 수많은 잡다한 있었다 없어졌다 바꿨다 내가 생각하는 이유는 농담으로 말하자면 근본이 없어서고 구조적으론 DogFooding의 부재. 유저들이 원하는 유니티의 강점 장점과 유니티가 추구하는 방향성이 다르기 때문에 유저들이 이해하기 어려운 이상한 결정들을 내놓는것같음.

[익명(14.42)]

시대의 흐름 남눈치보기 이런것들 때문에 시도하거나 없애거나 했던 결정들. DOTS 삽질도 그런 시도들중 하나라고 보임

[익명(223.62)]

bolt도 그렇고 probuilder도그렇고 사오려면 production ready 한걸 고르던가, 그렇게 만들던가 해야하는데 "활용은 성능에 맞게 계획적으로" 상태로 내던지는거 안좋은 버릇

[익명(14.42)]

ㅋㅋ 그런것들 진짜 딱 한문장으로 설명되는거잖음. 근본이 없어서다......

[익명(217.178)]

다 좋은데 막줄은 뭐냐 일베충이냐

[익명(121.155)]

비추 누루는 애들은 어 유니티 까네? 너 나쁜놈! 이러는 중인가.

[익명(219.251)]

"유니티에서 제공하는 근본적인 구조자체가 DoD적 접근법과 완전 반대편이라는거임" 에서 스크롤 내리고 비추 눌렀음. 유니티 Dots는 기존 GameObject 를 사용하는걸 상정하면서 개발했는데 3년전 지식 들고와서 pure, hybrid 어쩌구 GDC2022 에서 Authoring 시연하는것만 봐도 이런 개소리 안나오는데 그조차도 공부안하고 글 싼거임

[익명(223.33)]

authoring이 '변환' 이라는건 생각해보고 댓글 싸는거냐? 게자가 제입으로 GameObject와 같이 쓰는걸 상정했다면서 그게 oo랑 dod를 엮겠다는뜻이라는걸 이해못하고 1.0.0 릴리즈되고 api가 정교해졌으니까 이젠 아닌줄 아네 ㅋㅋㅋㅋ 원리를 이해못하고 작업하는 기술공으로만 시각이 굳으니 이런 소리가 나오지 ㅋㅋㅋ

[익명(110.11)]

그니까 Authoring 이 주요 기능으로 들어왔는데 pure 란 말을 왜 지금도 쓰냐고 저능아. 새끼야

[익명(110.11)]

그대신 이 ㅂㅅ들은 엔진 내부 코어에 중2병건담마냥 '내가 생각한 최강의 ECS' 를 탑재한 다음에 그 API 연결선을 주렁주렁 만들기 시작했음. IL2CPP랑 burst 컴파일러 전부 내부개발하니까 엔진내부 c++단에서 존나 잘만들면 최강아님? 하는 생각이었을듯한데 그 결과가 pure냐 hybrid냐 또 api deprecated됐냐 등등

[익명(110.11)]

API 연결선을 주렁주렁 만들어서 pure hybrid 생겼다는게 3년전 experiment 단계 얘기를 지금 써놓은거잖아 장애련아 그리고 지금 Authoring은 api 연결 때문에 쓰는게 아니라 유니티 철학인 wysiwyg를 에디터에서, 개발 방식에서 지원하려고 쓰는거지 병신아

[푸불(mygm1302)]

역시 프로 그래머는 달라 - dc App

[익명(121.149)]

기존에 유니티 사용하던 사용자가 새로 DOTS를 배우는 데에 필요한 Cost, 새로운 엔진을 통해서 비슷한 사양에서 더 나은 퍼포먼스를 보여주는데까지 필요한 Cost 어느 게 더 큼? DOTS를 배우는 게 지금은 더 나아보이는데... 길을 열어준 게 어디인가하는 생각이 들어 나는

[익명(223.33)]

개인입장에선 그래도 배우면 이득임

[익명(222.117)]

ECS는 좋은 방향이라고는 생각하는데 왜 OOP 중심으로 짜인 유니티에서 ECS를 억지로 제공하나 싶었긴 했음

[익명(211.226)]

성능이 수백배 차이나는데 알면 좋죠. 공부하기 싫으면 기존대로 만들면 되고..

[익명(119.207)]

이게 정답이지 코어는 변한거 하나도 없이 걍 옵션하나 더 생긴거고 모바일 시장 점유율 높은 유니티 생태계 특성상 로우엔드에서 조금이라도 더 퍼포먼스 뽑으려고 온몸비틀기 하는게 원래의 일상

[익명(119.207)]

언리얼이 하이엔드 지향이니 유니티는 dod 내세워서 반대로 가는거임 루멘 나나이트 이런거랑 완전히 대비되는 기술이라는게 안보임? 글고 구버전에 머물고 자시고가 아니라 메인 레이어는 변한게 없는데 뭔 dots 에 올인한다는식으로 호도하는지 모르겠음 글뽄새 보니까 기술너드 답정너 스타일이라 말씨름 하기 싫으니 비추박고 뒤로가기 하는거지

[익명(223.33)]

서로다른 두개가 섞이는게 어떻게 올인이냐 ㅋㅋㅋㅋ 하나를 버려야 올인이지 ㅋㅋㅋㅋㅋ 그리고 글로 말하는 사람하고 아무의견 말 안하고 비추튀 하는사람이 있으면 둘중에 누가 답정너임?

[익명(223.33)]

답정너로 비추박고 싶은데 쓸만한 합리적인 이유가 안나오니까 선x필승 하듯이 '답정너라서 아묻따 하는거' 로 포장하는거구만 ㅋㅋㅋ

[익명(223.33)]

stackoverflow 에서 dots 질답 보면 답변하는 dots 사용자들은 데이터적으로 사고방식을 바꿔라, 발상 전환하면 참 좋다고 엄청 푸쉬하는데 댓글에서 dots긁힌다고 신경질난 애들은 그런 개념 대전환이 아니라 그냥 좀 번거로운 기능이고 사용법 익히면 되는걸로 생각해서 틱틱대는것같다

[익명(222.235)]

그냥 선택지중하나인거지머

[익명(110.70)]

DOTS 좀 보고 이 글 다시보니까 ㅈㄴ 공감되네