Unity 6+ Generative Art / Procedural Art / Shader Art 가이드

이 문서는 Unity 6.0 이상, URP 기준, C# + HLSL/ShaderLab 코드 중심으로 Generative Art, Procedural Art, Shader Art를 구현하기 위한 사전 지침서입니다. (AI로 작성)

---

목차

• 1. 이 문서의 목적
• 2. Unity Generative Art를 보는 가장 중요한 관점
• 3. 전체 구조는 반드시 데이터 생성 → 상태 변화 → 시각화로 나눈다
• 4. 데이터 생성 단계에서 반드시 알아야 할 C# 문법
  • 4.1 Awake와 Start의 역할 분리
  • 4.2 struct vs class
  • 4.3 List와 Array 선택 기준
  • 4.4 SerializeField와 인스펙터 설계
  • 4.5 Random과 재현 가능한 시드
  • 4.6 ScriptableObject로 설정 분리
• 5. 상태 변화 단계에서 반드시 알아야 할 문법
  • 5.1 Update, FixedUpdate, LateUpdate
  • 5.2 deltaTime과 time
  • 5.3 Mathf와 수학 기반 모션
  • 5.4 Vector 연산
  • 5.5 실시간 시스템의 기본은 for 루프
  • 5.6 Coroutine
  • 5.7 LINQ 사용 기준
  • 5.8 delegate, Action, Func
• 6. 시각화 단계에서 알아야 할 Unity 렌더링 선택지
  • 6.1 LineRenderer
  • 6.2 Mesh API
  • 6.3 Graphics.DrawMeshInstanced
  • 6.4 Texture2D
  • 6.5 MaterialPropertyBlock
  • 6.6 GL
• 7. Unity 6 URP 기준으로 꼭 지켜야 할 렌더링 원칙
• 8. Shader Graph 없이 HLSL/ShaderLab으로 연동하는 기본 구조
  • 8.1 왜 Shader Graph 대신 HLSL/ShaderLab인가
  • 8.2 URP Unlit 셰이더 기본 예제
  • 8.3 C#에서 셰이더 프로퍼티 제어하기
• 9. Compute Shader로 확장할 때 알아야 할 기준
  • 9.1 언제 Compute Shader로 넘어가야 하는가
  • 9.2 CPU 시뮬레이션과 Compute 시뮬레이션의 역할 분리
  • 9.3 Compute Shader 기본 예제
  • 9.4 C#에서 ComputeBuffer 연결하기
  • 9.5 Compute 확장 시 주의할 점
• 10. Unity 6 URP 기준 최소 실전 예제
  • 10.1 C# 파티클 시뮬레이션 + LineRenderer
  • 10.2 URP용 HLSL 셰이더와 연결하는 예제
• 11. 성능과 GC 체크리스트
• 12. 블로그 글을 쓰기 전에 반드시 점검할 것
• 13. 결론

---

1. 이 문서의 목적

이 문서는 Generative Art를 유니티에서 코드로 작성 시 항상 염두에 두어야 하는 기준을 다룬다.

• Unity에서 제너레이티브 아트를 어떻게 설계했는가
• 왜 그 자료구조를 골랐는가
• 왜 Update 루프를 그렇게 작성했는가
• 왜 LineRenderer, Mesh, Texture2D, Shader 중 특정 방식을 선택했는가
• 왜 CPU로 처리했고, 왜 어떤 부분은 GPU로 넘겼는가

---

2. Unity Generative Art를 보는 가장 중요한 관점

Unity에서 Generative Art, Procedural Art, Shader Art를 코드로 만든다는 것은 결국 실시간 시뮬레이션 시스템을 설계하는 일이다.

겉으로 보기에는 선, 점, 텍스처, 메시, 색 변화처럼 보여도 내부에서는 거의 항상 같은 구조가 반복된다.

1. 데이터를 만든다.
2. 시간과 규칙에 따라 상태를 바꾼다.
3. 그 상태를 시각적으로 출력한다.

즉, 핵심은 화려한 비주얼보다 먼저 데이터 흐름 설계다.

이 관점이 중요한 이유는 다음과 같다.

• 결과가 달라져도 구조는 재사용할 수 있다.
• 렌더링 방식을 바꿔도 시뮬레이션 코어를 유지할 수 있다.
• CPU 기반 실험에서 Compute Shader 기반 확장으로 넘어가기 쉽다.

---

3. 전체 구조는 반드시 데이터 생성 → 상태 변화 → 시각화로 나눈다

Unity에서 제너레이티브 시스템은 아래 구조로 생각하는 것이 가장 안전하다.

void Initialize()
{
    // 데이터 생성
}

void Step(float dt)
{
    // 상태 변화
}

void Render()
{
    // 시각화 반영
}

Unity 라이프사이클로 옮기면 보통 이렇게 된다.

• Awake() 또는 Start() → 초기화
• Update() / FixedUpdate() / LateUpdate() → 상태 변화
• Renderer, Mesh, Texture, Shader, Buffer → 시각화

이 구분을 해두면 코드가 길어져도 시스템이 무너지지 않는다.
반대로 이 구분이 없으면 작은 실험 코드가 금방 뒤엉킨다.

---

4. 데이터 생성 단계에서 반드시 알아야 할 C# 문법

4.1 Awake와 Start의 역할 분리

초기화 시점을 구분하는 것은 매우 중요하다.

• Awake()는 오브젝트가 생성되자마자 호출된다.
• Start()는 첫 프레임 직전에 호출된다.

따라서 일반적으로 다음 기준을 추천한다.

• Awake() → 자기 자신이 사용할 데이터 구조 생성
• Start() → 다른 컴포넌트 참조 이후의 실제 초기화

using UnityEngine;
using System.Collections.Generic;

public class GeneratorBootstrap : MonoBehaviour
{
    private List<ParticleData> particles;
    private Camera cachedCamera;

    void Awake()
    {
        particles = new List<ParticleData>(1024);
    }

    void Start()
    {
        cachedCamera = Camera.main;
        SpawnParticles(512);
    }

    void SpawnParticles(int count)
    {
        for (int i = 0; i < count; i++)
        {
            particles.Add(new ParticleData
            {
                position = Random.insideUnitSphere * 5f,
                velocity = Random.onUnitSphere,
                life = Random.Range(1f, 3f),
                maxLife = 3f
            });
        }
    }
}

public struct ParticleData
{
    public Vector3 position;
    public Vector3 velocity;
    public float life;
    public float maxLife;
}

핵심은 초기화 코드를 한 군데에 몰아넣는 것이 아니라, 의존성 유무에 따라 나누는 것이다.

4.2 struct와 class

제너레이티브 아트에서는 아래의 구분을 따라 코드를 짜는 것이 효율적이다.

• 작고 단순한 대량 데이터는 struct
• 행동을 조정하는 시스템 객체는 class

public struct ParticleData
{
    public Vector3 position;
    public Vector3 velocity;
    public float life;
    public float maxLife;
}

public class ParticleController : MonoBehaviour
{
}

왜 struct가 중요한가

파티클, 포인트, 셀, 샘플처럼 수천~수만 개가 반복적으로 갱신되는 데이터는 참조 객체를 개별적으로 관리하기보다, 값 타입 기반으로 묶어 다루는 편이 더 적합한 경우가 많다.

다만 struct = 무조건 스택, class = 무조건 힙이라고 이해하면 곤란하다.
실전에서는 그보다 아래 특징을 기억하는 편이 정확하다.

• struct는 값 타입이다.
• 값 복사가 일어난다.
• 연속된 메모리 구조로 다루기 유리하다.
• 작은 데이터 단위에 적합하다.
• GC 부담을 줄이는 데 도움이 된다.

가장 중요한 주의점

struct는 값을 꺼내 수정하고 다시 넣어야 한다.

for (int i = 0; i < particles.Count; i++)
{
    var p = particles[i];
    p.life -= Time.deltaTime;
    p.position += p.velocity * Time.deltaTime;
    particles[i] = p;
}

이 재할당 패턴을 놓치면 수정이 반영되지 않는다.
실시간 시뮬레이션에서는 매우 자주 나오는 핵심 패턴이다.

4.3 List와 Array 선택 기준

자료구조 선택은 코드 성격을 결정한다.

• List<T>는 개수가 유동적인 데이터에 적합하다.
• T[] 배열은 크기가 고정된 데이터에 적합하다.

private List<ParticleData> particles = new List<ParticleData>(1024);
private Vector3[] gridPoints = new Vector3[128 * 128];

보통 이렇게 정리하면 된다

• 파티클 생성/삭제가 잦다 → List<T>
• 해상도 고정 그리드다 → 배열
• 버텍스 버퍼, 색상 버퍼, 픽셀 버퍼처럼 크기가 정해져 있다 → 배열

중요한 실전 원칙

런타임 중 매 프레임 새 배열을 만들지 않는 것이 중요하다.
가능하면 한 번 할당하고 계속 재사용한다.

4.4 SerializeField와 인스펙터 설계

제너레이티브 아트는 파라미터 실험의 연속이다.
따라서 Inspector 노출 전략이 중요하다.

[SerializeField] private int count = 500;
[SerializeField] private float radius = 5f;
[SerializeField] private float speed = 1f;
[SerializeField] private Color baseColor = Color.white;
[SerializeField, Range(0f, 1f)] private float noiseScale = 0.25f;

권장 기준은 다음과 같다.

• 외부 코드에서 직접 만지지 못하게 하려면 private 유지
• 실험 파라미터는 [SerializeField]로 노출
• 빠른 범위 조절이 필요하면 [Range] 사용

즉, 캡슐화와 실험성을 동시에 확보하는 방식이다.

4.5 Random과 재현 가능한 시드

랜덤은 변형을 만든다. 하지만 재현성 없는 랜덤은 디버깅을 어렵게 만든다.

using URandom = UnityEngine.Random;

float speed = URandom.Range(0.5f, 2f);
Vector2 p2 = URandom.insideUnitCircle * 3f;
Vector3 p3 = URandom.insideUnitSphere * 5f;

재현 가능한 결과가 필요할 때

URandom.InitState(42);

이렇게 시드를 고정하면 예제 재현, 블로그 설명, 디버깅이 훨씬 쉬워진다.

별칭을 추천하는 이유

Unity의 Random과 .NET의 System.Random은 이름이 겹친다.
혼동을 피하려면 아래처럼 별칭을 두는 편이 안정적이다.

using URandom = UnityEngine.Random;

4.6 ScriptableObject로 설정 분리

파라미터가 많아질수록 코드와 데이터가 엉키기 쉽다.
이때 ScriptableObject는 매우 좋은 분리 수단이다.

using UnityEngine;

[CreateAssetMenu(menuName = "GenerativeArt/Noise Settings")]
public class NoiseSettings : ScriptableObject
{
    public float scale = 1f;
    public float speed = 1f;
    public float amplitude = 1f;
    public Color tint = Color.white;
}

이 방식은 다음에 특히 좋다.

• 여러 씬에서 같은 설정을 재사용할 때
• 시각 실험용 프리셋을 관리할 때
• 런타임 로직과 튜닝 데이터를 분리할 때

---

5. 상태 변화 단계에서 반드시 알아야 할 문법

5.1 Update, FixedUpdate, LateUpdate

Unity 실시간 시스템에서 루프 선택은 매우 중요하다.

• Update()는 일반적인 시각 상태 갱신에 사용한다.
• FixedUpdate()는 물리 엔진과 동기화가 필요한 경우에 사용한다.
• LateUpdate()는 다른 업데이트 이후 보정 단계에 사용한다.

void Update()
{
    StepParticles(Time.deltaTime);
}

void FixedUpdate()
{
    // Rigidbody 기반 물리 전용
}

void LateUpdate()
{
    // 카메라 추적, 트레일 보정 등
}

제너레이티브 아트 대부분은 물리 시뮬레이션이 아니라 시각 규칙 기반 상태 변화다.
따라서 대부분의 핵심 로직은 Update()에 들어간다.

5.2 deltaTime과 time

프레임레이트에 상관없이 동일한 움직임을 만들려면 Time.deltaTime을 사용해야 한다.

position += velocity * Time.deltaTime;

전체 시간 축을 파형에 넣고 싶다면 Time.time을 사용한다.

float t = Time.time;
float wave = Mathf.Sin(t * frequency + phase) * amplitude;
float ping = Mathf.PingPong(t * speed, 1f);

정리하면 이렇다.

• 이동량, 감쇠, 수명 감소 → deltaTime
• 진동, 루프, 시간 기반 함수 입력 → time

5.3 Mathf와 수학 기반 모션

제너레이티브 아트는 사실상 수학의 시각화다.
Unity에서는 Mathf가 그 중심이다.

float x = Mathf.Cos(angle) * radius;
float y = Mathf.Sin(angle) * radius;

float a = Mathf.Lerp(minValue, maxValue, t);
float b = Mathf.LerpUnclamped(minValue, maxValue, t);

float c = Mathf.Clamp(value, 0f, 1f);
float d = Mathf.Clamp01(value);

float loop = Mathf.Repeat(Time.time, 1f);
float ping = Mathf.PingPong(Time.time, 1f);

자주 쓰는 함수와 의미는 다음과 같다.

• Sin, Cos → 진동, 원운동, 위상 변화
• Lerp → 보간
• Clamp, Clamp01 → 값 안정화
• Repeat, PingPong → 주기성 부여
• SmoothDamp → 부드러운 추종

float velocityRef = 0f;
float smoothed = Mathf.SmoothDamp(current, target, ref velocityRef, 0.2f);

5.4 Vector 연산

방향, 거리, 영향력, 회전 기준 계산에 벡터 연산이 필수다.

Vector3 dir = (target - position).normalized;
float dist = Vector3.Distance(a, b);
float dot = Vector3.Dot(a.normalized, b.normalized);
Vector3 normal = Vector3.Cross(a, b);
Vector3 blended = Vector3.Lerp(from, to, t);

2D에서는 각도를 방향 벡터로 바꾸는 패턴도 자주 사용한다.

Vector2 dir2D = new Vector2(
    Mathf.Cos(angle * Mathf.Deg2Rad),
    Mathf.Sin(angle * Mathf.Deg2Rad)
);

이 연산들은 아래 문제를 푸는 데 자주 쓰인다.

• 타깃 방향으로 이동하기
• 거리 기반 감쇠 만들기
• 전방/후방 판정하기
• 법선 방향 또는 수직 방향 만들기
• 두 방향을 부드럽게 섞기

5.5 실시간 시스템의 기본은 for 루프

실시간 제너레이티브 시스템에서 가장 기본적인 패턴은 명시적 반복문이다.

void UpdateParticles(float dt)
{
    for (int i = 0; i < particles.Count; i++)
    {
        var p = particles[i];
        p.position += p.velocity * dt;
        p.life -= dt;
        particles[i] = p;
    }
}

이 패턴이 중요한 이유는 다음과 같다.

• 처리 순서가 명확하다.
• 디버깅이 쉽다.
• 값 타입 재할당이 자연스럽다.
• GC를 통제하기 쉽다.
• 성능 특성을 읽기 쉽다.

실험 단계에서 코드가 짧아 보인다는 이유로 너무 이른 시점에 추상화를 늘리면, 오히려 제어력이 떨어질 수 있다.

5.6 Coroutine

Coroutine은 시간 지연이나 순차 진행을 표현하기 좋다.

using System.Collections;
using UnityEngine;

public class SpawnRoutine : MonoBehaviour
{
    [SerializeField] private int count = 20;
    [SerializeField] private float delay = 0.05f;

    void Start()
    {
        StartCoroutine(SpawnSequence());
    }

    IEnumerator SpawnSequence()
    {
        for (int i = 0; i < count; i++)
        {
            SpawnParticle(i);
            yield return new WaitForSeconds(delay);
        }
    }

    void SpawnParticle(int index)
    {
        Debug.Log(index);
    }
}

좋은 사용처는 다음과 같다.

• 순차 스폰
• 페이드 인/아웃
• 단계적 연출
• 지연 트리거

다만 시뮬레이션 핵심 루프 전체를 Coroutine으로 대체하는 것은 추천하지 않는다.
핵심 업데이트는 Update(), 연출 흐름은 Coroutine이라는 분리가 보통 더 안정적이다.

5.7 LINQ 사용 기준

LINQ는 간결하지만 실시간 루프에서는 신중히 써야 한다.

using System.Linq;

var alive = particles.Where(p => p.life > 0f).ToList();
float avgSpeed = particles.Average(p => p.velocity.magnitude);
ParticleData fastest = particles
    .OrderByDescending(p => p.velocity.magnitude)
    .First();

LINQ가 좋은 경우는 다음과 같다.

• 초기 데이터 가공
• 툴 스크립트
• 디버그 통계
• 에디터 유틸리티

반면 아래 상황에서는 주의해야 한다.

• 매 프레임 Where, Select, OrderBy, ToList, ToArray
• 반복적으로 새로운 열거 객체와 결과 컬렉션을 만드는 경우

즉, LINQ는 금지 도구가 아니라 핫패스에서 절제해야 하는 도구다.

5.8 delegate, Action, Func

규칙을 갈아끼우는 구조를 만들 때 유용하다.

using System;
using UnityEngine;

public class RuleSwitch : MonoBehaviour
{
    private Func<Vector3, Vector3> flowRule;

    void Awake()
    {
        flowRule = p => new Vector3(
            Mathf.Sin(p.y + Time.time),
            Mathf.Cos(p.x + Time.time),
            0f
        );
    }

    Vector3 Evaluate(Vector3 p)
    {
        return flowRule != null ? flowRule(p) : Vector3.zero;
    }
}

이런 패턴은 다음에 유용하다.

• 움직임 규칙 교체
• 노이즈 함수 비교
• 생성 알고리즘 교체
• 실험적 패턴 A/B 테스트

하지만 최종 실시간 루프에서는 과도한 람다 캡처나 불필요한 간접 호출을 줄이는 편이 낫다.

---

6. 시각화 단계에서 알아야 할 Unity 렌더링 선택지

6.1 LineRenderer

선, 궤적, 리본형 흐름을 빠르게 확인하고 싶다면 LineRenderer가 가장 빠르다.

using UnityEngine;

[RequireComponent(typeof(LineRenderer))]
public class LineExample : MonoBehaviour
{
    [SerializeField] private Vector3[] points;
    private LineRenderer lr;

    void Awake()
    {
        lr = GetComponent<LineRenderer>();
    }

    void Start()
    {
        lr.positionCount = points.Length;
        lr.startWidth = 0.02f;
        lr.endWidth = 0.005f;
        lr.useWorldSpace = true;
        lr.SetPositions(points);
    }
}

중요한 팁은 다음과 같다.

• 점이 많으면 SetPosition(i, ...) 반복보다 SetPositions(array)가 낫다.
• 시뮬레이션 버퍼와 렌더 버퍼를 분리하면 관리가 쉬워진다.
• 빠른 실험에 특히 좋다.

6.2 Mesh API

복잡한 프로시저럴 형상을 직접 만들고 싶다면 결국 메시를 다루게 된다.

using UnityEngine;

[RequireComponent(typeof(MeshFilter), typeof(MeshRenderer))]
public class QuadMeshExample : MonoBehaviour
{
    private Mesh mesh;
    private Vector3[] verts;
    private int[] tris;
    private Color[] colors;

    void Awake()
    {
        mesh = new Mesh();
        mesh.name = "Procedural Quad";

        verts = new Vector3[4]
        {
            new Vector3(-1f, -1f, 0f),
            new Vector3( 1f, -1f, 0f),
            new Vector3(-1f,  1f, 0f),
            new Vector3( 1f,  1f, 0f)
        };

        tris = new int[6] { 0, 2, 1, 2, 3, 1 };
        colors = new Color[4] { Color.red, Color.yellow, Color.cyan, Color.magenta };

        mesh.vertices = verts;
        mesh.triangles = tris;
        mesh.colors = colors;
        mesh.RecalculateNormals();
        mesh.RecalculateBounds();

        GetComponent<MeshFilter>().sharedMesh = mesh;
    }
}

실전에서는 아래 기준이 중요하다.

• 버텍스 배열 재사용
• 필요 없는 재계산 줄이기
• 색상, UV, 노멀, 인덱스 버퍼 역할 분리
• CPU 메시 생성과 셰이더 변형 역할 분리

6.3 Graphics.DrawMeshInstanced

같은 메시를 많이 찍어야 할 때는 GameObject를 개별 생성하는 것보다 인스턴싱이 효율적이다.

using UnityEngine;

public class InstancingExample : MonoBehaviour
{
    [SerializeField] private Mesh mesh;
    [SerializeField] private Material material;
    [SerializeField] private int instanceCount = 256;

    private Matrix4x4[] matrices;

    void Awake()
    {
        matrices = new Matrix4x4[instanceCount];

        for (int i = 0; i < instanceCount; i++)
        {
            Vector3 pos = Random.insideUnitSphere * 10f;
            Quaternion rot = Quaternion.identity;
            Vector3 scale = Vector3.one * Random.Range(0.2f, 1f);
            matrices[i] = Matrix4x4.TRS(pos, rot, scale);
        }
    }

    void Update()
    {
        Graphics.DrawMeshInstanced(mesh, 0, material, matrices);
    }
}

주의할 점도 명확하다.

• 한 번에 최대 1023개 제한이 있다.
• 셰이더에서 GPU Instancing이 활성화되어야 한다.
• 더 큰 규모로 가면 indirect 또는 compute 기반 경로를 고려해야 한다.

6.4 Texture2D

픽셀 기반 패턴, 피드백 이미지, 셀룰러 시스템에는 Texture2D가 직접적이다.

using UnityEngine;

public class TextureExample : MonoBehaviour
{
    [SerializeField] private Renderer targetRenderer;
    [SerializeField] private int width = 256;
    [SerializeField] private int height = 256;

    private Texture2D tex;
    private Color32[] pixels;

    void Start()
    {
        tex = new Texture2D(width, height, TextureFormat.RGBA32, false);
        tex.filterMode = FilterMode.Point;
        pixels = new Color32[width * height];

        for (int i = 0; i < pixels.Length; i++)
            pixels[i] = new Color32(255, 0, 128, 255);

        tex.SetPixels32(pixels);
        tex.Apply();
        targetRenderer.material.mainTexture = tex;
    }
}

핵심은 아래 두 가지다.

• 대량 픽셀 갱신에는 SetPixels32()가 유리하다.
• 변경 뒤 Apply()를 호출해야 GPU에 반영된다.

하지만 Apply() 자체도 업로드 비용이 있으므로 호출 빈도를 생각해야 한다.

6.5 MaterialPropertyBlock

같은 머티리얼을 공유하면서 렌더러별 개별 값을 넣고 싶다면 MaterialPropertyBlock이 중요하다.

using UnityEngine;

[RequireComponent(typeof(Renderer))]
public class MPBExample : MonoBehaviour
{
    static readonly int ID_BaseColor = Shader.PropertyToID("_BaseColor");
    static readonly int ID_Alpha = Shader.PropertyToID("_Alpha");

    private Renderer cachedRenderer;
    private MaterialPropertyBlock mpb;

    void Awake()
    {
        cachedRenderer = GetComponent<Renderer>();
        mpb = new MaterialPropertyBlock();
    }

    void Update()
    {
        float alpha = Mathf.PingPong(Time.time, 1f);
        Color col = Color.Lerp(Color.cyan, Color.magenta, alpha);

        mpb.Clear();
        mpb.SetColor(ID_BaseColor, col);
        mpb.SetFloat(ID_Alpha, alpha);
        cachedRenderer.SetPropertyBlock(mpb);
    }
}

이 방식이 중요한 이유는 renderer.material 직접 접근이 머티리얼 인스턴스 복제를 유발할 수 있기 때문이다.

6.6 GL

GL은 즉시 모드 기반이므로 빠른 디버그나 프로토타이핑에는 쓸 수 있지만, 장기적으로 주력 렌더링 경로로 삼기에는 제한이 많다.

using UnityEngine;

public class GLExample : MonoBehaviour
{
    [SerializeField] private Material lineMaterial;

    void OnPostRender()
    {
        if (lineMaterial == null)
            return;

        lineMaterial.SetPass(0);

        GL.Begin(GL.LINES);
        GL.Color(Color.magenta);
        GL.Vertex3(0f, 0f, 0f);
        GL.Vertex3(1f, 1f, 0f);
        GL.End();
    }
}

실전 기준으로는 다음처럼 생각하면 된다.

• 빠른 시각 검증 → 가능
• 지속적인 제작 파이프라인 → 비추천
• 최종 결과물 경로 → 보통 다른 렌더링 방식이 낫다

---

7. Unity 6 URP 기준으로 꼭 지켜야 할 렌더링 원칙

Unity 6 이상에서 URP를 기준으로 작업한다면, 단순히 API를 아는 것보다 파이프라인 감각이 중요하다.

첫째, URP에서는 셰이더가 Built-in 파이프라인과 다르므로, 예전 CGPROGRAM 예제를 그대로 가져오면 맞지 않는 경우가 많다.
둘째, 아트 실험용 코드라도 머티리얼 인스턴스 관리, 셰이더 프로퍼티 관리, 렌더 패스 호환성을 염두에 두는 것이 좋다.

특히 아래 원칙을 추천한다.

• URP용 셰이더는 HLSLPROGRAM 기반으로 작성한다.
• 셰이더 속성 제어는 문자열보다 Shader.PropertyToID() 캐싱을 우선한다.
• 오브젝트별 머티리얼 차등값은 MaterialPropertyBlock으로 전달한다.
• 시뮬레이션 데이터와 시각 표현 로직을 분리한다.
• CPU에서 계산할 것과 GPU에서 계산할 것을 미리 나눈다.

즉, URP에서는 단순히 “보이게 만드는 것”보다 지속 가능한 렌더링 구조가 더 중요하다.

---

8. Shader Graph 없이 HLSL/ShaderLab으로 연동하는 기본 구조

8.1 왜 Shader Graph 대신 HLSL/ShaderLab인가

Shader Graph는 빠른 시각 실험에는 좋다.
하지만 Generative Art를 코드 중심으로 다루고 싶다면 HLSL/ShaderLab 방식이 다음 장점을 준다.

• 셰이더 동작을 텍스트로 정확히 통제할 수 있다.
• 수학 구조를 명시적으로 설명할 수 있다.
• 블로그 글에 코드와 논리를 직접 기록하기 좋다.
• C#과 셰이더 간의 파라미터 흐름을 더 명확하게 설계할 수 있다.
• 노드 의존 없이 장기 유지보수가 가능하다.

즉, 결과만이 아니라 원리와 구조를 함께 설명하려면 HLSL/ShaderLab이 더 적합하다.

8.2 URP Unlit 셰이더 기본 예제

아래는 Unity 6 URP에서 사용 가능한 간단한 Unlit 기반 HLSL/ShaderLab 예제다.
색상과 파형 왜곡을 코드로 직접 제어하는 최소 구조다.

Shader "Custom/URP/GenerativeUnlit"
{
    Properties
    {
        _BaseColor ("Base Color", Color) = (1,1,1,1)
        _Amplitude ("Amplitude", Float) = 0.1
        _Frequency ("Frequency", Float) = 2.0
        _Speed ("Speed", Float) = 1.0
    }

    SubShader
    {
        Tags
        {
            "RenderType" = "Opaque"
            "RenderPipeline" = "UniversalPipeline"
            "Queue" = "Geometry"
        }

        Pass
        {
            Name "ForwardUnlit"

            HLSLPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl"

            struct Attributes
            {
                float4 positionOS : POSITION;
                float2 uv : TEXCOORD0;
            };

            struct Varyings
            {
                float4 positionHCS : SV_POSITION;
                float2 uv : TEXCOORD0;
                float wave : TEXCOORD1;
            };

            CBUFFER_START(UnityPerMaterial)
                float4 _BaseColor;
                float _Amplitude;
                float _Frequency;
                float _Speed;
            CBUFFER_END

            Varyings vert(Attributes IN)
            {
                Varyings OUT;

                float t = _Time.y * _Speed;
                float wave = sin(IN.positionOS.x * _Frequency + t);
                float3 displaced = IN.positionOS.xyz;
                displaced.y += wave * _Amplitude;

                OUT.positionHCS = TransformObjectToHClip(displaced);
                OUT.uv = IN.uv;
                OUT.wave = wave;
                return OUT;
            }

            half4 frag(Varyings IN) : SV_Target
            {
                float glow = IN.wave * 0.5 + 0.5;
                float3 color = lerp(_BaseColor.rgb * 0.3, _BaseColor.rgb, glow);
                return half4(color, _BaseColor.a);
            }
            ENDHLSL
        }
    }
}

이 셰이더는 매우 단순하지만, 다음 개념을 모두 보여준다.

• URP용 ShaderLab 구조
• HLSLPROGRAM 사용
• Core.hlsl 포함
• 버텍스 단계에서 위치 변형
• 프래그먼트 단계에서 색상 계산
• 머티리얼 프로퍼티를 CBUFFER로 받는 구조

8.3 C#에서 셰이더 프로퍼티 제어하기

URP 셰이더를 작성했다면, 이제 C#에서 안정적으로 값을 넣어야 한다.

using UnityEngine;

[RequireComponent(typeof(Renderer))]
public class URPShaderDriver : MonoBehaviour
{
    static readonly int ID_BaseColor = Shader.PropertyToID("_BaseColor");
    static readonly int ID_Amplitude = Shader.PropertyToID("_Amplitude");
    static readonly int ID_Frequency = Shader.PropertyToID("_Frequency");
    static readonly int ID_Speed = Shader.PropertyToID("_Speed");

    [SerializeField] private Color baseColor = Color.cyan;
    [SerializeField] private float amplitude = 0.25f;
    [SerializeField] private float frequency = 4f;
    [SerializeField] private float speed = 1f;

    private Renderer cachedRenderer;
    private MaterialPropertyBlock mpb;

    void Awake()
    {
        cachedRenderer = GetComponent<Renderer>();
        mpb = new MaterialPropertyBlock();
    }

    void Update()
    {
        float animatedAmplitude = amplitude + Mathf.Sin(Time.time) * 0.05f;

        mpb.Clear();
        mpb.SetColor(ID_BaseColor, baseColor);
        mpb.SetFloat(ID_Amplitude, animatedAmplitude);
        mpb.SetFloat(ID_Frequency, frequency);
        mpb.SetFloat(ID_Speed, speed);
        cachedRenderer.SetPropertyBlock(mpb);
    }
}

여기서 중요한 것은 두 가지다.

• 문자열 대신 프로퍼티 ID를 캐싱한다.
• MaterialPropertyBlock으로 오브젝트별 값을 전달한다.

이 구조를 익히면 Shader Graph 없이도 대부분의 Shader Art 제어가 가능하다.

---

9. Compute Shader로 확장할 때 알아야 할 기준

9.1 언제 Compute Shader로 넘어가야 하는가

처음부터 모든 것을 Compute Shader로 시작할 필요는 없다.
오히려 대부분의 경우는 CPU 버전으로 구조를 먼저 검증하는 편이 낫다.

그럼에도 아래 상황에서는 Compute Shader 확장을 진지하게 고려해야 한다.

• 파티클 수가 크게 늘어난다.
• CPU 루프가 병목이 된다.
• 대규모 그리드 연산이 필요하다.
• 픽셀 또는 필드 계산을 GPU 병렬화하는 편이 자연스럽다.
• 렌더링 이전의 상태 계산 자체가 너무 무겁다.

즉, Compute Shader는 “멋있어서” 쓰는 것이 아니라, 데이터 규모와 계산 패턴이 GPU 병렬화에 어울릴 때 쓰는 것이다.

9.2 CPU 시뮬레이션과 Compute 시뮬레이션의 역할 분리

Compute로 넘어가더라도 구조 원칙은 바뀌지 않는다.

• CPU는 시스템 제어, 파라미터 설정, 버퍼 바인딩을 담당한다.
• GPU Compute는 대량 상태 계산을 담당한다.
• 렌더 셰이더는 계산 결과를 화면에 보여준다.

즉, 구조는 여전히 이렇다.

1. CPU가 초기 버퍼를 준비한다.
2. Compute Shader가 상태를 갱신한다.
3. 렌더 단계가 그 버퍼를 읽는다.

핵심은 CPU와 GPU의 역할을 섞지 않는 것이다.

9.3 Compute Shader 기본 예제

아래는 가장 단순한 파티클 이동용 Compute Shader 예제다.

#pragma kernel CSMain

struct Particle
{
    float3 position;
    float3 velocity;
    float life;
    float maxLife;
};

RWStructuredBuffer<Particle> particles;

float deltaTime;
float radius;
float timeValue;

[numthreads(256, 1, 1)]
void CSMain(uint3 id : SV_DispatchThreadID)
{
    uint i = id.x;
    Particle p = particles[i];

    float3 flow = float3(
        sin(p.position.y + timeValue),
        cos(p.position.x + timeValue),
        sin(p.position.z + timeValue * 0.5)
    );

    p.velocity += flow * deltaTime;
    p.position += p.velocity * deltaTime;
    p.life -= deltaTime;

    if (p.life <= 0.0)
    {
        float a = frac(sin((i + 1) * 12.9898) * 43758.5453);
        float b = frac(sin((i + 7) * 78.233) * 12345.6789);
        float c = frac(sin((i + 13) * 39.425) * 24680.1357);

        p.position = (float3(a, b, c) * 2.0 - 1.0) * radius;
        p.velocity = 0;
        p.life = p.maxLife;
    }

    particles[i] = p;
}

이 예제는 단순하지만 아래 개념을 보여준다.

• RWStructuredBuffer를 통한 읽기/쓰기
• numthreads 기반 병렬 실행
• 파티클 구조체 기반 상태 갱신
• 수명 리셋 로직

9.4 C#에서 ComputeBuffer 연결하기

Compute Shader를 C#에서 연결하는 기본 구조는 다음과 같다.

using UnityEngine;
using System.Runtime.InteropServices;

public class ComputeParticleController : MonoBehaviour
{
    [StructLayout(LayoutKind.Sequential)]
    public struct ParticleData
    {
        public Vector3 position;
        public Vector3 velocity;
        public float life;
        public float maxLife;
    }

    [SerializeField] private ComputeShader computeShader;
    [SerializeField] private int count = 4096;
    [SerializeField] private float radius = 5f;

    private ComputeBuffer particleBuffer;
    private int kernel;

    void Start()
    {
        kernel = computeShader.FindKernel("CSMain");

        ParticleData[] data = new ParticleData[count];
        for (int i = 0; i < count; i++)
        {
            Vector3 pos = Random.insideUnitSphere * radius;
            data[i] = new ParticleData
            {
                position = pos,
                velocity = Random.onUnitSphere,
                life = Random.Range(1f, 3f),
                maxLife = 3f
            };
        }

        int stride = Marshal.SizeOf<ParticleData>();
        particleBuffer = new ComputeBuffer(count, stride);
        particleBuffer.SetData(data);

        computeShader.SetBuffer(kernel, "particles", particleBuffer);
    }

    void Update()
    {
        computeShader.SetFloat("deltaTime", Time.deltaTime);
        computeShader.SetFloat("radius", radius);
        computeShader.SetFloat("timeValue", Time.time);

        int groups = Mathf.CeilToInt(count / 256f);
        computeShader.Dispatch(kernel, groups, 1, 1);
    }

    void OnDestroy()
    {
        if (particleBuffer != null)
        {
            particleBuffer.Release();
            particleBuffer = null;
        }
    }
}

여기서 가장 중요한 것은 CPU 구조체와 HLSL 구조체의 메모리 레이아웃을 일치시키는 것이다.
Compute Shader 작업에서 문제가 생기면 가장 먼저 구조체 정렬과 stride를 의심해야 한다.

9.5 Compute 확장 시 주의할 점

Compute Shader는 강력하지만 아래 함정을 항상 의식해야 한다.

• CPU와 GPU 구조체 정렬 불일치
• 버퍼 Release 누락
• 스레드 그룹 크기 계산 오류
• 렌더 셰이더와 Compute 버퍼 레이아웃 불일치
• 디버깅 난이도 상승

따라서 권장 순서는 이렇다.

1. 먼저 CPU 버전으로 동작을 검증한다.
2. 데이터 구조를 확정한다.
3. 병목 구간만 Compute로 옮긴다.
4. 렌더 단계는 가능한 한 기존 구조를 유지한다.

즉, Compute는 시작점이 아니라 확장 단계로 보는 편이 맞다.

---

10. Unity 6 URP 기준 최소 실전 예제

10.1 C# 파티클 시뮬레이션 + LineRenderer

아래 예제는 Unity 6 URP 프로젝트에서도 바로 사용할 수 있는, 가장 작은 형태의 실전 예제다.
핵심은 데이터 생성 → 상태 변화 → 렌더 반영 구조를 분명하게 보여주는 것이다.

using UnityEngine;
using System.Collections.Generic;

[RequireComponent(typeof(LineRenderer))]
public class GenerativeTrailURP : MonoBehaviour
{
    private struct ParticleData
    {
        public Vector3 position;
        public Vector3 velocity;
        public float life;
        public float maxLife;
    }

    [Header("Simulation")]
    [SerializeField] private int count = 128;
    [SerializeField] private float radius = 5f;
    [SerializeField] private float speed = 1f;
    [SerializeField] private float noiseScale = 0.5f;
    [SerializeField] private float noiseSpeed = 1f;
    [SerializeField] private int randomSeed = 42;

    [Header("Line")]
    [SerializeField] private float startWidth = 0.06f;
    [SerializeField] private float endWidth = 0.01f;
    [SerializeField] private Gradient lineGradient;

    private readonly List<ParticleData> particles = new List<ParticleData>();
    private Vector3[] positions;
    private LineRenderer lineRenderer;

    void Awake()
    {
        lineRenderer = GetComponent<LineRenderer>();
        positions = new Vector3[count];
        particles.Capacity = count;
    }

    void Start()
    {
        Random.InitState(randomSeed);
        InitializeParticles();
        SetupLineRenderer();
    }

    void Update()
    {
        Step(Time.deltaTime);
        ApplyLine();
    }

    void InitializeParticles()
    {
        particles.Clear();

        for (int i = 0; i < count; i++)
        {
            Vector3 pos = Random.insideUnitSphere * radius;
            particles.Add(new ParticleData
            {
                position = pos,
                velocity = Random.onUnitSphere * speed,
                life = Random.Range(2f, 5f),
                maxLife = 5f
            });
            positions[i] = pos;
        }
    }

    void SetupLineRenderer()
    {
        lineRenderer.positionCount = count;
        lineRenderer.useWorldSpace = true;
        lineRenderer.startWidth = startWidth;
        lineRenderer.endWidth = endWidth;
        lineRenderer.textureMode = LineTextureMode.Stretch;
        lineRenderer.alignment = LineAlignment.View;

        if (lineGradient != null)
            lineRenderer.colorGradient = lineGradient;
    }

    void Step(float dt)
    {
        float t = Time.time * noiseSpeed;

        for (int i = 0; i < particles.Count; i++)
        {
            var p = particles[i];

            Vector3 flow = new Vector3(
                Mathf.PerlinNoise(p.position.y * noiseScale + t, p.position.z * noiseScale) - 0.5f,
                Mathf.PerlinNoise(p.position.z * noiseScale + t, p.position.x * noiseScale) - 0.5f,
                Mathf.PerlinNoise(p.position.x * noiseScale + t, p.position.y * noiseScale) - 0.5f
            );

            p.velocity += flow * dt;
            p.position += p.velocity * dt;
            p.life -= dt;

            if (p.life <= 0f)
            {
                p.position = Random.insideUnitSphere * radius;
                p.velocity = Random.onUnitSphere * speed;
                p.life = p.maxLife;
            }

            particles[i] = p;
            positions[i] = p.position;
        }
    }

    void ApplyLine()
    {
        lineRenderer.SetPositions(positions);
    }
}

이 예제가 보여주는 핵심은 다음과 같다.

• struct 기반 상태 저장
• List<T>를 통한 동적 관리
• Update() 기반 시뮬레이션 루프
• deltaTime 사용
• PerlinNoise 기반 흐름 변화
• LineRenderer를 통한 즉시 시각화
• 배열 재사용을 통한 GC 감소

10.2 URP용 HLSL 셰이더와 연결하는 예제

아래는 위 LineRenderer 예제와는 별개이며, URP 셰이더를 코드로 제어하는 최소 드라이버 예제이다.

using UnityEngine;

[RequireComponent(typeof(Renderer))]
public class GenerativeMaterialDriverURP : MonoBehaviour
{
    static readonly int ID_BaseColor = Shader.PropertyToID("_BaseColor");
    static readonly int ID_Amplitude = Shader.PropertyToID("_Amplitude");
    static readonly int ID_Frequency = Shader.PropertyToID("_Frequency");
    static readonly int ID_Speed = Shader.PropertyToID("_Speed");

    [SerializeField] private Color baseColor = new Color(0.2f, 0.9f, 1f, 1f);
    [SerializeField] private float amplitude = 0.12f;
    [SerializeField] private float frequency = 3f;
    [SerializeField] private float speed = 1f;
    [SerializeField] private bool animateColor = true;

    private Renderer cachedRenderer;
    private MaterialPropertyBlock mpb;

    void Awake()
    {
        cachedRenderer = GetComponent<Renderer>();
        mpb = new MaterialPropertyBlock();
    }

    void Update()
    {
        Color finalColor = baseColor;
        if (animateColor)
        {
            float t = Mathf.PingPong(Time.time * 0.5f, 1f);
            finalColor = Color.Lerp(new Color(0.2f, 0.9f, 1f, 1f), new Color(1f, 0.2f, 0.8f, 1f), t);
        }

        mpb.Clear();
        mpb.SetColor(ID_BaseColor, finalColor);
        mpb.SetFloat(ID_Amplitude, amplitude);
        mpb.SetFloat(ID_Frequency, frequency);
        mpb.SetFloat(ID_Speed, speed);
        cachedRenderer.SetPropertyBlock(mpb);
    }
}

이 코드는 Shader Graph 없이도 C#에서 URP 셰이더를 안정적으로 제어하는 기본 패턴을 보여준다.

---

11. 성능과 GC 체크리스트

Generative Art 시스템은 보기보다 빨리 병목에 닿는다.
따라서 아래 항목은 거의 항상 점검해야 한다.

• 매 프레임 new를 만들고 있지 않은가
• ToList(), ToArray()를 핫패스에서 남발하고 있지 않은가
• 버퍼를 재사용하고 있는가
• renderer.material을 무심코 호출하고 있지 않은가
• 텍스처 Apply() 호출 빈도가 과도하지 않은가
• 메시 버텍스 배열을 계속 새로 만들고 있지 않은가
• GPU Instancing을 쓸 수 있는 상황에서 GameObject를 과도하게 만들고 있지 않은가
• ComputeBuffer Release()를 놓치지 않았는가
• 구조체 레이아웃이 C#과 HLSL 사이에서 일치하는가

결국 성능 문제는 대개 특별한 비밀이 아니라, 데이터 재사용과 할당 제어 문제로 돌아온다.

---

12. 블로그 글을 쓰기 전에 반드시 점검할 것

이 문서의 최종 목적은 구현뿐 아니라 설명 가능한 구현이다.
따라서 블로그 글을 쓰기 전에는 아래 질문에 답할 수 있어야 한다.

• 내 작업은 데이터 생성, 상태 변화, 시각화 중 어디에 초점이 있는가
• 핵심 상태는 어떤 자료구조로 저장했는가
• 왜 struct 또는 class를 선택했는가
• 왜 Update()를 사용했고, 왜 다른 루프가 아닌가
• 시각화 방식은 왜 LineRenderer, Mesh, Texture2D, Shader, Compute 중 하나였는가
• 랜덤은 단순 장식인가, 구조적 규칙의 일부인가
• CPU 계산과 GPU 계산은 어디서 나뉘는가
• 성능상 가장 위험한 지점은 무엇인가

이 질문들에 답할 수 있으면, 결과 이미지를 나열하는 수준을 넘어서 구조를 설명하는 글을 쓸 수 있다.

---

13. 결론

Unity 6 URP에서 Generative Art, Procedural Art, Shader Art를 코드로 만든다는 것은 결국 시뮬레이션 구조를 설계하고, 그것을 적절한 렌더링 경로에 연결하는 일이다.

좋은 출발점은 항상 같다.

• 데이터를 먼저 설계한다.
• 상태 변화 규칙을 명확히 만든다.
• 시각화는 목적에 맞는 API를 고른다.
• Inspector 실험성과 내부 제어를 동시에 확보한다.
• 매 프레임 할당을 줄인다.
• 셰이더와 C#의 역할을 분리한다.
• 필요할 때만 Compute Shader로 확장한다.

즉, 좋은 제너레이티브 아트 코드는 우연히 나오지 않는다.
대부분은 작은 데이터 구조, 명시적인 업데이트 루프, 안정적인 렌더링 경로, 분명한 역할 분리에서 나온다.

---