의도적 연습 — 경력만으로는 늘지 않는다

• 들어가며: 10년 차인데 왜 안 늘까
• 1. 경력이 곧 실력이 아니라는 불편한 사실
  • 10년의 함정
  • 자동조종 모드의 정체
  • 핵심 구분: 경험 vs 연습
• 2. 의도적 연습의 4요소
  • 요소 1: 명확하고 구체적인 목표
  • 요소 2: 완전한 집중
  • 요소 3: 즉각적이고 구체적인 피드백
  • 요소 4: 한계 너머에 대한 도전 (컴포트존 밖)
• 3. 개발자를 위한 구체적 연습법
  • 방법 1: 코드 읽기 (잘 짠 코드를 의식적으로 읽기)
  • 방법 2: 재구현 (보고 베끼지 않고, 이해하고 다시 짜기)
  • 방법 3: 코드 카타 (작은 문제를 반복해 기본기를 닦기)
  • 방법 4: 포스트모템 (실패와 사건에서 의식적으로 배우기)
• 4. 피드백 루프 만드는 법
  • 피드백 루프의 구조
  • 혼자 피드백을 만드는 방법
  • 동료에게 피드백 구하는 대화
• 5. 컴포트존 밖으로 나가기
  • 컴포트존을 진단하기
  • 한 발짝씩 밀어내기
• 6. 정체기(plateau) 돌파하기
  • 정체기의 정체
  • 정체기를 깨는 전략
• 7. 진척 측정하기
  • 무엇을 측정할까
  • 학습 저널 쓰기
• 8. 주간 루틴 설계
• 9. 흔한 함정들
  • 함정 1: 분주함을 연습으로 착각하기
  • 함정 2: 수동적 소비를 학습으로 착각하기
  • 함정 3: 너무 큰 목표로 마비되기
  • 함정 4: 피드백을 회피하기
  • 함정 5: 고정 마인드셋
• 마치며: 오늘 한 발짝
• 참고 자료

들어가며: 10년 차인데 왜 안 늘까

제가 아는 한 선배는 백엔드 경력 12년 차였습니다. 이력서만 보면 누구나 시니어로 모실 만한 분이었죠. 그런데 함께 일하면서 묘한 위화감을 느꼈습니다. 그는 5년 전에 익힌 방식 그대로 코드를 짰고, 새로운 문제 앞에서도 늘 같은 도구를 꺼냈습니다. 경력은 12년이었지만, 실력은 "3년을 네 번 반복한" 것에 가까웠습니다.

반대로 어떤 후배는 3년 차인데도 토론 자리에서 핵심을 정확히 짚었습니다. 그는 매주 자기가 짠 코드를 다시 들여다보며 "이건 왜 이렇게 했더라"를 묻고, 모르는 부분을 메모해 두었다가 끝까지 파고들었습니다. 같은 시간을 보냈는데 두 사람의 격차는 점점 벌어졌습니다.

이 글은 그 격차의 정체에 관한 이야기입니다. 결론부터 말하면, 경력의 길이는 실력을 보장하지 않습니다. 무엇을, 어떻게 했느냐가 보장합니다. 그리고 그 "어떻게"에는 이름이 있습니다. 의도적 연습(deliberate practice)입니다.

이 글은 추상적인 훈계가 아니라, 내일 아침부터 책상에서 적용할 수 있는 구체적인 방법을 목표로 합니다. 따뜻하되 단단하게, 과장 없이 가보겠습니다.

1. 경력이 곧 실력이 아니라는 불편한 사실

10년의 함정

흔히 "1만 시간의 법칙"이라는 말을 듣습니다. 무엇이든 1만 시간을 투자하면 전문가가 된다는 통념이죠. 그런데 이 통념의 원전인 안데르스 에릭손(Anders Ericsson)의 연구는 사실 정반대에 가까운 이야기를 합니다.

에릭손이 강조한 것은 시간의 "양"이 아니라 "질"이었습니다. 그의 연구에서 최고 수준의 바이올린 연주자들을 가른 것은 단순히 연습 시간의 총합이 아니라, 한계를 밀어붙이는 집중된 연습의 시간이었습니다. 그냥 오래 켜는 것과, 못 하는 부분을 골라 의식적으로 고치는 것은 전혀 다른 활동이었던 겁니다.

에릭손은 책 『1만 시간의 재발견(Peak)』에서 한 가지 불편한 관찰을 합니다. 많은 분야에서 사람들은 일정 수준에 도달하면 더 이상 늘지 않는다는 것입니다. 운전을 20년 했다고 카레이서가 되지 않고, 진료를 30년 한 의사가 5년 차보다 진단을 더 잘한다는 보장도 없다는 연구들이 있습니다. 어느 순간 "충분히 잘하게" 되면, 우리는 자동조종 모드로 들어갑니다.

자동조종 모드의 정체

자동조종 모드는 효율적입니다. 익숙한 일을 생각 없이 빠르게 처리할 수 있죠. 문제는, 자동조종 상태에서는 실력이 늘지 않는다는 점입니다. 뇌는 어렵다고 느끼지 않는 일에는 변화를 일으키지 않습니다.

개발자의 자동조종 모드는 이렇게 생겼습니다.

- 늘 쓰던 프레임워크로, 늘 쓰던 패턴으로 짠다
- 에러가 나면 메시지를 복사해 검색하고, 처음 나온 답을 붙여넣는다
- 코드 리뷰는 "LGTM"으로 빠르게 통과시킨다
- 새 기술은 "나중에 시간 나면" 본다 (그 시간은 오지 않는다)
- 회고는 형식적으로, 같은 말을 반복한다

이 모드 안에서는 1년을 일하든 10년을 일하든 같은 근육만 씁니다. 경력은 쌓이는데 실력은 평평한 이유가 여기 있습니다.

핵심 구분: 경험 vs 연습

이 표의 핵심은, 경험과 연습이 겹칠 수는 있지만 같지는 않다는 점입니다. 우리는 매일 일하면서 무수히 많은 경험을 쌓지만, 그중 의도적 연습으로 전환되는 비율은 의외로 낮습니다.

2. 의도적 연습의 4요소

에릭손의 연구를 개발자의 언어로 옮기면, 의도적 연습은 네 개의 기둥 위에 서 있습니다. 하나씩 보겠습니다.

요소 1: 명확하고 구체적인 목표

"리액트를 잘하고 싶다"는 목표가 아닙니다. 너무 크고 모호해서 무엇을 해야 할지 알 수 없습니다. 의도적 연습의 목표는 측정 가능하고 좁아야 합니다.

나쁜 목표: "비동기 처리를 잘 다루고 싶다"
좋은 목표: "Promise.all과 for-await-of의 동작 차이를
           직접 실험으로 재현하고, 언제 무엇을 쓸지
           내 말로 한 단락 설명할 수 있다"

좋은 목표는 "끝났는지 아닌지"를 스스로 판정할 수 있습니다. 모호한 목표는 영원히 진행 중입니다. 좁은 목표는 한 번에 하나의 약점만 겨냥하기 때문에 뇌가 집중할 수 있습니다.

요소 2: 완전한 집중

의도적 연습은 멀티태스킹과 상극입니다. 슬랙 알림을 켜놓고, 유튜브를 틀어놓고 하는 "연습"은 연습이 아니라 배경음악이 깔린 시간 때우기입니다.

집중을 위한 현실적 장치는 이렇습니다.

- 25~50분 단위로 타이머를 맞춘다 (포모도로)
- 그 시간 동안 알림을 전부 끈다 (DnD 모드)
- 한 세션 = 한 가지 목표만
- 끝나면 5분 메모: 무엇을 알았고 무엇이 막혔나

집중의 질이 연습의 질을 결정합니다. 흩어진 두 시간보다 몰입한 30분이 낫습니다.

요소 3: 즉각적이고 구체적인 피드백

피드백 없는 연습은 어둠 속에서 골프 스윙을 연습하는 것과 같습니다. 공이 어디로 갔는지 모르면 아무리 휘둘러도 늘지 않습니다. 의도적 연습은 "지금 한 것이 맞았는지"를 빠르게 알려주는 장치가 필요합니다.

개발자에게 피드백 원천은 의외로 많습니다.

- 테스트: 빨강/초록으로 즉시 알려준다
- 타입 체커/린터: 실수를 코딩 중에 잡아준다
- 벤치마크: 빨라졌는지 느려졌는지 숫자로 말한다
- 코드 리뷰: 사람의 눈으로 본 구조적 피드백
- 프로덕션 지표: 실제 사용자가 주는 가장 정직한 피드백

핵심은 피드백 루프를 짧게 만드는 것입니다. 한 달 뒤에 오는 피드백보다 30초 뒤에 오는 피드백이 학습에 훨씬 강력합니다. 이 글의 4장에서 피드백 루프 설계를 따로 다루겠습니다.

요소 4: 한계 너머에 대한 도전 (컴포트존 밖)

마지막 기둥이 가장 어렵고 가장 중요합니다. 의도적 연습은 정의상 불편합니다. 편안하면 그것은 연습이 아니라 복습입니다.

학습 과학에서 말하는 영역은 셋입니다.

컴포트존 (편안한 영역)  - 이미 할 수 있는 것. 성장 없음.
러닝존  (학습 영역)     - 살짝 버거운 것. 성장 일어남.
패닉존  (공황 영역)     - 너무 어려운 것. 좌절만 남음.

의도적 연습은 러닝존에 머무는 기술입니다. 너무 쉬우면 지루하고, 너무 어려우면 무너집니다. 딱 한 발짝 어려운 곳, 90퍼센트는 알겠는데 10퍼센트가 막히는 지점, 그곳이 황금 지대입니다.

3. 개발자를 위한 구체적 연습법

이제 추상을 떠나 책상으로 갑니다. 아래 네 가지는 제가 직접 효과를 본, 그리고 많은 시니어 엔지니어들이 공통적으로 권하는 방법입니다.

방법 1: 코드 읽기 (잘 짠 코드를 의식적으로 읽기)

우리는 글을 잘 쓰려면 좋은 글을 읽어야 한다는 것은 알면서, 코드를 잘 짜려면 좋은 코드를 읽어야 한다는 것은 자주 잊습니다. 대부분의 개발자는 자기가 짠 코드와 동료가 짠 코드만 봅니다. 세계 최고 수준의 코드는 좀처럼 들여다보지 않습니다.

오픈소스가 그 보물창고입니다. 다만 그냥 스크롤하는 것은 연습이 아닙니다.

코드 읽기 연습 절차

1. 목표를 정한다
   예: "이 라이브러리는 동시성 문제를 어떻게 푸는가"
2. 진입점을 찾는다 (README, 테스트, public API)
3. 한 가지 흐름만 끝까지 따라간다 (전부 읽지 않는다)
4. 막히는 부분에 질문을 메모한다
   "여기서 왜 락 대신 CAS를 썼지?"
5. 답을 찾거나, 직접 가설을 세워 실험한다
6. 배운 패턴을 한 문장으로 적는다

이 연습의 핵심은 능동성입니다. "왜?"라는 질문을 멈추지 않는 것. 좋은 코드는 수많은 결정의 결과물이고, 그 결정의 이유를 추적하는 과정 자체가 연습입니다.

방법 2: 재구현 (보고 베끼지 않고, 이해하고 다시 짜기)

읽기에서 한 단계 나아간 것이 재구현입니다. 작동하는 무언가의 동작을 이해한 뒤, 원본을 보지 않고 직접 만들어 보는 것입니다.

재구현 연습 예시

- 디바운스/스로틀 함수를 직접 구현해 본다
- 작은 상태관리 라이브러리(스토어+구독)를 만들어 본다
- Promise를 표준 스펙만 보고 직접 구현해 본다
- 간단한 라우터, 간단한 가상 DOM diff를 짜 본다
- LRU 캐시를 테스트와 함께 처음부터 작성한다

재구현의 힘은 "안다고 착각한 것"과 "정말 아는 것"을 가른다는 데 있습니다. 디바운스를 백 번 써봤어도 직접 짜려고 하면 타이머 정리, this 바인딩, 마지막 호출 처리에서 막힙니다. 그 막히는 지점이 바로 당신이 모르던 부분입니다.

방법 3: 코드 카타 (작은 문제를 반복해 기본기를 닦기)

카타(kata)는 무술에서 정해진 동작을 반복 수련하는 것을 말합니다. 코드 카타는 같은 작은 문제를 여러 방식으로, 여러 번 푸는 연습입니다. 목적은 문제를 푸는 것이 아니라 푸는 과정을 다듬는 것입니다.

코드 카타 운영법

- 작은 문제 하나를 고른다 (예: 로마 숫자 변환)
- 월: 평소 방식대로 푼다
- 화: TDD로, 테스트 먼저 작성해 푼다
- 수: 함수형 스타일로만 푼다
- 목: 가장 적은 줄 수로 (가독성 희생 실험)
- 금: 가장 읽기 쉬운 코드로 다시 (균형 찾기)

같은 문제를 다른 제약 아래 풀면, 평소 자동으로 내리던 결정들이 표면으로 드러납니다. codewars.com이나 codekata.com 같은 곳에서 문제를 구할 수 있지만, 사실 일상 업무에서 만난 작은 함수 하나를 카타 삼아도 충분합니다.

방법 4: 포스트모템 (실패와 사건에서 의식적으로 배우기)

가장 비싼 교과서는 장애입니다. 새벽에 울린 알람, 깨진 배포, 사라진 데이터. 이 경험들은 강렬해서 자동으로 학습이 될 것 같지만, 의식적으로 정리하지 않으면 그저 트라우마로만 남습니다.

포스트모템은 사건을 학습 자산으로 바꾸는 의식적 절차입니다. 핵심은 비난 없는(blameless) 태도입니다. "누가 잘못했나"가 아니라 "어떤 시스템이 이 실수를 가능하게 했나"를 묻습니다.

간단한 개인 포스트모템 템플릿

1. 무슨 일이 일어났나 (사실만, 시간순)
2. 왜 일어났나 (5 Whys로 근본 원인까지)
3. 어떻게 알아챘나 (탐지까지 걸린 시간)
4. 어떻게 복구했나
5. 무엇을 바꾸면 재발을 막는가 (구체적 액션)
6. 내가 이번에 새로 배운 것 한 가지

구글 SRE 책의 포스트모템 문화 장이 좋은 출발점입니다. 팀 차원의 포스트모템이 없더라도, 개인적으로 위 템플릿을 채워보는 것만으로 같은 사건에서 두 배로 배울 수 있습니다.

4. 피드백 루프 만드는 법

의도적 연습의 네 요소 중 개발자가 가장 자주 빠뜨리는 것이 피드백입니다. 혼자 공부할 때 특히 그렇습니다. 그래서 피드백 루프를 따로 설계하는 법을 다룹니다.

피드백 루프의 구조

   ┌──────────────┐
   │  1. 시도하기   │   (코드를 짠다, 가설을 세운다)
   └──────┬───────┘
          │
          v
   ┌──────────────┐
   │  2. 신호 받기   │   (테스트, 리뷰, 지표, 사람)
   └──────┬───────┘
          │
          v
   ┌──────────────┐
   │  3. 차이 보기   │   (기대 vs 실제, 무엇이 어긋났나)
   └──────┬───────┘
          │
          v
   ┌──────────────┐
   │  4. 조정하기   │   (가설 수정, 다음 시도)
   └──────┬───────┘
          │
          └──────────> 다시 1번으로 (루프가 짧을수록 강력)

이 루프가 빠르게 돌수록 학습이 빨라집니다. 좋은 개발 환경은 결국 이 루프를 짧게 만드는 도구의 집합입니다. 핫 리로드, 빠른 테스트, 좋은 에러 메시지가 모두 피드백 루프 단축 장치입니다.

혼자 피드백을 만드는 방법

동료 리뷰가 없을 때도 피드백을 만들 수 있습니다.

- 미래의 나에게 리뷰 받기:
  코드를 짜고 하루 뒤 다시 읽으면 객관화된다
- 테스트를 피드백 기계로:
  "이게 맞다"를 코드가 아니라 테스트로 증명한다
- 공개적으로 쓰기:
  배운 것을 글이나 메모로 정리하면 구멍이 드러난다
- 설명해 보기 (러버덕):
  남에게 (또는 인형에게) 설명하다 보면 모르는 곳이 나온다
- 두 가지 방식으로 짜보기:
  같은 걸 다르게 짜면 두 방식이 서로의 피드백이 된다

동료에게 피드백 구하는 대화

피드백을 잘 받으려면 잘 물어야 합니다. "코드 좀 봐줘"는 좋은 질문이 아닙니다. 너무 넓어서 상대가 무엇을 봐야 할지 모릅니다.

나쁜 요청:
  "이 PR 리뷰 좀 해주세요."

좋은 요청:
  "이 PR에서 에러 처리 부분이 자신이 없어요.
   특히 외부 API가 타임아웃 났을 때 재시도 로직이
   합리적인지 봐주시면 감사하겠습니다.
   나머지는 가볍게 봐주셔도 됩니다."

좁고 구체적인 요청은 상대의 시간을 아끼고, 당신이 정말 약한 부분에 피드백을 집중시킵니다.

5. 컴포트존 밖으로 나가기

머리로는 "어려운 걸 해야 는다"를 알지만, 몸은 편한 쪽으로 흐릅니다. 컴포트존을 벗어나는 것은 의지력의 문제라기보다 설계의 문제입니다.

컴포트존을 진단하기

먼저 내가 어디에 머물러 있는지 알아야 합니다. 아래 질문에 정직하게 답해 보세요.

컴포트존 체크리스트

[ ] 최근 한 달, 막혀서 한 시간 이상 헤맨 적이 있는가?
[ ] 최근 짠 코드 중 "이게 될까?" 싶었던 게 있는가?
[ ] 모른다고 솔직히 말한 적이 최근에 있는가?
[ ] 새 도구/언어/패러다임을 시도한 적이 있는가?
[ ] 내 결정에 누군가 반론을 제기한 적이 있는가?

체크가 적을수록 컴포트존에 깊이 머물고 있을 가능성이 높다.

막힘이 전혀 없다는 것은 편안하다는 뜻이고, 편안함은 성장이 멈췄다는 신호일 수 있습니다.

한 발짝씩 밀어내기

컴포트존을 벗어나는 안전한 방법은 패닉존으로 점프하는 것이 아니라, 러닝존으로 한 발짝 옮기는 것입니다.

- 익숙한 언어의 미사용 기능 하나를 일부러 써본다
- 평소 피하던 영역(프론트면 백엔드, DB면 프론트)을 건드린다
- 코드 리뷰에서 의견이 갈리면 침묵하지 말고 근거를 댄다
- 자신 없는 주제로 사내 발표/공유를 자청한다
- 추정만 하던 부분을 측정으로 검증한다

작은 불편을 자주 겪는 것이, 큰 불편을 가끔 겪는 것보다 낫습니다. 매일 5퍼센트씩 버거운 일을 하는 사람이 1년 뒤 가장 멀리 가 있습니다.

6. 정체기(plateau) 돌파하기

열심히 했는데 어느 순간부터 늘지 않는 느낌. 이것이 정체기입니다. 정체기는 실패가 아니라 학습 곡선의 자연스러운 일부입니다. 거의 모든 숙련 과정에 나타납니다.

정체기의 정체

에릭손은 정체기가 능력의 한계가 아니라 방법의 한계인 경우가 많다고 말합니다. 지금까지 쓰던 연습 방식으로는 더 이상 자극이 되지 않는 지점에 도달한 것입니다. 같은 자극에 적응해 버린 거죠.

정체기의 흔한 신호
- 새로운 게 하나도 없다고 느껴진다
- 익숙한 일이 너무 쉬워졌다
- 흥미가 떨어지고 지루하다
- 노력 대비 변화가 안 보인다

정체기를 깨는 전략

1. 약점을 정밀 조준한다
   막연히 다 잘하려 말고, 가장 약한 한 가지를 찾아
   그것만 집중 공략한다 (자동조종을 끊는 효과)

2. 제약을 추가한다
   "라이브러리 없이", "한 파일로", "성능 2배로" 같은
   인위적 제약은 새로운 근육을 강제로 쓰게 만든다

3. 난이도를 한 단계 올린다
   더 큰 코드베이스, 더 까다로운 요구사항으로 옮긴다

4. 가르친다
   남을 가르치면 자기 이해의 구멍이 적나라하게 드러난다

5. 환경을 바꾼다
   새 팀, 새 도메인, 새 동료는 자동조종을 강제로 끈다

정체기에서 가장 위험한 반응은 "더 많이, 더 오래"입니다. 같은 방식으로 양만 늘리는 것은 효과가 없습니다. 방식을 바꿔야 합니다.

7. 진척 측정하기

"측정되지 않는 것은 개선되지 않는다"는 말은 실력에도 적용됩니다. 다만 실력은 매출처럼 깔끔한 숫자가 아니어서, 측정에 약간의 창의가 필요합니다.

무엇을 측정할까

- 학습 로그: 매주 "이번 주 새로 안 것" 3가지를 기록
- 막힘 시간: 같은 종류 문제에서 막히는 시간이 주는가
- 재구현 속도: 예전에 두 시간 걸린 걸 지금은 얼마에 하는가
- 코드 리뷰 코멘트: 받는 지적의 종류가 고급으로 옮겨가는가
- 설명 능력: 한 개념을 막힘없이 설명할 수 있는가

학습 저널 쓰기

가장 단순하고 강력한 측정 도구는 학습 저널입니다. 거창할 필요 없습니다.

주간 학습 저널 양식 (5분)

날짜:
이번 주 의도적 연습한 것:
새로 알게 된 것 3가지:
  1.
  2.
  3.
가장 크게 막혔던 지점:
다음 주에 시도할 한 가지:

몇 주 치를 모아 다시 읽으면, 매일은 안 보이던 성장 곡선이 보입니다. 저널은 진척을 측정하는 동시에, 학습한 것을 한 번 더 인출해 기억을 강화하는 효과도 있습니다.

8. 주간 루틴 설계

좋은 의도는 루틴이 없으면 증발합니다. "시간 날 때 공부해야지"의 그 시간은 오지 않습니다. 의도적 연습은 캘린더에 자리를 잡아야 살아남습니다.

아래는 주당 약 5시간을 의도적 연습에 배분한 예시입니다. 분량은 형편에 맞게 조절하세요. 핵심은 매일 조금씩, 그리고 다양하게입니다.

이 표를 그대로 따를 필요는 없습니다. 중요한 것은 두 가지입니다. 첫째, 연습이 캘린더에 구체적 시간으로 박혀 있을 것. 둘째, 매주 최소 한 번은 컴포트존 밖으로 나가는 활동이 들어 있을 것.

업무 중 도전을 강조하고 싶습니다. 별도의 5시간만 연습이 아닙니다. 매일의 업무 안에서 "조금 더 좋은 방식은 없을까"를 한 번 더 묻는 것, 익숙한 해법 대신 한 발짝 어려운 해법을 시도하는 것이 가장 효율적인 연습입니다. 일과 연습을 분리하지 말고, 일 안에 연습을 심으세요.

9. 흔한 함정들

마지막으로, 좋은 의도를 가진 사람들이 자주 빠지는 함정을 짚겠습니다. 이 함정들을 피하는 것만으로도 절반은 성공입니다.

함정 1: 분주함을 연습으로 착각하기

가장 흔하고 가장 교묘한 함정입니다. 우리는 바쁘면 성장하고 있다고 느낍니다. 티켓을 쳐내고, 회의에 참석하고, 슬랙에 답하면서 하루가 꽉 찹니다. 그러나 그 대부분은 자동조종 모드의 분주함일 뿐, 의도적 연습이 아닙니다.

분주함 vs 연습 구별법
- 끝나고 새로 배운 게 있는가? 없다면 분주함이다.
- 살짝이라도 버거웠는가? 편했다면 분주함이다.
- 약점을 겨냥했는가? 강점만 썼다면 분주함이다.

바쁜 것과 자라는 것은 다릅니다. 일을 많이 한 날과 실력이 는 날은 같지 않을 수 있습니다.

함정 2: 수동적 소비를 학습으로 착각하기

강의 영상을 2배속으로 몰아보고, 기술 아티클을 북마크만 잔뜩 하는 것. 입력은 학습의 시작일 뿐 학습 자체가 아닙니다. 직접 손을 움직여 출력하지 않으면 대부분 휘발됩니다. 강의 한 시간을 보면 코드 두 시간을 짜는 비율이 건강합니다.

함정 3: 너무 큰 목표로 마비되기

"머신러닝 마스터하기" 같은 목표는 너무 커서 첫발조차 떼기 어렵게 만듭니다. 목표가 클수록 작게 쪼개야 합니다. 큰 산은 한 발짝씩만 오를 수 있습니다.

함정 4: 피드백을 회피하기

자기가 짠 코드를 남에게 보여주기는 늘 두렵습니다. 그래서 피드백이 가장 필요한 사람일수록 피드백을 피합니다. 그러나 부끄러움을 무릅쓰고 받은 피드백이 가장 빠른 성장의 지름길입니다. 피드백은 공격이 아니라 선물입니다.

함정 5: 고정 마인드셋

캐롤 드웩(Carol Dweck)의 연구는 능력을 고정된 것으로 보는 사람과 키울 수 있는 것으로 보는 사람의 성장 격차를 보여줍니다. "나는 원래 알고리즘에 약해"라는 말은 자기실현적 예언이 됩니다. 약점은 아직 연습하지 않은 영역일 뿐입니다. "아직(yet)"이라는 단어 하나를 붙이는 것에서 시작됩니다. "나는 이걸 못해"가 아니라 "나는 이걸 아직 못해"로.

마치며: 오늘 한 발짝

다시 처음의 두 선후배 이야기로 돌아갑니다. 12년 차 선배와 3년 차 후배의 차이는 재능도, 시간도 아니었습니다. 매일의 작은 의식적 노력이 복리로 쌓인 결과였습니다.

의도적 연습은 거창한 결심이 아닙니다. 오늘 짠 코드를 한 번 더 들여다보는 것, 모르는 것을 모른다고 메모하는 것, 한 발짝 어려운 해법을 시도하는 것, 그 작은 행동들의 누적입니다.

그리고 솔직히 말하면, 이것은 늘 즐겁지만은 않습니다. 의도적 연습은 정의상 불편하니까요. 편안한 자동조종을 끄고 매번 러닝존에 자기를 두는 것은 에너지가 듭니다. 그러니 자신에게 너무 가혹하지는 마세요. 매일 완벽할 필요는 없습니다. 다만 멈추지만 않으면 됩니다.

경력의 길이가 아니라, 그 시간에 무엇을 어떻게 했는지가 당신을 만듭니다. 내일의 당신은 오늘 당신이 선택한 연습의 합입니다. 거창하게 시작하지 말고, 작게 시작하세요. 오늘 한 발짝이면 충분합니다.

참고 자료

• Anders Ericsson & Robert Pool, "Peak: Secrets from the New Science of Expertise"
• The Making of an Expert (Harvard Business Review)
• Carol Dweck on Growth Mindset (Stanford Profile)
• Will Larson, Irrational Exuberance (lethain.com)
• StaffEng — Stories and guides for reaching Staff-plus roles
• Martin Fowler — Refactoring
• Google SRE Book — Postmortem Culture
• CodeKata — Dave Thomas
• Codewars — practice coding challenges