AI 코딩 시대 — 성장이 멈추는 개발자의 뇌에서 일어나는 일

역설적인 현실

AI를 잘 쓰려면 AI 없이도 판단할 능력이 필요하다.

GitHub Copilot, Claude Code, Cursor가 일상이 된 지금, 코드 작성 속도는 확실히 빨라졌다. 그런데 한 가지 불편한 질문이 따라온다. "내가 AI 없이도 이 코드를 짤 수 있을까?"

더 정확하게는 이렇다. AI가 뽑아낸 코드를 읽을 때, 어디가 틀렸는지 짚어낼 수 있는가. 짚어내지 못한다면, 그 AI를 제대로 쓰고 있는 게 맞는가.

Evan Moon이 쓴 글은 이 질문에 신경과학으로 답한다. AI 보조 코딩이 개발자의 장기 성장을 어떻게 저해하는지, 그리고 AI를 쓰면서도 어떻게 성장을 유지할 수 있는지를 다룬다. 이 글은 그 내용을 개발자 실무 관점에서 다시 정리한 것이다.

뇌의 학습 원리: 고통이 기억을 만든다

바람직한 어려움 (Desirable Difficulty)

UCLA의 Robert Bjork는 학습에서 역설적인 원리를 발견했다. "적절한 수준의 어려움이 단기 수행은 느리게 만들지만, 장기 기억과 전이(transfer)는 향상시킨다."

근육 운동과 똑같다. 들기 쉬운 무게만 반복하면 근육이 붙지 않는다. 한계에 가까운 무게에서 발생하는 미세 손상이 근성장을 만든다. 뇌도 마찬가지다. 너무 쉬우면 흔적이 안 남고, 너무 어려우면 포기한다. 딱 맞는 저항이 기억을 만든다.

StackOverflow 시대의 개발자는 검색하고, 답변 여러 개를 비교하고, 자신의 코드에 맞게 고쳐 붙이는 과정에서 최소한의 인지 마찰을 겪었다. AI 시대엔 완성된 코드가 즉시 나온다. 마찰이 거의 0이다. 생산성이 올라간 만큼, 근육이 붙는 부위는 줄어든다.

인출 연습 효과 (Retrieval Practice)

Roediger & Karpicke(2006) 연구는 이 원리를 숫자로 보여준다.

• A 그룹: 같은 내용을 여러 번 다시 읽음
• B 그룹: 내용을 덮고 직접 떠올려 씀 (인출 연습)

일주일 후 기억 보존율은 B 그룹이 약 50% 더 높았다. 더 적게 공부한 쪽이 더 많이 기억한 것이다.

"이 훅 어떻게 쓰더라?" 하고 기억을 끄집어내는 그 순간이 바로 인출 연습이다. 뇌가 저장된 경로를 다시 더듬는 동안, 그 경로가 더 굵어진다. AI가 코드를 대신 생성하면 이 순간이 통째로 사라진다. 꺼내지 않는 기억은 점점 희미해진다.

생성 효과 (Generation Effect)

Slamecka & Graf(1978)의 연구도 같은 방향을 가리킨다.

직접 생성하는 과정에서 뇌의 의미 처리, 인출 경로, 실행 제어 영역이 동시에 활성화된다. AI 코드를 읽으면 이해한 것 같은 느낌이 들지만, 실제 보존율은 훨씬 얕다.

[💡 잠깐! 이 용어는?] 생성 효과(Generation Effect): 정보를 수동으로 받아들이는 것보다 직접 생성할 때 기억이 더 잘 유지되는 현상. "AI가 뽑아낸 코드를 읽는 것"보다 "빈 에디터에 직접 한 글자씩 타이핑하는 것"이 학습 효과가 압도적으로 크다.

절차 기억: 개발자 실력의 본체

Anderson의 ACT 모델

숙련된 개발자는 왜 초보자보다 같은 작업을 빠르고 정확하게 할까? 지식의 양 때문이 아니다. 절차 기억의 깊이 때문이다. Anderson의 적응적 사고 통제(ACT) 모델은 이를 3단계로 설명한다.

처음 운전할 때는 핸들, 브레이크, 사이드미러, 주변 차량을 전부 의식적으로 처리한다. 5년 차 운전자는 이 모든 걸 자동으로 처리하면서 라디오 주파수를 바꾼다. 같은 뇌 용량으로 훨씬 많은 일을 처리하는 이유가 자동화다.

코딩도 같다. try-catch-finally, useEffect 클린업, 비동기 에러 핸들링 — 숙련자에겐 손가락이 먼저 움직이는 영역이고, 인지 자원은 설계 판단에 쓰인다. AI가 코드를 대신 작성하면 인지 단계를 건너뛰게 된다. 출발점 자체가 없으니 자동화에 이르지 못한다.

청킹: 전문가의 진짜 무기

Chase & Simon의 체스 연구에서 유명한 결과가 나왔다. 체스 고수는 "시실리안 디펜스 중반 배치"를 **하나의 청크(chunk)**로 인식한다. 말 하나하나를 보는 게 아니라, 패턴 전체를 한 덩어리로 본다.

한글 읽기와 같다. 초등학생은 "ㅂ + ㅏ + ㅂ"을 한 글자씩 조립해서 "밥"을 읽는다. 성인은 "밥"을 통째로 인식한다. 같은 눈, 같은 뇌, 같은 시간에 받아들이는 정보량이 10배 차이 난다.

코딩에서도 마찬가지다. 숙련 개발자는 for문 + 배열 + 조건 + push를 "필터링 패턴" 하나로 압축해서 인식하고, 남은 인지 자원을 구조적 판단에 쓴다. 이 청크는 직접 반복해서 짜봐야 형성된다. 읽는 것만으로는 청크가 만들어지지 않는다. AI가 출력한 코드를 읽는 시간은 청크 형성 시간이 아니라, 청크 소비 시간이다.

AI가 만드는 성장 정체

버그를 못 잡는 이유

아래 코드를 보자. 두 가지 버그가 있다.

function useNotification(userId: string) {
  const [notifications, setNotifications] = useState([])
 
  useEffect(() => {
    const intervalId = setInterval(() => {
      fetchNotifications(userId).then(setNotifications)
    }, 5000)
    // 버그 1: clearInterval 누락 → 언마운트 후에도 인터벌 계속 실행
  }, []) // 버그 2: userId 의존성 배열 누락 → 이전 사용자 데이터 계속 폴링
 
  return notifications
}

SOLID 원칙을 줄줄 설명하는 개발자도 이 코드를 보고 두 버그를 즉시 잡아내지 못할 수 있다. 이건 지식의 문제가 아니라 절차 기억의 문제다. useEffect의 클린업과 의존성 배열은 수십 번 직접 짜고 깨지면서 손에 배는 영역이다.

AI 없이 손으로 짰다면 어땠을까. 클린업을 빠뜨린 순간 DevTools에서 메모리가 슬금슬금 차오르는 걸 본다. 의존성 배열을 잘못 쓴 순간 "왜 userId를 바꿨는데 이전 데이터가 보이지?" 하고 30분간 헤맨다. 그 30분의 고통이 패턴을 뇌에 각인시킨다. AI가 완성된 코드를 뱉는 순간, 이 각인 기회 자체가 사라진다.

[💡 잠깐! 이 용어는?] 메모리 누수(Memory Leak): 사용이 끝난 리소스가 해제되지 않고 계속 메모리를 점유하는 현상. React의 useEffect 클린업 함수를 빠뜨리면, 컴포넌트가 화면에서 사라진 뒤에도 setInterval이 살아남아 메모리가 쌓인다.

유창성의 착각

AI 코드를 읽으면 이해한 것 같다. 실제로는 아니다. 예측과 피드백 없이 수동적으로 받아들인 정보는 장기 기억에 깊이 저장되지 않는다. 이걸 **유창성의 착각(Fluency Illusion)**이라 부른다.

악보를 눈으로 읽는 것과 직접 연주하는 것의 차이다. 악보를 읽을 땐 "아, 이렇게 치면 되겠구나" 싶지만, 막상 건반 앞에 앉으면 손가락이 멈춘다. AI 코드를 훑으며 "아 이 패턴이구나" 하고 넘겼는데, 다음날 빈 에디터 앞에서 커서가 깜빡이기만 하는 경험이 정확히 이것이다.

실무에서는 이런 상황으로 드러난다.

• PR 리뷰 중 AI가 만든 코드를 승인했는데, 나중에 "왜 이 구조로 갔냐"는 질문에 답하지 못한다
• 같은 패턴을 다시 구현해야 할 때, 이전 브랜치에서 AI가 만든 코드를 다시 찾아 복사한다
• "이거 전에 해봤는데" 감은 있지만, 빈 파일에서 시작하면 첫 줄부터 막힌다

세 증상 중 하나라도 반복되고 있다면, 청크가 안 만들어지고 있다는 신호다.

성장을 유지하는 전략

1. AI를 부르기 전에 "설계 스케치"를 먼저 쓴다

코드 에디터를 열기 전에, 주석 3~5줄로 자기 머릿속 설계를 먼저 적는다.

// 스케치 (AI 호출 전, 혼자 작성)
// - 상태: notifications[], loading, error
// - useEffect: userId 바뀌면 재시작, 5초 인터벌, 언마운트 시 clearInterval
// - 의존성 배열: [userId]
// - 반환: { notifications, isLoading, error }
 
// 이후 AI 호출 → 출력과 스케치 비교 → 다른 부분이 있으면 "왜 다른가" 질문

핵심은 비교와 평가다. 스케치 없이 AI 코드를 받으면 그냥 읽고 넘어가지만, 스케치가 있으면 "내가 놓친 부분은 무엇인가"가 명확해진다. 인출 연습과 생성 효과를 동시에 챙기는 방법이다.

2. AI가 뽑은 코드에 "왜?"를 3번 질문한다

머지 버튼을 누르기 전, 다음 세 가지를 스스로 답해본다.

• 이 함수가 왜 이 시그니처인가? (다른 시그니처는 왜 안 되는가)
• 이 에러 처리가 왜 여기에 있나? (한 단계 위/아래에선 왜 안 되는가)
• 이 의존성 배열에 왜 이 값들만 들어갔나?

세 질문에 답하지 못하면, 그 코드는 아직 내 코드가 아니다. 귀찮은 감각이 드는 순간이 바로 바람직한 어려움이 작동하는 증거다.

3. 일주일에 "AI 금식 시간"을 확보한다

업무 전체를 AI 없이 하자는 얘기가 아니다. 주당 2~3시간 정도, 새로운 개념/알고리즘을 AI 없이 짜는 세션을 루틴으로 만든다. 막히면 AI에게 완성 코드가 아니라 힌트만 요청한다.

❌ "useEffect로 폴링 구현해줘"
✅ "useEffect 클린업에서 놓치기 쉬운 케이스 3가지만 알려줘"

힌트를 받고 다시 에디터로 돌아간다. 손가락이 움직여야 청크가 생긴다.

4. 작업 유형별로 AI 사용 강도를 바꾼다

모든 작업에서 AI를 같은 강도로 쓸 필요는 없다. 자동화된 영역과 학습이 필요한 영역을 구분한다.

원칙은 하나다. 처음 만나는 영역엔 근육을 키우고, 자동화된 영역에선 AI에게 맡긴다.

정리

AI 코딩 도구는 생산성을 올린다. 동시에 성장의 마찰을 제거한다. 뇌의 근본 작동 방식 — 인지 부하를 회피하려는 경향 — 은 AI 발전과 무관하게 수십만 년째 고정되어 있다.

• 바람직한 어려움: 근육은 저항이 있어야 붙는다. 뇌도 같다
• 인출 연습과 생성 효과: 읽은 기억은 얕고, 꺼낸 기억과 만든 기억은 깊다
• 절차 기억과 청킹: 직접 짜봐야 패턴이 한 덩어리로 압축된다
• 유창성의 착각: "이해한 느낌"과 "다시 짤 수 있는 능력"은 다른 것이다

결국 선택은 하나다. AI를 쓰되, 바람직한 어려움을 의도적으로 남겨두는 것. 설계 스케치 먼저 쓰기, "왜?" 3질문, 주간 AI 금식, 작업별 사용 강도 조절. 네 가지만 지켜도 AI 시대에 근육이 빠지지 않는다.

참고:

• Evan Moon — AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일: https://evan-moon.github.io/2026/04/18/developers-who-stopped-growing-in-ai-era/
• Roediger & Karpicke (2006) — The Power of Testing Memory
• Bjork, R.A. — Desirable difficulties perspective on learning