이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
유니티 셰이더는 처음에 Shader Graph로 시작했습니다. 노드를 연결하며 빛이 어떻게 반사되는지, 텍스처가 어떻게 섞이는지 눈으로 확인하니 개념이 빠르게 잡혔습니다. 어느 정도 익숙해진 뒤 HLSL 기초 문법으로 넘어가서 Shader Graph가 내부에서 어떤 코드를 생성하는지 비교해봤습니다. 직접 코드를 짜면서 버텍스 셰이더와 프래그먼트 셰이더의 역할 차이를 체감했습니다. 커스텀 물 셰이더를 만들 때 Shader Graph로는 표현이 안 되는 부분을 Custom Function 노드로 HLSL 조각을 끼워넣어 해결했습니다. 이 과정이 셰이더를 도구가 아닌 내가 제어할 수 있는 영역으로 인식하게 해줬습니다.
Shader Graph에서 시각 효과를 추가하다가 GPU 부하가 급격히 올라간 경험이 있습니다. 노드를 연결할수록 효과가 풍부해졌는데, 실제 기기에서 돌려보니 프레임이 크게 떨어지는 문제가 생겼습니다. 에디터 미리보기와 실기기 성능 차이를 고려하지 않은 게 원인이었습니다.
쉐이더 복잡도와 성능 예산을 함께 보지 않으면 아무리 좋아 보여도 쓸 수 없다는 걸 그때 배웠습니다.
그 경험 이후로 쉐이더 작업 시 GPU 비용을 중간중간 실기기에서 확인하는 습관이 생겼습니다. 보이는 품질과 실행 가능한 품질은 다르다는 걸 그때 배웠고, 타깃 기기 스펙을 먼저 확인하고 쉐이더 복잡도 상한선을 잡는 방식을 씁니다. 타깃 기기 기준의 쉐이더 복잡도 상한선을 먼저 잡는 습관이 그 경험에서 생겼습니다.
컴퓨터 그래픽스 수업에서 배운 벡터 연산과 좌표 변환 개념이 쉐이더 코드를 이해하는 데 직접 연결됐습니다. 처음엔 HLSL 코드가 추상적으로 보였는데, 수업에서 본 행렬 변환 수식이 버텍스 쉐이더에서 쓰이는 MVP 행렬과 같은 것이라는 걸 알게 됐습니다.
수학 개념이 실제 코드로 구현된 것을 보면서 추상적 공식이 구체적인 의미를 가지게 됐습니다.
그 이후로 새 쉐이더 기법을 배울 때 수식이 어떤 변환을 표현하는지를 먼저 이해하는 순서를 씁니다. 원리를 이해하고 구현하면 오류가 생겼을 때 어디를 수정해야 할지 알게 된다는 걸 그 경험에서 배웠습니다. 수학 기초가 그래픽스 응용의 출발점이라는 것도 그때 실감했고, 이후로 이론과 실습을 함께 학습하는 방식을 씁니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 111퍼센트 게임 아트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.