리허설을 매뉴얼의 첫 장에 넣기로 했습니다

처음에는 이 문장을 쓰고 싶었습니다. "리허설 없이도 바로 됩니다." 앱을 안 깔아도 되게 만들었고, 바깥 회선을 쓰지 않고 공유기 한 대 안에서만 돌게 만들었으니 그렇게 말해도 되는 줄 알았습니다. 그런데 결국 반대로 정했습니다. 안내의 맨 앞에 리허설을 두기로 했습니다.

우리가 만들 수 없는 것이 하나 남아 있었습니다

프로그램은 우리가 만듭니다. 접속 방식도, 화면 지정 방식도 우리가 정합니다. 그런데 그 프로그램이 놓이는 자리, 그러니까 그날 그 건물의 네트워크는 우리가 만들 수 없습니다. 공유기 설정도 벽도 사람도 매번 다릅니다.

여기서 판단이 갈렸습니다. 통제할 수 없는 변수를 '없는 척' 하고 간편함만 앞세울 것인지, 아니면 변수가 있다는 걸 인정하고 그걸 미리 확인하는 방법을 같이 줄 것인지. 후자를 택했습니다. 사고가 나는 자리는 대부분 프로그램 안이 아니라 프로그램 바깥이었기 때문입니다.

항목을 여섯 개로 줄였습니다

체크리스트를 만들면서 처음에는 길게 써 봤습니다. 챙길 만한 것을 다 적으니 줄이 계속 늘어났습니다. 그 목록을 그대로 내보내면 아무도 안 볼 거라고 판단했습니다. 현장에서 종이를 들고 긴 목록을 처음부터 끝까지 확인할 여유가 있는 사람은 없습니다.

그래서 '이게 안 되면 본 행사가 멈춘다'는 기준 하나로 걸러 여섯 개만 남겼습니다. 접속, 화면 지정 반영, 라이브, 슬라이드 이동, 타이머 자동 시작, 관리자 배치. 나머지는 안 되더라도 그 자리에서 우회할 수 있는 것들이라 뺐습니다.

첫 줄에 '접속'을 적어 둔 이유

여섯 개의 순서도 그냥 적은 게 아닙니다. 맨 위에 접속을 둔 건 뒤의 다섯 개가 전부 접속을 전제로 하기 때문입니다. 태블릿이 열리지 않으면 화면 지정도 라이브도 시험해 볼 방법이 없습니다. 첫 줄이 막히면 나머지 다섯 줄은 손도 못 대 보고 시간만 갑니다.

그리고 이 줄 옆에는 'AP 격리 해제 확인'이라는 말을 굳이 붙여 뒀습니다. 안내문에 낯선 용어를 넣는 건 되도록 피하려고 했는데, 이건 예외로 남겼습니다. 원인을 모르면 프로그램이 고장 났다고 판단하게 되는 자리라서, 이름을 정확히 적어 두는 편이 낫다고 봤습니다. 이름만 알면 공유기 설명서에서든 검색으로든 찾아갈 수 있지만, 이름을 모르면 갈 데가 없습니다.

라이브를 목록에 넣은 건 성능 문제가 아니었습니다

라이브는 첫 송출에 5~15초가 걸립니다. 압축 방식을 찾는 과정이 한 번 들어가기 때문입니다. 이 시간을 더 줄이는 쪽으로 손을 볼 수도 있었지만, 그보다 확실한 해결이 있었습니다. 그 한 번을 리허설에서 치르게 하는 것입니다.

기술로 없앨 수 있는 대기와, 순서를 바꾸는 것만으로 사라지는 대기는 다릅니다. 이건 후자였습니다. 그래서 성능 항목이 아니라 리허설 항목으로 옮겨 적었습니다.

슬라이드를 그림 파일로 바꿔 두는 일도 같은 이유로 리허설 항목에 넣었습니다. 언젠가 한 번은 해야 하는 일이라면, 본 행사 직전이 아니라 전날에 하는 게 맞습니다.

화면 대신 종이라고 적은 이유

체크리스트를 프로그램 안에 넣어 클릭으로 지우게 만들 수도 있었습니다. 그렇게 하지 않고 "인쇄해서 쓰세요"라고 적었습니다.

리허설 중에는 관리자 화면을 계속 써야 합니다. 그 위에 체크리스트 창을 하나 더 띄우면 정작 확인해야 할 화면을 가립니다. 종이는 화면을 가리지 않고, 손으로 그어 둔 줄은 창을 닫아도 사라지지 않습니다. 프로그램 안에 넣지 않는 편이 나은 경우도 있다고 판단했습니다.

남은 과제

여섯 개를 확인하는 일 자체를 더 줄일 수 있는지는 아직 답을 못 냈습니다. 접속 여부 정도는 프로그램이 스스로 훑어 알려 줄 수도 있을 것 같은데, 그렇게 되면 사람이 현장을 한 바퀴 돌아보는 시간이 없어집니다. 그 한 바퀴에서 발견되는 것들이 있어서, 아직은 사람 손에 남겨 두고 있습니다.

여섯을 다섯으로 줄이는 안도 생각해 봤습니다. 뺄 후보는 관리자 배치였습니다. 이건 안 해 둬도 본 행사가 멈추지는 않으니, 제가 세운 기준대로라면 빠지는 게 맞습니다. 그래도 남겨 뒀습니다. 당일에 창부터 벌리기 시작하면 그 시간이 나머지 다섯을 확인하는 시간보다 길어질 수 있어서입니다. 기준을 지키는 것보다 목록이 실제로 쓸모 있는 쪽이 먼저라고 봤습니다.

만들면서 제일 오래 붙잡고 있던 건 기능이 아니라 이 목록의 길이였습니다. 짧게 쓸수록 안 적힌 것이 늘어나고, 길게 쓸수록 안 읽힙니다. 여섯이 정답인지는 아직 모르겠습니다. 다만 안 읽히는 긴 목록보다는 읽히는 여섯 줄이 낫다는 판단은 지금도 바꾸지 않았습니다.

도입 문의

WPMS ver26 — 무선 발표 관리 시스템 (윈도우용)

• 문의: 카카오톡 채널 「펀트컴퍼니」 · funt_company@naver.com