Today I Learned - Day 69 [직렬화와 역직렬화의 소소한 팁]

프로젝트 진행 중에 엑셀 등의 외부 요소와 연동을 하기 위해서 Json이나 Csv, ScriptableObject 등을 사용하는 건 일전에도 몇 번 설명한 적 있다.

다만, 그 때에는 '직렬화/역직렬화 방법' 만을 서술했지, 그래서 어떻게 구성하면 되느냐는 서술한 적이 없다.

그러니, 그것을 작성하는 방식에 대해서 '간략하게' 설명 해 보자.

---

직렬화, 역직렬화

직렬화는 프로그램 내부의 각종 요소들을 외부 프로그램으로 입/출력 할 수 있도록 '형태 자체를 간략화 시키는' 행위를 말하며, 역직렬화는 이렇게 '간략화 된 형태를 원상 복귀 시키는' 행위를 가리킨다.

비단 게임 제작 뿐만이 아니라 프로그램 개발 전체에서 다른 부서와의 협업을 한다거나 자동화 시스템을 구축한다거나 하는 경우에 매우 자주 활용되는 개념으로, 현대 개발 사회에서 절대로 뺴 놓을 수 없는 프로그래밍의 필수 기술이라고 할 수 있는 요소다.

 

즉, '직렬화와 역직렬화는 개발자가 아닌, 다른 부서를 위해서 사용하는 경우가 잦다.' 때문에 이와 관련된 요소 만큼은 개발자적 마인드를 꽤나 많이 포기해야 한다. 가능한 한 헷깔리지 않게 구성하면서도 작성하기 쉽게 만들어야 하며, 그것을 위한 포맷이나 플랫폼의 제작 능력 또한 중요한 편이다.

---

CSV, JSON... '엑셀'

직렬화와 역직렬화는 기본적으로 데이터를 기술하기 위한 확장자를 기반으로 구축된다.

대표적인 것이 CSV, XML, JSON으로, 이에 대해서는 일전에 기술한 바 있다.

하지만, 이들은 일개 중개 역할을 진행할 뿐이다. 다른 반대쪽에서 이 파일을 다루는 것을 한번 더 해야하며, 이 2중 구조를 통해서 서로 완전히 다른 개발 환경 2개를 연동하는 것이다.

 

이 '맞은 편'에 해당하는 요소는 여러 종류가 있겠으나, 게임 개발에서 가장 많이 사용하는 것은 엑셀이다.

엑셀 자체가 통합 문서 작성 프로그램이다 보니 이래저래 수식이랑 기타 요소들을 활용해서 '문서를 편하게 작성하는 것'에 집중한 덕분에 이런 '데이터 편집'에 너무나도 탁월한 것이 원인이다.

 

즉, 게임 개발자는 기본적으로 '엑셀을 다룰 줄 알아야 한다.' 이것이 기본 전제 중 하나다.

가능하면 엑셀 매크로도 쓸 줄 알면 좋겠지만, 일반적으로는 그것을 익힐 수 있을 정도로 정보나 여유나 기타 등등이 부족했을 것이라서 이에 대해서는 덤으로 보는 것이 좋을 터다.

중요한 것은, '엑셀을 이용해서 문서를 제작할 수 있느냐'이니 말이다.

---

개발자와 기획자의 괴리감에 대하여.

'데이터 작성'에 대해서는 개발자와 기획자는 시각이 완전히 다르다.

간단하게 정리하겠다. 개발자는 데이터를 형성할 때 가장 많이 신경쓰는 요소는 '최적화'지만 기획자는 그 반대로 '직관성'을 중점으로 본다. 그렇다 보니 '데이터'를 보는 시점이 둘 간에 차이가 거의 반대에 가까울 정도로 큰 편이다.

 

개발자의 시점에서 데이터를 바라보면 통합 변수를 형성한다거나 하는 방식으로 존재하는 변수를 줄이려고 하는 경우가 많다. 배열이나 리스트는 하나의 셀에 콤마로 구분하는 것을 선호하는 편이기도 하다. 그도 그럴게, 이러면 추가로 처리해야 하는 작업이 없기 때문에 이래저래 편하기 때문. 거기다가 최적화를 생각한다면 변수를 마냥 늘리는 것도 난감하다.

이 경향은 서버 개발자 시점에서 극대화 되며, 그렇다 보니 전체적으로 '묶어서 구성하는' 경우가 많다.

 

반대로 기획자의 시점에서는 한 눈에 어떤 것이 어떤 역할인지 알아볼 수 있고, 작성하기 편하고 안정적인 것을 선호한다.

한 눈에 볼 수 있다는 것은 '전체 상황을 살피기가 좋다는 것'이고, 작성하기 편하고 안정적인 것은 그 만큼 실수를 할 확률을 줄여주기 때문이다. 그렇기 때문에 변수를 전체적으로 '풀어서 구성하는' 경우가 많고, 아예 특정 상황에만 쓰는 변수라고 해도 별개 변수로 두는 것을 선호한다.

배열이나 리스트도 콤마로 구분하기 보다는 아예 다른 셀으로 두는 것을 선호하기도 한다.

 

물론, 개발자가 기획까지 한다고 한다면 그냥 개발자 적 시점으로 데이터를 바라보면 될 것이다.

하지만, 그러지 못하니까 개발자와 기획자가 나뉘는 것일 터다.

 

어지간하면 '데이터'를 다루는 것은 개발자 보다는 기획자다. 그렇기 때문에 이러한 점에 대해서는 기획자를 우선해서 고려하는 것이 좋다.

---

기획자를 우선 고려한다?

자, 위에서 '기획자를 우선해서 고려하라'고 말은 했지만, 우리는 개발자다.

[본인은 기획자로서 업무를 해 본 적이 짧게나마 있긴 하지만, 일단 지금은 개발자로서 작업하고 있다.]

그렇다면 기획자가 어떤 것을 선호하는 지는 확실하게 알아야 할 것이다.

그러니, 한번 생각나는 대로 정리해볼까 한다.

[여담으로, 본인도 개발하다 보면 깜빡하기도 하고, 본인이 담당하지 않는 경우도 있는 지라, 사실 잘 지켜지지는 않는다.]

• Enum값은 '알기 쉽게 구성된 경우'가 아니라면 int로 치환하여 사용한다.
  • 알기 쉽게 구성된 경우가 무엇이냐면, Fire, Ice, Lightning 같이 '극단적으로 직관적'으로 쓰여서 따로 외울 필요가 없는 경우를 말한다. 이 경우에는 굳이 코드나 Enum을 정리한 것을 볼 필요 없이 사용할 수 있기 때문에 직관성을 위해서 Enum값을 그대로 사용하는 것이 좋다.
  • 다만, 클래스 명 같은 것은 아무리 직관적으로 적는다고 해도 안외우고 사용하는 것은 힘들다. 이런 경우에는 int값으로 정리하고 기록되는 영역 밖에 추가로 기술해 놓는 것이 좋다.
• 배열 값은 따로 떨어뜨려서 셀로 형성하는 것도 고려하자.
  • 의외로 이게 '직관성'에 기여하는 요소가 어마어마하게  크다.
  • 거기다가 만약에 '아이템과 드랍률'을 작성한다고 하면 아이템 1, 2, 3... 확률 1, 2, 3... 이렇게 작성하는 것 보다 아이템1, 확률1 | 아이템 2, 확률 2 | 아이템 3, 확률 3 ... 이런 방식으로 작성하는 것이 훨씬 보기 좋다.
  • 다만, 이렇게 구성했을 때 좌우로 너무 길어지면 오히려 역효과가 난다. 이런 경우에는 '서로 연관성이 깊어서 순서 만 기억하면 바로 작성 가능한 경우'에 한하여 List로 합쳐서 구성하는 것이 더 좋을 것이다.
• '상황에 따른 용도가 다른 변수'는 가능하면 지양하는 것이 좋다. 쓰더라도 '같은 구분이나 유사한 역할'으로 묶어서 구성하도록 하자.
  • 그리고, 이런 '상황에 따라서 다르게 작동하는 변수'는 확실하게 데이터화 영역 바깥에 부연설명을 적어놓자.
  • 비슷하게, 여러 변수를 통합해서 구성하는 경우도 이와 동일하다. 가능하면 지양하되, 써야한다면 부연 설명을 확실하게 적고, 통합하는 기준도 같은 부류로 묶이는 경우에만 통합해서 쓰도록 하자.
• 이외에도 여러 방법이 있긴 하다. 다만, 이 이상으로 가면 개발자가 데이터 입력 포맷을 위해서 별개 작업을 추가로 해야하는 수준이기 때문에, 기획자와 논의 해 보고 결정하는 것이 좋다.

---

사실 이번 내용은 개발을 하면서 기획자와 직접 연계해서 형성하는 것이 제일 중요하다.

위의 사항은 어디까지나 '이런 것도 고려하자'라는 것이고, 기획자와 상의하여서 개발자와 기획자 양쪽 모두가 작성에 불편함이 없는 정도가 가장 좋은 방식일 것이다.

기획자를 우선해야 하는 것은 맞지만, 기획자에게 너무 우선해서 직렬화/역직렬화 작업에 긴 시간이 걸리면 그거야 말로 본말전도일 수도 있으니 말이다.

그래도 위 사항을 알고 있다면 미리 어떻게 만들면 좋을지 미리 고민해 두고, 실제로 사용할 때 그걸 통해서 더욱 수월하게 작업할 수 있을것이라 생각한다.