AI 시대의 학습: 생산성과 깊이 사이에서

들어가며

AI 도구를 써서 빨라져야 하는 시대라고 한다. 주변을 보면 실제로 그렇다. AI 코딩 에이전트로 커스텀 스킬을 뚝딱 만들어 내고, 여러 도구를 조합해서 몇 시간이면 끝내는 사람들이 있다. 그 사람들이 실제로 생산적이라는 걸 안다. 나도 그렇게 해야 한다는 걸 안다.

그런데 나는 직접 쓰면서 소화해야 “아는” 사람이다.

이 글은 NCCL 트러블슈팅을 진행하면서 GPU 통신과 분산학습 개념을 공부해야 했던 시점에서 시작된 고민의 기록이다. 실무에서 생산성도 높여야 하고, 그러면서 지식도 내재화해야 하는데, 이 두 가지가 나에게는 자꾸 충돌했다. 그래서 나름의 워크플로우를 만들어 봤고, 그래도 여전히 걱정은 남아 있다. 워크플로우 가이드가 아니라, 그 고민 자체를 적어 두려 한다.

나의 학습 패턴

나는 아주 어렸을 때부터 이런 식으로 공부해 왔다.

모르는 게 생기면 질문을 쌓아 나간다. 하나의 개념을 파다 보면 또 모르는 게 나오고, 그 질문들이 계속 불어난다. 그 질문들에 대한 답을 하나씩 손으로 쓰면서 해소해 나간다. 그러다 어느 순간 모든 퍼즐이 맞춰졌다는 느낌이 들면, 그때까지 쓴 것들의 순서를 재배치하고, 전체 그림을 요약해 본다. 그게 되면 비로소 “알았다”는 감각이 온다.

성장하면서 매체가 바뀌었다. 손글씨 대신 타자를 치고, 노트 대신 노션 같은 메모 앱에 정리한다. 하지만 본질은 같다. 직접 쓰면서 이해하는 것. 남이 정리해 준 걸 읽는 것만으로는 내 머릿속에 자리 잡지 않는다.

이 패턴의 장점은 깊이다. 한번 이해한 것은 단단하게 남는다. 그리고 솔직히, 모든 퍼즐이 맞춰지는 순간의 희열이 꽤나 크다. 단점도 명확하다. 우선 시간이 많이 걸린다. 아주 많이 걸린다. 그리고 모든 질문에 답을 찾지 못하면 완전히 “안다”는 느낌이 오지 않는다. 가장 힘든 건 어디까지 파야 충분한지, 그 깊이 조절이 안 된다는 것이다. 뭘 모르는지 모르는 상태에서는 어디까지 알아야 하는지도 알 수가 없다. 질문이 꼬리를 물고 불어나는데 어디서 멈춰야 할지를 모르니 끝없이 빠져든다.

예전에는 이런 어려움이 다른 형태로 나타났다. 구글링하면서 크롬 탭이 한가득 열려 있고, 책을 사서 읽다가 시간이 없어서 끝까지 못 마치고, 뽑아 놓은 자료가 쌓이면서 좌절하곤 했다. LLM(Large Language Model)이 등장하면서 정보 접근 측면에서는 많이 해소됐다. 궁금한 걸 바로 물어볼 수 있게 됐으니까.

물론 이 학습 패턴 자체가 바뀐 건 아니었다. 도구가 빨라졌을 뿐, 끝까지 답을 찾아야 “알았다”는 느낌이 오는 건 여전하다. 다만 수많은 현타를 겪으면서 나름의 조절법을 익혀 갔을 뿐이다. 모든 걸 다 파지 않아도 된다는 것, 지금 당장 필요한 깊이와 나중에 돌아올 깊이를 구분할 수 있다는 것을 조금씩 알아갔다.

그런데 지금, 다시 그 어려움이 찾아왔다.

왜 지금 더 어려움을 느끼는가

처음 개발을 시작할 때도 모르는 건 매한가지였다. DB 연결, 3-layer architecture, 서버-클라이언트 개념, 웹서버와 WAS의 차이. 전부 처음부터 배워야 했다.

다만 지금의 상황을 냉정하게 진단해 보면, 겨우 익힌 조절 감각이 다시 무너진 이유가 두 가지 있다.

도메인 전환

개발에서 Ops영역으로 확장하면서 학습의 성격 자체가 달라졌다.

개발은 그래도 몇 년 해온 도메인이라 “대충 감 잡히니 일단 짜고 나중에 보강”이 가능했다. 잘해서가 아니라, 틀려도 어디가 틀렸는지 감이라도 왔다는 뜻이다. 인프라는 그게 안 된다. 감이 잡히지 않으니 딥다이브를 시작하고, 끝이 없고, 길을 잃는다.

개발(익숙):  모르는 것 → "대충 감 잡힘" → 일단 구현 → 나중에 보강
인프라(낯선): 모르는 것 → "감이 안 잡힘" → 딥다이브 시작 → 끝이 없음 → 길을 잃음

특히 ML/GPU 인프라 쪽은 OS, 네트워크, 컴퓨터 구조 등 모든 것이 맞물려 있다. 쿠버네티스를 배우면서 더 느끼는 점이다. 하나를 파면 모르는 게 줄줄이 딸려 나오고, 노션의 체크박스가 한가득 쌓인다.

피드백 루프도 길다. Dockerfile 리빌드, 이미지 푸시, 파드 스케줄링, 런타임 에러 확인까지 수십 분이 걸린다. 서비스가 운영되고 있는 경우 환경을 망가뜨리면 안된다는 부담도 있다. 그 사이에 “제대로 한 건지” 불안해서, 개념부터 완벽히 이해하고 넘어가려는 충동이 더 강해진다.

AI 시대가 주는 부담

여기에 AI 시대가 주는 부담이 더해졌다.

단순히 “AI를 써라”는 분위기 때문만은 아니다. 실제로 내가 주변에서 그 생산성을 목격하고 있어서다.

같은 시간에 나보다 훨씬 많은 걸 해내는 사람들이 있다. 새로운 도구가 나오면 금방 자기 워크플로우에 녹여내고, 반복 작업은 자동화 파이프라인으로 만들어 버리고, 모르는 영역도 AI와 빠르게 주고받으면서 결과물을 찍어낸다. 그리고 그 결과물의 품질이 실제로 높다. 단순히 빠르기만 한 게 아니라, 빠르면서도 좋다.

그걸 보면서 드는 질문이 있다. 내가 주변에서 목격하는 사람들은 생산성과 깊이를 동시에 챙기고 있는 건 아닐까? 빠르게 만들어내면서도, 그 과정 자체가 반복과 피드백을 통해 이해를 쌓는 경로가 되는 사람들이 있을 수 있다.

그렇다면 내가 전제하고 있는 것 — “느리게 씹어야만 깊이가 생긴다” — 자체를 재검토해야 하는 걸까? 그런데 그 전제를 쉽게 버릴 수도 없다. 실제로 그 방식으로 여기까지 왔으니까. 결국 불안의 실체는 “저 사람들이 빠르다”가 아니라, “생산성과 깊이를 양립하는 방법이 있을 수 있는데 내가 그걸 못 찾고 있다”에 가깝다.

그래서 느끼는 건 선망이라기보다는 조급함에 가깝다. 나도 저렇게 해야 한다는 건 안다. 저렇게 할 수 있는 도구도 있다. 그런데 막상 내가 쓰려고 하면, 도구를 익히는 데에도 시간이 걸리고, 도구가 뱉어낸 결과를 내가 이해하지 못한 채 넘어가는 게 불안해서 또 멈추게 된다. “이걸 내가 정말 아는 건가?”라는 질문이 자꾸 발목을 잡는다.

충돌 지점

예전이라면 느리더라도 결국 내 방식대로 이해하면 그만이었다. 시간이 걸려도 어차피 다 내 몫이었으니까. 하지만 솔직히, AI 시대가 아니더라도 이 충돌은 언젠가 왔을 것이다. 연차가 쌓이면 맡는 범위가 넓어지고, 모든 걸 그때그때 딥다이브할 여유는 줄어든다. AI 시대가 그걸 앞당기고 더 선명하게 만들었을 뿐, 근본적으로는 “한정된 시간 안에 깊이와 생산성을 동시에 요구받는 상황”이 된 것이고, 그 속에서 내 학습 패턴이 정면으로 부딪혔다.

구체적으로는 이랬다. 인프라 업무를 하면서 모르는 게 나오면 Claude Web에서 별도 세션을 열고 딥다이브하고, 노션에 정리하고, 다시 작업 컨텍스트를 복구하는 루틴을 반복했다. 컨텍스트 스위칭의 비용이 과도했고, 거기에 시간이 걸리는 내 학습 패턴까지 더해지니 도무지 생산성이 나오지 않았다.

내가 지식을 내재화하는 방식 자체가 생산성 향상에 독이 된다고 느꼈다. 그 느낌이 꽤 고통스러웠다. 원래 그 패턴 덕분에 여기까지 온 건데.

그래서 만들어 본 것

고민만 하고 있을 수는 없었다. Claude Code를 본격적으로 쓰기 시작하면서, 실무 생산성과 지식 내재화를 동시에 잡아 보기 위한 워크플로우를 만들어 봤다. 핵심은 네 가지 전략이다.

작업 중 학습: 컨텍스트 스위칭 제거

가장 큰 비용이 컨텍스트 스위칭이었으니, 이걸 먼저 없앤다. Claude Web과 Claude Code를 오가는 대신, 작업 세션 안에서 바로 질문하는 방식으로 바꿨다.

기존: 업무(터미널) → 막힘 → Claude Web 이동 → 상황 다시 설명
      → 딥다이브 → 노션 정리 → 다시 업무 컨텍스트 복구

개선: 업무(Claude Code) → 막힘 → 같은 세션에서 질문 → 답변 받음
      → 바로 계속 → 정리 필요하면 "/notion-upload"

지금 보고 있는 파일, 방금 실행한 명령어 결과, 현재 작업 맥락이 전부 공유된 상태에서 답변이 나온다. Claude Web에서 “지금 Dockerfile에서 CUDA 12.8 base 이미지를 쓰는데…“부터 설명하지 않아도 된다.

Just Enough 깊이 조절: 딥다이브 충동 관리

“지금 하고 있는 일을 다음 한 단계 진행하는 데 필요한 만큼만 이해한다”는 원칙을 세웠다.

인프라 도메인에서 딥다이브가 끝없어지는 이유는 “이걸 모르니까 저것도 모르고, 저걸 모르니까 그것도…“의 연쇄 때문이다. 예를 들어 ldd 명령어를 실행해야 할 때, “ldd가 뭔지”(동적 라이브러리 의존성 확인 도구) 정도면 충분하다. “ELF 바이너리 포맷이 어떻게 동작하는지”까지는 지금 필요 없다. 나중에 LD_LIBRARY_PATH 가드레일을 설계할 때 더 깊이 파면 된다.

더 알고 싶은 건 노션에 [ ]로 남겨두고, 주말 정리 시간에 해소하는 것으로 분리했다.

깊이 제한을 시스템화하기

깊이를 명시적으로 제한하는 것도 방법이다. “이 개념을 한 줄로 설명해줘. 지금 이 작업을 진행하는 데 필요한 수준으로만.” 이렇게 질문하면 답변의 깊이도 달라진다. 다만 이걸 매번 의식적으로 하기는 어렵다. 딥다이브 충동이 올 때는 이미 “한 줄”이 아니라 “전부”를 알고 싶어지기 때문이다.

그래서 한 걸음 더 나아가, 글로벌 CLAUDE.md(~/.claude/CLAUDE.md)에 깊이 관리 규칙을 행동 하네스로 심어 뒀다. Claude Code는 어떤 프로젝트에서 대화를 시작하든 이 파일을 먼저 읽기 때문에, CI의 테스트 하네스가 코드 품질을 강제하듯 대화마다 자동으로 걸리는 가드레일이 된다. 핵심 규칙은 세 가지다.

• 깊이 경계 제시: 개념 설명 시 대화 흐름을 끊지 않되, 경계가 필요한 순간에 “지금은 여기까지 알면 충분합니다”를 포함한다.
• 딥다이브 가드레일: 현재 작업 범위 밖으로 빠지기 시작하면 경계를 명시하고, 더 파고 싶은 주제는 별도 학습으로 이연한다.
• 세션 마무리 학습 포인트: 대화가 끝날 때, 표면적으로만 다룬 개념 중 독립 학습이 필요한 것을 learning-backlog에 누적한다.

실제로 작동하는 모습은 이랬다. GPU 스택 문서를 작성하다 SM 내부 실행 모델(warp divergence, occupancy 등)로 빠져들려 할 때, “SM이 GPU의 기본 실행 단위이고, 그 안에 CUDA Core가 있다 — 지금은 여기까지면 충분합니다. 상세는 별도 학습으로 이연합니다”라고 선을 그어 줬다. NCCL 트러블슈팅 중 ABI 호환 개념이 궁금해졌을 때도, “PyTorch가 libnccl.so.2를 찾으므로 soname이 .2인 NCCL만 로드 대상 — 지금은 여기까지, ABI의 실체는 별도 주제입니다”라고 끊어 줬다. 내가 멈춰야 할 지점을 도구가 대신 잡아 주니, 딥다이브 충동에 빠지는 빈도가 체감될 정도로 줄었다.

산출물 = 학습 기록: 별도 정리 비용 제거

작업 산출물 자체가 학습 기록이 되게 만들었다. 기존에는 학습과 노션 정리가 별도 작업이었는데, 이 경계를 없앴다.

명령어 결과를 수집하면서(작업), 각 명령어가 어느 계층을 보여주는지 매핑하고(학습), 테이블로 정리한다(산출물). 이 세 가지가 하나의 흐름 안에서 동시에 일어나게 만들었다.

개념 지도 선행: 새 도메인 진입 패턴

내가 길을 잃는 또 다른 이유는, 전체 지형을 모르는 상태에서 한 곳을 파기 시작하기 때문이다. 그래서 새 도메인에 진입할 때는 세부부터 파는 대신, 작업 세션 안에서 Claude Code에게 전체 개념 지도를 먼저 그려 달라고 요청한다. 작업 문맥이 유지된 상태에서 지형을 조감한 뒤, 내 역할에서 필요한 깊이 기준을 설정하고 나서야 세부로 들어간다.

실제로 GPU 통신 학습에서 이런 기준표를 만들었다.

계층	MLOps Platform Engineer	ML Engineer
물리 하드웨어 (PCIe/NVLink/IB)	읽을 줄 알아야 (nvidia-smi topo)	몰라도 됨
CUDA/Driver/NCCL 스택	핵심. 버전 정합성, .so 로딩	대략만
통신 라이브러리 (NCCL/Gloo)	핵심. 환경변수 튜닝, 에러 해석	backend 선택 정도
분산학습 전략 (DP/MP/PP)	개념 수준	직접 설계

이 기준표가 있으면 “여기는 교양이니까 깊이 파지 말자” vs “여기는 전공이니까 확실히 알아야 한다”를 판단할 수 있다. 모든 걸 같은 깊이로 파려다 지치는 패턴을 막아 준다.

워크플로우의 도구화

이 네 가지 전략을 일관되게 실행하기 위해, Claude Code의 커스텀 스킬과 MCP(Model Context Protocol)를 활용해서 워크플로우 자체를 도구화했다. 노션 업로드를 자동화하는 notion-upload, 주간 사용 습관을 추적하는 weekly-review, 비효율 세션을 분석하는 prompt-deep-dive, 실시간으로 워크플로우를 피드백하는 workflow-suggest 같은 것들이다.

스킬의 상세 스펙보다 중요한 건, 왜 이런 도구를 만들게 됐는가다. 전략을 세워도 실행이 흐지부지해지는 경험을 여러 번 했기 때문이다. 도구로 만들어 놓으면 한 마디로 실행할 수 있고, 실행 자체의 마찰이 줄어든다. 예를 들어 앞서 말한 산출물 정리 흐름의 마지막 단계는 이렇다. 작업 세션에서 명령어 결과 수집과 학습 매핑이 끝나면, /notion-upload 한 마디로 Notion MCP를 통해 노션에 바로 올라간다. 별도 앱을 열고 복사-붙여넣기할 필요가 없다.

변화를 정리하면 이렇다.

항목	기존	개선
학습 장소	Claude Web (별도 세션)	Claude Code (작업 세션 내)
학습 타이밍	작업 전/후 별도 시간	작업 중 즉시 (5-15분)
학습 깊이	이해될 때까지 딥다이브	“다음 한 단계에 필요한 만큼”
정리	별도 노션 정리	/notion-upload으로 마무리
미해결 질문	해소 시점 불명확	주간 정리 시간에 집중 해소
새 도메인 진입	세부부터 파고듦	전체 지도 → 깊이 기준 → 필요한 만큼

그래도 걱정은 남는다

워크플로우를 만들고 도구화까지 했지만, 솔직히 불안은 해소되지 않았다. 오히려 이 워크플로우를 쓰면 쓸수록 더 선명해지는 걱정이 있다.

“빨라졌다”와 “알게 됐다”는 다른 축이다

이 워크플로우를 통해 throughput은 확실히 올라갈 수 있다. 그런데 직접 타자 치면서 “이게 왜 이렇게 되는 거지?”를 씹어보는 과정에서 생기는 depth는 — 답을 받아 읽는 것만으로는 대체가 안 된다.

결국 이 두 가지는 다른 축이다.

• 처리 속도(throughput): 문제를 만나고 → 답을 얻고 → 다음 단계로 넘어가는 시간
• 이해 깊이(depth): 그 과정에서 내 머릿속에 남는 멘탈 모델의 견고함

이 워크플로우가 주로 최적화하는 건 전자다. 후자는 여전히 내가 직접 해야 하는 영역이다.

진짜 위험한 건 “생산성 향상”이라는 포장

사실 이쪽이 더 무서운 함정이다.

“오늘 NCCL 이슈 해결했고, 학습도 했고, 노션에 정리도 했어. 생산적인 하루였다.”

근데 돌아보면 Claude가 알려준 걸 따라간 거고, 내가 독립적으로 “왜 NCCL이 shared memory를 이렇게 쓰는지” 설명할 수 있느냐 하면 못 할 수도 있다. 이런 상황이 반복되면, 산출물은 쌓이는데 실력은 정체되는 기이한 상태가 될 수 있다.

이걸 본인이 인지하기 어려운 이유는, 산출물이 눈에 보이기 때문이다. “정리했으니 알고 있는 거 아닌가?”라는 착각이 자연스럽게 생긴다.

어떻게 이겨 나갈 것인가

결국 핵심은, 기존 습관 — 직접 쓰면서 이해하기 — 을 버리지 않고 AI 워크플로우와 공존시키는 것이다.

진짜 중요한 건 내 말로 다시 쓰기

모든 걸 다시 쓸 필요는 없다. 하지만 “전공” 영역 — CUDA/NCCL 스택, 분산학습 통신 같은 내 역할의 핵심 영역 — 은 Claude 답변을 닫고 내 언어로 한 번 더 정리하는 과정이 필요하다. 이게 기존에 타자 치면서 해소하던 것과 같은 역할을 한다.

“설명할 수 있는가” 테스트

주간 정리 시간에 단순히 미해결 질문을 해소하는 게 아니라, 이번 주에 배운 것 중 하나를 골라서 Claude 없이 3분간 설명해 본다. 막히는 지점이 곧 실제로 이해하지 못한 부분이다.

속도 모드와 이해 모드의 명시적 구분

모든 작업에서 depth를 추구할 필요는 없다. “교양” 영역은 AI로 빠르게 넘기고, “전공” 영역은 의도적으로 느리게 간다. 중요한 건 이 전환을 무의식이 아니라 스스로 선언하는 것이다.

여기에 더해, 아직 확신은 없지만 경계해야 할 것들이 보인다.

• AI에 기대는 빈도가 늘면서, 내 가설을 먼저 세우는 습관이 사라지지 않을까.
• 효율을 좇다가 “전공” 영역의 깊이를 건너뛰게 되지 않을까.
• 워크플로우를 다듬는 데 매몰되어 정작 실무가 밀리지 않을까.
• 혼자만 이해하고 끝나서 팀에는 아무것도 남기지 못하는 건 아닐까.

솔직히, 이것들이 실제로 문제가 될지는 더 지켜봐야 안다. 다만 한 가지는 분명하다. 이 전략들은 편의를 위한 것이지, 깊이를 포기하기 위한 것이 아니다. 특히 CUDA/NCCL 스택처럼 내 역할의 핵심 영역은 Just Enough를 넘어서 깊이 파는 시간을 별도로 확보해야 한다.

마무리

원래부터 모르는 상태가 싫어서, 항상 딥다이브해서 이해하고 실행하는 패턴을 유지해 왔다. 이제는 생산성을 무시할 수 없는 상황이 됐기에 이런 전략을 세웠다.

그렇지만, 여전히 “이 전략이 나를 얕은 사람으로 만들까?”라는 걱정이 든다. 지금이야 이 걱정을 하고 있으니 다행이다. 나중에 어느 순간 이 걱정이 사라지면 — “뭐, AI가 알려줬으니까 아는 거지”라고 느끼기 시작하면 — 그때가 진짜 위험한 순간이다.

AI가 코드를 짜주고 디버깅을 해줄 수 있지만, 근본 원리를 내재화하는 것은 대신 해주지 못한다. 뇌에 직접 꽂아 주는 시대가 올 수도 있겠지만, 그 전까지는 — 생산성을 높이되, 직접 쓰면서 씹어보는 습관의 중요성은 잊지 않겠다.