디자인 패턴을 만들어내는 이유

디자인 패턴을 만들어낸 이유에는

소프트웨어공학의 정신이 깃들어있다.

[컴퓨터(Computer Science)/소프트웨어공학(Software engineering)] - 소프트웨어공학(1) 필요성과 특징

알아보자

 

---

 

소프트웨어 구조가 잡혀있어야 좋은 프로그램이 나온다고 한다.

그러한 소프트웨어 구조를 짜는 법은 도대체 어디서 배우는 것일까?

소프트웨어 공학에서 보았듯이

구조는 변경할 수 있느냐가 제일 중요한 핵심이다.

 

코드를 고치기 위해서는 기존 코드를 이해해야 한다.

어떠한 프로젝트에 중간에 투입되었을 때, 신입 사원이 되었을 때, 가장 오래 걸리는 부분이라고 한다.

머리로 코드에 대한 전체적인 그림을 그릴 수 있다면 해결책을 쉽게 찾을 수 있다.

그렇다면 어떻게 코드를 구성해야

누구든지 시간이 조금만 걸리고도 이해하게 만들 수 있을까?

라는 질문을 해봐야 한다.

또한 내가 해결책을 바로 찾았다고 해서

해당 해결책이 후에 다른 사람의 접근을 방해하지는 않는지 알아보아야 한다.

 

---

 

그 중에서 디커플링, decoupling 이라는 용어가 있다.

쉽게 말하자면 2개의 코드 중에서 1개의 코드가 없다면 나머지 코드를 이해할 수 없을 때

그것이 커플링, coupling 되었다고 한다.

즉, 의존적인 관계를 벗어나는 것을 디커플링이라고 할 수 있다.

 

만약 차례대로 코드를 읽는데 커플링된 스크립트가 많아진다면

하나를 읽어도 중간에 다른 스크립트를 참조해야하는 등

머리로 한 번에 그려지지 않는 스파게티 코드가 될 수가 있다.

또한 하나를 바꾸면 여러가지를 연쇄적으로 바꿔야하는 상황이 올 수도 있다.

 

다시 말하면 디커플링의 최종 목표는

내가 변경/수정 하더라도 다른 코드는 변경/수정을 하지 않아도 되게 하는 것

이라고 할 수 있다.

 

커플링이 적을수록 이해하기 쉬운 코드라고 할 수 있다.

-> 이해하기 쉬운 것이지 효율적인 것 까지는 모르겠다.

다만 하드웨어의 발전에 따라 장비의 효율성보다

작업의 효율성을 중요시 한다면 커플링을 지양하는 것이 올바른 방향일 것이다.

 

---

 

그렇다 모든 코드를 디커플링하면 된다는 간단한 결론을 얻었다.

위와 같이 좋은 구조는 변경을 하더라도 해당 부분에만 영향을 끼치니 생산성을 높여줄 수 있을 것이다.

하지만 게임의 특성상 업데이트라는 것이 주기적으로 일어난다는 가정하에

기능을 하나 추가하거나 버그를 잡을 때 변경하는 경우

나머지 코드와 깔끔하게 통합할 수 있도록 신경써줘야 한다.

즉, 업데이트 주기마다 수천 수만 번의 변경에서도 구조를 유지해야한다는 말이다.

 

프로그래머는 이 시점에서 

어디를 디커플링 해야하는 것인지 또는 어디를 추상화시켜야 하는지 고민해야 한다.

이것은 나중에 쉽게 변경하기 위해서 어디를 확장성에 중점을 두고 설계할 지를 결정하는 것이다.

++ 예를 들어 캐릭터의 탈 것에 대해서 말만 타고다니게 했는데 나중에 용을 타고 다니게 한다면

말이 이동하는 코드와 날라다니는 용의 코드는 다를 것인데 이를 추상화시키는 것이 낫지 않을까?

라는 생각과 비슷하다.

 

하지만 우리가생각한 대로 되지 않는다.

https://www.youtube.com/watch?v=y8LVEc5cwXk 

짱구는 못말려

 

추상화 계층을 추가하거나 확장 가능성을 제공하기 위해 기존의 코드를 수정하거나 새로 만드는 것은

우리가 필요할 경우가 미래에 생길 것이라고 생각했기 때문이다.

하지만 이를 위해 미래에 쓰일 것이지만 당장 필요없는 것들이 추가되면 

지금 현 상태에서의 개발 비용이 급격하게 늘어난다.

딜레마에 빠지게 된다.

 

즉, 해당 모듈을 만들어놓았지만 쓰지 않을 경우에 대한 리스크가 커진다.

모든 것에 대해 확장성을 열어 놓으면 앞서 말했듯이 주기적 업데이트 시에

검토해야할 것들이 엄청나게 많아진다.

일정에 못맞추는 경우도 생길 수도 있다는 말이다.

 

---

 

아니 그러면 우리가 디자인패턴을 배우는 것이 쓸모가 없는 것인가??

라는 질문이 나올 수 있다.

 

아니다. 정확하게 말하면 반만 맞다.

우리가 미래에 필요한 것을 미리 만드는 것은 괜찮다.

하지만 미래에 쓰일지도 몰라라는 생각으로 미리 만드는 것은 게임의 성능을 저하시킬 수 있다.

코드의 유연성을 위해 가상 함수, 인터페이스, 포인터, 메시지와 같은 많은 도구들에 의존하지만 이것들의 런타임 비용이 만만치 않기 때문이다.

 

유연성이 나쁜 것은 아니지만

개발 속도, 일정 또한 맞춰야 하는 것이 현실이다.

게임은 더군다나 밸런스, Balance라는 것이 있어야 하기 때문에

처음부터 모든 것을 갖추고 개발하기라는 것은 쉽지가 않다.

이러한 특성 때문에

게임개발에서는 프로토타입을 빨리 만드는 것에 치중하기도 한다.

 

그렇다면 뭐가 중요한거야? 코드를 확장성 있게 만들라는 거야 말라는 거야?

결국 Trade-off 관계이다.

무엇이 더 중요한지는 프로젝트 리더의 결정에 따르자.

 

---

 

그렇다면 프로토타입 위주의 개발을 하자고 했다면 어떻게 될까?

 

앞서 말한 구조가 잘 짜여진 코드를 작성하기 위해서는 설계에 대해서 엄청난 비용이 들어간다.

하지만 어떤 기획에 대해서 이것이 기획팀과 개발팀의 커뮤니케이션을 위해서

프로토타입을 빨리 뽑아야할 때가 있다.

더군다나 확장성을 위해서 모듈을 만들었지만 기획에서도 의도하지 않고 그냥 시험삼아 넣어본 기능에

너무 비용을 들이다 뒤집어지는 경우가 나오는 것만큼 화나는 일이 없다고 한다.

즉, 쓰지도 않을 코드에 정성들이다가 죽도 밥도 안되는 경우가 있다는 말이다.

때문에 처음에 말했던 잘 짜여진 구조에 대해서는 어느 정도 게임이 완성된 이후에 고려할 일일 것이다.

 

---

 

잘 짜여진 구조를 만드는 것에는 목적이 있다.

 

1. 프로젝트에 누가 중간에 참가하더라도 코드를 쉽게 이해하고 바로 도움이 될 수 있게 한다

2. 실행 성능을 최적화하고 싶다.

3. 새로운 기능을 빨리 추가할 수 있다.

 

하지만 업데이트 주기에 개발 속도를 맞추다 보면 이같은 것이 힘든게 현실이라고 한다.

결국 위 3가지를 모두 충족시키기는 정말 어려워진다.

trade-off 로 귀결된다.

 

---

 

현직자 분들이 준 꿀팁 아닌 꿀팁이 있다며 주신 것들이 있다.

 

1. 추상화와 디커플링을 잘 활용하면 코드를 점차 쉽고 빠르게 만드는 것이 가능하지만

해당 모듈 또는 기능에 대해 미래에 필요할 것이 라고 생각되지 않으면 시간 낭비는 x

2. 프로토타입을 만들 때에는 신속한 것이 좋다. 어차피 될대로 되라 하고 만들었는데

그대로 진행된다면 잘 만든 나의 능력을 칭찬해주자

3. 버릴 코드는 시간을 들이지 말자

4. 재미있는 것을 만들고 싶다면 만드는 것부터 재밌어 하자.