
프로젝트에서 온보딩이 중요한 이유: 맥락 없이 내린 결정은 리스크가 된다
프로젝트에는 사람이 계속 합류합니다. 반복되는 설명, 늦어지는 적응, 맥락 없이 내린 결정을 PM의 시선으로 보고, 온보딩을 프로젝트 관리의 일로 다시 정리했습니다.
파트 1 / 3
프로젝트 팀은 처음 꾸린 모습 그대로 끝까지 가지 않을 때가 많습니다. 일정이 밀리면 개발자가 추가로 투입되고, 파트너사 인력이 바뀌고, 다른 팀의 기획자가 중간에 넘어옵니다. 그리고 새 사람이 올 때마다 프로젝트는 같은 질문을 다시 받습니다. “이건 왜 이렇게 하기로 했어요?”
이 시리즈는 그 질문에서 출발합니다. 세 편에 걸쳐 프로젝트에서 온보딩이 왜 중요한지, 좋은 온보딩은 어떤 모습인지, 그리고 왜 일 속에 놀이가 필요한지를 이야기하려 합니다. 그 생각들 끝에 제가 만든 것이 신규 입사자와 프로젝트 투입자를 위한 온보딩 RPG, First Run입니다.
프로젝트는 원래 사람이 바뀌는 일이다
PMP 이후 실무에서 달라진 점을 쓰면서 PMBOKPMBOK프로젝트 관리 지식 체계: 프로젝트 관리 협회(PMI)에서 발행하는 표준 가이드로, 프로젝트 성공을 위한 핵심 프로세스, 베스트 프랙티스 및 표준 용어집입니다.Read More → 8판의 프로젝트 정의를 소개한 적이 있습니다. “고유한 맥락에서 가치를 만들기 위해 수행하는 일시적인 시도.” 저는 이 정의에서 일시적이라는 단어를 온보딩과 연결해서 읽습니다.
운영 조직은 같은 사람들이 같은 일을 오래 하면서 맥락을 쌓습니다. 프로젝트는 다릅니다. 목표에 맞춰 사람을 모으고, 단계에 따라 필요한 사람이 달라지고, 끝나면 흩어집니다. 그 과정에서 합류는 예외가 아니라 일상입니다. 합류하는 사람도 한 종류가 아닙니다.
- 신규 입사자: 회사도 처음, 프로젝트도 처음입니다.
- 중간 투입자: 회사는 알지만 이 프로젝트의 결정 이력은 모릅니다.
- 외주·파트너 인력: 일은 잘하지만 우리 조직의 일하는 방식은 모릅니다.
- 직무 전환자: 사람과 회사는 알지만 새 역할의 판단 기준이 낯섭니다.
넷 다 온보딩 대상입니다. 그런데 보통 온보딩이라고 하면 첫 번째만 떠올립니다. 입사 첫 주의 회사 소개, 계정 발급, 복리후생 안내 같은 것들이요. 프로젝트에 필요한 온보딩은 그보다 훨씬 구체적입니다.
새 멤버가 맥락 없이 일하면 생기는 일
이런 장면을 떠올려 보겠습니다. 실제 사례가 아니라 설명을 위해 만든 가상의 상황입니다.
오픈을 3주 앞둔 프로젝트에 개발자 한 명이 새로 합류합니다. 둘째 날, 고객사 담당자가 메신저로 직접 연락합니다. “상품 목록에 필터 하나만 추가해 주실 수 있을까요? 간단한 거라서요.” 새 개발자는 친절하게 반나절 만에 기능을 붙입니다. 그런데 이 프로젝트는 범위 변경을 PM을 통해 변경 요청으로 받기로 합의해 두었고, 그 필터 하나 때문에 QA 범위와 UAT 시나리오가 늘어납니다. 아무도 이 변경을 모른 채 일주일이 지납니다.
새 개발자가 잘못한 걸까요? 저는 아니라고 생각합니다. 그는 규칙을 몰랐다기보다, 그 규칙이 바로 이 상황에 적용된다는 걸 몰랐을 가능성이 큽니다. 온보딩 문서에 “범위 변경은 PM을 통해”라는 한 줄이 있었더라도요.
이 장면에는 온보딩이 약할 때 생기는 비용 세 가지가 다 들어 있습니다.
| 비용 | 어떻게 나타나나 | PM의 시선으로 보면 |
|---|---|---|
| 반복되는 설명 | 사람이 올 때마다 같은 배경을 처음부터 다시 설명한다 | 시니어와 PM의 시간이 계획에 없던 곳으로 빠져나간다 |
| 늦어지는 적응 | 무엇을 먼저 해야 하는지 몰라 묻고 기다리는 시간이 길어진다 | 투입한 인력이 제 몫을 하기까지의 시간이 일정 가정에서 빠져 있다 |
| 맥락 없는 결정 | 선의로 내린 결정이 합의된 범위·절차와 어긋난다 | 범위, 품질, 일정에 영향을 주는 리스크가 조용히 쌓인다 |
앞의 둘은 눈에 보이는 비용입니다. 정말 무서운 건 세 번째입니다. 반복 설명은 시간이 들 뿐이지만, 맥락 없이 내린 결정은 아무도 모르는 사이에 프로젝트의 방향을 조금씩 바꿉니다.
숫자로 봐도 온보딩은 어렵다
이건 프로젝트만의 문제가 아닙니다. 조직 전반에서도 온보딩은 잘 안 되는 일로 꼽힙니다.
- Gallup은 직원 중 단 12%만이 자신의 조직이 신규 직원 온보딩을 잘한다고 강하게 동의한다고 보고했습니다.
- SHRM에 따르면 새 역할에서 성과를 낼 준비와 지원을 받았다고 느낀 신규 입사자는 29%에 그쳤습니다.
두 숫자 모두 신규 입사자 전반에 관한 것이고, 프로젝트 중간 투입자만 따로 본 숫자는 아닙니다. 다만 회사에 새로 들어온 사람조차 준비됐다고 느끼기 어렵다면, 이미 달리고 있는 프로젝트에 며칠 만에 투입되는 사람은 더 말할 것도 없다고 생각합니다.
온보딩은 프로젝트 관리의 일이다
그래서 저는 프로젝트 온보딩을 HR이 준비하는 행사가 아니라 PM이 관리해야 할 일로 봅니다. PM이 원래 하는 일과 온보딩을 겹쳐 보면 이렇습니다.
| PM의 일 | 온보딩에서 할 일 |
|---|---|
| 자원·팀 관리 | 투입 시점과 함께 적응 기간도 계획에 넣는다. 첫 주에 누가 무엇을 알려 줄지 정한다 |
| 지식 전달 | 결정 이력, 하지 않기로 한 것, 지난 실수에서 배운 점을 특정 사람의 기억이 아니라 구조로 남긴다 |
| 이해관계자 정렬 | 누가 결정하고, 무엇을 누구에게 물어야 하는지 첫날 알려 준다 |
| 리스크 관리 | 새 멤버의 적응 기간 자체를 리스크로 보고 대응 계획을 세운다 |
| 변경 통제 | 변경 요청 절차를 문서만이 아니라 실제 상황으로 보여 준다 |
표의 마지막 줄이 이 글의 핵심입니다. 절차를 알려 주는 것과, 절차가 필요한 순간을 알아보게 하는 것은 다른 일입니다. 앞의 가상 장면에서 새 개발자에게 필요했던 건 규칙 목록이 아니었습니다. 고객사 담당자가 “간단한 거”라며 직접 부탁해 오는 순간을 미리 한 번 겪어 보는 경험이었습니다.
프로젝트 온보딩에 꼭 담아야 할 5가지
프로젝트에 새 사람이 합류할 때, 저라면 최소한 이 다섯 가지는 챙기겠습니다.
- 왜 하는가: 이 프로젝트가 끝나면 누가 무엇을 더 잘하게 되는지.
- 어디까지 하는가: 합의된 범위와, 하지 않기로 한 것.
- 누가 정하는가: 결정권자, 소통 경로, 에스컬레이션 기준.
- 바뀔 때 어떻게 하는가: 변경 요청 절차와 그렇게 하는 이유.
- 자주 마주치는 상황에서 어떻게 판단하는가: 일정 지연, 요구사항 충돌, 품질 이슈 앞에서 이 팀은 무엇을 먼저 하는지.
1번부터 4번까지는 문서로도 어느 정도 전할 수 있습니다. 5번은 다릅니다. 판단 기준은 읽어서보다 직접 판단해 보면서 몸에 붙습니다. 그리고 대부분의 온보딩이 가장 약한 곳도 바로 여기라고 생각합니다.
그래서 First Run을 만들었다
이 글을 쓰면서 계속 돌아온 곳은 5번이었습니다. 판단 기준은 문서로 잘 전해지지 않는데, 프로젝트를 흔드는 건 대개 그 판단이니까요. 그렇다면 판단을 미리 연습해 볼 수 있는 온보딩이 있어야 한다고 생각했습니다. 그게 First Run입니다.
First Run은 신규 입사자와 프로젝트 투입자가 실제 업무 상황을 퀘스트로 경험하는 온보딩 RPG입니다. Make Feelbetter라는 가상의 IT 회사에 합류해 개발자, PMO, 퍼블리셔, 기획자, 디자이너 중 하나의 역할을 고르고, 멘토 NPC가 주는 퀘스트에서 판단을 내립니다. 일정 지연, API 오류, 요구사항 정리, UI 판단, 접근성 문제처럼 실제 업무에서 마주칠 수 있는 상황들이고, PMO 역할에는 리스크 대처, 일정 조율, 변경 통제 퀘스트가 들어 있습니다. 앞의 가상 장면 같은 순간을 실제 프로젝트가 아니라 게임 속에서 먼저 겪어 보게 하자는 생각이었습니다.

First Run은 PMP® 자격을 가진 PM의 실무 경험을 바탕으로 설계했고, 회사와 프로젝트에 맞게 바꿀 수 있습니다. 프로젝트별 온보딩 시나리오, 내부 업무 프로세스, 자주 발생하는 실무 상황을 퀘스트로 만들 수 있어서, 신규 입사자 온보딩뿐 아니라 프로젝트 킥오프 교육이나 외주·파트너사 업무 교육에도 쓸 수 있습니다.
프로젝트에서 온보딩은 사람이 들어올 때마다 다시 시작되는 일입니다. 그 시작을 설명 대신 경험으로 바꿀 수 있다면, 새 멤버가 내리는 첫 결정도 덜 위험해질 거라고 믿습니다. 그래서 First Run을 만들었습니다.
직접 해 보기 — 무료 데모는 로그인 없이 PC와 모바일 브라우저에서 바로 플레이할 수 있습니다. First Run 플레이하기 →
다음 편에서는 한 걸음 더 들어가, 왜 문서로 하는 온보딩은 잘 남지 않는지, 그리고 좋은 온보딩은 어떤 모습인지 이야기하겠습니다.
자주 묻는 질문
프로젝트 온보딩과 신규 입사자 온보딩은 무엇이 다른가요?
신규 입사자 온보딩이 회사와 조직에 적응하는 과정이라면, 프로젝트 온보딩은 진행 중인 프로젝트의 목표, 범위, 결정권자, 변경 절차, 자주 마주치는 상황의 판단 기준을 빠르게 익히는 과정입니다. 회사에 오래 다닌 사람도 새 프로젝트에 합류하면 프로젝트 온보딩이 필요합니다.
First Run 데모는 무료인가요?
네. 로그인이나 결제 없이 웹 브라우저에서 바로 플레이할 수 있고, PC와 모바일을 모두 지원합니다. 공개 데모의 플레이 기록은 계정 없이 해당 브라우저에만 저장됩니다.
First Run을 우리 프로젝트에 맞게 바꿀 수 있나요?
네. 회사의 실제 업무 시나리오와 프로젝트 규칙으로 퀘스트를 만들고, 실제 멘토를 본뜬 NPC, 오피스 맵, 브랜딩을 반영한 맞춤 버전을 구축할 수 있습니다. firstrun.fit의 문의 페이지에서 상담을 요청할 수 있습니다.
참고 자료
연결된 글
같은 시리즈, 직접 링크, 주제 모음, 태그로 이 글과 이어진 글입니다.
시리즈 · 온보딩, 플레이하다 · 1/3편
시리즈 전체 3편 →관련 프로젝트
이 글에서 다룬 프로젝트 · 신규 입사자와 프로젝트 투입자를 위한 게임형 온보딩 RPG입니다. 가상의 IT 회사 Make Feelbetter에 합류해 개발자·PMO·퍼블리셔·기획자·디자이너 중 하나를 고르고, 멘토 NPC가 주는 퀘스트에서 실제 업무 상황의 판단을 내립니다. 로그인 없이 브라우저에서 무료로 플레이할 수 있습니다.
주제 모음 · 커리어·온보딩
모음 전체 10편 →아이디어 진화
DailySay에 묻기
이어서 읽기

온보딩은 문서가 아니라 경험이다: 읽은 것보다 판단해 본 것이 남는다
온보딩 자료는 많은데 새 멤버는 왜 여전히 헤맬까. 문서형 온보딩이 남기지 못하는 것과, 상황 속 판단·역할별 경로·이유 있는 피드백·안전한 실패로 이루어진 좋은 온보딩을 정리했습니다.





