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

들어가며

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

그런데 나는 직접 쓰면서 씹어봐야 아는 사람이다.

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

나의 학습 패턴

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

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

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

이 패턴의 장점은 깊이다. 한번 이해한 것은 단단하게 남는다. 단점은 명확하다. 느리다. 아주 느리다.

예전에는 이 느림이 다른 형태로 나타났다. 구글링하면서 크롬 탭이 한가득 열려 있고, 읽지 않을 책을 사고, 읽기 힘들어서 뽑아 놓고 보지 못하는 자료가 쌓이면서 좌절하곤 했다. LLM(Large Language Model)이 등장하면서 그런 부분은 많이 해소됐다. 궁금한 걸 바로 물어볼 수 있게 됐으니까.

그렇다고 이 학습 패턴 자체가 바뀐 건 아니었다.

왜 지금 더 힘든가

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

다만 지금의 상황을 냉정하게 진단해 보면, 두 가지가 겹치면서 유독 힘들어졌다.

도메인 전환

개발에서 Ops영역으로 넘어오면서 학습의 성격 자체가 달라졌다.

개발은 그나마 어느 정도 체득한 도메인이었기에 “대충 감 잡히니 일단 짜고 나중에 보강”이 가능했다. 인프라는 그게 안 된다. 감이 잡히지 않으니 딥다이브를 시작하고, 끝이 없고, 길을 잃는다.

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

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

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

대 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 가드레일을 설계할 때 더 깊이 파면 된다.

깊이를 명시적으로 제한하는 것도 방법이다. “이 개념을 한 줄로 설명해줘. 지금 이 작업을 진행하는 데 필요한 수준으로만.” 이렇게 질문하면 답변의 깊이도 달라진다. 더 알고 싶은 건 노션에 [ ]로 남겨두고, 주말 정리 시간에 해소하는 것으로 분리했다.

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

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

명령어 결과를 수집하면서(작업), 각 명령어가 어느 계층을 보여주는지 매핑하고(학습), 테이블로 정리한다(산출물). 이 세 가지가 동시에 일어나고, 마지막에 /notion-upload 한 마디면 노션에 올라간다. Notion MCP(Model Context Protocol)를 연결하고 업로드 스킬을 만든 이유가 여기에 있었다.

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

인프라 도메인에서 길을 잃는 또 다른 이유는, 전체 지형을 모르는 상태에서 한 곳을 파기 시작하기 때문이다. 그래서 새 도메인에 진입할 때는 세부부터 파는 대신, 전체 개념 지도를 먼저 그리고 내 역할에서 필요한 깊이 기준을 설정하는 것부터 시작하게 됐다.

실제로 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를 활용해서 워크플로우 자체를 도구화했다. 노션 업로드를 자동화하는 notion-upload, 주간 사용 습관을 추적하는 weekly-review, 비효율 세션을 분석하는 prompt-deep-dive, 실시간으로 워크플로우를 피드백하는 workflow-suggest 같은 것들이다.

스킬의 상세 스펙보다 중요한 건, 왜 이런 도구를 만들게 됐는가다. 전략을 세워도 실행이 흐지부지해지는 경험을 여러 번 했기 때문이다. 도구로 만들어 놓으면 한 마디로 실행할 수 있고, 실행 자체의 마찰이 줄어든다.

변화를 정리하면 이렇다.

항목	기존	개선
학습 장소	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 의존도 과잉 → 자기 사고력 퇴화	“내 가설 먼저 → AI 검증” 순서 고수
효율 추구 → 깊이 있는 이해 회피	“전공” 영역은 주말/별도 시간에 깊이 보강
워크플로우 최적화에 매몰 → 실제 작업 지연	전략은 월 1회 회고로 조정, 평소는 그냥 실행
혼자만의 이해로 끝남 → 팀 공유 부재	정리된 산출물 중 팀에 유용한 건 싱크업에 공유

이 전략들은 편의를 위한 것이지, 깊이를 포기하기 위한 것이 아니다. 특히 CUDA/NCCL 스택처럼 내 역할의 핵심 영역은 Just Enough를 넘어서 깊이 파는 시간을 별도로 확보해야 한다.

마무리

원래부터 모르는 상태가 싫어서, 항상 딥다이브해서 이해하고 실행하는 패턴을 유지해 왔다. 이제는 생산성 향상을 생각하지 않을 수 없는 상태가 되었기에 이런 전략을 세운 것이다.

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

AI가 코드를 짜주고 디버깅을 해줄 수 있지만, 근본 원리를 내재화하는 것은 대신 해주지 못한다. 뇌에 직접 꽂아 주는 시대가 올 수도 있겠지만, 그 전까지는 스스로의 중심을 지키며 직접 쓰면서 씹어보는 습관, 적어도 그것의 중요성은 잊지 않으려 노력해야 할 것이다.