개발 멘토의 커리어 1년차, 6개월 진행 중


좀 더 잘 보이는 노션링크 입니다


개발자와 개발 멘토는 엄연히 다른 직업이라는 것을 개발 멘토가된지 6개월이나 지난 시점에 어렴풋이 알게 되었습니다.

그리고 개발 강사와 개발 멘토 또한 다른 직업이며, 멘토가 가진 다양한 역할에 따라 스스로가 헷갈리지 않게 행동하기 위해서 정리 해두고 있습니다.

6개월 동안에 깨닫게 된 점이나, 그 사이에 맞이한 변화를 기록해두고 그 이후의 변화를 스스로 살펴보고자 기록합니다.

앞에서는 실패 하라고 하고 뒤에서는 취업해라

멘토가 되어서, 스스로 혼란을 느낀것이 바로 방향성 이었습니다. 멘토링의 대부분은 멘티 스스로에게 도움이 되는 방향과 방법을 찾아보자라고 많이 했습니다. 그 과정에서 “실패할 수도 있고 실패를 통해 성장하면 된다.” 라는 말들을 많이 했습니다. 듣기에는 달콤하고 당연한 이야기지만, 결국에는 현실에서는 목표로 향하는 속도가 문제입니다.

실패도 하고 성장도 하지만 결국 우리는 직업을 가지는 방향으로 기술을 공부합니다. 트렌드는 빠르게 변하고 해야할 것은 많은데 마냥 공부하라고 하고 실패하라는 것은 너무나 무책임해 보입니다. 그리고 마지막에 가서는 “자 이제 다 배웠으니 취업하자” 라는 말은 앞 뒤가 너무나 달라보였습니다.

마지막에 취업을 하지 못할 것 같아 보였으면, 그 전에 채찍질을 하거나 초반부터 느리게 달리는 것에 대한 따끔한 피드백을 했어야 할텐데 말이죠.

이러한 아이러니 속에서 사실은 결이 맞는 이야기를 하고 있다는 것을 깨달았습니다.

무조건 빨리 달리라는 것이 아닙니다.

우리는 목표를 향해 달려가는 중 입니다. 그리고 목표를 달성하기 위해서는 많은 배움 그리고 많은 실패도 필요합니다. 이러한 과정들이 괜찮은 것이지 자신만의 속도로 가라는 것이 천천히 가라는 뜻은 아니었습니다. 언제나 자신의 한계에 도달하면 괴롭고 힘이듭니다. 그러니 힘든일을 하지 말라는 것이 아니라, 어디까지가 스스로의 한계치이고 또 어디가 나의 목표점인지 알게 도와주는 것이 멘토의 역할이라는 것을 깨달았습니다.

그렇기에 “너만의 속도로 목표를 향해 달려가라” 고 했다가 기회를 놓치는 것은, 더 빨리 달리게 도와주지 못한 멘토의 실패 혹은 자신의 한계를 아직 알지 못하는 멘티의 실패가 같이 들어있는 것 일 것 입니다.

그리고 이미 빨리 달리면서 보상을 취하고 있는 멘티들을 경쟁상대나 부러움의 대상이 될 텐데 그들을 신경쓰지 않아도 되지만 그들의 업적은 인정해주어야 할 것 입니다.

멘토와 그리고 멘토가 있는 곳이 취업사관학교가 아니라는 말은 도전을 하지 말라는 것은 아닙니다. 취업 사관학교라는 곳이 취업만을 위한 곳 이라면, 취업을 하고나서 그 사람이 어떻게 되던지 그런 것들을 상관 없을 것 입니다. 어떤 사람들은 더 잘하고 어떤 사람들은 지쳐 나가 떨어질 것 입니다. 우리가 원하는 것을 향해 가다보면 취업도 있고 실력의 향상도 있을 것 입니다. 하지만 궁극의 방향은 지속적으로 성장하고 목표를 설정해 성장해 나가는 것 일것입니다.

원하는 것을 얻기 위해서는 도전이 필요합니다. 그래서 목표를 세우고 도전을하고 그 도전을 성공했다면 어떻게 할 수 있었는지 실패를 했다면 왜 실패를 했는지 돌아봐야 할 것 입니다. 도전을 하는 것도 중요하지만 도전을 해서 결과를 만드는 것 또한 중요합니다.

멘토링을 하는 사람은 전문가이어야 하는가

멘토는 정답을 주는 사람은 아닙니다. 하지만 많은 멘티들은 멘토에게 언제나 질문합니다.

  • 지금 이 선택을 하는 것이 맞을까요?
  • 이 길이 저에게 좋은 길 일까요?

놀랍게도 이 모든 질문들의 답은 본인들이 가지고 있습니다. 멘토는 멘티의 답을 듣고, 그 이유도 들을 다음에 주장과 근거를 잘 맞춰서 타당한지를 봐야 합니다.

스토리가 중요한 것이 아닙니다. 지금 당장 시작하지 않으면, 너무 늦을 것 같아서 바로 시작하려 한다와 같은 이유를 들었을 때, 그러면 시작해라 하지마라가 아닌 다른 질문을 해주어야 할 것 입니다.

지금 당장 시작하지 않으면 어떤 문제 점이 있는지? 그리고 그 문제들이 얼마나 심각한지 또 선택의 각각의 미래에는 어떤 모습일지 등 멘티의 머릿속에 있는 한 가지의 상황에서 나온 문제들의 답을 찾아주는 것이 아니라 그 문제들이 가져올 상황들을 단순화 해주고 선택지를 정리해서 스스로 선택할 수 있는 상황을 만들어 주는 것이 필요합니다.

그렇기 때문에 나만의 전문분야가 있는 멘토에게 지식이나 선택에 대한 질문을 하고 기대할 수 있겠지만, 실제로 멘토가 답을 해서 결정해주지 않기 때문에 전문적인 분야가 필요하지는 않다고 생각합니다.

지금의 전문가가 준 답이 나중에 혹은 그 사람에게는 정답이 아니게 될 수 있기 때문입니다. 멘티의 선택을 대신 해주는 멘토가 되고 싶지는 않습니다. 하지만 더 좋은 선택 스스로 책임질 수 있는 선택을 하게 도와줄 수는 있습니다.

그들의 문제를 파악한다

결국 멘토의 가장 큰 역할 중 하나는 그들의 목표가 무엇인지 알아내야 하는 것 일 것입니다. 개발을 하는데 어떤 버그를 만나서 2~3일간의 시간을 보내고 있는 경우를 본 적이 있습니다.

처음에는 직접 버그를 찾아주거나, 버그를 해결할 수 있도록 코딩을 해줘도 아무런 문제가 해결되지는 않습니다. 순간의 기분좋음이나 스프린트의 목표는 달성했을 수는 있지만 다시 그 문제를 마주했을 때 해결능력이 없다면 의미없는 도움이 되었을 수 있다는 생각이 들었습니다.

왜 매끄럽게 동작하지 못하는지 그 원인를 파악을 하는 능력을 키워야 하는게 멘토의 자질이라는 생각이 많이 들었습니다. 문제를 해결해주는 것이 아닌 문제의 원인을 파악해서 제거해서 그 다음번에 동작에는 매끄럽게 동작할 수 있게 만들어 주는 것. 그 부분에 노력을 기울이는 중 입니다.

항상 멘티들을 추적할 수는 없습니다. 그래도 이야기를 듣고 그들의 이야기를 이해할 때는 100% 몰입을 해서 들어야 합니다. 그 방법은 아직 알 수 없지만, 적절한 주기와 거리에서 그들을 계속 트래킹 하는 방법을 고민하고 있습니다.

패턴을 찾아보자

실제 아카데미에서 볼 수 있는 패턴과 유저 케이스를 파악하고 정리하려고 합니다.

빈도와, 패턴을 파악하면, 특이 케이스 인지 아니면 일반적으로 일어나는 상황인지 알기쉽습니다.

패턴을 알고 변화를 원하는 대로 줄 수 있다면 더 나은 멘토링을 할 수 있을 것이라고 기대합니다.

현재까지 인지하고있는 개별 멘티의 성향입니다.

1. 가슴이 뜨거운 행동파

행동파는 자신을 불태워 결과를 만들어 냅니다. 어떤 문제가 있으면 바로 해결해 버리려는 경향을 가지고 있습니다.

물론 논의를 이끌고 발산과 수렴을 즐거워 하는 것은 좋으나, 때로는 가고 있는 길이 맞는 방향의 길인지 확인할 수 있는 검증방법을 확인할 수 있도록 질문해야합니다.

문제의 원인을 차분히 들여다보고 해결해야하는 경우 원인을 정확하게 짚고 행동하고 있는지 질문해주면 좋습니다.

예) 요즘 너무 자주 지각을 하는게 문제이다 → 알람시계를 10분더 일찍 맞추자고 하는건 어떨까요? 일어나는 시간이 늦은게 지각의 원인은 맞지만 근본적인 문제는 왜 늦게일어나게 되는지를 살펴보고 그 문제를 해결할 수 있도록 질문을 해본다

2. 걱정이 태산이라 못움직여

못움직이는 분들은 신중하기에 움직이지 못하는 모습을 보입니다. 내가 만들어낸 결과가 어떻게 보일지, 혹은 쓸모있을지에 대해 많은 고민으로 인해 정작 움직이지 못하기 때문에 움직일 수 있도록 질문해주어야 합니다.

이 중에서 오랜 시간동안 고민을 하면서도 움직임을 가지지 못하는 경우는 실제 할 수 있는 액션아이템의 첫 단계를 제시해주기도 하고, 성취욕을 느낄 수 있도록 도와주는 방법으로 멘토링을 하면 좋습니다

예) SwiftUI와 UIKit 중에 무엇을 먼저 공부해야할지 모르겠다 → 일단 SwiftUI를 먼저 시작해보고 더 할지 UIKit을 할지 고민해보는 건 어때?

불완전 함을 참지 못하는 완벽주의자

완벽주의자는 모든 문제를 완벽하게 해결해야 다음으로 넘어가려는 모습을 보입니다. 완벽주의자와 함께 일하면 디테일한 부분까지 챙기기에 결과물의 퀄리티가 높아지는 경험을 할 수 있습니다. 하지만 어쩌면 결과에 큰 영향을 주지 않는 사소한 것들에도 굉장히 집착하고 쉽게 놓아주지 못해 오랜 시간을 제체하거나 에너지를 소비합니다. 이런 경우에는 우리의 목표가 무엇인지 상기 해보는게 도움이 될 것입니다. 모두의 의견을 하나로 모으는 것이 우리의 목표인지 아니면 무언가를 만드는 것이 목표인지 말이죠

예) 우리가 그려야 할 버튼을 정확하게 픽스하지 못하면 다음단계로 넘어갈 수 없어!

화려한 테크니션

이미 잘하는 테크니션이지만 다른 사람들과 협업을 하는 소프트 스킬은 부족할 수 있습니다. 이들의 능력치와 스킬은 뛰어나서 프로젝트 내에서는 엄청난 퍼포먼스를 보여주지만 팀 내에서의 평은 좋지 않을 수 있습니다. 더 잘하는 사람으로써 팀을 리링하는 방법과 팀에 기여해서 우리팀을 더 잘 돌아가게 한다면 훨씬 좋은 결과를 만들어 낼 수 있을 것 입니다. 반대로 팀에 회의감을 느끼거나, 다른 팀원들이 벽을 느끼게 된다면 0보다도 낮은 마이너스 영향력을 끼칠 수 있습니다.

예) 내가 하는 말이 맞는데 왜 다 반대하는거지… 다들 너무 느려!

그룹과 개인은 다르다

결국 멘토링의 결과물은 멘티들의 잠재력을 이끌어내줄 것인가에 대한 고민이었습니다. 그들이 원하는 결과와 목표에 어떻게 더 잘 그리고 빠르게 도달하게 할 수 있을 것인가를 고민했을 때 개인과 그룹의 차이점을 많이 발견했습니다.

1:1 멘토링에서는 그들을 인스파이어링 해주는 것에 목표를 두고 멘토링을 하게 되었습니다. 그것이 칭찬인지 훈계인지는 다르겠지만 멘토링 결과 동기를 부여하고 영감을 줄 수 있는 멘토링이 개인에게는 더 좋은 결과를 만들어 내는 것을 자주 보았습니다.

그룹 멘토링에서는 그들의 아이디어를 좀 더 날카롭게 만들고 팀이 잘 돌아갈 수 있게 멘토링을 했습니다. 지금 그래서 문제점이 무엇인지, 목표 점으로 가는데 존재하는 문제점이 무엇인지를 찾고 같이 해결할 방법을 고민했습니다.

그룹에서 문제점을 찾아가면서 항상 스토리를 많이 들었습니다. 왜 이런문제가 발생 했으며, 언제부터 발생했는지 또 어떻게 하면 해결될 것 같은지와 같은 내용들입니다. 물론 이 내용들을 듣는 것도 중요하지만 그 경청 아래에는 그래서 이 문제를 만들어낸 원인이 무엇이며, 어떻게 하면 그 원인을 잘 해소 해줄 수 있는지에 방향을 맞추었습니다.

지금 잘 하고 있는가?

지금 잘 하고있는 가라는 질문에는 지식의 습득 단계를 예로들어서 설명을 해주었습니다.

  • 모르는 것이 뭔지 모름
  • 모르는 것이 뭔지 앎
  • 아는 것을 앎
  • 뭘 아는지 모름

가장 먼저는 내가 무엇을 모르는지도 모르는 단계 입니다. 이 때는 무엇을 해야하는지도 모르고 이런 것들을 공부해야하겠다라는 것도 모릅니다. 이 단계에서는 앞으로 어떤 공부를 해야할 지를 찾도록 멘토링을 했습니다.

그 다음이 모르는 것이 뭔지는 알고있는 단계입니다. 그래서 멘티 스스로는 공부계획을 세우고 앞으로 어떤 것들을 해 나가야 하는지에 대해서도 인지하고있는 상태입니다.

더 나아가서 이제 내가 무엇을 알고있는지를 알고있는 상태입니다. 그래서 발표도 하고 다른사람들도 알려줄 수 있는 상태입니다. 두 번째 단계에서 다음단계로 넘어가게 할 때 다른 사람을 가르쳐보라고 합니다.

마지막은 본인이 무엇을 아는지 모르는 상태입니다. 이 때 부터는 기술블로그를 쓰거나, 정리를 통해서 자신이 알고있는 것들이 무엇인지를 모르는 상태에서 벗어나도록 가이드를 했습니다.

멘토링은 아트와 비슷하다

예술작품은 정보를 전달하지는 않습니다. 하지만 어떤 작품을 보면서 작가의 의도대로 무언가를 느끼고 생각한다면, 의도가 잘 전달 된 작품이라고 생각합니다.

우리도 우리의 멘토링이 어떤 지식이나 정보는 전달하지 않지만 그 작품을 접한 사람이 의도된 곳으로 가는 것이 예술과 닮아있습니다.

어떻게 하면 의도와 메시지를 더 잘 전달할 수 있을지 연습해볼 필요가 있다고 생각합니다.

댓글

이 블로그의 인기 게시물

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

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

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