[ 졸업작품 기록 (69) ]

Об этом предложении

테스트는 전부 통과했는데, 그 테스트가 돈을 쓰고 있었다 한도를 관측 장치로 쓰기로 했었다 방문자가 현관에서 한 말을 글자로 바꿔 주는 음성 인식 서비스가 있다. 이 서비스에는 일일 사용 한도를 걸 수 있는데, 나는 한도를 아주 낮게(600초) 걸어 두었다. 비용 때문만은 아니었다. 그 한도 자체를 관측 장치로 쓰려는 것 이었다. 서버를 안 돌린 날에도 사용량이 차오르면 "설명되지 않는 호출이 있다"는 신호가 되기 때문이다. 이번에 그 장치가 제대로 울렸다. 사용량이 또 한도에 걸린 것이다. 한도가 또 찼다 콘솔의 일별 사용량을 펼쳐 보니 모양이 이상했다. 날짜(예시) 성공 실패 사용량(초) A 40 212 600 B 12 0 180 C 36 0 540 D 40 128 600 성공이 40회에서 딱 멈추고(40 × 15초 = 한도 600초) 그 뒤로 실패가 수백 건 쌓인 날이 있었다. 15초 단위로 과금되는 서비스라서 사용량 = 성공 횟수 × 15초 가 모든 날짜에서 정확히 맞았다. 그리고 서버도 터널도 대시보드도 꺼 둔 날에도 호출이 찍혀 있었다. 추측 대신 숫자로 가르는 대조 실험 추측하면 후보가 끝도 없이 늘어난다. 그래서 변수를 하나로 줄였다. 서버, 터널, 대시보드를 전부 끈다. 포트와 프로세스까지 확인했다. 콘솔 숫자를 적어 둔다. 회귀 테스트를 딱 한 번 돌린다. 몇 분 뒤 콘솔을 다시 본다. 시점 성공 실패 사용량 실행 전 1 0 15초 테스트 1회 후 13 0 195초 테스트 2회 후 25 0 375초 매번 정확히 +12건, +180초 였다. 우연이 아니었다. 메신저로 가는 알림은 한 건도 오지 않았고, 바깥으로 나간 건 음성 인식 호출뿐이었다. 내가 틀렸던 순간 첫 실행이 2초대에 끝났을 때 나는 이렇게 추론했다. "외부 서비스 왕복이 1초 가까이 걸리는데 12번이면 훨씬 오래 걸렸을 테니, 안 불렀을 가능성이 높다." 콘솔이 곧바로 반증했다. 내가 옮겨 쓴 그 1초는 4초짜리 음성 으로 잰 왕복이었다. 테스트가 보내는 음성은 훨씬 짧아서 왕복도 짧았다. 입력 길이를 확인하지 않은 채 숫자를 옮겨 쓴 것이다. 이 일로 분명해진 게 있다. 걸린 시간으로 외부 호출 여부를 가를 수는 없고, 판정은 콘솔로만 해야 한다. 지난 숫자들도 12의 배수였다 지난 며칠 치 호출 수를 12로 나눠 보니 나누어떨어졌다. 하루 12건 = 테스트 1회분 하루 36건 = 3회분 하루 168건 = 14회분 하루 252건 = 21회분 테스트를 그만큼 돌린 날로 설명된다. 다만 이건 정황이다. 처음 문제가 된 날의 호출은 301건(성공 34, 실패 267)이었고, 12의 배수가 아니다. 그 날의 구성은 아직 조사하지 못했다. 왜 진짜 열쇠가 쓰였나 원인 경로는 읽기 전용으로 추적했다. 테스트가 실제로 바깥에 나가려는 순간을 잡으려고, 저장소 밖에 네트워크 연결 시도를 기록하고 막는 장치 를 따로 만들어 그 아래에서 테스트를 한 번 돌렸다. 연결 시도 기록: 12건 코드를 따라가며 센 호출 지점: 12건 콘솔 증가: 12건 세 값이 일치했다. 체인은 이랬다. 설정 파일을 모듈이 불러오는 시점에 읽는다 → 테스트용 설정은 메신저 쪽 열쇠만 비우고, 음성 인식 열쇠는 안 비웠다 → 진짜 열쇠가 테스트 설정에 그대로 들어온다 → 요청 처리 경로를 타는 9개 테스트가 그 열쇠로 진짜 호출을 한다 → 호출이 성공하든 실패하든 결과는 "자막 없음"으로 흡수된다 → 테스트 판정에는 아무 영향이 없다 → 초록불 더 아팠던 건 시점이었다. 이 테스트들은 음성 인식을 가짜 문구로만 쓰던 시절에 만든 것이다. 나중에 실제 호출 분기가 추가되면서, 테스트 코드를 한 줄도 바꾸지 않았는데 옛 테스트가 진짜 호출자로 바뀌어 버렸다. 예전에 쓴 "무죄"가 뒤집혔다 처음 이 현상을 봤을 때도 "테스트가 실제 서비스를 부른 게 아닌지" 의심했었고, 그때는 무죄 라고 기록했다. 근거는 "가짜 열쇠 문자열이고 호출 함수를 스텁했다"였고, 근거 유형은 실측 이라고 적었다. 돌아보니 그건 실측이 아니라 코드 읽기 였다. 게다가 그 두 조건은 나중에 추가된 일부 테스트에만 성립했다. 나는 "스텁이 존재하는가"를 봤지, "서비스를 부르는 모든 테스트가 스텁 아래 있는가"를 보지 않았다. 호출 수를 센 적은 한 번도 없었다. 근거 유형 표기가 틀렸고, 그 틀린 표기가 무죄 판정을 실제보다 단단해 보이게 했다. 조용한 가드는 가드가 아니다 고치는 방법은 두 겹으로 정했다. 원인 제거 : 테스트 설정에서 음성 인식 열쇠 두 개를 비운다. 재발 탐지 : 테스트 중에 바깥으로 나가는 연결을 막고, 막은 사실을 테스트 실패로 만든다. 여기에 함정이 하나 있다. 연결을 막기만 하면 안 된다. 제품 코드가 음성 인식 실패를 "자막 없음"으로 삼켜 버리기 때문에, 예외만 던지는 차단은 막았는데도 테스트가 계속 합격 한다. 요금은 막아도, 다음에 또 새는 날 아무도 모른다. 그래서 시도 기록이 한 건이라도 있으면 그 테스트를 실패로 끝내게 했다. 이 설계가 진짜로 그 일을 하는지 보려고 일부러 부러뜨려 봤다. 변형 결과 열쇠 비우기를 되돌림 새던 9개 테스트가 정확히 빨개짐 실패 판정만 끔 9개가 조용히 합격 (자기검증 1개만 실패) 가드를 통째로 뺌 원래의 12건이 다시 나옴 (자기검증 2개 실패) 가운데 줄이 핵심이다. 처음에 기각했던 설계가 정확히 재현됐다. 차단만 하고 실패로 만들지 않으면 테스트는 합격하고, 새는 건 그대로다. 가드가 살아 있는지 매번 증명하는 자기검증 테스트도 둘 넣었다. 테스트는 104개에서 106개가 됐고 실행 시간은 2.16초에서 0.24초가 됐다. 속도는 참고치일 뿐이고, 판정 근거는 아니다. 합격 시험은 가드 없이 마지막으로, 고친 코드가 혼자서도 안 새는지 보려고 이번엔 저장소 밖 가드 없이 테스트를 한 번 돌렸다. 몇 분 뒤 콘솔은 25 / 0 / 375초 그대로 였다. 이 합격 시험은 처음엔 로그를 남기지 않아서 기록에서 한 번 빠졌다. 대화로만 확인한 실측은 그 자리에서 파일로 남겨야 한다는 걸 다시 배웠다. 아직 다 된 건 아니다 원인 경로는 확정됐지만 "모든 호출이 테스트 때문이었다"는 아니다. 과거 일별 숫자가 12의 배수라는 건 정황이다. 처음 문제가 된 날의 301건은 구성을 아직 모른다. 수정 후 안 샌다는 확인은 가드 없이 한 번 돌리고 콘솔이 그대로였다는 것이 전부다(n=1). 콘솔은 일 단위 집계라서 그 실행분만 따로 본 게 아니고, 직전 값 대비 무변동으로 판정했다. 옛 "무죄" 판정이 틀렸던 건 도구 탓이 아니고, 코드 읽기를 실측이라고 적은 내 표기 의 문제였다. 속도로 호출 여부를 추론한 것도 내 추론 오류였다. 마무리 이전 글들에서 확인에도 층위가 있다고 썼다. 얼마나 자주 보는가, 무엇을 검사하는가, 그 검사가 실제로 실행됐는가. 이번에는 한 층이 더 붙었다. 검사가 통과해도, 그 검사가 바깥에 무슨 일을 하고 있는가. 합격한 테스트가 하루에도 몇 번씩 돈을 쓰고 있었는데, 그걸 알려 준 건 테스트가 아니라 한도라는 숫자 였다. 테스트의 초록불은 테스트가 보려는 것만 알려 준다. 나머지는 바깥의 숫자가 알려 줬다. 띵동(Ddingdong)은 청각장애인 1인 가구를 위한 현관 부착형 소리 분류 알림 시스템 졸업작품입니다. 초인종 · 노크 · 화재경보를 구분해서 사진과 자막까지 스마트폰으로 보내주는 걸 목표로 만들고 있습니다.