전직 CS 교사로서 보면, 속도뿐 아니라 코드 이해도도 중간 수준에 머물 가능성이 큼. 학생들은 예제를 그대로 옮겨 적기보다 읽고 이해한 뒤 독립적으로 재현할 때 더 잘 배웠음. 스스로 해법을 설계하는 직관은 덜 길러지지만, 도구를 계속 쓸 생각이라면 이 방식이 더 도움 될 수 있음
“API나 알고리즘을 이해하지 못하면 멈춰서 찾아보거나 LLM에 설명을 요청한다”는 대목은 희망적임. 전통적인 프로그래밍 연습과는 다른 사고 능력을 쓰지만 비판적으로 관여하며 학습하고 있다는 뜻임. 다만 시간이 지나면 일탈의 정상화, 경보 피로 같은 인간의 고전적인 함정에 빠져 효과가 떨어질 가능성이 큼

인지 부채는 실재함. 몇 년간 각 세대 LLM을 사소한 도구 프로젝트에 시험해 보니 뚜렷한 변화가 보였음. 2025년 겨울 Sonnet 3.7은 지시를 받자마자 폭주하는 마법사의 제자 같았고, 가을의 Sonnet 4.5는 코드를 이해하는 인간이 명확히 지시하면 대규모 리팩터링이나 새 클라우드 공급자용 Rust 트레이트 구현을 능숙하게 처리하는 훌륭한 부하였음. 인지 부채를 최소화하는 최적점으로, 흔한 API를 모두 알고 타이핑이 매우 빠르지만 중요한 판단은 인간에게 맡기는 초보 페어 프로그래머에 가까웠음
2025년 12월 Opus 4.5부터 에이전트 코딩이 폭발했고, 몇 주간 흥미로웠지만 인지 부채가 쌓이는 것이 체감됐으며 몇몇 프로젝트가 난처한 상태가 됐음. 2026년 여름 Fable 5에는 몇 단락의 명세와 답변, 20~50달러어치 토큰만 주고 자리를 비우면 한두 시간 뒤 설치 가능한 APK가 완성됐지만, 코딩할 때 방에조차 없었으므로 인지 부채가 완전해졌음. 현실적인 규모에서는 여전히 성급하고 어리석은 선택을 하며, 소통 없이 사무실에 틀어박혔다가 가끔 자기 영리함만 장황하게 설명하는 유능한 시니어 개발자와 비슷함
개인적으로 LLM 코드를 다시 타이핑하지는 않을 생각임. 현대 IDE와 Zed의 Zeta2 같은 짧은 자동완성 모델이면 직접 작성해도 매우 빠르므로, LLM은 주로 지루하고 예측 가능한 코드를 대신 입력하는 데 사용함. 하지만 인간을 점점 작업 과정에서 배제하려는 유인은 분명하며, 이는 프로그래머가 두려워할 만한 WALL-E식 미래임
Sonnet 4.5급 모델은 “제대로 배우려면 남을 가르쳐라”라는 원리를 활용할 수 있는, 영원히 배우지 않는 학생 같았음. 현재 로컬 모델 중 Qwen3.6 27B는 Sonnet 4.5보다 조금 약하지만 허드렛일과 디버깅에 유능하고, 사용자가 작업을 이해하지 못하면 반드시 실패함. DeepSeek V4 Flash 0731은 Opus 4.5에 더 가까워 의식적으로 개입하지 않으면 몇 주 뒤 되돌리기 우울할 만큼 문제가 커짐
Anthropic과 OpenAI는 완전한 WALL-E 경험이나 부재중 Android 앱 완성을 원할 때 필요하지만, 중간급 MIT 라이선스 가중치만으로도 광범위한 작업에 충분하며 인지 부채 관점에서는 이미 지나치게 좋을 수도 있음. AI를 허용하는 이념적 자유 소프트웨어 프로젝트도 MIT 라이선스 가중치와 자유 소프트웨어 실행 도구를 진지하게 고려해야 함. 모든 것을 Anthropic이나 ChatGPT에 맡기는 것은 1990년대에 모든 것을 Microsoft에 맡기던 모습과 너무 닮았음

LLM 보조로 연습량이 줄어 기술을 잃을 수 있다는 우려는 타당하지만, 기술 재습득은 처음 배우는 것보다 대체로 훨씬 효율적임. 전직 사이클 선수로서 훈련을 완전히 쉬어도, 경기 훈련법을 배우기 전의 최고 수준보다 무훈련 기준점이 높게 유지되는 것을 느낌. 컴퓨터 작업도 적어도 내게는 비슷하게 작동함

이 방식은 Claude Code의 Manual 모드를 다소 번거롭게 구현한 것처럼 보임. Manual 모드는 LLM이 수정할 때마다 멈춰 차이를 보여 주고 수락, 중단, 재요청을 선택하게 함
나는 집에서는 LLM을 쓰지 않고, 직장에서는 주로 질문만 한 뒤 코드는 직접 작성함. 코드 생성을 맡길 때도 반드시 Manual이나 Plan 모드를 사용함. 자동 수정은 이해 없이 눈이 흐려지게 만들고, 모델이 완전히 잘못된 방향으로 갈 때 바로 개입할 기회도 주지 않기 때문임
덕분에 기본 역량은 유지하면서 막힐 때 동료를 덜 방해하고, 작업을 보여 주기 전에 명백한 문제를 걸러 과거의 여러 차례 커밋 재검토 주기를 줄일 수 있어 생산성이 높아졌음

코드는 전부 직접 작성하고 LLM과는 설계, 경계 조건, API·라이브러리 사용 예시를 중심으로 대화하는 방법도 좋음. 구현하려는 내용을 논의하고, 후속 질문으로 여러 구현 경로를 탐색하며, 익숙하지 않은 API나 라이브러리를 실제 기능의 맥락에서 살펴봄. 필요하면 클래스·함수·테스트 사례를 높은 수준의 의사 코드로 제안받은 뒤 최선의 경로가 명확해지면 직접 구현함
LLM을 사고 보조 도구로 다루면 막히는 횟수가 크게 줄어 작업에 따라 생산성이 2~3배 높아지면서도, 구현 대상에 대한 이해는 그대로이거나 오히려 깊어짐

ChatGPT에 Python 같은 의사 코드를 작성하게 하고 직접 C로 옮기는 비슷한 방식을 사용했음. 이 정도 작업은 무료 버전으로도 가능함

AI 에이전트가 자율적으로 PR을 제출하게 한 뒤, 인간 주니어 동료의 PR처럼 엄격하게 검토해도 비슷한 가치를 얻을 수 있다고 봄

LLM이 생성한 코드는 내가 검토를 요청받은 코드처럼 다룸

하지만 일반적인 코드 검토를 실제로 얼마나 철저히 하는지가 관건임. LLM은 경계 조건을 포괄적으로 사고하지 못하고, 완전한 테스트 모음을 만들게 하지 않는 한 누락이 많으며 설계 감각도 부족함. 인간과 달리 기분을 고려할 필요가 없으므로 취향과 일관성까지 가차 없이 비판해 더 정돈된 결과를 요구해야 함

큰 프로젝트에서 다른 사람에게 보여 줄 코드는 깊게 검토하고, LLM에 이의를 제기하며 정확성을 납득시킬 테스트 작성을 요구함. 시간이 걸리지만 매우 유능한 에이전트가 없었다면 시도하지 않았을 만큼 야심 찬 변경도 가능해짐
반면 바이브 코딩한 코드는 거의 이해하지 못함. 가끔 표본 검사만 하며, 특정 부분을 수정하려면 LLM에 독해 안내서를 작성하게 한 뒤 별도로 시간을 들여야 함. 명세로 무엇을 요구했는지는 알지만 실제 결과를 파악하기 위해 평소보다 훨씬 많은 관측 가능성 도구를 내장해 두었음