알파

다 만든 다음에야 처음 보여 주던 시절이 있었습니다. 반년 동안 설계하고 만들고 다듬어서 공개했는데, 정작 사용자가 원한 것은 그게 아니었다는 사실을 공개 첫 주에 알게 됩니다. 그때는 이미 돌이킬 수 있는 게 거의 없습니다. 사람도 시간도 다 들어간 뒤라 방향을 바꾸자는 말이 조직 안에서 나오지 않습니다.

페이지덱에서도 같은 일이 있었습니다. 문서에 댓글을 다는 기능을 두 달 만들어 한 번에 열었는데, 사용자들은 댓글이 아니라 문서를 누가 언제 고쳤는지를 보고 싶어 했습니다. 태오가 "이럴 거면 2주 만에 대충이라도 보여 드릴걸" 이라고 말한 회고가 남아 있습니다.

알파는 그 2주를 제도로 만든 것입니다. 완성도가 낮다는 사실을 미리 밝히고, 그 대신 남에게 보여 주는 시점을 최대한 앞으로 당깁니다. 어차피 틀릴 수 있다면 적게 들인 상태에서 틀리는 편이 싸다는 계산입니다. 두 달을 들인 뒤에 방향을 바꾸면 두 달이 사라지지만, 2주에 바꾸면 2주만 사라집니다.

알파 구간의 제품은 아직 성한 데가 많지 않습니다. 쓰이는 조건이 다른 구간과 달라서, 그 조건을 서로 알고 여는지가 알파의 전부입니다.

1. 쓰는 사람이 극소수입니다. 보통 만든 팀과 회사 안 몇 명이고, 밖으로 나가더라도 얼굴을 아는 열 명 안쪽입니다. 문제가 생겼을 때 바로 붙잡고 물어볼 수 있는 범위를 넘지 않습니다.
2. 기능이 비어 있습니다. 핵심 흐름 하나만 되고 나머지는 버튼만 있거나 아예 없습니다. 페이지덱의 댓글 기능 알파에서는 댓글을 달 수만 있고 수정도 삭제도 알림도 없었습니다.
3. 데이터를 보장하지 않습니다. 구조를 바꾸면서 그동안 쌓인 것을 지우는 일이 흔합니다. 그래서 알파에서는 "여기 넣은 내용은 날아갈 수 있습니다" 를 미리 말해 둡니다.
4. 화면이 시안과 다릅니다. 민서가 만든 디자인이 아직 안 붙어 있고, 개발자가 임시로 얹은 기본 스타일 그대로인 경우가 많습니다.
5. 피드백이 도구가 아니라 대화로 옵니다. 설문이나 지표가 아니라 옆자리에서 "이거 왜 이래요" 라고 묻는 말이 자료가 됩니다. 사용자가 적으니 그 편이 빠릅니다.

이 다섯 가지는 부실함이 아니라 합의한 조건입니다. 조건을 밝히지 않은 채 같은 물건을 열면 그건 알파가 아니라 사고입니다.

알파를 벗어나려면 기능이 다 붙는 것이 아니라 밖에서 온 사람이 혼자 써낼 수 있는 상태가 되어야 합니다. 옆에서 설명해 줘야 돌아가는 화면은 아직 알파입니다. 대개 아래 셋을 확인합니다.

1. 핵심 흐름이 끊기지 않습니다. 시작부터 끝까지 한 번이라도 도움 없이 통과하는 사람이 나와야 합니다. 중간에 오류가 나서 새로고침해야 넘어가는 자리가 남아 있으면 그 자리에서 밖의 사용자는 그냥 나갑니다.
2. 넣은 데이터가 남습니다. 다음 배포에서 지워질 예정인 구조 위에서는 사람을 더 부를 수 없습니다.
3. 방향에 대한 답이 나왔습니다. 알파의 목적은 완성이 아니라 확인이라서, "이 기능이 필요한가" 에 대한 답이 아직 없으면 사람을 늘려도 같은 질문만 커집니다.

셋이 채워지면 문을 조금 더 엽니다. 다음 칸은 대개 클로즈드 베타입니다. 초대한 사용자만 들어오는 시험 공개라서 대상을 고를 수 있고, 문제가 생겨도 영향받는 사람이 몇십 명으로 묶입니다. 돈을 내는 고객에게 먼저 열어 의견을 받기로 했다면 얼리 액세스로 갑니다. 대상 규모는 비슷하지만 먼저 쓰는 대가로 의견을 준다는 약속이 붙은 자리입니다. 여기서 더 나아가면 누구나 들어올 수 있는 오픈 베타이고, 딱지를 완전히 떼면 정식 출시입니다.

"이번 주에 알파 열게요. 개발팀이랑 지현 님만 쓰실 거예요."

밖에 알리지 않고 회사 안 몇 명에게만 먼저 켜겠다는 말입니다.

"그건 알파니까 데이터 날아갈 수 있다고 미리 말씀드렸어요."

기록이 사라진 것이 사고가 아니라 사전에 합의한 조건이었다는 뜻입니다.

"알파에서 답이 안 나왔는데 베타로 넘기는 건 순서가 아닌 것 같아요."

사람을 늘리기 전에 이 기능이 필요한지부터 정하자는 제동입니다.

페이지덱에서 알파는 대개 목요일 오후에 열립니다. 태오가 사내 계정에만 기능을 켜 두고, 지현이 팀 채널에 무엇이 되고 무엇이 안 되는지를 다섯 줄로 적어 올립니다. 이 다섯 줄이 알파의 계약서 구실을 합니다. 여기 적히지 않은 것은 안 되는 것이고, 그래서 안 된다는 제보는 받지 않습니다. 이 줄을 빼먹고 열면 한나절 안에 이미 아는 버그 제보가 스무 건씩 들어오고, 정작 듣고 싶던 이야기는 그 사이에 묻힙니다.

한 주쯤 지나면 지현이 쓴 사람들을 한 명씩 붙잡고 묻습니다. 설문을 돌리지 않고 직접 묻는 이유는 사람이 열 명 안팎이라 그 편이 빠르고, 막힌 자리를 화면 앞에서 같이 보는 것이 답변 한 줄보다 훨씬 많은 것을 알려 주기 때문입니다. 무엇을 하려다 막혔는지, 왜 그 자리에서 멈췄는지를 듣고 나면 다음에 무엇을 만들지가 정해집니다. 규원이 여기까지 보고 문을 더 열지 말지를 정합니다. 여기서 아니라는 판단이 나오면 만든 것을 접는 일도 알파의 정상적인 결말 중 하나입니다.

알파를 대충 만들어도 되는 기간으로 읽는 경우가 많습니다. 어차피 미완성이라고 공지해 뒀으니 품질 기준이 면제된다고 생각하기 쉽습니다. 하지만 알파에서 낮춰도 되는 것은 범위이지 만듦새가 아닙니다. 되는 기능 하나는 제대로 돌아야 합니다. 그 하나가 계속 터지면 쓰는 사람이 기능에 대한 판단 대신 버그 제보만 하게 되고, 방향을 확인하려던 목적 자체가 사라집니다.

알파를 버전 번호로 읽는 것도 흔합니다. 회사 밖에서는 이 말이 소프트웨어 버전 표기로도 쓰이니 자연스러운 혼동입니다. 실무에서 알파는 번호가 아니라 문이 열린 폭을 가리킵니다. 버전 1.4에서도 새 기능 하나만 알파로 열 수 있고, 같은 제품 안에서 어떤 기능은 알파이고 어떤 기능은 정식일 수 있습니다. 이 오해를 그대로 두면 회의에서 말이 어긋납니다. 누구는 제품 전체가 초기 단계라는 뜻으로, 누구는 이번 기능 하나만 좁게 열었다는 뜻으로 같은 단어를 씁니다.