개발자가 새로운 언어·프레임워크를
익히는 현실적인 방법
강의 10개 보고 못 쓰던 것들, 이렇게 했더니 2주 만에 실무에 썼다
나는 강의를 10개 봤는데 아무것도 못 썼다
React를 처음 배울 때 Udemy 강의를 세 개 샀다. 유튜브 무료 강의까지 포함하면 아마 열 개가 넘었다. 다 보진 않았다. 절반쯤 보고 다음 강의로 갔다. "이 강의가 더 좋다더라"는 말을 들으면 새 강의를 샀다. 3개월이 지나도 실제로 뭔가를 만들지 못했다.
지금 돌아보면 그 3개월의 문제가 뭔지 명확하다. 보는 것과 쓰는 것을 착각했다. 강의를 이해하면 쓸 수 있다고 생각했는데, 이해와 사용 사이에는 생각보다 큰 간격이 있었다. 그 간격을 메우는 방법을 찾는 데 또 3개월이 걸렸다.

안 됐던 방법들 — 솔직하게
강의를 처음부터 끝까지 다 보고 코딩 시작하기
공식 문서를 앞에서부터 전부 읽기
Todo 앱 튜토리얼 따라 만들기만 반복
"좋다는 강의" 모아서 나중에 보기
배속 2배로 강의 몰아서 하루에 10시간 보기
개요 파악 후 바로 내 프로젝트에 적용
필요한 것만 공식 문서에서 찾아 읽기
실제로 쓸 기능을 처음부터 만들기
막히는 것만 찾아보고 바로 적용
매일 30분씩 꾸준히, 결과물 남기기
강의를 다 보고 코딩을 시작하면 앞에서 본 내용을 이미 잊는다. 강의는 이해를 위한 도구이지 실력을 만드는 도구가 아니다. 강의를 보는 시간보다 코딩하는 시간이 반드시 더 많아야 한다.
실제로 새 스택을 익힌 경험 — 케이스별
Pages Router는 알고 있었는데 App Router는 처음이었다. 공식 문서를 처음부터 읽으려다 포기했다. 너무 많았다. 대신 Next.js 공식 문서의 "App Router" 섹션에서 가장 핵심 개념 세 가지만 골랐다. Server Components, Client Components 구분, data fetching 방식. 이것만 파악하고 바로 마이그레이션을 시작했다.
막히면 그때 문서를 찾아봤다. "layout.tsx 어떻게 써요?" → 문서 확인. "서버 컴포넌트에서 fetch 어떻게 해요?" → 문서 확인. 이런 식으로 필요한 것만 그때그때 채웠다. 2주 후에 마이그레이션이 완성됐다. 그때 App Router를 이해한 수준이 강의 다섯 개 보는 것보다 훨씬 깊었다.
Supabase 강의를 찾아봤는데 한국어 강의가 거의 없었다. 어쩔 수 없이 공식 문서를 봤다. 그런데 공식 문서가 생각보다 친절했다. Quickstart가 있었고, 거기서 5분 만에 기본 세팅이 됐다. 이메일 인증이 바로 작동했다.
"아, 그냥 따라 하면 되는 거구나"라는 걸 그때 알았다. 강의가 없어서 공식 문서를 보게 된 게 오히려 더 좋은 방법이었다. 막히는 부분은 Supabase Discord에서 찾았다. 실제 사용자들의 Q&A가 강의보다 현실적인 문제를 다루고 있었다.
Zustand는 진짜 쉬웠다. GitHub README가 전부였다. README를 읽는 데 20분, 실제로 쓰는 데 1시간. Redux 배울 때 보일러플레이트에 지쳐서 Zustand로 갔는데, 처음엔 "이게 맞나?" 싶을 정도로 간단했다.
그런데 그 간단함이 오히려 배움이었다. "왜 이게 작동하는 거지?"를 이해하려고 내부를 살펴봤다. 그 과정에서 상태 관리 패턴에 대한 이해가 Redux보다 더 깊어졌다. 가벼운 도구를 제대로 이해하는 게 복잡한 도구를 대충 아는 것보다 낫다는 걸 그때 알았다.
Turborepo를 팀에 도입하자고 제안했다. 개념은 이해했다. 모노레포, 캐싱, 워크스페이스. 근데 실제 회사 레포에 적용하려고 하니 막혔다. 예제 프로젝트가 아닌 기존 레포에 적용하는 게 완전히 다른 문제였다.
그때의 실수: 예제 프로젝트로만 연습했다. 실제 우리 레포와 비슷한 구조로 로컬에서 먼저 해봤어야 했다. 결국 팀에 적용하는 데 예상보다 두 배의 시간이 걸렸고, 중간에 기존 빌드가 깨지는 이슈도 있었다. 제안할 때는 먼저 비슷한 환경에서 직접 해보고 나서 해야 한다는 걸 배웠다.
내가 쓰는 학습 단계 — 현재 버전
여러 번의 시행착오 끝에 지금은 이 순서로 새 기술을 배운다. 완벽한 방법은 아니지만, 내가 경험한 것 중에서 가장 빠르게 실무에 쓸 수 있게 된 방법이다.
공식 문서 첫 페이지, 또는 공식 튜토리얼 하나만 본다. "왜 이걸 쓰는지", "어떤 문제를 푸는지", "기존 것과 뭐가 다른지"만 파악한다. 세부 API는 보지 않는다.
공식 Quickstart를 따라서 아주 작은 것 하나를 만든다. 작동하는 것을 눈으로 보는 게 목표다. 완성도는 중요하지 않다. "작동했다"는 경험이 다음 단계를 만든다.
내가 실제로 필요한 기능을 만든다. 막히면 그때 문서나 Stack Overflow를 찾는다. 미리 다 공부하고 시작하지 않는다. 문제가 생길 때 찾는 게 훨씬 기억에 남는다.
어느 정도 쓸 수 있게 되면 그때 "왜 이렇게 작동하지?"를 파고든다. 소스 코드, 공식 문서 심화, 커뮤니티 이슈. 이 단계가 표면적 사용과 진짜 이해를 나눈다.
새 기술을 배우는 가장 빠른 방법은 실제로 쓰는 것이다. 완벽하게 이해하고 시작하려고 기다리면 시작을 못 한다. 모르는 채로 시작하고, 막히는 것을 그때그때 배우는 게 결국 빠르다.
막혔을 때 찾는 순서
# 에러 또는 막힌 개념 발생 시
[1순위] 공식 문서 → 가장 정확, 버전 맞는 것 확인 필수
[2순위] GitHub Issues → 같은 문제 겪은 사람 있는지, 버전 이슈인지 확인
[3순위] Stack Overflow → 일반적인 패턴은 여기. 날짜 확인 (구버전 답변 주의)
[4순위] 공식 Discord / Slack → 최신 이슈, 메인테이너 직접 답변 가능
[5순위] AI (Claude, Copilot) → 빠른 힌트. 하지만 반드시 검증 필요
─────────────────────────────────────────
[주의]
- 블로그 글은 날짜 먼저 확인. 1년 전 글이면 버전 달라졌을 수 있음
- AI가 준 코드는 "그럴듯해 보이는 코드"일 수 있음. 테스트 필수
- 30분 이상 혼자 막히면 그냥 물어보는 게 맞음 (시간이 더 중요)
이미 아는 것을 연결하는 게 핵심이다
TypeScript를 처음 배울 때 낯설었다. 그런데 "JavaScript에 타입을 추가한 것"이라고 생각하니까 갑자기 쉬워졌다. 내가 이미 JavaScript를 알고 있었고, TypeScript는 거기에 레이어를 얹은 것이었다. 연결점을 찾는 순간 학습 속도가 달라졌다.
Svelte를 공부할 때도 비슷했다. "React인데 가상 DOM 없는 버전"으로 이해하니까 진입이 빨랐다. Svelte의 반응성 시스템이 React의 useState와 어떻게 다른지를 비교하면서 이해했다. 완전히 새로운 개념으로 접근하는 것보다 아는 것에서 다른 점을 찾아가는 게 훨씬 빠르다.
const newTechQuestions = {
// 1. 이게 뭘 대체하는가? replaces: "Zustand → Redux의 복잡함을 대체",
// 2. 내가 아는 것과 어떻게 다른가? diff: "Svelte vs React: 컴파일 타임 vs 런타임 반응성",
// 3. 언제 쓰는 게 맞는가? whenToUse: "Next.js → SEO 필요하거나 서버 사이드 로직 있을 때",
// 4. Hello World가 어떻게 생겼는가? quickStart: "공식 문서 첫 페이지. 무조건 따라 해봄",
// 5. 내 프로젝트에서 어디에 쓸 수 있는가? myUseCase: "Supabase → 지금 만드는 사이드 프로젝트 DB로"
}
// 이 질문들이 있으면 학습 방향이 생기고, 없으면 표류한다.
재직 중에 새 기술을 익히는 현실적인 방법
퇴근 후 2시간 공부하는 게 이상적이지만, 야근이 있거나 몸이 피곤하면 안 된다. 현실적으로 지속 가능한 방법을 찾는 게 더 중요하다.
점심 먹으면서 새 기술 관련 글 하나를 읽는다. 긴 강의가 아니라 짧은 글. "이런 게 있구나"를 쌓는 용도다. 실제로 쓸 수 있게 되는 건 나중이지만 개념 축적이 된다.
읽은 것을 손으로 치는 것이 이해를 완성한다. 보는 것과 치는 것 사이에 간격이 있다. 30분만 해도 이틀이면 작동하는 작은 예제가 생긴다. 예제가 생기면 동기부여가 된다.
평일에 익힌 것을 사이드 프로젝트에 실제로 쓴다. 여기서 진짜 막히는 게 뭔지 나온다. 예제에서 안 나오는 실제 문제들. 그걸 해결하는 과정에서 기술 이해가 깊어진다.
쓰는 것이 이해를 검증한다. "내가 이것을 남한테 설명할 수 있나"가 기준이다. 설명이 안 되면 덜 이해한 것이다. 정리 과정에서 몰랐던 구멍이 보인다.
실무에서 쓰는 게 학습의 완성이다. 코드 리뷰를 받으면 내가 놓친 부분이 나온다. 팀에 공유하면 더 잘 아는 사람한테 피드백을 받을 수 있다. 이게 가장 빠른 성장이다.
새 기술을 "완전히 마스터"하는 게 목표가 되면 시작이 어렵다. "이것으로 이 기능 하나를 만들 수 있다"로 목표를 낮추면 시작이 쉽다. 작은 성공이 다음 단계를 만든다. Zustand를 "마스터"하는 게 아니라 "장바구니 상태를 Zustand로 관리할 수 있다"가 목표다.
어떤 기술을 배울지 선택하는 기준
새 기술이 계속 나온다. 다 배우려고 하면 아무것도 깊게 못 배운다. 취준 때 이것저것 건드리다 아무것도 제대로 못 쓴 경험이 있었다. 이후로 필터 기준을 만들었다.
우선순위 1순위는 지금 일하는 데 바로 쓸 수 있는 것이다. 실무에서 당장 쓰면 가장 빠르게 익힌다. 2순위는 6개월 후 필요할 것 같은 것. 트렌드를 보되 유행에만 따라가지 않는다. 3순위는 재미있어서 하는 것. 이건 지속성이 있다. 단순히 "유망하다더라"만으로 시작한 것은 거의 다 흐지부지됐다.
3개월 동안 강의만 보면서 낭비했던 그 시간이 지금은 이렇게 정리가 된다. 보는 것과 쓰는 것은 다르다. 이해하는 것과 적용하는 것은 다르다. 아는 것과 설명할 수 있는 것은 다르다.
지금도 새 기술을 완벽하게 알고 시작하는 경우는 없다. 모르는 채로 시작하고, 막히면 찾고, 찾으면 쓰고, 쓰다 보면 알게 된다. 그게 내가 경험한 가장 현실적인 방법이다.
💬 새로운 기술을 익히는 본인만의 방법이 있으신가요?
강의, 공식 문서, 사이드 프로젝트 — 어떤 방식으로 새 스택을 익히는지, 효과 있었던 것과 없었던 것을 댓글로 나눠주세요. 지금 새 기술 공부 중인 분들에게 현실적인 힌트가 될 것 같습니다.
'개발자 > 성장 학습' 카테고리의 다른 글
| 컨퍼런스 처음 가봤을 때 달라진 시각 (0) | 2026.08.04 |
|---|---|
| 개발자 커뮤니티 활동으로 얻은 것들 (0) | 2026.07.28 |
| 알고리즘 공부, 실무에서 진짜 쓰이나? (0) | 2026.07.21 |
| 개발자가 영어 공부를 꼭 해야 하는 이유 (경험담) (0) | 2026.07.14 |
| 유료 강의 vs 무료 강의, 뭐가 더 도움됐나 (0) | 2026.07.07 |