젊은 프로그래머의 슬픔

[Unity] 총알 시스템으로 알아보는 Object Pool

브라더스톤 — Thu, 7 May 2026 16:18:24 +0900

■ Object Pool

[ObjectPool]

게임 오브젝트를 생성하는 Instantiate() 메서드는 비용이 높은 연산이다. 이 메서드를 게임 플레이 중 반복적으로 호출하면 프레임 드롭이나 GC(Garbage Collection) 스파이크 등 다양한 성능 문제를 일으킬 수 있다.

이를 해결하기 위해 "필요할 때마다 생성하자"가 아닌, "미리 만들어 두고 꺼내 쓰자"라는 접근 방식을 취하는 것이 바로 Object Pool이다.

Instantiate()가 비싼 이유

Unity에서 우리가 작성하는 코드는 C#이지만, Unity 엔진의 내부(코어)는 C++로 작성되어 있다. 즉, 우리가 다루는 C# 코드는 C++ 코어를 조작하는 리모컨 같은 역할을 한다.

Instantiate()를 호출하면, Unity는 하나의 게임 오브젝트를 위해 다음 과정을 거친다.

C# 영역(매니지드 힙)에 C# 래퍼 객체를 생성한다.
C++ 영역(네이티브 힙)에 실제 엔진 객체를 생성한다.
C# 래퍼 객체 안에 C++ 본체의 주소(핸들)를 저장해 둘을 연결한다.
C++ 본체를 엔진 시스템(씬 그래프, Transform 트리 등)에 등록한다.

여기서 핵심은, 이 과정이 컴포넌트 하나당, 자식 오브젝트 하나당 반복된다는 점이다.

C#-C++ 한 쌍을 만드는 비용 자체는 크지 않지만, 프리팹에 포함된 모든 컴포넌트와 모든 자식 오브젝트에 대해 곱해지기 때문에 전체 비용이 급격히 증가한다.

■ 간단한 게임 시스템 구현

위 영상처럼 플레이어가 마우스 방향을 바라보고, 바라보는 방향으로 총알을 발사하는 간단한 시스템을 만들어 볼 것이다.

Object Pool을 직접 구현하는 대신, Unity에서 제공하는 UnityEngine.Pool을 활용하여 제작한다.

1. Player.cs

using System;
using UnityEngine;
using UnityEngine.InputSystem;

public class Player : MonoBehaviour
{
    private Camera _camera;
    private Plane _aimPlane;

    private void Awake()
    {
        _camera = Camera.main;
        _aimPlane = new Plane(Vector3.up, transform.position.y);
    }

    private void Update()
    {
        var ray = _camera.ScreenPointToRay(Mouse.current.position.ReadValue());

        if (_aimPlane.Raycast(ray, out var dist) == true)
        {
            var hit = ray.GetPoint(dist);
        }
    }
}

[마우스 위치 구하기]

마우스의 월드 좌표(World Position)를 구하기 위해, 플레이어 위치의 Y값을 기준으로 수평 평면을 생성한다. 탑다운 시점에서는 마우스가 가리키는 바닥 위의 좌표를 알아야 하므로, 노멀을 Vector3.up(Y축)으로 설정해 바닥과 나란한 XZ 평면을 만든다. 플레이어가 이동하지 않으므로 Awake()에서 미리 생성해 둔다.

이후 카메라에서 마우스 방향으로 Ray를 발사하고, 이 Ray가 평면과 교차하는 지점을 마우스의 월드 좌표로 사용한다.

private void Update()
{
	var ray = _camera.ScreenPointToRay(Mouse.current.position.ReadValue());
	
	if (_aimPlane.Raycast(ray, out var dist) == true)
	{
		var hit = ray.GetPoint(dist);
		var dir = hit - transform.position;
		dir.y = 0;
		
		if (dir.sqrMagnitude > 0.001f)
		{
			transform.rotation = Quaternion.LookRotation(dir);
		}
	}
}

[캐릭터가 바라볼 방향 구하기]

마우스의 월드 좌표(hit)를 구했으니, 여기서 플레이어의 위치를 빼 플레이어에서 마우스 방향으로 향하는 방향 벡터(dir)를 구한다.

이때 마우스가 플레이어와 너무 가까우면 방향 벡터가 거의 0에 가까워져 회전이 불안정해질 수 있다. 이를 방지하기 위해 sqrMagnitude로 벡터의 제곱 크기를 검사하고, 일정 값 이상일 때만 Quaternion.LookRotation()으로 플레이어를 회전시켜 마우스 방향을 바라보게 한다.

sqrMagnitude는 벡터 크기의 제곱을 반환한다. magnitude와 달리 제곱근 연산을 생략하므로, 단순 대소 비교에서는 더 가볍다.

2. 총과 총알(Weapon, Bullet)

using System;
using UnityEngine;

public class Weapon : MonoBehaviour
{
    [SerializeField] private Bullet currentBullet;
    [SerializeField] private float fireDelay;
    
    private float _lastFireTime = float.NegativeInfinity;

    public void Fire()
    {
        if (Time.time - _lastFireTime < fireDelay) return;
        
        // TODO : Pool에서 총알을 얻어오기!
        _lastFireTime = Time.time;
    }
}

Weapon 클래스는 총의 역할을 담당한다.

발사할 총알과 발사 딜레이를 직렬화 필드로 선언하고, Fire()가 호출되면 사격 딜레이가 경과했는지 확인한다. 딜레이가 지났다면 풀에서 총알을 가져온 뒤 마지막 사격 시점을 갱신한다.

using UnityEngine;

public class Bullet : MonoBehaviour
{
    private Vector3 _dir;
    private float _velocity;

    private float _despawnTime;
    private const float LIFE_TIME = 5f;
    
    public void Init(Vector3 dir, Vector3 pos, float velocity)
    {
        _dir = dir.normalized;
        transform.position = pos;
        _velocity = velocity;

        _despawnTime = Time.time + LIFE_TIME;
    }
    
    private void Update()
    {
        transform.position += _dir * (_velocity * Time.deltaTime);

        if (Time.time >= _despawnTime)
        {
            // TODO : 사용한 총알을 다시 Pool로 돌려 재사용!
        }
    }
}

Bullet 클래스는 총알의 이동과 수명을 관리한다. Init()에서 날아갈 방향, 발사 위치, 속도를 파라미터로 받아 초기화하고, Update()에서 매 프레임 지정된 방향으로 이동한다. 일정 시간(LIFE_TIME)이 지나면 총알을 풀로 반환하여 재사용할 수 있도록 한다.

3. 입력 처리(Input Action)

기존 Input 클래스의 GetMouseButton() 대신, InputAction을 활용하여 마우스 좌클릭 입력 시 Weapon의 Fire()를 호출하도록 구현해 보자.

using System;
using UnityEngine;
using UnityEngine.InputSystem;

public class Player : MonoBehaviour
{
    [SerializeField] private Weapon equippedWeapon;

    private GameInput _gameInput;

    private void Awake()
    {
        _camera = Camera.main;
        _aimPlane = new Plane(Vector3.up, transform.position.y);
        
        _gameInput = new GameInput();
    }
    
    private void OnEnable()
    {
        _gameInput.Player.Enable();
       
        _gameInput.Player.Fire.performed += OnStartFire;
    }

    private void OnDisable()
    {
        _gameInput.Player.Disable();
        
        _gameInput.Player.Fire.performed -= OnStartFire;
    }

    private void OnDestroy()
    {
        _gameInput.Dispose();
    }

    private void OnStartFire(InputAction.CallbackContext _)
    {
        equippedWeapon.Fire();
    }
}

Input Action 에셋을 생성했으면, GameInput 타입의 변수를 선언할 수 있다. Awake()에서 new GameInput()으로 인스턴스를 초기화해야 사용할 수 있다.

OnEnable()에서 Player 액션 맵을 활성화하고, Fire 액션의 performed 이벤트에 OnStartFire()를 등록한다. OnDisable()에서는 액션 맵을 비활성화하고 이벤트를 해제하며, OnDestroy()에서 Dispose()를 호출해 리소스를 정리한다.

OnStartFire()는 InputAction.CallbackContext를 파라미터로 받아야 하므로, Weapon의 Fire()를 직접 등록하지 않고 별도 메서드로 래핑 하여 호출한다.

■ ObjectPool 구현

[ObjectPool 흐름]

오브젝트 풀을 구현하기 위해선 먼저 풀을 관리할 Owner클래스를 만들어야 한다. 구현 사항마다 다르지만, 여기서는 풀에 쉽게 접근할 수 있도록 전역 클래스로 생성한다.

using System;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Pool;

public class BulletSpawner : MonoBehaviour
{
    public static BulletSpawner Instance { get; private set; }
    public IObjectPool<Bullet> BulletPool => _pool;
    
    private ObjectPool<Bullet> _pool;
		private Bullet _curBullet;
    
    private void Awake()
    {
        if (Instance == null)
        {
            Instance = this;
            DontDestroyOnLoad(Instance.gameObject);
        }
        else
        {
            Destroy(gameObject);
        }
    }

    public void AddBullet(Bullet bullet)
    {
        _curBullet = bullet;

        _pool = new ObjectPool<Bullet>(
            CreateBullet,
            OnGetBullet,
            OnReleaseBullet,
            OnDestroyBullet,
            collectionCheck: true,
            defaultCapacity: 20,
            maxSize: 100
            );
    }

    private Bullet CreateBullet()
    {
        var obj = Instantiate(_curBullet, transform);
        return obj;
    }

    private void OnGetBullet(Bullet bullet)
    {
        bullet.gameObject.SetActive(true);
    }

    private void OnReleaseBullet(Bullet bullet)
    {
        bullet.gameObject.SetActive(false);
    }

    private void OnDestroyBullet(Bullet bullet)
    {
        Destroy(bullet.gameObject);
    }
    
}

클래스의 전체 형태는 위와 같다. 천천히 살펴보자.

먼저 풀 역할을 할 변수를 선언한다. 제네릭 타입 T에는 풀에서 관리할 오브젝트의 타입을 넣어주면 된다.

// 외부에서 접근할 Pool
public IObjectPool<Bullet> BulletPool => _pool;

// 내부에서 사용할 Pool    
private ObjectPool<Bullet> _pool;

IObjectPool<T>는 Unity가 제공하는 오브젝트 풀의 인터페이스로, Get()과 Release() 등 풀의 기본 동작을 정의한다. 외부에서는 이 인터페이스 타입으로 노출하여, 풀의 내부 구현을 감추고 꺼내기·반환하기만 가능하도록 제한한다.

ObjectPool<T>는 IObjectPool<T>를 구현한 구체 클래스다. Unity는 두 가지 구현체를 제공한다.

클래스	내부 구조	특징
ObjectPool<T>	Stack (배열 기반)	가장 최근에 반환된 객체를 먼저 꺼낸다(LIFO). 메모리가 연속적이고 접근이 빠르다.
LinkedPool<T>	LinkedList (노드 기반)	노드 단위로 할당되어 확장·축소에 유연하지만, 메모리 오버헤드가 크다. (자주 사용하지 않는 오브젝트를 풀링할 때 사용)

일반적으로는 ObjectPool<T>이 성능상 유리하므로, 이 글에서도 이를 사용한다.

public void AddBullet(Bullet bullet)
{
	_curBullet = bullet;

	_pool = new ObjectPool<Bullet>(
			CreateBullet,
			OnGetBullet,
			OnReleaseBullet,
			OnDestroyBullet,
			collectionCheck: true,
			defaultCapacity: 20,
			maxSize: 100
	);
}

ObjectPool<T>을 생성할 때 다음 파라미터를 전달한다.

파라미터	타입	설명
createFunc	Func<T>	풀에 여유 객체가 없을 때 새 객체를 생성하는 콜백.
actionOnGet	Action<T>	풀에서 객체를 꺼낼 때 호출되는 콜백. 주로 SetActive(true) 처리.
actionOnRelease	Action<T>	객체를 풀로 반환할 때 호출되는 콜백. 주로 SetActive(false) 처리.
actionOnDestroy	Action<T>	풀이 maxSize를 초과하여 객체를 수용할 수 없을 때 완전히 제거하는 콜백.
collectionCheck	bool	true로 설정하면 같은 객체를 중복 반환하는 실수를 방지한다.
defaultCapacity	int	풀 내부 컬렉션(Stack)의 초기 할당 크기.
maxSize	int	풀이 보관할 수 있는 최대 객체 수. 초과 시 actionOnDestroy가 호출된다.

여기서 중요한 점은, 이 파라미터들은 후처리 콜백 함수라는 것이다. 즉, 객체를 "어떻게 만들고, 어떻게 꺼내고, 어떻게 반환할지"의 핵심 로직은 Pool이 내부적으로 처리하고, 우리는 각 시점에 추가로 실행될 동작만 정의하면 된다.

collectionCheck, defaultCapacity, maxSize는 모두 선택적 파라미터로, 생략하면 기본값이 적용된다.

private Bullet CreateBullet()
{
	var obj = Instantiate(_curBullet, transform);
	return obj;
}

private void OnGetBullet(Bullet bullet)
{
	bullet.gameObject.SetActive(true);
}

private void OnReleaseBullet(Bullet bullet)
{
	bullet.gameObject.SetActive(false);
}

private void OnDestroyBullet(Bullet bullet)
{
	Destroy(bullet.gameObject);
}

Pool을 구현했으니, 이제 총알을 꺼내는 부분과 반환하는 부분을 마저 완성하면 된다.

public class Weapon : MonoBehaviour
{
    [SerializeField] private Bullet currentBullet;
    [SerializeField] private float fireDelay;
    
    private BulletSpawner _bulletSpawner;
    private float _lastFireTime = float.NegativeInfinity;

    private void Start()
    {
        _bulletSpawner = BulletSpawner.Instance;
        _bulletSpawner.AddBullet(currentBullet);
    }

    public void Fire()
    {
        if (Time.time - _lastFireTime < fireDelay) return;
        
        // Pool에서 총알을 얻어온 뒤, 초기화 함수 호출
        var bullet = _bulletSpawner.BulletPool.Get();
        bullet.Init(transform.forward, transform.position, 10f, 
	        _bulletSpawner.BulletPool);
        
        _lastFireTime = Time.time;
    }
}

Weapon은 Start()에서 BulletSpawner 싱글톤에 접근하고, AddBullet()으로 풀을 초기화한다.

Fire()가 호출되면 BulletPool.Get()으로 풀에서 총알을 꺼낸 뒤, Init()을 통해 발사 방향, 위치, 속도, 그리고 돌아갈 풀의 참조를 함께 전달한다.

public class Bullet : MonoBehaviour
{
    private IObjectPool<Bullet> _pool;
    
    private Vector3 _dir;
    private float _velocity;

    private float _despawnTime;
    private const float LIFE_TIME = 5f;
    
    public void Init(Vector3 dir, Vector3 pos, float velocity, IObjectPool<Bullet> pool)
    {
        _dir = dir.normalized;
        transform.position = pos;
        _velocity = velocity;
        _pool = pool;

        _despawnTime = Time.time + LIFE_TIME;
    }
    
    private void Update()
    {
        transform.position += _dir * (_velocity * Time.deltaTime);

        if (Time.time >= _despawnTime)
        {
            _pool.Release(this);
        }
    }
}

총알이 어느 풀로 돌아가야 하는지 알아야 하므로, Init() 시점에 돌아갈 풀의 참조를 IObjectPool<Bullet> 타입으로 저장한다. 이후 수명(LIFE_TIME)이 만료되면 _pool.Release(this)를 호출해 자기 자신을 풀로 반환한다.

■ 시스템 개선

총알이 한 종류뿐이라면 위 코드에 문제가 없지만, 여러 종류의 총알이 존재하면 문제점이 드러난다.

현재 AddBullet()을 호출하면 기존 풀을 덮어쓰고 새 풀을 생성한다. 이 경우 기존 풀의 참조가 사라져, 이미 발사된 총알이 반환될 풀을 잃게 된다.

또한 총알을 꺼낼 때마다 Init()에 방향, 위치, 속도, 풀 참조 등 모든 정보를 매번 전달하고 있어 비효율적이다.

1. BulletData

using UnityEngine;

[CreateAssetMenu(fileName = "BulletData", menuName = "Weapon/BulletData")]
public class BulletData : ScriptableObject
{
    public float Damage => damage;
    public float Velocity => velocity;
    public float LifeTime => lifeTime;
    public Bullet BulletPrefab => bulletPrefab;

    [SerializeField] private float damage;
    [SerializeField] private float velocity;
    [SerializeField] private float lifeTime;
    [SerializeField] private Bullet bulletPrefab;
}

총알마다 서로 다른 정보를 저장하기 위해 BulletData ScriptableObject를 만든다.

프리팹, 데미지, 속도, 수명 등 총알의 고정 데이터를 에셋으로 관리하면, 총알을 꺼낼 때마다 매번 값을 넘길 필요 없이 데이터 에셋 하나로 참조할 수 있다.

2. Bullet

using UnityEngine;
using UnityEngine.Pool;

public abstract class Bullet : MonoBehaviour
{
    protected BulletData BulletData;
    
    private IObjectPool<Bullet> _pool;
    
    private Vector3 _dir;
    private float _curTime = 0f;

    protected abstract bool OnHit(GameObject other);
    
    public void Init(BulletData bulletData, Vector3 dir, Vector3 pos)
    {
        BulletData = bulletData;
        _dir = dir;
        _curTime = 0f;
        
        transform.position = pos;
        transform.rotation = Quaternion.LookRotation(dir);
    }

    public void SetPool(IObjectPool<Bullet> pool)
    {
        _pool = pool;
    }
    
    private void Update()
    {
        transform.position += _dir * (BulletData.Velocity * Time.deltaTime);
        _curTime += Time.deltaTime;

        if (_curTime >= BulletData.LifeTime)
        {
            _pool.Release(this);
        }
    }

    private void OnTriggerEnter(Collider other)
    {
        if (other.CompareTag("Enemy"))
        {
            if(OnHit(other.gameObject)) _pool.Release(this);
        }
    }
}

기존 Bullet을 추상 클래스로 변경하여, 다양한 종류의 총알(예: 폭발탄, 관통탄)을 상속으로 확장할 수 있도록 한다.

OnHit()을 추상 메서드로 선언해 충돌 시 동작을 자식 클래스에서 정의하도록 한다. 반환값이 true이면 총알을 풀로 반환하고, false이면 반환하지 않아 관통 등의 동작을 구현할 수 있다.

또한 풀 참조를 Init()이 아닌 SetPool()로 분리했다. 풀 참조는 총알이 생성될 때 한 번만 설정하면 되지만, Init()은 풀에서 꺼낼 때마다 호출되므로 매번 풀을 다시 넘길 필요가 없기 때문이다.

using UnityEngine;

public class NormalBullet : Bullet
{
    protected override bool OnHit(GameObject other)
    {
			  // TODO : 일반 총알이 충돌했을 때 동작 구현
        return true;
    }
}

3. BulletSpawner

using System;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.Pool;

public class BulletSpawner : MonoBehaviour
{
    public static BulletSpawner Instance { get; private set; }
    private Dictionary<BulletData, IObjectPool<Bullet>> _pool;
    
    private void Awake()
    {
        if (Instance == null)
        {
            Instance = this;
            DontDestroyOnLoad(Instance.gameObject);
        }
        else
        {
            Destroy(gameObject);
            return;
        }
        
        _pool = new Dictionary<BulletData, IObjectPool<Bullet>>();
    }

    public Bullet GetBullet(BulletData data)
    {
        var pool = GetOrCreateBullet(data);
        return pool.Get();
    }
    
    private IObjectPool<Bullet> GetOrCreateBullet(BulletData data)
    {
        if(_pool.TryGetValue(data, out var bulletPool))
        {
            return bulletPool;
        }
        
        IObjectPool<Bullet> pool = null;
        
        pool = new ObjectPool<Bullet>(
            createFunc: () => 
            {
                var obj = Instantiate(data.BulletPrefab, transform);
                obj.SetPool(pool);
                return obj;
            },
            OnGetBullet,
            OnReleaseBullet,
            OnDestroyBullet,
            defaultCapacity: 10,
            maxSize: 100
            );
        
        _pool.Add(data, pool);
        return pool;
    }
    
    private void OnGetBullet(Bullet bullet)
    {
        bullet.gameObject.SetActive(true);
    }

    private void OnReleaseBullet(Bullet bullet)
    {
        bullet.gameObject.SetActive(false);
    }

    private void OnDestroyBullet(Bullet bullet)
    {
        Destroy(bullet.gameObject);
    }
  
}

BulletSpawner의 핵심 변경점은 풀의 자료구조다. 기존의 단일 ObjectPool<Bullet> 대신, Dictionary<BulletData, IObjectPool<Bullet>>로 변경하여 총알 종류별로 독립된 풀을 관리한다.

GetBullet()이 호출되면 내부의 GetOrCreateBullet()에서 해당 BulletData를 Key로 딕셔너리를 조회한다. 이미 풀이 존재하면 그대로 반환하고, 없으면 새 풀을 생성한 뒤 딕셔너리에 등록한다.

IObjectPool<Bullet> pool = null;
        
pool = new ObjectPool<Bullet>(
	createFunc: () => 
	{
		var obj = Instantiate(data.BulletPrefab, transform);
		obj.SetPool(pool);
		return obj;
	},
	OnGetBullet,
	OnReleaseBullet,
	OnDestroyBullet,
	defaultCapacity: 10,
	maxSize: 100
	);

여기서 주목할 부분은 createFunc 내부에서 pool 변수를 클로저로 캡처하고 있다는 점이다.

pool을 먼저 null로 선언한 뒤 ObjectPool을 생성하면, 람다가 pool 변수 자체를 캡처하므로 실제 총알이 생성되는 시점에는 이미 유효한 풀 참조를 갖게 된다. 이를 통해 Init()에서 매번 풀을 전달하는 대신, 생성 시 한 번만 SetPool()로 등록하여 불필요한 반복을 제거할 수 있다.

4. Player & Weapon

using System;
using UnityEngine;

public class Weapon : MonoBehaviour
{
    [SerializeField] private float fireDelay;
    
    private BulletData _loadedBullet;
    private float _lastFireTime = float.NegativeInfinity;
    
    public void Fire()
    {
        if (Time.time - _lastFireTime < fireDelay) return;
        
        var bullet = BulletSpawner.Instance.GetBullet(_loadedBullet);
        bullet.Init(_loadedBullet, transform.forward, transform.position);
        
        _lastFireTime = Time.time;
    }

    public void SwapBullet(BulletData bullet)
    {
        _loadedBullet = bullet;
        
    }
}

using System;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.InputSystem;

public class Player : MonoBehaviour
{
    [SerializeField] private Weapon equippedWeapon;
    [SerializeField] private List<BulletData> inventory;

    private int _curInventoryIndex = 0;
    private GameInput _gameInput;
    private Camera _camera;
    private Plane _aimPlane;

    private void Awake()
    {
        _camera = Camera.main;
        _aimPlane = new Plane(Vector3.up, transform.position.y);
        
        _gameInput = new GameInput();
        
        equippedWeapon.SwapBullet(inventory[_curInventoryIndex]);
    }

    private void Update()
    {
        var ray = _camera.ScreenPointToRay(Mouse.current.position.ReadValue());

        if (_aimPlane.Raycast(ray, out var dist) == true)
        {
            var hit = ray.GetPoint(dist);
            var dir = hit - transform.position;
            dir.y = 0;

            if (dir.sqrMagnitude > 0.001f)
            {
                transform.rotation = Quaternion.LookRotation(dir);
            }
        }
    }

    private void OnEnable()
    {
        _gameInput.Player.Enable();
        
        _gameInput.Player.Fire.performed += OnStartFire;
        _gameInput.Player.Reload.started += OnStartReload;
    }

    private void OnDisable()
    {
        _gameInput.Player.Disable();
        
        _gameInput.Player.Fire.performed -= OnStartFire;
        _gameInput.Player.Reload.started -= OnStartReload;
    }

    private void OnDestroy()
    {
        _gameInput.Dispose();
    }

    private void OnStartFire(InputAction.CallbackContext _)
    {
        equippedWeapon.Fire();
    }

    private void OnStartReload(InputAction.CallbackContext _)
    {
        _curInventoryIndex = (_curInventoryIndex + 1) % inventory.Count;
        equippedWeapon.SwapBullet(inventory[_curInventoryIndex]);
    }
}

기존에는 Weapon이 직렬화된 Bullet 프리팹을 직접 들고 있었지만, 총알 종류가 여러 가지로 늘어나면서 구조를 변경했다. Player에 BulletData 리스트로 간단한 인벤토리를 구성하고, 장전 키(Reload)를 누르면 인벤토리의 다음 총알 데이터를 Weapon에 전달하도록 했다.

Weapon은 더 이상 특정 총알에 종속되지 않으며, SwapBullet()을 통해 언제든 장전된 총알을 교체할 수 있다. Fire() 호출 시에는 현재 장전된 BulletData를 기반으로 BulletSpawner에서 해당 종류의 총알을 꺼내 발사한다.

최종 결과

[Unity, C#] 델리게이트에 대한 모든것(Action, Func, Lambda)

브라더스톤 — Thu, 7 May 2026 16:05:06 +0900

■ 델리게이트(Delegate)

게임 개발을 하다 보면 “어떤 일이 일어났을 때 이 코드를 실행해 줘”라는 패턴이 굉장히 많다. 예를 들어,

private void OnTriggerEnter(Collider other)
{
	if(other.Tag("Wall") == true)
	{
		//충돌된 오브젝트의 태그가 Wall이라면 실행...
	}
}

[간단한 충돌 코드]

위 코드처럼 충돌 발생 시 실행할 코드를 작성한다. 하지만 충돌 시 실행할 동작이 상황에 따라 매번 달라져야 한다면 어떻게 될까?

public class Bullet
{
	private Player _player;
	private Enemy _enemy;
	private Manager _manager;
	
	private void OnTriggerEnter(Collider other)
	{
		if(other.CompareTag("Wall"))
		{
			// 이런 상황일 땐...
			_player.DoSomething();
			
			// 저런 상황일 땐...
			_enemy.DoSomething();
			
			// 요런 상황일 땐...
			_manager.DoSomething();
		}
	}
}

[복잡해진 충돌 코드]

이처럼 Bullet이 Player, Enemy, Manager 등 모든 객체를 직접 참조하고 있으면 결합도가 높아진다. 새로운 클래스가 추가될 때마다 Bullet 코드를 수정해야 하고, 어떤 상황에 어떤 메서드가 호출되는지 한눈에 파악하기도 어려워진다.

이런 문제를 해결하기 위해 등장한 것이 바로 델리게이트(Delegate)이다.

1. 델리게이트(Delegate, 대리자)의 사용

변수에 숫자나 문자열을 담듯이, 델리게이트 변수에는 메서드를 담을 수 있다. 메서드를 값처럼 저장하고, 전달하고, 원하는 시점에 호출할 수 있게 되는 것이다.

// 1. 델리게이트 타입 선언 — 반환형과 매개변수를 지정한다
public delegate void MyDelegate(string msg);

// 2. 델리게이트 변수 선언
public MyDelegate onEvent;

// 3. 메서드 등록
onEvent += SayHello;
onEvent += SayBye;

// 4. 호출 — 등록된 메서드가 순서대로 실행된다
onEvent?.Invoke("Unity");

// 결과:
// "안녕, Unity"
// "잘가, Unity"

private void SayHello(string name)
{
	Debug.Log($"안녕, {name}");
}

private void SayBye(string name)
{
	Debug.Log($"잘가, {name}");
}

[델리게이트 기본 사용법]

델리게이트의 핵심을 정리하면 다음과 같다.

delegate 반환형 이름(매개변수) : 델리게이트 타입을 선언한다. 어떤 형태의 메서드를 담을 수 있는지를 정의한다.
델리게이트타입 변수명 : 델리게이트 변수를 선언한다. 이 변수에 같은 시그니처(반환형, 매개변수)를 가진 메서드를 등록할 수 있다.
+= : 메서드를 등록(구독)한다. 여러 개를 등록하면 모두 순서대로 실행된다.
-= : 등록된 메서드를 해제한다.
?.Invoke() — 등록된 메서드가 있을 때만 안전하게 호출한다. ?를 빼면 등록된 메서드가 없을 때 NullReferenceException이 발생한다.

이처럼 델리게이트를 사용하면 메서드를 변수처럼 사용할 수 있게 된다. 앞서 본 예제 코드를 델리게이트로 수정하면 아래와 같이 간략하게 정리된다.

public class Bullet
{
	public delegate void OnHitWallDelegate();
	public OnHitWallDelegate OnHitWall;
	
	private void OnTriggerEnter(Collider other)
	{
		if(other.CompareTag("Wall"))
		{
			OnHitWall?.Invoke();
		}
	}
}

public class Player : MonoBehaviour
{
	[SerializeField] private Bullet _bullet;
	
	private void Start()
	{
		_bullet.OnHitWall += HandleHitWall;
	}
	
	private void HandleHitWall()
	{
		Debug.Log("Player: 총알이 벽에 맞았다!");
	}
}

[외부에서 동작을 등록]

이제 Bullet은 벽에 부딪혔다는 사실만 알리고, 실제로 무엇을 할지는 외부에서 결정한다.

Bullet이 Player, Enemy, Manager를 직접 알 필요가 없으므로 결합도가 낮아지고, 새로운 동작을 추가할 때도 Bullet 코드를 수정할 필요 없이 OnHitWall +=로 등록만 하면 된다.

하지만 매번 delegate void OnHitWallDelegate();처럼 델리게이트 타입을 직접 선언하는 것은 번거롭다. 시그니처가 달라질 때마다 새로운 델리게이트 타입을 만들어야 하기 때문이다. 이 불편함을 해결하기 위해 C#에서는 Action과 Func를 제공한다.

■ Action<T>, Func<T, TResult>

public delegate void OnHitWallDelegate();
public OnHitWallDelegate OnHitWall;

앞서 본 것처럼 델리게이트를 사용하려면 먼저 타입을 선언하고, 그다음에 변수를 만들어야 했다. 델리게이트가 늘어날수록 타입 선언도 함께 늘어나고, 시그니처를 잘못 정의하는 등 실수가 발생할 가능성도 높아진다.

public class GameEvents
{
	public static Action OnGameOver;
	public static Action<int> OnScoreChanged;
}

// 구독
GameEvents.OnGameOver += DoSomething;

// 호출
GameEvents.OnGameOver?.Invoke();

따라서 C#에서는 자주 쓰는 시그니처를 매번 선언할 필요 없도록, 제네릭 델리게이트인 Action과 Func를 미리 제공한다. 사용법은 델리게이트와 동일하지만, 타입 선언이 사라진 것을 알 수 있다.

무조건 델리게이트를 static으로 선언해야 하는 것은 아님.

// 파라미터가 int, float 형식이고, 반환값이 없음
Action<int, float>
// 파라미터가 int 타입이고, 반환값 형식이 bool 타입.
Func<int, bool>

Action과 Func의 차이는 반환값의 유무다. Action은 반환값이 없고(void), Func는 마지막 제네릭 파라미터가 반환 타입이 된다.

// Action 내부 선언
public delegate void Action();
public delegate void Action<in T>(T obj);
public delegate void Action<in T1, in T2>(T1 arg1, T2 arg2);

// Func 내부 선언
public delegate TResult Func<out TResult>();
public delegate TResult Func<in T, out TResult>(T arg);

Action과 Func의 실제 선언부를 보면 결국 델리게이트라는 것을 알 수 있다. Action과 Func는 특별한 기능이 아니라, 우리가 직접 선언하던 델리게이트를 C#이 미리 만들어둔 것에 불과하다.

Action은 매개변수를 최대 16개까지 받을 수 있으며, Func 역시 매개변수 최대 16개 + 반환 타입 1개를 지원한다.

콜백(Callback) 함수

"지금 당장 실행하지 말고, 나중에 특정 조건이 되면 이 메서드를 대신 호출해 줘"라는 의미다.

일반적인 메서드 호출은 내가 원하는 시점에 직접 호출한다. 하지만 콜백은 다르다. 메서드를 미리 등록해 두고, 어떤 일이 일어났을 때 상대 쪽에서 대신 호출해 주는 방식이다. 델리게이트는 이 콜백을 구현하는 대표적인 수단이다.

▶ UnityAction과 UnityEvent

UnityAction은 UnityEvent에 메서드를 등록할 때 사용하는 델리게이트이며, 기능적으로는 Action과 동일하다. UnityEvent는 코드와 인스펙터에서 모두 이벤트를 연결할 수 있다는 것이 가장 큰 차이점이다.

// UnityAction — 코드에서만 등록 가능 (Action과 동일)
public UnityAction onDeathAction;

// UnityEvent — 코드 + 인스펙터 둘 다 등록 가능
public UnityEvent onDeathEvent;

[인스펙터에 표시된 모습]

■ event 키워드

public Action OnDeath;

// 외부 클래스에서
player.OnDeath = DoSomething;   //기존 등록이 전부 삭제됨
player.OnDeath?.Invoke();       //아무 곳에서나 호출 가능

델리게이트를 public으로 선언하면, 외부에서 두 가지 위험한 동작이 가능하다.

=로 덮어쓰기 : 다른 곳에서 등록한 메서드가 전부 날아간다.
외부에서 직접 Invoke() 호출 : 의도하지 않은 시점에 이벤트 발동.

콜백의 핵심은 특정 상황이 발생했을 때 선언한 쪽에서 대신 호출하는 것인데, 위처럼 외부에서 마음대로 덮어쓰거나 호출할 수 있다면 일반 메서드를 직접 호출하는 것과 다를 바가 없다.

public event Action OnDeath;

// 외부 클래스에서
player.OnDeath = DoSomething;   //컴파일 에러!
player.OnDeath?.Invoke();       //컴파일 에러!

player.OnDeath += DoSomething;  //외부에서 이벤트 구독과 해제만 가능
player.OnDeath -= DoSomething;

델리게이트에 event 키워드를 붙이면, 외부에서는 +=(구독)과 -=(해제)만 가능해진다. Invoke()는 오직 이벤트를 선언한 클래스 내부에서만 호출할 수 있으므로, "언제 이벤트를 발동할지"는 해당 클래스가 온전히 제어하게 된다.

즉 event 키워드는 델리게이트의 기능을 바꾸는 것이 아니라, 외부 접근을 제한하는 보호 장치라고 이해하면 된다.

■ 람다식(Lambda Expression)

앞서 델리게이트에 메서드를 등록할 때, 매번 별도의 메서드를 작성해야 했다.

public event Action OnDeath;

private void Start()
{
	OnDeath += HandleDeath;
}

private void HandleDeath()
{
	Debug.Log("사망!");
}

간단한 동작 하나를 등록하기 위해 메서드를 따로 만들고, 이름을 짓고, 등록하는 과정을 거쳐야 한다. 람다식을 사용하면 이 과정을 한 줄로 줄일 수 있다.

람다식은 “익명 함수”를 간결하게 작성하는 문법이다.

OnDeath += () => Debug.Log("사망!");

람다식은 이름 없는 메서드를 그 자리에서 바로 작성하는 문법이다. => 기호를 기준으로 왼쪽이 매개변수, 오른쪽이 실행할 코드다.

1. 기본 문법

// 매개변수 없음
() => Debug.Log("Hello");

// 매개변수 1개 — 괄호 생략 가능
x => Debug.Log(x);

// 매개변수 2개 이상 — 괄호 필수
(x, y) => Debug.Log(x + y);

OnDeath += () =>
{
	Debug.Log("사망!");
	Debug.Log("게임 오버 화면 표시");
	GameManager.Instance.GameOver();
};

실행할 코드가 여러 줄이면 {}로 감싸면 된다.

2. Action, Func와 사용하기

// Action — 반환값 없음
Action<string> greet = (name) => Debug.Log($"안녕, {name}!");
greet("Unity");  // "안녕, Unity!"

// Func — 반환값 있음
Func<int, int, int> add = (a, b) => a + b;
int result = add(3, 5);  // 8

람다식은 델리게이트 타입 변수에 바로 대입할 수 있다.

// return 생략 가능
Func<int, int> double1 = x => x * 2;

// {} 사용 시 return 필수
Func<int, int> double2 = x =>
{
	return x * 2;
};

Func에서 실행할 코드가 한 줄이면 return을 생략할 수 있다. 하지만 {}를 사용하면 return을 명시해야 한다.

▶ 람다식은 언제 사용하면 좋을까?

// 간단한 동작 — 람다식이 적합
OnDeath += () => Debug.Log("사망!");

// 복잡한 동작 — 별도 메서드가 적합
OnDeath += HandleDeath;

private void HandleDeath()
{
	SavePlayerData();
	ShowGameOverUI();
	PlayDeathAnimation();
	ReportToServer();
}

짧고 단순한 동작을 등록할 때는 람다식이 편리하다. 하지만 로직이 복잡하거나 여러 곳에서 재사용해야 한다면, 별도의 메서드로 분리하는 것이 가독성과 유지보수 면에서 더 좋다.

// 해제 불가 — 등록할 때와 해제할 때의 람다가 서로 다른 인스턴스
OnDeath += () => Debug.Log("사망!");
OnDeath -= () => Debug.Log("사망!");  // 해제되지 않음!

// 해제가 필요하면 변수에 담아두기
Action deathHandler = () => Debug.Log("사망!");
OnDeath += deathHandler;
OnDeath -= deathHandler;  // 정상적으로 해제됨

또한 람다식으로 등록한 메서드는 -=로 해제하기 어렵다는 점도 주의해야 한다.

■ 캡쳐(Capture)

람다식은 자신이 선언된 위치의 외부 변수를 사용할 수 있다. 이때 람다식이 외부 변수를 기억하고 가져가는 것을 캡처(Capture)라고 한다.

private void Start()
{
	string playerName = "용사";
	
	Action greet = () => Debug.Log($"안녕, {playerName}!");
	greet();  // "안녕, 용사!"
}

greet 람다식은 자신의 매개변수가 아닌 외부 변수 playerName을 사용하고 있다. 이것이 캡처다. 얼핏 보면 당연한 동작 같지만, 여기에는 주의해야 할 함정이 있다.

▶ 캡처는 값이 아니라 변수 자체를 기억

private void Start()
{
	int count = 0;
	
	Action increase = () => count++;
	
	increase();
	increase();
	increase();
	
	Debug.Log(count);  // 3 — 람다 안에서 수정한 값이 반영됨
}

람다식은 캡처 시점의 값을 복사하는 것이 아니라, 변수 자체를 참조한다. 따라서 변수의 값이 변하면 람다식의 결과도 달라진다. 이 개념을 모르면 아래와 같은 문제가 발생할 수 있다.

private void Start()
{
	Action[] actions = new Action[3];
	
	for (int i = 0; i < 3; i++)
	{
		actions[i] = () => Debug.Log(i);
	}
	
	actions[0]();  // 3
	actions[1]();  // 3
	actions[2]();  // 3
}

0, 1, 2가 출력될 것 같지만, 실제로는 전부 3이 출력된다. 세 개의 람다식이 모두 같은 변수 i를 캡처하고 있고, 반복문이 끝난 시점에 i의 값은 3이기 때문이다.

이 문제를 해결하려면 반복문 안에서 지역 변수에 값을 복사해 두면 된다.

private void Start()
{
	Action[] actions = new Action[3];
	
	for (int i = 0; i < 3; i++)
	{
		int captured = i;  // 값을 복사
		actions[i] = () => Debug.Log(captured);
	}
	
	actions[0]();  // 0
	actions[1]();  // 1
	actions[2]();  // 2
}

int captured = i;로 매 반복마다 새로운 지역 변수를 만들면, 각 람다식이 서로 다른 변수를 캡처하게 되어 의도한 대로 동작한다.

private void Start()
{
	GameObject effect = Instantiate(effectPrefab);
	
	DOTween.Sequence()
		.AppendInterval(3f)
		.OnComplete(() =>
		{
			// 3초 후 실행 — 이 시점에 effect가 이미 Destroy 되었다면?
			effect.SetActive(false);  // MissingReferenceException!
		});
}

Unity에서 캡처를 사용할 땐 특히 더 조심해야 하는 점이 있는데, 람다식이 effect를 캡처한 뒤, 실제 호출 시점에 해당 오브젝트가 파괴되어 있으면 MissingReferenceException이 발생한다. 이런 경우 null 체크를 추가해야 한다.

.OnComplete(() =>
{
	if (effect != null)
	{
		effect.SetActive(false);
	}
});

▶ 캡처를 활용한 매개변수 바인딩

캡처는 단순히 외부 변수를 읽는 것뿐만 아니라, 구독하는 시점에 데이터를 미리 전달해 두고, Invoke 될 때 해당 데이터와 함께 실행되도록 할 수 있다.

public Action OnFire;

// 구독 시점 — data를 캡처해서 미리 묶어둠
BulletData data = new BulletData(speed: 10, damage: 50);
OnFire += () => CreateBullet(data);

// Invoke 시점 — 캡처해둔 data와 함께 실행됨
OnFire?.Invoke();

OnFire는 매개변수가 없는 Action이지만, 람다식이 data를 캡처하고 있기 때문에 Invoke 시점에 CreateBullet에 데이터를 함께 넘길 수 있다.

이 방식은 시그니처가 맞지 않는 메서드를 델리게이트에 등록할 때도 활용할 수 있다.

public Action OnHit;

// PlaySound는 string 매개변수가 필요하지만, OnHit은 매개변수가 없다
string soundName = "Hit_SFX";
OnHit += () => PlaySound(soundName);  // 캡처로 해결

단, 앞서 설명한 것처럼 캡처는 값이 아니라 변수를 참조한다는 점을 잊지 말자. 캡처 이후 변수의 값이 바뀌면 Invoke 시점의 결과도 달라진다.

1. 리치마작을 배워보자! - 마작의 기본

브라더스톤 — Sun, 22 Mar 2026 21:57:47 +0900

■ 마작 패

마작 패

마작의 패는 숫자가 적힌 수패(만수패, 통수패, 삭수패)와, 글자가 적힌 자패(동·남·서·북의 풍패와 백·발·중의 삼원패)로 구성된다. 각 패는 동일한 종류가 총 4장씩 존재한다.

수패 중에서 1과 9는 노두패, 2~8은 중장패라고 부른다.

마작은 기본적으로 4명(또는 규칙에 따라 3명)이 참여하며, 각 플레이어는 처음에 13장의 패를 받는다. 자신의 턴이 되면 패산(쌓아놓은 패 더미)에서 패를 한 장 뽑고, 그 후 패 한 장을 버리는 방식으로 게임을 진행한다.

■ 마작의 승리! 화료(和了)의 조건

마작은 4개의 몸통(멘츠)과 1개의 머리(또이츠)를 완성하면 화료(승리)할 수 있다. 머리는 동일한 패 2개로 이루어지며, 몸통은 연속된 수패 3장(예: 2만·3만·4만) 또는 같은 패 3장(刻子-커쯔)을 모아 만들어진다.

연속된 수패 3장을 슌쯔(順子)라 부르고, 같은 패 3장을 커쯔(刻子) 라 부른다.

[화료의 방식, 쯔모와 론]

화료에는 두 가지 방식이 있다. 하나는 직접 패를 뽑아 완성하는 “쯔모(和ホ)”와, 상대의 버림패로 완성하는 “론(栄)”이 있다.

하지만 모든 상황에서 쯔모와 론이 가능한 것은 아니다. 화료를 위해선 반드시 한 판 이상의 역이 필요하며, 특정 조건에서는 론이 불가능한 경우도 존재한다.

1. 상대의 버림패를 가져오는 치, 퐁

역을 배우기 전에 치와 퐁에 대해 알아보자.

마작에서는 패산에서 가져온 패만으로 패를 완성하기 어려운 경우가 많기 때문에, 자신의 패를 완성하기 위해 다른 플레이어의 버림패를 가져올 수 있다. 이러한 행동을 울기(후로 - 鳴き)라 한다.

후로라는 단어는 역을 설명하면서 많이 나오는 단어니 꼭 기억해 두자.

▶ 치(チー)

2삭과 3삭을 가지고 있을 때, 1삭이나 4삭이 들어오면 하나의 슌쯔를 만들 수 있다.

이때, 내 왼쪽 플레이어가 슌쯔를 완성할 수 있는 패를 버리면 치(チー)를 할 수 있다. 치는 반드시 왼쪽 플레이어의 버림패에서만 가능하다.

치를 하면 완성된 몸통(멘츠)을 한쪽에 따로 놓고 패를 공개한다. 이후 자신의 패에서 한 장을 버리며 턴이 종료된다.

단, 다음과 같은 경우는 주의해야 한다. 예를 들어 2삭·3삭·4삭으로 이미 슌쯔를 완성한 상태에서, 치를 통해 1삭·2삭·3삭이라는 새로운 슌쯔를 만들었다고 하자.

이때 4삭을 버리는 것은 금지된다. 이는 치를 통해 만든 슌쯔와 관련된 패를 바로 교체하는 행위이기 때문이다.

이러한 행위를 쿠이카에(食い替え, 울어 바꾸기)라고 하며, 일반적으로 금지되는 플레이이다. 대부분의 온라인 마작에서는 시스템적으로 제한되며, 오프라인 마작에서도 반칙으로 간주된다.

후에 설명할 퐁과 깡도 모두 위와 같은 단계로 진행된다.

▶ 퐁(ポン)

[퐁]

3통 두 장을 가지고 있는 상태에서 3통이 한 장 더 있으면 하나의 커쯔를 만들 수 있다.

이때, 다른 플레이어가 3통을 버리면 플레이어의 위치와 관계없이 퐁(ポン)을 할 수 있다. 퐁을 하면 완성된 몸통(멘쯔)을 공개하여 한쪽에 놓고, 이후 자신의 패에서 한 장을 버리며 턴이 종료된다.

[퐁한 패를 공개하는 방식]

퐁은 치와 달리 모든 플레이어의 버림패를 가져올 수 있다. 따라서 어떤 플레이어로부터 패를 가져왔는지를 표시해야 한다. 일반적으로는 가져온 패의 위치에 따라 해당 패를 가로로 눕혀 놓는 방식으로 표현한다.

예를 들어, 내 기준 왼쪽 플레이어에게서 가져왔다면 왼쪽에 있는 패를 눕혀 놓는다.

온라인 마작들은 이를 알아서 표시해 준다.

퐁을 하게 되면 커쯔를 공개하게 되는데, 이를 밍커(明刻)라 하고 반대로 퐁 하지 않은 커쯔를 안커(暗刻) = 숨겨진 커쯔라 한다.

2. 4개의 패를 모아버렸다! 깡(カン)!

한 개의 커쯔(3개의 남)가 있는 상황에서, 상대가 남 한 장을 버릴 때 깡을 할 수 있다. 깡을 하게 되면 동시에 상대방의 버림패를 가져온 뒤, 패를 공개한다.

같은 패 3장(예: 남 3장)을 가지고 있는 상태에서, 다른 플레이어가 동일한 패를 버리면 깡(칸カン)을 할 수 있다.

깡을 하면 상대의 버림패를 가져와 같은 패 4장을 만들고, 이를 공개하여 한쪽에 놓는다.

깡의 가장 큰 특징은 치나 퐁과 달리, 패를 공개한 후 바로 턴이 끝나는 것이 아니라 영상(嶺上)에서 패를 한 장 더 가져온다는 점이다. 이 패를 영상패(嶺上牌)라고 한다.

영상패에 대해서는 도라와 같이 설명하겠다.

영상패를 가져온 뒤에는, 다른 경우와 마찬가지로 패를 한 장 버리고 턴을 마친다.

커쯔를 들고 있는 상태에서 상대의 버림패로 깡을 하는 경우를 “대명깡”이라 한다.

[전설의 스깡즈 자일색 영상 일부분]

중 3장을 퐁한 상태에서, 동일한 패인 중을 한 장 더 뽑으면 “깡”을 할 수 있다. 이 경우, 기존에 공개된 퐁에 해당 패를 추가하여 4장을 만들고, 추가된 패는 일반적으로 위에 겹쳐 놓는 방식으로 표시한다. 이후 영상(嶺上)에서 패를 한 장 더 가져온다.

이미 퐁을 한 상태에서는 상대의 버림패로 깡을 할 수 없으며, 반드시 자신이 직접 뽑은 패로만 가능하다. 이러한 깡을 가깡(加槓)이라고 한다.

[암깡]

같은 패 4장을 모두 자신의 손패로 가지고 있는 경우에도 깡을 할 수 있으며, 이를 암깡(暗槓)이라고 한다.

암깡은 다른 울기와 달리 외부에서 가져온 패가 없기 때문에, 패를 공개할 때 양 끝의 패를 뒤집어 놓고 가운데 두 장만 보이도록 배치하는 방식으로 표시한다.

암깡을 한 뒤에는 다른 깡과 마찬가지로 영상에서 패를 한 장 더 가져온다.

깡의 종류	명칭
상대의 버림패로부터 깡	대명깡(大明槓)
퐁 후에 내가 뽑은 패로 깡	가깡(加槓) 혹은 소명깡
손패 4장으로 깡	암깡(暗槓)

깡을 할 수 있다고 해서 항상 깡을 하는 것이 좋은 것은 아니다. 깡을 하면 새로운 “도라” 라고 불리는 패가 공개되며, 이는 모든 플레이어의 점수를 높일 수 있는 요소가 된다.

따라서 자신이 유리한 상황이 아니라면, 깡을 신중하게 선택하는 것이 좋다.

3. 점수를 올리는 가장 쉬운 방법 : 도라

리치마작을 하다 보면(온라인) 화면의 한쪽에 여러 장의 패가 표시되는데, 이 부분이 바로 도라 표시패이다. 표시된 패의 다음 패가 도라가 된다.

8삭이 표시되어 있다면 9삭이 도라가 되며, 9만이 표시되어 있다면 1만이 도라가 된다.
자패의 경우, 동 → 남 → 서 → 북 순으로 이어지며, 동이 도라 표시패라면 남이 도라가 된다.
백 → 발 → 중 순서를 가지며, 백이 표시되어 있다면 발이 도라가 된다.

이 외에도 5만, 5통, 5삭 중 일부는 적도라(아카도라)로 존재한다. 이는 일반적으로 각 종류당 1장씩 포함되며, 해당 패를 가지고 있으면 도라와 동일하게 추가 점수를 얻을 수 있다.

도라는 그 자체로는 역이 아니지만, 가지고 있는 개수만큼 점수가 추가되기 때문에 점수를 크게 올릴 수 있는 중요한 요소이다.

깡을 하면 새로운 도라 표시패가 공개된다. 이로 인해 전체적으로 높은 타점이 나올 가능성이 커지므로, 상황에 따라 유리할 수도 있고 불리할 수도 있다. 따라서 깡은 신중하게 선택하는 것이 좋다.

[뒷도라]

이후에 설명할 “리치”를 선언한 뒤 화료하게 되면, 추가로 뒷도라(우라도라, 裏ドラ)를 확인할 수 있다.

온라인 마작에서는 패산의 모습이 보이지 않기 때문에 구조를 직접 확인하기 어렵지만, 실제 오프라인 마작 테이블에서는 다음과 같은 형태로 구성되어 있다.

[마작 테이블과 왕패]

깡을 하면 영상패에서 패를 한 장 가져온다. 그 후 깡도라 표시패를 뒤집어 새로운 도라 표시패를 추가로 공개한다.

리치를 선언한 뒤 화료하게 되면, 이미 공개된 도라 표시패의 개수만큼 뒷도라 표시패를 추가로 뒤집어 도라를 확인한다.

온라인 마작은 시스템이 자동으로 처리해 주니, 이러한 개념이 있다는 것만 알면 된다.

■ 패만 맞춘다고 끝이 아니다, 역(役)

앞서 4개의 몸통과 1개의 머리를 완성하더라도, 반드시 화료할 수 있는 것은 아니라고 설명했다.

화료를 하기 위해서는 반드시 1판 이상의 역(役)이 필요하며, 역이 없는 경우에는 패를 완성해도 화료할 수 없다. 또한 역의 종류와 난이도에 따라 1판, 2판, 3판, 6판, 역만 등으로 구분되며, 이에 따라 얻을 수 있는 점수가 크게 달라진다.

앞서 치, 퐁, 깡에 대해 설명했는데, 이러한 행동을 하면 후로(副露, 흔히 ‘울었다’라고 표현) 상태에 들어가게 된다.

역의 조건 중에는 후로 상태에서는 성립하지 않고, 멘젠(門前, 후로를 하지 않은 상태)일 때만 성립하는 역이 많다. 따라서 역에 익숙하지 않다면 함부로 울지 않는 것이 중요하다.

1. 리치마작의 꽃, 리치(立直, 판수1)<멘젠>

[리치를 걸 수 있는 상황]

먼저 위 패를 보자. 6삭을 뽑은 상태에서 어떤 패를 버리면 텐파이가 될 수 있을까?

한 개의 패를 쯔모(혹은 론)했을 때 화료할 수 있는 상태를 텐파이(聴牌) 상태라고 한다.
3만, 3만, 4만, 5만, 1삭, 2삭, 4삭, 5삭, 6삭, 6삭, 7삭, 8삭, 9삭이 있는 상태에서 6삭을 쯔모한 상황이다.

3만을 버리면 3만·4만·5만으로 슌쯔를 만들 수 있고, 6삭 두 장으로 머리(또이츠)를 구성할 수 있다. 이 경우 3삭을 기다리는 텐파이 상태가 된다.

이처럼 울지 않은 상태(멘젠)에서 텐파이가 되면 리치(立直)를 선언할 수 있다.

온라인 마작에서는 리치 버튼을 누르면 어떤 패를 버려야 텐파이 상태로 들어가는지 알려주기 때문에 크게 부담 가지지 않아도 된다.

[리치를 걸고 난 뒤]

리치를 선언하면 1000점을 지불하고 자신의 앞에 리치봉을 놓는다. 리치를 한 이후에는 패의 형태를 변경할 수 없으며, 이후에는 쯔모한 패를 그대로 타패해야 한다.

특정 패를 기다리고 있는 상태라면, 그 패를 대기패(화료패)라고 한다. 예를 들어 3삭을 기다리고 있는 상태에서 상대가 3삭을 버리면 “론”으로 화료할 수 있다.

또는 내가 3삭을 직접 뽑으면 “쯔모”로 화료할 수 있다.

론으로 화료하게 되면, 해당 패를 버린 플레이어로부터 점수를 모두 가져오게 된다(이를 흔히 “쏘였다”고 표현한다).

반대로 쯔모로 화료하게 되면, 나를 제외한 다른 플레이어들이 점수를 나누어 지불하게 된다.

단, 내가 동 위치에 있는 상태에서 상대방이 쯔모하게 되면 남들보다 더 점수를 내야 한다.

정리하자면 울지 않고(멘젠), 텐파이 상태, 패산에 패가 4장 이상 남아있는 상황이라면 리치를 걸 수 있다.

▼ 멘젠 상태에서 할 수 있는 역

이름	판수	조건
일발	1	리치 선언 후 한 턴 이내(아무도 치,퐁,깡을 하지 않음)에 화료하는 경우. → 론, 쯔모 둘다 가능하다.
우라도라(뒷도라)	n	리치 화료 시에만 확인 가능한 보너스 도라. 도라 표시패 개수만큼 뒤집는다.
멘젠쯔모	1	리치를 걸지 않아도, 멘젠 상태에서 쯔모하는 경우 성립되는 역이다.
더블리치	2	첫 턴에서(모든 플레이어가 멘젠) 타패 전에 리치하는 경우 성립된다.

▶ 무지성 리치는 안된다!

초보자일 때는 리치 버튼이 보이면 바로 누르고 싶어 지지만, 상황을 고려하지 않고 리치를 걸면 오히려 불리해질 수 있다.

위와 같은 상황에서 내가 화료하기 위해 필요한 패는 오로지 3삭 하나뿐이다. 만약 3삭이 이미 여러 장 버려져 있다면, 남아 있는 3삭의 개수가 적어 화료 확률이 크게 낮아진다.

또한 리치를 선언하면 이후에는 패의 형태를 변경할 수 없기 때문에, 수비적인 선택이 매우 제한된다. 상황에 따라 안전패를 선택하기 어려워져, 오히려 상대에게 쏘일 위험이 커질 수 있다.

따라서 리치는 가능한 한 대기패의 종류가 많고(좋은 대기), 화료 확률이 높은 상황에서 거는 것이 좋다.

2. 울어도 된다! 탕야오(断么九)와 역패(役牌)

[탕야오와 쿠이탕]

수패 중 1과 9(노두패/요구패)와 자패(동·남·서·북, 백·발·중)가 하나도 포함되지 않은 상태로 화료하면 탕야오(断么九)가 성립한다.

수패 중에서 1과 9를 노두패(老頭牌 혹은 요구패)라고 하며, 자패는 풍패와 삼원패를 포함한다.

즉, 손패가 2~8의 만수, 통수, 삭수로만 이루어져야 성립하는 역이다.

울어서 만든 탕야오를 쿠이탕(喰い断)이라고 하며, 룰에 따라 이를 인정하지 않는 경우도 있지만, 많이 플레이하는 작혼에서는 유효한 역으로 인정한다.

탕야오는 비교적 빠르게 만들 수 있는 역이기 때문에, 상대가 빠르게 리치를 걸었거나 판의 흐름이 불리하다고 판단될 때 빠르게 화료하여 판을 넘기는 전략으로 활용할 수 있다.

[자풍과 장풍]

마작에는 자풍(自風)과 장풍(場風)이라는 개념이 있다. 내가 앉아 있는 자리의 바람을 자풍이라고 하며(위 예시에서는 서), 현재 판의 바람을 장풍이라고 한다(위 예시에서는 동1국이므로 동).

이 개념이 중요한 이유는, 자풍이나 장풍에 해당하는 바람 패를 커쯔로 완성하면, 이 역시 1판의 역으로 인정되기 때문이다.

위와 같이 동1국에서 서쪽에 앉아 있을 경우, 서를 커쯔로 만들면 자풍 역이 성립하고, 동을 커쯔로 만들면 장풍 역이 성립한다.

만약 동1국에서 동쪽에 앉아 있는 상태에서 동 커쯔를 만들었다면, 자풍과 장풍이 동시에 성립하여 2판을 얻을 수 있다.

또한 삼원패(백·발·중) 중 하나만 커쯔로 만들어도 이 역시 자풍,장풍과 관계 없이 역으로 성립한다.

3. 몸통이 모두 슌쯔! 핑후(平和)<멘젠>

초보자들은 멘탕핑(멘젠,탕야오,핑후)을 만들어 화료하라고 한다. 멘젠과 탕야오와 달리 핑후는 그 조건이 조금 복잡하다.

[핑후가 가능한 예시]

패산의 상태를 먼저 살펴보자. 234삭으로 슌쯔, 345삭으로 슌쯔, 456통으로 슌쯔, 8통 또이츠(머리), 4만 5만을 가지고 있는 상태에서 두 종류의 패(3만, 6만)가 들어오면 화료할 수 있는 상태다.

이때 론이나 쯔모로 화료하면 핑후라는 역을 달성할 수 있다. 핑후의 조건은 다음과 같다.

멘쯔(몸통) 4개가 전부 슌쯔.
또이츠(머리)는 수패 혹은 객풍패 (자풍, 장풍, 삼원패는 불가)
양면 대기 상태.

위와 같이, 앞뒤로 패를 기다리는 양면 대기 상태에서만 핑후가 성립한다. 역패를 머리로 사용할 경우 핑후는 성립하지 않는다. 따라서 핑후는 이름 그대로 “평범한 화료”라는 의미를 지닌다.

▶ 마작의 점수 계산

핑후는 멘젠 상태에서 추가 부수가 붙지 않는 손패 를 의미한다. 이때 ‘부수’란 손패의 구조에 따라 계산되는 점수 단위이다.

마작의 점수는 판(역의 개수) x 부(패의 구조 점수)로 계산된다.

기본적으로 20부에서 시작하고, 다음과 같은 경우에 부가 추가 계산된다.

같은 패 3개(커쯔)가 있을 때.

역패(자풍, 장풍, 삼원패)를 머리로 사용할 때

양면 대기가 아닌 대기 형태일 때.

쯔모(+2부) 또는 멘젠 론(+10부)으로 화료할 때.

쯔모 또는 멘젠 론으로 화료할 때 부수가 추가되므로, “핑후는 멘젠 쯔모일 때만 가능한가?”라고 생각할 수 있다.

하지만 이는 아니다. 핑후 쯔모는 특례로 쯔모 2부를 계산하지 않는다. 따라서 멘젠 쯔모 시에도 20부를 유지하며 핑후가 성립한다.

[핑후가 성립하지 않을 때]

4. 같은 슌쯔가 2개?! 이페코(一盃口)<멘젠>

멘젠 상태에서 같은 슌쯔가 두 개 있는 경우 이페코 역이 성립한다.

만약 이페코가 2개(예시 123만/123만, 456통/456통)있으면, 3판 역인 량페코(二盃口)가 성립한다.

5. 화료를 모두 머리로! 치또이츠(七対子)<멘젠, 2판>

위 처럼 14개의 패를 모두 또이츠(7개)로 모은 경우 성립한다. 당연하게도 치,퐁,깡을 하게 되면 멘쯔가 형성되어 패의 구조가 깨지므로, 멘젠 상태에서만 성립할 수 있는 역이다.

6. 몸통이 모두 커쯔! 또이또이(対々和)<2판>

몸통을 모두 커쯔(후로 가능)로 만들면 성립하는 역이다.

초보자들에게는 비추천되는 역인데, 퐁도 가능하고 외우기 쉬운 역이다 보니 무작정 또이또이로 가는 경우가 많다.

핑후와 정반대 역이기 때문에, 핑후에서 추가적으로 붙는 역(멘젠쯔모, 리치, 탕야오 등)을 노릴 수 없으며, 무엇보다 많이 울수록 방어하기도(내 패가 공개되므로) 어려워진다.

7. 마작의 스트레이트, 일기통관(一気通貫)<멘젠2판, 후로1판>

한 종류의 수패를 1~9까지 모아 123-456-789로 슌쯔 3개를 만들면 성립한다.

멘젠 시에는 2판 역으로, 후로 시에는 1판 역으로 취급한다.

8. 삼색동순(三色同順)<멘젠2판, 후로1판>

서로 다른 종류의 같은 슌쯔(2만3만4만/2삭3삭4삭/2통3통4통)를 모으면 성립한다. 일기통관과 동일하게 후로시 한 판 감소한다.

반대로 서로 다른 종류의 같은 커쯔(222만/222삭/222통)를 모으면 삼색동각(三色同刻)이 된다.

위에서는 자주 등장하며 실전에서 활용도가 높은 역들을 중심으로 정리하였다. 이제 나머지 역들을 간단히 살펴보자.

이름	조건
해저로월(海底撈月) <1판>	패산의 맨 마지막에 남아있는 패를 해저(海底)라 하며, 이것을 쯔모해서 화료하는 경우 성립한다.
하저로어(河底撈魚) <1판>	마지막에 버려지는 패(하저패)로 화료하는 경우 성립한다.
영상개화(嶺上開花) <1판>	깡을 한 뒤, 영상에서 가져온 패(영상패)로 화료하는 경우 성립한다.
창깡(搶槓, 창공) <1판>	상대가 이미 퐁 해둔 상태에서 같은 패를 하나 더 가져와 깡(가깡)을 선언했을 때, 그 패가 화료하기 위한 패라면 론을 통해 화료할 수 있다. 이 때, 창깡이라는 1판 역이 성립한다.
찬타(全帯幺九) <2판(후로1)>	모든 몸통과 머리에 반드시 1개 이상의 요구패(1,9,자패)를 포함하면 성립한다.
혼노두(混老頭)<2판>	모든 몸통과 머리를 요구패로 만들면 성립한다. 반드시 자패가 포함되어야 한다.
소삼원(小三元)<2판>	삼원패중 두 종류를 몸통, 한 종류를 머리로 만들면 성립한다.(구조상 손패에 소삼원 하나만 성립해도 4판 역이다.)
산안커(三暗刻)<2판>	안커 3개를 만들면 성립한다.
산깡쯔(三槓子)<2판>	안깡, 가깡, 대명깡 상관 없이 총 3번 깡을 하면 성립한다. 2판 역 치곤 매우 어려운 난이도.
혼일색(混一色) <3판(후로2)>	한 종류의 수패와 자패만으로 역을 만들면 성립한다. 조건이 간단해 초보자들도 자주 노릴 수 있다.
준찬타(純全帯幺九) <3판(후로2>	요구패가 한개 이상만 있으면 되는 찬타와 달리, 모든 몸통과 머리에 자패 없이 노두패가 들어가는 형태로 만들어야 한다.
청일색(清一色) <6판(후로5)>	한 종류의 “수패”로만 화료했을 때 성립한다.
유국만관 (流し満貫)	자신의 버림패가 모두 요구패인 상태에서 유국(아무도 화료하지 않고 게임이 끝남)하면 성립한다. ~~요구패만 나와서 불쌍하니 점수를 주겠다는 느낌.~~ - 누군가 한번이라도 내 버림패를 치,퐁,깡 하면 성립하지 않음.

■ 매우 큰 한 탕을 노리는 역, 역만

역만은 난이도가 매우 높지만, 완성하는 순간 판을 뒤집을 수 있는 강력한 조합이다. 그만큼 보기 드물지만, 기본적인 형태를 알고 있지 않으면 눈앞의 역만을 놓치는 아쉬운 상황이 생길 수 있다.

따라서 이번에는 비교적 자주 등장하는 대표적인 역만들을 간단히 살펴보자.

역만은 한 번에 최소 32,000점을 얻을 수 있는 역이다.

1. 국사무쌍(国士無双)<멘젠>

13종의 요구패(1통, 9통, 1삭, 9삭, 1만, 9만, 동, 남, 서, 북, 백, 발, 중)를 모두 갖추고 있는 상태에서 화료하면 성립한다.

머리를 만들어야 하기 때문에, 위의 13종 중 하나는 2개를 모아야 한다.

처음 패를 받았을 때, 서로 다른 요구패가 9종류 있으면 유국(판 리셋)을 선언할 수 있다. 하지만 유국을 선언하지 않고 국사무쌍을 노리는 경우도 있다.

조합만 보면 어려운 역으로 생각되지만, 스안커, 대삼원과 더불어 가장 쉬운 축에 속하는 역만이다.

▶ 국사무쌍 13면대기(国士無双十三面聽) <멘젠>

모든 요구패 13종을 중복 없이 모으면, 어느 요구패를 하나 더 가져와도 화료할 수 있는 상태가 되므로13면 대기 형태를 만들 수 있다.

국사무쌍 13면 대기의 경우 더블 역만 처리된다.

국사무쌍 같은 경우, 생각보다 쏘이기 쉽다. 요구패는 잘 쓰기 않기 때문에 버리는 경우가 많기 때문이다. 따라서 상대방이 요구패가 아닌 중장패(2~8)만 버린다면 국사무쌍을 의심해봐도 된다.

2. 스안커(四暗刻)<멘젠>

모든 멘쯔를 안커로 만들면 성립한다. 단, 마지막 멘쯔를 론으로 완성할 경우 해당 멘쯔는 안커로 인정되지 않으므로 스안커는 쯔모로 화료해야 성립한다.

단, 위와 같이 멘쯔를 모두 안커로 만든 상태에서 또이츠를 대기중이라면 론 할 수 있고, 이는 스안커 단기로 더블 역만 처리된다.

3. 대삼원(大三元)

모든 삼원패를 멘쯔로 만들거나, 마지막에 완성시켜 화료하는 경우 성립한다.

굳이 멘젠일 필요가 없으므로 가장 하기 쉬운 역이지만, 삼원패 2개가 퐁 되면 그때부터 남은 삼원패를 함부로 버리지 않기에 어찌 보면 가장 어려운 역이기도 하다.

■ 론을 할수 없다고? 후리텐(振聴)

내가 버린 패에 화료에 필요한 패가 하나라도 포함되어 있다면, 상대의 버림패로 론을 할 수 없다. 예를 들어, 3만을 버린 상태에서 텐파이에 진입했고 화료패가 3만, 6만이라면,

3만뿐만 아니라 6만으로도 론할 수 없다.

또한 리치를 건 상태에서 화료 가능한 패를 론하지 않으면, 그 판이 끝날 때까지 론할 수 없는 영구 후리텐 상태가 된다.

후리텐은 사람이 아닌 현재 대기 패를 기준으로 적용되는 규칙이다. 따라서 후리텐 상태에서는 쯔모로만 화료할 수 있으며, 패를 바꿔 대기 형태에서 이미 버린 패가 제외되면 후리텐은 해제된다.

단, 리치를 건 이후에는 대기를 변경할 수 없으며, 화료 가능한 패를 론하지 않은 경우 해당 판이 끝날 때까지 론할 수 없다.

■ 마작 용어 정리


수패	숫자가 적힌 패
자패	동·남·서·북의 풍패와 백·발·중의 삼원패
노두패	수패 중 1과 9
중장패	수패 중 2~8
멘츠	몸통
또이츠	머리
슌쯔	연속된 수패 3장
커쯔	같은 패 3장
텐파이	화료하기 까지 딱 1장의 패만 남은 상태
쯔모	텐파이 상태에서 패를 뽑아 화료
론	텐파이 상태에서 상대의 버림패로 화료
후로(울기)	상대방의 버림패를 가져오는 모든 행위
멘젠	후로하지 않은 상태
치	내 왼쪽의 플레이어로부터 버림패를 가져와 슌쯔를 만든다
퐁	위치의 관계 없이 버림패를 가져와 커쯔를 만든다
깡	같은 패 4장을 모아 만드는 멘쯔이다
대명깡	상대의 버림패로부터 깡
가깡	퐁 후에 내가 뽑은 패로 깡
암깡	손패 4장으로 깡

[C++, 자료구조] 트리(Tree)

브라더스톤 — Wed, 4 Mar 2026 17:48:06 +0900

■ 비선형 자료구조 - 트리(Tree)

우리가 여태까지 다룬 자료구조(배열, 리스트, 스택, 큐, 덱)는 각 데이터가 앞 뒤로 하나의 데이터와만 연결되는 구조를 가지는 “선형 자료구조”였다.

이번 장에서 설명할 트리(Tree)는 하나의 데이터가 여러 개의 하위 데이터를 가질 수 있는 구조로, 계층적인 관계(Hierarchical Relationshipe)를 표현하는 비선형 자료구조인 트리에 대해 살펴보자.

자료구조를 단순히 “저장하고 꺼내는 도구”로 이해하기 쉽지만, 자료구조의 본질은 어떤 대상을 구조적으로 표현하는 도구이다.

따라서, 트리의 추상 자료형(ADT)을 정의할 때도 “저장과 삭제가 편리한가?”보다 “계층 구조를 표현하기에 적절하게 정의되었는가?”의 관점에서 바라보는 것이 옳다.

1. 트리의 표현

트리도 우리 주변에서 쉽게 예시를 찾을 수 있는 자료구조이다. 폴더 구조나 집안의 족보 혹은 기업 및 정보의 조직도로 트리의 예시를 들 수 있다.

[트리의 예시 - 1]

나무처럼 보이진 않지만, 이 자료구조에 트리라는 이름이 붙은 이유는 “가지를 늘려가며 뻗어나간다”라는 공통점이 있기 때문이다.

[트리의 예시 - 2]

위와 같은 트리를 “의사 결정 트리(Decision tree)”라 한다. 의사 결정 트리는 다양한 데이터 분석 기법의 도구가 되며, 경영학 등 공학 이외의 영역에서도 유용하게 사용된다.

이처럼 트리를 이용해 무엇을 저장하고 꺼내야 한다는 생각을 지우고, 무엇을 표현하는 도구라고 생각하자.

2. 트리 용어

노드(Node)
- 트리의 구성 요소에 해당하는 A, B, C, D, E, F와 같은 요소.
간선(Edge)
- 노드와 노드를 연결하는 연결선
루트 노드(Root Node)
- 트리의 최상단에 존재하는 A와 같은 노드.
단말 노드(Leaf Node/Terminal Node)
- 아래로 또 다른 노드가 연결되어 있지 않은(자식이 없는) C, D, E, F와 같은 노드.
- 다른 표현으로 Terminal Node라고 불리지만, Leaf Node라는 표현이 더 많이 쓰인다.
내부 노드(Internal Node)
- 단말 노드를 제외한 모든 노드.

[트리 관계]

또한 위처럼 트리의 노드 간에는 부모(parent), 자식(child), 형제(sibling)의 관계가 성립된다.

[트리의 높이와 레벨]

트리에서는 루트 노드부터 각 층별로 숫자를 매겨 이를 트리의 “레벨”이라고 하고, 트리의 최고 레벨을 가리켜 “높이”라 한다.

■ 이진트리(Binary Tree)와 서브 트리(Sub Tree)

[서브 트리]

큰 트리는 작은 트리로 구성이 되고, 큰 트리에 속하는 작은 트리를 가리켜 “서브 트리(Sub Tree)” 라 한다.

서브 트리의 아래에는 더 작은 서브 트리가 존재한다.

[이진 트리]

위 그림에서 보이는 트리가 중점을 두어 살펴보고 구현할 “이진트리(Binary tree)”이다. 이진트리를 간단하게 설명하자면 자식 노드가 두 개씩 달린 트리를 의미한다. 자세한 조건은 다음과 같다.

루트 노드를 중심으로 두 개의 서브 트리로 나뉜다.
나뉜 두 서브 트리도 모두 이진트리이어야 한다.

[다양한 이진 트리의 종류]

노드가 위치할 수 있는 곳에 노드가 존재하지 않는다면, 공집합(empty set) 노드가 존재하는 것으로 간주할 수 있다. 물론 공집합 노드도 이진트리의 판단에 있어서 노드로 인정하기에, 위와 같은 형태의 트리도 이진 트리라 볼 수 있다.

이처럼 이진 트리의 폭은 생각보다 넓고, 이에 따라 이진트리도 특성에 따라 세분화된다.

1. 포화 이진(Full Binary) 트리와 완전 이진(Complete Binary) 트리

[포화 이진 트리]

위의 이진트리는 모든 레벨이 꽉 차있다. 노드를 더 추가하려면 레벨을 늘려야 하는데, 이렇게 레벨이 모두 꽉 찬 이진트리를 가리켜 “포화 이진트리”라 한다.

[완전 이진 트리]

포화 이진트리처럼 레벨이 꽉 찬 상태는 아니지만, 빈 틈 없이 채워진 트리를 가리켜 “완전 이진트리”라 한다. 여기서 말하는 “빈 틈 없이 채워진 트리”가 가지는 의미는,

노드가 위에서 아래로, 왼쪽에서 오른쪽의 순서대로 채워졌다!

를 의미한다.

참고로 이런 트리는 이진트리의 조건에는 부합하지만, 포화도 완전도 아닌 그냥 이진트리이다.

■ 이진트리의 구현

이진트리는 재귀적인 특성을 지니고 있어서 어느정도 재귀 함수에 익숙해야 구현하는데 큰 어려움이 없을 것이다.

1. 배열 기반? 리스트 기반?

이진 트리 역시 배열 기반으로도, 연결 리스트 기반으로도 구현이 가능하다. 트리를 표현하기엔 연결 리스트가 더 유연하기 때문에 대부분은 연결 리스트를 기반으로 구현할 것이다.

하지만 완전 이진트리의 경우, 트리가 완성된 이후부터는 그 트리를 대상으로 매우 빈번한 탐색이 일어나기에 탐색이 용이한 배열 기반으로 먼저 살펴보자.

[노드 번호가 부여된 이진 트리]

배열을 기반으로 이진트리를 구현하려면, 각 노드에 번호를 구현해야 한다. 이 번호가 의미하는 바는, 각 노드의 데이터가 저장되어야 할 배열의 인덱스 값을 의미한다.

[배열 기반 이진 트리]

길이가 8인 배열을 선언하여 노드 번호 1~5까지 노드에 저장된 데이터를 배열에 저장한 결과이다. 번호가 1인 루트 노드의 데이터 A는 인덱스가 1인 위치에 저장되었고, 번호가 3인 노드의 데이터 C는 3인 위치에 저장되었다.

인덱스 0은 사용하지 않는 편이 구현의 편의와 실수할 확률을 낮추기 때문에 사용하지 않는다.

[리스트 기반 이진 트리]

그림으로 봐도 리스트 기반의 구현 방식이 바로 이해될 수 있다. 사실 연결 리스트의 구성 형태가 트리와 일치하기 때문이다.

2. 헤더 파일 정의

#pragma once
using BData = int;

struct BNode
{
	BData data;
	BNode* left = nullptr;
	BNode* right = nullptr;
};

BData GetNodeData(BNode* node);
void SetNodeData(BNode* node, BData data);

BNode* GetLeftSubTree(BNode* node);
BNode* GetRightSubTree(BNode* node);

void MakeLeftSubTree(BNode* main, BNode* sub);
void MakeRightSubTree(BNode* main, BNode* sub);

[BinaryTree.h]

이진트리를 구현하기 위해서는 각 노드를 표현하는 구조체 하나만으로도 기본적인 트리 구조를 구성할 수 있다.

그렇다면, 이진 트리를 표현한 구조체는 정의하지 않아도 될까?

앞서 리스트 기반 큐를 구현할 때는 노드를 표현한 구조체와 큐를 표현한 구조체를 각각 정의하였다.

하지만 이진트리에서는 노드가 위치할 수 있는 곳에 노드가 존재하지 않아도, 공집합 노드가 존재하는 것으로 간주하고 공집합 노드도 이진트리를 판단하는 데 있어서 노드로 인정받는다.

따라서 자식 노드가 하나도 없는 노드도 그 자체로 이진트리이기 때문에 별도로 이진트리를 표현하기 위한 구조체는 구현하지 않아도 된다.

그럼 헤더파일에 선언된 함수의 기능을 정리해 보자.

BData GetNodeData(BNode node) / void SetNodeData(BNode node, BData data)
- 노드에 저장된 데이터를 반환하거나, 노드에 데이터를 저장한다.
BNode GetLeftSubTree(BNode node) / BNode* GetRightSubTree(BNode* node)
- 파라미터로 넘어온 노드의 왼쪽/오른쪽 서브 트리의 주소 값을 반환한다.
void MakeLeftSubTree(BNode main, BNode sub)
- 왼쪽 서브 트리를 연결한다.
void MakeRightSubTree(BNode main, BNode sub)
- 오른쪽 서브 트리를 연결한다.

3. 이진트리의 구현

이진 트리의 구현은 의외로 쉽다. 코드도 그렇게 길지 않으니 천천히 살펴보는 것만으로도 충분히 이해가 가능하다.

#include "BinaryTree.h"

BData GetNodeData(BNode* node)
{
	if(node != nullptr && node->data != 0)
		return node->data;

	return BData();
}

void SetNodeData(BNode* node, BData data)
{
	if (node != nullptr)
		node->data = data;
}

BNode* GetLeftSubTree(BNode* node)
{
	return (node != nullptr && node->left != nullptr) ? node->left : nullptr;
}

BNode* GetRightSubTree(BNode* node)
{
	return (node != nullptr && node->right != nullptr) ? node->right : nullptr;
}

void MakeLeftSubTree(BNode* main, BNode* sub)
{
	if (main == nullptr)
		return;

	if (main->left != nullptr)
		delete main->left;

	main->left = sub;
}

void MakeRightSubTree(BNode* main, BNode* sub)
{
	if (main == nullptr)
		return;

	if (main->right != nullptr)
		delete main->right;

	main->right = sub;
}

[BinaryTree.cpp]

코드를 잘 보면 문제가 생길 만한 부분이 존재한다. 아래 글을 보기 전에 먼저 어떤 함수에서 어떤 부분이 문제가 생길지 생각해 보자.

void MakeLeftSubTree(BNode* main, BNode* sub)
{
	if (main == nullptr)
		return;

	if (main->left != nullptr)
		delete main->left;

	main->left = sub;
}

[MakeLeftSubTree()]

문제는 MakeLeftSubTree() 함수와 MakeRightSubTree() 함수에서 발생한다.

한 번의 delete가 전부이기 때문에, 삭제할 서브 트리가 하나의 노드로 이뤄져 있다면 문제없지만, 그렇지 않다면 메모리 누수로 이어진다.

따라서 둘 이상의 서브 트리를 구성하는 모든 노드를 대상으로 delete를 해야 한다. 이렇게 모든 노드를 방문하는 것을 가리켜 “순회”라고 하는데, 데이터가 나란히 있는 다른 자료구조와 달리 트리는 별도의 방법이 필요하다.

순회를 살펴보기 전에 이진트리 사용 예제인 Main함수를 살펴보자.

#include <iostream>
#include "BinaryTree.h"
using namespace std;

int main()
{
	auto node1 = new BNode;
	auto node2 = new BNode;
	auto node3 = new BNode;
	auto node4 = new BNode;

	SetNodeData(node1, 1);
	SetNodeData(node2, 2);
	SetNodeData(node3, 3);
	SetNodeData(node4, 4);

	MakeLeftSubTree(node1, node2); // node1의 왼쪽 서브 트리는 node2
	MakeRightSubTree(node1, node3); // node1의 오른쪽 서브 트리는 node3
	MakeLeftSubTree(node2, node4); // node2의 왼쪽 서브 트리는 node4

	cout << "Node1의 왼쪽 자식 노드 데이터 : " 
		<< GetNodeData(GetLeftSubTree(node1)) << endl;

	cout << "Node1의 왼쪽 자식 노드의 왼쪽 자식 노드의 데이터 : "
		<< GetNodeData(GetLeftSubTree(GetLeftSubTree(node1))) << endl;

	return 0;
}

[트리 사용 예제]

위 Main 함수를 통해 형성되는 이진트리의 구조는 위와 같다. 1이 저장된 노드의 왼쪽 자식 노드와, 그 자식 노드의 왼쪽 자식 노드를 출력했을 때, 위 구조처럼 출력이 되는것을 확인할 수 있다.

■ 이진 트리의 순회(Traversal)

아까 트리를 구현함에 있어서 “재귀”를 이해해야 한다고 했는데, 이진트리를 순회할 때 재귀 방식이 사용된다.

~~무조건 재귀 방식을 사용하는 것은 아니고, 스택이나 큐를 사용해 반복문 방식으로도 구현한다.~~

트리를 순회하는 방식에는 크게 3가지 방식이 존재한다.

전위 순회(Preorder Traversal) : 루트를 먼저 방문. (루트 → 왼쪽 → 오른쪽)
중위 순회(Inorder Traversal) : 루트를 중간에 방문. (왼쪽 → 루트 → 오른쪽)
후위 순회(Postorder Traversal) : 루트 노드를 마지막에 방문. (왼쪽 → 오른쪽 → 루트)

1. 순회의 재귀적 표현

위 3가지의 방식 모두 재귀적으로 구현만 하면 문제는 해결된다. 재귀가 끼어있어서 감을 잡기 힘들 수도 있는데, 먼저 중위 순회를 진행하는 함수를 살펴보자.

[중위 순회]

서브 트리라고 해서 순회의 방법이 달라지는 것은 아니다. 간단하게 전체를 순회하는 함수는 아래와 같이 정의할 수 있다.

void InorderTraverse(BNode* node)
{
	if (node == nullptr)
		return;

	// 왼쪽 서브트리 부터 탐색
	InorderTraverse(node->left);
	
	cout << "Node Data : " << node->data << endl;
	
	// 오른쪽 서브트리 탐색
	InorderTraverse(node->right);
}

[InorderTraverse()]

일단은 트리의 전체 노드를 순회하며 저장된 데이터를 출력하는 함수를 작성하였다. 재귀의 탈출 조건은 자식이 더 이상 존재하지 않는 경우(node == nullptr인 경우)가 바로 탈출 조건이다.

Main에서도 해당 함수를 호출하면, 왼쪽 서브트리의 단말 노드부터 거슬러 올라가 루트를 거쳐 오른쪽 서브트리로 넘어가는 것을 확인할 수 있다.

void PreorderTraverse(BNode* node)
{
	if (node == nullptr)
		return;

	cout << "node : " << node->data << endl;
	PreorderTraverse(node->left);
	PreorderTraverse(node->right);
}

void PostorderTraverse(BNode* node)
{
	if (node == nullptr)
		return;

	PostorderTraverse(node->left);
	PostorderTraverse(node->right);
	cout << "node : " << node->data << endl;
}

[전위, 후위 순회 방식]

중위 순회 방식과 동일하게 전위와 후위 순회 방식도 구현할 수 있다. 차이는 루트 노드를 방문하는 문장이 삽입된 위치이다.

2. 노드의 방문 목적을 자유롭게 구성하기

노드를 순회하는 데 있어서 목적은 데이터 출력이 전부가 아니다. 따라서 함수 포인터를 사용해서 노드를 방문했을 때 할 일을 결정해 보자.

// **BinaryTree.h**
void InorderTraverse(BNode* node, void (*visit)(BNode*));

// **BinaryTree.cpp**
void InorderTraverse(BNode* node, void (*visit)(BNode*))
{
	if (node == nullptr)
		return;

	// 왼쪽 서브트리 부터 탐색
	InorderTraverse(node->left, visit);

	visit(node);

	// 오른쪽 서브트리 탐색
	InorderTraverse(node->right, visit);
}

[함수 포인터 추가]

함수의 주소 값을 매개변수 visit를 통해 전달받도록 변경하였다. 그리고 이 함수를 기반으로 노드의 방문은 다음과 같이 처리되도록 변경하였다.

visit(node) ← 노드의 방문

즉, 매개변수 visit에 전달되는 함수에 따라 노드의 방문결과가 결정되는 것이다.

#include <iostream>
#include "BinaryTree.h"
using namespace std;

void PrintNodeData(BNode* node);

int main()
{
	auto node1 = new BNode;
	auto node2 = new BNode;
	auto node3 = new BNode;
	auto node4 = new BNode;

	SetNodeData(node1, 1);
	SetNodeData(node2, 2);
	SetNodeData(node3, 3);
	SetNodeData(node4, 4);

	MakeLeftSubTree(node1, node2); // node1의 왼쪽 서브 트리는 node2
	MakeRightSubTree(node1, node3); // node1의 오른쪽 서브 트리는 node3
	MakeLeftSubTree(node2, node4); // node2의 왼쪽 서브 트리는 node4

	cout << "중위 순회 결과" << endl;
	InorderTraverse(node1, PrintNodeData);
	cout << endl;

	return 0;
}

void PrintNodeData(BNode* node)
{
	cout << "Data : " << GetNodeData(node) << endl;
}

[Main.cpp]

Main 함수에서도 위와 같이 코드를 수정해 주면, 함수 포인터를 통해 중위 순회에서 방문 목적을 지정해 줄 수 있다.

3. 순회를 통한 노드의 삭제

앞서 MakeLeftSubTree() 함수와 MakeRightSubTree() 함수의 문제에 대해 살펴봤으니, 구현한 순회 함수를 통해 문제를 해결해 보자.

서브 트리의 자식 노드들까지 순회를 통해 모두 제거.

[노드의 삭제]

상황을 다시 한번 살펴보면, 1번 노드의 왼쪽 자식인 2번 노드를 삭제해야 한다고 해보자. 그럼 2번 노드의 모든 자식 노드들을 순회하며 삭제해야 할 것이다.

[중위 순회의 문제점]

하지만 여기서 살펴봐야 할 점이 있는데, 중위 순회의 경우 왼쪽 → 루트 → 오른쪽의 순서로 순회한다.

왼쪽 노드를 방문하고 자식 노드가 더 이상 없으면 왼쪽 노드를 삭제한 뒤, 루트 노드가 삭제된다. 이렇게 되면 루트 노드가 삭제되어 루트 노드의 오른쪽 노드는 더 이상 접근할 수 없다.

void MakeLeftSubTree(BNode* main, BNode* sub)
{
	if (main == nullptr)
		return;

	if (main->left != nullptr)
	{
		PostorderTraverse(main->left, [](BNode* node) { delete node; });
		main->left = nullptr;
	}

	main->left = sub;
}

void MakeRightSubTree(BNode* main, BNode* sub)
{
	if (main == nullptr)
		return;

	if (main->right != nullptr)
	{
		PostorderTraverse(main->right, [](BNode* node) { delete node; });
		main->right = nullptr;
	}
	
	main->right = sub;
}

[하위 노드의 모든 노드 삭제]

위와 같은 문제를 방지하기 위해 후위 순회를 사용하여 자식 노드부터 차례대로 삭제한 뒤, 마지막에 부모 노드를 삭제하도록 구현하였다.

PostorderTraverse(main->left, [](BNode* node) { delete node; });

[](BNode* node) { delete node; }는 이름이 없는 익명 함수(람다)로, 방문한 노드를 즉시 delete 하도록 정의된 콜백 함수이다.

#include <iostream>
#include "BinaryTree.h"
using namespace std;

void PrintNodeData(BNode* node);

int main()
{
	auto node1 = new BNode;
	auto node2 = new BNode;
	auto node3 = new BNode;
	auto node4 = new BNode;

	SetNodeData(node1, 1);
	SetNodeData(node2, 2);
	SetNodeData(node3, 3);
	SetNodeData(node4, 4);

	MakeLeftSubTree(node1, node2); // node1의 왼쪽 서브 트리는 node2
	MakeRightSubTree(node1, node3); // node1의 오른쪽 서브 트리는 node3
	MakeLeftSubTree(node2, node4); // node2의 왼쪽 서브 트리는 node4

	cout << "중위 순회 결과" << endl;
	InorderTraverse(node1, PrintNodeData);
	cout << endl;

	// 노드 1의 왼쪽 자식 교체
	auto node5 = new BNode;
	SetNodeData(node5, 5);
	MakeLeftSubTree(node1, node5);

	cout << "중위 순회 결과" << endl;
	InorderTraverse(node1, PrintNodeData);
	cout << endl;

	return 0;
}

void PrintNodeData(BNode* node)
{
	cout << "Data : " << GetNodeData(node) << endl;
}

[실행 결과]

이렇게 트리의 구현과, 트리를 순회하는 재귀 호출 함수를 작성해 보았다. 다음에는 수식 트리를 사용해 계산기 프로그램을 만들어보자.

[게임수학] 10-2. 깊이 값

브라더스톤 — Sat, 28 Feb 2026 19:40:16 +0900

→ 이 글은 「이득우의 게임 수학」을 바탕으로 작성했습니다.

■ 깊이 값

3D 공간의 물체들을 화면이라는 2차원 평면에 투영하면, 화면 좌표에는 $x$와 $y$정보만 남게 된다. 이 상태에는 어떤 물체가 더 앞에 있고 뒤에 있는지를 구분할 수 없어 결국 나중에 그려진 물체가 화면의 앞에 보일 수밖에 없다.

따라서 물체가 카메라로부터 얼마나 떨어져 있는지 파악할 수 있는 데이터가 필요한데, 이를 깊이$^{Depth}$값 이라 한다.

[3차원으로 확장된 NDC 영역]

2차원 평면의 NDC에서 깊이 값을 추가하면 3차원 영역으로 확장된다. 깊이 값의 범위는 동일하게 $[-1,1]$이다.

[카메라에 설정한 절두체]

NDC영역과 마찬가지로 카메라에 부여한 시야각은 깊이값과 무관하기 때문에 근평면$^{Near plan}$과 원평면 $^{Fraplane}$이라는 추가 속성을 부여해야 한다.

사각뿔 영역을 근평면과 원평면으로 잘라주면 위 그림과 같은 형태가 나오게 되는데 이를 절두체$^{Frustum}$라 한다.

1. 원근 투영 행렬에 깊이값 추가

$$ P \cdot \vec{v}=\begin{bmatrix}\frac{d}{a} & 0 & 0 \\0 & d & 0 \\0 & 0 & -1\end{bmatrix}\begin{bmatrix}v_x \\v_y \\v_z\end{bmatrix}=\begin{bmatrix}\frac{d}{a}\, v_x \\d\, v_y \\- v_z\end{bmatrix} $$

[원근 투영 행렬]

앞서 구한 3X3 행렬에서 깊이 값을 계산하는데 필요한 값을 추가하기 위해 3행을 4행으로 옮기고, 3행은 깊이 값을 구하는 용도로 변경하자.

[깊이값을 계산하기 위한 미지수 추가 - 1]

깊이 값을 계산하는데 사용하는 3행은 4개의 미지수$i,j,k,l$로 지정했다.

하지만 깊이 값은 카메라 전방 향향($z$축)의 거리만을 의미한다. 따라서 동일한 $z$값을 가지는 점들은 $x, y$위치와 관계없이 같은 깊이를 가져야 한다.

$$ z′=ivx+jvy+kvz+l $$

만약 깊이값을 계산하는데 $v_x$와 $v_y$가 포함된다면 깊이값이 $x,y$에 따라 달라진다는 의미이다. 그러므로 깊이 계산식에서는 $v_x,v_y$가 포함될 수 없으며 원근 투영의 3번째 행에서 $i,j$는 0이 된다.

[깊이값을 계산하기 위한 미지수 추가 - 2]

여기서 두 미지수의 값을 얻기 위해 근평면과 원평면의 값을 사용하자.

카메라로부터 근평면까지의 거리 $= n$
카메라로부터 원평면까지의 거리 $= f$

카메라로부터 $n$만큼 시선 방향으로 이동한, 근평면 상에 위치한 점의 뷰 공간 좌표는 $(0,0,-n,1)$이 된다.

이는 깊이 값의 시작지점이기 때문에 NDC좌표 $(0,0,-1)$에 대응.
동일하게 뷰 공간의 원평면상의 좌표는 $(0,0,-f,1)$인데 이는 깊이 값의 끝 지점이기 때문에 NDC$(0,0,1)$에 대응된다.

원근 투영 행렬에 뷰 공간의 점을 곱한 결과는 클립 좌표가 된다. 근평면의 점을 $P_1$, 원평면의 점을 $P_2$라 한다면,

아직 $k,l$값을 모르기 때문에 클립 좌표의 세 번째 요소를 직접 계산할 수 없다.

$$ P_1\cdot P_{near} = (0,0,-kn + l , n) \\ \ \\ z_{ndc} = \frac{-kn + l}{n} $$

하지만 근평면은 NDC에서 $z = -1$에 대응되어야 하므로,

$$ \frac{-kn + l}{n} = -1 $$

이다.

NDC는 클립 좌표를 마지막 요소인 $w$로 나눈 값이므로, $w = n$ 일 때 NDC가 $-1$이 되기 위해서는 클립 좌표의 $z$값이

$$ z_c = -n $$

이어야 한다. 따라서, 근평면의 클립 좌표는 $(0,0,-n,n)$이 되고, 원평면의 클립 좌표도 동일한 방식으로 $(0,0,f,f)$가 되어야 한다.

[뷰 공간의 좌표와 NDC값의 비교]

따라서 위와 같은 식을 얻을 수 있다. 여기서 두 행렬의 3행과 뷰 공간의 점을 내적하면 다음 두 식을 얻을 수 있다.

$$ -kn + l = -n \\ -kf + l = f $$

$n,f$는 카메라에 설정된 상수이므로, 두 식을 서로 빼, $l$을 소거한 후 $k$값을 구하면 아래와 같다.

$$ k = \frac{-(n + f)}{(-n + f)} = \frac{n + f}{n - f} $$

여기서 구한 $k$를 대입해 $l$을 계산하면,

$$ l = \frac{2nf}{(n-f)} $$

따라서 깊이 값을 산출해주는 최종 원근 투영 행렬 $P$는 다음과 같다.

■ 원근 보정 매핑

원근 투영 행렬에서 깊이 값을 추가해 문제를 해결했지만, 아직 한 가지 문제가 남아있다.

[기존 텍스처 매핑의 문제점]

각 픽셀의 무게중심좌표를 구한 뒤, UV좌표를 계산하고 텍스처 매핑을 구현했지만, 평평하게 그려져야 할 눈과 눈썹이 처지거나 올라가 있다.

이는 원근 투영이 “선형 변환”이 아니어서 생기는 문제인데, 왜 이런 상황이 나오는지 자세히 살펴보자.

[시야각 사이에 걸쳐 있는 두 점의 투영 결과]

투영하기 전의 두 점$(P_1, P_2)$가 카메라 시야각에 걸쳐있다면, 투영한 점$(N_1, N_2)$의 $x$좌표값은 $-1, 1$이 된다.

카메라 정면에 위치한 $P_3$는 투영 후 투영 평면의 정 중앙에 위치한다.

투영 후 $N_1$과 $N_2$를 이어 선분을 생성하면, 선분의 중앙에 위치한 $N_3$의 무게중심좌표는 0.5가 된다.

하지만 투영 전, 선분$P_1P_2$ 내에 위치한 점 $P_3$의 무게중심좌표는 0.5에 위치하지 않는다.

[뷰 공간의 선을 수평으로 조정]

원근 투영은 다음과 같이 계산된다.

$$ x_{ndc} = \frac{x}{-z} $$

즉, 좌표를 나누는 연산이 포함되는데, 이 나눗셈 때문에 선형 관계가 유지되지 않는다. 깊이가 다르면 선형 관계가 깨진다는 의미이다.

3D 공간에서 선형 보간된 점은 $P = \alpha P_1 + \beta P_2$의 형태이지만, 투영 후에는 $N = \frac{P}{w}$가 되므로 결국,

$$ \frac{\alpha P_1 + \beta P_2}{w} \ne \alpha \frac{P_1}{w_1} + \beta\frac{P_2}{w_2} $$

가 된다. 즉, 투영 전 무게중심좌표와 투영 후 무게중심좌표가 서로 다르게 되므로 이 차이로 인해 텍스처 왜곡이 발생하는 것이다.

1. 투영 보정 보간

이를 수정하기 위해선 “투영 전 무게중심좌표”를 사용해야 하고, NDC의 무게중심으로부터 투영 전의 무게중심좌표를 계산하는 것을 투영 보정 보간(Perspective corrention interpolation)이라 한다.

NDC의 무게중심좌표를 투영 전의 무게중심좌표로 돌려주는 계산식을 유도하기 위해 반비례 함수 $y = -\frac{1}{x}$가 가진 성질을 보자.

[반비례 함수 그래프]

함수 $y = -\frac{1}{x}$에서 $x = 2,4,6$에 대응되는 값은 각각 아래와 같다.

$$ -\frac{1}{2}, -\frac{1}{4}, -\frac{1}{6} $$

$x$축에서 가운데 위치한 4는 2와 6의 정확한 중간에 있으므로 선형 보간의 기본 형태에 의해 다음과 같이 표현할 수 있다.

$$ 4 = a\cdot 2 + (1-a)\cdot 6 $$

이를 정리하면,

$$ 4 = 2a + 6 - 6a \\ 4 = 6 - 4a \\ a = \frac{1}{2} $$

즉, 4의 무게중심좌표는 0.5이다.

▼ 선형 보간식의 의미

예를 들어 2와 6가이의 어떤 값을 표현하고 싶다면, 그 값은 두 점의 일정 비율로 섞어서 나타낼 수 있다. 이는 일반적으로,

$$ x = ax_1 +(1-a)x_2 $$

의 형태로 두며, 여기서 $a$는 두 점 사이의 위치 비율을 의미한다.

보간을 할 때 가중치의 합은 항상 1이어야 하므로 $a + (1-a) = 1$이 되도록 정의한다. 이 식이 바로 선형 보간의 기본 형태이다.

이번엔 4에 대응하는 y값 $-\frac{1}{4}$의 무게중심좌표를 구해보자. 동일하게 선형 보간식을 사용하면,

$$ -\frac{1}{4} = a\cdot -\frac{1}{2} + (1-a) \cdot -\frac{1}{6} $$

가 되고, 위 식을 정리하면 $a = 0.25$가 된다.

여기서 살펴봐야 할 점은,

$x$축에서 2와 6의 중간인 4의 보간계수는 0.5 이다.
$y$값에서 $-\frac{1}{2}$와 $-\frac{1}{6}$ 사이에서 $-\frac{1}{4}$이 되도록 만드는 보간계수는 0.25이다.

$$ a_x = 0.5 \ \ \ne \ \ a_y = 0.25 $$

선형 함수라면 두 보간계수가 동일해야 하지만, 반비례 함수에서는 그렇지 않다.

만약 $y$축의 무게중심좌표 0.25로부터 $x$축의 무게중심좌표 0.5를 계산해 주는 식을 찾을 수 있다면, 이를 응용해 투영 전 무게중심좌표를 계산할 수 있을 것이다.

2. 투영 보정 보간식 유도

$y$축에서의 무게중심좌표를 $q_1, q_2$로 지정하고, 이를 사용해 $y$축의 두 점 $y_1, y_2$ 사이의 점 $y'$을 구하는 수식을 정리하자.

$$ y ' = q_1 \cdot y_1 + q_2 \cdot y_2 $$

$q_1 + q_2 = 1$

이번엔 반비례가 적용되기 전 $x$축의 수식을 정리해 보자. 무게중심좌표를 $t_1, t_2$로 지정하고, $x_1,x_2$사이의 점 $x'$을 구하는 수식은 아래와 같다.

$$ x' = t_1\cdot x_1 + t_2 \cdot x_2 $$

두 값은 서로 반비례 관계이므로, $y$값을 $x$값으로 표현하면 아래와 같은 식이 성립한다.

$$ \frac{1}{x'} = q_1\cdot \frac{1}{x_1} + q_2 \cdot \frac{1}{x_2} $$

그렇다면 주어진 두 점 $y_1,y_2$의 값과 둘의 무게중심좌표를 사용해 $x'$값을 계산할 수 있다.

$$ x' = \frac{1}{(q_1\cdot \frac{1}{x_1}+q_2\cdot\frac{1}{x_2})} $$

양변에 분모를 곱하면 다음의 식이 성립하고,

양변의 덧셈항을 분리하면 다음의 관계를 얻을 수 있다.

$$ t_1 = \frac{x'}{x_1}q_1, \ \ \ t_2 = \frac{x'}{x_2}q_2 $$

앞선 예의 $y$축에서 무게중심좌표는 각각 0.25와 0.75였다. 이를 통해 $x$축에서의 무게중심좌표 0.5가 잘 계산되는지 확인해 보자.

$$ q_1 = \frac{1}{4}, \ \ q_2 = \frac{3}{4} $$

$$ t_1 = \frac{x'}{x_1} q_1 = \frac{4}{2} \cdot \frac{1}{4} = 0.5 \\ t_2 = \frac{x'}{x_2} q_2 = \frac{4}{6} \cdot \frac{3}{4} = 0.5 $$

위처럼 $x$축에서의 무게중심좌표 0.5가 잘 계산됨을 확인할 수 있다.

두 점에 조합에 대한 무게중심좌표를 확장해 삼각형을 구정하는 세 점의 조합에도 동일하게 적용할 수 있다.

위 식을 사용하여 NDC에서 구한 무게중심좌표를 투영 전 무게중심좌표로 변환해 보자. NDC로 변환할 때 나누는 값은 뷰 공간의 $z$값이므로, 위 식에서 $x$를 $-z$로 치환하면 최종 투영 보정 보간식을 얻을 수 있다.

[최종 투영 보정 보간식]

■ 깊이 버퍼

같은 거리에 있는 두 게임 오브젝트가 서로 겹쳐있다면, 물체 단위로 그리는 순서를 조절하는 것으로는 문제를 해결할 수 없다.

근본적인 해결 방식은 오브젝트 단위가 아닌, 삼각형의 픽셀 단위로 깊이를 비교하여 가까운 곳의 픽셀만 그리는 것이다.

이를 구현하기 위해 화면의 픽셀마다 현재의 깊이 값을 보관해 주는 별도의 저장 공간이 필요한데, 이를 깊이 버퍼(Depth buffer)라고 한다.
깊이 버퍼에 저장된 값을 비교하여 현재 깊이 값이 작은 경우에만 픽셀을 찍도록 로직을 구성하면, 그리지 않아도 되는 픽셀을 파악해 그리기를 건너뛸 수 있는데, 이 작업을 깊이 테스팅이라 한다.

[게임수학] 10-1. 원근 투영

브라더스톤 — Sat, 28 Feb 2026 18:20:51 +0900

→ 이 글은 「이득우의 게임 수학」을 바탕으로 작성했습니다.

■ 원근 투영 변환 원리

[투시 원근법]

우리 눈은 멀리 있는 물체일수록 작게 보이는 구조를 가지고 있다. 이는 눈이 외부의 빛을 한 점(망막)으로 모아 받아들이기 때문이다.

르네상스 시대의 화가들은 이 원리를 그림에 적용해 입체감을 표현하는 기법을 만들었고, 이를 투시 원근법(Perspective projection drawing)이라 한다.

[카메라의 화각]

우리가 만드는 3D 공간은 결국 2D화면(모니터)에 표현되어야 한다.

따라서 3차원 공간의 모든 점들을 2차원 화면 위에 자연스럽게 투영하기 위해, 멀리 있는 것은 작게, 가까운 것은 크게 보이도록 하는 변환 과정이 필요하다.

이 변환을 바로 “원근 투영 변환(Perspective projection transformation)”이라 한다.

가상공간에서 우리 눈에 대응되는 물체는 카메라이고, 이 카메라가 보는 범위를 화각(Field of view)라 한다.
- 카메라에 화각을 설정하면 위와 같은 균등한 사각뿔 영역이 만들어진다.

[투영 평면과 초점 거리]

카메라에서부터 3차원 공간의 모든 물체의 상이 맺히는 “가상의 평면”을 투영 평면(Projection plane)이라 한다.

투영 평면은 “3D 점의 상이 어디에 맺힐 것인가”를 정의하는 개념적 기준이고, 실제 계산은 원근 투영 변환 행렬을 통해 수행된다.
카메라로부터 투영 평면까지의 거리를 초점 거리(Focal Length)라 하며, 이는 원근감과 화면에 보이는 물체 크기에 영향을 준다.

1. NDC(Normalized device coordinate) 영역

[오른쪽에서 바라본 투영 평면]

원근 투영을 구현하기 위해 투영 평면의 위치를 지정해야 하는데, 일반적으로 계산의 편의를 위해 위아래 크기가 각각 1이 되는 지점으로 결정한다.

따라서 좌우와 상하가 각각 $[-1,1]$의 범위를 가지는 정사각형 평면에 물체의 상이 맺힌다.

투영 평면에 대응하는 정사각형 영역의 2차원 좌표 시스템을 “NDC(Normalized device coordinate)”라 부른다.

[투영 평면의 NDC 영역]

투영 평면에 대응되는 NDC가 언제나 일정한 값을 가져야 한다면, 카메라의 화각이 변활 때, 초점 거리는 달라질 수밖에 없다.

화각이 커질수록 초점 거리는 짧아진다.
화각이 작아질수록 초점 거리는 멀어진다.

그렇다면 화각과 초점 거리의 관계는 아래처럼 직각삼각형의 $\tan$ 함수로 결정된다.

$$ \tan(\frac{\theta}{2}) = \frac{1}{d} $$

[화곽과 초점거리의 관계]

따라서 주어진 화각 $\theta$에 따른 초점 거리 $d$는 양변에 $d$를 곱하고, 다시 양변에 $\tan(\frac{\theta}{2})$로 나누면 아래와 같이 정리된다.

$$ d = \frac{1}{\tan(\frac{\theta}{2})} $$

2. 원근 투영 행렬

지금까지의 공간 변환은 $x,y,z$축이 서로 직교하고 크기가 동일한 형태였다. 이러한 공간을 유클리드 공간(Euclidean space)라 하고, 여태까지 다룬 로컬, 월드, 뷰 모두 유클리드 공간의 형태다.

정육면체 형태의 공간.

유클리드 공간의 점들은 원근 투영 변환을 통해 사각뿔 형태로 바뀌게 되며, 이를 사영 공간(동차좌표 공간)이라 한다. 그중 카메라 시야 영역은 절두체 형태로 정의된다.

사영 공간에서 $x,y$축은 여전히 직교하지만, $z$축은 깊이에 따라 $x,y$축에 영향을 준다. → 이는 초점 거리에 따라 투영 평면의 크기가 달라지기 때문.

이러한 사영 공간의 성질 때문에 기존의 표준기저벡터의 변화를 관찰하는 방법으로는 행렬을 설계할 수 없다.

[투영의 진행 과정]

따라서, $x$축을 배제(0으로 고정)한 $y, z$축으로 공간을 설정하고 투명 평면에 상이 맺히는 과정을 생각해 보자.

뷰 공간의 점 $P_{view}$가 투영 평면에 투영된 점을 $P_{ndc}$라 할 때, 투영 과정은 위와 같이 진행된다.

$x$축을 0으로 고정했으니, 각 공간의 점 $P$의 좌표는 다음과 같이 표현할 수 있다.

$$ P_{view} = (0, v_y, v_z) \\ P_{ndc} = (0, n_y) $$

[두 개의 닮은꼴 삼각형]

두 점의 관계를 파악하기 위해 닮은 꼴 삼각형 두 개를 그리면, 닮은꼴 성질로부터 아래의 비가 완성된다.

$$ n_y : d = v_y : -v_z $$

여기서 투영평면의 $y$값인 $n_y$는 아래와 같은 방식으로 얻을 수 있고,

$$ n_y = \frac{d \cdot v_y}{-v_z} $$

카메라의 좌우와 상하의 시야각은 동일하므로, NDC의 $y$값 또한 0으로 고정시키면 $x,z$축의 평면을 사용하는 방식으로 구할 수 있다.

$$ n_x = \frac{d \cdot v_x}{-v_z} $$

따라서 초점거리와 뷰 좌표로부터 $P_{ndc}$는 아래와 같이 계산된다.

$$ P_{ndc} = (n_x, n_y) = (\frac{d \cdot v_x}{-v_z},\frac{d \cdot v_y}{-v_z}) = -\frac{d}{v_z} (v_x, v_y) $$

■ 종횡비

NDC영역은 $[-1,1]$의 범위를 가진, 정사각형 모양의 정규화된 좌표계를 가지므로 실제 화면에 출력하기 위해서는 변환을 통해 화면 해상도에 맞게 변환해주어야 한다.

[종횡비를 고려하지 않아서 발생하는 문제]

하지만 모니터는 1:1 비율이 아닌 16:9, 4:3처럼 가로 세로 비율이 다르다.

이때, 가로와 세로를 균등하게 늘리면 물체가 찌그러지게 되는데, 이는 화면의 가로 세로 비, 즉(종횡비 - Aspect ratio)를 고려하지 않았기 때문이다.

따라서 종횡비를 미리 파악해 NDC에 원을 투영할 때 종횡비를 거꾸로 뒤집은 비율을 적용해 먼저 찌그러트려보자.

[종횡비를 고려해 처리]

종횡비는 보통 하나의 축 크기를 1로 지정하고, 다른 축의 크기를 상대적으로 측정해 나타낸다.

많이 사용하는 1920x1080 해상도의 세로축을 기준으로 측정한 종횡비는 $a = \frac{1920}{1080} = \frac{16}{9} \approx 1.777...$ 이 된다.

$$ P_{ndc} = -\frac{d}{v_z}(\frac{v_x}{a}, v_y) $$

[NDC 좌표 수정]

NDC의 투영 결과를 좌우로 찌그러트리려면 $x$축 값을 변경해야 하는데, 종횡비의 역수 $\frac{1}{a}$을 곱하면 된다.

따라서 NDC 좌표를 계산하는 공식은 위와 같이 변경된다.

마지막으로 뷰 공간의 점$P_{view}$의 $x,y$ 값으로 만든 벡터를 $\vec v = (v_x, v_y)$로 지정하면, $P_{ndc}$의 두 점의 좌표는 다음과 같이 계산할 수 있다.

$$ P_{ndc} = P \cdot \vec{v}= \begin{bmatrix}\frac{1}{a}\,\frac{d}{-v_z} & 0 \\0 & \frac{d}{-v_z}\end{bmatrix}\cdot\begin{bmatrix}v_x \\v_y\end{bmatrix} $$

[원근 투영 행렬]

하지만 이 행렬엔 문제가 있는데, 변환할 점의 $z$값이 행렬에 사용되다 보니 변환할 점마다 행렬을 새로 생성해야 한다.

미리 곱해둔 행렬을 사용하여 연산량을 줄이는 장점이 사라짐.

그렇다면 우리는 카메라 설정만으로 행렬을 만들어야 한다.

행렬의 구성 요소를 자세히 보면 $-v_z$를 모두 분모로 사용하는데, 이러면 행렬에서 이 값을 제거하고 결과에서 나눠줄 수 있을 것이다.

1. 원근 투영 행렬에서 값 제거

앞서 설계한 원근 투영 행렬에서 $-v_z$값을 제거하고 행렬의 곱하는 벡터의 값을 $\vec v = (v_x, v_y, v_z)$로 지정하자.

$\vec v$는 뷰 좌표계의 점과 동일한 값.

최종적으로 얻어야 할 NDC 좌표와는 다르지만, 위 행렬$P$는 카메라 설정 값으로만 구성된다. 이렇게 되면 모든 점에 대해 원근 투영 행렬 $P$를 사용할 수 있다.

$$ P_{clip} = (\frac{d \cdot v_x}{a}, d \cdot v_y, -v_z) $$

[클립 좌표]

이렇게 원근 투영 행렬 $P$로 변환되는 좌표계 클립을 클립 좌표(Clip coordinate)라 부른다.

2. 뷰 공간 좌표 적용

$$ P_{ndc} = (\frac{d \cdot v_x}{-v_z \cdot a}, \frac{d \cdot v_y}{-v_z}, 1) $$

마지막으로 클립 좌표의 점의 각 요소를 세 번째 값인 $-v_z$로 나누면 최종적인 NDC의 좌표를 얻을 수 있다.

■ 동차 좌표계

모든 점에서 원근 투영 행렬을 사용할 수 있도록 두 단계로 구분하고, 사용하는 벡터의 값도 한 차원 높였다.

이렇게 한 차원 높인 벡터를 사용하는 것을 게임 제작에서 보통 동차 좌표계(Homogenous coordinate system)를 사용한다고 표현한다.

좀 전에 “유클리드 공간의 점들은 원근 투영 변환을 통해 사각뿔 형태로 바뀌게 되며, 이를 사영 공간이라 한다.”라고 설명하였다.

정확히 말하자면, 사영 공간은 어떠한 모양이 있는 것이 아니라 원근을 선형변환으로 다루기 위한 수학적 구조이다. 그렇다면 사영 공간과 동차 좌표게는 어떤 관련이 있는지 살펴보자.

[사영 공간에서 점의 이동과 투영된 점의 변화]

사영 공간의 점은 카메라와 가까울수록 투영 평면의 원점과 멀어지고, 멀수록 투영 평면의 원점과 가까워지는 반비례 관계이다.

3차원 사영 공간의 점을 $(x', y', z')$으로 표기하고, 투영된 NDC 좌표를 $(x,y)$로 표기한다면, 사영 공간의 마지막 차원 값의 반비례로 영향을 받으므로 아래와 같은 관계가 성립한다.

$$ x = \frac{x'}{z'} \ \ \ \ y = \frac{y'}{z'} $$

[직선의 방정식]

여기서 직선의 방정식을 사영 공간의 좌표로 표현해 보자. 위 식을 사용하여 $x,y$를 치환하면,

$$ \frac{y'}{z'} = a\frac{x'}{z'}+b $$

위 식의 양변에 $z'$을 곱하면 상수가 사라지고, 세 미지수의 차수가 모두 1차식으로 동일한 수식이 구성된다.

$$ y' = ax' +bz' $$

이렇게 미지수에 대한 차수가 모두 동일한 방정식을 동차 방정식이라 부르며, 사영 공간에서 사용하는 좌표계도 동차 좌표계라 부를 수 있다.

정리하자면 원근 투영 행렬을 구하기 위한 첫 단계의 클립 좌표는, 투영되기 전 사영 공간의 좌표를 의미한다.

따라서 원근 투영에서 등장한 사영, 클립, 동차 공간은 모두 동일한 공간을 가리키고, 클립, 동차 좌표 역시 동일한 좌표계를 가리킨다.

사영 공간의 점이 카메라로부터 멀어질수록 투영 평면의 원점$(0,0)$에 가까워지는데, NDC의 원점은 회화의 투시 원근 기법에서 이야기하는 “소실점(Vanishing Point)” 에 해당된다.

■ 정리

다음 내용인 깊이값으로 넘어가기 전에 내용을 다시 한번 정리해 보겠다.

1. 월드 → 뷰 공간

월드 공간의 물체 좌표를 카메라를 원점으로 다시 계산한 공간.

카메라가 바라보는 방향이 기준축이 되고, View 행렬은 카메라 트랜스폼의 역행렬이다.

2. 투영 평면

뷰 공간에서 카메라 앞에는 투영 평면이 있고, 원근 투영으로 모든 물체의 상이 해당 평면에 맺힌다.

여기서 이 투영 평면을 $[-1,1]$로 정규화한 공간을 NDC라 한다.

투영 평면에 대응되는 NDC는 언제나 일정한 값을 가져야 하므로, 화각$(\frac{\theta}{2})$에 따라 초점 거리는 달라진다.

화각이 클수록 초점 거리$(d)$는 짧아지고, 화각이 작을수록 초점 거리는 멀어지는 $d = \frac{1}{\tan(\frac{\theta}{2})}$ 관계를 가지게 된다.

3. 투영 행렬

사영 공간에서 x, y축은 직교하지만 두 축은 z축의 영향을 받는다(초점 거리에 따라 투영 평면의 크기가 달라지기 때문). x축을 0으로 고정하고, view와 ndc 좌표는 다음과 같이 표현한다.

$$ P_{view} = (0, v_y, v_z) \\ P_{ndc} = (0, n_y) $$

두 점의 관계는 두 개의 닮은 꼴 삼각형 성질로부터 구할 수 있고, x값과 y값을 0으로 고정시키는 방법으로 $P_{ndc}$ 좌표를 구할 수 있다.

$$ P_{ndc} = (n_x, n_y) = (\frac{d \cdot v_x}{-v_z},\frac{d \cdot v_y}{-v_z}) = -\frac{d}{v_z} (v_x, v_y) $$

NDC 영역은 정사각형 영역이기 때문에, 화면 모니터 비율에 맞추어 늘리게 되면 물체가 찌그러지는 현상이 생긴다.

$$ P_{ndc} = P \cdot \vec{v}= \begin{bmatrix}\frac{1}{a}\,\frac{d}{-v_z} & 0 \\0 & \frac{d}{-v_z}\end{bmatrix}\cdot\begin{bmatrix}v_x \\v_y\end{bmatrix} $$

따라서 미리 좌우로 찌그러트리면 종횡비 문제를 해결할 수 있고, 종횡비의 역수인$\frac{1}{a}$를 $x$좌표에 곱하면 된다.

하지만 위 행렬은 변환할 점의 $z$값이 사용되다 보니, 이를 배제해야 한다. 앞서 설계한 원근 투영에서 $-v_z$값을 제거하고 곱하는 벡터의 값을 $\vec v = (v_x, v_y, v_z)$로 지정하면,

행렬 $P$는 카메라 설정 값으로만 구성할 수 있다.

$$ P_{clip} = (\frac{d \cdot v_x}{a}, d \cdot v_y, -v_z) $$

[클립 좌표]

$$ P_{ndc} = (\frac{d \cdot v_x}{-v_z \cdot a}, \frac{d \cdot v_y}{-v_z}, 1) $$

마지막으로 클립 좌표의 점의 각 요소를 세 번째 값인 $-v_z$로 나누면 최종적인 NDC의 좌표를 얻을 수 있다.

[C++, 자료구조] 덱(Deque)

브라더스톤 — Mon, 22 Dec 2025 16:53:02 +0900

■ 덱(Deque)

스택은 같은 한쪽(Top)에서 데이터를 넣고 빼는 구조였고, 큐는 뒤에서 데이터를 넣고 앞에서 데이터를 꺼내는 자료구조였다.

[Deque]

덱은 앞으로도 뒤로도 넣을 수 있고, 앞으로도 뒤로도 뺄 수 있는, 스택과 큐의 특성을 모두 갖추고 있는 자료구조이다.

Deque는 ‘디큐’로 읽기 쉬운데, 이러면 큐의 Dequeue연산과 발음이 같아져 “덱”으로 발음한다
- Double-Ended Queue의 줄임말이다.

▶ 덱의 추상 자료형

덱의 특성을 살펴봤으니, 이번엔 덱의 추상 자료형에 대해 살펴보자.

정의	설명
void InitDeque(Deque* dq)	덱의 초기화를 진행한다. 덱 생성 후 가장 먼저 호출한다.
bool IsEmpty(Deque* dq)	덱이 빈 경우 ture, 그렇지 않은 경우는 false를 반환한다.
void PushFront(Deque* dq, Data data)	덱의 머리에 데이터를 저장한다.
void PushBack(Deque* dq, Data data)	덱의 꼬리에 데이터를 저장한다.
Data PopFront(Deque* dq)	덱의 머리에 위치한 데이터를 반환 및 소멸한다.
Data PopBack(Deque* dq)	덱의 꼬리에 위치한 데이터를 반환 및 소멸한다.
Data GetFirst(Deque* dq)	덱의 머리에 위치한 데이터를 소멸하지 않고 반환한다.
Data GetLast(Deque* dq)	덱의 꼬리에 위치한 데이터를 소멸하지 않고 반환한다.

덱도 마찬가지로 배열, 혹은 리스트를 기반으로 작성할 수 있지만 데이터의 삽입 특징에 따라 가장 어울리는 “양방향 연결 리스트”를 사용하여 구현할 것이다.

■ 덱의 구현

1. Deque.h

#pragma once
typedef int Data;

struct DequeNode
{
	DequeNode* prev = nullptr;
	DequeNode* next = nullptr;
	Data data;
}; typedef DequeNode Node;

struct Deque
{
	Node* head = nullptr;
	Node* tail = nullptr;
};

void InitDeque(Deque* dq);

void push_front(Deque* dq, Data value);
void push_back(Deque* dq, Data value);
Data pop_front(Deque* dq);
Data pop_back(Deque* dq);

Data get_front(Deque* dq);
Data get_back(Deque* dq);

bool IsEmpty(Deque* dq);

앞서 정리한 추상 자료형을 기반으로 헤더 파일을 작성하였다.

[꼬리가 있는 양방향 연결 리스트]

머리를 가리키는 Head 포인터를 덱의 앞으로, 꼬리를 가리키는 Tail 포인터를 덱의 끝으로 설정하여 데이터를 추가하거나 반환한다.

기존 양방향 리스트와 크게 차이는 없지만, 추상 자료형이 다르기 때문에 코드까지 완전히 동일하진 않다.

2. Deque.cpp

1. InitDeque() / IsEmpty()

void InitDeque(Deque* dq)
{
	if(dq->head != nullptr)
	{
		while (IsEmpty(dq) == false)
		{
			pop_front(dq);
		}
	}

	dq->head = nullptr;
	dq->tail = nullptr;
}

bool IsEmpty(Deque* dq)
{
	return dq->head == nullptr;   // 헤드 노드가 nullptr이라면, 덱은 비어있다.
}

덱을 초기화하고 나서 가장 먼저 호출하는 함수이다.

이전과 동일하게 덱에 데이터가 있는 상태에서 head와 tail을 nullptr로 만들어버리면, 기존 데이터에는 접근이 불가능하니 pop_front() 함수를 사용하여 할당된 메모리를 해제한다.

2. push_front()

void push_front(Deque* dq, Data value)
{
	auto newNode = new Node;

	newNode->data = value;
	newNode->next = dq->head;

	if(IsEmpty(dq))
	{
		dq->tail = newNode;
	}
	else
	{
		dq->head->prev = newNode;
	}

	dq->head = newNode;
}

노드를 생성하고, 인자로 전달된 데이터를 초기화한다. 새롭게 생성된 노드의 next 포인터는 기존 head가 가리키는 노드를 가리키도록 만든다.

[데이터가 추가되는 경우]

처음으로 데이터가 추가되는 경우라면(dq→head == null), tail도 newNode를 가리켜야 한다.
기존 데이터가 존재하는 경우라면, head가 가리키는 노드의 prev 포인터를 newNode를 가리키게 한 뒤, head노드를 옮긴다.

3. push_back()

void push_back(Deque* dq, Data value)
{
	auto newNode = new Node;

	newNode->data = value;
	newNode->prev = dq->tail;

	if(IsEmpty(dq))
	{
		dq->head = newNode;
	}
	else
	{
		dq->tail->next = newNode;
	}

	dq->tail = newNode;
}

push_front()와 동일한 원리로 노드를 추가한다. 데이터가 끝(tail)에 추가된다는 점만 조심해 주면 된다.

4. pop_front()

Data pop_front(Deque* dq)
{
	if(IsEmpty(dq))
	{
		cout << "Deque is empty!" << endl;
		return -1;
	}

	auto delNode = dq->head;
	auto retData = delNode->data;

	dq->head = delNode->next;
	delete delNode;

	if(dq->head == nullptr)
	{
		dq->tail = nullptr;
	}
	else
	{
		dq->head->prev = nullptr;
	}

	return retData; 
}

head가 가리키는 노드의 포인터 정보와 데이터 정보를 저장하고, Head의 위치를 삭제될 노드의 다음 위치로 옮긴다.

[데이터를 반환하는 경우]

데이터를 추가할 때와 마찬가지로, 반환하고 소멸시킬 때도 확인해야 할 경우가 있다.

dq->head == nullptr : 더이상 남아있는 데이터가 없으므로, tail 역시 nullptr로 변경한다.
dq->head != nullptr : 옮겨진 head가 가리키는 prev가 소멸되었으니, nullptr로 변경한다.

5. pop_back()

Data pop_back(Deque* dq)
{
	if(IsEmpty(dq))
	{
		cout << "Deque is empty!" << endl;
		return -1;
	}

	auto delNode = dq->tail;
	auto retData = delNode->data;

	dq->tail = delNode->prev;
	delete delNode;

	if(dq->tail == nullptr)
	{
		dq->head = nullptr;
	}
	else
	{
		dq->tail->next = nullptr;
	}

	return retData;
}

pop_back() 함수 역시 pop_front()와 같은 구조이므로 따로 설명은 하지 않고 넘어가겠다.

▼ 전체 코드

#include "Deque.h"
#include <iostream>
using namespace std;

void InitDeque(Deque* dq)
{
	if(dq->head != nullptr)
	{
		while (IsEmpty(dq) == false)
		{
			pop_front(dq);
		}
	}

	dq->head = nullptr;
	dq->tail = nullptr;
}

void push_front(Deque* dq, Data value)
{
	auto newNode = new Node;

	newNode->data = value;
	newNode->next = dq->head;

	if(IsEmpty(dq))
	{
		dq->tail = newNode;
	}
	else
	{
		dq->head->prev = newNode;
	}

	dq->head = newNode;
}

void push_back(Deque* dq, Data value)
{
	auto newNode = new Node;

	newNode->data = value;
	newNode->prev = dq->tail;

	if(IsEmpty(dq))
	{
		dq->head = newNode;
	}
	else
	{
		dq->tail->next = newNode;
	}

	dq->tail = newNode;
}

Data pop_front(Deque* dq)
{
	if(IsEmpty(dq))
	{
		cout << "Deque is empty!" << endl;
		return -1;
	}

	auto delNode = dq->head;
	auto retData = delNode->data;

	dq->head = delNode->next;
	delete delNode;

	if(dq->head == nullptr)
	{
		dq->tail = nullptr;
	}
	else
	{
		dq->head->prev = nullptr;
	}

	return retData; 
}

Data pop_back(Deque* dq)
{
	if(IsEmpty(dq))
	{
		cout << "Deque is empty!" << endl;
		return -1;
	}

	auto delNode = dq->tail;
	auto retData = delNode->data;

	dq->tail = delNode->prev;
	delete delNode;

	if(dq->tail == nullptr)
	{
		dq->head = nullptr;
	}
	else
	{
		dq->tail->next = nullptr;
	}

	return retData;
}

Data get_front(Deque* dq)
{
	if(IsEmpty(dq))
	{
		cout << "Deque is empty!" << endl;
		return -1;
	}

	return dq->head->data;
}

Data get_back(Deque* dq)
{
	if (IsEmpty(dq))
	{
		cout << "Deque is empty!" << endl;
		return -1;
	}

	return dq->tail->data;
}

bool IsEmpty(Deque* dq)
{
	return dq->head == nullptr;
}

#include<iostream>
#include "Deque.h"
using namespace std;

int main()
{
	Deque dq;
	InitDeque(&dq);

	for(int i = 0; i <= 50; i++)
	{
		if(i % 2 == 0)
		{
			push_front(&dq, i);
		}
		else
		{
			push_back(&dq, i);
		}
	}

	PrintAllDataFromFront(&dq);

	for(int i = 0; i <= 25; i++)
	{
		cout << "Pop Front: " << pop_front(&dq) << endl;
		cout << "Pop Back: " << pop_back(&dq) << endl << endl;
	}

	return 0;
}

[Main.cpp]

0~50까지의 수 중 짝수는 덱의 앞에, 홀수는 뒤의 덱에 추가한 뒤 앞 뒤에서 하나씩 pop 하면 성공적으로 덱을 구현한 것을 확인할 수 있다.

[C++, 자료구조] 큐(Queue)

브라더스톤 — Mon, 22 Dec 2025 16:44:07 +0900

■ 큐(Queue)

[큐의 예시]

앞서 스택(Stack)은 먼저 들어온 것이 나중에 나가는 “선입후출(FILO)” 구조를 지녔다. 그리고 이걸 “쌓여있는 접시”, “프링글스 통 안의 감자칩”에 비유했었다,

반대로 큐(Queue)는 “줄을 서 있는 사람들”처럼 먼저 들어온 것이 먼저 나가는 “선입선출(FIFO)”의 구조를 지닌다.

큐의 개념은 일상생활에서도 쉽게 찾을 수 있다. 고무호스, 터널, 극장표 예매처 등은 모두 큐의 동작 방식과 유사한 구조이다.

▶ 큐의 추상 자료형

스택과 마찬가지로 큐의 추상 자료형도 정형화된 편이다.

enqueue : 큐에 데이터를 넣는 연산.
dequeue : 큐에서 데이터를 빼는 연산.

정의	의미
void InitQueue(Queue* pq)	큐의 초기화를 진행한다.
bool IsEmpty(Queue* pq)	큐가 빈 경우 true, 비어있지 않은 경우 false를 반환한다.
void Enqueue(Queue* pq, Data data)	큐에 데이터를 저장한다.
Data Dequeue(Queue* pq)	저장순서가 가장 앞선 데이터를 삭제하고 반환한다.
Data Peek(Queue* pq)	저장순서가 가장 앞선 데이터를 반환하되 삭제하지 않는다.

스택에서 데이터를 넣고 빼는 연산을 가리켜 각각 push, pop이라 하는 것처럼, 큐에서 데이터를 넣고 빼는 연산을 각각 enqueue, dequeue라고 한다.

■ 큐의 설계

1. 배열 기반 구현

스택과 큐의 가장 큰 차이는 데이터를 꺼내는 위치, 즉 앞에서 꺼내느냐 뒤에서 꺼내느냐의 차이이다.

그래서 얼핏 보면, 앞서 만든 스택 자료구조에서 단순히 꺼내는 위치만 바꾸면 큐를 만들 수 있을 것처럼 보일 수 있지만, 실제로는 그렇지 않다.

[Enqueue 과정]

F(Fornt)가 가리키는 것이 큐의 머리이고, R(Rear)이 가리키는 것이 큐의 꼬리이다.

Enqueue를 하게 되면 R이 다음 칸을 가리키고 그 칸에 데이터가 저장된다.

Dequeue : f가 가리키는 데이터 반환 후, 데이터를 빈자리로 이동

[잘못된 Dequeue 방식]

Dequeue 연산을 할 때, 반환할 데이터를 항상 배열의 맨 앞(Index : 0)에 위치시켜 보자. 이 방식의 경우 아래와 같은 문제점이 생긴다.

항상 배열의 첫 번째 데이터만 Dequeue되므로, 굳이 F(fornt 인덱스)가 필요 없다.
Dequeue가 일어날 때마다, 남아 있는 모든 데이터를 한 칸씩 앞으로 옮겨야 한다.

Dequeue : f가 가리키는 데이터 반환 후, f를 이동

[일반적인 Dequeue 방식]

이번엔 Dequeue 연산 시 F를 이동시키고 있다. 이 방식을 취하게 되면 Dequeue 연산에서 데이터의 이동이 필요하지 않다.

[R의 위치가 배열의 끝인 경우]

문자 E가 배열의 끝에 저장되어 더 이상 R을 옮길 수 없는 상황이다. 이 상황에서 어떻게 enqueue 연산을 진행할 수 있을까?

바로 R을 다시 배열의 맨 앞으로 이동시키면 된다!! (F 역시 마찬가지.)

이렇게 배열의 끝에 도달하면 다시 처음으로 돌아가 회전하는 방식의 구조를 “원형 큐(circular queue)라 한다.”

2. 원형 기반 큐

[3번의 Enqueue 연산]

원형 큐도 앞서 보인 큐와 같이 첫 번째 데이터가 추가되는 순간 F, R이 동시에 그 데이터를 가리킨다. 이후 Dequeue연산을 두 번 진행하면 아래와 같다.

[2번의 Dequeue 연산]

이제 구현만 하면 될 것 같지만, 현재 원형 큐에서 생각해 볼 문제가 아직 남아있다.

[큐의 상태]

원형 큐에서 데이터가 모두 차 있는 경우와 비어 있는 경우는 모두 F가 R보다 한 칸 앞선 위치를 가리키는 형태를 갖는다.

따라서 F와 R의 위치 정보만으로 큐가 비어 있는 상태인지, 가득 찬 상태인지 구분할 수 없다.

이러한 문제를 해결하기 위해 배열의 크기가 N일 때, 최대 N - 1개의 데이터만 저장하도록 제한한다.

즉, 배열에 N-1개의 데이터가 채워졌을 경우를 “꽉 찬 상태”로 간주하고, 항상 하나의 빈 공간을 유지한다.

[개선된 원형 큐의 꽉 찬 상황]

enqueue 연산 시 R이 가리키는 위치를 한 칸 이동시킨 다음에 데이터를 저장한다.
Dequeue 연산 시 F가 가리키는 위치를 한 칸 이동시킨 다음에 데이터를 반환한다.

따라서 R과 F가 같은 위치를 가리킨다면 큐가 “비어있는 상태” R이 가리키는 앞 위치가 F라면 큐가 “꽉 찬 상태”로 해석할 수 있다.

■ 원형 큐의 구현(배열 기반)

1. CircularQueue.h

#pragma once
constexpr int QUE_LENGTH = 100;
typedef int Data;

struct CircularQueue
{
	Data data[QUE_LENGTH];
	int front;
	int rear;
}; typedef CircularQueue CQueue;

void InitQueue(CQueue* pq);

void Enqueue(CQueue* pq, Data item);
Data Dequeue(CQueue* pq);
Data Peek(CQueue* pq);

bool IsEmpty(const CQueue* pq);

[CircularQueue.h]

앞서 정의한 큐의 추상 자료형을 기반으로 위의 헤더파일을 정의하였다.

2. CircularQueue.cpp

헤더파일에 선언된 함수의 구현을 보일 차례인데, 그에 앞서 아래의 함수를 살펴보자. 함수는 간단하지만 원형 큐의 핵심이라 할 수 있다.

int NextIndex(int index)
{
	return (index + 1 >= QUE_LENGTH - 1)
		? 0 : index + 1;
}

이는 큐의 다음 위치에 해당하는 배열의 인덱스 값을 반환하는 함수이다.

pos 를 전달하면 pos + 1의 값을 반환하지만, 큐의 길이보다 하나 작은 값이 인자로 전달된다면 0을 반환한다.

이는 F와 R이 배열의 끝에 도달했으므로 앞으로 이동해야 함을 의미한다.

#include "CircularQueue.h"
#include <iostream>
using namespace std;

int NextIndex(int index);

void InitQueue(CQueue* pq)
{
	pq->front = pq->rear = 0;
}

void Enqueue(CQueue* pq, Data item)
{
	auto nextIndex = NextIndex(pq->rear);

	// Queue가 가득 찼는지 확인
	if(nextIndex == pq->front)
	{
		cout << "Queue is Full!" << endl;
		return;
	}

	pq->rear = nextIndex;
	pq->data[pq->rear] = item;
}

Data Dequeue(CQueue* pq)
{
	if(IsEmpty(pq))
	{
		cout << "Queue is Empty!" << endl;
		return -1;
	}

	pq->front = NextIndex(pq->front);
	return pq->data[pq->front];
}

Data Peek(CQueue* pq)
{
	if(IsEmpty(pq))
	{
		cout << "Queue is Empty!" << endl;
		return -1;
	}

	return pq->data[NextIndex(pq->front)];
}

int NextIndex(int index)
{
	return (index + 1 >= QUE_LENGTH - 1)
		? 0 : index + 1;
}

bool IsEmpty(const CQueue* pq)
{
	return pq->front == pq->rear;
}

[CircularQueue.cpp]

Queue에 2~100의 숫자 중 짝수만 Enqueue() 하고, 그 뒤에 Queue가 빌 때까지 Dequeue()하였다. 스택과 다르게 먼저 들어간 숫자가 먼저 나오는 “선입선출(FIFO)”구조로 만들어진 것을 확인할 수 있다.

■ 연결 리스트 기반 큐의 구현

배열을 기반으로 구현된 Stack을 Queue로 변경하려고 하면, 앞에서 살펴본 것처럼 고려해야 할 문제가 한두가지가 아니다.

하지만 ”연결 리스트 기반의 큐”는 배열 기반 구조에 비해 이러한 제약이 적기 때문에, 구조적으로는 스택 구현 방식을 어느 정도 재활용할 수 있지만, 아래와 같은 본질적인 동작 방식의 차이는 존재한다.

스택은 Push와 Pop이 같은 위치에서 이루어지지만, 큐는 Queue와 Dequeue가 다른 위치에서 발생한다.

1. ListQueue.h

#pragma once
typedef int Data;

struct ListQueueNode
{
	Data data;
	ListQueueNode* next = nullptr;
}; typedef ListQueueNode Node;

struct ListQueue
{
	Node* front = nullptr;
	Node* rear = nullptr;
}; typedef ListQueue LQueue;

void InitQueue(LQueue* pq);

void Enqueue(LQueue* pq, Data item);
Data Dequeue(LQueue* pq);
Data Peek(LQueue* pq);

bool IsEmpty(const LQueue* pq);

위의 헤더파일에서 보이듯이 연결 리스트 기반 큐에서도 원형 큐와 마찬가지로 front와 rear을 유지해야 한다.

enqueue연산과 dequeue 연산이 이뤄지는 위치가 다르기 때문.

2. ListQueue.cpp

void InitQueue(LQueue* pq)
{
	if(pq->front != nullptr && pq->rear != nullptr)
	{
		// 기존 노드가 존재한다면 해제
		while(IsEmpty(pq) == false)
		{
			Dequeue(pq);
		}
	}

	pq->front = nullptr;
	pq->rear = nullptr;
}

처음 큐를 생성하면 front와 rear이 가리킬 대상이 없으니, 초기에는 nullptr로 설정한다.

단, 데이터가 남아있는 상태에서 nullptr로 초기화 하면 기존 생성된 데이터에 접근할 수 없으니, Dequeue()를 호출하여 메모리 공간을 해제한다.

void Enqueue(LQueue* pq, Data item)
{
	auto node = new Node();
	node->data = item;
	node->next = nullptr;

	if(IsEmpty(pq) == true)
	{
		pq->front = node;
		pq->rear = node;
	}
	else
	{
		pq->rear->next = node;
		pq->rear = node;
	}
}

[Enqueue()]

큐에 아무런 데이터가 저장되지 않은 상태에서 데이터를 추가하면, F와 R모두 첫 번째 데이터를 가리켜야 한다.

이후에 추가되는 데이터는 R만 움직이면 되므로 가장 끝에 있는 노드(R이 가리키는 노드)가 새 노드를 가리키게 한 다음, R이 새 노드를 가리키게 만든다.

Data Dequeue(LQueue* pq)
{
	if(IsEmpty(pq))
	{
		cout << "Queue is Empty!" << endl;
		return -1;
	}

	auto delNode = pq->front;
	auto retData = delNode->data;
	pq->front = delNode->next;

	delete delNode;
	return retData;
}

[Dequeue()]

Dequene 과정에서는 신경 써야 할 부분이 F 하나이므로, Enqueue처럼 다른 포인터(R)를 건드릴 필요는 없다.

F가 다음 노드를 가리키게 한다.
F가 이전에 가리키던 노드를 소멸시킨다.

#include "ListQueue.h"
#include <iostream>
using namespace std;

void InitQueue(LQueue* pq)
{
	if(pq->front != nullptr && pq->rear != nullptr)
	{
		// 기존 노드가 존재한다면 해제
		while(IsEmpty(pq) == false)
		{
			Dequeue(pq);
		}
	}

	pq->front = nullptr;
	pq->rear = nullptr;
}

void Enqueue(LQueue* pq, Data item)
{
	auto node = new Node();
	node->data = item;
	node->next = nullptr;

	if(IsEmpty(pq) == true)
	{
		pq->front = node;
		pq->rear = node;
	}
	else
	{
		pq->rear->next = node;
		pq->rear = node;
	}
}

Data Dequeue(LQueue* pq)
{
	if(IsEmpty(pq))
	{
		cout << "Queue is Empty!" << endl;
		return -1;
	}

	auto delNode = pq->front;
	auto retData = delNode->data;
	pq->front = delNode->next;

	delete delNode;
	return retData;
}

Data Peek(LQueue* pq)
{
	if(IsEmpty(pq))
	{
		cout << "Queue is Empty!" << endl;
		return -1;
	}

	return pq->front->data;
}

bool IsEmpty(const LQueue* pq)
{
	return pq->front == nullptr;
}

[ListQueue.cpp 전체 코드]

[Unity, C#] SOLID 원칙

브라더스톤 — Fri, 21 Nov 2025 00:22:47 +0900

■ SOLID 원칙

[Gamg of Four]

프로그래밍에서 널리 사용되는 디자인 패턴(Design Patterns)은 Gang of Four(GOF) 라 불리는 4명의 저자가 정리한 책에서 시작되었다.

디자인 패턴을 공부해본 사람이라면 알겠지만, 대부분의 책은 SOLID 원칙부터 소개하고, 대부분의 디자인 패턴 역시 이 SOLID 원칙을 준수하도록 설계되어 있다.

▶ SOLID 원칙

Single responsibility : 단일 책임 원칙
Open-closed : 개방-폐쇄 원칙
Liskov substitution : 리스코프 치환 원칙
Interface segregation : 인터페이스 분리 원칙
Dependency inversion : 의존 역전 원칙

위 5가지 원칙의 앞 글자를 따서 “SOLID” 원칙이라 부른다.

물론 실제 프로그래밍에서 이 모든 원칙을 완벽하게 지키며 설계하는 것은 쉽지 않다.

하지만 가능한 한 SOLID 원칙을 기반으로 구조를 설계하면 코드의 유지보수성이 높아지고, 읽기 좋은 깔끔한 구조를 만들 수 있다.

1. Single responsibility principle : 단일 책임 원칙

[Unity Component]

모든 클래스는 오직 하나의 책임만 가진다. (대표적인 예 : Unity의 Component 구조)
클래스는 그 책임을 완전히 캡슐화한다.

Unity의 컴포넌트를 보면 Audio Source는 오디오 출력을 담당하고, Mesh Renderer는 메쉬를 그리는 역할만 담당한다.

이처럼 하나의 클래스가 “하나의 역할(책임)”만 수행하도록 하는 것이 바로 “단일 책임 원칙”이다.

또한 클래스는 자신이 맡은 책임을 완전히 캡슐화해야 하는데, 이는 다음을 의미한다.

책임을 수행하는 데 필요한 데이터(변수)를 외부에 노출하지 않는다. (private 선언)
책임과 관련된 동작(메서드)을 클래스 내부에서 직접 수행한다.
외부에는 필요한 기능만 공개하고, 내부 구현 방식을 감춘다.

단일 책임 원칙의 장점

하나의 클래스가 하나의 책임만 수행하므로, 클래스의 길이가 짧아지고 읽기 쉬워진다.
클래스가 작고 역할이 명확하므로 상속이나 확장이 쉬워지고, 재사용성이 높아진다.

public class Player : MonoBehaviour
{
    [SerializeField] private string 이동입력;
    [SerializeField] private float 이동관련변수_1;
    private float _이동관련변수_2;
    private AudioSource _오디오변수;

    private void Start()
    {
        _오디오변수 = GetComponent<AudioSource>();
    }

    private void Update()
    {
		    // 입력 로직...
        // 이동 관련 로직...
    }

    private void OnTriggerEnter(Collider other)
    {
        _오디오변수.Play();
    }
}

[단일 책임 원칙을 지키지 않은 코드]

위 코드를 보면 Player 클래스가 이동, 입력, 오디오 재생을 모두 한 번에 담당하고 있다.

즉, 하나의 클래스 안에서 “서로 다른 여러 책임”이 섞여있으므로, 단일 책임 원칙을 지키지 않은 예시라 볼 수 있다.

public class Player : MonoBehaviour
{
    [SerializeField] private PlayerAudio playerAudio;
    [SerializeField] private PlayerInput playerInput;
    [SerializeField] private PlayerMovement playerMovement;

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

public class PlayerAudio : MonoBehaviour
{
    //...
}

public class PlayerInput : MonoBehaviour
{
    //...
}

public class PlayerMovement : MonoBehaviour
{
    //...
}

[단일 책임 원칙을 지킨 코드]

각 역할을 담당(이동, 입력, 오디오)하는 클래스를 만들고, Player 클래스가 이들을 의존(사용)하도록 만들었다. 이렇게 책임을 독립된 클래스로 나누면 구조가 명확해지고, 각 클래스는 자신만의 역할을 수행한다.

또한 PlayerAudio 같은 클래스는 NPC나 다른 오브젝트에도 재사용할 수 있어서 확장성이 크게 높아진다.

2. Open-closed principle : 개방-폐쇄 원칙

“확장에 대해 열려 있어야 하고”

요구 사항이 변경될 때, 새로운 기능을 추가하여 모듈을 확장할 수 있어야 한다.
즉, 기존 기능을 바꾸지 않고 동작을 덧붙여 확장할 수 있어야 한다.

“수정에 대해서는 닫혀 있어야 한다.”

코드를 수정하지 않아도 모듈의 기능을 확장하거나 변경 가능해야 한다.

말이 좀 모호할 수 있는데, 간단히 설명하자면 “상속”을 통해 기능을 확장하고, 기존에 잘 굴러가는 코드는 수정하지 말라는 얘기이다.

public class Rectangle
{
    public float width;
    public float height;
}

public class Circle
{
    public float radius;
}

public class AreaCalculator
{
    public float GetRectangleArea(Rectangle rect)
    {
        //...
    }
    
    public float GetCircleArea(Rectangle rect)
    {
        //...
    }
}

[나쁜 예시]

AreaCalculator에서 각 도형의 부피를 계산하지만, 위와 같이 코드를 작성하면 도형을 추가할 때마다 원본 코드(AreaCalculator)를 수정해야 한다.

또한, 도형이 늘어날수록 AreaCalculator의 함수도 계속 추가해야 한다.

public abstract class Shape
{
    public abstract float CalculateArea();
}

public class Rectangle : Shape
{
    public float width;
    public float height;
    
    public override float CalculateArea()
    {
        //...
    }
}

public class Circ : Shape
{
    public float radius;
    
    public override float CalculateArea()
    {
        //...
    }
}

public class AreaCalculator
{
    public float GetArea(Shape shape)
    {
        return shape.CalculateArea();
    }
}

[좋은 예시]

CalculateArea()라는 추상 메서드를 가진 Shape 클래스를 만들고, 각 도형 클래스가 이를 상속받아 자신만의 방식으로 면적을 계산하도록 구현했다.

이렇게 구현하면 새로운 도형이 추가되더라도, AreaCalculator 클래스는 전혀 수정할 필요가 없다.

새로운 도형이 기존 코드를 건드리지 않고 자연스럽게 확장되기 때문에, 이러한 구조가 개방-폐쇄 원칙을 잘 지킨 사례이다.

3. Liskov substitution principle : 리스코프 치환 원칙

[바바라 리스코프(Barbara Liskov)]

파생 클래스는 기본 클래스를 대체할 수 있어야 한다.

리스코프(Liskov)에 별다른 뜻이 있는 것은 아니고, 이 원칙을 개발한 사람의 이름을 따서 만들어졌다.

이 원칙 역시 조금 애매한 표현인데, 쉽게 얘기하면 상속받은 클래스(하위 클래스)는 부모 클래스의 방향성을 지켜줘야 한다.

[Vehicle 클래스를 상속받는 두 클래스]

Vehicle 클래스는 속도와 방향을 나타내는 변수와 전, 후, 좌, 우로 움직이는 기능을 갖추고 있다. 이 클래스를 상속받아 Car와 Truck 클래스를 만들었고, 두 클래스 모두 동일한 방식으로 이동할 수 있다.

자동차와 트럭 모두 같은 방식으로 움직이며, 다른 탈것을 만든다고 해도 Vehicle 클래스를 상속받으면 기본적인 이동 기능을 그대로 사용할 수 있기에, 아직까지 문제가 있는 코드는 아니다.

[새로운 탈것(Train)의 추가]

여기에 레일을 따라 움직이는 새로운 탈것인 Train 클래스를 추가해 보자.

자연스럽게 Vehicle 클래스를 상속받았지만, 문제는 부모 클래스에 있는 TurnLeft(), TurnRight() 메서드가 Train에서는 전혀 사용되지 않는다.

이처럼 부모 클래스의 기능이 자식 클래스에서 무효화되거나 사용하지 않는 구조는 부모 클래스로서의 방향성을 지키지 못한다는 의미이다.

이러한 설계는 리스코프 치환 원칙에 위배된다.

[인터페이스로 책임 분리]

따라서 탈것의 기능을 “회전이 가능한가?”, “앞뒤로 이동이 가능한가?”처럼 역할 단위로 분리하고, 그 역할에 맞는 인터페이스를 정의한 뒤, 탈것이 필요한 기능만 조립하도록 만드는 방식이 더 올바르다.

이렇게 하면 불필요한 메서드가 자식 클래스에 강제로 들어오는 일을 막을 수 있어, 리스코프 치환 원칙을 위반하지 않은 구조로 설계할 수 있다.

역할에 따라 인터페이스를 분리하고 필요한 기능만 구현.
상속(Inheritance) 보다 구성(Composition)을 우선적으로 사용한다.

4. Interface segregation principle : 인터페이스 분리 원칙

클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다.

앞서 말한 단일 책임 원칙과 리스코프 치환 법칙에서 연장되는 원칙인데, 필요한 인터페이스만 만들고, 큰 인터페이스를 구체적이고 작은 단위로 분리하라는 얘기이다.

시스템의 내부 의존성을 약화하고 유연성을 강화한다.

public interface IUnitState
{
    public float HP { get; set; }
    public float MP { get; set; }
    public int Defense { get; set; }

    public void Die();
    public void TakeDamage(int damage);
    public void RestoreHealth();

    public void GoForward();
    public void Reverse();
    public void TurnLeft();
    public void TurnRight();
    
    // ....
}

[IUnitState]

게임에서 유닛이 가지는 상태와 행동은 매우 다양하다. 하지만 이 모든 기능을 하나의 인터페이스에 몰아넣어버리면, 유닛마다 필요하지 않는 기능까지 억지로 구현해야 한다.

이런 구조는 앞서 설명한 원칙들, 특히 “단일 책임 원칙”, “리스코프 치환 원칙”, “인터페이스 분리 원칙”을 위배할 가능성이 매우 높다.

[인터페이스 분리 원칙]

이처럼 인터페이스를 역할 단위로 최대한 작게 분리하여 구성하면, 유닛은 필요한 기능만 선택적으로 구현할 수 있게 된다.

따라서 불필요한 기능을 억지로 구현할 필요가 없고,
기능과 확장 조합이 훨씬 쉬워지며,
앞선 원칙들도 자연스럽게 지킬 수 있다.

5. Dependency Inversion Principle : 의존 역전 원칙

의존 역전 원칙은 간단하게 말하면 소프트웨어 모듈들을 분리하는 특정 형식을 말한다.

상위(High - level) 모듈은 하위(Low-level) 모듈의 것을 직접 가져오면 안 된다.
- 상위, 하위 모듈 둘 다 추상화(abstraction)에 의존해야 한다.
추상화는 세부 사항에 의존해서는 안 된다.
- 세부 사항이 추상화에 의존해야 한다.
클래스가 다른 클래스와 관계가 있으면 안된다.
- 클래스가 다른 클래스의 작동 방식을 많이 알고 있으면, 종속성(Dependency) 또는 결합(Coupling)이 발생한다.

[의존 역전 원칙]

코드를 작성하다 보면 자연스럽게 상위 레벨(Player)이 하위 레벨(KeyboardInput)에 의존하게 되고, 이것이 일반적인 “정방향 의존”이다.

하지만 의존 역전 원칙은 말 그대로, 이 관계를 뒤집어 상위 레벨과 하위 레벨 모두 추상화(IInput)에 의존하도록 만든다.

[낮은 결합도와 높은 결합도]

또한, 두 클래스의 결합도가 높을수록 A 클래스의 내용을 수정했을 때, B 클래스의 내용도 함께 수정해야 한다.

지금은 예시로 두 클래스만 놓고 봤지만, 실제 개발에선 여러 클래스가 서로 얽혀 있는 경우가 많기 때문에 한 클래스를 수정하면 관련 클래스까지 줄줄이 수정해야 하는 문제가 생기기 쉽다.

이렇게 되면 전체 구조의 유지보수가 매우 어려워진다.

public class Switch : Monobehaviour
{
	public Door door;
	public bool isActivated;
	
	public void Toggle()
	{
		if(isActivated)
		{
			isActivated = false;
			door.Close();
			
			return;
		}
		
		isActivated = ture;
		door.Open();
}

[예시 - 1]

현재 구조에서는 Switch가 Door 클래스를 직접 참조하고 있으며, 스위치를 작동할 때 Door의 메서드를 그대로 호출하고 있다.

Door만 있는 상황은 괜찮지만, 기능을 확장시켜 스위치를 켜면 폭탄이 폭발하는 기능을 추가하거나, 전등을 키는 기능을 추가해야 한다고 생각해 보자.

이 경우, Switch 클래스 안에 폭탄용 ToggleBomb(), 전등용 ToggleLight()와 같이 새로운 메서드를 계속 추가해야 하는 상황이 생긴다.

즉, 기능을 확장할 때마다 Switch 코드를 수정해야 하므로 유지보수가 점점 어려워진다.

public interface ISwitchable
{
	public bool IsActive {get;}
	public void Activate();
	public void Deavtivate()
}

// higher - level
public class Switch : MonoBehaviour
{
	public ISwitchable client;
	
	public Toggle()
	{
		//...
	}
}

// lower - level
public class Door : MonoBehaviour, ISwitchable
{
	private bool isActive;
	public bool IsActive => isActive;
	
	public void Activate() { // ... }
	public void Deactivate() { // ... }
}

[의존성 역전 원칙]

스위치가 가능한 오브젝트에서의 역할을 인터페이스로 따로 빼두고, 상위-하위 레벨 모두 이 인터페이스를 의존하게 만든다.

이렇게 만들면 어떠한 ISwitchable 객체가 추가되더라도, Switch의 Toggle() 메서드는 수정할 필요가 없어지게 된다.

SOLID 원칙의 핵심

결국 SOLID 원칙의 목적은 코드를 더 읽기 쉽고, 유지보수하기 쉬운 구조로 만드는 것이다.

한 가지 원칙을 지키기 시작하면, 다른 원칙들도 자연스럽게 지켜지는 경우가 많다. 따라서 코드를 작성할 때 항상 SOLID 원칙을 염두하면 변경에 강하고, 이해하기 쉬우며, 확장성이 높은 깔끔한 구조를 만들 수 있다.

하나의 클래스와 인터페이스는 오직 하나의 역할만 수행하도록 설계한다.
구현해야 하는 기능은 잘게 분리하여 인터페이스 단위로 모듈화 한다.
상속과 구성을 상황에 맞게 적절히 활용한다.

■ abstract class VS Interface

[abstract class]

추상 클래스를 구체 클래스(concrete class)가 상속받아 직접 내용을 구현하게 된다. 이렇게 직접적으로 상속을 받으면 “is” 관계가 된다.

추상 “클래스” 이기 때문에 필드, 스태틱 멤버, 전체 혹은 일부 구현된 메서드들을 가질 수 있다.
C#은 다중 상속이 불가능하고 오로지 한 개의 “클래스”만 상속받을 수 있다.

[interface]

따라서 C#에서 다중 상속을 구현하려면 Interface를 활용해야 한다. 인터페이스를 구현하게 되면 클래스와 인터페이스는 “can - do” 관계가 된다.

is - a 관계(추상 클래스 상속) : 자식 클래스는 부모 클래스의 “종류”이다.
can - do 관계(인터페이스 구현) : 클래스가 특정 능력이나 기능을 “할 수 있다”는 의미.

Abstract class	Interface
메서드를 완전히 또는 일부 구현.	메서드를 선언만 가능. 구현 불가능.
변수 및 필드 선언 / 사용.	메서드와 프로퍼티 선언만 가능.
스태틱 멤버 가능.	스태틱 멤버 불가.
생성자 사용 가능.	생성자 사용 불가능.
모든 액세스 한정자 가능.	모든 멤버는 public으로 취급.

최종 정리

→ Single responsibility (단일 책임 원칙)

클래스가 한 가지 작업만 수행한다.

→ Open-Closed (개방 폐쇄 원칙)

이미 작동하는 방식을 변경하지 않고도 클래스의 기능을 확장할 수 있어야 한다.

→ Liskov substitution (리스코프 치환 원칙)

하위 클래스는 기본 클래스를 대체할 수 있어야 한다. 기본 클래스의 방향성을 유지해야 한다.

→ Interface segregation (인터페이스 분리 원칙)

인터페이스를 작게 유지. 클라이언트는 필요한 것만 구현.

→ Dependency inversion (의존 역전 원칙)

추상화에 의존. 하나의 구체 클래스에서 다른 클래스로 직접 의존 금지.

[Unity] UI Toolkit 기본 사용법

브라더스톤 — Fri, 21 Nov 2025 00:00:23 +0900

■ UI Toolkit

[UI Toolkit]

UI Toolkit은 Unity 2022.2 이후 유니티의 기존 UGUI(Canvas 기반 UI)를 대체할 수 있도록 개발된 새로운 공식 UI 시스템이다.

기존 UGUI는 GameObject 기반으로 동작하는 UI 시스템으로 드래그 앤 드롭을 통한 직관적인 UI 제작이 가능하다. 또한 하이어라키 구조와 Canvas의 SortOrder를 이용해 UI의 렌더링 순서를 제어할 수 있다.

UGUI는 편리하고 직관적인 반면에 아래와 같은 뚜렷한 단점도 존재한다.

구분	단점
GameObject 기반	UGUI의 모든 UI요소는 GameObject + Component 로 구성된다. → 따라서 많은 UI요소가 있으면 UpdateLoop, Transform 갱신 등 CPU 오버헤드와메모리 사용량이 커진다.
Canvas 전체 리빌드	Canvas내 어느 한 UI요소라도 변경되면, Unity는 Canvas 전체를 다시 빌드(Rebuild) 해야 한다.
실시간 갱신 비효율	위와 같은 이유로 인하여, 실시간으로 수치나 상태가 바뀌는 UI(경험치, 체력바 등)는 Canvas 리빌드와 Layout 계산이 지속적으로 발생한다

[Web 개발 방식을 적용]

UI Toolkit은 기존 UGUI의 성능 및 유지보수 문제를 해결하기 위해, 웹 개발에 사용되는 스크립트(HTML, CSS, Java)를 Unity 환경에 도입하여 UI를 구성할 수 있도록 했다.

.UXML(HTML) : 기존 웹 개발의 프런트 레이아웃과 비슷한 구조를 가지고 있다. 유니티에서 UI의 레이아웃을 담당한다.
.USS(CSS) : UI의 스타일을 결정.
.cs : 인터페이스의 컨트롤 및 이벤트는 C# 스크립트에서 정의.

웹 개발과 상당히 흡사한 방식을 사용하기 때문에, 웹 개발 경험이 있다면 쉽게 인터페이스를 제작할 수 있고, 게임 내 UI뿐만 아니라 에디터 윈도우도 직접 제작할 수 있다.

■ UI Toolkit 사용하기

인게임 UI는 아직 UGUI를 사용하는 경우가 많으므로, UI Toolkit을 사용하여 커스텀 에디터를 만들어보자.

[Editor Window 생성]

Project → Create → UI Toolkit → Editor Window를 클릭하고 이름을 입력하면 자동으로 3개의 파일(.cs, .uss, .uxml)파일이 만들어진다.

▶ UI Builder

[UI Builder]

만들어진 .uxml 파일을 클릭하면 위와 같이 UI를 만들 수 있는 UI Builder 창이 열리게 된다. UI Builder의 레이아웃과 역할은 다음과 같다.

Style sheet : 현재 문서에 연결된 USS 스타일시트 목록을 표시한다.
Hierarchy : UXML의 Visual Tree(계층구조)를 표시한다. 드래그 앤 드롭으로 부모/자식 관계를 조정하고 이름 등을 설정할 수 있다.
Library : 배치 가능한 UI요소(VisualElement, Lable, Button 등)와 공통 템플릿 제공.
Viewport : 편집 중인 UI를 실시간으로 확인한다.
Preview : 현재 상태의 UXML, USS 코드 미리 보기(읽기 전용)를 제공한다.
Inspector : 선택한 UI요소의 속성을 편집한다. UGUI 컴포넌트가 아닌 웹에서 사용되는 프로퍼티를 Unity에서 사용 가능하도록 재구성.

■ VisualElement

VisualElement는 UI Toolkit에서 가장 기본이 되는 구성 요소이다. 모든 UI 요소들은 이 클래스를 상속받아 만들어진다.

[VisualElement 생성]

두 개의 VisualElement를 생성하고 이름을 각각 Main, Sub로 지정해 준 뒤, 인스펙터의 BackGround 탭에서 색상을 조절하면 위와 같이 배경색이 적용된다.

VisualElement는 하위 UI 요소를 배치할 영역(Container)을 정의하는 데 사용한다.

[하위 오브젝트 배치]

VisualElement 안에 요소를 배치하면, 그 영역에 맞게 UI 요소들이 배치되는 것을 확인할 수 있다.

위 사진의 빨간색 박스 안의 4개의 버튼은 현재 선택한 VisualElement의 레이아웃 정렬 및 크기 설정 방식을 변경한다.

좌측의 버튼부터 아래와 같은 기능을 한다.

[Flex Direction / Align Items ]

[Justify Content / Align self]

현재 Viewport에서 설정된 테마는 기본적으로 Cinemachine Runtime Theme가 적용되어 있다.

하지만 지금은 런타임 UI가 아닌 커스텀 에디터 창이므로, 이 테마를 Editor용 테마로 변경해 주어야 한다.

Cinemachine Runtime Theme를 사용하면 Viewport에서 보는 모습과 실제 커스텀 에디터는 다르게 보임.

[라이브러리 설정]

UI Builder 좌측 하단 Library 패널의 오른쪽 상단 점(⋯) 메뉴를 클릭하고 Editor Extension Authoring

옵션을 활성화하면, Viewport의 Theme 드롭다운에서 Dark 혹은 Light테마를 선택할 수 있게 된다.

■ 코드 작성

UXML로 UI의 레이아웃을 지정해주었으니, C# 코드를 통해 UI에 기능을 부여해야 한다.

public class TestWindow : EditorWindow
{
    [SerializeField] private VisualTreeAsset visualTreeAsset = default;

    [MenuItem("Window/UI Toolkit/TestWindow")]
    public static void ShowWindow()
    {
        var wnd = GetWindow<TestWindow>();
        wnd.titleContent = new GUIContent("TestWindow");
    }

    public void CreateGUI()
    {
        
    }
}

[TestWindow.cs]

기본적으로 생성된 파일에는 위와 같이 작성되어 있다. 만약 처음부터 작성하는 경우라면, 아래와 같은 변수와 함수를 선언해주어야 한다.

1. VisualTreeAsset visualTreeAsset : .uxml 파일을 참조하고, 다루기 위한 변수. UXML이 UI구조를 저장한 설계도라면, VisualTreeAsset은 그 설계도를 메모리에서 다루는 리소스 객체이다.

[.uxml 연결]

→ 해당 변수를 선언하고 난 뒤, .uxml 파일을 링크해주어야 한다.

2. [MenuItem("경로")] : 상단 메뉴에 “경로”로 입력한 곳에 커스텀 에디터를 띄울 수 있는 버튼을 추가한다.

3. public static void “이름:”() : 버튼이 클릭되면, 해당 함수를 호출하고 EditorWindow를 생성 및 호출한다.

▶ CreateGUI()

EditorWindow 클래스에서 UI Toolkit을 사용할 때 자동으로 호출되는 함수이다. 이 함수에서 UI 요소에 기능을 추가하거나 새로운 UI요소를 생성할 수 있다.

public void CreateGUI()
{
	var root = rootVisualElement;
	visualTreeAsset.CloneTree(root);
}

rootVisualElement는 현재 창의 최상위 컨테이너이다. 이 안에 모든 UI 요소(버튼, 라벨 등)가 들어간다.

CloneTree()는 인스펙터에서 참조한 UXML 파일(visualTreeAsset)을 기반으로 실제 UI 인스턴스를 생성하여 최상위 컨테이너 안에 배치한다.

public void CreateGUI()
{
	var root = rootVisualElement;
	visualTreeAsset.CloneTree(root);
	
	var label = root.Q<Label>("TextInfo");
	var button = root.Q<Button>("TestButton");

	button.clicked += () =>
	{
		Debug.Log(label.text);
	};
}

UI요소를 가져올 땐 Q<T>(”이름”) 혹은 Query<T>(”이름”)을 사용한다.

Q<T>(”이름”) : 첫 번째로 일치하는 요소 1개를 가져온다.
Query<T>(”이름”) : 트리 내 모든 일치하는 요소를 검색하며, 결과를 리스트로 사용하려면 .ToList()를 함께 사용한다.

위 코드는 UXML에 정의된 Lable과 Button 요소를 가져온 뒤, 버튼을 클릭하면 해당 라벨의 텍스트를 콘솔에 출력한다.