동료학습에 대한 고찰

GDSC (이젠 GDG on Campus가 되긴했지만..)에서 동료학습에 대해서 발표를 했었습니다. 발표에 대한 큰 흐름은 다음과 같았습니다.

1. 42Network에서 어떻게 동료학습을 하는지
2. 동료학습이 어떤 장점이 있는지
3. 다른 공간 및 상황에서 어떻게 동료학습을 해야하는지

구체적으로, 일반적인 학습 방법(강의 학습)을 통해서 공부한 경험에 대해서 상기시킬 수 있는 내용을 언급했습니다. 예를 들어, 학교 강의를 듣고 다음 학기에 그것에 심화된 내용 및 실험과목에 대해서 수강하려고 할 때, 가르치는 교수 및 강사가 “직전 학기에 배웠으니 다 알지?”를 말했는데 그 말을 듣고 “나 잘 모르겠는데?”와 같이 분명 강의를 수강했음에도 불구하고 제대로 기억이 나지 않는 에피소드를 통해 언급했습니다.

그 이후 동료학습에 대해서 설명하기 전에 동료학습에 대한 용어정리를 상호 피드백할 수 있는 학습방법 이라고 설정하고 42Network 속에서 어떻게 동료학습을 하는지 다큐멘터리 영상과 함께 설명했습니다.

https://youtu.be/0VrB9PoWa04

그리고 42Network에선 각 과제마다 원격저장소가 존재하고, 과제를 제출한 후 평가매칭이 되면 동료가 내 자리로 와서 각 과제마다 주어지는 평가지를 통해서 평가를 하고 평가자와 피평가자와 상호 피드백로그를 작성하는 식으로 평가가 진행되는데 그에 해당하는 평가로그를 보여드리고 설명을 드렸습니다.

그 후 그렇다면 42Network가 아닌 환경에선 어떻게 동료평가를 해야할지라는 생각에 팀 프로젝트를 대안으로 말씀드렸습니다.

그리고 팀 프로젝트의 장점으로써,

1. 남의 코드를 많이 볼 수 있다.
2. 구현을 해보면서 구현 및 문제해결 능력이 길러진다.
3. 질문을 많이 할 수 있는 환경에 위치하게된다.

를 말씀드렸고 그에 대한 이유로

남의 코드를 많이 봐야, 다른 사람은 어떻게 해결했고 내 케이스에 어떻게 적용할 수 있을까? 라는 생각을 할 수 있게 하여 불필요한 고민 시간을 줄인다고 말씀드렸습니다.

2번의 경우에는 팀 프로젝트 속 맡은 역할 및 임무에 대해서 해결하다 보면 자연스레 개발능력이 상승한다고 말씀을 드렸습니다.

마지막의 경우에는 질문을 많이할 수록 좋은 질문에 대해서 고민을 하게 되고 서로 질문을 주고 받는 과정 속에서 개념에 대해서 이해하고 오래 기억할 수 있다고 말씀드렸습니다.

그 이후 구체적으로 Git을 통해서 팀 프로젝트 작업을 할 때 Review Requirements 수를 적절하게 정해서 피드백을 할 수 있는 환경을 만들면 조금 더 발전할 수 있는 환경일 거라고 말씀드렸습니다.

이후, 발표가 끝나고 인상깊은 질문을 받았습니다. “공부하는 학생들 입장에서 서로 상호 피드백을 할 때, 정답이 없는 문제에 대해서 어떻게 결론을 지어야하나요?” 라는 것이었습니다.

저도 생각해본 적 없는 문제라 당시에는 어느정도 결론을 내고 추후 어느정도 시간이 지난 뒤 리마인드를 해보라는 식으로 답변을 드렸으나, 사실 직접적인 해결법이 아니라고 스스로 생각이 듭니다.

물론, 이러한 문제들에 대해서 정답은 없으나 생각해본 해결방법을 적어보고자 합니다.

• TDD(테스트 코드)

장점

• 확실한 허들이 존재하니 뚜렷한 목표를 선정할 수 있습니다.
• 효율성 측면에서만 논의해볼 수 있기에, 불필요한 논의 시간이 줄게 됩니다.

단점

• 러닝 커브 특히, 한 번도 프로젝트를 안해봤거나 테스트코드를 짜봤지 않은 인원이 있는 경우 힘듭니다.
• FE의 경우 적절히 대응하기 쉽지 않습니다.
• 리드개발자 설정
  • 결정을 하는데 크게 시간이 필요하지 않습니다.
  단점
  • 비슷한 수준의 사람들과 프로젝트를 할 때 현실적으로 쉽지 않습니다.
  • 더 비효율적인 방법으로 흘러갈 수도 있습니다.
• 장점

결론적으로, 구체적인 코드 구현사항에 대한 제한을 통해서 논의를 할 수 있지만, 코드 철학 및 프로젝트 구조에 관련된 내용에 대해선 정답이 없기 때문에 적절한 논의 끝에 방향성을 잡아나가야 한다고 생각합니다.