새 기술을 배울 때 순서 — 튜토리얼을 끝까지 따라 해도 남지 않는 이유
따라 하기는 이해와 다르다. 무엇을 만들지 먼저 정하고 필요한 것만 배우는 방식.
따라 했는데 남지 않는 이유
튜토리얼을 끝까지 따라 하고 나서도 혼자 만들려면 막히는 경험은 흔하다. 원인은 능력이 아니라 학습 과정에서 판단을 하지 않았기 때문이다.
튜토리얼은 이미 정해진 답을 순서대로 보여준다. 따라 하는 동안 "왜 이걸 여기서 쓰지?", "다른 방법은 없나?" 같은 판단이 발생하지 않는다. 그래서 절차는 남지만 판단 능력은 안 남는다.
순서를 뒤집기
효율적인 순서는 다음과 같다.
```
만들 것을 정한다 → 막힌다 → 필요한 것만 찾아 배운다 → 다시 만든다
```
이 방식의 장점은 배운 것마다 쓰인 자리가 있다는 것이다. 자리가 있으면 기억에 남고, 없으면 사라진다.
무엇을 만들 것인가
학습용 프로젝트의 조건:
- 작다 — 1~2주 안에 동작하는 형태까지
- 자기가 쓴다 — 요구사항이 명확해진다
- 그 기술을 실제로 필요로 한다 — 억지로 끼워 넣으면 배움이 안 된다
마지막 조건이 자주 빠진다. 상태 관리 라이브러리를 배우겠다며 상태가 두 개뿐인 앱을 만들면, 그 라이브러리가 왜 필요한지 끝내 알 수 없다.
최소한의 선행 학습
아무것도 모르는 상태에서 만들기 시작하면 검색조차 안 된다. 최소한 다음은 먼저 훑는다.
- 공식 문서의 시작 가이드 — 전체가 아니라 첫 페이지들
- 핵심 개념 이름 — 무엇을 검색해야 할지 알기 위해
- 간단한 예제 하나 — 동작하는 형태를 한 번 본다
여기까지가 대개 1~3시간이다. 그 이상은 만들면서 배우는 편이 빠르다.
막혔을 때의 순서
- 에러 메시지를 그대로 읽는다 — 상당수는 답이 메시지에 있다
- 공식 문서에서 해당 부분 — 블로그보다 정확하고 최신이다
- 이슈 트래커 검색 — 같은 문제가 이미 보고돼 있는 경우가 많다
- 최소 재현 코드를 만든다 — 만드는 과정에서 원인이 드러나는 경우가 흔하다
- 그다음에 질문
4번을 건너뛰고 질문하면 답하는 쪽도 원인을 찾기 어렵다.
동시에 몇 개까지
새 기술 두 개를 함께 배우면, 문제가 생겼을 때 어느 쪽 문제인지 판단이 안 된다. 디버깅 비용이 급증한다.
하나가 손에 익은 뒤 다음으로 넘어가는 편이 결과적으로 빠르다. "손에 익었다"의 기준은 문서 없이 기본 구조를 쓸 수 있다 정도면 충분하다.
기록해두면 좋은 것
배우면서 남기는 기록은 나중에 자신에게 가장 유용하다.
- 막혔던 지점과 해결 방법 (같은 문제가 반복된다)
- 처음에 잘못 이해했던 개념 (오해가 재발한다)
- 선택했던 대안과 이유
블로그로 공개하지 않아도 된다. 검색 가능한 형태로 자기 저장소에 있으면 충분하다.
최종 수정 2026-08-28