덴바의 노트

[유니티 기능] TMP Material Preset

덴바 — Tue, 4 Aug 2026 14:28:10 +0900

TMP Text
Material Presets

안녕하세요 오늘은 TMP_Text 컴포넌트의 마테리얼 프리셋에 대해서 포스팅 하고자 합니다.

생각치고 이 기능을 어떻게 생성하고 활용하는지 모릅니다.

TextMeshPro 컴포넌트를 보면 Material Presets라는 것이 존재합니다.

기본적으로 Text는 Vertex Color와 Color Gradient, Font Style을 활용해서 다양하게 표현할 수 있습니다.

그런데 스크롤링해서 아래를 보시면 마테리얼에서

Face(표면에 보이는 부분), Outline, Underlay를 조절할 수 있는 것을 볼 수 있습니다.

해당 프로퍼티를 이용하면 이와 같이 폰트의 다양성을 추가할 수 있습니다.

(포토샵, 프리미어 프로 등에서도 자주 사용하는 프로퍼티인거 같습니다)

하지만 여기서 문제가 하나 있습니다

아무 생각 없이 저 수치를 변경하면 큰 문제가 생겨 버립니다

영상에서 보시는 바와 같이 텍스트 오브젝트를 하나 생성 했는데, 아까 조절했던 효과가 적용이 되어 나옵니다

이 이유는 조금만 생각해보면 간단합니다.

TextMeshPro에서는 Font 파일을 이용해서 TMP_Font Asset 파일을 만듭니다.

그리고 이는 Material을 이용해서 시각적으로 Text를 표현하는 형태입니다.

그런데 그 기본이 되는 Default Material의 수치를 건들였기 때문에,

새로 생성한 Text 오브젝트도 동일한 효과가 적용이 되어버립니다.

그럼 도대체 저 프리셋을 어떻게 만드는지가 중요합니다.

'그냥 아무 생각 없이 Material을 생성하는건가?' 싶겠지만,

정말 어이없게도 해당 프리셋을 만드는 방법은 꽁꽁 숨겨져 있습니다.

1. 먼저 TMP Font Asset을 생성하면서 만들어진 Default Material을 찾아줍니다.

2. 해당 Material을 클릭하고 Inspector의 우측 상단에 세로로 점 3개의 아이콘(Context Menu)을 클릭하거나,

우클릭을 통해서 Context Menu를 띄우면, Create Material Preset 메뉴가 존재합니다.

해당 메뉴를 클릭합니다.

3. 그럼 자연스럽게 Material이 생성됩니다.

해당 Material에 명칭을 적절하게 바꾸고 프로퍼티를 변경해줍니다.

4. TMP 컴포넌트의 Material Preset Dropdown을 눌러보면

아까 생성한 Red Outline이 추가된 것을 볼 수 있습니다.

5. 해당 프리셋으로 변경해보면 빨간색 아웃라인이 자연스럽게 적용된 것을 볼 수 있습니다.

자 여기 까지 TMP Font Asset의 Material Preset 생성 및 사용 방법에 대해서 적어봤습니다.

'그래서 이걸 어디에 사용해?' 라고 생각하실 수 있습니다.

간단히 생각하면, 매 번 공통적으로 사용되는 Text의 프로퍼티를 미리 저장해둔다면,

딸깍 한 번으로 처리가 되고

A, B의 Title Text의 디자인이 같아야 하는데, 각 담당자가 서로 다르게 나올 수 있습니다.

하지만 해당 프리셋을 저장해둔다면, 이에 대해서 정보 공유만 해두었을 때 이런 트러블이 발생하지 않겠죠?

이상 TMP Material Preset 포스팅이었습니다.

감사합니다

[유니티] 버튼 연타 방지 확장 메소드 구현

덴바 — Wed, 27 May 2026 11:45:52 +0900

UniRx
연타 방지

버튼 연속 클릭 방지 코드

public static IObservable<Unit> OnClickAsObservableWithThrottle(
  this Button button, float intervalSeconds, Action onWaitAction = null)
{
  var cooldownEnd = DateTimeOffset.MinValue;
  return button.OnClickAsObservable()
    .Do(_ => {
      if (DateTimeOffset.UtcNow < cooldownEnd)
        onWaitAction?.Invoke(); // 대기 중 액션 실행
    })
    .Where(_ => {
      var now = DateTimeOffset.UtcNow;
      if (now < cooldownEnd) return false; // 쿨다운 중 차단
      cooldownEnd = now.AddSeconds(intervalSeconds);
      return true;
    }).AsUnitObservable();
}

[유니티 알고리즘] 슬라이딩 윈도우 알고리즘 활용

덴바 — Sat, 23 May 2026 01:42:48 +0900

안녕하세요, 오늘은 슬라이딩 윈도우 알고리즘을

게임에서 어떻게 활용하면 좋을지에 대해서 포스팅하고자 합니다.

슬라이딩 윈도우 알고리즘

슬라이딩 윈도우 알고리즘

슬라이딩 윈도우 알고리즘이란 배열 내에서 연속된 구간의 범위를 순회하는 알고리즘 입니다.

위 그림처럼 배열에서 연속된 3개의 구간의 합이 가장 큰 부분을 찾는 과정과 같습니다.

윈도우 슬라이딩 알고리즘을 사용해야 하는 이유는 바로 시간 복잡도O(n) 이라는 이점이 있기 때문입니다.

만약, 윈도우 슬라이딩 알고리즘을 사용하지 않고 직관적으로 코드를 구현한다면 어떤 코드가 나올까요?

int maxSum = 0;

for (int i = 0; i < arr.Length - 2; i++)
{
    int sum = 0;
    for (int j = i; j < i + 3; j++)
    {
        sum += arr[j];
    }
    if (sum > maxSum)
    {
        maxSum = sum;
    }
}

이와 같이 반복문을 2번 사용하여 O(3n) 의 시간복잡도가 나오게 구현하고 말 것입니다.

윈도우 슬라이딩 알고리즘의 경우, 연속된 구간의 윈도우를 구하고 이를 마치 슬라이딩 하듯이 구현합니다.

int maxSum = 0;
int sum = 0;

// 첫 번째 윈도우 초기화
for (int i = 0; i < 3; i++)
{
    sum += arr[i];
}
maxSum = sum;

// 윈도우 슬라이딩
for (int i = 1; i <= arr.Length - 3; i++)
{
    sum = sum - arr[i - 1] + arr[i + 2];
    if (sum > maxSum)
    {
        maxSum = sum;
    }
}

위 코드와 같이 연속된 구간을 유지한 채 시작 부분을 끝 부분으로 이동시키는 방식입니다.

이 알고리즘을 게임 개발에서는 어떻게 활용하면 좋을까요?

DPS 계산

MVP 계산

적 AI가 일정 간격 플레이어로 부터 피격 횟수를 이용해서 위험도 계산

Combo 판정 등

슬라이딩 윈도우 기법을 활용해서 다양한 기능을 구현할 수 있다.

게임 외에도 채팅 도배 감지 등에서도 사용할 수 있다.

이 중 DPS 계산을 구현해보겠습니다.

DPS 계산

미리보기

public class DPSExample : MonoBehaviour
{
    [SerializeField] private TMP_Text dpsText;
    [SerializeField] private Slider dpsSlider;
    [SerializeField] private Button attackButton;
    [SerializeField] private float damage;
    [SerializeField] private float Window = 1f;
    [SerializeField] private float dpsLerpTime = 0.1f;

    private float _displayDPS = 0f;
    private float _totalDamage = 0;
    private float _maxDps = 0;
    private readonly List<(float time, float damage)> _damages = new();


    private void Start()
    {
        attackButton.OnClickAsObservable().Subscribe(OnDamage).AddTo(this);
    }

    private void Update()
    {
        float now = Time.time;

        float removedDamage = 0;

        _damages.RemoveAll(d =>
        {
            bool isExpired = now - d.time > Window;

            if (isExpired)
            {
                removedDamage += d.damage;
            }

            return isExpired;
        });

        _totalDamage -= removedDamage;
        float dps = _totalDamage / Window;
        if(dps > _maxDps)
        {
            _maxDps = dps;
            dpsSlider.maxValue = _maxDps;
        }
        _displayDPS = Mathf.Lerp(_displayDPS, dps, dpsLerpTime * Time.deltaTime);
        dpsSlider.value = _displayDPS;
        dpsText.text = _displayDPS.ToString("N0");
    }

    public void OnDamage(Unit _)
    {
        float now = Time.time;

        _damages.Add((now, damage));
        _totalDamage += damage;
    }
}

이게 왜 윈도우 슬라이딩 알고리즘인가 생각할 수 있지만,

윈도우의 중심이 배열의 Index가 아닌,

Time으로 변경되었을 뿐이다.

값을 추가하고 시간을 중심으로 Window를 이용한 이전 값을 삭제하는 방식이다.

하지만 위 코드는 약간 단점이 있다.

RemoveAll을 사용했기 때문이다.

RemoveAll 함수는 배열 내 모든 요소를 탐색하기 때문에 무조건 최소 시간 복잡도O(N)가 나옵니다.

시간 복잡도를 낮추기 위해서는 Queue를 활용하는 것이 좋습니다.

    private void Update()
    {
        float now = Time.time;

        while(_damages.Count > 0)
        {
            var oldest = _damages.Peek(); // 가장 오래된 데이터를 가져옴

            if (now - oldest.time > Window)
            {
                _totalDamage -= oldest.damage; // 전체 데미지 감소
                _damages.Dequeue(); // Dequeue로 데이터 제거
            }
            else break;
        }

        float dps = _totalDamage / Window;
        if(dps > _maxDps)
        {
            _maxDps = dps;
            dpsSlider.maxValue = _maxDps;
        }
        _displayDPS = Mathf.Lerp(_displayDPS, dps, dpsLerpTime * Time.deltaTime);
        dpsSlider.value = _displayDPS;
        dpsText.text = _displayDPS.ToString("N0");
    }

Queue는 먼저 들어온 값을 먼저 내보내는 FIFO 방식이고, 오래된 순의 데이터를 관리하기 좋습니다.

이로 인해 최대 시간복잡도O(N)으로 최적화를 할 수 있습니다.

이상으로 윈도우 슬라이딩 알고리즘에 대해서 포스팅을 마치겠습니다.

[코딩테스트 : 프로그래머스] 노란불 신호등 C#

덴바 — Mon, 11 May 2026 18:29:18 +0900

문제 내용

https://school.programmers.co.kr/learn/courses/30/lessons/468371

문제 분석

여러 신호등이 노란색이 되어 정전이 일어나는 시간을 찾기

1. LCM을 활용해서 신호등 전체의 한 사이클 범위를 분석.

2. 나머지 계산(%)을 통해서 노란색이 사이클 내에 몇 번인지 파악하고, 이를 활용해서 노란색이 겹치는 타이밍을 계산

필요한 알고리즘 - LCM, GCD

    // 유클리드 호제법 최대 공약수
    private int GCD(int a, int b)
    {
        while(b != 0)
        {
            int temp = a % b;
            a = b;
            b = temp;
        }
        return a;
    }

    private int LCM(int a, int b)
    {
        return a / GCD(a, b) * b;
    }

	public class Solution
	{
    	public int solution(int[,] signals)
        {
        	int row = signals.GetLength(0);
            int lcm = 1;
            
            for(int i = 0; i < row; i++)
            {
            	int cycle = signals[i, 0] + signals[i, 1] + signals[i, 2];
                lcm = LCM(cycle, lcm); // 신호등 전체의 한 사이클을 최소 공배수로 계산
            }
            
            for(int t = 1; t <= lcm; t++)
            {
            	bool isAllYellow = true;
            	for(int i = 0; i < row; i++)
                {
                	int green = signals[i, 0];
                    int yellow = signals[i, 1];
                    int red = signals[i, 2];
                    
                    int yellowStart = green + 1;
                    int yellowEnd = green + yellow;
                    
                    int cycle = green + yellow + red;
                    int pos = t % cycle; // 각 신호등의 사이클 내에서 몇 번째인지 추출
                    if(pos == 0) // 한 사이클을 다 돌음
                    	pos = cycle;
                    
                    if(pos < yellowStart || pos > yellowEnd) // 노란색 범위 밖일 경우
                    {
                    	isAllYellow = false;
                        break;
                    }
                }
                
                if(isAllYellow) return t; // 정전 시간 반환
            }
            return -1; // 해당하지 않는 경우
        }
    }

[유니티] 3D FPS 게임 구현 1 - 이동 구현 (Locomotion)

덴바 — Wed, 22 Apr 2026 07:46:17 +0900

이전 포스트

[유니티] 3D FPS 게임 구현 0 - 에셋 준비

최근 원신, 명조 등의 장르 구현에만 너무 몰두한 나머지 다른 장르 구현 실력이 바닥을 치는 것을 느꼈습니다.이번에는 오랜만에 FPS 게임의 일부를 구현해볼까 합니다. 오늘의 키워드에셋 준비

denbacodingnote.tistory.com

지난번에 에셋 준비를 모두 마쳤으니 이번에는 캐릭터 이동을 구현해보도록 하겠습니다.

캐릭터 움직임

1. 이용할 모델링 파일 배치

먼저 준비한 캐릭터 에셋을 맵에 배치해둡니다. Transform은 Scale 빼고 모두 0으로 초기화 합니다.

플레이어 기능 스크립트 설계 및 구현

InputSystem : 플랫폼/디바이스에 상관없이 입력을 추상화해서, 이벤트 기반으로 처리하는 유니티 시스템
InputManager : Input System의 입력을 받아 Observable 스트림으로 배포하는 기능
FPSPlayerController : 입력을 받아서 해석 후 각 기능으로 전파 및 관리하는 기능 
PlayerLocomotion : 플레이어의 움직임을 담당

INPUT SYSTEM의 Generate C# Class를 생성합니다.

또한 각 필요한 키 입력을 등록 합니다.

InputManager 구현

먼저 InputManager는 싱글톤으로 구현해줍니다. 특히 MonoBehaviour를 상속하는 싱글톤이 아닌, 일반 class, new()의 Singleton으로 구현합니다.

이유는 Update, FixedUpdate 등의 함수를 이용할 이유가 없기 때문입니다.

    public class InputManager : Singleton<InputManager>
    {
        private GameInput_Actions m_Actions;
        private Subject<Vector2> onMove = new();
    }

InputSystem의 Actions를 C# 클래스로 생성했기에, 해당 클래스를 InputManager에 필드로 선언해둡니다.

또한 UniRx를 이용해서 Move Action의 입력값을 외부해서 받을 수 있게 OnMove Subject를 생성해둡니다.

        private void Bind(InputAction action, Action<InputAction.CallbackContext> callback, bool performed = true, bool canceled = false, bool started = false)
        {
            if (performed) action.performed += callback;
            if (canceled) action.canceled += callback;
            if (started) action.started += callback;
        }
        
        private void Unbind(InputAction action, Action<InputAction.CallbackContext> callback)
        {
            action.performed -= callback;
            action.canceled -= callback;
            action.started -= callback;
        }

우리가 등록한 Action에는 started, performed, canceled가 존재하기는데, 새로운 액션을 추가할 때 마다 위 내용을 다 넣기에는 반복적이고 귀찮기에 이를 함수로 묶어둡니다.

        private void OnMoveInput(InputAction.CallbackContext context)
        {
            var move = context.ReadValue<Vector2>();
            onMove?.OnNext(move);
        }

이제 이동의 입력값을 InputAction.CallbackContext 파라미터를 통해서 받고, 이를 Vector2로 받아서,

아까 구현한 onMove에 발행할 수 있도록 합니다.

    public override UniTask Initialize()
    {
        m_Actions?.Enable();
        m_Actions?.AddTo(this);

        if (m_Actions != null)
        {
            Bind(m_Actions.Player.Move, OnMoveInput, started: false, performed: true, canceled: true);
        }
    }

해당 InputManager를 초기화할 때 Actions를 Enable()를 반드시 호출해줍니다. 이를 활성화하지 않으면, Input 하드웨어로 부터의 입력에 대해서 Action이 일어나지 않는다고 판단해주시면 됩니다.

그리고 아까 구현한 기능을 Bind해줍니다.

저는 performed로 실시간으로 입력과 입력이 끝날 때에 대해서 액션을 구독해둡니다.

다른 입력을 추가할 때 또한 위와 같은 방식으로 처리합니다.

플레이어 컨트롤러

PlayerController는 MonoBehaviour를 상속하는 스크립트로 생성합니다.

Start 함수에서 아까 호출했던 InputManager에 접근해서 OnMove에 OnMove를 구독합니다.

InputContext를 struct로 가볍게 만들어줍니다.

예전에는 PlayerController에 필요한 필드를 하나씩 만들어 갔지만, 이렇게 하면 막상 필요한 필드를 하나씩 가져와야 하는 불편함이 있습니다.

그래서 위와 같이 Context로서 하나로 묶고 각 기능의 로직으로 이를 전달하는 방식을 채택했습니다.

PlayerLocomotion

이동 방식은 진짜 구현하는 방법이 다양하지만 대표적으로는 Rigidbody와 CharacterController가 존재합니다.

이번에는 굳이 물리적인 처리가 크게 필요하지 않기 때문에 CharacterController를 사용하겠습니다.

또한 PlayerLocomotion은 MonoBehaviour를 상속하지 않고 일반 C# 클래스로 구현했습니다.

실시간 기반 호출을 하려면 Update, FixedUpdate, LateUpdate 등을 사용해야 하지만, MonoBehaviour를 상속시켜 해당 스크립트 내에서 처리하면, 각 기능별 호출 타이밍을 개발자가 마음대로 조절할 수 없습니다.

예를들어서, Locomotion의 Update 함수가 맨마지막에 호출되고 StateMachine의 Update 함수가 호출되게 하고 싶을 때,

MonoBehaviour 내의 Update 함수로 제어를 가능한가? 라고 질문하면 그건 운적으로 그렇게 호출될 가능성은 있어도 제어는 불가능합니다.

물론 Script Execution Order를 사용하면 제어는 할 수 있지만, 복잡하고 확장성이 떨어진다고 생각합니다.

하지만 PlayerController의 Update 내부에서 실행할 함수를 직접 지정하도록 구성하면, 실행 순서를 비교적 간단하게 제어할 수 있습니다.

    void Update()
    {
        _stateMachine?.LogicUpdate();
    	_weapon?.LogicUpdate();    
    	_locomotion?.LogicUpdate(deltaTime, _inputContext);
    }

스크립트 구현이 완료되었으니 캐릭터 오브젝트에 해당 컴포넌트를 부착하고

CharacterController 필드를 할당해줍니다.

결과 확인

이제 이동은 구현이 되었지만, 움직이는 모션이나 카메라 회전 등이 아직 부족합니다.

위 내용은 다음 포스팅에서 작성해보겠습니다.

[유니티] 3D FPS 게임 구현 0 - 에셋 준비

덴바 — Wed, 22 Apr 2026 06:19:17 +0900

최근 원신, 명조 등의 장르 구현에만 너무 몰두한 나머지 다른 장르 구현 실력이 바닥을 치는 것을 느꼈습니다.

이번에는 오랜만에 FPS 게임의 일부를 구현해볼까 합니다.

에셋 준비

에셋 준비

시작하기에 앞서, 에셋을 몇 가지 준비해보고자 합니다.

준비해야할 에셋은 다음과 같습니다.

저는 3년간 할인하는 에셋부터 번들, 무료 배포 등의 에셋을 꾸준히 모아왔기에 사용할만한 에셋은 많았고, 이 참에 이를 활용하기로 했습니다.

캐릭터 모델링 | 애니메이션 | 총 모델링

BIPER 라는 분이 제작하는 에셋을 즐겨 사용하며, 이번 세일에 구입했기에 사용했습니다.

해당 에셋에는 캐릭터 모델링 뿐만 아닌 총 모델링과 필요한 애니메이션이 다 들어있습니다.

https://assetstore.unity.com/packages/3d/characters/humanoids/humans/combatgirls-riflecharacterpack-305180

CombatGirls_RifleCharacterPack | 캐릭터 | Unity Asset Store

Get the CombatGirls_RifleCharacterPack package from BIPER and speed up your game development process. Find this & other 캐릭터 options on the Unity Asset Store.

assetstore.unity.com

총 이펙트

발사 시 보이는 총구 섬광(Muzzle Flash)과 피격 시 발생하는 Hit Effect (Blood)는 놀랍게도 구매해둔 에셋이 없기에 무료 에셋을 사용했습니다.

피격 이펙트

https://assetstore.unity.com/packages/vfx/particles/vfx-impact-and-hit-light-version-335800

VFX - Impact and Hit - Light Version | 시각 효과 파티클 | Unity Asset Store

Add depth to your next project with VFX - Impact and Hit - Light Version from Cartoon VFX by Wallcoeur. Find this & more 시각 효과 파티클 on the Unity Asset Store.

assetstore.unity.com

총구 섬광(Muzzle Flash)

https://assetstore.unity.com/packages/vfx/particles/free-quick-effects-vol-1-304424

Free Quick Effects Vol. 1 | 시각 효과 파티클 | Unity Asset Store

Add depth to your next project with Free Quick Effects Vol. 1 from Gabriel Aguiar Prod. Find this & more 시각 효과 파티클 on the Unity Asset Store.

assetstore.unity.com

총 사운드

https://assetstore.unity.com/packages/audio/sound-fx/sci-fi-weapons-bullet-hell-sound-effects-pack-271305

Sci-Fi Weapons: Bullet Hell Sound Effects Pack | 음향 효과음 | Unity Asset Store

Layer in the sounds of Sci-Fi Weapons: Bullet Hell Sound Effects Pack from SwishSwoosh for your next project. Browse all audio options on the Unity Asset Store.

assetstore.unity.com

해당 에셋들을 가지고 3D FPS 게임 기능을 일부 구현해보겠습니다.

[유니티] 컴파일링(Compiling)과 어셈블리 정의 (Assembly Definition)

덴바 — Thu, 16 Apr 2026 00:01:07 +0900

컴파일링
Assembly
IL

안녕하세요, 오늘은 Assembly Definition에 대해서 공부해보고자 합니다.

컴파일링

컴파일링이란 우리가 고급 언어(C#, C++, Java 등)로 작성한 소스코드를 컴퓨터가 실행할 수 있는 (IL/DLL)로 변환하는 작업입니다.

위와 같이, 새로운 스크립트를 생성하거나 코드 작성 또는 변경 시 하나의 프로세스 진행을 보여주는 다이얼로그 보입니다.

이는 생성 또는 변경한 코드의 컴파일링을 처리를 보여줍니다.

참고로 유니티에서의 컴파일링 방식은 2가지가 존재합니다.

MONO

IL2CPP

또한 위 프로세스 다이얼로그를 살펴보면 크게 4가지 정도의 동작이 발생합니다.

컴파일을 통해 C# 코드를 IL 코드와 메타데이터를 포함한 어셈블리(DLL)로 생성하고, 이를 로드하여 메모리에 올립니다.

그 후, 유니티의 도메인 환경을 초기화합니다.

어셈블리

어셈블리라는 단어를 처음 봤을 때 생각나는 것은 어셈블리 언어였습니다.

하지만, 어셈블리 언어와 유니티에서 말하는 어셈블리는 전혀 다른 개념입니다.

유니티에서의 어셈블리는 .NET 환경의 코드 묶음을 의미합니다.

즉, 코드를 하나로 묶은 배포 단위 (DLL / EXE) 라고 생각하면 됩니다.

개발자들이 생성 및 구현하는 스크립트 코드도 전부 Assembly-CSharp.dll에 합쳐져서 어셈블리 단위로 컴파일링이 일어납니다.

물론, Editor 라는 폴더를 생성하고 해당 폴더에서 작성한 스크립트는 기본적으로 Assembly-CSharp.Editor.dll로 컴파일링이 일어납니다.

Editor 관련 코드는 빌드할 수 없기 때문에, 툴을 개발할 때는 기본적으로 Editor 폴더를 만들면 빌드 시 걱정이 없습니다.

빌드 시 Assembly-CSharp.Editor.dll 컴파일링은 동작하지 않기 때문입니다.

어셈블리 정의 (Assembly Definition)

위에서 언급했듯이, 개발자가 Editor 폴더 또는 그 외에 생성한 스크립트는 모두 Assembly-CSharp.dll과Assembly-CSharp.Editor.dll에 자동으로 합쳐집니다.

하지만, 이는 하나의 큰 문제점이 있습니다.

작은 프로젝트의 경우에는 크게 영향이 없지만, 큰 프로젝트의 경우는 대량의 게임 로직, 데이터 로직, 툴 등의 스크립트가 존재하기 합니다. 스크립트가 많을 수록 컴파일링 시간은 길어집니다.

예를 들어, 유저가 단순히 변수명을 변경하는 것과 같은 작은 수정만 하더라도, Assembly-CSharp.dll과 Assembly-CSharp-Editor.dll에 포함된 모든 코드가 다시 컴파일됩니다. 이로 인해 컴파일 시간이 길어지고, 전체적인 작업 속도가 저하되는 문제가 발생할 수 있습니다.

이러한 문제를 해결하기 위해 Unity는 기본적으로 모든 스크립트를 하나의 어셈블리로 자동으로 묶지만, Assembly Definition Asset을 통해 개발자가 어셈블리를 직접 분리하고 관리할 수 있도록 합니다.

어셈블리 정의 생성 위치

유니티 6 기준으로 Create -> Scripting -> Assembly Definition을 통해서 어셈블리 정의 에셋을 생성할 수 있습니다.

어셈블리 정의 에셋을 생성하면 Inspector에서 어셈블리명과 NameSpace의 Root명, 참조 가능한 Assembly Definition, 사용 범위를 정하는 Platforms 등을 설정할 수 있습니다.

이를 사용해서 스크립트들을 어셈블리 정의를 통해서 분리하면 컴파일링 속도, 의존성 관리, Editor / Runtime 분리가 가능해집니다.

주의점

Assembly Definition References에 각 정의를 참조시킬 때, 의존성을 고려하여 연결해야 합니다.

그렇지 않으면, 컴파일링 발생 시 무한 참조가 발생하는 문제가 발생할 수 있습니다.

예를 들어서 Assembly Definition을 3가지 생성했다고 가정해보겠습니다.

Editor
Runtime
Data

Editor -> Runtime, Data

Runtime -> Data

Data -> Editor, Runtime

위와 같이 참조를 설정할 경우, Data → Editor → Runtime → Data와 같은 순환 참조가 발생하게 됩니다.

이러한 순환 구조는 컴파일 순서를 결정할 수 없게 만들어, 컴파일 에러를 유발하거나 예상치 못한 동작을 일으킬 수 있습니다.

따라서 Assembly Definition을 설계할 때는 의존성이 한 방향으로만 흐르도록 구성하는 것이 중요합니다.

[유니티 셰이더] 툰셰이더 기초 1 - Lambert BRDF

덴바 — Sun, 12 Apr 2026 21:59:43 +0900

셰이더
Lambert
툰 셰이더

안녕하세요, 오늘은 셰이더에 대해서 공부한 것을 포스팅해보고자 합니다.

몇 년 전 부터 게임 업계에서 툰 셰이더를 사용하는 서브컬처 게임이 아직까지 매우 인기를 끌고 있습니다.

또한 이러한 툰 셰이더를 활용한 버튜버 또한 매우 인기가 있죠.

최근 많은 사람들이 사용하는 퀄리티 높은 셰이더라고 하면 역시 닐로툰 대표적이지 않을까 생각합니다.

닐로툰 깃허브 소개 이미지

게임 개발에 있어서 데이터 관리, 로직 구현도 중요하지만, 시각적인 부분도 빠질 수 없는 만큼, 셰이더에 대해서 공부하기 해볼까 합니다.

이득우 님의 셰이더 강의 영상을 참고해서 공부를 했습니다.

툰 셰이더 Toon Shader

툰 셰이더는 Lambert 방식으로 계산된 빛을 단순하게 나눠서(계단화해서), 만화처럼 딱 끊기는 명암을 만드는 방식입니다.

유니티 툰 셰이더 설명 페이지 공식 이미지

따라서 툰 셰이더는 현실처럼 부드러운 빛과 그림자가 표현되지 않고, 밝은 부분과 어두운 부분이 명확하게 나뉘어 표현됩니다.

(좌)Lil Toon Shader (우)URP Lit Shader

Lambert (람베르트) 반사

람베르트(Lambert) 반사란 빛이 표면에 닿는 각도에 따라 밝기가 결정되는 가장 기본적인 확산 반사의 양이 점점 감소 됩니다.

그리고 빛이 들어왔을 때, 어느 방향으로 얼마나 반사되는지를 정의하는 함수가 바로 Lambert BRDF 입니다.

밝기 = N · L = cos θ

앞서 살펴봤듯이, Lambert 반사에서 표면의 밝기는 빛이 닿는 각도, 즉 법선 벡터 N과 빛 방향 벡터 L의 내적으로 결정됩니다.

원래는 θ값을 알기 위해서 Acos을 이용하여 계산을 하지만, Acos는 연산 비용이 크기 때문에, 게임에서는 이를 위해서 내적 (Dot)을 사용합니다.

이러한 람베르트 반사를 표현하기 위해서 유니티의 Shader Graph를 사용해봤습니다.

오브젝트 -> 빛 방향 계산

빛의 방향을 출력하는 Main Light Direction 노드가 있지만, 이는 빛 -> 오브젝트의 방향을 출력하기에, Negate를 이용해서 해당값을 반전시켜줍니다.

이로 인해 오브젝트 -> 빛의 방향을 계산해낼 수 있습니다.

법선 벡터 N

법선 벡터 N의 경우, Normal Vector 노드를 통해서 출력해낼 수 있습니다.

Dot(N, L)

두 벡터의 내적을 계산해냅니다. 내적 계산은 Dot Product 노드를 사용합니다.

색 반영

마지막으로 Dot 출력 값과 프로퍼티로 뺀 컬러의 출력값을 Multiply 노드로 곱해서 BaseColor에 반영해줍니다.

결과

유니티 VirtualCamera가 Live 상태로 변하지 않는 문제

덴바 — Sun, 23 Nov 2025 23:54:09 +0900

CinemachineVirtualCamera
CinemachineBrain

발생한 문제

CinemachineVirtualCamera의 상태가 Standby가 아닌 Live로 변하지 않아서 CinemachineBrain이 해당 VirtualCamera를 따라가지 않는 문제가 발생

해결 방안

CinemachineBrain이 있는 오브젝트에 부착된 Camera Component의 CullingMask에 Default가 체크되지 않으면 VirtualCamera가 켜져도 인식을 못하는 것을 발견

유니티 C#, C++ 그리고 Null

덴바 — Mon, 30 Jun 2025 02:35:20 +0900

유니티와 C++의 관계
Null 처리의 중요성

얀녕하세요, 오늘은 회사를 다니면서 새로 배운 내용들을 잊기 전에 메모해둘 필요가 있다고 느껴서 포스팅 해봅니다.

기본적으로 유니티는 C#을 사용하기 때문에 당연하게 C++과는 관계 없을 거라고 생각할 수 있습니다.

하지만 실제 Unity 엔진의 코어(렌더링, 물리, 오디오, 메모리 관리 등)은 C++로 구현되어 있습니다.

그럼 왜 우리는 C++로 이루어진 엔진을 C#으로 코딩을 할까? 라는 의문이 있습니다.

이유는 C#이 생산성, 유지보수, 개발 속도가 매우 높은 반면,

C++은 메모리 버그가 많고, 개발 속도가 느리며, 가독성 생산성이 낮다고 판단되기 때문입니다.

특히, C++은 컴파일과 링크 시간이 길기 때문에 게임 엔진 개발로서는 부적합하다고 판단했다 생각합니다.

즉, 실제로 GameObject를 생성하게 되면 코어의 C++ 코드가 실행됩니다.

여기서 핵심은 엔진의 C++ 코드가 생성되면서 C++객체가 생성됩니다.

동시에 이를 접근하고 관리하기 위해서 C#의 객체를 생성하고 C++의 객체를 참조합니다.

						Destroy(obj);

Destroy 메소드 또한 코어 함수 중 하나입니다.

Destroy가 호출되면, C++의 객체가 파괴됩니다.

이 순간 댕글링 포인터 현상이 발생합니다.

C++의 객체는 파괴되지만, 이를 참조하기 위해 생성된 C# 객체는

아직도 C++ 객체의 주소를 참조하고 있는 문제가 발생합니다.

이렇게 되면 해당 C# 객체는 GC에 빠르게 수거 대상이 되지 않습니다.

즉, 불필요한 데이터가 계속해서 메모리에 쌓이게 되는 것입니다.

그럼 이를 유니티에서 어떻게 하면 확인할 수 있을까요?

        private void Update()
        {
            if(Input.GetKeyDown(KeyCode.F1))
            {
                Destroy(obj);
            }
            if (Input.GetKeyDown(KeyCode.F2))
            {
                Debug.Log(obj);
                Debug.Log(obj.GetType());
                Debug.Log(obj == null);
            }
        }

위와 같은 방식으로 테스트하면 어떤 결과가 나올까요?

obj가 null처리 되었음에도 불구하고 obj의 타입은 아직 UnityEngine.GameObject임을 알려줍니다.

이는 아직 C# 객체가 제대로 파괴되지 않았기 때문입니다.

그럼 이를 방지하기 위해서는 어떻게 해야할까요?

간단합니다.

파괴한 객체를 Null 처리해주는 것입니다.

        private void Update()
        {
            if(Input.GetKeyDown(KeyCode.F1))
            {
                Destroy(obj);
                obj = null;
            }
            if (Input.GetKeyDown(KeyCode.F2))
            {
                Debug.Log(obj);
                Debug.Log(obj.GetType());
                Debug.Log(obj == null);
            }
        }

이렇게 하면 어떤 결과가 나올까요?

객체가 null처리가 확실히 되면서 해당 객체와의 레퍼 연결이 끊깁니다.

즉, 이는 GC의 대상이 되면서 빠르게 메모리 관리가 될 수 있습니다.

C++에서는 소멸자 등을 사용해서 데이터를 관리해주지만, C#은 GC가 메모리를 관리해준다는 점.

자동으로 메모리가 관리되지만, 그럼에도 불구하고 레퍼런스 타입의 객체는 항상 null처리를 해주는 것이 중요합니다.

최근 저는 IDisposable을 구현하는 클래스에 상속해서 Dispose 패턴을 꾸준히 구현합니다.

작은 프로젝트의 경우에는 굳이 할 필요는 없을 수 있지만, 프로젝트가 커질 수록 메모리 관리는 중요해집니다.

이상으로 포스팅을 마치도록 하겠습니다.

감사합니다.