디자인 패턴은 자주 만나는 설계 문제에 대해 개발자들이 정리해 둔 해결 방식입니다. 게임 개발에서는 특히 싱글턴, 옵저버, 상태 패턴이 많이 쓰입니다. 여기서 말하는 게임 디자인 패턴은 게임 기획의 디자인이 아니라 코드 설계 방식이라는 점을 먼저 밝혀 둡니다. 세 패턴이 어떤 문제를 풀고, 어디서 조심해야 하는지 정리합니다.

디자인 패턴을 배우는 이유

패턴은 정답 코드가 아니라 '이런 상황에서는 이런 구조가 잘 통했다'는 경험의 모음입니다. 패턴 이름을 알면 팀원과 대화가 짧아집니다. '이건 옵저버로 묶자'라고 말하면 긴 설명 없이도 구조를 공유할 수 있습니다.

반대로 패턴을 위해 패턴을 쓰면 코드가 쓸데없이 복잡해집니다. 문제가 먼저 있고, 그 문제에 맞을 때 패턴을 꺼내 쓴다는 순서를 지키는 것이 중요합니다.

싱글턴 패턴: 하나만 있어야 하는 관리자

싱글턴은 프로그램 전체에서 객체가 딱 하나만 존재하도록 하고, 어디서든 그 객체에 접근할 수 있게 하는 패턴입니다. 게임 매니저, 사운드 매니저, 저장 데이터 관리자처럼 하나만 있으면 되는 관리 객체에 자주 쓰입니다.

• 장점: 어디서든 쉽게 불러 쓸 수 있고, 중복 생성을 막음
• 단점: 전역 변수처럼 아무 곳에서나 상태를 바꿀 수 있어 버그 추적이 어려워짐
• 단점: 다른 코드가 싱글턴에 강하게 묶여 테스트와 교체가 어려워짐

유니티에서는 씬이 바뀔 때 싱글턴 오브젝트가 중복 생성되는 문제가 흔합니다. 이미 있으면 새로 생긴 것을 지우는 처리와, 씬 전환 시 유지할지 여부를 명확히 정해 두어야 합니다. 싱글턴이 늘어날수록 구조가 얽히므로 꼭 필요한 곳에만 씁니다.

옵저버 패턴: 일이 생기면 알려 주기

옵저버 패턴은 어떤 객체의 상태가 바뀌었을 때, 이를 지켜보던 여러 객체에게 자동으로 알려 주는 구조입니다. 업적 시스템이 대표적인 예입니다. 몬스터를 100마리 잡으면 업적이 달성되어야 하는데, 전투 코드가 업적 코드를 직접 부르면 둘이 단단히 묶입니다. 대신 전투 코드는 '몬스터가 죽었다'는 사건만 알리고, 업적·퀘스트·통계 시스템이 각자 그 사건을 듣고 반응하게 합니다.

C#의 event, 유니티의 UnityEvent, 언리얼의 델리게이트가 옵저버 패턴을 쉽게 쓰도록 도와주는 기능입니다. 주의할 점은 구독 해제입니다. 사라진 객체가 구독을 풀지 않으면 오류가 나거나 메모리가 해제되지 않습니다.

상태 패턴: 상태마다 행동을 나누기

캐릭터는 대기, 걷기, 점프, 공격, 피격 같은 상태를 오갑니다. 이를 if 문 하나로 처리하면 '점프 중이면서 공격 중이 아니고 피격 중도 아니면' 같은 조건이 끝없이 늘어납니다. 상태 패턴은 각 상태를 별도 객체로 만들고, 현재 상태 객체에게 입력 처리와 갱신을 맡깁니다.

상태마다 들어갈 때, 머무는 동안, 나갈 때의 처리를 나눠 두면 새 상태를 추가하기 쉽고 버그 위치도 금방 찾을 수 있습니다. 이 생각은 몬스터 AI의 유한 상태 기계로 그대로 이어집니다.

그 밖에 자주 쓰는 패턴

• 오브젝트 풀: 총알처럼 자주 생기고 사라지는 객체를 미리 만들어 두고 재사용
• 커맨드: 입력을 명령 객체로 바꿔 키 설정 변경, 되돌리기, 리플레이에 활용
• 컴포넌트: 기능을 부품으로 나눠 게임 오브젝트에 붙이는 방식
• 플라이웨이트: 나무 수천 그루가 같은 모델 데이터를 공유하게 해 메모리 절약

배운 패턴을 내 것으로 만드는 법

작은 플랫포머 게임을 만들며 플레이어 이동을 if 문으로 먼저 짜고, 같은 기능을 상태 패턴으로 다시 짜 보세요. 그다음 점수 UI를 옵저버로 연결해 보면 두 패턴의 효과를 직접 비교할 수 있습니다. 면접에서도 '어떤 문제 때문에 그 패턴을 썼는가'를 설명할 수 있어야 합니다.

SBS아카데미게임학원 게임프로그래밍 과정은 캐릭터 컨트롤과 게임 시스템 구현을 프로젝트 기반으로 다루어, 패턴을 실제 코드에 적용해 볼 기회가 됩니다.

자주 묻는 질문