좋은 소프트웨어 구조의 필요성과 장점
구조는 "변경"과 관련이 깊습니다.
구조가 없는 코드는 여러 시스템들이 얽히고 섥혀있는 스파게티의 형태로 코드가 흐릅니다.
그렇게 되면 나중에 코드를 수정해야 할 때, 하나의 변수를 바꾸려고 하면 다른 모든 부분이 틀어지게 될 수가 있게 됩니다.
정말 최악입니다. 저런 상황에서 유지보수를 하기는 너무 어렵습니다.
복잡도가 너무 높죠
그래서 좋은 소프트웨어 구조가 필요합니다. 변경이 쉽도록 하기 위해서죠.
구조가 잡혀있는 코드는 고칠 때 전체 프로그램을 이해해야 하는 것이 아니라 각 시스템들이 잘 분리되어 있기 때문에 고치려는 부분과 연관된 작은 부분만 이해하고 코드를 고칠 수 있습니다.
고친 후 테스트를 진행한 후 코드를 보기 좋게 정리까지 해주면 됩니다!
좋은 소프트웨어의 구조의 비용
득이 있으면 실이 있는 법이죠
좋은 구조는 거저 생기지 않습니다.
지속적으로 유지보수를 하면서 구조를 유지하려는 노력이 필요합니다.
그리고 구조를 유지하는 이유는 결국 변경에 대비하는 것입니다.
하지만 변경될 가능성이 거의 없는 프로젝트라면 구조를 유지하려고 노력한 의미가 많이 떨어지는 것이죠.
예를 들어 미래에 변경 될 것이라 예측해서 확장성 있게 추상화도하고 복잡성을 늘리다보면 디버깅도 어려워지고 유지보수에 시간이 더 걸리게 됩니다.
이런 확장성에 취하게 되면 코드에 인터페이스, 가상함수, 추상화 등등 온갖 구조가 붙으면서 오히려 이해하기 어려운 코드가 될 수도 있습니다. 아이러니하죠?
또 성능 이슈도 있습니다.
코드를 유연하게 만드는 많은 패턴이 포인터, 메시지, 가상함수같은 메커니즘에 의존하게 되는데 이러한 메커니즘은 런타임에 비용이 요구됩니다.
예를 들면 가상 함수의 경우 virtual table을 한 번 참조해야 하는 비용이 있습니다.
성능을 위한 최적화는 가정을 제한할 수록 선호합니다.
예를 들어 적이 256보다 적게 나온다고 확신한다면 적의 ID를 1byte로 압축할 수 있습니다.
결론
소프트웨어 구조의 장단점을 간단히 알아보았는데요, 결국 중요한 것은 밸런스를 잘 잡는 것입니다.
프로그램을 유연하게 만들려고 하면 성능이 낮아질 수 있고, 성능을 높히려 최적화하면 유연하지 못하게 됩니다.
역시나 결국은 트레이드 오프!
제가 읽고 있는 책의 저자는 이렇게 말합니다.
경험상으로는 재미있는 게임을 최적화하는 것이 최적화된 게임을 재미있게 만드는 것보다 훨씬 쉽다. 처음에는 코드를 유연하게 유지하다가 기획이 확실해진 다음에 추상 계층을 제거해서 성능을 높이는 타협안도 있다.
제가 느끼기에는 딱 이렇게 하라는 지침은 없으며, 지금 작성하고 있는 코드가 유연성이 필요한지를 먼저 판단하고 그 판단에 맞는 코드를 작성하면 좋을 것같다고 생각합니다.
참고
게임 프로그래밍 패턴 (로버트 나이스트롬, 한빛 미디어)
