김치킨 님의 블로그

[Unity/C#] 리플렉션은 왜 느리고, 왜 IL2CPP에서 위험한가

김치킨. — Sat, 31 Jan 2026 16:22:19 +0900

유니티 프로젝트에서 이름(문자열)으로 메서드/필드/프로퍼티를 찾거나 호출하는 순간, 대부분 “리플렉션(Reflection) 계열” 문제(성능/안정성/스트리핑)를 만나게 됩니다.
이 글은 Unity + IL2CPP(AOT) 환경을 기준으로, “언제 써도 되는지/언제 피해야 하는지/피할 수 없으면 어떻게 안전장치를 거는지”를 정리합니다.

0) 한 줄 요약

link.xml / [Preserve]는 코드가 빌드에서 삭제(스트리핑)되는 문제를 막는 장치입니다.
하지만 리플렉션 호출이 느린 것(탐색/메타데이터 접근 비용) 자체를 빠르게 만들진 못합니다.
런타임(특히 매 프레임) 에서 리플렉션을 쓰면 성능이 무너질 수 있고, IL2CPP(AOT) 에서는 “에디터에서는 OK, 기기에서는 실패” 패턴이 쉽게 나옵니다.

1) 유니티에서 흔히 등장하는 “리플렉션/문자열 호출” 패턴들

아래는 유니티 개발에서 많이 보이는 대표적인 문자열 기반 호출입니다. (직접 Reflection API를 쓰지 않더라도 결과적으로 비슷한 위험을 가집니다.)

1-1. SendMessage / BroadcastMessage

gameObject.SendMessage("OnDamage", 10f, SendMessageOptions.DontRequireReceiver);
gameObject.BroadcastMessage("OnReset");

문자열로 메서드 이름을 찾아 호출합니다.
컴파일 타임 체크가 없어서 오타가 런타임에야 터집니다.
성능상 비추천(특히 빈번 호출).

1-2. Invoke / InvokeRepeating

Invoke("SpawnEnemy", 2f);
InvokeRepeating("Tick", 1f, 0.2f);

내부적으로 문자열 기반으로 메서드를 찾습니다.
IL2CPP/스트리핑 상황에서 “찾을 메서드가 없어짐” 류 문제가 날 수 있습니다.

1-3. StartCoroutine("MethodName") / StopCoroutine("MethodName")

StartCoroutine("MyRoutine");
StopCoroutine("MyRoutine");

문자열 기반 코루틴은 직접 참조 방식보다 안전성과 유지보수성이 떨어집니다.
가능하면 아래처럼 바꾸는 게 정석입니다:
StartCoroutine(MyRoutine());

1-4. GetComponent("TypeName")

var rb = GetComponent("Rigidbody"); // 문자열로 타입 탐색

GetComponent<Rigidbody>()가 가능하면 항상 그쪽이 낫습니다.

2) “정통 리플렉션” API: GetField/GetProperty/Invoke

유니티에서 직접 System.Reflection을 써야 하는 경우도 있습니다(툴, 디버깅, 플러그인). 가장 흔한 형태는 아래입니다.

2-1. 필드(Field) 접근

using System.Reflection;

var flags = BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public;
FieldInfo fi = target.GetType().GetField("hp", flags);
int hp = (int)fi.GetValue(target);
fi.SetValue(target, hp + 10);

2-2. 프로퍼티(Property) 접근

using System.Reflection;

var flags = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;
PropertyInfo pi = target.GetType().GetProperty("Speed", flags);
float speed = (float)pi.GetValue(target);
pi.SetValue(target, speed * 1.1f);

2-3. 메서드(Method) 호출

using System.Reflection;

var flags = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;
MethodInfo mi = target.GetType().GetMethod("Recalculate", flags);
mi.Invoke(target, null);

3) 왜 IL2CPP(AOT)에서 문제가 더 자주 터지나?

3-1. 코드 스트리핑(Managed Stripping / Linker)

IL2CPP 빌드(특히 iOS)는 용량/로딩/보안을 위해 사용되지 않는 관리 코드를 제거합니다.
문제는 “문자열로만 호출되는 코드”는 정적 분석에서 사용된다고 확신할 수 없어서 제거될 수 있다는 점입니다.

에디터/Mono에서는 잘 되는데
기기(IL2CPP)에서만 MissingMethodException, 호출 실패, 동작 누락 같은 현상이 나옵니다.

3-2. 제네릭(generic)과 AOT 제약

IL2CPP는 런타임에 새 제네릭 인스턴스를 JIT로 만들 수 없습니다.
리플렉션으로 예측 불가능한 제네릭 조합을 만들거나 호출하려 하면, 특정 케이스에서 런타임 실패를 유발할 수 있습니다.

4) link.xml / [Preserve]는 “성능 최적화”가 아니라 “생존 장치”다

4-1. link.xml이 하는 일

link.xml은 빌드 단계에서 링커에게 “이 타입/메서드는 삭제하지 말라”고 지시합니다.

예시(Assets/link.xml):

<linker>
  <assembly fullname="Assembly-CSharp">
    <type fullname="MyNamespace.MyBehaviour" preserve="all"/>
  </assembly>
</linker>

✅ 해결: 스트리핑으로 인해 “메서드를 못 찾는” 문제
❌ 미해결: 리플렉션 호출이 느린 문제(탐색/메타데이터 접근 비용은 그대로)

4-2. [Preserve]가 하는 일

코드에 직접 보존 표시를 할 수 있습니다.

using UnityEngine.Scripting;

public class MyBehaviour : MonoBehaviour
{
    [Preserve]
    private void SpawnEnemy()
    {
        // Invoke("SpawnEnemy") 같은 문자열 호출을 쓴다면 보존 표시가 도움이 됩니다.
    }
}

5) 성능 관점: 리플렉션을 “안 느리게” 쓰는 방법(캐싱/델리게이트)

리플렉션이 느린 핵심은 보통 이렇습니다.

타입/멤버 탐색(GetMethod, GetProperty 등)
접근 제한/메타데이터 확인
박싱/언박싱
Invoke의 간접 호출 오버헤드

5-1. 멤버 탐색 결과를 캐싱하기

using System;
using System.Collections.Generic;
using System.Reflection;

public static class ReflectionCache
{
    private static readonly Dictionary<(Type, string), MethodInfo> _methodCache = new();

    public static MethodInfo GetMethodCached(Type t, string name, BindingFlags flags)
    {
        var key = (t, name);
        if (_methodCache.TryGetValue(key, out var mi)) return mi;

        mi = t.GetMethod(name, flags);
        _methodCache[key] = mi;
        return mi;
    }
}

“매번 찾는 비용”을 한 번으로 줄입니다.
그래도 Invoke 자체는 느립니다.

5-2. Delegate로 변환(가능하면 가장 효과적)

리플렉션으로 한 번 찾고, 이후부터는 델리게이트로 호출하면 오버헤드가 크게 줄어듭니다.

using System;
using System.Reflection;

public static class DelegateFactory
{
    public static Action CreateAction(object target, string methodName)
    {
        var flags = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;
        MethodInfo mi = target.GetType().GetMethod(methodName, flags);
        return (Action)Delegate.CreateDelegate(typeof(Action), target, mi);
    }
}

사용:

private Action _tick;

void Awake()
{
    _tick = DelegateFactory.CreateAction(this, "Tick");
}

void Update()
{
    _tick?.Invoke(); // 리플렉션 Invoke보다 훨씬 유리
}

private void Tick()
{
    // ...
}

주의: IL2CPP/AOT 환경에서는 CreateDelegate 조합이나 시그니처가 복잡해질수록 보존/제네릭 문제가 얽힐 수 있습니다.
“정말 매 프레임 호출해야 한다”면 구조적으로 리플렉션을 제거하는 쪽이 최선입니다.

6) 실무 규칙(추천)

6-1. 절대(에 가까운) 금지 구역

Update() / LateUpdate() / FixedUpdate()에서의 리플렉션/문자열 호출
대량 반복(수백~수천 회) 루프 안에서의 GetMethod/GetProperty/Invoke
SendMessage/BroadcastMessage 남발

6-2. 조건부 허용 구역(“가끔”이면 가능)

UI 버튼 클릭, 메뉴 열기, 설정 적용 같은 낮은 빈도 이벤트
디버그/치트/툴용 코드(릴리스에서 제외하거나 빈도 제한)
에디터 전용 도구(런타임이 아니라면 비교적 안전)

6-3. 모바일(IL2CPP)에서 안전장치 체크리스트

문자열/리플렉션으로만 호출되는 메서드/타입이 있나?
- 있다면 link.xml 또는 [Preserve] 적용
Managed Stripping Level이 Medium/High인가?
- 실제 기기에서 반드시 테스트
제네릭/런타임 타입 생성이 있나?
- IL2CPP 제약을 고려해 설계 변경 검토

7) 결론

link.xml / [Preserve]는 “코드가 사라지는 문제”를 막는 안전망입니다.
성능을 지키려면 리플렉션 자체를 빈도 높은 경로에서 제거하거나,
- 최소한 캐싱 + 델리게이트로 “탐색/Invoke 비용”을 낮추는 전략이 필요합니다.
“에디터 OK / 모바일만 Fail”은 대부분 스트리핑/IL2CPP 제약부터 의심하는 게 정석입니다.

부록) 빠른 치환 표

문제 코드	추천 대안
`StartCoroutine("MyRoutine")`	`StartCoroutine(MyRoutine())`
`Invoke("Spawn", 1f)`	`StartCoroutine(SpawnAfter(1f))` 또는 타이머/스케줄러
`GetComponent("Rigidbody")`	`GetComponent<Rigidbody>()`
`SendMessage("OnDamage")`	인터페이스/이벤트/델리게이트
반복적으로 `GetMethod(...).Invoke(...)`	1회 탐색 후 캐싱/델리게이트

[Unity\] On-Screen Stick 으로 모바일 조이스틱 구현하기

김치킨. — Sat, 20 Dec 2025 19:53:24 +0900

모바일 게임을 개발할 때 가장 먼저 부딪히는 난관 중 하나는 바로 이동 컨트롤입니다. 과거에는 Joystick Pack 같은 외부 에셋을 다운로드하거나, UI 터치 좌표를 계산하는 복잡한 코드를 직접 짜야 했습니다.

하지만 유니티의 New Input System이 등장하면서, 이제는 On-Screen Stick 컴포넌트 하나로 아주 손쉽게 가상 조이스틱을 구현할 수 있게 되었습니다.

오늘은 유니티 공식 기능을 활용해 깔끔하고 반응성 좋은 모바일 조이스틱을 만드는 방법을 알아보겠습니다.

1. 사전 준비 (Package 설치)

가장 먼저 프로젝트에 Input System 패키지가 설치되어 있어야 합니다.

Window > Package Manager를 엽니다.
Packages를 Unity Registry로 변경합니다.
Input System을 검색하여 Install 합니다.
(설치 후 에디터가 재시작될 수 있습니다. 경고창이 뜨면 'Yes'를 눌러주세요.)

2. UI 구성하기 (비주얼 만들기)

조이스틱은 눈에 보여야 하니 UI 이미지가 필요합니다.

Hierarchy 창에서 우클릭 > UI > Canvas를 생성합니다. (Canvas Scaler는 Scale With Screen Size로 설정하는 것을 추천합니다.)
Canvas 아래에 Empty Object를 만들고 이름을 Joystick이라고 짓습니다. (위치 잡기 용도)
Joystick 아래에 Image를 만들고 Background라고 합니다. (조이스틱 배경 원)
Background 아래에 Image를 만들고 Handle이라고 합니다. (움직이는 손잡이)

Tip: Background는 조금 크게, Handle은 그보다 작게 사이즈를 조절하고, 앵커(Anchor)를 활용하여 화면 좌측 하단에 적절히 배치하세요.

3. On-Screen Stick 컴포넌트 추가

이제 마법을 부릴 차례입니다. 실제로 움직이는 Handle 오브젝트에 기능을 부여합니다.

Hierarchy에서 Handle 이미지를 선택합니다.
Inspector에서 Add Component > On-Screen Stick을 검색해 추가합니다.
Movement Range를 조절합니다. (보통 50~100 사이가 적당합니다. Handle이 배경을 벗어나지 않게 설정하세요.)

4. Input Action 연결하기 (핵심!)

On-Screen Stick의 원리는 "화면의 터치 입력을 마치 게임패드의 스틱 입력인 것처럼 속여서 Input System에 전달하는 것"입니다.

1) Control Path 설정

Handle 오브젝트의 On-Screen Stick 컴포넌트로 돌아가서 Control Path를 설정합니다.

Control Path: Gamepad > Left Stick

2) Input Actions 생성 및 연결

Project 창에서 우클릭 > Create > Input Actions를 생성합니다. (이름 예시: GameControls)
생성된 에셋을 더블 클릭하여 편집 창을 엽니다.
Action을 하나 만들고 이름을 Move라고 짓습니다.
Action Type은 Value, Control Type은 Vector 2로 설정합니다.
Move 아래의 Binding(No Binding)을 지우고, +를 눌러 Add Binding을 선택합니다.
Binding의 Path를 Gamepad > Left Stick으로 설정합니다.

중요: On-Screen Stick 컴포넌트에서 설정한 Path와 Input Action의 Binding Path가 반드시 일치해야 작동합니다!

이제 Input System이 모바일 화면의 터치 조작을 게임패드의 왼쪽 스틱 입력으로 인식하게 됩니다. 기존에 게임패드 지원이 구현되어 있다면 코드를 수정할 필요 없이 즉시 작동합니다.

5. 캐릭터 움직이기 (스크립트 작성)

이제 입력값을 받아 캐릭터를 움직이는 간단한 스크립트를 작성해 봅시다.

using UnityEngine;
using UnityEngine.InputSystem; // 네임스페이스 필수

public class PlayerController : MonoBehaviour
{
    public float moveSpeed = 5f;
    private Vector2 moveInput;
    private Rigidbody2D rb;

    // Input Action 레퍼런스 (인스펙터에서 할당 필요)
    public InputActionReference moveAction;

    void Awake()
    {
        rb = GetComponent<Rigidbody2D>();
    }

    void OnEnable()
    {
        // 액션 활성화
        moveAction.action.Enable();
    }

    void OnDisable()
    {
        moveAction.action.Disable();
    }

    void Update()
    {
        // 입력값 읽어오기
        moveInput = moveAction.action.ReadValue<Vector2>();
    }

    void FixedUpdate()
    {
        // 물리 이동 처리
        rb.velocity = moveInput * moveSpeed;
    }
}

마무리 설정

플레이어 캐릭터에 위 스크립트를 추가합니다.

인스펙터의 Move Action 빈칸에, 아까 만든 Input Action Asset(GameControls) 내부의 Move 액션을 드래그해서 넣어줍니다.

게임을 실행하고 마우스(또는 터치)로 UI 핸들을 움직여 보세요!

마치며: 왜 On-Screen Stick인가?

직접 터치 좌표를 계산하는 방식(IDragHandler 등)도 좋지만, On-Screen Stick을 사용하면 다음과 같은 장점이 있습니다.

통합 관리: PC(키보드/패드)와 모바일(터치) 입력을 Input System 하나로 통합하여 관리할 수 있습니다.
간편함: 복잡한 UI 좌표 계산 로직을 작성할 필요가 없습니다.
유연함: 나중에 물리 컨트롤러(Xbox 패드 등)를 연결해도 별도의 코드 수정 없이 그대로 호환됩니다.

이제 복잡한 구현은 엔진에 맡기고, 여러분은 더 재미있는 콘텐츠를 만드는 데 집중하세요! ️`
```

[Unity] while 문 그만! Coroutine에서 '우아하게' 기다리기 : WaitUntil, WaitWhile

김치킨. — Sat, 20 Dec 2025 00:36:27 +0900

게임 로직을 짜다 보면 "특정 조건이 만족될 때까지 대기"해야 하는 상황이 정말 많이 발생합니다.

플레이어의 HP가 0이 될 때까지 대기
스페이스 바를 누를 때까지 대기
적들이 모두 사라질 때까지 대기

보통 우리는 Coroutine(코루틴)을 사용해 이 문제를 해결하는데요. 여러분은 이 코드를 어떻게 작성하고 계신가요? 오늘은 고전적인 방식과 유니티가 제공하는 조금 더 '우아한' 방식을 비교해 보겠습니다.

1. 고전적인 방식: `while` 루프와 `yield return null`

가장 흔하게 사용되는 패턴입니다. while 문으로 조건을 검사하고, 조건이 만족되지 않으면 yield return null을 통해 1 프레임을 쉬는 방식이죠.

예를 들어, 플레이어의 HP가 0 이하가 될 때까지 기다리는 코드는 보통 이렇게 작성합니다.

IEnumerator WaitForDeath_Classic()
{
    Debug.Log("전투 시작! 죽을 때까지 기다립니다...");

    // HP가 0보다 큰 동안 계속 루프를 돕니다.
    while (playerHP > 0)
    {
        // 1 프레임 대기 후 다시 조건을 검사합니다.
        yield return null; 
    }

    Debug.Log("플레이어 사망! 게임 오버 처리를 시작합니다.");
}

이 방식의 단점?

사실 기능상으로는 전혀 문제가 없습니다. 하지만:

가독성: while 문 안에 yield return null이 들어가는 구조가 매번 반복되어 코드가 길어집니다.
의도 파악: 코드를 읽을 때 "이 루프가 도대체 무엇을 기다리는 것인가?"를 파악하기 위해 루프 내부 로직을 해석해야 할 때가 있습니다.

2. 우아한 방식: `WaitUntil`과 `WaitWhile`

유니티는 이러한 패턴을 더 직관적으로 작성할 수 있도록 WaitUntil과 WaitWhile이라는 클래스를 제공합니다. 이들은 델리게이트(Delegate) 를 인자로 받아 조건을 판단합니다.

1) `WaitUntil`: 조건이 True가 될 때까지 대기

말 그대로 "~할 때까지(Until)" 기다리는 것입니다. 괄호 안의 조건이 true가 되면 대기를 멈추고 다음 줄로 넘어갑니다.

위의 while 문 코드를 리팩토링해 볼까요?

IEnumerator WaitForDeath_Elegant()
{
    Debug.Log("전투 시작! 죽을 때까지 기다립니다...");

    // 플레이어의 HP가 0 이하가 될 때(True)까지 대기합니다.
    yield return new WaitUntil(() => playerHP <= 0);

    Debug.Log("플레이어 사망! 게임 오버 처리를 시작합니다.");
}

단 한 줄로 줄어들었습니다!
() => playerHP <= 0 은 람다식(Lambda Expression)으로, "HP가 0 이하인가?"라는 조건을 실시간으로 체크합니다.

2) `WaitWhile`: 조건이 True인 동안 대기

이건 반대입니다. "~하는 동안(While)" 계속 기다리는 것입니다. 즉, 괄호 안의 조건이 false가 되어야 탈출합니다.

IEnumerator WaitForInput_Elegant()
{
    Debug.Log("키 입력을 기다리는 중...");

    // 스페이스 바를 누르지 않고 있는 동안(True) 계속 대기합니다.
    // 즉, 스페이스 바를 누르면(False) 대기가 끝납니다.
    yield return new WaitWhile(() => !Input.GetKeyDown(KeyCode.Space));

    Debug.Log("스페이스 바 입력 확인!");
}

3. 비교 및 요약

특징	고전 방식 (`while`)	우아한 방식 (`WaitUntil` / `WaitWhile`)
구문	`while(조건) { yield return null; }`	`yield return new WaitUntil(() => 조건);`
가독성	루프 구조로 인해 다소 김	영어 문장처럼 읽혀 직관적임
유연성	루프 내부에 추가 로직 넣기 쉬움	오직 '대기' 목적에 특화됨
성능	가비지 생성 없음	`new` 키워드로 인한 미세한 가비지 생성 (무시할 수준)

언제 무엇을 써야 할까?

단순히 "특정 상태가 변하길 기다리는 것"이 목적이라면 WaitUntil / WaitWhile을 쓰세요. 코드가 훨씬 깔끔해지고 "나는 지금 기다리는 중이다"라는 의도가 명확해집니다.
기다리는 동안 매 프레임 다른 연산(예: 타이머 카운트 다운, 로그 출력 등)을 같이 해야 한다면 기존의 while 문을 쓰는 것이 낫습니다.

마무리

코드는 컴퓨터가 읽는 글이기도 하지만, 동료(혹은 미래의 나)가 읽는 글이기도 합니다.
똑같은 기능을 하더라도 yield return new WaitUntil(() => isFinished);라고 적혀 있다면, 누구나 직관적으로 "아, 끝날 때까지 기다리는구나!"라고 이해할 수 있을 것입니다.

지금 작성 중인 코루틴에 불필요한 while 루프가 있다면, 오늘 한 번 리팩토링해 보는 건 어떨까요?

[Unity] Prefab Variant vs Nested Prefab

김치킨. — Thu, 18 Dec 2025 21:46:21 +0900

1. 한눈에 보는 차이점: 포함 vs 상속

가장 많이 하는 실수가 이 둘의 용도를 혼동하는 것입니다. 아래 표로 확실히 정리해 드립니다.

핵심 개념	포함 (Composition)	상속 (Inheritance)
관계	"A Has a B" (A는 B를 가지고 있다)	"B Is a A" (B는 A의 일종이다)
예시	자동차는 바퀴를 가지고 있다.	스포츠카는 자동차의 일종이다.
아이콘	일반 파란색 큐브	화살표가 있는 큐브 아이콘
주 사용처	씬 구성, 복합 오브젝트 조립 (건물, UI 패널)	데이터 변형이 필요한 개체 (적 캐릭터, 아이템)

2. 실전 전략: 두 기능을 섞어 쓰기 (The Killer Combo) ⚔️

고수들은 이 두 가지를 따로 쓰지 않고 함께 사용합니다. RPG 게임의 아이템 시스템을 예로 들어보겠습니다.

단계 1: Nested Prefab으로 '부품' 만들기

먼저 게임에 쓰일 시각적 이펙트나 공통 UI를 만듭니다.

SparkleEffect (프리팹)
ItemLabelUI (프리팹)

단계 2: Base Prefab 만들기

모든 아이템의 조상이 될 기본 프리팹을 만듭니다. 여기에 단계 1의 프리팹을 Nested 시킵니다.

Item_Base (프리팹)
- 모델링 (Placeholder)
- SparkleEffect (Nested Prefab)
- ItemLabelUI (Nested Prefab)

단계 3: Prefab Variant로 '파생' 상품 만들기

Item_Base를 우클릭하여 Create > Prefab Variant를 선택해 실제 아이템들을 만듭니다.

Sword_Fire (Variant): Item_Base 상속 + 빨간색 모델링 교체 + 공격력 100
Shield_Ice (Variant): Item_Base 상속 + 파란색 모델링 교체 + 방어력 50

결과적으로 얻는 이득

나중에 기획자가 *"모든 아이템 먹을 때 반짝이는 효과(SparkleEffect)를 좀 더 화려하게 바꿔주세요!"* 라고 요청한다면?

SparkleEffect 프리팹 하나만 수정합니다.
이것이 포함된 Item_Base에 반영됩니다. (Nested 덕분)
Item_Base를 상속받은 Sword_Fire, Shield_Ice 등 수백 개의 아이템이 동시에 수정됩니다. (Variant 덕분)

3. 주의할 점 (Best Practices)

Variant의 Variant는 신중하게:
Base -> Variant A -> Variant A-1 처럼 상속이 너무 깊어지면, 나중에 수정 사항이 어디서 덮어씌워졌는지(Override) 파악하기 힘듭니다. 1~2단계 상속을 권장합니다.
이름 규칙 정하기:
프로젝트 뷰에서 헷갈리지 않도록 Base 프리팹에는 _Base나 _Master 같은 접미사를 붙여 원본임을 명시하는 것이 좋습니다.

마치며

Nested Prefab은 "조립"을 위해,
Prefab Variant는 "변형"을 위해 사용하세요.

이 두 가지 무기를 적재적소에 활용한다면, 수정 사항이 발생했을 때 야근하지 않고 "클릭 한 번"으로 해결하는 쾌거를 맛보실 수 있을 것입니다..

태그: #Unity #PrefabVariant #NestedPrefab #유니티강좌 #객체지향

[Unity] 프리팹 안의 프리팹 : Nested Prefab (중첩 프리팹)

김치킨. — Thu, 18 Dec 2025 21:44:52 +0900

안녕하세요! 유니티로 게임을 개발하다 보면 '프리팹(Prefab)'은 떼려야 뗄 수 없는 존재입니다. 하지만 혹시, 프리팹 안에 다른 프리팹을 넣었다가 수정 사항이 반영되지 않아 고생했던 기억, 없으신가요?

과거(Unity 2018.3 이전)에는 프리팹 안에 다른 프리팹을 넣으면 그 연결 고리가 끊어져 버리는 악몽 같은 문제가 있었습니다. 하지만 Nested Prefab(중첩 프리팹) 시스템이 도입되면서 개발 환경은 완전히 달라졌습니다.

오늘은 유니티 개발의 생산성을 200% 올려주는 Nested Prefab에 대해 아주 쉽게 정리해 드립니다.

1. Nested Prefab이란 무엇인가요?

간단히 말해 "프리팹 안에 들어있는 또 다른 프리팹"을 의미합니다.

과거에는 '집(House)' 프리팹 안에 '의자(Chair)' 프리팹을 넣는 순간, '의자'는 더 이상 독립적인 프리팹이 아니게 되었습니다. 단순히 복사된 데이터 덩어리가 되어버렸죠. 그래서 원본 '의자' 프리팹을 수정해도 '집' 안에 있는 의자는 바뀌지 않았습니다.

하지만 Nested Prefab 시스템 하에서는:

'집' 프리팹 안에 '의자' 프리팹을 넣어도 '의자'의 원본 링크가 유지됩니다.
원본 '의자' 디자인을 바꾸면, '집' 안에 있는 의자도 자동으로 바뀝니다.

2. 왜 써야 할까요? (강력한 장점)

Nested Prefab을 잘 활용하면 게임 구조가 레고 블록처럼 모듈화(Modular)됩니다.

✅ 모듈형 작업 가능

거대한 맵이나 UI를 하나의 통짜 프리팹으로 만들지 않아도 됩니다.

UI: 버튼 프리팹 -> 팝업창 프리팹 -> HUD 프리팹
환경: 나무 프리팹 -> 숲 프리팹 -> 전체 맵 씬

각각의 작은 부품(프리팹)만 수정하면, 이를 포함하는 모든 상위 프리팹에 자동으로 변경 사항이 전파됩니다.

✅ 협업 효율 증대

이 기능은 팀 프로젝트에서 빛을 발합니다.

아티스트 A: '무기' 모델링과 이펙트를 수정합니다.
기획자 B: 해당 무기를 들고 있는 '캐릭터'의 스탯을 조정합니다.

두 프리팹이 분리되어 있으면서도 중첩되어 작동하기 때문에, 서로의 작업물을 덮어쓰지 않고 병렬로 작업할 수 있습니다.

3. 핵심 기능: Overrides (오버라이드)

Nested Prefab의 꽃은 바로 Overrides 기능입니다.
상위 프리팹(Parent) 안에서 하위 프리팹(Child)의 일부 속성만 '살짝' 바꾸고 싶을 때 사용합니다.

예시:
기본 '병사' 프리팹이 있습니다. 이 병사를 '부대' 프리팹 안에 10명 배치했습니다. 대장 병사 한 명만 빨간색 투구를 씌우고 싶다면?

'부대' 프리팹 편집 모드로 들어갑니다.
대장 병사의 투구 색을 빨간색으로 변경합니다.
이 변경 사항은 이 특정 병사에게만 적용(Override)되며, 원본 '병사' 프리팹은 그대로 유지됩니다.

인스펙터 창에서 변수 이름이 굵은 글씨(Bold)로 표시되거나, 왼쪽에 파란색 선이 생긴다면 그 부분은 오버라이드 되었다는 뜻입니다.

Revert: 오버라이드한 내용을 취소하고 원본 프리팹 값으로 되돌립니다.
Apply: 변경한 내용을 원본 프리팹에 덮어씌웁니다. (주의: 이 경우 모든 병사의 투구가 빨간색이 됩니다!)

4. 실무 활용 팁 & 주의사항

1) Prefab Mode(프리팹 모드)를 적극 활용하세요

하이어라키(Hierarchy)에서 프리팹 옆의 작은 화살표(>)를 누르면 해당 프리팹만 독립적으로 편집할 수 있는 Prefab Mode로 진입합니다. 씬이 복잡할 때 이 모드에서 작업하면 실수로 다른 오브젝트를 건드리는 일을 방지할 수 있습니다.

2) 너무 깊은 중첩(Deep Nesting)은 피하세요

나사 < 바퀴 < 자동차 < 차고 < 마을 < 도시 처럼 너무 깊게 중첩하면, 나중에 수정 사항이 어디서 오버라이드 되었는지 추적하기 힘들어질 수 있습니다. 3~4단계 정도의 깊이를 유지하는 것이 정신건강에 좋습니다.

3) Prefab Variant(프리팹 변형)와 함께 쓰세요

Nested Prefab과 짝꿍인 기능이 Prefab Variant입니다.

Nested: 포함 관계 (A 안에 B가 있다)
Variant: 상속 관계 (A를 기반으로 만든 A')

기본 '몬스터' 프리팹을 만들고, 이를 상속받아 '불 몬스터', '얼음 몬스터' Variant를 만드세요. 그리고 이들을 '던전' 프리팹 안에 Nested 시키면 완벽한 구조가 됩니다.

마치며

Nested Prefab은 유니티가 제공하는 가장 강력한 워크플로우 개선 기능 중 하나입니다. 이 기능을 제대로 이해하고 구조를 짠다면, 나중에 게임의 규모가 커져도 유지 보수가 훨씬 쉬워질 것입니다.

오늘 당장 여러분의 프로젝트에서 반복되는 요소들을 쪼개고, 중첩시켜 보세요! ️

태그: #Unity #유니티 #게임개발 #NestedPrefab #프리팹 #개발꿀팁

[Unity] 프리팹 간에 상속이 가능하다고? Prefab Variant 활용법

김치킨. — Thu, 11 Dec 2025 10:54:00 +0900

객체 지향 프로그래밍(OOP)에서 클래스 상속(Inheritance)은 코드의 재사용성을 높이는 핵심 개념입니다. 유니티의 Prefab Variant(프리팹 바리언트)를 사용하면, 게임 오브젝트(Prefab) 단계에서도 이 상속의 이점을 그대로 누릴 수 있습니다.

단순 복제(Ctrl+D)로 인해 발생하는 유지보수의 문제를 해결하고, 효율적으로 프리팹을 계층화하는 방법을 소개합니다.

1. 프리팹의 상속 개념 (Duplicate vs Variant)

유니티에서 프리팹을 기반으로 새로운 프리팹을 만들 때는 두 가지 방식이 존재합니다.

단순 복제 (Duplicate, Ctrl+D)
- 원본과 완전히 독립된 개체가 됩니다.
- 원본이 수정되어도 복제본에는 아무런 영향을 주지 않습니다.
- 비유: 코드를 복사해서 새 파일(ClassB.cs)을 만드는 것.
프리팹 바리언트 (Prefab Variant)
- 원본(Base)을 부모로 하는 자식 프리팹을 생성합니다.
- 부모가 수정되면 자식에게도 변경 사항이 자동 반영됩니다.
- 비유: class Child : Parent 처럼 상속받는 것.

2. 구현 시나리오: 몬스터 시스템

목표: 기본형 몬스터(Zombie_Base)를 만들고, 이를 상속받아 화염 속성(Zombie_Red)과 빙결 속성(Zombie_Blue) 몬스터를 구현한다.

기존 방식 (Duplicate)의 문제점

Zombie_Base를 복사해서 Zombie_Red를 만듦.
개발 후반부에 좀비의 기본 이동 속도가 너무 느려 Zombie_Base를 수정함.
결과: Zombie_Red는 업데이트되지 않음. 수십 종류의 파생 좀비들을 일일이 찾아가서 똑같은 값을 수정해야 함.

상속 방식 (Variant)의 해결책

프로젝트 창에서 Zombie_Base 우클릭 -> Create > Prefab Variant 선택.
생성된 Zombie_Red는 Base의 모든 컴포넌트와 설정을 상속받음.
Zombie_Red에만 화염 공격 스크립트를 추가하거나 외형을 변경.
결과: 추후 Zombie_Base의 이동 속도를 수정하면, 모든 파생 좀비(Variant)들의 속도가 자동으로 일괄 변경됨.

3. 설계 구조

프리팹 상속을 활용하면 다음과 같은 구조로 데이터를 관리할 수 있습니다.

계층	역할	포함 요소 (컴포넌트)
Parent (Base)	공통 로직 정의	`MonsterAI`, `Animator`, `Collider`, `Rigidbody`
Child (Variant)	개별 기능 확장	부모 요소 + `FireAttack`, `IceEffect` (추가 컴포넌트)
Instance	개별 수치 조정	변수 값 변경 (HP, Speed 등)

4. 핵심 기능: 오버라이드(Override)와 리버트(Revert)

상속받은 자식 프리팹은 부모의 속성을 따르지만, 필요시 특정 값만 재정의할 수 있습니다.

Override (재정의):
- Variant에서 특정 변수(예: Max HP) 값을 변경하면, 해당 속성은 부모와의 연결이 끊깁니다.
- 인스펙터에서 굵은 글씨(Bold)나 파란색 띠로 표시됩니다.
- 이후 부모의 HP가 변경되어도, 이 Variant는 재정의된 독자적인 값을 유지합니다.
Revert (되돌리기):
- 재정의했던 값을 다시 부모의 설정과 동기화하고 싶을 때 사용합니다.
- 변경된 변수 우클릭 -> Revert 선택.

5. 협업 시 식별 가이드

팀 프로젝트 진행 시, 프리팹 아이콘과 인스펙터만 확인하면 상속 관계를 파악할 수 있습니다.

1) 아이콘 확인

일반 프리팹 (Parent): 파란색 육면체.
프리팹 바리언트 (Child): 아이콘 한쪽 면이 회색.

2) 인스펙터 확인

Variant를 선택하면 인스펙터 최상단 헤더에 Prefab Variant라고 명시되어 있습니다.
Open 버튼 옆 계층 구조를 통해 부모가 누구인지 확인할 수 있습니다.

3) 부모 수정 시 주의사항 (Find References)

일반 프리팹처럼 보여도 다른 프리팹의 부모일 수 있습니다.
수정 전 우클릭 -> Find References In Project를 실행하여, 이를 상속받고 있는 다른 프리팹이 있는지 확인하는 습관이 중요합니다.

요약

반복되는 구조는 상속하라: 유사한 오브젝트는 복사(Duplicate)하지 말고 Variant를 사용하세요.
계층적 설계: 공통 기능은 부모 프리팹에, 특수 기능은 자식 프리팹에 구현하세요.
유연한 변경: 부모를 수정하여 전체를 제어하고, 자식에서 Override하여 개성을 부여하세요.

Unity에서 `MonoBehaviour`를 `new`로 만들면 무슨 일이 일어날까?

김치킨. — Tue, 21 Oct 2025 17:11:53 +0900

Unity 개발 중 MonoBehaviour를 만들 때, 보통은 AddComponent<T>()를 사용합니다.
그런데 혹시 new 키워드로 MonoBehaviour를 직접 생성하면 어떤 일이 일어날까요?

이 글에서는 MonoBehaviour를 AddComponent로 만든 경우와 new로 만든 경우의 차이점을
동작, 구조, 런타임 관점에서 자세히 살펴보겠습니다.

1. `MonoBehaviour`는 일반 C# 클래스가 아니다

MonoBehaviour는 단순한 C# 객체가 아니라,
Unity 엔진(C++) 쪽 객체와 C# 객체가 연결된 하이브리드 구조입니다.

즉,

C# 객체: 우리가 코드에서 접근하고 조작하는 부분
Unity 네이티브 객체: Unity 엔진 내부에서 실제로 관리되는 GameObject 컴포넌트

따라서 new 키워드로 생성하면 엔진 쪽 네이티브 객체가 전혀 생성되지 않습니다.
이게 핵심입니다.

2. 잘못된 생성 방식 — `new`

TempObj obj = new TempObj(); // ❌ 잘못된 방식

이렇게 생성하면 C# 입장에서는 객체가 생기지만,
Unity는 그 존재를 전혀 모릅니다.

즉, 이 객체는 C# 힙에만 존재하는 유령 객체이며,
Unity 씬 어디에도 연결되지 않습니다.

✅ 3. 올바른 생성 방식 — `AddComponent`

TempObj obj = gameObject.AddComponent<TempObj>(); // ✅ 올바른 방식

AddComponent를 사용하면 Unity가 다음 과정을 자동으로 수행합니다.

C# 객체를 생성
Unity 네이티브 객체를 생성
둘을 연결하여 관리 시작
Awake(), Start(), Update() 등의 생명주기 함수를 호출

즉, 이 방법만이 MonoBehaviour를 Unity 엔진이 인식할 수 있는 상태로 등록하는 방법입니다.

⚙️ 4. 실제 차이점 비교

항목	`AddComponent`로 생성	`new`로 생성
GameObject 연결	✅ 연결됨	❌ 연결 안 됨
Unity 네이티브 객체	✅ 존재함	❌ 없음
`gameObject`, `transform`	✅ 유효	❌ null
`Awake()`, `Start()`	✅ 정상 호출	❌ 호출 안 됨
Hierarchy 창 표시	✅ 표시됨	❌ 안 보임
Inspector 표시	✅ 가능	❌ 불가능
`Destroy()` 작동	✅ 작동함	❌ 무효
메모리 관리	Unity + GC	C# GC만 관리
실질적 유효성	엔진 관리 중인 정상 객체	엔진에 등록되지 않은 유령 객체

5. 예시: `new`로 만든 객체의 동작

TempObj obj = new TempObj();

if (obj != null)
{
    Debug.Log("obj는 null이 아닙니다."); // ✅ 출력됨
    Debug.Log(obj.transform.position);   // ❌ NullReferenceException 발생
}

obj != null 은 참입니다.
(C# 상에서 분명히 객체가 존재하기 때문입니다.)
하지만 obj.transform 은 Unity 네이티브 객체가 없기 때문에 null이며,
접근 시 예외가 발생합니다.

즉, 살아는 있지만 엔진과 연결되지 않은 유령 객체입니다.

6. `AddComponent`로 생성된 객체인지 구분하는 방법

Unity 엔진에 실제로 등록된 컴포넌트인지 확인하려면
아래와 같이 검사하면 됩니다.

if (obj != null && obj.gameObject != null)
{
    Debug.Log("✅ Unity에 등록된 실제 컴포넌트입니다.");
}
else
{
    Debug.Log("❌ new로 만들어진 유령 객체입니다.");
}

gameObject 프로퍼티는 Unity 네이티브 객체가 연결될 때 자동으로 채워지는 필드이므로,
이 값이 null이라면 AddComponent로 생성된 객체가 아닙니다.

7. 요약

구분	설명
`new` 로 생성	C# 객체만 존재. Unity는 모름
`AddComponent` 로 생성	Unity 네이티브 객체와 연결되어 엔진이 관리
`gameObject`, `transform`	AddComponent 객체에서만 유효
`Destroy()`	Unity 관리 객체에서만 작동
판별 코드	`if (obj != null && obj.gameObject != null)`

결론

MonoBehaviour는 단순한 C# 클래스가 아니라
Unity 엔진이 관리하는 컴포넌트입니다.

new로 생성하면 Unity 세계에서는 존재하지 않는 유령 객체가 됩니다.

✅ 따라서 MonoBehaviour를 만들 때는 반드시 AddComponent<T>()를 사용해야 합니다.

참고

만약 순수 데이터나 로직만 다루는 클래스라면
MonoBehaviour 대신 그냥 일반 클래스나 ScriptableObject를 사용하는 것이 적절합니다.

public class TempData // MonoBehaviour 제거
{
    public int hp;
}

// 이렇게 안전하게 생성 가능
TempData data = new TempData();

한 줄 요약:

MonoBehaviour는 Unity 엔진이 관리하는 컴포넌트다.
new로 만들면 유령 객체가 되고, AddComponent()로만 정상적으로 작동한다.

Unity Vector2.Reflect 함수 완벽 가이드

김치킨. — Sun, 24 Aug 2025 02:15:35 +0900

게임 속 물리 계산이나 충돌 처리에서 중요한 개념 중 하나가 바로 "반사"입니다. 예를 들어, 공이 벽에 튕겨 나가거나, 레이캐스트가 표면에 맞고 반사되는 경우를 구현할 때 유용합니다. Unity에서는 이런 상황을 쉽게 처리할 수 있도록 Vector2.Reflect 함수를 제공합니다.

1. 기본 정의


public static Vector2 Reflect(Vector2 inDirection, Vector2 inNormal);

inDirection : 진행 중인 벡터(예: 공의 이동 방향)
inNormal : 맞닿은 표면의 법선 벡터(normal)
반환값 : 반사된 새로운 방향 벡터

즉, 특정 표면에 어떤 방향 벡터가 부딪혔을 때, 그 표면을 기준으로 대칭된 방향을 계산해서 돌려줍니다.

2. 방향 벡터와 법선 벡터란?

Vector2.Reflect를 이해하려면 두 가지 개념을 알아야 합니다.

(1) 방향 벡터 (Direction Vector)

객체가 어느 쪽으로 움직이고 있는지를 나타내는 벡터입니다. 예를 들어, 공이 오른쪽 아래로 굴러가고 있다면 방향 벡터는 (1, -1)이 됩니다.


Vector2 dir = new Vector2(1, -1); // 오른쪽 아래 방향

(2) 법선 벡터 (Normal Vector)

표면에 수직으로 뻗은 벡터를 의미합니다. - 바닥(수평면)의 법선은 (0, 1) (위쪽) - 오른쪽 벽(수직면)의 법선은 (-1, 0) (왼쪽)


Vector2 normal = Vector2.up; // 바닥 표면의 법선

즉, 방향 벡터는 “움직이는 방향”, 법선 벡터는 “표면이 바라보는 방향”이라고 이해하면 쉽습니다.

3. 수학적 원리

벡터 반사는 수학적으로 이렇게 정의됩니다:


R = D - 2 * (D · N) * N

D : 진행 방향 벡터 (inDirection)
N : 단위(normalized) 법선 벡터 (inNormal)
R : 반사된 결과 벡터

즉, 법선 방향으로의 성분을 빼서, 반대쪽으로 튕겨낸 것이 반사 벡터입니다. Unity의 Vector2.Reflect는 이 계산을 대신 해줍니다.

4. 간단한 예시


Vector2 dir = new Vector2(1, -1).normalized; // 오른쪽 아래로 이동
Vector2 normal = Vector2.up;                 // 위쪽(0,1) 법선

Vector2 reflected = Vector2.Reflect(dir, normal);
// 결과: (1, 1) → 오른쪽 위 방향

아래쪽으로 향하던 벡터가 바닥에 맞아, 위쪽으로 튀어 나가는 결과가 계산됩니다.

5. 활용 사례

(1) 공 튀기기


void OnCollisionEnter2D(Collision2D collision) {
    Vector2 inDir = rigidbody2D.velocity;
    Vector2 normal = collision.contacts[0].normal;
    rigidbody2D.velocity = Vector2.Reflect(inDir, normal);
}

공이 벽에 부딪힐 때 속도를 반사시켜, 튕기는 효과를 줍니다.

(2) 레이 반사


RaycastHit2D hit = Physics2D.Raycast(origin, direction);
if (hit.collider != null) {
    Vector2 reflectedDir = Vector2.Reflect(direction, hit.normal);
    Debug.DrawRay(hit.point, reflectedDir * 5, Color.red);
}

레이가 벽에 맞으면 반사된 방향을 계산하고, 그 결과를 디버그로 시각화할 수 있습니다.

(3) 탄알 반사

총알이나 빛줄기가 벽에 맞고 튀는 효과를 구현할 때 간단히 쓸 수 있습니다.

6. 주의할 점

법선 벡터는 반드시 단위 벡터(normalized)여야 올바른 결과가 나옵니다.
Unity의 충돌 정보 collision.contacts[0].normal은 이미 단위 벡터라 바로 사용할 수 있습니다.
Vector2.Reflect는 방향만 계산하므로, 속도의 크기(스피드)는 별도로 유지하거나 조절해야 합니다.

7. 결론

Vector2.Reflect는 2D 게임에서 벽 튕김, 레이 반사, 시야 연출 등 다양한 곳에서 활용할 수 있는 간단하면서도 강력한 함수입니다. 핵심은 방향 벡터 = 움직이는 방향, 법선 벡터 = 표면이 바라보는 방향이라는 개념을 이해하는 것입니다. 이 원리만 알면, 반사 효과를 아주 쉽게 구현할 수 있습니다.

Unity Mathf.Lerp 함수 완벽 가이드

김치킨. — Sat, 23 Aug 2025 16:54:29 +0900

게임에서 자연스럽게 값이 변하거나 점점 다가가는 느낌을 줄 때 자주 사용하는 함수가 있습니다. 바로 Mathf.Lerp 입니다. 예를 들어, 카메라가 부드럽게 이동하거나 UI 값이 서서히 변할 때 이 함수를 활용하면 간단하게 구현할 수 있습니다.

1. 기본 정의

Mathf.Lerp 함수는 다음과 같이 정의됩니다:


public static float Lerp(float a, float b, float t);

a : 시작 값
b : 목표 값
t : 보간 계수(0 ~ 1 사이의 값 권장)

t가 0일 때는 a, 1일 때는 b를 반환합니다. 0과 1 사이 값에서는 a와 b 사이의 중간 값을 계산해 줍니다.

2. 동작 예시


// 0과 10 사이에서 절반 지점
float value = Mathf.Lerp(0f, 10f, 0.5f); 
// 결과: 5f


// 속도 값 보간
float speed = Mathf.Lerp(5f, 20f, 0.25f); 
// 결과: 8.75f

보간 계수 t의 의미와 변화

Mathf.Lerp(a, b, t)에서 t는 두 값 사이에서 몇 퍼센트나 이동했는지를 나타냅니다.

t = 0 → 결과는 시작값 a
t = 1 → 결과는 목표값 b
0 < t < 1 → a와 b 사이의 중간 값

예: a=0, b=10일 때

t 값	결과	설명
0.0	0	시작점 그대로
0.25	2.5	25% 이동
0.5	5	절반 지점
0.75	7.5	75% 이동
1.0	10	목표값

즉, t가 조금씩 커질수록 결과 값도 일정한 속도로 바뀌게 됩니다. 그래서 UI, 카메라, 색상 변화 등에서 부드럽고 예측 가능한 전환을 구현할 수 있습니다.

3. 왜 부드럽게 변화할까?

사실 Mathf.Lerp 자체는 단순히 “t에 따라 하나의 값”을 계산해 주는 함수일 뿐입니다. 그런데 게임에서는 이 함수를 매 프레임마다 계속 호출하면서 t를 바꿔주기 때문에, 값이 조금씩 이어지면서 변화하고, 그 결과 화면에는 부드럽게 움직이는 것처럼 보입니다.

(1) 일정 시간 동안 점점 이동


float elapsed = 0f;
float duration = 2f;
float start = 0f, end = 10f;

void Update() {
    elapsed += Time.deltaTime;
    float t = Mathf.Clamp01(elapsed / duration);
    float value = Mathf.Lerp(start, end, t);
}

- 처음에는 0에서 시작해, 2초 동안 점점 커지다가 끝에서 10에 도달합니다. - 이렇게 시간에 따라 t를 계산하면, 값이 서서히 바뀌어 보이게 됩니다.

(2) 목표 값에 천천히 다가가기


current = Mathf.Lerp(current, target, Time.deltaTime * speed);

- 여기서는 매 프레임마다 현재 값이 목표 값 쪽으로 조금씩 이동합니다. - 처음에는 빠르게 움직이다가 목표에 가까워질수록 속도가 줄어들면서 “서서히 멈추는 듯한” 느낌을 줍니다. - 이 패턴 덕분에 체력바, UI 슬라이더, 카메라 이동 등에서 자연스럽게 다가가는 효과를 쉽게 만들 수 있습니다.

4. 주요 활용 사례

(1) 부드러운 이동


transform.position = new Vector3(
    Mathf.Lerp(transform.position.x, target.x, 0.1f),
    Mathf.Lerp(transform.position.y, target.y, 0.1f),
    Mathf.Lerp(transform.position.z, target.z, 0.1f)
);

- 매 프레임마다 조금씩 움직여 자연스러운 이동을 구현합니다.

(2) UI 애니메이션


float alpha = Mathf.Lerp(0f, 1f, t);
canvasGroup.alpha = alpha;

- UI가 점점 투명 → 불투명으로 변하도록 할 수 있습니다.

(3) 체력바 게이지 변화


hpBar.fillAmount = Mathf.Lerp(hpBar.fillAmount, targetHP, Time.deltaTime * speed);

- 체력 게이지가 순간적으로 튀지 않고 부드럽게 줄거나 차오릅니다.

5. Lerp와 Time.deltaTime

Lerp를 사용할 때 자주 쓰이는 방식은 Time.deltaTime을 곱하는 것입니다. 이렇게 하면 프레임 속도와 관계없이 비슷한 체감 속도로 움직이는 효과를 줄 수 있습니다.


currentValue = Mathf.Lerp(currentValue, targetValue, Time.deltaTime * 5f);

6. 주의할 점

Lerp는 내부적으로 t 값을 0~1 범위 안에 맞추는 것이 기본입니다.
만약 그 범위를 넘어선 값까지 계산하고 싶다면 Mathf.LerpUnclamped를 사용하세요.


float safe = Mathf.Lerp(a, b, Mathf.Clamp01(t));     // 안전하게 0~1
float over = Mathf.LerpUnclamped(a, b, 1.2f);        // 목표를 넘어선 값도 계산

7. 결론

Mathf.Lerp는 Unity에서 값을 자연스럽게 변화시키는 가장 기본적인 도구입니다. 핵심은 함수 자체가 아니라, 시간의 흐름에 맞춰 t를 바꿔주고 반복 호출

Unity Mathf.Clamp 함수 완벽 가이드

김치킨. — Sat, 23 Aug 2025 16:37:21 +0900

게임 개발을 하다 보면, 값이 특정 범위를 벗어나지 않도록 제한해야 할 때가 자주 있습니다. 예를 들어 플레이어 체력(HP) 은 0보다 작아지면 안 되고, 최대 체력을 넘어가서도 안 됩니다. 이럴 때 바로 유용하게 쓰이는 함수가 Mathf.Clamp 입니다.

1. 기본 정의

Mathf.Clamp 함수는 다음과 같이 정의됩니다:

public static float Clamp(float value, float min, float max);

value : 제한할 대상 값

min : 최소 허용 값

max : 최대 허용 값

즉, value가 min보다 작으면 min을 반환하고, max보다 크면 max를 반환합니다. 범위 안에 있다면 그대로 반환합니다.

2. 동작 예시

float hp = 120f; hp = Mathf.Clamp(hp, 0f, 100f); // 결과: 100f

float speed = -5f; speed = Mathf.Clamp(speed, 0f, 10f); // 결과: 0f

float volume = 0.7f; volume = Mathf.Clamp(volume, 0f, 1f); // 결과: 0.7f (변화 없음)

3. 오버로드(정수 지원)

Mathf.Clamp는 float뿐만 아니라 int 버전도 있습니다.

public static int Clamp(int value, int min, int max);

정수 값의 범위를 제한할 때도 동일하게 활용할 수 있습니다.

4. 활용 사례

(1) 플레이어 체력 관리

currentHP = Mathf.Clamp(currentHP, 0, maxHP);

체력이 0 미만으로 내려가도 자동으로 0에 맞춰짐

회복 아이템을 사용해도 maxHP를 넘지 않음

(2) 이동 속도 제한

moveSpeed = Mathf.Clamp(moveSpeed, minSpeed, maxSpeed);

- 캐릭터가 지나치게 느려지거나 빨라지는 현상 방지

(3) UI 슬라이더 값 제한

sliderValue = Mathf.Clamp(sliderValue, 0f, 1f);

- 항상 0~1 범위 내 값만 유지 (볼륨, 밝기 등)

5. Mathf.Clamp01 와의 비교

Unity는 자주 쓰이는 0~1 범위 제한을 위한 별도 함수도 제공합니다.

float normalized = Mathf.Clamp01(value);

value가 0 미만 → 0 반환

value가 1 초과 → 1 반환

0~1 사이 값은 그대로 반환

주로 정규화(normalization) 나 Lerp 보간 값을 처리할 때 자주 사용됩니다.

6. 주의할 점

min 값이 max보다 크면 모든 경우에 max를 반환합니다.

항상 min ≤ max 관계가 보장되도록 코드를 짜는 습관이 필요합니다.

7. 결론

Mathf.Clamp는 간단하지만, 게임 개발에서 굉장히 자주 사용되는 안전장치 함수입니다. 체력, 속도, 카메라 이동, UI 값 등 범위를 제한해야 하는 모든 상황에 적용할 수 있으니, 습관적으로 활용하는 것이 좋습니다.

김치킨 님의 블로그

[Unity/C#] 리플렉션은 왜 느리고, 왜 IL2CPP에서 위험한가

0) 한 줄 요약

1) 유니티에서 흔히 등장하는 “리플렉션/문자열 호출” 패턴들

1-1. SendMessage / BroadcastMessage

1-2. Invoke / InvokeRepeating

1-3. StartCoroutine("MethodName") / StopCoroutine("MethodName")

1-4. GetComponent("TypeName")

2) “정통 리플렉션” API: GetField/GetProperty/Invoke

2-1. 필드(Field) 접근

2-2. 프로퍼티(Property) 접근

2-3. 메서드(Method) 호출

3) 왜 IL2CPP(AOT)에서 문제가 더 자주 터지나?

3-1. 코드 스트리핑(Managed Stripping / Linker)

3-2. 제네릭(generic)과 AOT 제약

4) link.xml / [Preserve]는 “성능 최적화”가 아니라 “생존 장치”다

4-1. link.xml이 하는 일

4-2. [Preserve]가 하는 일

5) 성능 관점: 리플렉션을 “안 느리게” 쓰는 방법(캐싱/델리게이트)

5-1. 멤버 탐색 결과를 캐싱하기

5-2. Delegate로 변환(가능하면 가장 효과적)

6) 실무 규칙(추천)

6-1. 절대(에 가까운) 금지 구역

6-2. 조건부 허용 구역(“가끔”이면 가능)

6-3. 모바일(IL2CPP)에서 안전장치 체크리스트

7) 결론

부록) 빠른 치환 표

[Unity\] On-Screen Stick 으로 모바일 조이스틱 구현하기

1. 사전 준비 (Package 설치)

2. UI 구성하기 (비주얼 만들기)

3. On-Screen Stick 컴포넌트 추가

4. Input Action 연결하기 (핵심!)

1) Control Path 설정

2) Input Actions 생성 및 연결

5. 캐릭터 움직이기 (스크립트 작성)

마치며: 왜 On-Screen Stick인가?

[Unity] while 문 그만! Coroutine에서 '우아하게' 기다리기 : WaitUntil, WaitWhile

1. 고전적인 방식: while 루프와 yield return null

이 방식의 단점?

2. 우아한 방식: WaitUntil과 WaitWhile

1) WaitUntil: 조건이 True가 될 때까지 대기

2) WaitWhile: 조건이 True인 동안 대기

3. 비교 및 요약

언제 무엇을 써야 할까?

마무리

[Unity] Prefab Variant vs Nested Prefab

1. 한눈에 보는 차이점: 포함 vs 상속

2. 실전 전략: 두 기능을 섞어 쓰기 (The Killer Combo) ⚔️

단계 1: Nested Prefab으로 '부품' 만들기

단계 2: Base Prefab 만들기

단계 3: Prefab Variant로 '파생' 상품 만들기

결과적으로 얻는 이득

3. 주의할 점 (Best Practices)

마치며

[Unity] 프리팹 안의 프리팹 : Nested Prefab (중첩 프리팹)

1. Nested Prefab이란 무엇인가요?

2. 왜 써야 할까요? (강력한 장점)

✅ 모듈형 작업 가능

✅ 협업 효율 증대

3. 핵심 기능: Overrides (오버라이드)

4. 실무 활용 팁 & 주의사항

1) Prefab Mode(프리팹 모드)를 적극 활용하세요

2) 너무 깊은 중첩(Deep Nesting)은 피하세요

3) Prefab Variant(프리팹 변형)와 함께 쓰세요

마치며

[Unity] 프리팹 간에 상속이 가능하다고? Prefab Variant 활용법

1. 프리팹의 상속 개념 (Duplicate vs Variant)

2. 구현 시나리오: 몬스터 시스템

기존 방식 (Duplicate)의 문제점

상속 방식 (Variant)의 해결책

3. 설계 구조

4. 핵심 기능: 오버라이드(Override)와 리버트(Revert)

5. 협업 시 식별 가이드

1) 아이콘 확인

2) 인스펙터 확인

3) 부모 수정 시 주의사항 (Find References)

요약

Unity에서 `MonoBehaviour`를 `new`로 만들면 무슨 일이 일어날까?

1. MonoBehaviour는 일반 C# 클래스가 아니다

2. 잘못된 생성 방식 — new

1. 고전적인 방식: `while` 루프와 `yield return null`

2. 우아한 방식: `WaitUntil`과 `WaitWhile`

1) `WaitUntil`: 조건이 True가 될 때까지 대기

2) `WaitWhile`: 조건이 True인 동안 대기

1. `MonoBehaviour`는 일반 C# 클래스가 아니다

2. 잘못된 생성 방식 — `new`

✅ 3. 올바른 생성 방식 — `AddComponent`

5. 예시: `new`로 만든 객체의 동작

6. `AddComponent`로 생성된 객체인지 구분하는 방법