2022년 테크 멘토 / 코치에 대한 회고



좀 더 보기 쉬운 링크를 준비했습니다.

2022년에는 iOS 개발자에서, 테크 멘토 / 코치로 새로운 커리어를 시작했습니다. 처음에는 강사, 교육자라고 생각했던 커리에서 다른 커리어 였다는 것을 깨닫고 난 후에 했던 시행착오와 의문들을 적어보았습니다. 한 해에도 몇 번의 생각이 바뀌었고, 그래서 앞으로도 바뀔 때 마다 적어두어야겠습니다.

선생님과 멘토는 무엇이 다른가요?

선생님과 멘토의 가장 큰 차이점은 정보의 전달이라고 생각했습니다. 어떤 방법이 더 나은 방법이다 라고 말할 수 없기 때문에 차이점에 초점을 맞춰서 답을 찾았습니다.

제가 처음에 가진 마인드는 선생님이었습니다.

질문을 하는 사림(학생)이 더 많은 것을 알도록 내가 아는 것을 전해주고, 그들이 모르는 것을 물어봤을 때 답을 해주는 사람이었습니다. 하지만 2022년을 보내면서 많은 시행착오 끝에 생각의 변화가 있었는데, 가장 처음에 든 생각은 선생님과 멘토는 다른 직군이다 였습니다. 그렇기 때문에 다른 일을 하는것이 자연스럽다고 생각했습니다.

그 다음으로 나아간 생각은 스스로 생각을 할 수 있게 도와주고, 그들이 넘어지고 쓰러졌을 때 응원해서 일어나게 하거나, 일어날 수 있도록 도움을 주는 사람이라고 생각했습니다. 이 것이 현재 많이 쓰이고 있는 멘토라는 용어의 정의와도 닮아 있다고 생각했습니다.

하지만 1년의 여정의 끝을 다 보고나면서 한 번 더 생각이 바뀌었습니다. 결국 (테크) 멘토는 그들의 잠재력을 발휘할 수 있도록 선택지를 높여주고, 그들의 깨달음을 도와주는 사람 이었습니다. 이 과정에서 중요한 것은 멘토의 생각을 주입하지 않는다 였습니다. 멘토의 경험과 생각을 주입하지 않고 그들의 잠재력을 끌어올리는 일은 너무나 어려웠습니다.

결국 멘토의 역할은 크게 2가지로 정리되었습니다.

  • 그들의 선택지를 어떻게 늘려줄 수 있을 것인가?
  • 그들의 깨달음을 어떻게 도와줄 것인가?

좋은 질문을 하는 방법은?

좋은 멘토의 역할은 결국 좋은 질문을 멘티들에게 던져주는 것입니다. 이런 관점에서 올 해 내내 했던 가장 큰 삽질의 포인트가 있었습니다.

멘토와 멘티는 경험과 생각의 갭이 매우 큽니다. 그래서 처음에는 그 갭을 줄이기 위해 많은 질문들을 했습니다.

  • 왜 그런 생각을 했는지?,
  • 그러면 어떤 결과가 있을 것인지?

하지만 이런 것들은 멘토가 가진 인사이트와 생각을 정확하게 멘티들에게 좋은 질문은 아니었습니다. 특히 ‘왜’ 로 시작한 질문은 격차를 낮추기 보다는 공격적으로 느껴져 방어적으로 생각하고 답을하게 만드는 질문이었습니다.

예를 들면 왜 이런 방법을 선택하게 되었나요?’ 보다는 ‘무엇이 이런 방법을 선택하게 만들었나요?’ 라는 질문이 멘티들에게 도움이 되는 결과를 만들어 주었습니다. 특히 중요한 점은 이 질문에 대한 답변이 멘토를 위한 것이 아니라 멘티 스스로 답을 찾을 수 있는 답을 하도록 해야한다는 것 입니다.

즉 멘토가 멘티가 대체 왜 이런 방법을 선택한거지를 이해하기 위한 질문 보다는, 멘티스스로가 말을 하면서 깨달을 수 있는 질문이 제일 좋은 질문이라는 생각에 도달하게되었습니다. 심지어 멘토는 이 멘티 머릿속에서 무슨 생각이 왔다갔다 하는지도 모르는데도 말이죠!

물론 내가 좋은질문을 했는지 아닌지를 검증하는 방법은 아직 찾지 못 했습니다.

하지만 질문을 하고 시간이 지나야 알 수 있다는게 어렵지만 그래도 시간이 지나고 나서 알 수 있다는 점은 불행 중 다행입니다.

그들의 스트레스에 공감하지 말자

너무나 차갑고 냉철한, 그리고 가까이 대하기에 어려운 멘토처럼 보일 수 있습니다. 하지만 이 부분 또한 많은 시행착오와 고민을 하게 만든 부분이었습니다.

멘티들은 많은 성장을 합니다. 그러면서 많은 성장통을 겪습니다. 관심이 가는, 애정이 가는 멘티들이 괴로워 하는 것을 보는 것이 유쾌한 멘토는 없을 것 이라고 확실하게 이야기 할 수 있습니다. 하지만 이러한 고통에 깊은 공감을 하기 시작하면 멘토는 본인이 그 문제를 해결해주거나, 해결하는 방법을 알려주거나, 해결에 대한 영향을 주게됩니다.

물론 좌절하고 다시 일어서기 힘든 적절한 때는 도와주어야 합니다. 하지만 제 생각보다 멘티들은 강했고, 그들을 걱정해서 한 저의 행동은 결과적으로는 그들을 약하게 만들었습니다. 결국 저에게 필요했던건 그들을 좀 더 믿고 그들의 성장통에 최대한 공감하지 않는 방법 이었습니다.

하지만 자칫 잘못하면 멘티와의 공감대 형성이 힘들어지거나, 방치했다라는 인식을 줄 수도 있어서 이 부분은 아직도 참 어렵습니다.

그들의 이야기를 많이 들어주자

위에서 공감하지 말자라는 이야기를 하자마자 이야기를 많이 들어주어야 한다는 이야기를 바로하는 이 혼란스러운 상황!

하지만 이 이야기는 문자 그대로, 그들의 이야기를 많이 들어주는 것이 필요하는 것 입니다. 여기서 가장 중요한 것은 그들의 이야기를 듣고 판단하지 않는 것 입니다.

이야기를 많이 듣는 이유는 멘티들이 생각을 정리하다가 그 들 스스로 깨달을 수 있는 기회를 더 많이주기 위해서 입니다. 그렇기 때문에 멘토에게 설명하게 하거나, 문제점을 정리해서 멘토에게 말하도록 하는 것은 매우 중요한 장치였습니다.

개인적으로 삽질(?)의 이야기와 소설과 같은 이야기를 들을 때, 당장이라도 그건 말도 안돼! 그러면 이런 경우에는 어떻게 할껀데? 와 같은 이야기를 해서 그들을 깨우쳐 주고 싶지만, 그것은 스스로 깨닫게 하는것 이라는 멘토의 역할에 위배되는 행동이기 때문에 스스로 참는 방법에 대해서 많은 고민을 했습니다. 잘 못 되었다는 판단은 멘토의 머릿속에서만 하고 그래서 멘토가 멘티들이 스스로 생각할 수 있는 질문을 입 밖으로 내야한다는 것은 너무나 어렵다는 것을 느꼈습니다.

멘티들의 수준을 정의하지 말자

그들은 놀랍습니다. 시작한지 얼마되지 않았는데 높은 수준의 앱을 만든다면 분명 칭찬할 만한 일입니다. 하지만 그렇다고 해서 거기까지가 끝은 아닙니다. 그들의 잠재력은 어쩌면 멘토보다 더 클지도 모릅니다. 멘토의 기준에 만족했다고 해서, 멘토가 보기에 대단해보인다고 끝내게 두면 안됩니다.

멘토의 역할은 그들의 선택지를 넓혀주고, 멘티들이 스스로 깨닫게 도와주는 역할이지 특정 지점까지 안락하게 데려다주는 역할은 아니라는 것을 느꼈습니다.

올 해 한해 엄청난 결과물을 많이 보았습니다. 하지만 어쩌면 나 스스로의 만족과 칭찬으로 인해서 멘티들의 성장을 막은 것은 아닌 것인가 라는 질문에 아니다 라고 답할 수 없었습니다.

맺음

높은 연차의 개발자는 좋은 멘토 라는 공식은 성립하지 않습니다. 개발자에서 멘토라는 새로운 영역에 발을 들여놓았던 1년을 마무리 하면서 멘토는 어떤 일을 하는 사람이고 또 어떤 것들은 조심해야하는지 시행착오를 통해 알 수 있었습니다. 이런 시행착오를 겪게 해준 멘티들에게 너무나 감사하고 또 너무나 미안합니다. 이 미안한 마음을 다음에 만나는 멘티들에게 더 좋은 멘토링으로 보답을 한다면 괜찮지 않을까 라고 위로를 하면서 잘 정리해 두었습니다.

혹시나 비슷한 생각이나 다른 생각이 있으신 분들은 언제나 댓글이나 메일(leeo@kakao.com)으로 의견 주시면 재미있는 이야기를 이어나갈 수 있습니다!



댓글

  1. 강사랑 선생님 구분을 못 하고 계신 것 같군요

    답글삭제
  2. 멘토는 선생님과 의미상 같고, 님이 생각하는 선생님의 개념은 강사에 해당합니다

    답글삭제
    답글
    1. 테크 멘토의 정의는 제가한거라 틀린게 아니라 다를 수 있습니다. 테크 멘토는 선생님과 의미상 같지 않습니다. 제가 생각하는 선생님과 강사의 개념은 크게 다르지 않습니다 :)

      삭제

댓글 쓰기

이 블로그의 인기 게시물

[IOS] AppDelegate는 뭐하는 녀석이지?

[git] git의 upstream과 origin 헷갈리는 사람 손!

[git] Github 이슈 라벨(issue labels)