서론 (결론)

"AI를 사용하여 개발한 날의 끝에, 자신이 작성한 코드의 내용을 기억하지 못한다". 이러한 감각을 뒷받침하는 실증 연구가 여러 건 보고되고 있습니다.

무작위 대조 시험 (RCT)을 통해 확인된 것은 다음의 한 가지 점입니다.

"학습을 목적으로 한 과제에서는, AI를 사용하면 학습량이 줄어들고 작업 속도도 빨라지지 않는다"

다만, 같은 AI를 사용하더라도 성적에는 큰 차이가 있었습니다.

낮은 관여도 (AI에게 통째로 맡기기): 평균 점수 24%~39% -
높은 관여도 (대화·검증): 평균 점수 65%~86% (AI 미사용군인 67%와 동등하거나 그 이상)

즉, "AI를 사용했는지 여부"가 아니라 "어떻게 관여했는가"가 학습 성과를 좌우합니다.

본 기사는 2023~2026년에 발표된 실증 연구의 1차 소스를 바탕으로, AI 시대의 효과적인 학습·개발 스타일을 정리한 것입니다.

1. 실험으로 증명된 사실

1.1 학습 목적의 과제에서는 "학습이 줄어들고, 빨라지지도 않는다"

Anthropic의 연구 (Shen & Tamkin, 2026)에서는 개발자 52명을 대상으로 미지의 라이브러리 (Python Trio)를 사용하는 과제를 실시했습니다.

테스트 결과: AI 이용군은 이해도 테스트 성적이 유의미하게 저하 (27점 만점 중 평균 4.15점 낮음). -
소요 시간: AI군이 약 23.0분, 수기(Hand-writing)군이 약 24.7분으로 통계적인 유의차 없음 (p=0.391). -
결론: 이 과제에서 AI는 학습을 줄였을 뿐, 속도 또한 얻지 못했습니다.

1.2 "설명 게이트"가 AI 제거 후의 버그 수정률을 개선

Sankaranarayanan (2026)은 피험자 78명에게 React.js 과제를 수행하게 한 후, AI 없이 유지보수·디버깅 과제 (30분)를 부여했습니다.

무제한 AI군: 버그 수정 실패율 77% -
설명 게이트 포함 AI군: 버그 수정 실패율 39%

※ 과제 자체는 두 AI군 모두 제대로 만들어냈습니다. 차이가 난 것은 나중에 고치는 능력입니다. "만드는 능력"과 "고치는 능력"이 별개로 작동하고 있음을 보여줍니다.

1.3 프로그래밍 이외의 영역으로부터의 방증 (참고)

문장 집필 (Kosmyna et al., 2025): LLM 이용 시 뇌 내 네트워크의 결합도가 저하 (뇌파 측정). -
수학 (Bastani et al., 2025): GPT-4 사용자는 연습 성적이 오르지만, AI를 제거한 테스트에서는 성적이 17% 저하 (가드레일이 없는 경우). -
비판적 사고 (Gerlich, 2025): 생성형 AI의 이용 빈도와 비판적 사고 사이에 부의 상관관계 (인지적 오프로딩 (Cognitive Offloading)의 증가가 영향). -
기업 조사 (Chen et al., 2026): BNY Mellon에서의 조사. 장기적인 생산성에는 "기술적 전문성"과 "업무 소유감"이 중요하다고 제시.

2. 같은 AI를 써도 "결과가 갈리는" 이유

2.1 6가지 관여 패턴과 성적

Shen & Tamkin (2026)은 AI 이용자를 관여 스타일에 따라 6가지 패턴으로 분류했습니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

• 핵심 포인트: AI를 사용하더라도, 스스로 이해하려고 노력하거나 개념만 들은 그룹(상위 1~3)은 AI를 사용하지 않은 대조군과 동등하거나 그 이상의 성적을 거두었습니다.

2.2 주의점: 인과관계인가 '사전 능력'인가?

이 분류는 사후 분석(각 클러스터 2~7명, 총 24명)이며, '이런 사용법을 선택하면 성적이 오른다'는 직접적인 인과관계를 제시하지 않습니다.

Kazemitabaar et al. (2023)의 연구(초심자 69명)에서는 사전 프로그래밍 능력(Scratch 테스트)이 높은 참가자일수록 AI(Codex)를 사용했을 때 유지 테스트에서 좋은 결과를 보였습니다. 즉, '원래 실력이 있기 때문에 능숙하게 참여할 수 있었다'는 가능성이 있습니다.

2.3 시간 비용 분배 문제

참여를 깊게 하려면 시간이 걸립니다. 실험에서는 프롬프트 하나 작성에 최대 6분, 대화 전체에서 최대 11분을 소비한 사례도 있었습니다(총 시간의 큰 비율). 사용할 수 있는 시간은 한정적이므로, 어디에 시간을 쓸지 선택해야 합니다.

3. 왜 참여 방식에 따라 학습이 달라지는가?

인지 부하 이론으로 해석

인간의 학습 과정에는 세 가지 인지 부하가 존재합니다(Sweller et al.).

• 외재적 부하: 타이핑이나 구문 오류 등 본질적이지 않은 수고 -

• 본질적 부하: 로직 구축이나 상태 관리 등 영역의 본질적인 사고 -

• 학습 관련 부하: 생각을 장기 기억(지식)으로 정착시키는 처리

• 인지 오프로딩 (수고 감소): 외재적 부하만 줄이는 것(예: 자동 완성). 남는 부분을 본질적 부하에 할애할 수 있으므로 학습에 효과적입니다. - 인지 아웃소싱 (사고 위임): 본질적 부하 자체를 AI에게 맡겨버리는 것(Kirschner의 정의). 그 결과, 학습 관련 부하가 발생하지 않아 지식이 전혀 정착되지 않습니다.

이 사고 위임으로 인해 발생하는 것이 '인식적 부채(Epistemic Debt)'입니다.

겉보기에는 작동하는 코드를 빠르게 작성할 수 있지만, 고장 났을 때 스스로 고치지 못하는 '취약한 전문가(fragile experts)'가 만들어집니다.

4. 현재 시점에서 권장되는 AI 활용법

연구 데이터에 기반한 '효과적인 접근 방식'과 '비효율적인 접근 방식'을 정리했습니다.

상세 설명

1. '손으로 다시 입력하기(필사)'는 효과가 없다

생성 코드를 손으로 다시 입력한 그룹과 직접 붙여넣은 그룹 사이에 이해도 테스트 점수에 명확한 차이는 없었습니다. 괜히 시간을 소비할 뿐이므로, 손을 움직이기보다는 '머리를 움직이는 것(개념 이해)'에 시간을 사용하세요.

2. 설명을 요구하는 쿼리를 섞기

논문(論文)의 VibeCheck는 VS Code 확장 기능이지만, Claude Code에서도 같은 발상을 구현할 수 있습니다. 여기서 주의해야 할 점은, '규범을 작성하는 것'과 '적용을 막는 것'이 별개의 메커니즘이라는 점입니다. VibeCheck가 77%→39%(AI 제거 후 버그 수정 실패율)를 기록한 것은, '합격할 때까지 적용을 거부하는' 강제력이 있었기 때문입니다. 규범을 선언만 했다고 해서 이 수치가 나오지는 않습니다.

5.1 강제력의 계층 (Hierarchy of Enforcement)

Claude Code의 설정 메커니즘을 설명 게이트(explanation gate)로서의 강제력으로 나열하면 다음과 같습니다.

CLAUDE.md에 '코드를 적용하기 전에 인과 로직을 언어화할 것'이라고 적는 것만으로는 바쁠 때나 긴 대화의 끝에서 건너뛰기 쉽습니다. VibeCheck가 확장 기능으로 구현되었던 이유와 마찬가지로, 적용 경로 자체를 막지 않으면 설명은 생략됩니다.

하지만 이 표는 강제력만을 나열한 것입니다. 역할은 또 다른 축으로 나뉘어 있습니다. hook이 보이는 것은 '작성했는지 여부'에 불과하며, 무엇을 작성하게 할지를 결정하는 것은 rules/ 측입니다. 공식 문서도 이러한 분담을 그대로 설명합니다.

Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead [1]。

한쪽만으로는 부족합니다. rules/는 내용을 정할 수 있지만 막을 수는 없고, hook은 막을 수 있지만, 종류별 깊이(depth)에 따라 움직일 수 없기 때문에, 두 가지를 조합합니다.

Claude Code의 공식 문서는 PreToolUse hook의 exit 2를 Blocks the tool call로 정의하고, stderr text is fed back to Claude as an error message라고 명시하고 있습니다[2]. 게다가 exit 2는 permission rule의 평가보다 먼저 작동합니다 (stops the tool call before permission rules are evaluated [3]). 따라서 Edit을 allow에 넣어 확인 절차를 생략하는 환경에서도 막힙니다. 여기에 들어가는 메커니즘이, 기사에서 말하는 '설명 게이트'의 Claude Code 버전이 됩니다.

5.2 구현 (Implementation)

세 개의 파일을 배치합니다. 무엇을 작성하게 할지를 결정하는 rule, 종류별 관점을 추가하는 rule, 그리고 작성했는지 여부를 보는 hook입니다.

1. 범용적인 3축 (항상 로드되는 rule)

~/.claude/rules/explain-before-apply.md는 paths를 가지고 있지 않기 때문에, 세션 시작 시 반드시 로드됩니다.

---
name: explain-before-apply
description: 코드를 적용하기 전에, 차이점(diff)의 이유를 작성한다.
...

3축은 각각 다른 것을 묻습니다. 1은 차이점을 읽고 재구성할 수 있는지, 2는 배제한 선택지를 말할 수 있는지, 3은 실패했을 때의 대비책을 생각해낼 수 있는지를 묻습니다. 1만 답변되고 2와 3이 빈칸인 설명은 흔하며, 그럴 때 손에 남는 것은 작동하는 코드와 고칠 수 없는 자신입니다.

보충 설명입니다. 이 수치가 무엇에 대해 부여된 것인지를 정확히 적어둡니다.

VibeCheck가 채점한 것은 React의 상태 업데이트(State Update)에 대한 설명이며, 77%→39%라는 수치는 그 형식에 부여된 결과입니다. 위의 3개 축 자체는 실험의 직접적인 검증 대상이 아닙니다. 2번 항목이 VibeCheck가 말하는 '인과 로직 (Causal Logic)'에 가장 가깝지만, 실증 데이터를 이 3개 축으로 바꿔서 적용하지 마십시오. 1.2절에서 효과가 나타난 것은 'LLM이 채점하여 합격할 때까지 거부하는 루프 (Loop)'입니다. 요구하는 관점을 늘리는 것 자체에 근거가 있는 것은 아닙니다.

2. 종류별 관점 (path-scoped rule)

paths:

frontmatter를 가진 rule은 일치하는 파일을 Claude가 읽는 시점에 로드됩니다. glob 매칭은 Claude Code 측에서 담당하므로, hook은 glob을 일절 해석하지 않습니다.

---
name: explain-terraform
description: .tf를 적용하기 전에 추가로 작성할 것.
...

나머지 종류별 관점은 다음과 같습니다. 이것은 hook이 읽는 설정 데이터가 아니라, 자신의 rule을 작성하기 위한 출발점입니다. 열거형이므로 반드시 누락되는 부분이 생깁니다. 본인이 다루는 종류를 추가하십시오.

| 다루는 것 |
|---|---|
| migration / SQL | 불가역성 여부, 기존 행에 미치는 영향, 락 (Lock) 필요 여부 |
| ... |

rule이 실제로 로드되었는지는 InstructionsLoaded를 hook에서 로그로 남기거나, 세션 중에 /context의 Memory files를 확인하여 확인할 수 있습니다.

3. 작성 여부를 확인하는 hook

~/.claude/hooks/explain-gate.sh에 두고, ~/.claude/settings.json에 등록합니다.

#!/bin/bash
# ~/.claude/hooks/explain-gate.sh
#
...

`)) then .fence = (.fence | not)
elif (.fence | not) and ($ln | test($re)) then .hit = true
else . end)
| .hit
' "$TRANSCRIPT") || exit 0 # jq가 실패하면 통과 (중단하는 것은 판정이 가능할 때뿐)
[ "$GATE" = "true" ] && exit 0
cat >&2 <<'EOF'
적용을 중단했습니다. 이 차분(diff)을 적용하기 전에 "## 왜 이 차분이 필요한가"라는 헤더를 세우고,
다음 3가지 사항을 자신의 언어로 작성하십시오. 작성할 수 없다면 아직 이해하지 못한 것입니다.

1. 이 차분이 받는 것과 반환하는 것, 통과하는 경로
2. 가능한 다른 작성 방식을 하나 들고, 그것을 택하지 않는 이유
3. 오류가 발생했을 때, 무엇이 실패하고 누가 어디에서 알아차리는가
   규범의 정본은 ~/.claude/rules/explain-before-apply.md 입니다.
   판정은 이전 응답의 텍스트를 참조하므로, 설명을 작성한 다음 응답에서 편집을 다시 요청하십시오.
   급한 경우에는 touch ~/.claude/.skip-explain-gate-once 명령으로 딱 한 번만 통과할 수 있습니다.
   종류별 관점을 담은 rule (해당하는 것을 직접 선택):
   EOF
   ls "$HOME"/.claude/rules/explain-*.md >&2 2>/dev/null
   exit 2

`settings.json`

```json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write|MultiEdit|NotebookEdit",
"hooks": [
{ "type": "command", "command": "${HOME}/.claude/hooks/explain-gate.sh" }
]
}
]
}
}

hook의 stderr에도 3개 축을 적어둔 것은 중복이지만 의도적인 것입니다. rule이 로드되지 않은 상태에서도 중단된 이유만은 전달될 필요가 있기 때문입니다. 종류별 관점은 hook 측에 두지 않고, ls...

printf '%s' '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"ask","permissionDecisionReason":"적용 전 설명이 없습니다. 이 차이점이 무엇을 하는지, 잘못되었을 때 무엇이 실패하는지 확인하십시오."}}'
exit 0

하지만 이 방식조차 인간은 다이얼로그에서 승인 버튼을 누를 뿐입니다. VibeCheck가 수행했던 "인간 스스로 설명을 쓰게 하는 것(SOLO 레벨 3 평가)"을 완전히 재현하기에는 부족합니다. 여기서 추가할 수 있는 것은 "인간이 손을 멈추고 확인하는 단계"까지입니다.

...

편집을 내보내기 직전에 실행하여, 나오는 것이 방금 작성한 텍스트인지 아니면 바로 이전 응답의 텍스트인지 확인한다

jq -rn -R '[inputs|fromjson?|select(.type=="assistant")|.message.content[]?|select(.type=="text")|.text]|.[-1][0:40]'
~/.claude/projects/<project>/<session-id>.jsonl

#### ③ 구조적인 허점과 한계

...

(개념 예시) 판정을 통과한 설명 텍스트를 별도 프로세스의 Claude에 전달하여 JSON 채점을 시킴

claude -p "다음 설명문이 SOLO 레벨 3 (인과 로직의 통합적 설명)을 충족하는지 채점해 주세요"
--output-format json
--json-schema '{"type":"object","properties":{"passed":{"type":"boolean"}},"required":["passed"]}'
--append-system-prompt-file "$HOME/.claude/rules/explain-before-apply.md"
--bare

※ `--bare` 옵션은 자신의 hook이나 `CLAUDE.md`에 의한 무한 루프를 방지합니다. 다만 subscription login을 사용하지 않으므로, 별도로 `ANTHROPIC_API_KEY` 설정이 필요합니다. 트레이드오프(Trade-off)도 있습니다. 편집 1회당 수 초의 레이턴시(Latency)와 API 비용이 발생하며, API 에러 발생 시 통과시킬지 차단할지(fail-open / fail-closed)를 결정해야 합니다.

#### ⑤ 단계적 도입 (모니터링 모드) 권장

이러한 허점이나 오탐(False Positive)이 있으므로, 사용 초기 며칠 동안은 적용을 중단하지 않는 형태로 테스트하는 것을 추천합니다.

스크립트 끝부분의 `cat >&2 ... exit 2`를 로그 파일에 추가하는 방식(`echo ... >> gate.log`)과 `exit 0`으로 바꾸면, 개발을 중단하지 않고 "어떤 편집이 걸렸는지"에 대한 로그만 수집할 수 있습니다. 자신의 편집 습관이나 파일 구성에서의 오검출률을 확인한 후, `exit 2`에 의한 차단으로 이행하는 것이 안전합니다.

그럼에도 불구하고, `rules/`와 `hooks/`를 쌍으로 두는 차이는 클 것입니다. **"여기서 손을 멈추고 이유를 써라"를 바쁜 와중에도 반드시 거치게 하는 구조**가 도입되며, 무엇을 쓸지는 다루고 있는 대상에 따라 달라집니다. VibeCheck가 가져온 것은 아마도 이 '경유의 강제성' 부분일 것입니다.

## 마치며

무작위 대조 시험(RCT)을 통해 알 수 있는 결론은 단순합니다.

- 새로운 지식을 배우는 과제에서, AI에게 통째로 맡기는 것은 **학습량을 줄이고 속도 또한 향상시키지 못한다**.
- 코드를 적용하기 전에 **인과 로직을 언어화하여 이해하면**, 이후의 실패율이 대폭 낮아진다 (AI 제거 후 버그 수정 실패율이 77% → 39%로 감소).
- 코드를 그대로 베껴 쓰는 것(사경)은 의미가 없다. 시간을 들여야 할 곳은 "**설명의 확인**"과 "**에러의 자력 분석**"이다.

AI에게 효율화를 맡기면서도 자신의 머릿속에 지식을 남기고 싶다면, "**에러가 나오면 먼저 스스로 읽기**", "**생성된 코드의 로직을 한 문장으로 설명해 보기**"와 같은 작은 습관부터 시작해 보세요.

## 참고 문헌

## 참고 문헌

- 
**Shen & Tamkin (2026)**:
*How AI Impacts Skill Formation*
*(arXiv:2601.20245)* — 52명 RCT, 4.15점 차이, d=0.738, 소요 시간 p=0.391, 참여 패턴 분석 등. (PDF 원본 참조) -
**Sankaranarayanan (2026)**:
*Mitigating "Epistemic Debt" in Generative AI-Scaffolded Novice Programming using Metacognitive Scripts*
*(arXiv:2602.20206)* — 78명 RCT, 실패율 77% 대 39%, 설명 게이트(VibeCheck)의 영향. -
**Kazemitabaar et al. (2023)**:
*Studying the effect of AI Code Generators on Supporting Novice Learners in Introductory Programming*
*(CHI 2023)* — 69명, 사전 능력과 AI 활용의 영향 비교. (PDF 원본 참조) -
**Baltes et al. (2026)**:"AI Slop의 끝없는 흐름": 개발자들이 AI 지원 소프트웨어 개발의 부담에 대해 논하는 방식
*(arXiv:2603.27249)* — 1,154건 게시물 분석. -
**Chen et al. (2026)**:
*Beyond the Commit: Developer Perspectives on Productivity with AI Coding Assistants*
*(arXiv:2602.03593)* — BNY Mellon 대규모 조사. -
**Sweller (1988) / Kirschner**: 인지 부하 이론 및 인지 오프로딩/아웃소싱에 관한 고찰. -
**Kosmyna et al. (2025) / Bastani et al. (2025) / Gerlich (2025)**: 다른 분야(에세이・수학・비판적 사고)에서의 간접 증거 데이터.

- 
How Claude remembers your project (2026-08 참조).

`paths`

frontmatter를 통한 path-scoped rule과, `Path-scoped rules trigger when Claude reads files matching the pattern, not on every tool use`

의 기술도 같은 페이지에 있음. ↩︎ -
Claude Code Hooks reference (2026-08 참조).

`exit 2 = blocking error`

, PreToolUse에서는 `Blocks the tool call`

. ↩︎ -
Claude Code Permissions (2026-08 참조)의 Extend permissions with hooks.

`permissionDecision`

은 `allow` / `deny` / `ask` / `defer`

. ↩︎ ↩︎

### 논의 (Discussion)

![](https://static.zenn.studio/images/drawing/discussion.png)