온보딩 퀘스트를 만들자고 하면 대개 이렇게 시작합니다. 위키에서 온보딩 관련 페이지를 모아 각 페이지의 핵심 문장을 문제로 바꿉니다. 결과물은 대체로 퀴즈입니다. 변경 요청은 누가 승인하는지 묻는 문항이 스무 개쯤 만들어지고, 신규 입사자는 문서를 검색해서 풉니다. 다 맞힌 뒤에도 실제 변경 요청이 들어오면 여전히 멈춥니다.
문서를 퀘스트로 바꾸는 작업은 문장을 문제로 바꾸는 게 아닙니다. 문서에 적혀 있지 않은 판단 지점을 찾아내는 작업입니다. 아래 5단계는 그 순서로 진행하면 결과가 달라지는 절차입니다.
위키를 그대로 퀘스트로 옮기면 안 되는 이유
사내 위키는 조회용으로 쓰이도록 만들어졌습니다. 필요할 때 찾아 읽는 문서라서 판단 순서나 예외 처리는 대체로 빠져 있습니다. 적혀 있는 건 규칙의 최종 형태입니다. 긴급 배포는 팀 리드 승인 후 진행한다는 문장은 맞지만, 팀 리드가 휴가일 때 어떻게 하는지, 어디까지를 긴급으로 볼지는 적혀 있지 않습니다.
신규 입사자가 막히는 지점은 정확히 그 빈칸입니다. 그래서 변환 작업의 출발점은 위키가 아니라, 위키를 읽고도 남는 질문이어야 합니다.
5단계 변환 워크플로
1단계. 반복 질문 수집
지난 두세 달 안에 실제로 나온 질문을 모읍니다. 출처는 이미 있습니다. 팀 채널에서 신규 입사자가 물어본 것, 사내 챗봇 로그, 1대1 면담 메모, 온보딩 담당자가 같은 답을 반복한 항목, 코드 리뷰에서 반복되는 지적.
이때 세는 단위는 질문의 문장이 아니라 질문의 유형입니다. 누구에게 물어야 하는지와 누가 결정하는지는 같은 유형입니다. 서른에서 오십 개쯤 모이면 상위 열 개 유형이 전체의 절반 이상을 차지합니다. 퀘스트는 그 열 개에서만 만듭니다.
수집 결과는 이런 모양이 됩니다. 변경 요청이 들어왔을 때의 처리 순서 9회, 장애 발생 시 보고 대상과 순서 7회, 오픈 전 이슈의 Go/No-Go 기준 6회, 요구사항이 모호할 때 되묻는 방법 6회, 산출물 리뷰 요청 시점 4회.
2단계. 판단 지점 추출
각 질문 유형에서 실제로 갈리는 지점을 하나만 뽑습니다. 기준은 여기서 잘못 선택하면 손실이 있는지입니다. 손실이 없으면 퀘스트가 아니라 문서 항목으로 충분합니다.
예를 들어 변경 요청 유형에서 판단 지점은 승인권자가 누구인지가 아닙니다. 그건 조회하면 됩니다. 실제 판단 지점은 요청을 받은 직후에 무엇을 먼저 하는지입니다. 영향도 확인이 먼저인지, 관련 직무에 알리는 것이 먼저인지, 고객에게 회신 시점을 알리는 것이 먼저인지.
퀘스트 하나에는 판단 지점이 하나만 들어가야 합니다. 두 개를 넣으면 플레이어가 왜 틀렸는지 알 수 없고 오답 데이터도 해석이 안 됩니다.
3단계. 상황 카드로 쓰기
판단 지점을 실제 상황으로 옮깁니다. 상황 카드는 짧아야 합니다. 다섯 문장을 넘으면 읽지 않고 선택지로 내려갑니다. 들어가야 하는 요소는 네 개입니다. 시점, 주체, 사건, 그리고 제약 하나.
상황: 오픈 4일 전, 고객이 메인 페이지에 신규 배너 영역을 추가해달라고 메일을 보냈습니다. 디자인은 이미 확정되어 퍼블리싱이 진행 중이고, QA 일정은 이틀 뒤 시작입니다. 질문: 프로젝트 PMO로서 가장 먼저 할 일은 무엇입니까?
시점, 주체, 사건, 제약이 한 문단에 모두 들어 있습니다. 실제 프로젝트에서 가져온 제약일수록 좋습니다. 날짜와 산출물 이름이 실제와 비슷하면 플레이어의 몰입도가 확실히 달라집니다.
4단계. 선택지와 피드백 설계
여기가 품질이 갈리는 단계입니다. 대부분의 온보딩 퀴즈는 오답이 나쁘게 만들어져서 실패합니다. 고객을 무시한다 같은 선택지는 아무도 고르지 않습니다.
좋은 오답은 절반쯤 맞습니다. 실제로 신규 입사자가 할 만한 행동이어야 합니다. 위 배너 카드의 선택지는 이렇게 만들 수 있습니다.
1. 확정된 디자인이 있으므로 변경이 불가하다고 회신한다. 2. 퍼블리셔에게 먼저 작업 가능 여부를 물어본다. 3. 요청 내용을 정리하고 일정·범위·QA 영향도를 확인한 뒤 회신 시점을 고객에게 알린다. 4. 배너는 작은 작업이므로 QA 일정에 영향이 없다고 보고 바로 진행을 요청한다.
2번과 4번은 현장에서 자주 나오는 선택입니다. 2번은 순서가 틀렸을 뿐 악의는 없고, 4번은 영향도를 추정으로 처리했습니다. 이런 오답이 있어야 오답 데이터가 의미를 갖습니다.
피드백은 정답 여부보다 이유를 씁니다. 4번을 고른 플레이어에게는 배너 추가가 QA 범위에 어떤 항목을 더하는지 확인하지 않았고 작업 규모와 QA 영향도는 별개라는 점을 짚어줍니다. 두세 문장이면 충분하고, 관련 문서 링크를 함께 둡니다.
5단계. 난이도·직무 배치와 리포트 연결
만든 퀘스트를 배치합니다. 난이도는 정답의 어려움이 아니라 맥락의 양으로 조절합니다. 초급은 제약이 하나, 중급은 제약 두 개가 충돌하는 상황, 고급은 정답이 하나로 떨어지지 않고 근거를 요구하는 형태입니다.
직무 배치는 같은 사건을 재사용하는 쪽이 효율적입니다. 위 배너 요청 하나로 다섯 개 퀘스트가 나옵니다. PMO는 처리 순서, 기획자는 요구사항을 구체화하는 질문, 디자이너는 기존 시각 위계와의 충돌, 퍼블리셔는 반응형 레이아웃 영향, 개발자는 CMS 구조 변경 범위를 봅니다. 같은 상황을 직무별로 다르게 보는 경험 자체가 학습입니다.
마지막으로 리포트에 연결합니다. 퀘스트마다 판단 유형 태그를 붙여두면 플레이 후 유형별 정답률이 나옵니다. 변경 관리, 에스컬레이션, 요구사항 명확화, 품질 기준 정도로 나누면 충분합니다. 이 리포트는 신규 입사자 개인용이면서 동시에 조직용입니다. 특정 유형에서 전원이 틀리면 고쳐야 할 건 사람이 아니라 문서입니다.
흔한 실패 패턴
- 정답이 뻔한 문제. 선택지 네 개 중 하나만 길고 정중하면 그게 정답입니다.
- 조회형 퀴즈. 문서를 찾으면 답이 나오는 문항은 퀘스트가 아니라 문서 링크로 충분합니다.
- 판단 지점이 두 개 이상인 카드. 오답 원인을 알 수 없습니다.
- 게임 요소 과잉. 포인트와 배지, 랭킹을 먼저 만들면 콘텐츠 품질 문제가 가려집니다.
- 낡은 정답. 프로세스가 바뀌었는데 퀘스트를 고치지 않으면 신규 입사자에게 틀린 절차를 가르칩니다.
- 한 번에 스무 개 제작. 다섯 개를 만들어 파일럿을 돌리고 오답 분포를 본 뒤 늘리는 편이 낫습니다.
변환 체크리스트
- 질문을 문장 단위가 아니라 유형 단위로 세었는가
- 상위 열 개 유형에서만 퀘스트를 만들었는가
- 퀘스트마다 판단 지점이 하나인가
- 상황 카드에 시점·주체·사건·제약이 들어 있는가
- 오답 중 최소 두 개가 실제로 할 만한 선택인가
- 피드백이 정답 여부가 아니라 이유를 설명하는가
- 판단 유형 태그가 붙어 리포트로 집계되는가
- 프로세스가 바뀔 때 퀘스트를 고치는 담당이 정해져 있는가
마무리하며
이 워크플로의 핵심은 3단계가 아니라 1단계입니다. 반복 질문을 제대로 모으면 만들어야 할 퀘스트가 저절로 좁혀지고, 아무도 묻지 않는 내용을 문제로 만드는 일이 없어집니다. 위키는 여전히 필요합니다. 다만 위키가 답하지 못하는 질문이 무엇인지 알고 나면, 온보딩에서 무엇을 만들어야 하는지가 분명해집니다.
---