개발자가 더 큰 성장을 이루는 방법

feat. 교육자

개발자가 더 큰 성장을 이루는 방법 (feat. 교육자)

SW 개발 생태계에서 성장이라는 키워드가 참 많이 보이는 것 같다. 물론 다른 직군에서도 많은 사람들이 지속적인 발전을 추구하고 있을 것이라고 생각한다.

성장 마인드셋의 주요한 사항 중 하나는 타인을 경쟁자가 아닌 함께 성장하는 동료로 보는 것이다. 신기하게도 SW 업계는 공유 문화에 아주 익숙하다. 오픈 소스가 대표적인 예다. 그 외에도 전 세계적으로 개발자 모임이나 행사가 개최되고 지식이나 경험을 공유한다.

하지만 이런 문화 속에서 불안함을 느끼는 사람도 분명히 있다. 남들은 모두 성장하고 있는 것 같은데 본인만 정체된 것이 아닐까 하는 마음 때문일 것이다. 무엇이든 진정 원해서가 아니라 해야만 해서 억지로 매달리게 되면 굉장히 힘이 든다.

성장에 집착하는 순간 성장은 더 이상 성장이 아니다. 그것은 곧 불행이고 괴로움이 된다. 그럼에도 불구하고, 우리는 해야만 할 때가 있다. (그것이 어른이니까…)

그러면 우리는 과연 성장하는 방법을 제대로 알고 있을까? 흔히 다이어트 방법을 몰라서 살을 못 빼는 것이 아니다, 공부하는 방법을 몰라서 안 하는 것이 아니라는 농담을 한다. 근데 그게 모르고 있다는 사실조차 모르고 있는 상태일 수도 있다.

어쩌면 그것이 가장 위험한 상태가 아닐까? 그러면 어떻게 해야 성장할 수 있을까?

지금부터 할 이야기는 정답이 아니다. 개인적인 경험과 몇 가지 이론에 대한 이야기다.

메타인지를 통한 성장 마인드셋 갖추기

나는 뛰어난 개발자가 아니다.

학부 시절이나 회사에서 주변을 둘러보면 항상 재능 있는 사람이 존재했다. 정말 저런 사람이 개발자를 해야지 싶은 사람이 있다. 굳이 따지자면 난 그런 부류는 아니다. 그래서 내가 모자란 사람이라는 것을 늘 인지하고 있었다. 그게 한편으로는 도움이 되었다. 일말의 학습에 대한 필요성을 느끼기 때문이다.

훌륭한 동료들

주변에 뛰어나다고 느끼는 동료가 있다면 그것은 곧 좋은 선생님이 존재한다는 의미다. 동료에게 배우는 것이 부끄럽거나 자존심 상한다면 아직 배울 준비가 덜 된 것이다. 비슷한 처지에 있는데 나보다 더 잘하는 것이 배 아프거나 시기 질투심이 생긴다면 그것은 성장 마인드셋이 갖춰지지 않은 것이다. 주변에 훌륭한 동료들이 있다면 나 또한 그들처럼 될 수 있다고 긍정적으로 생각하고, 학습에 대한 동기 부여로 활용하자.

주어진 환경(이라는 핑계)

훌륭한 동료가 많아도 함께 학습하는 분위기가 아니라면 큰 도움이 안 될 수 있다. 회사가 학교는 아니기 때문이다. 업무가 우선이기 때문에 개인 시간을 할당하여 함께 학습하기란 쉽지 않다. 그러면 외부로 눈길을 돌리는 방법이 있다. 성장 마인드셋이 있는 사람들이 분명히 스터디나 커뮤니티를 만들어서 운영하고 있을 것이다.

사실 그 이전에 업무 자체에서 배울 수 있는 것이 분명히 있다. 그것에 먼저 집중하는 것이 중요하다. 그러면 일하는 것이 성장 그 자체가 된다. 하지만 SI 업체는 개발자의 무덤이라는 자조적인 소리를 한다. 소위 말하는 네카라쿠배와 같은 곳에 가면 자신이 더 성장할 수 있다고 생각한다. 물론 환경은 중요하다. 그럴 수밖에 없는 환경이면 당연히 그런 방향으로 성장할 수 있다. 하지만 궁금하다. 개발자의 성장이라는 것은 도대체 무엇일까? SI에서 하는 것도 개발인데 왜 그것은 마치 다른 세상의 개발처럼 대하는 걸까? 현재 직무에서도 최선을 다하지 못한다면 환경이 바뀐다고 해서 최선을 다할 수 있을까? 각자의 환경에서 배울 수 있는 종류가 다를 뿐이다. 개발 그 자체의 성장이 멈추는 것은 일정 부분 본인의 책임이다.

나도 그랬다. 제조업에서 개발을 할 때는 서비스업에서 사용하는 기술들을 거의 다루지 않아서 불안했다. 뒤처지는 기분이 들었다. 그런데 반대로 서비스업에서는 과연 제조업에서 다루는 기술을 다루는가? 각각의 포지션이 있을 뿐이다. 물경력 탓만 하고 있어서는 바뀌는 것이 없다.

작은 노력

본인의 환경에서 성장할 수 없다고 생각한다면 별도로 노력을 해야 한다. 그렇지 않고 환경만 탓한다면 그것은 본인이 열심히 하지 않을 좋은 핑곗거리 밖에 되지 않는다.

나도 대단한 노력을 한 것은 아니지만, 현재 상황에서 뭐라도 할 수 있는 것은 해봐야겠다는 생각을 했다. 업무에 사용하지 않는 기술을 공부해서 블로그에 글을 썼다. 간단한 앱을 만들어 배포해 보기도 했다. 실무에서 코틀린을 전혀 사용하지 않는 환경일 때 코틀린을 공부했고, 책을 썼다. 플러터가 지금처럼 위상이 대단하지 않을 시기에 플러터 책을 쓰고 강의도 했다. 당연히 코틀린이나 플러터를 사용하는 실무 환경이었다면 훨씬 빠르고 많은 것을 배울 수 있었을 것이다. 하지만 사용하지 않는다고 아무것도 하지 않으면 조금도 성장할 수가 없다.

나는 개발자에서 교육자로 전향했다. 그러한 경험에서 그동안 느껴보지 못한 성장을 했다고 생각한다. 그러면 교육자로 살아가는 것이 어떻게 개발자로서의 성장에 도움이 될까?

내적 동기 부여 찾기

나는 왜 개발자에서 교육자로 전향했을까?

자기결정성 이론에서는 인간의 동기 부여를 내적 동기와 외적 동기로 구분한다. 관련하여 에드워드 데시라는 사람이 외적 보상이 내적 동기에 미치는 영향에 대해 알아보기 위해 진행한 세 가지 실험이 있다. 요약하면 내적 동기에 의해 하던 일에 돈과 같은 외적 보상이 주어지면 순간의 동기 부여를 향상시킬 수 있다. 하지만 돈과 같은 외부 보상이 제거되면 이전보다 동기 부여가 떨어진다. 하지만 칭찬과 긍정적 피드백과 같은 외부 보상은 오히려 내적 동기 부여를 증가시킨다. 내가 교육에 대한 관심이 커진 것도 그러한 영향이 없지 않다.

나, 공유 좋아하네?

아... 아니요.

사람들은 남을 돕는 일에서 기쁨을 느낀다. 실제로 정신의학 용어에 '헬퍼스 하이(Helper's High)'란 말이 있다. 도움을 주는 사람들의 기분이 좋아지는 현상이라는 뜻이다.

나에게 있어 블로그를 통해서 지식을 공유하는 것이 그런 일이다. 처음에는 나중에 내가 볼 용도로 시작했다. 간혹 도움이 되었다는 댓글이 달리면 기분이 좋았다. 그것은 더 좋은 글을 쓰자는 강력한 동기 부여가 되었다.

그래서 의도적으로 개발자 커뮤니티에 공유하기도 했다. 글을 공유하는 것은 용기가 필요하다. 아무런 피드백을 받지 못해도 단순히 공유하는 것 자체가 루틴이 되었고, 그걸 충족시키는 것 자체가 동기 부여가 되었다. 이 상태는 외적 보상도 없는 상태다. 철저히 내적 동기에 의해서 움직인 것이다.

과거의 나를 돕는다는 생각

검색이나 책 등을 통해 얻는 정보들은 모두 앞서 그 길을 걸어간 누군가의 발자취다. 혹여라도 후발대가 따라온다면 좀 더 좋은 길로 안내하고자 하는 마음이 배어 있을 것이다. 그러한 행동을 하는 사람들은 대부분 내적 동기에 의해 움직일 가능성이 크다. 나는 내가 잘하는 사람이 아니라고 생각하기 때문에 비슷한 상황에 놓여있는 다른 사람이 과거의 나와 같은 고통을 겪지 않길 바라는 마음이 크다. 그래서 많은 시간을 들여 좀 더 쉽게 설명하려고 노력한다. 그리고 그러한 시간이 현재의 나에게도 많은 도움이 된다.

교육자가 하는 일

기존과 성격이 많이 다른 업무

교육자가 되고 얼마지 않아 알 수 없는 공허함을 느꼈다. 개발을 할 때는 이슈를 수정하거나 신규 기능을 개발하는 것과 같이 명확한 결과물이 있었다. 거기서 성취감을 느낄 수 있었다. 그런 환경에 있다가 교육이라는 카테고리에 들어오니 업무 성격이 굉장히 달라졌다. '업무'라는 것의 정의가 달라졌다. 개발자 시절에 업무는 자고로 기획서를 보고, 회의를 하고, 코딩하기였다. 그런데 지금은 당장 아웃풋이 나오지 않는, 그리고 정답도 없는 회의를 1시간 넘게 하고 있다. 코딩 테스트를 위해서 책상을 옮기고 멀티탭을 설치하고 있다. 내가 이러려고 교육자를 했나... 자괴감이... 들거나 그러진 않았지만 뭔가 이런 것도 하나의 업무가 맞고 내가 월급을 받아도 된다는 것을 받아들이는데 약간의 시간이 필요했다. 그래서 세상에는 정말 다양한 일이 존재하겠구나 싶은 생각을 새삼 다시 하였다.

그래서 교육자가 무슨 일을 하나? 그리고 그게 개발자의 성장과 무슨 상관인가? 추구하는 교육 방향에 따라 다르겠지만 현재 우리 조직에서 하는 것을 기준으로 주요한 내용만 정리해 보면 다음과 같다. 가급적 개발자의 성장이라는 관점에서 이야기할 것이라 어느 정도는 소속 조직과 무관함을 미리 알린다.

교육생/리뷰어 모집 및 선발

교육생을 선발하는 것이 약간 의아할 수도 있겠지만 많은 회사처럼 fit을 보는 것이라고 생각하면 될 것 같다. 그리고 우리 교육에서 중요하게 생각하는 것 중 하나가 리뷰 시스템이다. 따라서 리뷰어가 중요한 역할을 한다. 이러한 선발 과정이 개발자의 성장과 무관하다고 생각할 수 있다. 하지만 이것은 면접관의 경험과 유사한 면이 있다. 실제로 면접을 보지는 않지만 선발을 위해서 고려해야 하는 상황에 놓이면 평소에 생각하지 않았던 부분들에 대한 고민이 생긴다. 리뷰어를 선발한다면 리뷰를 잘하기 위해서는 어떤 역량이 필요하고 어떤 부분을 고려해야 하는지에 대한 고민을 하게 된다. 또한 기술적인 부분이 아니더라도 지원서를 읽으면서 어떤 글이 잘 읽히는지 배우게 된다. 이런 부분이 개발자의 성장과 무슨 상관인지 아직 모르겠다면 아마 기술적인 부분에 포커스가 맞춰진 성장을 추구하고 있지 않은지 반문해 봐도 좋겠다.

물론 기술적인 부분에 포커스가 맞춰진 것이 무조건 나쁜 것은 아니다.

커리큘럼 설계

본인이 뭔가 학습하려고 한다고 생각해 보자. 아마 어떤 것을 어떤 순서대로 학습할지 학습 목록을 작성하는 사람이 있을 것이다. 그리고 거기서 어려움을 느끼는 경우도 있을 것이다. 본인이 모르는 영역이기 때문에 무엇을 어떤 순서로 해야 하는지 감이 잡히지 않기 때문이다. 그래서 우리는 잘 짜인 커리큘럼의 도움을 받는다. 책이나 강의가 대표적인 예이다. 따라서 커리큘럼을 설계하는 것은 어떤 것을 학습할 때 어떤 식으로 진행하면 좋을 지에 대한 역량을 강화할 수 있는 일이다. 새로운 것이 아니라 자신의 전문 분야에 대한 커리큘럼을 만들어 보는 것도 좋다. 그러면 본인이 어떤 부분에 강하고 어떤 부분에 약한지 파악할 수 있다.

본인 학습과 다른 점은 책임감이 부여된다. 기술 트렌드를 파악한다. 효율적이고 효과적인 방법에 대해 고민한다.

강의

교육이라고 하면 가장 먼저 떠오르는 것이 아마 강의가 아닐까 싶다. 누군가를 가르치기 위해 하는 강의가 사실 자신을 가르치는 최고의 방법이다. 미국 행동과학연구소(NTL, National Training Laboratories)에서 제시한 것으로 알려진 학습 피라미드라는 것이 있다. 여기서 제시하는 가장 효과적인 학습 방법이 '가르치기'다.

학습 피라미드

강의라고 하니 거창하게 느껴질 수 있는데 본인이 학습한 것을 발표하거나 글로 적는 것도 가르치기의 일종이다. 누군가에게 설명하는 행위라고 보면 된다. 그냥 단순히 본인이 공부한 것을 요약하거나 나열하는 것은 가르치기가 아니다. 자신이 정확히 이해하고 남이 쉽게 이해할 수 있도록 많은 고민이 필요하다. 작은 스터디를 열어 본인이 강사가 되어 보는 경험도 좋은 방법이다.

교육자가 해야 하는 일

교육, 쉽지 않네

교육자가 하는 일과 해야 하는 일로 구분하는 것은 어렵다. 사실은 하는 일이자 해야 할 일이다. 굳이 나눠 본 이유는 해야 하는 일은 어쩌면 선택적인 부분일 수도 있지 않을까 싶어서이다. 또한 이 부분들이 교육이 쉽지 않다고 느껴지게 만드는 점이기도 하다.

관성에서 벗어나기

철저히 논리적인 프로그래밍에 암묵지가 존재한다는 것이 넌센스 같기도 하지만 그런 것들이 있다. 왜냐하면 경험을 통해서 자신도 모르게 축적되는 것이 있기 때문이다. 예를 들면 코드를 깊게 들여다보지 않았지만 쓱 봤을 때 어떤 문제점이 있을 것 같다고 예상되는 것과 같은 것이다. 그래서 당연하게 작성하는 코드도 초보자에겐 익숙하지 않을 수 있다. 그러면 초보자 입장에서는 왜?라는 의문이 계속 든다. 초보자를 대상으로 교육을 한다면 그런 것을 놓치지 않고 의식적으로 잘 챙겨야 한다.

안드로이드 스튜디오 패키지 구조, 왜 java가 기본일까?

또한 유심히 살펴보지 않고 그냥 쓰던 부분들에 대해서 막상 질문받으면 자세히 모르거나 설명하기 어려운 것들이 있다. 모든 것이 궁금한 초보자의 눈에서 바라보면 평소 미처 신경 쓰지 못했던 부분에 대해서도 공부하게 된다.

난이도 조절

경력이 쌓이면 개구리 올챙이 적 생각 못한다고 초보자의 마음을 모를 수도 있다. 관성과 마찬가지로 '그건 그냥 이렇게 하면 되는 쉬운 일인데'라고 생각할지도 모른다. 하지만 초보자에겐 어려울 수 있다. 그래서 어떤 내용을 설명할 때 난이도 설정이 중요하다. 또한 교육생의 수준도 모두 다르다. 그래서 어느 수준에 맞춰야 할까에 대한 결정도 중요하다.

위의 상황을 고려하면 이걸 지금 알아야 할까? 이건 어디까지 알아야 할까? 이런 고민들이 생긴다. 이 고민들이 자신을 향하게 되면 어떻게 될까? 본인의 학습 범위와 깊이를 설정하는데 도움이 된다.

개인 역량 강화

한 사람이 모든 것을 알 수 없다. 안드로이드 프레임워크만 해도 정말 많은 내용들이 있다. 실제 개발자들도 모든 내용을 알고 개발을 하진 않는다. 하지만 교육자는 아는 것만 가르칠 수 없다. 그리고 새로운 기술은 계속 등장한다. 개발자도 평생 공부해야 하는 직업이라고 하는데, 개발자를 양성하는 교육자는 더 말할 것도 없다. 그러니 교육자가 되면 개발자로서의 역량도 자연스럽게 향상될 수밖에 없다. 물론 현장에서 학습하는 것과는 약간 결이 다를 수는 있지만 근본적인 내용은 어디서나 통한다.

효과적인 학습법

어떻게 공부할 것인가

효과적인 학습법은 '어떻게 공부할 것인가'라는 책에서 잘 설명하고 있다. 회사에서 학습에 대한 학습을 진행하면서 읽은 책인데 많은 도움이 되었다.

모든 내용을 이야기할 수는 없고 몇 가지만 정리하면 다음과 같다.

수업 설계가 학습과 깊은 관련

배우기 어려울수록 오래 기억

A, B, C, D단계로 나눠 암기하고 연습

간단한 시험을 통한 훈련

연습에 변화 주기

위 외에도 여러 가지 상황들이 있는데 결국은 '인출, 정교화, 생성, 반추'라는 용어로 정리할 수 있다. 인출은 공부했던 내용을 다시 기억해 내는 과정이다. 이런 인출 연습을 할 수 있는 쉬운 방법이 시험이다. 시험이라고 하면 부정적으로 생각할 수도 있는데, 평가로써의 시험이 아니라 학습으로써의 시험으로 봐야 한다. 어떤 내용을 읽고 추후에 적어 보는 것도 (셀프) 시험이다. 이 과정을 통해 학습한 내용이 장기 기억으로 이어진다. 정교화는 학습한 내용을 기존에 알고 있던 지식들과 연관 짓는 작업이다. 생성은 시험 문제를 풀 때 정보나 해답을 제공받는 대신 기존의 지식들을 활용해서 문제를 풀려고 애쓰는 과정이다. 마지막으로 반추는 앞선 내용들의 종합이다. 학습한 내용을 다시 글로 써보는 과정을 떠올리면 된다.

백문불여일타

시도를 하지 않는 것보다는 문제를 풀려고 시도하고 오답을 내놓는 편이 낫다.

개발 공부를 어떻게 하면 좋냐는 질문에 일단 뭐라도 만들어 보라는 조언을 쉽게 들을 수 있다. 과거의 나는 이 말에 동의하지 않았다. 아니 반만 동의했고 여전히 반만 동의한다. 아무것도 모르는데 도대체 어떻게 뭘 만들라는 것인가? 그래서 필요한 기본 지식을 쌓고 시작해야 한다고 생각했다.

하지만 우리가 학창 시절 운동장에서 축구를 할 때 그것을 위해서 축구 관련 책부터 읽지는 않는다. 일단 축구를 시작한다. 그렇다고 해서 무작정 공만 찰 수는 없다. 손으로 공을 만져서는 안 되며 어떤 포지션이 어떤 역할을 하는지 등에 대한 기본적인 지식이 필요하다. 이것은 책으로 배울 수 있는 부분이다.

그러나 그게 전부가 아니다. 축구를 좀 더 잘하기 위해서는 공을 컨트롤하는 방법을 배우는 활동이 반드시 병행되어야 한다. 공을 다루는 방법을 습득하는 것은 직접 뛰며 체감하는 것이 효과적이다. 이 부분은 책으로 완전하게 배울 수 없다. 하지만 이 조차도 이론적인 것을 미리 숙지한다면 좀 더 효과적인 학습이 가능하다.

개발 공부도 비슷한 부분이 있다. 무엇을 만들지 정했다면 그것을 구현하기 위해서 필요한 부분만 찾아서 적용하는 것이다. 그러다 보면 기초가 부족해서 모르는 것이 꼬리에 꼬리를 무는 경우가 있을 것이다. 그러한 부분은 일단 넘어가고 동작하게만 구현하는 연습이 무작정 공차기와 비슷하다. 좀 더 좋은 코드를 작성하기 위해 필요한 기술을 공부하는 것이 공을 컨트롤하는 방법을 배우는 것이다.

기초 지식 쌓기와 일단 만들어 보기는 각각의 장단점이 있다. 배울 수 있는 것의 결이 다르다. 각 방법마다 좀 더 효과적인 영역이 있다. 결국 잘하기 위해서는 둘 다 병행해야 한다.

하지만 분명한 것은 일단 해보기는 효과적인 학습 방법이라는 것이다. 그것은 지식이 얕은 상태든 지식을 쌓은 후든 반드시 해보기 과정이 필요하다는 의미다.

도전적인 학습 범위

많은 학습자들이 실수를 실패로 받아들이며, 실수를 피하기 위해 감당할 수 있는 것만 하려고 하는 풍조가 형성되었다.

학습하는 과정에서 실수는 종종 있다. 예를 들어 세미콜론을 빠뜨려 빌드가 실패했다면 그것이 본인의 실패는 아니다. 실수일 뿐이다. 거기서 좌절하고 재능을 운운하며 학습을 멈출 필요가 없다.

실수라고 인정해도 실수를 피하기 위해서 감당할 수 있는 것만 하려는 것도 좋은 태도는 아니다. 대신에 실수를 바로 잡아주는 피드백을 받아야 한다. 이러한 방식이 수동적인 학습 전략에 비해 학습과 정확한 정보를 보유하는 데 유리하다. 피드백과 관련하여 개발 세계에서는 아주 좋은 문화가 있다. 바로 코드 리뷰다. 코드 리뷰를 학습 도구로 적극 활용하자.

어렵다고 생각하는 부분도 도전해서 구현해 보고 피드백을 받아 결국 알게 되는 과정이 중요하다. 계속 회피한다고 해서 해결될 문제가 아니기 때문이다. 여기서 중요한 것은 바람직한 어려움을 설정하는 것이다. 너무 어려운 문제에 도전해서 좌절만 하면 그건 바람직하지 않은 어려움이다. 난이도 설정을 다시 해야 한다.

지식 인출

지식 인출은 앞서 말한 인출을 의미한다. 학습한 내용을 기억해 내는 과정이다. 기억하는 것보다 기억을 인출하는 것이 중요하다. 그렇게 머릿속에서 기억을 찾아낼 때 그 기억이 장기 기억으로 발전하기 때문이다. 이런 측면에서 프로젝트를 일단 해보기는 인출할 지식 자체가 없는 상태다. 그래서 지식 쌓기가 병행되어야 한다. 지식을 쌓으면 또 인출을 해야 한다. 가장 효과가 큰 인출 연습은 나중에 그 지식을 가지고 진짜 하게 될 일을 반영하는 연습이다. 인출의 수단으로 프로젝트를 하는 것이 아주 좋은 것이다. 따라서 이 두 가지가 반복되어야 한다.

인출을 위한 시험과 그 효과

인출의 효과는 앞서 말했듯 장기 기억이다. 실제로 시험(=프로젝트)을 통해 인출을 수행한 팀과 학습만 진행항 팀의 장기 기억은 큰 차이가 있다.

지식 인출을 어렵게 하기

시간 간격을 두거나 교차하여 연습함으로써 기억을 약간 흐려지게 하면, 인출이 힘들어지고 솜씨를 그다지 능숙하게 발휘하지 못하며 실망스러운 기분이 들 수는 있어도 한 층 깊이 학습하게 되고 나중에 그 지식을 더 수월하게 인출할 수 있을 것이다.

인출할 때 더 많은 노력이 필요하면 더 잘 배울 수 있다. 인출은 사실상 재학습의 과정이기 때문이다. 더 많은 노력이 필요하도록 할 수 있는 장치가 시간 간격을 두기, 교차하여 연습이다. 이렇게 하면 당장 학습 위주로 좋은 결과를 내는 다른 사람과 비교된다. 그러면 자신을 의심하게 되고 인출 연습보다 단순 학습에 눈이 갈 수도 있다. 그러나 그 결과는 앞서 실험 결과를 보여주는 그래프로 알 수 있다. 학교 선생님들이나 교수님들이 종종 계단식 성장에 대해 이야기한다. 바로 이렇게 어려운 방식의 공부를 통해서 성장한 결과가 계단식 성장이다.

실제 교육 방식

앞선 내용들은 아래 교육 방식에 잘 녹아 있다. 모든 것을 자세히 설명하기엔 양이 많아서 몇 가지만 간단히 살펴보겠다. 도전적인 학습과 바람직한 어려움을 위해서 상세히 가르쳐 주기보다는 중요한 개념에 대해 설명하고 추가 학습을 위한 키워드를 알려준다. 그래서 우리 조직에서는 교육자를 코치라고 부른다. 또한 학습한 내용을 인출하고 답을 생성하기 위한 미션들이 있다. 이러한 미션은 난도가 있기 때문에 도전적인 과제다. 바람직한 어려움을 주기 위해 노력했고, 실수를 바로 잡기 위한 피드백인 코드 리뷰가 존재한다. 리뷰 역시 정답을 알려주기보단 문제점에 대해 인지시켜 주고 스스로 생각하여 답을 찾아가도록 유도한다. 이러한 과정은 실제 현업에서 있는 일이다. 나중에 진짜 할 일을 통한 인출 연습이 된다. 인터뷰 역시 평가를 위한 것이 아니라 셀프 시험과 같은 효과를 위한 장치다. 그 순간 기억을 인출하기 위해 많은 노력이 동반되기 때문이다. 추가적으로 메타인지가 되기도 한다.

티칭보다는 코칭을

미션 기반 야생 학습

토론 문화: 집단지성의 힘

인터뷰

쓰고, 말하고

페어 프로그래밍

코드 리뷰

회고

팀 프로젝트: 협업

결론

셀프 교육자가 되어보자.

지금까지의 내용을 자신에게 적용해 보자. 효과적으로 가르치는 방법은 효과적으로 학습하는 방법이다. 자신을 가르친다는 생각으로 전략을 짜고 그대로 자신이 학습을 하면 그것이 곧 성장을 이끌 것이다.

학습을 위한 자료와 방법은 정말 많은 시대이다. 특히 AI 등장은 학습에도 엄청난 도움이 된다. 따라서 지금까지는 학습하는 방법에 대한 고민을 했다면, 앞으로는 무엇을 위한 학습을 할 것인가에 대한 고민이 필요하다.