-
Notifications
You must be signed in to change notification settings - Fork 10
/
0326.txt
279 lines (279 loc) · 16.7 KB
/
0326.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
안녕하세요 포프입니다.
예전에 한 번 비디오에서
디버깅이 개발의 반이라고 이야기를 했던 적이 있어요
그러고 나서 이제 또
다양한 사람들과 일을 해봤는데
요즘 드는 생각은
디버깅이 절반 이상인 것 같아요
거의 75프로나 85프로가 되지 않나 생각을 하는데
이제 그 이유를 곰곰히 생각을 해 보니까
디버깅 이라는 게 단순히 버그를 잡는 문제보다는
몇가지가 더 있더라고요
일단은 다른 사람의 코드를 이해를 할 수 있느냐.
왜냐면
제가 만든 코드만 이해하는 거 아니잖아요
남이 만든 코드를 봐서 거기서 버그를 고쳐야 할 때도 있고
아니면
아니면, 뭐라 그럴까
내가 직접 코드는 했지만 누군가가 만든 함수 쓰는데 뭔가 이상할 경우
그 함수
그 함수 에 이상한 동작을 어떻게 바꿀 수가 없으니까
제대로 쓰는 법도 저는 디버깅의 과정이라 생각을 하거든요
그래서
어찌보면은
뭐라 그럴까
테스트 까지도 같이 하게 되는 것 같아요
어떤게 제대로 작동을 하냐 안하냐 테스트를 하는 과정에서
아 요거는 작동하고 요거는 작동 안한다
근데 워낙 어떤 함수든 어떤 기능이든
인풋은 수만개가 될 수 있잖아요
그러면 그 수만개의 인풋중에 과연 어느정도를 내가 테스트 했을 때
이게 이거에서는 제대로 작동하고 딴거에서는 작동을 안 할 수 있느냐는 걸
확신을 할 수 있느냐는 것도 어찌보면 논리력이기도 하거든요
음...
그리고 전에 제가 항상 얘기했지만
어떤 문제가 발생을 하면은
문제의 현상을 해결하는 것 보다
그 문제가 발생한 근본적인 원인을 찾아서 고쳐야만
아까 제가 말했던 방금전에 말했던
얼마나 테스트를 해야 이게 올바르게 돈다고 생각할 수 있을까 여기까지 들어가는 것 같아요
또 그런 생각을 하고
다시 처음에 들었던 남의 코드를 이해할 수 있어야 한다로 잠깐 돌아가면
어찌보면은
제가
코딩을 잘하게 된 계기도
남의 코드를 보고
저는 보고 공부하고 분석한다 이런 말 안 좋아해요
어차피 그래봐야 집중 안할 거 뻔하니까
그 남의 코드에서 일하게 되면서 그 코드 고치고 잘못된 거 찾고 그러는 과정들?
그리고 남의 코드 보자마자
물론 되게 단순한 거면 금방도 이해가 되지만
전체적인 시스템을 여러번 사용을 하면서
점점 전체 시스템이 어떻게 돌아가는지 서로 맞물려서
그걸 이해하는 데 까지 조금 시간이 오래 걸리기도 해요
뭐 2주가 걸리기도 하고 두달이 걸리기도 하고
근데 저는 이제 운이 좋았던지 아니면 제가 워낙
뭐랄까 참을성이 안 좋아서 여러 회사를 돌아다녔던 건지는 모르겠지만
제 생각에는 정말 세상에 존재하는 게임엔진의
대충 패턴들이 있을 거 아녜요 사람들이 생각하는게 그래도
다들 똑같지는 않지만 열개 열두개를 똑같다고 보면은
그런 패턴을 다 봤고 그런 패턴에서
일을 해봤고
그래서 이제는 어떤 뭐 게임엔진 코드건 솔직히
괴랄 스러운 건 없어요
보면 아 이런 거구나 이런 거였구나 저거랑 비슷했구나
그러면서 그 코드 내부가 왜 어떻게 돌고
그 프로그래머가 어떤 생각을 하고 코드를 짰는지를 아니까
디버깅도 빨라지는 것 같아요
저는 이제 뭐 어쩔 수 없이 여기저기서
새로운 회사 돌아다니면서 일을 하다 보니까
새로운 코드 접하는 속도가 빨라졌고
그로 인해 디버깅을 잘하게 된 거라고 보는데.
어쩌면 그 디버깅을 잘한다는 거 자체가 역시
코드를 잘 이해한다는 것일 수도 있고
코드를 아까 말했듯 잘 이해할려면은
그 말했잖아요 얼마나... 뭐랄까
가장 근본이 되는 것을 이해하지 못하면
곁가지 백날 이해해봐야 나중에 새로운 거 나오면 틀리기 때문에 그런 부분이 있었어요
근데 재미있는 건
참고로 하나 말하고 싶은 건 Printf() 는 절대 디버깅은 아니예요
근데 디버거 툴이나 그런게 후진 환경에서는 그런 걸 써서 디버깅 할 수 밖에 없죠
이미 뭐 Printf()로 디버깅 하는 시절은
벌써 30년은, 30 40년 정도를 지났다고 봐야 정상인거 같은데
그뒤에 굉장히 많은 훌륭한 회사들이 좋은 디버거를 만들었어요
그 디버거를 저희가 쓰면서 개발을 하고 있고
근데 그 디버거를 사용하지 못하는 사람들은
디버깅 속도가 떨어질 수 밖에 없죠
왜냐면 무슨 문제가 있을 때
디버거가 단순히 후지기 때문에
라이브 서버에서 디버거를 쉽게 못 쓰기 때문에
printf()로 로그찍고 나중에 로그분석하고 이게 틀렸구나 라고 하는 경우가 있거든요
근데 문제는 로그는 미리 안 넣어놓으면 나중에 또 넣고 디플로이 한 다음에 다시 봐야되는 그런 문제들이 있는데
음...
일단 게임 쪽에서는
요즘은 디버깅이 굉장히 x5 편해졌어요
한 10년전만 해도 괜찮은 툴들이 많이 나왔고
한때 소니가 독주하던 때에는 괜찮은 툴들이
없던 경우가 있어서 굉장히 이상한 디버깅을 하게 되고
그리고 어떤 경우에는 디버깅 정보가 없이 디버깅 해야 될 때도 있어요.
그 때 가면은 단순히... 아니 여러 단계가 있는데
일단 툴을 못쓰는 사람들은 제가 볼 때는 절대 디버깅을 할 가능성이 없고
잘 할 가능성이 없고
두번째는
이제 툴을 사용할 수는 있는데 툴을 못 사용하게 할 경우에
과연 디버깅을 잘 할 수 있는 사람이 얼마나 있을까
그럼 이제 아까 말했던 것 처럼
printf() 등에 의존하는 거거든요
옛날에 소니쪽 독식하던 때니까, 플스2 정도 때에는,
그런 디버깅 툴이 제대로 돌지 않는 상황에서 디버깅 해야 됐을 때가 있었어요.
물론 개발 도중에는 디버깅 툴 다 쓰지만
저희가 되게 재미있는 에피소드 하나 들려 드리면
예전에 ps2 같은 경우에는
피씨를 꽂고 뭐하고 개발을 하고 디버그도 대충 할 수 있었지만
결과적으로 최종적으로 제품이 나갈 때는
CD에 구워서 제품을 만들어야 됐어요
CD로 굽는순간 여기에는
뭐랄까, 어떤 디버그 정보도 없어요
심지어는 그 당시에는 cd로 구웠을 때는
디버그를 어태치해서 어셈블리로 보는 방법 밖에 없었거든요
어셈블리 수준의 디버깅도 불가능한 상태였어요.
printf도 불가능한 상태였어요. 왜냐면
printf를 하는 거 자체가 cd를 굽는 버젼이 아니고,
cd굽는 버젼에 그런게 들어가면 무조건 소니에서 리젝트를 해버리거든요
저희가 가지고 있었던 건 순수 cd였는데
재미있는 건 여기서 언제나 나는 버그가 하나 있었어요
근데 이거를 CD를 안 굽고
릴리스 빌드로 구워서 디버깅 하던,
로칼에서 빌드를 해서 디버그 버젼을 디버깅 하던
절대 나지 않는 버그였어요
c나 c++쪽에서는 메모리 레이아웃이 약간 바뀌면서 메모리 스톰프가 사라질 수도 있고
아니면 타이밍이 달라서 생기는 버그일 수도 있거든요
그 순간에
저희가 아 이거 디버깅 어떻게 할까
고민하다가
결과적으로 한 방법이 뭐냐면
어찌보면 printf를 굉장히 익스트림하게 올린건데
저희가 그당시에 할 수 있었던 방법은
화면에 그림은 그릴 수 있었어요 게임이니까
그래서 저희가 궁금했던 변수값들 있잖아요
변수가 이렇게 바뀌면 문제가 되겠구나
printf랑 되게 비슷한거죠
그런 변수값을 화면에 출력을 해야 되는데
이게 텍스트로 출력하는 순간에 뭐랄까 텍스트 랜더러 들어가고 거기서 폰트 불러오고 이런 이상한 짓을 해야됐어요
그래서 그 순간 굉장히 많은게 또 망가지거든요
저희가 할 수 있던거는 이 변수를
화면 왼쪽 제일 구석에 넣어놓고
이 변수의 값이 바뀔 때 마다 이를 색깔로 표시하던 때가 있어요
요 변수값이 이거야 하면 빨간색 가장 강한거, 이 변수값이 이거면 약간 그린 20% 이런 식으로
보고 싶은 변수를 상태를 픽셀마다 해서 밑에 쫙 박아두고
그걸 열개 이십개 박아두고
게임 진행되는 거 보면서
깨지기 전에 이 변수값들이 어떻게 되나
그렇게 해가지고 결과적으로는 잘못된 문제를 찾아서
고친 적이 있어요
이렇게 얘기하면 되게 printf랑 같지 않나 라고 솔직히 얘기를 하는데
결과적으로는 그렇거든요 모든 툴이 없을 때는 printf로 갈 수 밖에 없는데
저는 되게 재미있었던 게 뭐냐면
디버깅 툴들은 이렇게 printf로 할 수 있는 일들을
실행중에 브레이크 포인트 걸고 변수값들 변하면서 걸고
함수 호출이 어디로 가는지
이런 걸 보여주는 툴이잖아요
그런거에서 습관이 어느정도 잘 들면은
일단 디버그 툴들이 제공하는 기능들이니까
여기서 어떤 어떤 것들을 봐야만
어떤 버그를 잡을 수 있다라는 걸 되게 쉽게 알수가 있어요
그럼 이제 그게 툴을 걷더라도
툴에서 미리 해주던 일을
여기서는 이 함수가 호출되는지 봐야 하니까 그걸 픽셀로 하나 받고
여기서는 무슨 변수값을 바꾸는 걸 봐야 하니까 그거도 픽셀로 받고
이런 식으로 해서 툴이 해주던 거를 조금
뭐랄까 열배 스무배 느리게 할 수 밖에 없지만
그걸 화면에 찍고 볼 수가 있다는거죠
이게 반드시 논리적으로 맞냐 틀리냐는 모르겠는데
제가 여태까지 봤던 거 중에는
훌륭하게 디버깅을 잘 하는 사람들은
툴을 되게 잘 써요. 그 이유가 제 생각에는
그사람들이 printf로만 디버깅을 하기에는 그사람들의 생각속도가 너무 빠른 거 같아요
자기가 실제 버그를 잡는 속도를 도와줄 수 있는 툴을 쓴다는 게 첫번째 인 것 같고
그 툴조차 안 쓰는 사람들은 굉장히 많은 경우가
생각이 그냥 느려요
디버깅을 잡고 이거이거 봐야 하는데
printf 한번 찍고 빌드 한번 돌리고
또 prinf 한번 찍고 빌드 한번 돌리고
이런 개념으로 가니까
하나하나 확인하는게 툴로 하면 1분, 30초에 확인할 것을
이사람들은 30분 40분에 확인하는 경우가 있다, 30분은 좀 그렇고 10분?
그 정도에 확인하는 경우가 있다는거죠
그래서 그런 사고의 흐름 자체를
원래 느린건지 도구를 제대로 안 써서 느린건지 모르겠지만
그렇게 느린 부분이 있고
그리고 툴을 잘 쓰는
사람중에서 나중에 툴을 걷었을 때
이 사람들이 처음 말했던 printf를 쓰는 사람들만큼은 잘하지만
제가 아까 말했던, 화면에 점을 찍어가면서까지 뭔가를 볼려고 하는 그런
생각까지 다가갈 수 있는 사람은
생각보다 그렇게 많지는 않았어요
어찌보면 되게 창의적인 디버깅이라고 할 수 밖에 없거든요
흔히 보던 printf 달고 브레이크 포인트 달고 뭐 이정도 수준이 아니라
지금 도는 환경에서 어떻게든 상태를 볼 수 있는 방법을 만들겠다죠
이걸 소리로 만들고 싶으면 소리로 만들 수 있겠고
아까 말했듯 픽셀로 만들려면 만들 수 있겠죠
그리고 이 중간에 있는 것 중에 하나가 어셈블리 기능이예요
어셈블리 디버깅이
또 두가지가 있어요 제가 보기에는 그냥
코드를 브레이크 포인트 걸어놓고 어떤 어셈블리가 실행되는지 본 다음에
그걸 생각하면서 하나하나 따라가는 방법이 있고
아니면 거기에 레지스터 값이나 이런 게 있거든요
그럼 레지스터 값이나 메모리 값을 실제 메모리 뷰를 봐가면서
아 여기 어떤 데이터가 있구나를 수치로 보는 경우가 있고
그 외에는 툴 같은게 잘 진행이 되면은
잘 지원이 되면은, 비쥬얼 스튜디오 같은 쪽의
그 레지스터에 있는 값을 그냥
특정 오브젝트로 캐스트 한 다음에
그럼 오브젝트의 레이아웃은 알려져 있으니까 메모리 레이아웃은
그러면 거기에 들어간 필드가 어떤건지 빨리 보는 방법도 있거든요
근데
이제
결과적으로는 모든게 디버깅하려면 어셈블리 내려가고 아까 말했던 픽셀 디버깅 까지 가야 되지만
툴을 잘 사용하는 사람들은 이거를 굉장히 빠르게 할 수 있다는 거예요 툴의 기능을 이용해서
이게 참
양쪽의 진영으로 갈려져 있다는 것도 되게 웃긴데
툴을 쓰는 사람들은
이 처음에 시작할때 양쪽진영이 printf와 툴을 쓰는 상황
툴을 잘 쓰는 사람들은 printf쓰는 사람들 쪽도 이해하고 잘 할 수 있어요 그건 확실해요
그런데 이 처음 시작점이 아니라 나중에 내려가면
정말 괴랄스러워지는 디버깅 까지 가면은
printf를 그냥 쓰는 사람
이나 그사람들보다 툴을 쓰는 사람이 조금은 나은 것 같은데
그 다음에 창의적인 디버깅을 할 수 있는 생각은
단순하게 디버깅 하는 거 이런 거 발달하는 게 아니라
예전에도 흔히 말했던 컴퓨터 내부 구조를
되게 잘 알고 하드웨어를 알지 않으면 되게 하기 어려워지는 부분 같아요
그런 생각이 들고
요즘 드는 생각이 그거여서 비디오로 만들어 봤어요
디버깅이 반이라고 했는데
솔직히 디버깅에 코드를 배우는 능력까지 포함을 시키면
이건 반 이상이 되지 않을까, 그리고
저는 언제나 학습의 기본이 모방을 하고 남이 하는 걸 보고 배워서 학습이 된다고 생각하는 스타일이기 때문에
그렇게 생각하면
코드보고 디버깅해보고 뭐하고 이러는게
음...
훈련을 통한, 남의 코드를 익히는 걸 되게 돕는 것 같고, 배우는 걸
그리고 우리가 가끔 말하는 이론적인 거
되게 중요한 거긴 한데
이거는 제가 볼때는
우리가 교육을 되게 잘못하고 있는 것 같아요
이론적인 걸 배우는 시점자체가 잘못되지 않았나 하는 생각을 되게 많이 해요
어느정도 코딩에 손이 오르고 남의 것을 흉내낼 수 있고 자유롭게 마음껏 할 수 있을 정도의
이론을 배우면서 자리를 잡으면서
이게 좀 더 이렇게 이렇게 하면
뭐랄까 좀 더 유지보수 가능한 코드가 나올 수 있다라는 그런 가능성을 보면 좋은데
코딩을 할 줄도 모르는 사람들에게 이론부터 가르키면 얘네들은
왜 필요한지도 모른채 이론을 배우고
그거가 유일한 방법인양 따라가는게 뭔가 잘못된 것 같아요
아직까지도 누군가가 저에게 묻는다면
코드만져보고 디버깅하는게 처음 시작할때는 제일 중요한 것 같고
그다음에 1,2년이 지났을 때
경력말고 코딩을 한게 1,2년이요
그 때
그때쯤에 이론을 좀 올려서 한단계 업그레이드 하는 게 더 좋지 않나 이생각을 하고
그 다음엔 이론이 생각보다 별로 없는 것 같아요
프로그래밍 쪽에서 필요한 이론이
되게 좀 적다고 생각하는 주의기 때문에
굉장히 기본적인 이론을
잘만 이해하면 나머지는 거기서 확장시키고 이해할 수 있는 부분이라고 보거든요
대충 읽고 아 이런 거구나 하고 넘어갈 수 있는
처음부터 너무 공부를 이상하게 한 사람들이
이론을 시작해서 이론의 이유도 모른채 이해도 못한 채
계속 이론만 쌓아가니까
사실은 같은 거에서 조금만 확장된건데 전혀 다른거라고 생각하고 수만가지를
중구난방적으로
다 배우고 어떤 걸 어디에 써야 하는지도 모르는게 좀 아쉬운 거 같아요 그래서
지금 코딩을 하는 사람이 있다면 하고싶은 사람이 있다면
무조건 코드를 만들어 보고
남의 코드 봐보고 디버깅 해보는 걸 먼저하고
그 다음에 어느정도 한계가 온다고 느겼을 때
아니면 내 코드가 너무 드럽다거나 하거나 할 때
그때 한번쯤 제대로 잡아주는게 되게 좋지 않을까 생각을 해요
오늘은 디버깅 이야기를 했습니다.
포프였습니다.