멘토링 팁

멘토링 노트

멘토링에 가장 큰 도움이 되는 것 중 하나는 맡은 연습 문제마다 노트를 적어 둘 파일을 하나 갖는 거예요. 많은 풀이가 같은 제안으로부터 도움을 받을 수 있다는 걸 알게 될 거예요. 그래서 노트를 적어 두면 같은 제안을 기억에 의존해 매번 다시 쓰지 않아도 돼요. 그리고 제안을 한곳에 모아 두면 시간이 지나면서 계속 다듬어 더 명확하게 만들 수 있어요.

노트를 어떻게 시작해야 할지 모르겠다면, exercism/website-copy/tracks 아래에서 트랙 연습 문제의 mentoring.md 파일을 찾을 수 있어요. 그 파일이 있다면, 적절한 풀이 예시와 함께 더 깊은 논의를 이끌어 낼 흔한 제안이나 이야깃거리가 들어 있을 거예요. 없다면, 그 연습 문제에 대한 자신만의 노트 파일을 만든 뒤에 돌아와서 하나 만들어 보는 것도 좋아요.

또한, 지금은 한 언어만 멘토링하더라도 앞으로 더 많은 언어를 멘토링하게 될 수도 있어요. 트랙별로, 그리고 연습 문제 이름별로 멘토링 노트를 정리해 두면 도움이 될 수 있어요. 트랙마다 같은 연습 문제에도 다른 제안이 필요할 가능성이 크니까요.

멘토링 노트는 그 연습 문제를 자주 멘토링하든 드물게 하든 유용해요. 그 연습 문제를 자주 멘토링한다면, 노트에서 복사해서 붙여 넣기만 하면 되니 처음부터 타이핑하는 수고를 크게 덜어 줘요. 드물게 멘토링한다면, 마지막으로 멘토링한 뒤 몇 주나 몇 달 동안 잊고 있었을 제안을 떠올리게 해 줘요.

멘토링 노트는 멘토마다 달라도 괜찮아요. 다음은 노트를 구성하는 한 가지 방법이지만, 유일한 방법은 아니에요.

멘티가 테스트를 통과했다면 축하해 줘요.

그 연습 문제가 며칠째 대기열에 머물러 있었다면, 다음과 같이 언급해 볼 수 있어요:

답장이 좀 늦어서 죄송해요. Resistor Color Duo를 맡을 활동 중인 JavaScript 멘토가 지금 부족한 상황이에요.

멘티의 풀이에서 좋았던 점을 항목별로 나열해 줘요. 예를 들어:

• 이 풀이가 간결하고 읽기 쉽다는 점이 좋아요.

• indexOf를 사용한 점이 좋아요.

• 숫자를 문자열로, 다시 숫자로 변환하는 것을 피하려고 (first * 10) + second 방식을 사용한 점이 좋아요.

• 반복문이나 이터레이션을 사용하지 않은 점이 좋아요.

• 매개변수를 구조 분해한 점이 좋아요.

그다음에는 자주 하는 제안을 이어서 적을 수 있어요.

풀이를 그냥 알려 주고 싶지는 않지만, 멘티에 따라서는 예시를 통해 가장 잘 배우기도 해요. 접혀 있는 details 섹션에 코드 조각을 넣으면 그런 예시를 보여 줄 수 있고, 멘티는 펼칠지 말지를 스스로 고를 수 있어요. 예를 들어:

<details><summary>스포일러 예시</summary>

<pre>

export const decodedValue = ([firstColor, secondColor]) => COLORS.indexOf(firstColor) * 10 + COLORS.indexOf(secondColor)

</pre>

</details>

노트 끝자락에는 제안을 전부 반영한 공개된 풀이 링크를 넣을 수도 있어요.

노트 맨 아래에는 멘티가 가끔 물어보는 자세한 설명을 둘 수도 있어요. 이런 설명이 자주 나오는 건 아니지만, 처음 사용할 때 적어 두면 좋아요. 그러면 몇 주나 몇 달 뒤가 될 다음번에 설명을 처음부터 다시 떠올리지 않아도 되니까요. 예를 들어, 멘티가 Resistor Color Duo에서 검정이 앞자리 0을 나타내는 첫 번째 띠인 경우 곱셈 방식이 어떻게 동작하는지 물어보기도 해요:

검정이 첫 번째 띠라는 점은 짚어 볼 만한 좋은 지적이에요. 한번 생각해 봐요. 저항 색상은 저항의 옴 값을 나타내기 위한 것이고, 여러 띠를 가진 저항에는 앞자리 0을 쓰지 않아요. 그래서 검정이 첫 번째 띠가 될 수 없어요. 게다가 parseInt나 Number도 앞자리 0을 제거해요.

멘토링 노트에 선택적으로 기록해 둘 수 있는 데이터로, 여러 풀이나 접근 방식의 벤치마크 기록이 있어요.

벤치마킹

멘티들이 흔히 걱정하는 것은 자기 풀이의 성능이 어느 정도인지예요. 특히 C, C++, Go, Rust 같은 "저수준" 언어에서 그런 경우가 많아요. 다른 언어의 멘티들도 코드가 얼마나 관용적인지와 더불어 코드의 효율성도 자주 걱정해요.

Go는 벤치마킹에 특히 친화적인 트랙이에요. 벤치마크가 테스트 파일에 포함되는 경우가 많거든요. 다른 언어는 어떤 방법이 가장 잘 맞을지 알아내려면 좀 더 찾아봐야 할 수도 있어요. 예를 들어, 온라인 에디터만 사용한다면 온라인에서 벤치마크를 실행할 곳을 찾게 될 거예요. 예를 들어, JSBench.me는 JavaScript용 온라인 벤치마크 도구예요.

코드를 로컬에서 실행한다면, 자신의 컴퓨터에서 실행할 수 있는 벤치마킹 소프트웨어를 내려받는 선택지도 있어요. 예를 들어, Rust는 Criterion을 사용하거나 benchmark tests와 함께 cargo bench를 사용할 수 있어요.

벤치마크를 기록해 두는 방법은 적어도 몇 가지가 있어요. 한 가지는 벤치마크한 것들을 모두 계속 목록으로 유지하는 것이지만, 목록이 길어지면 다루기 힘들어질 수 있어요. 또 다른 방법은 여러 접근 방식을 대표하는 벤치마크 목록을 유지하는 거예요. 멘티들은 더 빠른 접근 방식의 코드를 보고 싶어 하는 경우가 많아요. 그래서 더 빠른 접근 방식이 공개되어 있다면 그 링크를 제공해 주면 아주 고마워할 거예요.

연습 문제에 한정되지 않는 멘토링 노트

하나 이상의 연습 문제에서 다루게 되는 언어 기능이 있을 수 있어요. 한 파일에서 다른 파일로 제안을 복사해 붙여 넣으려 할 때, 차라리 그 제안만을 위한 별도 파일에 넣는 것을 고려해 봐요. 다시 말하지만, 제안을 한곳에 두면 시간이 지나면서 다듬기 쉬워진다는 장점이 있어요. 전에 사용해 본 적 없는 연습 문제에 쓸 때 찾기도 더 쉬워요. 전에 어느 연습 문제에서 그 제안을 다뤘는지 기억해 내려 애쓰는 대신, 그 제안의 파일로 곧장 갈 수 있어요.

멘티가 질문할 때

멘티는 멘토링 세션에서 무엇을 얻고 싶은지 구체적으로 밝히도록 권장돼요. 그리고 그걸 흔히 질문의 형태로 표현해요. 그 질문에 대한 답을 모르고 관심도 없다면, 그 멘토링 요청을 다른 멘토에게 남겨 두어도 괜찮아요.

답을 모르지만 알아내고 싶다면, 답을 익힐 때까지 그 멘토링 요청을 맡지 않는 게 가장 좋을 수 있어요. 그때까지 그 멘토링 요청이 사라졌다 해도, 적어도 뭔가를 배웠고 멘티를 기다리게 하지는 않은 거예요.

한 가지 예외는 그 멘토링 요청이 이미 며칠 이상 대기열에 있었던 경우예요. 그런 상황에서는 그 멘토링 요청을 맡아서 할 수 있는 만큼 피드백을 주고, 질문에 대해서는 나중에 다시 연락하겠다고 멘티에게 알려 주는 게 좋아요. 물론 그 뒤에 꼭 후속 조치를 해야 해요. 답을 알려 주거나, 찾지 못했다는 걸 알려 주는 거죠. 답을 찾지 못했다면, 답을 찾기 위해 어떤 방법을 시도했는지 설명해 주면 멘티에게 도움이 될 수 있어요. 멘티가 답을 찾아볼 다른 방법을 알려 줄 수도 있어요. 두 사람이 힘을 합치면 답을 찾을 수도 있어요.

아는 모든 방법을 다 써 봤다면, 다른 멘토가 답을 줄 수도 있으니 멘티에게 논의를 끝내고 요청을 다시 제출하라고 제안할 수 있어요. 멘티가 원한다면, 나중에 답을 알게 되었을 때 끝난 논의에 글을 남겨 답을 공유할 수 있어요. 마찬가지로, 나중에 답을 알게 되면 끝난 논의로 돌아가 멘티에게 알려 줄 수 있어요.

답을 알고 있고 다뤄 주고 싶다면, 학생의 풀이에서 좋았던 점을 말해 주는 것과 다른 접근 방식을 제안하는 것 사이가 좋은 자리예요.

실패하는 코드

코드는 모든 테스트를 통과하지 못해서 실패할 수도 있고, 컴파일되지 않거나 인터프리터를 만족시키지 못해서 실패할 수도 있어요.

실패하는 코드를 다루는 데 대한 성향이나 인내심은 멘토마다 달라요. 그리고 그건 코드가 어떻게 제시되는지에 어느 정도 달려 있기도 해요. 실패하는 코드가 항상 같은 방식으로 제시되지는 않으니까요.

때때로 멘티가 다른 접근 방식을 시도했는데 안 됐다면서 왜 안 됐는지 물어보기도 해요. 코드가 아예 제공되지 않을 수도 있고, 이터레이션 대신 거의 읽을 수 없는 댓글에 올려져 있을 수도 있어요.

웹 에디터에서 테스트한 풀이는 모든 테스트를 통과한 경우에만 멘토링 요청으로 제출할 수 있어요. 그 이유 중 하나는 멘토가 이미 동작하는 코드에 대한 개선점이나 다른 접근 방식을 제안하는 데 집중할 수 있게 하기 위해서예요. 코드 _디버깅_은 멘토가 반드시 하고 싶어 하거나 해야 하는 일은 아니에요. 하지만 CLI를 통해 제출한 실패하는 풀이는 학생이 해결을 도와달라고 요청하는 멘토링 요청으로 제출할 수 있어요.

실패하는 코드가 제공되지 않았고, 설명된 실패한 접근 방식이 좋아 보이지 않는다면, 실패한 접근 방식을 쓰는 대신 실패한 접근 방식도, 통과한 접근 방식도 아닌 또 다른 접근 방식을 써 볼 수 있다고 제안하는 것으로 충분할 수 있어요. 또는 실패한 접근 방식에 어떤 버그가 있었는지 세세히 파고들지 않고, 사용한 접근 방식이 실패한 접근 방식보다 왜 더 나은지 설명하는 것으로 충분할 수도 있어요.

예를 들어, 멘티가 Robot Name에서 어려움을 겪는 일이 흔해요. 테스트가 시간 초과되거나 이름을 충분히 생성하지 못하고, 어떻게 고쳐야 할지 알고 싶어 하죠. 성향과 인내심이 있다면, 그 코드를 분석해서 문제를 어떻게 해결할지 제안할 수도 있어요. 또는 무작위로 생성한 이름을 확인하면 이름이 많이 생성될수록 충돌이 더 잦아진다고 설명하고, 이름을 순차적으로 생성한 뒤 섞는 다른 접근 방식을 제안할 수도 있어요.

실패하는 코드가 거의 읽을 수 없는 댓글에 붙여 넣어져 있다면, 통과한 풀이에 대해 할 수 있는 만큼 피드백을 주고, 그 댓글의 코드를 또 다른 이터레이션으로 제출해 보라고 제안하는 게 좋아요. 또한 멘티에게 실패한 이터레이션의 오류를 확인해서 문제가 어디 있는지 알아보라고 제안할 수도 있어요.

코드가 실패한 이터레이션에 있다면, 멘티에게 테스트 실행의 오류를 확인해 보라고 안내해 주면 도움이 될 수 있어요. 언어에 따라서는 오류나 테스트 결과를 읽는 방법에 대해 더 많은 안내가 필요한 경우가 있어요. 오류의 일부를 하나 이상 인용하고 학생에게 그 의미를 설명해 주면 도움이 될 수 있어요.

결국 실패하는 멘티의 코드를 고치는 건 멘토의 책임이 아니에요. 하지만 멘토가 원한다면 멘티가 스스로 고칠 수 있는 방법을 제안할 수는 있어요.

대기열 연속선 다루기

트랙 멘토링을 신청했는데 그 대기열에서 멘토링할 연습 문제가 전혀 보이지 않을 수도 있어요. 뭔가 잘못됐다고 생각할 수도 있지만, 여기에는 적어도 몇 가지 이유가 있어요. 한 가지 이유는 지금은 사람들이 그 트랙에서 멘토링을 요청하지 않기 때문일 수 있어요. 트랙에 따라 한동안 활동이 뜸한 시기가 있기도 해요. 또 다른 이유는 다른 멘토가 그 요청을 보기도 전에 먼저 맡아 가기 때문일 수 있어요. 활동 중인 멘토가 많은 인기 트랙에서 흔히 일어나는 일이에요.

대기열에 요청이 많다면, 그것들을 멘토링하는 방법이 몇 가지 있어요. 가장 오래된 것부터 최신 것 순으로 처리해서, 가장 오래 기다린 사람이 먼저 다뤄지게 할 수도 있어요. 또는 최신 것부터 오래된 것 순으로 처리할 수도 있어요. 특히 가장 오래된 것들이 이미 오래 기다린 경우에는요. 그러면 최근에 활동한 사람들이 밀린 요청이 처리될 때까지 기다리지 않아도 돼요.

같은 연습 문제에 대한 요청이 여러 개라면, 연습 문제 A에서 B로 갔다가 다시 A로 돌아오는 대신, 같은 연습 문제끼리 묶어서 처리하며 집중력을 유지하는 게 좋아요.

관심 없는 연습 문제에 대한 요청이 며칠이나 몇 주째 그대로 남아 있을 수도 있어요. 다른 멘토가 맡아 주기를 바라며 그냥 두거나, 오히려 그 연습 문제를 직접 한번 풀어 볼 동기로 삼을 수도 있어요. 도움이 될 만한 한 가지는 제출된 풀이를 살펴보는 거예요. 미처 생각하지 못한 접근 방식을 쓰고 있을 수 있고, 그 접근 방식이 그 연습 문제를 풀고 싶게 만들 수도 있어요. 그래도 코드를 보고도 여전히 그 연습 문제를 풀 마음이 안 든다면, 아무 문제 없어요. 멘토링 요청을 살펴봤다고 해서 "Start mentoring" 버튼을 눌러야 하는 건 아니에요.