[💬] ECS, DOTS.. 이게 맞는건가 싶네.. (잡설 장문 주의)

[익명(125.248)]

(일단 본인은 ECS, DOTS에 대해서는 그냥 소개 정도만 본 완전 문외한이야. 틀린 부분이 있다면 부디 화내지 말고 너그럽게 지적해주길 바라)

대충 들어보니까, 기존 OOP 방식에서 발생하는 데이터의 분산화로 인한 성능 저하를 개선하고자 데이터 지향적인 프로그래밍으로 성능을 대폭 끌어 올리겠다. 뭐 이런 거 같은데..

뭐 아무튼 취지도 알겠고 다 좋은데,

기기 상에서의 동작 성능 향상을 위해서 사람 쪽에서 기존의 프로그래밍 방식을 버리고 새로운 방식에 적응해야 한다는게.. 좀.. 

대개 프로그래밍 패러다임이나 디자인 패턴은 사람의 이해와 편의, 즉 사람의 효율성을 위해 도입되고 발전되어 왔잖아?

대표적으로 객체지향프로그래밍이 그랬고.

그런데 DOTS는 반대로 사람이 기계한테 맞춰주는 느낌이랄까? 그것도 오로지 성능 향상만을 위해서? (?)

물론 기존에도 최적화 기법 같은 것들은 있어 왔지. 성능이 필요한 부분은 어셈블리로 짠다던가. 등등..

하지만 그런 것들은 코드 특정 부분만 새로 짠다던가, 아니면 불필요나 오버헤드를 발생시키지 않도록 한다던가 하는 단편적인 기법이었고,

또한 일반적으로 그런 세세한 최적화 같은 것들은 하드웨어의 처리속도가 발전하면서 점점 무시해도 되는 부분들이 되어 가는 흐름인데,

(예전에 foreach 대신에 for문 쓰라고 하던 거라든지.. Linq를 죄악시(?) 하던 것.. 등등)

DOTS는 오히려 사람이 패러다임을 바꾸어 기계에게 맞추라는게 뭔가 거꾸로된 것 같아서 시대의 흐름을 역행하는 느낌이랄까...?

프로그래밍에도 AI가 도입되어 가는 요즘 시대의 흐름에서는,

오히려 기존의 문법을 공부해서 하나씩 짜는 코딩 방식조차도 AI가 대신하여 단순 노동에서 벗어나, 사람은 좀 더 고수준의 창의적인 부분에 에너지를 써야하는 시대가 오고 있는데,

기존 방식의 코드를 AI(기계)단에서 Data Oriented 방식으로 해석해서 재구성해줘도 모자랄 판에, 되려 사람이 방식을 기계에게 맞춰서 바꾸라고 하니.. 그 이유도 단지 성능이 딸리고 게임이 느려서라는 게 좀..

아무튼 뭐, DOTS의 필요성이나 취지에 대해서 비판하는 건 전혀 아니고 그냥 좀 아직 갈 길이 멀다 싶다는 잡설이었음..

요즘 ECS, DOTS 얘기가 많아지길래 나도 좀 해볼까 하고 기웃거려 보는데..

코딩 방식이야 뭐 바꾸려면 바꾸는 건데,

우리같은 1인이나 소규모 팀인 인디 개발자들은 특히나 외부 에셋이나 라이브러리 의존도가 높은데 이것들이 다 호환될 정도로 DOTS가 일반화되기 전까지는 뭐 도입하고 싶어도 할 수가 없는 강제 홀드 상태 같음..

나중에 때가 되면 자연스레(?) 넘어가게 되겠지..

작업하다가 잠깐 잡설한다는데 너무 길어졌네;;

아무튼 다들 화이팅해~!! 수고!!

[ㅇㅇ 2(61.85)]

대규모 데이터 처리를 위한 게임 아니면 클라단에선 아직 시기상조같긴해

[ㅇㅇ 3(218.39)]

개인적으론 인디 개발하면서 성능 최적화에 신경쓸 이유나 여유가 없는듯 렌더링도 아니고 로직 부분이면 더더욱

[글쓴 ㅇㅇ(125.248)]

동감. 초보 수준의 어이 없는 설계를 하거나 한 게 아니라면, 최적화는 게임 완성한 후에 해도 괜찮다고 봄. 완성도 못하는 경우가 태반이니.. 일단 속도감 있게 완성부터 ㄱㄱ

[익명(116.127)]

유저가 완전히 새로운 문법을 배워서 다시 코딩하는게 아니라 기존의 유니티 문법에서 살짝만 수정하는 식으로 그 효과를 얻을 수 있어야 하는데 ecs와 dots는 유니티의 개발 모토였던 개발의 민주화에서 한참 벗어나 있는것 같음

[ㅇㅇ 4(222.117)]

데이터 지향이라고 기계에 맞춰서 하는 느낌은 아니고 객체지향이 아닌 좀 다른 방식의 프로그래밍 방식이라고 이해하면 좋음. 데이터 지향이 객체지향과는 방식이 꽤 달라서 객체지향 위주로 했다면 불편하게 느껴질 수 밖에 없음 그치만 인디에서는 아직 미성숙하기에 ECS, DOTS 안 건드는 게 좋다는 건 나도 동의, DOTS가 어느정도 발전하더라도 데이터 지향에 대해 이해하지 못했으면 기존 OOP 지식을 버려서까지 할 필요는 없다고 생각함

[ㅇㅇ 4(222.117)]

보통 사람들이 ECS 쓰는 이유가 최적화라고 생각하는데, 객체지향, 절차지향, 함수형, 선언형 전부 현업에서 쓰고 마스터해본 경험으로는 버그를 줄이고 유지보수가 쉬운 깔끔한 아키텍처 구조 하나만 보고 가더라도 의미 있다고 생각 함. 근데 객체지향도 러닝커브가 꽤 있듯이 데이터지향도 러닝커브 만만치 않아서 프로그래밍 어느정도 통달한 거 아니면 굳이

[ᆼᆼ(104.28)]

아키텍처가 깔끔하다~ 유지보수가 쉬워진다~ 이러는 애들 하나같이 허수임. 최적화 때문에 쓰는거 맞고 그 이유가 아닌 애들은 걍 다 허수라고 보면 됨

[ㅇㅇ 4(222.117)]

허수라기엔 이미 구를대로 굴러서 뭐.. 타 패러다임들 충분히 써보고 말하는거면 인정해드림

[익명(marokim)]

겜개발 꿈 중 하나가 시뮬겜이라 기대는 하는중 다른 사람들이 총대매고 생태계 어느정도 구성되면 승차하려고

[ㅇㅇ 5(118.235)]

무조건 쓰라는게 아니라 프로젝트에 따라 필요한 경우 쓰라는건데 무지한것들이 말만 많누ㅋㅋㅋ

[소닉쫄따구테일즈(dcz3xv7zgu14)]

객체지향으로 짜면 복잡한게 특정 장르는 ecs가 편하긴함. 구조확장에 확실히 편함. 꼭 성능땜에 쓰는건아님

[ㅇㅇ 6(61.255)]

성능때문에 쓰는거 아니라는 애들특징: ECS로 멀티스레드 이점 못얻게한다 하면 ECS 애초에 거들떠도 안봄. 꼭 전후관계를 착각하는 애들이 있어요.

[소닉쫄따구테일즈(dcz3xv7zgu14)]

미안하지만 애초부터 멀티스레딩때문에 쓰는게 아니라 애초부터 멀티플레이 결정론적 시뮬에 쓰는거라 쓰고싶어도 멀티스레딩은 제한적인거 알고씀. 난 빼줘

[ㅇㅇ 7(180.230)]

뭐랄까 객체지향으로 만들어도 ECS로 바꿔주는 AI같은게 있었으면 좋겠네

[ㅇㅇ 8(110.12)]

근데 막상 또 써보면 쓸만함. ECS안에서도 어차피 모노비헤이비어랑 왔다갔다 해야하는게 필수인 경우도 있고. 특히 비슷한 성질을 가진 오브젝트 여러개를 한꺼번에 관리하는 부분에 있어서는 ECS가 압도적으로 편리해서 좋음

[ㅇㅇ 8(110.12)]

그니까 걍 기계가 사람에게 맞춰야 한다니 뭐니 그런거에 연연하기 보단 각 프로그래밍 방식의 장점만 잘 뽕뽑아서 모노랑 ECS섞어쓰는게 최적이라고 봄