데모

진척을 말로만 주고받으면 같은 문장이 반복됩니다. "80퍼센트 됐습니다" 가 3주 연속으로 나오고, 4주차에 "다음 주면 됩니다" 가 나오고, 6주차에 그 기능은 여전히 안 됩니다. 아무도 거짓말을 하지 않았습니다. 남은 20퍼센트가 앞의 80퍼센트만큼 오래 걸린다는 것을 본인도 몰랐을 뿐입니다.

이 문장이 위험한 이유는 듣는 사람이 검증할 수 없기 때문입니다. 세일즈는 그 말을 믿고 고객에게 출시 시점을 알리고, 마케팅은 그 날짜에 맞춰 준비하고, 대표는 투자자에게 그대로 전합니다. 말 한마디가 회사 밖까지 나간 뒤에 그 말이 틀렸다는 사실이 드러납니다.

데모는 이 검증을 각자의 신뢰가 아니라 화면에 맡기려고 만든 자리입니다. 로그인해서 버튼을 누르고 결과가 뜨는 것까지 보여 주면, 무엇이 되고 무엇이 아직 안 되는지가 설명 없이 드러납니다. 퍼센트는 해석이 필요하지만 동작하는 화면은 그렇지 않습니다.

동작하는 것을 실제 환경에서 눌러 보이는 것이 전부이고, 나머지는 그것을 짧고 솔직하게 만드는 장치입니다. 보통 15분에서 30분이면 끝납니다.

1. 보여 줄 것을 고릅니다. 기준은 하나입니다. 지금 눌러서 동작하는가. 설계 문서나 화면 시안은 이 자리의 재료가 아닙니다. 그것을 논의하는 자리는 따로 있습니다.
2. 맥락을 한 줄로 깝니다. "팀 관리자가 구성원 권한을 한 번에 바꾸지 못해 일일이 들어가야 했던 문제입니다" 처럼 누가 무엇 때문에 불편했는지를 먼저 말합니다. 이 한 줄이 없으면 보는 사람은 화면만 보고 왜 그게 필요한지 모릅니다.
3. 실제 환경에서 직접 조작합니다. 미리 녹화한 영상이나 시안을 넘기는 방식은 이 자리의 목적을 없앱니다. 버튼을 눌렀을 때 3초씩 걸리는 것도 정보이고, 중간에 오류가 나는 것도 정보입니다.
4. 안 되는 것을 말합니다. "권한 변경은 되는데 기록이 남지 않고, 되돌리기도 아직 없습니다" 처럼 경계를 그립니다. 이 단계를 건너뛰면 보는 사람이 남은 부분도 됐다고 짐작하고 돌아갑니다.
5. 의견을 받되 그 자리에서 결정하지 않습니다. 나온 의견을 적기만 하고, 무엇을 반영할지는 우선순위를 정하는 자리에서 따로 다룹니다. 이 구분이 없으면 데모가 한 시간짜리 기획 회의로 바뀝니다.
6. 남은 것을 적어 둡니다. 나온 의견과 그 자리에서 드러난 문제를 목록으로 남기고 담당과 시점을 붙입니다.

절차가 짧은 데는 이유가 있습니다. 준비에 드는 시간이 길어지는 순간 팀은 데모를 미루기 시작하고, 미루면 이 자리가 막으려던 문제가 그대로 돌아옵니다. 준비 시간이 30분을 넘어가고 있다면 대개 보여 줄 것을 고르는 대신 보여 줄 것을 만들고 있는 중입니다.

만든 사람이 직접 보여 줍니다. 프로덕트 매니저가 대신 시연하면 막히는 지점에서 설명이 멈추고, 보는 사람은 그 지점이 원래 그런 것인지 아직 안 된 것인지 구분하지 못합니다.

보는 쪽에는 이해관계자가 들어옵니다. 결과에 영향을 받거나 영향을 줄 수 있는 사람들로, 세일즈·고객 지원·마케팅처럼 이 기능을 고객에게 설명해야 하는 사람이 여기 속합니다. 이들이 데모에 들어오면 출시 뒤에 나올 질문이 미리 나옵니다. 고객 지원이 "기존 설정은 어떻게 되나요" 라고 묻는 순간 아무도 생각하지 않았던 경우가 드러납니다.

시점은 두 가지로 잡습니다. 하나는 주기의 끝입니다. 2주짜리 주기를 도는 팀이면 마지막 날에 그 주기에 끝낸 것을 모아 보여 줍니다. 다른 하나는 기능이 처음 동작한 날입니다. 주기를 기다리지 않고 그날 바로 관련된 사람 서넛을 불러 5분 동안 보여 주는 방식인데, 방향이 어긋났을 때 되돌리는 비용이 가장 적은 시점이기도 합니다. 2주를 더 만든 뒤에 방향을 고치면 그 2주가 통째로 버려지지만, 첫날에 고치면 하루치만 버립니다.

너무 이르면 보여 줄 것이 없어 설명으로 채우게 되고, 너무 늦으면 의견을 받아도 고칠 시간이 없습니다. 완료 정의와 나란히 두면 시점을 잡기 쉽습니다. 작업을 끝났다고 부를 수 있는 공통 기준인데, 팀에 따라 데모를 통과한 것까지를 완료로 치기도 합니다.

"다음 주 데모에 올릴 수 있는 상태로 맞춰 주세요."

말로 설명하는 수준이 아니라 눌러 보일 수 있는 상태까지 만들어 달라는 뜻입니다.

"이건 데모에서 보고 정합시다. 지금 문서로는 감이 안 와요."

글로 주고받는 논의가 겉돌고 있으니 동작하는 것을 본 뒤에 판단하자는 말입니다.

"데모 때 권한 부분은 목업이라고 미리 말씀드릴게요."

지금 보이는 화면 중 일부는 실제로 동작하지 않는다는 사전 고지입니다.

페이지덱은 격주 목요일 오후에 30분짜리 데모를 엽니다. 어느 주에 태오가 기업 고객용 권한 관리 화면을 시연했습니다. 구성원 목록에서 여러 명을 골라 권한을 한 번에 바꾸는 부분까지는 매끄러웠는데, 수아가 "관리자 권한을 가진 사람이 자기 권한을 내리면 어떻게 되나요" 라고 물었습니다. 태오가 직접 해 보니 화면이 멈췄습니다.

이 경우는 설계 문서에도 없었고 작업 목록에도 없었습니다. 문서 검토만 돌렸다면 출시 뒤 고객이 먼저 찾았을 문제입니다. 민서가 그 자리에서 경고 문구를 어떻게 띄울지 그려 보였고, 지현은 의견만 적은 뒤 다음 주기 계획을 짜는 자리에서 순서를 정했습니다. 데모에서 결정까지 하지 않은 것은 그 30분이 다른 팀의 시간이기도 하기 때문입니다.

발표 자리로 준비하는 경우가 가장 많습니다. 사람들 앞에서 무언가를 보여 준다는 형식이 발표를 떠올리게 하니 자연스러운 오해입니다. 그래서 슬라이드를 만들고, 순서를 외우고, 오류가 날 만한 경로를 피해 가는 길을 미리 짜 둡니다. 그렇게 다듬을수록 이 자리는 원래 목적을 잃습니다. 막히는 지점을 감추면 보는 사람은 다 된 줄 알고 돌아가고, 준비에 반나절이 드는 자리는 바쁜 주에 가장 먼저 취소됩니다. 매끄러운 데모보다 오류가 한 번 난 데모가 정보량이 많습니다.

완성된 것만 올려야 한다고 보는 것도 흔합니다. 이 기준을 세우면 초반 몇 주 동안 보여 줄 것이 없어 자리를 건너뛰게 되고, 방향이 어긋난 채로 그 몇 주가 지나갑니다. 절반만 동작하는 화면도 올릴 수 있습니다. 어디까지 동작하는지를 먼저 말하기만 하면 됩니다.