掘金2026년 11월 5일 19:07중국어 → 한국어

AI로 새 라이브러리 배우면 숙달도 40%…입력·가공·보존 재설계

AI가 답을 쉽게 주는 대신 무엇을 물을지가 비싸졌다며, Anthropic 52인 대조실험과 검색 연습 실험을 근거로 입력·가공·보존 3단계 학습법을 제시했다.

중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.

내 로컬에는 DDD 칼럼 Markdown 71편이 놓여 있다. 《DDD实战课》 26편, 《手把手教你落地DDD》 45편으로, geektime-dl로 내려받은 것이다.

다운로드를 마친 그 순간의 느낌은 마치 다 배운 것 같다. 이 두 가지 사이에는 인과관계가 없다. 가공과 검색을 하지 않으면 그것들은 그저 71개의 파일일 뿐이다. 나는 검증할 수 있다. 언제든 열 수는 있지만, 주문 애그리거트의 경계를 어느 계층에 그어야 하는지 나는 말할 수 없다.

같은 시기 Anthropic의 대조 실험(2026년 초): 52명의 개발자가 낯선 Python 비동기 라이브러리 Trio를 배웠는데, AI를 사용한 그룹은 이후 테스트에서 평균 50점, 직접 작성한 그룹은 67점이었다. AI 그룹은 약 2분만 빨랐을 뿐 통계적 유의성은 없었다.

두 가지 사실은 같은 한 가지를 가리킨다. 답을 얻는 비용은 내려갔지만, 답을 자신의 능력으로 만드는 비용은 그대로다. 더 곤란한 것은, 답이 너무 쉽게 얻어지다 보니 우리가 '내가 무엇을 모르는지'조차 물어볼 수 없게 되었다는 점이다.

이 글은 내가 다시 만든 이후의 프로세스를 제시한다. 입력, 가공, 보존의 세 단계이며, 각 단계마다 그대로 따라 할 수 있는 산출물이 하나씩 있다. 파일, 프롬프트, 일주일에 한 번 하는 일정이다.

먼저 증거의 경계를 분명히 긋자

이것은 앞에 써야 한다. 아래 두 숫자가 가장 전달 과정에서 왜곡되기 쉬운 탓이다.

- 17%라는 격차의 기준은 이렇다. 52명의 참가자(다수가 초급 Python 개발자), 단일 과제 약 1시간, 측정한 것은 과제 종료 직후의 즉각적 이해도다. 이것은 'AI를 장기간 사용하면 능력이 17% 떨어진다'는 것과 같지 않다. 장기적인 기술 형성에 관해서는 데이터가 없으며, 있다고 말하는 사람은 지어내는 것이다.

- 6가지 상호작용 모드의 등급 구분은 51명 참가자의 화면 녹화 자료에 대한 정성 분석에서 나온 것으로, 상관관계이지 인과 실험이 아니다. 연구자 자신도 그렇게 말한다. 그래서 뒤에서 나는 '추궁형 질문법을 쓰면 반드시 고득점을 받는다'라고 쓰지 않고, '고득점 구간에 있는 사람들은 모두 이 몇 가지를 하고 있다'라고만 쓴다.

- Roediger & Karpicke의 실험 재료는 산문 단락이지 프로그래밍 기술이 아니다. 기술 학습으로의 전이는 나의 판단이자 나 자신의 실천이지, 엔지니어 표본의 실측 결론이 아니다.

- GeekTime + ima라는 툴체인은 나 자신의 선택이지 범용 최적해가 아니다. 뒤에서 판단 기준을 제시할 테니, 같은 조건을 충족하는 어떤 도구로든 바꿔도 된다.

- 이 글에는 허구의 수익 퍼센트도 없고, 허구의 독자 댓글이나 온라인 사고도 없다. '돌려봤다'는 모든 서술은 내 로컬에 실제로 존재하는 디렉터리와 스크립트다.

경계를 그은 뒤에야 나머지 부분이 믿을 만하다고 말할 수 있다.

답이 거의 무료가 되면서, 높아진 대가는 무엇인가

먼저 업계 측 숫자를 보자. 이것들은 이 일을 지금 반드시 다뤄야 하는 이유를 설명해 준다.

Stack Overflow의 2025년 12월 질문량은 3,862개로 전년 대비 78% 감소했다. 2014년 월간 최고치는 20만 개를 넘었다. 같은 시기 Stack Overflow 2025 개발자 설문에서 84%의 개발자가 AI 도구를 사용 중이거나 사용할 계획이라고 했는데, 2024년 이 숫자는 76%였다. 질문량이 학습량과 같지는 않고, 감소에는 커뮤니티 운영의 요인도 있지만 방향은 분명하다. 공개적으로 질문하는 이 행위가 사라지고 있다.

이 행위가 사라진 대가는 대부분이 생각하는 것보다 크다.

Stack Overflow에서 질문하는 것은 강제된다. 환경을 명확히 써야 하고, 재현 가능한 최소 단계를 써야 하고, 이미 무엇을 시도했는지, 오류 메시지의 완전한 정보를 써야 한다. 많은 사람이 비난받을 바보 같은 질문을 올리지 않으려고 게시 전에 스스로 한 번 더 찾아본다. 이 한 번이 바로 가공이다. 지금은 이 가공 단계가 건너뛰어진다. 당신은 AI에게 바로 묻고, AI는 바로 답을 주며, 중간에 그 단계가 없다.

게다가 AI가 주는 답의 품질은 대개 꽤 높아서, 자신이 이해하지 못했다는 것을 의심하지 않을 정도다.

거시적 측면의 압력도 동시에 커지고 있다. 세계경제포럼 《2025년 미래 일자리 보고서》(55개 경제권, 1000개 이상 기업 대상)에 따르면, 고용주는 2030년까지 39% 노동자의 핵심 기술이 바뀔 것으로 예상한다(2023년판은 44%). 장기 학습 전략 아래 훈련을 완료한 직원 비율은 2023년 41%에서 50%로 올랐다. 숫자는 고용주 예상 조사이지 실측이 아니고, 중국 표본도 별도로 공개되지 않았지만, 적어도 한 가지는 말해 준다. 지속적 학습은 이미 개인의 선택에서 직무의 요구가 되었고, 직무 요구는 AI를 썼다고 해서 낮아지지 않는다.

그리하여 학습이라는 일의 비용 구조가 바뀌었다.

다시 만들어야 하는 것은 뒤의 두 줄이지 첫 줄이 아니다. 이것이 이 글의 유일한 논점이며, 뒤의 세 단락은 모두 이것의 구체화다.

실험에서 실제로 격차를 벌린 것은 AI를 쓰느냐 마느냐가 아니다

같은 Anthropic 연구 안에 '50점 대 67점'보다 더 쓸모 있는 발견이 있다. 연구자는 참가자와 AI의 상호작용을 6가지 모드로 나누고, 점수를 두 구간으로 나눴다.

점수 차가 가장 큰 문항 유형은 디버깅 문항이었다. 이 세부 사항이 중요하다. 디버깅 문항은 API를 기억하는지를 묻는 것이 아니라, 현상에서 원인을 역추론할 수 있는지를 묻는다. 그리고 이것이 바로 AI가 대신해 버린 그 단계다.

연구자에게는 더 따끔한 관찰이 하나 더 있다. 대조군(직접 작성 그룹)은 Trio 특정 오류(TypeError, RuntimeWarning)를 더 많이 겪었고, 스스로排查해야 했던 횟수가 AI 그룹의 3배였다. 연구자는 이해 격차를 cognitive effort에 귀인했다. 그 '고통스럽게 막히는' 시간은 효율 손실이 아니라, 그 자체가 이해가 형성되는 메커니즘이다.

반직관적인 세부 사항도 하나 따로 말할 만하다. AI 그룹이 유의하게 더 빠르지도 않았고, 평균 약 2분만 빨랐다. 어떤 사람은 프롬프트를 쓰는 데만 11분을 써서 가용 시간의 30%를 차지했다. 즉, 위임형 사용법은 많은 경우 '시간을 아낀다'는 유일한 이유조차 성립하지 않는다.

그림 속 '위임형 → <40%'라는 화살표가 대응하는 것이 바로 이 세 가지다. 과정을 보지 않음, 원인을 보지 않음, 스스로 오류를 잡지 않음. 그리고 고득점 구간의 세 가지 모드에는 공통점이 하나 있다. 모두 AI가 '무엇인지'만이 아니라 '왜인지'를 출력하도록 요구한다.

이 문장은 뒤에서 그대로 복사할 수 있는 프롬프트가 된다.

세 단계법의 골격

나는 프로세스를 입력, 가공, 보존의 세 단계로 나눴고, 각 단계에는 확고한 산출물이 하나씩만 있다. 산출물은 이 단계를 실제로 했는지 판단하는 최저 기준이다. 끝냈지만 산출물이 없으면 안 한 것과 같다.

- 입력 → 산출물: questions.md, 지금 내가 설명하지 못하는 문제만 저장한다.

- 가공 → 산출물: 한 번의 되묻기 기록(AI의 답변 + 내가 먼저 쓴 답 + 채점).

- 보존 → 산출물: 일주일 뒤의 자체 테스트 결과, 그리고 답하지 못한 문제가 자동으로 topics.md 주제 풀에 들어간다.

‘보존’에서 ‘입력’으로 돌아가는 그 피드백 간선이 이 방법의 유일한 설계 요점이다. 답하지 못한 문제는 단순한 할 일 목록이 아니라, 바로 다음에 써야 할 글이다. 글쓰기는 인과 사슬 하나를 끝까지 채우도록 강제하며, 이는 내가 아는 가장 강력한 보존 수단이다. 나는 2021–2023년에 위챗 공식 계정에 40+편의 Redis 시리즈 글을 썼고, 3년째에 《Redis 高手心法》을 냈는데, 그 책은 기본적으로 그 글들의 부산물이다. 글쓰기는 유명해지는 수단이 아니라, 검색 연습의 고강도 형태다.

첫 번째 단계: 입력 — 답을 먼저 모으는 것이 아니라 문제를 먼저 생산하기

입력 단계에서는 세 가지를 한다: 정보원 고정, 단일 수신함, 문제를 먼저 쓰고 답을 찾기.

고정 정보원: 유료 칼럼 하나를 커리큘럼으로 삼기

나의 현재 정보원은 极客时间의 DDD 칼럼 두 개이며, 로컬 Markdown으로 내보낸다:

``` ~/Documents/magebyte/pay-columns/DDD/极客时间/ ├── DDD实战课/articles/ # 26편 ├── 手把手教你落地DDD/articles/ # 45편 ├── questions.md # 문제만 저장, 답은 저장하지 않음(새로 만듦) └── topics.md # 주제 풀, 답하지 못한 문제가 여기로 들어옴(새로 만듦) ```

고정 정보원은 ‘오늘 무엇을 배울까’의 의사결정 비용을 해결한다. 칼럼 하나에는 개요가 있고, 순서가 있고, 종착점이 있어서 그것은 바로 쓸 수 있는 커리큘럼이다. 반면 ‘아무거나 한 편 저장해 두기’에는 종착점이 없어서, 너는 그것을 다 배웠는지 영원히 알 수 없다. 71편은 셀 수 있고, 진도를 낼 수 있고, 완료할 수 있는 목표지만, 즐겨찾기는 그렇지 않다.

정보원을 고르는 기준은 단 하나다: 그것은 지금 네가 이해하지 못하는 내용이 절반쯤 되어야 한다. 전부 아는 내용이라면 너는 그저 복습하는 것이고, 전부 모르는 내용이라면 과부하가 걸릴 것이다(뒤의 ‘실패 경계’에서 다룬다).

단일 수신함: 파편은 한 곳에만 떨어져야 한다

모든 출처의 파편, 즉 위챗 공식 계정 글의 스크린샷, 동료가 말한 단어 하나, 오류 메시지, AI가 제시한 어떤 주장까지도 먼저 같은 파일에 떨어뜨리고, 분류하지 않고, 정리하지 않고, 보관하지 않는다. 분류는 가공 단계의 일이고, 입력 단계에서 분류를 하면 ‘수집’과 ‘사고’가 뒤섞여 둘 다 잘되지 않는다.

내 방식은 모든 파편을 먼저 questions.md의 ‘처리 대기’ 구역에 넣고, 일주일에 한 번 비우는 것이다.

입력 단계에서 분류를 하지 않는 이유는, 분류라는 행동이 네가 가진 유일하게 한정된 그 한 호흡을 소모하기 때문이다. 파편 하나를 두고 ‘이것을 데이터베이스에 넣어야 하나, 아키텍처에 넣어야 하나’를 생각할 때, 네 뇌는 이미 문제를 제기하는 것이 아니라 정리를 하고 있다. 그리고 그렇게 정리해 낸 디렉터리 구조는 결국 대개 즐겨찾기와 함께 묻힌다. 분류는 가공 단계로 남겨 두라. 그때는 이 파편이 어떤 문제와 관련 있는지 이미 알고 있으므로, 분류는 근거 있는 판단이지 더 이상 추측이 아니다.

문제를 먼저 쓰고 답을 찾기

이것은 입력 단계에서 유일하게 어려운 항목이자, 가장 쉽게 건너뛰는 항목이다.

어떤 글을 읽기 전에 먼저 ‘지금 내가 설명하지 못하는 것’을 적고, 그다음 읽어라. 순서를 바꾸면 안 된다. 반대로 하면, 너는 이미 읽은 자료를 가지고 문제를 끼워 맞추는 것이 되고, 그렇게 끼워 맞춘 문제는 이미 자료가 답해 버린 것이라 검색 연습이 무효가 된다(이유는 보존 단계를 보라).

questions.md의 형식은 내 경우 이렇게 쓴다:

``` # questions.md ## 2026-09-29 · DDD-실전 수업-제8강 - [ ] ‘주문 + 주문 항목’ 구조에서 애그리거트 루트는 주문이어야 할까, 주문 항목이어야 할까? 판단 근거는 무엇인가? - [ ] 경계 컨텍스트와 마이크로서비스는 1:1인가? 아니라면 어떤 경우에 이들을 분리해야 하는가? - [ ] 도메인 이벤트의 소비자는 같은 경계 컨텍스트로 간주하는가? ## 처리 대기(파편, 미정형) - 동료가 ‘트랜잭션 경계는 애그리거트를 넘지 말아야 한다’고 언급했는데, 그때 말을 잇지 못했다 — 왜? ```

세 가지 강한 규칙:

- 설명하지 못하는 문제만 쓰고, 답은 쓰지 않는다. 이 규칙은 가장 반직관적으로 보이는데, 이유는 두 가지다. 답은 만료되지만 문제는 그렇지 않다. ‘애그리거트 루트 경계는 어디에 그어야 하는가’라는 문제는 3년 뒤에도 여전히 성립하지만, 그 답은 이미 바뀌었을 수 있다. 더 결정적으로, 답과 문제를 함께 적어 두면 다음에 그것을 펼칠 때 답을 읽게 되고, 뇌는 ‘이 글자를 알아본다’를 ‘나는 안다’로 착각한다. 이것이 바로 Roediger & Karpicke 실험에서 반복 읽기 집단의 자신감은 더 높고 회상률은 더 낮았던 그 일이다. 문제 풀은 순수하게 유지되어야 하고, 답은 가공 기록에 남긴다.

- 각 문제는 두 줄을 넘지 않는다. 넘게 썼다면 네가 사실 어느 단계에서 막혔는지 아직 명확히 생각하지 못한 것이니, 자료로 돌아가라.

- 일주일 안에 답을 얻지도, 떠올리지도 못한 문제는 바로 삭제한다. 그것은 중요하지 않다. 그것을 삭제하는 행동 자체가 정보원에 점수를 매기는 일이다.

두 번째 단계: 가공 — AI를 답변 기계에서 되묻기 기계로 바꾸기

입력 단계에서 문제가 생산되었으니, 가공 단계의 목표는 이 문제들을 AI에게 넘기되, 돌려받는 것은 답이 아니라 더 많은 질문이 되게 하는 것이다.

아래 세 템플릿은 각각 실험에서 고득점 구간의 세 가지 모드에 대응한다: 개념만 묻기, 생성 시 설명 요구, 생성 후 되묻기. 세 번째 ‘AI에게 나를 검토시키기’는 내가 추가한 것으로, 검색 연습을 가공 단계에 직접 밀어 넣는다.

템플릿 1: 개념 질문(‘개념만 묻기’ 구간에 대응)

적용 상황: 새로운 용어를 접했고, 정의를 한번 보고, 이해한 것 같은 느낌이 들 때 — 이때가 가장 위험하다.

``` 나는 DDD를 배우고 있고, 현재 ‘애그리거트 루트’라는 단어의 문자적 정의만 알 뿐 사용해 본 적은 없다. 200자 이내로 답하라: 1. 먼저 ‘애그리거트 루트를 쓰지 않으면 구체적인 문제가 발생하는’ 시나리오를 제시하라. 시나리오에는 호출 순서나 데이터 구조가 있어야 하며, ‘데이터 불일치를 초래한다’ 같은 추상적 결과만 말하지 말라. 2. 다음으로 그것이 어떤 종류의 일관성 문제를 해결하는지 설명하고, 어느 코드 사이의 제약인지 지적하라. 3. 마지막으로 이 단계의 초보자가 높은 확률로 오해할 만한 점을 하나 달라. 요구 사항: ‘총적으로’ 같은 요약 문장으로 끝내지 말라; 어떤 주장이 업계에서 논쟁 중이라면 논쟁 중이라고 직접 말하고, 한 가지 관행을 표준 답안처럼 쓰지 말라. ```

세 번째 요구 사항이 핵심이다. AI는 기본적으로 매끄럽고 논쟁이 없는 답을 주지만, 논쟁점이야말로 네가 진짜 기억해야 하는 부분이다. 왜냐하면 그것은 지식의 위치가 아니라 판단력의 위치이기 때문이다.

템플릿 2: 생성 시 설명 요구(‘생성 시 설명 요구’ 구간에 대응)

적용 상황: 정말로 AI에게 코드를 작성하게 해야 하고, 그 코드를 실제로 사용할 때.

도와줘, 구현해 줘: <네 요구 사항>. 출력 규칙: 1. 단락별로 출력한다. 각 단락마다 먼저 「이 코드가 만족해야 하는 제약」을 한두 문장으로 쓰고, 그다음 코드를 쓴다. 2. 네가 확신하지 못하는 API 동작이나 버전 차이를 만나면, 바로 「여기는 내가 확신하지 못하니 네가 검증해야 한다」라고 쓰고, 짐작해서 어떤 식으로든 채워 넣지 마라. 3. 다 쓴 뒤에는 따로 한 절을 두어 「이번 구현에서 네가 아마 놓쳤을 두 가지 리스크」를 쓴다. 각 리스크는 구체적인 특정 줄에 대응할 수 있어야 한다. 그대로 복사해 갈 수 있는 구현만 던져 주고 설명은 하지 마라.

2번째 조항이 가장 가치 있다. AI의 기본 동작은 채워 넣기이고, 그렇게 채워 넣은 API 시그니처는 환각인 경우가 많다. 불확실한 부분을 명시적으로 표시하게 하는 것은 「내가 검증해야 할 지점」을 너 자신의 검색 목록으로 바꾸는 것과 같다.

템플릿 3: 생성 후 되묻기 (「생성 후 되묻기」 항목에 대응)

적용 장면: AI가 이미 구현을 줬고, 너는 그것을 받아들이려는 참이다. 이 템플릿이 바로 그 단계의 브레이크다.

이건 네가 방금 내게 준 구현이다: <코드 붙여넣기> 나는 이걸 그대로 고칠 생각이 없다. 순서대로 답해라: 1. N번째 줄은 왜 반드시 이렇게 써야 하는가? 내가 그걸 지우면 어떤 구체적 결과가 생기는가(무슨 에러가 나고, 데이터가 어디서 틀리는가)? 2. 이 코드는 어떤 입력에서 틀리는가? 그걸 촉발하는 최소 입력을 내게 줘라. 3. 내가 동시성 양을 한 자릿수(10배) 높이면, 어느 줄이 먼저 문제를 일으키는가, 왜 그것인가? 4. 마지막으로, 이 코드로 나를 시험할 수 있는 문제를 하나 내라. 내가 먼저 답을 써서 너에게 주면, 너는 내가 맞는지 틀리는지 판정하고, 틀린 부분은 내 추론의 어느 단계에서 틀렸는지 직접 지적해라.

4번째 조항은 가공 단계와 보존 단계를 이어 붙인다: AI가 낸 문제가 바로 일주일 뒤 자체 테스트의 문제 출처다. 그리고 순서는 「내가 답을 쓴다 → AI가 판정한다」이지, 「AI가 답을 준다 → 내가 본다」가 아니다.

템플릿 4: AI에게 나를 심사시키기 (내가 쓰고, AI가 판정한다)

이건 실험의 여섯 가지 모드에 없는 것으로, 내가 직접 추가한 것이고, 네 템플릿 중 가장 힘든 것이다.

다음은 「<어떤 개념>」에 대한 내 이해다. 내가 직접 쓴 것이지, 네가 생성한 것이 아니다: <내가 직접 쓴 이해 한 단락 붙여넣기> 세 가지를 해라, 내가 한 말을 되풀이하지 마라: 1. 그중 사실적 오류를 하나하나 지적하고, 각각에 반례를 하나씩 대라. 2. 어디가 내가 그저 용어를 되풀이했을 뿐 메커니즘을 설명하지 않은 곳인지(그런 곳은 사실상 내가 이해하지 못한 것) 지적해라. 3. 「내 이 이해가 무효가 되는」 구체적 장면을 하나 내게 줘라. 마지막으로 판단을 하나 줘라: 이 이해를 코드 리뷰에서 말한다면, 어떤 두 가지 질문을 받게 될까? 만약 그 두 질문에 내가 답하지 못한다면, 내게 부족한 것이 어느 인과 사슬인지 직접 설명해라.

입력은 네가 먼저 쓴 것이라는 점에 주목하라. 이 단계는 건너뛸 수 없다 — AI가 심사하는 것은 네 이해이고, 만약 그 이해가 AI가 쓴 것이라면 심사하는 것은 AI 자기 자신이니, 아무것도 심사해 낼 수 없다.

써낼 수 없으면 어떻게 하나? 써낼 수 없다는 것 자체가 결과다: 아직 이해하지 못했다는 뜻이니, 돌아가서 자료를 읽어라. 이것이 이 절차에서 유일하게 「해내지 못해도 유효한 산출」인 고리다.

네 가지 템플릿은 같은 일을 하고 있다

위 네 가지 프롬프트를 나란히 놓고 보면, 공통 구조가 있다: 모두 「답을 산출하기」를 「한 번의 능동적 출력을 끌어내기」로 바꾼다.

- 템플릿 1이 먼저 장면과 반례를 주라고 요구하는 것은, 추상적 결론은 검증될 수 없기 때문이다; 장면이 있어야 네가 그것을 정말 쓸 줄 아는지 판단할 수 있다.

- 템플릿 2가 AI에게 불확실성을 표시하라고 요구하는 것은, 「내가 무엇을 검증해야 하는가」라는 판단을 너에게 남겨 두는 것이다.

- 템플릿 3이 너를 시험할 문제를 내라고 요구하는 것은, 가공 단계의 종점을 보존 단계의 기점에 연결하는 것이다.

- 템플릿 4가 AI에게 네가 쓴 것을 판정하라고 요구하는 것은, 「내가 정말 이해했는가」를 한 번 부정될 수 있는 출력으로 바꾸는 것이다.

이 네 가지 모두 실험에서의 그 귀인(귀속)에 대응한다: 이해 격차는 cognitive effort에서 온다. 위임형 사용법이 40% 이하로 떨어지는 이유는 AI가 주는 코드가 나빠서가 아니라, 전체 과정에서 네가 능동적 출력을 한 번도 만들어 내지 않았기 때문이다 — 짐작하지도, 판단하지도, 틀리지도 않았다.

한 가지 당부: 템플릿 3의 4번째 조항(「나를 시험할 문제를 내라」)이 가장 건너뛰기 쉬운데, 가장 쓸모없어 보이고, AI가 낸 문제를 네가 그 자리에서 풀지도 않기 때문이다. 그러나 그것은 네 템플릿 중 유일하게 간격을 스스로 갖춘 것이다 — 그 문제는 일주일 뒤 자체 테스트에서 너를 기다린다. 이 조항을 하지 않으면, 가공 단계와 보존 단계가 끊어진다.

가공 단계의 세 가지 강제 조건

- 먼저 스스로 한 번 써 보고, 그다음 AI의 답을 본다. 순서가 뒤바뀌면 너는 교정을 하는 것이지 검색을 하는 것이 아니다.

- AI의 답은 questions.md에 넣지 않고, 가공 기록에만 넣는다. questions.md는 문제 풀이니 순수하게 유지해야 한다, 그렇지 않으면 노트 창고로 퇴화한다.

- 한 번에 하나의 문제만 가공한다. 내 자신의 버릇은 대화창을 열면 한꺼번에 다섯 개를 묻고 싶어 하고, 다섯 개를 다 물으면 하나도 기억하지 못한다는 것이다. 이것은 개인 습관 차원의 관찰이지 실험 결론이 아니다.

왜 「지식 베이스를 구축했다」가 보존 문제를 해결했다는 뜻이 아닌가

보존 단계를 말하기 전에, 거의 모든 사람이 빠지는 혼동 하나를 먼저 분리해 내야 한다. 기술인들은 이 2년간 온갖 창고를 지었다: 즐겨찾기, Notion, Obsidian, ima, AI가 자동 생성한 독서 노트. 이런 투자가 쓸모없는 것은 아니지만, 각각은 문제의 절반만 해결한다.

「찾을 수 있다」와 「떠올릴 수 있다」는 두 가지 일이다. 전자는 외부 저장 문제로, 도구로 해결하며, 게다가 도구는 이미 아주 잘 해결해 두었다 — 의미 검색은 네가 석 달 전에 쓴 노트 한 토막을 뜻으로 찾아낼 수 있고, 이 일은 예전에는 불가능했다. 후자는 네 뇌 속의 검색 경로 문제로, 네가 스스로 성공적으로 꺼내 본 횟수에 달려 있고, 도구는 도울 수 없다.

내 그 71편 DDD의 상태가 바로 전형적인 「찾을 수 있지만 떠올릴 수 없다」다: 「애그리거트 루트」를 검색하면 결과가 나오지만, 빈 종이에는 써낼 수 없다. 그래서 아래 판단들은 나눠서 봐야 한다:

표의 마지막 줄은 왜 내가 「답하지 못한 문제를 바로 글쓰기 주제로 바꾸기」를 절차의 시작이 아니라 끝에 두었는지 설명한다: 글쓰기의 보존 효과가 가장 강하지만 비용도 가장 높아서, 가치 있는 문제만 그것을 쓸 자격이 있다.

세 번째 단계: 보존 — 보존은 검색에 달려 있지, 다시 읽기에 달려 있지 않다

이 단락은 대다수 사람의 전체 절차에서 완전히 빠져 있는 단락이다.

Roediger & Karpicke (2006)가 Psychological Science 17(3):249-255에 발표한 실험: 한 자료를 학습한 뒤, 반복 읽기를 4회 한 집단은 일주일 뒤 회상률이 약 40%; 학습 1회 + 자유 회상 테스트 3회를 한 집단은 약 60%였다. 더 기억할 만한 것은 두 번째 발견이다: 반복 읽기 집단이 자기 기억 효과에 대한 자신감이 더 높았다.

엔지니어의 언어로 번역하면 이렇다. 네 번째 읽을 때쯤이면 '이건 익숙해'라는 느낌이 든다. 그 느낌은 친숙함이지 인출 능력이 아니다. 친숙함은 반복 접촉에서 오고, 인출 능력은 성공적인 꺼내기에서 온다. 이 두 가지는 뇌 안에서 같은 메커니즘이 아니다. Adesope 등이 2017년에 118개 연구를 대상으로 한 메타분석에서 제시한 효과 크기는 Hedges' g = 0.51로, 중간보다 조금 높은 수준이다. 신비한 게 아니다.

Bjork의 desirable difficulties(바람직한 어려움) 프레임은 왜 이렇게 하면 오히려 더 어려운지를 설명한다. 연습 중에 적당한 난이도(간격, 교차, 인출)를 더하면 장기 기억 유지와 전이가 향상되지만, 연습 당시의 수행은 떨어지고, 게다가 학습자는 대체로 그것이 효과가 없다고 오판한다(Schmidt & Bjork 1992; Kornell & Bjork 2007/2008). 그래서 이 절차가 당신을 멍청하게 만든다고 느끼겠지만, 이는 예상된 반응이지 방법이 틀린 게 아니다.

구체적인 동작으로 옮기면, 일주일에 한 사이클이다:

단계 1: 자료를 덮고, 자유 회상하기

한 편을 다 읽거나 한 번의 가공을 마친 뒤, 모든 창을 닫고 빈 파일에 쓴다. 이 편이 무엇을 말했는지, 내가 어느 항목까지 다시 말할 수 있는지, 어느 항목은 완전히 말하지 못하는지.

자료를 펼치지 말 것. 펼치면 이 단계는 없어진다. 쓰지 못한 부분은 채우지 않아도 된다. 빈칸이 곧 자가 테스트 문제다.

단계 2: '다음 주에 내가 또 틀릴' 질문 3개 쓰기

빈칸에서 3개를 골라 questions.md에 적고 타임스탬프를 찍는다. 이 세 질문의 기준은 '중요함'이 아니라 '다음 주에도 내가 십중팔구 답하지 못할 것'이다.

중요하지만 이미 아는 문제를 고르는 것은 자신을 속이는 것과 같다.

단계 3: 일주일 뒤, 내 노트로 검색해 자가 테스트하기

일주일 뒤, ima의 의미 검색으로 내가 쓴 노트를 불러오되, 검색은 노트를 찾기 위한 것이지 답을 보기 위한 것이 아니다. 그 단락을 찾은 뒤 검색 결과를 닫고, 먼저 답을 쓴 다음 다시 열어 대조한다.

내 라이브러리는 이렇게 구축했다. 공식 계정에 쓴 글과 이미지는 wechat-column/.workbuddy/sync-to-ima.cjs로 ima의 '码哥跳动公众号' 라이브러리에 증분 동기화하고, DDD 71편 칼럼 Markdown은 따로 업로드했으며, 디렉터리는 읽기 쉬운 중국어로 명명했다. 두 무리의 콘텐츠가 같은 계정 아래에 있어 검색할 때 함께 불러올 수 있다. 동기화에 쓴 명령은 이렇다:

node .workbuddy/sync-to-ima.cjs --kb-id <지식베이스ID> --root /path/to/wechat-column

이 스크립트의 세 가지 특성이 이 단계에 적합하게 만든다:

- 이어받기(중단점 재개): state 파일에 이미 업로드한 상대 경로를 기록해 두어, 같은 명령을 다시 실행하면 이어서 올린다. 어디까지 올렸는지 기억할 필요가 없다.

- 빈도 제한과 재시도: 빈도 제한 오류 코드 200001을 만나면 지수 백오프로 재시도하고, 220021(일일 할당량)을 만나면 당일에는 진행할 수 없으니 거기서 멈추고 다음 날 이어서 실행한다.

- 디렉터리 계층 인코딩: 업로드에 쓰는 표시명은 상대 경로의 /를 __로 바꾼 것으로, 계층이 사라지지 않는다(articles/092-xxx.md가 들어가도 여전히 어느 계층에 있는지 알 수 있다).

덧붙여 그 범위를 분명히 해 둔다. 이 스크립트는 articles/*.md와 images/ 아래의 이미지만 스캔하며, DDD 칼럼 파일들은 그 스캔 범위에 없어 따로 올렸다.

세 번째 특성이 내가 이것을 고른 진짜 이유다. 검색 결과는 반드시 내 원문으로 되돌아갈 수 있어야 한다. 어떤 지식베이스가 요약 한 단락만 줄 수 있다면, 그것은 '찾을 수 있음'만 해결할 뿐 '떠올릴 수 있음'은 해결하지 못한다.

다른 도구로 바꿔도 충분히 성립하며, 판단 기준은 세 가지뿐이고 하나라도 빠지면 이 자리에 두기에 적합하지 않다:

- 안에 저장된 것이 당신이 직접 쓴 노트여야 한다. AI가 생성한 요약이나 스크랩한 글이 아니라.

- 의미 검색을 지원해야 한다. 키워드 정확 매칭만이 아니라 뜻으로 찾을 수 있어야 한다.

- 검색 결과가 원문으로 넘어갈 수 있어야 한다. 원문을 보며 자기 답이 맞는지 판정할 수 있어야 한다.

Obsidian에 전문 검색 플러그인을 더하면 이 세 가지를 충족하고, Notion의 AI 검색은 앞의 두 가지는 충족하며 세 번째는 어떻게 저장하느냐에 달려 있고, ima는 세 가지를 충족하면서 번거로움이 적다. 도구는 중요하지 않고 이 세 가지가 중요하다.

자가 테스트는 어떻게 판정하나: 세 가지 합격선

'맞혔는지 아닌지'는 스스로 쉽게 봐주게 된다. 나는 세 가지 엄격한 기준을 쓰고, 세 가지를 모두 충족해야 그 문제가 통과다:

- 인과 사슬을 말할 수 있어야 하고, 결론만 말해서는 안 된다. '컨텍스트 간에는 동기 호출을 쓸 수 없다'는 결론이고, '동기 호출은 두 컨텍스트의 트랜잭션을 묶어 버려 하나가 죽으면 다른 하나도 함께 쓸 수 없게 되는데, 컨텍스트를 나누는 목적이 바로 이런 연쇄를 끊는 것이기 때문'이 인과 사슬이다.

- 반례 또는 실패 시나리오를 하나 제시할 수 있어야 한다. '언제 이렇게 쓰면 안 되는지'를 말할 수 없다면, 당신이 기억한 것은 이해가 아니라 규칙이다.

- '만약 …라면 어떻게 될까'라는 되물음에 답할 수 있어야 한다. 자가 테스트 때 나는 추가로 '동시성이 한 자릿수 더 높아지면 이 결론이 여전히 성립하는가'라고 묻는다. 답하지 못하면 이 문제는 통과로 치지 않는다.

세 가지 중 어느 하나라도 빠지면 그 문제는 topics.md로 들어가고 '이미 습득'에는 들어가지 않는다.

단계 4: 답하지 못한 것은 다음 편 주제로 전환

자가 테스트 판정이 끝난 뒤, 틀린 문제는 문제 풀에서 맴돌게 두지 않고 바로 topics.md로 넣는다:

topics.md · 주제 풀 ## 작성 예정 - [ ] 도메인 이벤트의 소비자는 대체로 같은 경계 컨텍스트로 봐야 하나? · 왜 답하지 못했는가: '컨텍스트 경계'가 팀 단위로 나뉘는지 트랜잭션 일관성으로 나뉘는지 헷갈린다 · 보충해야 할 인과 사슬: 왜 컨텍스트 간에는 이벤트만 쓸 수 있고 동기 호출은 쓸 수 없는가 · 출처: 2026-09-29 자가 테스트, 두 번째 오답 ## 작성 완료 - [x] 애그리거트 루트 경계는 어떻게 그어야 하나 → 공식 계정 글(제목과 링크는 이 줄에 보충)

'왜 답하지 못했는가' 칸은 필수다. 그것은 '나는 못한다'를 '나는 어느 인과 사슬이 빠졌다'로 바꾼다. 후자는 보충할 수 있는 구체적인 것이고, 전자는 그저 감정이다.

주제 풀에 들어간 문제는 글로 써지고, 글쓰기는 다시 한 번 강도가 더 높은 인출 연습이다. 내 40여 편의 Redis 글이 바로 이렇게 나왔고, 3년째에 《Redis 高手心法》으로 쌓였다. 이것은 감동적인 이야기가 아니라, 이 절차가 내 안에 유일하게 흔적을 남긴 부분이다. 내가 그때 쓴 것은 지금도 말할 수 있지만, 그저 본 것들은 이미 남아 있지 않다. 이 대비는 정량적 데이터로 뒷받침되지 않으며, 그저 내 경험일 뿐이니 당신은 자신의 기록으로 검증해야 한다.

내 실패 상태, 솔직히 말하면

이 단락을 쓰지 않으면 위의 전체가 마치 내가 처음부터 끝까지 생각해 낸 것처럼 보일 것이다. 실제로는 아니다.

내 실제 상태는 이랬다. 71편의 Markdown을 다운로드하고, 그것들을 지식베이스에 동기화했고, 그다음 꽤 오랜 시간 동안 아무 일도 일어나지 않았다. 검색에서 '애그리거트 루트'라는 단어가 어느 편에 나오는지는 찾을 수 있었지만, 백지에 '한 주문의 애그리거트 경계를 어떻게 정하는가'를 쓰라고 하면 쓰지 못했다.

문제는 제가 ‘저장했다’를 ‘배웠다’로 착각한 데 있었습니다. 이 두 가지 사이의 격차가 바로 Roediger & Karpicke가 말한 40%와 60%의 격차입니다. 반복적인 접촉은 친숙함을 낳지만, 인출 능력은 낳지 않습니다. 제가 가진 71편은 자료를 첫 번째로 읽은 것에 해당하며, 그 뒤로 계속 두 번째, 세 번째 읽기를 기다리고 있었던 셈입니다.

고친 동작은 딱 두 가지였고, 둘 다 아주 작습니다.

- questions.md를 하나 만들고, 여기에는 답은 저장하지 않고 질문만 저장한다고 정합니다.

- 매주 월요일 저녁 20분을 들여, 자료를 덮고 한 번 자유 회상을 합니다.

이게 전부입니다. 도구 체인은 한 줄도 바뀌지 않았습니다. geektime-dl은 여전히 그 geektime-dl이고, 동기화 스크립트도 여전히 그 명령어입니다. 달라진 것은 이 두 단계가 71개 파일을 ‘찾아볼 수 있는’ 상태에서 ‘떠올려지는’ 상태로 바꿨다는 점입니다.

저는 여러분께 ‘효율 X% 향상’ 같은 숫자를 주려고 하지 않습니다. 그런 숫자는 제가 만들어낼 수도 없고, 측정해 본 적도 없습니다.

세 가지 실패 경계

이 프로세스는 어려울수록 좋은 것이 아니며, 아래 세 가지 경우에는 멈춰야 합니다.

1. 이미 능숙하게 익힌 기술을 배울 때는 느린 프로세스를 거치지 마세요. Anthropic의 이전 관찰 연구에 따르면, 참가자가 이미 관련 기술을 가진 과제에서 AI는 완료 시간을 약 80% 단축할 수 있었습니다. 이때 여러분은 배우는 것이 아니라 생산하는 것입니다. 일부러 마찰을 만드는 것은 납품만 늦출 뿐, 어떤 이해도 늘려주지 않습니다. 판단 방법은 아주 원시적입니다. 이 과제를 문서를 보지 않고 쓸 수 있다면, 바로 AI로 속도를 내고 입력 단계를 거치지 마세요.

2. 기초가 심각하게 부족할 때는 먼저 분블록한 뒤 교차와 검색 연습을 논하세요. desirable difficulties에는 하한이 있습니다. 사전 지식이 낮은 사람이 너무 일찍 교차 연습을 하면 과부하가 걸립니다(Schmidt & Bjork 1992; Kornell & Bjork 2007/2008). 바꿔 말하면, Redis의 영속화조차 제대로 파악하지 못한 상태에서 여섯 가지 캐시 일관성 방안을 교차 학습해서는 안 됩니다. 먼저 한 블록을 완전히 배운 뒤 간격과 검색을 하세요. 구체적인 행동으로 말하면, 연속 세 번의 자유 회상에서 아무 항목도 써내지 못한다면 자료의 입자가 너무 큰 것이니 더 작게 쪼개세요.

3. ‘매주 세 가지 질문’을 연속 두 주 동안 써내지 못한다면, 정보원을 잘못 고른 것이지 여러분이 충분히 노력하지 않은 것이 아닙니다. 써내지 못하는 데는 두 가지 가능성이 있습니다. 자료가 너무 쉬워서(물어볼 질문이 없음)이거나, 너무 낯설어서(질문이 전부 ‘이 단어가 무슨 뜻이지’임)입니다. 둘 다 버티는 것으로 해결되지 않습니다. 판단 방법은 여러분의 세 가지 질문이 어느 층에 머무는지 보는 것입니다. 연속 두 주 동안 모두 ‘이게 뭐지’에 머문다면 정보원이 너무 낯선 것이니 한 층 아래로 기초를 보충한 뒤 돌아와야 합니다. 전부 ‘이건 기억나’라면 너무 쉬운 것이니 한 단계 난도를 올리세요. 정보원을 바꾸는 것이 버티는 것보다 효과적입니다.

언제 느린 프로세스를 거치고, 언제 AI를 바로 쓸까

바로 실행할 수 있는 판단 기준을 하나 줍니다.

당신의 상태 | 해야 할 일 이 기술에 장기적으로 의존해 먹고살아야 하는데 아직 원리를 설명하지 못한다 | 세 단계 전체를 거치고, 중점은 가공과 유지에 둔다 그저 돌아가게만 만들면 되고 앞으로 다시는 건드릴 가능성이 낮다 | AI에게 바로 생성을 맡기고, 유지는 건너뛰며, 죄책감은 갖지 않는다 이미 문서를 보지 않고 쓸 수 있지만 다만 느린 게 싫다 | AI로 바로 속도를 내고, 마찰을 만들지 않는다 기초 개념조차 읽어도 이해되지 않는다 | 먼저 블록으로 나눠 기초를 보충하고, 교차와 검색은 하지 않는다 어느 범주인지 확실하지 않다 | 자유 회상을 한 번 해본다. 세 개를 써내지 못하면 첫 번째 범주다

마지막 줄이 이 방법에서 여러분이 먼저 판단해야 하는 유일한 부분이고, 나머지는 모두 기계적인 동작입니다.

한 가지 더 쉽게 벗어나는 점을 덧붙입니다. 이 프로세스의 비용은 실제이니, 모든 학습에 이걸 씌우지 마세요. 제가 71편의 DDD 칼럼에 세 단계 전체를 거친 것은 DDD가 제가 장기적으로 의존해 먹고살려는 분야이기 때문입니다. 제가 임시로 맡게 된 SDK의 문서를 찾아볼 때는 AI에게 예제 코드를 바로 생성하게 해서 돌려보고, 자유 회상도 하지 않고 세 가지 질문도 쓰지 않습니다. 구분 기준은 ‘이 기술이 중요한가’가 아니라 ‘앞으로 2~3년의 업무에 반복적으로 등장할 것인가’입니다. 그렇다면 느린 프로세스를 거치고, 그렇지 않다면 쓰고 바로 버리며, 아낀 시간은 반복적으로 등장할 그 하나에 남겨두세요.

다음 단계의 최소 행동은 ‘오늘부터 꾸준히 하기’가 아니라, 오늘 밤 10분을 들여 한 가지 일을 하는 것입니다.

questions.md를 새로 만들고, 지금 설명하지 못하는 세 가지 질문을 적으세요. 답은 쓰지 말고, 분류하지 말고, 중요한지 아닌지는 신경 쓰지 마세요. 다 쓰는 그 순간, 여러분은 이 프로세스에서 유일하게 AI가 대신할 수 없는 자산, 즉 자신이 어디를 모르는지 아는 목록을 갖게 됩니다. 이후의 모든 가공과 유지는 이 목록에서부터 아래로 내려갑니다.

———

🔧 본문에서 사용한 전체 질문 템플릿

위에서 저는 네 가지 핵심 템플릿(개념 질문 / 생성 시 설명 요구 / 생성 후 추가 질문 / AI에게 나를 검토시키기)을 제시했습니다. 전체 버전 모음(총 42개, 신기술 학습 · Code Review · 리팩터링 · 단위 테스트 생성 · 아키텍처 설계 · AI Agent 조율 커버)을 정리해 두었습니다.

‘prompt’라고 회신하면 받을 수 있으며, 계속 업데이트됩니다.

이 글이 도움이 되었다면 프로그래머 친구에게 전달해 주세요 — 모두가 AI 효율화를 모색하고 있으니, 여러분의 공유가 그의 시간을 많이 아껴줄 수 있습니다.

码哥字节

아키텍트 @인터넷

220

글

336k

읽음

686

팬

출처 원문