세 명이 만든 세 개의 버그
함께 고치는 법

지난 시간 우리 팀은 처음으로 성능을 쟀습니다. 견본 데이터 158행을 훈련 110 · 테스트 48로 나누고, k를 일곱 개 돌려 k=7에서 85.4%를 얻었지요. 늘 ‘가능’이라고만 답하는 기준선이 60.4%였으니 +25.0%p였습니다.

그다음 시간에 팀은 일을 나눴습니다. 갑은 데이터 설정을, 을은 파이프라인을, 병은 학습 부분을 맡았습니다. 각자 자기 컴퓨터에서 파일을 하나씩 내려받아 고쳤고, 셋 다 “내 쪽은 잘 돌아간다”고 했습니다. 그리고 오늘, 합친 파일을 처음으로 함께 실행합니다.

첫 줄에서 죽었습니다. 그 아래로는 한 줄도 돌지 않았습니다. 어렵게 그것을 고치고 다시 돌리면 이번에는 표가 이렇게 나옵니다.

답을 미리 말해 두겠습니다. 좋은 소식이 아닙니다. 이 파일에는 버그가 셋 있고, 100%는 그중 둘째 버그가 내는 소리입니다. 그리고 셋째 버그는 이 표를 아무리 들여다봐도 안 보입니다. 오늘은 셋을 차례로 잡습니다. 잡는 도구는 눈이 아니라 검사표입니다.

“버그가 셋 있다”는 말은 오늘 배울 것의 절반도 담지 못합니다. 중요한 것은 개수가 아니라 성격입니다. 셋은 서로 다른 방식으로 우리를 속입니다.

세 버그가 이 파일 어디에 있는지도 성격만큼 중요합니다. 셋 중 둘은 함수 안이 아니라 함수를 부르는 자리에 있습니다.

오류가 터진 자리 ≠ 고쳐야 할 자리

ㄱ의 오류 메시지는 minmax_apply를 가리킵니다. 그런데 minmax_apply는 2단원 5차시에서 가져온 함수입니다. 우리가 고칠 곳이 아니에요. 그 함수는 시킨 대로 (v − lo) / (hi − lo)를 계산했을 뿐인데, 마침 hi − lo가 0이었던 것입니다. ZeroDivisionError는 ‘여기가 범인’이 아니라 ‘여기까지 잘못된 값이 흘러 들어왔다’는 신호입니다.

그래서 오류 메시지를 읽는 순서는 이렇습니다. ① 마지막 줄이 무엇이 났는지를 말합니다 (ZeroDivisionError: division by zero). ② 그 위 줄들이 어느 함수를 거쳐 왔는지를 아래에서 위로 말합니다. ③ 그중 ‘우리가 쓴 줄’을 찾습니다. 2단원에서 가져온 함수 안에서 터졌다면, 우리가 그 함수에 무엇을 넘겼는지를 보는 것이 순서입니다.

버그 ㄴ과 ㄷ은 오류를 내지 않습니다. 화면만 보고는 알 수 없습니다. 그러면 무엇으로 잡을까요? 검사로 잡습니다. 검사는 거창한 것이 아닙니다. 한 줄이면 됩니다.

오늘 쓸 파일 맨 아래에는 이런 검사가 여섯 줄 들어 있습니다. 다만 기대값 칸이 비어 있습니다. 오늘 여러분이 첫 5분에 할 일은 그 여섯 칸을 채우는 것입니다. “무엇을 고칠까”가 아니라 “무엇을 기대해야 하는가”를 먼저 정하는 것이지요.

검사값을 잘못 고르면 ‘죽은 검사’가 된다

검사 1을 보세요. 왜 하필 [0,0,3,4,0]처럼 뒤쪽 자리에 3과 4를 두었을까요? 앞의 두 자리에 두면 안 될까요? 실제로 재 보면 이렇습니다.

검사 4의 TINY도 마찬가지로 골라 두었습니다. 점 셋 ([0,0],"가") ([0,1],"나") ([0,2],"나")는 [0,0]에서 가까운 순서가 ‘가’·‘나’·‘나’입니다. 그래서 k=1이면 ‘가’, k=3이면 ‘나’로 답이 갈립니다. 만약 셋 다 같은 이름표였다면 k를 무시하는 버그가 이 검사를 그냥 통과했겠지요.

검사는 뒤가 아니라 앞에 둔다

지금 이 파일의 검사표는 파이프라인 뒤에 있습니다. 그런데 버그 ㄱ이 앞에서 죽여 버리니 검사표는 한 줄도 못 돕니다. 검사 6을 앞으로 옮기면 같은 사고가 이렇게 바뀝니다.

같은 사고인데 읽을 수 있는 문장이 되었습니다. 무엇을 어디서 고쳐야 하는지가 메시지 안에 들어 있습니다. ZeroDivisionError는 그 정보를 하나도 주지 않았지요. 이것이 검사를 앞에 두는 까닭입니다. 뒤에 둔 검사는 앞에서 죽으면 아무것도 지켜 주지 못합니다.

버그 ㄴ은 복사한 두 줄 중 아랫줄에 있고, 버그 ㄷ은 ‘고치지 않는다’라고 적힌 상자 안에 있습니다. 둘 다 혼자 읽으면 눈이 미끄러지는 자리입니다. 사람은 자기가 방금 쓴 줄을 읽을 때 쓴 대로가 아니라 쓰려던 대로 읽거든요. 그래서 오늘은 둘이 한 화면을 봅니다.

막혔을 때 — 사람을 부르기 전에 네 단계

“안 돼요”라고만 말하면 도우러 온 사람도 처음부터 다시 시작해야 합니다. 아래 네 단계를 밟은 뒤에 부르면, 부르는 동안 스스로 답을 찾는 일이 자주 생깁니다.

1. 증상을 한 문장으로 적는다. “k를 3으로 바꿔도 정확도가 70.8%로 똑같다.” — ‘안 된다’가 아니라 무엇이 어떻게 되는지를 적습니다.
2. 어디까지 맞는지 범위를 좁힌다. 분할까지는 맞나? 정규화까지는? 검사표 여섯 줄이 이 일을 대신해 줍니다 — ✘가 뜬 줄이 곧 범위입니다.
3. 오류 메시지를 끝까지 읽는다. 마지막 줄(무엇이 났나)과 그 위 줄들(어디를 거쳤나)을 둘 다 읽습니다. 대부분은 안 읽어서 못 고칩니다.
4. 가장 작은 재현 예를 만든다. 158행이 아니라 세 점짜리 TINY로 줄여 봅니다. 작아지면 손으로 답을 낼 수 있고, 손으로 답을 낼 수 있으면 그것이 곧 검사가 됩니다.

그다음에 사람을 부릅니다. 이 순서를 지키면 부를 때 이렇게 말하게 됩니다 — “k를 바꿔도 값이 같고, 검사 3이 3 대신 1을 냈어. nearest가 의심스러운데 같이 봐 줄래?” 이 한 문장이 ‘안 돼요’보다 열 배 빠릅니다.

갑·을·병은 성실했습니다. 각자 한 시간씩 썼고 각자 버그를 하나씩 잡았습니다. 그런데 셋이 같은 파일을 각자 내려받아 고쳤습니다. 합칠 때 무슨 일이 나는지 재 봤습니다.

그래서 팀에서 일을 나눌 때의 첫 규칙은 이것입니다. 역할을 파일 단위로 나눈다. ‘데이터 담당’·‘모델 담당’처럼 주제로 나누면 결국 같은 파일을 셋이 건드리게 됩니다. 어쩔 수 없이 한 파일을 나눠야 한다면 셋을 지키세요.

1. 고칠 곳을 먼저 말로 나눈다. “나는 【0】만, 너는 파이프라인만, 너는 함수 상자만.”
2. 짧게 자주 합친다. 한 시간 뒤가 아니라 버그 하나 잡을 때마다 합칩니다.
3. 합친 뒤 검사표를 다시 돌린다. 합치는 과정에서 남의 수정이 지워졌는지는 검사표만 압니다. 눈으로 훑어서는 모릅니다.

합치기 전에 서로의 코드를 이 순서로 본다

코드 리뷰라는 이름이 붙으면 거창해 보이지만, 실제로는 여덟 줄짜리 점검표입니다. 오늘 우리가 만난 사고가 그대로 들어 있습니다.

도구는 사다리다 — 그리고 생성형 AI에게 받은 코드

팀이 쓸 도구는 하나가 아닙니다. 티처블 머신 · 엔트리 · 파이썬은 어느 것이 더 훌륭한 도구가 아니라 사다리의 다른 칸이고, 팀의 실력과 남은 시간에 맞는 칸을 고르면 됩니다. 우리는 파이썬 칸에 있으니 그 칸의 규칙을 지킵니다.

막혔을 때 생성형 AI에게 물어도 됩니다. 다만 3단원에서 세운 비판적 자세가 그대로 적용됩니다. 받은 코드를 그냥 붙여 넣으면 안 되는 까닭은 도덕이 아니라 공학입니다 — 그 코드는 우리 데이터를 본 적이 없습니다. 우리 FEATURES에 상수 열이 있는지, 우리 nearest가 이미 망가져 있는지 모릅니다. 그래서 오늘의 검사표가 그대로 답이 됩니다.

1. 돌려 본다. 읽어서 그럴듯하면 통과가 아닙니다. 오늘 버그 ㄴ·ㄷ도 읽기에는 그럴듯했습니다.
2. 검사에 걸어 본다. 여섯 검사를 다시 돌립니다. 통과 수가 줄었다면 되돌립니다.
3. 어디를 어떻게 받았는지 기록에 남긴다. 무엇을 물었고, 무엇을 받았고, 어디를 우리가 고쳤는지를 협업 기록표 한 줄로. 11차시 공유회에서 이 줄이 그대로 근거가 됩니다.

아래 파일이 갑·을·병이 합쳐 놓은 그 파일입니다. 588줄이지만 겁먹지 마세요. 여러분이 고칠 곳은 딱 세 곳이고, 나머지는 6차시·7차시에서 이미 본 골격 그대로입니다. 먼저 이 파일의 지도를 봅시다.

증상은 차례로 드러난다

세 버그는 줄 서서 기다립니다. 하나를 고쳐야 다음 증상이 보입니다. 아래 표는 여러분 화면에 무엇이 나와야 하는지를 미리 적어 둔 것입니다. 화면이 이 표와 다르면 고친 곳이 다른 것입니다.

협업 기록표 — 고칠 때마다 한 줄

고친 뒤에 “고쳤다”고만 말하면 팀의 다른 사람은 그것을 되돌릴 수도, 이어받을 수도 없습니다. 무엇을 · 왜 · 무엇으로 확인했나 셋을 한 줄로 남깁니다. 아래 표는 화면에서 바로 적어도 되고, 공책에 옮겨 적어도 됩니다.

‘무엇으로 확인했나’ 칸에 “돌아갔다”라고 쓰면 안 됩니다. “검사 6이 ✔로 바뀌었다”, “맞힌 수가 110/110에서 34/48로 바뀌었다”처럼 숫자나 판정으로 적으세요. 오늘 이 칸이 곧 10차시 실험 기록과 11차시 발표의 뼈대가 됩니다.

파이썬 파일에서 버그를 하나 고치는 데는 시간이 걸립니다. 아래 사냥터는 같은 계산을 브라우저에서 그대로 돌려, 버그를 스위치처럼 켜고 끄며 증상만 빠르게 견줘 보는 곳입니다. 나오는 숫자는 파이썬이 내는 숫자와 같습니다 — 158행을 110/48로 나누고 k-NN을 실제로 돌립니다.

세 가지로 씁니다. ① 파일이 막혀 있는 팀은 여기서 오늘 몫을 합니다. ② 다 고친 팀은 ‘셋 다 고치기’를 눌러 자기 화면과 견줍니다. ③ 씨앗을 바꿔 가며, 파일 한 벌로는 볼 수 없는 것을 봅니다 — 같은 버그가 어떤 데이터에서는 안 들킨다는 사실입니다.

과제 ① — 네 판을 돌려 표를 채운다

스위치를 아래 순서대로 맞추고 한 판씩 돌려, 공책이나 아래 칸에 옮겨 적으세요. 씨앗은 42로 두고, 검사는 여섯 개를 다 씁니다.

두 번째 줄에서 ‘화면의 테스트’와 ‘실제로 채점한 수’를 나란히 보세요. 두 숫자가 다릅니다. 이것이 정확도 100%보다 확실한 증거입니다 — 100%는 의심할 이유이고, 이 어긋남이 증거입니다.

과제 ② — 반례를 만든다: 버그가 있는데 안 들키는 자리

이제 ㄷ만 켜 놓고 씨앗을 42 · 1 · 2 · 3 · 5로 바꿔 가며 돌려 보세요. ‘정직한 판 겹쳐 보기’를 켜 두면 회색 점선이 정직한 판입니다. 막대와 점선이 같은 높이인 k가 “버그가 있는데 안 들키는 k”입니다. 아래 칸에 그런 k를 모두 적으세요.

다섯 줄을 다 채우면 마지막 칸에서 한 가지가 눈에 들어옵니다. 어느 씨앗에서든 k=1은 늘 안 들킵니다. 그리고 씨앗 하나에서는 k가 하나 더 늘어납니다. ‘재현이 어렵다’는 말은 이런 뜻입니다 — 같은 코드가 어떤 데이터에서는 옳은 답을 냅니다. k=1 하나만 돌려 본 팀에게는 이 버그가 어떤 데이터에서도 보이지 않습니다.

과제 ③ — 검사를 골라 본다

검사표의 ‘쓴다’ 칸을 꺼 보세요. 이 사냥터에서 확인할 것은 하나입니다 — 어떤 버그는 검사를 아무리 봐도 화면만으로는 못 잡습니다.

• 검사를 하나도 안 쓰면: 버그 ㄴ이 살아 있어도 화면은 “정확도 100%”라고만 말합니다.
• 검사 5만 켜면: 버그 ㄴ이 잡힙니다. 다른 둘은 안 잡힙니다.
• 검사 3·4만 켜면: 버그 ㄷ이 잡힙니다. 다른 둘은 안 잡힙니다.
• 검사 6만 켜면: 버그 ㄱ이 잡힙니다. 그리고 ㄱ이 켜져 있으면 검사 5는 아예 돌지 못합니다 — 판정 칸에 ‘—’가 뜹니다. 앞에서 죽으면 뒤의 검사는 아무것도 지키지 못하니까요.

오늘 팀이 손에 쥐고 나가는 것은 셋입니다.

1. 돌아가는 파이프라인 파일 하나. 세 곳(33줄 · 449줄 · 494줄)을 고쳐 k 표가 7차시와 같아진 판입니다. 다음 시간 9차시가 이 파일 위에서 시작합니다.
2. 검사표 6/6. ‘오류가 안 난다’가 아니라 ‘여섯 검사가 통과한다’가 오늘부터 우리 팀의 ‘다 됐다’입니다.
3. 협업 기록표 네 줄. 무엇을 · 왜 · 무엇으로 확인했나. 10차시의 실험 기록과 11차시의 발표가 이 표에서 자랍니다.

다음 시간까지 할 것

9차시는 오늘 살려 낸 그 파일 위에서 2단원 12차시의 네 칸을 다시 꺼냅니다. “전체 85.4%”가 누구의 85.4%인지를 묻는 시간이에요. 그래서 다음 시간까지 팀이 정해 와야 할 것이 하나 있습니다.

• 성능을 쪼개어 볼 ‘집단 열’ 하나를 정해 오세요. 견본에서는 촬영조건(밝음/어두움)입니다. 요일 · 학년 · 수집한 사람 — 무엇이든 좋지만 한 집단에 15개 이상이어야 그 %를 성능이라 부를 수 있습니다.
• 협업 기록표를 팀 문서에 옮겨 두세요. 오늘 칸이 비어 있으면 10차시에 되살릴 수 없습니다.
• 오늘 고친 세 곳을 팀원 모두가 각자의 파일에 반영했는지 확인하세요. 한 사람만 고친 파일을 다음 시간에 들고 오면 오늘의 합치기 사고가 그대로 되풀이됩니다.

✍️ 문제마다 답을 쓰고 제출하기를 누르세요. 제출하면 모범 답안이 열리고, 제출한 답은 선생님께 전달됩니다.