[ 졸업작품 기록 (71) ]

About this offer

시간 제한 상수는 총 시간이 아니었다 기기가 처음으로 두 번째 알림을 직접 쐈다 서버 쪽을 한참 닫아 오다가, 이날은 반대편을 붙였다. 현관 기기(보드)가 두 번째 알림, 즉 사진을 찍고 5초 동안 녹음해서 서버에 올리는 경로 였다. 이 경로는 그때까지 코드가 한 줄도 없었다. 하루에 붙여서 실기기로 네 번 돌렸다. 결과만 보면 성공한 날이었다. 보드가 찍은 사진이 메신저에 도착했고, 보드 마이크로 한 실제 말이 음성 인식을 거쳐 글자로 돌아왔다. 그런데 이 글은 그 성공이 아니라, 같은 세션에서 내 판단이 두 번 접힌 일 에 대한 이야기다. 둘 다 같은 함정에서 나왔다. 3초 상한을 걸었는데 6.4초 뒤에 시간 초과가 났다 서버가 음성 인식 서비스를 부를 때 시간 제한을 3.0초로 걸어 두었다. 그런데 실측에서 6.42초가 지난 뒤에 시간 초과 가 났다. 나는 바로 판정했다. "상수 미작동이다." 상한이 3초인데 6초 넘게 걸렸으니 상수가 안 먹히고 있다고 본 것이다. 코드를 열어 보니 상수는 정확히 전달되고 있었다. 문제는 이 시간 제한의 성질이었다. 이 값은 총 경과 시간의 상한이 아니라 , 연결, 핸드셰이크, 전송, 응답 대기 같은 개별 단계마다 따로 걸리는 값 이었다. 3초짜리 단계가 여러 개 이어지면 6초는 정상 거동이다. 기대한 것: [──────── 총 3초 ────────] 실제 구조: [연결 3초][핸드셰이크 3초][전송 3초][응답 대기 3초] ... 내 오진은 원값과 코드를 보기 전에 판정을 확정했기 때문에 났다. 의심하는 것 자체는 싸다. 비용이 드는 건 확정 이다. 확정은 코드를 본 뒤에 해야 했다. 더 쓰라린 건 이 성질을 이미 한 번 정정한 적이 있다는 점이었다. 기기 쪽 HTTP 라이브러리에서 똑같은 성질을 확인하고 정정해 둔 상태였다. 같은 함정이 서버 쪽에도 있었는데, 한 군데만 알고 있었다. 상한이라고 적어 둔 숫자가 하한이었다 이 성질이 서버에만 해당하는 게 아니라면, 다른 곳에 적어 둔 숫자도 의심해야 했다. 이전에 나는 "두 번째 알림의 최악 경우는 12.1초"라고 계산해 두었다. 이 계산은 상수를 총 시간으로 읽은 것이었다. 같은 함정을 메신저 발송에도 적용해, 실측 시각으로 다시 재 봤다. 발송 시간 제한 상수는 1.5초였는데, 시도 네 번의 실제 합계는 약 9.2초 였다. 상수 대비 실제 소요는 약 1.5~1.6배 였다(3구간만 잡히는 경우 약 1.60). 이 배율을 대입하면 최악 경우가 12.1초에서 약 19.5초 로 늘어난다. 그러면 두 가지를 동시에 넘는다. 두 번째 알림에 주어진 15초 예산을 넘고, 내가 기기의 시간 제한으로 잠정 걸어 둔 15초도 넘는다. 그리고 실제로 넘었다. # 게이트 첫 번째 알림 왕복 두 번째 알림 왕복 결과 1 건너뜀 683ms — 두 번째 알림 미발송 2 진행 4,902ms 6,710ms 200 3 진행 4,301ms 10,014ms 200 4 진행 5,814ms 15,474ms 시간 초과(-11) 네 번째 이벤트에서 보드는 15.5초에 시간 초과로 끊었다. 그런데 서버 로그를 보니 서버는 그 직후에 정상(200)으로 끝냈다. 보드는 실패로 읽었는데 서버는 성공으로 종결한 것이다. "서버는 성공했는데 기기는 그걸 못 들을 수 있다"고 미결로 적어 둔 상태가 실물로 재현됐다. 여기서 조심할 점이 있다. 1.5~1.6배라는 배율은 한 세션, 네 번의 시도 에서 나온 값이라 확정하지 않고 범위로 적었다. 19.5초도 그 배율을 쓴 논증이다. 그래서 단정할 수 있는 건 하나뿐이다. 12.1초가 과소평가였다는 결론은 어느 배율을 써도 성립한다. 몇 초가 정확한 상한인지는 아직 모른다. 말은 맞게 알아들었는데 알림이 안 갔다 네 번째 이벤트의 서버 기록은 또 하나를 알려 줬다. 음성 인식은 완벽하게 성공했다. "계세요 택배입니다 문 앞에 놓고 갈게요", 내가 한 말 그대로였다. 그런데 메신저 발송은 네트워크 도달 실패 로 전부 깨졌다. 첫 번째 알림도, 사진도, 자막도 전부 나가지 못했다. 처음에는 인증 열쇠 만료를 의심했다. 로그의 오류 종류를 보고 그 의심을 접었다. 열쇠가 만료되면 인증 오류 가 나지, 연결 오류 가 나지 않는다. 에러의 종류가 어느 층에서 깨졌는지를 가려 줬다. 이 이벤트에서 말소리를 글자로 바꾸는 층은 무죄였고, 깨진 건 그 뒤의 발송 계층이었다. 앞서 "자막 없음은 실패가 아니다"를 갈라 둔 것의 반대편 사례다. 인식은 됐는데 전달이 안 됐다. 아직 다 된 건 아니다 시간 제한의 새 값은 정하지 않았다. 잠정으로 걸어 둔 15초가 실제로 터졌다는 것까지가 사실이다. 최악 19.5초는 한 세션 네 번의 시도에서 나온 배율을 쓴 논증이다. 상한으로 단정할 수 없다. 서버가 성공으로 종결했는데 보드가 끊은 건 관측된 사실이지만, 그 상태를 어떻게 다룰지(재시도 정책)는 아직 정하지 않았다. 네 번째 이벤트의 시간 초과가 네트워크 문제 때문이었다는 건 서버 로그로 설명되지만, 앞선 이벤트들의 첫 번째 알림 지연과 같은 네트워크 열화인지는 모른다. 실제 육성 인식은 이 한 번뿐이고, 거리와 소음 조건은 재지 않았다. 마무리 상수가 안 먹는다고 판정하고 곧바로 상수를 고쳤다면, 문제를 더 깊이 묻어 버렸을 것이다. 상수는 멀쩡했고 틀린 건 상수를 읽는 내 방식이었다. 시간 제한은 총량이 아니라 단계마다 따로 걸리는 값 이라는 한 문장이 서버 쪽에서는 빠져 있었다. 그 한 문장이 빠진 채 쌓아 둔 12.1초라는 숫자는 실측 한 번에 하한이 됐다. 의심은 싸지만 확정은 비싸다. 판정을 확정하기 전에 코드를 한 파일 더 열어 보는 일이, 이날 가장 싼 보험이었다. 띵동(Ddingdong)은 청각장애인 1인 가구를 위한 현관 부착형 소리 분류 알림 시스템 졸업작품입니다. 초인종 · 노크 · 화재경보를 구분해서 사진과 자막까지 스마트폰으로 보내주는 걸 목표로 만들고 있습니다.