온보딩은 문서가 아니라 경험이다: 읽은 것보다 판단해 본 것이 남는다

지난 편에서는 프로젝트에서 온보딩이 중요한 이유를 PM의 시선으로 정리했습니다. 결론은 이랬습니다. 목표, 범위, 결정권자, 변경 절차는 문서로도 전할 수 있지만, 자주 마주치는 상황에서 어떻게 판단하는가는 문서로 잘 전해지지 않는다.

이번 편은 그다음 질문입니다. 그럼 좋은 온보딩은 어떤 모습일까요?

온보딩 자료는 많은데 왜 여전히 헤맬까

많은 조직의 온보딩은 비슷한 모양입니다. 위키 링크 몇 개, 회사 소개 슬라이드, 프로세스 문서, 그리고 “궁금한 거 있으면 언제든 물어보세요.” First Run 소개 페이지에도 정리해 둔, 기존 온보딩이 잘 작동하지 않는 이유는 네 가지입니다.

문제	무슨 일이 생기나
반복되는 설명	새 멤버가 올 때마다 회사와 프로젝트 흐름을 다시 설명한다
읽히지 않는 문서	자료는 많지만 끝까지 읽고 이해하기 어렵다
늦어지는 실무 적응	실제 상황을 겪기 전까지는 어떤 판단을 해야 하는지 알기 어렵다
직무별 기준 차이	개발, PMO, 기획, 디자인, 퍼블리싱마다 배워야 할 기준이 다르다

이 중 제가 가장 근본적이라고 보는 건 세 번째입니다. 문서를 다 읽은 사람도 막히는 지점이 있습니다. 규칙을 아는 것과, 규칙이 필요한 순간을 알아보는 것은 다른 능력이기 때문입니다.

예를 들어 온보딩 문서에 “범위 변경은 반드시 변경 요청으로 받는다”라고 적혀 있다고 해 보죠. 읽으면 누구나 고개를 끄덕입니다. 하지만 실제 그 순간은 “변경 요청입니다”라는 이름표를 달고 오지 않습니다. 출시 이틀 전 금요일 오후, 친한 고객사 담당자가 메신저로 “이 문구 하나만 살짝 바꿔 주세요”라고 보낼 때 옵니다. 그 메시지를 변경 요청으로 알아보는 감각은 문서를 한 번 더 읽는다고 생기지 않습니다.

좋은 온보딩의 네 가지 조건

그럼 그 감각은 어떻게 생길까요? 저는 좋은 온보딩에 네 가지 조건이 있다고 생각합니다.

1. 실제와 닮은 상황에서 직접 판단한다

가장 중요한 조건입니다. 온보딩의 기본 단위를 읽을 문서에서 판단할 상황으로 바꾸는 것입니다. 상황에는 맥락이 있고, 선택지가 있고, 선택에 따른 결과가 있습니다.

저도 PMP를 공부하면서 같은 걸 겪었습니다. PMP 문제 대부분은 지식을 그대로 묻지 않고, 프로젝트 상황을 하나 준 뒤 PM이 지금 무엇을 먼저 해야 하는지 고르게 합니다. PMP 합격 후기 1부에도 적었지만 정답 문장을 외웠더니 단어만 조금 바뀌어도 또 틀렸습니다. 그래서 오답노트에 문제 대신 “이런 상황이면, 먼저 ___한다”라는 판단 규칙을 쌓았습니다. 온보딩도 같다고 생각합니다. 남겨야 하는 건 규칙 목록이 아니라 상황 속의 판단입니다.

2. 역할마다 다른 길이 있다

개발자와 디자이너가 같은 프로젝트에 합류해도, 첫 주에 마주칠 상황은 다릅니다. 개발자는 API 오류나 디버깅 앞에서, 기획자는 요구사항 충돌 앞에서, 디자이너는 디자인 시스템 규칙과 사용성 검수 앞에서 판단해야 합니다. 모두에게 같은 슬라이드를 보여 주는 온보딩은 누구에게도 딱 맞지 않습니다.

그렇다고 자기 역할만 알면 되는 것도 아닙니다. 프로젝트는 결국 협업이라, 옆 직무가 무엇 때문에 고민하는지 알면 대화가 훨씬 쉬워집니다. 내 역할에서 시작해 옆 역할로 넓혀 가는 경로가 좋은 온보딩의 두 번째 조건입니다.

3. 정답 여부가 아니라 이유를 돌려준다

“정답입니다”와 “오답입니다”만으로는 배움이 잘 남지 않습니다. 실무의 선택은 대개 맞고 틀리고보다 더 나은 것과 위험한 것의 차이입니다. 어떤 선택은 최선이고, 어떤 선택은 괜찮지만 아쉽고, 어떤 선택은 당장은 문제없어 보여도 위험합니다. 그래서 피드백에는 등급과 이유가 함께 있어야 합니다.

상황 — 출시 이틀 전 금요일 오후. 고객사 담당자가 메신저로 “결제 버튼 문구 하나만 바꿔 주세요. 간단한 거예요.”라고 보냈습니다. 당신은 이번 주에 합류한 개발자입니다. 무엇을 먼저 하겠습니까?

선택	등급	이유
요청 내용을 PM에게 공유하고, 변경 요청으로 받을지 판단을 맡긴다	Excellent	출시 직전의 변경은 QA·번역·UAT에 영향을 줄 수 있어 결정권자가 판단해야 한다
담당자에게 영향 범위를 먼저 묻고, 그 내용을 정리해 PM에게 공유한다	Good	방향은 맞지만, 결정 전에 혼자 협의를 이어 가면 상대에게 기대를 만들 수 있다
간단하니 바로 고치고, 배포 후에 PM에게 알린다	Risky	선의지만 합의된 절차를 건너뛰고, 출시 직전에 회귀 리스크를 만든다
바쁘니 월요일에 보자고 하고 따로 기록하지 않는다	Poor	요청이 사라지고, 출시 후 같은 요구가 더 큰 이슈로 돌아온다

Risky와 Poor를 비교해 보세요. 둘 다 좋은 선택은 아니지만 이유가 다릅니다. Risky는 잘해 보려다 생긴 위험이고, Poor는 놓쳐서 생긴 문제입니다. 이 차이를 이유와 함께 들어야 다음에 비슷한 상황에서 다르게 판단할 수 있습니다.

4. 틀려도 되는 안전한 곳이 있다

실제 프로젝트에서 위의 Risky를 고르면, 그 대가는 출시 뒤에 치릅니다. 온보딩은 그 대가 없이 틀려 볼 수 있는 몇 안 되는 시간입니다. 그러려면 틀려도 괜찮다는 신호가 분명해야 하고, 틀린 문제를 다시 풀어 볼 기회가 있어야 합니다. 한 번 틀리고 끝나는 시험이 아니라, 틀린 이유를 확인하고 다시 도전하는 연습장이어야 합니다.

문서형 온보딩과 경험형 온보딩

네 가지 조건을 나란히 놓으면 차이가 분명해집니다.

	문서형 온보딩	경험형 온보딩
기본 단위	읽을 문서	판단할 상황
경로	모두에게 같은 자료	역할별로 다른 길, 이후 다른 역할로 확장
피드백	없거나, 맞다·틀리다	등급과 이유, 배울 점
실수	실제 업무에서 처음 한다	연습 안에서 먼저 하고 다시 풀어 본다
끝났다는 기준	다 읽었다	판단할 수 있다

오해가 없도록 덧붙이면, 문서가 필요 없다는 이야기가 아닙니다. 목표, 범위, 결정권자처럼 찾아볼 정보는 문서가 가장 좋습니다. 다만 문서만으로 끝나는 온보딩은 새 멤버에게 가장 어려운 부분, 즉 처음으로 혼자 판단해야 하는 순간을 비워 둔 채 끝납니다.

그래서 First Run을 만들었다

이 네 가지 조건을 한 번에 담을 수 있는 형식이 무엇일까 생각했을 때, 제 답은 RPG였습니다. 그래서 First Run을 만들었습니다. First Run에서 네 가지 조건은 이렇게 들어가 있습니다.

• 상황 속 판단: 실제 업무 상황을 담은 퀘스트에서 무엇을 먼저 할지 고릅니다. 정답을 외우는 문제가 아니라 판단 문제입니다.
• 역할별 경로: 개발자, PMO, 퍼블리셔, 기획자, 디자이너 다섯 직무별로 퀘스트와 멘토 NPC가 있고, 레벨 3부터는 다른 직무의 퀘스트도 풀 수 있습니다.
• 이유 있는 피드백: 답변은 Excellent·Good·Risky·Poor 네 등급으로 평가되고, 이유와 학습 포인트가 함께 나옵니다.
• 안전한 실패: 틀린 퀘스트는 복습 게시판에서 다시 풀 수 있고, 플레이가 끝나면 강점, 보완할 영역, 추천 복습 퀘스트를 정리한 결과 리포트가 나옵니다.

그리고 이 모든 걸 회사와 프로젝트에 맞게 바꿀 수 있습니다. 실제 업무 시나리오와 프로젝트 규칙으로 퀘스트를 만들고, 실제 멘토를 본뜬 NPC, 오피스 맵, 브랜딩을 반영할 수 있습니다. 위의 예시 퀘스트 같은 장면을 우리 팀의 실제 상황으로 채울 수 있다는 뜻입니다.

온보딩 문서는 앞으로도 필요합니다. 다만 문서가 끝나는 곳에서, 새 멤버가 처음으로 혼자 판단해야 하는 순간이 시작됩니다. 그 순간을 실제 프로젝트보다 먼저, 안전하게 겪어 볼 수 있게 하고 싶었습니다. 그래서 First Run을 만들었습니다.

직접 해 보기 — 무료 데모는 로그인 없이 브라우저에서 바로 플레이할 수 있고, 한국어·영어·일본어·스페인어를 지원합니다. First Run 플레이하기 →

다음 편은 이 시리즈의 마지막 질문입니다. 왜 하필 게임이고, 일 속의 놀이는 왜 중요한가. 요한 하위징아의 《호모 루덴스》에서 답을 찾아보겠습니다.

자주 묻는 질문

온보딩 문서는 이제 필요 없나요?+

필요합니다. 목표, 범위, 결정권자, 절차처럼 찾아볼 정보는 문서가 가장 좋습니다. 다만 문서는 지금 이 상황에서 무엇을 먼저 할지 판단하는 연습을 시키기 어렵기 때문에, 문서에 상황 속 판단 경험을 더하는 것이 좋다고 생각합니다.

First Run은 일반 e러닝 퀴즈와 무엇이 다른가요?+

정답을 외우는 문제가 아니라 실제 업무 상황에서 무엇을 먼저 할지 고르는 판단 문제입니다. 답변은 Excellent, Good, Risky, Poor 네 등급으로 평가되고 이유와 학습 포인트가 함께 제시되며, 틀린 퀘스트는 복습 게시판에서 다시 풀 수 있습니다.

First Run은 어떤 직무를 다루나요?+

개발자, PMO, 퍼블리셔, 기획자, 디자이너 5개 직무입니다. 레벨 3부터는 다른 직무의 퀘스트도 풀며 협업 감각을 넓힐 수 있습니다.

참고 자료

• First Run: 커스텀 게임형 온보딩 RPG
• PMP 오답노트 쓰는 법: 틀린 문제를 판단 규칙으로 바꾸는 6단계