자라기
- 당신은 몇 년 차?
- 자기계발은 복리로 돌아온다
- 학습 프레임과 실행 프레임
- 달인이 되는 비결
- 의도적 수련
- 실수는 예방이 아니라 관리
- 뛰어난 선생에 대한 미신
- 나홀로 전문가에 대한 미신
학교에서 배우는 학습이 아니라, 현실 세계에서의 야생 학습을 다루는 장이야. 야생 학습은 순서도 없고, 정답도 없고, 목표도 유동적이고, 혼자가 아니라 협력적으로 이루어지지.
개발자들 사이에서 흔히 "경력 몇 년 차"를 물어보잖아. 그런데 연구 결과를 보면 좀 충격적이야. 경력 10년인 개발자가 2년 차보다 반드시 잘하는 게 아니거든. 실제 연구에서 경력과 실제 생산성 사이에 상관관계가 거의 없었다고 해.
왜 그럴까? 단순히 시간을 많이 쓴다고 실력이 느는 게 아니기 때문이야. 매일 출근해서 비슷한 일을 반복하는 건 성장이 아니라 그냥 익숙해지는 것일 뿐이지. 1년의 경험을 10번 반복한 건 10년의 경험이 아니라는 얘기야.
그래서 경력 연차보다 그 시간 동안 뭘 했느냐가 중요해. 같은 5년이라도 매번 새로운 도전을 하면서 피드백을 받은 사람과, 편한 일만 반복한 사람의 실력 차이는 어마어마하거든.
자기계발은 복리처럼 작동해. 은행 이자처럼, 처음에는 티가 안 나지만 시간이 지나면 기하급수적으로 불어나지. 핵심은 이전 단계에서 배운 것이 다음 단계의 학습을 더 빠르게 만든다는 거야. A라는 기술을 배우면서 익힌 학습 방법이 B를 배울 때도 도움이 되고, A+B를 알고 있으니 C를 이해하는 건 훨씬 쉬워지는 식이지.
꾸준히, 매일 조금씩이 핵심이야. 하루에 1%씩만 성장해도 1년이면 37배가 돼. 물론 현실에서 매일 정확히 1%씩 자라는 건 불가능하지만, 요점은 작은 개선을 꾸준히 쌓아가는 게 장기적으로 엄청난 차이를 만든다는 거야.
같은 일을 할 때도 두 가지 프레임이 있어. 실행 프레임은 "잘해야 해, 실수하면 안 돼"라는 마음가짐이야. 성과를 증명해야 하니까 이미 아는 방법만 쓰고, 도전을 피하게 되지. 학습 프레임은 "이번에 뭘 배울 수 있을까?"라는 마음가짐이야. 실패해도 괜찮고, 오히려 실패에서 배울 게 있다고 생각하는 거지.
재밌는 건, 학습 프레임으로 접근한 사람이 결과적으로 실행 프레임으로 접근한 사람보다 성과도 더 좋았다는 연구 결과가 있다는 거야. 잘하려고 안간힘 쓴 사람보다, 배우려고 한 사람이 더 잘했다니 아이러니하지 않아? 특히 새로운 프로젝트나 낯선 기술을 만났을 때, "이거 잘 해내야 하는데..." 대신 "이거 하면서 뭘 배울 수 있지?"로 프레임을 바꿔보는 거야.
달인이 되려면 두 가지가 필요해. 첫째, 실력을 개선하려는 동기가 있어야 해. 당연한 것 같지만, 의외로 많은 사람이 현재 수준에서 안주하거든. "이 정도면 됐지" 하는 순간 성장이 멈추지. 둘째, 구체적인 피드백을 적절한 시기에 받아야 해. 내가 뭘 잘하고 뭘 못하는지 빠르게 알 수 있어야 한다는 거야. 코딩으로 치면, 코드 짜고 6개월 뒤에 버그를 발견하는 것보다 테스트를 바로 돌려서 확인하는 게 학습 효과가 훨씬 크잖아.
그리고 달인이 되기 쉬운 분야와 어려운 분야가 있어. 피드백이 빠르고, 반복 연습이 가능하고, 규칙이 명확한 분야(체스, 음악 등)에서는 달인이 나오기 쉽지. 반면 피드백이 느리고 불확실한 분야(장기 투자, 정치 등)에서는 경력이 아무리 길어도 달인이 나오기 어려워.
안데쉬 에릭손의 의도적 수련(Deliberate Practice) 개념도 중요해. 흔히 알려진 "1만 시간 법칙"의 원작자인데, 대부분이 이걸 잘못 이해하고 있거든. 1만 시간을 그냥 쏟는 게 아니야. 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련을 1만 시간 해야 한다는 거지. 매일 편한 코드만 짜면서 10년 일한 건 의도적 수련이 아니야.
의도적 수련의 핵심 조건은 이래:
- 현재 실력보다 약간 어려운 과제에 도전한다
- 즉각적인 피드백을 받는다
- 같은 작업을 반복하면서 교정한다
개발자로 치면, 항상 같은 CRUD만 만드는 게 아니라 조금 어려운 알고리즘을 풀어보거나, 코드 리뷰를 적극적으로 받거나, 새로운 아키텍처 패턴을 적용해보는 것이 의도적 수련에 해당하지.
실수에 대한 이야기도 와닿아. 보통 조직에서는 "실수를 하지 마라"고 하잖아. 프로세스를 촘촘하게 만들고, 체크리스트를 늘리고, 승인 절차를 추가하지. 하지만 실수는 어차피 일어나. 문제는 실수 자체가 아니라 실수를 어떻게 다루느냐야. 실수를 예방하려고만 하면 사람들이 도전을 안 하게 되고, 실수를 숨기게 돼. 그러면 작은 실수가 발견 안 되고 쌓이다가 나중에 큰 사고로 터지지.
반면 실수를 관리하는 문화에서는 실수가 빨리 드러나고, 빨리 고쳐지고, 그 경험이 학습으로 전환돼. 테스트 코드를 짜는 것, 코드 리뷰를 하는 것, 장애 포스트모템을 하는 것 — 이런 게 전부 실수를 관리하는 장치들이야.
우리는 보통 "좋은 선생님만 만나면 잘 배울 수 있을 텐데"라고 생각하잖아. 그런데 이게 미신이야. 연구를 보면, 뛰어난 선생의 유무보다 학습자 자신의 학습 전략과 메타인지가 훨씬 중요했거든. 자기가 뭘 모르는지 아는 사람, 학습 방법 자체를 개선하는 사람이 어떤 환경에서든 잘 배웠어. 물론 좋은 선생이 도움이 안 된다는 게 아니야. 하지만 선생에게 의존하는 것보다 스스로 학습하는 능력을 키우는 게 더 근본적인 해결책이라는 이야기지. 결국 현실에서는 항상 좋은 선생이 옆에 있는 게 아니니까.
마지막으로 "혼자서 전문가가 될 수 있다"는 미신도 깨야 해. 어떤 기술적 실천법이라도 현실에서 적용하려면 사회적 자본과 기술이 필요하거든. 아무리 뛰어난 기술을 알고 있어도 팀원들을 설득하지 못하면 못 쓰잖아. 아무리 좋은 아키텍처를 설계해도 혼자서는 구현 못 하고. 결국 진짜 전문가는 혼자 방에서 탄생하는 게 아니라, 다른 사람들과 상호작용하면서 자라는 거야.
정리
1장 읽고 기억할 거 세 가지:
- 경력 연차는 실력의 지표가 아니야. 시간이 아니라 그 시간 동안 뭘 했느냐가 중요하지
- 의도적 수련이 핵심이야. 편한 걸 반복하는 건 연습이 아니거든. 약간 어려운 것에 도전하고, 피드백을 빠르게 받아야 해
- 혼자서는 한계가 있어. 기술적 성장도 결국 사회적 맥락 안에서 일어나는 거야