[ 졸업작품 기록 (67) ]

About this offer

같은 숫자를 네 번 재현했는데, 그 숫자가 부풀려 있었다 새 데이터도, 보드도 없는 하루 재학습 날이 다가오고 있었는데, 그날 쓸 새 데이터는 아직 도착하지 않은 상태였다. 노트북 하나로 할 수 있는 일이 뭘까 생각하다가, 그동안 났던 사고 기록을 쭉 모아 봤다. 모아 놓고 보니 전부 같은 모양이었다. 틀렸는데 에러 없이 계속 진행한 경우 였다. 그래서 하루를 이렇게 잡았다. 재학습 날 조용히 틀릴 것들을, 틀리면 그 자리에서 시끄럽게 죽도록 미리 바꿔 놓는 날. 새 기능은 하나도 만들지 않고, 이미 있는 숫자를 다른 방식으로 한 번 더 재 보는 작업이었다. 그 와중에 테스트 성적에 데이터 누수가 있다는 걸 찾았다. 전수 측정 도구를 만들었고, 네 번 재현됐다 먼저 도구 얘기를 해야 한다. 모델이 테스트 데이터 424건을 어떻게 분류하는지(알림이 나가는지, 막히는지, 오분류가 어디로 새는지) 보는 전수 측정은 원래 한 번 돌리고 버린 스크립트였다. 이걸 저장소에 남는 도구로 바꿨다. 넣은 장치는 이런 것들이다. 진짜 모델에 쏘고 있는지 스스로 확인한다. 메모리 사용량의 자릿수, 모델 라이브러리가 실제로 로드됐는지, 같은 입력을 두 번 넣었을 때 출력이 완전히 같은지를 본다. 기준 숫자와 전 칸이 일치해야 정상 종료한다. 일치 판정이 느슨하면 아무거나 통과하니, 일부러 한 칸만 틀리게 바꿔서 실제로 실패하는지도 확인했다. 결과는 424건 전수에서 정상 통과 367, 오알림 27, 막힘 30이었고, 정확도는 0.8868이었다. 이 값이 네 번째 재현까지 전부 일치 했다. 여기까지는 기분이 좋았다. 측정 경로가 안정적이라는 확신이 들었다. 그런데 이 일치가 증명한 건 딱 거기까지였다. 같은 숫자를 안정적으로 재현한다는 것과, 그 숫자가 옳다는 것은 다른 이야기였다. 같은 누수를 네 번 정확하게 재현했을 수도 있었다. 파일 이름이 같이 찍히자 보였다 도구는 결과를 낼 때 파일 이름을 같이 출력하게 만들어 두었다. 그 열이 생기자 눈에 걸리는 게 있었다. 서로 다른 화재경보 파일 17개의 첫 3초 확신도가 전부 0.9809193015098572 였다. 다음 3초도 17개가 전부 같은 값이었다. 확신도가 1.0 근처에서 겹치는 건 이상하지 않다. 숫자 표현이 그 근처에서는 촘촘하지 않기 때문이다. 그런데 0.98 언저리의 값이 소수점 16자리까지 겹치는 건 다른 문제다. 입력이 같았다는 뜻 이다. 파일 해시로 대조해 봤다. 항목 값 전처리 단계 파일 수 2,792개 고유한 내용 2,305개 잉여 487개 (17.4%) 중복 그룹 15개 가장 큰 세 그룹은 한 내용이 각각 108개, 56개, 30개 파일로 퍼져 있었다. 그리고 이 그룹들이 학습/검증/테스트 어디에 들어갔는지 보니 이랬다. 그룹 학습 / 검증 / 테스트 108개 그룹 71 / 20 / 17 56개 그룹 38 / 9 / 9 30개 그룹 19 / 4 / 7 중복 15그룹 중 10그룹이 경계를 가로질렀다. 같은 내용이 학습에도, 검증에도, 테스트에도 들어가 있었다. 나머지 5그룹은 학습 안에만 갇혀 있었고 전부 파일 2개짜리, 잉여 5개였다. 데이터량을 줄이는 문제는 사실상 없고, 문제는 경계를 넘은 쪽에 있었다. 결정타는 이거였다. 테스트 424건 중 79건이 학습·검증 데이터와 바이트 단위로 같았고, 전부 화재경보였다. 초인종과 노크는 0건이었다. (여러 파일이 앞부분을 공유하는 것으로 보이긴 하는데, 왜 그렇게 됐는지는 확정하지 못했다. 이 중복이 데이터를 모으는 단계에서 생겼는지 전처리 단계에서 생겼는지도 모른다.) 얼마나 부풀려졌나 — 그리고 아침에 내가 한 과장 이 숫자를 처음 봤을 때 나는 "정확도의 상당 부분이 암기일 수 있다"고 말했다. 실측해 보니 과한 표현이었다. 누수 79건의 정확도는 1.0000 , 전부 맞혔다. 나머지 청정 345건의 정확도는 0.8609 였다. 전체 정확도는 0.8868에서 청정 기준 0.8609로, 2.6%p 내려간다. 클래스 균형을 보는 지표(macro F1)는 0.8478에서 0.8367로, 0.011 내려간다. 화재경보만 흔들린다. 그 클래스의 F1은 0.927에서 0.893으로 내려가고, 평가 건수는 254에서 175로 줄어든다. 그리고 데모 주력인 초인종(F1 0.736)과 노크(0.881)는 소수점 아래까지 한 글자도 변하지 않았다. 누수가 그 두 클래스에 0건이었으니 당연한 결과다. 동시에 청정 값을 가려내는 계산이 맞게 돌았다는 검산이기도 했다. 건드리지 않아야 할 곳이 안 움직였다. 여기서 구분해 둘 게 있다. 79건이 전부 맞았다는 건 실측이다. 왜 전부 맞았는지, 그게 암기 때문인지는 아직 추정이다. 이 둘을 한 문장에 섞지 않으려고 했다. 그리고 누수가 있다 는 사실과 성적이 크게 틀렸다 는 주장도 별개였다. 아침에는 앞의 것을 보고 뒤의 것까지 말해 버렸고, 숫자를 보고서야 크기를 제대로 쟀다. 설계가 고장난 게 아니라, 범위 밖이었다 학습과 테스트를 나눌 때는 같은 원본에서 나온 조각이 양쪽으로 갈라지지 않게 파일 이름 기준으로 묶어서 나눈다. 이 방어는 설계대로 작동했다. 다만 내용이 같고 이름이 다른 파일 은 애초에 이 방어의 사정권 밖이었다. 그래서 기록에도 "설계 결함"이 아니라 "방어 범위 밖"이라고 적었다. 두 표현은 그 뒤의 대응을 다르게 이끈다. 결함이라고 하면 설계를 갈아엎는 쪽으로 가고, 범위 밖이라고 하면 방어를 한 겹 더 얹는 쪽으로 간다. 이번 경우에는 후자가 사실에 맞았다. 아직 다 된 건 아니다 누수는 발견과 정량까지다. 대응은 아직 정하지 않았다. 중복을 제거하고 다시 나눠 재학습할지, 누수를 고지하고 그대로 쓸지, 청정 값을 정본으로 바꿀지 모두 미결이다. 데이터는 한 줄도 건드리지 않았고 재학습도 하지 않았다. 청정 정확도 0.8609도 확정 숫자가 아니다. 발표에 어떤 숫자를 쓸지는 개발이 끝난 뒤 정한다. 증강본과 최종 데이터셋에 같은 중복이 있는지는 아직 보지 않았다. 이 측정은 노트북에서 서버 없이 모델만 직접 호출한 것이다. 보드는 쓰지 않았고 실제 알림 경로를 통과한 게 아니다. 기기와 시연 쪽 상태는 이날 달라진 게 없다. 79건이 전부 맞았다는 것과, 그 이유가 암기라는 것은 다른 층위다. 앞은 실측이고 뒤는 추정이다. 마무리 이날 한 일은 새 기능이 아니라 이미 있던 숫자를 다른 방식으로 한 번 더 재 본 것뿐이었다. 그랬더니 성적이 부풀려 있었다. 그중 가장 크게 남은 건 네 번 재현된다는 사실이 그 숫자가 옳다는 증거가 아니라는 것 이었다. 재현이 알려 주는 건 측정이 안정적이라는 사실이고, 무엇을 재고 있는지는 알려 주지 않는다. 이번에는 그걸 파일 이름 한 열이 알려 줬다. 띵동(Ddingdong)은 청각장애인 1인 가구를 위한 현관 부착형 소리 분류 알림 시스템 졸업작품입니다. 초인종 · 노크 · 화재경보를 구분해서 사진과 자막까지 스마트폰으로 보내주는 걸 목표로 만들고 있습니다.