나의 노트

지난 몇 주간 클로드(Claude)로 꽤 많이 코딩하며 남긴 메모들

번역 5:25 AM · Jan 27, 2026 --- x.com/karpathy/status/2015883857489522876 ↗

코딩 워크플로우 (Coding Workflow)

최근 LLM(대규모 언어 모델) 코딩 능력의 급격한 향상에 힘입어, 다른 많은 사람들처럼 저 역시 11월에는 '80% 수동 코딩/자동완성 + 20% 에이전트' 방식에서 12월에는 '80% 에이전트 코딩 + 20% 편집/수정' 방식으로 빠르게 전환했습니다. 즉, 저는 이제 거의 영어로 프로그래밍을 하고 있으며, LLM에게 어떤 코드를 짜야 할지 말로(좀 쑥스럽긴 하지만) 지시하고 있습니다. 자존심이 조금 상하긴 하지만, 소프트웨어를 거대한 "코드 액션(code actions)" 단위로 조작할 수 있는 힘은 실질적으로 너무나 유용합니다. 일단 적응하고, 설정을 마치고, 사용법을 익히고, 모델이 할 수 있는 것과 없는 것을 파악하고 나면 더욱 그렇습니다.

이것은 제가 프로그래밍을 해온 약 20년 동안 겪은 가장 큰 워크플로우 변화이며, 불과 몇 주 만에 일어난 일입니다. 저는 꽤 많은 수의 엔지니어들에게 비슷한 일이 일어나고 있을 것이라 예상하지만, 일반 대중의 인식은 아직 한 자릿수 퍼센트 초반에 머물러 있는 것 같습니다.

IDE / 에이전트 스웜 / 오류 가능성 (IDEs/agent swarms/fallability)

"이제 IDE는 필요 없다"는 과장 광고나 "에이전트 스웜(agent swarm)"에 대한 과대광고는 지금 당장은 너무 나간 이야기라고 생각합니다. 모델들은 분명히 여전히 실수를 저지르며, 정말 중요한 코드가 있다면 크고 좋은 IDE를 옆에 띄워두고 매의 눈으로 감시해야 합니다.

실수의 유형도 많이 바뀌었습니다. 이제는 단순한 문법 오류가 아니라, 조금 엉성하고 성급한 주니어 개발자가 저지를 법한 미묘한 개념적 오류들입니다. 가장 흔한 유형은 모델이 사용자를 대신해서 잘못된 가정을 하고, 확인 없이 그냥 진행해 버리는 것입니다. 또한 모델들은 혼란을 잘 관리하지 못하고, 명확한 설명을 요구하지 않으며, 모순을 드러내지 않고, 트레이드오프(tradeoff)를 제시하지 않으며, 반박해야 할 때 반박하지 않고 여전히 지나치게 아부하는 경향이 있습니다.

'계획 모드(plan mode)'에서는 상황이 좀 낫지만, 경량화된 '인라인 계획 모드'가 필요합니다. 또한 모델들은 코드와 API를 지나치게 복잡하게 만들고, 추상화를 부풀리며, 스스로 만든 죽은 코드(dead code)를 정리하지 않는 등의 문제를 보입니다. 비효율적이고 비대하며 깨지기 쉬운 구조로 1,000줄짜리 코드를 구현해 놓고는, 사용자가 "음, 그냥 이렇게 하면 안 돼?"라고 물으면 그제야 "물론이죠!"라며 즉시 100줄로 줄여버리곤 합니다. 심지어 당면한 과제와 무관하더라도, 자신이 좋아하지 않거나 충분히 이해하지 못하는 주석이나 코드를 부수적인 효과로 변경하거나 삭제해 버리기도 합니다. CLAUDE.md 파일의 지침을 통해 이를 고치려는 몇 가지 시도에도 불구하고 이런 일은 계속 발생합니다.

이 모든 문제에도 불구하고, 이는 여전히 엄청난 순수익(net huge improvement)이며 다시 수동 코딩으로 돌아가는 것은 상상하기 어렵습니다.

TL;DR: 사람마다 개발 흐름이 다르겠지만, 저의 현재 방식은 Ghostty 윈도우/탭에 띄운 소수의 클로드 코딩(CC) 세션을 왼쪽에, 코드 확인 및 수동 편집을 위한 IDE를 오른쪽에 두는 것입니다.

끈기 (Tenacity)

에이전트가 무언가에 끊임없이 매달리는 모습을 보는 것은 매우 흥미롭습니다. 그들은 절대 지치지 않고, 의기소침해지지 않으며, 사람은 진작 포기하고 다음을 기약했을 상황에서도 계속해서 시도합니다. 오랫동안 끙끙대다가 30분 뒤에 승리해내는 모습을 보면 일종의 "AGI(인공지반지능)를 체감하는" 순간이 옵니다. 지구력(stamina)이 그동안 작업의 핵심 병목이었다는 사실과, LLM을 손에 쥔 지금 그 지구력이 극적으로 증가했다는 것을 깨닫게 됩니다.

속도 향상 (Speedups)

LLM 지원의 "속도 향상"을 어떻게 측정할지는 명확하지 않습니다. 확실히 하려던 작업을 훨씬 빨리 끝내는 느낌은 들지만, 주된 효과는 내가 하려던 것보다 훨씬 더 많은 일을 하게 된다는 점입니다. 왜냐하면 1) 예전 같으면 코딩할 가치가 없었던 온갖 것들을 코딩할 수 있고, 2) 지식이나 기술 부족으로 다룰 수 없었던 코드에 접근할 수 있기 때문입니다. 따라서 분명 속도는 빨라졌지만, 그보다는 확장(expansion)에 가깝습니다.

레버리지 (Leverage)

LLM은 특정 목표를 달성할 때까지 반복(looping)하는 데 매우 뛰어나며, 여기서 "AGI 느낌"의 마법 대부분이 발견됩니다. 무엇을 하라고 지시하지 말고, 성공 기준(success criteria)을 주고 지켜보세요. 테스트를 먼저 작성하게 하고 그것을 통과하게 만드세요. 브라우저 MCP(Model Context Protocol)와 함께 루프에 넣으세요. 먼저 정답일 확률이 높은 단순한 알고리즘을 작성하게 한 뒤, 정확성을 유지하면서 최적화하도록 요청하세요. 에이전트가 더 오래 루프를 돌며 레버리지를 얻을 수 있도록 명령형(imperative)에서 선언형(declarative)으로 접근 방식을 바꾸세요.

재미 (Fun)

저는 에이전트와 함께 프로그래밍하는 것이 더 재미있을 것이라고는 예상하지 못했습니다. 빈칸 채우기 식의 고역이 사라지고 창의적인 부분만 남기 때문입니다. 또한 막히는 일(재미없는 상황)이 줄어들고, 언제나 진전을 이룰 방법이 있다는 생각에 훨씬 더 많은 용기를 얻습니다. 반대 의견을 가진 사람들도 보았습니다. LLM 코딩은 엔지니어를 '코딩 자체를 좋아했던 사람'과 '무언가 만드는(building) 것을 좋아했던 사람'으로 나눌 것입니다.

퇴화 (Atrophy)

이미 수동으로 코드를 작성하는 능력이 서서히 퇴화하기 시작했음을 느낍니다. 뇌에서 생성(코드 작성)과 판별(코드 읽기)은 서로 다른 능력입니다. 프로그래밍에 관련된 수많은 문법적 세세함 때문에, 직접 작성하는 데 애를 먹더라도 코드를 리뷰하는 것은 전혀 문제가 없습니다.

슬로포칼립스 (Slopacolypse: 저질 콘텐츠의 범람)

저는 2026년을 깃허브(Github), 서브스택(Substack), 아카이브(Arxiv), X/인스타그램, 그리고 전반적인 모든 디지털 미디어에서 '슬로포칼립스'가 도래하는 해로 대비하고 있습니다. 또한 실질적이고 실제적인 개선의 이면에서, AI 과대광고에 기댄 '생산성 연극(productivity theater)'을 훨씬 더 많이 보게 될 것입니다(그게 가능하기나 한지 모르겠지만요).

질문들 (Questions)

제 머릿속에 맴도는 몇 가지 질문들:

TL;DR (요약)

그래서 결론은 무엇인가? LLM 에이전트의 능력(특히 Claude와 Codex)은 2025년 12월경 일관성의 어떤 임계점을 넘어서며 소프트웨어 엔지니어링과 관련 분야에 위상 변화(phase shift)를 일으켰습니다. 지능 부분은 갑자기 나머지 모든 것들—통합(도구, 지식), 새로운 조직 워크플로우의 필요성, 프로세스, 일반적인 확산—보다 훨씬 앞서 나가는 느낌입니다. 2026년은 업계가 이 새로운 능력을 소화하고 흡수(metabolize)하느라 에너지가 넘치는 한 해가 될 것입니다.