Loading the catalog…
Loading the catalog…
멀쩡한 숫자를 버그로 의심했는데, 다른 게 고장나 있었다 노트북 하나만 있는 날 이날은 장비가 아무것도 없었다. 기기는 집에 있었고, 주문한 부품은 아직 안 왔고, 가진 건 노트북뿐이었다. 그래서 남은 미결을 다시 읽다가, "기기가 있어야 한다"고 적어둔 항목 하나를 쪼개봤다. 판정 기준이 네 가지였는데(실제 모델을 띄운다 / 진짜 초인종 소리를 넣는다 / 사람이 없는 상태로 만든다 / 화면과 기록 양쪽에서 차단을 확인한다), 기기가 있어야 하는 건 하나도 없었다. 모델은 노트북에 있고, 초인종 소리는 학습 데이터에 수백 개가 있고, "사람 없음"은 요청에 값을 넣으면 되고, 화면은 브라우저로 본다. 그렇게 노트북으로 모델을 띄우고 첫 요청을 쏘는 데까지 갔는데, 거기서 이 글의 이야기가 시작된다. 0.4 / 0.6 / 0.0 첫 요청의 점수가 이렇게 돌아왔다. 0.4 / 0.6 / 0.0 소수 첫째 자리로 딱 떨어지고, 하나는 정확히 0.0이다. 확률값이 이렇게 나오는 건 이상하다고 봤다. 며칠 전에 같은 모델로 쏴봤을 때는 소수점이 길게 나왔었다. 그래서 "표시가 뭉개지는 버그"라고 의심하고 파고들었다. 결과부터 쓰면 그 의심은 틀렸다. 서버가 점수를 소수 둘째 자리까지 반올림해서 내보내는 건 정상 동작이었고, 이 소리 파일의 값이 우연히 그렇게 떨어졌을 뿐이다. 버그를 찾으러 간 곳에 버그는 없었다. 그런데 파고드는 길에 다른 게 걸려 있었다. 반올림이 판정 앞에 있었다 반올림하는 자리를 찾아 올라가 보니, 그게 알림을 보낼지 판정하는 단계보다 앞 에 있었다. 지금: 점수 계산 → 반올림 → 알림 보낼지 판정 원칙: 점수 계산 → 알림 보낼지 판정 → (표시용으로만) 반올림 그러니까 "신뢰도 0.70 미만이면 알림을 보내지 않는다"는 기준이 원래 값이 아니라 반올림된 값 을 받고 있었다. 원래 값이 0.695에서 0.69999 사이면 반올림돼서 0.70이 되고, 문턱을 못 넘어야 할 게 통과한다. 여기서 뼈아팠던 건, 이게 내가 직접 세워둔 원칙의 위반 이라는 점이다. 몇 주 전에 "표시용 반올림이 판정 경계를 오염시키면 안 된다"고 문서에 못 박아뒀다. 그 원칙은 그때 만지던 파일에서만 지켜졌고, 다른 파일에서는 위반이 그대로 살아 있었다. 원칙을 적어두는 일과 그게 지켜지는지 확인하는 일은 별개인데, 나는 앞의 것만 했다. 다만 심각도는 따로 봐야 했다. 평가용 데이터 424개를 전부 돌려서 그 구간에 든 게 몇 개인지 셌더니 0건 이었다. 구조적으로 폭은 있는데 실제 사례는 없었다. 그래서 이건 "고쳐야 한다"가 아니라 "기록해두고 판단을 기다린다" 로 남겼다. 수정할지는 아직 정하지 않았다. 과잉 진단의 수지 이 하루를 정리하면 계산이 이렇게 된다. 내가 의심한 것: "표시가 뭉개진다" → 틀렸다 (정상 동작) 의심하며 파고든 길: 반올림 위치 → 원칙 위반이 걸렸다 (진짜) 이상한 숫자를 보고 "버그다" 하고 달려갔는데, 숫자는 정상이었고 다른 게 고장나 있었다. 과잉 진단은 비용이 싸다. 틀려도 잃는 건 시간이 조금이고, 가끔은 이렇게 공짜 수확을 준다. 다만 조건이 하나 있다. 결론을 확정하기 전에 원래 값을 직접 볼 것. 그러지 않고 "표시 버그"로 기록하고 끝냈다면, 거짓 진단이 문서에 남고 진짜 결함은 못 봤을 것이다. 아직 다 된 건 아니다 반올림 결함은 실제 사례가 0건 이다. "버그를 찾았다"가 아니라 "구조적 폭은 있으나 실사례는 없어 기록만 해뒀다"가 정확하다. 고칠지는 미정이다. 이날은 하루 종일 노트북만 썼고, 기기는 여전히 아무것도 안 했다. 노트북에서 한 확인은 기기가 실제로 보내는 경로를 검증한 게 아니다. 주문한 부품이 아직 안 왔고, 그게 안 오면 직접 녹음, 재학습, 분류 개선이 통째로 멈춘다. 진척이 좋아 보이는 하루였지만 이 병목은 그대로다. 마무리 이날 가장 값진 건 숫자 하나를 잘못 의심한 덕에 내가 세운 원칙이 어디서 안 지켜지고 있는지 보게 된 것이었다. 그리고 "장비가 없어서 못 한다"고 적어둔 일이 쪼개보니 노트북 일이었던 것도 같은 결이다. 이날 하루의 대부분은 새로 만드는 일이 아니라 적어둔 것을 다시 읽는 일 이었다. 띵동(Ddingdong)은 청각장애인 1인 가구를 위한 현관 부착형 소리 분류 알림 시스템 졸업작품입니다. 초인종 · 노크 · 화재경보를 구분해서 사진과 자막까지 스마트폰으로 보내주는 걸 목표로 만들고 있습니다.
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
[ 졸업작품 기록 (66) ]. 멀쩡한 숫자를 버그로 의심했는데, 다른 게 고장나 있었다 노트북 하나만 있는 날 이날은 장비가 아무것도 없었다. 기기는 집에 있었고, 주문한 부품은 아직 안 왔고, 가진 건 노트북뿐이었다. 그래서 남은 미결을 다시 읽다가, "기기가 있어야 한다"고 적어둔 항목 하나를 쪼개봤다. 판정 기준이 네 가지였는데(실제 모델을 띄운다 / 진짜 초인종 소리를 넣는다 / 사람이 없는 상태로 만든다 / 화면과 기록 양쪽에서 차단을 확인한다), 기기가 있어야 하는 건 하나도 없었다. 모델은 노트북에 있고, 초인종 소리는 학습 데이터에 수백 개가 있고, "사람 없음"은 요청에 값을 넣으면 되고, 화면은 브라우저로 본다. 그렇게 노트북으로 모델을 띄우고 첫 요청을 쏘는 데까지 갔는데, 거기서 이…
Open source