개발자의 울트라러닝

column

지식을 얻는 9단계 초학습법 울트라러닝의 9가지 법칙을 개발자의 관점에서 바라보기

Table of Contents

울트라러닝의 9가지 법칙

이전에 읽었던 울트라러닝의 법칙을 기반으로 개발자는 어떻게 행동할 수 있을까?

다시 한번 개발자의 입장으로 정의해보고 싶어 책을 다시 한번 펼쳐보았다.

1. 메타학습: 먼저 지도를 그려라

어떻게 습득할지 조사한다.

메타는 그리스어에서 온 것으로 그 너머를 의미하며 학습에 관한 학습이라고 할 수 있다.

메타 학습은 자신만의 메타 학습 지도 그리기부터 시작한다.
때문에 3가지 질문을 통해 메타 학습 탐색을 하게 되면 학습 지도 그리기에 바탕이 된다.

  • 왜 그것을 배우려 하는가? (동기 파악)
  1. 또 다른 결과를 위해
  2. 결과보다는 나만의 목적을 위해
  • 무엇을 흭득해야 하는가? (공부하려는 지식을 구조화하기 위해 브레인스토밍)
  1. 개념: 암기가 아닌 이해해야하는 내용들
  2. 사실 정보: 외우면 그만인 것들
  3. 절차: 수행을 동반한 연습
  • 어떻게 학습할 것인가?
  1. 벤치마킹 (예: 커리큘럼, 추천 서적, 강의)
  2. 강조: 목표로 설정한 부분을 집중적으로 학습
  3. 제거: 목표에 부합하지 않는 부분을 미루거나 제외

1-1. 어떠한 기술을 공부해야 하는 이유 파악하기

  1. 취업 혹은 이직 같은 커리어 패스를 위해
  2. 개인의 이익이나 목적만을 위해 (Proof of Concept) 없이 회사의 서비스에 불필요한 기술 도입을 추진하는 경우
  3. 개발이나 코딩 자체가 즐거움

수 많은 학원들의 과장 광고와
Hype Driven Development라는 아티클이 이를 증명한다.
스스로 욕망을 감추지 않고 학습을 대하는 태도에 진심이 담겨 있거나 스스로 즐겁다면 배움에 이유는 중요치 않다.

하지만 학습에 전념하는 목적과 방향이 흐릿한데 그 이유가 다른 곳에 있다면 독학을 하면서도 길을 잃을 수 있다.
때문에 어떠한 기술을 왜 배워야 하는지 스스로 잘 정리해놓고 준비해야 한다.

1-2. 리소스 수집하기

  1. 관심 있는 위클리 구독
  2. 즐겨 찾는 아티클 정리 (Medium, DEV.to)
  3. SNS (Facebook, Slack, Reddit, Meetup, twitter, Youtube)

1-3. Proof of Concept (PoC)

직역하자면 개념증명이라고도 한다.
경력자의 경우 충분히 접해봤을 수 있는 용어인데 주로 신기술 도입 전 검증을 뜻한다.

개인적으로 무언가를 학습하기 전에 PoC (Proof of Concept) 과정을 거치는 게 큰 도움이 됐다.
한마디로 내가 이 기술을 꼭 학습해야 하는 이유가 무엇인지 셀프 검증하며 다시 한번 판단해볼 수 있다.
(뚜렷한 목적 없이 단지 불안함과 유행 등을 이유로 학습하는 경우도 있었다.)

1-4. 나만의 로드맵 그리기

목적이 정해졌다면 수집된 리소스를 통해 학습을 방법을 고민해 본다.
완벽함을 추구하기 위해 시간을 쏟지 말자 가장 중요한 것은 실천이다.

방향을 명확하게 가져가며 중간 중간 빠르게 수정하자

아무리 찾아도 로드맵을 그릴 수 없고 스스로 로드맵에 확신이 들지 않는다면 다양한 매체를 활용해보자

  1. 강의
  2. 독서
  3. 클론 코딩
  4. 멘토링
  5. 학원 및 교육 기관 커리큘럼

2. 집중하기: 짧은 시간에 집중도를 높여라

집중력을 기르고 공부할 수 있는 시간을 빼둔다.

  • 시작하지 못하고 미룬다
  1. 실천할 수 있는 정신적 습관 만들기
  2. 미루게 되는 대상이 싫은 이유 파악
  3. 시간을 쏟게 되는 다른 관심사가 좋은 이유 파악
  • 집중에 실패한다 (일정과 성격 그리고 작업 흐름을 고려해 최적의 방법을 찾기)
  1. 환경: 가장 잘할 수 있는 환경
  2. 과제: 집중이 잘 되는 과제 (예: 동영상, 문제풀이)
  3. 정신: 깨끗하고 차분한 마음을 장기적으로 강화
  • 집중에 좋은 최상의 상태 찾기
  1. 복잡한 업무: 다소 느슨한 집중 상태와 낮은 각성 상태
  2. 문제 풀이: 조용한 환경
  3. 단순한 일: 적절한 소음과 함께

2-1. 뽀모도로 혹은 타이머 활용하기

나를 감시하는 또 다른 잔소리꾼을 만드는 일이지만 이러한 간섭이 필요할 경우도 있다.
단 한계를 벗어나게 된다면 번아웃이 예상된다.

2-2. 루틴 만들기

어쩌면 습관 만들기라고 볼 수 있다.
루틴을 만들어 자연스럽게 집중이 되도록 환경을 만들어보자

예) 기상시 폰을 보지 않고 바로 일어나서 영단어 외우기

2-3. 집중이 잘 되는 TPO 파악하기

집중이 잘 되기 위한 시간 & 장소 & 상황을 만든다.
그전에 스스로 어느 시간 & 장소 & 상황에 집중이 잘되고 안되는지 파악하는 게 선행되어야 한다.

예) 카페에서 코딩하기, 새벽에 독서하기

3. 직접 하기: 목표를 향해 똑바로 나아가라

  • 잘하고 싶은 그 일을 해라
  1. 배우려는 기술과 가까운 환경과 상황 그리고 상태에서 학습하는 방식
  2. 직접 하는 것은 불편하고 지루하며 좌절감을 느낌 => 책, 강좌, 앱에 만족하게 된다 (실력 상승 기대)
  3. 가장 쉬운 방법은 많은 시간을 들이는 것이다.
  • 직접 학습 전략
  1. 프로젝트 기반 학습: 수많은 기술을 활용하여 프로젝트로 마무리
  2. 담금형 학습: 목표로 하는 기술을 해야하는 환경에 뛰어든다.
  3. 모의 비행 방식: 시뮬레이션
  4. 과다학습: 많은 도전을 하며 피드백을 받는다.

3-1. 회사에서 실천하기

회사에서 실천한다는 것은 정말 무모한 도전이다.
서비스와 비즈니스의 이해 관계 그리고 릴리즈까지 생각해보면 잘 하고 싶은 그 일을 회사에서 한다는 것은 이기적이다.

PoC를 통해 스스로 잘하고 싶은 그 일이 회사에 기여할 수 있는 측면이 가득한지 철저하게 의심해보자

실제로 개발자들에게 기술 스택이나 도메인 지식이 회사를 선택하는 동기로 작용하는 면도 있기때문에
회사에서 가고자 하는 방향과 내가 잘하고 싶은 그 일이 일치한다면 일석이조가 아닐까 생각이 든다.

3-2. 외주 진행하기

내가 하고 싶은 그 일을 직접 자유롭게 하고 싶다면 외주를 받아보는 것도 방법이다.
(하지만 납기일과 계약 조건 관계를 생각한다면 일반적인 회사 생활과 크게 다르지 않다)

3-3. 사이드 프로젝트 진행

개발자의 견습공의 패턴 중 부숴도 괜찮은 장난감만들기라는 이야기가 있다.
개인적인 시간을 사용해야 하며 별도의 금전적인 이득은 없지만 내가 직접 처음부터 끝까지 다 직접 해보자

요즘은 사이드 프로젝트를 위한 다양한 커뮤니티가 많다.

예) 디프만, DDD, 멋사(직장인), 비사이드, 넥스터즈, DnD 등

4. 특화 학습: 취약점을 공략하라

취약한 부분을 냉정하게 극복해나가라.

  • 특화 학습 전략
  1. 피드백 순환 고리 만들기
  2. 학습의 병목 구간은 하위 단계로 분리하고 잘할 때까지 학습
  3. 배운 것들을 통합하여 맥락 정리
  • 특화 학습 적용
  1. 시간 쪼개기: 짜투리 시간 활용
  2. 흉내내기: 시간 절약
  3. 돋보기 방식: 어떠한 한 가지 요소에 훨씬 많은 시간 쏟기
  4. 되돌아가기: 반복된 연습

4-1. 취약점 파악

손자병법 중 적을 알고 나를 알면 백번 싸워도 위태롭지 않다는 말이 있다.

하지만 취약점 파악이 마냥 쉽지는 않다.
이미 알고 있다고 착각하고 있기 때문이다.

누군가에게 내가 알고 있는 것을 설명하거나 가르칠 수 있는 기회가 있다면 그 착각이 깨진다.
면접, 스터디, 멘토링 등을 통해 나의 취약점을 파악하자 (무지가 드러나는 것을 두려워하지 말자)

스스로 메타 인지 강화에 꾸준하거나 피드백을 기반으로 성장해왔다면 이 부분은 이미 극복하고도 남았을 것이다.

4-2. 계층 지식 활용

지식의 계층을 만들고 무한하게 펼쳐보자
즉 나의 지식을 지도 혹은 트리 등으로 만들어 구축해보자 위키 형태도 좋다.

그렇게 구축하고 나면 부족한 점이 눈에 보이고 채워야 할 부분이 눈에 보이기 시작한다.

4-3. 피드백 받아보기

개발자 커뮤니티는 상당히 넓다.
또한 환경이 좋은 회사에 재직 중이라면 회사에서도 피드백을 받아볼 수 있다.

짧은 주기로 자주 피드백을 받아보자

4-4. 이론과 실습의 경계

책만 보는 사람, 클론 코딩만 하는 사람, 코드만 짜는 사람

내가 불편한 공부는 하고 싶지 않은 사람들이 생각보다 많다.
나 대신 공부해주며 경험을 쌓아놓은 매체들이 많기 때문이다.

불편하더라도 파악한 취약점을 토대로 불편한 공부도 해보자

5. 인출: 배운 것을 시험하라

자체적인 시험은 지식을 만드는 방식이며 정보를 적극적으로 기억하게 해준다.

  1. 수동적인 복습은 피드백을 받을 수 없다.
  2. 뽑아내는 고통을 겪어라
  3. 아직 배우지 못한 지식에 애쓰는 행위의 효과는 현실로 나타난다.
  • 인출 방법
  1. 낱말 카드: 질문과 답을 짝지어 학습
  2. 자유 회상: 기억나는 것을 모조리 회상
  3. 문제집 방식
  4. 도전 과제: 스스로 도전할 과제를 만든다.
  5. 클로즈 북: 머릿속부터 탐색

5-1. 알고리즘 풀기

개발자의 기본 소양 중 하나로 이만한 학습 수단이 없다.
알고리즘을 푸는 방법이나 학습 방법에 대한 이야기만해도 한 트럭 나오겠지만 더 이상의 설명이 필요하지 않다.

알고리즘 자체가 이미 인출의 대표적인 모범 사례이기 때문이다

5-2. 지원하기

회사나 다양한 교육 기관을 통해 시험을 치뤄본 경험은 개발자들에게 흔할 것이다.

알고리즘을 풀고 과제를 수행하고 면접을 본다.
또 면접 중에 손 코딩이나 자신이 해왔던 경험과 지식을 잘 정리해서 인출해야 한다.

시작부터 끝까지 인출의 연속이니 두말할 것도 없이 최고의 인출 방법이다.
향후 면접을 통해 나왔단 피드백을 정리한다면 취약점 분석과 복습에 큰 도움이 된다.

6. 피드백: 날아드는 조언을 피하지 마라

자존심은 버리고 피드백을 이용하라

  1. 피드백이 마냥 좋은 것은 아니다. 피드백의 유형이 중요하다.
  2. 장래의 학습에 지침이 될 유용한 정보를 제공
  3. 부정적인 피드백을 이겨낼 수 있도록 적응을 돕는다.
  • 피드백 유형 (최선의 피드백은 현재와 목표의 차이를 알려주고 더 잘할 수 있는 단계를 취하도록 돕는다.)
  1. 결과 피드백: 잘했다 or 잘못했다
  2. 정보 피드백: 잘하고 있다 or 잘못하고 있다
  3. 수정 피드백: 잘못하고 있는 것을 어떻게 고칠 수 있을까?

6-1. 면접 보기

면접을 보면서 파악해야 한다. 필히 면접관의 반응과 피드백을 유도한다.

면접관이 갸우뚱하거나 시원치 않은 반응을 보인다면 그것이 신호가 아닐까

6-2. 그룹 스터디

빨리 가려면 혼자 가고, 멀리 가려면 함께 가라.는 말이 있듯이 학습을 함께 해야 하는 경우가 생각보다 많으며 효과 또한 배가 될 수도 있다.

워낙 스터디의 방향이나 진행 방법이 다양하지만 피드백에 큰 도움이 될 수 있다.

  • 피드백에 도움이 되는 스터디
  1. 참여형 스터디
  2. 토론형 스터디
  3. 피드백이 강제되는 구조의 스터디
  4. 함께 코드를 구현하는 프로젝트형 스터디

6-3. 오픈 소스 기여

First Pull Request에서 첫 PR 기여가 있는지 검색해보자

아무런 검색 결과가 없다면 내가 오픈 소스에 전혀 관심이 없었구나 생각해보면 된다.
대규모 오픈 소스거나 유명 오픈 소스가 아니더라도 작게 시작해보자

실력에 자신이 없다면 문서화나 꼼꼼한 번역 활동으로 기여를 해볼 수도 있고
실력이 뛰어나거나 훌륭한 아이디어가 있다면 직접 만든 오픈 소스를 전세계에 공개해 반대로 PR을 받아보자

6-4. 배운 것을 공유하기

블로그, 컨퍼런스 발표, 멘토링, 오픈소스 등 다양한 활동으로 배운 것을 공유해보자

대부분 청자보다 배운 것을 공유하는 공유자가 더 배우게 된다.

7. 유지: 새는 양동이에 물을 채우지 마라

지금 당장이 아닌 평생 기억해야 할 것을 공부하라.

  • 뇌는 처음 배운 것부터 망각한다
  1. 쇠퇴: 시간이 흐르며 망각
  2. 간섭: 새로운 기억이 과거의 기억을 덮어쓴다.
  3. 망각: 인출되지 않는 기억
  • 기억 유지하기
  1. 공백: 기억하기 위해 반복
  2. 절차화: 절차화한 지식이 더 오래 저장된다.
  3. 초과 학습: 꾸준히 연습하고 제련
  4. 연상 기호: 기억의 연결 고리를 만든다

7-1. 기본에 충실하자

개발을 학문으로 바라봤을 때 그 양과 깊이는 정말 방대하다.
때문에 내재화하는 것도 어려운데 그것을 반복 학습하여 유지하는 것도 쉽지 않다.

변할 수 있는 기술인 프레임워크와 라이브러리에만 함몰되지 않도록 주의를 기울이자.
CS 기초 지식을 쌓는 것에 충실하며 사용 중인 기술들을 잘 사용하며 동작 원리나 철학에 깊은 관심을 갖으며 기반 지식을 쌓아보자

7-2. 리듬 유지하기

학습을 너무 타이트하게 가져간다면 번아웃에 빠질 수 있으며
이후 극복에 실패한다면 번아웃이 지속될 수 있다.

극한의 학습 스케줄을 유지하는 대단한 사람도 있지만 그렇지 못한 경우가 더 많다.
차라리 조금씩 꾸준히 유지하는 게 장기적으로는 더 좋다.

jQuery의 창시자인 존 레식 또한 매일 코드를 작성하기 위해 의식적인 커밋을 하고 있다.

예) 1일 1커밋

8. 직관: 뼈대를 세우기 전에 깊이 파라

개념과 기술을 탐구함으로써 직관을 길러라.

  • 직관 기르기
  1. 어려운 문제라고 쉽게 포기하지 마라
  2. 대상을 증명하는 방식으로 이해하라
  3. 늘 구체적인 사례를 가지고 시작하라
  4. 자신을 속이지 마라
  • 파인만 기법
  1. 전혀 이해하지 못할 때
  2. 문제를 해결하지 못할 때
  3. 직관을 확장할 때

8-1. Computer Science

문제를 해결 과정에 경험이 크게 필요할 할 수 있다.
하지만 절대적인 근간이 되는 CS을 뼈대로 잘 쌓아놓는 것은 경험만으로 가능한 범위가 아니다.

8-2. 의식적인 학습하기

동일한 경험과 학습을 하더라도 가지고 있는 직관은 사람마다 천차만별이다.
어떠한 대상에 대해 충분히 알지 못하고 추상적으로 이해한다면 알고 있다는 착각과 경험이 쌓이기 때문이다.

학습의 대상을 이해하는데 집요하게 파고들어 이해할 수 있도록 노력해야 한다.

예) 비유를 위한 사례, 시각화

8-3. 독서

학습에 도움이 되는 매체들이 점점 늘어나고 있다.
구글링이나 동영상 강의를 하거나 클론 코딩을 하며 인스턴트에 가까운 학습을 하게 되는 것이다.

때로는 학습 대상에 대해서 깊게 이해하기 위해 독서를 하는 것이다.
(요즘 훌륭한 아티클이나 튜토리얼이 많지만)
책에 쓰인 저자의 철학이나 관점이 주는 영감을 무시할 수 없다.

9. 실험: 자신의 안전지대 밖을 탐험하라

  • 상상하지 못한 가능성들을 탐색해야 한다.
  1. 따라 하고 창조하기
  2. 비교하기
  3. 새로운 제약 도입
  4. 관련 없는 기술 결합하기
  5. 극단을 탐험하라

9-1. 극한에 도전하기

성능 개선과 최적화 등에 도전하는 것이다.
혹은 새로운 기술을 도입해보는 방법도 있다.

직접하기에서 언급했듯이 이기적인 방향이 아닌 꼭 필요한 실험에 도전해보자

9-2. TDD

개발자에게 실험 정신은 중요하지만 이미 잘 돌아가는 코드를 뜯어고치는 것에는 큰 위험이 따른다.

마틴 파울러는 TDD 없는 리팩터링은 리팩터링이 아니라고 설명한다.
극한에 도전하기 위해서 안전장치가 필요하다는 것을 잊지 말자

9-3. 학생 계정 및 프리 티어 등 다양한 제도 활용하기

학습을 위해 돈이 드는 것은 무시할 수 없다.
회사 지원 혹은 학생 지원을 잘 확인해서 비용을 아끼도록 한다.

마치며

울트라러닝에서 제시하는 9가지의 학습 법칙을 개발자 입장에서 바라보고 정리해봤다.
MIT 컴퓨터 공학 과정을 독학하던 저자가 정리한 법칙이라 그런지 개발자에게 적용되는 법칙이 제법 많았고 개발자 버전으로는 9가지가 아닌 6~7가지로도 줄 일 수 있겠다는 생각이 들었다.

배움의 길에는 왕도가 없다는 말이 있듯이 수많은 개발자들에게 배움이 어렵게 느껴질 수 있다 보니 배움의 강박에 시달리며 스트레스 받는 개발자들을 흔하게 볼 수 있다.

울트라러닝에서 제시하는 9가지의 학습 법칙 자체가 정답은 아니지만 스스로 학습 방법을 계속 정리하고자 글을 작성하니 매우 도움이 되었다.
다음에는 작년에 큰 영감을 줬던 함께 자라기를 다시 한번 정독하고 나만의 학습 방법을 정리하고 루틴을 만들어보도록 해야겠다.

Share Comments