프로그래밍/Unity Engine

[쿠고랑 AI 일일 개발일지 #01] Unity 6 UI Toolkit 실측 픽셀 대조: USS cubic-bezier 미지원 결함 해결기

kugorang 2026. 11. 8. 18:30

TL;DR — 3줄 핵심 요약

• 문제: 컴퓨터 화면에 버튼을 그릴 때, 원래 계획했던 점(픽셀)의 위치와 실제 게임 화면에 그려진 점의 위치가 1~2개씩 어긋나는 문제가 생겼습니다.

• 원인과 기술: 이미지를 9개 조각으로 나누어 늘리는 방법(9-슬라이스)과 버튼 움직임 속도 규칙(cubic-bezier)이 유니티 6 엔진에서 제대로 실행되지 않았습니다. 화면을 사진 찍어 점의 개수를 자로 재듯 세어보며 문제를 확인했습니다.

• 해결과 인계: 작동하지 않는 규칙을 유니티가 읽을 수 있는 다른 규칙으로 바꾸고, 이 사실을 다음 작업자를 위해 노션(Notion) 공용 메모리에 기록했습니다.

1인 인디게임 개발사 쿠고랑에서 만들고 있는 3D 큐브 스도쿠 게임 'Facet'의 화면을 유니티 6 엔진으로 옮기던 2026년 7월 5일의 실제 개발 기록입니다.

이날의 목표는 게임 화면이 처음 디자인했던 화면과 완전히 똑같은지 눈짐작이 아니라 정확한 숫자로 확인하는 것이었습니다.

1. 화면을 만드는 기본 단위: 픽셀(Pixel)이란 무엇일까요?

컴퓨터나 스마트폰 화면을 돋보기로 아주 크게 확대해보면, 화면 전체가 바둑판처럼 작은 네모 점들로 가득 차 있습니다.

이 네모 점 하나를 영어로 픽셀(Pixel)이라고 부릅니다. 우리말로는 '화소'라고 부르기도 합니다.

가로로 100개의 점, 세로로 50개의 점이 모이면 가로 100픽셀, 세로 50픽셀 크기의 네모 상자가 만들어집니다.

게임 개발자가 화면에 버튼이나 점수판을 배치할 때는 모든 위치와 크기를 이 점(픽셀)의 개수로 지정합니다.

화면을 구성하는 기초 개념: 픽셀(Pixel)과 9-슬라이스(9-Slice)
그림 1: 컴퓨터 화면을 이루는 기본 점(픽셀)과 둥근 모서리를 지키는 9-슬라이스 원리

2. 9-슬라이스(9-Slice)의 원리와 유니티 6에서 일어난 문제

네모난 버튼을 만들 때, 네 귀퉁이 모서리가 둥근 모양인 경우가 많습니다.

이 버튼을 가로로 길게 잡아당겨 늘리면, 둥근 모서리 모양도 같이 옆으로 늘어나서 타원형으로 찌그러집니다.

둥근 모서리가 찌그러지지 않게 만들기 위해 네모난 이미지를 가로 3칸, 세로 3칸으로 잘라 총 9개의 조각으로 나누는 방법을 씁니다. 이것을 9-슬라이스(9-Slice)라고 부릅니다.

4개의 모서리 조각은 크기를 그대로 고정해 두고, 가운데 영역과 상하좌우 테두리 조각만 길게 늘려 크기를 조절합니다.

실제로 발생한 문제: 유니티 6(게임 제작 프로그램)에서 모서리 조각을 너무 바짝 잘랐더니, 버튼 바깥쪽에 자연스럽게 퍼져야 할 그림자가 잘려 나가고 테두리 안쪽으로 파고드는 현상이 일어났습니다. 원래 계획했던 그림자 위치와 실제 화면의 점(픽셀) 위치가 달랐던 것입니다.

3. 이날의 화면 제작 순서: 3단계 파이프라인

화면을 만들 때는 세 단계를 거쳐 진행했습니다.

1단계 (기획): 대화(챗)를 통해 화면에 어떤 버튼, 어떤 글자, 어떤 점수판이 들어갈지 목록을 정합니다.

2단계 (디자인 시안): 웹 브라우저 프로그램(HTML)을 사용해 버튼의 가로세로 점(픽셀) 크기를 정확하게 정해 둡니다.

3단계 (게임 구현): 미리 만든 디자인의 점(픽셀) 값을 게임 제작 프로그램(유니티 6 UI Toolkit)에 숫자로 그대로 입력합니다.

쿠고랑 Facet UI 개발 파이프라인 3단계: 챗 기획 → standalone HTML 시안 → Unity 6 UI Toolkit 구현
그림 2: 기획부터 게임 엔진 코드 구현까지 이어지는 3단계 작업 순서

4. 실측 픽셀 대조: 눈짐작 대신 점의 개수를 직접 세는 방법

화면을 보고 "조금 이상한 것 같다"라고 눈으로만 어림잡으면 무엇이 잘못되었는지 정확히 고칠 수 없습니다.

그래서 화면을 사진으로 찍은 뒤, 그림을 크게 확대해서 점(픽셀)의 개수를 하나하나 직접 세었습니다. 이것을 실측 픽셀 대조라고 합니다.

1) 2단계 디자인 시안에서 버튼의 가로 크기(예: 120개 점)와 세로 크기(예: 60개 점)를 숫자로 확인합니다.

2) 유니티 게임 화면에 실제로 나타난 버튼을 컴퓨터 분석 도구(UI Toolkit Debugger)로 측정합니다.

3) 두 숫자를 표에 나란히 적어서 몇 개의 점이 차이 나는지 뺍니다.

이렇게 측정했더니 "테두리 모양은 맞는데 그림자가 1픽셀 안쪽으로 밀려났다"는 구체적인 사실을 숫자로 확인할 수 있었습니다.

UI Toolkit 실측 픽셀 대조 4단계: 요소 선택 → Layout·Computed Style 확인 → 확대 검사 → 값 반영
그림 3: 디자인과 실제 게임 화면의 점(픽셀)을 비교하는 4단계 검증 과정

5. USS cubic-bezier: 오류 표시도 없이 무시되는 프로그램 결함

게임에서 버튼을 누르면 버튼이 부드럽게 커지거나 작아지는 움직임이 필요합니다.

움직임이 시작할 때 천천히 움직이다가 중간에 빨라지는 것처럼, 시간에 따른 움직임 속도를 정해주는 수학 공식 이름 중 하나가 cubic-bezier(큐빅 베지어)입니다.

개발자가 이 공식 이름을 유니티 프로그램의 스타일 규칙(USS)에 적어 넣었습니다.

결함의 내용: 유니티 6 프로그램은 이 글자를 읽고 움직임을 만들어내지 못했습니다. 그런데 "이 글자를 지원하지 않습니다"라는 에러 경고 창을 띄우지 않고, 마치 아무 글자도 적히지 않은 것처럼 조용히 무시해 버렸습니다.

해결 방법: 유니티가 읽을 수 있는 다른 기본 속도 규칙(linear, ease-in, ease-out)으로 글자를 바꾸어 적거나, C# 프로그래밍 코드로 직접 속도를 계산해서 움직이도록 수정했습니다.

6. 노션(Notion) 공용 메모리에 기록하고 인계하기

혼자서 개발하거나 여러 AI 도구를 함께 사용할 때, 오늘 발견한 버그와 해결법을 적어두지 않으면 며칠 뒤에 같은 실수를 또 하게 됩니다.

그래서 노션의 '공용 메모리' 공간에 오늘 확인한 사실을 다음 순서로 정리했습니다.

1) 확실하게 확인한 사실: 유니티 6에서 9-슬라이스 경계를 너무 촘촘하게 잡으면 그림자가 잘린다는 점, cubic-bezier 글자는 지원되지 않는다는 점.

2) 아직 시도해보지 않은 내용: 모서리 여백을 넓혀서 그림자가 완전히 나오는지 다시 측정하기.

3) 도구 이름을 회사명과 함께 정확하게 기록: OpenAI(ChatGPT, Codex, Dots), Anthropic(Claude Code, Claude), xAI(Grok Bot, Grok), Pickle, Inc.(Pickle).

그리고 가장 중요한 원칙을 문서 맨 위에 적어 두었습니다: "컴퓨터 코드를 고쳤다고 해서 끝난 것이 아니며, 실제 스마트폰 기기 화면에서 직접 눈과 손으로 테스트할 때까지는 완성된 것이 아니다."

자주 묻는 질문 (FAQ)

Q1. 픽셀(Pixel)이란 무엇인가요?

A. 컴퓨터나 스마트폰 화면을 이루는 가장 작은 단위의 네모난 점입니다. 화면에 보이는 모든 글자, 사진, 게임 캐릭터는 이 작은 네모 점들이 모여서 만들어집니다.

Q2. 왜 비유를 쓰지 않고 점(픽셀)을 직접 세어야 하나요?

A. 컴퓨터 프로그램은 숫자로만 작동하기 때문입니다. "조금 크다"거나 "약간 밀렸다"는 표현은 컴퓨터가 이해할 수 없지만, "가로로 1픽셀 줄여라"라고 숫자를 정확하게 주면 컴퓨터가 틀리지 않고 똑같이 화면을 그립니다.

Q3. 9-슬라이스는 왜 필요한가요?

A. 네모난 버튼을 길게 늘릴 때 네 모서리의 둥근 모양이 찌그러지는 것을 막기 위해서입니다. 네 모서리는 그대로 두고 가운데 네모 부분만 늘려서 모양을 반듯하게 유지합니다.

728x90
728x90