0072.txt

네 안녕하세요. 포프입니다.
오늘은 디버그 빌드(Debug Build)에 대해 얘기를 좀 해볼게요.
어찌 보면 예전에 제가 블로그
제 개인 블로그 하고
게임........
게임 개발.....
게임 개발 포에버
거기 블로그 하고 동시 게재했던 
글에도 그런 게 있었는데
그거랑 맥락을 같이하는 글이에요 똑같은 글은 아니고
그때 글 제목이
"컴파일러 워닝(Warning) 하나당 열대씩 맞습니다." 라고  올렸던 거 같아요.
그래서
그거하고 좀 비슷한 얘기예요.
왜냐하면, 어찌
제가 이제
얼마전에 EA에 있을 때 다시 한번 뼈저리게 느꼈던 거기도 하고
그래서 오늘 할 말은 디버그 빌드를 유지하라는 
얘기를 하고 싶어요.
유지라는 게 뭐냐면
그 보통 그 프로그램 솔루션 C++ 쪽에서 
솔루션 작업하시는 분들은
뭐 굳이 C++ 아니여도 똑같겠지만
디버그 빌드(Debug Build)하고 
릴리즈 빌드(Release Build)라는 게 있잖아요.
이제 디버그 빌드는 모든 디버그~~~~~
코드가 활성화돼 있고
아 코드 최적화도 안 돼 있기 때문에 속도는 느리지만
아 코드가 로직이 제대로 실행되어 있는지 볼 수 있는 
그 빌드가 디버그고
브레이크 포인트 걸 수 있고 뭐 변수 명도 다 볼 수 있고
그게
이제 그런 거 이제 다 빼고 뭐 최적화하고
뭐 코드도 좀 알아서 삭제해주고 
컴파일러(Compiler)가 링커(Linker)가
그런 게 이제
아.. 릴리즈 빌드라고 많이 하죠.
그래서 회사 따라는 릴리즈 빌드 자체를
최종 빌드로 해가지고 실제로 납품하는 경우도 있고
아니면 그다음에 파이널 빌드라고 해서
더더욱 또
잘라내 그러니까 뭐 더더욱 최적화시키고 아예 디버그
아... 기능 완벽히 빼버리고 
그렇게 세 가지로 나누는 사람들도 있고
아... 아니면은 거기다 이제 릴리즈 빌드인데
여기다가 이제 프로파일(Profile)을 또 하나 하기 위해서
아 뭐 프로파일 빌드 그러니까 릴리즈 빌드 위에 속도만 
잴 수 있는 그런 프로파일러(Profiler) 달아 논거?
그리고 심지어는
이렇게 하면 디버그 빌드 아까 최적화가 안 되어 있다고 했잖아요.
디버그 빌드는 최적화가 안돼어 있으니까
이거를 조금 빠르게
그러니까
빠르게 실행이 되면서도
디버그를 할 수 있게끔
뭐
패스트 디버거(Fast Debugger) 
이런 거 하나 만드는 경우도 있고
그래서 뭐 여러 가지가 있는데
뭐 솔직히
좀 너무 많고요.
(흐흐흐)
저는 일단 디버그하고 릴리즈 두 개로 얘기를 해볼게요.
일단
디버그 빌드에
문제점은
당연히 속도가 느리다는 거예요.
디버그 빌드에서 정말 온갖 어썰트 넣고
뭐....
이런저런 체크하면 엄청나게 느려지는 거는 맞아요.
그래서 이제 게임..
어떤 경우에는 그런 경우도 많아요.
디버그 빌드가 너무 느려서
게임을
실제 실행할 수가 없다.
그러니까 개발 중에 실제 게임을 뭐 해보면서 해봐야 하는데
뭐 초당 1 0프레임도 안 나온다.
이래서
상당히 많은 수의 개발자들이 릴리즈 빌드에서 거의 게임을
개발을 해요.
되게 웃기는 건데 그런 경우가 상당히 많아요.
그러다가
어느 순간
이....
뭐 릴리즈 빌드에서 뭐 예를 들어서 게임 플레이 프로그래머가 이런 거 저런 거 만들어 놓고
어 너 된다고 체크인을 했어
근데
디버그 빌드를 딱 빌드 해 놓는 순간
이게 빌드가 안 되는 경우도 있어요.
근데 뭐 이런 거야 이제 뭐
컴..
뭐라 그래 빌드 서버에서 잡아주니까 상관은 없고
더 큰 문제는
가끔 릴리즈 빌드에서 이게 실행이 빠르니까
아 어떤 뭐 자료를 로딩할 때
이 자료가 로딩이 된 후에 액세스(Access)를 해야 하는데
그런 걸 제대로 안 해두고
아 자료 로딩하는데 0.1 초 밖에 안 걸렸으니까
아무 문제없겠지. 계속 쓰기 시작한 거예요.
아무 문제가 없어 릴리즈 빌드에서
근데 디버그 빌드에서는
자료를 로딩하는 게 
그 2초가 걸리는 거예요.
근데 다음 코드는
아... 0.5초에 실행이 되는 거야.
그러면 아직도
자료가 로딩이 안 됐기 때문에
그걸 액세스 해서 널(null)포인터 에러가 난다든가 
이런 타이밍 적 에러가 많이 나요.
크래쉬(Crash)도 많이 나고
에러(Error)가 아니라 
거의 크래쉬(Crash) 수준이죠.
재가 그런 거를
(Error)
되게 많이 봤거든요
EA에서
그래서
물어봤죠.
디버그 빌드 아무도 안 쓰냐고.
아무도 안 쓴....
안 쓴다고 그러더라고요.
가끔 쓸 일 있으면 그때 고쳐 쓴다고
근데..
회사가
크면 문제가 뭐냐면
상당히 많은 수의 라이브러리가 있어요.
컴포넌트가 있고
그 그 수만은 라이브러리와 컴포넌트에서
내가 정말 모르는 부분도 있거든요.
이거를 정말 디버그 빌드가
빌드가 안될 때
이거를 고쳐 쓰기가 상당히 힘들 때가 있어요.
정말 이해도 안 되는 코드도 가끔 있고
뭐 이상한 라이브러리에 라이브러리를 참고해 가지고 
심지어 내가 뭐 소스코드도 없는 경우도 있고
그래서 그런 거를 보면서
저는 디버그가 되게 힘든 경우가 몇 번 있었어요.
몇 번을 꼭 디버그 빌드를 꼭 썼어야만 했는데
릴리즈 빌드
릴리즈 빌드에서 전혀 디버깅이 너무 어려워서
오히려 디버그 빌드로 가는 게 더 어려워서
결과적으로는
어떻게든 릴리즈 빌드에서 해결하려는 하는 경우도 
몇 번이나 있었고
또 코드 베이스가 방대하다 보면 
디버그 빌드를 한번 빌드하는데 막
30분 40분 걸리기도 하거든요.
또 그런 것도 문제가 있었고
그래서
저는
어찌 보면은
가장 최악인 경우가
그 회사였고
정말
디버그 빌드를 가장 유지를 잘했던 회사가 
 저는 캡콤(Capcom)
그러니까 그때는 블루 캐슬 게임즈(Blue Castle Games)에서 다닐 때였죠.
지금은 캡콤이 됐지만
거기가 정말 디버그 빌드 유지를 잘했어요.
왜냐면 모든 사람이 디버그에서 솔직히 개발을 했거든
그래서 재가 이제 첫 번째 하고 싶은 말은
디버그 빌드.........는
유지를 반드시 해야 돼요.
릴리즈 빌드에서 주로 개발자 개발하든 말든 간에
디버그 빌드는 언제나 컴파일되고 
언제나 실행이 되고
그게 뽀개 졌다면
그거를 뽀갠 프로그래머가 곧바로
고쳐야 되죠.
가장 최우선 적으로
그래야만 다른 사람들 정말 디버깅할 중요한 일 있을 때
안 떨어..
아.. 뭐라 그래요.
(--
--)
긴 시간 낭비 안 할 수 있게 좋은 거고
이게 첫 번째 문제예요.
두 번째 문제는 다른 게 뭐냐면
그럼 사람들이 왜 디버그 빌드를 안 쓰냐는 문제가 있어요.
느리기 때문이죠.
그러면 두 번째 문제는 디버그 빌드를
빠르게 만들어야만 해요.
사실은
그러면 어떻게 빠르게 만드냐
그것도 좋은 얘기죠.
어떻게 빠르게 만들지?
그래서 이제 상당히 많은 수들이 이제 
아까 말씀드렸듯이 했던 게
아....
디버그
아 패스트 디버그 빌드를 많이 만든다는 거죠.
실제 뭐 컴파일은 다 되지만
아... 디버그 정보 다 있지만
최적화를 조금 켜가지고 
그래도 빨리 돌게 하는 거
그런 방법도 있고요.
아니면은
그 뭐라 그래
각 부서별로
이제 그 디버그하고 릴리즈 빌드를
자기 컴퓨터에서 설정을
자동적으로 해주는 게 있으면 좀 더 좋죠.
예를 들어서
저희가 지금 렌더링(rendering) 프로그램 쪽이면 기본적으로
렌더링만 디버그를 돌리고 나머지는 릴리즈 돌려도 크게 
상관이 없지 않냐 시스템이나 렌더링만 디버거로 돌리고
나머지를 뭐 릴리즈로 돌린다던가
게임 플레이 팀에서라면
아........
렌더링이나 시스템 쪽엔 굳이 뭐
디버그 빌드를 돌릴 일이 사실은 거의 없죠 
뭐 그쪽에선
돌리다가 뻑이 나면은 그때 저희 잡아가지고 
뻑이 난다고 얘기를 한다는 게 조금 문제긴 한데
그래도 모르겠어요. 그거를
적당히 키고 끄는 옵션이 있으면 좋고요.
아니면 어써트(assert)를 좀 효과적으로 여기저기 제거하는 것만으로도 효과가 있는 경우도 있고
아니면은
뭐
디버그 빌드에서 어써트를 끄더라도
그게 로그로 나오면은 솔직히 크게 문제 안돼잖아요.
콜 스택(Call stack) 못 보는 거만 문제지
그런 것도 좀 꼼수를 생각해 봐야 되는 건 있고
근데 그것도 완벽하진 않죠. 사실
예
저는
모르겠어요
저는 언제나
디버그 빌드를 잘 쓰는 편이거 든요. 사실은
왜냐 하면은 렌더링 쪽은 뭐
어찌 보면 두 개의 레이어가 따로 있어요.
렌더링은
왜냐하면
C++ 코드 쪽에서 디버그를 열심히 돌려도
저희가 느려질 수 있는 경우는 그렇게 많지 않아요.
근데
그게 아니라 실제 GPU 들어가는 부분에 이제
다이렉트3D(Direct3D, 디렉트3D) 런타임이 있잖아요.
이것도 디버그 릴리즈 빌드가 있는데
이거는 전혀 저희 코드 하고는 상관없이
아...
다이렉트X(DirectX) 컨트롤 패널에 들어가서
수정이 가능한 거예요.
그거를 릴리즈로 만들면
빨라지고 디버그로 만들면
느려지고 이런 게 있기 때문에
근데 뭐
렌더링 쪽에서는 크게 디버그 빌드가 
느리다는 생각을 하지 못했어요.
그.......
다이렉트X 런타임(Runtime)을 디버그를 쓰더라도
그래서 그거는 문제가 없는데 게임 플레이 쪽이 가장 큰 문제일 거 같아요.
제 생각에는
프레임 속도 안 나오고 그러면 문제가 되니까
그런 사람들 디버그는 아까 말씀드린 대로
패스트 디버그
그 패스트 디버그 쓰는 게 거의 유일한 해결방법이지 않나 
그렇게 생각하고요.
뭐 더 좋은 방법이 있으면 누군가 알려주시겠죠.
그러고 지금 이제 다이렉트 3D얘기가 나왔으니까 
또 한마디 할게요.
그러니까 아까 말씀드린 대로 다이렉트3D는
런타임 자체가 디버그하고 릴리즈가 있고
이거는 저희 코드
짠 디버그 릴리즈 그거 하고 상관이 없이 
변환이 가능해요.
스위치가 가능해요.
굉장히 좋죠!!
여기서 단점이 하나 있어요.
대부분의 사람들이
그냥
다이렉트3D를 릴리즈를 켜놓고 쓰거든요.
뭐 빠르고 에러도 쓸데없이 덜 주고 이러니까
근데
어느 순간 이거를
디버그로 돌려서 디버깅을 해야 될 때가 있어요.
뭐 메모리 릭(memory leak) 문제가 발생할 때도 있고
참조 카운터 뭐 그런 거도 있고
그래서 이걸 딱 디버그로 돌리는 순간
상당히 많은 수의 워닝(warning)하고 에러가 뛰쳐나오는 경우가 있어요.
그게 그 뛰쳐나올 때마다
아.. 브레이크를 걸 수 있거든요.
근데 렌더링이라는 게 그렇잖아요.
매 프레임 한 번씩 뭐 똑같은걸 한 번씩 계속 그려 주는 거잖아요.
그거
그런 브레이크가 나기 시작하면 매 프레임 나요.
거의 디버깅이 불가능할 정도로 매 프레임마다 나는 경우가 있어요.
아니면은 백번 이백 번씩 나는 경우도 있고 
한 프레임마다
그러면 그거 F5 눌러서 가기도 어렵고
그래서 또 한 가지 그래픽 프로그램에서 
추가하고 싶은 얘기는
그래픽 프로그래머들은
반드시
실행 타임 그러니깐 런타임
다이렉트3D 런타임을
디버그를 두고 하셔야 될 거 같아요.
속도상에는 크게 차이가 없어요. 
개발 중에 사실은
근데 이제 보통
최종
개발 머신에서 다른 게임도 많이 하잖아요.
그러면 그때는 이제
아무래도
속도가 조금 느린 것도 있고.
그 게임 자체가 다이렉트3D
디버~~~
디버그~~~
런타임에서 제대로 개발 안 한 것도 많기 때문에
그런 부분에서 조금 딜레이가 걸리는 경우가 있어요.
그게 조금 느려지고 약간식 느려지는 게 보이니깐
그거때문에 릴리즈를 켜놓고 게임을 많이 하시는데
사실은 그래야 하는 거고
근데 개발하시는 분은
그거 반드시 디버그로 돌려놓으세요.
왜냐하면
자기가
그래픽 프로그래머
자기가 코드를 짜다가 깜박 잊고
뭐...
뭐 안 한 게 있을 수도 있죠. 뭐 카운..
레프 카운트를 안 줄여 줬다 거나 아니면
이 함수에서 이런...
파라미터(parametar, 패러미터)가 안 들어가야 되는 건데 잘못 넣었거나
릴리즈 빌드에선 그런 거 워닝 에러 잘 안 해줘요.
근데 디버그 빌드에선 내주거든요.
그래서 근데 릴리즈 빌드에서 할 때는 잘됬어.
그럼 어 잘 되는구나 체크인을 한 거야
소스코드에 아니 소스 컨트롤 시스템에
근데 나중에
다른 사람이 한창 그러다가 어 그래 이거 뭐 디버그 할거 있으니까 레프 카운트가 좀 이상한 거 같으니까
디버깅하자고 딱 키는 순간
그 디버그 에러가 엄청 나오는 거예요.
워닝 하고 에러가 도저히 다른 거 디버깅을 못할 정도로
그럼 그거 다 고쳐야 하거든요 누가?
근데
이미 다른 사람이 한 달 동안 한걸 내가 고치는 것보다
내가 오늘 한 거 딱 에러 났을 때 고치는 게 훨씬 빨라요.
그래서 그렇게 돼야만
정말 팀이 일할 때 너무나 편하거든요.
그게 아니고 자꾸만
다른 사람이 만든 거에서 버그가 자꾸만 나오면 부주의한 거로
그 개발 문화 자체로 저 사람을 욕하게 돼요.
저 새끼는 왜 저래 이러면서
그리고 그렇게 서로 욕하는 문화가 생기고 남 탓하는 문화가 생겨버리면
개발팀이 상당히....
힘들어져요.
개판이 돼요.
그래서
저희도 똑같은 맥락으로 .....
그런 것도 있더라고요.
이제 어떤 개발 회사나 개발팀을 보면은
부서 간에 막 욕하는 게 되게 많은 거
저 그런 거 별로 안 좋아해요. 
그래서 그런 건 말 그대로
그냥
그냥 잘못된 건 내 탓이 아니라 남 탓이다
 그런 개념이 강해요.
그리고 남 탓이니깐 내가 할 일은 없고
쟤네가 망치는 거야 나는 제대로 했어
그런 얘기를 하는 거죠.
그 게임 망했을 때도 그런 얘기를 하잖아요.
프로그래밍은 좋았는데 기획이 나빴다 라던가
이제 뭐 저도
한두 번 얘기했던 거예요. 
사실은 스페이스 마린에 관련해서
근데
가능하면 그 얘기를 안 하려고 하는 얘기가
제가 그 기획이 나빴다는 거는
당연히 그 기획자의 문제일 수도 있는데
그거를
한 팀의 일원으로서 게임팀의 일원으로서
제가 어떻게든 피드백을 줘서 고쳤어야 하는 거죠.
재가 정말 그게 잘되기를 원했으면
그런데 저는
개인적으로 게임 기획을 못한다고 생각을 해요.
내가 저는 게임을 많이 하는 편도 아니고
게임을 실제로 해보지 않으면 
이게 재미있는지 재미없는지도 몰라
재미없어도 뭘 더 해야 재밌는지도 몰라
저는 기획능력이 상당히 부족하다고 생각하는 편이기 
때문에 제가 그러를 많이...
못한 거에 대한 아쉬움은 있죠.
내 일은 했지만
팀에서 봤을 때 내 일을 전체를 안 했다는 그런
책임감도 있기 때문에
그런 거는 조금 자제하려고 해요.
그래서 어찌 보면은
프로그래머 부서끼리도 서로 싸움이 날 수도 있는 게 
그런 거거든요.
이젠 아 저 팀은 맨날 부주의해서
디버그 빌드 신경도 안 쓰고 넣어가지고 맨날 저 새끼 들 꺼 받아오면은
저쪽 라이브러리에서 맨날 뻑난다.
맨날 크래쉬 난다.
이런 거는
팀을 와해시키는 아주 지름길이죠.
그래서 그런 거를 피하기 위해서라도
내가 쓰는 코드만은
디버그 빌드에서 잘 돌고 릴리즈 빌드에서도 잘 돌고 
둘 다 잘 돌게 해야 되고
아.. 다이렉트3D 런타임 할 때도 그래야 한다는 거를 
말씀을 드리고 싶어요.
프로그래머 같은 경우는 할 일이 두배로 늘어난 거죠.
그러니깐 그래픽 프로그래머 같은 경우엔
할 일이 두배로 늘어난 거예요.
디버그 빌드 C/C++ 확실하게 잡아줘야 되고
어... 다이렉트3D에서도 확실히 문제없이 
돌아가게 해야 되고
일단 뭐
디버그 빌드 잘 유지하자
그게 시간 팀의 시간을 낭비하게 안 하는
방법 중에 하나다. 그리고
팀.....
팀..........
팀...............
팀....................
팀 스피릿? (Team Spirit?)
팀 워크?(Teamwork?)
그거를 이제 유지하기 위해서도 좋은 방법이다.
라고 말씀을 드리고 싶어요.
에......
에...... 또?
그 정도면 된 거 같아요.
예 포프였습니다.