교육용 레일

계산

이후 4개월 동안 우리는 2주에 한 번씩 만나 단계별로 루비 언어인 Ruby on Rails를 다루며 루비의 멋진 세계를 발견해 나갔습니다, 자바스크립트 Devise, Pundit, Sidekiq 또는 Carriewave와 같은 RoR 애플리케이션을 위한 인기 도구도 있습니다.

또한 모든 학생에게는 멘토가 있었는데, 멘토는 학생들에게 동기를 부여하고 회의 중간중간 학생들의 작업을 점검하는 역할을 담당했습니다.

공격 계획

교사로서 저는 Ruby on Rails를 사용한 3년의 경험과 프로그래밍 전반에 대한 10년의 경험, 그리고 문제와 연습이 포함된 몇 가지 프레젠테이션을 준비했습니다.

이전에 리눅스 관리에 대한 짧은 강좌를 진행한 것 외에는 강의 경험이 전혀 없었습니다. 수강생이 10명 정도 될 거라는 것만 알고 있었고, 수강생 중에는 프로그래밍을 처음 접하는 사람도 있고, 등록하기 전에 C나 Ruby를 독학으로 배우려고 했던 사람도 있는 등 배경이 매우 다양했습니다.

인내심을 갖고 필요한 경우 모든 것을 설명하겠다는 두 가지 결심을 하기로 했습니다("이미 설명했습니다"라는 말은 하지 않기로 했습니다). 첫 번째 결심은 시간의 시험을 견뎌냈지만 두 번째 결심은 그렇지 못했습니다. 저는 제가 가르칠 내용에 대해 특별한 준비를 하지 않기로 결심했습니다. 저는 매일 Ruby/Rails로 작업하고 있고 그 분야에 대한 제 기술에 꽤 자신감이 있습니다. 기껏해야 제가 가지고 있던 프레젠테이션을 읽었을 뿐입니다.

도전 과제

강의를 시작하자마자 가장 먼저 깨달은 것 중 하나는 모든 것을 설명할 수는 없다는 것이었습니다. 저처럼 사물이 어떻게 작동하는지 파헤치고 발견하는 것을 좋아하는 사람에게는 매우 슬픈 깨달음이지만, 한 번의 제한된 시간 동안 가르칠 수 있고 수강생이 기억할 수 있는 것은 한정되어 있습니다. 배열이 실제로 메모리에서 어떻게 표현되는지, Devise가 정확히 어떻게 작동하는지 정확히 알지 못해도 아주 훌륭한 루비 프로그래머가 될 수 있다는 것이 밝혀졌습니다.

수업은 토요일과 일요일 오전 9시부터 오후 5시까지 진행되었습니다. 교재를 설명하는 것 외에도 항상 관련 질문(또는 관련 없는 질문)에 답하고 학생들이 겪는 다양한 문제를 해결할 준비가 되어 있어야 하기 때문에 가르치는 일은 매우 고된 일이라는 것을 인식하는 것이 중요합니다.

커피는 여러분의 친구이지만 가장 중요한 것은 앞서 언급한 인내심입니다. 코딩을 해본 적이 없는 사람들에게는 루프, 유형 또는 변수와 같이 프로그래머에게 당연한 개념은 학습이 필요하며, 이는 즉각적인 과정이 아닙니다. 프로그래밍을 XX년 동안 해왔고, 수학을 쉽게 생각하고, 알려진 모든 프로그래밍 패러다임을 한밤중에 나열할 수 있다면 변수 이름이 등호의 어느 쪽에 있는지 잘 모르는 사람의 입장이 되어보기 어려울 수 있습니다. 하지만 그렇게 하는 것이 중요합니다. 변수, 루프 또는 배열과 같은 기본 개념은 너무 자연스러워서 어떻게 누군가가 바로 이해하지 못할 수 있는지 이해하기 어렵지만, '우리 프로그래머'에게는 생각보다 어렵습니다.

특히 과정 초반에는 이러한 개념을 잘 이해할 수 있도록 설명하는 것이 어려웠습니다. 일부에서는 그렇지 않다고 주장할 수도 있겠지만, 제 생각에는 Ruby를 배우지 않고 Rails를 배울 수는 없습니다. Rails에는 자체적인 패턴이 있고 처음부터 배우기보다는 기억해야 할 것이 많은 것은 사실입니다. 하지만 양심적인 RoR 개발자가 되기 위해서는 루비, OOP 또는 SQL에 대한 적당한 이해는 필수라고 생각합니다. 사람들에게 프로그래밍을 가르치는 것은 레일즈를 가르치는 것과는 상당히 다릅니다. 레일즈는 그냥 받아들이거나 믿으면 되는 것이 많지만(콜백이 어떻게 작동하는지 처음부터 알 필요는 없고 할 수 있는 것만 알면 됩니다), 프로그래밍 개념은 더 자세히 설명해줘야 합니다.

포스 참여

그렇다면 어떻게 할 수 있을까요?

참을성 있게.

항상 반복하는 말 같지만 인내심이 얼마나 중요한지 아무리 강조해도 지나치지 않습니다. 아무리 의욕이 넘치는 학생이라도 여기저기서 구문 오류를 범하는 경우가 있는데, 이는 정상적인 학습 과정의 일부이며 오류가 무엇이고 어떻게 고치는지 알려주는 것 외에는 교사가 할 수 있는 일이 없습니다. 시간이 지나면 학생들은 스스로 고치는 방법을 배우게 되지만 한두 번의 오류보다 훨씬 더 많은 시간이 걸립니다.

또 한 가지 주의해야 할 점은 루비가 생각만큼 쉽지 않다는 것입니다. C/Java/Python에 대한 지식을 가지고 루비를 배우기 시작했다면 모든 것이 매우 깔끔하고 단순해 보였을 것입니다. 하지만 곰곰이 생각해 보면 알 수 있습니다:

1. 괄호는 무엇인가요? 괄호를 사용해야 하나요? 안 써야 하나요?
2. 그게 뭐죠? self 같은 거요? 가끔 사용해야 할 때가 있습니다(예. attr_writer – self.variable = ...), 때로는 그렇지 않을 때도 있습니다(attr_reader – 변수), 때로는 그렇지 못할 때도 있습니다! (private def some_method – self.some_method 은 오류를 발생시킵니다)
3. 블록. (다른 언어를 사용하는) 숙련된 프로그래머도 다음을 이해하는 데 예상보다 많은 시간이 필요할 것입니다. #inject

단순히 오류를 수정하는 것 외에도, 교수자가 이해한 내용을 학생들에게 실제로 전달해야 하는 문제가 있습니다. 이를 위해서는 많은 유연성이 필요합니다. 일부 학생들은 배열이 단순히 요소의 정렬된 목록인 것에 만족했습니다. 다른 학생들은 물건을 놓을 수 있는 번호가 매겨진 선반처럼 좀 더 시각적인 비유가 필요했습니다. 저는 같은 내용을 여러 번 다른 방식으로 설명해야 했기 때문에 상당히 어려운 연습이었습니다!

하지만 앞서 말했듯이 모든 것을 설명할 수는 없습니다. Rails에서 관계를 설명할 때는 "이렇게 하면 이렇게 할 수 있고, 이렇게 하면 저렇게 할 수 있습니다. 그렇게 하면 정말 멋져요"라는 식이었죠. 다행히도 주니어 개발자는 리플렉션에 대해 알 필요가 없다고 생각하기 때문에 리플렉션이 어떻게 작동하는지 물어보는 사람은 아무도 없었습니다.

상황별 포지셔닝

격주 주말 모임과 긴 방학이라는 강의 형식 때문에 주말 사이의 시간을 학생들에게 생산적인 시간으로 만들어야 했고, 그 시간에 연습을 하지 않으면 강의가 전혀 진행되지 못했습니다.

제 동료 중 일부는 이 과정의 수강생 멘토가 되기로 동의했습니다. 멘토의 역할은 주말 회의에서 할당된 연습 문제를 확인하고 문제를 완료하는 동안 발생하는 문제를 해결하는 것이었습니다. 학생들은 Slack을 통해 멘토와 소통했습니다.

저는 제 학생 두 명의 멘토였습니다. 그것은 상당히 다른 형태의 가르침이었고 나름의 함정이 가득했습니다. 제가 너무 늦게 깨달은 한 가지는 훌륭한 프로그래머는 독립적이어야 하며, 도움을 요청하기 전에 최소한 스스로 문제를 해결하려고 노력해야 한다는 것이었습니다. 그리고 항상 Slack을 사용하다 보니 시간이 많이 걸릴 뿐만 아니라 그런 독립심을 키우지 못했습니다.

멘토로서 제가 받은 많은 질문이 타당했고, 그 질문에 답하면서 학생들에 대한 지식을 넓힐 수 있었습니다. 하지만 '교사 모드'로 들어가서 주말 회의에서 나온 모든 문제를 다시 설명하는 것은 매우 쉽습니다. 오늘날의 관점에서 멘토의 역할은 개요를 정리하고 유용한 링크를 제공하며 해결책을 찾는 데 도움이 될 만한 몇 가지 질문을 하는 것이라고 생각합니다. 가끔씩 설명이 필요할 수도 있지만, 그 대부분이 되어서는 안 됩니다.

인텔리전스 사용

모든 학생은 다릅니다. 가장 큰 어려움 중 하나는 모든 학생에게 가장 잘 맞도록 강의 속도를 조정하는 것이었습니다. 학생들마다 배경이 다르고 새로운 아이디어를 쉽게 받아들이는 수준이 다르기 때문에 거의 불가능한 일이었습니다.

2일에 8시간을 곱하면 0에서 루비 히어로가 되기까지 144시간이 걸렸습니다. 이 시간 안에 전체 강의안을 작성하는 것이 가장 중요했는데, 그 자체로 상당히 빠른 속도를 낼 수 있었습니다. 처음 세 번의 회의는 모두 Ruby에 관한 것이었고, 그다음 한 번은 SQL에 관한 회의, 그다음 한 번은 RoR에 관한 회의, 그리고 그 사이에 JS에 관한 회의가 있었습니다.

교사로서 저는 항상 제가 발표하는 자료의 일부를 누가 어느 정도 이해하고 있는지 파악해야 했습니다. 때로는 이해했는지 물어보는 것으로 충분했고, 때로는 작은 테스트를 하기도 했습니다. 예를 들어, 저는 모든 학생들에게 다음과 같은 루비 개념에 대한 정의를 보내달라고 요청했습니다. 클래스, self, 메서드, 변수 등을 Slack에서 확인합니다. 특히 불명확한 문제가 있으면 돌아가서 다시 설명하려고 노력했습니다.

환상과 현실

요약하자면, 가르치는 일은 생각보다 훨씬 더 어려운 일이었습니다. 또한 매우 보람 있는 일이기도 합니다. 그럼에도 불구하고 힘든 일이고 그 효과는 교사에게만 달려 있는 것이 아니라 학생 스스로의 노력이 학습에 훨씬 더 중요합니다. 따라서 일반적으로 성공과 실패를 모두 교사가 소유할 수 있는 프로그래밍과는 매우 다른 교육 방식입니다. 이 차이를 기억하는 것이 중요합니다.

또한 평소에는 생각하지 못했던 문제에 대해 생각하게 되고, 설명하는 과정에서 문제를 더 잘 이해할 수 있게 됩니다. 이런 식으로 가르치면 더 나은 프로그래머가 될 수 있습니다.