자기개발/Retrospect

2019 겜마루 신입생 공모전 멘토링 후기

pula39 2020. 10. 7. 03:22

2019년 2학기에 진행된 겜마루 신입생 공모전에서 멘토를 한 적이 있습니다. 그때 멘토링을 하면서 느낀 점을 여기 간단하게 적어보고자 합니다.

Icebreaking

  • 멘토링을 시작할 때, 서로의 목표를 확인하는 것이 중요합니다.

  • 멘티가 이 활동을 통해 어떤 것을 원하고, 할 수 있는지 알아야합니다.

    • 어느정도의 실력을 가지고 있는지
    • 어느정도의 성장을 원하는지
    • 어느정도의 시간과 열정을 가지고 임하고 있는지.

  • 멘토(나)는 이 활동으로 어떻게 하고 싶은지를 생각해보는 것도 중요합니다.

    • 어떠한 목적으로 임하고 있는지(지식 정리, 가르침 욕구, 친목 도모 등)
    • 어느 정도의 교육을 할 수 있는지
    • 어느 정도의 시간과 열정을 가지고 임하고 있는지

  • 이렇게 서로의 이해를 맞추고, 자신의 이해를 파악하고. 멘토링의 계획을 세우는것이 좋습니다.

  • 이때 이야기 한 것을 기반으로, 러프한 계획을 짭니다.

    • 정말 중요한 목표와, 강렬한 의지가 있을 때가 아니면 러프하게 계획을 짜는 편입니다.
    • 한두번 진행해보고 계획을 굳혀가는것이 훨씬 좋고.
    • 이것보다 계획대로 이루어지는지 자주 점검하는것이 훨씬 중요하기 때문에 이에 집중합니다.

    어디까지 잡아줘야 할까?

    • 보통은 하고싶은것은 있지만 어떻게 해야하는지 모르는 경우가 많습니다. 그럴 경우에 무작정 다 알려주기보다는, 큰 그림을 그리는 것을 우선적으로 진행했습니다.

      • 제가 생각하는 게임을 만들기 위해 우선적으로 해야하는 과정을 설명해줬습니다.
      • 한문장으로 정의하기 -> 스토리보드 만들기 -> 규모 정하기 (프로토타입을 정한다) -> 그 후 Iteration 반복하면서 감각을 잡기

    • 하지만 이것이 꼭 그대로 가는건 아닙니다. 하지만 이런것에서 영감을 주는 것은 중요한 것 같습니다.

      • 실제로 결국 스토리보드는 만들지 않았습니다.
      • 하지만 위의 과정을 말하면서 요구사항 분석을 해나갈 수 있었습니다.

    • 저는 그 당시 회사 일이 바빴기때문에 구체적인 교육은 해줄 수 없었고, 공부해야 하는 것과 관련된 과제를 계속 내주며 그것에 대해서 이야기하는 식으로 멘토링을 진행했습니다

      • 이 방식의 단점은 멘티가 할 생각이 없으면 진행할 수 없다는 것인데, 다행히도 잘 따라와줬습니다.

    • 이에 대해 내가 당시에 남긴 메모가 있는데, 이 말이 참 맞는 것 같습니다.

      물고기를 주는 것이 아니라 물고기를 잡는 법을 알려줘야 한다. 하지만, 한번은 물고기를 같이 잡을 필요가 있다.

과몰입을 하지 않는다.

  • 이러한 과정을 통해 멘티의 페이스를 찾아갑니다. 보통 멘토의 실력이 멘티보다 높고, 개구리 올챙이적 생각 못하듯이 자신의 지식을 멘티가 금방 흡수할 수 있다 생각합니다.

  • 하지만 모든 사람에게는 페이스가 있습니다. 이런 페이스를 찾아서, 어디까지의 지식을 이 멘토링에서 줄 수 있는지 생각해보는게 좋습니다.

    • 저는 Git은 빨리 배울수록 좋다 생각합니다. (써봐야 필요성을 느끼고 그 과정에서 숙련도가 오르기에)
    • 하지만 Git을 배우는 비용을 생각해서 멘토링 때 진행하지 않았습니다.

  • 멘티가 받아들일 수 있는 지식의 양과 속도를 맞춰서 진행하는 것이 좋습니다.

    구체적인 목표와 계획

    • 구체적인 목표와 계획은 위에서 말한것을 이루기위해서도 중요하고, 잘 되고 있는지 점검하기위해서도 중요합니다.
    • 아래는 그 당시에 제가 제시했던 과제입니다. .뮤즈대쉬 같은 게임을 만들고 싶다 했기에, 그를 위해서 간단한 것부터 쌓아올릴 수 있게 했습니다.

      평지에 공을 굴러가게 한다.
      Space를 누르면 공이 점프하게 한다.
      큐브를 일정간격으로 만들게 한다.
      BPM을 설정해서 BPM에 맞게 라인을 그린다.
      BPM에 맞게 큐브를 일정 간격 스폰하고, 라인을 4배로 스폰되게 한다.
      블럭에 하나 충돌할 때 마다 카운트를 센다. 그 카운트를 로그로 표시한다.
      곡 길이를 초로 받고, 곡 길이와 BPM을 계산해서 블럭을 배치한다. 마지막 블럭을 지났을 때 로그로 끝났다고 알린다.
      List에 숫자를 받는다. 한 마디는 32이다. BPM을 통해 곡에서 한 마디를 구할 수 있다. 그 List의 숫자 기반으로 블럭을 출력해보자.
      <예시> 180 BPM에 60초짜리 곡이면 1초에 3 마디. (180 / 60) 1초에 3마디니까 1초는 0~95. 사이의 숫자의 블럭이 있으면 나타나게 된다
      그 리스트를 3개 준비해서, 곡 시작할 떄 선택하고, 곡이 끝날 때 그 곡 클리어할 때의 데미지 정보를 저장한다.
      List에 들어가는게 숫자였는데 이제는 Structure라 바꾼다. (이름은 대충 NoteObject 이런식으로 하자)
      NoteObject는 데미지 정보와, 자신의 위치를 가진다.
      블럭에 맞을 때, 노트 오브젝트에 해당되는 데미지만큼 데미지가 달게 한다.

  • 다행히 멘티가 잘 따라와줬습니다. 그래서 저는 적절한 페이스라 생각하여 진행했습니다.

    결론

  • 결론은 이번 경우는 멘티가 너무 잘 해줬습니다.

  • 사실 의욕이 없는 멘티를 너무 만나면 점점 기대치가 떨어지게 됩니다. 그러면서 점점 의욕이 낮아지는데 이번에는 제 예상을 뛰어넘게 의욕을 보이며 주도적으로 진행했습니다.

  • 저 또한 Unity를 거의 처음 써보는 사람에게 어떻게 알려줘야할지에 대해 경험해볼 수 있던 좋은 기회였던 것 같습니다.