오늘은 디버깅하는 법에 대해 알아보고자 합니다.
그동안은 프로젝트를 진행하면서
Debug.Log를 통해서 일일이 확인해 가며 완성했었습니다.
이 방식으로는 한계가 있었고 캠프 마지막 프로젝트에 들어가기 전
제대로 디버깅하는 법을 익히고, 정리해 보고자 글을 작성하게 되었습니다.
(사실 늦은 감도 있긴 합니다만;; 원래 늦었다고 할 때가 가장 빠른 거 아니겠습니까;;;)
유니티의 Debug기능
매번 Debug.Log("");만 사용해 봐서
그 외에도 대표적으로 자주 사용되는 몇 가지 기능들을 가져와 사용해 봤습니다.
Debug.Log를 사용할 때 몇 가지 주의할 점이 있는데
Debug.Log를 까먹고 지우지 않은 채 빌드하면
그대로 노출되어 해킹의 위험이 될 수 있습니다.
이뿐만 아니라 성능 저하의 원인이 될 수도 있어서
Debug.Assert를 사용하는 걸 권장하는 듯합니다.
Debug.Assert의 경우 빌드할 때는 제외된다고 합니다.
IDE 디버깅
IDE?
integrated development environment의 줄임말로
소프트웨어 코드를 효율적으로 개발하도록 돕는
소프트웨어 애플리케이션이라 할 수 있습니다.
대표적으로 Visual studio, Rider가 있겠네요.
최근에 Rider(유니티에 특화된 IDE라고 할까요?)가 부분 무료화가 되어서
관심 있으신 분은 한번 사용해 보시는 것도 좋아 보입니다.
주위에서도 많이들 넘어가는 것 같던데
저도 조만간 넘어가야 하나 고민 중입니다.
잡설이 길었네요.
우선은 제가 주로 사용하는 Visual Studio(이하 VS)로
디버깅하는 법에 대해 다루고자 합니다.
Rider나 VS Code로 디버깅하는 방법은
아래 참고 자료 영상에서 자세히 다루고 있으니
한번 확인해 보시면 좋을 것 같습니다.
1부터 100까지 세는 간단한 코드를 작성해 봤습니다.
중단점을 활용하여 다음의 코드가 어떻게 동작하는지 자세히 보고자 합니다.
중단점을 찍는 방법은 원하는 줄 위치를 클릭 후 F9를 누르거나
흰색 점이 있는 부분에 마우스를 올리고 더블클릭하면 중단점을 설정할 수 있습니다.
(그 부근에 마우스를 올리면 흰색 점이 생깁니다. 아마 직접 해보시면 무슨 말인지 이해하실 겁니다.)
빨갛게 변한 게 보이시나요? 중단점이 설정된 겁니다.
해제하는 법은 반대로 빨간 점을 두 번 클릭하거나 F9를 누르면 해제할 수 있습니다.
이제 코드를 실행하면 중단점 찍은 부분을 지날 때마다 그 자리에서 멈추고 확인이 가능합니다!
중단점 여러 개를 찍고 작업하다가
어느 정도 해소가 되어 넘어가고 싶을 때는 어떻게 하면 좋을까요.
디버그 창에서 모든 중단점 해제를 선택하면
중단점을 잠시 비활성화시킬 수 있습니다.
중단점을 설정한 후 유니티와 연결 버튼을 누르면
다음과 같은 창이 뜰 텐데 Enable debugging을 누르면
유니티와 연동이 됩니다.
이제 유니티 플레이 버튼을 눌러 실행했을 때
설정한 중단점에서 코드를 자세하게 살펴볼 수 있습니다.
아래 창에서도 확인이 가능하고,
원하는 함수에 마우스를 올리면 현재 상태를 알 수 있습니다.
상단의 버튼 혹은 단축키를 통해서
중단점 이후 실행을 이어가며 확인 할 수도 있습니다.
단축 번호로는 F10, F11, shitf + F11 입니다.
각 기능은
한 단계씩 진행, 프로시저 단위 실행, 프로시저 나가기 기능입니다.
여기서 한 가지 의문이 생깁니다.
sum이 70번째 값일 때를 알고 싶은데 하나하나 눌러가면서 확인해야 하나.
아닙니다.
중단점에서 조건을 걸어 손쉽게 확인 할 수 있습니다.
조건 설정 방법은 중단점에서 우클릭하면 조건을 걸 수 있는 창이 뜹니다.
추가로 어디서 함수를 호출하고 있는지도 확인이 가능합니다.
코드를 아래와 같이 바꾸었고,
실행했을 때 호출 스택을 보면 Start()에서 sum()을 호출한 걸 확인 할 수 있었습니다.
(우측 하단에 출력이라고 적혀 있는 부분을 자세히 보시면 호출 스택이라고 적혀 있습니다.)
지금이야 간단한 코드라서 괜찮지만
큰 규모의 설계를 하다 보면 여러 곳에서 함수를 호출하게 될 텐데
이때 참고하면 좋겠죠?
마무리
오늘은 간략하게 디버깅에 대해 정리하는 시간을 가졌습니다.
공부하면서 TDD(Test - driven - development)라는 용어를 처음 들어봤습니다.
처음 들어봤지만, 내용을 보니 완성된 작업을 하기 위해
중간중간 테스트할 수 있는 코드를 작성하라는 이야기더군요.
버그 없는 코드는 존재할 수 없기에
이런 개발론적인 부분도 함께 소개해 준 듯합니다.
글에서는 주제와 벗어나는 것 같아
언급하지 않고 넘어간 유익한 부분들도 꽤 있어서
꼭 아래 참고 자료 영상을 한번 보셨으면 좋겠네요.
중간 내용에 DLL에 관해서 다루던데
이 부분은 따로 정리해 작성해 보겠습니다.
참고한 자료
https://www.youtube.com/live/4JlW0-hA6Zk?si=N90q_XpF_ZJn9p7L
https://docs.unity3d.com/kr/2023.2/ScriptReference/Debug.html
Debug - Unity 스크립팅 API
Class containing methods to ease debugging while developing a game.
docs.unity3d.com