콘티온 ContiOn TIL 12
외부 도구에 파일을 만들어 넘기는 일을 한 달 전에 한 번 「불가」로 적어 뒀는데, 이번에 실물을 뜯어보고 그 판단을 뒤집었다. 뒤집히기까지 거친 장면들을 남긴다.
「못 만든다」고 적어 둔 것을 다시 꺼냈다
앞선 TIL 11에서 외부 자막기 파일을 직접 만들 수 있는지 판단했고, 결론은 못 만든다였다. 근거는 둘이었다. 그 파일이 독자 규격의 바이너리 포맷(사람이 읽는 글자가 아니라 프로그램용 이진 데이터로 저장된 형식)이라는 것, 그리고 안에 텍스트로는 채울 수 없는 3차원 장면 데이터가 들어 있다는 것이었다. 그래서 그 도구가 스스로 열어 둔 입력 통로를 쓰기로 했고, 콘티온은 텍스트 파일을 내보내는 데서 멈췄다.
한 달을 그렇게 쓰다가 이번에 실물 폴더를 통째로 받았다. 행사 네 번 분량에 파일이 천 개 넘게 들어 있었다. 「이 안에서 순서 목록을 뽑아낼 수 있는지, 그리고 콘티온에서 무엇을 내려받으면 이 안의 글자를 갈아 끼울 수 있는지」가 이번 질문이었다.
매뉴얼에 있는 기능이 현장에선 안 쓰이고 있었다
파일을 보기 전에 먼저 나온 안은 그 도구가 제공하는 데이터 링크(외부 텍스트 파일을 줄 번호로 끌어다 쓰는 기능 — 앞선 TIL 11에서 찾아 둔 그 통로)를 쓰는 것이었다. 설정해 두면 콘티온은 텍스트만 내보내면 된다.
그 자리에서 접었다. 자막 담당자가 그런 설정까지 알 리 없다고 봤기 때문이다. 확인해 보니 실제로 그 기능은 천 개 넘는 파일 어디에도 쓰이고 있지 않았다. 매뉴얼에 있다고 현장에서 쓰이는 건 아니었다.
기능이 있느냐와 그 기능이 쓰이느냐는 다른 문제다. 도구를 바꾸는 방법을 낼 때는 그걸 배워야 하는 사람이 누구인지부터 봐야 한다. 배울 사람이 안 배우면 그 방법은 없는 것과 같다. 쓰는 사람이 새로 익혀야 할 것이 있다면, 그건 해법의 부록이 아니라 해법의 가격이다.
파일 하나 뽑아서 바로 넣고 싶었다
다음으로 나온 안은 콘티온이 파일을 곡별로 쪼개 주는 것이었다. 담당자는 텍스트를 한 번에 넣으면 줄마다 자막 한 장이 생기는 방식으로 일하고 있었는데, 제목과 가사는 디자인이 달라서 제목판과 가사판을 따로 만든 뒤 최종본에 번갈아 끼워 넣고 있었다. 그러니 곡별로 나눠 주면 순서대로 넣기만 해도 된다는 것이었다.
그건 내가 원한 게 아니었다. 넣는 횟수가 두 번에서 곡 수만큼으로 늘 뿐, 사람이 하나씩 자리를 맞추는 일은 그대로 남는다. 모양만 바꾼 같은 노동이다. 내가 원한 건 파일 하나를 뽑아 그대로 넣으면 끝나는 것이었다.
불편의 정체는 겪는 사람이 말해야 한다. 만든 쪽에서 본 병목은 「끼워 넣는 횟수」였고, 실제 불편은 「손으로 자리를 맞춘다」였다. 이 둘은 해법이 완전히 다르다. 횟수를 줄이는 쪽으로는 아무리 다듬어도 답이 안 나온다. 그러니 불편하다고 말할 때는 무엇이 불편한지를 내가 정확히 말해 주는 편이 빠르다.
다시 뜯어 보니 글자가 그냥 줄줄이 있었다
그래서 접어 뒀던 쪽을 다시 봤다. 파일을 만들어 주는 것 말이다.
열어 보니 안에 글자가 길이 접두 문자열(글자 앞에 「몇 글자인지」를 먼저 적어 두는 저장 방식)로 줄줄이 놓여 있었다. 자막 문구도, 이미지 파일 이름도, 화면에 붙은 이름표도 전부 그 꼴이었다. 한 달 전에 못 만든다고 판단한 근거는 파일 종류였는데, 정작 우리가 건드려야 할 글자는 그냥 평범하게 들어 있었다.
여기서 질문이 갈렸다는 것도 알았다. 「이 형식의 파일을 처음부터 만들 수 있나」와 「이미 있는 파일을 복제해 한 군데만 바꿀 수 있나」는 전혀 다른 질문이다. 앞엣것은 그 형식을 전부 이해해야 하지만, 뒤엣것은 바꿀 한 군데만 알면 된다. 한 달 전에는 이 둘을 「파일을 만든다」로 뭉뚱그려서 어려운 쪽 답으로 결론을 내버렸다.
복제하는 쪽으로 보면 남은 근거 하나도 같이 풀린다. 3차원 장면 데이터는 우리가 만들 필요가 없다. 복제한 원본에 그대로 남아 있고 우리는 글자만 갈아 끼우니, 「텍스트로는 그걸 채울 수 없다」는 근거 자체가 이 방식에선 무의미해진다.
겉으로 붙은 형식의 이름이 아니라 안에 무엇이 어떻게 놓였는지가 답을 정한다. 그리고 그건 열어 봐야만 안다. 뒤집는 김에 반대 근거로 보이던 것도 하나 확인해 지웠다 — 「안 되는 이유를 찾았다」 싶을 때가 오히려 한 번 더 확인할 자리였다.
「대표」를 「대표자」로 바꾸면 뒤가 다 밀린다
마지막으로 본 건 글자 수가 달라져도 되느냐였다. 한 글자가 늘면 파일이 그만큼 길어지고, 그 뒤에 있는 모든 것의 자리가 밀린다.
이때 갈리는 기준이 있었다. 파일 안에 오프셋 필드나 길이 필드(무엇이 몇 번째 자리에 있다, 전체 크기가 얼마다를 따로 적어 둔 값)가 있느냐다. 그런 값이 있으면 한 글자만 늘어도 그 값들이 전부 거짓이 되어 파일이 깨진다. 없으면 앞에서부터 차례로 읽어 내려가는 구조라, 길이가 바뀌어도 그 글자의 길이 숫자만 고치면 된다.
찾아보니 그런 값이 하나도 없었다. 이게 이번 판단의 결정적 근거였다.
이건 이 도구에만 해당하는 얘기가 아니다. 남이 만든 파일을 손대도 되는지 볼 때, 눈으로 훑어서 「복잡해 보인다」로 정할 게 아니라 이 질문 하나를 먼저 던지면 된다. 안에 오프셋·길이 필드가 있는가. 있으면 손대는 순간 전부 맞춰야 하고, 없으면 한 군데만 고쳐도 된다.
다만 여기까지는 파일을 읽어서 낸 결론이라, 실제로 그 도구가 열어 주는지는 별개다. 그래서 원본은 그대로 두고 복사본에 글자 수가 다른 문구 세 개를 심어 시험 파일을 만들었다. 같은 글자 수로 바꾸는 건 당연히 되니 시험할 값어치가 없고, 늘어나고 줄어드는 경우라야 방금 세운 판단이 맞는지가 드러난다.
요약
- 도구를 바꾸는 해법을 낼 때는 그걸 배워야 하는 사람이 누구인지부터 본다. 쓰는 사람이 새로 익혀야 하는 것은 해법의 부록이 아니라 가격이다.
- 매뉴얼에 있는 기능이 현장에서 쓰이고 있는 건 아니다. 실물을 뒤져 보면 안 쓰는 기능이 그대로 드러난다.
- 불편의 정체는 겪는 사람이 말해야 한다. 「횟수가 많다」와 「손으로 자리를 맞춘다」는 다른 문제고, 해법도 다르다.
- 「이 형식을 처음부터 만들 수 있나」와 「있는 것을 복제해 한 군데만 바꿀 수 있나」는 다른 질문이다. 뭉뚱그리면 어려운 쪽 답으로 결론이 난다. 복제하는 쪽에서는 못 만드는 부분이 원본에 그대로 남으므로 그 근거가 사라진다.
- 형식의 이름이 아니라 안에 무엇이 어떻게 놓였는지가 답을 정한다. 그건 열어 봐야 안다.
- 남의 파일을 손대도 되는지는 안에 오프셋·길이 필드가 있느냐로 가른다. 있으면 전부 맞춰야 하고, 없으면 한 군데만 고치면 된다.
- 시험은 가장 의심스러운 조건으로 짠다. 당연히 되는 경우를 시험하면 아무것도 알아내지 못한다.