멘토링 자주 묻는 질문

멘토가 되려면 어떤 자격이 필요한가요?

아직 배우는 중인 언어도 멘토링할 수 있나요?

여러 언어를 멘토링할 수 있나요?

대기열에 있는 모든 풀이를 멘토링하려고 해야 하나요?

풀이가 며칠, 심지어 몇 주째 대기열에 남아 있다면 어떻게 하나요?

풀이에 대해 제안할 게 아무것도 없다면 어떻게 하나요?

한 번도 풀어본 적 없는 연습 문제를 멘토링해도 되나요?

풀긴 했지만 다른 언어로 푼 연습 문제를 멘토링해도 되나요?

한 번 본 풀이를 꼭 멘토링해야 하나요?

몇 번이나 설명했는데도 학생이 이해하지 못한다면 어떻게 하나요?

학생이 제 제안에 방어적으로 나온다면 어떻게 대응해야 하나요?

제가 학생이 틀렸다고 생각하더라도 학생이 마지막 말을 하게 해야 하나요?

제안은 어떻게 표현하는 게 가장 좋나요?

포매팅, 주석, 이름 짓기 관례를 강제해야 하나요?

멘토가 되려면 어떤 자격이 필요한가요?

어떤 언어를 멘토링한다고 해서 그 언어의 전문가일 필요는 없어요. 멘토링받는 사람보다 조금 덜 초보자면 충분해요. 풀이에서 다른 방식으로 할 수 있다고 생각되는 부분이 있으면 제안해도 돼요. 꼭 더 나은 방식일 필요는 없고, 관용적인 대안이면 충분해요. 제안을 쓸지 말지는 학생이 선택하면 되고, 적어도 학생이 고를 수 있는 선택지는 더 많아지는 거예요.

아직 배우는 중인 언어도 멘토링할 수 있나요?

이상적으로는 이미 아는 언어라도 언어 공부를 멈추지 않아요. 어떤 언어는 몇 주나 몇 달마다 새 버전을 내놓기도 해요. 배워야 할 새로운 언어 기능이 있을 뿐만 아니라, 아직 모르고 있던 기존 기능도 있을 수 있어요. 때로는 학생이 어떤 기능을 쓰는데, 그때 처음 보는 경우도 있어요. 그래서 멘토링은 언어를 더 많이 배우는 좋은 방법이 될 수 있어요.

여러 언어를 멘토링할 수 있나요?

편하게 느껴지는 만큼 여러 언어를 멘토링해도 돼요. 자신 있는 여러 언어는 물론이고, 아직 배우는 중인 언어도 함께 멘토링해도 괜찮아요.

대기열에 있는 모든 풀이를 멘토링하려고 해야 하나요?

그 시점에 풀이에 대해 알찬 내용이나 건설적인 이야기를 떠올릴 수 없다면, 학생이 응답을 더 오래 기다려야 하더라도 멘토링 요청을 다른 멘토에게 남겨 두는 편이 학생에게 더 나을 수 있어요.

풀이가 며칠, 심지어 몇 주째 대기열에 남아 있다면 어떻게 하나요?

학생이 내가 답할 수 없는 구체적인 질문을 했다면, 그 질문에 답할 수 있는 사람에게 맡겨 두는 편이 좋아요.

그게 아니라면, 나에게 어려웠던 연습 문제의 풀이일 수 있어요. 풀지 못했거나, 풀긴 했지만 잘 풀지 못했다고 느꼈던 문제요. 그런 경우에는 그 풀이에서 배울 것이 있는지 한번 살펴볼 수 있어요. 배울 게 있다면, 그 풀이에서 특별히 배운 점에 대해 학생에게 고마움을 전해도 좋아요.

아니면 학생이 자기 풀이를 직접 설명해 주기를 바랄 수도 있어요. 일종의 "역멘토링"이지만, 예의 바르고 존중하는 태도로 부탁하면 기꺼이 설명해 주는 학생도 있어요. 그런 다음 다른 접근을 고려해 봤는지, 왜 그 접근을 선택했는지 물어볼 수 있어요.

또는 전체적으로는 이해가 안 되지만, 짚어 줄 수 있는 부분이 몇 가지 보일 수도 있어요. 예를 들어 함수 매개변수에 그냥 n이나 m을 썼다면, 의미 있는 이름을 쓰는 걸 고려해 보라고 알려줄 수 있어요.

이 중 어느 것도 편하게 하기 어렵다면, 요청에 답하지 않은 채 두어도 괜찮아요. 멘토링은 자발적인 활동이에요. 어떤 언어를 멘토링한다고 해서 그 언어의 모든 연습 문제를 멘토링해야 하는 건 아니에요.

풀이에 대해 제안할 게 아무것도 없다면 어떻게 하나요?

풀이에서 마음에 드는 점을 말하는 것도 괜찮아요. 사실 풀이에서 특별히 마음에 드는 점을 말하는 건 어떤 멘토링을 시작할 때나 좋은 방법이에요. 그렇게 한 뒤에, 연습 문제를 다른 방식으로 접근하는 제안이 없다면 학생에게 그냥 "잘했어요!"라고 말해도 괜찮아요. 학생이 이터레이션을 두 개 이상 제출했다면, 가장 최근 이터레이션이 어떤 점에서 나아졌는지 짚어 줄 수 있어요.

한 번도 풀어본 적 없는 연습 문제를 멘토링해도 되나요?

때로는 학생의 풀이를 보다가 직접 그 연습 문제를 풀고 싶어질 수 있어요. 특히 그 풀이에서 쓴 접근이 이미 고려해 본 다른 접근보다 문제를 더 단순해 보이게 만든다면 더 그렇죠. 문제를 풀고 나서, 영감을 준 그 멘토링 요청이 이미 사라졌더라도 적어도 다음번을 위해 준비가 된 셈이에요.

풀긴 했지만 다른 언어로 푼 연습 문제를 멘토링해도 되나요?

한 언어에서 관용적인 것이 다른 언어에서는 관용적이지 않을 수 있으니, 멘토링하려는 언어로 그 연습 문제를 풀어 본 적이 있는 게 가장 좋아요. 두 언어의 풀이가 아주 비슷하고, 각 언어에서 무엇이 관용적인지 알 만큼 두 언어를 잘 안다면, 한 언어의 풀이를 다른 언어로 옮기는 데 오래 걸리지 않아요. 풀이를 옮기고 나서 멘토링 요청이 이미 사라졌더라도, 적어도 다음번을 위해 준비가 된 셈이에요.

한 번 본 풀이를 꼭 멘토링해야 하나요?

풀이를 보고 나서 여러 이유로 멘토링하고 싶지 않다는 걸 깨달을 수 있어요. 예를 들면:

• 학생이 내가 답을 모르는 질문을 했을 수 있어요.
• 코드가 너무 장황하거나 혼란스러워서 어디서부터 비평을 시작해야 할지 모르겠을 수 있어요.
• 코드를 보면 학생이 완전한 초보자라서 기본적인 안내가 많이 필요하지만, 그럴 시간도 인내심도 없다는 게 느껴질 수 있어요.
• 학생이 남긴 코멘트가 불쾌하거나 함께 대화하기 힘든 사람이라는 신호일 수 있어요.

특정 멘토링 요청이 나에게 맞지 않다고 생각되면 "Start mentoring" 버튼을 클릭할 의무는 없어요.

몇 번이나 설명했는데도 학생이 이해하지 못한다면 어떻게 하나요?

학생이 설명을 거의 일부러 이해하려 하지 않는 것처럼 보일 때도 있어요. 아는 방법을 모두 동원해서 설명해 봤다고 느껴진다면, 학생에게 멘토링 요청을 다시 제출하라고 제안하면서 대화를 마무리할 수 있어요. 어려운 부분을 더 잘 설명해 줄 수 있는 다른 멘토가 맡을 수 있으니까요.

학생이 제 제안에 방어적으로 나온다면 어떻게 대응해야 하나요?

때로는 학생이 어떤 언어 기능을 더 배우기 위해 일부러 더 번거로운 접근을 썼다고 말할 수 있어요. 그 기능이 그 연습 문제에 가장 잘 맞지는 않더라도요. Exercism은 경쟁 코딩 사이트가 아니라 배움을 위한 플랫폼이니, 가장 우아하거나 효율적인 접근을 쓰지 않은 데에는 충분히 그럴 만한 이유가 있어요. 학생이 자기 접근을 더 관용적인 방식으로 구현할 수 있었다고 보인다면, 그 접근을 어떻게 활용했는지에 대해 몇 가지 제안을 해도 좋아요. 어쨌든 피드백을 바탕으로 이터레이션을 하나 더 제출하거나, 멘토링 자리를 비우기 위해 대화를 끝낼 수 있다고 제안할 수 있어요.

학생이 그 언어나 연습 문제에 가장 잘 맞지 않는 프로그래밍 패러다임을 고집할 수도 있어요. 예를 들어 항상 객체 지향 패러다임을 쓰고 싶어 해서, 비교적 단순하고 직관적인 풀이를 여러 메서드를 거치는 미로 같은 제어 흐름을 가진 클래스들로 잘게 쪼개 버리기도 해요. 학생이 그 패러다임을 교조적으로 따르는 경우에는, 다른 접근을 설득하려 해도 대개 소용이 없어요. 시도해 볼 수는 있고 학생이 제안에 반응할 수도 있지만, 학생이 고집을 부린다면 넘어가는 게 가장 좋아요.

학생이 제안을 아예 거부할 수도 있어요. 예를 들어 map과 join 대신 reduce를 쓰라고 제안할 수 있어요. reduce는 한 번만 반복하면 되지만, map과 join은 각각 한 번씩 반복해야 하니까요. 하지만 학생은 map과 join이 더 읽기 쉽다며 거부할 수 있어요. map과 join이 reduce보다 더 읽기 쉬울 수 있다는 데 동의해 줘도 괜찮아요. 시간이 지나 익숙해지면 reduce가 더 편해질 수 있다고 제안할 수 있고, map과 join을 쓰는 데 잘못된 점은 아무것도 없어요.

학생이 맞는 부분까지만 동의해 줘도 괜찮고, 학생이 표현한 오해나 과장을 바로잡으려 시도해도 괜찮아요.

제가 학생이 틀렸다고 생각하더라도 학생이 마지막 말을 하게 해야 하나요?

예를 들어 Clock 연습 문제를 풀 때 60과 24 같은 매직 넘버를 쓰지 말고, 의미 있는 이름의 상수로 정의하라고 제안할 수 있어요. 그러면 학생은 문맥상 60과 24가 무엇을 뜻하는지 뻔하다고 답할 수 있어요. 제안은 했고 학생은 받아들이지 않았어요. 그걸 두고 다투는 건 얻을 게 없고, 어쩌면 호의만 잃을지도 몰라요.

제안은 어떻게 표현하는 게 가장 좋나요?

반드시 더 나은 것은 아닐 수도 있는 대안을 제안할 때는 "다른 접근으로는..."이라고 서두를 붙일 수 있어요. 예를 들어 "includes와 함께 every를 쓰는 다른 접근도 있어요"처럼요.

제안을 시작하는 또 다른 방법은 "혹시..."예요. 예를 들어 "혹시 split() 대신 스프레드 문법을 쓰는 건 어떨까요?"처럼요. 학생이 꼭 대안을 써야 한다고 강하게 느낀다면 "혹시"를 빼고 "고려해 보세요..."로 시작할 수 있어요. 예를 들어 "기본 인자를 쓰는 걸 고려해 보세요"처럼요.

제안이 여러 개라면 각각을 어떻게 시작할지 다양하게 바꿔 보는 것도 좋아요.

글머리 기호는 풀이에서 마음에 드는 점을 나열할 때 효과적이에요. 하지만 제안을 나열할 때는 덜 친근하게 느껴질 수 있어요. 제안을 편안하고 대화하듯 전하면 학생이 더 부담 없이 고려하고 받아들일 수 있어요.

제안할 때 가장 쓰지 않는 게 좋은 단어는 "should"예요. 예를 들어 "You should use a default argument."처럼요. "should"나 "must" 같은 단어를 쓰면 압박하는 것처럼 들릴 수 있어요.

포매팅, 주석, 이름 짓기 관례를 강제해야 하나요?

멘토들은 코드 포매팅, 주석, 이름 짓기 관례 같은 문제를 언제, 얼마나 강하게 꺼낼지에 대해 의견이 갈리기 쉬워요. 한편으로는 Two Fer 같은 연습 문제로 일찍부터 이런 것들을 생각하게 해서 나쁜 습관이 들기 전에 잡아 주고 싶을 수 있어요. 아니면 예의범절에 대한 온갖 고민으로 초보자를 겁주고 싶지 않을 수도 있고요. 다른 한편으로는, 더 심화된 연습 문제를 하는 학생들은 이미 관례를 알지만 당장의 과제에 집중하느라 일부러 무시하기도 해요. 관례에 계속 집중하는 걸 잔소리처럼 여길 수도 있어요. 어떤 언어에 포매터나 린터가 하나 이상 있다면, 그것들을 소개할 연습 문제를 고르는 게 좋아요. 그게 아니라면 특정 관례 위반이 정말 심각할 때는 어디서든 짚어 주는 게 좋아요. 멘토마다 다를 수 있는 건 무엇이 "정말 심각한지"에 대한 기준이에요.