디자인패턴 공부

[게임 프로그래밍 패턴] 1. 구조, 성능, 게임

EJH 2025. 5. 29. 17:31
반응형

소프트웨어 구조

혹시 정말 잘 짜여진 코드를 본 적이 있나?
나는 학생 시절엔 그런 기회도, 볼 생각도 하지 않았다.

과제를 제출할 때는 결과물만으로 평가받았다.
코드의 질은 중요하지 않았고, 주어진 기능만 구현하면 좋은 점수를 받을 수 있었다.

아래는 그 당시 제출했던 코드의 일부이다.

for (int i = 0; i < 20; ++i)
{
	check = 0;
	for (int k = 0; k < 10; ++k)
	{
		for (int j = 0; j < 100; ++j)
		{
			if (bl[j].y == i&&bl[j].x==k && bl[j].val==4)
				check++;
		}
	}
	if (check == 10)
	{
		for (int j = 0; j < 100; ++j)
		{
			if (bl[j].y == i)
				bl[j].x = 10000;
			if (bl[j].y < i)
				bl[j].y++;
		}
	}
}

지금 보면 의미를 알 수 없는 매직넘버와 변수명, 어떤 조건을 검사하는지조차 감이 오지 않는다.
함수로 분리하지 않아 중복되는 코드가 많았고, 조건이 바뀔 때마다 모든 코드를 일일이 수정해야 했다.

무려 2학년까지 이런 끔찍한 코드들을 작성했었다.

2학년 말부터 프로젝트의 규모가 커지면서, 여러 서적과 강의를 접하고 나서야 비로소 이런 문제들을 깨닫기 시작했다.

좋은 소프트웨어 구조

좋은 소프트웨어 구조란, 무언가를 고치거나 추가할 때 기존 코드를 거의 건드리지 않아도 되는 구조다.
그리고 이를 위해서는 기존 코드를 이해하는 과정이 반드시 필요하다.

위의 코드는 읽고 이해하기조차 힘들고, 수정하려면 이곳저곳을 함께 고쳐야 한다.
이런 문제를 해결해주는 대표적인 개념이 디커플링(Decoupling) 패턴이다.

디커플링은 작업하는 코드만 이해하면 된다.
다른 코드를 보거나 고치지 않아도, 원하는 작업을 할 수 있도록 해준다.

물론, 말만 들으면 멋져 보이지만…
이렇게 구조를 잘 유지하려면 많은 시행착오와 노력이 필요하다.

나 역시 졸업작품을 만들 당시, 좋은 구조를 유지하려고 무척 애썼다.
하지만 이번에는 구조에 너무 매달린 나머지, 정작 컨텐츠를 채워가는 시간이 부족해졌다.
엔진을 만드는데 90%의 시간을 쓰고, 컨텐츠는 발표일이 다가와서야 부랴부랴 쌓아갔다.
결국 구조는 무너지기 시작했고, 원하는 결과물까지 도달하기 어려웠다.

나쁜 코드의 장점

따라서 항상 완벽한 구조를 고집할 수만은 없다.
아무리 기발하고 재밌어보이는 게임이라도, 실제로 만들어보지 않고는 알 수 없다.
프로토타입을 빠르게 만들어보는 과정이야말로, 게임의 재미를 실험하고 발견할 수 있는 첫걸음이다.

이때는 완벽한 구조보다는,
언제든 버릴 수 있는 코드로라도 빠르게 결과물을 확인하는 것이 중요하다.
그러니 좋은 구조와 빠른 프로토타이핑, 이 두 가지를 균형 있게 맞춰야 한다.

마무리

아직도 완벽한 코드를 쓸 수는 없다.
하지만 과거의 코드와 시행착오를 통해, 조금씩 더 나은 구조와 더 나은 균형을 찾아가고 있다.
앞으로도, 언제나 이 균형을 의식하며 코드를 짜고 싶다.

 

 

 

 

 

반응형