새로운 사람이 팀에 합류하면 대부분의 조직은 비슷한 과정을 반복합니다. 회사 소개 자료를 공유하고, 프로젝트 히스토리를 설명하고, 역할과 책임을 안내합니다. 필요한 문서는 이미 어딘가에 정리되어 있지만, 막상 신규 멤버가 실제 업무에 들어가면 같은 질문이 다시 나옵니다.
"이 상황에서는 누구에게 먼저 물어봐야 하나요?" "고객이 이렇게 요청하면 바로 반영하면 되나요?" "QA에서 이슈가 나왔는데 오픈을 미뤄야 하나요?" "이건 개발자가 판단해야 하나요, PMO가 정리해야 하나요?"
Gallup에 따르면 직원 중 12%만이 조직이 신규 직원을 잘 온보딩한다고 강하게 동의한다고 보고했습니다. SHRM은 신규 입사자 중 29%만이 새 역할에서 성과를 낼 준비와 지원을 받았다고 느꼈다고 정리합니다. 온보딩이 어려운 이유는 정보가 부족해서만은 아닙니다. 신규 멤버가 업무 맥락 안에서 판단하는 경험을 아직 해보지 못했다는 데 있습니다.
온보딩은 자료 전달이 아니라 맥락 학습입니다
좋은 온보딩은 회사 규칙을 알려주는 데서 끝나지 않습니다. 신규 멤버가 회사의 일하는 방식, 의사결정 흐름, 프로젝트 기준, 직무별 책임을 이해하도록 돕는 과정입니다.
하지만 많은 온보딩은 여전히 문서 중심으로 구성됩니다. 회사 소개 PDF, 프로젝트 개요 문서, 업무 프로세스 가이드, 협업툴 사용법, 직무별 체크리스트. 이 자료들은 필요합니다. 문제는 자료를 읽는 것과 실제 업무에서 판단하는 것은 다르다는 점입니다.
예를 들어 "리스크는 미리 관리해야 한다"는 문장을 읽는 것과, 실제로 일정 지연이 발생했을 때 어떤 정보를 먼저 정리하고 누구에게 보고해야 하는지 판단하는 것은 전혀 다른 경험입니다.
사례: 프로젝트 투입 첫 주에 자주 생기는 문제
한 신규 PMO가 글로벌 웹사이트 구축 프로젝트에 투입되었다고 가정해보겠습니다. 프로젝트 문서에는 전체 일정, 담당자, 산출물, 보고 체계가 정리되어 있습니다. 그런데 첫 주부터 고객이 갑자기 추가 요청을 합니다.
"이번 오픈에 이 기능도 같이 넣을 수 있나요?"
문서에는 변경 요청 프로세스가 적혀 있습니다. 하지만 신규 멤버는 실제 상황에서 고민합니다. 고객에게 바로 가능하다고 답해도 될까? 개발팀에 먼저 물어봐야 할까? 일정 영향도를 정리해야 할까? 이건 범위 변경으로 봐야 할까? 내부 보고를 먼저 해야 할까?
이런 상황에서 필요한 것은 단순 지식이 아니라 판단 순서입니다. 좋은 온보딩은 이런 실제 상황을 미리 경험하게 해야 하고, 그 경험은 문서보다 시나리오에 더 잘 담깁니다.
시나리오 기반 온보딩이 필요한 이유
시나리오 기반 온보딩은 신규 멤버에게 실제 업무와 비슷한 상황을 제시하고, 선택지를 통해 판단하게 만드는 방식입니다.
예를 들어 다음과 같은 문제가 가능합니다.
고객이 오픈 일주일 전 추가 기능을 요청했습니다. PMO로서 가장 먼저 해야 할 일은 무엇일까요?
1. 고객 요청이므로 바로 반영한다고 답한다. 2. 개발자에게 야근 가능 여부를 먼저 묻는다. 3. 요청 내용을 정리하고 일정·범위·리스크 영향도를 확인한다. 4. 오픈 후 반영하자고 바로 거절한다.
정답은 단순히 "3번"이 아닙니다. 중요한 것은 왜 3번이 더 적절한지, 나머지 선택지는 어떤 리스크를 갖는지 피드백하는 것입니다. 이렇게 하면 신규 멤버는 프로세스를 외우는 것이 아니라, 상황 안에서 판단하는 연습을 하게 됩니다.
게임형 퀘스트로 바꾸면 무엇이 달라질까
First Run은 이런 시나리오를 게임 속 퀘스트로 바꾸는 방식으로 설계되었습니다. 신규 멤버는 Make Feelbetter라는 가상의 IT회사에 합류하고, 개발자, PMO, 퍼블리셔, 기획자, 디자이너 중 하나의 역할을 선택합니다. 이후 회사 맵을 돌아다니며 NPC를 만나고, 각 직무별 실무 상황 퀘스트를 해결합니다.
PMO NPC는 일정 지연과 리스크 판단 문제를 줍니다. 개발자 NPC는 API 오류나 디버깅 문제를 제시합니다. 기획자 NPC는 모호한 요구사항을 어떻게 질문해야 하는지 묻습니다. 디자이너 NPC는 CTA 우선순위나 UI 일관성을 판단하게 합니다.
이 구조의 장점은 명확합니다. 신규 멤버가 수동적으로 문서를 읽지 않고, 실제 업무와 비슷한 선택을 해보며, 선택 결과에 대한 피드백을 즉시 받습니다. 직무별로 다른 온보딩 경험을 제공하고, 반복 교육을 재사용 가능한 콘텐츠로 만들 수 있습니다.
단순한 퀴즈가 아니라 선택과 피드백이 중요합니다
게임형 온보딩이 항상 좋은 것은 아닙니다. 점수, 배지, 랭킹만 붙이면 오히려 학습보다 게임 요소에만 집중하게 될 수 있습니다. 연구에서도 게임형 학습은 실제 상황을 시나리오로 만들고 사용자가 판단하게 할 때 효과가 좋지만, 과도한 게임 요소는 학습을 방해할 수 있다고 지적합니다.
그래서 중요한 것은 "얼마나 재미있게 꾸몄는가"보다 "실제 업무 판단을 얼마나 잘 담았는가"입니다. 좋은 온보딩 퀘스트는 다음 조건을 가져야 합니다.
- 실제 업무에서 자주 발생하는 상황이어야 합니다.
- 정답뿐 아니라 오답도 그럴듯해야 합니다.
- 선택 후 피드백이 구체적이어야 합니다.
- 직무별 역할과 책임을 반영해야 합니다.
- 난이도가 점진적으로 올라가야 합니다.
- 마지막에는 어떤 역량을 학습했는지 리포트가 남아야 합니다.
First Run이 지향하는 방향도 여기에 있습니다. 단순히 "문제를 맞히는 게임"이 아니라, 신규 멤버가 회사와 프로젝트의 일하는 방식을 미리 경험하는 온보딩 도구입니다.
마무리
온보딩이 어려운 이유는 자료가 부족해서만은 아닙니다. 신규 멤버가 실제 업무 상황에서 어떤 판단을 해야 하는지 경험해볼 기회가 부족하기 때문입니다. 문서는 여전히 필요하지만, 문서만으로는 업무 맥락을 충분히 전달하기 어렵습니다.
앞으로의 온보딩은 "읽는 교육"에서 "경험하는 교육"으로 바뀔 필요가 있습니다. First Run은 그 전환을 게임형 시나리오 퀘스트로 풀어보려는 시도입니다.
---