개발농장

[유니티 공부 기록] #5 - GC & 프로파일러

코드짜는농부 — Sat, 24 Oct 2026 20:34:00 +0900

유니티 개발을 하다보면 오브젝트가 갑자기 많아지거나, 너무 무거운 등 다양한 이유로 게임이 끊길 때가 있다.

이 렉의 원인은 절반은 내가 짠 코드 속에 있어서 금방 찾을 수 있지만, 절반은 그렇지 않았던 것 같다.

그럴 때 마다 구글(AI가 없던 시절...)에 현상들을 적어보면서 열심히 구글링했었다.

하지만 이번에 공부를 하면서, 그 번거롭던 작업을 좀 더 효율적이고 정확하게 처리할 수 있는 방법을 알게 되었다.

이걸 알려면 우선 GC에 대해서 알고 넘어가야 한다.

가비지 컬렉션 (Garbage Collection)

가비지 컬렉션(GC)는 메모리에 할당된 것이 더 이상 쓰이지 않게 되었을 때, 자동으로 그 메모리를 비워주는 기능이다.

말 그대로 메모리에 남은 쓰레기들을 치워주는 것이다.

이런 쓰레기들은 '다른 어떠한 곳에서도 자신을 참조하고 있지 않은' 상태이다.

다른 곳에서 아무도 필요로 하지 않으니, 더 이상 필요없는 쓰레기로 취급되어 메모리에서 비워져버린다.

이쯤에서 용어를 한 번 정리해보자.

메모리 할당, 보유, 회수

메모리 할당 : 객체가 쓸 메모리 공간을 확보
메모리 보유 : 이미 만든 객체가 다른 객체에 접근할 수 있는 참조를 보유
메모리 회수 : 더 이상 접근할 수 없게 된 메모리 공간을 비움

여기에서 GC가 하는 일이 바로 '메모리 회수' 인 것이다.

그럼 반대로, GC가 비우지 않는것은 '다른 곳에서 자신을 참조하고있는' 것들, 즉 누군가가 '보유' 하고있는 것임을 알 수 있다.

이런 것들에는 명시적으로 참조를 갖게 한 것들 말고도 더 있다.

바로 static 이다.

static으로 선언한 것은 전역에 인스턴스를 단 하나만 두고 그것에 접근하게 한다.

그런데 이러면 이 하나뿐인 인스턴스를 다른 객체들이 언제 접근할지 모른다. 영원히 안 찾을수도 있고, 먼 미래에 한 번 찾을수도 있다.

static이라는 정적 필드는 이 '언제 접근할지 모른다' 를 위해 언제라도 접근할 수 있는 상태를 만들기 위해 static으로 선언한 인스턴스 메모리를 계속 '보유'하고있는 것이다.

GC의 관점에서는 이 인스턴스가 'static 정적 필드' 에 의해 참조되고 있으니, 회수하지 않는 것이다.

그럼 대체 이 '메모리'는 뭘까?

유니티 메모리의 종류

크게 3가지 종류가 있다.

관리 힙 (Managed Heap) : 일반 C# 클래스 객체, 배열, 문자열, 리스트... 등이 들어간다.
스택 (Stack) : 함수 호출 정보, 일부 지역 정보(함수에서 쓰는 변수, 참조 등)
네이티브 메모리 (Native Memory) : 엔진 쪽 객체 / 자원 등

여기에서 관리 힙 구역을 GC가 담당하고있다.

주의해야 할 것은, GC가 관리 힙에 있는 쓰레기를 회수하는 것은 맞지만, 관리 힙만 들여다 보는것은 아니다.

스택과 네이티브 메모리도 둘러본다.

다만, 둘러보는 목적이 '관리 힙에 있는 무언가의 참조를 갖고있나?'(보유 여부) 를 보기 위해 둘러보는 것이다.

스택은 다 둘러보고, 네이티브 메모리는 이 참조를 둘러보라고 명시해둬야 둘러본다.

다시 정리하면, GC는 관리 힙 구역에 있는 것들 중 아무한테도 보유되고있지 않은 것들을 회수해간다.

GC를 먼저 알고 넘어가려고 한 이유가 있다.

위에서 '게임이 끊긴다' 라고 표현한 현상이, 바로 이 메모리 사용량 때문에 발생하는 경우가 있기 때문이다.

사실 이런 경우가 좀 많다.

GC가 없다면 메모리가 계속 쌓이면서 끊기는 것이 아니라 멈춰버릴 것이다.

하지만 꼭 메모리 때문만은 아니다. 정말 다양한 이유로 게임이 끊길 수 있다.

그럼 이제 이 '끊김'을 분석하는 과정을 알아보자.

프로파일러

게임이 끊긴다는 것은 프레임 드랍이 생긴다는 것이다.

이는 다시 말하면, 한 프레임 안에 작업량이 너무 많아서 알맞은 타이밍에 다음 프레임으로 넘어가지 못한다는 것이다.

그럼 한 프레임 안에서 무슨 작업들이 일어나는지 알면, 이 끊김을 해결할 수 있을 것이다.

이걸 보여주는것이 바로 '프로파일러(Profiler)' 이다.

프로파일러 녹화를 켜둔 상태로 게임을 플레이하면, 프레임 안에서 일어나는 모든 것들이 기록된다.

만약 중간에 끊긴다면 그 끊기는 프레임에서 무슨 일이 일어나는지 알 수 있다.

보는 방법

Windows → Analysis → Profiler 로 접근할 수 있다.

켜면 타임라인 같은 창이 나온다.

이 타임라인에 게임에서 무슨 일이 벌어지는지 다 녹화된다.

왼쪽 위 쯤 있는 빨간 버튼을 게임 플레이 도중 누르면 된다.

이렇게 말이다.

녹화버튼을 다시 눌러 녹화를 종료하고, 오른쪽 위에 저장 버튼을 눌러 기록으로 남길수도 있다.

지금 저 위에 타임라인에 나타난 그래프들은 시각적 자료일 뿐이다. 어디 프레임에서 작업량이 많았는지 보기 쉽게 나타낸 것이다.

우리가 볼 것은 그 아래 수치들이다.

Total : 하위 호출을 포함한 전체 실행 비율
Self : 하위 호출을 제외한 전체 실행 비율
Calls : 호출 횟수
GC Alloc : GC가 관리하는 메모리(관리 힙)에 새로 작성된 객체들의 용량
Time ms : 하위 호출을 포함한 전체 실행 시간
Self ms : 하위 호출을 제외한 전체 실행 시간

이것들을 보고서 성능에 어떤 문제를 발생시키는지 알 수 있다.

검색창에 스크립트 내에서 작성한 함수 이름을 검색해 그 작업 정보도 알 수 있다.

이건 일부러 부하를 일으켰을 때 실제로 부하가 일어난 프레임의 정보이다.

60프레임이 나오려면 프레임당 16.667ms 정도의 시간이 필요한데, 이 프레임에서는 그것보다 더 오래걸린 약 18ms의 시간이 걸려서 느끼지는 못해도 한번 끊겼음을 알 수 있다.

창의 상단의 이 부분을 보자.

왼쪽 Highlight를 누르면 위에서 본 프레임의 정보를 보여준다.

그 아래에 있는 Target Frame을 눌러서 게임의 원하는 프레임률을 설정해 부하의 기준을 바꿀수도 있다.

옆의 타임라인을 눌러 프레임 이동이 가능하고, 위의 ▶| 버튼을 눌러 한 프레임씩 앞으로든 뒤로든 넘겨볼 수 있다.

메모리 프로파일러도 있다.

여기에서는 어떤 메모리가 어떻게 쓰였는지 보여준다.

왼쪽 위의 캡쳐 버튼으로 메모리 상황을 스냅샷으로 찍는 원리이다.

짧은 생각

게임의 성능을 눈으로 볼 수 있다는 점에서 앞으로 많이 사용할 것 같다.

객체 참조를 넣으려면 반드시 안 쓰게 될 때 모든 것에서 참조를 해제해야한다는 것을 잊지 말자.

[유니티 공부 기록] #4 - 인터페이스

코드짜는농부 — Wed, 21 Oct 2026 14:56:00 +0900

C++로 알고리즘 문제들을 풀 때, 인터페이스 구조를 쓸 때가 있다.

여기에서 인터페이스란, '어떤 기능을 어떤 방식으로 사용할 수 있는지 정한 약속' 으로 설명할 수 있다.

기능 사용법은 공통으로 정하고, 내부 처리 방법은 실제로 사용하는 곳에 맡기는 것이다.

C++에서는 이걸 추상 클래스로 만들어서 사용하곤 했다.

C#에서도 이걸 구현하려고 abstract나 virtual 키워드를 쓰면서 해보려고 했는데, 공부하다 보니 interface라는 것을 따로 지원해준다는 것을 알았다.

C# 인터페이스

위에서 말했듯이, C#에서는 interface로 인터페이스를 지원해주고 있다.

public interface IDamageable
{
    void TakeDamage(int amount);
}

이렇게 데미지를 받는 인터페이스를 구현할 수 있다.

이 IDamageable 인터페이스는 'int 값 하나를 전달해 TakeDamage를 호출할 수 있다' 라고 기능과 방식을 정의한 것이다.

그리고, 클래스에 이걸 상속시켜서 '이 친구는 데미지를 받을 수 있습니다' 라고 표현할 수도 있다.

public class Enemy : MonoBehaviour, IDamageable
{
    public void TakeDamage(int amount)
    {
        // Blabla
    }
}

이걸 알게 되면서, 그동안 인터페이스를 잘못 쓰고 있다는 것을 깨달았다.

나는 인터페이스를 단순히 '비어있는 템플릿' 이라고 생각하고, C++로 문제를 풀 때 부모 클래스를 인터페이스로 구현해놓고 자식 클래스에서 이것만 상속받아 사용하고있었다.

이건 반은 맞고 반은 틀린데,

비어있는 템플릿은 맞다.
다만, 템플릿만 상속받아서 템플릿에 맞춰 구현한다기 보다는, 인터페이스 상속을 통해 클래스에 역할을 한 개 또는 그 이상의 개수만큼 부여하는 것이 핵심이다.
그리고 나중에는 그 역할을 호출해 타입이 뭐가 되었든 역할의 기능을 수행하라고 시킬 수 있는 것도 중요하다.

C#에서는 기본적으로 다중 상속을 지원하지 않지만, 인터페이스 만큼은 여러개를 상속 받는것이 된다.

그래서 클래스를 만든 뒤 인터페이스를 상속 받아 역할을 명시할 수 있다.

짧은 생각

인터페이스 자체를 군대에 있을 때 알았고, 유니티에 interface가 있다는 걸 이번에 알아서, 이걸 조금만 더 빨리 알았더라면 그동안 게임 만드는 과정에서 겪었던 불편들을 간편하게 해결할 수 있었겠다 하는 생각이 들었다.

지금까지 공부하면서 알게 된 내용만 합쳐도 게임 구조를 설계할 때 엄청난 도움이 될 것 같다.

[유니티 공부 기록] #3 - 씬 개발 및 전환

코드짜는농부 — Wed, 21 Oct 2026 13:58:46 +0900

유니티로 게임을 개발하면 씬을 넘기면서 스테이지를 전환하거나, 컷씬을 보여주게 된다.

이번에 공부하면서 재밌고 혁신적이라고 느꼈던 것들이 있어서 기록하려고 한다.

여러 씬 동시 수정 (Multi-Scene Editing)

일단 제목부터 심상치 않다. 여러 개의 씬을 동시에 수정하려면, 그 씬들을 모두 동시에 열어서 동시에 봐야 한다.

놀랍게도, 유니티는 그 기능을 지원하고있었다! 그것도 너무 쉬운 방법으로.

여러 씬 열기

우선, 씬 두 개를 만들어보자.

두 씬에 모두 큐브를 만들고, 위치는 서로 약간 어긋나게 해 준다.

이제 저 두 씬을 동시에 열어볼 것이다.

한 씬을 열고, 하이어라키 창에 다른 씬을 끌어다 놓으면 된다.

두 씬이 한 화면에 동시에 보이는 모습

이제 이렇게 여러 씬을 열고 동시에 수정할 수 있다.

오브젝트들이 어느 씬에 배치된 것들인지 알 수 있고, 씬 간에 오브젝트 이동도 자유로워서 정말 편하다.

여러 씬 로드

여러 씬을 동시에 편집했다면, 게임을 플레이 하면서도 여러 씬을 불러올 수 있다.

이것도 보여주는 방식은 똑같다. 한 화면에 두 씬이 동시에 보인다.

불러오는 방식에는 비동기로 씬을 불러오는 방식이 관여한다.

씬 로드 방법

씬을 불러오는 방법에는 크게 두 가지가 있다.

SceneManager.LoadScene(씬 이름) // 동기
SceneManager.LoadSceneAsync(씬 이름) // 비동기

동기적으로 불러오는 방법과, 비동기적으로 불러오는 방법이다.

동기적으로 불러오면 씬을 불러오는 동안에는 다른 작업을 처리하지 못한다.
비동기적으로 불러오면 씬을 불러오는 동안에도 다른 작업을 할 수 있다.

이 때, 여러 씬을 불러오는건 보통 플레이 도중 추가 씬을 불러오기 때문에 비동기를 사용하는 것이다.

불러온 씬을 보여주는 방법에도 두 가지가 있다.

LoadSceneMode.Single
LoadSceneMode.Additive

Single 모드는 한 번에 한 씬만 보여주게 하는 것이고,
Additive 모드는 현재 씬 위에 추가로 더 불러오는 것이다.

씬을 불러왔다면, 다시 집어넣을 수도 있다.

UnloadSceneAsync(씬 이름)

씬을 언로드 하려면, Additive 하게 두 개 이상의 씬이 불러와진 상태여야 한다.
하나만 불러와진 상태에서는 언로드 할 수 없다.

Additive 로드

여기에서 Additive로 불러오는 것이 핵심이다.

불러온 두 씬을 동시에 보여주기 때문에, 구간별로 맵을 따로 만들어 로드하거나 언로드 해서 최적화를 신경쓸 수 있다.

이걸 잘 보여주는 예시 자료가 있다.

스크립터블 오브젝트로 더 나은 씬 워크플로 달성하기

Unity에서 여러 씬을 관리하는 것은 어려운 작업이며, 이 워크플로를 개선하는 것은 게임의 성능과 팀의 생산성 모두에 중요합니다. 여기에서는 대규모 프로젝트에 맞게 확장할 수 있는 방식으로

unity.com

유니티에서 직접 공개한 방법이다.

이렇게 구간이 많고 한 번에 두~세 개 정도의 맵만 보여지는 경우라면 이 방법을 사용해 최적화를 할 수 있다.

짧은 생각

이걸 사용하면 확실히 스테이지가 나눠지거나 맵이 구간별로 끊기는 등의 장르 게임을 개발할 때 정말 편할 것 같다.

그리고 동시에 씬 하나 하나가 가벼워져서 수정하기도 쉽고, 관리하기도 쉬울 것 같다.

무엇보다, 씬 이름 규칙을 통일해두면 여러가지 종류의 전체 맵을 개발하는게 진짜 개발이 쉬워질 것 같다.

[유니티 공부 기록] #2 - 직렬화 (Serialization)

코드짜는농부 — Tue, 20 Oct 2026 22:09:16 +0900

유니티 에셋을 임포트 해놓고 쓰다보면 에셋 스크립트 파일을 잘못 들어갈 때가 있었다.

그때마다 보던게 있었다.

[SerializeField], [System.Serializable], ...

이것들이다.

그 당시에는 이 키워드들이 단순히 private 앞에 붙어있어서 '그냥 인스펙터에 보여주는 용도인가보다' 했다.

private 변수들은 인스펙터에 안보이는데, 이게 붙은 것들은 보여서 그렇게 생각했다.

그러다 이번에 유니티를 공부하면서 다시 만났는데, 내가 몰랐던 것들이 많아서 기록해두기로 했다.

직렬화

유니티에서 인스펙터에 입력한 값들은 에디터를 껐다 켜도 저장된다.

처음에는 그냥 유니티가 저장해주나보다 했다.

하지만 공부해보니, 그건 아니었다.

유니티는 인스펙터 값들을 저장해 주는것은 맞다.

여기서 주의할 것이, '인스펙터 값을 저장' 이 아니고 '인스펙터에 입력된 값들이 저장 대상' 인 것이다.

인스펙터는 단순히 값 편집이 편하도록 띄워주는 것이 아니고, '직렬화' 할 값들에 사용자가 할당하기 쉽도록 보여주는 것이다.

그리고 유니티는 이 '직렬화' 된 값들을 저장한다.

여기서 '직렬화(Serialization)'은 값을 저장이 가능한 형태로 변환하는 것을 말한다.

인스펙터에는 기본적으로 public으로 선언된 변수들만 보여진다.

이는 public 변수가 기본적으로 직렬화 된다는 것을 말한다.

public과는 달리, private나 클래스의 멤버 변수 같은 것들은 인스펙터에 보여지지 않는다. 직렬화 되지 않는 것이다.

보통 이런 것들은 인스펙터에도 나오지 않아서 코드에서 값을 부여했다. (Awake()에서 컴포넌트 찾아서 부여하거나, 선언과 동시에 = XXX 이런식으로)

그런데, 이 것들은 코드에서 값을 부여하는 것이지 유니티가 저장된 값을 불러오는 것이 아니다.

그동안은 당연히 코드에서 불러와야 하는거 아닌가 하면서 private와 클래스 멤버 변수들을 저장한다는 생각을 아예 안했었다.

여기에서 글 처음에 말했던 의문이 풀렸다.

[SerializeField], [System.Serializable] 같은 키워드들이 위 값들을 저장할 수 있게 직렬화 해주는 역할을 한다.

이에 따라, 직렬화가 가능해졌으므로 인스펙터는 이 키워드들이 붙은 private나 클래스를 인스펙터에 보여준다.

이런 키워드들이 여러가지 있다.

키워드	역할
[SerializeField]	private 도 직렬화에 포함시킨다. 단, static, const, readonly가 붙은 것들은 제외한다.
[Sysetm.Serializable]	클래스, 구조체도 직렬화에 포함시킨다.
[System.NonSerialized]	직렬화 대상에서 제외한다.
[FormerlySerialiazedAs("이전 이름")]	이전 변수 이름에 저장된 값을 새 변수로 옮긴 채로 직렬화한다.
[HideInInspector]	직렬화 대상인 것을 인스펙터에서만 숨긴다.
[SerializedReference]	클래스도 직렬화 대상에 포함시킨다.

한 번 예시를 보자.

[SerializeField]

우선, 이런 스크립트를 작성했다.

간단하게 public 변수 하나, private 변수 하나를 넣었다.

이 스크립트를 게임오브젝트에 넣고, 인스펙터를 보면,

public 변수만 나오는 모습

이렇게 기본적으로 직렬화가 되는 public 변수만 나온다.

이제 private 앞에 [SerializeField]를 붙여보자.

private 변수를 직렬화에 포함시켰다.

이제 다시 인스펙터를 보면,

private 변수도 인스펙터에 나오는 모습

private 변수였던 thisIsPrivate도 직렬화에 포함되어 인스펙터에 나오게 된다.

이제 클래스도 한번 직렬화에 포함시켜보자.

[System.Serializable], [SerializeReference]

우선, 간단하게 클래스를 만들고 생성해보았다.

이렇게 하고 인스펙터를 보면,

변화가 없다.

아무런 변화가 없다.

이제 이것을 클래스에는 [System.Serializable], 인스턴스에는 [SerializeReference]를 붙여보겠다.

이제 다시 인스펙터를 보면,

생성한 tc 인스턴스가 나타난 모습

인스턴스가 인스펙터에 나타나게 되었다.

그렇다면, 클래스 안에 있던 private 변수에 [SerializeField]를 붙이면 어떻게 될까?

private 멤버 변수까지 잘 나오는 모습

역시 직렬화에 포함되어 인스펙터에 나오게 된다.

그렇다면, 인스턴스 앞에 [SerializeReference]가 아닌 [SerializeField]가 붙는다면 어떻게 될까?

똑같이 나오는 모습

잘 나온다.

그렇다면 두 키워드(Reference, Field)의 차이는 뭘까?

[SerializeReference]와 [SerializeField]의 차이

이 둘은 단순한 클래스 구조에서는 같은 역할이지만, 상속이 들어가면 얘기가 달라진다.

[System.Serializable]
public class AttackData
{
    public int damage = 10;
}

[System.Serializable]
public class AreaAttackData : AttackData
{
    public float radius = 3;
}

[SerializeField]
private AttackData attack1 = new AreaAttackData();
[SerializeReference]
private AttackData attack2 = new AreaAttackData();

이렇게 상속을 한번 거친 인스턴스 두 개가 있다고 해보자.

그리고 그 인스턴스들은 부모 클래스로 선언되었지만 내용은 자식 클래스이다.

이 때, 직렬화에 포함되는 범위가 달라진다.

[SerializeField]는 인스턴스를 AttackData(선언된 형식)로 저장하는 반면,
[SerializeReference]는 인스턴스를 AreaAttackData(실제로 생성된 클래스)로 저장한다.

이런 차이가 있어 클래스를 직렬화를 하려고 할 때에는 구조가 어떻게 되는지 잘 보고 사용해야 한다.

직접 직렬화하기

이렇게 유니티에게 직렬화를 맡기지 않고, 직접 할 수도 있다.

유니티의 JsonUtility를 이용하면 된다.

// 객체 데이터 → JSON 문자열
string json = JsonUtility.ToJson(data, true);

// JSON 문자열 → 새 데이터 객체
LabSaveData loaded = JsonUtility.FromJson<LabSaveData>(json);

위 코드에서 객체를 json 문자열로 변환하는 과정이 직렬화,
그걸 다시 객체 데이터로 변환하는 과정이 직렬화의 반대라고 해서 '역직렬화' 이다.

유니티는 직렬화해서 저장하고, 불러올 때 역직렬화를 통해 불러온다.

위 코드는 그걸 수동으로 한 것이다.

짧은 생각

드디어 에셋 파일들에 있던 요상한 문구들의 정체를 알게 되었다.

더불어 '직렬화' 에 대한 개념을 확실히 알고 가서, 실제로 쓰게 될 때 제대로 사용할 수 있을 것 같다.

[유니티 공부 기록] #1 - 프리팹 (Prefab)

코드짜는농부 — Mon, 19 Oct 2026 23:18:29 +0900

유니티에서 프리팹(Prefab)은 게임 오브젝트를 재사용 가능한 에셋으로 만들어주는 기능이다.

그동안은 여기까지만 알고있었다.

이번에는 프리팹에 대해 더 공부하면서 알게된 것을 적어보고자 한다.

프리팹과 인스턴스

프리팹을 생성하는 과정은 간단하다. 하이어라키에 있는 게임 오브젝트를 작업 창에 끌어다 놓으면 된다.

그리고, 이렇게 생성한 프리팹을 다시 하이어라키로 끌어다 놓아 배치할 수 있다.

여기에서 개념을 새롭게 알았다.

직접 씬 하이어라키에 배치한 프리팹을 프리팹 인스턴스(Instance) 라고 한다.

그리고 이 인스턴스는 실제 프리팹과 구분되는 점이 있다.

인스턴스를 수정하면, 인스펙터 상에 Overrides 라는 변경 사항들이 수정한 것들에 대해 생긴다.

씬에 배치된 프리팹(인스턴스)에 Overrides가 생기는 모습

나는 그동안 이걸 '저장 안 된 프리팹' 이라고 생각하고 저장 안 된 수정사항을 보여주는 것인줄 알았다.

근데 이건 반은 맞고 반은 틀렸다.

하이어라키 상에 배치한 프리팹, 즉, 인스턴스를 수정하면 프리팹을 수정한 것이 아니고, 인스턴스를 수정한 것이다.

그리고 Overrides는 '인스턴스에서 수정한거 원본에도 똑같이 적용할까?' 라고 물어보는 편의 기능인 것이다.

이 사실을 알고 나니 '프리팹을 수정했는데 왜 에디터 끌 때 저장하겠냐고 안물어보지?' 라고 생각했던 것에 답을 할 수 있게 되었다.

프리팹을 수정한 것이 아니고, 씬에 배치된 프리팹 인스턴스를 수정했으니 씬을 저장했으면 당연히 잘 저장된 것이기 때문이다.

그동안 프리팹 인스턴스를 수정할 때 마다 Overrides를 모두 Apply하고 꼼꼼하다고 뿌듯해했던 나 자신을 반성하게 되었다...

~~프리팹 바꾼거 날아갔나? 하고 에디터 다시 켜본 나... 참 뭐라 할 말이 없다.~~

프리팹 배리언트

프리팹을 사용하다 보면 프리팹은 하나인데 값을 살짝 바꿔서 하나 더 만들고 싶을 때가 있다.

그럴 때에는 프리팹을 복제해서 하나 더 만들고는 했다.

하지만, 이번에 그러지 않고도 쉽게 하는 방법을 배웠다.

바로 프리팹 배리언트(Variant)이다.

이 기능은 한 프리팹을 부모로 삼아 여러 개의 자식 프리팹을 만들 수 있게 해준다.

배리언트로 생성한 자식 프리팹은 왼쪽에 무늬가 생긴다.

이렇게 생성한 자식 프리팹에 입력된 값은 자식 프리팹에만 적용된다.

그리고 이것도 똑같이 씬에 배치해 프리팹으로 사용할 수 있다.

하지만 이렇게만 된다면 프리팹 복제랑 별다를게 없다.

여기서 중요한건, 부모가 되는 프리팹 하나만 수정하면 배리언트로 생성한 모든 것들에 알아서 적용된다는 것이다.

단, 부모 프리팹에서 수정한 값이 적용되려면 자식 프리팹에서 수정되지 않은 상태 (부모 프리팹 값을 건드리지 않은 상태) 여야

다.

부모 프리팹에 생긴 변경사항이 자식 프리팹에도 반영되는 모습

짧은 생각

인스턴스 개념을 진작 알았더라면... 한 씬에서 프리팹을 바꿔놓고 다른 씬에서 왜 바뀌었는지 몰라서 디버깅하는 불상사는 없었을 것이다...
배리언트는 적들이 나오다가 가끔씩 변이된 적이 나온다거나, 아이템 등급을 나누거나 할 때 유용할 것 같다.

[유니티] 실시간 그래픽스 / 비주얼 연출 #4 - 셰이더 만들기 (3)

코드짜는농부 — Fri, 25 Sep 2026 18:25:18 +0900

이번에 해볼 것은 두 가지이다.

물체 테두리를 발광시켜서 강조하는 효과 만들기
물체가 사라지는 효과(디졸브, Dissolve) 만들기

우선 1번부터 해보자.

이번 편은 저번 바다 보다는 단순할 것이다.

무작정 만들어보기 1 : 빛나는 물체 테두리

만들기 전에, 하나 알아갈 것이 있다.

프레넬(Fresnel) 효과

프레넬 효과는 바라보는 각도에 따라 물체의 반사량이 달라지는 현상을 설명한 것이다.

이 효과에 따르면, 정면을 바라볼 때 가장자리의 반사량이 정면보다 훨씬 높아서 밝고 강하게 반사광이 보인다고 한다.

우리는 이것을 이용해 테두리 발광 효과를 만들어 볼 것이다.

변수 생성

Rim Color는 원하는 테두리 색, 나머지 Float형 변수들은 차례로 2, 4의 기본값으로 해주자.

셰이더 그래프 작업

다행히도, 유니티에서 프레넬 효과 노드를 제공해준다. 여기의 Power에 생성한 Rim Power를 연결해준다.

그 후, Rim Color에 Rim Strength를 곱해 조색해주고, 그걸 프레넬 효과 노드와 또 곱한다.

이걸 마스터 스택의 Fragment → Emission 값에 넣어주면 된다.

역시 머터리얼 생성해서 셰이더 그래프 적용하고, 물체에 머터리얼을 넣어주면,

발광 테두리가 추가된 구체

잘 발광하는 것을 볼 수 있다.

여기서 짚고 넘어갈 것은, 프레넬 효과가 관찰자 기준에서의 효과이기 때문에 카메라를 움직여도 카메라에서 보이는 테두리에 발광 테두리가 생긴다는 것이다.

이제 이 물체를 사라지게 할 차례이다.

무작정 만들어보기 2 : 디졸브(Dissolve) 효과

우리가 만들 사라지기 효과는, 게임에서 한 번 쯤 봤을 연출이다.

표면이 서서히 무작위로 사라지면서 결국 없어지는 것이다.

스포 섞인 예시를 들자면,

이런 연출이다.

사전 설정 / 변수 생성

그래프 설정을 바꿀 것이 있다.

Alpha Clipping 옵션을 켜주면 된다.

이 옵션은 들어온 값에 따라 알파 값(투명도)를 조절해주는 역할을 한다.

변수도 만들어주자.

변수명	자료형	기본값	역할
Base Color	Color	원하는 색	물체의 기본 색을 정한다.
Dissolve Amount	Float(0~1 슬라이더)	0	물체가 사라지는 정도를 결정한다. (0 : 존재, 1 : 소멸)
Noise Scale	Float(1~30 슬라이더)	8	사라지는 덩어리의 크기를 결정한다.
Edge Width	Float(0.01~0.2 슬라이더)	0.05	사라지는 덩어리의 테두리 크기를 결정한다.
Edge Color	Color (HDR)	원하는 색	사라지는 덩어리의 테두리 색을 결정한다.
Edge Strength	Float(0~10 슬라이더)	3	사라지는 덩어리의 테두리 밝기를 결정한다.

셰이더 그래프 작업

간단하게 표면을 읽어와서 노이즈를 적용해주자.

노이즈의 Scale은 생성해둔 Noise Scale을 넣으면 된다.

이 노이즈의 결과값을 Alpha에, Alpha Clip Threshold에는 Dissolve Amount를 넣어준다.

이후 머터리얼에서 Dissolve Amount 값을 조정해주면 올라갈수록 물체가 사라지는 것이 보일 것이다.

Dissolve Amount가 0이면 꽉 차고, 1이면 없어진다.

이제 테두리에 발광 효과를 적용해보자.

Step 두개를 사용한다.

모두 노이즈 값을 In으로 사용하고, 하나는 Dissolve Amount, 하나는 Dissolve Amount와 Edge Width를 합친 것을 Edge값으로 받는다.

이후 두 값을 빼주어 사라지는 덩어리의 테두리만 추출해낸다.

이제 테두리 색을 조색하고, 그 색을 위에서 테두리만 추출한것과 곱해 테두리에 색을 입힌다.

이후 만들어뒀던 빛나는 테두리 효과 결과값과 더한 뒤, Emission에 연결해주면 된다.

잘 사라지는 모습

그러면 이렇게 자연스럽게 사라지는 것을 확인할 수 있다.

일일이 수치를 조정해가면서 봐도 되지만, 코드로 Dissolve Amount를 조정하게 하면 더 실감이 날 것이다.

아래에 AI가 간단하게 짜준 코드를 첨부하겠다.

using System.Collections;
using UnityEngine;

public class DissolveController : MonoBehaviour
{
    [SerializeField] private Renderer targetRenderer;
    [SerializeField] private float duration = 1.5f;

    private Material runtimeMaterial;
    private static readonly int DissolveAmount =
        Shader.PropertyToID("_Dissolve_Amount");

    private void Awake()
    {
        runtimeMaterial = targetRenderer.material;
    }

    private void Start()
    {
        PlayDissolve();
    }

    public void PlayDissolve()
    {
        StopAllCoroutines();
        StartCoroutine(DissolveRoutine());
    }

    private IEnumerator DissolveRoutine()
    {
        float elapsed = 0f;

        while (elapsed < duration)
        {
            elapsed += Time.deltaTime;
            float amount = Mathf.Clamp01(elapsed / duration);
            runtimeMaterial.SetFloat(DissolveAmount, amount);
            yield return null;
        }

        runtimeMaterial.SetFloat(DissolveAmount, 1f);
    }
}

사라지는 효과까지 모두 만들어보았다.

실시간 그래픽스의 첫걸음이지만, 게임에서 봤던 연출들을 직접 만들어봐서 그런지 재미있게 할 수 있었다.

[유니티] 실시간 그래픽스 / 비주얼 연출 #3 - 셰이더 만들기 (2)

코드짜는농부 — Wed, 23 Sep 2026 20:23:58 +0900

이번에는 조금 더 딥하게 들어가서, 게임에 나오는 바다를 만들어 본다.

AAA게임 급의 고급진 물은 아니고, 진짜 물처럼만 보이게끔 할 것이다.

최종 결과물은 이렇게 될 것이다.

사전 준비

세 가지가 필요하다.

Lit 셰이더 그래프
노멀 맵(Normal Map) 파일
ProBuilder로 만든 Plane

노멀 맵 (Normal Map)

노멀 맵은 오브젝트에서 폴리곤 수를 늘리지 않고 깊이나 질감을 표현하는데 쓰이는 이미지 파일이다.

위 사진처럼 푸른 색 계열로 표현된 이미지가 노멀 맵이다.

이것을 이미지에 적용시키면 평면적 이미지라도 빛 반사 같이 상호작용이 가능한 자연 요소들을 깊이감을 반영해 받는다.

이번 바다 구현을 위한 노멀맵은 아래 링크에서 받았다.

Ocean Normal Map Seamless PBR Water Texture

Layered ocean normal generator with long swells, secondary chop, and foam-height masks.

proctexture.com

여기에서 Zip파일을 받은 후, normal이라고 이름붙은 파일만 사용할 것이다.

ProBuilder Plane 만들기

일반 Plane 오브젝트를 써도 되지만, 더 자연스러운 연출을 위해 사용한다.

왜 더 자연스럽냐 하면, ProBuilder로 만든 Plane은 폴리곤 수를 조정할 수 있어서 더 자연스러운 파도 굴곡을 줄 수 있기 때문이다.

패키지 매니저에서 설치 가능하고, 설치 되면

상단 바의 Tools에서 위 사진과 같은 방법으로 Plane을 생성할 수 있다.

초기 설정은 가로 세로 크기 10에, Width Cut / Height Cut은 30으로 설정해준다.

무작정 만들어보기 1 : 기본 파도 만들기

구현할 파도를 두 가지로 분류할 수 있다.

Plane이 직접 구부러지며 표현되는 큰 파도
그 안에서 노멀 맵이 움직이며 표현되는 작은 파도

우리는 작은 파도 먼저 구현해본다.

변수 생성

필요한 변수들을 만들어준다.

변수명	자료형	기본값	용도
Water Color	Color	원하는 물 색	물의 색을 결정한다.
Normal A	Texture 2D	준비한 노멀 맵 파일	노멀 맵을 저장한다.
Normal B	Texture 2D	준비한 노멀 맵 파일	노멀 맵을 저장한다.
Normal Strength	Float	0.6	노멀 맵이 표현되는 정도를 결정한다.
Flow Speed A	Vector 2	0.05, 0.02	A 노멀 맵이 움직이는 속도 (파도 A의 속도)를 결정한다.
Flow Speed B	Vector 2	-0.03, 0.04	B 노멀 맵이 움직이는 속도 (파도 B의 속도)를 결정한다.
Wave Height	Float	0.1	큰 파도의 높이를 결정한다.
Wave Frequency	Float	1	큰 파도가 얼마나 자주 칠지를 결정한다.
Wave Speed	Float	1	큰 파도의 속도를 결정한다.

작은 파도 만들기

우선 어떻게 구현할지를 생각해보자.

물체의 표면을 받아와서
모두 노멀 맵 파일로 덮은 뒤
그 노멀 맵을 움직이게 해서
물체의 Normal 속성으로 넣어준다.

이렇게 할 수 있다.

이것을 노드로 변환하면,

UV로 표면을 받아온 뒤
파도가 흐르는 것을 표현하기 위해 Time과 곱한 파도의 속도만큼 Offset을 준 것을 Tiling으로 덮는다.
그리고 그 덮은 것에 준비한 노멀 맵을 적용시킨다.

이렇게 하면, 미리보기가 벌써부터 움직이기 시작하는 것을 볼 수 있다.

이것을 Flow Speed A, Normal A / Flow Speed B, Normal B에 대해 두 번 해주면 된다.

이제 만든 두 개의 노멀 맵들을 섞어준다.

그리고 이것을 세기를 Normal Strength로 조정해준 후, Fragment의 Normal에 연결해준다.

이 때, 변수 이름과 노드 이름이 같아서 헷갈리는 것에 주의하자.

여기까지 하면, 벌써 물이 잔잔하게 흐르기 시작한다.

큰 파도 만들기

이 작업은 Plane을 직접 움직이는 작업이다. 따라서 위치를 직접 조정해줄 필요가 있다.

Plane의 좌표를 받아와서, x, y, z로 나눈다. 여기서 x값만 사용한다.

Plane의 x값은 위치, y값은 높이, z값은 앞/뒤 를 나타낸다. 파도는 시간이 지날수록 '이동' 하기 때문에, 위치 값에 따른 높이 값을 설정해주어야 한다.

그래서 x값을 다루는 것이다.

우선 x값에 파도의 주기를 곱해준다.

이후 시간에 파도의 속도를 곱한것과 서로 더한다.

그리고, 파도를 치게 하기 위해 Sine 함수에 적용해준다.

쉽게 말하면, 우리는 지금

이 형태의 사인 함수를 만든 것이다. X축이 시간과 Plane의 위치를 더한 값이라고 생각하면 된다.

이후, 그 값을 파도의 높이와 곱해서 높이를 구현하고, 이를 Plane의 y값에 더한다.

다시 정리하면, 지금 x값을 조작해서 y축에 적용한 것이다.

수학에 익숙한 사람이라면 아마 x값을 꺼내서 높이에 반영한다고 할 때 부터 감을 잡았을수도 있다. ~~일단 나는 아니었다...~~

이제 이걸 다시 좌표로 합친다.

주의할 점은, 우리가 만든 값은 G, 즉, y값이 된다는 것이다.

나머지는 원래 값을 넣어주면 된다.

이후 Vertex의 Position 값에 넣어주면,

이렇게 일렁이는 파도가 나오게 된다.

이렇게 간단한 파도 구현이 끝났다.

하지만, 이대로 게임에 들어간다면 바다 보다는 일렁이는 파란 무언가로 보일 가능성이 높다.

우리는 이걸 더 '바다' 같이 만들어야 한다.

무작정 만들어보기 2 : 바다를 더 바다답게

우리가 구현할 것은 세 가지가 있다.

바다를 투명하게, 깊이감 구현하기
물체와 부딪히는 경계에는 하얗게 부서지는 거품 연출하기
물 속의 물체는 굴절되어 보이게 하기

우선 깊이감부터 해보자.

깊이감 구현하기

깊이감에 필요한 변수부터 만들어준다.

변수들이 이름 그대로의 역할이라 따로 설명하지는 않겠다.

그리고, 인스펙터의 Graph Settings에서 설정을 바꿔줄 것이 있다.

Surface Type을 Transparent로 해주면 된다.

나머지는 Lit 셰이더 그래프의 기본값을 유지한다.

이제 셰이더 그래프에서 작업해보자.

Screen Position을 따와서, Scene Depth에 연결한다.

이 때, Scene Depth는 Eye로 설정한다.

Eye로 설정하면 카메라에서 바닥까지의 깊이를 반환하게 된다.

Position 노드를 View 설정으로 하여 카메라를 원점으로 하는 좌표를 받아온다.

이 때, 카메라 앞쪽이 보통 z값을 음수로 가지므로 Negate로 양수로 변환한다.

이렇게 한 결과는, 카메라에서 물 표면까지의 좌표이다.

이제 연산한 결과를 빼고, 최댓값을 0으로 설정해준다.

이러면 카메라에서 바닥까지의 깊이 - 카메라에서 물 표면까지의 깊이가 되어 물 표면 ~ 바닥까지의 깊이값을 얻게 된다.

이 때, 바닥이 물보다 높이 있는 이상한 경우(?)를 막기 위해 최댓값을 0으로 설정해준 것이다.

여기까지의 과정을 Depth Gap이라고 부르겠다.

이 Depth Gap을 Deep Distance로 나누고, Saturate로 0~1 사이로 제한하면 깊이에 따른 범위를 나타낼 수 있다.

이 값을 Lerp를 이용해 범위에 맞게 섞어준 뒤, Fragment에 기존 Water Color로 연결되어있던 Base Color에 연결해주면 깊이에 따라 색이 다른 연출을 할 수 있다.

이제 만들어뒀던 투명도를 추가로 Lerp 해주고, Fragment에 Alpha값으로 넣어주면 완성이다.

이렇게 깊이감까지 구현했다.

하얗게 부서지는 연출 구현하기

파도는 어떤 물체와 닿으면 하얗게 부서진다.

이것을 구현해볼 것이다.

변수부터 만들어보자.

여기에서 Foam Cutoff는 거품이 사라지는 경계값이다.

이제 노드를 다뤄보자.

그래프만 보면 무슨 작업인지 감이 올수도 있다.

표면을 움직이는 과정이다.

가로 0.2, 세로 0.1의 속도로 표면이 움직이게 했다.

이제 그 결과값에 노이즈를 섞어준다.

노이즈란, 말 그대로 잡음이다.

현실에서 파도 거품은 그 이유를 설명할 수 없을 정도로 무작위 모양으로 생긴다.

그것을 따라잡고자 의도적으로 잡음을 섞어서 계속 변하는 모양처럼 보이게 하는 것이다.

Simple Noise의 Scale값을 크게 할수록 파도 거품 하나 하나가 작아질 것이다.

이후 Foam Cutoff 변수와 거기에 0.1을 더한 변수를 넣어서 SmoothStep에 반영해 거품의 테두리를 부드럽게 해준다.

다시 위에서 만들었던 Depth Gap 쪽으로 돌아와보자.

거기에 Foam Distance에 따른 SmoothStep을 넣어주고, One Minus를 거치게 해 물체와 바다와의 접촉면에서 1, 멀어질수록 0에 가까워지는 구조를 만든다.

이제 두 개를 곱한 뒤, 지금 Base Color에 연결되어있는 것과 Foam Color를 섞은 것을 Lerp를 이용해 반영해준다.

이후 이것을 새로운 Base Color로 삼아주면, 거품까지 구현이 완료된다.

물체와 닿았던 곳에 거품이 생기는 모습

이제 물 속의 물체를 굴절시킬 차례이다.

굴절

역시 변수부터 만들어보자.

Water Tint는 굴절된 물체에 물 색을 얼마나 섞을 지 결정하는 용도이다.

여기에서는 맨 처음에 작은 파도를 만들 때 썼던 것을 재활용 할 것이다.

Normal Strength를 거친 값을 쪼개준다.

그것을 다시 2차원 벡터로 묶어 반사 정도를 곱해준다.

그리고 좌표를 받아와 역시 2차원 벡터를 만들어주고, 위에서 만든 값과 더한다.

이제 이것을 Scene Color의 UV로 삼아 물 아래 배경을 가져오게 하고, 깊이감을 구현할 때 Shallow Color와 Deep Color를 섞었던 Lerp의 출력값과 섞는다. 대상은 Water Tint이다.

그 후, 그것을 최종 출력 Lerp 노드로 가져가 최종 Base Color에 반영시킨다.

그러면 모든 과정이 끝난다.

진짜 바다같다

이렇게 몰랐을 때는 어려워 보였던 바다까지 구현을 할 수 있게 되었다.

다음에는 물체가 사라지는 연출을 구현해 볼 것이다.

[유니티] 실시간 그래픽스 / 비주얼 연출 #2 - 셰이더 만들기 (1)

코드짜는농부 — Wed, 23 Sep 2026 12:11:26 +0900

이제 직접 셰이더를 만들어 볼 차례이다.

그 전에, 짚고 넘어갈 것이 있다.

Lit / Unlit

URP 셰이더에는 크게 Lit, Unlit이 있다.

간단하게 말하면 Lit은 광원에 영향을 받는 것이고, Unlit은 받지 않는 것이다.

그래서 주로 Lit 셰이더는 빛에 반응하는 재질이나 물 같은 것들을 만들 때 사용하고, Unlit은 평면적인 스타일을 만들 때 사용한다.

이제 만들어보자.

무작정 따라해보기 1 : 색 입히기

간단하게 색을 입혀보자.

Lit 셰이더 그래프를 하나 만들고, 이름은 아무렇게나 정한다.

셰이더 그래프 작업

이제 메인 색을 정하기 위해서, 블랙보드에 Main Color라는 이름의 Color 형 변수를 하나 만들어준다.

+ 버튼을 누르고 Color를 선택하면 만들 수 있다.

이 변수가 만들고싶은 색을 결정하는 변수가 될 것이다.

이제 이 변수의 초기값을 설정해주자.

그래프 인스펙터에서 바꿀 수 있고, 나는 빨간색으로 했다.

이제 이 색을 반영할 차례이다.

Main Color 변수를 드래그 해 그래프 캔버스에 놓으면 변수가 노드로 생긴다.

이 노드를 마스터 스택에 있는 Fragment → Base Color에 연결한다.

이 연결의 의미는, 이 셰이더의 기본 색을 Main Color로 설정하겠다는 의미가 된다.

셰이더 그래프 안에서의 모든 작업이 끝났다!

이제 저장하고 나가자.

적용하기

이 셰이더를 적용해보기 위해서는 머터리얼이 하나 필요하다.

머터리얼을 하나 생성하고, 만들었던 셰이더 그래프를 머터리얼로 끌어다 놓으면 적용된다.

적용된 모습

이렇게 우리가 만들었던 Main Color 변수가 보이면서 적용이 되었다.

내가 앞선 글에서 블랙보드의 변수가 외부와 소통하는 창구가 된다는 말을 여기서 확인할 수 있다.

변수로 설정한 Main Color가 머터리얼에 적용되니 색을 직접 바꿀 수 있는 기능이 되었다.

다른 변수 타입들도 머터리얼에 들어가면 이처럼 값을 바꾸거나, 무언가를 할당할 수 있게 된다. 그래서 '외부와 소통하는 창구' 라고 표현한 것이다.

씬에 구를 하나 생성하고, 머터리얼을 적용해보면 잘 되는 것을 확인할 수 있다.

머터리얼에서 변수 할당 값을 바꾸면 실시간으로 구의 색이 변한다.

실시간으로 색이 변하는 모습

무작정 만들어보기 2 : 픽셀 질감 표현하기

이번에는 물체의 표면을 화질이 낮은 것 처럼 표현해볼 것이다.

Unlit 셰이더 그래프를 만들고, 들어가보자.

셰이더 그래프 작업

다음과 같은 변수들을 만들어준다.

Main Texture는 물체 표면에 나타낼 사진 파일을 의미하고, Cells는 표면을 몇 픽셀로 쪼갤지 결정한다.

Cells의 기본값은 32로 설정해줬다.

우선, 이 픽셀 질감의 구조를 설명해보자면,

표면을 읽어온다.
Cells만큼 곱한 것을 소수점을 버려서 범위 내의 값들을 한 값으로 통일시킨다.
다시 Cells 만큼 나눠서 원래 크기로 돌려놓는다.

이렇게 되면, 해상도가 낮은 것처럼 픽셀로 표현할 수 있다.

이제 노드를 이용한 그래프로 표현해보자.

UV 노드를 만들어 표면을 읽어온다.

그 후, Multiply를 이용해 Cells 만큼 곱한다.

이제 이것을 소수 아래를 버리고, 다시 나눠야 한다.

Floor를 이용해 소수 아래를 버리고, Divide로 나눠준다.

벌써부터 미리보기가 픽셀처럼 나온 것을 알 수 있다.

이것을 아까 만들어둔 Main Texture에 적용하면 끝난다.

미리 보기가 하얀 것은 당연하다. 우리가 Main Texture의 기본값을 설정해주지 않았기 때문이다.

일단 이렇게 저장하고 나가보자.

적용하기

똑같이 머터리얼을 하나 만들고, 셰이더 그래프를 끌어다 놓으면 된다.

그러면 이렇게 이미지를 끌어다 놓을 수 있는 곳과 쪼갤 픽셀 수를 정하는 곳이 생긴다.

여기에 원하는 이미지를 넣으면 된다.

토토로 이미지로 넣어보니 잘 되는 모습을 확인할 수 있다.

무작정 만들어보기 3 : 툰 셰이더

툰 셰이더를 간단히 짚고 가면, 빛이 받는 쪽은 밝게, 아닌 쪽은 어둡게 하고, 그 중간 구간들을 단계를 나눠서 끊기게 만화처럼 표현하는 것이다.

이 원리를 먼저 생각해보자.

빛이 있는 쪽은 밝고, 반대는 어둡다.

이는 표면이 보고있는 방향과 메인 라이트를 향한 방향이 얼마나 일치하는 지를 보면 빛이 있는 쪽과 없는 쪽을 구분할 수 있을 것이다.

이것을 판단하여, 그 중간에 있는 범위들을 단계별로 잘라가면서 그 밝기나 색을 지정하면 저 사진처럼 나올 수 있을 것이다.

한번 실행에 옮겨보자.

셰이더 그래프 작업

우선, 이 변수들을 생성해준다.

Color 변수들은 단계별 색을 나타내고, Float 변수들은 단계를 나타낸다.

단계 변수는 0.2, 0.4, 0.6으로 초기값을 설정해줬다. 이렇게 되면 0~0.2, 0.2~0.4, 0.4~0.6, 0.6~1의 4단계가 생기게 된다.

Color 변수의 초기값은 변수에 맞게 어둡거나 밝게 설정해주면 된다.

우선, 아까 원리로 봤던 것 처럼 표면의 방향과 빛의 방향이 얼마나 일치하는지 계산한다.

벡터의 내적(Dot Product)은 1에 가까울 수록 서로 같은 방향을 지향한다는 의미이다.

이제 이 결과값을 0~1 범위로 제한하고, 그 단계를 나눌 차례이다.

Saturate 노드는 값을 0~1 사이로 제한한다고 했었다.

이것을 이용해 값을 제한하고, Step과 변수들을 이용해 단계를 쪼개준다.

그 다음에 Lerp를 이용해 단계별로 색을 입혀준다. A 부분이 범위 밖, B가 안이라고 생각하면 된다.

Lerp를 차례대로 연결해서 단계별 색을 표현하고, 마지막 Lerp는 마스터 스택의 Base Color로 연결해주면 완성이다.

똑같이 머터리얼을 만들어서 적용하고, 구에 넣어보면 잘 되는 것을 확인할 수 있다.

광원의 방향 변화에 따라 구체도 변화하는 모습

여기서 한가지 의문이 들 수도 있다.

Unlit은 분명히 광원에 영향을 받지 않는데, 이 셰이더는 광원의 방향에 따라 물체도 모습이 바뀐다.

이것은 셰이더 내부에서 빛의 방향과 물체 표면의 방향을 실시간으로 계산하고 있기 때문에 광원에 영향을 받는 것 처럼 보인다.

만약 저 광원의 빛이 너무 약해서 모든 세상이 까맣게 보인다고 가정했을 때,

Lit 셰이더는 빛이 표면에 닿는 것을 반영하여 똑같이 까맣게 보이겠지만,
이 Unlit 툰 셰이더는 방향만 움직여주면 빛이 있는 것처럼 똑같이 보여지는 것이다.

이렇게 기초적인 세 가지 셰이더를 만들어봤다.

다음 글에서는 조금 더 '오...' 할 수 있는 셰이더를 만들어보겠다.

[유니티] 실시간 그래픽스 / 비주얼 연출 #1 - 셰이더

코드짜는농부 — Tue, 22 Sep 2026 17:26:55 +0900

유니티에는 오브젝트가 움직이고 상호작용하는 것 뿐만 아니라, 사물이 어떻게 보일지도 결정할 수 있다.

그리고 이것이 게임의 분위기나 독창적인 특징을 결정하기도 한다.

이를 이용해 사람 눈에 보이는 화면을 구성하는 데에는 요소가 엄청 많지만, 하나씩 차근차근 알아가 보려고 한다.

이번 글은 그 중 셰이더(Shader)에 관한 것이다.

셰이더(Shader)란?

셰이더(Shader)는 '물체를 화면에 어떻게 그릴지 알려주는 규칙'이다.

모양을 바꾸거나, 표면의 모습을 계산해서 그 결과로 다시 표면을 만들거나, 보이거나 보이지 않을 부분을 지정하는 등의 작업을 셰이더가 담당한다.

긴 말 안하고, 바로 만들어보면서 이해해보자.

무작정 만들어보기 전에 : 어떻게 만들어요?

일단 Unity 6을 사용한다. 상세 버전은 크게 상관이 없을 것이다.

유니티는 셰이더를 만들 때, 코드로 작성할수도 있고, 노드들을 조작해 그래프 형식으로도 제작할 수 있다.

우리는 그래프 형식의 '셰이더 그래프' 로 알아볼 것이다.

셰이더 그래프

첫 생성했을 때의 모습

셰이더 그래프를 생성하면, 다음과 같은 화면이 보인다.

구성 요소부터 천천히 살펴보자.

블랙보드

화면의 왼쪽 위에 위치한 작은 창을 '블랙보드' 라고 한다.

변수들을 담는 역할을 한다.

"셰이더 만드는 데 변수도 필요해요?" 라고 할 수 있지만, 자주 쓰는 값이나 다시 재현하기 어려운 값을 저장하거나, 외부와 소통하는 창구로도 작용해서 없어서는 안될 요소이다.

'외부와 소통하는 창구' 가 무슨 의미인지에 대해서는 만들어보면서 더 잘 이해하게 될 것이다.

노드

그래프를 구성하는 핵심 요소이다.

화면 가운데 사각형으로 이루어진 것들이다.

이 노드들을 서로 연결해 계산하고, 덮어쓰는 등 엄청 다양한 작업을 할 수 있다.

특히, 위 사진 상 가운데 있는 것들은 최종적으로 어떻게 출력할지를 결정하는 가장 기본적인 노드들이라서, 마스터 스택 (Master Stack) 이라고도 부른다.

인스펙터

화면 오른쪽 위에 위치한 작은 창을 '인스펙터' 라고 한다.

변수나 노드의 상태를 볼 수 있다.

특히, 변수의 기본값을 초기화할 때 많이 쓴다.

그래프 캔버스

이 모든 것들을 제외한 전체 화면을 '그래프 캔버스' 라고 한다.

기본적인 노드들

그래프는 노드와 노드의 결합으로 이루어지기 때문에, 어떤 노드들을 쓰냐에 따라 결과가 많이 달라진다.

그럼 들어가기 전에, 어떤 노드들이 있는지 간단히 알아보자.

입력 / 좌표용 노드

노드 이름	내부에서 하는 일	실제 역할 / 의도
UV	표면의 2D 좌표를 꺼낸다. 보통 0~1 사이의 범위이다.	이미지를 표면 어디에서 읽을 지 결정한다.
Sample Texture 2D	UV가 가리킨 이미지 색 / 데이터를 읽는다.	UV에 따른 그림 무늬가 나타난다.
Tiling And Offset	새 UV를 만든다. (UV * 반복값(Tiling) + 이동 (Offset))	UV를 반복하거나 무늬를 이동시킨다.
Position	꼭짓점이나 표면의 공간 상 위치를 읽는다.	동일
Normal Vector	표면이 향하는 방향을 읽는다.	빛을 받을 방향을 판정하는 재료이다.
View Direction	표면에서 카메라 쪽 방향을 읽는다.	시점에 따라 달라지는 효과를 만든다.
Time	흐르는 시간을 숫자로 제공한다.	속도 또는 주기를 줄 때 사용한다.

계산 / 마스크용 노드

노드 이름	내부에서 하는 일	실제 역할 / 의도
Multiply / Add	두 값을 곱한다 / 더한다.	동일
Lerp (A, B, T)	T가 0이면 A, 1이면 B, 중간값이면 그에 맞게 섞는다.	무늬를 혼합할 때 사용한다.
Dot Product	내적, 두 방향이 얼마나 같은 방향을 보는지 숫자로 계산한다.	명암을 표현할 때 사용한다.
Step (경계, 값)	값이 경계 미만이면 0, 이상이면 1로 자른다.	끊기는 연출에 사용한다.
SmoothStep(A, B, 값)	A~B의 범위 안에서 0→1로 부드럽게 전환한다.	테두리의 경계를 부드럽게 한다.
Floor	소수 아래를 버린다.	동일
Split	벡터값(x, y, z)를 쪼개거나 색 값(R, G, B)를 쪼갠다.	Combine과 세트로, 특정 값만 바꾼다.
Combine	쪼개진 값을 다시 합친다.	Split과 세트로, 특정 값만 바꾼다.
Clamp	값을 정한 범위 내에 가둔다.	너무 밝거나 음수로 튀는 계산을 제한한다.
Saturate	값을 0~1 사이로 가둔다.	너무 밝거나 음수로 튀는 계산을 제한한다.

이렇게 기본적인 것들이 있지만, 설명만 봐서는 이해가 잘 안된다.

예제를 따라 만들어보면 이게 어떤 역할이고, 어떻게 만들어지는지 이해가 갈 것이다.

무작정 만들어보기 전에 : 어떻게 조작해요?

간단한 조작법과 단축키를 알아보자.

조작법	행동
클릭	선택
드래그	다중 선택
Ctrl + 클릭	추가 선택 / 다중 선택중 해당 요소만 선택 취소
휠	줌 인 / 아웃
Alt + 드래그	시점 이동
빈공간 클릭 + 스페이스 바 OR 우클릭 → Create Node	새로운 노드 생성(검색)
Delete	삭제
Ctrl + Z / Y	Z : 되돌리기 / Y : 재실행
우클릭 → Create Sticky Note	움직일 수 있는 메모장 생성 (코드의 주석같은 느낌)
블랙보드 변수 드래그 → 그래프 캔버스에 내려놓음	변수 배치

이제 실제로 만들어 볼 차례이다.

다음 글에서 기본적인 것 부터 만들어보도록 하겠다.

[후기] BOJ C++, 200일의 에필로그

코드짜는농부 — Thu, 28 May 2026 15:14:05 +0900

군 생활을 하며 지난 200일동안 백준을 하루에 한 문제 이상씩 풀어왔다.

백준이 서비스를 종료한 지금 생각해보면 어떻게 했지 싶다가도, 재미있게 풀었던 기억이 많아서 다시 하라면 다시 할 수 있을 것 같은 마음이 든다.

200일 인증

200일을 달려왔지만 얻은건 백준의 서비스 종료 소식이라서 아쉬운 마음이 있지만, 이것만 얻은 것은 아니다.

긴 시간이라면 긴 시간동안 많은 것을 얻었다.

본격적으로 후기를 작성해보기 전에, 대체 그 200일동안 뭘 했는지 한번 끄적여보려고 한다.

※ 스트릭 기준은 solved.ac로 정했다.

보직 특성상 밤샘도 있고, 불규칙적인 생활을 해서 00시에 초기화되는 스트릭에는 도저히 맞출 수가 없었다.

그래서 06시에 초기화되는 solved.ac 스트릭이 나의 근무 시간이나 군 내 생활 패턴이랑 딱 맞아서 이걸로 스트릭을 유지하기로 결정했던 것이다.

백준 풀이 시작 (25.09.13)

작년 9월 13일부터 백준에 손을 대보기 시작했다.

24년도 초에 잠깐 풀다가, 실버조차 아직은 어렵게 느껴져서 잠깐 접었던 기억이 있어서 이번 기회에 한번 제대로 해보자고 마음 먹었었다.

목적은 코딩 테스트 연습, 코딩 감각 잃지 않기가 주된 것이었다.

물론 갑자기 잘해지거나 그러진 않았다. 여전히 실버 티어의 상위권(1~2)은 아직은 어렵게 느껴졌다.

하지만, 군대에 있으면서 남는게 시간이기 때문에 한 문제를 진득하게 생각할 시간이 많았다.

풀다가 막히면 노트에 그려가면서 해보고, 짜둔 알고리즘을 여러번 바꿔가며 시도했었다.

그러다가 하나 둘 씩 풀리기 시작하니 재미를 느꼈던 것 같다.

이 당시 solved.ac 티어는 브론즈 1이었다.

사실 문제를 풀기 전부터 문제가 있었다.

바로 싸지방에서 코딩을 어떻게 하느냐였다.

키보드는 키가 몇개 잘 안눌리지만 어떻게든 누를 수 있어서 해결됐고, 컴파일러가 문제였다.

VS를 설치하는 건 크롬만 켜도 죽으려고 하는 컴퓨터를 지옥으로 보내버리는 길인걸 알기에 하지 않았다.

그래서, 온라인 컴파일러를 쓰기로 했다.

Codechef 라는 온라인 컴파일러 사이트에서 C++로 코딩을 했다.

근데 이 사이트는 C++ 문법에 진짜 기초적인 예약어(자료형) 말고는 예약어가 등록되어있지 않아서 일일이 다 손으로 쳐야했다.

처음엔 불편했는데, 하다보니 원래 쓰던 예약어가 뭔지 자세히 알 수 있어서 오히려 좋다 였다.

이런 식으로 창을 두개 띄워놓고 코딩했다.

풀이 기록 시작 (25.09.15)

백준을 시작한지 얼마 안돼서, 풀이를 블로그에 남기기 시작했다.

문제를 풀고 다시 안 보는 것이 뭔가 아까워서, 내가 어떻게 생각하고 어떻게 접근해서 풀었는지를 기록으로 남기고 싶었다.

그리고 그 것에 가장 잘 맞는 것이 블로그에 남기는 것이었다.

이때는 아직 이런 풀이 블로그를 쓰는 게 익숙하지 않아 형식이 안정해져있었는데, 좀 쓰다보니 들어갈 내용들(알고리즘 설명, 로직 설명, 접근법 등)만 들어간다는 걸 알아채고 형식을 정해서 그 형식에 맞춰서 깔끔하게 쓰기 시작했다.

그렇게 정신없이 쓰다보니 지금 이 후기를 쓰는 기준(26.05.28) 131개의 풀이 글을 써냈다.

골드 5 달성, 삼성 기출 풀이 시작 (25.10.23)

하루 한 문제씩, 잘 풀릴때는 더 풀면서 블로그를 병행하다보니, 시간도 빨리가고, solved.ac 티어도 빠르게 올랐다.

그리고 무엇보다, 이 쯤부터 실버 티어의 문제는 더 이상 어렵지 않게 되었다.

'이제 골드로 가 볼까' 라고 생각할 즈음에, 지금은 취업한 친한 선배님이 오랜만에 백준 풀이 글을 올린 것을 봤다.

그 문제는 [삼성 기출] 이라고 표시되어있었고, 풀이가 엄청 길고 뭔가 많이 로직적으로 연결이 되어있는 것처럼 보였다.

[BOJ C++] 19236번 - 청소년 상어

[삼성 SW 역량 테스트 기출 문제]백준 19236번 - 청소년 상어문제더보기아기 상어가 성장해 청소년 상어가 되었다.4×4크기의 공간이 있고, 크기가 1×1인 정사각형 칸으로 나누어져 있다. 공간의 각

devfarm.tistory.com

바로 이 문제였다.

이 때를 기준으로 백준을 푸는 마음가짐이 달라졌다.

원래는 그저 내가 풀 수 있는 선에서 연습하기 위해서, 내가 풀 수 있는 선에서 알고리즘 코딩 능력을 연습하기 위해서 그 선의 랜덤한 문제를 풀었다.

그러다보니 어떤 문제를 풀지에 대한 기준도 없고, 문제를 보고 너무 어렵다 싶으면 넘기거나 아예 티어를 낮춰서 문제를 푸는 일도 있었다. (물론 브론즈까지 내려가진 않았다.)

하지만 이제 그러면 안된다는 것을 느꼈다.

백준을 푸는 것은, 내가 풀고 '내가 해냄' 에 중점을 두는 것이 아니고, 내가 공부를 하고 무언가를 알아간다는 것에 중점을 맞춰야 나에게 도움이 극대화된다는 걸 알았다.

전자도 중요하지만, 후자가 이뤄질 때 전자가 자연스레 따라온다는 것을 몰랐었다.

그래서 글을 올렸던 선배를 좇아 삼성 기출 문제를 풀겠다고 마음 먹었다.

하나 둘 풀다보니, 정말 어려웠다. 첫 문제부터 골드 1이었고, 빡센 구현이나 많은 조건 분기, 예외 처리들이 쏟아졌다.

하지만, 이내 해답을 찾았다.

삼성 문제들은 대체로 빡센 구현, 예외처리, 완전 탐색이나 BFS/DFS가 많았다.

그리고 보통 이런 알고리즘은 게임에 무조건 등장하기 마련이다.

이걸 이용해 이런 문제들을 게임처럼 OOP 스럽게 구현해서 풀었다.

문제에서 요구하는 주인공이나 물체, 지형 같은 것들을 클래스로 구현해 객체를 직접 다루도록 진짜 '게임처럼' 했다.

확실히 이렇게 하니 재미는 물론이고, 게임 개발 지식을 탄탄하게 다지는 데에도 한 몫 한 것 같다.

삼성 기출 풀이 완료 (25.12.14)

약 한달 반 만에 백준에 올라온 삼성 문제집을 클리어했다.

정말 뿌듯한 성과였다.

이 쯤의 티어가 골드 3이었고, 이제는 골드 문제도 쉽게 풀 수 있게 되었다.

문제는 플래티넘 문제들이었다. 위에 보이는 플래티넘 문제들은 생각할 것도 많고, 구현량이 어마어마했다.

하지만 풀 시간도 많고 생각할 시간도 많아서 골드 문제보다 오래걸리고 머리아프긴 했지만 결국 풀어낼 수 있었다.

특히 위에서 말했던 청소년 상어 문제를 나도 풀고 나서 더 자신감이랑 탄력이 붙었던 것 같다.

플래티넘 5 달성 (26.03.18)

드디어 나의 새로운 목표였던 플래티넘 5를 달성한 순간이었다.

왜 '새로운 목표' 일까? 라고 한다면...

원래는 플래티넘이 목표가 아니고, 골드가 목표였다.

그래서 골드 5를 달성했을 때 '이쯤이면 되려나? 조금만 더 해볼까?' 라는 생각이 들어서 더 할지 말지 결정을 못하고 있다가, 삼성 기출을 풀기 시작하면서 쭉 오게 되었다.

그러면서 자연스레 목표도 골드가 아닌 플래티넘으로 바뀌었다.

달성 인증

이 때 문제를 정신없이 풀다가 플래티넘 5를 달성한줄도 몰랐다.

그러다가 근무때 알게 되어서 선임 동기 후임 간부님 할 것 없이 붙잡고 방방 뛰었던 기억이 있다.

모두들 나를 응원해주던 분위기여서 짬오바 였지만 다 잘 받아주셨다.. 감사합니다 다들

백준 풀이 200일 달성, 풀이 종료 (26.04.09)

플래티넘을 달성한 뒤로 약 4주 정도를 더 풀어서 200일을 달성했다.

일병 끝나갈 때 쯤 풀기 시작해서 병장을 달았을 때 마무리되었다.

중간에 한 번 확 뛴 건 Class 5를 달성해서 점수를 많이 받아서 그런 것이다.

시간이 정말 빨리 갔다. 물론 백준만 했던건 아니지만, 상병 시즌의 메인 컨텐츠는 백준이었다.

200일동안 많은 것을 알게 되었고, 코딩 감각도 녹슬지 않도록 유지할 수 있었다.

이후 2주도 채 되지 않아 서비스 종료 소식이 들려온 건 아쉽지만, 이걸 안했었다면 더욱 후회했을 것을 알기에 내가 했던게 헛되었다거나 의미가 없어졌다고는 결코 생각하지 않는다.

200일동안 고생했다고 내 자신에게 해주고 싶다.

이렇게 200일동안 백준을 풀었다.

이제 그 200일 동안 알게된 두 가지 큰 것들을 적어보려고 한다.

문제 이해와 최적화는 아예 다른 영역이다

문제를 풀면서, 문제가 이해도 잘 되고, 테스트케이스에 대한 답도 다 잘 나오는데, 시간 초과가 나는 경우가 많았다.

그래서 시간 복잡도를 줄인다거나, 조건 탐색 횟수를 줄이는 등의 최적화 방법을 적용해봐도 시간 초과는 변함이 없었다.

이럴 때에는 어떻게 하지 하다가 어느 날 한 문제의 풀이를 봤는데, 반복 없이 단순 수학 공식으로 끝내는 풀이가 있었다.

"이건 모르면 못풀잖아" 라고 생각했는데, 다시 생각해보면 문제를 잘 뜯어보면 공식이 나올 수 있고, 얼마든지 도출해낼 수 있다.

이처럼 공식으로 끝난다거나, 문제에서 요구하지 않는 조건들을 모두 배제하고 특정 알고리즘을 적용하여 빠르게 끝내버리는 케이스가 종종 있었다.

'그래서 어떻게 하면 더 빠르게 할까?' 라는 접근의 최적화는 단순히 문제를 이해한다고 되는 게 아니고, 문제를 변형해보고 규칙을 찾는 것이 더 중요한 일이라는 것을 깨달았다.

그리고 이건 아마도 현업에서도 적용될 것이라고 생각한다.

내가 게임을 만들 때, 기존에 만들어뒀던 알고리즘을 뜯어고치거나, 시간적으로 버그가 나서 고쳐야할 때가 있었다.

그럴 때에는 이 일이 알고리즘 문제처럼 작용된다. 어떻게하면 더 빠르게 하지, 하면서 백준 문제를 시간적으로 최적화할 때랑 같은 과정을 거친다.

그러니 현업에서도 시간 최적화 문제가 생기면 이런 과정을 거치지 않을까 싶다.

시간 외로, 메모리 초과가 나는 경우도 있었는데, 이건 불필요한 컨테이너를 축소 / 재사용 한다거나, 메모리 값이 더 적은 자료형을 쓴다거나, 정보 저장 형태를 바꿔서 잘 해결할 수 있었다.

디커플링이 중요하다

앞서 삼성 문제를 풀었다고 했을 때, 게임처럼 클래스를 만들어 OOP 스럽게 했다고 했는데, 이 풀이 방식이 전부 한 번에 정답을 뱉는 것은 아니다.

거의 모든 문제는 첫 테스트에서 테스트케이스를 돌렸을 때 이상한 값이 나온다.

오타가 났거나, 단순히 변수를 잘못 사용해서 그런 것이라면 수정하는데 얼마 걸리지 않았다. (눈에 안보여서 삽질하는 경우는 빼고..)

문제는 로직 자체가 잘못되었거나, 단단히 꼬여버렸을 때다.

객체를 만들어놓고 결국 다른걸 다 참조하게 된다거나, 문제 이해를 잘못했거나, 순서가 잘못되었을 경우에 보통 이런 현상이 발생한다.

이렇게 꼬여버린 코드들을 수정하면서 '디커플링'을 신경쓰기 시작했다.

디커플링을 간단하게 설명하면, '상호 의존성'을 낮추는 건데, 여기에서는 무언가를 수정할 때 그것을 담당하는 클래스만 수정하면 되도록 로직 자체를 객체별로 독립시켜놓는 것이라고 할 수 있다.

이걸 신경 쓴 문제가 위에서 말한 청소년 상어 문제와,

[BOJ C++] 19237번 - 어른 상어

[삼성 SW 역량 테스트 기출 문제]백준 19237번 - 어른 상어문제더보기청소년 상어는 더욱 자라 어른 상어가 되었다. 상어가 사는 공간에 더 이상 물고기는 오지 않고 다른 상어들만이 남아있다. 상

devfarm.tistory.com

이 문제이다.

다른 문제도 있지만, 이 두 문제를 하면서 깨달았던 것 같다.

확실히 디커플링 되어있으니 수정하기도 편하고, 디버깅도 편했다. 유지보수성이 올라간 것이다.

에필로그

200일동안 백준을 풀면서 브론즈 1 → 플래티넘 5까지 달성했고, 200문제 이상을 풀어냈다.

군대에서 근무를 서면서도 짬이 날 때 마다 풀었고, 휴가를 나와서도 소홀히 하지 않았다.

입대 이후에 훈련을 받으면서 자칫 잃었을 수 있는 감각을 다시 일깨워준 기간이었다.

그러면서 기억에 남는 문제들이 몇 가지 있다.

기억에 남는 문제들

[BOJ C++] 25585번 - 86 ─에이티식스─ 1

문제산마그놀리아 공화국은 '레기온'이라는 인공지능 무인 병기들과 전쟁 중이다. 공화국은 레기온에 대항할 수단으로 '저거노트'라는 보행 병기를 개발했다. 공화국 군인들은 이 저거노트에

devfarm.tistory.com

한창 재밌게 보던 '에이티식스' 라는 애니메이션을 랜덤 문제로 맞딱뜨렸다.

'이것도 문제가 있네' 하면서 풀었는데, 풀기 시작했던 초반에 만난 골드 티어 문제라서 조금 애를 먹었던 기억이 있다.

[BOJ C++] 1131번 - 숫자

문제자연수 N이 주어졌을 때, N의 각 자리수를 K제곱 한 후에 그 합을 구하는 함수를 S_K(N)이라고 하자. 예를 들어, S2(65) = 62 + 52 = 61이다.이제 다음과 같은 수열을 하나 만들어보자. N, S_K(N), S_K(S_K(N

devfarm.tistory.com

이 문제는 DP를 이용하는 플래티넘 티어의 문제이다.

이 이전에 골드 티어 DP 문제를 두 개 진짜 고생하면서 풀었는데, 그러면서 DP에 대해 이해하고, '그럼 이렇게 되는건가?' 하는 생각이 들었다. 다시 말해, DP를 깨달은 순간이었다.

그래서 자신감이 붙어 홀린듯이 DP 플래티넘 티어 문제를 찾아 깨달은 개념을 이용해봤는데, 바로 풀려버렸다.

그 때 쾌감과 기쁨은 진짜 이루 말할 수 없었다. 그때도 방방 뛰었다. 대신 후임만 잡았다.

전에 DP가 나오면 좌절부터 하고 뭐가 뭐지 하면서 진짜 어거지로 풀었는데, 이 이후로 DP는 무섭지 않게 되었다.

[BOJ C++] 3954번 - Brainf**k 인터프리터

[삼성 A형 기출 문제]백준 3954번 - Brainf**k 인터프리터문제더보기Brainf**k 프로그램이 주어졌을 때, 이 프로그램이 끝나는지, 무한 루프에 빠지는지 알아내는 프로그램을 작성하시오.무한 루프란,

devfarm.tistory.com

이 문제는 난해한 코딩언어인 Brainf**k(그거 맞음) 의 인터프리터를 제작하라는 문제였다.

단순히 생각해보면 뭐가 어렵지 싶은 문제인데, 무한 루프를 감지하는 지점이 진짜 어려웠다.

그러다 문제에서 준 제한을 두 번 돌리는 방법으로 접근하니 풀렸다. 50000000번을 두 번 돌려 무한루프를 보는 것이다.

'문제에서 준 제한을 역이용할 수도 있구나' 라는 생각과 '저걸 왜 제한사항이라고 생각했지' 라는 생각이 들어 신기하면서도 충격적인 문제로 기억에 남았다.

[BOJ C++] 5373번 - 큐빙

[삼성 SW 역량 테스트 기출 문제]백준 5373번 - 큐빙문제더보기루빅스 큐브는 삼차원 퍼즐이다. 보통 루빅스 큐브는 3×3×3개의 작은 정육면체로 이루어져 있다. 퍼즐을 풀려면 각 면에 있는 아홉

devfarm.tistory.com

역대급으로 구현량이 많았던 문제였다.

머릿속으로 큐브를 하나 준비해서 직접 상상으로 돌려가며 규칙을 찾고, 값 설정하고... 푸는데만 이틀이 걸렸다. (중간에 실버 문제를 풀어서 스트릭을 유지했다.)

지금 다시 생각해봐도 근무서고 생각하고 근무서고 상상큐브 돌려보고 했던게 진짜 머리아프다.

[BOJ C++] 15685번 - 드래곤 커브

[삼성 SW 역량 테스트 기출 문제]백준 15685번 - 드래곤 커브 문제더보기드래곤 커브는 다음과 같은 세 가지 속성으로 이루어져 있으며, 이차원 좌표 평면 위에서 정의된다. 좌표 평면의 x축은 →

devfarm.tistory.com

이 문제는 방대한 숫자가 나오는 문제였다.

몇 번만 반복해도 겉잡을 수 없이 커져서 측정이 정말 어려워보였다.

문제를 딱 보고나서 '와 이걸 어떻게 하지...' 하고 있었는데, 한 3번쯤 손으로 반복해보니 규칙이 보였다.

시계방향으로 돌지만 좌표는 반시계방향으로 간다는 식의 규칙을 이용해 간단한 코드를 작성하니 바로 풀렸다.

이것도 쾌감과 신기함이 몰려와서 기억에 남는다.

200일 이후

이후인 현재는 게임 기획과 프로젝트 준비를 병행하고있다.

게임 프로그래밍 패턴도 공부했는데, 백준을 풀었던 것이 여기 나오는 코드를 이해하는데 한 몫 한 것 같다.

그리고, 백준이 장례식에서 하면 안되는 행동인 '부활'을 해버려서, 백준부활절 전까지는 여기에 집중하다가 차츰 백준을 다시 풀어볼 계획이다.

플래티넘 풀고 탈진한 나