https://x.com/karpathy/status/2015883857489522876

Vibe Coding이란 표현을 처음으로 사용한 Andrej Karpathy가 Claude를 사용하면서 느낀 점을 본인 계정에 짧게 올렸습니다.

참고로 Andrej Karpathy는 OpenAI의 창립 멤버이자 Tesla의 AI 총책임자로 근무한 이력이 있습니다.

전 Antigravity에서 Gemini 3 Pro를 주로 쓰고 있지만 많은 부분에서 공감이 가 해당 글을 공유합니다.

[번역: Gemini 3 Flash]

지난 몇 주간 Claude로 코딩하며 느낀 점들을 몇 가지 정리해 보았습니다.

코딩 워크플로우 (Coding Workflow)

최근 LLM의 코딩 능력이 비약적으로 상승하면서, 저를 포함한 많은 이들의 작업 방식이 급변했습니다. 11월만 해도 '수동+자동완성'이 80%, '에이전트'가 20%였다면, 12월에는 '에이전트 코딩'이 80%, **'수정 및 다듬기'가 20%**로 바뀌었습니다. 즉, 이제는 거의 영어로 프로그래밍을 하고 있습니다. 약간은 쑥스러운 기분으로 LLM에게 어떤 코드를 짤지 '말로' 지시하는 식이죠.

자존심이 조금 상하긴 하지만, 대규모 "코드 액션" 단위로 소프트웨어를 다루는 힘은 그 유용성이 압도적입니다. 특히 이 방식에 적응하고, 설정하고, 활용법을 익히고, 모델의 한계를 파악하고 나면 더욱 그렇습니다. 개발 경력 20년 만에 제 코딩 워크플로우에 일어난 가장 큰 변화이며, 이 모든 것이 단 몇 주 만에 일어났습니다. 아마 현업 엔지니어의 두 자릿수 퍼센트 이상이 비슷한 경험을 하고 있을 것으로 보이지만, 일반 대중의 인식은 여전히 한 자릿수 퍼센트에 머물러 있는 것 같습니다.

IDE / 에이전트 스웜 / 결함 가능성

"이제 IDE는 필요 없다"거나 "에이전트 스웜(Agent Swarm)"이 대세라는 식의 하이프(Hype)는 현재로선 좀 과하다고 생각합니다. 모델은 분명히 실수를 합니다. 정말 중요한 코드라면 옆에 커다란 IDE를 띄워놓고 매의 눈으로 감시해야 합니다.

실수의 양상도 달라졌습니다. 더 이상 단순한 구문 오류(Syntax error)가 아닙니다. 마치 덤벙거리고 서두르는 주니어 개발자가 저지를 법한 미묘한 개념적 오류에 가깝습니다. 가장 흔한 케이스는 모델이 제멋대로 가정을 내리고 확인도 없이 밀고 나가는 경우입니다. 또한 혼란을 스스로 관리하지 못하고, 명확한 설명을 요구하지 않으며, 불일치를 드러내거나 트레이드오프를 제시하지도 않습니다. 반박해야 할 때 반박하지 않고 여전히 지나치게 비위를 맞추려(sycophantic) 합니다.

'계획 모드(Plan mode)'에서는 좀 나아지지만, 가벼운 '인라인 계획 모드'가 필요해 보입니다. 또한 모델들은 코드와 API를 과하게 복잡하게 만들고, 추상화를 남발하며, 쓰지 않는 코드(Dead code)를 정리하지 않는 경향이 있습니다. 1,000줄짜리 비효율적이고 취약한 구조를 만들어 놓았을 때, 제가 "음, 그냥 이렇게 하면 되지 않아?"라고 하면 그제야 "물론이죠!"라며 즉시 100줄로 줄여버리곤 하죠. 가끔은 작업과 전혀 상관없는 주석이나 코드를 자기 맘에 안 든다거나 이해가 안 된다는 이유로 지워버리기도 합니다. CLAUDE.md에 지침을 넣어 해결해보려 해도 이런 일들이 발생합니다.

그럼에도 불구하고, 이는 결과적으로 엄청난 발전이며 다시 수동 코딩으로 돌아가는 것은 상상하기 어렵습니다.

요약하자면: 왼쪽에는 Ghostty 윈도우/탭에 Claude 대화창을 띄우고, 오른쪽에는 코드 확인 및 수동 수정을 위한 IDE를 띄워두는 것이 현재 저의 개발 흐름입니다.

끈기 (Tenacity)

에이전트가 끈질기게 문제를 붙들고 늘어지는 모습은 매우 흥미롭습니다. 지치지도 않고, 사기가 꺾이지도 않습니다. 사람이면 진작에 포기하고 내일을 기약했을 상황에서도 계속해서 시도합니다. 한참을 끙끙대다가 30분 뒤에 결국 승리하는 모습을 보면 **"AGI를 느낀다"**는 말이 절로 나옵니다. '지구력'이 작업의 핵심 병목이었음을 깨닫게 되며, LLM을 통해 이 능력이 비약적으로 확장되었습니다.

가속도 (Speedups)

LLM 지원을 통한 '속도 향상'을 어떻게 측정해야 할지 모호합니다. 분명히 원래 하려던 작업은 훨씬 빨라졌지만, 핵심은 전에는 엄두도 못 냈을 일들을 훨씬 더 많이 하게 되었다는 점입니다.

1. 전에는 코딩할 가치가 없다고 느꼈던 온갖 것들을 짜게 되었고,

2. 지식이나 기술 부족으로 손대지 못했던 코드에 접근할 수 있게 되었습니다.단순한 속도 향상을 넘어선 '확장'에 가깝습니다.

레버리지 (Leverage)

LLM은 특정 목표를 달성할 때까지 루프를 도는 데 탁월하며, 여기서 AGI의 마법이 느껴집니다. 무엇을 할지 일일이 말하지 말고, **성공 기준(Success criteria)**을 주고 지켜보세요. 테스트 코드를 먼저 짜게 한 뒤 통과시키게 하거나, 브라우저 MCP와 함께 루프에 넣으세요. 먼저 정답일 확률이 높은 단순한 알고리즘을 짜게 한 뒤, 정확성을 유지하며 최적화하라고 시키는 식입니다. 명령형(Imperative)에서 선언형(Declarative)으로 접근 방식을 바꾸면 에이전트가 더 오래 루프를 돌며 레버리지를 높일 수 있습니다.

재미 (Fun)

에이전트 덕분에 프로그래밍이 더 즐거워질 줄은 몰랐습니다. 단순 반복 작업(drudgery)이 사라지고 창의적인 부분만 남았기 때문입니다. 막히는 느낌(이건 전혀 즐겁지 않죠)도 덜하고, LLM과 협력해 어떻게든 진전시킬 수 있다는 확신이 생겨 더 용기 있게 도전하게 됩니다.

물론 반대 의견도 있습니다. LLM 코딩은 엔지니어를 두 부류로 나눌 것입니다. **'코딩 그 자체를 좋아했던 사람'**과 **'무언가를 만드는 것(Building)을 좋아했던 사람'**으로요.

퇴화 (Atrophy)

이미 수동 코딩 능력이 서서히 퇴화하는 것을 느끼고 있습니다. 뇌에서 생성(코드 작성)과 판별(코드 읽기)은 서로 다른 능력입니다. 프로그래밍에 수반되는 자잘한 구문적 디테일들 때문에, 코드를 직접 쓰기는 힘들어져도 리뷰하는 데는 아무 지장이 없을 수 있습니다.

슬롭아포칼립스 (Slopacolypse)

저는 2026년을 GitHub, Substack, Arxiv, SNS 등 모든 디지털 미디어에 '슬롭(Slop, AI가 만든 저질 콘텐츠)'이 넘쳐나는 **'슬롭아포칼립스'**의 해가 될 것으로 보고 대비하고 있습니다. 실질적인 개선 이면에, AI 하이프를 이용한 생산성 연극(Productivity theater)도 훨씬 더 많이 보게 될 것입니다.

질문들 (Questions)

제 머릿속을 떠도는 질문들입니다:

• **'10배수 엔지니어(10X Engineer)'**는 어떻게 될 것인가? 평균과 최상위 엔지니어의 생산성 격차는 훨씬 더 벌어질 가능성이 큽니다.

• LLM을 무장한 제너럴리스트가 스페셜리스트를 압도하게 될까? LLM은 거시적 전략(Macro)보다 빈칸 채우기(Micro)에 훨씬 강합니다.

• 미래의 LLM 코딩은 어떤 느낌일까? 스타크래프트? 팩토리오? 아니면 악기 연주?

• 사회 전체가 '디지털 지식 노동'에 의해 얼마나 병목 현상을 겪고 있는가?

결론: 우리는 어디에 있는가?

LLM 에이전트 능력(특히 Claude와 Codex)은 2025년 12월경 모종의 '일관성 임계점'을 넘었으며, 소프트웨어 공학 및 관련 분야에 위상 변화(Phase shift)를 일으켰습니다. 이제 '지능' 영역이 도구, 지식과의 통합, 새로운 조직 워크플로우, 프로세스 등 다른 모든 요소보다 한참 앞서 나가는 느낌입니다. 2026년은 업계가 이 새로운 능력을 소화해 내느라 에너지가 넘치는 한 해가 될 것입니다.