[💬] 프로그래밍 TIP

[o o(27.119)]

간만에 갤에 왔다가 분탕질 한번 해보고

갤에 이런 저런글 읽다가 갤러들이 잘못이해하고 있는 것들이

있는것 같아 한번 얘기해본다.

클래스 설계 잘하기

게임개발이던 다른 소프트웨어 개발이던 처음에 클래스설계를 하는 것은 불가능하다.

결국 나중에는 바뀌게 되어 있다.

이건 개발방법론 책 아무거나 읽어봐도 항상 나오는 얘기고 실제로 몸으로 체험해봐도 그래.

왜냐면 초기에는 정보가 절대적으로 부족하거나 잘못된 정보(즉 나중에 바뀔수 있는 정보)를 많이 가지고 있

기 때문이지.

초보들히 흔히 하는 실수가 초반에 완벽한 클래스 설계를 하려고 한다는 거야.

초보가 되었든 고수가 되었든 이거는 절대로 불가능해. 

단지 남들이 빠르게 설계하는 경우는 이전에 비슷한 구조를 여러번 경험해 봤을뿐이지

설계능력이 특별한 것은 아니야.

결국 계속해서 리팩토링하는 수밖에 없어. 

그러니 이 리팩토링과정을 빠르게 반복할수 있는 기술을 익히는게 설계를 잘하는 길이다.

싱글톤 사용에 대하여

싱글톤은 단순히 글로벌 변수야.  OOP 에서  class A의 인스턴스를 전역적으로 하나만 

두게 하는 경우를 OOP 용어로 정의해서 말하는 거고. 

C#/Java에서 이 인스턴스를 만들때 보통 new 로 생성해서 만들면 이건 힙에 위치된다.

C++ 같은 경우 그냥 글로벌 변수로 선언하면  데이터 영역에 위치되고. (물론 new로 생성하면 

역시 힙에 위치된다)

그리고 static class 는 문법상 new 같은 키워드로 인스턴스를 만들수 없고 

그 자체로 데이터 영역에 단 한개의 인스턴스가 자동으로 생긴다.

결론적으로 그냥 글로벌 변수 일뿐이다.

그런데 이걸 피한다고?

첫번째 댓글 싱글톤이 더 지저분해 보인다는 것은 일리가 있긴함. 가능한 전역변수(싱글톤)를 줄이면 좋긴하지만 꼭 필요한 걸 안쓰려고 하면

그에 대한 어마어마한 비용이 들어간다.

두번째 댓글, 상속구조설계와 싱글톤은 전혀 관련이 없는 얘기다.

맨 마지막 댓글에서 잘못된게 멀티쓰레드하고 싱글톤만 연관있다기 보다 모든 데이터 (데이터 영역 + 힙에 존재하는) 가 사실 쓰레드간 경쟁관계에 

있기 때문에 특별히 싱글톤만의 문제는 아니다.  

단 지역변수 그 자체 (지역변수가 참조하는 힙에 존재하는 오브젝트가 아니라, 지역변수 레퍼런스 그 자체) 는 문제가 없는게 쓰레드는 각 쓰레드당

스택을 따로 가지고 있기 때문에 지역 변수는 문제가 없다 (지역변수그자체는 스택에 위치됨)

그래서 어떻게 하라고? 쓰라는 얘기야 말라는 얘기야?

불필요하게 사용되는 건 피해야 하지만 필요한 만큼 자유롭게 사용해야한다.

왜냐고?

사실 글로별 변수를 사용안하기 위해 대두된 패러다임이 함수형언어다. 이거 게임에 못쓴다.

써봤자 대부분 간단한 아케이드 수준이고 사실 상업용으로 불가능해.

왜? 전역변수(싱글톤) 를 피하기 위해 복사가 어마어마 하게 일어나서 도대체 성능이 안나오거든.

DirectX 가 왜 direct 라는 이름이 붙은건지 알고 있음? 원래 윈도우 GUI 시스템은 GDI  라는 시스템이야.

아주 유연하고, 소위 싱글톤 사용을 극도로 줄인 구조지. 

하지만 유연하게 설계되다 보니 복사가 너무 많이 일어나서 성능이 당췌 안나와.

그래서 어떻게 ? direct로 비디오 버퍼에 바로 쓰고 읽게 만든거지. 

GDI는 비디오 버퍼에 바로접근못하고 중간에 여러단계로 프레임데이터가 복사되.

소위 싱글톤을 안쓴거지.

그래서 DirectX 야.

성능 문제 그다음으로 글로벌 변수(싱글톤)을 안쓰기 위해 필요한 지식들이 어마어마해.

무슨 말도 안되는 소리냐 하겠지만 내말이 맞아. 진입장벽이 니들이 생각하는 것보다 훨씬 높아. 

빨리 배워서 빨리 써먹어야 하는데 언어하나 붙잡고 익숙해지는데 몇년씩 걸리면 안되지 ~

그래서 결론은 불필요한 싱글톤만 아니면 마음 대로써. 아니 꼭 써야해.

그게 함수형언어와 다른 imperative language(C/C++, java, C#, ...) 의 장점이자 단점인데 

이 단점을 보완하고자 사용을 피한다면 그 대가로 들여야하는 노력이 정말 어마어마 하다.

상속을 피해라?

"상속대신 delegation 하도록 설계를 하자" 뭐 이런 얘기가 많아.

물론 구조상 상속이 아니라 delegation 이 맞는 구조가 있다.

이런 경우에도 상속을 쓰자는 게 아니야 ~

모델링을 할때 클래스간에 공유되는 속성을 공통 속성으로 모델링를 할것인가하는 문제로 

만약 그렇다면 상속을 쓰는게 맞아.

예로,  사람도 age 라는 나이라는 속성이 있고 개(Dog)도 age라는 속성이 존재하는데 이 두개의 공통된 속성

이 있다고 상속을 해야 하느냐? 이건 모델링의 문제로 이걸 공통의 속성으로 볼것이냐 아니냐로 업무 도메인마다

틀리다. 하지만 그 업무 도메인에서 이게 공통의 속성이다 라고 모델링이 되면 

꼭 상속을 써야함.

꼭 이해해야 할게 상속을 결정하는 기준이 기능을 물려받기 때문에 상속하는게 아니야.

공통 속성이 있느냐 없느냐로 결정해야 함.

메소드를 어느 계층에 두고 상속을 받을지 오버라이드를 할지는 그 다음이야.

약간 번외로 유니티 DOT 은 데이터 드리븐 방식이고 구조 보다는 성능을 극도로 추구하는 방식이야. 

내가봤을때는 C/C++ 놔두고 성능올린다고 기계어나 어셈블리로 짜는 격이다.

물론 데이터 드리븐 방식이 구글에서도 크롬만들때 사용했던 방식이고 나름의 이유가 존재했겠지만 

그들은 충분한 인력이 있잖아.

최소한 나나 니들이 사용할 방법은 아니야.  구조를 잘 잡는게 우선이지.

그 밖에 좀더 길게 쓰고 싶은데 잠깐 나갔다 올일이 생겨서 

다음에 쓰도록 하겠다.

비난 글은 좋은데 댓글에 욕은 하지말자. 진짜로 찾아가서 죽여버린다.

[익명(222.117)]

2번째 댓글 썻던 사람인데 싱글톤 글 본문에서 잘짠 사람들 상속 ㅈㄹ떤다고해서 저렇게 쓴거임. 아무리 그래도 맥락에 맞춰서 읽어야지.

[익명(222.117)]

변화하는 스펙에 맞춰서 리팩토링은 꾸준히 해야한다 - 동의 싱글톤은 필요한 상황에서는 써야한다 - 동의 상속을 피해라 - 정확히는 composition over inheritance 라고 OOP 오래 써본 사람들은 다 동감하는 얘기임 OOP 상속 남발해서 복잡도 제대로 제어한 코드를 본적이 없음. 상속의 가장 큰 문제는 부모와 자식 클래스의 커플링이 너무 강함. 요거때문에 코드들을 더 이상 수정할 수 없고 기능 추가할 수 없는 레거시화되는 꼴을 너무 많이 봤음. 상속은 최소화해서 필요한 곳에만 써야함.

[익명(222.117)]

유니티 DOT는 ECS에 기반해있고 ECS는 정확히는 Data-Oriented Progamming에 기반해있음(DOT의 DO도 Data-Oriented임). ECS는 성능 향상을 메모리 캐시 적중률을 높여서 하는 방식임. CPU가 메모리 주소를 역참조할 때 역참조할 데이터만 가져오는게 아니라 데이터 뭉터리를 가져와서 캐시에 저장하는데, 이후 역참조할 때 캐시에 있는 주소면 램까지 갈 필요 없이 바로 캐시에서 가져오는거임. 현대 CPU의 병목은 클록 자체보다는 메모리 조회가 생각보다 많이 먹는데, 이걸 없앰으로서 코드에 따라서는 C/C++로 변경하는 것보다 더 빨라질 수도 있음. 구조적으로는 상속을 거의 포기하고 컴포지션 중시하는 구조라서 구조를 못 챙기는게 아님. OOP보다는 명령형에 가까울 뿐임.

[익명(222.117)]

함수형은 정확히는 상태 변화를 제어하려고 만든거임. 아무런 곳에서나 조회하고 수정할 수 있는 글로벌 변수는 언제 변할지 모르니 한 코드에서 만든 버그가 다른 코드에도 영향끼쳐서 디버깅이 어려워지는 상황을 방지하려고 만듬. 그래서 순수 함수형에서는 이 니즈를 어떻게 처리하냐, 싱글톤들을 메인 함수 쪽에서 로컬 변수로 가지고 있고 그걸 다른 함수에 넘기고 넘겨서 조회를 하는거임. 이때 복사하는 건 싱글톤 데이터 자체가 아니라 싱글톤 레퍼런스라서 그리 무거운 작업은 아님. 함수형을 게임 클라이언트에 쓰기 어려운 이유는 일반 유저 데이터의 필드를 수정하려면 불변성을 지키기 위해서 새 유저 데이터 만들어서 모든 필드안에 있는 값/레퍼런스를 복사하고 수정할 필드만 다르게 생성해야 함.

[익명(222.117)]

당연히 게임에서는 유저 데이터의 수정이 빈번하니까 이게 레퍼런스나 숫자 값이라해도 성능이 부담 됨. 그래서 못 쓰는거지 싱글톤 때문에 못 쓰는 건 아님. 함수형은 대신 서버에는 잘 쓸 수 있음. 서버같은 경우 쓰루풋이 꽤 중요한데 함수형의 불변성 성질이 멀티쓰레딩하기 좋게 만들어줌. 함수형으로 만들어진 게임 서버 아주 간혹 볼 수 있음.

[o o(27.119)]

물론 아는 얘기일테지만 composition , delegation도 사실 논리적으로는 상속이야. DB 모델링에서도 1:1 이든, 1:N 이든 FK 로 다른 테이블 참조하는 것을 inhertance 라고 함. composition하고 같아. 물론 composition over inheritance 에서 composition은 문법적으로 as-is 관계를 피해서 불필요한 상속관계를 없애자는 거고. 그부분은 니말에 동감해. 그리고 글에 썻듣이 모델링에 포함되는 경우에는 상속을 쓰자고 했지. 모델링이라느 말은 있는 그대로 설계하는 게 아니고 원하는 걸 만들기 위해 꼭 필요한 관계를 정의하는 것이고. 즉 니말하고 같아.

[o o(27.119)]

함수형에 대해서는 좀 많이 잘못알고 있는거 같은데, 서버에서 쓰루풋이 충분히 잘나오게 만든건 니말대로 드물지만 있다. 근데 글에 쓴것처럼 그정도 수준까지 그걸 공부하려면 얼마나 걸리는지 암? 그 사례들 잘봐봐. 거의다 그 언어 만든사람이거나 컴파일러 만든사람들 데려다가 구글이나 아마존에서 만든거야. 일반적인 개발자가 그렇게 만드는건 거의 불가능해. 상당히 투자를 해야해.

[o o(27.119)]

그리고 클라이언트에서 못쓰는 이유도 틀린게 쓰루풋은 어떻게 해서 C++수준이상으로 만들수 있지만 응답성은 현저히 떨어져. 왜? 복사가 너무 많아서 가비지가 어마어마하게 커져. 그리고 대부분 stop the world GC를 쓰기 때문에 프레임 드랍이 너무 심하거든. C#도 그렇지만 C#하고 비교할만한 수준이 아니야.

[o o(27.119)]

그리고 순수함수형은 상태변화를 제어하려고 만든게 아니고 아예 상태 변화라는 개념자체가 없다. 변수, 즉 변하는 개념자체가 없어. 그래서 항상 새로운 값을 새로 만들어. 그럼 메모리를 어떻게 수정하냐고? 언어적으로 메모리를 수정하는 방법자체가 없어. 단지 런타임 라이브러리(IO Monad) 가 IO 타입의 표현식대로 런타임에 실행하는 거지. 본인도 본인 잘 모르고 있다는걸 알면서도 너무 아는척 쓴거 아님?

[o o(27.119)]

실제로 해보고서도 충분히 만들수 있다는 얘기는 절대로 못해 ~ 내가 볼때 니말은 그냥 지기 싫어서 그냥 아는척 우기는 것 뿐이야. 그렇게 잘알고 있으면 모나드가 뭔지 검색해서라도 댓글 달아봐. 내가 반박해줄게~. 그렇게 잘아는듯 말하면서 설마 모나드 정도는 이해하고 있지 않음?

[익명(222.117)]

delegation은 composition에서 어떻게하면 인터페이스 노출을 할 수 있을까를 고민해서 만들어진 것이라 보통 개발자들은 좀 더 여러 패러다임에 적용되는 compostion이라는 단어를 씀. 의견은 비슷하지만 좀 더 자세하게 정의하려고 컴포지션이라는 단어를 가져온거임. 함수형 얘기는 당연히 함수형 써라 그런 얘기가 절대 아니고 추천도 안해. 싱글톤 복사 때문에 못 쓴다라는 늬앙스로 보여서 왜 못 쓰는지 다시 정리한거야. GC 발생 때문에도 못 쓰는 거는 동의해 성능 이슈 말고도 그런 이유가 있는것도 맞아. 순수 함수 언어에서도 상태라는 개념은 논리적으로는 존재하긴 해 결국 다 모나드로 래핑하는 건 맞는데 런타임에는 결국 그 람다들을 실행하면서 메모리가 변화해.

[익명(222.117)]

하스켈에서도 성능 타협을 위해서 순수 함수형을 깨는 도구들이 몇개 있어서 언어적으로 불가능하지는 않아. 나 이미 함수형을 현업에서 많이 써보고 얘기하는거라 이미 다 아는 것들이야 모나드를 알고 있다면 상태 모나드(State Monad)라는 개념은 아나?

[o o(27.119)]

알지 . 계속해봐~

[o o(27.119)]

혹시 State Monad가 메모리 변경할때 사용한다는 그런말은 아니지? 아니길 바래~

[익명(222.117)]

당연히 그런 얘기겠어? 상태란 개념이 충분히 존재한다는 의미지 개발할때도 (모나드로 추상화된)상태가 어떻게 변화하나 신경쓰면서 개발해

[o o(27.119)]

그리고 하스켈에서 순수함수형을 깬다는게 unsafe 말하는거라면 실망이야. 걔는 그냥 라이브러리 잖아. 예를 들어 C언어는 메모리 연산을 추상화하고 CPU연산을 추상화해서 메모리에 직접 값을 읽고 쓸수 있지만 키보드나 마우스로 부터 값을 읽거나 쓸수 없어. IO를 추상화하지 않아서 C언어는 키보드나 마우스라는 개념을 몰라. 하다못해 화면에 "hello" 라는 글자도 출력못해. 단지 표준라이브러리나 라이브러리를 작성해서 추가적으로 하는거지~~ OK?

[o o(27.119)]

State Monad라는것 때문에 상태가 존재한다니 ~~ 변수에서 읽어오고 쓰고 하는 것처럼 쉽게 다룰수 있게 만든거지 실제로는 완전히 purity한 연산이거든? 아놔 진짜 알고 얘기하는거 맞음?

[o o(27.119)]

do { x <- get; put (x-1); get } 이게 진짜로 x를 변경한다고 생각함? 재귀적으로 새로운 x가 생기고 그냥 보통의 아주 평번함 모나드야. 모나드 컨텍스트에서 디테일한 부분을 숨겨줄 뿐이지. 완전 purity 해.

[o o(27.119)]

그만하자. 시간낭비다.

[익명(222.117)]

아니 언제 순수 함수형이 순수하지 않다고 한거야 내가? 상태가 논리적인 개념으로는 존재한다는 의미지. 상태 변화라는 단어가 성립 안하는게 아니야 결국 모나드 위에서는 말이 돼. 잘 알고 있잖아. 함수형으로 서버 짤 때 유저 상태 변화를 정의하고 실행한다고. 상태 변화라는 단어를 자꾸 변수 값 수정으로만 받아들이면 곤란해. 순수함수형을 깨는 기능에 대해서는 하스켈에서 메모리 변화가 아예 불가능하다라는 의미로 받아들었기 때문에 표준 라이브러리로 가능하다는 의미로 한거야. 결국 성능때문에 깨야하는 경우가 있고 기능은 제공해야하니까. 근데 딴건 다 괜찮은데 비아냥대듯이 말하면 좀 그렇다. 다른 의견 주니까 내가 함수형 모를거라고 생각하는 이유는 대체 뭐야. 함수형 서버로 출시도 했어.

[o o(27.119)]

보통 evaluation 과 execution 이렇게 나눠. 하스켈은 evaluation 되는 완전 순수한 함수형 언어야. side effect가 zero. IO Monad 그자체도 side effect가 없어. 단지 런타임에 execution될때 실제로 side effect가 생기는데 이것때문에 purity가 깨진다는건 이해가 완전히 없어서 그래. 그냥 모르는거.

[o o(27.119)]

OK 비아냔대듯이 말한건 사과하겠고 서버까지 만들어봤으면 어느정도 다루어 봤겠지만 , 그렇다고 아주 잘 이해한다는 듯이 말한건 니 잘못. 니가 말한것 처럼 넌 그 정도 이해가 없어.

[익명(222.117)]

상태 변화가 side-effect야? 부가효과랑 상태변화랑 별개 개념이지. 모나드라는 개념이 꼭 상태랑 엮이지는 않지만 상태 변화를 사이드이펙트 제어하면서 정의하는데 쓰이잖아. 자꾸 상태변화 얘기한다고 purity 깨는거라고 생각하면 좀 그렇다니까

[o o(27.119)]

엥? 그럼 상태변화가 뭐임?

[o o(27.119)]

side effect는 메모리가 변경되는걸 말해 동의? 그럼 상태변화는 뭐임?

[익명(222.117)]

논리적인 개념에서 상태 변화를 말하는거야 가령 유저가 무언가를 구매한다는 로직을 담는 모나드는 끝에서는 유저 상태와 상점 상태를 받아서 변화된 유저 상태와 변화된 상점 상태를 리턴하겠지. 이때 이 로직 자체가 상태변화야. 메모리 변화는 메모리를 외부 시스템이라고 생각하고 이것을 eval하면서 변화시킨다면 사이드 이펙트 방출하는게 맞지. 마치 데이터베이스 쿼리 날리듯이.

[o o(27.119)]

이쯤 끝내자. 누가 이겼니 하는건 기분나쁠것 같고. 그냥 끝.

[익명(222.117)]

그래 근데 오랜만에 함수형 좀 제대로 알고 있는 사람 만나서 반가웠다. 그냥 서로 오해가 좀 있지 않나 싶어.

[o o(27.119)]

걍 디씨 잖아. 반가웠다 ㅋㅋ ~~ 최소한 허접은 아니네 ㅋ

[익명(1.237)]

나도 싱글톤으로 떡칠하는 개발자인데... 싱글톤이 위험한 이유는 전역 변수처럼 무지성 떡칠이 가능하기 때문이 아닌가 싶다. 싱글톤이 어울리는 과제가 있는거고 다른 패턴을 써야할 때가 있지만 나중에는 그 무지성 떡칠들 때문에 큰코다치기 쉬운듯. 그래서 경험에서 우러나오는 부정적 반응들이 있는게 아닌가 싶다. 쟤네 생각이랑 너가 하는 얘기랑 똑같을걸?

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

[익명(110.11)]

막줄보고 욕 참았다

[익명(220.119)]

ㄹㅇ 왜 유도하는거야

[익명(110.11)]

내가 싱글톤 빠돌인데, 다른사람이 쓴 코드.. 래퍼에 래퍼보고 현타와서 쓴거임. 에셋을 올렸으면 적당히 활용할수있게 외부 api노출되는거 깔끔하게 해놔야하는데 그런거 없이 내부 코드까지 다 보게 만들음. 근데 그게 참조에 참조 래퍼에 래퍼라 돌아버릴거같다

[익명(222.236)]

싱글톤 쓰기 싫어서 코드를 전부 합쳐서 하나로 만들었습니다 - dc App

[익명(117.111)]

막줄추

[익명(121.158)]

욕하면 찾아옴? 와서 과외좀 부탁해

[익명(219.251)]

어휴

[익명(175.223)]

그냥 뭐 깊게 아는 건 없고 깔짝대기만 한 것 같은 느낌인데요