[내일배움캠프_2025AUG04] 팀 프로젝트 5일차, 발표 준비

팀 프로젝트 5일차, 발표 준비

 

오늘은 주말이 지나고 팀 프로젝트 5일차가 되었다!

 

개발보다는 버그 픽스를 위주로 진행하고 발표자료를 만들고 발표 연습을 진행했다.

유니티 경력이 있으신 분들이 계셔서 그런지, 버그 픽스 혹은 구현을 더욱 간단하게 하는 방법들을 얻을 수 있었다.

팀플의 장점인 것 같다.

---

스크롤 뷰

상단 우측 이미지와 같이 여러 항목들을 UI에 표시해야하는 상황이었다.

나는... for 문을 이용해 컨텐츠 크기 + 패딩 만들의 간격을 만들어서 생성해주는 방식을 사용했다.

때문에 4가지 아이템만 만들어둔 상태고, 추후 시간이 있으면 스크롤 기능을 자체 구현해야지! 라는 생각을 하고 있었다.

 

그러나 UI인 탓에 화면 비율이 바뀌자마자 바로 오류가 떴고...

이를 확인한 팀원 분이 "스크롤 뷰로 하면 간단할 것 같은데, 제가 고칠까요?" 라고 하시고 바로 고쳐주셨다.

 

하단의 코드 블럭을 보면 for문 내부에 단 2줄의 코드로 간단하게 구현하신 것을 확인할 수 있었다.

[SerializeField] GameObject itemPanel;
[SerializeField] Transform content;

void Start()
{
    foreach (OutfitItemBase item in OutfitItemData.allOutfitItems)
    {
        GameObject go = Instantiate(itemPanel, content);
        go.GetComponent<OutfitItemPanelUI>().Setting(item.Id);
    }
}

생각해보면 웹 개발을 할때 UI Framework를 사용하곤 했다.

그때에도 UI를 구현하고 나면 이미 Framework에서 제공하는 UI라서 허탈했던 적이 한두번이 아니었다.

그때 생각했던 것이 Framework를 사용할거면... framework에 대한 공부도 필요하다는 것이다.

 

유니티 또한 같은 개념인 것 같다.

하지만 아직 배우는 과정에서 존재 자체를 전혀 모르는 경우에는 어떻게 해야할까?

어떻게 하면 존재조차 모르는 기능을 더 빨리 발견할 수 있을까?

 

이럴 때 튜터님을 찾아뵈어야하는 것 같다.

당시에도 사수에게 바로 물어보지 않아 같은 일을 더 어렵게, 두번이나 했었는데 똑같은 실수를 반복할 수는 없지..

물론 그 전에 문제가 생겼을 때 "이건 이미 유니티가 해결책을 제공했을까?"를 먼저 의심하는 습관이 필요하다.

질문 전엔 최소한 Unity Manual과 Unity Learn을 10분 내에서 뒤져보고 안되면 바로 튜터님을 찾아가야겠다.

---

Button Navigation Option

키 바인딩을 변경할때, 이상하게 Space로 키 바인딩을 시도하면 계속해서 이해할 수 없는 진행이 되었다.

Jump를 바꿨다고 생각했는데 Slide가 바뀌는 식이다.

매일 버그를 고치면서 문제 원인을 좁혀갔지만, 처음에는 키 입력 이벤트 쪽만 의심해서 문제를 완전히 해결하지 못했다.

(생각해보면 중간부터는 불필요한 작업이었다. 덕분에 코드가 깔끔해졌지만, 시간 소모가 커서 계획했던 튜토리얼 UI 구현을 하지 못했다. 앞으로는 우선순위에 맞춰 꼭 필요한 부분부터 집중해야겠다.)

 

오늘 게임 빌드를 하고 그걸 플레이해본 팀원 분이 이 부분에서 또 문제가 발생한다고 하셔서 정말.. 포기하고 싶었다.

회의 중이었어서 같이 있었던 다른 팀원 분이 Button 컴포넌트의 Navigation 속성이 기본적으로 ‘Automatic’이라서 Space키가 버튼 간 포커스 이동 역할을 하며 의도하지 않은 버튼이 선택될 수도 있다고 알려주셨다.

이 관점은 내가 놓쳤던 부분이었다.

 

문제 해결 후에는 Navigation을 ‘None’으로 설정하여 이런 자동 포커스 이동을 차단했다.

 

인터넷 웹사이트에서 tab키를 누르면 다음 항목으로 이동하는 것처럼 유니티도 비슷한 기능을 space로 하는 것이다.

때문에 내가 선택한 버튼이 아닌 다른 버튼이 선택되어 변경되었던 것 같다.

 

이번 경험으로 UI 컴포넌트 기본 동작을 항상 체크하는 습관과, 팀 내 다양한 시각을 빠르게 수용하는 태도의 중요성을 깨달았다.

앞으로도 문제를 좁힐 때는 기능 동작 원리를 먼저 점검하고, 팀원과 적극 소통하는 것을 루틴으로 삼아야겠다.

참고

https://docs.unity3d.com/kr/2021.3/Manual/script-SelectableNavigation.html

---

느낀점

오늘 진행하면서 느낀 점은 내가 기능 동작 원리에 대한 확신과 버그를 향한 끈기가 부족하다는 것이다.

버그를 고쳐도 계속해서 비슷한 버그가 발생하는 것은 기능에 대한 충분한 조사와 확신 없이 기능을 구현했기 때문이다.

확신이 없기 때문에 이 기능의 동작 원리 중 내가 놓친 것이 있다는 생각에 코드만 살펴봤지 다른 관점으로 생각해볼 여유가 없었고, 이로 인해 더 많은 시간을 버그 픽스에 투자했음에도 고칠 수 없었다.

 

정말 전부 다 끝냈다고 생각했던 오늘 오전에도 버그가 발생하자 팀원들이 아니었다면 포기해버릴 뻔 했다. 

내가 구현한 기능인데 그러면 안됬었다고 생각한다.

 

결론적으로, 구현하고 버그가 발생하면 고치는 데 급급해하지 말고, 내가 해당 기능을 충분히 이해하고 구현하려고 했는지 점검하는 태도가 필요한 것 같다.

앞으로는 기능을 구현하기 전에 관련 문서와 사례를 충분히 조사하고, 설계 계획을 세운 뒤 개발에 들어가야겠다.

또한, 문제 발생 시 팀원과 적극적으로 소통하며 빠르게 피드백을 받을 수 있도록 루틴과 환경을 조성해야할 것 같다.

정기적인 코드 리뷰 시간을 마련하거나 버그 공유 회의 활성화같은 식으로 말이다.

---

내일 학습 할 것은 무엇인지

내일은 발표!

옆 발표장 팀장님이랑 팀 발표 연습 및 피드백 품앗이를 하기로 했다.

다른 팀의 발표를 보면서 배울 점들도 찾아야하고

무엇보다! 개인과제 해설을 아직 못 봤다ㅠㅠ

내일 오전 중에 여유가 생길 것 같으니 꼭 봐야겠다.