transform.Find 메소드 사용시 주의점

 리듬게임 프로젝트를 진행하면서 평소와 같이 코딩을 해나가던 중 문제가 발생했다. 에디터 환경설정과 관련해서 UI 스크립트를 작성중이었는데, transform.Find가 제대로 동작하지 않는 것이었다.. 정확히 말하자면, transform.Find 메소드가 반환하는 트랜스폼이 null이었다. 때문에 GetComponent 메소드가 동작하지 않았고 오류가 나는 것이었다. 그리고 아래의 코드가 그 문제가 되는 부분이었다.

 

 여러분들은 문제가 보이는가? 트랜스폼의 경로가 길어 가독성이 떨어지지만 분명 15, 16행의 코드는 잘 실행되고 바인딩이 제대로 되는 한편 17, 18행의 코드는 전혀 동작할 기미를 보이지 않았다. 필자는 처음에는 해당 오브젝트들을 스크롤뷰에 넣어 구현했기 때문에 트랜스폼이 Content Size Fitter와 같은 부모의 컴포넌트로부터 영향을 받아 트랜스폼을 찾지 못한다고 가정을 세웠다.

 

 하지만 그렇게 생각하면 또 이상한게 15, 16행의 코드는 정상적으로 작동했고, 함수 호출주기의 문제도 아닌 것 같았다. 혹시 몰라서 Start 함수에 넣어보기도 하고, 초기화를 따로 하기위해 Init 메소드를 작성해서 돌려보기도 했다. 하지만 모두 실행되지 않았다. 심지어 transform.Find로 트랜스폼을 먼저 받아온 후에 GetComponent 메소드를 실행해봤지만 애초에 트랜스폼이 null값이었다.

 

 문제가 전혀 해결될 기미가 보이지 않아 다른 씬에서 스크롤뷰를 사용하는 스크립트들과 오브젝트들을 확인하며 원인을 찾던 중 조금 다른 곳에서 그 실마리를 잡았다.

 

 해당 하이래키 뷰를 자세히 보면 조금 불편한 부분이 한 군데 있다. 바로 OptionPanel 자식으로 있는 Scroll View 오브젝트다. 다른 오브젝트들의 경우 모두 CamelCase형식에 맞춰 명명했지만, Scroll View의 경우 유니티에서 스크롤뷰 오브젝트를 생성한 후에 필자가 따로 이름을 바꾸지 않았기 때문에 기본값이 들어갔고, 띄어쓰기가 들어간 것이다.

 

 어? 근데 나는 경로에 띄어쓰기를 고려해서 코드를 작성한 적이 없는데 왜 이전 코드들은 잘만 돌아갔지? 그건 에디터 씬의 오브젝트는 또 내가 붙여쓰기로 수정해뒀기 때문이다. 위의 사진은 에디터 씬이 아닌 인게임 씬의 하이래키 뷰로, 추후에 일관성을 위해 모두 붙여쓰기로 수정했다. 물론 띄어쓰기가 있는 경우에는 띄어쓰기도 포함해서 경로를 적어야한다.

 

 여기서 불현듯 나는 생각이 들었다. 혹시 이렇게 내가 잘못 확인한 경로가 코드상에 존재하지는 않을까? 분명히 드래그를 해가며 경로를 똑같이 집어넣었는지 수번을 확인했다. 하지만 짚히는 곳은 달리 없었다.

 

 다시 처음으로 돌아가서 경로를 살펴보자. 공통된 경로부분을 드래그해보면 확실히 IDE 상에서는 같은 문자열이라고 표시해준다. 그런데 자세히 보면 차이점이 딱 한 군데 존재한다.

 

 바로 Viewport에서 p를 소문자로 적었냐 대문자로 적었냐다! 뒤늦게 알아챈게 무색할 정도로 어이없는 실수다. transform.Find 메소드는 대소문자를 구분한다. 그걸 알고있기 때문에 CamelCase로 명명한 오브젝트들의 이름을 그대로 가져왔고, 평소 코딩을 할 때도 이 부분을 염두에 두고 작업했다.

 

 하지만 이 습관이 Viewport에서 View와 Port를 다른 단어라고 생각하고, p를 대문자로 작성한 것이 문제가 된 것이다. 간혹 transform.Find 메소드를 사용할 때 경로가 길어지는 경우가 있을 것이다. 그땐 대소문자의 구분에 있어서 틀린부분이 없는지, 제대로 경로를 따왔는지 면밀히 검사해볼 필요가 있다. 공통된 경로부분은 따로 문자열로 저장해서 붙여주는 방법 또한 가독성을 높일 수 있을 것이다. 필자는 실제로 그렇게 수정했다.

 

 코드가 길어지면 길어질 수록 리팩토링의 중요성을 점점 깨닫는 것 같다..