People & Culture

[26-1 온보딩 회고 #01] 게임 동아리가 온보딩에 3주를 투자하는 이유 - 마인크래프트로 50명을 한 팀으로 만든 설계

hmgames / 2026. 5. 15. 09:29
더보기
한 줄 요약
50명 규모로 커진 동아리에 들어온 26명의 신입을, 3주 안에 한 팀으로 움직이게 만들기 위해 우리가 어떤 온보딩을 설계했는지 정리한 글이에요.
마인크래프트 위에 직접 구축한 자체 게임 환경, 6멘토·1총괄 운영 구조, 직무별 평가 기준, 그리고 솔직한 한계까지 모두 담았어요.

 

들어가며

안녕하세요. 회기동 막걸리 회장 이종인입니다.

 

지난 4월 Founder's Note에서 “온보딩에 대한 자세한 얘기는 다른 글로 풀어볼 예정”이라고 약속드렸어요.

이 글이 그 약속을 지키는 첫 번째 글이에요.

 

회기동 막걸리는 이번 2026-1학기에 50명 내외 규모가 되었어요.

그중 신입은 26명. 학기 시작과 동시에 우리는 3주 동안 신입 온보딩 프로그램을 운영했고, 그 과제는 마인크래프트로 팀별 던전을 만드는 거였어요.

“게임 동아리가 게임을 만들기 전에, 마인크래프트로 던전을 만들었다고요?”

 

네, 맞아요.

이 글은 우리가 왜 그렇게 했는지, 어떻게 설계했고, 어디서 잘됐고 어디서 부족했는지를 풀어내는 회고예요.

운영을 고민하는 다른 동아리, 합류를 고민하는 잠재 지원자, 그리고 우리 활동을 지켜봐 주시는 분들 모두에게 도움이 되었으면 해요.

 


01. 왜 마인크래프트 던전인가 - 토이 프로젝트로 게임 개발을 미리 경험하기

마인크래프트 온보딩 팀별 던전 홍보물

 

학생 동아리의 흔한 신입 환영 방식은 자기소개와 친목 모임이에요.

우리도 그런 시기를 거쳤어요. 그런데 동아리가 50명 규모로 커지면서 그 방식이 더는 작동하지 않았어요.

 

지난 학기 회고에서 반복적으로 나온 피드백은 다음과 같았어요.

  • “3주가 지나도 같은 팀 멤버 이름조차 잘 모른다.”
  • “내가 무엇을 잘하는지, 무엇을 배워야 하는지 알 수 없다.”
  • “기존 멤버와 신입 사이의 거리가 좁혀지지 않는다.”

사실 이전에 언리얼이나 유니티로 미니 게임을 만드는 안을 시도해본 적도 있어요.

 

결과는 실패였어요. 신입들의 엔진 숙련도 편차가 너무 컸고, 비개발 직군은 진입조차 어려웠어요.

3주 안에 결과물이 나오지 않으니 동기 부여도 떨어졌고요.

 

“게임 개발 동아리니까 진짜 엔진으로 해야지”라는 생각이 도리어 협업의 의미를 흐렸던 거예요.

 

그래서 이번에는 발상을 완전히 뒤집었어요.

온보딩의 목표를 “진짜 게임을 만드는 것”이 아니라 “토이 프로젝트로 게임 개발의 전체 흐름을 한 번 통과해보는 것”으로 재정의했어요.

이미지: 토이 프로젝트의 정의

 

이 재정의 위에서 온보딩 프로그램의 기획 의도는 두 갈래로 갈라졌어요.

 

첫째, 개발 본부 인원에게는 게임 개발 과정 자체의 경험을 주려고 했어요

기획서를 쓰고, 일정에 맞춰 개발하고, 다른 직군과 협업하고, 의도대로 안 되는 지점을 만나고, 그 안에서 타협안을 찾아가는 흐름 전체요.

3주 안에 한 번 이 흐름을 통과해본 사람과 안 통과해본 사람의 학기 후반 퍼포먼스는 완전히 달라요.

 

둘째, 운영·사업 본부 인원에게는 게임 개발 도메인 경험을 주려고 했어요

게임이 어떻게 만들어지는지를 옆에서 직접 봐야, 마케팅·사업기획·운영 업무에서 개발팀과 같은 언어로 대화할 수 있거든요.

게임을 한 번도 만들어보지 않은 사람이 게임 동아리의 사업기획을 한다는 건 한계가 명확해요.

 

“이유 있게 실패하는 경험”도 의도된 설계였어요

 

3주짜리 토이 프로젝트에서 한 번 부딪혀보면, 그다음 실제 프로젝트를 시작할 때 “지난번에 이래서 안 됐으니까 이번엔 이렇게 해보자”는 가설이 생겨요.

 

동기 부여는 강연이나 매뉴얼이 아니라, 본인이 실패를 겪고 거기서 다음 시도를 떠올릴 때 가장 강하게 작동해요.

이미지: 게이미피케이션의 정의

 

그리고 한 가지 더. 게이미피케이션으로 “놀면서 하나가 되자”는 취지도 있었어요.

학습과 평가라는 단어가 주는 무게를 덜어내고, 신입들이 첫 3주를 “재미있는 게임”으로 기억하게 만들고 싶었어요.

같은 동아리에 속했다는 동질감은 회식이나 OT보다 함께 무언가를 플레이하면서 만든 추억에서 더 깊게 생긴다고 봤거든요.

 

마인크래프트는 이 모든 조건을 동시에 만족시켰어요.

  • 진입 장벽이 낮아 비개발 직군도 즉시 참여할 수 있고
  • 던전이라는 형식이 레벨 디자인·내러티브·비주얼·체험 흐름까지 게임 개발의 축소판이 되고
  • 무엇보다 그 자체가 이미 게임이라는 게 결정적이었어요

 


02. 진짜 게임처럼 - 우리가 직접 구축한 마인크래프트 환경

스크린샷: 마인크래프트 서버 플레이

 

그냥 마인크래프트를 켜고 "던전을 만들어보세요”로는 위 의도를 전부 살릴 수 없어요.

바닐라 마크에서 던전 제작은 결국 블록 쌓기에 가까워요. 우리가 원한 건 “진짜 게임을 만들고 있다”는 감각이었어요.

 

그래서 인프라팀이 온보딩 전용 마인크래프트 서버를 직접 구축했어요.

스트리머들이 운영하는 RPG 서버처럼, 신입들이 접속하는 순간 “이게 정말 우리 동아리만의 게임 세계구나”를 느낄 수 있게요.

 

자체 개발한 시스템은 크게 네 가지예요.

  1. 던전 시스템: 기믹, 몬스터, 보스 등을 구현할 수 있는 시스템이에요.
  2. 직업 시스템: 캐릭터에 직업을 부여하고 직업별 능력치와 스킬이 작동해요.
  3. 펫/탈 것 시스템: 동료 캐릭터를 데리고 다닐 수 있어요.
  4. 치장 시스템: 외형 커스터마이징으로 자기 캐릭터를 꾸밀 수 있어요.
  5. 퀘스트 시스템: NPC와 상호작용해 미션을 받고 보상을 받을 수 있어요.

이 시스템들의 진짜 가치는 신입들이 던전을 만들 때 발휘됐어요.

자기 팀 던전 안에 직업별 분기 동선을 설계할 수 있고, 펫이 동행하는 구간을 의도할 수 있고, 퀘스트로 내러티브를 풀 수 있어요.

상용 게임의 던전 디자이너가 다루는 변수와 본질적으로 같은 변수를 다루게 되는 거예요.

 

이미지: 던전 코드의 역할

 

여기에 한 가지 도구를 더 만들었어요.

바로 “던전 코드”라는 명령어 기반의 자체 던전 개발 도구예요.

 

블록을 일일이 손으로 쌓는 게 아니라, 명령어로 던전의 구조·트리거·이벤트를 정의할 수 있게 만든 환경이에요.

신입들은 “코드로 게임 콘텐츠를 만든다”는 경험을 진짜 IDE 환경에 가깝게 체험할 수 있었어요.

 

개발 직군 신입에게는 이게 곧 게임 스크립팅의 경험이 됐고, 비개발 직군 신입에게는 “개발자들이 매일 다루는 도구가 이런 거구나”라는 도메인 이해가 됐어요.

 

의도했던 기획이 정확히 작동한 부분이에요.

물론 이 환경을 만들기까지 인프라팀이 적지 않은 시간을 썼어요.

 

그렇지만 이번 학기에 만들어둔 자산은 다음 학기에도, 그다음 학기에도 계속 쓸 수 있는 인프라예요.

한 번의 투자로 매 학기 온보딩의 품질이 보장되는 구조를 만든 거예요.

 


03. 6멘토 + 1총괄 - 운영 구조의 설계 원칙

 

이미지: 운영 조직도

 

운영 구조를 짤 때 가장 먼저 결정한 건 멘토를 팀당 2명씩 배치한다는 원칙이었어요.

 

이유는 단순해요.

한 명의 멘토만 두면 그 멘토의 직무 색깔에 팀이 끌려가요.

개발자 멘토 한 명이 붙으면 팀이 기술적인 완성도에만 집중하고, 기획자 멘토 한 명이 붙으면 결과물보다 회의가 많아지죠.

 

우리는 게임 개발 동아리이지만, 동시에 사업과 운영이 함께 굴러가는 조직이에요.

그래서 모든 팀에 개발 멘토 1명 + 사업·운영 멘토 1명을 페어로 배치했어요.

 

이 페어링이 자연스럽게 만들어내는 효과가 있어요.

신입은 3주 동안 두 가지 시선을 동시에 받아요.

  • “이 던전의 동선이 게이머의 경험을 어떻게 끌고 가는가”
  • “이 작업을 일정 안에 끝낼 수 있는가, 어떤 협업 도구로 어떻게 기록할 것인가”

두 시선이 한 팀 안에서 부딪힐 때, 신입은 “혼자 잘하는 것”과 “함께 만드는 것”의 차이를 자연스럽게 학습해요.

이미지: 총괄의 역할

 

총괄 1명의 역할은 따로 있었어요.

 

멘토와 팀 사이에서 해결되지 않는 문제, 팀과 팀 사이의 형평성 문제, 평가 기준 해석의 차이 등.

이런 이슈가 발생했을 때 결정권을 가진 단일 창구가 필요했어요.

 

총괄 없이 멘토 6명만 두면 의사결정이 분산되어 신입들이 혼란을 느꼈을 거예요.

 


04. 직무별 평가 기준 - “내가 무엇으로 평가받는지” 미리 알려주기

스크린샷: 직무별 평가 기준표 일부 - 개발·기획·아트·운영·사업

 

이번 온보딩에서 가장 공들인 부분이 평가 기준이에요.

지난 학기까지 신입들이 가장 자주 한 질문은 “제가 잘하고 있는 건가요?”였어요.

 

멘토는 “잘하고 있어요”라고 답하지만, 신입 입장에서는 그 답이 위로인지 평가인지 구분이 안 됐어요.

평가 기준이 멘토의 머릿속에만 있었기 때문이에요.

 

그래서 이번엔 직무별로 평가 항목을 명문화한 기준표를 온보딩 시작 전에 신입들에게 전달했어요.

직무별 평가 항목은 다음과 같았어요.

직무 주요 평가 항목
프로그래밍 코드 협업, 문서화 수준
기획 의사결정 근거, 커뮤니케이션
아트 컨셉 일관성, 작업 가시성
운영 일정 관리, 이슈 대응
사업 시장 리서치의 깊이, 발표 구성력

 

각 항목마다 “시도 / 수행 / 우수”의 3단 기준을 함께 적었어요.

이 기준표의 진짜 가치는 평가 그 자체가 아니라, 신입이 스스로 행동을 설계할 수 있게 해준다는 데 있었어요.

예를 들어 “내가 운영 직군이라면 이번 주에 일정 이슈를 한 번이라도 미리 공유해봐야겠다”는 식의 자기주도가 가능해진 거예요.

이미지: 26-1 온보딩 회고 중 발췌

 

 

기준표를 만드는 과정 자체도 어렵지 않았어요.

직무 리드들이 각자 자신의 직무에서 “신입에게 기대하는 최소 행동”을 정의하고, 운영진이 형식을 통일했어요.

일주일이면 충분했어요.

 


05. R&R 혼선이라는 한계 - 우리 설계의 솔직한 반성

지난 Founder's Note에서 짧게 짚었지만,

이번 학기에는 본부·팀 체계로 조직을 개편하면서 R&R(Role & Responsibility, 역할과 책임)이 재정의되었어요.

 

그리고 그 변화가 온보딩 운영에도 영향을 줬어요.

가장 명확한 문제는 멘토 본인이 자기 역할의 범위를 정확히 모르고 시작한 경우가 있었다는 점이에요.

  • “내가 어디까지 개입해야 하는가”
  • “팀의 의사결정에 어떤 권한을 가지는가”
  • “총괄에게 언제 도움을 요청해야 하는가”

이 질문에 대한 답이 멘토마다 달랐어요.

결과적으로 어떤 팀은 멘토가 깊게 개입했고, 어떤 팀은 거의 방치된 채로 흘러갔어요.

 

원인은 두 가지였어요.

첫째, 조직 개편과 온보딩이 같은 시기에 진행됐어요

본부 승격, 신규 팀 신설, 신입 모집, 온보딩 설계가 동시에 굴러가다 보니 멘토들도 역할에 적응 중이었어요.

자기 R&R도 정리되지 않은 상태에서 신입의 멘토 역할까지 맡은 셈이에요.

 

둘째, 멘토 온보딩을 별도로 운영하지 않았어요

신입을 위한 온보딩에는 3주를 투자했으면서, 정작 멘토들에게는 “이번 학기 멘토 R&R은 이렇습니다”를 정리해 전달하는 자리가 없었어요.멘토 매뉴얼은 있었지만 문서로만 존재했고, 함께 읽고 합의하는 시간을 만들지 못했어요.

 

이 한계는 평가 만족도 자체에는 큰 영향을 주지 않았어요.

직무별 평가 기준이 명확했기 때문에 신입들은 멘토 개입 정도와 무관하게 자기 방향을 잡을 수 있었거든요.

 

다만 “멘토와의 관계에서 무엇을 배웠는가”라는 질적 경험에서는 팀 간 격차가 분명히 있었어요.

같은 동아리에 들어왔는데 멘토에 따라 경험의 깊이가 달랐다는 건, 운영진이 다음 학기에 반드시 풀어야 할 과제예요.

 


06. 숫자로 본 결과

3주짜리 프로그램을 운영하고 나면 가장 먼저 궁금해지는 건 "잘된 건가?"예요.

운영진이 체감으로 느끼는 "잘됐다"와 실제로 측정된 "잘됐다"는 다를 수 있으니까요.

 

이번 온보딩이 끝난 직후, 우리는 두 가지 축에서 숫자를 모았어요.

신입들이 어떻게 느꼈는지를 묻는 만족도 축, 그리고 신입들이 실제로 무엇이 달라졌는지를 묻는 효과 축이에요.

 

만족도 — 신입이 어떻게 느꼈는가

멘토 평가 평균 4.83 / 5.00 온보딩 프로그램 긍정 평가 90% 이상

 

멘토 평가가 5점 만점에 4.83점이 나온 부분은 운영진 입장에서 안도와 숙제를 동시에 안긴 숫자였어요.

 

멘토 한 명 한 명이 자기 R&R도 정리되지 않은 상태에서 신입을 맡았던 학기였는데도, 신입들이 멘토와의 경험을 거의 최상단에 가깝게 평가해줬어요. 

 

팀 간 멘토링 격차가 분명히 있었음에도 평균 자체는 높았다는 건, 격차가 평균을 끌어내릴 만큼 깊지는 않았다는 뜻이기도 해요.

 

프로그램 자체에 대한 긍정 평가 90% 이상은 마인크래프트 던전 제작이라는 과제 설계에 대한 직접적 답이에요. 

환영회 대신 3주짜리 프로젝트를 시켰을 때 신입들이 부담스러워할 가능성은 우리도 가장 우려했던 부분이었거든요.

 

90% 이상이 긍정으로 답했다는 건 "학습과 평가의 무게를 게임처럼 풀어낸다"는 우리 기획 의도가 실제로 작동했다는 신호예요.

 

효과 — 신입에게 실제로 무엇이 달라졌는가

업무 프로세스·게임 개발 이해도 기존 대비 80% 증가 팀별 업무 적응 기간 기존 4주 → 2주로 단축

 

만족도가 기분이 좋았는가를 묻는 숫자라면, 이 두 지표는 온보딩이 끝난 뒤 신입이 실제로 일할 수 있게 되었는가를 묻는 숫자예요.

이해도 80% 증가는 이번 온보딩의 가장 핵심적인 효과 지표예요. 

 

동아리 내 업무 프로세스와 게임 개발 방법에 대한 이해도가 기존 학기 대비 80% 더 올랐다는 건, 신입이 실제 프로젝트에 투입됐을 때 처음부터 같은 언어로 대화할 수 있다는 의미예요.

 

비개발 직군이 던전 코드 도구를 직접 만져본 경험, 직군별 평가 기준을 미리 읽고 자기 행동을 설계한 경험, 자체 마크 환경 안에서 진짜 게임을 만든다는 감각을 체험한 경험 — 이 세 가지가 합쳐져 만들어낸 숫자라고 봐요.

 

적응 기간 2주 단축은 가장 운영적으로 와닿는 지표예요.

기존 학기에는 신입이 실제 프로젝트에 들어간 뒤 자기 역할을 찾고 팀에 녹아드는 데 평균 4주가 걸렸어요.

 

이번 학기에는 그 기간이 2주로 줄었어요. 절반이에요. 

온보딩에 투자한 3주가, 이후 프로젝트에서 2주를 벌어준 셈이에요.

 

단순 시간 산수로만 봐도, 3주 투자해 2주를 회수한 게 아니라 26명이 각자 2주씩 빠르게 합류했으니 동아리 전체 누적 가용 시간으로는 훨씬 큰 회수예요.

 

숫자가 말해주지 않는 것

다만 짚어둘 게 있어요. 위 네 지표는 모두 온보딩 직후 자기 보고와 운영진 관찰에 기반해요.

 

진짜 효과는 6개월·1년 단위로 이 신입들이 어떤 결과물을 내고, 얼마나 동아리에 남는지에서 드러날 거예요.

이번 회고의 숫자는 출발선의 기록이고, 다음 학기 온보딩 회고에서 이 숫자들이 어떻게 이어졌는지 다시 보고드릴게요.


07. 다음 학기에 바꿀 3가지

이번 회고를 정리하면서 운영진이 합의한 다음 학기 변경 사항이 세 가지 있어요.

이 자리에서 적어두고, 다음 학기에 실제로 어떻게 바뀌었는지 다시 보고드릴게요.

 

첫째, 멘토 온보딩을 별도 프로그램으로 분리할 거예요

신입 온보딩이 시작되기 1~2주 전에, 멘토들이 모여 자기 R&R과 평가 기준을 함께 읽고 합의하는 자리를 만들어요.

멘토가 흔들리지 않아야 신입도 흔들리지 않아요.

 

둘째, 자체 마크 환경을 더 깊은 게임 개발 경험으로 확장할 거예요

이번 학기 던전 코드 도구가 좋은 반응을 얻은 만큼, 다음 학기에는 명령어 기반이 아닌 실제 프로그래밍 언어와 같이 개발할 수 있게 코드를 플러그인화 할 거에요.

 

그러면 아래와 같은 것들도 직접 만들 수 있겠죠.

  • 새로운 퀘스트 타입
  • 미니 이벤트 트리거
  • 직업별 상호작용 구조

“주어진 도구로 콘텐츠를 만든다”에서 “도구 자체를 한 칸 확장해본다”로 한 발 나아가는 거예요.

게임 개발의 핵심 경험을 한 층 더 진하게 줄 수 있어요.

 

셋째, 온보딩 과제 결과물을 외부에 공개하는 채널을 만들 거예요

이번에 만든 던전들이 동아리 내부 시상식으로만 끝났는데,

다음 학기에는 영상이나 플레이 다이어리 형태로 블로그에 게시해 신입들의 첫 결과물이 외부에서도 보이도록 할 계획이에요.

 

신입에게 “내 작업이 외부에 보인다”는 경험을 첫 학기부터 주고 싶어요.


08. 마치며 - 그리고 다음 글 예고

3주짜리 온보딩 프로그램을 설계하는 건 생각보다 큰 작업이었어요.

과제를 정하는 데에만 운영진 회의 여러 차례가 필요했고, 자체 마인크래프트 환경을 만들고 멘토를 배치하고 평가 기준을 정리하는 일도 만만치 않았어요.

 

그럼에도 우리가 신입 온보딩에 3주를 투자한 이유는 명확해요.

신입이 동아리에 들어와서 처음 3주 동안 어떤 경험을 하느냐가, 그 신입이 1년 동안 어떤 동아리원으로 성장하느냐를 결정한다고 믿기 때문이에요.

 

좋은 결과물을 만드는 동아리가 되려면, 먼저 좋은 사람을 잘 받아들이는 동아리가 되어야 해요.

 

이번 글은 온보딩 프로그램의 설계 원칙과 환경에 집중했어요.

 

다음 글에서는 각 팀이 3주 동안 자체 마크 환경 위에서 어떻게 던전을 만들어갔는지를 깊이 들여다보려고 해요.

같은 도구·같은 멘토 구조 안에서도 팀마다 어떻게 다른 결과물이 나왔는지를 보여드릴게요.

 

긴 글 읽어주셔서 감사합니다.

회기동 막걸리에 관심 있으신 분들은 댓글이나 동아리 소개 페이지에서 더 많은 이야기를 만나실 수 있어요.