[세튼의 유적 개발 일지 #03] 언리얼 GAS로 RPG 장비 아이템 시스템 설계하기

안녕하세요! '세튼의 유적'에서 프로그래밍을 맡고 있는 최우혁이에요.

 

이번 주에는 RPG 게임의 꽃이라고 할 수 있는 장비 아이템 시스템을 GAS(Gameplay Ability System, 언리얼 엔진에서 캐릭터의 능력·효과·스탯을 통합 관리하는 프레임워크) 위에서 새롭게 구현하는 작업을 진행했어요.

 

이 과정에서 겪었던 고민과 해결 과정, 그리고 그 속에서 얻은 작은 깨달음을 공유해 보려고 해요.

GAS 기반 RPG 장비 시스템을 어떻게 확장 가능하게 설계할지 고민 중인 분께 작은 참고가 되길 바라요.

 

1. 이번 주 목표

기존 프로젝트의 게임 시스템이 GAS 프레임워크로 전환됨에 따라, 장비 아이템이 부여하는 효과들도 프레임워크의 규칙에 맞게 다시 짤 필요가 있었어요.

 

이번 작업의 핵심 목표는 단순히 장비를 입고 벗는 것을 넘어, '앞으로 기획될 많은 종류의 장비 아이템을 단일 시스템 안에서 쉽게 정의할 수 있도록 유연하고 확장성 있는 구조를 만드는 것'이었어요.

 

2. 실제로 한 것

장비 아이템은 장착 시 스탯 증감, 스킬 부여, VFX(Visual Effects, 시각 효과) 출력, 특정 상태(태그) 부여 등 복합적인 효과를 동시에 통제해야 해요.

 

GAS에서는 이를 GameplayEffect(GE, 캐릭터의 스탯·태그·상태 변화를 정의하는 GAS의 핵심 효과 단위)라는 기능으로 처리하는데, 저는 구현 과정에서 발생할 수 있는 '구조적 문제'들을 막기 위해 두 가지 핵심 방식을 도입했어요.

 

A. GameplayTag-Attribute 매핑으로 UI 결합도 낮추기

아이템의 스탯 정보는 필연적으로 여러 UI에 표시되어야 해요.

하지만 UI가 데이터를 효과 로직(GE)으로부터 직접 참조하게 되면 시스템 간의 결합도가 너무 높아져요.

 

이를 해결하기 위해 프로젝트 전반에서 통용되는 GameplayTag(계층 구조로 분류된 식별용 태그 시스템)를 스탯(Attribute, 체력·공격력 등 수치형 스탯을 나타내는 GAS의 데이터 타입)과 매핑했어요.

 

이 방식으로 태그만으로 어떤 스탯을 다루는지 식별할 수 있게 되어, 코드 수정이나 Attribute 타입 참조 없이도 UI와 아이템 데이터가 깔끔하게 정보를 주고받을 수 있게 되었어요.

 

[스크린샷: GameplayTag와 Attribute 매핑 구조 — 태그로 스탯을 식별하는 흐름]

 

2. 에셋 파편화를 막는 Payload 기반 동적 GE 조립

보통 아이템을 하나 만들 때, 정보가 담긴 '데이터 에셋'과 실제 효과를 내는 'GE 블루프린트' 두 개의 에셋을 따로 관리해야 하는 경우가 발생해요. 이는 휴먼 에러를 유발하기 쉬운 환경이에요.

 

그래서 저는 데이터 에셋에 직접 장비의 효과 정보를 담는 Payload(GE 부여 시 함께 전달되는 사용자 정의 데이터 묶음) 구조체를 정의하는 방식을 사용했어요.

 

아이템 데이터 에셋 하나에 데이터가 집중되면, 런타임에 이 Payload 데이터를 읽어와 필요한 옵션을 적용하여 동적으로 GE를 조립해 부여할 수 있어요. 결과적으로 테스트 장비를 만들어 확인해 본 결과, 의도대로 하나의 에셋만으로 장착 기능이 온전히 동작하는 것을 확인할 수 있었어요.

 

[스크린샷: 데이터 에셋의 Payload를 읽어 런타임에 GE를 동적 조립하는 흐름]

 

3. 막힌 부분

사실 기술적인 구현보다 저를 더 괴롭혔던 것은 "어디까지 고려해서 설계할 것인가?"라는 구조적인 딜레마였어요

과거에 눈앞의 구현에만 급급하다가 데이터가 꼬이거나 확장이 불가능해 전체 코드를 다시 작성하게 된 아픈 경험이 있어서, 이번 프로젝트의 개발에 있어서는 유연함과 확장성을 가진 시스템을 만들려고 노력했어요.

 

하지만 막상 복잡한 동적 조립 시스템을 완성하고 되돌아보니, 머리를 싸매며 투자한 시간에 비해 '아이템마다 단순하게 GE를 선언하는 방식'보다 압도적으로 큰 이점을 얻었는가에 대한 회의감이 들었어요.

 

개발 시간은 한정되어 있는데, 너무 먼 미래의 확장성까지 챙기려다 보니 정작 가장 단순하고 직관적인 접근을 외면하고 있었을지도 몰라요.

 

처음에는 가장 단순하게 요구사항을 구현하고, 테스트를 통해 부딪히는 문제들을 다시 단순하게 풀어가는 것이 코드를 필요 이상으로 복잡하게 만들지 않는 접근임을 배웠어요.

 

4. 마치며

좋은 게임을 만들기 위해 기획은 끊임없이 변화해요.

이에 발맞춰 프로그래머는 한 발 앞을 내다보고 코드를 짜야 하지만, 그 확장성을 담아낸 코드가 때로는 스스로의 발목을 잡는 족쇄가 될 수도 있어요.

 

프로그래밍 격언 중 YAGNI(You ain't gonna need it)와 KISS(Keep it simple, stupid)라는 말이 있어요.

확장의 여지는 구조로 남겨두되, 구현은 가장 간결하게 해내는 것이 좋은 코드를 만드는 방법이 아닐까 생각해요.

 

다음 주에는 RPG의 또 다른 핵심인 '소비 아이템' 시스템을 구현할 차례예요.

소비 아이템은 장비와는 또 다른, 버프 중첩 시 로직 처리 등의 고민거리가 있지만, 금주의 깨달음을 바탕으로 다음 주에는 보다 단순 명료한 접근법으로 좋은 코드를 작성해 볼게요.

 

읽어주셔서 감사합니다!