분할 화면 수정은 모든 테스트를 통과했다. 그런데 버그는 절반만 고쳐졌다

작성: 2026년 10월 12일 · 수정: 2026년 10월 12일

Katto는 긴 영상을 세로 클립으로 바꿔 주는 서비스입니다. 저는 이걸 혼자, 공개적으로 만들고 있습니다. 10월 10일에 분할 화면의 기하 구조 버그를 고치고, 테스트하고, 배포한 뒤 변경 로그에 "수정됨"이라고 적었습니다. 그날 저녁, 똑같은 버그가 여전히 일어나고 있다는 걸 발견했습니다. 그리고 두 번이나 고쳤는데도 분할 화면이 좋아지지는 않았습니다.

분할 화면은 무엇을 위한 것인가

팟캐스트나 인터뷰는 보통 넓게 찍습니다. 테이블에 두 사람이 앉아 있고, 16:9 화면 양쪽에 한 명씩 있죠. 세로 쇼츠는 9:16입니다. 가운데를 잘라내면 테이블만 남고 얼굴은 하나도 안 보입니다. 말하는 사람을 따라가면 상대방이 대답할 때마다 화면에서 사라집니다.

두 사람이 충분히 떨어져 앉아 있으면 Katto는 다른 방법을 씁니다. 각 사람 주위로 창을 하나씩 잘라 위아래로 쌓는 거죠. 절반 높이의 패널 두 개, 두 얼굴이 내내 보입니다. 두 화자 샷에 대한 표준적인 해법이고, 리프레임 페이지에서 설명하는 것도 바로 이것입니다.

무엇이 잘못되고 있었나

패널마다 너비가 있고, 코드는 두 창이 겹치지 않도록 그 너비에 상한을 두었습니다. 그 상한은 두 사람 사이의 거리에서 계산했습니다. 그럴듯하게 들리지만, 엉뚱한 것을 재고 있었습니다.

실제 사례를 보겠습니다. 너비 1920픽셀인 원본에서 두 사람이 1300픽셀 떨어져 있습니다. 상한은 1235, 패널 너비는 1214가 나왔으니 상한은 작동하지 않았습니다. 그다음 각 창을 해당 인물에 맞춰 가운데 정렬하고, 화면 밖으로 삐져나간 창은 다시 안쪽으로 밀어 넣었습니다. 왼쪽 창은 오른쪽으로 358픽셀, 오른쪽 창은 왼쪽으로 236픽셀 움직였습니다. 서로를 향해서요.

1214픽셀짜리 창 두 개를 나란히 놓으려면 2428픽셀이 필요합니다. 화면은 1920픽셀입니다. 어떻게 배치하든 최소 508픽셀은 두 패널에 동시에 들어갑니다.

화면에서는 위 패널 아래쪽과 아래 패널 위쪽에 같은 이미지 띠가 나타납니다. 어깨가 두 번, 얼굴 반쪽이 두 번, 때로는 사람 전체가 두 번 보입니다.

처음부터 출발했어야 할 규칙은 한 줄이면 충분합니다. 너비가 W인 창 두 개는 2W가 화면 너비 이하일 때만 나란히 들어간다. 두 사람 사이의 거리와는 아무 관계가 없습니다.

얼마나 자주 일어났나

Katto가 이미 전달한 분할 클립들을 다시 살펴보며, 저장된 기하 정보에서 겹침을 바로 읽어냈습니다. 첫 번째 창의 오른쪽 끝에서 두 번째 창의 왼쪽 끝을 뺀 값입니다.

그중 31퍼센트가 겹쳐 있었습니다. 겹친 클립의 내역은 이렇습니다.

겹침	비율	보이는 것
300 px 이상	18%	사람이나 상반신이 중복됨
150~299 px	15%	안쪽 가장자리에 몸 일부
60~149 px	36%	배경 띠
60 px 미만	30%	눈치채기 어려운 수준

백분율은 반올림한 값이라 합계가 99입니다. 대략 3분의 1은 보이지 않고, 3분의 1은 미묘하고, 3분의 1은 대놓고 깨져 있었습니다. 최악의 경우는 앞에서 본 508픽셀이었습니다.

처음 집계는 31퍼센트가 아니라 23퍼센트였습니다. 겹침을 일부 오래된 클립에는 없는 필드로 계산했는데, 그 행들이 아무 경고 없이 건너뛰어졌던 겁니다. 숫자가 그럴듯해 보여서 하마터면 그대로 쓸 뻔했습니다.

수정, 그리고 통과한 테스트

새 상한은 앞의 한 줄 규칙 그대로입니다. 각 패널은 최대 화면의 절반이고, 두 창은 서로 교차할 수 없도록 배치합니다. 원래 배치가 실제로 겹칠 때만 작동합니다. 이전 버전은 모든 경우에 기하를 다시 계산해서 멀쩡한 클립 몇 개를 1~2픽셀씩 밀어 버렸습니다. 문제없던 클립을 건드리는 수정은 그 자체로 두 번째 버그입니다.

그다음은 검증입니다. 저장된 클립 한 묶음을 수정을 끈 상태와 켠 상태로 다시 돌렸습니다. 겹치지 않던 클립은 모두 똑같이 나왔고, 바뀐 클립은 정확히 겹치던 클립들뿐이었습니다. 이어서 실제 영상으로 새 작업을 돌렸습니다. 분할 클립 12개 중 3개에서 상한이 작동했고, 겹친 클립은 하나도 없었습니다.

배포했고, 변경 로그에 수정 완료라고 적었습니다.

그날 저녁

테스트 영상을 하나 더 돌렸습니다. 수정을 켠 상태인데도 클립 하나가 44픽셀 겹친 채로 나왔습니다.

함수가 두 개 있었습니다. 하나는 고전적인 경우, 즉 테이블에서 마주 앉은 두 사람을 처리하고 각자에게 클로즈업을 줍니다. 다른 하나는 첫 번째 함수가 거절할 때 쓰이는 일반 대체 경로로, 프레임마다 가장 왼쪽과 가장 오른쪽 얼굴을 잡아 그 기준으로 화면을 나눕니다. 둘 다 각자의 창 위치 한 쌍으로 분할 화면 클립을 만듭니다. 그리고 둘 다 거의 토씨 하나 다르지 않은 똑같은 결함을 갖고 있었습니다. 저는 첫 번째를 고치고 두 번째는 열어 보지도 않았습니다.

짜증 나는 건 증거가 너무 그럴듯해 보였다는 점입니다. 제 측정과 테스트 묶음에는 두 코드 경로가 섞여 있었는데, 저는 전혀 몰랐습니다. 첫 번째 수정이 표본을 충분히 정리해 준 덕분에 결과가 완벽해 보였던 겁니다. 저장된 결과로 하는 측정은 증상을 셉니다. 그 증상을 만들어 내는 곳이 몇 군데인지는 알려 주지 않습니다.

두 번째 수정은 같은 규칙을 두 번째 함수에 넣은 것입니다. 같은 묶음으로 다시 돌리니 클립 4개가 추가로 고쳐졌습니다. 56, 124, 230, 340픽셀이던 겹침이 모두 0이 됐고, 다른 건 하나도 움직이지 않았습니다. 56픽셀짜리는 아침 수정을 아무 영향 없이 통과한 클립이었습니다. 새던 곳을 현장에서 잡은 셈입니다.

세 번째가 있는지 확인하기

두 번째로 "수정됨"이라고 쓰기 전에, 창 위치를 정하는 코드를 전부 검색했습니다. 한 곳이 아니라 네 곳이었습니다. 두 곳은 위의 함수들이고, 이제 둘 다 고쳤습니다. 세 번째는 이미 찾아 둔 분할선을 기준으로 패널을 만들고 각 패널을 그 선의 자기 쪽 공간으로 제한하기 때문에, 구조상 두 창이 교차할 수 없습니다. 네 번째는 세 번째가 계산한 값을 넘겨줄 뿐입니다.

그래서 이번에는 주장의 범위가 더 좁습니다. 10월 10일 이후 렌더링된 분할 화면은 화면의 같은 부분을 두 패널에 함께 넣지 않습니다. 그 전에 렌더링된 클립은 만들어질 당시의 기하를 그대로 유지합니다.

아직 제대로 되지 않은 것

화면이 중복되지 않는다는 건 최저선일 뿐, 좋은 분할 화면이라는 뜻은 아닙니다. 지금 실제 영상에서 보이는 문제가 세 가지 있습니다.

패널이 안에 있는 사람에 비해 너무 넓습니다. 각 패널의 크기는 사람이 아니라 화면을 기준으로 정해집니다. 넓은 스튜디오 샷에서는 한 사람이 자기 패널의 3분의 1만 채우고 나머지는 뒤쪽 세트가 차지할 수도 있습니다. 반쯤 빈 패널 두 개는 잘 잡은 샷 하나보다 못해 보일 수 있고, 그래서 아직 분할 화면을 더 많은 종류의 샷으로 넓히지 않았습니다. 각 패널을 사람에 맞춰 좁히는 것이 다음 작업입니다.

긴 클립 안의 짧은 주고받기는 분할되지 않습니다. 결정은 클립 전체 단위로 내려집니다. 한 사람이 40초 동안 말하고 다른 사람이 5초 끼어들면, 클립은 하나의 구도로 유지되고 대답은 화면 밖에서 일어납니다.

어떤 2인 샷은 아예 2인 샷으로 인식되지 않습니다. 트리거는 얼굴 수를 셉니다. 옆모습이거나, 멀리 있거나, 조명이 나쁘면 얼굴 감지기는 몸 감지기가 모든 프레임에서 보는 사람을 놓칠 수 있고, 그러면 클립은 단일 구도로 돌아갑니다.

이 중 어느 것도 화면을 중복시키지는 않습니다. 깨지지 않은 분할 화면과 정말 좋은 분할 화면의 차이일 뿐이고, "수정됨"이라는 한 단어가 둘 다를 뜻하게 내버려 두기보다는 이렇게 솔직히 밝히는 쪽을 택하겠습니다.

이번 일에서 남기는 것

수정이 효과가 있으면, 같은 출력을 만드는 다른 곳을 찾아보세요. 버그를 발견한 곳만이 아니라, 같은 종류의 결과를 낼 수 있는 모든 곳을요. 이번에는 필드 이름 하나로 검색 한 번이면 됐는데, 저는 그걸 배포 전이 아니라 배포 후에 했습니다.

집계 숫자로는 수정이 완전한지 알 수 없습니다. 숫자는 크게 떨어졌고, 크게 떨어지는 바로 그 순간에 사람은 찾기를 멈춥니다.

조용히 행을 건너뛰는 지표는 아예 실패하는 지표보다 나쁩니다. 빠진 필드 하나가 경고 한 번 없이 31퍼센트를 23퍼센트로 바꿔 놓았습니다.

대리 지표가 아니라 제약 조건에서 출발하세요. 상한을 두 사람 사이의 거리로 만든 건 그 숫자가 손에 있었기 때문입니다. 진짜 한계는 화면 너비였고, 그 숫자도 손에 있었습니다.

변경 로그 항목 (영어)은 10월 10일에 "수정됨"이라고 적었는데, 몇 시간 일렀습니다. 지금은 실제로 일어난 일을 그대로 적어 두었습니다.