[지식/경험] 사이드 이펙트

 

 

 

안녕하세요.

 

딩딩입니다~!

 

 

이번에는 의도치 않게 발생하는 부작용인, 사이드 이펙트에 대해서 포스팅해보려고 합니다.

 

---

 

사이드 이펙트란?

 

 

사이드 이펙트(Side Effect)를 사전에서 검색해보면 다음과 같이 나타납니다.

 

1. (약의) 부작용

2. (조치 등의 예상치 못한) 부작용

 

즉 무언가에 대한 부작용을 뜻합니다.

 

 

 

 

그렇다면 게임 개발에서 발생하는 사이드 이펙트는 무엇이 있을까요?

다양한 부분이 있겠지만, 크게 세 가지(+1)로 확인할 수 있습니다.

 

1. 패치 후 기존 내용에 발생

2. 새로운 스펙을 개발 중에 발생

3. 이슈 수정 후에 관련된 부분에서 발생

+근본 없는 문제

 

보통 이슈를 수정을 하면, 당장 해당 이슈는 정리가 됩니다. 그러나...

이슈를 해결하기 위해 충분한 분석을 하고 *코드 리팩토링을 하지 않고 급하게 때우는 경우.

사이드 이펙트가 발생하게 됩니다.

 

 

 

대부분 일정이 타이트하고 당장 쳐내야 할 일감이 너무 많다 보니 어쩔 수 없이 프로그래머가 급하게 수정을 하게 되는데, 보통 여기서

사이드 이펙트가 '크게' 발생할 가능성이 많아집니다. 물론 당장 발생하지 않더라고 어느 시점에 크리티컬하게 나타나는 경우도 많습니다.

QA 입장에서는 이렇게 수정된 이슈를 겉으로 보기에는 알 수가 없습니다.

그래서 전체적인 테스트가 마무리된 시점에서 리그레션 테스트를 통해서 사이드 이펙트를 미리 잡아내는 일정을 따로 빼놓기도 합니다.

(리그레션 테스트 일정)

 

 

 

 

패치 후 기존 내용에 발생

 

해당 사이드 이펙트는 라이브 환경에서 주로 확인이 됩니다.

테스트 환경 혹은 QA, 리뷰 환경에서는 전혀 발생하지 않았으나, 패치한 내용이 라이브 환경에서 유저가 기존에 가지고 있던 정보와 충돌하여

발생하는 문제가 있습니다.

이러한 사이드 이펙트는 이미 상황이 벌어지고 나서 체크가 되는 경우가 많기 때문에, 빠른 대응을 위해서 관련 히스토리를 찾고

그에 대한 내용을 미리 체크해두고 개발팀에 공유하는 것이 가장 베스트 합니다.

 

 

 

 

새로운 스펙을 개발 중에 발생

 

개발 단계, 다음 업데이트 스펙 개발 중인 상황에서 발생하는 형태입니다.

새로운 콘텐츠, 시스템을 만들다 보니 보통 기존에 만들어 두었던 내용을 복사해서 사용하는 경우가 많습니다.

그러나, 이때 기존 내용을 복사한 내용에 의해서 기존 부분에서 사이드 이펙트가 발생하거나, 새로 만든 부분과 기존에 있던 부분이 엮인 부분에서

사이드 이펙트가 발생할 수 있습니다.

(이때 QA는 발생한 이슈가 새로운 이슈인지, 사이드 이펙트 이슈인지 판단하는 것도 좋은 경험이라고 생각합니다.)

 

 

 

이슈 수정 후에 관련된 부분에서 발생

 

가장 일반적인 사이드 이펙트입니다.

A를 고쳤더니, A의 이어진 기능에서 이슈가 발생하는 것입니다. 이런 현상은 주로 급하게 때운 방어 코드로 인한 문제가 발생하는 것이며, 보통 수정 확인 후 기능이 정상적으로 동작하는지 한번 체크해보던 중에 바로 찾아낼 수 있는 형태의 사이드 이펙트입니다.

 

 

 

 

 

+ 근본 없는 버그

 

크게 나눈다기보단, 별도로 설명하는 내용입니다.

게임은 여러 명의 인원이 협업해서 만드는 것이기도 하며, 다양한 직군이 모여서 만드는 것이기도 합니다.

그러다 보니, 프로그래머 코드뿐만 아니라 그래픽 리소스 업데이트 또는 기획자의 데이터에서도 이슈는 발생할 수 있습니다.

간혹 A를 수정했는데, 아~무런 연관이 없어 보이는 Z에서 문제가 발생할 수도 있습니다.

ex) 게임 옵션의 크레딧의 텍스트를 고쳤더니, 특정 스킬의 텍스트가 없어졌다.... 와 같은..

 

 

 

 

 

모든 사이드 이펙트가 발생하면, 이를 별도로 리스트 업해서 관리해 주는 것이 가장 바람직하며, 동일한 문제가 다시 발생하지 않도록 챙기는 것이

QA의 업무 중 하나입니다. (별도로 리스트업한 체크리스트로 리그레션 테스트를 진행하기도 합니다.)

언제 어디서 발생할지 알 수 없는 것이지만, 이를 막기 위한 QA의 고군분투는 항상 계속됩니다.

 

 

 

 

 

 

* 코드 리팩토링(Code Refactoring)

- 일련의 리팩토링을 적용하여 쉽게 이해할 수 있고 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작 변화 없이 소프트웨어 내부 구조를 변경하는 것을 말합니다. (코드의 가독성 증대, 효율성 증가를 위해 정리한다고 보면 됩니다.)

 

코드 리팩토링을 하는 상황은 아래와 같습니다.

1. 삼진 규칙(3번의 중복 / 3번의 같은 행위를 하면 리팩토링 진행)

2. 기능을 추가할 때, 코드 개선을 하며 리팩토링 진행

3. 버그를 수정해야 할 때 리팩토링 진행

4. 코드 검토(코드 리뷰)를 진행할 때 리팩토링 진행

 

---

 

 

QA 업무는 하면 할수록 아쉽고 빡센 것 같습니다.

어떻게 보면 쉽다고 생각되지만, 또 어떨 땐 감이 잡히지도 않고 너무 버겁기도 하고요.

하지만 여러 부서 인원들과 함께 업데이트를 해가면서 게임을 계속 다듬어 나가는 건 정말 보람되고 재밌는 것 같습니다!