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

글또 8기 활동이 반환점을 지나 7회차에 접어들었다. 이번에는 글을 마감일에 쫒겨 쓰고 싶지 않아 이수역 근처의 할리스 커피에서 글을 쓰게 됐다. 만나는 김에 글또 하는 다른 분들과 식사도 같이 하고 스몰톡을 하고 싶었지만, 다 같이 모일 수 있는 큰 테이블도 없는 듯 했고 모이는 시간도 각자 달라 이 부분이 조금은 아쉬웠다.

 

그래도 글 쓰는 중간에 잠깐 인사를 나눌 수 있는 기회가 있어 좋았다. 7회차 글을 쓰기 위해 온 만큼 열심히 글을 쓰고 얼른 집에 가자!

 

들어가며

이번 회차 글은 지난번 작성하던 "Unity UI Toolkit을 활용한 Custom Package 만들기"의 다음 편을 쓰게 됐다.

 

1편 : https://kugora.ng/21

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

 

약 한 달이 지난 시점이라 기억이 잘 나지 않을까 걱정되기도 하지만, 오히려 시간이 지났을 때 보이는 것들도 있으니 장점도 많을 거라 생각해본다.

 

프로젝트 진행 방식에서 좋았던 점

이번 회차 글을 어떻게 구성할까 하다 1편에 적었던 내용을 기반으로 키보드 타이핑을 하기 시작했다. 원래 3편에 프로젝트 회고를 적으려 했는데, 이 프로젝트 작업을 했던 기간이 지나 리마인드도 할 겸, 2편에 프로젝트를 회고 3편에 기술적인 내용을 작성하려 한다.

 

프로젝트 진행 방식에서 좋았던 점은 아래와 같았다.

 

• 올해 2월 말까지만 진행
  • 실제로는 3월 중순까지 진행됐다.
• 프로젝트 기록은 Github Discussion을, 급한 의사소통은 Discord를 활용

 

위의 두 가지 진행 방식은 모두 큰 의미가 있는 진행 방식이었다.

 

올해 2월까지만 진행

우선, 이번 사이드 프로젝트는 시작부터 데드라인을 부여하고 이를 지키려 노력하는 데 성공한 첫 번째 프로젝트라는 것에 큰 의의를 두고 싶다.

 

회사에서 일하며 꾸준히 들었던 피드백도 그렇고 평소 고쳤으면 하는 습관 중에서도 하나인 일정 잘 지키기에 대해 이렇게 빡세게 설정하고 들어갔던 프로젝트는 몇 없었던 걸로 기억한다. 평소의 사이드 프로젝트이면 하고 싶은 거를 왕왕 하다, 내 열정과 체력이 점점 떨어져감에 따라 조금씩 그 기획을 줄이는 것이 관례였다.

 

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

 

하지만 이 프로젝트는 시작 때부터, "저희 두 달 동안 할 수 있는 걸 하죠" 라는 말을 나와 다른 분 모두 입에 달고 살았기 때문에 현실적으로 원하는 바를 만족하면서 잘 끝낼 수 있었던 것 같다.

 

한 예로, 입력 시스템을 기록하는 경우 PC는 키보드와 마우스만 고려하면 되지만 모바일의 경우 입력 좌표, 멀티 터치, 스와이프 등을 모두 고려해야 한다. 내가 이에 대한 걱정을 할 때 동료 분께서 "저희 두 달 동안 할 수 있는 걸 하죠" 를 말씀해주셔서 그냥 PC만 고려하기로 했고, 추후 폭발적인 반응이 있을 때 업데이트를 하기로 했다.

 

결과적으로는 올바른 선택이었다고 생각한다. 매번 큰 그림만 그리다 중요 시스템을 제대로 구현 못하기 일쑤였는데 이번에는 그러지 않아 좋았다.

 

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

 

그리고 원래 2월 말이라는 목표도 우리가 정한 목표에서 예상치 못한 문제가 발생해서 버그 수정 때문에 조금은 늦어져서 이 또한 나에게는 "데드라인은 설정하기 나름" 이라는 생각도 다시끔 들게 했다. 회사를 다니며 느꼈던 건 "합리적인 이유가 있다면 일정이 얼마든지 늦춰져도 된다" 였다. 모든 회사가 그런지는 잘 모르겠지만, 현재까지 내가 몸 담았던 회사들의 경우 사업부의 요청이 아니라면 이 규칙의 예외는 없었다.

 

완벽주의보다 완성주의가 프로젝트 결과에 긍정적인 영향을 미치는 걸을 보며, 다시끔 소프트웨어공학이라는 과목에서 배웠던 애자일 방법론이 왜 인기를 끌었는지 알 것 같았다.

 

Github Discussion과 Discord

나머지 한 부분은 동료와의 의사소통 방식이었다. 그동안 오픈소스에 대한 관심은 항상 있어왔고, 오픈소스 컨트리뷰션이라는 행사를 통해 여러차례 오픈소스 프로젝트도 접해봤었다. 그러나, 깃허브를 "오픈 소스 프로젝트 관점에서 제대로 활용하고 있는가?" 에 대한 스스로에 대한 물음에 대해 선뜻 "그렇다" 라고 말할 수는 없었다. 내가 프로젝트를 주도적으로 하기 보다 기존의 잘 짜여진 프로젝트의 일부 개선 사항을 코드 몇 줄 추가하는 것에 그쳤기 때문이라고 생각한다.

 

하지만, 이 프로젝트를 통해 Github의 PR을 비로소 조금이나마 제대로 사용해봤다고 생각한다. 이 점 때문에, 같이 프로젝트를 진행했던 동료 분께 다시 한 번 감사함을 느낀다.

 

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

 

물론 Github Discussions를 통해 모든 의사소통을 하기는 힘들었다. 그래서 사소한 대화나 비공개로 하면 좋을 대화 같은 건 디스코드 서버에서 소통했다. DM을 통해 의사소통 할 수도 있었지만, 프로젝트의 작은 흔적들이 모여 기록이 되고 이 또한 프로젝트의 일부로 남는 게 좋겠다고 생각했었다. 그리고 추후 관심 있는 사람이 들어왔을 때 서버의 대화를 보며 Follow up이 가능하기 때문에 이렇게 아카이빙하는 게 좋겠다고 생각했었고, 실제로 한 달이 지난 시점에서 굉장히 잘 한 선택이라고 생각된다.

 

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

 

프로젝트에서 새로 사용한 기술에서 좋았던 점

다음은 이번 프로젝트에서 새로 사용 또는 도입해서 좋았던 기술적인 요소들을 정리해봤다.

 

UI Tookit으로 Editor Scripting 진행

아무래도 가장 좋았던 건 역시 Unity에서 만든 최신 기술인 UI Toolkit을 실사용을 할 수 있었던 것이 아닐까 싶다. 평소 Unity의 UGUI를 활용해서 UI 작업을 많이 하는 만큼, 관심 있게 지켜보던 기술인데 실제로 사용을 해보니 장단점이 뚜렷하게 느껴져서 좋았다.

 

먼저, 좋았던 점은 프로젝트를 위해 UI Toolkit을 공부하다보니 Unity에서 UGUI에 대한 근본적인 문제를 제대로 해결하려는 의지가 돋보였다는 것이었다. In Game과 Editor의 코드를 별도의 Scripting이 아닌 UI Toolkit이라는 하나의 기술로 묶으려 했던 점, 벡터 방식을 도입해 불필요한 기본적이고 단순한 Sprite의 경우 UI Toolkit 내부에서 처리하려 한 점, UI View와 기능을 분리해서 관리하려 하는 점 등은 특히 웹 퍼블리싱 개념을 접해본 나에게 신선한 충격으로 다가왔다.

 

그러나, 단점도 명확하게 보였다. 우선 이번 프로젝트에서 In Game UI는 적용하지 않고 Editor에서만 UI Toolkit을 사용했는데, 아직 숙련도 문제인지 기존 UGUI 작업 프로세스와는 완전히 달라 러닝 커브에 대한 문제가 있었다. 그리고 모든 신규 기술이 마찬가지겠지만, 아직 도입된 직후라 프로젝트에 적용된 사례를 찾기 힘들어 선뜻 상용 프로젝트에 넣기에는 부족함이 많아 보였다. 특히 기존 프로젝트에 대한 마이그레이션이 사실상 불가해서 새로 작업을 해야될텐데 이 부분에 대한 재설계의 비용이 만만치 않을 것으로 예상되어 기존 프로젝트에 UI Toolkit을 넣는 건 힘들지 않을까 싶다.

 

하지만 Unity라는 게임 제작을 위한 엔진을 만드는 사람들이 만든 기능인만큼 곧 대세가 되지 않을까 하는 게 지금 생각이다! 에셋 번들이 어드레서블로 대체되기까지의 과정이 몇 년 걸렸듯이, UGUI도 UI Toolkit으로 서서히 대체되어 추후 ECS와 더불어 Unity를 대표하는 핵심 기능 중 하나가 되지 않을까 하는 예상을 해본다.

 

UI Toolkit! 난 널 믿어 (진심)

 

JetBrians사의 Rider 사용

Rider의 경우, 좋다고 많이 이야기를 들었지만 가볍고 약한 그램이 실행하기엔 너무나 무거운 친구라 그동안 VS나 VS Code를 주로 사용했었다. 그런데 올해 1월, 13세대 i7, 64GB의 RAM, 그리고 RTX 4070 Ti를 품고 있는 데스크탑 친구가 생기면서 상황이 많이 달라졌다.

 

든-든

 

근 10년만에 사게 된 데스크탑이라, 이왕이면 오래 쓰고 싶어 내 예산 범위 안에서 구매 가능한 가장 좋은 부품을 데스크탑에 넣었다. (그래픽카드가 많이 비쌌지만... 우리 오래오래 함께 하자 ㅠㅠ) 그래서 요즘은 그램과 아이패드로 이 데스크탑에 원격을 붙어 주로 작업하고 있다. 자연스럽게 고사양 프로그램과 게임도 관심이 생겨 이번 프로젝트부터 Rider를 도입해서 사용해보기 시작했다.

 

시간이 조금 지난 시점에서 돌아보면, Rider의 빡빡한 코드 개선 사항이 도움이 될 때가 많은 것 같다. 왜 이렇게 단축시킬 수 있는지, 고쳤을 때 문제가 발생하면 왜 발생했는지에 대해 익힐 때 공부가 많이 된다. 그리고 2023.1 버전이 되면서 한글이 정식으로 지원되고, Github Copilot까지 Plugin이 제공되면서 이제 데스크탑에서는 Rider만을 IDE로 사용하게 될 것 같다.

 

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

 

ChatGPT 3.5 모델을 활용한 코드 작성

처음에는 이 프로젝트에 ChatGPT를 사용할 계획이 없었기에 UI Toolkit 공부를 진행하면서 시간 소요가 꽤 많이 들었다. 그런데, 프로젝트를 하면서 ChatGPT를 활용하여 러닝 커브를 줄일 수 있지 않을까 하는 생각이 들어 이번 프로젝트에서 본격적으로 ChatGPT를 프로젝트에 사용해보았다.

 

결과는 절반의 성공이었다고 생각한다. 위에서 의도한대로 ChatGPT를 통해 UI Toolkit에 대한 기본 틀 구성과 함께 ChatGPT가 제공하는 설명이 이 프로젝트의 많은 진행을 맡아주어 이 부분은 의도했던대로 제대로 사용했다고 생각한다. 다만, ChatGPT가 환각(할루시네이션)을 통해 없는 코드를 있는 것처럼 속여 코드를 작성했을 때, 해당 코드 조각의 전부를 통째로 사용할 수 없음을 알게 된 순간 굉장한 상실감도 느낄 수 있었다.

 

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

 

이번 사례를 통해 ChatGPT에게 핵심 기능, 특히 최신 기술일수록 코딩을 맡기는 것에 신중을 기해야 함을 느꼈다. 다만, 이번 프로젝트는 ChatGPT 3.5 모델을 적용했었기 때문에 ChatGPT의 성능을 평가 절하하기엔 너무 이르지 않나 하는 생각도 들었다. 현재 유료 결제를 통해 GPT-4 모델을 사용 중인데, GPT-4 모델은 정확도가 정말 높아서 이 친구였다면 결과가 많이 다르지 않았을까 하는 생각도 든다.

 

마치며

이번 글은 지난 프로젝트의 진행과 기술 관점에 각각 어떤 점이 좋았고, 이로 인해 내가 어떤 점을 느꼈는지 주로 기술했다. 본문 내용을 간단히 요약해보면 아래와 같이 정리할 수 있다.

 

• 사이드 프로젝트임에도 욕심 부리지 않고 데드라인에 맞춰 진행했다.
• Open Source 관점에서 Github Discussion과 Discord를 사용하여 협업했다.
• Unity UI Toolkit, Jetbrains Rider라는 새로운 기술과 도구를 사용해봤다.
• ChatGPT 3.5 모델의 인공지능과 함께 페어 프로그래밍을 했고, 나름 만족할만한 코드를 작성했다.

 

사실 이 사이드 프로젝트할 때 여러 가지 일이 겹쳐 심적으로나, 신체적으로 매우 지친 상태였다. 그래도 이렇게 회고를 해보니 감정은 순간이지만, 결과는 평생이라 힘든 것보다 뿌듯함과 보람이 더 크게 기억 남는 듯하다.

 

다음 글은 프로젝트 진행을 하며 문제가 발생했던 내용과, 이를 어떻게 해결했는지 기술하고 시리즈를 마무리하겠다.