성장하는 개발자의 모험: Learning Zone Model로 성장하기

안녕하세요. F-Lab  'Python Backend' 과정 멘토 Jacob 입니다. 저는 센드버드 출신의 엔지니어링 조직 문화와 생산성에 관심이 많은 개발자입니다. 오늘은 Learning Zone Model 을 통해서 성장하는 방법을 알아보려고 합니다.

개요

회사에서 성장이 정체되었다는 느낌을 받으신 적이 있으신가요? 소프트웨어 엔지니어로써 직장 생활을 하면 누구나 성장의 정체를 겪습니다. 성장의 정체를 해결하기 위해서 멘토를 찾거나 새로운 업무에 도전해보기도 하고 평소에 하던 업무를 다른 방식으로 하려고 노력해보기도 합니다. 이러한 방법론들은 성장의 정체라는 문제에 대한 부분적인 해결책을 제시하지만 문제를 해결하는 일반적인 방법론에 해당하지는 않습니다. 따라서 이러한 방법론들을 따랐을때 사람에 따라서, 그리고 상황에 따라서 문제가 해결될수도 있고 그렇지 않을수도 있습니다.

배우는 속도가 느려지는 일

그렇다면 성장의 정체란 무엇일까요? 다양한 정의가 있겠지만 필자는 성장의 정체가 "배우는 속도가 느려지는 일" 이라고 생각합니다. 주어진 업무에 통달해서 해당 업무와 관련해서는 배울 것이 많이 남아있지 않을수도 있고 업무의 난이도가 높아서 자신의 기술이나 경험의 한계에 부딪혀 업무로부터 새로운 것을 배우는 것이 어렵게 느껴지는 경우도 있을것입니다. 두 예시는 전혀 다르지만 "성장이 느려진" 상황에 해당할 수 있습니다. 성장의 정체가 "배우는 속도가 느려지는 일" 이라면 배우는 속도를 높이는 것으로 정체를 해결할 수 있을 것 같습니다. 그렇다면 회사라는 환경에서 배우는 속도를 높게 유지하려면 어떻게 해야 할까요?

Learning Zone Model

많은 사람들이 무언가를 배울때 편안하고 익숙한 환경에서 배우는 것이 더 효율이 높다고 생각합니다. 하지만 Learning Zone Model 은 편안한 환경을 벗어났을 때 학습 능력이 더 높아진다는 통념과는 사뭇 다른 관점을 제시합니다. 이 모델은 Lev Vygotsky 와 같은 심리학자들에 의해 개념화되었으며, Tom Senninger 와 같은 교육자들에 의해 널리 알려지게 되었습니다. Learning Zone Model 은 학습의 효율을 극대화하기 위해서는 익숙하지 않은 환경에 스스로를 노출시켜야 하지만 동시에 주어진 상황으로 인해서 혼란에 빠지지는 않아야 한다고 주장하며 그러한 내용을 세가지 영역을 활용한 모델링으로 개념화합니다. Learning Zone Model 에서 제시하는 세 영역은 "Comfort Zone", "Learning Zone" 그리고 "Panic Zone" 이며 각각은 이름 그대로 학습자가 편안한 영역, 배우는 영역, 혼란에 빠지는 영역을 의미합니다.

1. Comfort Zone

Comfort Zone 은 익숙함과 일상을 대변합니다. 여기에서는 사람들이 이미 보유한 기술과 지식을 활용하여 안정적으로 활동합니다. 안락 지대는 안정성을 제공하지만, 그 안에 머무르는 것은 많은 경우 개인과 전문적인 성장을 제약할 수 있습니다. 이미 숙달된 업무, 잘 알고 있는 기술이 Comfort Zone 에 해당할 수 있습니다. Python 을 주로 사용하는 백엔드 엔지니어인 필자에게는 단순한 CRUD 어플리케이션을 만드는 일이 여기에 해당할것 같습니다.

‘Comfort Zone’ 은 안정성을 제공하지만, 그 안에 머무르는 것은 많은 경우 개인과 전문적인 성장을 제약할 수 있습니다.

2. Learning Zone

Learning Zone 은 Comfort Zone 바로 바깥의 영역입니다. Comfort Zone 을 벗어나면 낯선 환경에 스스로를 노출시킬 수 있고 여기에서 성장의 가능성이 펼쳐집니다. 이 영역에서는 사람들이 익숙하지 않은 일로부터 도전을 받고 새로운 기술을 습득합니다. 가령 필자의 경우에는 웹 브라우저가 어떻게 동작하는지, SPA에서 렌더링은 어떻게 이루어지는지 이해하는것이 이 영역에 해당할수 있을 것 같습니다.  Learning Zone 에서는 많은 경우 익숙하지 않은 기술이나 지식이 요구되며 그러한 기술이나 지식의 습득에는 호기심과 인내심, 그리고 빠르게 학습하는 능력이 필요합니다. 이러한 능력들은 스스로를 Learning Zone 에 자주 노출 시킬수록 발전시킬 수 있습니다.

‘Learning Zone’ 에서는 낯선 환경에 노출되며, 여기에서 성장의 가능성이 펼쳐집니다.

3. Panic Zone

Panic Zone 은 위에서 언급했듯이 Learning Zone Model 에서 가장 바깥쪽의 영역입니다. 과도하게 난이도가 높은 업무나 어디서부터 시작해야 좋을지 모를 난해한 문제가 이 영역에 해당합니다. 이 영역은 개인에게 불안감과 스트레스를 주고 스스로가 문제 해결을 위한 실마리를 찾기 어려운 상황에 빠지게 만듭니다. 따라서 개인이 학습하는 속도를 떨어트릴 뿐만 아니라 학습에 대한 의욕도 꺾이는 결과를 가져올 수 있습니다.

과도하게 난이도가 높은 업무나 어디서부터 시작해야 좋을지 모를 난해한 문제를 맞이하면, ‘Panic Zone’ 에 놓여지게 됩니다.

위의 설명에 따르면 배우는 속도를 높게 유지하려면 Comfort Zone 에서 벗어나야 하지만 동시에 Panic Zone 에 들어가는 상황을 피해야 할 것 같습니다. 필자는 Panic Zone 에 들어가는 상황을 피하기 위해서는 무엇보다도 안정감을 확보해야 한다고 생각합니다. 다시 말해서 Panic Zone 에 들어가는 상황을 피하기 위해서는 스스로가 성공적으로 학습할 수 있다고 믿어야 합니다. 학습 과정에서 어려움이 있을 수 있지만, 이를 극복할 수 있는 자신감을 가지는 것이 중요합니다. 스스로가 잘 할수 있는지 확신이 들지 않는다면 더 작은 단위의 성공 사례들을 모아나가는것도 좋은 시작점이 될 수 있습니다.

새로운 기술이나 지식을 학습하는 일은 막막할 수 있습니다. 이럴 때 이미 알고 있는 기술과 지식을 발판 또는 징검다리로 삼으면 막막함이 덜어지고 스스로에게 자신감을 불어넣을 수 있습니다. 또 이러한 익숙한 것들을 활용하는 접근 방식은 내가 실행하고 있는 것들이 맞는지 불확실하게 느껴지는 상황에서 아는것들 부터 점검 할수 있도록 도움으로써 안정감을 제공합니다.

안정감 제공하기

학습 과정을 모두 혼자서 해내기란 어렵습니다. 혼자서 학습을 하다가 벽에 부딪힌 상황에서는 멘토나 주변 사람들의 도움을 받는 습관을 길러야 합니다. 모든 것을 처음부터 잘 하는 사람은 없기 때문에 주변의 지원과 피드백을 받는것을 주저하지 않아도 괜찮습니다. 질문을 할때는 스스로가 이해한것과 지금 부딪힌 문제에 대해서 빠짐없이 공유한 후에 도움을 요청하는것이 좋습니다. 경우에 따라서는 스스로가 이해한 것들을 설명하는 과정에서 답을 스스로 찾아내기도 합니다.

반대로 주변에서 도움을 요청하는 경우에도 도움의 손길을 내미는 것을 권하고 싶습니다. 심적 부담 없이 도움을 주고받는 환경을 만들면 구성원 모두의 성장에 도움이 됩니다. 또 기회가 된다면 주변 사람들에게 혹시 요즘 어려움을 겪고 있는 것은 없는지 물어보는것도 좋습니다. 실질적인 도움을 주지 못하더라도 격려나 다른 시각을 제시하는 것만으로도 사람들이 학습하는데 큰 도움을 줄 수 있습니다.

Learning Zone Model 활용하기

지금까지 Learning Zone Model 이 어떤 것이고 이 모델을 어떻게 활용해서 꾸준히 성장할 수 있는지 알아봤습니다. 가상의 주니어 개발자의 하루로 Learning Zone Model 이 어떻게 활용될 수 있는지 예시를 들면서 블로그 글을 마무리하도록 하겠습니다.

김코딩은 대학교 졸업 후 지난 달 스타트업에 취업한 백엔드 개발자입니다. 학교에서 기본적인 내용들은 배웠지만 HTTP를 기반으로 동작하는 간단한 CRUD 어플리케이션을 만드는 것 이상의 실무 경험은 없는 상태입니다. 오늘 아침 회의에서 사수로부터 이미 존재하는 REST API 하나와 동일한 일을 하는 GraphQL API 를 만들어보라는 업무를 할당받았습니다.

 

김코딩은 GraphQL 이 어떤 것인지 알지 못하기 때문에 당황했습니다. 하지만 곧 이것이 Learning Zone Model 에서 Learning Zone 으로 갈 수 있는 기회라고 생각했습니다. 새로운 기술을 사용하려면 우선 기술의 존재 의의와 한계를 알아야 하기 때문에 GraphQL 공식 문서를 읽었습니다. GraphQL 은 HTTP를 기반으로 하지만 REST API 와는 다르다고 생각했기 때문에 REST API 와 어떤 점이 다른지를 주의깊게 읽었습니다. 관련 라이브러리 항목에서 기존 코드베이스에 이미 존재하는 라이브러리가 있는 것을 확인했습니다. 코드베이스에 존재하는 GraphQL API 관련 코드를 참고하는 것으로 할당받은 업무를 해낼 수 있을 것 같다고 생각했습니다.

 

하지만 하필이면 오늘 따라 만들어야 하는 REST API 에서 존재하는 리소스에 대한 스키마가 GraphQL 관련 코드에 존재하지 않는다는것을 알게 되었습니다. 스키마의 개념은 이해했지만 리소스를 올바르게 표현한것인지 확신이 들지 않습니다. 김코딩은 사수에게 현재까지 학습한 내용과 직접 만든 스키마를 공유하고 조언을 구합니다. 사수는 relationship 과 관련된 정의가 이상해보인다고 말하며 공식 문서를 열어서 명세를 보여줍니다. 김코딩은 사수의 조언을 기반으로 스키마를 수정합니다. 나중을 위해서 오늘 배운 내용을 바탕으로 회사 내부 위키에 스키마 작성법과 관련된 가이드를 작성해 공유합니다.

마무리

김코딩은 오늘 Learning Zone 에 스스로를 위치 시킴으로써 GraphQL 이라는 기술에 대해서 배울 수 있었을 뿐만 아니라 사수가 공식 문서의 명세를 참고해서 불분명한 지점들을 해결하는 방식도 습득했습니다. 혼자서 학습을 하다가 막히는 부분이 있을때 사수에게 질문을 하고 함께 문제를 해결하는 경험을 통해서 앞으로 문제가 있는 상황에서 빠르게 질문을 할 수 있다는 자신감도 얻었습니다. 독자 여러분도 위의 예시처럼 Learning Zone Model 을 활용해서 성장하는 개발자가 되어 보시면 어떨까요?