1강. GAS는 어떤 문제를 해결하며 언제 도입해야 할까

?1. 이번 강의에서 해결할 문제

공격 두 개뿐인 게임에 GAS를 넣으면 Plugin 설정, 태그, Effect Asset과 비동기 Ability 수명 때문에 오히려 개발이 느려질 수 있습니다. 반대로 스킬마다 비용·쿨다운·기절·면역·버프·예측을 별도 bool과 Timer로 구현하면 조합 수가 폭발합니다. 도입 결정은 유명 프로젝트 사용 여부가 아니라 현재 복잡도와 향후 변화로 내려야 합니다.

✓2. 학습 목표

✓이 강의를 마치면

• GAS가 해결하는 반복 문제와 도입 비용을 설명합니다.
• 작은 Component 구조로 충분한 프로젝트를 구분합니다.
• 서버 권한·예측·데이터 조합이 필요한 시점을 판단합니다.

◇3. 핵심 개념

GAS의 강점은 스킬 하나의 코드량을 줄이는 데 있지 않습니다. 여러 Ability가 같은 Attribute, Effect, Tag, Cue와 활성화 규칙을 공유하고 네트워크 예측·복제를 같은 계약으로 처리하는 데 있습니다. 스킬 수가 적고 상태 충돌이 거의 없으면 명시적 Component가 더 낫습니다.

질문	일반 Component가 유리	GAS가 유리
능력 수	소수·고정	다수·지속 추가
상태 상호작용	독립적	기절·침묵·면역·중첩 조합
수치 변경	단순 직접 계산	버프·디버프·캡처·실행 계산
네트워크	서버 실행만으로 충분	소유자 예측과 보정 필요
데이터 제작	코드 중심	DataAsset·Effect 조립 필요

§4. 구현

Plugin을 활성화하고 Game Module의 빌드 의존성을 명시합니다.

GASCombat.Build.cs

PublicDependencyModuleNames.AddRange(new[]
{
    "Core", "CoreUObject", "Engine",
    "GameplayAbilities", "GameplayTags", "GameplayTasks"
});

도입 전 현재 전투 코드를 다음 네 열로 분류합니다.

행동: 공격, 대시, 회복
수치: 체력, 마나, 공격력, 방어력
상태: 기절, 침묵, 무적, 슬로우
표현: Montage, Niagara, Sound, HUD

상태마다 Timer·bool·RPC가 중복되고 세 열 이상이 서로 직접 참조한다면 GAS 후보입니다. 단순 점프나 문 열기처럼 엔진 기본 기능으로 충분한 행동까지 Ability로 바꾸지 않습니다.

→5. 코드가 동작하는 이유

세 Module을 공개 의존성으로 추가하면 Public GAS 타입을 소비 Module에서도 해석할 수 있습니다. 도입 결정표는 기능 이름이 아니라 수명·조합·권한 복잡도를 드러내므로 과도한 도입과 뒤늦은 재작성 위험을 함께 줄입니다.

§6. 실패 사례와 해결

!자주 하는 실수

• 모든 상호작용을 Ability로 구현: 비용·상태·예측이 없는 단순 기능은 일반 Component로 유지합니다.
• 네트워크를 나중에 추가: 데미지·비용·타깃의 권한 경계를 첫 설계부터 서버에 둡니다.
• Effect Asset 수만 증가: 이름 규칙과 공통 계산·태그 정책을 먼저 만듭니다.
• 샘플 구조를 그대로 복사: Pawn 교체와 지속 상태 요구를 기준으로 ASC 위치를 다시 결정합니다.

✎7. 직접 실습

✎직접 실습

현재 또는 가상의 전투 기능 12개를 행동·수치·상태·표현으로 분류하세요. 각 기능의 서버 권한, 지속 시간, 중첩, 취소, 예측 필요성을 표시하고 GAS 도입을 정당화하는 조건 세 가지와 도입하지 않을 조건 세 가지를 작성합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 스킬 수가 적은 프로젝트에서 GAS가 오히려 비용이 될 수 있는 이유는 무엇인가요?
2. GAS의 핵심 이점이 단일 Ability 코드 단축이 아닌 이유는 무엇인가요?
3. 클라이언트 예측이 필요해도 최종 데미지 권한은 어디에 있어야 하나요?

■9. 핵심 요약

■핵심 요약

GAS는 스킬·상태·수치 조합과 네트워크 예측이 복잡해질 때 선택합니다. 다음 강의에서는 ASC를 중심으로 Ability, Attribute, Effect, Tag, Cue가 어떤 방향으로 데이터를 주고받는지 추적합니다.