[26-1 온보딩 회고 #02] 같은 온보딩 시스템 안에서도 팀이 다르게 움직이는 이유 — 협업이 막히는 두 지점과 풀어낸 방식

 

한 줄 요약

같은 온보딩 시스템, 같은 과제, 같은 멘토 구조 안에서도 팀은 갈려요. 회기동 막걸리 26-1 신입 온보딩에서 세 팀이 협업의 두 분기점을 어떻게 다르게 통과했는지 정리한 글이에요. 새로 결성된 팀이 첫 몇 주에 반드시 마주치는 문제와, 거기서 갈라지는 길의 패턴을 담았어요.

---

들어가며

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

지난 온보딩 회고 #01 포스트에서는 우리가 어떤 온보딩 시스템을 설계했는지 다뤘어요.

3주짜리 프로그램, 자체 마인크래프트 환경, 6멘토·1총괄 구조, 직무별 평가 기준에 대해 설명했죠.

 

그런데 시스템을 잘 설계해도 그 안에서 실제로 무언가가 만들어지는 건 결국 각 팀 안에서 일어나는 일들이에요.

같은 도구를 받고, 같은 과제를 풀고, 같은 멘토 구조 안에서 움직였지만, 26-1학기 세 팀은 완전히 다른 던전을 만들었어요.

던전의 결과물만 다른 게 아니라, 3주 동안 팀이 작동한 방식 자체가 달랐어요.

 

이 글은 그 차이가 어디서 생겼는지를 따라가는 글이에요.

결론부터 말하면, 팀이 갈리는 지점은 두 군데였어요. 새로운 환경을 처음 마주했을 때, 그리고 팀 내부에서 의견이 부딪혔을 때. 모든 팀이 이 두 지점을 통과해야 했고, 세 팀이 각기 다른 방식으로 통과했어요.

 

이 글이 같은 종류의 고민을 하는 다른 팀에게도, 우리 동아리에 합류를 고민하는 분들에게도 도움이 되었으면 해요.

---

01. 세 팀이 시작한 자리

이번 온보딩 팀 빌딩에는 스타크래프트 종족을 모티프로 했어요. 세 팀의 이름이 각각 테란·저그·프로토스예요.

종족명이 평가 기준이나 멘토링 방식을 결정짓진 않았지만, 기획 단계에서 각 팀이 자기 팀의 정체성을 잡는 데 가벼운 영감을 줬어요.

 

세 팀의 출발선은 이랬어요.

테란 팀

 

프로그래밍 2, 아트 1, 서비스 기획자 1, 대외협력 PM 1, 사운드 디자이너 1. 멘토 페어는 프로그래밍 멘토와 인프라 팀장.

던전 콘셉트는 "다른 행성에 착륙한 플레이어가 끊임없이 몰려오는 테란 군대의 공격을 피해 미션을 수행하고, 결국 테란을 무너뜨리는 어드벤처 액션"이었어요. 외부의 위협이 끊임없이 밀려오는 수비-반격 구도가 핵심이에요.

 

저그 팀 

 

프로그래밍 2, 아트 1, 기획 2, 운영 1. 멘토 페어는 프로그래밍 멘토와 사업·운영 겸직 멘토.

던전 콘셉트는 "수상한 연구소의 순찰을 맡은 경비원 단체가 협동으로 비상 사태에서 벗어나 연구소를 탈출하는 어드벤처". 다인 협동과 상황 대응 중심의 던전이에요. 기획 인원이 두 명이라는 점이 다른 팀과 가장 다른 특징이었어요.

 

프로토스 팀 

 

프로그래밍 2, 아트 1, 기획 1, 개발 PM 1, 사운드 디자이너 1. 멘토 페어는 프로그래밍 멘토와 운영·시나리오 겸직 멘토.

던전 콘셉트는 "탐정을 구한다는 모집글을 보고 버려진 성소에 진입한 4인 플레이어가 단서를 수집하고 비밀을 풀어 나가는 추리형 어드벤처". 단서 수집과 추리가 메인 메커니즘이라 세 팀 중 던전 구조의 복잡도가 가장 높았어요.

 

세 팀의 직군 구성을 보면 이미 흥미로운 차이가 보여요.

테란 팀은 기획·운영·사업·사운드까지 비개발 직군이 다양하게 섞였고, 저그 팀은 기획에 무게가 실렸고, 프로토스 팀은 PM이 별도로 있어 의사결정 라인이 가장 정돈된 구조였어요.

 

이 차이가 뒤에서 다룰 두 분기점에서 각기 다른 방식으로 드러나요.

---

02. 첫 번째 분기점 — 새로운 환경을 처음 마주했을 때

[스크린샷 - 마인크래프트 서버 가이드]

 

우리는 신입들이 진짜 게임을 만들고 있다는 감각을 주기 위해 자체 마인크래프트 환경을 구축했어요. 던전·직업·펫·치장·퀘스트 시스템에, 명령어 기반의 던전 코드 개발 도구까지.

 

문제는 이 환경이 처음 접해보는 사람에게는 직관적이지 않다는 점이었어요.

개발 직군 신입에게도 학습 곡선이 있었고, 비개발 직군에게는 더 가파른 벽이었어요.

"어디서부터 손대야 하는지 모르겠다"가 1주 차 멘토 평가에서 세 팀 모두 공통적으로 발견된 첫 번째 신호였어요.

 

같은 벽 앞에서, 세 팀은 분명히 다르게 움직였어요.

 

테란 팀은 가장 먼저 구조를 만들었어요.

 

프로그래밍 팀원과 서비스 기획자가 주도해서 "우리가 파악해야 할 범위가 어디까지인가, 어떤 순서로 갈 것인가"를 먼저 정리했어요. 그 위에서 팀원들이 각자 자신의 역할을 나눠 가졌고, 모르는 부분은 두 가지 경로로 해결했어요.

 

담당 멘토에게 질문을 던지는 외부 경로와, 인게임에서 개인적으로 실험을 반복하는 내부 경로.

 

이 두 경로가 동시에 굴러가면서 협업 툴과 개발 환경에 대한 이해도가 빠르게 올라갔어요. 

팔로워십과 팔로우의 역할이 분명했다는 게 멘토 평가에 남은 표현이에요.

 

저그 팀의 첫 주는 결이 달랐어요.

 

팀 전체적으로 주도하는 사람보다 기다리는 사람이 많았고, 인게임 활동 자체에 참여가 저조했어요.

그 결과 협업 툴 확인과 개발 환경 파악에서 다른 두 팀에 비해 진도가 늦었어요.

 

이 부분은 한 가지 짚어둘 필요가 있어요. 저그 팀이 덜 열심히 했다는 의미가 아니에요.

팀의 직군 구성을 다시 보면 기획 두 명·프로그래밍 두 명·아트 한 명·운영 한 명으로, 다른 두 팀과 달리 PM이나 서비스 기획자처럼 진행을 끌고 가는 직군이 명확히 한 사람으로 잡혀 있지 않았어요.

 

비슷한 무게의 직군이 분산되어 있을 때, 누가 먼저 "이 범위를 이 순서로 가자"고 말할지가 모호해져요.

의도된 분산이 자연스러운 주저를 만든 경우예요.

 

이 관찰은 다음 학기 팀 빌딩에서 직군 구성만큼 진행 주도권의 위치도 함께 설계해야 한다는 숙제로 우리에게 남았어요.

 

프로토스 팀은 또 다른 길로 갔어요.

 

첫 주부터 인게임 활동에 대부분의 인원이 적극적으로 참여했고, 회의도 잦았어요.

다만 회의의 무게중심이 환경 이해보다 아이디어 합의 쪽에 실려 있어서, 개발 환경과 온보딩 프로세스에 대한 이해 자체는 다소 늦게 따라왔어요.

 

그런데 이걸 질문이라는 단일 경로로 풀어냈어요.

막히면 멘토에게 묻고, 또 막히면 또 묻는 방식이 반복됐고, 결과적으로 환경 이해도는 대부분 회복됐어요.

가장 복잡한 던전 콘셉트(추리형)를 가진 팀이었던 만큼 내가 모르는 것을 빠르게 드러내는 문화가 결정적으로 작동한 거예요.

 

세 팀의 대응 방식을 한 축으로 정렬해보면 팔로워십의 구조가 가장 명확한 차이로 떠올라요.

테란은 주도자가 일찍 정해진 팀이었어요. 누가 끌고 누가 따를지가 1주 차에 결정됐고, 그 위에서 분담이 굴러갔어요.

 

프로토스는 수평적으로 모두 참여하되 질문이라는 공통 경로가 작동한 팀이었어요. 주도자가 한 명으로 좁혀지진 않았지만 모두가 같은 방향으로 묻고 있었다는 점에서 응집력이 있었어요.

 

저그는 주도자와 경로 모두 1주 차에 자리잡지 못한 팀이었어요.

 

이 첫 번째 분기점에서 보인 패턴 하나는 분명했어요. 

누가 끌고 누가 따를지를 일찍 정한 팀, 또는 모두가 같은 방식으로 모르는 것을 드러낸 팀이 빨리 움직였다는 점이에요.

두 길은 달랐지만 구조가 있었다는 점은 같았어요. 가장 어려운 자리는 구조가 아직 잡히지 않은 자리였어요.

 

이게 이전 포스트에서 언급한 "이유 있게 실패하기"의 첫 번째 작동 지점이에요.

새로운 도구 앞에서 한 번 막혀본 신입은, 다음 학기 실제 프로젝트에서 새 엔진·새 라이브러리·새 협업 도구를 받을 때 "먼저 누가 익히고 누가 따라갈지"를 묻게 돼요.

 

이 질문이 머릿속에 한 번 박혔다는 게 3주 온보딩의 진짜 산출물이에요.

---

03. 두 번째 분기점 — 팀 안에서 의견이 부딪혔을 때

첫 번째 분기점을 통과한 팀에게 두 번째 벽이 기다리고 있었어요.

기획 단계에서의 의견 충돌이에요.

 

세 팀 모두 1주 차 후반에서 2주 차 초반 사이의 비슷한 시점에 마주쳤어요.

던전 콘셉트는 합의했지만 구체적으로 어떤 방을 만들지, 어떤 메커니즘을 넣을지에서 갈렸어요.

 

누구의 잘못도 아니죠.

다들 경험해보셨겠지만 처음 만났는데 3주 안에 게임 한 편을 만들어야하는 상황에, 의견이 안 갈리는 게 오히려 이상해요.

 

다만 갈렸을 때 어떻게 푸는지는 팀마다 달랐어요.

그리고 흥미롭게도 어떻게 푸는지는 첫 번째 분기점에서 만들어진 팀의 구조와 거의 그대로 이어졌어요.

 

테란 팀의 의견 조율은 논리에 가까웠어요.

 

1주 차에 질의와 실험을 반복하면서 쌓아둔 환경에 대한 이해가 의견 충돌 단계에서 판단의 공통 근거로 작동했어요.

 

"이 메커니즘이 자체 마크 환경에서 실제로 어떻게 구현 가능한가"에 대해 팀 전체가 비슷한 수준의 이해를 가지고 있었기 때문에, 각자의 기획안을 그 위에서 논리적으로 조정할 수 있었어요.

 

여기에 한 가지 더해진 게 팔로워십의 명확성이었어요.

누가 어디까지 책임지는지가 1주 차에 이미 자리잡혀 있었기 때문에, 의견을 낼 때 내 책임 범위 안에서 어떤 상황과 환경이 있는지를 충분히 설명하고 조정안을 내는 흐름이 자연스러웠어요. 

 

책임 범위가 명확하면 충돌이 줄어든다는 일반 협업 원칙이 그대로 작동한 케이스예요.

 

저그 팀은 진행 주도권 모호함이 2주 차까지 이어지진 않았어요. 

 

프로그래밍 팀원 한 명이 의견 조율 단계에서 리더십을 잡았고, 나머지 팀원이 팔로워로 따라가는 구조가 만들어졌어요.

잠시 길을 잃었던 팀이, 한 사람의 리더십으로 회복한 거예요.

 

저그 팀의 길이 가진 특징 하나는 합의의 속도였어요.

의사 결정의 대부분이 구두로 이뤄졌기 때문에, 회의에서 한 번 정리된 내용이 그 자리에서 곧바로 팀의 방향이 됐어요.

빠르고 가벼운 운영 방식이에요.

 

이 방식이 다음 단계로 어떻게 확장될 수 있을지가 흥미로운 지점이에요.

구두 합의의 속도감을 유지하면서도, 합의된 내용을 팀 바깥의 누군가가 봤을 때 따라올 수 있는 형태로 남기는 방법을 함께 찾아간다면, 이 팀의 가벼운 운영 감각은 다음 프로젝트에서 더 큰 강점이 될 거예요.

 

운영진이 다음 학기 멘토링에서 함께 고민해볼 부분이에요.

 

프로토스 팀의 의견 조율은 가장 민주적인 시도로 시작했어요.

 

잦은 브레인스토밍을 반복하며 가능한 모든 의견을 조율해 반영하려고 노력했어요.

추리형이라는 가장 복잡한 던전 콘셉트를 함께 짜고 있었으니, 모든 아이디어를 테이블에 올려두려는 시도는 합리적이었어요.

 

프로토스 팀의 길이 가진 특징은 의견의 다양성을 끝까지 테이블 위에 두는 자세였어요.

다섯 명의 신입이 모인 자리에서 모든 안을 들어보겠다는 시도는 협업의 가장 큰 자산 중 하나예요.

 

이 방식이 다음 단계로 진화하는 지점은 어떤 의견이 어떤 이유로 채택되었는지를 함께 가시화하는 것에 있어요.

 

의견을 모으는 단계와 결정을 내리는 단계가 자연스럽게 한 흐름으로 이어지면, 이 팀이 가진 다양성의 폭이 결정의 깊이로 연결될 수 있어요. 가장 복잡한 던전 콘셉트를 끝까지 완성도 있게 풀어낸 팀인 만큼, 잠재력의 폭이 큰 지점이기도 해요.

 

세 팀의 의견 조율 방식을 한 줄로 정리하면 각각 다른 자리에 무게중심을 두었어요.

• 테란은 공통의 기반 위에서 조정하는 길로 갔어요. 책임 범위와 환경 이해라는 합의된 기반이 의견의 조율을 떠받쳤어요.
• 저그는 리더십과 속도의 길로 갔어요. 한 명의 리더십과 구두 합의의 빠른 회전이 팀을 움직였어요.
• 프로토스는 다양성의 길로 갔어요. 모든 의견을 테이블 위에 올려두는 시도가 의사 결정의 출발점이었어요.

세 길 모두 3주 안에 던전을 완성시켰어요.

어떤 길이 더 낫다고 말할 수 없어요. 각자의 길은 다음 단계로 어떻게 진화할 수 있는가라는 질문을 다르게 안고 있을 뿐이에요.

 

공통 기반 위에서 조정하는 팀은 기반 자체를 어떻게 더 빠르게 만들까를 묻고, 리더십과 속도의 팀은 그 속도를 어떻게 더 멀리 전달할까를 묻고, 다양성의 팀은 그 다양성을 어떻게 결정의 깊이로 연결할까를 물어요.

 

이 두 번째 분기점에서 우리가 확인한 건 하나의 정답이 아니라, 세 개의 길이 각자의 질문을 안고 있다는 사실이었어요.

시스템이 모든 팀이 같은 방식으로 일하게 만드는 장치가 아니라, 각 팀이 자기 길을 찾을 수 있는 공간이라는 것.

 

어쩌면 이게 이번 온보딩에서 가장 중요한 발견일지도 모르겠어요.

---

04. 같은 시스템, 다른 결

세 팀이 통과한 두 분기점을 다시 보면 한 가지 관찰이 남아요.

시스템은 결과를 직접 결정하지 않지만, 분기점의 수를 줄여줬어요.

 

같은 도구, 같은 멘토 구조, 같은 평가 기준 위에서 세 팀이 다르게 움직였다는 건, 운영진이 만든 틀이 팀의 고유한 결을 지우지 않았다는 뜻이에요.

 

운영진 입장에서 이번 온보딩에서 배운 것은 시스템의 역할은 정답을 강요하는 것이 아니라, 팀이 본질에 집중할 수 있는 여백을 만드는 것이라는 점이었어요,

---

05. 마치며

세 팀이 다른 길을 통과한 끝에, 세 개의 던전이 완성되었어요.

 

다음 글에서는 세 팀이 만든 던전의 실제 모습과, 온보딩이 끝난 뒤 26명의 신입이 본 프로젝트에서 어떻게 움직이고 있는지를 함께 정리해볼게요.

 

이전 포스트를 아직 읽어보시지 않은 분은 링크를 통해 읽어보실 수 있습니다.