개발자 멘토링, 아무에게나 받지 마세요
개발자 멘토링은 주로 멘토가 멘티의 이력과 상황, 궁금한 점을 파악하는 것으로 시작합니다. 그렇게 어느 정도 파악을 마쳤다면 멘티가 놓친 관점이나, 잘못 알고 있는 부분을 바로 잡으며, 정답에 가까워지도록 방향을 잡아 줍니다. 다음으로는 잡아준 방향이 쉽게 틀어지지 않도록 여러 관점에서 생각의 방법을 제시해 주는 과정을 거칩니다.
요즘은 많은 개발자가 취업과 이직을 어려워하는 한편 개인 브랜딩이 넘쳐나는 세상입니다. 그러다 보니 멘토를 자처하는 사람도, 멘토링을 받고 싶어 하는 사람도 많아졌고, 그렇게 잘못된 멘토링도 많아지기 시작했습니다. 멘티들이 멘토를 고르는 데 알아야 할 요소보다 눈에 보이는 출신 회사나 괜찮아 보이는 말에 휘둘리기 쉬워 더욱 그렇습니다.
그래서 이 글에서는 제대로 멘토와 멘토링을 판단하는 방법을 알려 드리려고 합니다.
무작정 출신 회사만 믿지 말자
멘토링을 받으려고 할 때 가장 먼저 보는 것, 혹시 “출신 회사”인가요?
“당연히 대기업 다닌 사람이 멘토링도 더 잘하겠지?”라고 생각하지는 않나요?
멘토링을 받는 분들이 가장 많이 하는 실수가 이 지점입니다.
“대기업 출신” 같은 정보는 멘토링을 받기 전, 멘티가 멘토를 무작정 신뢰하게끔 하는 장치입니다. 하지만 정작 대기업에서 채용할 때는 멘토링 능력을 보지 않습니다. 회사와 팀에 맞는 개개인의 역량을 보고 뽑을 뿐입니다. 따라서 ‘대기업 출신이라고 모두 좋은 멘토가 될 것이다’라는 전제는 잘못된 생각입니다.
그럼 어떤 멘토가 내게 맞는 사람일까요?
“나와 비슷한 환경을 경험하고, 극복해 본 사람”입니다.
만약, 내가 당장 부트캠프를 수료해 빠르게 취업하는 게 목표라면, 대기업 멘토보다는 중소기업부터 경험해 본 사람이 나의 상황을 이해하기 쉽습니다. SI 회사에 다니고 있는데 서비스 회사로 이직하고 싶다면, 서비스 회사에 바로 취업한 사람보다는 SI에서 서비스 회사로 이직한 경험이 있는 멘토가 상황을 이해하기 쉽습니다.
결국 멘토는 나에게 조언을 해주는 사람입니다. 그러니 “내게 어떤 조언을 해줄 수 있는가”를 판단하는 것이 가장 중요합니다.
자기 이야기만 하는 사람은 피하자
멘토링이란 멘토가 본인의 경험만을 이야기하는 것이 아닌, 멘티의 상황을 파악하고 그에 맞는 최선의 방향을 제시해 주는 과정입니다.
그런데 이력서를 피드백하거나 대화를 할 때 “무조건 이건 이렇게 하세요”, “이게 맞아요”라는 이야기만 한다면, 멘토링을 받는 의미가 없습니다.
무엇보다 어려운 점은, 멘토링을 받은 직후에는 멘토의 이야기가 대부분 맞는 말처럼 느껴진다는 점입니다. 그 때문에 잘못된 부분을 인지하기가 어렵습니다. 그렇게 멘토의 잘못된 의견대로 취업이나 이직을 준비해도 생각만큼 합격률이 높아지지 않습니다. 그러다 멘토가 한 이야기와 다른 말을 하는 사람이 나타나면 그제야 잘못된 부분이 있었다는 생각을 하는 거죠.
이 문제는 멘티가 멘토를 근거 없이 맹목적으로 신뢰해 올바른 판단을 하지 못할 때 발생합니다.
이런 상황을 줄이기 위해 멘티가 알아야 할 것이 있습니다. 올바른 멘토링의 핵심은 “새로운 관점과 명확한 근거 제시로 멘티 스스로 판단하고 생각할 능력을 길러주는 것”이라는 점입니다.
만약 이력서에 대한 멘토링을 성공적으로 받았다면, 멘토링 이후에는 어떤 기업의 이력서든 적을 수 있으며, 이력서에 대한 목적과 방향을 명확히 할 수 있어야 합니다. 그렇게 기준이 명확하게 잡혀 외부의 다른 의견에도 쉽게 흔들리지 않는 상황이 와야 합니다.
이처럼 좋은 멘토링은 “멘토가 어떻게 하면 된다”를 알려주는 것이 아닌, “멘티가 어떻게 하면 될지를 생각하게 만드는 것”에 가깝습니다.
그럴듯한 이야기에 속지 말자
사실 멘토링을 받기 전이나 멘토링을 받다가 무엇이 잘못된 멘토링인지 판단하는 것이 쉽지만은 않습니다.
그래서 멘토링이 끝난 다음 멘티의 반응 예시를 몇 가지 준비해 봤습니다. 아래 예시에서 ‘잘못된 멘토링의 사례’라고 할만한 것은 무엇일까요?
- 멘토님이 제 이력서를 보고 성과가 부족해 보이니 성과를 추가하면 좋겠다고 합니다.
- 이력서는 회사가 팀에 맞는 사람을 뽑기 위해 적는 것이니, 제가 팀에 맞는 사람이라는 걸 어필하려고 합니다.
- SI에서 대기업으로 넘어갈 때는 하드 스킬이 중요하므로, 대규모 트래픽 관련 프로젝트 정도는 필요하다고 합니다.
- 요즘 하드 스킬보다는 소프트 스킬이 중요하다고 강조해서, 기술보다는 경험에 기반한 어필 요소를 찾고 있습니다.
- 기업이 왜 문제를 해결하는 사람을 뽑으려 하는지 이해했기에 이를 기반으로 강점을 어필할 수 있겠습니다.
제가 생각하는 잘못된 멘토링 사례는 1번, 3번, 4번입니다.
잘못된 멘토링이 끼치는 영향
“멘토님이 제 이력서를 보고 성과가 부족해 보이니 성과를 추가하면 좋겠다고 합니다.”
성과를 추가한다고 이력서가 좋아지는 것은 아닙니다. 멘티의 경험이나 경력에서 성과를 부각하는 것이 어려운 경우도 있습니다. 또, 어필하기 어려운 성과를 늘어놓다 이력서의 가독성을 낮추는 결과가 생길 지도 모릅니다. 이처럼 왜 성과를 추가해야 하는지, 그 목적을 함께 알지 못하면 결국 방향을 잃을 수 있습니다.
좋은 멘토의 한마디: 이 채용 공고는 3년 차 이상이 조건인데, 이런 경우 실무를 할 수 있는 사람을 뽑는 경우가 많아요. 그러니 자신이 주요 업무를 충분히 진행할 수 있다는 것을 증명할 성과나 경험을 어필해야 해요.
“SI에서 대기업으로 넘어갈 때는 하드 스킬이 중요하므로, 대규모 트래픽 관련 프로젝트 정도는 필요하다고 합니다.”
하드 스킬이 중요한 것은 맞지만, 그 스킬만 중요한 것은 아닙니다. 또, 적절한 하드 스킬의 수준으로 ‘대규모 트래픽 경험’만을 언급하는 것은 지나친 일반화입니다. 대기업에도 다양한 포지션이 있는 만큼, 꼭 트래픽 관련 경험이 없어도 다른 강점으로 이직할 수 있습니다. 멘토링은 특정한 방향으로 고정해 몰아가는 방식이 아닌 멘티의 강점에 기반한 현실적인 전략을 찾을 때 더 효과적입니다.
좋은 멘토의 한마디: 멘티님이 노리는 채용 공고를 보니, 사내 시스템 개선 작업이 들어 있네요. 특히, 시스템 자동화가 중요하다 하고요. SI에서 얻은 경험 가운데 시스템 자동화를 다루었던 경험을 어필해 보세요. 만약 그런 경험이 없다면 사이드 프로젝트로 자동화 경험을 얻어 보면 좋겠습니다.
“요즘 하드 스킬보다는 소프트 스킬이 중요하다고 강조해서, 기술보다는 경험에 기반한 어필 요소를 찾고 있습니다.”
여기서 문제는 하드 스킬과 소프트 스킬의 중요도가 산업과 회사, 포지션에 따라 다르다는 점입니다. "요즘은 소프트 스킬이 더 중요하다"라는 식의 조언은 멘티에게 오히려 혼란만 줄 수 있습니다. 상황에 따라 적절한 균형을 잡으며 멘티 스스로 판단할 수 있도록 도와주는 것이 더 좋은 멘토링입니다.
좋은 멘토의 한마디: 멘티님의 이력서에 보이는 하드 스킬은 충분히 경쟁력이 있지만, 채용 공고에서 원하는 팀원 간의 소통이나, 사용자 관점에서의 사례가 없네요. 그래서 소프트 스킬에 대한 어필을 못 하고 있어요. 결국 팀원과 함께 업무하는 것이고, 프로덕트를 사용하는 사람의 관점을 알아야 하니 하드 스킬만으로는 어필이 부족할 수 있습니다.
이처럼 잘못된 사례의 공통점은 무엇일까요? 그럴듯해 보이지만, “왜?”가 빠져 있다는 것입니다.
왜 성과를 입력해야 하는지, 왜 이런 하드 스킬을 어필해야 하는지, 왜 소프트 스킬이 중요한 건지, 이를 알지 못한 채로 멘토링을 진행하면 멘티가 여전히 다른 의견에 쉽게 흔들릴 가능성이 있습니다.
만약 좋은 멘토의 한마디 없이, 다른 사람으로부터 이런 말을 들었다면 어땠을까요?
- 성과가 부족한 게 아니라, 방식이 문제네요. 문제 제시 / 해결 방식으로 바꿔야 할 것 같아요.
- 요즘엔 대규모 트래픽 경험도 많아서, MSA(마이크로 서비스 아키텍처) 정도까지는 알아야 어필될 거예요.
- 소프트 스킬이 중요한 건 맞는데, 일단 개발자라면 하드 스킬에 기반을 두어야 해요.
‘이것도 맞는 말 같은데 뭐가 정답이지?’라는 생각에 다시 한번 혼란스러웠을 거예요.
좋은 멘토링이 끼치는 영향
좋은 멘토링을 받은 멘티의 반응을 다시 한 번 보겠습니다.
“이력서는 회사가 팀에 맞는 사람을 뽑기 위해 적는 것이니, 제가 팀에 맞는 사람이라는 걸 어필하려고 합니다.”
“기업이 왜 문제를 해결하는 사람을 뽑으려 하는지 이해했기에 이를 기반으로 강점을 어필할 수 있겠습니다.”
이 케이스의 공통점은 직접적으로 “무엇이 부족하다”고 한 것이 아니라, “회사의 채용 이유”와 “이력서의 목적” 등 본질을 기반으로 했다는 점입니다.
이력서의 본질은 회사가 팀에 맞는 사람을 뽑기 위함이므로, 결국 “누구를 뽑을지”는 채용 공고에 나와 있는 것을 봐야 합니다. 또한, “기업이 왜 문제를 해결하는 사람을 뽑는지” 채용 공고 기반으로 이해해야 합니다. 그래야 “채용 공고를 기준으로 자신이 이 회사에 맞는 사람임을 어필”할 것입니다.
이처럼 “왜?”에 대한 근거는 채용 공고를 기반으로 이야기해야 합니다.
결국 좋은 개발자 취업 멘토링은 내가 이 회사에 들어가기 위해 어떤 것이 중요한지, 어떤 관점이 있는지를 알려 주고, 멘티가 직접 논리적으로 생각하며 이력서를 작성하게 유도하는 과정이어야 합니다.
불안감을 증폭시키는 사람을 피하자
간혹 “그러다가는 취업/이직 못 해요, 내가 말하는 대로만 따라 해 봐요.”, “요즘은 다들 이거 배우는 데 아직도 몰라요?”라는 말이 멘토링에서 나오는 경우가 있습니다.
저런 말은 대표적인 영업용 멘트로, 멘티의 불안을 만들어 돈을 버는 사람들이 할 법한 말입니다.
저런 멘트로 불안감이 커진 멘티는 무슨 생각을 할까요? 그 기술이 무엇인지 관심을 가지거나, 실제로 강의 등을 구매하는 경우도 많을 것입니다. 무언가를 팔 때 가장 쉬운 방법은 사람들의 불안감을 증폭시키는 것이니까요.
게다가 기본적으로 멘토링에는 예의가 필수입니다. 아무리 좋은 조언이더라도 예의가 없으면 무례한 잔소리가 됩니다. 위와 같은 말은 멘토링의 질과 별개로 이미 상대에게 피해를 주는 것이기 때문에 좋지 않습니다.
마치며: 결국, 판단은 ‘내’가 해야 한다
멘토링의 마지막 목표는 멘티 스스로 상황을 판단하고, 해결할 능력을 갖추도록 하는 것입니다.
하지만 누군가는 멘토링을 돈벌이로만 생각하며, 이러한 본질을 간과하기도 합니다. 그리고 이런 상황을 막아줄 플랫폼도 현재로는 찾기 어렵습니다.
만약 좋은 멘토를 찾고 싶다면, “자신이 바라는 회사에 다니는 사람” 또는 “현재 자신의 문제와 비슷한 경험을 글로 공유한 사람”과 직접 이야기해 보는 게 가장 좋습니다. 블로그나 링크드인처럼 자신의 생각을 이야기하는 공간에서 나와 비슷한 경험을 해온 사람을 찾아보세요. 그리고 개인 메시지로 커피챗 또는 상담을 신청해 보는 것이 좋습니다. 또는, 컨퍼런스와 외부 네트워킹 행사에서 여러 사람을 만나며 고민을 이야기해 보는 것도 방법입니다.
빠르게 멘토링을 받고 싶은 분이라면 인프런 같은 플랫폼에서 활동하는 멘토를 찾아도 좋습니다. 다만 신청 전에 멘토 닉네임을 기반으로 SNS를 찾아 어떤 프로세스로 진행할지 먼저 물어보고 신청하는 것을 추천합니다.
만약 접점을 만드는 데 실패하더라도 시도해서 손해 볼 것은 없습니다. 도움을 받고 싶어 연락하는 사람에게 거절은 할 수 있다 해도 무작정 화를 낼 사람은 많지 않으니까요.
결국 이 모든 것을 판단해야 하는 사람은 멘토링을 듣는 자신입니다. 이 글 역시, 제 주장과 근거를 평가하고 논리가 있는지 직접 판단하고 받아들여야 합니다. 조언을 무조건 받아들이기보다 근거와 논리를 검증하며 자신의 상황에 맞는지 판단해 보세요.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
