hades83bks

음성 검사에서 “잇달아”가 걸렸다. 허용 CER은 0.50%였는데 결과는 3.79~5.30%였다. 첫 합성이 실패하자 캐시를 비켜 두 번째 테이크를 만들었다. 그래도 같은 문장 끝에서 다시 걸렸다.

문제는 바깥 파이프라인이었다. 안쪽 검사는 한 사건당 두 테이크로 끝내도록 만들었는데, 바깥 호출자가 종료코드만 보고 전체 단계를 세 번 다시 실행했다.

두 번 제한이 실제로는 여섯 번이 됐다

재시도 3회×테이크 2회로 같은 사건을 여섯 번 합성했다. 매번 “잇달아”의 같은 위치에서 실패했다. 약 11분을 쓰고도 결과는 같았다. 실패 원인이 바뀌지 않았는데 횟수만 늘어난 것이다.

더구나 이전 테이크 경로를 같은 이름으로 덮어써 앞선 증거도 사라질 수 있었다. 재시도가 복구가 아니라 비용과 증거 손실을 함께 만들었다.

콘텐츠 실패와 시스템 실패를 갈랐다

발음·문장처럼 입력이 같은 한 다시 나올 결정적 실패는 재시도하지 않게 했다. 같은 텍스트 해시, 음성 모델, 오류 구간, 편집 연산이 두 테이크에서 같으면 PERSISTENT_LEXICAL_FAILURE로 기록하고 해당 사건만 격리한다.

네트워크 오류, 서버 5xx, ASR 프로세스 크래시처럼 다음 시도에서 상태가 달라질 수 있는 시스템 오류만 제한적으로 다시 시도한다. 단순히 실패했다는 이유만으로 같은 일을 반복하지 않는다.

주식 롱폼의 사건 열 건을 음성으로 만든 뒤 자동 검사를 붙였다. 한 사건의 발음이 기준을 넘지 못했다. 코드는 그 사건을 목록에서 빼고 나머지 아홉 건으로 영상을 만들 준비까지 마쳤다.

원장에도 passed 9, omitted ev7, assembly_allowed true라고 적혔다. 여기까지만 보면 부분 성공이었다.

마지막 한 줄은 정반대로 행동했다

콘솔은 조립 불가라고 출력했고 프로세스는 exit 2로 끝났다. 호출자는 이를 전체 실패로 받아 롱폼을 중단했다. 같은 실행 안에서 주석·원장·사건 목록은 “하나를 격리하고 계속”이라 했고, 종료코드만 “전부 멈춤”이라 했다.

파일 하나가 틀린 문제가 아니었다. 상태를 세 군데서 따로 계산한 게 원인이었다.

건수 비율 대신 집합과 역할로 결정했다

9/10이면 무조건 통과하는 임의 규칙은 쓰지 않았다. 원본 사건 ID와 검사 원장이 정확히 일치하는지, 남긴 목록이 원본에서 격리 ID만 뺀 집합인지, 필수 사건이 빠지지 않았는지, 남은 사건이 0이 아닌지를 모두 확인했다.

상태는 네 가지로 고정했다. 전건 성공은 FULL_PASS, 선택 사건만 안전하게 격리하면 PARTIAL_PASS, 필수 사건 실패나 집합 불일치는 BLOCKED, 검사기 자체가 죽으면 SYSTEM_ERROR다. 콘솔과 종료코드는 최종 원장의 같은 상태값만 읽게 했다.

화이트보드 그림의 크기가 계획과 맞는지 자동으로 검사했다. 그림을 다 그린 프레임에서 새로 늘어난 잉크의 좌우 끝을 재고, 계획한 슬롯의 좌우 끝과 비교하는 방식이었다.

대부분은 오차가 0~8픽셀인데 두 사건만 수백 픽셀씩 틀렸다고 나왔다. 영상을 보면 그림은 정상이라 검사 쪽을 다시 열었다.

검사는 자막이 항상 두 줄이라고 믿었다

자막 영역을 빼는 코드에는 하단 여백 86픽셀과 두 줄×59픽셀이 상수로 들어 있었다. 하지만 긴 문장은 브라우저의 어절 단위 줄바꿈 때문에 세 줄이 됐다. 세 번째 줄의 첫 줄이 검사 영역 안으로 들어왔다.

그림의 새 잉크를 재야 하는데 자막까지 같이 잡으니, 실측 폭이 화면 전체에 가까워졌다. 측정창을 넓힐수록 검출 폭도 같이 넓어지는 포화 현상이 생겼다. 정상 그림이 geometry_mismatch로 막힌 이유였다.

글자 수로 줄 수를 맞히는 방법도 버렸다

처음에는 문장 길이로 두 줄인지 세 줄인지 계산하려 했다. 하지만 같은 글자 수라도 어절 구성이 다르면 줄바꿈이 달라졌다. 화면 픽셀에서 자막 상단을 찾는 방법은 가까이 있는 그림까지 자막으로 잘라냈다.

최종적으로 렌더러와 같은 폰트·폭·줄바꿈 규칙으로 자막 전용 알파 마스크를 만들고, QC가 그 마스크 영역만 정확히 제외하게 했다. 추정값을 더 정교하게 만드는 대신 렌더러가 실제로 만든 결과를 계약으로 넘겼다.

화이트보드 영상에 그림 이름을 붙였더니 글자가 부들부들 떨렸다. 화면에는 빨간 펜이 선을 따라 움직이고 있었다. 처음엔 펜 위치나 선을 드러내는 마스크가 글자를 건드린다고 생각했다.

눈으로만 보면 그럴듯한 용의자였다. 하지만 프레임을 나눠 재자 이야기가 달라졌다.

펜이 멈춘 뒤에도 같은 폭으로 흔들렸다

라벨 영역의 잉크 픽셀은 평균 약 6,000개였고 프레임마다 약 ±330개, 5.5%씩 흔들렸다. 그런데 글자 상자의 좌우 끝은 x 92~457로 고정돼 있었다. 글자가 이동한 게 아니라 가장자리 픽셀이 매 프레임 다르게 다시 그려지고 있었다.

결정적인 값은 구간 비교에서 나왔다. 펜이 그리는 동안의 변동폭은 ±329, 펜이 다 그린 뒤는 ±339였다. 펜이 사라져도 떨림이 그대로였다. 펜은 무죄였다.

글자가 카메라와 함께 확대되고 있었다

라벨이 그림과 같은 카메라 레이어 안에 있었다. 카메라가 움직일 때마다 글자도 확대 배율을 받아 다시 래스터화됐다. 원화를 크게 다시 굽는 과정에서 최대 줌이 1.16배에서 1.58배로 올라간 뒤 떨림이 더 잘 보이기 시작했다.

그림은 카메라 레이어에 남기고, 글자는 화면 좌표로 투영한 별도 레이어로 꺼냈다. 확대 구간에서는 크기를 고정해 같은 글자 가장자리를 유지했다. 이후에는 글자 위치가 아니라 글리프 경계가 정지해 있는지를 검사 대상으로 삼았다.

프로그램이 메모리를 너무 많이 먹으면 자동으로 멈추고, 바꿔놓은 설정도 원래대로 돌리는 감시 장치를 시험했다. 말로만 안전하다고 하지 않으려면 일부러 사고를 내봐야 했다.

시험 프로그램에 10MB짜리 메모리를 70번 잡게 했다. 제한은 200MB였다.

두 번 연속 넘자 실제로 죽였다

감시 결과는 756.7MB > 200MB. 한 번 튄 값으로 바로 끊지 않고 연속 2회 초과를 확인한 뒤 프로세스를 종료했다. 기록에는 killed:true, samples:2가 남았다.

설정 복구도 시험했다. 작업이 바꿔놓은 adopt_threshold 1을 원래 값 70으로 되돌렸다. 삭제·강제 초기화·배포 같은 우회 명령 다섯 종류도 5/5 차단됐다.

처음 측정은 0MB였다

그런데 이 결과까지 오는 동안 감시자 자신이 두 번 틀렸다. 명령을 껍데기 하나 더 거쳐 실행하니, 감시자는 껍데기만 재고 실제로 메모리를 먹는 자식은 못 봤다. 결과가 0MB에 가까웠다.

윈도우 프로세스 부모·자식 관계를 6단계까지 따라가서 합산하자 756.7MB가 잡혔다. 종료할 때도 자식만 끊으면 손자가 남아서, 전체 트리를 종료해야 했다.

감시자가 자기 CPU를 범인으로 만들었다

CPU 검사에서는 더 웃긴 일이 났다. 짧은 간격을 바쁜 반복문으로 기다렸더니 감시자 자신이 CPU 97.7%를 썼다. 제한 90%를 넘겨 정상 명령까지 막았다. 감시가 사고를 만든 셈이다.

바쁜 대기를 없애고 실제 대기 방식과 3회 중앙값으로 바꿨다. 오탐 93.2%였던 측정은 1.8~16.1% 범위로 안정됐다.

이 장치는 하드웨어 한도가 아니다. 반드시 감시 경로를 거친 명령만 본다. 그래서 “초과를 막는다”가 아니라 “초과를 감지해 죽이고 되돌린다”고 기록했다.

화이트보드 영상이 처음으로 끝까지 완주했다. 1920×1080, 563프레임, 18.816초. 그림은 자막 순서대로 누적됐고, 빨간 봉 모양 커서도 움직였고, 자막도 다섯 토막에 맞춰 바뀌었다.

잉크 포함률, 그림 상자끼리의 겹침, 자막 영역 침범 검사도 전부 통과했다. 기능만 보면 성공이었다.

그림이 열릴 때마다 네모가 생겼다

중간 프레임을 직접 열어보니 그림 주변이 밝은 사각형으로 드러났다. 그림 하나가 나올 때마다 종이 위에 밝은 카드가 한 장씩 붙는 것처럼 보였다. 마지막에는 상자 다섯 개가 나란히 남았다.

원인은 아주 작았다. 생성된 선화의 종이색은 RGB 251·244·231, 색상으로는 #FBF4E7이었다. 내가 영상 배경에 박아둔 값은 245·239·224, #F5EFE0이었다.

차이는 각각 +6·+5·+7. 숫자만 보면 사소한데, 넓은 직사각형 면적으로 붙으니 경계가 또렷하게 보였다.

검사는 잉크만 보고 있었다

검사 세 개가 모두 통과한 이유도 분명했다. 전부 검은 선이 어디 있느냐만 봤다. 그림 뒤에 깔린 종이색은 검사 대상이 아니었다. 그래서 잉크는 완벽한 위치에 있어도 화면은 실패할 수 있었다.

배경색 상수를 없애고 이미지에서 실측한 종이색을 장면 계획에 넘기기로 했다. 더 근본적으로는 사각형 그림을 그대로 여는 대신 종이색을 투명하게 만들고 잉크만 드러내야 한다. 마지막에는 렌더된 프레임에서 상자 경계 안팎의 색차까지 재야 압축과 합성 뒤의 문제도 잡힌다.

이번에 배운 건 색을 “비슷하게” 맞추는 것과 같은 픽셀로 이어 붙이는 것은 다르다는 사실이다.

자막에 맞춰 그림이 하나씩 그려지는 화이트보드 영상을 만들었다. 내용은 다섯 토막이었다. 그래서 화면에도 칸 다섯 개를 미리 정하고, 이미지 생성기에 각 칸 안에 그림을 하나씩 넣어달라고 했다.

한 장을 만드는 데 34.2초가 걸렸다. 결과도 좋아 보였다. 글자와 로고는 0개였고, 다섯 그림의 선 굵기와 화풍도 같았다. 하단 자막 자리도 비워뒀다.

좌표를 재자 전부 밀려 있었다

그림을 미리 정한 칸으로 잘라 애니메이션을 만들기 전에, 검은 잉크가 실제로 어디 있는지 x축으로 투영해봤다. 계획한 위치와 실제 그림은 60~108픽셀씩 어긋나 있었다.

더 큰 문제도 있었다. 내용은 다섯 토막인데 잉크 덩어리는 여섯 개였다. 두 갈래 화살표 하나가 가운데가 비어 있다는 이유로 서로 다른 그림 두 개처럼 검출된 것이다.

원본 크기도 내가 예상한 1920×1080이 아니라 1672×941이었다. 말로 지정한 위치와 픽셀 좌표는 같은 것이 아니었다.

그림을 칸에 맞추는 방향을 버렸다

처음 생각은 “정해둔 칸에 맞게 다시 그려라”였다. 하지만 생성기는 좌표를 계약처럼 지키는 도구가 아니다. 같은 요구를 다시 보내도 다른 데 그릴 수 있다.

방향을 뒤집었다. 그림이 나온 뒤 잉크 위치를 직접 재서 칸을 만든다. 서로 가까운 덩어리는 실제 간격으로 병합한다. 이번 그림은 합쳐야 하는 틈이 24픽셀이고, 나머지 틈은 51·73·73·88픽셀이어서 구분할 근거도 있었다.

그림 수가 자막 토막 수와 맞지 않으면 억지로 끼우지 않고 다른 방식으로 넘긴다. 생성 결과를 계획에 맞다고 우기는 대신, 결과를 측정해 다음 단계의 입력으로 삼았다.