복잡한 상태 관리

이 글은 복잡한 상태 관리에 대해 다루지 않는 복잡한 글입니다.

저는 얼마 전 까지만 해도 게임 프로그래머였습니다.

프론트엔드 개발자로 전향한 후 가장 생소했던 말은 복잡한 상태 관리 라는 말이었는데, 왜냐면 안 복잡했기 때문이죠.

게임에서의 상태

• 애초에 최소한 수백개의 상태가 있습니다.
• 그중 수십개는 초당 60번씩 변경됩니다.
• 상용 모바일 게임은 클래스 하나가 100개의 상태 (프로퍼티)를 가지고 있는 경우도 흔할 것 같습니다. 그리고 패치 한번 할 때마다 10개씩 늘어납니다.
  • 업데이트마다 10개씩 늘어나기만 하고 절대로 지워지진 않습니다.
  • 서비스 앱들은 부분 서비스 종료나, 이벤트 종료, UI 개편에 따라 기능이 줄어들거나 리팩토링 될 수 있습니다.
  • 게임 아이템이 시간이 지남에 따라 사용불가가 되는걸 보셨나요? 하스스톤 초기 카드부터 지금까지 나온 모든 카드는 시간이 지나면 없어지는게 아니라, 실제로 모든 카드가 플레이 가능합니다.
• 인스턴스가 굉장히 많습니다. 몬스터는 기본적으로 수십마리 ~ 수백마리도 존재할 수 있습니다.
• 커플링이 심합니다.
  • 웹페이지, 특히 모바일 앱은 서로 떨어져있는 컴포넌트가 통신할 일이 거의 없습니다.
  • 게임은 거의 모든 클래스가 다른 거의 모든 클래스와 통신합니다.
• 프론트엔드 개발에서 대부분의 상태는 서버에서 전달됩니다. 계산 또한 서버에서 이루어지구요.
  • 게임 개발에서 99% 상태는 클라이언트에서 계산합니다. 필요에 따라 서버에서도 한번 더 하는 것일 뿐이구요.

게임 개발자들의 상태 관리에 대한 생각

• 복잡하다고 생각하진 않습니다. 그냥 코드가 지저분하다고는 생각할 뿐..
• 애초에 상태 관리 라는 멋있어보이는 단어를 발명할 생각 자체를 해보지 않았습니다.
• 이걸 라이브러리를 개발해서 단순화하려고 하지 않습니다.
  • 첫번째는, 위에 언급한것처럼 복잡하다 고 생각하지 않습니다.
  • 그래도 몇몇 사람들은 깔끔하게 처리해보고자 라이브러리를 만들었습니다.
  • 결과는 처참하게 더 복잡해졌고, 라이브러리들은 자연스럽게 뭍혔습니다.

물론 근본적인 차이는 있습니다.
가장 큰 차이는 웹은 가능한 한 효울적으로 렌더링 하려고 하고 게임은 무식하게 렌더링 한다 이런 차이가 있겠네요.

그럼에도 불구하고

2021년, 모던 프론트엔드 개발 은 그다지 복잡하지 않습니다.
심플함이 미덕이 되면서 한 화면에 나타나는 정보는 점점 더 줄어들고 있고, 복잡한 UI가 배제되면서 버튼(action)의 수 또한 같이 줄어들고 있습니다.

모바일 앱 개발을 생각해 보세요.

화면에는 아주 적은 양의 정보만 표시되며, Page(Screen)단위로 잘 분리되어 있고, 페이지간에 일방적으로 데이터를 넘겨주기는 해도, 서로 소통할일은 없습니다.

그래서 하고싶은 말은

게임이 어렵고 앱만들기는 껌이다 라는 글이 아닙니다.
(애초에 게임 만들면서도 복잡하다고 생각해본적이 없습니다.)

복잡한 상태 관리 라는 고정관념이 오히려 일을 더 복잡하게 만듭니다.

인터넷에 올라오는 대부분의 상태 관리 혹은 아키텍쳐 글을 보면 느끼는점은, 쉽게 할 수 있는 일을 좀 많이 돌아간다라는 느낌입니다.

복잡하게 생각하지 말고 아주 간단하게 다시 생각해보세요.

그렇게 어렵지 않을 수 있습니다.