Unity UI Toolkit을 활용한 Custom Package 만들기 (2)

TL;DR — 3줄 핵심 요약

• 문제: 두 달 안에 낯선 기술로 Unity 에디터 도구를 만드는 사이드 프로젝트에서 일정과 결과를 함께 잡아야 했다.

• 기술/원인: 처음부터 범위를 잘랐다(PC와 키보드·마우스만). 기록은 GitHub Issue와 Discussion에, 사소한 대화는 Discord에 남겼다. 코드 초안은 ChatGPT 3.5로 만들었다.

• 해결/인사이트: 마감은 2월 말에서 3월 중순으로 밀렸지만 기능은 끝냈다. ChatGPT는 구조를 잡는 데 도움이 됐고, 없는 API를 있는 것처럼 쓰는 환각 때문에 코드를 통째로 쓰지는 못했다.

들어가며: 2편에서 다루는 것

1편에서는 프로젝트를 시작한 계기와 목표, 역할을 정리했다. 2편에서는 진행 방식과 새로 쓴 기술에서 좋았던 점과 아쉬웠던 점을 정리한다. 3편에서는 진행 중 생긴 문제와 해결 과정을 다룬다.

Unity UI Toolkit을 활용한 Custom Package 만들기 (1)

작업이 끝난 지 한 달쯤 지난 시점에 쓰는 글이라 세부 기억은 흐려졌지만, 시간이 지나야 보이는 것도 있었다.

진행 방식 1: 지킬 수 있는 크기로 목표를 자른다

이 프로젝트에서 가장 큰 성과는 마감을 정하고 지킨 것이다. 보통 사이드 프로젝트는 만들고 싶은 기능이 계속 늘어나고, 시간이 지나면서 의욕과 체력이 줄어 기획이 작아지다가 멈춘다.

그동안 나를 거쳐갔던 사이드 프로젝트들은 그나마 "말"이라는 게 표현되어도 성공이었다.

PC만 지원하기로 한 이유

입력을 기록하는 시스템은 PC라면 키보드와 마우스 두 가지만 처리하면 된다. 모바일은 손가락 좌표, 여러 손가락 동시 입력, 스와이프까지 다뤄야 한다. 내가 이 걱정을 꺼냈을 때 동료가 "두 달 동안 할 수 있는 것만 하자"고 했고, 그래서 PC만 다루기로 했다. 나중에 사용자가 늘면 그때 모바일을 붙이기로 했다.

결과적으로 옳은 선택이었다. 이전에는 큰 구조만 그리다가 핵심 기능을 끝내지 못하는 일이 반복됐다. 이번에는 적은 범위지만 실제로 동작하는 결과가 나왔다.

마치 "하쿠나 마타타"를 외치는 것과 비슷하달까?

마감이 밀렸을 때의 판단

2월 말 목표는 버그 수정 때문에 3월 중순으로 밀렸다. 회사에서 배운 기준은 "합리적인 이유가 있으면 일정은 늦출 수 있다"였다. 완벽을 목표로 하기보다 완성된 결과를 먼저 내는 편이 프로젝트에 도움이 된다는 것을 확인했고, 소프트웨어공학에서 배운 애자일 방법론이 왜 쓰이는지도 이해하게 됐다.

진행 방식 2: 기록이 남는 협업

GitHub의 Issue를 Project 보드와 연결해 할 일을 관리했고, 공개해도 되는 자료는 Discussion에 정리했다. 이전까지는 오픈소스 프로젝트에 코드 몇 줄을 더하는 정도였다. 이번에는 PR로 코드를 주고받고 리뷰를 하는 과정을 처음으로 제대로 해 봤다.

Github의 Issues를 Project와 연계하고, 작업 진행 중 공개하면 좋을 자료들은 Discussions로 기록했다.

Discord를 함께 쓴 이유

모든 대화를 GitHub에 남기기는 어려웠다. 사소한 대화와 공개하기 어려운 이야기는 Discord 서버에서 나눴다. DM 대신 서버 채널을 쓴 것은 대화가 기록으로 남아, 나중에 관심을 가진 사람이 읽고 이어서 참여할 수 있기 때문이었다. 한 달 뒤 돌아보니 이 선택은 옳았다.

2월 16일에는 맥북이 버즈2와 사이가 좋지 않아 사이를 달래주느라 회의가 조금 지연됐었다.

기술 1: UI Toolkit으로 에디터 화면 만들기

이번 프로젝트에서 가장 큰 부분이다. 평소 UGUI로 UI를 만들어 왔기 때문에 두 방식의 차이가 뚜렷하게 느껴졌다.

좋았던 점

• 게임 화면과 에디터 화면을 같은 기술로 만들 수 있다. 코드를 두 벌로 나눌 필요가 없다.
• 테두리, 모서리 둥글기, 색을 이미지 없이 값으로 그린다. 단순한 도형을 위해 이미지 파일을 만들지 않아도 된다.
• 화면 구조(UXML)와 동작(C#)을 나눠서 관리한다. 웹에서 HTML과 스크립트를 나누는 방식과 같다.

아쉬웠던 점

• UGUI와 작업 순서가 완전히 달라 익히는 데 시간이 들었다.
• 출시된 지 얼마 되지 않아 적용 사례가 적고, 상용 프로젝트에 넣기에는 확인할 것이 많았다.
• 기존 UGUI 화면을 그대로 옮길 수 없어 새로 만들어야 한다. 재설계 비용이 크다.

그래도 Unity가 직접 만든 기능이고, 에셋 번들이 어드레서블로 바뀌는 데 몇 년이 걸렸던 것처럼 시간이 지나면 UGUI도 UI Toolkit으로 옮겨 갈 것으로 본다.

UI Toolkit! 난 널 믿어 (진심)

기술 2: Rider로 옮긴 이유

Rider는 JetBrains가 만든 IDE다. 좋다는 이야기는 들었지만, 이전에 쓰던 가벼운 노트북에서는 너무 무거워 Visual Studio와 VS Code를 썼다. 2023년 1월에 데스크탑(i7 13세대, RAM 64GB, RTX 4070 Ti)을 장만하면서 상황이 바뀌었다.

든-든

코드를 줄일 수 있는 곳을 구체적으로 알려 주기 때문에, 왜 그렇게 고치는지 배우게 된다. 2023.1 버전부터 한국어를 정식으로 지원하고 GitHub Copilot 플러그인도 제공되어, 데스크탑에서는 Rider만 쓰게 됐다.

Rider, 유니티와 언리얼 모두 잘 부탁해!

기술 3: ChatGPT 3.5로 코드 초안 만들기

처음에는 쓸 계획이 없었지만, UI Toolkit을 익히는 시간을 줄이려고 프로젝트에 도입했다.

결과는 절반의 성공이었다. 화면의 기본 구조를 잡고 각 부분이 무슨 역할을 하는지 설명을 받는 데는 도움이 됐다. 그러나 없는 API를 있는 것처럼 설명하며 코드를 만들어 내는 환각(할루시네이션)이 있었고, 그 부분은 코드를 통째로 쓸 수 없었다.

ChatGPT가 환각을 겪으면서 행복했던 추억 모두를 하얗게 불태웠다. :)

최신 기술일수록 AI에게 핵심 기능 구현을 맡기는 일은 신중해야 한다. 다만 당시 쓴 모델은 3.5였고, 지금 쓰는 GPT-4는 정확도가 높아 결과가 달랐을 수 있다. AI가 만든 코드는 초안이며, 컴파일과 실행, 실제 기기 검증, 운영 반영은 각각 따로 확인해야 한다.

정리

• 사이드 프로젝트라도 범위를 줄여 마감 안에 끝내는 편이 결과가 남는다.
• GitHub Issue와 Discussion, Discord를 나눠 쓰면 기록과 대화가 함께 남는다.
• UI Toolkit과 Rider는 이번에 처음 실무처럼 써 봤고, 둘 다 계속 쓸 생각이다.
• ChatGPT 3.5는 구조를 잡는 데는 유용했고, 없는 코드를 만들어 내는 경우가 있어 검증이 필요했다.

이 프로젝트를 하던 시기에는 다른 일이 겹쳐 몸과 마음이 지쳐 있었다. 그래도 회고로 정리해 보니 힘들었던 기억보다 결과가 남은 느낌이 크다. 다음 글에서는 진행 중 생긴 문제와 해결 과정을 정리하고 시리즈를 마무리한다.

자주 묻는 질문 (FAQ)

Q1. 사이드 프로젝트에서 마감을 지키는 방법은 무엇인가요?

A. 시작할 때 범위를 먼저 정하는 것이 핵심이다. 이번에는 PC와 키보드·마우스만 다루기로 하고 모바일은 제외했다. 기능을 늘리는 대신 "두 달 동안 끝낼 수 있는 것"을 기준으로 목록을 만들면 마감이 지켜진다.

Q2. GitHub Discussion과 Discord는 어떻게 나눠 썼나요?

A. 공개해도 되는 기술 기록과 결정 사항은 GitHub Discussion에, 사소한 대화와 공개하기 어려운 이야기는 Discord 서버에 남겼다. 둘 다 채널에 기록이 남기 때문에 나중에 참여한 사람이 읽고 따라올 수 있다.

Q3. ChatGPT가 만든 코드의 환각은 어떻게 확인했나요?

A. 코드를 실제로 컴파일하고 실행해 봤고, Unity 공식 문서와 대조했다. 존재하지 않는 API는 컴파일 단계에서 오류가 나므로 바로 드러난다. 최신 기술일수록 문서 확인이 먼저다.