어긋남을 찾아 고치기, 디버깅

멈춘 자리를 알려줘요

프로그램이 어긋나면
조용히 죽는 게 아니라 한 자리에서 멈춰요.
그리고 손가락으로 가리키죠. '여기, 이 줄.'
그 가리킴이 가장 값진 첫 단서예요.
에러는 '어디서' 멈췄는지부터 알려 줘요.

실행을 눌러 보세요. 단계가 차례로 켜지다 어긋난 자리에서 딱 멈춰요.

어디서 멈췄는지 한눈에 보이죠.
이제 그 자리에 빨간 글씨가 뜰 거예요.
많은 사람이 그 글씨를 보면 덜컥 겁부터 먹어요.
그런데 그건 사실 우리 편이에요. 왜냐면...

빨간 글씨는 꾸중이 아니라 힌트예요

그 빨간 글씨는 우리를 혼내는 게 아니에요.
'무엇을 이해 못 했는지'를 적어 주는 쪽지죠.
보통 두 가지가 들어 있어요. 자리(어디)와 종류(무엇).
'이건 숫자가 아니에요', '그런 이름은 없어요'처럼요.
차분히 읽는 법만 익히면 절반은 푼 거예요.

메시지 조각을 눌러 보세요. '어디'와 '무엇'이 따로 빛나며 풀려요.

메시지를 '어디'와 '무엇'으로 갈라 읽으니
무섭던 글씨가 갑자기 친절해 보이죠.
그런데 메시지가 가리키는 자리가 늘 진짜 원인은 아니에요.
긴 프로그램이라면, 원인을 어떻게 빨리 좁힐까요?

범위를 반씩 좁혀요

버그가 어디 있는지 모를 땐
처음부터 다 읽지 말고 가운데를 봐요.
여기까진 멀쩡한가? 그렇다면 버그는 뒤쪽 반에.
아니라면 앞쪽 반에 있죠. 다시 반으로.
이 '반씩 좁히기'면 긴 줄도 금세 범인을 찾아요.

'가운데 확인'을 눌러 보세요. 멀쩡/문제에 따라 범위가 반으로 줄어요.

몇 번 누르니 범위가 한 자리로 좁혀졌죠?
전체를 다 안 봐도 범인을 콕 집었어요.
이제 원인 자리를 찾았으니 고칠 차례예요.
그런데 고칠 때 한 가지 함정이 있어요.

한 번에 하나만 바꿔서 확인해요

원인 같은 게 보인다고 한꺼번에 다 손대면 안 돼요.
다섯 군데를 동시에 바꾸면,
고쳐져도 어느 게 고친 건지 알 수가 없어요.
새 문제가 생겨도 누구 탓인지 모르고요.
그래서 하나만 바꾸고, 실행해 보고, 살펴요.

후보를 하나만 바꿔 '확인'해 보세요. 여럿 바꾸면 무엇이 고쳤는지 흐려져요.

하나씩 바꾸니 무엇이 진짜 원인이었는지 또렷하죠.
범인을 정확히 알았고, 고쳤어요.
그럼 이제 끝난 걸까요? 아직 한 걸음 남았어요.
'고친 것 같다'와 '고쳤다'는 다르거든요.

고친 뒤엔 꼭 다시 돌려 확인해요

고쳤다는 생각만으론 끝이 아니에요.
다시 실행해서 끝까지 통과하는 걸 두 눈으로 봐야 끝이죠.
덤으로, 멀쩡하던 다른 곳이 망가지진 않았는지도 봐요.
이 '고치고 다시 확인' 한 바퀴가
어림짐작과 진짜 고치기를 가르는 선이에요.

'다시 실행'을 눌러 보세요. 고친 프로그램이 끝까지 초록으로 통과해요.

이제 우린 만들 줄도 알고(1~13강),
어긋났을 때 찾아 고칠 줄도 알아요(14강).
그런데 우리가 쓴 이 글자들은
어떻게 진짜 기계가 돌리는 것이 될까요?
다음엔 그 글이 기계의 일이 되는 길을 따라가 봐요.